156 lines
13 KiB
Markdown
156 lines
13 KiB
Markdown
# Задание AGY: доведение `krona-front` после контрольного аудита
|
||
|
||
## 1. Цель
|
||
|
||
Довести интерактивный frontend-прототип Krona Business Platform до состояния, в котором заявленная функциональность действительно работает и проверяется автоматическими тестами.
|
||
|
||
Это задание исправляет результат коммита `0e4c0f7`. Нельзя ограничиваться изменением документации, скрытием предупреждений линтера или ослаблением тестов.
|
||
|
||
## 2. Исходное состояние
|
||
|
||
- Production build проходит.
|
||
- 97 unit/component тестов проходят.
|
||
- `npm run lint` завершается с кодом 0, но выдаёт около 186 предупреждений.
|
||
- 9 Playwright E2E-тестов не были выполнены из-за отсутствующего Chromium.
|
||
- E2E-тест с названием про перемещение сделки фактически не выполняет перемещение.
|
||
- Configuration Engine объявляет поддержку 39+ типов, однако runtime renderer полноценно поддерживает только часть.
|
||
- IndexedDB и сервисные контракты не готовы к tenant-aware подключению backend.
|
||
- В проекте дублируются `shared/components` и `shared/ui`.
|
||
- README и `FEATURE-COVERAGE.md` содержат завышенные или устаревшие утверждения.
|
||
|
||
## 3. Обязательные работы
|
||
|
||
### Этап A. Честная система качества
|
||
|
||
1. Исправить все предупреждения `oxlint`, включая:
|
||
- неиспользуемые импорты, параметры и state;
|
||
- синхронные `setState` внутри effects;
|
||
- `Date.now()` и другие impure-вызовы во время render.
|
||
2. Включить режим, при котором предупреждения линтера ломают CI.
|
||
3. Добавить единый скрипт `npm run check`, выполняющий последовательно:
|
||
- lint без предупреждений;
|
||
- TypeScript typecheck;
|
||
- unit/component tests;
|
||
- production build;
|
||
- E2E.
|
||
4. Playwright должен устанавливаться воспроизводимо:
|
||
- локальная команда установки браузера описана в README;
|
||
- CI устанавливает Chromium с необходимыми зависимостями;
|
||
- отсутствие браузера не маскируется как пропуск или успех.
|
||
5. Не коммитить `test-results`, traces и генерируемые screenshots, кроме отдельно утверждённых visual baselines.
|
||
|
||
### Этап B. Настоящие E2E-сценарии
|
||
|
||
Переписать `e2e/app.spec.ts` и при необходимости разделить тесты по файлам. Каждый тест обязан совершать заявленное действие и проверять устойчивый результат.
|
||
|
||
Минимальный набор:
|
||
|
||
1. Dashboard открывается без runtime/console/page errors и горизонтального overflow на desktop/tablet/mobile.
|
||
2. Переключение темы выполняется через UI, сохраняется после reload и проверяется по фактическому состоянию приложения. Запрещено подменять проверку прямой установкой `data-theme`.
|
||
3. CRM: перетащить сделку в другую колонку, проверить изменение стадии и сохранение после reload.
|
||
4. CRM: создать лид, конвертировать его в контакт и сделку, проверить появление всех результатов.
|
||
5. Сделка `Won`: создать заказ и проверить его в разделе продаж.
|
||
6. Заказ: подтверждение → резерв → оплата → отгрузка; проверить изменения склада и финансов.
|
||
7. Configuration Engine: создать кастомную сущность, добавить поля разных групп, собрать форму, сохранить запись и проверить её после reload.
|
||
8. View Builder: изменить порядок колонок настоящим drag-and-drop и проверить сохранение.
|
||
9. RBAC: разрешённый маршрут доступен, запрещённый приводит на корректный 403.
|
||
10. Export/import/reset IndexedDB: экспортировать изменённое состояние, сбросить, импортировать и проверить восстановление.
|
||
|
||
Использовать устойчивые `data-testid` или role/name locators. Не использовать селекторы вида «любой `[draggable=true]`», если тест относится к конкретной сущности.
|
||
|
||
### Этап C. Полная реализация типов полей
|
||
|
||
Согласовать реестр типов с нормативным `docs/52-FIELD-TYPES-REFERENCE.md` Business Platform. Один канонический список должен использоваться Builder, renderer, validation, table, card и serialization.
|
||
|
||
Для каждого заявленного типа реализовать корректные ввод, readonly-отображение, validation и сериализацию. В частности:
|
||
|
||
- `multiselect` / `multi_select`, `checkbox_group` — массив значений, не строка;
|
||
- `rating` — ограниченный числовой контрол;
|
||
- `time` — `input[type=time]`;
|
||
- `url`, `color` — соответствующие контролы и validation;
|
||
- `file`, `image` — mock upload/storage abstraction с metadata и preview, не текстовое поле;
|
||
- `address`, `location` — структурированный формат либо явно документированный MVP-контракт;
|
||
- `user`, `employee`, `team`, `company`, `contact`, `product`, `entity_relation`, `entity_ref` — selector записей с хранением стабильного ID;
|
||
- `formula` — readonly вычисление по безопасному ограниченному выражению; запрещён `eval`/`Function`;
|
||
- `autonumber` — readonly значение из отдельного генератора;
|
||
- `json` — JSON parse/validation и хранение объекта, а не необработанной строки;
|
||
- `rich_text` — безопасный ограниченный редактор/формат; не допускать небезопасный HTML;
|
||
- `money` — minor units плюс ISO 4217 currency, без float как доменного значения;
|
||
- `decimal` — не смешивать с money; определить сериализацию без неявной потери точности.
|
||
|
||
Удалить дублирующие псевдонимы типов либо реализовать явную backward-compatible normalization. Добавить parameterized contract tests на каждый тип.
|
||
|
||
### Этап D. Tenant-aware frontend contracts
|
||
|
||
Прототип остаётся без backend, но его контракты должны позволять подключить платформу без переписывания UI.
|
||
|
||
1. Ввести `AppContext`/`RequestContext` как минимум с `tenantId`, `actorId`, `roleIds`, `correlationId`.
|
||
2. Все repository/service methods должны принимать контекст явно или через типизированный provider.
|
||
3. IndexedDB demo storage должен изолировать данные по `tenantId`:
|
||
- составной ключ или tenant-aware ключи/индексы;
|
||
- tenant filter обязателен для get/list/update/delete;
|
||
- импорт и экспорт относятся к явно выбранному tenant;
|
||
- нельзя прочитать/изменить запись другого tenant по известному ID.
|
||
4. Добавить тесты tenant isolation для records, metadata, layouts, views, audit и settings.
|
||
5. Описать адаптер `mock ↔ REST API`, включая auth/401/403, validation errors, pagination, optimistic concurrency и correlation IDs.
|
||
|
||
### Этап E. UI-kit и архитектурная очистка
|
||
|
||
1. Выбрать один канонический путь: предпочтительно `src/shared/ui`.
|
||
2. Перевести потребителей со `src/shared/components`, затем удалить дубли без поломки интерфейса.
|
||
3. Устранить слишком крупные модули (`CrmModule`, builders) путём выделения экранов, hooks и domain actions. Не делать механическую нарезку без ясных границ.
|
||
4. Исправить несоответствие README: `QueryClientProvider` либо реально внедрить при необходимости, либо удалить упоминание.
|
||
5. Удалить неиспользуемые зависимости и проверить production bundle. Зафиксировать разумные budget-пороги для initial JS и крупных lazy chunks.
|
||
|
||
### Этап F. Честная документация готовности
|
||
|
||
1. Обновить README и `FEATURE-COVERAGE.md` по фактическому результату.
|
||
2. Различать:
|
||
- готовый интерактивный сценарий;
|
||
- target prototype;
|
||
- demo-only;
|
||
- placeholder;
|
||
- ожидает backend.
|
||
3. Не писать «100% готово», если проверены только render и наличие кнопки.
|
||
4. Число тестов не вводить вручную в badge либо обновлять автоматически.
|
||
5. Для каждого модуля указать реально работающие CRUD/actions, persistence, ограничения и непокрытые сценарии.
|
||
|
||
## 4. Запреты
|
||
|
||
- Не отключать lint-правила ради зелёного результата.
|
||
- Не заменять E2E unit-тестами.
|
||
- Не использовать `test.skip`, условный early return или фиктивные проверки для обязательных сценариев.
|
||
- Не проверять только наличие элемента, если сценарий заявляет изменение данных.
|
||
- Не добавлять фиктивный backend и не привязывать UI напрямую к endpoint без service adapter.
|
||
- Не хранить tenant только в визуальном state без фильтрации storage/repositories.
|
||
- Не заявлять поддержку типа поля, если он отображается обычным текстовым input.
|
||
- Не коммитить секреты, локальные `.local`, build artifacts и Playwright output.
|
||
|
||
## 5. Приёмочные критерии
|
||
|
||
Работа принимается, когда:
|
||
|
||
1. `npm ci` проходит на чистом checkout.
|
||
2. `npm run lint` даёт 0 ошибок и 0 предупреждений.
|
||
3. TypeScript strict typecheck проходит.
|
||
4. Все unit/component tests проходят.
|
||
5. Все обязательные Playwright tests реально выполняются в Chromium и проходят на трёх viewport.
|
||
6. Production build проходит, а budget-проверка не нарушена.
|
||
7. Каждый заявленный тип поля имеет contract test и минимум один integration test renderer → save → reload → readonly.
|
||
8. Tenant isolation доказана негативными тестами.
|
||
9. DnD проверен мышью и доступной клавиатурной альтернативой.
|
||
10. README и coverage matrix соответствуют фактам.
|
||
11. Рабочее дерево после проверок чистое.
|
||
|
||
## 6. Порядок сдачи
|
||
|
||
1. Работать в ветке `codex/frontend-remediation`.
|
||
2. Делать небольшие логические коммиты по этапам A–F.
|
||
3. В финальном отчёте приложить:
|
||
- список исправлений;
|
||
- команды и полный итог проверок;
|
||
- количество unit и E2E тестов;
|
||
- список сознательно оставшихся ограничений;
|
||
- ссылку на PR.
|
||
4. Не сливать PR самостоятельно без отдельной команды владельца.
|
||
|