contracts/History/llm-analysis/opus-plan-review.md

Ответ Opus на бриф — моё мнение

Что Opus сделал хорошо

1. Сверил бриф с кодом — подтвердил что группировка матчит по normalize_number, что прогресс-данные уже есть в /api/batch-progress, что сырой LLM-ответ не хранится. Без этого был риск писать план «в воздух».

2. Нашёл дубликат _handle_cleanup — я знал про это но не зафиксировал. Opus заметил сам. Побочная находка, полезно.

3. Риск baseline для виртуальных групп — ключевое. Если первый документ виртуальной группы — допник, а не базовый договор, то run_pipeline() может построить baseline из допника, а не из полной спецификации. Opus прав: это надо проверить перед релизом #1.

4. Приоритеты — правильно оценил: #3 тяжелее всего (миграция БД + 3 слоя), #2 легче всего (только UI). Совпадает с моей оценкой.

Где Opus ошибся или недоработал

1. Схема БД — написал «схема documents создаётся на ВМ, в репозитории её нет». Это правда, но миграция через ALTER TABLE на лету — хрупко. Лучше через seed_defaults() или отдельный ensure_schema(), как уже сделано для prompts. Opus не предложил механизм.

2. Два допника с одним parent_number, разными counterparty — Opus рекомендует разделять. Я бы наоборот: группировать по номеру, игнорировать counterparty. Потому что один договор может иметь одного контрагента в базовом договоре, а в допнике он может быть написан иначе (сокращение, другая оргформа). Риск ложного разделения выше чем риск ложного объединения.

3. Прогресс-бар в топбаре — идея ок, но топбар уже содержит лого + заголовок + «О сервисе». 4 этапа + текст займут место. Возможно лучше сделать отдельную строку под топбаром или внутри карточки результатов. Opus не учёл текущую вёрстку.

4. classify_raw vs parsed — Opus предлагает хранить только classify_raw. Я бы хранил и то и другое: classify_raw (текст) + classify_json (jsonb). Потому что сырой ответ может быть невалидным JSON, а для отладки нужны оба. Но это увеличивает трудозатраты — ок, можно только raw для начала.

Что я бы сделал иначе

1. Порядок реализации: #1 → #3 → #2. Потому что #1 (группировка) — самое востребованное заказчиком прямо сейчас. #3 (промежуточные результаты) даст данные для отладки #1 если что-то пойдёт не так. #2 (прогресс-бар) — вишенка, можно последней.

2. Для #1: вместо «виртуальной группы» — просто создавать реальный contract с флагом is_virtual=true или number из parent_number. Тогда apply_groups() не нужно менять вообще — contract уже существует, supplement просто привязывается. Меньше спецкейсов.

3. Для #3: вместо ALTER TABLE на лету — добавить колонку в ensure_schema() который вызывается при старте. Идемпотентно: ADD COLUMN IF NOT EXISTS. Уже есть прецедент с _ensure_classify_prompt().

Вердикт

План Opus — добротный, можно брать за основу. Три поправки выше (порядок, виртуальный contract через флаг, механизм миграции) — и можно делать.