# 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.
