tester(ET): auto-commit from tester run_id=636

Единая точка входа в документацию платформы (ADR-001 D1–D9):
- docs/overview/ — 10 файлов: индекс (маршруты «Я заказчик / Я менеджер /
  Я разработчик» + норматив «изменил функциональность → обнови витрину в том же
  PR»), business.md (без жаргона, 6 сценариев), 7 тех-блоков (link-first),
  presentation.md (16 слайдов + процедура сборки «команда + Проверка:»).
- scripts/build_presentation.py — генератор .pptx в тёмном дизайне (python-pptx;
  чистый stdlib-парсер parse_slides + ленивый import pptx; бинарь не коммитится,
  build/ в .gitignore; зависимость НЕ в прод-образе — машинный гард TC-09).
- tests/test_system_docs.py — структурный анти-дрейф: derive-сверки стадий/
  гейтов/агентов импортом STAGE_TRANSITIONS/QG_CHECKS/glob промптов/config,
  валидность ссылок, FORBIDDEN-скан + секрет-эвристика, слайды каноническим
  парсером, NFR-2, указатели.
- reviewer.md — ось обзорных доков ORCH-079 расширена на витрину (D7; канон 52d
  байт-в-байт, только текст внутри секций) + анти-регресс ассерт в
  test_agent_prompts_canon.py.
- Указатели: README.md, CLAUDE.md (правила №2/№6, «Структура»),
  PRODUCT_VISION.md (врезка-ссылка), CHANGELOG.md.

Рантайм байт-в-байт: src/**, docker-compose.yml, Dockerfile, requirements* —
ноль изменений (docs+tests+dev-скрипт, паттерн ORCH-102/103). pytest: 1873 passed.

Refs: ORCH-011

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.env.example

@@ -5,14 +5,68 @@ ORCH_PLANE_API_URL=http://plane-app-api-1:8000
 ORCH_PLANE_WEB_URL=
 ORCH_PLANE_API_TOKEN=
 ORCH_PLANE_WORKSPACE_SLUG=
+# Webhook secrets are GENERATED PER HOST: python3 scripts/gen_secrets.py
+# (ORCH-101 / AC-5: production secrets are NEVER copied to a new host).
 ORCH_PLANE_WEBHOOK_SECRET=
 ORCH_GITEA_URL=http://localhost:3000
+# External (browser) URL of Gitea for clickable Branch/PR links in comments;
+# empty -> falls back to ORCH_GITEA_URL.
+ORCH_GITEA_PUBLIC_URL=
 ORCH_GITEA_TOKEN=
 ORCH_GITEA_WEBHOOK_SECRET=
+ORCH_GITEA_OWNER=admin
+# Per-agent Plane bot tokens (optional): when set, comments are posted under
+# the matching bot so Plane shows the real author; empty -> ORCH_PLANE_API_TOKEN.
+ORCH_PLANE_BOT_ANALYST=
+ORCH_PLANE_BOT_ARCHITECT=
+ORCH_PLANE_BOT_DEVELOPER=
+ORCH_PLANE_BOT_REVIEWER=
+ORCH_PLANE_BOT_TESTER=
+ORCH_PLANE_BOT_DEPLOYER=
+ORCH_PLANE_BOT_STREAM=
+# Telegram live-tracker / alerts (empty -> notifications are logged, not sent).
+ORCH_TELEGRAM_BOT_TOKEN=
+ORCH_TELEGRAM_CHAT_ID=
+# ORCH-6: project registry — JSON array of {plane_project_id, repo,
+# work_item_prefix, name}. Empty -> built-in default registry (src/projects.py)
+# whose Plane UUIDs belong to the ORIGINAL host. On a NEW host this key is
+# MANDATORY (ORCH-101 replication checklist, docs/operations/REPLICATION.md).
+ORCH_PROJECTS_JSON=
 ORCH_CLAUDE_BIN=/usr/bin/claude
-ORCH_REPOS_DIR=/home/slin/repos
 ORCH_DB_PATH=/app/data/orchestrator.db
 
+# ── ORCH-101: host parametrization (replication foundation, ADR-001 D1–D7) ───
+# Every host-specific value lives HERE (defaults = the current production host;
+# an empty/absent value keeps behaviour 1:1). The same names are read by BOTH
+# pydantic Settings (env_file) and docker-compose ${VAR:-default} interpolation
+# (compose reads .env/shell, NOT a service's env_file). Full variable map and
+# the new-host procedure: docs/operations/REPLICATION.md.
+#   AGENT_HOME_DIR -> HOME of all actor subprocesses (agents/finalizer/monitor)
+#                     AND the target of the .claude/.claude.json/.ssh mounts AND
+#                     Dockerfile ARG APP_HOME (ORCH-040 group moves together).
+#   AGENT_GIT_NAME / GIT_EMAIL_DOMAIN -> git identity of agent commits; system
+#                     actors keep platform names deploy-finalizer/post-deploy-
+#                     monitor under the same domain.
+#   STAGING_PORT   -> staging instance port; image_freshness fail-closes when it
+#                     equals the prod port (ORCH-058 AC-9 guard).
+#   HOST_*         -> host-side sources of the bind mounts (repos, ~/.claude,
+#                     ~/.claude.json, ssh keydir, claude-code dist, node binary).
+#   RUN_UID/RUN_GID/DOCKER_GID -> container uid:gid + host docker group for
+#                     docker.sock access (group_add «МИНА 1», ORCH-040).
+ORCH_AGENT_HOME_DIR=/home/slin
+ORCH_AGENT_GIT_NAME=claude-bot
+ORCH_GIT_EMAIL_DOMAIN=mva154.local
+ORCH_STAGING_PORT=8501
+ORCH_HOST_REPOS_DIR=/home/slin/repos
+ORCH_HOST_CLAUDE_DIR=/home/slin/.claude
+ORCH_HOST_CLAUDE_JSON=/home/slin/.claude.json
+ORCH_HOST_SSH_DIR=/home/slin/.orchestrator-ssh
+ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
+ORCH_HOST_NODE_BIN=/usr/bin/node
+ORCH_RUN_UID=1000
+ORCH_RUN_GID=1000
+ORCH_DOCKER_GID=999
+
 # ── Agent model / effort / fallback (ORCH-41, validation ORCH-74) ─────────────
 # Per-agent LLM model + reasoning effort, resolved by launcher.resolve_agent_*.
 # Resolution priority (per agent): project-override (projects_json agent_models/
@@ -139,6 +193,18 @@ ORCH_SERIAL_GATE_FREEZE_ENABLED=true
 #                                for enduro too).
 ORCH_STOP_STATUS_ENABLED=true
 ORCH_STOP_STATUS_REPOS=
+# ORCH-019: bug-fast-track — a cheaper/shorter pipeline route for bug-fix tasks.
+# A task carrying the Plane `Bug` label skips the whole `architecture` stage; EVERY
+# Quality Gate / sub-gate runs UNCHANGED (route is a scheduler property, not a gate).
+# Additive, never-raise, fail-safe -> full cycle. Infra precondition: create a `Bug`
+# label on the ORCH board (its absence = full cycle, fail-safe). Leaf src/bug_fast_track.py.
+#   BUG_FAST_TRACK_ENABLED=false -> start_pipeline AND advance_stage are 1:1 as before
+#                                   ORCH-019 (zero regression).
+#   BUG_FAST_TRACK_LABEL         -> Plane label that activates the track (default `Bug`).
+#   BUG_FAST_TRACK_REPOS (CSV)   -> scope; EMPTY = self-hosting only (orchestrator).
+ORCH_BUG_FAST_TRACK_ENABLED=true
+ORCH_BUG_FAST_TRACK_LABEL=Bug
+ORCH_BUG_FAST_TRACK_REPOS=
 # ORCH-094: terminal-window-aware guard for the three deploy-phase Plane status
 # setters (set_issue_awaiting_deploy / set_issue_deploying / set_issue_monitoring).
 # A DB stage=done task converges to Done idempotently instead of flapping
@@ -394,6 +460,35 @@ ORCH_COVERAGE_EPSILON=0.5
 ORCH_COVERAGE_TOOL_FAIL_CLOSED=false
 ORCH_COVERAGE_RUN_TIMEOUT_S=900
 
+# ORCH-057 (follow-up ORCH-040): legacy root-owned ownership detect + actionable
+# worktree error. After the uid migration (user: "1000:1000") legacy root:root files
+# in /repos broke worktree creation under uid 1000 with a raw "Permission denied".
+# Three additive, kill-switch-reversible layers: an actionable RuntimeError in
+# ensure_worktree, a cheap never-raise detect leaf (src/fs_normalize.py) with a
+# startup WARNING/Telegram + GET /queue fs_ownership block, and an opt-in chown ONLY
+# when privileged (under uid 1000 a no-op; the real fix is the operator procedure in
+# docs/operations/INFRA.md «Миграция uid»). No STAGE_TRANSITIONS / QG_CHECKS / schema
+# change.
+#   ENABLED        -> kill-switch; false -> all code inert, behaviour 1:1 as before
+#                     ORCH-057 (the actionable error too).
+#   REPOS          -> CSV of repos the layer is REAL for; empty -> self-hosting only.
+#   TARGET_UID     -> target uid fallback when os.getuid() is unavailable.
+#   NORMALIZE_AUTO -> detect-only (false) | attempt chown when privileged (true).
+#   SCAN_ROOTS     -> CSV override of the scan roots (empty -> default roots).
+#   SCAN_CACHE_TTL_S -> TTL of the detect cache (mirrors ORCH_PREFLIGHT_CACHE_TTL).
+ORCH_FS_NORMALIZE_ENABLED=true
+ORCH_FS_NORMALIZE_REPOS=
+ORCH_FS_TARGET_UID=1000
+ORCH_FS_NORMALIZE_AUTO=false
+ORCH_FS_SCAN_ROOTS=
+ORCH_FS_SCAN_CACHE_TTL_S=300
+
+# ORCH-099 (FND/F1a): operator off-switch for the read-only GET /metrics endpoint
+# (raw-signal snapshot for the F1b sidecar). Default true -> available out of the
+# box. false -> /metrics returns a minimal parsable body {"schema_version":1,
+# "enabled":false} (200, not 404). The endpoint is inert / read-only anyway.
+ORCH_METRICS_ENABLED=true
+
 # ORCH-021: post-deploy production monitoring + degradation reaction. After the
 # terminal deploy->done transition for an applicable repo, a reserved-agent job
 # `post-deploy-monitor` (no LLM, modelled on deploy-finalizer) probes prod over a
@@ -424,3 +519,48 @@ ORCH_POST_DEPLOY_BASE_URL=http://localhost:8500
 # DB title TEXT is unbounded). Default 200. An invalid/empty value gracefully
 # degrades to 200 (the process never crashes on startup).
 ORCH_QG0_TITLE_MAX=200
+
+# ── ORCH-100 (FND/F1b): sidecar-watchdog (orchestrator-watchdog container) ─────
+# The monitoring brain runs in a SEPARATE container with its OWN config. These
+# keys are read by the watchdog package (watchdog/config.py), NOT by the
+# orchestrator. At runtime they live in `.env.watchdog` (env_file of the
+# orchestrator-watchdog service); this block is the canon. NO real secrets here.
+#   ENABLED        -> kill-switch; false (or not starting the service) -> inert.
+#   INTERVAL_S     -> seconds between ticks.
+#   HTTP_TIMEOUT_S -> per-request timeout (metrics / pings / docker / telegram).
+#   COOLDOWN_S     -> re-alert throttle for a sustained signal (anti-spam).
+#   METRICS_URL    -> orchestrator /metrics (host-network -> 127.0.0.1:8500).
+#   ORCH_DOWN_TICKS-> K consecutive /metrics failures before "орк не отвечает".
+#   MEM_PCT        -> host memory used-% threshold.
+#   DISK_CRIT_*    -> OPT-IN independent disk CEILING (disk_watchdog/ORCH-063 owns
+#                     the 85% alert; this is a higher ceiling on the sidecar's own
+#                     channel, OFF by default -> no double disk-alert, AC-5/D6).
+#   DISK_PATHS     -> host paths measured for the opt-in ceiling.
+#   AGENT_HUNG_MIN -> runtime minutes before an agent with ~0 CPU is "hung".
+#   AGENT_CPU_FLOOR-> CPU fraction below which a long-running agent counts as hung.
+#   STAGE_STUCK_MIN-> minutes a task may sit in one stage before alerting.
+#   QUEUE_DEPTH    -> queued-job depth threshold.
+#   CONTAINERS     -> CSV of container names to watch (status != running/healthy).
+#   DOCKER_SOCK    -> path to the read-only docker.sock inside the container.
+#   DEPS           -> CSV of name=url dependency pings (empty -> no pings).
+#   TG_BOT_TOKEN / TG_CHAT_ID -> the sidecar's OWN Telegram bot/chat (independent
+#                     of the orchestrator's; absent -> logs, does not send).
+WATCHDOG_ENABLED=true
+WATCHDOG_INTERVAL_S=30
+WATCHDOG_HTTP_TIMEOUT_S=5
+WATCHDOG_COOLDOWN_S=1800
+WATCHDOG_METRICS_URL=http://127.0.0.1:8500/metrics
+WATCHDOG_ORCH_DOWN_TICKS=3
+WATCHDOG_MEM_PCT=90
+WATCHDOG_DISK_CRIT_ENABLED=false
+WATCHDOG_DISK_CRIT_PCT=97
+WATCHDOG_DISK_PATHS=/repos,/app/data
+WATCHDOG_AGENT_HUNG_MIN=20
+WATCHDOG_AGENT_CPU_FLOOR=0.01
+WATCHDOG_STAGE_STUCK_MIN=120
+WATCHDOG_QUEUE_DEPTH=20
+WATCHDOG_CONTAINERS=orchestrator
+WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
+WATCHDOG_DEPS=
+WATCHDOG_TG_BOT_TOKEN=
+WATCHDOG_TG_CHAT_ID=

.env.staging.example

@@ -36,6 +36,14 @@ ORCH_CLAUDE_BIN=/usr/bin/claude
 ORCH_REPOS_DIR=/repos
 ORCH_HOST_REPOS_DIR=/home/slin/repos
 
+# ── ORCH-101: host parametrization ───────────────────────────────────────────
+# The host keys (ORCH_AGENT_HOME_DIR / ORCH_AGENT_GIT_NAME / ORCH_GIT_EMAIL_DOMAIN /
+# ORCH_STAGING_PORT / ORCH_HOST_* / ORCH_RUN_* / ORCH_DOCKER_GID) default to the
+# current production host — set them ONLY on a new/different host (see
+# docs/operations/REPLICATION.md). NB: docker-compose ${VAR:-default}
+# interpolation reads the project .env / shell, NOT this env_file — values that
+# must reach compose (mounts/uid/ports) belong in .env, not here.
+
 # ── Database (ISOLATION KEY for staging) ─────────────────────────────────────
 # The staging volume mounts ./data/staging:/app/data, so the DB physically lives
 # at ./data/staging/orchestrator.db on the host — fully isolated from prod.

.env.watchdog.example

@@ -0,0 +1,42 @@
+# .env.watchdog — конфигурация sidecar-watchdog (контейнер orchestrator-watchdog).
+# Канонический example (ORCH-102, ADR-001 D5; симметрия .env.example/.env.staging.example).
+#
+# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ: sidecar-контейнер читает ТОЛЬКО этот файл
+# (compose: env_file {path: .env.watchdog, required: false}). Ключ WATCHDOG_*,
+# положенный в .env, для sidecar ИНЕРТЕН (его видит лишь контейнер орка).
+# Отсутствие файла НЕ ломает `docker compose up` (required: false); нет токена →
+# fail-safe: watchdog пишет алерты в логи, но не отправляет.
+#
+# Создание на хосте: cp .env.watchdog.example .env.watchdog → заполнить два токена.
+# DO NOT COMMIT реальный .env.watchdog — этот файл только шаблон (зеркало
+# .env.staging.example); реальные значения живут на хосте.
+#
+# Нормативы:
+#   * C-1 (ORCH-100): у watchdog СВОЙ Telegram-бот — независимый канал алертов.
+#     Переиспользовать токен орка (ORCH_TELEGRAM_BOT_TOKEN) ЗАПРЕЩЕНО: упавший
+#     орк не сможет сообщить о себе своим же ботом.
+#   * Когерентность порта: WATCHDOG_METRICS_URL следует за прод-портом
+#     (ORCH_DEPLOY_PROD_TARGET_PORT) — сменил порт орка → обнови URL здесь.
+#   * Key-set этого файла = блок WATCHDOG_* в .env.example (канон ключей);
+#     синхронность держит tests/test_lite_setup_doc.py (key-sync, TC-02b).
+#     Значения = дефолты watchdog/config.py.
+
+WATCHDOG_ENABLED=true
+WATCHDOG_INTERVAL_S=30
+WATCHDOG_HTTP_TIMEOUT_S=5
+WATCHDOG_COOLDOWN_S=1800
+WATCHDOG_METRICS_URL=http://127.0.0.1:8500/metrics
+WATCHDOG_ORCH_DOWN_TICKS=3
+WATCHDOG_MEM_PCT=90
+WATCHDOG_DISK_CRIT_ENABLED=false
+WATCHDOG_DISK_CRIT_PCT=97
+WATCHDOG_DISK_PATHS=/repos,/app/data
+WATCHDOG_AGENT_HUNG_MIN=20
+WATCHDOG_AGENT_CPU_FLOOR=0.01
+WATCHDOG_STAGE_STUCK_MIN=120
+WATCHDOG_QUEUE_DEPTH=20
+WATCHDOG_CONTAINERS=orchestrator
+WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
+WATCHDOG_DEPS=
+WATCHDOG_TG_BOT_TOKEN=
+WATCHDOG_TG_CHAT_ID=

.gitignore

@@ -7,5 +7,13 @@ data/
 .pytest_cache/
 # ORCH-31: staging env (secrets, not committed — see .env.staging.example)
 .env.staging
+# ORCH-102: sidecar-watchdog env (secrets, not committed — see .env.watchdog.example)
+.env.watchdog
 # ORCH-31: staging DB data directory
 data/staging/
+# ORCH-103: Bundled-тираж — локальные клоны репо bundle-инсталляции (целевой хост);
+# deploy/bundled/.env и deploy/bundled/data покрыты неякорными `.env` / `data/` выше
+deploy/bundled/repos/
+# ORCH-011 (D5): собранная презентация (scripts/build_presentation.py) — бинарь .pptx
+# в git не коммитится, источник истины — docs/overview/presentation.md
+build/

.openclaw/agents/analyst.md

@@ -29,6 +29,17 @@ FastAPI + SQLite, конвейер стадий через Quality Gates, аге
 
 Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; копируй скелеты из
 `docs/_templates/` (`01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`).
+
+**Багфикс-трек (ORCH-019).** Если задача помечена меткой Plane `Bug` (укороченный маршрут —
+пропуск стадии `architecture`), выпускай **облегчённый** пакет, но **всё равно все 4 файла**
+(гейт `check_analysis_complete` требует `01/02/03/04` — не меняется): `01-brd.md` = короткий
+bug-report (симптом / шаги воспроизведения / локализация / причина), `02-trz.md` +
+`03-acceptance-criteria.md` = краткие bug-shaped заглушки, `04-test-plan.yaml` = план
+**обязательного регресс-теста** (красный до фикса, зелёный после). Экономия — в пропуске целой
+стадии `architecture` (отдельный прогон архитектора + ADR), не в числе файлов. Если баг оказался
+**сложным/архитектурным/визуальным** (нужен ADR или макет) — выпусти **полный** analysis-пакет и
+помечай в bug-report `escalate: full-cycle` (эскалация в полный цикл, ADR-001 D5 ORCH-019); оператор
+снимает багфикс-трек эндпоинтом `POST /bug-fast-track/escalate`.
 </task>
 
 <deliverables>

.openclaw/agents/reviewer.md

@@ -42,6 +42,11 @@ tools:
      (слом критического инварианта конвейера может быть P0). Это усиление оси, а не отдельная ось.
 3. **Качество кода** — нет явных ошибок/утечек/security-дыр? Есть docstrings на публичных функциях?
    Тесты содержательные (не тривиальные)?
+   - **Багфикс-трек: регресс-тест (ORCH-019, BR-4).** Если задача — багфикс (метка `Bug` /
+     укороченный маршрут с пропуском `architecture`), исправление кода **обязано** нести
+     новый/изменённый тест-фиксатор дефекта (красный до фикса, зелёный после). Фикс кода без
+     теста-фиксатора → **finding ≥ P1 / REQUEST_CHANGES**. Это усиление оси «качество», а не
+     отдельная ось (структурно дублируется coverage-гейтом ORCH-027).
 4. **Документация — ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА** (приоритет над остальным): если PR меняет `src/`
    (функционал, API, конфигурацию, конвейер, QG) — документация ДОЛЖНА быть обновлена в том же PR.
    Проверь: API → `docs/architecture/README.md` (таблица API)? стадии/QG →
@@ -52,7 +57,10 @@ tools:
      ограничения» (обзорная витрина проекта), README ДОЛЖЕН быть обновлён в том же PR — пункт снят
      или помечен закрытым с ORCH-ссылкой. Необновление обзорных доков → **finding ≥ P1**; если
      ограничение закрыто правкой `src/` без обновления README — это совпадает с P0 «`src/` изменён,
-     документация не обновлена». Это усиление трактовки оси, а не отдельная ось.
+     документация не обновлена». Это усиление трактовки оси, а не отдельная ось. Та же ось
+     покрывает **витрину системы** (ORCH-011): PR меняет функциональность, описанную в витрине
+     `docs/overview/` (стадии, гейты, агенты, интеграции, способности из `business.md`), а витрина
+     не обновлена → **finding ≥ P1** — расширение трактовки той же оси, не новая ось.
 </task>
 
 <deliverables>
@@ -72,6 +80,9 @@ frontmatter-вердиктом, см. `<output_format>`).
 - ❌ PR закрыл пункт из `README.md` «Известные ограничения», но README не обновлён (пункт остался
   открытым) → ✅ требуй обновления обзорных доков — пункт снят либо помечен закрытым с ORCH-ссылкой;
   необновление обзорной витрины → **finding ≥ P1** (ORCH-079).
+- ❌ PR меняет функциональность, описанную в витрине `docs/overview/` (стадии, гейты, агенты,
+  интеграции, способности из `business.md`), но витрина не обновлена → ✅ требуй обновления витрины
+  в том же PR; необновление → **finding ≥ P1** (расширение оси обзорных доков ORCH-079 — ORCH-011).
 
 **Severity:**
 - **P0 (blocker):** не реализовано требование ТЗ; нарушен ADR; критическая уязвимость;

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-093
+Work item: ORCH-011
 Repo: orchestrator
-Branch: feature/ORCH-093-bug-merge-gitea-405-5xx-hold-p
+Branch: feature/ORCH-011-
 Stage: development

CHANGELOG.md

@@ -3,6 +3,74 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
+- **Витрина системы `docs/overview/`: бизнес + тех, маршруты трёх аудиторий, презентация** (ORCH-011, `docs`): единая точка входа в документацию платформы — новый docs-раздел `docs/overview/` (плоский каталог, 10 файлов, ADR-001 D1): индекс `README.md` (маршруты «Я заказчик / Я менеджер / Я разработчик» + норматив сопровождения «изменил функциональность → обнови витрину в том же PR»), бизнес-часть `business.md` (проблема → решение → что умеет фактически → ценность → 6 сценариев; без жаргона, цифры только с атрибуцией), 7 тех-блоков `tech-*.md` (архитектура со схемой потока, конвейер/гейты, агенты, модель объектов, интеграции, качество/безопасность, наблюдаемость; link-first — за деталями ссылки в golden sources, разрешённый дубль только машинно-сверяемый). **Docs+tests+dev-скрипт** (паттерн ORCH-102/103): `src/**`/`docker-compose.yml`/`Dockerfile`/`requirements*`/`STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схема БД — ноль изменений. ADR: `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`, сквозной `adr-0039-system-overview-docs-canon.md`.
+  - **Презентация (D4/D5):** слайдо-источник `docs/overview/presentation.md` (16 слайдов в машинно-парсимой структуре «## Слайд N: …» + процедура сборки «команда + Проверка:») + dev-скрипт `scripts/build_presentation.py` (python-pptx, тёмный дизайн, редактируемый текст с точной кириллицей; чистый stdlib-парсер `parse_slides` + ленивый импорт pptx). Запуск только вне рантайма; `python-pptx` НЕ в прод-образе (машинный гард); собранный `.pptx` в git не коммитится — `build/` в `.gitignore`.
+  - **Анти-дрейф (D6):** новый структурный `tests/test_system_docs.py` (без сети/LLM/subprocess, паттерн `test_lite_setup_doc.py`) — 10 файлов витрины; маршруты/норматив; derive-сверки с кодом: стадии импортом `src.stages.STAGE_TRANSITIONS` (вкл. `deploy-staging`/`cancelled`, порядок цепочки), exit-гейты и под-гейты именами реестра `QG_CHECKS` в нормативном порядке security → merge → coverage → image-freshness (+ маркер «не стадии»), 6 агентов glob'ом промптов, таблица эффортов class-default'ами config (ORCH-41/81); валидность относительных ссылок + обязательные golden-source ссылки; полнотекстовый FORBIDDEN-скан (импорт из `test_no_host_hardcodes.py`) + секрет-эвристика + запрет вне-репозиторных путей; слайды каноническим парсером; `pptx` отсутствует в `requirements*`/`Dockerfile`; указатели README/CLAUDE/CHANGELOG.
+  - **Reviewer-ось (D7):** ось обзорных доков ORCH-079 в `.openclaw/agents/reviewer.md` точечно расширена на витрину (необновлённая витрина при изменении описанной в ней функциональности → finding ≥ P1; канон 52d байт-в-байт, только добавление внутрь существующих секций) + анти-регресс ассерт в `tests/test_agent_prompts_canon.py`; зеркальные правки правил №2/№6 `CLAUDE.md`.
+  - **Указатели (D8):** `README.md` — ссылка на витрину; `CLAUDE.md` — указатель в правиле №2 и строке «Структура»; `docs/PRODUCT_VISION.md` — врезка-ссылка «фактическое состояние — витрина» (vision не переписывается; расхождения vision↔код в витрину не переносятся — она строится от кода).
+- **ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт** (ORCH-103, `feat`): закрыт Type B эпика ORCH-10 — заказчик **без собственной инфраструктуры** получает конвейер «под ключ»: одна команда `docker compose -f deploy/bundled/docker-compose.yml up -d` поднимает весь стек (орк + watchdog + Gitea + зеркало upstream Plane CE ≈14 контейнеров), один прогон `scripts/bootstrap_bundle.py apply` доводит его до рабочего состояния. Рантайм байт-в-байт: `src/**`/корневой compose/`Dockerfile`/`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — ноль изменений (паттерн ORCH-009/102, kill-switch не нужен — активация только явным запуском оператора на целевом хосте). ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`, сквозной `adr-0038-bundled-replication-canon.md`.
+  - **Bundle-compose (D1–D4):** новый top-level каталог `deploy/` (дистрибутивы развёртывания); `deploy/bundled/docker-compose.yml` — один самодостаточный файл, project name `orchestrator-bundle` (узнаваемый префикс томов/контейнеров, по нему preflight детектирует «грязный хост»); `container_name` не пиннится (bundle и Lite не сталкиваются на одном хосте); staging-контура орка нет вовсе (self-hosting у заказчика = маршрут Lite). Все сторонние образы пиннованы неподвижными тегами (Plane CE v0.23.1 upstream-имена сервисов, Gitea 1.22.6, postgres/valkey/rabbitmq/minio). Сеть — одна bridge: машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/plane|gitea`, `ORCH_GITEA_URL=http://gitea:3000`), наружу — только человеческие порты `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`; postgres/redis/mq/minio не публикуются; мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Конфиг-канон — `deploy/bundled/.env.example` (только плейсхолдеры, ни одного дефолтного пароля; key-set-sync интерполяций держит тест); runtime-конфиг орка/watchdog — корневые `.env`/`.env.watchdog` (канон Lite 1:1, `env_file required: false` — первый `up` живёт до сборки конфига).
+  - **Bootstrap (D5–D8):** `scripts/bootstrap_bundle.py` — python stdlib-only (модули платформы не импортируются, держится ast-сканом), режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`, step-движок check→ensure (повторный запуск = каскад skip, resume после manual-step = повторный запуск), exit-контракт 0/2/1. Шаги: preflight (fail-fast ДО мутаций: docker/compose, порты, RAM/диск, чистота хоста по префиксу) → секреты (webhook — **строго** субпроцессом `gen_secrets.py`; bundle-креды — stdlib `secrets`; существующие не перетираются без `--force-secrets`; значения не печатаются) → up+готовность (healthchecks + poll, migrator exit 0) → init Gitea полностью автоматом (`gitea admin user create`/`generate-access-token`; branch protection НЕ настраивается — норматив D10 ORCH-009/INV-4) → init Plane (честные manual-step c API-верификацией результата; workspace-webhook — ensure с fallback на manual-step) → онбординг sandbox-проекта **строго** `onboard_project.py apply+verify` (нулевой дрейф канона статусов/лейблов) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых `.env`/`.env.watchdog` (bootstrap — единственный писатель, права 600) → health/итоговая сводка PASS/FAIL. Delete-операций НЕТ вообще (D9): teardown — только документированная процедура.
+  - **Док-канон (D10):** `docs/deployment/BUNDLED_SETUP.md` — 14 разделов в порядке маршрута оператора (рамка → требования к хосту с цифрами RAM/диск/CPU и картой портов («Plane ≈ 14 контейнеров») → предусловия → код → секреты → запуск → bootstrap с перечнем manual-step → LLM/Telegram/онбординг ссылками на LITE_SETUP §7–§8/ONBOARDING → smoke (REPLICATION §4) → stateless-проверка → остановка/полный сброс → траблшутинг); каждый шаг = fenced-команда + «Проверка:» PASS/FAIL; REPLICATION.md §1 — строка Type B → ✅ ORCH-103. **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
+  - **Анти-дрейф (D11):** три структурных тест-модуля без docker/сети/LLM — `tests/test_bundle_compose.py` (состав сервисов, пины образов, изоляция томов, key-set-sync, заморозка корневого compose), `tests/test_bundled_setup_doc.py` (14 разделов, FORBIDDEN — импорт из `test_no_host_hardcodes.py`, секрет-эвристика hex≥32/alnum≥40, env-ключи ⊆ канонов, «22 статуса» импортом `plane_sync`, кросс-рефы, CHANGELOG), `tests/test_bootstrap_script.py` (кирпичи, stdlib-only, нет delete-операций/своего списка статусов, unit чистых функций preflight/плана/рендера, exit 0/2/1). `.gitignore` дополнен `deploy/bundled/repos/` (клоны целевого хоста не коммитятся; `.env`/`data/` уже покрыты неякорными паттернами).
+- **ORCH-10a Lite-тираж: инструкция LITE_SETUP + канон watchdog-конфига + анти-дрейф контур** (ORCH-102, `docs`): закрыт Type A эпика ORCH-10 — заказчик разворачивает у себя **только орк+watchdog** и донастраивает окружение (Plane/Gitea/Telegram/LLM) по одной сквозной инструкции «голый хост → работающий конвейер». **Docs+tests** (паттерн ORCH-077/092): `src/**`/`docker-compose.yml`/`Dockerfile`/`scripts/**` — ноль изменений; конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт. ADR: `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной `adr-0037-lite-replication-canon.md`.
+  - **Главный продукт (D1/D2):** новый docs-раздел `docs/deployment/` (витрина тиража, читатель — внешний оператор) с golden source `docs/deployment/LITE_SETUP.md` — 13 нормативных разделов в порядке маршрута оператора (рамка → предусловия хоста → перенос кода → конфигурация → Plane → Gitea → LLM → Telegram → запуск → регистрация проекта → smoke → stateless-проверка → траблшутинг ×7); каждый шаг = fenced-команда + явная «Проверка:»/PASS/FAIL; хост-специфика — только плейсхолдеры `<...>`/`$ENV_VAR`; канон не форкается — статусы/env/вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS.
+  - **Канон watchdog-конфига (D5, исход А-4):** новый `.env.watchdog.example` (третий env-example; key-set = блок `WATCHDOG_*` `.env.example`, 19 ключей, токены — пустые плейсхолдеры) закрывает ловушку файла-носителя: sidecar читает ТОЛЬКО `.env.watchdog`, ключ `WATCHDOG_*` в `.env` для него инертен; шапка несёт C-1 (ORCH-100: свой бот, токен орка переиспользовать запрещено) и когерентность порта `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`; `.env.watchdog` добавлен в `.gitignore` (секрет-гигиена, зеркало `.env.staging`).
+  - **Нормативы разделов:** Gitea (D3, исход А-1) — branch protection на `main` НЕ включать (ADR D10 ORCH-009: ломает PR-merge API merge-актора → ложные HOLD; INV-4), pre-receive хуки платформа не вводит, ОДИН глобальный webhook-секрет на все репо; staging-вилка (D6, исход А-5) — базовый Lite-контур БЕЗ staging (нужен только под self-hosting развитие платформы); источник кода (D7, исход А-6) — параметризованный `git clone <ORCHESTRATOR_GIT_URL>`; stateless (AC-3) — пустая БД при первом старте, секреты только свежевыпущенные `gen_secrets.py`, явная проверка чистоты через `GET /queue`.
+  - **Анти-дрейф контур (D8):** новый `tests/test_lite_setup_doc.py` (25 структурных тестов, без сети/LLM/subprocess) — 13 разделов в порядке D2; обязательные кирпичи; key-sync `.env.watchdog.example` ⇄ `.env.example`; каждый упомянутый env-ключ существует в каноне; compose-подмножество (ровно 3 сервиса, staging строго за `profiles: [staging]`, дефолтный `up -d` = ровно орк+watchdog, анти-появление `plane*`/`gitea*`); fenced-скан боевых литералов (импорт `FORBIDDEN` из `test_no_host_hardcodes.py` — один источник истины) + эвристика секретоподобных значений с негативным самочеком; сверка «22 статуса» импортом `plane_sync._PLANE_NAME_TO_KEY`; перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
+  - **Перекрёстные доки (FR-7):** REPLICATION.md §1 — строка «Type A — Lite» → ✅ ORCH-102 + ссылка; README.md — способность Lite-тиража + `docs/deployment/` в структуре; INFRA.md — `.env.watchdog` в секрет-нормативе + ссылка на deployment-раздел; CLAUDE.md — блок ORCH-102.
+- **Фундамент тиража 10-common: расхардкод хоста + секреты нового хоста + smoke-процедура** (ORCH-101, `feat`): платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10, критический путь обоих типов A Lite / B Bundled; stateless по решению 10.06). Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт не тронут; **каждый дефолт = боевому значению** → пустой/неизменённый `.env` ⇒ поведение 1:1 (kill-switch-природа, отдельный флаг не вводится — NFR-2; enduro не затронут). ADR: `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной `adr-0036-replication-foundation-host-parametrization.md`.
+  - **Расхардкод (D2, FR-1/FR-2):** четыре код-блокера закрыты тремя новыми `Settings`-ключами + реюзом существующих: `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, HOME всех акторских env), `agent_git_name`/`git_email_domain` (`ORCH_AGENT_GIT_NAME`/`ORCH_GIT_EMAIL_DOMAIN`, git-идентичность: агенты — `claude-bot@<домен>` через единый `launcher.agent_git_env()` ×2 места; системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом). `plane_sync.notify_stage_change` строит ссылки Branch/PR из `gitea_public_url`(fallback `gitea_url`)+`gitea_owner` вместо литералов `git.mva154.duckdns.org`/`admin`. `SELF_HOSTING_REPO` — **нормативная платформенная константа** тиража (D3: конфиг-ключ превращал бы опечатку в активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов), пин-тест.
+  - **Staging-порт + исполняемый инвариант ORCH-058 (D4):** `_STAGING_PORT` → ключ `staging_port` (`ORCH_STAGING_PORT`, дефолт 8501; то же имя интерполируется в compose `command:` staging — один факт, одно имя); в начале freshness-пути новый **fail-closed guard**: `staging_port == deploy_prod_target_port` → отказ «staging rebuild refused» + Telegram-алерт, **без тихого fallback** — анти-prod-гарантия из подразумеваемой константы стала исполняемой. Имена сервисов/профиля остаются константами.
+  - **Инфра-файлы (D5/D6/D7, FR-3):** `docker-compose.yml` — полная интерполяция `${VAR:-default}` (реестр B: `ORCH_HOST_REPOS_DIR`/`_CLAUDE_DIR`/`_CLAUDE_JSON`/`_SSH_DIR`/`_CLAUDE_CODE_DIR`/`_NODE_BIN`, `ORCH_DOCKER_GID` (group_add «МИНА 1» сохранён ×3), `ORCH_RUN_UID/GID`, реюз `ORCH_DEPLOY_SSH_USER`/`_HOST_REPO_PATH`/`_PROD_TARGET_PORT`); оба app-сервиса получили явный `command:` (прод — `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}`); группа ORCH-040 (uid/gid/HOME/маунты/useradd) двигается согласованно через `build.args APP_UID/APP_GID/APP_HOME`. `Dockerfile` — `ARG APP_UID/APP_GID/APP_USER/APP_HOME` (useradd параметризован; CMD сознательно остаётся exec-form 8500 — PID-1/сигнальная семантика `init: true` не тронута). `orchestrator-deploy-hook.sh` — `REPO="${REPO:-…}"`; **оба инвокера** (`self_deploy.build_deploy_command`, `image_freshness.rebuild_staging_image`) передают `REPO=` явно из конфига (exit-контракт хука 0/1/2 не тронут).
+  - **Секреты (D8, FR-4):** новый stdlib-only `scripts/gen_secrets.py` — криптослучайные `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` (`secrets.token_hex(32)`, повторный запуск — другие значения); режим по умолчанию — печать; `--write` **никогда не перезаписывает существующий `.env` молча** (отказ exit=2, перезапись только `--force`); чек-лист внешних токенов (Plane/Gitea/BotFather/watchdog) + нормативное «боевые секреты не копируются». `.env.example` дополнен до полноты ключей старта (+`ORCH_GITEA_OWNER`/`_PUBLIC_URL`, `ORCH_PLANE_BOT_*`, `ORCH_TELEGRAM_*`, `ORCH_PROJECTS_JSON`, блок хост-параметризации).
+  - **Smoke + доки (D9, FR-5/FR-7):** новый runbook `docs/operations/REPLICATION.md` — карта переменных, процедура секретов, пошаговая smoke-процедура с явными PASS/FAIL (compose config → `/health` → `/queue`+`/metrics` → onboarding sandbox → тестовая задача → артефакты `01–04` стадии analysis; расширенно — до `done`), границы 10-common vs Lite vs Bundled, платформенные конвенции; карта env `INFRA.md` дополнена; `.env.staging.example` согласован.
+  - **Анти-регресс (D10, FR-6):** новый структурный сканер `tests/test_no_host_hardcodes.py` — запрещённые литералы (`82.22.50.71`/`/home/slin`/`mva154`/`duckdns`) в исполняемом коде `src/**`+`watchdog/**` ломают CI; комментарии/докстринги исключены через `tokenize`; `config.py` — структурное исключение (канон дефолтов); allowlist пуст; негативная самопроверка (подсаженный литерал ловится). Тесты: `test_host_config_keys.py` (ключи/guard/REPO/D3-пин), `test_infra_parametrization.py` (интерполяция compose = боевым дефолтам, ORCH-040-группа, Dockerfile ARG, полнота `.env.example`), `test_secrets_gen.py`, `test_replication_smoke.py`.
+- **Turnkey-онбординг проектов: kit + операторский CLI + runbook** (ORCH-009, `feat`): способность развернуть **новый** проект одним проходом (домен D5.2 эпика саморазвития) — **вне рантайма и вне конвейера**: `src/**` байт-в-байт (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты, снапшот-контроль `tests/test_onboarding_invariants.py`), kill-switch не нужен (активация — только явный запуск CLI человеком). Эталон — сам репозиторий orchestrator (каноны ORCH-52b/c/d/e). ADR: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md` (D1…D11), сквозной `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
+  - **Kit `onboarding/repo-skeleton/` (D1–D3, FR-1/FR-2/FR-3):** параметризуемый каркас нового репо — 6 промптов агентов канона 52d/92 (5 XML-секций в нормативном порядке, «❌ → ✅», `<escalation>` у developer/reviewer/tester, frontmatter-схема 52c с плейсхолдерными датами/моделями, machine-verdict ключи байт-в-байт; язык — канон орка: 5 ru + deployer en c рамкой shared-host-гардрейлов), reviewer-gate «дока не обновлена → `REQUEST_CHANGES`», паспорт `CLAUDE.md`, `AGENTS.md` (карта доков + правила ведения), `CONTRIBUTING.md`, `README`/`CHANGELOG`, скелет `docs/` (`ARCHITECTURE`/`PIPELINE`/`PRODUCT_VISION`/`operations/INFRA.md` с обязательными секциями топологии/env/границ/рисков общего хоста, реестр сквозных ADR), `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция словарь↔kit держится тестом). **Канон не форкается (BR-2):** `docs/_templates/` (16) + `docs/_standards/` (3) в kit не хранятся — копируются live из чекаута в момент материализации.
+  - **CLI `scripts/onboard_project.py` (D4–D7, D11, FR-4/FR-5):** режимы `plan` (дефолт, GET-only, ноль мутаций сети/диска) / `apply` (идемпотентный ensure: существующее → `skipped(exists)`, delete-операций нет вовсе) / `verify` (round-trip реестра, резолв всех 22 статусов включая fail-closed `Confirm Deploy`/`STOP`, лейблы, webhook активен, полнота kit в репо, скан неразрешённых плейсхолдеров). Закрытый список read-only импортов из `src` (нулевой дрейф по построению): `projects._parse_projects_json`, `plane_sync._PLANE_NAME_TO_KEY`, `config.settings`. Канонические группы статусов фиксированы ADR D5 (код-критично: `STOP`→`cancelled` ORCH-090; терминальные группы только у Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит). Gitea: репо `auto_init=false` + per-repo webhook (`push`/`pull_request`/`status`, **переиспользует** глобальный `ORCH_GITEA_WEBHOOK_SECRET` — новый сломал бы HMAC существующих, TR-6); initial push — **только** в свежесозданный пустой репо (INV-4 не затрагивается). Реестр: merged-вывод `ORCH_PROJECTS_JSON` через фактический парсер; скрипт `.env` НЕ правит, прод НЕ рестартит, ничего не удаляет (NFR-2); секреты маскируются (NFR-3); Plane CE API-пробел → `manual-step` со ссылкой на runbook (fail-safe, TR-8). Отчёт `created/skipped(exists)/manual-step` + `--json`; exit-коды 0/2/1.
+  - **Runbook `docs/operations/ONBOARDING.md` (FR-6):** полный чеклист (предусловия → Plane → Gitea → kit → регистрация с self-hosting-предупреждением → верификация → откат), каждый ручной шаг с командой проверки; smoke — на **staging-контуре** (8501, изолированная БД) с одноразовым sandbox-проектом (D8), журнал smoke-прогонов. `docs/operations/SETUP_WEBHOOKS.md` обобщён per-repo (без хардкода enduro-trails).
+  - **Анти-дрейф (NFR-4):** структурные канон-тесты kit `tests/test_onboarding_kit.py` (TC-01…08, 19–20), рендер/планы/идемпотентность `tests/test_onboarding_script.py` (TC-02, 09–18, моки, без сети), инварианты `tests/test_onboarding_invariants.py` (TC-21: снапшоты `STAGE_TRANSITIONS`/`QG_CHECKS`, закрытый список импортов CLI, эталонные промпты `.openclaw/agents/` не тронуты).
+  - **fix(tests): герметизация ORCH-41-тестов model/effort от хост-env (разблокировка merge-gate):** re-test merge-gate бежит в прод-окружении орка, где оператор легитимно включил `ORCH_AGENT_FALLBACK_MODEL` и сменил `ORCH_AGENT_MODEL_DEFAULT`/`ORCH_AGENT_EFFORT_*` — `test_resolve_agent_model.py::test_fallback_model_disabled_by_default` и `test_resolve_agent_effort.py::test_flags_present_when_configured` ассертили **заводские** дефолты через env-backed singleton `settings` (в чистом env Gitea CI зелёные → мина на `main`; ветка ORCH-009 `src/` и эти тесты не трогает, детонация от смены прод-env). Фикс: autouse-фикстуры обоих файлов пиняют shipped-дефолты model/fallback-полей (зеркально друг другу), ассерт «G4 выключен по умолчанию» переведён на **класс-дефолт поля** (`type(settings).model_fields["agent_fallback_model"].default == ""` — подлинный инвариант ORCH-074 ADR-001 Решение 3), never-break ассерты `is_valid_model` — байт-в-байт. В чистом CI поведение байт-эквивалентно (фикстуры ставят ровно то, что даёт пустой env). Полный регресс: 1713 passed (было 2 failed / 1711 passed на re-test).
+- **Машинный журнал уроков `lessons`** (ORCH-098, `feat`): шаг 1 («Фундамент», F2) эпика саморазвития — формализует свободнотекстовые «уроки» из `memory/` в **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих ретроспективщика (E2), приоритизатора RICE (E3) и Стрим. Чистый **observer-leaf** `src/lessons.py` (never-raise, kill-switch, паттерн `serial_gate`/`coverage_gate`/`metrics`): `record()`/`get()`/`update()`/`snapshot()`. **Инвариант:** журнал — наблюдатель, **не** Quality Gate — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы существующих таблиц байт-в-байт не тронуты; enduro не затронут. ADR: `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`, сквозной `docs/architecture/adr/adr-0034-lessons-journal.md`.
+  - **Таблица (D1, FR-1):** аддитивная идемпотентная `lessons` (`CREATE TABLE IF NOT EXISTS` в `db.init_db()` + три индекса, restart-safe) — контекст (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализ (`root_cause`/`suggestion`), статус (`status`/`related_task`), **колонки атрибуции — сразу и нуллабельно** (`attribution`/`target_repo`/`target_domain`, требование Славы 10.06 / NFR-6, заполняется позже через update; `_ensure_column` форвард-safe на старой таблице) + `source`/`detail`; без `enum`-констрейнтов (слаги forward-compatible). Хелперы `db.record_lesson`/`get_lessons`/`update_lesson`/`lessons_snapshot`/`lessons_recent_dup_exists`.
+  - **НЕ скоупится по репо (D2):** журнал observer-only → единственный регулятор — глобальный kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`); **`lessons_repos` НЕ вводится**. Recorder пишет уроки про **любой** репо (включая enduro-trails); репо-разрез — на **выборке** (`get(repo=…)`).
+  - **Автозапись 4 типов (D3, FR-3):** тонкие best-effort врезки (`source="auto"`, never-raise, дедуп) — `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`, откат на `development`), `merge_hold` (`stage_engine._handle_merge_verify` HOLD), `transient_retry` (`launcher._finalize_transient` на исчерпании бюджета ретраев), `deploy_degraded` (post-deploy `DEGRADED → set_repo_freeze`, урок слоя-3 «деплой OK / прод сломан» ET-8).
+  - **Дедуп (D4):** для `auto` — один indexed-SELECT по `idx_lessons_wi_type`: дубль `(work_item_id, lesson_type, stage)` в окне `lessons_dedup_window_s` (env, дефолт 3600с) → no-op; `manual` не дедупится.
+  - **Эндпоинты (D5, FR-4/5):** `GET /lessons` (read-only, фильтры `type`/`status`/`repo`/`work_item`/`limit`), `POST /lessons` (ручная запись), `POST /lessons/{id}` (доклассификация/update); read-only ключ `lessons` в `GET /queue`. Выключенный флаг → `{"enabled": false}`.
+  - **Регресс:** kill-switch `lessons_enabled=False` → полная инертность (no-op без обращения к БД); never-raise на всех публичных функциях/врезках — сбой журнала не роняет конвейер; аддитивно (новая таблица + leaf + эндпоинты + тонкие врезки). Флаги `config.py`: `lessons_enabled`/`lessons_query_limit_default`/`lessons_dedup_window_s`. Тесты `tests/test_lessons.py` (TC-01…TC-12, unit+integration).
+- **FND/F1b: sidecar-watchdog — мозг мониторинга в отдельном контейнере** (ORCH-100, `feat`): новая папка `watchdog/` (тонкий **Python-3.12-stdlib-only** демон) + сервис `orchestrator-watchdog` в `docker-compose.yml` (`network_mode: host`, read-only `docker.sock`, `mem_limit: 128m`). Вторая половина пары наблюдаемости домена 0: F1a (ORCH-099) отдаёт `GET /metrics` (сырьё), F1b — **мозг**, который это сырьё читает, дополняет внешними сигналами (хост/контейнеры/зависимости) и превращает в **алерты** через **собственный** независимый Telegram-канал. **`src/**` НЕ изменён** — F1b потребитель `/metrics`; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД орка — байт-в-байт. Аддитивно, под kill-switch `WATCHDOG_ENABLED`, строго read-only к наблюдаемому (self-hosting-безопасно). ADR: `docs/work-items/ORCH-100/06-adr/ADR-001-sidecar-watchdog.md`, сквозной `docs/architecture/adr/adr-0033-sidecar-watchdog.md`.
+  - **fix(test): изоляция `settings.runs_dir` в conftest** — устранена амбиентная prod-зависимость, валившая `test_queue.py::TestRetry::test_finalize_job_requeue_then_fail` в self-hosting-окружении (TC-14 «full tests/ regression green»). `launcher._finalize_job` классифицирует падение по хвосту `<settings.runs_dir>/<run_id>.log`; `runs_dir` по умолчанию = живой prod-каталог `/app/data/runs`, где на хосте накоплены РЕАЛЬНЫЕ логи агентов (`2.log` содержит `429` → 'transient'), поэтому тест с литеральным `run_id=2` читал чужой prod-лог и получал requeue вместо `failed`. Новый autouse-фикстур `_isolate_runs_dir` в `tests/conftest.py` (по образцу `_no_telegram`/`_disable_merge_verify`) перенаправляет `runs_dir` в пер-тестовый tmp → `_run_log_path()` указывает на несуществующий файл → `classify_log_file()` отдаёт документированный дефолт 'permanent'. Детерминизм всей сюты восстановлен (1617 passed); `src/**` не тронут.
+  - **Стек (D1):** Python 3.12 stdlib-only на `python:3.12-slim` — `urllib` (HTTP `/metrics` + пинги + Telegram POST), сырой HTTP-over-unix-socket для read-only `docker.sock` (БЕЗ pip-пакета `docker`), `shutil.disk_usage`/`/proc/meminfo` для хоста. Нет дерева зависимостей (тонкость, C-3). Отдельный образ `watchdog/Dockerfile` (build-контекст = корень репо; `src/**` НЕ копируется — изоляция C-1).
+  - **Топология (D2):** сервис собирается из `watchdog/Dockerfile`, `restart: unless-stopped` (самовосстановление), `network_mode: host` → `/metrics` достижим как `http://127.0.0.1:8500/metrics`; `docker.sock` смонтирован `:ro` И код GET-only (двойная гарантия read-only); хост-пути bind-mount `:ro`; `mem_limit: 128m`+`mem_reservation: 32m`. `env_file` опционален (`required: false`) → отсутствие `.env.watchdog` НЕ ломает `docker compose up` прод-орка. Деплой watchdog поднимает ТОЛЬКО его — прод `orchestrator` не пересобирается/не рестартится.
+  - **Обобщённая чистая решающая функция (D4):** `watchdog/decision.py::decide(signal_active, prev, now, cooldown_s) -> alert|realert|recovery|none` — строгая генерализация `disk_watchdog.decide_action` (булев `signal_active` вместо `used_pct >= threshold`), per-signal in-memory `AlertState` (анти-спам/recovery, рестарт сбрасывает → корректный повторный алерт стоящей проблемы).
+  - **Реестр сигналов (D5):** `orch_down` (K=3 подряд неудачных `/metrics` — debounce, не флаппит на одиночной икоте), `host_mem` (≥90%), `host_disk_crit` (opt-in потолок 97%, default off — D6), `agent_hung` (per run_id, два опроса: `runtime > N` И доля CPU `< floor`), `stage_stuck` (per work_item), `job_failed` (edge, рост счётчика), `queue_depth` (≥20), `container_down` (per name, статус ∉ {running,healthy}), `dep_down` (per name, пинг Plane/Gitea/Anthropic). Все пороги/интервалы/URL/токены — из env (`WATCHDOG_*`, канон в `.env.example`).
+  - **Анти-дубль диск-алерта (D6, AC-5):** штатные 85% остаются ЕДИНСТВЕННО за `disk_watchdog` (ORCH-063) → **нулевой дубль по построению**; вклад sidecar — `orch_down` (когда орк лёг, in-process стражи мертвы) + **opt-in** независимый потолок `host_disk_crit` (97%, default off) как резерв канала. Один владелец на порог.
+  - **Независимый транспорт (D7):** `watchdog/notify.py` читает **свои** `WATCHDOG_TG_BOT_TOKEN`/`WATCHDOG_TG_CHAT_ID`, **запрещён** импорт `src/notifications.py`/токена орка (падение орка не утянет алерт-канал). Отсутствие токена → fail-safe (логирует, не шлёт, не падает).
+  - **never-raise + kill-switch (D8):** три уровня (per-source: битый коллектор деградирует один сигнал; per-tick: внешний try/except цикла; per-send: обёрнутая отправка). `WATCHDOG_ENABLED=false` → демон инертен (idle-loop с логом, НЕ exit — чтобы restart-policy не крутил петлю). Толерантность к версии `/metrics` (D9): неизвестные поля игнорируются, рост `schema_version` логируется (warning) без крэша.
+  - Тесты: `tests/watchdog/test_*.py` (TC-01…TC-13: решение/orch-down/never-raise/kill-switch/full-tick/docker-readonly/notify-isolation/metrics-parse/compose/disk-dedup + коллекторы host/deps) + полный регресс `tests/ -q` зелёный (TC-14, `src/**` не тронут). **Инфра-предусловие** (07): добавить сервис в compose, создать bot/chat watchdog + `.env.watchdog`, первый запуск на хосте. Откат: не запускать сервис / `WATCHDOG_ENABLED=false`.
+- **Багфикс-трек: упрощённый/дешёвый маршрут конвейера для багов** (ORCH-019, `feat`): задача с меткой Plane `Bug` идёт **укороченным маршрутом** — пропускается стадия `architecture` (отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`), тяжёлая аналитика заменяется облегчённым пакетом (короткий bug-report + обязательный план регресс-теста). **Все Quality Gate'ы исполняются без изменений** (корневой инвариант NFR-1): `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / сигнатуры `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/`coverage_status:`) — байт-в-байт прежние; маршрутизация багфикса — свойство планировщика, **не** гейт. Аддитивно, под kill-switch, с областью репо, never-raise, fail-safe → полный цикл. ADR: `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`, сквозной `docs/architecture/adr/adr-0032-bug-fast-track.md`.
+  - **Классификация (D1, FR-1):** новый leaf `src/bug_fast_track.py` (never-raise, паттерн `labels`/`serial_gate`). `bug_fast_track_applies(repo)` (локально, без сети) проверяется ПЕРВЫМ → выключенный флаг = нулевой сетевой оверхед; `is_bug_task(work_item_id, project_id)` делегирует в проверенный `labels.has_label` (ORCH-089: `fetch_issue_labels`+`get_project_labels`, нормализация, TTL-кэш). **Источник истины — Plane API**, не payload вебхука. Чтение метки — только в `start_pipeline`, **никогда** в горячем `claim_next_job` (NFR-4).
+  - **Хранение типа (D2):** аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'` (`_ensure_column`, паттерн `tasks.cancelled_at` ORCH-090); значения `'full'` (дефолт, ВСЕ существующие и не-баг задачи) | `'bug'`. Хелперы `db.set_task_track`/`db.get_task_track` (отсутствие/NULL → `'full'`, fail-safe). Сигнатура `create_task_atomic` не меняется.
+  - **Routing-override (D3, FR-2):** врезка в `advance_stage` на ребре выхода из `analysis`: при `track='bug'` (через чистый предикат `bug_fast_track.skips_architecture`) `next_stage` → `development`, `next_agent` → `developer` (минуя `architect`). `get_next_stage`/`get_agent_for_stage`/`STAGE_TRANSITIONS` — чистые, 1:1; тип читается из БД (без сети, NFR-4). Для не-баг задач (`track='full'`) маршрут байт-в-байт прежний. Сопутствующе: стамп `mark_brd_review_ended` расширен на `analysis → development` (честная метрика ORCH-087 на багфикс-треке).
+  - **Гейт `analysis` не тронут (D4, FR-6):** `check_analysis_complete`/`check_analysis_approved` байт-в-байт прежние; багфикс-аналитик всё равно эмитит все 4 файла (облегчённые) — сильнейшая позиция NFR-1 (нулевая поверхность правок гейта).
+  - **Эскалация (D5, FR-5):** админ-эндпоинт `POST /bug-fast-track/escalate?work_item=<id>` (по образцу `POST /serial-gate/unfreeze`) сбрасывает `track` `'bug'→'full'` → следующий переход уходит в `architecture` (полный цикл). Плюс решение мини-аналитика «баг сложный → полный пакет + `escalate: full-cycle`».
+  - **Область / флаги (D6):** `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`), `bug_fast_track_label` (дефолт `Bug`), `bug_fast_track_repos` (CSV; **пусто → self-hosting only** — enduro подключается явным CSV). `False` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия, AC-6).
+  - **Наблюдаемость (D7, FR-7):** аддитивный read-only блок `bug_fast_track` в `GET /queue` (флаг/метка/область + счётчик багфикс-задач + метрика сэкономленных стадий `architecture`); лог-строка на решение о маршруте; отметка `🐞` в Telegram-карточке (never-raise). Композиция (D8, AC-9): багфикс-задача — обычная задача репо для serial-gate (ORCH-088, не обходит его); `autoApprove`/`autoDeploy` (ORCH-089), coverage-gate (ORCH-027, союзник BR-4), merge-gate (ORCH-043) — штатно.
+  - **Промпты:** `analyst.md` (облегчённый багфикс-пакет + путь эскалации), `reviewer.md` (ось «багфикс без регресс-теста → finding ≥P1 / REQUEST_CHANGES») — канон 52d не нарушен. **Инфра-предусловие:** создать метку `Bug` в Plane-проекте ORCH (её отсутствие = fail-safe полный цикл). Тесты: `tests/test_bug_fast_track*.py` + `tests/test_db_migrations.py` + блок в `tests/test_queue_endpoint.py` (TC-01…TC-15). Полный регресс `tests/ -q` зелёный. Откат: `ORCH_BUG_FAST_TRACK_ENABLED=false` (мгновенный; остаточная колонка `track` безвредна).
+- **Детект legacy root-owned файлов + внятная ошибка worktree при миграции на uid 1000** (ORCH-057, follow-up ORCH-040, `feat`): закрыт недоделанный AC ORCH-040 — legacy `root:root` файлы в `/repos` (после перевода контейнеров на `user: "1000:1000"`) ломали создание worktree под uid 1000 (`ensure_worktree` → сырой `fatal: … Permission denied`, агент не стартовал, диагноза не было). Три аддитивных, обратимых kill-switch'ем слоя; **`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД — байт-в-байт прежние**. ADR: `docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md`, сквозной `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`.
+  - **D1 — actionable-ошибка `ensure_worktree`:** класс «нет прав» (`Permission denied` / `could not create leading directories` / `insufficient permission for adding an object` / `PermissionError`/`EACCES`/`EPERM`) оборачивается в `RuntimeError` с **причиной** (legacy root-файлы в `/repos/_wt`/`.git` после миграции uid), **лечащей командой** (`chown -R <uid>:<uid> …`) и ссылкой на `INFRA.md` — вместо сырого git stderr. Ошибки, **не** связанные с правами, сохраняют прежний контракт (меняется только формулировка, не факт сбоя; чистый классификатор `fs_normalize.classify_worktree_error`). Под выключенным kill-switch контракт ошибки 1:1 как до ORCH-057.
+  - **D2 — детект-леаф `src/fs_normalize.py`** (never-raise, паттерн `serial_gate`/`coverage_gate`): `scan_ownership(roots, target_uid=os.getuid())` обходит `/repos/_wt`, `<repo>/.git/{objects,worktrees}`, `data/runs` с ранним выходом при первом `st_uid != target_uid`, TTL-кэшем (`fs_scan_cache_ttl_s`, по образцу `preflight._cache`) и `applies(repo)` first (пустой CSV → self-hosting only → enduro-trails не сканируется). Опц. `normalize()` chown'ит **только** при `geteuid()==0` (под uid 1000 — no-op + честный лог «нужна операторская процедура», НЕ ошибка).
+  - **D3 — наблюдаемость, БЕЗ блокировки claim:** best-effort вызов `scan_ownership()` на старте `main.lifespan` (рядом с lease-reclaim/log-rotation, never-fatal) → WARNING + Telegram при mismatch; read-only блок `fs_ownership` в `GET /queue`; опц. ручной `POST /fs-normalize/check`. Claim **не** блокируется (preflight repo-слеп → регресс enduro; queue_worker — дорогой FS-обход в hot-path + молчаливое зависание); внятный ранний отказ даёт D1 в точке launch.
+  - **Процедура (D5):** обязательная операторская нормализация под root на хосте — в `docs/operations/INFRA.md` (раздел «Миграция uid: обязательная нормализация legacy root-файлов», все корни: `_wt`, оба `.git`, `data/runs`); фактический `chown` остаётся ручным шагом (контейнер без root его сделать не может) — задача гарантирует **внятность** отказа, а не его отсутствие.
+  - **Флаги** (`src/config.py`, аддитивно): `ORCH_FS_NORMALIZE_ENABLED` (kill-switch), `ORCH_FS_NORMALIZE_REPOS` (CSV; пусто → self-hosting only), `ORCH_FS_TARGET_UID` (1000), `ORCH_FS_NORMALIZE_AUTO` (детект-only), `ORCH_FS_SCAN_ROOTS`, `ORCH_FS_SCAN_CACHE_TTL_S`. Тесты: `tests/test_fs_normalize.py`, `tests/test_git_worktree_perm.py`, `tests/test_fs_normalize_startup.py`, `tests/test_api_queue.py` (TC-01…TC-12).
+- **Лёгкий read-only `GET /metrics` — машинное «сырьё» о самом орке для sidecar F1b** (ORCH-099, FND/F1a, `feat`): добавлен версионируемый JSON-эндпоинт `GET /metrics`, отдающий снимок внутреннего состояния орка для будущего отдельного sidecar-наблюдателя F1b (`watchdog/`) — наблюдатель отделён от наблюдаемого (BRD §1): орк отдаёт ТОЛЬКО факты, которые знает лишь он сам; пороги/алерты/история/Telegram — на стороне F1b. **Аддитивно, строго read-only, never-raise:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — **не тронуты**; `/health`/`/status`/`/queue` — байт-в-байт прежние. ADR: `docs/work-items/ORCH-099/06-adr/ADR-001-metrics-endpoint.md`, сквозной `docs/architecture/adr/adr-0030-metrics-endpoint.md`.
+  - **Leaf-сборщик + тонкий эндпоинт (D1):** новый `src/metrics.py` (`build_metrics() -> dict`, never-raise по разделам, паттерн `serial_gate.snapshot()`) собирает конверт по-раздельно (каждый раздел в своём `try/except` → безопасный дефолт `null`/`[]`/`{}` + WARNING); эндпоинт `@app.get("/metrics")` в `src/main.py` — тонкая обёртка, возвращает результат как есть (стиль `GET /queue`). Тестируемость без ASGI: разделы проверяются прямым вызовом `build_metrics()`.
+  - **Конверт + контракт `schema_version` (D2):** `schema_version` (стартует с `1`), `generated_at` (UTC ISO-8601, часовой домен орка → дельты CPU иммунны к skew орк↔sidecar, TR-3), `clk_tck` (`os.sysconf("SC_CLK_TCK")`, базис тиков). Политика: аддитивные изменения **НЕ бампят** версию (sidecar обязан игнорировать незнакомые ключи) — бамп только при ломающем (rename/remove/retype).
+  - **Разделы сырья (D3–D7):** `stages` — незавершённые задачи (`stage NOT IN ('done','cancelled')`, ORCH-090) с `work_item`/`stage`/`age_in_stage_s`/`repo` (источник `db.get_active_tasks_for_reconcile()` + фильтр терминалов на потребителе, helper-инвариант ORCH-053/086 не тронут). `queue` — `db.job_status_counts()` (+`cancelled`-ключ дефолтом), глубина, сырьё ретраев (`db.queue_retry_stats()`: attempts/transient/в-backoff), `worker.breaker.snapshot()`, `max_concurrency`. `agents` (liveness) — по running-job (новый read-only `db.get_running_agents()`, dedicated SELECT, НЕ расширение hot-path `get_running_jobs()`): `agent`/`run_id`/`job_id`/`pid`/`runtime_s` (= `running_age_s` от `jobs.started_at`, D6)/`model`/`effort` + **CPU-сырьё** `cpu_ticks` (utime+stime из `/proc/<pid>/stat`, поля 14+15; орк дельту не считает — stateless, арбитр sidecar). `cost` — `running` (по running-job, `null` до завершения = честное сырьё) + `aggregate` (новый `db.agent_cost_totals()`, `COALESCE(SUM(...),0)` по `agent_runs`).
+  - **Never-raise сырьё для liveness (FR-6/NFR-2):** `metrics._read_cpu_ticks(pid)` — `pid is None` / нет `/proc/<pid>` / мёртвый процесс / не-Linux → `cpu_ticks: null` у этого агента, прочие поля и весь эндпоинт целы (НЕ raise). Недоступный `worker` → `breaker: null`/`max_concurrency: null`, не 500. Пустые таблицы → `stages=[]`/`agents=[]`/`cost.aggregate=нули`.
+  - **Kill-switch (D8):** `src/config.py` `metrics_endpoint_enabled: bool = True` (env `ORCH_METRICS_ENABLED` через явный `validation_alias` — документированное имя контракта реально управляет флагом). `False` → `200` с минимальным телом `{"schema_version":1,"enabled":false}` (НЕ 404 — контракт остаётся парсимым). Дефолт `True` → нулевая регрессия (эндпоинт доступен из коробки).
+  - **Контракт задокументирован (AC-7):** формат `/metrics` зафиксирован в `docs/architecture/README.md` (раздел «Сырьё-эндпоинт `/metrics`» + строка в таблице API) как стабильный контракт для F1b. Тесты: `tests/test_metrics.py` (TC-01…TC-11: конверт/4 раздела, исключение терминалов, queue-поля, liveness-сырьё + cpu_ticks на живом pid, never-raise на `pid=None`/мёртвом pid/бросающем источнике/недоступном breaker, cost-агрегат + пустая таблица, эндпоинт через handler, read-only снимок БД до/после, аддитивность `/health`//status//queue, пустое состояние, kill-switch). Полный регресс `tests/ -q` зелёный (1480 → +14). Откат: `ORCH_METRICS_ENABLED=false` (мгновенный) или удаление модуля/эндпоинта/helper'ов (без следов в БД/схеме).
 - **Детерминированный гейт покрытия тестами — защита от тихой деградации coverage перед merge в `main`** (ORCH-027, `feat`): существующие тестовые гейты (`check_ci_green`, `check_tests_passed`, merge-gate re-test) судят только по **факту** прохождения, не по **полноте** — ни один не замечает «300 строк кода, 0 тестов», и при пакетном автономном прогоне (ORCH-088) покрытие монотонно деградирует. Введён детерминированный (без LLM) под-гейт ребра `deploy-staging → deploy` по образцу security-гейта (ORCH-022): leaf `src/coverage_gate.py` (never-raise) + тонкая обёртка `check_coverage_gate` в `QG_CHECKS` + врезка `_handle_coverage_gate` в `advance_stage`. **Аддитивно:** `STAGE_TRANSITIONS` / семантика существующих `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) — байт-в-байт прежние; новая БД-таблица аддитивна (NFR-5/AC-8). См. `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`, сквозной `docs/architecture/adr/adr-0029-coverage-gate.md`.
   - **Точка/порядок (D1, AC-2):** под-гейт исполняется **ПОСЛЕ merge-gate** (покрытие меряется на догнанном `auto_rebase_onto_main` HEAD — ровно том коде, что landed в `main`) и **ДО image-freshness** (фейл до дорогого docker-rebuild). FAIL → штатный откат на `development` (+ инкремент developer-retry, cap `MAX_DEVELOPER_RETRIES`) **и освобождение merge-lease** (merge-gate держал его на своём PASS — зеркало image-freshness rollback, TR-2). `STAGE_TRANSITIONS` не меняется (под-гейт, как security/merge/image-freshness).
   - **Измерение (D2, FR-1/AC-1):** `python -m pytest tests/ --cov=src --cov-report=json` в изолированном per-branch worktree (`ensure_worktree`, прецедент `check_tests_local`); метрика — `totals.percent_covered` (line coverage `src/`). Измеритель инкапсулирован за `measure_coverage(repo, branch) -> float | None` (стек-расширяемость BR-6: jest/jacoco — новая ветка `measure_*`, без переписывания ядра). Тайм-аут `coverage_run_timeout_s`. Новая pip-зависимость `pytest-cov==5.0.0` (offline на момент замера). 

CLAUDE.md

@@ -28,7 +28,7 @@
 - `src/qg/checks.py` — Quality Gate проверки
 - `src/webhooks/` — приём вебхуков Plane/Gitea
 - `tests/` — pytest
-- `docs/` — документация, ADR, work-items, operations
+- `docs/` — документация, ADR, work-items, operations; **витрина системы — `docs/overview/`** (единая точка входа «бизнес + тех», ORCH-011)
 - `scripts/` — утилиты (staging_check.py, orchestrator-deploy-hook.sh)
 
 ## Конвейер (кратко; детали — docs/architecture/README.md)
@@ -153,6 +153,43 @@ created → analysis → architecture → development → review → testing →
   `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`,
   `docs/architecture/adr/adr-0026-stop-cancel-task.md`.
 
+## Багфикс-трек: дешёвый маршрут для багов (ORCH-019)
+Задача с меткой Plane `Bug` идёт **укороченным маршрутом** — пропускается стадия `architecture`
+(отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`); тяжёлая
+аналитика заменяется облегчённым пакетом (короткий bug-report + обязательный план регресс-теста,
+но всё равно все 4 файла analysis — гейт `check_analysis_complete` не меняется). **Корневой
+инвариант (NFR-1):** срезается ТОЛЬКО аналитика/архитектура — **все Quality Gate'ы и под-гейты
+исполняются без изменений** (`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи —
+байт-в-байт прежние); маршрутизация багфикса — свойство планировщика, **не** гейт. Аддитивно, под
+kill-switch, never-raise, fail-safe → полный цикл.
+- **Классификация (D1):** leaf `src/bug_fast_track.py` (never-raise, образец `labels`/`serial_gate`).
+  `bug_fast_track_applies(repo)` (локально, без сети) ПЕРВЫМ → выключенный флаг = нулевой сетевой
+  оверхед; `is_bug_task` делегирует в `labels.has_label` (ORCH-089-аппарат, источник истины — Plane
+  API, не payload). Чтение метки — только в `start_pipeline`, **никогда** в горячем `claim_next_job`
+  (NFR-4).
+- **Хранение типа (D2):** аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'`
+  (`_ensure_column`, паттерн `tasks.cancelled_at`); значения `'full'` (дефолт, ВСЕ существующие и
+  не-баг задачи) | `'bug'`. Хелперы `db.set_task_track`/`get_task_track` (отсутствие/NULL → `'full'`,
+  fail-safe). Читается в `advance_stage` из БД, не из сети.
+- **Routing-override (D3):** врезка в `advance_stage` на ребре выхода из `analysis`: при `track='bug'`
+  (чистый предикат `bug_fast_track.skips_architecture`) `next_stage` → `development`, `next_agent` →
+  `developer` (минуя `architect`). `STAGE_TRANSITIONS`/`get_next_stage`/`get_agent_for_stage` — чистые,
+  1:1. Стамп `mark_brd_review_ended` расширен на `analysis → development` (честная метрика ORCH-087).
+- **Эскалация (D5):** `POST /bug-fast-track/escalate?work_item=<id>` сбрасывает `track` `'bug'→'full'`
+  → следующий переход уходит в `architecture` (полный цикл). Плюс self-escalate мини-аналитика
+  («баг сложный → полный пакет + `escalate: full-cycle`»).
+- **Флаги** (`config.py`): `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`),
+  `bug_fast_track_label` (дефолт `Bug`), `bug_fast_track_repos` (CSV; **пусто → self-hosting only**).
+  `False`/неприменимый репо → старт и маршрут байт-в-байт прежние (нулевая регрессия для enduro и
+  orchestrator). Наблюдаемость — read-only блок `bug_fast_track` в `GET /queue` (флаг/метка/область +
+  счётчик багфикс-задач + метрика пропущенных стадий `architecture`) + отметка `🐞` в Telegram-карточке
+  (never-raise). Композиция: багфикс-задача — обычная задача репо для serial-gate (ORCH-088, не
+  обходит его); `autoApprove`/`autoDeploy` (ORCH-089), coverage-gate (ORCH-027, союзник BR-4),
+  merge-gate (ORCH-043) — штатно. **Инфра-предусловие:** создать метку **`Bug`** в Plane-проекте ORCH
+  (её отсутствие = fail-safe полный цикл). Детали —
+  `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`,
+  `docs/architecture/adr/adr-0032-bug-fast-track.md`.
+
 ## Гейт покрытия тестами (ORCH-027)
 Существующие тестовые гейты (`check_ci_green`, `check_tests_passed`, merge-gate re-test) судят
 только по **факту** прохождения, не по **полноте** — ни один не замечает «300 строк кода, 0
@@ -198,6 +235,151 @@ created → analysis → architecture → development → review → testing →
   `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`,
   `docs/architecture/adr/adr-0029-coverage-gate.md`.
 
+## Машинный журнал уроков (ORCH-098)
+Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
+**машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих
+ретроспективщика (E2), приоритизатора RICE (E3) и Стрим. Чистый **observer-leaf** `src/lessons.py`
+(never-raise, kill-switch, паттерн `serial_gate`/`coverage_gate`/`metrics`): `record()`/`get()`/
+`update()`/`snapshot()`. **Инвариант:** журнал — наблюдатель, **не** Quality Gate; запись урока
+никогда не влияет на продвижение по стадиям — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict/схемы существующих таблиц байт-в-байт не тронуты.
+- **Таблица (D1):** аддитивная идемпотентная `lessons` (`CREATE TABLE IF NOT EXISTS` в `init_db()`,
+  три индекса) — контекст (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализ (`root_cause`/
+  `suggestion`), статус (`status`/`related_task`), **атрибуция сразу и нуллабельно** (`attribution`/
+  `target_repo`/`target_domain`, требование Славы 10.06 / NFR-6, заполняется позже через update;
+  `_ensure_column` форвард-safe на старой таблице) + `source`/`detail`. Без `enum`-констрейнтов —
+  значения суть forward-compatible слаги. Хелперы `db.record_lesson`/`get_lessons`/`update_lesson`/
+  `lessons_snapshot`/`lessons_recent_dup_exists`.
+- **НЕ скоупится по репо (D2):** в отличие от гейт-leaf'ов (`serial_gate`/`coverage_gate` имеют
+  `*_repos`, т.к. *действуют* на репо), журнал observer-only → единственный регулятор — глобальный
+  kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`); **`lessons_repos` НЕ
+  вводится**. Recorder пишет уроки про **любой** репо (включая enduro-trails — урок ценен для петли);
+  репо-разрез — на **выборке** (`get(repo=…)`). enduro не затронут (общая БД, аддитивная таблица).
+- **Автозапись 4 типов (D3):** тонкие best-effort врезки (`source="auto"`, never-raise, дедуп) —
+  `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`, откат на `development`), `merge_hold`
+  (`stage_engine._handle_merge_verify` HOLD-ветка), `transient_retry` (`launcher._finalize_transient`
+  на **исчерпании** бюджета ретраев, а не на каждом backoff), `deploy_degraded` (post-deploy
+  `DEGRADED → set_repo_freeze`, урок слоя-3 «деплой OK / прод сломан» ET-8 — `attribution="unknown"`,
+  классифицируется позже).
+- **Дедуп (D4):** для `source="auto"` — один indexed-SELECT по `idx_lessons_wi_type`: дубль с тем же
+  `(work_item_id, lesson_type, stage)` в окне `lessons_dedup_window_s` (env, дефолт 3600с) → no-op.
+  `source="manual"` дедуп НЕ проходит (оператор/Стрим всегда пишут).
+- **Эндпоинты (D5):** `GET /lessons` (read-only, фильтры `type`/`status`/`repo`/`work_item`/`limit`),
+  `POST /lessons` (ручная запись, `source="manual"`), `POST /lessons/{id}` (доклассификация/update);
+  read-only ключ `lessons` в `GET /queue`. Выключенный флаг → `{"enabled": false}`.
+- **never-raise (NFR-1):** все публичные функции и врезки изолированы (`try/except` → warning +
+  безопасный дефолт) — сбой журнала не роняет конвейер. Self-hosting-безопасно: только читает/пишет
+  свою таблицу, не деплоит/не рестартит прод/не трогает `main`/без процессов/сети. Детали —
+  `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`,
+  `docs/architecture/adr/adr-0034-lessons-journal.md`.
+
+## Turnkey-онбординг проектов (ORCH-009)
+Операторская способность развернуть **новый** проект одним проходом — **вне рантайма и вне
+конвейера** (`src/**` байт-в-байт, kill-switch не нужен: активация — только явный запуск CLI
+человеком). Три артефакта: **kit** `onboarding/repo-skeleton/` (параметризуемый каркас нового репо:
+6 промптов канона 52d/92 — 5 ru + deployer en, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`,
+скелет `docs/` с обязательным `operations/INFRA.md`; плейсхолдеры `{{NAME}}`, словарь —
+`onboarding/placeholders.json`; **канон не форкается**: `docs/_templates/`+`docs/_standards/`
+копируются live из чекаута в момент материализации); **CLI** `scripts/onboard_project.py`
+(`plan` — дефолт, GET-only / `apply` — идемпотентный ensure без delete / `verify`): Plane-проект +
+22 статуса с точными именами (read-only импорт `plane_sync._PLANE_NAME_TO_KEY`; группы фиксированы
+ADR: `STOP`→`cancelled`, терминальные группы только Done/Cancelled/STOP) + лейблы
+`autoApprove`/`autoDeploy`/`Bug` → Gitea-репо + per-repo webhook (переиспользует глобальный
+`ORCH_GITEA_WEBHOOK_SECRET`) → материализация kit + initial push **только** в свежесозданный пустой
+репо → merged-вывод `ORCH_PROJECTS_JSON` (round-trip через фактический `_parse_projects_json`);
+скрипт никогда не рестартит прод / не правит `.env` / ничего не удаляет; недоступное в Plane CE
+API → `manual-step` (fail-safe); **runbook** `docs/operations/ONBOARDING.md` (ручные шаги: env +
+управляемый рестарт; smoke — на staging 8501). Анти-дрейф — структурные тесты
+`tests/test_onboarding_{kit,script,invariants}.py`. Детали —
+`docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`, сквозной
+`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
+
+## Тираж платформы: фундамент 10-common (ORCH-101)
+Платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10,
+оба типа A Lite / B Bundled, stateless). Принцип: **дефолт каждого параметра = боевому значению**
+(пустой `.env` ⇒ поведение байт-в-байт; kill-switch-природа, отдельный флаг не вводится).
+`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты.
+- **Расхардкод:** ключи `agent_home_dir`/`agent_git_name`/`git_email_domain` (HOME + git-идентичность
+  акторов: агенты — единый `launcher.agent_git_env()`; системные имена `deploy-finalizer`/
+  `post-deploy-monitor` — платформенные литералы под тем же доменом), `staging_port`; ссылки
+  Plane-комментариев — из `gitea_public_url`/`gitea_owner`. `docker-compose.yml` — интерполяция
+  `${VAR:-default}` (карта `ORCH_HOST_*`/`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID`; группа ORCH-040
+  uid/gid/HOME/маунты — одни env насквозь, «МИНА 1» сохранена); `Dockerfile` — `ARG APP_*`
+  (CMD exec-form 8500 не тронут); deploy-hook — `"${REPO:-…}"` + явная передача `REPO=` обоими
+  инвокерами. **Платформенные константы (НЕ конфиг):** `SELF_HOSTING_REPO="orchestrator"` (узел
+  «empty CSV → self-hosting only» всех `*_repos`-leaf'ов), имена сервисов/профиля, контейнерный
+  layout. **Инвариант ORCH-058 усилен:** guard fail-closed `staging_port == прод-порт` → отказ
+  freshness-пути ДО любого ssh/build, без тихого fallback.
+- **Секреты нового хоста:** stdlib `scripts/gen_secrets.py` (`secrets.token_hex(32)`; печать по
+  умолчанию; `--write` отказывает при существующем `.env`, перезапись только `--force`); норматив —
+  боевые секреты не копируются. `.env.example` — канон 100% ключей старта.
+- **Smoke тиража:** runbook `docs/operations/REPLICATION.md` (карта env, чек-лист секретов,
+  пошаговый smoke с PASS/FAIL до артефактов `01–04`/`done`, границы 10-common vs Lite vs Bundled).
+  Анти-регресс — `tests/test_no_host_hardcodes.py` (запрещённые литералы в исполняемом коде
+  `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов; config-модули — канон
+  дефолтов, вне скана; allowlist пуст). Детали —
+  `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной
+  `docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`.
+
+## Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
+Закрыт **Type A** эпика ORCH-10 (поверх фундамента 10-common ORCH-101): заказчик разворачивает
+у себя ТОЛЬКО `orchestrator`+`orchestrator-watchdog` и донастраивает окружение
+(Plane/Gitea/Telegram/LLM — его инсталляции) по одной сквозной инструкции. **Docs+tests**
+(паттерн ORCH-077/092): `src/**`/compose/Dockerfile/`scripts/**` не тронуты; конвейер байт-в-байт.
+- **Golden source** — `docs/deployment/LITE_SETUP.md` (новый раздел `docs/deployment/` — витрина
+  тиража, читатель — внешний оператор; vs `docs/operations/` — эксплуатация НАШЕГО прода): 13
+  нормативных разделов в порядке маршрута оператора, каждый шаг = fenced-команда + явная
+  «Проверка:»/PASS/FAIL, хост-специфика только плейсхолдерами; канон не форкается — статусы/env/
+  вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS (явно в доке —
+  только fail-closed имена `Confirm Deploy`/`STOP` и обязательные ключи нового хоста).
+- **Канон watchdog-конфига** — новый `.env.watchdog.example` (key-set = блок `WATCHDOG_*`
+  `.env.example`, держится key-sync тестом): sidecar читает ТОЛЬКО `.env.watchdog`, ключ
+  `WATCHDOG_*` в `.env` для него инертен (ловушка файла-носителя закрыта); C-1 ORCH-100 — свой
+  бот, токен орка не переиспользовать; `.env.watchdog` в `.gitignore`.
+- **Нормативы:** Gitea — branch protection на `main` НЕ включать (ADR D10 ORCH-009 / INV-4),
+  pre-receive не вводится, ОДИН глобальный webhook-секрет; compose НЕ форкается (дефолтный
+  `up -d` = ровно орк+watchdog, staging строго за `profiles: [staging]` — вилка только под
+  self-hosting развитие платформы); stateless — данные/задачи/секреты боевого хоста НЕ
+  переносятся, проверка чистоты через `GET /queue`.
+- **Анти-дрейф** — `tests/test_lite_setup_doc.py` (структурный, без сети/LLM/subprocess):
+  13 разделов в порядке, кирпичи, env-ключи ⊂ `.env.example`, compose-подмножество
+  (анти-появление `plane*`/`gitea*`), fenced-скан `FORBIDDEN` (импорт из
+  `test_no_host_hardcodes.py`) + секрет-эвристика, «22 статуса» сверкой импорта
+  `plane_sync._PLANE_NAME_TO_KEY`, перекрёстность REPLICATION→LITE_SETUP. **Норматив
+  сопровождения (NFR-5):** меняешь шаги тиража → обнови LITE_SETUP.md в том же PR. Детали —
+  `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной
+  `docs/architecture/adr/adr-0037-lite-replication-canon.md`.
+
+## Bundled-тираж: весь стек одним комплектом (ORCH-103)
+Закрыт **Type B** эпика ORCH-10 (поверх 10-common ORCH-101 и канона Lite ORCH-102): заказчик
+**без собственной инфраструктуры** получает весь стек одним комплектом — новый top-level каталог
+**`deploy/bundled/`** (самодостаточный compose: орк + watchdog + Gitea + зеркало upstream Plane CE
+≈14 контейнеров; project name `orchestrator-bundle` = узнаваемый префикс томов/контейнеров;
+`container_name` не пиннится; staging-контура нет вовсе — самразвитие платформы у заказчика =
+маршрут Lite) + **`scripts/bootstrap_bundle.py`** (python stdlib-only, режимы `plan` (дефолт) /
+`apply`/`verify`, step-движок check→ensure, exit 0/2/1), доводящий стек одним прогоном: preflight
+(fail-fast до мутаций) → секреты (webhook — строго `gen_secrets.py`; bundle-креды — stdlib
+`secrets`, без перетирания без `--force-secrets`) → up+готовность → init Gitea (полностью
+автоматом, `gitea admin …`; branch protection НЕ включается — D10 ORCH-009/INV-4) → init Plane
+(честные manual-step c API-верификацией; молчаливый пропуск запрещён) → онбординг sandbox-проекта
+**строго** `onboard_project.py apply+verify` (22 статуса — `plane_sync._PLANE_NAME_TO_KEY`, нулевой
+дрейф канона) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых
+`.env`/`.env.watchdog` (bootstrap — единственный писатель live-конфигов) → health/итог.
+Сеть — одна bridge, машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/*`),
+наружу — только человеческие порты (`BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`);
+мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Все сторонние образы пиннованы
+неподвижными тегами; teardown — только документированная процедура BUNDLED_SETUP §13 (delete-операций
+в скрипте НЕТ вообще). Рантайм байт-в-байт: `src/**`, корневой compose, `Dockerfile`,
+`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты; kill-switch не нужен (активация — только
+явный запуск оператором, паттерн ORCH-009/102). Golden source — `docs/deployment/BUNDLED_SETUP.md`
+(14 разделов канона LITE_SETUP; общие шаги — ссылками на LITE_SETUP/ONBOARDING/REPLICATION).
+Анти-дрейф — `tests/test_bundle_compose.py` (состав/пины/key-set-sync/заморозка корневого compose),
+`tests/test_bundled_setup_doc.py` (разделы/FORBIDDEN-импорт/секрет-эвристика/env-ключи/кросс-рефы),
+`tests/test_bootstrap_script.py` (кирпичи/stdlib-only ast-сканом/нет delete-операций/unit чистых
+функций). **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md
+в том же PR. Детали — `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
+сквозной `docs/architecture/adr/adr-0038-bundled-replication-canon.md`.
+
 ## Конвенции
 - Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
 - Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`
@@ -213,11 +395,11 @@ created → analysis → architecture → development → review → testing →
 
 ## Правила для агентов
 1. Перед любым действием прочесть этот файл и `docs/architecture/README.md`.
-2. **Документация = golden source наравне с кодом.** Изменил функционал → обнови доку В ТОМ ЖЕ PR. Архитектурное решение → заведи ADR (формат — `docs/_standards/PIPELINE_DOCS.md` §4). Структура номерных доков и шаблоны — `docs/_standards/PIPELINE_DOCS.md` + `docs/_templates/`. Обнови `CHANGELOG.md`.
+2. **Документация = golden source наравне с кодом.** Изменил функционал → обнови доку В ТОМ ЖЕ PR. Архитектурное решение → заведи ADR (формат — `docs/_standards/PIPELINE_DOCS.md` §4). Структура номерных доков и шаблоны — `docs/_standards/PIPELINE_DOCS.md` + `docs/_templates/`. Обнови `CHANGELOG.md`. **Витрина системы `docs/overview/` (ORCH-011):** изменил функциональность платформы → обнови витрину в том же PR (какой файл какому классу изменений — таблица в индексе витрины); машинно-проверяемые факты витрины держит `tests/test_system_docs.py`.
 3. Никогда не править артефакты других этапов.
 4. Никогда не комментировать ТЗ задним числом — если ТЗ не годится, возвращай в Анализ.
 5. Никогда не закрывать задачу самостоятельно — это делает CI / финальная стадия.
-6. **Reviewer проверяет: обновлена ли документация. Нет → REQUEST_CHANGES.** Это включает **обзорные доки** (ORCH-079, 52f — финал эпика 52): если PR закрывает пункт `README.md` «Известные ограничения», но README не обновлён → finding ≥P1 (витрина проекта не должна выдавать решённое за открытое).
+6. **Reviewer проверяет: обновлена ли документация. Нет → REQUEST_CHANGES.** Это включает **обзорные доки** (ORCH-079, 52f — финал эпика 52): если PR закрывает пункт `README.md` «Известные ограничения», но README не обновлён → finding ≥P1 (витрина проекта не должна выдавать решённое за открытое). Та же ось покрывает витрину системы (ORCH-011): PR меняет функциональность, описанную в `docs/overview/`, а витрина не обновлена → finding ≥P1.
 7. Не использовать `--no-verify` без явного одобрения Owner.
 8. Секреты — только в `.env`/`.env.staging` на хосте, в гит НЕ коммитятся (канон — `.env.example`).
 9. **Трассировка маркеров (ORCH-078, ORCH-52e):** правишь строку/блок с маркером `ORCH-NNN` →

Dockerfile

@@ -35,7 +35,16 @@ RUN set -eux; \
 # "No user exists for uid 1000" (rc=255), breaking the detached self-deploy ssh
 # launch (ORCH-36 Phase B). Create a real user 1000 with a home dir so getpwuid()
 # resolves and ssh can start.
-RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bash slin
+# ORCH-101 (D5): uid/gid/home/username are build ARGs (defaults = current prod
+# values); compose build.args wires APP_UID/APP_GID/APP_HOME from the SAME env
+# vars as the runtime user: and the mount targets, so the ORCH-040 group
+# (uid/gid/HOME/mounts/useradd) moves coherently. APP_USER is passwd cosmetics
+# (the ENTRY matters for getpwuid/ssh, not the name) — Dockerfile-default only.
+ARG APP_UID=1000
+ARG APP_GID=1000
+ARG APP_USER=slin
+ARG APP_HOME=/home/slin
+RUN groupadd -g ${APP_GID} app && useradd -u ${APP_UID} -g ${APP_GID} -m -d ${APP_HOME} -s /bin/bash ${APP_USER}
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 COPY src/ ./src/
@@ -48,4 +57,9 @@ COPY src/ ./src/
 # and bounced the task off `deploy-staging`. We just ensure the mountpoint exists.
 RUN mkdir -p /app/data
 ENV PYTHONPATH=/app
+# ORCH-101 (D5): CMD deliberately stays exec-form with the documented 8500
+# default — an ARG cannot reach a runtime CMD, and a shell-form CMD would break
+# the verified `init: true` + exec-form PID-1/signal semantics (B-2). The prod
+# port is parametrised on the compose layer (`command:` with
+# ${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}), which overrides this CMD.
 CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]

README.md

@@ -1,6 +1,9 @@
 # Multi-Agent Orchestrator
 
 > См. [CLAUDE.md](CLAUDE.md) (паспорт проекта) и [docs/architecture/README.md](docs/architecture/README.md) (архитектура).
+>
+> **Витрина системы — [docs/overview/](docs/overview/README.md)**: единая точка входа в документацию
+> (бизнес + тех, 7 блоков, маршруты для заказчика / менеджера / разработчика, презентация). ORCH-011.
 
 FastAPI-сервис для оркестрации мульти-агентного пайплайна разработки. Принимает webhooks от Plane и Gitea, управляет жизненным циклом задач через Quality Gates, запускает Claude CLI агентов на каждой стадии.
 
@@ -45,6 +48,7 @@ created → analysis → architecture → development → review → testing →
 | GET | `/queue` | Очередь задач (ORCH-1): counts по статусам + max_concurrency + последние 10 jobs |
 | POST | `/webhook/plane` | Plane webhook receiver |
 | POST | `/webhook/gitea` | Gitea webhook receiver |
+| POST | `/bug-fast-track/escalate?work_item=<id>` | Эскалация багфикс-задачи в полный цикл (ORCH-019): сброс `track` `'bug'→'full'` → следующий переход уходит в `architecture` |
 
 ## Структура проекта
 
@@ -69,6 +73,8 @@ data/
 └── runs/                # Agent output logs ({run_id}.log)
 docs/
 ├── PRODUCT_VISION.md            # Видение продукта
+├── deployment/
+│   └── LITE_SETUP.md            # Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
 ├── architecture/
 │   ├── README.md                # Обзор архитектуры, компоненты, API
 │   ├── internals.md             # Схема БД, потоки, resilience-слой
@@ -140,6 +146,20 @@ uvicorn src.main:app --reload --port 8500
 | `ORCH_QG0_TITLE_MAX` | Верхний лимит длины заголовка QG-0 (вход `_qg0_errors`); невалидное/пустое значение → дефолт (ORCH-069) | `200` |
 | `ORCH_STOP_STATUS_ENABLED` | Kill-switch отмены задачи по Plane-статусу **STOP** + закрытия дыры релонча (ORCH-090); `false` → поведение 1:1 как до ORCH-090 | `true` |
 | `ORCH_STOP_STATUS_REPOS` | CSV область репо для STOP-отмены; пусто = все репо (ORCH-090) | `""` |
+| `ORCH_BUG_FAST_TRACK_ENABLED` | Kill-switch багфикс-трека (ORCH-019): задача с меткой Plane `Bug` пропускает стадию `architecture`; `false` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия) | `true` |
+| `ORCH_BUG_FAST_TRACK_LABEL` | Имя метки Plane, активирующей багфикс-трек (ORCH-019) | `Bug` |
+| `ORCH_BUG_FAST_TRACK_REPOS` | CSV область репо для багфикс-трека; **пусто → self-hosting only** (`orchestrator`) — enduro подключается явным CSV (ORCH-019) | `""` |
+| `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME акторских процессов + таргет маунтов `.claude`/`.ssh` + `ARG APP_HOME` (группа ORCH-040) | `/home/slin` |
+| `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot@mva154.local` при дефолтах) | `claude-bot` / `mva154.local` |
+| `ORCH_STAGING_PORT` | ORCH-101: порт staging (читают `image_freshness` и compose); guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) | `8501` |
+| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` / `_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-источники bind-маунтов (compose-интерполяция) | боевые пути mva154 |
+| `ORCH_RUN_UID` / `ORCH_RUN_GID` / `ORCH_DOCKER_GID` | ORCH-101: uid:gid контейнера и gid docker-группы (`group_add`, ORCH-040) | `1000`/`1000`/`999` |
+
+Тираж платформы на новый хост (полная карта, секреты, smoke) — `docs/operations/REPLICATION.md` (ORCH-101).
+**Lite-тираж под ключ (ORCH-102):** разворачивание орк+watchdog на инфраструктуре заказчика
+по одной сквозной инструкции «голый хост → работающий конвейер» (Plane/Gitea/Telegram/LLM
+заказчик ставит сам и подключает по шагам) — `docs/deployment/LITE_SETUP.md`; канон конфига
+sidecar-watchdog — `.env.watchdog.example`; анти-дрейф — `tests/test_lite_setup_doc.py`.
 
 ## Очередь задач (ORCH-1 / F-2b)
 
@@ -181,6 +201,36 @@ ORCH-090/06-adr/ADR-001-stop-cancel-task.md` + сквозной
 > группой `cancelled`. До создания статуса фича в fail-safe (нет UUID → ветка STOP
 > не активируется).
 
+## Багфикс-трек: дешёвый маршрут для багов (ORCH-019)
+
+Задача с меткой Plane `Bug` (имя метки — `ORCH_BUG_FAST_TRACK_LABEL`, дефолт `Bug`)
+идёт **укороченным маршрутом** конвейера: `analysis(lite) → development → review →
+testing → deploy-staging → deploy → done`, т.е. **пропускается стадия `architecture`**
+(отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`).
+Мини-аналитик выдаёт облегчённый пакет (короткий bug-report + обязательный план
+регресс-теста), но всё равно все 4 файла analysis — гейт `check_analysis_complete`
+не меняется.
+
+**Корневой инвариант:** упрощается только аналитика/архитектура — **все Quality
+Gate'ы и под-гейты исполняются без изменений** (`STAGE_TRANSITIONS` / `QG_CHECKS` /
+`check_*` / machine-verdict ключи — байт-в-байт прежние). Маршрутизация багфикса —
+свойство планировщика (routing-override в `advance_stage` по `tasks.track='bug'`),
+**не** Quality Gate.
+
+Классификация (`src/bug_fast_track.py`, never-raise): локальный `bug_fast_track_applies(repo)`
+ПЕРВЫМ (выключенный флаг = нулевой сетевой оверхед), затем `is_bug_task` через
+`labels.has_label` (источник истины — Plane API). Тип хранится в аддитивной колонке
+`tasks.track` (`'full'` | `'bug'`), читается в горячем пути из БД (не из сети).
+**Эскалация** сложного/архитектурного бага в полный цикл — `POST /bug-fast-track/escalate?work_item=<id>`
+(сброс `'bug'→'full'`). Всё под kill-switch `ORCH_BUG_FAST_TRACK_ENABLED`, область —
+`ORCH_BUG_FAST_TRACK_REPOS` (пусто → self-hosting only), fail-safe → полный цикл.
+Наблюдаемость — блок `bug_fast_track` в `GET /queue` + отметка `🐞` в Telegram-карточке.
+Деталь — `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md` + сквозной
+`docs/architecture/adr/adr-0032-bug-fast-track.md`.
+
+> **Инфра-предусловие:** на доске Plane проекта ORCH создать метку **`Bug`**. До её
+> создания фича в fail-safe (нет метки → задача идёт полным циклом).
+
 **Resilience-слой:** дешёвый preflight (CLI/net, кэш, без токенов) гейтит claim;
 429/overload детектится по логу (transient vs permanent), transient ретраится с
 exp-backoff (`available_at`, Retry-After); circuit breaker паузит воркер после N

deploy/bundled/.env.example

@@ -0,0 +1,61 @@
+# deploy/bundled/.env — конфиг bundle-ИНФРЫ (ORCH-103, ADR-001 D2).
+# Канонический example: 100% ключей интерполяции deploy/bundled/docker-compose.yml
+# (key-set-sync держит tests/test_bundle_compose.py) + ключи init-кред, которые
+# заполняет bootstrap. Создание: cp .env.example .env (или это сделает
+# scripts/bootstrap_bundle.py apply); права 600.
+#
+# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ (TR-8): этот файл читает ТОЛЬКО compose-интерполяция
+# bundle (авто-чтение .env из project dir deploy/bundled/). Runtime-конфиг самого
+# оркестратора и watchdog — КОРНЕВЫЕ .env / .env.watchdog (каноны Lite 1:1:
+# .env.example / .env.watchdog.example, карта — docs/operations/REPLICATION.md §2).
+# Единственный писатель всех live-файлов — scripts/bootstrap_bundle.py: дублируемые
+# ключи (uid/gid, HOME, пути Claude CLI) когерентны механически, не дисциплиной.
+#
+# DO NOT COMMIT реальный deploy/bundled/.env (покрыт неякорным `.env` в .gitignore).
+# Секреты: НИ ОДНОГО дефолтного пароля — пустые значения ниже генерирует bootstrap
+# (stdlib secrets) и никогда не печатает (NFR-3); повторный запуск НЕ перетирает
+# существующие значения без явного --force-secrets.
+
+# --- Публичная точка инсталляции -------------------------------------------
+# Хост, по которому браузер оператора открывает Plane/Gitea и по которому
+# строятся публичные ссылки (ORCH_GITEA_PUBLIC_URL / ORCH_PLANE_WEB_URL / WEB_URL
+# Plane / ROOT_URL Gitea). HTTPS/домены/reverse-proxy заказчика — вне bundle.
+BUNDLE_PUBLIC_HOST=localhost
+
+# --- Карта публикуемых портов (D4: только человеческие точки) ---------------
+# Конфликт порта на хосте → отказ preflight bootstrap ДО любых мутаций (BR-7).
+BUNDLE_ORCH_PORT=8500
+BUNDLE_PLANE_PORT=8080
+BUNDLE_GITEA_HTTP_PORT=3000
+
+# --- Идентичность контейнера орка (реюз имён ORCH-101: один факт = одно имя) --
+# uid:gid владельца deploy/bundled/repos (инвариант ORCH-040); docker-gid хоста
+# («МИНА 1», узнать: getent group docker). Заполняет bootstrap из id -u/-g/getent.
+ORCH_RUN_UID=1000
+ORCH_RUN_GID=1000
+ORCH_DOCKER_GID=999
+# HOME всех акторов в контейнере (группа ORCH-040 двигается одной переменной).
+ORCH_AGENT_HOME_DIR=/home/orchestrator
+
+# --- LLM-предусловие хоста заказчика (bundle НЕ поставляет Claude CLI) -------
+# Пути дистрибутива claude-code/node и кред CLI на хосте (канон — LITE_SETUP §7).
+ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
+ORCH_HOST_NODE_BIN=/usr/bin/node
+ORCH_HOST_CLAUDE_DIR=~/.claude
+ORCH_HOST_CLAUDE_JSON=~/.claude.json
+
+# --- Внутренние креды Plane CE-стека (upstream-имена; значения — bootstrap) --
+POSTGRES_USER=plane
+POSTGRES_PASSWORD=
+POSTGRES_DB=plane
+SECRET_KEY=
+RABBITMQ_DEFAULT_USER=plane
+RABBITMQ_DEFAULT_PASS=
+RABBITMQ_DEFAULT_VHOST=plane
+MINIO_ROOT_USER=plane-minio-admin
+MINIO_ROOT_PASSWORD=
+
+# --- Init-креды Gitea (D6: один пользователь-бот = админ, владелец репо,
+#     носитель API-токена; создаёт bootstrap через `gitea admin user create`) --
+GITEA_ADMIN_USERNAME=orchestrator-bot
+GITEA_ADMIN_PASSWORD=

deploy/bundled/docker-compose.yml

@@ -0,0 +1,338 @@
+# ORCH-103 (Type B Bundled, ADR-001 D1–D4): самодостаточный compose ВСЕГО стека
+# для тиража «под ключ» на хост заказчика: orchestrator + orchestrator-watchdog +
+# Gitea + Plane CE (зеркало официального selfhost-référence makeplane/plane
+# v0.23.1: имена сервисов и env-контракт — upstream, анти-дрейф к их докам; наши
+# отличия от référence: пиннинг неподвижными тегами литералом вместо ${APP_RELEASE}
+# (NFR-6, держится tests/test_bundle_compose.py), убраны replicas/platform/SENTRY,
+# секреты БЕЗ дефолтных значений — их генерирует scripts/bootstrap_bundle.py).
+#
+# Этот файл НЕ исполняется в нашем прод-контуре (корневой docker-compose.yml —
+# байт-в-байт, заморожен анти-дрейфом ORCH-102); активация — только явный запуск
+# оператором на целевом хосте (паттерн ORCH-009, kill-switch не нужен).
+#
+# Конфиг-слои (D2): интерполяции ${VAR} читаются compose'ом из deploy/bundled/.env
+# (авто-чтение из project dir — без --env-file-футгана); канон ключей —
+# deploy/bundled/.env.example (key-set-sync держит тест). Runtime-конфиг орка и
+# watchdog — КОРНЕВЫЕ .env / .env.watchdog (канон Lite 1:1, REPLICATION §2);
+# их единственный писатель — bootstrap_bundle.py.
+#
+# Сеть (D4): одна bridge-сеть проекта; машинный трафик — строго сервис-DNS
+# (Plane→орк http://orchestrator:8500/webhook/plane, Gitea→орк .../webhook/gitea,
+# орк→Plane http://proxy, орк→Gitea http://gitea:3000); network_mode: host НЕ
+# используется (ssh-деплой-контур нашего хоста в bundle структурно спит —
+# ORCH_DEPLOY_SSH_HOST пуст). Наружу публикуются ТОЛЬКО человеческие порты
+# (орк/Plane proxy/Gitea web); postgres/redis/mq/minio не публикуются.
+#
+# Project name = узнаваемый префикс томов/контейнеров orchestrator-bundle_* (D1);
+# container_name сознательно НЕ пиннится ни у кого — bundle и Lite/корневой
+# compose не сталкиваются по именам на одном хосте.
+name: orchestrator-bundle
+
+networks:
+  default:
+    name: orchestrator-bundle
+    driver: bridge
+
+# Env-контракт Plane CE — upstream-имена (référence v0.23.1). Значения секретов
+# (POSTGRES_PASSWORD/SECRET_KEY/RABBITMQ_DEFAULT_PASS/MINIO_ROOT_PASSWORD) живут
+# ТОЛЬКО в deploy/bundled/.env (генерирует bootstrap); дефолтных паролей нет.
+x-plane-env: &plane-env
+  environment:
+    - WEB_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
+    - DEBUG=0
+    - CORS_ALLOWED_ORIGINS=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
+    - GUNICORN_WORKERS=1
+    # db (upstream-имена; host/port — фиксированные сервис-DNS этого файла)
+    - PGHOST=plane-db
+    - PGDATABASE=${POSTGRES_DB:-plane}
+    - POSTGRES_USER=${POSTGRES_USER:-plane}
+    - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
+    - POSTGRES_DB=${POSTGRES_DB:-plane}
+    - POSTGRES_PORT=5432
+    - PGDATA=/var/lib/postgresql/data
+    - DATABASE_URL=postgresql://${POSTGRES_USER:-plane}:${POSTGRES_PASSWORD}@plane-db:5432/${POSTGRES_DB:-plane}
+    # redis
+    - REDIS_HOST=plane-redis
+    - REDIS_PORT=6379
+    - REDIS_URL=redis://plane-redis:6379/
+    # rabbitmq
+    - RABBITMQ_HOST=plane-mq
+    - RABBITMQ_PORT=5672
+    - RABBITMQ_DEFAULT_USER=${RABBITMQ_DEFAULT_USER:-plane}
+    - RABBITMQ_DEFAULT_PASS=${RABBITMQ_DEFAULT_PASS}
+    - RABBITMQ_DEFAULT_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
+    - RABBITMQ_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
+    - AMQP_URL=amqp://${RABBITMQ_DEFAULT_USER:-plane}:${RABBITMQ_DEFAULT_PASS}@plane-mq:5672/${RABBITMQ_DEFAULT_VHOST:-plane}
+    # application secret (генерирует bootstrap; дефолта сознательно НЕТ)
+    - SECRET_KEY=${SECRET_KEY}
+    # datastore (minio)
+    - USE_MINIO=1
+    - AWS_REGION=
+    - AWS_ACCESS_KEY_ID=${MINIO_ROOT_USER:-plane-minio-admin}
+    - AWS_SECRET_ACCESS_KEY=${MINIO_ROOT_PASSWORD}
+    - AWS_S3_ENDPOINT_URL=http://plane-minio:9000
+    - AWS_S3_BUCKET_NAME=uploads
+    - MINIO_ROOT_USER=${MINIO_ROOT_USER:-plane-minio-admin}
+    - MINIO_ROOT_PASSWORD=${MINIO_ROOT_PASSWORD}
+    - BUCKET_NAME=uploads
+    - FILE_SIZE_LIMIT=5242880
+    # live server
+    - API_BASE_URL=http://api:8000
+    # proxy
+    - NGINX_PORT=80
+
+services:
+  # ── Платформа: орк + sidecar-watchdog (образы собираются из этого же чекаута;
+  #    корневой Dockerfile / watchdog/Dockerfile — без правок, NFR-1) ──────────
+  orchestrator:
+    build:
+      context: ../..
+      # ORCH-101 (D5): uid/gid/home двигаются ОДНОЙ группой с user: и таргетами
+      # маунтов ниже (инвариант ORCH-040). Дефолты bundle нейтральны (D2).
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/orchestrator}
+    restart: unless-stopped
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    init: true
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]
+    ports:
+      # человеческая точка: операторский smoke `curl /health` (D4)
+      - "${BUNDLE_ORCH_PORT:-8500}:8500"
+    volumes:
+      # данные/репозитории — bind ВНУТРИ project dir (uid-причины ORCH-040;
+      # покрыты .gitignore: неякорный data/ + deploy/bundled/repos/)
+      - ./data:/app/data
+      - ./repos:/repos
+      - /var/run/docker.sock:/var/run/docker.sock
+      # LLM-предусловие хоста заказчика (bundle его НЕ поставляет, BRD §1.3)
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-~/.claude}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-~/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude.json:ro
+      # ssh-контур в bundle сознательно НЕ вводится (ADR D8): git-доступ агентов
+      # — HTTP token-remote, деплой-хуки нашего хоста структурно спят.
+    # runtime-конфиг орка собирает bootstrap (шаг 8); required:false — первый
+    # `up -d` поднимает стек ДО сборки конфига (AC-1), орк жив без него.
+    env_file:
+      - path: ../../.env
+        required: false
+    environment:
+      - ORCH_REPOS_DIR=/repos
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  orchestrator-watchdog:
+    build:
+      context: ../..
+      dockerfile: watchdog/Dockerfile
+    restart: unless-stopped
+    init: true
+    mem_limit: 128m
+    mem_reservation: 32m
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+      - ./repos:/repos:ro
+      - ./data:/app/data:ro
+    env_file:
+      - path: ../../.env.watchdog
+        required: false
+    environment:
+      # bundle-сеть ≠ host-network Lite: метрики — по сервис-DNS; имя контейнера
+      # орка детерминировано project name (container_name не пиннится, D1).
+      # environment перекрывает env_file → когерентность механическая (TR-8).
+      - WATCHDOG_METRICS_URL=http://orchestrator:8500/metrics
+      - WATCHDOG_CONTAINERS=orchestrator-bundle-orchestrator-1
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  # ── Gitea (D6): официальный образ, НЕ rootless; init полностью автоматом —
+  #    bootstrap создаёт админа/токен через `gitea admin ...` CLI в контейнере.
+  #    Branch protection на main НЕ настраивается (норматив D10 ORCH-009/INV-4).
+  gitea:
+    image: gitea/gitea:1.22.6
+    restart: unless-stopped
+    ports:
+      - "${BUNDLE_GITEA_HTTP_PORT:-3000}:3000"
+    environment:
+      - GITEA__database__DB_TYPE=sqlite3
+      - GITEA__security__INSTALL_LOCK=true
+      - GITEA__server__DOMAIN=${BUNDLE_PUBLIC_HOST:-localhost}
+      - GITEA__server__ROOT_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_GITEA_HTTP_PORT:-3000}/
+      # ssh-контур не вводится (D8): порт не публикуется, ssh выключен.
+      - GITEA__server__DISABLE_SSH=true
+      - GITEA__service__DISABLE_REGISTRATION=true
+      # МИНА TR-4 (D4): Gitea по умолчанию режет webhook'и в приватные адреса —
+      # без этой строки «задача не появилась» гарантирован.
+      - GITEA__webhook__ALLOWED_HOST_LIST=orchestrator
+    volumes:
+      - gitea-data:/data
+    healthcheck:
+      test: ["CMD", "curl", "-fsS", "http://localhost:3000/api/healthz"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  # ── Plane CE — зеркало upstream selfhost-référence v0.23.1 (D3) ────────────
+  web:
+    <<: *plane-env
+    image: makeplane/plane-frontend:v0.23.1
+    restart: unless-stopped
+    command: node web/server.js web
+    depends_on:
+      - api
+      - worker
+
+  space:
+    <<: *plane-env
+    image: makeplane/plane-space:v0.23.1
+    restart: unless-stopped
+    command: node space/server.js space
+    depends_on:
+      - api
+      - worker
+      - web
+
+  admin:
+    <<: *plane-env
+    image: makeplane/plane-admin:v0.23.1
+    restart: unless-stopped
+    command: node admin/server.js admin
+    depends_on:
+      - api
+      - web
+
+  live:
+    <<: *plane-env
+    image: makeplane/plane-live:v0.23.1
+    restart: unless-stopped
+    command: node live/dist/server.js live
+    depends_on:
+      - api
+      - web
+
+  api:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-api.sh
+    volumes:
+      - logs_api:/code/plane/logs
+    depends_on:
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  worker:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-worker.sh
+    volumes:
+      - logs_worker:/code/plane/logs
+    depends_on:
+      - api
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  beat-worker:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-beat.sh
+    volumes:
+      - logs_beat-worker:/code/plane/logs
+    depends_on:
+      - api
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  migrator:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: "no"
+    command: ./bin/docker-entrypoint-migrator.sh
+    volumes:
+      - logs_migrator:/code/plane/logs
+    depends_on:
+      - plane-db
+      - plane-redis
+
+  plane-db:
+    <<: *plane-env
+    image: postgres:15.7-alpine
+    restart: unless-stopped
+    command: postgres -c 'max_connections=1000'
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  plane-redis:
+    <<: *plane-env
+    image: valkey/valkey:7.2.5-alpine
+    restart: unless-stopped
+    volumes:
+      - redisdata:/data
+    healthcheck:
+      test: ["CMD", "valkey-cli", "ping"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  plane-mq:
+    <<: *plane-env
+    image: rabbitmq:3.13.6-management-alpine
+    restart: always
+    volumes:
+      - rabbitmq_data:/var/lib/rabbitmq
+    healthcheck:
+      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
+      interval: 15s
+      timeout: 10s
+      retries: 12
+
+  plane-minio:
+    <<: *plane-env
+    # upstream-référence держит latest — bundle пиннит неподвижный тег (NFR-6)
+    image: minio/minio:RELEASE.2024-05-28T17-19-04Z
+    restart: unless-stopped
+    command: server /export --console-address ":9090"
+    volumes:
+      - uploads:/export
+    healthcheck:
+      test: ["CMD", "curl", "-fsS", "http://localhost:9000/minio/health/live"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  proxy:
+    <<: *plane-env
+    image: makeplane/plane-proxy:v0.23.1
+    restart: unless-stopped
+    ports:
+      # человеческая точка: UI Plane в браузере оператора (D4)
+      - "${BUNDLE_PLANE_PORT:-8080}:80"
+    depends_on:
+      - web
+      - api
+      - space
+
+# Состояние Plane/Gitea — именованные тома проекта (префикс orchestrator-bundle_,
+# D1/D2); preflight bootstrap детектирует «грязный хост» по этому префиксу.
+volumes:
+  pgdata:
+  redisdata:
+  uploads:
+  logs_api:
+  logs_worker:
+  logs_beat-worker:
+  logs_migrator:
+  rabbitmq_data:
+  gitea-data:

docker-compose.yml

@@ -1,42 +1,98 @@
+# ORCH-101 (replication foundation): every host-specific value is interpolated
+# as ${VAR:-default}; the defaults equal the current production values, so an
+# empty environment resolves to a byte-for-byte equivalent of the previous file
+# (zero regression, BR-5). Compose reads ${VAR} from the project `.env` /shell —
+# NOT from a service's env_file (so .env.staging does NOT interpolate); the
+# Settings-shared names (ORCH_AGENT_HOME_DIR, ORCH_STAGING_PORT, ...) are read
+# by pydantic from env_file AND by compose from .env — one name per fact (D1).
+# Container-side paths (/app/data, /repos, /opt/claude-code, docker.sock) are a
+# container-layout convention, NOT host values — deliberately not parametrised.
+# See docs/operations/REPLICATION.md for the full variable map.
 services:
   orchestrator:
-    build: .
+    build:
+      context: .
+      # ORCH-101 (D5): uid/gid/home move as ONE coherent group with the runtime
+      # user: and the mount targets below (ORCH-040 invariant).
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
     container_name: orchestrator
     restart: unless-stopped
     # ORCH-040: бежим под uid:gid хоста (slin=1000:1000), а не root, чтобы
     # артефакты конвейера (worktree + docs) создавались как slin:slin и git на
     # хосте работал без ручного chown. Доступ к docker.sock сохранён через
     # group_add: ["999"] (МИНА 1 — НЕ удалять). См. ADR-001 ORCH-040.
-    user: "1000:1000"
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
     # init: true injects docker-init (tini) as PID 1 so reparented grandchild
     # processes from the claude/node subprocess tree are reaped (no zombies, B-2).
     init: true
     network_mode: host
+    # ORCH-101 (D5): the prod port is configurable on the compose layer (the
+    # Dockerfile CMD keeps its exec-form 8500 default — ADR-001 D5); the default
+    # resolves byte-for-byte to the previous image CMD. Reuses the existing
+    # ORCH_DEPLOY_PROD_TARGET_PORT (no second truth about the prod port).
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}"]
     volumes:
       - ./data:/app/data
-      - /home/slin/repos:/repos
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
       - /var/run/docker.sock:/var/run/docker.sock
-      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
-      - /usr/bin/node:/usr/bin/node:ro
-      - /home/slin/.claude:/home/slin/.claude
-      - /home/slin/.claude.json:/home/slin/.claude.json:ro
-      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
-      - /home/slin/.orchestrator-ssh:/home/slin/.ssh:ro
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
+      # ORCH-040: target согласован с HOME (launcher: settings.agent_home_dir),
+      # не /root/.ssh — обе стороны двигаются одной переменной ORCH_AGENT_HOME_DIR.
+      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
     env_file: .env
     environment:
       - ORCH_REPOS_DIR=/repos
-      - ORCH_HOST_REPOS_DIR=/home/slin/repos
+      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
       # legacy enduro deployer (read via os.environ, keep as-is):
-      - DEPLOY_SSH_USER=slin
+      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
       - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
+      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
       # ORCH-036 self-deploy (read via pydantic ORCH_ prefix; host-network -> 127.0.0.1, ssh key mounted):
-      - ORCH_DEPLOY_SSH_USER=slin
+      - ORCH_DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
       - ORCH_DEPLOY_SSH_HOST=127.0.0.1
       - ORCH_DEPLOY_HOOK_SCRIPT=scripts/orchestrator-deploy-hook.sh
-      - ORCH_DEPLOY_HOST_REPO_PATH=/home/slin/repos/orchestrator
+      - ORCH_DEPLOY_HOST_REPO_PATH=${ORCH_DEPLOY_HOST_REPO_PATH:-/home/slin/repos/orchestrator}
     group_add:
-      - "999"
+      - "${ORCH_DOCKER_GID:-999}"
+
+  # ORCH-100 (FND/F1b): sidecar-watchdog — the monitoring brain in a SEPARATE
+  # container (observer separated from observed, ADR-001 D2). Deploying it builds
+  # ONLY this service — the prod `orchestrator` is NOT rebuilt/restarted.
+  #   * network_mode: host -> /metrics reachable at http://127.0.0.1:8500/metrics
+  #     and host interfaces visible for memory/disk reads.
+  #   * docker.sock mounted :ro AND the code is GET-only (double read-only guard).
+  #   * host disk paths bind-mounted :ro so shutil.disk_usage sees the host FS but
+  #     can never write (opt-in disk ceiling, D6).
+  #   * mem_limit caps the thin stdlib daemon (D2): OOM = early "sidecar grew" signal.
+  #   * WATCHDOG_ENABLED=false (or simply not starting the service) -> inert.
+  orchestrator-watchdog:
+    build:
+      context: .
+      dockerfile: watchdog/Dockerfile
+    container_name: orchestrator-watchdog
+    restart: unless-stopped
+    init: true
+    network_mode: host
+    mem_limit: 128m
+    mem_reservation: 32m
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos:ro
+      - ./data:/app/data:ro
+    # Optional env_file (required: false): a missing .env.watchdog must NOT fail
+    # `docker compose up` for the prod orchestrator (self-hosting safety). Absent
+    # file -> WATCHDOG_* defaults, no token -> fail-safe (logs, does not send).
+    env_file:
+      - path: .env.watchdog
+        required: false
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
 
   # ORCH-31: staging instance (port 8501, isolated DB).
   # Starts ONLY with: docker compose --profile staging up -d orchestrator-staging
@@ -44,35 +100,42 @@ services:
   orchestrator-staging:
     profiles:
       - staging
-    build: .
+    build:
+      context: .
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
     container_name: orchestrator-staging
     restart: unless-stopped
     # ORCH-040: тот же uid хоста, что и у prod (см. комментарий выше / ADR-001).
-    user: "1000:1000"
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
     init: true
     network_mode: host
-    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8501"]
+    # ORCH-101 (D4): the same ORCH_STAGING_PORT that settings.staging_port reads —
+    # the image_freshness rebuild target and the listening port can never drift.
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_STAGING_PORT:-8501}"]
     volumes:
       - ./data/staging:/app/data
-      - /home/slin/repos:/repos
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
       - /var/run/docker.sock:/var/run/docker.sock
-      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
-      - /usr/bin/node:/usr/bin/node:ro
-      - /home/slin/.claude:/home/slin/.claude
-      - /home/slin/.claude.json:/home/slin/.claude.json:ro
-      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
-      - /home/slin/.orchestrator-ssh:/home/slin/.ssh:ro
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
+      # ORCH-040: target согласован с HOME (settings.agent_home_dir), не /root/.ssh.
+      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
     env_file: .env.staging
     environment:
       - ORCH_REPOS_DIR=/repos
-      - ORCH_HOST_REPOS_DIR=/home/slin/repos
-      - DEPLOY_SSH_USER=slin
+      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
+      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
       - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
+      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
       # Staging DB is isolated via ./data/staging volume mount.
       # Inside the container the path remains /app/data/orchestrator.db (same default),
-      # but on the host it physically lives at ./data/staging/orchestrator.db — 
+      # but on the host it physically lives at ./data/staging/orchestrator.db —
       # completely separate from prod ./data/orchestrator.db.
       - ORCH_DB_PATH=/app/data/orchestrator.db
     group_add:
-      - "999"
+      - "${ORCH_DOCKER_GID:-999}"

docs/PRODUCT_VISION.md

@@ -4,6 +4,9 @@
 
 **Версия:** 1.0 · **Дата:** 2026-06-04 · **Статус:** концепция развития
 
+> **Фактическое текущее состояние платформы** (что уже умеет, как устроена) — витрина системы
+> [docs/overview/](overview/README.md) (ORCH-011). Этот документ — vision: «куда идём».
+
 ---
 
 ## 1. Зачем это (бизнес-взгляд)

docs/architecture/adr/README.md

@@ -31,11 +31,23 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | adr-0023 | Обзорная ось reviewer + закрытие эпика 52 | accepted | 2026-06-09 | ORCH-079 |
 | adr-0024 | Disk-watchdog — heartbeat-сигнал заполнения хост-ФС | proposed | 2026-06-09 | ORCH-063 |
 | adr-0025 | Build-cache-pruner — авто-prune docker build cache на хосте | proposed | 2026-06-09 | ORCH-062 |
+| adr-0026 | STOP / отмена задачи — системный терминал `cancelled` | proposed | 2026-06-09 | ORCH-090 |
+| adr-0027 | Merge-актор — ретрай транзиентных ошибок Gitea + гард «ветка уже в `main`» | proposed | 2026-06-09 | ORCH-093 |
+| adr-0028 | Terminal-window-aware гард deploy-фазовых статусов Plane | proposed | 2026-06-09 | ORCH-094 |
+| adr-0029 | Гейт покрытия тестами — edge sub-gate + ratchet-базовая линия | proposed | 2026-06-10 | ORCH-027 |
+| adr-0030 | Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b) | proposed | 2026-06-10 | ORCH-099 |
+| adr-0031 | Нормализация legacy root-owned файлов при миграции uid — детект-leaf + actionable worktree-ошибка | proposed | 2026-06-10 | ORCH-057 |
+| adr-0032 | Багфикс-трек — укороченный маршрут конвейера для багов | proposed | 2026-06-10 | ORCH-019 |
+| adr-0033 | Sidecar-watchdog F1b — мозг мониторинга в отдельном контейнере | proposed | 2026-06-10 | ORCH-100 |
+| adr-0034 | Машинный журнал уроков — таблица `lessons` + observer-leaf | proposed | 2026-06-10 | ORCH-098 |
+| adr-0035 | Turnkey-онбординг проектов — kit + операторский CLI + runbook | proposed | 2026-06-10 | ORCH-009 |
+| adr-0036 | Фундамент тиража платформы — параметризация хоста, секреты, smoke (10-common) | proposed | 2026-06-10 | ORCH-101 |
+| adr-0037 | Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` | proposed | 2026-06-10 | ORCH-102 |
 
 > ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
 > `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
 > (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
-> свободный номер (текущий максимум — `0020`).
+> свободный номер (текущий максимум — `0037`).
 > adr-0014 **amends** adr-0013 (меняет критерий merge-verify на «SHA-в-main»).
 > adr-0016 **amends** adr-0013/0014 (гарантирует открытый код-PR перед merge_pr, ORCH-082).
 > adr-0020 реализует машинный слой к adr-0019 (ORCH-52b→52c).

docs/architecture/adr/adr-0030-metrics-endpoint.md

@@ -0,0 +1,88 @@
+---
+work_item: ORCH-099
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0030: Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b)
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-099 (FND/F1a)
+- **Детальный ADR:** `docs/work-items/ORCH-099/06-adr/ADR-001-metrics-endpoint.md`
+
+## Контекст
+Эпик автономного саморазвития, домен 0 «Фундамент». Рамка наблюдаемости (заказчик): **наблюдатель
+отделён от наблюдаемого** — мозг мониторинга (пороги/алерты/история/Telegram) живёт в отдельном
+sidecar-контейнере **F1b** (`watchdog/`), а орк отдаёт **только сырьё**, которое знает лишь он сам.
+Сегодня такого источника нет: `/health` = `{"status":"ok"}`, `/status` = активные задачи, `/queue` —
+«человеческий» снимок, перемешанный с конфигом демонов. Нет стабильного машинного контракта для
+детекта застрявшей стадии / зависшего агента / деградации очереди / всплеска стоимости. F1b
+заблокирована этой задачей. Self-hosting: прод общий с enduro-trails ⇒ эндпоинт обязан быть строго
+read-only и never-raise.
+
+## Решение
+Новый **leaf-модуль** `src/metrics.py` (`build_metrics() -> dict`, чистый, never-raise по разделам —
+паттерн `serial_gate.snapshot()`) + тонкий эндпоинт `@app.get("/metrics")` в `src/main.py` (стиль
+`GET /queue`). Только чтение существующих таблиц (`tasks`/`jobs`/`agent_runs`) и in-memory-снапшотов
++ два read-only helper'а в `src/db.py`. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-
+ключи/схема БД — **не трогаются**.
+
+- **Конверт + контракт версии:** `schema_version` (старт `1`), `generated_at` (UTC ISO-8601 —
+  момент снимка, домен часов орка), `clk_tck` (`os.sysconf("SC_CLK_TCK")`), разделы
+  `stages`/`queue`/`agents`/`cost`. **Политика версии:** аддитивные изменения НЕ бампят (sidecar
+  обязан игнорировать незнакомые ключи и толерировать отсутствие опциональных); бамп — только при
+  ломающем (rename/remove/retype). Forward-compatible контракт для F1b.
+- **`stages`** — `db.get_active_tasks_for_reconcile()` + фильтр `stage NOT IN ('done','cancelled')`
+  на слое metrics (helper намеренно отдаёт `cancelled` для ORCH-086 — не трогаем его инвариант);
+  поля `work_item`/`stage`/`age_in_stage_s`/`repo`.
+- **`queue`** — `db.job_status_counts()` (+`cancelled`), глубина, сырьё ретраев
+  (`attempts`/`max_attempts`/`transient_attempts`/в-backoff), `worker.breaker.snapshot()`,
+  `max_concurrency`. Недоступный worker → `breaker: null`, не 500.
+- **`agents` (liveness)** — новый dedicated read-only helper `db.get_running_agents()` (НЕ расширение
+  hot-path `get_running_jobs()` reaper'а, ORCH-065): `agent`/`run_id`/`job_id`/`pid`/`runtime_s`
+  (= `running_age_s` от `jobs.started_at`)/`model`/`effort`. CPU-сырьё — **вариант A**: орк читает
+  `/proc/<pid>/stat` (поля 14+15, utime+stime) → `cpu_ticks`; **дельту не считает** — арбитр
+  «жив/завис» это sidecar (stateless-эмиссия). `pid is None`/мёртвый/нет `/proc`/не-Linux →
+  `cpu_ticks: null`, не ошибка.
+- **`cost`** — `running` (по running-job, часто `null` до завершения — честное сырьё, `null` ≠ ноль)
+  + `aggregate` (новый helper `db.agent_cost_totals()`, `COALESCE(SUM(...),0)` по
+  `cost_usd`/`input_tokens`/`output_tokens`/`cache_read_tokens`/`cache_creation_tokens`).
+- **Kill-switch** `metrics_endpoint_enabled` (env `ORCH_METRICS_ENABLED`, дефолт `True`): при `False`
+  → `200` с `{"schema_version":1,"enabled":false}` (контракт остаётся парсимым). Операторский
+  off-switch на общем инстансе.
+- **Never-raise:** каждый раздел — свой `try/except` + `logger.warning` + дефолт (`null`/`[]`/`{}`);
+  `build_metrics()` никогда не пробрасывает. Read-only: ни одного `INSERT/UPDATE/DELETE/CREATE/ALTER`.
+
+## Альтернативы
+- **Расширить `/queue`** — отклонено: ломает байт-в-байт контракт (BR-6) + смешивает сырьё с
+  человеческим снимком.
+- **Prometheus/OpenMetrics** — отклонено: заказчик задал тонкий кастомный sidecar (не Prometheus),
+  контракт — JSON.
+- **Орк считает CPU-дельту сам** — отклонено: требует состояния; stateful-арбитр это sidecar (C-1).
+- **Расширить SELECT `get_running_jobs()`** — отклонено: перенос инварианта hot-path reaper'а;
+  изолируем dedicated helper.
+- **Push в sidecar** — отклонено: нарушает разделение C-1; зависший орк ⇒ pull падает = сам сигнал.
+
+## Последствия
+- F1b разблокирована стабильным машинным контрактом; домен наблюдаемости стартует.
+- Строго read-only + never-raise ⇒ near-zero риск для общего прод-конвейера (enduro-trails);
+  `/health`/`/status`/`/queue` байт-в-байт; гейты/схема/machine-verdict-ключи не тронуты (NFR-5).
+- `schema_version` + аддитивно-толерантная политика ⇒ расширения не ломают F1b.
+- Плата: новая поверхность совместимости `/metrics`↔F1b (митигейшн — единый репо контракта + версия);
+  CPU-liveness Linux-специфичен (`/proc`; не-Linux → `null`). Топология/схема не меняются (sidecar и
+  его сетевая достижимость — объём F1b).
+- Новый компонент + публичный контракт → `arch:major-change` (хоть и аддитивно/read-only/обратимо);
+  прод-деплой строго через staging-гейт (8501), без рестарта прод-контейнера.
+- **Откат:** `metrics_endpoint_enabled=False` (мгновенный) или удаление модуля/эндпоинта/helper'ов —
+  без следов в БД/схеме.
+
+## Связи
+adr-0002 (job-queue/circuit-breaker — источник `queue`-сырья), adr-0011 (job-reaper —
+`get_running_jobs`/pid/liveness-семантика, изоляция hot-path), adr-0026 (терминал `{done,cancelled}`
+— фильтр `stages`), adr-0017 (serial_gate — паттерн leaf `snapshot()`/never-raise), adr-0020
+(frontmatter-контракт — стиль версионируемого контракта). Прямой потребитель — **F1b** (sidecar
+`watchdog/`, отдельная задача).

docs/architecture/adr/adr-0031-legacy-ownership-normalization.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-057
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0031: Нормализация legacy root-owned файлов при миграции uid — детект-leaf + actionable worktree-ошибка
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-057 (follow-up ORCH-040)
+- **Детальный ADR:** `docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md`
+
+## Контекст
+ORCH-040 перевёл контейнеры на `user: "1000:1000"`, изменив только `docker-compose.yml`. Владельца
+уже существующих `root:root` файлов в bind-mount `/repos` это не меняет. Под uid 1000
+`src/git_worktree.py::ensure_worktree` (`os.makedirs` стр. 78 / `git worktree add` стр. 81/85) не может
+создать worktree рядом с root-owned `/repos/_wt/` → `fatal: could not create leading directories …
+Permission denied`, который сейчас пробрасывается сырым. Конвейер приходит сюда из
+`launcher._spawn`/`_materialize_deferred_branch` (ORCH-088) — **агент не стартует** (launch-time
+инфра-сбой, не код задачи). Инцидент 06.06 на проде (первый запуск ORCH-043); workaround Стрима
+(`chown -R 1000:1000`) наложен вручную. ADR-040 описал нормализацию абстрактно («вне объёма кода») и
+не дал процедуры → баг воспроизводим на чистой среде / новом репо / после исторического запуска под
+root. Контейнер бежит **без root** → код физически не может `chown` чужие файлы; ему доступны лишь
+детект + диагностика.
+
+## Решение
+Три аддитивных, обратимых kill-switch'ем слоя — паттерн условного leaf-гейта (`coverage_gate`/
+`serial_gate`) + best-effort startup-хук (`main.lifespan`, как lease-reclaim). `STAGE_TRANSITIONS` /
+`QG_CHECKS` / `check_*` / machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/
+`staging_status:`/`security_status:`/`coverage_status:`) / схема БД — **байт-в-байт прежние**.
+
+- **Actionable worktree-ошибка (D1):** `ensure_worktree` классифицирует класс «нет прав» (маркеры
+  `Permission denied`/`could not create leading directories`/`insufficient permission`/`EACCES`/
+  `EPERM`) и поднимает `RuntimeError` с причиной (legacy root-файлы после миграции uid) + лечащей
+  командой + ссылкой на INFRA.md. Не-прав-ошибки сохраняют прежний текст/смысл (никакой подмены).
+  Меняется лишь **формулировка**, не факт сбоя.
+- **Детект-leaf `src/fs_normalize.py` (D2):** чистый, never-raise, TTL-кэш (паттерн `preflight`).
+  `scan_ownership(roots, target_uid)` обходит `/repos/_wt`, `<repo>/.git/objects`,
+  `<repo>/.git/worktrees`, `data/runs`; ранний выход при первом `st_uid != target_uid`
+  (`target_uid=os.getuid()` по умолчанию). `applies(repo)` (kill-switch + scope; пусто →
+  `is_self_hosting_repo`) проверяется ПЕРВЫМ → дорогой обход только при applies. Идемпотентно;
+  ошибка обхода → WARNING + консервативный `mismatch=False`.
+- **Интеграция = наблюдаемость, без блокировки claim (D3):** best-effort `scan_ownership()` на старте
+  `main.lifespan` → WARNING + Telegram при mismatch. Claim НЕ гейтится: внятный ранний отказ даёт D1
+  в точке launch (знает repo, агент ещё не тратил токены). Блокирующий preflight-гейт отвергнут —
+  preflight не знает repo, заблокировал бы и enduro-trails на общем `/repos`.
+- **Опц. `normalize()` (D4):** chown только при `CAP_CHOWN`/root (под uid 1000 — no-op + лог),
+  флаг `fs_normalize_auto` (дефолт `False`). Init-контейнер/root-entrypoint отвергнут: реинтродукция
+  root-контекста (анти-цель ORCH-040) + правка compose = self-deploy/групповой риск. Реальную
+  нормализацию несёт операторская процедура.
+- **Процедура (D5):** `INFRA.md` получает раздел «Миграция uid: обязательная нормализация legacy
+  root-файлов» (точные команды по всем корням) как обязательный шаг миграции; forward-breadcrumb из
+  ADR-040.
+- **Флаги:** `fs_normalize_enabled` (kill-switch, дефолт `True`), `fs_normalize_repos` (CSV, пусто →
+  self-hosting only), `fs_target_uid` (1000), `fs_normalize_auto` (`False`), `fs_scan_roots`,
+  `fs_scan_cache_ttl_s` (300). Наблюдаемость — блок `fs_ownership` в `GET /queue`; опц. `POST
+  /fs-normalize/check`.
+
+## Альтернативы
+- **Init-контейнер/root-entrypoint** — реинтродукция root (анти-цель ORCH-040), self-deploy compose,
+  групповой риск ради разовой операции. Отвергнуто; носитель нормализации — операторская процедура.
+- **Блокирующий claim-гейт (preflight)** — preflight не знает repo → регресс enduro на общем `/repos`.
+  Отвергнуто.
+- **Блокирующий claim-гейт (queue_worker/claim)** — дорогой FS-обход в hot-path + «молчаливое
+  зависание» вместо диагноза D1. Отвергнуто.
+- **Авто-chown из app по умолчанию** — под uid 1000 невозможен; ложное ожидание самолечения.
+  Отвергнуто (оставлен opt-in `fs_normalize_auto`).
+- **Hard-fail старта при mismatch** — нарушает never-raise, стопорит сервис всех проектов. Отвергнуто.
+
+## Последствия
+- Класс «сырой git-fatal на launch после миграции uid» закрыт внятным диагнозом (D1) + проактивным
+  startup-сигналом (D3); пробел процедуры ADR-040 закрыт (INFRA.md).
+- Нулевая регрессия enduro-trails (scope first); инварианты конвейера/схема БД — байт-в-байт.
+- Никакого root-контекста/рестарта прода/касания `main`/force-push/прод-образа (NFR-1).
+- Плата: фактический `chown` остаётся ручным операторским шагом (но теперь внятным, с инструкцией);
+  +1 best-effort startup-хук и leaf-модуль; `fs_normalize_auto=True` под root реинтродуцирует
+  chown-контекст (дефолт `False`, не для прод-self).
+- Аддитивно/обратимо: **не** `arch:major-change` (нет новой стадии/QG/таблицы/смены топологии) — leaf
+  + startup-хук + docs.
+- **Откат:** `fs_normalize_enabled=False` → полный no-op (мгновенный обратимый kill-switch).
+
+## Связи
+adr-0005 (контейнер под host-uid — порождающее решение ORCH-040, чей пробел закрываем),
+adr-0029/adr-0012 (coverage/security-гейт — паттерн условного leaf `applies`/scope/never-raise/
+fail-open), adr-0017 (serial-gate — leaf never-raise + отложенный срез ветки `_materialize_deferred_
+branch`, чья точка падает в `ensure_worktree`), adr-0011 (job-reaper — образец best-effort
+startup-хука в `lifespan`), adr-0024 (disk-watchdog — образец «только читать/уведомлять, не трогать
+хост/прод»).

docs/architecture/adr/adr-0032-bug-fast-track.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0032: Багфикс-трек — укороченный маршрут конвейера для багов (ORCH-019)
+
+## Статус
+Proposed
+
+## Контекст
+
+Любая задача идёт по полному конвейеру `analysis → architecture → development → review → testing
+→ deploy-staging → deploy → done`. Для мелкого бага стадия `architecture` (отдельный прогон
+opus-агента `architect` + ADR + exit-гейт `check_architecture_done`) избыточна и тратит
+токены/время (прецедент ET-9/ET-014 ~35 мин).
+
+**Корневой инвариант (нерушимый):** упрощаем только *аналитику/архитектуру*; ни один Quality
+Gate / под-гейт (security/merge/coverage/image-freshness) / exit-код deploy-хука — НЕ ослаблен
+(урок ET-8: срезанная проверка = недоделка на проде).
+
+Кросс-каттинговость: затрагивает семантику маршрутизации (`advance_stage`), вводит новый
+leaf-компонент `src/bug_fast_track.py` и аддитивную колонку `tasks.track` → регистрируется
+сквозным ADR.
+
+## Решение
+
+Багфикс-трек — **свойство планировщика/точки входа, НЕ Quality Gate**.
+
+1. **Классификация** (`src/bug_fast_track.py`, leaf never-raise по образцу `serial_gate`/`labels`):
+   задача с меткой Plane `Bug` (`bug_fast_track_label`, читается аппаратом ORCH-089
+   `labels.has_label`) помечается `track='bug'`. `applies(repo)` (локально, без сети) — первым;
+   `has_label` (сеть) — только при `applies==True`; чтение метки **только** в `start_pipeline`,
+   никогда в горячем `claim_next_job` (anti-stall).
+
+2. **Хранение** — аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'`
+   (`_ensure_column`, паттерн `tasks.cancelled_at` ORCH-090); читается в `advance_stage` из БД
+   (не из сети).
+
+3. **Routing-override** — `STAGE_TRANSITIONS` и `get_next_stage`/`get_agent_for_stage` остаются
+   **чистыми** (1:1). В `advance_stage`, на ребре выхода из `analysis`, при `track='bug'`:
+   `next_stage` → `development` (вместо `architecture`), `next_agent` → `developer` (вместо
+   `architect`). Багфикс физически минует стадию `architecture` → её exit-гейт
+   `check_architecture_done` и `06-adr/` для багфикса не исполняются.
+
+4. **Гейт `analysis` не трогаем** — `check_analysis_complete`/`check_analysis_approved` байт-в-байт
+   прежние; lite-аналитик эмитит все 4 файла (01-bug-report / 02-03 краткие заглушки / 04 план
+   обязательного регресс-теста). Экономия — пропуск всей стадии `architecture`, не число файлов.
+
+5. **Эскалация** (обратимость) — `POST /bug-fast-track/escalate?work_item=<id>` сбрасывает
+   `track→'full'` (+ self-escalate мини-аналитика); задача далее идёт через `architecture`.
+
+6. **Условность/откат** — `bug_fast_track_enabled` (kill-switch), `bug_fast_track_label`,
+   `bug_fast_track_repos` (CSV; **пусто → self-hosting only**). `False`/неприменимый репо →
+   путь старта и маршрут **байт-в-байт** прежние.
+
+7. **Наблюдаемость** — read-only блок `bug_fast_track` в `GET /queue` (флаг/область/метка +
+   счётчик `track='bug'` + метрика экономии из `agent_runs`); лог на решение о маршруте; опц.
+   `🐞` в Telegram-карточке.
+
+## Кросс-каттинговые инварианты (НЕ нарушаются)
+
+- `STAGE_TRANSITIONS` структурно не меняется (нет новых/удалённых стадий); `cancelled`/`done`
+  стоки и предикаты терминальности (ORCH-090) не затронуты.
+- Реестр `QG_CHECKS`, сигнатуры `check_*`, вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/
+  `staging_status:`/`security_status:`/`coverage_status:`), порядок под-гейтов — байт-в-байт.
+- Врезка ORCH-019 в `advance_stage` — ТОЛЬКО на ребре выхода из `analysis`, ДО всех deploy-edge
+  под-гейтов (ORCH-022/043/027/058) и Phase A/B (ORCH-036/059) → их инварианты сохранены.
+- Композиция с serial-gate (ORCH-088), auto-label (ORCH-089), coverage-gate (ORCH-027),
+  merge-gate (ORCH-043) — багфикс-задача остаётся обычной задачей репо.
+
+## Последствия
+
+- **+** Багфикс минует стадию `architecture` (основная экономия), гейты качества сохранены.
+- **+** Аддитивно, под kill-switch, per-repo, never-raise, fail-safe → полный цикл; нулевая
+  регрессия для enduro и orchestrator при выключении.
+- **−** lite-аналитик эмитит 02/03 заглушки (компромисс ради неизменности гейта); эскалация v1
+  требует операторского действия (авто-триаж сложности — будущее, ORCH-13/Вариант 3).
+- **Откат:** `bug_fast_track_enabled=False` (мгновенно); колонка `tasks.track` аддитивна и
+  безвредна (дефолт `'full'`).
+
+## Связанные решения
+- ORCH-089 (auto-label) — переиспользуемый аппарат label-чтения: [adr-0018](adr-0018-auto-label-gates.md)
+- ORCH-088 (serial gate) — композиция очереди репо
+- ORCH-027 (coverage-gate) — структурный союзник BR-4: [adr-0029](adr-0029-coverage-gate.md)
+- ORCH-090 (cancelled) — паттерн аддитивной колонки `tasks.*`: [adr-0026](adr-0026-stop-cancel-task.md)
+
+## Ссылки
+- Детальный ADR задачи: `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-019/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+</content>

docs/architecture/adr/adr-0033-sidecar-watchdog.md

@@ -0,0 +1,85 @@
+---
+work_item: ORCH-100
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0033: Sidecar-watchdog F1b — мозг мониторинга в отдельном контейнере
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-100 (FND/F1b)
+- **Детальный ADR:** `docs/work-items/ORCH-100/06-adr/ADR-001-sidecar-watchdog.md`
+- **Парный ADR:** `adr-0030` (F1a `/metrics` — источник сырья)
+
+## Контекст
+Домен 0 «Фундамент» эпика автономного саморазвития, рамка наблюдаемости заказчика: **наблюдатель
+отделён от наблюдаемого**. F1a (adr-0030) отдаёт read-only `GET /metrics` — **только сырьё**. F1b —
+**мозг**: читает сырьё, дополняет внешними сигналами (хост/контейнеры/зависимости), решает по порогам,
+алертит. Частичные стражи (`disk_watchdog`/`reaper`/`reconciler`) живут ВНУТРИ процесса орка — орк
+завис/упал ⇒ они мертвы, платформа слепа в критический момент. Рамки: C-1 (отдельный контейнер, код в
+`watchdog/`), C-2 (без внешнего плеча — принятый риск), C-3 (тонкий стек, НЕ Grafana/Prometheus; хост
+впритык). Критический инвариант: орк лёг ⇒ `/metrics` недоступен = **сам сигнал тревоги**.
+
+## Решение
+Новая папка `watchdog/` — **тонкий Python-3.12-stdlib демон** (без сторонних зависимостей), отдельный
+образ `watchdog/Dockerfile` + сервис `orchestrator-watchdog` в `docker-compose.yml` (`network_mode:
+host`, read-only `docker.sock`, `mem_limit: 128m`, `restart: unless-stopped`). Тик: (1) `GET /metrics`;
+(2) хост (диск/inode/память/CPU, stdlib); (3) статусы контейнеров через read-only `docker.sock`
+(GET-only — без `docker` SDK); (4) пинг Plane/Gitea/Anthropic. Сигналы проходят через **обобщённую
+чистую** `decide(signal_active, prev, now, cooldown) -> alert|realert|recovery|none` (генерализация
+`disk_watchdog.decide_action`; per-signal in-memory `AlertState`). Алерт — в **собственный** Telegram-
+канал sidecar (свои `WATCHDOG_TG_*`; **НЕ** импорт `src/notifications.py`). Особый сигнал — `/metrics`
+не отвечает → `orch_down`. Всё never-raise (per-source/per-tick/per-send), под kill-switch
+`WATCHDOG_ENABLED`, строго read-only к наблюдаемому. **`src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/
+`check_*`/схема БД орка — не тронуты** (F1b вне процесса орка и вне конвейера QG).
+
+- **Стек** — Python stdlib (`urllib`, `socket`+`http.client` для docker.sock, `shutil.disk_usage`,
+  `/proc/meminfo`); pytest на чистые функции. Отвергнуты Go / `docker` SDK / Prometheus (C-3).
+- **Реестр сигналов** — `orch_down` (K подряд неудачных опросов), `host_mem`/`host_disk_crit`,
+  `agent_hung` (Δ`cpu_ticks`/`clk_tck`/Δ`generated_at` < floor при растущем `runtime_s`; нужно 2
+  опроса — sidecar stateful-арбитр), `stage_stuck` (`age_in_stage_s`), `job_failed` (edge),
+  `queue_depth`, `container_down` (per name), `dep_down` (per name). Пороги/интервалы/URL — из env.
+- **Владелец диск-алерта (BR-10)** — штатные 85% остаются за внутренним `disk_watchdog` (ORCH-063,
+  канал орка) ⇒ **нулевой дубль по построению**; sidecar покрывает провал «орк+disk_watchdog мертвы»
+  через `orch_down`, плюс **opt-in** (default off) независимый критический потолок `host_disk_crit`
+  (97%) — другое событие/канал, не повтор 85%.
+- **Толерантность контракта** — неизвестные ключи `/metrics` игнорируются, отсутствие опционального не
+  ошибка, рост `schema_version` → warning (зеркало аддитивной политики adr-0030).
+- **Kill-switch** `WATCHDOG_ENABLED=false` → демон инертен (idle-loop, не exit) ⇒ нулевой эффект.
+
+## Альтернативы
+- **Go / `docker` SDK / `requests`** — отклонено: вес/вторая цепочка против C-3 и консистентности с
+  `disk_watchdog`.
+- **Prometheus/Grafana/TSDB** — отклонено: прямой запрет C-3.
+- **Sidecar — единственный владелец диска** — отклонено: потеря покрытия, когда сам sidecar/Docker
+  недоступен; выбрана связка primary `disk_watchdog` + opt-in ceiling.
+- **Push из орка в sidecar** — отклонено: зависший орк не пушит; pull падает = сам сигнал `orch_down`.
+- **bridge + `host.docker.internal`** — отклонено: на Linux ненадёжно; `network_mode: host` проще.
+- **Своя БД/файл порогов** — отклонено: C-3; in-memory best-effort достаточно (как `disk_watchdog`).
+
+## Последствия
+- Внешний мозг мониторинга переживает падение орка; `orch_down` делает наблюдателя громче в инцидент.
+- Строго read-only + независимый канал + never-raise ⇒ self-hosting-безопасно (enduro не затронут);
+  падение sidecar не влияет на конвейер.
+- Аддитивно/обратимо: `src/**`/гейты/схема байт-в-байт; kill-switch → нулевая регрессия; дубль диска
+  исключён структурно.
+- Плата: новый контейнер на впритык-хосте (`mem_limit: 128m` + замер RSS на staging обязательны);
+  C-2 (падёт хост → молчит и sidecar); новая поверхность совместимости `/metrics`↔F1b (толерантный
+  парсинг + единый репо контракта); CPU-liveness Linux-специфичен.
+- **Топология** меняется (новый контейнер) → `07-infra-requirements.md`; **схема БД** не меняется →
+  08 = N/A. Новый компонент + контейнер + канал → `arch:major-change`; прод-выкат через staging-гейт
+  (8501), деплой sidecar НЕ рестартит прод-контейнер.
+- **Откат:** не запускать сервис / `WATCHDOG_ENABLED=false` (мгновенный) или удаление `watchdog/` +
+  сервиса + env — без следов в БД/схеме.
+
+## Связи
+adr-0030 (F1a `/metrics` — парный источник сырья; контракт `cpu_ticks`/`clk_tck`/`generated_at`/
+`schema_version`), adr-0024 (`disk_watchdog` — образец решающей функции/never-raise + владелец
+диск-алерта), adr-0025 (build-cache-pruner — паттерн «вторая половина»), adr-0017 (serial_gate —
+leaf `snapshot()`/never-raise), adr-0011 (job-reaper — pid/liveness-семантика). Прямой источник —
+**F1a** (`GET /metrics`); F1b — его потребитель.
+</content>

docs/architecture/adr/adr-0034-lessons-journal.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-098
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0034: Машинный журнал уроков — таблица `lessons` + observer-leaf (ORCH-098)
+
+## Статус
+Proposed
+
+## Контекст
+
+Оркестратор автономно ведёт задачи по конвейеру (ORCH-54), но **развивается** вручную: инциденты →
+уроки → задачи. Уроки живут свободным текстом в `memory/` — не машиночитаемы: нельзя считать
+паттерны, приоритизировать, предлагать улучшения. ORCH-098 — шаг 1 эпика саморазвития (домен 0
+«Фундамент», F2): «топливо» петли самообучения 8A. Нужна **структурированная таблица отклонений
+конвейера**, на которой позже встанут ретроспективщик (E2), приоритизатор RICE (E3) и Стрим.
+
+Нормативное требование Славы (10.06): схема ДОЛЖНА **сразу** нести поля **атрибуции** урока
+(`platform`/`project`/`both`/`unknown` + целевой репо + домен улучшения), иначе позже придётся
+переделывать схему на живой общей прод-БД.
+
+**Кросс-каттинговость** (почему сквозной ADR): новый компонент `src/lessons.py` + аддитивная
+таблица на **общей прод-БД** (self-hosting, разделяемой с enduro-trails) + врезки автозаписи в
+несколько горячих choke-point'ов (`stage_engine`/`merge_gate`/`launcher`) + новый раздел контракта
+`GET /queue`. Фундамент для будущих задач-потребителей → регистрируется глобально.
+
+## Решение
+
+Журнал уроков — **observer (наблюдатель), НЕ Quality Gate**. Аддитивная таблица + чистый leaf,
+по образцу `serial_gate`/`coverage_gate`/`metrics`/`bug_fast_track`.
+
+1. **Таблица `lessons`** (`db.init_db()`, `CREATE TABLE IF NOT EXISTS` + 3 индекса, идемпотентно,
+   restart-safe) — поля контекста (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализа
+   (`root_cause`/`suggestion`), статуса (`status`/`related_task`), **атрибуции сразу и нуллабельно**
+   (`attribution`/`target_repo`/`target_domain`) + `source`/`detail`. Без `enum`-констрейнтов
+   (слаги forward-compatible). Будущие колонки — `_ensure_column`.
+
+2. **Leaf `src/lessons.py`** (never-raise, импортирует только `config`+`db`): `record()` / `get()` /
+   `update()` / `snapshot()`. **Расхождение с гейт-шаблоном: журнал НЕ скоупится по репо** — он
+   observer-only и не *действует* ни на один репо; единственный регулятор — глобальный kill-switch
+   `lessons_enabled`. Запись урока про enduro ценна и **не затрагивает** пайплайн enduro (чистая
+   память орка); репо-разрез — на выборке (`repo`-колонка/фильтр).
+
+3. **Автозапись 4 типов** (`source="auto"`, best-effort, дедуп в окне; `transient_retry` — только на
+   исчерпании бюджета ретраев): `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`),
+   `merge_hold` (`merge_gate._handle_merge_verify` HOLD), `transient_retry` (merge-retry/launcher
+   transient budget-exhaustion), `deploy_degraded` (post-deploy `DEGRADED → set_repo_freeze`, урок
+   слоя-3 «деплой OK / прод сломан», ET-8). Каждая врезка — одиночный вызов в защитном `try/except`.
+
+4. **Эндпоинты** `GET /lessons` (read-only, фильтры), `POST /lessons` (ручная запись,
+   `source="manual"`), `POST /lessons/{id}` (update — доклассификация `unknown`), + read-only ключ
+   `"lessons": snapshot()` в `GET /queue`. При выключенном флаге → `{"enabled": false}`.
+
+**Инвариант (нерушимый):** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи
+(`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`) /
+схемы существующих таблиц — **байт-в-байт не тронуты**. Журнал не влияет на продвижение по стадиям.
+
+## Композиция с существующими механизмами
+- **Self-hosting (общая БД):** аддитивная таблица; enduro не затронут (NFR-3).
+- **serial-gate (ORCH-088) / post-deploy (ORCH-021):** детектор `deploy_degraded` врезан рядом с
+  `set_repo_freeze`, не меняя freeze-логику.
+- **merge-gate (ORCH-043/071/093):** `merge_hold`/`transient_retry` читают исход актора, не меняя
+  классификатор/ретрай.
+- **metrics (ORCH-099):** журнал — историческая память петли (best-effort запись), `/metrics` —
+  realtime-сырьё для sidecar; разные роли, оба observer-only.
+
+## Условность и откат
+- Флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`; kill-switch) +
+  `lessons_dedup_window_s` / `lessons_query_limit_default`. `False` → полная инертность, нулевая
+  регрессия, конвейер байт-в-байт прежний.
+- **never-raise** на всех публичных функциях и врезках (NFR-1) — сбой журнала не роняет конвейер.
+- Откат — флаг в `false` (мгновенно) или revert диффа; таблица не касается существующих.
+
+## Последствия
+- **+** Машиночитаемые уроки — фундамент E2/E3/Стрим; атрибуция forward-proof (без передела живой БД).
+- **+** Нулевая регрессия; проверенный additive-observer-leaf шаблон → низкий риск; enduro изолирован.
+- **−** Рост таблицы (митигейшн: лёгкие строки + дедуп + budget-exhaustion; ретенция — будущее).
+- **−** Дедуп-запрос в `record()` (один indexed-SELECT, только `auto`).
+
+## Ссылки
+- Локальный ADR: `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-098/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+- Data/Infra/Risks: `docs/work-items/ORCH-098/08-data-requirements.md`, `07-infra-requirements.md`,
+  `10-tech-risks.md`
+- Эпик: `docs/epics/self-evolution.md` (домен 0 «Фундамент», F2; петля 8A)
+- Сверено по коду: `src/serial_gate.py`, `src/coverage_gate.py`, `src/db.py`, `src/stage_engine.py`,
+  `src/merge_gate.py`, `src/agents/launcher.py`, `src/main.py`, `src/qg/checks.py`.

docs/architecture/adr/adr-0035-turnkey-project-onboarding.md

@@ -0,0 +1,80 @@
+---
+work_item: ORCH-009
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0035: Turnkey-онбординг проектов — kit + операторский CLI + runbook (ORCH-009)
+
+## Статус
+Proposed
+
+## Контекст
+
+Подключение нового проекта к оркестратору — ручная археология по разрозненным докам и памяти;
+каждый пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не работает
+вовсе (launcher резолвит `.openclaw/agents/<role>.md` относительно worktree репо задачи); без
+точных имён статусов Plane ветки `Confirm Deploy` (ORCH-059) / `STOP` (ORCH-090) молча не
+активируются (fail-closed); без лейблов `autoApprove`/`autoDeploy`/`Bug` авто-режимы (ORCH-089)
+и багфикс-трек (ORCH-019) молча выключены (fail-safe). Эталон онбординга — **сам репозиторий
+orchestrator** (каноны ORCH-52b/c/d/e кодифицированы в `docs/_templates/`, `docs/_standards/`,
+`.openclaw/agents/`). Домен D5.2 эпика саморазвития: способность разворачивать новый проект
+одним проходом.
+
+## Решение
+
+Способность реализуется **вне рантайма и вне конвейера** — `src/**` байт-в-байт не меняется
+(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД/контракт `projects.py`
+нетронуты), kill-switch не нужен (активация — только явный запуск операторского CLI):
+
+1. **Onboarding-kit `onboarding/repo-skeleton/`** — параметризуемый каркас нового репо:
+   6 промптов агентов канона 52d/92 (5 XML-секций, «❌→✅», эмиссия схемы 52c, verdict-ключи
+   байт-в-байт; язык — канон орка: 5 ru + deployer en), паспорт `CLAUDE.md`, `AGENTS.md`
+   (точка входа агентов), `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/` с
+   обязательным `operations/INFRA.md`, `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер
+   (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция со
+   вхождениями в kit держится тестами). **Канон не форкается:** `docs/_templates/` +
+   `docs/_standards/` НЕ хранятся в kit — копируются live из чекаута орка в момент материализации.
+2. **Операторский CLI `scripts/onboard_project.py`** — `plan` (дефолт, GET-only, ни одной
+   мутации) / `apply` (идемпотентный ensure, без delete-операций) / `verify`. Шаги: Plane-проект →
+   22 статуса с точными именами из `plane_sync._PLANE_NAME_TO_KEY` (read-only импорт — нулевой
+   дрейф; канонические группы фиксированы: `STOP`→`cancelled`, терминальные группы только у
+   Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит) → лейблы → Gitea-репо
+   (+per-repo webhook `push`/`pull_request`/`status`; HMAC-секрет **переиспользуется** из
+   `ORCH_GITEA_WEBHOOK_SECRET` — приёмник один на все репо) → материализация kit + initial push
+   **только в свежесозданный пустой репо** (INV-4 не затрагивается) → merged-вывод
+   `ORCH_PROJECTS_JSON`, провалидированный фактическим `projects._parse_projects_json`
+   (round-trip). Недоступное в Plane CE API → `manual-step` со ссылкой на runbook (fail-safe).
+   Скрипт **никогда** не рестартит прод, не правит `.env`, не пушит в существующие репо, ничего
+   не удаляет.
+3. **Runbook `docs/operations/ONBOARDING.md`** — полный чеклист: предусловия (токены) → скрипт →
+   операторские шаги (env + управляемый рестарт с self-hosting-предупреждением; UI-only Plane) →
+   верификация (`verify` + smoke) → откат. Smoke-контур — **staging (8501, изолированная БД)** +
+   одноразовый sandbox-проект (`SMK`); протокол — «Журнал smoke-прогонов» в runbook.
+
+Анти-дрейф — структурные тесты kit (аналог `tests/test_agent_prompts_canon.py`) + снапшот-тест
+`STAGE_TRANSITIONS`/`QG_CHECKS` (контроль ненарушения `src`). Branch protection `main` новых репо
+**не включается** (ломала бы PR-merge API merge-актора — ложные HOLD класса ORCH-093).
+
+## Последствия
+
+- **+** Новый проект разворачивается одним проходом проверяемо: все слои (Plane-контракты,
+  webhook, промпты, дока, реестр) закрыты скриптом+runbook; тихие деградации ловит `verify`.
+- **+** Нулевой риск рантайма: изменение docs/templates/scripts/tests-only; регресс
+  enduro/orchestrator невозможен по построению; общая БД не читается и не пишется скриптом.
+- **+** Единый эталон без форка: новые репо получают живой канон момента онбординга;
+  обновления канона в них едут обычными PR с reviewer-gate.
+- **−** Регистрация в реестре остаётся операторской (env + управляемый рестарт — Ф-3,
+  сознательное ограничение NFR-2); разрыв «создано, но не зарегистрировано» виден через `verify`.
+- **−** Закрытый список read-only импортов из `src` (`projects._parse_projects_json`,
+  `plane_sync._PLANE_NAME_TO_KEY`, поля `config.settings`) — связь с приватными именами;
+  поломка при рефакторинге видимая (тесты), расширение списка — только через ADR.
+- **Ограничение:** способность ≠ исполнение: онбординг конкретного заказчика — операторская
+  эксплуатация (вне ORCH-009); тиражирование на новый хост — ORCH-10 (вне объёма).
+
+Детально: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
+(D1…D11 — раскладка, плейсхолдеры, copy-vs-template split, импорт src, группы статусов,
+webhook-секрет, формат реестра, smoke-контур, языковая политика, branch protection, форма CLI).

docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md

@@ -0,0 +1,109 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0036: Фундамент тиража платформы — параметризация хоста, секреты, smoke (ORCH-101, 10-common)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5.3 «Масштаб») — тираж платформы для заказчиков-тестеров двумя типами (A Lite /
+B Bundled), оба stateless. Платформа была фактически прибита к хосту `mva154`: четыре места в
+`src/**` обходили конфиг (внешний Gitea-URL в `plane_sync`, HOME + git-идентичности акторов в
+`launcher`/`self_deploy`/`post_deploy`), `docker-compose.yml`/`Dockerfile`/deploy-hook несли
+литералы путей/uid/gid/портов; механизма выпуска нового комплекта секретов и процедуры верификации
+развёрнутой копии не существовало. ORCH-101 (10-common) — общий фундамент обоих типов тиража.
+
+Это сквозное решение: оно задаёт **платформенные конвенции тиража** и трогает блоки, помеченные
+маркерами ORCH-036/ORCH-040/ORCH-058 (по `docs/_standards/TRACEABILITY.md` — сводный ADR вместо
+архео-перечисления). Детальный пакет решений (D1…D10) — work-item ADR:
+`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`.
+
+## Решение
+
+**Принцип: «дефолт = боевое значение».** Каждое хост-специфичное значение читается из конфига
+(`Settings` env `ORCH_*` / compose-интерполяция `${VAR:-default}` / Dockerfile `ARG` /
+shell-default хука) с дефолтом, равным текущему боевому значению. Отсутствие новых переменных =
+байт-в-байт текущее поведение (kill-switch-природа; отдельный функциональный флаг не вводится).
+`src/config.py` и `watchdog/config.py` — единственные легитимные места хост-литералов в коде.
+
+**Новые конфиг-ключи:** `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, `/home/slin`) — HOME всех
+акторских процессов; `agent_git_name` (`claude-bot`) + `git_email_domain` (`mva154.local`) —
+git-идентичности (`<actor>@<domain>`; системные акторы `deploy-finalizer`/`post-deploy-monitor` —
+платформенные литералы); `staging_port` (`ORCH_STAGING_PORT`, `8501`). Ссылки в Plane-комментариях —
+из существующих `gitea_public_url`/`gitea_owner`. Compose-слой — карта `ORCH_HOST_*`/
+`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID` + реюз `ORCH_DEPLOY_*`; порт прод/стейджинг — явные `command:`
+с `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}` / `${ORCH_STAGING_PORT:-8501}` (CMD образа не трогается —
+exec-form + `init: true` сохранены).
+
+**Платформенные конвенции тиража (нормативно):**
+1. **`SELF_HOSTING_REPO = "orchestrator"` — константа, не конфиг.** На ней «empty CSV →
+   self-hosting only» всех `*_repos`-leaf'ов; конфигурируемость превращала бы опечатку env в
+   активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов. Репо платформы
+   в тираже обязан называться `orchestrator` (REPLICATION.md).
+2. **Имена compose-сервисов/контейнеров/образов, профиль `staging`, `network_mode: host`,
+   контейнерный layout (`/app/data`, `/repos`, `/opt/claude-code`)** — конвенции, не переменные
+   (для образов истина уже в конфиге `deploy_prod_*_image`).
+3. **Staging-порт конфигурируем ТОЛЬКО с fail-closed guard'ом** (усиление инварианта ORCH-058
+   AC-9): freshness-путь отказывает ДО любого ssh/build при
+   `staging_port == deploy_prod_target_port` — без тихого fallback. Explicit-pass таргета хуку
+   (`TARGET_PORT=` и др.) сохранён; добавлена явная передача `REPO=` обоими инвокерами хука
+   (его строка 38 становится `"${REPO:-…}"` — exit-контракт 0/1/2 ORCH-036 не тронут).
+4. **Группа ORCH-040 неделима:** uid/gid/HOME/маунт-таргеты/`useradd` управляются одними env
+   насквозь (`ORCH_RUN_UID/GID`, `ORCH_AGENT_HOME_DIR` → compose `user:`/таргеты/`build.args
+   APP_*`); `group_add` docker-gid («МИНА 1») не удаляется — литерал станет
+   `${ORCH_DOCKER_GID:-999}`.
+
+**Секреты нового хоста:** stdlib-скрипт `scripts/gen_secrets.py` — криптослучайные webhook-секреты
+(`secrets.token_hex(32)`), печать по умолчанию, `--write` отказывает при существующем `.env`
+(перезапись — только явный `--force`); внешние токены (Plane/Gitea/Telegram/watchdog) — по
+чек-листу. Норматив: **боевые секреты текущего хоста не копируются ни на одном шаге**.
+
+**Smoke-верификация тиража:** runbook `docs/operations/REPLICATION.md` (deployment golden source:
+карта env, чек-лист секретов, пошаговый smoke с PASS/FAIL: `compose config` → `/health` →
+`/queue`+`/metrics` → `onboard_project.py plan/apply/verify` → тестовая задача → артефакты `01–04`
+в ветке; расширенно — до `done`; границы 10-common vs Lite vs Bundled). Нового smoke-скрипта нет —
+шаги собраны из существующих кирпичей.
+
+**Анти-регресс (постоянная CI-гарантия):** структурный сканер `tests/test_no_host_hardcodes.py` —
+запрещённые литералы (`82.22.50.71`, `/home/slin`, `mva154`, `duckdns`; список централизован) в
+исполняемом коде `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов;
+структурное исключение двух config-модулей (канон дефолтов); allowlist пуст; негативная
+самопроверка.
+
+### Что НЕ меняется
+`STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД —
+байт-в-байт; значения существующих конфиг-дефолтов; INV-4; прод-контейнер в рамках задачи не
+рестартуется (правки compose/Dockerfile инертны до штатного деплоя через staging 8501 →
+`Confirm Deploy`).
+
+## Альтернативы
+- **`ORCH_SELF_HOSTING_REPO` конфигом** — отвергнуто: узел безопасности; опечатка = групповой риск.
+- **Staging-порт константой** — отвергнуто: compose-порт параметризуется (AC-6), константа дала бы
+  рассинхрон слоёв; пара «ключ + guard» строго сильнее.
+- **Smoke-скрипт-обвязка / генератор в `onboard_project.py`** — отвергнуто: лишняя поверхность;
+  разные жизненные циклы (онбординг проекта ≠ provisioning хоста).
+
+## Последствия
+- Платформа разворачивается на чужой инфре env-конфигурацией; критический путь ORCH-10 разблокирован
+  (Lite/Bundled строятся поверх REPLICATION.md).
+- Инвариант ORCH-058 переходит из «подразумеваемого константой» в исполняемый guard; возврат
+  хост-хардкода ломает CI структурно.
+- Цена: ~13 новых env-имён (на текущем хосте настраивать нечего — дефолты боевые) и правило
+  «интерполяция читает `.env`/shell, не `env_file`» (зафиксировано в REPLICATION.md).
+- Откат: не задавать переменные (дефолты = прежнее поведение); полный — revert PR (без миграций).
+
+## Связи
+adr-0005 (ORCH-040 — uid/HOME/«МИНА 1»; группа становится параметризуемой, инвариант сохранён),
+adr-0008 (ORCH-058 — INV-FRESH/AC-9; guard усиливает), adr-0007 (ORCH-036 — exit-контракт хука
+не тронут), adr-0035 (ORCH-009 — onboarding переиспользуется smoke-процедурой; kit не форкается),
+adr-0001 (`is_self_hosting_repo` — конвенция имени закреплена). Детально —
+`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md` (D1…D10),
+`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0037-lite-replication-canon.md

@@ -0,0 +1,96 @@
+---
+work_item: ORCH-102
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0037: Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` (ORCH-102, 10a)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **A — Lite**: раздача орк+watchdog заказчику-тестеру, окружение
+(Plane/Gitea/LLM/Telegram) он донастраивает сам. Фундамент 10-common (ORCH-101, adr-0036) в
+`main`: технически платформа разворачивается без правки кода, но операционно знания размазаны по
+4 operations-докам, писанным для оператора НАШЕГО хоста, — заказчик не может развернуть Lite без
+доп-вопросов. Решения Владельца 10.06: оба типа тиража stateless; главный продукт ORCH-102 —
+инструкция-golden-source в репо.
+
+Сквозной характер: вводится новый docs-раздел, новый канонический example-файл и нормативы,
+обязательные для всех будущих задач эпика ORCH-10 и для любого агента, меняющего шаги тиража.
+Детальный пакет решений (D1…D9, исходы вопросов ТЗ А-1…А-6) — work-item ADR:
+`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`.
+
+## Решение
+
+1. **Новый docs-раздел `docs/deployment/` — витрина тиража.** Семантика: `deployment/` — «как
+   развернуть платформу у себя» (читатель — внешний оператор), `operations/` — «как
+   эксплуатировать наш прод». Golden source Lite — **`docs/deployment/LITE_SETUP.md`**:
+   сквозной маршрут «голый хост → работающий конвейер» из 13 нормативных разделов (рамка →
+   предусловия → код → конфиг/секреты → Plane → Gitea → LLM → Telegram → запуск → онбординг →
+   smoke → stateless-проверка → траблшутинг); каждый шаг = fenced-команда + явная проверка
+   (PASS/FAIL); хост-специфика — только плейсхолдеры. Канон не форкается: статусы/env/вебхуки —
+   ссылками на ONBOARDING/REPLICATION/SETUP_WEBHOOKS (`REPLICATION.md` остаётся в
+   `operations/`; перекрёстные ссылки в обе стороны). **Норматив сопровождения:** изменение
+   шагов тиража → обновление LITE_SETUP.md в том же PR (правило агентов №2).
+2. **Compose не форкается.** `docker-compose.yml` сам является Lite-подмножеством (ровно
+   `orchestrator` + `orchestrator-watchdog` + `orchestrator-staging` за `profiles: [staging]`;
+   дефолтный `up -d` поднимает орк+watchdog; сервисов Plane/Gitea нет) — отдельный
+   `docker-compose.lite.yml` не вводится; свойство становится CI-гарантией (структурный тест
+   через `yaml.safe_load`).
+3. **`.env.watchdog.example` — третий канонический env-example** (рядом с `.env.example`/
+   `.env.staging.example`): закрывает ловушку файла-носителя (sidecar читает ТОЛЬКО
+   `.env.watchdog`; ключ `WATCHDOG_*` в `.env` для него инертен). Key-set = ровно блок
+   `WATCHDOG_*` из `.env.example` (равенство множеств держит тест); токены — плейсхолдеры;
+   шапка несёт C-1 ORCH-100 (отдельный watchdog-бот, токен орка переиспользовать запрещено)
+   и когерентность `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`.
+4. **Норматив тиражной инсталляции Gitea: branch protection на `main` НЕ включать; pre-receive
+   хуки не вводятся** (подтверждение ORCH-009 ADR-001 D10 для чужих инсталляций:
+   required-approvals/status-checks ломают PR-merge API merge-актора → ложные HOLD; защита
+   `main` — конвенция + скоуп токенов + INV-4).
+5. **Staging-контур в Lite опционален:** базовый контур заказчика = prod-оркестратор + watchdog;
+   песочница 8501 нужна только при self-hosting развитии платформы у заказчика (регистрация
+   проекта `orchestrator`); guard ORCH-058 (staging-порт ≠ прод-порт) действует.
+6. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_lite_setup_doc.py` (структурный, без
+   сети/LLM): разделы/кирпичи дока, env-ключи дока ⊂ `.env.example`, key-sync watchdog-example,
+   compose-подмножество, stateless-норматив + отсутствие секретов/боевых литералов в
+   fenced-блоках (реюз центрального `FORBIDDEN` из `tests/test_no_host_hardcodes.py` импортом),
+   перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
+
+### Что НЕ меняется
+`src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**`; `STAGE_TRANSITIONS`, состав
+`QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД — байт-в-байт. Новый QG не
+регистрируется (структурные тесты попадают в существующие гейты). Прод-контейнер в рамках
+задачи не рестартуется (выкат — штатно: staging 8501 → `Confirm Deploy`).
+
+## Альтернативы
+- **Инструкция в `docs/operations/`** — отвергнуто: другой целевой читатель; путь зафиксирован
+  Владельцем (D-4).
+- **`docker-compose.lite.yml`** — отвергнуто: вторая правда о сервисах = дрейф-поверхность.
+- **Pre-receive/branch protection как «защита `main`»** — отвергнуто: класс инцидента ORCH-063
+  (ложные HOLD merge-актора); пересмотр — только отдельным ADR.
+- **Без example-файла watchdog (шаг прозой)** — отвергнуто: двусмысленность файла-носителя
+  остаётся; example + key-sync тест надёжнее.
+
+## Последствия
+- Type A эпика ORCH-10 закрыт продуктом-инструкцией; Type B (Bundled) строится поверх
+  (переиспользует разделы Lite). Полнота инструкции и compose-подмножество защищены CI.
+- Цена: новый golden source требует сопровождения (норматив «в том же PR» + структурный тест
+  рвёт CI при дрейфе); осознанный дубль ключей `WATCHDOG_*` в двух example-файлах — под
+  key-sync тестом.
+- Откат: удалить `docs/deployment/`, тест и `.env.watchdog.example`, вернуть строку
+  REPLICATION.md §1 — состояние 1:1 (docs+tests, без миграций).
+
+## Связи
+adr-0036 (ORCH-101 — фундамент 10-common; этот ADR строит слой Lite поверх), adr-0035
+(ORCH-009 — onboarding-CLI/kit переиспользуются маршрутом §5/§6/§10; D10 подтверждён п.4),
+adr-0033 (ORCH-100 — sidecar-watchdog; C-1 независимый Telegram-канал закреплён в example),
+adr-0008 (ORCH-058 — staging-порт guard, вилка staging п.5), adr-0027/INV-4 (merge-актор —
+основание запрета branch protection). Детально —
+`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`,
+`docs/work-items/ORCH-102/10-tech-risks.md`.

docs/architecture/adr/adr-0038-bundled-replication-canon.md

@@ -0,0 +1,114 @@
+---
+work_item: ORCH-103
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# adr-0038: Канон Bundled-тиража — `deploy/bundled/` + bootstrap + `BUNDLED_SETUP.md` (ORCH-103, 10b)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **B — Bundled**: заказчик без собственной инфраструктуры
+получает **весь стек одним комплектом** (орк + watchdog + Gitea + Plane CE ≈13–14 контейнеров) и
+bootstrap, доводящий его до рабочего конвейера одним запуском. Фундамент готов: 10-common
+(ORCH-101, adr-0036 — хост-параметризация/секреты/smoke) и Lite (ORCH-102, adr-0037 — док-канон
+`docs/deployment/`). Корневой `docker-compose.yml` заморожен анти-дрейфом ORCH-102 (ровно 3
+сервиса, запрет подстрок `plane`/`gitea`) → комплект обязан жить отдельным файлом.
+
+Сквозной характер: вводится новый top-level каталог `deploy/` (дистрибутивы развёртывания),
+новый канонический env-example и нормативы, обязательные для будущих задач эпика ORCH-10 и
+любого агента, меняющего шаги тиража. Детальный пакет решений (D1…D11, исходы OQ-1…OQ-7 ТЗ) —
+work-item ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`.
+
+## Решение
+
+1. **Новый top-level каталог `deploy/` — исполняемые дистрибутивы развёртывания** (дополняет
+   `docs/deployment/` — инструкции). Bundled-комплект: **`deploy/bundled/docker-compose.yml`** —
+   один самодостаточный compose всего стека с top-level `name: orchestrator-bundle` (project
+   name = узнаваемый префикс томов/контейнеров; `container_name` не пиннится — нет коллизий с
+   корневым compose на одном хосте). Staging-контур орка в bundle **отсутствует вовсе**; репо
+   `orchestrator` в bundle-инсталляции не регистрируется → self-deploy-машинерия структурно спит
+   (`SELF_HOSTING_REPO`-леафы не матчатся).
+2. **Конфиг-слои:** `deploy/bundled/.env.example` — канон bundle-инфры (committed, плейсхолдеры;
+   key-set-sync тест: каждая `${VAR}`-интерполяция bundle-compose имеет ключ в каноне) → live
+   `deploy/bundled/.env` (авто-чтение compose из project dir — без `--env-file`-футгана; покрыт
+   неякорным `.env` в `.gitignore`); runtime орка/watchdog — **корневые `.env`/`.env.watchdog`
+   ровно по канону Lite** (REPLICATION §2 применим 1:1), в bundle-compose — `env_file:
+   required: false` (первый `up` жив до сборки конфига). **Bootstrap — единственный писатель**
+   всех трёх live-файлов (когерентность дублируемых ключей — механическая). Один факт = одно имя
+   (ORCH-101 D1): существующие факты — существующие `ORCH_*`-имена; bundle-only — `BUNDLE_*`;
+   внутренние креды Plane — upstream-имена.
+3. **Состав/пиннинг:** Plane CE — зеркало официального selfhost-référence (upstream-имена
+   сервисов/env); Gitea — `gitea/gitea` (не rootless). Пиннинг — **точный неподвижный тег
+   литералом** (не `latest`, не интерполяция; digest не требуется); точные теги фиксирует
+   developer по проверенному стенду; форму держит структурный тест.
+4. **Сеть:** одна именованная bridge-сеть; машинный трафик — строго сервис-DNS
+   (`http://orchestrator:8500/webhook/*`, `http://gitea:3000`, plane-proxy); `network_mode: host`
+   в bundle не используется (ssh-деплой-пути неактивны: `ORCH_DEPLOY_SSH_HOST` пуст). Наружу —
+   только человеческие порты (Plane proxy 8080 / Gitea 3000 / орк 8500; конфигурируемы);
+   БД/брокер/minio не публикуются. Публичные URL — от `BUNDLE_PUBLIC_HOST` (split internal/public
+   уже в конфиге орка). Мина Gitea закрывается явно: `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`.
+5. **Bootstrap `scripts/bootstrap_bundle.py`:** python stdlib-only, без импортов из `src/**`;
+   режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`; step-движок check→ensure
+   (идемпотентность, resume = повторный запуск); exit `0/2/1`. Preflight fail-fast до мутаций
+   (docker/порты/чистота томов по префиксу/RAM/диск; Claude CLI — warning). **Кирпичи не
+   дублируются:** секреты — субпроцесс `gen_secrets.py`; статусы/лейблы/репо/вебхуки — строго
+   `onboard_project.py apply`+`verify` (host-venv, канон ONBOARDING). Init Gitea — полностью
+   автоматом (CLI в контейнере; branch protection НЕ настраивается — D10 ORCH-009/adr-0037 п.4);
+   init Plane CE — честные **manual-step чекпоинты** (инструкция → подтверждение →
+   API-верификация; прогрессивная автоматизация разрешена без смены контракта). Git-доступ
+   агентов — HTTP token-remote (паттерн `_push_url`); ssh-контур не вводится. Секреты в
+   логи не печатаются; delete-операций в скрипте нет вообще — teardown только документированной
+   процедурой (`BUNDLED_SETUP` §13).
+6. **Док-канон:** `docs/deployment/BUNDLED_SETUP.md` — 14 нормативных разделов по форме
+   LITE_SETUP (fenced-команда + «Проверка:» PASS/FAIL, плейсхолдеры, общие шаги ссылками на
+   LITE_SETUP/ONBOARDING/REPLICATION — канон не форкается), включая «Требования к хосту» с
+   цифрами **по замеру** тестового развёртывания. REPLICATION §1: Type B → ✅ ORCH-103.
+   **Норматив сопровождения:** изменил шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
+7. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_bundle_compose.py` /
+   `test_bundled_setup_doc.py` / `test_bootstrap_script.py` (структурные, без docker/сети/LLM:
+   состав сервисов, заморозка корневого compose, пины, key-set-sync, разделы дока, FORBIDDEN —
+   импортом из `test_no_host_hardcodes.py`, секрет-эвристика, ссылки на кирпичи, отсутствие
+   delete-операций, unit чистых функций preflight/плана, exit-контракт).
+
+### Что НЕ меняется
+`src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**`, `onboarding/**`,
+промпты `.openclaw/agents/**`; `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`,
+machine-verdict ключи, схема БД — байт-в-байт. Kill-switch не вводится (активация — только явный
+запуск оператора на целевом хосте, паттерн ORCH-009). Прод-контейнер в рамках задачи не
+рестартуется; наши данные/секреты не переносятся (stateless, решение Владельца 10.06).
+
+## Альтернативы
+- **Расширение корневого compose (профиль `bundled`)** — отвергнуто: заморожен анти-дрейфом
+  ORCH-102/нормативом «compose не форкается»; смешение дистрибутива с боевым контуром.
+- **Include-композиция / live-env через `--env-file`** — отвергнуто: лишние степени свободы
+  запуска, молчаливые дефолты при забытом флаге.
+- **Орк в bundle на host-network + `host-gateway`** — отвергнуто: хост-сеть нужна была
+  ssh-деплой-контуру нашего хоста, который в bundle спит; bridge даёт чистые двунаправленные
+  сервис-DNS-URL.
+- **Digest-пиннинг / rootless-Gitea / ssh-доступ агентов / bash-bootstrap / reset-режим
+  скрипта** — отвергнуты (см. work-item ADR-001, «Альтернативы»).
+
+## Последствия
+- Эпик ORCH-10 закрыт по обоим типам: A (Lite, инструкция) + B (Bundled, комплект); заказчик
+  без инфраструктуры разворачивает конвейер «под ключ».
+- Цена: пиннованные версии Plane/Gitea стареют (апгрейд — отдельные задачи); manual-step Plane CE
+  размывают «одну команду» — неустранимо честно (нет API), митигировано контрактом чекпоинта;
+  двойной `.env`-слой — под единственным писателем-bootstrap и key-sync тестом.
+- Откат: удалить `deploy/`, bootstrap, BUNDLED_SETUP.md, три тест-модуля, строку REPLICATION §1 —
+  состояние 1:1 (docs+scripts+tests, без миграций).
+
+## Связи
+adr-0036 (ORCH-101 — фундамент 10-common: параметризация, gen_secrets, REPLICATION/smoke),
+adr-0037 (ORCH-102 — док-канон `docs/deployment/`, compose-подмножество, запрет branch
+protection), adr-0035 (ORCH-009 — onboarding-CLI: 22 статуса, manual-step паттерн, `_push_url`,
+D10), adr-0027/INV-4 (merge-актор — основание норматива Gitea), adr-0001
+(`SELF_HOSTING_REPO`-конвенция — почему self-гейты в bundle спят). Детально —
+`docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
+`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0039-system-overview-docs-canon.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-011
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# adr-0039: Витрина системы `docs/overview/` — единая точка входа (бизнес + тех) и канон презентации (ORCH-011)
+
+## Статус
+Proposed
+
+## Контекст
+
+Документация платформы богатая, но фрагментированная: паспорт `CLAUDE.md` (реестр доработок),
+тех-витрина `README.md`, vision `docs/PRODUCT_VISION.md`, инженерный справочник
+`docs/architecture/` (~1246 строк + internals), 38 сквозных ADR, стандарты, операционные и
+deployment-доки. Единой точки входа «бизнес + тех» для трёх аудиторий (заказчик / менеджер /
+разработчик) нет; презентацию о возможностях собирать не из чего. С тиражируемостью
+(ORCH-101/102/103) появился внешний читатель. Решения Владельца: слайды PowerPoint в тёмном
+дизайне; единое место — `docs/`; витрина поддерживается актуальной.
+
+Живые доказательства проблемы в самом репо: схема конвейера в `PRODUCT_VISION.md` §2 устарела
+(нет `deploy-staging`/`cancelled`); `docs/PRODUCT_VISION.pptx` закоммичен **без пути генерации**
+(невоспроизводим). Reviewer-ось обзорных доков (ORCH-079, adr-0023) по букве привязана к
+`README.md` «Известные ограничения» — новую витрину не покрывает.
+
+Сквозной характер: вводится новый docs-раздел с нормативом сопровождения, обязательным для
+**всех будущих функциональных PR**, расширяется reviewer-ось и фиксируется канон
+презентационных артефактов. Детальный пакет решений (D1…D9, исходы OQ-1…OQ-5) — work-item ADR:
+`docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`.
+
+## Решение
+
+1. **Новый docs-раздел `docs/overview/` — витрина системы.** Семантика разделов после ORCH-011:
+   `overview/` — «что это за система и как устроена» (вход для любой аудитории), `architecture/`
+   — инженерный справочник, `deployment/` — «как развернуть у себя», `operations/` — «как
+   эксплуатировать наш прод», `_standards/` — нормативы агентов. Состав — плоский каталог,
+   10 файлов: индекс `README.md` (точка входа, 3 маршрута аудиторий, норматив сопровождения),
+   `business.md` (бизнес-уровень: проблема → решение → способности → ценность → сценарии; без
+   жаргона; числа только с подтверждением), 7 файлов `tech-*.md` = 7 блоков контент-карты
+   (архитектура / конвейер / агенты / модель объектов / интеграции / качество-безопасность /
+   наблюдаемость), `presentation.md` (слайдо-источник).
+2. **Link-first, канон не форкается:** витрина даёт цельную картину и ссылается на golden
+   sources за деталями; запрещён дубль живых таблиц (компоненты, env, статусы). Разрешённый
+   дубль — только машинно-сверяемый тестом факт: стадии/гейты/агенты derive-тестами из
+   `STAGE_TRANSITIONS`/`QG_CHECKS`/glob промптов (прецедент key-sync ORCH-102).
+3. **Канон презентации:** источник — `presentation.md` (машинно-парсимая слайдо-структура
+   `## Слайд N:` + тезисы, 14–18 слайдов); генератор — `scripts/build_presentation.py` на
+   python-pptx (тёмная тема, редактируемый текст, кириллица), запуск **только вне рантайма**
+   (dev-venv, явный запуск человеком — паттерн ORCH-009); зависимость в
+   `requirements*`/`Dockerfile` НЕ попадает (машинный гард в тестах). **Собранный `.pptx` в git
+   не коммитится** (источник истины — markdown + скрипт; существующий `PRODUCT_VISION.pptx` не
+   трогается, но прецедентом не является).
+4. **Норматив сопровождения (кросс-каттинг):** «изменил функциональность платформы → обнови
+   витрину `docs/overview/` в том же PR» — в индексе витрины и `CLAUDE.md` (правило агентов №2);
+   **reviewer-ось обзорных доков ORCH-079 расширяется** точечной врезкой в
+   `.openclaw/agents/reviewer.md`: функциональность из витрины изменена, витрина не обновлена →
+   finding ≥ P1 (расширение трактовки той же оси; канон 52d и verdict-ключи — байт-в-байт;
+   анти-регресс `test_agent_prompts_canon.py`).
+5. **Анти-дрейф — `tests/test_system_docs.py`** (структурный, без сети/LLM/subprocess, паттерн
+   `test_lite_setup_doc.py`): наличие/непустота 10 файлов; маршруты и норматив в индексе;
+   сверка стадий и имён гейтов импортом из кода; полнота 6 агентов glob'ом промптов; валидность
+   относительных ссылок; полнотекстовый FORBIDDEN-скан (импорт из `test_no_host_hardcodes.py`)
+   + секрет-эвристика; парс слайдо-источника функцией самого генератора; чистота
+   `requirements*`/`Dockerfile` от pptx; указатели README/CLAUDE/CHANGELOG. Новый QG НЕ
+   регистрируется — тесты исполняются существующими гейтами.
+
+Рантайм байт-в-байт: `src/**`, compose, Dockerfile, `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict/схема БД — не тронуты; kill-switch не нужен (доки и dev-скрипт конвейером не
+исполняются).
+
+## Последствия
+
+- **+** Закрывается корневая фрагментация: одна точка входа для трёх аудиторий; презентация
+  собирается за одну команду из версионируемого источника; машинно-проверяемые факты витрины —
+  CI-гарантии.
+- **+** Нулевой риск рантайма; для enduro-trails инертно.
+- **−** Новый golden source = обязанность каждого функционального PR (в этом смысл задачи);
+  митигировано link-first + derive-тестами + reviewer-осью.
+- **−** Точечная правка промпта reviewer — поверхность канона 52d; держится анти-регресс
+  тестами.
+- **Откат:** удалить `docs/overview/`, тест-модуль, скрипт, вернуть точечные правки указателей
+  и промпта — 1:1, без миграций и состояния.
+
+## Ссылки
+
+- Детально: `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md` (D1…D9),
+  `docs/work-items/ORCH-011/10-tech-risks.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-011/01-brd.md` / `02-trz.md` / `03-acceptance-criteria.md`
+- Соседние каноны: adr-0019 (стандарт доков), adr-0021 (канон промптов 52d), adr-0023
+  (ось обзорных доков ORCH-079 — расширяется), adr-0029 (порядок под-гейтов), adr-0037/0038
+  (deployment-каноны)

docs/architecture/internals.md

@@ -106,6 +106,17 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash
 
 Примечание: переход `review → testing` использует `check_reviewer_verdict` (читается из frontmatter `12-review.md`); `development → review` — `check_tests_local` (оркестратор сам прогоняет тесты, не зависит от Gitea CI).
 
+**Багфикс-трек: routing-override на ребре выхода из `analysis` (ORCH-019 — design).** Для задачи
+с `tasks.track='bug'` (помечена в `start_pipeline` по метке Plane `Bug` через аппарат ORCH-089)
+`advance_stage` на шаге 3 переопределяет результат `get_next_stage('analysis')`: `next_stage` →
+`development` (вместо `architecture`), а на шаге 4 `next_agent` → `developer` (вместо `architect`)
+→ стадия `architecture` и её exit-гейт `check_architecture_done` для багфикса не исполняются.
+`STAGE_TRANSITIONS`/`get_next_stage`/`get_agent_for_stage` остаются чистыми (1:1) — override живёт
+только в `advance_stage`. Чистый предикат `bug_fast_track.skips_architecture(track)` (leaf
+`src/bug_fast_track.py`, never-raise) под `bug_fast_track_enabled`; `track` читается из БД, не из
+сети (NFR-4). `False`/неприменимый репо → маршрут байт-в-байт прежний. Детали —
+[adr-0032](adr/adr-0032-bug-fast-track.md).
+
 ### 6. Review Bounce
 
 При REQUEST_CHANGES:

docs/deployment/BUNDLED_SETUP.md

@@ -0,0 +1,436 @@
+# BUNDLED_SETUP — Bundled-тираж: весь стек одним комплектом (ORCH-103)
+
+> **Golden source Bundled-тиража (Type B эпика ORCH-10).** Маршрут «чистый хост →
+> работающий конвейер» для заказчика **без собственной инфраструктуры**: один
+> compose-комплект (`deploy/bundled/docker-compose.yml`) поднимает оркестратор +
+> watchdog + Gitea + Plane CE, один запуск `scripts/bootstrap_bundle.py apply`
+> доводит стек до рабочего состояния. Каждый шаг — исполняемая команда + явная
+> проверка результата (**Проверка:** / PASS / FAIL). Хост-специфика — только
+> плейсхолдеры `<...>` и `$ENV_VAR`. Тираж **stateless**: данные/задачи/секреты
+> боевого (исходного) хоста **НЕ переносятся** ни на одном шаге (§12).
+> Границы слоёв тиража (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1;
+> канон Lite (своя инфраструктура Plane/Gitea) — `docs/deployment/LITE_SETUP.md`.
+
+---
+
+## 1. Рамка Bundled
+
+**Что входит в комплект** (compose-проект `orchestrator-bundle`, одна bridge-сеть):
+- `orchestrator` (конвейер, образ собирается из этого чекаута) и
+  `orchestrator-watchdog` (независимый sidecar-мониторинг);
+- **Gitea** (git-хостинг, пиннованный официальный образ);
+- **Plane CE — ≈ 14 контейнеров** (зеркало официального selfhost-комплекта:
+  web/space/admin/api/worker/beat-worker/migrator/live + postgres/redis/
+  rabbitmq/minio/proxy) — это **ресурсоёмко**, см. §2.
+
+**Что НЕ входит** (внешние предусловия заказчика):
+- **Claude CLI / LLM-доступ** — дистрибутив claude-code, node и аутентификация
+  живут на хосте и пробрасываются маунтами (§8); без них стек поднимется, но
+  конвейер не поедет;
+- **Telegram-боты** — опциональны (§9): пусто = деградация только нотификаций;
+- **HTTPS/домены/reverse-proxy** — вне bundle: наружу публикуются три http-порта
+  (§2), терминирование TLS — средствами заказчика.
+
+**Bundled vs Lite:** Lite (`LITE_SETUP.md`) подключает оркестратор к **вашим**
+Plane/Gitea; Bundled везёт их **с собой** на чистых томах. Staging-контур орка в
+bundle отсутствует вовсе: заказчик Type B эксплуатирует платформу для своих
+проектов, а не развивает её self-hosting'ом (нужен self-hosting — маршрут Lite,
+`LITE_SETUP.md` §9.3). Репо `orchestrator` в bundle-инсталляции **не
+регистрируется** как проект.
+
+**Осознанный компромисс (TR-7):** git-доступ агентов — HTTP token-remote
+(токен бот-юзера в конфиге локальных чекаутов, права 600); ssh-контур
+сознательно не вводится; порты БД/брокера/minio наружу не публикуются.
+
+---
+
+## 2. Требования к хосту
+
+Linux x86_64, один хост. Минимумы проверяет preflight bootstrap **до любых
+мутаций** (пороги — константы `scripts/bootstrap_bundle.py`, ниже — те же цифры;
+подтверждаются замером приёмочного развёртывания):
+
+| Ресурс | Минимум | Почему |
+|--------|---------|--------|
+| RAM | **8 GB** | Plane CE — ≈ 14 контейнеров (миграции и брокер прожорливы) |
+| Диск | **40 GB** свободно | образы стека + тома postgres/minio/gitea + данные орка |
+| CPU | **4 vCPU** (рекомендация) | меньше — стек поднимется, но будет медленным |
+
+**Карта публикуемых портов** (дефолты; конфигурируемы в
+`deploy/bundled/.env`, ключи `BUNDLE_*`):
+
+| Порт | Ключ | Сервис |
+|------|------|--------|
+| 8500 | `BUNDLE_ORCH_PORT` | API оркестратора (`/health`, `/queue`, `/metrics`, вебхуки) |
+| 8080 | `BUNDLE_PLANE_PORT` | Plane UI (proxy) |
+| 3000 | `BUNDLE_GITEA_HTTP_PORT` | Gitea web/API |
+
+Postgres/redis/rabbitmq/minio наружу **не публикуются** (машинный трафик —
+внутрисетевой сервис-DNS).
+
+```bash
+free -g                                   # RAM ≥ 8 GB
+df -h .                                   # свободно ≥ 40 GB
+nproc                                     # ≥ 4
+ss -ltn | grep -E ':(8500|8080|3000)\b' || echo "ports free"
+```
+
+**Проверка:** ресурсы не ниже минимумов и `ports free` — PASS. Порт занят →
+смените соответствующий `BUNDLE_*`-ключ в §5 (или освободите порт) — иначе
+preflight откажет (FAIL до мутаций, это штатно).
+
+---
+
+## 3. Предусловия
+
+Софт хоста: Docker Engine + Compose v2, git, python3 (+venv), sudo у оператора.
+
+```bash
+uname -sm                      # Linux x86_64
+docker --version && docker compose version
+git --version && python3 --version
+python3 -m venv --help >/dev/null && echo "venv: ok"
+getent group docker            # третье поле — gid, понадобится в §5 (ORCH_DOCKER_GID)
+id -u && id -g                 # uid/gid оператора (ORCH_RUN_UID / ORCH_RUN_GID)
+```
+
+**Проверка:** все команды отвечают без ошибок, gid группы docker известен —
+PASS; что-то отсутствует — FAIL (доставьте пакет средствами дистрибутива).
+
+---
+
+## 4. Получение кода
+
+Переносится **только код** — чекаут репо `orchestrator` (норматив §12).
+
+```bash
+git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>
+cd <путь-чекаута>
+ls deploy/bundled/docker-compose.yml deploy/bundled/.env.example \
+   scripts/bootstrap_bundle.py scripts/gen_secrets.py scripts/onboard_project.py
+```
+
+**Проверка:** все пять файлов на месте — PASS. Канал дистрибуции
+(`<ORCHESTRATOR_GIT_URL>`) согласуйте с поставщиком платформы (как в
+`LITE_SETUP.md` §3).
+
+---
+
+## 5. Секреты
+
+Все секреты инсталляции выпускаются **заново на месте** (§12): webhook-секреты —
+`scripts/gen_secrets.py`, внутренние креды Plane/Gitea-стека — генерирует
+bootstrap (в репо — только пустые плейсхолдеры, ни одного дефолтного пароля).
+
+**5.1. Конфиг bundle-инфры.**
+
+```bash
+cd <путь-чекаута>
+cp deploy/bundled/.env.example deploy/bundled/.env
+chmod 600 deploy/bundled/.env
+# заполнить НЕсекретные ключи: BUNDLE_PUBLIC_HOST (IP/имя хоста для браузера),
+# карту портов BUNDLE_* (§2), ORCH_RUN_UID/ORCH_RUN_GID (из §3),
+# ORCH_DOCKER_GID (getent group docker, §3), пути Claude CLI (§8).
+```
+
+**Проверка:**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml config --quiet && echo "config: PASS"
+```
+
+`config: PASS` — интерполяция согласована; ошибка — FAIL (опечатка в
+`deploy/bundled/.env`).
+
+**5.2. Секрет-значения** (пустые ключи `deploy/bundled/.env` и корневого `.env`)
+заполнит `bootstrap_bundle.py apply` (§7): webhook-секреты — субпроцессом
+`gen_secrets.py`, креды postgres/rabbitmq/minio/`SECRET_KEY` Plane и пароль
+админ-бота Gitea — stdlib-генератором. Значения **не печатаются** (только имена
+ключей); повторный запуск **не перетирает** существующие секреты (явная
+регенерация — флаг `--force-secrets`, допустим только ДО первого запуска стека).
+
+```bash
+grep -cE '^(POSTGRES_PASSWORD|SECRET_KEY|RABBITMQ_DEFAULT_PASS|MINIO_ROOT_PASSWORD|GITEA_ADMIN_PASSWORD)=$' \
+  deploy/bundled/.env
+```
+
+**Проверка:** до §7 счётчик `5` (пустые плейсхолдеры) — PASS; после §7 — `0`.
+
+---
+
+## 6. Запуск bundle-compose
+
+Одна команда поднимает весь стек (≈ 16 контейнеров; первый запуск тянет образы
+и гоняет миграции Plane — это минуты, не секунды).
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml up -d
+docker compose -f deploy/bundled/docker-compose.yml ps
+```
+
+**Проверка:** все сервисы в состоянии `Up`/`Up (healthy)`; `migrator` —
+`Exited (0)` (одноразовая миграция) — PASS. Контейнер в рестарт-цикле — FAIL
+(§14). Шаг идемпотентен; можно пропустить — `bootstrap_bundle.py apply` выполнит
+`up -d` сам (§7).
+
+---
+
+## 7. Bootstrap
+
+Доводка «одним запуском»: preflight → секреты → up/готовность → init Gitea
+(полностью автоматом: админ-бот + API-токен) → init Plane → онбординг
+sandbox-проекта **строго** кирпичом `onboard_project.py` (22 канонических
+статуса, включая fail-closed **`Confirm Deploy`** и **`STOP`**, лейблы,
+репо+webhook — golden source `docs/operations/ONBOARDING.md` §1) → git-доступ
+агентов → сборка `.env`/`.env.watchdog` → health.
+
+```bash
+python3 scripts/bootstrap_bundle.py            # план + preflight-диагностика (ноль мутаций)
+python3 scripts/bootstrap_bundle.py apply      # полный прогон
+```
+
+**Manual-step чекпоинты Plane CE** (API первичной инициализации в CE нет;
+каждый чекпоинт: точная инструкция → подтверждение → верификация результата
+API-пробой, молчаливый пропуск запрещён):
+1. **instance setup** — открыть Plane UI, зарегистрировать первого
+   пользователя (станет администратором инстанса);
+2. **workspace** — создать workspace, ввести его slug в bootstrap;
+3. **API-токен** — Workspace Settings → API tokens, вставить значение в
+   bootstrap (ввод скрыт; уходит в `ORCH_PLANE_API_TOKEN`);
+4. **workspace-webhook** — bootstrap регистрирует сам (запись в Postgres
+   инсталляции, путь Б канона `LITE_SETUP.md` §5.4) и проверяет; при отказе —
+   честный ручной шаг с той же проверкой;
+5. **порядок статусов на доске** — drag-and-drop по отчёту onboard
+   (`docs/operations/ONBOARDING.md`).
+
+Exit-коды: `0` — успех; `2` — остановка на manual-step/предусловии (выполните
+шаг и перезапустите `apply` — завершённые шаги пропускаются, повторный запуск
+безопасен); `1` — ошибка. Пароль админ-бота Gitea — ключ `GITEA_ADMIN_PASSWORD`
+в `deploy/bundled/.env` (права 600; вход в UI Gitea под
+`GITEA_ADMIN_USERNAME`).
+
+**Проверка:**
+
+```bash
+python3 scripts/bootstrap_bundle.py verify && echo "bootstrap: PASS"
+```
+
+`verify` зелёный (health/queue/metrics + onboard verify) — PASS; exit 2 —
+остались ручные пункты отчёта; exit 1 — FAIL (§14).
+
+---
+
+## 8. LLM (claude CLI)
+
+Канон — `LITE_SETUP.md` §7 (полностью применим; не дублируется). Кратко: на
+хост ставятся claude-code + node, выполняется интерактивный логин CLI; пути
+прописываются в `deploy/bundled/.env` (это источники маунтов контейнера орка):
+`ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`,
+`ORCH_HOST_CLAUDE_JSON`.
+
+```bash
+claude --version
+docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
+```
+
+**Проверка:** обе команды печатают версию — PASS; вторая падает — пути в
+`deploy/bundled/.env` не указывают на фактические каталоги хоста (§14.4).
+
+---
+
+## 9. Telegram
+
+Канон — `LITE_SETUP.md` §8 (два независимых бота, C-1: токен орка для watchdog
+переиспользовать запрещено). Ключи орка (`ORCH_TELEGRAM_BOT_TOKEN`,
+`ORCH_TELEGRAM_CHAT_ID`) — в корневой `.env`; ключи watchdog
+(`WATCHDOG_TG_BOT_TOKEN`, `WATCHDOG_TG_CHAT_ID`) — **только** в `.env.watchdog`
+(файл-носитель, `LITE_SETUP.md` §4.3). Шаг опционален: пустые токены =
+деградация только нотификаций.
+
+```bash
+grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=' .env
+grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=' .env.watchdog
+docker compose -f deploy/bundled/docker-compose.yml up -d orchestrator orchestrator-watchdog
+```
+
+**Проверка:** ключи заполнены и контейнеры пересозданы → тестовое сообщение от
+обоих ботов (`getMe` — команды в `LITE_SETUP.md` §8) — PASS; пусто — осознанный
+PASS без нотификаций.
+
+---
+
+## 10. Онбординг следующих проектов
+
+Sandbox-проект создал bootstrap (§7). Каждый следующий проект заказчика —
+штатный runbook `docs/operations/ONBOARDING.md` поверх bundle-инсталляции; для
+команд из чекаута: Plane/Gitea доступны на `localhost`-портах §2, webhook-URL —
+in-network `http://orchestrator:8500/webhook/gitea`.
+
+```bash
+. .venv/bin/activate    # venv создан bootstrap'ом (§7)
+python3 scripts/onboard_project.py plan \
+  --name "<имя проекта>" --repo <repo> --prefix <PREFIX> \
+  --stack "<стек>" --test-cmd "<команда тестов>" \
+  --prod-port <порт-прода> --staging-port <порт-staging> \
+  --webhook-url http://orchestrator:8500/webhook/gitea
+# план устроил → apply → verify (как в LITE_SETUP.md §10), затем:
+# строку ORCH_PROJECTS_JSON из отчёта — в .env и пересоздать орк:
+docker compose -f deploy/bundled/docker-compose.yml up -d --force-recreate orchestrator
+```
+
+**Проверка:** `verify` зелёный; `GET /queue` отвечает после пересоздания — PASS.
+
+---
+
+## 11. Smoke
+
+Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до
+`done`» — опционально) поверх bundle-инсталляции, без форка. Минимальный сигнал
+«конвейер доехал»: issue в sandbox-проекте Plane → статус **To Analyse** →
+артефакты `01`–`04` в ветке задачи.
+
+```bash
+curl -fsS http://127.0.0.1:8500/health
+curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -30
+curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
+# создать issue в Plane (порт 8080) → перевести в «To Analyse», затем:
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40   # job появился
+git -C deploy/bundled/repos/sandbox fetch origin
+git -C deploy/bundled/repos/sandbox ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id>/"
+```
+
+**Проверка:** оба направления связности живы — job в `/queue` (Plane→орк
+доехал), `ls-tree` показывает `01-brd.md` … `04-test-plan.yaml` (орк→Gitea
+пишет; Gitea→орк события идут) — PASS. Любой шаг FAIL → тираж FAIL: соберите
+`docker compose -f deploy/bundled/docker-compose.yml logs --tail 100 orchestrator`
+и снапшот `GET /queue`, разбор — §14. (Порты замените, если меняли `BUNDLE_*`.)
+
+---
+
+## 12. Stateless-проверка
+
+**Нормативно: данные/задачи/секреты/БД боевого (исходного) хоста НЕ
+переносятся** (зеркало `docs/operations/REPLICATION.md` §5). Все тома bundle
+созданы заново при первом `up`; секреты — только свежевыпущенные (§5); в
+Plane/Gitea инсталляции нет чужих задач/репо/пользователей.
+
+```bash
+docker volume ls --format '{{.Name}}' | grep '^orchestrator-bundle' # только тома этой инсталляции
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool        # счётчики нулевые
+```
+
+**Проверка:** в `/queue` нулевые счётчики и ни одной чужой задачи (никаких
+work-item исходного хоста) — PASS. Чужая задача/перенесённый файл БД — FAIL:
+инсталляция собрана не stateless, выполните полный сброс (§13) и повторите.
+
+---
+
+## 13. Остановка и полный сброс
+
+Teardown — **только эта документированная процедура** (в bootstrap delete-режима
+сознательно нет, ADR-001 D9).
+
+**Остановка (обратимая):**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml down
+```
+
+**Проверка:** `docker compose -f deploy/bundled/docker-compose.yml ps` пуст;
+тома целы (`docker volume ls | grep orchestrator-bundle`) — PASS.
+
+**Полный сброс (НЕОБРАТИМО — удаляет все данные Plane/Gitea/орка):**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml down -v
+rm -rf deploy/bundled/data deploy/bundled/repos
+rm -f deploy/bundled/.env .env .env.watchdog
+```
+
+**Проверка:** `docker volume ls --format '{{.Name}}' | grep -c '^orchestrator-bundle'`
+→ `0`; live-конфигов нет — PASS (хост чист, можно разворачивать заново с §5).
+
+---
+
+## 14. Траблшутинг
+
+Формат: симптом → диагностика → лечение.
+
+**14.1. Webhook не доходит (issue в Plane есть, job в `/queue` нет).**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 orchestrator | grep -i "webhook\|signature"
+docker compose -f deploy/bundled/docker-compose.yml exec -T plane-db \
+  psql -U plane -d plane -c "SELECT url, is_active FROM webhooks;"
+```
+
+Лечение: (а) нет строки webhook → §7 чекпоинт 4; (б) URL не
+`http://orchestrator:8500/webhook/plane` → исправьте на in-network URL;
+(в) 401/HMAC → секрет в Plane обязан байт-в-байт совпадать с
+`ORCH_PLANE_WEBHOOK_SECRET` корневого `.env`. Для Gitea-направления проверьте
+Recent Deliveries в настройках hook'а репо; помните про
+`GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` в bundle-compose (без него
+Gitea молча режет вебхуки в приватные адреса).
+
+**14.2. Не хватает RAM / OOM (контейнеры Plane в рестарт-цикле).**
+
+```bash
+free -g && docker stats --no-stream | head -20
+docker compose -f deploy/bundled/docker-compose.yml ps
+```
+
+Лечение: минимум §2 (8 GB; Plane ≈ 14 контейнеров). Меньше — добавьте RAM/swap;
+preflight bootstrap отказывает заранее именно поэтому.
+
+**14.3. Порт занят (`up` падает с bind error).**
+
+```bash
+ss -ltnp | grep -E ':(8500|8080|3000)\b'
+```
+
+Лечение: смените `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`
+в `deploy/bundled/.env` и повторите `up`/bootstrap.
+
+**14.4. claude не найден / агент падает на старте.**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
+ls "$(grep '^ORCH_HOST_CLAUDE_CODE_DIR=' deploy/bundled/.env | cut -d= -f2)"
+```
+
+Лечение: пути `ORCH_HOST_*` в `deploy/bundled/.env` обязаны указывать на
+фактические каталоги хоста; креды CLI читаемы uid'ом `ORCH_RUN_UID` (канон —
+`LITE_SETUP.md` §7/§13.3); после правки — `up -d --force-recreate orchestrator`.
+
+**14.5. Миграции Plane не завершились (bootstrap падает на ожидании).**
+
+```bash
+docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 migrator plane-db
+docker compose -f deploy/bundled/docker-compose.yml ps plane-db plane-mq plane-redis
+```
+
+Лечение: чаще всего — нехватка RAM/диска (§14.2) или невыпущенные секреты
+(пустой `POSTGRES_PASSWORD` → postgres не стартует; прогоните §7, который
+заполняет креды ДО `up`). После лечения — повторный `apply` (идемпотентен).
+
+**14.6. PR задачи не мержится / HOLD.** Branch protection на `main` в Gitea
+**НЕ включать** — норматив `LITE_SETUP.md` §6.4 (ломает PR-merge API
+merge-актора); bundle-Gitea конфигурируется тем же правилом.
+
+```bash
+curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
+  "http://127.0.0.1:3000/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
+```
+
+Лечение: непустой список правил → удалить (канон `LITE_SETUP.md` §6.4/§13.7).
+
+---
+
+*Golden source Bundled-тиража (ORCH-103, ADR-001 D10). **Норматив сопровождения
+(NFR-5):** меняешь шаги Bundled-тиража (состав bundle-compose, ключи
+`deploy/bundled/.env.example`, шаги bootstrap, smoke) → обнови этот док В ТОМ ЖЕ
+PR. Полноту и гигиену держит `tests/test_bundled_setup_doc.py`; кирпичи-каноны:
+`LITE_SETUP.md` (§5–§8 — подключения), `docs/operations/ONBOARDING.md` (статусы
+§1, онбординг), `docs/operations/REPLICATION.md` (карта env §2, секреты §3,
+smoke §4), `deploy/bundled/.env.example` + `.env.example` /
+`.env.watchdog.example` (каноны ключей).*

docs/deployment/LITE_SETUP.md

@@ -0,0 +1,596 @@
+# LITE_SETUP — Lite-тираж: оркестратор + watchdog на вашей инфраструктуре (ORCH-102)
+
+> **Golden source Lite-тиража (Type A эпика ORCH-10).** Сквозной маршрут
+> «голый хост → работающий конвейер» для внешнего оператора/заказчика. Каждый шаг —
+> исполняемая команда + явная проверка результата (**Проверка:** / PASS / FAIL).
+> Хост-специфика в командах — только плейсхолдеры `<...>` и `$ENV_VAR`.
+> Тираж **stateless**: данные/задачи/секреты исходного (боевого) хоста **НЕ переносятся**
+> ни на одном шаге — всё создаётся заново (§12).
+
+---
+
+## 1. Рамка Lite
+
+**Что разворачиваем:** два контейнера платформы — `orchestrator` (конвейер, порт
+`ORCH_DEPLOY_PROD_TARGET_PORT`, дефолт 8500) и `orchestrator-watchdog`
+(независимый sidecar-мониторинг). Третий сервис `orchestrator-staging` существует в том же
+compose-файле, но строго за профилем `staging` и в базовом Lite-контуре не поднимается (§9).
+
+**Что заказчик ставит и администрирует сам** (вне этой инструкции — как продукты):
+- **Plane** (task-management) — своя инсталляция; здесь только её *подключение* (§5);
+- **Gitea** (git-хостинг) — своя инсталляция; здесь только её *подключение* (§6);
+- **Telegram-боты** (нотификации) — свои боты (§8);
+- **LLM-доступ** (claude CLI + node) — свой дистрибутив и аутентификация (§7).
+
+**Границы слоёв тиража** (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1.
+Этот док собирает кирпичи 10-common (карта env, секреты, smoke) в один маршрут и не форкает их.
+
+**Платформенные конвенции (не менять):**
+- репо платформы обязан называться **`orchestrator`** (узел безопасности `SELF_HOSTING_REPO`);
+- имена compose-сервисов/профиля (`orchestrator`, `orchestrator-watchdog`,
+  `orchestrator-staging`, профиль `staging`) — константы платформы;
+- контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout контейнера,
+  не хост-значения; не параметризуются.
+
+---
+
+## 2. Предусловия хоста
+
+Поддерживаемый контур: **Linux x86_64, Docker Engine + Compose v2, git, python3, node** +
+дистрибутив claude-code на хосте. Вне контура — вне гарантии Lite. Каждое предусловие —
+команда проверки; все проверки PASS → можно переходить к §3.
+
+**2.1. ОС и базовые зависимости.**
+
+```bash
+uname -sm                      # Linux x86_64
+docker --version               # Docker Engine
+docker compose version         # Compose v2
+git --version
+python3 --version              # 3.x (для scripts/*.py)
+node --version                 # путь к бинарю станет ORCH_HOST_NODE_BIN
+```
+
+**Проверка:** все команды отвечают версиями без ошибок — PASS; любая отсутствует — FAIL
+(доставить пакет средствами вашего дистрибутива).
+
+**2.2. Пользователь-владелец и uid/gid (инвариант ORCH-040).** Контейнеры бегут под
+`ORCH_RUN_UID:ORCH_RUN_GID` — это обязан быть uid:gid владельца каталога репозиториев
+`ORCH_HOST_REPOS_DIR`, иначе git-артефакты конвейера не запишутся.
+
+```bash
+id -u <deploy-user>; id -g <deploy-user>     # значения для ORCH_RUN_UID / ORCH_RUN_GID
+mkdir -p <путь-каталога-репозиториев>        # станет ORCH_HOST_REPOS_DIR
+stat -c '%u:%g' <путь-каталога-репозиториев> # обязан совпасть с ORCH_RUN_UID:ORCH_RUN_GID
+```
+
+**Проверка:** uid:gid владельца каталога = будущие `ORCH_RUN_UID`/`ORCH_RUN_GID` — PASS.
+
+**2.3. Группа docker (доступ к docker.sock).**
+
+```bash
+getent group docker            # третье поле — gid, станет ORCH_DOCKER_GID
+```
+
+**Проверка:** строка вида `docker:x:<gid>:...` есть — PASS; группы нет — FAIL
+(установите Docker корректно / создайте группу).
+
+**2.4. Каталог ssh-ключей деплой-хука** (понадобится для git-push артефактов агентов и
+деплой-хуков; монтируется в `$HOME/.ssh` акторов).
+
+```bash
+mkdir -p <путь-ssh-каталога>                 # станет ORCH_HOST_SSH_DIR
+ssh-keygen -t ed25519 -f <путь-ssh-каталога>/id_ed25519 -N "" -C "orchestrator@<host>"
+ls -l <путь-ssh-каталога>                    # ключи читаемы пользователем из 2.2
+```
+
+**Проверка:** каталог существует, ключи на месте, владелец — пользователь из 2.2 — PASS.
+Публичный ключ добавьте в Gitea (Settings → SSH Keys) на шаге §6.
+
+**2.5. Свободные порты** (дефолты платформы: 8500 — прод, 8501 — staging).
+
+```bash
+ss -ltn | grep -E ':(8500|8501)\b' || echo "ports free"
+```
+
+**Проверка:** вывод `ports free` — PASS. Порты заняты → выберите другие и на шаге §4
+синхронно задайте `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄
+`ORCH_POST_DEPLOY_BASE_URL` (и `ORCH_STAGING_PORT` ≠ прод-порт — guard ORCH-058 fail-closed).
+
+---
+
+## 3. Перенос кода
+
+Переносится **только код** — чекаут репо `orchestrator`. **НИКАКИХ** данных, БД или `.env`
+с исходного хоста (норматив §12). Watchdog отдельно не переносится: его код — каталог
+`watchdog/` того же репо, образ собирается локально compose'ом.
+
+```bash
+git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>   # путь станет ORCH_DEPLOY_HOST_REPO_PATH
+cd <путь-чекаута>
+```
+
+Конкретный канал дистрибуции (`<ORCHESTRATOR_GIT_URL>` — зеркало/архив/доступ к
+Gitea поставщика) согласуйте с поставщиком платформы; опционально — `--branch <тег-среза>`.
+
+**Проверка:**
+
+```bash
+git -C <путь-чекаута> log --oneline -1            # коммит виден
+ls <путь-чекаута>/docker-compose.yml <путь-чекаута>/watchdog/Dockerfile \
+   <путь-чекаута>/.env.example <путь-чекаута>/.env.watchdog.example
+```
+
+Все файлы на месте — PASS.
+
+---
+
+## 4. Конфигурация
+
+`.env` собирается **с нуля от канона `.env.example`** (100% ключей старта; полная карта
+переменных и их семантика — `docs/operations/REPLICATION.md` §2). Дефолт каждого ключа =
+значению исходного хоста, поэтому задаёте только то, что отличается у вас.
+
+**4.1. Создать `.env` и выпустить webhook-секреты.**
+
+```bash
+cd <путь-чекаута>
+cp .env.example .env
+python3 scripts/gen_secrets.py        # печатает свежие ORCH_PLANE_WEBHOOK_SECRET / ORCH_GITEA_WEBHOOK_SECRET
+```
+
+Вставьте оба напечатанных значения в `.env`. Секреты выпускаются **только заново** —
+боевые не копируются (§12).
+
+**4.2. Обязательные ключи нового хоста** (заполняются в `.env` по ходу §5–§8):
+
+| Группа | Ключи | Откуда |
+|--------|-------|--------|
+| Plane | `ORCH_PLANE_API_URL`, `ORCH_PLANE_WEB_URL`, `ORCH_PLANE_WORKSPACE_SLUG`, `ORCH_PLANE_API_TOKEN` | §5 |
+| Gitea | `ORCH_GITEA_URL`, `ORCH_GITEA_PUBLIC_URL`, `ORCH_GITEA_OWNER`, `ORCH_GITEA_TOKEN` | §6 |
+| Webhook-секреты | `ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET` | 4.1 (`gen_secrets.py`) |
+| Telegram | `ORCH_TELEGRAM_BOT_TOKEN`, `ORCH_TELEGRAM_CHAT_ID` | §8 |
+| Реестр проектов | `ORCH_PROJECTS_JSON` — **обязателен**: встроенный fallback несёт Plane-UUID исходного хоста | §10 |
+| Хост-параметры | `ORCH_AGENT_HOME_DIR`, `ORCH_HOST_REPOS_DIR`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON`, `ORCH_HOST_SSH_DIR`, `ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_RUN_UID`, `ORCH_RUN_GID`, `ORCH_DOCKER_GID`, `ORCH_DEPLOY_HOST_REPO_PATH`, `ORCH_AGENT_GIT_NAME`, `ORCH_GIT_EMAIL_DOMAIN` | значения из §2–§3 |
+| Порты | `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`; `ORCH_STAGING_PORT` ≠ прод-порт | §2.5 |
+
+**4.3. Конфиг sidecar-watchdog — отдельный файл-носитель.** Sidecar-контейнер читает
+**ТОЛЬКО `.env.watchdog`**; ключ `WATCHDOG_ENABLED` (и любой другой `WATCHDOG_*`),
+положенный в `.env`, для sidecar **инертен**.
+
+```bash
+cp .env.watchdog.example .env.watchdog
+# заполнить два ключа: WATCHDOG_TG_BOT_TOKEN / WATCHDOG_TG_CHAT_ID (бота создадим в §8)
+```
+
+**Проверка (резолв всей конфигурации):**
+
+```bash
+docker compose config >/dev/null && echo "compose config: PASS"
+```
+
+`PASS` без ошибок интерполяции — конфигурация согласована; ошибка — FAIL (ищите
+незакрытую кавычку/невалидный JSON в `ORCH_PROJECTS_JSON`).
+
+---
+
+## 5. Подключение Plane
+
+Инсталляция Plane — ваша; платформа подключается к ней API-токеном и webhook'ом.
+
+**5.1. Workspace и проект.** Создайте workspace (его slug → `ORCH_PLANE_WEB_URL` /
+`ORCH_PLANE_WORKSPACE_SLUG`) и проект под вашу разработку — через UI Plane.
+
+```bash
+# базовая доступность API из хоста оркестратора:
+curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/" \
+  -H "X-API-Key: <plane-api-token>" | head -c 200
+```
+
+**Проверка:** HTTP 200 и JSON со списком проектов — PASS; 401/403 — токен (5.2) ещё не
+выпущен или не имеет прав.
+
+**5.2. API-токен.** Plane UI → Workspace Settings → API tokens → выпустить токен →
+`ORCH_PLANE_API_TOKEN` в `.env`. Токен должен иметь право создавать проекты/статусы
+(нужно для `onboard_project.py apply`, §10).
+
+**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **22 канонических статуса** с
+точными именами и группами; их создаёт `python3 scripts/onboard_project.py apply` (§10),
+полная таблица — `docs/operations/ONBOARDING.md` §1 (golden source; здесь не дублируется).
+Два имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
+активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя) и
+**`STOP`** (отмена задачи; обязан быть в группе `cancelled`).
+
+```bash
+# после §10 — проверить, что статусы созданы:
+curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/<project-uuid>/states/" \
+  -H "X-API-Key: $ORCH_PLANE_API_TOKEN" | python3 -m json.tool | grep -c '"name"'
+```
+
+**Проверка:** счётчик имён = 22 (или больше, если в проекте остались дефолтные статусы
+Plane) и среди них `Confirm Deploy` и `STOP` — PASS.
+
+**5.4. Webhook + HMAC.** Приёмник — `POST https://<orchestrator-public-host>/webhook/plane`;
+подпись — заголовок `X-Plane-Signature` (HMAC-SHA256, hex digest); секрет — значение
+`ORCH_PLANE_WEBHOOK_SECRET` из 4.1. События: Issue, Issue Comment.
+
+**Каверза Plane CE:** webhook **не экспонирован во внешнем `/api/v1`** — настраивается
+одним из двух путей.
+
+*Путь А — UI (если ваша сборка Plane его показывает):* Workspace Settings → Webhooks →
+Add Webhook → URL + Secret (значение `ORCH_PLANE_WEBHOOK_SECRET`) → события Issue,
+Issue Comment → Save.
+
+*Путь Б — прямой SQL в Postgres инсталляции Plane:*
+
+```bash
+WORKSPACE_ID=$(docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> \
+  psql -U plane -d plane -t -A -c "SELECT id FROM workspaces WHERE slug='<workspace-slug>'")
+WEBHOOK_ID=$(cat /proc/sys/kernel/random/uuid)
+docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c "
+INSERT INTO webhooks (id, created_at, updated_at, deleted_at, workspace_id, url, is_active,
+  secret_key, project, issue, module, cycle, issue_comment, is_internal, version)
+VALUES ('${WEBHOOK_ID}', NOW(), NOW(), NULL, '${WORKSPACE_ID}',
+  'https://<orchestrator-public-host>/webhook/plane',
+  true, '<значение ORCH_PLANE_WEBHOOK_SECRET>', true, true, false, false, true, false, 'v1');
+"
+```
+
+**Проверка:**
+
+```bash
+docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c \
+  "SELECT url, is_active FROM webhooks;"
+```
+
+Строка с вашим URL и `is_active = t` — PASS. Сквозная проверка доставки — §11 (smoke);
+generic-образец команд и формат подписи — `docs/operations/SETUP_WEBHOOKS.md`.
+
+---
+
+## 6. Подключение Gitea
+
+**6.1. Токен.** Gitea UI → Settings → Applications → Generate Token, scope: `repo`,
+`admin:repo_hook` → `ORCH_GITEA_TOKEN` в `.env`.
+
+```bash
+curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" "$ORCH_GITEA_URL/api/v1/user" | head -c 200
+```
+
+**Проверка:** HTTP 200 с JSON вашего пользователя — PASS; владелец репозиториев
+(организация/пользователь) → `ORCH_GITEA_OWNER`, браузерный URL → `ORCH_GITEA_PUBLIC_URL`.
+
+**6.2. Репо проекта.** Создаёт `onboard_project.py apply` (§10) — или вручную (пустой
+репо + initial push). Чекаут обязан появиться в `$ORCH_HOST_REPOS_DIR/<repo>` (общий
+каталог репозиториев из §2.2). Публичный ключ из §2.4 добавьте в Gitea
+(Settings → SSH Keys), чтобы акторы могли пушить.
+
+```bash
+git -C "$ORCH_HOST_REPOS_DIR" clone <git-url-репо-проекта> <repo>
+stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR/<repo>"     # владелец = ORCH_RUN_UID:ORCH_RUN_GID
+```
+
+**Проверка:** чекаут на месте, владелец совпадает — PASS.
+
+**6.3. Per-repo webhook.** Создаёт `onboard_project.py apply` (§10). Параметры (если
+вручную): URL `https://<orchestrator-public-host>/webhook/gitea`, content type `json`,
+события **`push` / `pull_request` / `status`**, branch filter `*`, подпись —
+`X-Gitea-Signature` (HMAC-SHA256). Секрет — **ОДИН глобальный `ORCH_GITEA_WEBHOOK_SECRET`
+на ВСЕ репо** (приёмник валидирует только его; «свой секрет на репо» сломал бы HMAC
+остальных).
+
+```bash
+curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
+  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
+```
+
+**Проверка:** hook с вашим URL и тремя событиями существует, `active: true` — PASS.
+
+**6.4. Норматив защиты `main` (ВАЖНО).** **Branch protection на `main` НЕ включать**
+(никаких required-approvals / required-status-checks): merge-актор конвейера мержит PR
+строго через Gitea PR-merge API (INV-4), и protection-правила дают 405/409-класс отказов →
+ложные HOLD задач (ADR D10 ORCH-009). **pre-receive хуки платформа не вводит** и не
+проверяет — защита `main` держится конвенцией (агенты не пушат `main`) + скоупом токенов.
+
+```bash
+curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
+  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
+```
+
+**Проверка:** пустой список `[]` — PASS; есть правила на `main` — FAIL (удалите их,
+симптом «PR не мержится / HOLD» — §13.7).
+
+---
+
+## 7. LLM (claude CLI)
+
+Агенты конвейера — процессы claude CLI **внутри контейнера**, но дистрибутив, node и
+аутентификация живут **на хосте** и пробрасываются маунтами (источники маунтов =
+ключи `.env`).
+
+**7.1. Дистрибутив claude-code и node.** Установите claude-code (npm-дистрибутив
+Anthropic) и node на хост. Пути → `.env`:
+
+```bash
+which node                                   # → ORCH_HOST_NODE_BIN
+npm root -g                                  # каталог глобальных модулей
+ls "<npm-root>/@anthropic-ai/claude-code"    # → ORCH_HOST_CLAUDE_CODE_DIR
+```
+
+**Проверка:** каталог дистрибутива существует и непуст — PASS. Внутри контейнера бинарь
+доступен как `ORCH_CLAUDE_BIN` (дефолт менять не нужно).
+
+**7.2. Аутентификация CLI.** Выполните первичный интерактивный логин claude CLI **на
+хосте** под пользователем из §2.2 (по инструкции Anthropic к claude-code). Логин создаёт
+каталог `~/.claude` и файл `~/.claude.json` — их пути задайте в `ORCH_HOST_CLAUDE_DIR` /
+`ORCH_HOST_CLAUDE_JSON`.
+
+```bash
+claude --version                                            # CLI работает
+sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
+```
+
+**Проверка:** версия печатается; `creds: PASS` — креды читаемы uid'ом контейнера
+(иначе — `chown -R <uid>:<gid>` каталога, симптом §13.3).
+
+**7.3. Модели агентов.** Резолв модели/эффорта — только из конфига (ORCH-41/74):
+дефолты канона уже в `.env.example` (`ORCH_AGENT_MODEL_DEFAULT`,
+`ORCH_AGENT_EFFORT_DEFAULT` и per-агент ключи рядом) — менять не обязательно.
+
+```bash
+grep -E '^ORCH_AGENT_(MODEL|EFFORT)_DEFAULT=' .env
+```
+
+**Проверка:** оба ключа присутствуют и непусты — PASS.
+
+---
+
+## 8. Telegram
+
+Каналов **два и они независимы** (C-1 ORCH-100): бот live-трекера оркестратора и
+**отдельный** бот sidecar-watchdog. Токен орка для watchdog переиспользовать
+**ЗАПРЕЩЕНО** — упавший орк не сможет сообщить о себе своим же ботом.
+
+**8.1. Бот трекера.** BotFather → `/newbot` → токен → `ORCH_TELEGRAM_BOT_TOKEN` в `.env`.
+
+```bash
+curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
+# напишите боту любое сообщение (или добавьте его в чат), затем:
+curl -fsS "https://api.telegram.org/bot<токен-трекера>/getUpdates" | python3 -m json.tool | grep -m1 '"id"'
+```
+
+**Проверка:** `getMe` → `"ok":true`; `id` чата из `getUpdates` → `ORCH_TELEGRAM_CHAT_ID` —
+PASS.
+
+**8.2. Watchdog-бот (отдельный).** BotFather → `/newbot` ещё раз → токен и chat-id →
+**`.env.watchdog`** (`WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID`). Помните о
+файле-носителе: эти ключи работают только в `.env.watchdog` (§4.3).
+
+```bash
+curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
+grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
+```
+
+**Проверка:** `getMe` → `"ok":true`; оба ключа в `.env.watchdog` непусты — PASS.
+
+---
+
+## 9. Запуск
+
+**9.1. Базовый Lite-контур (дефолт): орк + watchdog.**
+
+```bash
+cd <путь-чекаута>
+docker compose config --services    # ровно: orchestrator, orchestrator-watchdog, orchestrator-staging
+docker compose up -d --build
+docker compose ps
+```
+
+**Проверка:** запущены **ровно два** контейнера — `orchestrator` и
+`orchestrator-watchdog`; `orchestrator-staging` НЕ поднялся (он строго за
+`profiles: [staging]`) — PASS. Поднялось что-то ещё/меньше — FAIL.
+
+**9.2. Health-чек контрактов.**
+
+```bash
+curl -fsS http://127.0.0.1:8500/health
+curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -20
+curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
+```
+
+**Проверка:** `/health` → HTTP 200, `"status":"ok"`; `/queue` → штатный JSON
+(счётчики очереди); `/metrics` → JSON со `"schema_version": 1` — PASS. (Порт замените,
+если меняли `ORCH_DEPLOY_PROD_TARGET_PORT`.)
+
+**9.3. Вилка staging (опционально).** Базовому контуру «гонять СВОИ проекты» staging
+**не нужен**. Он нужен ТОЛЬКО если вы регистрируете проект `orchestrator` (self-hosting
+развитие самой платформы у себя): стадия `deploy-staging` требует песочницу на
+`ORCH_STAGING_PORT` (изолированная БД `./data/staging`; guard ORCH-058: staging-порт ≠
+прод-порт, fail-closed).
+
+```bash
+cp .env.staging.example .env.staging      # заполнить по аналогии с .env
+docker compose --profile staging up -d orchestrator-staging
+curl -fsS http://127.0.0.1:8501/health
+```
+
+**Проверка (только для этой вилки):** `/health` staging → 200 — PASS.
+
+---
+
+## 10. Регистрация проекта заказчика
+
+Onboarding-CLI создаёт Plane-проект с 22 статусами и лейблами (`autoApprove` /
+`autoDeploy` / `Bug`), Gitea-репо с webhook'ом, скелет репо (kit) и печатает merged-реестр.
+Полный runbook — `docs/operations/ONBOARDING.md`; Lite-последовательность:
+
+```bash
+cd <путь-чекаута>
+python3 scripts/onboard_project.py plan \
+  --name "<имя проекта>" --description "<зачем проект>" \
+  --repo <repo> --prefix <PREFIX> \
+  --stack "<стек>" --test-cmd "<команда тестов>" \
+  --prod-port <порт-прода-проекта> --staging-port <порт-staging-проекта> \
+  --webhook-url https://<orchestrator-public-host>/webhook/gitea
+# план устроил → тот же вызов с apply; затем read-only контроль:
+python3 scripts/onboard_project.py verify <те же аргументы>
+```
+
+**Проверка:** `apply` завершился без ошибок (exit 0; `2` = остались 🖐 ручные шаги — выполните
+их по отчёту), `verify` зелёный — PASS.
+
+Дальше реестр и рестарт:
+
+```bash
+# 1) строку ORCH_PROJECTS_JSON=[...] из отчёта apply вставить в .env (заменить целиком);
+# 2) дождаться тихого окна и управляемо перезапустить орк:
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20   # нет running-job
+docker compose up -d --force-recreate orchestrator
+# 3) убедиться, что инстанс жив и реестр подхвачен:
+curl -fsS http://127.0.0.1:8500/health
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20
+```
+
+**Проверка:** `/health` → 200 после рестарта; в Plane создан проект со статусами
+(см. §5.3), в Gitea — репо с webhook (§6.3) — PASS.
+
+---
+
+## 11. Smoke: «конвейер доехал»
+
+Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до `done`» —
+опционально), без форка; каждый шаг несёт явный PASS/FAIL. Lite-предусловия: §2–§10 этого
+дока выполнены, проект заказчика зарегистрирован (§10).
+
+Минимальный сигнал «конвейер доехал» (шаги 4–5 чек-листа): создайте issue в Plane-проекте
+и переведите в статус **To Analyse**, затем:
+
+```bash
+# задача появилась и analyst-job в очереди:
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40
+# по завершении стадии analysis — артефакты 01–04 в ветке задачи:
+git -C "$ORCH_HOST_REPOS_DIR/<repo>" fetch origin
+git -C "$ORCH_HOST_REPOS_DIR/<repo>" ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id-задачи>/"
+```
+
+**Проверка:** в `/queue` виден job задачи; `ls-tree` показывает `01-brd.md` …
+`04-test-plan.yaml` — PASS.
+
+**Итоговый вердикт:** все шаги чек-листа PASS ⇒ **тираж PASS**; любой шаг FAIL ⇒ тираж
+FAIL — соберите `docker logs orchestrator --tail 100` и снапшот `GET /queue`, разбор —
+§13.
+
+---
+
+## 12. Stateless-проверка
+
+**Нормативно: данные/задачи/секреты боевого (исходного) хоста НЕ переносятся** (зеркало
+`docs/operations/REPLICATION.md` §5). БД создаётся **пустой** при первом старте; `.env` /
+`.env.staging` / `.env.watchdog` собраны с нуля (§4); секреты — только свежевыпущенные
+(`gen_secrets.py` + чек-лист внешних токенов `docs/operations/REPLICATION.md` §3).
+
+Проверка чистоты развёрнутого инстанса (выполнить ДО первой своей задачи):
+
+```bash
+ls -la <путь-чекаута>/data/                                  # БД появилась только после первого старта
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool # счётчики jobs нулевые
+```
+
+**Проверка:** в `/queue` нулевые счётчики и НИ ОДНОЙ задачи чужих проектов (никаких
+`ORCH-*`/`ET-*` исходного хоста) — PASS. Любая чужая задача/перенесённый файл БД — FAIL:
+инстанс собран не stateless, пересоберите `data/` с нуля.
+
+---
+
+## 13. Траблшутинг первичной настройки
+
+Формат: симптом → команда диагностики → лечение.
+
+**13.1. Webhook отвечает 401 / HMAC mismatch.**
+
+```bash
+docker logs orchestrator --tail 50 2>&1 | grep -i "webhook\|signature\|401"
+```
+
+Лечение: секрет в `.env` (`ORCH_PLANE_WEBHOOK_SECRET` / `ORCH_GITEA_WEBHOOK_SECRET`)
+обязан **байт-в-байт** совпадать с секретом в настройке webhook'а (Plane §5.4 / Gitea
+§6.3); после правки `.env` — управляемый рестарт (§10). Формат подписи —
+`docs/operations/SETUP_WEBHOOKS.md`.
+
+**13.2. Задача в Plane создана, но в оркестраторе не появилась.**
+
+```bash
+curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -30   # есть ли job
+docker logs orchestrator --tail 50 2>&1 | grep -i "ignored\|unknown project"
+grep ORCH_PROJECTS_JSON .env                                              # uuid вашего проекта в реестре?
+```
+
+Лечение: (а) проект отсутствует/с чужим UUID в `ORCH_PROJECTS_JSON` → поправить реестр
+(§10) + рестарт; (б) webhook не доставлен → Plane: `SELECT url, is_active FROM webhooks;`
+(§5.4), Gitea: Recent Deliveries в настройках hook'а; (в) подпись → §13.1.
+
+**13.3. claude CLI не найден / не аутентифицирован (агент падает на старте).**
+
+```bash
+docker exec orchestrator /usr/bin/claude --version
+sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
+```
+
+Лечение: маунты указывают на фактические пути хоста (`ORCH_HOST_CLAUDE_CODE_DIR`,
+`ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON` в `.env`); креды
+читаемы uid'ом из §2.2 (`chown -R <uid>:<gid>`); при невалидной сессии — повторный логин
+на хосте (§7.2) + `docker compose up -d --force-recreate orchestrator`.
+
+**13.4. `docker.sock: permission denied` в логах орка/watchdog.**
+
+```bash
+getent group docker          # фактический gid
+grep ORCH_DOCKER_GID .env    # gid в конфиге
+```
+
+Лечение: значения обязаны совпадать → выставить `ORCH_DOCKER_GID` = фактическому gid и
+`docker compose up -d --force-recreate`.
+
+**13.5. `Permission denied` при создании worktree (права `/repos`, ORCH-040/057).**
+
+```bash
+stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR" "$ORCH_HOST_REPOS_DIR/<repo>"
+grep -E '^ORCH_RUN_(UID|GID)=' .env
+```
+
+Лечение: владелец каталога репо обязан совпадать с `ORCH_RUN_UID:ORCH_RUN_GID`
+(§2.2) → `chown -R <uid>:<gid> "$ORCH_HOST_REPOS_DIR"` (включая legacy root-owned файлы)
+и пересоздать контейнер.
+
+**13.6. Telegram молчит (нет карточек/алертов).**
+
+```bash
+curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
+curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
+grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=.+' .env
+grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
+```
+
+Лечение: оба бота отвечают `"ok":true`; chat-id корректен (бот добавлен в чат / получил
+сообщение); ключи watchdog-бота лежат именно в `.env.watchdog` (в `.env` они инертны,
+§4.3); пустой токен = режим «логи без отправки» (fail-safe, не ошибка).
+
+**13.7. PR задачи не мержится / задача в HOLD.** Первая проверка — **не включена ли
+branch protection на `main`** (§6.4):
+
+```bash
+curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
+  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
+```
+
+Лечение: непустой список правил на `main` → удалить (норматив §6.4); merge выполняет
+PR-merge API оркестратора, ручной merge не требуется.
+
+---
+
+*Golden source Lite-тиража (ORCH-102, ADR-001). **Норматив сопровождения (NFR-5):**
+меняешь шаги тиража (env-ключи, compose-сервисы, маршрут онбординга, smoke) → обнови
+этот док В ТОМ ЖЕ PR (правило агентов №2). Полноту и гигиену дока держит структурный
+анти-дрейф тест `tests/test_lite_setup_doc.py`; кирпичи-каноны: REPLICATION.md (карта
+env §2, секреты §3, smoke §4), ONBOARDING.md (статусы §1, онбординг), SETUP_WEBHOOKS.md
+(формат вебхуков), `.env.example` / `.env.watchdog.example` (канон ключей).*

docs/epics/self-evolution.md

@@ -75,6 +75,16 @@
 - **F1 Наблюдаемость** (ORCH-83 [ЭПИК]): метрики agent-liveness + очередь + стадии + хост (диск/память/CPU) + контейнеры + внешние деп (Plane/Gitea/Anthropic). Эндпоинты /health /status /queue → расширить до /metrics + дашборд.
 - **F2 Журнал уроков** (ORCH-8 шаг 1): машинная структурированная таблица отклонений (тип, контекст, корень, предложение, статус) — формализовать то, что сейчас в memory/. Это «топливо» для вертикали-двигателя.
 
+### 🎯 СКОП НАБЛЮДЕНИЯ — три слоя (решено Славой 10.06)
+
+> Граница «мониторим ПЛАТФОРМУ vs ПРОДУКТЫ на ней». Важно для архитектора и будущих задач — не путать уровни.
+
+- **Слой 1 — проекты как ЗАДАЧИ в конвейере — ✅ В СКОПЕ (F1a/F1b).** ET-задачи в stages/queue/agents `/metrics` — это работа орка (его агенты/очередь/стадии). Sidecar алертит «ET-задача застряла». Здоровье КОНВЕЙЕРА.
+- **Слой 2 — проекты как КОНТЕЙНЕРЫ на хосте — ✅ В СКОПЕ (F1b, жив/мёртв).** `enduro-trails-app-1`, `osrm` и пр. через docker.sock ro — Up/healthy/restarting/exited. Общий хост впритык → текущий ET-контейнер вредит орку. Здоровье контейнера как чёрного ящика.
+- **Слой 3 — ВНУТРЕННЕЕ бизнес-здоровье продукта — ❌ НЕ В ФУНДАМЕНТЕ, НО НУЖНО (см. ниже).** Эндпоинты ET отвечают 200? карта рендерится? latency не деградировала после фичи? Орк не знает внутренностей задеплоенных приложений — это МОНИТОРИНГ ПРОДУКТА, не платформы.
+
+**Слой 3 — это отдельная продуктовая способность (домен D4/D5):** «per-project мониторинг здоровья задеплоенного приложения» — опция для заказчика («слежу, что твой ET-сайт жив»). **НО он НУЖЕН и самой петле** (см. §8A «атрибуция уроков») — без детекции деградации продукта петле нечего ловить. Порядок: фундамент (слои 1-2) сначала, слой 3 — позже как D4/D5-фича.
+
 ---
 
 ## 3. ДОМЕН D1 — 🛡️ Надёжность (Self-Repairing)
@@ -166,6 +176,25 @@
 - **Анализ (гибрид):** машина копит и предлагает черновик → Стрим фильтрует/оформляет → Слава апрувит.
 - **E1** Журнал уроков (=F2). **E2** Агент-ретроспективщик (анализ→предложение).
 
+#### ⚖️ АТРИБУЦИЯ урока — platform-level vs project-level (решено Славой 10.06)
+
+> Ключевой шаг петли. Пример Славы: выпустили фичу в ET → она деградировала ET. Петля поймала сигнал — но ЧЬЯ вина и ГДЕ чинить?
+
+Когда детектирована деградация продукта после выпуска фичи, петля ДОЛЖНА различить два уровня вины и направить урок в правильное русло:
+
+- **А. Platform-level (недоработал ОРК):** конвейер выпустил деградацию, потому что у платформы СЛАБЫЙ ПРОЦЕСС (нет регресс-гейта «фича не ломает соседнее», тест-стадия не ловит деградацию производительности, нет производительностного бенчмарка в приёмке). → улучшаем ПРОЦЕСС орка (домен **D2 Качество** / **D1 Надёжность**). Чинится ОДИН раз — выигрывают ВСЕ проекты.
+- **Б. Project-level (недоработал ПРОЕКТ):** процесс орка нормальный, но в конкретном ET МАЛО тестов/слабая приёмка под этот тип фич. → усиливаем ТЕСТЫ/приёмку В САМОМ ET (задача в бэклог ET). Чинится точечно — выигрывает только ET.
+
+**Механизм (новый шаг петли):**
+```
+ДЕТЕКЦИЯ деградации продукта (слой 3) → урок →
+   АТРИБУЦИЯ: platform-level или project-level?
+   ├─ platform → задача в D1/D2 (улучшить процесс — польза всем)
+   └─ project  → задача в бэклог ET (усилить тесты ET — польза ET)
+   (развилка не всегда бинарна — бывает ОБА: и гейт в орк, и тесты в ET)
+```
+Без атрибуции петля «чинит платформу» там, где надо усилить проект (и наоборот). **Зависит от слоя-3 детекции** (§2): без мониторинга здоровья продукта петле нечего атрибутировать. **E2-ретроспективщик** несёт эту классификацию; спорные случаи → Стрим/Слава решают.
+
 ### 8B. Проактивная турбина 💡 — генератор идей новых возможностей (НОВОЕ — запрос Славы)
 
 > Отдельный источник идей роста функционала — НЕ только требования от Славы. Проактивно предлагает новые фичи/возможности/удобства. Та же воронка: машина/агент генерит черновики → Стрим фильтрует → Слава решает.

docs/operations/INFRA.md

@@ -47,8 +47,35 @@ ADR `docs/work-items/ORCH-040/06-adr/ADR-001-run-agents-as-host-uid.md` и гл
 - **P-3:** `id slin` → `1000:1000`; `/repos`, `/app/data` уже `1000:1000`.
 - **P-4:** прод-рестарт self — только в окно тишины (`GET /status` без активных задач):
   общий инстанс с enduro-trails.
-- Разовый разгребающий `chown -R 1000:1000 /home/slin/repos/orchestrator` для старых
-  `root:root` файлов из истории (вне объёма кода).
+- **P-5 (блокер миграции uid, ORCH-057):** нормализация **всех** legacy `root:root` файлов в `/repos`
+  — см. подраздел «Миграция uid: обязательная нормализация legacy root-файлов» ниже. Без неё первый
+  job падает на launch при создании worktree (инцидент 06.06, ORCH-043).
+
+### Миграция uid: обязательная нормализация legacy root-файлов (ORCH-057)
+ORCH-040 сменил `user:` контейнера, но **не** владельца уже существующих файлов в bind-mount `/repos`,
+созданных прежним root-контейнером. Под uid 1000 `src/git_worktree.py::ensure_worktree` не может
+создать worktree рядом с `root:root` каталогом `/repos/_wt/` → `fatal: could not create leading
+directories … Permission denied` (агент даже не стартует). С ORCH-057 эта ошибка распознаётся и
+выдаётся **внятно** (с лечащей командой) + детектится на старте сервиса (WARNING/Telegram, блок
+`fs_ownership` в `GET /queue`), но **фактический `chown` обязан выполнить оператор под root на хосте**
+(контейнер бежит без root и chown'ить чужие файлы не может).
+
+**Обязательный разовый шаг при миграции uid / на новой среде (под root на mva154, ПЕРЕД стартом app):**
+```bash
+# 1) worktree-корень (все ветки всех проектов режутся здесь)
+sudo chown -R 1000:1000 /home/slin/repos/_wt
+# 2) .git обоих репо (objects / worktrees-административные записи)
+sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git \
+                        /home/slin/repos/enduro-trails/.git
+# 3) корень orchestrator целиком (включая data/runs/*.log — 37 root-логов в инциденте)
+sudo chown -R 1000:1000 /home/slin/repos/orchestrator
+# Проверка (пусто = ок):
+find /home/slin/repos/_wt ! -uid 1000 -print -quit
+```
+Процедура **идемпотентна** (повтор на корректной среде — no-op) и входит в **чеклист деплоя/миграции
+self**. Область охвата: `_wt`, оба `.git` (`objects`+`worktrees`), `data/runs`. См.
+`docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md` и сквозной
+`docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`.
 
 ### Тома (volumes)
 - `./data` → `/app/data` (БД; у staging — `./data/staging`)
@@ -144,8 +171,15 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `ORCH_BUILD_CACHE_PRUNE_TIMEOUT_S` | таймаут ssh-команды prune, сек; дефолт `120` |
 | `ORCH_BUILD_CACHE_PRUNE_NOTIFY_MIN_GB` | Telegram при освобождении ≥ N ГБ; дефолт `0` (тихо) |
 | `DEPLOY_SSH_USER` / `_HOST` / `DEPLOY_HOOK_SCRIPT` | параметры деплой-хука |
+| `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME всех акторских subprocess-env (агенты/finalizer/monitor) **и** таргет маунтов `.claude`/`.claude.json`/`.ssh` **и** `ARG APP_HOME` Dockerfile (группа ORCH-040 двигается согласованно); дефолт `/home/slin` |
+| `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot` @ `mva154.local`); системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом |
+| `ORCH_STAGING_PORT` | ORCH-101: порт staging-инстанса (дефолт `8501`); читается и `image_freshness`, и compose `command:` staging; guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) |
+| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` | ORCH-101: host-источники bind-маунтов `~/.claude`, `~/.claude.json`, ssh-ключей (`/home/slin/.{claude,claude.json,orchestrator-ssh}`) |
+| `ORCH_HOST_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-пути дистрибутива claude-code и бинаря node (`/usr/lib/node_modules/@anthropic-ai/claude-code`, `/usr/bin/node`) |
+| `ORCH_RUN_UID` / `ORCH_RUN_GID` | ORCH-101: uid:gid контейнера (`user:`) + `ARG APP_UID/APP_GID` (дефолт `1000:1000`, ORCH-040) |
+| `ORCH_DOCKER_GID` | ORCH-101: gid docker-группы хоста для `group_add` (дефолт `999`; «МИНА 1» ORCH-040 — не удалять) |
 
-**Секреты — только в `.env` / `.env.staging` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`.
+**Секреты — только в `.env` / `.env.staging` / `.env.watchdog` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`, `.env.watchdog.example` (ORCH-102: sidecar-watchdog читает ТОЛЬКО `.env.watchdog`; `WATCHDOG_*` в `.env` для него инертен). Выпуск нового комплекта секретов для нового хоста — `scripts/gen_secrets.py` (боевые секреты не копируются). **Тираж платформы на новую инфру** (карта переменных, секреты, smoke-процедура, границы Lite/Bundled) — `docs/operations/REPLICATION.md` (ORCH-101); сквозная инструкция Lite-тиража для внешнего оператора («голый хост → конвейер», орк+watchdog) — `docs/deployment/LITE_SETUP.md` (ORCH-102). Когерентность портов при смене прод-порта: `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`.
 
 ## Реестр проектов (`src/projects.py`, ORCH-6)
 Связывает Plane project id → gitea repo + work-item prefix. Источник: `ORCH_PROJECTS_JSON`, fallback — встроенный дефолт. Прод видит: `enduro-trails` (ET), `orchestrator` (ORCH). Staging видит ТОЛЬКО `orchestrator-sandbox` (SANDBOX) — изоляция.

docs/operations/ONBOARDING.md

@@ -0,0 +1,200 @@
+# ONBOARDING — turnkey-онбординг нового проекта (ORCH-009)
+
+> RUNBOOK. Полный чеклист подключения нового проекта к оркестратору одним проходом.
+> Исполнитель — оператор; инструмент — CLI `scripts/onboard_project.py`
+> (режимы `plan` — дефолт/dry-run, `apply`, `verify`). Каждый шаг, который CLI выполнить
+> не может, помечен **🖐 РУЧНОЙ ШАГ** и снабжён командой проверки результата.
+> Архитектура решения — см. «Ссылки» внизу.
+
+Запуск CLI — из корня чекаута репо orchestrator, в venv с `requirements.txt`:
+
+```bash
+python3 scripts/onboard_project.py plan \
+  --name "My Project" --description "зачем проект" \
+  --repo my-project --prefix MP \
+  --stack "Python 3.12 + FastAPI" --test-cmd "pytest tests/ -q" \
+  --prod-port 8600 --staging-port 8601 \
+  --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
+```
+
+`plan` печатает полный план **без единой мутации** (ни сети-POST, ни записи на диск);
+`apply` — идемпотентный ensure (существующее → `skipped(exists)`, ничего не удаляется);
+exit-коды: `0` — чисто, `2` — есть `manual-step`/gap, `1` — ошибка.
+
+---
+
+## 0. Предусловия
+
+Все значения — в `.env` на хосте (секреты в гит не попадают):
+
+| Переменная | Зачем | Проверка |
+|-----------|-------|----------|
+| `ORCH_PLANE_API_TOKEN` (+`ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение проекта, статусов, лейблов | `curl -s -H "X-API-Key: $TOKEN" $URL/api/v1/workspaces/$SLUG/projects/ \| head -c 200` |
+| `ORCH_GITEA_TOKEN` (+`ORCH_GITEA_URL`) | создание репо + webhook | `curl -s -H "Authorization: token $TOKEN" $URL/api/v1/user \| head -c 200` |
+| `ORCH_GITEA_WEBHOOK_SECRET` | HMAC webhook (переиспользуется, один на все репо) | есть строка в `.env`; нет → `apply` сгенерирует и выведет |
+| `ORCH_PROJECTS_JSON` | текущий реестр — источник merged-вывода | `grep ORCH_PROJECTS_JSON .env` |
+
+Токен Plane должен иметь право создавать проекты в workspace; токен Gitea — создавать репо и
+hooks под выбранным owner (`--gitea-owner`, дефолт из конфига).
+
+---
+
+## 1. Слой Plane: проект + статусы + лейблы
+
+Выполняет `apply` (или вручную при недоступности API CE — каждый отказ CLI помечает
+`manual-step`, не падает).
+
+1. **Проект**: создаётся с `identifier = --prefix`. Уже существует → передай
+   `--plane-project-id <uuid>` (ensure распознает и пропустит).
+2. **Статусы — точные канонические имена** (22, источник — `plane_sync._PLANE_NAME_TO_KEY`;
+   опечатка = тихая деградация fail-closed веток):
+
+   | Статус | Группа | | Статус | Группа |
+   |--------|--------|-|--------|--------|
+   | Backlog | `backlog` | | In Review | `started` |
+   | Todo | `unstarted` | | Blocked | `started` |
+   | To Analyse | `unstarted` | | Approved | `started` |
+   | In Progress | `started` | | Rejected | `started` |
+   | Analysis | `started` | | **Confirm Deploy** | `started` |
+   | Architecture | `started` | | Needs Input | `started` |
+   | Development | `started` | | Done | `completed` |
+   | Code-Review | `started` | | Cancelled | `cancelled` |
+   | Review | `started` | | **STOP** | **`cancelled`** |
+   | Testing | `started` | | Awaiting Deploy | `started` |
+   | Deploying | `started` | | Monitoring after Deploy | `started` |
+
+   ⚠️ Код-критично: `STOP` обязан быть в группе `cancelled` (иначе ветка отмены молча не
+   активируется); в терминальных группах (`completed`/`cancelled`) — ТОЛЬКО
+   Done/Cancelled/STOP, иначе terminal-detection ложно сочтёт живую задачу терминальной.
+3. **Лейблы**: `autoApprove`, `autoDeploy`, `Bug` (имена — из конфига оркестратора; их
+   отсутствие = fail-safe ручной режим / полный цикл).
+4. **🖐 РУЧНОЙ ШАГ — порядок статусов на доске**: drag-and-drop в UI (API не управляет
+   порядком). Проверка: открой доску проекта — колонки в порядке конвейера.
+5. **Workspace-webhook**: уже **существует** (один на весь workspace, создан на уровне
+   workspace заранее) — CLI его НЕ создаёт, только напоминает проверить:
+
+   ```bash
+   docker exec -e PGPASSWORD=plane plane-app-plane-db-1 psql -U plane -d plane -c \
+     "SELECT id, url, is_active FROM webhooks;"
+   ```
+
+---
+
+## 2. Слой Gitea: репо + per-repo webhook
+
+1. **Репо** `--gitea-owner/--repo`: создаётся пустым (`auto_init=false`; ветку `main` создаст
+   initial push следующего слоя). Существует → `skipped(exists)`.
+2. **Per-repo webhook**: `events: push/pull_request/status`, `content_type: json`,
+   `branch_filter: *`, URL = `--webhook-url`. **Секрет переиспользуется** из
+   `ORCH_GITEA_WEBHOOK_SECRET` (приёмник валидирует ОДИН глобальный секрет на все репо;
+   новый секрет сломал бы HMAC существующих вебхуков). Секрета нет в env → CLI сгенерирует и
+   выведет строку для `.env` — **🖐 РУЧНОЙ ШАГ**: добавить её в `.env` (в гит не коммитить).
+   Формат и проверка — `docs/operations/SETUP_WEBHOOKS.md`. Проверка:
+
+   ```bash
+   curl -s -H "Authorization: token $ORCH_GITEA_TOKEN" \
+     "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
+   ```
+3. **Branch protection `main` НЕ включать** (ADR D10): required-approvals/status-checks ломают
+   PR-merge API merge-актора конвейера (ложные HOLD). Защита держится конвенцией + скоупом
+   токенов.
+
+---
+
+## 3. Слой kit: материализация + initial push
+
+1. `apply` рендерит kit (`onboarding/repo-skeleton/`, плейсхолдеры `{{NAME}}` из
+   `onboarding/placeholders.json`) во временный каталог, докладывает live-copy канона
+   (`docs/_templates/` 16 скелетов + `docs/_standards/` 3 стандарта — verbatim из текущего
+   чекаута, BR-2 «канон не форкается») и пушит **ТОЛЬКО в свежесозданный/пустой репо**
+   (единственный разрешённый push; коммит `feat: onboarding skeleton (ORCH-009 kit)`).
+2. Репо непустой → шаг помечается `manual-step`: **🖐 РУЧНОЙ ШАГ** — занеси недостающие
+   файлы обычным PR с ревью; поверх существующего контента ничего не пушится (BR-9).
+3. После рендера не должно остаться ни одного `{{...}}`: CLI падает на этом сам; повторная
+   проверка — `verify` (скан плейсхолдеров в файлах репо).
+
+---
+
+## 4. Регистрация в реестре оркестратора
+
+> ⚠️ **САМЫЙ ВАЖНЫЙ РУЧНОЙ СЛОЙ.** CLI `.env` прода НЕ правит и контейнер НЕ рестартит
+> (инвариант NFR-2) — он только печатает готовую строку.
+
+1. **🖐 РУЧНОЙ ШАГ — env**: возьми из отчёта `apply` строку
+   `ORCH_PROJECTS_JSON=[...полный merged-массив...]` (существующие записи verbatim + новая в
+   конец; строка уже провалидирована фактическим парсером реестра) и замени ею строку в `.env`
+   оркестратора на хосте. Вставляется атомарно одной строкой — ручное слияние JSON не нужно.
+2. **🖐 РУЧНОЙ ШАГ — управляемый рестарт оркестратора**: реестр строится при импорте, нужна
+   перезагрузка процесса. **Self-hosting предупреждение: прод-контейнер один на ВСЕ проекты —
+   рестарт = групповое окно** (встаёт конвейер всех проектов). Выполняй осознанно: дождись
+   тихого окна (`GET /queue` — нет бегущих job), затем штатный рестарт по
+   `docs/operations/INFRA.md`. Проверка после рестарта:
+
+   ```bash
+   curl -s http://localhost:8500/health
+   curl -s http://localhost:8500/queue | python3 -m json.tool | head -30   # реестр жив, конвейер пуст/цел
+   ```
+3. TTL-self-heal статусов Plane (300с) рестарта НЕ требует: статусы/лейблы, созданные после
+   регистрации, подхватятся сами.
+
+---
+
+## 5. Верификация
+
+1. **`verify`-режим CLI** (read-only):
+
+   ```bash
+   python3 scripts/onboard_project.py verify --name ... --repo ... --prefix ... \
+     --plane-project-id <uuid> --stack ... --test-cmd ... --prod-port ... --staging-port ... \
+     --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
+   ```
+
+   Проверяет: запись реестра парсится и совпадает по полям; все 22 статуса резолвятся
+   (включая fail-closed `Confirm Deploy`/`STOP`); лейблы на месте; webhook существует и
+   активен; kit-файлы в репо (6 промптов, `AGENTS.md`, `INFRA.md`, `_templates`/`_standards`);
+   нет неразрешённых плейсхолдеров. Любой gap → exit `2` с перечнем.
+
+2. **Smoke на песочнице (ADR D8)** — контур: **staging-оркестратор (порт 8501, изолированная
+   БД `./data/staging`)** + одноразовый sandbox-проект (рекомендуемые имена: проект
+   `onboarding-smoke`, префикс `SMK`, репо `onboarding-smoke`):
+   1. Онборди sandbox самим CLI (слои 1–3 этого runbook).
+   2. **🖐 РУЧНОЙ ШАГ**: зарегистрируй sandbox в `ORCH_PROJECTS_JSON` **`.env.staging`**
+      (не прода!) и перезапусти staging-контейнер (он свободен от прод-инварианта):
+      `docker compose --profile staging up -d orchestrator-staging`.
+   3. Создай тестовую задачу в sandbox-проекте → доведи до стадии analysis в песочнице.
+   4. Критерий PASS: агент по своему промпту **прочитал доку проекта** (следы чтения
+      `CLAUDE.md`/`AGENTS.md` в выводе) и **записал артефакты** в `docs/work-items/SMK-…/`
+      по канону `PIPELINE_DOCS.md`.
+   5. Запротоколируй прогон в «Журнале smoke-прогонов» (ниже). Для приёмки ORCH-009 первый
+      протокол обязателен.
+
+---
+
+## 6. Откат
+
+CLI ничего не удаляет (BR-9) — откат всегда ручной и осознанный:
+
+| Что создано | Как откатить | Проверка |
+|-------------|--------------|----------|
+| Plane-проект (+статусы/лейблы) | удалить проект в UI Plane | проект исчез из списка workspace |
+| Gitea-репо (+webhook) | удалить репо в UI/API Gitea (webhook умрёт вместе с ним) | `GET /api/v1/repos/<owner>/<repo>` → 404 |
+| Строка реестра | убрать запись из `ORCH_PROJECTS_JSON` в `.env` + управляемый рестарт (см. слой 4, то же групповое окно) | `GET /queue` — проекта нет в реестре |
+| Sandbox-артефакты smoke | удалить sandbox-проект/репо после прогона (или архивировать) | см. выше |
+
+---
+
+## Журнал smoke-прогонов
+
+| Дата | Оператор | Параметры (проект/префикс/репо) | Контур | Результат (PASS/FAIL) | Протокол |
+|------|----------|----------------------------------|--------|------------------------|----------|
+| —    | —        | — (первый прогон фиксируется при приёмке ORCH-009) | staging 8501 | — | — |
+
+---
+
+## Ссылки
+
+- Архитектура решения: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
+  (D1…D11); сквозной ADR — `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
+- Устройство набора шаблонов и словарь плейсхолдеров: `onboarding/README.md`.
+- Формат вебхуков: `docs/operations/SETUP_WEBHOOKS.md`; топология и рестарты —
+  `docs/operations/INFRA.md`.

docs/operations/REPLICATION.md

@@ -0,0 +1,155 @@
+# REPLICATION — тираж платформы на новую инфраструктуру (ORCH-101)
+
+> RUNBOOK фундамента тиража (эпик ORCH-10, слой **10-common**). Как развернуть
+> оркестратор на чужом хосте **без правки кода**: переменные → секреты → smoke.
+> Тираж **stateless**: данные/БД/секреты боевого хоста НЕ переносятся ни на одном
+> шаге — на целевой инфре всё создаётся заново.
+
+---
+
+## 1. Границы: 10-common vs Lite vs Bundled
+
+| Слой | Что это | Статус |
+|------|---------|--------|
+| **10-common** (этот док) | фундамент: все хост-значения параметризованы (env/конфиг), секреты выпускаются заново, smoke-процедура с PASS/FAIL | ✅ ORCH-101 |
+| **Type A — Lite** | инструкция «поставь Plane+Gitea сам, подключи оркестратор» поверх 10-common | ✅ ORCH-102 — [`docs/deployment/LITE_SETUP.md`](../deployment/LITE_SETUP.md) |
+| **Type B — Bundled** | комплект «всё в одном» (Plane+Gitea+оркестратор) поверх 10-common | ✅ ORCH-103 — [`docs/deployment/BUNDLED_SETUP.md`](../deployment/BUNDLED_SETUP.md) |
+
+Этот док НЕ описывает установку Plane/Gitea — только параметризацию, секреты и
+smoke самого оркестратора (анти-скоуп-крип Р-5).
+
+### Платформенные конвенции тиража (нормативно, ADR-001 D3/D4)
+
+- **Репо платформы обязан называться `orchestrator`.** Имя — узел безопасности
+  (`SELF_HOSTING_REPO`, на него завязаны все `*_repos`-leaf'ы «empty CSV →
+  self-hosting only»); оно сознательно НЕ конфигурируется.
+- Имена compose-сервисов/профиля (`orchestrator`, `orchestrator-staging`,
+  `orchestrator-watchdog`, профиль `staging`) — константы платформы.
+- Контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout
+  контейнера, не хост-значения; не параметризуются.
+
+---
+
+## 2. Карта переменных нового хоста
+
+Принцип (ADR-001 D1): **дефолт каждой переменной = боевое значение текущего
+хоста** — пустой `.env` ⇒ поведение байт-в-байт; на новом хосте задаёшь только
+то, что отличается. Одно env-имя = один факт: pydantic `Settings` читает имя из
+`env_file`, compose-интерполяция `${VAR:-default}` — из **`.env` проекта/shell**
+(⚠️ НЕ из `env_file` сервиса: `.env.staging` на интерполяцию не влияет —
+значения для маунтов/uid/портов живут в `.env`).
+
+### 2.1. Хост-параметризация (новое в ORCH-101)
+
+| Переменная | Дефолт | Назначение |
+|-----------|--------|------------|
+| `ORCH_AGENT_HOME_DIR` | `/home/slin` | HOME всех акторов (агенты, finalizer, monitor) + таргет маунтов `.claude`/`.claude.json`/`.ssh` + `ARG APP_HOME` (группа ORCH-040 двигается вместе) |
+| `ORCH_AGENT_GIT_NAME` | `claude-bot` | git-имя коммитов агентов |
+| `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен git-email всех акторов (`claude-bot@…`, `deploy-finalizer@…`, `post-deploy-monitor@…`) |
+| `ORCH_STAGING_PORT` | `8501` | порт staging; читают `image_freshness` И compose `command:`; guard: совпадение с прод-портом → отказ fail-closed (ORCH-058 AC-9) |
+| `ORCH_HOST_REPOS_DIR` | `/home/slin/repos` | каталог репозиториев на хосте (источник маунта `/repos`) |
+| `ORCH_HOST_CLAUDE_DIR` | `/home/slin/.claude` | источник маунта `~/.claude` |
+| `ORCH_HOST_CLAUDE_JSON` | `/home/slin/.claude.json` | источник маунта `~/.claude.json` |
+| `ORCH_HOST_SSH_DIR` | `/home/slin/.orchestrator-ssh` | источник маунта ssh-ключей (`→ $HOME/.ssh:ro`) |
+| `ORCH_HOST_CLAUDE_CODE_DIR` | `/usr/lib/node_modules/@anthropic-ai/claude-code` | дистрибутив claude-code на хосте |
+| `ORCH_HOST_NODE_BIN` | `/usr/bin/node` | бинарь node на хосте |
+| `ORCH_RUN_UID` / `ORCH_RUN_GID` | `1000` / `1000` | uid:gid контейнера (`user:` + `ARG APP_UID/APP_GID`); = uid владельца `ORCH_HOST_REPOS_DIR` (ORCH-040) |
+| `ORCH_DOCKER_GID` | `999` | gid группы docker хоста (`group_add`, «МИНА 1» — обязателен для docker.sock); узнать: `getent group docker` |
+| `ORCH_DEPLOY_PROD_TARGET_PORT` | `8500` | (реюз) прод-порт; интерполируется в `command:` прод-сервиса |
+| `ORCH_DEPLOY_SSH_USER` / `ORCH_DEPLOY_HOST_REPO_PATH` | `slin` / `/home/slin/repos/orchestrator` | (реюз) ssh-юзер хука и чекаут платформы на хосте; `REPO=` передаётся хуку явно из конфига |
+
+### 2.2. Обязательные ключи идентичности нового хоста
+
+| Переменная | Где взять |
+|-----------|-----------|
+| `ORCH_PLANE_API_URL` / `ORCH_PLANE_WEB_URL` / `ORCH_PLANE_WORKSPACE_SLUG` | инсталляция Plane целевого хоста |
+| `ORCH_GITEA_URL` / `ORCH_GITEA_PUBLIC_URL` / `ORCH_GITEA_OWNER` | инсталляция Gitea целевого хоста |
+| `ORCH_PROJECTS_JSON` | **обязателен на новом хосте**: встроенный fallback (`src/projects.py`) несёт Plane-UUID *исходного* хоста — чужие UUID безвредны (не сматчатся), но без своего реестра конвейер не увидит проекты. Сгенерировать: `scripts/onboard_project.py apply` печатает merged-значение |
+| Когерентность портов | сменил прод-порт → синхронно `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL` |
+
+Полный справочник всех остальных флагов — `.env.example` (канон) и
+`docs/operations/INFRA.md` (карта env).
+
+---
+
+## 3. Секреты нового хоста (FR-4 / AC-5)
+
+**Нормативно: боевые секреты текущего хоста НЕ копируются ни на одном шаге.**
+Для нового хоста всегда выпускается новый комплект.
+
+### 3.1. Генерация локальных webhook-секретов
+
+```bash
+python3 scripts/gen_secrets.py            # печать .env-фрагмента в stdout
+python3 scripts/gen_secrets.py --write    # создать .env (существующий → отказ exit=2)
+python3 scripts/gen_secrets.py --write --force  # перезапись только явно
+```
+
+Скрипт stdlib-only (`secrets.token_hex(32)` — 32 байта энтропии); повторный
+запуск даёт другие значения; существующий `.env` **никогда не перезаписывается
+молча**.
+
+| Секрет | Генерируется | Куда вписать |
+|--------|--------------|--------------|
+| `ORCH_PLANE_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + настройка webhook в Plane (см. `SETUP_WEBHOOKS.md`) |
+| `ORCH_GITEA_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + webhook Gitea (создаёт `onboard_project.py apply`) |
+
+### 3.2. Чек-лист внешних токенов
+
+| Секрет | Где выпустить | Куда вписать | Как проверить |
+|--------|---------------|--------------|---------------|
+| `ORCH_PLANE_API_TOKEN` | Plane UI → Workspace Settings → API tokens | `.env` | `curl -H "X-API-Key: $TOKEN" $ORCH_PLANE_API_URL/api/v1/workspaces/<slug>/projects/` → 200 |
+| `ORCH_PLANE_BOT_*` (7, опциональны) | Plane UI: bot-аккаунты per-агент; пусто → fallback на `ORCH_PLANE_API_TOKEN` | `.env` | комментарий в Plane от имени бота |
+| `ORCH_GITEA_TOKEN` | Gitea UI → Settings → Applications → Generate Token (scope: repo, admin:repo_hook) | `.env` | `curl -H "Authorization: token $TOKEN" $ORCH_GITEA_URL/api/v1/user` → 200 |
+| `ORCH_TELEGRAM_BOT_TOKEN` | BotFather (`/newbot`) | `.env` | `curl https://api.telegram.org/bot$TOKEN/getMe` → ok |
+| `ORCH_TELEGRAM_CHAT_ID` (несекретный) | id чата оператора | `.env` | тестовое сообщение |
+| `WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID` | отдельный бот sidecar-watchdog (ORCH-100, независимый канал) | `.env.watchdog` | алерт от sidecar |
+
+### 3.3. Полнота
+
+`.env.example` — канон 100% ключей старта (секретные значения — только
+плейсхолдеры). Состав вывода `gen_secrets.py` сверяется с `.env.example`
+тестом (`tests/test_secrets_gen.py`).
+
+---
+
+## 4. Smoke-верификация тиража (FR-5 / AC-3)
+
+Процедура «инстанс → тестовый проект → тестовая задача → конвейер доехал» из
+существующих кирпичей; **каждый шаг имеет явный PASS/FAIL**. Итог — однозначный
+вердикт: все шаги PASS ⇒ тираж PASS; любой шаг FAIL ⇒ тираж FAIL (собери логи
+контейнера `docker logs orchestrator` и снапшот `GET /queue` и разбирайся).
+
+Воспроизводимость без нового железа: процедура прогоняется на текущей инфре —
+staging-песочница (порт `ORCH_STAGING_PORT`, дефолт 8501) + sandbox-проект.
+Stateless: ни один шаг не предполагает перенос данных/БД/секретов.
+
+| # | Шаг | Команда | PASS | FAIL |
+|---|-----|---------|------|------|
+| 0 | Конфиг резолвится | `docker compose config` | резолв без ошибок; при пустом env значения = боевым дефолтам | ошибка интерполяции / неожиданные значения |
+| 1 | Инстанс жив | `curl -fsS http://127.0.0.1:<port>/health` | HTTP 200, `"status":"ok"` | не-200 / таймаут |
+| 2 | Контракты отвечают | `curl -fsS …/queue` и `…/metrics` | JSON со штатными блоками; `/metrics` → `schema_version: 1` | не-JSON / 5xx |
+| 3 | Тестовый проект | `python3 scripts/onboard_project.py plan` → `apply` → `verify` (sandbox) | `verify` зелёный (статусы/лейблы/repo/webhook на месте) | `verify` красный / manual-step не выполнен |
+| 4 | Тестовая задача | создать issue в Plane → статус «To Analyse» | задача в БД, analyst-job виден в `GET /queue` | задача не появилась (webhook/секрет/реестр) |
+| 5 | **Минимальный сигнал «конвейер доехал»** | дождаться окончания `analysis` | артефакты `01`–`04` в ветке задачи: `git ls-tree origin/<branch> docs/work-items/<id>/` | стадия не завершилась / артефактов нет |
+| 6 | Расширенный режим (опционально) | Approved → … → Confirm Deploy | задача дошла до `done` | застряла (разбор по `GET /queue` + логам) |
+
+> Ручной запуск deploy-хука на нестандартных портах — всегда с явными
+> `REPO=`/`TARGET_PORT=` (wired-путь оркестратора передаёт их сам из конфига;
+> дефолты хука — staging текущего хоста).
+
+---
+
+## 5. Что НЕ переносится (stateless, решение 10.06)
+
+- БД (`data/orchestrator.db`) — создаётся пустой при первом старте;
+- `.env` / `.env.staging` / `.env.watchdog` — собираются заново (§2–§3);
+- worktree'ы/runs/логи — рабочее состояние, не данные;
+- боевые секреты — никогда (§3).
+
+---
+
+*RUNBOOK ORCH-101. Поддерживать при добавлении хост-переменных (карта §2 +
+`.env.example` + INFRA.md в том же PR). Анти-регресс возврата хардкодов —
+`tests/test_no_host_hardcodes.py`; параметризация инфра-файлов —
+`tests/test_infra_parametrization.py`.*

docs/operations/SETUP_WEBHOOKS.md

@@ -12,30 +12,36 @@ Internal URL: `http://127.0.0.1:8500/`
 
 ---
 
-## Gitea Webhook
+## Gitea Webhook (per-repo)
 
-**Создан автоматически через API.**
+Gitea-webhook — **per-repo**: создаётся для КАЖДОГО подключаемого к оркестратору репозитория
+(`<repo>` ниже). Для новых проектов его создаёт onboarding-CLI
+(`scripts/onboard_project.py apply`) — полный процесс см. `docs/operations/ONBOARDING.md`;
+команды ниже — для ручной проверки/пересоздания на любом репо.
 
 - URL: `https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea`
 - Events: `push`, `pull_request`, `status`
-- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env`
+- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env` — **ОДИН глобальный секрет на все
+  репо** (приёмник валидирует только его; новый секрет на одном репо сломал бы HMAC остальных —
+  при ротации меняется на всех репо разом)
 - Signature header: `X-Gitea-Signature` (HMAC-SHA256 hex digest)
 
 ### Проверка
 
 ```bash
 GITEA_TOKEN=$(grep ORCH_GITEA_TOKEN /home/slin/repos/orchestrator/.env | cut -d= -f2)
-curl -s "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
+curl -s "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
   -H "Authorization: token ${GITEA_TOKEN}" | python3 -m json.tool
 ```
 
 ### Пересоздание (если нужно)
 
 ```bash
-GITEA_WEBHOOK_SECRET=$(openssl rand -hex 20)
-# Обновить в .env: ORCH_GITEA_WEBHOOK_SECRET=<new_secret>
+# Секрет переиспользуй из .env (ORCH_GITEA_WEBHOOK_SECRET); генерируй новый ТОЛЬКО при
+# первичной настройке/осознанной ротации (и обнови вебхуки ВСЕХ репо):
+GITEA_WEBHOOK_SECRET=$(grep ORCH_GITEA_WEBHOOK_SECRET /home/slin/repos/orchestrator/.env | cut -d= -f2)
 
-curl -X POST "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
+curl -X POST "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
   -H "Authorization: token ${GITEA_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '{

docs/overview/README.md

@@ -0,0 +1,89 @@
+# Витрина системы — Orchestrator
+
+**Что это за система.** Orchestrator — автономная фабрика разработки: конвейер из шести
+ИИ-агентов (аналитик → архитектор → разработчик → ревьюер → тестировщик → деплойер), который
+проводит задачу от бизнес-постановки до выкладки на прод. Человек ставит задачу и принимает
+результат; всё между — автономно, под защитой машинных гейтов качества. Платформа ведёт
+несколько проектов из одного инстанса, дорабатывает сама себя (self-hosting) и тиражируется
+на новые хосты.
+
+**Зачем эта витрина.** Это единая точка входа в документацию системы: связное описание на двух
+уровнях — бизнес (для нетехнического читателя) и технический (7 блоков), с маршрутами чтения
+для трёх аудиторий и слайдо-готовой основой для презентации. Витрина — обзор; за деталями она
+ведёт ссылками в инженерные golden sources, не подменяя их.
+
+---
+
+## Состав витрины
+
+| Файл | О чём |
+|------|-------|
+| [business.md](business.md) | Бизнес-уровень: проблема, решение, что умеет, ценность, сценарии |
+| [tech-architecture.md](tech-architecture.md) | Блок 1: компоненты и связи, схема потока |
+| [tech-pipeline.md](tech-pipeline.md) | Блок 2: конвейер, стадии, гейты, откаты, человеческие гейты |
+| [tech-agents.md](tech-agents.md) | Блок 3: 6 ролей агентов, артефакты, модель/эффорт |
+| [tech-data-model.md](tech-data-model.md) | Блок 4: каноническая модель объектов, словарь терминов |
+| [tech-integrations.md](tech-integrations.md) | Блок 5: Plane, Gitea, LLM, Telegram |
+| [tech-quality-security.md](tech-quality-security.md) | Блок 6: гейты качества, безопасность, секреты |
+| [tech-observability.md](tech-observability.md) | Блок 7: наблюдаемость, аналитика, журнал уроков |
+| [presentation.md](presentation.md) | Слайдо-источник презентации + сборка `.pptx` |
+
+---
+
+## Маршруты чтения
+
+### Я заказчик
+1. [business.md](business.md) — проблема, решение, ценность.
+2. [business.md → Сценарии использования](business.md#сценарии-использования) — как это выглядит в работе.
+3. [presentation.md](presentation.md) — слайдовая версия рассказа (собирается в PowerPoint).
+4. Развернуть у себя: [LITE_SETUP](../deployment/LITE_SETUP.md) (своя инфраструктура) или
+   [BUNDLED_SETUP](../deployment/BUNDLED_SETUP.md) (весь стек одним комплектом).
+
+### Я менеджер проекта
+1. [business.md](business.md) — что платформа делает и где в процессе человек.
+2. [tech-pipeline.md](tech-pipeline.md) — конвейер, статусная модель Plane, человеческие гейты
+   (одобрение постановки, подтверждение прод-деплоя).
+3. [tech-observability.md](tech-observability.md) — как следить за ходом: живая Telegram-карточка,
+   статусы, стоимость.
+
+### Я разработчик
+1. Тех-блоки 1→7: [архитектура](tech-architecture.md) → [конвейер](tech-pipeline.md) →
+   [агенты](tech-agents.md) → [модель объектов](tech-data-model.md) →
+   [интеграции](tech-integrations.md) → [качество/безопасность](tech-quality-security.md) →
+   [наблюдаемость](tech-observability.md).
+2. [Инженерный справочник архитектуры](../architecture/README.md) и
+   [internals](../architecture/internals.md) — детали реализации.
+3. [Стандарты](../_standards/PIPELINE_DOCS.md) (структура доков конвейера),
+   [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md) (машинный контракт стадий),
+   [TRACEABILITY](../_standards/TRACEABILITY.md) (маркеры решений).
+4. [Реестр сквозных ADR](../architecture/adr/) — история архитектурных решений.
+5. [CLAUDE.md](../../CLAUDE.md) — паспорт проекта и правила для агентов.
+
+---
+
+## Норматив сопровождения
+
+> **Изменил функциональность платформы → обнови витрину `docs/overview/` в том же PR.**
+
+Какой файл правится при каком классе изменений:
+
+| Класс изменения | Файл витрины |
+|-----------------|--------------|
+| Новый компонент / демон / поток данных | [tech-architecture.md](tech-architecture.md) |
+| Стадии, гейты, под-гейты, маршруты задач | [tech-pipeline.md](tech-pipeline.md) |
+| Роли агентов, промпты, модель/эффорт | [tech-agents.md](tech-agents.md) |
+| Таблицы БД, объекты, термины | [tech-data-model.md](tech-data-model.md) |
+| Plane / Gitea / LLM / Telegram | [tech-integrations.md](tech-integrations.md) |
+| Гейты качества, секреты, self-hosting-страховки | [tech-quality-security.md](tech-quality-security.md) |
+| Эндпоинты наблюдаемости, метрики, уроки | [tech-observability.md](tech-observability.md) |
+| Новая способность уровня продукта | [business.md](business.md) + при необходимости [presentation.md](presentation.md) |
+
+Каркас и машинно-проверяемые факты витрины (перечень стадий, имена гейтов, полнота агентов,
+валидность ссылок) защищены структурными тестами `tests/test_system_docs.py` — дрейф рвёт CI.
+Прозу проверяет reviewer: необновлённая витрина при изменении описанной в ней функциональности —
+finding ≥ P1 (расширение оси обзорных доков).
+
+---
+
+*Витрина — обзорный слой документации. Текущее состояние и реестр доработок — [CLAUDE.md](../../CLAUDE.md);
+концепция развития — [Product Vision](../PRODUCT_VISION.md).*

docs/overview/business.md

@@ -0,0 +1,105 @@
+# Бизнес-уровень: что это и зачем
+
+> Читатель этого документа — нетехнический: заказчик, руководитель, менеджер. Технические
+> детали вынесены в [тех-часть витрины](README.md) и даются здесь только ссылками.
+
+## Проблема
+
+Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор,
+разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря
+времени, контекста и денег. Мелкая фича или баг едут до прода днями: не потому, что работа
+сложная, а потому, что задача ждёт людей в очередях между ролями.
+
+## Решение
+
+**Orchestrator** — конвейер из ИИ-агентов, который проводит задачу через все стадии разработки
+сам: анализ требований → проектирование → код → ревью → тестирование → репетиция выкладки →
+выкладка на прод. Человек в этой схеме — **постановщик и приёмщик**: он формулирует задачу,
+одобряет постановку и подтверждает выкладку на прод. Всё между — автономно.
+
+Честность конвейера держат **гейты качества**: автоматические проверки на каждом переходе,
+которые не пускают задачу дальше, пока стадия не выполнена по-настоящему (тесты зелёные,
+ревью одобрено, репетиция выкладки успешна). Агент не может «уговорить» гейт — вердикты
+машинные, не прозой.
+
+## Что умеет платформа сегодня
+
+Ниже — фактическое состояние, не планы (концепция развития — отдельный документ,
+[Product Vision](../PRODUCT_VISION.md)).
+
+- **Автономный конвейер «задача → прод».** Задача, поставленная в трекере, проходит весь путь
+  до выкладки без ручных пинков; человек участвует ровно в двух точках — одобрение постановки
+  и подтверждение прод-выкладки.
+- **Мультипроектность.** Один инстанс платформы ведёт несколько проектов (репозиториев)
+  одновременно, с общей очередью и честным разделением работы.
+- **Самовосстановление.** Фоновые механизмы находят и чинят зависшие задачи: упавший агент
+  перезапускается, осиротевшая задача возвращается в очередь, переполненный диск чистится,
+  а независимый сторож следит за самой платформой снаружи.
+- **Пакетный авто-режим.** Задачи одного проекта выстраиваются в очередь и едут друг за другом
+  без столкновений; специальными метками на задаче можно снять оба человеческих одобрения —
+  и пакет задач уедет «за ночь» полностью автономно.
+- **Дешёвый багфикс-маршрут.** Задача с меткой «баг» едет коротким путём — без тяжёлой
+  аналитики и отдельной стадии проектирования, но через все те же гейты качества.
+- **Отмена задачи одной кнопкой.** Перевод задачи в статус «STOP» в трекере останавливает
+  работу, снимает её с очереди и прибирает за собой — безопасно даже посреди конвейера.
+- **Наблюдаемость.** У каждой задачи — живая карточка в Telegram (стадия, время, стоимость);
+  у платформы — служебные страницы состояния и машинные метрики; история отклонений пишется
+  в журнал уроков.
+- **Самообслуживание (self-hosting).** Платформа дорабатывает сама себя тем же конвейером,
+  с обязательной репетицией на песочнице и ручным подтверждением выкладки.
+- **Тиражируемость.** Платформа разворачивается на новой инфраструктуре без правки кода:
+  вариант Lite (у заказчика своя инфраструктура) и вариант Bundled (весь стек одним
+  комплектом) — по пошаговым инструкциям.
+
+## Ценность
+
+- ⚡ **Скорость.** Полный цикл «постановка → прод» без очередей между ролями; по оценке из
+  [Product Vision](../PRODUCT_VISION.md) — порядка 35 минут на типовую фичу без ручных
+  вмешательств.
+- 💰 **Стоимость.** Работа агентов в разы дешевле команды специалистов; стоимость каждой
+  задачи видна в её карточке — расходы прозрачны.
+- 🎯 **Автономность.** Ноль ручных пинков в штатном прогоне: человек принимает решения,
+  а не двигает задачу.
+- 🛡️ **Надёжность.** Многоуровневые гейты качества и репетиция выкладки на песочнице не
+  пускают недоделку на прод; сломавшаяся выкладка откатывается, проект замораживается до
+  разбора.
+- 🔁 **Масштаб.** Одна платформа — несколько проектов; сама платформа тиражируется на новые
+  хосты за часы по инструкции.
+
+## Сценарии использования
+
+### Сценарий 1: фича за вечер
+Заказчик формулирует задачу в трекере и переводит её в работу. Конвейер собирает требования,
+проектирует, пишет код и тесты, проходит ревью и тестирование, репетирует выкладку. Человек
+дважды нажимает «одобрить» — на постановке и перед продом. Вечером фича на проде.
+
+### Сценарий 2: багфикс по короткому маршруту
+На задачу ставится метка «баг» — конвейер пропускает тяжёлую аналитику и отдельное
+проектирование, сразу чинит и фиксирует дефект регресс-тестом. Все гейты качества — без
+исключений.
+
+### Сценарий 3: пакет задач на ночь
+Несколько задач проекта получают метки авто-одобрения. Очередь проводит их друг за другом:
+каждая следующая стартует от свежей версии кода с результатом предыдущей. Утром — пакет
+изменений на проде и полный след по каждой задаче.
+
+### Сценарий 4: несколько проектов параллельно
+Один инстанс платформы обслуживает несколько репозиториев: задачи разных проектов едут
+одновременно, не мешая друг другу; внутри одного проекта порядок строго последовательный.
+
+### Сценарий 5: развернуть платформу у себя
+Заказчик получает платформу на своей инфраструктуре по инструкции
+[Lite](../deployment/LITE_SETUP.md) (есть свои трекер и git) или
+[Bundled](../deployment/BUNDLED_SETUP.md) (весь стек одним комплектом, ~14 контейнеров),
+со свежими секретами и проверкой каждого шага.
+
+### Сценарий 6: остановить задачу
+Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и
+рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в
+необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения.
+
+---
+
+*Технические детали каждой способности — в [тех-части витрины](README.md): как устроен
+[конвейер](tech-pipeline.md), кто такие [агенты](tech-agents.md), как работает
+[наблюдаемость](tech-observability.md).*

docs/overview/presentation.md

@@ -0,0 +1,190 @@
+# Презентация системы: слайдо-источник
+
+> Источник истины презентации. Каждый слайд — блок `## Слайд N: Заголовок` с тезисами
+> (3–6 на слайд) и опциональной подписью визуала. Из этого файла собирается редактируемый
+> PowerPoint в тёмном дизайне — процедура в конце файла («Как собрать .pptx»). Собранный
+> бинарь в git не коммитится: меняешь рассказ — правишь этот файл и пересобираешь.
+
+## Слайд 1: Orchestrator — автономная фабрика разработки
+
+- Конвейер из ИИ-агентов: от постановки задачи до выкладки на прод
+- Человек ставит задачу и принимает результат — всё между автономно
+- Платформа уже работает: ведёт несколько проектов и дорабатывает сама себя
+
+> Визуал: тёмный титул, логотип-конвейер из шести звеньев
+
+## Слайд 2: Проблема
+
+- Классическая разработка — люди-бутылочное-горлышко на каждом шаге
+- Каждая передача между ролями — потеря времени, контекста и денег
+- Мелкая фича или баг едут до прода днями — из-за очередей, не сложности
+
+> Визуал: цепочка из шести человек с песочными часами между ними
+
+## Слайд 3: Решение
+
+- Шесть ИИ-агентов проводят задачу через все стадии разработки сами
+- Аналитик → архитектор → разработчик → ревьюер → тестировщик → деплойер
+- Человек принимает два решения: одобрить постановку и подтвердить прод
+- Честность держат машинные гейты качества — их нельзя «уговорить»
+
+> Визуал: та же цепочка, но из агентов; человек над ней с двумя кнопками
+
+## Слайд 4: Как это работает — конвейер
+
+- Задача из трекера едет по стадиям: анализ → проектирование → код → ревью → тесты → репетиция → прод
+- На каждом переходе — гейт: машинная проверка честности стадии
+- Не прошёл гейт — задача возвращается на доработку с замечаниями
+- Каждая задача — своя ветка и изолированная рабочая копия кода
+
+> Визуал: горизонтальная схема стадий со шлагбаумами-гейтами
+
+## Слайд 5: Гейты качества
+
+- Вердикты машинные: зелёный CI, одобрение ревью, отчёт тестов — только структурированные ключи
+- Перед продом — четыре дополнительных проверки: безопасность, слияние, покрытие тестами, свежесть сборки
+- Покрытие тестами не может деградировать: базовая линия растёт только вверх
+- Слияние в основную ветку — только через PR; прямой push запрещён всем
+
+> Визуал: четыре шлагбаума подряд перед воротами «прод»
+
+## Слайд 6: Роли агентов
+
+- Аналитик: требования, критерии приёмки, тест-план
+- Архитектор: проектные решения с фиксацией в ADR
+- Разработчик: код + тесты + документация одним PR
+- Ревьюер и тестировщик: независимые машинные вердикты
+- Деплойер: репетиция на песочнице, затем прод
+
+> Визуал: шесть карточек-ролей с артефактами на выходе
+
+## Слайд 7: Человек в контуре
+
+- Постановщик и приёмщик, а не оператор: ноль ручных пинков в штатном прогоне
+- Решение 1: одобрить постановку после аналитики
+- Решение 2: подтвердить выкладку на прод отдельным статусом
+- Живая карточка задачи в Telegram показывает, когда конвейер ждёт вас
+
+> Визуал: человек с двумя кнопками и карточка задачи в телефоне
+
+## Слайд 8: Пакетный автономный режим
+
+- Задачи одного проекта едут строго друг за другом — без столкновений
+- Каждая следующая стартует от свежего кода с результатом предыдущей
+- Метки авто-одобрения снимают оба человеческих гейта — пакет уезжает «за ночь»
+- Технические проверки при этом не ослабляются ни на одну
+
+> Визуал: ночная очередь задач, утром — стопка готовых
+
+## Слайд 9: Багфикс за полцены
+
+- Метка «баг» — и задача едет коротким маршрутом
+- Пропускаются тяжёлая аналитика и отдельное проектирование
+- Обязателен регресс-тест, фиксирующий дефект
+- Все гейты качества — без исключений
+
+> Визуал: развилка маршрутов — длинный и короткий путь к одному финишу
+
+## Слайд 10: Самовосстановление
+
+- Упавший агент перезапускается, осиротевшая задача возвращается в очередь
+- Зависшие состояния находит и чинит фоновый сверщик
+- Независимый сторож следит за платформой снаружи и шлёт алерты отдельным каналом
+- Деградация прода после выкладки замораживает проект до разбора человеком
+
+> Визуал: платформа с автоподзаводом и внешним сторожем
+
+## Слайд 11: Наблюдаемость
+
+- Одна задача — одна живая карточка: стадия, агент, стоимость, время
+- Служебные страницы: снимок очереди и машинные метрики для мониторинга
+- Журнал уроков копит отклонения конвейера — фундамент самообучения
+- Стоимость каждой задачи и каждой роли видна по фактам
+
+> Визуал: дашборд из карточки, очереди и графика стоимости
+
+## Слайд 12: Одна платформа — много проектов
+
+- Несколько репозиториев из одного инстанса с общей очередью
+- Внутри проекта — строгий порядок, между проектами — параллельность
+- Платформа дорабатывает сама себя тем же конвейером (self-hosting)
+- Своя доработка репетируется на песочнице и требует явного подтверждения
+
+> Визуал: один конвейер, несколько лент с разными проектами
+
+## Слайд 13: Сценарии использования
+
+- Фича за вечер: постановка → прод с двумя кликами человека
+- Пакет задач на ночь: метки авто-одобрения, утром всё на проде
+- Багфикс по короткому маршруту с обязательным регресс-тестом
+- Остановить задачу: статус STOP — безопасная отмена с уборкой
+- Несколько проектов параллельно без пересечений
+
+> Визуал: пять пиктограмм-сценариев
+
+## Слайд 14: Тираж платформы
+
+- Разворачивается на новой инфраструктуре без правки кода — только конфиг
+- Lite: у заказчика свои трекер и git — ставятся только оркестратор и сторож
+- Bundled: весь стек одним комплектом (~14 контейнеров) и бутстрап-скрипт
+- Свежие секреты, пошаговые инструкции с проверкой каждого шага
+
+> Визуал: коробка-дистрибутив в двух размерах
+
+## Слайд 15: Статус платформы сегодня
+
+- В проде: автономный конвейер, мультипроектность, самовосстановление
+- В проде: пакетный авто-режим, багфикс-маршрут, отмена задач, журнал уроков
+- Тираж Lite и Bundled — готовые инструкции и инструменты
+- Платформа развивает сама себя: документация и гейты растут с каждой задачей
+
+> Визуал: чек-лист способностей с отметками «в проде»
+
+## Слайд 16: Итог
+
+- Разработка без очередей между ролями: задача → прод за один проход
+- Человек принимает решения — конвейер делает работу
+- Качество держат машинные гейты, прозрачность — живая карточка и метрики
+- Следующий шаг: поставить первую задачу или развернуть платформу у себя
+
+> Визуал: тёмный финальный слайд с одной фразой-приглашением
+
+---
+
+## Как собрать .pptx
+
+Сборка выполняется **вне рантайма платформы** — в одноразовом dev-окружении на хосте
+разработчика (зависимость генерации не входит в прод-образ). Скрипт —
+`scripts/build_presentation.py`; формат слайдов выше парсится им же (один парсер — один
+источник истины).
+
+**Шаг 1. Создать venv и поставить python-pptx:**
+
+```bash
+python3 -m venv .venv-pptx
+.venv-pptx/bin/pip install python-pptx
+```
+
+Проверка: `.venv-pptx/bin/pip show python-pptx` печатает версию пакета — PASS; ошибка
+установки — FAIL (проверьте доступ к PyPI).
+
+**Шаг 2. Собрать презентацию (из корня репозитория):**
+
+```bash
+.venv-pptx/bin/python scripts/build_presentation.py
+```
+
+Проверка: скрипт печатает `Собрано слайдов: <N> → build/orchestrator-overview.pptx`, где
+`<N>` равно числу слайдов в этом файле — PASS; `ОШИБКА: …` — FAIL (текст подскажет причину).
+
+**Шаг 3. Открыть и проверить результат:**
+
+Откройте `build/orchestrator-overview.pptx` в PowerPoint/LibreOffice. Проверка: тема тёмная
+(тёмный фон, светлый текст, акцентные заголовки), кириллица отображается точно, текст слайдов
+выделяется и редактируется — PASS. Каталог `build/` в `.gitignore`: собранный бинарь в git
+не попадает.
+
+---
+
+*Нарратив слайдов опирается на [business.md](business.md); технические утверждения — на
+тех-блоки витрины ([конвейер](tech-pipeline.md), [агенты](tech-agents.md)).*

docs/overview/tech-agents.md

@@ -0,0 +1,60 @@
+# Блок 3. Агенты: 6 ролей конвейера
+
+> Промпты ролей лежат в `.openclaw/agents/*.md` (по одному файлу на роль). Канон манифеста
+> «документ → агент → стадия → гейт → machine-key» — [PIPELINE_DOCS §2](../_standards/PIPELINE_DOCS.md);
+> машинный контракт передачи между стадиями — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).
+
+## Паспорта ролей
+
+| Роль | Стадия | Вход | Выходные артефакты | Machine-verdict ключ |
+|------|--------|------|--------------------|----------------------|
+| `analyst` | analysis | бизнес-запрос (`00-business-request.md`) | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | — (гейт проверяет полноту пакета + одобрение человека) |
+| `architect` | architecture | пакет аналитики | `06-adr/ADR-NNN-*.md`, when-applicable `07-infra-requirements.md` / `08-data-requirements.md`, `10-tech-risks.md` | — (гейт проверяет наличие ADR) |
+| `developer` | development | ТЗ + ADR | код в `src/`, тесты в `tests/`, обновлённые доки, `CHANGELOG.md`, PR в Gitea | — (гейт — зелёный CI ветки) |
+| `reviewer` | review | PR diff + ТЗ/ADR | `12-review.md` | `verdict:` (`APPROVED` \| `REQUEST_CHANGES`) |
+| `tester` | testing | ветка задачи + тест-план | `13-test-report.md` | `result:` (`PASS` \| `FAIL` \| `BLOCKED`) |
+| `deployer` | deploy-staging / deploy | прошедшая гейты ветка | `15-staging-log.md`, `14-deploy-log.md` | `staging_status:` / `deploy_status:` (`SUCCESS` \| `FAILED`) |
+
+Machine-verdict ключи читаются гейтами **только из YAML-frontmatter** артефакта (никогда из
+прозы) и неизменны байт-в-байт — подробнее в [блоке качества](tech-quality-security.md).
+
+## Модель и эффорт
+
+Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
+дефолты конфига:
+
+| Роль | Модель | Эффорт |
+|------|--------|--------|
+| `analyst` | `claude-opus-4-8` | `high` |
+| `architect` | `claude-opus-4-8` | `high` |
+| `developer` | `claude-opus-4-8` | `xhigh` |
+| `reviewer` | `claude-opus-4-8` | `high` |
+| `tester` | `claude-opus-4-8` | `medium` |
+| `deployer` | `claude-opus-4-8` | `medium` |
+
+Разработчику — максимальный эффорт (он пишет код); тестировщику и деплойеру хватает среднего
+(их работа процедурная). Таблица сверяется с class-default'ами `src/config.py` структурным
+тестом — дрейф рвёт CI.
+
+## Канон промптов
+
+Все промпты следуют единому канону (Anthropic XML, эпик 52): пять обязательных секций в
+нормативном порядке `<context>` → `<task>` → `<deliverables>` → `<constraints>` →
+`<output_format>`, запреты в формате «❌ X → ✅ Y», секция эскалации у решающих ролей. Каждый
+агент эмитит единую frontmatter-схему в своих документах (work item, стадия, автор, статус,
+дата, модель). Промпт читается из worktree в момент запуска — обновление промптов вступает в
+силу со следующей задачи, без рестарта прода.
+
+Особенность: промпт `deployer` сознательно на английском (самый safety-critical — несёт
+запреты self-hosting в видной рамке); остальные пять — на русском.
+
+## Человек как седьмая роль
+
+Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы
+агентам: одобрение постановки (после `analyst`) и подтверждение прод-выкладки (перед финалом
+работы `deployer`). Подробнее — [человеческие гейты](tech-pipeline.md).
+
+---
+
+*Структуры документов, которые сдаёт каждая роль, — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md);
+скелеты — `docs/_templates/`.*

docs/overview/tech-architecture.md

@@ -0,0 +1,63 @@
+# Блок 1. Архитектура: компоненты и связи
+
+> Обзорный уровень. Полная таблица компонентов с деталями и историей решений — в
+> [инженерном справочнике](../architecture/README.md) («Компоненты») и
+> [internals](../architecture/internals.md); здесь — цельная картина, как части складываются
+> в конвейер.
+
+## Поток одной задачи
+
+```
+            Plane (трекер)            Gitea (git/CI)
+                 │ вебхук                  │ вебхук
+                 ▼                         ▼
+        ┌────────────────────────────────────────┐
+        │   FastAPI-приём (HMAC-подпись, дедуп)  │
+        └───────────────────┬────────────────────┘
+                            ▼
+   вебхук → очередь (jobs) → агент (Claude CLI в worktree) → гейт (QG) → переход стадии
+                            ▲                                              │
+                            └────────── следующая стадия / откат ◄─────────┘
+```
+
+Каждое продвижение задачи — один и тот же цикл: событие принято → в очередь поставлен job →
+worker запустил агента стадии → результат проверен гейтом качества → state machine перевела
+задачу на следующую стадию (или откатила назад).
+
+## Компоненты
+
+| Компонент | Роль |
+|-----------|------|
+| **Webhook-приёмники** (`src/webhooks/`) | Принимают события Plane (статусы задач) и Gitea (push, PR, CI). Проверяют HMAC-подпись, дедуплицируют повторные доставки. |
+| **Очередь задач** (`jobs` + worker) | Собственная очередь на SQLite: атомарный захват job'а, ретраи с backoff, зависимости между job'ами, ограничение параллелизма. |
+| **State machine** (`src/stages.py`) | Карта стадий `STAGE_TRANSITIONS`: для каждой стадии — следующая, агент и гейт выхода. Единственный источник истины о конвейере. |
+| **Stage engine** (`src/stage_engine.py`) | Исполняет переходы: диспетчеризация гейтов, откаты, под-гейты деплойного ребра, синхронизация статусов с Plane. |
+| **Agent launcher** (`src/agents/launcher.py`) | Запускает Claude CLI агента в изолированном git worktree ветки задачи, следит за процессом (watchdog), авто-продвигает стадию по завершении. |
+| **Реестр гейтов** (`src/qg/checks.py`) | `QG_CHECKS` — машинные проверки выхода со стадий; вердикты читаются только из YAML-frontmatter артефактов. |
+| **Plane-sync** (`src/plane_sync.py`) | Индикация статусов в Plane (слой «показать человеку», никогда не управление конвейером). |
+| **Notifications** (`src/notifications.py`) | Живая Telegram-карточка задачи и алерты. |
+
+## Фоновые демоны (самовосстановление)
+
+Поднимаются в lifespan FastAPI-приложения (`src/main.py`) и работают рядом с конвейером:
+
+- **reconciler** — находит расхождения «БД говорит одно, реальность другое» (зависшие стадии,
+  потерянные ветки) и возвращает задачи в консистентное состояние;
+- **job-reaper** — возвращает в очередь job'ы, чей исполнитель умер (упавший процесс, рестарт);
+- **disk-watchdog** — следит за местом на диске, чистит устаревшие worktree;
+- **build-cache-pruner** — прибирает докер-кэш сборок.
+
+Отдельно от приложения живёт **sidecar-watchdog** — независимый контейнер-наблюдатель: следит
+за самим оркестратором снаружи (health, метрики) и шлёт алерты в собственный Telegram-канал.
+Наблюдатель сознательно отделён от наблюдаемого: падение оркестратора не валит сторожа.
+
+## Изоляция работы агентов
+
+Каждая задача живёт в собственной git-ветке (`feature/<ID>-slug`) и собственном **worktree** —
+изолированной рабочей копии репозитория. Агенты разных задач не видят незакоммиченную работу
+друг друга; слияние в `main` происходит только через PR в Gitea после всех гейтов.
+
+---
+
+*Подробнее: [компоненты и API](../architecture/README.md) · [внутренности и схема БД](../architecture/internals.md) ·
+следующий блок — [конвейер и стадии](tech-pipeline.md).*

docs/overview/tech-data-model.md

@@ -0,0 +1,70 @@
+# Блок 4. Структура объектов: каноническая модель
+
+> Источник истины — фактическая схема SQLite в `src/db.py` и реестр проектов в
+> `src/projects.py`; подробное описание таблиц — [internals, «Database Schema»](../architecture/internals.md).
+
+## Каноническая модель
+
+```
+Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N──► Agent-run
+   │                    │
+   │                    └── артефакты задачи (docs/work-items/<ID>/)
+   └── Plane-проект ↔ git-репозиторий ↔ префикс задач
+```
+
+### Project — проект в реестре
+Связка «Plane-проект ↔ git-репозиторий ↔ префикс задач» (например, `ORCH-`). Реестр живёт в
+конфиге (`src/projects.py`): один инстанс платформы обслуживает несколько проектов; по
+префиксу задачи платформа находит репозиторий и настройки.
+
+### Work-Item / Task — задача конвейера
+Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
+багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
+в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
+**артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
+deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).
+
+### Job — единица работы в очереди
+Строка таблицы `jobs`: что запустить (агент какой стадии), для какой задачи, в каком статусе
+(`queued` → `running` → терминал). Очередь даёт: **атомарный захват** (два worker'а не возьмут
+один job), **зависимости** между job'ами, **ретраи** с экспоненциальным backoff и breaker
+после исчерпания бюджета, ограничение параллелизма.
+
+### Agent-run — один запуск агента
+Строка таблицы `agent_runs`: какой агент, какой моделью и эффортом, сколько длился, сколько
+стоил (токены/доллары). Из этих строк складывается честная стоимость задачи в живой карточке
+и аналитика по ролям.
+
+### События вебхуков и дедуп
+Входящие события Plane/Gitea фиксируются с ключом дедупликации: повторная доставка того же
+события (ретраи источника, сетевые икоты) не порождает повторной работы.
+
+## Вспомогательные таблицы
+
+| Таблица | Зачем |
+|---------|-------|
+| `repo_freeze` | durable-заморозка репозитория после деградации прода (serial gate) |
+| `coverage_baseline` | базовая линия покрытия тестами; растёт только вверх (ratchet) |
+| `tracker_messages` | леджер всех Telegram-карточек задачи (зачистка сирот) |
+| `lessons` | машинный журнал уроков — структурированные отклонения конвейера |
+
+Все изменения схемы — аддитивные и идемпотентные (`CREATE TABLE IF NOT EXISTS`, ensure-column
+при старте): обновление платформы не требует ручных миграций.
+
+## Словарь терминов
+
+| Термин | Значение |
+|--------|----------|
+| **Стадия** | Позиция задачи в конвейере; карта стадий — `STAGE_TRANSITIONS` ([блок 2](tech-pipeline.md)) |
+| **Гейт (exit-гейт)** | Машинная проверка выхода со стадии; реестр — `QG_CHECKS` |
+| **Под-гейт** | Проверка-врезка внутри перехода (не стадия); см. деплойное ребро в [блоке 2](tech-pipeline.md) |
+| **Job** | Единица работы в очереди; задача порождает job'ы по мере продвижения |
+| **Worktree** | Изолированная рабочая копия репозитория для ветки задачи |
+| **Lease (merge-lease)** | Эксклюзивная блокировка «кто сейчас мержит этот репозиторий» — сериализация слияний |
+| **Track (маршрут)** | Вариант пути задачи: полный цикл или багфикс с пропуском проектирования |
+| **Freeze** | Заморозка очереди репозитория после инцидента до ручного разбора |
+
+---
+
+*Как объекты двигаются по конвейеру — [блок 2](tech-pipeline.md); кто их создаёт —
+[агенты](tech-agents.md); как за ними наблюдать — [блок 7](tech-observability.md).*

docs/overview/tech-integrations.md

@@ -0,0 +1,54 @@
+# Блок 5. Интеграции: Plane, Gitea, LLM, Telegram
+
+> Обзорный уровень; детали API, эндпоинтов и вебхуков — в
+> [инженерном справочнике](../architecture/README.md) и [internals](../architecture/internals.md).
+
+## Plane — управление задачами
+
+- **Вход конвейера:** перевод задачи в статус «To Analyse» — единственная точка запуска
+  пайплайна. Вебхуки Plane (HMAC-подписанные) доставляют изменения задач.
+- **Статусы = индикация, не управление** ([блок 2](tech-pipeline.md)): платформа сама
+  выставляет статусы доски, чтобы человек видел осмысленную картину; управляют конвейером
+  только машина стадий и три управляющих статуса (запуск, человеческие гейты, STOP).
+- **Лейблы** — декларативные переключатели на задаче: `autoApprove` / `autoDeploy` (снятие
+  человеческих гейтов), `Bug` (багфикс-маршрут). Источник истины — Plane API: ошибка чтения
+  лейблов трактуется как «лейбла нет» (fail-safe — никогда не «авто» по ошибке).
+- Платформа пишет в задачу комментарии о ходе работ (под ботами ролей) с кликабельными
+  ссылками на ветку/PR.
+
+## Gitea — git, PR, CI
+
+- **Каждая задача = одна ветка = один PR.** Ветка срезается от свежего `main`, работа идёт в
+  изолированном worktree, слияние — только после всех гейтов.
+- **Слияние строго через PR-merge API** — платформенный инвариант: прямой push или
+  force-push в `main` запрещён всем акторам, включая агентов и сам движок.
+- **Merge-актор устойчив к икотам:** транзиентные ошибки Gitea (таймаут, «try again later»)
+  ретраятся с backoff; необратимые — честный отказ без ложных повторов. Ветка, уже целиком
+  попавшая в `main`, распознаётся и не порождает мусорных PR.
+- **CI (Gitea Actions)** гонит полный тест-сьют на каждый push ветки; зелёный CI — гейт
+  выхода из разработки (`check_ci_green`).
+- Вебхуки Gitea (push, PR, статус CI) — второй источник событий конвейера.
+
+## LLM — Claude CLI
+
+- Агенты запускаются через **Claude CLI**: launcher собирает команду с промптом роли,
+  `--model` и эффортом, резолвленными **только из конфига** (таблица — в
+  [блоке агентов](tech-agents.md)); имя модели валидируется перед запуском.
+- Запуск — в worktree ветки задачи: агент видит код своей задачи и ничего лишнего.
+- Каждый запуск пишет в учёт стоимость и токены ([блок 7](tech-observability.md)).
+
+## Telegram — живой трекер и алерты
+
+- **Одна задача = одна живая карточка**: стадия, статус, модель/эффорт агента, стоимость,
+  честные метрики времени. Карточка обновляется «переездом вниз» чата (старая удаляется,
+  свежая приходит тихо); леджер карточек зачищает осиротевшие дубли.
+- **Алерты** (упавший гейт, ожидание человека, инциденты) приходят отдельными сообщениями
+  с пингом.
+- **Sidecar-watchdog шлёт в собственный канал** со своим ботом: наблюдатель за платформой
+  не зависит от её Telegram-стека.
+
+---
+
+*Развёртывание интеграций с нуля — [LITE_SETUP](../deployment/LITE_SETUP.md) /
+[BUNDLED_SETUP](../deployment/BUNDLED_SETUP.md); безопасность стыков —
+[блок 6](tech-quality-security.md).*

docs/overview/tech-observability.md

@@ -0,0 +1,54 @@
+# Блок 7. Наблюдаемость и аналитика
+
+> Машинный контракт метрик и устройство sidecar-наблюдателя — в
+> [инженерном справочнике](../architecture/README.md) (разделы `/metrics` и sidecar-watchdog).
+
+## Живая Telegram-карточка задачи
+
+Каждая задача — одна карточка в Telegram, обновляемая на каждом событии:
+
+- текущая стадия и Plane-статус (включая человеческие гейты — видно, когда задача ждёт вас);
+- строка работающего агента: роль · модель · эффорт;
+- стоимость задачи нарастающим итогом (токены/доллары по каждому запуску агента);
+- честные метрики времени на финише: время агентов / время ожидания человека / общее
+  календарное — три независимые цифры, а не одна вводящая в заблуждение сумма;
+- кликабельный номер задачи (ведёт в Plane), отметка багфикс-маршрута.
+
+Карточка тихая (без пингов); пингуют только алерты: красный гейт, ожидание решения человека,
+инциденты.
+
+## Служебные страницы платформы
+
+- **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
+  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, фоновые
+  демоны. Первая точка диагностики «что сейчас происходит».
+- **`GET /metrics`** — машинный контракт для внешнего наблюдателя (версионированная схема):
+  health, возраст последних событий, счётчики сбоев.
+- **`GET /health`** — живость процесса.
+
+## Sidecar-watchdog: наблюдатель отделён от наблюдаемого
+
+Отдельный контейнер-сторож опрашивает `/metrics` платформы и шлёт алерты в **собственный**
+Telegram-канал со **своим** ботом. Падение платформы, зависание очереди или протухание
+событий видно даже тогда, когда сама платформа уже не может пожаловаться.
+
+## Журнал уроков
+
+Машинная таблица отклонений конвейера: красные гейты, ложные блокировки слияния, исчерпание
+ретраев, деградации после выкладки. Каждая запись — контекст (задача, стадия, агент, репо),
+первопричина и предложение. Журнал — наблюдатель (никогда не влияет на продвижение задач) и
+фундамент петли самообучения платформы: уроки доступны через API и копятся для будущего
+ретроспективного анализа.
+
+## Стоимость и аналитика по агентам
+
+Каждый запуск агента фиксирует модель, эффорт, длительность и стоимость
+([модель объектов](tech-data-model.md)). Это даёт ответы на вопросы «сколько стоит задача»,
+«какая роль ест бюджет», «как изменилась экономика после смены модели» — по фактам, не по
+ощущениям.
+
+---
+
+*Что делать при инцидентах и как устроен прод — `docs/operations/` (через
+[инженерный справочник](../architecture/README.md)); бизнес-взгляд на наблюдаемость —
+[business.md](business.md).*

docs/overview/tech-pipeline.md

@@ -0,0 +1,103 @@
+# Блок 2. Конвейер: стадии, гейты, маршруты
+
+> Источник истины — карта переходов `STAGE_TRANSITIONS` в `src/stages.py` и реестр гейтов
+> `QG_CHECKS` в `src/qg/checks.py`; перечень ниже сверяется с кодом структурным тестом
+> (`tests/test_system_docs.py`). Норматив структуры доков конвейера —
+> [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md).
+
+## Схема конвейера
+
+```
+created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
+                          ↑                          │
+                          └──── REQUEST_CHANGES ─────┘   (откат на доработку, max 3)
+```
+
+Плюс системный сток **`cancelled`** — терминальное состояние отменённой задачи (кнопка STOP,
+см. ниже). Это не ребро конвейера, а равноправный `done` сток: попасть в него можно с любой
+стадии, выйти — нельзя.
+
+## Стадии и гейты выхода
+
+Гейт выхода (exit-гейт) — машинная проверка, без которой задача не покидает стадию:
+
+| Стадия | Кто работает | Гейт выхода (имя в реестре) | Что проверяет |
+|--------|--------------|------------------------------|----------------|
+| `created` | — | — | вход конвейера (вебхук Plane) |
+| `analysis` | analyst | `check_analysis_approved` | пакет аналитики полон И постановка одобрена человеком |
+| `architecture` | architect | `check_architecture_done` | ADR / инфра-требования зафиксированы |
+| `development` | developer | `check_ci_green` | CI на ветке задачи зелёный |
+| `review` | reviewer | `check_reviewer_verdict` | машинный вердикт ревью: APPROVED |
+| `testing` | tester | `check_tests_passed` | машинный вердикт тестера: PASS |
+| `deploy-staging` | deployer | `check_staging_status` | репетиция выкладки на песочнице успешна |
+| `deploy` | deployer / finalizer | `check_deploy_status` | прод-выкладка реально успешна |
+| `done` | — | — | терминал |
+| `cancelled` | — | — | терминал (сток отмены) |
+
+## Под-гейты деплойного ребра — врезки, не стадии
+
+На переходе `deploy-staging → deploy` исполняются четыре под-гейта в нормативном порядке
+(security → merge → coverage → image-freshness):
+
+1. `check_security_gate` — секреты/зависимости, вердикт из security-отчёта;
+2. `check_branch_mergeable` — merge-gate: ветка догнана до свежего `main` (под merge-lease)
+   и мержабельна;
+3. `check_coverage_gate` — покрытие тестами не ниже базовой линии/порога (baseline-ratchet);
+4. `check_staging_image_fresh` — staging-образ собран из актуального кода.
+
+Это **врезки в переход, а не стадии**: они не появляются в карте `STAGE_TRANSITIONS`, а
+исполняются stage engine'ом внутри ребра. Провал любого из них — откат на доработку. На ребре
+`deploy → done` аналогичная врезка merge-verify подтверждает, что код задачи реально слит в
+`main` (слияние — только через PR-API Gitea, см. [интеграции](tech-integrations.md)).
+
+## Откаты
+
+`REQUEST_CHANGES` от ревьюера, проваленные тесты или красный под-гейт возвращают задачу на
+стадию разработки с дословным перечнем замечаний. Лимит — 3 попытки подряд, дальше задача
+останавливается и требует человека (анти-петля).
+
+## Человеческие гейты и их снятие авто-лейблами
+
+В штатном прогоне человек принимает ровно два решения:
+
+- **Одобрение постановки** (на `analysis`): перевод задачи в статус Approved пропускает её
+  дальше;
+- **Подтверждение прод-выкладки** (на `deploy`): отдельный статус **Confirm Deploy** — чтобы
+  привычный «approve» не выкатывал прод случайным кликом.
+
+Оба решения можно снять декларативно — лейблами **autoApprove** / **autoDeploy** на задаче
+(пакетный авто-режим). Снимается только ожидание человеческого сигнала: ни одна техническая
+проверка не пропускается, autoDeploy физически не может выкатить непрошедшее под-гейты.
+
+## Багфикс-маршрут
+
+Задача с меткой **Bug** едет коротким путём: облегчённая аналитика (но полный пакет
+документов) и пропуск стадии `architecture` — из аналитики сразу в разработку. Срезается
+только аналитика/проектирование: **все гейты исполняются без изменений**. Сложный баг
+эскалируется обратно в полный цикл.
+
+## Последовательность внутри репозитория (serial gate)
+
+Новая задача репозитория не входит в работу, пока не завершена более ранняя (FIFO): ветка
+каждой задачи срезается от свежего `main`, уже содержащего код предшественника. Деградация
+прода после выкладки замораживает репозиторий (freeze) до ручного разбора — следующие задачи
+ждут.
+
+## Отмена: STOP → `cancelled`
+
+Перевод задачи в статус **STOP** останавливает агента, снимает job'ы с очереди, удаляет
+рабочую ветку и worktree и переводит задачу в `cancelled`. Если задача в необратимой фазе
+(идёт слияние/выкладка) — отмена откладывается и применяется после честного завершения шага.
+STOP никогда не трогает `main` и прод-контейнер.
+
+## Статусная модель Plane: индикация ≠ управление
+
+Статусы в Plane — слой **индикации**: они показывают человеку осмысленную картину хода задачи,
+но никогда не управляют конвейером (машина стадий — только `STAGE_TRANSITIONS`). Управляющих
+статусов ровно три: запуск в работу, Approved/Confirm Deploy (человеческие гейты) и STOP
+(отмена). Полная карта статусов — в [инженерном справочнике](../architecture/README.md).
+
+---
+
+*Кто работает на каждой стадии и что сдаёт — [агенты](tech-agents.md); как гейты читают
+вердикты — [качество и безопасность](tech-quality-security.md).*

docs/overview/tech-quality-security.md

@@ -0,0 +1,63 @@
+# Блок 6. Качество и безопасность
+
+> Реестр гейтов и их распределение по стадиям — [блок 2](tech-pipeline.md); механизм
+> machine-verdict доков — [PIPELINE_DOCS §3](../_standards/PIPELINE_DOCS.md); машинный
+> контракт стадий — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).
+
+## Философия Quality Gates
+
+**Вердикты — машинные, никогда проза.** Гейт читает вердикт ТОЛЬКО из YAML-frontmatter
+артефакта (ключи вида `verdict:`, `result:`, `staging_status:`, `deploy_status:`,
+`security_status:` — имена и регистр неизменны байт-в-байт). Агент не может «уговорить» гейт
+красивым отчётом: нет ключа — нет прохода. Парсинг frontmatter сведён к единому контракту
+`src/frontmatter.py` — одна точка чтения для всех гейтов.
+
+**Гейт ≠ маршрутизация.** Маршруты задач (багфикс-трек, авто-лейблы, serial gate) — свойство
+планировщика; ни один из них не ослабляет ни одного гейта. Любая новая способность платформы
+проектируется так, чтобы реестр гейтов и карта стадий не трогались.
+
+**Анти-петля.** Откаты на доработку ограничены (max 3 подряд); инструментальные сбои
+вспомогательных проверок по умолчанию fail-open с предупреждением (не запирают конвейер),
+критичные проверки — fail-closed.
+
+## Специальные гейты деплойного ребра
+
+- **Security-гейт** (`check_security_gate`) — детерминированная (без LLM) проверка секретов и
+  зависимостей перед продом; вердикт — `security_status:` в отчёте задачи.
+- **Coverage-гейт** (`check_coverage_gate`) — покрытие тестами измеряется на финальном коде
+  ветки; базовая линия по репозиторию растёт только вверх (ratchet при подтверждённом
+  слиянии) — покрытие не может деградировать молча.
+
+Оба — врезки в переход ([блок 2](tech-pipeline.md)), включаются по конфигу и скоупятся по
+репозиториям.
+
+## Канон секретов
+
+- Секреты живут **только в `.env`-файлах на хосте** и никогда не коммитятся; в git — только
+  канон-примеры с пустыми плейсхолдерами.
+- Для нового хоста секреты **выпускаются свежими** (`scripts/gen_secrets.py`), боевые не
+  копируются.
+- Анти-регресс машинный: структурные тесты сканируют исполняемый код на боевые хост-литералы,
+  а документацию — на секретоподобные значения; находка рвёт CI.
+
+## Self-hosting-страховки
+
+Платформа дорабатывает сама себя тем же конвейером — прод-инстанс при этом обслуживает и
+другие проекты. Страховки:
+
+- **Песочница обязательна:** перед прод-выкладкой платформы изменение репетируется на
+  staging-инстансе (отдельный порт/БД); guard не даёт staging-операциям коснуться прод-порта.
+- **Прод-выкладка — только по явному человеческому статусу Confirm Deploy** (обычный approve
+  прод не выкатывает); деплой идёт детачнутым процессом с финализатором — честный исход
+  фиксируется даже при рестарте.
+- **`main` неприкосновенен:** слияние только через PR-API, force-push запрещён всем.
+- **Прод-контейнер никогда не роняется задачей**: агенты проверяют изменения локально и на
+  песочнице; рестарт прода — только штатным деплой-маршрутом.
+- **Пост-деплой наблюдение:** после выкладки платформа следит за своим здоровьем; деградация
+  замораживает репозиторий и зовёт человека.
+
+---
+
+*Операционные детали и топология прода — `docs/operations/` (см.
+[инженерный справочник](../architecture/README.md)); наблюдение за здоровьем —
+[блок 7](tech-observability.md).*

docs/work-items/ORCH-009/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
+
+Work Item ID: ORCH-009
+
+## Description
+
+TBD

docs/work-items/ORCH-009/01-brd.md

@@ -0,0 +1,176 @@
+---
+work_item: ORCH-009
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD: ORCH-009 — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
+
+Work Item: **ORCH-009** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
+Заказчик: Слава · Домен эпика: 📈 **D5 Масштаб (D5.2)** — `docs/epics/self-evolution.md`
+
+> ⚠️ **Актуализация Владельца 10.06 принята как приоритетная над исходной постановкой 05.06.**
+> Эталон онбординга = **сам репозиторий orchestrator** (каноны ORCH-52b/c/d/e уже кодифицированы),
+> НЕ enduro-trails (устаревший пример). «Дыра: у orchestrator только deployer.md» — уже закрыта
+> (в `.openclaw/agents/` полный набор 6 промптов). Скоуп — **способность** разворачивать новый
+> проект по образцу орка одним проходом; онбординг конкретного нового заказчика — исполнение этой
+> способности, вне данной задачи.
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1. Цель
+При подключении **нового** проекта к оркестратору одним проходом разворачивается всё, что нужно
+мульти-агентам для автономной работы: Plane-проект (статусы/лейблы под машинные контракты),
+Gitea-репо (+webhook), полный набор промптов агентов, структура документации по единым канонам,
+инфра-описание (INFRA.md), регистрация в реестре проектов. Агенты нового проекта **обязаны** знать,
+где лежит документация, использовать её и актуализировать.
+
+### 1.2. Проблема сегодня
+Онбординг проекта — ручная археология: шаги размазаны по докам (`SETUP_WEBHOOKS.md`,
+`INFRA.md`), памяти Стрима/Славы и инцидентам (прецедент 2026-06-02: webhook всего workspace +
+захардкоженный `default_repo` → задачи чужого проекта падали в enduro-trails; закрыто реестром
+ORCH-6). Любой пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не
+работает вовсе; без точных имён статусов Plane ветки `Confirm Deploy`/`STOP` молча не активируются
+(fail-closed); без лейблов авто-режимы и багфикс-трек молча выключены (fail-safe). Турникей-проход
+обязан закрывать все слои сразу и проверяемо.
+
+### 1.3. Установленные факты (проверено по коду, не изобретать)
+
+| # | Факт | Где проверено |
+|---|------|---------------|
+| Ф-1 | Промпты агентов — **per-repo**: launcher резолвит `system_prompt: .openclaw/agents/<role>.md` относительно worktree репо задачи. Нет промптов в новом репо → конвейер для него не работает. | `src/agents/launcher.py` (реестр AGENTS, 6 ролей) |
+| Ф-2 | Агент видит **только** worktree своего репо → каноны (шаблоны/стандарты) обязаны быть **скопированы** в новый репо; «ссылка на репо орка» агенту недоступна. | модель worktree `src/git_worktree.py`, launcher |
+| Ф-3 | Реестр проектов строится **при импорте** из `ORCH_PROJECTS_JSON` (или built-in default): ключи `plane_project_id`/`repo`/`work_item_prefix`/`name` + опц. `agent_models`/`agent_efforts`. Регистрация нового проекта = правка `.env` на хосте + **управляемый рестарт** (операторский шаг). | `src/projects.py` (`_parse_projects_json`, `_load_projects`) |
+| Ф-4 | Статусы Plane резолвятся по **точным именам** (22 ключа `_PLANE_NAME_TO_KEY`); `Confirm Deploy` (ORCH-059) и `STOP` (группа `cancelled`, ORCH-090) — **fail-closed** (нет статуса на доске → ветка не активируется); TTL-self-heal 300с (ORCH-068) — статус, добавленный позже, подхватывается без рестарта. | `src/plane_sync.py` (`_PLANE_NAME_TO_KEY`, `get_project_states`) |
+| Ф-5 | Лейблы `autoApprove`/`autoDeploy` (ORCH-089) и `Bug` (ORCH-019) — **fail-safe** (нет лейбла → ручной режим / полный цикл); сопоставление по нормализованному имени через Plane API. | `src/labels.py`, `src/bug_fast_track.py`, CLAUDE.md (инфра-предусловия) |
+| Ф-6 | Plane-webhook — **workspace-level** (один на все проекты, уже существует; в Plane CE создаётся SQL-ом, внешнего API нет). Gitea-webhook — **per-repo** (создаётся через API; events `push`/`pull_request`/`status`; HMAC-secret). | `docs/operations/SETUP_WEBHOOKS.md`, docstring `src/projects.py` |
+| Ф-7 | Каноны (golden source) в репо орка: `docs/_templates/` — 16 скелетов (`00…18`, ORCH-52b); `docs/_standards/` — `HANDOFF_PROTOCOL.md`/`PIPELINE_DOCS.md`/`TRACEABILITY.md` (ORCH-52c/e); `.openclaw/agents/*.md` — 6 промптов канона Anthropic (ORCH-52d/92; `deployer.md` — английский **нормативно**, ADR-001 D2 ORCH-092); ADR-конвенция — `PIPELINE_DOCS.md` §4. | листинг репо, `docs/_standards/PIPELINE_DOCS.md` |
+| Ф-8 | Per-repo паспорт `CLAUDE.md` — канон самого ORCH-9 (подпись в паспорте орка: «канон per-repo, см. ORCH-9»); все 6 промптов орка начинаются с «прочти CLAUDE.md». | `CLAUDE.md`, `.openclaw/agents/*.md` |
+
+### 1.4. Принятая трактовка постановки (расхождения 05.06 ↔ 10.06)
+- **Реализация в репо orchestrator** (данный конвейер пишет в этот репо; каноны живут здесь).
+  Упоминание отдельного репо `onboard2orch` (05.06) — историческое: его пример enduro-trails
+  объявлен устаревшим; судьба репо — операторское решение вне кода (рекомендация: архивировать/
+  оставить указатель, чтобы не плодить второй источник канона). Эскалации не требует: актуализация
+  10.06 прямо говорит «каноны кодифицированы в репо орка — их и брать за образец».
+- **Раскладка docs/**: слой-1 постановки (05.06) указывал `docs/adr/`; канон орка —
+  `docs/architecture/adr/` (сквозные) + `docs/work-items/<id>/06-adr/` (per-task). Применяется
+  канон орка (эталон = орк).
+
+---
+
+## 2. Объём (scope)
+
+### 2.1. В объёме
+- **Onboarding-kit**: параметризуемый каркас нового репо — 6 промптов агентов, паспорт
+  `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/`
+  (включая `operations/INFRA.md`), копии `docs/_templates/` + `docs/_standards/`.
+- **Onboarding-скрипт** (операторский CLI, вне конвейера): Gitea-репо + per-repo webhook,
+  Plane-проект + статусы + лейблы (в мере, доступной API), материализация kit (подстановка
+  параметров) + initial push в свежесозданный репо, генерация валидной записи реестра, режимы
+  dry-run / apply / verify, идемпотентность.
+- **Runbook** `docs/operations/ONBOARDING.md`: полный чеклист, явная маркировка ручных шагов
+  (env + управляемый рестарт; UI-only действия Plane), верификация, откат.
+- **Верификация способности**: автоматические структурные тесты kit (pytest) + документированный
+  smoke-прогон на песочнице («агент по своему промпту находит доку, использует и актуализирует»).
+- **Актуализация обзорных доков** в том же PR (CLAUDE.md, `docs/architecture/README.md`,
+  CHANGELOG, обобщение `SETUP_WEBHOOKS.md`).
+
+### 2.2. Вне объёма (явно, не делать)
+- Исполнение онбординга конкретного нового заказчика/проекта (включая правку прод-`.env` и
+  рестарт прода) — операторская эксплуатация способности.
+- ORCH-10 — тиражирование платформы на новый хост (IaC-bundle); мультитенантность (D5.6);
+  параллелизм D5.1.
+- Стеки-плагины D4.1 (профили web/mobile/data/ML): kit параметризуется плейсхолдерами, без
+  механизма профилей.
+- Любые изменения `src/**`: машина стадий, QG, launcher, реестр `projects.py` (его контракт уже
+  достаточен — регистрация через `ORCH_PROJECTS_JSON`), схема БД.
+- Создание/миграция Plane workspace-webhook (уже существует, общий на workspace).
+- Слой-3 продуктовый мониторинг онбордируемого приложения (фундамент эпика, отдельные задачи).
+
+---
+
+## 3. Заинтересованные стороны
+- **Владелец/оператор (Слава, Стрим):** запускает онбординг, выполняет операторские шаги
+  (env, рестарт, UI-шаги Plane), принимает результат smoke-прогона.
+- **Будущие заказчики/проекты:** получают рабочий автономный конвейер «за минуты» (D5.2).
+- **Действующие проекты (enduro-trails, orchestrator):** не должны почувствовать онбординг
+  соседа — общий прод-инстанс, общая БД, общая очередь (self-hosting, ORCH-1).
+- **Агенты конвейера:** потребители kit — промпты обязаны вести их к доке проекта.
+
+---
+
+## 4. Бизнес-требования (BR)
+
+| ID | Требование | Связь |
+|----|------------|-------|
+| BR-1 | **Turnkey-проход:** один документированный проход (скрипт + runbook) разворачивает все слои: Plane-проект (статусы+лейблы) → Gitea-репо (+webhook) → kit в репо (initial push) → запись реестра → верификация. Список шагов закрыт и воспроизводим. | AC-1, AC-11 |
+| BR-2 | **Единый эталон без форка:** kit производится от **живых** канонов репо орка — `docs/_templates/`/`docs/_standards/` копируются в новый репо в момент онбординга «как есть»; параметризация — только в kit-собственных шаблонах (промпты, паспорт, INFRA и пр.). Вторая редактируемая копия канона внутри орка не создаётся. enduro-trails эталоном не является. | AC-5, Ф-2/Ф-7 |
+| BR-3 | **Полный набор промптов:** 6 ролей (analyst/architect/developer/reviewer/tester/deployer), параметризуемых под проект/стек, по канону Anthropic 52d: 5 XML-секций в нормативном порядке, запреты «❌ X → ✅ Y», `<escalation>` у developer/reviewer/tester (ORCH-092), добровольная эмиссия 6-польной frontmatter-схемы 52c, machine-verdict ключи байт-в-байт (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`). Каждый промпт жёстко направляет: читай паспорт/`AGENTS.md`/доку ПЕРЕД работой, пиши артефакты в `docs/work-items/<id>/` по канону, обновляй CHANGELOG/доку. | AC-2, AC-4 |
+| BR-4 | **Reviewer-gate на доку:** шаблон reviewer-промпта содержит проверку «документация обновлена; нет → REQUEST_CHANGES» (канон держится автоматически, не на честном слове). | AC-3 |
+| BR-5 | **Каркас репо полон:** `README.md`, `CHANGELOG.md`, `CONTRIBUTING.md`, `AGENTS.md` (точка входа агентов: карта доков + правила), паспорт `CLAUDE.md`, `docs/` (архитектура, конвейер, продукт-видение, `operations/`, ADR-реестр, `work-items/`, `history/`), копии `_templates/`+`_standards/`. Ссылочная целостность: промпты ссылаются только на реально существующие в каркасе пути. | AC-1, AC-5 |
+| BR-6 | **INFRA.md обязателен:** топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env-переменных (дескрипторы в репо, секреты только в `.env` на хосте, `.env.example` — канон), границы доступа, риски общего хоста. Для самого орка существующие self-hosting-предупреждения (общая БД/очередь/groupwide-риск рестарта) сохраняются нетронутыми. | AC-10 |
+| BR-7 | **Plane-проект под машинные контракты:** статусы с **точными** каноническими именами (все 22 имени `_PLANE_NAME_TO_KEY`, включая `Confirm Deploy` и `STOP` с группой `cancelled`) + лейблы `autoApprove`/`autoDeploy`/`Bug`. Что недоступно через Plane API — явный ручной пункт runbook с командой проверки. | AC-7, Ф-4/Ф-5 |
+| BR-8 | **Регистрация в реестре:** скрипт генерирует запись `ORCH_PROJECTS_JSON`, валидную через фактический парсер `projects._parse_projects_json` (round-trip). Применение env + рестарт — **операторский** шаг, явно описанный в runbook; скрипт прод-контейнер НЕ рестартит. | AC-6, AC-9, Ф-3 |
+| BR-9 | **Безопасность исполнения:** dry-run по умолчанию / явный apply; идемпотентный повторный прогон (доделывает недостающее, не дублирует, ничего не удаляет); аддитивность — существующие проекты/репо не модифицируются; push — только initial в свежесозданный пустой репо (никогда в `main` существующих). | AC-8, AC-9 |
+| BR-10 | **Верификация способности:** (а) автоматические структурные тесты kit/скрипта (pytest, без сети); (б) verify-режим: registry-валидность, резолв статусов, наличие webhook, полнота kit; (в) документированный smoke на песочнице: новый агент по своему промпту находит доку, использует и актуализирует её. | AC-12, AC-13 |
+| BR-11 | **Прозрачность:** каждый шаг скрипта логируется; итоговый отчёт «создано / уже было (пропущено) / требует ручного шага». | AC-8 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| NFR-1 | **`src/**` не меняется.** Изменение — docs/templates/scripts/tests-only. `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД, контракт `projects.py` — байт-в-байт. |
+| NFR-2 | **Self-hosting безопасность:** скрипт никогда не рестартит/не останавливает прод-контейнер, не пишет в общую БД, не пушит в `main` существующих репо, не трогает чужие Plane-проекты/Gitea-репо. Онбординг соседа не влияет на enduro/orchestrator. |
+| NFR-3 | **Секреты:** токены Plane/Gitea — только из env на хосте; сгенерированные секреты (webhook HMAC) выводятся оператору для `.env` и в гит не попадают; `.env.example` — канон. |
+| NFR-4 | **Anti-drift:** структурные тесты канона для kit-промптов (аналог `tests/test_agent_prompts_canon.py`) — расхождение kit с каноном 52d ловится CI, а не глазами. |
+| NFR-5 | **Оффлайн-тестируемость:** все тесты детерминированы, без реальных вызовов Plane/Gitea (моки); сетевые шаги изолированы за тонким слоем. |
+| NFR-6 | **Документация = golden source:** CLAUDE.md / `docs/architecture/README.md` / CHANGELOG обновлены в том же PR; reviewer-gate применим к самому PR. |
+
+---
+
+## 6. Допущения и ограничения
+- Plane API v1 позволяет создавать проект/статусы/лейблы (issue-API уже используется кодом);
+  если на практике какой-то вызов недоступен в CE — шаг деградирует в ручной пункт runbook
+  (fail-safe постановки, не блокер задачи).
+- Скрипт — операторский инструмент: запускается человеком на хосте с токенами из `.env`,
+  **вне** конвейера задач; конвейер его не вызывает.
+- Регистрация проекта вступает в силу после операторского рестарта (Ф-3) — это сознательное
+  ограничение (никакой автоматики рестартов, NFR-2); TTL-self-heal статусов (Ф-4) рестарта
+  не требует.
+- Песочница для smoke — staging-контур (8501, изолированная БД, sandbox-проект) либо одноразовый
+  sandbox-проект в Plane/Gitea; выбор фиксирует архитектор/оператор в runbook.
+- Языковая политика kit-промптов: по канону орка (5 ru + deployer en, ADR-001 D2 ORCH-092);
+  окончательное слово за архитектором, отступление — только с обоснованием в ADR.
+
+---
+
+## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
+- Kit полон и канон-чист (структурные тесты зелёные): 6 промптов 52d + reviewer-gate + каркас
+  репо + INFRA.md + копии канонов.
+- Скрипт: dry-run печатает полный план без мутаций; apply идемпотентен; registry-запись проходит
+  round-trip через фактический парсер; план Plane содержит точные имена статусов и лейблы.
+- Runbook закрывает 100% шагов (ручные — помечены) и верификацию.
+- `src/**` не тронут; пайплайн-инварианты байт-в-байт.
+- Smoke на песочнице: агент по промпту находит и актуализирует доку (документированный прогон).
+
+---
+
+## 8. Риски (кратко; детали — 10-tech-risks.md, заполняет архитектор)
+- **R-1 Drift канона:** копия канонов в kit/новых репо разъезжается с живым каноном орка →
+  митигируется BR-2 (live-copy в момент онбординга) + NFR-4 (структурные тесты).
+- **R-2 Тихая деградация Plane-контрактов:** опечатка в имени статуса/лейбла → fail-closed/
+  fail-safe ветки молча не работают → митигируется BR-7 (точные имена из кода) + verify-режимом.
+- **R-3 Скрипт с боевыми токенами:** ошибка = разрушительное действие → dry-run по умолчанию,
+  никаких delete-операций, аддитивность (BR-9).
+- **R-4 «Скрипт сделал — оператор не знает про env+restart»:** проект создан, но невидим для
+  оркестратора → runbook явно фиксирует операторские шаги + verify-режим показывает разрыв (BR-8/10).
+- **R-5 Утечка орк-специфики в kit:** новый проект получает чужие литералы (ORCH-, порты 8500/8501,
+  self-hosting-правила) → структурный тест на остаточные плейсхолдеры/литералы (AC-5).

docs/work-items/ORCH-009/02-trz.md

@@ -0,0 +1,227 @@
+---
+work_item: ORCH-009
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-009 — Онбординг проектов в оркестратор (turnkey)
+
+Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты). **Как** (точная
+> раскладка kit, механизм подстановки, формат CLI) — решает архитектор в `06-adr/`. Имена путей
+> ниже — рабочее предложение; архитектор вправе скорректировать, сохранив требования и AC.
+
+> ⚠️ Скоуп по актуализации 10.06: эталон = репо orchestrator; deliverables — в этом репо.
+> `src/**` НЕ меняется (NFR-1) — задача docs/templates/scripts/tests-only.
+
+---
+
+## 1. Сводка изменения
+Создать **способность turnkey-онбординга** нового проекта: (1) параметризуемый **onboarding-kit**
+(каркас нового репо: 6 промптов агентов по канону 52d/92, паспорт, AGENTS/CONTRIBUTING, скелет
+`docs/` с INFRA.md, копии живых канонов `_templates/`+`_standards/`); (2) операторский
+**onboarding-скрипт** (Gitea-репо + per-repo webhook; Plane-проект + статусы + лейблы;
+материализация kit + initial push; генерация записи реестра; dry-run/apply/verify; идемпотентно);
+(3) **runbook** `docs/operations/ONBOARDING.md` (полный чеклист, ручные шаги, верификация);
+(4) **структурные тесты** анти-дрейфа. Конвейер/движок не трогаются.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие | Роль |
+|------|----------|------|
+| `onboarding/repo-skeleton/**` | создать | параметризуемый kit нового репо (дерево зеркалит целевой репо: `.openclaw/agents/*.md`, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/**`) |
+| `onboarding/README.md` | создать | устройство kit: словарь плейсхолдеров, правило «канон не форкается» (что копируется live, что шаблонизируется) |
+| `scripts/onboard_project.py` | создать | операторский turnkey-CLI: `plan` (dry-run, дефолт) / `apply` / `verify`; идемпотентность; отчёт |
+| `docs/operations/ONBOARDING.md` | создать | runbook: последовательность, ручные шаги (env+рестарт, UI-only Plane), верификация, откат |
+| `docs/operations/SETUP_WEBHOOKS.md` | обновить | обобщить per-repo Gitea-webhook секцию (сейчас примеры захардкожены на enduro-trails); сослаться на ONBOARDING.md |
+| `tests/test_onboarding_kit.py` | создать | структура kit, канон промптов, reviewer-gate, INFRA/AGENTS/CONTRIBUTING |
+| `tests/test_onboarding_script.py` | создать | рендер/плейсхолдеры, registry round-trip, dry-run/идемпотентность, план Plane/Gitea (моки) |
+| `tests/test_onboarding_invariants.py` | создать | `src/**` не тронут логикой онбординга; снапшот `STAGE_TRANSITIONS`/`QG_CHECKS` |
+| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | обновить | golden source: раздел «Онбординг проектов (ORCH-009)», запись changelog |
+| `src/**` | **не менять** | NFR-1; скрипту разрешён **read-only import** `src.projects._parse_projects_json` / констант `src.plane_sync._PLANE_NAME_TO_KEY` для round-trip и точных имён (не дублировать литералы) — допустимость импорта vs снапшот-фикстура решает архитектор |
+
+Справочные источники kit (read-only): `.openclaw/agents/*.md`, `docs/_templates/` (16 скелетов),
+`docs/_standards/` (3 стандарта), `docs/operations/INFRA.md` (образец структуры RUNBOOK).
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Onboarding-kit: состав каркаса нового репо (BR-3/BR-5/BR-6)
+`onboarding/repo-skeleton/` содержит (минимум):
+
+```
+.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md   ← шаблоны промптов
+CLAUDE.md            ← паспорт проекта (per-repo канон, Ф-8)
+AGENTS.md            ← точка входа агентов: карта доков + правила ведения
+CONTRIBUTING.md      ← канон процесса: где что лежит, как вести
+README.md            ← entrypoint: что это, quickstart, ссылки
+CHANGELOG.md         ← пустой каркас
+docs/ARCHITECTURE.md         ← код-карта/потоки/БД (заполняется по мере жизни)
+docs/PIPELINE.md             ← стадии, QG, агенты (ссылается на _standards)
+docs/PRODUCT_VISION.md       ← зачем проект (BRD-свод)
+docs/operations/INFRA.md     ← обязательный RUNBOOK (см. FR-3)
+docs/architecture/adr/       ← реестр сквозных ADR (канон орка, §1.4 BRD)
+docs/work-items/.gitkeep
+docs/history/.gitkeep
+docs/_templates/   ← live-копия канона орка в момент онбординга (BR-2)
+docs/_standards/   ← live-копия канона орка в момент онбординга (BR-2)
+.env.example       ← заготовка карты env (без секретов)
+```
+
+- **Параметризация** — единый словарь плейсхолдеров (минимум): `{{PROJECT_NAME}}`, `{{REPO}}`,
+  `{{WORK_ITEM_PREFIX}}`, `{{PLANE_PROJECT_ID}}`, `{{STACK}}`, `{{TEST_CMD}}`,
+  `{{PROD_PORT}}`/`{{STAGING_PORT}}` (расширяемо; единый синтаксис, фиксирует архитектор).
+- **Ссылочная целостность:** каждый путь, на который ссылаются kit-промпты/AGENTS.md, существует
+  в каркасе (проверяемо тестом).
+- **Правило «канон не форкается» (BR-2):** `docs/_templates/` и `docs/_standards/` НЕ хранятся
+  второй редактируемой копией в kit — копируются скриптом из живого канона репо орка в момент
+  материализации. В kit хранятся только параметризуемые дельты (промпты, паспорт, AGENTS,
+  CONTRIBUTING, README, INFRA и пр.).
+
+### FR-2 — Шаблоны промптов 6 ролей по канону 52d/92 (BR-3/BR-4)
+Каждый из 6 шаблонов промптов:
+- 5 обязательных XML-секций в нормативном порядке `<context>` → `<task>` → `<deliverables>` →
+  `<constraints>` → `<output_format>`; `<success_criteria>`; `<escalation>` у
+  developer/reviewer/tester (после `</success_criteria>`); `<thinking>` у решающих ролей —
+  как в эталоне `.openclaw/agents/` (ORCH-077/092).
+- Запреты в формате «❌ X → ✅ Y».
+- Директивы доки (жёстко): читай `CLAUDE.md`(паспорт)/`AGENTS.md`/`docs/ARCHITECTURE.md`/ADR
+  ПЕРЕД работой; пиши артефакты в `docs/work-items/<id>/` по `docs/_standards/PIPELINE_DOCS.md`
+  (скелеты из `docs/_templates/`); архитектор фиксирует решения в `06-adr/` + сквозные в
+  `docs/architecture/adr/adr-NNNN-slug.md`; каждый обновляет `CHANGELOG.md`/релевантную доку.
+- **Reviewer:** содержит gate «документация обновлена? нет → `verdict: REQUEST_CHANGES`».
+- Эмиссия 6-польной frontmatter-схемы 52c (`work_item`/`stage`/`author_agent`/`status`/
+  `created_at`/`model_used`) — аддитивно; machine-verdict ключи и значения байт-в-байт
+  (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`); копируемые
+  примеры — с плейсхолдерами `<YYYY-MM-DD>`/`<resolve по конфигу>` (анти-паттерн ORCH-092 учтён).
+- Стек-специфика (язык/тесты/команды) — только через плейсхолдеры; никаких унаследованных
+  орк-литералов (порты 8500/8501, «ORCH-», self-hosting-правила орка) в материализованном виде.
+- Языковая политика: по канону орка (5 ru + deployer en, нормативно ADR-001 D2 ORCH-092);
+  отступление — только решением архитектора в ADR.
+
+### FR-3 — INFRA.md шаблон: обязательные секции (BR-6)
+Шаблон `docs/operations/INFRA.md` нового проекта содержит секции: топология (контейнеры, порты
+прод/staging, сеть, тома, БД); карта env-переменных (дескрипторы в репо; секреты ТОЛЬКО в `.env`
+на хосте; `.env.example` — канон; `docker-compose.yml`/`Dockerfile` трекаются в гите); границы
+доступа; эксплуатационные предупреждения, включая **риски общего хоста** (соседние контейнеры,
+общие ресурсы; факт: хост впритык — см. `docs/epics/self-evolution.md` С-3). Существующий
+`docs/operations/INFRA.md` орка с self-hosting-предупреждениями (общая БД/очередь/групповой риск
+рестарта) — не модифицируется этой задачей (read-only образец).
+
+### FR-4 — Onboarding-скрипт: провижининг (BR-1/BR-7/BR-9/BR-11)
+`scripts/onboard_project.py` (вход: имя проекта, repo, префикс work-item, параметры стека):
+- **Gitea:** создать репо (API), создать per-repo webhook (`push`/`pull_request`/`status`,
+  HMAC-secret из/для `.env` — формат `SETUP_WEBHOOKS.md`); материализовать kit → **initial push
+  в свежесозданный пустой репо** (единственный разрешённый push; в существующие репо — никогда).
+- **Plane:** создать проект (или принять существующий `--plane-project-id`); создать статусы со
+  **точными** именами из `_PLANE_NAME_TO_KEY` (22 имени; `STOP` — группа `cancelled`,
+  `Confirm Deploy` — отдельный статус; группы фиксирует архитектор по `plane_sync`) и лейблы
+  `autoApprove`/`autoDeploy`/`Bug`. Недоступное через API CE → пункт отчёта «ручной шаг» со
+  ссылкой на runbook (fail-safe, не падение).
+- **Реестр:** сгенерировать запись `ORCH_PROJECTS_JSON` (полный новый массив или диф —
+  фиксирует архитектор), **валидную через фактический `projects._parse_projects_json`**;
+  вывести оператору инструкцию «добавь в `.env` + управляемый рестарт». Скрипт сам `.env` прода
+  не правит и контейнер не рестартит (NFR-2).
+- **Режимы:** `plan` (дефолт; полный план без единой мутации), `apply` (исполнение),
+  `verify` (см. FR-5). Идемпотентность: повторный `apply` обнаруживает существующее
+  (репо/webhook/статусы/лейблы/файлы) и пропускает с пометкой; ничего не удаляет и не
+  перезаписывает существующий контент без явного флага.
+- **Прозрачность:** лог каждого шага + итоговый отчёт: `created / skipped(exists) / manual-step`.
+- **Webhook Plane:** не создаётся (workspace-level уже существует, Ф-6) — только проверка в verify.
+
+### FR-5 — Верификация (BR-10)
+- `verify`-режим скрипта: запись реестра парсится (`_parse_projects_json` round-trip → поля
+  совпадают); статусы проекта резолвятся (все логические ключи, включая `confirm_deploy`/`stop`);
+  лейблы присутствуют; Gitea-webhook существует и активен; kit-файлы в репо (включая 6 промптов,
+  AGENTS.md, INFRA.md, `_templates`/`_standards`); нет неразрешённых плейсхолдеров.
+- **Smoke на песочнице** (runbook, операторский): онбордить sandbox-проект → создать тестовую
+  задачу → стадия analysis в песочнице → убедиться: агент прочитал доку проекта (следы в
+  выводе/артефактах) и записал артефакты в `docs/work-items/<id>/` по канону. Контур песочницы
+  (staging 8501 / одноразовый sandbox) фиксирует архитектор в ADR + runbook.
+
+### FR-6 — Runbook ONBOARDING.md (BR-1/BR-8)
+Полный чеклист онбординга: предусловия (токены, доступы) → шаги скрипта → **операторские шаги**
+(env+рестарт — с предупреждением self-hosting: рестарт прода = групповое окно, выполнять
+осознанно; UI-only шаги Plane, напр. drag-and-drop порядок статусов) → верификация (verify +
+smoke) → откат (удаление созданного — вручную, скрипт не удаляет). Каждый ручной шаг — с командой
+проверки результата.
+
+---
+
+## 4. Изменения API
+**Нет.** Новые/изменённые HTTP-эндпоинты оркестратора не вводятся; вебхук-контракты не меняются.
+(Onboarding-CLI — операторский инструмент вне FastAPI-приложения.)
+
+## 5. Изменения схемы БД
+**Нет.** Общая БД не читается и не пишется скриптом (NFR-2).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Реестр `QG_CHECKS`/`check_*`/`STAGE_TRANSITIONS` — байт-в-байт (контроль — снапшот-тест,
+TC-18). Онбординг — операторская способность, не гейт конвейера.
+
+---
+
+## 7. Совместимость / регресс
+- **Нулевая регрессия кода:** `src/**` не меняется → поведение конвейера для enduro/orchestrator
+  идентично; полный регресс `tests/` остаётся зелёным.
+- **Kill-switch не требуется:** способность активируется только явным запуском операторского CLI;
+  в горячих путях конвейера нового кода нет.
+- **Обратимость:** удаление `onboarding/`/`scripts/onboard_project.py`/runbook возвращает репо в
+  исходное состояние; созданные онбордингом внешние сущности сносятся вручную по разделу
+  «Откат» runbook.
+- **Совместимость канонов:** kit-промпты проходят те же структурные требования, что эталонные
+  (анти-дрейф NFR-4); обновление канона орка автоматически подхватывается live-copy частью kit
+  (BR-2), шаблонные дельты — через обычные PR с reviewer-gate.
+
+---
+
+## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
+- `docs/work-items/ORCH-009/06-adr/ADR-001-…` — решения архитектора (раскладка kit, синтаксис
+  плейсхолдеров, copy-vs-template split по файлам, импорт `src` из скрипта vs снапшот, контур
+  песочницы, языковая политика kit-deployer).
+- `docs/architecture/README.md` — раздел «Онбординг проектов (ORCH-009)».
+- `CLAUDE.md` — краткий абзац о способности онбординга.
+- `CHANGELOG.md` — запись `feat:`.
+- `docs/operations/ONBOARDING.md` (новый), `docs/operations/SETUP_WEBHOOKS.md` (обобщение).
+- `07-infra-requirements.md` — предусловия онбординга (токены/доступы), заполняет архитектор.
+
+---
+
+## 9. Инварианты (не нарушать)
+- `src/**` без изменений; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема
+  БД — байт-в-байт (NFR-1).
+- Скрипт: не рестартит/не останавливает прод-контейнер; не пушит в `main` существующих репо
+  (INV-4 — мерж только через PR-merge API — не затрагивается: initial push идёт в свежесозданный
+  пустой репо, не являющийся участником конвейера до регистрации); не удаляет внешние сущности;
+  секреты в гит не попадают (NFR-2/NFR-3).
+- Никаких сетевых вызовов в тестах (NFR-5); никаких новых обязательных pip-зависимостей без
+  обоснования в ADR.
+- Эталонные промпты орка `.openclaw/agents/*.md` этой задачей не модифицируются (они — read-only
+  образец; их правка = отдельные задачи канона).
+
+---
+
+## 10. Открытые вопросы для архитектора (не блокируют анализ)
+- OQ-1: Раскладка kit — `onboarding/repo-skeleton/` (предложение) vs `docs/_onboarding/` vs
+  `scripts/onboarding/`; где словарь плейсхолдеров.
+- OQ-2: Механизм подстановки — stdlib (`str.replace`/`string.Template`) без новых зависимостей
+  (рекомендация) vs шаблонизатор (новая зависимость — потребует обоснования).
+- OQ-3: Copy-vs-template split: какие файлы kit — live-copy канона, какие — параметризуемые
+  шаблоны (минимум по BR-2: `_templates`/`_standards` — live-copy).
+- OQ-4: Скрипту импортировать `src.projects`/`src.plane_sync` (точные имена/парсер, нет
+  дублирования) vs автономный снапшот констант с тестом синхронизации.
+- OQ-5: Plane API CE: фактическая доступность создания проекта/статусов/лейблов — что уходит в
+  ручные шаги runbook.
+- OQ-6: Контур песочницы для smoke (staging 8501 vs одноразовый sandbox-проект) и судьба
+  sandbox-артефактов после прогона.
+- OQ-7: Языковая политика kit-промптов для не-self-hosting проектов (рекомендация: канон орка,
+  deployer — en).
+- OQ-8: Защита `main` нового репо в Gitea (branch protection): не должна ломать PR-merge API
+  конвейера — включать ли вообще (рекомендация: не включать, зафиксировать в runbook).

docs/work-items/ORCH-009/03-acceptance-criteria.md

@@ -0,0 +1,146 @@
+---
+work_item: ORCH-009
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-009 — Turnkey-онбординг проектов
+
+Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий — чёткое условие **PASS/FAIL**, проверяемое буквально по файлам
+репозитория и детерминированным тестам (без сети). AC-13 — единственный операторский
+(документированный smoke), его автоматизируемая часть вынесена в AC-2/AC-12.
+
+---
+
+## AC-1 — Kit полон (состав каркаса)
+**Условие:** инспекция `onboarding/repo-skeleton/` (или каталога, выбранного архитектором в ADR).
+- **PASS:** присутствуют все элементы FR-1: 6 шаблонов промптов (`analyst/architect/developer/
+  reviewer/tester/deployer`), `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`,
+  `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`,
+  `docs/operations/INFRA.md`, `docs/architecture/adr/`, `docs/work-items/`, `docs/history/`,
+  `.env.example`; материализация добавляет live-копии `docs/_templates/` + `docs/_standards/`.
+- **FAIL:** отсутствует любой элемент состава, либо промптов меньше 6.
+
+## AC-2 — Промпты kit соответствуют канону 52d/92
+**Условие:** структурные тесты по каждому из 6 шаблонов промптов.
+- **PASS:** в каждом — 5 обязательных XML-секций в нормативном порядке `<context>→<task>→
+  <deliverables>→<constraints>→<output_format>`; запреты в формате «❌ → ✅»; `<escalation>` у
+  developer/reviewer/tester; директивы «читай паспорт/AGENTS.md/доку ПЕРЕД работой» и «пиши
+  артефакты в `docs/work-items/<id>/`»; эмиссия 6-польной frontmatter-схемы 52c с
+  плейсхолдерными примерами дат/моделей; machine-verdict ключи у ролей-вердиктов байт-в-байт
+  (`verdict:` / `result:` / `staging_status:` / `deploy_status:` / `security_status:`).
+- **FAIL:** нарушен порядок/состав секций, отсутствует любой verdict-ключ или директива доки,
+  пример frontmatter содержит захардкоженные дату/модель.
+
+## AC-3 — Reviewer-gate на обновление доки
+**Условие:** шаблон `reviewer.md` в kit.
+- **PASS:** содержит явное правило: документация (CHANGELOG/релевантные доки/ADR) обновлена в том
+  же PR; нет → `verdict: REQUEST_CHANGES`.
+- **FAIL:** правило отсутствует или сформулировано как необязательное.
+
+## AC-4 — Языковая политика kit
+**Условие:** проверка языка шаблонов промптов против решения ADR (дефолт — канон орка).
+- **PASS:** языковая раскладка соответствует зафиксированной в ADR (по умолчанию: 5 ru +
+  deployer en, как ADR-001 D2 ORCH-092); отступление — только с обоснованием в ADR.
+- **FAIL:** язык промптов противоречит ADR, либо политика нигде не зафиксирована.
+
+## AC-5 — Материализация: плейсхолдеры и отсутствие утечек
+**Условие:** рендер kit с тестовыми параметрами (`PROJECT_NAME`, `REPO`, `WORK_ITEM_PREFIX` и т.д.).
+- **PASS:** все плейсхолдеры подставлены; в результате нет ни одного неразрешённого плейсхолдера
+  (grep по синтаксису из ADR); нет утечек орк-специфики, где должен быть параметр (литералы
+  `ORCH-` как префикс work-item чужого проекта, порты 8500/8501, self-hosting-правила орка);
+  пути, на которые ссылаются отрендеренные промпты/AGENTS.md, существуют в каркасе.
+- **FAIL:** найден неразрешённый плейсхолдер, орк-литерал вместо параметра или битая ссылка
+  на несуществующий путь.
+
+## AC-6 — Registry round-trip через фактический парсер
+**Условие:** скрипт генерирует запись реестра для тестового проекта.
+- **PASS:** сгенерированный JSON парсится `projects._parse_projects_json` без ошибок; полученный
+  `ProjectConfig` несёт исходные `plane_project_id`/`repo`/`work_item_prefix`/`name`; существующие
+  записи реестра не модифицируются и не теряются.
+- **FAIL:** парсер отвергает запись, поля искажены, либо генерация ломает/теряет существующие записи.
+
+## AC-7 — План Plane: точные статусы и лейблы
+**Условие:** `plan`-режим для нового проекта (моки сети).
+- **PASS:** план провижининга содержит ВСЕ канонические имена статусов из `_PLANE_NAME_TO_KEY`
+  (включая `Confirm Deploy` и `STOP` с группой `cancelled`) и лейблы `autoApprove`/`autoDeploy`/
+  `Bug`; имена байт-в-байт совпадают с константами `src/plane_sync.py` (или их синхронизированным
+  снапшотом по OQ-4); недоступные через API шаги помечены `manual-step` со ссылкой на runbook.
+- **FAIL:** пропущен/искажён любой статус или лейбл; недоступный шаг молча отброшен.
+
+## AC-8 — План Gitea: репо + per-repo webhook; dry-run без мутаций
+**Условие:** `plan`-режим (моки сети).
+- **PASS:** план содержит создание репо, создание webhook с events `push`/`pull_request`/`status`
+  и HMAC-secret (секрет — для `.env` оператора, не в гит), материализацию kit + initial push в
+  свежесозданный репо; в режиме `plan` не выполняется НИ ОДНОЙ мутации (ни одного
+  POST/PUT/DELETE-вызова в моках, ни одной записи на диск вне отчёта).
+- **FAIL:** план неполон, или dry-run произвёл мутацию.
+
+## AC-9 — Идемпотентность и безопасность apply
+**Условие:** повторный `apply` на частично/полностью созданном проекте (моки: сущности существуют).
+- **PASS:** существующие сущности (репо/webhook/статусы/лейблы/файлы) распознаны и пропущены с
+  пометкой `skipped(exists)`; ничего не удалено и не перезаписано без явного флага; скрипт не
+  выполняет рестарт/останов контейнеров, не правит `.env` прода, не пушит в существующие репо
+  (в коде отсутствуют такие операции — проверяемо тестом/ревью); итоговый отчёт перечисляет
+  created/skipped/manual-step.
+- **FAIL:** дублирование сущностей, любое удаление/перезапись без флага, любая операция
+  рестарта/push в существующий репо, отсутствие отчёта.
+
+## AC-10 — INFRA.md шаблон: обязательные секции
+**Условие:** инспекция шаблона `docs/operations/INFRA.md` в kit.
+- **PASS:** присутствуют секции: топология (контейнеры/порты прод+staging/сеть/тома/БД);
+  карта env-переменных + правило секретов (только `.env` на хосте, `.env.example` — канон);
+  границы доступа; предупреждения о рисках общего хоста. Существующий `docs/operations/INFRA.md`
+  орка (self-hosting-предупреждения) этой задачей не изменён.
+- **FAIL:** отсутствует любая обязательная секция, либо изменён INFRA.md самого орка.
+
+## AC-11 — Runbook ONBOARDING.md полон
+**Условие:** инспекция `docs/operations/ONBOARDING.md`.
+- **PASS:** покрывает все слои BR-1 в последовательности: предусловия (токены/доступы) → Plane
+  (проект/статусы/лейблы) → Gitea (репо/webhook) → kit (материализация/push) → регистрация
+  (env-строка + операторский управляемый рестарт с self-hosting-предупреждением) → верификация
+  (`verify` + smoke на песочнице) → откат; каждый ручной шаг помечен и снабжён командой проверки;
+  Plane workspace-webhook описан как существующий (проверка, не создание).
+- **FAIL:** пропущен слой, ручной шаг не помечен/без проверки, или runbook требует
+  автоматического рестарта прода.
+
+## AC-12 — Инварианты: src/** не тронут
+**Условие:** diff PR + снапшот-тест.
+- **PASS:** `git diff` PR не содержит изменений `src/**`; снапшот `STAGE_TRANSITIONS` и реестра
+  `QG_CHECKS` совпадает с эталоном; эталонные промпты `.openclaw/agents/*.md` орка не изменены;
+  полный регресс `tests/` зелёный.
+- **FAIL:** любой diff в `src/**` или `.openclaw/agents/`, расхождение снапшота, красный регресс.
+
+## AC-13 — Smoke: агент находит, использует и актуализирует доку (операторский)
+**Условие:** документированный прогон по runbook на песочнице (контур — по ADR): онбординг
+sandbox-проекта → тестовая задача → стадия analysis.
+- **PASS:** агент песочницы по своему промпту прочитал доку проекта (следы чтения паспорта/
+  AGENTS.md в выводе или артефактах) и записал артефакты в `docs/work-items/<id>/` по канону
+  (структура соответствует `PIPELINE_DOCS.md`); результат прогона зафиксирован в runbook/отчёте
+  задачи. Для приёмки данной задачи прогон выполняется один раз и протоколируется.
+- **FAIL:** агент не нашёл доку (артефакты вне канона/не созданы), либо прогон не запротоколирован.
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+
+| AC | BR | FR | Тип проверки |
+|----|----|----|--------------|
+| AC-1 | BR-5 | FR-1 | unit (структура kit) |
+| AC-2 | BR-3 | FR-2 | unit (структурный канон) |
+| AC-3 | BR-4 | FR-2 | unit |
+| AC-4 | BR-3 | FR-2 | unit + ADR |
+| AC-5 | BR-2/BR-5 | FR-1/FR-2 | unit (рендер) |
+| AC-6 | BR-8 | FR-4 | integration (реальный парсер) |
+| AC-7 | BR-7 | FR-4 | unit (план, моки) |
+| AC-8 | BR-1/BR-9 | FR-4 | unit (план, моки) |
+| AC-9 | BR-9/BR-11 | FR-4 | unit/integration (моки) |
+| AC-10 | BR-6 | FR-3 | unit (структура) |
+| AC-11 | BR-1/BR-8 | FR-6 | unit (структура дока) |
+| AC-12 | NFR-1 | — | unit (снапшот) + ревью diff |
+| AC-13 | BR-10 | FR-5 | ручной smoke (протоколируемый) |

docs/work-items/ORCH-009/04-test-plan.yaml

@@ -0,0 +1,164 @@
+work_item: ORCH-009
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "Turnkey-онбординг проектов: kit + скрипт + runbook (ORCH-009)"
+framework: pytest
+scope: >
+  Структурная полнота onboarding-kit, канон 52d/92 шаблонов промптов, материализация
+  (плейсхолдеры/утечки), registry round-trip через фактический парсер projects.py,
+  планы Plane/Gitea (dry-run, моки), идемпотентность apply, runbook, инварианты src/**.
+  Вне покрытия pytest: реальные вызовы Plane/Gitea API и операторский smoke на песочнице
+  (AC-13) — выполняется вручную по docs/operations/ONBOARDING.md и протоколируется.
+notes: >
+  Все тесты детерминированы, без сети (Plane/Gitea мокируются; NFR-5). Точные имена файлов
+  тест-модулей могут уточняться архитектором при сохранении покрытия TC↔AC. Полный регресс
+  tests/ должен оставаться зелёным (src/** не меняется — NFR-1). Если ADR изменит раскладку
+  kit (OQ-1) — пути в тестах следуют ADR, маппинг TC↔AC неизменен.
+
+tests:
+  # ---------- AC-1: состав kit ----------
+  - id: TC-01
+    type: unit
+    description: "Kit содержит все элементы FR-1: 6 шаблонов промптов, CLAUDE.md, AGENTS.md, CONTRIBUTING.md, README.md, CHANGELOG.md, docs/ARCHITECTURE.md, docs/PIPELINE.md, docs/PRODUCT_VISION.md, docs/operations/INFRA.md, docs/architecture/adr/, docs/work-items/, docs/history/, .env.example"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Материализация добавляет live-копии docs/_templates/ (16 канонических скелетов) и docs/_standards/ (3 стандарта) из живого канона репо орка; вторая редактируемая копия канона в kit отсутствует (BR-2)"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-2: канон промптов 52d/92 ----------
+  - id: TC-03
+    type: unit
+    description: "Каждый из 6 шаблонов промптов содержит 5 обязательных XML-секций в нормативном порядке context→task→deliverables→constraints→output_format"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Шаблоны developer/reviewer/tester содержат секцию <escalation>; запреты оформлены в формате '❌ → ✅'"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Каждый шаблон промпта направляет агента к доке: читай паспорт(CLAUDE.md)/AGENTS.md/ARCHITECTURE/ADR перед работой; пиши артефакты в docs/work-items/<id>/ по PIPELINE_DOCS; обновляй CHANGELOG/доку"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Шаблоны эмитят 6-польную frontmatter-схему 52c (work_item/stage/author_agent/status/created_at/model_used); machine-verdict ключи ролей байт-в-байт (verdict:/result:/staging_status:/deploy_status:/security_status:); примеры дат/моделей — плейсхолдеры, не литералы (анти-паттерн ORCH-092)"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  # ---------- AC-3: reviewer-gate ----------
+  - id: TC-07
+    type: unit
+    description: "Шаблон reviewer.md содержит обязательный gate: документация не обновлена в PR → verdict: REQUEST_CHANGES"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  # ---------- AC-4: языковая политика ----------
+  - id: TC-08
+    type: unit
+    description: "Языковая раскладка шаблонов соответствует политике ADR (дефолт: 5 ru + deployer en, канон ADR-001 D2 ORCH-092)"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  # ---------- AC-5: материализация ----------
+  - id: TC-09
+    type: unit
+    description: "Рендер kit с тестовыми параметрами подставляет все плейсхолдеры: в выходе нет ни одного неразрешённого плейсхолдера (grep по синтаксису из ADR)"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "В отрендеренном kit нет утечек орк-специфики, где должен быть параметр: префикс ORCH- вместо префикса проекта, порты 8500/8501, self-hosting-правила орка"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Ссылочная целостность: каждый путь, на который ссылаются отрендеренные промпты и AGENTS.md, существует в материализованном каркасе"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-6: registry round-trip ----------
+  - id: TC-12
+    type: integration
+    description: "Сгенерированная скриптом запись реестра парсится фактическим projects._parse_projects_json; ProjectConfig несёт исходные plane_project_id/repo/work_item_prefix/name; существующие записи реестра сохранены без искажений"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-7: план Plane ----------
+  - id: TC-13
+    type: unit
+    description: "plan-режим: план Plane содержит все канонические имена статусов _PLANE_NAME_TO_KEY (включая 'Confirm Deploy' и 'STOP' с группой cancelled) байт-в-байт и лейблы autoApprove/autoDeploy/Bug"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  - id: TC-14
+    type: unit
+    description: "Шаг Plane, недоступный через API (мок отвечает отказом/не реализовано), помечается в плане/отчёте как manual-step со ссылкой на runbook — не отбрасывается молча и не валит скрипт"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-8: план Gitea + dry-run ----------
+  - id: TC-15
+    type: unit
+    description: "plan-режим: план Gitea содержит создание репо, webhook (events push/pull_request/status + HMAC-secret вне гита) и initial push kit в свежесозданный репо"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  - id: TC-16
+    type: unit
+    description: "dry-run (plan) не выполняет ни одной мутации: ноль POST/PUT/DELETE в замоканных клиентах Plane/Gitea, ноль git push, ноль записей на диск вне отчёта"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-9: идемпотентность / безопасность apply ----------
+  - id: TC-17
+    type: integration
+    description: "Повторный apply на уже созданном проекте (моки: репо/webhook/статусы/лейблы существуют): сущности распознаны и помечены skipped(exists); нет дублей, удалений и перезаписи без явного флага; итоговый отчёт перечисляет created/skipped/manual-step"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  - id: TC-18
+    type: unit
+    description: "Скрипт не содержит операций рестарта/останова контейнеров, правки прод-.env и push в существующие репо: на моках полного прогона apply такие вызовы отсутствуют (NFR-2)"
+    module: tests/test_onboarding_script.py
+    expected: PASS
+
+  # ---------- AC-10: INFRA.md шаблон ----------
+  - id: TC-19
+    type: unit
+    description: "Шаблон INFRA.md kit содержит обязательные секции: топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env + правило секретов (.env на хосте, .env.example — канон), границы доступа, риски общего хоста"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  # ---------- AC-11: runbook ----------
+  - id: TC-20
+    type: unit
+    description: "ONBOARDING.md покрывает все слои в последовательности: предусловия → Plane → Gitea → kit → регистрация (env + операторский управляемый рестарт с self-hosting-предупреждением) → верификация (verify + smoke) → откат; ручные шаги помечены и снабжены командами проверки"
+    module: tests/test_onboarding_kit.py
+    expected: PASS
+
+  # ---------- AC-12: инварианты ----------
+  - id: TC-21
+    type: unit
+    description: "Снапшот STAGE_TRANSITIONS и реестра QG_CHECKS совпадает с эталоном (src/** не затронут логикой онбординга); эталонные промпты .openclaw/agents/ орка не изменены задачей"
+    module: tests/test_onboarding_invariants.py
+    expected: PASS
+
+  - id: TC-22
+    type: integration
+    description: "Полный регресс существующего tests/ остаётся зелёным после добавления onboarding-артефактов (никакой новый импорт/код не ломает конвейер)"
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md

@@ -0,0 +1,341 @@
+---
+work_item: ORCH-009
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Turnkey-онбординг проектов — kit `onboarding/` + операторский CLI + runbook
+
+Work Item: **ORCH-009** — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
+Стадия: **architecture**
+Связь: BRD `01-brd.md`, ТЗ `02-trz.md`, AC `03-acceptance-criteria.md`, тест-план `04-test-plan.yaml`,
+инфра `07-infra-requirements.md`, риски `10-tech-risks.md`.
+Сквозная регистрация: **`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`**
+(решение кросс-каттинговое: новая способность уровня всего оркестратора — масштабирование на
+новые проекты, домен D5.2 эпика саморазвития).
+
+## Статус
+Proposed
+
+---
+
+## Контекст
+
+Онбординг нового проекта сегодня — ручная археология по `SETUP_WEBHOOKS.md`/`INFRA.md`/памяти;
+любой пропуск даёт тихую деградацию (BRD §1.2): без промптов в репо конвейер проекта не работает
+вовсе (Ф-1: launcher резолвит `.openclaw/agents/<role>.md` **относительно worktree репо задачи**);
+без точных имён статусов ветки `Confirm Deploy`/`STOP` молча не активируются (fail-closed,
+`src/plane_sync.py:130-165`); без лейблов авто-режимы/багфикс-трек молча выключены (fail-safe,
+`src/labels.py`/`src/bug_fast_track.py`).
+
+Ограничения, заданные анализом и проверенные по коду:
+
+- **NFR-1:** `src/**` не меняется; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict
+  ключи/схема БД/контракт `projects.py` — байт-в-байт. Задача docs/templates/scripts/tests-only.
+- **Ф-2:** агент видит только worktree своего репо → каноны обязаны быть **скопированы** в новый
+  репо (ссылка на репо орка агенту недоступна).
+- **Ф-3:** реестр строится при импорте из `ORCH_PROJECTS_JSON` (`src/projects.py::_load_projects`);
+  регистрация = правка `.env` + **операторский** управляемый рестарт.
+- **Ф-6:** Plane-webhook — workspace-level, уже существует (в CE создаётся SQL-ом, внешнего API
+  нет); Gitea-webhook — per-repo, через API (`push`/`pull_request`/`status`, HMAC).
+- **Ф-7:** живой канон — `docs/_templates/` (16 скелетов), `docs/_standards/` (3 стандарта),
+  `.openclaw/agents/*.md` (канон 52d/92).
+- Эталон онбординга = **сам репозиторий orchestrator** (актуализация Владельца 10.06);
+  enduro-trails эталоном не является.
+
+ТЗ оставило архитектору 8 открытых вопросов (OQ-1…OQ-8) — все закрываются ниже (D1…D11).
+
+---
+
+## Решение
+
+### Сводка
+
+Три артефакта + тесты, всё **вне конвейера и вне рантайма**:
+
+1. **Onboarding-kit** `onboarding/repo-skeleton/` — параметризуемый каркас нового репо
+   (6 промптов канона 52d/92, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, скелет `docs/`
+   с обязательным `operations/INFRA.md`); словарь плейсхолдеров — `onboarding/placeholders.json`.
+2. **Операторский CLI** `scripts/onboard_project.py` — `plan` (дефолт, GET-only) / `apply`
+   (идемпотентный ensure) / `verify`; Plane (проект+статусы+лейблы) → Gitea (репо+webhook) →
+   материализация kit (рендер + live-copy канона) + initial push → генерация записи реестра →
+   отчёт `created/skipped(exists)/manual-step`.
+3. **Runbook** `docs/operations/ONBOARDING.md` — полный чеклист, явные ручные шаги
+   (env + управляемый рестарт; UI-only Plane), верификация (verify + smoke на staging), откат.
+
+Никакого нового кода в горячих путях; kill-switch не нужен (способность активируется только
+явным запуском CLI человеком — TRZ §7).
+
+### D1 — Раскладка: top-level `onboarding/` (OQ-1)
+
+**Решение: `onboarding/` в корне репо** — ровно как предложено ТЗ:
+
+```
+onboarding/
+  README.md            ← устройство kit: словарь плейсхолдеров, правило «канон не форкается»,
+                          copy-vs-template карта (D3), как запускать тесты kit
+  placeholders.json    ← словарь плейсхолдеров (single source of truth, D2)
+  repo-skeleton/       ← дерево зеркалит целевой репо (FR-1)
+    .openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md
+    CLAUDE.md  AGENTS.md  CONTRIBUTING.md  README.md  CHANGELOG.md  .env.example
+    docs/ARCHITECTURE.md  docs/PIPELINE.md  docs/PRODUCT_VISION.md
+    docs/operations/INFRA.md
+    docs/architecture/adr/README.md      ← стаб реестра сквозных ADR (дир непустая, самоописуема)
+    docs/work-items/.gitkeep  docs/history/.gitkeep
+```
+
+Отвергнуто:
+- **`docs/_onboarding/`** — смешивает kit (продукт-артефакт, исходник для ЧУЖИХ репо) с
+  документацией самого орка; шаблоны промптов под `docs/` рядом с живыми `docs/_templates/`
+  провоцируют путаницу «какая копия живая» (прямо риск R-1/R-5 BRD) и ложные срабатывания
+  doc-тулинга.
+- **`scripts/onboarding/`** — смешивает данные (дерево skeleton) с исполняемым кодом; `scripts/`
+  в этом репо — плоские утилиты (`staging_check.py`, deploy-hook).
+
+Top-level каталог делает границу физической: **всё под `onboarding/` предназначено новому репо,
+ничто под `onboarding/` не исполняется рантаймом орка.** Структурные тесты канона гоняются по
+`onboarding/repo-skeleton/.openclaw/agents/*.md` отдельно от живых промптов орка (TC-03…08 ↔
+существующий `tests/test_agent_prompts_canon.py` не пересекаются).
+
+### D2 — Механизм подстановки: `{{NAME}}` + stdlib, без новых зависимостей (OQ-2)
+
+**Решение: синтаксис `{{PLACEHOLDER_NAME}}`** (верхний регистр, `[A-Z][A-Z0-9_]*`), подстановка —
+простой проход `str.replace` по словарю; после рендера — обязательный скан
+`re.compile(r"\{\{[A-Z][A-Z0-9_]*\}\}")` на неразрешённые плейсхолдеры (ошибка в apply/verify,
+PASS-условие AC-5/TC-09).
+
+- **`string.Template` отвергнут:** kit-шаблоны (INFRA.md, `.env.example`, промпты) содержат
+  shell-сниппеты с `$VAR`/`${VAR}` — синтаксис `$` коллидирует и потребовал бы экранирования по
+  всему kit (хрупко, нечитабельно).
+- **Jinja2 отвергнут:** новая pip-зависимость (ТЗ §9 запрещает без обоснования) + условная логика
+  в шаблонах = второй язык программирования в kit → выше риск дрейфа. Kit обязан быть тупым.
+- Синтаксис `{{…}}` визуально различим, greppable; в Markdown/YAML kit-файлов естественно не
+  встречается, остаточные случаи ловит скан.
+
+**Словарь — `onboarding/placeholders.json`** (машиночитаемый single source of truth; формат:
+`{ "NAME": {"description": …, "required": bool, "default": …|null, "example": …} }`):
+
+| Плейсхолдер | Смысл | Обяз. |
+|---|---|---|
+| `{{PROJECT_NAME}}` | человекочитаемое имя проекта | да |
+| `{{PROJECT_DESCRIPTION}}` | 1–2 фразы «зачем проект» (README/PRODUCT_VISION) | да |
+| `{{REPO}}` | имя Gitea-репо (== каталог под `/repos`) | да |
+| `{{GITEA_OWNER}}` | owner/org репо в Gitea | да |
+| `{{WORK_ITEM_PREFIX}}` | префикс work-item (`ET`/`ORCH`-аналог) | да |
+| `{{PLANE_PROJECT_ID}}` | uuid Plane-проекта (известен после Plane-шага apply) | да |
+| `{{STACK}}` | стек проекта (описательно) | да |
+| `{{TEST_CMD}}` | команда тестов (напр. `pytest -q`) | да |
+| `{{PROD_PORT}}` / `{{STAGING_PORT}}` | порты прод/staging | да |
+
+Расширение словаря = правка `placeholders.json` + kit + тестов в одном PR. Тесты держат
+**биекцию**: каждый плейсхолдер, встречающийся в kit, объявлен в словаре, и каждый объявленный —
+используется (нет мёртвых/опечаточных).
+
+### D3 — Copy-vs-template split (OQ-3, BR-2)
+
+| Класс | Файлы | Механизм |
+|---|---|---|
+| **Live-copy канона** (НЕ хранится в kit) | `docs/_templates/**` (16), `docs/_standards/**` (3) | копируются скриптом **verbatim из рабочего чекаута репо орка в момент материализации** |
+| **Параметризуемые шаблоны** (хранятся в kit) | 6 промптов, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`, `docs/operations/INFRA.md`, `docs/architecture/adr/README.md`, `.env.example` | рендер `{{…}}` (D2) |
+| **Скелет-каркас** | `docs/work-items/.gitkeep`, `docs/history/.gitkeep` | копия как есть |
+
+- Канон копируется **байт-в-байт, без переписывания**: ORCH-примеры внутри стандартов
+  (`PIPELINE_DOCS.md` цитирует ORCH-088 и т.п.) остаются примерами — это не «утечка», а
+  иллюстрация (утечкой считается орк-литерал там, где должен быть параметр — AC-5/TC-10:
+  префикс work-item, порты 8500/8501, self-hosting-правила в паспорте/промптах).
+- Повторный `apply` существующие файлы в целевом репо **не перезаписывает** (идемпотентность
+  BR-9): обновление канона в уже-онбордженных репо едет их обычными PR с reviewer-gate;
+  новые онбординги автоматически получают свежий канон (live-copy, ТЗ §7).
+- Источник live-copy — чекаут, из которого запущен скрипт; скрипт проверяет наличие обоих
+  каталогов и (в verify) количество скелетов ≥ 16 / стандартов ≥ 3.
+
+### D4 — Скрипту разрешён read-only импорт `src` — закрытый список (OQ-4)
+
+**Решение: импортировать, не снапшотить.** Закрытый список импортов:
+
+| Импорт | Зачем |
+|---|---|
+| `src.projects._parse_projects_json`, `src.projects.ProjectConfig` | round-trip валидация генерируемой записи реестра фактическим парсером (AC-6/TC-12) |
+| `src.plane_sync._PLANE_NAME_TO_KEY` | точные канонические имена 22 статусов байт-в-байт (AC-7/TC-13) |
+| `src.config.settings` (read-only поля) | имена лейблов `auto_approve_label`/`auto_deploy_label`/`bug_fast_track_label` (дефолты `autoApprove`/`autoDeploy`/`Bug`), URL/токены Plane/Gitea из env |
+
+- **Почему не снапшот:** дублирование констант = гарантированный дрейф (R-2); AC-6 и так требует
+  фактический парсер; снапшот потребовал бы отдельного «теста синхронизации», который и есть
+  признание дрейфа. Импорт даёт нулевой дрейф **по построению**.
+- Импорт безопасен: `src.projects` → `src.config` (pydantic-settings с дефолтами, инстанцируется
+  без env); `src.plane_sync` module-level считает только строки из settings; `httpx` — уже
+  зависимость проекта (`requirements.txt`), **новых pip-зависимостей нет**.
+- Импорт приватных имён (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`) — сознательная,
+  санкционированная ТЗ связь (ТЗ §2 разрешает явно). **Список закрыт:** любой новый импорт из
+  `src` — только через обновление этого ADR. Контроль ненарушения `src` — снапшот-тест TC-21
+  (`STAGE_TRANSITIONS`/`QG_CHECKS`) + AC-12 (diff).
+- Скрипт запускается из корня чекаута орка (runbook-предусловие); `sys.path`-шим в начале файла
+  (паттерн `scripts/staging_check.py`).
+
+### D5 — Plane-провижининг: канонические статусы + группы + fail-safe (OQ-5, BR-7)
+
+**Ensure-семантика:** `GET states` → создать недостающие по точным именам (ключи
+`_PLANE_NAME_TO_KEY`, 22 имени); существующие (включая CE-дефолтные Backlog/Todo/In Progress/
+Done/Cancelled нового проекта) — `skipped(exists)` по совпадению имени. Аналогично лейблы:
+`autoApprove`/`autoDeploy`/`Bug` (имена — из `settings`, D4).
+
+**Канонические группы статусов** (Plane: `backlog|unstarted|started|completed|cancelled`) —
+фиксируются этим ADR; код-критичные констрейнты выделены:
+
+| Статус | Группа | Констрейнт |
+|---|---|---|
+| Backlog | `backlog` | |
+| Todo, To Analyse | `unstarted` | |
+| In Progress, Analysis, Architecture, Development, Code-Review, Review, Testing, Awaiting Deploy, Deploying, Monitoring after Deploy, Needs Input, In Review, Blocked, Approved, Confirm Deploy | `started` | **рабочие/гейтовые статусы НЕ в терминальных группах** — иначе terminal-detection ORCH-068 (`{uuid→group}`, группы `completed`/`cancelled` = терминал) ложно сочтёт живую задачу терминальной |
+| Rejected | `started` | reject = rework-петля в анализ, задача жива → НЕ `cancelled` |
+| Done | `completed` | терминал |
+| Cancelled | `cancelled` | терминал |
+| **STOP** | **`cancelled`** | **требование ORCH-090** (fail-closed: без статуса/группы ветка cancel не активируется) |
+
+**Fail-safe (CE-пробелы):** код орка использует только GET states — доступность POST
+project/states/labels в Plane CE не гарантирована. Любой недоступный вызов (403/404/405/501/
+нереализовано) → шаг помечается **`manual-step`** со ссылкой на соответствующий раздел runbook
+(точное имя статуса + группа для ручного создания в UI), скрипт не падает (AC-7/TC-14).
+Заведомо ручные шаги: порядок статусов на доске (drag-and-drop, UI-only), workspace-webhook
+(существует, Ф-6 — verify печатает команду проверки, не создаёт).
+
+### D6 — Gitea-провижининг: репо + webhook + initial push только в пустой репо (BR-9)
+
+- **Репо:** `POST /api/v1/...` под `{{GITEA_OWNER}}`, `auto_init=false` (репо рождается пустым;
+  `main` создаёт initial push). Существует → `skipped(exists)`.
+- **Webhook (per-repo):** events `push`/`pull_request`/`status`, `content_type: json`,
+  `branch_filter: "*"`, URL = внешний URL орка `/webhook/gitea` (формат `SETUP_WEBHOOKS.md`).
+  **Секрет: приёмник `src/webhooks/gitea.py` валидирует ОДИН глобальный
+  `ORCH_GITEA_WEBHOOK_SECRET` на все репо** → скрипт **переиспользует** существующий секрет из
+  env (никогда не генерит новый при наличии — новый сломал бы HMAC всех вебхуков); секрет
+  отсутствует в env → сгенерить `secrets.token_hex(20)` + вывести оператору для `.env`
+  (первичная настройка). В логах/отчёте секрет всегда маскируется (NFR-3).
+- **Initial push:** материализованный kit коммитится (`feat: onboarding skeleton (ORCH-009 kit)`)
+  и пушится в `main` **только если репо свежесоздан/пуст** (Gitea `empty: true`); непустой репо →
+  `manual-step` (kit-файлы НИКОГДА не пушатся поверх существующего контента). Это единственный
+  разрешённый push: новый пустой репо до регистрации в реестре не является участником конвейера →
+  **INV-4 (мерж только через PR-merge API) не затрагивается** (ТЗ §9).
+
+### D7 — Запись реестра: полный merged-массив, скрипт `.env` не трогает (BR-8)
+
+**Решение: скрипт выводит (а) standalone-запись нового проекта и (б) полный merged-массив
+`ORCH_PROJECTS_JSON`** = существующие записи verbatim + новая в конец. Источник существующих:
+текущий env / `--env-file` (дефолт — `.env` в корне чекаута, если есть); источника нет → только
+standalone-запись + инструкция. Перед выводом merged-массив прогоняется через
+`projects._parse_projects_json` (round-trip: поля новой записи совпадают, существующие не
+потеряны/не искажены — AC-6/TC-12).
+
+- **Почему full-array, а не диф:** оператор вставляет одну строку в `.env` атомарно — ручное
+  слияние JSON в env-строке (экранирование, запятые) и есть источник ошибок R-4.
+- Скрипт **не правит** `.env` прода и **не рестартит** контейнер (NFR-2): печатает строку +
+  инструкцию «добавь в `.env` → управляемый рестарт оркестратора (self-hosting: групповое окно,
+  выполнять осознанно)» со ссылкой на runbook. `verify` после рестарта показывает разрыв
+  «создано, но не зарегистрировано» (R-4).
+
+### D8 — Песочница для smoke: staging-контур 8501 + одноразовый SMK-проект (OQ-6, AC-13)
+
+**Решение: smoke выполняется на staging-контуре** (`orchestrator-staging`, 8501, изолированная БД
+`./data/staging`) с **одноразовым** sandbox: Plane-проект `onboarding-smoke` (префикс `SMK`) +
+Gitea-репо `onboarding-smoke`, онбордженные самим скриптом. Регистрация — в `ORCH_PROJECTS_JSON`
+**staging-окружения** (`.env.staging`) + рестарт staging (свободен, в отличие от прод-инварианта).
+Прогон: тестовая задача SMK → стадия `analysis` → проверить следы чтения паспорта/`AGENTS.md` и
+артефакты `docs/work-items/SMK-…/` по канону `PIPELINE_DOCS.md`.
+
+- **Прод-контур отвергнут:** smoke-задача писала бы конвейерные строки в общую прод-БД и жила бы
+  в общей очереди с enduro/ORCH — шум и риск в общем инстансе (дух NFR-2).
+- Протокол прогона — раздел **«Журнал smoke-прогонов»** в `ONBOARDING.md` (дата, параметры,
+  PASS/FAIL по чек-листу AC-13); для приёмки ORCH-009 первый протокол обязателен, ссылка на него —
+  из `13-test-report.md` задачи. Судьба sandbox-артефактов: архив/удаление вручную по разделу
+  «Откат» runbook (скрипт не удаляет ничего — BR-9).
+
+### D9 — Языковая политика kit-промптов: канон орка (OQ-7, AC-4)
+
+**Решение: 5 ru + deployer en** — ровно языковая раскладка канона орка, нормативная по
+ADR-001 D2 ORCH-092 (deployer — самый safety-critical промпт, en-раскладка минимизирует
+регресс-поверхность байт-точных verdict-ключей/команд). Kit наследует канон без отступлений;
+per-project отступление возможно позже **только** решением в собственном ADR нового проекта
+(правило фиксируется в `onboarding/README.md` и шаблоне `CONTRIBUTING.md`). Проверяется TC-08.
+
+### D10 — Branch protection `main` нового репо: НЕ включать (OQ-8)
+
+**Решение: не включать.** Merge-актор конвейера — Gitea PR-merge API под токеном орка
+(INV-4; `src/merge_gate.py`, ORCH-093): required-approvals/required-status-checks дали бы
+405/409-класс отказов `merge_pr` → ложные HOLD (ровно класс инцидента ORCH-063). Сам орк живёт
+без protection — защита `main` держится конвенцией (агенты не пушат `main`; мерж только через
+PR API) и скоупом токенов. Решение фиксируется в runbook; пересмотр — при мультитенант-hardening
+(D5.6, вне объёма).
+
+### D11 — Форма CLI и тестируемость без сети (BR-11, NFR-5)
+
+**Один файл `scripts/onboard_project.py`** (операторская UX: один очевидный энтрипойнт; паттерн
+`scripts/staging_check.py`), внутри — слои:
+
+- **Чистое ядро:** `build_plan(params, observed) -> Plan` — без I/O; `Plan` = упорядоченный список
+  шагов закрытого списка BR-1: `plane.project → plane.states(22) → plane.labels(3) → gitea.repo →
+  gitea.webhook → kit.materialize+push → registry.emit`. Рендер kit — чистая функция
+  `render(text, params)` (D2), в plan-режиме выполняется **in-memory** (ни одной записи на диск —
+  AC-8/TC-16); материализация на диск (temp-dir → git init/commit/push) — только в `apply`.
+- **Тонкие клиенты** `PlaneClient`/`GiteaClient` (httpx; единственные точки сети) — инжектируются
+  → в тестах мокаются целиком (NFR-5: ноль сетевых вызовов, TC-13…18).
+- **Режимы:** `plan` (дефолт) — только GET-пробы текущего состояния + полный план без единой
+  мутации; `apply` — ensure-исполнение (идемпотентно, без delete-операций вовсе); `verify` —
+  GET-пробы + локальные проверки (registry round-trip, резолв всех логических ключей включая
+  `confirm_deploy`/`stop`, лейблы, webhook активен, kit-файлы в репо, скан неразрешённых
+  плейсхолдеров).
+- **Отчёт:** человекочитаемый + `--json`; статус каждого шага
+  `created | skipped(exists) | manual-step | planned | error`; exit-коды: `0` — чисто, `2` — есть
+  `manual-step`/gap в verify, `1` — ошибка. Каждый шаг логируется (BR-11).
+
+---
+
+## Альтернативы (сводно)
+
+- **`docs/_onboarding/` / `scripts/onboarding/`** — отвергнуто (D1): смешение kit с живой докой
+  орка / данных с кодом.
+- **Jinja2 / `string.Template`** — отвергнуто (D2): новая зависимость и логика в шаблонах /
+  коллизия `$` с shell-сниппетами.
+- **Снапшот констант `src` + тест синхронизации** — отвергнуто (D4): узаконенный дрейф; импорт
+  даёт нулевой дрейф по построению.
+- **Генерация нового webhook-секрета per-repo** — отвергнуто (D6): приёмник валидирует один
+  глобальный секрет; новый сломал бы HMAC существующих вебхуков.
+- **Диф-вывод реестра** — отвергнуто (D7): ручное слияние JSON-в-env — источник ошибок R-4.
+- **Smoke на прод-контуре** — отвергнуто (D8): запись в общую прод-БД/очередь.
+- **Branch protection `main`** — отвергнуто (D10): ломает PR-merge API актора (ложные HOLD).
+
+## Последствия
+
+- **+** Turnkey-способность D5.2: один проход + runbook вместо археологии; тихие деградации
+  (статусы/лейблы/промпты) закрываются проверяемо (`verify` + структурные тесты).
+- **+** Нулевой риск рантайма: `src/**` байт-в-байт, нового кода в горячих путях нет, kill-switch
+  не нужен; регресс enduro/orchestrator невозможен по построению.
+- **+** Анти-дрейф структурный: live-copy канона (BR-2) + единые канон-тесты kit (NFR-4) +
+  биекция словаря плейсхолдеров.
+- **−** Операторские шаги остаются ручными (env + управляемый рестарт; UI-only Plane): осознанное
+  ограничение NFR-2 (никакой автоматики рестартов) — митигировано runbook + verify (видимый разрыв).
+- **−** Импорт приватных имён `src` связывает скрипт с внутренними идентификаторами — митигировано
+  закрытым списком (D4) и тем, что рефакторинг имён мгновенно валит импорт в тестах (видимая,
+  не тихая поломка).
+- **−** Kit-шаблоны промптов требуют сопровождения при эволюции канона — митигировано общими
+  структурными требованиями тестов (расхождение ловит CI, NFR-4).
+- **Откат:** удалить `onboarding/`, `scripts/onboard_project.py`, `docs/operations/ONBOARDING.md`,
+  тесты — репо в исходном состоянии (ТЗ §7); внешние сущности (sandbox/созданные проекты) —
+  вручную по разделу «Откат» runbook.
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-009/01-brd.md` · TRZ: `02-trz.md` · AC: `03-acceptance-criteria.md`
+  · Test plan: `04-test-plan.yaml`
+- Сверено по коду: `src/projects.py` (`ProjectConfig`, `_parse_projects_json`, `_load_projects`),
+  `src/plane_sync.py:94-165` (`_DEFAULT_STATES`, `_PLANE_NAME_TO_KEY` — 22 имени, fail-closed
+  `Confirm Deploy`/`STOP`), `src/qg/checks.py::check_architecture_done`, `src/config.py`
+  (`auto_*_label`/`bug_fast_track_label`), `requirements.txt` (httpx уже есть)
+- Операции: `docs/operations/SETUP_WEBHOOKS.md` (формат Gitea-webhook; Plane workspace-webhook —
+  SQL-only), `docs/operations/INFRA.md`
+- Стандарты: `docs/_standards/PIPELINE_DOCS.md` (§4 ADR-naming), `HANDOFF_PROTOCOL.md`,
+  `TRACEABILITY.md`
+- ADR: adr-0001 (registry), adr-0017/0018 (паттерны условности), adr-0021/0022 (канон промптов/
+  трассировка), adr-0026 (STOP, группа `cancelled`), ORCH-092 `ADR-001` D2 (язык deployer),
+  сквозной **adr-0035-turnkey-project-onboarding**

docs/work-items/ORCH-009/07-infra-requirements.md

@@ -0,0 +1,66 @@
+---
+work_item: ORCH-009
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-009 — Turnkey-онбординг проектов
+
+Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
+
+> Топология оркестратора **не меняется** (NFR-1/NFR-2: `src/**` и compose не трогаются).
+> Файл фиксирует **предусловия исполнения способности** (токены/доступы/контуры) и инфра-границы
+> операторского скрипта. Детали решений — `06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`.
+
+## I-1. Топология / окружения
+
+- **Прод (`orchestrator`, 8500):** не затрагивается. Скрипт не создаёт/не останавливает/не
+  рестартит контейнеры; в общую БД не пишет (читает только файлы чекаута и внешние API).
+- **Staging (`orchestrator-staging`, 8501, БД `./data/staging`):** контур smoke-прогона (ADR D8).
+  Регистрация sandbox-проекта — в `.env.staging`; рестарт staging — штатный, свободный
+  (прод-инвариант на него не распространяется).
+- **Новые внешние сущности** (создаются скриптом в `apply`): Plane-проект, Gitea-репо +
+  per-repo webhook. Аддитивно: существующие проекты/репо не модифицируются (BR-9).
+- **Запуск скрипта:** хост mva154, из корня чекаута репо orchestrator. Среда исполнения —
+  venv с `requirements.txt` (httpx уже в зависимостях; новых pip-зависимостей нет) **или**
+  `docker compose exec orchestrator python scripts/onboard_project.py …` (read-only к рантайму,
+  без рестартов). Канонический способ фиксирует runbook `docs/operations/ONBOARDING.md`.
+
+## I-2. Переменные окружения / секреты
+
+**Новых env-переменных не вводится.** Используются существующие (предусловия запуска):
+
+| Переменная | Роль в онбординге |
+|---|---|
+| `ORCH_PLANE_API_TOKEN` (+ `ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение Plane-проекта, статусов, лейблов; токен с правом создания проектов в workspace |
+| `ORCH_GITEA_TOKEN` (+ Gitea base URL) | создание репо (под `{{GITEA_OWNER}}`), per-repo webhook; токен с правом create-repo + hooks |
+| `ORCH_GITEA_WEBHOOK_SECRET` | **переиспользуется** для webhook нового репо (приёмник валидирует один глобальный секрет, ADR D6); отсутствует → скрипт генерит и печатает оператору для `.env` |
+| `ORCH_PROJECTS_JSON` | источник существующих записей для merged-вывода (ADR D7); **применение новой строки — операторский шаг** |
+
+- Секреты — только в `.env`/`.env.staging` на хосте, в гит не попадают (правило #8 CLAUDE.md);
+  в логах/отчётах скрипта секреты маскируются (NFR-3).
+- Kit несёт собственный `.env.example` нового проекта (дескрипторы без значений) — канон секретов
+  транслируется в онбордируемые репо.
+
+## I-3. Деплой / рестарт
+
+- **Скрипт НИКОГДА не рестартит/не останавливает прод-контейнер** (NFR-2, self-hosting инвариант).
+- Регистрация проекта в реестре (Ф-3): правка `.env` (строка `ORCH_PROJECTS_JSON` из отчёта
+  скрипта) + **управляемый операторский рестарт** оркестратора — групповое окно для ВСЕХ проектов
+  общего инстанса; runbook помечает шаг self-hosting-предупреждением и командой проверки
+  (`GET /queue`, резолв статусов нового проекта).
+- TTL-self-heal статусов Plane (ORCH-068, 300с) рестарта не требует: статусы/лейблы, созданные
+  после регистрации, подхватываются без вмешательства.
+- Деплой самой задачи ORCH-009 — штатный конвейер: изменение docs/scripts/tests-only, образ
+  пересобирается стандартно, staging-гейт (8501) обязателен как обычно.
+
+## I-4. CI/CD
+
+- `.gitea/workflows/` — **без изменений**: новые тесты (`tests/test_onboarding_kit.py`,
+  `test_onboarding_script.py`, `test_onboarding_invariants.py`) подхватываются существующим
+  pytest-шагом; все детерминированы, без сети (NFR-5).
+- Инфра-предусловий в образе нет: скрипт — операторский CLI вне рантайма, в образ ничего
+  дополнительно не запекается.

docs/work-items/ORCH-009/10-tech-risks.md

@@ -0,0 +1,42 @@
+---
+work_item: ORCH-009
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-009 — Turnkey-онбординг проектов
+
+Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Детализирует риски BRD §8 (R-1…R-5) до уровня решений
+> `06-adr/ADR-001`; митигейшены привязаны к D-решениям и TC тест-плана.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Drift канона** (R-1): копия `_templates`/`_standards` в новых репо разъезжается с живым каноном орка; kit-промпты отстают от эволюции канона 52d | Сред. | Сред. | BR-2/D3: live-copy в момент онбординга, второй редактируемой копии канона нет; NFR-4: структурные канон-тесты kit (TC-03…08) ловят расхождение в CI; обновление онбордженных репо — их обычные PR |
+| TR-2 | **Тихая деградация Plane-контрактов** (R-2): опечатка в имени статуса/лейбла или неверная **группа** → fail-closed/fail-safe ветки (`Confirm Deploy`, `STOP`, авто-лейблы, `Bug`) молча не работают; рабочий статус в группе `completed`/`cancelled` → terminal-detection ORCH-068 ложно терминалит живую задачу | Сред. | Выс. | D4: имена импортируются из `_PLANE_NAME_TO_KEY` (нулевой дрейф по построению, TC-13); D5: канонические группы зафиксированы таблицей ADR с код-критичными констрейнтами (STOP→`cancelled`, терминальные группы только Done/Cancelled/STOP); `verify` резолвит ВСЕ логические ключи включая `confirm_deploy`/`stop` |
+| TR-3 | **Скрипт с боевыми токенами** (R-3): ошибка = разрушительное действие на общих Plane/Gitea | Низ. | Выс. | BR-9/D11: `plan` (GET-only) — дефолт; delete-операций в коде нет вовсе (TC-18); аддитивный ensure (TC-17); push только в свежесозданный пустой репо (`empty: true`, D6); существующие сущности не модифицируются |
+| TR-4 | **Разрыв «создано, но не зарегистрировано»** (R-4): оператор не применил env+рестарт → проект невидим для орка | Сред. | Сред. | D7: merged-массив одной строкой (без ручного слияния JSON); runbook: явный операторский шаг с self-hosting-предупреждением + команда проверки; `verify` показывает разрыв (TC-12, AC-11) |
+| TR-5 | **Утечка орк-специфики в kit** (R-5): новый репо получает ORCH-префикс, порты 8500/8501, self-hosting-правила орка | Сред. | Сред. | D2: скан неразрешённых плейсхолдеров после рендера; TC-10: явный тест на утечки; биекция словаря `placeholders.json` ↔ kit (мёртвые/опечаточные плейсхолдеры не живут) |
+| TR-6 | **Поломка HMAC существующих вебхуков**: генерация нового per-repo секрета при едином глобальном `ORCH_GITEA_WEBHOOK_SECRET` приёмника | Низ. | Выс. | D6: секрет **переиспользуется** из env (новый генерится только при полном отсутствии — первичная настройка); секрет маскируется в логах/отчёте (NFR-3) |
+| TR-7 | **Связь скрипта с приватными именами `src`** (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`): рефакторинг src валит скрипт | Низ. | Низ. | D4: закрытый список импортов (расширение — только через ADR); поломка видимая, не тихая — импорт падает в тестах (TC-12/13) на том же PR, что рефакторит src; снапшот TC-21 гардит сам src |
+| TR-8 | **Plane CE API-пробелы** (OQ-5): POST project/states/labels недоступен в CE → провижининг неполон | Сред. | Низ. | D5: fail-safe деградация в `manual-step` со ссылкой на runbook (имя+группа для UI-создания), не падение (TC-14); `verify` подтверждает итоговую полноту независимо от способа создания |
+| TR-9 | **Smoke загрязняет общий контур**: прогон способности в проде = строки в общей БД/очереди | Низ. | Сред. | D8: smoke только на staging (8501, изолированная БД, `.env.staging`); sandbox-сущности одноразовые, снос вручную по разделу «Откат» runbook |
+
+## Сводный вывод
+
+Доминирующий класс — **операционные риски исполнения способности** (TR-2/TR-3/TR-4): они
+митигированы структурно (импорт констант вместо копий, GET-only дефолт, отсутствие delete-операций,
+verify-режим), а не дисциплиной. Рисков для прод-конвейера самой задачи **нет по построению**:
+`src/**` байт-в-байт (AC-12/TC-21), нового кода в горячих путях нет, kill-switch не требуется —
+способность активируется только явным запуском операторского CLI.
+
+Эскалация `arch:major-change` **не требуется**: ни новой стадии, ни нового рантайм-компонента,
+ни изменения БД — это docs/templates/scripts/tests-only способность (новая стадия/компонент
+конвейера не вводится). Возврат в анализ не требуется: ТЗ выполнимо без нарушения принципов.
+Остаточный риск для прод-конвейера (self-hosting): **низкий**.

docs/work-items/ORCH-009/12-review.md

@@ -0,0 +1,167 @@
+---
+verdict: APPROVED
+work_item: ORCH-009
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-10
+model_used: claude-fable-5
+type: review
+work_item_id: ORCH-009
+version: 2
+---
+
+# Review ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook) — re-review (цикл 2)
+
+Ветка: `feature/ORCH-009-turnkey-plane` · Diff vs `origin/main`: 46 файлов, +5478/−12.
+Состав: kit `onboarding/repo-skeleton/` (28 файлов), CLI `scripts/onboard_project.py` (1090 строк),
+runbook `docs/operations/ONBOARDING.md`, 3 онбординг-тест-модуля (83 теста), golden-source доки,
+ADR×2 + индекс.
+
+**Контекст цикла:** review v1 (`APPROVED`, 3×P2/2×P3) → testing `PASS` → re-test merge-gate упал на
+**средовых** не-герметичных тестах ORCH-41-эры (прод-env `ORCH_AGENT_FALLBACK_MODEL`/
+`ORCH_AGENT_MODEL_DEFAULT`) → откат на development → фикс `e903818` (герметизация
+`tests/test_resolve_agent_{model,effort}.py`) + регенерация `17-security-report.md` (`b26a391`).
+Этот review: независимая проверка дельты цикла + выборочная верификация клеймов v1.
+
+## Summary
+
+**APPROVED.** P0/P1 нет. Дельта цикла (фикс герметичности тестов) корректна, трассирована к
+ORCH-074 ADR-001 Решение 3 и сохраняет его инвариант; полный регресс теперь зелёный **под
+фактическим прод-env** (перепроверено мной: 1713 passed, exit 0 — ровно та среда, что валила
+merge-gate до фикса). Клеймы review v1 выборочно перепроверены и подтверждены. Переносятся 3×P2
+(харднинг краевых путей CLI, не фикшены — легитимно, follow-up) + 3×P3. Документация обновлена в
+том же PR по всем точкам, включая отдельную CHANGELOG-запись про сам фикс тестов.
+
+## Оси проверки
+
+### Ось 1 — Соответствие ТЗ (`02-trz.md`, `03-acceptance-criteria.md`) — ✅
+
+| Требование | Статус | Чем подтверждено |
+|---|---|---|
+| FR-1 состав kit (19 элементов, анти-форк канона) | ✅ | TC-01/02 зелёные; `docs/_templates|_standards` в kit не хранятся — live-copy в `materialize_kit` (`LIVE_COPY_DIRS`, прочитан код) |
+| FR-2 канон 52d/92 промптов (5 секций, ❌→✅, `<escalation>`, 52c-схема, verdict-ключи байт-в-байт, плейсхолдерные даты/модели) | ✅ | TC-03…06 зелёные; verdict-ключи в kit-промптах сверены grep'ом (`verdict:`/`staging_status:`/`deploy_status:`/`security_status:` на месте) |
+| FR-2 reviewer-gate доки (AC-3) | ✅ | kit `reviewer.md:65`: «документация НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES`» — прочитано лично |
+| FR-3 INFRA.md шаблон | ✅ | TC-19 зелёный (топология/env/границы/риски общего хоста); INFRA орка не тронут (diff пуст) |
+| FR-4 CLI plan/apply/verify | ✅ | Код прочитан полностью: `plan` GET-only (рендер in-memory), `apply` идемпотентный ensure без delete, 22 статуса из `_PLANE_NAME_TO_KEY` + `STATE_GROUPS` 1:1 c ADR D5, CE-отказ → `ManualStep` → `manual-step` (fail-safe); TC-13…18 зелёные |
+| FR-5 verify | ✅ | round-trip фактическим парсером, резолв всех 22 имён, лейблы, webhook active, полнота kit (`VERIFY_KIT_FILES`), скан `{{…}}`, канон ≥16/≥3 |
+| FR-6 runbook | ✅ | `ONBOARDING.md` прочитан: слои 0→6 в порядке BR-1, каждый 🖐-шаг с командой проверки, self-hosting-предупреждение «групповое окно» (§4.2), workspace-webhook — «существует, только проверка» (§1.5), откат §6 |
+| §4/§5 нет API/БД изменений | ✅ | diff `src/**` пуст (проверено лично) |
+| §9 инварианты | ✅ | `git diff origin/main...HEAD -- src/ .openclaw/ docs/_templates/ docs/_standards/ docs/operations/INFRA.md requirements.txt` — **пусто**; сетевых вызовов в тестах нет (фейк-клиенты); новых pip-зависимостей нет |
+| AC-12 полный регресс | ✅ | **1713 passed, 0 failed, exit 0** — мой прогон в worktree ветки под фактическим хост-env (до фикса здесь было 2 failed) |
+| AC-13 операторский smoke | ⏳ | По построению операторский (ADR D8); «Журнал smoke-прогонов» — плейсхолдер. Обязателен ДО `Confirm Deploy` — см. handoff |
+
+### Ось 2 — Соответствие ADR (`06-adr/ADR-001` D1–D11, сквозной `adr-0035`) — ✅
+
+- **D1** top-level `onboarding/` ✅; **D2** `{{NAME}}` + `str.replace` + обязательный пост-скан
+  (`PLACEHOLDER_RE`, ValueError в `materialize_kit`) + биекция словаря тестом ✅; **D3**
+  live-copy verbatim, существующие файлы не перезаписываются ✅; **D4** закрытый список импортов
+  `src` — в скрипте ровно три (`settings`, `_PLANE_NAME_TO_KEY`, `_parse_projects_json`),
+  загвожден AST-тестом TC-21 ✅; **D5** `STATE_GROUPS` 1:1 с таблицей ADR (22 имени, set-равенство
+  с `_PLANE_NAME_TO_KEY` тестом; `STOP`→`cancelled`; терминальные группы только
+  Done/Cancelled/STOP; `Rejected`→`started`) ✅; **D6** `auto_init=False`, переиспользование
+  глобального HMAC-секрета, push только в свежесозданный/пустой репо ✅; **D7** merged-full-array
+  + round-trip + `.env` read-only ✅; **D8** smoke на staging 8501, журнал в runbook ✅; **D9**
+  5 ru + deployer en с «Do NOT translate»-гардом и рамкой shared-host-гардрейлов (прочитано
+  лично) ✅; **D10** runbook §2.3 «branch protection НЕ включать» ✅; **D11** plan/apply/verify,
+  чистый `build_plan`, инжектируемые клиенты, отчёт `created/skipped(exists)/manual-step/planned/
+  error`, exit-коды 0/2/1 ✅.
+- **Трассировка (`docs/_standards/TRACEABILITY.md`) — дельта цикла:**
+  - `tests/test_resolve_agent_{model,effort}.py` несут маркеры **ORCH-41/ORCH-074** — сверено с
+    `docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md` **Решение 3 (G4)**:
+    инвариант = «**shipped-дефолт** `agent_fallback_model` остаётся `""`». Фикс переводит ассерт
+    с env-backed singleton на **класс-дефолт поля** (`model_fields[...].default == ""`) — это
+    и есть подлинный инвариант ADR (заводской дефолт, а не рантайм-конфиг оператора);
+    never-break ассерты `is_valid_model` — байт-в-байт. Инвариант **сохранён и уточнён**,
+    обоснование — в коммит-месседже и инлайн-комментариях со ссылкой на ADR. Чужой инвариант
+    не сломан → finding нет.
+  - `docs/architecture/adr/README.md` — бэкфилл строк 0032–0035 сверен: все 4 файла
+    (`adr-0032-bug-fast-track`, `adr-0033-sidecar-watchdog`, `adr-0034-lessons-journal`,
+    `adr-0035-turnkey-project-onboarding`) существуют, привязки задач корректны, «текущий
+    максимум 0035» верен.
+  - `docs/operations/SETUP_WEBHOOKS.md` — обобщение per-repo **усиливает** инвариант одного
+    глобального HMAC-секрета (явное предупреждение про ротацию на всех репо разом).
+- **Инварианты NFR-1/INV-4:** снапшот-тесты `STAGE_TRANSITIONS`/`QG_CHECKS` зелёные; push —
+  только initial в пустой репо вне конвейера; PR-merge API не затрагивается.
+
+### Ось 3 — Качество кода — ✅ (с переносными P2 ниже)
+
+- CLI: чистое разделение слоёв (ядро без I/O / тонкие клиенты / режимы), docstrings на всех
+  публичных функциях, единственная точка subprocess (только `git`, токен в логе маскируется
+  `://***@`), `ManualStep` fail-safe вместо падений, delete-операций нет вовсе, секрет в отчёте
+  `***` + тест non-leak. Тесты содержательные: AST-проверка закрытого списка импортов,
+  monkeypatch-мины на мутации в dry-run, негативные CE-сценарии, set-равенство против дрейфа
+  констант — не тривиальные.
+- **Фикс герметичности (дельта цикла) — корректен:** autouse-фикстуры пиняют shipped-дефолты
+  (зеркально между файлами-сиблингами), в чистом env поведение байт-эквивалентно; класс среды
+  merge-gate re-test (прод-env) теперь покрыт. Перепроверено прогоном: 1713 passed под хост-env.
+  Правка существующих тестов вне инвентаря ТЗ §2 — легитимна: инвентарь «рабочее предложение»,
+  ни один инвариант §9 не запрещает правку тестов; без неё PR непроходим через merge-gate
+  (латентная мина `main`, детонированная сменой прод-env).
+- Багфикс-трек (ORCH-019, BR-4): не применим — задача не `Bug`, маршрут полный.
+
+### Ось 4 — Документация — ✅ ОБНОВЛЕНА В ТОМ ЖЕ PR
+
+| Точка | Статус |
+|---|---|
+| `CLAUDE.md` — раздел «Turnkey-онбординг проектов (ORCH-009)» | ✅ |
+| `docs/architecture/README.md` — раздел + ссылки на оба ADR | ✅ (diff прочитан, фактам соответствует) |
+| `CHANGELOG.md` — детальная `feat`-запись **+ отдельная под-запись про фикс герметичности тестов** | ✅ (дельта цикла задокументирована — образцово) |
+| ADR per-WI `06-adr/ADR-001` + сквозной `adr-0035` + индекс `adr/README.md` | ✅ |
+| `docs/operations/ONBOARDING.md` (новый runbook) | ✅ |
+| `docs/operations/SETUP_WEBHOOKS.md` — обобщён per-repo | ✅ |
+| `onboarding/README.md` — устройство kit, словарь, анти-форк | ✅ |
+| README «Известные ограничения» (ORCH-079) | **N/A — проверено лично:** открыты 3 пункта (Telegram 48h / intra-repo deps ORCH-026 / пакетный автоном Этап 1) — ни один этим PR не закрывается |
+| `17-security-report.md` | ✅ `security_status: PASS` (0 secrets, 0 blocking) |
+| `08-data-requirements.md` отсутствует | Легитимно: гейт `check_analysis_complete` требует 01–04; ТЗ §5 «изменений БД нет» |
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix (перенос из review v1 — не фикшены, перепроверены: всё ещё в коде; follow-up, не блокируют)
+- [ ] **Quoted-значение в `.env` → тихая потеря существующих записей в merged-выводе.**
+  `read_existing_registry` (строка ~355) возвращает значение после `=` как есть; кавычки →
+  `json.loads` в `merged_projects_json` молча даёт `existing=[]` → merged-массив только с новым
+  проектом, а runbook §4.1 велит «заменить строку». Доминирующий путь безопасен (pydantic
+  снимает кавычки), потому P2. Рекомендация: `strip("'\"")` в фоллбеке + GAP-warning, если строка
+  в `.env` есть, а existing пуст. (ADR D7 «существующие не теряются».)
+- [ ] **`GiteaClient.create_repo`: фоллбек `POST /user/repos` может создать репо в чужом
+  namespace** (строки ~474–477): owner не org и не юзер токена → репо рождается под юзером
+  токена, последующие шаги по `owner/repo` дают 404/manual-step. Рекомендация: сверять
+  `owner.login` ответа с запрошенным; расхождение → `manual-step`.
+- [ ] **CE-деградация Plane + успешный Gitea в одном apply запекает литерал
+  `<assigned-on-apply>` в запушенный паспорт** (`build_params` → `PLANE_PROJECT_ID`); скан ловит
+  только `{{…}}`. Рекомендация: при неразрешённом `PLANE_PROJECT_ID` деградировать
+  `kit.materialize`/`kit.push` в `manual-step` ИЛИ добавить `<assigned-on-apply>` в скан verify.
+
+### P3 — Nice to have
+- [ ] `--env-file` игнорируется в `plan` (`run_plan` → `_registry_instructions(report, params,
+  None)`; `main()` его в `run_plan` и не передаёт): превью merged-массива может расходиться с apply.
+- [ ] Push-URL с `oauth2:<token>@` остаётся в `.git/config` temp-каталога после успешного apply
+  (cleanup нет). Рекомендация: чистить на успехе, на ошибке сохранять для дебага.
+- [ ] *(новое)* `run_apply`: шаг `registry.emit` добавляется со статусом `CREATED` **до**
+  `_registry_instructions`, который на ошибке round-trip добавляет второй шаг `registry.emit`
+  со статусом `ERROR` → дубль step-id в отчёте (exit-код при этом честный — 1). Косметика отчёта.
+
+## Документация
+
+Обновлена полностью в том же PR (таблица оси 4). Несоответствий «код изменён — дока молчит» нет;
+дельта цикла (фикс тестов) получила собственную CHANGELOG-запись с диагнозом и обоснованием;
+обзорная витрина README задачей не затрагивается (проверено: открытые ограничения не про онбординг).
+
+## Для следующей стадии (testing) — handoff
+
+1. **AC-13 (операторский smoke, ADR D8)** — единственный непокрытый pytest'ом AC: прогон по
+   runbook §5.2 (staging 8501, sandbox `SMK`) должен быть выполнен и запротоколирован в «Журнале
+   smoke-прогонов» `ONBOARDING.md`, ссылка — из `13-test-report.md`. Обязателен **до**
+   `Confirm Deploy` (человеческий гейт — точка контроля сохраняется).
+2. Средовая мина merge-gate обезврежена фиксом `e903818`: полный регресс зелёный и в чистом env,
+   и под прод-env (1713 passed, проверено в этом review) — спец-обвязка прогона больше не нужна.
+3. `13-test-report.md` в дереве — от прошлого цикла (до `e903818`): его строка «PR эти файлы не
+   трогает» про `tests/test_resolve_agent_*` устарела. Перегенерировать отчёт штатно (артефакт
+   чужой стадии — в этом review не правился).

docs/work-items/ORCH-009/13-test-report.md

@@ -0,0 +1,117 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-009
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-009
+---
+
+# Test Report — ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook)
+
+> Машинный вердикт читается ТОЛЬКО из frontmatter (`result:`). Перепрогон стадии testing на
+> opus после сброса session-limit (ре-ран по запросу). Review-вердикт цикла 2 — `APPROVED`
+> (`12-review.md`, P0/P1 нет). Дельта цикла (герметизация ORCH-41-тестов `e903818`) перепроверена
+> полным регрессом под фактическим окружением worktree.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (pytest-cov 5.0.0, asyncio 0.23.8)
+- Дата: 2026-06-10
+- Worktree: `feature/ORCH-009-turnkey-plane` (`/repos/_wt/orchestrator/feature_ORCH-009-turnkey-plane`, HEAD `b97ffae`)
+- Прод-контейнер `orchestrator` (8500) — НЕ трогался (smoke read-only).
+
+## Smoke API (read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
+- `GET /status` → отвечает; задача ORCH-009 (task 87) на стадии `testing` ✅
+- `GET /queue` → блок `serial_gate` **присутствует** (ORCH-088) ✅; блок `auto_labels` присутствует ✅
+  (полный набор ключей: `auto_labels, bug_fast_track, build_cache_prune, counts, coverage,
+  disk_monitor, fs_ownership, lessons, max_concurrency, merge_verify, poll_interval, post_deploy,
+  reaper, recent, reconcile, resilience, serial_gate, stop, task_deps`).
+
+## Результаты
+
+### Полный регресс
+`pytest tests/ -q` → **1713 passed, 0 failed, 1 warning** за 65.40s (exit 0). Прод-контейнер не
+трогался. Средовая мина merge-gate цикла 1 обезврежена фиксом `e903818` — регресс зелёный.
+
+### Профильные сюиты (онбординг)
+`pytest tests/test_onboarding_kit.py tests/test_onboarding_script.py tests/test_onboarding_invariants.py -v`
+→ **83 passed, 0 failed** за 0.55s (exit 0). Сетевых вызовов нет (Plane/Gitea — фейк-клиенты, NFR-5).
+
+### Сопоставление с тест-планом (`04-test-plan.yaml`)
+
+| TC ID | Описание | Тест-функция | Рез. |
+|-------|----------|--------------|------|
+| TC-01 | Kit содержит все элементы FR-1 (6 промптов + доки) | `test_tc01_kit_contains_all_required_elements`, `test_tc01_kit_readme_and_placeholder_dictionary_exist` | PASS |
+| TC-02 | Материализация добавляет live-копии `_templates`/`_standards`; форк канона отсутствует | `test_tc02_materialise_live_copies_canon`, `test_kit_does_not_fork_the_canon` | PASS |
+| TC-03 | 5 XML-секций в нормативном порядке (6 ролей) | `test_tc03_five_xml_sections_in_normative_order[*]` | PASS |
+| TC-04 | `<escalation>` у dev/rev/tester; запреты «❌→✅» | `test_tc04_escalation_section_after_success_criteria[*]`, `test_tc04_bans_use_cross_check_format[*]` | PASS |
+| TC-05 | Директивы доки (читай паспорт/AGENTS/ADR; пиши в work-items; CHANGELOG) | `test_tc05_prompt_directs_agent_to_docs[*]`, `test_tc05_changelog_duty_present[*]`, `test_tc05_architect_carries_adr_rules` | PASS |
+| TC-06 | 6-польная схема 52c; verdict-ключи байт-в-байт; даты/модели — плейсхолдеры | `test_tc06_six_schema_fields_named[*]`, `test_tc06_schema_pins_role_author_and_stage[*]`, `test_tc06_machine_verdict_keys_byte_exact`, `test_tc06_dates_and_models_are_placeholders[*]` | PASS |
+| TC-07 | reviewer-gate: дока не обновлена → `REQUEST_CHANGES` | `test_tc07_reviewer_gate_docs_not_updated_means_request_changes` | PASS |
+| TC-08 | Языковая политика (5 ru + deployer en) | `test_tc08_ru_canon_for_five_roles[*]`, `test_tc08_deployer_is_english` | PASS |
+| TC-09 | Рендер подставляет все плейсхолдеры (нет неразрешённых) | `test_tc09_render_resolves_all_placeholders`, `test_render_is_a_pure_replace` | PASS |
+| TC-10 | Нет утечек орк-специфики (ORCH-/8500/8501/self-hosting) | `test_tc10_no_orchestrator_specific_leaks` | PASS |
+| TC-11 | Ссылочная целостность отрендеренных промптов/AGENTS | `test_tc11_referenced_paths_exist_in_materialised_tree` | PASS |
+| TC-12 | Registry round-trip через фактический `_parse_projects_json`; существующие записи целы | `test_tc12_registry_round_trip_through_actual_parser`, `test_tc12_merge_is_idempotent_no_duplicates` | PASS |
+| TC-13 | План Plane: все статусы `_PLANE_NAME_TO_KEY` (вкл. `Confirm Deploy`/`STOP`) + лейблы | `test_tc13_plan_covers_all_statuses_and_labels`, `test_state_groups_match_plane_name_to_key` | PASS |
+| TC-14 | Недоступный Plane-шаг → `manual-step` (не падение/не молча) | `test_tc14_plane_refusal_becomes_manual_step` | PASS |
+| TC-15 | План Gitea: репо + webhook (push/pr/status + HMAC) + initial push | `test_tc15_plan_contains_gitea_repo_webhook_and_push` | PASS |
+| TC-16 | dry-run (plan) — ноль мутаций | `test_tc16_plan_is_a_pure_dry_run`, `test_secret_never_leaks_into_report` | PASS |
+| TC-17 | Повторный apply: `skipped(exists)`, без дублей/удалений; отчёт created/skipped/manual | `test_tc17_second_apply_skips_everything_existing` | PASS |
+| TC-18 | Нет операций рестарта/правки прод-.env/push в существующие репо (NFR-2) | `test_tc18_fresh_apply_runs_git_only_inside_workdir`, `test_tc18_source_has_no_container_or_env_mutation_ops` | PASS |
+| TC-19 | INFRA.md шаблон: обязательные секции; INFRA орка не тронут | `test_tc19_infra_template_mandatory_sections`, `test_tc19_orchestrator_own_infra_untouched_sections` | PASS |
+| TC-20 | Runbook: слои предусловия→Plane→Gitea→kit→регистрация→верификация→откат | `test_tc20_runbook_exists_and_layer_order`, `test_tc20_runbook_manual_steps_and_selfhosting_warning`, `test_tc20_runbook_verification_and_smoke_journal` | PASS |
+| TC-21 | Снапшот `STAGE_TRANSITIONS`/`QG_CHECKS`; `src/**` не ссылается на онбординг; закрытый список импортов | `test_tc21_stage_transitions_snapshot`, `test_tc21_qg_checks_registry_snapshot`, `test_tc21_src_never_references_onboarding`, `test_tc21_cli_src_imports_stay_in_closed_list`, `test_tc21_kit_prompts_name_only_real_gates` | PASS |
+| TC-22 | Полный регресс `tests/` зелёный | весь прогон `pytest tests/` (1713 passed) | PASS |
+
+**Итого тест-плана: 22/22 TC выполнены и PASS.**
+
+### Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
+
+| AC | Покрытие | Результат |
+|----|----------|-----------|
+| AC-1 Kit полон | TC-01 | PASS |
+| AC-2 Канон 52d/92 промптов | TC-03/04/05/06 | PASS |
+| AC-3 Reviewer-gate доки | TC-07 | PASS |
+| AC-4 Языковая политика | TC-08 | PASS |
+| AC-5 Материализация / нет утечек | TC-02/09/10/11 | PASS |
+| AC-6 Registry round-trip | TC-12 | PASS |
+| AC-7 План Plane (статусы/лейблы) | TC-13/14 | PASS |
+| AC-8 План Gitea + dry-run без мутаций | TC-15/16 | PASS |
+| AC-9 Идемпотентность/безопасность apply | TC-17/18 | PASS |
+| AC-10 INFRA.md шаблон | TC-19 | PASS |
+| AC-11 Runbook полон | TC-20 | PASS |
+| AC-12 `src/**` не тронут (снапшот + регресс) | TC-21/22 | PASS |
+| AC-13 Операторский smoke на песочнице | вне pytest (см. ниже) | DEFERRED (операторский гейт до `Confirm Deploy`) |
+
+## AC-13 — операторский smoke (не блокирует ребро testing → deploy-staging)
+AC-13 по построению (ADR D8, scope-нота `04-test-plan.yaml`) — **документированный операторский
+прогон** на песочнице staging 8501 с реальными Plane/Gitea-вызовами. Это мутирующая операторская
+процедура → вне read-only smoke и автоматизированного скоупа тестера. «Журнал smoke-прогонов»
+в `docs/operations/ONBOARDING.md` сейчас — плейсхолдер (прогон не выполнен).
+- **Не блокирует данную стадию:** AC-13 обязателен **до `Confirm Deploy`** (человеческий гейт
+  прод-деплоя, ORCH-059), который наступает ПОСЛЕ `deploy-staging`. Ребро `testing → deploy-staging`
+  он не гейтит (это операторская страховка, а не Quality Gate; `QG_CHECKS` не содержит проверки AC-13).
+- **Handoff оператору:** выполнить runbook §5.2 (staging 8501, sandbox-префикс) и запротоколировать
+  результат в «Журнале smoke-прогонов» `ONBOARDING.md` **перед** нажатием `Confirm Deploy`.
+
+## Вывод pytest (итоги)
+```
+# полный регресс
+1713 passed, 1 warning in 65.40s (exit 0)
+
+# профильные сюиты онбординга
+83 passed, 1 warning in 0.55s (exit 0)
+```
+(Единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, существующий, не связан с задачей.)
+
+## Итог
+**PASS.** Полный регресс зелёный (1713 passed), все 22 TC тест-плана выполнены и PASS, все
+машинно-проверяемые AC (1–12) закрыты, read-only smoke API в норме (`serial_gate`/`auto_labels`
+в `/queue` присутствуют). AC-13 — операторский smoke, отложен к гейту `Confirm Deploy` (не блокирует
+переход на `deploy-staging`). Задача готова к стадии `deploy-staging`.

docs/work-items/ORCH-009/14-deploy-log.md

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-009
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-036 executable self-deploy
+
+Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
+
+Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-009/15-staging-log.md

@@ -0,0 +1,48 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-009
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-10
+model_used: claude-fable-5
+timestamp: 2026-06-10T13:07:10Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment
+(`orchestrator-staging`, 8501), run canonically inside the container
+(ORCH-048, ADR-001: `docker exec orchestrator-staging python3
+/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501
+--mode stub`).
+
+**Verdict: SUCCESS** (exit code 0).
+
+## Results
+
+Result: 8/10 checks PASS. All REAL (pipeline) checks are green:
+
+- **Block A (SMOKE)**: A1 `/health` → 200 status=ok, A2 `/queue` → 200 with
+  counts/max_concurrency/resilience (incl. `serial_gate`, `coverage`,
+  `auto_labels`, `stop`, `bug_fast_track`, `lessons` blocks), A3
+  `ORCH_STAGING=true` — PASS
+- **Block B (ACCESS)**: B4 Plane sandbox accessible, B5 Gitea
+  `orchestrator-sandbox` accessible (push=true), B6 registry isolation
+  (sandbox present, prod ET/ORCH absent) — PASS
+- **Block C (E2E, mode=stub)**: C7 create issue in Plane SANDBOX (HTTP 201),
+  C8 trigger pipeline via `/webhook/plane` (HTTP 200, accepted) — PASS;
+  cleanup completed (Plane issue deleted, HTTP 204)
+
+REAL failed: none.
+
+The two failed checks (C9a/C9b) are known sandbox-infra checks (they depend on
+SANDBOX bot accounts being project members, not on the pipeline) and were
+waived per ORCH-061 (`staging_infra_tolerance_enabled=True`); the script still
+exited 0 fail-closed because every REAL check is green.
+
+```
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+```

docs/work-items/ORCH-009/17-security-report.md

@@ -0,0 +1,25 @@
+---
+security_status: PASS
+secrets_found: 0
+deps_blocking: 0
+deps_warning: 4
+deps_audit_degraded: false
+---
+# Security Report — ORCH-009
+
+Детерминированный security-гейт (ORCH-022): secret-scanning (gitleaks, offline) + dependency audit (pip-audit). Машинный вердикт читается ТОЛЬКО из frontmatter выше.
+
+## Verdict
+clean: 0 secrets, 0 blocking CVE(s)
+
+## Secrets
+- None
+
+## Dependencies (blocking)
+- None
+
+## Dependencies (warning)
+- `pytest==8.3.3` — GHSA-6w46-j5rx-g56g severity=UNKNOWN fix=9.0.3
+- `starlette==0.38.6` — PYSEC-2026-161 severity=UNKNOWN fix=1.0.1
+- `starlette==0.38.6` — GHSA-f96h-pmfr-66vw severity=UNKNOWN fix=0.40.0
+- `starlette==0.38.6` — GHSA-2c2j-9gv5-cj73 severity=UNKNOWN fix=0.47.2

docs/work-items/ORCH-011/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
+
+Work Item ID: ORCH-011
+
+## Description
+
+TBD

docs/work-items/ORCH-011/01-brd.md

@@ -0,0 +1,199 @@
+---
+work_item: ORCH-011
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD: ORCH-011 — Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
+
+Work Item: **ORCH-011** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
+Заказчик: Владелец (Слава)
+Тип: docs+tests (паттерн ORCH-102/103 — golden-source-документ + структурные анти-дрейф тесты; рантайм не трогается)
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1. Цель
+Описать работу **всей** мультиагентной системы оркестратора в **одном месте** — от бизнес-смысла
+(зачем, какую проблему решает, что умеет) до технического устройства (архитектура, конвейер,
+агенты, модель объектов, интеграции, качество, наблюдаемость). Документация нужна, чтобы:
+1. **другие люди** (разработчики, заказчики, менеджеры проектов) могли разобраться, как работает
+   оркестратор, не раскапывая 60+ work-item пакетов и 40 ADR;
+2. на её основе **генерировать презентационные материалы** по использованию и возможностям
+   (решение Владельца: слайды PowerPoint, стильный тёмный дизайн, точный рендеринг).
+
+### 1.2. Корневая проблема — документация богатая, но фрагментированная
+Установленные факты (проверено по дереву репо, не изобретать):
+
+| Что есть | Где | Ограничение как «единого места» |
+|----------|-----|---------------------------------|
+| Паспорт проекта | `CLAUDE.md` | для агентов/разработчиков; плотный реестр доработок, не вводный текст |
+| Тех-витрина | `README.md` | только технический уровень; обзор без бизнес-слоя |
+| Бизнес-видение | `docs/PRODUCT_VISION.md` (v1.0, 2026-06-04) | «концепция развития» (vision), не описание текущего состояния; не покрывает тех-уровень |
+| Детальная архитектура | `docs/architecture/README.md` (~1246 строк), `internals.md` | глубокий справочник для инженеров; нечитаем «с нуля» нетехническим читателем |
+| Решения | `docs/architecture/adr/` (40 сквозных ADR) + per-work-item ADR | точечные решения, не цельная картина |
+| Стандарты | `docs/_standards/` (PIPELINE_DOCS, HANDOFF_PROTOCOL, TRACEABILITY) | нормативы для агентов |
+| Эксплуатация/тираж | `docs/operations/` (8 runbook'ов), `docs/deployment/` (LITE_SETUP, BUNDLED_SETUP) | операторские инструкции |
+| История/уроки | `docs/history/`, `docs/epics/self-evolution.md` | сырьё, не витрина |
+
+**Ни один** из этих документов не является единой точкой входа «бизнес + тех» для трёх целевых
+аудиторий. Новому человеку (заказчику, менеджеру, новому разработчику) сегодня нужно собирать
+картину из 5–8 разных мест с разной степенью детализации и разным языком. Презентацию о
+возможностях системы собирать не из чего — нет слайдо-готового источника.
+
+### 1.3. Почему сейчас
+- Платформа достигла тиражируемости (ORCH-101/102/103: Lite- и Bundled-развёртывание у заказчика)
+  — появился **внешний читатель** (заказчики-тестеры), которому нужно объяснять систему.
+- Самовоспроизводящийся темп доработок (self-hosting) без единой витрины делает порог входа всё
+  выше с каждой задачей.
+
+### 1.4. Решения Владельца (из бизнес-запроса) — приняты как требования
+| # | Решение |
+|---|---------|
+| D-1 | Формат презентационных материалов — **слайды PowerPoint**, стильный **тёмный дизайн**, точный рендеринг. |
+| D-2 | Аудитория документации — **разработчики, заказчики, менеджеры проектов** (три явных маршрута чтения). |
+| D-3 | Единое место — репозиторий orchestrator: `docs/` (+ возможно compiled-wiki — как опция, см. §2.2). |
+| D-4 | Поддерживать в актуальном состоянии: документация обновляется **сразу после изменения функционала** (правило CLAUDE.md §2 распространяется на новую витрину). |
+
+---
+
+## 2. Объём (scope)
+
+### 2.1. В объёме
+- **Единая витрина системы** — новый связный раздел в `docs/` с одной точкой входа (индексом),
+  покрывающий **два уровня**:
+  - **Бизнес-уровень** (для нетехнических читателей и презентаций): зачем нужен оркестратор и
+    какую проблему решает; что умеет (автономный конвейер «задача → прод», мультипроектность,
+    самовосстановление, пакетный авто-режим, багфикс-трек, тиражируемость); ценность и
+    возможности простым языком; сценарии использования.
+  - **Технический уровень** (7 блоков, контент-карта — TRZ §3):
+    1) архитектура — компоненты и их связи; 2) конвейер/стадии и гейты на переходах;
+    3) агенты — 6 ролей, входы/выходы, артефакты, шаблоны; 4) структура объектов —
+    Project/Work-Item, реестр проектов, jobs-очередь, события/дедуп, каноническая модель БД;
+    5) интеграции — Plane, Gitea, LLM-модели, Telegram; 6) качество/безопасность;
+    7) аналитика/наблюдаемость.
+- **Маршруты чтения** для трёх аудиторий (D-2): «я заказчик / я менеджер / я разработчик —
+  с чего начать и что читать дальше».
+- **Презентационная основа** (D-1): слайдо-структурированный источник (последовательность
+  слайдов: заголовок/тезисы/визуальный мотив) + воспроизводимый путь получения `.pptx` в тёмном
+  дизайне. Выбор инструмента генерации — за архитектором (TRZ §3.4, OQ-2).
+- **Норматив сопровождения**: правило «изменил функционал → обнови витрину в том же PR»
+  зафиксировано в витрине и в правилах агентов (D-4; ось reviewer'а по обзорным докам уже
+  существует — ORCH-079).
+- **Анти-дрейф**: структурные pytest-тесты каркаса витрины (по образцу
+  `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py`): обязательные разделы, сверка
+  карты стадий импортом `src/stages.py::STAGE_TRANSITIONS`, полнота 6 агентов, валидность
+  внутренних ссылок, запрет секретов/хост-хардкодов.
+- Обновление указателей: `README.md`, `CLAUDE.md` (ссылка на витрину), `CHANGELOG.md`.
+
+### 2.2. Вне объёма (явно, не делать)
+- **Любые изменения рантайма:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
+  machine-verdict ключи, схема БД, compose/Dockerfile — байт-в-байт.
+- **Compiled-wiki / внешняя вики-платформа** — вне объёма v1: репозиторий остаётся единственным
+  источником истины («канон не форкается», паттерн ORCH-009 BR-2); экспорт в wiki — возможное
+  развитие, фиксируется как открытый вопрос (TRZ §9 OQ-4), не реализуется.
+- **Перенос вне-репозиторных источников в репо**: `tasks/orchestrator/STATUS.md`, `BACKLOG.md`,
+  PROGRESS-журналы, дневники `memory/` физически в репозитории отсутствуют — они служат лишь
+  затравками для содержания; сами файлы в гит не переносятся (внутренняя кухня, риск утечки
+  контекста/секретов).
+- **Переписывание/замена существующих golden sources** (`docs/architecture/README.md`,
+  `internals.md`, стандарты `docs/_standards/`, deployment-доки): витрина ссылается на них,
+  а не дублирует и не подменяет (анти-«второй источник истины», BR-4).
+- **Автогенерация документации из кода** (doc-from-code, autodoc) — вне объёма.
+- **Маркетинговые материалы за пределами PPTX-основы** (видео, лендинги, демо-стенды).
+- Новые runtime-зависимости прод-образа (включая библиотеки генерации презентаций) — запрещено
+  (NFR-2).
+
+---
+
+## 3. Заинтересованные стороны
+- **Владелец/оператор (Слава)** — заказчик задачи; принимает витрину и презентационную основу;
+  использует слайды для показа возможностей платформы.
+- **Заказчики платформы** (внешние, включая тестеров Lite/Bundled-тиража ORCH-102/103) — читают
+  бизнес-уровень и сценарии; смотрят презентацию.
+- **Менеджеры проектов** — читают бизнес-уровень + конвейер/статусную модель (что видно в Plane,
+  какие человеческие гейты есть).
+- **Разработчики** (люди и агенты самого оркестратора) — входят через витрину в технический
+  уровень и далее по ссылкам в golden sources.
+- **Reviewer-агент конвейера** — контролирует соблюдение норматива сопровождения витрины
+  (расширение оси «обзорные доки» ORCH-079).
+
+---
+
+## 4. Бизнес-требования (BR)
+
+| ID | Требование | Связь |
+|----|------------|-------|
+| BR-1 | В `docs/` существует **единая точка входа** (индекс витрины), из которой достижимы оба уровня (бизнес/тех) и все 7 тех-блоков; любой из трёх читателей начинает с одного места. | D-3, AC-1 |
+| BR-2 | **Бизнес-уровень** читается нетехническим человеком: проблема → решение → ценность → возможности → сценарии использования; термины конвейера объяснены по-человечески; без необъяснённого жаргона и кодовых идентификаторов в основном тексте. | D-2, AC-2 |
+| BR-3 | **Технический уровень** покрывает все 7 заявленных блоков (§2.1) и соответствует фактическому коду/канону репо: карта стадий = `STAGE_TRANSITIONS`, реестр гейтов = `QG_CHECKS` + под-гейты, агенты = 6 промптов `.openclaw/agents/` + таблица модель/эффорт (ORCH-41), модель данных = фактические таблицы `src/db.py`. | AC-3, AC-4, AC-5 |
+| BR-4 | **Link-first / не форкается канон:** витрина даёт цельную картину и ссылается на golden sources за деталями (architecture/README, internals, стандарты, ADR, deployment-доки); не создаёт второй источник истины и не противоречит коду. | §2.2, AC-6 |
+| BR-5 | **Презентационная основа:** в репо есть слайдо-структурированный источник (бизнес-нарратив → слайды) и воспроизводимый, документированный путь получения `.pptx` в тёмном дизайне (D-1). Инструмент — выбор архитектора; запуск — вне рантайма конвейера. | D-1, AC-7 |
+| BR-6 | **Маршруты аудиторий:** витрина содержит явные маршруты чтения для заказчика / менеджера / разработчика (D-2). | D-2, AC-8 |
+| BR-7 | **Норматив сопровождения:** правило «изменил функционал → обнови витрину в том же PR» зафиксировано в витрине и видимо агентам (CLAUDE.md-указатель); reviewer-ось обзорных доков покрывает витрину. | D-4, AC-9 |
+| BR-8 | **Анти-дрейф:** каркас витрины и её ключевые машинно-проверяемые факты (стадии, агенты, ссылки, отсутствие секретов) защищены структурными pytest-тестами; их падение ловит расхождение витрины с кодом. | AC-10 |
+| BR-9 | Существующие указатели актуализированы: `README.md` и `CLAUDE.md` ссылаются на витрину; `CHANGELOG.md` несёт запись. | AC-11 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| NFR-1 | **docs+tests only:** `src/**` байт-в-байт; `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД / compose / Dockerfile — не тронуты. Kill-switch не нужен: документация не исполняется (паттерн ORCH-102/103). |
+| NFR-2 | **Прод-образ без новых зависимостей:** генерация презентации (если скриптом) исполняется вне рантайма (host/dev-окружение, явный запуск человеком — паттерн ORCH-009); зависимости генерации НЕ попадают в `requirements`/образ оркестратора. |
+| NFR-3 | **Без секретов и хост-специфики** в новых доках/источниках презентации: токены, внутренние URL/имена хостов — только плейсхолдерами (паттерн `tests/test_no_host_hardcodes.py` / fenced-скан `test_lite_setup_doc.py`). |
+| NFR-4 | **Язык:** русский (канон репо; языковое исключение deployer.md не затрагивается). Терминология единая со статусной моделью Plane (ORCH-066) и PIPELINE_DOCS. |
+| NFR-5 | **Self-hosting safety:** задача не рестартит/не роняет прод-контейнер; прод-деплой — только штатным маршрутом конвейера (staging-гейт + Confirm Deploy). |
+| NFR-6 | **Поддерживаемость:** витрина модульная (отдельные файлы по блокам, связанные индексом), чтобы будущие правки были точечными; объём основного текста разумен за счёт link-first (BR-4). |
+
+---
+
+## 6. Допущения и ограничения
+- **Вне-репозиторные затравки** (`tasks/orchestrator/STATUS.md`, `BACKLOG.md`, PROGRESS-журналы,
+  `memory/`) в worktree недоступны — содержание витрины строится из **внутрирепозиторных** golden
+  sources (CLAUDE.md, README, PRODUCT_VISION, architecture/, _standards/, ADR, deployment/,
+  history/). Этого достаточно: репо самодостаточен по фактам (проверено §1.2).
+- `docs/PRODUCT_VISION.md` остаётся самостоятельным vision-документом; витрина переиспользует его
+  бизнес-нарратив со сверкой с фактическим состоянием (что из vision уже реализовано — например,
+  тираж ORCH-101/102/103) и ссылается на него.
+- Точное имя/структура каталога витрины — решение архитектора (рекомендация TRZ §2: новый каталог
+  в `docs/`, например `docs/overview/`); анти-дрейф тесты пишутся под выбранные пути.
+- Бинарный артефакт `.pptx`: коммит бинаря в git спорен — решает архитектор (OQ-3); требование
+  BR-5 — воспроизводимость пути генерации, не обязательность бинаря в репо.
+- Задача объёмная по контенту: допускается реализация витрины «вглубь по блокам» в одном PR
+  (один прогон developer); если объём не помещается — эскалация на уровне задач (разбиение)
+  по штатному маршруту, не молчаливое сокращение объёма.
+
+---
+
+## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
+- AC-1 единая точка входа существует и связывает оба уровня и маршруты аудиторий.
+- AC-2 бизнес-уровень самодостаточен для нетехнического читателя.
+- AC-3…AC-5 тех-уровень покрывает 7 блоков и сходится с кодом (стадии/гейты/агенты/модель данных).
+- AC-6 link-first: ссылки на golden sources валидны, дублирования-противоречий нет.
+- AC-7 презентационная основа есть; путь к `.pptx` (тёмный дизайн) воспроизводим и документирован.
+- AC-8 маршруты трёх аудиторий присутствуют.
+- AC-9 норматив сопровождения зафиксирован.
+- AC-10 структурные анти-дрейф тесты существуют и зелёные; полный pytest зелёный.
+- AC-11 README/CLAUDE.md/CHANGELOG обновлены; `src/**` не тронут.
+
+---
+
+## 8. Риски (кратко; детали — 10-tech-risks.md, заполняет архитектор)
+- **R-1 — гниение витрины.** Self-hosting темп (несколько задач в неделю) быстро устаревает любой
+  снапшот. Митигция: link-first (BR-4) + норматив сопровождения (BR-7) + структурные тесты на
+  машинно-проверяемые факты (BR-8) — дрейф ловится CI, а не глазами.
+- **R-2 — второй источник истины.** Дублирование деталей architecture/README в витрине приведёт к
+  противоречиям. Митигция: витрина = картина + ссылки; детали живут в существующих golden sources.
+- **R-3 — объём одного прогона.** Полная витрина + презентация + тесты могут не поместиться в один
+  PR разумного размера. Митигция: модульность (NFR-6), приоритет блоков, при необходимости —
+  эскалация/разбиение (допущение §6).
+- **R-4 — зависимость генерации презентации.** Библиотека генерации PPTX в прод-образе — лишний
+  attack-surface/вес. Митигция: NFR-2 (вне рантайма), решение по инструменту — ADR архитектора.
+- **R-5 — расползание скопа в маркетинг.** Слайды → «а давайте ещё видео/лендинг». Митигция:
+  жёсткая граница §2.2.

docs/work-items/ORCH-011/02-trz.md

@@ -0,0 +1,191 @@
+---
+work_item: ORCH-011
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-011 — Полная документация системы мультиагентов оркестратора
+
+Work Item: **ORCH-011** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно появиться/измениться и **где** (файлы, структура, контент-карта,
+> источники истины). **Как** (точное имя каталога витрины, инструмент генерации PPTX, разбиение
+> на файлы) — решает архитектор в `06-adr/`. Тип изменения — **docs+tests** (паттерн
+> ORCH-102/103): рантайм не трогается.
+
+---
+
+## 1. Сводка изменения
+Создать в `docs/` **единую витрину системы** — связный набор документов с одной точкой входа,
+описывающий мультиагентный оркестратор на двух уровнях (бизнес + технический, 7 блоков),
+с маршрутами чтения для трёх аудиторий (разработчики / заказчики / менеджеры), слайдо-готовой
+презентационной основой (PowerPoint, тёмный дизайн) и нормативом сопровождения. Каркас и
+машинно-проверяемые факты витрины защитить структурными pytest-тестами (анти-дрейф). Обновить
+указатели (`README.md`, `CLAUDE.md`, `CHANGELOG.md`). `src/**` — байт-в-байт.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `docs/<витрина>/` (рекомендация: `docs/overview/`; финальное имя — ADR архитектора) | **создать**: индекс + бизнес-часть + тех-часть (7 блоков) + маршруты аудиторий + презентационная основа |
+| `docs/<витрина>/README.md` (или `index.md` — по ADR) | **создать**: единая точка входа (BR-1) |
+| `tests/test_system_docs.py` (имя — по паттерну `test_lite_setup_doc.py`; финал — ADR) | **создать**: структурный анти-дрейф витрины (FR-7) |
+| `scripts/` (опционально, по ADR — например `scripts/build_presentation.py`) | **создать (опц.)**: генерация `.pptx` из презентационной основы (FR-4) |
+| `README.md` | изменить: ссылка на витрину (раздел-указатель) |
+| `CLAUDE.md` | изменить: указатель на витрину + норматив сопровождения (FR-6) |
+| `CHANGELOG.md` | изменить: запись `docs:` |
+| `docs/PRODUCT_VISION.md` | НЕ переписывать; допустима врезка-ссылка на витрину |
+| `src/**`, `docker-compose.yml`, `Dockerfile`, `requirements*` | **НЕ трогать** (NFR-1, NFR-2) |
+
+Чтение (источники истины для контента, без изменения): `src/stages.py`, `src/qg/checks.py`,
+`src/db.py`, `src/projects.py`, `src/plane_sync.py`, `src/notifications.py`, `src/queue_worker.py`,
+`src/agents/launcher.py`, `.openclaw/agents/*.md`, `docs/architecture/README.md`, `internals.md`,
+`docs/_standards/*`, `docs/architecture/adr/*`, `docs/deployment/*`, `docs/operations/*`,
+`docs/PRODUCT_VISION.md`.
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Единая точка входа и каркас витрины (BR-1, NFR-6)
+- Новый каталог в `docs/` с индекс-документом, который: (а) в 1–2 абзацах отвечает «что это за
+  система»; (б) ведёт на бизнес-часть и тех-часть; (в) несёт маршруты чтения трёх аудиторий
+  (FR-5); (г) несёт норматив сопровождения (FR-6).
+- Витрина модульная: отдельные файлы по частям/блокам, связанные индексом (а не один монолит) —
+  точечные правки в будущем дешевле. Точная разбивка — ADR.
+- Все внутренние ссылки — относительные, валидные (проверяется тестом FR-7).
+
+### FR-2 — Бизнес-уровень (BR-2)
+Содержание (для нетехнического читателя; источники: `docs/PRODUCT_VISION.md` §1–2, `README.md`,
+`CLAUDE.md` TL;DR — со сверкой с фактическим состоянием кода):
+- **Проблема и решение:** люди-бутылочное-горлышко в передачах между ролями → конвейер ИИ-агентов
+  «постановка → прод», человек = постановщик и приёмщик.
+- **Что умеет (фактическое состояние, не vision):** автономный конвейер задача→прод с гейтами
+  качества; мультипроектность (несколько репо из одного инстанса); самовосстановление
+  (reconciler / job-reaper / watchdog'и / sidecar); пакетный авто-режим (serial gate ORCH-088 +
+  autoApprove/autoDeploy ORCH-089); дешёвый багфикс-трек (ORCH-019); отмена задач (STOP,
+  ORCH-090); наблюдаемость (живая Telegram-карточка, `/queue`, `/metrics`, журнал уроков);
+  самообслуживание (self-hosting — платформа дорабатывает себя); тиражируемость (Lite/Bundled,
+  ORCH-101/102/103).
+- **Ценность простым языком:** скорость / стоимость / автономность / надёжность / масштаб
+  (переиспользовать формулировки PRODUCT_VISION, сверив цифры с реальностью; цифры без
+  подтверждения в репо не изобретать).
+- **Сценарии использования** (минимум): «фича за вечер» (полный цикл с человеческими гейтами
+  Approved / Confirm Deploy); «багфикс по короткому маршруту» (метка Bug); «пакет задач на ночь»
+  (serial gate + авто-лейблы); «несколько проектов параллельно»; «развернуть платформу у себя»
+  (Lite/Bundled); «остановить задачу» (STOP).
+- Кодовые идентификаторы (`ORCH-NNN`, имена функций) в основном бизнес-тексте не используются;
+  допустимы сноски/ссылки.
+
+### FR-3 — Технический уровень: 7 блоков с контент-картой (BR-3, BR-4)
+Каждый блок: цельное изложение + ссылки на golden source за деталями. Обязательная привязка
+к фактам кода (источники указаны; не дублировать детали сверх необходимого — link-first):
+
+| # | Блок | Обязательное содержание | Источник истины (ссылаться) |
+|---|------|------------------------|------------------------------|
+| 1 | Архитектура | компоненты и связи: FastAPI-приём вебхуков (Plane/Gitea, HMAC, дедуп), очередь jobs + worker, stage-engine, agent launcher (Claude CLI, git worktree), QG-реестр, plane-sync, notifications, фоновые демоны (reconciler, job-reaper, disk-watchdog, build-cache-pruner), sidecar-watchdog; одна диаграмма потока «вебхук → очередь → агент → гейт → переход» | `docs/architecture/README.md` «Компоненты», `internals.md`, `src/main.py` lifespan |
+| 2 | Конвейер/стадии | схема `created → analysis → architecture → development → review → testing → deploy-staging → deploy → done` (+ `cancelled`-сток); exit-гейты рёбер; под-гейты ребра `deploy-staging→deploy` (security → merge → coverage → image-freshness) и `deploy→done` (merge-verify) как врезки, не стадии; откаты REQUEST_CHANGES (max 3); человеческие гейты (Approved BRD, Confirm Deploy) и их снятие авто-лейблами; багфикс-маршрут (пропуск architecture); serial gate / freeze; статусная модель Plane = индикация ≠ управление | `src/stages.py::STAGE_TRANSITIONS`, `src/qg/checks.py::QG_CHECKS`, `docs/_standards/PIPELINE_DOCS.md` §1–3, CLAUDE.md (ORCH-059/066/088/089/019/090) |
+| 3 | Агенты | 6 ролей (analyst/architect/developer/reviewer/tester/deployer): задача роли, вход/выход, артефакты по стадиям, machine-verdict ключи; таблица модель/эффорт (резолв из config, ORCH-41/74/81); канон промптов (5 XML-секций, 52d) и где лежат промпты; handoff-протокол | `.openclaw/agents/*.md`, `docs/_standards/PIPELINE_DOCS.md` §2, `HANDOFF_PROTOCOL.md`, таблица моделей `docs/architecture/README.md` |
+| 4 | Структура объектов | каноническая модель: Project (реестр `projects.py`: plane-project → repo+prefix) → Work-Item/Task (`tasks`: stage, track, ветка) → Jobs (очередь: статусы, atomic claim, deps, ретраи/backoff/breaker) → Agent-runs (стоимость/токены/effort) → события вебхуков и дедуп → вспомогательные таблицы (`repo_freeze`, `coverage_baseline`, `tracker_messages`, `lessons`); словарь терминов (стадия/гейт/под-гейт/job/worktree/lease) | `src/db.py` (фактические таблицы), `src/projects.py`, `internals.md` «Database Schema», ADR соответствующих задач |
+| 5 | Интеграции | Plane (issues/states/labels/webhooks; статусная модель ORCH-066; вход конвейера «To Analyse»); Gitea (репо/ветки/PR; merge строго через PR-API — INV-4; merge-актор с retry ORCH-093; CI `check_ci_green`); LLM (Claude CLI, `--model`/`--effort` из config); Telegram (live-карточка bump-режима, алерты; sidecar-канал отдельно) | `src/plane_sync.py`, `src/webhooks/*`, `src/merge_gate.py`, `src/agents/launcher.py`, `src/notifications.py`, CLAUDE.md (ORCH-042/067/087/093) |
+| 6 | Качество/безопасность | философия Quality Gates: машинные вердикты только из YAML-frontmatter (никогда проза), единый контракт `src/frontmatter.py`; реестр гейтов и что каждый ловит; security-гейт (ORCH-022) и coverage-гейт с baseline-ratchet (ORCH-027); канон секретов (.env, не в гит; `gen_secrets.py`); self-hosting-страховки (staging 8501, Confirm Deploy, запрет force-push в main, никогда не ронять прод) | `src/qg/checks.py`, `src/frontmatter.py`, `docs/_standards/PIPELINE_DOCS.md` §3, CLAUDE.md «Self-hosting», `docs/operations/INFRA.md` |
+| 7 | Аналитика/наблюдаемость | живая Telegram-карточка задачи (стадии, модель/эффорт, стоимость/токены, честные метрики времени); `GET /queue` (снимки всех подсистем: serial_gate, auto_labels, bug_fast_track, coverage, lessons, reaper, reconcile, …); `GET /metrics` (машинный контракт для sidecar, schema_version); sidecar-watchdog (наблюдатель отделён от наблюдаемого); журнал уроков `lessons` (фундамент петли самообучения); стоимость по агентам (`agent_runs`) | `src/metrics.py`, `src/notifications.py`, `src/lessons.py`, `docs/architecture/README.md` (§ /metrics, § sidecar), CLAUDE.md (ORCH-098/099/100) |
+
+- **Согласованность с кодом обязательна:** перечень стадий, имена гейтов, имена агентов, имена
+  таблиц в витрине должны совпадать с фактическими (`src/stages.py`, `src/qg/checks.py`,
+  `src/db.py`); расхождение — дефект (ловится FR-7 и reviewer'ом).
+
+### FR-4 — Презентационная основа и путь к PPTX (BR-5, D-1)
+- В витрине есть **презентационный источник**: упорядоченная последовательность слайдов
+  (рекомендация: markdown с явной слайдо-структурой — «слайд N: заголовок / 3–5 тезисов /
+  подпись-визуал»), покрывающая бизнес-нарратив (проблема → решение → как работает → возможности →
+  сценарии → тираж → статус платформы). Объём — ориентир 12–20 слайдов (финал — у архитектора).
+- Зафиксирован **воспроизводимый путь** получения `.pptx` в тёмном дизайне: либо скрипт в
+  `scripts/` (запуск вне рантайма, host/dev-окружение), либо документированная ручная процедура
+  поверх источника. Выбор инструмента (python-pptx / Marp→pptx / иное) и факт коммита бинаря —
+  решение архитектора (OQ-2, OQ-3). Требования к пути: тёмная тема, кириллица рендерится точно,
+  процедура описана пошагово с проверкой результата (паттерн «команда + Проверка:» из
+  LITE_SETUP).
+- Зависимости генерации **не** попадают в прод-образ/`requirements` оркестратора (NFR-2).
+
+### FR-5 — Маршруты аудиторий (BR-6, D-2)
+- Индекс несёт три явных маршрута: **заказчик** (бизнес-часть → сценарии → презентация →
+  Lite/Bundled-доки), **менеджер** (бизнес-часть → конвейер и статусная модель Plane →
+  человеческие гейты → наблюдаемость), **разработчик** (тех-часть → architecture/README →
+  internals → стандарты → ADR-реестр → CLAUDE.md).
+
+### FR-6 — Норматив сопровождения (BR-7, D-4)
+- В витрине (индексе) — явная норма: «изменил функционал → обнови витрину в том же PR»
+  (формулировка по образцу NFR-5 ORCH-102/103).
+- `CLAUDE.md` — краткий указатель на витрину в существующем правиле документации (§2 правил
+  агентов); reviewer-ось «обзорные доки» (ORCH-079) распространяется на витрину — фиксируется
+  формулировкой в витрине/ADR (изменение промпта reviewer'а НЕ требуется, если ось уже
+  сформулирована обобщённо — проверить при реализации; если требуется правка промпта, она
+  следует канону 52d и анти-регресс тестам `test_agent_prompts_canon.py`).
+
+### FR-7 — Структурный анти-дрейф (BR-8)
+Новый тест-модуль (паттерн `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py` /
+`test_orch_52b_docs_standard.py`; без сети/LLM/subprocess):
+- наличие файлов витрины и обязательных разделов индекса (вкл. маршруты 3 аудиторий и норматив
+  сопровождения);
+- **сверка карты стадий** в витрине импортом `src.stages.STAGE_TRANSITIONS` (полнота и порядок —
+  как тест полноты `_STAGE_STATUS_LABEL` ORCH-091: derive из кода, не статичный список);
+- **полнота 6 агентов** (analyst/architect/developer/reviewer/tester/deployer) в блоке агентов;
+- валидность относительных внутренних ссылок витрины (целевые файлы существуют);
+- FORBIDDEN-скан новых доков/презент-источника: запрещённые хост-литералы (импорт списка из
+  `tests/test_no_host_hardcodes.py`, как делает `test_lite_setup_doc.py`) + секрет-эвристика;
+- наличие ссылки на витрину в `README.md`.
+
+---
+
+## 4. Изменения API
+**Нет.** Эндпоинты/вебхуки не добавляются и не меняются.
+
+## 5. Изменения схемы БД
+**Нет.** Таблицы/миграции не вводятся.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Реестр `QG_CHECKS`/`check_*` не меняется. Анти-дрейф витрины — обычные pytest-тесты в
+`tests/` (исполняются существующими гейтами `check_ci_green`/`check_tests_passed`/coverage-гейтом
+штатно), **не** новый Quality Gate.
+
+## 7. Совместимость / регресс
+- **Нулевая регрессия рантайма по построению:** меняются только `docs/**`, `tests/**`,
+  `README.md`, `CLAUDE.md`, `CHANGELOG.md` (+ опц. `scripts/`); `src/**` байт-в-байт. Kill-switch
+  не нужен — документация и dev-скрипт не исполняются конвейером (паттерн ORCH-009/102/103).
+- Существующие тесты остаются зелёными; новые тесты аддитивны.
+- enduro-trails не затрагивается (общих артефактов нет).
+- Откат = revert PR (доки/тесты), без операционных последствий.
+- Self-hosting: прод-контейнер не рестартится в рамках задачи; выкат — штатным маршрутом.
+
+---
+
+## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR разработки)
+- Витрина `docs/<…>/` (FR-1…FR-5) + презентационный источник.
+- `tests/test_system_docs.py` (FR-7).
+- `README.md` (ссылка), `CLAUDE.md` (указатель + норматив), `CHANGELOG.md` (`docs:`-запись).
+- ADR архитектора: `docs/work-items/ORCH-011/06-adr/ADR-001-<slug>.md` (структура витрины,
+  инструмент PPTX, политика бинаря, состав тестов); при сквозной значимости — зеркало в
+  `docs/architecture/adr/`.
+
+---
+
+## 9. Открытые вопросы для архитектора (не блокируют анализ)
+- **OQ-1:** Имя и внутренняя структура каталога витрины (`docs/overview/` vs `docs/system/`;
+  один индекс + N файлов блоков vs два файла «business/tech»). Рекомендация аналитика —
+  `docs/overview/` с индексом и помодульными файлами (NFR-6).
+- **OQ-2:** Инструмент генерации PPTX: скрипт `scripts/` (python-pptx; host/dev-venv, вне
+  прод-образа) vs конвертация из markdown (Marp и т.п.) vs документированная ручная процедура.
+  Критерии: тёмная тема, точный рендеринг кириллицы, воспроизводимость, NFR-2.
+- **OQ-3:** Коммитить ли собранный `.pptx` в репо (бинарь в git) или хранить только источник +
+  процедуру сборки.
+- **OQ-4:** Compiled-wiki/экспорт (упомянут в бизнес-запросе как «возможно»): фиксируем вне
+  объёма v1; нужно ли заводить follow-up work item.
+- **OQ-5:** Достаточна ли текущая формулировка reviewer-оси обзорных доков (ORCH-079) для
+  покрытия витрины, или нужна точечная правка промпта reviewer (тогда — по канону 52d, с
+  обновлением `test_agent_prompts_canon.py`).

docs/work-items/ORCH-011/03-acceptance-criteria.md

@@ -0,0 +1,187 @@
+---
+work_item: ORCH-011
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки: ORCH-011 — Полная документация системы мультиагентов
+
+Work Item: **ORCH-011** · Repo: **orchestrator** · Стадия: analysis
+
+Каждый критерий — однозначный PASS/FAIL. Reviewer/Tester проверяют буквально по файлам
+репозитория (пути витрины — те, что зафиксирует ADR архитектора; ниже «витрина» = выбранный
+каталог в `docs/`).
+
+---
+
+## AC-1 — Единая точка входа существует (BR-1)
+
+**Условие:** в `docs/` создан каталог витрины с индекс-документом.
+- **PASS:** индекс существует; из него по относительным ссылкам достижимы: бизнес-часть,
+  тех-часть (все 7 блоков FR-3), презентационная основа, маршруты трёх аудиторий, норматив
+  сопровождения. Каталог и индекс совпадают с зафиксированными в ADR-001 путями.
+- **FAIL:** индекса нет, ИЛИ хотя бы одна из перечисленных частей недостижима из индекса.
+
+---
+
+## AC-2 — Бизнес-уровень самодостаточен для нетехнического читателя (BR-2)
+
+**Условие:** бизнес-часть содержит все 5 обязательных смысловых разделов.
+- **PASS:** присутствуют разделы: (1) проблема, которую решает оркестратор; (2) суть решения
+  (конвейер агентов, человек = постановщик/приёмщик); (3) что умеет — фактические способности
+  (минимум: автономный конвейер задача→прод, мультипроектность, самовосстановление, пакетный
+  авто-режим, багфикс-трек, отмена STOP, наблюдаемость, self-hosting, тиражируемость
+  Lite/Bundled); (4) ценность (скорость/стоимость/автономность/надёжность/масштаб);
+  (5) сценарии использования (минимум 5 из перечня FR-2). В основном тексте нет необъяснённых
+  кодовых идентификаторов/имён функций.
+- **FAIL:** отсутствует любой из 5 разделов, ИЛИ способности из обязательного минимума
+  пропущены, ИЛИ текст оперирует жаргоном без объяснения.
+
+---
+
+## AC-3 — Тех-уровень покрывает 7 блоков (BR-3)
+
+**Условие:** тех-часть содержит все блоки контент-карты TRZ §3 FR-3.
+- **PASS:** присутствуют и непусты блоки: 1) архитектура/компоненты (включая фоновые демоны и
+  sidecar), 2) конвейер/стадии/гейты (включая под-гейты и человеческие гейты), 3) агенты,
+  4) структура объектов/каноническая модель, 5) интеграции (Plane/Gitea/LLM/Telegram),
+  6) качество/безопасность, 7) аналитика/наблюдаемость. Блок 1 содержит хотя бы одну
+  диаграмму/схему потока (текстовую ASCII или mermaid).
+- **FAIL:** любой блок отсутствует/пуст, ИЛИ схема потока отсутствует.
+
+---
+
+## AC-4 — Карта стадий и гейтов сходится с кодом (BR-3, FR-7)
+
+**Условие:** конвейер в витрине = `src/stages.py::STAGE_TRANSITIONS` + реестр `QG_CHECKS`.
+- **PASS:** все стадии из `STAGE_TRANSITIONS` (включая `deploy-staging` и сток `cancelled`)
+  присутствуют в витрине в правильном порядке; exit-гейты рёбер названы фактическими именами
+  (`check_analysis_approved` … `check_deploy_status`); под-гейты ребра
+  `deploy-staging→deploy` описаны в фактическом порядке (security → merge → coverage →
+  image-freshness) и явно помечены как врезки, не стадии. Структурный тест сверяет перечень
+  стадий импортом `src.stages.STAGE_TRANSITIONS` и зелёный.
+- **FAIL:** стадия/гейт пропущены или названы несуществующим именем, ИЛИ порядок противоречит
+  коду, ИЛИ тест-сверка отсутствует/красная.
+
+---
+
+## AC-5 — Агенты: 6 ролей с полным паспортом (BR-3)
+
+**Условие:** блок агентов описывает все 6 ролей.
+- **PASS:** для каждой роли (analyst, architect, developer, reviewer, tester, deployer) указаны:
+  назначение, стадия работы, вход, выходные артефакты (по `PIPELINE_DOCS.md` §2) и
+  machine-verdict ключ (где есть: `verdict:`/`result:`/`staging_status:`/`deploy_status:`);
+  присутствует таблица модель/эффорт, совпадающая с фактическим резолвом config (ORCH-41/81:
+  developer=`xhigh`, tester/deployer=`medium`, прочие=`high`). Структурный тест полноты 6 ролей
+  зелёный.
+- **FAIL:** роль пропущена, ИЛИ артефакты/ключи противоречат `PIPELINE_DOCS.md`, ИЛИ таблица
+  модель/эффорт расходится с config.
+
+---
+
+## AC-6 — Link-first: ссылки валидны, канон не форкается (BR-4)
+
+**Условие:** витрина ссылается на golden sources, не подменяя их.
+- **PASS:** витрина содержит работающие относительные ссылки минимум на:
+  `docs/architecture/README.md`, `docs/architecture/internals.md`,
+  `docs/_standards/PIPELINE_DOCS.md`, `docs/_standards/HANDOFF_PROTOCOL.md`, реестр
+  `docs/architecture/adr/`, `docs/deployment/LITE_SETUP.md`, `docs/deployment/BUNDLED_SETUP.md`,
+  `docs/PRODUCT_VISION.md`, `CLAUDE.md`. Все относительные ссылки витрины резолвятся в
+  существующие файлы (структурный тест зелёный). Существующие golden sources не удалены и не
+  переписаны (допустимы только врезки-ссылки).
+- **FAIL:** битая ссылка, ИЛИ обязательная ссылка отсутствует, ИЛИ витрина дублирует-подменяет
+  существующий golden source (например, копия таблицы компонентов architecture/README вместо
+  ссылки с кратким резюме).
+
+---
+
+## AC-7 — Презентационная основа и путь к PPTX (BR-5)
+
+**Условие:** слайдовый источник существует; путь к `.pptx` воспроизводим.
+- **PASS:** в витрине есть презентационный источник с явной слайдо-структурой (нумерованные
+  слайды: заголовок + тезисы), покрывающий бизнес-нарратив FR-4 (проблема → решение → как
+  работает → возможности → сценарии → тираж → статус); зафиксирована пошаговая воспроизводимая
+  процедура получения `.pptx` в тёмном дизайне (скрипт `scripts/` ИЛИ документированная
+  процедура — по ADR-001), каждая команда — с проверкой результата; зависимости генерации
+  отсутствуют в `requirements*` и `Dockerfile` оркестратора (NFR-2).
+- **FAIL:** источника нет, ИЛИ слайдо-структура не выражена, ИЛИ путь к `.pptx` не описан /
+  невоспроизводим, ИЛИ зависимость генерации попала в прод-образ.
+
+---
+
+## AC-8 — Маршруты трёх аудиторий (BR-6)
+
+**Условие:** индекс несёт маршруты чтения.
+- **PASS:** в индексе явно выделены 3 маршрута — заказчик, менеджер проекта, разработчик — каждый
+  с упорядоченным списком «что читать» (состав по FR-5).
+- **FAIL:** хотя бы один маршрут отсутствует или пуст.
+
+---
+
+## AC-9 — Норматив сопровождения зафиксирован (BR-7)
+
+**Условие:** правило актуальности витрины закреплено.
+- **PASS:** индекс витрины несёт норму «изменил функционал → обнови витрину в том же PR»;
+  `CLAUDE.md` содержит указатель на витрину; в ADR-001 зафиксировано, как reviewer-ось обзорных
+  доков (ORCH-079) покрывает витрину (с правкой промпта reviewer или обоснованием, что правка
+  не нужна; при правке промпта — канон 52d сохранён и `tests/test_agent_prompts_canon.py`
+  зелёный).
+- **FAIL:** норматив отсутствует в витрине, ИЛИ CLAUDE.md не обновлён, ИЛИ вопрос reviewer-оси
+  не разрешён в ADR.
+
+---
+
+## AC-10 — Анти-дрейф тесты существуют и зелёные (BR-8)
+
+**Условие:** структурный тест-модуль витрины создан и проходит.
+- **PASS:** новый тест-модуль (паттерн `test_lite_setup_doc.py`) покрывает: наличие
+  файлов/разделов витрины, сверку стадий импортом `STAGE_TRANSITIONS`, полноту 6 агентов,
+  валидность относительных ссылок, FORBIDDEN-скан (импорт запрещённых литералов из
+  `tests/test_no_host_hardcodes.py` + секрет-эвристика) по новым докам и презентационному
+  источнику, наличие ссылки на витрину в `README.md`. `pytest tests/ -q` полностью зелёный.
+- **FAIL:** тест-модуль отсутствует, ИЛИ любая из перечисленных проверок не реализована, ИЛИ
+  pytest красный.
+
+---
+
+## AC-11 — Рантайм не тронут; указатели обновлены (NFR-1, BR-9)
+
+**Условие:** изменение строго docs+tests(+опц. scripts).
+- **PASS:** diff PR не содержит изменений `src/**`, `docker-compose.yml`, `Dockerfile`,
+  `requirements*`, схемы БД; `README.md` ссылается на витрину; `CHANGELOG.md` несёт
+  `docs:`-запись по ORCH-011; в новых файлах нет секретов/боевых токенов/хост-хардкодов
+  (FORBIDDEN-скан AC-10 зелёный).
+- **FAIL:** любой файл рантайма изменён, ИЛИ указатели не обновлены, ИЛИ найден
+  секрет/хост-хардкод.
+
+---
+
+## AC-12 — Самодостаточность против вне-репозиторных источников (допущение BRD §6)
+
+**Условие:** витрина не зависит от файлов вне репо.
+- **PASS:** витрина не содержит ссылок на вне-репозиторные пути (`tasks/…`, `memory/…`,
+  локальные пути хоста); всё содержание подтверждается внутрирепозиторными источниками.
+- **FAIL:** есть ссылка на файл, отсутствующий в репозитории, или цитата «по памяти» без
+  внутрирепозиторного источника.
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-2 |
+| AC-3 | BR-3 / FR-3 |
+| AC-4 | BR-3, BR-8 / FR-3, FR-7 |
+| AC-5 | BR-3 / FR-3 |
+| AC-6 | BR-4 / FR-1, FR-3 |
+| AC-7 | BR-5 / FR-4, NFR-2 |
+| AC-8 | BR-6 / FR-5 |
+| AC-9 | BR-7 / FR-6 |
+| AC-10 | BR-8 / FR-7 |
+| AC-11 | BR-9, NFR-1, NFR-3 |
+| AC-12 | BRD §6 (допущения), NFR-3 |

docs/work-items/ORCH-011/04-test-plan.yaml

@@ -0,0 +1,117 @@
+work_item: ORCH-011
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+title: "Полная документация системы мультиагентов: структурный анти-дрейф витрины"
+framework: pytest
+scope: >
+  Покрывается: каркас витрины (файлы/разделы/маршруты/норматив), сходимость
+  машинно-проверяемых фактов с кодом (стадии из STAGE_TRANSITIONS, 6 агентов),
+  валидность внутренних ссылок, отсутствие секретов/хост-хардкодов, обновление
+  указателей README/CLAUDE.md, неизменность рантайма (полный регресс).
+  Вне покрытия: качество прозы/дизайна слайдов (проверяет reviewer/человек),
+  фактический рендеринг .pptx (ручная проверка по процедуре AC-7).
+notes: >
+  Все тесты — структурные, без сети/LLM/subprocess (паттерн tests/test_lite_setup_doc.py,
+  test_bundled_setup_doc.py, test_orch_52b_docs_standard.py). Точные пути витрины фиксирует
+  ADR-001 архитектора (рекомендация TRZ: docs/overview/); имя тест-модуля ниже —
+  tests/test_system_docs.py — может быть уточнено в ADR, состав проверок обязателен.
+  Сверки derive-из-кода (стадии) обязаны импортировать src.stages, а не дублировать
+  статичный список (анти-дрейф, образец — тест полноты ORCH-091). FORBIDDEN-скан
+  импортирует список запрещённых литералов из tests/test_no_host_hardcodes.py.
+  Полный регресс tests/ должен оставаться зелёным.
+
+tests:
+  # ---- FR-1: каркас витрины и единая точка входа ----
+  - id: TC-01
+    type: unit
+    description: "Каталог витрины и индекс существуют; индекс содержит обязательные разделы: вход «что это», ссылки на бизнес-часть и тех-часть, маршруты аудиторий, норматив сопровождения (AC-1)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Из индекса по относительным ссылкам достижимы все файлы витрины: бизнес-часть, тех-блоки 1–7, презентационный источник (AC-1/AC-3)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- FR-2: бизнес-уровень ----
+  - id: TC-03
+    type: unit
+    description: "Бизнес-часть содержит 5 обязательных смысловых разделов (проблема, решение, что умеет, ценность, сценарии) и минимум 5 сценариев использования (AC-2)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- FR-3: тех-уровень, сходимость с кодом ----
+  - id: TC-04
+    type: unit
+    description: "Тех-часть содержит все 7 блоков контент-карты (архитектура, конвейер, агенты, объекты, интеграции, качество/безопасность, наблюдаемость); блок архитектуры несёт схему потока (AC-3)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Карта стадий витрины сверена импортом src.stages.STAGE_TRANSITIONS: каждая стадия (включая deploy-staging и cancelled) упомянута; derive из кода, не статичный список (AC-4)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Имена exit-гейтов рёбер в витрине существуют в реестре qg.checks.QG_CHECKS (нет выдуманных имён гейтов) (AC-4)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Блок агентов покрывает все 6 ролей (analyst/architect/developer/reviewer/tester/deployer); каждой роли сопоставлены артефакты; таблица модель/эффорт присутствует (AC-5)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- FR-1/FR-3: link-first ----
+  - id: TC-08
+    type: unit
+    description: "Все относительные ссылки витрины резолвятся в существующие файлы; обязательные ссылки на golden sources (architecture/README, internals, PIPELINE_DOCS, HANDOFF_PROTOCOL, adr/, LITE_SETUP, BUNDLED_SETUP, PRODUCT_VISION, CLAUDE.md) присутствуют (AC-6)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Витрина не ссылается на вне-репозиторные пути (tasks/, memory/, абсолютные пути хоста) (AC-12)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- FR-4: презентационная основа ----
+  - id: TC-10
+    type: unit
+    description: "Презентационный источник существует, несёт явную слайдо-структуру (нумерованные слайды с заголовками, не менее 12) и покрывает обязательный нарратив (проблема/решение/как работает/возможности/сценарии/тираж) (AC-7)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Зависимости генерации презентации не попали в прод-образ: requirements*/Dockerfile не содержат библиотек генерации (например python-pptx) (AC-7/NFR-2)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- FR-6: норматив и указатели ----
+  - id: TC-12
+    type: unit
+    description: "Индекс витрины несёт норматив сопровождения («в том же PR»); README.md содержит ссылку на витрину; CLAUDE.md содержит указатель (AC-9/AC-11)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- NFR-3: секреты/хост-хардкоды ----
+  - id: TC-13
+    type: unit
+    description: "FORBIDDEN-скан новых доков и презентационного источника: запрещённые хост-литералы (импорт из tests/test_no_host_hardcodes.py) и секрет-эвристика не находят совпадений (AC-10/AC-11)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  # ---- Регресс ----
+  - id: TC-14
+    type: integration
+    description: "Полный регресс: pytest tests/ -q зелёный; существующие структурные док-тесты (test_lite_setup_doc, test_bundled_setup_doc, test_orch_52b_docs_standard, test_agent_prompts_canon) не сломаны (AC-10/AC-11)."
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md

@@ -0,0 +1,388 @@
+---
+work_item: ORCH-011
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Витрина системы `docs/overview/` — структура, путь к PPTX, анти-дрейф контур
+
+Work Item: **ORCH-011** — Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0039-system-overview-docs-canon.md`**
+(новый docs-раздел `docs/overview/` с нормативом сопровождения, обязательным для всех будущих
+функциональных PR, + расширение reviewer-оси обзорных доков ORCH-079 — кросс-каттинг).
+
+## Статус
+Proposed
+
+## Контекст
+
+Решения Владельца (BRD §1.4): D-1 презентация = PowerPoint, тёмный дизайн, точный рендеринг;
+D-2 три аудитории (разработчики/заказчики/менеджеры); D-3 единое место — `docs/` репозитория;
+D-4 витрина поддерживается актуальной сразу после изменения функционала.
+
+Факты, сверенные с кодом/репо на ветке задачи:
+
+- **Документация богатая, но фрагментированная** (BRD §1.2, проверено): паспорт `CLAUDE.md`
+  (реестр доработок, не вводный текст), тех-витрина `README.md`, vision
+  `docs/PRODUCT_VISION.md` (v1.0, «концепция развития»), инженерный справочник
+  `docs/architecture/README.md` (~1246 строк) + `internals.md`, 38 сквозных ADR, стандарты
+  `docs/_standards/`, операционные/деплойные доки. Единой точки входа «бизнес + тех» нет.
+- **Живое доказательство риска гниения (R-1):** схема конвейера в `docs/PRODUCT_VISION.md` §2
+  уже устарела — в ней нет стадии `deploy-staging` и стока `cancelled`, фактически
+  присутствующих в `src/stages.py::STAGE_TRANSITIONS` (9 ключей + `cancelled`). Снапшот без
+  машинной сверки расходится с кодом за недели.
+- **Прецедент бинаря без воспроизводимости:** `docs/PRODUCT_VISION.pptx` закоммичен, но пути
+  его генерации в репо нет (`grep pptx scripts/ docs/` — пусто) — ровно тот паттерн
+  «невоспроизводимый артефакт», который BR-5 требует исключить.
+- **Reviewer-ось обзорных доков (ORCH-079) по букве привязана к README:**
+  `.openclaw/agents/reviewer.md` формулирует ось через «пункт из `README.md` „Известные
+  ограничения“»; новая витрина под букву оси не подпадает (релевантно OQ-5). История ORCH-079
+  показывает: общего правила «документация = golden source» недостаточно — обзорные доки гниют,
+  пока ось не названа явно.
+- **Тестовая механика готова:** паттерны структурных доков-тестов —
+  `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py` (разделы по порядку, кирпичи,
+  скан FORBIDDEN импортом из `tests/test_no_host_hardcodes.py` (`FORBIDDEN`,
+  `find_violations`), секрет-эвристика, кросс-рефы); импорт `STAGE_TRANSITIONS` в тестах —
+  норма (ORCH-091: полнота derive из кода, не статичный список); импорт `QG_CHECKS` —
+  `tests/test_qg_registry_snapshot.py`; импорт чистых функций из `scripts/` —
+  `tests/test_bootstrap_script.py`.
+- **Источники контента самодостаточны внутри репо** (BRD §6): вне-репозиторные затравки
+  (`tasks/…`, `memory/…`) недоступны и не нужны; таблица модель/эффорт — ORCH-41/81
+  (developer=`xhigh`, tester/deployer=`medium`, прочие=`high`, все на `claude-opus-4-8`).
+- `docs/overview/` свободен (коллизий имён нет).
+
+Задача — **docs+tests (+dev-скрипт)** (паттерн ORCH-102/103): `src/**`,
+`docker-compose.yml`, `Dockerfile`, `requirements*` читаются как источник истины и НЕ меняются;
+конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
+Kill-switch не нужен: документация и dev-скрипт конвейером не исполняются (активация генерации —
+только явный запуск человеком, паттерн ORCH-009).
+
+## Решение
+
+### Сводка
+
+Создаётся новый docs-раздел **`docs/overview/`** — витрина системы: индекс `README.md`
+(точка входа, маршруты трёх аудиторий, норматив сопровождения), бизнес-часть `business.md`,
+семь тех-файлов `tech-*.md` (= 7 блоков контент-карты TRZ FR-3, link-first), слайдо-источник
+`presentation.md` + dev-скрипт `scripts/build_presentation.py` (python-pptx, вне прод-образа;
+бинарь `.pptx` НЕ коммитится — D5). Машинно-проверяемые факты витрины (стадии, гейты, агенты,
+ссылки, гигиена секретов, слайдо-структура, чистота prod-зависимостей) защищаются структурным
+`tests/test_system_docs.py` (D6). Reviewer-ось обзорных доков точечно расширяется на витрину
+(D7). Исходы всех открытых вопросов ТЗ §9 (OQ-1…OQ-5) — в D1/D4/D5/D9/D7 соответственно.
+
+### D1 (исход OQ-1) — Размещение и состав: `docs/overview/`, плоский каталог, 10 файлов
+
+**Решение: каталог `docs/overview/`** (рекомендация аналитика подтверждена). Семантика
+docs-разделов после ORCH-011: `overview/` — «что это за система и как она устроена» (читатель —
+любой из трёх аудиторий, входит впервые); `architecture/` — инженерный справочник (детали);
+`deployment/` — «как развернуть у себя» (ORCH-102/103); `operations/` — «как эксплуатировать
+наш прод»; `_standards/` — нормативы для агентов.
+
+**Состав — плоский каталог, 10 файлов** (модульность NFR-6: будущие правки точечные; плоскость —
+одна глубина относительных ссылок и простые globs в тестах; индекс — `README.md`, а не
+`index.md`: авто-рендер в web-UI Gitea, симметрия `docs/architecture/README.md`):
+
+| Файл | Содержание | Покрывает |
+|------|-----------|-----------|
+| `README.md` | индекс: «что это» в 1–2 абзацах; навигация на все части; 3 маршрута аудиторий (D8); норматив сопровождения (D8) | FR-1, FR-5, FR-6, AC-1, AC-8, AC-9 |
+| `business.md` | бизнес-уровень (D2) | FR-2, AC-2 |
+| `tech-architecture.md` | блок 1: компоненты и связи + диаграмма потока | FR-3.1, AC-3 |
+| `tech-pipeline.md` | блок 2: конвейер/стадии/гейты/под-гейты/откаты/человеческие гейты/авто-лейблы/багфикс-трек/serial gate/статусная модель Plane | FR-3.2, AC-4 |
+| `tech-agents.md` | блок 3: 6 ролей, входы/выходы/артефакты/verdict-ключи, таблица модель/эффорт, канон промптов | FR-3.3, AC-5 |
+| `tech-data-model.md` | блок 4: Project → Work-Item/Task → Jobs → Agent-runs → события/дедуп → вспомогательные таблицы; словарь терминов | FR-3.4 |
+| `tech-integrations.md` | блок 5: Plane / Gitea / LLM / Telegram | FR-3.5 |
+| `tech-quality-security.md` | блок 6: философия QG, frontmatter-контракт, security/coverage-гейты, канон секретов, self-hosting-страховки | FR-3.6 |
+| `tech-observability.md` | блок 7: live-карточка, `/queue`, `/metrics`, sidecar, журнал уроков, стоимость | FR-3.7 |
+| `presentation.md` | слайдо-источник + процедура сборки `.pptx` (D4) | FR-4, AC-7 |
+
+Один тех-блок = один файл (а не монолит `tech.md` и не два файла «business/tech»): блоки
+независимы по темпу устаревания (pipeline меняется чаще, чем интеграции), точечный PR правит
+один файл; тесту проще ассертить присутствие и непустоту каждого блока пофайлово.
+
+Привязка: BR-1, NFR-6, AC-1, AC-3.
+
+### D2 — Бизнес-уровень: текущее состояние, не vision; числа только с подтверждением
+
+**Решение: `business.md` описывает фактическое состояние платформы** (контент-минимум FR-2:
+проблема → решение → что умеет → ценность → ≥5 сценариев), переиспользуя нарратив
+`docs/PRODUCT_VISION.md` §1–2 со сверкой с кодом. Нормативные правила:
+
+- **Разделение ролей документов:** PRODUCT_VISION остаётся vision («куда идём», не трогается;
+  допустима врезка-ссылка на витрину — на усмотрение developer); `business.md` — «что есть
+  сейчас». Расхождение vision ↔ код (пример: устаревшая схема конвейера в vision §2) в витрину
+  не переносится — витрина строится от `STAGE_TRANSITIONS`.
+- **Числовые метрики** (скорость/стоимость) — только с внутрирепозиторным подтверждением либо
+  с явной атрибуцией «оценка из PRODUCT_VISION»; новые цифры не изобретать (FR-2, AC-12).
+- **Без жаргона:** кодовые идентификаторы (`ORCH-NNN`, имена функций/модулей) в основном тексте
+  не используются; термины конвейера (стадия, гейт, ревью) объясняются по-человечески; детали —
+  сносками/ссылками в тех-часть (AC-2).
+- Обязательный минимум способностей — список AC-2 (конвейер задача→прод, мультипроектность,
+  самовосстановление, пакетный авто-режим, багфикс-трек, STOP, наблюдаемость, self-hosting,
+  тираж Lite/Bundled) — каждый пункт сводится к одному абзацу простым языком.
+
+Привязка: BR-2, FR-2, AC-2, AC-12.
+
+### D3 — Тех-уровень: 7 файлов по контент-карте TRZ, link-first, согласованность с кодом
+
+**Решение: контент-карта TRZ §3 FR-3 принимается как нормативная** (обязательное содержание и
+источники истины каждого блока — таблица FR-3, в ADR не дублируется). Архитектурные уточнения:
+
+- **Link-first (BR-4, анти-«вторая правда»):** каждый файл даёт цельную картину уровня
+  «понять устройство» и ведёт ссылкой в golden source за деталями
+  (`docs/architecture/README.md`, `internals.md`, `_standards/*`, ADR-реестр, deployment-доки).
+  Запрещено копировать в витрину таблицы/списки, которые живут в golden source и меняются с
+  кодом (таблица компонентов, карта env, 22 статуса Plane). Разрешённый дубль — только
+  машинно-сверяемый тестом факт (перечень стадий, имена гейтов, 6 агентов, таблица
+  модель/эффорт) — ровно потому, что тест D6 рвёт CI при дрейфе (прецедент — key-sync TC-02b
+  ORCH-102).
+- **`tech-architecture.md` несёт одну диаграмму потока** «вебхук → очередь → агент → гейт →
+  переход» (mermaid или ASCII — на выбор developer; AC-3 требует хотя бы одну).
+- **`tech-pipeline.md`:** схема стадий включает `deploy-staging` и сток `cancelled`; под-гейты
+  ребра `deploy-staging→deploy` перечисляются в фактическом порядке **security → merge →
+  coverage → image-freshness** (нормативный порядок — adr-0029/ORCH-027) и явно помечаются как
+  **врезки в переход, а не стадии** (AC-4); под-гейт `deploy→done` (merge-verify) — аналогично;
+  человеческие гейты (Approved, Confirm Deploy) и их снятие авто-лейблами (ORCH-089), STOP
+  (ORCH-090), багфикс-маршрут (ORCH-019), serial gate/freeze (ORCH-088); «статусы Plane =
+  индикация ≠ управление» (ORCH-066).
+- **`tech-agents.md`:** паспорт каждой из 6 ролей по `PIPELINE_DOCS.md` §2 (назначение, стадия,
+  вход, артефакты, machine-verdict ключ — имена байт-в-байт: `verdict:`/`result:`/
+  `staging_status:`/`deploy_status:`/`security_status:`); таблица модель/эффорт = фактический
+  резолв config (ORCH-41/74/81).
+- **Терминология** едина со статусной моделью Plane (ORCH-066) и PIPELINE_DOCS (NFR-4); язык —
+  русский.
+
+Привязка: BR-3, BR-4, FR-3, AC-3…AC-6.
+
+### D4 (исход OQ-2) — Презентация: `presentation.md` (машинно-парсимый источник) + `scripts/build_presentation.py` на python-pptx
+
+**Решение: слайдо-источник — `docs/overview/presentation.md`** с жёсткой машинно-парсимой
+структурой:
+
+```markdown
+## Слайд N: <Заголовок>
+- <тезис 1>            (3–6 тезисов на слайд)
+- <тезис 2>
+> Визуал: <подпись визуального мотива слайда>   (опционально)
+```
+
+Нумерация сквозная с 1; объём — **14–18 слайдов** (в коридоре ориентира FR-4 12–20);
+нормативные смысловые биты нарратива (порядок FR-4): проблема → решение → как работает
+(конвейер+гейты) → роли агентов → человек в контуре → возможности (автономный пакетный режим,
+багфикс-трек, самовосстановление, наблюдаемость) → сценарии → тираж → статус платформы.
+Точная нарезка по слайдам — за developer; тест D6 ассертит структуру и биты, не прозу.
+
+**Генератор — `scripts/build_presentation.py` на `python-pptx`:**
+
+- **Запуск только вне рантайма** (host/dev venv, явный запуск человеком — паттерн ORCH-009);
+  `python-pptx` НЕ добавляется в `requirements*`/`Dockerfile` (NFR-2; машинный гард — D6 TC-09).
+- **Архитектура скрипта:** чистая функция-парсер `parse_slides(text) -> list[Slide]`
+  (stdlib-only, без импорта pptx) + рендерер с **ленивым** `import pptx` внутри функции сборки.
+  Один парсер = один источник истины о формате: `tests/test_system_docs.py` импортирует
+  `parse_slides` (механика импорта из `scripts/` — прецедент `test_bootstrap_script.py`) и
+  валидирует слайдо-источник без установленного python-pptx.
+- **Тёмный дизайн (D-1):** константы темы в скрипте — тёмный фон (≈`#1F1F2E`), светлый текст,
+  один акцентный цвет; шрифты — стандартные системные с полной кириллицей (Calibri/Arial).
+  python-pptx пишет **настоящий редактируемый текст** в slide-объекты → «точный рендеринг»
+  гарантирован самим PowerPoint (а не headless-браузером), кириллица не растрируется, Владелец
+  может править слайды руками.
+- **Процедура — в `presentation.md`**, раздел «Как собрать .pptx», форма «fenced-команда +
+  Проверка:» (канон LITE_SETUP): создать venv → `pip install python-pptx` → запуск скрипта →
+  проверка (скрипт печатает число собранных слайдов; файл открывается, тема тёмная). Дефолтный
+  выход — `build/orchestrator-overview.pptx` (D5).
+
+**Почему python-pptx, а не альтернативы:** Marp → pptx требует Node+Chromium и экспортирует
+слайды растровыми картинками (нередактируемо, текст не выделяется — против «точного
+рендеринга» как редактируемого артефакта); pandoc → pptx ограниченно управляет тёмной темой
+(reference-doc с мастер-слайдами — отдельный бинарный артефакт в репо); «только ручная
+процедура» — слабейшая воспроизводимость (человек = источник дрейфа). python-pptx: один
+pip-пакет в одноразовом dev-venv, детерминированный код-как-дизайн, тестируемый парсер.
+
+Привязка: BR-5, FR-4, AC-7, NFR-2.
+
+### D5 (исход OQ-3) — Бинарь `.pptx` НЕ коммитится; источник истины — markdown + скрипт
+
+**Решение: собранный `.pptx` в git НЕ коммитится.** Канон: источник истины —
+`presentation.md` + `build_presentation.py`; артефакт собирается по требованию за одну команду.
+Обоснование: бинарь не диффуем, анти-дрейф тесты его содержимое не проверяют → закоммиченный
+deck молча устаревает относительно источника (живой пример — `docs/PRODUCT_VISION.pptx`:
+закоммичен, пути генерации нет, контент vision уже разошёлся с кодом); BR-5 требует
+воспроизводимость пути, не бинарь (BRD §6).
+
+- Дефолтный выход генератора — `build/orchestrator-overview.pptx`; в `.gitignore` добавляется
+  строка `build/` (разрешённое отклонение диффа, не рантайм).
+- **Существующий `docs/PRODUCT_VISION.pptx` не трогается** (артефакт другого work item;
+  ретроактивная чистка — вне объёма §2.2). Новый канон действует на витрину и вперёд.
+
+Привязка: BR-5, AC-7, BRD §6.
+
+### D6 (FR-7) — Анти-дрейф контур: `tests/test_system_docs.py`
+
+**Решение: один структурный модуль, детерминированный, без сети/LLM/subprocess** (образец —
+`test_lite_setup_doc.py`/`test_bundled_setup_doc.py`). Нормативные семейства проверок (точная
+нарезка по тест-функциям — за developer, `04-test-plan.yaml` дополняется на development):
+
+| TC | Проверка | Механика |
+|----|----------|----------|
+| TC-01 | Все 10 файлов витрины D1 существуют и непусты | `Path.exists()` + размер |
+| TC-02 | Индекс: 3 маршрута аудиторий («Я заказчик» / «Я менеджер» / «Я разработчик») и норматив сопровождения присутствуют; из индекса по относительным ссылкам достижимы business / все 7 tech / presentation (AC-1) | regex-извлечение ссылок + подстроки |
+| TC-03 | **Карта стадий = код:** каждый ключ `src.stages.STAGE_TRANSITIONS` (вкл. `deploy-staging`, `cancelled`) упомянут в `tech-pipeline.md`; порядок основной цепочки created→…→done — по возрастанию позиций вхождений; derive из импорта, не статичный список (паттерн ORCH-091) | `import src.stages` + поиск позиций |
+| TC-04 | **Гейты = код:** имя exit-гейта каждого ребра (`qg` из `STAGE_TRANSITIONS`) упомянуто в `tech-pipeline.md`; под-гейты названы фактическими именами реестра `QG_CHECKS` (`check_security_gate`, `check_branch_mergeable`, `check_coverage_gate`, `check_staging_image_fresh`) и идут в нормативном порядке security → merge → coverage → image-freshness (порядок — фикс adr-0029, позиционный ассерт); рядом с под-гейтами есть маркер «не стадии» (врезки) | импорт `STAGE_TRANSITIONS` + `QG_CHECKS`, позиции подстрок |
+| TC-05 | **Полнота 6 агентов:** derive из glob `.openclaw/agents/*.md` (не статичный список) — стем каждого файла упомянут в `tech-agents.md`; таблица эффортов сходится с config-дефолтами (поля class-default `agent_effort_<role>`, ORCH-81) | glob + `import src.config` |
+| TC-06 | **Валидность ссылок:** все относительные md-ссылки всех файлов витрины резолвятся в существующие файлы; обязательный список ссылок AC-6 (architecture/README, internals, PIPELINE_DOCS, HANDOFF_PROTOCOL, adr-реестр, LITE_SETUP, BUNDLED_SETUP, PRODUCT_VISION, CLAUDE.md) присутствует | regex `\[..\]\((..)\)` + `Path.exists()` относительно файла |
+| TC-07 | **Гигиена:** полнотекстовый скан всех 10 файлов витрины — нет литералов центрального списка `FORBIDDEN` (импорт из `tests/test_no_host_hardcodes.py`, не копия) и секретоподобных значений (эвристика hex/base64 ≥ 32 симв., не плейсхолдер); нет ссылок на вне-репозиторные пути (`tasks/`, `memory/`) (AC-12) | `find_violations` + эвристика |
+| TC-08 | **Слайдо-источник:** парс через `parse_slides` из `scripts/build_presentation.py` (один парсер — D4): ≥ 12 слайдов, нумерация сквозная с 1, на каждом ≥ 1 тезис; нормативные биты нарратива FR-4 присутствуют (подстроки: проблема/решение/сценарии/тираж/статус) | импорт чистой функции (прецедент `test_bootstrap_script.py`) |
+| TC-09 | **NFR-2 машинно:** подстрока `pptx` отсутствует в `requirements*` и `Dockerfile` | чтение файлов |
+| TC-10 | **Указатели:** `README.md` ссылается на `docs/overview/`; `CLAUDE.md` несёт указатель на витрину; `CHANGELOG.md` несёт `ORCH-011` | подстроки |
+
+Скоуп FORBIDDEN-скана — **полнотекстовый** (не только fenced, в отличие от ORCH-102 TC-05):
+витрина по построению не дублирует дефолты/хост-специфику даже в прозе (NFR-3), упоминать
+боевые литералы ей незачем → ложно-красных нет, а защита шире. Существующие тесты не
+ослабляются; новые попадают в существующие гейты (`check_ci_green`/`check_tests_passed`/
+merge-gate re-test/coverage ORCH-027) автоматически — **новый QG НЕ регистрируется** (ТЗ §6).
+
+Привязка: BR-8, FR-7, AC-4, AC-5, AC-10, AC-11, AC-12.
+
+### D7 (исход OQ-5) — Reviewer-ось обзорных доков: точечная правка промпта НУЖНА
+
+**Решение: расширить существующую ось ORCH-079 в `.openclaw/agents/reviewer.md` точечной
+врезкой, называющей витрину явно.** Обоснование: по букве ось привязана к `README.md`
+«Известные ограничения» («если PR закрывает/меняет пункт из README…»); витрина под букву не
+подпадает, а история ORCH-079 показала, что общего правила «документация = golden source»
+для обзорных доков недостаточно — ось работает, когда названа явно (❌→✅-паттерн). Норматив
+правки:
+
+- В оси 4 «Документация» и в соответствующем ❌→✅-пункте `<constraints>` существующая
+  формулировка ORCH-079 дополняется: *PR меняет функциональность, описанную в витрине
+  `docs/overview/` (стадии, гейты, агенты, интеграции, способности из business.md), а витрина
+  не обновлена → finding ≥ P1* — **расширение трактовки той же оси, не новая ось**.
+- Канон 52d сохраняется байт-в-байт: 5 XML-секций и их порядок не меняются, verdict-ключ
+  `verdict: APPROVED|REQUEST_CHANGES` не трогается; правка — добавление текста внутрь
+  существующих секций (паттерн самой ORCH-079).
+- `tests/test_agent_prompts_canon.py` расширяется ассертом на упоминание витрины в оси
+  обзорных доков (анти-регресс; существующие ассерты остаются зелёными).
+- Зеркальная правка правила №6 `CLAUDE.md` («Reviewer проверяет…») — упоминание витрины.
+
+Привязка: BR-7, FR-6, AC-9.
+
+### D8 — Индекс: маршруты аудиторий и норматив сопровождения; указатели репо
+
+**Маршруты (FR-5, нормативный состав):** индекс несёт три явных маршрута с упорядоченными
+списками «что читать»:
+- **«Я заказчик»:** `business.md` → сценарии → `presentation.md` →
+  `docs/deployment/LITE_SETUP.md`/`BUNDLED_SETUP.md`;
+- **«Я менеджер проекта»:** `business.md` → `tech-pipeline.md` (конвейер, статусная модель
+  Plane, человеческие гейты) → `tech-observability.md`;
+- **«Я разработчик»:** `tech-*` (1→7) → `docs/architecture/README.md` → `internals.md` →
+  `docs/_standards/` → реестр ADR → `CLAUDE.md`.
+
+**Норматив сопровождения (FR-6, формулировка по образцу NFR-5 ORCH-102/103):** в индексе —
+явная норма «**изменил функциональность платформы → обнови витрину `docs/overview/` в том же
+PR**» (+ указание, какой файл какому классу изменений соответствует). Указатели:
+- `CLAUDE.md`: в правило №2 («Документация = golden source») добавляется указатель на витрину
+  и норматив; правка правила №6 — D7; строка о витрине в разделе «Структура» (`docs/`).
+- `README.md`: ссылка на витрину в начале (рядом с «Архитектура») — «единая точка входа в
+  документацию системы».
+- `CHANGELOG.md`: запись `docs:` по ORCH-011.
+
+Привязка: BR-6, BR-7, BR-9, FR-5, FR-6, AC-8, AC-9, AC-11.
+
+### D9 — Границы изменения; 07/08 — N/A; исход OQ-4; эскалация не требуется
+
+- **Дифф задачи:** `docs/overview/` (10 файлов, D1), `tests/test_system_docs.py` (D6),
+  `scripts/build_presentation.py` (D4), правки `.openclaw/agents/reviewer.md` +
+  `tests/test_agent_prompts_canon.py` (D7), `README.md`/`CLAUDE.md`/`CHANGELOG.md` (D8),
+  `.gitignore` (+`build/`, D5), ADR-пакет work item + сквозной adr-0039 + секция в
+  `docs/architecture/README.md`. **`src/**`, `docker-compose.yml`, `Dockerfile`,
+  `requirements*` — ноль изменений** (NFR-1; машинный гард — TC-09); любое отклонение — только
+  новым ADR.
+- `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — байт-в-байт; новых
+  эндпоинтов/флагов/kill-switch нет (выключать нечего: доки и dev-скрипт не исполняются
+  конвейером).
+- **`07-infra-requirements.md` / `08-data-requirements.md` — N/A** (прецедент ORCH-102 D9):
+  топология не меняется (ни контейнера, ни порта, ни маунта), схема БД не меняется (ТЗ §5).
+  Dev-venv для генерации `.pptx` — не инфра-предусловие конвейера: создаётся ad-hoc человеком
+  при сборке презентации (процедура — `presentation.md`).
+- **Исход OQ-4 (compiled-wiki/экспорт):** вне объёма v1 — зафиксировано; репозиторий —
+  единственный источник истины («канон не форкается», ORCH-009 BR-2). Follow-up work item не
+  заводится автоматически: потребность в wiki-экспорте — решение Владельца после приёмки
+  витрины (если витрина в репо закрывает D-2/D-3, экспорт не нужен вовсе).
+- **Объём одного прогона (R-3):** допущение BRD §6 принимается; приоритет при дефиците объёма:
+  каркас+индекс → tech-pipeline/tech-agents (машинно-сверяемые) → business → остальные tech →
+  presentation+скрипт. Молчаливое сокращение запрещено — недоезд = эскалация разбиением.
+- **Self-hosting (NFR-5):** прод-контейнер не рестартится; выкат — штатный конвейер
+  (deploy-staging 8501 → Confirm Deploy). Для enduro-trails изменение инертно (общих
+  артефактов нет).
+- **Эскалация:** `arch:major-change` не требуется (нет новой стадии/компонента/смены БД —
+  docs-канон); ТЗ удовлетворимо без нарушения принципов — возврат в анализ не нужен.
+
+## Альтернативы
+
+- **Расширить `README.md` вместо нового раздела** — отвергнуто: README — тех-витрина с
+  собственной ролью (и осью ORCH-079); бизнес-уровень + 7 блоков + маршруты раздули бы его в
+  монолит против NFR-6; D-3 предполагает выделенное «единое место».
+- **`docs/system/` как имя каталога** — отвергнуто: «overview» точнее передаёт роль (обзор для
+  входа), рекомендация аналитика, прецедентов коллизии нет.
+- **Монолит `tech.md` (или пара business/tech)** — отвергнуто: блоки устаревают с разным
+  темпом; точечные правки и пофайловые ассерты тестов дешевле на 7 файлах (NFR-6).
+- **Marp / pandoc для PPTX** — отвергнуто (D4): Node+Chromium-тулчейн и растровые слайды
+  (Marp) / ограниченная тёмная тема через бинарный reference-doc (pandoc); python-pptx даёт
+  редактируемый текст и код-как-дизайн с одним pip-пакетом вне прод-образа.
+- **Коммитить собранный `.pptx`** — отвергнуто (D5): недиффуемый, тестами не проверяемый,
+  молча устаревает (живой пример — `PRODUCT_VISION.pptx` без пути генерации); BR-5 требует
+  воспроизводимость, не бинарь.
+- **Жёсткий снапшот-тест контента витрины (хэши/полные списки компонентов)** — отвергнуто:
+  превратил бы каждую docs-правку в красный CI (ложная жёсткость); тесты держат только
+  машинно-проверяемые факты, derive из кода (стадии/гейты/агенты), остальное — за reviewer.
+- **Не править промпт reviewer (положиться на общее правило)** — отвергнуто (D7): по букве ось
+  ORCH-079 привязана к README; сам ORCH-079 существует потому, что общего правила для обзорных
+  доков не хватило; одна строка расширения дешевле гниющей витрины.
+- **Автогенерация витрины из кода (autodoc)** — отвергнуто: явно вне объёма (BRD §2.2);
+  derive-from-code остаётся в тестах (сверка), не в генерации текста.
+
+## Последствия
+
+- **+** Единая точка входа для трёх аудиторий закрывает корневую проблему фрагментации
+  (BRD §1.2); презентация собирается за одну команду из версионируемого источника.
+- **+** Машинно-проверяемые факты витрины (стадии/гейты/агенты/ссылки/гигиена/чистота
+  prod-зависимостей) — CI-гарантии (TC-01…TC-10), а не обещания: дрейф ловится тестом, гниение
+  прозы — расширенной reviewer-осью (D7).
+- **+** Нулевой риск рантайма: docs+tests+dev-скрипт, конвейер байт-в-байт, kill-switch не
+  нужен; для enduro-trails инертно.
+- **−** Новый golden source = новая обязанность сопровождения каждого функционального PR —
+  принято осознанно (в этом смысл задачи), митигировано link-first (правится одна строка-резюме,
+  не трактат), нормативом в индексе/CLAUDE.md и осью reviewer.
+- **−** Разрешённый машинно-сверяемый дубль (стадии/гейты/агенты в `tech-pipeline.md`/
+  `tech-agents.md`) — двойная запись фактов кода; защищён derive-тестами TC-03…TC-05
+  (прецедент TC-02b ORCH-102).
+- **−** Правка промпта reviewer — расширение поверхности канона 52d; митигировано: только
+  добавление внутрь существующих секций, анти-регресс `test_agent_prompts_canon.py`.
+- **−** `.pptx` не в репо — показ «здесь и сейчас» требует одной команды сборки; принято
+  (Владелец собирает deck при необходимости; альтернатива — гниющий бинарь — хуже).
+- **Откат:** удалить `docs/overview/`, `tests/test_system_docs.py`,
+  `scripts/build_presentation.py`, вернуть точечные правки README/CLAUDE/CHANGELOG/.gitignore/
+  reviewer.md — состояние 1:1, ни миграций, ни состояния (ТЗ §7).
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-011/01-brd.md` (решения Владельца D-1…D-4, факты §1.2)
+- TRZ: `docs/work-items/ORCH-011/02-trz.md` (FR-1…FR-7, OQ-1…OQ-5)
+- Acceptance: `docs/work-items/ORCH-011/03-acceptance-criteria.md` (AC-1…AC-12)
+- Риски: `docs/work-items/ORCH-011/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0039-system-overview-docs-canon.md`
+- Сверено по коду/репо: `src/stages.py::STAGE_TRANSITIONS` (9 стадий + `cancelled`),
+  `src/qg/checks.py::QG_CHECKS` (14 проверок), `.openclaw/agents/*.md` (6 промптов; ось
+  ORCH-079 в `reviewer.md`), `docs/PRODUCT_VISION.md` §1–2 (+ устаревшая схема конвейера §2),
+  `docs/PRODUCT_VISION.pptx` (бинарь без пути генерации), `tests/test_lite_setup_doc.py` /
+  `test_bundled_setup_doc.py` (паттерн структурных доков-тестов),
+  `tests/test_no_host_hardcodes.py` (`FORBIDDEN`, `find_violations`),
+  `tests/test_qg_registry_snapshot.py` (импорт QG_CHECKS), `tests/test_bootstrap_script.py`
+  (импорт чистых функций из `scripts/`), `.gitignore`
+- Инварианты соседних решений: adr-0019 (стандарт доков), adr-0021/ORCH-092 (канон промптов
+  52d), adr-0023 (ось обзорных доков ORCH-079), adr-0029 (порядок под-гейтов), adr-0037/0038
+  (deployment-каноны — ссылаемся, не форкаем), ORCH-041/074/081 (модель/эффорт),
+  ORCH-066 (статусная модель), `docs/_standards/PIPELINE_DOCS.md` §4 (ADR-naming),
+  `docs/_standards/TRACEABILITY.md` (маркеры)

docs/work-items/ORCH-011/10-tech-risks.md

@@ -0,0 +1,40 @@
+---
+work_item: ORCH-011
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-011 — Полная документация системы мультиагентов (витрина + PPTX)
+
+Work Item: **ORCH-011** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+> Базовые бизнес-риски R-1…R-5 — BRD §8; здесь — их техническая детализация + новые.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Гниение витрины** (R-1): self-hosting темп быстро устаревает снапшот; живой пример уже в репо — схема конвейера в `PRODUCT_VISION.md` §2 потеряла `deploy-staging`/`cancelled` | Выс. | Сред. | Машинно-проверяемые факты держат derive-тесты (ADR-001 D6 TC-03…TC-05: стадии/гейты/агенты импортом из кода); проза — норматив сопровождения в индексе + расширенная reviewer-ось (D7); link-first сводит правку к одной строке-резюме |
+| TR-2 | **Второй источник истины** (R-2): дубль деталей architecture/README в витрине → противоречия | Сред. | Сред. | Норматив D3: запрещён дубль живых таблиц golden sources; разрешённый дубль — только машинно-сверяемый тестом факт (прецедент key-sync ORCH-102 TC-02b); контроль — AC-6 + reviewer |
+| TR-3 | **Объём одного прогона** (R-3): 10 файлов + скрипт + тесты + правка промпта могут не поместиться в разумный PR | Сред. | Сред. | Модульность D1 (правки независимы); нормативный приоритет блоков при дефиците (D9); молчаливое сокращение запрещено — эскалация разбиением по штатному маршруту |
+| TR-4 | **Утечка зависимости генерации в прод-образ** (R-4): `python-pptx` случайно попадает в `requirements*`/`Dockerfile` | Низ. | Выс. | Архитектура скрипта D4 (lazy import, запуск только вне рантайма); **машинный гард TC-09** (скан `requirements*`/`Dockerfile` на `pptx`) — попадание рвёт CI |
+| TR-5 | **Ложная жёсткость анти-дрейф тестов:** слишком буквальные ассерты (точные фразы прозы) делают каждую будущую docs-правку красной → тесты начнут ослаблять | Сред. | Сред. | D6: ассерты только на стабильное (заголовки, имена из кода через импорт, относительные ссылки, биты-подстроки); снапшот-контента отвергнут явно (ADR-001 «Альтернативы») |
+| TR-6 | **Регресс канона 52d при правке промпта reviewer** (D7): нарушение порядка секций / verdict-ключа | Низ. | Выс. | Правка — только добавление текста внутрь существующих секций (паттерн ORCH-079); анти-регресс `tests/test_agent_prompts_canon.py` (существующие ассерты + новый на упоминание витрины) |
+| TR-7 | **Кириллица/тема в PPTX:** артефакт собирается, но рендеринг не «точный» (D-1): шрифт без кириллицы, контраст темы | Низ. | Сред. | python-pptx пишет редактируемый текст (не растр); шрифты — системные с полной кириллицей (Calibri/Arial); процедура в `presentation.md` несёт явную «Проверка:» (открыть файл, тема тёмная, кириллица читается); приёмка — AC-7 |
+| TR-8 | **Парсер слайдо-источника расходится с тестом:** свой regex в тесте ≠ парсер скрипта → источник валиден для теста, но не собирается | Низ. | Сред. | Один парсер: тест импортирует `parse_slides` из `scripts/build_presentation.py` (D4/D6 TC-08; прецедент импорта из scripts — `test_bootstrap_script.py`) |
+| TR-9 | **Цифры в бизнес-части не подтверждаются репо** (метрики скорости/стоимости из vision) → витрина теряет доверие / выдаёт желаемое за действительное | Сред. | Низ. | Норматив D2: числа только с внутрирепозиторным подтверждением или явной атрибуцией «оценка из PRODUCT_VISION»; новые цифры не изобретать (AC-12; reviewer проверяет) |
+| TR-10 | **Путаница канона бинарей:** в репо остаётся `docs/PRODUCT_VISION.pptx` (старый паттерн), новый канон — «бинарь не коммитим» (D5) → будущий агент скопирует старый паттерн | Низ. | Низ. | Канон зафиксирован сквозным adr-0039 + нормативом в `presentation.md`; PRODUCT_VISION.pptx не трогается (чужой артефакт), но прецедентом не является — явная оговорка в ADR-001 D5 |
+
+## Сводный вывод
+
+Доминирующий класс — **риски сопровождения документации** (TR-1/TR-2/TR-5): изменение не несёт
+рантайм-риска вовсе (docs+tests+dev-скрипт, `src/**` байт-в-байт, машинный гард TC-09), но
+создаёт новый golden source, который без машинной сверки и явной reviewer-оси начал бы гнить с
+первой же задачи. Митигация встроена в само решение (derive-тесты + link-first + норматив +
+ось D7). Эскалация `arch:major-change` не требуется (нет новой стадии/компонента/смены БД);
+возврат в анализ не нужен. Остаточный риск для прод-конвейера (self-hosting): **низкий** —
+прод-контейнер не затрагивается, деплой штатным маршрутом, для enduro-trails изменение инертно.

docs/work-items/ORCH-011/12-review.md

@@ -0,0 +1,106 @@
+---
+verdict: APPROVED
+work_item: ORCH-011
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-011
+version: 1
+---
+
+# Review ORCH-011
+
+## Summary
+
+PR (`7f0298b`, ветка `feature/ORCH-011-`) создаёт витрину системы `docs/overview/` строго по
+ADR-001 (D1–D9): 10 файлов плоского каталога (индекс + business + 7×tech-* + presentation),
+dev-скрипт `scripts/build_presentation.py` (stdlib-парсер `parse_slides` + ленивый `import pptx`),
+структурный анти-дрейф `tests/test_system_docs.py`, точечное расширение reviewer-оси ORCH-079 на
+витрину (D7) + анти-регресс ассерт, указатели README/CLAUDE.md/PRODUCT_VISION/CHANGELOG,
+сквозной `adr-0039` + секция в `docs/architecture/README.md`, `build/` в `.gitignore` (D5).
+
+Проверено по 4 осям:
+
+1. **Соответствие ТЗ (FR-1…FR-7, AC-1…AC-12)** — выполнено, детальная сверка ниже. Все 12 AC — PASS.
+2. **Соответствие ADR** — реализация 1:1 с ADR-001 D1–D9 и adr-0039; исходы OQ-1…OQ-5 воплощены
+   (каталог `docs/overview/`, python-pptx вне прод-образа, бинарь не закоммичен, OQ-4 вне объёма,
+   правка промпта reviewer по канону 52d). Глобальные ADR не нарушены: канон 52d (adr-0021) —
+   5 секций/порядок/verdict-ключ целы (зелёный `test_agent_prompts_canon.py`); ось ORCH-079
+   (adr-0023) — расширена аддитивно, не ослаблена; порядок под-гейтов (adr-0029) в витрине —
+   фактический security → merge → coverage → image-freshness (позиционный тест).
+   **Трассировка (TRACEABILITY):** правка блока с чужим маркером ORCH-079 в `reviewer.md` сверена
+   с его ADR — инвариант не сломан, расширение зафиксировано собственным D7 + тестом.
+3. **Качество кода** — `tests/test_system_docs.py`: 20 содержательных тест-функций, derive-сверки
+   импортом `STAGE_TRANSITIONS`/`QG_CHECKS`/glob промптов/class-default'ов config (не статика),
+   границы токенов стадий (`deploy` не матчится в `deploy-staging`), негативный самочек
+   секрет-эвристики, анти-выдумка имён гейтов по всем 10 файлам. `build_presentation.py` —
+   докстринги на всех публичных функциях, честные коды возврата, ImportError-подсказка.
+   **Полный регресс: `pytest tests/ -q` → 1873 passed, 0 failed.**
+4. **Документация** — обновлена в том же PR (см. раздел ниже). `src/**` НЕ изменён
+   (docs+tests+dev-скрипт), P0-правило «src без доки» неприменимо и не нарушено.
+
+Сверка машинных фактов витрины с кодом (независимо от тестов):
+- стадии/exit-гейты таблицы `tech-pipeline.md` = `src/stages.py::STAGE_TRANSITIONS` байт-в-байт
+  (`check_analysis_approved` … `check_deploy_status`, `done`/`cancelled` — терминалы);
+- таблица модель/эффорт `tech-agents.md` = `src/config.py` (default `claude-opus-4-8`;
+  developer=`xhigh`, tester/deployer=`medium`, прочие=`high`);
+- verdict-ключи ролей (`verdict:`/`result:`/`staging_status:`/`deploy_status:`) = канон AC-5;
+- бинарь `.pptx` в diff отсутствует; `pptx` в `requirements*`/`Dockerfile` отсутствует (NFR-2);
+- `docker-compose.yml`/`Dockerfile`/`requirements*`/схема БД/`QG_CHECKS` — ноль изменений (AC-11).
+
+## Findings
+
+### P0 — Blocker
+Нет.
+
+### P1 — Must fix
+Нет.
+
+### P2 — Should fix
+Нет.
+
+### P3 — Nice to have
+- [ ] `docs/overview/tech-pipeline.md`, раздел «Статусная модель Plane»: «Управляющих статусов
+  ровно три: запуск в работу, Approved/Confirm Deploy … и STOP» — фактически перечислены четыре
+  статуса в трёх группах; формулировка «три управляющих воздействия (запуск, человеческие гейты,
+  отмена)» была бы точнее. Косметика прозы, машинных фактов не искажает (привязка: AC-4/FR-3.2 —
+  согласованность трактовок; не блокирует).
+- [ ] `04-test-plan.yaml` не дополнен на development (норматив ADR-001 D6 «точная нарезка по
+  тест-функциям — за developer, 04-test-plan.yaml дополняется на development»). Решение developer
+  консервативно-корректное: правило №3 CLAUDE.md запрещает править артефакты других этапов, а все
+  TC-01…TC-14 плана реализованы 1:1 (маппинг «план TC-NN» зафиксирован в докстрингах
+  `test_system_docs.py`, TC-14 = полный зелёный регресс) — tester может работать по плану как есть.
+  Фиксирую как observation для будущего уточнения норматива, не как дефект.
+
+## Сверка по критериям приёмки
+
+| AC | Вердикт | Основание |
+|----|---------|-----------|
+| AC-1 точка входа | PASS | индекс `docs/overview/README.md`; все части достижимы (тест `test_index_links_reach_every_showcase_part`) |
+| AC-2 бизнес-уровень | PASS | 5 разделов + 6 сценариев (≥5); без необъяснённого жаргона; цифра «35 минут» с атрибуцией Product Vision (D2) |
+| AC-3 7 тех-блоков | PASS | 7 файлов `tech-*`; ASCII-схема потока «вебхук → очередь → агент → гейт → переход» в блоке 1 |
+| AC-4 стадии/гейты = код | PASS | сверено с `src/stages.py` напрямую + derive-тесты (стадии, порядок цепочки, имена гейтов, порядок под-гейтов, маркер «не стадии») |
+| AC-5 6 агентов | PASS | паспорта ролей + verdict-ключи + таблица модель/эффорт = config (сверено с `src/config.py`) |
+| AC-6 link-first | PASS | все 9 обязательных golden-source ссылок присутствуют и резолвятся (тесты); живые таблицы не форкнуты |
+| AC-7 презентация | PASS | 16 слайдов «## Слайд N:», нарратив полный; процедура «команда + Проверка:» ×3 шага; `pptx` вне прод-образа; бинарь не закоммичен |
+| AC-8 3 маршрута | PASS | «Я заказчик / Я менеджер / Я разработчик» с упорядоченными списками по FR-5/D8 |
+| AC-9 норматив | PASS | норма «в том же PR» + таблица «класс изменения → файл» в индексе; CLAUDE.md правила №2/№6; D7 разрешён правкой промпта + тест |
+| AC-10 анти-дрейф | PASS | `tests/test_system_docs.py` покрывает все семейства D6; `pytest tests/ -q` → 1873 passed |
+| AC-11 рантайм не тронут | PASS | diff: ноль изменений `src/**`/compose/Dockerfile/requirements; указатели обновлены; FORBIDDEN-скан зелёный |
+| AC-12 самодостаточность | PASS | запрет `tasks/`/`memory/` — тест зелёный; источники внутрирепозиторные |
+
+## Документация
+
+Изменение само является документационным; все сопутствующие обязательства выполнены в том же PR:
+
+- **Обновлено:** `CHANGELOG.md` (детальная `docs:`-запись ORCH-011), `README.md` (ссылка на
+  витрину), `CLAUDE.md` (строка «Структура», правила №2 и №6), `docs/PRODUCT_VISION.md`
+  (врезка-ссылка «фактическое состояние — витрина», vision не переписан — по ТЗ §2),
+  `docs/architecture/README.md` (секция витрины), ADR-пакет: work-item
+  `06-adr/ADR-001-system-overview-canon.md` + сквозной `adr-0039-system-overview-docs-canon.md`.
+- **Обзорные доки (ORCH-079):** «Известные ограничения» README данный PR не закрывает —
+  обновления не требуется. Сама ось расширена на новую витрину (D7) с анти-регресс тестом.
+- **Дополнительно обновлять нечего:** API/env/конфигурация/QG/схема БД не менялись (ТЗ §4–§6).

docs/work-items/ORCH-011/13-test-report.md

@@ -0,0 +1,79 @@
+---
+result: PASS
+work_item: ORCH-011
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-011
+---
+
+# Test Report — ORCH-011
+
+Полная документация системы мультиагентов: витрина `docs/overview/` + структурный анти-дрейф.
+
+## Окружение
+- Worktree (код ветки): `/repos/_wt/orchestrator/feature_ORCH-011-` (ветка `feature/ORCH-011-`)
+- Python: 3.12.13
+- pytest: 8.3.3
+- Дата: 2026-06-11
+- Предусловие: `12-review.md` → `verdict: APPROVED` ✅
+
+## Smoke API (read-only)
+| Эндпоинт | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — задача ORCH-011 активна на стадии `testing` |
+| `GET /queue` | PASS — payload несёт блоки `serial_gate` (ORCH-088) **и** `auto_labels` (наряду с `coverage`/`stop`/`bug_fast_track`/`lessons`) — регресса смока нет |
+
+## Результаты (покрытие test-plan ↔ acceptance-criteria)
+
+Изменение — docs+tests+dev-скрипт; анти-дрейф витрины реализован в `tests/test_system_docs.py`
+(28 содержательных тест-функций), полностью зелёном. Каждый TC из `04-test-plan.yaml` выполнен и
+сопоставлен с критериями `03-acceptance-criteria.md`.
+
+| TC ID | Описание | AC | Тест-функция(и) `test_system_docs.py` | Результат |
+|-------|----------|----|----------------------------------------|-----------|
+| TC-01 | Каталог витрины + индекс с обязательными разделами | AC-1 | `test_all_showcase_files_exist_and_nonempty`, `test_index_carries_maintenance_normative` | PASS |
+| TC-02 | Из индекса достижимы все части витрины | AC-1/AC-3 | `test_index_links_reach_every_showcase_part` | PASS |
+| TC-03 | Бизнес-часть: 5 разделов + ≥5 сценариев | AC-2 | `test_business_part_has_five_mandatory_sections`, `test_business_part_has_at_least_five_scenarios` | PASS |
+| TC-04 | Тех-часть: 7 блоков + схема потока | AC-3 | `test_architecture_block_carries_flow_diagram` (+ link-reach) | PASS |
+| TC-05 | Стадии сверены импортом `STAGE_TRANSITIONS` (derive) | AC-4 | `test_every_stage_from_code_is_mentioned_in_pipeline_doc`, `test_main_chain_order_in_pipeline_doc_matches_code` | PASS |
+| TC-06 | Имена exit-гейтов существуют в `QG_CHECKS` | AC-4 | `test_every_exit_gate_from_code_is_named_in_pipeline_doc`, `test_no_invented_gate_names_anywhere_in_showcase`, `test_subgates_in_normative_order_and_marked_as_insets` | PASS |
+| TC-07 | 6 ролей + артефакты + таблица модель/эффорт = config | AC-5 | `test_every_agent_prompt_stem_is_covered`, `test_effort_table_matches_config_class_defaults` | PASS |
+| TC-08 | Все ссылки резолвятся + обязательные golden sources | AC-6 | `test_all_relative_links_resolve_to_existing_files`, `test_mandatory_golden_source_links_present` | PASS |
+| TC-09 | Нет вне-репозиторных путей (`tasks/`/`memory/`/абс. хоста) | AC-12 | `test_no_out_of_repo_references` | PASS |
+| TC-10 | Презентация: ≥12 нумерованных слайдов + нарратив | AC-7 | `test_presentation_source_parses_with_canonical_parser`, `test_presentation_covers_mandatory_narrative_bits`, `test_presentation_carries_reproducible_build_procedure` | PASS |
+| TC-11 | Зависимости генерации (`python-pptx`) вне прод-образа | AC-7/NFR-2 | `test_no_pptx_dependency_in_prod_image`, `test_build_script_toplevel_imports_are_stdlib_only` | PASS |
+| TC-12 | Норматив «в том же PR» + ссылки README/CLAUDE.md | AC-9/AC-11 | `test_index_carries_maintenance_normative`, `test_repo_readme_links_overview`, `test_claude_md_carries_overview_pointer_and_normative`, `test_changelog_has_orch_011_entry` | PASS |
+| TC-13 | FORBIDDEN-скан хост-литералов + секрет-эвристика | AC-10/AC-11 | `test_showcase_carries_no_forbidden_host_literals`, `test_showcase_carries_no_secret_like_values`, `test_secret_heuristic_is_not_evergreen` | PASS |
+| TC-14 | Полный регресс `pytest tests/` зелёный; существующие док-тесты не сломаны | AC-10/AC-11 | весь прогон `tests/` (вкл. `test_lite_setup_doc`/`test_bundled_setup_doc`/`test_orch_52b_docs_standard`/`test_agent_prompts_canon`) | PASS |
+
+Также покрыты `test_index_carries_three_audience_routes` (AC-8 — 3 маршрута аудиторий).
+
+## Вывод pytest
+
+Модуль витрины:
+```
+$ python3 -m pytest tests/test_system_docs.py -v
+...
+======================== 28 passed, 1 warning in 0.43s =========================
+```
+
+Полный регресс:
+```
+$ cd /repos/_wt/orchestrator/feature_ORCH-011- && pytest tests/ -v --tb=short
+...
+================== 1873 passed, 1 warning in 71.36s (0:01:11) ==================
+```
+
+(Единственный warning — преэкзистентный `PydanticDeprecatedSince20` в `src/config.py:8`,
+не связан с ORCH-011, к коду ветки не относится.)
+
+## Итог
+
+PASS — все 14 TC выполнены и сопоставлены с критериями приёмки (AC-1…AC-12), smoke read-only
+зелёный (`serial_gate` + `auto_labels` присутствуют в `/queue`), полный регресс `tests/` —
+**1873 passed, 0 failed**. Стадия переходит на `deploy-staging`.

docs/work-items/ORCH-011/15-staging-log.md

@@ -0,0 +1,32 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-011
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+timestamp: 2026-06-11T06:35:40Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` environment (8501).
+Run canonically inside the container via `docker exec orchestrator-staging
+python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501
+--mode stub` (ORCH-048). Exit code **0** → advance.
+
+All REAL pipeline checks passed. The two failing checks are the known sandbox-infra
+checks C9a/C9b (depend on SANDBOX bot accounts being members of the sandbox project —
+not on the pipeline), tolerated under ORCH-061 since every REAL check is green.
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Results
+- **Block A (SMOKE)**: PASS — A1 `/health` 200 ok, A2 `/queue` 200, A3 `ORCH_STAGING=true`.
+- **Block B (ACCESS)**: PASS — B4 Plane sandbox accessible, B5 Gitea orchestrator-sandbox push=true, B6 registry isolated (sandbox present, prod ET/ORCH absent).
+- **Block C (E2E, mode=stub)**: C7 create issue PASS, C8 trigger pipeline PASS; C9a/C9b waived sandbox-infra. CLEANUP ok (Plane issue deleted).
+
+RESULT: 8/10 checks PASS — REAL failed: none; SANDBOX_INFRA waived: C9a, C9b.

docs/work-items/ORCH-019/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: Режим багфиксинга: упрощённый/дешёвый трек для багов (не полный цикл)
+
+Work Item ID: ORCH-019
+
+## Description
+
+TBD

docs/work-items/ORCH-019/01-brd.md

@@ -0,0 +1,178 @@
+---
+work_item: ORCH-019
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-019 — Режим багфиксинга (упрощённый/дешёвый трек для багов)
+
+Work Item: **ORCH-019** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
+Заказчик: Слава · Тип: фича (новый режим конвейера, опциональный, под флагом)
+
+> ⚠️ **Принцип, заданный Владельцем (нерушимый):** упрощаем **аналитику**, но **НЕ ослабляем
+> качество**. Гейты CI / review / tester verdict / deploy verdict **остаются**. Горький урок
+> ET-8 / BUG-TESTS-SUBSTRING: срезанная *проверка* = недоделка на проде. «Дешевле ≠
+> бесконтрольнее». Этот принцип — корневой инвариант всей задачи (см. NFR-1, BR-6).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1. Цель
+Дать оркестратору **отдельный удешевлённый трек для багфиксов**. Сейчас любой баг (пример:
+зашёл на карту enduro-trails, увидел дефект, завёл задачу) идёт по **полному** конвейеру
+`analysis → architecture → development → review → testing → deploy-staging → deploy`. Для мелкой
+правки полный цикл **избыточен**: лишние стадии (полный BRD/TRZ/AC + архитектурный ADR) тратят
+токены и время, не добавляя ценности на однострочном фиксе.
+
+### 1.2. Установленные факты (проверено по коду, не изобретать)
+- **Точка входа задачи в конвейер:** `src/webhooks/plane.py::start_pipeline` создаёт task-row
+  с **жёстко зашитой** начальной стадией `"analysis"` (`create_task_atomic(..., "analysis", ...)`)
+  и режет ветку (`_create_gitea_branch`). Это единственная точка, где задаётся точка входа.
+- **Маршрутизация стадий полностью управляется** `src/stages.py::STAGE_TRANSITIONS` через
+  `get_next_stage` — `advance_stage` (`src/stage_engine.py`) не содержит «зашитого» порядка стадий,
+  он спрашивает `get_next_stage`. → Изменение точки входа / маршрута локализуемо, машину стадий
+  ломать не нужно.
+- **Метка задачи уже читается из Plane** аппаратом ORCH-089: `src/labels.py::has_label` +
+  `plane_sync.fetch_issue_labels` / `get_project_labels` (TTL-кэш, нормализация имени, never-raise,
+  fail-safe → False). Источник истины — Plane API, **не** payload вебхука (`type`/`priority` в
+  payload отсутствуют). Это готовый, проверенный шаблон классификации задачи.
+- **Все Quality Gate'ы читают вердикт из артефактов**, а не из стадии входа: `check_ci_green`,
+  `check_reviewer_verdict` (`12-review.md`), `check_tests_passed` (`13-test-report.md`),
+  `check_staging_status`, `check_deploy_status`, под-гейты security/merge/coverage/image-freshness.
+  Они **не зависят** от того, прошла ли задача `analysis`/`architecture`, → их можно сохранить
+  нетронутыми при срезанном «входе».
+- **Coverage-гейт (ORCH-027)** уже структурно ловит «код без тестов» на ребре
+  `deploy-staging → deploy` — союзник принципа «баг фиксируется тестом».
+- **Прецедент стоимости:** UI z-index баг ET-9/ET-014 прошёл **полный** цикл ~35 мин — типичный
+  кандидат на удешевление.
+
+### 1.3. Связки и разграничение
+- **ORCH-13 (роутинг моделей):** «дешёвая модель на багфиксе» (Вариант 4 постановки) —
+  **вне объёма** ORCH-019, отдельная задача; ORCH-019 лишь оставляет точку композиции
+  (флаг bug-track наблюдаем, по нему ORCH-13 позже может выбрать модель). См. §2.2.
+- **ORCH-088 (serial gate) / ORCH-089 (auto-label):** ORCH-019 **сосуществует** с ними и
+  переиспользует их аппарат (label-чтение, per-repo flag, claim-gate); не конфликтует.
+- **ORCH-12 / ORCH-14 (UX) / ET-9 (визуальные баги):** часть багов визуальные и может требовать
+  мини-макета — для таких случаев предусмотрен механизм **эскалации обратно в полный цикл**
+  (BR-5), а не слепое удешевление.
+- **ORCH-8 (петля уроков):** баг, найденный на проде, — сигнал петли уроков; ORCH-019 этого не
+  меняет (post-deploy-телеметрия ORCH-021 сохраняется).
+
+---
+
+## 2. Объём (scope)
+
+### 2.1. В объёме
+- **BR-1 — Классификация «баг».** Задача распознаётся как баг по **метке Plane** (рекоменд. имя
+  `Bug`), читаемой аппаратом ORCH-089. Операторская, детерминированная, обратимая разметка.
+- **BR-2 — Упрощённый трек.** Багфикс-задача идёт по **укороченному** пути: пропускается
+  **тяжёлая аналитика и стадия `architecture`** (полный BRD/TRZ/AC/ADR не требуются); вместо них —
+  **минимальный набор артефактов** (короткий bug-report + обязательный план регресс-теста).
+- **BR-3 — Гейты качества сохраняются ПОЛНОСТЬЮ.** CI (`check_ci_green`), review
+  (`check_reviewer_verdict`), testing (`check_tests_passed`), staging/deploy-вердикты и под-гейты
+  (security/merge/coverage/image-freshness) исполняются **без изменений** на багфикс-треке.
+- **BR-4 — Обязательный регресс-тест.** Багфикс **обязан** зафиксировать дефект тестом (тест,
+  падающий до фикса и зелёный после) — главный предохранитель от рецидива (урок ET-8).
+- **BR-5 — Эскалация в полный цикл.** Если баг оказался сложным/архитектурным или визуальным
+  (нужен макет), он **возвращается** в полный цикл; багфикс-трек не «застревает» на сложном.
+- **BR-6 — Безопасность по умолчанию (fail-safe → полный цикл).** Любая неоднозначность/ошибка
+  чтения метки/выключенный флаг → задача идёт **полным** циклом (никогда не «теряет» стадии молча).
+- **BR-7 — Наблюдаемость стоимости.** Виден факт «задача на багфикс-треке» и метрика экономии
+  (стадии/agent-runs/токены/время) относительно полного цикла.
+
+### 2.2. Вне объёма (явно не делать)
+- **Роутинг моделей (ORCH-13 / Вариант 4):** выбор дешёвой модели на багфиксе — отдельная задача.
+- **Авто-триаж сложности аналитиком (полный Вариант 3):** автоматическая classification
+  `trivial/small/complex` LLM-аналитиком — будущее развитие; v1 опирается на явную метку оператора
+  + ручную/мини-эскалацию (BR-5), не на ML-классификатор.
+- **Изменение `STAGE_TRANSITIONS` (новые стадии), реестра `QG_CHECKS`, семантики любого `check_*`,
+  вердикт-ключей** (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+  `coverage_status:`).
+- **Параллелизм багфиксов**, изменение `max_concurrency`, merge-очередь.
+- **Полный отказ от стадии `analysis`** (вариант «hotfix → сразу development») как дефолт — см.
+  §6 (требуется минимальный аналитический проход ради регресс-теста и трассируемости). Чистый
+  hotfix без аналитики оставлен как возможная опция архитектора, но не дефолт.
+
+---
+
+## 3. Заинтересованные стороны
+- **Владелец/оператор (Слава):** ставит метку `Bug`, получает быстрый дешёвый фикс, эскалирует
+  сложный баг, читает метрику экономии.
+- **Self-hosting прод (`orchestrator`) и enduro-trails:** общий инстанс/БД/очередь — режим обязан
+  быть аддитивным, под флагом, per-repo, с нулевой регрессией при выключении (FR-условие).
+- **Агенты конвейера (analyst/developer/reviewer/tester):** работают по тем же контрактам; на
+  багфикс-треке analyst выдаёт облегчённый пакет, остальные — как обычно.
+
+---
+
+## 4. Бизнес-требования (BR) — сводная таблица
+
+| ID | Требование | Связь |
+|----|------------|-------|
+| BR-1 | Задача распознаётся как баг по метке Plane (`Bug`), читаемой через аппарат ORCH-089 (`labels.has_label` + `plane_sync.fetch_issue_labels`). Источник истины — Plane API, не payload. | FR-1, AC-1 |
+| BR-2 | Багфикс-задача пропускает тяжёлую аналитику и стадию `architecture`; маршрут `analysis(lite) → development → review → testing → deploy-staging → deploy`. Полный BRD/TRZ/AC/ADR не обязателен. | FR-2, AC-2 |
+| BR-3 | Все Quality Gate'ы (CI/review/tester/staging/deploy + под-гейты security/merge/coverage/image-freshness) исполняются на багфикс-треке **без изменений**. | FR-3, AC-3 |
+| BR-4 | Багфикс обязан содержать **регресс-тест** (падает до фикса, зелён после); отсутствие нового/изменённого теста на исправление — повод для REQUEST_CHANGES reviewer'ом. | FR-3/FR-4, AC-4 |
+| BR-5 | Существует механизм **эскалации** багфикса в полный цикл (сложный/архитектурный/визуальный баг) — задача возвращается на полную аналитику/архитектуру. | FR-5, AC-5 |
+| BR-6 | **Fail-safe:** при выключенном флаге, ошибке/неоднозначности чтения метки, неприменимом репо — задача идёт **полным** циклом (никогда не теряет стадии молча). never-raise. | FR-6, AC-6 |
+| BR-7 | Факт багфикс-трека и метрика экономии (пропущенные стадии / Σ agent-runs / токены / время vs полный цикл) наблюдаемы (`GET /queue` блок + лог/Telegram-карточка). | FR-7, AC-7 |
+| BR-8 | Поведение управляется kill-switch'ом и областью репо (как ORCH-35/43/58/88/89): выключение флага → строго прежнее поведение (нулевая регрессия для enduro и для orchestrator). | NFR-2, AC-6 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| NFR-1 | **Качество не ослабляется (корневой инвариант).** Срезается только *аналитика/архитектура*; ни один Quality Gate, exit-код deploy-хука, под-гейт безопасности/покрытия — не ослаблен и не пропущен. |
+| NFR-2 | **Нулевая регрессия / аддитивность.** При `bug_fast_track_enabled=False` или неприменимом репо путь старта и маршрут идентичны текущим. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/вердикт-ключи/схема БД — не меняются (допустима лишь аддитивная идемпотентная миграция, если архитектор сочтёт нужным помечать тип задачи в БД). |
+| NFR-3 | **never-raise / fail-safe.** Любая ошибка классификации/маршрутизации → деградация на полный цикл, не падение вебхука/конвейера (по образцу `labels.py`/`serial_gate.py`). |
+| NFR-4 | **Offline-устойчивость горячего пути.** Классификация может ходить в Plane API только в момент `start_pipeline` (как ORCH-089), но **не** в горячем `claim_next_job` (иначе встанет очередь всех проектов). |
+| NFR-5 | **Per-repo область.** Режим включается по CSV-области репо; orchestrator и enduro управляются независимо. |
+| NFR-6 | **Self-hosting безопасность.** Механизм не рестартит/не роняет прод-контейнер, не пушит/force-push в `main`. |
+| NFR-7 | **Композируемость.** Корректно сосуществует с serial-gate (ORCH-088), auto-label (ORCH-089), coverage-gate (ORCH-027), merge-gate (ORCH-043). |
+
+---
+
+## 6. Допущения и ограничения
+- **Минимальный аналитический проход сохраняется** (а не «hotfix → сразу dev»): ради (а)
+  фиксации регресс-теста как контракта приёмки (BR-4), (б) трассируемости (минимальный bug-report).
+  Полный отказ от `analysis` для багов оставлен архитектору как опция, но дефолт — мини-анализ.
+  Обоснование: урок ET-8 — именно отсутствие явного теста-фиксатора привело к «недоделка в Done».
+- **Классификация v1 — явная метка оператора**, не LLM-авто-триаж (Вариант 3 в полном объёме —
+  будущее). Метка `Bug` должна существовать в Plane-проекте; её отсутствие = fail-safe полный цикл.
+- **Эскалация v1** — допускает как минимум ручной путь (снять метку `Bug` / вернуть стадию) и/или
+  решение мини-аналитика «баг сложный → не фаст-трекать». Конкретный механизм — архитектору.
+- **Стоимость измеряется относительно**: метрика «во сколько раз дешевле» считается по факту из
+  существующей телеметрии `agent_runs` (стадии/токены/время), без новой тяжёлой инфраструктуры.
+
+---
+
+## 7. Критерии успеха (резюме; детали — `03-acceptance-criteria.md`)
+- AC-1 — задача с меткой `Bug` распознаётся и помечается как багфикс-трек.
+- AC-2 — багфикс-задача проходит конвейер, пропустив стадию `architecture` (и тяжёлый BRD/TRZ/AC).
+- AC-3 — все Quality Gate'ы исполнены на багфикс-треке (CI/review/tester/staging/deploy + под-гейты).
+- AC-4 — багфикс содержит регресс-тест; его отсутствие даёт REQUEST_CHANGES.
+- AC-5 — сложный/визуальный баг эскалируется в полный цикл.
+- AC-6 — при выключенном флаге / ошибке / неприменимом репо — поведение строго прежнее (полный цикл).
+- AC-7 — факт багфикс-трека и метрика экономии наблюдаемы.
+
+---
+
+## 8. Риски (детали — `10-tech-risks.md`, заполняет архитектор)
+- R-1: **Срезали лишнее.** Ошибочный пропуск гейта качества → недоделка на проде (ET-8). Митигатор —
+  NFR-1: режется только аналитика/архитектура, гейты структурно нетронуты + тест AC-3.
+- R-2: **Сложный баг под меткой `Bug`** уходит на фаст-трек и упирается в отсутствие архитектуры →
+  нужна эскалация (BR-5) и/или решение мини-аналитика.
+- R-3: **Регресс-тест не написан** (developer «забыл») → рецидив бага. Митигатор — BR-4 + reviewer-ось
+  + союзник coverage-gate (ORCH-027).
+- R-4: **Fail-safe инвертирован** (ошибка → молча срезали стадии) → недоделка. Митигатор — NFR-3
+  fail-safe строго в сторону полного цикла + тест AC-6.
+- R-5: **Конфликт с serial-gate/auto-label** при изменённой точке входа. Митигатор — NFR-7 +
+  интеграционный тест композиции.
+</content>
+</invoke>

docs/work-items/ORCH-019/02-trz.md

@@ -0,0 +1,207 @@
+---
+work_item: ORCH-019
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-019 — Режим багфиксинга (упрощённый/дешёвый трек для багов)
+
+Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты), выведенное из BRD
+> и фактического кода. **Как** (точная схема: где именно ветвить маршрут, хранить ли тип задачи в
+> БД, отдельный leaf-модуль или расширение `labels.py`) — решает архитектор в `06-adr/`. ТЗ
+> фиксирует требования и границы, архитектурное решение не предлагает.
+
+> ⚠️ **Корневой инвариант (NFR-1 BRD):** срезается ТОЛЬКО аналитика/архитектура. Любой Quality Gate,
+> exit-код deploy-хука, под-гейт безопасности/покрытия — байт-в-байт прежние.
+
+---
+
+## 1. Сводка изменения
+Ввести **опциональный багфикс-трек**: задача, помеченная в Plane меткой `Bug`, проходит конвейер по
+**укороченному маршруту** — пропускается стадия `architecture` и тяжёлая аналитика (полный
+BRD/TRZ/AC/ADR заменяются минимальным bug-report + обязательным планом регресс-теста). Все
+Quality Gate'ы (CI/review/tester/staging/deploy + под-гейты security/merge/coverage/image-freshness)
+исполняются **без изменений**. Распознавание бага и маршрут — аддитивно, под kill-switch, с областью
+репо, never-raise, fail-safe → полный цикл. `STAGE_TRANSITIONS` и реестр `QG_CHECKS` структурно не
+меняются.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Роль в задаче | Характер изменения |
+|------|---------------|--------------------|
+| `src/labels.py` | аппарат чтения метки Plane (ORCH-089: `has_label`, `*_applies`) | переиспользовать; **добавить** `is_bug_task(work_item_id, project_id) -> bool` + `bug_fast_track_applies(repo) -> bool` (по образцу `auto_approve_applies`), либо вынести в новый leaf `src/bug_fast_track.py` (never-raise) — выбор архитектора |
+| `src/plane_sync.py` | `fetch_issue_labels` / `get_project_labels` / `_normalize_label` | **без изменений** — переиспользуются для чтения метки `Bug` (источник истины — Plane API) |
+| `src/webhooks/plane.py` | `start_pipeline` (создаёт task-row со стадией `"analysis"`, режет ветку `_create_gitea_branch`), `handle_status_start`, `handle_issue_updated` | **ключевая врезка:** перед `create_task_atomic(...)` определить тип задачи и (при багфикс-треке) пометить задачу багом / задать укороченный маршрут. Внешний контракт вебхука Plane не меняется |
+| `src/stages.py` | `STAGE_TRANSITIONS`, `get_next_stage` | **структура `STAGE_TRANSITIONS` не меняется** (новых стадий нет). Требование: маршрут багфикса = `analysis → development` (пропуск `architecture`). Механизм (условный `get_next_stage` по типу задачи / bug-mode-флаг на task) — архитектору |
+| `src/stage_engine.py` | `advance_stage`, `_run_qg`, `_handle_analysis_approved_flow`, откаты | `advance_stage` уже маршрутизирует через `get_next_stage` (не зашивает порядок) → при условной маршрутизации правка точечная. Гейты диспетчеризуются как раньше |
+| `src/db.py` | `create_task_atomic(plane_id, work_item_id, repo, branch, stage, title)`, схема `tasks`, `claim_next_job` | если архитектор решит хранить «тип=bug» в БД — **аддитивная идемпотентная** колонка (`_ensure_column`, напр. `tasks.track TEXT DEFAULT 'full'`); горячий `claim_next_job` **не** должен ходить в сеть (NFR-4) |
+| `src/config.py` | флаги фичи | новые: `bug_fast_track_enabled`, `bug_fast_track_label`, `bug_fast_track_repos` (CSV) + helper `applies(repo)` по образцу `auto_label_*` / `serial_gate_*` |
+| `src/qg/checks.py` | реестр `QG_CHECKS` и `check_*` | **без изменений** (инвариант NFR-1) |
+| `src/serial_gate.py`, `src/coverage_gate.py`, `src/merge_gate.py` | композиция | **без изменений**; проверить совместимость (NFR-7) интеграционным тестом |
+| `src/main.py` | `GET /queue` | **аддитивный** read-only блок `bug_fast_track` (флаг/область/счётчики/метрика экономии) |
+| `src/notifications.py` | live-карточка | опционально — отметка «🐞 багфикс-трек» в карточке (never-raise) |
+| `.openclaw/agents/analyst.md` | промпт мини-аналитика | при багфикс-треке выдавать **облегчённый** пакет (bug-report + регресс-тест-план), не полный BRD/TRZ/AC. Канон промптов 52d не нарушать |
+| `.openclaw/agents/reviewer.md` | ось контроля | добавить ось «багфикс без регресс-теста → REQUEST_CHANGES» (BR-4) — нормативно-описательно, не машинный гейт |
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Классификация задачи как «баг» (BR-1)
+- Багфикс-трек активируется, если issue несёт метку Plane с именем `bug_fast_track_label`
+  (дефолт `Bug`), прочитанную через `labels.has_label(work_item_id, label, project_id)` (ORCH-089:
+  `fetch_issue_labels` + `get_project_labels`, нормализация `_normalize_label`, TTL-кэш).
+- **Источник истины — Plane API**, не payload вебхука (поле `type` в payload отсутствует).
+- Чтение метки допускается **только** в `start_pipeline` (момент старта, сетевой вызов приемлем,
+  как ORCH-089) — **не** в горячем `claim_next_job` (NFR-4).
+- `applies(repo)` (локальный, без сети) проверяется **первым**; `has_label` (сеть) — только при
+  `applies==True` → при выключенном флаге нулевой сетевой оверхед (образец ORCH-089).
+
+### FR-2 — Укороченный маршрут (BR-2)
+- Для багфикс-задачи маршрут конвейера: `analysis(lite) → development → review → testing →
+  deploy-staging → deploy → done`, т.е. **пропускается стадия `architecture`** (и её exit-гейт
+  `check_architecture_done` / требование `06-adr/`).
+- `STAGE_TRANSITIONS` **не изменяется структурно**. Требуемый инвариант результата: при выходе
+  багфикс-задачи из `analysis` следующая стадия = `development` (а не `architecture`); для
+  не-багфикс задач — прежняя `architecture`. Конкретный механизм (условный `get_next_stage(stage,
+  task)` / bug-mode-флаг на task / точка входа сразу в `development`) — решение архитектора.
+- Тяжёлая аналитика облегчается: на багфикс-треке обязательны лишь `01-brd.md` (короткий
+  bug-report: симптом, шаги воспроизведения, локализация, причина) и `04-test-plan.yaml` (план
+  регресс-теста). Полные `02-trz.md`/`03-acceptance-criteria.md` и `06-adr/` — **не обязательны**.
+  (Совместимость с `check_analysis_complete`, требующим `01/02/03/04` — см. FR-6.)
+
+### FR-3 — Гейты качества сохраняются полностью (BR-3, корневой инвариант)
+- На багфикс-треке исполняются **без изменений**: `check_ci_green` (development→review),
+  `check_reviewer_verdict` (review→testing, `12-review.md`), `check_tests_passed` (testing→
+  deploy-staging, `13-test-report.md`), `check_staging_status`, `check_deploy_status`, под-гейты
+  ребра `deploy-staging→deploy` (security ORCH-022 → merge ORCH-043 → coverage ORCH-027 →
+  image-freshness ORCH-058) и merge-verify ребра `deploy→done` (ORCH-071/073).
+- Ни один `check_*`, его сигнатура, вердикт-ключ или порядок под-гейтов **не меняется**.
+
+### FR-4 — Обязательный регресс-тест (BR-4)
+- Багфикс **обязан** содержать новый/изменённый тест, воспроизводящий дефект (красный до фикса,
+  зелёный после). Требование закрепляется: (а) в `04-test-plan.yaml` багфикса как обязательный TC;
+  (б) reviewer-осью (`.openclaw/agents/reviewer.md`): «исправление кода без теста-фиксатора →
+  finding ≥P1 / REQUEST_CHANGES»; (в) усиливается coverage-гейтом ORCH-027 (структурно ловит «код
+  без тестов»). Это требование, не новый машинный гейт.
+
+### FR-5 — Эскалация в полный цикл (BR-5)
+- Багфикс-задача должна иметь путь возврата в полный цикл, если баг оказался сложным/архитектурным
+  или визуальным (нужен макет — связка ORCH-12/14, прецедент ET-9). Минимум v1: ручная эскалация
+  (оператор снимает метку `Bug` / переводит стадию) **и/или** решение мини-аналитика «баг сложный →
+  не фаст-трекать» (тогда задача идёт штатным маршрутом с `architecture`). Конкретный механизм и
+  его автоматизация — архитектору; v1 не обязан включать LLM-авто-триаж сложности.
+
+### FR-6 — Fail-safe → полный цикл (BR-6, NFR-3)
+- При `bug_fast_track_enabled=False`, неприменимом репо, ошибке/таймауте/неоднозначности чтения
+  метки (`has_label` → False / `None`-labels), отсутствии метки `Bug` в проекте — задача идёт
+  **полным** циклом (точка входа `analysis`, маршрут с `architecture`). never-raise: ошибка логики
+  не роняет `start_pipeline`/вебхук.
+- **Совместимость с `check_analysis_complete`** (требует наличие `01/02/03/04`): при облегчённом
+  пакете багфикса гейт не должен ложно блокировать. Варианты (архитектору): мини-аналитик всё равно
+  эмитит заглушки `02/03` ИЛИ гейт `check_analysis_approved` на багфикс-треке учитывает облегчённый
+  набор. Требование: **не ослабить** проверку для не-баг задач и **не заблокировать ложно** баг.
+
+### FR-7 — Наблюдаемость стоимости (BR-7)
+- Факт «задача на багфикс-треке» и метрика экономии видны: (а) аддитивный блок `bug_fast_track` в
+  `GET /queue` (флаг/область + счётчик задач на треке + агрегат сэкономленных стадий/agent-runs);
+  (б) лог-строка на решение о маршруте; (в) опц. отметка в Telegram-карточке. Метрика «во сколько
+  дешевле» считается из существующей телеметрии `agent_runs` (Σ токены/время багфикс-трека vs
+  средний полный цикл) — без новой тяжёлой инфраструктуры.
+
+---
+
+## 4. Изменения API
+
+### 4.1. Новые публичные endpoint'ы
+- **Не требуются обязательно.** (Эскалация и классификация идут через Plane-метки/статусы, не через
+  новый HTTP-эндпоинт. Если архитектор вводит админ-эндпоинт принудительной (де)классификации —
+  описать в ADR и обновить таблицу API в README.)
+
+### 4.2. Изменяемые endpoint'ы
+- `GET /queue` — **аддитивно** добавляется блок `bug_fast_track` (read-only, never-raise) по образцу
+  блоков `serial_gate` / `auto_labels` / `coverage`: `enabled`, `repos`, `label`, перечень/счётчик
+  задач на багфикс-треке, агрегатная метрика экономии. Существующие ключи `GET /queue` не меняются.
+
+### 4.3. Webhook-обработчики
+- `start_pipeline` (`webhooks/plane.py`): добавляется ветвление «issue имеет метку `Bug` и
+  `applies(repo)` → багфикс-трек (пометить задачу / задать укороченный вход-маршрут)». Внешний
+  контракт вебхука Plane не меняется.
+
+---
+
+## 5. Изменения схемы БД
+> Только **аддитивные, идемпотентные** миграции (общая прод-БД; enduro не трогать).
+
+- **Опционально (выбор архитектора):** если тип задачи нужно знать после старта (для маршрутизации
+  в `advance_stage`/`get_next_stage` и для метрики), ввести аддитивную колонку
+  `tasks.track TEXT DEFAULT 'full'` (значения `full` | `bug`) через `_ensure_column` (паттерн
+  `tasks.cancelled_at` ORCH-090). Тогда горячий `claim_next_job` читает тип из БД, **не** из сети
+  (NFR-4). Альтернатива без колонки (вывести тип повторным чтением метки) допустима, но повторный
+  сетевой вызов в горячем пути запрещён (NFR-4) → колонка предпочтительнее.
+- **Существующие** `tasks`-контракт (прочие колонки), `jobs`, `job_deps`, `agent_runs`,
+  `coverage_baseline`, `repo_freeze` — **без изменений**.
+
+---
+
+## 6. Требования к новым/изменённым QG checks
+- **Новых QG-проверок не вводить; ни один `check_*` не менять семантически** (NFR-1). Маршрутизация
+  багфикса — свойство планировщика/точки входа, **не** Quality Gate.
+- Единственная допустимая тонкая правка — обеспечить, чтобы exit-гейт стадии `analysis`
+  (`check_analysis_approved` / helper `check_analysis_complete`) **не блокировал ложно** облегчённый
+  багфикс-пакет, **не ослабляя** проверку для полного цикла (FR-6). Если для этого требуется правка
+  `check_*` — она должна сохранить вердикт-семантику для не-баг задач байт-в-байт.
+
+---
+
+## 7. Совместимость / регресс
+- **Kill-switch** `bug_fast_track_enabled` (env `ORCH_BUG_FAST_TRACK_ENABLED`); `False` → точка входа
+  и маршрут строго прежние (`analysis → architecture → …`), нулевая регрессия (NFR-2).
+- **Область репо** `bug_fast_track_repos` (CSV; пусто → рекомендуется self-hosting + явно
+  разрешённые проекты, где есть метка `Bug` — решение об области по умолчанию фиксирует архитектор).
+- **`applies(repo)` первым** (локально, без сети) → выключенный флаг = нулевой сетевой оверхед,
+  enduro не затронут.
+- **Композиция (NFR-7):** не конфликтует с serial-gate (ORCH-088: багфикс-задача — обычная задача
+  репо, учитывается в serial-очереди), auto-label (ORCH-089: `autoApprove`/`autoDeploy` работают и
+  на багфикс-треке), coverage-gate (ORCH-027: союзник BR-4), merge-gate (ORCH-043).
+- **never-raise / fail-safe** (NFR-3): ошибка классификации/маршрута → полный цикл, не падение.
+- **Self-hosting** (NFR-6): механизм не рестартит/не роняет прод, не пушит/force-push в `main`.
+- **Маркеры трассировки** (CLAUDE.md §9): новые инварианты помечаются `ORCH-019`; правка
+  маркированного кода (ORCH-088/089/027) — со сверкой их `06-adr/`.
+
+---
+
+## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
+- `docs/work-items/ORCH-019/06-adr/ADR-001-<slug>.md` — решение (механизм маршрута, хранение типа,
+  совместимость с `check_analysis_complete`, область по умолчанию, механизм эскалации).
+- `docs/architecture/README.md` — новый раздел «Багфикс-трек (ORCH-019)» + блок `bug_fast_track` в
+  описании `GET /queue`; при новой колонке — раздел «База данных».
+- `CLAUDE.md` — краткий абзац о багфикс-режиме (правила для агентов / конвейер).
+- `CHANGELOG.md` — запись `feat:`.
+- `.openclaw/agents/analyst.md` / `reviewer.md` — облегчённый пакет багфикса + reviewer-ось
+  регресс-теста (канон 52d не нарушать).
+- При новой колонке — `docs/work-items/ORCH-019/08-data-requirements.md` (заполняет архитектор).
+
+---
+
+## 9. Открытые вопросы для архитектора (не блокируют анализ)
+- OQ-1: Механизм пропуска `architecture` — условный `get_next_stage(stage, task)`, bug-mode-флаг на
+  task, или прямой вход багфикса сразу в `development` с сохранённым мини-bug-report? (Влияет на
+  §3 `stages.py`/`stage_engine.py` и на `check_analysis_complete`.)
+- OQ-2: Хранить ли тип задачи в БД (`tasks.track`) vs выводить из метки. Рекоменд. — колонка
+  (NFR-4 запрещает сеть в горячем claim).
+- OQ-3: Сохранять ли мини-стадию `analysis(lite)` (рекоменд., ради регресс-теста и трассируемости)
+  или допустить чистый hotfix `→ development` (вне дефолта). См. BRD §6.
+- OQ-4: Механизм эскалации (BR-5) — только ручной (снять метку/сменить стадию) или авто-сигнал
+  мини-аналитика «баг сложный → полный цикл».
+- OQ-5: Область по умолчанию (пустой CSV) — self-hosting only vs все репо с меткой `Bug`.
+- OQ-6: Совместимость с `check_analysis_approved`/`check_analysis_complete` на облегчённом пакете
+  (FR-6) — заглушки `02/03` vs условный учёт гейтом.
+</content>

docs/work-items/ORCH-019/03-acceptance-criteria.md

@@ -0,0 +1,139 @@
+---
+work_item: ORCH-019
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-019 — Режим багфиксинга
+
+Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
+считается провалом). Reviewer/tester проверяют их буквально по файлам репозитория и тестам.
+
+> ⚠️ Корневой инвариант (см. AC-3/AC-8): срезается только аналитика/архитектура; ни один Quality
+> Gate не ослаблен. Это главное условие приёмки — нарушение = безусловный FAIL всей задачи.
+
+---
+
+## AC-1 — Классификация задачи по метке `Bug`
+
+**Условие:** issue с меткой Plane `bug_fast_track_label` (дефолт `Bug`) при включённом флаге и
+применимом репо распознаётся как багфикс-задача.
+- **PASS:** при `bug_fast_track_enabled=True` и `applies(repo)==True` для issue с меткой `Bug`
+  `is_bug_task(...)` возвращает `True` (через `labels.has_label` → `plane_sync.fetch_issue_labels`);
+  задача стартует на багфикс-треке. Источник метки — Plane API, не payload вебхука.
+- **FAIL:** метка `Bug` игнорируется; ИЛИ тип читается из payload вебхука; ИЛИ задача без метки
+  `Bug` ошибочно попадает на багфикс-трек.
+
+---
+
+## AC-2 — Укороченный маршрут: пропуск стадии `architecture`
+
+**Условие:** багфикс-задача проходит конвейер, минуя стадию `architecture`.
+- **PASS:** для багфикс-задачи переход из `analysis` ведёт в `development` (а не `architecture`);
+  стадия `architecture` и её требование `06-adr/` для багфикса не исполняются; задача доходит до
+  `done`. Маршрут не-баг задачи остаётся `analysis → architecture → development → …`.
+- **FAIL:** багфикс-задача всё равно проходит `architecture`; ИЛИ не-баг задача начинает пропускать
+  `architecture`; ИЛИ `STAGE_TRANSITIONS` изменён структурно (новые/удалённые стадии).
+
+---
+
+## AC-3 — Все Quality Gate'ы исполнены на багфикс-треке (корневой инвариант)
+
+**Условие:** на багфикс-треке исполняются все гейты качества без изменений.
+- **PASS:** для багфикс-задачи отрабатывают `check_ci_green`, `check_reviewer_verdict`
+  (`12-review.md`), `check_tests_passed` (`13-test-report.md`), `check_staging_status`,
+  `check_deploy_status` и под-гейты ребра `deploy-staging→deploy` (security → merge → coverage →
+  image-freshness) и merge-verify ребра `deploy→done`. Реестр `QG_CHECKS`, сигнатуры `check_*`,
+  вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+  `coverage_status:`) и порядок под-гейтов — байт-в-байт прежние.
+- **FAIL:** хоть один гейт качества пропущен/ослаблен/изменён на багфикс-треке; ИЛИ изменён состав
+  `QG_CHECKS` / имя или регистр любого вердикт-ключа / порядок под-гейтов.
+
+---
+
+## AC-4 — Обязательный регресс-тест
+
+**Условие:** багфикс фиксирует дефект тестом.
+- **PASS:** PR багфикса содержит новый/изменённый тест, воспроизводящий исправляемый дефект
+  (красный на коде до фикса, зелёный после); требование закреплено в `04-test-plan.yaml` багфикса
+  и в reviewer-оси (`.openclaw/agents/reviewer.md`: фикс без теста → finding ≥P1 / REQUEST_CHANGES).
+- **FAIL:** багфикс мержится без теста-фиксатора; ИЛИ reviewer-ось отсутствует/не срабатывает; ИЛИ
+  тест присутствует, но не падает на исходном (нефиксированном) коде.
+
+---
+
+## AC-5 — Эскалация сложного бага в полный цикл
+
+**Условие:** сложный/архитектурный/визуальный баг возвращается в полный цикл.
+- **PASS:** существует и документирован путь эскалации (минимум ручной: снятие метки `Bug` /
+  перевод стадии, и/или решение мини-аналитика «баг сложный → не фаст-трекать»); после эскалации
+  задача проходит штатный маршрут с `architecture`.
+- **FAIL:** механизма эскалации нет; ИЛИ багфикс-задача необратимо застревает без `architecture`,
+  когда баг требует архитектурного решения/макета.
+
+---
+
+## AC-6 — Fail-safe → полный цикл (нулевая регрессия)
+
+**Условие:** при выключении/ошибке/неприменимости — строго прежнее поведение (полный цикл).
+- **PASS:** при `bug_fast_track_enabled=False`, неприменимом репо, ошибке/таймауте/неоднозначности
+  чтения метки, отсутствии метки `Bug` — задача стартует на `analysis` и идёт маршрутом с
+  `architecture` (как до ORCH-019). Логика never-raise: ошибка не роняет `start_pipeline`/вебхук.
+  При выключенном флаге путь старта и маршрут идентичны текущим (диффом по поведению — нулевые).
+- **FAIL:** ошибка/неоднозначность приводит к молчаливому пропуску стадий; ИЛИ исключение из
+  логики классификации роняет вебхук/конвейер; ИЛИ при выключенном флаге поведение отличается от
+  прежнего.
+
+---
+
+## AC-7 — Наблюдаемость трека и метрика стоимости
+
+**Условие:** факт багфикс-трека и экономия наблюдаемы.
+- **PASS:** `GET /queue` содержит аддитивный read-only блок `bug_fast_track` (флаг/область/метка +
+  счётчик задач на треке + агрегатная метрика экономии стадий/agent-runs/токенов/времени);
+  решение о маршруте логируется; существующие ключи `GET /queue` не изменены.
+- **FAIL:** трек/метрика ненаблюдаемы; ИЛИ блок ломает существующий контракт `GET /queue`; ИЛИ
+  ошибка построения блока роняет эндпоинт (нарушен never-raise).
+
+---
+
+## AC-8 — Аддитивность и self-hosting безопасность
+
+**Условие:** изменение аддитивно и безопасно для общего прод-инстанса.
+- **PASS:** миграции БД (если есть) аддитивны и идемпотентны (`_ensure_column`/`CREATE TABLE IF NOT
+  EXISTS`); enduro при выключенном/неприменимом флаге не затронут; механизм не рестартит/не роняет
+  прод-контейнер, не пушит/force-push в `main`. Полный регресс `tests/` зелёный.
+- **FAIL:** ломающая миграция/изменение существующих контрактов; ИЛИ затронут enduro при выключенном
+  флаге; ИЛИ механизм трогает прод-контейнер/`main`; ИЛИ красный `tests/`.
+
+---
+
+## AC-9 — Композиция с существующими гейтами
+
+**Условие:** багфикс-трек корректно сосуществует с ORCH-088/089/027/043.
+- **PASS:** багфикс-задача корректно учитывается serial-gate (ORCH-088) как обычная задача репо;
+  `autoApprove`/`autoDeploy` (ORCH-089) работают на багфикс-треке; coverage-gate (ORCH-027) и
+  merge-gate (ORCH-043) исполняются штатно. Интеграционный тест композиции зелёный.
+- **FAIL:** изменённая точка входа ломает serial-очередь/auto-label/merge/coverage; ИЛИ багфикс-
+  задача обходит serial-gate.
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-2 |
+| AC-3 | BR-3 / FR-3 / NFR-1 |
+| AC-4 | BR-4 / FR-4 |
+| AC-5 | BR-5 / FR-5 |
+| AC-6 | BR-6 / FR-6 / NFR-2 / NFR-3 |
+| AC-7 | BR-7 / FR-7 |
+| AC-8 | BR-8 / NFR-2 / NFR-6 |
+| AC-9 | NFR-7 |
+</content>

docs/work-items/ORCH-019/04-test-plan.yaml

@@ -0,0 +1,111 @@
+work_item: ORCH-019
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "Багфикс-трек: классификация по метке, укороченный маршрут, сохранность гейтов, fail-safe"
+framework: pytest
+scope: >
+  Покрывает: классификацию задачи как бага по метке Plane (ORCH-089-аппарат), маршрутизацию
+  багфикса в обход стадии architecture, сохранность ВСЕХ Quality Gate'ов, обязательность
+  регресс-теста, эскалацию в полный цикл, fail-safe → полный цикл, наблюдаемость/метрику,
+  аддитивность и композицию с serial-gate/auto-label/coverage. Вне покрытия: реальный
+  Plane/Gitea I/O (мокается), роутинг моделей ORCH-13, LLM-авто-триаж сложности.
+notes: >
+  Сетевые вызовы Plane (fetch_issue_labels/get_project_labels) мокаются. Полный регресс tests/
+  должен оставаться зелёным. Тесты на сохранность гейтов проверяют НЕИЗМЕННОСТЬ QG_CHECKS/check_*/
+  вердикт-ключей — это анти-регресс корневого инварианта (NFR-1). Финальные имена модулей/функций
+  (labels.py vs новый bug_fast_track.py; tasks.track колонка) фиксирует архитектор — TC привязаны
+  к поведению, имена путей уточняются на стадии разработки.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "is_bug_task() возвращает True для issue с меткой 'Bug' (has_label True); метка читается из Plane API, не из payload."
+    module: tests/test_bug_fast_track.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "is_bug_task() возвращает False при отсутствии метки, неоднозначной метке или labels=None (fail-safe)."
+    module: tests/test_bug_fast_track.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "bug_fast_track_applies(repo): первым проверяется локальная область (enabled + CSV repos) до любого сетевого вызова; выключенный флаг → False без обращения к has_label."
+    module: tests/test_bug_fast_track.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "never-raise: исключение в fetch_issue_labels/get_project_labels не пробрасывается — is_bug_task деградирует в False (полный цикл)."
+    module: tests/test_bug_fast_track.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Маршрут багфикса: для bug-задачи следующая стадия после analysis = development (architecture пропущена); для не-баг задачи = architecture."
+    module: tests/test_bug_fast_track_routing.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "STAGE_TRANSITIONS структурно не изменён: набор стадий и рёбер байт-в-байт прежний (анти-регресс)."
+    module: tests/test_bug_fast_track_routing.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Реестр QG_CHECKS и сигнатуры check_* не изменены багфикс-треком; вердикт-ключи (verdict/result/deploy_status/staging_status/security_status/coverage_status) сохранены по имени и регистру."
+    module: tests/test_bug_fast_track_gates.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "E2E багфикс-трек: bug-задача проходит development→review→testing→deploy-staging→deploy с исполнением всех гейтов (check_ci_green/reviewer_verdict/tests_passed/staging/deploy + под-гейты security/merge/coverage/image-freshness), минуя architecture."
+    module: tests/test_bug_fast_track_e2e.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "start_pipeline: issue с меткой Bug (флаг вкл, репо применим) создаёт задачу на багфикс-треке; issue без метки — на полном цикле (точка входа analysis + маршрут с architecture)."
+    module: tests/test_bug_fast_track_e2e.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "Fail-safe: при bug_fast_track_enabled=False путь старта и маршрут идентичны прежним (нулевая регрессия) — задача с меткой Bug идёт полным циклом."
+    module: tests/test_bug_fast_track_e2e.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "Эскалация: после снятия метки Bug / решения 'баг сложный' задача проходит штатный маршрут с architecture (возврат в полный цикл)."
+    module: tests/test_bug_fast_track_escalation.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "check_analysis_approved/check_analysis_complete не блокирует ложно облегчённый багфикс-пакет, но сохраняет прежнюю проверку для не-баг задач (требование FR-6)."
+    module: tests/test_bug_fast_track_gates.py
+    expected: PASS
+
+  - id: TC-13
+    type: integration
+    description: "GET /queue содержит аддитивный read-only блок bug_fast_track (enabled/repos/label/счётчик/метрика); существующие ключи неизменны; ошибка построения блока не роняет эндпоинт."
+    module: tests/test_queue_endpoint.py
+    expected: PASS
+
+  - id: TC-14
+    type: integration
+    description: "Композиция: багфикс-задача учитывается serial-gate (ORCH-088) как обычная задача репо и не обходит его; autoApprove/autoDeploy (ORCH-089) применимы на багфикс-треке."
+    module: tests/test_bug_fast_track_composition.py
+    expected: PASS
+
+  - id: TC-15
+    type: unit
+    description: "Миграция (если введена колонка tasks.track) аддитивна и идемпотентна: повторный init_db/_ensure_column не падает; дефолт 'full' для существующих строк."
+    module: tests/test_db_migrations.py
+    expected: PASS

docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md

@@ -0,0 +1,231 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Багфикс-трек — пропуск стадии `architecture` через track-aware routing override
+
+Work Item: **ORCH-019** — упрощённый/дешёвый трек для багов (укороченный маршрут конвейера)
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0032-bug-fast-track.md`** (решение
+кросс-каттинговое: новый leaf-компонент + аддитивная колонка `tasks.track` + семантика
+маршрутизации, затрагивающая `advance_stage`).
+
+## Статус
+Proposed
+
+## Контекст
+
+Любая задача входит в конвейер через `webhooks/plane.py::start_pipeline`, который
+**жёстко** создаёт task-row со стадией `"analysis"` (`create_task_atomic(..., "analysis", ...)`)
+и режет ветку. Маршрут стадий полностью управляется `src/stages.py::STAGE_TRANSITIONS` через
+`get_next_stage` — `advance_stage` (`src/stage_engine.py`) НЕ зашивает порядок, а спрашивает
+`get_next_stage(current_stage)` (строка 214) и `get_agent_for_stage(current_stage)` (строка 464).
+
+Для мелкого бага полный цикл `analysis → architecture → development → …` избыточен: стадия
+`architecture` = отдельный прогон агента `architect` (opus, дорогой) + ADR + exit-гейт
+`check_architecture_done`. Прецедент: UI z-index баг ET-9/ET-014 прошёл полный цикл ~35 мин.
+
+**Корневой инвариант (NFR-1 BRD, нерушимый):** упрощаем только *аналитику/архитектуру*; ни один
+Quality Gate / exit-код deploy-хука / под-гейт (security/merge/coverage/image-freshness) — НЕ
+ослаблен. Горький урок ET-8: срезанная *проверка* = недоделка на проде.
+
+**Факты, сверенные с кодом:**
+- `src/labels.py::has_label` + `plane_sync.fetch_issue_labels`/`get_project_labels` (ORCH-089) —
+  готовый, проверенный аппарат чтения метки Plane (TTL-кэш, нормализация, never-raise,
+  fail-safe → False, источник истины Plane API, не payload).
+- `advance_stage` маршрутизирует через `get_next_stage`/`get_agent_for_stage` → точка ветвления
+  локализуема, `STAGE_TRANSITIONS` ломать не нужно.
+- `check_analysis_approved` (exit-гейт `analysis`) вызывает `check_analysis_complete`, требующий
+  **01/02/03/04** (`src/qg/checks.py:33`). Это и есть точка риска ложной блокировки облегчённого
+  пакета (FR-6).
+- `_ensure_column` (`src/db.py:334`) — идемпотентная аддитивная миграция (паттерн
+  `tasks.cancelled_at`, ORCH-090).
+
+## Решение
+
+### Сводка
+
+Багфикс-трек — **свойство планировщика/точки входа, не Quality Gate**. Задача с меткой Plane
+`Bug` помечается в БД как `track='bug'`; на ребре выхода из `analysis` `advance_stage` применяет
+**чистый routing-override**: `next_stage` → `development` (вместо `architecture`), `next_agent`
+→ `developer` (вместо `architect`). `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, все `check_*` и
+вердикт-ключи — **байт-в-байт прежние**. Распознавание, маршрут и метрика — аддитивно, под
+kill-switch, с областью репо, never-raise, fail-safe → полный цикл.
+
+### D1 — Классификация: метка Plane `Bug`, читаемая в `start_pipeline` (FR-1, AC-1)
+
+Новый leaf `src/bug_fast_track.py` (пустой импорт-граф как `serial_gate`/`labels`: только
+`config`, лениво `labels`/`plane_sync`/`qg.checks`), never-raise. Публичные функции:
+- `bug_fast_track_applies(repo) -> bool` — локальный, без сети, по образцу `_auto_label_applies`:
+  `bug_fast_track_enabled=False` → `False`; `bug_fast_track_repos` (CSV) непустой → только
+  перечисленные репо; **пусто → self-hosting only** (`is_self_hosting_repo`, см. D6). Проверяется
+  **ПЕРВЫМ** → при выключенном флаге нулевой сетевой оверхед, enduro не затронут.
+- `is_bug_task(work_item_id, project_id) -> bool` — `bug_fast_track_applies` уже проверен
+  вызывающим; делегирует в `labels.has_label(work_item_id, settings.bug_fast_track_label,
+  project_id)` (дефолт метки `Bug`). Любая ошибка/неоднозначность → `False` (fail-safe → полный
+  цикл).
+
+Чтение метки — **только** в `start_pipeline` (момент старта, сетевой вызов приемлем, как
+ORCH-089), **никогда** в горячем `claim_next_job` (NFR-4).
+
+### D2 — Хранение типа: аддитивная колонка `tasks.track` (OQ-2, NFR-4)
+
+Идемпотентная миграция `_ensure_column(conn, "tasks", "track", "TEXT DEFAULT 'full'")` рядом с
+`tasks.cancelled_at`/`cancel_requested_at` (`src/db.py` init). Значения: `'full'` (дефолт, ВСЕ
+существующие и не-баг задачи) | `'bug'`. Хелперы: `db.set_task_track(task_id, track)` (запись),
+`db.get_task_track(task_id) -> str` (чтение, дефолт `'full'`). Тип читается из **БД** в
+`advance_stage` (NFR-4: горячий путь без сети). Альтернатива «выводить тип повторным чтением
+метки» отвергнута — повторный сетевой вызов в горячем пути запрещён.
+
+`create_task_atomic` НЕ меняет сигнатуру: задача создаётся как `'full'` (DEFAULT), затем
+`start_pipeline` после успешного `created=True` при `is_bug_task` вызывает
+`db.set_task_track(task_id, 'bug')`. Точка входа стадии остаётся `"analysis"` (мини-анализ
+сохраняется, OQ-3/BRD §6 — НЕ чистый hotfix).
+
+### D3 — Routing-override: пропуск `architecture` без правки `STAGE_TRANSITIONS` (FR-2, AC-2)
+
+`get_next_stage`/`get_agent_for_stage` остаются **чистыми** (принимают только стадию, 1:1).
+Override живёт в `advance_stage`, сразу после строки `next_stage = get_next_stage(current_stage)`:
+
+```python
+next_stage = get_next_stage(current_stage)
+# ORCH-019: bug-fast-track skips the architecture stage entirely.
+if current_stage == "analysis" and bug_fast_track.skips_architecture(track):
+    next_stage = "development"
+```
+
+и при запуске следующего агента (строка 464):
+
+```python
+next_agent = get_agent_for_stage(current_stage)        # "analysis" -> "architect"
+if current_stage == "analysis" and next_stage == "development":
+    next_agent = "developer"                            # skip architect run
+```
+
+`track` читается один раз в начале `advance_stage` (`db.get_task_track(task_id)`). Чистый
+предикат `bug_fast_track.skips_architecture(track) -> bool` (== `track == 'bug'` под
+`bug_fast_track_enabled`; иначе `False`). Багфикс-задача физически НЕ попадает в стадию
+`architecture` → её exit-гейт `check_architecture_done` и требование `06-adr/` не исполняются для
+багфикса. Для не-баг задач (`track='full'`) поведение **байт-в-байт** прежнее.
+
+**Сопутствующая правка телеметрии:** строка 386 стампит `mark_brd_review_ended` при
+`analysis → architecture`. Для багфикса next_stage = `development`, поэтому условие расширяется до
+`current_stage == "analysis" and next_stage in ("architecture", "development")` — чтобы метрика
+«твоё время» (ORCH-087) оставалась честной на багфикс-треке. Не влияет на гейты.
+
+### D4 — Quality Gate `analysis`: НЕ трогаем; lite-пакет эмитит все 4 файла (FR-3/FR-6, OQ-6, AC-3)
+
+**Корневой инвариант диктует минимальную поверхность изменения гейтов = ноль.**
+`check_analysis_complete` (требует 01/02/03/04) и `check_analysis_approved` остаются **байт-в-байт
+прежними**. Багфикс-аналитик (`analyst.md` lite-режим) всё равно эмитит **все 4** файла, но в
+облегчённой багфикс-форме: `01-brd.md` = короткий bug-report (симптом / шаги воспроизведения /
+локализация / причина), `02-trz.md` + `03-acceptance-criteria.md` = краткие bug-shaped заглушки,
+`04-test-plan.yaml` = план **обязательного регресс-теста** (красный до фикса, зелёный после).
+
+Обоснование выбора: доминирующая экономия — пропуск **всей стадии `architecture`** (отдельный
+прогон opus-агента `architect` + ADR), а не число файлов analysis (они эмитятся в ОДНОМ прогоне
+analyst-агента). Сохранение 4-файлового гейта = **сильнейшая** позиция NFR-1 (нулевая поверхность
+правок гейта) ценой почти нулевого оверхеда. Альтернатива «track-aware `check_analysis_complete`
+(для bug требовать только 01/04)» рассмотрена и отвергнута для v1 (D-Alt) — она трогает `check_*`
+и расширяет поверхность риска без существенной экономии.
+
+### D5 — Эскалация в полный цикл (FR-5, AC-5)
+
+Два пути возврата сложного/архитектурного/визуального бага в полный цикл, оба сбрасывают
+`track='bug'` → `'full'` (после чего `advance_stage` маршрутизирует `analysis → architecture`
+штатно):
+1. **Операторский (ручной, v1-дефолт):** админ-эндпоинт `POST /bug-fast-track/escalate?work_item=<id>`
+   (по образцу `POST /serial-gate/unfreeze`, `POST /coverage/baseline`) — `db.set_task_track(...,
+   'full')`, лог + Telegram + Plane-коммент, never-raise. Применять, пока задача в `analysis`
+   (до выхода) — тогда следующий переход уйдёт в `architecture`.
+2. **Решение мини-аналитика:** если на багфикс-треке аналитик определяет, что баг архитектурный,
+   он эмитит **полный** analysis-пакет (включая запрос на `06-adr/`) и помечает в bug-report
+   `escalate: full-cycle` — оператор подтверждает эскалацию эндпоинтом (1). v1 НЕ включает
+   автоматический LLM-авто-триаж сложности (вне объёма, BRD §2.2).
+
+Эскалация обратима, детерминирована, наблюдаема. Багфикс-задача не «застревает» без архитектуры.
+
+### D6 — Область по умолчанию: self-hosting only (OQ-5, NFR-5)
+
+Пустой `bug_fast_track_repos` → **self-hosting only** (`is_self_hosting_repo`, как
+ORCH-089/027/058). Это безопасный дефолт: режим обкатывается на самом орке (где метка `Bug`
+гарантированно заводится оператором), enduro подключается явным добавлением в CSV. Флаги
+(`config.py`): `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`),
+`bug_fast_track_label` (дефолт `Bug`, env `ORCH_BUG_FAST_TRACK_LABEL`), `bug_fast_track_repos`
+(CSV, env `ORCH_BUG_FAST_TRACK_REPOS`).
+
+### D7 — Наблюдаемость стоимости (FR-7, AC-7)
+
+- **`GET /queue`** — аддитивный read-only блок `bug_fast_track` (`bug_fast_track.snapshot()`,
+  never-raise, по образцу `serial_gate`/`auto_labels`/`coverage`): `enabled`, `repos`, `label`,
+  счётчик задач с `track='bug'`, агрегатная метрика экономии (пропущенные стадии / Σ agent-runs /
+  токены / время багфикс-трека против среднего полного цикла из существующей телеметрии
+  `agent_runs`). Существующие ключи `GET /queue` не меняются.
+- **Лог-строка** на решение о маршруте (`analysis → development (bug-fast-track)`).
+- **Опц.** отметка `🐞 багфикс-трек` в Telegram-карточке (`notifications.py`, never-raise).
+
+### D8 — Композиция (NFR-7, AC-9)
+
+- **serial-gate (ORCH-088):** багфикс-задача — обычная задача репо, учитывается в serial-очереди
+  как есть (FIFO `t2.id < jobs.task_id`); точка входа `analysis` не меняется, defer-branch логика
+  не затронута. Маркированный код `serial_gate.py` НЕ правится.
+- **auto-label (ORCH-089):** `autoApprove`/`autoDeploy` работают на багфикс-треке — autoApprove
+  врезка в `_handle_analysis_approved_flow` вызывает `advance_stage(finished_agent=None)`, который
+  применяет D3-override и уходит в `development`. Переиспользуем `labels.has_label`.
+- **coverage-gate (ORCH-027):** союзник BR-4 (структурно ловит «код без теста») — исполняется
+  штатно на ребре `deploy-staging → deploy`.
+- **merge-gate (ORCH-043):** не затронут.
+
+Правки маркированного кода (`advance_stage` несёт врезки ORCH-088/089/027/059/094) — точечные,
+со сверкой их `06-adr/`; зафиксированные инварианты (порядок под-гейтов, merge-lease,
+terminal-sync) НЕ нарушаются: ORCH-019 добавляет ветвление ТОЛЬКО на ребре выхода из `analysis`,
+до всех deploy-edge под-гейтов.
+
+## Альтернативы
+
+- **Track-aware `get_next_stage(stage, task)` / новая стадия в `STAGE_TRANSITIONS`** — отвергнуто:
+  ломает чистоту `stages.py` и риск задеть структуру таблицы (AC-2 FAIL при структурном изменении).
+  Override в `advance_stage` локальнее и держит `STAGE_TRANSITIONS` неизменным.
+- **Track-aware `check_analysis_complete` (bug → только 01/04)** — отвергнуто для v1 (D-Alt):
+  трогает `check_*`, расширяет поверхность риска NFR-1 ради почти нулевой экономии (см. D4).
+  Оставлено как возможное будущее уточнение, если потребуется реальный отказ от 02/03.
+- **Чистый hotfix `start_pipeline → development`, минуя `analysis`** — отвергнуто как дефолт
+  (BRD §6): теряется фиксация регресс-теста как контракта приёмки и трассируемость (урок ET-8).
+- **Тип задачи из payload вебхука / повторное чтение метки в `claim_next_job`** — отвергнуто:
+  payload не несёт `type` (источник истины — Plane API); сеть в горячем claim запрещена (NFR-4).
+- **Чтение типа без БД-колонки** — отвергнуто: потребовало бы сетевого вызова в горячем пути.
+
+## Последствия
+
+- **+** Багфикс минует целую стадию `architecture` (один прогон opus-агента `architect` + ADR) —
+  основная экономия токенов/времени; гейты качества **байт-в-байт** сохранены.
+- **+** Полностью аддитивно: kill-switch `False` или неприменимый репо → путь старта и маршрут
+  идентичны текущим (AC-6, нулевая регрессия для enduro и orchestrator).
+- **+** Переиспользует проверенный аппарат ORCH-089 (label-чтение) и паттерн leaf+флаги+snapshot.
+- **−** Багфикс-аналитик всё равно эмитит 02/03 (краткие заглушки) ради неизменности гейта —
+  принятый компромисс (D4); экономия на их содержании, не на их наличии.
+- **−** Эскалация v1 требует операторского действия (эндпоинт) — авто-триаж сложности отложен
+  (BRD §2.2). Митигатор: путь эскалации документирован, обратим, наблюдаем (D5).
+- **Откат:** `bug_fast_track_enabled=False` (мгновенно, 1:1 прежнее поведение); колонка
+  `tasks.track` остаётся (аддитивна, дефолт `'full'`, безвредна). Полный откат — revert PR;
+  миграция идемпотентна, остаточная колонка не мешает.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-019/01-brd.md`
+- TRZ: `docs/work-items/ORCH-019/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-019/03-acceptance-criteria.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0032-bug-fast-track.md`
+- Data: `docs/work-items/ORCH-019/08-data-requirements.md`
+- Infra: `docs/work-items/ORCH-019/07-infra-requirements.md`
+- Риски: `docs/work-items/ORCH-019/10-tech-risks.md`
+- Сверено по коду: `src/stages.py`, `src/stage_engine.py` (advance_stage:175-477),
+  `src/webhooks/plane.py::start_pipeline` (505-684), `src/labels.py`,
+  `src/qg/checks.py` (check_analysis_complete:33, check_analysis_approved:286,
+  check_architecture_done:62), `src/db.py` (_ensure_column:334, create_task_atomic:433)
+</content>
+</invoke>

docs/work-items/ORCH-019/07-infra-requirements.md

@@ -0,0 +1,62 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфраструктурные требования (Infra Requirements): ORCH-019 — Багфикс-трек
+
+Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
+
+> **Топология не меняется.** Один прод-контейнер `orchestrator` (8500) + staging (8501) на mva154,
+> общая SQLite-БД. ORCH-019 — чисто прикладное изменение под флагом. Этот документ фиксирует
+> **предусловия включения** (Plane-метка + env-флаги), не новую инфраструктуру.
+
+---
+
+## 1. Предусловие: метка `Bug` в Plane-проекте (блокирующее для активации)
+
+Багфикс-трек активируется по метке Plane с именем `bug_fast_track_label` (дефолт `Bug`),
+читаемой аппаратом ORCH-089 (`fetch_issue_labels`/`get_project_labels`). **Метка должна
+существовать** в Plane-проекте orchestrator (и в любом проекте, добавленном в
+`bug_fast_track_repos`).
+
+- Её **отсутствие = fail-safe полный цикл** (`has_label → False`), не сбой. Включение флага без
+  заведённой метки безопасно, но эффекта не даёт.
+- Создаётся оператором в Plane вручную (как `autoApprove`/`autoDeploy` для ORCH-089).
+
+## 2. Конфигурация (env-флаги, `src/config.py`)
+
+| Флаг | Env | Дефолт | Назначение |
+|------|-----|--------|-----------|
+| `bug_fast_track_enabled` | `ORCH_BUG_FAST_TRACK_ENABLED` | `False` | kill-switch; `False` → путь старта/маршрут строго прежние (нулевая регрессия) |
+| `bug_fast_track_label` | `ORCH_BUG_FAST_TRACK_LABEL` | `Bug` | имя метки Plane для распознавания бага |
+| `bug_fast_track_repos` | `ORCH_BUG_FAST_TRACK_REPOS` | `""` (пусто) | CSV-область; пусто → **self-hosting only** (`orchestrator`) |
+
+> Рекомендация выката: `enabled=False` до момента, когда метка `Bug` заведена в Plane и проведён
+> staging-прогон. Дефолт области (пустой CSV) = self-hosting only → enduro не затронут даже при
+> включённом флаге.
+
+## 3. Зависимости / образ
+
+- **Новых pip-зависимостей нет.** Переиспользуются существующие `httpx`/`plane_sync` (label-чтение)
+  и `sqlite3` (колонка `tasks.track`). Пересборка образа из-за зависимостей не требуется.
+- **Миграция БД** (`tasks.track`) применяется идемпотентно при старте приложения (`_ensure_column`)
+  — без ручного шага, без даунтайма (ALTER ADD COLUMN на SQLite — мгновенный).
+
+## 4. Self-hosting безопасность (NFR-6)
+
+- Механизм **не** рестартит/не роняет прод-контейнер, **не** пушит/force-push в `main`. Это
+  routing-решение планировщика + аддитивная колонка + read-only наблюдаемость.
+- Выкат самого ORCH-019 на прод орка идёт штатным конвейером через обязательный
+  `deploy-staging` (8501) → `Confirm Deploy` (ORCH-059). Топология/процедура — `docs/operations/INFRA.md`.
+
+## 5. Новый эндпоинт (эскалация)
+
+`POST /bug-fast-track/escalate?work_item=<id>` — админ-ручка возврата задачи в полный цикл
+(`track → 'full'`), по образцу `POST /serial-gate/unfreeze`. Без новой инфраструктуры (тот же
+FastAPI-приложение/порт). Read-only блок `bug_fast_track` добавляется в существующий `GET /queue`.
+</content>

docs/work-items/ORCH-019/08-data-requirements.md

@@ -0,0 +1,64 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным (Data Requirements): ORCH-019 — Багфикс-трек
+
+Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
+
+> ⚠️ Общая прод-БД (self-hosting + enduro). Только **аддитивные, идемпотентные** миграции;
+> существующие контракты таблиц не меняются.
+
+---
+
+## 1. Новая колонка `tasks.track`
+
+| Атрибут | Значение |
+|---------|----------|
+| Таблица | `tasks` |
+| Колонка | `track` |
+| Тип | `TEXT` |
+| DEFAULT | `'full'` |
+| Допустимые значения | `'full'` (дефолт; ВСЕ существующие и не-баг задачи) \| `'bug'` |
+| Миграция | `_ensure_column(conn, "tasks", "track", "TEXT DEFAULT 'full'")` (идемпотентно, паттерн `tasks.cancelled_at` ORCH-090) |
+| Размещение | рядом с `_ensure_column(conn, "tasks", "cancel_requested_at", ...)` в init `src/db.py` |
+
+**Семантика:** тип задачи (полный цикл / багфикс). Записывается в `start_pipeline` после
+успешного `create_task_atomic` (`created=True`) при `is_bug_task==True`. Читается в `advance_stage`
+для routing-override (D3) — из БД, **никогда** из сети (NFR-4).
+
+## 2. Хелперы доступа (`src/db.py`)
+
+| Хелпер | Контракт |
+|--------|----------|
+| `set_task_track(task_id: int, track: str) -> None` | `UPDATE tasks SET track=? WHERE id=?`; идемпотентно; never-raise на уровне вызова в `start_pipeline`/escalate |
+| `get_task_track(task_id: int) -> str` | `SELECT track FROM tasks WHERE id=?`; отсутствие/NULL → `'full'` (fail-safe → полный цикл) |
+
+## 3. Что НЕ меняется
+
+- Сигнатура `create_task_atomic(plane_id, work_item_id, repo, branch, stage, title)` —
+  **без изменений** (задача создаётся как `track='full'` по DEFAULT, тип проставляется отдельным
+  `set_task_track`).
+- Существующие колонки `tasks` (прочие), таблицы `jobs`, `job_deps`, `agent_runs`,
+  `coverage_baseline`, `repo_freeze`, `tracker_messages` — **без изменений**.
+- `claim_next_job` — **без изменений** (не читает `track`; сеть/маршрут в горячем claim не вводятся).
+
+## 4. Обратная совместимость / откат
+
+- Колонка аддитивна с безопасным DEFAULT `'full'` → существующие строки и enduro-задачи ведут
+  себя как сегодня без обратной записи.
+- Откат фичи (`bug_fast_track_enabled=False`) не требует удаления колонки: при выключенном флаге
+  `track` не влияет на маршрут (`skips_architecture` → `False`). Остаточная колонка безвредна.
+- Полный revert PR: миграция `_ensure_column` идемпотентна; повторный запуск на БД с уже
+  существующей колонкой — no-op.
+
+## 5. Объём данных / производительность
+
+- Одна `TEXT`-колонка на строку `tasks` (низкая кардинальность: 2 значения). Индекс не требуется
+  (чтение по `id` PK в `advance_stage`; агрегат для `GET /queue` — редкий read-only скан).
+</content>

docs/work-items/ORCH-019/10-tech-risks.md

@@ -0,0 +1,39 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-019 — Багфикс-трек
+
+Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
+
+> Шкала: вероятность × влияние ∈ {Низк., Средн., Выс.}. Каждый риск — с митигатором, привязанным
+> к ADR-001 / AC.
+
+---
+
+| ID | Риск | Вер. | Влияние | Митигатор |
+|----|------|------|---------|-----------|
+| R-1 | **Срезали лишнее** — ошибочный пропуск гейта качества → недоделка на проде (урок ET-8). | Низк. | Выс. | NFR-1 диктует **нулевую** поверхность правок гейтов (D4): `STAGE_TRANSITIONS`/`QG_CHECKS`/все `check_*`/вердикт-ключи — байт-в-байт; режется ТОЛЬКО стадия `architecture`. Тест AC-3: на багфикс-треке отрабатывают все гейты. |
+| R-2 | **Сложный баг под меткой `Bug`** уходит на фаст-трек и упирается в отсутствие архитектуры. | Средн. | Средн. | Эскалация D5 (эндпоинт `escalate` + self-escalate мини-аналитика) сбрасывает `track→full` → задача идёт через `architecture`. AC-5. |
+| R-3 | **Регресс-тест не написан** (developer «забыл») → рецидив бага. | Средн. | Выс. | BR-4: обязательный TC в `04-test-plan.yaml` + reviewer-ось (фикс без теста → REQUEST_CHANGES) + структурный союзник coverage-gate ORCH-027. AC-4. |
+| R-4 | **Fail-safe инвертирован** — ошибка чтения метки молча срежет стадии. | Низк. | Выс. | never-raise leaf `bug_fast_track.py`: любая ошибка/неоднозначность/`None`-labels → `is_bug_task=False` → полный цикл; `get_task_track` при NULL → `'full'`. AC-6. |
+| R-5 | **Конфликт с serial-gate/auto-label** при изменённой точке входа. | Низк. | Средн. | Точка входа НЕ меняется (задача стартует на `analysis`, ветвление — только на ребре выхода). serial_gate/auto-label маркированный код не правится. Интеграционный тест композиции (AC-9). |
+| R-6 | **Ложная блокировка** облегчённого пакета exit-гейтом `analysis` (`check_analysis_complete` требует 01/02/03/04). | Низк. | Средн. | D4: гейт НЕ трогаем; lite-аналитик эмитит все 4 файла (02/03 — краткие заглушки). FR-6/OQ-6. |
+| R-7 | **Правка маркированного `advance_stage`** (несёт врезки ORCH-088/089/027/059/094) сломает чужой инвариант. | Низк. | Выс. | Врезка ORCH-019 — ТОЛЬКО на ребре выхода из `analysis`, ДО всех deploy-edge под-гейтов; порядок под-гейтов/merge-lease/terminal-sync не затронуты (CLAUDE.md §9: сверка `06-adr/` затронутых ORCH-NNN). |
+| R-8 | **Телеметрия `mark_brd_review_ended`** не сработает на багфиксе (next=`development`, не `architecture`) → искажённая метрика «твоё время». | Низк. | Низк. | D3: условие расширено до `next_stage in ("architecture","development")`. Не влияет на гейты. |
+| R-9 | **Метрика экономии** (FR-7) вводит в заблуждение (несравнимые задачи). | Низк. | Низк. | Метрика помечена как относительная оценка из существующей телеметрии `agent_runs`; без новой тяжёлой инфраструктуры; read-only, never-raise. AC-7. |
+
+---
+
+## Сводный вывод
+
+Доминирующий риск — **R-1 (срезали лишнее)**; он структурно закрыт нулевой поверхностью правок
+гейтов (D4) — изменение касается планировщика/точки входа, а не Quality Gate. Остальные риски
+покрыты паттерном leaf+флаги+fail-safe (ORCH-088/089/027) и обратимой эскалацией (D5). Откат —
+мгновенный через `bug_fast_track_enabled=False`.
+</content>

docs/work-items/ORCH-019/12-review.md

@@ -0,0 +1,108 @@
+---
+verdict: APPROVED
+work_item: ORCH-019
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-019
+version: 1
+---
+
+# Review ORCH-019 — Багфикс-трек (упрощённый/дешёвый маршрут для багов)
+
+## Summary
+
+Реализация соответствует ТЗ (`02-trz.md`), ADR-001 и всем 9 критериям приёмки
+(`03-acceptance-criteria.md`). Корневой инвариант NFR-1 («срезается только аналитика/архитектура;
+ни один Quality Gate не тронут») соблюдён **структурно**: `src/stages.py` и `src/qg/checks.py` —
+**пустой diff**; маршрутизация багфикса реализована чистым routing-override в `advance_stage`, как
+и предписывал ADR (D3). Полный регресс `tests/` зелёный (**1551 passed**), 46 целевых тестов
+ORCH-019 (6 suites) — PASS. Документация обновлена исчерпывающе во всех требуемых поверхностях.
+Findings уровня P0/P1 — нет. → **APPROVED**.
+
+## Проверка по осям
+
+### 1. Соответствие ТЗ / Acceptance Criteria
+- **AC-1 (классификация по метке `Bug`)** ✓ — `bug_fast_track.is_bug_task` делегирует в
+  `labels.has_label` (источник истины — Plane API, не payload); `applies(repo)` (локальный)
+  проверяется ПЕРВЫМ в `start_pipeline` → при выключенном флаге нулевой сетевой оверхед.
+- **AC-2 (пропуск `architecture`)** ✓ — override на ребре выхода из `analysis`
+  (`next_stage → development`, `next_agent → developer`); `STAGE_TRANSITIONS`/`get_next_stage`/
+  `get_agent_for_stage` остались чистыми (1:1). Анти-регресс структуры — TC-06.
+- **AC-3 (все QG сохранены — корневой инвариант)** ✓ — `git diff` по `src/stages.py`/`src/qg/`
+  пуст; вердикт-ключи и порядок под-гейтов не тронуты (TC-07). Подтверждено независимой проверкой
+  diff, не только тестом.
+- **AC-4 (обязательный регресс-тест)** ✓ — ось добавлена в `.openclaw/agents/reviewer.md`
+  («фикс без теста-фиксатора → finding ≥P1»); `04-test-plan.yaml` несёт требование. (Сам ORCH-019 —
+  feature, не bugfix, поэтому правило к нему не применяется; покрытие — 46 содержательных тестов.)
+- **AC-5 (эскалация)** ✓ — `POST /bug-fast-track/escalate` (`db.set_task_track 'bug'→'full'`,
+  Telegram+Plane-коммент, never-raise) + self-escalate мини-аналитика (`analyst.md`).
+- **AC-6 (fail-safe / нулевая регрессия)** ✓ — `bug_fast_track_enabled` kill-switch; все публичные
+  функции leaf'а never-raise → False (full cycle); `get_task_track` деградирует в `'full'`.
+  Дефолт `True` согласован со всеми sibling-флагами (serial_gate/auto_label/coverage/stop/… все
+  `= True` при пустом scope = self-hosting only).
+- **AC-7 (наблюдаемость)** ✓ — read-only блок `bug_fast_track` в `GET /queue` (`snapshot()`,
+  never-raise) + отметка `🐞` в Telegram-карточке (never-raise) + лог-строки на решение.
+- **AC-8 (аддитивность / self-hosting)** ✓ — `_ensure_column(tasks, track, "TEXT DEFAULT 'full'")`
+  идемпотентна (TC-15); прод-контейнер/`main` не трогаются; полный `tests/` зелёный.
+- **AC-9 (композиция)** ✓ — serial-gate/auto-label/coverage/merge — тест композиции зелёный
+  (TC-14); override применяется ДО всех deploy-edge под-гейтов.
+
+### 2. Соответствие ADR
+Реализация точно следует ADR-001 (D1–D8): leaf `src/bug_fast_track.py`, колонка `tasks.track`,
+override в `advance_stage`, эскалация-эндпоинт, область self-hosting-only. Сквозной ADR
+`adr-0032-bug-fast-track.md` присутствует.
+**Трассировка:** `advance_stage` несёт маркеры ORCH-088/089/027/059/094; врезка ORCH-019 добавляет
+ветвление ТОЛЬКО на ребре выхода из `analysis` (до deploy-edge под-гейтов) — зафиксированные
+инварианты (порядок под-гейтов, merge-lease, terminal-sync) не нарушены. Сверено по diff. Расширение
+`mark_brd_review_ended` на `analysis → development` (ORCH-087 метрика) гейтов не касается.
+
+### 3. Качество кода
+- Leaf чист (импортирует только `config`, лениво `labels`/`db`/`qg.checks`), never-raise контракт
+  соблюдён везде, публичные функции снабжены docstrings. ✓
+- Next-agent override (`next_stage == "development"`) безопасен: единственный путь к
+  `analysis → development` — сам багфикс-override (штатно `get_next_stage("analysis") == "architecture"`). ✓
+- `get_task_by_work_item_id`/`add_comment`/`set_task_track`/`get_task_track` существуют и
+  совместимы по сигнатурам. ✓
+
+### 4. Документация — обязательная проверка
+`src/` изменён → документация ДОЛЖНА быть обновлена. **Обновлено в том же PR:**
+- `docs/architecture/README.md` — раздел «Багфикс-трек (ORCH-019)» + блок `bug_fast_track` в `GET /queue`;
+- `README.md` — таблица env (`ORCH_BUG_FAST_TRACK_*`) + обзорный раздел;
+- `.env.example` — три новых переменных;
+- `docs/architecture/adr/adr-0032-bug-fast-track.md` (сквозной) + `06-adr/ADR-001`;
+- `docs/architecture/internals.md`, `CLAUDE.md`, `CHANGELOG.md` (`feat:`);
+- `07-infra-requirements.md` / `08-data-requirements.md` / `10-tech-risks.md`;
+- `.openclaw/agents/analyst.md` (lite-пакет + self-escalate) и `reviewer.md` (ось регресс-теста).
+
+Все поверхности из §8 ТЗ покрыты. **Обзорная витрина README** — добавлен раздел, ничего из «Известных
+ограничений» не оставлено открытым в нарушение ORCH-079.
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice to have
+- [ ] `snapshot.est_saved_architecture_runs == total_bug_tasks` считает ВСЕ багфикс-задачи, включая
+  `cancelled` (которые могли не дойти до пропуска `architecture`). Косметическая неточность метрики
+  экономии; на гейты/маршрут не влияет. Можно сузить до `stage NOT IN ('cancelled')` при случае.
+
+## Документация
+Обновлена полностью и согласованно во всех требуемых поверхностях (architecture/README, README env +
+обзор, оба ADR, internals, CLAUDE.md, CHANGELOG, .env.example, промпты analyst/reviewer,
+infra/data/risks). Расхождений код↔документация не обнаружено. Требований к доработке документации
+нет.
+
+## Вердикт
+Нет findings уровня P0/P1; документация обновлена; корневой инвариант подтверждён независимой
+проверкой diff и зелёным полным регрессом (1551 passed). → **APPROVED**.

docs/work-items/ORCH-019/13-test-report.md

@@ -0,0 +1,84 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-019
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-019
+---
+
+# Test Report — ORCH-019 — Багфикс-трек (упрощённый/дешёвый маршрут для багов)
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-019-` (ветка `feature/ORCH-019-`)
+- Дата: 2026-06-10T00:53:34Z
+- Предусловие: review `12-review.md` = `verdict: APPROVED` ✓
+
+## Smoke API (read-only)
+| Endpoint | Результат | Примечание |
+|----------|-----------|------------|
+| `GET /health` | PASS | `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS | отвечает; ORCH-019 (task 84) виден на стадии `testing` |
+| `GET /queue` | PASS | блок `serial_gate` присутствует (ORCH-088) ✓; `auto_labels` присутствует ✓ |
+
+> Прод-контейнер (8500) исполняет код **до** ORCH-019 (фича ещё не задеплоена), поэтому блока
+> `bug_fast_track` в живом `/queue` ожидаемо нет — это не регресс смока. Обязательные для смока
+> блоки `serial_gate` и `auto_labels` присутствуют. Новый блок `bug_fast_track` верифицирован
+> юнит/интеграционными тестами `test_queue_endpoint.py` (TC-13) на коде ветки. Smoke — read-only,
+> прод-контейнер не трогался.
+
+## Результаты — покрытие TC из `04-test-plan.yaml`
+
+| TC ID | Описание (кратко) | Тип | Тесты | AC | Результат |
+|-------|-------------------|-----|-------|----|-----------|
+| TC-01 | `is_bug_task()` True для метки `Bug`; источник — Plane API, не payload | unit | `test_tc01_is_bug_task_true`, `test_tc01_label_from_plane_api_not_payload` | AC-1 | PASS |
+| TC-02 | `is_bug_task()` False при отсутствии/неоднозначной метке/`labels=None` (fail-safe) | unit | `test_tc02_label_absent`, `test_tc02_labels_none`, `test_tc02_label_ambiguous`, `test_tc02_empty_label_config` | AC-1/AC-6 | PASS |
+| TC-03 | `bug_fast_track_applies(repo)`: локальная область ПЕРВОЙ; выключенный флаг → без сети | unit | `test_tc03_empty_csv_self_hosting_only`, `test_tc03_csv_membership`, `test_tc03_killswitch_off_no_network` | AC-6 | PASS |
+| TC-04 | never-raise: исключение в fetch labels → деградация в False (полный цикл) | unit | `test_tc04_is_bug_task_never_raises`, `test_tc04_applies_never_raises` | AC-6 | PASS |
+| TC-05 | Маршрут: bug → next stage после analysis = `development`; не-баг = `architecture` | unit | `test_tc05_bug_task_skips_architecture`, `test_tc05_full_task_keeps_architecture`, `test_tc05_killswitch_off_bug_keeps_architecture`, `test_tc05_bug_only_affects_analysis_edge` | AC-2 | PASS |
+| TC-06 | `STAGE_TRANSITIONS` структурно не изменён (анти-регресс) | unit | `test_tc06_stage_transitions_unchanged`, `test_tc06_get_next_stage_pure` | AC-2 | PASS |
+| TC-07 | `QG_CHECKS`/сигнатуры `check_*`/вердикт-ключи не изменены (имя+регистр) | unit | `test_tc07_qg_checks_registry_unchanged`, `test_tc07_verdict_keys_preserved` | AC-3 | PASS |
+| TC-08 | E2E багфикс-трек проходит development→…→deploy, минуя architecture, все гейты | integration | `test_tc08_bug_task_full_walk_skips_architecture` | AC-2/AC-3 | PASS |
+| TC-09 | `start_pipeline`: метка Bug → bug-track; без метки → full-track | integration | `test_tc09_bug_label_creates_bug_track`, `test_tc09_no_label_creates_full_track` | AC-1 | PASS |
+| TC-10 | Fail-safe: `enabled=False` → метка Bug идёт полным циклом (нулевая регрессия) | integration | `test_tc10_killswitch_off_bug_label_full_cycle` | AC-6 | PASS |
+| TC-11 | Эскалация: `'bug'→'full'` → штатный маршрут с architecture | integration | `test_tc11_escalate_returns_to_full_cycle`, `test_tc11_escalate_unknown_work_item`, `test_tc11_escalate_missing_arg`, `test_tc11_escalate_idempotent_on_full` | AC-5 | PASS |
+| TC-12 | `check_analysis_*` не блокирует ложно lite-пакет; не ослаблен для не-баг | unit | `test_tc12_bug_lite_package_with_all_four_passes`, `test_tc12_missing_file_still_fails_for_any_track`, `test_tc12_signature_has_no_track_param` | AC-3/FR-6 | PASS |
+| TC-13 | `GET /queue` несёт read-only блок `bug_fast_track`; существующие ключи целы | integration | `test_queue_has_bug_fast_track_block_and_keeps_existing_keys`, `test_queue_bug_fast_track_counts_bug_tasks` | AC-7 | PASS |
+| TC-14 | Композиция: bug-задача учтена serial-gate; autoApprove/autoDeploy применимы | integration | `test_tc14_bug_task_counts_as_active_in_serial_gate`, `test_tc14_bug_task_itself_gated_behind_predecessor`, `test_tc14_bug_task_claimable_once_predecessor_done`, `test_tc14_auto_label_applies_track_agnostic` | AC-9 | PASS |
+| TC-15 | Миграция `tasks.track` аддитивна/идемпотентна; дефолт `'full'` | unit | `test_tc15_track_column_present_with_default`, `test_tc15_init_db_idempotent`, `test_tc15_helpers_round_trip`, `test_tc15_get_task_track_missing_row_failsafe` | AC-8 | PASS |
+
+**Итог покрытия:** все 15 TC из `04-test-plan.yaml` выполнены и сопоставлены с критериями
+`03-acceptance-criteria.md` (AC-1…AC-9). Непокрытых/пропущенных TC нет.
+
+## Вывод pytest
+
+### Целевые suite ORCH-019 (6 файлов + queue/migrations)
+```
+$ pytest tests/test_bug_fast_track.py tests/test_bug_fast_track_routing.py \
+         tests/test_bug_fast_track_gates.py tests/test_bug_fast_track_e2e.py \
+         tests/test_bug_fast_track_escalation.py tests/test_bug_fast_track_composition.py \
+         tests/test_queue_endpoint.py tests/test_db_migrations.py -v
+...
+======================== 46 passed, 1 warning in 2.51s =========================
+```
+46/46 целевых тестов — PASS.
+
+### Полный регресс
+```
+$ pytest tests/ -q --tb=short
+........................................................................ [100%]
+1551 passed, 1 warning in 56.64s
+```
+1551/1551 — PASS, 0 failed. (Единственный warning — известный Pydantic V2 deprecation в
+`src/config.py:8`, не относится к ORCH-019.)
+
+## Итог
+**PASS** — полный регресс (1551 passed) и целевые suites ORCH-019 (46 passed) зелёные; smoke API
+(`/health`/`/status`/`/queue` с блоками `serial_gate`+`auto_labels`) — OK; все 15 TC выполнены и
+сопоставлены с AC-1…AC-9. Корневой инвариант NFR-1 (неизменность `STAGE_TRANSITIONS`/`QG_CHECKS`/
+вердикт-ключей) подтверждён анти-регресс-тестами TC-06/TC-07. → стадия переходит на `deploy-staging`.

docs/work-items/ORCH-019/14-deploy-log.md

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-019
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-036 executable self-deploy
+
+Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
+
+Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-019/15-staging-log.md

@@ -0,0 +1,51 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-019
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+timestamp: 2026-06-10T00:56:51Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` environment (port 8501),
+run inside the `orchestrator-staging` container (canonical path, ORCH-048):
+
+```
+docker exec orchestrator-staging \
+  python3 /repos/orchestrator/scripts/staging_check.py \
+  --base-url http://localhost:8501 --mode stub
+```
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+- REAL failed: **none**
+- SANDBOX_INFRA waived (ORCH-061): C9a, C9b
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Check breakdown
+
+| Block | Check | Result |
+|-------|-------|--------|
+| A SMOKE | A1 GET /health → 200 status=ok | ✓ PASS |
+| A SMOKE | A2 GET /queue → 200 with counts/max_concurrency/resilience | ✓ PASS |
+| A SMOKE | A3 ORCH_STAGING=true (not prod) | ✓ PASS |
+| B ACCESS | B4 Plane: sandbox project accessible | ✓ PASS |
+| B ACCESS | B5 Gitea: orchestrator-sandbox accessible, push=true | ✓ PASS |
+| B ACCESS | B6 Registry: sandbox present, prod ET/ORCH absent | ✓ PASS |
+| C E2E | C7 Create issue in Plane SANDBOX | ✓ PASS |
+| C E2E | C8 Trigger pipeline via /webhook/plane | ✓ PASS |
+| C E2E | C9a Branch appears in orchestrator-sandbox | ✗ FAIL (INFRA-WAIVED) |
+| C E2E | C9b Analyst job enqueued in staging queue | ✗ FAIL (INFRA-WAIVED) |
+
+Cleanup: Plane issue deleted (HTTP 204); no branch to delete.
+
+Exit-code → verdict mapping unchanged: exit 0 → `staging_status: SUCCESS`. Waived checks are not
+re-judged (trust the exit code; the two infra-only checks C9a/C9b depend on SANDBOX bot accounts
+being project members, not on the pipeline). Staging gate **PASSED**; task advances to `deploy`.

docs/work-items/ORCH-057/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: BUG/follow-up ORCH-040: normalize legacy root-owned файлы при миграции на uid 1000 (one-time + защита)
+
+Work Item ID: ORCH-057
+
+## Description
+
+TBD

docs/work-items/ORCH-057/01-brd.md

@@ -0,0 +1,140 @@
+---
+work_item: ORCH-057
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000 (one-time + защита)
+
+Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+ORCH-040 перевёл оба контейнера (`orchestrator` 8500, `orchestrator-staging` 8501) с root
+на `user: "1000:1000"` (slin). Изменён был **только** `docker-compose.yml`. Однако bind-mount
+`/home/slin/repos → /repos` уже содержал файлы и каталоги, созданные **прежним root-контейнером**
+(`root:root`). Смена `user:` владельца существующих файлов НЕ меняет.
+
+**Реальный инцидент (прод, 06.06, поймали на первом запуске ORCH-043).** Первый job под uid 1000
+упал на стадии **launch** (НЕ на коде задачи):
+
+```
+fatal: could not create leading directories of
+'/repos/_wt/orchestrator/feature_ORCH-043-.../.git': Permission denied
+```
+
+Причина: `/repos/_wt/` и старые worktree-папки = `root:root` → uid 1000 не может создать рядом
+новый каталог worktree. Установлено фактически: ошибка возникает в `src/git_worktree.py::ensure_worktree`
+(вызов `git worktree add`), куда конвейер приходит из `src/agents/launcher.py::_spawn` (стр. 500)
+и `_materialize_deferred_branch` (ORCH-088). Агент даже не стартует — падает создание worktree.
+
+**Ручной workaround (применён Стрим, прод снова рабочий, ОДНОРАЗОВО):**
+```
+sudo chown -R 1000:1000 /home/slin/repos/_wt
+sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git /home/slin/repos/enduro-trails/.git
+sudo chown -R 1000:1000 /home/slin/repos/orchestrator   # +data/runs/*.log (37 root-логов)
+```
+
+ADR-001 ORCH-040 упоминал «массовый chown старых root-файлов» лишь абстрактно («вне объёма кода»,
+«разовая операция Owner») и НЕ дал конкретной процедуры чистки legacy worktree — поэтому deployer
+её не выполнил, и баг проявился в проде. Прод сейчас рабочий (ручной фикс наложен), но проблема
+**воспроизведётся** на чистой среде, новом репо или после любого исторического запуска под root,
+если её не закрыть кодом + процедурой.
+
+**Это follow-up / закрытие недоделанного AC ORCH-040** (legacy-файлы), а не новая фича.
+
+## 2. Объём (scope)
+
+### В объёме
+- **Защита launcher (код):** при `Permission denied` на создании worktree выдавать **внятную,
+  диагностируемую** ошибку «legacy root-файлы в `/repos/_wt` — требуется нормализация прав»
+  с указанием команды, а НЕ сырой `git fatal`.
+- **Раннее обнаружение (код):** детектирование наличия файлов с `uid != <target_uid>` в
+  `ORCH_REPOS_DIR` (включая `_wt`, `.git/objects`, `.git/worktrees`, `data/runs`) при старте
+  контейнера / перед претензией на job — чтобы конвейер падал **внятно и заранее**, а не сырым
+  git-фаталом на launch.
+- **Процедура нормализации (документация):** в `docs/operations/INFRA.md` (и собственный ADR
+  ORCH-057) — обязательная одноразовая процедура нормализации legacy root-файлов при миграции uid,
+  с точными командами и областью охвата (`_wt`, `.git`, `data/runs`).
+- **Опционально (по решению архитектора):** механизм one-time нормализации при буте/деплое —
+  init-контейнер/хук под root, либо blocking-entrypoint-проверка.
+
+### Вне объёма
+- Изменение логики конвейера, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, схемы БД.
+- Пересмотр самого решения ORCH-040 (uid 1000) — оно принято и остаётся.
+- Перенос инстанса на другой хост / другой uid (отдельная задача при миграции хоста).
+- Массовая ретроактивная переработка ADR-001 ORCH-040 (его история не переписывается;
+  допускается forward-breadcrumb-ссылка на ORCH-057 — решает архитектор).
+- Выбор конкретного варианта реализации one-time нормализации (a/b/в) — зона архитектора (06-adr).
+
+## 3. Заинтересованные стороны
+
+- **Заказчик / Owner** — Слава (homenet542), инициатор; принимает результат.
+- **Эксплуатация** — Стрим (применял ручной workaround); потребитель процедуры в INFRA.md.
+- **Затронутые проекты** — `orchestrator` (self-hosting) и `enduro-trails` (общий инстанс, общая
+  очередь, общий bind-mount `/repos`): нормализация прав `/repos` касается обоих репо.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1** — После миграции контейнера на новый uid конвейер запускается **без ручного `chown`**:
+  либо авто-нормализация прав, либо **явная блокирующая ошибка с инструкцией** (никогда не сырой
+  `git fatal` на launch).
+- **BR-2** — На свежей среде / новом репо / после исторического запуска под root проблема
+  **не воспроизводится** (детект + понятная диагностика срабатывают до падения агента).
+- **BR-3** — `INFRA.md` и ADR содержат **конкретную процедуру** нормализации legacy root-файлов
+  (точные команды, область: `_wt`, `.git/objects`, `.git/worktrees`, `data/runs`), помеченную как
+  обязательный шаг миграции uid.
+- **BR-4** — Несоответствие владельца наблюдаемо: оператор узнаёт о проблеме из лога/уведомления/
+  read-only статуса, а не по падению задачи на launch.
+- **BR-5** — Защита `ensure_worktree` распознаёт класс ошибки «нет прав на создание worktree» и
+  сообщает причину + лечащую команду (опц. — авто-самолечение, если процесс имеет права).
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 (self-hosting безопасность)** — Решение **никогда** не перезапускает/не роняет
+  прод-контейнер `orchestrator`, не трогает `main`/force-push/прод-образ. Контейнер бежит под
+  uid 1000 (без root) → код **не может** делать `chown` без root; код ограничивается
+  детектом + внятной диагностикой/блокировкой, а фактический `chown` — операторская/init-процедура.
+- **NFR-2 (общий инстанс)** — Нулевая регрессия для `enduro-trails`: feature под kill-switch и
+  scope-флагом (по образцу `serial_gate`/`coverage_gate`); выключено → поведение 1:1 как до ORCH-057.
+- **NFR-3 (never-raise / fail-safe)** — Детект-леаф никогда не бросает наружу неожиданное исключение
+  и не блокирует старт сервиса по своей ошибке; деградирует в WARNING.
+- **NFR-4 (идемпотентность)** — Повторный запуск детекта/нормализации на уже корректной среде —
+  no-op без побочных эффектов.
+- **NFR-5 (обратимость)** — Поведение откатывается выключением kill-switch без миграций/правки схемы.
+- **NFR-6 (наблюдаемость)** — Вердикт (есть/нет mismatch, сколько файлов, какие корни) логируется
+  структурно; при проблеме — Telegram с кликабельным номером задачи (если применимо) + read-only
+  отражение в `GET /queue`.
+
+## 6. Допущения и ограничения
+
+- Целевой uid:gid рантайма = `1000:1000` (slin), подтверждён ORCH-040 (P-3); на хосте `/repos`,
+  `/app/data` штатно `1000:1000`.
+- Контейнер бежит под numeric uid 1000 без записи в `/etc/passwd` базового образа; в образе создан
+  реальный user `slin` (uid 1000) для `getpwuid()` (ORCH-058, Dockerfile). Под uid 1000 `chown`
+  чужих (root) файлов **невозможен** без CAP_CHOWN/root.
+- `git config --system --add safe.directory '*'` уже в образе — git доверяет bind-mount.
+- Корни проверки: `ORCH_REPOS_DIR` (`/repos`), включая `_wt`, `<repo>/.git/objects`,
+  `<repo>/.git/worktrees`, и `data/runs` (37 root-логов в инциденте).
+- `start_pipeline` (ORCH-088) отложил срез ветки на момент claim analyst-job → детект уместен
+  и на старте сервиса, и перед claim'ом (точку выбирает архитектор).
+
+## 7. Критерии успеха
+
+После миграции uid (или на чистой среде) первый же job проходит launch без ручного `chown`, либо —
+если права не нормализованы — конвейер выдаёт **понятную блокирующую диагностику** с командой
+исправления вместо сырого `git fatal`. INFRA.md/ADR содержат воспроизводимую процедуру.
+Для `enduro-trails` — нулевая регрессия. Детальные PASS/FAIL — в `03-acceptance-criteria.md`.
+
+## 8. Риски
+
+- Контейнер без root не может `chown` → авто-самолечение возможно только частично/при наличии прав;
+  основной гарант — детект+диагностика+процедура (детали — `10-tech-risks.md`, архитектор).
+- Рекурсивный обход больших `.git/objects` / `_wt` может быть дорог → нужен дешёвый/семплированный
+  детект и кэш (как preflight TTL).
+- Ложно-блокирующая ошибка может застопорить и enduro-trails (общий `/repos`) → строгий scope/fail-safe.
+- Правка `docker-compose.yml`/entrypoint (init-контейнер) = деплой self → групповой риск (NFR-1),
+  обязательная страховка staging.

docs/work-items/ORCH-057/02-trz.md

@@ -0,0 +1,117 @@
+---
+work_item: ORCH-057
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
+
+Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/выбор варианта one-time нормализации (init-контейнер vs blocking-entrypoint
+> vs ансибл) — задача архитектора (`06-adr/`). Здесь — требования, контракты и ограничения.
+
+## 1. Сводка изменения
+
+Закрыть недоделанный AC ORCH-040 по legacy-файлам. Три слоя:
+1. **Защита launcher** — `ensure_worktree` распознаёт `Permission denied`/git-fatal на создании
+   worktree и поднимает **внятную** ошибку с диагнозом «legacy root-файлы в `/repos/_wt` — нужна
+   нормализация прав» + лечащая команда (опц. авто-самолечение при наличии прав).
+2. **Ранний детект** — новый чистый леаф находит файлы с `uid != target_uid` в `ORCH_REPOS_DIR`
+   (`_wt`, `.git/objects`, `.git/worktrees`, `data/runs`); вызывается на старте сервиса и/или перед
+   claim'ом job; never-raise, config-gated, с наблюдаемостью.
+3. **Процедура** — `INFRA.md` + ADR ORCH-057: точные команды разовой нормализации как обязательный
+   шаг миграции uid. Опционально — one-time нормализация под root через init-механизм (решает архитектор).
+
+Инвариант: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД —
+**байт-в-байт прежние**. Изменение аддитивно и обратимо kill-switch'ем.
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `src/git_worktree.py` (`ensure_worktree`, `remove_worktree`) | изменить — классификация `Permission denied`/git-fatal на `git worktree add` / `os.makedirs` → внятный actionable `RuntimeError` (опц. self-heal при правах) |
+| `src/fs_normalize.py` | **создать** — чистый леаф (never-raise): `scan_ownership(roots, target_uid) -> результат`; опц. `normalize(...)` (chown только при наличии прав); хелпер `applies(repo)` + кэш (TTL, как preflight) |
+| `src/config.py` | изменить — добавить флаги (см. §7); без правки существующих значений |
+| `src/main.py` (`lifespan`) | изменить — добавить startup-вызов детекта (best-effort, never-fatal по образцу L-2/lease-reclaim), лог + Telegram при mismatch; read-only блок в `GET /queue` |
+| `src/preflight.py` **или** `src/queue_worker.py` | изменить (на выбор архитектора) — опц. гейт claim'а job при обнаруженном mismatch, чтобы падать внятно ДО launch (по образцу preflight-гейта) |
+| `docker-compose.yml` / `Dockerfile` / `scripts/*entrypoint*` | **кандидат** (решает архитектор) — one-time root-нормализация (init-контейнер/хук) ПЕРЕД стартом app; если выбрано — деплой self, обязательная staging-страховка |
+| `docs/operations/INFRA.md` | изменить — раздел «Миграция uid: обязательная нормализация legacy root-файлов» (команды + область) |
+| `docs/work-items/ORCH-057/06-adr/ADR-001-*.md` | создать (architect) — решение + процедура; опц. forward-breadcrumb из ADR-001 ORCH-040 (без переписывания истории) |
+| `CHANGELOG.md` | изменить — запись о ORCH-057 |
+| `tests/test_*` | создать — см. `04-test-plan.yaml` |
+
+## 3. Функциональные требования
+
+### FR-1 — Внятная ошибка `ensure_worktree` (BR-1, BR-5)
+При неуспехе `git worktree add` / `os.makedirs(os.path.dirname(wt))` по причине отказа доступа
+(`Permission denied`, `could not create leading directories`, `insufficient permission for adding an
+object`) `ensure_worktree` поднимает `RuntimeError` с сообщением, которое: (а) называет корневую
+причину (legacy root-owned файлы в `/repos/_wt` или `.git` после миграции uid ORCH-040); (б) указывает
+лечащую команду (`chown -R <uid>:<gid> …`) или ссылку на процедуру INFRA.md; (в) НЕ является сырым
+git stderr. Прочие (нет-прав-несвязанные) ошибки сохраняют текущий контракт (никакой подмены смысла).
+
+### FR-2 — Детект несоответствия владельца (BR-2, BR-4)
+Леаф `fs_normalize.scan_ownership` обходит корни (`/repos/_wt`, `<repo>/.git/objects`,
+`<repo>/.git/worktrees`, `data/runs`) и возвращает: есть ли файлы с `uid != target_uid`, их число
+(или флаг «≥1»), список затронутых корней. Обход дешёвый/ограниченный (ранний выход при первом
+mismatch для быстрого вердикта; полный подсчёт — опционально/семплировано). Результат кэшируется по
+TTL (по образцу `preflight._cache`). `target_uid` = `os.getuid()` или конфиг (дефолт 1000).
+
+### FR-3 — Реакция на детект (BR-1, BR-4)
+- **Startup (main.lifespan):** вызвать детект best-effort; при mismatch — структурный WARNING +
+  Telegram (если включён) с числом/корнями и лечащей командой. Никогда не падать на старте по
+  ошибке детекта (NFR-3).
+- **Опц. гейт claim'а:** при обнаруженном mismatch и `target_uid` без прав на chown — не претендовать
+  на job (или претендовать и сразу честно фейлить с FR-1-сообщением), чтобы исход был внятным до launch.
+  Конкретную точку (preflight vs queue_worker) выбирает архитектор; требование — «внятно и заранее».
+
+### FR-4 — Опциональная авто-нормализация (BR-1)
+`fs_normalize.normalize` выполняет `chown -R target_uid:target_gid` по корням **только если процесс
+имеет на это право** (CAP_CHOWN/root). Под uid 1000 без прав — no-op + честный лог «нужна операторская
+процедура» (НЕ ошибка). Включается отдельным флагом (`*_AUTO`), по умолчанию — выкл (детект-only).
+Если архитектор выбирает init-контейнер под root — это и есть носитель FR-4 на буте.
+
+### FR-5 — Документированная процедура (BR-3)
+`INFRA.md` получает раздел с точными командами разовой нормализации (`_wt`, оба `.git`, `data/runs`),
+помеченный как **обязательный** шаг миграции uid и часть чеклиста деплоя self. ADR ORCH-057 фиксирует
+решение и ссылается на процедуру; ADR-001 ORCH-040 опц. получает forward-ссылку.
+
+## 4. Изменения API
+
+Нет новых обязательных эндпоинтов. **Опционально** (наблюдаемость, решает архитектор):
+- расширить `GET /queue` read-only блоком `fs_ownership` (`{enabled, target_uid, mismatch, roots, checked_at}`);
+- ручной триггер `POST /fs-normalize/check` (форс-пересчёт детекта) — по образцу `POST /serial-gate/unfreeze`.
+
+## 5. Изменения схемы БД
+
+Нет. Состояние детекта — в памяти (TTL-кэш), как `preflight`. Таблицы/миграции/индексы не вводятся.
+
+## 6. Требования к новым/изменённым QG checks
+
+Нет. Это **не** stage-гейт и **не** под-гейт ребра. `QG_CHECKS` / `check_*` / `STAGE_TRANSITIONS` /
+machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+`coverage_status:`) — не трогаются. (В описании баг-репорта «deploy-гейт ORCH-040» — это деплой-хук/
+процедура, а не зарегистрированный QG.)
+
+## 7. Совместимость / регресс
+
+- **Kill-switch** `ORCH_FS_NORMALIZE_ENABLED` (дефолт по решению архитектора; `False` → весь код инертен,
+  поведение 1:1 как до ORCH-057).
+- **Scope** `ORCH_FS_NORMALIZE_REPOS` (CSV; пусто → **self-hosting only**, как `coverage_gate_repos` →
+  enduro-trails не затронут). Локальный `applies(repo)` проверяется ПЕРВЫМ (дешёвый обход только при applies).
+- **Флаги** (рабочие имена, финал — за архитектором): `ORCH_FS_TARGET_UID` (дефолт 1000),
+  `ORCH_FS_NORMALIZE_AUTO` (дефолт `False` — детект-only; `True` → попытка chown при наличии прав),
+  `ORCH_FS_SCAN_ROOTS` (CSV переопределения корней), `ORCH_FS_SCAN_CACHE_TTL_S`.
+- **Never-raise / fail-safe** — ошибка детекта/нормализации деградирует в WARNING, не блокирует старт
+  сервиса по своей вине; FR-1 меняет лишь **формулировку** ошибки worktree, не её факт.
+- **Self-hosting** (NFR-1) — код только читает/детектит/диагностирует (и chown ТОЛЬКО при наличии прав);
+  не деплоит/не рестартит прод/не трогает `main`. Любое касание `docker-compose.yml`/entrypoint требует
+  staging-прогона (8501) перед прод-рестартом в окно тишины.
+- **Обратимость** — выкл kill-switch → прежнее поведение; миграций/правки схемы нет.
+- **Пайплайн-артефакты:** обновляются `01..04` (analysis), `06-adr/`+`07-infra-requirements.md`+`10-tech-risks.md`
+  (architecture), `12/13/15/14` (review/testing/staging/deploy), `INFRA.md`, `CHANGELOG.md`.

docs/work-items/ORCH-057/03-acceptance-criteria.md

@@ -0,0 +1,99 @@
+---
+work_item: ORCH-057
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-057 — нормализация legacy root-owned файлов
+
+Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория.
+
+---
+
+## AC-1 — Конвейер стартует без ручного chown (или внятная блокирующая ошибка)
+
+**Условие:** после миграции контейнера на новый uid первый job не падает сырым git-фаталом на launch.
+- **PASS:** при нормализованных правах worktree создаётся и агент стартует; при НЕнормализованных
+  правах конвейер выдаёт понятную блокирующую ошибку с диагнозом и лечащей командой (НЕ сырой
+  `fatal: could not create leading directories … Permission denied`).
+- **FAIL:** на launch всплывает сырой git-fatal/Permission denied без диагноза причины и инструкции.
+
+---
+
+## AC-2 — `ensure_worktree` даёт actionable-ошибку при отказе доступа
+
+**Условие:** `src/git_worktree.py::ensure_worktree` классифицирует ошибки прав.
+- **PASS:** при `Permission denied`/`could not create leading directories`/`insufficient permission`
+  поднимается `RuntimeError`, текст которого называет причину (legacy root-файлы в `/repos/_wt`/`.git`
+  после миграции uid) и указывает команду/ссылку на процедуру; ошибки, не связанные с правами,
+  сохраняют прежний контракт.
+- **FAIL:** сырой git stderr пробрасывается без диагноза; либо подменяется смысл не-прав-ошибок;
+  либо `ensure_worktree` падает необработанно.
+
+---
+
+## AC-3 — Детект несоответствия владельца
+
+**Условие:** новый леаф `src/fs_normalize.py` обнаруживает файлы с `uid != target_uid` в корнях
+(`/repos/_wt`, `<repo>/.git/objects`, `<repo>/.git/worktrees`, `data/runs`).
+- **PASS:** на среде с root-файлами `scan_ownership` возвращает mismatch=True + затронутые корни;
+  на чистой (`1000:1000`) среде — mismatch=False (no-op, идемпотентно); леаф never-raise.
+- **FAIL:** mismatch не обнаружен на грязной среде / ложный mismatch на чистой / леаф бросает наружу.
+
+---
+
+## AC-4 — Наблюдаемость детекта
+
+**Условие:** результат детекта виден оператору без падения задачи.
+- **PASS:** при mismatch — структурный лог-WARNING (число/корни/лечащая команда) и Telegram (если
+  включён); опц. read-only отражение в `GET /queue`.
+- **FAIL:** mismatch обнаружен, но никак не сообщён; оператор узнаёт о проблеме только по упавшей задаче.
+
+---
+
+## AC-5 — Self-hosting безопасность и нулевая регрессия enduro-trails
+
+**Условие:** изменение безопасно для общего инстанса.
+- **PASS:** код не рестартит/не роняет прод, не трогает `main`/force-push/прод-образ; chown — только
+  при наличии прав; при выключенном kill-switch поведение 1:1 как до ORCH-057; при пустом scope-CSV
+  feature активен только для self-hosting (enduro-trails не затронут); регресс `pytest tests/ -q` зелёный.
+- **FAIL:** любой рестарт/деградация прода из кода задачи; ненулевая регрессия enduro-trails;
+  поведение меняется при выключенном флаге; падение всего регресса.
+
+---
+
+## AC-6 — Инварианты конвейера сохранены
+
+**Условие:** изменение аддитивно.
+- **PASS:** `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict-ключи и схема БД —
+  байт-в-байт прежние; новые флаги аддитивны и обратимы.
+- **FAIL:** затронут любой exit/под-гейт, изменён machine-key, добавлена миграция схемы.
+
+---
+
+## AC-7 — Документированная процедура нормализации
+
+**Условие:** процедура воспроизводима.
+- **PASS:** `INFRA.md` содержит раздел «Миграция uid: обязательная нормализация legacy root-файлов»
+  с точными командами (`_wt`, оба `.git`, `data/runs`) как обязательный шаг миграции; ADR ORCH-057
+  фиксирует решение и ссылается на процедуру.
+- **FAIL:** процедура отсутствует/абстрактна (как было в ORCH-040) либо не покрывает все корни.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1, FR-3 |
+| AC-2 | BR-1, BR-5 / FR-1 |
+| AC-3 | BR-2 / FR-2 |
+| AC-4 | BR-4 / FR-3 |
+| AC-5 | NFR-1, NFR-2, NFR-5 / FR-4 |
+| AC-6 | NFR-5 (инварианты) |
+| AC-7 | BR-3 / FR-5 |

docs/work-items/ORCH-057/04-test-plan.yaml

@@ -0,0 +1,92 @@
+work_item: ORCH-057
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "Нормализация legacy root-owned файлов при миграции на uid 1000 (детект + защита worktree)"
+framework: pytest
+scope: >
+  Покрывается: классификация ошибки прав в ensure_worktree (внятная actionable-ошибка),
+  детект несоответствия владельца (fs_normalize.scan_ownership), идемпотентность на чистой среде,
+  fail-safe/never-raise, scope/kill-switch (self-hosting only при пустом CSV), опц. self-heal-noop
+  без прав. ВНЕ покрытия: реальный chown под root (требует привилегий — проверяется на staging
+  вручную), правка docker-compose/entrypoint (инфра, ручная проверка на 8501).
+notes: >
+  Все FS-зависимые тесты используют tmp_path и monkeypatch os.getuid/os.stat — без реального chown
+  и без записи в /repos. Telegram/Plane мокаются. Полный регресс tests/ должен оставаться зелёным;
+  STAGE_TRANSITIONS/QG_CHECKS/схема БД не затрагиваются — отдельные guard-тесты не требуются, но
+  существующие тесты на инварианты должны пройти без изменений.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "ensure_worktree при git-fatal 'could not create leading directories / Permission denied' поднимает RuntimeError с диагнозом legacy-root + лечащей командой, а не сырой git stderr"
+    module: tests/test_git_worktree_perm.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "ensure_worktree при ошибке, НЕ связанной с правами (например branch conflict), сохраняет прежний контракт сообщения (не подменяет смысл)"
+    module: tests/test_git_worktree_perm.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "scan_ownership на дереве с файлом uid != target_uid возвращает mismatch=True и список затронутых корней"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "scan_ownership на чистом дереве (все файлы target_uid) возвращает mismatch=False (идемпотентный no-op)"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "scan_ownership never-raise: при недоступном/несуществующем корне деградирует в WARNING и не бросает наружу"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "applies(repo): пустой ORCH_FS_NORMALIZE_REPOS → True только для self-hosting репо (orchestrator), False для enduro-trails; непустой CSV — по списку"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "kill-switch ORCH_FS_NORMALIZE_ENABLED=False → scan/normalize инертны (no-op), поведение 1:1 как до ORCH-057"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "normalize без прав (uid 1000, чужие root-файлы, ORCH_FS_NORMALIZE_AUTO=True) → no-op + честный лог 'нужна операторская процедура', НЕ исключение"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "TTL-кэш детекта: повторный вызов в окне TTL не пере-сканирует дерево (по образцу preflight._cache); force/reset инвалидирует"
+    module: tests/test_fs_normalize.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "startup-хук lifespan при mismatch вызывает send_telegram (мок) и логирует WARNING; при ошибке детекта старт сервиса не падает (never-fatal)"
+    module: tests/test_fs_normalize_startup.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "опц. гейт claim'а: при обнаруженном mismatch без прав исход job внятный (FR-1-сообщение / не-claim) ДО launch, а не сырой git-fatal"
+    module: tests/test_fs_normalize_startup.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: "GET /queue (если реализован read-only блок fs_ownership) отдаёт {enabled,target_uid,mismatch,roots,checked_at} и не 5xx-ит при выключенном флаге"
+    module: tests/test_api_queue.py
+    expected: PASS

docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md

@@ -0,0 +1,210 @@
+---
+work_item: ORCH-057
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Нормализация legacy root-owned файлов при миграции на uid 1000 — детект + actionable-ошибка + процедура
+
+Work Item: **ORCH-057** — follow-up ORCH-040 (legacy `root:root` файлы в `/repos` ломают создание worktree под uid 1000)
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`** (новый
+leaf-компонент + startup-поведение, затрагивает весь инстанс → кросс-каттинг).
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-040 перевёл оба контейнера на `user: "1000:1000"`, изменив **только** `docker-compose.yml`.
+Смена `user:` не меняет владельца уже существующих файлов, созданных прежним root-контейнером.
+Bind-mount `/home/slin/repos → /repos` содержал `root:root` каталоги (`_wt/`, старые worktree,
+`.git/objects`, `data/runs` — 37 root-логов).
+
+**Сверено по коду:**
+- `src/git_worktree.py::ensure_worktree` (стр. 78 `os.makedirs(os.path.dirname(wt))`, стр. 81/85
+  `git worktree add`) — точка реального падения. При `root:root` владельце `/repos/_wt/` uid 1000
+  не может создать рядом новый каталог worktree → `fatal: could not create leading directories …
+  Permission denied`. Сейчас этот stderr пробрасывается «сырым» в `RuntimeError` (стр. 90–93) без
+  диагноза причины.
+- Конвейер приходит сюда из `src/agents/launcher.py::_spawn` и `_materialize_deferred_branch`
+  (ORCH-088, отложенный срез ветки на момент claim analyst-job). **Агент не стартует** — падает
+  создание worktree (НЕ код задачи), т.е. это launch-time инфраструктурный сбой.
+- Контейнер бежит под numeric uid 1000 **без root** (ORCH-040 P-3, ORCH-058 реальный user `slin`
+  в образе). Под uid 1000 `chown` чужих (root) файлов **невозможен** без `CAP_CHOWN`. Значит код
+  физически не может «починить» права сам — ему доступны только **детект + диагностика**, а
+  фактический `chown` — операторская процедура.
+- ADR-001 ORCH-040 упоминал «массовый chown старых root-файлов» лишь абстрактно («вне объёма кода»,
+  «разовая операция Owner») и не дал конкретной процедуры → deployer её не выполнил → баг проявился
+  в проде 06.06 на первом запуске ORCH-043. Прод сейчас рабочий (ручной workaround Стрима наложен),
+  но проблема **воспроизводится** на чистой среде / новом репо / после любого исторического запуска
+  под root.
+
+Это **закрытие недоделанного AC ORCH-040**, а не новая фича. Существующие гейты/паттерны для опоры:
+условный leaf-гейт `coverage_gate`/`serial_gate` (kill-switch + scope + `is_self_hosting_repo`),
+best-effort startup-хуки в `main.lifespan` (lease-reclaim, log-rotation — never-fatal),
+read-only снимки `GET /queue` (`serial_gate.snapshot()`), TTL-кэш `preflight._cache`.
+
+## Решение
+
+### Сводка
+Три аддитивных, обратимых kill-switch'ем слоя, **без** изменения `STAGE_TRANSITIONS` / `QG_CHECKS` /
+`check_*` / machine-verdict-ключей / схемы БД:
+
+1. **Actionable-ошибка** в `ensure_worktree` — класс «нет прав на создание worktree» распознаётся и
+   превращается в диагностируемый `RuntimeError` с причиной + лечащей командой (FR-1).
+2. **Детект-леаф** `src/fs_normalize.py` — чистый, never-raise, TTL-кэшируемый обход корней, ищет
+   файлы с `uid != target_uid` (FR-2); вызывается best-effort на старте сервиса с наблюдаемостью
+   (FR-3).
+3. **Операторская процедура** в `INFRA.md` + forward-breadcrumb из ADR-040 — точные команды разовой
+   нормализации как обязательный шаг миграции uid (FR-5).
+
+Фактический `chown` остаётся **операторской процедурой** (NFR-1: код под uid 1000 без root его делать
+не может и не должен).
+
+### D1 — `ensure_worktree`: классификация отказа доступа (FR-1, AC-1, AC-2)
+Оборачиваем **обе** точки сбоя по правам — `os.makedirs(os.path.dirname(wt))` (стр. 78) и оба
+`git worktree add` (стр. 81/85). Класс «нет прав» детектируется по маркерам в `stderr`/исключении:
+`Permission denied`, `could not create leading directories`, `insufficient permission for adding an
+object`, `PermissionError` (errno `EACCES`/`EPERM`). При совпадении — `RuntimeError`, текст которого:
+(а) называет корневую причину («legacy root-owned файлы в `/repos/_wt` или `.git` после миграции uid
+ORCH-040»); (б) указывает лечащую команду (`chown -R <target_uid>:<gid> /repos/_wt …`) и ссылку на
+раздел INFRA.md; (в) **не** является сырым git stderr.
+
+**Инвариант контракта (AC-2 FAIL-условие):** ошибки, **не** связанные с правами (реальный git-конфликт,
+отсутствие `origin/main`, таймаут), сохраняют **прежний** текст/смысл — никакой подмены. Классификатор —
+чистая функция `classify_worktree_error(stderr_or_exc) -> bool` (или хелпер в `fs_normalize`),
+покрытая юнит-тестами на обе ветки. Помощь-сообщение строится только при `True`. Это **меняет лишь
+формулировку** ошибки, не её факт (NFR-3): worktree как падал, так и падает — но теперь внятно.
+
+### D2 — Детект-леаф `src/fs_normalize.py` (FR-2, AC-3)
+Новый чистый модуль по образцу `serial_gate`/`post_deploy` (импортирует только `config`/`logging`/
+`os`/`pwd`; не тянет `stage_engine`/`launcher`). API:
+
+- `scan_ownership(roots: list[str] | None = None, target_uid: int | None = None) -> OwnershipScan` —
+  обходит корни, возвращает `{mismatch: bool, target_uid: int, roots_checked: list, roots_mismatch:
+  list, sample_path: str | None, count: int | None, checked_at: float}`.
+- **`target_uid`** по умолчанию = `os.getuid()` (uid, под которым реально бежит процесс — ровно тот
+  субъект, что «не может создать файл»); переопределяется `fs_target_uid` (дефолт 1000) для тестов/
+  нестандартного рантайма.
+- **Корни** по умолчанию: `/repos/_wt`, `<repo>/.git/objects`, `<repo>/.git/worktrees` (для репо из
+  скоупа), `data/runs` (`os.path.dirname(settings.db_path)/runs`). Переопределяемы `fs_scan_roots`
+  (CSV).
+- **Дешевизна (риск стоимости обхода):** **ранний выход при первом mismatch** (для быстрого булева
+  вердикта `os.lstat(...).st_uid != target_uid`). Полный `count` — опционален/семплирован (отдельный
+  дешёвый режим, по умолчанию выключен), чтобы не обходить целиком большие `.git/objects`. Результат
+  **кэшируется по TTL** `fs_scan_cache_ttl_s` (паттерн `preflight._cache`, `force=` обходит кэш).
+- **never-raise (NFR-3):** любая ошибка обхода (исчезнувший путь, отказ stat) → деградирует в WARNING
+  и консервативный вердикт `mismatch=False` (не блокирует и не паникует); идемпотентно (AC-3:
+  повторный скан на чистой среде — `mismatch=False`, no-op).
+- **`applies(repo: str) -> bool`** — `fs_normalize_enabled` (kill-switch) И scope (`fs_normalize_repos`
+  CSV; пусто → `is_self_hosting_repo(repo)`, как `coverage_gate`); проверяется **ПЕРВЫМ**, дорогой
+  обход — только при `applies==True` (NFR-2: enduro-trails не сканируется при пустом CSV).
+- **`snapshot() -> dict`** — read-only для `GET /queue`.
+
+### D3 — Точка интеграции: startup-наблюдаемость, БЕЗ блокировки claim (FR-3 — разрешение открытого выбора TRZ)
+TRZ §2 оставил архитектору выбор «preflight vs queue_worker» для опц. гейта claim'а. **Решение:
+claim НЕ блокируем.**
+
+- **Startup (`main.lifespan`):** best-effort вызов `scan_ownership()` рядом с lease-reclaim/log-rotation
+  (стр. 63–90), обёрнут `try/except` (never-fatal). При `mismatch` — структурный WARNING (число/корни/
+  лечащая команда) + Telegram (если включён). Это даёт оператору **проактивный сигнал заранее**
+  (AC-4), не дожидаясь падения задачи.
+- **«Внятно и заранее» обеспечивает D1, а не claim-гейт.** `ensure_worktree` знает `repo` и падает
+  до того, как агент потратит хоть один токен (агент не стартует). Это и есть требуемый ранний внятный
+  исход.
+
+**Почему НЕ блокирующий claim-гейт (отвергнуто):**
+- `preflight.check()` **не знает repo** и гейтит claim **всех** репо → при mismatch в общем `/repos/_wt`
+  заблокировал бы и enduro-trails (нарушение NFR-2 при включённом флаге). Сделать его scope-aware
+  внутри preflight нельзя без знания репо в точке вызова.
+- Гейт в `queue_worker`/`db.claim_next_job` (как `serial_gate`) технически scope-aware, но: (1)
+  оставил бы задачу «молча висеть» в очереди вместо явного диагноза; (2) добавил бы дорогой FS-обход
+  в offline hot-path claim'а; (3) дублировал бы исход, который D1 уже даёт внятно. Лишняя поверхность
+  без выигрыша.
+
+Итог: **детект = наблюдаемость (startup + опц. ручной POST), а внятный отказ = D1 в точке launch.**
+
+### D4 — Опциональная авто-нормализация `normalize()` (FR-4) — не init-контейнер
+`fs_normalize.normalize(roots, target_uid)` выполняет `os.chown`/`chown -R` по корням **только если
+процесс имеет `CAP_CHOWN`/root**. Под uid 1000 без прав — **no-op + честный лог** «нужна операторская
+процедура» (НЕ ошибка). Включается отдельным флагом `fs_normalize_auto` (дефолт `False` — детект-only).
+
+**Init-контейнер/root-entrypoint отвергнут (см. Альтернативы):** он (а) реинтродуцирует root-контекст,
+ровно который ORCH-040 убрал ради безопасности; (б) требует правки `docker-compose.yml`/entrypoint →
+**self-deploy** с групповым риском (NFR-1) и обязательной staging-страховкой ради разовой задачи;
+(в) discretionary по BRD §2 «Опционально». Носитель реальной нормализации — **документированная
+операторская процедура** (D5), запускаемая под root **на хосте** один раз при миграции uid.
+
+### D5 — Процедура в INFRA.md + forward-breadcrumb (FR-5, AC-7)
+В `docs/operations/INFRA.md` (раздел «Рантайм-uid (ORCH-040)») добавляется подраздел **«Миграция uid:
+обязательная нормализация legacy root-файлов»** с точными командами, покрывающими **все** корни
+(`_wt`, оба `.git`, `data/runs`), помеченный как **обязательный** шаг миграции uid и пункт чеклиста
+деплоя self. Существующий абстрактный буллет (стр. 50–51) заменяется ссылкой на новый подраздел.
+В ADR-040 — необязательный forward-breadcrumb на ORCH-057 (история ORCH-040 не переписывается, §2 BRD).
+
+### D6 — Конфиг-флаги (TRZ §7) и наблюдаемость
+Аддитивно в `src/config.py` (существующие значения не трогаются):
+
+| Флаг (env) | Дефолт | Смысл |
+|------------|--------|-------|
+| `fs_normalize_enabled` (`ORCH_FS_NORMALIZE_ENABLED`) | `True` | kill-switch; `False` → весь код инертен, поведение 1:1 как до ORCH-057 (D1 тоже гардится — при выкл. контракт ошибки прежний) |
+| `fs_normalize_repos` (`ORCH_FS_NORMALIZE_REPOS`) | `""` | scope CSV; пусто → self-hosting only (`is_self_hosting_repo`) |
+| `fs_target_uid` (`ORCH_FS_TARGET_UID`) | `1000` | целевой uid (фолбэк, если `os.getuid()` неприменим) |
+| `fs_normalize_auto` (`ORCH_FS_NORMALIZE_AUTO`) | `False` | детект-only; `True` → попытка chown при наличии прав (D4) |
+| `fs_scan_roots` (`ORCH_FS_SCAN_ROOTS`) | `""` | CSV-переопределение корней |
+| `fs_scan_cache_ttl_s` (`ORCH_FS_SCAN_CACHE_TTL_S`) | `300` | TTL детект-кэша |
+
+Наблюдаемость (AC-4): read-only блок `fs_ownership` в `GET /queue` (`snapshot()`:
+`{enabled, target_uid, mismatch, roots_checked, roots_mismatch, checked_at}`); опц. ручной триггер
+`POST /fs-normalize/check` (форс-пересчёт, по образцу `POST /serial-gate/unfreeze`). Telegram при
+mismatch — с кликабельным номером задачи (если в контексте есть `work_item_id`), числом/корнями,
+лечащей командой.
+
+## Альтернативы
+- **Init-контейнер / root-entrypoint, выполняющий `chown` на буте** — отвергнуто: реинтродуцирует
+  root-контекст (анти-цель ORCH-040), требует правки `docker-compose.yml`/entrypoint = self-deploy +
+  групповой риск + обязательная staging-страховка ради одноразовой операции; BRD помечает его
+  «Опционально». Реальную нормализацию несёт документированная разовая операторская процедура.
+- **Блокирующий claim-гейт в `preflight`** — отвергнуто: preflight не знает repo → блокирует claim
+  ВСЕХ репо, регресс enduro-trails на общем `/repos` (нарушение NFR-2).
+- **Блокирующий claim-гейт в `queue_worker`/`claim_next_job`** — отвергнуто: дорогой FS-обход в
+  offline hot-path, «молчаливое зависание» вместо внятного диагноза, дублирует исход D1.
+- **Авто-`chown` из app-кода по умолчанию** — отвергнуто: под uid 1000 невозможен; включение по
+  умолчанию создавало бы ложное ожидание самолечения. Оставлен как opt-in `fs_normalize_auto` для
+  сред, где процесс имеет CAP_CHOWN.
+- **Жёсткий fail на старте при mismatch** — отвергнуто: нарушает never-raise (NFR-3) и мог бы
+  застопорить старт сервиса всех проектов из-за грязного `/repos`. Детект — only WARNING/Telegram.
+
+## Последствия
+- **+** Класс «сырой git-fatal на launch после миграции uid» закрыт: оператор получает внятный
+  диагноз + лечащую команду в точке падения (D1) и проактивный сигнал на старте (D3).
+- **+** Воспроизводимая процедура в INFRA.md закрывает пробел ADR-040 (AC-7).
+- **+** Нулевая регрессия enduro-trails (scope `applies()` first, пустой CSV → self-hosting only);
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт прежние (AC-6).
+- **+** Никакого root-контекста, рестарта прода, касания `main`/force-push/прод-образа (NFR-1, AC-5).
+- **−** Фактический `chown` остаётся **ручным** операторским шагом — на средах, где его забыли, баг
+  всё ещё проявится, но теперь **внятно** (с инструкцией), а не сырым git-fatal. Митигейшн:
+  startup-WARNING+Telegram + обязательный пункт чеклиста миграции в INFRA.md.
+- **−** Ещё один best-effort startup-хук + leaf-модуль (рост поверхности). Митигейшн: чистый
+  never-raise leaf, TTL-кэш, ранний выход обхода, kill-switch.
+- **−** `fs_normalize_auto=True` под root реинтродуцирует chown-контекст — поэтому дефолт `False` и
+  он не для прод-self (прод бежит под uid 1000).
+- **Откат:** `fs_normalize_enabled=False` → весь код инертен (D1 контракт ошибки прежний, детект не
+  запускается); миграций/правки схемы нет → мгновенный обратимый kill-switch.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-057/01-brd.md`
+- TRZ: `docs/work-items/ORCH-057/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-057/03-acceptance-criteria.md`
+- Инфра: `docs/work-items/ORCH-057/07-infra-requirements.md`
+- Риски: `docs/work-items/ORCH-057/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`
+- Сверено по коду: `src/git_worktree.py` (`ensure_worktree` стр. 78/81/85/90), `src/preflight.py`
+  (TTL-кэш), `src/main.py` (`lifespan` стр. 63–114), `src/serial_gate.py` / `src/coverage_gate.py`
+  (паттерн условного leaf `applies`/scope/`is_self_hosting_repo`).
+- Предшественник: `docs/work-items/ORCH-040/06-adr/ADR-001-run-agents-as-host-uid.md`,
+  `docs/architecture/adr/adr-0005-container-runs-as-host-uid.md`.

docs/work-items/ORCH-057/07-infra-requirements.md

@@ -0,0 +1,63 @@
+---
+work_item: ORCH-057
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
+
+Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Топология контейнеров **не меняется** (init-контейнер/правка `docker-compose.yml`
+> отвергнуты — ADR-001 D4). Файл фиксирует новые env-флаги и **обязательную операторскую процедуру**
+> нормализации legacy root-файлов как шаг миграции uid.
+
+## I-1. Топология / окружения
+**Без изменений.** Контейнеры `orchestrator` (8500) / `orchestrator-staging` (8501), `user:
+"1000:1000"`, bind-mount `/home/slin/repos → /repos`, `network_mode: host` — как есть. Init-контейнер
+/ root-entrypoint **сознательно НЕ вводятся** (реинтродуцировали бы root-контекст, убранный ORCH-040,
+и потребовали бы self-deploy compose с групповым риском — ADR-001 D4, Альтернативы).
+
+## I-2. Переменные окружения / секреты
+Новые env-флаги (аддитивно в `src/config.py`, дефолты сохраняют поведение до ORCH-057). Добавить в
+`.env.example` (секретов нет):
+
+| Env | Дефолт | Назначение |
+|-----|--------|------------|
+| `ORCH_FS_NORMALIZE_ENABLED` | `true` | kill-switch всего слоя ORCH-057 |
+| `ORCH_FS_NORMALIZE_REPOS` | `` (пусто) | scope CSV; пусто → self-hosting only (enduro не затронут) |
+| `ORCH_FS_TARGET_UID` | `1000` | целевой uid (фолбэк к `os.getuid()`) |
+| `ORCH_FS_NORMALIZE_AUTO` | `false` | детект-only; `true` → попытка chown при наличии CAP_CHOWN |
+| `ORCH_FS_SCAN_ROOTS` | `` (пусто) | CSV-переопределение корней обхода |
+| `ORCH_FS_SCAN_CACHE_TTL_S` | `300` | TTL детект-кэша |
+
+Секреты не вводятся.
+
+## I-3. Деплой / рестарт
+- **Self-hosting инвариант (NFR-1):** код задачи **не** рестартит/не роняет прод-контейнер
+  `orchestrator`, не трогает `main`/force-push/прод-образ. `chown` из кода возможен лишь при наличии
+  прав (под uid 1000 — no-op).
+- Изменение **только** `src/**` + docs → штатный деплой self **через staging-гейт (8501)**, затем
+  прод-рестарт **в окно тишины** (`GET /status` без активных задач). Правки `docker-compose.yml`/
+  entrypoint в задаче **нет** → нет дополнительного инфра-риска сверх обычного self-деплоя.
+- **Обязательная операторская процедура нормализации (host-prerequisite миграции uid)** — выполняется
+  **под root на хосте mva154 один раз** при миграции uid / на новой среде, ПЕРЕД стартом app.
+  Каноничный текст — в `docs/operations/INFRA.md` (раздел «Миграция uid: обязательная нормализация
+  legacy root-файлов»). Команды покрывают все корни:
+  ```
+  sudo chown -R 1000:1000 /home/slin/repos/_wt
+  sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git \
+                          /home/slin/repos/enduro-trails/.git
+  sudo chown -R 1000:1000 /home/slin/repos/orchestrator        # incl. data/runs/*.log
+  # Проверка: find /home/slin/repos/_wt ! -uid 1000 -print -quit   (пусто = ок)
+  ```
+  Идемпотентна (повтор на корректной среде — no-op). Помечена обязательным пунктом чеклиста
+  деплоя/миграции self.
+
+## I-4. CI/CD
+Без изменений в `.gitea/workflows/`. Новые юнит-тесты (`tests/test_fs_normalize.py`,
+`tests/test_git_worktree_perm_error.py` — см. `04-test-plan.yaml`) гоняются существующим
+`pytest tests/ -q`. Новых системных зависимостей образа нет.

docs/work-items/ORCH-057/10-tech-risks.md

@@ -0,0 +1,37 @@
+---
+work_item: ORCH-057
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
+
+Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Ложная классификация ошибки worktree** (D1): не-прав-ошибка распознана как «нет прав» → подмена смысла (FAIL AC-2). | Низ. | Сред. | Узкий набор маркеров (`Permission denied`/`could not create leading directories`/`insufficient permission`/`EACCES`/`EPERM`); классификатор — чистая функция с юнит-тестами на обе ветки; не-совпадение → прежний сырой текст без изменений. |
+| TR-2 | **Дорогой рекурсивный обход** больших `.git/objects` / `_wt` тормозит старт сервиса. | Сред. | Сред. | Ранний выход при первом mismatch (булев вердикт); полный `count` опционален/семплирован; TTL-кэш (`fs_scan_cache_ttl_s`); вызов best-effort на старте, не в hot-path claim'а; `applies()` first → обход только при applies. |
+| TR-3 | **Ложно-блокирующий эффект на enduro-trails** через общий `/repos`. | Низ. | Выс. | Claim НЕ блокируется (D3 — только наблюдаемость); scope `applies()` first, пустой CSV → self-hosting only → enduro не сканируется; детект never-raise. |
+| TR-4 | **Забытый ручной `chown`**: на среде без выполненной процедуры баг всё ещё проявится. | Сред. | Сред. | Теперь проявляется **внятно** (D1 actionable-ошибка + startup WARNING/Telegram, не сырой git-fatal); процедура — обязательный пункт чеклиста миграции в INFRA.md; идемпотентна. Остаточный риск принят (код под uid 1000 не может chown). |
+| TR-5 | **`fs_normalize_auto=True` под root** реинтродуцирует chown-контекст / неожиданный массовый chown. | Низ. | Сред. | Дефолт `False`; прод-self бежит под uid 1000 (chown = no-op); auto-режим — opt-in для сред с CAP_CHOWN; init-контейнер отвергнут (ADR-001 D4). |
+| TR-6 | **never-raise дыра**: необработанное исключение детекта роняет старт сервиса всех проектов. | Низ. | Выс. | Леаф never-raise (паттерн `serial_gate`/`post_deploy`); startup-вызов в `try/except` (как lease-reclaim/log-rotation); ошибка → WARNING + консервативный `mismatch=False`. |
+| TR-7 | **`os.getuid()` неприменим** в нестандартном рантайме → неверный target_uid → ложный mismatch. | Низ. | Низ. | Фолбэк `fs_target_uid` (дефолт 1000); идемпотентность скана; вердикт only-наблюдательный (не блокирует). |
+| TR-8 | **Кэш устарел** после выполнения нормализации → stale `mismatch=True` в `GET /queue`. | Низ. | Низ. | TTL-инвалидизация; ручной `POST /fs-normalize/check` (`force=True`) для немедленного пересчёта. |
+
+## Сводный вывод
+Доминирующий класс — **операционные риски разовой нормализации**, а не алгоритмические: код только
+читает/детектит/диагностирует (chown — операторская процедура под root на хосте). Самостоятельный
+техдолг (TR-4) — остаточный и **принят**: контейнер без root физически не может починить права сам;
+решение гарантирует **внятность** отказа, а не его отсутствие. Self-hosting-безопасность соблюдена
+(никакого рестарта прода / касания `main` / root-контекста в коде). Изменение аддитивно и обратимо
+kill-switch'ем → **эскалация `arch:major-change` НЕ требуется** (нет новой стадии/QG/таблицы/смены
+топологии). Возврат в анализ не нужен — ТЗ удовлетворяется без нарушения принципов архитектуры.
+Остаточный риск для прод-конвейера — **низкий**.

docs/work-items/ORCH-057/12-review.md

@@ -0,0 +1,105 @@
+---
+verdict: APPROVED
+work_item: ORCH-057
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-057
+version: 1
+---
+
+# Review ORCH-057
+
+## Summary
+
+Follow-up ORCH-040: закрыт недоделанный AC по legacy `root:root` файлам, ломавшим создание
+worktree под uid 1000. Реализованы три аддитивных, обратимых kill-switch'ем слоя ровно по ADR-001:
+**D1** actionable-ошибка в `ensure_worktree`, **D2** детект-леаф `src/fs_normalize.py`
+(never-raise, TTL-кэш, scope-aware), **D3** best-effort startup-наблюдаемость в `main.lifespan`
+(WARNING + Telegram, claim не блокируется), плюс `GET /queue` блок `fs_ownership` и
+`POST /fs-normalize/check`. Документация (INFRA.md процедура, architecture/README.md, сквозной
+adr-0031, CHANGELOG, .env.example) обновлена в том же PR.
+
+Проверено по 4 осям; все 7 AC выполнены, P0/P1 findings нет. Регресс `pytest tests/ -q` —
+**1507 passed**; целевые модули (`test_fs_normalize`, `test_fs_normalize_startup`,
+`test_git_worktree_perm`, `test_api_queue`) — **25 passed**, покрывают TC-01…TC-12.
+
+## Соответствие ТЗ (02-trz) и AC (03-acceptance-criteria)
+
+- **FR-1 / AC-1, AC-2** ✓ — `git_worktree._raise_if_permission` + `fs_normalize.is_permission_failure`/
+  `build_worktree_help`: класс «нет прав» (`Permission denied`/`could not create leading directories`/
+  `insufficient permission`/`PermissionError`/`EACCES`/`EPERM`) → actionable `RuntimeError` с причиной,
+  `chown`-командой и ссылкой на INFRA.md. Обе точки сбоя обёрнуты (`os.makedirs` + оба `worktree add`).
+  Не-прав-ошибки сохраняют прежний raw-контракт (TC-02 PASS). Под kill-switch — no-op, контракт 1:1.
+- **FR-2 / AC-3** ✓ — `scan_ownership` обходит `/repos/_wt`, `<repo>/.git/{objects,worktrees}`,
+  `data/runs`; ранний выход на первом `lstat.st_uid != target_uid`; чистая среда → `mismatch=False`
+  идемпотентно; never-raise → консервативный `mismatch=False` (TC-03/04/05).
+- **FR-3 / AC-4** ✓ — startup-хук never-fatal: WARNING + Telegram при mismatch; claim не блокируется
+  (D3, преднамеренно — внятный ранний отказ даёт D1, знающий repo). Read-only блок `fs_ownership` в
+  `GET /queue` (TC-10/TC-12).
+- **FR-4** ✓ — `normalize()` chown только при `_is_privileged()` (geteuid==0); под uid 1000 — no-op +
+  честный лог, НЕ ошибка; gated `fs_normalize_auto` (дефолт False) (TC-08).
+- **FR-5 / AC-7** ✓ — INFRA.md: блокер P-5 + подраздел «Миграция uid: обязательная нормализация»
+  со всеми корнями; work-item ADR + сквозной adr-0031.
+- **§7 совместимость / AC-5** ✓ — `applies(repo)` first (kill-switch + scope; пустой CSV →
+  self-hosting only через `is_self_hosting_repo`); enduro-trails не сканируется при дефолте.
+  TTL-кэш (`fs_scan_cache_ttl_s`). Регресс зелёный (1507 passed).
+
+## Соответствие ADR
+
+- Реализация совпадает с ADR-001 D1–D6 (включая сознательный отказ от блокирующего claim-гейта и
+  init-контейнера — обоснование в «Альтернативах»). Сквозная регистрация adr-0031 присутствует и
+  отражена в architecture/README.md.
+- **Трассировка (AC-6 / TRACEABILITY):** инварианты конвейера не тронуты — commit `9852871` НЕ
+  затрагивает `src/stages.py`, `src/qg/checks.py`, `src/db.py`, `src/stage_engine.py`. Маркеры
+  ORCH-040/088 в `git_worktree`/`main` читаются, зафиксированные инварианты (never-fatal startup,
+  отложенный срез ветки) не сломаны. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема
+  БД — байт-в-байт прежние.
+
+## Качество кода
+
+- `src/fs_normalize.py` — чистый leaf (импортирует только `config`/`logging`/`os`/`time`,
+  лениво `qg.checks`/`notifications`); строгий never-raise на каждой публичной функции; docstrings
+  на всех публичных символах; `os.lstat` (не `stat`) для честной оценки симлинков. Зависимость
+  односторонняя (`git_worktree` → `fs_normalize`).
+- Узкий `_PERM_MARKERS` сознательно не реклассифицирует не-прав-ошибки (защита AC-2).
+- Тесты содержательны (214/136/139/68 строк), используют `tmp_path`/monkeypatch, без реального
+  chown и записи в `/repos`; покрывают обе ветки классификатора, идемпотентность, scope, kill-switch,
+  TTL-кэш, startup-never-fatal.
+- Утечек/секретов/security-дыр не выявлено; chown физически возможен только под root (`_is_privileged`).
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice-to-have (не блокирует)
+- [ ] `snapshot()` в `GET /queue` на холодном кэше инициирует реальный обход `.git/objects` синхронно
+  в обработчике запроса. На практике кэш прогрет startup-хуком и TTL=300s, обход только для
+  self-hosting — латентность пренебрежима, паттерн зеркалит `coverage_gate`. Можно при желании
+  отдавать в `/queue` только кэш без форс-скана. Информационно.
+
+## Документация
+
+Обновлена в том же PR — golden source синхронен с кодом:
+- `docs/operations/INFRA.md` — P-5 (блокер миграции uid) + подраздел процедуры со всеми корнями ✓
+- `docs/architecture/README.md` — компонент «FS ownership detect» (D1–D3, условность, наблюдаемость) ✓
+- `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md` — сквозной ADR (tracked) ✓
+- `docs/work-items/ORCH-057/06-adr/ADR-001-…md` — work-item ADR ✓
+- `CHANGELOG.md` — запись ORCH-057 ✓
+- `.env.example` — 6 флагов `ORCH_FS_*` ✓
+
+`README.md` «Известные ограничения» (ORCH-079): пункт про legacy-ownership/uid-миграцию там
+отсутствует — закрывать/снимать нечего, обзорная витрина в обновлении не нуждается.
+
+**Вывод:** изменение `src/` сопровождено обновлением документации → требование правила 6
+выполнено.

docs/work-items/ORCH-057/13-test-report.md

@@ -0,0 +1,94 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-057
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-057
+---
+
+# Test Report — ORCH-057
+
+Нормализация legacy root-owned файлов при миграции на uid 1000 (детект + защита worktree).
+Review-вердикт `12-review.md` — **APPROVED**, P0/P1 findings нет.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Дата: 2026-06-10
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-057-bug-follow-up-orch-040-normali`
+  (ветка `feature/ORCH-057-bug-follow-up-orch-040-normali`, тесты прогнаны из рабочего дерева
+  именно этой задачи, НЕ из общего `/repos/orchestrator`)
+
+## Smoke API (read-only, прод-контейнер 8500 не тронут)
+| Эндпоинт | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok","service":"orchestrator"}` — OK |
+| `GET /status` | OK — задача ORCH-057 (id 83) видна на стадии `testing` |
+| `GET /queue` | OK — присутствуют блоки `serial_gate` (ORCH-088) ✓ и `auto_labels` (ORCH-089) ✓ |
+
+> Примечание: блок `fs_ownership` (ORCH-057) на прод-контейнере 8500 **отсутствует** —
+> это ожидаемо: ORCH-057 ещё не задеплоен, прод исполняет предыдущий образ. Read-only блок
+> `fs_ownership` присутствует и протестирован в коде ветки (TC-12, `test_api_queue.py` PASS).
+> Это НЕ регресс смока: обязательные блоки `serial_gate` + `auto_labels` на месте.
+
+## Результаты
+
+### Полный регресс
+`pytest tests/ -q` → **1507 passed, 1 warning in 52.22s** (warning — Pydantic V2 deprecation,
+предсуществующий, не относится к ORCH-057). Прод-контейнер не трогался.
+
+### Профильные сюиты
+`pytest tests/test_git_worktree_perm.py tests/test_fs_normalize.py tests/test_fs_normalize_startup.py tests/test_api_queue.py -v`
+→ **25 passed** — покрывают TC-01…TC-12.
+
+### Сопоставление с тест-планом (04-test-plan.yaml)
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-01 | `ensure_worktree` на git-fatal Permission denied → actionable RuntimeError | `test_git_worktree_perm::test_tc01_permission_git_fatal_becomes_actionable`, `test_tc01_makedirs_permission_error_becomes_actionable` | PASS |
+| TC-02 | не-прав-ошибка сохраняет прежний raw-контракт | `test_git_worktree_perm::test_tc02_non_permission_error_keeps_prior_contract`, `test_tc02_killswitch_off_keeps_raw_contract_even_for_permission` | PASS |
+| TC-03 | `scan_ownership` на дереве с uid≠target → mismatch=True + корни | `test_fs_normalize::test_tc03_scan_detects_mismatch` | PASS |
+| TC-04 | `scan_ownership` на чистом дереве → mismatch=False (идемпотентно) | `test_fs_normalize::test_tc04_clean_tree_no_mismatch` | PASS |
+| TC-05 | never-raise при недоступном/несуществующем корне → WARNING | `test_fs_normalize::test_tc05_never_raise_on_missing_root`, `test_tc05_never_raise_on_walk_error` | PASS |
+| TC-06 | `applies(repo)`: пустой CSV → self-hosting only; непустой — по списку | `test_fs_normalize::test_tc06_applies_empty_csv_self_hosting_only`, `test_tc06_applies_explicit_csv` | PASS |
+| TC-07 | kill-switch OFF → scan/normalize инертны (1:1 как до ORCH-057) | `test_fs_normalize::test_tc07_killswitch_off_scan_inert`, `test_tc07_killswitch_off_normalize_inert` | PASS |
+| TC-08 | `normalize` без прав → no-op + честный лог, НЕ исключение | `test_fs_normalize::test_tc08_normalize_without_rights_is_noop_not_error` | PASS |
+| TC-09 | TTL-кэш: повтор в окне TTL не пере-сканирует; ключ по roots+uid | `test_fs_normalize::test_tc09_ttl_cache_avoids_rescan`, `test_tc09_cache_keyed_by_roots_and_uid` | PASS |
+| TC-10 | startup-хук: mismatch → send_telegram + WARNING; ошибка детекта never-fatal | `test_fs_normalize_startup::test_tc10_startup_mismatch_warns_and_telegrams`, `test_tc10_startup_detect_error_never_fatal`, `test_tc10_startup_clean_no_telegram` | PASS |
+| TC-11 | гейт claim'а: mismatch без прав → внятный исход ДО launch, не сырой git-fatal | `test_fs_normalize_startup::test_tc11_launch_permission_failure_is_actionable_not_raw` | PASS |
+| TC-12 | `GET /queue` блок `fs_ownership` отдаёт поля и не 5xx-ит при выключенном флаге | `test_api_queue::test_tc12_queue_exposes_fs_ownership_block`, `test_tc12_queue_no_5xx_when_disabled`, `test_fs_normalize_check_endpoint` | PASS |
+
+Доп. целевые тесты (сверх плана, усиливают покрытие): `test_classify_worktree_error_markers`,
+`test_is_permission_failure_from_exc`, `test_snapshot_shape` — PASS.
+
+### Сопоставление с критериями приёмки (03-acceptance-criteria.md)
+| AC | Покрыто | Результат |
+|----|---------|-----------|
+| AC-1 — конвейер стартует без ручного chown / внятная блокирующая ошибка | TC-01, TC-11 | PASS |
+| AC-2 — `ensure_worktree` actionable-ошибка при отказе доступа, не-прав сохраняет контракт | TC-01, TC-02 | PASS |
+| AC-3 — детект несоответствия владельца (mismatch на грязной, no-op на чистой) | TC-03, TC-04, TC-05 | PASS |
+| AC-4 — наблюдаемость детекта (WARNING + Telegram + `GET /queue`) | TC-10, TC-12 | PASS |
+| AC-5 — self-hosting безопасность, нулевая регрессия enduro, зелёный регресс | TC-06, TC-07, TC-08 + 1507 passed | PASS |
+| AC-6 — инварианты конвейера (STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-key/схема БД) | полный регресс зелёный, guard-тесты пройдены | PASS |
+| AC-7 — документированная процедура нормализации (INFRA.md + ADR) | проверено reviewer (12-review.md), вне scope pytest | PASS (док.) |
+
+## Вывод pytest
+```
+============================= test session starts ==============================
+platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
+rootdir: /repos/_wt/orchestrator/feature_ORCH-057-bug-follow-up-orch-040-normali
+plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
+collected 25 items  (профильные сюиты)
+... 25 passed, 1 warning in 2.19s
+
+Полный регресс:
+1507 passed, 1 warning in 52.22s
+```
+
+## Итог
+**PASS** — все 12 TC выполнены и сопоставлены с тест-планом и критериями приёмки; профильные
+сюиты 25 passed; полный регресс 1507 passed; smoke (`/health`, `/status`, `/queue` c блоками
+`serial_gate` + `auto_labels`) — зелёный. Задача переходит на `deploy-staging`.

docs/work-items/ORCH-057/14-deploy-log.md

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-057
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-036 executable self-deploy
+
+Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
+
+Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-057/15-staging-log.md

@@ -0,0 +1,33 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-057
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+timestamp: 2026-06-10T00:02:11Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+> Машинный вердикт читается ТОЛЬКО из `staging_status:` во frontmatter. `SUCCESS` → дальше; `FAILED` → откат.
+
+Staging test suite завершён против живого стенда `orchestrator-staging` (8501). Запуск канонический —
+`docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
+(ORCH-048, ADR-001). Скрипт завершился с **exit code 0** → `staging_status: SUCCESS`.
+
+Итог: **8/10 checks PASS**. Все REAL-проверки зелёные; два FAIL — известные sandbox-infra-проверки
+(C9a/C9b), waived согласно ORCH-061 (зависят от членства SANDBOX bot-аккаунтов в проекте, не от
+конвейера). Exit-code → вердикт не меняется: trust the exit code, REAL failed = none.
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Results
+- **Block A (SMOKE)**: PASS — A1 `/health` → 200 `status=ok`; A2 `/queue` → 200 с counts/max_concurrency/resilience; A3 `ORCH_STAGING=true` (не прод).
+- **Block B (ACCESS)**: PASS — B4 Plane sandbox доступен (5 projects, sandbox=YES); B5 Gitea `orchestrator-sandbox` доступен, push=true; B6 Registry изолирован (sandbox present, prod ET/ORCH absent).
+- **Block C (E2E, mode=stub)**: C7 создать issue в Plane SANDBOX → PASS; C8 триггер конвейера `/webhook/plane` → PASS; C9a (branch в sandbox) и C9b (analyst job в очереди) → FAIL, **INFRA-WAIVED** (sandbox bot-accounts не члены проекта). Cleanup: Plane issue удалён (HTTP 204).
+
+REAL failed: none.

docs/work-items/ORCH-098/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: FND: машинный журнал уроков — структурированная база отклонений (топливо петли)
+
+Work Item ID: ORCH-098
+
+## Description
+
+TBD

docs/work-items/ORCH-098/01-brd.md

@@ -0,0 +1,143 @@
+---
+work_item: ORCH-098
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-098 — FND: машинный журнал уроков (структурированная база отклонений)
+
+Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Оркестратор уже автономно проводит задачи через конвейер (ORCH-54), но **развивает** платформу
+по-прежнему вручную связка Слава+Стрим: ловим инциденты → формулируем уроки → заводим задачи.
+Уроки сегодня живут **свободным текстом** в `memory/` — они не машиночитаемы, по ним нельзя
+считать паттерны, нельзя приоритизировать, нельзя автоматически предлагать улучшения.
+
+ORCH-098 — шаг 1 эпика саморазвития (`docs/epics/self-evolution.md`, **домен 0 «Фундамент», F2**,
+ORCH-8). Это **«топливо» вертикали-двигателя** (петля самообучения 8A): формализовать свободный
+текст в **машинную структурированную таблицу отклонений конвейера**. Каждый урок — запись с
+полями для машинного анализа паттернов. Журнал — фундамент, на котором позже встанут
+ретроспективщик (E2), приоритизатор RICE (E3) и Стрим как потребители.
+
+**Установленные факты-источники сигналов («уроков»)** — из памяти орка (инциденты 06–09.06) и §8A
+эпика:
+- Провал гейта (BLOCKED / FAILED / REQUEST_CHANGES).
+- **Ручное вмешательство человека — самый ценный сигнал** (каждый ручной пинок = дыра автономности).
+- Ретраи, откаты деплоя, таймауты агентов.
+- Ложные срабатывания гейтов (исторический пример: substring `PASS` в `check_tests_passed`).
+- «Деплой SUCCESS, а прод не работает» (урок ET-8); транзиенты (Gitea `405`, Anthropic `Overloaded`).
+
+**Решение Славы 10.06 (ОБЯЗАТЕЛЬНО учесть на этапе схемы):** схема журнала ДОЛЖНА **с самого
+начала** нести поля для будущей **АТРИБУЦИИ** урока (иначе потом переделывать схему на живой
+общей прод-БД). Атрибуция (`platform-level` / `project-level` / `both` / `unknown`), целевой
+проект и целевой домен улучшения — это §8A эпика «platform-level vs project-level». При автозаписи
+поля атрибуции могут быть пустыми/`unknown` (классификацию позже ставит ретроспективщик/Стрим), но
+**колонки в схеме должны существовать сразу** — аддитивные, нуллабельные.
+
+**Связь со слоями наблюдения (§2 эпика):** деградация продукта (слой 3, урок ET-8) — один из типов
+урока; журнал должен уметь его хранить с атрибуцией `platform`/`project`.
+
+## 2. Объём (scope)
+
+### В объёме
+- Аддитивная идемпотентная таблица БД `lessons` для структурированных уроков со всеми полями
+  контекста, анализа, статуса **и атрибуции** (колонки атрибуции — сразу, нуллабельные).
+- Leaf-модуль `src/lessons.py` (never-raise, kill-switch) + helper записи урока.
+- **Автозапись** ≥2–3 типов отклонений из кода через best-effort точки врезки в
+  `stage_engine.py` / `merge_gate.py` / `launcher.py` (провал гейта/откат, HOLD, транзиент-ретрай).
+- **Read-only выборка** уроков (HTTP-эндпоинт + блок в `GET /queue`) — для будущего
+  ретроспективщика и Стрим.
+- **Ручная запись** урока (HTTP-эндпоинт / helper) — Стрим/оператор кладёт урок руками.
+- Доки (CLAUDE.md / architecture README / ADR) + `CHANGELOG.md`.
+
+### Вне объёма
+- **Анализ паттернов / ретроспективщик (E2)** — отдельная задача-потребитель журнала.
+- **Приоритизатор RICE (E3)** — отдельная задача.
+- **Автоматическая классификация атрибуции** — её ставит ретроспективщик/человек позже; здесь —
+  только колонки и возможность проставить значение руками/через update.
+- **Банк идей (D4 / идеатор, E5)** — отдельный реестр, НЕ путать с журналом уроков.
+- **Слой-3 детекция здоровья продукта** (мониторинг задеплоенного приложения) — отдельная
+  D4/D5-способность; журнал лишь умеет **хранить** такой урок, когда детектор появится.
+- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключей / любых
+  существующих таблиц.
+- Миграция исторических уроков из `memory/` (ручной разовый импорт — вне объёма).
+
+## 3. Заинтересованные стороны
+- **Заказчик:** Слава (требование атрибуции 10.06 — нормативно).
+- **Прямой потребитель (будущее):** агент-ретроспективщик E2, приоритизатор E3, Стрим (ручной
+  разбор).
+- **Затрагивается:** self-hosting прод-инстанс orchestrator (общая БД и очередь с enduro-trails) —
+  enduro **не должен быть затронут** (аддитивность, never-raise).
+- **Принимает результат:** reviewer/tester конвейера + Слава.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 — Структурированная таблица уроков.** Аддитивная, идемпотентная (`CREATE TABLE IF NOT
+  EXISTS`) таблица `lessons` на общей прод-БД с полями: тип отклонения; контекст
+  (work_item/task/стадия/агент/repo); корневая причина (если известна); предложенное улучшение
+  (если есть); статус (`new`/`in_progress`/`closed`/`linked`) + связанная задача; timestamp.
+- **BR-2 — Поля атрибуции с самого начала.** Схема несёт **сразу** нуллабельные колонки:
+  `attribution` (`platform`/`project`/`both`/`unknown`), `target_repo` (кого касается:
+  `orchestrator`/`enduro-trails`/др.), `target_domain` (домен улучшения:
+  `reliability`/`quality`/`economy`/`features`/`scale`). При автозаписи допустимо пусто/`unknown`.
+- **BR-3 — Автозапись ≥2–3 типов отклонений.** Из кода, best-effort, в детерминированных
+  choke-point: (а) провал гейта / откат на `development` (reviewer REQUEST_CHANGES, tester FAIL,
+  staging/deploy FAILED), (б) HOLD merge-актора / regression-guard HOLD, (в) транзиент-ретрай
+  (Gitea-merge `405`/`5xx`, Anthropic `Overloaded`/agent-timeout requeue). Дополнительно желательно
+  (г) post-deploy `DEGRADED` (урок «деплой OK / прод сломан», слой-3, ET-8) с атрибуцией.
+- **BR-4 — Read-only выборка.** HTTP-эндпоинт `GET /lessons` (фильтры: тип/статус/repo/work_item,
+  лимит) + read-only блок `lessons` в `GET /queue` (сводка). Только чтение.
+- **BR-5 — Ручная запись.** HTTP-эндпоинт `POST /lessons` (+ публичный helper) — оператор/Стрим
+  кладёт урок руками, в т.ч. с проставленной атрибуцией.
+- **BR-6 — Обновление урока.** Возможность сменить статус / проставить атрибуцию / привязать
+  задачу после создания (helper/эндпоинт `POST /lessons/{id}` или поля в `POST /lessons`) — чтобы
+  ретроспективщик/человек позже классифицировал автозаписанный `unknown`.
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — never-raise (критично, self-hosting).** Сбой записи/чтения урока **никогда** не роняет
+  и не тормозит конвейер. Любая ошибка детектора/записи → лог WARNING + продолжение основного
+  потока. Журнал — наблюдатель, не участник пайплайна.
+- **NFR-2 — Kill-switch.** Флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`). `False` →
+  автозапись и эндпоинты инертны (нулевая регрессия, поведение конвейера байт-в-байт прежнее).
+- **NFR-3 — Аддитивность / изоляция enduro.** Только новая таблица + новый leaf + новые эндпоинты +
+  тонкие врезки. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема
+  существующих таблиц — **байт-в-байт не тронуты**. Общая БД: enduro-trails не затронут.
+- **NFR-4 — Restart-safe / идемпотентность таблицы.** `CREATE TABLE IF NOT EXISTS` + `_ensure_column`
+  (паттерн `repo_freeze`/`coverage_baseline`) — безопасно на живой БД, повторный старт без эффекта.
+- **NFR-5 — Лёгкость.** Запись — один `INSERT`, чтение — простые `SELECT` (общий хост впритык:
+  RAM 171Mi free, диск 92%). Никаких фоновых потоков/сканов.
+- **NFR-6 — Схема-forward-proof.** Колонки атрибуции добавлены сразу (BR-2), чтобы не
+  переделывать схему на живой БД, когда появится ретроспективщик.
+- **NFR-7 — Self-hosting безопасность.** Модуль только пишет/читает БД и отдаёт JSON — не
+  деплоит, не рестартит прод, не трогает `main`, не порождает процессы/сеть.
+
+## 6. Допущения и ограничения
+- Журнал уроков — **исключение** из правила «наблюдатель отделён от наблюдаемого» (§2 эпика): это
+  историческая память петли, не realtime-мониторинг → допустимо в БД орка; запись best-effort.
+- Точки автозаписи привязаны к существующим choke-point: `stage_engine._handle_qg_failure_rollbacks`
+  (откаты), `merge_gate` (HOLD/transient-классификатор ORCH-093), `launcher` (timeout/requeue
+  транзиентов). Архитектор уточняет точный набор и сигнатуры врезок.
+- Набор значений `lesson_type` / `attribution` / `target_domain` — конвенция (строковые слаги),
+  не enum-констрейнт БД (forward-compatible; новый тип не требует миграции).
+- Общая прод-БД с enduro: любое поле repo-scoped, фильтрация на уровне выборки.
+
+## 7. Критерии успеха
+Таблица `lessons` создаётся идемпотентно на старте; автозаписаны ≥2–3 типа отклонений из реального
+прогона; `GET /lessons` и `POST /lessons` работают; атрибутивные колонки присутствуют и
+проставляемы; kill-switch выключает всё без регрессии; `pytest tests/ -q` зелёный; доки+CHANGELOG
+обновлены. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- Врезка детектора в горячий путь конвейера → риск регрессии при сбое записи. Митигация: NFR-1
+  never-raise + kill-switch.
+- Рост таблицы со временем (автозапись на каждом откате/ретрае). Митигация: лёгкие строки;
+  будущая ретенция — вне объёма, отметить в `10-tech-risks.md` (архитектор).
+- Недооформленная схема атрибуции → переделка на живой БД. Митигация: BR-2/NFR-6 (колонки сразу).
+- Детали и архитектурные развилки (точные точки врезки, индексы, дедуп автозаписей) — задача
+  архитектора (`06-adr/`, `10-tech-risks.md`).

docs/work-items/ORCH-098/02-trz.md

@@ -0,0 +1,163 @@
+---
+work_item: ORCH-098
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-098 — FND: машинный журнал уроков
+
+Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения (точные сигнатуры врезок, индексы, дедуп, ретенция) — задача
+> архитектора (`06-adr`).
+
+## 1. Сводка изменения
+
+Ввести **машинный журнал уроков** — аддитивную таблицу `lessons` + чистый leaf-модуль
+`src/lessons.py` (never-raise, kill-switch) по образцу `serial_gate.py` / `coverage_gate.py` /
+`metrics.py`. Модуль несёт: helper записи урока (`record`), read-only выборку (`get_lessons`),
+обновление (`update_lesson`), `snapshot()` для `GET /queue`. Автозапись ≥2–3 типов отклонений —
+тонкими best-effort врезками в существующие choke-point `stage_engine.py` / `merge_gate.py` /
+`launcher.py`. Два новых HTTP-эндпоинта (`GET /lessons`, `POST /lessons`) в `main.py`. Схема несёт
+**сразу** нуллабельные колонки атрибуции (требование Славы 10.06). Конвейер (`STAGE_TRANSITIONS` /
+`QG_CHECKS` / `check_*` / machine-verdict) — **не тронут**; enduro — не затронут.
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/db.py` | изменить — `CREATE TABLE IF NOT EXISTS lessons` в `init_db()`; helper'ы `record_lesson` / `get_lessons` / `update_lesson` / `lessons_snapshot` |
+| `src/lessons.py` | **создать** — leaf: `record(...)`, `get(...)`, `update(...)`, `snapshot()`, константы `LessonType`/`Attribution`/`Domain`, `applies()`, never-raise |
+| `src/config.py` | изменить — флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`) + опц. `lessons_query_limit_default` |
+| `src/stage_engine.py` | изменить — best-effort врезка `lessons.record(...)` в `_handle_qg_failure_rollbacks` (откаты gate-fail) и в ветку post-deploy `DEGRADED` → freeze |
+| `src/merge_gate.py` | изменить — best-effort врезка в HOLD/regression-guard HOLD и в транзиент-классификатор (`_classify_merge_response == "transient"` / merge-retry-исчерпан) |
+| `src/agents/launcher.py` | изменить — best-effort врезка при timeout-kill / транзиент-requeue агента |
+| `src/main.py` | изменить — эндпоинты `GET /lessons`, `POST /lessons` (+опц. `POST /lessons/{id}`); блок `lessons` в `GET /queue` |
+| `tests/test_lessons.py` | **создать** — unit + integration (см. `04-test-plan.yaml`) |
+| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | изменить — документация |
+
+## 3. Функциональные требования
+
+### FR-1 — Таблица `lessons` (BR-1, BR-2)
+Аддитивная идемпотентная таблица в `db.init_db()` (паттерн `repo_freeze`/`coverage_baseline`):
+
+```sql
+CREATE TABLE IF NOT EXISTS lessons (
+    id            INTEGER PRIMARY KEY AUTOINCREMENT,
+    created_at    TEXT NOT NULL DEFAULT (datetime('now')),
+    updated_at    TEXT,
+    -- тип отклонения (slug-конвенция, не enum-констрейнт)
+    lesson_type   TEXT NOT NULL,
+    -- контекст
+    work_item_id  TEXT,
+    task_id       INTEGER,
+    stage         TEXT,
+    agent         TEXT,
+    repo          TEXT,
+    -- анализ
+    root_cause    TEXT,
+    suggestion    TEXT,
+    -- статус
+    status        TEXT NOT NULL DEFAULT 'new',   -- new|in_progress|closed|linked
+    related_task  TEXT,
+    -- АТРИБУЦИЯ (BR-2, Слава 10.06) — нуллабельные, заполняются позже
+    attribution   TEXT,                          -- platform|project|both|unknown
+    target_repo   TEXT,                          -- кого касается (orchestrator|enduro-trails|…)
+    target_domain TEXT,                          -- reliability|quality|economy|features|scale
+    -- учёт
+    source        TEXT,                          -- auto|manual
+    detail        TEXT                           -- свободный JSON/текст (payload детектора)
+);
+CREATE INDEX IF NOT EXISTS idx_lessons_type_status ON lessons (lesson_type, status);
+CREATE INDEX IF NOT EXISTS idx_lessons_repo        ON lessons (repo);
+```
+Колонки атрибуции создаются **сразу** и нуллабельны (NFR-6). На уже созданной таблице новые
+колонки добавляются `_ensure_column` (forward-safe). Никакого `enum`-констрейнта — значения суть
+конвенция строковых слагов (forward-compatible).
+
+### FR-2 — Helper записи `lessons.record(...)` (BR-3, BR-5; NFR-1)
+Сигнатура (уточняет архитектор), напр.:
+`record(lesson_type, *, work_item_id=None, task_id=None, stage=None, agent=None, repo=None,
+root_cause=None, suggestion=None, status="new", related_task=None, attribution=None,
+target_repo=None, target_domain=None, source="auto", detail=None) -> int | None`.
+- При `lessons_enabled is False` → немедленный no-op (`None`), без обращения к БД.
+- Оборачивает `db.record_lesson` в `try/except` → при любой ошибке `logger.warning` + `None`
+  (**never-raise**, NFR-1). Возвращает `id` вставленной строки при успехе.
+- `source="auto"` для детекторов, `source="manual"` для ручной записи.
+
+### FR-3 — Автозапись отклонений (BR-3)
+Минимум 2–3 типа, best-effort (каждая врезка обёрнута/делегирует в never-raise `record`):
+- **FR-3a — gate-fail / rollback** — в `stage_engine._handle_qg_failure_rollbacks`: при откате на
+  `development` (reviewer `REQUEST_CHANGES`, tester `check_tests_passed` FAIL, staging FAILED,
+  deploy FAILED) → `record("gate_failure", stage=…, agent=…, work_item_id=…, repo=…,
+  root_cause=reason)`. Тип откатной причины → в `detail`/`root_cause`.
+- **FR-3b — merge HOLD / regression-guard HOLD** — в `merge_gate` (путь HOLD `_handle_merge_verify`
+  / `main_regressed_alerts_total` инкремент) → `record("merge_hold", …, root_cause=…)`.
+- **FR-3c — транзиент-ретрай** — в `merge_gate._classify_merge_response`-ветке `"transient"`
+  (Gitea `405`/`5xx`) и/или `launcher` timeout-kill / транзиент-requeue (Anthropic `Overloaded`) →
+  `record("transient_retry", …, detail=<код/причина>)`.
+- **FR-3d (желательно) — post-deploy DEGRADED** — в ветке `stage_engine`, где post-deploy
+  `DEGRADED`/rollback ведёт к `set_repo_freeze` (ORCH-088/021) → `record("deploy_degraded", …,
+  attribution=None|"unknown", target_repo=repo)` — урок «деплой OK / прод сломан» (слой-3, ET-8),
+  атрибуцию проставит ретроспективщик/человек позже.
+
+Дедуп/частота автозаписи (чтобы не плодить дубли на ретраях) — решение архитектора (например,
+ключ `work_item_id+stage+lesson_type` в окне); если не реализуется в v1 — отметить в `10-tech-risks.md`.
+
+### FR-4 — Read-only выборка (BR-4)
+`db.get_lessons(*, lesson_type=None, status=None, repo=None, work_item_id=None, limit=N) ->
+list[dict]` (параметризованный `SELECT … ORDER BY id DESC LIMIT ?`). `lessons.get(...)` —
+never-raise обёртка → `[]` при ошибке. `lessons.snapshot()` — лёгкая сводка (счётчики по
+типу/статусу, последние N) для `GET /queue`, never-raise → `{}`.
+
+### FR-5 — Ручная запись + обновление (BR-5, BR-6)
+- `POST /lessons` (тело JSON) → `lessons.record(..., source="manual")`. Возвращает `{id}`.
+- `POST /lessons/{id}` (или поля в `POST /lessons`) → `lessons.update(id, status=…,
+  attribution=…, target_repo=…, target_domain=…, related_task=…, root_cause=…, suggestion=…)` →
+  `db.update_lesson` (`UPDATE … SET … updated_at=datetime('now')`). Позволяет ретроспективщику/
+  человеку классифицировать автозаписанный `unknown`. never-raise.
+
+### FR-6 — Kill-switch + изоляция (NFR-2, NFR-3)
+`lessons_enabled=False` → `record`/`get`/`update`/`snapshot` инертны, эндпоинты возвращают
+`{"enabled": false}` (паттерн `metrics_endpoint_enabled`), врезки no-op. Поведение конвейера —
+байт-в-байт прежнее. enduro не затронут (общая БД, аддитивная таблица).
+
+## 4. Изменения API
+Новые эндпоинты в `src/main.py` (стиль `GET /queue` / `POST /coverage/baseline`):
+- **`GET /lessons`** — read-only выборка. Query: `type`, `status`, `repo`, `work_item`, `limit`
+  (дефолт из конфига). Ответ: `{"enabled": bool, "lessons": [ {…строка…} ]}`. Всегда `200`.
+- **`POST /lessons`** — ручная запись. Тело: `lesson_type` (обяз.) + опциональные поля контекста/
+  анализа/атрибуции. Ответ: `{"id": <int>}` или `{"enabled": false}`.
+- **(опц.) `POST /lessons/{id}`** — обновление статуса/атрибуции/привязки задачи. Ответ `{"ok": bool}`.
+- `GET /queue` — добавить read-only ключ `"lessons": lessons.snapshot()` (рядом с `serial_gate`/
+  `coverage`/`bug_fast_track`). Существующие ключи — без изменений.
+
+`GET /health` / `GET /status` / `GET /metrics` / прочие эндпоинты — **байт-в-байт прежние**.
+
+## 5. Изменения схемы БД
+**Новая аддитивная таблица `lessons`** (FR-1) + два индекса, всё `IF NOT EXISTS` / `_ensure_column`.
+Существующие таблицы (`tasks`/`jobs`/`agent_runs`/`events`/`job_deps`/`repo_freeze`/
+`coverage_baseline`/`tracker_messages`) — **не тронуты**. Колонки атрибуции — сразу, нуллабельные
+(BR-2/NFR-6). Restart-safe, идемпотентно, безопасно на живой общей прод-БД (enduro не затронут).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Журнал уроков — наблюдатель, **не** Quality Gate. `QG_CHECKS` / `check_*` /
+machine-verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
+`coverage_status:`) — байт-в-байт не тронуты. Журнал не влияет на продвижение по стадиям.
+
+## 7. Совместимость / регресс
+- **Kill-switch** `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`): `False` → полная
+  инертность, нулевая регрессия.
+- **never-raise** на всех публичных функциях и врезках (NFR-1) — сбой журнала не роняет конвейер.
+- **Аддитивно**: только новая таблица + leaf + эндпоинты + тонкие врезки; ничего существующего не
+  переписывается.
+- **Изоляция enduro**: общая БД, новая таблица; репо-скоуп через поле/фильтр выборки.
+- **Обратимость**: выключение флага возвращает прод к доресурсному поведению мгновенно.
+- **Self-hosting безопасность** (NFR-7): модуль не деплоит/не рестартит прод/не трогает `main`/без
+  процессов/сети.
+- **Артефакты pipeline:** задача создаёт/обновляет стандартный пакет (`01`–`04` + `06-adr` от
+  архитектора, `12`/`13`/`14`/`15`/`17`/`18` по ходу конвейера). Сам журнал — БД-сущность, не
+  номерной артефакт.

docs/work-items/ORCH-098/03-acceptance-criteria.md

@@ -0,0 +1,123 @@
+---
+work_item: ORCH-098
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-098 — FND: машинный журнал уроков
+
+Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
+считается провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
+
+---
+
+## AC-1 — Аддитивная таблица уроков
+
+**Условие:** `db.init_db()` создаёт таблицу `lessons` идемпотентно.
+- **PASS:** в `src/db.py` есть `CREATE TABLE IF NOT EXISTS lessons (...)` со всеми полями
+  (`lesson_type`, контекст `work_item_id/task_id/stage/agent/repo`, `root_cause`, `suggestion`,
+  `status`+`related_task`, `created_at`); повторный `init_db()` не падает и не дублирует; таблица
+  создаётся на общей прод-БД без изменения существующих таблиц.
+- **FAIL:** таблицы нет / создаётся не идемпотентно / отсутствует любое поле из BR-1 / меняется
+  схема существующей таблицы.
+
+---
+
+## AC-2 — Поля атрибуции присутствуют с самого начала
+
+**Условие:** схема `lessons` несёт нуллабельные колонки атрибуции (требование Славы 10.06).
+- **PASS:** колонки `attribution` (`platform`/`project`/`both`/`unknown`), `target_repo`,
+  `target_domain` существуют сразу, нуллабельны, допускают пустое/`unknown` при автозаписи и
+  проставляются позже через update.
+- **FAIL:** хотя бы одной из трёх колонок нет в исходной схеме / колонка `NOT NULL` без дефолта /
+  атрибуцию нельзя проставить после создания записи.
+
+---
+
+## AC-3 — Автозапись ≥2–3 типов отклонений
+
+**Условие:** из кода автоматически (best-effort, `source="auto"`) пишутся минимум 2–3 типа уроков.
+- **PASS:** есть врезки `lessons.record(...)` минимум в двух-трёх точках из:
+  `stage_engine._handle_qg_failure_rollbacks` (gate-fail/откат), `merge_gate` (HOLD/transient),
+  `launcher` (timeout/transient-requeue); интеграционный тест подтверждает появление строки в
+  `lessons` после смоделированного отклонения.
+- **FAIL:** автозаписи нет / реализован <2 типов / врезка может бросить исключение в горячий путь.
+
+---
+
+## AC-4 — Read-only выборка
+
+**Условие:** уроки можно прочитать через эндпоинт и сводку в `GET /queue`.
+- **PASS:** `GET /lessons` возвращает `200` с массивом уроков, поддерживает фильтры
+  (type/status/repo/work_item/limit); `GET /queue` содержит read-only блок `lessons`; ни один
+  путь чтения не мутирует данные.
+- **FAIL:** эндпоинта нет / не фильтрует / чтение мутирует данные / блока в `/queue` нет.
+
+---
+
+## AC-5 — Ручная запись и обновление
+
+**Условие:** оператор/Стрим кладёт урок руками и может его доклассифицировать.
+- **PASS:** `POST /lessons` создаёт урок (`source="manual"`, можно задать атрибуцию); обновление
+  (`POST /lessons/{id}` или поля) меняет `status`/`attribution`/`target_*`/`related_task` и
+  стампит `updated_at`.
+- **FAIL:** ручной записи нет / нельзя проставить атрибуцию / нельзя обновить автозаписанный урок.
+
+---
+
+## AC-6 — never-raise (сбой журнала не роняет конвейер)
+
+**Условие:** любая ошибка записи/чтения урока изолирована от пайплайна.
+- **PASS:** все публичные функции `src/lessons.py` и все врезки обёрнуты так, что исключение БД/
+  любого источника → `logger.warning` + безопасный дефолт (`None`/`[]`/`{}`); юнит-тест с
+  замоканной падающей БД подтверждает, что вызывающий код (откат/HOLD/retry) не падает.
+- **FAIL:** исключение из журнала пробивается в `stage_engine`/`merge_gate`/`launcher`/эндпоинт.
+
+---
+
+## AC-7 — Kill-switch и нулевая регрессия
+
+**Условие:** `lessons_enabled=False` делает функционал инертным.
+- **PASS:** при `False` `record`/`get`/`update`/`snapshot` — no-op (без обращения к БД), эндпоинты
+  отдают `{"enabled": false}`, врезки не пишут; поведение конвейера и `GET /queue` (помимо нового
+  блока) — байт-в-байт прежнее; enduro-trails не затронут.
+- **FAIL:** при `False` журнал что-то пишет/ломает / меняется поведение конвейера / затронут enduro.
+
+---
+
+## AC-8 — Инварианты конвейера не тронуты
+
+**Условие:** изменение не касается машины стадий и гейтов.
+- **PASS:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, функции `check_*`, machine-verdict-ключи и
+  схема существующих таблиц — **диффом не затронуты**; журнал не влияет на продвижение по стадиям.
+- **FAIL:** изменён любой из перечисленных артефактов / журнал участвует в решении гейта.
+
+---
+
+## AC-9 — Тесты, документация, CHANGELOG
+
+**Условие:** изменение проверено и задокументировано.
+- **PASS:** `pytest tests/ -q` зелёный (включая новый `tests/test_lessons.py` с unit+integration);
+  обновлены `CLAUDE.md` + `docs/architecture/README.md`; в задаче есть `06-adr/` (архитектор);
+  `CHANGELOG.md` дополнен.
+- **FAIL:** тесты падают / нет покрытия новой логики / документация или CHANGELOG не обновлены.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-1 / NFR-6 |
+| AC-3 | BR-3 / FR-2 / FR-3 |
+| AC-4 | BR-4 / FR-4 |
+| AC-5 | BR-5 / BR-6 / FR-5 |
+| AC-6 | NFR-1 / FR-2 |
+| AC-7 | NFR-2 / NFR-3 / FR-6 |
+| AC-8 | NFR-3 / FR-6 |
+| AC-9 | NFR-1…NFR-7 (верификация) |

docs/work-items/ORCH-098/04-test-plan.yaml

@@ -0,0 +1,91 @@
+work_item: ORCH-098
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "Журнал уроков: таблица, автозапись отклонений, выборка, ручная запись, never-raise"
+framework: pytest
+scope: >
+  Покрывается: создание аддитивной таблицы lessons (идемпотентность, поля атрибуции),
+  helper записи record(), автозапись из choke-point (gate-fail/HOLD/transient), read-only
+  выборка get_lessons + snapshot, ручная запись/обновление, kill-switch, never-raise.
+  Вне покрытия: ретроспективщик (E2), приоритизатор (E3), автоклассификация атрибуции,
+  слой-3 детекция здоровья продукта.
+notes: >
+  Тесты используют изолированную временную SQLite-БД (фикстура init_db во временном файле).
+  Полный регресс tests/ должен оставаться зелёным. Self-hosting: журнал never-raise — ни один
+  тест не должен показать, что сбой записи урока роняет конвейер.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "init_db() создаёт таблицу lessons идемпотентно (двойной вызов не падает, нет дублей); присутствуют все поля BR-1."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Схема lessons несёт нуллабельные колонки атрибуции attribution/target_repo/target_domain; запись без них проходит (NULL/unknown), update проставляет их позже."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "lessons.record() вставляет строку с переданными полями (source=auto/manual), возвращает id; created_at заполняется."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "never-raise: при замоканной падающей БД record/get/update/snapshot возвращают None/[]/{} и не бросают исключение (logger.warning)."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "kill-switch: при lessons_enabled=False record/get/update/snapshot инертны (no-op, без обращения к БД)."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "get_lessons фильтрует по type/status/repo/work_item и соблюдает limit; порядок ORDER BY id DESC."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "update_lesson меняет status/attribution/target_*/related_task и стампит updated_at; несуществующий id безопасен."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "Автозапись gate-fail: смоделированный откат на development в _handle_qg_failure_rollbacks создаёт строку lessons type=gate_failure с контекстом (stage/agent/work_item/repo)."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "Автозапись transient/HOLD: транзиент-ветка merge_gate (или timeout/requeue launcher) пишет урок type=transient_retry/merge_hold; сбой записи не ломает основной путь (never-raise в горячем пути)."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "GET /lessons возвращает 200 с массивом и фильтрами; GET /queue содержит read-only блок lessons; чтение не мутирует данные."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "POST /lessons создаёт ручной урок (source=manual, с атрибуцией); POST /lessons/{id} обновляет его; при lessons_enabled=False эндпоинты отдают {enabled:false}."
+    module: tests/test_lessons.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "Инварианты конвейера не тронуты: STAGE_TRANSITIONS/QG_CHECKS/machine-verdict-ключи неизменны (структурный анти-регресс по составу реестра)."
+    module: tests/test_lessons.py
+    expected: PASS

docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md

@@ -0,0 +1,244 @@
+---
+work_item: ORCH-098
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Машинный журнал уроков `lessons` — аддитивная таблица + observer-leaf
+
+Work Item: **ORCH-098** — FND: машинный журнал уроков (структурированная база отклонений конвейера)
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0034-lessons-journal.md`** (решение
+кросс-каттинговое: новый компонент + новая таблица на общей прод-БД + фундамент эпика
+саморазвития).
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-098 — шаг 1 («Фундамент», F2) эпика саморазвития: формализовать свободнотекстовые «уроки»
+из `memory/` в **машинную структурированную таблицу отклонений конвейера**, на которой позже
+встанут ретроспективщик (E2), приоритизатор RICE (E3) и Стрим. BRD/TRZ уже зафиксировали состав
+полей, набор эндпоинтов и структуру leaf-модуля; нормативное требование Славы 10.06 — колонки
+**атрибуции** в схеме **с самого начала** (нуллабельные), чтобы не переделывать схему на живой
+общей прод-БД.
+
+Сверено по коду (recon):
+- **Образец observer-leaf**: `src/serial_gate.py`, `src/coverage_gate.py`, `src/metrics.py` —
+  чистые leaf'ы, импортируют только `config`+`db`, `applies(repo)`-first, never-raise, `snapshot()`
+  для `GET /queue`.
+- **БД-паттерн**: `db.get_db() -> sqlite3.Connection` (`row_factory=sqlite3.Row`, `.close()` в
+  `finally`); `db.init_db()` — `executescript` с `CREATE TABLE IF NOT EXISTS …`; идемпотентные
+  миграции `_ensure_column(conn, table, column, decl)` (`src/db.py:341`). Эталон аддитивной таблицы
+  — `repo_freeze`, `coverage_baseline`; атомарный helper — `ratchet_coverage_baseline` (`db.py:251`).
+- **Choke-point'ы автозаписи** (точные сигнатуры):
+  - `stage_engine._handle_qg_failure_rollbacks(task_id, current_stage, repo, work_item_id, branch,
+    agent, qg_name, reason, result)` (`src/stage_engine.py:728`) — все нужные поля контекста
+    локально доступны.
+  - post-deploy `DEGRADED → set_repo_freeze` (`src/stage_engine.py:~1993`) — доступны `repo`,
+    `work_item_id`, `branch`, локально собранный `reason`.
+  - `merge_gate._handle_merge_verify(task_id, repo, work_item_id, branch, result)`
+    (`src/merge_gate.py:1588`); ветка HOLD ставит `result.note="merge-not-verified-hold"` (~`:1695`).
+  - `merge_gate._classify_merge_response(repo, branch, index, status_code) -> "transient"|"terminal"`
+    (`src/merge_gate.py:811`).
+  - `launcher._watchdog`/`stop_process` (timeout-kill) и `launcher._finalize_transient(job_id, agent,
+    run_id, exit_code, job, retry_after)` (`src/agents/launcher.py:997`) — транзиент-requeue с
+    бюджетом `transient_attempts`.
+- **Конфиг-паттерн**: pydantic `BaseSettings` с авто-биндингом `ORCH_*`; пары `*_enabled` (bool) +
+  `*_repos` (CSV); `is_self_hosting_repo(repo)` (`src/qg/checks.py:520`).
+
+«Как есть» не годится: уроки в `memory/` не машиночитаемы — нельзя считать паттерны, нельзя
+приоритизировать. Нужна структурированная таблица, но врезанная в **горячий путь** конвейера, что
+на self-hosting прод-инстансе с общей БД (enduro-trails) требует жёсткой изоляции.
+
+## Решение
+
+### Сводка
+
+Ввести **аддитивную идемпотентную таблицу `lessons`** + **чистый observer-leaf `src/lessons.py`**
+(never-raise, kill-switch) по образцу `serial_gate`/`coverage_gate`/`metrics`. Leaf несёт
+`record()` / `get()` / `update()` / `snapshot()`. Автозапись 4 типов отклонений — тонкими
+best-effort врезками в существующие choke-point. Два-три HTTP-эндпоинта в `main.py`. Колонки
+атрибуции — в схеме сразу, нуллабельные. **Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict) и схемы существующих таблиц — байт-в-байт не тронуты; enduro не затронут.**
+
+### D1 — Таблица `lessons`: аддитивная, идемпотентная, forward-proof (BR-1, BR-2; AC-1, AC-2)
+
+`CREATE TABLE IF NOT EXISTS lessons (…)` в `db.init_db()` (паттерн `repo_freeze`):
+
+```sql
+CREATE TABLE IF NOT EXISTS lessons (
+    id            INTEGER PRIMARY KEY AUTOINCREMENT,
+    created_at    TEXT NOT NULL DEFAULT (datetime('now')),
+    updated_at    TEXT,
+    lesson_type   TEXT NOT NULL,                 -- slug-конвенция, НЕ enum-констрейнт
+    work_item_id  TEXT,
+    task_id       INTEGER,
+    stage         TEXT,
+    agent         TEXT,
+    repo          TEXT,
+    root_cause    TEXT,
+    suggestion    TEXT,
+    status        TEXT NOT NULL DEFAULT 'new',    -- new|in_progress|closed|linked
+    related_task  TEXT,
+    attribution   TEXT,                           -- platform|project|both|unknown (NULLABLE)
+    target_repo   TEXT,                           -- orchestrator|enduro-trails|… (NULLABLE)
+    target_domain TEXT,                           -- reliability|quality|economy|features|scale (NULLABLE)
+    source        TEXT,                           -- auto|manual
+    detail        TEXT                            -- свободный JSON/текст (payload детектора)
+);
+CREATE INDEX IF NOT EXISTS idx_lessons_type_status ON lessons (lesson_type, status);
+CREATE INDEX IF NOT EXISTS idx_lessons_repo        ON lessons (repo);
+CREATE INDEX IF NOT EXISTS idx_lessons_wi_type     ON lessons (work_item_id, lesson_type);
+```
+
+**Инварианты:**
+- Все три колонки **атрибуции создаются сразу и нуллабельны** (NFR-6, требование Славы 10.06): на
+  живой уже-существующей таблице добавляются через `_ensure_column(conn, "lessons", "<col>",
+  "TEXT")` — forward-safe, restart-safe, без миграции данных.
+- **Нет `enum`/`CHECK`-констрейнта** на `lesson_type`/`attribution`/`target_domain` — значения суть
+  конвенция строковых слагов (новый тип урока не требует миграции схемы; §6 допущений BRD).
+- **Третий индекс `idx_lessons_wi_type`** добавлен сверх двух из TRZ — обслуживает дедуп-запрос
+  автозаписи (D4) одним indexed-lookup'ом (NFR-5).
+
+DDL-хелперы в `db.py` (стиль `coverage_baseline`): `record_lesson(...) -> int|None`,
+`get_lessons(...) -> list[dict]`, `update_lesson(id, **fields) -> bool`, `lessons_snapshot() -> dict`.
+Каждый открывает `get_db()` и закрывает в `finally`.
+
+### D2 — Observer-leaf `src/lessons.py`: scope **kill-switch only**, НЕ repo-gated (BR-3/4/5/6; NFR-1/2/7)
+
+Чистый leaf, импортирует только `config`+`db` (lazy `notifications` при необходимости); **никогда
+не импортирует `stage_engine`/`merge_gate`/`launcher`** (анти-цикл). Публичный контракт:
+
+```python
+def record(lesson_type, *, work_item_id=None, task_id=None, stage=None, agent=None, repo=None,
+           root_cause=None, suggestion=None, status="new", related_task=None, attribution=None,
+           target_repo=None, target_domain=None, source="auto", detail=None) -> int | None
+def get(*, lesson_type=None, status=None, repo=None, work_item_id=None, limit=None) -> list[dict]
+def update(lesson_id, **fields) -> bool
+def snapshot() -> dict
+```
+
+**Ключевое решение D2 — расхождение с шаблоном гейт-leaf'ов: журнал НЕ скоупится по repo.**
+В отличие от `serial_gate`/`coverage_gate`/`bug_fast_track` (которые *действуют* на конкретный репо
+и потому имеют пару `*_repos`), журнал — **observer-only**: запись строки никогда не влияет на
+пайплайн ни одного репо. Поэтому:
+- единственный регулятор — глобальный kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`,
+  дефолт `True`); **`lessons_repos` НЕ вводится**;
+- recorder пишет уроки про **любой** репо (включая enduro-trails) — урок про деградацию деплоя
+  enduro ценен для петли самообучения; репо-скоуп терял бы этот сигнал;
+- `repo`-разрез — на уровне **выборки** (`get(repo=…)`, фильтр `snapshot()`), как зафиксировано в
+  §6 BRD «репо-скоуп через поле/фильтр выборки».
+- **enduro не затронут (NFR-3):** запись observer-строки про enduro не меняет ни одной стадии/гейта
+  enduro — это чистая память орка.
+
+**never-raise (NFR-1, AC-6):** при `lessons_enabled is False` каждая функция — немедленный no-op
+(`record→None`, `get→[]`, `update→False`, `snapshot→{}`) **без обращения к БД**. При `True` — тело в
+`try/except Exception → logger.warning(...) + безопасный дефолт`. Журнал **не** деплоит, **не**
+рестартит прод, **не** трогает `main`, **не** порождает процессов/сети (NFR-7).
+
+### D3 — Точки автозаписи: 4 детектора, тонкая врезка одним вызовом (BR-3; FR-3; AC-3)
+
+Каждая врезка = локальный импорт + один вызов `lessons.record(...)`, обёрнутый в защитный
+`try/except` (паттерн post-deploy-freeze-врезки `stage_engine.py:~1993`), чтобы даже ошибка импорта
+не пробилась в горячий путь:
+
+| Тип (`lesson_type`) | Choke-point | Контекст врезки |
+|---|---|---|
+| `gate_failure` | `stage_engine._handle_qg_failure_rollbacks` (после решения об откате на `development`) | `work_item_id, task_id, stage=current_stage, agent, repo, root_cause=reason, detail=qg_name` |
+| `merge_hold` | `merge_gate._handle_merge_verify` (ветка HOLD, `result.note="merge-not-verified-hold"`) | `work_item_id, task_id, repo, stage="deploy", root_cause="merge-not-verified-hold"` |
+| `transient_retry` | **budget-exhaustion**: `merge_gate` (merge-retry исчерпан) и/или `launcher._finalize_transient` (исчерпан `transient_attempts`) | `work_item_id?, repo, agent?, stage?, detail=<код/причина>` |
+| `deploy_degraded` | `stage_engine` post-deploy `DEGRADED → set_repo_freeze` | `work_item_id, repo, stage="deploy", root_cause=reason, attribution="unknown", target_repo=repo, target_domain="reliability"` |
+
+Все врезки — `source="auto"`. Это **4 типа > минимума 2–3** (BR-3). `(г) deploy_degraded` (желаемый
+по TRZ) включён как полноценный детектор: это урок слоя-3 «деплой OK / прод сломан» (ET-8),
+ради которого Слава и потребовал атрибуцию.
+
+### D4 — Дедуп автозаписи: один indexed-SELECT в окне (BR-3; FR-3 «решение архитектора»; NFR-5)
+
+Риск: транзиент-ретраи/повторные откаты плодят дубли. Решение — **дешёвый дедуп только для
+`source="auto"`** внутри `record()`: перед `INSERT` — один indexed-lookup
+```sql
+SELECT 1 FROM lessons
+WHERE work_item_id = ? AND lesson_type = ? AND (stage IS ? OR ?)  -- stage-match
+  AND created_at > datetime('now', ?)                            -- '-<window> seconds'
+LIMIT 1;
+```
+по индексу `idx_lessons_wi_type` (D1). Найдено → no-op (`return None`, лог DEBUG). Окно —
+`lessons_dedup_window_s` (env `ORCH_LESSONS_DEDUP_WINDOW_S`, дефолт `3600`). **`source="manual"`
+дедуп НЕ проходит** (оператор/Стрим всегда может записать). Это один лёгкий `SELECT` (NFR-5), без
+фоновых сканов.
+
+**Доп. контроль флуда на самом шумном детекторе:** `transient_retry` пишется **только на исчерпании
+бюджета ретраев** (а не на каждом backoff) — это и есть ценный сигнал «транзиенты исчерпаны», а не
+шум каждой попытки. Так флуд гасится в источнике до дедупа.
+
+### D5 — Эндпоинты `main.py`: read-only выборка + ручная запись/обновление (BR-4/5/6; FR-4/5; AC-4/5)
+
+Стиль `GET /queue` / `POST /coverage/baseline`, все never-raise, при выключенном флаге →
+`{"enabled": false}`:
+- **`GET /lessons`** — query `type/status/repo/work_item/limit` (дефолт `lessons_query_limit_default`,
+  напр. 100) → `{"enabled": bool, "lessons": [...]}`, всегда `200`, только чтение.
+- **`POST /lessons`** — тело JSON, `lesson_type` обязателен → `lessons.record(..., source="manual")`
+  → `{"id": <int>}`.
+- **`POST /lessons/{id}`** — `lessons.update(id, status=…, attribution=…, target_repo=…,
+  target_domain=…, related_task=…, root_cause=…, suggestion=…)` → `{"ok": bool}`; стампит
+  `updated_at=datetime('now')`. Позволяет ретроспективщику/человеку доклассифицировать
+  автозаписанный `unknown`.
+- **`GET /queue`** — добавить read-only ключ `"lessons": lessons.snapshot()` рядом с
+  `serial_gate`/`coverage`. `snapshot()` — лёгкие `GROUP BY`-счётчики (по типу/статусу) + последние
+  N. Существующие ключи `/queue` и эндпоинты `/health|/status|/metrics` — **байт-в-байт прежние**.
+
+### D6 — Изоляция от конвейера и гейтов (NFR-3; AC-8)
+
+`STAGE_TRANSITIONS`, реестр `QG_CHECKS`, функции `check_*`, machine-verdict-ключи
+(`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`) и
+схемы существующих таблиц — **диффом не затрагиваются**. Журнал — наблюдатель, **не** Quality Gate;
+он не участвует в решении о продвижении по стадиям. Никаких новых/изменённых QG-checks (FR-6).
+
+## Альтернативы
+
+- **Repo-скоуп `lessons_repos` (как у гейтов)** — отвергнуто: журнал observer-only, не действует на
+  репо; скоуп терял бы ценные enduro-уроки. Скоуп — на выборке (D2).
+- **Без дедупа в v1 (TRZ это допускает)** — отвергнуто как дефолт: транзиент-ретраи реально
+  флудят таблицу; дешёвый indexed-дедуп (D4) дешевле, чем последующая чистка. Бюджет-exhaustion +
+  окно дают двойную защиту при одном `SELECT`.
+- **Запись `transient_retry` на каждом backoff** — отвергнуто: шум; ценен факт исчерпания бюджета.
+- **Отдельная БД/файл для журнала** — отвергнуто: лишняя зависимость; общая SQLite-БД с аддитивной
+  таблицей соответствует принципу «минимум зависимостей» и паттерну `repo_freeze`/`coverage_baseline`.
+- **Фоновый агрегатор/ретенция-крон в v1** — отвергнуто: NFR-5 (без фоновых потоков/сканов);
+  ретенция — будущая задача (см. `10-tech-risks.md` TR-2).
+- **ORM** — отвергнуто: raw SQL достаточно (принцип «без ORM, если хватает raw SQL»).
+
+## Последствия
+
+- **+** Уроки становятся машиночитаемыми — фундамент для E2/E3/Стрим; атрибуция forward-proof
+  (колонки сразу, переделки живой БД не будет).
+- **+** Нулевая регрессия: kill-switch + never-raise + чистая аддитивность; enduro не затронут;
+  конвейер байт-в-байт прежний.
+- **+** Следует проверенному additive-observer-leaf шаблону (`serial_gate`/`coverage_gate`/`metrics`/
+  `cancel`/`bug_fast_track`) — низкий архитектурный риск, не требует `arch:major-change` (см.
+  `10-tech-risks.md` сводный вывод).
+- **−** Рост таблицы со временем (автозапись на отклонениях). Митигейшн: лёгкие строки + дедуп (D4) +
+  budget-exhaustion-only для транзиентов; ретенция — TR-2 (будущее).
+- **−** Лёгкое усложнение `record()` дедуп-запросом. Митигейшн: один indexed-SELECT, только для
+  `auto`, под окном; для `manual` пропускается.
+- **Откат:** `ORCH_LESSONS_ENABLED=false` → весь функционал инертен мгновенно (no-op, нулевая
+  регрессия). Полный откат — revert диффа; таблица `lessons` остаётся пустой/неиспользуемой,
+  существующих таблиц не касается.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-098/01-brd.md`
+- TRZ: `docs/work-items/ORCH-098/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-098/03-acceptance-criteria.md`
+- Data: `docs/work-items/ORCH-098/08-data-requirements.md`
+- Infra: `docs/work-items/ORCH-098/07-infra-requirements.md`
+- Risks: `docs/work-items/ORCH-098/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0034-lessons-journal.md`
+- Сверено по коду: `src/serial_gate.py`, `src/coverage_gate.py`, `src/metrics.py`, `src/db.py:251,341`,
+  `src/stage_engine.py:728,~1993`, `src/merge_gate.py:811,1588`, `src/agents/launcher.py:997`,
+  `src/main.py` (`GET /queue`, `POST /coverage/baseline`), `src/qg/checks.py:520`.

docs/work-items/ORCH-098/07-infra-requirements.md

@@ -0,0 +1,45 @@
+---
+work_item: ORCH-098
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-098 — машинный журнал уроков `lessons`
+
+Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Топология **не меняется**; файл создан для аудитопригодности (новая env-переменная).
+
+## I-1. Топология / окружения
+**N/A.** Новых контейнеров/портов/сети/томов нет. Таблица `lessons` живёт в существующей общей
+SQLite-БД (тот же том `./data`), эндпоинты обслуживаются текущим процессом `orchestrator` (8500) /
+`orchestrator-staging` (8501). Принцип «всё в Docker на одном сервере mva154» — соблюдён.
+
+## I-2. Переменные окружения / секреты
+Новые env (pydantic `BaseSettings`, авто-биндинг `ORCH_*`), все с безопасными дефолтами:
+
+| Env | Дефолт | Назначение |
+|---|---|---|
+| `ORCH_LESSONS_ENABLED` | `true` | kill-switch журнала (NFR-2); `false` → полная инертность |
+| `ORCH_LESSONS_DEDUP_WINDOW_S` | `3600` | окно дедупа автозаписи (ADR-001 D4) |
+| `ORCH_LESSONS_QUERY_LIMIT_DEFAULT` | `100` | дефолтный `limit` для `GET /lessons` |
+
+**`lessons_repos` СОЗНАТЕЛЬНО не вводится** — журнал observer-only и не скоупится по репо
+(ADR-001 D2). Секретов нет. `.env.example` дополнить тремя ключами для документируемости (значения —
+дефолтные, не секреты).
+
+## I-3. Деплой / рестарт
+- Изменение применяется штатным конвейером: **обязательный staging-гейт (8501) перед прод-деплоем**
+  орка (self-hosting инвариант). Прод-контейнер **не рестартить вне процедуры деплоя стадии**
+  `deploy`/`Confirm Deploy` (ORCH-059) — конвейер всех проектов встанет.
+- Таблица `lessons` создаётся идемпотентно при старте (`init_db()`) — на первом штатном запуске
+  нового образа, **без отдельной ручной миграции** (restart-safe, NFR-4). На живой БД enduro не
+  затронут.
+- Откат — `ORCH_LESSONS_ENABLED=false` (мгновенная инертность) либо revert образа.
+
+## I-4. CI/CD
+**Без изменений** в `.gitea/workflows/`. Новые тесты `tests/test_lessons.py` исполняются штатным
+шагом `pytest tests/ -q`. Новых системных/pip-зависимостей нет (raw SQL на stdlib `sqlite3`).