# Ответ Соннета: code review pipeline сверки

Дата получения: 2026-08-27  
Источник: пользовательский attachment `Pasted text #1`  
Статус: внешний отчёт, не подтверждённый текущим агентом

## Область

Соннет анализировал pipeline собственно сверки: `process.py`, `pipeline_bp.py`, `compare.js`, `app.js`, `llm.py`, `llm_client.py`, `llm_prompt.py`, `spec_events.py`, `spec_current.py`, `supplements.py`, `connection.py`, `metrics.py` и связанные тесты. Upload, ZIP, парсинг, классификация и grouping заявлены как исключённые из scope.

## Заявленные findings

### BLOCKER

- **B-1:** backend выдаёт событие `complete`, frontend обрабатывает только `done`; успешная сверка отображается как ошибка соединения.
- **B-2:** `apply_ops()` якобы не имеет единой транзакции; при сбое возможен частичный commit и недостоверная summary.
- **B-3:** UPDATE поля `name` якобы не пересчитывает `name_hash`, что может привести к дублированию строки при следующем документе.

### HIGH

- **H-1:** ветка неизвестного action якобы не увеличивает `seq`.
- **H-2:** summary `apply_ops()` якобы не содержит `unresolved`, поэтому счётчик недоступен UI.
- **H-3:** результат `check_arithmetic()` игнорируется; арифметическая ошибка не попадает в SSE/UI.
- **H-4:** `full_replace` с пустым `ops` якобы сначала очищает current state и затем успешно применяет ноль операций.

### MEDIUM

- **M-1:** pipeline безусловно завершает работу событием `complete`, даже после ошибок всех документов.
- **M-2:** отсутствует блокировка двух одновременных сравнений одного `contract_id`.
- **M-3:** отсутствует клиентский timeout SSE.
- **M-4:** `last_event_id` в `spec_current` якобы никогда не заполняется, поэтому cleanup supplement не работает.

### LOW

- **L-1:** сортировка по `doc_date` и `created_at` в `process.py` использует поля, которые якобы не возвращаются `supplements.list_by_contract()`.
- **L-2:** пустой `current_spec` не различает штатный первый документ и состояние после ошибки.

## Ответы Соннета на обязательные вопросы

1. Допник без базового договора не фильтруется; при пустом current state получает extract prompt и может быть ошибочно обработан как базовый документ.
2. `run_pipeline()` считает сверку успешной при наличии хотя бы одного supplement и безусловно выдаёт финальное событие.
3. Да, финальное событие может прийти после `extract_error`, включая случай, когда ошиблись все документы.
4. `complete` против `done` объявлено реальным frontend/backend багом.
5. Пустой `full_replace` очищает спецификацию; это признано опасным.
6. Частичный `apply_ops()` якобы остаётся в БД, но UI получает `extract_error` и неверную нулевую summary.
7. Единой транзакции current state и event history, по мнению Соннета, нет.
8. Повторный запуск сначала очищает состояние; последовательный запуск может дать чистый результат, конкурентный опасен.
9. Конкурентные pipeline для одного договора создают race condition и риск коллизий `seq`.
10. Пустой корректный ответ и повреждённый/неполный ответ не различаются.
11. `UNRESOLVED` сохраняется в `spec_events`, но не отображается пользователю и не включается в summary.
12. Арифметическая ошибка может остаться в БД, а pipeline всё равно завершиться успешно.
13. Нужны тесты для финального события, rollback, смены name, пустого full_replace, unknown action, unresolved summary, arithmetic warning и concurrency.
14. Главные риски: частичные commits, дублирование после смены name, уничтожение состояния при пустом full_replace, ложная ошибка UI и отсутствие защиты от concurrency.

## Предложенный Соннетом порядок исправлений

1. `complete` -> `done`.
2. Пересчёт `name_hash` при изменении `name`/`date_start`.
3. Запрет пустого `full_replace` до очистки state.
4. Единая транзакция для `apply_ops()`.
5. Инкремент `seq` для неизвестного action.
6. Счётчик `unresolved` и `total_unresolved`.
7. SSE warning для arithmetic mismatch.
8. `had_errors` в финальном событии.
9. Заполнение `last_event_id`.

## Что не является подтверждённым фактом

Этот файл фиксирует именно ответ Соннета. Ни один finding здесь не следует считать основанием для изменения кода до повторной проверки:

- по исходникам;
- по фактической схеме БД и реализации connection layer;
- по тестам;
- по реальному frontend/backend event contract;
- по воспроизводимому сценарию.

Следующий этап: критическая повторная проверка каждого finding и уточнение вопросов Соннету только там, где в его отчёте останется неразрешённое противоречие или отсутствует доказательство.

## Уточнение пользователя

Соннет используется только для анализа. Он не должен писать код, патчи или diff, изменять файлы либо выполнять команды: это ограничение введено для контроля стоимости. Реализацию и проверки выполняем отдельно после критической перепроверки findings.