# Задание 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 самостоятельно без отдельной команды владельца.