ochenstarik/krona-front
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
krona-front/FRONTEND-REMEDIATION-TASK-FOR-AGY.md

13 KiB
Raw Permalink Blame History

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