ACCEPTANCE_CHECKLIST_STAGE_01.md

# ACCEPTANCE_CHECKLIST_STAGE_01

## Назначение документа

Этот документ используется для приёмки первой волны реализации Stage 1.  
Его задача — не проверить “что-то поменялось”, а убедиться, что:

- foundation layer действительно усилен;
- текущий scope не расползся;
- structural gaps реально закрыты;
- изменения не маскируют проблемы косметикой;
- заложена корректная база для следующих этапов.

Документ обязателен для:
- Codex;
- разработчика;
- ручного review;
- финальной фиксации результата по Stage 1.

---

## Статус документа

- Статус: чеклист приёмки Stage 1
- Язык: русский
- Режим использования: обязателен при завершении каждой волны и при финальной приёмке Stage 1
- При конфликте по scope приоритет имеет `STAGE_01_TASK_CARD.md`
- При конфликте по архитектурным ограничениям приоритет имеет `ARCHITECTURE_GUARDRAILS.md`
- При конфликте по platform logic приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`

---

## Правила оценки

Для каждого пункта допускаются только следующие статусы:

- `PASS` — выполнено полностью
- `PARTIAL` — выполнено частично, требуется доработка
- `FAIL` — не выполнено
- `N/A` — не применимо, только если это действительно обосновано

Для каждого пункта должен быть указан комментарий:
- что проверялось;
- где это реализовано;
- чем подтверждается;
- какие ограничения остались.

---

## Общая логика приёмки

Stage 1 считается принятым только если одновременно соблюдены условия:

1. Закрыт именно Stage 1, а не “произвольный улучшенный вариант”.
2. Текущий рабочий контур не разрушен.
3. Есть минимальный формальный `investigation_state`.
4. Есть улучшение broad/generic question handling.
5. Evidence стало более структурным.
6. Ответы стали полезнее для бухгалтерского сценария.
7. Есть baseline eval / benchmark harness.
8. Есть accountant-facing метрики.
9. Нет скрытого выезда в Stage 2–6.
10. Изменения совместимы с platform core.

Если хотя бы один из этих пунктов провален, Stage 1 не считается завершённым.

---

# Блок A. Scope discipline

## A1. Реализован именно Stage 1
Статус:  
Комментарий:

Проверка:
- реализованы только foundation-hardening изменения;
- не добавлена скрытая логика следующих этапов;
- улучшения соответствуют текущему scope.

Критерии PASS:
- все ключевые изменения относятся к Stage 1;
- нет “заодно реализованных” future-stage подсистем.

---

## A2. Нет скрытого выезда в Stage 2
Статус:  
Комментарий:

Проверка:
- не внедрён полноценный `problem unit architecture`;
- нет полной смены retrieval unit model;
- нет явного runtime problem decomposition как core path.

Критерии PASS:
- максимум заложена совместимость;
- полноценный Stage 2 runtime не реализован.

---

## A3. Нет скрытого выезда в Stage 3
Статус:  
Комментарий:

Проверка:
- не внедрён lifecycle engine;
- нет полноценной дефектной/событийной модели lifecycle как core path;
- нет ранней формализации состояния документа/процесса на уровне Stage 3.

Критерии PASS:
- lifecycle как будущий слой не реализован.

---

## A4. Нет скрытого выезда в Stage 4
Статус:  
Комментарий:

Проверка:
- не внедрён полноценный ontology/graph runtime;
- не добавлена тяжёлая graph-логика как обязательный путь ответа;
- не построен graph-first core.

Критерии PASS:
- graph runtime отсутствует;
- максимум есть совместимые контракты, но не core-layer.

---

## A5. Нет скрытого выезда в Stage 5
Статус:  
Комментарий:

Проверка:
- не внедрён full investigation engine;
- нет полноценного branching case-runtime;
- нет сложного bounded investigation orchestration.

Критерии PASS:
- присутствует только minimal `investigation_state`, а не full engine.

---

## A6. Нет скрытого выезда в Stage 6
Статус:  
Комментарий:

Проверка:
- не внедрён live verification core;
- нет product mode split `direct / investigation / audit` как основного runtime;
- нет полноценного trust-state live contour.

Критерии PASS:
- Stage 6 логика не реализована как текущий рабочий слой.

---

## A7. Не выполнен большой ненужный рефактор
Статус:  
Комментарий:

Проверка:
- не переписан transport layer без необходимости;
- не переписан endpoint layer без необходимости;
- не переписан base routing без необходимости;
- не переписан assistant loop ради архитектурной красоты.

Критерии PASS:
- изменения локальны и обоснованы;
- рабочий контур сохранён.

---

# Блок B. Investigation state

## B1. Введён явный минимальный `investigation_state`
Статус:  
Комментарий:

Проверка:
- существует отдельная state-сущность или эквивалентный контракт;
- state не размазан по случайным переменным;
- state не заменён chat history.

Критерии PASS:
- есть явный минимальный state layer;
- его поля и правила обновления понятны.

---

## B2. `investigation_state` реально используется
Статус:  
Комментарий:

Проверка:
- state участвует в follow-up логике;
- state влияет на обработку продолжения разговора;
- state не является “мёртвой” сущностью.

Критерии PASS:
- есть реальные runtime-точки использования;
- поведение follow-up отличается от наивной одношаговой обработки.

---

## B3. `investigation_state` bounded и минимален
Статус:  
Комментарий:

Проверка:
- state не пытается хранить всё подряд;
- нет скрытого full case-engine;
- state ограничен по назначению.

Критерии PASS:
- state минимален, но полезен;
- state не превращён в premature investigation runtime.

---

## B4. `investigation_state` future-compatible
Статус:  
Комментарий:

Проверка:
- структура state не конфликтует с будущим Stage 5;
- контракты не тупиковые;
- state можно расширить без полного слома.

Критерии PASS:
- заложена совместимость без premature implementation.

---

# Блок C. Broad / generic query handling

## C1. Выявление broad/generic questions стало явным
Статус:  
Комментарий:

Проверка:
- система различает широкий, недоопределённый и достаточно конкретный вопрос;
- broadness не определяется только постфактум красивым ответом.

Критерии PASS:
- есть явная логика или критерии определения broad/generic запросов.

---

## C2. Появился controlled narrowing
Статус:  
Комментарий:

Проверка:
- система умеет сузить вопрос;
- либо умеет зафиксировать, что вопрос слишком общий;
- либо предлагает следующий прикладной шаг.

Критерии PASS:
- broad-вопрос не приводит автоматически к слабому общему ответу;
- narrowing выполняется или честно сигнализируется.

---

## C3. Generic-answer rate снизился
Статус:  
Комментарий:

Проверка:
- по контрольному набору кейсов доля “общих, малооперабельных” ответов уменьшилась;
- это подтверждается eval/ручным review.

Критерии PASS:
- улучшение заметно и измеримо;
- это не только субъективное ощущение.

---

## C4. Улучшение broad-handling не сводится к prompt-only
Статус:  
Комментарий:

Проверка:
- есть структурные изменения в логике;
- не всё улучшение сделано за счёт переписывания системного промпта.

Критерии PASS:
- prompt может помогать, но не является единственным решением.

---

# Блок D. Evidence structure

## D1. Evidence больше не является просто текстовым пересказом
Статус:  
Комментарий:

Проверка:
- evidence имеет отдельную структуру или явные поля;
- evidence не существует только как часть prose-ответа.

Критерии PASS:
- evidence выделено как отдельный элемент логики/контракта.

---

## D2. У evidence есть источник / происхождение
Статус:  
Комментарий:

Проверка:
- для evidence фиксируется source_type / source_ref / pointer или эквивалент;
- источник не теряется при сборке ответа.

Критерии PASS:
- происхождение каждого значимого evidence можно проследить.

---

## D3. У evidence есть связь с утверждением
Статус:  
Комментарий:

Проверка:
- ответные утверждения опираются на конкретные evidence items;
- нет ситуации, где вывод существует отдельно от опоры.

Критерии PASS:
- связка claim ↔ evidence читаема и проверяема.

---

## D4. У evidence есть механизм/основание
Статус:  
Комментарий:

Проверка:
- система показывает не только “что найдено”, но и “почему это подтверждает вывод”;
- есть mechanism note / reason / basis или эквивалент.

Критерии PASS:
- объяснение перестаёт быть чисто декларативным.

---

## D5. У evidence есть честная ограниченность / confidence
Статус:  
Комментарий:

Проверка:
- степень уверенности или ограниченности не скрыта;
- не создаётся ложная определённость.

Критерии PASS:
- uncertainty явно видна;
- слабая опора не маскируется уверенным тоном.

---

# Блок E. Answer quality

## E1. Ответ стал полезнее для бухгалтерского сценария
Статус:  
Комментарий:

Проверка:
- ответы стали более прикладными;
- пользователь понимает, что найдено, на чём основано и что делать дальше;
- ответ не ограничивается пересказом данных.

Критерии PASS:
- manual review показывает явный рост операбельности ответов.

---

## E2. Ответ стал более дисциплинированным по структуре
Статус:  
Комментарий:

Проверка:
- различаются summary, direct answer, evidence, uncertainty, next step или эквивалент;
- ответ не разваливается в свободный текст.

Критерии PASS:
- есть управляемая и повторяемая структура ответа.

---

## E3. Недостаток данных обрабатывается честно
Статус:  
Комментарий:

Проверка:
- если опоры недостаточно, система не симулирует точный вывод;
- явно обозначается ограниченность;
- предлагается следующий полезный шаг.

Критерии PASS:
- honest uncertainty работает не только в теории.

---

## E4. Улучшение качества не является чисто косметическим
Статус:  
Комментарий:

Проверка:
- улучшение связано с state/evidence/narrowing;
- это не просто более гладкий текст ответа.

Критерии PASS:
- answer quality опирается на structural changes.

---

# Блок F. Eval / metrics

## F1. Добавлен baseline benchmark / eval harness
Статус:  
Комментарий:

Проверка:
- существует минимальный воспроизводимый eval-контур;
- можно запускать сравнение до/после;
- можно фиксировать регрессии.

Критерии PASS:
- eval не остаётся ручной и разовой активностью.

---

## F2. Есть контрольный набор кейсов
Статус:  
Комментарий:

Проверка:
- есть набор representative вопросов;
- в набор входят broad/generic/follow-up/evidence-sensitive кейсы;
- набор пригоден для повторного запуска.

Критерии PASS:
- eval основан на зафиксированном наборе, а не на случайных примерах.

---

## F3. Появились accountant-facing метрики
Статус:  
Комментарий:

Проверка:
- измеряется не только техническая проходимость;
- есть метрики полезности ответа;
- есть метрики genericness / evidence quality / narrowing usefulness или эквиваленты.

Критерии PASS:
- продуктовая полезность стала измеримой.

---

## F4. Можно сравнить поведение до/после
Статус:  
Комментарий:

Проверка:
- есть baseline;
- есть результаты после изменений;
- можно показать, что конкретно улучшилось или ухудшилось.

Критерии PASS:
- есть сравнимость, а не просто “кажется стало лучше”.

---

## F5. Green tests не являются единственным доказательством готовности
Статус:  
Комментарий:

Проверка:
- решение не принято только на основании unit/integration success;
- есть ручной review и/или accountant-facing оценка.

Критерии PASS:
- продуктовая приёмка не подменена технической.

---

# Блок G. Observability / diagnostics

## G1. Новая логика диагностируема
Статус:  
Комментарий:

Проверка:
- можно понять, как было принято решение;
- можно увидеть, что произошло при broad-handling/state/evidence assembly;
- при сбое путь анализа не непрозрачен.

Критерии PASS:
- есть хотя бы минимальная наблюдаемость новых решений.

---

## G2. Новая логика тестируема
Статус:  
Комментарий:

Проверка:
- есть тесты или проверяемые контуры;
- критичные новые ветки поведения можно воспроизвести.

Критерии PASS:
- поведение не завязано только на ручной удачный сценарий.

---

## G3. Новые контракты описаны явно
Статус:  
Комментарий:

Проверка:
- state/evidence/eval contracts формализованы;
- их поля и назначение понятны;
- они не существуют только имплицитно в коде.

Критерии PASS:
- нет неявной архитектуры “между строк”.

---

# Блок H. Migration / compatibility

## H1. Новые сущности имеют явный source of truth
Статус:  
Комментарий:

Проверка:
- понятно, где хранится canonical form;
- понятно, что является derived form;
- нет размазанного состояния.

Критерии PASS:
- контракты и источники истины определены явно.

---

## H2. Изменения не создают тупик для будущих этапов
Статус:  
Комментарий:

Проверка:
- нет архитектурного решения, которое мешает Stage 2–6;
- не принято временное решение, выдаваемое за целевое.

Критерии PASS:
- Stage 1 усиливает основание, а не закрывает путь вперёд.

---

## H3. Обратная совместимость и миграции понятны
Статус:  
Комментарий:

Проверка:
- если появились новые контракты/хранилища/схемы, описано как они инициализируются;
- понятно, нужен ли migration step;
- понятно, что будет со старым поведением.

Критерии PASS:
- внедрение можно повторить и сопровождать без хаоса.

---

# Блок I. Documentation completeness

## I1. Есть итоговый отчёт по реализации
Статус:  
Комментарий:

Проверка:
- описано, что сделано;
- описано, какие файлы изменены;
- описано, что осталось вне scope.

Критерии PASS:
- по результату можно быстро понять состояние системы.

---

## I2. Есть acceptance mapping
Статус:  
Комментарий:

Проверка:
- для каждого ключевого изменения понятно, какой критерий Stage 1 оно закрывает;
- нет “непонятных улучшений”.

Критерии PASS:
- изменения привязаны к acceptance criteria.

---

## I3. Есть список сознательно не реализованного
Статус:  
Комментарий:

Проверка:
- явно перечислено, что не делалось сейчас;
- причины отложенных вещей зафиксированы;
- нет скрытого scope drift.

Критерии PASS:
- границы текущего этапа прозрачны.

---

# Блок J. Финальное решение по этапу

## J1. Stage 1 можно считать принятым
Статус:  
Комментарий:

Критерии PASS:
- блоки A–I не содержат критических FAIL;
- PARTIAL не влияют на core acceptance;
- foundation реально усилен.

---

## J2. Stage 1 нельзя считать принятым
Статус:  
Комментарий:

Ставится `PASS`, если выполнено хотя бы одно из условий:
- отсутствует `investigation_state`;
- broad/generic handling не улучшен по сути;
- evidence осталось неструктурированным;
- accountant-facing eval отсутствует;
- был скрытый выезд в future stages;
- рабочий контур сломан;
- изменения чисто косметические.

---

# Итоговая сводка по приёмке

## Общий итог
- Результат: `PASS / PARTIAL / FAIL`
- Дата проверки:
- Проверял:
- Версия / ветка / commit:
- Связанные документы:

---

## Ключевые сильные стороны
1.
2.
3.

---

## Ключевые недочёты
1.
2.
3.

---

## Что обязательно исправить до приёмки
1.
2.
3.

---

## Что допустимо перенести в следующий этап
1.
2.
3.

---

## Явно подтверждено как non-scope текущего этапа
1.
2.
3.

---

## Финальное решение
- `Принять Stage 1`
- `Принять Stage 1 условно`
- `Вернуть на доработку`

Комментарий:

---

# Короткая практическая формула

Stage 1 считается успешным не тогда, когда:

- код стал “чище”;
- ответы стали “приятнее”;
- тесты стали зелёными.

Stage 1 считается успешным тогда, когда одновременно:

- foundation стал структурно крепче;
- state перестал быть неявным;
- evidence перестало быть просто текстом;
- broad-вопросы стали обрабатываться дисциплинированно;
- качество стало измеримым;
- путь к следующим этапам остался открыт.