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`.