Создан golden source структуры номерных документов work item (ORCH-52b, слой 1 эпика ORCH-52). Docs-only: STAGE_TRANSITIONS / QG_CHECKS / check_* / схема БД не трогаются (AC-6). - docs/_standards/PIPELINE_DOCS.md — манифест «стадия→агент→документ→категория→ гейт→frontmatter machine-key» (сверен с src/stages.py и src/qg/checks.py) + раздел ADR-naming. Манифест документирует поведение гейтов, источник истины остаётся код (ADR-001 §D2); честно различает machine-verdict (12/13/14/15/17) и информационные (00/08/10/16) доки; под-гейты ребра deploy-staging→deploy отмечены как врезки в advance_stage. - docs/_templates/* — 15 копируемых скелетов; машинные доки несут точный frontmatter-ключ из _parse_* (verdict/result/deploy_status/staging_status/ security_status/post_deploy_status). - Точки-ссылки: CLAUDE.md, docs/architecture/README.md; запись CHANGELOG. - tests/test_orch_52b_docs_standard.py — TC-01..TC-20 структурные проверки; полный pytest tests/ зелёный (1177 passed). Refs: ORCH-075 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
01 — BRD (бизнес-требования): ORCH-NNN — <название>
Work Item: ORCH-NNN · Repo: · Стадия: analysis
1. Бизнес-контекст и проблема
<Зачем задача, какую боль/риск закрывает. Установленные факты — не изобретать.>
2. Объём (scope)
В объёме
- <что делаем>
Вне объёма
- <что явно НЕ делаем — чтобы исключить расползание>
3. Заинтересованные стороны
<Кто заказчик, кого затрагивает, кто принимает результат.>
4. Бизнес-требования (BR)
- BR-1 — <требование, проверяемое>
- BR-2 — …
5. Нефункциональные требования (NFR)
- NFR-1 — <надёжность / совместимость / обратимость / безопасность>
- NFR-2 — …
6. Допущения и ограничения
<Допущения, на которых стоит решение; внешние ограничения.>
7. Критерии успеха
<Резюме; детальные PASS/FAIL — в 03-acceptance-criteria.md.>
8. Риски
<Краткий перечень; детали — 10-tech-risks.md (заполняет архитектор).>