Files
orchestrator/docs/work-items/ORCH-075/03-acceptance-criteria.md

6.5 KiB
Raw Permalink Blame History

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 (12verdict:, 13result:, 14deploy_status:, 15staging_status:, 16post_deploy_status:, 17security_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