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