Stage 3 Wave 1: lifecycle-слой встроен в pipeline
This commit is contained in:
+687
@@ -0,0 +1,687 @@
|
||||
# ACCEPTANCE_CHECKLIST_STAGE_03
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ используется для приёмки реализации Stage 3.
|
||||
Его задача — не проверить “что-то поменялось”, а убедиться, что:
|
||||
|
||||
- lifecycle formalization реально внедрена в runtime;
|
||||
- текущий scope не расползся;
|
||||
- lifecycle-модели не остались формальными таблицами;
|
||||
- problem units, ranking и answer реально используют lifecycle;
|
||||
- заложена корректная база для Stage 4.
|
||||
|
||||
Документ обязателен для:
|
||||
- Codex;
|
||||
- разработчика;
|
||||
- ручного review;
|
||||
- финальной фиксации результата по Stage 3.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: чеклист приёмки Stage 3
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен при завершении каждой волны и при финальной приёмке Stage 3
|
||||
- При конфликте по scope приоритет имеет `STAGE_03_TASK_CARD.md`
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `ARCHITECTURE_GUARDRAILS.md`
|
||||
- При конфликте по platform logic приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
|
||||
## Правила оценки
|
||||
|
||||
Для каждого пункта допускаются только следующие статусы:
|
||||
|
||||
- `PASS` — выполнено полностью
|
||||
- `PARTIAL` — выполнено частично, требуется доработка
|
||||
- `FAIL` — не выполнено
|
||||
- `N/A` — не применимо, только если это действительно обосновано
|
||||
|
||||
Для каждого пункта должен быть указан комментарий:
|
||||
- что проверялось;
|
||||
- где это реализовано;
|
||||
- чем подтверждается;
|
||||
- какие ограничения остались.
|
||||
|
||||
---
|
||||
|
||||
## Общая логика приёмки
|
||||
|
||||
Stage 3 считается принятым только если одновременно соблюдены условия:
|
||||
|
||||
1. Закрыт именно Stage 3, а не “произвольный улучшенный вариант”.
|
||||
2. Текущий рабочий контур не разрушен.
|
||||
3. Есть формальные lifecycle-модели по целевым доменам.
|
||||
4. Есть рабочий lifecycle runtime.
|
||||
5. Problem units реально обогащаются lifecycle-полями.
|
||||
6. Ranking использует lifecycle-дефекты по смыслу вопроса.
|
||||
7. Ответы объясняют проблему через state/transition logic.
|
||||
8. Есть benchmark/eval и before/after evidence.
|
||||
9. Нет скрытого выезда в Stage 4–6.
|
||||
10. Изменения совместимы с platform core.
|
||||
|
||||
Если хотя бы один из этих пунктов провален, Stage 3 не считается завершённым.
|
||||
|
||||
---
|
||||
|
||||
# Блок A. Scope discipline
|
||||
|
||||
## A1. Реализован именно Stage 3
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- реализованы lifecycle formalization изменения;
|
||||
- не добавлена скрытая логика следующих этапов;
|
||||
- улучшения соответствуют текущему scope.
|
||||
|
||||
Критерии PASS:
|
||||
- все ключевые изменения относятся к Stage 3;
|
||||
- нет “заодно реализованных” future-stage подсистем.
|
||||
|
||||
---
|
||||
|
||||
## A2. Нет скрытого выезда в Stage 4
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён полноценный ontology/graph runtime;
|
||||
- нет graph-first core path;
|
||||
- graph не стал обязательной зависимостью answer flow.
|
||||
|
||||
Критерии PASS:
|
||||
- максимум заложена совместимость;
|
||||
- полноценный Stage 4 runtime не реализован.
|
||||
|
||||
---
|
||||
|
||||
## A3. Нет скрытого выезда в Stage 5
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён full investigation engine;
|
||||
- нет полноценного branching case-runtime;
|
||||
- нет сложного bounded investigation orchestration.
|
||||
|
||||
Критерии PASS:
|
||||
- Stage 5 логика не реализована как текущий core-runtime.
|
||||
|
||||
---
|
||||
|
||||
## A4. Нет скрытого выезда в Stage 6
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён live verification core path;
|
||||
- нет full product mode split `direct / investigation / audit`;
|
||||
- нет полноценного trust-state live contour.
|
||||
|
||||
Критерии PASS:
|
||||
- Stage 6 логика не реализована как текущий рабочий слой.
|
||||
|
||||
---
|
||||
|
||||
## A5. Не выполнен большой ненужный рефактор
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не переписан transport layer без необходимости;
|
||||
- не переписан endpoint layer без необходимости;
|
||||
- не переписан base routing без необходимости;
|
||||
- не переписан assistant loop ради архитектурной красоты.
|
||||
|
||||
Критерии PASS:
|
||||
- изменения локальны и обоснованы;
|
||||
- рабочий контур сохранён.
|
||||
|
||||
---
|
||||
|
||||
# Блок B. Lifecycle models
|
||||
|
||||
## B1. Есть lifecycle_domain registry по целевым доменам
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- покрыты `bank_settlement`, `customer_settlement`, `deferred_expense`, `fixed_asset`, `vat_flow`, `period_close`;
|
||||
- для доменов определены поддерживаемые объекты.
|
||||
|
||||
Критерии PASS:
|
||||
- registry существует и используется runtime.
|
||||
|
||||
---
|
||||
|
||||
## B2. Состояния описаны формально и операционно
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- у состояний есть `entry_conditions` и `exit_conditions`;
|
||||
- у состояний есть business смысл;
|
||||
- состояния не абстрактны и распознаваемы по данным.
|
||||
|
||||
Критерии PASS:
|
||||
- state-модель применима к реальным retrieval данным.
|
||||
|
||||
---
|
||||
|
||||
## B3. Переходы описаны с evidence requirements
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть `required_evidence` и `forbidden_conditions`;
|
||||
- transition logic пригодна для runtime resolution.
|
||||
|
||||
Критерии PASS:
|
||||
- переходы можно проверить автоматически.
|
||||
|
||||
---
|
||||
|
||||
## B4. Есть lifecycle defect catalog
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- покрыты базовые defect classes;
|
||||
- у дефектов есть severity/business meaning;
|
||||
- дефекты привязаны к evidence requirements.
|
||||
|
||||
Критерии PASS:
|
||||
- дефекты классифицируются по данным, а не вручную.
|
||||
|
||||
---
|
||||
|
||||
## B5. Соблюдено правило масштаба lifecycle_object
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- lifecycle применяется к объекту правильного масштаба;
|
||||
- не используется слишком грубая сущность уровня “контрагент в целом”.
|
||||
|
||||
Критерии PASS:
|
||||
- resolution имеет предметный объект и контекст.
|
||||
|
||||
---
|
||||
|
||||
# Блок C. Lifecycle runtime
|
||||
|
||||
## C1. Реализован и используется `LifecycleRegistry`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- registry является source of truth;
|
||||
- runtime читает определения из registry.
|
||||
|
||||
Критерии PASS:
|
||||
- нет дублирующей логики “по месту”.
|
||||
|
||||
---
|
||||
|
||||
## C2. Реализован и используется `LifecycleResolver`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- resolver вычисляет `current` и `expected` state;
|
||||
- resolver определяет missing/invalid transitions;
|
||||
- resolver отдаёт confidence и limitations.
|
||||
|
||||
Критерии PASS:
|
||||
- resolution работает на runtime-данных.
|
||||
|
||||
---
|
||||
|
||||
## C3. Реализован `LifecycleDefectClassifier`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- classifier переводит несоответствия в defect types;
|
||||
- классификация воспроизводима и тестируема.
|
||||
|
||||
Критерии PASS:
|
||||
- defect typing не остаётся свободной интерпретацией.
|
||||
|
||||
---
|
||||
|
||||
## C4. Реализован `LifecycleEnricher`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- enrichment происходит на runtime-пути;
|
||||
- enrichment добавляет lifecycle поля в problem units.
|
||||
|
||||
Критерии PASS:
|
||||
- enriched unit не является “мёртвой” сущностью.
|
||||
|
||||
---
|
||||
|
||||
## C5. Runtime устойчив к неполным данным
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть честная обработка ограниченного evidence;
|
||||
- нет ложной уверенности при слабой опоре.
|
||||
|
||||
Критерии PASS:
|
||||
- uncertainty/limitations явно фиксируются.
|
||||
|
||||
---
|
||||
|
||||
# Блок D. Integration with problem units
|
||||
|
||||
## D1. Обновлён `problem_unit_schema`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- присутствуют lifecycle-поля Stage 3;
|
||||
- схема совместима с существующим Stage 2 контуром.
|
||||
|
||||
Критерии PASS:
|
||||
- problem unit содержит lifecycle-смысл.
|
||||
|
||||
---
|
||||
|
||||
## D2. Lifecycle enrichment реально участвует в runtime
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- enrichment выполняется на рабочем пути;
|
||||
- lifecycle-данные доходят до answer слоя.
|
||||
|
||||
Критерии PASS:
|
||||
- lifecycle не ограничен логами или служебным payload.
|
||||
|
||||
---
|
||||
|
||||
## D3. Механика дефекта видна в unit
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- в unit видны state/transition mismatch;
|
||||
- `missing_transition`, `invalid_transition`, `lifecycle_defect_type` доступны downstream.
|
||||
|
||||
Критерии PASS:
|
||||
- problem unit объясняет “что сломано” и “на какой стадии сломано”.
|
||||
|
||||
---
|
||||
|
||||
# Блок E. Ranking integration
|
||||
|
||||
## E1. Lifecycle factors добавлены в ranking policy
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть lifecycle severity, stale duration, period impact и связанные факторы;
|
||||
- ranking учитывает lifecycle confidence.
|
||||
|
||||
Критерии PASS:
|
||||
- ranking использует lifecycle-сигналы явно.
|
||||
|
||||
---
|
||||
|
||||
## E2. Ranking не сводится к сумме/объёму
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- для risk/stale/lifecycle-запросов lifecycle weight выше magnitude-only сигналов.
|
||||
|
||||
Критерии PASS:
|
||||
- порядок выдачи меняется по смыслу вопроса.
|
||||
|
||||
---
|
||||
|
||||
## E3. Есть evidence улучшения ranking
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть before/after примеры;
|
||||
- видно снижение entity-heavy leakage.
|
||||
|
||||
Критерии PASS:
|
||||
- изменение ranking подтверждено измеримо.
|
||||
|
||||
---
|
||||
|
||||
# Блок F. Answer quality
|
||||
|
||||
## F1. Ответы объясняют lifecycle-логику
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- ответ показывает текущую стадию и ожидаемую стадию;
|
||||
- ответ показывает проблемный или отсутствующий переход.
|
||||
|
||||
Критерии PASS:
|
||||
- есть state/transition reasoning, а не общие labels.
|
||||
|
||||
---
|
||||
|
||||
## F2. Появилась предметная business-интерпретация
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- объяснено бухгалтерское значение дефекта;
|
||||
- указано влияние на период/расчёты/вычет/амортизацию при релевантности.
|
||||
|
||||
Критерии PASS:
|
||||
- ответ операбелен для бухгалтера.
|
||||
|
||||
---
|
||||
|
||||
## F3. Есть связь вывода с evidence
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- в объяснении присутствуют документы/проводки/регистры как опора;
|
||||
- нет оторванных от evidence выводов.
|
||||
|
||||
Критерии PASS:
|
||||
- claim и evidence связаны прозрачно.
|
||||
|
||||
---
|
||||
|
||||
## F4. Generic lifecycle labels не доминируют
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- ответы не ограничиваются “broken_lifecycle”, “неполно подтверждено” и подобными формулировками.
|
||||
|
||||
Критерии PASS:
|
||||
- ответы стали stage-aware и механизмно объяснимыми.
|
||||
|
||||
---
|
||||
|
||||
# Блок G. Eval / quality
|
||||
|
||||
## G1. Есть benchmark suite по covered domains
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- benchmark покрывает 51/60, 97, ОС, НДС, period close;
|
||||
- кейсы воспроизводимы.
|
||||
|
||||
Критерии PASS:
|
||||
- benchmark можно использовать для повторной проверки.
|
||||
|
||||
---
|
||||
|
||||
## G2. Добавлены lifecycle resolution tests
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- тестируется определение current/expected states;
|
||||
- тестируются missing/invalid transitions.
|
||||
|
||||
Критерии PASS:
|
||||
- critical resolution логика покрыта тестами.
|
||||
|
||||
---
|
||||
|
||||
## G3. Добавлены defect classification tests
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- тестируется классификация основных defect types.
|
||||
|
||||
Критерии PASS:
|
||||
- defect classifier проверяется автоматически.
|
||||
|
||||
---
|
||||
|
||||
## G4. Добавлены lifecycle-aware explanation tests
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- тестируется шаблон и содержание lifecycle-объяснения;
|
||||
- проверяется отсутствие ухода в generic labels при успешном resolution.
|
||||
|
||||
Критерии PASS:
|
||||
- answer слой закреплён тестами.
|
||||
|
||||
---
|
||||
|
||||
## G5. Подготовлен before/after eval report
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть baseline;
|
||||
- есть результаты после внедрения Stage 3;
|
||||
- видно, что именно улучшилось и где остались ограничения.
|
||||
|
||||
Критерии PASS:
|
||||
- улучшения подтверждены измеримо.
|
||||
|
||||
---
|
||||
|
||||
# Блок H. Observability / compatibility
|
||||
|
||||
## H1. Lifecycle-решения диагностируемы
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- можно увидеть, как было разрешено состояние;
|
||||
- можно увидеть причину классификации дефекта.
|
||||
|
||||
Критерии PASS:
|
||||
- есть минимальная наблюдаемость новых решений.
|
||||
|
||||
---
|
||||
|
||||
## H2. Новые контракты описаны явно
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- lifecycle contracts формализованы;
|
||||
- поля и назначение понятны;
|
||||
- source of truth определён.
|
||||
|
||||
Критерии PASS:
|
||||
- нет неявной архитектуры “между строк”.
|
||||
|
||||
---
|
||||
|
||||
## H3. Изменения не создают тупик для Stage 4–6
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- решения Stage 3 не блокируют graph/investigation/live развитие;
|
||||
- нет временных схем, выдаваемых за целевые.
|
||||
|
||||
Критерии PASS:
|
||||
- путь к следующим этапам открыт.
|
||||
|
||||
---
|
||||
|
||||
## H4. Обратная совместимость и миграции понятны
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- если появились новые контракты/хранилища/схемы, описано как они инициализируются;
|
||||
- понятно, нужен ли migration step.
|
||||
|
||||
Критерии PASS:
|
||||
- внедрение повторяемо и сопровождаемо.
|
||||
|
||||
---
|
||||
|
||||
# Блок I. Documentation completeness
|
||||
|
||||
## I1. Созданы спецификационные артефакты Stage 3
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть domain/state/transition/defect спецификации;
|
||||
- есть lifecycle object mapping спецификация.
|
||||
|
||||
Критерии PASS:
|
||||
- спецификационные артефакты существуют и актуальны.
|
||||
|
||||
---
|
||||
|
||||
## I2. Созданы runtime-артефакты Stage 3
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- реализованы и задокументированы `LifecycleRegistry`, `LifecycleResolver`, `LifecycleDefectClassifier`, `LifecycleEnricher`.
|
||||
|
||||
Критерии PASS:
|
||||
- runtime-артефакты доступны и применяются.
|
||||
|
||||
---
|
||||
|
||||
## I3. Есть acceptance mapping
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- для каждого ключевого изменения указано, какой критерий Stage 3 оно закрывает.
|
||||
|
||||
Критерии PASS:
|
||||
- изменения привязаны к acceptance criteria.
|
||||
|
||||
---
|
||||
|
||||
## I4. Есть список сознательно не реализованного
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- явно перечислено, что не делалось сейчас;
|
||||
- причины отложенных вещей зафиксированы;
|
||||
- нет скрытого scope drift.
|
||||
|
||||
Критерии PASS:
|
||||
- границы текущего этапа прозрачны.
|
||||
|
||||
---
|
||||
|
||||
# Блок J. Финальное решение по этапу
|
||||
|
||||
## J1. Stage 3 можно считать принятым
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Критерии PASS:
|
||||
- блоки A–I не содержат критических FAIL;
|
||||
- PARTIAL не влияют на core acceptance;
|
||||
- lifecycle formalization реально работает в runtime.
|
||||
|
||||
---
|
||||
|
||||
## J2. Stage 3 нельзя считать принятым
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Ставится `PASS`, если выполнено хотя бы одно из условий:
|
||||
- lifecycle-модели остались только в документации;
|
||||
- lifecycle не участвует в problem units/ranking/answer;
|
||||
- дефекты не классифицируются автоматически;
|
||||
- ответы остаются generic;
|
||||
- benchmark/eval отсутствует;
|
||||
- был скрытый выезд в Stage 4–6;
|
||||
- рабочий контур сломан.
|
||||
|
||||
---
|
||||
|
||||
# Итоговая сводка по приёмке
|
||||
|
||||
## Общий итог
|
||||
- Результат: `PASS / PARTIAL / FAIL`
|
||||
- Дата проверки:
|
||||
- Проверял:
|
||||
- Версия / ветка / commit:
|
||||
- Связанные документы:
|
||||
|
||||
---
|
||||
|
||||
## Ключевые сильные стороны
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Ключевые недочёты
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Что обязательно исправить до приёмки
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Что допустимо перенести в следующий этап
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Явно подтверждено как non-scope текущего этапа
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Финальное решение
|
||||
- `Принять Stage 3`
|
||||
- `Принять Stage 3 условно`
|
||||
- `Вернуть на доработку`
|
||||
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
|
||||
# Короткая практическая формула
|
||||
|
||||
Stage 3 считается успешным не тогда, когда:
|
||||
|
||||
- появились новые lifecycle labels;
|
||||
- ответы стали длиннее;
|
||||
- тесты стали зелёными.
|
||||
|
||||
Stage 3 считается успешным тогда, когда одновременно:
|
||||
|
||||
- lifecycle-модель реально работает на runtime-данных;
|
||||
- problem units, ranking и answer используют lifecycle-логику;
|
||||
- пользователь получает объяснение, какая стадия нарушена и почему;
|
||||
- ценность улучшений подтверждена benchmark/eval.
|
||||
+9
-9
@@ -1,4 +1,4 @@
|
||||
ARCHITECTURE_GUARDRAILS.md
|
||||
ARCHITECTURE_GUARDRAILS.md
|
||||
|
||||
# ARCHITECTURE_GUARDRAILS
|
||||
|
||||
@@ -9,14 +9,14 @@ ARCHITECTURE_GUARDRAILS.md
|
||||
Документ нужен, чтобы:
|
||||
|
||||
- не допустить расползания scope;
|
||||
- не дать текущей реализации преждевременно превратиться в Stage 2–6;
|
||||
- не дать текущей реализации преждевременно превратиться в Stage 4–6;
|
||||
- не допустить появления скрытых костылей под видом “улучшения архитектуры”;
|
||||
- удержать изменения в рамках текущего этапа;
|
||||
- сохранить совместимость с будущим развитием системы.
|
||||
|
||||
Документ не заменяет:
|
||||
- `CODEX_MASTER_BRIEF.md`
|
||||
- `STAGE_01_TASK_CARD.md`
|
||||
- `STAGE_03_TASK_CARD.md`
|
||||
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- этапные ТЗ
|
||||
|
||||
@@ -29,7 +29,7 @@ ARCHITECTURE_GUARDRAILS.md
|
||||
- Статус: обязательный архитектурный ограничитель
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к применению до любых кодовых изменений
|
||||
- При конфликте с текущим scope приоритет имеет `STAGE_01_TASK_CARD.md`
|
||||
- При конфликте с текущим scope приоритет имеет `STAGE_03_TASK_CARD.md`
|
||||
- При конфликте по платформенным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
@@ -121,7 +121,7 @@ ARCHITECTURE_GUARDRAILS.md
|
||||
- уже действующий assistant loop.
|
||||
|
||||
Разрешены только точечные изменения, если они:
|
||||
- прямо обязательны для Stage 1;
|
||||
- прямо обязательны для Stage 3;
|
||||
- не могут быть внесены более локально.
|
||||
|
||||
---
|
||||
@@ -138,7 +138,7 @@ ARCHITECTURE_GUARDRAILS.md
|
||||
|
||||
---
|
||||
|
||||
### 3. Не внедрять преждевременно Stage 2–6
|
||||
### 3. Не внедрять преждевременно Stage 4–6
|
||||
|
||||
До наступления соответствующих этапов запрещено внедрять как core-runtime:
|
||||
|
||||
@@ -313,7 +313,7 @@ Evidence должно иметь хотя бы минимально явную
|
||||
Если да — выбирается более локальный вариант.
|
||||
|
||||
### Вопрос 3
|
||||
Это не тянет Stage 2–6 раньше времени?
|
||||
Это не тянет Stage 4–6 раньше времени?
|
||||
|
||||
Если тянет — изменение откладывается или упрощается.
|
||||
|
||||
@@ -495,7 +495,7 @@ Evidence должно иметь хотя бы минимально явную
|
||||
|
||||
1. Проверить соответствие текущему scope
|
||||
2. Проверить соответствие platform core ТЗ
|
||||
3. Проверить, не тянет ли изменение Stage 2–6
|
||||
3. Проверить, не тянет ли изменение Stage 4–6
|
||||
4. Проверить, можно ли сделать локальнее
|
||||
5. Зафиксировать риски
|
||||
6. Только после этого принимать решение
|
||||
@@ -530,4 +530,4 @@ Evidence должно иметь хотя бы минимально явную
|
||||
|
||||
**не сделать видимость зрелой системы, а реально уменьшить structural debt и подготовить прочную основу для следующих шагов.**
|
||||
|
||||
Любое изменение, которое противоречит этому принципу, должно считаться ошибочным, даже если оно выглядит “умным”, “масштабируемым” или “красивым”.
|
||||
Любое изменение, которое противоречит этому принципу, должно считаться ошибочным, даже если оно выглядит “умным”, “масштабируемым” или “красивым”.
|
||||
|
||||
+96
-111
@@ -1,6 +1,4 @@
|
||||
CODEX_MASTER_BRIEF.md
|
||||
|
||||
# CODEX_MASTER_BRIEF
|
||||
# CODEX_MASTER_BRIEF
|
||||
|
||||
## Назначение документа
|
||||
|
||||
@@ -22,14 +20,14 @@ CODEX_MASTER_BRIEF.md
|
||||
- Статус: основной управляющий бриф для Codex
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к прочтению перед любыми изменениями в коде
|
||||
- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_01_TASK_CARD.md`
|
||||
- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_03_TASK_CARD.md`
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
|
||||
## Контекст проекта
|
||||
|
||||
Разрабатывается бухгалтерский ассистент, который уже находится в рабочем состоянии на уровне функционального MVP+ и способен:
|
||||
Разрабатывается бухгалтерский ассистент, который находится в рабочем состоянии на уровне функционального MVP+ и способен:
|
||||
|
||||
- принимать пользовательские вопросы;
|
||||
- обращаться к имеющимся контурам данных;
|
||||
@@ -38,34 +36,30 @@ CODEX_MASTER_BRIEF.md
|
||||
- формировать объяснение;
|
||||
- возвращать ответ пользователю.
|
||||
|
||||
При этом текущая система ещё не является полноценным investigation copilot.
|
||||
Основные текущие ограничения:
|
||||
При этом текущая система ещё не является полноценным accountant-grade investigation copilot.
|
||||
На текущем переходе считаем этапы 1 и 2 выполненными и переходим к **Stage 3 / Lifecycle Formalization**.
|
||||
|
||||
- snapshot-only truth contour;
|
||||
- слабая формализация investigation state;
|
||||
- entity-heavy retrieval;
|
||||
- недостаточная структурность evidence;
|
||||
- неполный accountant-facing eval;
|
||||
- ограниченная управляемость broad / generic query handling;
|
||||
- отсутствие полноценного bounded investigation runtime;
|
||||
- отсутствие formal live verification trust model.
|
||||
Основные текущие ограничения, которые Stage 3 должен закрыть:
|
||||
|
||||
Проект развивается по поэтапной схеме.
|
||||
На текущей итерации реализуется только **Stage 1 / Foundation Hardening**.
|
||||
Этапы 2–6 задают forward-compatibility constraints, но не являются scope текущей реализации.
|
||||
- lifecycle-семантика остаётся частично эвристической;
|
||||
- отсутствует формализованная модель допустимых состояний/переходов по ключевым доменам;
|
||||
- problem units недостаточно насыщены temporal и stage-based смыслом;
|
||||
- ranking по ряду классов вопросов всё ещё тяготеет к frequency/sum/entity сигналам;
|
||||
- ответы местами остаются на уровне generic lifecycle labels.
|
||||
|
||||
---
|
||||
|
||||
## Цель работы Codex на текущей итерации
|
||||
|
||||
Codex должен помочь реализовать **только Stage 1**, не разрушая текущий работающий контур и не подтягивая prematurely решения из следующих этапов.
|
||||
Codex должен помочь реализовать **только Stage 3**, не разрушая текущий рабочий контур и не подтягивая prematurely решения из следующих этапов.
|
||||
|
||||
Текущая цель:
|
||||
|
||||
- усилить существующий assistant mode;
|
||||
- сделать архитектурно корректную базу для следующих этапов;
|
||||
- убрать наиболее опасные structural gaps;
|
||||
- не превращать текущий этап в скрытую реализацию Stage 2–6.
|
||||
- ввести формальную lifecycle-модель по целевым доменам Stage 3;
|
||||
- внедрить lifecycle runtime-компоненты и их использование в рабочем пути;
|
||||
- интегрировать lifecycle в problem units, ranking и answer synthesis;
|
||||
- подтвердить полезность через domain-eval и before/after проверку;
|
||||
- не превращать текущий этап в скрытую реализацию Stage 4–6.
|
||||
|
||||
---
|
||||
|
||||
@@ -74,7 +68,7 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
При чтении и интерпретации материалов использовать следующий порядок приоритета.
|
||||
|
||||
### 1. Текущий рабочий scope
|
||||
- `03_execution/STAGE_01_TASK_CARD.md`
|
||||
- `03_execution/STAGE_03_TASK_CARD.md`
|
||||
|
||||
Это главный документ по тому, что делать прямо сейчас.
|
||||
|
||||
@@ -90,12 +84,17 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
- security;
|
||||
- live bridge policy.
|
||||
|
||||
### 3. Детальное ТЗ первого этапа
|
||||
- `02_stages/stage-01-foundation-hardening.md`
|
||||
### 3. Детальное ТЗ третьего этапа
|
||||
- `02_stages/TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md`
|
||||
|
||||
Этот документ определяет содержимое Stage 1.
|
||||
Этот документ определяет содержимое Stage 3.
|
||||
|
||||
### 4. Текущий статус и общая логика развития
|
||||
### 4. Зависимости Stage 3
|
||||
- `02_stages/TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md`
|
||||
|
||||
Stage 3 опирается на problem-centric слой Stage 2 и не должен его ломать.
|
||||
|
||||
### 5. Текущий статус и общая логика развития
|
||||
- `00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`
|
||||
- `00_context/Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md`
|
||||
- `00_context/ROADMAP_endToReal.md`
|
||||
@@ -104,15 +103,13 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
Эти документы нужны для понимания:
|
||||
- что уже сделано;
|
||||
- где реальные потолки системы;
|
||||
- почему Stage 1 выполняется именно сейчас;
|
||||
- как Stage 1 стыкуется с дальнейшими этапами.
|
||||
- почему сейчас выполняется Stage 3;
|
||||
- как Stage 3 стыкуется с дальнейшими этапами.
|
||||
|
||||
### 5. Этапы 2–6
|
||||
- `02_stages/stage-02-...`
|
||||
- `02_stages/stage-03-...`
|
||||
- `02_stages/stage-04-...`
|
||||
- `02_stages/stage-05-...`
|
||||
- `02_stages/stage-06-...`
|
||||
### 6. Этапы 4–6
|
||||
- `02_stages/TZ_Stage_4_...`
|
||||
- `02_stages/TZ_Stage_5_...`
|
||||
- `02_stages/TZ_Stage_6_...`
|
||||
|
||||
Эти документы используются только как:
|
||||
- ограничители будущей совместимости;
|
||||
@@ -125,18 +122,18 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
## Scope текущей итерации
|
||||
|
||||
Разрешено делать только то, что относится к Stage 1 и необходимо для его корректной реализации.
|
||||
Разрешено делать только то, что относится к Stage 3 и необходимо для его корректной реализации.
|
||||
|
||||
К текущему scope относятся:
|
||||
|
||||
- усиление foundation layer без переписывания всей системы;
|
||||
- минимально необходимая формализация `investigation_state`;
|
||||
- усиление answer policy;
|
||||
- усиление broad-query / generic-query handling;
|
||||
- более структурное представление evidence;
|
||||
- accountant-facing metrics;
|
||||
- baseline benchmark/eval harness;
|
||||
- подготовка базы для следующих этапов без преждевременной реализации этих этапов.
|
||||
- формализация 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -144,13 +141,12 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
На этой итерации нельзя фактически реализовывать как core-runtime следующие слои:
|
||||
|
||||
- полноценный problem unit architecture из Stage 2;
|
||||
- полноценный lifecycle engine из Stage 3;
|
||||
- полноразмерный ontology / graph runtime из Stage 4;
|
||||
- investigation engine в полном виде из Stage 5;
|
||||
- полноценный investigation orchestrator из Stage 5;
|
||||
- live verification runtime core и full product mode split из Stage 6;
|
||||
- переезд на новую полную сервисную архитектуру;
|
||||
- переписывание ассистента вокруг новых abstraction layers без крайней необходимости;
|
||||
- домены, которые не поддерживаются текущими данными/evidence mapping;
|
||||
- большие инфраструктурные переделки ради “красоты”.
|
||||
|
||||
---
|
||||
@@ -158,20 +154,20 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
## Главный принцип текущей работы
|
||||
|
||||
**Не строить целевую систему раньше времени.**
|
||||
Нужно не “сразу сделать правильно всё”, а “сделать Stage 1 так, чтобы он был структурно корректен, совместим с будущими этапами и не создал новые архитектурные долги”.
|
||||
Нужно сделать Stage 3 так, чтобы lifecycle-модели были не формальными таблицами, а реально работающим runtime-слоем и базой для следующих этапов.
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие архитектурные ограничения
|
||||
|
||||
### 1. Нельзя ломать текущий рабочий контур без прямой причины
|
||||
Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 1.
|
||||
Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 3.
|
||||
|
||||
### 2. Нельзя подменять архитектурные изменения промптами
|
||||
Проблемы state, evidence structure, eval, traceability, narrowing и boundedness не должны решаться только промптами или “умной формулировкой ответа”.
|
||||
Проблемы lifecycle-state, transition logic, defect classification, ranking integration и answer grounding не должны решаться только промптами или “умной формулировкой ответа”.
|
||||
|
||||
### 3. Нельзя преждевременно тащить Stage 2–6 в кодовую базу
|
||||
Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 1.
|
||||
### 3. Нельзя преждевременно тащить Stage 4–6 в кодовую базу
|
||||
Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 3.
|
||||
|
||||
### 4. Нельзя делать большие рефакторы ради абстрактной чистоты
|
||||
Разрешены только те изменения, которые:
|
||||
@@ -179,23 +175,15 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
- повышают устойчивость текущего слоя;
|
||||
- не разрушают траекторию дальнейшего развития.
|
||||
|
||||
### 5. Все новые сущности должны быть future-compatible
|
||||
Любые новые:
|
||||
- типы,
|
||||
- storage contracts,
|
||||
- runtime state contracts,
|
||||
- evidence models,
|
||||
- metric payloads,
|
||||
- trace structures
|
||||
### 5. Каждый lifecycle-элемент обязан иметь полный контур реализации
|
||||
Для каждого lifecycle-элемента должны существовать:
|
||||
- spec-level описание;
|
||||
- runtime-level вычисление;
|
||||
- retrieval/ranking-level использование;
|
||||
- answer-level интерпретация.
|
||||
|
||||
должны проектироваться так, чтобы не конфликтовать со следующими этапами.
|
||||
|
||||
### 6. Нельзя маскировать structural gaps perceived-quality улучшениями
|
||||
Недопустимо заменять структурное решение:
|
||||
- более длинным ответом,
|
||||
- более “умным” summarization,
|
||||
- более агрессивной промптовой маршрутизацией,
|
||||
- косметическим улучшением вывода.
|
||||
### 6. Нельзя вводить состояния и дефекты без evidence mapping
|
||||
Если состояние/переход/дефект нельзя определить по реально доступным данным, его нельзя вводить как runtime-элемент Stage 3.
|
||||
|
||||
---
|
||||
|
||||
@@ -207,14 +195,14 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
Сначала изучить:
|
||||
- текущий статус;
|
||||
- platform core ТЗ;
|
||||
- Stage 1;
|
||||
- Stage 3;
|
||||
- зависимость от Stage 2;
|
||||
- roadmap;
|
||||
- контекст следующих этапов.
|
||||
|
||||
### Шаг B. Анализ текущего кода
|
||||
До внесения изменений определить:
|
||||
- какие части системы уже существуют;
|
||||
- какие из требований Stage 1 уже частично реализованы;
|
||||
- какие части lifecycle already/partially реализованы;
|
||||
- где находятся реальные точки расширения;
|
||||
- какие элементы являются хрупкими;
|
||||
- какие изменения потребуют новых contracts;
|
||||
@@ -233,7 +221,7 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
Только после плана переходить к реализации.
|
||||
|
||||
Изменения должны вноситься малыми порциями, чтобы можно было проверить:
|
||||
- не вышел ли scope за Stage 1;
|
||||
- не вышел ли scope за Stage 3;
|
||||
- не сломан ли текущий контур;
|
||||
- не появились ли premature abstractions.
|
||||
|
||||
@@ -255,20 +243,20 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
### 1. Summary текущего состояния
|
||||
Краткое описание того, как текущая реализация устроена по коду.
|
||||
|
||||
### 2. Gap analysis относительно Stage 1
|
||||
Перечень того, чего не хватает для соответствия Stage 1.
|
||||
### 2. Gap analysis относительно Stage 3
|
||||
Перечень того, чего не хватает для соответствия Stage 3.
|
||||
|
||||
### 3. Предлагаемый file-level plan
|
||||
Какие файлы нужно менять, создавать или расширять.
|
||||
|
||||
### 4. Предлагаемые contracts / types / schemas
|
||||
Какие сущности и интерфейсы появятся.
|
||||
Какие lifecycle-сущности и интерфейсы появятся.
|
||||
|
||||
### 5. Test plan
|
||||
Какие тесты будут добавлены или обновлены.
|
||||
|
||||
### 6. Acceptance mapping
|
||||
Какие критерии Stage 1 покрываются какими изменениями.
|
||||
Какие критерии Stage 3 покрываются какими изменениями.
|
||||
|
||||
### 7. Explicit non-scope
|
||||
Что сознательно не будет делаться сейчас.
|
||||
@@ -284,7 +272,7 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
1. Что было проанализировано
|
||||
2. Что обнаружено
|
||||
3. Что предлагается изменить
|
||||
4. Почему это соответствует Stage 1
|
||||
4. Почему это соответствует Stage 3
|
||||
5. Что не входит в текущий scope
|
||||
6. Какие файлы затрагиваются
|
||||
7. Какие риски есть
|
||||
@@ -295,7 +283,7 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
- это локальное изменение или системное;
|
||||
- ломает ли оно обратную совместимость;
|
||||
- требует ли миграции;
|
||||
- влияет ли на transport / routing / state / answer composition;
|
||||
- влияет ли на transport / routing / problem assembly / ranking / answer composition;
|
||||
- как это соотносится с будущими этапами.
|
||||
|
||||
---
|
||||
@@ -307,21 +295,22 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
### 2. Явные contracts
|
||||
Всё, что касается:
|
||||
- state,
|
||||
- evidence,
|
||||
- traceability,
|
||||
- metrics,
|
||||
- runtime decisions
|
||||
- lifecycle states/transitions/defects;
|
||||
- lifecycle resolution;
|
||||
- enrichment contracts;
|
||||
- ranking factors;
|
||||
- answer interpretation;
|
||||
- quality metrics
|
||||
|
||||
должно оформляться через явные контракты, а не “как получится по месту”.
|
||||
|
||||
### 3. Контролируемая расширяемость
|
||||
Расширяемость допустима, но только в той мере, в которой она:
|
||||
- реально нужна Stage 1;
|
||||
- реально нужна Stage 3;
|
||||
- не заставляет внедрять всю будущую архитектуру заранее.
|
||||
|
||||
### 4. Наблюдаемость изменений
|
||||
Если добавляется новая логика, нужно продумать:
|
||||
Если добавляется новая lifecycle-логика, нужно продумать:
|
||||
- как она тестируется;
|
||||
- как она логируется;
|
||||
- как проверяется её корректность;
|
||||
@@ -340,15 +329,13 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
Следующие действия считаются ошибочными:
|
||||
|
||||
- попытка “сразу построить конечную архитектуру”;
|
||||
- внедрение лишних сервисов без необходимости;
|
||||
- скрытая реализация future-stage логики под видом Stage 1;
|
||||
- замена structural fixes косметикой;
|
||||
- “красивые lifecycle-таблицы” без рабочего resolver;
|
||||
- lifecycle-поля в логах без влияния на ranking/answer;
|
||||
- ответы вида “broken_lifecycle” без state/transition логики;
|
||||
- скрытая реализация Stage 4–6 под видом Stage 3;
|
||||
- создание новых абстракций без runtime-пользы;
|
||||
- переписывание рабочего контура ради абстрактной чистоты;
|
||||
- смешивание temporary workaround и target architecture без явной маркировки;
|
||||
- неявное изменение scope;
|
||||
- неконтролируемая генерация “умных” helper layers;
|
||||
- перенос ответственности за структурный пробел в prompt layer.
|
||||
|
||||
---
|
||||
@@ -357,14 +344,12 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
Если в процессе работы появляется одно или несколько из следующих явлений, нужно остановиться и пересобрать plan:
|
||||
|
||||
- предлагается большой platform refactor для реализации Stage 1;
|
||||
- предлагается новая архитектура вместо усиления текущей;
|
||||
- в код начинают подтягиваться сущности из Stages 4–6 как обязательные;
|
||||
- вводятся новые сервисы, не дающие прямой пользы на текущем шаге;
|
||||
- “для удобства” переписывается base loop;
|
||||
- проблема объясняется как решаемая чисто промптом;
|
||||
- предлагается сложный orchestrator без прямой необходимости;
|
||||
- формируется новый data model слой без связи с acceptance criteria Stage 1.
|
||||
- предлагается graph runtime как обязательный путь Stage 3;
|
||||
- предлагается full investigation orchestration для “удобства”;
|
||||
- lifecycle-модели проектируются без data/evidence mapping;
|
||||
- ranking и answer не получают lifecycle-интеграцию;
|
||||
- для Stage 3 предлагается большой platform refactor;
|
||||
- формируется новый data model слой без связи с acceptance criteria Stage 3.
|
||||
|
||||
---
|
||||
|
||||
@@ -372,24 +357,24 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
Текущая волна считается завершённой только если выполнены одновременно все условия:
|
||||
|
||||
1. Реализован scope Stage 1, а не произвольный “улучшенный вариант”.
|
||||
1. Реализован scope Stage 3, а не произвольный “улучшенный вариант”.
|
||||
2. Текущий рабочий контур не разрушен.
|
||||
3. Новые state / evidence / metrics contracts описаны явно.
|
||||
3. Новые lifecycle contracts описаны явно.
|
||||
4. Есть тесты и/или проверяемые критерии для внесённых изменений.
|
||||
5. Нет скрытого уезда в Stage 2–6.
|
||||
5. Нет скрытого уезда в Stage 4–6.
|
||||
6. Изменения совместимы с platform core ТЗ.
|
||||
7. Зафиксировано, что сознательно осталось за пределами текущего этапа.
|
||||
|
||||
---
|
||||
|
||||
## Практическая цель первой итерации
|
||||
## Практическая цель текущей итерации
|
||||
|
||||
Первая итерация должна дать не “идеальную новую систему”, а следующий результат:
|
||||
Текущая итерация должна дать следующий результат:
|
||||
|
||||
- структурно усиленный assistant mode;
|
||||
- минимальную, но реальную формализацию foundation gaps;
|
||||
- снижение зависимости от неявной логики и ad hoc поведения;
|
||||
- более стабильную базу для перехода к следующим этапам.
|
||||
- lifecycle-aware problem reasoning вместо generic lifecycle labels;
|
||||
- stage/transition-aware ranking на covered-доменах;
|
||||
- более прикладные ответы по сценариям 51/60, 97, ОС, НДС и period close;
|
||||
- рабочий lifecycle runtime-контур, пригодный для дальнейшего развития.
|
||||
|
||||
---
|
||||
|
||||
@@ -409,6 +394,6 @@ Codex должен помочь реализовать **только Stage 1**,
|
||||
|
||||
Главный вопрос перед любым изменением:
|
||||
|
||||
**Это действительно необходимо для Stage 1, или это попытка преждевременно реализовать следующий этап?**
|
||||
**Это действительно необходимо для Stage 3, или это попытка преждевременно реализовать Stage 4–6?**
|
||||
|
||||
Если ответ неочевиден, изменение откладывается и выносится на отдельное согласование.
|
||||
Если ответ неочевиден, изменение откладывается и выносится на отдельное согласование.
|
||||
|
||||
@@ -0,0 +1,446 @@
|
||||
# STAGE_03_TASK_CARD
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ фиксирует **рабочий scope третьей итерации реализации** для Codex и разработчика.
|
||||
Документ не заменяет Stage 3 ТЗ и не заменяет platform core ТЗ.
|
||||
Его задача — перевести третий этап в **практический implementation scope**, который можно брать в работу без расползания в следующие этапы.
|
||||
|
||||
Документ должен использоваться как основной рабочий ориентир при реализации Stage 3.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: рабочая карта реализации Stage 3
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к прочтению перед любыми изменениями по Stage 3
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- При конфликте по общему режиму работы Codex приоритет имеет `CODEX_MASTER_BRIEF.md`
|
||||
|
||||
---
|
||||
|
||||
## Контекст
|
||||
|
||||
Текущий бухгалтерский ассистент уже работает на уровне функционального MVP+ и после Stage 2 умеет поднимать problem-centric units.
|
||||
При этом система ещё не умеет стабильно объяснять проблему как нарушение ожидаемого жизненного цикла объекта.
|
||||
|
||||
На текущем этапе нужно **не перестроить ассистента целиком**, а **ввести рабочий lifecycle knowledge layer**, чтобы:
|
||||
|
||||
- формально описать состояния и переходы по целевым доменам;
|
||||
- вычислять current/expected state на runtime-данных;
|
||||
- классифицировать lifecycle-дефекты;
|
||||
- обогащать problem units lifecycle-смыслом;
|
||||
- улучшить ranking и ответы по логике стадии/перехода;
|
||||
- не тащить prematurely графовое ядро и full investigation engine.
|
||||
|
||||
---
|
||||
|
||||
## Цель Stage 3
|
||||
|
||||
Stage 3 должен дать **lifecycle-aware reasoning слой**, не ломая текущий рабочий контур.
|
||||
|
||||
Практический результат этапа:
|
||||
|
||||
- formal lifecycle models для целевых доменов;
|
||||
- `LifecycleRegistry` как единый source of truth по lifecycle;
|
||||
- `LifecycleResolver` и `LifecycleDefectClassifier` в runtime;
|
||||
- `LifecycleEnricher` для problem units;
|
||||
- lifecycle-aware ranking factors;
|
||||
- lifecycle-aware answer policy;
|
||||
- benchmark/eval контур с before/after evidence по ключевым сценариям.
|
||||
|
||||
---
|
||||
|
||||
## Scope текущей реализации
|
||||
|
||||
В рамках Stage 3 разрешено реализовывать только то, что необходимо для lifecycle formalization.
|
||||
|
||||
### В scope входят
|
||||
|
||||
1. **Формализация lifecycle-доменов**
|
||||
- фиксация domain registry;
|
||||
- описание lifecycle objects нужного масштаба;
|
||||
- описание states/transitions/defects с business-смыслом;
|
||||
- обязательный evidence mapping для каждого элемента.
|
||||
|
||||
2. **Runtime-слой lifecycle-разрешения**
|
||||
- компонент `LifecycleRegistry`;
|
||||
- компонент `LifecycleResolver`;
|
||||
- компонент `LifecycleDefectClassifier`;
|
||||
- компонент `LifecycleEnricher`.
|
||||
|
||||
3. **Интеграция lifecycle в problem units**
|
||||
- расширение `problem_unit_schema` lifecycle-полями;
|
||||
- обогащение unit на runtime-пути;
|
||||
- поддержка confidence и snapshot limitations.
|
||||
|
||||
4. **Интеграция lifecycle в ranking**
|
||||
- добавление lifecycle-based факторов;
|
||||
- усиление веса stale/period-impact/cross-branch дефектов по релевантным вопросам;
|
||||
- снижение зависимости ranking только от суммы/объёма.
|
||||
|
||||
5. **Интеграция lifecycle в answer layer**
|
||||
- переход на объяснение через current state, expected state и transition logic;
|
||||
- явная связь вывода с evidence;
|
||||
- пользовательский next step по месту lifecycle-разрыва.
|
||||
|
||||
6. **Quality контур Stage 3**
|
||||
- lifecycle resolution tests;
|
||||
- defect classification tests;
|
||||
- lifecycle-aware explanation tests;
|
||||
- benchmark suite по covered domains;
|
||||
- before/after eval report.
|
||||
|
||||
---
|
||||
|
||||
## Что не входит в scope
|
||||
|
||||
Следующие вещи **не должны** реализовываться в рамках Stage 3 как core-runtime.
|
||||
|
||||
### Не делать сейчас
|
||||
|
||||
- полный ontology graph runtime из Stage 4;
|
||||
- полный rule engine по всем типам учёта;
|
||||
- full investigation orchestrator из Stage 5;
|
||||
- live verification core runtime из Stage 6;
|
||||
- full product mode split `direct / investigation / audit`;
|
||||
- универсальную state machine для всей 1С;
|
||||
- большой platform refactor ради будущего масштаба;
|
||||
- замену structural lifecycle-решений косметическими prompt-улучшениями.
|
||||
|
||||
---
|
||||
|
||||
## Обязательные результаты этапа
|
||||
|
||||
По завершении Stage 3 в системе должны появиться следующие результаты.
|
||||
|
||||
### 1. Рабочие lifecycle-модели по целевым доменам
|
||||
Должны существовать formal-модели как минимум по доменам Stage 3:
|
||||
|
||||
- `bank_settlement`;
|
||||
- `customer_settlement`;
|
||||
- `deferred_expense`;
|
||||
- `fixed_asset`;
|
||||
- `vat_flow`;
|
||||
- `period_close`.
|
||||
|
||||
### 2. Рабочий lifecycle runtime
|
||||
Должен существовать runtime-контур, который:
|
||||
|
||||
- определяет `current_lifecycle_state`;
|
||||
- определяет `expected_lifecycle_state`;
|
||||
- находит `missing_transition` и `invalid_transition`;
|
||||
- классифицирует lifecycle-дефект;
|
||||
- отдаёт `lifecycle_confidence` и `snapshot_limitations`.
|
||||
|
||||
### 3. Lifecycle-enriched problem units
|
||||
Problem units должны стать lifecycle-aware и включать:
|
||||
|
||||
- lifecycle domain;
|
||||
- lifecycle object;
|
||||
- stage/transition интерпретацию;
|
||||
- defect-type;
|
||||
- business lifecycle interpretation.
|
||||
|
||||
### 4. Lifecycle-aware ranking
|
||||
Ranking должен учитывать lifecycle severity и не сводиться к entities/sum/count.
|
||||
|
||||
### 5. Lifecycle-aware ответы
|
||||
Ответы должны объяснять проблему через логику стадии и перехода, а не через generic labels.
|
||||
|
||||
### 6. Измеримость ценности
|
||||
Должны быть тесты, benchmark и before/after отчёт, подтверждающие улучшение на ключевых сценариях.
|
||||
|
||||
---
|
||||
|
||||
## Рабочие deliverables от Codex
|
||||
|
||||
Codex должен вернуть не только код, но и набор артефактов.
|
||||
|
||||
### Обязательные deliverables
|
||||
|
||||
1. **Gap analysis по Stage 3**
|
||||
- чего не хватает в текущем коде;
|
||||
- что уже есть частично;
|
||||
- где точки внедрения.
|
||||
|
||||
2. **Implementation plan**
|
||||
- какие компоненты меняются;
|
||||
- какие файлы меняются;
|
||||
- какие сущности появляются;
|
||||
- что остаётся нетронутым.
|
||||
|
||||
3. **Новые или обновлённые contracts / types / schemas**
|
||||
- для lifecycle models;
|
||||
- для lifecycle resolution;
|
||||
- для enriched problem units;
|
||||
- для ranking и answer policy;
|
||||
- для eval/metrics.
|
||||
|
||||
4. **Кодовые изменения**
|
||||
- малыми контролируемыми порциями;
|
||||
- без скрытого выезда в Stage 4–6.
|
||||
|
||||
5. **Test / eval changes**
|
||||
- unit / integration / regression checks;
|
||||
- benchmark updates;
|
||||
- before/after проверка ценности.
|
||||
|
||||
6. **Итоговый отчёт по волне**
|
||||
- что сделано;
|
||||
- что не сделано сознательно;
|
||||
- какие риски остались;
|
||||
- что подготовлено для Stage 4.
|
||||
|
||||
---
|
||||
|
||||
## Ожидаемые сущности Stage 3
|
||||
|
||||
Ниже — минимальный набор сущностей, который должен быть введён или формализован.
|
||||
|
||||
### 1. LifecycleDomain
|
||||
Примерный состав:
|
||||
- `domain_code`
|
||||
- `domain_label`
|
||||
- `supported_object_types`
|
||||
- `required_evidence_signals`
|
||||
|
||||
### 2. LifecycleObject
|
||||
Примерный состав:
|
||||
- `lifecycle_object_id`
|
||||
- `lifecycle_object_type`
|
||||
- `lifecycle_domain`
|
||||
- `source_entities`
|
||||
- `period_context`
|
||||
- `account_context`
|
||||
- `document_context`
|
||||
|
||||
### 3. LifecycleState
|
||||
Примерный состав:
|
||||
- `state_code`
|
||||
- `state_label`
|
||||
- `state_class`
|
||||
- `entry_conditions`
|
||||
- `exit_conditions`
|
||||
- `is_terminal`
|
||||
- `is_problematic`
|
||||
- `business_meaning`
|
||||
|
||||
### 4. LifecycleTransition
|
||||
Примерный состав:
|
||||
- `from_state`
|
||||
- `to_state`
|
||||
- `transition_type`
|
||||
- `required_evidence`
|
||||
- `optional_evidence`
|
||||
- `forbidden_conditions`
|
||||
- `business_meaning`
|
||||
|
||||
### 5. LifecycleDefect
|
||||
Примерный состав:
|
||||
- `defect_code`
|
||||
- `defect_class`
|
||||
- `severity_hint`
|
||||
- `business_meaning`
|
||||
- `evidence_requirements`
|
||||
- `period_impact_potential`
|
||||
|
||||
### 6. LifecycleResolution
|
||||
Примерный состав:
|
||||
- `lifecycle_object_id`
|
||||
- `resolved_current_state`
|
||||
- `resolved_expected_state`
|
||||
- `resolved_previous_states`
|
||||
- `missing_transitions`
|
||||
- `invalid_transitions`
|
||||
- `detected_defects`
|
||||
- `state_confidence`
|
||||
- `resolution_evidence`
|
||||
- `snapshot_limitations`
|
||||
|
||||
### 7. LifecycleEnrichedProblemUnit
|
||||
Примерный состав:
|
||||
- `problem_unit_id`
|
||||
- `problem_unit_type`
|
||||
- `lifecycle_domain`
|
||||
- `current_lifecycle_state`
|
||||
- `expected_lifecycle_state`
|
||||
- `lifecycle_defect_type`
|
||||
- `missing_transition`
|
||||
- `invalid_transition`
|
||||
- `stale_duration`
|
||||
- `lifecycle_confidence`
|
||||
- `business_lifecycle_interpretation`
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие implementation-ограничения
|
||||
|
||||
### 1. Не трогать без необходимости
|
||||
Без прямой нужды не переписывать:
|
||||
- transport layer;
|
||||
- endpoint layer;
|
||||
- base routing;
|
||||
- normalizer pipeline;
|
||||
- рабочий retrieval flow.
|
||||
|
||||
### 2. Не внедрять будущие этапы скрыто
|
||||
Если предлагаемое изменение:
|
||||
- требует полноразмерного graph runtime;
|
||||
- требует full investigation orchestration;
|
||||
- требует live verification core path,
|
||||
|
||||
то оно не относится к Stage 3 и должно быть отложено.
|
||||
|
||||
### 3. Не моделировать абстрактные состояния
|
||||
Каждое состояние, переход и дефект должны быть распознаваемы по доступным данным.
|
||||
|
||||
### 4. Не отделять lifecycle от runtime
|
||||
Lifecycle считается внедрённым только если используется в resolver, ranking и answer layer.
|
||||
|
||||
### 5. Не подменять lifecycle ценность красивым текстом
|
||||
Смысл Stage 3 — в структурном reasoning, а не в более длинной формулировке ответа.
|
||||
|
||||
---
|
||||
|
||||
## Порядок работы по Stage 3
|
||||
|
||||
### Шаг 1. Прочитать материалы
|
||||
Обязательно прочитать:
|
||||
- `CODEX_MASTER_BRIEF.md`
|
||||
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- `TZ_Stage_3_Lifecycle_Formalization_Assistant_Mode.md`
|
||||
- `TZ_Stage_2_Retrieval_Unit_Shift_Assistant_Mode.md`
|
||||
- status documents
|
||||
- roadmap
|
||||
|
||||
### Шаг 2. Сделать code-level mapping
|
||||
Нужно определить:
|
||||
- где находится текущий lifecycle/signal extraction слой;
|
||||
- где собирается problem unit;
|
||||
- где формируется ranking;
|
||||
- где формируется финальный answer;
|
||||
- где безопасно подключать lifecycle runtime;
|
||||
- где подключать benchmark/eval.
|
||||
|
||||
### Шаг 3. Подготовить plan без кода
|
||||
До начала реализации Codex должен выдать:
|
||||
- gap analysis;
|
||||
- file-level plan;
|
||||
- список новых контрактов;
|
||||
- список новых тестов;
|
||||
- список non-scope.
|
||||
|
||||
### Шаг 4. Реализовывать малыми волнами
|
||||
Рекомендуемая последовательность:
|
||||
|
||||
#### Волна 1
|
||||
- спецификация lifecycle domains/states/transitions/defects;
|
||||
- контракт registry.
|
||||
|
||||
#### Волна 2
|
||||
- внедрение `LifecycleRegistry` и `LifecycleResolver`.
|
||||
|
||||
#### Волна 3
|
||||
- внедрение `LifecycleDefectClassifier` и `LifecycleEnricher`.
|
||||
|
||||
#### Волна 4
|
||||
- интеграция lifecycle в `problem_unit_schema` и ranking.
|
||||
|
||||
#### Волна 5
|
||||
- интеграция lifecycle в answer layer.
|
||||
|
||||
#### Волна 6
|
||||
- benchmark, before/after eval, acceptance mapping.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
Stage 3 считается закрытым только если выполнены все критерии ниже.
|
||||
|
||||
### A. По моделям
|
||||
- для каждого целевого домена есть formal lifecycle model;
|
||||
- states/transitions/defects описаны и привязаны к данным;
|
||||
- lifecycle-модели не висят отдельно от runtime.
|
||||
|
||||
### B. По runtime
|
||||
- реализован lifecycle resolver;
|
||||
- problem units реально обогащаются lifecycle-полями;
|
||||
- defects вычисляются автоматически по retrieval data.
|
||||
|
||||
### C. По ranking
|
||||
- lifecycle severity влияет на ranking;
|
||||
- stale и period-impact defects поднимаются выше при релевантных вопросах;
|
||||
- ranking больше не сводится к объёму и сумме.
|
||||
|
||||
### D. По ответу
|
||||
- ответы по covered domains объясняют проблему через state/transition logic;
|
||||
- generic lifecycle labels уходят на второй план;
|
||||
- пользователю понятно, какая стадия нарушена.
|
||||
|
||||
### E. По ценности
|
||||
- на сценариях 51/60, 97, ОС, НДС и period close ответы становятся глубже;
|
||||
- система различает `stalled`, `misclosed`, `not yet completed`, `contradicted`.
|
||||
|
||||
### F. По защите от формализма
|
||||
- для каждого lifecycle domain есть working examples;
|
||||
- есть benchmark cases;
|
||||
- есть связка `spec -> runtime -> retrieval -> answer`.
|
||||
|
||||
---
|
||||
|
||||
## Что Codex обязан явно указать в конце работы
|
||||
|
||||
В финальном отчёте по Stage 3 обязательно должны быть разделы:
|
||||
|
||||
1. Что было сделано
|
||||
2. Какие файлы изменены
|
||||
3. Какие новые сущности введены
|
||||
4. Какие тесты добавлены
|
||||
5. Какие acceptance criteria закрыты
|
||||
6. Что сознательно НЕ реализовано
|
||||
7. Какие риски и ограничения остались
|
||||
8. Что подготовлено для Stage 4
|
||||
|
||||
---
|
||||
|
||||
## Красные флаги
|
||||
|
||||
Если в ходе работы появляется одно из следующего, реализацию нужно остановить и пересобрать plan:
|
||||
|
||||
- lifecycle описан только на уровне документации;
|
||||
- resolver не влияет на problem unit, ranking и answer;
|
||||
- ответы остаются на generic labels;
|
||||
- состояние нельзя определить по реальным данным;
|
||||
- предлагается ранний graph-first runtime;
|
||||
- предлагается full investigation engine;
|
||||
- ради Stage 3 предлагается большой рефактор transport/routing.
|
||||
|
||||
---
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Stage 3 завершён, если одновременно соблюдены все условия:
|
||||
|
||||
- lifecycle formalization реализована как рабочий runtime-слой;
|
||||
- problem units стали lifecycle-aware;
|
||||
- ranking учитывает lifecycle-дефекты по смыслу вопроса;
|
||||
- ответы строятся на state/transition логике;
|
||||
- есть benchmark и before/after подтверждение ценности;
|
||||
- текущий рабочий контур не разрушен;
|
||||
- нет premature implementation из Stage 4–6.
|
||||
|
||||
---
|
||||
|
||||
## Короткая практическая формула этапа
|
||||
|
||||
**Stage 3 = переход от problem-centric retrieval к lifecycle-aware accounting reasoning.**
|
||||
|
||||
Нужно получить не просто новые labels, а рабочую способность системы объяснять:
|
||||
|
||||
- где объект находится сейчас;
|
||||
- куда он должен был перейти;
|
||||
- какой переход не произошёл или произошёл неверно;
|
||||
- почему это бухгалтерски важно именно в контексте периода и домена.
|
||||
Reference in New Issue
Block a user