docs(ORCH-021): post-deploy HEALTHY/NONE for ORCH-112

Self-deploy git pull blocked on a dirty shared main checkout (manual/abandoned
WIP from a failed/cancelled task) — incident ORCH-111: "Your local changes to
src/config.py would be overwritten by merge" wedged the prod deploy and required
manual intervention (a group risk on self-hosting).

The deploy hook (--deploy) now converges the deploy-base to a clean, current
origin/main BEFORE the pull (git fetch + reset --hard origin/main + a SCOPED
`git clean -fd`, NEVER -x), strictly preserving the rollback/log artefacts
(.deploy-prev-image-* / deploy-hook.log via -e), gitignored .env/data/*.db/build
(no -x), and sibling/.git state (out of clean scope). Gated by CHECKOUT_HYGIENE
env injected by self_deploy.build_deploy_command only when the new pure never-raise
leaf src/checkout_hygiene.py says applies(repo) (kill-switch + self-hosting scope).
Convergence after failed/cancelled is this same deploy-time self-heal — cancel_task
is NOT extended and no background janitor is introduced. Observability: the hook
writes a `hygiene` sentinel, the Phase-C finalizer reads it and sends a best-effort
Telegram alert.

Additive, under kill-switch (ORCH_CHECKOUT_HYGIENE_ENABLED, default true; off ->
bare `git pull origin main` 1:1 before ORCH-112), never-raise, self-hosting scope.
STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict keys / DB schema / the
hook exit-code contract (0/1/2, ORCH-036) are byte-for-byte untouched.

Coverage: tests/test_deploy_checkout_hygiene.py (TC-01..TC-10; real-hook shell
simulation in a temp git repo, no network/prod/ssh, + unit). TC-01 is the
mandatory ORCH-111 regression (RED before the fix, GREEN after). Docs golden
source updated in the same PR (CLAUDE.md, CHANGELOG.md, .env.example; INFRA.md /
architecture/README.md / adr-0044 written at the architecture stage).

Refs: ORCH-112

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/
@@ -53,6 +107,30 @@ ORCH_AGENT_EFFORT_DEPLOYER=medium
 # (G4 NOT enabled, ADR-001 ORCH-74: determinism — all agents stay on opus-4-8). A
 # non-empty value is validated by the SAME predicate as the model; a typo is dropped.
 ORCH_AGENT_FALLBACK_MODEL=
+
+# ── Agent timeout / wall-clock budgets (ORCH-7, raised per-role ORCH-109) ─────
+# The in-process watchdog kills a run that exceeds its wall-clock budget
+# (SIGTERM -> grace -> SIGKILL, exit_code=-9). _resolve_timeout ladder (highest
+# first): OVERRIDES_JSON[agent] > dedicated role key > SECONDS (global default).
+#   SECONDS                -> global default budget for every role WITHOUT a raised
+#                             key (analyst/architect/tester/deployer).
+#   KILL_GRACE_SECONDS     -> pause between SIGTERM and SIGKILL so claude can flush
+#                             artifacts before the hard kill.
+#   OVERRIDES_JSON         -> optional per-agent override object, e.g.
+#                             {"reviewer":3600,"architect":2700}; wins for ANY role.
+#                             Malformed JSON -> ignored + WARNING (never-break).
+# ORCH-109: the two HEAVY roles get raised dedicated budgets (defaults = prod, so an
+# empty .env reproduces prod — ORCH-101 canon). A non-positive value falls back to
+# SECONDS + WARNING.
+#   DEVELOPER_S            -> developer budget (xhigh, coding/agentic bottleneck), 60m.
+#   REVIEWER_S             -> reviewer budget (large diff + high reasoning), 50m.
+# CROSS-INVARIANT (ORCH-065): ORCH_REAPER_MAX_RUNNING_S MUST stay > max(budget)+grace;
+# it is raised to 5400 in lockstep below (5400 > 3600 + 20 = 3620).
+ORCH_AGENT_TIMEOUT_SECONDS=1800
+ORCH_AGENT_KILL_GRACE_SECONDS=20
+ORCH_AGENT_TIMEOUT_OVERRIDES_JSON=
+ORCH_AGENT_TIMEOUT_DEVELOPER_S=3600
+ORCH_AGENT_TIMEOUT_REVIEWER_S=3000
 # ORCH-042/ORCH-067: live-tracker mode. bump (DEFAULT since ORCH-067) -> on every
 # update the old card is deleted and a fresh one is sent silently to the BOTTOM of
 # the chat (deleteMessage + sendMessage + repoint), so the current status is always
@@ -86,11 +164,32 @@ ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S=3
 #   DEFER_MAX_ATTEMPTS -> defer retries before escalation (avoids livelock).
 ORCH_MERGE_GATE_ENABLED=true
 ORCH_MERGE_GATE_REPOS=
-ORCH_MERGE_RETEST_TIMEOUT_S=600
+# ORCH-110 (D5): re-test budget raised 600 -> 900 (74% headroom over the observed
+# 516.7s suite). Cross-invariant (ORCH-065/109): keep ORCH_REAPER_MAX_RUNNING_S
+# (5400) > Σ(deploy-staging gate-work) + grace if you raise this — see
+# docs/work-items/ORCH-110/07-infra-requirements.md.
+ORCH_MERGE_RETEST_TIMEOUT_S=900
 ORCH_MERGE_RETEST_TARGET=tests/
 ORCH_MERGE_LOCK_TIMEOUT_S=300
 ORCH_MERGE_DEFER_DELAY_S=60
 ORCH_MERGE_DEFER_MAX_ATTEMPTS=5
+# ORCH-110: merge-gate re-test infra-timeout tolerance + tree-kill of the
+# orchestrator-spawned pytest subprocess (re-test + coverage). Each default = the
+# desired prod behaviour; each flag is an independent kill-switch (off ->
+# byte-for-byte pre-ORCH-110). The tree-kill grace reuses ORCH_AGENT_KILL_GRACE_SECONDS.
+#   SUBPROCESS_TREE_KILL_ENABLED          -> D1: spawn re-test/coverage pytest in its
+#       own process group; tree-kill the WHOLE group on timeout (no orphan grandchildren).
+#   MERGE_RETEST_INFRA_TOLERANCE_ENABLED  -> D3: a re-test TIMEOUT is a transient
+#       (bounded infra-retry, NOT a code-fault rollback to development).
+#   MERGE_RETEST_INFRA_MAX_RETRIES        -> D3: infra-retry budget before an infra-alert.
+#   MERGE_RETEST_INFRA_RETRY_DELAY_S      -> D3: delay before the staging-deployer re-run.
+#   MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED-> D4: skip the local re-test when the
+#       pre-merge rebase was a proven no-op (HEAD already CI/tester/staging-validated).
+ORCH_SUBPROCESS_TREE_KILL_ENABLED=true
+ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED=true
+ORCH_MERGE_RETEST_INFRA_MAX_RETRIES=2
+ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S=120
+ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED=true
 # ORCH-026 Level A: unconditional pre-merge rebase. With the flag ON (default),
 # check_branch_mergeable ALWAYS rebases the branch onto origin/main under the held
 # merge-lease (not only when behind) — a deterministic structural anti-phantom on
@@ -241,6 +340,15 @@ ORCH_DEPLOY_PROD_TARGET_IMAGE=orchestrator-orchestrator
 ORCH_DEPLOY_PROD_COMPOSE_PROFILE=
 ORCH_DEPLOY_PROD_PREV_IMAGE_FILE=.deploy-prev-image-prod
 
+# ORCH-112: deploy-base checkout-hygiene (resilient-pull). The self-deploy hook
+# converges a DIRTY shared deploy-base to a clean, current origin/main BEFORE the
+# `git pull` (git fetch + reset --hard + a SCOPED `git clean -fd`, NEVER `-x`), so
+# manual/abandoned WIP left by a failed/cancelled task never blocks the deploy
+# (incident ORCH-111). False -> bare `git pull origin main` 1:1 as before ORCH-112.
+# Empty REPOS -> only the self-hosting repo (orchestrator).
+ORCH_CHECKOUT_HYGIENE_ENABLED=true
+ORCH_CHECKOUT_HYGIENE_REPOS=
+
 # ORCH-058: staging-image provenance before the BUILD-ONCE prod retag (INV-FRESH).
 # Guarantees the staging image promoted to prod is the EXACT artefact rebuilt from the
 # validated commit — two layers, self-hosting only:
@@ -311,6 +419,8 @@ ORCH_PLANE_STATES_TTL_S=300
 #   REAPER_INTERVAL_S       -> background scan period (seconds).
 #   REAPER_DEAD_TICKS       -> consecutive dead-pid ticks before reaping (Tier-1, >=2).
 #   REAPER_MAX_RUNNING_S    -> Tier-3 backstop ceiling; must exceed max agent_timeout+grace.
+#                              ORCH-109: raised 3600 -> 5400 in lockstep with the developer
+#                              budget (5400 > 3600 + 20 = 3620).
 #   REAPER_FINALIZE_GRACE_S -> Tier-2 grace: how long agent_runs.exit_code must have been
 #                              recorded before a still-'running' job is reaped; MUST exceed
 #                              the max finalization window (git push + PR + Plane comments).
@@ -320,7 +430,7 @@ ORCH_PLANE_STATES_TTL_S=300
 ORCH_REAPER_ENABLED=true
 ORCH_REAPER_INTERVAL_S=60
 ORCH_REAPER_DEAD_TICKS=2
-ORCH_REAPER_MAX_RUNNING_S=3600
+ORCH_REAPER_MAX_RUNNING_S=5400
 ORCH_REAPER_FINALIZE_GRACE_S=300
 ORCH_LEASE_RECLAIM_ENABLED=true
 
@@ -489,6 +599,12 @@ ORCH_QG0_TITLE_MAX=200
 #   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).
+#   PROC_ENABLED   -> ORCH-111 opt-in: alert on a long-lived test process (pytest)
+#                     orphaned on the host (needs `pid: host`, default OFF).
+#   PROC_AGE_MIN   -> minutes a test process may live before alerting; MUST exceed
+#                     max(merge_retest_timeout_s, coverage_run_timeout_s)/60.
+#   PROC_PATTERNS  -> CSV of cmdline substrings that mark the test-class (pytest).
+#   PROC_COOLDOWN_S-> per-signal re-alert throttle for proc_blocking.
 #   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
@@ -508,5 +624,9 @@ WATCHDOG_QUEUE_DEPTH=20
 WATCHDOG_CONTAINERS=orchestrator
 WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
 WATCHDOG_DEPS=
+WATCHDOG_PROC_ENABLED=false
+WATCHDOG_PROC_AGE_MIN=60
+WATCHDOG_PROC_PATTERNS=pytest
+WATCHDOG_PROC_COOLDOWN_S=1800
 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,52 @@
+# .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=
+# proc_blocking (ORCH-111): opt-in алерт на долго живущий осиротевший тест-процесс
+# (pytest), репарентированный на хост. Требует `pid: host` на сервисе
+# orchestrator-watchdog (compose) — привилегия только у наблюдателя, read-only.
+# Дефолт-off → нулевая регрессия. PROC_AGE_MIN ОБЯЗАН превышать
+# max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)/60 = 15 мин, иначе
+# легитимный прогон даст ложный алерт. 60 мин = 4× запас.
+WATCHDOG_PROC_ENABLED=false
+WATCHDOG_PROC_AGE_MIN=60
+WATCHDOG_PROC_PATTERNS=pytest
+WATCHDOG_PROC_COOLDOWN_S=1800
+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/reviewer.md

@@ -57,7 +57,10 @@ tools:
      ограничения» (обзорная витрина проекта), README ДОЛЖЕН быть обновлён в том же PR — пункт снят
      или помечен закрытым с ORCH-ссылкой. Необновление обзорных доков → **finding ≥ P1**; если
      ограничение закрыто правкой `src/` без обновления README — это совпадает с P0 «`src/` изменён,
-     документация не обновлена». Это усиление трактовки оси, а не отдельная ось.
+     документация не обновлена». Это усиление трактовки оси, а не отдельная ось. Та же ось
+     покрывает **витрину системы** (ORCH-011): PR меняет функциональность, описанную в витрине
+     `docs/overview/` (стадии, гейты, агенты, интеграции, способности из `business.md`), а витрина
+     не обновлена → **finding ≥ P1** — расширение трактовки той же оси, не новая ось.
 </task>
 
 <deliverables>
@@ -77,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-009
+Work item: ORCH-112
 Repo: orchestrator
-Branch: feature/ORCH-009-turnkey-plane
+Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
 Stage: development

CHANGELOG.md

@@ -3,6 +3,57 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
+- **Гигиена shared deploy-базы: устойчивый self-deploy `git pull` к грязному дереву** (ORCH-112, `fix`, bug→escalate full-cycle): устранён инцидент ORCH-111 — self-deploy падал на шаге `git pull origin main` хост-хука с `error: Your local changes to the following files would be overwritten by merge: src/config.py` (грязь от неуспешной/отменённой/брошенной задачи ORCH-104 в общем main checkout) → деплой вставал → ручное вмешательство (на self-hosting — групповой риск). Решение — **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`): перед `git pull` хук при обнаружении грязи приводит deploy-базу к чистому актуальному `origin/main` (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Аддитивно, под kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты** (это устойчивость deploy-пути, **не** Quality Gate и **не** стадия). ADR: `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
+  - **Leaf `src/checkout_hygiene.py` (новый, чистый never-raise):** по образцу `serial_gate`/`cancel`/`self_deploy` (импортирует только `config`, лениво `self_deploy`/`qg.checks`/`notifications`) — `applies(repo)` (kill-switch `checkout_hygiene_enabled` + скоуп `checkout_hygiene_repos`, пусто → self-hosting only, локально и ПЕРВЫМ), `hook_env(repo, work_item_id)` (env-префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`, инжектится в detached-команду хука только при `applies==True`, иначе `""` → голый pull 1:1), `read_report`/`alert_dirty` (наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
+  - **Хук-блок «2a. Resilient pull» (`scripts/orchestrator-deploy-hook.sh`):** между шагом «1. Capture PREV_IMG» и «2. Pull», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`. **Сохранность (NFR-2, жёсткий контракт):** `git clean` — **только `-fd`, НИКОГДА `-x`** (иначе удалил бы gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломался бы rollback `do_rollback`); sibling `<repos_dir>/.deploy-state-*`/`.merge-lease-*.json` (под родителем `$REPO`) и `.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`. Каждый git-шаг — `|| log "...continuing"` (never-break): сбой гигиены не ухудшает исход относительно текущего голого pull; на чистой базе блок — no-op (happy-path и exit-коды байт-в-байт). `--build-staging` (build из worktree, без pull) не затронут.
+  - **Сходимость после failed/cancelled (FR-2)** — этим же deploy-time self-heal (база сходится на следующем же self-deploy); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**. **Наблюдаемость (FR-4)** — хук пишет sentinel `hygiene` в deploy-state каталог; Phase-C finalizer (`stage_engine.run_deploy_finalizer`) читает (`read_report`) и шлёт Telegram-алерт (`alert_dirty`, кликабельный номер, best-effort, never-raise — сбой алерта не валит деплой).
+  - **Флаги** (`config.py`, дефолт = боевое): `checkout_hygiene_enabled` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`), `checkout_hygiene_repos` (env `ORCH_CHECKOUT_HYGIENE_REPOS`). Откат = `ORCH_CHECKOUT_HYGIENE_ENABLED=false` → деплой байт-в-байт до ORCH-112. Покрытие — `tests/test_deploy_checkout_hygiene.py` (TC-01…TC-10: шелл-симуляция реального хука во временном git-репо без сети/прода/ssh + unit; TC-01 — обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
+- **Job-reaper не реапит живой долго финализирующий монитор `deploy-staging`** (ORCH-113, `fix`, bug→escalate full-cycle): устранено расхождение состояния из инцидента ORCH-111 (deployer job 1914 / run_id 683). На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит `agent_runs.finished_at`/`exit_code` **первым**, затем синхронно в своём потоке прогоняет тяжёлые edge-под-гейты (`security → merge-gate re-test → coverage → image-freshness`) — **минуты** — и лишь потом `_finalize_job`. Reaper Tier-2 меряет `finished_age_s` от `finished_at` (= начала финализации), поэтому по истечении `reaper_finalize_grace_s=300` трактовал живого долго финализирующего монитора как мёртвого и **независимо** повторял тот же тяжёлый advance: повторный re-test стал красным → ложный откат `deploy-staging → development` (+ ложный developer-retry) **параллельно** с тем, что исходный finalizer довёл deploy до SUCCESS и смержил PR — состояние раздвоилось. Аддитивно, под глобальным kill-switch, never-raise; `STAGE_TRANSITIONS`/`QG_CHECKS`/каждый `check_*`/machine-verdict ключи/схема БД — **байт-в-байт не тронуты**; `reaper_finalize_grace_s`/`reaper_max_running_s` и сквозной бюджет ORCH-065/109/110 (`5400 > Σ(gate-work)+grace`) сохранены; фикс не рестартит прод и не пушит `main`. ADR: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`, сквозной `docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`.
+  - **Leaf `src/finalizer_liveness.py` (новый, процесс-локальный реестр владения):** чистый never-raise модуль (паттерн `serial_gate`/`coverage_gate`, без сети/БД) — `mark(job_id, run_id, stage)` / `clear(job_id)` / `is_active(job_id)` / `snapshot()`; состояние `{job_id: {...}}` под `threading.Lock`. Авторитетно in-memory, т.к. монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без `--workers`) с общей SQLite-БД. Собственного TTL нет — ограничение по времени даёт Tier-3 backstop. `is_active` при ошибке → `False` (консервативно: не блокировать добивание).
+  - **Эмиссия владения (`launcher._monitor_agent`):** `mark()` вызывается **сразу после** штампа `exit_code` (самый ранний момент Tier-2), хвост финализации вынесен в `_run_monitor_finalization` и обёрнут в `try/finally` с `clear()` в `finally` → исключение в потоке монитора гарантированно снимает владение, и реально мёртвый finalizer добивается. Маркер пишется **безусловно** (kill-switch гейтит только консультацию reaper, поэтому выключенный путь — байт-в-байт прежний). Хвост перенесён **дословно** (проверяется `git diff -w`: +49/−0, нулевое изменение логики).
+  - **Консультация reaper (`job_reaper._reap_job` Tier-2):** при `reaper_finalizer_liveness_enabled` **И** стадии задачи `== "deploy-staging"` **И** активном владении → **defer** (счётчик + лог, не повторять advance), провал к Tier-3. **Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — застрявший/мёртвый finalizer добивается в ограниченное время. Скоуп — только глобальный kill-switch `reaper_finalizer_liveness_enabled` (env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`; `False` → reaper байт-в-байт прежний), **без** per-repo разреза (баг общий для всех репо со стадией `deploy-staging`).
+  - **Наблюдаемость:** аддитивные ключи `finalizer_liveness_enabled`/`finalizer_defers_total`/`finalizer_owned` в блоке `reaper` ответа `GET /queue` (существующие ключи не тронуты). Покрытие — `tests/test_orch113_reaper_finalizer_liveness.py` (TC-01…TC-08, включая обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
+- **Merge-gate re-test: толерантность к инфра-таймауту + tree-kill спавненных pytest + контракт необходимости re-test** (ORCH-110, `fix`, bug→escalate full-cycle): устранён ложный откат `deploy-staging → development`, возникавший когда локальный re-test merge-gate падал по **таймауту** (инфра/ресурс) при зелёных CI + tester + staging (инцидент ORCH-109/PR #129: сюит 516.7s упёрся в бюджет 600s под CPU-голоданием от осиротевших pytest-процессов → `(False, "re-test timeout after 600s")` → `_handle_merge_gate_rollback` → каждый из 3 developer-retry падал так же → «Merge-gate still failing after 3 developer retries» → ручное вмешательство). Аддитивно, под 5 независимыми kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты**; INV-4 (никогда push/force-push `main`) и запрет рестарта прод-контейнера — соблюдены. ADR: `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`, сквозной `docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`.
+  - **D1 — process-group tree-kill (`src/proc_group.py`, новый stdlib-only leaf):** `merge_gate.retest_branch` и `coverage_gate.measure_coverage` теперь спавнят pytest в **отдельной группе процессов** (`start_new_session`) и при таймауте убивают **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL по образцу `launcher.stop_process`), а не только прямого потомка — осиротевшие внуки-pytest больше не переживают бюджет и не грузят CPU. Контракты возврата сохранены (меняется лишь побочный эффект — нет утечки). Грейс реюзит `agent_kill_grace_seconds`. Fallback never-break: `subprocess_tree_kill_enabled=False` или не-POSIX → прежний `subprocess.run(timeout=)`.
+  - **D2/D3 — классификация + маршрутизация инфра-таймаута:** чистый предикат `merge_gate.classify_retest_failure(reason)` различает `timeout`/`red`/`lock-busy`/`other` (scope-guard: `auto_rebase_onto_main`'s «rebase timeout» — НЕ инфра-таймаут re-test, остаётся на rollback-пути). Инфра-таймаут → новый `_handle_merge_gate_infra_retry` (ограниченный повтор по образцу `_handle_merge_gate_defer`: задача **остаётся на deploy-staging**, staging-deployer перезапускается с задержкой, **БЕЗ** отката на `development` и **БЕЗ** расхода developer-retry). Анти-над-толерантность (BR-6): детерминированно **красный** re-test / конфликт по-прежнему → `_handle_merge_gate_rollback`. Anti-loop: исчерпание бюджета → один **инфра-alert** (явно инфраструктурная формулировка «НЕ дефект кода» с кликабельным номером), задача НЕ уходит в `development`.
+  - **D4 — контракт необходимости re-test:** при `premerge_rebase_always=True` re-test теперь **пропускается**, когда rebase оказался доказанным no-op (HEAD не сдвинулся = ветка уже содержит свежий `origin/main`, тот же коммит уже подтвердили CI + tester + staging) — distribute той же оптимизации, что путь `premerge_rebase_always=False` уже имеет для не-behind ветки. Fail-safe: при любой неопределённости (`head_sha` пуст / git-ошибка) re-test **выполняется** (BR-6/AC-3 не ослаблен).
+  - **D5 — бюджет:** `merge_retest_timeout_s` 600 → **900** (запас 74% над 516.7s) + валидация `_resolve_retest_timeout` (малформ/непозитив → дефолт 900 + WARNING). Сквозной инвариант ORCH-065/109 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work)+grace (≈4460)` соблюдён **без** правки `reaper_max_running_s`.
+  - **D6 — наблюдаемость:** in-process счётчики (`retest_timeout_total`/`retest_infra_retry_total`/`retest_infra_exhausted_total`/`retest_skipped_current_total`/`last_infra_timeout_wi`) + read-only блок `merge_gate` в `GET /queue` (отличим от код-фейл-отката); координация с ORCH-111 (`proc_blocking`) без дубля (ORCH-110 предотвращает/толерирует, ORCH-111 наблюдает). Append-only regression-guard: добавлен `("ORCH-110", "classify_retest_failure", "src/merge_gate.py")` в `MAIN_REGRESSION_MARKERS`.
+  - **Конфиг (5 новых ключей, дефолт = боевое):** `ORCH_SUBPROCESS_TREE_KILL_ENABLED`/`ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED`/`ORCH_MERGE_RETEST_INFRA_MAX_RETRIES=2`/`ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S=120`/`ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED` + бамп `ORCH_MERGE_RETEST_TIMEOUT_S=900`. Покрытие — `tests/test_orch110_*.py` (TC-01…TC-12, включая регресс инцидента red-before/green-after).
+- **Watchdog-сигнал `proc_blocking`: алерт на долго живущий осиротевший тест-процесс** (ORCH-111, `feat`): закрыта слепая зона наблюдаемости между `agent_hung` (видит только треканые джобы по `jobs.pid`) и осиротевшими субпроцессами `pytest`, которые орк запускает сам (`merge_gate.retest_branch`/`coverage_gate.measure_coverage`) и которые при timeout-kill агента (`-9`, ORCH-109) репарентируются на tini и живут сутками, грузя CPU и валя merge-gate re-test (инцидент: процессы `test_install_lite_script.py` жили >2 суток без единого алерта). Изменения **строго внутри наблюдателя** (`watchdog/**` + сервис watchdog в compose); `src/**`/`/metrics`/`schema_version`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — **байт-в-байт не тронуты**; выкат пересобирает **только** `orchestrator-watchdog`, прод `orchestrator` не рестартится (NFR-3). ADR: `docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md`, сквозной `docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md`.
+  - **Коллектор `watchdog/collectors/proc.py` (D3):** новый stdlib-only `/proc`-скан (под `pid: host` контейнерный `/proc` отражает хост-namespace) — читает `/proc/stat` (`btime`) + `os.sysconf("SC_CLK_TCK")`, итерирует числовые `/proc/<pid>`, матчит `/proc/<pid>/cmdline` по паттерну тест-класса, парсит `/proc/<pid>/stat` (поле 22 `starttime` → `age_s`, поля 14+15 `utime+stime` → `cpu_s` информационно). Строго **read-only** (никаких `os.kill`/сигналов/`subprocess`; **никогда** не читает `/proc/<pid>/environ` — секреты); **never-raise** (per-pid гонка «процесс умер между listdir и read» пропускается, top-level → `[]`); чистый разбор отделён от I/O (тестируется на фейковом `/proc`-дереве).
+  - **Чистый builder `proc_signals` + синтез RECOVERY (D4):** per-entity `Signal("proc_blocking", pid)` active ⇔ `age_s > cfg.proc_age_s` (cmdline уже отфильтрована коллектором); действенный RU-`detail` (PID + возраст + усечённый фрагмент cmdline + CPU-время). Исчезновение процесса не оставляет «висящего» алерта: в `core.tick()` для каждого alerting-ключа без свежего сигнала **синтезируется** `Signal(active=False)` → существующая `decision.decide()`/`AlertState` даёт **однократный** RECOVERY и чистит состояние (никакой новой анти-спам-логики — FR-5).
+  - **Анти-false-positive и отсутствие дубля с `agent_hung` — по построению (D2):** cmdline-скоуп (`claude`-агент ≠ `pytest` → нулевое пересечение, NFR-4/AC-5) + дефолтный порог возраста (60 мин) **превышает** макс. легитимный бюджет тест-прогона `max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)` → in-flight прогон физически не перерастает порог (BR-4/AC-4). Без хрупкого кросс-namespace матчинга PID.
+  - **Конфиг + kill-switch (D5):** ключи `WATCHDOG_PROC_ENABLED` (дефолт **false** — opt-in) / `WATCHDOG_PROC_AGE_MIN` (60) / `WATCHDOG_PROC_PATTERNS` (`pytest`) / `WATCHDOG_PROC_COOLDOWN_S` (1800), never-raise парсеры. При выключенном флаге коллектор в `tick()` **не вызывается** → нулевой оверхед и байт-в-байт прежний тик (AC-7). Топология (D6): аддитивный `pid: host` **только** на сервисе `orchestrator-watchdog` (привилегия read-only, меньше уже-смонтированного `docker.sock`; не volume → инвариант read-only-маунтов цел).
+  - **Канон тиража (NFR-5):** новые `WATCHDOG_PROC_*` синхронизированы в `.env.watchdog.example` ↔ блок `WATCHDOG_*` `.env.example` (key-sync тест зелёный), описаны в `docs/deployment/LITE_SETUP.md` §4 и `docs/architecture/README.md` (§ proc_blocking). Покрытие — `tests/watchdog/test_proc_blocking_signal.py` (TC-01…TC-06), `test_proc_collector.py` (парсинг `/proc`), `test_tick_proc_blocking_integration.py` (TC-07 tick→dispatch + flag-off), позитивный `pid: host` в `test_compose_service.py`, proc-конфиг в `test_config_killswitch.py`. Полный `pytest tests/` зелёный (1930).
+- **Timeout-бюджеты developer/reviewer + launch-стамп модели в телеметрии** (ORCH-109, `fix`): две аддитивные изолированные правки подсистемы запуска агентов (инцидент ORCH-104, runs 658/659/660), **без** касания `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы БД. ADR: `docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md`, сквозной `docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`.
+  - **Launch-стамп модели (D1, FR-1):** резолвенная `resolve_agent_model(...)` пишется в `agent_runs.model` в **момент launch** объединённым `UPDATE agent_runs SET model=?, effort=? WHERE id=?` рядом со стампом эффорта (ORCH-087) в `launcher._spawn`. Раньше модель писалась только постфактум из финального usage-JSON (`record_usage`, `model=COALESCE(?, model)`), а убитый по тайм-ауту прогон этот JSON не эмитит → модель оставалась `NULL` ровно тогда, когда нужна для разбора инцидента. Теперь модель присутствует с launch, **переживает timeout-kill (`exit_code=-9`)**, видна in-flight в `GET /metrics`/`GET /queue` (`get_running_agents` уже отдаёт `model`) и в строке Telegram-карточки. Пустой резолв (CLI-дефолт без `--model`) → `NULL` (симметрично `effort or None`). Постфактум `record_usage` остаётся **обогащением** (COALESCE сохраняет launch-стамп при `model=None`). never-raise: сбой стампа изолирован `try/except` + WARNING, launch продолжается.
+  - **Поднятые per-role wall-clock бюджеты (D3/D4, FR-3):** выделенные типизированные ключи `agent_timeout_developer_s=3600` (60м) / `agent_timeout_reviewer_s=3000` (50м) (env `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S`). `_resolve_timeout(agent)` получил детерминированную лестницу: `agent_timeout_overrides_json[agent]` (операторский escape-hatch, высший приоритет, BC) → выделенный ключ роли → `agent_timeout_seconds=1800` (прочие роли — байт-в-байт). Малформный JSON / непозитивный/нечисловой выделенный ключ → откат на глобальный дефолт + WARNING (never-break). Дефолты = боевым значениям (канон ORCH-101): пустой `.env` воспроизводит поднятые бюджеты. **Кросс-инвариант reaper ORCH-065** сохранён синхронным поднятием `reaper_max_running_s` 3600 → **5400** (`5400 > max(timeout)3600 + grace20 = 3620`).
+  - **FR-4/NFR-6 (видимость при kill / in-flight) и FR-5 (анти-salvage) — структурно уже выполнены** существующим кодом (продвижение гейтится `if exit_code == 0`, timeout-kill → `_finalize_job` retry/fail, не advance); ORCH-109 фиксирует их **регресс-тестами**, новых ветвей не вводит. Покрытие — новый `tests/test_orch109_timeout_model.py` (TC-01…TC-12, детерминированный, без сети/CLI). Обновлены `tests/test_config.py` (reaper-дефолт 5400) и `tests/test_launcher.py` (ладдер `_resolve_timeout`). Документация — `.env.example` (блок agent-timeout + reaper), `config.py`-паспорт, `docs/architecture/README.md`/`internals.md` + front-page `README.md` (раздел «Watchdog») (per-role бюджеты).
+- **Презентация: слайды Lite-установки и использования через Plane** (ORCH-105, `docs`): слайдо-источник `docs/overview/presentation.md` расширен тремя слайдами в каноне ORCH-011 (16 → 19, сквозная нумерация сохранена): один слайд про **Lite-установку скриптами** (два контейнера платформы — оркестратор + сторож на инфре заказчика; развёртывание без правки кода, только конфиг; помощники `gen_secrets.py`/`onboard_project.py` + `docker compose up -d`; runbook `LITE_SETUP.md` с проверкой каждого шага; одношаговый bootstrap — это смежный Bundled, не Lite) и два слайда оператор-инструкции **«как пользоваться орком через Plane»** (запуск через статус «To Analyse»; статусы Plane — индикация, не управление; оба человеческих гейта «Approved»/«Confirm Deploy»; авто-лейблы `autoApprove`/`autoDeploy`/`Bug` — снимают только человеческие решения, ни одна техническая проверка не пропускается; отмена через «STOP»; наблюдение — статусы доски + живая Telegram-карточка + комментарии со ссылками на ветку/PR). Факты сверены с golden sources (`docs/deployment/LITE_SETUP.md`, `docs/overview/tech-pipeline.md`, `tech-integrations.md`, `CLAUDE.md`). **Docs+tests only:** `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД — байт-в-байт; новый QG не вводится; `python-pptx` не добавлен в прод-образ; собранный `.pptx` в git не коммитится. Анти-дрейф — новая функция `test_presentation_covers_lite_and_plane_usage_bits` в `tests/test_system_docs.py` (существующие проверки без послаблений). ADR: `docs/work-items/ORCH-105/06-adr/ADR-001-presentation-lite-and-plane-usage-slides.md` (канон витрины не меняется — `adr-0039-system-overview-docs-canon.md`).
+- **Витрина системы `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.

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 агентов на каждой стадии.
 
@@ -70,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-слой
@@ -144,6 +149,17 @@ uvicorn src.main:app --reload --port 8500
 | `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)
 
@@ -276,7 +292,7 @@ Task-файлы `.task-*.md` пишутся **прямой записью в с
 stdout/stderr агента перенаправляются СРАЗУ в `/app/data/runs/{id}.log` на уровне ОС (без PIPE). monitor-поток делает `proc.wait()` → реальный exit_code, нет зомби.
 
 ### Watchdog
-Каждый агент имеет timeout 30 минут. При превышении — SIGKILL + запись exit_code=-9.
+Каждый агент имеет per-role wall-clock бюджет (ORCH-109): developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт (`_resolve_timeout`). При превышении — SIGTERM→grace→SIGKILL + запись exit_code=-9. Tier-3 backstop `reaper_max_running_s`=90 мин > max(timeout)+grace (ORCH-065).
 
 ### Event routing
 Gitea events роутятся по типу:

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,65 @@
+# 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
@@ -56,11 +79,17 @@ services:
     restart: unless-stopped
     init: true
     network_mode: host
+    # ORCH-111 (adr-0041 D6): share the host PID-namespace so the sidecar's /proc
+    # reflects the host and the proc_blocking collector can see orphaned pytest
+    # subprocesses. Privilege is read-only and ONLY on the observer; the signal
+    # is default-off (WATCHDOG_PROC_ENABLED=false) -> no behaviour change unless
+    # opted in. NOT a volume, so the host-paths-read-only compose test is unaffected.
+    pid: host
     mem_limit: 128m
     mem_reservation: 32m
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro
-      - /home/slin/repos:/repos: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
@@ -69,7 +98,7 @@ services:
       - path: .env.watchdog
         required: false
     group_add:
-      - "999"
+      - "${ORCH_DOCKER_GID:-999}"
 
   # ORCH-31: staging instance (port 8501, isolated DB).
   # Starts ONLY with: docker compose --profile staging up -d orchestrator-staging
@@ -77,35 +106,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/README.md

@@ -9,9 +9,9 @@
 - **Stage Engine** (`src/stage_engine.py`) — исполнение переходов, диспетчеризация QG (`_run_qg`), откаты, синхронизация с Plane.
 - **Review/Test Parsers** (`src/review_parse.py`, ORCH-046) — defensive-извлечение дословного must-fix текста из артефактов для встраивания в `task_desc` заворота: `extract_review_findings` (P0/P1 из `12-review.md`), `extract_test_failures` (фрагмент тела `13-test-report.md`). Контракт «never raise»: любая ошибка → `""`.
 - **Quality Gates** (`src/qg/checks.py`) — проверки выхода со стадии, реестр `QG_CHECKS`.
-- **Agent Launcher** (`src/agents/launcher.py`) — запуск Claude CLI агентов в изолированном git worktree, мониторинг, auto-advance. Модель/эффорт каждого агента резолвятся из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41), а не из frontmatter промпта. **ORCH-74:** имя модели валидируется форматом `^claude-…$` (`is_valid_model`) перед `--model`; невалидное → лог + откат на следующий уровень/CLI-дефолт (never-break, как `VALID_EFFORTS` для эффорта). Тот же предикат гардит inline-чтение `--fallback-model`.
+- **Agent Launcher** (`src/agents/launcher.py`) — запуск Claude CLI агентов в изолированном git worktree, мониторинг, auto-advance. Модель/эффорт каждого агента резолвятся из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41), а не из frontmatter промпта. **ORCH-74:** имя модели валидируется форматом `^claude-…$` (`is_valid_model`) перед `--model`; невалидное → лог + откат на следующий уровень/CLI-дефолт (never-break, как `VALID_EFFORTS` для эффорта). Тот же предикат гардит inline-чтение `--fallback-model`. **ORCH-109 ([adr-0040](adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md)):** (1) резолвенная **модель стампится в `agent_runs.model` в момент launch** (`_spawn`, объединённый `UPDATE … SET model=?, effort=?` рядом со стампом эффорта ORCH-087; пустой резолв → `NULL`; never-raise) → модель видна не-`null` при любом исходе прогона, включая timeout-kill (`exit_code=-9`), и in-flight в `GET /metrics`/`GET /queue` (`get_running_agents` уже отдаёт `model`); постфактум `record_usage` (`model=COALESCE(?, model)`) остаётся **обогащением**, не единственным источником истины. (2) **Per-role wall-clock бюджеты** через выделенные ключи `agent_timeout_developer_s=3600`/`agent_timeout_reviewer_s=3000` (лестница `_resolve_timeout`: `agent_timeout_overrides_json` → выделенный ключ роли → `agent_timeout_seconds=1800`; прочие роли — байт-в-байт; малформный/вне-диапазонный конфиг → дефолт + WARNING). Инвариант reaper ORCH-065 сохранён синхронным поднятием `reaper_max_running_s` 3600→**5400** (`5400 > max(timeout)3600 + grace20`). FR-5 анти-salvage — структурно: продвижение гейтится `if exit_code==0`, timeout-kill → `_finalize_job` (retry/fail), не advance. `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты.
 - **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe. **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота; декларации/циклы — leaf `src/task_deps.py`.
-- **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max`→`queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`).
+- **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max`→`queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`). **ORCH-113 ([adr-0043](adr/adr-0043-reaper-finalizer-liveness-ownership.md)):** на ребре `deploy-staging → deploy` тяжёлые edge-под-гейты (security/merge-gate re-test/coverage/image-freshness) исполняются в потоке монитора **после** штампа `finished_at` и **до** `_finalize_job` — минуты, а Tier-2 `finished_age_s` меряется от `finished_at`, поэтому живой долго финализирующий монитор ошибочно реапился (инцидент ORCH-111: повторный re-test → ложный откат `deploy-staging → development` параллельно успешному deploy). Фикс — процесс-локальный реестр владения финализацией (leaf `src/finalizer_liveness.py`, never-raise): монитор `mark()`/`clear()` (try/finally), reaper в Tier-2 при `stage=="deploy-staging"` И активном владении делает **defer** (не повторяет advance); Tier-3 backstop маркер игнорирует (мёртвый/застрявший finalizer добивается в ограниченное время). In-memory restart-safe через `requeue_running_jobs` (вызов до старта reaper); схема БД, `reaper_finalize_grace_s`/`reaper_max_running_s` и сквозной бюджет не тронуты. Kill-switch `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`.
 - **Reconciler** (`src/reconciler.py`, ORCH-053 — реализовано, [adr-0007](adr/adr-0007-reconciler.md)) — фоновый daemon-поток (паттерн `queue_worker`), стартует/останавливается в `main.lifespan` (после `worker.start()` / перед `worker.stop()`). Реконсилирует рассинхрон «источник истины ≠ стадия задачи» при потерянном webhook. F-1 gate-side (продвигает застрявшую стадию по локальной БД через штатный `advance_stage(..., finished_agent=None)`), F-2 plane-side (опрос Plane API → `handle_*` из `plane.py`), F-3 (БД-fallback `sha→branch` в `handle_ci_status`). Источник истины — гейт/Plane, не событие; идемпотентность (active-job guard + atomic-claim + grace); kill-switch `ORCH_RECONCILE_ENABLED`. `analysis` F-1 не трогает (человеческий гейт). F-1 также пропускает escalated (retry≥лимита) и Blocked/Needs-Input задачи (ORCH-060). Наблюдаемость — блок `reconcile` в `GET /queue`.
 - **Disk-watchdog** (`src/disk_watchdog.py`, ORCH-063 — [adr-0024](adr/adr-0024-disk-watchdog.md)) — фоновый daemon-поток (каркас `reconciler`/`job_reaper`), стартует/останавливается в `main.lifespan` (старт последним — после `reaper.start()`; стоп первым в reverse-порядке; гард `disk_monitor_enabled`). Каждые `disk_monitor_interval_s` (дефолт 300с) меряет заполнение **хост-ФС** по смонтированным bind-путям (`/repos`, `/app/data`) через stdlib `shutil.disk_usage` (не overlay `/` контейнера, не субпроцесс `df`; дедуп путей по `st_dev`). Решение об алерте — pure-функция `decide_action(used_pct, threshold, prev_state, now, realert_s)`: алерт на пересечении порога (дефолт **85%**), cooldown-повтор `disk_monitor_realert_s` (анти-спам, не на каждом тике), однократный recovery при возврате ниже порога. Алерт — `send_telegram` (notifying, best-effort). Состояние анти-спама — in-memory (без миграции БД). never-raise (per-path/per-tick/per-send); только читает и уведомляет — не трогает диск/контейнер, не рестартит прод (self-hosting безопасность). Kill-switch `ORCH_DISK_MONITOR_ENABLED`; снимок — блок `disk_monitor` в `GET /queue` (`enabled`/`threshold_pct`/`interval_s`/`realert_s`/`paths`[`used_pct`/`free_gb`/`alerting`/`last_alert_at`]). `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты. Детали — `docs/work-items/ORCH-063/06-adr/ADR-001-disk-watchdog.md`.
 - **Build-cache-pruner** (`src/build_cache_pruner.py`, ORCH-062 — [adr-0025](adr/adr-0025-build-cache-pruner.md)) — фоновый daemon-поток (каркас `disk_watchdog`), стартует/останавливается в `main.lifespan` (старт последним — после `disk_watchdog.start()`; стоп первым в reverse; гард `build_cache_prune_enabled`). «Вторая половина» disk-watchdog: **watchdog сигналит — pruner убирает**. Каждые `build_cache_prune_interval_s` (дефолт 21600с = 6ч) выполняет **строго `docker builder prune -f --filter until=<until>`** (BuildKit GC; дефолт `until=24h` — удаляет build cache старше суток, тёплый кэш сохраняет; `-a` опционально, только в паре с фильтром). Затрагивает **только** build cache — НЕ образы/контейнеры; рестарт docker daemon/прода не выполняется (self-hosting безопасность). В контейнере нет `docker` CLI (`Dockerfile:11`), поэтому уборка идёт **на хосте через ssh** каналом `deploy_ssh_user@deploy_ssh_host` (как `image_freshness`/`self_deploy`); пустой `deploy_ssh_host` → тик no-op (скоуп на self-host). never-raise (per-команда/per-tick); учёт результата in-memory (без миграции БД). Kill-switch `ORCH_BUILD_CACHE_PRUNE_ENABLED`; снимок — блок `build_cache_prune` в `GET /queue` (`enabled`/`interval_s`/`until`/`last_run_ts`/`last_reclaimed`/`last_error`). `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты. Детали — `docs/work-items/ORCH-062/06-adr/ADR-001-build-cache-pruner.md`.
@@ -108,6 +108,24 @@ F1b (рамка C-1: наблюдатель отделён от наблюдае
   `disk_watchdog` (ORCH-063, канал орка) ⇒ **нулевой дубль по построению**; sidecar покрывает провал
   «орк+disk_watchdog мертвы» через `orch_down`, плюс **opt-in** независимый критический потолок
   `host_disk_crit` (97%, `WATCHDOG_DISK_CRIT_ENABLED=false` по умолчанию) — другое событие/канал.
+- **`proc_blocking` — алерт на долго живущий осиротевший тест-процесс (ORCH-111, opt-in,
+  [adr-0041](adr/adr-0041-watchdog-orphan-test-process-alert.md)):** закрывает слепую зону между
+  `agent_hung` (видит только треканые джобы по `jobs.pid`) и осиротевшими субпроцессами pytest,
+  которые орк запускает сам (`merge_gate.retest_branch`/`coverage_gate.measure_coverage`) и которые
+  при timeout-kill агента (`-9`, ORCH-109) репарентируются на tini и живут сутками, грузя CPU и валя
+  merge-gate re-test. Sidecar **сам** сканирует `/proc` хоста (новый коллектор
+  `watchdog/collectors/proc.py`, stdlib-only, read-only, never-raise→`[]`); per-entity сигнал
+  `("proc_blocking", pid)` active ⇔ возраст > порога **И** cmdline матчит тест-класс (дефолт `pytest`).
+  Анти-false-positive и отсутствие дубля с `agent_hung` — **по построению**: cmdline-скоуп
+  (`claude`-агент ≠ `pytest`) + порог возраста > макс. бюджета тест-прогона
+  (`max(merge_retest_timeout_s, coverage_run_timeout_s)`), а не хрупким кросс-namespace матчингом PID.
+  Алерт/recovery — через ту же `decide()`/`AlertState` (RECOVERY синтезируется для исчезнувшего
+  процесса). Watchdog процесс **не трогает** (только наблюдение, C-1/BR-3). **Топология:** сервису
+  `orchestrator-watchdog` добавлен `pid: host` (видимость хост-namespace; привилегия только у
+  наблюдателя, read-only, меньше уже-смонтированного `docker.sock`). Ключи `WATCHDOG_PROC_*`
+  (`ENABLED` дефолт **false** / `AGE_MIN`=60 / `PATTERNS`=`pytest` / `COOLDOWN_S`); дефолт-off →
+  нулевая регрессия. Деплой пересобирает **только** sidecar — прод `orchestrator` не рестартится.
+  Детали — `docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md`.
 - **Гарантии:** never-raise (per-source/per-tick/per-send); kill-switch `WATCHDOG_ENABLED=false` →
   демон инертен (idle-loop, нулевой эффект на орк); строго read-only к наблюдаемому (нет
   start/stop/restart/exec/записи в `docker.sock`/БД/`main`) ⇒ self-hosting-безопасно (enduro не
@@ -158,6 +176,114 @@ orchestrator (каноны ORCH-52b/c/d/e); enduro-trails эталоном не
 `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md` (D1…D11),
 `docs/work-items/ORCH-009/07-infra-requirements.md`.
 
+## Тираж платформы: фундамент 10-common (ORCH-101)
+
+Фундамент эпика ORCH-10 (D5.3 «Масштаб»: раздача платформы заказчикам-тестерам, типы A Lite /
+B Bundled, оба stateless). Платформа разворачивается на новой инфре **без правки кода** — только
+env/конфиг; конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) —
+байт-в-байт не тронут. Три слоя:
+
+- **Расхардкод по принципу «дефолт = боевое значение»** (kill-switch-природа: отсутствие новых
+  переменных = текущее поведение 1:1). Новые ключи: `ORCH_AGENT_HOME_DIR` (HOME акторских
+  процессов: launcher ×2 / self-deploy / post-deploy), `ORCH_AGENT_GIT_NAME` +
+  `ORCH_GIT_EMAIL_DOMAIN` (git-идентичности `<actor>@<domain>`; системные имена
+  `deploy-finalizer`/`post-deploy-monitor` — платформенные литералы), `ORCH_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»
+  `group_add` сохранена); `Dockerfile` — `ARG APP_*` (CMD не трогается: exec-form + `init: true`);
+  deploy-hook — `"${REPO:-…}"` + явная передача `REPO=` инвокерами. **Платформенные константы
+  (нормативно, НЕ конфиг):** `SELF_HOSTING_REPO="orchestrator"` (узел «empty CSV → self-hosting
+  only» всех `*_repos`-leaf'ов), имена сервисов/образов/профиля, контейнерный layout.
+  **Инвариант ORCH-058 усилен:** staging-порт конфигурируем только с fail-closed guard'ом
+  (`staging_port == прод-порт` → отказ freshness-пути ДО любого ssh/build, без тихого fallback).
+- **Секреты нового хоста:** stdlib `scripts/gen_secrets.py` (криптослучайные webhook-секреты
+  `secrets.token_hex(32)`; печать по умолчанию; `--write` отказывает при существующем `.env`,
+  перезапись — только явный `--force`) + чек-лист внешних токенов. Норматив: боевые секреты
+  текущего хоста не копируются ни на одном шаге.
+- **Smoke-верификация тиража:** runbook `docs/operations/REPLICATION.md` (deployment golden
+  source: карта env, чек-лист секретов, пошаговый smoke с PASS/FAIL — `/health` → `/queue`+
+  `/metrics` → `onboard_project.py plan/apply/verify` → тестовая задача → артефакты `01–04`;
+  расширенно — до `done`); без нового скрипта — кирпичи уже в репо. Анти-регресс — структурный
+  сканер `tests/test_no_host_hardcodes.py` (запрещённые литералы в исполняемом коде
+  `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов; config-модули — канон
+  дефолтов, вне скана; allowlist пуст).
+
+Подробнее: [adr-0036](adr/adr-0036-replication-foundation-host-parametrization.md), детально —
+`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md` (D1…D10),
+`docs/work-items/ORCH-101/07-infra-requirements.md`, `10-tech-risks.md`.
+
+**Type A — Lite (ORCH-102 — design).** Поверх 10-common вводится канон Lite-тиража: новый
+docs-раздел `docs/deployment/` (витрина тиража, читатель — внешний оператор) с golden source
+`docs/deployment/LITE_SETUP.md` — сквозной маршрут «голый хост → работающий конвейер» из 13
+нормативных разделов (предусловия → код → конфиг/секреты → Plane → Gitea → LLM → Telegram →
+запуск → онбординг проекта → smoke → stateless-проверка → траблшутинг), каждый шаг =
+fenced-команда + явная проверка (PASS/FAIL), хост-специфика — только плейсхолдеры. Compose не
+форкается: `docker-compose.yml` сам является Lite-подмножеством (дефолтный `up -d` поднимает
+ровно `orchestrator`+`orchestrator-watchdog`; staging — за профилем, в Lite опционален). Канон
+watchdog-конфига — новый `.env.watchdog.example` (key-set = блоку `WATCHDOG_*` `.env.example`;
+sidecar читает только `.env.watchdog`; C-1 ORCH-100 — отдельный бот). Норматив тиражной
+инсталляции Gitea: branch protection на `main` НЕ включать (D10 ORCH-009, защита merge-актора).
+Анти-дрейф — структурный `tests/test_lite_setup_doc.py`. Рантайм/конвейер — байт-в-байт
+(docs+tests). Подробнее: [adr-0037](adr/adr-0037-lite-replication-canon.md), детально —
+`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`.
+
+**Type B — Bundled (ORCH-103).** Закрывает эпик ORCH-10: весь стек одним комплектом
+(орк + watchdog + Gitea + Plane CE ≈13–14 контейнеров) для заказчика без собственной
+инфраструктуры. Состав Plane — зеркало официального selfhost-référence v0.23.1
+(upstream-имена сервисов web/space/admin/api/worker/beat-worker/migrator/live +
+plane-db/plane-redis/plane-mq/plane-minio/proxy); Gitea — `gitea/gitea:1.22.6`
+(не rootless, ssh выключен). Новый top-level каталог **`deploy/`** (исполняемые дистрибутивы; дополняет
+`docs/deployment/` — инструкции): `deploy/bundled/docker-compose.yml` — один самодостаточный
+compose с `name: orchestrator-bundle` (узнаваемый префикс томов/контейнеров; `container_name`
+не пиннится — нет коллизий с корневым compose на одном хосте), пиннинг сторонних образов
+неподвижными тегами литералом (не `latest`); корневой compose не форкается (заморожен
+анти-дрейфом ORCH-102); staging-контур орка в bundle отсутствует, репо `orchestrator` не
+регистрируется → self-deploy-машинерия структурно спит (`SELF_HOSTING_REPO`-леафы не матчатся).
+Сеть — одна bridge: машинный трафик строго сервис-DNS (webhooks в обе стороны, API, /metrics),
+наружу — только человеческие порты (Plane 8080 / Gitea 3000 / орк 8500; явный
+`GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` против дефолтного запрета приватных таргетов).
+Конфиг-слои: `deploy/bundled/.env.example` (канон bundle-инфры, key-set-sync тест) → live
+`deploy/bundled/.env` (авто-чтение compose из project dir, без `--env-file`-футгана); runtime
+орка/watchdog — корневые `.env`/`.env.watchdog` ровно по канону Lite (`env_file: required:
+false` до сборки); **единственный писатель live-файлов — bootstrap**.
+`scripts/bootstrap_bundle.py` (python stdlib-only, `plan`-дефолт/`apply`/`verify`, step-движок
+check→ensure, exit 0/2/1): preflight fail-fast до мутаций → секреты (`gen_secrets.py` +
+stdlib-креды стека, в логи не печатаются) → up+ожидание готовности → init Gitea (полностью
+автоматом через CLI; branch protection НЕ включать — D10 ORCH-009) → init Plane CE (честные
+manual-step: инструкция → подтверждение → API-верификация результата) → онбординг
+sandbox-проекта строго `onboard_project.py apply`/`verify` (host-venv, канон ONBOARDING) →
+git-доступ агентов token-remote (`_push_url`-паттерн; ssh-контур не вводится) → сборка env
+орка → health/итог; delete-операций в скрипте нет — teardown только документированной
+процедурой (§13). Golden source — `docs/deployment/BUNDLED_SETUP.md` (14 разделов по канону
+LITE_SETUP, требования к хосту по замеру тестового развёртывания; REPLICATION §1 — отметка
+Type B). Анти-дрейф — `tests/test_bundle_compose.py` / `test_bundled_setup_doc.py` /
+`test_bootstrap_script.py`. Рантайм/конвейер — байт-в-байт; kill-switch не нужен (активация —
+только явный запуск оператора на целевом хосте, паттерн ORCH-009). Подробнее:
+[adr-0038](adr/adr-0038-bundled-replication-canon.md), детально —
+`docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`.
+
+## Витрина системы `docs/overview/` (ORCH-011 — design)
+
+Единая точка входа «бизнес + тех» для трёх аудиторий (заказчик / менеджер / разработчик) —
+новый docs-раздел **`docs/overview/`** (семантика разделов: `overview/` — «что это за система
+и как устроена», `architecture/` — инженерный справочник, `deployment/` — «как развернуть у
+себя», `operations/` — «как эксплуатировать наш прод»). Состав — плоский каталог, 10 файлов:
+индекс `README.md` (маршруты 3 аудиторий + норматив сопровождения), `business.md`
+(бизнес-уровень без жаргона), 7 × `tech-*.md` (= 7 блоков: архитектура / конвейер / агенты /
+модель объектов / интеграции / качество-безопасность / наблюдаемость), `presentation.md`
+(слайдо-источник). **Link-first:** витрина ссылается на golden sources (этот README, internals,
+стандарты, ADR), не форкает их; разрешённый дубль — только машинно-сверяемый тестом факт
+(стадии/гейты/агенты — derive-тестами из `STAGE_TRANSITIONS`/`QG_CHECKS`/glob промптов).
+**Канон презентации:** `.pptx` (тёмный дизайн) собирается из `presentation.md` dev-скриптом
+`scripts/build_presentation.py` (python-pptx, запуск только вне рантайма; зависимость в
+прод-образ не попадает — машинный гард); **собранный бинарь в git не коммитится**. **Норматив
+сопровождения (кросс-каттинг):** «изменил функциональность → обнови витрину в том же PR»;
+reviewer-ось обзорных доков (ORCH-079) расширена на витрину (finding ≥ P1). Анти-дрейф —
+структурный `tests/test_system_docs.py` (паттерн `test_lite_setup_doc.py`); новый QG не
+вводится, рантайм байт-в-байт. Подробнее: [adr-0039](adr/adr-0039-system-overview-docs-canon.md),
+детально — `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`.
+
 ## Конвейер и Quality Gates
 
 ```
@@ -321,13 +447,50 @@ Self-hosting зацикливался на `deploy-staging`: `scripts/staging_ch
 Назначение: ветка валидируется относительно того `main`, из которого создана; параллельная задача могла уйти вперёд → семантический конфликт слияния (зелёная ветка ломает обновлённый `main`). Merge-gate гарантирует проверку против **актуального** `origin/main` перед слиянием:
 - **Догон:** ветка отстаёт (⇔ `origin/main` не предок HEAD) → `rebase origin/main` в worktree + `push --force-with-lease` (ТОЛЬКО ветка задачи; `main` — никогда). Текстовый конфликт → `rebase --abort` → откат на `development`.
 - **Безусловный pre-merge rebase (ORCH-026, A-2):** при `premerge_rebase_always` (дефолт `True`, скоуп `merge_gate_repos`) short-circuit `branch_is_behind_main` пропускается — `auto_rebase_onto_main` вызывается **всегда** под лизом. На актуальной ветке это no-op (`rebase` не меняет HEAD, `push --force-with-lease` → «Everything up-to-date», CI не триггерится); на отстающей — реальный догон. Детерминированный структурный анти-фантом на уровне планировщика (дополняет рубежи ORCH-073, не заменяет). Kill-switch `premerge_rebase_always=False` → прежнее поведение (ребейз только при behind).
-- **Re-test:** `python -m pytest` (`merge_retest_target`, дефолт `tests/`) в worktree догнанной ветки, тайм-аут `merge_retest_timeout_s`. Красный/тайм-аут → откат на `development`.
+- **Re-test:** `python -m pytest` (`merge_retest_target`, дефолт `tests/`) в worktree догнанной ветки, тайм-аут `merge_retest_timeout_s` (ORCH-110 D5: 600 → **900**, валидация `_resolve_retest_timeout` — малформ/непозитив → дефолт 900 + WARNING). **Красный** (детерминированный сбой теста) → откат на `development` + developer-retry (без изменений). **ORCH-110 (реализовано, [adr-0042](adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md)):**
+  - **(D4) Контракт необходимости re-test:** локальный re-test исполняется лишь когда rebase реально сдвинул HEAD (`main` уехал). Доказанный **no-op** rebase (`head_sha` до==после, обе непусты — ветка уже содержит свежий `origin/main`, HEAD уже прошёл CI+tester+staging) **пропускает** re-test (`(True, "branch up-to-date (re-test skipped: rebase no-op, HEAD CI-validated)")`, лиз HELD) — распространяет на путь `premerge_rebase_always=True` ту же оптимизацию, что путь `=False` уже имеет для не-behind ветки. Fail-safe: любая неопределённость (`head_sha` пуст / git-ошибка) → re-test **выполняется**. Kill-switch `merge_retest_skip_when_current_enabled`.
+  - **(D2/D3) Толерантность к инфра-таймауту:** предикат `classify_retest_failure(reason)` различает `timeout`/`red`/`lock-busy`/`other`. **Таймаут** re-test = инфра-транзиент → `_handle_merge_gate_infra_retry` (ограниченный повтор по образцу defer: задача **остаётся на `deploy-staging`**, staging-deployer перезапускается с задержкой `merge_retest_infra_retry_delay_s`, **БЕЗ** отката на `development` и **БЕЗ** расхода developer-retry), а НЕ прежний rollback. Исчерпание `merge_retest_infra_max_retries` → один **инфра-alert** (явно «НЕ дефект кода», кликабельный номер), задача НЕ уходит в `development`. Анти-над-толерантность (BR-6): **красный** re-test / конфликт по-прежнему откатывают. Scope-guard: «rebase timeout» (git завис) — НЕ инфра-таймаут re-test, остаётся на rollback-пути. Kill-switch `merge_retest_infra_tolerance_enabled` (off → таймаут=прежний rollback).
+  - **(D1) Tree-kill спавненных pytest:** re-test (и coverage `measure_coverage`) бегут через `proc_group.run_in_process_group` в **отдельной группе процессов** (`start_new_session`); при таймауте убивается **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL, грейс = `agent_kill_grace_seconds`) — осиротевшие внуки-pytest не переживают бюджет (корень CPU-голодания инцидента ORCH-109). Контракты возврата сохранены. Fallback never-break: `subprocess_tree_kill_enabled=False`/не-POSIX → прежний `subprocess.run`. Наблюдаемость — блок `merge_gate` в `GET /queue`; координация с ORCH-111 (`proc_blocking`) без дубля.
 - **Сериализация (merge-lock):** файловый **merge-lease** на репо (`<repos_dir>/.merge-lease-<repo>.json`), живёт от гейта до фактического merge. Acquire **неблокирующий** (anti-deadlock при `max_concurrency=1`): busy → **defer** (повторная постановка deployer'а на `deploy-staging` с задержкой через `available_at`), а не откат. Release — на PR-merged вебхуке / `deploy→done` / откате / по возрасту (crash-реклейм). Restart-safe; без изменения схемы БД. **ORCH-026 (A-1):** это окно = «merge → main-updated» (для self `done` ⇔ SHA-in-main, ORCH-073) — пока A не в `main`, B того же репо получает `merge-lock busy` → defer. Окно сериализации per-repo НЕ переписывается; кросс-репо параллелизм сохранён (лиз — per-repo файл).
 - **Условность (как ORCH-35):** реален для `orchestrator`; прочие репо — no-op. Флаги `merge_gate_enabled` / `merge_gate_repos` — поэтапный раскат. Контракт **never-raise**.
 
 Подробнее: [adr-0006](adr/adr-0006-merge-gate.md), детально — `docs/work-items/ORCH-043/06-adr/ADR-001-merge-gate.md`.
 Безусловный pre-merge rebase + связь с зависимостями задач — [adr-0015](adr/adr-0015-task-deps-and-merge-serialization.md) (ORCH-026).
 
+#### Merge-gate re-test: толерантность к инфра-таймауту + tree-kill + контракт re-test (ORCH-110 — design)
+Инцидент ORCH-109/PR#129: при зелёном tester `PASS` (1899 passed / 516.7s), зелёном CI и актуальной
+ветке локальный re-test merge-gate упал по **таймауту** (600s) из-за CPU-голодания от **осиротевших**
+pytest-процессов (жили > 2 суток). Таймаут классифицировался как код-фейл → ложный откат
+`deploy-staging → development` + 3 сожжённых developer-retry → manual-gate. ORCH-110 бьёт по двум
+корням, одному контракту и бюджету — **аддитивно, под kill-switch, never-raise, скоуп self-hosting**;
+исходная защита merge-gate от семантического конфликта сохранена (красный re-test по-прежнему
+откатывает). `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — **не тронуты**.
+- **Tree-kill (root, D1):** новый leaf `src/proc_group.py::run_in_process_group` спавнит
+  оркестратор-порождённые pytest-прогоны (`merge_gate.retest_branch` + `coverage_gate.measure_coverage`)
+  в отдельной группе процессов (`start_new_session`) и при таймауте/прерывании убивает **всё дерево**
+  (`os.killpg`, каскад SIGTERM→grace→SIGKILL, зеркало `launcher.stop_process`). Контракты возврата 1:1
+  (меняется лишь побочный эффект — нет сирот); fallback на прежний `subprocess.run` при kill-switch off
+  / не-POSIX. Kill-switch `subprocess_tree_kill_enabled`.
+- **Классификация + маршрутизация (D2/D3):** чистый `merge_gate.classify_retest_failure(reason) →
+  timeout|red|lock-busy|other`; инфра-таймаут → `_handle_merge_gate_infra_retry` (ограниченный
+  повтор/defer по образцу `_handle_merge_gate_defer`, **без** отката на `development`, **без** расхода
+  developer-retry; исчерпание → отдельный **инфра-alert**, не «developer must fix»); красный re-test →
+  прежний `_handle_merge_gate_rollback`. Kill-switch `merge_retest_infra_tolerance_enabled`, бюджеты
+  `merge_retest_infra_max_retries` (2) / `merge_retest_infra_retry_delay_s` (120s).
+- **Контракт re-test (D4):** локальный re-test исполняется ⇔ rebase реально сдвинул HEAD; доказанный
+  no-op rebase пропускает re-test (как уже делает путь `premerge_rebase_always=False` для не-behind
+  ветки), offline, без сетевого CI-запроса; fail-safe — на неопределённости re-test бежит. Kill-switch
+  `merge_retest_skip_when_current_enabled`.
+- **Бюджет (D5):** `merge_retest_timeout_s` 600 → 900 (запас 74% над 516.7s) + валидация (непозитив →
+  дефолт + WARNING); сквозной инвариант `reaper_max_running_s (5400) > Σ(deploy-staging gate-work
+  ≈4460)+grace` проверен — `reaper_max_running_s` **не меняется**.
+- **Наблюдаемость (D6):** счётчики + блок `merge_gate` в `GET /queue`; координация с ORCH-111
+  (`proc_blocking`, adr-0041) без дубля: ORCH-110 предотвращает/толерирует у источника, ORCH-111
+  наблюдает.
+
+Подробнее: [adr-0042](adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md), детально —
+`docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`.
+
 ### Coverage-гейт: защита от деградации покрытия тестами (ORCH-027 — design)
 Существующие тестовые гейты (`check_ci_green`, `check_tests_passed`, merge-gate re-test) судят
 только по факту прохождения тестов, не по **полноте** — фича «300 строк, 0 тестов» проходит
@@ -579,6 +742,40 @@ sentinel-файлы (`<repos_dir>/.deploy-state-<repo>/<wi>/`), без мигр
 Подробнее: [adr-0007](adr/adr-0007-executable-self-deploy.md), детально —
 `docs/work-items/ORCH-036/06-adr/ADR-001-executable-self-deploy.md`.
 
+#### Гигиена shared deploy-базы: устойчивый self-deploy `git pull` (ORCH-112 — design)
+**Инвариант (нормативно):** shared main checkout `<host_repos_dir>/<repo>`
+(= `settings.deploy_host_repo_path` = `/home/slin/repos/orchestrator`) — это
+**deploy/worktree-management база, НЕ редактируемый workspace.** Рабочие изменения туда
+**не пишутся** конвейером/агентами: агенты работают в worktree'ах `/repos/_wt/<repo>/<branch>`
+(`git_worktree.ensure_worktree`), `docker build` берёт контекст worktree
+(`image_freshness._host_worktree_path`), fallback'и гейтов на main clone — только чтение
+(`git show origin/main:...`). Локальные правки в deploy-базе по определению существовать не должны.
+
+**Проблема (инцидент ORCH-111 от грязи ORCH-104):** хук `scripts/orchestrator-deploy-hook.sh`
+делал **голый** `git pull origin main` в `$REPO` без гигиены рабочего дерева → любая локальная правка
+tracked-файла (`src/config.py`) блокировала merge → деплой падал → ручное вмешательство (групповой риск
+self-hosting). **Решение** — **resilient-pull, встроенный в хук** (`--deploy`): перед `git pull` хук
+при обнаружении грязи приводит базу к чистому актуальному `origin/main`
+(`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Гейт — env
+`CHECKOUT_HYGIENE`, инжектится `self_deploy.build_deploy_command` когда новый чистый never-raise leaf
+`src/checkout_hygiene.py`-`applies(repo)` истинен (kill-switch `checkout_hygiene_enabled` + скоуп
+`checkout_hygiene_repos`, пусто → self-hosting only).
+- **Сохранность (NFR-2, жёсткий контракт):** `git clean` — **только `-fd`, НИКОГДА `-x`** (иначе
+  удалит gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'`
+  и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломается rollback `do_rollback`).
+  Sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json` (под родителем `$REPO`) и
+  `.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`.
+- **Сходимость после failed/cancelled** — этим же deploy-time self-heal (база сходится на следующем
+  деплое); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
+- **Наблюдаемость** — хук пишет sentinel `hygiene` в deploy-state каталог; Phase-C finalizer читает и
+  шлёт Telegram-алерт (кликабельный номер, best-effort, never-raise).
+- **Чистая база / kill-switch off** — голый fast-forward `git pull` байт-в-байт (happy-path без
+  регресса); `--build-staging` (build из worktree, без pull) не затронут. `STAGE_TRANSITIONS` / реестр
+  `QG_CHECKS` / `check_*` / machine-verdict / схема БД / exit-code-контракт хука (0/1/2) — не тронуты.
+
+Детально — `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной
+[adr-0044](adr/adr-0044-deploy-base-checkout-hygiene.md).
+
 #### Выделенный статус-триггер прод-деплоя «Confirm Deploy» (ORCH-059 — реализовано)
 Перегрузка: один Plane-статус `Approved` служил И человеческим гейтом BRD на
 `analysis` (`check_analysis_approved`), И триггером Фазы B прод-деплоя на `deploy`
@@ -1008,7 +1205,15 @@ ORCH-065 вводит фоновый watchdog, чтобы смерть проц
   затем git push/PR/Plane-комментарии), поэтому Tier-2 реапит только после
   finalization-grace `reaper_finalize_grace_s` (живой финализирующий monitor НЕ
   реапится); Tier-3 backstop по потолку `reaper_max_running_s` (> max
-  agent_timeout+grace). Действие переиспользует контракты по принципу
+  agent_timeout+grace). **ORCH-113 (adr-0043):** на ребре `deploy-staging → deploy`
+  финализация в потоке монитора длится **минуты** (тяжёлые edge-под-гейты
+  security/merge-gate re-test/coverage/image-freshness идут после штампа
+  `finished_at` и до `_finalize_job`), а grace=300 это не покрывал → живой долгий
+  finalizer ошибочно реапился и независимо повторял advance (ложный откат,
+  инцидент ORCH-111). Tier-2 теперь консультирует процесс-локальный реестр владения
+  (`src/finalizer_liveness.py`): при `stage=="deploy-staging"` И активном владении —
+  **defer** (не повторяет advance), Tier-3 backstop маркер игнорирует. In-memory,
+  restart-safe через `requeue_running_jobs`; grace/потолок и бюджет не меняются. Действие переиспользует контракты по принципу
   **claim-before-act**: для exit0 канонический QG оценивается read-only ПЕРЕД
   атомарным claim, затем claim `done` ПЕРВЫМ и только победитель claim делает
   `_try_advance_stage` (advance+enqueue) — проигравший claim (поздний monitor /
@@ -1040,11 +1245,15 @@ ORCH-065 вводит фоновый watchdog, чтобы смерть проц
   `logger.warning`; reap→`failed` и lease-reclaim → Telegram.
 - **Kill-switch'и:** `ORCH_REAPER_ENABLED`, `ORCH_REAPER_INTERVAL_S`,
   `ORCH_REAPER_DEAD_TICKS`, `ORCH_REAPER_MAX_RUNNING_S`,
-  `ORCH_REAPER_FINALIZE_GRACE_S`, `ORCH_LEASE_RECLAIM_ENABLED`; `false` → строго
-  прежнее поведение.
+  `ORCH_REAPER_FINALIZE_GRACE_S`, `ORCH_LEASE_RECLAIM_ENABLED`,
+  `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED` (ORCH-113); `false` → строго прежнее
+  поведение.
 
-Подробнее: [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md), детально —
-`docs/work-items/ORCH-065/06-adr/ADR-001-job-reaper-and-lease-reclaim.md`.
+Подробнее: [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md) +
+[adr-0043](adr/adr-0043-reaper-finalizer-liveness-ownership.md) (ORCH-113,
+finalizer-liveness ownership); детально —
+`docs/work-items/ORCH-065/06-adr/ADR-001-job-reaper-and-lease-reclaim.md`,
+`docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`.
 
 ### Осмысленная статусная модель Plane (ORCH-066 — реализовано)
 Plane-доска была семантически перегружена: `In Progress` означал «человек запускает

docs/architecture/adr/README.md

@@ -41,11 +41,13 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | 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 использовать следующий
-> свободный номер (текущий максимум — `0035`).
+> свободный номер (текущий максимум — `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-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/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md

@@ -0,0 +1,85 @@
+---
+work_item: ORCH-109
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# adr-0040: Per-role wall-clock бюджеты (developer/reviewer) + launch-time стамп модели
+
+- **Статус:** proposed
+- **Дата:** 2026-06-14
+- **Задача:** ORCH-109
+- **Детальный ADR:** `docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md`
+
+## Контекст
+Инцидент **ORCH-104** вскрыл два глобальных дефекта подсистемы запуска агентов (`src/agents/launcher.py`),
+затрагивающих **все** репо общего self-hosting-инстанса (orchestrator + enduro-trails):
+(A) единый wall-clock тайм-аут `agent_timeout_seconds=1800` убивает здоровые тяжёлые роли
+(`developer` xhigh, `reviewer`), т.к. в проде `agent_timeout_overrides_json` пуст; (B)
+`agent_runs.model` пишется только постфактум из usage-JSON (`record_usage`, `COALESCE`), а
+timeout-killed прогон финальный JSON не эмитит → модель остаётся `NULL` именно в момент инцидента,
+хотя эффорт уже стампится на launch (ORCH-087). Решение меняет два **глобальных per-agent
+инварианта** (бюджеты тайм-аутов + потолок Tier-3 reaper'а ORCH-065), поэтому регистрируется сквозным
+ADR, а не только work-item ADR.
+
+## Решение
+Две аддитивные правки launcher'а, **без** касания `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict-ключей/схемы БД (колонка `agent_runs.model TEXT` уже существует — миграции нет):
+
+- **Launch-time стамп модели.** В `_spawn` резолвенная `resolve_agent_model(...)` пишется в
+  `agent_runs.model` рядом со стампом эффорта (объединённый `UPDATE … SET model=?, effort=?`),
+  пустой резолв → `NULL`. Постфактум `record_usage` (`model=COALESCE(?, model)`) остаётся
+  **обогащением**, перестаёт быть единственным источником истины — launch-стамп переживает kill и
+  виден in-flight (`db.get_running_agents` уже отдаёт `model`). never-raise: сбой стампа изолирован,
+  launch не падает.
+- **Per-role бюджеты через выделенные типизированные config-ключи** (по образцу
+  `agent_model_<role>`/`agent_effort_<role>`): `agent_timeout_developer_s=3600`,
+  `agent_timeout_reviewer_s=3000`. Лестница `_resolve_timeout`: `agent_timeout_overrides_json[agent]`
+  (escape-hatch, высший) → выделенный ключ роли → `agent_timeout_seconds=1800` (прочие роли —
+  байт-в-байт). never-break: малформный JSON / вне-диапазонный ключ → откат на глобальный дефолт +
+  WARNING.
+- **Синхронное поднятие reaper (инвариант ORCH-065).** `reaper_max_running_s`: **3600 → 5400**.
+  Проверка `reaper_max_running_s > max(timeout) + agent_kill_grace_seconds`: `5400 > 3600 + 20 = 3620`
+  ✓ (запас 1780s, покрывает окно финализации монитора). `5400 < ` sidecar `stage_stuck_s`=7200 →
+  легитимный длинный developer-прогон не порождает ложный `stage_stuck`-алерт.
+- **Канон дефолтов (ORCH-101).** Дефолт каждого ключа = боевому значению → пустой `.env`
+  воспроизводит прод-поведение (в т.ч. поднятые бюджеты). «Байт-в-байт прежнее» (NFR-1) строго
+  применяется к ролям вне `{developer, reviewer}`.
+- **FR-5 анти-salvage — структурно, без нового кода.** Продвижение стадии гейтится
+  `if exit_code == 0: _try_advance_stage(...)`; timeout-kill (-9) → `_finalize_job` → retry/fail,
+  никогда не advance. Добавляется регресс-тест, не новая ветвь.
+
+## Альтернативы
+- **Дефолт `agent_timeout_overrides_json={"developer":…}`** — отвергнуто: ломает канон ORCH-101
+  непустым JSON-дефолтом, хрупкая строка против типизированного int, нельзя override одной env-роли.
+- **Бюджеты ≤ 3580 без поднятия reaper** — рассмотрено (меньший blast-radius), отвергнуто как
+  доминирующее: урезает самую тяжёлую роль ради статичности backstop-числа; NFR-4 явно делегирует
+  reaper-поднятие архитектору. Остаётся операторским запасным путём (всё env-override'имо).
+- **Repo-scoped бюджеты (`*_repos`)** — отвергнуто: тайм-аут — свойство launch, не гейт-решение;
+  глобальность благоприятна enduro.
+- **Новый guard-leaf анти-salvage** — отвергнуто: продвижение уже гейтится exit-кодом; новый код =
+  лишняя ветвь риска.
+
+## Последствия
+- Модель видна (не `null`) при любом исходе прогона (трекер / status-комментарии / `/metrics` /
+  `/queue`) — ключевой контекст инцидента доступен в момент сбоя; тяжёлые роли получают реальный
+  бюджет (developer ×2, reviewer +67%) → меньше ложных timeout-kill при автономном прогоне (ORCH-088).
+- Аддитивно/обратимо/never-raise; гейты/схема/machine-verdict/деплой-путь не тронуты; прод-контейнер
+  не рестартится (self-hosting безопасность, NFR-5).
+- Плата: Tier-3 backstop 60→90м (реально зависший прогон держится дольше — митигейшн Tier-1/Tier-2 +
+  watchdog ≤ бюджета); глобальность поднимает enduro-роли (благоприятно; reaper-страховка цела);
+  sidecar `agent_hung` (alert-only) может чаще срабатывать на здоровых длинных прогонах с low-CPU
+  фазами (не влияет на конвейер).
+- **Откат:** занизить `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S` (= 1800) и вернуть
+  `ORCH_REAPER_MAX_RUNNING_S=3600`; launch-стамп модели отката не требует. Kill-switch не вводится
+  (нет рисковых ветвей: стамп безопасен, тайм-аут fail-safe на дефолт).
+
+## Связи
+adr-0011 (job-reaper — Tier-3 backstop `reaper_max_running_s`, инвариант ORCH-065 правится здесь
+синхронно), adr-0030 (metrics-endpoint — `get_running_agents().model` начинает заполняться для
+running-job), adr-0033 (sidecar-watchdog — `agent_hung`/`stage_stuck` пороги, alert-only),
+adr-0036 (replication foundation — канон «дефолт = боевое значение»). Маркер-инварианты: ORCH-065,
+ORCH-087, ORCH-101.

docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-111
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0041: Watchdog-сигнал `proc_blocking` — алерт на долго живущий осиротевший тест-процесс
+
+- **Статус:** proposed
+- **Дата:** 2026-06-15
+- **Задача:** ORCH-111 (bug → escalate full-cycle)
+- **Детальный ADR:** `docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md`
+- **Парные ADR:** `adr-0033` (sidecar-watchdog F1b), `adr-0030` (`/metrics` — не трогаем),
+  `adr-0024` (disk-watchdog — образец), `adr-0040` (timeout-kill `-9` — источник осиротения)
+
+## Контекст
+Sidecar-watchdog (ORCH-100, adr-0033) алертит `agent_hung`/`stage_stuck`/`container_down`/`orch_down`/
+`host_mem`/`queue_depth`/`job_failed`/`dep_down`. `agent_hung` покрывает **только** running-агент-джобы
+(по `jobs.pid` из `/metrics agents[]`). Но виновные процессы инцидента ORCH-109 — это субпроцессы
+pytest, которые орк запускает своим кодом (`merge_gate.retest_branch`, `coverage_gate.measure_coverage`);
+при timeout-kill агента (`-9`, adr-0040) или `TimeoutExpired` внук-pytest репарентируется на PID 1
+orchestrator-контейнера (tini жнёт зомби, но **не убивает живых осиротевших**) и живёт сутками, грузя
+CPU и валя merge-gate re-test. Контейнер `orchestrator-watchdog` сейчас **не видит таблицу процессов
+хоста** (`network_mode: host`, но **без** `pid: host` и mount `/proc`). Между `agent_hung` (треканые
+джобы) и осиротевшим процессом — слепая зона: блокирующий pytest **не порождает сигнала**.
+
+## Решение
+Новый per-entity сигнал **`proc_blocking`** **внутри наблюдателя** (`watchdog/**`): на каждом тике
+sidecar **сам** сканирует `/proc` хоста (stdlib), отбирает процессы тест-класса (cmdline матчит
+паттерн, дефолт `pytest`) и при возрасте > порога (заведомо > макс. легитимного бюджета тест-прогона)
+поднимает алерт через **существующую** `decision.decide()`/`AlertState` в собственный Telegram-канал
+sidecar. Watchdog процесс **не трогает** (только наблюдение, C-1). Изменения строго в наблюдателе;
+`src/**` / `/metrics`+`schema_version` / `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
+machine-verdict / схема БД — **не тронуты**.
+
+- **Механизм — watchdog-side `pid: host`, НЕ orch-side `/metrics`.** Решающее: orch-side путь правит
+  `src/metrics.py` → рестарт прод-`orchestrator` (запрет NFR-3); и слеп именно когда орк деградировал
+  (CPU-голодание), что противоречит C-1 (наблюдатель переживает падение наблюдаемого). Watchdog-side
+  читает `/proc` независимо от живости орка и не трогает контракт `/metrics`.
+- **Коллектор** `watchdog/collectors/proc.py` (новый, по образцу `collectors/host.py`): stdlib-only
+  (`/proc/stat` btime + `SC_CLK_TCK`; `/proc/<pid>/{cmdline,stat}`; возраст из starttime, CPU-время
+  из utime+stime — информационно); **read-only** (никогда `os.kill`/`Popen`/`/proc/<pid>/environ`);
+  **never-raise** (per-pid skip; top → `[]`).
+- **Builder** `proc_signals` (чистый, в `signals.py`): ключ `("proc_blocking", pid)`; `active` ⇔
+  `age_s > proc_age_s`; detail = усечённый cmdline-фрагмент + PID + возраст + CPU-время (BR-2).
+- **RECOVERY для исчезнувшего процесса (AC-6):** в `core.tick()` синтезируется `Signal(active=False)`
+  для `proc_blocking`-ключей, которые `alerting=True`, но исчезли из наблюдаемых → `decide()` даёт
+  один RECOVERY (переиспользование машины, без отдельной анти-спам-логики, FR-5).
+- **Анти-false-positive и отсутствие дубля с `agent_hung` — по построению:** (1) cmdline-скоуп —
+  `claude`-агенты не матчат `pytest` ⇒ нулевое пересечение с `agent_hung` (NFR-4); (2) порог возраста
+  > макс. бюджета (`max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)=900s`) ⇒ легитимный
+  in-budget прогон всегда ниже порога (BR-4). Кросс-namespace матчинг PID не нужен (ненадёжен).
+- **Конфиг (новые `WATCHDOG_PROC_*`):** `WATCHDOG_PROC_ENABLED` (дефолт **false** — opt-in/kill-switch,
+  зеркало `WATCHDOG_DISK_CRIT_ENABLED`), `WATCHDOG_PROC_AGE_MIN` (дефолт `60` мин; **инвариант:** >
+  макс. бюджета), `WATCHDOG_PROC_PATTERNS` (CSV, дефолт `pytest`), `WATCHDOG_PROC_COOLDOWN_S`
+  (дефолт `1800`). Дефолт-off ⇒ коллектор не вызывается ⇒ нулевая регрессия (AC-7).
+- **Топология:** `pid: host` **только** на сервисе `orchestrator-watchdog` (НЕ volume → существующий
+  `:ro`-тест compose зелёный; `/proc` отражает хост автоматически, отдельный mount не нужен).
+  Привилегия — только у наблюдателя.
+
+## Альтернативы
+- **Orch-side `/metrics`-обогащение** — отвергнуто: рестарт прод-орка (NFR-3) + слепота при
+  деградации орка (C-1) + новая поверхность контракта.
+- **Bind-mount `/proc:ro` вместо `pid: host`** — эквивалентная видимость/привилегия; `pid: host`
+  идиоматичнее (согласован с уже-`network_mode: host`). Валидная замена при предпочтении не делить
+  PID-namespace.
+- **Расширить `agent_hung` на нетреканые процессы** — отвергнуто: дубль/смешение классов (NFR-4).
+- **Реакция (kill/reap)** — вне объёма (BR-3, жёсткое ограничение): только мониторинг.
+- **Дефолт-on** — отвергнуто: привилегия + риск false-positive требуют осознанного opt-in.
+
+## Последствия
+- Закрыта слепая зона: ранний адресный алерт о CPU-голодании до того, как оно завалит merge-gate
+  re-test очередной задачи; работает даже при лёгшем орке.
+- Строго read-only + never-raise + дефолт-off + только наблюдатель ⇒ self-hosting-безопасно (enduro не
+  затронут); конвейер byte-for-byte; deploy без рестарта прод-`orchestrator` (только sidecar).
+- Анти-FP и no-dup — структурно (cmdline-скоуп + порог возраста), не хрупким PID-матчингом.
+- Плата: расширение привилегии наблюдателя (`pid: host`, read-only, **меньше** уже-смонтированного
+  `docker.sock`; код читает только `/stat`+`/cmdline`, никогда `/environ`; cmdline в алерте усечена);
+  Linux-специфичность `/proc` (не-Linux → `[]`); новые `WATCHDOG_PROC_*` ключи в каноне тиража.
+- **Топология** меняется (`pid: host`) → `07-infra-requirements.md`; **схема БД** не меняется → 08 =
+  N/A. Новый компонентный сигнал + привилегия → `arch:major-change`; прод-выкат через staging-гейт
+  sidecar, без рестарта прод-контейнера.
+- **Откат:** `WATCHDOG_PROC_ENABLED=false` (мгновенный) или удаление коллектора/builder/врезок/ключей
+  + `pid: host` — без следов в БД/схеме/контракте `/metrics`.
+
+## Связи
+adr-0033 (sidecar-watchdog F1b — рантайм/машина решения/независимый канал/never-raise — прямой
+родитель), adr-0030 (контракт `/metrics`/`schema_version` — изолирован, не тронут), adr-0024
+(disk-watchdog — образец pure-`decide_action`/dedup/recovery + «только читает и уведомляет»), adr-0040
+(timeout-бюджеты + `-9` timeout-kill — механизм осиротения внука-pytest), adr-0037/0038
+(Lite/Bundled тираж — канон `WATCHDOG_*` + compose sidecar, NFR-5).
+</content>

docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md

@@ -0,0 +1,84 @@
+---
+work_item: ORCH-110
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0042: Merge-gate re-test — толерантность к инфра-таймауту + tree-kill спавненных процессов + контракт re-test
+
+- **Статус:** proposed
+- **Дата:** 2026-06-15
+- **Задача:** ORCH-110 (bug → escalate full-cycle)
+- **Детальный ADR:** `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`
+- **Парные/смежные ADR:** `adr-0006` (merge-gate ORCH-043), `adr-0040` (timeout-бюджеты ORCH-109),
+  `adr-0029` (coverage-gate ORCH-027), `adr-0011` (reaper/lease ORCH-065),
+  `adr-0041` (ORCH-111 `proc_blocking` — комплементарный наблюдатель)
+
+## Контекст
+
+Merge-gate (ORCH-043) на ребре `deploy-staging → deploy` локально пере-прогоняет тест-сюит
+(`retest_branch`) для защиты от семантического конфликта слияния. Инцидент ORCH-109/PR#129: при
+зелёном tester `PASS` (1899 passed / 516.7s), зелёном CI и актуальной ветке re-test упал по
+**таймауту** (600s) из-за CPU-голодания от **осиротевших** pytest-процессов, переживших > 2 суток.
+Таймаут классифицировался как код-фейл → откат `deploy-staging → development` + 3 сожжённых
+developer-retry → manual-gate. Корни: (1) `subprocess.run(timeout=)` убивает только прямого потомка —
+внуки pytest репарентируются на PID 1 и живут (в `merge_gate.retest_branch` и
+`coverage_gate.measure_coverage`); (2) нет толерантности к инфра-таймауту; (3) тонкий бюджет (≈16%);
+(4) избыточный re-test на уже актуальной ветке (`premerge_rebase_always=True` форсит rebase+retest
+даже на no-op rebase).
+
+Решение кросс-каттинговое: затрагивает merge-gate, coverage-gate и сквозной инвариант времени
+reaper/lease — поэтому регистрируется глобально.
+
+## Решение (сводка)
+
+Аддитивно, под kill-switch, never-raise, скоуп self-hosting; исходная защита merge-gate от
+семантического конфликта сохранена (красный re-test по-прежнему откатывает).
+
+- **D1 — tree-kill.** Новый leaf `src/proc_group.py::run_in_process_group` спавнит
+  оркестратор-порождённые pytest-прогоны в отдельной группе процессов (`start_new_session`) и при
+  таймауте убивает **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL, зеркало
+  `launcher.stop_process`). Используют `retest_branch` и `measure_coverage`; контракты возврата 1:1,
+  меняется лишь побочный эффект (нет сирот). Fallback на прежний `subprocess.run` при kill-switch off
+  / не-POSIX. Kill-switch `subprocess_tree_kill_enabled`.
+- **D2 — классификация.** Чистый `merge_gate.classify_retest_failure(reason) → timeout|red|lock-busy|
+  other`; `check_branch_mergeable` не меняет имя/семантику/PASS-FAIL (реестр `QG_CHECKS` цел).
+- **D3 — маршрутизация.** Инфра-таймаут → `_handle_merge_gate_infra_retry` (ограниченный повтор/defer
+  по образцу `_handle_merge_gate_defer`, **без** отката на `development`, **без** расхода
+  developer-retry); исчерпание → отдельный **инфра-alert** (не «developer must fix»). Красный re-test
+  → прежний `_handle_merge_gate_rollback`. Kill-switch `merge_retest_infra_tolerance_enabled`,
+  бюджеты `merge_retest_infra_max_retries`/`merge_retest_infra_retry_delay_s`.
+- **D4 — контракт re-test.** Локальный re-test исполняется ⇔ rebase реально сдвинул HEAD (`main`
+  уехал); доказанный no-op rebase пропускает re-test (как уже делает путь
+  `premerge_rebase_always=False` для не-behind ветки), offline, без сетевого CI-запроса. Fail-safe: на
+  любой неопределённости re-test бежит. Kill-switch `merge_retest_skip_when_current_enabled`.
+- **D5 — бюджет.** `merge_retest_timeout_s` 600 → 900 (запас 74%) + валидация (непозитив → дефолт +
+  WARNING). Сквозной инвариант `reaper_max_running_s (5400) > Σ(deploy-staging gate-work ≈4460)+grace`
+  проверен — `reaper_max_running_s` **не меняется**.
+- **D6 — наблюдаемость.** Счётчики `merge_gate` + блок `merge_gate` в `GET /queue`; координация с
+  ORCH-111 без дубля (ORCH-110 предотвращает/толерирует у источника, ORCH-111 наблюдает).
+
+## Инварианты (неприкосновенны)
+
+- `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict ключи / схема БД —
+  **байт-в-байт** (под-гейт — врезка в `advance_stage`, не новая стадия/QG; новых таблиц/колонок нет).
+- INV-4: никогда push/force-push `main`, merge только через Gitea PR API; прод-контейнер не
+  рестартится; detached-деплой не трогается.
+- never-raise во всех новых функциях/врезках; исключение не уходит в `advance_stage`/монитор.
+- Kill-switch + нулевая регрессия: каждый флаг off → байт-в-байт до-ORCH-110; enduro (non-self) — no-op.
+
+## Последствия
+
+- **+** Устранён ложный откат/manual-gate при инфра-таймауте; устранена утечка CPU от сирот;
+  re-test не избыточен на актуальной ветке.
+- **−** До ~34 мин на инфра-ретраи перед alert (вместо мгновенного ложного отката); +5 конфиг-ключей.
+- **Откат:** вернуть 4 kill-switch и `merge_retest_timeout_s=600`.
+
+## Ссылки
+- Детально: `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`
+- Код: `src/merge_gate.py`, `src/coverage_gate.py`, `src/qg/checks.py`, `src/stage_engine.py`,
+  `src/config.py`, `src/agents/launcher.py`, `src/job_reaper.py`, новый `src/proc_group.py`
+</content>

docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-113
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0043: Reaper Tier-2 — in-memory ownership-маркер финализации `deploy-staging` (живой finalizer не реапится)
+
+- **Статус:** proposed
+- **Дата:** 2026-06-15
+- **Задача:** ORCH-113 (bug → escalate full-cycle; кластер инцидента ORCH-111)
+- **Детальный ADR:** `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`
+- **Уточняет:** `adr-0011` (job-reaper/lease-reclaim ORCH-065), `adr-0040` (timeout-бюджеты ORCH-109),
+  `adr-0042` (merge-gate re-test infra-tolerance + tree-kill ORCH-110), `adr-0041`
+  (ORCH-111 `proc_blocking` — комплементарный наблюдатель того же инцидента)
+
+## Контекст
+
+На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит
+`agent_runs.finished_at`/`exit_code` **первым**, затем синхронно, в своём потоке, прогоняет тяжёлый
+набор edge-под-гейтов через `_try_advance_stage → advance_stage` (`stage_engine.py:327–368`):
+`security` → `merge-gate` (полный локальный re-test, `merge_retest_timeout_s=900`) → `coverage`
+(`pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание staging) — **минуты**, — и лишь
+потом `_finalize_job`. Reaper Tier-2 (`job_reaper.py:197–209`) меряет `finished_age_s` от
+`finished_at` = **начала** финализации и по `reaper_finalize_grace_s=300` считает живого, долго
+финализирующего монитора мёртвым → независимо повторяет тот же тяжёлый advance. Атомарный
+claim-before-act защищает лишь **флип строки** job, но не **side-effectful исполнение edge-гейтов**
+(монитор не claim'ит строку перед `advance_stage`) → две `advance_stage` параллельно.
+
+Инцидент ORCH-111 (job 1914): повторный re-test красный, ложный откат `deploy-staging → development`
+(+ ложный developer-retry), **параллельно** исходный finalizer довёл deploy до SUCCESS и смержил
+PR #130 — состояние раздвоилось. Реального сигнала «жив ли finalizer» нет (pid агента в Tier-2 мёртв в
+обоих случаях). Per-stage grace, покрывающая Σ финализации (≈4160с), невозможна без нарушения сквозного
+бюджета ORCH-065/109/110 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace (≈4460)`.
+
+**Решающий факт (проверен):** монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без
+`--workers`), общая SQLite-БД → живость finalizer'а определяется **in-memory**. Рестарт покрыт
+существующим `requeue_running_jobs()` (running→queued), вызываемым в `main.lifespan` **до** старта reaper.
+
+## Решение
+
+1. **Leaf `src/finalizer_liveness.py`** — чистый процесс-локальный реестр владения финализацией
+   (паттерн `serial_gate`/`coverage_gate`: never-raise, без сети/БД): `mark(job_id, run_id, stage)` /
+   `clear(job_id)` / `is_active(job_id) -> bool` / `snapshot()`; `{job_id: {...}}` + `threading.Lock`;
+   собственного TTL нет (ограничение по времени даёт Tier-3).
+2. **Эмиссия владения** — `launcher._monitor_agent`: `mark(...)` сразу после штампа `exit_code`
+   (самый ранний момент Tier-2), `clear(...)` в `try/finally` вокруг хвоста финализации → исключение
+   в потоке монитора гарантированно снимает владение (reaper добивает). Гибель процесса → рестарт →
+   `requeue_running_jobs` → реестр пуст (restart-safe без durable-хранения).
+3. **Консультация reaper** — `_reap_job` Tier-2 (`exit_code` записан, `finished_age >= grace`): если
+   `reaper_finalizer_liveness_enabled` **И** стадия `== "deploy-staging"` **И** `is_active(job_id)` →
+   **defer** (лог + счётчик), не реапить через Tier-2, провалиться к Tier-3. Иначе — прежний путь.
+   **Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — добивает всегда в ограниченное время.
+4. **Скоуп/флаг** — только глобальный kill-switch `reaper_finalizer_liveness_enabled`
+   (env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`); **без** per-repo разреза (баг общий
+   для всех репо со стадией `deploy-staging`; per-repo оставил бы баг активным для части репо).
+   `False` → reaper байт-в-байт прежний; стадии `!= deploy-staging` не консультируются.
+5. **Наблюдаемость** — счётчик `finalizer_defers_total` + размер `snapshot()` в блоке `reaper`
+   `GET /queue`; существующие ключи ответа не меняются; новых эндпоинтов нет.
+
+**Инварианты:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
+существующих таблиц — **байт-в-байт**; **нулевое** изменение схемы БД; reaper остаётся never-raise
+наблюдателем; `reaper_finalize_grace_s` и `reaper_max_running_s` **не меняются** (сквозной бюджет цел);
+фикс не рестартит прод и не пушит `main`.
+
+## Альтернативы
+- Per-stage grace, покрывающая Σ — отвергнуто (нарушает бюджет `5400 > Σ+grace`; таймер = источник бага).
+- Durable-колонка (heartbeat/owner-токен) — отвергнуто (один процесс → in-memory авторитетно; рестарт
+  покрыт requeue; блокирующий re-test не может бить heartbeat).
+- Sub-state `finalizing` в `jobs.status` — отвергнуто (меняет семантику статуса для
+  claim/requeue/reconciler/reaper — нарушение NFR-2).
+- Lease-файл на `(job, stage)` — отвергнуто (тяжелее, дублирует merge-lease, TTL = таймер-проблема).
+- Флип job из `running` до тяжёлых гейтов — отвергнуто (ломает `get_running_jobs`/метрики и
+  restart-requeue).
+
+## Последствия
+- (+) Устранены повторный прогон edge-гейтов, ложный откат и расхождение состояния при живом долгом
+  finalizer'е `deploy-staging`; идемпотентность исполнения edge-гейтов через владение.
+- (+) Реально мёртвый/застрявший finalizer добивается (finally-clear → Tier-2; иначе Tier-3); функция
+  reaper ORCH-065 сохранена.
+- (+) Нулевое изменение схемы и контрактов; сквозной бюджет ORCH-065/109/110 не тронут; откат — один
+  env-флаг.
+- (−) Гарантия владения валидна при **одном процессе/одной БД** (проверено: один uvicorn-воркер); ввод
+  `--workers>1` потребует durable-сигнала (риск в work-item 10-tech-risks).
+- (−) Окно «штамп `finished_at` → `mark()`» (git push) маркером не покрыто — закрыто прежним grace=300.
+
+## Связи
+- Базируется/уточняет: `adr-0011`, `adr-0040`, `adr-0042`, `adr-0041`.
+- Союзные задачи кластера инцидента ORCH-111: `ORCH-110` (инфра-толерантность merge-gate — отдельный
+  объём, не дублировать), `ORCH-109` (бюджеты).
+- Детально: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`.
+</content>

docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md

@@ -0,0 +1,66 @@
+---
+work_item: ORCH-112
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0044: Гигиена shared deploy-базы — устойчивый self-deploy `git pull`
+
+Сквозное (cross-cutting) решение. Детальный per-work-item ADR —
+`docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`.
+
+## Статус
+Proposed (ORCH-112)
+
+## Контекст (сквозной)
+
+Глобальный путь прод-деплоя self-hosting (`deploy`-стадия, ORCH-036) исполняет хост-хук
+`scripts/orchestrator-deploy-hook.sh`, чей шаг «2. Pull latest code» — **голый** `git pull origin main`
+в shared main clone (`settings.deploy_host_repo_path`). Любая грязь рабочего дерева (модифицированный
+tracked-файл и/или untracked-остатки failed/cancelled/брошенной задачи) **блокирует** merge → деплой
+встаёт → ручное вмешательство. На self-hosting (один прод-инстанс на все проекты с общей БД/очередью)
+это **групповой риск**: залипший self-deploy орка останавливает обслуживание всех проектов
+(инцидент ORCH-111, грязь от ORCH-104).
+
+## Решение (сквозное)
+
+Вводится **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`), + новый чистый never-raise
+leaf-компонент `src/checkout_hygiene.py`:
+
+- **Хук** перед `git pull origin main` приводит грязную deploy-базу к чистому актуальному `origin/main`
+  (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`), **строго сохраняя**
+  rollback/лог-артефакты. Гейт — env `CHECKOUT_HYGIENE`, инжектится `self_deploy.build_deploy_command`.
+- **Leaf** `checkout_hygiene` решает условность (`applies(repo)`: kill-switch `checkout_hygiene_enabled`
+  + скоуп `checkout_hygiene_repos`, пусто → self-hosting only), строит env-префикс, читает sentinel
+  отчёта, шлёт Telegram-алерт. Образец `serial_gate`/`cancel`/`self_deploy`.
+- **Сходимость** базы после failed/cancelled (FR-2) — этим же deploy-time self-heal; `cancel_task`
+  (ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
+- **Наблюдаемость** — хук пишет sentinel `hygiene`, Phase-C finalizer читает и шлёт Telegram-алерт
+  (best-effort, never-raise).
+- **Инвариант** «main checkout — deploy/worktree-management база, НЕ workspace» документируется
+  (INFRA.md + architecture/README.md); de-facto энфорс — сам resilient-pull.
+
+## Кросс-каттинг-инварианты (обязательны к соблюдению будущими задачами)
+
+- **INV-HYGIENE-1 (никогда `-x`):** hygiene-`git clean` — только `git clean -fd`. `-x` удалил бы
+  gitignored `.env` (прод-секреты) / `data/*.db` (БД прода) / `build/`. Анти-регресс — статический тест.
+- **INV-HYGIENE-2 (явные excludes):** `.deploy-prev-image-*` (rollback, `deploy_prod_prev_image_file`)
+  и `deploy-hook.log` — untracked-но-НЕ-ignored → обязательны `-e`-исключения; их удаление сломало бы
+  rollback.
+- **INV-HYGIENE-3 (скоуп = `$REPO`):** гигиена оперирует только рабочим деревом deploy-базы;
+  sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json` и `.git/worktrees/*` — вне области.
+- **Self-hosting safety (NFR-1):** никогда не трогать `main` на remote, не force-push, не рестартить
+  прод вне штатного гейта, не сносить worktree/ветки других активных задач.
+- **Нулевая регрессия (NFR-5):** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` /
+  machine-verdict ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — байт-в-байт. Это
+  устойчивость deploy-пути, **не** Quality Gate и **не** стадия.
+
+## Связи
+- Дополняет: adr-0007 (executable self-deploy, ORCH-036), adr-0008 (image-freshness, ORCH-058).
+- Не нарушает: adr-0026 (STOP/cancel, ORCH-090) — каскад cancel не трогается.
+
+## Откат
+`ORCH_CHECKOUT_HYGIENE_ENABLED=false` → прод-деплой байт-в-байт до ORCH-112 (голый `git pull origin main`).

docs/architecture/internals.md

@@ -93,7 +93,7 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash
 Каждый запуск:
 1. Записывает run в DB (agent_runs)
 2. Запускает subprocess. **stdout/stderr перенаправляются СРАЗУ в файл `/app/data/runs/{id}.log` на уровне ОС** (Popen `stdout=log_fh`). Никакого PIPE в памяти оркестратора → нет PIPE-deadlock, нет потока-читателя, нет зомби (B-2).
-3. Стартует **watchdog thread** (timeout 30 мин → SIGKILL по pid)
+3. Стартует **watchdog thread** (per-role wall-clock бюджет → SIGTERM→grace→SIGKILL по pid; ORCH-109: developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт, `_resolve_timeout`)
 4. Стартует **monitor thread**: `proc.wait()` (гарантированный reap → реальный exit_code в БД) → закрывает log_fh → git commit/push → auto-advance
 
 ### 5. Auto-advance (`launcher._try_advance_stage`)
@@ -259,7 +259,7 @@ services:
 
 | Механизм | Описание |
 |----------|----------|
-| Watchdog | Каждый агент: timeout 30 мин → SIGKILL + exit_code=-9 |
+| Watchdog | Per-role wall-clock бюджет (ORCH-109): developer 60 мин / reviewer 50 мин / прочие 30 мин (`_resolve_timeout`) → SIGTERM→grace→SIGKILL + exit_code=-9. Tier-3 backstop `reaper_max_running_s`=90 мин > max(timeout)+grace (ORCH-065) |
 | safe.directory | git операции работают в любой директории |
 | Max retries | Developer: max 3 попытки, затем эскалация |
 | Zombie-free | stdout идёт сразу в файл + monitor `proc.wait()` → процесс всегда reap'нут (B-2) |
@@ -385,7 +385,16 @@ daemon-поток `src/job_reaper.py` (каркас `reconciler`) периоди
   git push/PR/Plane-комментарии (секунды-десятки секунд) и лишь потом
   `_finalize_job`; pid агента к этому моменту мёртв в обоих случаях. Поэтому
   Tier-2 реапит только после finalization-grace `reaper_finalize_grace_s`
-  (`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится;
+  (`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится.
+  **ORCH-113 (adr-0043):** на ребре `deploy-staging → deploy` финализация длится
+  **минуты** (тяжёлые edge-под-гейты после штампа `finished_at`, до `_finalize_job`),
+  grace=300 это не покрывал → живой долгий finalizer ошибочно реапился и повторял
+  advance (ложный откат, инцидент ORCH-111). Tier-2 консультирует процесс-локальный
+  реестр владения `src/finalizer_liveness.py` (`mark`/`clear` в потоке монитора через
+  try/finally): при `stage=="deploy-staging"` И активном владении → **defer**;
+  Tier-3 backstop маркер игнорирует (мёртвый/застрявший finalizer добивается).
+  Kill-switch `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`; in-memory, restart-safe через
+  `requeue_running_jobs` (до старта reaper); схема БД и сквозной бюджет не тронуты;
 - **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
 
 Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,

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,608 @@
+# 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)
+```
+
+**Опционально (ORCH-111): алерт на осиротевший тест-процесс.** Watchdog умеет
+поднимать сигнал `proc_blocking` на долго живущий процесс тест-класса (по умолчанию
+`pytest`), репарентированный на хост и грузящий CPU. По умолчанию **выключен**
+(`WATCHDOG_PROC_ENABLED=false`) — нулевая регрессия. Чтобы включить, в `.env.watchdog`:
+`WATCHDOG_PROC_ENABLED=true`, при необходимости подстройте `WATCHDOG_PROC_AGE_MIN`
+(минуты; **обязан** превышать `max(merge_retest_timeout_s, coverage_run_timeout_s)/60`,
+дефолт 60), `WATCHDOG_PROC_PATTERNS` (CSV cmdline-подстрок), `WATCHDOG_PROC_COOLDOWN_S`.
+Для видимости процессов хоста сервису `orchestrator-watchdog` в `docker-compose.yml`
+задан `pid: host` (привилегия только у наблюдателя, read-only). **Проверка:**
+`grep -E '^WATCHDOG_PROC_ENABLED=' .env.watchdog` — если `true`, после рестарта только
+sidecar (`docker compose up -d orchestrator-watchdog`) в его логах виден тик без ошибок.
+
+**Проверка (резолв всей конфигурации):**
+
+```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/operations/INFRA.md

@@ -21,6 +21,14 @@
    /repos/<project>  ← общий каталог репозиториев (host: /home/slin/repos)
 ```
 
+> **Инвариант deploy-базы (ORCH-112, нормативно).** Shared main checkout
+> `<host_repos_dir>/<repo>` (= `/home/slin/repos/orchestrator` == `/repos/orchestrator` в контейнере
+> через bind-mount == `settings.deploy_host_repo_path`) — это **deploy/worktree-management база, НЕ
+> редактируемый workspace.** Рабочие изменения туда **не пишутся** конвейером/агентами: агенты —
+> worktree `/repos/_wt/<repo>/<branch>` (`git_worktree`), `docker build` — worktree-контекст,
+> fallback'и гейтов — read-only `git show origin/main`. Self-deploy `git pull` устойчив к грязной
+> базе (resilient-pull, см. self-hosting-страховки ниже).
+
 ## Контейнеры
 
 | Контейнер | Роль | Порт | env_file | БД (хост) | Старт |
@@ -171,8 +179,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) — изоляция.
@@ -213,6 +228,7 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 **Страховки:**
 - Стадия `deploy-staging` (порт 8501) — обязательный гейт перед прод-деплоем орка. Прод-деплой недостижим, пока staging-гейт не зелёный (см. `STAGING.md`, ORCH-35). Гейт условный: реален только для self-hosting (repo=orchestrator), для остальных проектов — no-op.
 - **Свежесть staging-образа (ORCH-058):** на ребре `deploy-staging → deploy` (ПОСЛЕ merge-gate, ДО Phase A) QG-под-чек `check_staging_image_fresh` пересобирает staging-образ из валидированного коммита и пересоздаёт 8501 (Strategy A), а хук перед build-once retag fail-closed сверяет OCI-лейбл `revision` с `EXPECTED_REVISION` (Strategy B). Гарантирует: в прод промоутится РОВНО провалидированный артефакт (инцидент LESSONS_ORCH-036 п.4 — тихий промоут устаревшего образа). Сборки/recreate — ТОЛЬКО staging (8501); FAIL → откат на `development`. Условный: реален только для self-hosting.
+- **Гигиена shared deploy-базы (ORCH-112):** self-deploy `git pull origin main` устойчив к грязному рабочему дереву deploy-базы (модифицированные tracked + untracked-остатки failed/cancelled/брошенных задач). Хук `--deploy` перед pull приводит базу к чистому `origin/main` (resilient-pull: `git fetch` + `git reset --hard origin/main` + `git clean -fd`), **строго сохраняя** rollback-снимки `.deploy-prev-image-*`, `deploy-hook.log`, gitignored `.env`/`data/`/`*.db` (НИКОГДА `-x`!), sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*`. Гейт — kill-switch `ORCH_CHECKOUT_HYGIENE_ENABLED` (дефолт `True`; off → голый pull 1:1); скоуп `ORCH_CHECKOUT_HYGIENE_REPOS` (пусто → self-hosting only). Грязь базы детектируется → лог + Telegram-алерт (Phase-C finalizer). Решает инцидент ORCH-111 (грязь ORCH-104 заблокировала `git pull`). Детально — `docs/work-items/ORCH-112/06-adr/ADR-001`, сквозной adr-0044.
 
 **Правила для агентов при задачах ORCH:**
 1. НЕ перезапускать / не ронять прод-контейнер `orchestrator` в рамках задачи.

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/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,220 @@
+# Презентация системы: слайдо-источник
+
+> Источник истины презентации. Каждый слайд — блок `## Слайд N: Заголовок` с тезисами
+> (3–6 на слайд) и опциональной подписью визуала. Из этого файла собирается редактируемый
+> PowerPoint в тёмном дизайне — процедура в конце файла («Как собрать .pptx»). Собранный
+> бинарь в git не коммитится: меняешь рассказ — правишь этот файл и пересобираешь.
+
+## Слайд 1: Orchestrator — автономная фабрика разработки
+
+- Конвейер из ИИ-агентов: от постановки задачи до выкладки на прод
+- Человек ставит задачу и принимает результат — всё между автономно
+- Платформа уже работает: ведёт несколько проектов и дорабатывает сама себя
+
+> Визуал: тёмный титул, логотип-конвейер из шести звеньев
+
+## Слайд 2: Проблема
+
+- Классическая разработка — люди-бутылочное-горлышко на каждом шаге
+- Каждая передача между ролями — потеря времени, контекста и денег
+- Мелкая фича или баг едут до прода днями — из-за очередей, не сложности
+
+> Визуал: цепочка из шести человек с песочными часами между ними
+
+## Слайд 3: Решение
+
+- Шесть ИИ-агентов проводят задачу через все стадии разработки сами
+- Аналитик → архитектор → разработчик → ревьюер → тестировщик → деплойер
+- Человек принимает два решения: одобрить постановку и подтвердить прод
+- Честность держат машинные гейты качества — их нельзя «уговорить»
+
+> Визуал: та же цепочка, но из агентов; человек над ней с двумя кнопками
+
+## Слайд 4: Как это работает — конвейер
+
+- Задача из трекера едет по стадиям: анализ → проектирование → код → ревью → тесты → репетиция → прод
+- На каждом переходе — гейт: машинная проверка честности стадии
+- Не прошёл гейт — задача возвращается на доработку с замечаниями
+- Каждая задача — своя ветка и изолированная рабочая копия кода
+
+> Визуал: горизонтальная схема стадий со шлагбаумами-гейтами
+
+## Слайд 5: Гейты качества
+
+- Вердикты машинные: зелёный CI, одобрение ревью, отчёт тестов — только структурированные ключи
+- Перед продом — четыре дополнительных проверки: безопасность, слияние, покрытие тестами, свежесть сборки
+- Покрытие тестами не может деградировать: базовая линия растёт только вверх
+- Слияние в основную ветку — только через PR; прямой push запрещён всем
+
+> Визуал: четыре шлагбаума подряд перед воротами «прод»
+
+## Слайд 6: Роли агентов
+
+- Аналитик: требования, критерии приёмки, тест-план
+- Архитектор: проектные решения с фиксацией в ADR
+- Разработчик: код + тесты + документация одним PR
+- Ревьюер и тестировщик: независимые машинные вердикты
+- Деплойер: репетиция на песочнице, затем прод
+
+> Визуал: шесть карточек-ролей с артефактами на выходе
+
+## Слайд 7: Человек в контуре
+
+- Постановщик и приёмщик, а не оператор: ноль ручных пинков в штатном прогоне
+- Решение 1: одобрить постановку после аналитики
+- Решение 2: подтвердить выкладку на прод отдельным статусом
+- Живая карточка задачи в Telegram показывает, когда конвейер ждёт вас
+
+> Визуал: человек с двумя кнопками и карточка задачи в телефоне
+
+## Слайд 8: Запуск и ведение задачи через Plane
+
+- Запуск: перевод задачи в статус «To Analyse» — единственная точка входа в конвейер
+- Статусы Plane — индикация, а не управление: платформа выставляет их сама (Backlog → … → Done)
+- Управляющих статусов ровно три: запуск, человеческие гейты и отмена
+- Ход задачи виден сразу: статусы доски, живая карточка в Telegram, комментарии в задаче со ссылками на ветку и PR
+
+> Визуал: доска Plane с движущейся карточкой и зеркальное уведомление в Telegram
+
+## Слайд 9: Что решает человек: гейты, авто-режим, отмена
+
+- Гейт 1 — статус «Approved» на анализе: одобрить постановку задачи
+- Гейт 2 — статус «Confirm Deploy» на деплое: подтвердить прод отдельным статусом, чтобы привычный approve не выкатил прод случайным кликом
+- Лейблы «autoApprove» / «autoDeploy» снимают эти два решения для пакетного авто-режима
+- Авто-режим убирает только ожидание человека — ни одна техническая проверка не пропускается
+- Лейбл «Bug» — короткий багфикс-маршрут; статус «STOP» — безопасная отмена с уборкой ветки и worktree, не трогает прод
+
+> Визуал: две кнопки человека, переключатели авто-лейблов и стоп-кран STOP
+
+## Слайд 10: Пакетный автономный режим
+
+- Задачи одного проекта едут строго друг за другом — без столкновений
+- Каждая следующая стартует от свежего кода с результатом предыдущей
+- Метки авто-одобрения снимают оба человеческих гейта — пакет уезжает «за ночь»
+- Технические проверки при этом не ослабляются ни на одну
+
+> Визуал: ночная очередь задач, утром — стопка готовых
+
+## Слайд 11: Багфикс за полцены
+
+- Метка «баг» — и задача едет коротким маршрутом
+- Пропускаются тяжёлая аналитика и отдельное проектирование
+- Обязателен регресс-тест, фиксирующий дефект
+- Все гейты качества — без исключений
+
+> Визуал: развилка маршрутов — длинный и короткий путь к одному финишу
+
+## Слайд 12: Самовосстановление
+
+- Упавший агент перезапускается, осиротевшая задача возвращается в очередь
+- Зависшие состояния находит и чинит фоновый сверщик
+- Независимый сторож следит за платформой снаружи и шлёт алерты отдельным каналом
+- Деградация прода после выкладки замораживает проект до разбора человеком
+
+> Визуал: платформа с автоподзаводом и внешним сторожем
+
+## Слайд 13: Наблюдаемость
+
+- Одна задача — одна живая карточка: стадия, агент, стоимость, время
+- Служебные страницы: снимок очереди и машинные метрики для мониторинга
+- Журнал уроков копит отклонения конвейера — фундамент самообучения
+- Стоимость каждой задачи и каждой роли видна по фактам
+
+> Визуал: дашборд из карточки, очереди и графика стоимости
+
+## Слайд 14: Одна платформа — много проектов
+
+- Несколько репозиториев из одного инстанса с общей очередью
+- Внутри проекта — строгий порядок, между проектами — параллельность
+- Платформа дорабатывает сама себя тем же конвейером (self-hosting)
+- Своя доработка репетируется на песочнице и требует явного подтверждения
+
+> Визуал: один конвейер, несколько лент с разными проектами
+
+## Слайд 15: Сценарии использования
+
+- Фича за вечер: постановка → прод с двумя кликами человека
+- Пакет задач на ночь: метки авто-одобрения, утром всё на проде
+- Багфикс по короткому маршруту с обязательным регресс-тестом
+- Остановить задачу: статус STOP — безопасная отмена с уборкой
+- Несколько проектов параллельно без пересечений
+
+> Визуал: пять пиктограмм-сценариев
+
+## Слайд 16: Тираж платформы
+
+- Разворачивается на новой инфраструктуре без правки кода — только конфиг
+- Lite: у заказчика свои трекер и git — ставятся только оркестратор и сторож
+- Bundled: весь стек одним комплектом (~14 контейнеров) и бутстрап-скрипт
+- Свежие секреты, пошаговые инструкции с проверкой каждого шага
+
+> Визуал: коробка-дистрибутив в двух размерах
+
+## Слайд 17: Lite-установка скриптами
+
+- Lite — два контейнера платформы: оркестратор и сторож (watchdog) на инфраструктуре заказчика
+- Свои Plane, Gitea, Telegram и LLM заказчик подключает — в Lite они не входят
+- Разворачивается без правки кода — только конфигом (принцип «дефолт = боевое значение»)
+- Скрипты-помощники: gen_secrets.py (свежие секреты), onboard_project.py (регистрация проекта: plan / apply / verify); подъём — docker compose up -d
+- Маршрут — пошаговый runbook LITE_SETUP.md с проверкой каждого шага (PASS/FAIL)
+- Весь стек одним комплектом и одношаговым бутстрапом — это смежный вариант Bundled, не Lite
+
+> Визуал: два контейнера-кубика и чек-лист шагов с галочками
+
+## Слайд 18: Статус платформы сегодня
+
+- В проде: автономный конвейер, мультипроектность, самовосстановление
+- В проде: пакетный авто-режим, багфикс-маршрут, отмена задач, журнал уроков
+- Тираж Lite и Bundled — готовые инструкции и инструменты
+- Платформа развивает сама себя: документация и гейты растут с каждой задачей
+
+> Визуал: чек-лист способностей с отметками «в проде»
+
+## Слайд 19: Итог
+
+- Разработка без очередей между ролями: задача → прод за один проход
+- Человек принимает решения — конвейер делает работу
+- Качество держат машинные гейты, прозрачность — живая карточка и метрики
+- Следующий шаг: поставить первую задачу или развернуть платформу у себя
+
+> Визуал: тёмный финальный слайд с одной фразой-приглашением
+
+---
+
+## Как собрать .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,106 @@
+# Блок 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'ом внутри ребра. Провал любого из них — откат на доработку. Исключение
+(ORCH-110): **инфра-таймаут** локального re-test merge-gate (а не детерминированный красный тест) —
+это транзиент, а не дефект кода → ограниченный повтор + отдельный инфра-alert, без отката на
+доработку и без расхода developer-retry (красный re-test/конфликт по-прежнему откатывают). На ребре
+`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-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/14-deploy-log.md

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-011
+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-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-101/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
+
+Work Item ID: ORCH-101
+
+## Description
+
+TBD

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

@@ -0,0 +1,175 @@
+---
+work_item: ORCH-101
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Эпик **ORCH-10** (домен 📈 D5 «Масштаб», `docs/epics/self-evolution.md`, D5.3) — тираж платформы
+для раздачи **текущей** функциональности нескольким заказчикам **на тест**. Решения Славы 10.06:
+
+- **Два типа тиража, оба stateless** (наши задачи/данные НЕ переносятся, чистый старт):
+  - **Тип A (Lite):** перенос орк + watchdog на новую инфру; окружение донастраивается по чёткой
+    инструкции.
+  - **Тип B (Bundled):** весь стек (Plane/Gitea/орк) одним комплектом.
+- **ORCH-101 = 10-common** — общий фундамент **обоих** типов. Без него ни Lite, ни Bundled не поедут.
+
+**Проблема.** Платформа фактически прибита гвоздями к хосту `mva154`:
+
+1. **Хардкоды хоста/окружения.** Аудит репо (стадия analysis, см. реестр в `02-trz.md` §3.1)
+   подтвердил: в `src/**` есть код, который **обходит конфиг** — внешний URL Gitea
+   `http://git.mva154.duckdns.org` зашит в `src/plane_sync.py`, `HOME=/home/slin` и git-идентичность
+   `*@mva154.local` зашиты в трёх местах (`launcher`/`self_deploy`/`post_deploy`); в
+   `docker-compose.yml` зашиты пути `/home/slin/...`, gid docker-группы `999`, uid `1000:1000`,
+   node-пути; в `Dockerfile` — `useradd … -d /home/slin slin` и порт CMD; в
+   `scripts/orchestrator-deploy-hook.sh` — `REPO=/home/slin/repos/orchestrator`. На новом хосте
+   (другой пользователь, другие пути, другой gid docker, другие URL) платформа не заведётся без
+   правки кода — это блокер тиража.
+2. **Секреты.** Боевые секреты (`.env`) копировать на чужую инфраструктуру нельзя (общий
+   webhook-secret = чужой хост сможет слать нам валидные вебхуки; утечка токенов). Механизма
+   «сгенерировать НОВЫЙ комплект секретов на новом хосте» нет; `.env.example` не имеет чек-листа
+   «что обязан заполнить оператор».
+3. **Верификация.** Нет процедуры убедиться, что развёрнутая копия платформы **жива**: «завести
+   тестовый проект + задачу → конвейер доехал». Без неё каждый тираж — слепой деплой.
+
+**Ценность:** после ORCH-101 платформа разворачивается на новой инфре конфигурацией (env), с
+собственными секретами и проверяется воспроизводимым smoke-прогоном. Это критический путь всего
+эпика ORCH-10.
+
+## 2. Объём (scope)
+
+### В объёме
+
+1. **Расхардкод** — вынести все хардкоды хоста/окружения в конфиг/env **с дефолтами, равными
+   текущим значениям**: IP/hostname (`82.22.50.71`, `mva154`, `*.duckdns.org`), пути
+   (`/home/slin/...`, `/repos`), порты (8500/8501/3000/8091), gid docker `999`, uid `1000`, имена
+   контейнеров/сервисов/образов, URL Plane/Gitea, git-идентичность агентов. Зоны:
+   `src/**`, `watchdog/**`, `docker-compose.yml`, `Dockerfile`, `scripts/`, `.env.example`.
+   Аудит — **весь репо** (нормативный реестр находок — `02-trz.md` §3.1).
+2. **Секреты** — механизм генерации **новых** секретов на новом хосте (webhook-секреты —
+   криптослучайная генерация на месте; внешние токены Plane/Gitea/Telegram — выпуск на целевых
+   системах по чек-листу). Полный шаблон `.env.example` с плейсхолдерами + чек-лист «что заполнить».
+   Боевые секреты не покидают текущий хост.
+3. **Smoke-верификация** — документированная воспроизводимая процедура (и/или скрипт-обвязка):
+   «завести тестовый проект + задачу → конвейер доехал», с чёткими критериями PASS/FAIL.
+4. **Анти-регресс** — структурный тест (grep-тест по образцу `tests/test_agent_prompts_canon.py`),
+   запрещающий возврат хост-хардкодов в `src/**`.
+5. **Доки** — deployment-раздел (параметризация, карта новых env-ключей, чек-лист секретов,
+   smoke-процедура) + обновление карты env в `docs/operations/INFRA.md` + `CHANGELOG.md`.
+
+### Вне объёма
+
+- **Сама инструкция тиража Типа A (Lite) end-to-end** и **сборка комплекта Типа B (Bundled)** —
+  отдельные задачи эпика ORCH-10; 10-common даёт им фундамент.
+- **Перенос данных/задач/истории** — тираж stateless по решению Славы 10.06 (чистый старт).
+- **Мультитенантность** (D5.6), горизонтальный воркер-пул (D5.4), IaC-автоматизация
+  (Terraform/Ansible) — не сейчас.
+- **Изменение конвейера**: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи /
+  схема БД — не трогаются (задача конфигурационная, не процессная).
+- **Расхардкод исторических документов** `docs/**`, `memory/**`, `CHANGELOG.md` — историческая
+  правда не переписывается; аудит судит **код и инфра-файлы**, не архив.
+- **`tests/**`** — тестам разрешены литералы как фикстуры/ожидания.
+- **Onboarding-kit** (`onboarding/`, ORCH-009) — уже параметризован плейсхолдерами `{{NAME}}`;
+  правится только при необходимости согласовать новые env-ключи.
+
+## 3. Заинтересованные стороны
+
+- **Слава (Owner)** — заказчик эпика ORCH-10; принимает BRD (гейт Approved) и прод-деплой
+  (Confirm Deploy).
+- **Будущие заказчики-тестеры** — потребители тиража Типов A/B (получают платформу на своей инфре).
+- **Стрим** — оператор тиража: выполняет инструкцию, генерирует секреты, гоняет smoke.
+- **Последующие задачи эпика ORCH-10 (Lite/Bundled)** — прямые потребители фундамента.
+- **Агенты конвейера / self-hosting** — изменения катятся через общий прод-инстанс; регресс на
+  текущем хосте недопустим (обслуживает и enduro-trails).
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 (расхардкод src)** — в `src/**` и `watchdog/**` не остаётся хост-специфичных литералов
+  (IP/hostname/пути/порты/URL/идентичности), **обходящих конфиг**: каждое такое значение читается
+  из `Settings` (env `ORCH_*` / `WATCHDOG_*`) с дефолтом, равным текущему боевому значению.
+  Дефолты в `src/config.py` / `watchdog/config.py` — легитимное место значений по умолчанию.
+- **BR-2 (расхардкод инфра-файлов)** — `docker-compose.yml`, `Dockerfile`,
+  `scripts/orchestrator-deploy-hook.sh` параметризованы (compose-интерполяция `${VAR:-default}`,
+  `ARG`, env-override соответственно); без заданных переменных конфигурация резолвится в текущие
+  значения 1:1.
+- **BR-3 (секреты)** — существует механизм получения **нового** комплекта секретов на новом хосте:
+  генерируемые локально (webhook-секреты) создаются криптослучайно; выпускаемые внешними системами
+  (токены Plane/Gitea/Telegram) перечислены в чек-листе с указанием, где их выпустить.
+  `.env.example` покрывает 100% обязательных ключей. Копирование боевых секретов не требуется ни
+  на одном шаге.
+- **BR-4 (smoke)** — существует документированная воспроизводимая процедура верификации тиража:
+  «развёрнутый инстанс → тестовый проект + задача → конвейер доехал», с момента старта до явного
+  PASS/FAIL-критерия; воспроизводимость подтверждена прогоном на текущей инфре (staging-песочница
+  8501 / sandbox-проект).
+- **BR-5 (zero-regression)** — на текущем хосте поведение 1:1: все новые параметры имеют дефолты =
+  сегодняшним значениям; пустой/неизменённый `.env` даёт байт-в-байт текущее поведение; полный
+  `pytest tests/ -q` зелёный.
+- **BR-6 (анти-регресс)** — возврат хост-хардкода в `src/**` ломает CI: структурный тест
+  сканирует код (вне комментариев/докстрингов) на запрещённые литералы.
+- **BR-7 (доки)** — deployment-раздел + карта env + чек-лист секретов + smoke-процедура
+  опубликованы в `docs/operations/`; `CHANGELOG.md` обновлён (правило агентов №2).
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 (self-hosting safety)** — задача не перезапускает и не роняет прод-контейнер
+  `orchestrator`; правки `docker-compose.yml`/`Dockerfile` инертны до следующего штатного деплоя
+  через конвейер (staging 8501 → Confirm Deploy). Никаких push/force-push в `main` мимо PR.
+- **NFR-2 (обратимость)** — «kill-switch природа» параметризации: отсутствие новых env-переменных
+  = текущее поведение. Отдельный функциональный kill-switch не требуется — дефолты и есть откат.
+- **NFR-3 (секреты вне гита)** — реальные значения только в `.env`/`.env.staging` на хосте
+  (правило агентов №8); в гит попадают только шаблоны/плейсхолдеры; генератор секретов никогда не
+  перезаписывает существующий `.env` молча.
+- **NFR-4 (инварианты соседних задач, правило №9)** — параметризация не ослабляет зафиксированные
+  инварианты: ORCH-058 «freshness-путь целится ТОЛЬКО в staging, никогда в прод 8500»; ORCH-040
+  «uid 1000 + group_add 999 (МИНА 1 — не удалять) + HOME согласован с маунтами»; INV-4 «мерж только
+  через Gitea PR-merge API». Затронутые маркеры читаются перед правкой.
+- **NFR-5 (стабильность анти-регресс теста)** — grep-тест детерминирован и не флапает: судит код,
+  исключает комментарии/докстринги/`tests/**`/`docs/**`; список запрещённых литералов
+  централизован в самом тесте.
+- **NFR-6 (конвейер не трогаем)** — `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`,
+  machine-verdict ключи, схема БД — байт-в-байт прежние.
+
+## 6. Допущения и ограничения
+
+- Целевой хост тиража: Linux + Docker + Compose; Plane и Gitea доступны (для Типа A — донастройка
+  по инструкции Lite-задачи; их URL/токены подаются через env). Claude CLI присутствует на хосте
+  (пути маунтов параметризуются).
+- Тираж — **single-tenant**: один инстанс платформы на заказчика; общая мультитенантная топология
+  вне объёма.
+- Имя self-hosting репо платформы (`orchestrator`) — платформенная конвенция; делать ли его
+  конфигурируемым (`SELF_HOSTING_REPO`) — решение архитектора (см. `02-trz.md` §3.4, вопрос А-2).
+- Встроенный fallback-реестр проектов (`src/projects.py::_DEFAULT_PROJECTS`) содержит UUID'ы Plane
+  текущего хоста; на новом хосте обязателен `ORCH_PROJECTS_JSON` — фиксируется в чек-листе, сами
+  UUID'ы в дефолте безвредны (не сматчатся) и остаются как документированный fallback.
+- Историческая документация и комментарии кода могут упоминать `mva154`/пути — это не хардкоды
+  поведения и аудитом кода не считаются.
+
+## 7. Критерии успеха
+
+Платформа разворачивается на чужой инфре **без правки кода** — только env/конфиг; секреты
+выпускаются заново по чек-листу; smoke-прогон даёт явный PASS; на текущем хосте — ноль изменений
+поведения и зелёный полный регресс. Детальные условия PASS/FAIL — `03-acceptance-criteria.md`
+(AC-1…AC-8); прослеживаемость BR ↔ AC — в сводной матрице там же.
+
+## 8. Риски
+
+Кратко (детально — `10-tech-risks.md`, заполняет архитектор):
+
+- **Р-1: скрытый регресс при параметризации горячих путей** (`launcher` env агентов, compose
+  volumes) — митигируется дефолтами = текущим значениям + полным регрессом + staging-прогоном.
+- **Р-2: ослабление инварианта ORCH-058** при конфигуризации staging-порта (`_STAGING_PORT`) —
+  митигируется guard-условием «staging-порт ≠ прод-порт» и решением архитектора (возможно,
+  оставить константой с обоснованием).
+- **Р-3: флап анти-регресс grep-теста** (ложные срабатывания на комментарии) — митигируется
+  правилами исключений NFR-5.
+- **Р-4: неполный аудит** (пропущенный хардкод всплывает на первом реальном тираже) — митигируется
+  нормативным реестром §3.1 ТЗ + smoke-процедурой как последней линией обнаружения.
+- **Р-5: расползание скоупа в Lite/Bundled** — митигируется явным «вне объёма» §2.

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

@@ -0,0 +1,253 @@
+---
+work_item: ORCH-101
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты), выведено из BRD и
+> фактического кода (аудит выполнен по репо на ветке задачи). **Как** (точные имена новых
+> конфиг-ключей, механика генератора секретов, форма smoke-скрипта) — решает архитектор в `06-adr/`.
+
+---
+
+## 1. Сводка изменения
+
+Три слоя одного фундамента тиража (эпик ORCH-10, оба типа A/B):
+
+1. **Расхардкод:** все хост-специфичные значения, которые сегодня **обходят конфиг** (зашиты в код
+   `src/**`, в `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh`),
+   переводятся на чтение из `Settings` (env `ORCH_*`) / compose-интерполяцию `${VAR:-default}` /
+   `ARG` / env-override — **с дефолтами, равными текущим боевым значениям** (zero-regression).
+   Нормативный реестр находок — §3.1 (результат аудита всего репо).
+2. **Секреты:** механизм выпуска **нового** комплекта секретов на новом хосте (генерация
+   webhook-секретов + чек-лист внешних токенов) + полнота `.env.example`.
+3. **Smoke:** документированная воспроизводимая процедура «тестовый проект + задача → конвейер
+   доехал» с PASS/FAIL-критериями (+ анти-регресс grep-тест против возврата хардкодов).
+
+Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/verdict-ключи/схема БД) — не меняется.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `src/config.py` | изменить: новые `Settings`-ключи (HOME агент-процессов, git-идентичность акторов, внешний Gitea-URL уже есть — `gitea_public_url`; прочее по §3.1), дефолты = текущим значениям |
+| `src/plane_sync.py` | изменить: `notify_stage_change` — убрать литерал `gitea_base = "http://git.mva154.duckdns.org"` и owner `admin` из путей ссылок → `settings.gitea_public_url` (fallback `gitea_url`) + `settings.gitea_owner` |
+| `src/agents/launcher.py` | изменить: env агент-процесса (×2 места) — `HOME` и git author/committer (`claude-bot@mva154.local`) из конфига |
+| `src/self_deploy.py` | изменить: env detached-процесса — `HOME`, `deploy-finalizer@mva154.local` из конфига |
+| `src/post_deploy.py` | изменить: env монитора — `HOME`, `post-deploy-monitor@mva154.local` из конфига |
+| `src/image_freshness.py` | изменить ИЛИ обосновать: `_STAGING_PORT = 8501` (см. §3.4 А-1, инвариант ORCH-058) |
+| `src/qg/checks.py` | изменить ИЛИ обосновать: `SELF_HOSTING_REPO = "orchestrator"` (см. §3.4 А-2) |
+| `src/fs_normalize.py` | изменить: fallback-подсказку `sudo chown -R 1000:1000 /repos/_wt` строить из `settings` (uid/worktrees_dir) |
+| `src/projects.py` | не менять логику; `_DEFAULT_PROJECTS` остаётся документированным fallback (UUID'ы чужого Plane безвредны); фиксация в чек-листе «на новом хосте обязателен `ORCH_PROJECTS_JSON`» |
+| `watchdog/config.py` | проверить/синхронизировать: уже env-driven (`WATCHDOG_*`); дефолт `http://127.0.0.1:8500/metrics` согласовать с параметризацией прод-порта |
+| `docker-compose.yml` | изменить: интерполяция `${VAR:-default}` для всех хост-значений (§3.1 B) |
+| `Dockerfile` | изменить: `ARG` для uid/gid/username/home; CMD-порт — по решению архитектора (§3.4 А-3) |
+| `scripts/orchestrator-deploy-hook.sh` | изменить: `REPO=/home/slin/repos/orchestrator` → env-override `REPO="${REPO:-…}"` |
+| `scripts/` (новый) | создать: генератор секретов и/или smoke-обвязка — форма за архитектором (§3.2, §3.3) |
+| `.env.example` | изменить: новые ключи, секции секретов с плейсхолдерами, чек-лист «что заполнить» |
+| `.env.staging.example` | изменить: согласовать с новыми ключами (при необходимости) |
+| `tests/test_no_host_hardcodes.py` (новый) | создать: структурный анти-регресс grep-тест (FR-8) |
+| `tests/` (новые) | создать: тесты параметризации/секретов/smoke по `04-test-plan.yaml` |
+| `docs/operations/` | создать deployment-раздел тиража (предложение: `REPLICATION.md`; имя финализирует архитектор) + обновить карту env в `INFRA.md` |
+| `CHANGELOG.md`, `CLAUDE.md`, `README.md` | изменить: запись изменения; паспорт/обзорные доки — по фактическому объёму (правило агентов №2/№6) |
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Нормативный реестр хардкодов (результат аудита) и их устранение
+
+Привязка: BR-1, BR-2. Аудит выполнен по всему репо (grep по классам: IP/hostname, пути, порты,
+gid/uid, URL, идентичности). Реестр ниже **нормативен**: developer закрывает каждую строку;
+расхождение «нашёл ещё» — дополняет реестр в PR, а не игнорирует.
+
+#### 3.1. Реестр
+
+**A. `src/**` / `watchdog/**` — код, обходящий конфиг (блокеры AC-1):**
+
+| # | Файл:строка | Хардкод | Требование |
+|---|---|---|---|
+| A1 | `src/plane_sync.py:1064` | `gitea_base = "http://git.mva154.duckdns.org"` в `notify_stage_change` + owner `admin` в построении ссылок Branch/PR | читать `settings.gitea_public_url` (fallback `settings.gitea_url`; loopback-семантика — как в `notifications._build_plane_issue_link`) + `settings.gitea_owner`; никаких новых ключей не требуется |
+| A2 | `src/agents/launcher.py:594, 825` | `"HOME": "/home/slin"`; `GIT_AUTHOR/COMMITTER_EMAIL: claude-bot@mva154.local` (×2 места) | HOME и git-идентичность из конфига (новые ключи, дефолты = текущим значениям) |
+| A3 | `src/self_deploy.py:332–336` | `"HOME": "/home/slin"`; `deploy-finalizer@mva154.local` | то же (единый источник с A2; имя актора может остаться per-actor) |
+| A4 | `src/post_deploy.py:575–579` | `"HOME": "/home/slin"`; `post-deploy-monitor@mva154.local` | то же |
+| A5 | `src/image_freshness.py:61` | `_STAGING_PORT = 8501` (модульная константа; намеренный анти-prod-инвариант ORCH-058 AC-9) | конфигуризовать с дефолтом 8501 **с сохранением инварианта** (guard «staging-порт ≠ прод-порт») ИЛИ оставить константой с явным обоснованием в ADR — решение архитектора (§3.4 А-1) |
+| A6 | `src/qg/checks.py:517` | `SELF_HOSTING_REPO = "orchestrator"` (узел: на него опираются все `*_repos`-leaf'ы «empty CSV → self-hosting only») | конфиг-ключ с дефолтом `orchestrator` ИЛИ нормативная платформенная константа («репо платформы в тираже обязан называться `orchestrator`», фиксируется в deployment-доке) — решение архитектора (§3.4 А-2) |
+| A7 | `src/fs_normalize.py:539` | fallback-строка подсказки `sudo chown -R 1000:1000 /repos/_wt` | строить из `settings.fs_target_uid` / `settings.worktrees_dir` (соседние строки 533–535 уже так делают) |
+| A8 | `src/disk_watchdog.py:95` | fallback `["/repos", "/app/data"]` — зеркало дефолта `settings.disk_monitor_paths` | допустимое config-backed зеркало; не блокер. Требование: значения остаются синхронными с конфиг-дефолтом (одна точка истины желательна — на усмотрение архитектора) |
+| A9 | `src/projects.py:42–55` | `_DEFAULT_PROJECTS`: UUID'ы Plane текущего хоста | НЕ блокер (документированный fallback «out of the box», чужие UUID не сматчатся). Требование: чек-лист тиража обязывает задать `ORCH_PROJECTS_JSON` |
+| A10 | `watchdog/config.py:100,144` | дефолт `http://127.0.0.1:8500/metrics` | уже env-driven (`WATCHDOG_METRICS_URL`); дефолт легитимен; согласовать с А-3 (прод-порт), если тот станет параметром |
+
+> Паттерн `getattr(settings, "x", <литерал>)` (A7/A8 и др.) — **config-backed fallback**, не
+> хардкод-блокер: значение управляется конфигом. Блокер — только код, который конфиг **обходит**.
+
+**B. `docker-compose.yml` — хост-специфика (блокеры AC-6):**
+
+| # | Место | Хардкод |
+|---|---|---|
+| B1 | volumes ×3 сервисов | `/home/slin/repos:/repos`(+`:ro`), `/home/slin/.claude`, `/home/slin/.claude.json`, `/home/slin/.orchestrator-ssh:/home/slin/.ssh` |
+| B2 | volumes ×2 сервисов | `/usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro`, `/usr/bin/node:/usr/bin/node:ro` |
+| B3 | `group_add` ×3 | `"999"` (gid docker-группы хоста) |
+| B4 | `user:` ×2 | `"1000:1000"` (uid:gid хоста) |
+| B5 | environment | `ORCH_HOST_REPOS_DIR=/home/slin/repos` ×2, `ORCH_DEPLOY_HOST_REPO_PATH=/home/slin/repos/orchestrator`, `DEPLOY_SSH_USER=slin` ×2, `ORCH_DEPLOY_SSH_USER=slin`, `DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh` ×2 (legacy enduro) |
+| B6 | `orchestrator-staging.command` | порт `8501` |
+
+Требование: compose-интерполяция `${VAR:-default}` (источник — `.env`, штатный механизм Compose);
+`docker compose config` без заданных переменных резолвится в текущие значения 1:1. Целевая
+семантика «HOME внутри контейнера согласован с маунтами `.claude`/`.ssh` и `useradd` Dockerfile»
+(инвариант ORCH-040) сохраняется как согласованная группа переменных.
+
+**C. `Dockerfile`:**
+
+| # | Место | Хардкод |
+|---|---|---|
+| C1 | `useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bash slin` | uid/gid/home/username |
+| C2 | `CMD … --port 8500` | прод-порт |
+
+Требование: C1 → `ARG` с дефолтами (1000/1000//home/slin/slin). C2 — по решению архитектора
+(§3.4 А-3): порт уже переопределяем через compose `command:`; допустимо оставить CMD-дефолт 8500.
+
+**D. `scripts/`:**
+
+| # | Место | Хардкод |
+|---|---|---|
+| D1 | `orchestrator-deploy-hook.sh:38` | `REPO=/home/slin/repos/orchestrator` (единственный непараметризованный путь скрипта; остальное уже env-override) |
+
+Требование: `REPO="${REPO:-/home/slin/repos/orchestrator}"` (паттерн остальных переменных скрипта).
+`scripts/staging_check.py` — уже env-driven (`ORCH_PLANE_API_URL`/`ORCH_GITEA_URL`/`--base-url`),
+изменений не требует.
+
+**E. Уже параметризовано (НЕ трогать, фиксация аудита):** дефолты `src/config.py`
+(`plane_api_url:8091`, `gitea_url:3000`, `repos_dir`, `host_repos_dir`, `worktrees_dir`, `runs_dir`,
+`db_path`, `deploy_ssh_user`, `deploy_host_repo_path`, `deploy_prod_target_port:8500`,
+`post_deploy_base_url`, `disk_monitor_paths`, `claude_bin`) — легитимные значения по умолчанию,
+управляемые env; менять их значения запрещено (BR-5).
+
+### FR-2 — Чтение хост-значений из конфига в `src/**`
+
+Привязка: BR-1. Каждый блокер класса A (A1–A4, A7; A5/A6 — по исходу §3.4) читает значение через
+`settings` (существующие либо новые ключи `Settings` с env `ORCH_*`). Требования к новым ключам:
+
+- дефолт = текущее боевое значение (BR-5): `/home/slin`, `claude-bot`, `*@mva154.local`-адреса;
+- описательный комментарий в `config.py` по образцу существующих блоков (назначение + env-имя);
+- ключи отражены в `.env.example` и карте env `INFRA.md`;
+- точные имена ключей и группировка (например, единый `agent_home_dir` + per-actor идентичности
+  или общий email-домен) — решение архитектора; ТЗ фиксирует контракт: **ни один из пяти акторов
+  (агенты CLI ×2 места, self-deploy finalizer, post-deploy monitor, fs-подсказка) не содержит
+  литералов `/home/slin` / `mva154` после изменения**.
+
+### FR-3 — Параметризация инфра-файлов
+
+Привязка: BR-2. Реестр B/C/D закрыт; механика — compose-интерполяция / `ARG` / shell-default.
+Инварианты: ORCH-040 (uid 1000 + `group_add` docker-gid + HOME-согласованность маунтов — группа
+переменных меняется согласованно, «МИНА 1» `group_add` не удаляется), ORCH-058 (staging-сервис
+никогда не резолвится в прод-таргет). Поведение `docker compose config` при пустом окружении —
+эквивалент текущего файла (проверяется тестом TC-06).
+
+### FR-4 — Механизм секретов нового хоста
+
+Привязка: BR-3. Состав:
+
+1. **Инвентаризация** (фиксация аудита): генерируемые локально — `ORCH_PLANE_WEBHOOK_SECRET`,
+   `ORCH_GITEA_WEBHOOK_SECRET`; выпускаемые внешними системами — `ORCH_PLANE_API_TOKEN`,
+   `ORCH_PLANE_BOT_*` (7 шт., опциональны: fallback на `ORCH_PLANE_API_TOKEN`), `ORCH_GITEA_TOKEN`,
+   `ORCH_TELEGRAM_BOT_TOKEN` (+ несекретный `ORCH_TELEGRAM_CHAT_ID`).
+2. **Генерация:** webhook-секреты создаются криптослучайно (стандарт: `secrets`-модуль Python /
+   эквивалент, длина ≥ 32 байт энтропии) на целевом хосте; форма (отдельный
+   `scripts/gen_secrets.py`, режим onboarding-CLI или документированная команда) — решение
+   архитектора. Требования к поведению: повторный запуск даёт другие значения; существующий `.env`
+   никогда не перезаписывается молча (NFR-3); вывод согласован с ключами `.env.example`.
+3. **Чек-лист** в deployment-доке: для каждого секрета — где выпустить (Plane UI/API, Gitea UI,
+   BotFather), куда вписать, как проверить. Явное правило: «боевые секреты текущего хоста не
+   копируются».
+4. **Полнота `.env.example`:** каждый обязательный для старта ключ присутствует (с плейсхолдером
+   или дефолтом), включая новые ключи FR-2/FR-3; секретные значения — только плейсхолдеры.
+
+### FR-5 — Smoke-верификация тиража
+
+Привязка: BR-4. Документированная процедура (deployment-раздел) + опциональная скрипт-обвязка
+(форма — архитектор; кандидаты-кирпичи уже в репо: `scripts/onboard_project.py` `plan/apply/verify`,
+`scripts/staging_check.py`, `GET /health` / `/queue` / `/metrics`):
+
+1. **Шаги:** поднять инстанс (env+секреты заполнены) → `GET /health` ок → завести тестовый
+   проект (onboarding-CLI `verify` или sandbox-проект) → создать тестовую задачу → убедиться, что
+   конвейер «доехал» (задача продвигается по стадиям; минимальный обязательный сигнал — стадия
+   `analysis` отработала и артефакты `01–04` созданы; полный прогон до `done` — расширенный режим).
+2. **Критерии:** каждый шаг имеет явный PASS/FAIL; итог процедуры — однозначный вердикт.
+3. **Воспроизводимость:** процедура прогоняется на текущей инфре (staging-песочница 8501 +
+   sandbox-проект) без нового железа — это и приёмочная проверка AC-3.
+4. **Stateless:** процедура нигде не предполагает перенос данных/БД с боевого хоста.
+
+### FR-6 — Анти-регресс структурный тест
+
+Привязка: BR-6. Новый `tests/test_no_host_hardcodes.py` (образец — `tests/test_agent_prompts_canon.py`):
+
+- сканирует `src/**/*.py` и `watchdog/**/*.py` на запрещённые литералы: `82.22.50.71`,
+  `/home/slin`, `mva154`, `duckdns` (список централизован в тесте; расширяем);
+- судит **код**: строки-комментарии и докстринги исключаются (NFR-5; механика исключения —
+  прагматичная построчная/AST — за developer);
+- `tests/**`, `docs/**`, `.env.example` — вне зоны сканирования;
+- допускает точечный явный allowlist (файл:литерал) с комментарием-обоснованием — пустой на
+  момент сдачи задачи (все блокеры A закрыты).
+
+### FR-7 — Документация
+
+Привязка: BR-7. Deployment-раздел в `docs/operations/` (предложение: `REPLICATION.md`): карта
+новых env-переменных (включая compose-интерполяцию), процедура секретов (FR-4), smoke-процедура
+(FR-5), границы «10-common vs Lite vs Bundled». Обновления: `INFRA.md` (карта env),
+`CHANGELOG.md`; `CLAUDE.md`/`README.md` — по фактическому объёму изменений (правило №2/№6).
+
+---
+
+### 3.4. Вопросы архитектору (решаются в `06-adr/`, не в ТЗ)
+
+- **А-1:** `_STAGING_PORT = 8501` (`image_freshness`) — конфиг-ключ с guard'ом «≠ прод-порт» или
+  нормативная константа? Инвариант ORCH-058 AC-9 («никогда не прод 8500») обязан сохраниться.
+- **А-2:** `SELF_HOSTING_REPO = "orchestrator"` — конфиг-ключ или платформенная конвенция тиража
+  (репо платформы всегда `orchestrator`)? На него завязаны все `*_repos`-leaf'ы.
+- **А-3:** CMD-порт Dockerfile (8500) — `ARG` или остаётся (порт уже переопределяем compose
+  `command:`)?
+- **А-4:** форма генератора секретов (отдельный скрипт / режим `onboard_project.py` /
+  документированная команда) и форма smoke (чистый runbook / runbook + скрипт).
+- **А-5:** группировка новых конфиг-ключей FR-2 (единый HOME-ключ + per-actor email'ы vs общий
+  email-домен).
+
+---
+
+## 4. Изменения API
+
+Нет. Существующие эндпоинты (`/health`, `/queue`, `/metrics`) переиспользуются smoke-процедурой
+read-only; новые эндпоинты не вводятся.
+
+## 5. Изменения схемы БД
+
+Нет.
+
+## 6. Требования к новым/изменённым QG checks
+
+Нет. `QG_CHECKS`/`check_*`/machine-verdict ключи не меняются. Новый структурный тест (FR-6) —
+обычный pytest: попадает в существующие гейты `check_ci_green`/`check_tests_passed`/merge-gate
+re-test автоматически, без регистрации нового QG.
+
+## 7. Совместимость / регресс
+
+- **Zero-regression (BR-5):** все новые параметры — с дефолтами, равными сегодняшним боевым
+  значениям; пустой/неизменённый `.env` ⇒ байт-в-байт текущее поведение; `docker compose config`
+  без переменных ⇒ эквивалент текущего файла. Полный `pytest tests/ -q` зелёный.
+- **Обратимость (NFR-2):** откат = не задавать новые переменные. Функциональный kill-switch не
+  требуется (дефолты и есть прежнее поведение); вводить новый флаг ради флага запрещено.
+- **Область раската:** изменения инертны для enduro-trails (значения те же); compose/Dockerfile
+  вступают в силу только при следующем штатном деплое через конвейер (staging 8501 → ручной
+  Confirm Deploy) — прод-контейнер в рамках задачи не рестартуется (NFR-1).
+- **Инварианты соседних маркеров (правило №9):** ORCH-040 (uid/gid/HOME/«МИНА 1»), ORCH-058
+  (freshness → только staging), ORCH-036/059 (self-deploy фазы, Confirm Deploy), INV-4 (мерж только
+  через PR-merge API) — сохраняются; соответствующие ADR прочитаны при правке помеченных блоков.

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

@@ -0,0 +1,131 @@
+---
+work_item: ORCH-101
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория. AC-1…AC-4 — дословно из бизнес-запроса (уточнены до проверяемости); AC-5…AC-8 —
+детализация скоупа (секреты/инфра/анти-регресс/инварианты).
+
+---
+
+## AC-1 — Ноль хардкодов хоста/путей/портов в `src/**`
+
+**Условие:** в коде `src/**` и `watchdog/**` (вне комментариев/докстрингов) нет хост-специфичных
+литералов, обходящих конфиг; всё читается из env/конфига с дефолтами. Проверка — grep-тестом
+(`tests/test_no_host_hardcodes.py`) и ревью по реестру `02-trz.md` §3.1.
+- **PASS:**
+  - блокеры A1–A4, A7 реестра закрыты: `grep -rn "git.mva154.duckdns.org\|/home/slin\|mva154.local" src/ watchdog/` не находит ни одного вхождения в исполняемом коде (докстринги/комментарии — допустимы);
+  - `src/plane_sync.py::notify_stage_change` строит ссылки Branch/PR из `settings.gitea_public_url` (fallback `gitea_url`) и `settings.gitea_owner`;
+  - env-словари акторов (`launcher` ×2, `self_deploy`, `post_deploy`) берут HOME и git-идентичность из `settings`;
+  - A5 (`_STAGING_PORT`) и A6 (`SELF_HOSTING_REPO`) либо конфигуризованы, либо явно обоснованы в ADR задачи как платформенные константы (решение архитектора зафиксировано);
+  - структурный тест `tests/test_no_host_hardcodes.py` существует, его allowlist пуст (или каждая запись обоснована комментарием), тест зелёный.
+- **FAIL:** хотя бы один литерал `82.22.50.71` / `/home/slin` / `mva154` / `duckdns` в исполняемом коде `src/**`/`watchdog/**`; ИЛИ ссылка в Plane-комментарии всё ещё строится от захардкоженного `http://git.mva154.duckdns.org`; ИЛИ A5/A6 не конфигуризованы и не обоснованы в ADR; ИЛИ анти-регресс тест отсутствует/красный.
+
+---
+
+## AC-2 — Без регресса: на текущем хосте поведение 1:1
+
+**Условие:** дефолты всех новых параметров равны текущим боевым значениям; pytest зелёный.
+- **PASS:**
+  - каждый новый `Settings`-ключ / compose-переменная / `ARG` / shell-default имеет дефолт, равный значению, зашитому до задачи (`/home/slin`, `claude-bot@mva154.local`-адреса, gid 999, uid 1000, порты 8500/8501, пути node/claude-code и т.д.);
+  - `docker compose config` без заданных переменных окружения резолвится в эквивалент текущей конфигурации (volumes/user/group_add/environment/command совпадают по значениям);
+  - значения существующих дефолтов `src/config.py` (реестр §3.1 E) не изменены;
+  - полный `pytest tests/ -q` зелёный;
+  - `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — без изменений (диф не затрагивает их семантику).
+- **FAIL:** хотя бы один дефолт отличается от текущего боевого значения; ИЛИ `docker compose config` при пустом окружении даёт иную эффективную конфигурацию; ИЛИ любой существующий тест красный; ИЛИ диф меняет машину стадий/реестр QG/схему БД.
+
+---
+
+## AC-3 — Smoke-процедура задокументирована и воспроизводима
+
+**Условие:** существует документированная процедура «развёрнутый инстанс → тестовый проект +
+задача → конвейер доехал» с явными PASS/FAIL-критериями; воспроизводимость подтверждена.
+- **PASS:**
+  - в `docs/operations/` есть раздел/документ (предложение ТЗ: `REPLICATION.md`) с пошаговой smoke-процедурой: health-check инстанса → тестовый проект → тестовая задача → подтверждение продвижения конвейера (минимум: `analysis` отработала, артефакты `01–04` созданы; расширенный режим — до `done`);
+  - каждый шаг имеет явный ожидаемый результат (PASS/FAIL), итог — однозначный вердикт;
+  - процедура не требует переноса данных/секретов с боевого хоста (stateless);
+  - воспроизводимость подтверждена хотя бы одним прогоном на текущей инфре (staging-песочница 8501 / sandbox-проект) — результат зафиксирован в артефактах задачи (например, `13-test-report.md` / `15-staging-log.md`);
+  - если введена скрипт-обвязка (`scripts/…`) — она запускается (`--help`/dry-run без ошибок) и покрыта тестом из `04-test-plan.yaml`.
+- **FAIL:** процедуры нет; ИЛИ шаги без явных критериев («посмотреть, что всё ок»); ИЛИ процедура требует копирования боевых данных/секретов; ИЛИ заявленный прогон не зафиксирован; ИЛИ скрипт-обвязка падает на запуске.
+
+---
+
+## AC-4 — Доки (deployment-раздел) + CHANGELOG
+
+**Условие:** документация обновлена в том же PR (правило агентов №2; reviewer проверяет — №6).
+- **PASS:**
+  - deployment-раздел (см. AC-3) дополнительно содержит: карту всех новых env-переменных (имя, назначение, дефолт), процедуру/чек-лист секретов (см. AC-5), границы «10-common vs Lite vs Bundled»;
+  - карта переменных окружения в `docs/operations/INFRA.md` дополнена новыми ключами;
+  - `CHANGELOG.md` содержит запись ORCH-101;
+  - `CLAUDE.md`/`README.md` обновлены, если фактический объём изменений того требует (новые операторские способности/ограничения).
+- **FAIL:** новый env-ключ отсутствует в карте env; ИЛИ нет записи в `CHANGELOG.md`; ИЛИ deployment-раздел не покрывает секреты/smoke; ИЛИ README выдаёт решённое за открытое (правило №6).
+
+---
+
+## AC-5 — Секреты: генерация новых, не копирование боевых
+
+**Условие:** механизм выпуска нового комплекта секретов на новом хосте существует и безопасен.
+- **PASS:**
+  - webhook-секреты (`ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET`) генерируются криптослучайно (≥ 32 байт энтропии; повторный запуск даёт другие значения);
+  - механизм никогда не перезаписывает существующий `.env` молча;
+  - чек-лист перечисляет все внешние токены (`ORCH_PLANE_API_TOKEN`, `ORCH_PLANE_BOT_*`, `ORCH_GITEA_TOKEN`, `ORCH_TELEGRAM_BOT_TOKEN`) с указанием, где их выпустить и куда вписать; явно сказано «боевые секреты не копируются»;
+  - `.env.example` покрывает 100% ключей, обязательных для старта (включая новые из AC-1/AC-2), секретные значения — только плейсхолдеры; реальные секреты в гит не попадают (`.gitleaks`/security-гейт зелёный);
+  - `.env.staging.example` согласован (если затронут).
+- **FAIL:** секрет генерируется детерминированно/слабо; ИЛИ запуск механизма затирает существующий `.env`; ИЛИ в `.env.example` отсутствует обязательный ключ; ИЛИ в гит закоммичено реальное секретное значение; ИЛИ процедура предписывает копирование боевого секрета.
+
+---
+
+## AC-6 — Инфра-файлы параметризованы
+
+**Условие:** `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh` не требуют
+правки под новый хост — только переменные.
+- **PASS:**
+  - реестр §3.1 B/C/D закрыт: пути `/home/slin/...`, gid `999`, uid `1000:1000`, node/claude-code-пути, ssh-user, staging-порт в `command:`, `REPO=` в deploy-hook — параметризованы (`${VAR:-default}` / `ARG` / `"${REPO:-…}"`) с дефолтами = текущим значениям;
+  - связка «uid/gid/HOME/маунты `.claude`+`.ssh`/`useradd`» меняется согласованной группой переменных (инвариант ORCH-040 сохранён, `group_add` docker-gid не удалён);
+  - структурный тест параметризации (TC-06/TC-12 из `04-test-plan.yaml`) зелёный.
+- **FAIL:** хотя бы одно значение реестра B/C/D осталось непараметризованным; ИЛИ группа ORCH-040 рассогласована (HOME ≠ маунт-таргеты при дефолтах); ИЛИ `group_add` удалён; ИЛИ структурный тест красный.
+
+---
+
+## AC-7 — Анти-регресс защита от возврата хардкодов
+
+**Условие:** возврат хост-хардкода в `src/**` ломает CI.
+- **PASS:** `tests/test_no_host_hardcodes.py` существует; сканирует `src/**`+`watchdog/**` на централизованный список запрещённых литералов (минимум: `82.22.50.71`, `/home/slin`, `mva154`, `duckdns`); исключает комментарии/докстринги/`tests/**`/`docs/**`; детерминирован (повторные прогоны стабильны); демонстрационно ловит подсадку литерала (негативная самопроверка в самом тесте или в тестах теста).
+- **FAIL:** тест отсутствует; ИЛИ не ловит подсаженный в код литерал из списка; ИЛИ флапает; ИЛИ список литералов размазан по нескольким местам без единой точки правки.
+
+---
+
+## AC-8 — Self-hosting безопасность и инварианты соседних задач
+
+**Условие:** задача не дестабилизирует общий прод и не ослабляет зафиксированные инварианты.
+- **PASS:**
+  - в рамках задачи прод-контейнер `orchestrator` не перезапускается; прод-деплой — только штатно (staging 8501 → ручной `Confirm Deploy`);
+  - инвариант ORCH-058 сохранён: freshness/staging-путь не может быть переконфигурирован в прод-таргет (guard «staging-порт ≠ прод-порт» при конфигуризации A5 — либо A5 остался константой по ADR);
+  - INV-4 сохранён (никаких push/force-push в `main` мимо PR-merge API);
+  - маркеры `ORCH-NNN` в правленых блоках сохранены/обновлены корректно (правило №9).
+- **FAIL:** диф содержит рестарт/останов прод-контейнера вне штатного деплой-пути; ИЛИ конфигурацией можно нацелить staging-rebuild на прод-порт; ИЛИ нарушен INV-4; ИЛИ правка помеченного блока стёрла инвариант соседнего ADR.
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1, FR-2, FR-6 |
+| AC-2 | BR-5 / FR-1 (реестр E), FR-2, FR-3, NFR-6 |
+| AC-3 | BR-4 / FR-5 |
+| AC-4 | BR-7 / FR-7 |
+| AC-5 | BR-3 / FR-4, NFR-3 |
+| AC-6 | BR-2 / FR-3, NFR-4 |
+| AC-7 | BR-6 / FR-6, NFR-5 |
+| AC-8 | NFR-1, NFR-2, NFR-4 / FR-3 |

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

@@ -0,0 +1,146 @@
+work_item: ORCH-101
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "ORCH-10-common: расхардкод + секреты + smoke — план тестов"
+framework: pytest
+scope: >
+  Покрывается: расхардкод src/**+watchdog/** (чтение хост-значений из Settings),
+  параметризация docker-compose.yml/Dockerfile/deploy-hook (структурные проверки),
+  полнота .env.example, поведение генератора секретов, запускаемость smoke-обвязки,
+  анти-регресс grep-тест и его негативная самопроверка, zero-regression (полный
+  регресс tests/). Вне покрытия: реальный e2e-тираж на новом железе (заменён
+  воспроизводимым прогоном smoke-процедуры на staging-песочнице 8501 — AC-3),
+  задачи Lite/Bundled эпика ORCH-10, перенос данных (stateless по решению 10.06).
+notes: >
+  Имена новых тест-модулей — предложение analyst; developer может переименовать,
+  сохранив покрытие TC. Дефолты всех новых параметров обязаны равняться текущим
+  боевым значениям (AC-2) — тесты фиксируют это явно. Анти-регресс тест судит
+  исполняемый код (комментарии/докстринги исключены) — образец структурных тестов:
+  tests/test_agent_prompts_canon.py. Полный регресс tests/ должен оставаться
+  зелёным; STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict не меняются —
+  новые тесты входят в существующие гейты (check_ci_green) автоматически.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: >
+      Анти-регресс скан: в исполняемом коде src/** и watchdog/** нет запрещённых
+      литералов (82.22.50.71, /home/slin, mva154, duckdns); комментарии/докстринги
+      исключаются; список литералов централизован; allowlist пуст либо каждая
+      запись обоснована (AC-1, AC-7 / FR-6).
+    module: tests/test_no_host_hardcodes.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      Негативная самопроверка сканера: подсаженный во временный/фиктивный модуль
+      запрещённый литерал детектируется (сканер реально ловит, не вечно-зелёный)
+      (AC-7 / FR-6, NFR-5).
+    module: tests/test_no_host_hardcodes.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      plane_sync.notify_stage_change строит ссылки Branch/PR из
+      settings.gitea_public_url (fallback gitea_url) + settings.gitea_owner;
+      литерал git.mva154.duckdns.org и owner admin из кода удалены; при
+      переопределённых настройках ссылка меняется соответственно (monkeypatch,
+      без сети) (AC-1 / FR-1 A1, FR-2).
+    module: tests/test_host_config_keys.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      Env агент-процесса в agents/launcher (оба места запуска): HOME и
+      GIT_AUTHOR/COMMITTER_NAME/EMAIL берутся из settings; дефолты равны прежним
+      значениям (/home/slin, claude-bot@mva154.local); переопределение env-ключей
+      меняет словарь окружения (AC-1, AC-2 / FR-1 A2, FR-2).
+    module: tests/test_host_config_keys.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      Env self_deploy (deploy-finalizer) и post_deploy (monitor): HOME и
+      git-идентичность из settings, дефолты = прежним значениям; литералы
+      /home/slin и *@mva154.local из кода удалены (AC-1, AC-2 / FR-1 A3–A4, FR-2).
+    module: tests/test_host_config_keys.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Структурная проверка docker-compose.yml: хост-значения реестра ТЗ §3.1 B
+      (пути /home/slin/*, node/claude-code-пути, gid 999, uid 1000:1000, ssh-user,
+      staging-порт в command) выражены интерполяцией ${VAR:-default}, и дефолты
+      равны текущим значениям; group_add docker-gid присутствует во всех трёх
+      сервисах (инвариант ORCH-040 «МИНА 1») (AC-2, AC-6 / FR-3).
+    module: tests/test_infra_parametrization.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: >
+      Структурная проверка Dockerfile: uid/gid/username/home параметризованы через
+      ARG с дефолтами 1000/1000/slin//home/slin; решение по CMD-порту соответствует
+      ADR задачи (ARG либо обоснованный дефолт 8500) (AC-2, AC-6 / FR-3, §3.4 А-3).
+    module: tests/test_infra_parametrization.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: >
+      Полнота .env.example: каждый обязательный для старта ключ присутствует,
+      включая ВСЕ новые ключи FR-2/FR-3 (сверка с Settings.model_fields по
+      выбранному архитектором контракту); секретные ключи содержат только
+      плейсхолдеры, не реальные значения; deploy-hook принимает REPO через
+      env-override (AC-5, AC-6 / FR-1 D1, FR-4.4).
+    module: tests/test_infra_parametrization.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: >
+      Генератор секретов: два запуска дают различные значения; длина/энтропия
+      webhook-секретов >= 32 байт; существующий .env никогда не перезаписывается
+      молча (запуск при существующем файле -> отказ/явное подтверждение);
+      вывод согласован с ключами .env.example (AC-5 / FR-4, NFR-3).
+    module: tests/test_secrets_gen.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: >
+      Smoke-обвязка и процедура: deployment-док с пошаговой smoke-процедурой
+      существует и содержит явные PASS/FAIL-критерии каждого шага; если введён
+      скрипт — он запускается без ошибок в безопасном режиме (--help/dry-run, без
+      сети/LLM-расходов); карта env в INFRA.md дополнена; CHANGELOG.md содержит
+      запись ORCH-101 (AC-3, AC-4 / FR-5, FR-7).
+    module: tests/test_replication_smoke.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: >
+      Инвариант ORCH-058 при исходе А-1: если staging-порт стал конфигуром —
+      дефолт 8501, guard «staging-порт != прод-порт» отвергает совпадение
+      (freshness-путь невозможно нацелить на прод); если остался константой —
+      тест фиксирует константу 8501 и наличие обоснования в ADR задачи
+      (AC-8 / FR-1 A5, NFR-4).
+    module: tests/test_host_config_keys.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: >
+      Полный регресс: pytest tests/ -q зелёный на дефолтной конфигурации (пустой
+      env) — поведение платформы на текущем хосте 1:1; существующие тесты не
+      правились под задачу (кроме согласованных структурных) (AC-2 / BR-5, NFR-6).
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md

@@ -0,0 +1,374 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Параметризация хоста + секреты нового хоста + smoke-верификация (фундамент тиража 10-common)
+
+Work Item: **ORCH-101** — ORCH-10-common: расхардкод + секреты + smoke
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`**
+(решение кросс-каттинговое: задаёт платформенные конвенции тиража и трогает блоки с маркерами
+ORCH-036/040/058 — по `docs/_standards/TRACEABILITY.md` агрегируется сводным сквозным ADR).
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5.3 «Масштаб») требует разворачивать платформу на чужой инфре **без правки кода** —
+двумя типами тиража (A Lite / B Bundled), оба stateless. Сегодня платформа прибита к `mva154`:
+часть значений **обходит конфиг**. Аудит стадии analysis (нормативный реестр — `02-trz.md` §3.1)
+перепроверен мной по коду ветки (`grep` всех запрещённых классов по `src/**`+`watchdog/**`):
+
+- **Код-блокеры ровно четыре:** A1 `plane_sync.py:1064` (`gitea_base = "http://git.mva154.duckdns.org"`
+  + owner `admin` в ссылках), A2 `agents/launcher.py:594,825` (HOME + git-идентичность ×2 места),
+  A3 `self_deploy.py:332–336`, A4 `post_deploy.py:575–579` (то же у finalizer/monitor).
+- **Все остальные вхождения** `82.22.50.71|/home/slin|mva154|duckdns` в `src/**`/`watchdog/**` —
+  комментарии/докстринги (`disk_watchdog.py:3,80`, `build_cache_pruner.py:3`, `fs_normalize.py:7`,
+  `config.py:469`) либо **легитимные конфиг-дефолты** (`config.py:48,201` — реестр E, BR-1).
+- A7 (`fs_normalize.py::healing_command`) **уже config-backed в основном пути** (строит из
+  `_resolve_target_uid`/`settings.worktrees_dir`); литерал остался только в `except`-ветке
+  never-raise (см. D10).
+- Инфра-файлы: `docker-compose.yml` (реестр B1–B6), `Dockerfile` (C1–C2),
+  `scripts/orchestrator-deploy-hook.sh:38` (D1 — единственная непараметризованная строка скрипта;
+  критично: хук **безусловно перезаписывает** `REPO=`, поэтому даже корректный env инвокера сегодня
+  игнорируется).
+- Секретов «для нового хоста» нет (общий webhook-secret = чужой хост шлёт нам валидные вебхуки);
+  smoke-процедуры тиража нет.
+
+Сопутствующие инварианты, которые НЕЛЬЗЯ ослабить (правило №9, ADR прочитаны):
+**ORCH-040** (adr-0005: uid 1000 + `group_add: ["999"]` «МИНА 1» + HOME согласован с маунтами),
+**ORCH-058** (adr-0008: freshness-путь целится ТОЛЬКО в staging, explicit-pass таргета, INV-FRESH),
+**ORCH-036** (adr-0007: exit-code контракт хука 0/1/2, detached Phase B), **INV-4** (мерж только
+через Gitea PR-merge API).
+
+## Решение
+
+### Сводка
+
+Три слоя одного фундамента. (1) **Расхардкод**: четыре код-блокера переводятся на `Settings`
+(три новых ключа + два существующих), инфра-файлы — на compose-интерполяцию/`ARG`/env-override;
+**каждый дефолт равен боевому значению** → отсутствие новых переменных = байт-в-байт текущее
+поведение (kill-switch-природа, NFR-2; отдельный флаг не вводится). (2) **Секреты**: новый
+stdlib-скрипт `scripts/gen_secrets.py` (криптослучайные webhook-секреты, печать по умолчанию,
+никогда не перезаписывает `.env` молча) + чек-лист внешних токенов. (3) **Smoke**: чистый runbook
+`docs/operations/REPLICATION.md` из существующих кирпичей (`/health`, `/queue`, `/metrics`,
+`onboard_project.py`, sandbox-задача), без нового скрипта. Анти-регресс — структурный сканер
+`tests/test_no_host_hardcodes.py`. Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict/схема БД) — байт-в-байт не тронут (NFR-6).
+
+### D1 — Принцип параметризации: «дефолт = боевое значение», механизм по слоям
+
+| Слой | Механизм | Канон дефолта |
+|------|----------|---------------|
+| `src/**`, `watchdog/**` | ключи `Settings` (env `ORCH_*`) / `watchdog.Config` (`WATCHDOG_*`) | `src/config.py` / `watchdog/config.py` — **единственные легитимные места** хост-литералов в коде (BR-1) |
+| `docker-compose.yml` | интерполяция `${VAR:-default}` | дефолт в самом файле = текущее значение |
+| `Dockerfile` | build `ARG` (+ wiring через compose `build.args`) | дефолт `ARG` = текущее значение |
+| `scripts/orchestrator-deploy-hook.sh` | `"${VAR:-default}"` (паттерн остальных переменных хука) | дефолт = текущее значение |
+
+**Правило одного имени:** если значение нужно и контейнеру (pydantic), и compose-интерполяции —
+используется **одно** env-имя (например `ORCH_AGENT_HOME_DIR`, `ORCH_STAGING_PORT`): pydantic
+читает его из `env_file`, compose — из `.env`/shell. Два имени для одного факта запрещены.
+
+**Источник интерполяции (важно, фиксируется в REPLICATION.md):** compose резолвит `${VAR}` из
+`.env` проекта/shell-окружения, **НЕ** из `env_file` сервиса — `.env.staging` на интерполяцию не
+влияет. Для single-host тиража это штатно: интерполяционные значения живут в `.env`.
+
+Привязка: BR-1, BR-2, BR-5, NFR-2 / FR-1, FR-2, FR-3. Проверка: AC-1, AC-2, AC-6 (TC-01…TC-08).
+
+### D2 — Новые `Settings`-ключи и группировка акторских env (вопрос А-5)
+
+Выбран вариант **«единый HOME + общий email-домен + одно агентское имя»** (3 ключа), против
+6+ per-actor ключей:
+
+| Ключ | env | Дефолт | Потребители |
+|------|-----|--------|-------------|
+| `agent_home_dir` | `ORCH_AGENT_HOME_DIR` | `/home/slin` | `HOME` всех 4 акторских env-словарей: `launcher` (×2 места — Popen агента и git commit/push), `self_deploy.write_deploy_log`, `post_deploy.write_post_deploy_log`; + compose mount-таргеты и `ARG APP_HOME` (D5/D6) |
+| `agent_git_name` | `ORCH_AGENT_GIT_NAME` | `claude-bot` | `GIT_AUTHOR/COMMITTER_NAME` агентов в `launcher` (×2) — customer-visible идентичность коммитов |
+| `git_email_domain` | `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен email всех трёх акторов |
+
+**Контракт идентичностей:** email строится как `f"{name}@{settings.git_email_domain}"`, где
+`name` = `settings.agent_git_name` для агентов (launcher) и **платформенные литералы**
+`deploy-finalizer` / `post-deploy-monitor` для системных акторов (`self_deploy` / `post_deploy`) —
+имена системных акторов не хост-специфичны, различимость их коммитов в истории ценна, ключи на них
+не заводятся. Дефолтные итоговые значения = сегодняшним байт-в-байт: `claude-bot@mva154.local`,
+`deploy-finalizer@mva154.local`, `post-deploy-monitor@mva154.local` (BR-5).
+
+**A1 (`plane_sync.notify_stage_change`) — новых ключей НЕ требует:** база ссылок —
+`settings.gitea_public_url or settings.gitea_url` (точно та же fallback-семантика, что у
+существующих потребителей `notifications.py:901` и `usage.py:457,662`), owner —
+`settings.gitea_owner` (заменяет литерал `admin` в путях Branch/PR).
+
+Каждый новый ключ получает описательный комментарий в `config.py` (по образцу соседних блоков),
+строку в `.env.example` и в карте env `INFRA.md`. Контракт FR-2 после изменения: **ни один из
+акторов не содержит литералов `/home/slin` / `mva154` в исполняемом коде** (TC-03…TC-05).
+
+### D3 — Вопрос А-2: `SELF_HOSTING_REPO = "orchestrator"` остаётся платформенной константой
+
+**Решение: НЕ конфигурируем.** Имя self-hosting репо — **нормативная конвенция тиража**: «репо
+платформы в любом тираже обязан называться `orchestrator`» (фиксируется в REPLICATION.md §границы
++ чек-лист). Обоснование:
+
+1. **Это узел безопасности, а не хост-значение.** На `is_self_hosting_repo` завязана семантика
+   «empty CSV → self-hosting only» **всех** `*_repos`-leaf'ов (merge-gate, image-freshness,
+   security, coverage, serial-gate freeze, fs-normalize, auto-labels, bug-fast-track, deploy-guard…).
+   Опечатка в гипотетическом `ORCH_SELF_HOSTING_REPO` либо **активирует деплой-машинерию на чужом
+   репо** (групповой риск), либо **молча выключает все self-гейты** на своём (класс «гейт тихо
+   исчез» — худший отказ по урокам ORCH-058). Константа делает оба отказа структурно невозможными.
+2. **Цена конвенции — ноль.** Тираж stateless (решение Славы 10.06): репо платформы создаётся
+   заново на целевой инфре (Type A — по инструкции Lite, Type B — в комплекте) — его имя полностью
+   под контролем оператора. Конфигурируемость не покупает ни одного сценария, который конвенция не
+   даёт бесплатно.
+3. Расширяемость не теряется: если будущий тираж потребует иного имени — отдельная задача с
+   guard'ами; этот ADR — зафиксированное место, откуда она стартует.
+
+Привязка: AC-1 (вариант «обоснованы в ADR задачи как платформенные константы»). Анти-дрейф: тест
+фиксирует константу (см. D10/TC-11-паттерн).
+
+### D4 — Вопрос А-1: staging-порт конфигурируем С fail-closed guard (инвариант ORCH-058 усилен)
+
+**Решение: конфигурируем порт, НЕ конфигурируем имена.** Новый ключ:
+
+- `staging_port: int = 8501` (env **`ORCH_STAGING_PORT`**) — заменяет модульную константу
+  `image_freshness._STAGING_PORT`; то же env-имя интерполируется в `command:` staging-сервиса
+  compose (`${ORCH_STAGING_PORT:-8501}`, реестр B6) → обе точки читают один факт (D1).
+- `_STAGING_SERVICE` / `_STAGING_COMPOSE_PROFILE` (`orchestrator-staging` / `staging`) —
+  **остаются константами**: имена сервисов/профиля нашего же compose-файла — платформенная
+  конвенция (логика D3); их разъезд с compose ломал бы rebuild внутри одного репо без выгоды.
+
+**Guard (ядро решения, NFR-4 / Р-2):** в начале freshness-пути (`check_staging_image_fresh`,
+ДО любого ssh/build/recreate) — проверка
+`settings.staging_port == settings.deploy_prod_target_port` → **отказ fail-closed**:
+`(False, "misconfiguration: ORCH_STAGING_PORT == prod target port (ORCH-058 AC-9) — staging rebuild refused")`
++ best-effort Telegram-алерт. **Без тихого fallback на 8501** — молчаливая подмена порта хуже
+громкого отказа (оператор обязан починить env). Дисциплина explicit-pass ORCH-058 сохраняется:
+`TARGET_PORT=` по-прежнему передаётся хуку явно (`image_freshness.py:272`), источник теперь — один
+валидируемый конфиг-ключ вместо литерала. Инвариант «freshness-путь никогда не целится в прод»
+из подразумеваемого константой становится **исполняемым** (guard) — усиление, не ослабление.
+
+Примечание: при изменённом `ORCH_STAGING_PORT` ручной запуск хука `--build-staging` без env-прefix
+использует staging-дефолты хука (8501) — это документируется в REPLICATION.md (ручные запуски —
+с явным `TARGET_PORT=`); wired-путь (через `image_freshness`) всегда передаёт порт явно.
+
+Привязка: FR-1 A5, AC-8, TC-11.
+
+### D5 — Вопрос А-3: CMD Dockerfile остаётся `8500`; параметризация порта — на слое compose
+
+**Решение: `CMD` не трогаем** (exec-form, `--port 8500` — документированный дефолт образа):
+
+- `ARG` не подставляется в рантайм-CMD; shell-form CMD (`sh -c "… ${PORT}"`) менял бы
+  PID-1/сигнальную семантику — пара «`init: true` + exec-form» выверена (B-2, зомби-репарентинг
+  поддерева claude/node) и трогать её ради порта — риск без выгоды.
+- Порт конфигурируется там, где уже доказанно работает (staging так живёт с ORCH-31): **оба**
+  compose-сервиса получают явный `command:`: прод —
+  `["uvicorn","src.main:app","--host","0.0.0.0","--port","${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}"]`,
+  staging — то же с `${ORCH_STAGING_PORT:-8501}`. **Реюз существующего env-имени**
+  `ORCH_DEPLOY_PROD_TARGET_PORT` (ключ `deploy_prod_target_port: 8500` уже описывает прод-порт для
+  деплой-пути) — вторая «истина» о прод-порте не вводится. Дефолтный резолв = байт-в-байт текущему
+  CMD → эффективная конфигурация 1:1 (AC-2; TC-06 сверяет резолв по значениям).
+
+**C1 (`useradd`):** `ARG APP_UID=1000 / APP_GID=1000 / APP_USER=slin / APP_HOME=/home/slin` в
+`Dockerfile`; compose `build.args` обоих сервисов прокидывают их из тех же env, что и рантайм:
+`APP_UID: ${ORCH_RUN_UID:-1000}`, `APP_GID: ${ORCH_RUN_GID:-1000}`,
+`APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}` → uid/gid/HOME двигаются **одной согласованной
+группой** (инвариант ORCH-040, FR-3). `APP_USER` — косметика passwd-записи (важен факт записи для
+`getpwuid`/ssh, ORCH-058 Dockerfile:38, не имя), дефолт `slin`.
+
+Привязка: FR-1 C1–C2, §3.4 А-3, AC-6, TC-07.
+
+### D6 — Карта compose-интерполяции (реестр B) и согласованная группа ORCH-040
+
+Полная карта переменных `docker-compose.yml` (дефолты = текущим значениям; все три сервиса):
+
+| Переменная | Дефолт | Закрывает |
+|---|---|---|
+| `ORCH_HOST_REPOS_DIR` *(реюз)* | `/home/slin/repos` | B1 volumes ×3 (`:/repos`, у watchdog `:ro`) + environment ×2 (`ORCH_HOST_REPOS_DIR=` прокидывается тем же значением) |
+| `ORCH_HOST_CLAUDE_DIR` | `/home/slin/.claude` | B1 (source маунта) |
+| `ORCH_HOST_CLAUDE_JSON` | `/home/slin/.claude.json` | B1 (source, `:ro`) |
+| `ORCH_HOST_SSH_DIR` | `/home/slin/.orchestrator-ssh` | B1 (source, `:ro`) |
+| `ORCH_AGENT_HOME_DIR` *(= Settings-ключ D2)* | `/home/slin` | **таргеты** маунтов `.claude`/`.claude.json`/`.ssh` (`…:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude` и т.д.) + `build.args APP_HOME` |
+| `ORCH_HOST_CLAUDE_CODE_DIR` | `/usr/lib/node_modules/@anthropic-ai/claude-code` | B2 (`:/opt/claude-code:ro`) |
+| `ORCH_HOST_NODE_BIN` | `/usr/bin/node` | B2 (`:/usr/bin/node:ro`) |
+| `ORCH_DOCKER_GID` | `999` | B3 `group_add` ×3 — **«МИНА 1» НЕ удаляется**, меняется только литерал на `${ORCH_DOCKER_GID:-999}` |
+| `ORCH_RUN_UID` / `ORCH_RUN_GID` | `1000` / `1000` | B4 `user:` ×2 + `build.args APP_UID/APP_GID` |
+| `ORCH_DEPLOY_SSH_USER` *(реюз)* | `slin` | B5: `ORCH_DEPLOY_SSH_USER=`, `DEPLOY_SSH_USER=` (legacy enduro — то же значение через `${ORCH_DEPLOY_SSH_USER:-slin}`) |
+| `ORCH_DEPLOY_HOST_REPO_PATH` *(реюз)* | `/home/slin/repos/orchestrator` | B5 environment |
+| `DEPLOY_HOOK_SCRIPT` *(legacy)* | `/home/slin/bin/enduro-deploy-hook.sh` | B5 ×2 (`${DEPLOY_HOOK_SCRIPT:-…}`) |
+| `ORCH_STAGING_PORT` *(= Settings-ключ D4)* | `8501` | B6 `command:` staging |
+| `ORCH_DEPLOY_PROD_TARGET_PORT` *(реюз)* | `8500` | `command:` prod (D5) |
+
+Не параметризуются (зафиксировано): контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`,
+`/var/run/docker.sock`) — конвенция layout'а контейнера, не хост-специфика;
+`DEPLOY_SSH_HOST/ORCH_DEPLOY_SSH_HOST=127.0.0.1` — loopback при `network_mode: host`, валиден на
+любом single-host; имена сервисов/контейнеров/образов — платформенные константы (D3/D4; для образов
+истина уже в конфиге: `deploy_prod_source_image`/`deploy_prod_target_image`); `network_mode: host`,
+`init: true`, профиль `staging` — архитектурные решения, не значения.
+
+Группа ORCH-040 после изменения: `ORCH_RUN_UID/GID` + `ORCH_AGENT_HOME_DIR` + source-переменные
+маунтов меняются согласованно; при дефолтах резолв эквивалентен текущему файлу (TC-06).
+
+### D7 — Deploy-hook: env-override `REPO` + явная передача от инвокеров
+
+1. `scripts/orchestrator-deploy-hook.sh:38`: `REPO=/home/slin/repos/orchestrator` →
+   `REPO="${REPO:-/home/slin/repos/orchestrator}"` (паттерн остальных переменных хука; D1 реестра).
+2. **Оба инвокера передают `REPO` явно** (иначе на новом хосте env-override мёртв — сейчас хук
+   безусловно перезаписывает значение): `self_deploy.build_deploy_command` (prod env-прefix) и
+   `image_freshness` (`env_assignments`, строки ~268–275) добавляют
+   `REPO={shlex.quote(settings.deploy_host_repo_path)}` — тот же источник, которым инвокеры уже
+   делают `cd` (`image_freshness.py:277`). Конфиг становится единственной истиной на wired-пути;
+   дефолт хука сохраняет ручные операторские запуски на текущем хосте.
+
+**Инварианты не тронуты:** exit-code контракт хука (0/1/2, ORCH-036), шаги `--deploy`/`--rollback`/
+`--build-staging`, provenance-guard `EXPECTED_REVISION` (ORCH-058 Strategy B) — добавляется ровно
+одно env-присваивание в префикс команды. Привязка: FR-1 D1, AC-6, TC-08.
+
+### D8 — Вопрос А-4 (секреты): отдельный stdlib-скрипт `scripts/gen_secrets.py`
+
+**Форма: новый самостоятельный скрипт** (НЕ режим `onboard_project.py`: онбординг подключает проект
+к **живой** платформе, генерация секретов — provisioning **нового хоста**; это разные жизненные
+циклы и разные операторы, смешение связало бы независимые сценарии и раздуло CLI ORCH-009).
+
+Контракт (BR-3 / FR-4 / NFR-3 / AC-5, TC-09):
+
+- **stdlib-only** (`secrets`, `argparse`); генерирует `ORCH_PLANE_WEBHOOK_SECRET`,
+  `ORCH_GITEA_WEBHOOK_SECRET` через `secrets.token_hex(32)` (32 байта энтропии, 64 hex-символа;
+  повторный запуск — другие значения).
+- **Режим по умолчанию — печать в stdout** (`.env`-фрагмент: сгенерированные webhook-секреты +
+  плейсхолдеры внешних токенов + указатель на чек-лист); файлы не трогаются.
+- `--write [PATH=.env]`: **существующий файл → отказ с exit≠0 и внятным сообщением**; перезапись —
+  только явный `--force` (AC-5 «отказ/явное подтверждение»). Никогда не перезаписывает молча.
+- Состав ключей вывода согласован с `.env.example` (TC-09 сверяет программно).
+- **Инвентаризация секретов** (фиксация аудита FR-4.1): генерируемые локально —
+  `ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET`; выпускаемые внешними системами (только
+  чек-лист REPLICATION.md: где выпустить → куда вписать → как проверить) — `ORCH_PLANE_API_TOKEN`,
+  `ORCH_PLANE_BOT_*` (7, опциональны — fallback на API-токен), `ORCH_GITEA_TOKEN`,
+  `ORCH_TELEGRAM_BOT_TOKEN` (+несекретный `ORCH_TELEGRAM_CHAT_ID`), sidecar
+  `WATCHDOG_TG_BOT_TOKEN`/`WATCHDOG_TG_CHAT_ID` (ORCH-100, независимый канал). Нормативная строка:
+  **«боевые секреты текущего хоста не копируются ни на одном шаге»**.
+- `.env.example` дополняется до 100% обязательных ключей старта (включая новые D2/D4/D6);
+  секретные значения — только плейсхолдеры; `.env.staging.example` согласуется.
+
+### D9 — Вопрос А-4 (smoke): чистый runbook без нового скрипта
+
+**Форма: документированная процедура** `docs/operations/REPLICATION.md` (имя из ТЗ принято),
+собранная из **существующих кирпичей** — нового smoke-скрипта **не вводим**: каждый шаг уже имеет
+машинную команду с однозначным исходом; обвязка добавила бы поверхность сопровождения и LLM/сетевые
+зависимости без новой гарантии (AC-3 допускает «и/или скрипт»; TC-10 — «если введён»).
+
+Скелет процедуры (developer материализует; каждый шаг — явные PASS/FAIL):
+
+| Шаг | Команда/кирпич | PASS |
+|---|---|---|
+| 0. Конфиг резолвится | `docker compose config` | резолв без ошибок/未-переменных |
+| 1. Инстанс жив | `curl -fsS http://127.0.0.1:<port>/health` | HTTP 200 |
+| 2. Контракты отвечают | `GET /queue`, `GET /metrics` | JSON, штатные блоки, `schema_version: 1` |
+| 3. Тестовый проект | `scripts/onboard_project.py plan` → `apply` → `verify` (sandbox) | `verify` зелёный |
+| 4. Тестовая задача | создать issue в Plane → статус «To Analyse» | задача в БД, analyst-job в `GET /queue` |
+| 5. **Минимальный сигнал «конвейер доехал»** | дождаться окончания `analysis` | артефакты `01–04` в ветке задачи (`git ls-tree origin/<branch> docs/work-items/<id>/`) |
+| 6. Расширенный режим (опционально) | Approved → … → Confirm Deploy | задача дошла до `done` |
+
+Итог — однозначный вердикт PASS/FAIL; при FAIL — что собрать (логи контейнера, снапшот `/queue`).
+Stateless: ни один шаг не предполагает перенос данных/БД/секретов с боевого хоста.
+**Приёмка воспроизводимости (AC-3):** один прогон на текущей инфре — staging-песочница 8501 +
+sandbox-проект (исполняет tester, фиксация в `13-test-report.md`/`15-staging-log.md`).
+Границы «10-common vs Lite vs Bundled» — отдельный раздел REPLICATION.md (анти-скоуп-крип Р-5).
+
+### D10 — Анти-регресс сканер: механика исключений (NFR-5)
+
+`tests/test_no_host_hardcodes.py` (образец — `tests/test_agent_prompts_canon.py`):
+
+- **Список запрещённых литералов централизован в тесте:**
+  `FORBIDDEN = ("82.22.50.71", "/home/slin", "mva154", "duckdns")` — единственная точка правки.
+- **Зона скана:** `src/**/*.py` + `watchdog/**/*.py`. Вне зоны: `tests/**`, `docs/**`, `scripts/**`
+  (deploy-hook несёт легитимный shell-default D7), `.env*`.
+- **Структурное исключение — `src/config.py` и `watchdog/config.py` целиком:** это канонические
+  места дефолтов (BR-1), и их дефолты **обязаны** нести боевые значения (BR-5: `/home/slin`,
+  `mva154.local`) — сканировать их значило бы держать вечно непустой allowlist. Исключение —
+  правило теста с комментарием-обоснованием, не allowlist-запись.
+- **Исключение комментариев/докстрингов** — через `tokenize` (надёжнее построчных regex: судит
+  токены `COMMENT`/`STRING`-докстринги, а не текст; детерминирован — NFR-5).
+- **Allowlist-механизм** (`{(file, literal): "обоснование"}`) существует и **пуст на сдаче**
+  (после D2/D7 код-блокеров не остаётся; `fs_normalize.healing_command` except-ветка
+  (`/repos/_wt`, `1000:1000`) запрещённых литералов **не содержит** и остаётся как never-raise
+  floor — главный путь уже строит подсказку из settings, отдельной правки A7 не требуется).
+- **Негативная самопроверка (TC-02):** сканер прогоняется по синтетическому фрагменту с
+  подсаженным литералом и обязан его поймать (тест не вечно-зелёный).
+
+### Что НЕ меняется (граница решения)
+
+- `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД —
+  байт-в-байт (NFR-6); новые тесты входят в существующие гейты (`check_ci_green`/merge-gate re-test)
+  автоматически.
+- Значения существующих дефолтов реестра E (`02-trz.md` §3.1) — не меняются (BR-5).
+- A8 (`disk_watchdog` fallback `["/repos","/app/data"]`) — config-backed зеркало, остаётся как есть
+  (синхронность с конфиг-дефолтом фиксирует существующий тест-ландшафт; вводить «одну точку истины»
+  ради неблокера — лишний диф).
+- A9 (`projects._DEFAULT_PROJECTS`) — документированный fallback, не трогаем; чек-лист REPLICATION.md
+  обязывает `ORCH_PROJECTS_JSON` на новом хосте.
+- A10 (`watchdog/config.py` `metrics_url` 127.0.0.1:8500) — уже env-driven; при смене прод-порта
+  оператор задаёт `WATCHDOG_METRICS_URL` (строка чек-листа о когерентности портов:
+  `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`).
+- `onboarding/` (ORCH-009) — не форкается; новые env-ключи отражаются в его `.env.example`-скелете
+  только при фактическом расхождении.
+
+## Альтернативы
+
+- **`ORCH_SELF_HOSTING_REPO` как конфиг-ключ** — отвергнуто: превращает опечатку оператора в
+  активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов (D3); конвенция
+  бесплатна при stateless-тираже.
+- **`_STAGING_PORT` оставить константой** — отвергнуто: реестр B6 (AC-6) требует параметризации
+  порта в compose `command:`; константа в `image_freshness` при конфигурируемом compose-порте даёт
+  рассинхрон (rebuild целится в 8501, staging слушает иное) — хуже управляемой пары
+  «ключ + fail-closed guard» (D4).
+- **Тихий fallback guard'а на 8501 при misconfig** — отвергнуто: молчаливая подмена таргета —
+  ровно тот класс отказа, против которого ORCH-058 строился; отказ громче и честнее.
+- **Shell-form CMD / `ENV PORT` в Dockerfile** — отвергнуто: меняет PID-1/сигнальную семантику
+  выверенной пары `init: true` + exec-form (B-2) ради порта, который уже параметризуем на слое
+  compose (D5).
+- **Генератор секретов как режим `onboard_project.py`** — отвергнуто: разные жизненные циклы
+  (онбординг проекта на живой платформе vs provisioning хоста), связывание независимых
+  операторских сценариев (D8).
+- **Отдельный smoke-скрипт-обвязка** — отвергнуто (сейчас): каждый шаг runbook уже машинно
+  проверяем существующими кирпичами; скрипт = новая поверхность сопровождения без новой гарантии.
+  Дверь открыта: Lite/Bundled-задачи могут ввести обвязку поверх того же runbook (D9).
+- **Allowlist-записи для `config.py` вместо структурного исключения** — отвергнуто: allowlist
+  обязан быть пуст (AC-1/AC-7); вечные записи о легитимных дефолтах девальвируют его сигнал (D10).
+
+## Последствия
+
+- **+** Платформа разворачивается на новой инфре только env/конфигом: четыре код-блокера закрыты
+  тремя ключами + реюзом существующих; инфра-файлы интерполируются; секреты выпускаются заново;
+  smoke даёт явный PASS/FAIL. Критический путь эпика ORCH-10 разблокирован.
+- **+** Инвариант ORCH-058 усилен: анти-prod-гарантия freshness-пути теперь исполняемый guard,
+  а не подразумеваемая константа.
+- **+** Возврат хардкода ломает CI структурно (сканер), а не ловится ревью.
+- **−** Поверхность конфигурации растёт (~13 новых env-имён). Митигейшн: дефолты = боевым
+  значениям (ничего настраивать на текущем хосте не нужно), карта env в INFRA.md/REPLICATION.md,
+  TC-06/TC-08 сверяют полноту и резолв.
+- **−** Правка двух safety-critical билдеров команд (D7) и compose-файла прод-сервиса (D5).
+  Митигейшн: изменения чисто аддитивные (одно env-присваивание; `command:` = текущему CMD),
+  exit-контракт хука не тронут, полный регресс + staging-гейт 8501 перед прод-деплоем (NFR-1).
+- **−** Compose-интерполяция читает `.env`/shell, а не `env_file` — возможна операторская путаница
+  на staging. Митигейшн: правило явно зафиксировано (D1) и попадает в REPLICATION.md.
+- **Откат:** не задавать новые переменные (дефолты = прежнее поведение — kill-switch-природа,
+  NFR-2); полный откат — revert PR (изменение конфигурационное, без миграций состояния).
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-101/01-brd.md`
+- TRZ: `docs/work-items/ORCH-101/02-trz.md` (нормативный реестр §3.1, вопросы §3.4 А-1…А-5)
+- Acceptance: `docs/work-items/ORCH-101/03-acceptance-criteria.md` (AC-1…AC-8)
+- Test plan: `docs/work-items/ORCH-101/04-test-plan.yaml` (TC-01…TC-12)
+- Сквозной ADR: `docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`
+- Инварианты соседей: `docs/architecture/adr/adr-0005-container-runs-as-host-uid.md` (ORCH-040),
+  `adr-0008-staging-image-provenance.md` (ORCH-058), `adr-0007-executable-self-deploy.md` (ORCH-036),
+  `adr-0035-turnkey-project-onboarding.md` (ORCH-009)
+- Сверено по коду: `src/plane_sync.py:1064`, `src/agents/launcher.py:592–599,823–831`,
+  `src/self_deploy.py:330–337`, `src/post_deploy.py:573–580`, `src/image_freshness.py:60–62,263–280`,
+  `src/qg/checks.py:517`, `src/fs_normalize.py:529–540`, `src/config.py:33–49,193–209`,
+  `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh:38`

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

@@ -0,0 +1,80 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
+
+> Топология НЕ меняется (контейнеры/порты/сеть/тома — те же при дефолтах); меняется
+> **параметризуемость** инфра-файлов. Раздел фиксирует карту переменных и правила раската.
+
+## I-1. Топология / окружения
+
+- **Без изменений при дефолтах:** те же 3 сервиса (`orchestrator` 8500, `orchestrator-watchdog`,
+  `orchestrator-staging` 8501 под профилем `staging`), `network_mode: host`, те же тома и
+  `group_add` docker-gid («МИНА 1» ORCH-040 — сохраняется, литерал → `${ORCH_DOCKER_GID:-999}`).
+- `docker-compose.yml` переводится на интерполяцию `${VAR:-default}` (реестр ТЗ §3.1 B; карта —
+  ADR-001 D6); `Dockerfile` получает `ARG APP_UID/APP_GID/APP_USER/APP_HOME` (D5); оба сервиса
+  получают явный `command:` с портом из env (`${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}` /
+  `${ORCH_STAGING_PORT:-8501}`) — дефолтный резолв эквивалентен текущей конфигурации (AC-2/TC-06).
+- **Источник интерполяции** — `.env` проекта / shell-окружение (НЕ `env_file` сервиса):
+  интерполяционные значения тиража живут в `.env` (ADR-001 D1; попадает в REPLICATION.md).
+- Имена сервисов/контейнеров/образов, профиль `staging`, `network_mode: host`, контейнерные пути
+  (`/app/data`, `/repos`, `/opt/claude-code`) — платформенные константы (ADR-001 D3/D4/D6).
+
+## I-2. Переменные окружения / секреты
+
+**Новые `Settings`-ключи** (дефолт = боевому значению; см. ADR-001 D2/D4):
+
+| env | Дефолт | Назначение |
+|---|---|---|
+| `ORCH_AGENT_HOME_DIR` | `/home/slin` | HOME акторских процессов (launcher ×2 / self-deploy / post-deploy) + таргеты маунтов + `APP_HOME` |
+| `ORCH_AGENT_GIT_NAME` | `claude-bot` | git-имя агентских коммитов |
+| `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен git-email всех акторов (`<actor>@<domain>`) |
+| `ORCH_STAGING_PORT` | `8501` | порт staging: `image_freshness` (c guard'ом ≠ прод-порт) + compose `command:` |
+
+**Новые compose-only переменные:** `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON`,
+`ORCH_HOST_SSH_DIR`, `ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_DOCKER_GID`,
+`ORCH_RUN_UID`, `ORCH_RUN_GID` (дефолты — текущие значения; полная карта — ADR-001 D6).
+**Реюз существующих имён:** `ORCH_HOST_REPOS_DIR`, `ORCH_DEPLOY_SSH_USER`,
+`ORCH_DEPLOY_HOST_REPO_PATH`, `ORCH_DEPLOY_PROD_TARGET_PORT`, legacy `DEPLOY_HOOK_SCRIPT`.
+**Deploy-hook:** `REPO="${REPO:-/home/slin/repos/orchestrator}"` + явная передача `REPO=` обоими
+инвокерами (ADR-001 D7).
+
+**Секреты (BR-3 / AC-5):** новый stdlib-скрипт `scripts/gen_secrets.py` — криптослучайные
+`ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` (`secrets.token_hex(32)`), печать по
+умолчанию, `--write` с отказом при существующем `.env` (перезапись только `--force`). Внешние
+токены (`ORCH_PLANE_API_TOKEN`, `ORCH_PLANE_BOT_*`, `ORCH_GITEA_TOKEN`, `ORCH_TELEGRAM_BOT_TOKEN`,
+`WATCHDOG_TG_*`) — по чек-листу REPLICATION.md (где выпустить → куда вписать → как проверить).
+Боевые секреты текущего хоста не покидают его (NFR-3); в гит — только шаблоны/плейсхолдеры
+(правило агентов №8); `.env.example` доводится до 100% обязательных ключей, `.env.staging.example`
+согласуется.
+
+**Карта env в `docs/operations/INFRA.md`** дополняется всеми новыми ключами; deployment-раздел —
+новый `docs/operations/REPLICATION.md` (FR-7). Чек-лист тиража обязывает: `ORCH_PROJECTS_JSON`
+(fallback-реестр UUID'ов чужого Plane не сматчится), когерентность портов
+`ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`.
+
+## I-3. Деплой / рестарт
+
+- **Рестарт прод-контейнера в рамках задачи — НЕ требуется и запрещён** (NFR-1, self-hosting):
+  правки `docker-compose.yml`/`Dockerfile`/хука инертны до следующего штатного деплоя через
+  конвейер (staging 8501 → ручной `Confirm Deploy`, ORCH-059).
+- На текущем хосте ничего донастраивать не нужно: все дефолты = боевым значениям; пустой/
+  неизменённый `.env` → поведение 1:1 (BR-5). Откат = не задавать переменные (NFR-2).
+- Инвариант ORCH-058 сохранён и усилен: freshness-путь fail-closed отказывает при
+  `ORCH_STAGING_PORT == прод-порт` (ADR-001 D4); INV-4 не затрагивается.
+
+## I-4. CI/CD
+
+- `.gitea/workflows/` — **без изменений**. Новые тесты (`test_no_host_hardcodes.py`,
+  `test_host_config_keys.py`, `test_infra_parametrization.py`, `test_secrets_gen.py`,
+  `test_replication_smoke.py`) попадают в существующие гейты (`check_ci_green`/
+  `check_tests_passed`/merge-gate re-test) автоматически — новых QG не вводится (NFR-6).
+- Новых pip/системных зависимостей нет (генератор секретов — stdlib).

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

@@ -0,0 +1,32 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable / информационный. Задача конфигурационная — данные и схема БД не затрагиваются;
+> файл создан для аудитопригодности с явными `N/A`.
+
+## Изменения схемы БД
+
+`N/A` — таблицы/индексы/миграции не добавляются и не меняются; `init_db()` не трогается (NFR-6,
+ТЗ §5). Тираж stateless (решение Славы 10.06): перенос данных/БД с боевого хоста не предполагается
+ни одним шагом (smoke-процедура это явно проверяет — AC-3).
+
+## Новые/изменённые сущности
+
+Нет. Новые конфиг-ключи (`agent_home_dir`, `agent_git_name`, `git_email_domain`, `staging_port`) —
+слой `Settings` (env), не данные.
+
+## Совместимость данных / миграции
+
+`N/A` — общая прод-БД (self-hosting, enduro-trails) не затрагивается; `ORCH_DB_PATH` и layout
+`/app/data` остаются прежними (контейнерные пути — платформенная конвенция, ADR-001 D6). На новом
+хосте БД создаётся с нуля штатным `init_db()`.

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

@@ -0,0 +1,38 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
+
+Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Детализация рисков Р-1…Р-5 BRD §8 в привязке к решениям
+> ADR-001 (D1…D10).
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Регресс горячих путей при параметризации env-словарей акторов** (launcher ×2 / self-deploy / post-deploy): опечатка в ключе/дефолте ломает git-коммиты или credentials-резолв claude CLI (HOME) у ВСЕХ проектов общего инстанса (Р-1 BRD) | Низ. | Выс. | Дефолты байт-в-байт = боевым (`/home/slin`, `claude-bot@mva154.local` — BR-5); TC-04/TC-05 фиксируют итоговые словари при дефолтах И при переопределении; полный регресс TC-12; staging-гейт 8501 перед прод-выкатом (NFR-1) |
+| TR-2 | **Ослабление инварианта ORCH-058 при конфигуризации staging-порта** (`ORCH_STAGING_PORT=8500` нацеливает rebuild/recreate на прод; Р-2 BRD) | Низ. | Выс. | Fail-closed guard ДО любого ssh/build: `staging_port == deploy_prod_target_port` → отказ + алерт, без тихого fallback (ADR-001 D4); explicit-pass `TARGET_PORT=` хуку сохранён; TC-11 проверяет guard |
+| TR-3 | **Флап анти-регресс сканера** (ложные срабатывания на комментарии/докстринги или вечно-непустой allowlist из-за дефолтов config.py; Р-3 BRD) | Сред. | Низ. | `tokenize`-исключение комментариев/докстрингов (не regex); структурное исключение `src/config.py`+`watchdog/config.py` как канонических мест дефолтов (BR-1); негативная самопроверка TC-02; список литералов централизован (ADR-001 D10) |
+| TR-4 | **Неполный аудит**: пропущенный хардкод всплывает на первом реальном тираже (Р-4 BRD) | Сред. | Сред. | Реестр §3.1 нормативен и перепроверен на стадии architecture повторным grep'ом (код-блокеры = ровно A1–A4, см. ADR-001 «Контекст»); сканер CI держит классы литералов навсегда; smoke-процедура (D9) — последняя линия обнаружения на целевой инфре |
+| TR-5 | **Правка safety-critical билдеров команд деплоя** (D7: `build_deploy_command` / `image_freshness` env-prefix; D5: `command:` прод-сервиса compose) — ошибка ломает self-deploy/rollback | Низ. | Выс. | Изменения строго аддитивные: одно env-присваивание `REPO=` (exit-контракт хука 0/1/2 не тронут, ORCH-036 прочитан); `command:` прод = байт-в-байт текущему CMD при дефолтах (TC-06); существующие self-deploy/freshness тесты + staging-прогон |
+| TR-6 | **Путаница источников env**: compose-интерполяция читает `.env`/shell, а не `env_file` (`.env.staging` НЕ влияет на `${VAR}`) → оператор тиража задаёт переменную «не туда» | Сред. | Низ. | Правило явно зафиксировано (ADR-001 D1) и входит в REPLICATION.md; дефолты делают ошибку безопасной (резолв в боевые значения, не в мусор); TC-06 проверяет дефолт-резолв |
+| TR-7 | **Рассинхрон группы ORCH-040** (uid/gid/HOME/маунты/`useradd`) при частичном переопределении (например, сменили `ORCH_AGENT_HOME_DIR`, забыли пересобрать образ с `APP_HOME`) | Низ. | Сред. | Группа управляется одними env-именами насквозь (compose `build.args` ← те же `ORCH_RUN_UID/GID`/`ORCH_AGENT_HOME_DIR`, ADR-001 D5/D6); «МИНА 1» `group_add` сохранена; согласованная группа описана в REPLICATION.md как «менять вместе»; TC-06/TC-07 |
+| TR-8 | **Слабые/затёртые секреты**: детерминированная генерация или молчаливая перезапись `.env` уничтожает работающий комплект | Низ. | Выс. | `secrets.token_hex(32)` (криптослучайно, 32 байта); отказ при существующем файле, перезапись только явным `--force` (NFR-3, ADR-001 D8); TC-09 проверяет различие повторных запусков и отказ |
+
+## Сводный вывод
+
+Доминирующий класс — **регресс общего прод-инстанса через горячие пути** (TR-1/TR-2/TR-5):
+вероятность низкая (kill-switch-природа дефолтов: на текущем хосте без новых env поведение 1:1),
+влияние высокое (self-hosting, общая БД с enduro-trails) → ключевая страховка — полный регресс +
+обязательный staging-гейт 8501 + ручной `Confirm Deploy` (прод-контейнер в рамках задачи не
+рестартуется, NFR-1). Эскалация `arch:major-change` **не требуется**: ни новой стадии, ни нового
+компонента, ни смены БД — конвейер и QG байт-в-байт (NFR-6); возврат в анализ не нужен (ТЗ
+выполнимо без нарушения принципов). Остаточный риск для прод-конвейера — **низкий**.

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

@@ -0,0 +1,118 @@
+---
+verdict: APPROVED
+work_item: ORCH-101
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-101
+version: 1
+---
+
+# Review ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
+
+## Summary
+
+PR (`feature/ORCH-101-orch-10-common-smoke`, commit `f1635dd`) реализует фундамент тиража
+ровно по ТЗ (`02-trz.md`) и ADR (`06-adr/ADR-001`, D1–D10): нормативный реестр хардкодов §3.1
+закрыт полностью, секреты нового хоста выпускаются `scripts/gen_secrets.py`, smoke-процедура —
+runbook `docs/operations/REPLICATION.md` с явными PASS/FAIL. Полный `pytest tests/ -q` зелёный
+(**1764 passed**), включая 6 новых/адаптированных тест-модулей. P0/P1 findings — нет;
+два косметических P3. Вердикт: **APPROVED**.
+
+### Ось 1 — Соответствие ТЗ (FR-1…FR-7, AC-1…AC-8)
+
+| AC | Статус | Проверено |
+|----|--------|-----------|
+| AC-1 ноль хардкодов в `src/**` | ✅ | A1 `plane_sync.notify_stage_change` → `gitea_public_url or gitea_url` + `gitea_owner` (семантика существующих потребителей, литералы `git.mva154.duckdns.org`/`/admin/` удалены); A2 — единый `launcher.agent_git_env()` для ОБОИХ мест (Popen агента + post-run git); A3/A4 — `self_deploy`/`post_deploy` читают `agent_home_dir`/`git_email_domain`, платформенные имена `deploy-finalizer`/`post-deploy-monitor` сохранены (D2); A5 → ключ `staging_port` + guard (D4); A6 → платформенная константа c обоснованием в ADR D3 и пин-тестом (`test_self_hosting_repo_is_platform_constant` фиксирует и значение, и ОТСУТСТВИЕ конфиг-ключа); A7 — основной путь уже config-backed, except-ветка запрещённых литералов не содержит (ADR D10). Контрольный grep: остаточные `mva154`/`/home/slin` в `src/**`/`watchdog/**` — только комментарии/докстринги. Сканер существует, allowlist пуст, зелёный |
+| AC-2 zero-regression | ✅ | дефолты новых ключей = боевым (`test_new_settings_defaults_equal_previous_production_values`, судит по `Settings.model_fields` — иммунно к ambient env); реестр E не тронут (там же); резолв compose при пустом env = боевым значениям (TC-06, `EXPECTED_DEFAULTS` — единая нормативная карта); `pytest tests/ -q` → 1764 passed; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/verdict-ключи/схема БД дифф не трогает |
+| AC-3 smoke-процедура | ✅* | `REPLICATION.md` §4: 7 шагов, каждый с явными PASS/FAIL, однозначный итоговый вердикт; stateless (§5); кирпичи существующие (D9, скрипт-обвязка сознательно не вводилась). *Прогон воспроизводимости — стадия `testing` (см. «Передача тестеру») |
+| AC-4 доки + CHANGELOG | ✅ | см. раздел «Документация» ниже |
+| AC-5 секреты | ✅ | `secrets.token_hex(32)` = 64 hex (тест `test_secret_is_cryptorandom_64_hex` + неравенство повторных запусков); `--write` через `open(path, "x")` — атомарный отказ exit=2 на существующем файле, перезапись только `--force` (NFR-3, покрыто тестами); чек-лист внешних токенов §3.2 (где выпустить → куда вписать → как проверить) + норматив «боевые секреты не копируются»; `.env.example` дополнен (полнота сверяется `test_env_example_contains_*` и `test_output_keys_consistent_with_env_example`); реальных секретов в гите нет (плейсхолдеры пустые, анти-тест `test_no_real_secret_committed_anywhere_near`) |
+| AC-6 инфра-файлы | ✅ | реестр B1–B6/C1–C2/D1 закрыт: compose — полная интерполяция `${VAR:-default}` (карта D6 1:1); Dockerfile — `ARG APP_UID/GID/USER/HOME`, CMD exec-form 8500 сознательно сохранён (D5, PID-1/сигнальная семантика); hook — `REPO="${REPO:-…}"` + ОБА инвокера передают `REPO=` явно (D7, иначе override был бы мёртв — закрыто `test_rebuild_staging_passes_configured_port_and_repo`/`test_build_deploy_command_passes_repo_explicitly`) |
+| AC-7 анти-регресс | ✅ | `test_no_host_hardcodes.py`: централизованный `FORBIDDEN`, `tokenize`-исключение комментариев/докстрингов (NFR-5, детерминирован), структурное исключение config-модулей по ADR D10 (не allowlist-запись), allowlist пуст + тест на пустоту, негативные самопроверки ×4 (plain/env-dict/f-string/значение при докстринге выше) + guard от пустой зоны скана (`test_scan_zone_is_nonempty`) |
+| AC-8 self-hosting / инварианты | ✅ | прод-контейнер не трогается (изменения compose/Dockerfile вступают в силу на следующем штатном деплое); ORCH-058 **усилен**: fail-closed guard `staging_port == deploy_prod_target_port` → отказ ДО любого ssh/build, без тихого fallback, + Telegram-алерт (тесты: guard срабатывает на 8500/8500 и НЕ срабатывает на дефолте 8501/8500); INV-4 не затронут; маркеры соседей сохранены (ось 2) |
+
+### Ось 2 — Соответствие ADR + трассировка (TRACEABILITY)
+
+Реализация 1:1 по D1–D10. Правки блоков с чужими маркерами сверены с их ADR:
+
+- **ORCH-040** (adr-0005): `group_add` «МИНА 1» сохранён на всех трёх сервисах (только литерал →
+  `${ORCH_DOCKER_GID:-999}`); uid/gid/HOME/маунт-таргеты двигаются одной группой env
+  (`user:` + `build.args APP_*` + таргеты `.claude`/`.ssh` — все от `ORCH_RUN_UID/GID`/
+  `ORCH_AGENT_HOME_DIR`); адаптация `test_orch040_compose.py` корректна — судит резолв дефолтов,
+  инвариант НЕ ослаблен (смена дефолта по-прежнему валит тест).
+- **ORCH-058** (adr-0008): explicit-pass дисциплина сохранена (`TARGET_PORT=` по-прежнему передаётся
+  явно, источник — валидируемый ключ); анти-prod инвариант из подразумеваемой константы стал
+  исполняемым guard'ом — усиление, не ослабление; имена сервиса/профиля остались константами.
+- **ORCH-036** (adr-0007): exit-code контракт хука 0/1/2 не тронут — в префикс добавлено ровно одно
+  env-присваивание `REPO=`; detached Phase B не изменён.
+- **INV-4**: дифф не содержит push/force-push в `main`; merge-путь не тронут.
+- Сквозной `adr-0036` заведён (кросс-каттинг по TRACEABILITY — корректно, блоки несут 3 маркера).
+
+### Ось 3 — Качество кода
+
+- `agent_git_env()` устраняет дублирование ×2 в launcher (DRY) и структурно исключает дрейф двух
+  мест; docstrings на всех новых публичных функциях (`agent_git_env`, `generate_secret`,
+  `build_fragment`, `main`).
+- Guard в `check_staging_image_fresh` размещён правильно: после дешёвых kill-switch/`applies`
+  (нулевой оверхед для неприменимых репо), ДО любого ssh/build; Telegram-алерт best-effort
+  (`try/except`, never-raise сохранён).
+- Тесты содержательные: функциональные через monkeypatch-швы (link-build без сети, guard, передача
+  `REPO=`/`TARGET_PORT=` в собранную команду), структурные пины там, где env-словарь строится inline
+  в never-raise акторе — осознанный выбор, задокументирован в докстринге модуля. Негативные
+  самопроверки исключают «вечно-зелёный» сканер. `test_deploy_hook_rollback_sim.py` переведён на
+  env-override `REPO` — симуляция теперь дополнительно доказывает работоспособность override.
+- Security: секретные значения в `.env.example` — пустые плейсхолдеры; генератор не несёт зашитых
+  hex-значений (анти-тест); `open(..., "x")` — race-safe отказ от перезаписи.
+
+### Ось 4 — Документация
+
+Полностью обновлена в том же PR, см. раздел «Документация» ниже. README «Известные ограничения»
+(ORCH-079): ни один из трёх открытых пунктов (Telegram 48h / intra-repo deps / пакетный автоном)
+задачей не закрывается — обновление витрины не требуется; таблица env README дополнена.
+
+## Findings
+
+### P0 — Blocker
+— нет.
+
+### P1 — Must fix
+— нет.
+
+### P2 — Should fix
+— нет.
+
+### P3 — Nice to have (не блокирует, на усмотрение следующих задач)
+- [ ] `src/plane_sync.py::notify_stage_change`: при пустых ОБОИХ `gitea_public_url`/`gitea_url`
+  (нештатная конфигурация) собирается некорректная Markdown-ссылка вида `(/owner/...)`. Покрыто
+  never-raise конвертом и нереально при валидном конфиге (у `gitea_url` непустой дефолт);
+  опциональный guard «пустая база → пропустить ссылку» — косметика. Правило: ТЗ FR-1/A1 требует
+  только источник из Settings — выполнено.
+- [ ] `tests/test_no_host_hardcodes.py::find_violations`: эвристика statement-position пропускает
+  любой bare-string-statement (не только докстринги) — теоретический класс ложноотрицательных
+  (литерал в строке-выражении без присваивания). Реалистичные паттерны регрессии (env-dict,
+  f-string, RHS-значение) закрыты негативными самопроверками; ужесточение — отдельной задачей при
+  желании. Правило: NFR-5/AC-7 — выполнены как сформулированы.
+
+## Документация
+
+| Артефакт | Статус |
+|----------|--------|
+| `CHANGELOG.md` | ✅ запись ORCH-101 (детальная, по слоям D1–D10) |
+| `CLAUDE.md` | ✅ новая секция «Тираж платформы: фундамент 10-common» |
+| `README.md` | ✅ таблица env (+6 строк ORCH-101) + ссылка на REPLICATION.md; «Известные ограничения» не затронуты (корректно) |
+| `docs/architecture/README.md` | ✅ секция ORCH-101 со ссылками на adr-0036/work-item ADR |
+| `docs/operations/INFRA.md` | ✅ карта env дополнена (7 строк) + норматив секретов + когерентность портов |
+| `docs/operations/REPLICATION.md` | ✅ новый runbook: границы/конвенции, карта env, секреты, smoke PASS/FAIL, stateless |
+| ADR per work-item + сквозной | ✅ `06-adr/ADR-001-…` + `adr-0036-…` (frontmatter-схема 52c корректна) |
+| `.env.example` / `.env.staging.example` | ✅ полнота ключей старта (закреплена тестами) / согласован |
+
+## Передача тестеру (не findings)
+
+- **AC-3 (воспроизводимость):** заявленный прогон smoke-процедуры на текущей инфре
+  (staging 8501 + sandbox-проект) исполняется на стадии `testing` и фиксируется в
+  `13-test-report.md`/`15-staging-log.md` — без этой фиксации AC-3 не считается закрытым.
+- Smoke `serial_gate`/`GET /queue` — штатно по канону tester-промпта.

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

@@ -0,0 +1,88 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-101
+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-101
+---
+
+# Test Report — ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
+
+## Окружение
+- 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-101-orch-10-common-smoke`
+- Ветка: `feature/ORCH-101-orch-10-common-smoke` (HEAD `26fe4cd`, код задачи — `f1635dd`)
+- Прогон выполнен в worktree ветки задачи (не в общем `/repos/orchestrator`).
+- Вердикт ревью (`12-review.md`): **APPROVED**.
+
+## Smoke API (read-only)
+| Проверка | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — активная задача ORCH-101 на стадии `testing` |
+| `GET /queue` | PASS — отдаёт полезную нагрузку |
+| Блок `serial_gate` в `/queue` (ORCH-088) | PASS — присутствует; `orchestrator.active_task = ORCH-101 (testing)`, не заморожен |
+| Блок `auto_labels` в `/queue` (ORCH-089) | PASS — присутствует (`enabled`, `autoApprove`/`autoDeploy`) |
+| `GET /metrics` | PASS — `schema_version:1`, стадия ORCH-101 видна |
+
+## Smoke-процедура тиража (AC-3 / FR-5)
+Воспроизводимость smoke-runbook подтверждена на текущей инфре (read-only, без переноса данных):
+| Шаг | Результат |
+|-----|-----------|
+| `docs/operations/REPLICATION.md` существует (runbook с PASS/FAIL) | PASS (13 КБ) |
+| `scripts/gen_secrets.py` запускается в безопасном (print) режиме | PASS — exit 0, файлы не тронуты |
+| Webhook-секреты крипто-случайны (64 hex = 32 байта) | PASS — `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` |
+| Внешние токены — только плейсхолдеры (пустые) | PASS |
+| Инстанс поднят и health-check зелёный (см. Smoke API) | PASS |
+
+## Результаты (покрытие TC из `04-test-plan.yaml`)
+
+| TC ID | Описание | Покрывающие тесты | Результат |
+|-------|----------|-------------------|-----------|
+| TC-01 | Анти-регресс скан: нет запрещённых литералов в исполняемом коде `src/**`+`watchdog/**` (AC-1, AC-7) | `test_no_host_hardcodes::test_no_host_hardcodes_in_executable_code`, `test_scan_zone_is_nonempty`, `test_allowlist_is_empty_at_acceptance` | PASS |
+| TC-02 | Негативная самопроверка сканера: подсаженный литерал детектируется (AC-7) | `test_scanner_catches_planted_literal_in_code`/`_in_env_dict`/`_in_fstring`, `test_scanner_ignores_comments_and_docstrings` | PASS |
+| TC-03 | `plane_sync.notify_stage_change` строит ссылки из `gitea_public_url`(fallback `gitea_url`)+`gitea_owner`; литералы удалены (AC-1/FR-1 A1) | `test_host_config_keys::test_stage_change_link_uses_public_url_and_owner`/`_falls_back_to_gitea_url`/`_hardcoded_base_removed_from_source` | PASS |
+| TC-04 | Env агент-процесса (launcher ×2): HOME+git-идентичность из settings, дефолты прежние (AC-1/AC-2/FR-1 A2) | `test_host_config_keys::test_agent_git_env_reads_settings`/`_default_identity_matches_previous_hardcode`/`_preserves_ambient_environ`/`test_both_launcher_sites_use_the_helper` | PASS |
+| TC-05 | Env `self_deploy`/`post_deploy`: HOME+идентичность из settings, литералы удалены (AC-1/AC-2/FR-1 A3–A4) | `test_host_config_keys::test_system_actor_envs_read_settings` | PASS |
+| TC-06 | Структурная проверка `docker-compose.yml`: интерполяция `${VAR:-default}`, `group_add` ×3 (ORCH-040) (AC-2/AC-6) | `test_infra_parametrization::test_compose_interpolation_defaults_match_production_values`/`_group_add_docker_gid_on_all_three_services`/`_uid_gid_home_move_as_one_group`/`_ports_parametrised`/`_container_layout_paths_stay_constant`/`_no_raw_host_paths` | PASS |
+| TC-07 | `Dockerfile`: uid/gid/username/home через `ARG`; CMD-порт по ADR (AC-2/AC-6) | `test_infra_parametrization::test_dockerfile_useradd_parametrised_via_args`/`test_dockerfile_cmd_stays_exec_form_8500` | PASS |
+| TC-08 | Полнота `.env.example`: все новые ключи, секреты — плейсхолдеры; deploy-hook `REPO` env-override (AC-5/AC-6) | `test_infra_parametrization::test_env_example_contains_all_new_keys`/`_contains_start_mandatory_keys`/`_secrets_are_placeholders_only`/`test_deploy_hook_repo_is_env_overridable` | PASS |
+| TC-09 | Генератор секретов: разные значения, ≥32 байта, не затирает `.env` молча (AC-5/FR-4/NFR-3) | `test_secrets_gen::test_secret_is_cryptorandom_64_hex`/`test_two_runs_give_different_values`/`test_write_refuses_existing_file_without_force`/`test_write_creates_new_file_and_force_overwrites`/`test_output_keys_consistent_with_env_example`/`test_default_mode_prints_and_touches_no_files`/`test_no_real_secret_committed_anywhere_near` | PASS |
+| TC-10 | Smoke-док + обвязка: `REPLICATION.md` с PASS/FAIL, INFRA.md дополнен, CHANGELOG (AC-3/AC-4/FR-5/FR-7) | `test_replication_smoke::test_replication_doc_has_smoke_procedure_with_pass_fail`/`_covers_secrets_checklist`/`_has_env_map_and_boundaries`/`_is_stateless`/`test_infra_env_map_extended`/`test_changelog_has_orch_101_entry`/`test_gen_secrets_runs_in_safe_mode` | PASS |
+| TC-11 | Инвариант ORCH-058 (A-1): `staging_port` дефолт 8501, guard «≠ прод-порт» (AC-8/FR-1 A5) | `test_host_config_keys::test_staging_port_guard_refuses_prod_port`/`test_staging_port_default_passes_guard`/`test_self_hosting_repo_is_platform_constant` | PASS |
+| TC-12 | Полный регресс `pytest tests/` зелёный на дефолтной конфигурации (AC-2/BR-5) | весь набор — **1764 passed** | PASS |
+
+Соответствие критериям `03-acceptance-criteria.md`: AC-1 (TC-01/02/03/04/05), AC-2 (TC-04/05/06/07/12),
+AC-3 (TC-10 + smoke-прогон выше), AC-4 (TC-10), AC-5 (TC-08/09), AC-6 (TC-06/07/08),
+AC-7 (TC-01/02), AC-8 (TC-11) — все покрыты и зелёные.
+
+## Вывод pytest
+```
+============================= test session starts ==============================
+platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
+rootdir: /repos/_wt/orchestrator/feature_ORCH-101-orch-10-common-smoke
+configfile: pytest.ini
+plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
+...
+================== 1764 passed, 1 warning in 72.41s (0:01:12) ==================
+```
+(единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, предсуществующий, не связан с задачей.)
+
+Целевые модули задачи (отдельный прогон):
+```
+tests/test_no_host_hardcodes.py tests/test_host_config_keys.py
+tests/test_infra_parametrization.py tests/test_secrets_gen.py tests/test_replication_smoke.py
+======================== 51 passed, 1 warning in 0.73s =========================
+```
+
+## Итог
+**PASS** — полный регресс зелёный (1764 passed), все 12 TC из `04-test-plan.yaml` выполнены и
+сопоставлены с критериями `03-acceptance-criteria.md`, smoke API read-only (включая блоки
+`serial_gate` и `auto_labels` в `/queue`) и smoke-процедура тиража (AC-3: `REPLICATION.md` +
+безопасный прогон `gen_secrets.py`) зелёные. Задача переходит на `deploy-staging`.

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

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-101
+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-101/15-staging-log.md

@@ -0,0 +1,37 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-101
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+timestamp: 2026-06-10T18:02:26Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance (8501),
+run inside the `orchestrator-staging` container via the canonical
+`scripts/staging_check.py --base-url http://localhost:8501 --mode stub`.
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+- REAL failed: none — all real checks green.
+- SANDBOX_INFRA failed (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
+
+## Block detail
+
+- Block A (SMOKE): A1 /health 200, A2 /queue 200, A3 ORCH_STAGING=true — all PASS.
+- Block B (ACCESS): B4 Plane sandbox accessible, B5 Gitea push=true, B6 registry isolation
+  (sandbox present, prod ET/ORCH absent) — all PASS.
+- Block C (E2E, stub): C7 create issue PASS, C8 trigger pipeline PASS,
+  C9a/C9b waived sandbox-infra (depend on SANDBOX bot accounts being project members, not the pipeline).
+- Cleanup: Plane issue deleted (HTTP 204).
+
+Exit code 0 with infra-tolerance enabled (`staging_infra_tolerance_enabled=True`).
+Verdict mapping unchanged: trust the exit code → SUCCESS.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
+
+Work Item ID: ORCH-102
+
+## Description
+
+TBD

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

@@ -0,0 +1,211 @@
+---
+work_item: ORCH-102
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD: ORCH-102 — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
+
+Work Item: **ORCH-102** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
+Заказчик: Слава · Эпик: **ORCH-10** (домен D5 «Масштаб», `docs/epics/self-evolution.md`) · Тип: **A — Lite**
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1. Цель эпика ORCH-10
+Тираж платформы — РАЗДАЧА текущей функциональности нескольким заказчикам **на тест**.
+Решения Владельца 10.06 (приняты как требования, см. §1.4): ДВА типа тиража, ОБА **stateless**
+(наши задачи/данные/секреты НЕ переносим — чистый старт):
+
+- **Тип A (Lite)** — переносим ТОЛЬКО орк+watchdog на новую инфру; окружение
+  (Plane / Gitea / LLM / Telegram) заказчик донастраивает сам **по чёткой инструкции**.
+- **Тип B (Bundled)** — весь стек одним комплектом (отдельная задача эпика, вне ORCH-102).
+
+### 1.2. Проблема, которую закрывает ORCH-102
+Фундамент **10-common (ORCH-101) уже в `main`**: все хост-значения параметризованы env
+(`docker compose config` без переменных = боевое поведение 1:1), секреты выпускаются заново
+(`scripts/gen_secrets.py`), есть smoke-процедура с PASS/FAIL (`docs/operations/REPLICATION.md` §4)
+и анти-регресс `tests/test_no_host_hardcodes.py`. **Технически** платформа разворачивается на
+чужом хосте без правки кода.
+
+**Операционно** — нет: знания размазаны по 4+ документам, каждый из которых писался для
+оператора НАШЕГО хоста, а не для заказчика на чистой инфре:
+
+| Документ | Что покрывает | Чего не хватает для Lite |
+|----------|---------------|--------------------------|
+| `docs/operations/REPLICATION.md` | карта env, секреты, smoke | явно НЕ описывает установку/подключение Plane/Gitea (анти-скоуп Р-5 ORCH-101) |
+| `docs/operations/ONBOARDING.md` | онбординг проекта (статусы/лейблы/репо/kit/реестр) | предполагает уже работающий оркестратор и наш хост |
+| `docs/operations/SETUP_WEBHOOKS.md` | формат вебхуков Plane/Gitea | примеры с боевыми URL (`mva154`), не generic |
+| `docs/operations/INFRA.md` | топология/рестарты нашего хоста | не инструкция «с нуля» |
+
+Заказчик сегодня **не может развернуть Lite без доп-вопросов** — отсутствует единый сквозной
+маршрут «голый хост → работающий конвейер». Главный продукт ORCH-102 — **ИНСТРУКЦИЯ**
+`docs/deployment/LITE_SETUP.md` (golden source в репо), закрывающая этот разрыв.
+
+### 1.3. Установленные факты (проверено по репо, не изобретать)
+- **ORCH-101 смержен** (`git log`: merge #122) — ветка задачи уже содержит фундамент: env-карта
+  §2 REPLICATION.md, `gen_secrets.py`, `.env.example` = канон 100% ключей старта (включая блок
+  `WATCHDOG_*`), smoke §4, тесты `test_no_host_hardcodes/test_infra_parametrization/test_secrets_gen/test_replication_smoke`.
+- **`docker-compose.yml` УЖЕ является compose-подмножеством Lite:** ровно три сервиса —
+  `orchestrator`, `orchestrator-watchdog`, `orchestrator-staging` (последний строго за
+  `profiles: [staging]`); сервисов Plane/Gitea в compose НЕТ. Дефолтный `docker compose up -d`
+  поднимает ровно орк+watchdog. AC-2 достижим без форка compose — нужны фиксация в доке и
+  анти-дрейф тест.
+- **Plane CE не отдаёт webhook через публичный API** — на нашем хосте webhook создан напрямую в
+  PostgreSQL / через UI (`SETUP_WEBHOOKS.md`). Инструкция Lite обязана дать заказчику оба пути
+  (UI и DB) для ЕГО инсталляции Plane.
+- **Точная модель статусов**: 22 канонических имени с группами (источник —
+  `plane_sync._PLANE_NAME_TO_KEY`; таблица — `ONBOARDING.md` §1; создаёт
+  `scripts/onboard_project.py apply`). Код-критичные fail-closed: `Confirm Deploy`, `STOP`
+  (группа `cancelled`); в терминальных группах — только Done/Cancelled/STOP.
+- **Branch protection на `main` нормативно ЗАПРЕЩЁН** (ORCH-009 ADR D10: required-approvals /
+  status-checks ломают PR-merge API merge-актора → ложные HOLD). **Pre-receive хуков в платформе
+  НЕТ** — защита держится конвенцией + скоупом токенов. Формулировка бизнес-запроса
+  «pre-receive хуки» конфликтует с этим нормативом → вопрос архитектору (ТЗ §3.8 А-1);
+  рекомендация: раздел Gitea фиксирует канон (репо+токен+webhook+«protection НЕ включать»).
+- **Гэп watchdog-конфига:** compose читает `.env.watchdog` (`required: false`), но
+  `.env.watchdog.example` в репо НЕТ (есть только `.env.example`/`.env.staging.example`);
+  ключи `WATCHDOG_*` задокументированы внутри `.env.example`. Инструкции нужен однозначный
+  рецепт настройки watchdog-бота (форма — вопрос архитектору А-4).
+- **Платформенные конвенции тиража** (REPLICATION.md §1, нормативно): репо платформы обязан
+  называться `orchestrator` (`SELF_HOSTING_REPO`); имена сервисов/профиля — константы;
+  контейнерный layout (`/app/data`, `/repos`, `/opt/claude-code`) не параметризуется.
+- **Прецедент приёмки smoke**: ORCH-101 AC-3 — воспроизводимость подтверждается прогоном на
+  текущей инфре (staging-песочница `ORCH_STAGING_PORT`=8501 + sandbox-проект), без нового железа.
+
+### 1.4. Решения Владельца (10.06) — приняты как требования
+| # | Решение |
+|---|---------|
+| D-1 | Тиражей ДВА типа: A (Lite) и B (Bundled); ORCH-102 реализует ТОЛЬКО A. |
+| D-2 | Оба типа **stateless**: наши задачи/данные/секреты не переносятся; на целевой инфре чистый старт. |
+| D-3 | Lite = перенос ТОЛЬКО орк+watchdog; окружение (Plane/Gitea/LLM/Telegram) заказчик донастраивает по инструкции. |
+| D-4 | Главный продукт задачи = **инструкция** `docs/deployment/LITE_SETUP.md` — golden source в репо. |
+| D-5 | Зависимость: ORCH-102 ← **10-common (ORCH-101)** — выполнена (смержен), блокеров нет. |
+
+---
+
+## 2. Объём (scope)
+
+### 2.1. В объёме
+- **Инструкция `docs/deployment/LITE_SETUP.md`** — полная пошаговая (каждый шаг = команда +
+  проверка), покрывающая сквозной маршрут: предусловия хоста (зависимости, uid/gid) → перенос
+  кода орк+watchdog → конфиг (`.env` с нуля + секреты) → подключение Plane (workspace/проект,
+  точная модель статусов, API-токен, webhook+HMAC) → подключение Gitea (репо, токен, webhook,
+  норматив защиты `main`) → LLM-доступ (claude CLI / ключи моделей) → Telegram (бот трекера +
+  watchdog-бот + chat-id) → запуск compose-подмножества → регистрация проекта
+  (`ORCH_PROJECTS_JSON`, `src/projects.py`) → health-чек → smoke (из 10-common) → траблшутинг.
+- **Фиксация compose-подмножества** (AC-2): документировано и защищено структурным тестом, что
+  дефолтный запуск = ровно орк+watchdog, без Plane/Gitea-контейнеров.
+- **Stateless-нормативы** в инструкции (AC-3): чистая БД, новые секреты, явный запрет переноса
+  наших задач/данных/секретов.
+- **Smoke на чистом окружении** (AC-4): воспроизводимая процедура/чек-лист (переиспользование
+  REPLICATION.md §4) + зафиксированный приёмочный прогон.
+- **Анти-дрейф тесты** структуры/полноты инструкции и compose-подмножества; полный pytest
+  зелёный; `CHANGELOG.md`; перекрёстные ссылки (REPLICATION.md §1 границы, README — по объёму).
+
+### 2.2. Вне объёма (явно, не делать)
+- **Тип B (Bundled)** — весь стек одним комплектом: отдельная задача эпика.
+- **Установка самих Plane / Gitea / Telegram / LLM-аккаунтов** — заказчик ставит по официальной
+  документации вендоров; ORCH-102 покрывает только ПОДКЛЮЧЕНИЕ к оркестратору (анти-скоуп-крип,
+  зеркало Р-5 ORCH-101).
+- **Изменения рантайма/конвейера**: ожидаемый объём — docs+tests; `src/**` не трогается;
+  `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — байт-в-байт.
+- **Перенос данных**: ни БД, ни задач, ни worktree, ни секретов (D-2).
+- **Новая автоматизация** поверх существующих CLI (`gen_secrets.py`, `onboard_project.py`):
+  новые скрипты не вводятся без решения архитектора.
+- **Коммерческая механика раздачи** (доступ заказчика к коду, лицензии, поддержка) —
+  операторский/владельческий уровень; в инструкции — параметризованный источник кода.
+- **Введение pre-receive хуков / branch protection** — запрещено действующим нормативом
+  ORCH-009 ADR D10 (см. §1.3); пересмотр только явным ADR архитектора.
+
+---
+
+## 3. Заинтересованные стороны
+- **Владелец (Слава)** — раздаёт платформу заказчикам на тест; принимает инструкцию как продукт.
+- **Заказчик-тестер (новый оператор)** — целевой читатель LITE_SETUP.md: разворачивает Lite на
+  своей инфре без доп-вопросов; технически грамотен (linux/docker), платформу видит впервые.
+- **Оператор текущего прода** — прогоняет приёмочный smoke на staging-песочнице; его прод
+  (общий для enduro-trails) не должен быть затронут.
+- **Будущая задача 10b (Bundled)** — переиспользует разделы Lite-инструкции; границы фиксируются
+  в REPLICATION.md §1.
+
+---
+
+## 4. Бизнес-требования (BR)
+
+| ID | Требование | Связь |
+|----|------------|-------|
+| BR-1 | Существует `docs/deployment/LITE_SETUP.md` — **полная пошаговая** инструкция Lite-тиража: по ней человек, не видевший платформу, разворачивает орк+watchdog и донастраивает окружение **без доп-вопросов**; **каждый шаг несёт команду и проверку** (ожидаемый результат / PASS-FAIL). | AC-1, FR-1, D-4 |
+| BR-2 | Инструкция покрывает ВСЕ системы донастройки: Plane (workspace/проект, точная модель статусов — 22 имени с группами, API-токен, webhook+HMAC с учётом ограничения Plane CE), Gitea (репо, токен с нужными scope, per-repo webhook, норматив «branch protection `main` НЕ включать»), LLM (claude CLI: дистрибутив/node/аутентификация/`ORCH_CLAUDE_BIN`/модели), Telegram (бот трекера + ОТДЕЛЬНЫЙ watchdog-бот + получение chat-id), регистрацию проекта (`ORCH_PROJECTS_JSON` через `onboard_project.py`), health-чек, smoke. | AC-1, FR-4 |
+| BR-3 | Разворачивается **compose-подмножество только орк+watchdog**: дефолтный `docker compose up -d` поднимает ровно `orchestrator`+`orchestrator-watchdog`; Plane/Gitea-контейнеров в compose нет; staging-сервис — строго за профилем. Свойство зафиксировано в доке и защищено структурным тестом. | AC-2, FR-2 |
+| BR-4 | **Stateless**: инструкция предписывает чистую БД (создаётся пустой при первом старте), выпуск НОВОГО комплекта секретов (`gen_secrets.py` + чек-лист внешних токенов), и нигде не предписывает перенос наших задач/данных/секретов; в самой доке — только плейсхолдеры, ни одного реального секрета/боевого токена. | AC-3, FR-3 |
+| BR-5 | **Smoke на чистом окружении** существует как воспроизводимая процедура/чек-лист с PASS/FAIL (переиспользование REPLICATION.md §4, без форка); приёмочный прогон выполнен на чистом контуре (минимум — staging-песочница + sandbox-проект, прецедент ORCH-101 AC-3) и зафиксирован в артефактах задачи. | AC-4, FR-5 |
+| BR-6 | **Канон не форкается**: канонические таблицы (модель статусов, карта env, формат вебхуков) инструкция даёт ссылкой на golden source (`ONBOARDING.md`/`REPLICATION.md`/`SETUP_WEBHOOKS.md`) либо с анти-дрейф тестом при неизбежном дублировании; копируемые команды инструкции — generic (плейсхолдеры вместо боевых URL/путей). | AC-1/AC-6, FR-4, NFR-4 |
+| BR-7 | Полный `pytest tests/ -q` зелёный; запись в `CHANGELOG.md`; перекрёстные доки обновлены (REPLICATION.md §1 «границы» — строка Type A → ссылка/статус; README/CLAUDE.md — по фактическому объёму, правило агентов №2/№6). | AC-5, FR-6/FR-7 |
+| BR-8 | Полнота/структура инструкции защищена **структурным pytest** (анти-дрейф, по образцу `tests/test_replication_smoke.py`): исчезновение обязательного раздела/кирпича/env-ключа из дока или дрейф compose-подмножества ломает CI. | AC-6, FR-6 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| NFR-1 | **Self-hosting безопасность:** задача docs+tests; прод-контейнер `orchestrator` не перезапускается; прод-выкат — только штатным конвейером (staging 8501 → ручной Confirm Deploy). |
+| NFR-2 | **Нулевая регрессия:** поведение рантайма не меняется (ожидаемо ноль изменений `src/**`); `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт; существующие тесты (включая `test_no_host_hardcodes`, `test_replication_smoke`) остаются зелёными. |
+| NFR-3 | **Секрет-гигиена:** ни в инструкции, ни в тестах — ни одного реального секрета/токена/боевого webhook-секрета; только плейсхолдеры и ссылки на `gen_secrets.py`; security-гейт (ORCH-022) зелёный. |
+| NFR-4 | **Единый источник истины:** инструкция — маршрутизатор поверх канонов, не их копия; неизбежные дубли защищены анти-дрейф тестом (сверка с кодом/каноном импортом, не строкой). |
+| NFR-5 | **Поддерживаемость golden source:** LITE_SETUP.md версионируется в репо и поддерживается агентами при каждой доработке, меняющей шаги тиража (правило агентов №2 — дока в том же PR). |
+| NFR-6 | **Копируемость команд:** каждый код-блок инструкции выполняется на чистом хосте дословно после подстановки явно перечисленных плейсхолдеров (`<...>`); никаких неявных «подразумевается, что…». |
+
+---
+
+## 6. Допущения и ограничения
+- **Поддерживаемый контур** (фиксируется в предусловиях инструкции): Linux x86_64, Docker Engine +
+  Compose v2, git, python3; пользователь с правами docker; диск/память по минимальным требованиям
+  (значения уточнит архитектор/инструкция). Иные ОС/архитектуры — вне гарантии Lite.
+- **Заказчик сам ставит** Plane CE, Gitea, заводит Telegram-ботов и LLM-доступ (Claude
+  CLI-аутентификация / ключи) — по официальным докам вендоров; наша инструкция начинается с
+  «системы установлены и доступны по сети».
+- **Имя репо платформы — `orchestrator`** (норматив REPLICATION.md §1 / `SELF_HOSTING_REPO`);
+  инструкция не предлагает его менять.
+- **Источник кода** для заказчика (clone-URL/архив) — решение Владельца; в инструкции —
+  параметризованный шаг (А-6 в ТЗ).
+- «Без доп-вопросов» (AC-1) операционализируется проверяемо: (а) каждый шаг несёт
+  команду+проверку, (б) приёмочный smoke-прогон по инструкции на чистом контуре зафиксирован,
+  (в) траблшутинг покрывает типовые отказы первичной настройки.
+- Терминология бизнес-запроса «pre-receive хуки» трактуется по факту платформы (§1.3):
+  канонический механизм защиты — конвенция + скоуп токенов + запрет branch protection;
+  окончательная формулировка раздела Gitea — за архитектором (А-1).
+
+---
+
+## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
+- AC-1: `docs/deployment/LITE_SETUP.md` — полная пошаговая, человек разворачивает без
+  доп-вопросов (каждый шаг — команда/проверка).
+- AC-2: compose-подмножество только орк+watchdog (без Plane/Gitea-контейнеров).
+- AC-3: stateless — чистая БД, ни одной нашей задачи/секрета.
+- AC-4: smoke на чистом окружении проходит (минимум — воспроизводимая процедура/чек-лист).
+- AC-5: pytest зелёный; CHANGELOG.
+- AC-6 (детализация): анти-дрейф тесты структуры дока/compose; канон не форкается.
+- AC-7 (детализация): self-hosting безопасность, инварианты конвейера не тронуты.
+
+---
+
+## 8. Риски (детали — 10-tech-risks.md, заполняет архитектор)
+- R-1 — **Дрейф инструкции**: платформа развивается, шаги устаревают → структурные тесты (BR-8)
+  + правило golden source (NFR-5).
+- R-2 — **Форк канона**: скопированная таблица статусов/env разъедется с кодом → ссылки/анти-дрейф
+  (BR-6, NFR-4).
+- R-3 — **Непроверяемость «без доп-вопросов»** → операционализация через §6 (команда+проверка,
+  smoke-прогон, траблшутинг).
+- R-4 — **Гетерогенность хостов заказчиков** (rootless docker, иной uid, нет node) → явный
+  поддерживаемый контур + предусловия с проверками (`getent group docker`, владение
+  `ORCH_HOST_REPOS_DIR`).
+- R-5 — **Конфликт «pre-receive» с нормативом ADR D10** → вопрос А-1 архитектору; до решения —
+  канон платформы.
+- R-6 — **Утечка секрета через примеры дока** → NFR-3, security-гейт, тест на отсутствие
+  секретоподобных значений.

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

@@ -0,0 +1,270 @@
+---
+work_item: ORCH-102
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-102 — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
+
+Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно измениться и **где** (документы/контракты/тесты), выведено из BRD и
+> фактического кода (аудит выполнен по репо на ветке задачи; ORCH-101 уже в `main`). **Как**
+> (точная разбивка разделов дока, форма анти-дрейф тестов, исходы вопросов §3.8) — решает
+> архитектор в `06-adr/`.
+
+---
+
+## 1. Сводка изменения
+
+**Docs-first задача** (паттерн ORCH-077/092: документы + тесты, рантайм не трогается).
+Создаётся главный продукт — инструкция `docs/deployment/LITE_SETUP.md` (golden source Lite-тиража,
+новый раздел `docs/deployment/`), которая собирает существующие кирпичи 10-common
+(REPLICATION/ONBOARDING/SETUP_WEBHOOKS/INFRA, `gen_secrets.py`, `onboard_project.py`, smoke §4)
+в один сквозной маршрут «голый хост → работающий конвейер» для заказчика. Дополнительно:
+структурные анти-дрейф тесты (полнота дока, compose-подмножество, stateless/секрет-гигиена),
+перекрёстные ссылки и CHANGELOG.
+
+Ожидаемый дифф: `docs/**`, `tests/**`, `CHANGELOG.md` (+ опционально `.env.watchdog.example` —
+исход А-4). **`src/**` — ноль изменений**; конвейер
+(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `docs/deployment/LITE_SETUP.md` | **создать** — главный продукт (полная пошаговая инструкция Lite; новый каталог `docs/deployment/`) |
+| `docs/operations/REPLICATION.md` | изменить: §1 таблица границ — строка «Type A — Lite» → статус ✅ ORCH-102 + ссылка на LITE_SETUP.md |
+| `tests/test_lite_setup_doc.py` | **создать** — структурные анти-дрейф проверки дока + compose-подмножества (образец: `tests/test_replication_smoke.py`) |
+| `.env.watchdog.example` | создать **по исходу А-4** (канон конфигурации sidecar-watchdog для нового хоста; сейчас примера нет, compose читает `.env.watchdog` `required: false`) |
+| `docs/operations/INFRA.md` | изменить при необходимости: перекрёстная ссылка на deployment-раздел (по фактическому объёму) |
+| `README.md` | изменить: обзорный док — способность Lite-тиража (правило агентов №6: не выдавать открытое за решённое и наоборот) |
+| `CLAUDE.md` | изменить: блок ORCH-102 в паспорте — по фактическому объёму (правило №2) |
+| `CHANGELOG.md` | изменить: запись ORCH-102 |
+| `src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**` | **НЕ менять** (читаются инструкцией/тестами как источник истины; любое отклонение — только через ADR архитектора) |
+
+Кирпичи, которые инструкция **переиспользует по ссылке** (не форкает, BR-6/NFR-4):
+`docs/operations/REPLICATION.md` (карта env §2, секреты §3, smoke §4),
+`docs/operations/ONBOARDING.md` (статусы §1, слои Gitea/kit/реестр §2–5),
+`docs/operations/SETUP_WEBHOOKS.md` (формат вебхуков, Plane CE-каверза),
+`scripts/gen_secrets.py`, `scripts/onboard_project.py` (plan/apply/verify),
+`.env.example` (канон 100% ключей), `GET /health|/queue|/metrics`.
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Документ `docs/deployment/LITE_SETUP.md`: состав и форма
+
+Привязка: BR-1, BR-2. Нормативный перечень разделов (порядок = маршрут оператора; финальную
+разбивку/нумерацию решает архитектор, состав — обязательный минимум):
+
+1. **Рамка Lite** — что разворачиваем (орк+watchdog), что заказчик ставит сам (Plane/Gitea/
+   Telegram/LLM), границы vs 10-common vs Bundled (ссылка на REPLICATION.md §1), платформенные
+   конвенции (репо `orchestrator`, имена сервисов, контейнерный layout — не менять).
+2. **Предусловия хоста** («зависимости, uid/gid» из бизнес-запроса): поддерживаемый контур
+   (Linux x86_64, Docker Engine + Compose v2, git, python3); node + дистрибутив claude-code на
+   хосте (`ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_CODE_DIR` — пути под маунты); пользователь и
+   владение каталогами: `ORCH_RUN_UID/GID` = uid владельца `ORCH_HOST_REPOS_DIR` (инвариант
+   ORCH-040), `ORCH_DOCKER_GID` — `getent group docker`; ssh-ключи деплой-хука
+   (`ORCH_HOST_SSH_DIR`); свободные порты (`ORCH_DEPLOY_PROD_TARGET_PORT`=8500,
+   `ORCH_STAGING_PORT`=8501). Каждое предусловие — команда проверки.
+3. **Перенос кода орк+watchdog**: получение чекаута репо `orchestrator` на хост в
+   `ORCH_DEPLOY_HOST_REPO_PATH` (источник кода — параметризованный шаг, исход А-6); НИКАКИХ
+   данных/БД/`.env` с боевого хоста (D-2). Watchdog отдельно не переносится — код в `watchdog/`
+   того же репо, образ собирается локально compose'ом.
+4. **Конфигурация**: `.env` строится с нуля от `.env.example` (канон); webhook-секреты —
+   `python3 scripts/gen_secrets.py [--write]`; карта переменных — ссылкой на REPLICATION.md §2;
+   в доке явно — **обязательные ключи нового хоста**: `ORCH_PLANE_API_URL/WEB_URL/WORKSPACE_SLUG`,
+   `ORCH_PLANE_API_TOKEN`, `ORCH_GITEA_URL/PUBLIC_URL/OWNER`, `ORCH_GITEA_TOKEN`, оба
+   webhook-секрета, `ORCH_TELEGRAM_BOT_TOKEN/CHAT_ID`, `ORCH_PROJECTS_JSON` (обязателен:
+   встроенный fallback несёт UUID исходного хоста), хост-параметры `ORCH_AGENT_HOME_DIR`/
+   `ORCH_HOST_*`/`ORCH_RUN_*`/`ORCH_DOCKER_GID`, когерентность портов
+   (`ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`).
+5. **Подключение Plane** (инсталляция заказчика): создать workspace/проект; **точная модель
+   статусов** — 22 канонических имени с группами: создаёт `onboard_project.py apply`, таблица —
+   ссылкой на ONBOARDING.md §1 (без форка; fail-closed `Confirm Deploy`/`STOP` упомянуть явно);
+   выпуск API-токена (Workspace Settings → API tokens) + команда проверки; **webhook+HMAC**:
+   URL `…/webhook/plane`, секрет из `gen_secrets.py`, заголовок `X-Plane-Signature`; каверза
+   Plane CE «webhook не экспонирован в /api/v1» — оба пути (UI и прямой SQL, generic-вариант
+   команд SETUP_WEBHOOKS.md с плейсхолдерами).
+6. **Подключение Gitea** (инсталляция заказчика): репо (`onboard_project.py` или вручную),
+   токен (scope `repo`, `admin:repo_hook`) + проверка, per-repo webhook (events
+   `push`/`pull_request`/`status`, `X-Gitea-Signature`, **ОДИН глобальный секрет на все репо**);
+   норматив защиты `main` — по исходу А-1 (канон: branch protection НЕ включать, ORCH-009 ADR D10).
+7. **LLM-доступ (claude CLI)**: дистрибутив claude-code и node на хосте (пути = маунты compose),
+   `ORCH_CLAUDE_BIN`; аутентификация CLI на хосте (каталог `ORCH_HOST_CLAUDE_DIR` +
+   `ORCH_HOST_CLAUDE_JSON` — монтируются в контейнер; команда первичного логина/проверки —
+   `claude --version` / минимальный вызов); конфигурация моделей — `ORCH_AGENT_MODEL_*` /
+   `ORCH_AGENT_EFFORT_*` (резолв ORCH-41; дефолты канона — в `.env.example`).
+8. **Telegram**: бот трекера (BotFather `/newbot` → `ORCH_TELEGRAM_BOT_TOKEN`), получение
+   `chat_id` (воспроизводимая команда, например через `getUpdates`), проверка `getMe`;
+   **отдельный** watchdog-бот (`WATCHDOG_TG_BOT_TOKEN/CHAT_ID` — независимый канал, C-1
+   ORCH-100, токен орка переиспользовать запрещено) — размещение ключей по исходу А-4
+   (`.env.watchdog`).
+9. **Запуск compose-подмножества**: `docker compose config` (резолв без ошибок) →
+   `docker compose up -d --build` → поднимаются ровно `orchestrator` + `orchestrator-watchdog`
+   (AC-2); staging-профиль — опционально/когда нужен (исход А-5); health-чек:
+   `GET /health` → 200 `"status":"ok"`, `GET /queue`/`GET /metrics` → штатный JSON
+   (`schema_version: 1`).
+10. **Регистрация проекта заказчика**: `onboard_project.py plan → apply → verify`
+    (Plane-проект+статусы+лейблы `autoApprove`/`autoDeploy`/`Bug`, Gitea-репо+webhook, kit,
+    merged `ORCH_PROJECTS_JSON`) → внести строку в `.env` → управляемый рестарт → проверка
+    `/health`+`/queue` (маршрут ONBOARDING.md, ссылкой; в Lite-доке — последовательность команд).
+11. **Smoke** (AC-4): чек-лист REPLICATION.md §4 (шаги 0–5, опционально 6 до `done`) —
+    переиспользовать ссылкой + Lite-специфичные предусловия; критерий «конвейер доехал»:
+    задача в БД → analyst-job в `/queue` → артефакты `01–04` в ветке задачи.
+12. **Stateless-проверка** (AC-3): первый старт создаёт пустую БД (`data/` чист); `GET /queue` —
+    нулевые счётчики, ни одной задачи `ORCH-*`/`ET-*`; явная нормативная строка «данные/задачи/
+    секреты боевого хоста НЕ переносятся».
+13. **Траблшутинг** первичной настройки: минимум — webhook 401/HMAC mismatch; «задача не
+    появилась» (реестр/`ORCH_PROJECTS_JSON`/webhook); claude CLI не аутентифицирован/не найден;
+    `docker.sock` permission denied (`ORCH_DOCKER_GID`); права `/repos` (uid mismatch,
+    ORCH-040/057); Telegram молчит (токен/chat-id). Каждый пункт — симптом → команда
+    диагностики → лечение.
+
+**Форма (NFR-6, BR-1):** каждый шаг — исполняемая команда (fenced code block) + явная проверка
+(«Проверка:» / PASS-FAIL / ожидаемый вывод); все хост-специфичные значения в командах — только
+плейсхолдеры `<...>` или `$ENV_VAR` (боевые `mva154`/`82.22.50.71`/реальные токены — запрещены);
+язык — русский (канон доков платформы).
+
+### FR-2 — Compose-подмножество (AC-2)
+
+Привязка: BR-3. Зафиксировать (в доке + тестом), что Lite-развёртывание использует
+существующий `docker-compose.yml` БЕЗ форка:
+
+- множество сервисов файла — ровно `{orchestrator, orchestrator-watchdog, orchestrator-staging}`;
+- `orchestrator-staging` строго за `profiles: [staging]` → дефолтный `docker compose up -d`
+  поднимает ровно орк+watchdog;
+- сервисов/образов Plane/Gitea в compose НЕТ (и тест не даст появиться молча);
+- форма фиксации (существующий файл vs отдельный lite-вариант) — исход А-2; ТЗ-рекомендация:
+  существующий файл (он уже является подмножеством — факт BRD §1.3), отдельный файл не плодить.
+
+### FR-3 — Stateless-нормативы (AC-3)
+
+Привязка: BR-4. Инструкция обязана: (а) предписывать чистый старт — пустой `data/` (БД создаётся
+`init_db()` при первом старте), `.env` только с нуля; (б) предписывать выпуск НОВЫХ секретов
+(`gen_secrets.py` + чек-лист REPLICATION.md §3.2) и нести норматив «боевые секреты/данные/задачи
+не копируются»; (в) содержать проверку чистоты (FR-1 п.12); (г) сама не содержать реальных
+секретов (NFR-3; проверяется тестом FR-6 и security-гейтом ORCH-022).
+
+### FR-4 — Покрытие донастройки окружения без форка канона (AC-1)
+
+Привязка: BR-2, BR-6. Per-system разделы FR-1 п.5–8 обязаны быть полными (заказчик не ходит за
+ответами вовне репо), при этом канонические данные даются ссылкой на golden source:
+
+| Данные | Golden source | В LITE_SETUP.md |
+|--------|---------------|------------------|
+| 22 статуса + группы | `plane_sync._PLANE_NAME_TO_KEY` / ONBOARDING.md §1 | ссылка + критичные fail-closed имена (`Confirm Deploy`, `STOP`) |
+| Карта env / хост-параметры | REPLICATION.md §2 / `.env.example` | ссылка + список обязательных ключей нового хоста |
+| Формат вебхуков / Plane CE-каверза | SETUP_WEBHOOKS.md | ссылка + generic-команды с плейсхолдерами |
+| Онбординг проекта | ONBOARDING.md / `onboard_project.py` | ссылка + последовательность команд Lite-маршрута |
+| Smoke | REPLICATION.md §4 | ссылка + Lite-предусловия |
+
+Если архитектор решит дублировать таблицу (читаемость) — дубль защищается анти-дрейф тестом
+(сверка импортом из `src/plane_sync.py` / парсингом `.env.example`), не строковой копией.
+
+### FR-5 — Smoke на чистом окружении (AC-4)
+
+Привязка: BR-5. Состав: (а) в LITE_SETUP.md — smoke-раздел (FR-1 п.11) как воспроизводимый
+чек-лист с PASS/FAIL на каждый шаг; (б) приёмочный прогон процедуры на чистом контуре — минимум
+staging-песочница (порт `ORCH_STAGING_PORT`, изолированная БД `./data/staging`) + одноразовый
+sandbox-проект (прецедент ORCH-101 AC-3 / ONBOARDING.md §5.2), без нового железа; (в) результат
+прогона фиксируется в артефактах задачи (`13-test-report.md` / `15-staging-log.md`); (г) прогон
+на реальном новом хосте — желателен, но НЕ требование приёмки (нет железа в контуре задачи).
+
+### FR-6 — Анти-дрейф тесты (BR-8)
+
+Привязка: BR-3, BR-6, BR-8. Новый `tests/test_lite_setup_doc.py` (структурный, без сети/LLM;
+образец — `tests/test_replication_smoke.py`):
+
+1. док существует по канонному пути; несёт обязательные разделы/кирпичи FR-1 (минимум:
+   `gen_secrets.py`, `onboard_project.py`, `docker compose`, `/health`, `/queue`, `/metrics`,
+   `ORCH_PROJECTS_JSON`, webhook-секреты, `X-Plane-Signature`/`X-Gitea-Signature`,
+   `getent group docker`, `Confirm Deploy`/`STOP`, Telegram-боты обоих каналов, маркеры
+   PASS/FAIL/«Проверка»);
+2. каждый env-ключ `ORCH_*`/`WATCHDOG_*`, упомянутый в доке, существует в `.env.example`
+   (анти-опечатка/анти-дрейф канона);
+3. compose-подмножество: парсинг `docker-compose.yml` — ровно 3 сервиса, staging за профилем,
+   ни одного сервиса/образа `plane*`/`gitea*` (AC-2);
+4. stateless/секрет-гигиена: нормативная строка «не копиру…» присутствует; в доке нет
+   секретоподобных значений (эвристика по образцу security-паттернов) и боевых литералов
+   (`mva154`, `duckdns`, `82.22.50.71`) в копируемых код-блоках;
+5. перекрёстность: REPLICATION.md §1 ссылается на LITE_SETUP.md; `CHANGELOG.md` несёт ORCH-102.
+
+Точная нарезка по тест-модулям — за developer (план — `04-test-plan.yaml`); существующие тесты
+не правятся (кроме согласованных структурных дополнений).
+
+### FR-7 — Перекрёстная документация (BR-7)
+
+Привязка: BR-7. REPLICATION.md §1 (строка Type A — Lite → ✅ + ссылка); README.md — способность
+Lite-тиража в обзоре (правило №6); CLAUDE.md — по фактическому объёму; CHANGELOG.md — запись.
+INFRA.md — ссылка на deployment-раздел при необходимости.
+
+---
+
+## 3.8. Вопросы архитектору (решаются в `06-adr/`, не в ТЗ)
+
+- **А-1 — «pre-receive хуки» vs норматив ADR D10 (ORCH-009):** бизнес-запрос упоминает
+  pre-receive хуки, но в платформе их нет, а branch protection на `main` нормативно запрещён
+  (ломает PR-merge API merge-актора). Что фиксирует раздел Gitea? Рекомендация ТЗ: канон —
+  репо+токен+webhook+явный норматив «branch protection НЕ включать»; pre-receive не вводить;
+  отклонение — только отдельным ADR с анализом совместимости с merge-актором (ORCH-093/INV-4).
+- **А-2 — форма compose-подмножества:** существующий `docker-compose.yml` (уже = подмножество)
+  + документация/тест vs отдельный `docker-compose.lite.yml`. Рекомендация: существующий, без
+  форка (нулевой дрейф, AC-2 держит тест).
+- **А-3 — размещение дока:** бизнес-запрос фиксирует `docs/deployment/LITE_SETUP.md` (новый
+  раздел `docs/deployment/`); REPLICATION.md живёт в `docs/operations/`. Подтвердить layout
+  (deployment как витрина тиража vs operations) и перекрёстные ссылки; отступление от пути
+  бизнес-запроса — только явным решением.
+- **А-4 — канон watchdog-конфига нового хоста:** compose читает `.env.watchdog`
+  (`required: false`), примера-файла нет; ключи `WATCHDOG_*` канонизированы в `.env.example`.
+  Добавить `.env.watchdog.example` (симметрия с `.env.staging.example`) или документировать
+  шаг «создай `.env.watchdog` с двумя ключами» в LITE_SETUP? Рекомендация: example-файл +
+  упоминание в доке (меньше шансов перепутать файл-носитель).
+- **А-5 — staging-контур в Lite-инструкции:** обязателен ли запуск `orchestrator-staging` у
+  заказчика? Рекомендация: опционален — нужен только если заказчик регистрирует проект
+  `orchestrator` (self-hosting развитие платформы); для «раздачи на тест» базовый контур =
+  prod-инстанс + watchdog; в доке — явная вилка.
+- **А-6 — источник кода для заказчика:** clone-URL (зеркало/доступ к нашему Gitea) vs архив.
+  В доке — параметризованный шаг `git clone <ORCHESTRATOR_GIT_URL>`; конкретику источника
+  фиксирует Владелец (вне репо).
+
+---
+
+## 4. Изменения API
+
+Нет. Существующие `GET /health` / `/queue` / `/metrics` переиспользуются инструкцией read-only;
+новые эндпоинты не вводятся.
+
+## 5. Изменения схемы БД
+
+Нет.
+
+## 6. Требования к новым/изменённым QG checks
+
+Нет. `QG_CHECKS`/`check_*`/machine-verdict ключи не меняются. Новые структурные тесты (FR-6) —
+обычный pytest: попадают в существующие гейты (`check_ci_green`/`check_tests_passed`/merge-gate
+re-test/coverage-гейт ORCH-027) автоматически, без регистрации нового QG.
+
+## 7. Совместимость / регресс
+
+- **Нулевая регрессия (NFR-2):** дифф — docs+tests (+опц. `.env.watchdog.example`); рантайм не
+  меняется; kill-switch не требуется (нечего выключать); полный `pytest tests/ -q` зелёный,
+  существующие структурные тесты (`test_no_host_hardcodes`, `test_replication_smoke`,
+  `test_infra_parametrization`, `test_onboarding_*`) не ослабляются.
+- **Обратимость:** удаление дока/тестов возвращает состояние 1:1 (никаких миграций/состояния).
+- **Self-hosting (NFR-1):** прод-контейнер не рестартится; выкат — штатный конвейер
+  (deploy-staging 8501 → ручной Confirm Deploy). Для enduro-trails изменение инертно.
+- **Секрет-гигиена (NFR-3):** в доке/тестах только плейсхолдеры; security-гейт (ORCH-022,
+  `17-security-report.md`) обязан остаться `PASS`.
+- **Инварианты соседних маркеров (правило №9):** ORCH-101 (дефолт = боевое значение; канон
+  `.env.example`; конвенции тиража REPLICATION §1), ORCH-009 (ADR D10 — без branch protection;
+  onboarding-CLI ничего не удаляет), ORCH-100 (независимый Telegram-канал watchdog, C-1),
+  ORCH-040 (uid/gid/HOME группа), ORCH-058 (staging ≠ прод-порт), INV-4 (мерж только через
+  PR-merge API) — инструкция обязана им следовать, а не противоречить.

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

@@ -0,0 +1,181 @@
+---
+work_item: ORCH-102
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-102 — ORCH-10a Lite-тираж
+
+Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория. AC-1…AC-5 — дословно из бизнес-запроса (уточнены до проверяемости);
+AC-6…AC-7 — детализация скоупа (анти-дрейф / инварианты).
+
+---
+
+## AC-1 — `docs/deployment/LITE_SETUP.md`: полная пошаговая, без доп-вопросов
+
+**Условие:** инструкция существует и покрывает сквозной маршрут Lite-тиража; каждый шаг —
+команда/проверка; человек, не видевший платформу, разворачивает по ней без доп-вопросов.
+- **PASS:**
+  - файл `docs/deployment/LITE_SETUP.md` существует (путь — по исходу А-3; отклонение от пути
+    бизнес-запроса зафиксировано в ADR задачи);
+  - покрыты ВСЕ разделы нормативного перечня ТЗ §FR-1: рамка Lite/границы; предусловия хоста
+    (зависимости, uid/gid: `ORCH_RUN_UID/GID`, `ORCH_DOCKER_GID` через `getent group docker`,
+    владение `ORCH_HOST_REPOS_DIR`); перенос кода (чекаут `orchestrator`, без данных);
+    конфигурация (`.env` с нуля от `.env.example` + `gen_secrets.py`, обязательные ключи нового
+    хоста включая `ORCH_PROJECTS_JSON`); Plane (workspace/проект, точная модель статусов с
+    fail-closed `Confirm Deploy`/`STOP`, API-токен, webhook+HMAC `X-Plane-Signature` + каверза
+    Plane CE); Gitea (репо, токен со scope, per-repo webhook `X-Gitea-Signature`, один глобальный
+    секрет, норматив защиты `main` по исходу А-1); LLM (claude CLI: дистрибутив/node/аутентификация/
+    `ORCH_CLAUDE_BIN`/модели ORCH-41); Telegram (бот трекера + отдельный watchdog-бот +
+    получение chat-id); запуск compose + health-чек (`/health`, `/queue`, `/metrics`);
+    регистрация проекта (`onboard_project.py` → `ORCH_PROJECTS_JSON` → управляемый рестарт);
+    smoke; stateless-проверка; траблшутинг (≥ 5 типовых отказов: симптом → диагностика → лечение);
+  - **каждый** нормативный шаг несёт исполняемую команду (fenced code block) И явную проверку
+    результата (маркер «Проверка:» / PASS-FAIL / ожидаемый вывод);
+  - копируемые команды generic: хост-специфика только плейсхолдерами `<...>`/`$ENV_VAR`;
+    боевых литералов (`mva154`, `duckdns`, `82.22.50.71`, реальные токены) в код-блоках нет;
+  - «без доп-вопросов» подтверждено операционально: приёмочный smoke-прогон по инструкции
+    выполнен на чистом контуре и зафиксирован (см. AC-4) + траблшутинг покрывает типовые отказы.
+- **FAIL:** файла нет; ИЛИ отсутствует любой нормативный раздел FR-1; ИЛИ есть шаг без
+  команды/проверки («настройте webhook» без как-проверить); ИЛИ в копируемых командах боевые
+  URL/пути/секреты; ИЛИ инструкция отсылает за обязательным шагом во внешний (вне репо) источник.
+
+---
+
+## AC-2 — Compose-подмножество: только орк+watchdog
+
+**Условие:** Lite разворачивает ровно `orchestrator`+`orchestrator-watchdog`; Plane/Gitea-контейнеров
+нет; свойство зафиксировано и защищено.
+- **PASS:**
+  - `docker compose config --services` (без активных профилей, пустой env) →
+    ровно `orchestrator` и `orchestrator-watchdog`;
+  - `orchestrator-staging` присутствует в файле строго за `profiles: [staging]` (дефолтный
+    `up -d` его не поднимает);
+  - в `docker-compose.yml` нет сервисов/образов Plane/Gitea (ни `plane*`, ни `gitea*`);
+  - LITE_SETUP.md документирует это свойство (что поднимется после `up -d` и почему staging
+    опционален — исход А-5);
+  - структурный тест compose-подмножества (TC-04) существует и зелёный;
+  - если по исходу А-2 введён отдельный lite-compose — он покрыт тем же тестом, а existing
+    `docker-compose.yml` не форкается без обоснования в ADR.
+- **FAIL:** дефолтный запуск поднимает что-то кроме орк+watchdog; ИЛИ staging вне профиля;
+  ИЛИ в compose появился Plane/Gitea-сервис; ИЛИ свойство не задокументировано; ИЛИ тест
+  отсутствует/красный.
+
+---
+
+## AC-3 — Stateless: чистая БД, ни одной нашей задачи/секрета
+
+**Условие:** инструкция предписывает чистый старт и не допускает переноса наших данных/секретов;
+сама дока секретов не содержит.
+- **PASS:**
+  - LITE_SETUP.md нормативно фиксирует: БД создаётся пустой при первом старте (`data/` чист,
+    переносить нечего); `.env`/`.env.staging`/`.env.watchdog` собираются с нуля; явная строка
+    «данные/задачи/секреты боевого хоста НЕ переносятся» (зеркало REPLICATION.md §5);
+  - секреты — только выпуск НОВЫХ: `gen_secrets.py` (webhook) + чек-лист внешних токенов
+    (ссылка на REPLICATION.md §3); ни один шаг не предписывает копирование боевого секрета;
+  - инструкция содержит проверку чистоты развёрнутого инстанса: первый `GET /queue` — нулевые
+    счётчики jobs, ни одной задачи (`ORCH-*`/`ET-*`) в системе;
+  - в самом доке и тестах задачи нет реальных секретоподобных значений (только плейсхолдеры);
+    security-гейт (ORCH-022, `17-security-report.md`) — `PASS`.
+- **FAIL:** любой шаг предписывает/допускает перенос БД/задач/боевого `.env`/секрета; ИЛИ нет
+  нормативной stateless-строки; ИЛИ нет проверки чистоты; ИЛИ в доке обнаружен реальный
+  секрет/боевой токен; ИЛИ security-гейт `FAIL`.
+
+---
+
+## AC-4 — Smoke на чистом окружении проходит
+
+**Условие:** smoke существует как воспроизводимая процедура/чек-лист и подтверждён прогоном.
+- **PASS:**
+  - LITE_SETUP.md несёт smoke-раздел: чек-лист с явным PASS/FAIL на каждый шаг, построенный на
+    REPLICATION.md §4 (ссылка, без форка процедуры): конфиг резолвится → `/health` →
+    `/queue`+`/metrics` → тестовый проект (`onboard_project.py plan/apply/verify`) → тестовая
+    задача → «конвейер доехал» (минимум: `analysis` отработала, артефакты `01–04` в ветке);
+  - итог процедуры — однозначный вердикт (все шаги PASS ⇒ тираж PASS);
+  - приёмочный прогон выполнен на чистом контуре — минимум staging-песочница
+    (`ORCH_STAGING_PORT`, изолированная БД `./data/staging`) + одноразовый sandbox-проект
+    (прецедент ORCH-101 AC-3 / ONBOARDING.md §5.2) — и зафиксирован в артефактах задачи
+    (`13-test-report.md` и/или `15-staging-log.md`: дата, контур, шаги, вердикт);
+  - процедура нигде не требует боевых данных/секретов (stateless, согласовано с AC-3).
+- **FAIL:** smoke-раздела нет; ИЛИ шаги без явных PASS/FAIL («посмотреть, что всё ок»); ИЛИ
+  процедура форкает REPLICATION.md §4 с расхождениями; ИЛИ заявленный прогон не зафиксирован в
+  артефактах; ИЛИ прогон провален и не разобран.
+
+---
+
+## AC-5 — pytest зелёный; CHANGELOG; перекрёстные доки
+
+**Условие:** регресс чист, документация согласована (правила агентов №2/№6).
+- **PASS:**
+  - полный `pytest tests/ -q` зелёный (включая новые структурные тесты задачи и существующие
+    `test_no_host_hardcodes` / `test_replication_smoke` / `test_infra_parametrization` /
+    `test_onboarding_*` — не ослаблены и не правлены под задачу без согласования);
+  - `CHANGELOG.md` содержит запись ORCH-102;
+  - `docs/operations/REPLICATION.md` §1: строка «Type A — Lite» обновлена (статус ✅/ссылка на
+    LITE_SETUP.md) — границы 10-common vs Lite vs Bundled остаются честными;
+  - `README.md`/`CLAUDE.md` обновлены, если фактический объём того требует (новая операторская
+    способность — Lite-тираж; README не выдаёт нерешённое за решённое и наоборот).
+- **FAIL:** любой тест красный; ИЛИ нет записи в CHANGELOG; ИЛИ REPLICATION.md §1 продолжает
+  числить Lite «отдельной задачей» без ссылки; ИЛИ обзорные доки противоречат факту.
+
+---
+
+## AC-6 — Канон не форкается; анти-дрейф защита
+
+**Условие:** инструкция — маршрутизатор поверх golden source'ов, её полнота защищена тестом.
+- **PASS:**
+  - канонические данные (22 статуса, карта env, формат вебхуков, онбординг, smoke) даны ссылкой
+    на golden source (`ONBOARDING.md` §1 / `REPLICATION.md` §2–§4 / `SETUP_WEBHOOKS.md`); при
+    дублировании таблицы — анти-дрейф тест сверяет дубль с источником истины (импорт из
+    `src/plane_sync.py` / парсинг `.env.example`), не строковой копией;
+  - `tests/test_lite_setup_doc.py` существует и проверяет минимум: наличие дока; обязательные
+    кирпичи (ТЗ FR-6.1); согласованность упомянутых env-ключей с `.env.example` (FR-6.2);
+    compose-подмножество (FR-6.3); stateless-норматив и отсутствие боевых литералов/секретов в
+    код-блоках (FR-6.4); перекрёстность REPLICATION→LITE_SETUP и запись CHANGELOG (FR-6.5);
+  - тест детерминирован (повторные прогоны стабильны, без сети/LLM).
+- **FAIL:** таблица статусов/env скопирована без анти-дрейф сверки; ИЛИ тест отсутствует/не
+  ловит исчезновение обязательного раздела/кирпича; ИЛИ упомянутый в доке env-ключ отсутствует
+  в `.env.example`; ИЛИ тест флапает/ходит в сеть.
+
+---
+
+## AC-7 — Self-hosting безопасность и неизменность конвейера
+
+**Условие:** задача не дестабилизирует общий прод и не меняет рантайм.
+- **PASS:**
+  - дифф задачи — `docs/**`, `tests/**`, `CHANGELOG.md` (+ согласованные обзорные доки,
+    + `.env.watchdog.example` при исходе А-4); `src/**` не изменён — либо каждое отклонение
+    обосновано в ADR задачи;
+  - `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД —
+    без изменений;
+  - прод-контейнер `orchestrator` в рамках задачи не перезапускается; выкат — только штатным
+    конвейером (deploy-staging 8501 → ручной Confirm Deploy);
+  - инструкция не противоречит инвариантам платформы: ADR D10 ORCH-009 (без branch protection),
+    C-1 ORCH-100 (watchdog-бот ≠ бот орка), ORCH-040 (uid/gid/HOME группа), ORCH-058
+    (staging-порт ≠ прод-порт), INV-4 (мерж только через PR-merge API), конвенции тиража
+    REPLICATION.md §1 (репо `orchestrator`, имена сервисов).
+- **FAIL:** немотивированные правки `src/**`/compose/Dockerfile; ИЛИ дифф трогает машину
+  стадий/QG/вердикты/схему БД; ИЛИ рестарт прода вне штатного деплой-пути; ИЛИ шаг инструкции
+  предписывает запрещённое инвариантами (включить branch protection, переиспользовать токен орка
+  для watchdog, скопировать боевой секрет и т.п.).
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1, BR-2 / FR-1, FR-4, NFR-6 |
+| AC-2 | BR-3 / FR-2 |
+| AC-3 | BR-4 / FR-3, NFR-3 |
+| AC-4 | BR-5 / FR-5 |
+| AC-5 | BR-7 / FR-7, NFR-2 |
+| AC-6 | BR-6, BR-8 / FR-6, NFR-4, NFR-5 |
+| AC-7 | NFR-1, NFR-2 / §7 ТЗ (инварианты) |

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

@@ -0,0 +1,146 @@
+work_item: ORCH-102
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+title: "ORCH-10a Lite-тираж: инструкция LITE_SETUP + compose-подмножество — план тестов"
+framework: pytest
+scope: >
+  Покрывается: существование и полнота docs/deployment/LITE_SETUP.md (нормативные
+  разделы FR-1, форма «команда+проверка», generic-команды без боевых литералов),
+  согласованность упомянутых env-ключей с каноном .env.example, структурная
+  фиксация compose-подмножества (ровно орк+watchdog, staging за профилем, без
+  Plane/Gitea-сервисов), stateless-нормативы и секрет-гигиена дока, перекрёстные
+  ссылки (REPLICATION.md §1, CHANGELOG), воспроизводимый smoke-чек-лист и его
+  приёмочный прогон на чистом контуре, полный регресс. Вне покрытия: реальный
+  e2e-тираж на новом железе заказчика (заменён прогоном на staging-песочнице —
+  прецедент ORCH-101 AC-3), установка Plane/Gitea как таковых, задача 10b
+  (Bundled), перенос данных (stateless по решению 10.06).
+notes: >
+  Задача docs-first: ожидаемый дифф — docs/** + tests/** + CHANGELOG.md
+  (+ .env.watchdog.example при исходе А-4); src/** не меняется. Имя нового
+  тест-модуля tests/test_lite_setup_doc.py — предложение analyst; developer может
+  переименовать/разбить, сохранив покрытие TC (образец структурных док-тестов —
+  tests/test_replication_smoke.py). Тесты детерминированы, без сети/LLM.
+  Полный регресс tests/ обязан остаться зелёным; STAGE_TRANSITIONS/QG_CHECKS/
+  check_*/machine-verdict не меняются — новые тесты входят в существующие гейты
+  (check_ci_green / merge-gate re-test / coverage-гейт ORCH-027) автоматически.
+  TC-09 — процедурная приёмка AC-4: прогон фиксируется tester'ом в
+  13-test-report.md / 15-staging-log.md, а не автоматизируется в pytest.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: >
+      LITE_SETUP.md существует по канонному пути (docs/deployment/, исход А-3 —
+      синхронизировать с ADR) и несёт ВСЕ нормативные разделы FR-1: рамка/границы
+      Lite, предусловия хоста (зависимости, uid/gid, getent group docker), перенос
+      кода, конфигурация (.env с нуля + gen_secrets.py + ORCH_PROJECTS_JSON),
+      Plane (статусы/токен/webhook+HMAC), Gitea (репо/токен/webhook), LLM
+      (claude CLI), Telegram (трекер + watchdog-бот + chat-id), запуск+health-чек,
+      регистрация проекта, smoke, stateless-проверка, траблшутинг (AC-1 / FR-1).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      Форма «каждый шаг — команда/проверка»: нормативные разделы содержат fenced
+      code blocks с исполняемыми командами и явные маркеры проверки
+      (PASS/FAIL/«Проверка:»); ключевые кирпичи присутствуют: docker compose,
+      /health, /queue, /metrics, gen_secrets.py, onboard_project.py,
+      X-Plane-Signature, X-Gitea-Signature (AC-1 / FR-1, NFR-6).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      Согласованность env-канона: каждый ключ ORCH_*/WATCHDOG_*, упомянутый в
+      LITE_SETUP.md, существует в .env.example; обязательный набор нового хоста
+      упомянут явно (ORCH_PROJECTS_JSON, ORCH_PLANE_WEBHOOK_SECRET,
+      ORCH_GITEA_WEBHOOK_SECRET, ORCH_PLANE_API_TOKEN, ORCH_GITEA_TOKEN,
+      ORCH_TELEGRAM_BOT_TOKEN, ORCH_TELEGRAM_CHAT_ID, WATCHDOG_TG_BOT_TOKEN,
+      WATCHDOG_TG_CHAT_ID) (AC-1, AC-6 / FR-1.4, FR-6.2).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      Compose-подмножество (AC-2): docker-compose.yml парсится; множество сервисов
+      ровно {orchestrator, orchestrator-watchdog, orchestrator-staging};
+      orchestrator-staging строго за profiles: [staging] (дефолтный up -d поднимает
+      ровно орк+watchdog); ни одного сервиса/образа plane*/gitea*; LITE_SETUP.md
+      документирует состав дефолтного запуска (AC-2 / FR-2).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      Stateless и секрет-гигиена (AC-3): док несёт нормативную строку «боевые
+      данные/задачи/секреты не копируются» и предписывает чистую БД + выпуск
+      новых секретов (gen_secrets.py); проверка чистоты инстанса (первый GET
+      /queue без задач) описана; в копируемых код-блоках нет боевых литералов
+      (mva154, duckdns, 82.22.50.71) и секретоподобных значений — только
+      плейсхолдеры <...>/$ENV_VAR (AC-3 / FR-3, NFR-3).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Канон не форкается (AC-6): раздел Plane-статусов ссылается на golden source
+      (ONBOARDING.md §1 / onboard_project.py) и явно упоминает fail-closed имена
+      Confirm Deploy и STOP; при наличии дубля таблицы статусов в доке — дубль
+      сверяется с plane_sync._PLANE_NAME_TO_KEY импортом (22 имени, нулевой
+      дрейф); карта env и smoke даны ссылкой на REPLICATION.md (AC-6 / FR-4,
+      NFR-4).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: >
+      Раздел Gitea соответствует инвариантам платформы: события
+      push/pull_request/status, ОДИН глобальный webhook-секрет на все репо,
+      и норматив защиты main согласован с исходом А-1 ADR задачи (канон: branch
+      protection НЕ включать — ADR D10 ORCH-009; инструкция не предписывает
+      запрещённого) (AC-1, AC-7 / FR-1.6, §3.8 А-1).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: >
+      Перекрёстная документация (AC-5): REPLICATION.md §1 (границы 10-common vs
+      Lite vs Bundled) ссылается на LITE_SETUP.md / отмечает Lite реализованным;
+      CHANGELOG.md содержит запись ORCH-102 (AC-5 / FR-7).
+    module: tests/test_lite_setup_doc.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: >
+      Приёмочный smoke-прогон по LITE_SETUP.md на чистом контуре (минимум:
+      staging-песочница ORCH_STAGING_PORT с изолированной БД ./data/staging +
+      одноразовый sandbox-проект; прецедент ORCH-101 AC-3): чек-лист REPLICATION
+      §4 шаги 0–5 — конфиг резолвится, /health 200, /queue+/metrics штатны,
+      onboard verify зелёный, тестовая задача дошла до артефактов 01–04; вердикт
+      и контур зафиксированы в 13-test-report.md / 15-staging-log.md. Процедурная
+      приёмка (исполняет tester по чек-листу), не pytest-модуль (AC-4 / FR-5).
+    module: tests/manual/lite-smoke-checklist (процедура; протокол в 13/15)
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: >
+      Полный регресс: pytest tests/ -q зелёный; существующие структурные тесты
+      (test_no_host_hardcodes, test_replication_smoke, test_infra_parametrization,
+      test_onboarding_*) не ослаблены/не правлены под задачу; дифф не трогает
+      src/** (или каждое отклонение обосновано ADR), STAGE_TRANSITIONS/QG_CHECKS/
+      machine-verdict/схему БД (AC-5, AC-7 / NFR-2).
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md

@@ -0,0 +1,298 @@
+---
+work_item: ORCH-102
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Канон Lite-тиража — `docs/deployment/LITE_SETUP.md`, исходы А-1…А-6, анти-дрейф контур
+
+Work Item: **ORCH-102** — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0037-lite-replication-canon.md`**
+(новый docs-раздел `docs/deployment/`, новый канонический example-файл и нормативы тиражной
+инсталляции — кросс-каттинг для всех будущих задач эпика ORCH-10 и для агентов, меняющих шаги тиража).
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **A — Lite**: заказчик-тестер разворачивает на своей инфре
+ТОЛЬКО орк+watchdog, окружение (Plane/Gitea/LLM/Telegram) донастраивает сам по инструкции.
+Решения Владельца 10.06 (BRD §1.4): оба типа тиража stateless (D-2), главный продукт ORCH-102 —
+**инструкция** `docs/deployment/LITE_SETUP.md` (D-4).
+
+Факты, сверенные с кодом/репо на ветке задачи:
+
+- **Фундамент 10-common (ORCH-101) в `main`** (adr-0036): хост-значения параметризованы
+  (`${VAR:-default}`, «дефолт = боевое значение»), секреты выпускаются заново
+  (`scripts/gen_secrets.py`), smoke с PASS/FAIL — `docs/operations/REPLICATION.md` §4,
+  анти-регресс `tests/test_no_host_hardcodes.py` (центральный список `FORBIDDEN` + хелпер
+  `find_violations`). Технически платформа разворачивается без правки кода; операционно
+  единого маршрута для заказчика нет (знания в 4 operations-доках, писанных для НАШЕГО хоста).
+- **`docker-compose.yml` уже является Lite-подмножеством:** ровно 3 сервиса —
+  `orchestrator`, `orchestrator-watchdog`, `orchestrator-staging`; staging строго за
+  `profiles: [staging]`; сервисов/образов Plane/Gitea нет. Дефолтный `docker compose up -d`
+  поднимает ровно орк+watchdog. Свойство нигде не зафиксировано и ничем не защищено.
+- **Гэп канона watchdog-конфига:** compose читает `.env.watchdog`
+  (`env_file: {path: .env.watchdog, required: false}`), но example-файла нет (есть только
+  `.env.example` / `.env.staging.example`). Ключи `WATCHDOG_*` (19 шт., дефолты =
+  `watchdog/config.py`) задокументированы внутри `.env.example` — однако sidecar-контейнер
+  читает ТОЛЬКО `.env.watchdog`: ключ, положенный оператором в `.env`, для watchdog **инертен**
+  (в `.env` его видит лишь контейнер орка через его `env_file`). Двусмысленность файла-носителя —
+  реальная ловушка первичной настройки.
+- **«Pre-receive хуки» из бизнес-запроса конфликтуют с действующим нормативом:** ORCH-009
+  ADR-001 **D10** — branch protection на `main` НЕ включать (required-approvals/status-checks →
+  405/409-класс отказов `merge_pr` → ложные HOLD, класс инцидента ORCH-063); merge-актор работает
+  только через Gitea PR-merge API (INV-4, `src/merge_gate.py`). Pre-receive хуков в платформе нет;
+  защита `main` — конвенция (агенты не пушат `main`) + скоуп токенов.
+- **Парсер YAML доступен тестам** (`yaml.safe_load` уже используется в
+  `tests/test_infra_parametrization.py::_compose_services`) — структурный тест
+  compose-подмножества не требует новых зависимостей.
+- Прецедент приёмки smoke без нового железа: ORCH-101 AC-3 — staging-песочница
+  (`ORCH_STAGING_PORT`=8501, изолированная БД `./data/staging`) + sandbox-проект
+  (ONBOARDING.md §5, журнал smoke-прогонов).
+
+Задача — **docs+tests** (паттерн ORCH-077/092): `src/**`, `docker-compose.yml`, `Dockerfile`,
+`scripts/**` читаются как источник истины и НЕ меняются; конвейер
+(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
+
+## Решение
+
+### Сводка
+
+Создаётся новый docs-раздел **`docs/deployment/`** (витрина тиража) с golden source
+**`docs/deployment/LITE_SETUP.md`** — сквозной маршрут «голый хост → работающий конвейер» из 13
+нормативных разделов (D2), собирающий кирпичи 10-common ссылками, без форка канона. Compose не
+форкается (D4); канон watchdog-конфига закрывается новым **`.env.watchdog.example`** (D5);
+раздел Gitea фиксирует действующий норматив D10 — branch protection НЕ включать, pre-receive не
+вводить (D3). Полнота/гигиена дока и compose-подмножество защищаются структурным
+`tests/test_lite_setup_doc.py` (D8). Рантайм не трогается; исходы всех вопросов ТЗ §3.8 — ниже.
+
+### D1 (исход А-3) — Размещение: новый раздел `docs/deployment/`, путь бизнес-запроса подтверждён
+
+**Решение: `docs/deployment/LITE_SETUP.md`, как зафиксировано Владельцем (D-4).** Семантика
+разделов: `docs/deployment/` — «как развернуть платформу У СЕБЯ» (читатель — внешний
+оператор/заказчик, платформу видит впервые); `docs/operations/` — «как эксплуатировать НАШ прод»
+(читатель — оператор текущего хоста). `REPLICATION.md` остаётся в `docs/operations/` — это
+runbook фундамента 10-common, исторический якорь ORCH-101, к пути прибит
+`tests/test_replication_smoke.py`; перенос дал бы правку чужого артефакта без выгоды.
+Перекрёстные ссылки обе стороны: REPLICATION.md §1 (строка Type A — Lite → ✅ ORCH-102 + ссылка
+на LITE_SETUP.md) и LITE_SETUP.md §1 (границы — ссылкой на REPLICATION.md §1). INFRA.md получает
+ссылку на deployment-раздел (по фактическому объёму, FR-7).
+
+Привязка: FR-1, FR-7, AC-1, AC-5.
+
+### D2 (FR-1) — Нормативная структура LITE_SETUP.md: 13 разделов, форма «команда + проверка»
+
+**Решение: фиксированная нумерация `## N. <Название>`, порядок = маршрут оператора** (состав —
+обязательный минимум FR-1; анти-дрейф тест ассертит наличие и порядок заголовков):
+
+| § | Раздел | Ключевое содержимое (норматив) |
+|---|--------|--------------------------------|
+| 1 | Рамка Lite | что разворачиваем (орк+watchdog); что заказчик ставит сам; границы vs 10-common/Bundled — ссылка REPLICATION.md §1; платформенные конвенции (репо `orchestrator`, имена сервисов, контейнерный layout — не менять) |
+| 2 | Предусловия хоста | контур: Linux x86_64, Docker Engine + Compose v2, git, python3, node + дистрибутив claude-code; `ORCH_RUN_UID/GID` = uid владельца `ORCH_HOST_REPOS_DIR` (ORCH-040), `ORCH_DOCKER_GID` ← `getent group docker`; ssh (`ORCH_HOST_SSH_DIR`); свободные порты 8500/8501; **каждое предусловие — команда проверки** |
+| 3 | Перенос кода | `git clone <ORCHESTRATOR_GIT_URL>` в `ORCH_DEPLOY_HOST_REPO_PATH` (D7); НИКАКИХ данных/БД/`.env` с боевого хоста; watchdog отдельно не переносится (код в `watchdog/` того же репо) |
+| 4 | Конфигурация | `.env` с нуля от `.env.example` (канон); `python3 scripts/gen_secrets.py [--write]`; карта env — ссылка REPLICATION.md §2; явный список обязательных ключей нового хоста (вкл. `ORCH_PROJECTS_JSON`); `.env.watchdog` от `.env.watchdog.example` (D5); когерентность портов `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL` |
+| 5 | Подключение Plane | workspace/проект; 22 статуса с группами — создаёт `onboard_project.py apply`, таблица ссылкой ONBOARDING.md §1; явно — fail-closed `Confirm Deploy`/`STOP`; API-токен + проверка `curl`; webhook+HMAC: URL `…/webhook/plane`, `X-Plane-Signature`, каверза Plane CE — оба пути (UI и SQL), generic-команды по образцу SETUP_WEBHOOKS.md с плейсхолдерами |
+| 6 | Подключение Gitea | репо (`onboard_project.py` или вручную); токен scope `repo`,`admin:repo_hook` + проверка; per-repo webhook (`push`/`pull_request`/`status`, `X-Gitea-Signature`, ОДИН глобальный секрет); **норматив D3: branch protection НЕ включать** |
+| 7 | LLM (claude CLI) | дистрибутив claude-code и node на хосте = источники маунтов (`ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`); аутентификация CLI (`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`); проверка `claude --version`; модели — `ORCH_AGENT_MODEL_*`/`ORCH_AGENT_EFFORT_*` (резолв ORCH-41, дефолты — `.env.example`) |
+| 8 | Telegram | бот трекера (BotFather → `ORCH_TELEGRAM_BOT_TOKEN`), `chat_id` через `getUpdates`, проверка `getMe`; **отдельный** watchdog-бот → `.env.watchdog` (C-1 ORCH-100: токен орка переиспользовать ЗАПРЕЩЕНО) |
+| 9 | Запуск | `docker compose config` → `up -d --build` → ровно `orchestrator`+`orchestrator-watchdog` (D4); health-чек `GET /health` → 200 `"status":"ok"`, `/queue`+`/metrics` → штатный JSON (`schema_version: 1`); **вилка staging (D6)** |
+| 10 | Регистрация проекта | `onboard_project.py plan → apply → verify` (статусы+лейблы `autoApprove`/`autoDeploy`/`Bug`, репо+webhook, kit, merged `ORCH_PROJECTS_JSON`) → строка в `.env` → управляемый рестарт → `/health`+`/queue`; маршрут — ссылка ONBOARDING.md, в доке — последовательность команд Lite |
+| 11 | Smoke | чек-лист REPLICATION.md §4 (шаги 0–5, опционально 6 до `done`) ссылкой + Lite-предусловия; критерий «конвейер доехал»: задача в БД → analyst-job в `/queue` → артефакты `01–04` в ветке |
+| 12 | Stateless-проверка | первый старт = пустая БД (`data/` чист); `GET /queue` — нулевые счётчики, ни одной задачи `ORCH-*`/`ET-*`; нормативная строка «данные/задачи/секреты боевого хоста НЕ переносятся» |
+| 13 | Траблшутинг | ≥ 5 отказов, каждый «симптом → команда диагностики → лечение»: webhook 401/HMAC mismatch; задача не появилась (реестр/`ORCH_PROJECTS_JSON`/webhook); claude CLI не найден/не аутентифицирован; docker.sock permission denied (`ORCH_DOCKER_GID`); права `/repos` (uid mismatch, ORCH-040/057); Telegram молчит |
+
+**Форма (нормативно, NFR-6/BR-1):** (а) каждый нормативный шаг = fenced-команда + явная проверка
+(маркер «Проверка:» / PASS/FAIL / ожидаемый вывод); (б) хост-специфика в fenced-блоках — ТОЛЬКО
+плейсхолдеры `<...>`/`$ENV_VAR`; боевые литералы (`mva154`, `duckdns`, `82.22.50.71`, реальные
+токены) запрещены; дефолты хост-переменных НЕ копируются в док — ссылка на карту
+REPLICATION.md §2 (иначе fenced-скан D8 и форк канона); (в) язык — русский; (г) футер дока несёт
+норматив сопровождения (NFR-5: меняешь шаги тиража → обнови LITE_SETUP.md в том же PR,
+правило агентов №2).
+
+Привязка: FR-1, FR-3, FR-4, AC-1, AC-3.
+
+### D3 (исход А-1) — Раздел Gitea: канон D10, pre-receive НЕ вводить
+
+**Решение: раздел Gitea фиксирует канон платформы — репо + токен (scope `repo`,
+`admin:repo_hook`) + per-repo webhook + нормативная рамка «branch protection на `main` НЕ
+включать».** Формулировка бизнес-запроса «pre-receive хуки» трактуется по намерению («защита
+`main`») и закрывается действующей моделью: мерж — только через Gitea PR-merge API под токеном
+орка (INV-4, `src/merge_gate.py`); агенты не пушат `main` (конвенция + скоуп токенов).
+Pre-receive хуки НЕ вводятся: это server-side механизм инсталляции Gitea заказчика, платформа
+его не несёт и не проверяет; required-approvals/status-checks дали бы 405/409-класс отказов
+`merge_pr` → ложные HOLD (ORCH-009 ADR-001 D10, инцидент ORCH-063). В §13 (траблшутинг) —
+симптом «PR не мержится / HOLD» с первой проверкой «не включена ли branch protection».
+Пересмотр — только отдельным ADR с анализом совместимости с merge-актором (ORCH-093/INV-4).
+
+Привязка: BRD §1.3/§6, FR-1 п.6, AC-7.
+
+### D4 (исход А-2) — Compose: существующий файл, без lite-форка; свойство держит тест
+
+**Решение: `docker-compose.yml` НЕ форкается** — он уже является Lite-подмножеством (факт из
+контекста). Отдельный `docker-compose.lite.yml` отвергнут: второй файл = вторая правда =
+поверхность дрейфа (зеркало решения D9 ORCH-101 «без скрипта-обвязки»). Свойство фиксируется
+в LITE_SETUP.md §9 и защищается тестом (D8, TC-04) через `yaml.safe_load` (паттерн
+`tests/test_infra_parametrization.py::_compose_services`):
+
+- `set(services) == {"orchestrator", "orchestrator-watchdog", "orchestrator-staging"}`;
+- `services["orchestrator-staging"]["profiles"] == ["staging"]`;
+- множество сервисов без `profiles` (= дефолтный `up -d`) — ровно
+  `{"orchestrator", "orchestrator-watchdog"}`;
+- ни в имени сервиса, ни в `image:`/`container_name:` нет подстрок `plane`/`gitea`
+  (анти-появление молча).
+
+Привязка: FR-2, AC-2, BR-3.
+
+### D5 (исход А-4) — `.env.watchdog.example`: создать; key-set синхронизирован тестом
+
+**Решение: создать `.env.watchdog.example`** — третий канонический env-example
+(симметрия `.env.example`/`.env.staging.example`), единственное разрешённое отклонение диффа от
+docs+tests (предусмотрено ТЗ §2). Нормативное содержимое:
+
+- **полный набор ключей `WATCHDOG_*` — ровно тот же, что блок `WATCHDOG_*` в `.env.example`**
+  (key-set equality, 19 ключей; значения = дефолты канона/`watchdog/config.py`,
+  токены — пустые плейсхолдеры);
+- шапка-комментарий: семантика файла-носителя — sidecar-контейнер читает ТОЛЬКО `.env.watchdog`
+  (compose `env_file: required: false`; отсутствие файла не ломает `up`; нет токена → fail-safe:
+  логи без отправки); **ключ `WATCHDOG_*` в `.env` для sidecar инертен**;
+- норматив C-1 (ORCH-100): свой бот, независимый канал; токен орка переиспользовать запрещено;
+- когерентность порта: `WATCHDOG_METRICS_URL` следует за `ORCH_DEPLOY_PROD_TARGET_PORT`;
+- «не коммить реальный `.env.watchdog`» (зеркало шапки `.env.staging.example`).
+
+Анти-дрейф (D8, TC-02b): `keys(.env.watchdog.example) == {k ∈ keys(.env.example) |
+k.startswith("WATCHDOG_")}` — появление нового ключа watchdog в каноне без обновления example
+(и наоборот) ломает CI. Это дубль по необходимости, защищённый сверкой парсингом, не строкой
+(NFR-4). LITE_SETUP.md §4/§8 предписывают `cp .env.watchdog.example .env.watchdog` + два токена.
+
+Привязка: FR-1 п.4/п.8, FR-6.2, AC-1, AC-7 (C-1).
+
+### D6 (исход А-5) — Staging-контур в Lite: опционален, явная вилка
+
+**Решение: базовый Lite-контур = prod-оркестратор (8500) + watchdog; `orchestrator-staging`
+НЕ обязателен.** Staging нужен ТОЛЬКО если заказчик регистрирует проект `orchestrator`
+(self-hosting развитие самой платформы у себя): стадия `deploy-staging` орка требует
+песочницу 8501 (`.env.staging` от `.env.staging.example`, изолированная БД `./data/staging`,
+guard ORCH-058: staging-порт ≠ прод-порт — fail-closed). Для целевого сценария «раздача на
+тест» (заказчик гоняет СВОИ проекты) staging не участвует. В §9 — явная вилка двумя ветками
+с командами; дефолтная ветка — без staging.
+
+Привязка: FR-1 п.9, AC-2 (staging за профилем), ТЗ §3.8 А-5.
+
+### D7 (исход А-6) — Источник кода: параметризованный шаг
+
+**Решение: шаг §3 — `git clone <ORCHESTRATOR_GIT_URL> <ORCH_DEPLOY_HOST_REPO_PATH>`** (плюс
+опциональный `--branch <тег/срез>`). Конкретный канал дистрибуции (зеркало, доступ к нашему
+Gitea, архив) — решение Владельца ВНЕ репо (коммерческая механика — анти-скоуп BRD §2.2);
+док не хардкодит наш Gitea-URL (это же требует NFR-3/fenced-скан). Плейсхолдер
+`<ORCHESTRATOR_GIT_URL>` включён в перечень подстановок §3.
+
+Привязка: FR-1 п.3, BRD §6, ТЗ §3.8 А-6.
+
+### D8 (FR-6) — Анти-дрейф контур: `tests/test_lite_setup_doc.py`
+
+**Решение: один структурный модуль, детерминированный, без сети/LLM/subprocess** (образец —
+`tests/test_replication_smoke.py`). Нормативные семейства проверок (точная нарезка по
+тест-функциям — за developer, `04-test-plan.yaml`):
+
+| TC | Проверка | Механика |
+|----|----------|----------|
+| TC-01 | Док существует; 13 нормативных разделов D2 присутствуют **в заданном порядке** | regex по заголовкам `^## N\.` |
+| TC-02 | Обязательные кирпичи FR-6.1: `gen_secrets.py`, `onboard_project.py`, `docker compose`, `/health`, `/queue`, `/metrics`, `ORCH_PROJECTS_JSON`, оба webhook-секрета, `X-Plane-Signature`/`X-Gitea-Signature`, `getent group docker`, `Confirm Deploy`/`STOP`, оба Telegram-канала, маркеры PASS/FAIL/«Проверка» | подстроки |
+| TC-02b | Key-sync `.env.watchdog.example` ⇄ блок `WATCHDOG_*` `.env.example` (D5) | парсинг строк `^KEY=` обоих файлов, равенство множеств |
+| TC-03 | Каждый токен `\b(ORCH\|WATCHDOG)_[A-Z0-9_]+\b` из дока существует ключом в `.env.example` (канон 100% ключей, ORCH-101) | regex по доку + парсинг `.env.example` |
+| TC-04 | Compose-подмножество (D4): 3 сервиса, staging за профилем, дефолтный up = орк+watchdog, нет `plane*`/`gitea*` | `yaml.safe_load` |
+| TC-05 | Stateless/гигиена: нормативная строка «не перенос…» присутствует; **в fenced-блоках** нет литералов центрального списка `FORBIDDEN` (импорт из `tests/test_no_host_hardcodes.py`, НЕ копия — один источник истины) и секретоподобных значений (эвристика: hex/base64 ≥ 32 симв., не плейсхолдер) | выделение fenced-блоков + `find_violations`/эвристика |
+| TC-06 | Перекрёстность: `REPLICATION.md` §1 ссылается на `LITE_SETUP.md`; `CHANGELOG.md` несёт `ORCH-102` | подстроки |
+
+Скоуп секрет/литерал-скана — **только fenced-блоки** (копируемое); проза дока дефолтов не
+дублирует (D2-форма, п. б) — поэтому полнодокументный скан не нужен и не даёт ложно-красных.
+Существующие тесты (`test_no_host_hardcodes`, `test_replication_smoke`,
+`test_infra_parametrization`, `test_onboarding_*`) не ослабляются; новые тесты попадают в
+существующие гейты (`check_ci_green`/`check_tests_passed`/merge-gate re-test/coverage ORCH-027)
+автоматически — новый QG НЕ регистрируется (ТЗ §6).
+
+Привязка: FR-6, BR-8, AC-5, AC-6.
+
+### D9 — Границы изменения; что НЕ делается; 07/08 — N/A
+
+- **Дифф задачи:** `docs/**` (LITE_SETUP.md, правки REPLICATION §1/INFRA/README/CLAUDE.md по
+  объёму), `tests/test_lite_setup_doc.py`, `CHANGELOG.md`, `.env.watchdog.example` (D5).
+  **`src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**` — ноль изменений**; любое
+  отклонение — только новым ADR (AC-7).
+- `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — байт-в-байт; новых
+  эндпоинтов/флагов/kill-switch нет (выключать нечего — D-4: док и тесты).
+- **`07-infra-requirements.md` / `08-data-requirements.md` — N/A:** топология не меняется (ни
+  контейнера, ни порта, ни маунта), схема БД не меняется (ТЗ §5). Инфра-предусловий нет:
+  приёмочный smoke-прогон (FR-5/AC-4) идёт на СУЩЕСТВУЮЩЕМ контуре — staging-песочница
+  `ORCH_STAGING_PORT`=8501 + одноразовый sandbox-проект (прецедент ORCH-101 AC-3 /
+  ONBOARDING.md §5); прогон на реальном новом хосте желателен, но не требование приёмки.
+- **Self-hosting (NFR-1):** прод-контейнер не рестартится; выкат — штатный конвейер
+  (deploy-staging 8501 → ручной `Confirm Deploy`). Для enduro-trails изменение инертно.
+- Эскалация: `arch:major-change` не требуется (нет новой стадии/компонента/смены БД); ТЗ
+  удовлетворимо без нарушения принципов — возврат в анализ не нужен.
+
+## Альтернативы
+
+- **Разместить инструкцию в `docs/operations/`** — отвергнуто: целевой читатель другой (внешний
+  оператор, не оператор нашего прода); путь `docs/deployment/LITE_SETUP.md` зафиксирован
+  Владельцем (D-4), отступать не от чего (D1).
+- **Перенести REPLICATION.md в `docs/deployment/`** — отвергнуто: правка чужого артефакта и
+  путей `tests/test_replication_smoke.py` без выгоды; перекрёстных ссылок достаточно (D1).
+- **Отдельный `docker-compose.lite.yml`** — отвергнуто: вторая правда о сервисах, дрейф-
+  поверхность; существующий файл уже = подмножество, тест дешевле форка (D4).
+- **Pre-receive хуки / branch protection для «защиты `main`»** — отвергнуто: ломает PR-merge
+  API merge-актора (D10 ORCH-009, ложные HOLD); защита — конвенция + скоуп токенов + INV-4 (D3).
+- **Без `.env.watchdog.example`, шаг «создай файл с двумя ключами» в доке** — отвергнуто:
+  двусмысленность файла-носителя остаётся (ключи канонизированы в `.env.example`, но там для
+  sidecar инертны); example-файл + key-sync тест дешевле и надёжнее прозы (D5).
+- **Скопировать таблицу 22 статусов / карту env в LITE_SETUP.md** — отвергнуто: форк канона
+  (R-2); ссылки на golden source + явное упоминание только fail-closed имён
+  (`Confirm Deploy`/`STOP`) — достаточно (FR-4); дубль допустим только с тест-сверкой
+  парсингом/импортом (прецедент — TC-02b).
+- **Полнодокументный секрет-скан (не только fenced)** — отвергнуто: ложно-красные на прозе
+  («не используйте mva154-значения»); норматив D2(б) выводит дефолты из дока, fenced-скан
+  покрывает всё копируемое (D8).
+
+## Последствия
+
+- **+** Закрывается Type A эпика ORCH-10: заказчик получает единый исполняемый маршрут
+  «голый хост → конвейер» без археологии по 4 докам; Type B (Bundled) строится поверх
+  (переиспользует §2–§8, §11–§13).
+- **+** Compose-подмножество и полнота инструкции из «фактов» становятся CI-гарантиями
+  (TC-01…TC-06); ловушка файла-носителя watchdog-конфига закрыта каноном (D5).
+- **+** Нулевой риск рантайма: docs+tests, конвейер байт-в-байт, kill-switch не нужен.
+- **−** Новый golden source = новая обязанность сопровождения (шаги тиража меняются →
+  LITE_SETUP.md в том же PR; NFR-5) — митигировано футером-нормативом, правилом агентов №2 и
+  структурным тестом, который рвёт CI при дрейфе кирпичей.
+- **−** Дубль ключей `WATCHDOG_*` в двух example-файлах — принят осознанно, защищён key-sync
+  тестом TC-02b (равенство множеств, не строк).
+- **−** Приёмка «без доп-вопросов» на staging-песочнице ≠ прогон на реальном чужом хосте —
+  остаточный риск принят (прецедент ORCH-101 AC-3); зазор сужают чек-команды предусловий §2 и
+  траблшутинг §13.
+- **Откат:** удалить `docs/deployment/`, `tests/test_lite_setup_doc.py`,
+  `.env.watchdog.example`, вернуть строку REPLICATION.md §1 — состояние 1:1, ни миграций,
+  ни состояния (ТЗ §7).
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-102/01-brd.md` (решения Владельца D-1…D-5, факты §1.3)
+- TRZ: `docs/work-items/ORCH-102/02-trz.md` (FR-1…FR-7, вопросы §3.8 А-1…А-6)
+- Acceptance: `docs/work-items/ORCH-102/03-acceptance-criteria.md` (AC-1…AC-7)
+- Риски: `docs/work-items/ORCH-102/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0037-lite-replication-canon.md`
+- Сверено по коду/репо: `docker-compose.yml` (3 сервиса, `profiles: [staging]`,
+  `env_file: {path: .env.watchdog, required: false}`), `.env.example` (блок `WATCHDOG_*`,
+  19 ключей), `watchdog/config.py` (дефолты), `tests/test_infra_parametrization.py`
+  (`yaml.safe_load`-паттерн), `tests/test_no_host_hardcodes.py` (`FORBIDDEN`,
+  `find_violations`), `tests/test_replication_smoke.py` (образец структурного теста дока),
+  `docs/operations/REPLICATION.md` §1–§5, `docs/operations/ONBOARDING.md` §1/§5,
+  `docs/operations/SETUP_WEBHOOKS.md`
+- Инварианты соседних решений: ORCH-009 ADR-001 D10 (`docs/work-items/ORCH-009/06-adr/…`),
+  adr-0036 (ORCH-101, 10-common), adr-0035 (onboarding), adr-0033 (sidecar-watchdog, C-1
+  ORCH-100), ORCH-040 (uid/gid/HOME), ORCH-058 (staging-порт guard), INV-4 (ORCH-093)

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

@@ -0,0 +1,40 @@
+---
+work_item: ORCH-102
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-102 — ORCH-10a Lite-тираж (инструкция + анти-дрейф)
+
+Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+> Решения, на которые ссылаются митигейшны (D1…D9), — `06-adr/ADR-001-lite-setup-doc-canon.md`.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Дрейф инструкции**: платформа развивается, шаги LITE_SETUP.md тихо устаревают (новый env-ключ, изменённый маршрут онбординга) | Сред. | Сред. | Структурный `tests/test_lite_setup_doc.py` (D8: кирпичи, env-ключи ⊂ `.env.example`, compose-подмножество, перекрёстность) рвёт CI при дрейфе; футер-норматив NFR-5 + правило агентов №2 («шаги тиража → док в том же PR»); reviewer-ось обзорных доков (правило №6) |
+| TR-2 | **Форк канона**: скопированная в док таблица статусов/env/вебхуков разъезжается с golden source | Низ. | Сред. | D2/FR-4: канон — только ссылками (ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS); в доке дублируются лишь fail-closed имена (`Confirm Deploy`/`STOP`) и списки обязательных ключей — оба под TC-02/TC-03; единственный структурный дубль (`WATCHDOG_*`) — под key-sync TC-02b |
+| TR-3 | **«Без доп-вопросов» непроверяемо**: реальный заказчик найдёт пробел, который не увидел внутренний прогон | Сред. | Низ. | Операционализация BRD §6: каждый шаг = команда+проверка (TC-01/02), приёмочный smoke-прогон на чистом контуре фиксируется в `13-test-report.md`/`15-staging-log.md`, траблшутинг ≥5 отказов (§13). Остаточные пробелы лечатся правкой golden source штатной задачей |
+| TR-4 | **Гетерогенность хостов заказчиков**: rootless docker, иной uid владельца репо, нет node/claude-code, arm64 | Сред. | Сред. | §2 «Предусловия» с явным поддерживаемым контуром (Linux x86_64, Docker+Compose v2, git, python3, node) и чек-командой на каждое предусловие (`getent group docker`, владение `ORCH_HOST_REPOS_DIR` = `ORCH_RUN_UID`); вне контура — вне гарантии Lite (BRD §6); §13 покрывает типовые отказы (docker.sock gid, uid mismatch ORCH-040/057) |
+| TR-5 | **Заказчик включит branch protection / pre-receive на `main`** вопреки нормативу → ложные HOLD merge-актора на ЕГО инсталляции (класс ORCH-063) | Низ. | Выс. (у заказчика) | D3: явная нормативная рамка в §6 («НЕ включать», основание D10 ORCH-009/INV-4) + симптом в §13 («PR не мержится/HOLD → проверь protection»); для нашего прода риск нулевой (его Gitea не трогается) |
+| TR-6 | **Утечка секрета/боевого литерала** через примеры дока или `.env.watchdog.example` | Низ. | Выс. | NFR-3: только плейсхолдеры; TC-05 — fenced-скан на `FORBIDDEN` (импорт из `test_no_host_hardcodes.py`, один источник истины) + эвристика секретоподобных значений; security-гейт ORCH-022 (`17-security-report.md`) обязан остаться PASS; D2(б): дефолты хост-переменных в док не копируются |
+| TR-7 | **Хрупкость анти-дрейф теста**: ложно-красный CI от безобидной правки прозы → соблазн ослабить тест | Сред. | Низ. | D8: ассерты только на стабильное (заголовки `## N.`, подстроки-кирпичи, парсинг env-ключей, `yaml.safe_load`), запреты — только в fenced-блоках; никаких проверок прозы/формулировок; паттерн уже обкатан (`test_replication_smoke.py` стабилен) |
+| TR-8 | **`.env.watchdog.example` разъезжается** с блоком `WATCHDOG_*` `.env.example` / дефолтами `watchdog/config.py` | Низ. | Низ. | TC-02b: равенство множеств ключей двух файлов; значения = дефолты канона (сверены с `watchdog/config.py` при ревью); полнота самого `.env.example` уже держится тестами ORCH-101 |
+| TR-9 | **Приёмочный smoke на staging-песочнице ≠ голый чужой хост**: средовые эффекты нового железа (сеть, версии docker) не проверены | Сред. | Низ. | Принятый прецедент ORCH-101 AC-3 (без нового железа в контуре задачи; FR-5(г) — прогон на реальном хосте желателен, не блокер); зазор сужают чек-команды §2 и траблшутинг §13; первый реальный тираж — операторски сопровождаемый |
+
+## Сводный вывод
+
+Доминирующий класс — **документационный** (дрейф/полнота/гигиена), систематически закрытый
+структурными тестами (TC-01…TC-06) и нормативом golden source; рантайм-рисков нет — дифф
+docs+tests (+`.env.watchdog.example`), конвейер и `src/**` байт-в-байт (D9), kill-switch не
+требуется. Самый тяжёлый по влиянию риск (TR-5) материализуется только на инсталляции
+заказчика и купирован явным нормативом + траблшутингом. Эскалация `arch:major-change` не
+требуется; возврат в анализ не нужен. **Остаточный риск для self-hosting прод-конвейера —
+минимальный** (прод-контейнер не трогается; выкат — штатно через staging 8501 →
+`Confirm Deploy`).

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

@@ -0,0 +1,93 @@
+---
+verdict: APPROVED
+work_item: ORCH-102
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-102
+version: 1
+---
+
+# Review ORCH-102 — ORCH-10a Lite-тираж: LITE_SETUP.md + канон watchdog-конфига + анти-дрейф контур
+
+## Summary
+
+PR (`d03e29f`, docs+tests, 2378 строк) реализует все требования ТЗ и решения ADR-001 (D1–D9)
+точно по спецификации; P0/P1 findings отсутствуют. Дифф строго в декларированных границах:
+`docs/**`, `tests/test_lite_setup_doc.py`, `CHANGELOG.md`, `.env.watchdog.example` + `.gitignore`
+(единственное разрешённое отклонение по ADR D5/ТЗ §2). **`src/**`, `docker-compose.yml`,
+`Dockerfile`, `scripts/**` — ноль изменений** (AC-7 PASS, сверено по `git diff --stat`);
+`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД не тронуты.
+
+**Проверено фактически (не по описанию):**
+- Полный регресс: `pytest tests/ -q` → **1789 passed** (включая 25 новых структурных тестов;
+  заявление CHANGELOG «25 структурных тестов» совпадает с фактом). Существующие
+  `test_no_host_hardcodes`/`test_replication_smoke`/`test_infra_parametrization` не ослаблены.
+- **AC-1/FR-1:** `docs/deployment/LITE_SETUP.md` — 13 нормативных разделов D2 в порядке маршрута
+  оператора; каждый исполняемый раздел = fenced-команда + явная «Проверка:»/PASS/FAIL;
+  хост-специфика только плейсхолдерами. Копируемые команды сверены с фактическими контрактами
+  кода: флаги `onboard_project.py` (`plan|apply|verify` + `--name/--repo/--prefix/--stack/
+  --test-cmd/--prod-port/--staging-port/--webhook-url`) — совпадают с argparse скрипта;
+  exit-коды (0/2 = manual-step) — совпадают с docstring/кодом; `gen_secrets.py` печатает именно
+  `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET`; `/metrics` → `schema_version: 1`
+  (`src/metrics.py::SCHEMA_VERSION`); ссылка на шаги 0–5/6 REPLICATION §4 — фактическая нумерация
+  таблицы §4 совпадает. Траблшутинг — 7 отказов (≥5 по AC-1), каждый «симптом → диагностика → лечение».
+- **AC-2/FR-2 (D4):** compose не форкается; TC-04 ассертит ровно 3 сервиса, staging строго за
+  `profiles: [staging]`, дефолтный up = орк+watchdog, анти-`plane*`/`gitea*` — через `yaml.safe_load`.
+- **AC-3/FR-3:** stateless-норматив (§12 + шапка), чистый старт, проверка чистоты через
+  `GET /queue`, секреты только свежевыпущенные; в fenced-блоках и `.env.watchdog.example` —
+  только плейсхолдеры (TC-05 + зеркальный placeholder-тест, токены пустые).
+- **D5:** `.env.watchdog.example` — key-set ровно = блоку `WATCHDOG_*` `.env.example` (19 ключей,
+  сверено; держится TC-02b равенством множеств), шапка несёт семантику файла-носителя, C-1
+  ORCH-100, когерентность порта, do-not-commit; `.env.watchdog` добавлен в `.gitignore`.
+- **AC-6/FR-6 (D8):** канон не форкается — статусы/env/вебхуки/smoke ссылками; «22 статуса»
+  защищено **импортом** `plane_sync._PLANE_NAME_TO_KEY` (не строкой); `FORBIDDEN` — импорт из
+  `test_no_host_hardcodes.py` (один источник истины); секрет-эвристика с негативным самочеком
+  (анти-вечнозелёность). Тесты детерминированы, без сети/LLM/subprocess.
+- **D3 (исход А-1):** §6.4 нормативно запрещает branch protection на `main` (ADR D10 ORCH-009 /
+  INV-4), pre-receive не вводится, ОДИН глобальный webhook-секрет; §13.7 — симптом «HOLD».
+- **Трассировка (TRACEABILITY):** правки чужих маркированных блоков сверены: REPLICATION.md §1
+  (ORCH-101) — ровно предусмотренное закрытие строки «Type A — Lite» → ✅ + ссылка; INFRA.md —
+  аддитивное расширение секрет-норматива на `.env.watchdog`; инварианты ORCH-101/009/100/040/058/
+  INV-4 не нарушены (инструкция им следует, ADR их цитирует). Бонус: дозаполнена пропущенная
+  строка adr-0036 в индексе `docs/architecture/adr/README.md` + max-номер → 0037.
+
+## Findings
+
+### P0 — Blocker
+Нет.
+
+### P1 — Must fix
+Нет.
+
+### P2 — Should fix
+Нет.
+
+### P3 — Nice to have (не блокирует)
+- [ ] `LITE_SETUP.md` §13.3: в fenced-блоке литерал `/usr/bin/claude` — совпадает с канон-дефолтом
+  `ORCH_CLAUDE_BIN` (контейнерный layout, не хост-специфика), но `docker exec orchestrator
+  "$ORCH_CLAUDE_BIN" --version`-форма была бы устойчивее к смене дефолта (правило формы D2(б) —
+  ссылка на канон вместо копии значения).
+- [ ] `tests/test_lite_setup_doc.py` BRICKS: кирпич `"STOP"` как подстрока всего дока слаб
+  (матчится любым словом STOP); фактически заякорен `test_plane_canon_is_linked_not_forked`
+  (STOP внутри тела §5), так что дублирование безвредно — можно убрать из BRICKS или заякорить.
+
+## Документация
+
+**Полностью обновлена в том же PR** (правило №2; ось 4 — PASS):
+- `CHANGELOG.md` — запись ORCH-102 (фактуально точная: 25 тестов, траблшутинг ×7 — сверено);
+- `CLAUDE.md` — блок «Lite-тираж (ORCH-102)»; `README.md` — способность Lite + `docs/deployment/`
+  в структуре; `docs/architecture/README.md` — блок Type A — Lite;
+- ADR: per-work-item `06-adr/ADR-001-lite-setup-doc-canon.md` (D1–D9, исходы А-1…А-6) + сквозной
+  `docs/architecture/adr/adr-0037-lite-replication-canon.md` + индекс ADR обновлён;
+- `docs/operations/REPLICATION.md` §1 и `docs/operations/INFRA.md` — перекрёстные ссылки (FR-7);
+- **ORCH-079 (обзорные доки):** README «Известные ограничения» проверен — пунктов про
+  тираж/Lite в открытом списке не было и нет, закрывать/снимать нечего; противоречий факту нет.
+
+**Handoff для tester (не finding):** AC-4 требует фиксации приёмочного smoke-прогона на чистом
+контуре (staging-песочница + sandbox-проект) в `13-test-report.md` и/или `15-staging-log.md` —
+эти артефакты по конвейеру создаются на стадиях testing/deploy-staging (план — TC-09
+`04-test-plan.yaml`); на стадии review их отсутствие штатно.

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

@@ -0,0 +1,95 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-102
+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-102
+---
+
+# Test Report — ORCH-102 — ORCH-10a Lite-тираж: LITE_SETUP.md + канон watchdog-конфига + анти-дрейф контур
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Дата: 2026-06-11
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-102-orch-10a-lite-watchdog`
+- Ветка: `feature/ORCH-102-orch-10a-lite-watchdog` (HEAD `e67c026`)
+- Прогон выполнен в worktree ветки задачи (не в общем `/repos/orchestrator`).
+- Вердикт ревью (`12-review.md`): **APPROVED** (P0/P1 — нет).
+
+## Smoke API (read-only)
+| Проверка | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — задача ORCH-102 (task 89) на стадии `testing` |
+| `GET /queue` | PASS — отдаёт полезную нагрузку, штатные счётчики |
+| Блок `serial_gate` в `/queue` (ORCH-088) | PASS — присутствует; `orchestrator.active_task = ORCH-102 (testing)`, не заморожен |
+| Блок `auto_labels` в `/queue` (ORCH-089) | PASS — присутствует |
+| `GET /metrics` | PASS — `schema_version: 1` |
+| `GET /health` staging (8501) | PASS — `{"status":"ok","service":"orchestrator"}` |
+
+## Smoke-процедура Lite-тиража (AC-4 / FR-5, TC-09)
+Воспроизводимость smoke-runbook LITE_SETUP.md подтверждена на текущей инфре (read-only, stateless,
+без переноса данных/секретов; прецедент ORCH-101 AC-3). Docs+tests-задача — `src/**` не тронут,
+полноценный e2e на новом железе заказчика заменён прогоном артефактов smoke-цепочки:
+| Шаг smoke (REPLICATION §4 / LITE_SETUP §10–12) | Результат |
+|-----|-----------|
+| `docs/deployment/LITE_SETUP.md` существует по канонному пути (33 КБ, 13 разделов) | PASS |
+| `.env.watchdog.example` существует (канон watchdog-конфига, ADR D5) | PASS |
+| `scripts/gen_secrets.py` запускается в безопасном (print) режиме | PASS — exit 0, файлы не тронуты (`git status` чист) |
+| Webhook-секреты крипто-случайны (64 hex = 32 байта) | PASS — `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` |
+| Внешние токены/боевые секреты в доке отсутствуют (плейсхолдеры) | PASS (подтверждено TC-05) |
+| Конфиг резолвится, инстанс поднят, health-check зелёный (см. Smoke API) | PASS |
+| `GET /metrics` → `schema_version: 1` | PASS |
+| Compose-подмножество (ровно орк+watchdog, staging за профилем) | PASS — структурно через TC-04 (yaml-парс; `docker` CLI в песочнице tester'а недоступен, свойство фиксируется тестом) |
+
+## Результаты (покрытие TC из `04-test-plan.yaml`)
+
+| TC ID | Описание | Покрывающие тесты | Результат |
+|-------|----------|-------------------|-----------|
+| TC-01 | LITE_SETUP.md существует по канонному пути и несёт ВСЕ 13 нормативных разделов FR-1 (AC-1/FR-1) | `test_lite_setup_doc::test_doc_exists_with_all_13_sections_in_order`, `test_doc_carries_all_mandatory_bricks` | PASS |
+| TC-02 | Форма «каждый шаг — команда/проверка»: fenced-команды + маркеры PASS/FAIL/«Проверка», ключевые кирпичи (AC-1/FR-1, NFR-6) | `test_every_normative_section_carries_commands`, `test_doc_carries_explicit_check_markers` | PASS |
+| TC-03 | Согласованность env-канона: каждый `ORCH_*`/`WATCHDOG_*` в доке есть в `.env.example`; обязательный набор нового хоста явно (AC-1/AC-6/FR-1.4/FR-6.2) | `test_every_env_token_in_doc_exists_in_env_example`, `test_mandatory_new_host_keys_are_explicit`, `test_watchdog_example_keys_sync_with_env_example_block` | PASS |
+| TC-04 | Compose-подмножество: ровно `{orchestrator, orchestrator-watchdog, orchestrator-staging}`, staging за `profiles:[staging]`, без `plane*`/`gitea*` (AC-2/FR-2) | `test_compose_services_are_exactly_the_lite_set`, `test_compose_staging_is_strictly_behind_profile`, `test_compose_has_no_plane_or_gitea_services`, `test_doc_documents_default_up_composition` | PASS |
+| TC-05 | Stateless и секрет-гигиена: нормативная строка «не копируются», чистая БД + новые секреты, проверка чистоты, нет боевых литералов/секретов в код-блоках (AC-3/FR-3/NFR-3) | `test_doc_has_stateless_normative_line`, `test_doc_prescribes_clean_db_and_fresh_secrets`, `test_fenced_blocks_carry_no_forbidden_literals`, `test_fenced_blocks_carry_no_secret_like_values`, `test_secret_heuristic_is_not_evergreen`, `test_watchdog_example_secrets_are_placeholders_only` | PASS |
+| TC-06 | Канон не форкается: статусы ссылкой на ONBOARDING §1 + fail-closed `Confirm Deploy`/`STOP`; «22 статуса» сверены импортом `plane_sync._PLANE_NAME_TO_KEY`; env/smoke ссылкой на REPLICATION (AC-6/FR-4/NFR-4) | `test_plane_canon_is_linked_not_forked`, `test_status_count_claim_matches_plane_sync`, `test_env_map_and_smoke_are_linked_to_replication` | PASS |
+| TC-07 | Раздел Gitea: события `push/pull_request/status`, ОДИН глобальный webhook-секрет, норматив «branch protection НЕ включать» (ADR D10 ORCH-009) (AC-1/AC-7/FR-1.6/§3.8 А-1) | `test_gitea_section_fixes_platform_invariants`, `test_gitea_section_forbids_branch_protection` | PASS |
+| TC-08 | Перекрёстная документация: REPLICATION §1 ссылается на LITE_SETUP; CHANGELOG несёт ORCH-102 (AC-5/FR-7) | `test_replication_boundaries_reference_lite_setup`, `test_changelog_has_orch_102_entry` | PASS |
+| TC-09 | Приёмочный smoke-прогон по LITE_SETUP на чистом контуре; вердикт фиксируется tester'ом (процедура, не pytest) (AC-4/FR-5) | см. раздел «Smoke-процедура Lite-тиража» + «Smoke API» выше | PASS |
+| TC-10 | Полный регресс `pytest tests/ -q` зелёный; существующие структурные тесты не ослаблены; дифф не трогает машину стадий/QG/вердикты/схему БД (AC-5/AC-7/NFR-2) | весь набор — **1789 passed** | PASS |
+
+Соответствие критериям `03-acceptance-criteria.md`: AC-1 (TC-01/02/03), AC-2 (TC-04), AC-3 (TC-05),
+AC-4 (TC-09 + smoke-процедура), AC-5 (TC-08/TC-10), AC-6 (TC-03/06), AC-7 (TC-07/TC-10) — все
+покрыты и зелёные.
+
+## Вывод pytest
+```
+============================= test session starts ==============================
+platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
+rootdir: /repos/_wt/orchestrator/feature_ORCH-102-orch-10a-lite-watchdog
+configfile: pytest.ini
+plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
+........................................................................ [100%]
+================== 1789 passed, 1 warning in 64.06s (0:01:04) ==================
+```
+(единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, предсуществующий, не связан с задачей.)
+
+Целевой модуль задачи (отдельный прогон):
+```
+tests/test_lite_setup_doc.py
+======================== 25 passed, 1 warning in 0.44s =========================
+```
+(25 структурных тестов покрывают TC-01…TC-08; заявление CHANGELOG «25 структурных тестов» совпадает с фактом.)
+
+## Итог
+**PASS** — полный регресс зелёный (1789 passed), все 10 TC из `04-test-plan.yaml` выполнены и
+сопоставлены с критериями `03-acceptance-criteria.md`. Smoke API read-only (включая блоки
+`serial_gate` и `auto_labels` в `/queue`, `/metrics schema_version:1`) и smoke-процедура
+Lite-тиража (LITE_SETUP.md + безопасный прогон `gen_secrets.py`, stateless, без переноса данных)
+зелёные. Задача переходит на `deploy-staging`.
+</content>
+</invoke>

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

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-102
+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-102/15-staging-log.md

@@ -0,0 +1,36 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-102
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+timestamp: 2026-06-10T21:39:20Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed. Canonical run **inside** the `orchestrator-staging` container
+(8501) via the Docker exec API (`scripts/staging_check.py --base-url http://localhost:8501
+--mode stub`). Exit code **0** → `staging_status: SUCCESS`.
+
+All REAL checks green. The only two failures are the known sandbox-infra checks C9a/C9b
+(depend on SANDBOX bot accounts being project members, not on the pipeline) and are
+waived under ORCH-061 tolerance (`staging_infra_tolerance_enabled=True`).
+
+```
+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 with counts/max_concurrency/resilience, A3 `ORCH_STAGING=true`.
+- **Block B (ACCESS)**: PASS — B4 Plane sandbox accessible, B5 Gitea `orchestrator-sandbox` push=true, B6 registry isolation (sandbox present, prod ET/ORCH absent).
+- **Block C (E2E, mode=stub)**: C7 create issue PASS, C8 trigger pipeline PASS; C9a/C9b FAIL → **waived** (sandbox-infra, ORCH-061).
+
+RESULT: 8/10 checks PASS. REAL failed: none. SANDBOX_INFRA failed (waived): C9a, C9b.
+
+> Note: ORCH-102 is a docs+tests-only change (`src/**`/compose/Dockerfile/`scripts/**` untouched);
+> the staging gate is run as the mandatory self-hosting safety net before prod deploy.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+Work Item ID: ORCH-103
+
+## Description
+
+TBD

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

@@ -0,0 +1,199 @@
+---
+work_item: ORCH-103
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD: ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+Work Item: **ORCH-103** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
+Заказчик: Слава · Эпик: **ORCH-10** (домен D5 «Масштаб», `docs/epics/self-evolution.md`) · Тип: **B — Bundled**
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1. Цель эпика ORCH-10
+Тираж платформы — РАЗДАЧА текущей функциональности нескольким заказчикам **на тест**.
+Решения Владельца 10.06 (приняты как требования): ДВА типа тиража, ОБА **stateless**
+(наши задачи/данные/секреты НЕ переносим — чистый старт):
+
+- **Тип A (Lite, ORCH-102 ✅)** — переносится ТОЛЬКО орк+watchdog; Plane/Gitea/LLM/Telegram
+  заказчик донастраивает сам по инструкции `docs/deployment/LITE_SETUP.md`.
+- **Тип B (Bundled, эта задача)** — **весь стек одним комплектом**
+  (орк + watchdog + Gitea + Plane + рантайм-обвязка агентов) — «под ключ».
+
+### 1.2. Проблема, которую закрывает ORCH-103
+Lite предполагает, что у заказчика **уже есть** (или он сам поднимет) свои Plane и Gitea.
+Для заказчика без собственной инфраструктуры это барьер: Plane CE self-hosted — это ~14
+контейнеров со своей БД/брокером/хранилищем, Gitea — отдельная установка, и поверх всего —
+первичная инициализация (админы, токены, workspace, 22 статуса, лейблы, вебхуки в обе стороны,
+git-доступ агентов). Сегодня репо не содержит ни compose-описания этого стека, ни автоматизации
+его доводки: разворачивание «с нуля до работающего конвейера» = многочасовая ручная работа по
+сторонним докам с рисками дефолтных паролей и дрейфа от канона платформы.
+
+ORCH-103 должен дать: **один compose-комплект** всего стека + **bootstrap-скрипт**, доводящий
+свежеподнятый стек до рабочего состояния одной командой/визардом, + **новые секреты** на каждую
+инсталляцию + **инструкцию `docs/deployment/BUNDLED_SETUP.md`** с требованиями к хосту.
+
+### 1.3. Установленные факты (проверено по репо — не изобретать)
+- **Корневой `docker-compose.yml` защищён анти-дрейфом:** ровно 3 сервиса
+  (`orchestrator`, `orchestrator-watchdog`, `orchestrator-staging` за `profiles: ["staging"]`);
+  `tests/test_lite_setup_doc.py` (TC-04) проверяет точное множество сервисов и **запрещает**
+  появление в нём имён/образов с подстроками `plane`/`gitea` → bundle-компоуз обязан быть
+  **отдельным файлом**, корневой compose не форкается и не расширяется.
+- **Кирпичи уже в `main` (переиспользовать, не дублировать):**
+  - `scripts/gen_secrets.py` (ORCH-101) — криптослучайные webhook-секреты
+    (`ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET`), печать по умолчанию,
+    `--write` отказывает при существующем `.env`, `--force` — перезапись; exit 0/2.
+  - `scripts/onboard_project.py` (ORCH-009) — `plan` (GET-only) / `apply` (идемпотентный ensure,
+    без delete) / `verify`: Plane-проект + **22 статуса** (read-only импорт
+    `plane_sync._PLANE_NAME_TO_KEY`, fail-closed имена `Confirm Deploy`/`STOP`) + лейблы
+    `autoApprove`/`autoDeploy`/`Bug`; Gitea-репо + per-repo webhook (`push`/`pull_request`/`status`,
+    ОДИН глобальный `ORCH_GITEA_WEBHOOK_SECRET`); недоступное в Plane CE API → `manual-step`
+    (fail-safe); exit 0/2/1.
+  - `docs/operations/REPLICATION.md` (ORCH-101) — карта env (§2), чек-лист секретов (§3),
+    **smoke §4** (шаги 0–6 с PASS/FAIL: config-резолв → `/health` → `/queue`+`/metrics` →
+    onboard plan/apply/verify → тестовая задача → артефакты `01–04` → опц. до `done`); §1 —
+    таблица границ, где Type B помечен «отдельная задача».
+  - `docs/deployment/LITE_SETUP.md` (ORCH-102) — канон тиражной инструкции: 13 нормативных
+    разделов, каждый шаг = fenced-команда + явная «Проверка:» PASS/FAIL, хост-специфика только
+    плейсхолдерами; канон не форкается — общие шаги ссылками.
+  - `.env.example` — канон 100% ключей орка; `.env.watchdog.example` — канон watchdog
+    (key-set-sync тестом, D5 ORCH-102).
+- **Хост-параметризация завершена (ORCH-101):** платформа разворачивается без правки кода —
+  только env (`${VAR:-default}`-интерполяция compose, `ARG APP_*` Dockerfile); анти-регресс
+  `tests/test_no_host_hardcodes.py` (FORBIDDEN-литералы: IP/`/home/slin`/`mva154`/`duckdns`).
+- **Claude CLI НЕ запечён в образ орка:** монтируется с хоста
+  (`ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`/`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`).
+  «Агенты» в комплекте = рантайм-обвязка запуска; **инсталляция Claude CLI и LLM-ключ — внешнее
+  предусловие хоста заказчика** (как Lite §7), bundle их не содержит и не генерирует.
+- **Нормативы тиражной Gitea:** branch protection на `main` НЕ включать (D10 ORCH-009 / INV-4 —
+  мерж только через Gitea PR-merge API); pre-receive не вводится.
+- **Plane CE self-hosted ≈ 14 контейнеров** (web/admin/space/api/worker/beat/live/migrator +
+  postgres/redis/mq/minio/proxy) — ресурсоёмко; часть первичной инициализации в CE недоступна
+  по API → честные ручные чекпоинты (паттерн `manual-step` ORCH-009).
+
+---
+
+## 2. Объём (scope)
+
+### 2.1. В объёме
+- **Bundle-compose** — отдельный compose-комплект всего стека: орк + watchdog + Gitea +
+  Plane-стек (~14 контейнеров); пиннинг версий; чистые именованные тома; согласованная
+  сетевая достижимость (вебхуки в обе стороны).
+- **Bootstrap-скрипт** — один запуск (команда/визард): поднять всё → дождаться
+  готовности/миграций → инициализация Gitea (админ/токен) → инициализация Plane
+  (instance/workspace/API-токен; CE-ограничения → явные manual-step чекпоинты) →
+  онбординг sandbox-проекта (22 статуса/3 лейбла/репо/вебхуки — через `onboard_project.py`) →
+  git-доступ агентов → сборка `.env`/`.env.watchdog` орка → health → smoke-подсказка.
+- **Инициализация секретов** — генерация НОВЫХ на каждую инсталляцию (reuse `gen_secrets.py` +
+  bundle-внутренние креды: пароли БД/брокера/хранилища Plane, админ Gitea); дефолтных паролей
+  в репо нет.
+- **`docs/deployment/BUNDLED_SETUP.md`** — инструкция запуска bundle по канону LITE_SETUP,
+  включая **требования к хосту (RAM/диск/CPU/порты)**.
+- **Структурные анти-дрейф тесты** (без docker/сети/LLM в CI) + полный зелёный pytest + CHANGELOG.
+- Отметка Type B в `docs/operations/REPLICATION.md` §1 (границы трёх задач эпика).
+
+### 2.2. Вне объёма (явно, не делать)
+- Изменения рантайма: `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/`,
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт.
+- Перенос наших задач/данных/секретов (stateless — решение Владельца 10.06).
+- Автоматическая установка Claude CLI / выдача LLM-ключей / создание Telegram-ботов —
+  внешние предусловия заказчика (документируются, не автоматизируются).
+- HTTPS/домены/публичный reverse-proxy заказчика — за рамками bundle (документируется
+  как ручной шаг при необходимости).
+- Процедура обновления (upgrade) развёрнутого bundle; миграция Lite→Bundled; кластерные/
+  multi-host топологии; мультитенантность (D5.6) и горизонтальный воркер-пул (D5.4).
+- Какая-либо активация bundle на НАШЕМ боевом хосте.
+
+---
+
+## 3. Заинтересованные стороны
+- **Владелец (Слава)** — раздаёт платформу заказчикам на тест; принимает результат.
+- **Оператор заказчика** — целевой читатель BUNDLED_SETUP.md: чистый Linux-хост,
+  docker+compose, без знания внутренностей платформы.
+- **Self-hosting прод** (`orchestrator`, общий для всех проектов) — не должен быть затронут:
+  задача — артефакты репо (compose/скрипт/доки/тесты), активируемые только явным запуском
+  на ЦЕЛЕВОМ хосте.
+
+---
+
+## 4. Бизнес-требования (BR)
+
+| ID | Требование | Связь |
+|----|------------|-------|
+| BR-1 | Единый bundle-compose (отдельный файл) поднимает ВЕСЬ стек одной командой: орк, watchdog, Gitea, Plane-стек. Корневой `docker-compose.yml` не форкается и не меняется. | AC-1, AC-6, FR-1 |
+| BR-2 | Bootstrap-скрипт ОДНИМ запуском (команда/визард) доводит свежеподнятый стек до рабочего состояния: готовность/миграции → init Gitea → init Plane → онбординг sandbox-проекта → git-доступ агентов → конфиг орка → health. Шаги, физически недоступные через Plane CE API, оформляются явными интерактивными manual-step чекпоинтами (fail-safe, паттерн ORCH-009) — без молчаливых пропусков. | AC-1, FR-2 |
+| BR-3 | После bootstrap smoke проходит: тестовый проект создан, тестовая задача доезжает минимум до артефактов `01–04` в ветке (минимальный сигнал REPLICATION §4 шаг 5); расширенно — до `done`. Вебхуки работают в ОБЕ стороны (Plane→орк, Gitea→орк, орк→Plane/Gitea API). | AC-2, FR-2/FR-6 |
+| BR-4 | Stateless: каждая инсталляция стартует с чистых томов/БД (Plane, Gitea, орк) и НОВЫХ секретов (`gen_secrets.py` + bundle-внутренние креды). Боевые данные/секреты не используются ни на одном шаге; в репо нет ни одного реального секрета/дефолтного пароля. | AC-3, FR-3 |
+| BR-5 | `docs/deployment/BUNDLED_SETUP.md` написан по канону LITE_SETUP (fenced-команды + «Проверка:» PASS/FAIL, плейсхолдеры вместо хост-специфики, канон не форкается — общие шаги ссылками на LITE_SETUP/ONBOARDING/REPLICATION) и фиксирует требования к хосту: RAM/диск/CPU/занимаемые порты (Plane ~14 контейнеров — ресурсоёмко). | AC-4, FR-4 |
+| BR-6 | Переиспользование кирпичей без дублирования: секреты — `gen_secrets.py`; статусы/лейблы/репо/вебхуки — `onboard_project.py` (22 статуса — из `plane_sync._PLANE_NAME_TO_KEY`, нулевой дрейф); smoke — шаги REPLICATION §4. Bootstrap не реализует собственную копию этих канонов. | FR-2/FR-3, AC-7 |
+| BR-7 | Идемпотентность/fail-safe: повторный запуск bootstrap безопасен (ensure/skip, без delete-операций); запуск на «грязном» хосте (существующие тома/занятые порты/нехватка ресурсов) → явный отказ preflight с понятной подсказкой, а не молчаливое переиспользование чужого состояния. | FR-2, AC-8 |
+| BR-8 | Наш прод не затрагивается: вся задача — вне рантайма и вне конвейера; kill-switch не требуется (активация — только явный запуск человеком на целевом хосте, паттерн ORCH-009). | NFR-1/NFR-2, AC-6 |
+| BR-9 | Анти-дрейф: структурные тесты держат bundle-канон (compose-структура, док-канон, env-ключи, FORBIDDEN-литералы, секрет-эвристика, кросс-ссылки); существующие `test_lite_setup_doc.py`/`test_no_host_hardcodes.py` остаются зелёными; полный `pytest tests/ -q` зелёный; CHANGELOG обновлён. | AC-5, AC-6, AC-7, FR-5 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| NFR-1 | **Рантайм/конвейер байт-в-байт:** `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД орка — не тронуты. Задача — docs+scripts+compose-bundle+tests. |
+| NFR-2 | **Self-hosting безопасность:** ни один артефакт задачи не рестартит/не деплоит/не конфигурирует наш прод-контейнер; bundle-артефакты в нашем контуре инертны (никто их не исполняет). |
+| NFR-3 | **Секрет-гигиена:** в репо не попадают реальные секреты, высокоэнтропийные литералы и хост-литералы (FORBIDDEN-скан `test_no_host_hardcodes.py` распространяется на новые артефакты); bootstrap не печатает секреты в лог; сгенерированные файлы конфигов — только на целевом хосте, в `.gitignore`. |
+| NFR-4 | **Переносимость:** bundle не зависит от нашей инфраструктуры; вся хост-специфика — переменные/плейсхолдеры; целевая платформа — одиночный Linux x86_64 хост с docker+compose. |
+| NFR-5 | **Норматив сопровождения** (зеркало NFR-5 ORCH-102): изменение шагов тиража в будущих задачах → обновление `BUNDLED_SETUP.md` в том же PR. |
+| NFR-6 | **Воспроизводимость:** версии образов Gitea/Plane-стека зафиксированы (пиннинг тегов/digest, не `latest`); состав bundle детерминирован. |
+| NFR-7 | **Без новых тяжёлых зависимостей:** bootstrap — в духе существующих скриптов (stdlib-инструментарий `gen_secrets.py`/`onboard_project.py`); точный стек (bash/python) — решение архитектора. |
+
+---
+
+## 6. Допущения и ограничения
+- Целевой хост: чистый одиночный Linux x86_64 с установленными docker + docker compose;
+  оператор имеет sudo. Прочие ОС — вне целевой платформы (best-effort).
+- Ресурсы: Plane-стек ресурсоёмок; ориентир для проверки — **не менее 4 vCPU / 8 GB RAM /
+  40 GB диска** (финальные минимумы УТОЧНЯЮТСЯ при реализации замером на тестовом
+  развёртывании и фиксируются в BUNDLED_SETUP.md — см. AC-4; цифры выше — гипотеза, не факт).
+- Внешние предусловия заказчика (bundle не поставляет): инсталляция/аутентификация Claude CLI
+  + LLM-доступ Anthropic; Telegram-боты (трекер + watchdog) — опциональны, их отсутствие
+  деградирует только нотификации (never-raise), не конвейер.
+- Часть инициализации Plane CE недоступна по API (instance-setup/workspace/API-токен) —
+  допускаются документированные интерактивные шаги внутри визарда; «одной командой» означает
+  «один запуск bootstrap с явными чекпоинтами», а не «ноль действий человека».
+- Версии upstream-образов (Plane CE/Gitea) фиксируются на момент реализации; их обновление —
+  отдельные будущие задачи (NFR-6).
+
+---
+
+## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
+Пять AC из постановки Владельца (сохранены 1:1 как AC-1…AC-5) + производные проверяемые:
+- AC-1 единый bundle-compose поднимает ВЕСЬ стек; bootstrap доводит до рабочего состояния
+  одной командой/визардом.
+- AC-2 после bootstrap smoke проходит (тестовый проект + задача доезжает).
+- AC-3 stateless (чистые Plane/Gitea/БД, новые секреты).
+- AC-4 BUNDLED_SETUP.md + требования к хосту (RAM/диск) задокументированы.
+- AC-5 pytest зелёный; CHANGELOG.
+- AC-6 корневой compose/рантайм не тронуты (анти-дрейф зелёный); AC-7 нулевой дрейф канонов
+  (22 статуса/лейблы/секреты — через существующие кирпичи); AC-8 идемпотентность/fail-safe
+  bootstrap; AC-9 секрет-гигиена новых артефактов.
+
+---
+
+## 8. Риски (детали — 10-tech-risks.md, заполняет архитектор)
+- **R-1 Ресурсоёмкость Plane:** ~14 контейнеров → OOM/медленный старт на слабом хосте;
+  смягчение — preflight-проверка ресурсов + честные требования в доке (AC-4).
+- **R-2 Дыры Plane CE API:** первичная инициализация частично UI-only → ручные чекпоинты;
+  риск — UX «одной команды» размывается; смягчение — явные manual-step с проверкой результата
+  (паттерн ORCH-009), минимизация числа ручных шагов.
+- **R-3 Дрейф upstream-образов:** «плавающие» теги ломают воспроизводимость → пиннинг (NFR-6).
+- **R-4 Сетевая достижимость вебхуков:** орк (host network) ⟷ Plane/Gitea (bridge-сеть bundle)
+  — двунаправленные URL должны быть согласованы bootstrap'ом; ошибка = «задача не появилась»
+  (труднодиагностируемо); смягчение — smoke проверяет оба направления.
+- **R-5 Соблазн форкнуть корневой compose** (анти-дрейф TC-04 `test_lite_setup_doc.py` упадёт)
+  → bundle строго отдельным файлом.
+- **R-6 Утечка секретов в логи/репо** при генерации bundle-кред → секрет-эвристика в тестах,
+  запрет печати секретов (NFR-3).

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

@@ -0,0 +1,232 @@
+---
+work_item: ORCH-103
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ фиксирует **что** должно измениться и **где** (артефакты/контракты/границы). **Как**
+> (расположение bundle-каталога, состав сервисов Plane-стека, язык/режимы bootstrap, механизм
+> сетевой связности) — решает архитектор в `06-adr/`. Архитектурные решения здесь не принимаются.
+
+---
+
+## 1. Сводка изменения
+
+Добавить в репо **Bundled-комплект тиража (Type B эпика ORCH-10)**: (1) отдельный
+**bundle-compose** всего стека (орк + watchdog + Gitea + Plane-стек ~14 контейнеров),
+(2) **bootstrap-скрипт**, доводящий свежеподнятый стек до рабочего конвейера одним запуском
+(с явными manual-step чекпоинтами там, где Plane CE API не позволяет автоматизацию),
+(3) **генерацию новых секретов** на инсталляцию (reuse `gen_secrets.py` + bundle-внутренние
+креды), (4) инструкцию **`docs/deployment/BUNDLED_SETUP.md`** с требованиями к хосту,
+(5) **структурные анти-дрейф тесты**. Всё — вне рантайма и вне конвейера: `src/**`, корневой
+`docker-compose.yml`, `Dockerfile`, `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — байт-в-байт
+(паттерн ORCH-009/ORCH-102). Kill-switch не требуется: активация — только явный запуск
+оператором на целевом хосте.
+
+---
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие | Назначение |
+|------|----------|------------|
+| `deploy/bundled/docker-compose.yml` *(рабочая гипотеза; финальное расположение/имя — ADR; далее «bundle-compose»)* | **создать** | Compose-комплект всего стека (FR-1) |
+| `deploy/bundled/.env.bundled.example` *(имя — ADR; далее «bundle-конфиг-канон»)* | **создать** | Канон 100% переменных bundle (порты/версии/плейсхолдеры кред), паттерн `.env.watchdog.example` |
+| `scripts/bootstrap_bundle.py` *(имя/язык — ADR)* | **создать** | Bootstrap-скрипт (FR-2) |
+| `docs/deployment/BUNDLED_SETUP.md` | **создать** | Golden source инструкции Bundled-тиража (FR-4) |
+| `docs/operations/REPLICATION.md` | **изменить (точечно)** | §1: строка Type B → ✅ ORCH-103 + ссылка на BUNDLED_SETUP.md (FR-6) |
+| `tests/test_bundle_compose.py` | **создать** | Структура bundle-compose + изоляция корневого compose (FR-5) |
+| `tests/test_bundled_setup_doc.py` | **создать** | Канон дока, env-ключи, FORBIDDEN/секрет-эвристика, кросс-рефы (FR-5) |
+| `tests/test_bootstrap_script.py` | **создать** | Структурные/unit-ассерты bootstrap (FR-5) |
+| `CHANGELOG.md` | **изменить** | Запись `feat: ORCH-103` |
+| `.gitignore` | **изменить (при необходимости)** | Сгенерированные на хосте конфиги bundle не коммитятся (NFR-3) |
+| **НЕ трогать:** `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**`, `.env.example` (кроме явно обоснованного в ADR аддитива), `onboarding/**`, промпты `.openclaw/agents/**` | — | NFR-1; анти-дрейф `test_lite_setup_doc.py` (TC-04: ровно 3 сервиса, нет `plane*`/`gitea*`) и `test_no_host_hardcodes.py` остаются зелёными |
+
+---
+
+## 3. Функциональные требования
+
+### FR-1 — Bundle-compose всего стека (BR-1)
+- **Отдельный файл**, корневой `docker-compose.yml` не изменяется (жёсткое ограничение:
+  анти-дрейф TC-04 `tests/test_lite_setup_doc.py` проверяет точное множество сервисов корневого
+  compose и запрещает подстроки `plane`/`gitea` в именах сервисов/образов/контейнеров).
+- **Состав стека:** `orchestrator` (образ собирается из существующего корневого `Dockerfile` —
+  без его правки), `orchestrator-watchdog` (существующий `watchdog/Dockerfile`), Gitea
+  (+ её хранилище), полный Plane CE-стек (~14 контейнеров: web/admin/space/api/worker/beat/
+  live/migrator + postgres/redis/mq/minio/proxy — точный состав и версии пиннит архитектор по
+  upstream-référence). Staging-контур орка (8501) — НЕ в дефолтном `up` (вне скоупа заказчика;
+  включать ли за профилем — ADR).
+- **Пиннинг версий** всех сторонних образов (тег или digest; не `latest`) — NFR-6.
+- **Тома:** только именованные/каталожные тома bundle (узнаваемый префикс); чистый первый старт;
+  пересечений с томами/путями нашего прод-контура нет.
+- **Сеть и достижимость (двунаправленно):** (a) Plane→орк и Gitea→орк webhooks доставляются;
+  (b) орк→Plane API и орк→Gitea API доступны; (c) git push/fetch агентов в Gitea работает.
+  Механизм (bridge-сеть + публикация портов, `extra_hosts: host-gateway`, host-network — что
+  выбрать) — ADR; ТЗ фиксирует только инвариант достижимости, проверяемый smoke (FR-6).
+- **Порты:** карта портов по умолчанию задокументирована (BUNDLED_SETUP «Требования к хосту»);
+  порты конфигурируемы через bundle-конфиг; конфликт порта → отказ preflight bootstrap (FR-2),
+  не молчаливый сбой. Дефолт порта орка — существующий 8500 (`ORCH_DEPLOY_PROD_TARGET_PORT`).
+- **Конфиг-канон:** все параметры bundle (порты/версии/пути/плейсхолдеры кред) — в
+  bundle-конфиг-каноне; key-set синхронизируется структурным тестом (паттерн key-sync
+  `.env.watchdog.example`, D5 ORCH-102). Ключи орка НЕ дублируются — `.env` орка собирается
+  bootstrap'ом из существующего канона `.env.example`.
+
+### FR-2 — Bootstrap-скрипт: один запуск до рабочего состояния (BR-2, BR-6, BR-7)
+Последовательность (нумерация — норматив поведения; механика шагов — ADR):
+1. **Preflight (fail-fast, до любых мутаций):** docker+compose присутствуют; свободные
+   RAM/диск ≥ задокументированных минимумов; целевые порты свободны; тома bundle отсутствуют
+   (чистый хост) — иначе явный отказ с подсказкой (BR-7); наличие Claude CLI/кред — warning
+   (не блокер: конвейер без LLM не поедет, но стек поднимется).
+2. **Секреты (FR-3):** генерация полного набора НОВЫХ секретов инсталляции.
+3. **Up:** подъём bundle-compose; ожидание готовности каждого сервиса (healthcheck/готовность
+   БД/завершение миграций Plane и Gitea) с таймаутами и внятной диагностикой.
+4. **Init Gitea:** административная учётка + API-токен (через официальные механизмы Gitea —
+   CLI/env/API; конкретика — ADR); branch protection НЕ настраивается (норматив D10 ORCH-009).
+5. **Init Plane:** instance-setup/workspace/API-токен. Всё, что недоступно в CE по API, —
+   **интерактивный manual-step чекпоинт**: скрипт печатает точную инструкцию (URL/что нажать/
+   что ввести), ждёт подтверждения, **проверяет результат** (например, валидность введённого
+   API-токена запросом) и только тогда продолжает (fail-safe; молчаливый пропуск запрещён).
+6. **Онбординг sandbox-проекта:** вызов `scripts/onboard_project.py apply` + `verify`
+   (22 статуса из `plane_sync._PLANE_NAME_TO_KEY`, лейблы `autoApprove`/`autoDeploy`/`Bug`,
+   Gitea-репо, per-repo webhook под глобальным секретом). Собственная реализация этих шагов
+   в bootstrap **запрещена** (BR-6, нулевой дрейф канона).
+7. **Git-доступ агентов:** обеспечить push/fetch созданного репо из контейнера орка
+   (ssh-ключ + регистрация в Gitea ИЛИ токен-remote — механизм ADR); клон репо в repos-каталог
+   орка (`ORCH_HOST_REPOS_DIR`).
+8. **Конфиг орка:** собрать `.env` (на базе `.env.example`: URL'ы Plane/Gitea bundle-инсталляции,
+   токены, webhook-секреты, `ORCH_PROJECTS_JSON` из вывода onboard) и `.env.watchdog`
+   (из `.env.watchdog.example`); файлы остаются только на целевом хосте.
+9. **Health + итог:** `GET /health`, `GET /queue`, `GET /metrics` зелёные; финальная сводка
+   PASS/FAIL по всем шагам + следующая команда оператора (smoke FR-6).
+
+Требования к скрипту:
+- **Идемпотентность:** повторный запуск на уже-инициализированном bundle безопасен
+  (ensure/skip-семантика, как `onboard_project.py apply`); никаких delete-операций.
+- **Exit-коды:** `0` — успех; `2` — остановка на manual-step/незавершённое предусловие;
+  `1` — ошибка (паттерн `onboard_project.py`).
+- **Логи без секретов** (NFR-3): значения кред не печатаются (только имена ключей/пути файлов).
+- **Никогда не адресует наш прод:** в скрипте нет боевых хостов/путей (FORBIDDEN-скан),
+  работает только с локальным docker целевого хоста.
+- Желателен режим `plan` (печать шагов без мутаций, паттерн ORCH-009) — финально ADR.
+
+### FR-3 — Инициализация секретов: новые на каждую инсталляцию (BR-4)
+- **Webhook-секреты орка** — строго через существующий `scripts/gen_secrets.py`
+  (не реализовывать заново).
+- **Bundle-внутренние креды** (генерирует bootstrap, криптослучайно, stdlib `secrets`):
+  пароли postgres/redis*/mq/minio Plane-стека, секрет-ключи Plane, админ-пароль и API-токен
+  Gitea. В репо — только плейсхолдеры в bundle-конфиг-каноне; **ни одного дефолтного пароля**.
+- **Внешние секреты заказчика** (не генерятся, чек-лист в доке): Anthropic/Claude CLI доступ,
+  Telegram-токены (опционально), `ORCH_PLANE_API_TOKEN` (если выдаётся вручную на manual-step).
+- Сгенерированные файлы: только на целевом хосте, права `600`, в `.gitignore`; повторный
+  запуск НЕ перетирает существующие секреты без явного флага (паттерн `--force` gen_secrets).
+
+### FR-4 — `docs/deployment/BUNDLED_SETUP.md` (BR-5)
+- **Канон LITE_SETUP** (ORCH-102): нормативные разделы в порядке маршрута оператора; каждый
+  исполняемый шаг = fenced-команда + явная «Проверка:» с PASS/FAIL; хост-специфика — только
+  плейсхолдеры; запрещены FORBIDDEN-литералы и реальные секреты (структурный тест).
+- **Обязательные разделы** (минимум; точные заголовки — автор дока, проверяемость — тест):
+  (1) рамка Bundled (что входит/что НЕ входит: Claude CLI, Telegram, HTTPS; границы vs Lite);
+  (2) **требования к хосту** — RAM/диск/CPU/порты, явно «Plane ≈ 14 контейнеров», финальные
+  цифры — по замеру на тестовом развёртывании; (3) предусловия (docker/compose/sudo);
+  (4) получение кода; (5) секреты; (6) запуск bundle-compose; (7) bootstrap (включая перечень
+  manual-step чекпоинтов Plane); (8) LLM/Claude CLI (ссылкой на канон LITE_SETUP §7);
+  (9) Telegram (ссылкой на LITE_SETUP §8); (10) онбординг следующих проектов
+  (ссылкой на ONBOARDING.md); (11) smoke (шаги REPLICATION §4); (12) stateless-проверка;
+  (13) остановка/полный сброс инсталляции; (14) траблшутинг (минимум: webhook не доходит,
+  не хватает RAM/OOM, порт занят, claude не найден, Plane-миграции не завершились).
+- **Канон не форкается:** общие с Lite шаги — ссылками (LITE_SETUP §5–§8, ONBOARDING §1,
+  REPLICATION §2–§4), не копипастой; fail-closed имена `Confirm Deploy`/`STOP` и «22 статуса» —
+  согласованы с `plane_sync._PLANE_NAME_TO_KEY` (число — сверкой импорта в тесте, не литералом).
+
+### FR-5 — Структурные анти-дрейф тесты (BR-9)
+Все тесты — без docker/сети/LLM/subprocess-мутаций (CI-безопасные; паттерн
+`test_lite_setup_doc.py`):
+- **bundle-compose:** файл существует, валидный YAML; обязательные сервисы присутствуют
+  (`orchestrator`, `orchestrator-watchdog`, Gitea, Plane-стек — по списку из ADR); все
+  сторонние образы пиннованы (нет `:latest`/безтегового образа); корневой
+  `docker-compose.yml` НЕ изменён (множество сервисов == текущему эталону);
+- **док:** BUNDLED_SETUP.md существует, несёт обязательные разделы (включая «Требования к
+  хосту»), каждый env-ключ из дока существует в канонах (`.env.example` ∪ bundle-конфиг-канон),
+  кросс-ссылки на LITE_SETUP/ONBOARDING/REPLICATION присутствуют;
+- **гигиена:** FORBIDDEN-литералы (импорт списка из `test_no_host_hardcodes.py`) отсутствуют
+  в bundle-compose/доке/bootstrap; секрет-эвристика (hex ≥32 / alnum ≥40, паттерн D8 ORCH-102)
+  по новым файлам;
+- **bootstrap:** скрипт существует; структурно ссылается на `gen_secrets`/`onboard_project`
+  (не дублирует канон); не содержит delete-операций уровня `docker volume rm`/`rm -rf` вне
+  явного отдельного «сброс»-режима; чистые функции (preflight-решение, сборка плана шагов,
+  рендер `.env`) покрыты unit-тестами;
+- **кросс-рефы:** REPLICATION.md §1 несёт отметку Type B → BUNDLED_SETUP.md; CHANGELOG
+  содержит `ORCH-103`.
+
+### FR-6 — Smoke и наблюдаемость результата (BR-3)
+- Smoke Bundled = шаги REPLICATION §4 (0–6) поверх bundle-инсталляции, зафиксированные в
+  BUNDLED_SETUP §smoke: config-резолв → `/health` → `/queue`+`/metrics` → onboard verify →
+  тестовая задача (Plane issue → «To Analyse» → job в очереди) → **минимальный сигнал:
+  артефакты `01–04` в ветке** → опционально полный цикл до `done`.
+- Прохождение фиксируется оператором по PASS/FAIL каждого шага; это ручная приёмка AC-2
+  (e2e в CI не гоняется — нет docker/LLM).
+
+---
+
+## 4. Изменения API
+**Нет.** Эндпоинты орка не добавляются/не меняются; bundle использует существующие
+`/health`, `/queue`, `/metrics`, вебхуки `/webhook/plane`, `/webhook/gitea`.
+
+## 5. Изменения схемы БД
+**Нет** (схема БД орка не тронута). БД Plane/Gitea внутри bundle — их собственные, на чистых
+томах инсталляции; к схеме орка отношения не имеют.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Реестр `QG_CHECKS`/`check_*`/`STAGE_TRANSITIONS` — байт-в-байт. Bundled-тираж — это
+артефакты дистрибуции, а не гейты конвейера.
+
+---
+
+## 7. Совместимость / регресс
+- **Kill-switch не требуется** (паттерн ORCH-009): артефакты вне рантайма; в нашем контуре
+  ничего их не исполняет; активация — явный запуск оператором на целевом хосте.
+- **Нулевая регрессия:** корневой compose/`Dockerfile`/`src/**` не изменены ⇒ наш прод,
+  staging-контур и enduro-trails не затронуты по построению; существующие анти-дрейф тесты
+  (`test_lite_setup_doc.py`, `test_no_host_hardcodes.py`, канон-тесты ORCH-009) остаются
+  зелёными без правки их ассертов.
+- **Обратимость:** удаление bundle-каталога/скрипта/дока возвращает репо в текущее состояние;
+  на целевом хосте полный сброс = задокументированная процедура (FR-4 §13).
+- **Эскалация:** если при реализации выяснится необходимость править `src/**`/корневой compose
+  (например, недостающая параметризация, не закрытая ORCH-101) — это выход за рамки ТЗ:
+  остановиться и вернуть задачу с обоснованием (CLAUDE.md правило 4), не «дотачивать молча».
+
+---
+
+## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
+- `docs/work-items/ORCH-103/06-adr/ADR-001-<slug>.md` — решения архитектора (см. §9 OQ);
+  при сквозном значении — зеркало в `docs/architecture/adr/adr-NNNN-<slug>.md`.
+- `docs/architecture/README.md` — раздел «Bundled-тираж (ORCH-103)» рядом с 10-common/Lite.
+- `CLAUDE.md` — краткий абзац Type B (паттерн абзацев ORCH-101/102).
+- `docs/operations/REPLICATION.md` §1 — отметка Type B (FR-6).
+- `CHANGELOG.md` — `feat: ORCH-103 …`.
+- При выявлении инфра-предусловий целевого хоста — `07-infra-requirements.md` (архитектор).
+
+---
+
+## 9. Открытые вопросы для архитектора (не блокируют анализ)
+- **OQ-1** Расположение/имя bundle-каталога и compose-файла (`deploy/bundled/` vs `bundle/`;
+  один compose vs include-композиция); судьба staging-контура орка в bundle (исключить vs
+  профиль).
+- **OQ-2** Точный состав/версии Plane CE-стека (по upstream selfhost-référence) и Gitea;
+  стратегия пиннинга (тег vs digest).
+- **OQ-3** Перечень физически автоматизируемых шагов инициализации Plane CE (instance-setup/
+  workspace/API-токен): что через API/CLI/seed, что — manual-step чекпоинт.
+- **OQ-4** Язык и режимы bootstrap (python stdlib vs bash; `plan`/`apply` vs линейный визард);
+  способ ожидания готовности (healthchecks vs poll).
+- **OQ-5** Механизм сетевой связности орк (host network?) ⟷ bundle bridge-сеть: публикация
+  портов, `host-gateway`, либо весь bundle в host-network — и согласование URL вебхуков.
+- **OQ-6** Механизм git-доступа агентов к bundle-Gitea (ssh-ключ vs http-токен) и наполнение
+  repos-каталога.
+- **OQ-7** Делать ли отдельный явный «сброс»-режим (teardown) частью скрипта или только
+  документированной процедурой в BUNDLED_SETUP §13.

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

@@ -0,0 +1,164 @@
+---
+work_item: ORCH-103
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). AC-1…AC-5 — из постановки Владельца (сохранены 1:1 по смыслу);
+AC-6…AC-9 — производные обязательные. AC-1/AC-2/AC-3 в части e2e — **ручная приёмка** на
+чистом тестовом хосте/VM по BUNDLED_SETUP.md (в CI docker/LLM не гоняются); остальное
+проверяется по файлам репозитория и структурным тестам.
+
+---
+
+## AC-1 — Единый bundle поднимает ВЕСЬ стек; bootstrap доводит одной командой/визардом
+
+**Условие:** на чистом Linux-хосте с docker+compose по шагам BUNDLED_SETUP.md: одна команда
+`docker compose -f <bundle-compose> … up -d` поднимает все сервисы стека (орк + watchdog +
+Gitea + Plane-стек); затем ОДИН запуск bootstrap-скрипта доводит инсталляцию до рабочего
+состояния (init Gitea/Plane → онбординг sandbox-проекта → git-доступ агентов → конфиг орка →
+health). Интерактивные manual-step чекпоинты допустимы только там, где Plane CE API не
+позволяет автоматизацию, каждый — с инструкцией и проверкой результата.
+- **PASS:** все контейнеры bundle в состоянии Up/healthy; bootstrap завершается `exit 0`;
+  `GET /health` орка — 200/ok, `GET /queue` и `GET /metrics` отдают валидный JSON;
+  `onboard_project.py verify` зелёный (22 статуса, лейблы, репо, webhook); ни одного
+  НЕдокументированного ручного действия (правка compose/конфигов руками сверх инструкции).
+- **FAIL:** хотя бы один сервис не поднялся/в рестарт-цикле; bootstrap падает или завершается
+  с нерабочим конвейером; для доводки потребовались действия, отсутствующие в BUNDLED_SETUP.md;
+  manual-step пропускается молча без проверки результата.
+
+---
+
+## AC-2 — После bootstrap smoke проходит (тестовый проект + задача доезжает)
+
+**Условие:** smoke-процедура BUNDLED_SETUP §smoke (шаги REPLICATION.md §4 поверх
+bundle-инсталляции): создать issue в sandbox-проекте Plane → перевести в «To Analyse».
+- **PASS:** webhook доезжает (job появляется в `GET /queue`); конвейер запускает analyst;
+  в рабочей ветке Gitea появляются артефакты `01-brd.md`/`02-trz.md`/`03-acceptance-criteria.md`/
+  `04-test-plan.yaml` (минимальный сигнал — шаг 5 REPLICATION §4); обратное направление
+  работает (орк пишет статус/коммент в Plane). Опционально-расширенно: задача доводится до
+  `done` (шаг 6).
+- **FAIL:** webhook не доходит (нет job); analyst не стартует; артефакты `01–04` не появляются;
+  орк не может писать в Plane/Gitea API (одностороння связность — R-4).
+
+---
+
+## AC-3 — Stateless: чистые Plane/Gitea/БД, новые секреты
+
+**Условие:** инсталляция стартует с нуля и не содержит ничего нашего.
+- **PASS:** все тома bundle созданы заново при первом `up` (чистые БД Plane/Gitea/орка:
+  `GET /queue` — нулевые счётчики, в Plane/Gitea нет наших задач/репо/пользователей); ВСЕ
+  секреты инсталляции сгенерированы на месте (`gen_secrets.py` + bundle-креды bootstrap);
+  в репо нет ни одного реального секрета/дефолтного пароля (структурный тест: секрет-эвристика
+  + плейсхолдеры в bundle-конфиг-каноне); боевые данные/секреты/БД не копируются ни одним шагом
+  инструкции.
+- **FAIL:** инструкция/скрипт предлагает перенос наших данных или переиспользование боевых
+  секретов; в репо обнаружен реальный секрет/дефолтный пароль/высокоэнтропийный литерал;
+  на свежей инсталляции видны чужие задачи/счётчики.
+
+---
+
+## AC-4 — BUNDLED_SETUP.md + требования к хосту задокументированы
+
+**Условие:** `docs/deployment/BUNDLED_SETUP.md` существует и написан по канону тиражных доков
+(ORCH-102).
+- **PASS:** док несёт обязательные разделы FR-4 (рамка, **требования к хосту с явными цифрами
+  RAM/диск/CPU и картой портов**, предусловия, секреты, запуск, bootstrap с перечнем
+  manual-step, LLM, Telegram, онбординг, smoke, stateless-проверка, остановка/сброс,
+  траблшутинг); каждый исполняемый шаг = fenced-команда + «Проверка:» PASS/FAIL; явно указано
+  «Plane ≈ 14 контейнеров — ресурсоёмко»; цифры требований подтверждены замером на тестовом
+  развёртывании (не «с потолка»); хост-специфика — только плейсхолдеры; общие шаги — ссылками
+  на LITE_SETUP/ONBOARDING/REPLICATION (без копипасты канона).
+- **FAIL:** дока нет/раздел «Требования к хосту» отсутствует или без цифр; шаги без
+  команд/проверок; FORBIDDEN-литералы (IP/`/home/slin`/`mva154`/`duckdns`) или секреты в
+  тексте/fenced-блоках; канон LITE_SETUP скопирован вместо ссылок.
+
+---
+
+## AC-5 — pytest зелёный; CHANGELOG
+
+**Условие:** полный регресс и журнал изменений.
+- **PASS:** `pytest tests/ -q` — 0 failed (включая существующие анти-дрейф
+  `test_lite_setup_doc.py`, `test_no_host_hardcodes.py`, канон-тесты ORCH-009 — без правки их
+  ассертов); `CHANGELOG.md` содержит запись `ORCH-103`.
+- **FAIL:** хотя бы один тест красный; существующий анти-дрейф тест «починен» ослаблением
+  ассертов; CHANGELOG не обновлён.
+
+---
+
+## AC-6 — Корневой compose и рантайм не тронуты
+
+**Условие:** изоляция от боевого контура (NFR-1/NFR-2, BR-1/BR-8).
+- **PASS:** `git diff main` НЕ содержит изменений `src/**`, корневого `docker-compose.yml`,
+  `Dockerfile`, `.gitea/workflows/**`; bundle-compose — отдельный файл; множество сервисов
+  корневого compose неизменно (`orchestrator`/`orchestrator-watchdog`/`orchestrator-staging`);
+  ни один артефакт задачи не исполняется в нашем контуре автоматически (нет правок
+  деплой-хука/CI, нет cron/врезок).
+- **FAIL:** любая правка рантайма/корневого compose/Dockerfile; сервисы `plane*`/`gitea*`
+  добавлены в корневой compose; артефакт bundle задействован в нашем прод/staging-контуре.
+
+---
+
+## AC-7 — Нулевой дрейф канонов: кирпичи переиспользованы
+
+**Условие:** BR-6 — единственный источник истины для статусов/лейблов/секретов/smoke.
+- **PASS:** bootstrap вызывает `scripts/gen_secrets.py` (webhook-секреты) и
+  `scripts/onboard_project.py` (статусы/лейблы/репо/вебхуки) — структурный тест подтверждает
+  ссылки; собственного списка статусов/лейблов в bundle-артефактах нет (упоминание числа
+  статусов в доке сверяется импортом `plane_sync._PLANE_NAME_TO_KEY` в тесте, не литералом);
+  smoke-раздел ссылается на REPLICATION §4.
+- **FAIL:** bootstrap/док несут собственную копию канона (свой список статусов, свой генератор
+  webhook-секретов, свой smoke-чеклист с нуля) — дрейф при будущих изменениях канона.
+
+---
+
+## AC-8 — Идемпотентность и fail-safe bootstrap
+
+**Условие:** BR-7 — повторный запуск и грязный хост.
+- **PASS:** повторный запуск bootstrap на уже-инициализированном bundle завершается успешно
+  (ensure/skip, без дублей и без разрушения состояния); preflight на грязном/непригодном хосте
+  (существующие тома bundle, занятый порт, нехватка RAM/диска) → явный отказ с понятной
+  подсказкой ДО любых мутаций; delete-операций нет (teardown — только отдельный
+  явный режим/процедура, не часть обычного прогона); exit-коды: 0 — успех, 2 — manual-step/
+  предусловие, 1 — ошибка; секреты в логи не печатаются; повторный запуск не перетирает
+  существующие секреты без явного флага.
+- **FAIL:** повторный запуск ломает/дублирует состояние; bootstrap молча переиспользует чужие
+  тома или продолжает после провального preflight; обычный прогон удаляет данные; секрет виден
+  в stdout/логе.
+
+---
+
+## AC-9 — Секрет-гигиена и переносимость новых артефактов
+
+**Условие:** NFR-3/NFR-4/NFR-6 по файлам репо.
+- **PASS:** структурные тесты подтверждают: в bundle-compose/доке/скрипте нет
+  FORBIDDEN-литералов (список — импорт из `test_no_host_hardcodes.py`) и высокоэнтропийных
+  литералов (hex ≥32 / alnum ≥40); все сторонние образы bundle-compose пиннованы (не `latest`);
+  все env-ключи, упомянутые в BUNDLED_SETUP.md, существуют в канонах (`.env.example` ∪
+  bundle-конфиг-канон); сгенерированные на хосте конфиги — в `.gitignore`.
+- **FAIL:** найден хост-литерал/секрет; образ без пина; ключ-фантом в доке (нет в канонах);
+  сгенерированный конфиг коммитится.
+
+---
+
+## Сводная матрица AC ↔ BR/FR
+
+| AC | Покрывает | Способ проверки |
+|----|-----------|-----------------|
+| AC-1 | BR-1, BR-2 / FR-1, FR-2 | ручной e2e на тестовом хосте + структурные тесты (TC-01..04, TC-08) |
+| AC-2 | BR-3 / FR-2, FR-6 | ручной e2e (smoke REPLICATION §4) |
+| AC-3 | BR-4 / FR-3 | ручной e2e + структурные тесты (TC-06, TC-09) |
+| AC-4 | BR-5 / FR-4 | структурный тест дока (TC-05) + ревью |
+| AC-5 | BR-9 / FR-5, FR-6 | `pytest tests/ -q` (TC-12) + CHANGELOG (TC-11) |
+| AC-6 | BR-1, BR-8 / NFR-1, NFR-2 | git diff + существующий анти-дрейф (TC-02) |
+| AC-7 | BR-6 / FR-2, FR-3 | структурный тест bootstrap/дока (TC-07, TC-10) |
+| AC-8 | BR-7 / FR-2 | unit-тесты чистых функций preflight/плана (TC-08) + ручной повторный прогон |
+| AC-9 | NFR-3, NFR-4, NFR-6 / FR-1, FR-4 | структурные тесты гигиены (TC-03, TC-06, TC-09) |

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

@@ -0,0 +1,102 @@
+work_item: ORCH-103
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+title: "Bundled-тираж: bundle-compose + bootstrap + BUNDLED_SETUP.md (структурные анти-дрейф тесты)"
+framework: pytest
+scope: >
+  Автоматическое покрытие — СТРУКТУРНЫЕ инварианты артефактов Bundled-тиража
+  (bundle-compose, bootstrap-скрипт, docs/deployment/BUNDLED_SETUP.md) без docker/сети/LLM
+  в CI (паттерн tests/test_lite_setup_doc.py). Вне автоматического покрытия — фактический
+  e2e-подъём стека: он принимается ВРУЧНУЮ по чек-листу BUNDLED_SETUP §smoke
+  (шаги REPLICATION.md §4) на чистом тестовом хосте/VM — см. notes (AC-1/AC-2/AC-3/AC-8).
+notes: >
+  Ручная приёмка (вне CI): чистый Linux-хост/VM -> docker compose -f <bundle> up -d ->
+  один запуск bootstrap (manual-step чекпоинты Plane CE допустимы и проверяются) ->
+  health/queue/metrics зелёные -> onboard verify -> тестовая задача доезжает до артефактов
+  01-04 (минимальный сигнал), опционально до done; повторный запуск bootstrap безопасен;
+  тома чистые, секреты новые. Имена модулей tests/test_bundle_compose.py /
+  tests/test_bundled_setup_doc.py / tests/test_bootstrap_script.py — норматив тест-плана;
+  имена bundle-каталога/скрипта внутри ассертов следуют ADR-001 архитектора.
+  Полный регресс tests/ обязан остаться зелёным БЕЗ ослабления ассертов существующих
+  анти-дрейф тестов (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон ORCH-009).
+
+tests:
+  # ---------- FR-1 / AC-1: bundle-compose ----------
+  - id: TC-01
+    type: unit
+    description: "Bundle-compose существует и валидно парсится (yaml.safe_load); содержит обязательные сервисы: orchestrator, orchestrator-watchdog, Gitea и Plane-стек (имена — по ADR-001); staging-контур орка не входит в дефолтный up"
+    module: tests/test_bundle_compose.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Корневой docker-compose.yml НЕ изменён: множество сервисов == {orchestrator, orchestrator-watchdog, orchestrator-staging}; в его сервисах/образах/container_name нет подстрок plane/gitea (зеркало TC-04 test_lite_setup_doc.py — существующий анти-дрейф остаётся зелёным)"
+    module: tests/test_bundle_compose.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Все сторонние образы bundle-compose пиннованы: ни одного image с тегом latest или без тега/digest (NFR-6, воспроизводимость)"
+    module: tests/test_bundle_compose.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Изоляция и конфиг-канон bundle: тома — именованные с узнаваемым bundle-префиксом, без bind-путей нашего прод-контура; bundle-конфиг-канон (example-файл) существует, и каждая ${VAR}-интерполяция bundle-compose имеет ключ в каноне (key-set-sync, паттерн .env.watchdog.example)"
+    module: tests/test_bundle_compose.py
+    expected: PASS
+
+  # ---------- FR-4 / AC-4: BUNDLED_SETUP.md ----------
+  - id: TC-05
+    type: unit
+    description: "docs/deployment/BUNDLED_SETUP.md существует и несёт обязательные разделы FR-4 (включая 'Требования к хосту' с цифрами RAM/диск/CPU, картой портов и упоминанием ~14 контейнеров Plane; bootstrap; smoke; stateless-проверка; остановка/сброс; траблшутинг); исполняемые шаги оформлены fenced-блоками с явной 'Проверка:'"
+    module: tests/test_bundled_setup_doc.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Гигиена новых артефактов (док + bundle-compose + bootstrap): нет FORBIDDEN-литералов (список — импорт из tests/test_no_host_hardcodes.py) и нет высокоэнтропийных секрет-литералов (hex >=32 / alnum >=40, эвристика D8 ORCH-102)"
+    module: tests/test_bundled_setup_doc.py
+    expected: PASS
+
+  # ---------- FR-2/FR-3 / AC-7: bootstrap переиспользует кирпичи ----------
+  - id: TC-07
+    type: unit
+    description: "Bootstrap-скрипт существует и структурно переиспользует канон: ссылается на scripts/gen_secrets.py и scripts/onboard_project.py; НЕ несёт собственного списка Plane-статусов/лейблов; в обычном прогоне нет delete-операций (docker volume rm / rm -rf допустимы только в отдельном явном reset-режиме, если введён ADR)"
+    module: tests/test_bootstrap_script.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Чистые функции bootstrap (preflight/план шагов): грязное состояние (существующие bundle-тома, занятый порт, нехватка RAM/диска) -> отказ с диагностикой ДО мутаций; чистое -> план полного прогона; контракт exit-кодов 0/2/1 (успех / manual-step-остановка / ошибка)"
+    module: tests/test_bootstrap_script.py
+    expected: PASS
+
+  # ---------- FR-4/FR-5 / AC-9: env-канон и нулевой дрейф ----------
+  - id: TC-09
+    type: unit
+    description: "Каждый env-ключ ORCH_*/WATCHDOG_*, упомянутый в BUNDLED_SETUP.md, существует в .env.example либо в bundle-конфиг-каноне (нет ключей-фантомов); упоминание ЧИСЛА статусов Plane сверяется импортом len(plane_sync._PLANE_NAME_TO_KEY), а не зашитым литералом"
+    module: tests/test_bundled_setup_doc.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "Кросс-ссылки канона: BUNDLED_SETUP.md ссылается на LITE_SETUP.md, ONBOARDING.md и REPLICATION.md (канон не форкается); docs/operations/REPLICATION.md §1 несёт отметку Type B -> BUNDLED_SETUP.md / ORCH-103"
+    module: tests/test_bundled_setup_doc.py
+    expected: PASS
+
+  # ---------- AC-5: журнал и полный регресс ----------
+  - id: TC-11
+    type: unit
+    description: "CHANGELOG.md содержит запись ORCH-103"
+    module: tests/test_bundled_setup_doc.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: "Полный регресс pytest tests/ -q зелёный: новые тесты добавлены, существующие анти-дрейф (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон-тесты ORCH-009) проходят БЕЗ изменения их ассертов"
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md

@@ -0,0 +1,362 @@
+---
+work_item: ORCH-103
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Bundled-тираж (Type B) — bundle-compose всего стека + bootstrap-канон
+
+Work Item: **ORCH-103** — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0038-bundled-replication-canon.md`**
+(закрывает Type B эпика ORCH-10; вводит новый top-level каталог `deploy/` и нормативы,
+обязательные для будущих задач тиража).
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **B — Bundled**: заказчик без собственной инфраструктуры
+получает **весь стек одним комплектом** (орк + watchdog + Gitea + Plane CE) + bootstrap,
+доводящий стек до рабочего конвейера одним запуском. Факты, сверенные с репо:
+
+- **Корневой `docker-compose.yml` заморожен анти-дрейфом** (`tests/test_lite_setup_doc.py::
+  test_compose_services_are_exactly_the_lite_set` + `test_compose_has_no_plane_or_gitea_services`):
+  ровно 3 сервиса, подстроки `plane`/`gitea` запрещены → bundle обязан быть **отдельным файлом**.
+- **Кирпичи уже в `main`:** `scripts/gen_secrets.py` (webhook-секреты, `--write PATH`, exit 0/2),
+  `scripts/onboard_project.py` (`plan`/`apply`/`verify`, 22 статуса из
+  `plane_sync._PLANE_NAME_TO_KEY`, шаг `plane.workspace-webhook` — уже **MANUAL** в его отчёте,
+  token-push `_push_url`, exit 0/2/1; запуск — host-venv, `docs/operations/ONBOARDING.md`),
+  smoke `docs/operations/REPLICATION.md` §4, док-канон `docs/deployment/LITE_SETUP.md` (ORCH-102).
+- **Хост-параметризация закрыта ORCH-101** (adr-0036): `src/**` без хост-литералов
+  (`tests/test_no_host_hardcodes.py`, FORBIDDEN = `82.22.50.71`/`/home/slin`/`mva154`/`duckdns`);
+  internal/public split URL уже в конфиге (`ORCH_GITEA_URL`≠`ORCH_GITEA_PUBLIC_URL`,
+  `ORCH_PLANE_API_URL`≠`ORCH_PLANE_WEB_URL`).
+- **`.gitignore` уже неякорный** для `.env`, `data/`, `.env.watchdog` — вложенные копии этих имён
+  игнорируются на любом уровне без правок.
+- **Claude CLI не запекается** в образ (маунты `ORCH_HOST_CLAUDE_*`) — внешнее предусловие хоста
+  заказчика; bundle его не поставляет (решение Владельца, BRD §1.3).
+
+ТЗ (02-trz.md §9) оставило архитектору OQ-1…OQ-7. Ниже — пакет решений D1…D11.
+
+## Решение
+
+### Сводка
+
+Bundled-комплект живёт в новом top-level каталоге **`deploy/bundled/`**: самодостаточный
+compose-файл всего стека (зеркало официального Plane CE selfhost-référence + Gitea + орк +
+watchdog, пиннинг неподвижными тегами) на **одной bridge-сети** с сервис-DNS для машинного
+трафика и публикацией только «человеческих» портов. **`scripts/bootstrap_bundle.py`**
+(python stdlib, режимы `plan`/`apply`/`verify`, step-движок check→ensure, exit 0/2/1) доводит
+стек: preflight → секреты → up → init Gitea (полностью автоматом) → init Plane (честные
+manual-step с верификацией) → онбординг sandbox-проекта **строго** через `onboard_project.py` →
+git-доступ агентов token-remote → сборка `.env`/`.env.watchdog` орка → health/итог. Teardown —
+только документированная процедура. Рантайм байт-в-байт: `src/**`, корневой compose,
+`Dockerfile`, `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схема БД — не тронуты (NFR-1);
+kill-switch не нужен — активация только явным запуском оператора на целевом хосте
+(паттерн ORCH-009/102).
+
+### D1 — Расположение и изоляция: `deploy/bundled/`, project name `orchestrator-bundle` (OQ-1)
+
+- Новый top-level каталог **`deploy/`** — «дистрибутивы развёртывания» (исполняемые комплекты;
+  семантика дополняет `docs/deployment/` — инструкции). Bundle: **`deploy/bundled/docker-compose.yml`**,
+  один **самодостаточный** файл (include-композиция отвергнута — см. Альтернативы).
+- Top-level **`name: orchestrator-bundle`** в compose: project name фиксирован → все тома/контейнеры
+  получают узнаваемый префикс `orchestrator-bundle_*`/`orchestrator-bundle-*` (требование TC-04
+  тест-плана «узнаваемый bundle-префикс»; preflight bootstrap детектирует «грязный хост» по этому
+  префиксу). **`container_name` не пиннится ни у одного сервиса** — установка Lite и bundle на одном
+  хосте не сталкивается по именам с корневым compose (у которого `container_name: orchestrator`
+  закреплён).
+- **Staging-контур орка в bundle отсутствует вовсе** (ни сервисом, ни профилем): заказчик Type B
+  эксплуатирует платформу для СВОИХ проектов, а не развивает её self-hosting'ом; репо `orchestrator`
+  в bundle-инсталляции **не регистрируется** как проект → вся self-deploy-машинерия
+  (`SELF_HOSTING_REPO="orchestrator"`-леафы, freshness, serial-gate freeze) структурно спит.
+  Нужен self-hosting у заказчика → это маршрут Lite/корневого compose (LITE_SETUP §9), не bundle.
+- Имена сервисов: `orchestrator`, `orchestrator-watchdog` — платформенные конвенции (ORCH-101 D3);
+  `gitea`; Plane-стек — **upstream-имена** сервисов (минимальный дифф к référence, D3 ниже).
+  Запрет `plane*`/`gitea*` касается ТОЛЬКО корневого compose — на bundle-файл не распространяется.
+
+### D2 — Конфиг-слои: три файла, один писатель (OQ-1, FR-1/FR-3)
+
+| Файл | Роль | В гите |
+|------|------|--------|
+| `deploy/bundled/.env.example` | **bundle-конфиг-канон**: 100% ключей bundle-инфры (публичный хост, карта портов, uid/gid, пути Claude CLI, плейсхолдеры внутренних кред Plane/Gitea) | да (только плейсхолдеры/нейтральные дефолты) |
+| `deploy/bundled/.env` | live bundle-конфиг; **авто-читается compose** из project dir — все `docker compose -f deploy/bundled/docker-compose.yml …` работают без флагов | нет (покрыт неякорным `.env` в `.gitignore`) |
+| корневые `.env` / `.env.watchdog` | runtime-конфиг орка и watchdog — **ровно канон Lite** (REPLICATION §2 / `.env.example` / `.env.watchdog.example` применимы 1:1); в bundle-compose подключаются `env_file: ../../.env` (`required: false` — см. ниже) | нет (уже в `.gitignore`) |
+
+- **Отвергнут** отдельный live-файл с обязательным `--env-file`: оператор неизбежно наберёт голую
+  compose-команду без флага → интерполяции молча упадут в дефолты → пересоздание контейнеров с
+  чужими портами/путями (труднодиагностируемый класс R-4). Авто-`.env` в project dir — fail-safe
+  по построению.
+- **`env_file` орка/watchdog — `required: false`** (паттерн уже в корневом compose у watchdog):
+  первый `up -d` поднимает ВЕСЬ стек до того, как конфиг орка собран (AC-1 «одна команда»); орк
+  без конфига жив (`/health` отвечает), bootstrap пересоздаёт его после сборки env (шаг 8 D5).
+- **Bootstrap — единственный писатель** `deploy/bundled/.env` (дозапись сгенерённых кред),
+  корневого `.env` и `.env.watchdog` на целевом хосте: дублируемые между слоями ключи
+  (`ORCH_AGENT_HOME_DIR`, порт орка) когерентны механически, а не дисциплиной оператора.
+  Права `600`; повторный запуск НЕ перетирает существующие значения без явного флага
+  (паттерн `--force` `gen_secrets.py`).
+- **Неймспейсы ключей:** один факт = одно имя (ORCH-101 D1) — существующие факты переиспользуют
+  существующие имена (`ORCH_RUN_UID/GID`, `ORCH_DOCKER_GID`, `ORCH_AGENT_HOME_DIR`,
+  `ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`/`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`);
+  bundle-only факты — префикс **`BUNDLE_*`** (`BUNDLE_PUBLIC_HOST`, `BUNDLE_PLANE_PORT`,
+  `BUNDLE_GITEA_HTTP_PORT`, `BUNDLE_ORCH_PORT`); внутренние креды Plane-стека — **upstream-имена**
+  Plane CE (значения генерирует bootstrap). Точный состав финализирует developer; форму держит
+  key-set-sync тест: **каждая `${VAR}`-интерполяция bundle-compose имеет ключ в
+  `deploy/bundled/.env.example`** (паттерн `.env.watchdog.example`, D5 ORCH-102).
+- **Дефолты bundle-compose нейтральны** (FORBIDDEN-литералов нет — TC-06 распространяет скан на
+  bundle-артефакты): HOME акторов в bundle — `/home/orchestrator` (значение в `.env.example`
+  bundle, обе стороны группы ORCH-040 двигаются одной переменной — инвариант сохранён);
+  uid/gid/доки docker-gid заполняет bootstrap из `id -u`/`id -g`/`getent group docker`.
+- Каталоги данных орка — bind внутри project dir: `./data` → `deploy/bundled/data` (покрыт
+  неякорным `data/` в `.gitignore`), `./repos` → `deploy/bundled/repos` (**добавить в
+  `.gitignore`**: `deploy/bundled/repos/`); bind, а не named volume — те же uid-причины, что в
+  корневом compose (ORCH-040: named volume создаётся root-owned, контейнер бежит под uid
+  оператора). Состояние Plane/Gitea (postgres/redis/mq/minio/gitea-data) — **именованные тома**
+  проекта (root-владение для них нормально: процессы своих образов).
+
+### D3 — Состав стека и пиннинг: зеркало upstream, неподвижные теги литералом (OQ-2)
+
+- **Plane CE** — зеркало официального selfhost-compose Plane CE (web/space/admin/api/worker/
+  beat-worker/migrator/live + postgres/redis/mq/minio/proxy, ≈13–14 сервисов по факту référence
+  на момент пиннинга). Структура сервисов/env-контракт — upstream-имена (анти-дрейф к их докам;
+  своя «переписанная» топология Plane = неоплачиваемый долг сопровождения).
+- **Gitea** — официальный `gitea/gitea` (НЕ rootless: rootless усложняет ssh/тома, а ssh-контур
+  и так не вводится — D8).
+- **Пиннинг: точный неподвижный тег литералом в compose** (`image: <repo>:<x.y.z>`), не `latest`,
+  не плавающий мажор, не `${VERSION}`-интерполяция (версия — не операторская ручка; её смена =
+  осознанная правка bundle под тестом). Digest-пиннинг **не требуется**: тег + анти-дрейф формы
+  (TC-03: ни одного `:latest`/безтегового образа) достаточны для NFR-6, digest нечитаем и
+  затрудняет осознанный апгрейд.
+- **Точные теги фиксирует developer при реализации по фактически проверенному стенду** (ADR
+  сознательно не выдумывает номера версий — ложная точность хуже честной отсылки к référence);
+  обновление версий после ORCH-103 — отдельные задачи (BRD §6).
+- Healthchecks: у инфра-сервисов (postgres/redis/minio/gitea) — стандартные; у Plane-сервисов —
+  что даёт upstream; недостающее добирает poll-ожидание bootstrap (D5).
+
+### D4 — Сеть: одна bridge, сервис-DNS внутрь, публикация только человеческих портов (OQ-5)
+
+- **Вся инсталляция — в одной именованной bridge-сети** compose-проекта. `network_mode: host`
+  в bundle **не используется** ни для кого: он был нужен нашему контуру ради ssh-деплоя в
+  127.0.0.1 (ORCH-036/058) — в bundle эти пути структурно неактивны (`ORCH_DEPLOY_SSH_HOST`
+  пуст → freshness/self-deploy/build-cache-pruner no-op по построению).
+- **Машинный трафик — строго сервис-DNS:** Plane→орк webhook `http://orchestrator:8500/webhook/plane`,
+  Gitea→орк `http://orchestrator:8500/webhook/gitea`, орк→Plane `ORCH_PLANE_API_URL=http://<plane-proxy-svc>`,
+  орк→Gitea `ORCH_GITEA_URL=http://gitea:3000`, watchdog→орк
+  `WATCHDOG_METRICS_URL=http://orchestrator:8500/metrics`. Никаких `host-gateway`/`extra_hosts`.
+- **Наружу публикуются только человеческие точки** (карта конфигурируема в bundle-каноне,
+  дефолты): Plane proxy → `${BUNDLE_PLANE_PORT:-8080}`, Gitea web → `${BUNDLE_GITEA_HTTP_PORT:-3000}`,
+  орк API → `${BUNDLE_ORCH_PORT:-8500}` (операторский smoke `curl /health`). **Postgres/redis/
+  mq/minio наружу НЕ публикуются** (секрет-гигиена/поверхность атаки).
+- **Публичные URL** (браузер оператора, ссылки в Plane-комментариях/Telegram) строятся от
+  **`BUNDLE_PUBLIC_HOST`** (дефолт `localhost`): `ORCH_GITEA_PUBLIC_URL=http://$BUNDLE_PUBLIC_HOST:3000`,
+  `ORCH_PLANE_WEB_URL=http://$BUNDLE_PUBLIC_HOST:8080`, WEB_URL Plane, ROOT_URL Gitea. Split
+  internal/public уже поддержан конфигом орка (ORCH-101) — новых ключей `src/**` не требуется.
+- **Мина Gitea закрывается явно:** Gitea по умолчанию запрещает webhook'и в приватные адреса —
+  bundle задаёт `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` (env-конфиг образа Gitea), иначе
+  R-4 «задача не появилась» гарантирован. Smoke (FR-6) проверяет оба направления.
+- HTTPS/домены/reverse-proxy заказчика — вне bundle (BRD §2.2); `BUNDLE_PUBLIC_HOST` +
+  документированный ручной шаг при необходимости.
+
+### D5 — Bootstrap: `scripts/bootstrap_bundle.py`, python stdlib, `plan`/`apply`/`verify` (OQ-4)
+
+- **Язык — python stdlib-only** (NFR-7; паттерн `gen_secrets.py`: работает на голом python3
+  целевого хоста ДО `docker compose up`; bash отвергнут — 9-шаговый stateful-визард с
+  таймаутами/JSON/чистыми функциями под unit-тесты на bash не тестируем структурно).
+  Никаких импортов из `src/**` (bootstrap бежит вне venv платформы; канон-знания — только
+  субпроцессами кирпичей, см. ниже).
+- **Режимы (паттерн ORCH-009):** `plan` — **дефолт**, ноль мутаций (печать плана + read-only
+  preflight-диагностика); `apply` — полный прогон; `verify` — read-only пост-проверка
+  (health/queue/metrics + `onboard_project.py verify` субпроцессом). Exit-коды: `0` успех /
+  `2` остановка на manual-step или незавершённое предусловие / `1` ошибка (контракт TRZ FR-2).
+- **Step-движок check→ensure:** каждый шаг = `check()` (выполнено?) → skip | `ensure()`
+  (доводка). Повторный `apply` на инициализированном bundle = каскад skip (AC-8);
+  «resume» после manual-step = просто повторный запуск. Чистые функции (preflight-вердикт,
+  сборка плана, рендер env-файлов) выделены для unit-тестов (TC-08).
+- **Последовательность apply (норматив TRZ FR-2, механика):**
+  1. **Preflight (fail-fast, до мутаций):** docker+compose есть; `deploy/bundled/.env` существует
+     и обязательные ключи заполнены (пути Claude CLI — существуют на хосте, иначе warning-блок:
+     стек поднимется, конвейер без LLM не поедет); целевые порты свободны; томов/контейнеров с
+     префиксом `orchestrator-bundle` нет (иначе — явный «уже инициализирован, продолжаю в
+     ensure-режиме» либо отказ при противоречивом состоянии); RAM/диск ≥ минимумов из
+     BUNDLED_SETUP (пороги — константы скрипта, синхронизированы с доком); python3+venv доступны.
+  2. **Секреты (FR-3):** webhook-секреты — **субпроцессом `scripts/gen_secrets.py --write <tmp>`**
+     (не реализуются заново, AC-7); bundle-внутренние (пароли postgres/redis/mq/minio,
+     SECRET_KEY Plane, админ-пароль Gitea) — stdlib `secrets`; запись в `deploy/bundled/.env` +
+     корневой `.env`; существующие значения не перетираются без `--force-secrets`; значения
+     в stdout/лог **не печатаются** (только имена ключей).
+  3. **Up + готовность:** `docker compose -f deploy/bundled/docker-compose.yml up -d`
+     (идемпотентен по построению — оба прочтения AC-1 истинны: оператор мог выполнить up сам);
+     ожидание готовности poll-циклами с таймаутами (health контейнеров, `migrator` завершился
+     `exit 0`, HTTP-пробы Plane/Gitea); по таймауту — диагностика «какой сервис не дождались +
+     хвост его логов».
+  4. **Init Gitea — полностью автоматом** (D6).
+  5. **Init Plane — manual-step чекпоинты** (D7).
+  6. **Онбординг sandbox-проекта — строго `onboard_project.py apply` + `verify`** (D7).
+  7. **Git-доступ агентов** (D8) + клон sandbox-репо в `deploy/bundled/repos/`.
+  8. **Конфиг орка:** сборка корневого `.env` (база — канон `.env.example`: URL'ы D4, токены,
+     секреты, `ORCH_PROJECTS_JSON` из вывода onboard; `ORCH_DEPLOY_SSH_HOST=` пусто —
+     деплой-машинерия спит) и `.env.watchdog` (база — `.env.watchdog.example`; Telegram-ключи
+     опциональны — пусто = деградация только нотификаций); пересоздание
+     `up -d orchestrator orchestrator-watchdog` для подхвата env.
+  9. **Health + итог:** `GET /health`, `/queue`, `/metrics`; финальная сводная таблица PASS/FAIL
+     по шагам; следующая команда оператора — smoke BUNDLED_SETUP §smoke (REPLICATION §4).
+- **Контракт manual-step (fail-safe, BR-2):** печать точной инструкции (URL/что нажать/что
+  ввести) → ожидание подтверждения (интерактивно при TTY; без TTY — немедленный `exit 2` с той
+  же инструкцией) → **верификация результата API-пробой** (например, валидность введённого
+  `ORCH_PLANE_API_TOKEN` запросом к workspace) → только затем продолжение. Молчаливый пропуск
+  запрещён.
+- **Запретов в скрипте нет:** delete-операций (`docker volume rm`/`rm -rf`/`down -v`) — **ноль**
+  (teardown — D9); боевых литералов FORBIDDEN — ноль (TC-06); печати секретов — ноль (NFR-3);
+  наш прод недостижим по построению (скрипт говорит только с локальным docker целевого хоста).
+
+### D6 — Init Gitea: полностью автоматизирован, branch protection НЕ настраивается (OQ-3-часть)
+
+- Административная учётка — **официальный CLI в контейнере**:
+  `docker compose … exec gitea gitea admin user create --admin …` (idempotent: предсуществование
+  пользователя → skip); API-токен — `gitea admin user generate-access-token` (или REST под basic
+  auth — равнозначно, выбирает developer по фактической версии Gitea) → `ORCH_GITEA_TOKEN`.
+- **Один пользователь-бот** — владелец (`ORCH_GITEA_OWNER`) sandbox-репо и носитель токена для
+  API орка и token-remote агентов (D8). Отдельная россыпь пользователей на тестовый bundle —
+  неоправданная сложность (зафиксировано как осознанный компромисс в 10-tech-risks TR-7).
+- **Branch protection на `main` НЕ включается; pre-receive не вводится** — норматив D10 ORCH-009 /
+  adr-0037 п.4 (ломают PR-merge API merge-актора, INV-4); bundle-Gitea конфигурируется тем же
+  правилом, BUNDLED_SETUP фиксирует его явно (ссылкой на LITE_SETUP §6, не копией).
+- `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` — см. D4.
+
+### D7 — Init Plane: честные manual-step + онбординг строго кирпичом (OQ-3)
+
+- **Не автоматизируется (CE):** instance-setup/первый админ, создание workspace
+  (`ORCH_PLANE_WORKSPACE_SLUG`), выпуск `ORCH_PLANE_API_TOKEN` — три **manual-step чекпоинта**
+  контракта D5 (инструкция → подтверждение → API-верификация). **Прогрессивная автоматизация
+  разрешена:** если на момент реализации у конкретной пиннованной версии Plane CE обнаружится
+  стабильный API/seed-механизм для шага — developer вправе заменить manual-step на ensure **без
+  изменения контракта чекпоинта** (верификация результата остаётся той же) и без правки ADR.
+- **Онбординг sandbox-проекта — ТОЛЬКО субпроцессом** `python3 scripts/onboard_project.py apply`
+  + `verify` из **host-venv чекаута** (канон запуска — ONBOARDING.md: venv с `requirements.txt`;
+  создание venv — ensure-шаг bootstrap). Env для субпроцесса (URL'ы/токены D4) bootstrap передаёт
+  через окружение процесса (pydantic env-переменные перекрывают `env_file`) — корневой `.env` к
+  этому моменту уже собран либо передаётся фрагментом. Собственная реализация статусов/лейблов/
+  webhook в bootstrap **запрещена** (BR-6/AC-7; 22 статуса остаются за
+  `plane_sync._PLANE_NAME_TO_KEY`).
+- **Workspace-webhook Plane** (Plane→орк) — остаётся manual-step **самого onboard-CLI**
+  (его шаг `plane.workspace-webhook` уже MANUAL — CE не даёт API); bootstrap лишь подставляет
+  правильный in-network URL `http://orchestrator:8500/webhook/plane` и секрет-имя в инструкцию
+  и верифицирует доставку на smoke (FR-6).
+- `--webhook-url` для Gitea per-repo hook — `http://orchestrator:8500/webhook/gitea` (D4).
+
+### D8 — Git-доступ агентов: HTTP token-remote; ssh-контур не вводится (OQ-6)
+
+- Клон sandbox-репо в `deploy/bundled/repos/<repo>` с remote-URL вида
+  `http://<token>@gitea:3000/<owner>/<repo>.git` — **паттерн уже в каноне**
+  (`onboard_project.py::_push_url` делает initial push именно так); агенты наследуют origin
+  чекаута (push/fetch из контейнера — bridge-DNS, D4).
+- **Ssh-контур в bundle не вводится:** ssh-порт Gitea не публикуется, маунт `ORCH_HOST_SSH_DIR`
+  в bundle-compose отсутствует (это нашему контуру нужен ssh к хосту/Gitea; в bundle —
+  лишняя поверхность: генерация ключей, known_hosts, регистрация в Gitea).
+- Компромисс «токен в `.git/config` plaintext» зафиксирован честно: каталог `deploy/bundled/repos`
+  — локальный, права на токен-носители `600`, токен — бот-юзера одной тестовой инсталляции;
+  риск/митигейшн — 10-tech-risks TR-7. Git-идентичность агентов — существующие
+  `ORCH_AGENT_GIT_NAME`/`ORCH_GIT_EMAIL_DOMAIN` (дефолты годятся).
+
+### D9 — Teardown: только документированная процедура, не режим скрипта (OQ-7)
+
+`BUNDLED_SETUP.md` §13 «Остановка и полный сброс»: `docker compose -f … down` (остановка) /
+`down -v` + удаление сгенерённых конфигов и `deploy/bundled/{data,repos}` (полный сброс) — с
+явным предупреждением о необратимости. **Reset-режим в bootstrap отвергнут:** одна опечатка
+флага = снос томов; ценность против fenced-команды — нулевая; зато скрипт получает структурную
+гарантию «delete-операций НЕТ вообще» (упрощение TC-07 и ревью).
+
+### D10 — Док-канон: `docs/deployment/BUNDLED_SETUP.md`, 14 разделов, ссылки вместо форка (FR-4)
+
+Форма — канон LITE_SETUP (adr-0037 D2): нормативные разделы в порядке маршрута оператора,
+каждый исполняемый шаг = fenced-команда + «Проверка:» PASS/FAIL, хост-специфика — только
+плейсхолдеры. **14 разделов** (норматив; точные заголовки — за developer'ом, проверяемость —
+структурный тест): (1) рамка Bundled (включая «что НЕ входит»: Claude CLI, Telegram, HTTPS;
+границы vs Lite); (2) **требования к хосту** (RAM/диск/CPU **по замеру тестового развёртывания**,
+карта портов D4, явное «Plane ≈ 14 контейнеров — ресурсоёмко»); (3) предусловия;
+(4) получение кода; (5) секреты; (6) запуск bundle-compose; (7) bootstrap (+ перечень
+manual-step Plane); (8) LLM — ссылкой на LITE_SETUP §7; (9) Telegram — ссылкой на LITE_SETUP §8;
+(10) онбординг следующих проектов — ссылкой на ONBOARDING.md; (11) smoke — шаги REPLICATION §4;
+(12) stateless-проверка; (13) остановка/полный сброс (D9); (14) траблшутинг (минимум: webhook
+не доходит — включая `ALLOWED_HOST_LIST`, OOM/нехватка RAM, порт занят, claude не найден,
+Plane-миграции не завершились). Fail-closed имена `Confirm Deploy`/`STOP` и «22 статуса» —
+сверкой импорта в тесте, не литералом. `docs/operations/REPLICATION.md` §1: строка Type B →
+✅ ORCH-103 + ссылка. **Норматив сопровождения (NFR-5):** изменил шаги Bundled-тиража → обнови
+BUNDLED_SETUP.md в том же PR.
+
+### D11 — Анти-дрейф: три структурных тест-модуля (FR-5; без docker/сети/LLM)
+
+По тест-плану `04-test-plan.yaml` (имена модулей — норматив): `tests/test_bundle_compose.py`
+(TC-01…04: yaml.safe_load, обязательные сервисы, заморозка корневого compose зеркалом
+существующего ассерта, пины образов, префикс томов, key-set-sync `${VAR}` ⊆
+`deploy/bundled/.env.example`), `tests/test_bundled_setup_doc.py` (TC-05/06/09/10/11: разделы
+D10, FORBIDDEN — **импорт** из `test_no_host_hardcodes.py`, секрет-эвристика hex≥32/alnum≥40 —
+паттерн D8 ORCH-102, env-ключи ⊆ канонов, число статусов — импортом `plane_sync`, кросс-рефы,
+CHANGELOG), `tests/test_bootstrap_script.py` (TC-07/08: ссылки на кирпичи, отсутствие
+delete-операций и собственного списка статусов, unit чистых функций preflight/плана/рендера,
+контракт exit 0/2/1). Существующие анти-дрейф тесты остаются зелёными **без правки их ассертов**
+(AC-5/AC-6).
+
+## Альтернативы
+
+- **Расширить корневой `docker-compose.yml` (профиль `bundled`)** — отвергнуто: заморожен
+  анти-дрейфом ORCH-102 (TC-04) и нормативом adr-0037 п.2 «compose не форкается»; смешение
+  боевого контура с дистрибутивом = групповой риск self-hosting.
+- **Include-композиция (`include:`/несколько `-f`)** — отвергнуто: многофайловость = новые
+  степени свободы запуска (забытый `-f` молча меняет состав), сложнее структурный тест; один
+  самодостаточный файл проще и детерминированнее (NFR-6).
+- **Live env через `--env-file deploy/bundled/.env.bundled`** — отвергнуто: footgun голой
+  compose-команды без флага (молчаливые дефолты) — см. D2.
+- **Орк в bundle под `network_mode: host` + `host-gateway` для webhook'ов** — отвергнуто:
+  хост-сеть нужна была нашему ssh-деплой-контуру, который в bundle спит; bridge даёт чистые
+  стабильные сервис-DNS-URL обоих направлений и нулевые порт-конфликты (D4).
+- **Digest-пиннинг образов** — отвергнуто: нечитаем, усложняет осознанный апгрейд; неподвижный
+  тег + тест формы достаточны для NFR-6 (D3).
+- **Ssh-доступ агентов к bundle-Gitea** — отвергнуто: три лишних механизма (ключи, known_hosts,
+  регистрация) против уже существующего token-remote-паттерна onboard (D8).
+- **Bash-bootstrap** — отвергнуто: нет unit-тестируемых чистых функций (TC-08), JSON/поллинг/
+  стейт-машина шагов на bash хрупки (D5).
+- **Reset-режим bootstrap** — отвергнуто: риск-поверхность против нулевой ценности (D9).
+- **Переписать Plane-стек «по-своему» (свои имена сервисов/env)** — отвергнуто: дрейф от
+  upstream-доков, неоплачиваемое сопровождение (D3).
+
+## Последствия
+
+- **+** Эпик ORCH-10 закрывается по типу B: заказчик без инфраструктуры получает конвейер
+  «под ключ» одной командой + одним bootstrap-прогоном с честными чекпоинтами.
+- **+** Нулевой дрейф канонов: статусы/лейблы/секреты/smoke/док-форма — переиспользованы
+  (gen_secrets, onboard_project, REPLICATION §4, форма LITE_SETUP); рантайм байт-в-байт.
+- **+** Наш прод недостижим по построению: артефакты инертны в нашем контуре, kill-switch не
+  нужен (паттерн ORCH-009); все существующие анти-дрейф тесты остаются зелёными.
+- **−** Новая поверхность сопровождения: пиннованные версии Plane/Gitea стареют (апгрейд —
+  отдельные задачи, NFR-6); двойной `.env`-слой (bundle-инфра vs runtime орка) требует
+  дисциплины «писатель — bootstrap» (митигировано D2: один писатель + key-sync тест).
+- **−** Manual-step Plane CE размывают UX «одной команды» — неустранимо честно (CE без API
+  первичной инициализации); митигировано контрактом чекпоинта (инструкция+верификация) и
+  прогрессивной автоматизацией (D7).
+- **−** Токен в remote-URL агентских чекаутов — осознанный компромисс тестовой инсталляции
+  (TR-7; права 600, непубликуемые порты БД, один бот-юзер).
+- **Откат:** удалить `deploy/`, `scripts/bootstrap_bundle.py`, `docs/deployment/BUNDLED_SETUP.md`,
+  три тест-модуля, строку REPLICATION §1 и записи CHANGELOG/CLAUDE.md/README — состояние репо 1:1
+  (docs+scripts+tests, без миграций); на целевых хостах — процедура §13 (D9).
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-103/01-brd.md`
+- TRZ: `docs/work-items/ORCH-103/02-trz.md` (OQ-1…OQ-7 → D1…D9)
+- Acceptance: `docs/work-items/ORCH-103/03-acceptance-criteria.md`; тест-план: `04-test-plan.yaml`
+- Сквозной ADR: `docs/architecture/adr/adr-0038-bundled-replication-canon.md`
+- Предшественники: adr-0035 (ORCH-009 onboarding: D10 branch-protection, manual-step, `_push_url`),
+  adr-0036 (ORCH-101 10-common: параметризация/«дефолт=боевое»/gen_secrets/REPLICATION),
+  adr-0037 (ORCH-102 Lite: док-канон/`.env.watchdog.example`/compose-подмножество)
+- Сверено по коду/репо: `tests/test_lite_setup_doc.py` (заморозка корневого compose, FORBIDDEN-импорт,
+  секрет-эвристика), `tests/test_no_host_hardcodes.py` (`FORBIDDEN`), `scripts/gen_secrets.py`
+  (`--write PATH`, exit 0/2), `scripts/onboard_project.py` (закрытый src-импорт-лист, MANUAL
+  `plane.workspace-webhook`, `_push_url`, exit 0/2/1), `docs/operations/ONBOARDING.md` (host-venv),
+  `docker-compose.yml` (паттерны `${VAR:-default}`, `env_file required:false`, группа ORCH-040),
+  `.gitignore` (неякорные `.env`/`data/`/`.env.watchdog`)

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

@@ -0,0 +1,73 @@
+---
+work_item: ORCH-103
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap
+
+Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: architecture
+
+> Вся инфраструктура этой задачи — **ЦЕЛЕВОЙ хост заказчика** (и одноразовый тестовый хост/VM
+> приёмки). Инфраструктура НАШЕГО прод-контура (mva154) не затрагивается ни одним пунктом:
+> артефакты bundle в нашем контуре инертны (NFR-2, паттерн ORCH-009).
+
+## I-1. Топология / окружения
+
+**Наш контур: N/A** (корневой `docker-compose.yml`, прод 8500, staging 8501 — байт-в-байт).
+
+**Целевой хост bundle (нормативно, ADR-001 D1/D3/D4):**
+- Один Linux x86_64 хост, docker + docker compose v2, sudo у оператора. Compose-проект
+  **`orchestrator-bundle`** (`deploy/bundled/docker-compose.yml`), одна именованная bridge-сеть.
+- Состав: `orchestrator` (build из корневого `Dockerfile`), `orchestrator-watchdog`
+  (build из `watchdog/Dockerfile`), `gitea` (пиннованный `gitea/gitea`), Plane CE-стек —
+  зеркало upstream selfhost-référence (≈13–14 сервисов: web/space/admin/api/worker/beat-worker/
+  migrator/live + postgres/redis/mq/minio/proxy; точные теги пиннит developer по проверенному
+  стенду). Staging-контур орка отсутствует.
+- **Карта портов (дефолты; конфигурируемы в `deploy/bundled/.env.example`):**
+  `${BUNDLE_ORCH_PORT:-8500}` — API орка (smoke/health), `${BUNDLE_PLANE_PORT:-8080}` — Plane
+  proxy (UI), `${BUNDLE_GITEA_HTTP_PORT:-3000}` — Gitea web. Postgres/redis/mq/minio/ssh-Gitea —
+  **наружу не публикуются**. Машинный трафик (webhooks в обе стороны, API, git, /metrics) —
+  внутрисетевой сервис-DNS.
+- **Хранилище:** состояние Plane/Gitea — именованные тома `orchestrator-bundle_*`; данные орка —
+  bind `deploy/bundled/data`; репозитории агентов — bind `deploy/bundled/repos` (владелец —
+  uid оператора = `ORCH_RUN_UID`, инвариант ORCH-040).
+- **Ресурсы (предусловие, гипотеза BRD §6 — финальные цифры по замеру на приёмке, AC-4):**
+  ориентир ≥ 4 vCPU / 8 GB RAM / 40 GB диска; preflight bootstrap проверяет и отказывает до
+  любых мутаций (BR-7).
+
+## I-2. Переменные окружения / секреты
+
+- **Новый канон:** `deploy/bundled/.env.example` (bundle-инфра: `BUNDLE_PUBLIC_HOST`, карта
+  портов, реюз `ORCH_RUN_UID/GID`/`ORCH_DOCKER_GID`/`ORCH_AGENT_HOME_DIR`/`ORCH_HOST_CLAUDE_*`,
+  плейсхолдеры внутренних кред Plane/Gitea по upstream-именам). Live-файлы только на целевом
+  хосте, права 600: `deploy/bundled/.env`, корневые `.env`/`.env.watchdog` (каноны Lite 1:1).
+- **Корневой `.env.example` НЕ меняется** (bundle не вводит новых ключей `Settings`); в
+  `.gitignore` добавляется `deploy/bundled/repos/` (остальные live-файлы уже покрыты неякорными
+  `.env`/`data/`/`.env.watchdog`).
+- **Секреты (FR-3):** webhook-секреты — `gen_secrets.py`; внутренние креды стека (postgres/
+  redis/mq/minio/SECRET_KEY Plane, админ Gitea) — stdlib `secrets` в bootstrap; внешние
+  предусловия заказчика — Claude CLI/Anthropic-доступ (обязателен для конвейера),
+  Telegram-токены (опциональны). В репо и логах bootstrap секретов нет (NFR-3, тест-эвристика).
+
+## I-3. Деплой / рестарт
+
+- **Наш прод: рестарт НЕ требуется и НЕ выполняется.** Задача — docs+scripts+compose+tests;
+  мерж в `main` ничего не активирует в нашем контуре (никто не исполняет bundle-артефакты;
+  kill-switch не нужен — паттерн ORCH-009). Self-hosting инвариант соблюдён по построению.
+- На целевом хосте пересоздание контейнеров орка/watchdog после сборки env — штатный шаг
+  bootstrap (D5 шаг 8); к нашему проду отношения не имеет.
+
+## I-4. CI/CD
+
+- `.gitea/workflows/**` — **без изменений**; три новых структурных тест-модуля подхватываются
+  существующим `pytest tests/ -q` (без docker/сети/LLM — CI-безопасны, TC-12).
+
+## I-5. Разовое предусловие приёмки (человек)
+
+Чистый тестовый Linux-хост/VM (ресурсы I-1) для ручной приёмки AC-1/AC-2/AC-3/AC-8 по
+`BUNDLED_SETUP.md` + замер фактических минимумов RAM/диск/CPU для §2 дока (AC-4: цифры «не с
+потолка»). На нашем боевом хосте bundle не запускается ни в каком виде (BRD §2.2).

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

@@ -0,0 +1,42 @@
+---
+work_item: ORCH-103
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap
+
+Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации и эксплуатации bundle; решения —
+> `06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md` (D1…D11).
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Ресурсоёмкость Plane** (≈13–14 контейнеров): OOM/вечные миграции на слабом хосте → «bundle не работает» | Сред. | Выс. | Preflight bootstrap (RAM/диск/CPU до мутаций, BR-7); честные цифры в BUNDLED_SETUP §2 **по замеру** (AC-4); таймауты ожидания готовности с диагностикой «кто не дождался + хвост логов» (D5 ш.3); траблшутинг §14 |
+| TR-2 | **Дыры Plane CE API**: instance-setup/workspace/API-токен UI-only → UX «одной команды» размывается; молчаливый пропуск шага ломает всё дальше | Выс. | Сред. | Контракт manual-step (инструкция → подтверждение → **API-верификация результата**, exit 2 без TTY; D5/D7); число ручных шагов минимизировано (Gitea — полностью автоматом, D6); прогрессивная автоматизация разрешена без смены контракта |
+| TR-3 | **Дрейф upstream-образов**: «плавающий» тег ломает воспроизводимость; пиннованные версии стареют (CVE/несовместимость) | Сред. | Сред. | Неподвижные теги литералом + тест формы TC-03 (не `latest`/безтеговых); теги фиксируются по фактически проверенному стенду (D3); апгрейд — отдельные задачи (NFR-6, BRD §6) |
+| TR-4 | **Сетевая недостижимость вебхуков** (труднодиагностируемое «задача не появилась»): приватные адреса, рассинхрон URL | Сред. | Выс. | Одна bridge-сеть + строго сервис-DNS для машинного трафика (D4); **явный `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`** (Gitea по умолчанию режет приватные таргеты); URL подставляет bootstrap, не оператор; smoke проверяет ОБА направления (FR-6); траблшутинг §14 |
+| TR-5 | **Соблазн форкнуть/расширить корневой compose** (упадёт анти-дрейф ORCH-102 TC-04) | Низ. | Выс. | Bundle строго отдельным файлом `deploy/bundled/` (D1); TC-02 зеркалит заморозку корневого compose; правило эскалации TRZ §7 — если всплывёт незакрытая параметризация `src/**`, остановиться и вернуть задачу, не «дотачивать молча» |
+| TR-6 | **Утечка секретов** в репо/логи при генерации bundle-кред | Низ. | Выс. | В гите — только плейсхолдеры (канон D2); bootstrap не печатает значения (имена ключей/пути, D5); права 600; секрет-эвристика hex≥32/alnum≥40 + FORBIDDEN-скан на новых артефактах (TC-06); live-файлы в `.gitignore` |
+| TR-7 | **Токен-remote агентов**: токен бот-юзера plaintext в `.git/config` чекаутов; один бот = широкие права | Сред. | Низ. | Осознанный компромисс тестовой инсталляции (D8): порты БД/брокера не публикуются, каталог локальный, права 600; ssh-контур сознательно не вводится (меньше поверхность); зафиксировано в BUNDLED_SETUP §1 «рамка» |
+| TR-8 | **Путаница двух `.env`-слоёв** (bundle-инфра `deploy/bundled/.env` vs runtime орка корневой `.env`): ручная правка не того файла | Сред. | Сред. | Bootstrap — **единственный писатель** всех live-файлов (D2); авто-чтение compose из project dir (нет `--env-file`-футгана); шапки-комментарии в канонах перекрёстно ссылаются; key-set-sync тест TC-04 |
+| TR-9 | **Хост-python/venv для onboard**: `onboard_project.py` требует venv с `requirements.txt` (канон ONBOARDING) — на голом хосте шаг 6 падает | Сред. | Сред. | Preflight проверяет python3/venv (D5 ш.1); создание venv — идемпотентный ensure-шаг bootstrap; сам bootstrap stdlib-only и от venv не зависит (D5) |
+| TR-10 | **Повторный запуск/грязный хост**: bootstrap портит чужое состояние или дублирует своё | Низ. | Выс. | Step-движок check→ensure (skip-семантика, AC-8); детект «грязи» по префиксу `orchestrator-bundle` до мутаций; delete-операций в скрипте нет вообще — teardown только документированной процедурой §13 (D9); unit-тесты чистых функций preflight (TC-08) |
+
+## Сводный вывод
+
+Доминирующий класс — **эксплуатационные риски целевого хоста** (TR-1/TR-2/TR-4): они не
+затрагивают наш прод и гасятся честным preflight, контрактом manual-step и smoke в обе стороны.
+Рисков для прод-конвейера self-hosting **нет по построению** (NFR-1/NFR-2: рантайм байт-в-байт,
+артефакты в нашем контуре инертны, kill-switch не требуется — паттерн ORCH-009; все существующие
+анти-дрейф тесты остаются зелёными). Эскалация `arch:major-change` не требуется: новых стадий/
+компонентов рантайма/смены БД нет — задача целиком в слое дистрибуции (паттерн ORCH-101/102).
+Возврат в анализ не требуется: ТЗ выполнимо без нарушения принципов; единственный заранее
+оговорённый стоп-кран — TR-5 (обнаружение незакрытой параметризации `src/**` ⇒ остановка по
+TRZ §7). Остаточный риск — **низкий**.

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

@@ -0,0 +1,160 @@
+---
+verdict: APPROVED
+work_item: ORCH-103
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-103
+version: 1
+---
+
+# Review ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter.
+
+## Summary
+
+PR закрывает Type B эпика ORCH-10 строго по ТЗ и ADR-001 (D1–D11): новый каталог
+`deploy/bundled/` (самодостаточный compose 16 сервисов, project name `orchestrator-bundle`,
+пиннинг неподвижными тегами, одна bridge-сеть, только человеческие порты, мина
+`GITEA__webhook__ALLOWED_HOST_LIST` закрыта), `scripts/bootstrap_bundle.py` (stdlib-only,
+`plan`-дефолт/`apply`/`verify`, step-движок check→ensure, exit 0/2/1, ноль delete-операций),
+конфиг-канон `deploy/bundled/.env.example` (ни одного дефолтного пароля),
+`docs/deployment/BUNDLED_SETUP.md` (14 разделов канона D10) и три содержательных
+анти-дрейф тест-модуля. Рантайм байт-в-байт: `git diff main` не содержит `src/**`,
+корневого `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**` (AC-6 подтверждён
+diff-stat'ом). Полный регресс: **`pytest tests/ -q` → 1844 passed, 0 failed** (AC-5);
+существующие анти-дрейф тесты (`test_lite_setup_doc.py`, `test_no_host_hardcodes.py`,
+канон ORCH-009) не правились. Документация обновлена в том же PR по всем точкам §8 ТЗ.
+Findings — только P2/P3, блокеров нет → **APPROVED**.
+
+## Оси проверки
+
+### 1. Соответствие ТЗ (02-trz.md, 03-acceptance-criteria.md)
+
+- **FR-1** ✅ — отдельный bundle-compose; состав = ADR D1/D3 (тест
+  `test_bundle_has_exactly_the_adr_service_set` фиксирует множество); пиннинг всех сторонних
+  образов литералом (TC-03); тома — именованные с префиксом проекта + bind строго внутри
+  project dir (TC-04); достижимость в обе стороны — сервис-DNS (D4) + `ALLOWED_HOST_LIST`;
+  карта портов в доке §2, конфликт порта → отказ preflight; staging-контура нет вовсе.
+- **FR-2** ✅ — последовательность шагов 1–9 ТЗ воспроизведена 1:1 в `APPLY_STEPS`
+  (тест `test_apply_steps_match_normative_plan` держит соответствие нормативному плану);
+  идемпотентность — check→ensure/skip (AC-8 покрыт unit'ами resume/«противоречивое
+  состояние»); exit-контракт 0/2/1 (`test_exit_code_contract`); манифест manual-step честный:
+  инструкция → подтверждение → API-верификация, без TTY — немедленный exit 2.
+- **FR-3** ✅ — webhook-секреты строго субпроцессом `gen_secrets.py` (структурный тест);
+  bundle-креды — stdlib `secrets` (token_hex ≥16 байт, unit проверяет длину); в репо только
+  пустые плейсхолдеры (`test_bundle_secrets_in_example_are_empty_placeholders`); права 600;
+  без перетирания без `--force-secrets` (`test_merge_missing_secrets_never_overwrites_without_force`).
+- **FR-4** ✅ — BUNDLED_SETUP.md: все 14 разделов в порядке маршрута, fenced-команды +
+  «Проверка:»/PASS/FAIL в каждом исполняемом разделе, общие шаги ссылками на
+  LITE_SETUP §5–§8 / ONBOARDING / REPLICATION §4 (форк канона отсутствует), fail-closed имена
+  `Confirm Deploy`/`STOP` и «22 статуса» — сверкой импорта `plane_sync._PLANE_NAME_TO_KEY`.
+- **FR-5** ✅ — три модуля без docker/сети/LLM; FORBIDDEN — импорт из
+  `test_no_host_hardcodes.py` (один источник истины); секрет-эвристика hex≥32/alnum≥40 с
+  негативным самочеком (не-evergreen); key-set-sync `${VAR}` ⊆ bundle-канона; заморозка
+  корневого compose зеркалом ассерта ORCH-102.
+- **FR-6** ✅ — smoke = REPLICATION §4 поверх bundle (§11 дока, без форка), минимальный
+  сигнал «артефакты 01–04 в ветке» зафиксирован.
+- **AC-матрица:** AC-4…AC-9 в файловой/структурной части — PASS (TC-01…TC-12 зелёные).
+  AC-1/AC-2/AC-3/AC-8(повторный прогон) в e2e-части — **ручная приёмка** на чистом хосте/VM
+  по рамке самих AC (в CI docker/LLM не гоняются) — остаётся за стадией приёмки, см. P2-2.
+
+### 2. Соответствие ADR (06-adr/ADR-001, adr-0038)
+
+- D1–D11 реализованы без отклонений; сквозной `adr-0038-bundled-replication-canon.md` заведён.
+- **Прогрессивная автоматизация webhook (D7)** — единственное место, где реализация глубже
+  буквы ADR: `step_plane_webhook` регистрирует workspace-webhook прямой записью в Postgres
+  инсталляции. Сверено: это **не новый канон, а переиспользование** документированного
+  «пути Б» LITE_SETUP §5.4 (тот же INSERT-контракт, колонка-в-колонку), контракт чекпоинта
+  сохранён (верификация SELECT'ом; при отказе — fallback на честный manual-step с той же
+  проверкой), схема стабильна благодаря пину `v0.23.1`. D7 явно разрешает такую замену
+  manual-step → ensure «без правки ADR». Нарушения нет; в доке §7 чекпоинт 4 описан честно.
+- **Трассировка (TRACEABILITY):** правка чужого маркированного блока одна — строка Type B в
+  `REPLICATION.md` §1 (артефакт ORCH-101); это запланированная точка расширения, прямо
+  предписанная ТЗ FR-6/§8 — инвариант ORCH-101 не сломан. Остальные изменения аддитивны
+  (новые файлы / новые секции CLAUDE.md, README архитектуры, CHANGELOG).
+- Нормативы предшественников соблюдены: branch protection НЕ настраивается (D10 ORCH-009 /
+  INV-4 — явно в D6 и §14.6 дока), compose не форкается (adr-0037), «дефолт = боевое» не
+  нарушен (корневой `.env.example` не тронут).
+
+### 3. Качество кода
+
+- `pytest tests/ -q`: **1844 passed, 0 failed** (66s); новые тесты содержательные — unit'ы
+  чистых функций покрывают позитив/негатив/resume/противоречивое состояние, эвристики имеют
+  негативный самочек, ast-скан stdlib-allowlist реально закрыт.
+- Бизнес-логика скрипта аккуратная: never-print секретов в stdout (только имена ключей),
+  маскированный лог при падении clone (токен в URL не утекает в вывод), `_psql` через stdin
+  (секрет не в argv), fail-fast preflight до любых мутаций, диагностика «кто не дождался +
+  хвост логов». Не багфикс-трек (feature) — требование регресс-теста-фиксатора BR-4/ORCH-019
+  неприменимо.
+- Замечания P2/P3 — ниже; ни одно не ломает инварианты конвейера и не относится к рантайму
+  платформы (скрипт исполняется только оператором на целевом хосте).
+
+### 4. Документация — обязательная проверка
+
+Выполнена явно, см. раздел «Документация» ниже. Обновлено всё требуемое в том же PR.
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- [ ] **P2-1. Секреты в argv субпроцессов** (`scripts/bootstrap_bundle.py`):
+  `step_init_gitea` передаёт `GITEA_ADMIN_PASSWORD` аргументом `--password` в
+  `docker compose exec gitea gitea admin user create …`, а `step_agent_git` — токен в
+  clone-URL аргументом `git clone http://oauth2:<token>@…`. Значения видимы в `ps` хоста на
+  время исполнения. Формально AC-8 («секрет виден в stdout/логе») не нарушен, но это против
+  духа NFR-3 (ТЗ FR-2) и непоследовательно с собственной argv-гигиеной скрипта (`_psql`
+  прогоняет секреты через stdin с явным комментарием «секреты не попадают в argv, NFR-3»).
+  Рекомендация: для clone — использовать `git -c credential.helper`/`GIT_ASKPASS` либо
+  дописать компромисс в TR-7 (10-tech-risks) и шапку скрипта; для `gitea admin user create`
+  альтернатив CLI мало — минимум зафиксировать окно экспозиции в TR-7. Не блокер: разовая
+  операция оператора на одноарендном целевом хосте, угроза-модель совпадает с уже
+  зафиксированным компромиссом TR-7.
+- [ ] **P2-2. Замер цифр «Требований к хосту» отложен на приёмку** (AC-4): BUNDLED_SETUP §2
+  декларирует «подтверждаются замером приёмочного развёртывания» — на момент ревью цифры
+  (8 GB / 40 GB / 4 vCPU) синхронизированы с константами preflight структурным тестом, но
+  фактический замер ещё не зафиксирован. По рамке 03-acceptance-criteria (e2e — ручная
+  приёмка вне CI) это допустимо, однако при ручной приёмке AC-1/AC-2 результат замера нужно
+  зафиксировать (13-test-report / 15-staging-log или правка §2), иначе FAIL-условие AC-4
+  «цифры с потолка» останется формально незакрытым.
+
+### P3 — Nice to have
+- [ ] **P3-1.** `step_plane_webhook`: `slug`/`secret` интерполируются в SQL-строку без
+  экранирования одинарных кавычек. Секрет — hex от `gen_secrets` (безопасен), slug —
+  операторский ввод; кавычка в slug уронит INSERT. Риск минимален (ON_ERROR_STOP +
+  fail-safe fallback на manual-step), но дешёвое `value.replace("'", "''")` сняло бы класс
+  целиком.
+- [ ] **P3-2.** `run_verify`: при одновременном health-FAIL и onboard `exit 2` функция
+  возвращает `EXIT_MANUAL` (2), маскируя ошибку (ожидался бы приоритет `1`). Поведенческая
+  мелочь read-only режима.
+
+## Документация
+
+| Артефакт | Статус |
+|----------|--------|
+| `CLAUDE.md` | ✅ новый раздел «Bundled-тираж (ORCH-103)» (паттерн ORCH-101/102) |
+| `docs/architecture/README.md` | ✅ блок Type B — Bundled рядом с 10-common/Lite |
+| `CHANGELOG.md` | ✅ запись `feat: ORCH-103` (детальная, D1–D11) |
+| `docs/operations/REPLICATION.md` §1 | ✅ Type B → ✅ ORCH-103 + ссылка на BUNDLED_SETUP.md |
+| `docs/deployment/BUNDLED_SETUP.md` | ✅ создан, 14 разделов канона D10, держится тестом |
+| ADR | ✅ work-item `06-adr/ADR-001-…` + сквозной `adr-0038-bundled-replication-canon.md` |
+| `07-infra-requirements.md`, `10-tech-risks.md` (TR-1…TR-9) | ✅ заведены архитектором, кросс-рефы из кода сходятся |
+| `.gitignore` | ✅ `deploy/bundled/repos/` (NFR-3) |
+| `README.md` «Известные ограничения» (ORCH-079) | ✅ проверено явно: PR не закрывает ни один из 3 открытых пунктов (Telegram 48h / intra-repo deps / пакетный автоном) — обновление витрины не требуется |
+
+`src/**` не изменён (PR — deploy/scripts/docs/tests), поэтому P0-правило «`src/` изменён без
+документации» неприменимо; документация при этом обновлена полностью.
+
+## Итог
+
+`verdict: APPROVED` — P0/P1 отсутствуют; P2-1/P2-2 и P3 рекомендуется снять follow-up'ом или
+при ручной приёмке Bundled-развёртывания (AC-1/AC-2/AC-3/AC-8 e2e-часть).

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

@@ -0,0 +1,67 @@
+---
+result: PASS
+work_item: ORCH-103
+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-103
+---
+
+# Test Report — ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
+
+> Машинный вердикт читается ТОЛЬКО из `result:` во frontmatter (`check_tests_passed`).
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-103-orch-10b-bundled-bootstrap/` (ветка задачи, не общий чекаут)
+- Дата: 2026-06-11
+
+## Smoke API (read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — активная задача ORCH-103 (`stage: testing`) видна |
+| `GET /queue` | PASS — валидный JSON; блок `serial_gate` присутствует (ORCH-088, `orchestrator.active_task = ORCH-103`), блок `auto_labels` присутствует |
+
+Смок-регресс ORCH-088: блок `serial_gate` присутствует в полезной нагрузке `/queue` наряду с `auto_labels` — регресса нет.
+
+## Результаты (покрытие каждого TC из 04-test-plan.yaml)
+
+| TC ID | Тип | Описание (кратко) | AC | Модуль | Результат |
+|-------|-----|-------------------|----|--------|-----------|
+| TC-01 | unit | Bundle-compose существует/парсится; обязательные сервисы (орк/watchdog/Gitea/Plane-стек); staging не в дефолтном up | AC-1 | test_bundle_compose.py | PASS |
+| TC-02 | unit | Корневой docker-compose.yml не изменён; нет подстрок plane/gitea (зеркало TC-04 lite) | AC-6 | test_bundle_compose.py | PASS |
+| TC-03 | unit | Все сторонние образы пиннованы (нет latest/безтегового) | AC-9 | test_bundle_compose.py | PASS |
+| TC-04 | unit | Тома именованные с bundle-префиксом, без bind прод-контура; key-set-sync `${VAR}` ⊆ bundle-канон | AC-9 | test_bundle_compose.py | PASS |
+| TC-05 | unit | BUNDLED_SETUP.md: обязательные разделы FR-4 (требования к хосту с цифрами/портами/~14 контейнеров, bootstrap, smoke, stateless, сброс, траблшутинг); fenced + «Проверка:» | AC-4 | test_bundled_setup_doc.py | PASS |
+| TC-06 | unit | Гигиена (док+compose+bootstrap): нет FORBIDDEN-литералов (импорт из test_no_host_hardcodes); нет секрет-литералов (hex≥32/alnum≥40) | AC-9 | test_bundled_setup_doc.py | PASS |
+| TC-07 | unit | Bootstrap ссылается на gen_secrets.py/onboard_project.py; нет своего списка статусов/лейблов; нет delete-операций в обычном прогоне | AC-7 | test_bootstrap_script.py | PASS |
+| TC-08 | unit | Чистые функции bootstrap: грязный хост → отказ ДО мутаций; чистый → план; контракт exit 0/2/1 | AC-8 | test_bootstrap_script.py | PASS |
+| TC-09 | unit | Каждый env-ключ из дока есть в `.env.example` ∪ bundle-канон; число статусов сверяется импортом `plane_sync._PLANE_NAME_TO_KEY` | AC-9 | test_bundled_setup_doc.py | PASS |
+| TC-10 | unit | Кросс-ссылки: BUNDLED_SETUP → LITE_SETUP/ONBOARDING/REPLICATION; REPLICATION §1 отметка Type B → ORCH-103 | AC-7 | test_bundled_setup_doc.py | PASS |
+| TC-11 | unit | CHANGELOG.md содержит запись ORCH-103 | AC-5 | test_bundled_setup_doc.py | PASS |
+| TC-12 | integration | Полный регресс `pytest tests/ -q` зелёный; существующие анти-дрейф (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон ORCH-009) без правки ассертов | AC-5 | tests/ | PASS |
+
+Все 12 TC выполнены и сопоставлены с критериями приёмки 03-acceptance-criteria.md. Структурная/файловая часть AC-4…AC-9 покрыта зелёными TC-01…TC-12. e2e-часть AC-1/AC-2/AC-3/AC-8 (фактический подъём bundle на чистом хосте/VM) — ручная приёмка вне CI по рамке самих AC (docker/LLM в CI не гоняются), как зафиксировано в test-plan `scope/notes` и ревью P2-2.
+
+## Целевые модули ORCH-103 (детально)
+- `tests/test_bundle_compose.py` — 14 passed (TC-01..04)
+- `tests/test_bundled_setup_doc.py` — 16 passed (TC-05/06/09/10/11)
+- `tests/test_bootstrap_script.py` — 19 passed (TC-07/08)
+- Анти-дрейф (без правки ассертов): `tests/test_lite_setup_doc.py` — 26 passed; `tests/test_no_host_hardcodes.py` — 8 passed
+- Итого по целевому срезу: **88 passed, 0 failed** (0.91s)
+
+## Вывод pytest (полный регресс)
+```
+$ python -m pytest tests/ -v --tb=short
+...
+================== 1844 passed, 1 warning in 70.33s (0:01:10) ==================
+```
+- 1844 passed, 0 failed, 1 warning (Pydantic V2 deprecation, не относится к задаче).
+
+## Итог
+PASS — полный регресс зелёный (1844 passed / 0 failed), smoke read-only (`/health`, `/status`, `/queue` с блоками `serial_gate` и `auto_labels`) в норме, все 12 TC из 04-test-plan.yaml выполнены и сопоставлены с критериями приёмки. Задача переходит на `deploy-staging`.

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

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-103
+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-103/15-staging-log.md

@@ -0,0 +1,34 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-103
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+timestamp: 2026-06-10T23:15:16Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment (`orchestrator-staging`,
+port 8501, mode=stub). Ran canonically **inside the container** via `docker exec` (ORCH-048)
+so the B6 registry-isolation check reads `.env.staging` from the running instance's own
+process-env.
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+- REAL failed: none
+- All REAL checks (A1–A3 smoke, B4–B6 access incl. registry isolation, C7–C8 E2E
+  create-issue / trigger-pipeline) are 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) — C9a/C9b are the two known sandbox-infra checks (depend on SANDBOX
+bot accounts being project members, not on the pipeline) and are tolerated under ORCH-061
+waiver tolerance (`staging_infra_tolerance_enabled=True`) since every REAL check passed.
+
+ORCH-103 is a docs+tests + new `deploy/bundled/` and `scripts/bootstrap_bundle.py` change;
+`src/**`, the root compose, Dockerfile, `STAGE_TRANSITIONS`/`QG_CHECKS`/DB schema are untouched,
+so no runtime behaviour regression is expected — consistent with the all-green REAL checks.

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

@@ -0,0 +1,7 @@
+# Business Request: Подготовка презентации по орку
+
+Work Item ID: ORCH-105
+
+## Description
+
+TBD

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

@@ -0,0 +1,169 @@
+---
+work_item: ORCH-105
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-105 — Подготовка презентации по орку
+
+Work Item: **ORCH-105** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Заказчику нужна **презентация о продукте «Orchestrator» в формате PowerPoint** — чтобы
+показывать платформу стейкхолдерам и потенциальным заказчикам. Дополнительно в презентацию
+надо добавить **слайд про Lite-установку** (через скрипты-установщики) и **слайды-инструкцию
+«как пользоваться орком через Plane»**.
+
+**Установленный факт (опора, не изобретать):** канон презентации в репозитории **уже
+существует** — его ввела задача **ORCH-011** (витрина системы `docs/overview/`):
+
+- `docs/overview/presentation.md` — **слайдо-источник** (источник истины): 16 слайдов в
+  формате `## Слайд N: Заголовок` + 3–6 тезисов + опциональная подпись `> Визуал: …`.
+- `scripts/build_presentation.py` — dev-скрипт сборки **редактируемого `.pptx`** в тёмном
+  дизайне (`python-pptx`, ленивый импорт; чистый парсер `parse_slides` — stdlib-only).
+- `tests/test_system_docs.py` — анти-дрейф-контур, который машинно валидирует формат
+  слайдов, сквозную нумерацию, обязательные биты нарратива и процедуру сборки.
+
+Канон **намеренно** держит инварианты (ORCH-011 D4/D5, NFR-2): сборка идёт **вне рантайма
+платформы** (одноразовый dev-venv), `python-pptx` **не входит** в прод-образ, а **собранный
+`.pptx`-бинарь в git не коммитится** (`build/` в `.gitignore`).
+
+**Проблема (дельта ORCH-105):** текущая дека рассказывает про продукт в целом, но **не
+содержит** (а) выделенного слайда о том, как просто развернуть Lite-вариант скриптами, и
+(б) слайдов-инструкции для оператора «как вести задачу через Plane» (запуск, статусы,
+человеческие гейты, авто-лейблы, STOP, наблюдение). Задача — **дополнить существующий
+слайдо-источник** этим содержанием и убедиться, что `.pptx` собирается с новыми слайдами.
+Это **docs-only** доработка контента витрины: код рантайма не меняется.
+
+## 2. Объём (scope)
+
+### В объёме
+- **Расширить `docs/overview/presentation.md`:**
+  - добавить **один выделенный слайд про Lite-установку** (скрипт-ассистированный характер:
+    `gen_secrets.py` → секреты, `onboard_project.py` → регистрация проекта, `docker compose
+    up`, пошаговый runbook `LITE_SETUP.md` с проверкой каждого шага);
+  - добавить **2–3 слайда-инструкцию «как пользоваться орком через Plane»** (запуск задачи,
+    статусная модель «индикация ≠ управление», два человеческих гейта — Approved и Confirm
+    Deploy, авто-лейблы `autoApprove`/`autoDeploy`/`Bug`, отмена STOP, наблюдение за ходом);
+  - при необходимости — лёгкая актуализация продуктового нарратива на текущее состояние.
+- Сохранить **сквозную нумерацию слайдов с 1** (renumber при вставке в середину) и формат
+  (заголовок + 3–6 тезисов + опц. `> Визуал:`), а также раздел «Как собрать .pptx».
+- Убедиться, что `scripts/build_presentation.py` собирает валидный `.pptx`, включающий новые
+  слайды (скрипт менять **не требуется** — парсер обобщённый; правка только при крайней
+  необходимости).
+- **Расширить анти-дрейф** `tests/test_system_docs.py`: зафиксировать присутствие нового
+  обязательного контента (Lite-установка, использование через Plane).
+- Обновить `CHANGELOG.md` (запись `docs:`); при необходимости — указатель/маршрут в
+  `docs/overview/README.md`.
+
+### Вне объёма
+- **Коммит собранного `.pptx`-бинаря в git** — запрещён каноном ORCH-011 D5 (`build/`
+  в `.gitignore`); презентация собирается по требованию.
+- Добавление `python-pptx` в `requirements*`/`Dockerfile` (NFR-2; машинно запрещено тестом).
+- Кастомный графический дизайн/брендинг сверх существующего тёмного текстового шаблона
+  (визуалы — текстовые подписи `> Визуал: …`, а не растровые картинки).
+- Переписывание дизайна рендера (`build_pptx`), смена темы/шрифтов — если это не строго
+  необходимо.
+- Любые изменения рантайма: `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
+  схема БД — **не трогаются**.
+- Переписывание `business.md` и прочих тех-блоков витрины (описанные способности — тираж и
+  работа через трекер — там уже отражены; ORCH-105 добавляет именно **слайды**).
+- Создание отдельного монолитного «lite-инсталлятора» как нового скрипта (его нет; Lite
+  ставится комбинацией существующих скриптов и compose — см. §6).
+
+## 3. Заинтересованные стороны
+
+- **Заказчик / Owner** — постановщик задачи и **приёмщик** презентации; конечный
+  пользователь `.pptx` при показе стейкхолдерам.
+- **Потенциальные заказчики / менеджеры** — аудитория презентации (нетехнический и
+  полу-технический читатель).
+- **Операторы платформы** — целевые читатели слайдов «как пользоваться через Plane».
+- **Reviewer** — контролирует норматив сопровождения витрины (изменил витрину → согласовано,
+  факты не разъехались с golden sources; необновлённый сопутствующий док → finding ≥ P1).
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1** — Презентация о продукте в формате PowerPoint собирается из слайдо-источника
+  витрины и содержит связный рассказ о платформе (существующий нарратив сохранён и при
+  необходимости актуализирован).
+- **BR-2** — В презентации есть **выделенный слайд про Lite-установку**, точно отражающий её
+  скрипт-ассистированный характер: секреты генерирует `scripts/gen_secrets.py`, проект
+  регистрирует `scripts/onboard_project.py` (`plan`/`apply`/`verify`), стек поднимается
+  `docker compose`, а маршрут описан пошаговым runbook `LITE_SETUP.md` с проверкой каждого
+  шага. Без вымышленных артефактов/скриптов.
+- **BR-3** — В презентации есть **слайды-инструкция «как пользоваться орком через Plane»**,
+  покрывающие: запуск задачи (перевод в «To Analyse» — единственная точка входа), статусную
+  модель (индикация ≠ управление; управляющих статусов ровно три), **два человеческих гейта**
+  (Approved на `analysis`, Confirm Deploy на `deploy`), **авто-лейблы** (`autoApprove`/
+  `autoDeploy`/`Bug`), **отмену STOP**, и **наблюдение за ходом** (статусы доски + живая
+  карточка в Telegram + комментарии в задаче).
+- **BR-4** — Итоговый `.pptx` собирается документированной командой
+  (`scripts/build_presentation.py`) и включает **все** новые слайды; тёмный дизайн и
+  корректное отображение кириллицы сохранены.
+- **BR-5** — Содержание презентации **фактологически точно** и согласовано с golden sources
+  витрины (`tech-pipeline.md`, `tech-integrations.md`, `LITE_SETUP.md`, паспорт `CLAUDE.md`):
+  никаких выдуманных возможностей, имён статусов, лейблов или скриптов.
+- **BR-6** — Сопровождение выполнено в том же PR: `CHANGELOG.md` несёт запись `docs:` по
+  ORCH-105; норматив витрины (ORCH-011/079) соблюдён.
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 (self-hosting безопасность)** — изменение **docs-only**: `src/**`,
+  `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, схема БД — байт-в-байт не трогаются; `python-pptx`
+  **не попадает** в прод-образ; сборка `.pptx` — только вне рантайма (dev-venv).
+- **NFR-2 (анти-дрейф / совместимость формата)** — после правок `presentation.md` остаётся
+  валидной для канонического парсера `parse_slides` (сквозная нумерация с 1, ≥1 тезис на
+  слайд, непустые заголовки); **весь существующий** `tests/test_system_docs.py` — зелёный.
+- **NFR-3 (бинарь не в git)** — собранный `.pptx` не коммитится; `build/` остаётся в
+  `.gitignore`; артефакт сборки — по требованию.
+- **NFR-4 (гигиена)** — в слайдах **нет** боевых хост-литералов (FORBIDDEN-скан) и
+  секретоподобных значений (секрет-эвристика); относительные ссылки резолвятся.
+- **NFR-5 (стиль)** — новые слайды держат стиль деки: 3–6 тезисов, опц. подпись
+  `> Визуал: …`, тон и терминологию `business.md` (нетехнический язык для продуктовых слайдов;
+  оператор-инструкция — простыми шагами).
+
+## 6. Допущения и ограничения
+
+- **Форма поставки = воспроизводимая сборка.** Deliverable — **расширенный слайдо-источник +
+  скрипт сборки**; сам `.pptx` производится по требованию (ORCH-011 D5). Если нетехническому
+  стейкхолдеру нужен готовый файл — он **собирается командой и передаётся вне git** (например,
+  вложением к задаче Plane); это операционный шаг, не изменение кода. Это сознательное
+  следование действующему машинно-проверяемому канону, а не упущение.
+- **«Скрипт-установщик» для Lite** = фактические скрипты-помощники (`gen_secrets.py`,
+  `onboard_project.py`) + `docker compose` + verified-runbook `LITE_SETUP.md`. **Отдельного
+  монолитного lite-инсталлятора в репозитории нет**; одношаговый bootstrap (`bootstrap_bundle.py`)
+  относится к варианту **Bundled**, а не Lite. Заказчик явно просил **Lite** — слайд остаётся
+  точным к Lite (при желании можно одной строкой упомянуть Bundled-bootstrap как смежный
+  вариант, но фокус слайда — Lite).
+- **Рост деки.** С добавлением ~4 слайдов (1 Lite + 2–3 Plane) дека вырастает до ~19–20
+  слайдов. Это выше «ориентира 14–18» из ORCH-011 FR-4, но **проходит жёсткий тест** (`≥ 12`).
+  Рост оправдан явным запросом; финальное число и возможное слияние слайдов — на усмотрение
+  developer/architect (жёсткое требование — только сквозная нумерация и ≥ 12).
+- **Сборка/проверка `.pptx`** предполагает доступность `python-pptx` в dev-venv (вне рантайма).
+  **Автоматический гейт тестов проверяет ИСТОЧНИК** (`presentation.md`: парс/структура/контент),
+  а **не отрендеренный бинарь** — рендер проверяется **вручную** в dev-venv (честное
+  разграничение; см. 03/04).
+
+## 7. Критерии успеха
+
+Расширенный слайдо-источник собирается в `.pptx`; слайды Lite-установки и использования через
+Plane присутствуют, точны и согласованы с golden sources; сквозная нумерация и формат
+сохранены; весь `tests/test_system_docs.py` (с новыми проверками) зелёный; `python-pptx` не в
+прод-образе, бинарь не в git; `CHANGELOG`/витрина обновлены. Детальные PASS/FAIL —
+`03-acceptance-criteria.md`.
+
+## 8. Риски
+
+- **Ошибка перенумерации** при вставке слайдов в середину → падение проверки сквозной
+  нумерации (`parse_slides`).
+- **Дрейф фактов**: слайд расходится с реальной возможностью/именем (статус/лейбл/скрипт).
+- **Случайный запрещённый литерал/секрет** в тексте слайда → красный анти-дрейф.
+- **Неточная подача Lite** как монолитного инсталлятора (его нет) → вводящий в заблуждение
+  слайд.
+- **Раздувание деки** сверх читаемого объёма.
+
+Краткий перечень; детальная проработка и митигации — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,150 @@
+---
+work_item: ORCH-105
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-105 — Подготовка презентации по орку
+
+Work Item: **ORCH-105** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения — задача архитектора (06-adr).
+
+## 1. Сводка изменения
+
+**Docs-only** доработка контента витрины. Расширяем существующий слайдо-источник
+`docs/overview/presentation.md` (канон ORCH-011) тремя смысловыми блоками: (1) выделенный
+слайд про **Lite-установку** скриптами; (2) 2–3 слайда-инструкция **«как пользоваться орком
+через Plane»**; (3) при необходимости — точечная актуализация нарратива. Сохраняем формат и
+сквозную нумерацию слайдов, раздел сборки `.pptx` и тёмный дизайн. Дополняем анти-дрейф
+`tests/test_system_docs.py`, чтобы новый обязательный контент был зафиксирован машинно.
+Скрипт сборки `scripts/build_presentation.py` менять **не требуется** (парсер обобщённый).
+Рантайм (`src/**`, стадии, гейты, БД) — **не затрагивается**.
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `docs/overview/presentation.md` | **изменить** — добавить слайд Lite + 2–3 слайда Plane-usage; перенумеровать сквозно; сохранить раздел «Как собрать .pptx»; опц. актуализировать нарратив |
+| `tests/test_system_docs.py` | **изменить** — добавить assert'ы присутствия нового обязательного контента (Lite-установка, использование через Plane); существующие проверки сохранить зелёными |
+| `CHANGELOG.md` | **изменить** — запись `docs:` по ORCH-105 |
+| `docs/overview/README.md` | **опц.** — указатель/строка маршрута (если уместно); не обязателен |
+| `scripts/build_presentation.py` | **НЕ изменять** — `parse_slides` обобщён; правка только при крайней необходимости (тогда сохранить ленивый импорт `pptx` и stdlib-only top-level) |
+| `build/orchestrator-overview.pptx` | **НЕ коммитить** — артефакт сборки (`build/` в `.gitignore`, ORCH-011 D5) |
+| `requirements*.txt`, `Dockerfile` | **НЕ изменять** — `python-pptx` не добавлять (NFR-2) |
+
+## 3. Функциональные требования
+
+### FR-1 — Слайд про Lite-установку (BR-2)
+Добавить **один** слайд (формат `## Слайд N: <Заголовок>` + 3–6 тезисов + опц. `> Визуал:`),
+точно отражающий Lite-маршрут по `docs/deployment/LITE_SETUP.md`:
+- Lite = **два контейнера платформы** (`orchestrator` + `orchestrator-watchdog`) на
+  инфраструктуре заказчика; свои Plane / Gitea / Telegram / LLM подключаются (не входят в Lite).
+- Разворачивается **без правки кода — только конфиг** (принцип 10-common, ORCH-101).
+- Скрипты-помощники: `scripts/gen_secrets.py` (свежие секреты), `scripts/onboard_project.py`
+  (`plan`/`apply`/`verify` — регистрация проекта заказчика); подъём — `docker compose up -d`.
+- Маршрут — **пошаговый runbook** `LITE_SETUP.md` с **проверкой каждого шага** (PASS/FAIL).
+- **Рекомендуемое размещение:** сразу после текущего слайда «Тираж платформы» (обзор Lite/
+  Bundled) — как его углубление. Точная позиция — на усмотрение developer (требование жёсткое
+  только к сквозной нумерации).
+- **Точность (BR-5):** не называть Lite «одним монолитным инсталлятором»; одношаговый
+  bootstrap — это Bundled (`bootstrap_bundle.py`), упоминание опционально и как **смежный**
+  вариант.
+
+### FR-2 — Слайды «как пользоваться орком через Plane» (BR-3)
+Добавить **2–3** слайда оператор-инструкции, опираясь на `docs/overview/tech-pipeline.md`
+(человеческие гейты, STOP, статусная модель) и `tech-integrations.md` (Plane). Покрыть:
+- **Запуск:** перевод задачи в статус **«To Analyse»** — единственная точка входа в конвейер.
+- **Статусная модель:** статусы Plane — **индикация, не управление**; платформа сама их
+  выставляет; управляющих статусов ровно три (запуск, человеческие гейты, STOP).
+- **Два человеческих гейта:** **Approved** на `analysis` (одобрить постановку) и **Confirm
+  Deploy** на `deploy` (подтвердить прод-выкладку — отдельный статус, чтобы привычный approve
+  не выкатывал прод случайным кликом).
+- **Авто-лейблы:** `autoApprove` / `autoDeploy` (снимают человеческие гейты, пакетный
+  авто-режим — но **ни одна техническая проверка не пропускается**); `Bug` (багфикс-маршрут).
+- **Отмена:** статус **STOP** — безопасная отмена с уборкой (ветка/worktree), `cancelled`;
+  STOP не трогает `main`/прод-контейнер.
+- **Наблюдение за ходом:** платформа двигает статусы доски (Backlog → … → Done) + **живая
+  карточка в Telegram** (стадия, стоимость, время, кликабельный номер задачи) + комментарии в
+  задаче со ссылками на ветку/PR.
+- **Рекомендуемое размещение:** связным кластером после слайда «Человек в контуре» (он вводит
+  «два решения человека») и/или рядом со «Сценарии использования». Точная позиция — на
+  усмотрение developer.
+
+### FR-3 — Формат и сквозная нумерация (NFR-2)
+- Слайды нумеруются **сквозно с 1** без пропусков (вставка в середину ⇒ перенумеровать все
+  последующие). Это машинно-проверяемо: `tests/test_system_docs.py::
+  test_presentation_source_parses_with_canonical_parser` требует
+  `[s.number] == list(range(1, N+1))`.
+- Каждый новый слайд: **непустой заголовок** + **3–6 тезисов** (минимум — ≥1, требует тест) +
+  опц. одна строка `> Визуал: …`.
+- Раздел **«Как собрать .pptx»** сохранён (несёт `build_presentation.py` и маркеры «Проверка:»
+  — требует `test_presentation_carries_reproducible_build_procedure`).
+- Служебные `##`-заголовки (например, «Как собрать .pptx») не являются слайдами и завершают
+  предыдущий слайд (контракт `parse_slides`) — не вставлять контент слайдов после них.
+
+### FR-4 — Сборка `.pptx` с новыми слайдами (BR-4)
+Команда из канона (вне рантайма, dev-venv):
+```bash
+python3 -m venv .venv-pptx && .venv-pptx/bin/pip install python-pptx
+.venv-pptx/bin/python scripts/build_presentation.py
+```
+Ожидаемо: печать `Собрано слайдов: N → build/orchestrator-overview.pptx`, где `N` =
+фактическому числу слайдов источника (включая новые). Открытие `.pptx`: тёмная тема, светлый
+текст, акцентные заголовки, корректная кириллица, новые слайды присутствуют и редактируемы.
+**Это ручная проверка** (см. §6 — `python-pptx` нет в гейте тестов).
+
+### FR-5 — Анти-дрейф нового контента (NFR-2, BR-5)
+Расширить `tests/test_system_docs.py`, зафиксировав присутствие нового обязательного нарратива
+в `presentation.md`:
+- маркер **использования через Plane** (например, наличие подстроки уровня `plane` + признака
+  оператор-инструкции, по образцу `test_presentation_covers_mandatory_narrative_bits`);
+- маркер **Lite-установки** (например, `lite` / `установк`).
+Точные подстроки выбирает developer; цель — чтобы случайное удаление новых слайдов рвало CI.
+Все **существующие** проверки модуля остаются зелёными без послаблений.
+
+### FR-6 — Сопровождение (BR-6)
+- `CHANGELOG.md`: запись `docs:` по ORCH-105 (презентация дополнена слайдами Lite-установки и
+  использования через Plane).
+- Витрина: при изменении `presentation.md` норматив сопровождения ORCH-011/079 соблюдён;
+  reviewer сверяет факты с golden sources.
+
+## 4. Изменения API
+
+**Нет.** Эндпоинты (`/queue`, `/metrics`, вебхуки и пр.) не затрагиваются.
+
+## 5. Изменения схемы БД
+
+**Нет.** Таблицы/миграции/индексы не вводятся и не меняются.
+
+## 6. Требования к новым/изменённым QG checks
+
+**Нет нового гейта.** Презентация — артефакт витрины; новый Quality Gate не регистрируется
+(`QG_CHECKS` / `STAGE_TRANSITIONS` / `check_*` — байт-в-байт прежние). Контроль выполняется
+**существующими** механизмами:
+- `tests/test_system_docs.py` исполняется обычным тест-сьютом → попадает под `check_ci_green`
+  (выход из `development`) и `check_tests_passed` (стадия `testing`).
+- **Важное разграничение (честность гейта):** автоматический гейт проверяет **источник**
+  (`presentation.md`: парс, нумерация, обязательные биты, процедура сборки) и инвариант
+  «`python-pptx` не в прод-образе». **Сам рендер `.pptx`** в гейте **не выполняется** —
+  `python-pptx` отсутствует в прод/тест-образе по канону (ORCH-011 NFR-2), сборка — вне
+  рантайма в dev-venv (ручная проверка FR-4 / 04-test-plan TC-07).
+
+## 7. Совместимость / регресс
+
+- **Docs-only, нулевой рантайм-риск:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
+  схема БД — байт-в-байт не тронуты; kill-switch не нужен (нет рантайм-поведения).
+- **Self-hosting безопасно:** `python-pptx` не входит в прод-образ; сборка — вне рантайма;
+  собранный бинарь не коммитится (`build/` в `.gitignore`).
+- **Анти-дрейф сохранён:** `presentation.md` остаётся валидной для `parse_slides`; раздел
+  сборки и обязательные биты — на месте; новые проверки только **добавляют** покрытие.
+- **Воспроизводимая сборка:** канон ORCH-011 (источник → скрипт → `.pptx` по требованию) не
+  форкается; один парсер (`parse_slides`) — один источник истины о формате.
+- **Обратимость:** изменение полностью обратимо (revert правок `presentation.md` /
+  `test_system_docs.py` / `CHANGELOG.md`).
+- **Регресс-поверхность:** полный `pytest tests/ -q` остаётся зелёным (нет правок кода
+  рантайма).

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

@@ -0,0 +1,130 @@
+---
+work_item: ORCH-105
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-105 — Подготовка презентации по орку
+
+Work Item: **ORCH-105** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — Слайд про Lite-установку присутствует и точен
+
+**Условие:** `docs/overview/presentation.md` содержит выделенный слайд про Lite-установку.
+- **PASS:** есть слайд (блок `## Слайд N: …`), посвящённый Lite-установке, с тезисами,
+  отражающими: два контейнера платформы (`orchestrator` + `orchestrator-watchdog`),
+  развёртывание без правки кода (только конфиг), скрипты-помощники (`gen_secrets.py`,
+  `onboard_project.py`) и/или `docker compose`, пошаговый runbook `LITE_SETUP.md` с проверкой
+  шагов. Факты согласованы с `docs/deployment/LITE_SETUP.md`.
+- **FAIL:** слайда нет; ИЛИ слайд называет Lite «единым монолитным инсталлятором»/упоминает
+  несуществующий скрипт; ИЛИ путает Lite с Bundled; ИЛИ факты расходятся с `LITE_SETUP.md`.
+
+---
+
+## AC-2 — Слайды «как пользоваться орком через Plane» присутствуют и точны
+
+**Условие:** `presentation.md` содержит ≥ 2 слайда оператор-инструкции по работе через Plane.
+- **PASS:** ≥ 2 слайда покрывают (суммарно): запуск задачи («To Analyse»), статусную модель
+  «индикация ≠ управление», **оба** человеческих гейта (Approved на `analysis` и Confirm
+  Deploy на `deploy`), авто-лейблы (`autoApprove`/`autoDeploy`/`Bug`), отмену **STOP**,
+  наблюдение за ходом (статусы доски + живая Telegram-карточка + комментарии в задаче). Имена
+  статусов/лейблов точны и согласованы с `tech-pipeline.md`/`tech-integrations.md`/`CLAUDE.md`.
+- **FAIL:** слайдов нет или один; ИЛИ пропущен любой из двух человеческих гейтов; ИЛИ
+  перепутаны имена статусов/лейблов (напр. «Approved выкатывает прод»); ИЛИ утверждается, что
+  авто-лейблы пропускают технические проверки.
+
+---
+
+## AC-3 — Сквозная нумерация и формат слайдов валидны
+
+**Условие:** канонический парсер `parse_slides` разбирает источник без нарушений.
+- **PASS:** `tests/test_system_docs.py::test_presentation_source_parses_with_canonical_parser`
+  зелёный — слайдов ≥ 12, номера `[1..N]` строго сквозные, у каждого слайда непустой заголовок
+  и ≥ 1 тезис.
+- **FAIL:** тест падает — пропуск/дубль в нумерации, пустой заголовок, слайд без тезисов, или
+  слайдов < 12.
+
+---
+
+## AC-4 — Обязательный нарратив и процедура сборки сохранены + новые биты зафиксированы
+
+**Условие:** обязательные биты нарратива на месте; процедура сборки цела; новый контент
+анти-дрейф-защищён.
+- **PASS:** `test_presentation_covers_mandatory_narrative_bits` и
+  `test_presentation_carries_reproducible_build_procedure` зелёные (биты `проблем`/`решени`/
+  `конвейер`/`сценари`/`тираж`/`статус` присутствуют; раздел сборки несёт `build_presentation.py`
+  и «Проверка»). Добавлены проверки присутствия **Lite-установки** и **использования через
+  Plane**, и они зелёные.
+- **FAIL:** любой из этих тестов красный; ИЛИ новые биты Lite/Plane не покрыты тестом (можно
+  бесследно удалить новый слайд, CI не заметит).
+
+---
+
+## AC-5 — `.pptx` собирается с новыми слайдами (ручная dev-venv проверка)
+
+**Условие:** документированная сборка вне рантайма даёт валидный `.pptx`, включающий новые
+слайды.
+- **PASS:** в dev-venv `.venv-pptx/bin/python scripts/build_presentation.py` печатает
+  `Собрано слайдов: N → build/orchestrator-overview.pptx` (N = числу слайдов источника, включая
+  новые), `exit code 0`; открытый файл показывает тёмную тему, корректную кириллицу, новые
+  слайды Lite/Plane — присутствуют и редактируемы.
+- **FAIL:** скрипт печатает `ОШИБКА: …` / ненулевой код возврата; ИЛИ N не совпадает с числом
+  слайдов; ИЛИ новых слайдов нет в собранном файле; ИЛИ кириллица/тема сломаны.
+
+---
+
+## AC-6 — Анти-дрейф и гигиена витрины зелёные
+
+**Условие:** структурный контур витрины проходит целиком.
+- **PASS:** весь `tests/test_system_docs.py` зелёный, включая:
+  `test_showcase_carries_no_forbidden_host_literals` (нет боевых хост-литералов),
+  `test_showcase_carries_no_secret_like_values` (нет секретоподобных значений),
+  `test_all_relative_links_resolve_to_existing_files` (ссылки резолвятся),
+  `test_build_script_toplevel_imports_are_stdlib_only` (top-level скрипта без `pptx`).
+- **FAIL:** любой из перечисленных тестов красный (запрещённый литерал/секрет/битая ссылка/
+  `pptx` на top-level скрипта).
+
+---
+
+## AC-7 — Self-hosting безопасность: рантайм и образ нетронуты
+
+**Условие:** изменение остаётся docs-only.
+- **PASS:** `git diff` не содержит изменений в `src/**`, `STAGE_TRANSITIONS` (`src/stages.py`),
+  `QG_CHECKS`/`check_*` (`src/qg/checks.py`), схеме БД (`src/db.py`);
+  `test_no_pptx_dependency_in_prod_image` зелёный (`python-pptx` нет в `requirements*`/
+  `Dockerfile`); собранный `.pptx` **не** добавлен в git (`build/` в `.gitignore`).
+- **FAIL:** затронут любой рантайм-модуль/стадия/гейт/схема; ИЛИ `python-pptx` появился в
+  прод-образе; ИЛИ `.pptx`-бинарь закоммичен.
+
+---
+
+## AC-8 — Сопровождение выполнено в том же PR
+
+**Условие:** доки сопровождения обновлены.
+- **PASS:** `CHANGELOG.md` несёт запись `docs:` по ORCH-105; при изменении `presentation.md`
+  норматив витрины соблюдён; полный `pytest tests/ -q` зелёный.
+- **FAIL:** нет записи в `CHANGELOG.md`; ИЛИ полный регресс `tests/` красный.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-2 / FR-1 |
+| AC-2 | BR-3 / FR-2 |
+| AC-3 | NFR-2 / FR-3 |
+| AC-4 | BR-5 / FR-3 / FR-5 |
+| AC-5 | BR-4 / FR-4 |
+| AC-6 | NFR-4 / FR-5 |
+| AC-7 | NFR-1 / NFR-3 |
+| AC-8 | BR-6 / FR-6 |

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

@@ -0,0 +1,84 @@
+work_item: ORCH-105
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+title: "Презентация: слайды Lite-установки и использования через Plane (анти-дрейф витрины)"
+framework: pytest
+scope: >
+  Покрывается: структурная валидность слайдо-источника docs/overview/presentation.md после
+  добавления слайдов Lite-установки и использования через Plane (парс/нумерация/обязательные
+  биты/процедура сборки), фиксация нового контента анти-дрейф-тестом, гигиена витрины,
+  self-hosting-инварианты (python-pptx вне прод-образа, бинарь не в git), сопровождение
+  (CHANGELOG). Вне автоматического покрытия: фактический рендер .pptx через python-pptx —
+  выполняется ВНЕ рантайма в dev-venv (ORCH-011 NFR-2), поэтому TC-07 — ручной интеграционный
+  шаг, а не часть гейта тестов.
+notes: >
+  Изменение docs-only: src/** не трогается, новый QG не вводится. Тесты живут в существующем
+  модуле tests/test_system_docs.py (ORCH-011) — большинство TC расширяют/подтверждают уже
+  имеющиеся проверки. Полный регресс pytest tests/ -q должен оставаться зелёным. Имена статусов
+  Plane и лейблов в слайдах сверяются с docs/overview/tech-pipeline.md, tech-integrations.md и
+  CLAUDE.md (фактологическая точность, BR-5). TC-07 (сборка .pptx) — обязательная ручная
+  проверка в одноразовом dev-venv: python-pptx в прод/тест-образ НЕ добавляется.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "parse_slides разбирает presentation.md: слайдов >= 12, номера сквозные [1..N], у каждого непустой заголовок и >= 1 тезис (после добавления новых слайдов нумерация не разъехалась)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Обязательные биты нарратива присутствуют (проблем/решени/конвейер/сценари/тираж/статус) — существующая проверка остаётся зелёной после правок."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Новый контент зафиксирован анти-дрейфом: добавлены и зелёные assert'ы присутствия слайда Lite-установки (напр. lite/установк) и слайдов использования через Plane (напр. plane + признак оператор-инструкции)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Процедура сборки .pptx цела: presentation.md несёт ссылку на build_presentation.py и явные маркеры «Проверка:» (test_presentation_carries_reproducible_build_procedure)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Гигиена витрины: нет боевых хост-литералов (FORBIDDEN-скан) и нет секретоподобных значений в presentation.md после добавления слайдов."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Все относительные ссылки витрины (включая новые, если добавлены) резолвятся в существующие файлы (test_all_relative_links_resolve_to_existing_files)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "Ручной dev-venv шаг (вне рантайма, python-pptx): .venv-pptx/bin/python scripts/build_presentation.py печатает «Собрано слайдов: N» (N = числу слайдов), exit 0; открытый .pptx — тёмная тема, кириллица корректна, новые слайды Lite/Plane присутствуют и редактируемы."
+    module: docs/overview/presentation.md
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Self-hosting инвариант: python-pptx отсутствует в requirements*/Dockerfile (test_no_pptx_dependency_in_prod_image); top-level scripts/build_presentation.py остаётся stdlib-only (импорт pptx ленивый)."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Указатели репозитория: CHANGELOG.md несёт запись по ORCH-105 (запись docs:), витрина docs/overview/ по-прежнему достижима из README.md/CLAUDE.md."
+    module: tests/test_system_docs.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "Полный регресс pytest tests/ -q зелёный — изменение docs-only, рантайм-код не тронут, регрессии нет."
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-105/06-adr/ADR-001-presentation-lite-and-plane-usage-slides.md

@@ -0,0 +1,249 @@
+---
+work_item: ORCH-105
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Расширение слайдо-источника презентации — слайд Lite-установки и слайды «как пользоваться орком через Plane»
+
+Work Item: **ORCH-105** — Подготовка презентации по орку
+Стадия: **architecture**
+Сквозная регистрация: **N/A — локальное решение задачи.** Канон витрины и презентации уже
+зафиксирован сквозным `docs/architecture/adr/adr-0039-system-overview-docs-canon.md` (ORCH-011,
+D3/D4/D5). ORCH-105 **наполняет** этот канон контентом, **не меняя** его инвариантов → новый
+глобальный `adr-NNNN` не вводится. Анти-археология (3+ маркеров в код-блоке) не срабатывает —
+правок исполняемого кода нет.
+
+## Статус
+Proposed
+
+## Контекст
+
+Заказчику нужна продуктовая презентация орка (PowerPoint) с двумя новыми смысловыми блоками:
+(а) выделенный слайд про **Lite-установку скриптами** и (б) слайды-инструкция **«как
+пользоваться орком через Plane»** (запуск, статусы, человеческие гейты, авто-лейблы, STOP,
+наблюдение).
+
+**Опора, не изобретать (сверено по коду/доке):**
+
+- Слайдо-источник уже существует — `docs/overview/presentation.md` (16 слайдов в формате
+  `## Слайд N: Заголовок` + 3–6 тезисов + опц. `> Визуал:`), канон ORCH-011.
+- Сборка `.pptx` — `scripts/build_presentation.py`; формат парсит **чистая stdlib-функция**
+  `parse_slides` (один парсер — один источник истины о формате; её же импортирует тест-контур).
+- Анти-дрейф — `tests/test_system_docs.py` (валидирует структуру/нумерацию/обязательные биты
+  нарратива/процедуру сборки; FORBIDDEN-скан + секрет-эвристика; `pptx` не в прод-образе).
+- Канон **намеренно** держит инварианты (adr-0039 §3 «Канон презентации»; детальные D4/D5
+  work-item ADR-001 ORCH-011): сборка — **вне рантайма** (dev-venv), `python-pptx` **не** в
+  прод/тест-образе, собранный `.pptx` **не коммитится** (`build/` в `.gitignore`).
+
+**Факты для нового контента — golden sources (сверены):**
+
+- Lite — `docs/deployment/LITE_SETUP.md` (+ `tech-pipeline.md` §Тираж, adr-0037): Lite = **два
+  контейнера платформы** `orchestrator` + `orchestrator-watchdog` на инфре заказчика (свои
+  Plane/Gitea/Telegram/LLM подключаются, в Lite не входят); разворачивается **без правки кода —
+  только конфиг** (принцип 10-common ORCH-101); скрипты-помощники `scripts/gen_secrets.py`
+  (свежие секреты) и `scripts/onboard_project.py` (`plan`/`apply`/`verify` — регистрация
+  проекта), подъём `docker compose up -d`; маршрут — пошаговый runbook с **проверкой каждого
+  шага** (PASS/FAIL). Одношаговый bootstrap (`bootstrap_bundle.py`) — это **Bundled**, не Lite.
+- Plane-usage — `docs/overview/tech-pipeline.md` + `tech-integrations.md` + `CLAUDE.md`: вход —
+  статус **«To Analyse»** (единственная точка запуска); статусы Plane = **индикация, не
+  управление** (управляющих статусов ровно три); два человеческих гейта — **Approved** на
+  `analysis` и **Confirm Deploy** на `deploy`; авто-лейблы **autoApprove**/**autoDeploy**
+  (снимают только человеческие гейты — **ни одна техническая проверка не пропускается**) и
+  **Bug** (багфикс-маршрут); отмена — статус **STOP** → `cancelled` (не трогает `main`/прод);
+  наблюдение — статусы доски + **живая карточка в Telegram** + комментарии в задаче со ссылками
+  на ветку/PR.
+
+**Почему нужно архитектурное решение, а не просто «дописать слайды»:** дельта затрагивает три
+файла канона (`presentation.md`, `tests/test_system_docs.py`, `CHANGELOG.md`) и несёт реальные
+архитектурные развилки — рост деки за «ориентир 14–18», точная привязка каждого тезиса к golden
+source (риск фактдрейфа №1), форма анти-дрейфа нового контента без хрупкости и без нового гейта,
+и честная граница «что проверяет CI vs. что проверяется руками». Развилки зафиксированы ниже.
+
+## Решение
+
+### Сводка
+
+ORCH-105 — **docs-only расширение контента** слайдо-источника **внутри** канона adr-0039.
+Добавляем **ровно 3 слайда** (1 Lite + 2 Plane-usage), доводя деку 16 → **19 слайдов**;
+сохраняем сквозную нумерацию, формат, раздел сборки и тёмный дизайн. Каждый тезис привязан к
+golden source (D3). Анти-дрейф — **одна новая тест-функция** в существующем контуре (D4); новый
+QG **не** регистрируется. Рантайм (`src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, схема
+БД) — **байт-в-байт** не тронут. `07-infra-requirements.md` / `08-data-requirements.md` —
+**не применимы** (нет смены топологии и схемы БД).
+
+### D1 — Канон не форкается; новый компонент / гейт / глобальный ADR не вводятся
+
+Расширение целиком живёт в инвариантах adr-0039:
+
+- **Единственный источник истины о формате** — `parse_slides`; контент пишется под него (формат
+  слайда не меняется). Скрипт сборки **не правится** (парсер обобщён; правка — только при
+  крайней необходимости, тогда сохранить ленивый импорт `pptx` и stdlib-only top-level).
+- **Новый Quality Gate НЕ регистрируется** (TRZ §6): `QG_CHECKS` / `STAGE_TRANSITIONS` /
+  `check_*` / machine-verdict ключи — байт-в-байт. Контроль — существующими механизмами:
+  `tests/test_system_docs.py` исполняется обычным сьютом → попадает под `check_ci_green` (выход
+  из `development`) и `check_tests_passed` (стадия `testing`).
+- **Бинарь не в git, `python-pptx` не в прод-образе** (adr-0039 §3; NFR-1/NFR-3) — сохраняем.
+- **Локальность решения:** нет нового компонента/стадии/гейта/смены БД → сквозной `adr-NNNN`
+  не нужен; канон уже зафиксирован adr-0039. `docs/architecture/README.md` и `internals.md`
+  **не обновляются** (стадии/гейты/компоненты не затронуты).
+
+**Привязка:** BR-1, NFR-1, AC-7; TRZ §6/§7.
+
+### D2 — Структура деки и размещение (ограниченный рост, +3 → 19 слайдов)
+
+Рост деки ограничиваем **тремя** слайдами (анти-раздувание; BRD §6 явно допускает ~19–20 и
+проходит жёсткий пол `≥ 12`). **Рекомендуемая раскладка** (точные позиции — на усмотрение
+developer, жёсткое требование — только сквозная нумерация и ≥ 12):
+
+| Новый слайд | Якорь (после какого слайда) | Роль |
+|-------------|------------------------------|------|
+| **Запуск и ведение задачи через Plane** | после «Человек в контуре» (тек. №7) | оператор-инструкция: вход + статусная модель + наблюдение |
+| **Что решает человек: гейты, авто-режим, отмена** | сразу за предыдущим (кластер) | оператор-инструкция: 2 гейта + авто-лейблы + STOP |
+| **Lite-установка скриптами** | после «Тираж платформы» (тек. №14) | углубление обзорного слайда тиража |
+
+Итоговая нумерация (рекомендация): Plane-слайды → новые №8, №9; Lite-слайд → новый №17; всё
+последующее перенумеровать сквозно (deck = 19). **Инвариант FR-3:** вставка в середину ⇒
+перенумеровать **все** последующие слайды; `parse_slides`-тест требует `[1..N]` строго подряд.
+
+**Разграничение с существующими слайдами (анти-дубль; для reviewer):** новые Plane-слайды —
+**процедурная оператор-инструкция** («что делаете вы / что показывает платформа»), а не описание
+способностей. Они дополняют, не дублируют, capability-слайды «Человек в контуре» (№7),
+«Наблюдаемость» (тек. №11) и «Сценарии использования» (тек. №13). Lite-слайд — углубление
+обзорного «Тираж платформы» (тек. №14) до конкретного скрипт-маршрута.
+
+**Число Plane-слайдов = 2** (а не 3): 8 обязательных тем (запуск, статус-модель, 2 гейта,
+авто-лейблы, Bug, STOP, наблюдение) укладываются в 2 слайда по ≤ 6 тезисов. Если у developer
+тезисы перерастают лимит 6 — допустим 3-й Plane-слайд (тогда deck = 20; BRD §6 разрешает).
+
+**Привязка:** BR-2/BR-3, FR-1/FR-2/FR-3, AC-1/AC-2/AC-3.
+
+### D3 — Привязка каждого тезиса к golden source (анти-фактдрейф, BR-5)
+
+Фактдрейф — доминирующий риск (TR-2). **Норматив для developer:** каждый тезис нового слайда
+обязан выводиться из golden source ниже; **запрещены** выдуманные возможности, имена статусов,
+лейблов, скриптов.
+
+**Lite-слайд** ← `docs/deployment/LITE_SETUP.md` (первоисточник) + `tech-pipeline.md` §Тираж:
+- Lite = **два контейнера платформы** (`orchestrator` + `orchestrator-watchdog`); свои Plane /
+  Gitea / Telegram / LLM подключаются (в Lite не входят).
+- Разворачивается **без правки кода — только конфиг** (10-common, ORCH-101).
+- Скрипты-помощники: `scripts/gen_secrets.py` (секреты), `scripts/onboard_project.py`
+  (`plan`/`apply`/`verify`); подъём — `docker compose up -d`.
+- Маршрут — пошаговый runbook `LITE_SETUP.md` с проверкой **каждого** шага (PASS/FAIL).
+- **Точность (FAIL-условие AC-1):** НЕ называть Lite «единым монолитным инсталлятором»;
+  одношаговый `bootstrap_bundle.py` — это **Bundled**, упоминание опционально и как **смежный**
+  вариант (одной строкой, не как суть Lite).
+
+**Plane-слайд A «Запуск и ведение задачи через Plane»** ← `tech-integrations.md` §Plane +
+`tech-pipeline.md` §Статусная модель:
+- Запуск: перевод задачи в **«To Analyse»** — единственная точка входа в конвейер.
+- Статусная модель: статусы Plane — **индикация, не управление**; платформа выставляет их сама;
+  управляющих статусов ровно **три** (запуск, человеческие гейты, STOP).
+- Наблюдение: статусы доски (Backlog → … → Done) + **живая карточка в Telegram** (стадия,
+  стоимость, время, кликабельный номер задачи) + комментарии в задаче со ссылками на ветку/PR.
+
+**Plane-слайд B «Что решает человек: гейты, авто-режим, отмена»** ← `tech-pipeline.md`
+§Человеческие гейты + `CLAUDE.md` (ORCH-089/090/019):
+- Гейт 1 — **Approved** на `analysis` (одобрить постановку).
+- Гейт 2 — **Confirm Deploy** на `deploy` (подтвердить прод — отдельный статус, чтобы привычный
+  approve не выкатывал прод случайным кликом).
+- Авто-лейблы **autoApprove** / **autoDeploy** — снимают **только** человеческие гейты;
+  **ни одна техническая проверка не пропускается** (FAIL-условие AC-2 — обратное утверждение).
+- Лейбл **Bug** — багфикс-маршрут (короче, но все гейты исполняются).
+- **STOP** → `cancelled` — безопасная отмена с уборкой (рабочая ветка/worktree); **не трогает**
+  `main`/прод-контейнер.
+
+**Точность имён критична:** имена статусов/лейблов воспроизводить дословно
+(`To Analyse`/`Approved`/`Confirm Deploy`/`STOP`/`autoApprove`/`autoDeploy`/`Bug`). Reviewer
+сверяет факты с golden sources (BR-5; правило агентов №6 — необновлённая/расходящаяся витрина →
+finding ≥ P1).
+
+**Привязка:** BR-5, FR-1/FR-2, AC-1/AC-2.
+
+### D4 — Анти-дрейф нового контента: одна новая тест-функция, без хрупкости, без послаблений
+
+**Решение:** в `tests/test_system_docs.py` **добавить ровно одну** функцию (рекомендуемое имя
+`test_presentation_covers_lite_and_plane_usage_bits`), по образцу
+`test_presentation_covers_mandatory_narrative_bits` (lower-case подстрочный матч). Существующие
+функции — **байт-в-байт** (только добавление; NFR-2).
+
+Требования к выбору маркеров (чтобы тест ловил удаление слайда, но не был хрупким к
+переформулировке):
+- **Lite:** `lite` **и** маркер установки (`установк` / `разверн`).
+- **Plane-usage:** `plane` **и** оператор-маркер (например `to analyse` / `confirm deploy` /
+  `stop`). Точные подстроки — на усмотрение developer; выбирать **семантические корни**, не
+  целые фразы (анти-переобучение).
+- Матч — по lower-case тексту (как существующий бит-тест).
+- **Не** трогать пол `≥ 12` и сквозную нумерацию в
+  `test_presentation_source_parses_with_canonical_parser` — он уже покрывает счёт/формат.
+- Маркеры обязаны пережить `test_showcase_carries_no_forbidden_host_literals` (без боевых
+  хост-литералов) и `test_showcase_carries_no_secret_like_values` (без hex≥32/alnum≥40);
+  имена статусов/лейблов и `8500/8501` этим скан-ам не противоречат.
+
+**Цель (AC-4 FAIL-условие):** бесследное удаление нового слайда должно рвать CI.
+
+**Привязка:** BR-5, FR-5, NFR-2, AC-4.
+
+### D5 — Честная граница гейта: источник проверяется CI, рендер `.pptx` — вручную
+
+Автоматический контур проверяет **источник** (`presentation.md`: парс/нумерация/обязательные
+биты/процедура сборки) и инвариант «`python-pptx` не в прод-образе». **Сам рендер `.pptx` в
+гейте не выполняется** — `python-pptx` намеренно отсутствует в прод/тест-образе (adr-0039 §3,
+NFR-1). Сборка и визуальная проверка (тёмная тема, кириллица, новые слайды присутствуют и
+редактируемы) — **ручной dev-venv шаг** (FR-4 / AC-5 / тест-план TC-07). Это **сознательная
+честная граница**, а не пробел покрытия; tester обязан выполнить ручную сборку и зафиксировать
+исход. Ожидаемая печать: `Собрано слайдов: 19 → build/orchestrator-overview.pptx` (N = факт.
+числу слайдов), exit 0.
+
+**Привязка:** BR-4, FR-4, AC-5, NFR-1.
+
+## Альтернативы
+
+- **Форкнуть `build_presentation.py` / завести гейт, рендерящий `.pptx` в CI** — отвергнуто:
+  нарушает adr-0039 §3 и NFR-1 (`python-pptx` намеренно вне прод/тест-образа); оверинжиниринг
+  для контентной правки. Рендер остаётся ручным (D5).
+- **Закоммитить собранный `.pptx` для удобства стейкхолдера** — отвергнуто: adr-0039 §3 / NFR-3
+  (бинарь не в git). Поставка = воспроизводимая сборка; готовый файл собирается командой и
+  передаётся **вне git** (вложением к задаче Plane) — операционный шаг, не изменение кода
+  (BRD §6).
+- **Завести сквозной `adr-NNNN`** — отвергнуто: ничего сквозного не меняется (нет нового
+  компонента/гейта/стадии/смены БД); канон презентации уже держит adr-0039.
+- **Один объединённый слайд использования** — отвергнуто: AC-2 жёстко требует ≥ 2 слайда, а
+  8 обязательных тем переполняют лимит 6 тезисов одного слайда.
+- **3+ слайда Plane по умолчанию** — отвергнуто как дефолт (анти-раздувание): 2 слайда
+  достаточны; 3-й допустим лишь при переполнении тезисов (D2).
+
+## Последствия
+
+- **+** Дека получает оператор-применимый контент (Lite-маршрут + работа через Plane); каждый
+  факт CI-заякорен к golden source новой подстрочной проверкой (D4); нулевой рантайм-риск; для
+  enduro-trails инертно.
+- **+** Канон не форкается: один парсер `parse_slides` = один источник истины; анти-дрейф только
+  **добавляет** покрытие.
+- **−** Дека растёт до 19 (выше ориентира 14–18) — принято осознанно (BRD §6), ограничено **+3**;
+  митигировано плотной группировкой тезисов (D2) и порогом `≥ 12`, который не нарушается.
+- **−** Ручной рендер вне CI — принятая честная граница (D5); митигировано явным ручным шагом
+  AC-5 / TC-07 (исход фиксирует tester).
+- **− (риск перенумерации)** вставка в середину рвёт сквозную нумерацию при невнимательности —
+  митигировано тестом `test_presentation_source_parses_with_canonical_parser` (`[1..N]`) и явным
+  инвариантом FR-3 (см. TR-1).
+- **Применимость 07/08:** `07-infra-requirements.md` и `08-data-requirements.md` **не создаются**
+  — нет смены топологии и схемы БД (TRZ §4/§5).
+- **Откат:** полностью обратимо — revert правок `presentation.md` / `tests/test_system_docs.py` /
+  `CHANGELOG.md` (1:1, без миграций и состояния).
+
+## Ссылки
+
+- BRD: `docs/work-items/ORCH-105/01-brd.md`
+- TRZ: `docs/work-items/ORCH-105/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-105/03-acceptance-criteria.md`
+- Риски: `docs/work-items/ORCH-105/10-tech-risks.md`
+- Канон витрины/презентации (не меняется): `docs/architecture/adr/adr-0039-system-overview-docs-canon.md`
+- Golden sources контента: `docs/deployment/LITE_SETUP.md`, `docs/overview/tech-pipeline.md`,
+  `docs/overview/tech-integrations.md`, `CLAUDE.md`
+- Сверено по коду: `scripts/build_presentation.py` (`parse_slides`),
+  `tests/test_system_docs.py` (анти-дрейф витрины), `docs/overview/presentation.md` (источник)

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

@@ -0,0 +1,37 @@
+---
+work_item: ORCH-105
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-105 — Подготовка презентации по орку
+
+Work Item: **ORCH-105** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+> Решения — `06-adr/ADR-001-presentation-lite-and-plane-usage-slides.md`.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Ошибка перенумерации** при вставке слайдов в середину (пропуск/дубль номера) → падение сквозной нумерации. | Сред. | Низ. | Тест `test_presentation_source_parses_with_canonical_parser` требует `[1..N]` строго подряд → ловит мгновенно в CI; инвариант FR-3 явно выписан; ADR D2 даёт точную раскладку 19 слайдов. Откат — тривиальный revert. |
+| TR-2 | **Фактдрейф**: тезис расходится с реальной возможностью / именем статуса / лейбла / скрипта (напр. «Approved выкатывает прод», «autoApprove пропускает проверки», «Lite — монолитный инсталлятор»). | Сред. | Сред. | ADR D3 — построчная привязка к golden sources (`LITE_SETUP.md`/`tech-pipeline.md`/`tech-integrations.md`/`CLAUDE.md`) с дословными именами; новый бит-тест D4 фиксирует присутствие; reviewer сверяет факты (правило агентов №6 → finding ≥ P1). |
+| TR-3 | **Случайный запрещённый хост-литерал / секретоподобное значение** в тексте слайда → красный анти-дрейф. | Низ. | Низ. | Существующие `test_showcase_carries_no_forbidden_host_literals` (FORBIDDEN-импорт) и `test_showcase_carries_no_secret_like_values` (hex≥32/alnum≥40) ловят в CI; ADR D4 предписывает использовать только семантические корни/имена статусов; `8500/8501` явно безопасны (самочек эвристики). |
+| TR-4 | **Хрупкий или послабляющий анти-дрейф-тест**: переобучение на целую фразу (рвётся при переформулировке) ИЛИ ослабление существующих проверок. | Сред. | Низ. | ADR D4 — ровно одна новая функция по образцу `..._mandatory_narrative_bits`, матч по семантическим корням, существующие функции байт-в-байт; пол `≥ 12` и нумерация не трогаются. |
+| TR-5 | **Раздувание деки** сверх читаемого объёма (соблазн добавить >3 слайда). | Низ. | Низ. | ADR D2 ограничивает рост **+3** (deck = 19; 3-й Plane-слайд — только при переполнении лимита 6 тезисов); BRD §6 допускает ~19–20; жёсткий пол `≥ 12` не нарушается. |
+| TR-6 | **Случайная правка рантайма / попадание `python-pptx` в прод-образ / коммит `.pptx`-бинаря** → нарушение self-hosting-инварианта. | Низ. | Выс. | Docs-only по ТЗ; `git diff` не должен затрагивать `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/схему БД (AC-7); `test_no_pptx_dependency_in_prod_image` + `build_script_toplevel_imports_are_stdlib_only` зелёные; `build/` в `.gitignore`. Скрипт сборки не правится (ADR D1). |
+| TR-7 | **Ложное ощущение покрытия рендера**: рендер `.pptx` в CI не выполняется (нет `python-pptx`), визуальный дефект (битая кириллица/тема/отсутствие слайда) проходит мимо автогейта. | Сред. | Низ. | ADR D5 — честная граница: рендер проверяется **вручную** в dev-venv (FR-4/AC-5/TC-07), исход фиксирует tester; печать `Собрано слайдов: N → …` сверяется с числом слайдов источника. |
+
+## Сводный вывод
+
+Доминирующий класс — **риски точности контента** (TR-1, TR-2): чисто документарные, ловятся
+существующим + одним новым структурным тестом и сверкой reviewer с golden sources; остаточный
+риск низкий. Рантайм-класс (TR-6) теоретически высоковлияющий, но вероятность минимальна —
+изменение docs-only по конструкции, накрыто машинными гардами витрины (AC-7) и инвариантами
+adr-0039. **Эскалация `arch:major-change` не требуется; возврат в анализ не требуется.** Для
+прод-конвейера (self-hosting) и для enduro-trails изменение инертно: `src/**`, стадии, гейты,
+схема БД — байт-в-байт; `python-pptx` вне прод-образа; собранный бинарь не коммитится.

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

@@ -0,0 +1,116 @@
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-105
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-105
+version: 1
+---
+
+# Review ORCH-105 — Подготовка презентации по орку (слайды Lite-установки и использования через Plane)
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter. `APPROVED` → дальше по конвейеру.
+
+## Summary
+
+**Docs-only** доработка витрины: слайдо-источник `docs/overview/presentation.md` расширен **тремя**
+слайдами в каноне ORCH-011 (дека 16 → 19, сквозная нумерация цела), добавлена **одна** анти-дрейф
+тест-функция в `tests/test_system_docs.py`, обновлён `CHANGELOG.md`. Реализация **полностью**
+соответствует ТЗ (`02-trz.md`), критериям приёмки (`03-acceptance-criteria.md`) и
+`06-adr/ADR-001`. Рантайм (`src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, схема БД) —
+байт-в-байт не тронут. Факты новых слайдов сверены с golden sources. Весь
+`tests/test_system_docs.py` — **зелёный (29 passed)**. P0/P1 findings нет → **APPROVED**.
+
+> **Замечание по среде ревью (не finding):** локальный `main` устарел (`9b7bdc0`), поэтому
+> `git diff main...HEAD` ложно тянул уже смерженный контент ORCH-011. Достоверный диф снят против
+> `origin/main` (`4d5e461`) — он чистый: `CHANGELOG.md`, `presentation.md`, `tests/test_system_docs.py`
+> + артефакты `docs/work-items/ORCH-105/`. Никаких чужих правок в PR нет.
+
+## Оси проверки
+
+### 1. Соответствие ТЗ / Acceptance Criteria — PASS
+- **FR-1 / AC-1 (Lite-слайд):** добавлен «Слайд 17: Lite-установка скриптами». Тезисы точны и
+  согласованы с `docs/deployment/LITE_SETUP.md`: два контейнера платформы (`orchestrator` +
+  `orchestrator-watchdog`), развёртывание без правки кода (только конфиг), помощники
+  `gen_secrets.py`/`onboard_project.py` (`plan`/`apply`/`verify`) + `docker compose up -d`, runbook
+  с проверкой каждого шага. **BR-5 соблюдён:** одношаговый bootstrap явно отнесён к **смежному
+  Bundled, не Lite** (нет «монолитного инсталлятора», нет выдуманных скриптов).
+- **FR-2 / AC-2 (Plane-usage):** добавлены **два** оператор-слайда («Слайд 8: Запуск и ведение
+  задачи через Plane», «Слайд 9: Что решает человек: гейты, авто-режим, отмена»). Покрыты все 8
+  обязательных тем: запуск «To Analyse», «индикация ≠ управление», **оба** человеческих гейта
+  (`Approved` на анализе и `Confirm Deploy` на деплое), авто-лейблы `autoApprove`/`autoDeploy`/`Bug`,
+  отмена `STOP`, наблюдение (статусы доски + Telegram-карточка + комментарии со ссылками на
+  ветку/PR). Имена статусов/лейблов **дословно** сверены с `tech-pipeline.md` (стр. 65/68/97) и
+  `tech-integrations.md` (стр. 8/13). Инвариант «авто-режим не пропускает техпроверки» зафиксирован
+  верно.
+- **FR-3 / AC-3 (нумерация/формат):** заголовки слайдов строго сквозные `1..19`, `## Как собрать
+  .pptx` остаётся служебным разделом (не слайд). `test_presentation_source_parses_with_canonical_parser`
+  — зелёный (≥12, `[1..N]`, непустые заголовки, ≥1 тезис).
+- **FR-5 / AC-4 (анти-дрейф):** добавлена `test_presentation_covers_lite_and_plane_usage_bits`,
+  фиксирующая `lite`+маркер установки и `plane`+`to analyse`/`approved`/`confirm deploy`/`stop`.
+  Существующие проверки нарратива и процедуры сборки — без послаблений, зелёные.
+- **FR-6 / AC-8 (сопровождение):** запись `docs:` по ORCH-105 в `CHANGELOG.md` присутствует и
+  содержательна; норматив витрины ORCH-011/079 соблюдён (PR сам и есть обновление витрины).
+
+### 2. Соответствие ADR / инвариантам — PASS
+- Реализация 1:1 c `06-adr/ADR-001`: ровно 3 слайда (2 Plane + 1 Lite), дека 16→19, **одна** новая
+  тест-функция, новый QG **не** регистрируется, скрипт `build_presentation.py` **не** правится
+  (подтверждено: вне дифа), `07/08`-доки не создаются (нет смены топологии/схемы БД).
+- Канон витрины `adr-0039` не форкается; локальность решения обоснована (глобальный `adr-NNNN` не
+  нужен) — корректно.
+- **Трассировка (TRACEABILITY):** исполняемый код с маркерами `ORCH-NNN` не затронут (docs/tests
+  only) → инварианты конвейера не задеты, анти-археология не срабатывает.
+
+### 3. Качество кода — PASS
+- Новая тест-функция **содержательна** (не тривиальна): проверяет присутствие конкретных имён
+  статусов/лейблов, несёт docstring с привязкой к FR-5/AC-4 и предупреждением об анти-переобучении.
+- Багфикс-трек (ORCH-019/BR-4) **не применим** — задача не `Bug`, регресс-тест-фиксатор не требуется.
+- Маркеры теста проходят `FORBIDDEN`-скан и секрет-эвристику (весь модуль зелёный).
+
+### 4. Документация — PASS (см. раздел «Документация»)
+
+### 5. Совместимость / регресс / self-hosting — PASS
+- `git diff origin/main...HEAD -- 'src/**'` пуст → рантайм, стадии, гейты, схема БД не тронуты.
+- `python-pptx` в прод-образ не добавлен; `build/` в `.gitignore` (стр. 19); новый `.pptx`-бинарь
+  не закоммичен (`docs/PRODUCT_VISION.pptx` — преэкзистент, вне дифа PR).
+- Изменение полностью обратимо.
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice-to-have (не блокирует)
+- Анти-дрейф `assert "stop" in low` ловит подстроку `stop`, которая встречается и в визуале
+  слайда 9; для большей устойчивости к точечному удалению блока STOP можно было бы матчить
+  `«STOP»`/`stop` в связке с маркером отмены. Решение D4 осознанно выбрало семантические корни
+  (анти-переобучение) — приемлемо, правка не требуется.
+
+## Документация
+
+**Обновлена корректно и в том же PR.** Этот PR сам является обновлением витрины `docs/overview/`
+(презентация — артефакт витрины ORCH-011). Проверено:
+- `CHANGELOG.md` — запись `docs:` по ORCH-105 присутствует. ✅
+- Витрина `docs/overview/presentation.md` — расширена; факты сверены с golden sources
+  (`docs/deployment/LITE_SETUP.md`, `docs/overview/tech-pipeline.md`,
+  `docs/overview/tech-integrations.md`, `CLAUDE.md`) — расхождений нет. ✅
+- `README.md` «Известные ограничения» (ORCH-079) — данный PR ни одного пункта не закрывает
+  (контентная правда о уже существующей функциональности), обновление не требуется. ✅
+- Прочие тех-блоки `docs/overview/tech-*.md`, `docs/architecture/README.md`/`internals.md` — новой
+  функциональности нет, обновлять нечего (правка только наполняет витрину контентом). ✅
+- `src/` не изменён → P0-условие «`src/` изменён, документация не обновлена» **не наступает**.
+
+**Замечание для tester:** AC-5 (ручная dev-venv сборка `.pptx`, ожидается
+`Собрано слайдов: 19 → build/orchestrator-overview.pptx`, exit 0, тёмная тема/кириллица/новые
+слайды) — ручной шаг стадии `testing` (TC-07), вне автоматического гейта по канону (`python-pptx`
+не в тест-образе). Это сознательная честная граница (ADR D5), не пробел покрытия.

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

@@ -0,0 +1,67 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-105
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-105
+---
+
+# Test Report — ORCH-105 — Подготовка презентации по орку
+
+> Машинный вердикт читается ТОЛЬКО из `result:` во frontmatter. `PASS` → задача переходит на
+> `deploy-staging`.
+
+## Окружение
+- 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-105-/` (ветка `feature/ORCH-105-`)
+- Дата: 2026-06-12
+
+## Smoke API (read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — **OK**
+- `GET /status` → активные задачи перечислены, задача ORCH-105 (id 93) в стадии `testing` — **OK**
+- `GET /queue` → блок `serial_gate` присутствует (**True**), блок `auto_labels` присутствует
+  (**True**) — регресса смока нет — **OK**
+
+## Покрытие ТЗ (каждый TC из 04-test-plan.yaml ↔ 03-acceptance-criteria.md)
+
+| TC ID | Тип | Описание | AC | Результат |
+|-------|-----|----------|----|-----------|
+| TC-01 | unit | `parse_slides` разбирает `presentation.md`: слайдов 19 (≥12), номера сквозные `[1..19]`, у каждого непустой заголовок + ≥1 тезис (`test_presentation_source_parses_with_canonical_parser`) | AC-3 | PASS |
+| TC-02 | unit | Обязательные биты нарратива (проблем/решени/конвейер/сценари/тираж/статус) — `test_presentation_covers_mandatory_narrative_bits` | AC-4 | PASS |
+| TC-03 | unit | Новый контент зафиксирован анти-дрейфом: Lite-установка + использование через Plane — `test_presentation_covers_lite_and_plane_usage_bits` | AC-4 | PASS |
+| TC-04 | unit | Процедура сборки `.pptx` цела (`build_presentation.py` + «Проверка:») — `test_presentation_carries_reproducible_build_procedure` | AC-4 | PASS |
+| TC-05 | unit | Гигиена витрины: нет хост-литералов (`test_showcase_carries_no_forbidden_host_literals`) и секретоподобных значений (`test_showcase_carries_no_secret_like_values`) | AC-6 | PASS |
+| TC-06 | unit | Все относительные ссылки витрины резолвятся — `test_all_relative_links_resolve_to_existing_files` | AC-6 | PASS |
+| TC-07 | integration | Ручной dev-venv build: `build_presentation.py` → `Собрано слайдов: 19 → build/orchestrator-overview.pptx`, exit 0, валидный 56 КБ `.pptx` (N=19 = числу слайдов). Визуальная проверка темы/кириллицы — human-only, скрипт отработал чисто | AC-5 | PASS |
+| TC-08 | unit | Self-hosting инвариант: `python-pptx` отсутствует в `requirements*`/`Dockerfile` (`test_no_pptx_dependency_in_prod_image`); top-level `build_presentation.py` stdlib-only (`test_build_script_toplevel_imports_are_stdlib_only`) | AC-7 | PASS |
+| TC-09 | unit | `CHANGELOG.md` несёт запись `docs:` по ORCH-105; витрина `docs/overview/` достижима из README/CLAUDE (`test_changelog_has_orch_011_entry`, `test_repo_readme_links_overview`, `test_claude_md_carries_overview_pointer_and_normative`) | AC-8 | PASS |
+| TC-10 | integration | Полный регресс `pytest tests/` зелёный — **1874 passed** | AC-8 | PASS |
+
+**Итог покрытия:** все 10 TC выполнены и сопоставлены с AC-1…AC-8. Дополнительно подтверждено:
+- **AC-1/AC-2** (контент Lite-слайда и Plane-usage слайдов) — структурно зафиксированы TC-03
+  (`test_presentation_covers_lite_and_plane_usage_bits`), фактологическая сверка — в `12-review.md`
+  (вердикт `APPROVED`).
+- **AC-7** (docs-only): `git diff origin/main...HEAD` не содержит изменений `src/**` —
+  затронуты только `docs/**`, `CHANGELOG.md`, `tests/test_system_docs.py`; `build/`-артефакт
+  `.pptx` не закоммичен (gitignored), `python-pptx` не добавлен в прод-образ.
+
+## Вывод pytest
+
+```
+tests/test_system_docs.py ... 29 passed (включая test_presentation_covers_lite_and_plane_usage_bits)
+...
+================== 1874 passed, 1 warning in 74.80s (0:01:14) ==================
+```
+(Единственный warning — преэкзистентный `PydanticDeprecatedSince20` в `src/config.py:8`, не
+связан с ORCH-105.)
+
+## Итог
+**PASS** — полный регресс `pytest tests/` зелёный (1874 passed), smoke read-only OK
+(`serial_gate` + `auto_labels` в `/queue` присутствуют), каждый TC `04-test-plan.yaml` выполнен и
+сопоставлен с критериями `03-acceptance-criteria.md`, изменение остаётся docs-only (рантайм/образ
+нетронуты). Задача готова к переходу на `deploy-staging`.

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

@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-105
+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-105/15-staging-log.md

@@ -0,0 +1,43 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-105
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-12
+model_used: claude-opus-4-8
+timestamp: 2026-06-12T05:18:22Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance (port 8501),
+run canonically inside the container (`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.**
+
+All REAL checks green; the two failures are known sandbox-infra checks (C9a/C9b), waived
+under ORCH-061 (`staging_infra_tolerance_enabled=True`). They depend on SANDBOX bot accounts
+being project members, not on the pipeline.
+
+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) |
+
+Staging gate passed → pipeline may advance to `deploy`.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH: timeout budgets + launch-time model telemetry for developer/reviewer
+
+Work Item ID: ORCH-109
+
+## Description
+
+TBD

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

@@ -0,0 +1,167 @@
+---
+work_item: ORCH-109
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
+
+Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Инцидент **ORCH-104** (runs 658/659/660, прод-watchdog 1800s) вскрыл **два независимых дефекта**
+в подсистеме запуска агентов и телеметрии:
+
+**Дефект A — недостаточный wall-clock бюджет для тяжёлых ролей.**
+Агенты `developer` и `reviewer` на сложных задачах **честно** упираются в общий тайм-аут
+`agent_timeout_seconds = 1800` и убиваются watchdog'ом (`launcher._watchdog → stop_process`,
+exit 143 / -9). Этот тайм-аут — единый для ВСЕХ ролей, хотя `developer` (effort `xhigh`,
+кодирующая роль) и `reviewer` объективно требуют больше времени, чем механические роли
+(`tester`/`deployer`, effort `medium`). Существует механизм per-agent override
+(`_resolve_timeout` + `agent_timeout_overrides_json`), но в проде он пуст → все роли получают 1800s.
+
+**Дефект B — потеря модели в телеметрии при оборванном прогоне.**
+Модель агента (`agent_runs.model`) пишется **только постфактум** — из финального usage-JSON
+прогона в `launcher._monitor_agent → usage.record_usage` (`_extract_model`). Убитый по тайм-ауту
+прогон **не успевает эмитить финальный JSON** → `_extract_model` возвращает `None` →
+`record_usage` пишет `model=COALESCE(None, model)` = остаётся **NULL**. В результате карточка
+Telegram-трекера (`notifications._stage_line`) и снимок `GET /metrics`/`GET /queue`
+(`db.get_running_agents`) показывают `model=null` именно тогда, когда что-то пошло не так — в
+момент, когда модель/эффорт критичны для разбора инцидента.
+
+Существующий прецедент уже решает половину задачи: **эффорт стампится в момент launch**
+(`launcher._spawn`, ORCH-087, `UPDATE agent_runs SET effort=?`), потому что CLI его в result-JSON
+не возвращает. Модель резолвится в той же точке (`resolve_agent_model`, строка 559), но **в БД на
+launch не пишется** — стампится только эффорт. ORCH-109 распространяет ту же гарантию на модель.
+
+**Сопутствующие проверки (производные от A и B):**
+- Поведение оборванного (timeout-killed) прогона в трекере и status-комментариях: модель и эффорт
+  должны быть видны даже если финальный JSON не записан.
+- Нужен ли отдельный guard: не пускать timeout-killed `developer`/`reviewer` автоматически дальше
+  по конвейеру (`development → review`, `review → testing`) без явного salvage-режима.
+
+**Установленные факты (по коду, не изобретать):**
+- `agent_runs.model` — колонка `TEXT` (NULLABLE), уже существует (`db._ensure_column`); **миграция
+  не нужна**.
+- `record_usage` уже использует `model=COALESCE(?, model)` — то есть постфактум-парс уже
+  **сохраняет** ранее проставленное значение и не затирает его `NULL`'ом. Не хватает только
+  записи на launch.
+- `_resolve_timeout(agent)` уже умеет per-agent override через `agent_timeout_overrides_json`;
+  малформный JSON → откат на глобальный дефолт + лог (never-break).
+- Кросс-инвариант reaper: `reaper_max_running_s = 3600` с зафиксированным в `config.py` правилом
+  «MUST be > max agent_timeout + grace» (Tier-3 backstop job-reaper'а, ORCH-065).
+
+## 2. Объём (scope)
+
+### В объёме
+- **Launch-time стамп модели:** записывать резолвенную `resolve_agent_model(...)` в
+  `agent_runs.model` в момент launch (`launcher._spawn`), рядом со стампом эффорта (ORCH-087).
+- **Конфигурируемый поднятый wall-clock бюджет для `developer` и `reviewer`** через config-override,
+  **без изменения** бюджета остальных ролей (`analyst`/`architect`/`tester`/`deployer`).
+- **Сохранение постфактум-enrich:** `usage.record_usage` остаётся источником обогащения
+  модели/токенов/стоимости из usage-JSON, но **перестаёт быть единственным источником истины** о
+  модели (launch-стамп — первичный, JSON — уточняющий).
+- **Видимость при timeout/kill:** строка стадии трекера и status-комментарии показывают реальные
+  модель + эффорт для оборванного прогона (model не `null`).
+- **Guard анти-salvage:** гарантия (и регресс-тест), что timeout-killed прогон
+  (`exit_code != 0`, в т.ч. -9/-15/143) **не продвигает** стадию автоматически в следующую без
+  явного решения.
+- **Обновление документации/комментариев** по конфигу тайм-аутов (`config.py`, `.env.example`).
+- **Тесты**, покрывающие все перечисленные FR.
+
+### Вне объёма
+- Изменение model-routing: все 6 агентов остаются на `claude-opus-4-8` (ORCH-41 G3 не включается).
+- Любые изменения `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей / схемы БД
+  (колонка `agent_runs.model` уже есть — миграции нет).
+- Изменение тайм-аута для ролей кроме `developer`/`reviewer`.
+- **Salvage / возобновление** недоделанной работы убитого прогона (поднять «как было», дописать,
+  переиспользовать частичный результат) — в объёме ТОЛЬКО гарантия не-продвижения, не salvage.
+- Изменения транспорта Telegram/Plane (`send_telegram`/комментарии) — только использование уже
+  доступных полей.
+- Перезапуск/деплой прод-контейнера в рамках задачи (self-hosting безопасность).
+
+## 3. Заинтересованные стороны
+
+- **Заказчик/Owner (Слава)** — инициатор; нуждается в надёжной телеметрии для разбора инцидентов и
+  в адекватных бюджетах тяжёлых ролей при пакетном автономном прогоне (эпик ORCH-088).
+- **Оператор self-hosting** — потребитель карточки трекера и `GET /metrics`/`GET /queue`; без модели
+  в карточке теряет ключевой контекст инцидента.
+- **Сам конвейер (self-hosting)** — затрагивается поведение запуска агентов; общий прод-инстанс
+  обслуживает и enduro-trails (тайм-аут — глобальная per-agent настройка, не repo-scoped).
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1** — Резолвенная модель агента сохраняется в `agent_runs.model` **в момент launch**, рядом
+  с эффортом, а не только постфактум из usage-JSON. Значение присутствует на строке прогона с
+  момента запуска и переживает любой исход прогона.
+- **BR-2** — Постфактум-парс usage/model (`usage.record_usage`) сохраняется как **обогащение**, но
+  **не как единственный источник истины**: при отсутствии/обрыве финального JSON launch-стамп модели
+  не теряется.
+- **BR-3** — Wall-clock тайм-аут для `developer` и `reviewer` поднимается и **настраивается через
+  config-override**, **без изменения** тайм-аута остальных ролей; механизм покрыт тестом/проверкой.
+- **BR-4** — При timeout/kill (оборванный прогон без финального JSON) строка стадии в трекере и
+  status-комментарии показывают **реальную модель (не `null`) и эффорт**.
+- **BR-5** — Timeout-killed прогон `developer`/`reviewer` **не продвигается** автоматически на
+  следующую стадию без явного salvage-режима; поведение зафиксировано регресс-тестом. (Анализ
+  определяет, нужен ли отдельный guard поверх существующей гарантии «advance только при чистом
+  exit + зелёный QG».)
+- **BR-6** — Документация и комментарии по конфигу тайм-аутов обновлены (паспорт изменения внутри
+  `config.py` + `.env.example`).
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — Обратная совместимость / нулевая регрессия.** Стамп модели аддитивен (колонка уже
+  существует, миграции нет). Дефолтный тайм-аут ролей, кроме `developer`/`reviewer`, не меняется;
+  при пустом override-конфиге поведение байт-в-байт прежнее.
+- **NFR-2 — never-raise / never-break.** Сбой стампа модели (ошибка БД) **не блокирует** launch
+  (та же `try/except`-изоляция, что у стампа эффорта). Малформный/невалидный timeout-конфиг →
+  откат на глобальный дефолт + WARNING, прогон не падает.
+- **NFR-3 — Неприкосновенность контрактов.** `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
+  machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+  `coverage_status:`), схема БД — **не трогаются**.
+- **NFR-4 — Сохранение reaper-инварианта.** Любой поднятый бюджет `developer`/`reviewer` обязан
+  сохранять `reaper_max_running_s > max(резолвенный тайм-аут любого агента) + agent_kill_grace_seconds`
+  (Tier-3 backstop ORCH-065); иначе job-reaper может реапнуть **здоровый** долгоиграющий прогон до
+  срабатывания его собственного watchdog'а. Если новый бюджет нарушает неравенство —
+  `reaper_max_running_s` поднимается синхронно (решение архитектора).
+- **NFR-5 — Self-hosting безопасность.** Изменение не рестартит/не роняет прод-контейнер, не
+  трогает deploy-путь, безопасно для общего инстанса (enduro-trails не затронут негативно).
+- **NFR-6 — Наблюдаемость in-flight.** Модель становится видна в `GET /metrics`/`GET /queue`
+  (`db.get_running_agents`) **во время** прогона, а не только после завершения (побочное улучшение
+  launch-стампа).
+
+## 6. Допущения и ограничения
+
+- Тайм-аут — **глобальная per-agent** настройка (не repo-scoped): поднятие бюджета
+  `developer`/`reviewer` действует на все репо. Для enduro это благоприятно/нейтрально.
+- Колонка `agent_runs.model` уже существует и NULLABLE — повторная запись/COALESCE безопасны.
+- CLI не возвращает effort в result-JSON (причина launch-стампа эффорта ORCH-087); модель в JSON
+  возвращается, но только при успешном финале — отсюда необходимость launch-стампа модели.
+- Точные числовые значения новых бюджетов (`developer`/`reviewer`) и способ их конфигурации
+  (выделенные ключи vs `agent_timeout_overrides_json`) — решение архитектора/Owner в рамках FR-3;
+  BRD фиксирует только **способность + инвариант NFR-4 + тест**.
+- Salvage недоделанной работы — отдельная возможность, вне этой задачи.
+
+## 7. Критерии успеха
+
+Модель агента видна (не `null`) в трекере, status-комментариях и `/metrics` для ЛЮБОГО исхода
+прогона, включая timeout-kill; бюджеты `developer`/`reviewer` подняты и конфигурируемы без влияния
+на прочие роли и без нарушения reaper-инварианта; timeout-killed прогон не «протекает» в следующую
+стадию; всё покрыто тестами; конфиг задокументирован. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+
+- **R-1** — Поднятие бюджета выше `reaper_max_running_s − grace` → ложный reap здорового прогона
+  (NFR-4). Митигируется sanity-тестом конфига и/или синхронным поднятием `reaper_max_running_s`.
+- **R-2** — Постфактум-enrich затирает корректный launch-стамп при странном JSON. Митигируется
+  семантикой COALESCE (NULL не затирает) + тестом enrich-кейсов.
+- **R-3** — Гонка двух писателей `exit_code` (`_record_kill` = -9 и `_monitor_agent` = `proc.wait()`)
+  не должна влиять на телеметрию модели (модель — отдельная колонка). Подтверждается тестом FR-4.
+- **R-4** — Глобальность тайм-аута: поднятие для enduro-developer могло бы маскировать зависший
+  прогон. Митигируется тем, что Tier-3 backstop reaper'а сохраняется (NFR-4).
+
+Детали рисков и архитектурные трейд-оффы — `10-tech-risks.md` (заполняет архитектор).