Files
contracts-flask/History/sonnet-review-comparison-answer-2026-08-27.md
“Naeel” f9745e5c6b
Deploy contracts-flask / validate (push) Canceled after 0s
Document comparison review findings
2026-08-27 11:24:32 +03:00

7.2 KiB
Raw Permalink Blame History

Ответ Соннета: 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.