Law/context/10_development_execution_plan.md

План Разработки (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	сделано	Hardening/release	Полировка безопасности, логирования, лимитов, отказоустойчивости, документации API/UI и runbook	Проект готов к стабилизации и приемке
P23	сделано	Mobile UX	Мобильная адаптация лендинга и клиентских форм (заявка, OTP, кабинет клиента: чат, файлы, история)	UI корректно работает на 320-768px, элементы доступны и читаемы без горизонтального скролла
P24	сделано	Тарифы юристов	Добавить ставку и процент юриста (по умолчанию в профиле), а также фиксируемые в заявке поля ставки/суммы (override админом)	Финансовые поля заявки фиксируются и не зависят от последующих правок профиля; клиенту не показываются
P25	сделано	Биллинг-статус	Добавить тип статуса «выставление счета»: генерация счета из шаблона, отправка клиенту и фиксация события оплаты по смене статуса администратором на Оплачено	Для темы можно включить billing-этап, счет формируется и доставляется; факт оплаты фиксируется по событиям Оплачено (возможны множественные события в одной заявке)
P26	сделано	Security Audit	Внедрить аудит безопасности и защиту ПДн для S3/файлов по требованиям РФ и кибербезопасности	Реализован журнал доступа, шифрование, RBAC/least-privilege, политика хранения и контроль инцидентов
P27	сделано	Итоговое тестирование E2E	Покрыть ключевые бизнес-сценарии: OTP, claim, auto-assign v2, чат, файлы, SLA, уведомления, read markers и выполнить финальный регрессионный прогон	Набор автотестов фиксирует регрессии критичных сценариев и подтверждает готовность перед приемкой

Критический маршрут (обязательный порядок)

1. P07 -> P08 -> P09 -> P10 (полный контур назначения).
2. P11 -> P12 -> P13 (публичный клиентский контур).
3. P14 -> P15 -> P16 (процесс работы по заявке).
4. P17 -> P18 -> P24 -> P25 -> P19 -> P20 -> P21 (файлы, SLA, тарифы/биллинг, аналитика).
5. P22 -> P23 -> P26 -> P27 (стабилизация, mobile UX, security-аудит, итоговые тесты в конце).

Правила выполнения для ИИ-агента

1. Не менять бизнес-правила без обновления context/*.md.
2. Любую новую таблицу добавлять только через миграции + тест миграций.
3. На каждый новый endpoint добавлять позитивный и негативный автотест.
4. Для RBAC: сначала ограничить доступ, затем открывать минимально необходимое.
5. Для операций назначения использовать транзакционную защиту от гонок.
6. Для статусов и SLA использовать только серверную валидацию (не доверять фронту).
7. Перед переводом пункта в сделано выполнять проверки из context/11_test_runbook.md.