Этап 4 / Волна 10: корректировка settlement-кейса — доменная фиксация синтеза, честное покрытие, удержание фокуса / Этап 4 / Волна 11: бизнес-якоря, доменное заземление и устранение утечки дебага
This commit is contained in:
+63
-169
@@ -1,272 +1,166 @@
|
||||
# ACCEPTANCE_CHECKLIST_STAGE_04
|
||||
|
||||
## Назначение документа
|
||||
## Назначение
|
||||
|
||||
Этот документ используется для приёмки реализации Stage 4.
|
||||
Его задача — проверить, что graph core внедрён как рабочий runtime-слой, а не как формальная схема.
|
||||
Чеклист используется для приемки Stage 4 в текущей фазе (Wave 9):
|
||||
**P0 baseline hardening и формальная измеримость качества**.
|
||||
|
||||
Документ обязателен для:
|
||||
- Codex;
|
||||
- разработчика;
|
||||
- ручного review;
|
||||
- финальной фиксации Stage 4.
|
||||
## Статус
|
||||
|
||||
---
|
||||
- Дата актуализации: 2026-03-27
|
||||
- Применимость: Waves 5-9 и финальная фиксация P0 baseline
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: чеклист приёмки 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` (только с явным обоснованием)
|
||||
|
||||
- `PASS` — выполнено полностью
|
||||
- `PARTIAL` — выполнено частично, требуется доработка
|
||||
- `FAIL` — не выполнено
|
||||
- `N/A` — не применимо (только с явным обоснованием)
|
||||
|
||||
Для каждого пункта обязателен комментарий:
|
||||
- что проверялось;
|
||||
Для каждого пункта фиксируется:
|
||||
- что проверено;
|
||||
- где реализовано;
|
||||
- чем подтверждается;
|
||||
- чем подтверждено (тест/отчет/артефакт);
|
||||
- какие ограничения остались.
|
||||
|
||||
---
|
||||
## Блок A. Scope discipline
|
||||
|
||||
## Общая логика приёмки
|
||||
|
||||
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
|
||||
### A1. Stage 4 удержан в P0-only контуре
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## A2. Нет скрытого выезда в Stage 5
|
||||
### A2. Нет расширения доменов за пределы 3 P0
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## A3. Нет скрытого выезда в Stage 6
|
||||
### A3. Нет скрытого выезда в Stage 5 investigation
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## A4. Нет большого ненужного platform refactor
|
||||
### A4. Нет скрытого выезда в Stage 6 live verification
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
|
||||
# Блок B. Graph model
|
||||
|
||||
## B1. Реализована schema `AccountingGraphNode`
|
||||
### A5. Нет большого runtime/transport refactor
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## B2. Реализована schema `AccountingGraphEdge`
|
||||
## Блок B. Wave 5-8 baseline integrity
|
||||
|
||||
### B1. Route correctness удержан на gate-уровне
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## B3. Внедрён `GraphSchemaRegistry`
|
||||
### B2. Domain purity удержан на gate-уровне
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## B4. Узлы/связи имеют provenance/confidence
|
||||
### B3. Problem-first answer contract сохранен
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## B5. Нет generic edges уровня `related_to` как основного механизма
|
||||
### B4. Internal leakage guard сохранен
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
## Блок C. Wave 9 quality hardening
|
||||
|
||||
# Блок C. Graph runtime
|
||||
|
||||
## C1. Реализован `GraphBuilder`
|
||||
### C1. P0 baseline snapshot зафиксирован явно
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## C2. Реализован `GraphTraversalPolicy`
|
||||
### C2. Eval corpus расширен относительно Wave 8
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## C3. Реализован `GraphValidationLayer`
|
||||
### C3. В corpus покрыты noisy/translit/multi-intent классы
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## C4. Missing/conflicting links детектируются как runtime-сигналы
|
||||
### C4. В corpus покрыты follow-up continuity кейсы
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## C5. Runtime устойчив к неполным данным
|
||||
### C5. Decomposition/alias regression coverage расширен
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
## Блок D. Формальные метрики
|
||||
|
||||
# Блок D. Интеграция слоёв
|
||||
|
||||
## D1. Planner поддерживает graph eligibility
|
||||
### D1. Автоматически считается `generic_explanation_rate`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## D2. Execution использует typed graph traversal в graph-eligible запросах
|
||||
### D2. Автоматически считается `false_confidence_rate`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## D3. Problem assembly использует graph connectivity
|
||||
### D3. Автоматически считается `mechanism_specificity_score`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## D4. Lifecycle checks используют graph transitions
|
||||
### D4. Автоматически считается `followup_context_retention_score`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## D5. Answer layer использует graph-backed causal path
|
||||
### D5. Есть before/after сравнение относительно Wave 8 baseline
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
## Блок E. Формальный verdict Wave 9
|
||||
|
||||
# Блок E. Quality / eval
|
||||
|
||||
## E1. Добавлены unit tests для graph contracts/runtime
|
||||
### E1. Вердикт сформирован через formal gate
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## E2. Добавлены integration tests для planner/execution graph path
|
||||
### E2. Допустимый verdict:
|
||||
- `P0_BASELINE_STABLE`
|
||||
- или `P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## E3. Regression по Stage 2/Stage 3 не сломан
|
||||
## Блок F. Документация и run-артефакты
|
||||
|
||||
### F1. `STAGE_04_TASK_CARD.md` синхронизирован
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## E4. Есть benchmark suite Stage 4
|
||||
### F2. `ARCHITECTURE_GUARDRAILS.md` синхронизирован
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
## E5. Есть before/after value report
|
||||
### F3. Run-артефакты оформлены полностью
|
||||
Обязательный минимум:
|
||||
- `README.md`
|
||||
- `run_summary.json`
|
||||
- `prompt_dialogs/`
|
||||
- updated benchmark reports
|
||||
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
## Итоговая сводка
|
||||
|
||||
# Блок 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:
|
||||
- Связанные документы:
|
||||
- Версия/ветка/commit:
|
||||
- Связанные run-артефакты:
|
||||
|
||||
## Ключевые сильные стороны
|
||||
## Ключевые наблюдения
|
||||
|
||||
Сильные стороны:
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Ключевые недочёты
|
||||
Открытые ограничения:
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Что обязательно исправить до приёмки
|
||||
Обязательные follow-up шаги (если есть):
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Что допустимо перенести в следующий этап
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Явно подтверждено как non-scope текущего этапа
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Финальное решение
|
||||
- `Принять Stage 4`
|
||||
- `Принять Stage 4 условно`
|
||||
- `Вернуть на доработку`
|
||||
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
|
||||
## Короткая практическая формула
|
||||
|
||||
Stage 4 считается успешным тогда, когда graph layer реально работает в runtime и улучшает retrieval/problem/lifecycle/answer, а не только добавляет новую схему данных.
|
||||
|
||||
+51
-514
@@ -1,533 +1,70 @@
|
||||
ARCHITECTURE_GUARDRAILS.md
|
||||
# ARCHITECTURE_GUARDRAILS
|
||||
|
||||
# ARCHITECTURE_GUARDRAILS
|
||||
## Назначение
|
||||
|
||||
## Назначение документа
|
||||
Этот документ фиксирует архитектурные ограничения для Stage 4 в текущем состоянии (Waves 5-9):
|
||||
**P0-only baseline + quality hardening**, без расширения runtime scope.
|
||||
|
||||
Этот документ фиксирует **жёсткие архитектурные рамки** для работы Codex и разработчика по бухгалтерскому ассистенту.
|
||||
## Актуальный статус (2026-03-27)
|
||||
|
||||
Документ нужен, чтобы:
|
||||
- Stage 4 baseline после Wave 8: `P0_ACCEPTED_WITH_LIMITATIONS`
|
||||
- Текущая волна: Wave 9 (quality/process)
|
||||
- Scope freeze: 3 P0 домена, без добавления новых доменов и без broad refactor
|
||||
|
||||
- не допустить расползания scope;
|
||||
- не дать текущей реализации преждевременно превратиться в Stage 4–6;
|
||||
- не допустить появления скрытых костылей под видом “улучшения архитектуры”;
|
||||
- удержать изменения в рамках текущего этапа;
|
||||
- сохранить совместимость с будущим развитием системы.
|
||||
## Жесткая рамка Stage 4 (текущая)
|
||||
|
||||
Документ не заменяет:
|
||||
- `CODEX_MASTER_BRIEF.md`
|
||||
- `STAGE_03_TASK_CARD.md`
|
||||
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- этапные ТЗ
|
||||
Разрешено только то, что:
|
||||
1. укрепляет качество на существующем P0 контуре;
|
||||
2. измеряется через eval harness и formal gates;
|
||||
3. не меняет архитектурный контур runtime-routing/retrieval вширь.
|
||||
|
||||
Его задача — фиксировать **что можно**, **что нельзя** и **по каким признакам видно, что реализация пошла не туда**.
|
||||
## Что обязательно сохранять неизменным
|
||||
|
||||
---
|
||||
- P0 domain runtime scope:
|
||||
- `settlements_60_62`
|
||||
- `vat_document_register_book`
|
||||
- `month_close_costs_20_44`
|
||||
- базовый transport/endpoints
|
||||
- общий route/runtime контур, кроме минимальных корректировок, необходимых для корректных измерений
|
||||
|
||||
## Статус документа
|
||||
## Допустимые изменения в Wave 9
|
||||
|
||||
- Статус: обязательный архитектурный ограничитель
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к применению до любых кодовых изменений
|
||||
- При конфликте с текущим scope приоритет имеет `STAGE_03_TASK_CARD.md`
|
||||
- При конфликте по платформенным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- eval corpus expansion
|
||||
- metric layer hardening
|
||||
- decomposition/alias regression coverage
|
||||
- follow-up/context retention regression coverage
|
||||
- docs sync для execution контуров
|
||||
|
||||
---
|
||||
## Недопустимые изменения в Wave 9
|
||||
|
||||
## Базовая установка
|
||||
- новые P0/P1 домены
|
||||
- graph/schema expansion
|
||||
- Stage 5 investigation orchestration
|
||||
- Stage 6 live verification integration
|
||||
- новые runtime-маршруты
|
||||
- крупные рефакторы `assistantDataLayer` / `routeHintAdapter` / transport
|
||||
- переписывание lifecycle слоя
|
||||
|
||||
Текущая задача — **не построить конечную архитектуру**, а **усилить существующую систему так, чтобы она стала устойчивой основой для следующих этапов**.
|
||||
## Признаки нарушения guardrails
|
||||
|
||||
Следовательно:
|
||||
Нарушением считаются:
|
||||
- попытка "улучшить" систему через расширение доменов вместо улучшения качества на P0
|
||||
- смешивание quality-wave с feature-wave
|
||||
- изменения runtime, не требуемые для измеримости quality-gap метрик
|
||||
- отсутствие формального before/after отчета при заявленном улучшении
|
||||
|
||||
- нельзя преждевременно тащить в код будущие слои;
|
||||
- нельзя переписывать рабочий контур ради абстрактной чистоты;
|
||||
- нельзя маскировать structural gaps косметикой;
|
||||
- нельзя заменять архитектуру “умным” поведением промптов.
|
||||
## Обязательные quality-сигналы Wave 9
|
||||
|
||||
---
|
||||
В harness должны автоматически считаться:
|
||||
- `generic_explanation_rate`
|
||||
- `false_confidence_rate`
|
||||
- `mechanism_specificity_score`
|
||||
- `followup_context_retention_score`
|
||||
|
||||
## Главный принцип
|
||||
## Формальный выход Stage 4 / Wave 9
|
||||
|
||||
**Каждое изменение должно отвечать на вопрос:**
|
||||
Допустимые итоговые verdict:
|
||||
- `P0_BASELINE_STABLE`
|
||||
- `P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS`
|
||||
|
||||
> Это действительно необходимо для текущего этапа, или это попытка заранее реализовать следующий уровень системы?
|
||||
|
||||
Если ответ неочевиден, изменение считается подозрительным и должно быть вынесено на отдельное согласование.
|
||||
|
||||
---
|
||||
|
||||
## Архитектурная позиция проекта
|
||||
|
||||
Развитие системы должно идти поэтапно.
|
||||
|
||||
### Текущая логика развития
|
||||
1. Усиление foundation
|
||||
2. Сдвиг retrieval units
|
||||
3. Формализация lifecycle
|
||||
4. Формирование graph core
|
||||
5. Построение investigation engine
|
||||
6. Live verification и product modes
|
||||
|
||||
Из этого следует:
|
||||
|
||||
- текущий этап не должен содержать скрытую реализацию graph runtime;
|
||||
- текущий этап не должен содержать полноценный investigation engine;
|
||||
- текущий этап не должен содержать полноценный mode router;
|
||||
- текущий этап не должен содержать live verification core path;
|
||||
- текущий этап не должен содержать premature orchestration architecture.
|
||||
|
||||
---
|
||||
|
||||
## Что считается архитектурно допустимым
|
||||
|
||||
Допустимы только такие изменения, которые одновременно:
|
||||
|
||||
1. закрывают конкретный gap текущего этапа;
|
||||
2. дают прямую runtime-пользу уже сейчас;
|
||||
3. не тянут в код полноразмерные future-stage слои;
|
||||
4. не ломают текущий рабочий контур;
|
||||
5. не создают новый труднообратимый архитектурный долг.
|
||||
|
||||
---
|
||||
|
||||
## Что считается архитектурно недопустимым
|
||||
|
||||
Недопустимы изменения, которые:
|
||||
|
||||
- реализуют будущее раньше, чем для него готов фундамент;
|
||||
- создают тяжёлые абстракции без текущей пользы;
|
||||
- требуют большого переписывания ради “красоты”;
|
||||
- маскируют отсутствие структуры промптами;
|
||||
- подменяют состояние чатом;
|
||||
- подменяют evidence словами;
|
||||
- вводят новые сервисы без необходимости;
|
||||
- создают platform complexity, не нужную текущему шагу.
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие guardrails
|
||||
|
||||
### 1. Не переписывать рабочий контур без прямой причины
|
||||
|
||||
Без крайней необходимости запрещено переписывать:
|
||||
|
||||
- transport layer;
|
||||
- endpoint layer;
|
||||
- base routing;
|
||||
- normalizer pipeline;
|
||||
- текущий путь сборки ответа;
|
||||
- рабочий retrieval flow;
|
||||
- уже действующий assistant loop.
|
||||
|
||||
Разрешены только точечные изменения, если они:
|
||||
- прямо обязательны для Stage 3;
|
||||
- не могут быть внесены более локально.
|
||||
|
||||
---
|
||||
|
||||
### 2. Не строить новую архитектуру вместо усиления текущей
|
||||
|
||||
Нельзя использовать текущий этап как повод для:
|
||||
|
||||
- полного redesign системы;
|
||||
- переезда на другую базовую схему исполнения;
|
||||
- внедрения большого orchestration layer;
|
||||
- скрытого перехода на новую core-модель;
|
||||
- замены существующей структуры на “более правильную” без немедленной пользы.
|
||||
|
||||
---
|
||||
|
||||
### 3. Не внедрять преждевременно Stage 4–6
|
||||
|
||||
До наступления соответствующих этапов запрещено внедрять как core-runtime:
|
||||
|
||||
- полноценный `problem unit architecture`;
|
||||
- полноценный lifecycle engine;
|
||||
- полноразмерный ontology/graph runtime;
|
||||
- full investigation engine;
|
||||
- live verification core;
|
||||
- split product runtime `direct / investigation / audit`;
|
||||
- тяжёлую multi-step orchestration system;
|
||||
- систему ветвления расследований как основной путь выполнения.
|
||||
|
||||
Если требуется часть будущей совместимости, она должна реализовываться:
|
||||
- минимально;
|
||||
- локально;
|
||||
- через совместимые контракты;
|
||||
- без включения всего будущего слоя.
|
||||
|
||||
---
|
||||
|
||||
### 4. Не решать structural gaps только промптами
|
||||
|
||||
Запрещено считать, что следующие проблемы решены, если было сделано только prompt tuning:
|
||||
|
||||
- отсутствие формального state;
|
||||
- слабое evidence-linking;
|
||||
- generic response behavior;
|
||||
- отсутствие boundedness;
|
||||
- отсутствие quality metrics;
|
||||
- неявная uncertainty handling;
|
||||
- отсутствие управляемого narrowing.
|
||||
|
||||
Промпт может помогать, но не может быть единственной формой архитектурного решения.
|
||||
|
||||
---
|
||||
|
||||
### 5. Не подменять state историей чата
|
||||
|
||||
Запрещено считать, что:
|
||||
- chat history,
|
||||
- предыдущий ответ,
|
||||
- контекст последнего сообщения
|
||||
|
||||
эквивалентны формальному state.
|
||||
|
||||
Если системе нужен state, он должен быть:
|
||||
- явным;
|
||||
- минимальным;
|
||||
- ограниченным;
|
||||
- типизированным;
|
||||
- контролируемым.
|
||||
|
||||
---
|
||||
|
||||
### 6. Не подменять evidence текстовой убедительностью
|
||||
|
||||
Запрещено считать, что ответ “обоснован”, если модель просто написала убедительный текст.
|
||||
|
||||
Evidence должно иметь хотя бы минимально явную структуру:
|
||||
- источник;
|
||||
- тип опоры;
|
||||
- связь с утверждением;
|
||||
- механизм/основание;
|
||||
- степень уверенности или ограниченности.
|
||||
|
||||
---
|
||||
|
||||
### 7. Не вводить абстракции “на будущее” без runtime-пользы
|
||||
|
||||
Любая новая абстракция должна быть оправдана текущей пользой.
|
||||
|
||||
Недопустимы:
|
||||
- интерфейсы ради гипотетического расширения;
|
||||
- service layers без прямой функции на текущем этапе;
|
||||
- сложные фабрики/адаптеры/оркестраторы “на потом”;
|
||||
- обобщения, которые пока ничего не упрощают.
|
||||
|
||||
---
|
||||
|
||||
### 8. Не раздувать сервисную архитектуру раньше времени
|
||||
|
||||
Запрещено добавлять отдельные сервисы, если задачу можно решить проще.
|
||||
|
||||
Не нужно сейчас:
|
||||
- выделять отдельные сервисы ради формального микросервисного вида;
|
||||
- дробить систему под будущий scale, которого ещё нет;
|
||||
- вводить сетевое взаимодействие между модулями, где достаточно модульной декомпозиции в кодовой базе;
|
||||
- строить платформенный контур сложнее, чем требует текущий этап.
|
||||
|
||||
---
|
||||
|
||||
### 9. Не вводить storage complexity без ясной причины
|
||||
|
||||
Разрешено вводить новые contracts и storage-слои только если понятно:
|
||||
|
||||
- что является source of truth;
|
||||
- что хранится как runtime state;
|
||||
- что хранится как derived artifacts;
|
||||
- как обеспечивается совместимость;
|
||||
- как это будет использоваться уже сейчас.
|
||||
|
||||
Недопустимо:
|
||||
- размазывать состояние по случайным местам;
|
||||
- хранить критичное состояние в ad hoc формате;
|
||||
- смешивать runtime state, long-term artifacts и временные вспомогательные данные без явной дисциплины.
|
||||
|
||||
---
|
||||
|
||||
### 10. Не считать green tests доказательством качества продукта
|
||||
|
||||
Если изменения прошли технические тесты, это ещё не означает, что этап закрыт.
|
||||
|
||||
Архитектурно недостаточно:
|
||||
- unit tests без проверки полезности ответа;
|
||||
- integration tests без accountant-facing criteria;
|
||||
- успешного пайплайна без оценки качества narrowing/evidence/usefulness.
|
||||
|
||||
---
|
||||
|
||||
## Разрешённые архитектурные паттерны
|
||||
|
||||
Ниже перечислено то, что допустимо и желательно.
|
||||
|
||||
### 1. Минимальный совместимый контракт
|
||||
Если нужен новый слой, сначала вводится:
|
||||
- минимальный тип;
|
||||
- минимальный контракт;
|
||||
- минимальный runtime-путь;
|
||||
- без избыточной генерализации.
|
||||
|
||||
### 2. Локальное усиление точки принятия решения
|
||||
Если есть конкретная слабая зона, допустимо:
|
||||
- локально усилить её;
|
||||
- формализовать решение;
|
||||
- добавить проверку/метрику;
|
||||
- не затрагивать весь контур.
|
||||
|
||||
### 3. Расширение через bounded сущности
|
||||
Новые сущности допустимы, если они:
|
||||
- ограничены по назначению;
|
||||
- не претендуют на роль будущей полноразмерной подсистемы;
|
||||
- не конфликтуют с дальнейшим развитием.
|
||||
|
||||
### 4. Явные интерфейсы вместо неявного поведения
|
||||
Если логика уже существует, но живёт неявно, допустимо:
|
||||
- вывести её в контракт;
|
||||
- типизировать;
|
||||
- сделать наблюдаемой;
|
||||
- покрыть тестами.
|
||||
|
||||
### 5. Наблюдаемость как часть архитектуры
|
||||
Если появляется новая логика, у неё должны быть:
|
||||
- диагностика;
|
||||
- traceability;
|
||||
- метрики;
|
||||
- понятная точка проверки.
|
||||
|
||||
---
|
||||
|
||||
## Decision rules перед любым изменением
|
||||
|
||||
Перед внесением любого изменения нужно проверить следующее.
|
||||
|
||||
### Вопрос 1
|
||||
Это закрывает конкретный gap текущего этапа?
|
||||
|
||||
Если нет — изменение отклоняется.
|
||||
|
||||
### Вопрос 2
|
||||
Это можно сделать локальнее?
|
||||
|
||||
Если да — выбирается более локальный вариант.
|
||||
|
||||
### Вопрос 3
|
||||
Это не тянет Stage 4–6 раньше времени?
|
||||
|
||||
Если тянет — изменение откладывается или упрощается.
|
||||
|
||||
### Вопрос 4
|
||||
Это даёт прямую runtime-пользу уже сейчас?
|
||||
|
||||
Если нет — изменение подозрительно.
|
||||
|
||||
### Вопрос 5
|
||||
Это не создаёт новый трудный долг?
|
||||
|
||||
Если создаёт — нужен другой вариант.
|
||||
|
||||
### Вопрос 6
|
||||
Это не решает проблему только косметикой?
|
||||
|
||||
Если решает только косметикой — изменение недостаточно.
|
||||
|
||||
---
|
||||
|
||||
## Проверка на scope drift
|
||||
|
||||
Признаки того, что реализация вышла за рамки:
|
||||
|
||||
- в код попали сущности, которые фактически образуют graph runtime;
|
||||
- появилась логика сложного branching investigation;
|
||||
- появился mode router для нескольких продуктовых режимов;
|
||||
- появилась зависимость от live verification core;
|
||||
- ради текущего этапа меняется половина репозитория;
|
||||
- вводятся сущности, которые пока никто не использует;
|
||||
- строится общий orchestration framework вместо локального усиления;
|
||||
- Codex объясняет сложность тем, что “так будет лучше на будущее”.
|
||||
|
||||
Если наблюдается один или несколько признаков — нужно остановить изменения и сократить scope.
|
||||
|
||||
---
|
||||
|
||||
## Красные флаги
|
||||
|
||||
Следующие ситуации считаются тревожными:
|
||||
|
||||
1. Предлагается переписать base loop
|
||||
2. Предлагается “сразу сделать правильно всю архитектуру”
|
||||
3. Предлагается отдельный graph layer уже сейчас
|
||||
4. Предлагается большой orchestration framework
|
||||
5. Предлагается product split runtime уже на первом этапе
|
||||
6. State остаётся неявным, но промпт становится длиннее
|
||||
7. Evidence описывается красивее, но не структурируется
|
||||
8. Метрики остаются только техническими
|
||||
9. Добавляются новые сервисы без реальной необходимости
|
||||
10. Временное решение подаётся как target architecture
|
||||
|
||||
---
|
||||
|
||||
## Правило minimal irreversible change
|
||||
|
||||
Любое изменение должно быть по возможности:
|
||||
|
||||
- минимальным;
|
||||
- обратимым;
|
||||
- наблюдаемым;
|
||||
- проверяемым;
|
||||
- совместимым с дальнейшими этапами.
|
||||
|
||||
Нельзя делать решение, которое:
|
||||
- сложно откатить;
|
||||
- сложно объяснить;
|
||||
- сложно протестировать;
|
||||
- сложно встроить в дальнейшую архитектуру;
|
||||
- принято только потому, что “быстрее сейчас”.
|
||||
|
||||
---
|
||||
|
||||
## Правило explicit source of truth
|
||||
|
||||
Для каждой новой сущности должно быть явно определено:
|
||||
|
||||
- где находится источник истины;
|
||||
- кто её обновляет;
|
||||
- кто её читает;
|
||||
- как она версионируется;
|
||||
- что является derived form, а что canonical form.
|
||||
|
||||
Если это не определено, сущность не готова к внедрению.
|
||||
|
||||
---
|
||||
|
||||
## Правило bounded state
|
||||
|
||||
Любой новый state должен быть:
|
||||
|
||||
- ограниченным по объёму;
|
||||
- ограниченным по назначению;
|
||||
- независимым от случайного текстового контекста;
|
||||
- пригодным для диагностики;
|
||||
- пригодным для расширения в будущих этапах.
|
||||
|
||||
Нельзя вводить state, который:
|
||||
- хранит всё подряд;
|
||||
- не имеет чётких полей;
|
||||
- зависит от неявных текстовых интерпретаций;
|
||||
- фактически дублирует chat history;
|
||||
- не имеет правил обновления.
|
||||
|
||||
---
|
||||
|
||||
## Правило honest uncertainty
|
||||
|
||||
Система не должна производить архитектурно ложную определённость.
|
||||
|
||||
Если данных недостаточно, допустимо и желательно:
|
||||
- явно показать ограниченность;
|
||||
- указать, чего не хватает;
|
||||
- предложить следующий полезный шаг;
|
||||
- удержаться от псевдоточного ответа.
|
||||
|
||||
Запрещено:
|
||||
- маскировать отсутствие опоры уверенным тоном;
|
||||
- расширять answer prose вместо усиления основания;
|
||||
- выдавать общую формулировку как точный вывод.
|
||||
|
||||
---
|
||||
|
||||
## Правило compatibility without premature implementation
|
||||
|
||||
Система должна быть совместима с будущими этапами, но не должна их реализовывать заранее.
|
||||
|
||||
Допустимо:
|
||||
- закладывать совместимые поля;
|
||||
- делать совместимые интерфейсы;
|
||||
- избегать тупиковых решений;
|
||||
- оставлять расширяемые точки.
|
||||
|
||||
Недопустимо:
|
||||
- включать полный будущий runtime;
|
||||
- строить будущий слой целиком;
|
||||
- обосновывать сложность только будущими гипотетическими выгодами.
|
||||
|
||||
---
|
||||
|
||||
## Как должен выглядеть хороший change proposal
|
||||
|
||||
Хорошее предложение по изменению должно содержать:
|
||||
|
||||
1. Какой конкретный gap закрывается
|
||||
2. Почему это относится к текущему этапу
|
||||
3. Какой минимальный вариант реализации выбран
|
||||
4. Какие файлы затрагиваются
|
||||
5. Какие сущности добавляются
|
||||
6. Почему это не является скрытой реализацией будущего этапа
|
||||
7. Как это тестируется
|
||||
8. Как это наблюдается
|
||||
9. Что сознательно не делается сейчас
|
||||
|
||||
Если хотя бы половина этих пунктов отсутствует, proposal недостаточно дисциплинирован.
|
||||
|
||||
---
|
||||
|
||||
## Как должен выглядеть плохой change proposal
|
||||
|
||||
Плохим считается предложение, если в нём есть формулировки типа:
|
||||
|
||||
- “сразу сделаем правильно на будущее”
|
||||
- “заодно перепишем”
|
||||
- “проще построить новый слой”
|
||||
- “пусть пока будет так, потом переделаем”
|
||||
- “можно промптом компенсировать”
|
||||
- “сделаем универсальную архитектуру”
|
||||
- “вдруг потом пригодится”
|
||||
- “это подготовка к следующим этапам”
|
||||
|
||||
Без доказанной текущей пользы такие аргументы не принимаются.
|
||||
|
||||
---
|
||||
|
||||
## Эскалация при спорном решении
|
||||
|
||||
Если изменение спорное, применять следующий порядок:
|
||||
|
||||
1. Проверить соответствие текущему scope
|
||||
2. Проверить соответствие platform core ТЗ
|
||||
3. Проверить, не тянет ли изменение Stage 4–6
|
||||
4. Проверить, можно ли сделать локальнее
|
||||
5. Зафиксировать риски
|
||||
6. Только после этого принимать решение
|
||||
|
||||
Если спор остаётся, решение не внедряется автоматически.
|
||||
|
||||
---
|
||||
|
||||
## Короткая практическая формула
|
||||
|
||||
### Что делать
|
||||
- усиливать основание;
|
||||
- формализовать неявное;
|
||||
- добавлять минимально нужные контракты;
|
||||
- повышать наблюдаемость;
|
||||
- сохранять совместимость с будущим.
|
||||
|
||||
### Что не делать
|
||||
- строить будущее раньше времени;
|
||||
- переписывать рабочее;
|
||||
- лечить архитектуру текстом;
|
||||
- плодить абстракции;
|
||||
- усложнять платформу без необходимости.
|
||||
|
||||
---
|
||||
|
||||
## Финальная установка
|
||||
|
||||
Архитектурная дисциплина в этом проекте важнее скорости декоративных изменений.
|
||||
|
||||
Главная цель текущего этапа:
|
||||
|
||||
**не сделать видимость зрелой системы, а реально уменьшить structural debt и подготовить прочную основу для следующих шагов.**
|
||||
|
||||
Любое изменение, которое противоречит этому принципу, должно считаться ошибочным, даже если оно выглядит “умным”, “масштабируемым” или “красивым”.
|
||||
Любой следующий архитектурный шаг обсуждается только после формальной фиксации одного из этих состояний.
|
||||
|
||||
+201
@@ -0,0 +1,201 @@
|
||||
# STAGE_04_REFOCUS_P0_PLAYBOOK_2026-03-27
|
||||
|
||||
## Статус
|
||||
|
||||
- Дата: 2026-03-27
|
||||
- Назначение: зафиксировать перефокус Stage 4 после провалов Wave 4 на реальную продуктовую ценность
|
||||
- Режим: рабочий playbook для ближайших волн (без выхода в Stage 5-6)
|
||||
|
||||
---
|
||||
|
||||
## 1. Что было проанализировано
|
||||
|
||||
1. Контекст и архитектура:
|
||||
- `00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`
|
||||
- `01_platform/TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- `02_stages/TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md`
|
||||
|
||||
2. Execution-документы:
|
||||
- `03_execution/CODEX_MASTER_BRIEF.md`
|
||||
- `03_execution/STAGE_04_TASK_CARD.md`
|
||||
- `03_execution/ACCEPTANCE_CHECKLIST_STAGE_04.md`
|
||||
- `03_execution/ARCHITECTURE_GUARDRAILS.md`
|
||||
|
||||
3. Новые problem-first материалы (Word):
|
||||
- `Карта_острых_бухгалтерских_вопросов_по_следам_форумных_обсуждений.docx`
|
||||
- `Примеры_вопросов_и_схемы_решения_по_четырём_семействам.docx`
|
||||
- `Как_перевести_реальные_форумные_боли_в_язык_ваших_ТЗ_и_собрать_работающий.docx`
|
||||
- `Tz Codex Problem First Accounting Assistant P0.docx`
|
||||
|
||||
4. Фактическое состояние кода:
|
||||
- `llm_normalizer/backend/src/services/{assistantService,routeHintAdapter,assistantDataLayer,retrievalResultNormalizer,problemUnitAssembler,lifecycleRuntime,stage4GraphRuntime,answerComposer}.ts`
|
||||
- `llm_normalizer/backend/src/types/{stage2ProblemUnits,stage4Graph}.ts`
|
||||
- Stage 4 тесты и user-facing тесты
|
||||
|
||||
5. Фактические артефакты Wave 4:
|
||||
- `llm_normalizer/docs/runs/2026-03-26_Stage_04_Wave_04_Graph_Critical_Coverage`
|
||||
|
||||
---
|
||||
|
||||
## 2. Факт по готовности
|
||||
|
||||
### 2.1. Что реально готово
|
||||
|
||||
1. Problem-unit контур (Stage 2 база): есть `candidate_evidence`, `ProblemUnitAssembler`, duplicate collapse, ranking.
|
||||
2. Lifecycle enrichment (Stage 3 база): есть lifecycle enrichment/ranking и интеграция в problem units.
|
||||
3. Graph layer (Stage 4 база): есть `stage4GraphRuntime`, graph binding в `problem_units`, graph summary.
|
||||
4. Graph-aware retrieval в `hybrid_store_plus_live`: есть domain-typed graph traversal сигналы.
|
||||
5. Техническая стабильность: backend `npm.cmd test` и `npm.cmd run build` проходят.
|
||||
|
||||
### 2.2. Что готово только частично (главный блокер пользы)
|
||||
|
||||
1. Domain purity retrieval:
|
||||
- `store_feature_risk` строит риск-выдачу из смешанного источника (`problemCases + ndsRegisters`) без жёсткой доменной изоляции.
|
||||
- Из-за этого возможны ответы не по целевой боли пользователя.
|
||||
|
||||
2. Маршрутизация symptom->causal path:
|
||||
- Есть улучшения в `routeHintAdapter`, но historical Wave 4 показывает, что lifecycle-intent кейсы могли уходить в `store_canonical`.
|
||||
|
||||
3. User-facing контракт:
|
||||
- Ответы остаются перегруженными техническими блоками (структура answer policy и internal labels/англ. маркеры).
|
||||
- Часть кейсов остаётся «entity/tech-heavy», а не «problem-first в бухгалтерском языке».
|
||||
|
||||
4. Процессная дисциплина по run-артефактам:
|
||||
- В Wave 4 отсутствуют обязательные `README.md` и `run_summary.json` в корне run-папки.
|
||||
|
||||
### 2.3. Документные конфликты
|
||||
|
||||
1. `ARCHITECTURE_GUARDRAILS.md` остался в логике Stage 3 (запреты на graph runtime), при этом проект уже в Stage 4.
|
||||
2. `STAGE_04_TASK_CARD.md` фиксирует Wave 2/3, но не отражает Wave 4 и диагностический стоп.
|
||||
|
||||
---
|
||||
|
||||
## 3. Решение по перефокусу
|
||||
|
||||
### Принять как рабочий режим
|
||||
|
||||
`Stage 4 в ближайших волнах = graph-lite + problem-first value`, а не расширение онтологии «вширь».
|
||||
|
||||
### Смысл
|
||||
|
||||
1. Не расширять покрытие доменов сейчас.
|
||||
2. Довести до продуктивного качества ограниченный набор pain-семейств.
|
||||
3. Отвечать в формате «проблема -> механизм -> доказательства -> ограничения -> первый шаг проверки».
|
||||
|
||||
---
|
||||
|
||||
## 4. Рабочий scope P0 внутри Stage 4
|
||||
|
||||
### В приоритете (product-first)
|
||||
|
||||
1. Расчёты/банк 60-62 (разрыв платеж -> закрытие).
|
||||
2. НДС цепочки (документ -> регистр -> книга).
|
||||
3. Закрытие периода/затраты (20/44, зависшие остатки).
|
||||
|
||||
### В режиме regression-only (не расширять сейчас)
|
||||
|
||||
1. РБП/97.
|
||||
2. ОС/амортизация.
|
||||
3. Полный cross-domain depth beyond текущих кейсов.
|
||||
|
||||
---
|
||||
|
||||
## 5. План волн (сразу в работу)
|
||||
|
||||
## Wave 5 — Domain Purity + Route Discipline
|
||||
|
||||
Цель: прекратить смешение доменов и убрать промахи маршрута на symptom-first запросах.
|
||||
|
||||
Изменения:
|
||||
1. `assistantDataLayer.executeRisk`:
|
||||
- ввести domain-gated source selection по `semantic_profile.domain_scope` и `account_scope`.
|
||||
- запретить выдачу нецелевого домена в top-N.
|
||||
|
||||
2. `assistantDataLayer.executeCanonical`:
|
||||
- ограничить canonical выдачу доменным профилем, а не только сортировкой по дате.
|
||||
|
||||
3. `routeHintAdapter`:
|
||||
- закрепить deterministic promotion lifecycle/problem intents в `hybrid_store_plus_live`.
|
||||
|
||||
4. Тесты:
|
||||
- добавить domain-purity regression suite для 3 P0 доменов.
|
||||
|
||||
Acceptance Wave 5:
|
||||
- top-3 результата не содержат чужой домен в P0 кейсах.
|
||||
- lifecycle/symptom цепочки не падают в canonical без явной причины.
|
||||
|
||||
## Wave 6 — Problem-First Answer Contract
|
||||
|
||||
Цель: убрать technical leakage и сделать бухгалтерский actionable ответ.
|
||||
|
||||
Изменения:
|
||||
1. `answerComposer`:
|
||||
- перейти на короткий user-facing формат:
|
||||
- Коротко
|
||||
- Что сломано
|
||||
- Почему (механизм)
|
||||
- Что проверить первым
|
||||
- Ограничения
|
||||
- internal/debug блоки оставлять только в debug payload, не в `assistant_reply`.
|
||||
|
||||
2. Усилить humanization mapping:
|
||||
- запрет raw lifecycle/internal токенов в direct answer.
|
||||
|
||||
3. Добавить hard leakage guards в тестах:
|
||||
- no `graph_*`, `domain_scope`, `relation_patterns`, внутренних кодов состояний в user-facing тексте.
|
||||
|
||||
Acceptance Wave 6:
|
||||
- ответы проходят leakage guard.
|
||||
- дубли problem lines схлопнуты до уникальных.
|
||||
- period limitation явно указан при missing period.
|
||||
|
||||
## Wave 7 — P0 Eval Harness и продуктовая приёмка
|
||||
|
||||
Цель: перестать оценивать по ощущению.
|
||||
|
||||
Изменения:
|
||||
1. Собрать P0 корпус реальных вопросов (минимум 10-15 кейсов на каждый P0 домен).
|
||||
2. Запускать before/after по фиксированному набору.
|
||||
3. Фиксировать метрики:
|
||||
- `problem_first_answer_rate`
|
||||
- `mechanism_coherence_score`
|
||||
- `entity_leakage_rate`
|
||||
- `accountant_actionability_score`
|
||||
|
||||
Acceptance Wave 7:
|
||||
- есть формальный отчёт до/после.
|
||||
- улучшение подтверждено на корпусе, а не на единичных примерах.
|
||||
|
||||
---
|
||||
|
||||
## 6. Что запрещено до закрытия P0
|
||||
|
||||
1. Расширение graph schema «вообще».
|
||||
2. Добавление новых доменов в runtime scope.
|
||||
3. Stage 5 orchestration и Stage 6 live verification как core path.
|
||||
4. Большой refactor transport/endpoint/base routing.
|
||||
|
||||
---
|
||||
|
||||
## 7. Процессные фиксации
|
||||
|
||||
1. Для каждой новой волны в run-папке обязательны:
|
||||
- `README.md`
|
||||
- `run_summary.json`
|
||||
- `prompt_dialogs/`
|
||||
|
||||
2. Обновить execution-документы после стабилизации Wave 5:
|
||||
- синхронизировать `STAGE_04_TASK_CARD.md` с фактическим статусом Wave 4/5.
|
||||
- устранить Stage 3-формулировки из `ARCHITECTURE_GUARDRAILS.md`.
|
||||
|
||||
---
|
||||
|
||||
## 8. Definition of Done перефокуса
|
||||
|
||||
Перефокус считается успешным, когда одновременно:
|
||||
|
||||
1. В P0-доменах top-object ответа = problem unit/механизм, а не entity list.
|
||||
2. User-facing ответ бухгалтерски читаемый и без internal leakage.
|
||||
3. Domain contamination в retrieval устранена.
|
||||
4. Есть измеримый прирост по P0 метрикам на фиксированном корпусе.
|
||||
5. Scope Stage 5-6 не подтянут преждевременно.
|
||||
+82
-273
@@ -2,276 +2,85 @@
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ фиксирует **рабочий 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.**
|
||||
Документ фиксирует **актуальный implementation scope Stage 4** после завершения Waves 5-8 и запуска Wave 9.
|
||||
Он нужен для работы в узком P0-контуре и предотвращения расползания в будущие этапы.
|
||||
|
||||
## Статус
|
||||
|
||||
- Дата актуализации: 2026-03-27
|
||||
- Статус Stage 4: в процессе quality hardening (Wave 9)
|
||||
- Текущий baseline: `P0_ACCEPTED_WITH_LIMITATIONS` (получен в Wave 8)
|
||||
- Рабочий режим: **P0-only**, без расширения runtime/domain scope
|
||||
|
||||
## Фактический контур Stage 4
|
||||
|
||||
Stage 4 в текущем состоянии — это **problem-first контур на 3 P0 доменах**, а не широкий ontology/graph expansion.
|
||||
|
||||
В baseline включены только:
|
||||
- `settlements_60_62` (расчеты/банк 60-62)
|
||||
- `vat_document_register_book` (НДС: документ -> регистр -> книга)
|
||||
- `month_close_costs_20_44` (закрытие периода/затраты 20-44)
|
||||
|
||||
## Хронология Waves 5-9
|
||||
|
||||
- Wave 5: Domain Purity + Route Discipline
|
||||
- закреплены route/domain guardrails в runtime seams
|
||||
- Wave 6: Problem-First Answer Contract
|
||||
- user-facing direct answer очищен от internal leakage
|
||||
- Wave 7: P0 Eval Harness + Formal Product Acceptance
|
||||
- добавлены корпус, метрики, formal gate
|
||||
- Wave 8: Route Correctness Recovery + Domain Purity Closure
|
||||
- закрыты blocking gaps `route_correctness` и `domain_purity`
|
||||
- verdict улучшен до `P0_ACCEPTED_WITH_LIMITATIONS`
|
||||
- Wave 9: P0 Quality Hardening + Corpus Expansion + Docs Sync
|
||||
- расширение eval corpus
|
||||
- автоматизация remaining quality-gap метрик
|
||||
- sync execution документации с фактическим статусом
|
||||
|
||||
## Scope Wave 9
|
||||
|
||||
Разрешено:
|
||||
- развитие eval harness / metric layer
|
||||
- расширение P0 corpus (без новых доменов)
|
||||
- regression coverage для decomposition/noisy/translit/multi-intent/follow-up continuity
|
||||
- минимальные product-facing fixups, необходимые для измерения качества
|
||||
- синхронизация execution docs
|
||||
|
||||
Не разрешено:
|
||||
- новые домены
|
||||
- graph/schema expansion
|
||||
- Stage 5 investigation orchestration
|
||||
- Stage 6 live verification
|
||||
- новые runtime маршруты
|
||||
- большой refactor `assistantDataLayer` / `routeHintAdapter` / transport
|
||||
|
||||
## Acceptance Wave 9
|
||||
|
||||
Wave 9 считается завершенной, если:
|
||||
|
||||
1. зафиксирован P0 baseline state
|
||||
2. corpus расширен относительно Wave 8
|
||||
3. quality-gap метрики считаются автоматически:
|
||||
- `generic_explanation_rate`
|
||||
- `false_confidence_rate`
|
||||
- `mechanism_specificity_score`
|
||||
- `followup_context_retention_score`
|
||||
4. есть before/after report относительно Wave 8 baseline
|
||||
5. execution docs синхронизированы с фактическим Stage 4 status
|
||||
6. run-артефакты оформлены полностью:
|
||||
- `README.md`
|
||||
- `run_summary.json`
|
||||
- `prompt_dialogs/`
|
||||
- updated benchmark reports
|
||||
|
||||
## Run-артефакты (обязательная дисциплина)
|
||||
|
||||
Каждая новая волна Stage 4 обязана иметь run-папку в `llm_normalizer/docs/runs/<date>_Stage_04_Wave_*` с полным комплектом артефактов.
|
||||
|
||||
## Следующий переход после Wave 9
|
||||
|
||||
После Wave 9 допустим только один из двух формальных исходов:
|
||||
- `P0_BASELINE_STABLE`
|
||||
- `P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS`
|
||||
|
||||
Переход к новым архитектурным слоям возможен только после формальной фиксации состояния baseline на Wave 9 корпусе.
|
||||
|
||||
BIN
Binary file not shown.
@@ -0,0 +1,58 @@
|
||||
ВОПРОСЫ 2020 07
|
||||
|
||||
20 вопросов по вашей компании и июльскому снапшоту
|
||||
1. Расчёты / банк / 60–62
|
||||
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
|
||||
Проверяет payment → settlement closure по поставщику.
|
||||
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
|
||||
Это прямой company-specific тест на зачёт аванса покупателя.
|
||||
По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?
|
||||
Хороший тест на 62.01/62.02 и partial settlement.
|
||||
Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?
|
||||
Это вопрос не про сумму, а про механизм.
|
||||
Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?
|
||||
Проверяет problem-first объяснение, а не dump.
|
||||
Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?
|
||||
Тест на document_conflict.
|
||||
Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?
|
||||
Это уже “человеческий” symptom-first вопрос.
|
||||
Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?
|
||||
Полезный тест на ranking и truthful limitations.
|
||||
2. НДС / книга покупок / книга продаж
|
||||
13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?
|
||||
Это хороший cross-branch вопрос по реальной цепочке июля.
|
||||
По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?
|
||||
Тест на false confidence и mechanism specificity.
|
||||
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
|
||||
Это уже отличный реальный кейс под P0-домен НДС.
|
||||
Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?
|
||||
Проверяет expected edges.
|
||||
Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно?
|
||||
Полезно для поиска реальных дыр, а не только для заранее известных кейсов.
|
||||
Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?
|
||||
Тест именно на explainability.
|
||||
Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?
|
||||
Это хороший semi-open case на company snapshot.
|
||||
Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?
|
||||
Тест на broken_chain_segment в домене НДС.
|
||||
3. Закрытие месяца / затраты / РБП / амортизация
|
||||
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
|
||||
Это company-specific вопрос на period close.
|
||||
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
|
||||
Хороший тест на lifecycle anomaly без выхода в полный Stage 5.
|
||||
31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
|
||||
Даже если ОС не P0, этот кейс полезен как controlled adjacent check.
|
||||
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
|
||||
Это уже зрелый product test на limitation honesty.
|
||||
Какие из этих 20 самые сильные для первого прогона
|
||||
|
||||
Если сжать до “ядра”, я бы первым запускал вот эти 8:
|
||||
|
||||
Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
|
||||
Поступление денег 276 873,60 от 13 июля — корректно ли зачёлся аванс 15 июля.
|
||||
Платежи 40 860 и 20 000 по договору № 1-ПМ/2020 — аванс это или закрытие дебиторки.
|
||||
31 июля услуги связи + НДС 233,33 + полученный счёт-фактура — полная ли НДС-цепочка.
|
||||
Есть ли покупки июля, где товар/услуга есть, а НДС-контур неполный.
|
||||
Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
|
||||
Списание РБП на 31 июля — не живёт ли часть РБП дольше ожидаемого.
|
||||
После полного month-end — что из остатков является реальной проблемой, а что нет.
|
||||
BIN
Binary file not shown.
BIN
Binary file not shown.
@@ -0,0 +1,325 @@
|
||||
Корпус Wave 9: 60 живых кейсов.md
|
||||
|
||||
Сейчас вы занимаетесь не “большим бухгалтерским ассистентом вообще”, а **доводкой P0-среза Stage 4**: ограниченный problem-first контур на трёх доменах — **60–62/банк/расчёты**, **НДС-цепочки**, **закрытие периода/затраты**. После Waves 5–8 базовый контур уже доведён до `P0_ACCEPTED_WITH_LIMITATIONS`, то есть архитектурный минимум работает, но теперь нужен **Wave 9 не про runtime, а про качество**: расширить живой корпус вопросов, усилить accountant-facing метрики и поймать скрытые quality-gap’ы — `generic_explanation_rate`, `false_confidence_rate`, `mechanism_specificity_score`, `followup_context_retention_score`, а также шумный ввод, транслит и multi-intent. Это прямо следует из playbook и Stage 1: не расширять домены, не лезть в Stage 5/6, а делать baseline stable и мерить реальную пользу бухгалтеру.
|
||||
|
||||
По форумной фактуре это тоже бьётся один в один: реальные вопросы крутятся вокруг **“не закрывается 60/62”, “аванс не зачёлся”, “не формируется книга покупок / не попадает счёт-фактура”, “не закрывается 20”, “остатки НЗП висят”, “68.90 не сходится с ЛК/ЕНС”**. На форумах ответы часто сводятся не к абстрактной аналитике, а к очень предметным проверкам: договор, зачёт аванса, основание счёта-фактуры, заполнение регистра, база распределения, номенклатурная группа, отчёт по расчётам/ЕНС. Это хороший сигнал для вас: корпус надо собирать не “про сущности”, а про **симптом + ожидаемое состояние + первый шаг проверки**.
|
||||
|
||||
Ниже даю тебе уже **готовый корпус живых человекоподобных кейсов для Wave 9**, собранный по логике форумов и под ваш продуктовый контур. Я специально делаю его не как “идеальные формулировки”, а как то, **как реально спрашивают**. Внутри каждого кейса ставлю, какую дыру он должен помогать ловить.
|
||||
|
||||
---
|
||||
|
||||
## Какой корпус вам нужен для Wave 9
|
||||
|
||||
Нужны не просто ещё вопросы, а вопросы, которые добивают оставшиеся quality-gap’ы:
|
||||
|
||||
* чтобы ассистент **не отвечал общими словами**;
|
||||
* чтобы **не делал лишне уверенных выводов**;
|
||||
* чтобы называл **механизм**, а не только симптом;
|
||||
* чтобы **держал продолжение разговора**;
|
||||
* чтобы не ломался на **шуме, разговорности, транслите и multi-intent**.
|
||||
|
||||
Поэтому корпус лучше строить из 4 слоёв:
|
||||
|
||||
1. **Core P0 symptom cases** — прямые форумные боли.
|
||||
2. **Mechanism specificity cases** — где важен точный тип поломки.
|
||||
3. **Follow-up cases** — продолжение без полного повторения контекста.
|
||||
4. **Noisy / translit / multi-intent cases** — чтобы не было “зелёной” ложной обработки.
|
||||
|
||||
---
|
||||
|
||||
## Корпус Wave 9: 60 живых кейсов
|
||||
|
||||
### A. Расчёты / банк / 60–62 — 20 кейсов
|
||||
|
||||
1. Почему не закрываются между собой 60.01 и 60.02 по одному поставщику, суммы одинаковые, а висит и дебет, и кредит?
|
||||
Теги: core, mechanism specificity
|
||||
Опора: типовой форумный паттерн по 60.01/60.02.
|
||||
|
||||
2. Оплата поставщику прошла, акт закрыт, а 60 счёт всё равно не сворачивается. Куда смотреть первым делом?
|
||||
Теги: core, actionability
|
||||
Опора: частый симптом “оплата есть, закрытия нет”.
|
||||
|
||||
3. У меня по поставщику аванс ушёл, поступление есть, но проводки Дт 60.01 Кт 60.02 нет. Это договор или документ расчётов?
|
||||
Теги: core, mechanism specificity
|
||||
Опора: форумный паттерн про незачтённый аванс.
|
||||
|
||||
4. Почему аванс поставщику не зачёлся частично? Было 40 тысяч, акт на 20, а зачёт нужен только на 2600.
|
||||
Теги: specificity, false confidence
|
||||
Опора: кейсы про частичный зачёт аванса.
|
||||
|
||||
5. Деньги ушли в прошлом месяце, закрытие идёт в этом, и теперь расчёты разъехались. Что именно проверить по периодам?
|
||||
Теги: period, mechanism specificity
|
||||
|
||||
6. По покупателю висит 62.01 и одновременно аванс на 62.02. Это ошибка в оплате или в закрывающем документе?
|
||||
Теги: core, ambiguity
|
||||
|
||||
7. Несколько оплат и несколько реализаций по одному договору, а система закрыла не тем документом. Как понять, какой документ спорный?
|
||||
Теги: problem-first, mechanism specificity
|
||||
|
||||
8. Почему после перепроведения документы по контрагенту начали закрываться по-другому, и остаток по 60 съехал?
|
||||
Теги: false confidence, follow-up ready
|
||||
|
||||
9. Услуга закрыта, деньги заплачены, но кредиторка осталась висеть. Это точно не из-за договора “без указания документа”?
|
||||
Теги: mechanism specificity
|
||||
Опора: на форумах договор и документ расчётов постоянно всплывают как первый check.
|
||||
|
||||
10. У нас ERP, не закрывается аванс поставщику, хотя поставка пришла. Как найти разрыв: в платёжке, поступлении или зачёте?
|
||||
Теги: core, actionability
|
||||
Опора: серия форумных ERP-кейсов есть в собранной карте.
|
||||
|
||||
11. Оплата и поступление на одинаковую сумму, а свёртки нет. Что чаще всего не совпадает: договор, статья, аналитика или документ расчётов?
|
||||
Теги: generic explanation trap
|
||||
|
||||
12. Почему после корректировки поступления зачёт аванса поехал и теперь расчёты перестали биться?
|
||||
Теги: specificity
|
||||
Опора: есть отдельные кейсы про корректировку поступления и зачёт аванса.
|
||||
|
||||
13. По одному контрагенту всё закрывается, по другому — нет, хотя схема одна и та же. Какой минимальный набор отличий нужно сравнить?
|
||||
Теги: actionability
|
||||
|
||||
14. У меня остаток по поставщику висит копейками после серии взаимозачётов. Это признак кривой цепочки или просто округление?
|
||||
Теги: false confidence
|
||||
|
||||
15. Почему при оплате услуг 60.02 и 60.01 не сворачиваются, если сумма одна и та же?
|
||||
Теги: core
|
||||
Опора: практически дословный форумный паттерн.
|
||||
|
||||
16. Я перепровела все документы, но 60 всё равно не закрывается. Что дальше: восстановление расчётов или искать не тот договор?
|
||||
Теги: actionability
|
||||
Опора: форумные ответы часто советуют договор + перепроведение/восстановление.
|
||||
|
||||
17. Можешь понять, это у меня реально проблема с закрытием расчётов или просто обычный незакрытый аванс, который так и должен висеть?
|
||||
Теги: false confidence, limitation honesty
|
||||
|
||||
18. Я не понимаю, почему по поставщику в одном месте долг, а в другом переплата. Это один конфликт или две разные проблемы?
|
||||
Теги: problem unit clarity
|
||||
|
||||
19. Скажи по-человечески, что именно сломано: деньги ушли, товар пришёл, а расчёты не закрылись.
|
||||
Теги: generic explanation trap
|
||||
|
||||
20. У меня несколько договоров с одним поставщиком, и кажется, оплата легла не туда. Как это проверить без ковыряния всех документов подряд?
|
||||
Теги: actionability, follow-up ready
|
||||
|
||||
---
|
||||
|
||||
### B. НДС / книга покупок / книга продаж — 20 кейсов
|
||||
|
||||
21. Почему не формируется книга покупок, если все счета-фактуры есть и проведены?
|
||||
Теги: core
|
||||
Опора: один из самых повторяющихся форумных симптомов.
|
||||
|
||||
22. Счёт-фактура есть, поступление есть, а в формирование записей книги покупок документ не попадает. Что конкретно обычно ломает цепочку?
|
||||
Теги: core, mechanism specificity
|
||||
Опора: типовой форумный паттерн.
|
||||
|
||||
23. Почему часть счетов-фактур попадает в книгу покупок, а часть нет, хотя все проведены одинаково?
|
||||
Теги: ambiguity
|
||||
Опора: частый симптом частичного выпадения.
|
||||
|
||||
24. У меня поступление и счёт-фактура на основании есть, но НДС в книге пустой. Это проблема документа-основания или регистра?
|
||||
Теги: mechanism specificity
|
||||
|
||||
25. Не формируется проводка Дт 19 Кт 68 после корректировки поступления. Где искать конфликт?
|
||||
Теги: specificity
|
||||
Опора: отдельный форумный паттерн собран в карте.
|
||||
|
||||
26. Почему книга покупок пустая, если журнал полученных счетов-фактур заполнен?
|
||||
Теги: core, false confidence
|
||||
Опора: связка “журнал есть, книга пустая” встречается в практических кейсах.
|
||||
|
||||
27. Счет-фактура на аванс поставщику есть, галочка для книги покупок стоит, а книга всё равно пустая. Что я делаю не так?
|
||||
Теги: core
|
||||
Опора: форумный кейс по авансовой счёт-фактуре.
|
||||
|
||||
28. Документ поступления есть, счёт-фактура есть, но вычет по НДС не отразился. Это уже налоговая проблема или ещё документная?
|
||||
Теги: mechanism specificity, false confidence
|
||||
|
||||
29. Не могу понять, почему с фильтром по счёту книга покупок не формируется, а без фильтра формируется. Это я не туда смотрю?
|
||||
Теги: noisy practical case
|
||||
Опора: отдельный форумный кейс по отбору по счёту.
|
||||
|
||||
30. Почему после ввода остатков у меня не формируется книга покупок? Это потому что счёт-фактура введена тем же числом?
|
||||
Теги: period/migration
|
||||
Опора: кейсы после ввода остатков есть на форуме.
|
||||
|
||||
31. У меня НДС “включён в стоимость”, это может объяснить, почему документ не попадает в вычет?
|
||||
Теги: mechanism specificity
|
||||
Опора: в предыдущем исследовании отмечалось, что форумные причины часто сидят в конкретных флагах/режимах.
|
||||
|
||||
32. Почему формирование записей книги покупок не берёт конкретную счёт-фактуру, хотя договор настроен на автоматическое формирование?
|
||||
Теги: core
|
||||
Опора: договор/настройка автоматического формирования — повторяющийся форумный мотив.
|
||||
|
||||
33. Мне нужен не список отчётов, а нормальный ответ: почему конкретный документ не попал в книгу покупок?
|
||||
Теги: generic explanation trap
|
||||
|
||||
34. Это проблема периода или проблема связи “поступление → счёт-фактура”?
|
||||
Теги: mechanism specificity
|
||||
|
||||
35. По одной организации вкладка со счётом-фактурой в поступлении есть и всё формируется, по другой — нет. Это учётная политика?
|
||||
Теги: ambiguity
|
||||
Опора: похожий форумный кейс с разным поведением по организациям.
|
||||
|
||||
36. Скажи, у меня реально разрыв НДС-цепочки или просто не хватает одного регистра/флага, чтобы это доказать?
|
||||
Теги: limitation honesty
|
||||
|
||||
37. В книге продаж всё ок, а книга покупок пустая. Это один и тот же механизм или две разные ветки проверки?
|
||||
Теги: problem unit clarity
|
||||
|
||||
38. После корректировки документа НДС поехал, а я не понимаю, где именно: в основании, счёт-фактуре или книге.
|
||||
Теги: specificity, follow-up ready
|
||||
|
||||
39. У меня часть авансов по НДС берётся к вычету не так, как ожидалось. Это зачёт аванса или восстановление НДС?
|
||||
Теги: ambiguity
|
||||
Опора: форумный кейс по зачёту авансов и НДС.
|
||||
|
||||
40. Почему документ виден в одном НДС-отчёте, но не участвует в формировании записей книги покупок?
|
||||
Теги: cross-branch contradiction
|
||||
|
||||
---
|
||||
|
||||
### C. Закрытие месяца / 20 / 44 / затраты — 20 кейсов
|
||||
|
||||
41. При закрытии месяца не закрывается 20 счёт. С чего начать, если никаких ошибок программа не показывает?
|
||||
Теги: core
|
||||
Опора: очень типичный форумный симптом.
|
||||
|
||||
42. Закрытие месяца прошло без ошибок, но остатки на 20 всё равно висят. Это норма или явный дефект?
|
||||
Теги: false confidence
|
||||
Опора: “прошло без ошибок, но остатки остались” — повторяющийся кейс.
|
||||
|
||||
43. Почему не закрывается НЗП прошлого месяца по одной номенклатурной группе, хотя выручка в периоде есть?
|
||||
Теги: mechanism specificity
|
||||
Опора: почти дословный форумный кейс.
|
||||
|
||||
44. Я руками завела расходы на 20, и после этого счёт не закрывается. Это из-за ручных операций или из-за аналитики?
|
||||
Теги: specificity
|
||||
Опора: форумный пример с ручными операциями Дт20 Кт71.
|
||||
|
||||
45. Сумма зависла на 20 счёте, но я не понимаю — это нормальное НЗП или программа не довела close до конца?
|
||||
Теги: limitation honesty
|
||||
Опора: на форуме прямо указывают, что часть остатков на 20 — это нормальное НЗП.
|
||||
|
||||
46. Почему 44 не закрывается, хотя выручка есть и вроде всё настроено?
|
||||
Теги: core
|
||||
Опора: кейсы по 44 есть в собранной карте форумов.
|
||||
|
||||
47. Документ закрытия месяца проводится, но фактического эффекта нет. Где искать: база распределения, учётная политика или аналитика затрат?
|
||||
Теги: mechanism specificity
|
||||
|
||||
48. Выпуска нет, расходы есть. Что программа должна сделать с 20 счётом в этом случае?
|
||||
Теги: false confidence
|
||||
Опора: в практических материалах это отдельный типовой вопрос.
|
||||
|
||||
49. По одной номенклатурной группе всё закрывается, по другой — нет. Какой минимальный дифф сравнивать?
|
||||
Теги: actionability
|
||||
|
||||
50. Почему после смены способа распределения 20 счёт стал закрываться по-другому?
|
||||
Теги: follow-up ready
|
||||
|
||||
51. Можешь понять, что именно мешает закрытию месяца, а не просто перечислять документы по затратам?
|
||||
Теги: generic explanation trap
|
||||
|
||||
52. Остатки на 20 висят копейками. Это rounding, НЗП или реальная поломка распределения?
|
||||
Теги: false confidence
|
||||
|
||||
53. По идее база распределения есть, но программа ведёт себя так, как будто её нет. Куда копать?
|
||||
Теги: mechanism specificity
|
||||
Опора: дословно близко к форумному кейсу с “как будто нет базы распределения”.
|
||||
|
||||
54. После закрытия месяца по 20 всё красиво, а по 44 хвосты остались. Это одна проблема или две?
|
||||
Теги: problem unit clarity
|
||||
|
||||
55. Закрытие затрат прошло, но себестоимость выглядит странно. Это вообще этот домен или уже другая ветка?
|
||||
Теги: ambiguity
|
||||
|
||||
56. Я хочу понять человеческим языком: что именно сломано в закрытии — нет выпуска, нет аналитики или нет базы распределения?
|
||||
Теги: generic explanation trap
|
||||
|
||||
57. Почему после ручной корректировки всё закрылось, а без неё нет? Это значит, что сломан маршрут закрытия?
|
||||
Теги: mechanism specificity
|
||||
|
||||
58. У меня зависает сумма на 20 и программа молчит. Какой первый отчёт или объект смотреть, чтобы не копать всё подряд?
|
||||
Теги: actionability
|
||||
Опора: на форуме советуют сначала понять, что это за сумма, через профильный отчёт по затратам.
|
||||
|
||||
59. Это похоже на проблему периода или на проблему конкретной затратной цепочки?
|
||||
Теги: mechanism specificity
|
||||
|
||||
60. По-человечески объясни, почему месяц “закрылся”, а результат не похож на закрытие.
|
||||
Теги: accountant-facing quality
|
||||
|
||||
---
|
||||
|
||||
## Отдельный mini-pack для Wave 9: follow-up / noisy / translit / multi-intent
|
||||
|
||||
Эти кейсы не расширяют доменный scope, но очень нужны именно под Wave 9, потому что они бьют по `followup_context_retention_score`, `false_confidence_rate` и decomposition quality. Это прямо рекомендовано в Stage 1 и в ваших problem-first материалах.
|
||||
|
||||
### Follow-up
|
||||
|
||||
61. А теперь посмотри только по одному договору, не по всему поставщику.
|
||||
62. Нет, меня интересует именно почему не зачёлся аванс, а не почему долг висит в целом.
|
||||
63. Возьми тот же кейс, но только за прошлый квартал.
|
||||
64. Хорошо, а если исключить корректировку, проблема всё ещё остаётся?
|
||||
65. Я про тот документ, который вчера обсуждали, не про все поступления.
|
||||
|
||||
### Noisy / colloquial
|
||||
|
||||
66. Чё за фигня, бабки ушли, акт есть, а 60 всё равно висит.
|
||||
67. Книга покупок пустая, хотя сч-ф все на месте, где косяк-то?
|
||||
68. Месяц типа закрылся, а двадцатка как висела, так и висит.
|
||||
69. По ЕНС всё вообще черт ногу сломит, с чем мне сверяться-то.
|
||||
70. У меня не бьётся НДС, не надо мне список отчётов, скажи что сломано.
|
||||
|
||||
### Translit / mixed
|
||||
|
||||
71. ne zakryvaetsya 20 schet posle zakrytiya mesyatsa
|
||||
72. kniga pokupok pustaya hotya schet-faktury est
|
||||
73. avans postavshiku ne zaschitalsya pochemu
|
||||
74. ne bietsya 68.90 s lk fns kak sverit
|
||||
75. pochemu ne popadaet schet faktura v formirovanie zapisey
|
||||
|
||||
### Multi-intent
|
||||
|
||||
76. Проверь, почему не закрывается 60, и заодно скажи, не из-за этого ли не формируется книга покупок.
|
||||
77. Посмотри, у меня и 20 не закрывается, и по НДС документы не попадают, это одно с другим связано?
|
||||
78. Сначала пойми, почему висит 62, а потом отдельно скажи, надо ли перепроводить документы.
|
||||
79. Проверь расчёты с поставщиком и скажи, не ломает ли это закрытие месяца.
|
||||
80. Мне нужно понять и почему книга покупок пустая, и почему 68.90 не бьётся, но если это разные проблемы — раздели их.
|
||||
|
||||
---
|
||||
|
||||
## Как этим пользоваться в вашем контуре
|
||||
|
||||
Чтобы не растерять суть, я бы превращал этот корпус не просто в список вопросов, а в таблицу с такими колонками:
|
||||
|
||||
* `case_id`
|
||||
* `domain`
|
||||
* `query_text`
|
||||
* `query_class`
|
||||
(`symptom_first`, `lifecycle_first`, `followup`, `multi_intent`, `noisy`, `translit`)
|
||||
* `expected_problem_family`
|
||||
* `expected_mechanism_class`
|
||||
* `must_have_first_check`
|
||||
* `must_have_limitation`
|
||||
* `forbidden_answer_pattern`
|
||||
|
||||
И вот тут у вас как раз появится нормальная связь с Wave 9:
|
||||
она будет не “доделать ответы ещё чуть-чуть”, а **добить качество на тех запросах, на которых бухгалтер реально разговаривает**. Это соответствует вашему `accountant eval layer`, canonical scenario suite и benchmark logic.
|
||||
|
||||
## Коротко, что вы хотите от Wave 9
|
||||
|
||||
Если совсем сжать:
|
||||
|
||||
**Wave 9 нужна, чтобы доказать, что текущий P0-контур держит не только “чистые” вопросы, но и живую бухгалтерскую речь.**
|
||||
|
||||
То есть:
|
||||
|
||||
* не срывается в generic;
|
||||
* не врёт уверенно;
|
||||
* называет механизм;
|
||||
* даёт первый шаг проверки;
|
||||
* держит продолжение;
|
||||
* не теряет смысл на шумном вводе.
|
||||
|
||||
Если хочешь, следующим сообщением я превращу это сразу в **готовую JSON/YAML-структуру для eval corpus Wave 9** с полями, чтобы это можно было почти без переделки отдать в Codex.
|
||||
Reference in New Issue
Block a user