82 lines
7.2 KiB
Markdown
82 lines
7.2 KiB
Markdown
# Ответ Соннета: 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.
|