Document comparison review findings
Deploy contracts-flask / validate (push) Canceled after 0s

This commit is contained in:
“Naeel”
2026-08-27 11:24:32 +03:00
parent 811be85efe
commit f9745e5c6b
3 changed files with 429 additions and 0 deletions
@@ -0,0 +1,81 @@
# Ответ Соннета: 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.