# План Разработки (Execution Plan) ## Назначение Этот файл фиксирует последовательность работ до завершения проекта. Используется ИИ-агентом как рабочий чеклист реализации. ## Правило статусов - `сделано` — реализовано в коде, покрыто тестами или подтверждено рабочим сценарием. - `к разработке` — еще не реализовано полностью или реализовано как заглушка. ## Порядок выполнения Работы выполняются строго сверху вниз по `ID`. Переход к следующему пункту возможен только после: 1. Обновления кода. 2. Обновления/добавления тестов. 3. Проверки `unittest` и миграций. 4. Обновления контекста (`context/*.md`) при изменении требований. ## Дорожная карта | ID | Статус | Блок | Задача для ИИ-агента | Критерий готовности | |---|---|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---| | P01 | сделано | База проекта | Поднять базовую архитектуру FastAPI + PostgreSQL + Redis + Celery + админку и лендинг | API запускается, миграции применяются, базовые страницы доступны | | P02 | сделано | Модели и миграции | Создать основные таблицы (`requests`, `topics`, `statuses`, `form_fields`, `messages`, `attachments`, `status_history`, `audit_log`, `admin_users`, `otp_sessions`, `quotes`) + системные поля | Миграции `0001-0003` проходят, тесты миграций зеленые | | P03 | сделано | Универсальный CRUD | Реализовать универсальный CRUD + RBAC по таблицам + аудит изменений | CRUD работает для справочников и пользователей, аудит пишется | | P04 | сделано | Пользователи и роли | CRUD пользователей, хеширование паролей, роль `ADMIN/LAWYER`, профильная тема (`primary_topic_code`) | Тесты на CRUD пользователей и пароли проходят | | P05 | сделано | Базовый auto-assign | Реализовать автоназначение через 24 часа по профильной теме и активной нагрузке | `auto_assign_unclaimed` назначает корректно, тесты проходят | | P06 | сделано | Базовая админ-панель | Перевод `admin.html` -> `admin.jsx`, универсальные таблицы/модалки/фильтры | Работа с сущностями через единый UI доступна | | P07 | сделано | Темы юриста (расширение) | Добавить связующую таблицу `admin_user_topics` для дополнительных тем юриста; обновить CRUD/UI/фильтры | У юриста: 1 основная + N дополнительных тем; выбор тем в UI и в API | | P08 | сделано | Назначение заявок (ручное) | Добавить endpoint «Взять в работу» для юриста с атомарной блокировкой (без гонок), только если заявка не назначена | Два юриста не могут одновременно взять одну заявку; takeover запрещен | | P09 | сделано | Переназначение | Добавить ADMIN-only ручное переназначение уже назначенной заявки | Юрист не может перехватывать назначенные заявки, админ может переназначить | | P10 | сделано | Алгоритм auto-assign v2 | Доработать автоназначение: приоритет `primary_topic` -> `admin_user_topics` -> минимальная активная нагрузка (`is_terminal=false`) | Воркеры и тесты покрывают новый приоритет и edge-cases | | P11 | сделано | OTP create/view | Внедрить полноценный OTP-поток: OTP обязателен для создания заявки и просмотра по `track_number`, cookie JWT 7 дней | Без OTP нельзя создать/смотреть заявку; повторный OTP не нужен при валидной cookie | | P12 | сделано | Публичный кабинет клиента | Реализовать публичные endpoints и UI: просмотр статуса, чат, файлы, история изменений по `track_number` | Клиент может вести диалог и видеть прогресс заявки в одном контуре | | P13 | сделано | Read/unread маркеры | Добавить request-level маркеры «есть обновления» для клиента/юриста; открытие заявки сбрасывает маркер; одноразовая зеленая точка типа события | В списке заявок корректно отображаются непрочитанные обновления | | P14 | сделано | Статусные флоу по темам | Добавить настройку линейных флоу с допустимыми вариациями переходов (Jira-like), валидировать переходы | Нельзя выполнить переход вне разрешенной цепочки | | P15 | сделано | Иммутабельность по статусам | На смене статуса «замораживать» сообщения и вложения предыдущих статусов + писать `status_history` | Попытка изменения старых сообщений/файлов отклоняется API | | P16 | сделано | Шаблоны данных | Разделить шаблоны: (1) обязательные поля создания по теме; (2) шаблон дозапроса документов в работе, расширяемый юристом только для текущей заявки | Админ настраивает базу, юрист расширяет только в рамках конкретной заявки | | P17 | сделано | Файловый контур | Довести загрузку/скачивание файлов: лимиты 25MB/файл и 250MB/заявка, хранение метаданных, контроль суммарного объема | Лимиты enforced сервером, загрузки и скачивание стабильны | | P18 | сделано | SLA-конфиг | Настройка SLA на каждый переход статуса для каждой темы | SLA-конфиг хранится в БД, валидируется в админке | | P19 | сделано | SLA-check и overdue | Реализовать `sla_check`: контроль просрочек по переходам, расчет FRT/времени в статусе | Метрики и флаги просрочек обновляются по расписанию | | P20 | сделано | Уведомления | Уведомления в Telegram (если подключен) + внутренние уведомления сайта по изменениям | При событиях (сообщения/файлы/статусы/SLA) уведомления доставляются | | P21 | сделано | Dashboard LAWYER/ADMIN | Расширить дашборды: назначенные/неназначенные, активные по статусам, непрочитанные, SLA, по каждому юристу: активная загрузка, сумма активных заявок, вал оплаченных за месяц, зарплата за месяц | Дашборды соответствуют ролям и данным из БД | | P22 | к разработке | Тестирование E2E | Покрыть ключевые бизнес-сценарии: OTP, claim, auto-assign v2, чат, файлы, SLA, уведомления, read markers | Набор автотестов фиксирует регрессии критичных сценариев | | P23 | к разработке | Hardening/release | Полировка безопасности, логирования, лимитов, отказоустойчивости, документации API/UI и runbook | Проект готов к стабилизации и приемке | | P24 | к разработке | Mobile UX | Мобильная адаптация лендинга и клиентских форм (заявка, OTP, кабинет клиента: чат, файлы, история) | UI корректно работает на 320-768px, элементы доступны и читаемы без горизонтального скролла | | P25 | к разработке | Тарифы юристов | Добавить ставку и процент юриста (по умолчанию в профиле), а также фиксируемые в заявке поля ставки/суммы (override админом) | Финансовые поля заявки фиксируются и не зависят от последующих правок профиля; клиенту не показываются | | P26 | к разработке | Биллинг-статус | Добавить тип статуса «выставление счета»: генерация счета из шаблона, отправка клиенту и фиксация события оплаты по смене статуса администратором на `Оплачено` | Для темы можно включить billing-этап, счет формируется и доставляется; факт оплаты фиксируется по событиям `Оплачено` (возможны множественные события в одной заявке) | | P27 | к разработке | Security Audit | Внедрить аудит безопасности и защиту ПДн для S3/файлов по требованиям РФ и кибербезопасности | Реализован журнал доступа, шифрование, RBAC/least-privilege, политика хранения и контроль инцидентов | ## Критический маршрут (обязательный порядок) 1. `P07 -> P08 -> P09 -> P10` (полный контур назначения). 2. `P11 -> P12 -> P13` (публичный клиентский контур). 3. `P14 -> P15 -> P16` (процесс работы по заявке). 4. `P17 -> P18 -> P25 -> P26 -> P19 -> P20 -> P21` (файлы, SLA, тарифы/биллинг, аналитика). 5. `P22 -> P23 -> P24 -> P27` (стабилизация, mobile UX, security-аудит). ## Правила выполнения для ИИ-агента 1. Не менять бизнес-правила без обновления `context/*.md`. 2. Любую новую таблицу добавлять только через миграции + тест миграций. 3. На каждый новый endpoint добавлять позитивный и негативный автотест. 4. Для RBAC: сначала ограничить доступ, затем открывать минимально необходимое. 5. Для операций назначения использовать транзакционную защиту от гонок. 6. Для статусов и SLA использовать только серверную валидацию (не доверять фронту). 7. Перед переводом пункта в `сделано` выполнять проверки из `context/11_test_runbook.md`.