03 — Критерии приёмки (Acceptance Criteria): ORCH-076 — ORCH-52c: протокол handoff + frontmatter-контракт

Work Item: ORCH-076 · Repo: orchestrator · Стадия: analysis

Формат: каждый критерий имеет PASS (что должно быть истинно для приёмки) и FAIL (что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория. Критерии прямо отражают AC из постановки задачи (AC-1…AC-7).

AC-1 — frontmatter: reader + writer + валидатор

Условие: src/frontmatter.py несёт полный контракт.

PASS: в src/frontmatter.py есть (а) сохранённый reader read_frontmatter_value с прежним контрактом; (б) writer (запись/рендер YAML-frontmatter); (в) валидатор обязательной схемы, проверяющий поля work_item, stage, author_agent, status, created_at, model_used. Все три покрыты unit-тестами.
FAIL: отсутствует writer ИЛИ валидатор; или валидатор не проверяет полный список из 6 обязательных полей; или контракт reader сломан (изменена сигнатура/поведение).

AC-2 — спека handoff создана и согласована

Условие: формальный контракт handoff в docs/_standards/.

PASS: в docs/_standards/ создан документ-спека, где для КАЖДОЙ стадии указано, какие документы и какие frontmatter-ключи она обязана оставить на выходе; набор документов/ключей/ гейтов согласован с PIPELINE_DOCS.md §2–§3 (нет противоречий); PIPELINE_DOCS.md обновлён ссылкой на спеку и отметкой о реализации машинного контракта в ORCH-52c.
FAIL: спека отсутствует, не в docs/_standards/, покрывает не все стадии, или противоречит PIPELINE_DOCS.md (другой набор ключей/документов).

AC-3 — единый контракт вердиктов

Условие: гейты читают вердикты через единый frontmatter-API.

PASS: контракт вердиктов сведён в ОДНО место (единый frontmatter-API); все пять вердикт-точек — check_reviewer_verdict (verdict:), _parse_tests_verdict (result:/verdict:/status:), _parse_deploy_status (deploy_status:), _parse_staging_status (staging_status:), parse_security_status (security_status:) — парсят YAML-frontmatter через этот API, а не дублированной ad-hoc логикой.
FAIL: хотя бы один из пяти гейтов по-прежнему содержит собственную дублированную реализацию парсинга YAML-frontmatter вместо единого API.

AC-4 — анти-регресс: старые доки читаются, ORCH-52c проходит свои гейты (критично self-hosting)

Условие: обратная совместимость + самопрохождение.

PASS: документ-вердикт БЕЗ новой полной схемы (только с вердикт-ключом) читается гейтом ровно как до задачи (подтверждено тестом для каждого из пяти гейтов); полный регресс tests/ зелёный; сама ORCH-52c проходит свои гейты (review→testing→staging→deploy) и доезжает до done.
FAIL: любой старый док-вердикт перестал читаться/изменил вердикт; регресс tests/ красный; задача застряла/откатилась на собственном гейте из-за нового контракта.

AC-5 — never-raise + валидатор не hard-fail по умолчанию (kill-switch)

Условие: fail-safe и не-самоблокирующая валидация.

PASS: ошибка writer'а/валидатора логируется и НЕ роняет конвейер (исключение наружу не выходит, подтверждено тестом на битом вводе); валидация обязательной схемы по умолчанию — warning/лог, НЕ blocker; hard-fail доступен ТОЛЬКО под kill-switch (frontmatter_validation_strict, дефолт False).
FAIL: ошибка writer/валидатора пробрасывается в конвейер; ИЛИ отсутствие полей схемы по умолчанию заваливает гейт/останавливает задачу; ИЛИ нет kill-switch для строгого режима.

AC-6 — STAGE_TRANSITIONS и состав QG_CHECKS не изменены; семантика неизменна

Условие: инварианты конвейера.

PASS: src/stages.py::STAGE_TRANSITIONS и реестр QG_CHECKS (src/qg/checks.py) — без изменений по составу (те же стадии, те же зарегистрированные гейты); семантика каждого вердикта (значение → переход/откат) идентична прежней, включая ORCH-047 (3 равноранговых поля tester) и приоритет негативного токена.
FAIL: изменён состав STAGE_TRANSITIONS/QG_CHECKS; или хоть один вердикт даёт другой переход при том же значении, что до задачи.

AC-7 — документация обновлена

Условие: golden-source документации синхронна с кодом.

PASS: обновлены CLAUDE.md, docs/architecture/README.md, CHANGELOG.md; заведён ADR per-work-item (docs/work-items/ORCH-076/06-adr/ADR-001-*.md) и сквозной (docs/architecture/adr/adr-NNNN-*.md); спека handoff и PIPELINE_DOCS.md согласованы.
FAIL: функционал изменён, но доки/ADR/CHANGELOG не обновлены (reviewer → REQUEST_CHANGES по правилу CLAUDE.md №6).

Сводная матрица AC ↔ FR/BR

AC	Покрывает
AC-1	BR-1 / BR-2 / FR-1 / FR-2 / FR-3
AC-2	BR-3 / FR-6
AC-3	BR-4 / FR-4
AC-4	NFR-1 / NFR-4 / FR-5
AC-5	NFR-2 / NFR-3 / NFR-5 / FR-2
AC-6	BR-5 / NFR-1
AC-7	правило CLAUDE.md №2/№6

7.1 KiB Raw Permalink Blame History Unescape Escape