Stage 3: улучшена логика жизненного цикла и очищены ответы ассистента

docs/accounting-assistant/accounting-assistant/03_execution/ACCEPTANCE_CHECKLIST_STAGE_04.md

@@ -0,0 +1,272 @@
+# ACCEPTANCE_CHECKLIST_STAGE_04
+
+## Назначение документа
+
+Этот документ используется для приёмки реализации Stage 4.
+Его задача — проверить, что graph core внедрён как рабочий runtime-слой, а не как формальная схема.
+
+Документ обязателен для:
+- Codex;
+- разработчика;
+- ручного review;
+- финальной фиксации Stage 4.
+
+---
+
+## Статус документа
+
+- Статус: чеклист приёмки Stage 4
+- Язык: русский
+- Режим использования: обязателен при завершении каждой волны и при финальной приёмке Stage 4
+- При конфликте по scope приоритет имеет `STAGE_04_TASK_CARD.md`
+- При конфликте по архитектурным ограничениям приоритет имеет `ARCHITECTURE_GUARDRAILS.md`
+- При конфликте по platform logic приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
+
+---
+
+## Правила оценки
+
+Допустимые статусы:
+
+- `PASS` — выполнено полностью
+- `PARTIAL` — выполнено частично, требуется доработка
+- `FAIL` — не выполнено
+- `N/A` — не применимо (только с явным обоснованием)
+
+Для каждого пункта обязателен комментарий:
+- что проверялось;
+- где реализовано;
+- чем подтверждается;
+- какие ограничения остались.
+
+---
+
+## Общая логика приёмки
+
+Stage 4 считается принятым только если одновременно выполнено:
+
+1. Закрыт именно Stage 4, без скрытого выезда в Stage 5–6.
+2. Graph contracts реализованы и используются runtime.
+3. Graph traversal реально участвует в graph-eligible retrieval.
+4. Problem assembly использует graph connectivity.
+5. Lifecycle reasoning использует graph transitions.
+6. Answer layer использует graph-backed causal explanation.
+7. Есть benchmark/eval подтверждение value.
+8. Рабочий контур не разрушен.
+
+---
+
+# Блок A. Scope discipline
+
+## A1. Реализован именно Stage 4
+Статус:
+Комментарий:
+
+## A2. Нет скрытого выезда в Stage 5
+Статус:
+Комментарий:
+
+## A3. Нет скрытого выезда в Stage 6
+Статус:
+Комментарий:
+
+## A4. Нет большого ненужного platform refactor
+Статус:
+Комментарий:
+
+---
+
+# Блок B. Graph model
+
+## B1. Реализована schema `AccountingGraphNode`
+Статус:
+Комментарий:
+
+## B2. Реализована schema `AccountingGraphEdge`
+Статус:
+Комментарий:
+
+## B3. Внедрён `GraphSchemaRegistry`
+Статус:
+Комментарий:
+
+## B4. Узлы/связи имеют provenance/confidence
+Статус:
+Комментарий:
+
+## B5. Нет generic edges уровня `related_to` как основного механизма
+Статус:
+Комментарий:
+
+---
+
+# Блок C. Graph runtime
+
+## C1. Реализован `GraphBuilder`
+Статус:
+Комментарий:
+
+## C2. Реализован `GraphTraversalPolicy`
+Статус:
+Комментарий:
+
+## C3. Реализован `GraphValidationLayer`
+Статус:
+Комментарий:
+
+## C4. Missing/conflicting links детектируются как runtime-сигналы
+Статус:
+Комментарий:
+
+## C5. Runtime устойчив к неполным данным
+Статус:
+Комментарий:
+
+---
+
+# Блок D. Интеграция слоёв
+
+## D1. Planner поддерживает graph eligibility
+Статус:
+Комментарий:
+
+## D2. Execution использует typed graph traversal в graph-eligible запросах
+Статус:
+Комментарий:
+
+## D3. Problem assembly использует graph connectivity
+Статус:
+Комментарий:
+
+## D4. Lifecycle checks используют graph transitions
+Статус:
+Комментарий:
+
+## D5. Answer layer использует graph-backed causal path
+Статус:
+Комментарий:
+
+---
+
+# Блок E. Quality / eval
+
+## E1. Добавлены unit tests для graph contracts/runtime
+Статус:
+Комментарий:
+
+## E2. Добавлены integration tests для planner/execution graph path
+Статус:
+Комментарий:
+
+## E3. Regression по Stage 2/Stage 3 не сломан
+Статус:
+Комментарий:
+
+## E4. Есть benchmark suite Stage 4
+Статус:
+Комментарий:
+
+## E5. Есть before/after value report
+Статус:
+Комментарий:
+
+---
+
+# Блок F. Observability / compatibility
+
+## F1. Graph decisions и traversal диагностируемы
+Статус:
+Комментарий:
+
+## F2. Contracts и source of truth документированы
+Статус:
+Комментарий:
+
+## F3. Изменения совместимы с roadmap Stage 5
+Статус:
+Комментарий:
+
+## F4. Миграционная дисциплина соблюдена
+Статус:
+Комментарий:
+
+---
+
+# Блок G. Documentation completeness
+
+## G1. Есть актуальный `STAGE_04_TASK_CARD.md`
+Статус:
+Комментарий:
+
+## G2. Есть acceptance mapping `изменение -> критерий`
+Статус:
+Комментарий:
+
+## G3. Есть explicit non-scope список
+Статус:
+Комментарий:
+
+## G4. Run-артефакты оформлены по стандарту `date -> Stage -> Wave`, включая `prompt_dialogs`
+Статус:
+Комментарий:
+
+---
+
+# Блок H. Финальное решение по этапу
+
+## H1. Stage 4 можно считать принятым
+Статус:
+Комментарий:
+
+## H2. Stage 4 нельзя считать принятым
+Статус:
+Комментарий:
+
+---
+
+# Итоговая сводка по приёмке
+
+## Общий итог
+- Результат: `PASS / PARTIAL / FAIL`
+- Дата проверки:
+- Проверял:
+- Версия / ветка / commit:
+- Связанные документы:
+
+## Ключевые сильные стороны
+1.
+2.
+3.
+
+## Ключевые недочёты
+1.
+2.
+3.
+
+## Что обязательно исправить до приёмки
+1.
+2.
+3.
+
+## Что допустимо перенести в следующий этап
+1.
+2.
+3.
+
+## Явно подтверждено как non-scope текущего этапа
+1.
+2.
+3.
+
+## Финальное решение
+- `Принять Stage 4`
+- `Принять Stage 4 условно`
+- `Вернуть на доработку`
+
+Комментарий:
+
+---
+
+## Короткая практическая формула
+
+Stage 4 считается успешным тогда, когда graph layer реально работает в runtime и улучшает retrieval/problem/lifecycle/answer, а не только добавляет новую схему данных.

docs/accounting-assistant/accounting-assistant/03_execution/CODEX_MASTER_BRIEF.md

@@ -20,7 +20,7 @@
 - Статус: основной управляющий бриф для Codex
 - Язык: русский
 - Режим использования: обязателен к прочтению перед любыми изменениями в коде
-- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_03_TASK_CARD.md`
+- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_04_TASK_CARD.md`
 - При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
 
 ---
@@ -37,29 +37,29 @@
 - возвращать ответ пользователю.
 
 При этом текущая система ещё не является полноценным accountant-grade investigation copilot.  
-На текущем переходе считаем этапы 1 и 2 выполненными и переходим к **Stage 3 / Lifecycle Formalization**.
+Stage 3 зафиксирован как завершённый (accepted), и текущий переход — **Stage 4 / Accounting Ontology Graph Core**.
 
-Основные текущие ограничения, которые Stage 3 должен закрыть:
+Основные текущие ограничения, которые Stage 4 должен закрыть:
 
-- lifecycle-семантика остаётся частично эвристической;
-- отсутствует формализованная модель допустимых состояний/переходов по ключевым доменам;
-- problem units недостаточно насыщены temporal и stage-based смыслом;
-- ranking по ряду классов вопросов всё ещё тяготеет к frequency/sum/entity сигналам;
-- ответы местами остаются на уровне generic lifecycle labels.
+- отсутствует единое graph-представление бухгалтерских сущностей и связей;
+- причинно-следственные цепочки до сих пор частично собираются эвристически;
+- missing/conflicting links не являются first-class runtime-объектами;
+- lifecycle/problem reasoning недостаточно использует структурную graph-связность;
+- cross-branch traversal и period-impact проверки ограничены локальными rule bundles.
 
 ---
 
 ## Цель работы Codex на текущей итерации
 
-Codex должен помочь реализовать **только Stage 3**, не разрушая текущий рабочий контур и не подтягивая prematurely решения из следующих этапов.
+Codex должен помочь реализовать **только Stage 4**, не разрушая текущий рабочий контур и не подтягивая prematurely решения из следующих этапов.
 
 Текущая цель:
 
-- ввести формальную lifecycle-модель по целевым доменам Stage 3;
-- внедрить lifecycle runtime-компоненты и их использование в рабочем пути;
-- интегрировать lifecycle в problem units, ranking и answer synthesis;
+- ввести рабочее graph-ядро бухгалтерских сущностей и типизированных связей;
+- внедрить graph runtime-компоненты в retrieval/planning/problem assembly/lifecycle binding;
+- интегрировать graph-связность в reasoning и answer synthesis;
 - подтвердить полезность через domain-eval и before/after проверку;
-- не превращать текущий этап в скрытую реализацию Stage 4–6.
+- не превращать текущий этап в скрытую реализацию Stage 5–6.
 
 ---
 
@@ -68,7 +68,7 @@ Codex должен помочь реализовать **только Stage 3**,
 При чтении и интерпретации материалов использовать следующий порядок приоритета.
 
 ### 1. Текущий рабочий scope
-- `03_execution/STAGE_03_TASK_CARD.md`
+- `03_execution/STAGE_04_TASK_CARD.md`
 
 Это главный документ по тому, что делать прямо сейчас.
 
@@ -84,15 +84,16 @@ Codex должен помочь реализовать **только Stage 3**,
 - security;
 - live bridge policy.
 
-### 3. Детальное ТЗ третьего этапа
+### 3. Детальное ТЗ четвёртого этапа
+- `02_stages/TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md`
+
+Этот документ определяет содержимое Stage 4.
+
+### 4. Зависимости Stage 4
 - `02_stages/TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md`
-
-Этот документ определяет содержимое Stage 3.
-
-### 4. Зависимости Stage 3
 - `02_stages/TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md`
 
-Stage 3 опирается на problem-centric слой Stage 2 и не должен его ломать.
+Stage 4 опирается на problem-centric слой Stage 2 и lifecycle слой Stage 3 и не должен их ломать.
 
 ### 5. Текущий статус и общая логика развития
 - `00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`
@@ -103,11 +104,10 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 Эти документы нужны для понимания:
 - что уже сделано;
 - где реальные потолки системы;
-- почему сейчас выполняется Stage 3;
-- как Stage 3 стыкуется с дальнейшими этапами.
+- почему сейчас выполняется Stage 4;
+- как Stage 4 стыкуется с дальнейшими этапами.
 
-### 6. Этапы 4–6
-- `02_stages/TZ_Stage_4_...`
+### 6. Этапы 5–6
 - `02_stages/TZ_Stage_5_...`
 - `02_stages/TZ_Stage_6_...`
 
@@ -122,18 +122,17 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 ## Scope текущей итерации
 
-Разрешено делать только то, что относится к Stage 3 и необходимо для его корректной реализации.
+Разрешено делать только то, что относится к Stage 4 и необходимо для его корректной реализации.
 
 К текущему scope относятся:
 
-- формализация lifecycle-доменов и lifecycle-сущностей Stage 3;
-- описание states/transitions/defects с привязкой к доступным evidence;
-- реализация runtime-слоя (`LifecycleRegistry`, `LifecycleResolver`, `LifecycleDefectClassifier`, `LifecycleEnricher`);
-- обновление `problem_unit_schema` lifecycle-полями;
-- интеграция lifecycle-факторов в ranking policy;
-- интеграция lifecycle-логики в answer policy;
-- lifecycle-aware тесты и benchmark контур по ключевым доменам;
-- before/after eval отчёт по продуктовой ценности Stage 3.
+- формализация graph-ядра (`AccountingGraphNode`, `AccountingGraphEdge`, typed relations);
+- реализация runtime-слоя (`GraphSchemaRegistry`, `GraphBuilder`, `GraphTraversalPolicy`, `GraphValidationLayer`);
+- интеграция graph-сигналов в retrieval planning/execution;
+- интеграция graph connectivity в problem assembly и lifecycle binding;
+- интеграция graph-based объяснений в answer policy;
+- graph-aware тесты и benchmark контур по ключевым доменам;
+- before/after eval отчёт по продуктовой ценности Stage 4.
 
 ---
 
@@ -141,12 +140,13 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 На этой итерации нельзя фактически реализовывать как core-runtime следующие слои:
 
-- полноразмерный ontology / graph runtime из Stage 4;
 - полноценный investigation orchestrator из Stage 5;
 - live verification runtime core и full product mode split из Stage 6;
+- полноразмерный enterprise-wide graph beyond accounting core Stage 4;
 - переезд на новую полную сервисную архитектуру;
 - переписывание ассистента вокруг новых abstraction layers без крайней необходимости;
 - домены, которые не поддерживаются текущими данными/evidence mapping;
+- попытки закрывать graph-gap только prompt-инженерией;
 - большие инфраструктурные переделки ради “красоты”.
 
 ---
@@ -154,20 +154,20 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 ## Главный принцип текущей работы
 
 **Не строить целевую систему раньше времени.**  
-Нужно сделать Stage 3 так, чтобы lifecycle-модели были не формальными таблицами, а реально работающим runtime-слоем и базой для следующих этапов.
+Нужно сделать Stage 4 так, чтобы graph-модели были не формальными схемами, а реально работающим runtime-слоем и базой для следующих этапов.
 
 ---
 
 ## Жёсткие архитектурные ограничения
 
 ### 1. Нельзя ломать текущий рабочий контур без прямой причины
-Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 3.
+Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 4.
 
 ### 2. Нельзя подменять архитектурные изменения промптами
-Проблемы lifecycle-state, transition logic, defect classification, ranking integration и answer grounding не должны решаться только промптами или “умной формулировкой ответа”.
+Проблемы graph connectivity, relation semantics, traversal logic, problem assembly integration и answer grounding не должны решаться только промптами или “умной формулировкой ответа”.
 
-### 3. Нельзя преждевременно тащить Stage 4–6 в кодовую базу
-Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 3.
+### 3. Нельзя преждевременно тащить Stage 5–6 в кодовую базу
+Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 4.
 
 ### 4. Нельзя делать большие рефакторы ради абстрактной чистоты
 Разрешены только те изменения, которые:
@@ -175,15 +175,15 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 - повышают устойчивость текущего слоя;
 - не разрушают траекторию дальнейшего развития.
 
-### 5. Каждый lifecycle-элемент обязан иметь полный контур реализации
-Для каждого lifecycle-элемента должны существовать:
+### 5. Каждый graph-элемент обязан иметь полный контур реализации
+Для каждого graph-элемента должны существовать:
 - spec-level описание;
 - runtime-level вычисление;
 - retrieval/ranking-level использование;
 - answer-level интерпретация.
 
-### 6. Нельзя вводить состояния и дефекты без evidence mapping
-Если состояние/переход/дефект нельзя определить по реально доступным данным, его нельзя вводить как runtime-элемент Stage 3.
+### 6. Нельзя вводить узлы/связи без provenance и evidence mapping
+Если node/edge нельзя определить по реально доступным данным и привязать к источнику, его нельзя вводить как runtime-элемент Stage 4.
 
 ---
 
@@ -195,14 +195,14 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 Сначала изучить:
 - текущий статус;
 - platform core ТЗ;
-- Stage 3;
-- зависимость от Stage 2;
+- Stage 4;
+- зависимости от Stage 3 и Stage 2;
 - roadmap;
 - контекст следующих этапов.
 
 ### Шаг B. Анализ текущего кода
 До внесения изменений определить:
-- какие части lifecycle already/partially реализованы;
+- какие части graph/lifecycle/problem layers already/partially реализованы;
 - где находятся реальные точки расширения;
 - какие элементы являются хрупкими;
 - какие изменения потребуют новых contracts;
@@ -221,7 +221,7 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 Только после плана переходить к реализации.
 
 Изменения должны вноситься малыми порциями, чтобы можно было проверить:
-- не вышел ли scope за Stage 3;
+- не вышел ли scope за Stage 4;
 - не сломан ли текущий контур;
 - не появились ли premature abstractions.
 
@@ -233,6 +233,61 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 - список ограничений;
 - список нерешённых вопросов;
 - оценку совместимости с дальнейшими этапами.
+- ссылку на run-папку в `llm_normalizer/docs/runs` с артефактами по стандарту структуры волны.
+
+---
+
+## Стандарт структуры run-артефактов (обязательный)
+
+Для каждой волны тестов и приёмки нужно создавать отдельную run-папку в:
+
+- `llm_normalizer/docs/runs`
+
+### 1. Обязательный формат имени run-папки
+
+Имя папки должно быть в формате:
+
+- `YYYY-MM-DD_Stage_<NN>_Wave_<NN>_<short_topic>`
+
+Где:
+- после даты обязательно идёт `Stage`;
+- после `Stage` обязательно идёт `Wave`;
+- только потом добавляется краткая тема прогона.
+
+Пример:
+- `2026-03-26_Stage_03_Wave_03_Lifecycle_Prompts`
+
+### 2. Обязательный состав артефактов run-папки
+
+В каждой run-папке должны быть минимум:
+
+- `README.md` (контекст волны и что проверяли);
+- `run_summary.json` (команды, результаты, ссылки на артефакты);
+- артефакты тестов/прогонов (eval, acceptance, regression и т.д.);
+- отдельная папка `prompt_dialogs`.
+
+### 3. Обязательная папка диалогов `prompt_dialogs`
+
+Папка `prompt_dialogs` должна содержать данные диалога в формате "вопрос пользователя -> ответ системы" и runtime-контекст:
+
+- `prompt_dialogs/index.json` (индекс всех кейсов и файлов);
+
+По каждому кейсу:
+
+- `prompt_dialogs/<suite>/<case_id>.json` (сырой JSON диалога, debug/runtime поля, decomposition/grounding если доступны);
+- `prompt_dialogs/<suite>/<case_id>.md` (быстро читаемая версия user/system/assistant).
+
+Эти файлы обязательны для разборов wave-результатов, чтобы быстро видеть:
+
+- что именно спросил пользователь;
+- что вернула система;
+- что было декомпозировано и на чём основан ответ;
+- что отсутствует или отфильтровано в pipeline.
+
+### 4. Запрет на смешивание волн
+
+Нельзя складывать артефакты разных волн в одну и ту же run-папку.  
+Каждая волна должна иметь собственную папку и собственный набор `prompt_dialogs`.
 
 ---
 
@@ -243,20 +298,20 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 ### 1. Summary текущего состояния
 Краткое описание того, как текущая реализация устроена по коду.
 
-### 2. Gap analysis относительно Stage 3
-Перечень того, чего не хватает для соответствия Stage 3.
+### 2. Gap analysis относительно Stage 4
+Перечень того, чего не хватает для соответствия Stage 4.
 
 ### 3. Предлагаемый file-level plan
 Какие файлы нужно менять, создавать или расширять.
 
 ### 4. Предлагаемые contracts / types / schemas
-Какие lifecycle-сущности и интерфейсы появятся.
+Какие graph/lifecycle/problem-сущности и интерфейсы появятся.
 
 ### 5. Test plan
 Какие тесты будут добавлены или обновлены.
 
 ### 6. Acceptance mapping
-Какие критерии Stage 3 покрываются какими изменениями.
+Какие критерии Stage 4 покрываются какими изменениями.
 
 ### 7. Explicit non-scope
 Что сознательно не будет делаться сейчас.
@@ -272,7 +327,7 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 1. Что было проанализировано  
 2. Что обнаружено  
 3. Что предлагается изменить  
-4. Почему это соответствует Stage 3  
+4. Почему это соответствует Stage 4  
 5. Что не входит в текущий scope  
 6. Какие файлы затрагиваются  
 7. Какие риски есть  
@@ -295,8 +350,8 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 ### 2. Явные contracts
 Всё, что касается:
-- lifecycle states/transitions/defects;
-- lifecycle resolution;
+- graph nodes/edges/relation semantics;
+- graph traversal/resolution;
 - enrichment contracts;
 - ranking factors;
 - answer interpretation;
@@ -306,11 +361,11 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 ### 3. Контролируемая расширяемость
 Расширяемость допустима, но только в той мере, в которой она:
-- реально нужна Stage 3;
+- реально нужна Stage 4;
 - не заставляет внедрять всю будущую архитектуру заранее.
 
 ### 4. Наблюдаемость изменений
-Если добавляется новая lifecycle-логика, нужно продумать:
+Если добавляется новая graph-логика, нужно продумать:
 - как она тестируется;
 - как она логируется;
 - как проверяется её корректность;
@@ -329,10 +384,10 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 Следующие действия считаются ошибочными:
 
-- “красивые lifecycle-таблицы” без рабочего resolver;
-- lifecycle-поля в логах без влияния на ranking/answer;
-- ответы вида “broken_lifecycle” без state/transition логики;
-- скрытая реализация Stage 4–6 под видом Stage 3;
+- “красивая ontology-схема” без рабочего graph runtime;
+- graph-поля в payload без влияния на retrieval/problem assembly/answer;
+- формальный builder без typed traversal и causal value;
+- скрытая реализация Stage 5–6 под видом Stage 4;
 - создание новых абстракций без runtime-пользы;
 - переписывание рабочего контура ради абстрактной чистоты;
 - неявное изменение scope;
@@ -344,12 +399,12 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 Если в процессе работы появляется одно или несколько из следующих явлений, нужно остановиться и пересобрать plan:
 
-- предлагается graph runtime как обязательный путь Stage 3;
+- graph-модель проектируется без runtime-использования в retrieval/problem assembly/lifecycle;
 - предлагается full investigation orchestration для “удобства”;
-- lifecycle-модели проектируются без data/evidence mapping;
-- ranking и answer не получают lifecycle-интеграцию;
-- для Stage 3 предлагается большой platform refactor;
-- формируется новый data model слой без связи с acceptance criteria Stage 3.
+- relation semantics задаются без provenance/evidence mapping;
+- answer слой не получает graph-based объяснения;
+- для Stage 4 предлагается большой platform refactor;
+- формируется новый data model слой без связи с acceptance criteria Stage 4.
 
 ---
 
@@ -357,13 +412,14 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 Текущая волна считается завершённой только если выполнены одновременно все условия:
 
-1. Реализован scope Stage 3, а не произвольный “улучшенный вариант”.
+1. Реализован scope Stage 4, а не произвольный “улучшенный вариант”.
 2. Текущий рабочий контур не разрушен.
-3. Новые lifecycle contracts описаны явно.
+3. Новые graph contracts описаны явно.
 4. Есть тесты и/или проверяемые критерии для внесённых изменений.
-5. Нет скрытого уезда в Stage 4–6.
+5. Нет скрытого уезда в Stage 5–6.
 6. Изменения совместимы с platform core ТЗ.
 7. Зафиксировано, что сознательно осталось за пределами текущего этапа.
+8. Run-артефакты оформлены по стандарту `дата -> Stage -> Wave` и включают обязательную папку `prompt_dialogs`.
 
 ---
 
@@ -371,10 +427,10 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 Текущая итерация должна дать следующий результат:
 
-- lifecycle-aware problem reasoning вместо generic lifecycle labels;
-- stage/transition-aware ranking на covered-доменах;
-- более прикладные ответы по сценариям 51/60, 97, ОС, НДС и period close;
-- рабочий lifecycle runtime-контур, пригодный для дальнейшего развития.
+- graph-backed causal reasoning вместо локальных эвристических связок;
+- typed edge traversal в сценариях cross-branch и period-impact;
+- более прикладные ответы с явным путём проблемы по связям;
+- рабочий graph runtime-контур, пригодный для Stage 5 investigation engine.
 
 ---
 
@@ -394,6 +450,6 @@ Stage 3 опирается на problem-centric слой Stage 2 и не дол
 
 Главный вопрос перед любым изменением:
 
-**Это действительно необходимо для Stage 3, или это попытка преждевременно реализовать Stage 4–6?**
+**Это действительно необходимо для Stage 4, или это попытка преждевременно реализовать Stage 5–6?**
 
 Если ответ неочевиден, изменение откладывается и выносится на отдельное согласование.

docs/accounting-assistant/accounting-assistant/03_execution/STAGE_03_CLOSEOUT_2026-03-26.md

@@ -0,0 +1,58 @@
+# STAGE_03_CLOSEOUT_2026-03-26
+
+## Статус
+
+- Этап: Stage 3 / Lifecycle Formalization
+- Решение: `Accepted / Closed`
+- Дата фиксации: 2026-03-26
+
+---
+
+## Что подтверждено
+
+1. `03_S3-97-STALLED-NODES` выведен из `out_of_scope` в `in_scope`.
+2. Схлопывание доменов в `bank_settlement` устранено.
+3. Synthetic placeholders удалены из user-facing `assistant_reply`.
+4. Stage 2 regression и Stage 3 probe разделение сохранено.
+5. Mojibake cleanup в user-facing layer завершён и подтверждён на всех 9 Stage 3 lifecycle probe кейсах.
+
+---
+
+## Финальные артефакты Stage 3
+
+- Основной финальный run:
+  - `llm_normalizer/docs/runs/2026-03-26_Stage_3_Wave_6_Mojibake_Final_MicroPatch`
+
+- В run-папке присутствует `prompt_dialogs/stage3_lifecycle_probe`:
+  - `01_S3-51-WRONG-CLOSE-TYPE`
+  - `02_S3-60-PAYMENT-WITHOUT-CLOSURE`
+  - `03_S3-97-STALLED-NODES`
+  - `04_S3-97-EXPECTED-VS-ACTUAL`
+  - `05_S3-OS-BRANCH-DIVERGENCE`
+  - `06_S3-OS-TERMINAL-GAP`
+  - `07_S3-VAT-CROSS-BRANCH-CONFLICT`
+  - `08_S3-VAT-ACTUAL-VS-EXPECTED`
+  - `09_S3-PERIOD-CLOSE-LIFECYCLE-IMPACT`
+
+---
+
+## Техническая валидация на момент закрытия
+
+- `npm test` (backend): PASS
+- `npm run build` (backend): PASS
+
+---
+
+## Что переносится в Stage 4
+
+1. Ввести graph-backed causal layer поверх текущих Stage 2/3 контрактов.
+2. Перевести retrieval/problem/lifecycle reasoning на typed graph connectivity.
+3. Подготовить архитектурную базу под Stage 5 investigation engine без преждевременной реализации Stage 5.
+
+---
+
+## Scope-дисциплина
+
+- Stage 3 закрыт без изменения prompt-set как механизма решения runtime-проблем.
+- Stage 3 завершён без redesign transport/endpoint/base routing.
+- Stage 3 завершён без скрытой реализации Stage 4–6.

docs/accounting-assistant/accounting-assistant/03_execution/STAGE_03_TASK_CARD.md

@@ -12,12 +12,22 @@
 
 ## Статус документа
 
-- Статус: рабочая карта реализации Stage 3
+- Статус: Stage 3 завершён и зафиксирован как accepted (2026-03-26)
 - Язык: русский
 - Режим использования: обязателен к прочтению перед любыми изменениями по Stage 3
 - При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
 - При конфликте по общему режиму работы Codex приоритет имеет `CODEX_MASTER_BRIEF.md`
 
+### Фиксация закрытия Stage 3 (2026-03-26)
+
+- Приёмка Stage 3 подтверждена.
+- Финальный micro-patch по mojibake закрыт.
+- Full test suite после финальной стабилизации: `npm test` = PASS.
+- Финальные run-артефакты Stage 3:
+  - `llm_normalizer/docs/runs/2026-03-26_Stage_3_Wave_6_Mojibake_Final_MicroPatch`
+
+Документ сохраняется как reference-card завершённого этапа и как baseline для Stage 4.
+
 ---
 
 ## Контекст
@@ -191,7 +201,9 @@ Codex должен вернуть не только код, но и набор
    - что сделано;
    - что не сделано сознательно;
    - какие риски остались;
-   - что подготовлено для Stage 4.
+   - что подготовлено для Stage 4;
+   - run-папка в `llm_normalizer/docs/runs` с именем по схеме `YYYY-MM-DD_Stage_<NN>_Wave_<NN>_<short_topic>`;
+   - обязательная папка `prompt_dialogs` с логами диалогов по кейсам (`index.json`, `<case_id>.json`, `<case_id>.md`).
 
 ---
 

docs/accounting-assistant/accounting-assistant/03_execution/STAGE_04_TASK_CARD.md

@@ -0,0 +1,277 @@
+# STAGE_04_TASK_CARD
+
+## Назначение документа
+
+Этот документ фиксирует **рабочий implementation scope четвёртого этапа** для Codex и разработчика.
+Документ не заменяет Stage 4 ТЗ и не заменяет platform core ТЗ.
+Его задача — перевести Stage 4 в практический рабочий контур без расползания в Stage 5–6.
+
+---
+
+## Статус документа
+
+- Статус: рабочая карта реализации Stage 4
+- Язык: русский
+- Режим использования: обязателен к прочтению перед любыми изменениями по Stage 4
+- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
+- При конфликте по общему режиму работы Codex приоритет имеет `CODEX_MASTER_BRIEF.md`
+
+---
+
+## Контекст
+
+- Stage 3 закрыт и принят (2026-03-26).
+- Текущий baseline: lifecycle-aware reasoning работает, Stage 2 regression и Stage 3 probe разделены.
+- Следующий шаг — не расширять prompt-слой, а ввести graph-backed causal layer как основу для дальнейшего investigation режима.
+
+Опорные артефакты закрытия Stage 3:
+- `llm_normalizer/docs/runs/2026-03-26_Stage_3_Wave_6_Mojibake_Final_MicroPatch`
+
+Стартовая run-папка Stage 4 Wave 1:
+- `llm_normalizer/docs/runs/2026-03-26_Stage_04_Wave_01_Kickoff`
+
+---
+
+## Цель Stage 4
+
+Stage 4 должен дать **рабочее graph-ядро бухгалтерской предметной области**, чтобы retrieval, lifecycle и problem assembly опирались на единое причинно-следственное представление.
+
+Практический результат этапа:
+
+- типизированные graph-узлы и связи для ключевых бухгалтерских сущностей;
+- runtime-построение графа с provenance/confidence;
+- graph-aware planning/execution для graph-eligible запросов;
+- graph-backed problem assembly и lifecycle binding;
+- более причинные и проверяемые пользовательские ответы;
+- измеримое улучшение по benchmark/eval.
+
+---
+
+## Scope текущей реализации
+
+### В scope входят
+
+1. **Graph contracts и schema layer**
+   - `AccountingGraphNode`;
+   - `AccountingGraphEdge`;
+   - `GraphSchemaRegistry`;
+   - доменные типы узлов/связей для покрываемых сценариев.
+
+2. **Graph runtime core**
+   - `GraphBuilder`;
+   - `GraphTraversalPolicy`;
+   - `GraphProvenanceLayer`;
+   - `GraphValidationLayer`.
+
+3. **Интеграция в retrieval path**
+   - graph eligibility в planner;
+   - typed traversal в execution для graph-eligible кейсов;
+   - детекция missing/conflicting links как runtime сигналов.
+
+4. **Интеграция в problem/lifecycle layers**
+   - graph-backed problem assembly;
+   - graph-backed lifecycle transition checks;
+   - корректная передача graph evidence в answer layer.
+
+5. **Интеграция в answer layer**
+   - user-facing объяснение по causal path;
+   - явная фиксация отсутствующих/конфликтных связей;
+   - сохранение честных ограничений confidence/coverage.
+
+6. **Quality контур Stage 4**
+   - unit/integration тесты graph core;
+   - regression на Stage 2/Stage 3 маршрутах;
+   - benchmark/eval до/после по graph value сценариям.
+
+---
+
+## Что не входит в scope
+
+### Не делать сейчас
+
+- полноценный Investigation Engine Stage 5;
+- full orchestration case-runtime с глубокой ветвизацией;
+- live verification core path и full mode split Stage 6;
+- глобальный enterprise graph beyond accounting core Stage 4;
+- большой рефактор transport/endpoint/base routing;
+- попытки закрыть graph-gap только prompt-изменениями.
+
+---
+
+## Обязательные результаты этапа
+
+### 1. Рабочая graph-модель по целевым доменам
+
+Должны быть внедрены типизированные узлы/связи как минимум для доменов, критичных для текущего набора кейсов:
+
+- 51/60 расчётные цепочки;
+- 97 (расходы будущих периодов);
+- ОС;
+- НДС;
+- period_close.
+
+### 2. Рабочий graph runtime
+
+Должен существовать runtime-контур, который:
+
+- строит graph из нормализованных сущностей;
+- хранит provenance/confidence;
+- поддерживает typed traversal;
+- выявляет missing/conflicting edges.
+
+### 3. Graph-backed retrieval и problem assembly
+
+- graph-eligible queries реально используют traversal;
+- problem units используют graph connectivity, а не только proximity/heuristics.
+
+### 4. Graph-backed lifecycle binding
+
+- lifecycle transition checks используют graph relations;
+- missing/invalid transitions имеют graph-опору.
+
+### 5. Улучшение user-facing объяснений
+
+- ответы показывают причинный путь проблемы;
+- видны узлы/связи разрыва;
+- сохраняется прозрачность uncertainty.
+
+### 6. Измеримость ценности
+
+- есть benchmark suite;
+- есть before/after evidence;
+- есть отчёт, где именно graph layer даёт прирост качества.
+
+---
+
+## Ожидаемые сущности Stage 4
+
+Минимальный набор сущностей/компонентов:
+
+1. `AccountingGraphNode`
+2. `AccountingGraphEdge`
+3. `GraphSchemaRegistry`
+4. `GraphBuilder`
+5. `GraphTraversalPolicy`
+6. `GraphProvenanceLayer`
+7. `GraphValidationLayer`
+8. `GraphBackedProblemAssembly`
+9. `GraphBackedLifecycleBinding`
+
+---
+
+## Жёсткие implementation-ограничения
+
+### 1. Не ломать рабочий контур
+
+Без прямой необходимости не переписывать:
+- transport;
+- endpoint;
+- base routing;
+- normalizer pipeline.
+
+### 2. Graph только с runtime-value
+
+Graph считается внедрённым только если влияет на:
+- retrieval execution;
+- problem assembly;
+- lifecycle reasoning;
+- user-facing explanation.
+
+### 3. Никаких бездоказательных узлов/связей
+
+Нельзя добавлять node/edge, если нет:
+- источника данных;
+- evidence mapping;
+- provenance trace.
+
+### 4. Stage 5/6 не реализовывать внутри Stage 4
+
+Любая попытка внедрить full investigation orchestration или live verification core отклоняется как non-scope.
+
+---
+
+## Порядок работы по Stage 4
+
+### Шаг 1. Прочитать материалы
+
+Обязательно прочитать:
+- `CODEX_MASTER_BRIEF.md`
+- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
+- `TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md`
+- `TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md`
+- `TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md`
+
+### Шаг 2. Сделать code-level mapping
+
+Нужно определить:
+- где безопасно встраивать graph builder;
+- где planner/execution могут включать graph traversal;
+- где problem/lifecycle layers принимают graph evidence;
+- где answer layer получает causal path.
+
+### Шаг 3. План без кода
+
+До начала реализации Codex обязан вернуть:
+- gap analysis;
+- file-level plan;
+- contracts/types plan;
+- test/eval plan;
+- explicit non-scope.
+
+### Шаг 4. Реализация малыми волнами
+
+Рекомендуемая последовательность:
+
+- Волна 1: graph schema + registry;
+- Волна 2: graph builder + provenance;
+- Волна 3: retrieval planner/execution graph integration;
+- Волна 4: problem/lifecycle graph binding;
+- Волна 5: answer integration;
+- Волна 6: benchmark/eval + hardening.
+
+---
+
+## Acceptance criteria (кратко)
+
+Stage 4 считается закрытым только если одновременно:
+
+1. Graph contracts реализованы и используются runtime.
+2. Graph traversal реально участвует в graph-eligible запросах.
+3. Problem assembly использует graph connectivity.
+4. Lifecycle checks используют graph transitions.
+5. User-facing ответы отражают causal graph path.
+6. Есть before/after подтверждение улучшения.
+7. Нет скрытого выезда в Stage 5–6.
+8. Run-артефакты оформлены по стандарту `date -> Stage -> Wave`, включая `prompt_dialogs`.
+
+---
+
+## Что Codex обязан явно указать в конце работы
+
+1. Что сделано
+2. Какие файлы изменены
+3. Какие graph-сущности и компоненты введены
+4. Какие тесты добавлены
+5. Какие acceptance criteria закрыты
+6. Что сознательно НЕ реализовано
+7. Какие риски и ограничения остались
+8. Что подготовлено для Stage 5
+
+---
+
+## Definition of Done
+
+Stage 4 завершён, если одновременно:
+
+- graph-ядро работает в runtime, а не только в документации;
+- retrieval/problem/lifecycle/answer слои используют graph signals;
+- ответы становятся причинно связными и проверяемыми;
+- есть измеримая прибавка по benchmark/eval;
+- рабочий контур не разрушен;
+- нет premature implementation Stage 5–6.
+
+---
+
+## Короткая практическая формула этапа
+
+**Stage 4 = переход от lifecycle-aware reasoning к graph-backed accounting causality.**