Этап 4 / Волна 18 закрытие блокеров по времени, доменной полярности и допуску доказательной базы

2026-03-29 00:40:06 +03:00
parent 7eb1410501
commit d7e145010b
140 changed files with 417053 additions and 42196 deletions
@@ -5,6 +5,12 @@
 Чеклист используется для приемки Stage 4 в текущей фазе (Wave 9):
 **P0 baseline hardening и формальная измеримость качества**.

+## Актуализация на 2026-03-28
+
+Этот чеклист оставлен для исторической фиксации Wave 9.
+Для текущего corrective-пакета Stage 4 использовать:
+`03_execution/ACCEPTANCE_CHECKLIST_STAGE_04_CORRECTIVE_PACK_2026-03-28.md`
+
 ## Статус

 - Дата актуализации: 2026-03-27
@@ -0,0 +1,188 @@
+# ACCEPTANCE_CHECKLIST_STAGE_04_CORRECTIVE_PACK_2026-03-28
+
+## Назначение
+
+Чеклист используется для формальной приемки Stage 4 corrective pack.
+Заполняется после каждого run и финально после двух live rerun подряд.
+
+## Правила статусов
+
+Допустимые статусы:
+- `PASS`
+- `PARTIAL`
+- `FAIL`
+- `N/A` (только с явным обоснованием)
+
+Для каждого пункта фиксируется:
+- что проверено
+- чем подтверждено (файл/метрика/trace)
+- какие ограничения остались
+
+## Блок A. Scope Discipline
+
+### A1. Stage 4 удержан в P0-only контуре (3 домена)
+Статус:
+Подтверждение:
+Комментарий:
+
+### A2. Нет расширения graph/schema/ontology
+Статус:
+Подтверждение:
+Комментарий:
+
+### A3. Нет выезда в Stage 5/6 как core path
+Статус:
+Подтверждение:
+Комментарий:
+
+### A4. Нет большого transport/routing refactor
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок B. Subwave 0 Session Isolation
+
+### B1. Межкейсовое загрязнение контекста устранено
+Статус:
+Подтверждение:
+Комментарий:
+
+### B2. В debug есть `question_scope_id` и `scope_origin`
+Статус:
+Подтверждение:
+Комментарий:
+
+### B3. `session_leakage_rate = 0` на контрольном наборе
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок C. Subwave A Temporal Anchor
+
+### C1. Temporal anchor для July snapshot корректен
+Статус:
+Подтверждение:
+Комментарий:
+
+### C2. Нет `2023/2025/2026/2030` и других out-of-window дат в grounded path
+Статус:
+Подтверждение:
+Комментарий:
+
+### C3. Неразрешимый temporal case уходит в limited answer
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок D. Subwave B Domain Polarity
+
+### D1. Supplier/account-60 не уходит в customer/receivable branch
+Статус:
+Подтверждение:
+Комментарий:
+
+### D2. Customer/account-62 не уходит в supplier/payable branch
+Статус:
+Подтверждение:
+Комментарий:
+
+### D3. Нет mixed semantic profile для single-focus кейсов
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок E. Subwave C Evidence Admissibility
+
+### E1. Inadmissible evidence не попадает в grounded answer
+Статус:
+Подтверждение:
+Комментарий:
+
+### E2. При `matched_rows = 0` live evidence не усиливает ответ
+Статус:
+Подтверждение:
+Комментарий:
+
+### E3. Future-dated/VAT contamination отсутствует в settlement кейсах
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок F. Subwave D Mechanism Contract
+
+### F1. Ответ формата mechanism-first (не checklist)
+Статус:
+Подтверждение:
+Комментарий:
+
+### F2. `mechanism_discrimination_rate >= 0.90`
+Статус:
+Подтверждение:
+Комментарий:
+
+### F3. Если уверенности недостаточно, используется честный top-2 с ранжированием
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок G. Regression / Metrics
+
+### G1. Прогнан минимум обязательный контрольный набор
+Статус:
+Подтверждение:
+Комментарий:
+
+### G2. Посчитаны метрики corrective pack
+Список:
+- `temporal_anchor_correctness_rate`
+- `domain_polarity_correctness_rate`
+- `evidence_admissibility_rate`
+- `mechanism_discrimination_rate`
+- `limited_answer_honesty_rate`
+- `session_leakage_rate`
+
+Статус:
+Подтверждение:
+Комментарий:
+
+### G3. Нет срабатывания hard fail criteria
+Статус:
+Подтверждение:
+Комментарий:
+
+## Блок H. Run Artifacts Discipline
+
+### H1. Для каждого run-пакета есть полный комплект артефактов
+Статус:
+Подтверждение:
+Комментарий:
+
+### H2. Артефакты предметно отражают фикс текущей подволны
+Статус:
+Подтверждение:
+Комментарий:
+
+### H3. Есть consolidated acceptance note после финального live rerun
+Статус:
+Подтверждение:
+Комментарий:
+
+## Итог
+
+- Результат: `PASS / PARTIAL / FAIL`
+- Дата:
+- Проверял:
+- Версия/ветка/commit:
+- Связанные run-папки:
+
+## Открытые ограничения
+
+1.
+2.
+3.
+
+## Обязательные next steps
+
+1.
+2.
+3.
@@ -0,0 +1,114 @@
+# RUN_ARTIFACTS_PROTOCOL_STAGE_04_CORRECTIVE_PACK
+
+## Назначение
+
+Протокол задает обязательный состав артефактов после каждого прогона Stage 4 corrective pack.
+Цель: любой run должен предметно подтверждать конкретный фикс подволны.
+
+## Базовая папка
+
+Все артефакты сохраняются в:
+`X:\1C\NDC_1C\llm_normalizer\docs\runs`
+
+## Именование run-папок
+
+Формат:
+`YYYY-MM-DD_Stage_04_Wave_<NN>_Subwave_<ID>_<ShortName>`
+
+Примеры:
+- `2026-03-29_Stage_04_Wave_17_Subwave_0_Session_Isolation`
+- `2026-03-29_Stage_04_Wave_18_Subwave_A_Temporal_Anchor_Hardening`
+- `2026-03-29_Stage_04_Wave_19_Subwave_B_Domain_Polarity_Lock`
+- `2026-03-30_Stage_04_Wave_20_Subwave_C_Evidence_Admissibility_Gate`
+- `2026-03-30_Stage_04_Wave_21_Subwave_D_Mechanism_Contract`
+- `2026-03-31_Stage_04_Wave_22_Subwave_E_Final_Live_Rerun_1`
+- `2026-03-31_Stage_04_Wave_23_Subwave_E_Final_Live_Rerun_2`
+
+Если требуется повтор подволны:
+- добавлять суффикс `_R1`, `_R2`, ...
+
+## Обязательная структура каждой run-папки
+
+1. `README.md`
+2. `run_summary.json`
+3. `before_after_metrics.json`
+4. `case_matrix.md`
+5. `prompt_dialogs/`
+6. `debug_payloads/`
+7. `acceptance_note.md`
+
+## Обязательное содержание артефактов
+
+### 1) `README.md`
+
+Минимум:
+- цель прогона
+- какая подволна и какой фикс проверяется
+- список контрольных кейсов
+- что считалось PASS/FAIL для этого прогона
+- краткий итог
+
+### 2) `run_summary.json`
+
+Минимум:
+- `run_id`
+- `stage`
+- `subwave`
+- `target_defect`
+- `verdict`
+- `hard_fail_triggered` (true/false)
+- ссылки на ключевые артефакты
+
+### 3) `before_after_metrics.json`
+
+Минимум:
+- baseline до фикса
+- значения после фикса
+- delta по каждой метрике corrective pack
+
+### 4) `case_matrix.md`
+
+Для каждого кейса:
+- case id
+- expected behavior
+- actual behavior
+- status
+- ссылка на trace/debug
+
+### 5) `prompt_dialogs/`
+
+Минимум:
+- диалоги по ключевым кейсам подволны
+- отдельный диалог по проблемному кейсу, который фиксился
+
+### 6) `debug_payloads/`
+
+Минимум:
+- не менее 3 payload:
+  - supplier/account-60
+  - VAT
+  - month-close
+- в payload должны быть видны причины отбраковки evidence и выбранный mechanism
+
+### 7) `acceptance_note.md`
+
+Минимум:
+- что именно исправлено в этой подволне
+- что осталось ограничением
+- решение: `PASS/PARTIAL/FAIL`
+- можно ли переходить к следующей подволне
+
+## Жесткие правила для достоверности артефактов
+
+1. Артефакты должны отражать именно целевой фикс текущей подволны, а не общий шум.
+2. Если прогон упал по hard fail criteria, это явно указывается в `run_summary.json` и `acceptance_note.md`.
+3. Нельзя отмечать прогон как PASS без заполненных `case_matrix.md` и `before_after_metrics.json`.
+4. Для финальной стабилизации обязательны 2 подряд live rerun с полным комплектом артефактов.
+
+## Мини-чек перед закрытием каждого run
+
+1. Папка создана по формату именования.
+2. 7 обязательных артефактов присутствуют.
+3. В `run_summary.json` указан целевой дефект и verdict.
+4. В `case_matrix.md` заполнены все контрольные кейсы этого прогона.
+5. Есть явное решение: переходим дальше или делаем rerun этой же подволны.
@@ -0,0 +1,185 @@
+# STAGE_04_CORRECTIVE_PACK_TASK_CARD_2026-03-28
+
+## Назначение
+
+Документ фиксирует рабочий план закрытия Stage 4 как live-grounded слоя для P0 бухгалтерских кейсов.
+План оформлен как один corrective pack с короткими подволнами и отдельным acceptance по каждой подволне.
+
+## Статус
+
+- Дата актуализации: 2026-03-28
+- Статус Stage 4: `OPEN_FOR_CORRECTIVE_PACK`
+- Базовый факт: Chat20 baseline green достигнут, но live/debug path показывает hard-fail по grounding
+- Режим: только Stage 4 corrective work, без выхода в Stage 5/6 как core path
+
+## Scope Stage 4 (фиксированный)
+
+Разрешены только P0 домены:
+- `settlements_60_62`
+- `vat_document_register_book`
+- `month_close_costs_20_44`
+
+## Что запрещено в corrective pack
+
+- Добавлять новые домены
+- Расширять ontology/graph/schema
+- Подтягивать Stage 5 investigation orchestration в core path
+- Добавлять Stage 6 live verification layer как архитектурный слой
+- Делать большой refactor transport/routing
+- Лечить качество общим ростом generic retrieval
+
+## Непокрытые acceptance-критерии Stage 4
+
+1. `temporal_correctness`
+2. `domain_polarity_correctness`
+3. `evidence_admissibility`
+4. `mechanism_specific_answer`
+5. `session_context_isolation`
+
+## Поэтапный план corrective pack
+
+Каждая подволна выполняется отдельным run с обязательными артефактами в:
+`X:\1C\NDC_1C\llm_normalizer\docs\runs`
+
+### Подволна 0. Session / Context Isolation
+
+Цель:
+- исключить межкейсовое загрязнение контекста и неверный перенос active focus
+
+Изменения:
+- в trace/debug явно фиксировать `question_scope_id` и `scope_origin`
+- в follow-up handling ввести защиту от переноса нерелевантного фокуса между независимыми кейсами
+
+Acceptance:
+- `session_leakage_rate = 0` на контрольном наборе
+- в debug payload видно, какой контекст активен и почему
+
+### Подволна A. Temporal Anchor Hardening
+
+Цель:
+- закрепить корректную привязку времени для company snapshot July 2020
+
+Изменения:
+- ввести `company_snapshot_temporal_lock`
+- hard priority: `explicit_from_question -> snapshot_context_lock -> limited_answer`
+- запретить relative/default year для snapshot-вопросов
+- hard-fail: time_scope вне окна snapshot не может идти в grounded answer
+
+Acceptance:
+- 100% попадание temporal anchor в окно `2020-07-01..2020-07-31` для snapshot-кейсов
+- 0 ответов с датами вне окна snapshot в grounded path
+
+### Подволна B. Domain Polarity Lock
+
+Цель:
+- устранить инверсию supplier/customer и payable/receivable
+
+Изменения:
+- `domain_polarity_guard` до retrieval ranking и до problem-unit assembly
+- hard veto:
+  - `supplier + account 60` не может резолвиться в customer/receivable branch
+  - `customer + account 62` не может резолвиться в supplier/payable branch
+- запрет mixed semantic profile для single-focus вопроса
+
+Acceptance:
+- 100% корректность polarity для core P0 вопросов
+- 0 случаев `customer_settlement` для supplier/account-60 case
+
+### Подволна C. Evidence Admissibility Gate
+
+Цель:
+- допускать в grounded answer только релевантные и доказательные факты
+
+Изменения:
+- `evidence_admissibility_gate` перед answer composer
+- правила допуска:
+  - дата в окне вопроса
+  - домен совпадает с active domain card
+  - account scope совместим
+  - weak mapping не используется как доказательство
+  - при `matched_rows = 0` live не усиливает grounded answer
+- классифицировать evidence на:
+  - `hard_evidence`
+  - `supporting_signal`
+  - `inadmissible_noise`
+
+Acceptance:
+- 0 inadmissible evidence в grounded answers
+- 0 future-dated evidence для snapshot-кейсов
+- 0 false-grounded ответов при `matched_rows = 0`
+
+### Подволна D. Mechanism-Specific Answer Contract
+
+Цель:
+- перейти от checklist-ответов к mechanism-first диагностике
+
+Изменения:
+- добавить `mechanism_discriminator` перед финальным answer composer
+- для settlements_60_62 различать минимум:
+  - `wrong_contract_binding`
+  - `wrong_settlement_object`
+  - `closure_document_not_confirmed`
+  - `partial_settlement_tail`
+  - `chronology_break`
+- основной механизм выбирается только при достаточном margin top1/top2; иначе честный top-2 с ранжированием
+
+Acceptance:
+- `mechanism_discrimination_rate >= 0.90`
+- symptom-first ответы выдают основной механизм, а не равноправный список гипотез
+
+### Подволна E. Final Live Stabilization
+
+Цель:
+- подтвердить устойчивость после фиксов
+
+Изменения:
+- 2 последовательных live rerun без красных регрессий
+- consolidated acceptance note по Stage 4 corrective pack
+
+Acceptance:
+- оба live rerun проходят hard fail criteria
+- зафиксирован итог `STAGE_04_READY_FOR_CLOSEOUT` или `STAGE_04_PARTIAL_WITH_EXPLICIT_LIMITATIONS`
+
+## Контрольный набор (минимум)
+
+1. supplier settlement case (оплата 55 200, незакрытый хвост)
+2. buyer advance offset case (276 873,60 / 62.02)
+3. VAT case (услуги связи + СФ 233,33)
+4. month-close case (закрытие косвенных расходов)
+5. RBP case
+6. limitation honesty case после полного month-end
+
+Предпочтительно: все 8 core вопросов Stage 4.
+
+## Метрики corrective pack
+
+- `temporal_anchor_correctness_rate`
+- `domain_polarity_correctness_rate`
+- `evidence_admissibility_rate`
+- `mechanism_discrimination_rate`
+- `limited_answer_honesty_rate`
+- `session_leakage_rate`
+
+## Hard fail criteria (красные линии)
+
+Любой из пунктов ниже автоматически валит прогон:
+- temporal anchor вне окна snapshot в grounded path
+- polarity inversion supplier/customer для 60/62 core кейсов
+- inadmissible evidence в блоке доказательств
+- false-grounded ответ при weak evidence или `matched_rows = 0`
+- межкейсовое загрязнение follow-up контекста
+
+## Процесс выполнения
+
+1. Одна подволна = один run
+2. Если подволна не прошла acceptance, делается rerun той же подволны до PASS
+3. Переход к следующей подволне только после PASS текущей
+4. После каждого run артефакты обязательно сохраняются в `docs/runs` по протоколу
+
+## Definition of Done для Stage 4 corrective pack
+
+Stage 4 corrective pack считается закрытым, если одновременно:
+- закрыты acceptance подволны 0/A/B/C/D/E
+- выполнены 2 подряд live rerun без красных регрессий
+- в `docs/runs` есть полный и воспроизводимый артефактный след по каждой подволне
+- выпущен consolidated acceptance note с честным перечнем оставшихся ограничений (если есть)
@@ -0,0 +1,93 @@
+# STAGE_04_CORRECTIVE_RUN_QUEUE_2026-03-28
+
+## Назначение
+
+Очередь прогонов для Stage 4 corrective pack с жестким порядком и entry/exit gate.
+Переход к следующему run разрешен только после PASS текущего.
+
+## Run Queue
+
+### Run 1
+
+- Run ID: `2026-03-29_Stage_04_Wave_17_Subwave_0_Session_Isolation`
+- Цель: снять межкейсовое загрязнение контекста
+- Entry: текущий baseline с воспроизводимым leakage кейсом
+- Exit:
+  - `session_leakage_rate = 0`
+  - debug содержит `question_scope_id` и `scope_origin`
+
+### Run 2
+
+- Run ID: `2026-03-29_Stage_04_Wave_18_Subwave_A_Temporal_Anchor_Hardening`
+- Цель: зафиксировать July 2020 temporal lock
+- Entry: PASS Run 1
+- Exit:
+  - 100% `temporal_anchor_correctness_rate` для snapshot-кейсов
+  - 0 out-of-window temporal в grounded path
+
+### Run 3
+
+- Run ID: `2026-03-29_Stage_04_Wave_19_Subwave_B_Domain_Polarity_Lock`
+- Цель: убрать supplier/customer polarity inversion
+- Entry: PASS Run 2
+- Exit:
+  - 100% `domain_polarity_correctness_rate` на core P0
+  - 0 `customer_settlement` для supplier/account-60
+
+### Run 4
+
+- Run ID: `2026-03-30_Stage_04_Wave_20_Subwave_C_Evidence_Admissibility_Gate`
+- Цель: не допускать нерелевантное evidence в grounded answer
+- Entry: PASS Run 3
+- Exit:
+  - 0 inadmissible evidence в grounded answers
+  - 0 false-grounded при `matched_rows = 0`
+
+### Run 5
+
+- Run ID: `2026-03-30_Stage_04_Wave_21_Subwave_D_Mechanism_Contract`
+- Цель: mechanism-first answer contract
+- Entry: PASS Run 4
+- Exit:
+  - `mechanism_discrimination_rate >= 0.90`
+  - symptom-first ответы дают основной механизм или честный top-2
+
+### Run 6
+
+- Run ID: `2026-03-31_Stage_04_Wave_22_Subwave_E_Final_Live_Rerun_1`
+- Цель: первая фиксация общей устойчивости после corrective pack
+- Entry: PASS Run 5
+- Exit:
+  - нет hard fail criteria
+  - полный комплект артефактов
+
+### Run 7
+
+- Run ID: `2026-03-31_Stage_04_Wave_23_Subwave_E_Final_Live_Rerun_2`
+- Цель: подтверждение стабильности вторым подряд прогоном
+- Entry: PASS Run 6
+- Exit:
+  - нет hard fail criteria
+  - metrics стабильны относительно Run 6
+  - подготовлен consolidated acceptance note
+
+## Обязательные артефакты для каждого run
+
+См. протокол:
+`03_execution/RUN_ARTIFACTS_PROTOCOL_STAGE_04_CORRECTIVE_PACK.md`
+
+Коротко, обязательно:
+1. `README.md`
+2. `run_summary.json`
+3. `before_after_metrics.json`
+4. `case_matrix.md`
+5. `prompt_dialogs/`
+6. `debug_payloads/`
+7. `acceptance_note.md`
+
+## Политика rerun
+
+Если run получает `PARTIAL` или `FAIL`:
+1. выполняется rerun той же подволны
+2. run ID получает суффикс `_R1`, `_R2`, ...
+3. переход к следующей подволне запрещен до `PASS`
@@ -0,0 +1,67 @@
+# STAGE_04_RUNTIME_GROUND_TRUTH_AUDIT_TASK_CARD_2026-03-28
+
+## Назначение
+
+Execution-карта для разворота Stage 4 из fix-wave режима в режим независимого runtime ground-truth аудита.
+
+## Цель
+
+Подтвердить фактический end-to-end runtime pipeline и доказательную основу ответов:
+`question -> route -> retrieval -> snapshot/live -> evidence -> answer`.
+
+## Non-goals
+
+- Не делать архитектурный redesign в этом задании.
+- Не запускать большой кодовый refactor как часть аудита.
+- Не закрывать Stage 4 по косвенным симптомам.
+
+## Рабочие фазы
+
+1. `Static architecture pass`
+- runtime call graph по фактическим код-путям.
+
+2. `Instrumentation pass`
+- временные hooks/logging для невидимых runtime решений.
+
+3. `Controlled runtime pass`
+- прогоны 8 core вопросов July 2020 с audit logging.
+
+4. `Comparative pass`
+- матрица по каждому кейсу: route/sources/evidence/claim/answer.
+
+5. `Structural gap analysis`
+- фиксация gaps и минимально необходимого следующего слоя.
+
+## Артефакты (обязательные)
+
+В `docs/ARCH`:
+- `7 - assistant_runtime_ground_truth_audit_2026-03-28.md`
+- `7A - runtime_call_graph.md`
+- `7B - snapshot_inventory_and_coverage.md`
+- `7C - live_mcp_call_inventory.md`
+- `7D - control_question_trace_matrix.md`
+- `7E - structural_gap_register.md`
+- `7F - instrumentation_notes.md`
+- `audit_artifacts/`
+
+## Формат верификации
+
+Каждое ключевое утверждение имеет минимум одно подтверждение:
+- code path;
+- runtime trace;
+- debug payload;
+- live call dump;
+- snapshot inspection.
+
+Маркировка:
+- `verified`
+- `partially verified`
+- `not verified`
+- `inferred`
+
+## Финальный выход
+
+Жесткий итоговый вердикт:
+- `VERIFIED_AS_EVIDENCE_FIRST`
+- `VERIFIED_AS_HYPOTHESIS_FIRST`
+- `MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`
@@ -5,6 +5,12 @@
 Документ фиксирует **актуальный implementation scope Stage 4** после завершения Waves 5-8 и запуска Wave 9.
 Он нужен для работы в узком P0-контуре и предотвращения расползания в будущие этапы.

+## Актуализация на 2026-03-28
+
+Этот документ сохраняется как исторический контекст Wave 9.
+Текущий рабочий execution-план по закрытию Stage 4 после live/debug hard-fail вынесен в:
+`03_execution/STAGE_04_CORRECTIVE_PACK_TASK_CARD_2026-03-28.md`
+
 ## Статус

 - Дата актуализации: 2026-03-27
@@ -0,0 +1,289 @@
+Да. Тут лучше не распиливать на десять мелких задач. Оптимальный формат — **одна ТЗ на corrective pack Stage 4**, но внутри неё сделать **4 короткие подволны** с отдельным acceptance на каждую. Это не ломает вашу текущую рамку, потому что Stage 4 у вас уже жёстко зафиксирован как `P0-only` по трём доменам, без новых доменов, без graph/schema expansion, без Stage 5/6 как core path и без больших транспортных рефакторингов. При этом сам отчёт уже показывает, что после зелёного `Chat20` у вас live-path всё ещё дочищался отдельными micro-fix проходами, а в follow-up прямо требуется финальный live-rerun и consolidated acceptance note. 
+
+Ниже даю ТЗ в форме, которую можно почти как есть отправлять в Codex.
+
+## ТЗ для Codex: Stage 4 Corrective Pack — Grounding / Polarity / Evidence / Mechanism
+
+### 1. Контекст
+
+Текущий Stage 4 формально удерживается в `P0-only` контуре по трём доменам:
+
+* `settlements_60_62`
+* `vat_document_register_book`
+* `month_close_costs_20_44`
+
+В рамках corrective work **запрещено**:
+
+* добавлять новые домены;
+* расширять graph/schema;
+* тащить внутрь core-path Stage 5 investigation;
+* строить новый live verification layer как архитектурный слой;
+* делать большие refactor transport/routing. 
+
+### 2. Цель corrective pack
+
+Нужно не расширять архитектуру, а **добить качество Stage 4 на live-path** для company-specific вопросов по июльскому снапшоту 2020 так, чтобы ассистент:
+
+* держал правильный temporal anchor;
+* не путал supplier/customer polarity;
+* не тащил нерелевантные live/snapshot evidence в ответ;
+* отвечал mechanism-first, а не checklist-ом из нескольких гипотез;
+* проходил контрольные P0-вопросы не только на Chat20, но и на живом trace/debug прогоне.   
+
+### 3. Зафиксированные дефекты, которые надо исправить
+
+На текущем прогоне по supplier settlement вопросу зафиксированы такие сбои:
+
+1. **Temporal anchor error**
+   Вопрос про оплату 6 июля в июльском снапшоте 2020 был нормализован в `time_scope = 2023-07-06`. 
+
+2. **Business scope / company grounding слабый**
+   `business_scope` остался `generic_accounting`, хотя вопрос company-specific и привязан к конкретному снапшоту. 
+
+3. **Domain polarity drift**
+   Кейс по поставщику / счёту 60 уходит в смесь supplier/customer логики, а problem units оказываются в `customer_settlement` и `stale_receivable`, что бухгалтерски неверно для supplier payable closure. При этом semantic profile одновременно содержит и `suppliers`, и `customers`, а graph traversal допускает `bank_settlement` и `customer_settlement` вместе. 
+
+4. **Evidence contamination / inadmissible evidence**
+   `live_mcp.matched_rows = 0`, но в evidence всё равно попадают live-элементы; среди них есть записи с проводками `68.02 / 19.04`, то есть VAT-контур, плюс даты 2025/2026/2030, что недопустимо для ответа по июльскому снапшоту 2020. Для части evidence уже помечено `weak_source_mapping`, но они всё равно используются как опора. 
+
+5. **Mechanism-first answer contract не дожат**
+   Вопросы в контрольном наборе специально проверяют, способен ли ассистент различать механизм разрыва: не тот договор, не тот объект расчётов, неполный closure, неполный VAT-edge, stale RBP и т.д. Сейчас ответ часто скатывается в общий partial-coverage checklist вместо выбора наиболее вероятного механизма и объяснения, почему именно он. 
+
+### 4. Объём работ
+
+Сделать **одну corrective wave**, но внутри неё 4 подволны.
+
+---
+
+## Подволна A — Temporal Anchor Hardening
+
+### Задача
+
+Запретить неверную интерпретацию даты/периода для company snapshot вопросов.
+
+### Что сделать
+
+1. В normalizer/router добавить `company_snapshot_temporal_lock`.
+2. Если вопрос явно относится к июльскому снапшоту 2020:
+
+   * не допускать авто-подстановку текущего/дефолтного года;
+   * не допускать relative reinterpretation;
+   * переводить время в fixed window `2020-07-01 .. 2020-07-31`, если вопрос не требует более узкого дня;
+   * если в вопросе явно указан день июля, привязывать к `2020-07-DD`.
+3. Добавить hard-fail guard:
+
+   * если extracted time_scope выходит за рамки company snapshot, answer не должен собираться как grounded.
+4. В debug/export явно показывать:
+
+   * raw time anchor;
+   * resolved time anchor;
+   * source of resolution (`explicit_from_question`, `snapshot_context_lock`, etc.).
+
+### Acceptance
+
+* Ни один вопрос из июльского контрольного набора не должен уходить в 2023/2025/2026/2030.
+* В debug payload temporal resolution должна быть прозрачной и объяснимой.
+* Если temporal anchor неразрешим, ответ обязан честно это признать, а не строить псевдо-grounded answer.  
+
+---
+
+## Подволна B — Domain Polarity Lock
+
+### Задача
+
+Убрать путаницу между supplier/customer, payable/receivable, 60/62 и month-close/VAT соседними контурами.
+
+### Что сделать
+
+1. Ввести `domain_polarity_guard` до retrieval ranking и до problem-unit assembly.
+2. Минимальные правила:
+
+   * `supplier + account 60 + obligation not closed` => только supplier/payable semantics.
+   * `buyer/customer + 62 + аванс/дебиторка` => только customer/receivable semantics.
+   * VAT domain не может подмешиваться в settlement answer без явного VAT-вопроса.
+   * month-close domain не может подменять settlement domain по общим lifecycle сигналам.
+3. Запретить mixed semantic_profile вида:
+
+   * `suppliers + customers` одновременно для одного single-focus question, если вопрос не cross-entity by design.
+4. Для problem units ввести polarity-aware mapping:
+
+   * supplier cases: `unresolved_supplier_settlement_cluster`, `supplier_document_conflict`, `supplier_partial_closure`
+   * customer cases: `unresolved_customer_settlement_cluster`, `customer_advance_offset_conflict`
+     Названия можно оставить внутренними, но логика должна быть раздельной.
+5. Если polarity не определена достаточно уверенно, ответ должен переходить в ограниченный режим с явным указанием, что именно не удалось различить.
+
+### Acceptance
+
+* Вопросы про счёт 60 и поставщика не должны производить `customer_settlement`, `stale_receivable`, `receivable_closed`.
+* Вопросы про 62/авансы покупателя не должны превращаться в supplier payable cases.
+* Domain drift между settlement / VAT / month-close должен быть снят не только по Chat20, но и по debug/live traces.  
+
+---
+
+## Подволна C — Evidence Admissibility Gate
+
+### Задача
+
+Запретить попадание в grounding нерелевантного evidence даже если retrieval что-то “нашёл”.
+
+### Что сделать
+
+1. Ввести `evidence_admissibility_gate` перед answer composer.
+2. Evidence допускается в grounded answer только если одновременно выполнено:
+
+   * дата попадает в допустимое временное окно вопроса;
+   * домен совпадает с активным domain card;
+   * account scope совместим с вопросом;
+   * source mapping не weak/ambiguous, либо такой evidence помечается только как limitation, но не как доказательство;
+   * если live probe дал `matched_rows = 0`, live evidence не усиливает answer.
+3. Запретить cross-domain contamination:
+
+   * VAT postings не попадают в settlement evidence;
+   * settlement traces не попадают в VAT proof без явной cross-branch задачи;
+   * month-close traces не усиливают settlement answer.
+4. Развести уровни evidence:
+
+   * `hard_evidence`
+   * `supporting_signal`
+   * `inadmissible_noise`
+5. В debug payload показывать:
+
+   * сколько evidence прошло gate;
+   * сколько отрезано и почему (`wrong_period`, `wrong_domain`, `wrong_account_scope`, `weak_source_mapping`, `zero_live_match`).
+
+### Acceptance
+
+* При `matched_rows = 0` live probe не должен добавлять ложную уверенность.
+* VAT проводки и future-dated live rows не должны попадать в settlement-grounded answer.
+* grounded answer без admissible evidence должен автоматически деградировать в честный limited answer. 
+
+---
+
+## Подволна D — Mechanism-Specific Answer Contract
+
+### Задача
+
+Заставить ассистента не просто перечислять проверки, а различать механизм разрыва и объяснять его.
+
+### Что сделать
+
+1. Для P0-доменов ввести `mechanism_discriminator` перед финальным answer composer.
+2. Для settlements_60_62 минимум различать:
+
+   * wrong_contract_binding
+   * wrong_settlement_object
+   * closure_document_not_confirmed
+   * partial_settlement_tail
+   * chronology_break
+3. Для VAT минимум различать:
+
+   * missing_invoice_link
+   * missing_tax_entry
+   * missing_purchase_book_entry
+   * partial_vat_chain
+4. Для month_close минимум различать:
+
+   * close_completed_but_tail_remains
+   * stale_rbp
+   * invalid_close_transition
+   * normal_residual_not_a_bug
+5. Финальный answer contract сделать таким:
+
+   * **Основной вывод**: один наиболее вероятный механизм.
+   * **Почему именно он**: 2–4 коротких grounding facts.
+   * **Что не доказано**: отдельный limitation block.
+   * **Что проверить первым**: 1–2 next checks, а не длинный checklist.
+6. Если discriminator не может выбрать один механизм честно:
+
+   * разрешено показать top-2 mechanism candidates,
+   * но с ранжированием и явным объяснением, почему первый выше второго.
+
+### Acceptance
+
+* Ответ на symptom-first вопросы должен содержать не набор равноправных гипотез, а основной mechanism candidate.
+* False confidence по VAT и month-close не допускается.
+* Ranking/truthful limitation из контрольного набора должны быть сохранены. 
+
+---
+
+## 5. Eval / Regression
+
+### Обязательный контрольный набор
+
+Минимум прогонять:
+
+1. supplier settlement case по оплате 55 200 / незакрытый хвост;
+2. buyer advance offset case 276 873,60 / 62.02;
+3. VAT case по услугам связи + счёт-фактура 233,33;
+4. month-close case по закрытию косвенных расходов;
+5. RBP case;
+6. limitation honesty case после полного month-end.
+
+Предпочтительно прогонять все 8 core-вопросов из вашего ядра. 
+
+### Новые метрики
+
+Добавить в harness:
+
+* `temporal_anchor_correctness_rate`
+* `domain_polarity_correctness_rate`
+* `evidence_admissibility_rate`
+* `mechanism_discrimination_rate`
+* `limited_answer_honesty_rate`
+
+### Минимальный проходной порог
+
+Для corrective acceptance:
+
+* 100% по temporal_anchor на контрольном наборе;
+* 100% по domain polarity на core P0 вопросах;
+* 0 inadmissible evidence в grounded answers;
+* не менее 0.9 по mechanism discrimination;
+* 0 false-grounded answers при weak evidence / zero live match.
+
+---
+
+## 6. Артефакты, которые нужно вернуть после реализации
+
+1. `run_summary.json`
+2. `before_after_metrics.json`
+3. `case_matrix.md` по контрольным вопросам
+4. `чат.txt` / dialog export по минимум 3 вопросам, лучше по 6–8
+5. `debug_payloads/` с примерами:
+
+   * supplier 60 case
+   * VAT case
+   * month-close case
+6. короткий `acceptance_note.md`:
+
+   * что исправлено;
+   * что осталось ограничением;
+   * прошёл ли final live rerun.
+
+Это согласуется с вашим текущим operational follow-up по Stage 4: нужен единый финальный live-rerun и короткая consolidated acceptance фиксация. 
+
+---
+
+## 7. Что не делать
+
+* Не добавлять новые домены.
+* Не расширять онтологию/graph ради этого фикса.
+* Не тащить Stage 5 investigation state как обязательный core-path.
+* Не делать большой рефактор маршрутизации.
+* Не пытаться “лечить” всё общим ростом generic retrieval.
+
+Задача corrective pack — не расширение платформы, а жёсткое добивание качества Stage 4 в уже зафиксированной P0-рамке. 
+
+---
+
+## 8. Ожидаемый итог
+
+После corrective pack система должна:
+
+* корректно держать июль 2020;
+* не путать supplier/customer и 60/62;
+* не использовать нерелевантные live/VAT/future traces как доказательство;
+* выдавать mechanism-first answer с честными ограничениями;
+* проходить контрольные company-specific P0 вопросы не только на корпусе, но и на живом trace/debug прогоне.  
+
+Если хочешь, следующим сообщением я могу сразу дать ещё **сверхкороткую версию этой ТЗ на 15–20 строк**, прямо в формате “вставить в Codex без лишнего контекста”.