docs(standards): pipeline docs standard — manifest + templates + ADR-naming

Создан 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>

docs/_templates/00-business-request.md

@@ -0,0 +1,8 @@
+# Business Request: <краткий заголовок задачи>
+
+Work Item ID: ORCH-NNN
+
+## Description
+
+<Что хочет заказчик/Владелец своими словами: проблема, желаемый результат, контекст.
+Допускается `TBD` на входе — analyst уточняет на стадии `analysis` и формализует в 01-brd.md.>

docs/_templates/01-brd.md

@@ -0,0 +1,34 @@
+# 01 — BRD (бизнес-требования): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<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 (заполняет архитектор).>

docs/_templates/02-trz.md

@@ -0,0 +1,30 @@
+# 02 — ТЗ (TRZ): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения — задача архитектора (06-adr).
+
+## 1. Сводка изменения
+<Что меняется, в одном-двух абзацах.>
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/<module>.py` | изменить / создать |
+
+## 3. Функциональные требования
+### FR-1 — <название>
+<Поведение, контракт, инварианты. Привязать к BR.>
+
+## 4. Изменения API
+<Новые/изменённые эндпоинты; либо «Нет.».>
+
+## 5. Изменения схемы БД
+<Таблицы/миграции/индексы; либо «Нет.».>
+
+## 6. Требования к новым/изменённым QG checks
+<Изменения `QG_CHECKS` / `check_*`; либо «Нет.».>
+
+## 7. Совместимость / регресс
+<Обратная совместимость, kill-switch, область раската, обратимость.>

docs/_templates/03-acceptance-criteria.md

@@ -0,0 +1,31 @@
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — <краткий заголовок>
+
+**Условие:** <проверяемое условие>
+- **PASS:** <что должно быть истинно>
+- **FAIL:** <что считается провалом>
+
+---
+
+## AC-2 — <краткий заголовок>
+
+**Условие:** <…>
+- **PASS:** <…>
+- **FAIL:** <…>
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-2 |

docs/_templates/04-test-plan.yaml

@@ -0,0 +1,20 @@
+work_item: ORCH-NNN
+title: "<краткое название тест-плана>"
+framework: pytest
+scope: "<что покрывается тестами; что вне покрытия>"
+notes: >
+  <Свободные заметки: окружение, особенности, что считается регрессом.
+  Полный регресс tests/ должен оставаться зелёным.>
+
+tests:
+  - id: TC-01
+    type: unit            # unit | integration
+    description: "<что проверяет тест>"
+    module: tests/test_<feature>.py
+    expected: PASS
+
+  - id: TC-02
+    type: integration
+    description: "<…>"
+    module: tests/test_<feature>.py
+    expected: PASS

docs/_templates/06-adr-ADR-NNN-slug.md

@@ -0,0 +1,43 @@
+# ADR-NNN: <Заголовок решения>
+
+> **Шаблон ADR.** Скопируй в `docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md`.
+> `NNN` начинается с `001`, инкремент при нескольких ADR в задаче. `<kebab-slug>` — нижний
+> регистр, слова через дефис. Сквозное (cross-cutting) решение дополнительно дублируй в
+> `docs/architecture/adr/adr-NNNN-<kebab-slug>.md` (4-значная глобальная нумерация).
+> См. `docs/_standards/PIPELINE_DOCS.md` §4.
+
+Work Item: **ORCH-NNN** — <короткое описание>
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-NNNN-<slug>.md`** (если решение
+кросс-каттинговое; иначе — «N/A, локальное решение задачи»).
+
+## Статус
+Proposed   <!-- Proposed | Accepted | Superseded by ADR-… -->
+
+## Контекст
+<Какую проблему решаем; факты, сверенные с кодом (`src/…`); почему «как есть» не годится.>
+
+## Решение
+
+### Сводка
+<Суть выбранного решения в одном-двух абзацах.>
+
+### D1 — <название аспекта решения>
+<Конкретное решение по аспекту, инварианты, привязка к FR/AC.>
+
+### D2 — <название аспекта решения>
+<…>
+
+## Альтернативы
+- **<альтернатива>** — отвергнуто: <почему>.
+
+## Последствия
+- **+** <положительный эффект>
+- **−** <издержка / приятый компромисс + митигейшн>
+- **Откат:** <как полностью откатить изменение>
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-NNN/01-brd.md`
+- TRZ: `docs/work-items/ORCH-NNN/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-NNN/03-acceptance-criteria.md`
+- Сверено по коду: `src/…`

docs/_templates/07-infra-requirements.md

@@ -0,0 +1,19 @@
+# 07 — Инфра-требования: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> When-applicable. Если инфраструктура не затрагивается — оставить явные `N/A` по пунктам
+> (файл создаётся для аудитопригодности, а не из-за изменения топологии).
+
+## I-1. Топология / окружения
+<Контейнеры, порты, сеть, тома, хост; либо `N/A`.>
+
+## I-2. Переменные окружения / секреты
+<Новые env-переменные, изменения `.env` / `.env.example`, секреты; либо `N/A`.>
+
+## I-3. Деплой / рестарт
+<Требуется ли рестарт прод-контейнера; self-hosting инвариант (не ронять прод вне staging);
+либо `N/A`.>
+
+## I-4. CI/CD
+<Изменения `.gitea/workflows/`, новые тестовые шаги; либо «без изменений».>

docs/_templates/08-data-requirements.md

@@ -0,0 +1,15 @@
+# 08 — Требования к данным: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> When-applicable / информационный (гейтом не парсится). Если данные/схема не затрагиваются —
+> оставить явные `N/A`.
+
+## Изменения схемы БД
+<Новые/изменённые таблицы, индексы, миграции (`init_db`); либо `N/A`.>
+
+## Новые/изменённые сущности
+<Поля, колонки, инварианты данных; либо «Нет.».>
+
+## Совместимость данных / миграции
+<Аддитивность, идемпотентность миграций, restart-safe, влияние на общую прод-БД; либо `N/A`.>

docs/_templates/10-tech-risks.md

@@ -0,0 +1,16 @@
+# 10 — Технические риски: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | <описание риска> | Низ./Сред./Выс. | Низ./Сред./Выс. | <как снижаем> |
+| TR-2 | <…> | | | |
+
+## Сводный вывод
+<Доминирующий класс рисков; нужна ли эскалация `arch:major-change` / возврат в анализ;
+итоговая оценка остаточного риска для прод-конвейера (self-hosting).>

docs/_templates/12-review.md

@@ -0,0 +1,31 @@
+---
+type: review
+work_item_id: ORCH-NNN
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES  (machine-key — читает check_reviewer_verdict)
+version: 1
+---
+
+# Review ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter (никогда из прозы).
+> `APPROVED` → дальше по конвейеру; `REQUEST_CHANGES` → откат на `development`.
+
+## Summary
+<Краткая оценка: реализовано ли по ТЗ/ADR, покрытие тестами, обновлена ли документация.>
+
+## Оси проверки
+<Корректность, соответствие ADR/инвариантам, тесты, документация, совместимость/регресс.>
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+## Документация
+<Обновлена ли документация (README/CLAUDE/CHANGELOG/архитектура) в том же PR. Нет → REQUEST_CHANGES.>

docs/_templates/13-test-report.md

@@ -0,0 +1,33 @@
+---
+type: test-report
+work_item_id: ORCH-NNN
+result: PASS            # PASS | FAIL | BLOCKED  (machine-key — читает _parse_tests_verdict)
+---
+
+# Test Report — ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из frontmatter. Канонический ключ — `result:`; равнорангово
+> допускаются `verdict:` / `status:` (ORCH-047). Любой негативный токен (`FAIL`/`BLOCKED`) —
+> авторитетен.
+
+## Окружение
+- Python: <версия>
+- pytest: <версия>
+- Дата: YYYY-MM-DD
+- Worktree: `feature/ORCH-NNN-<slug>`
+
+## Результаты
+
+### Полный регресс
+<`pytest tests/ -q` — итог (N passed); прод-контейнер не трогается.>
+
+### Профильные сюиты
+<Целевые тесты задачи.>
+
+### Сопоставление с тест-планом
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-01 | <…> | test_… | PASS |
+
+### Сопоставление с критериями приёмки
+<AC-1…AC-N — покрыт каким тестом / результат.>

docs/_templates/14-deploy-log.md

@@ -0,0 +1,14 @@
+---
+deploy_status: SUCCESS    # SUCCESS | FAILED  (machine-key — читает _parse_deploy_status)
+work_item: ORCH-NNN
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из `deploy_status:` во frontmatter.
+> `SUCCESS` → `done`; `FAILED` → откат на `development` (БАГ-8).
+
+<Краткое описание деплоя: что выкачено, exit-code хука, кто/что зафиксировало вердикт
+(детерминированный finalizer Фаза C, не LLM, для self-hosting).>

docs/_templates/15-staging-log.md

@@ -0,0 +1,20 @@
+---
+staging_status: SUCCESS    # SUCCESS | FAILED  (machine-key — читает _parse_staging_status)
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+> Машинный вердикт читается ТОЛЬКО из `staging_status:` во frontmatter. Реален для self-hosting
+> (`orchestrator`); для прочих репо гейт — N/A (ORCH-35). `SUCCESS` → дальше; `FAILED` → откат.
+
+Staging test suite — итог (например: «All REAL pipeline checks passed»). Запуск канонически
+внутри контейнера `orchestrator-staging` (8501).
+
+## Results
+- **Block A (SMOKE)**: <…>
+- **Block B (ACCESS)**: <…>
+- **Block C (E2E)**: <…>
+
+REAL failed: <none | перечень>.

docs/_templates/16-post-deploy-log.md

@@ -0,0 +1,21 @@
+---
+post_deploy_status: HEALTHY    # HEALTHY | DEGRADED  (информационный, гейтом НЕ парсится — телеметрия ORCH-021)
+action_taken: NONE             # NONE | ALERT_ONLY | ROLLBACK_OK | ROLLBACK_FAILED
+work_item: ORCH-NNN
+window_s: 900
+checks_total: 0
+checks_failed: 0
+---
+
+# Post-deploy log — ORCH-NNN
+
+> Пост-`done` наблюдение прода (ORCH-021). НЕ ребро `STAGE_TRANSITIONS`, гейтом не парсится —
+> frontmatter машиночитаем для петли уроков ORCH-8 / наблюдаемости.
+
+Окно наблюдения: <window_s>s; опросов всего: <checks_total>, с провалом: <checks_failed>.
+
+## Серия наблюдений
+<Краткая серия сигналов health / доли 5xx; классификация HEALTHY/DEGRADED.>
+
+## Решение
+<Реакция: для self-hosting всегда `ALERT_ONLY` (ручной approve, тик не откатывает прод).>

docs/_templates/17-security-report.md

@@ -0,0 +1,26 @@
+---
+security_status: PASS      # PASS | FAIL  (machine-key — читает check_security_gate)
+work_item: ORCH-NNN
+secrets_found: 0
+deps_blocking: 0
+deps_warning: 0
+deps_audit_degraded: false
+---
+
+# Security Report — ORCH-NNN
+
+> Детерминированный security-гейт (ORCH-022) — под-гейт ребра `deploy-staging→deploy` (врезка в
+> `advance_stage`, не строка `STAGE_TRANSITIONS`). Машинный вердикт читается ТОЛЬКО из
+> `security_status:`. `PASS` → дальше; `FAIL` → откат.
+
+## Verdict
+<clean / blocking: N secrets, M blocking CVE(s).>
+
+## Secrets
+<secret-scanning (gitleaks, offline): None | перечень.>
+
+## Dependencies (blocking)
+<dependency audit (pip-audit): None | перечень блокирующих CVE.>
+
+## Dependencies (warning)
+<Не блокирующие предупреждения зависимостей.>