# 03 — Критерии приёмки (Acceptance Criteria): ORCH-075 — ORCH-52b: стандарт документов

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

Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
(что считается провалом). Скоп — только создание стандарта/шаблонов/манифеста (docs-only).

> Критерии унаследованы из AC задачи и расширены проверяемыми условиями. Любой машинный/ручной
> reviewer проверяет их буквально по файлам репозитория.

---

## AC-1 — Манифест создан и покрывает весь реальный набор

**Условие:** существует `docs/_standards/PIPELINE_DOCS.md` с таблицей-манифестом.
- **PASS:** файл существует; манифест содержит строки для **всех** номерных доков реального
  набора — `00, 01, 02, 03, 04, 06, 07, 08, 10, 12, 13, 14, 15, 16, 17`; для каждого указаны
  владелец-агент (analyst/architect/developer/reviewer/tester/deployer/система) и категория
  (`required` / `when-applicable` / `optional`).
- **FAIL:** файла нет; пропущен хотя бы один документ набора; у дока отсутствует владелец или
  категория.

---

## AC-2 — Шаблоны созданы для каждого required/when-applicable дока

**Условие:** существует `docs/_templates/` с каноническими скелетами.
- **PASS:** для каждого `required` и `when-applicable` дока есть файл-шаблон; в шаблоне
  присутствуют (а) frontmatter с machine-key там, где он требуется по FR-1 (`12`→`verdict:`,
  `13`→`result:`, `14`→`deploy_status:`, `15`→`staging_status:`, `16`→`post_deploy_status:`,
  `17`→`security_status:`), и (б) обязательные `##`-секции из ТЗ §FR-2.1.
- **FAIL:** отсутствует шаблон для какого-либо required/when-applicable дока; в шаблоне
  машинного дока нет требуемого frontmatter-ключа; набор секций произвольный, не из ТЗ.

---

## AC-3 — ADR-naming зафиксирован

**Условие:** в стандарте есть раздел про ADR-naming.
- **PASS:** зафиксирован формат `06-adr/ADR-NNN-<kebab-slug>.md` (NNN с `001`), путь
  (`docs/work-items/<plane-id>/06-adr/`), правило формирования slug (kebab-case) и связь со
  сквозным реестром `docs/architecture/adr/adr-NNNN-<slug>.md`; приведён ≥1 реальный пример.
- **FAIL:** ADR-naming не описан, либо описанный формат не совпадает с реальными ADR в репо
  (напр. указана нумерация не с `001`, неверный путь, неверный регистр slug).

---

## AC-4 — Согласованность с фактическими эталонами

**Условие:** манифест и шаблоны соответствуют реальным эталонным докам (ORCH-088/073/089/071)
и фактическому коду.
- **PASS:** в шаблонах нет секций, которых никто не пишет в эталонах; все секции эталонов,
  входящие в общий канон, присутствуют; frontmatter-ключи машинных доков совпадают с тем, что
  реально парсят `src/qg/checks.py` (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/
  `security_status:`); привязка «документ→стадия→гейт» совпадает с `src/stages.py`
  (`STAGE_TRANSITIONS`).
- **FAIL:** шаблон вводит выдуманную секцию; манифест приписывает доку неверную стадию/гейт/
  агента; frontmatter-ключ в шаблоне не тот, что читает гейт.

---

## AC-5 — Ссылки и CHANGELOG обновлены

**Условие:** точки-ссылки и журнал изменений отражают новый стандарт.
- **PASS:** `CLAUDE.md` и `docs/architecture/README.md` содержат ссылку на
  `docs/_standards/PIPELINE_DOCS.md` (и/или `docs/_templates/`); в `CHANGELOG.md` добавлена
  запись в `## [Unreleased]` типа `docs:`.
- **FAIL:** хотя бы одна из трёх точек не обновлена.

---

## AC-6 — Код гейтов НЕ изменён

**Условие:** изменение строго docs-only.
- **PASS:** `git diff` не содержит изменений в `src/qg/checks.py` (`QG_CHECKS`/`check_*`),
  `src/stages.py` (`STAGE_TRANSITIONS`), `src/stage_engine.py`, схеме БД и любом коде гейтов;
  затронуты только `docs/**`, `CLAUDE.md`, `CHANGELOG.md` (+ опционально новые файлы тестов).
- **FAIL:** изменён любой из перечисленных кодовых модулей/гейтов/схемы.

---

## AC-7 — Манифест различает machine-verdict и информационные доки

**Условие:** манифест честно отражает механизм проверки.
- **PASS:** документы, чей frontmatter читает гейт (`12,13,14,15,17`), помечены своим
  machine-key и гейтом; информационные (`00,08,10,16`) явно помечены как не гейтящиеся;
  под-гейты ребра `deploy-staging→deploy` (security/merge/image-freshness) отмечены как врезки
  в `advance_stage`, а не строки `STAGE_TRANSITIONS`.
- **FAIL:** информационный док представлен как гейтящийся (или наоборот); под-гейты выданы за
  стадии.

---

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

| AC | Покрывает BR |
|----|--------------|
| AC-1 | BR-1 |
| AC-2 | BR-2 |
| AC-3 | BR-3 |
| AC-4 | BR-4, BR-6 |
| AC-5 | BR-5 |
| AC-6 | NFR-1, NFR-5 |
| AC-7 | BR-6, NFR-2 |