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

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

.env.example

@@ -24,6 +24,19 @@ ORCH_PLANE_BOT_REVIEWER=
 ORCH_PLANE_BOT_TESTER=
 ORCH_PLANE_BOT_DEPLOYER=
 ORCH_PLANE_BOT_STREAM=
+# ORCH-117: sandbox-only fail-closed guard for Plane WRITES from a test/worktree
+# process (regression of ORCH-114, where pytest mutated a live prod board issue).
+# In the live runtime (uvicorn, no pytest) the guard is a no-op; in a test process
+# it BLOCKS every Plane write unless BOTH the opt-in is true AND the target project
+# is in the sandbox allowlist. Defaults are SAFE (default-deny): leave both as-is.
+#   ORCH_PLANE_TEST_WRITE_ENABLED -> opt-in for REAL Plane writes from a test process.
+#     false (default) = no test may write to Plane. NOT a kill-switch for the prod
+#     block: even true, only the sandbox allowlist below is writable (a prod write
+#     from pytest stays impossible).
+#   ORCH_PLANE_TEST_SANDBOX_PROJECTS -> CSV allowlist of sandbox project ids the
+#     opt-in may write to. Default = the single SANDBOX project; empty = none.
+ORCH_PLANE_TEST_WRITE_ENABLED=false
+ORCH_PLANE_TEST_SANDBOX_PROJECTS=8c5a3025-4f9d-4190-b79f-fa06276bb27e
 # Telegram live-tracker / alerts (empty -> notifications are logged, not sent).
 ORCH_TELEGRAM_BOT_TOKEN=
 ORCH_TELEGRAM_CHAT_ID=
@@ -107,6 +120,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
@@ -140,11 +177,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
@@ -295,6 +353,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:
@@ -365,6 +432,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).
@@ -374,10 +443,38 @@ 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
 
+# ORCH-114 (adr-0045): durable transition-ownership lease + expected-stage CAS for
+# side-effectful stage transitions. Generalises the process-local ORCH-113 finalizer-
+# liveness into a DURABLE, cross-path owner-exclusion (additive table `transition_lease`)
+# so a concurrent OR post-restart re-entry into a side-effectful transition (reaper /
+# reconciler / webhook / startup-requeue) is deferred or a no-op instead of re-applying
+# an irreversible effect (merge_pr / coverage-ratchet / image-rebuild / prod-deploy
+# initiation / contradictory rollback<->done). Two layers, both gated by the SINGLE
+# kill-switch below: (1) a durable lease on ENTRY to the side-effectful region (a second
+# actor that sees a live owner does not start the heavy sub-gates at all); (2) an
+# expected-stage CAS on the stage WRITE (a lost race -> abort with NO side effect), which
+# also closes the paths that write the stage in bypass of advance_stage. Owner liveness =
+# owner_pid + owner_boot_id (NOT a heartbeat), so restart recovery is free (new process ->
+# new boot_id -> all prior leases instantly stale -> reclaimed). The lease has NO own TTL:
+# its hard age ceiling IS the reaper Tier-3 backstop (ORCH_REAPER_MAX_RUNNING_S), so the
+# cross-cutting budget invariant ORCH-065/109/110/113 is untouched. STAGE_TRANSITIONS /
+# QG_CHECKS / check_* / machine-verdict keys / existing table schemas — byte-for-byte.
+#   TRANSITION_LEASE_ENABLED -> SINGLE kill-switch. false -> the lease is neither written
+#                               nor read AND the CAS degenerates to the prior unconditional
+#                               update_task_stage -> behaviour byte-for-byte as before
+#                               ORCH-114 (reaper -> ORCH-113 in-memory fallback,
+#                               reconciler/webhook skip-guard inert). Default true.
+#   TRANSITION_LEASE_REPOS   -> CSV scope. Empty -> applies ONLY to the self-hosting repo
+#                               (orchestrator), where the irreversible side-effectful edges
+#                               live; non-empty -> only the listed repos. Mirrors
+#                               ORCH_COVERAGE_GATE_REPOS -> enduro untouched at the default.
+ORCH_TRANSITION_LEASE_ENABLED=true
+ORCH_TRANSITION_LEASE_REPOS=
+
 # ORCH-063: disk-watchdog — background heartbeat that measures HOST-FS fill via the
 # mounted bind-paths (/repos, /app/data) with shutil.disk_usage (NOT the container
 # overlay /) and Telegram-alerts the operator at >= threshold. On 07.06.2026 the
@@ -543,6 +640,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
@@ -562,5 +665,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.watchdog.example

@@ -38,5 +38,15 @@ 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

@@ -14,3 +14,6 @@ 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-103
+Work item: ORCH-112
 Repo: orchestrator
-Branch: feature/ORCH-103-orch-10b-bundled-bootstrap
+Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
 Stage: development

CHANGELOG.md

@@ -3,6 +3,48 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
+- **Карта LLM-консультаций + control-path-ось «avoidable» + roadmap + нормативная политика** (ORCH-118, `docs`+`test`, inventory-first, docs+tests only): зонтичный follow-up RCA-трека ORCH-114/117 — у оркестратора не было ни нормативного критерия «где LLM нужен, а где это avoidable control path», ни карты мест вызова LLM, прибитой к коду. Выпущена **доказательная карта** каждого места, где control-path потребляет (или способен потребить) суждение LLM, с control-path-разметкой и классификацией; **упорядоченный roadmap** детерминированных замен; **нормативная политика** использования LLM; набор **структурных анти-дрейф тестов**. Это **docs + tests only**: `src/**`-рантайм не меняется → `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен **не** реализуются (FR-7); конкретные follow-up Plane-ID **не** фиксируются (R3/NFR-6 — кандидаты по роли). kill-switch не нужен (нет рантайм-поведения), как ORCH-077/079/101/102/103/011. ADR: `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`, сквозной `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`.
+  - **Единица инвентаря — LLM-консультация** (control-path потребляет суждение LLM), а **не** «спавн процесса / существование Claude CLI» (R4, capability ≠ consultation). Карта разводит **три ортогональных факта**: (1) consultation ≠ transport/slot (единственный транспорт LLM-консультации в `src/**` — `launcher._spawn`, `launcher.py:472`/CLI-сборка `610-614`; иного транспорта нет; job-роли `deploy-finalizer`/`post-deploy-monitor` занимают слот, но перехватываются в `launch_job` **до** `_spawn`, `launcher.py:389/394` — консультации нет); (2) **control-path (C) ≠ artifact-producer (P)** по коду-потребителю в `src/qg/checks.py` (C: гейт ветвится на LLM-вердикте; P: детерминированный гейт судит артефакт независимо — файлы/CI); (3) деривируемость вердикта из tool-сигналов.
+  - **Нормативное определение** «avoidable LLM control path» = двухбитный предикат (C-консультация **И** вердикт деривируем из exit-кодов `pytest`/smoke/`staging_check.py`/деплоя). Поимённый целевой набор (доказательно, прибит тестами): **avoidable = `{tester, deployer}`**; control-path-но-keep = `{reviewer}` (вердикт «приемлемость кода/решения» НЕ деривируем); не-control-path (P, keep) = `{analyst, architect, developer}`; уже детерминированы (эталон) = `{deploy-finalizer, post-deploy-monitor}`.
+  - **Документы (durable, `docs/architecture/`):** `llm-call-sites.md` (карта + машинно-читаемый блок инвентаря + control-path-разметка + классификация, снимок), `llm-determinization-roadmap.md` (порядок замен; рекомендованный первый срез — **deployer staging-status**, чистый маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C ORCH-036), `llm-usage-policy.md` (нормативный принцип + критерии keep/replace через ось + определение «avoidable»). Витрина `docs/overview/tech-quality-security.md` и `docs/architecture/README.md` ссылаются на карту и политику.
+  - **Анти-дрейф тесты (offline, без сети/LLM/subprocess-к-модели):** `tests/test_llm_call_site_inventory.py` (TC-01 единственный транспорт = `_spawn`; TC-12 отсутствие иного LLM-транспорта; TC-02 детерминированные модули без консультации; TC-03 промпты↔файлы; TC-04 тотальность+согласованность класса с осью; TC-05 keep-LLM именует суждение; TC-06 capability≠consultation; TC-09 снимок рантайм-контрактов; **TC-13** control-path-разметка сверена с потребителем в `src/qg/checks.py`; **TC-14** avoidable-набор = `{tester, deployer}`) и `tests/test_llm_determinization_docs.py` (TC-07 полнота roadmap+первый срез; TC-08 политика нормативна+определяет термин; TC-11 анти-фабрикация follow-up ID). Дискриминатор всех проверок — **«консультирует LLM», а не «спавнит subprocess»**. Норматив сопровождения: менял место вызова LLM или потребителя вердикта в `src/qg/checks.py` → обнови карту/разметку и политику в том же PR.
+- **Sandbox-only fail-closed изоляция записи в Plane из тест-процесса** (ORCH-117, `fix`, bug→escalate full-cycle): закрыт корневой класс инцидента **ORCH-114** — тест/worktree-процесс выполнил РЕАЛЬНУЮ запись (`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого** Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** — подмена env/токена постфактум бесполезна, NFR-4), и **ничто** не принуждало их писать только в sandbox. Симметрия прецеденту `tests/conftest.py::_no_telegram` (autouse-глушилка Telegram «pytest на проде слал реальные сообщения») — для Plane-**записи** такой защиты не было. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента Plane, **не** Quality Gate и **не** стадия). Новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op, work_item) -> (ALLOW|BLOCK, reason)`, по образцу `deploy_status_guard`/`serial_gate`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и **до** любого сетевого шага (ни GET, ни PATCH/POST). Гард активен **только в тест-процессе** (детект `"pytest" in sys.modules` / `PYTEST_CURRENT_TEST`); боевой и staging рантаймы (`uvicorn src.main:app`, без pytest в процессе) — строгий **no-op** (NFR-2/NFR-3). В тест-процессе запись разрешена **только** при одновременном (а) opt-in `plane_test_write_enabled=True` **и** (б) целевом проекте ∈ sandbox-allowlist `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-…`); иначе — default-deny; нерезолвимый проект → блок (fail-closed, NFR-1); боевой проект запрещён **даже при opt-in** (allowlist sandbox-only). Второй независимый sandbox-bound слой — autouse-floor `tests/conftest.py::_plane_sandbox_only` (opt-in OFF для всего сьюта, по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит opt-in в своей фикстуре поверх floor. **Умышленно БЕЗ kill-switch прод-блока** (NFR-6/FR-7/anti-drift): выключателя, переоткрывающего прод-запись из pytest, нет — единственный реверс — sandbox-bound opt-in. Аудит: блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason` — делает инцидент класса ORCH-114 очевидным), разрешённая sandbox-запись → INFO. Новые ключи `ORCH_PLANE_TEST_WRITE_ENABLED` (дефолт `false`) / `ORCH_PLANE_TEST_SANDBOX_PROJECTS` (дефолт = SANDBOX id) с безопасными дефолтами; `scripts/staging_check.py` Block C (E2E в SANDBOX) — отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие — `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до врезки, зелёный после; TC-02…TC-14). ADR: `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`, сквозной `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`.
+- **Ownership-lease для side-effectful переходов стадий + умное восстановление при старте** (ORCH-114, `fix`, bug→escalate full-cycle): закрыт **корневой класс** инцидент-цепочки ORCH-110/111/112/113 — у side-effectful переходов стадий не было единого владения. `advance_stage` ре-ентерабельна и пишет стадию «голым» `UPDATE … WHERE id=?` (без compare-and-swap), а ≥5 акторов (монитор / Plane-webhook / reconciler F-1 / job-reaper / deploy-finalizer) входят в один переход независимо → конкурентный или после-рестартовый повторный вход **дважды** применял необратимые эффекты (merge_pr / coverage-ratchet / image-rebuild / инициация прод-деплоя) и давал **противоречие rollback↔done** (инцидент ORCH-111, job 1914 / PR #130). Два комплементарных слоя, оба аддитивные, под единым kill-switch, never-raise: **(1) durable transition-lease** (новая таблица `transition_lease`) — владение на ВХОДЕ в side-effectful регион (второй актор, увидев живого владельца, не стартует тяжёлые под-гейты вовсе — предотвращение, не починка постфактум); **(2) expected-stage CAS** (`update_task_stage_cas`) — на ЗАПИСИ стадии (проигравший гонку — аборт без побочных эффектов), что закрывает и **6 путей записи стадии в обход `advance_stage`** (gitea×5 + plane rollback). Liveness владельца = `owner_pid` + `owner_boot_id` (НЕ heartbeat: блокирующий 900s merge re-test не может бить heartbeat — довод самого ORCH-113), что делает рестарт-recovery бесплатным (новый процесс → новый boot-id → все прежние lease мгновенно устаревшие → реклеймятся). Lease без собственного TTL: его потолок возраста = Tier-3 backstop `reaper_max_running_s` (5400) → сквозной бюджет ORCH-065/109/110/113 не тронут. `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / **схемы существующих таблиц** — байт-в-байт (одна аддитивная таблица, без epoch-колонки на `tasks`). Скоуп self-hosting (`transition_lease_repos=""` → только `orchestrator`; enduro не затронут); kill-switch `ORCH_TRANSITION_LEASE_ENABLED=false` → CAS вырождается в прежний безусловный `update_task_stage`, lease инертен → поведение байт-в-байт до ORCH-114. ADR: `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`, сквозной `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`.
+  - **Leaf `src/transition_lease.py` (новый, чистый never-raise):** по образцу `serial_gate`/`coverage_gate`/`finalizer_liveness` (импортирует только `db`+`config`, лениво `merge_gate.pid_alive`/`qg.checks`/`notifications`; НЕ импортирует `stage_engine`/`launcher`) — `applies(repo)` / `acquire(task_id, owner, run_id, stage)` (атомарный rowcount-guard `INSERT … ON CONFLICT DO NOTHING` после очистки stale-строки) / `is_held_by_live_owner(task_id)` (fail-closed → defer на сомнении) / `release(task_id, force=False)` (holder-aware по boot) / `reclaim_if_stale` / `recover_on_startup` / `commit_stage_cas(task_id, expected, new, repo)` (flag-off → unconditional `update_task_stage`; flag-on → CAS) / `snapshot()`.
+  - **Интеграция:** `advance_stage` захватывает lease на входе в side-effectful ребро (`deploy-staging`/`deploy`), пишет стадию через CAS, освобождает lease в `try/finally` (на любом исходе, включая исключение/откат); **rollback-записи side-effectful под-гейтов** (`_handle_merge_gate_rollback`/`_handle_security_gate`/`_handle_coverage_gate`/`_handle_image_freshness`) пишут `development` через тот же CAS (общий хелпер `_rollback_stage_cas`, ADR-001 D4: защита rollback↔done — под держимым lease это единственный владелец, проигранный CAS → аборт без side-effects, не слепой перетир `done`); job-reaper `_finalizer_owns` обобщён с процесс-локального ORCH-113 (Tier-2/`deploy-staging`) на **durable cross-path** lease (defer при живом владельце; Tier-3 backstop игнорирует маркер → bounded reclaim; реап force-освобождает lease); reconciler F-1 и Plane-webhook (`_try_advance_stage`) делают **defer** при активном lease; `main.lifespan` зовёт `recover_on_startup()` после `requeue_running_jobs`. Наблюдаемость — read-only блок `transition_lease` в `GET /queue` + Telegram-алерт на форсированный/устаревший реклейм + опциональный `POST /transition-lease/release?work_item=<id>`. Покрытие — `tests/test_orch114_transition_ownership.py` (TC-01 обязательный регресс класса ORCH-111: красный до фикса, зелёный после; TC-02…TC-14 + регресс CAS на in-region rollback). Флаги (`config.py`, дефолт = боевое): `transition_lease_enabled` (env `ORCH_TRANSITION_LEASE_ENABLED`), `transition_lease_repos` (env `ORCH_TRANSITION_LEASE_REPOS`).
+- **Гигиена 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 — только документированная процедура.

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 агентов на каждой стадии.
 
@@ -289,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 роутятся по типу:

docker-compose.yml

@@ -79,6 +79,12 @@ 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:

docs/PRODUCT_VISION.md

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

docs/architecture/adr/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/adr/adr-0045-transition-ownership-lease-and-stage-cas.md

@@ -0,0 +1,94 @@
+---
+work_item: ORCH-114
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0045: Durable transition-ownership lease + expected-stage CAS — единое владение side-effectful переходами стадий
+
+- **Статус:** proposed
+- **Дата:** 2026-06-15
+- **Задача:** ORCH-114 (bug → escalate full-cycle; системный наследник кластера ORCH-110/111/112/113)
+- **Детальный ADR:** `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`
+- **Обобщает:** `adr-0043` (ORCH-113 in-memory finalizer-liveness — отправная точка)
+- **Уточняет/опирается:** `adr-0011` (reaper/lease-reclaim ORCH-065), `adr-0040` (бюджеты ORCH-109),
+  `adr-0042` (merge-retest ORCH-110), `adr-0027` (merge-lease ORCH-043), `adr-0029` (coverage-ratchet ORCH-027),
+  ORCH-071/073/093 (SHA-in-main / already-in-main), ORCH-036 (`INITIATED` self-deploy)
+
+## Контекст
+
+Корневой класс инцидент-цепочки ORCH-110/111/112/113: **у side-effectful переходов стадий нет единого
+владения**. `db.update_task_stage` — голый `UPDATE … WHERE id=?` без CAS (`db.py:671–679`); `advance_stage`
+ре-ентерабельна без защиты и исполняет минуты-длинные необратимые под-гейты (`deploy-staging → deploy`:
+security→merge-retest→coverage→image-freshness; `deploy → done`: `merge_pr`/ratchet/proof-of-merge) **до**
+единственной записи стадии. ≥5 акторов входят в переход независимо (монитор/webhook/reconciler F-1/reaper/
+Phase-C finalizer) + 6 путей пишут стадию в обход `advance_stage` (5× `gitea.py`, 1× `plane.py:806`).
+ORCH-113 (`finalizer_liveness`) закрыл это лишь in-memory, reaper-Tier-2, `deploy-staging`, теряя владение
+на рестарте — остаточный кросс-путь дал двойной эффект и противоречие rollback↔done (ORCH-111, job 1914/PR #130).
+
+## Решение
+
+Два комплементарных аддитивных слоя под единым kill-switch, never-raise:
+
+1. **Durable transition-lease** — новая аддитивная таблица `transition_lease`
+   (`task_id PK, owner, owner_pid, owner_boot_id, run_id, stage, acquired_at`; `CREATE TABLE IF NOT EXISTS`,
+   паттерн `repo_freeze`/`coverage_baseline`). Владение захватывается на **входе** в side-effectful регион
+   `advance_stage` (рёбра `deploy-staging→deploy`, `deploy→done`, Phase C `run_deploy_finalizer`); второй
+   актор, увидев **живого** владельца, не стартует под-гейты вовсе (предотвращение класса, а не починка).
+   Release — в `try/finally`. **Liveness = `owner_pid` + `owner_boot_id`**, НЕ heartbeat (heartbeat отвергнут
+   тем же доводом, что в adr-0043: блокирующий 900s re-test не может его бить). Реклейм мёртвого/устаревшего
+   (pid мёртв ИЛИ boot-id чужой) — немедленно; зависший живой добивается Tier-3.
+2. **Expected-stage CAS** — `update_task_stage_cas(task_id, expected_stage, new_stage)`
+   (`UPDATE tasks SET stage=? … WHERE id=? AND stage=?`, rowcount==1 ⇒ выиграл; 0 ⇒ проиграл → аборт без
+   побочных эффектов). Покрывает остаточное окно гонки И 6 обходных путей. Без epoch-колонки: для текущей
+   модели стадия *и есть* версия (epoch — задокументированное форвард-расширение под `--workers>1`).
+
+**Осведомлённость акторов:** reaper консультирует durable-lease на **всех** путях (обобщение ORCH-113):
+живой → defer, мёртвый → реклейм, Tier-3 маркер игнорирует; reconciler F-1 и webhook (Approved/Confirm
+Deploy) — новый skip-guard по образцу escalated/Blocked/task-deps. `finalizer_liveness` сохранён без правок
+как поведение при **выключенном** ORCH-114 (надстройка durable-слоя поверх).
+
+**Умное восстановление (FR-4)** — НЕ новый recovery-мозг, а композиция: `requeue_running_jobs` (есть) +
+startup stale-clear (boot-id mismatch ⇒ старые lease мертвы) + идемпотентность re-drive через
+**авторитетные durable-факты предшественников** (SHA-in-main ORCH-071/073, `INITIATED` ORCH-036,
+coverage-ratchet CAS ORCH-027). Lease лишь гарантирует **последовательную**, не конкурентную, их проверку.
+
+**Бюджет (NFR-6):** lease без собственного TTL; жёсткий потолок возраста = Tier-3 `reaper_max_running_s`
+(5400), reaper при реапе force-освобождает lease. Сквозной инвариант `5400 > Σ(≈4460)+grace` и
+`reaper_finalize_grace_s`/`reaper_max_running_s` — **не тронуты**.
+
+**Конфиг:** `transition_lease_enabled=True` (kill-switch) + `transition_lease_repos=""` (CSV; пусто →
+self-hosting only, паттерн coverage/serial-gate). Leaf `src/transition_lease.py` never-raise.
+
+**Инварианты:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict-ключи / схемы
+**существующих** таблиц — байт-в-байт; +1 аддитивная таблица; механизм не рестартит прод, не пушит/
+force-push `main`, не трогает detached-деплой (NFR-5). Hot-path `claim_next_job` не тронут (fail-open).
+
+## Альтернативы
+
+- Только CAS (без lease) — не предотвращает двойной side-effect в полёте.
+- Только lease (без CAS) — не покрывает 6 обходных путей + окно consult→acquire.
+- Heartbeat-liveness — блокирующий re-test не бьёт heartbeat (довод adr-0043).
+- Lease-файл per-task — CAS на стадию всё равно DB-операция; БД когерентнее, merge-lease-файл per-repo для
+  иной задачи (сериализация мержей), не дублируется.
+- epoch-колонка / sub-state `finalizing` в `jobs.status` / per-stage grace на Σ — отвергнуто (как в adr-0043:
+  меняет семантику/нарушает бюджет/неиспользуемо).
+
+## Последствия
+
+- (+) Класс двойного эффекта закрыт в корне; конкурентный/после-рестартовый/reconciler/webhook пути покрыты.
+- (+) Рестарт-safe без нового таймера; boot-id готовит multi-process; бюджет и инварианты конвейера целы; +1 таблица.
+- (+) Дыра обходных путей gitea/plane закрыта CAS; откат — один env-флаг.
+- (−) Полная multi-writer эксклюзия валидна при одном процессе/одной БД (как adr-0043); durable делает её
+  корректной для рестарта, но `--workers>1`-верификация — вне объёма (риск в `10-tech-risks.md`).
+
+## Связи
+
+- Обобщает `adr-0043`; опирается на `adr-0011`/`adr-0040`/`adr-0042`/`adr-0027`/`adr-0029` и ORCH-071/073/093/036.
+- Маркеры (ORCH-078/TRACEABILITY): блоки reaper/finalizer-liveness/stage-engine несут ORCH-065/109/110/113 +
+  новый `ORCH-114`; правки сверяются с их ADR (анти-археология — этот сводный сквозной ADR).
+- Детально: `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`.
+</content>

docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md

@@ -0,0 +1,121 @@
+---
+work_item: ORCH-117
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0046: Sandbox-only fail-closed гард записи в Plane из тест-процесса
+
+Сквозной (cross-cutting) ADR. Вводит инвариант **«мутирующая запись в Plane из тест/worktree-процесса
+физически невозможна в боевой проект; sandbox — только под явным opt-in»** поверх **общего**
+Plane-клиента `src/plane_sync.py` (три примитива записи, используемые ВСЕМИ проектами общего
+инстанса) и нового тест-харнесс-инварианта `tests/conftest.py`. Детальное решение задачи —
+`docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`.
+
+> Регистрируется как сквозной, т.к. правит **системно используемые** примитивы записи
+> `update_issue_state`/`add_comment`/`_set_issue_state_direct` и вводит новый рантайм-компонент
+> (leaf `src/plane_write_guard.py`), затрагивающий индикацию (слой B, ORCH-066) всех проектов.
+> Кросс-каттинг с adr-0028 (deploy-status guard, ORCH-094) и adr-0009 (staging-tolerance, ORCH-061):
+> оба — потребители того же `plane_sync`; гард для них — no-op в боевом/staging рантайме.
+
+## Статус
+Proposed
+
+## Контекст
+
+Инцидент **ORCH-114**: тестовый/worktree-процесс (`python -m pytest` из worktree) выполнил
+**реальную** запись в Plane против **боевого** проекта ORCH (`PATCH state=<Done>` + комментарий) —
+«ложный Done» на боевой доске. Корень (сверено по коду `src/plane_sync.py`):
+
+1. `PLANE_HEADERS`/`PROJECT_ID` (боевой токен + боевой дефолтный проект) **захвачены на импорте**
+   модуля (стр. 17/57) → подмена env/токена постфактум бесполезна.
+2. Тестовые `os.environ.setdefault("ORCH_PLANE_API_TOKEN",…)` — **no-op** в контейнере с уже
+   установленной боевой переменной.
+3. Все мутации сходятся в **три** примитива (`update_issue_state`/`add_comment`/
+   `_set_issue_state_direct`), и ни один **не** проверяет тест-контекст и легитимность целевого
+   проекта.
+
+Симметричная защита для Telegram (`tests/conftest.py::_no_telegram`) существует и работает по тому же
+классу проблем («pytest на проде слал реальные сообщения»); для Plane-записи её **не было**.
+
+## Решение
+
+**Fail-closed гард на низком чокпоинте**, в момент вызова, двумя независимыми sandbox-bound слоями.
+
+### D1 — Рантайм-leaf `src/plane_write_guard.py` (never-raise)
+
+Чистый leaf (паттерн `serial_gate`/`cancel`/`deploy_status_guard`): импортирует только `config`,
+лениво `db`. `decide(project_id, op, work_item_id) -> (ok: bool, reason: str)`:
+
+1. `not _in_test_process()` → **ALLOW** (боевой/staging рантайм — no-op, byte-for-byte).
+2. `project_id` нерезолвим → **BLOCK** `ambiguous-target` (fail-closed, NFR-1).
+3. `not plane_test_write_enabled` → **BLOCK** `opt-in-disabled`.
+4. `project_id ∉ sandbox-allowlist` → **BLOCK** `prod-project-in-test` (sandbox-only даже при opt-in).
+5. иначе → **ALLOW** `sandbox-opt-in` (audit INFO).
+
+Врезается в 3 примитива `plane_sync` сразу после `_resolve_project_id` и **до** любого сетевого шага;
+на BLOCK — структурный аудит + `return` (ни GET, ни PATCH/POST).
+
+### D2 — Детект `_in_test_process()`
+
+`"pytest" in sys.modules or PYTEST_CURRENT_TEST` (call-time). Боевой/staging рантайм
+(`uvicorn src.main:app`) pytest в свой процесс не импортирует → детект там никогда не срабатывает
+(нулевая регрессия). worktree-`python -m pytest` (инцидентный путь) детектируется гарантированно.
+
+### D3 — Conftest-floor `tests/conftest.py::_plane_sandbox_only`
+
+Autouse-фикстура (паттерн `_no_telegram`/`_reset_webhook_secrets`/`_disable_*`) форсит во ВСЕХ тестах
+безопасные дефолты (`plane_test_write_enabled=False`, allowlist = канонический SANDBOX id),
+перекрывая любую боевую переменную из окружения. Sandbox-e2e ре-энейблит opt-in **после** autouse
+(scoping реальной записи на себя). Слой независим от рантайм-leaf → двойной default-deny.
+
+### D4 — Реверс через opt-in, БЕЗ kill-switch (норматив)
+
+Единственный реверсивный регулятор — sandbox-bound opt-in `plane_test_write_enabled` (+ allowlist
+`plane_test_sandbox_projects`). **Намеренно нет** prod-блок kill-switch: выключатель, обнуляющий
+prod-блок в тест-процессе, был бы «чёрным ходом» (NFR-6). Прецедент — `_no_telegram` (тоже без
+«разрешить»-флага). **Анти-дрейф (норматив на будущее):** не вводить общий kill-switch гарда,
+переоткрывающий прод-запись из pytest.
+
+### D5 — Скоуп: НЕ `*_repos`
+
+В отличие от гейт-leaf'ов (`serial_gate`/`coverage_gate`, scope по репо, т.к. *действуют* на репо),
+гард защищает запись в **любой** боевой проект общего workspace (включая боевой enduro) → скоупа по
+репо нет; гейты — `_in_test_process()` + opt-in (как у observer-leaf `lessons`).
+
+## Инварианты (что НЕ меняется)
+
+`STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи
+(`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`) /
+схема БД — **байт-в-байт не тронуты**. Это bugfix-изоляция клиента Plane, **не** Quality Gate и
+**не** стадия. Боевой и staging рантаймы — byte-for-byte (no-op гарда). adr-0028 (deploy-status
+guard) / adr-0009 (staging-tolerance) / ORCH-066 (статусная модель) в проде/стейджинге не затронуты.
+
+## Конфиг
+
+| Ключ | Env | Дефолт |
+|------|-----|--------|
+| `plane_test_write_enabled` | `ORCH_PLANE_TEST_WRITE_ENABLED` | `False` |
+| `plane_test_sandbox_projects` | `ORCH_PLANE_TEST_SANDBOX_PROJECTS` | `8c5a3025-4f9d-4190-b79f-fa06276bb27e` |
+
+## Последствия
+
+- **+** Прод-запись в Plane из pytest/worktree физически невозможна независимо от токена; ORCH-114
+  закрыт у источника и стал видимым (аудит).
+- **+** Нулевая регрессия боевого/staging рантайма и гейтов/схемы БД.
+- **−** Детект завязан на «pytest-в-процессе» (теоретический ложноположительный риск — TR-1) и
+  умышленный отказ от kill-switch требует явной фиксации (TR-4). См. `10-tech-risks.md`.
+- **Откат:** снять врезку гарда + autouse-фикстуру + 2 конфиг-ключа → поведение до ORCH-117 (дефект
+  возвращается).
+
+## Ссылки
+- Детально: `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`
+- Риски: `docs/work-items/ORCH-117/10-tech-risks.md`
+- Связанные: [adr-0028](adr-0028-terminal-window-aware-deploy-status-guard.md) (ORCH-094),
+  [adr-0009](adr-0009-staging-infra-tolerance.md) (ORCH-061),
+  [adr-0034](adr-0034-lessons-journal.md) (observer-leaf без `*_repos`)
+- Сверено по коду: `src/plane_sync.py:17,57,846-889,1038-1051`, `tests/conftest.py`,
+  `scripts/staging_check.py:283`

docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md

@@ -0,0 +1,114 @@
+---
+work_item: ORCH-118
+stage: architecture
+author_agent: architect
+status: accepted
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# adr-0047: Нормативная политика использования LLM + карта call-site'ов (control-path-ось «avoidable»)
+
+> **Сквозной (cross-cutting) ADR.** Агрегирует решение ORCH-118, влияющее на **весь** оркестратор:
+> нормативная политика использования LLM, три ортогональных оси, определение «avoidable LLM control
+> path» и снимок-карта LLM-консультаций, прибитая к коду структурными тестами. Локальная детализация —
+> `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`.
+
+## Статус
+Accepted
+
+## Контекст
+
+RCA-цепочка ORCH-114/117 (и 110/111/112/113) показала корневой класс: у side-effectful и решающих
+control-path'ов не было единого детерминированного владения; местами решение брал LLM-агент «потому
+что удобно», хотя по сути это исполнение фиксированных команд + маппинг результата — лишний
+недетерминизм, задержка и расход токенов в точке ветвления.
+
+Оркестратор не имел **нормативного критерия** «где LLM нужен, а где это avoidable control path» и
+**карты** мест вызова LLM, прибитой к коду. Без них любая будущая правка control-path'а могла снова
+ввести LLM «на удобстве», а «вслепую» убирать LLM нельзя — часть путей несёт настоящее суждение
+(анализ, архитектура, написание кода, ревью).
+
+**Ground-truth кода (ORCH-118, сверено):** единственный транспорт LLM-консультации в `src/**` —
+`launcher._spawn` (`launcher.py:472`, CLI `610-614`); иного LLM-транспорта нет (нет SDK-импортов /
+прямого HTTP Anthropic / второго сборщика). 6 ролей-агентов консультируют через него; D1/D2
+(`deploy-finalizer`/`post-deploy-monitor`) перехватываются в `launch_job` **до** `_spawn`
+(`launcher.py:389/394`) — слот есть, консультации нет. Потребитель вывода каждой роли — конкретный
+`check_*`/`_parse_*` в `src/qg/checks.py`.
+
+## Решение
+
+### D1 — Три ортогональных оси (нормативно для всего оркестратора)
+
+1. **consultation ≠ transport/slot** — «потребляет суждение LLM» ≠ «спавнит процесс / занимает слот
+   агента» (capability ≠ consultation).
+2. **control-path (C) ≠ artifact-producer (P)** — определяется кодом-потребителем: C — `check_*`
+   ветвится на machine-verdict, написанном LLM; P — детерминированный гейт судит артефакт независимо
+   (файлы/CI).
+3. **деривируемость вердикта** — вердикт C-консультации либо детерминированная функция tool-сигналов
+   (exit-code `pytest`/smoke/`staging_check.py`/деплоя), либо настоящее суждение.
+
+### D2 — Нормативное определение «avoidable LLM control path»
+
+> Call-site — **avoidable LLM control path** ⟺ **(i)** C-консультация (LLM-вердикт потребляется
+> потоком управления) **И (ii)** вердикт деривируем из tool-сигналов, которые оркестратор уже
+> вычисляет → LLM не добавляет информации.
+
+Целевой набор (доказательно из `src/qg/checks.py`): **avoidable = {tester, deployer}**;
+control-path-но-keep = `{reviewer}`; не-control-path (P, keep) = `{analyst, architect, developer}`;
+уже детерминированы (вне консультаций) = `{deploy-finalizer, post-deploy-monitor}`.
+
+### D3 — Нормативная политика использования LLM (`docs/architecture/llm-usage-policy.md`)
+
+Принцип: **«LLM — только там, где требуется настоящее суждение».** Критерий keep vs replace —
+через оси D1 (является ли путь control path; деривируем ли вердикт; обратимость; влияние на
+автономность NFR-2). **Требование:** любая новая/изменённая control-path-консультация обязана
+обосновать использование LLM против этой политики; reviewer контролирует это как обзорную ось
+(в духе ORCH-079) — **как требование, не как новый машинный гейт**.
+
+### D4 — Карта как снимок, прибитый к коду
+
+`docs/architecture/llm-call-sites.md` — инвентарь + control-path-разметка + классификация со
+схемой полей и машинным блоком (детали — work-item ADR-001 D2/D4). Структурные тесты
+`tests/test_llm_call_site_inventory.py` (offline) держат инварианты: транспорт-агностичный
+двусторонний инвариант единственной точки, отсутствие консультации в детерминированных путях,
+control-path-разметка сверена с `src/qg/checks.py`, avoidable-набор = `{tester, deployer}`.
+
+### D5 — Roadmap детерминизации (`docs/architecture/llm-determinization-roadmap.md`)
+
+Рекомендованный первый срез — **deployer (staging-status)** (`replace-deterministic-now`: чистый
+маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C ORCH-036; опора на
+прецедент D1/D2). Затем — **tester-гибрид** (`needs-hybrid-fallback`). Кандидаты — **по роли**,
+без конкретных Plane-ID (NFR-6).
+
+### D6 — Скоуп и инварианты (нормативно)
+
+ORCH-118 — **docs + tests only**: `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` /
+machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен не реализуются;
+follow-up Plane-ID не фиксируются. Self-hosting-безопасно (только чтение кода + запись docs/tests).
+
+**Норматив сопровождения (durable):** менял места вызова LLM **или** потребителя вердикта в
+`src/qg/checks.py` → обнови карту/разметку и политику в **том же PR** (иначе тесты D4 красные).
+
+## Альтернативы
+- **Машинный гейт-enforcement политики (новый QG)** — отвергнуто: политика нормативно-описательная,
+  как ось трассировки ORCH-078; новый QG увеличил бы поверхность риска без необходимости (FR-6 §QG).
+- **Реализация раннеров в этой же задаче** — отвергнуто: inventory-first по требованию заказчика;
+  «вслепую» убирать LLM рискованно без утверждённой карты.
+- **Привязка к конкретным follow-up ID** — отвергнуто (NFR-6, корень отклонённой R2).
+
+## Последствия
+- **+** Единый нормативный критерий и код-привязанная карта закрывают класс «LLM на удобстве» и
+  делают замены предсказуемыми; автономность защищена политикой.
+- **−** Карта — снимок: эволюция `src/qg/checks.py` требует со-обновления карты (держится тестами).
+  *Митигейшн:* запланированный норматив сопровождения, тест указывает точку дрейфа.
+- **Откат:** удаление/правка `docs/architecture/llm-*.md` + тест-файла + секции README; рантайм не
+  затронут.
+
+## Ссылки
+- Work-item ADR: `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-118/{01-brd,02-trz,03-acceptance-criteria}.md`
+- Сверено по коду: `src/agents/launcher.py`, `src/qg/checks.py`, `.openclaw/agents/*.md`
+- Связанные: ORCH-036 (детерминированный self-deploy), ORCH-061 (`staging_verdict`),
+  ORCH-077/079 (docs/prompts-only прецедент + reviewer-ось обзорных доков), ORCH-114/117 (RCA-трек)
+</content>

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`)
@@ -188,6 +188,21 @@ CREATE TABLE events (
     payload TEXT,
     created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
 );
+
+-- ORCH-114 (adr-0045): durable transition-ownership lease. ОДНА аддитивная таблица
+-- (CREATE TABLE IF NOT EXISTS, паттерн repo_freeze/coverage_baseline/lessons) — одна
+-- строка = ≤1 активный владелец side-effectful перехода задачи. Живость владельца =
+-- owner_boot_id (нонс старта процесса; рестарт ⇒ смена ⇒ прежний lease мёртв) +
+-- pid_alive(owner_pid). БЕЗ epoch/version-колонки на tasks (стадия = версия CAS).
+CREATE TABLE transition_lease (
+    task_id       INTEGER PRIMARY KEY,
+    owner         TEXT NOT NULL,   -- monitor|reaper|reconciler|webhook|finalizer|engine
+    owner_pid     INTEGER,
+    owner_boot_id TEXT,
+    run_id        INTEGER,
+    stage         TEXT,            -- from-стадия захвата (контекст/наблюдаемость)
+    acquired_at   TEXT DEFAULT (datetime('now'))
+);
 ```
 
 ## Deployment
@@ -259,7 +274,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) |
@@ -369,7 +384,13 @@ status='queued'` и проверяет `rowcount`. При гонке двух т
 
 В `main.py` lifespan **после** M-1 orphan-recovery вызывается `requeue_running_jobs()`:
 jobs со статусом `running` (воркер умёр на рестарте) → возвращаются в `queued`.
-Потом стартует воркер; на shutdown — `worker.stop()` (Event.set + join).
+**ORCH-114 (adr-0045):** сразу следом вызывается `transition_lease.recover_on_startup()` —
+новый процесс имеет свежий `boot_id`, поэтому ВСЕ записанные ранее `transition_lease`
+устарели (boot-id mismatch) → реклеймятся, и только что requeued-jobs переисполняют свои
+side-effectful переходы **последовательно** (один владелец), без двойного необратимого
+эффекта. Идемпотентность самого re-drive обеспечивают существующие авторитетные факты
+(SHA-in-main ORCH-071/073, маркер `INITIATED` ORCH-036, coverage-ratchet CAS ORCH-027) —
+НЕ новый recovery-мозг. Потом стартует воркер; на shutdown — `worker.stop()` (Event.set + join).
 
 ### Job-reaper (ORCH-065, рестарт НЕ требуется)
 
@@ -385,7 +406,25 @@ 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); схема БД и сквозной бюджет не тронуты.
+  **ORCH-114 (adr-0045):** обобщает это in-memory-владение до **durable, кросс-путевого**
+  `transition_lease` (таблица `task_id PK, owner, owner_pid, owner_boot_id, …`): reaper
+  консультирует durable-lease на **всех** релевантных путях (не только Tier-2/`deploy-staging`),
+  живость владельца = `pid_alive(owner_pid)` + совпадение boot-id (рестарт ⇒ прежние lease мертвы);
+  парная CAS-запись стадии (`update_task_stage_cas`, `WHERE id=? AND stage=?`) — аборт проигравшего
+  без побочных эффектов; reconciler F-1 и webhook тоже defer при живом владельце. Kill-switch
+  `ORCH_TRANSITION_LEASE_ENABLED` (off → ровно поведение ORCH-113 выше); `finalizer_liveness.py`
+  не правится (надстройка durable-слоя поверх). Потолок возраста lease = `reaper_max_running_s`
+  (Tier-3 force-освобождает), сквозной бюджет цел;
 - **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
 
 Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,

docs/architecture/llm-call-sites.md

@@ -0,0 +1,156 @@
+# LLM call-site map — inventory, control-path axis & classification (ORCH-118)
+
+> **Что это.** Доказательная карта **каждого места**, где control-path оркестратора
+> потребляет (или способен потребить) суждение LLM. Единица инвентаря — **LLM-консультация**
+> (control-path потребляет суждение LLM), **не** «спавн процесса / существование Claude CLI»
+> (capability ≠ consultation, BRD §0 / R4).
+>
+> **Снимок, прибитый к коду.** Карта — *снимок*; её инварианты держат структурные тесты
+> `tests/test_llm_call_site_inventory.py` (анти-дрейф). Меняешь место вызова LLM или потребителя
+> вердикта в `src/qg/checks.py` → **обнови эту карту и политику в том же PR** (норматив сопровождения).
+>
+> **Источник истины** содержательной классификации — ADR
+> `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`
+> (D2/D3/D4) и сквозной `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`.
+> Нормативное определение «avoidable LLM control path» и критерии keep/replace — в
+> [`llm-usage-policy.md`](llm-usage-policy.md); порядок замен — в
+> [`llm-determinization-roadmap.md`](llm-determinization-roadmap.md).
+
+---
+
+## 0. Три ортогональных факта (как читать карту)
+
+Карта **явно** разводит три раздельных факта — их смешение было корнем блокеров R3→R5:
+
+1. **Ось 1 — consultation ≠ transport/slot.** «LLM-консультация» = точка, где решение/артефакт
+   конвейера **потребляет суждение LLM**. Транспорт (`_spawn`) — реализация, не определение. Слот
+   агента (job-роли `D1`/`D2`) делает site LLM-**capable**, но консультация гейтится потоком
+   управления (перехват **до** `_spawn`) → **capability ≠ consultation**.
+2. **Ось 2 — control-path (C) ≠ artifact-producer (P).** Определяется **кодом-потребителем** вывода
+   роли в `src/qg/checks.py`:
+   - **(C) control-path** — LLM эмитит machine-verdict, на котором **ветвится `check_*`-гейт**
+     (PASS → дальше / FAIL → откат). Суждение LLM **входит** в поток управления.
+   - **(P) artifact-producer** — LLM производит артефакт, а продвижение решает **детерминированный
+     гейт**, судящий артефакт **независимо** (наличие файлов / CI-статус). Суждение LLM в control
+     flow **не входит**.
+3. **Ось 3 — деривируемость вердикта.** Вердикт C-консультации либо есть **детерминированная функция
+   tool-сигналов** (exit-code `pytest`/smoke/`staging_check.py`/деплоя), которые оркестратор **уже
+   вычисляет сам**, либо требует **настоящего суждения**, не сводимого к exit-коду.
+
+> **Avoidable LLM control path** (нормативное определение — [`llm-usage-policy.md`](llm-usage-policy.md)):
+> call-site, для которого выполнены **оба** условия — **(i)** это C-консультация (её LLM-вердикт
+> потребляется потоком управления) **и** **(ii)** вердикт **деривируем** из tool-сигналов. Тогда
+> суждение LLM не добавляет информации → консультацию можно снять без потери смысла.
+
+---
+
+## 1. Инвентарь LLM-консультаций (полный, привязан к коду)
+
+Каждая запись несёт: `id` · `location (file:line)` · `trigger` · `stage/owner` · `output artifact` ·
+`machine-verdict key` · `output consumer` (кто потребляет вывод роли) · `est. tokens/runtime`
+(оценка из `agent_runs`) · `consults-LLM` · `axis` (C/P) · `classification` · `rationale`.
+
+| id | location (file:line) | trigger | stage / owner | output artifact | machine-verdict key | output consumer (`src/qg/checks.py`) | est. tokens/runtime (оценка) | consults-LLM | axis | classification | rationale |
+|----|----------------------|---------|---------------|-----------------|---------------------|--------------------------------------|------------------------------|--------------|------|----------------|-----------|
+| **S0** | `src/agents/launcher.py:472` (`_spawn`; CLI-сборка `610-614`; парс токенов `_monitor_agent:838`) | `launch_job` → `_spawn` для любой из 6 ролей | — (транспорт) | — | — | — | — | **транспорт** (capability) | — | — | Единственный транспорт LLM-консультации в `src/**`; не call-site решения |
+| **A1** | `.openclaw/agents/analyst.md` | стадия `analysis` | analyst | `01-brd` … `04-test-plan` | — | `check_analysis_complete:33` (наличие файлов) | ~80–200k / 5–20 мин | да (через S0) | **P** | `keep-LLM` | анализ требований / BRD/ТЗ — настоящее суждение; гейт судит лишь наличие артефактов |
+| **A2** | `.openclaw/agents/architect.md` | стадия `architecture` | architect | `06-adr/`, `07` | — | `check_architecture_done:62` (наличие 06-adr/07) | ~80–200k / 5–20 мин | да (через S0) | **P** | `keep-LLM` | архитектурное решение / ADR — настоящее суждение |
+| **A3** | `.openclaw/agents/developer.md` | стадия `development` | developer | код + PR | — | `check_ci_green:82` (+ `check_branch_mergeable:657`) — CI/merge | ~150–400k / 10–40 мин | да (через S0) | **P** | `keep-LLM` | написание кода — настоящее суждение; гейт судит CI/merge, не самоотчёт |
+| **A4** | `.openclaw/agents/reviewer.md` | стадия `review` | reviewer | `12-review.md` | `verdict:` | `check_reviewer_verdict:336` (`verdict:`) | ~100–300k / 5–25 мин | да (через S0) | **C** | `keep-LLM` | control path, но вердикт «приемлемость кода/решения» **НЕ деривируем** из exit-кода — настоящее суждение |
+| **A5** | `.openclaw/agents/tester.md` | стадия `testing` | tester | `13-test-report.md` | `result:` | `check_tests_passed:182` → `_parse_tests_verdict:226` (`result:`) | ~60–150k / 5–20 мин | да (через S0) | **C** | `needs-hybrid-fallback` | **avoidable**: PASS/FAIL = exit-code `pytest`+smoke (деривируем); LLM нужен лишь на триаж падений / маппинг TC↔критерии |
+| **A6** | `.openclaw/agents/deployer.md` | стадии `deploy-staging` / `deploy` | deployer | `15-staging-log.md` / `14-deploy-log.md` | `staging_status:` / `deploy_status:` | `check_staging_status:599` → `_parse_staging_status:538` (`staging_status:`); `check_deploy_status:473` → `_parse_deploy_status:413` (`deploy_status:`) | ~40–120k / 3–15 мин | да (через S0) | **C** | `replace-deterministic-now` | **avoidable**: staging-вердикт = маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C (ORCH-036) |
+| **D1** | `src/agents/launcher.py:389` (перехват в `launch_job` **до** `_spawn`; «Not an LLM spawn» `407`) | post-deploy edge | deploy-finalizer | jobs-row | — | — | — (детерминированный) | **нет** (слот, перехват до `_spawn`) | — | `already-deterministic` (эталон) | Занимает слот агента, но LLM не консультируется — рабочий прецедент замены |
+| **D2** | `src/agents/launcher.py:394` (перехват в `launch_job` **до** `_spawn`; «Not an LLM spawn» `428`) | post-deploy observation | post-deploy-monitor | jobs-row | — | — | — (детерминированный) | **нет** (слот, перехват до `_spawn`) | — | `already-deterministic` (эталон) | Тик наблюдения; LLM не консультируется |
+
+> **Итог (поимённо).** `avoidable LLM control paths = {tester, deployer}`; control-path-но-keep =
+> `{reviewer}`; не-control-path (P) = `{analyst, architect, developer}`; already-deterministic-эталон =
+> `{deploy-finalizer, post-deploy-monitor}`.
+
+### 1.1 Машинно-читаемый блок инвентаря
+
+> Стабильный заголовок таблицы (`id | role | location | output_consumer | consults_llm | axis |
+> avoidable | classification`) парсится `tests/test_llm_call_site_inventory.py` (split по `|`, без
+> новых зависимостей) и сверяется с кодом (TC-03/04/05/13/14). **Не менять заголовок и значения без
+> синхронной правки кода/тестов.**
+
+<!-- ORCH-118-INVENTORY-BLOCK:START -->
+| id | role | location | output_consumer | consults_llm | axis | avoidable | classification |
+|----|------|----------|-----------------|--------------|------|-----------|----------------|
+| S0 | _spawn | src/agents/launcher.py:472 | - | transport | - | - | - |
+| A1 | analyst | .openclaw/agents/analyst.md | check_analysis_complete | yes | P | no | keep-LLM |
+| A2 | architect | .openclaw/agents/architect.md | check_architecture_done | yes | P | no | keep-LLM |
+| A3 | developer | .openclaw/agents/developer.md | check_ci_green | yes | P | no | keep-LLM |
+| A4 | reviewer | .openclaw/agents/reviewer.md | check_reviewer_verdict | yes | C | no | keep-LLM |
+| A5 | tester | .openclaw/agents/tester.md | _parse_tests_verdict | yes | C | yes | needs-hybrid-fallback |
+| A6 | deployer | .openclaw/agents/deployer.md | _parse_staging_status | yes | C | yes | replace-deterministic-now |
+| D1 | deploy-finalizer | src/agents/launcher.py:389 | - | no | - | - | already-deterministic |
+| D2 | post-deploy-monitor | src/agents/launcher.py:394 | - | no | - | - | already-deterministic |
+<!-- ORCH-118-INVENTORY-BLOCK:END -->
+
+### 1.2 keep-LLM — названное суждение (обоснование)
+
+> Для каждой `keep-LLM`-записи назван **конкретный** вид суждения, ради которого LLM сохраняется.
+> Для C-keep (`reviewer`) обоснование явно фиксирует **НЕ-деривируемость** вердикта (почему не сводится
+> к exit-коду). Парсится TC-05 (`- role: текст`).
+
+<!-- ORCH-118-KEEP-JUSTIFICATION-BLOCK:START -->
+- analyst: анализ требований и написание BRD/ТЗ — настоящее суждение; детерминированный гейт `check_analysis_complete` судит лишь наличие файлов, не их содержательное качество.
+- architect: архитектурное решение и ADR — настоящее суждение о компромиссах/инвариантах; `check_architecture_done` судит лишь наличие 06-adr/07.
+- developer: написание кода — настоящее суждение; гейт `check_ci_green` судит CI/merge, а не самоотчёт агента.
+- reviewer: «приемлемость кода/решения» — настоящее суждение, которое НЕ деривируемо (not derivable) из exit-кода `pytest`/smoke/деплоя; в отличие от tester/deployer вердикт reviewer'а не сводится к tool-сигналу, поэтому это control-path-но-keep, а не avoidable.
+<!-- ORCH-118-KEEP-JUSTIFICATION-BLOCK:END -->
+
+---
+
+## 2. Таксономия классификации (4 класса, выведена из осей)
+
+Четыре взаимоисключающих класса; класс **выводится** из осей §0 (а не постулируется):
+
+- **`keep-LLM`** — нужно настоящее суждение (обязательно **назвать** конкретное суждение, §1.2).
+- **`replace-deterministic-now`** — безопасная детерминированная замена сейчас.
+- **`replace-later/risky`** — замена возможна позже / с предпосылками.
+- **`needs-hybrid-fallback`** — детерминированное ядро + LLM-фолбэк только на суждение.
+
+**Правило вывода:**
+`P → keep-LLM`; `C + не-деривируемый вердикт → keep-LLM`;
+`C + деривируемый вердикт → replace-* / needs-hybrid-fallback` (**= avoidable**).
+
+`deploy-finalizer`/`post-deploy-monitor` помечены `already-deterministic` — вне таксономии замен
+(эталон: LLM не консультируется, перехват до `_spawn`).
+
+---
+
+## 3. Детерминизм не-агентских control-path'ов (доказательство, FR-3 / AC-3)
+
+Эти пути **не консультируют LLM** (ни через `_spawn`-транспорт, ни альтернативным транспортом). ⚠️ Они
+**спавнят subprocess'ы** (`git`/`pytest`/`docker`/`ssh`/сканеры/`staging_check.py`) — это
+детерминированные **инструменты**, не LLM: доказательство детерминизма — **отсутствие *LLM*-транспорта**,
+а не отсутствие *subprocess* (дискриминатор §0). Проверяется TC-02.
+
+| Путь / модуль | `file:line` (якорь) | Природа |
+|---------------|---------------------|---------|
+| Маршрутизация стадий | `src/stages.py::STAGE_TRANSITIONS:12`, `advance_stage` в `src/stage_engine.py` | статический словарь + детерминированная функция |
+| Реестр Quality Gate | `src/qg/checks.py::QG_CHECKS:812` (14 имён) | словарь имя→функция |
+| Все `check_*` | `src/qg/checks.py` (`33/62/82/182/336/473/599/657`, …) | файловые/HTTP/exit-code проверки |
+| Парсеры вердиктов `_parse_*` | `src/qg/checks.py:226/413/538` через `src/frontmatter.py::parse_frontmatter` | YAML-frontmatter парс (читают, **не производят** вердикт) |
+| Классификатор ошибок | `src/error_classifier.py` | regex по строкам |
+| Под-гейты | `src/{security_gate,merge_gate,coverage_gate,staging_verdict}.py` | сканеры/`pytest --cov`/git/маппинг exit-кодов |
+| Self-deploy Phase A/B/C | `src/self_deploy.py` | детерминированный detached-деплой (ORCH-036) |
+| Сериализация / владение | `src/{serial_gate,transition_lease,reconciler,job_reaper}.py` | FIFO-гейт / durable-lease / CAS / reaper |
+
+Любая найденная **неожиданная** LLM-консультация в этих путях добавляется в инвентарь §1 и
+классифицируется §2 (тогда TC-02 станет красным — точка дрейфа).
+
+---
+
+## 4. Скоуп и анти-дрейф
+
+- **Docs + tests only (ORCH-118).** `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` /
+  machine-verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
+  `coverage_status:`) / схема БД — **байт-в-байт не тронуты**. Раннеры замен **не** реализованы
+  (см. roadmap — follow-up'ы по роли, без Plane-ID).
+- **Анти-дрейф тесты:** `tests/test_llm_call_site_inventory.py` (TC-01…TC-06, TC-09, TC-12, TC-13,
+  TC-14) и `tests/test_llm_determinization_docs.py` (TC-07/08/11). Дискриминатор всех проверок —
+  **«консультирует LLM», а не «спавнит subprocess»**.
+- **Связанные документы:** [`llm-usage-policy.md`](llm-usage-policy.md),
+  [`llm-determinization-roadmap.md`](llm-determinization-roadmap.md).

docs/architecture/llm-determinization-roadmap.md

@@ -0,0 +1,70 @@
+# LLM determinization roadmap (ORCH-118)
+
+> **Что это.** Упорядоченный план детерминированных замен **avoidable LLM control paths**
+> (`{tester, deployer}` — см. [`llm-call-sites.md`](llm-call-sites.md)). Это **транзиентный план**:
+> он обновляется по мере закрытия follow-up'ов. ORCH-118 раннеры **не реализует** (FR-7); старт каждого
+> кандидата гейтится утверждением карты.
+>
+> **Кандидаты названы ПО РОЛИ.** Конкретные follow-up Plane-ID **не фиксируются** ни в одном артефакте
+> (R3 / NFR-6): этих work item нет в подтверждённом backlog; ID присваивается при заведении задачи.
+> Анти-фабрикация прибита тестом `TC-11` (`tests/test_llm_determinization_docs.py`).
+>
+> **Оценки экономии — «оценка до фактического замера» (NFR-5).** Источник — существующие колонки
+> `agent_runs` (`model`/`effort`/токены/стоимость/время); точные числа снимаются при заведении
+> follow-up'а через `GET /metrics` / запрос к `agent_runs`. Здесь — порядок величины, а не контракт.
+
+---
+
+## 1. Рекомендованный первый срез — **deployer (staging-status)**
+
+Обоснование (самый низкорисковый «чисто деривируемый» control path):
+
+1. **Деривируемость максимальна.** Вердикт `staging_status:` — **чистый маппинг** exit-кода
+   `scripts/staging_check.py`; готовый leaf `src/staging_verdict.py::compute_staging_verdict` (ORCH-061)
+   уже считает этот вердикт детерминированно.
+2. **Прод уже детерминирован.** Ребро `deploy` (`deploy_status:`) для self-hosting `orchestrator`
+   производит детерминированный finalizer (Phase A/B/C, ORCH-036) — LLM в критическом
+   self-restart-пути нет. Срез не трогает критический путь → минимальная поверхность риска.
+3. **Опирается на прецедент** `D1`/`D2` (`launch_job`-перехват **до** `_spawn`) — архитектурный риск
+   замены агента уже снят рабочим паттерном.
+4. **`replace-deterministic-now`, без hybrid-fallback** (в отличие от tester).
+
+## 2. Второй кандидат — **tester (гибрид)**
+
+Детерминированное ядро (`pytest` + smoke даёт PASS/FAIL по exit-коду) покрывает основной вердикт;
+LLM-фолбэк сохраняется **только** на суждение, не сводимое к exit-коду: **триаж падений** и **маппинг
+TC ↔ критерии приёмки**. Поэтому `needs-hybrid-fallback`, а не `replace-deterministic-now`: поверхность
+суждения шире и объём работы больше.
+
+## 3. Общие требования к каждому follow-up'у
+
+Каждый кандидат при заведении задачи несёт: kill-switch + обратимость (паттерн
+ORCH-022/027/043/089/090 — флаг `*_enabled`, пустой CSV `*_repos` → self-hosting only), скоуп-гард
+(не трогать `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схему БД), а замена-агента —
+перехват в `launch_job` **до** `_spawn` (как `D1`/`D2`). Свежесть прецедента — инцидент-трек
+ORCH-110/111/112/113/114/117 (единое детерминированное владение side-effectful путями).
+
+---
+
+## 4. Машинно-читаемый блок roadmap
+
+> Заголовок (`rank | role | dependencies | savings_estimate_source | security_risk | hybrid_needed |
+> followup_type | first_slice`) парсится `tests/test_llm_determinization_docs.py::test_tc07_*`.
+> `followup_type` — **по роли**, без Plane-ID. Ровно один `first_slice = yes`.
+
+<!-- ORCH-118-ROADMAP-BLOCK:START -->
+| rank | role | dependencies | savings_estimate_source | security_risk | hybrid_needed | followup_type | first_slice |
+|------|------|--------------|-------------------------|---------------|---------------|---------------|-------------|
+| 1 | deployer | staging_verdict.compute_staging_verdict (ORCH-061) + launch_job pre-spawn precedent (D1/D2) | agent_runs (deployer rows; estimate pending GET /metrics) | low (prod already deterministic via Phase A/B/C ORCH-036) | no | deployer-replacement (staging-status mapping) | yes |
+| 2 | tester | deterministic pytest+smoke core; LLM fallback for failure triage / TC-to-criteria mapping | agent_runs (tester rows; estimate pending GET /metrics) | medium (failure-triage judgment must stay correct) | yes | tester-hybrid (deterministic core + LLM fallback) | no |
+<!-- ORCH-118-ROADMAP-BLOCK:END -->
+
+---
+
+## 5. Вне scope
+
+- `reviewer` — C, но **keep** (вердикт «приемлемость кода/решения» не деривируем): **не** в roadmap'е.
+- `analyst`/`architect`/`developer` — P (artifact-producer, не control path): **не** в roadmap'е.
+- Реализация раннеров — отдельные follow-up задачи (по роли), стартуют после утверждения карты.
+
+Связанные документы: [`llm-call-sites.md`](llm-call-sites.md), [`llm-usage-policy.md`](llm-usage-policy.md).

docs/architecture/llm-usage-policy.md

@@ -0,0 +1,96 @@
+# LLM usage policy (ORCH-118)
+
+> **Нормативный durable-документ.** Формулирует принцип использования LLM в оркестраторе, критерии
+> «keep vs replace» через **control-path-ось**, и нормативное **определение «avoidable LLM control
+> path»**. Применяется ко **всем** будущим правкам control-path'ов. Сопутствующие артефакты —
+> карта [`llm-call-sites.md`](llm-call-sites.md) и roadmap [`llm-determinization-roadmap.md`](llm-determinization-roadmap.md).
+
+---
+
+## 1. Принцип
+
+**LLM — только там, где нужно настоящее суждение.** Если решение/вердикт control-path'а есть
+**детерминированная функция tool-сигналов**, которые оркестратор уже вычисляет (exit-code `pytest`,
+smoke, `staging_check.py`, статус деплоя, наличие файлов, CI-статус), — оно должно приниматься
+**детерминированно**, а не консультацией LLM. LLM сохраняется там, где требуется суждение, **не
+сводимое** к tool-сигналу (анализ требований, архитектурное решение, написание кода, приемлемость
+ревью).
+
+Это защищает **автономность** (NFR-2): меньше точек, где недетерминизм/стоимость/латентность LLM
+встроены в поток управления, и меньше класса инцидентов «LLM-агент принял решение, которое на деле
+есть исполнение фиксированных команд и маппинг результата» (RCA-трек ORCH-110/111/112/113/114/117).
+
+---
+
+## 2. Три оси решения (ground-truth — код)
+
+1. **consultation ≠ transport/slot.** «LLM консультируется» ⇔ решение/артефакт конвейера **потребляет
+   суждение LLM**. Существование транспорта (`_spawn`) или слота агента (job-роли с перехватом до
+   `_spawn`) — это **capability**, не консультация.
+2. **control-path (C) ≠ artifact-producer (P)** — определяется **кодом-потребителем** вывода роли:
+   - **(C)** LLM эмитит machine-verdict, на котором **ветвится `check_*`-гейт** → суждение входит в
+     поток управления.
+   - **(P)** LLM производит артефакт, а продвижение решает **детерминированный гейт** независимо
+     (наличие файлов / CI) → суждение в control flow не входит.
+3. **деривируемость вердикта** — вердикт C-консультации либо детерминированная функция tool-сигналов,
+   либо настоящее суждение, не сводимое к exit-коду.
+
+---
+
+## 3. Нормативное определение «avoidable LLM control path»
+
+Это **двухбитный проверяемый предикат над `src/qg/checks.py`**, а не «удобство на глаз».
+
+<!-- ORCH-118-AVOIDABLE-DEFINITION-BLOCK:START -->
+Call-site является **avoidable LLM control path** тогда и только тогда, когда выполнены **оба** условия:
+- **(i)** это **C (control-path)** консультация — её LLM-вердикт потребляется потоком управления
+  (`check_*`-гейт ветвится на нём: PASS → дальше / FAIL → откат);
+- **(ii)** вердикт **деривируем** (derivable) из tool-сигналов, которые оркестратор уже вычисляет сам —
+  exit-code `pytest` / smoke / `staging_check.py` / статус деплоя.
+
+Если оба условия выполнены, суждение LLM не добавляет информации → консультацию можно снять без потери
+смысла (заменить детерминированным раннером или гибридом с LLM-фолбэком только на не-деривируемую часть).
+<!-- ORCH-118-AVOIDABLE-DEFINITION-BLOCK:END -->
+
+**Поимённый целевой набор** (сверен с кодом, прибит тестами TC-13/TC-14):
+
+- **avoidable LLM control paths = `{tester, deployer}`** — C **и** вердикт деривируем
+  (`result:` = exit-code `pytest`+smoke; `staging_status:` = маппинг exit-кода `staging_check.py`).
+- **`reviewer`** — C, но **keep**: вердикт «приемлемость кода/решения» **НЕ деривируем** из exit-кода
+  (настоящее суждение). Это control-path-но-keep, **не** avoidable.
+- **`analyst` / `architect` / `developer`** — **не** control path (**P**, artifact-producer):
+  детерминированный гейт судит артефакт независимо.
+
+---
+
+## 4. Критерии решения: keep vs replace
+
+| Ситуация (по осям §2) | Решение | Класс |
+|-----------------------|---------|-------|
+| **P** — artifact-producer (детерминированный гейт судит артефакт) | **keep** LLM | `keep-LLM` |
+| **C**, вердикт **НЕ деривируем** (настоящее суждение) | **keep** LLM (назвать суждение) | `keep-LLM` |
+| **C**, вердикт **деривируем**, замена безопасна сейчас | **replace** | `replace-deterministic-now` |
+| **C**, вердикт деривируем, но замена позже / с предпосылками | **replace later** | `replace-later/risky` |
+| **C**, ядро деривируемо, но часть требует суждения | **hybrid** (детерм. ядро + LLM-фолбэк) | `needs-hybrid-fallback` |
+
+> **keep-LLM требует обоснования:** любая `keep-LLM`-запись обязана **назвать конкретное суждение**;
+> для C-keep — явно зафиксировать **не-деривируемость** вердикта (почему не сводится к exit-коду).
+
+---
+
+## 5. Требование к новым/изменённым control-path'ам (норматив)
+
+- **Обоснование против политики.** Любой **новый** или изменённый control-path, который консультирует
+  LLM, обязан в своём ADR обосновать это против настоящей политики: показать, что он **P** (artifact
+  judged independently) **или** **C с не-деривируемым** вердиктом. C-консультация с деривируемым
+  вердиктом — это `avoidable`; её ввод без обоснования reviewer ловит как finding ≥P1.
+- **Reviewer-ось (как ORCH-079) — требование, не реализация гейта.** Политика **рекомендует**
+  reviewer'у проверять соответствие новых control-path'ов настоящей политике; ORCH-118 **не** вводит
+  новый Quality Gate (`QG_CHECKS`/`check_*` не меняются) — это нормативное требование процесса.
+- **Норматив сопровождения.** Меняешь место вызова LLM или потребителя вердикта в `src/qg/checks.py` →
+  обнови карту [`llm-call-sites.md`](llm-call-sites.md) и эту политику **в том же PR** (анти-дрейф
+  держат TC-13/TC-14).
+- **Единственный транспорт.** Единственный разрешённый транспорт LLM-консультации в `src/**` — это
+  `launcher._spawn` (S0). Ввод второго транспорта (новый `_spawn`, импорт `anthropic`/`openai`/иного
+  LLM-SDK, прямой HTTP Anthropic/Claude, второй model-invoking subprocess) запрещён без явного ADR;
+  прибито тестами TC-01/TC-12.

docs/deployment/LITE_SETUP.md

@@ -163,6 +163,18 @@ 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

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 | БД (хост) | Старт |
@@ -133,6 +141,8 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `ORCH_PLANE_API_URL` / `_TOKEN` / `_WORKSPACE_SLUG` | доступ к Plane API |
 | `ORCH_PLANE_WEB_URL` | внешний (браузерный) web-URL Plane для кликабельных ссылок на issue в уведомлениях (ORCH-017); пусто → фолбэк на `ORCH_PLANE_API_URL`, loopback-фолбэк → ссылка опускается |
 | `ORCH_PLANE_WEBHOOK_SECRET` | HMAC-проверка вебхуков Plane |
+| `ORCH_PLANE_TEST_WRITE_ENABLED` | ORCH-117: opt-in реальной записи в Plane из **тест-процесса** (дефолт `false` = default-deny). НЕ kill-switch прод-блока: даже `true` пишет только в sandbox-allowlist (прод-запись из pytest невозможна). В боевом/staging рантайме гард — no-op |
+| `ORCH_PLANE_TEST_SANDBOX_PROJECTS` | ORCH-117: CSV-allowlist sandbox-проектов, куда opt-in разрешает запись из тестов (дефолт = единственный SANDBOX `8c5a3025-…`; пусто → ни один проект из тестов не пишется) |
 | `ORCH_GITEA_URL` / `_TOKEN` / `_WEBHOOK_SECRET` | доступ к Gitea + HMAC |
 | `ORCH_CLAUDE_BIN` | путь к claude CLI |
 | `ORCH_REPOS_DIR` / `ORCH_HOST_REPOS_DIR` | каталог репозиториев (в контейнере / на хосте) |
@@ -216,10 +226,23 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 **Что изолировано (безопасно):**
 - Staging (8501) — отдельная БД (`./data/staging`), отдельный реестр (`ORCH_PROJECTS_JSON` = только sandbox). Прод-проекты не видит.
 - Репозитории разделены, изоляция веток через git worktree (ORCH-2).
+- **Запись в Plane из тест-процесса — sandbox-only fail-closed (ORCH-117).** Тест/worktree-процесс
+  наследует живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены на импорте `plane_sync`);
+  раньше **ничто** не мешало pytest смутировать боевую доску (инцидент ORCH-114 — «ложный Done»).
+  Теперь leaf `src/plane_write_guard.py` врезан в 3 примитива записи `plane_sync`
+  (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) и **в тест-процессе** (детект
+  `pytest`-в-процессе) блокирует запись по умолчанию; разрешена только при opt-in
+  `ORCH_PLANE_TEST_WRITE_ENABLED=true` **И** целевом проекте ∈ `ORCH_PLANE_TEST_SANDBOX_PROJECTS`
+  (sandbox-only — боевой проект запрещён даже при opt-in). Боевой и staging рантаймы
+  (`uvicorn src.main:app`, без pytest в процессе) — гард **no-op**, запись как прежде. Прод-блок
+  **без kill-switch** (выключателя-чёрного-хода нет); второй слой — autouse-floor
+  `tests/conftest.py::_plane_sandbox_only` (по образцу `_no_telegram`). Детали — `CLAUDE.md`
+  «Sandbox-only fail-closed изоляция записи в Plane (ORCH-117)», adr-0046.
 
 **Страховки:**
 - Стадия `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/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,64 @@
+# Блок 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. |
+| **Transition-lease** (`src/transition_lease.py`) | Durable-владение side-effectful переходом стадии: один владелец на задачу (lease на входе + expected-stage CAS на записи), liveness по pid+boot-id. Не даёт конкурентному или после-рестартовому повторному входу дважды применить необратимый эффект (merge / деплой / ratchet). |
+| **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,71 @@
+# Блок 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` | машинный журнал уроков — структурированные отклонения конвейера |
+| `transition_lease` | durable-владение side-effectful переходом стадии: один владелец на задачу, liveness по pid+boot-id (предотвращает двойное применение необратимых эффектов) |
+
+Все изменения схемы — аддитивные и идемпотентные (`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,55 @@
+# Блок 7. Наблюдаемость и аналитика
+
+> Машинный контракт метрик и устройство sidecar-наблюдателя — в
+> [инженерном справочнике](../architecture/README.md) (разделы `/metrics` и sidecar-watchdog).
+
+## Живая Telegram-карточка задачи
+
+Каждая задача — одна карточка в Telegram, обновляемая на каждом событии:
+
+- текущая стадия и Plane-статус (включая человеческие гейты — видно, когда задача ждёт вас);
+- строка работающего агента: роль · модель · эффорт;
+- стоимость задачи нарастающим итогом (токены/доллары по каждому запуску агента);
+- честные метрики времени на финише: время агентов / время ожидания человека / общее
+  календарное — три независимые цифры, а не одна вводящая в заблуждение сумма;
+- кликабельный номер задачи (ведёт в Plane), отметка багфикс-маршрута.
+
+Карточка тихая (без пингов); пингуют только алерты: красный гейт, ожидание решения человека,
+инциденты.
+
+## Служебные страницы платформы
+
+- **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
+  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, владение
+  переходами (`transition_lease`), фоновые демоны. Первая точка диагностики «что сейчас
+  происходит».
+- **`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,79 @@
+# Блок 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.
+
+## Где уместен LLM: карта вызовов и нормативная политика
+
+Платформа держит **доказательную карту** всех мест, где поток управления потребляет суждение
+LLM, и **нормативную политику** «LLM — только там, где нужно настоящее суждение». Карта разводит
+три факта: консультация ≠ транспорт/слот; **control-path** (вердикт LLM ветвит поток управления)
+≠ **artifact-producer** (детерминированный гейт судит артефакт независимо); и деривируемость
+вердикта из tool-сигналов. Путь называется **avoidable LLM control path**, когда он одновременно
+control-path и его вердикт деривируем из exit-кодов (тогда консультацию можно заменить
+детерминированным раннером). Поимённо: avoidable = `{tester, deployer}`; настоящее суждение
+сохраняется у `{analyst, architect, developer, reviewer}`. Карта — снимок, прибитый структурными
+анти-дрейф тестами; реализация замен — отдельные follow-up'ы по роли.
+
+- Карта вызовов LLM: [`../architecture/llm-call-sites.md`](../architecture/llm-call-sites.md)
+- Нормативная политика: [`../architecture/llm-usage-policy.md`](../architecture/llm-usage-policy.md)
+- Порядок замен: [`../architecture/llm-determinization-roadmap.md`](../architecture/llm-determinization-roadmap.md)
+
+## 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-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` (заполняет архитектор).

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

@@ -0,0 +1,145 @@
+---
+work_item: ORCH-109
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
+
+Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения (выбор «выделенные config-ключи vs `agent_timeout_overrides_json`»,
+> точные числовые бюджеты, синхронная правка `reaper_max_running_s`) — задача архитектора (`06-adr`).
+
+## 1. Сводка изменения
+
+Две независимые, но связанные правки в подсистеме запуска агентов:
+
+1. **Launch-time стамп модели.** В `launcher._spawn` резолвенная `resolve_agent_model(...)` (уже
+   вычисляется на launch, строка ~559) записывается в `agent_runs.model` в той же DB-сессии, что и
+   стамп эффорта (ORCH-087, строки ~566–571). Постфактум-парс (`usage.record_usage`,
+   `model=COALESCE(?, model)`) сохраняется как **обогащение** и уже не затирает launch-значение
+   `NULL`'ом. Следствие: модель присутствует на строке прогона с момента запуска, переживает
+   timeout-kill и видна in-flight в `GET /metrics`/`GET /queue`.
+
+2. **Конфигурируемый поднятый wall-clock бюджет для `developer`/`reviewer`.** `_resolve_timeout(agent)`
+   должен возвращать поднятый бюджет для `developer` и `reviewer`, конфигурируемый и не затрагивающий
+   прочие роли; механизм покрыт тестом. Сохраняется never-break (малформный конфиг → глобальный
+   дефолт) и кросс-инвариант reaper (`reaper_max_running_s > max(timeout)+grace`).
+
+Плюс верификационные требования: телеметрия timeout-killed прогона (модель+эффорт не `null`) и
+guard анти-salvage (timeout-killed прогон не продвигает стадию).
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `src/agents/launcher.py` | изменить — стамп `model` в `_spawn` рядом с `effort` (≈ стр. 559–573); проверка `_resolve_timeout` обслуживает override `developer`/`reviewer` (≈ стр. 661–679) |
+| `src/config.py` | изменить — config для поднятого тайм-аута `developer`/`reviewer` (выделенные ключи и/или дефолт `agent_timeout_overrides_json`); обновить комментарии-паспорт (≈ стр. 115–126); проверить/при необходимости поднять `reaper_max_running_s` (≈ стр. 494–499) |
+| `src/usage.py` | проверить/зафиксировать тестом — `record_usage` (`model=COALESCE(?, model)`) НЕ затирает launch-стамп при `model=None` (≈ стр. 207–230); `_extract_model` (≈ стр. 95–118) |
+| `src/notifications.py` | проверить (правка, вероятно, не нужна) — `_stage_line` рендерит `· {model} · {effort}` из `agent_runs` для строки с `exit_code=-9` (≈ стр. 360–373, 498–542) |
+| `src/db.py` | НЕ менять схему — `agent_runs.model` TEXT уже есть; проверить, что `get_running_agents` (≈ стр. 1370–1405) отдаёт launch-стампнутую модель для running-job |
+| `src/stage_engine.py` | проверить — путь продвижения стадии не advance'ит прогон с `exit_code != 0` (guard FR-5); правка только если найден разрыв |
+| `.env.example` | обновить — задокументировать ключи тайм-аута `developer`/`reviewer` (BR-6) |
+| `tests/test_orch109_timeout_model.py` (новый) | создать — покрытие FR-1…FR-5 |
+| `CHANGELOG.md`, `CLAUDE.md` (паспорт), `docs/architecture/README.md` (модель/эффорт-секция) | обновить в том же PR (правило агентов №2) |
+
+## 3. Функциональные требования
+
+### FR-1 — Launch-time стамп модели (BR-1)
+В `launcher._spawn`, после `model = resolve_agent_model(agent, project_id)`, резолвенное значение
+записывается в `agent_runs.model` для текущего `run_id` **в момент launch**, по образцу стампа
+эффорта (ORCH-087):
+- Запись в той же открытой `conn`, что и стамп эффорта (допустимо объединить в один
+  `UPDATE agent_runs SET model=?, effort=? WHERE id=?` — решение реализации).
+- Пустой резолв (`model == ""`, CLI-дефолт без `--model`) → пишется `NULL` (как эффорт: `effort or None`),
+  чтобы суффикс модели в трекере корректно опускался.
+- **Инвариант:** значение `agent_runs.model` присутствует с момента launch и не зависит от исхода
+  прогона.
+- **never-raise (NFR-2):** сбой записи изолирован `try/except` + WARNING; launch продолжается.
+
+### FR-2 — Постфактум-enrich сохраняет launch-стамп (BR-2)
+`usage.record_usage` остаётся источником обогащения (токены/стоимость/модель из usage-JSON), но:
+- При `usage is None` или `usage.get("model") is None` (оборванный/малформный JSON) launch-стамп
+  модели **не затирается** (текущая семантика `model=COALESCE(?, model)` это уже обеспечивает —
+  требование зафиксировать тестом, не регрессировать).
+- При наличии непустой модели в JSON enrich **уточняет** значение (например, полный
+  provider-prefixed id или фактический fallback-model) — допустимая перезапись непустым на непустое.
+- Семантика парсинга `_extract_model` (приоритет `modelUsage` → top-level `model`) — без изменений.
+
+### FR-3 — Конфигурируемый поднятый тайм-аут `developer`/`reviewer` (BR-3)
+- `_resolve_timeout(agent)` возвращает поднятый бюджет для `agent in {"developer","reviewer"}`,
+  конфигурируемый, **детерминированный**, и **не затрагивающий** прочие роли (они продолжают
+  получать глобальный `agent_timeout_seconds`, если для них нет override).
+- Механизм: либо документированный дефолт `agent_timeout_overrides_json`, либо выделенные ключи
+  (например `agent_timeout_developer_s`/`agent_timeout_reviewer_s`) — выбор архитектора; контракт
+  FR-3 — резолв per-agent поднятого бюджета.
+- **never-break (NFR-2):** малформный/невалидный конфиг → откат на глобальный дефолт + WARNING
+  (поведение `_resolve_timeout` сохраняется).
+- **Кросс-инвариант (NFR-4):** итоговый `max(резолвенный тайм-аут)` + `agent_kill_grace_seconds`
+  обязан оставаться `< reaper_max_running_s`; при нарушении — синхронно поднять `reaper_max_running_s`.
+
+### FR-4 — Телеметрия timeout-killed прогона (BR-4)
+Для прогона с `exit_code != 0` без финального usage-JSON (timeout-kill, `_record_kill` стампит -9):
+- Строка стадии трекера (`notifications._stage_line`) рендерит `· {short_model} · {effort}` с
+  реальными значениями (модель **не** `null`), т.к. оба стампнуты на launch (FR-1 + ORCH-087).
+- `db.get_running_agents` (источник `GET /metrics`/`GET /queue`) отдаёт launch-стампнутую модель и
+  для **running**-job (in-flight видимость, NFR-6).
+- Изменения `notifications.py`, вероятно, не требуются (рендер уже читает `model`); требование —
+  верифицировать тестом, что при стампе на launch значение долетает.
+
+### FR-5 — Guard анти-salvage timeout-killed прогона (BR-5)
+- Timeout-killed прогон (`exit_code != 0`, в т.ч. -9/-15/143) `developer`/`reviewer` **не продвигает**
+  стадию (`development → review`, `review → testing`) автоматически.
+- Существующий контракт (advance только при чистом exit-коде + зелёный exit-гейт; иначе
+  `attempts<max → queued`, иначе `failed` + Telegram — `launcher._monitor_agent`/`queue_worker`/
+  `job_reaper`) реализует это структурно.
+- **Требование:** анализ подтверждает достаточность существующей гарантии; поведение фиксируется
+  **регресс-тестом**. Отдельный guard в коде добавляется **только если тест выявит разрыв**.
+- **salvage-режим НЕ вводится** (вне объёма) — задача гарантирует не-продвижение, не возобновление.
+
+### FR-6 — Документация конфига (BR-6)
+- Комментарий-паспорт в `config.py` (блок ORCH-7, строки ~115–126) расширяется описанием поднятых
+  бюджетов `developer`/`reviewer` и ссылкой на reaper-инвариант (NFR-4).
+- `.env.example` несёт соответствующие ключи с дефолтами = боевым значениям (канон ORCH-101).
+- Сквозная документация (`CLAUDE.md`, `docs/architecture/README.md` — таблица «модель/эффорт по
+  ролям») обновляется в том же PR.
+
+## 4. Изменения API
+
+Нет. Ни одного нового/изменённого endpoint'а. `GET /metrics` и `GET /queue` отдают тот же контракт
+(`schema_version: 1`) — поле `agents[].model` лишь **начинает заполняться** для running-job
+(аддитивное улучшение данных, не контракта; sidecar обязан толерировать, ORCH-099 NFR-6).
+
+## 5. Изменения схемы БД
+
+Нет. Колонка `agent_runs.model` (`TEXT`, NULLABLE) уже существует (`db._ensure_column`, инициализация
+`init_db`). Никаких `CREATE`/`ALTER`/новых таблиц. Меняется только **момент** и **частота** записи в
+существующую колонку (launch + опциональный постфактум-enrich).
+
+## 6. Требования к новым/изменённым QG checks
+
+Нет. `QG_CHECKS` / `check_*` / `_parse_*` / machine-verdict ключи — не трогаются. Задача целиком вне
+слоя Quality Gate (подсистема launch/телеметрия/конфиг). FR-5 опирается на **существующий**
+exit-code-контракт продвижения, не на новый гейт.
+
+## 7. Совместимость / регресс
+
+- **Обратная совместимость:** стамп модели аддитивен; при пустом timeout-override поведение
+  байт-в-байт прежнее (NFR-1). Никаких kill-switch не требуется — изменение не вводит новых ветвей
+  риска (стамп модели всегда безопасен; тайм-аут конфигурируем и fail-safe на глобальный дефолт).
+- **Область раската:** стамп модели — все репо/роли (безопасно). Поднятый тайм-аут — только
+  `developer`/`reviewer` (все репо, т.к. тайм-аут глобален per-agent); прочие роли неизменны.
+- **Обратимость:** вернуть тайм-аут — снять override-конфиг (откат на 1800s). Launch-стамп модели
+  отката не требует (чистое улучшение телеметрии).
+- **Кросс-каттинг (NFR-4):** при поднятии бюджета выше `reaper_max_running_s − grace` синхронно
+  поднять `reaper_max_running_s` (ORCH-065). Sanity-тест конфига стережёт инвариант.
+- **never-raise (NFR-2):** обе правки изолированы; сбой не роняет launch и не падает на старте при
+  плохом env.
+- **Self-hosting (NFR-5):** ни рестарта прода, ни изменения deploy-пути; общий инстанс безопасен.
+- **Полный регресс `tests/`** остаётся зелёным; coverage-гейт (ORCH-027) удовлетворён новым
+  тест-файлом (изменения в `src/` минимальны и покрыты).

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

@@ -0,0 +1,139 @@
+---
+work_item: ORCH-109
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-109 — timeout budgets + launch-time model telemetry
+
+Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
+
+---
+
+## AC-1 — Модель стампится в `agent_runs.model` в момент launch
+
+**Условие:** запуск любого агента через `launcher._spawn` записывает резолвенную модель в
+`agent_runs.model` строки прогона ДО завершения процесса.
+- **PASS:** после стампа на launch (`UPDATE agent_runs SET model=…`/объединённый с effort)
+  `SELECT model FROM agent_runs WHERE id=<run_id>` возвращает `resolve_agent_model(agent)` (непустую
+  модель для текущей конфигурации — `claude-opus-4-8`); при пустом резолве — `NULL`. Запись
+  происходит рядом со стампом эффорта (`launcher._spawn`).
+- **FAIL:** модель пишется только в `usage.record_usage` (постфактум); строка прогона имеет
+  `model IS NULL` до завершения; стамп не изолирован и роняет launch при ошибке БД.
+
+---
+
+## AC-2 — Постфактум-enrich не затирает launch-стамп при оборванном JSON
+
+**Условие:** `usage.record_usage` с отсутствующей/`None`-моделью не обнуляет launch-стампнутую модель.
+- **PASS:** `record_usage(run_id, None)` и `record_usage(run_id, {... "model": None})` для строки с
+  launch-стампнутой моделью → `model` остаётся прежним непустым (семантика `COALESCE(?, model)`);
+  `record_usage(run_id, {... "model": "claude-opus-4-8"})` → модель проставлена/уточнена.
+- **FAIL:** оборванный/малформный JSON приводит к `model = NULL`; enrich затирает корректный
+  launch-стамп.
+
+---
+
+## AC-3 — Тайм-аут `developer`/`reviewer` поднят и конфигурируем без влияния на прочие роли
+
+**Условие:** `launcher._resolve_timeout(agent)` возвращает поднятый бюджет для `developer`/`reviewer`
+и неизменный глобальный дефолт для остальных.
+- **PASS:** при сконфигурированном override `_resolve_timeout("developer")` и
+  `_resolve_timeout("reviewer")` возвращают поднятые значения; `_resolve_timeout("analyst")`,
+  `("architect")`, `("tester")`, `("deployer")` возвращают `settings.agent_timeout_seconds` (1800 по
+  умолчанию). Конфигурация описана в `config.py` и `.env.example`.
+- **FAIL:** изменён бюджет роли вне `{developer, reviewer}`; значение захардкожено; бюджет не
+  настраивается через config.
+
+---
+
+## AC-4 — Малформный timeout-конфиг → безопасный откат (never-break)
+
+**Условие:** невалидный/малформный конфиг тайм-аутов не роняет прогон и не ломает старт.
+- **PASS:** при малформном `agent_timeout_overrides_json` (или невалидном выделенном ключе)
+  `_resolve_timeout(...)` возвращает глобальный дефолт + пишет WARNING; процесс не падает.
+- **FAIL:** исключение пробрасывается; прогон/старт падает на плохом env.
+
+---
+
+## AC-5 — Reaper-инвариант сохранён
+
+**Условие:** `reaper_max_running_s > max(резолвенный тайм-аут любого агента) + agent_kill_grace_seconds`.
+- **PASS:** с применённой конфигурацией бюджетов sanity-тест подтверждает неравенство для всех ролей
+  (`developer`/`reviewer` включительно); при необходимости `reaper_max_running_s` поднят синхронно.
+- **FAIL:** поднятый бюджет `developer`/`reviewer` + grace ≥ `reaper_max_running_s` → job-reaper может
+  реапнуть здоровый долгий прогон.
+
+---
+
+## AC-6 — Строка стадии трекера показывает модель+эффорт при timeout/kill
+
+**Условие:** для прогона с `exit_code = -9` (timeout-kill) с launch-стампнутыми model+effort строка
+стадии рендерит оба значения.
+- **PASS:** `notifications`-рендер строки стадии (`_stage_line`) для такого `agent_runs`-ряда содержит
+  ` · <short_model> · <effort>` (например `· opus-4-8 · xhigh`); модель **не** `null`/пустая.
+- **FAIL:** при `exit_code=-9` строка показывает стоимость без модели (суффикс модели опущен), т.к.
+  `model IS NULL`.
+
+---
+
+## AC-7 — In-flight видимость модели в `/metrics` и `/queue`
+
+**Условие:** `db.get_running_agents` отдаёт модель для **running** job'а (до завершения прогона).
+- **PASS:** для running-job с launch-стампнутой моделью `get_running_agents()[i]["model"]` непуст;
+  `GET /metrics` `agents[].model` непуст для активного агента.
+- **FAIL:** `model` остаётся `null` для running-job до завершения прогона.
+
+---
+
+## AC-8 — Timeout-killed прогон не продвигает стадию (анти-salvage)
+
+**Условие:** прогон `developer`/`reviewer` с `exit_code != 0` (timeout-kill) не вызывает переход
+`development → review` / `review → testing`.
+- **PASS:** регресс-тест подтверждает, что прогон с `exit_code = -9` не продвигает стадию
+  автоматически (следует retry/fail-пути; advance — только при чистом exit + зелёный exit-гейт).
+  Salvage-режим отсутствует.
+- **FAIL:** убитый по тайм-ауту прогон «протекает» в следующую стадию без явного решения; либо введён
+  неявный auto-salvage.
+
+---
+
+## AC-9 — Неприкосновенность контрактов и схемы
+
+**Условие:** задача не трогает машину стадий, гейты и схему БД.
+- **PASS:** диффы НЕ содержат изменений `STAGE_TRANSITIONS`, реестра `QG_CHECKS`, `check_*`/`_parse_*`,
+  machine-verdict ключей, `CREATE TABLE`/`ALTER TABLE`. `agent_runs.model` используется как есть.
+- **FAIL:** любое из перечисленного изменено.
+
+---
+
+## AC-10 — Документация и регресс
+
+**Условие:** конфиг задокументирован, полный регресс зелёный.
+- **PASS:** комментарий-паспорт в `config.py` (блок ORCH-7) и `.env.example` описывают бюджеты
+  `developer`/`reviewer`; `CHANGELOG.md`/`CLAUDE.md`/`docs/architecture/README.md` обновлены в том же
+  PR; `pytest tests/ -q` зелёный; новые тесты ORCH-109 проходят.
+- **FAIL:** конфиг не задокументирован; документация рассинхронизирована с кодом; регресс красный.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-2 |
+| AC-3 | BR-3 / FR-3 |
+| AC-4 | BR-3 / FR-3 / NFR-2 |
+| AC-5 | NFR-4 / FR-3 |
+| AC-6 | BR-4 / FR-4 |
+| AC-7 | BR-4 / FR-4 / NFR-6 |
+| AC-8 | BR-5 / FR-5 |
+| AC-9 | NFR-1 / NFR-3 / FR-5 |
+| AC-10 | BR-6 / FR-6 / NFR-1 |

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

@@ -0,0 +1,94 @@
+work_item: ORCH-109
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+title: "Timeout budgets + launch-time model telemetry для developer/reviewer"
+framework: pytest
+scope: >
+  Покрывает: launch-time стамп модели в agent_runs.model (FR-1), сохранение launch-стампа
+  постфактум-enrich'ем (FR-2), конфигурируемый поднятый тайм-аут developer/reviewer без влияния
+  на прочие роли (FR-3) + never-break на малформном конфиге, reaper-инвариант (NFR-4), видимость
+  модели+эффорта в строке трекера при timeout-kill (FR-4) и in-flight в get_running_agents (NFR-6),
+  guard анти-salvage — timeout-killed прогон не продвигает стадию (FR-5). Вне покрытия: model-routing,
+  salvage недоделанной работы, изменения STAGE_TRANSITIONS/QG_CHECKS/схемы (их и не должно быть).
+notes: >
+  Тесты детерминированы, без сети/LLM/subprocess Claude CLI: используют временную SQLite-БД и
+  синтетические agent_runs-ряды; настройки подменяются через monkeypatch/override settings.
+  Полный регресс tests/ должен оставаться зелёным; новый файл tests/test_orch109_timeout_model.py.
+  Любой найденный разрыв в FR-5 закрывается guard'ом + тестом; если разрыва нет — TC-08 фиксирует
+  существующую гарантию как анти-регресс.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "_resolve_timeout('developer') и ('reviewer') возвращают поднятый сконфигурированный бюджет"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "_resolve_timeout для analyst/architect/tester/deployer возвращает глобальный agent_timeout_seconds (1800) — прочие роли не затронуты"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Малформный/невалидный timeout-конфиг -> _resolve_timeout откатывается на глобальный дефолт + WARNING, без исключения (never-break)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Launch стампит agent_runs.model: после стамп-блока _spawn строка прогона имеет model == resolve_agent_model(agent) (непустую), рядом с effort"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Стамп модели изолирован: сбой записи (битый conn) не пробрасывает исключение из launch-пути (never-raise, NFR-2)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "record_usage(run_id, None) и record_usage с model=None НЕ затирают launch-стампнутую модель (COALESCE preserve, FR-2)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "record_usage с непустой model в usage-JSON уточняет/проставляет agent_runs.model (enrich по-прежнему работает)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Sanity reaper-инварианта: reaper_max_running_s > max(резолвенный тайм-аут всех ролей) + agent_kill_grace_seconds (NFR-4)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "Строка стадии трекера (_stage_line) для agent_runs с exit_code=-9 и launch-стампнутыми model+effort рендерит ' · <short_model> · <effort>' (model не null)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "get_running_agents отдаёт непустую model для running-job с launch-стампнутой моделью (in-flight видимость /metrics /queue, NFR-6)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "Анти-salvage: прогон developer/reviewer с exit_code=-9 не продвигает стадию (development->review / review->testing) автоматически; следует retry/fail-пути"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: "Анти-регресс контрактов: STAGE_TRANSITIONS/QG_CHECKS/check_* и схема agent_runs не изменены (модель пишется в существующую колонку, миграции нет)"
+    module: tests/test_orch109_timeout_model.py
+    expected: PASS

docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md

@@ -0,0 +1,221 @@
+---
+work_item: ORCH-109
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Поднятые wall-clock бюджеты developer/reviewer + launch-time стамп модели
+
+Work Item: **ORCH-109** — timeout budgets + launch-time model telemetry для developer/reviewer
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`**
+(решение кросс-каттинговое: меняет два глобальных per-agent инварианта подсистемы запуска —
+бюджеты тайм-аутов всех репо и потолок Tier-3 reaper'а ORCH-065).
+
+## Статус
+Proposed   <!-- Proposed | Accepted | Superseded by ADR-… -->
+
+## Контекст
+
+Инцидент **ORCH-104** (runs 658/659/660) вскрыл два независимых дефекта подсистемы запуска агентов
+(`src/agents/launcher.py`), верифицированных по коду:
+
+- **Дефект A — единый тайм-аут для всех ролей.** `_resolve_timeout(agent)` (launcher.py ≈661–679)
+  возвращает `settings.agent_timeout_seconds = 1800` (config.py:124) для **всех** ролей, если в
+  `agent_timeout_overrides_json` нет записи (в проде он пуст: `""`, config.py:126). Тяжёлые роли
+  `developer` (effort `xhigh`, кодирующая) и `reviewer` (effort `high`, читает диф + пишет ревью)
+  **честно** упираются в 1800s и убиваются watchdog'ом (`_watchdog → stop_process`, exit_code=-9
+  через `_record_kill`, launcher.py:778–786). Механические роли (`tester`/`deployer`, effort
+  `medium`) в этот бюджет укладываются.
+- **Дефект B — потеря модели в телеметрии при обрыве.** `agent_runs.model` пишется только
+  постфактум — из финального usage-JSON в `usage.record_usage` (`model=COALESCE(?, model)`,
+  usage.py:217). Убитый по тайм-ауту прогон не успевает эмитить финальный JSON → `_extract_model`
+  даёт `None` → модель остаётся `NULL` ровно тогда, когда она критична для разбора инцидента.
+  При этом **эффорт уже стампится на launch** (ORCH-087, launcher.py:566–571, `UPDATE agent_runs
+  SET effort=? WHERE id=?`), потому что CLI его в result-JSON не отдаёт; модель в той же точке
+  **резолвится** (`model = resolve_agent_model(...)`, launcher.py:559), но в БД на launch **не
+  пишется**.
+
+Установленные факты (по коду, не изобретены):
+- Колонка `agent_runs.model TEXT` (NULLABLE) уже существует (`db.py:111`, `_ensure_column`) —
+  **миграции нет**.
+- `record_usage` уже использует `model=COALESCE(?, model)` → `None` не затирает ранее проставленное
+  значение (usage.py:217). Не хватает только записи на launch.
+- `db.get_running_agents()` уже отдаёт `r.model AS model` (`db.py` ≈1370–1405) — running-job увидит
+  модель **сразу** после launch-стампа, без правки SELECT.
+- `notifications._stage_line` рендерит `· {model} · {effort}` из строки `agent_runs` — увидит
+  launch-стампнутую модель даже для `exit_code=-9`, без правки.
+- Продвижение стадии гейтится `if exit_code == 0: self._try_advance_stage(...)` (launcher.py:951–952);
+  иначе → `_finalize_job` (launcher.py:957) → retry/fail. Timeout-kill (-9) **структурно** не
+  продвигает стадию.
+- Кросс-инвариант reaper (ORCH-065): `reaper_max_running_s = 3600` (config.py:497) c зафиксированным
+  правилом «MUST be > max agent_timeout + grace» (config.py:480–482; `job_reaper.py:43,228`).
+  Сейчас `3600 > 1800 + 20 = 1820` ✓. **Любое поднятие бюджета обязано пересчитать это неравенство.**
+- Sidecar-watchdog (`watchdog/`, ORCH-100) — **наблюдатель**, процессы **не убивает**; сигнал
+  `agent_hung` (runtime > `agent_hung_min`=20м **И** cpu < 1%) — только Telegram-алерт. Кому
+  принадлежит kill — исключительно in-process `launcher._watchdog`.
+
+Почему «как есть» не годится: единый бюджет 1800 системно убивает здоровые тяжёлые прогоны при
+пакетном автономном прогоне (эпик ORCH-088), а телеметрия теряет модель именно на этих обрывах.
+
+## Решение
+
+### Сводка
+Две аддитивные, изолированные правки подсистемы запуска, **без** касания
+`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы БД:
+(1) стамп резолвенной модели в `agent_runs.model` **в момент launch** рядом со стампом эффорта;
+(2) **выделенные типизированные config-ключи** поднятого wall-clock бюджета для `developer`/`reviewer`
+с синхронным поднятием `reaper_max_running_s` (сохранение инварианта ORCH-065).
+FR-5 (анти-salvage) и FR-4/NFR-6 (видимость при kill / in-flight) — **структурно уже выполнены**
+существующим кодом; ORCH-109 добавляет к ним регресс-тесты, а не новые ветви.
+
+### D1 — Launch-time стамп модели (FR-1, AC-1)
+В `launcher._spawn`, в той же открытой `conn`, что и стамп эффорта (ORCH-087), резолвенная
+`model = resolve_agent_model(agent, project_id)` (уже вычислена, launcher.py:559) записывается в
+`agent_runs.model` текущего `run_id`. Рекомендуется **объединить** в один оператор:
+`UPDATE agent_runs SET model=?, effort=? WHERE id=?` с параметрами `(model or None, effort or None, run_id)`
+(один commit вместо двух; ровно та же `try/except`-изоляция, что у эффорта).
+- Пустой резолв (`model == ""`, CLI-дефолт без `--model`) → пишется `NULL` (симметрично `effort or None`)
+  → суффикс модели в трекере корректно опускается.
+- **Инвариант:** значение присутствует с момента launch и не зависит от исхода прогона (переживает
+  timeout-kill, виден in-flight).
+- **never-raise (NFR-2):** сбой записи изолирован существующим `try/except` + WARNING; launch
+  продолжается (`model_flag` строится из локальной `model`, а не из БД — стамп лишь телеметрия).
+
+### D2 — Постфактум-enrich сохраняет launch-стамп (FR-2, AC-2) — без кода
+`usage.record_usage` остаётся источником обогащения (токены/стоимость/модель из usage-JSON), но
+**перестаёт быть единственным источником истины** о модели. Семантика `model=COALESCE(?, model)`
+(usage.py:217) **уже** гарантирует: `usage=None` или `usage["model"]=None` → launch-стамп НЕ
+затирается; непустая модель из JSON — допустимо уточняет (полный provider-prefixed id / фактический
+fallback). **Код не меняется**; требование — зафиксировать поведение тестом (анти-регресс), не
+сломать его будущими правками `record_usage`.
+
+### D3 — Конфигурируемый поднятый бюджет: выделенные типизированные ключи (FR-3, AC-3/AC-4)
+Вводятся два **выделенных** config-ключа (по образцу `agent_model_<role>`/`agent_effort_<role>`,
+config.py:133–138/147):
+
+```python
+agent_timeout_developer_s: int = 3600   # env ORCH_AGENT_TIMEOUT_DEVELOPER_S
+agent_timeout_reviewer_s:  int = 3000   # env ORCH_AGENT_TIMEOUT_REVIEWER_S
+```
+
+`_resolve_timeout(agent)` получает детерминированную лестницу приоритетов (от высшего):
+1. **`agent_timeout_overrides_json[agent]`** — существующий операторский escape-hatch; сохраняется
+   как высший приоритет (полная BC: сконфигурированный JSON по-прежнему выигрывает для ЛЮБОЙ роли).
+2. **выделенный ключ роли** — `developer → agent_timeout_developer_s`,
+   `reviewer → agent_timeout_reviewer_s`.
+3. **`settings.agent_timeout_seconds`** (1800) — для всех прочих ролей (`analyst`/`architect`/
+   `tester`/`deployer`) — **байт-в-байт прежнее значение**.
+
+**never-break (NFR-2, AC-4):** малформный `agent_timeout_overrides_json` → уже игнорируется + WARNING
+(launcher.py:677–678). Для выделенных ключей добавляется такой же защитный гард: если резолвенное
+значение не положительный int (абсурд/0/отрицательное) → откат на `agent_timeout_seconds` + WARNING
+(зеркало защитной валидации disk_monitor, ORCH-063 D7). Прогон/старт не падает.
+
+**Почему выделенные ключи, а не дефолт `agent_timeout_overrides_json`:** см. «Альтернативы».
+
+### D4 — Числовые бюджеты + синхронное поднятие reaper (FR-3/NFR-4, AC-5)
+| Роль | Бюджет | Обоснование |
+|------|--------|-------------|
+| `developer` | **3600s (60м)** | бутылочное горло (xhigh, кодирующая); удвоение 1800→3600 — естественная разрядка для тяжёлых задач |
+| `reviewer` | **3000s (50м)** | асимметрично легче developer, но тяжелее механических ролей; большой диф + high-reasoning |
+| прочие | 1800s (без изменений) | механические/думающие роли укладываются в дефолт |
+
+`reaper_max_running_s`: **3600 → 5400 (90м)** синхронно (config.py:497).
+
+**Проверка инварианта ORCH-065** `reaper_max_running_s > max(резолвенный тайм-аут) + agent_kill_grace_seconds`:
+`5400 > 3600 + 20 = 3620` ✓ (запас **1780s** — покрывает и окно финализации монитора:
+commit/push/PR/usage-comments, Tier-2 `reaper_finalize_grace_s`=300). Дополнительно `5400 < `
+sidecar `stage_stuck_s` (7200s/120м) → легитимный длинный developer-прогон не порождает ложный
+`stage_stuck`-алерт.
+
+Бюджеты — **глобальные per-agent** (не repo-scoped): действуют на все репо, включая enduro-trails.
+Это благоприятно/нейтрально (enduro-developer тоже получает воздух; Tier-3 backstop reaper'а
+сохраняется как страховка от реально зависшего прогона — R-4).
+
+### D5 — FR-5 анти-salvage: регресс-тест, без нового кода (AC-8)
+Гарантия «timeout-killed прогон не продвигает стадию» **структурна**: `_try_advance_stage` вызывается
+только под `if exit_code == 0` (launcher.py:951–952); kill (-9/-15/143) → `_finalize_job` →
+`_finalize_transient`/`_finalize_permanent` (retry до `MAX_DEVELOPER_RETRIES`, иначе `failed` +
+Telegram). **Новый guard в коде НЕ вводится** (не плодить лишние ветви риска) — добавляется
+регресс-тест, фиксирующий, что прогон с `exit_code=-9` не вызывает `advance_stage`. salvage-режим
+вне объёма.
+
+### D6 — Документация и канон дефолтов (FR-6, AC-10)
+- `config.py` блок ORCH-7 (≈115–126): паспорт-комментарий расширяется описанием выделенных бюджетов
+  developer/reviewer + явной ссылкой на reaper-инвариант (NFR-4) с числами `5400 > 3620`.
+- `.env.example`: **сейчас агент-тайм-аут ключей нет вовсе** (`ORCH_AGENT_TIMEOUT_SECONDS`/
+  `_KILL_GRACE_SECONDS`/`_OVERRIDES_JSON` отсутствуют) → добавляется новый блок «Agent timeout
+  (ORCH-7/ORCH-109)» с пятью ключами (`SECONDS`/`KILL_GRACE_SECONDS`/`OVERRIDES_JSON`/
+  `DEVELOPER_S`/`REVIEWER_S`) **+ обновляется `ORCH_REAPER_MAX_RUNNING_S=3600 → 5400`** (line 377).
+  Дефолты = боевым значениям (канон ORCH-101): пустой `.env` воспроизводит прод-поведение, в т.ч.
+  поднятые бюджеты.
+- Архитектурная golden source (этот PR, авторство architect): `docs/architecture/README.md`
+  (бюллет Agent Launcher), `docs/architecture/internals.md` (стр. 96/262 — «timeout 30 мин»
+  расхардкоживается в per-role). Паспорт `CLAUDE.md` + `CHANGELOG.md` — обновляет developer в том
+  же PR (правило агентов №2).
+
+### Согласование BR-3 ↔ NFR-1 (важный нюанс)
+NFR-1 требует «при пустом override-конфиге поведение байт-в-байт прежнее», а BR-3 требует «бюджеты
+developer/reviewer подняты». Разрешение по канону **ORCH-101** («дефолт каждого параметра = боевому
+значению; пустой `.env` ⇒ боевое поведение»): выделенные ключи **дефолтят на поднятый прод-бюджет**,
+поэтому пустой `.env` даёт уже исправленное (поднятое) поведение для developer/reviewer — это и есть
+намеренная боевая конфигурация. «Байт-в-байт прежнее» строго применяется к **прочим ролям**
+(`analyst`/`architect`/`tester`/`deployer` остаются на 1800) — что и есть суть BR-3 (поднять ТОЛЬКО
+две роли). Зафиксировано явно, чтобы reviewer не прочитал поднятый дефолт как нарушение NFR-1.
+
+## Альтернативы
+- **Дефолт `agent_timeout_overrides_json = {"developer":3600,"reviewer":3000}`** (вместо выделенных
+  ключей) — отвергнуто: (1) ломает канон ORCH-101 «пустой = боевой» неочевидным непустым JSON-строковым
+  дефолтом; (2) JSON-строка хрупка (парс, экранирование) против типизированного int; (3) нельзя
+  переопределить одну роль одной env-переменной; (4) расходится с конвенцией per-agent скаляров
+  (`agent_model_<role>`/`agent_effort_<role>`). Выделенные ключи дают типобезопасность, индивидуальный
+  env-override и сохраняют JSON как чистый escape-hatch.
+- **Бюджет developer/reviewer ≤ 3580 без поднятия reaper** (например 3000/2700) — отвергнуто как
+  доминирующее, но рассмотрено: держит `reaper_max_running_s=3600` нетронутым (меньший blast-radius),
+  но искусственно урезает самую тяжёлую роль ради статичности backstop-числа — оптимизация не той
+  переменной. NFR-4 **явно делегирует** архитектору синхронное поднятие reaper. Оставлено как
+  операторский запасной путь: всё env-override'имо, Owner может занизить бюджеты и вернуть reaper к
+  3600 одной правкой `.env` (см. «Откат»).
+- **Новый guard-leaf анти-salvage** (FR-5) — отвергнуто: продвижение уже гейтится exit-кодом
+  (launcher.py:951); новый код = лишняя ветвь риска. Достаточно регресс-теста (D5).
+- **Repo-scoped бюджеты (`*_repos`)** — отвергнуто: тайм-аут — свойство launch, не гейт-решение;
+  глобальность благоприятна enduro и проще; гейт-паттерн `applies(repo)` тут неуместен.
+- **Стамп модели через постфактум-парс лога на kill** — отвергнуто: модель известна на launch
+  детерминированно (`resolve_agent_model`); парсить оборванный лог — хрупко и поздно.
+
+## Последствия
+- **+** Модель видна (не `null`) в трекере, status-комментариях, `/metrics`/`/queue` для **любого**
+  исхода, включая timeout-kill — ключевой контекст инцидента доступен в момент сбоя (BR-1/BR-4/NFR-6).
+- **+** Тяжёлые роли получают реальный бюджет (developer ×2, reviewer +67%) → меньше ложных
+  timeout-kill на сложных задачах при автономном прогоне (ORCH-088).
+- **+** Аддитивно/обратимо: ни схемы, ни гейтов, ни новых компонентов; `agent_runs.model` уже есть.
+- **−** `reaper_max_running_s` 60→90м: реально зависший прогон (двойной отказ — watchdog-поток **и**
+  pid-liveness) держится Tier-3 backstop'ом на 30м дольше. Митигейшн: Tier-1 (pid) и Tier-2
+  (finalize-grace) ловят типовые случаи быстрее; watchdog убивает в ≤3600s; double-fault редок.
+- **−** Глобальность бюджета поднимает и enduro-роли. Митигейшн: Tier-3 reaper сохранён (R-4);
+  поднятие благоприятно для качества enduro-прогонов.
+- **−** Sidecar `agent_hung_min`=20м теперь заметно ниже бюджета developer (60м) → возможны
+  Telegram-алерты `agent_hung` для здоровых длинных прогонов с low-CPU фазами. Митигейшн: сигнал —
+  **alert-only** (не убивает) и конъюнкция с `cpu<1%` гасит большинство ложных; тюнинг
+  `WATCHDOG_AGENT_HUNG_MIN` — вне объёма (отдельный sidecar-конфиг, alert-only). Детали — `10-tech-risks.md` TR-5.
+- **Откат:** занизить бюджеты — снять/уменьшить `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S`
+  (или выставить = 1800) и вернуть `ORCH_REAPER_MAX_RUNNING_S=3600`; launch-стамп модели отката не
+  требует (чистое улучшение телеметрии, COALESCE безопасен). Kill-switch не вводится — изменение не
+  добавляет рисковых ветвей (стамп всегда безопасен; тайм-аут fail-safe на глобальный дефолт).
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-109/01-brd.md`
+- TRZ: `docs/work-items/ORCH-109/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-109/03-acceptance-criteria.md`
+- Tech-risks: `docs/work-items/ORCH-109/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`
+- Сверено по коду: `src/agents/launcher.py` (`_spawn` 559–571, `_resolve_timeout` 661–679,
+  `_watchdog`/`stop_process`/`_record_kill` 681–786, advance-гейт 951–952), `src/usage.py`
+  (`_extract_model` 95–118, `record_usage` 207–230), `src/config.py` (115–126, 480–497),
+  `src/db.py` (`agent_runs.model` 111, `get_running_agents` ≈1370–1405), `src/job_reaper.py`
+  (43, 228), `watchdog/config.py`/`watchdog/signals.py` (agent_hung/stage_stuck)
+- Маркер-инвариант: ORCH-065 (reaper Tier-3), ORCH-087 (стамп эффорта), ORCH-101 (канон дефолтов)

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

@@ -0,0 +1,42 @@
+---
+work_item: ORCH-109
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-109 — timeout budgets + launch-time model telemetry
+
+Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | Поднятый бюджет developer/reviewer + grace ≥ `reaper_max_running_s` → job-reaper реапает **здоровый** долгий прогон до его watchdog'а (нарушение инварианта ORCH-065) | Низ. | Выс. | reaper синхронно поднят 3600→5400; sanity-тест проверяет `reaper_max_running_s > max(timeout)+grace` для всех ролей (`5400 > 3620`, запас 1780s); число живёт в `config.py` + `.env.example` рядом с инвариантом-комментарием (ADR D4/AC-5) |
+| TR-2 | Постфактум-enrich (`record_usage`) затирает корректный launch-стамп при странном/оборванном JSON (`model=None`) | Низ. | Сред. | Семантика `model=COALESCE(?, model)` (usage.py:217) уже сохраняет launch-значение; зафиксировано регресс-тестом (AC-2); `record_usage` не правится |
+| TR-3 | Гонка двух писателей `exit_code` (`_record_kill`=-9 и `_monitor_agent`=`proc.wait()`) искажает телеметрию модели | Низ. | Низ. | Модель — отдельная колонка, стампится один раз на launch до обоих писателей exit_code; они трогают только `exit_code`/`finished_at`. Подтверждается тестом (AC-1/AC-6) |
+| TR-4 | Глобальность бюджета: поднятый developer-тайм-аут для **enduro** маскирует реально зависший прогон | Низ. | Сред. | Tier-3 backstop reaper'а (`reaper_max_running_s`) сохранён как абсолютный потолок; watchdog по-прежнему убивает в ≤ бюджета; бюджет лишь повышен, не снят |
+| TR-5 | Sidecar `agent_hung_min`=20м заметно ниже бюджета developer (60м) → Telegram-алерты `agent_hung` для здоровых длинных прогонов | Сред. | Низ. | Сигнал **alert-only** (sidecar — наблюдатель, не убивает, ORCH-100); конъюнкция с `cpu<1%` гасит активный прогон; тюнинг `WATCHDOG_AGENT_HUNG_MIN` — вне объёма (отдельный sidecar-конфиг). Бюджет 5400s < `stage_stuck_s`=7200s → `stage_stuck` не ложит |
+| TR-6 | Сбой записи launch-стампа модели (ошибка БД) роняет launch | Низ. | Выс. | Стамп в существующем `try/except` ORCH-087 + WARNING (never-raise, NFR-2); `model_flag` строится из локальной переменной, не из БД → launch не зависит от стампа (ADR D1) |
+| TR-7 | Малформный/невалидный timeout-конфиг (битый JSON, нечисловой/отрицательный ключ) роняет прогон или старт | Низ. | Сред. | Малформный JSON → игнор + WARNING (существующее, launcher.py:677); выделенный ключ вне диапазона → откат на глобальный дефолт + WARNING (защитная валидация по образцу ORCH-063 D7); pydantic ловит нечисловой env на старте (AC-4) |
+| TR-8 | Регресс прочих ролей: правка `_resolve_timeout` случайно меняет бюджет `analyst`/`architect`/`tester`/`deployer` | Низ. | Сред. | Лестница приоритетов: dev/reviewer — только по точному имени роли; прочие падают на `agent_timeout_seconds` (1800) без изменений; покрыто тестом per-role (AC-3) |
+| TR-9 | Доп. риск контрактов: правка случайно задевает `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схему | Низ. | Выс. | Задача целиком вне слоя гейтов; диф-проверка AC-9; колонка `agent_runs.model` уже есть — ни одного `CREATE/ALTER` |
+
+## Сводный вывод
+
+Доминирующий класс — **конфигурационные инварианты подсистемы запуска** (TR-1/TR-7/TR-8): все
+снимаются детерминированной лестницей `_resolve_timeout`, защитной валидацией (never-break) и
+sanity-тестом reaper-неравенства. Остаточный риск для прод-конвейера (self-hosting) — **низкий**:
+изменение аддитивно, обратимо через `.env`, не трогает гейты/схему/деплой-путь и не рестартит
+прод-контейнер (NFR-5). Единственный наблюдаемый побочный эффект — возможный рост alert-only
+`agent_hung`-нотификаций sidecar (TR-5), не влияющий на конвейер.
+
+**Эскалация:** не требуется на уровне `arch:major-change` (нет новой стадии/компонента/смены БД), но
+решение **кросс-каттинговое** (меняет два глобальных per-agent инварианта всех репо + потолок Tier-3
+reaper'а) → зарегистрировано сквозным `docs/architecture/adr/adr-0040-*`. Возврат в анализ не нужен —
+ТЗ удовлетворяется без нарушения принципов архитектуры.

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

@@ -0,0 +1,119 @@
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-109
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-109
+version: 3
+---
+
+# Review ORCH-109
+
+## Summary
+
+Две аддитивные изолированные правки подсистемы запуска (`launcher`) — **launch-стамп модели** в
+`agent_runs.model` (D1/FR-1) и **поднятые per-role wall-clock бюджеты** developer/reviewer с
+синхронным поднятием reaper (D3/D4/FR-3) — реализованы **корректно и точно по ADR**. Контракты
+неприкосновенны: в `src/` изменены **только** `launcher.py` и `config.py`; ни одной строки
+`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / `_parse_*` / machine-verdict / `CREATE TABLE` /
+`ALTER TABLE` в диффе нет (AC-9 верифицирован grep'ом по диффу). Зафиксированные маркер-инварианты
+**ORCH-087** (стамп эффорта объединён в один `UPDATE`, `(effort or None)` сохранён) и **ORCH-065**
+(reaper поднят синхронно `3600→5400`, `5400 > 3600+20=3620`) — целы. Покрытие исчерпывающее: новый
+`tests/test_orch109_timeout_model.py` (TC-01…TC-12, детерминированный, без сети/CLI), обновлены
+`tests/test_config.py` (reaper-дефолт 5400) и `tests/test_launcher.py` (лестница `_resolve_timeout`).
+
+Независимая верификация reviewer'а: целевые тесты зелёные — `test_orch109_timeout_model.py` +
+`test_config.py` + `test_launcher.py` = **75 passed**; зависимые подсистемы FR-2/FR-4
+(`usage`/`notifications`/`tracker`) = **231 passed**. Полный регресс зелёный (см. `13-test-report.md`).
+Открытых findings P0/P1/P2 нет → вердикт **APPROVED**.
+
+## Оси проверки
+
+1. **Соответствие ТЗ (02-trz / 03-acceptance):** FR-1…FR-6 реализованы; AC-1…AC-10 покрыты тестами
+   TC-01…TC-12 буквально по матрице AC↔FR.
+   - FR-1/AC-1 (TC-04): `_spawn` пишет резолвенную модель в `agent_runs.model` объединённым
+     `UPDATE agent_runs SET model=?, effort=? WHERE id=?` с `(model or None, effort or None, run_id)`
+     рядом со стампом эффорта; пустой резолв → `NULL`; стамп = `resolve_agent_model` (single source).
+   - FR-2/AC-2 (TC-06/07): `usage.record_usage` использует `model=COALESCE(?, model)` (сверено по
+     `src/usage.py`) — `usage=None`/`model=None` не затирает launch-стамп; непустая модель уточняет.
+     Кода `usage.py` PR не трогает (корректно — семантика уже верна), зафиксировано регресс-тестом.
+   - FR-3/AC-3 (TC-01/02): `_resolve_timeout` отдаёт поднятый бюджет developer/reviewer и неизменный
+     1800 прочим ролям (analyst/architect/tester/deployer/unknown/None); бюджеты конфигурируемы.
+   - FR-3/AC-4 (TC-03): малформный `agent_timeout_overrides_json` и непозитивный/нечисловой
+     выделенный ключ `[0,-5,"abc"]` → откат на глобальный дефолт + WARNING, never-break.
+   - NFR-4/AC-5 (TC-08): инвариант reaper подтверждён на shipped-дефолтах (`5400 > 3600+20`).
+   - FR-4/AC-6 (TC-09): строка стадии рендерит `· opus-4-8 · xhigh` для `exit_code=-9`; присутствует
+     negative-guard (немаркированный -9 → суффикс опущен).
+   - FR-4/NFR-6/AC-7 (TC-10): `get_running_agents` отдаёт модель для running-job (in-flight).
+   - FR-5/AC-8 (TC-11): timeout-killed прогон developer/reviewer не вызывает `_try_advance_stage`
+     (роутится в `_finalize_job`); присутствует позитивный контроль (clean exit → advance).
+   - AC-9 (TC-12) + AC-10: контракты/схема нетронуты; документация и регресс зелёные.
+
+2. **Соответствие ADR (06-adr ADR-001 + сквозной adr-0040):** D1–D6 реализованы дословно. Лестница
+   `_resolve_timeout` (overrides_json → выделенный ключ роли → глобальный дефолт), выделенные ключи
+   `agent_timeout_developer_s=3600`/`agent_timeout_reviewer_s=3000`, `reaper_max_running_s` 3600→5400.
+   **Трассировка маркеров (TRACEABILITY):** правка касается блоков с маркерами ORCH-087 (стамп
+   эффорта) и ORCH-065 (reaper Tier-3) — оба зафиксированных инварианта сверены с их ADR и не
+   сломаны (эффорт-стамп сохранён в объединённом `UPDATE`; reaper-неравенство пересчитано и поднято
+   синхронно). Нарушений глобальных ADR нет.
+
+3. **Качество кода:** never-raise сохранён (`try/except` + WARNING вокруг стамп-`UPDATE`;
+   непозитивный/нечисловой выделенный ключ → откат + WARNING). Докстринг `_resolve_timeout` и
+   паспорт-комментарии `config.py` точны. Тесты содержательны: изоляция стамп-сбоя (TC-05,
+   `_RaisingConn` бьёт только по launch-`UPDATE`), параметризация `[0,-5,"abc"]`, негативный guard
+   (TC-09b), позитивный контроль (TC-11c). **Регресс-тест-фиксатор инцидента ORCH-104** присутствует
+   (ORCH-019 BR-4 удовлетворён) — весь тест-файл пинит дефектное и исправленное поведение.
+
+4. **Документация (приоритетная ось):** `src/` изменён → документация обновлена в том же PR
+   (golden source синхронизирован с кодом):
+   `CHANGELOG.md` / `CLAUDE.md` (паспорт) / `docs/architecture/README.md` (бюллет Agent Launcher +
+   ссылка на adr-0040) / `docs/architecture/internals.md` (оба упоминания «30 мин» → per-role) /
+   `README.md` front-page «### Watchdog» (per-role бюджеты + Tier-3 backstop 90м) / `.env.example`
+   (5 ключей agent-timeout + `ORCH_REAPER_MAX_RUNNING_S`=5400) / `config.py`-паспорт / детальный
+   ADR-001 + сквозной adr-0040. Обзорная витрина `docs/overview/` правки не требует — упоминания
+   watchdog концептуальны (sidecar-наблюдатель, «следит за процессом»), конкретного числа тайм-аута
+   витрина не несёт → устаревшего факта не возникает (ORCH-011/079 — нет finding). PR не закрывает
+   пункт `README.md` «Известные ограничения».
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice-to-have
+- [ ] ADR-001 (`status: proposed`) и adr-0040 (`Proposed`) на merge разумно перевести в `Accepted`
+  (косметика статуса ADR; на гейты/код не влияет, не блокер).
+
+## Документация
+
+**Обновлено в этом PR (golden source синхронизирован с кодом):**
+- `CHANGELOG.md` — детальная запись ORCH-109 (`fix`, D1/D3/D4, FR-4/FR-5 структурно). ✅
+- `CLAUDE.md` — паспорт (блок «Стек», абзац launcher). ✅
+- `docs/architecture/README.md` — бюллет Agent Launcher (ссылка на adr-0040). ✅
+- `docs/architecture/internals.md` — watchdog «30 мин» → per-role (стр. ~96 и ~262). ✅
+- `README.md` — front-page «### Watchdog» (стр. ~295) → per-role бюджеты + Tier-3 backstop. ✅
+- `.env.example` — новый блок agent-timeout (5 ключей) + `ORCH_REAPER_MAX_RUNNING_S` 3600→5400. ✅
+- `src/config.py` — паспорт-комментарий ORCH-7/ORCH-109 + reaper-инвариант. ✅
+- ADR — `docs/work-items/ORCH-109/06-adr/ADR-001-…` (детальный) + `docs/architecture/adr/adr-0040-…`
+  (сквозной). ✅
+
+**Обзорная витрина `docs/overview/` (ORCH-011/ORCH-079):** правки не требует — упоминания watchdog
+концептуальны, конкретного числа тайм-аута витрина не несёт, поэтому устаревшего факта не возникает.
+
+**Прочее (не findings):**
+- AC-9 верифицирован по диффу: в `src/` изменены только `launcher.py` и `config.py`; ни одной строки
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/`CREATE TABLE`/`ALTER TABLE`.
+- Целевой регресс reviewer'а зелёный: 75 (ORCH-109/config/launcher) + 231 (usage/notifications/
+  tracker) passed; полный регресс — `13-test-report.md`.
+</content>
+</invoke>

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

@@ -0,0 +1,82 @@
+---
+result: PASS
+work_item: ORCH-109
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-109
+---
+
+# Test Report — ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
+
+> Машинный вердикт читается ТОЛЬКО из frontmatter. Канонический ключ — `result:`.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Дата: 2026-06-14
+- Worktree: `feature/ORCH-109-orch-timeout-budgets-launch-ti`
+  (`/repos/_wt/orchestrator/feature_ORCH-109-orch-timeout-budgets-launch-ti/`)
+
+## Smoke API (read-only, прод не трогался)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — задача 98 (ORCH-109) в стадии `testing`, агент не запущен |
+| `GET /queue` | PASS — блок `serial_gate` присутствует (ORCH-088); блок `auto_labels` присутствует (ORCH-089) |
+
+## Результаты
+
+### Полный регресс
+`pytest tests/ -q` → **1899 passed, 1 warning in 516.70s (0:08:36)** (exit 0).
+Единственное предупреждение — `PydanticDeprecatedSince20` (class-based config, pre-existing,
+не связано с ORCH-109). Прод-контейнер не затрагивался.
+
+### Профильная сюита
+`pytest tests/test_orch109_timeout_model.py -v` → **25 passed** (exit 0, 13.50s).
+Покрывает TC-01…TC-12 (+ доп. варианты: configurable-keys, overrides-json-wins, параметризация
+non-positive `[0,-5,abc]`, clean-exit advances, unstamped-killed drops suffix).
+
+## Сопоставление с тест-планом (`04-test-plan.yaml`)
+
+| TC ID | Описание | Тест-функция(и) | Результат |
+|-------|----------|-----------------|-----------|
+| TC-01 | `_resolve_timeout('developer'/'reviewer')` возвращает поднятый бюджет | `test_tc01_developer_reviewer_raised`, `test_tc01_dedicated_keys_are_configurable`, `test_tc01_overrides_json_wins_over_dedicated` | PASS |
+| TC-02 | Прочие роли (analyst/architect/tester/deployer) → глобальный 1800 | `test_tc02_other_roles_use_global_default` | PASS |
+| TC-03 | Малформный конфиг → откат на дефолт + WARNING, без исключения | `test_tc03_malformed_overrides_json_never_raises`, `test_tc03_non_positive_dedicated_falls_back[0/-5/abc]` | PASS |
+| TC-04 | Launch стампит `agent_runs.model` (непустую) рядом с effort | `test_tc04_spawn_stamps_model_and_effort` | PASS |
+| TC-05 | Стамп изолирован: сбой записи не пробрасывает исключение (never-raise) | `test_tc05_stamp_failure_is_isolated` | PASS |
+| TC-06 | `record_usage(None)`/`model=None` НЕ затирают launch-стамп (COALESCE) | `test_tc06_record_usage_none_preserves_model`, `test_tc06_record_usage_model_none_preserves_model` | PASS |
+| TC-07 | `record_usage` с непустой model уточняет/проставляет значение | `test_tc07_record_usage_nonempty_model_enriches_blank`, `test_tc07_record_usage_refines_existing_model` | PASS |
+| TC-08 | Sanity reaper-инварианта: `reaper_max_running_s > max(timeout)+grace` | `test_tc08_shipped_defaults_satisfy_invariant`, `test_tc08_resolved_max_is_developer` | PASS |
+| TC-09 | `_stage_line` для `exit_code=-9` рендерит ` · <model> · <effort>` (model не null) | `test_tc09_killed_run_renders_model_effort`, `test_tc09_unstamped_killed_run_drops_model_suffix` | PASS |
+| TC-10 | `get_running_agents` отдаёт непустую model для running-job (in-flight) | `test_tc10_running_job_exposes_model` | PASS |
+| TC-11 | Анти-salvage: killed developer/reviewer (`exit_code=-9`) не продвигает стадию | `test_tc11_killed_developer_run_does_not_advance`, `test_tc11_killed_reviewer_run_does_not_advance`, `test_tc11_clean_exit_advances` | PASS |
+| TC-12 | Анти-регресс: STAGE_TRANSITIONS/QG_CHECKS/схема `agent_runs` не изменены | `test_tc12_stage_transitions_unchanged`, `test_tc12_agent_runs_model_effort_columns_preexist`, `test_tc12_qg_checks_registry_present` | PASS |
+
+**Все 12 TC выполнены и сопоставлены.**
+
+## Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
+
+| AC | Критерий | Покрытие | Результат |
+|----|----------|----------|-----------|
+| AC-1 | Модель стампится в `agent_runs.model` на launch | TC-04 | PASS |
+| AC-2 | Постфактум-enrich не затирает launch-стамп при оборванном JSON | TC-06, TC-07 | PASS |
+| AC-3 | Тайм-аут developer/reviewer поднят и конфигурируем без влияния на прочие | TC-01, TC-02 | PASS |
+| AC-4 | Малформный timeout-конфиг → безопасный откат (never-break) | TC-03 | PASS |
+| AC-5 | Reaper-инвариант сохранён | TC-08 | PASS |
+| AC-6 | Строка стадии трекера показывает model+effort при timeout/kill | TC-09 | PASS |
+| AC-7 | In-flight видимость модели в `/metrics`/`/queue` | TC-10 | PASS |
+| AC-8 | Timeout-killed прогон не продвигает стадию (анти-salvage) | TC-11 | PASS |
+| AC-9 | Неприкосновенность контрактов и схемы | TC-12 | PASS |
+| AC-10 | Документация и полный регресс зелёный | full regress (1899 passed) + review APPROVED | PASS |
+
+**Все 10 AC покрыты и зелёные.**
+
+## Итог
+**PASS** — полный регресс зелёный (1899 passed, exit 0), профильная сюита ORCH-109 зелёная
+(25 passed), smoke API OK (`serial_gate`/`auto_labels` присутствуют в `/queue`), каждый TC из
+тест-плана выполнен и сопоставлен с критериями приёмки. Задача переходит на `deploy-staging`.

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

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

@@ -0,0 +1,46 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-109
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-14
+model_used: claude-opus-4-8
+timestamp: 2026-06-14T11:21:00Z
+base_url: http://localhost:8501
+mode: stub
+---
+
+# Staging Gate Log — ORCH-109
+
+Canonical staging suite (`scripts/staging_check.py --base-url http://localhost:8501 --mode stub`)
+executed **inside the `orchestrator-staging` container** (ORCH-048 canonical path). Exit code **0**
+→ `staging_status: SUCCESS`.
+
+## Result
+
+```
+RESULT: 8/10 checks PASS
+REAL failed         : none
+SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
+```
+
+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
+
+## Per-block detail
+
+- **Block A (SMOKE):** A1 `/health` 200 ok · A2 `/queue` 200 (counts/max_concurrency/resilience) · A3 `ORCH_STAGING=true` — all PASS.
+- **Block B (ACCESS):** B4 Plane sandbox accessible · B5 Gitea `orchestrator-sandbox` accessible (push=true) · B6 registry isolation (sandbox present, prod ET/ORCH absent) — all PASS.
+- **Block C (E2E, stub):** C7 create issue in Plane SANDBOX · C8 trigger pipeline via `/webhook/plane` — PASS. C9a/C9b — **waived** sandbox-infra (SANDBOX bot accounts are not members of the sandbox Plane project, so pipeline steps 6+ are unreachable in the sandbox; not a pipeline regression — ORCH-061).
+- **CLEANUP:** Plane test issue deleted (HTTP 204); no stray branch.
+
+## Environment note (observability)
+
+The canonical path requires `docker exec orchestrator-staging …`. In this run no `docker`/`docker compose`
+CLI was reachable and the staging container was not running, so the `orchestrator-staging` service was
+brought up (staging-only, port 8501, real `.env.staging` → sandbox-isolated registry, `ORCH_STAGING=true`)
+via the Docker Engine API mirroring the compose `orchestrator-staging` spec, the canonical
+`staging_check.py` was `docker exec`'d inside it, and the container was torn down afterwards to restore
+the pre-existing state. Prod (8500) was never touched; `.env`/`.env.staging`/`docker-compose.yml`/prod
+infra were not modified.

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

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

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: merge-gate local re-test timeout causes false rollback after green CI
+
+Work Item ID: ORCH-110
+
+## Description
+
+TBD

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

@@ -0,0 +1,178 @@
+---
+work_item: ORCH-110
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 01 — BRD (бизнес-требования): ORCH-110 — BUG: merge-gate local re-test timeout causes false rollback after green CI
+
+Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
+
+> **Багфикс-трек → эскалация в полный цикл (`escalate: full-cycle`).** Задача помечена `Bug`, но
+> сама баг-карточка требует «отдельный анализ вариантов и контрактов merge-gate» (см. «Ограничение»
+> ниже) — это решение с несколькими проектными альтернативами и нетривиальными инвариантами
+> self-hosting, которому нужен ADR. По правилу ORCH-019 (ADR-001 D5) выпускается **полный**
+> analysis-пакет, а трек эскалируется (`POST /bug-fast-track/escalate?work_item=ORCH-110`) → задача
+> проходит стадию `architecture`. Прецедент — родственная задача ORCH-111 («bug → escalate
+> full-cycle»).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+Оркестратор — self-hosting инструмент: его прод-контейнер обслуживает конвейер всех проектов и
+дорабатывает сам себя. На ребре `deploy-staging → deploy` исполняется детерминированный под-гейт
+**merge-gate** (`check_branch_mergeable`, ORCH-043): он догоняет ветку до текущего `origin/main`
+(`auto_rebase_onto_main`) и затем **локально пере-прогоняет весь тест-сюит** (`retest_branch` →
+`python -m pytest tests/ -q`) в worktree, чтобы поймать **семантический** конфликт слияния (ветка
+зелёная по своей базе, но ломает уехавший `main`).
+
+**Установленные факты инцидента (ORCH-109, PR #129):**
+- tester завершился `result: PASS`; полный регресс — **`1899 passed` за `516.70s`**;
+- CI Gitea по HEAD — зелёный (push + pull_request success); PR после rebase — open, `mergeable=true`;
+- merge-gate локальный re-test упал по **таймауту**: `re-test timeout after 600s`
+  (`merge_retest_timeout_s = 600`);
+- на хосте обнаружены **старые зависшие pytest-процессы** `tests/test_install_lite_script.py`,
+  жившие **> 2 суток** и грузившие CPU; прибиты вручную 2026-06-14.
+
+**Цепочка отказа.** Зависшие осиротевшие pytest-процессы (CPU-голодание) → тот же сюит, что у tester
+шёл 516.70s (запас до 600s ≈ 16%), под нагрузкой превысил 600s → `check_branch_mergeable` вернул
+`(False, "re-test timeout after 600s")` → `_handle_merge_gate_rollback`: откат `deploy-staging →
+development` + developer-retry. Каждый из 3 retry повторно падал по тому же CPU-голоданию → финальный
+alert **«Merge-gate still failing after 3 developer retries (re-test timeout after 600s)»** → задача
+застряла, потребовалось ручное вмешательство.
+
+**Корень (подтверждён по коду):**
+1. **Утечка осиротевших процессов.** `merge_gate.retest_branch` и `coverage_gate.measure_coverage`
+   запускают `subprocess.run([... pytest ...], timeout=...)` **без изоляции группы процессов**
+   (`start_new_session`/`preexec_fn`). При `TimeoutExpired` Python убивает только **прямого
+   потомка**; внуки pytest репарентируются на PID 1 (tini жнёт зомби, но не убивает живых сирот) и
+   живут сутками, грузя CPU. Это источник CPU-голодания (ровно симптом из фактов).
+2. **Нет толерантности к инфра-таймауту.** Re-test **таймаут** (ресурсная/инфра-причина)
+   классифицируется идентично **красному** re-test (реальный дефект кода): оба → откат на
+   `development` + расход developer-retry. Разработчик не может «починить» CPU-голодание → retry
+   сгорают вхолостую и упираются в alert «Manual intervention needed».
+3. **Тонкий бюджет.** Бюджет re-test `600s` практически равен фактическому времени сюита
+   (`516.70s`); запас не растёт вместе с сюитом (ср. ORCH-109, где по той же причине были подняты
+   бюджеты агентов developer/reviewer).
+4. **Контракт необходимости re-test.** На ветке, уже актуальной к `origin/main` (rebase — no-op), и
+   с зелёным CI по этому же HEAD локальный полный re-test пере-проверяет ровно тот коммит, что CI
+   уже подтвердил, — становясь избыточной единственной точкой ложного отказа.
+
+## 2. Объём (scope)
+
+### В объёме
+- Поведение merge-gate при **таймауте** локального re-test: классификация и путь восстановления
+  (толерантность к инфра-таймауту вместо ложного отката на `development`).
+- **Жизненный цикл подпроцессов**, которые оркестратор запускает САМ для проверок: re-test merge-gate
+  (`merge_gate.retest_branch`) и coverage-run (`coverage_gate.measure_coverage`) — гарантия отсутствия
+  осиротевших процессов после таймаута/kill.
+- **Согласованность бюджета** re-test с фактическим временем полного сюита (адекватный запас) с учётом
+  сквозных инвариантов reaper/lease.
+- **Контракт необходимости** локального re-test merge-gate (когда он реально нужен относительно
+  зелёного CI и состояния `branch vs origin/main`) — анализ вариантов под решение архитектора.
+- Наблюдаемость инфра-таймаута (отличить «инфра-таймаут, повтор/defer» от «дефект кода → developer»).
+
+### Вне объёма
+- **Алерт sidecar-watchdog на осиротевший тест-процесс** — это **ORCH-111** (`proc_blocking`,
+  наблюдатель только сигналит, никогда не убивает, C-1). ORCH-110 — комплементарная сторона
+  (предотвращение утечки + толерантность), дубля детекции не вводит.
+- Ручное умерщвление уже зависших хост-процессов — операционная мера (выполнена 2026-06-14), не код.
+- Любые правки `STAGE_TRANSITIONS` / реестра `QG_CHECKS` / `check_*`-семантики / machine-verdict
+  ключей / схемы БД (инвариант NFR-1).
+- Изменение конкретного теста `tests/test_install_lite_script.py` (его поведение — отдельный предмет;
+  здесь важен класс «оркестратор-спавненный pytest не должен переживать свой бюджет»).
+- Поведение не-self-hosting репозиториев (enduro-trails) — нулевая регрессия.
+- Изменение хука прод-деплоя/рестарт прод-контейнера (self-hosting безопасность).
+
+## 3. Заинтересованные стороны
+- **Owner / оператор self-hosting** — страдает от ручного разбора застрявших задач и зависших
+  процессов; заказчик исправления.
+- **Конвейер всех проектов** — общий прод-контейнер: утечка CPU деградирует обслуживание enduro.
+- **Пакетный автономный режим (эпик ORCH-088)** — ложные откаты и manual-gate'ы ломают цель
+  «10–20 задач за ночь без вмешательства».
+- **Принимает результат:** reviewer → tester → deployer штатного конвейера.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 — Зелёный путь без ручного вмешательства.** При зелёном tester `PASS` и зелёном CI задача
+  **не должна** требовать ручного вмешательства из-за инфраструктурного/локального re-test таймаута
+  (прямое «Ожидаемое поведение» баг-карточки).
+- **BR-2 — Инфра-таймаут ≠ дефект кода.** Таймаут локального re-test merge-gate (ресурсная/инфра
+  причина) **не должен** трактоваться как код-фейл: путь восстановления **не** должен сжигать
+  developer-retry и приводить к «Manual intervention after N developer retries», если CI и tester
+  были зелёными. Реакция на таймаут — ограниченный повтор/defer и/или отдельный инфра-сигнал, не
+  безусловный откат на `development`.
+- **BR-3 — Нет осиротевших процессов.** Подпроцессы pytest, запущенные самим оркестратором для
+  re-test и coverage-run, **должны** полностью завершаться (всё дерево, включая внуков) при
+  таймауте/kill. Ни один оркестратор-спавненный pytest не должен переживать свой бюджет и продолжать
+  грузить CPU.
+- **BR-4 — Адекватный бюджет re-test.** Бюджет времени re-test **должен** иметь достаточный запас над
+  фактическим временем полного сюита, чтобы здоровый сюит при штатной нагрузке не падал по таймауту;
+  бюджет конфигурируем и со-эволюционирует с ростом сюита.
+- **BR-5 — Контракт необходимости re-test.** Merge-gate **должен** различать «ветка реально отстала
+  от уехавшего `origin/main` и была ребейзнута» (риск семантического конфликта → re-test оправдан) и
+  «ветка уже актуальна / rebase — no-op, CI по этому HEAD зелёный» (re-test избыточен). Локальный
+  re-test не должен быть избыточной единственной точкой ложного отказа на коммите, уже подтверждённом
+  CI. Конкретный контракт (skip/scope/trust-CI-SHA) выбирает архитектор и фиксирует в ADR.
+- **BR-6 — Сохранение защиты от семантического конфликта.** Толерантность к таймауту **не должна**
+  ослаблять исходную цель merge-gate (ORCH-043): **детерминированно красный** re-test (реальный сбой
+  теста, а не таймаут) по-прежнему обязан откатывать на `development`. Послабление применяется ТОЛЬКО
+  к таймауту/инфра, никогда к красному результату.
+- **BR-7 — Наблюдаемость.** Состояние «инфра-таймаут» должно быть видимым (лог + Telegram с
+  кликабельным номером + read-only в `GET /queue`) и отличимым от код-фейл-отката; согласовано с
+  сигналом ORCH-111 (без дубля).
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — Инварианты конвейера неприкосновенны.** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` /
+  семантика `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/
+  `staging_status:`/`security_status:`/`coverage_status:`) / схема БД — **байт-в-байт** прежние.
+  Исправление — аддитивное (врезка/leaf-логика), не новая стадия и не новый зарегистрированный QG.
+- **NFR-2 — Kill-switch + нулевая регрессия.** Новое поведение под флагом; при выключенном флаге —
+  поведение **байт-в-байт** как до ORCH-110 (таймаут → прежний откат). Скоуп — self-hosting
+  (`orchestrator`); enduro не затронут.
+- **NFR-3 — Self-hosting безопасность.** Исправление **никогда** не пушит/force-push в `main` (INV-4;
+  merge только через Gitea PR-merge API), не рестартит прод-контейнер, не трогает detached-деплой.
+- **NFR-4 — never-raise.** Любая ошибка в новом пути → безопасный дефолт + WARNING; исключение
+  никогда не уходит в `advance_stage`/monitor-поток (контракт merge-gate сохранён).
+- **NFR-5 — Ограниченность (anti-loop).** Любой повтор/defer таймаута строго ограничен по числу
+  попыток и суммарному времени; исчерпание → **чёткий инфра-alert**, отличный от «developer must
+  fix», а не бесконечный bounce и не молчаливое зависание.
+- **NFR-6 — Сквозные инварианты времени.** Любое изменение бюджета re-test должно уважать
+  существующие соотношения: `merge_lock_timeout_s` (TTL merge-lease), `reaper_max_running_s`
+  (Tier-3 backstop reaper, ORCH-065/109), `coverage_run_timeout_s` — без рассинхрона.
+
+## 6. Допущения и ограничения
+- **Ограничение из баг-карточки (дословно):** «Решение намеренно не описано в этой баге; нужен
+  отдельный анализ вариантов и контрактов merge-gate». → Аналитик фиксирует требования и
+  тест-план; **варианты и контракт merge-gate** прорабатывает архитектор (06-adr) — основание
+  эскалации в полный цикл.
+- Допущение: tini (PID 1) жнёт зомби, но не убивает живых осиротевших процессов (подтверждено
+  поведением инцидента) — отсюда требование tree-kill (BR-3).
+- Допущение: таймаут merge-gate re-test в зелёном инциденте вызван внешним CPU-голоданием, а не
+  реальным зависанием теста ветки; но решение обязано остаться **fail-safe** к случаю реального
+  зависшего теста (см. Риск R-2 / BR-6).
+- Среда верификации — staging-контур (8501), обязательная страховка перед прод-деплоем self.
+
+## 7. Критерии успеха
+Резюме: зелёный tester `PASS` + зелёный CI + актуальная ветка → задача доходит до `deploy` без
+ложного отката на `development` и без manual-gate из-за инфра-таймаута; оркестратор-спавненные
+pytest-процессы не переживают свой бюджет; реальный красный re-test по-прежнему откатывает на
+`development`; инварианты конвейера и self-hosting не тронуты. Детальные PASS/FAIL —
+`03-acceptance-criteria.md`.
+
+## 8. Риски
+- **R-1** — Над-толерантность маскирует реальный зависший тест (бесконечный/долгий) как «инфра» →
+  смягчение: строгая ограниченность (NFR-5) + отдельный инфра-alert + сохранение красно-откат-пути
+  (BR-6).
+- **R-2** — Поднятие бюджета без правки tree-kill лишь отодвигает отказ (сюит растёт) → исправление
+  должно бить корень (BR-3), бюджет (BR-4) — вторично.
+- **R-3** — Рассинхрон сквозных таймаутов (reaper/lease) при изменении бюджета (NFR-6).
+- **R-4** — Дубль/конфликт с сигналом ORCH-111 (`proc_blocking`) → координация: ORCH-110
+  предотвращает/толерирует, ORCH-111 наблюдает; разные слои.
+- Детальная оценка и митигации — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,129 @@
+---
+work_item: ORCH-110
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 02 — ТЗ (TRZ): ORCH-110 — merge-gate local re-test timeout: устранение ложного отката + утечки процессов
+
+Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные требования к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование, выбор вариантов и **контракт merge-gate** — задача архитектора (06-adr,
+> основание `escalate: full-cycle`). Здесь — поведение/контракты/инварианты и привязка к модулям,
+> НЕ выбор механизма.
+
+## 1. Сводка изменения
+Устранить ложный откат `deploy-staging → development`, возникающий когда локальный re-test merge-gate
+падает по **таймауту** (инфра/ресурс), при зелёном tester `PASS` и зелёном CI. Изменение бьёт по двум
+корням и одному контракту: (1) **утечка осиротевших pytest-процессов** из оркестратор-спавненных
+прогонов re-test/coverage (источник CPU-голодания) → гарантировать tree-kill дерева подпроцесса при
+таймауте/kill; (2) **классификация инфра-таймаута** как транзиента (повтор/defer/инфра-alert), а не
+код-фейла (откат + расход developer-retry); (3) **контракт необходимости** локального re-test
+относительно зелёного CI и состояния `branch vs origin/main`. Сопутствующе — согласование **бюджета**
+re-test с реальным временем сюита. Всё — аддитивно, под kill-switch, never-raise, скоуп self-hosting,
+с сохранением исходной защиты merge-gate от семантического конфликта (красный re-test по-прежнему
+откатывает).
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/merge_gate.py` | изменить — `retest_branch`: жизненный цикл подпроцесса (tree-kill при таймауте/kill); классификация исхода «timeout» как транзиента (контракт возврата) |
+| `src/coverage_gate.py` | изменить — `measure_coverage`: тот же tree-kill при таймауте (сиблинг-источник утечки, BR-3) |
+| `src/qg/checks.py` | изменить — `check_branch_mergeable`: различать «timeout/infra» от «red re-test» в возвращаемом контракте (без смены имени/семантики зарегистрированного `check_*`) |
+| `src/stage_engine.py` | изменить — `_handle_merge_gate` / маршрутизация исхода: инфра-таймаут → defer/повтор/инфра-alert (по образцу `_handle_merge_gate_defer`), НЕ `_handle_merge_gate_rollback`; красный re-test → прежний rollback |
+| `src/config.py` | изменить — флаг(и) толерантности к инфра-таймауту + (опц.) согласование `merge_retest_timeout_s`; уважить сквозные инварианты `merge_lock_timeout_s` / `reaper_max_running_s` / `coverage_run_timeout_s` |
+| `docs/architecture/README.md`, `CLAUDE.md`, `CHANGELOG.md` | обновить — описание поведения merge-gate re-test (golden source наравне с кодом) |
+| `tests/test_*` | создать — покрытие по `04-test-plan.yaml` |
+
+> Точный набор новых символов/флагов и механизм tree-kill (process-group `start_new_session`+killpg,
+> либо иной) — решение архитектора. ТЗ фиксирует **что** должно выполняться, не **как**.
+
+## 3. Функциональные требования
+
+### FR-1 — Толерантность к инфра-таймауту re-test (нет ложного отката) [BR-1, BR-2]
+Когда merge-gate локальный re-test завершается специфически по **таймауту** (а не детерминированно
+красным результатом), исход ДОЛЖЕН классифицироваться как транзиент/инфра, не код-фейл. Путь
+восстановления НЕ ДОЛЖЕН быть тем же `_handle_merge_gate_rollback` (откат на `development` + инкремент
+developer-retry), который при зелёных CI/tester ведёт к «Manual intervention needed». Допустимая
+реакция (выбор — архитектор): ограниченный повтор re-test и/или defer (по образцу существующего
+`_handle_merge_gate_defer` для `merge-lock busy`) и/или отдельный инфра-alert. Прецеденты толерантности
+к инфра: ORCH-061 (staging infra tolerance), ORCH-093 (transient vs terminal классификация merge-POST).
+
+### FR-2 — Tree-kill оркестратор-спавненных тест-процессов [BR-3]
+`merge_gate.retest_branch` и `coverage_gate.measure_coverage` ДОЛЖНЫ гарантировать, что при таймауте
+(а также при любом kill/прерывании прогона) завершается **всё дерево** подпроцесса pytest, включая
+внуков, а не только прямой потомок. После таймаута ни один оркестратор-спавненный pytest-процесс не
+должен оставаться живым и грузить CPU. Контракт возврата `retest_branch`
+(`(False, "re-test timeout after <T>s")`) сохраняется; меняется лишь побочный эффект — отсутствие
+утечки. Существующий каскад launcher `SIGTERM→grace→SIGKILL` (`stop_process`) — образец на уровне
+агентов; для этих subprocess-прогонов требуется эквивалентная гарантия на уровне группы процессов.
+
+### FR-3 — Согласованность бюджета re-test [BR-4, NFR-6]
+Бюджет `merge_retest_timeout_s` ДОЛЖЕН иметь достаточный запас над фактическим временем полного сюита
+(наблюдаемо: 600s бюджет vs 516.70s факт ≈ 16%). Бюджет остаётся конфигурируемым; при его изменении
+ДОЛЖНЫ соблюдаться сквозные инварианты: `reaper_max_running_s > max(agent_timeout, бюджеты) + grace`
+(ORCH-065/109) и согласование с `merge_lock_timeout_s` (TTL merge-lease держится на время re-test).
+Малформный/непозитивный конфиг → безопасный дефолт + WARNING (never-break).
+
+### FR-4 — Контракт необходимости локального re-test [BR-5, BR-6]
+Merge-gate ДОЛЖЕН различать риск-кейсы и применять re-валидацию пропорционально реальному риску
+слияния:
+- ветка **реально отстала** от уехавшего `origin/main` и ребейзнута → семантический риск → re-test
+  оправдан (текущая цель ORCH-043 сохраняется);
+- ветка **уже актуальна** / rebase — no-op, и CI по этому самому HEAD зелёный → локальный полный
+  re-test пере-проверяет ровно подтверждённый CI коммит и не должен быть единственной точкой ложного
+  отказа.
+Конкретный контракт (например: пропуск re-test при «не-behind + зелёный CI по HEAD», сокращённый
+scope, доверие SHA, подтверждённому CI, и т. п.) — **выбор архитектора в ADR** (ядро запрошенного
+баг-карточкой «анализа контрактов merge-gate»). Инвариант **BR-6**: детерминированно **красный**
+re-test (реальный сбой теста) обязан и далее откатывать на `development` — послабление применяется
+ТОЛЬКО к таймауту/инфра.
+
+### FR-5 — Сохранение инвариантов и kill-switch [NFR-1, NFR-2, NFR-3, NFR-4]
+Изменение аддитивно: `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict
+ключи / схема БД — без изменений; merge-gate остаётся под-гейтом-врезкой, не новой стадией/QG. Под
+kill-switch: выключенный флаг → байт-в-байт прежнее поведение (таймаут → откат). Скоуп self-hosting
+(`orchestrator`); enduro — no-op. never-raise; INV-4 (никогда push/force-push `main`; merge только
+через Gitea PR API) и запрет рестарта прод-контейнера — соблюдены.
+
+### FR-6 — Наблюдаемость и ограниченность [BR-7, NFR-5]
+Состояние «инфра-таймаут» ДОЛЖНО логироваться, уведомляться в Telegram (кликабельный номер задачи) и
+быть видимым read-only (например, расширение блока `merge`/`merge_verify` в `GET /queue`), отличимо от
+код-фейл-отката. Любой повтор/defer строго ограничен (число попыток + суммарное время); исчерпание →
+**инфра-alert** (не «developer must fix»). Координация с ORCH-111 (`proc_blocking`) — без дубля:
+ORCH-110 предотвращает/толерирует, ORCH-111 наблюдает.
+
+## 4. Изменения API
+Новых обязательных эндпоинтов **не требуется**. Допустимо (when-applicable, на усмотрение
+архитектора) **read-only** расширение существующего снимка `GET /queue` (блок merge-gate) полями
+наблюдаемости инфра-таймаута/повторов. Никаких новых управляющих эндпоинтов.
+
+## 5. Изменения схемы БД
+**Нет.** Счётчики повторов/defer — по образцу существующих (`_merge_defer_count` /
+`_developer_retry_count` поверх `jobs`/`agent_runs`) либо in-memory/sentinel; новые таблицы/колонки не
+вводятся (NFR-1).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет нового зарегистрированного QG.** `check_branch_mergeable` остаётся в реестре `QG_CHECKS` с тем же
+именем и семантикой PASS/FAIL; меняется лишь **различение причины FAIL** (timeout/infra vs red) в
+возвращаемом reason и **маршрутизация исхода** во врезке `_handle_merge_gate` (`advance_stage`).
+`STAGE_TRANSITIONS` и состав `QG_CHECKS` — байт-в-байт.
+
+## 7. Совместимость / регресс
+- **Обратная совместимость:** kill-switch off → поведение байт-в-байт как до ORCH-110 (таймаут →
+  rollback на `development`), включая текст alert'ов.
+- **Область раската:** self-hosting `orchestrator` (как ORCH-035/043/058/071); прочие репо — no-op,
+  путь LLM-`deployer`/прежний merge не затронут.
+- **Обратимость:** чисто аддитивная логика под флагом; откат = выключить флаг.
+- **Self-hosting:** без рестарта прод-контейнера; merge только через Gitea PR API; никаких операций с
+  `main` (INV-4).
+- **Анти-регресс целей merge-gate:** красный re-test → прежний rollback (BR-6); защита от
+  семантического конфликта/фантомного merge (ORCH-043/071/073) — не ослаблена.
+- **Трассировка маркеров (ORCH-078):** правки в `merge_gate.py`/`coverage_gate.py`/`qg/checks.py`
+  затрагивают блоки с маркерами ORCH-043/071/073/093/027/065/109 — перед изменением сверить их
+  `06-adr` и не сломать зафиксированные инварианты (lease, never-raise, fail-open/closed, бюджеты).

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

@@ -0,0 +1,123 @@
+---
+work_item: ORCH-110
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-110 — merge-gate re-test timeout
+
+Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
+провалом). Reviewer/тестировщик проверяет их буквально по файлам/тестам репозитория.
+
+---
+
+## AC-1 — Зелёный путь не требует ручного вмешательства из-за инфра-таймаута
+**Условие:** tester `PASS` + зелёный CI + ветка актуальна к `origin/main`, но локальный re-test
+merge-gate упирается в таймаут (смоделированное CPU-голодание/медленный прогон).
+- **PASS:** задача НЕ откатывается ложно как код-фейл и НЕ доходит до alert «Merge-gate still failing
+  after N developer retries»; она доходит до `deploy` (возможно после ограниченного defer/повтора)
+  или поднимает **отдельный инфра-alert**, отличимый от «developer must fix».
+- **FAIL:** таймаут → `_handle_merge_gate_rollback` на `development` с расходом developer-retry →
+  manual-gate (текущее ошибочное поведение).
+
+---
+
+## AC-2 — Инфра-таймаут классифицируется отдельно от красного re-test
+**Условие:** `check_branch_mergeable` вернул FAIL по причине таймаута vs по причине красного теста.
+- **PASS:** таймаут маршрутизируется в транзиент-путь (defer/повтор/инфра-alert), красный re-test —
+  в прежний rollback на `development`; пути различимы в коде и в логах/наблюдаемости.
+- **FAIL:** оба исхода идут одним путём отката на `development`.
+
+---
+
+## AC-3 — Реальный красный re-test по-прежнему откатывает (анти-над-толерантность)
+**Условие:** локальный re-test даёт детерминированно красный результат (реальный сбой теста, не
+таймаут).
+- **PASS:** задача откатывается на `development` + developer-retry (цель ORCH-043 сохранена), lease
+  освобождается.
+- **FAIL:** красный re-test «толерируется» и задача продвигается/деплоится со сломанным кодом.
+
+---
+
+## AC-4 — Нет осиротевших тест-процессов после таймаута
+**Условие:** `merge_gate.retest_branch` (и `coverage_gate.measure_coverage`) запущены против прогона,
+порождающего дочерние/внучатые процессы, и прогон превышает бюджет (таймаут).
+- **PASS:** по таймауту завершается всё дерево подпроцесса (включая внуков); живых
+  оркестратор-спавненных pytest-процессов не остаётся; контракт возврата
+  `(False, "re-test timeout after <T>s")` сохранён.
+- **FAIL:** прямой потомок убит, но внуки репарентируются и продолжают жить/грузить CPU.
+
+---
+
+## AC-5 — Бюджет re-test согласован и уважает сквозные инварианты
+**Условие:** конфигурация бюджета re-test и связанных таймаутов.
+- **PASS:** `merge_retest_timeout_s` имеет адекватный запас над фактическим временем сюита;
+  соблюдено `reaper_max_running_s > max(agent_timeout, бюджеты) + grace` и согласование с
+  `merge_lock_timeout_s`/`coverage_run_timeout_s`; малформный конфиг → дефолт + WARNING.
+- **FAIL:** бюджет оставлен впритык к времени сюита без обоснования, либо изменение бюджета ломает
+  инвариант reaper/lease.
+
+---
+
+## AC-6 — Контракт необходимости re-test зафиксирован и реализован
+**Условие:** ветка не-behind (rebase no-op) + зелёный CI по этому HEAD.
+- **PASS:** поведение локального re-test соответствует контракту, выбранному архитектором в ADR
+  (skip/scope/trust-CI-SHA и т. п.); re-test не является избыточной единственной точкой ложного
+  отказа на коммите, уже подтверждённом CI; решение и его обоснование задокументированы в `06-adr/`.
+- **FAIL:** контракт не определён/не реализован; полный re-test безусловно гоняется и при не-behind +
+  зелёном CI.
+
+---
+
+## AC-7 — Kill-switch и нулевая регрессия
+**Условие:** флаг толерантности выключен; и/или не-self-hosting репозиторий (enduro).
+- **PASS:** поведение байт-в-байт как до ORCH-110 (таймаут → прежний rollback; те же тексты
+  alert'ов); enduro-путь не затронут.
+- **FAIL:** при выключенном флаге/для enduro поведение изменилось.
+
+---
+
+## AC-8 — Инварианты конвейера и self-hosting не тронуты
+**Условие:** статический и поведенческий анализ изменений.
+- **PASS:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict ключи /
+  схема БД — без изменений; никаких push/force-push в `main` (INV-4), merge только через Gitea PR API,
+  прод-контейнер не рестартится; все публичные функции merge-gate/coverage остаются never-raise.
+- **FAIL:** изменён любой из перечисленных инвариантов, или исключение уходит в `advance_stage`.
+
+---
+
+## AC-9 — Ограниченность транзиент-пути (anti-loop) + наблюдаемость
+**Условие:** инфра-таймаут повторяется.
+- **PASS:** число повторов/defer ограничено и по попыткам, и по суммарному времени; исчерпание →
+  один чёткий инфра-alert; событие видно в логах/`GET /queue` и отличимо от код-фейла.
+- **FAIL:** бесконечный bounce/повтор, либо молчаливое зависание без терминального сигнала.
+
+---
+
+## AC-10 — Регресс-тест (красный до фикса, зелёный после)
+**Условие:** наличие автоматического теста, воспроизводящего инцидент.
+- **PASS:** в `tests/` есть тест, который на текущем коде **падал бы** (инфра-таймаут re-test →
+  ложный rollback / выживший процесс), а после фикса **зелёный**; включён в полный регресс `pytest`.
+- **FAIL:** регресс-теста нет, либо он не воспроизводит инцидент.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-1 |
+| AC-3 | BR-6 / FR-4 |
+| AC-4 | BR-3 / FR-2 |
+| AC-5 | BR-4 / FR-3 / NFR-6 |
+| AC-6 | BR-5 / FR-4 |
+| AC-7 | NFR-2 / FR-5 |
+| AC-8 | NFR-1 / NFR-3 / NFR-4 / FR-5 |
+| AC-9 | NFR-5 / BR-7 / FR-6 |
+| AC-10 | BR-1…BR-3 (регресс инцидента) |

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

@@ -0,0 +1,94 @@
+work_item: ORCH-110
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+title: "merge-gate re-test timeout: tolerance + no orphan-process leak + re-test contract"
+framework: pytest
+scope: >
+  Покрывает: классификацию инфра-таймаута re-test merge-gate как транзиента (без ложного отката),
+  tree-kill оркестратор-спавненных pytest-прогонов (re-test + coverage), сохранение красно-откат-пути,
+  согласование бюджета re-test со сквозными инвариантами, контракт необходимости re-test, kill-switch
+  и наблюдаемость. Вне покрытия: алерт sidecar-watchdog (ORCH-111), правка конкретного
+  test_install_lite_script.py, поведение enduro (только проверяется no-op).
+notes: >
+  TC-10 — ОБЯЗАТЕЛЬНЫЙ регресс-тест инцидента ORCH-109/PR#129: красный на текущем коде (инфра-таймаут
+  re-test → ложный rollback / выживший процесс), зелёный после фикса. Подпроцессы в тестах мокаются
+  (управляемый "медленный/спавнящий детей pytest"), без обращения к сети/Plane/Gitea. Полный регресс
+  tests/ должен оставаться зелёным. Точные имена символов/флагов уточняет архитектор (06-adr);
+  модули-плейсхолдеры ниже выровнены под манифест PIPELINE_DOCS.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "retest_branch: таймаут возвращает (False, 're-test timeout after <T>s') И завершает всё дерево подпроцесса (внуки не переживают таймаут)."
+    module: tests/test_orch110_retest_lifecycle.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "coverage_gate.measure_coverage: таймаут завершает всё дерево подпроцесса (сиблинг-источник утечки, BR-3); возврат None сохранён."
+    module: tests/test_orch110_retest_lifecycle.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "check_branch_mergeable: исход 'timeout' различим от 'red re-test' в reason/классификации (без смены имени/семантики зарегистрированного check_*)."
+    module: tests/test_orch110_merge_gate_classify.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Маршрутизация исхода: инфра-таймаут → defer/повтор/инфра-alert путь (НЕ _handle_merge_gate_rollback на development, без инкремента developer-retry)."
+    module: tests/test_orch110_merge_gate_routing.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Анти-над-толерантность: детерминированно КРАСНЫЙ re-test по-прежнему → откат на development + developer-retry + release lease (BR-6 сохранён)."
+    module: tests/test_orch110_merge_gate_routing.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Ограниченность (anti-loop): повторы/defer инфра-таймаута лимитированы по попыткам и суммарному времени; исчерпание → один инфра-alert, не бесконечный bounce."
+    module: tests/test_orch110_merge_gate_routing.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Kill-switch off → байт-в-байт прежнее поведение (таймаут → rollback на development, прежний текст alert); not-self repo (enduro) → no-op."
+    module: tests/test_orch110_killswitch.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Бюджет/инварианты: malformed/непозитивный merge_retest_timeout_s → дефолт + WARNING; соблюдён reaper_max_running_s > max(agent_timeout, бюджеты)+grace и согласование с merge_lock_timeout_s."
+    module: tests/test_orch110_budget_invariants.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "never-raise: любая ошибка в новом транзиент-пути → безопасный дефолт + WARNING; исключение не уходит в advance_stage."
+    module: tests/test_orch110_merge_gate_routing.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "РЕГРЕСС инцидента: tester PASS + зелёный CI + ветка не-behind, но re-test таймаут — задача НЕ откатывается ложно и НЕ упирается в 'Merge-gate still failing after N developer retries'; доходит до deploy или поднимает инфра-alert. Красный до фикса, зелёный после."
+    module: tests/test_orch110_false_rollback_regression.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "Контракт необходимости re-test (FR-4/AC-6): при не-behind + зелёном CI по HEAD локальный re-test ведёт себя по выбранному в ADR контракту (skip/scope/trust-CI) и не является избыточной единственной точкой ложного отказа. Финальная форма — после решения архитектора."
+    module: tests/test_orch110_retest_contract.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: "Наблюдаемость: инфра-таймаут отражён в логах/GET /queue (read-only) и Telegram-уведомлении с кликабельным номером; отличим от код-фейл-отката; без дубля с ORCH-111."
+    module: tests/test_orch110_observability.py
+    expected: PASS

docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md

@@ -0,0 +1,352 @@
+---
+work_item: ORCH-110
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Merge-gate re-test — толерантность к инфра-таймауту, tree-kill спавненных процессов и контракт необходимости re-test
+
+Work Item: **ORCH-110** — BUG: merge-gate local re-test timeout causes false rollback after green CI
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`**
+(решение кросс-каттинговое: затрагивает merge-gate ORCH-043, coverage-gate ORCH-027 и
+сквозной инвариант времени reaper ORCH-065/109).
+
+## Статус
+Proposed
+
+## Контекст
+
+На ребре `deploy-staging → deploy` детерминированный под-гейт **merge-gate** (`check_branch_mergeable`,
+ORCH-043) догоняет ветку до текущего `origin/main` (`auto_rebase_onto_main`) и **локально
+пере-прогоняет весь тест-сюит** (`retest_branch` → `python -m pytest tests/ -q`, бюджет
+`merge_retest_timeout_s=600`), чтобы поймать семантический конфликт слияния (зелёная по своей базе
+ветка ломает уехавший `main`).
+
+**Инцидент (ORCH-109 / PR #129, факты сверены по коду):** tester `PASS` (полный регресс
+`1899 passed` за `516.70s`), CI Gitea зелёный, PR `mergeable=true`, ветка не-behind — но merge-gate
+re-test **упал по таймауту** (`re-test timeout after 600s`). На хосте — осиротевшие pytest-процессы
+(`tests/test_install_lite_script.py`), жившие > 2 суток и грузившие CPU. Цепочка отказа: осиротевшие
+процессы → CPU-голодание → сюит (516.7s, запас до 600s ≈ 16%) превысил бюджет →
+`check_branch_mergeable` вернул `(False, "re-test timeout after 600s")` → `_handle_merge_gate`
+маршрутизировал в `_handle_merge_gate_rollback` (откат `deploy-staging → development` +
+developer-retry) → каждый из 3 retry падал по тому же CPU-голоданию → alert «Merge-gate still failing
+after 3 developer retries» → задача застряла, потребовалось ручное вмешательство.
+
+**Корни (подтверждены по коду):**
+1. **Утечка осиротевших процессов.** `merge_gate.retest_branch` (`src/merge_gate.py:202`) и
+   `coverage_gate.measure_coverage` (`src/coverage_gate.py:156`) запускают
+   `subprocess.run([... pytest ...], timeout=...)` **без изоляции группы процессов**. При
+   `TimeoutExpired` Python убивает только **прямого потомка** (`proc.kill()`); внуки pytest
+   репарентируются на PID 1 (tini жнёт зомби, но не убивает живых сирот) и живут сутками. Это
+   источник CPU-голодания.
+2. **Нет толерантности к инфра-таймауту.** `_handle_merge_gate` (`src/stage_engine.py:967`)
+   различает лишь `"merge-lock busy"` (→ defer) от всего остального (→ rollback). Re-test **таймаут**
+   (инфра/ресурс) классифицируется идентично **красному** re-test (дефект кода) → откат на
+   `development` + расход developer-retry, который разработчик не может «починить».
+3. **Тонкий бюджет.** `merge_retest_timeout_s=600` практически равен фактическому времени сюита
+   (516.7s); запас не растёт с сюитом.
+4. **Контракт необходимости re-test.** При `premerge_rebase_always=True` (дефолт, ORCH-026 A-2)
+   `check_branch_mergeable` (`src/qg/checks.py:705`) **всегда** ребейзит и пере-тестирует — даже на
+   ветке, уже актуальной к `origin/main` (rebase — no-op). На таком HEAD локальный re-test
+   пере-проверяет ровно тот коммит, что CI + tester + staging уже подтвердили, становясь избыточной
+   единственной точкой ложного отказа. (Заметим: на пути `premerge_rebase_always=False` не-behind
+   ветка re-test **уже пропускает** — `src/qg/checks.py:707-709`.)
+
+Баг-карточка явно отложила выбор механизма архитектору: «Решение намеренно не описано; нужен
+отдельный анализ вариантов и контрактов merge-gate» — основание эскалации `escalate: full-cycle`.
+
+## Решение
+
+### Сводка
+
+Бьём по двум корням, одному контракту и одному бюджету — **аддитивно, под kill-switch, never-raise,
+скоуп self-hosting**, сохраняя исходную защиту merge-gate от семантического конфликта:
+
+- **D1 (root)** — единый leaf `src/proc_group.py` спавнит оркестратор-порождённые pytest-прогоны в
+  **отдельной группе процессов** (`start_new_session`) и при таймауте/прерывании убивает **всё
+  дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL). Используют его `retest_branch` и
+  `measure_coverage`. Контракты возврата сохранены — меняется лишь побочный эффект (нет сирот).
+- **D2 (классификация)** — чистый предикат `merge_gate.classify_retest_failure(reason)` различает
+  `timeout`/`red`/`lock-busy`/`other` без смены имени/семантики `check_branch_mergeable`.
+- **D3 (маршрутизация)** — инфра-таймаут → новый `_handle_merge_gate_infra_retry` (ограниченный
+  повтор/defer по образцу `_handle_merge_gate_defer`, **без** отката на `development` и **без**
+  расхода developer-retry); красный re-test → прежний `_handle_merge_gate_rollback`.
+- **D4 (контракт re-test)** — re-test исполняется **тогда и только тогда**, когда rebase реально
+  сдвинул HEAD (`main` уехал); no-op rebase (ветка уже актуальна) **пропускает** локальный re-test,
+  ровно как уже делает путь `premerge_rebase_always=False` для не-behind ветки.
+- **D5 (бюджет)** — `merge_retest_timeout_s` 600 → **900** (запас 74% над 516.7s) с валидацией и
+  проверкой сквозного инварианта reaper/lease — **без** изменения `reaper_max_running_s`.
+- **D6 (наблюдаемость)** — счётчики в `merge_gate`, блок `merge_gate` в `GET /queue`, отдельный
+  инфра-alert, отличимый от код-фейла; координация с ORCH-111 без дубля.
+
+### D1 — Process-group изоляция + tree-kill спавненных pytest [FR-2 / BR-3 / AC-4]
+
+Новый **leaf-модуль** `src/proc_group.py` (stdlib-only, never-raise, импортирует только `os`/`signal`/
+`subprocess`/`time`/`logging` — НЕ другие `src/*`, по образцу чистоты `serial_gate`/`staging_verdict`):
+
+```python
+def run_in_process_group(
+    cmd: list[str], *, cwd: str, timeout: float, env: dict | None = None,
+    grace_s: float = 5.0, tree_kill: bool = True,
+) -> ProcResult:   # ProcResult(returncode:int|None, stdout:str, stderr:str, timed_out:bool)
+```
+
+Механика (POSIX):
+1. `proc = subprocess.Popen(cmd, cwd=cwd, env=env, stdout=PIPE, stderr=PIPE, text=True,
+   start_new_session=True)` — `start_new_session=True` делает потомка лидером новой сессии/группы
+   (`setsid`), поэтому все его потомки (xdist-воркеры, подпроцессы тестов) разделяют один `pgid ==
+   proc.pid`.
+2. `proc.communicate(timeout=timeout)` — ждём в бюджете.
+3. На `subprocess.TimeoutExpired` — **tree-kill группы** каскадом, зеркало `launcher.stop_process`,
+   но по **группе**: `os.killpg(os.getpgid(pid), SIGTERM)` → poll `grace_s` → если жива
+   `os.killpg(..., SIGKILL)`; затем обязательный `proc.communicate()`/`proc.wait()` (reap), чтобы не
+   оставить зомби. `ProcessLookupError` толерируется на каждом шаге.
+4. Возвращает `timed_out=True` при таймауте; иначе `returncode`/stdout/stderr.
+
+**Fallback (never-break):** при `tree_kill=False` ИЛИ платформе без `os.killpg`/`start_new_session`
+(`not hasattr(os, "killpg")`) — деградирует на прежний `subprocess.run(cmd, ..., timeout=timeout)`
+(байт-в-байт прежнее поведение, прод-Linux на это не попадает).
+
+**Интеграция:**
+- `retest_branch` зовёт `run_in_process_group([... pytest target -q], cwd=wt, timeout=<resolved>,
+  tree_kill=settings.subprocess_tree_kill_enabled, grace_s=settings.agent_kill_grace_seconds)`;
+  маппинг исхода 1:1 прежнему: `timed_out → (False, "re-test timeout after <T>s")`,
+  `returncode==0 → (True, "re-test green")`, иначе `(False, "re-test failed: ...<tail>")`. **Контракт
+  возврата сохранён** (FR-2) — меняется лишь отсутствие утечки.
+- `measure_coverage` зовёт тот же helper для `pytest --cov`; исход маппится как сейчас (таймаут/ошибка
+  → `None`, иначе чтение `--cov-report=json`). Грантия tree-kill — сиблинг-источник утечки закрыт
+  (BR-3).
+
+Грейс берётся из существующего `agent_kill_grace_seconds` (новый ключ не вводим — минимизация
+конфига); для subprocess-pytest грейс короткий и без необходимости «флашить артефакты».
+
+Kill-switch `subprocess_tree_kill_enabled` (дефолт `True`). Это **глобальная** гигиена процессов (не
+гейт-решение), поэтому без `*_repos`-скоупа; на практике оба call-site исполняются лишь для
+merge_gate/coverage-репо (self-hosting).
+
+### D2 — Классификация исхода re-test [FR-1 / AC-2 / TC-03]
+
+Чистый предикат в `src/merge_gate.py` (never-raise), единая точка «магической строки» вместо россыпи
+`"timeout" in reason`:
+
+```python
+def classify_retest_failure(reason: str) -> str:
+    # "timeout"  — re-test упёрся в бюджет (инфра/ресурс)
+    # "red"      — детерминированно красный re-test (дефект кода)
+    # "lock-busy"— merge-lock busy (контеншн леза)
+    # "other"    — rebase conflict / setup error / прочее
+```
+
+`check_branch_mergeable` **не меняет** имя/семантику/PASS-FAIL контракт (NFR-1): он уже возвращает
+различимый reason (`"re-test timeout after <T>s"` vs `"re-test failed after rebase: ..."` vs
+`"merge-lock busy"` vs `"rebase conflict: ..."`). Меняется только **различение причины FAIL** на
+слое маршрутизации.
+
+**Скоуп классификации — строго re-test таймаут.** `auto_rebase_onto_main` имеет собственный
+`"rebase timeout"` (git завис) — это **другой** инфра-таймаут, но без успешного rebase ветку нельзя
+догнать до `main` → merge невозможен по существу. Он остаётся на прежнем rollback-пути (вне объёма
+ORCH-110; консервативно). Документируем границу явно.
+
+### D3 — Маршрутизация инфра-таймаута: ограниченный повтор + инфра-alert [FR-1 / FR-6 / NFR-5 / AC-1 / AC-9]
+
+В `_handle_merge_gate` (`src/stage_engine.py`) после ветки `reason == "merge-lock busy"`:
+
+```python
+if (settings.merge_retest_infra_tolerance_enabled
+        and merge_gate.classify_retest_failure(reason) == "timeout"):
+    _handle_merge_gate_infra_retry(task_id, current_stage, repo, work_item_id, branch, reason, result)
+    return True
+_handle_merge_gate_rollback(...)   # red re-test / conflict — БЕЗ изменений (BR-6/AC-3)
+```
+
+Новый `_handle_merge_gate_infra_retry` — зеркало `_handle_merge_gate_defer` (НЕ rollback):
+- Перекладывает staging-deployer обратно в очередь с задержкой `merge_retest_infra_retry_delay_s`
+  (`enqueue_job("deployer", ..., available_at_delay_s=...)`); задача **остаётся на `deploy-staging`**.
+  **Нет** `update_task_stage("development")`, **нет** инкремента developer-retry, **нет**
+  `notify_qg_failure`-код-фейл-семантики.
+- Счётчик повторов — restart-safe, по маркеру в `task_content` (`_merge_infra_retry_count`, зеркало
+  `_merge_defer_count`: `... LIKE '%merge-gate infra-timeout retry%'`). Бюджет
+  `merge_retest_infra_max_retries` (дефолт 2).
+- **Лиз уже освобождён** `check_branch_mergeable` при таймауте (`src/qg/checks.py:721`) — на повторе
+  гейт переacquire'ит штатно (как defer-путь). Согласовано с инвариантом леза.
+- **Исчерпание (anti-loop, NFR-5):** `set_issue_blocked` + **отдельный инфра-alert** (Telegram с
+  кликабельным `link_for` + Plane-коммент), формулировка **явно инфраструктурная**, отличная от
+  «developer must fix»: *«Merge-gate re-test infra-timeout сохраняется после N повторов — ресурсная
+  проблема (CPU/осиротевшие процессы), НЕ дефект кода. Нужно ручное вмешательство /
+  проверьте хост.»* Задача **не** уходит в `development`.
+
+**Ограниченность по времени (NFR-5/AC-9).** Каждый повтор — **отдельный** staging-deployer job со
+своим agent-timeout и reaper-backstop; ни один прогон не превышает `reaper_max_running_s` сам по себе.
+Суммарная стоимость худшего случая: `N × (delay + re-test ≤ timeout)` =
+`2 × (120 + 900) ≈ 34 мин` до инфра-alert — конечно и наблюдаемо. После первого таймаута D1 уже убил
+сирот, поэтому следующий re-test, как правило, проходит — повтор есть механизм восстановления, а не
+маскировки.
+
+**Скоуп.** Отдельный `*_repos` не нужен: путь достижим только когда merge-gate **реален**
+(`_merge_gate_applies` → self-hosting/`merge_gate_repos`); для прочих репо гейт N/A → PASS → ветка
+недостижима. Kill-switch off → таймаут идёт прежним rollback-путём (NFR-2, байт-в-байт).
+
+### D4 — Контракт необходимости локального re-test [FR-4 / BR-5 / BR-6 / AC-6]
+
+**Выбранный вариант — пропуск re-test при no-op rebase** (ветка уже содержит свежий `origin/main`).
+ORCH-043 защищает от семантического конфликта, который возникает **только** когда `main` уехал и
+ветка была реально ребейзнута на новые коммиты. Если rebase HEAD **не сдвинул** (ветка уже актуальна),
+«уехавшего main» нет → re-test не даёт сигнала сверх уже пройденных `check_ci_green` + tester
+`check_tests_passed` + staging на **этом же** HEAD → он избыточен.
+
+Реализация в `check_branch_mergeable` (детерминированно, **offline**, без сетевого CI-запроса):
+1. `pre = _head_sha(repo, branch)` (rev-parse HEAD в worktree, never-raise → `""`).
+2. `auto_rebase_onto_main(...)` (как сейчас; конфликт → release lease → FAIL без изменений).
+3. `post = _head_sha(repo, branch)`.
+4. Если `merge_retest_skip_when_current_enabled` И `pre` и `post` непусты И `pre == post` (rebase —
+   доказанный no-op) → **пропустить re-test**, вернуть
+   `(True, "branch up-to-date (re-test skipped: rebase no-op, HEAD CI-validated)")`; лиз HELD.
+5. Иначе (HEAD сдвинут / SHA не определить / флаг off) → `retest_branch` как сейчас.
+
+**Почему без отдельного сетевого CI-запроса (отличие от варианта C).** HEAD на момент merge-gate при
+no-op rebase — тот же коммит, что уже прошёл `check_ci_green` (ребро development→review), tester и
+staging в этом же конвейере. «CI green for this HEAD» гарантирован **транзитивно** пройденным
+конвейером; повторный сетевой запрос статуса — лишняя зависимость и хрупкость.
+
+**Fail-safe к контракту (BR-6/AC-3):** при невозможности доказать no-op (любой `pre`/`post` пуст,
+git-ошибка) — re-test **выполняется** (не пропускается на неопределённости). Когда re-test
+**исполняется** и красный → прежний rollback. Послабление применяется ТОЛЬКО к доказанному no-op, и
+только к *пропуску*, не к красному вердикту. Это симметрично уже существующему пропуску re-test на
+не-behind ветке при `premerge_rebase_always=False` — D4 лишь распространяет ту же оптимизацию на
+no-op-rebase случай `premerge_rebase_always=True`, приводя оба режима к согласованному правилу:
+«локальный re-test гоняется лишь когда ветка реально догоняла уехавший `main`».
+
+Kill-switch `merge_retest_skip_when_current_enabled` (дефолт `True`); off → re-test после rebase
+всегда (прежнее `premerge_rebase_always` поведение).
+
+### D5 — Согласование бюджета re-test [FR-3 / BR-4 / AC-5 / NFR-6]
+
+`merge_retest_timeout_s`: **600 → 900** (запас 74% над наблюдаемыми 516.7s; против прежних ≈16%).
+Бюджет — теперь **третья** линия защиты (D1 убирает корень CPU-голодания, D3 толерирует редкий
+остаточный таймаут, D4 резко сокращает частоту re-test), поэтому большой бамп не нужен; умеренные 900
+дают runway под рост сюита, оставаясь в сквозном инварианте reaper **без** правки
+`reaper_max_running_s`.
+
+**Валидация (never-break):** `retest_branch` резолвит бюджет через новый
+`_resolve_retest_timeout()` — `int(settings.merge_retest_timeout_s)` если `> 0`, иначе дефолт **900**
++ WARNING (зеркало `launcher._resolve_timeout`). Малформ/непозитив больше не уходит в `subprocess`.
+
+**Проверка сквозного инварианта (NFR-6, AC-5).** Re-test/coverage исполняются в монитор-потоке
+**staging-deployer**-джоба (агент deployer уже завершён; `advance_stage` post-agent), поэтому суммарная
+работа джоба считается против `reaper_max_running_s`. Worst-case для deploy-staging-джоба:
+
+| Слагаемое | Бюджет, s |
+|-----------|-----------|
+| deployer-агент (deploy-staging, `agent_timeout_seconds`) | 1800 |
+| security-scan (gitleaks+pip-audit) | ~120 |
+| rebase (`_REBASE_TIMEOUT`) | 120 |
+| **re-test (`merge_retest_timeout_s`, новый)** | **900** |
+| coverage (`coverage_run_timeout_s`) | 900 |
+| image-freshness rebuild | ~600 |
+| grace | 20 |
+| **Σ** | **≈ 4460** |
+
+`reaper_max_running_s = 5400 > 4460` ✓ (запас ~940s). Инвариант ORCH-065/109
+`reaper_max_running_s > max(agent_timeout)+grace` (5400 > 3600+20 для developer-джоба) сохранён.
+`merge_lock_timeout_s = 300` (TTL леза) **меньше** держания леза на время re-test+coverage — но это
+**существующее** свойство (ORCH-043: лиз держится от гейта до merge, дольше TTL; реклейм безопасен
+holder-aware и pid-aware, ORCH-065) и **не** ухудшается ORCH-110 (re-test 900 vs прежние 600 — +300s
+держания, всё ещё покрыто pid-liveness реклеймом, который не трогает живого держателя). Поэтому
+`reaper_max_running_s` **не меняем**; D5 — только бамп `merge_retest_timeout_s` + валидация.
+
+> Если оператор поднимет `merge_retest_timeout_s` env'ом выше — обязан соблюсти
+> `reaper_max_running_s > Σ(deploy-staging gate-work) + grace` (таблица выше); зафиксировано в
+> `07-infra-requirements.md`.
+
+### D6 — Наблюдаемость и координация с ORCH-111 [FR-6 / BR-7 / AC-9 / R-4]
+
+- **Счётчики** in-process в `merge_gate.py` (`_MERGE_GATE_COUNTERS`, образец `_MERGE_VERIFY_COUNTERS`):
+  `retest_timeout_total`, `retest_infra_retry_total`, `retest_infra_exhausted_total`,
+  `retest_skipped_current_total`, `last_infra_timeout_wi`. Снимок `merge_gate_status()` → read-only
+  блок `merge_gate` в `GET /queue` (флаги/счётчики). Только информация, никогда не источник решения.
+- **Логи** — раздельные строки для infra-retry vs code-fail rollback; INFO на пропуск re-test (D4).
+- **Telegram/Plane** — инфра-alert на исчерпании (D3), формулировка инфраструктурная (не «developer
+  must fix») с кликабельным номером.
+- **Координация с ORCH-111 (`proc_blocking`, adr-0041) — без дубля (R-4):** ORCH-110
+  **предотвращает/толерирует** (tree-kill у источника + транзиент-маршрут), ORCH-111 **наблюдает**
+  (sidecar алертит на пережившие осиротевшие тест-процессы). ORCH-110 не вводит детектор процессов;
+  он убирает сирот у источника. Разные слои — нулевое пересечение.
+
+### Затронутые маркеры / трассировка (ORCH-078)
+
+Правки касаются блоков с маркерами ORCH-043 (`retest_branch`, `check_branch_mergeable`, lease),
+ORCH-026 (`premerge_rebase_always`), ORCH-027 (`measure_coverage`), ORCH-065/109 (инвариант
+reaper/timeout). 3+ маркера в `merge_gate.py` → опираемся на **сводный сквозной**
+`adr-0042` (этот пакет) + `adr-0006`/`adr-0040`. Инварианты ORCH-043/071/073/093 (лиз holder-aware,
+INV-4 «никогда push/force-push main», never-raise, fail-open/closed классификации) **не нарушаются**:
+ORCH-110 не трогает merge-актор/верификатор пути `deploy → done`.
+
+**Директива developer'у (append-only regression-guard, ORCH-073):** дописать в
+`merge_gate.MAIN_REGRESSION_MARKERS` строку `("ORCH-110", "classify_retest_failure",
+"src/merge_gate.py")`, чтобы новый инвариант был защищён от фантомного отката.
+
+## Альтернативы
+
+- **Только поднять бюджет (без D1).** Отвергнуто (R-2): не бьёт корень — растущий сюит снова упрётся;
+  сироты продолжат грузить CPU. Бюджет — вторичная мера.
+- **Tree-kill через `subprocess.run` + ручной `Popen` в каждом модуле (без общего leaf).** Отвергнуто:
+  дублирование хрупкой `killpg`-логики в двух местах → дрейф. Один тестируемый leaf
+  (`proc_group.py`) — single source of truth.
+- **Вариант C: trust-CI-SHA (сетевой запрос статуса CI HEAD → skip re-test).** Отвергнуто как контракт
+  по умолчанию: вводит сетевую зависимость в детерминированный offline-гейт и ослабляет
+  семантик-конфликт-гард (CI бежал на базе ветки, не на результате слияния). D4 (no-op-rebase skip)
+  даёт ту же выгоду детерминированно и offline.
+- **Толерировать ЛЮБОЙ FAIL merge-gate (включая красный) как транзиент.** Отвергнуто (BR-6/AC-3,
+  R-1): сломает цель ORCH-043 — красный re-test обязан откатывать. Послабление строго к таймауту.
+- **Новый зарегистрированный QG / новая стадия для инфра-ретрая.** Отвергнуто (NFR-1): под-гейт —
+  врезка в `advance_stage`; `STAGE_TRANSITIONS`/`QG_CHECKS` неприкосновенны.
+- **Init-process / убийца сирот на хосте.** Отвергнуто: реинтродукция привилегий/хост-доступа;
+  предотвращение у источника (D1) проще и self-hosting-безопасно; наблюдение оставлено ORCH-111.
+
+## Последствия
+
+- **+** Зелёный путь (tester PASS + CI green + актуальная ветка) больше не ловит ложный откат/manual-gate
+  из-за инфра-таймаута (BR-1/AC-1). Сироты не переживают бюджет (BR-3/AC-4). Re-test не гоняется
+  избыточно на актуальной ветке (BR-5/AC-6), что само снижает шанс таймаута.
+- **+** Красный re-test по-прежнему откатывает (BR-6/AC-3); инварианты конвейера/леза/INV-4
+  неприкосновенны (NFR-1/NFR-3/AC-8).
+- **−** Инфра-таймаут добавляет до `N×(delay+timeout)` (~34 мин) к худшему случаю перед инфра-alert
+  (вместо мгновенного, но ложного, отката). Митигейшн: D1 устраняет первопричину → повтор обычно
+  проходит первым; бюджет повторов мал (2).
+- **−** +5 конфиг-ключей + бамп бюджета. Митигейшн: дефолты = желаемое прод-поведение (ORCH-101
+  канон), каждый под kill-switch.
+- **−** D4 пропускает re-test на no-op rebase: теоретический пропуск семантик-конфликта, не
+  поймать который CI/tester/staging уже не смогли бы. Митигейшн: пропуск **только** при доказанном
+  no-op (нет «уехавшего main» → нет нового класса конфликта); на любой неопределённости — re-test
+  бежит (fail-safe).
+- **Откат:** `subprocess_tree_kill_enabled=False` (→ прежний `subprocess.run`),
+  `merge_retest_infra_tolerance_enabled=False` (→ таймаут=rollback),
+  `merge_retest_skip_when_current_enabled=False` (→ всегда re-test после rebase),
+  `merge_retest_timeout_s=600` (→ прежний бюджет). Каждый флаг независим; полный откат = вернуть 4
+  значения → байт-в-байт до-ORCH-110.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-110/01-brd.md`
+- TRZ: `docs/work-items/ORCH-110/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-110/03-acceptance-criteria.md`
+- Test-plan: `docs/work-items/ORCH-110/04-test-plan.yaml`
+- Инфра: `docs/work-items/ORCH-110/07-infra-requirements.md`
+- Риски: `docs/work-items/ORCH-110/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`
+- Сверено по коду: `src/merge_gate.py` (`retest_branch`, `auto_rebase_onto_main`,
+  `MAIN_REGRESSION_MARKERS`), `src/coverage_gate.py` (`measure_coverage`),
+  `src/qg/checks.py` (`check_branch_mergeable`, `_merge_gate_applies`),
+  `src/stage_engine.py` (`_handle_merge_gate`, `_handle_merge_gate_defer`,
+  `_handle_merge_gate_rollback`, `_merge_defer_count`),
+  `src/config.py` (`merge_retest_timeout_s`, `reaper_max_running_s`, `agent_kill_grace_seconds`),
+  `src/agents/launcher.py` (`stop_process` — образец каскада),
+  `src/job_reaper.py` (`reaper_max_running_s` backstop)
+- Смежные: `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` — комплементарный наблюдатель)
+</content>
+</invoke>

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

@@ -0,0 +1,68 @@
+---
+work_item: ORCH-110
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-110 — merge-gate re-test infra-tolerance + tree-kill
+
+Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Топология/контейнеры/порты/CI **не меняются**; файл фиксирует новые env-ключи,
+> сквозной инвариант времени и аудит self-hosting безопасности.
+
+## I-1. Топология / окружения
+**N/A.** Новых контейнеров/портов/томов/сетей нет. Изменения — только в коде приложения
+(`src/proc_group.py` новый leaf; правки `merge_gate`/`coverage_gate`/`qg.checks`/`stage_engine`/
+`config`) и в значениях конфигурации. Прод `orchestrator` (8500) / staging (8501) — без изменений
+топологии.
+
+**Требование среды:** оркестратор должен исполняться под POSIX (Linux-контейнер, как сейчас) — D1
+использует `os.setsid`/`os.killpg`/`os.getpgid`. На не-POSIX helper деградирует на прежний
+`subprocess.run` (never-break), но боевая среда — Linux.
+
+## I-2. Переменные окружения / секреты
+Секретов нет. Новые ключи (`src/config.py` + `.env.example`); **дефолт каждого = желаемому
+прод-поведению** (ORCH-101 канон: пустой `.env` воспроизводит целевое поведение):
+
+| Ключ (config) | Env | Дефолт | Назначение |
+|---------------|-----|--------|------------|
+| `subprocess_tree_kill_enabled` | `ORCH_SUBPROCESS_TREE_KILL_ENABLED` | `True` | D1 kill-switch; off → прежний `subprocess.run(timeout=)` |
+| `merge_retest_infra_tolerance_enabled` | `ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED` | `True` | D3 kill-switch; off → таймаут = прежний rollback |
+| `merge_retest_infra_max_retries` | `ORCH_MERGE_RETEST_INFRA_MAX_RETRIES` | `2` | D3 бюджет повторов инфра-таймаута |
+| `merge_retest_infra_retry_delay_s` | `ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S` | `120` | D3 задержка перед повтором staging-deployer |
+| `merge_retest_skip_when_current_enabled` | `ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED` | `True` | D4 kill-switch; off → re-test после rebase всегда |
+| `merge_retest_timeout_s` (изменение значения) | `ORCH_MERGE_RETEST_TIMEOUT_S` | `600 → 900` | D5 бюджет re-test (запас 74% над 516.7s) |
+
+Реюз существующего `agent_kill_grace_seconds` (грейс tree-kill каскада) — новый ключ не вводится.
+
+## I-3. Деплой / рестарт
+- **Self-hosting инвариант соблюдён:** изменение НЕ рестартит прод-контейнер, НЕ пушит/force-push
+  `main` (INV-4), НЕ трогает detached-деплой. Выкат — штатным конвейером через **обязательный
+  staging-гейт (8501)**.
+- Дефолты вступают в силу при следующей сборке образа; ручных env-шагов на хосте не требуется
+  (дефолты = целевое поведение). Откат — выставить 4 kill-switch в `False` и
+  `ORCH_MERGE_RETEST_TIMEOUT_S=600`.
+
+## I-4. CI/CD
+**Без изменений** `.gitea/workflows/`. Новые pytest-тесты (`tests/test_orch110_*.py` по
+`04-test-plan.yaml`) исполняются существующим шагом `pytest tests/ -q`. Новых зависимостей нет
+(`proc_group` — stdlib-only; `pytest-cov` уже в образе по ORCH-027).
+
+## I-5. Сквозной инвариант времени (NFR-6 — операционно критично)
+Re-test/coverage исполняются в монитор-потоке staging-deployer-джоба, поэтому их суммарная работа
+считается против `reaper_max_running_s`. Проверенный worst-case deploy-staging-джоба:
+
+```
+deployer-агент 1800 + security ~120 + rebase 120 + re-test 900 + coverage 900 + image ~600 + grace 20
+≈ 4460 s  <  reaper_max_running_s = 5400   (запас ~940 s)  ✓
+```
+
+`reaper_max_running_s` **не меняется** (D5). При ручном повышении `ORCH_MERGE_RETEST_TIMEOUT_S` env'ом
+оператор ОБЯЗАН сохранить неравенство `reaper_max_running_s > Σ(gate-work) + grace`, иначе reaper
+(ORCH-065) может реапнуть легитимный мид-гейт джоб; при необходимости поднять
+`ORCH_REAPER_MAX_RUNNING_S` в локстеп (паттерн ORCH-109).
+</content>

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

@@ -0,0 +1,40 @@
+---
+work_item: ORCH-110
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-110 — merge-gate re-test infra-tolerance + tree-kill
+
+Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Над-толерантность маскирует реально зависший тест ветки** как «инфра» (R-1 BRD): бесконечный/долгий тест ветки → таймаут → толерируется → задача не падает на дефекте | Низ. | Выс. | Строгая ограниченность D3 (`merge_retest_infra_max_retries=2`, суммарное время ≤ ~34 мин) → исчерпание = **инфра-alert** (не молчание); красно-откат-путь сохранён (BR-6); D4 не пропускает re-test когда HEAD реально сдвинут. Остаточно: «зависший тест ветки» эскалируется как инфра, а не код — приемлемо (оператор увидит alert и разберёт; тест-зависание чинит developer вручную) |
+| TR-2 | **`os.killpg`/`start_new_session` платформенная зависимость** (не-POSIX / урезанный контейнер) | Низ. | Сред. | Гард `hasattr(os, "killpg")` + kill-switch `subprocess_tree_kill_enabled` → fallback на прежний `subprocess.run` (never-break); бой — Linux |
+| TR-3 | **Tree-kill убьёт не те процессы** (неверный pgid → SIGKILL чужой группе) | Низ. | Выс. | `pgid == proc.pid` гарантирован `start_new_session` для **нашего** потомка; killpg только по `os.getpgid(proc.pid)` нашего Popen; `ProcessLookupError` толерируется; никогда не киляем pgid 0/own |
+| TR-4 | **Рассинхрон сквозных таймаутов** при бампе бюджета (R-3 BRD): re-test 900 + coverage 900 + агент → > reaper_max_running_s | Низ. | Сред. | Проверенная таблица worst-case (≈4460 < 5400, 07-infra I-5); `reaper_max_running_s` не меняется; валидация непозитивного бюджета → дефолт+WARNING; операторская заметка про ручной бамп |
+| TR-5 | **Магическая строка классификации** (`"timeout" in reason`) хрупка к смене текста reason | Низ. | Сред. | Единый предикат `classify_retest_failure` (одна тестируемая точка, TC-03) вместо россыпи; reason — стабильный контракт ORCH-043 (как `"merge-lock busy"`) |
+| TR-6 | **D4 пропустит re-test и пропустит семантический конфликт** | Оч.низ. | Сред. | Пропуск ТОЛЬКО при доказанном no-op rebase (нет «уехавшего main» → нет нового класса конфликта); на неопределённости (`pre`/`post` пуст / git-ошибка) re-test бежит (fail-safe); HEAD уже прошёл CI+tester+staging транзитивно |
+| TR-7 | **Дубль/конфликт с ORCH-111** (`proc_blocking`) | Оч.низ. | Низ. | Чёткое разделение слоёв (D6): ORCH-110 предотвращает/толерирует у источника, ORCH-111 наблюдает; ORCH-110 не вводит детектор процессов |
+| TR-8 | **Регресс при выключенном флаге** (нарушен байт-в-байт fallback) | Низ. | Выс. | TC-07 проверяет kill-switch off = прежнее поведение и enduro no-op; каждый из 4 флагов независим и off → старый путь |
+| TR-9 | **Гонка leдза на инфра-ретрае** (повторный acquire, держание дольше TTL) | Низ. | Сред. | Существующее свойство ORCH-043 (лиз держится дольше TTL; реклейм holder-aware + pid-aware, ORCH-065 не трогает живого держателя); таймаут уже освободил лиз перед ретраем — переacquire штатный |
+
+## Сводный вывод
+Доминирующий класс — **над-толерантность vs анти-регресс защиты merge-gate** (TR-1/TR-6): закрыт
+строгой ограниченностью + сохранением красно-откат-пути + пропуском re-test только на доказанном
+no-op. Остальные риски — стандартного класса (платформенная зависимость, сквозные таймауты,
+kill-switch регресс), митигированы существующими паттернами кодовой базы (never-raise, fail-safe,
+дефолт=бой, валидация). Изменение **аддитивно** и **полностью обратимо** флагами; новой стадии/QG/
+схемы БД нет. **Эскалация `arch:major-change` не требуется**; возврат в анализ не требуется. Остаточный
+риск для прод-конвейера (self-hosting) — **низкий**: critical-path не трогает `main`/прод-рестарт/
+detached-деплой, а наихудший новый сценарий (инфра-alert после ретраев) строго лучше текущего (ложный
+manual-gate).
+</content>

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

@@ -0,0 +1,112 @@
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-110
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-110
+version: 1
+---
+
+# Review ORCH-110
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter. `APPROVED` → дальше по конвейеру.
+
+## Summary
+Багфикс инцидента ORCH-109/PR#129 (bug → escalate full-cycle): локальный re-test merge-gate падал по
+**таймауту** при зелёных CI+tester+staging → ложно маршрутизировался как код-фейл (откат
+`deploy-staging → development` + расход developer-retry) → manual-gate. Реализация **полностью
+соответствует ТЗ (FR-1…FR-6, AC-1…AC-10) и ADR-001 (D1…D6)**, аддитивна, под 5 независимыми
+kill-switch, never-raise, скоуп self-hosting. Инварианты конвейера и self-hosting — байт-в-байт целы;
+документация (golden source) обновлена в том же PR; багфикс несёт регресс-тест-фиксатор (ORCH-019 BR-4 /
+AC-10). **Вердикт: APPROVED** — P0/P1/P2 findings нет.
+
+> Замечание по ревью-процессу (не finding): локальный ref `main` в worktree устарел (6a04d0a);
+> истинная цель мержа — `origin/main` (b6c9d27, уже содержит ORCH-111). Диф против `origin/main`
+> добавляет ровно 4 ORCH-110-коммита (fix + analysis + architect + business-request); посторонних
+> изменений нет. Ревью проведено против `origin/main`.
+
+## Оси проверки
+
+### 1. Соответствие ТЗ (02-trz / 03-acceptance-criteria) — PASS
+- **FR-1/AC-1/AC-2** (толерантность к инфра-таймауту, отдельная классификация): `merge_gate.classify_retest_failure`
+  (`timeout`/`red`/`lock-busy`/`other`) + `stage_engine._handle_merge_gate_infra_retry` (зеркало
+  `_handle_merge_gate_defer`: задача остаётся на `deploy-staging`, БЕЗ отката/developer-retry). ✓
+- **FR-2/AC-4** (tree-kill): новый stdlib-only leaf `src/proc_group.py::run_in_process_group`
+  (`start_new_session` → `os.killpg` SIGTERM→grace→SIGKILL), интегрирован в `retest_branch` и
+  `measure_coverage`; реальный grandchild-тест TC-01 доказывает «сирота не переживает таймаут». ✓
+- **FR-3/AC-5** (бюджет): `merge_retest_timeout_s` 600→900 + `_resolve_retest_timeout` (малформ/непозитив
+  → дефолт 900 + WARNING); сквозной инвариант `reaper_max_running_s (5400) > Σ≈4460 + grace` проверен
+  тестом TC-08 **без** правки `reaper_max_running_s`. ✓
+- **FR-4/AC-6/AC-3 (BR-6)** (контракт необходимости re-test): пропуск re-test при доказанном no-op rebase
+  (`head_sha` до==после, обе непусты) в `check_branch_mergeable`; fail-safe — на любой неопределённости
+  re-test выполняется; красный re-test/конфликт по-прежнему откатывают (тест
+  `test_tc10_real_catchup_red_retest_still_rolls_back`). ✓
+- **FR-5/AC-7/AC-8** (kill-switch + нулевая регрессия + инварианты): 5 независимых флагов (дефолт = боевое);
+  `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имя `check_branch_mergeable`/machine-verdict/схема БД —
+  статически подтверждено «не тронуты»; INV-4 (никогда push/force-push `main`) соблюдён. ✓
+- **FR-6/AC-9** (наблюдаемость + anti-loop): счётчики `_MERGE_GATE_COUNTERS` + read-only блок `merge_gate`
+  в `GET /queue`; ограниченность по попыткам (`merge_retest_infra_max_retries=2`, restart-safe счётчик по
+  маркеру в `task_content`) и времени; исчерпание → один инфра-alert (явно «НЕ дефект кода»). ✓
+- **AC-10** (регресс red-before/green-after): `tests/test_orch110_false_rollback_regression.py` гоняет
+  РЕАЛЬНЫЙ `check_branch_mergeable` через `advance_stage`; на до-ORCH-110-коде оба сценария упали бы
+  (Scenario A гоняла бы обречённый re-test, Scenario B откатилась бы на `development`). ✓
+
+### 2. Соответствие ADR + трассировка маркеров (ORCH-078) — PASS
+- D1…D6 реализованы как зафиксировано в `06-adr/ADR-001` + сквозном `adr-0042`. ✓
+- Директива developer'у выполнена: `("ORCH-110", "classify_retest_failure", "src/merge_gate.py")`
+  дописан в `MAIN_REGRESSION_MARKERS` (append-only, существующие маркеры целы). ✓
+- Затронутые маркеры ORCH-043/071/073/093/027/065/109 сверены, зафиксированные инварианты **не сломаны**:
+  лиз held-on-success / released-on-failure (контракт `check_branch_mergeable` сохранён, skip-путь
+  возвращает `(True, …)` с HELD lease), anti-phantom pre-merge rebase не тронут, coverage fail-open `None`
+  сохранён, reaper-инвариант проверен численно.
+
+### 3. Качество кода — PASS
+- never-raise по всему пути (leaf `proc_group`, классификатор, врезка `_handle_merge_gate_infra_retry`
+  обёрнута в `_handle_merge_gate_infra_retry`/`_merge_gate_infra_retry_impl` с проглатыванием исключения).
+- Docstrings на всех публичных функциях; чёткое разделение чистого предиката и I/O.
+- Тесты содержательные (реальный kill дерева процессов, реальная маршрутизация через `advance_stage`,
+  валидация бюджета, kill-switch-параметризация, наблюдаемость). Прогон зелёный:
+  141 (ORCH-110 + изменённые merge/coverage/config) + 575 (широкая зона stage_engine/qg/merge/deploy/reaper)
+  + 37 (docs-инварианты, ORCH-011 + host-hardcodes) — все PASS.
+- **Багфикс-трек (ORCH-019 BR-4):** исправление несёт тест-фиксатор дефекта (AC-10) — требование выполнено.
+
+### 4. Документация — PASS (приоритетная проверка)
+`src/` изменён → документация обновлена в **том же PR**:
+- `CLAUDE.md` — добавлена секция ORCH-110 (паспорт). ✓
+- `CHANGELOG.md` — запись `[Unreleased]` с разбивкой D1…D6 + 5 ключей. ✓
+- `.env.example` — 5 новых ключей + бамп `ORCH_MERGE_RETEST_TIMEOUT_S=900` с врезкой про сквозной
+  инвариант. ✓
+- `docs/architecture/README.md` — поведение merge-gate re-test (D1…D6) + ссылки на ADR. ✓
+- `docs/overview/tech-pipeline.md` — **витрина системы (ORCH-011)** обновлена: исключение «инфра-таймаут =
+  транзиент, не откат»; `tests/test_system_docs.py` зелёный. ✓
+- Глобальный сквозной ADR `docs/architecture/adr/adr-0042-…md` + work-item `06-adr/ADR-001-…md` заведены. ✓
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice-to-have (не блокирует)
+- В `check_branch_mergeable` (`src/qg/checks.py:750`) причина FAIL раскладывается локальной подстрокой
+  `"timeout" in t_reason`, тогда как введён точный предикат `merge_gate.classify_retest_failure`. Поведение
+  безопасно (авторитетная маршрутизация в `stage_engine._handle_merge_gate` использует классификатор; редкий
+  `"re-test error: …"` со словом «timeout» в детали безопасно уйдёт в `other`→rollback), но единая точка
+  классификации читалась бы чище. Косметика, на усмотрение.
+
+## Документация
+**Обновлена полностью в том же PR** (golden source наравне с кодом): `CLAUDE.md`, `CHANGELOG.md`,
+`.env.example`, `docs/architecture/README.md`, витрина `docs/overview/tech-pipeline.md` (ORCH-011),
+глобальный ADR `adr-0042`, work-item ADR `06-adr/ADR-001`. Машинно-проверяемые факты витрины и
+запрет хост-хардкодов — зелёные (`tests/test_system_docs.py`, `tests/test_no_host_hardcodes.py`).
+Пунктов `README.md` «Известные ограничения», требующих снятия этим PR, не затронуто. Расхождений
+документации с кодом не выявлено.

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

@@ -0,0 +1,91 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-110
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-110
+---
+
+# Test Report — ORCH-110
+
+Багфикс инцидента ORCH-109/PR#129: локальный re-test merge-gate падал по **таймауту** (инфра/CPU-
+голодание от осиротевших pytest-процессов) при зелёных CI+tester+staging → ложно маршрутизировался
+как код-фейл (откат `deploy-staging → development` + расход developer-retry) → manual-gate. Прогон
+регресса подтверждает: инфра-таймаут толерируется (D1…D6), tree-kill устраняет утечку, красный re-test
+по-прежнему откатывает.
+
+## Окружение
+- 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-110-bug-merge-gate-local-re-test-t`
+- Branch: `feature/ORCH-110-bug-merge-gate-local-re-test-t` (HEAD `5391c8b`; fix-коммит `b80edf3`)
+- Дата: 2026-06-15
+
+## Smoke API (read-only)
+| Эндпоинт | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok","service":"orchestrator"}` — OK |
+| `GET /status` | OK; задача ORCH-110 (id=100) на стадии `testing`, `agent_running=null` |
+| `GET /queue` | OK; блок `serial_gate` присутствует ✓ (наряду с `auto_labels` ✓); полезная нагрузка не деградировала |
+
+> Прим.: блок `merge_gate` (новая наблюдаемость ORCH-110, FR-6) в проде (8500) ещё отсутствует — это
+> ожидаемо, фича не задеплоена (задача на стадии `testing`). В коде ветки блок присутствует и покрыт
+> тестом TC-12 (`test_tc12_queue_endpoint_includes_merge_gate_block`). Регресса смока нет.
+
+## Результаты (покрытие ТЗ: каждый TC из 04-test-plan.yaml ↔ 03-acceptance-criteria.md)
+
+| TC ID | Описание | AC | Модуль | Результат |
+|-------|----------|----|--------|-----------|
+| TC-01 | `retest_branch`: таймаут → `(False, 're-test timeout after <T>s')` + tree-kill всего дерева (внуки не переживают) | AC-4 (BR-3) | test_orch110_retest_lifecycle.py | PASS |
+| TC-02 | `coverage_gate.measure_coverage`: таймаут → tree-kill дерева; возврат `None` сохранён | AC-4 (BR-3) | test_orch110_retest_lifecycle.py | PASS |
+| TC-03 | `classify_retest_failure`: `timeout` различим от `red`/`lock-busy`/`other` (имя/семантика `check_*` целы) | AC-2 | test_orch110_merge_gate_classify.py | PASS |
+| TC-04 | Маршрутизация: инфра-таймаут → defer/повтор/инфра-alert (НЕ `_handle_merge_gate_rollback`, без developer-retry) | AC-1 | test_orch110_merge_gate_routing.py | PASS |
+| TC-05 | Анти-над-толерантность: красный/конфликт re-test → откат на `development` + developer-retry + release lease (BR-6) | AC-3 | test_orch110_merge_gate_routing.py | PASS |
+| TC-06 | Anti-loop: повторы лимитированы по попыткам/времени; исчерпание → один инфра-alert | AC-9 | test_orch110_merge_gate_routing.py | PASS |
+| TC-07 | Kill-switch off → байт-в-байт прежнее (таймаут → rollback); not-self repo (enduro) → no-op | AC-7 | test_orch110_killswitch.py | PASS |
+| TC-08 | Бюджет: malformed/непозитив → дефолт 900 + WARNING; `reaper_max_running_s (5400) > Σ+grace`; `reaper_max_running_s` не тронут | AC-5 | test_orch110_budget_invariants.py | PASS |
+| TC-09 | never-raise: ошибка транзиент-пути → безопасный дефолт + WARNING; исключение не уходит в `advance_stage` | AC-8 | test_orch110_merge_gate_routing.py | PASS |
+| TC-10 | РЕГРЕСС инцидента: no-op rebase → skip+advance; catch-up timeout → infra-retry (НЕ rollback); красный → rollback (red-before/green-after) | AC-10 | test_orch110_false_rollback_regression.py | PASS |
+| TC-11 | Контракт необходимости re-test: no-op rebase → skip (lease HELD); HEAD сдвинулся / неопределённость SHA → re-test (fail-safe) | AC-6 | test_orch110_retest_contract.py | PASS |
+| TC-12 | Наблюдаемость: счётчики + блок `merge_gate` в `GET /queue`; инфра-alert кликабелен и отличим от код-фейла; без дубля ORCH-111 | AC-9 (FR-6) | test_orch110_observability.py | PASS |
+
+Все 12 TC выполнены и сопоставлены с критериями приёмки AC-1…AC-10. FAIL/непокрытых TC нет.
+
+## Вывод pytest
+
+### ORCH-110-специфичные модули (verbose)
+```
+collected 55 items
+tests/test_orch110_retest_lifecycle.py ........  (TC-01, TC-02)
+tests/test_orch110_merge_gate_classify.py ........  (TC-03)
+tests/test_orch110_merge_gate_routing.py ........  (TC-04, TC-05, TC-06, TC-09)
+tests/test_orch110_killswitch.py ....  (TC-07)
+tests/test_orch110_budget_invariants.py .........  (TC-08)
+tests/test_orch110_false_rollback_regression.py ...  (TC-10)
+tests/test_orch110_retest_contract.py ......  (TC-11)
+tests/test_orch110_observability.py .....  (TC-12)
+======================== 55 passed, 1 warning in 15.17s ========================
+```
+
+### Полный регресс
+```
+$ cd /repos/_wt/orchestrator/feature_ORCH-110-bug-merge-gate-local-re-test-t && python3 -m pytest tests/ -q --tb=short
+........................................................................ [100%]
+1988 passed, 1 warning in 346.71s (0:05:46)
+```
+(Единственное warning — `PydanticDeprecatedSince20` в `src/config.py:8`, предсуществующее, не связано
+с ORCH-110.)
+
+## Итог
+PASS
+
+- Полный регресс `pytest tests/` — **1988 passed** (0 failed).
+- Все 12 TC из `04-test-plan.yaml` выполнены, сопоставлены с `03-acceptance-criteria.md` (AC-1…AC-10) — **PASS**.
+- Smoke API read-only (`/health`, `/status`, `/queue`) — OK; блоки `serial_gate` и `auto_labels` присутствуют.
+- Review-вердикт — `APPROVED`.
+
+**Вердикт: `result: PASS`** → задача переходит на `deploy-staging`.

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

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

@@ -0,0 +1,32 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-110
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T07:40:28Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment (port 8501).
+
+**Execution:** canonical run INSIDE `orchestrator-staging` via the Docker Engine API
+exec endpoint (ORCH-048/ADR-001):
+`python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`.
+
+**Result:** 8/10 checks PASS, exit code **0** → advance.
+
+- REAL checks (A1–A3 SMOKE, B4–B6 ACCESS, C7–C8 E2E): all green.
+  - B6 registry-isolation: `sandbox=YES, prod-ET=NO, prod-ORCH=NO` (instance built registry
+    from its own `.env.staging` process-env — correct canonical-run behaviour).
+- SANDBOX_INFRA checks (C9a/C9b): FAIL, **waived** under ORCH-061 infra-tolerance
+  (known sandbox-infra; depend on SANDBOX bot accounts being project members, not on the
+  pipeline). All REAL checks green → exit 0.
+
+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) — infra-waived: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green.

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: watchdog must alert on long-lived pytest/child processes that block the pipeline
+
+Work Item ID: ORCH-111
+
+## Description
+
+TBD

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

@@ -0,0 +1,145 @@
+---
+work_item: ORCH-111
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 01 — BRD (бизнес-требования): ORCH-111 — watchdog должен алертить на долго живущие pytest/дочерние процессы, блокирующие конвейер
+
+Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в полный цикл**
+
+> **Эскалация (`escalate: full-cycle`).** Задача пришла как баг (`BUG:` в заголовке), но **не**
+> является дешёвым багфиксом: закрытие пробела требует **архитектурного решения** — у sidecar-watchdog
+> сейчас **нет видимости процессов хоста вообще** (`network_mode: host`, но без `pid: host` и без
+> bind-mount `/proc`). Выбор механизма наблюдения (расширение привилегий sidecar vs обогащение
+> контракта `/metrics` орком) — это развилка с последствиями для безопасности и стабильного контракта
+> `/metrics` (schema_version, ORCH-099). Поэтому пакет — **полный** (а не lite-bug), и задача
+> помечена `escalate: full-cycle`: нужен прогон стадии `architecture` + ADR (механизм видимости,
+> эвристика детекции, привилегии/безопасность). Оператор снимает багфикс-трек эндпоинтом
+> `POST /bug-fast-track/escalate?work_item=ORCH-111` (ADR-001 D5, ORCH-019).
+
+## 1. Бизнес-контекст и проблема
+
+### 1.1 Симптом (установленный факт)
+На хосте прода были обнаружены старые зависшие процессы `python3 -m pytest tests/test_install_lite_script.py`,
+которые жили **более 2 суток**, грузили CPU и мешали локальному merge-gate re-test. Из-за конкуренции
+за CPU задача **ORCH-109 несколько раз упиралась** в `re-test timeout after 600s`
+(`merge_gate.retest_branch`). Сами эти процессы **не были подняты как отдельный alert** watchdog'а —
+оператор узнал о них случайно.
+
+### 1.2 Локализация
+- **Мониторинг-мозг** — sidecar-watchdog (ORCH-100, каталог `watchdog/`, сервис `orchestrator-watchdog`).
+  Он уже алертит на `stage_stuck` (стадия задачи застряла) и `container_down` (контейнер не в норме),
+  а также `agent_hung`, `orch_down`, `host_mem`, `queue_depth`, `job_failed`, `dep_down`.
+- **Сигнал `agent_hung`** (`watchdog/signals.py::eval_envelope`) покрывает **только running-агент-джобы**:
+  он читает раздел `agents[]` из `GET /metrics`, а тот строится `src/metrics.py::_build_agents` по
+  `db.get_running_agents()` — то есть **только по `jobs.pid` активных джобов**.
+- **Источник зависших процессов** — субпроцессы pytest, которые орк запускает в worktree:
+  `merge_gate.retest_branch` (`python -m pytest <target>`) и `coverage_gate.measure_coverage`
+  (`pytest --cov=src`). При `subprocess.TimeoutExpired` Python убивает прямого ребёнка, но
+  **внуки/репарентированные процессы переживают**; а если сам агент-процесс убит по таймауту
+  (`exit_code=-9`, ORCH-109) — его дочерний pytest **репарентируется на PID 1** и продолжает жить.
+
+### 1.3 Причина (root cause)
+Между двумя наблюдателями зияет **слепая зона**: `agent_hung` видит лишь *отслеживаемые* агент-джобы
+(по `jobs.pid`), а **осиротевшие/внебюджетные тестовые субпроцессы** (внуки pytest, репарентированные
+на PID 1) **не присутствуют ни в `/metrics`, ни в поле зрения sidecar** — у контейнера watchdog нет
+доступа к таблице процессов хоста. Поэтому долго живущий pytest, реально блокирующий конвейер через
+CPU-голодание merge-gate, **не порождает ни одного сигнала**, пока формально ни одна стадия задачи не
+«застряла».
+
+## 2. Объём (scope)
+
+### В объёме
+- Новый **отдельный класс алерта** watchdog'а: «долго живущий тестовый/дочерний процесс блокирует
+  конвейер» — поднимается, даже если стадия задачи формально не `stuck`.
+- Детекция долго живущих процессов тест-класса (pytest и родственные субпроцессы гейтов), переживших
+  свой бюджет/осиротевших, на хосте прода.
+- Актуализация конфиг-канона watchdog (`.env.watchdog.example` / блок `WATCHDOG_*` в `.env.example`)
+  и наблюдаемости.
+
+### Вне объёма
+- **Любая реакция на процесс** (kill/SIGTERM/cleanup/reap/перезапуск). Задача — **только мониторинг +
+  сигнализация** (явное ограничение заказчика). Автоматический reap осиротевших процессов — **отдельная
+  задача**.
+- Изменение конвейера: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict / схема БД — **не
+  трогаются** (watchdog — наблюдатель вне процесса орка и вне Quality Gates).
+- Расширение `agent_hung` на нетреканые процессы (это другой класс сигнала; дубль запрещён — см. NFR-4).
+- Снятие первопричины осиротения процессов в самом орке (надёжный reap внуков pytest) — ценно, но это
+  **ремедиация**, она вне объёма этой задачи.
+
+## 3. Заинтересованные стороны
+- **Заказчик/оператор прода** (Слава) — получает ранний сигнал о CPU-голодании ещё до того, как оно
+  завалит merge-gate re-test очередной задачи.
+- **Self-hosting конвейер orchestrator** — страдает напрямую (инцидент ORCH-109).
+- **Тиражные инсталляции (Lite/Bundled, ORCH-102/103)** — sidecar входит в дефолтный комплект; новый
+  сигнал должен укладываться в канон конфига и не ломать тираж.
+- **Принимает результат** — reviewer/tester + оператор (smoke на staging-эквиваленте sidecar).
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Watchdog поднимает **отдельный, узнаваемый** alert, когда на хосте обнаружен долго живущий
+  процесс тест-класса (pytest и его субпроцессы), возраст которого превышает настраиваемый порог —
+  **независимо** от того, застряла ли формально какая-либо стадия задачи.
+- **BR-2** — Текст алерта **действенно идентифицирует** виновника: фрагмент командной строки, PID,
+  возраст процесса и (при наличии) доля CPU — чтобы оператор мог сразу разобраться и вручную вмешаться.
+- **BR-3** — **Только мониторинг + сигнализация.** Watchdog **не убивает / не останавливает / не шлёт
+  сигналы** процессу и не выполняет иную ремедиацию (жёсткое ограничение заказчика, рамка C-1
+  «наблюдатель строго read-only к наблюдаемому», ORCH-100).
+- **BR-4** — **Без ложных срабатываний** на легитимных in-flight прогонах: тестовый процесс,
+  принадлежащий **активному отслеживаемому** агенту/гейту в пределах его бюджета, alert поднимать
+  **не должен**.
+- **BR-5** — Анти-спам и recovery как у прочих сигналов: один alert на пересечение порога, throttled
+  re-alert по cooldown, однократный recovery при исчезновении процесса (переиспользовать
+  `watchdog/decision.py::decide` + `AlertState`).
+- **BR-6** — Сигнал под **kill-switch** и управляется конфигом (порог возраста, cooldown, область).
+  Дефолт выбирается так, чтобы включение было **осознанным** и **self-hosting-безопасным** (см. NFR-3).
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (надёжность)** — **never-raise** на всех новых путях (per-source / per-tick / per-send), как
+  и весь watchdog: сбой коллектора процессов деградирует ОДИН сигнал, а не роняет тик.
+- **NFR-2 (read-only)** — строго наблюдение: **ни одного** управляющего действия над процессами/хостом
+  (нет `kill`/`signal`/`Popen`/записи). Соответствует C-1 (observer separated from observed).
+- **NFR-3 (self-hosting безопасность)** — выкат изменения **не перезапускает** прод-контейнер
+  `orchestrator` (встанет конвейер всех проектов): пересобирается/рестартится **только** контейнер
+  `orchestrator-watchdog`. Если механизм требует расширения привилегий sidecar (напр. `pid: host`) —
+  это привилегия **только наблюдателя**, обоснование и риски — задача архитектора (ADR).
+- **NFR-4 (без дубля)** — новый сигнал **не пересекается** с `agent_hung` (тот уже покрывает
+  отслеживаемые агент-джобы): новый сигнал закрывает ровно пробел «нетреканый/осиротевший процесс».
+- **NFR-5 (канон тиража)** — при изменении compose / ключей `.env.watchdog` обновить в **том же PR**:
+  `.env.watchdog.example`, блок `WATCHDOG_*` в `.env.example`, `docs/deployment/LITE_SETUP.md` и
+  `docs/architecture/README.md` (норматив сопровождения ORCH-102 NFR-5; key-set-sync тест).
+- **NFR-6 (стек)** — sidecar остаётся **stdlib-only** (C-3, ORCH-100): без новых сторонних зависимостей.
+
+## 6. Допущения и ограничения
+- **Ключевое архитектурное допущение (для архитектора):** у контейнера `orchestrator-watchdog` сейчас
+  **нет** видимости процессов хоста (`network_mode: host`, но без `pid: host` и без mount `/proc`).
+  Закрытие пробела требует выбора механизма — **развилка, решаемая ADR**, не аналитиком. Кандидаты
+  (перечислены как материал для решения, **без навязывания**): (a) расширение привилегий sidecar —
+  `pid: host` либо read-only mount хостового `/proc`, затем stdlib-скан таблицы процессов; (b)
+  обогащение `/metrics` орком новым read-only разделом о «бесхозных» тест-субпроцессах (орк видит свой
+  PID-namespace), который sidecar лишь читает. У каждого — свои trade-off'ы (привилегии vs контракт
+  `/metrics`).
+- `/metrics` — **версионированный контракт** (`schema_version`, ORCH-099): если выбран путь (b),
+  аддитивные изменения **не бампят** версию (sidecar обязан толерировать).
+- Порог возраста для детекции **должен превышать** максимальный легитимный бюджет тест-прогона
+  (`merge_retest_timeout_s` ≈ 600s, `coverage_run_timeout_s`), чтобы нормальный прогон **никогда** не
+  алертил, а 2-суточный осиротевший pytest — гарантированно (анти-false-positive, материал для ADR).
+- enduro-trails не затронут: watchdog наблюдает хост/орк self-hosting; сигнал config-gated.
+
+## 7. Критерии успеха
+Watchdog при наличии долго живущего pytest/дочернего процесса, грузящего CPU, **поднимает отдельный
+alert** в свой Telegram-канал (с PID/cmd/возрастом), **не трогая** процесс; при отсутствии такого
+процесса (или выключенном флаге) — молчит; нормальный тест-прогон под активным джобом **не** триггерит
+ложный alert. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Ложные срабатывания** на легитимном длинном прогоне → спам в канал (митигируется порогом >
+  макс. бюджета + корреляцией с активным джобом).
+- **Расширение привилегий sidecar** (если выбран `pid: host`/`/proc`-mount) → увеличение поверхности
+  безопасности наблюдателя (требует явного обоснования в ADR; дефолт-off).
+- **Дубль с `agent_hung`** при небрежной реализации (NFR-4).
+- Детали и владельцы рисков — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,122 @@
+---
+work_item: ORCH-111
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-111 — alert на долго живущие pytest/дочерние процессы в watchdog
+
+Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения — задача архитектора (06-adr). В частности, **выбор механизма
+> видимости процессов хоста** (см. §2 «развилка») — за ADR; ниже зафиксированы **требования и
+> ограничения**, а не способ реализации.
+
+## 1. Сводка изменения
+Добавить в sidecar-watchdog (`watchdog/`) **новый сигнал** класса «долго живущий блокирующий
+тест/дочерний процесс» (рабочее имя ключа — `proc_blocking`; финальное имя утверждает разработчик/ADR).
+Сигнал активен, когда на хосте есть процесс тест-класса (pytest и его субпроцессы), чей возраст
+превысил настраиваемый порог и который **не атрибутируется активному отслеживаемому джобу**. Сигнал
+проходит через **существующую** машину `decide()`/`AlertState` (анти-спам/recovery) и публикуется в
+собственный Telegram-канал sidecar. Watchdog при этом **не трогает** процесс (BR-3/NFR-2). Это
+изменение **внутри наблюдателя**: машина стадий орка и Quality Gates не затрагиваются.
+
+## 2. Задействованные модули / пути
+
+> **Развилка механизма (решает архитектор, ADR).** Часть путей **условна** и зависит от выбранного
+> механизма видимости процессов. Ниже помечено явно.
+
+| Путь | Действие |
+|------|----------|
+| `watchdog/signals.py` | изменить — чистый builder нового сигнала `proc_blocking` (по образцу `host_signals`/`container_signals`) |
+| `watchdog/config.py` | изменить — новые ключи `WATCHDOG_PROC_*` (enable/порог возраста/паттерны/cooldown); never-raise парсеры |
+| `watchdog/core.py` | изменить — врезка коллектора процессов + диспетч нового сигнала в `tick()` (per-source guard) |
+| `watchdog/collectors/proc.py` | **создать** — коллектор списка процессов-кандидатов (механизм — по ADR); never-raise → `[]` |
+| `.env.watchdog.example` | изменить — задокументировать новые `WATCHDOG_PROC_*` ключи (канон) |
+| `.env.example` (блок `WATCHDOG_*`) | изменить — key-set-sync с `.env.watchdog.example` (тест `test_lite_setup_doc`/key-sync) |
+| `tests/watchdog/test_proc_blocking_signal.py` | **создать** — unit + регресс на новый сигнал |
+| `tests/watchdog/test_tick_proc_blocking_integration.py` | **создать** — интеграция tick→dispatch |
+| `docs/architecture/README.md`, `docs/deployment/LITE_SETUP.md` | изменить — описать сигнал/ключи (NFR-5) |
+| `docker-compose.yml` (сервис `orchestrator-watchdog`) | **условно** изменить — привилегия/mount (`pid: host` или `/proc:ro`) **только если** ADR выберет watchdog-side host-скан |
+| `src/metrics.py` (`_build_*`, аддитивный раздел) | **условно** изменить — **только если** ADR выберет orch-side обогащение `/metrics`; **аддитивно**, без бампа `schema_version` |
+
+## 3. Функциональные требования
+
+### FR-1 — Новый сигнал `proc_blocking` (чистый builder)
+В `watchdog/signals.py` добавить чистую функцию-builder (без I/O), которая по списку записей о
+процессах-кандидатах и конфигу возвращает `Signal`-объекты:
+- **Ключ** — per-entity, со **стабильной идентичностью** процесса (напр. `("proc_blocking", pid)` или
+  хеш `cmdline`), чтобы `AlertState`/cooldown работали по каждому процессу отдельно (как
+  `("container_down", name)`).
+- **active=True** ⇔ возраст процесса `> cfg.proc_age_s` **И** командная строка матчит класс
+  «тест/дочерний» (паттерн pytest и родственные, конфигурируемо) **И** процесс **не** принадлежит
+  активному отслеживаемому джобу (анти-false-positive, BR-4).
+- **title/detail** — действенные: фрагмент cmdline, PID, возраст (сек), доля/время CPU при наличии
+  (BR-2). Текст на русском, в стиле существующих сигналов.
+- Привязка: **BR-1, BR-2, BR-4**.
+
+### FR-2 — Коллектор процессов-кандидатов
+Создать `watchdog/collectors/proc.py` — собирает «сырьё» (список записей `{pid, cmdline, age_s,
+cpu?}`) тем механизмом, который утвердит ADR. Контракт коллектора **фиксирован независимо от
+механизма**: **stdlib-only** (NFR-6), **read-only** (NFR-2), **never-raise** → при любой ошибке/
+недоступности источника возвращает `[]` (один сигнал пропущен, тик жив). Привязка: **NFR-1, NFR-2,
+NFR-6**.
+
+### FR-3 — Конфиг + kill-switch
+В `watchdog/config.py` добавить ключи (имена финализирует разработчик/ADR; предложение):
+`WATCHDOG_PROC_ENABLED` (kill-switch), `WATCHDOG_PROC_AGE_MIN` (порог возраста в минутах; дефолт
+**должен превышать** макс. легитимный бюджет тест-прогона — см. §7), `WATCHDOG_PROC_PATTERNS`
+(CSV паттернов cmdline, дефолт включает `pytest`), при необходимости отдельный
+`WATCHDOG_PROC_COOLDOWN_S`. Все парсеры never-raise с безопасными дефолтами (как существующие
+`_int`/`_bool`/`_csv`). Выключенный флаг → коллектор/сигнал инертны (нулевой эффект). Привязка:
+**BR-6, NFR-1**.
+
+### FR-4 — Инвариант «только наблюдение»
+На всём новом пути запрещены `os.kill`, отправка сигналов, `subprocess.Popen`/`run`, любые мутации
+процессов/ФС/БД. Watchdog **только читает и уведомляет**. Привязка: **BR-3, NFR-2**.
+
+### FR-5 — Диспетч через существующую машину решения
+Новый сигнал диспетчеризуется в `core.tick()` через тот же путь `decision.decide(...)` +
+`self._states[key]` + `self._send(...)`: ALERT на пересечении порога, REALERT по cooldown, RECOVERY
+при исчезновении процесса. Никакой отдельной логики анти-спама не вводить. Привязка: **BR-5**.
+
+### FR-6 — Без дубля с `agent_hung`
+Новый сигнал покрывает **только** процессы, **не** представленные в `/metrics agents[]` (нетреканые/
+осиротевшие). Атрибуция «процесс принадлежит активному джобу» исключает такие процессы из
+`proc_blocking` (предотвращает двойной алерт и ложные срабатывания на живом агенте). Привязка:
+**NFR-4, BR-4**.
+
+## 4. Изменения API
+- **Орк HTTP API:** новых эндпоинтов **не требуется**. **Условно** (если ADR выберет orch-side путь):
+  **аддитивный** раздел в ответе `GET /metrics` (`src/metrics.py`) о бесхозных тест-субпроцессах —
+  строго read-only, **без бампа** `schema_version` (ORCH-099 NFR-6), sidecar толерирует отсутствие.
+- **Watchdog:** внутренний сигнал, внешнего API не имеет.
+
+## 5. Изменения схемы БД
+Нет.
+
+## 6. Требования к новым/изменённым QG checks
+Нет. Watchdog — наблюдатель **вне** конвейера и вне Quality Gates: `QG_CHECKS` / `check_*` /
+machine-verdict ключи / `STAGE_TRANSITIONS` — **байт-в-байт не трогаются** (как `disk_watchdog`/
+`reaper`/`reconciler`).
+
+## 7. Совместимость / регресс
+- **Kill-switch + дефолты:** при выключенном `WATCHDOG_PROC_ENABLED` (или при дефолте, выбранном
+  безопасно) — **нулевая регрессия**: ни одного нового алерта, тик 1:1 как до ORCH-111. Дефолтный
+  порог возраста **обязан превышать** максимальный легитимный бюджет тест-прогона
+  (`merge_retest_timeout_s` ≈ 600s, `coverage_run_timeout_s`) — иначе нормальный прогон даст ложный
+  alert (анти-false-positive, BR-4).
+- **never-raise / read-only:** новый код не может уронить тик и не выполняет управляющих действий
+  (NFR-1/NFR-2).
+- **Контракт `/metrics`:** при orch-side варианте — только аддитивно, без бампа версии; при
+  watchdog-side варианте — `/metrics` не трогается вовсе.
+- **Self-hosting (NFR-3):** выкат — пересборка/рестарт **только** `orchestrator-watchdog`; прод
+  `orchestrator` **не** перезапускается. Если механизм требует привилегии/mount в compose — это правка
+  **только** сервиса watchdog.
+- **Канон тиража (NFR-5):** новые ключи синхронизировать в `.env.watchdog.example` ↔ блок `WATCHDOG_*`
+  в `.env.example` и описать в `LITE_SETUP.md` в том же PR (key-set-sync тест должен остаться зелёным).
+- **Область:** сигнал config-gated; enduro-trails не затронут.

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

@@ -0,0 +1,129 @@
+---
+work_item: ORCH-111
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-111 — alert на долго живущие pytest/дочерние процессы
+
+Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
+провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
+
+---
+
+## AC-1 — Алерт на долго живущий блокирующий процесс
+
+**Условие:** на хосте есть процесс тест-класса (pytest/субпроцесс гейта), чей возраст превысил
+настроенный порог и который не атрибутирован активному отслеживаемому джобу.
+- **PASS:** watchdog поднимает **отдельный** сигнал (рабочий ключ `proc_blocking`) → ALERT в свой
+  Telegram-канал; алерт срабатывает **даже если** ни одна стадия задачи формально не `stuck`.
+- **FAIL:** такой процесс присутствует, но ни одного нового алерта не поднято (поведение до ORCH-111).
+
+---
+
+## AC-2 — Действенный текст алерта
+
+**Условие:** алерт `proc_blocking` сформирован.
+- **PASS:** `detail` содержит фрагмент cmdline (видно, что это pytest/тест-процесс), PID, возраст
+  процесса в секундах и (при наличии) долю/время CPU.
+- **FAIL:** алерт без идентификации процесса (нельзя понять, какой PID/команду проверять).
+
+---
+
+## AC-3 — Только наблюдение, без ремедиации
+
+**Условие:** обнаружен блокирующий процесс.
+- **PASS:** на всём новом пути нет `os.kill`/отправки сигналов/`subprocess.Popen|run`/иных мутаций;
+  watchdog **только** алертит, процесс остаётся жив (его судьба — на операторе).
+- **FAIL:** код пытается убить/остановить/просигналить процесс или иначе ремедиировать.
+
+---
+
+## AC-4 — Без ложных срабатываний на легитимном прогоне
+
+**Условие:** на хосте идёт нормальный тест-прогон (merge-gate re-test / coverage) под активным
+отслеживаемым джобом, в пределах своего бюджета.
+- **PASS:** `proc_blocking` **не** активен для такого процесса (возраст ниже порога **или** процесс
+  атрибутирован активному джобу) → алерта нет.
+- **FAIL:** легитимный прогон под активным джобом триггерит ложный `proc_blocking`-alert.
+
+---
+
+## AC-5 — Без дубля с `agent_hung`
+
+**Условие:** процесс уже представлен в `/metrics agents[]` (отслеживаемый running-агент).
+- **PASS:** для него работает только существующий `agent_hung`; `proc_blocking` его **не** дублирует
+  (ровно один класс алерта на один процесс).
+- **FAIL:** один и тот же процесс порождает и `agent_hung`, и `proc_blocking` (двойной алерт).
+
+---
+
+## AC-6 — Анти-спам и recovery
+
+**Условие:** блокирующий процесс держится несколько тиков, затем исчезает.
+- **PASS:** один ALERT при пересечении порога; в пределах cooldown — `NONE` (не спамит); REALERT
+  по истечении cooldown; **однократный** RECOVERY при исчезновении процесса (через
+  `decision.decide`/`AlertState`).
+- **FAIL:** алерт на каждом тике (спам) либо отсутствует recovery.
+
+---
+
+## AC-7 — Kill-switch и нулевая регрессия
+
+**Условие:** `WATCHDOG_PROC_ENABLED` выключен (или дефолт-off).
+- **PASS:** коллектор/сигнал инертны; набор и поведение тика **байт-в-байт** как до ORCH-111; полный
+  `pytest tests/` зелёный; watchdog-тесты зелёные.
+- **FAIL:** при выключенном флаге появляется новый алерт/сетевой оверхед, либо падают существующие
+  тесты/тик.
+
+---
+
+## AC-8 — never-raise / read-only
+
+**Условие:** коллектор процессов получает битый/пустой/недоступный источник.
+- **PASS:** коллектор деградирует в `[]` (один сигнал пропущен), тик завершается штатно; ни одной
+  записи/мутации/управляющего действия над процессами/ФС/БД; sidecar остаётся stdlib-only.
+- **FAIL:** исключение роняет тик, либо появляется новая сторонняя зависимость, либо мутирующая
+  операция.
+
+---
+
+## AC-9 — Конвейер и контракты не тронуты
+
+**Условие:** изменение влито.
+- **PASS:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД —
+  без изменений; правка `/metrics` (если выбрана) — **аддитивна**, `schema_version` не бампнут;
+  выкат не требует рестарта прод-контейнера `orchestrator`.
+- **FAIL:** затронут любой из перечисленных контрактов или бампнут `schema_version` без ломающего
+  изменения, либо выкат требует рестарта прод-орка.
+
+---
+
+## AC-10 — Канон конфига/тиража синхронизирован
+
+**Условие:** добавлены ключи `WATCHDOG_PROC_*` / изменён compose.
+- **PASS:** ключи присутствуют и согласованы в `.env.watchdog.example` ↔ блоке `WATCHDOG_*`
+  `.env.example`; описаны в `LITE_SETUP.md` и `docs/architecture/README.md` в том же PR; key-set-sync
+  тест зелёный.
+- **FAIL:** ключи добавлены только в код, канон/доки тиража не обновлены (дрейф).
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1, FR-2, FR-5 |
+| AC-2 | BR-2 / FR-1 |
+| AC-3 | BR-3 / FR-4 / NFR-2 |
+| AC-4 | BR-4 / FR-1, FR-6 |
+| AC-5 | NFR-4 / FR-6 |
+| AC-6 | BR-5 / FR-5 |
+| AC-7 | BR-6 / FR-3 / §7 |
+| AC-8 | NFR-1, NFR-2, NFR-6 / FR-2 |
+| AC-9 | §6 / NFR-3 / §4 |
+| AC-10 | NFR-5 / §7 |

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

@@ -0,0 +1,102 @@
+work_item: ORCH-111
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+title: "Watchdog alert на долго живущие pytest/дочерние процессы, блокирующие конвейер"
+framework: pytest
+scope: >
+  Покрывает новый сигнал watchdog `proc_blocking`: чистый builder, конфиг/kill-switch,
+  never-raise/read-only коллектор, анти-спам/recovery, отсутствие дубля с agent_hung и
+  диспетч в tick(). Вне покрытия: автоматический reap/kill процессов (ремедиация — вне
+  объёма задачи) и любые изменения конвейера/Quality Gates.
+notes: >
+  Эталон тестируемости — чистые функции `watchdog/signals.py` + `watchdog/decision.py`
+  (тесты без контейнера/сокета/таймера, см. tests/watchdog/test_decision.py,
+  test_host_collector.py). TC-01 и TC-07 — ОБЯЗАТЕЛЬНЫЙ регресс-тест бага: красный до
+  фикса (сигнал/диспетч отсутствуют → нет алерта на долго живущий процесс), зелёный
+  после. Точная форма теста КОЛЛЕКТОРА (host-scan vs orch-/metrics enrichment) зависит
+  от механизма, утверждаемого архитектором (ADR); детерминированные TC ниже якорятся на
+  чистом сигнале + decision-поверхности и не зависят от выбора механизма. Полный регресс
+  `pytest tests/` обязан оставаться зелёным.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: >
+      РЕГРЕСС (красный→зелёный): builder сигнала по записи о процессе с возрастом >
+      порога и cmdline класса pytest, не принадлежащему активному джобу, возвращает
+      активный Signal с ключом `proc_blocking`. До фикса — алерт отсутствует.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      Анти-false-positive: процесс с возрастом НИЖЕ порога ИЛИ атрибутированный активному
+      отслеживаемому джобу → сигнал НЕ активен (нет алерта). Покрывает BR-4.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      Конфиг/kill-switch: `WATCHDOG_PROC_*` парсятся с безопасными дефолтами; дефолтный
+      порог возраста превышает merge_retest_timeout_s; выключенный `WATCHDOG_PROC_ENABLED`
+      делает коллектор/сигнал инертными (нулевая регрессия). Покрывает BR-6/FR-3/AC-7.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      never-raise/read-only коллектора: битый/пустой/недоступный источник → `[]` (один
+      сигнал пропущен), без исключения; на пути нет os.kill/signal/subprocess/мутаций.
+      Покрывает NFR-1/NFR-2/AC-3/AC-8.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      Анти-спам/recovery через decision.decide+AlertState: ALERT при пересечении порога,
+      NONE в пределах cooldown, REALERT по истечении, однократный RECOVERY при исчезновении
+      процесса. Покрывает BR-5/AC-6.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Без дубля с agent_hung: процесс, присутствующий в /metrics agents[], не порождает
+      `proc_blocking` (исключён атрибуцией к активному джобу). Покрывает NFR-4/FR-6/AC-5.
+    module: tests/watchdog/test_proc_blocking_signal.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: >
+      РЕГРЕСС tick→dispatch: Watchdog.tick() с инъектированным коллектором, отдающим долго
+      живущий блокирующий процесс, диспетчеризует `proc_blocking`-алерт через fake-Notifier;
+      при выключенном флаге алерт не отправляется. Покрывает BR-1/FR-5/AC-1/AC-7.
+    module: tests/watchdog/test_tick_proc_blocking_integration.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: >
+      Конфиг-канон/тираж: key-set `.env.watchdog.example` ↔ блок WATCHDOG_* в `.env.example`
+      синхронизирован после добавления `WATCHDOG_PROC_*` (key-sync/LITE_SETUP тест зелёный).
+      Покрывает NFR-5/AC-10.
+    module: tests/watchdog/test_config_killswitch.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: >
+      Полный регресс: `pytest tests/` зелёный; конвейер/Quality Gates не затронуты
+      (STAGE_TRANSITIONS/QG_CHECKS/схема БД без изменений); при orch-side варианте
+      schema_version /metrics не бампнут. Покрывает AC-9.
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md

@@ -0,0 +1,245 @@
+---
+work_item: ORCH-111
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Watchdog-сигнал `proc_blocking` — алерт на долго живущий блокирующий тест-процесс
+
+Work Item: **ORCH-111** — watchdog должен алертить на долго живущие pytest/дочерние процессы, блокирующие конвейер
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md`** (кросс-каттинг: новый компонентный сигнал sidecar + изменение топологии контейнера-наблюдателя).
+
+## Статус
+Proposed
+
+## Контекст
+
+**Установленный инцидент (BRD §1).** На прод-хосте жили >2 суток осиротевшие процессы
+`python3 -m pytest tests/test_install_lite_script.py`, грузили CPU и через конкуренцию за CPU
+несколько раз валили локальный merge-gate re-test (`merge_gate.retest_branch` → `re-test timeout
+after 600s`) на ORCH-109. **Ни одного алерта** не поднялось — оператор узнал случайно.
+
+**Слепая зона (сверено по коду).**
+- Sidecar-watchdog (ORCH-100, `watchdog/`, adr-0033) уже алертит `agent_hung`/`stage_stuck`/
+  `container_down`/`orch_down`/`host_mem`/`queue_depth`/`job_failed`/`dep_down`.
+- `agent_hung` (`watchdog/signals.py::eval_envelope`) видит **только** running-агент-джобы: читает
+  `agents[]` из `GET /metrics`, который `src/metrics.py::_build_agents` строит по
+  `db.get_running_agents()` — то есть **только по `jobs.pid`**.
+- Виновные процессы — субпроцессы pytest, которые орк запускает **своим** кодом:
+  `merge_gate.retest_branch` (`subprocess.run(["python","-m","pytest", target, "-q"], …)`,
+  таймаут `settings.merge_retest_timeout_s=600`) и `coverage_gate.measure_coverage`
+  (`pytest --cov=src`, таймаут `settings.coverage_run_timeout_s=900`). При
+  `subprocess.TimeoutExpired` / timeout-kill агента (`exit_code=-9`, ORCH-109) внук-pytest
+  **репарентируется на PID 1** orchestrator-контейнера (tini под `init: true` — жнёт зомби, но
+  **не убивает живых** осиротевших) и продолжает жить.
+- **Контейнер `orchestrator-watchdog` сейчас не видит таблицу процессов хоста вообще**
+  (`docker-compose.yml`: `network_mode: host` + read-only `docker.sock` + `/repos:ro` + `./data:ro`,
+  **без** `pid: host` и **без** mount `/proc`). Между `agent_hung` (видит только треканые джобы по
+  `jobs.pid`) и реальностью (осиротевший pytest вне `/metrics` и вне поля зрения sidecar) зияет дыра:
+  долго живущий pytest, реально блокирующий конвейер через CPU-голодание, **не порождает сигнала**,
+  пока формально ни одна стадия не `stuck`.
+
+**Linux-семантика, на которую опирается решение.** Хост-namespace процессов — предок всех
+контейнерных: из корневого PID-namespace видны **все** процессы всех контейнеров (с хост-глобальными
+PID). Контейнер с `pid: host` присоединяется к этому namespace, и его `/proc` отражает хост → видит
+осиротевший pytest независимо от того, в каком контейнере он формально запущен. Это подтверждает
+факт BRD «обнаружены на хосте» (оператор делал `ps aux` в корневом namespace).
+
+**Почему нужен ADR, а не lite-bug.** Закрытие дыры — развилка с последствиями для безопасности
+(привилегии наблюдателя) и для стабильного контракта `/metrics` (`schema_version`, ORCH-099). Задача
+эскалирована `escalate: full-cycle` (BRD).
+
+## Решение
+
+### Сводка
+Добавить в sidecar-watchdog **новый per-entity сигнал** `proc_blocking`: на каждом тике sidecar
+**сам** сканирует хостовую таблицу процессов (stdlib `/proc`), отбирает процессы тест-класса (cmdline
+матчит паттерн, дефолт `pytest`), и если возраст процесса превысил порог (заведомо больший
+максимального легитимного бюджета тест-прогона) — поднимает алерт через **существующую** машину
+`decision.decide()` / `AlertState` в собственный Telegram-канал sidecar. Watchdog процесс **не
+трогает** (только наблюдение). Механизм видимости — **watchdog-side** (`pid: host` на сервисе
+`orchestrator-watchdog`), а **не** обогащение `/metrics` орком. Изменения — строго внутри наблюдателя
+(`watchdog/**` + сервис watchdog в compose); `src/**` / `/metrics` / `STAGE_TRANSITIONS` / `QG_CHECKS`
+/ `check_*` / machine-verdict / схема БД — **не тронуты**.
+
+### D1 — Механизм видимости: watchdog-side `/proc`-скан под `pid: host` (НЕ orch-side `/metrics`)
+**Решение:** sidecar получает видимость процессов хоста через `pid: host` на сервисе
+`orchestrator-watchdog` и читает `/proc` напрямую (stdlib). Отвергнут orch-side путь (обогащение
+`/metrics` разделом о бесхозных процессах).
+
+Обоснование (по приоритету):
+1. **NFR-3 (self-hosting deploy-инвариант) — решающий.** Orch-side путь правит `src/metrics.py` →
+   требует пересборки/**рестарта прод-контейнера `orchestrator`** → прямо запрещён NFR-3 («выкат
+   пересобирает/рестартит только `orchestrator-watchdog`»). Watchdog-side путь правит только
+   `watchdog/**` + сервис watchdog → удовлетворяет NFR-3.
+2. **Резилентность / покрытие именно дыры.** Осиротевший pytest опаснее всего, когда орк уже
+   деградировал (CPU-голодание) или лёг. Orch-side путь в этот момент **слеп** (`/metrics`
+   недоступен/тормозит → раздел не доставлен), что противоречит самой причине существования sidecar
+   (C-1: наблюдатель переживает падение наблюдаемого). Watchdog-side читает `/proc` независимо от
+   живости орка.
+3. **Изоляция контракта.** Watchdog-side не трогает контракт `/metrics` и `schema_version` (ORCH-099)
+   вовсе.
+
+Привязка: NFR-3, BR-1, C-1.
+
+### D2 — Анти-false-positive и отсутствие дубля с `agent_hung` — **по построению**, без матчинга PID
+Два структурных свойства, не требующих ненадёжного кросс-namespace сопоставления PID (при `pid: host`
+sidecar видит хост-глобальные PID, а `/metrics agents[].pid` — PID в namespace орка; они не совпадают):
+
+- **Скоуп по cmdline.** `proc_blocking` рассматривает **только** процессы, чья cmdline матчит
+  тест-класс (дефолт-паттерн `pytest`). Агент-процессы `claude` (которые покрывает `agent_hung`)
+  **никогда** не матчат `pytest` → нулевое пересечение с `agent_hung` (NFR-4 / AC-5 **по
+  построению**). Сами pytest-субпроцессы орк запускает своим кодом (merge/coverage-гейты), они
+  **никогда** не треканы как джобы → `agent_hung` их и не покрывает. Два сигнала разбивают
+  пространство процессов по cmdline.
+- **Порог возраста > макс. легитимного бюджета.** Легитимный in-flight прогон ограничен
+  `merge_retest_timeout_s=600s` и `coverage_run_timeout_s=900s`. При
+  `WATCHDOG_PROC_AGE_MIN*60 > max(600,900)=900s` легитимный прогон **всегда** ниже порога (BR-4 /
+  AC-4 **по построению**). Это и есть «атрибуция активному джобу» из FR-1/FR-6: процесс в пределах
+  бюджета физически не может перерасти порог. Кросс-namespace матчинг PID не нужен (и ненадёжен) —
+  возраст namespace-агностичен.
+
+**Кросс-инвариант (фиксируется ADR):** дефолтный порог **обязан** превышать максимум
+`max(merge_retest_timeout_s, coverage_run_timeout_s)`. Дефолт `WATCHDOG_PROC_AGE_MIN=60` (мин) =
+3600s — 4× запас над 900s; меняя `merge_retest_timeout_s`/`coverage_run_timeout_s` вверх,
+поднимай порог. Привязка: BR-4, NFR-4, AC-4, AC-5.
+
+### D3 — Коллектор `watchdog/collectors/proc.py` (stdlib `/proc`-скан)
+**Создать** leaf-коллектор по образцу `collectors/host.py`. Контракт **фиксирован** (NFR-1/2/6):
+- **stdlib-only:** читает `/proc/stat` (`btime` — момент загрузки) + `os.sysconf("SC_CLK_TCK")`;
+  итерирует числовые `/proc/<pid>`; `/proc/<pid>/cmdline` (NUL-разделённое → join пробелом) →
+  матч паттерна; `/proc/<pid>/stat` поле 22 (`starttime` в тиках) → `age_s = now - (btime +
+  starttime/clk_tck)`; поля 14+15 (`utime+stime`) → `cpu_s = (utime+stime)/clk_tck` (накопленное
+  CPU-время, **информационно** для BR-2; в активацию НЕ входит).
+- **read-only:** только открытие файлов на чтение. **Запрещены** `os.kill`, отправка сигналов,
+  `subprocess.Popen/run`, любые мутации ФС/процессов. **Никогда не читает `/proc/<pid>/environ`**
+  (там секреты).
+- **never-raise:** per-pid guard (один нечитаемый/исчезнувший `/proc/<pid>` пропускается, не роняя
+  список — гонка «процесс умер между listdir и read» нормальна); top-level guard → `[]`.
+- Выход — список записей `{pid, cmdline, age_s, cpu_s?, start_ticks}`; чистый разбор отделён от I/O
+  (тестируемо на фикстурах `/proc`-текста, без реального хоста).
+
+Привязка: FR-2, NFR-1, NFR-2, NFR-6, AC-8.
+
+### D4 — Чистый builder `proc_signals` + синтез RECOVERY для исчезнувшего процесса
+**Builder** в `watchdog/signals.py` (по образцу `container_signals`/`host_signals`): по списку
+кандидатов и конфигу возвращает `Signal`-объекты.
+- **Ключ** — per-entity `("proc_blocking", pid)` (зеркало `("container_down", name)`).
+- **active=True** ⇔ `age_s > cfg.proc_age_s` (cmdline уже отфильтрована коллектором по паттерну).
+- **title/detail** — действенные (RU, в стиле существующих): фрагмент cmdline + PID + возраст (сек) +
+  (при наличии) CPU-время (BR-2). Cmdline-фрагмент **усечь** до ограниченной длины (анти-утечка
+  случайных аргументов в канал; см. риск R-2).
+
+**RECOVERY для исчезнувшего процесса (новый аспект, AC-6).** `container_down` авто-recovery'ится
+лишь потому, что набор имён статичен (Signal строится на каждый сконфигурированный контейнер). А
+`agent_hung`/`stage_stuck` emit'ят сигнал **только** когда active=True → при исчезновении сущности
+**не** recovery'ятся (известное ограничение). AC-6 **требует однократный RECOVERY при исчезновении
+процесса**. Решение, **переиспользующее** `decide()`/`AlertState` (FR-5 — никакой отдельной
+анти-спам-логики): в `core.tick()` после построения сигналов по текущим кандидатам **синтезировать**
+`Signal(active=False)` для каждого ключа в `self._states` с префиксом `"proc_blocking"`, который
+`alerting=True`, но **отсутствует** в множестве текущих наблюдаемых ключей → `decide()` даёт
+`RECOVERY` один раз и чистит состояние. Это per-family bookkeeping, не новая throttle-логика.
+PID-recycling — редкий край: естественный цикл vanish→recovery→new-alert корректен; опциональное
+усиление ключа — добавить `start_ticks` (`("proc_blocking", pid, start_ticks)`).
+
+Привязка: FR-1, FR-5, BR-2, BR-5, AC-6.
+
+### D5 — Конфиг + kill-switch (дефолт-off)
+В `watchdog/config.py` добавить ключи (never-raise парсеры `_bool`/`_float`/`_csv`):
+
+| Ключ | Тип | Дефолт | Смысл |
+|------|-----|--------|-------|
+| `WATCHDOG_PROC_ENABLED` | bool | **`false`** | kill-switch / осознанный opt-in (зеркало `WATCHDOG_DISK_CRIT_ENABLED`) |
+| `WATCHDOG_PROC_AGE_MIN` | float (мин) | `60` | порог возраста; **обязан** > `max(merge_retest_timeout_s, coverage_run_timeout_s)/60` (D2) |
+| `WATCHDOG_PROC_PATTERNS` | CSV | `pytest` | паттерны cmdline тест-класса (substring-матч) |
+| `WATCHDOG_PROC_COOLDOWN_S` | float | `1800` | per-signal cooldown (через `Signal.cooldown_s`, уже есть) |
+
+Derived `proc_age_s = proc_age_min*60` (как `agent_hung_s`/`stage_stuck_s`). **Дефолт-off** — потому
+что `proc_blocking` требует привилегии `pid: host` (D6) и осознанного включения (BR-6/NFR-3). При
+`WATCHDOG_PROC_ENABLED=false` коллектор в `core.tick()` **не вызывается** (гейт как у `_collect_disk`
+на `disk_crit_enabled`) → нулевой оверхед и нулевая регрессия (AC-7).
+
+Привязка: FR-3, BR-6, NFR-1, AC-7.
+
+### D6 — Топология: `pid: host` **только** на `orchestrator-watchdog`
+Аддитивная однострочная правка сервиса `orchestrator-watchdog` в `docker-compose.yml`: `pid: host`.
+Под `pid: host` контейнерный `/proc` автоматически отражает хостовый namespace — **отдельный
+mount `/proc` не нужен**. `pid: host` — НЕ volume, поэтому существующий тест
+`tests/watchdog/test_compose_service.py::test_host_paths_mounted_read_only` (требует `:ro` на каждом
+**volume**) остаётся зелёным; разработчик добавляет позитивный тест на наличие `pid: host`.
+**Привилегия — только у наблюдателя**, обоснование/риски — `07-infra-requirements.md` + R-2 ниже.
+Деплой: пересобрать/рестартить **только** `orchestrator-watchdog`; прод `orchestrator` **не**
+трогается (NFR-3). Для Lite/Bundled (ORCH-102/103) `pid: host` становится частью канонического
+compose sidecar; сигнал дефолт-off → нулевое изменение поведения тиражных инсталляций.
+
+Привязка: NFR-3, BR-1, BR-6, AC-9.
+
+### D7 — Диспетч и инварианты конвейера
+Новый сигнал диспетчеризуется в `core.tick()` тем же путём `decision.decide(...)` + `self._states[key]`
++ `self._send(...)`: ALERT на пересечении порога, REALERT по cooldown, RECOVERY при исчезновении
+(D4). Никакой отдельной анти-спам-логики (FR-5). Инварианты (AC-9, byte-for-byte):
+`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict (`verdict:`/`result:`/`deploy_status:`/
+`staging_status:`/`security_status:`/`coverage_status:`) / схема БД / `/metrics`+`schema_version`
+— **не тронуты**. Watchdog — наблюдатель вне процесса орка и вне Quality Gates (как
+`disk_watchdog`/`reaper`/`reconciler`).
+
+## Альтернативы
+- **(b) Orch-side обогащение `/metrics` разделом о бесхозных процессах** — отвергнуто: правит
+  `src/**` → рестарт прод-`orchestrator` (нарушение NFR-3); слеп именно когда орк деградировал
+  (нарушение C-1); новая поверхность контракта `/metrics`. (D1.)
+- **Bind-mount хостового `/proc:ro` вместо `pid: host`** — даёт ту же видимость через read-only
+  volume (паттерн node_exporter `--path.procfs`), но привилегия **эквивалентна** (`/proc/<pid>/environ`
+  читаем при обоих) и `/proc`-mount имеет краевые особенности; `pid: host` идиоматичнее и согласован
+  с уже-host-network-наблюдателем. Остаётся валидной заменой, если оператор предпочитает не делить
+  PID-namespace. (D6.)
+- **Расширить `agent_hung` на нетреканые процессы** — отвергнуто: дубль/смешение классов (NFR-4); у
+  sidecar нет `jobs.pid` для нетреканых, а кросс-namespace PID не совпадают.
+- **Реакция (kill/reap осиротевших)** — вне объёма (жёсткое ограничение заказчика BR-3): задача —
+  только мониторинг; reap — отдельная задача (ремедиация).
+- **Дефолт-on сигнала** — отвергнуто: привилегия `pid: host` + риск false-positive требуют осознанного
+  включения; зеркало `WATCHDOG_DISK_CRIT_ENABLED=false`.
+
+## Последствия
+- **+** Закрыта дыра наблюдаемости: долго живущий блокирующий pytest даёт ранний адресный алерт
+  (PID/cmdline/возраст), даже если орк лёг и ни одна стадия формально не `stuck`.
+- **+** Строго read-only + never-raise + дефолт-off + изменения только в наблюдателе ⇒
+  self-hosting-безопасно; enduro не затронут; конвейер byte-for-byte; deploy без рестарта прод-орка
+  (NFR-3).
+- **+** Анти-false-positive и отсутствие дубля с `agent_hung` — структурно (cmdline-скоуп + порог
+  возраста), а не хрупким матчингом PID.
+- **−** Расширение привилегии наблюдателя (`pid: host`): sidecar видит таблицу процессов хоста.
+  Митигейшн: привилегия read-only и **меньше**, чем уже смонтированный `docker.sock` (полная
+  интроспекция контейнеров); код читает **только** `/stat`+`/cmdline`, никогда `/environ`; сигнал
+  дефолт-off; cmdline в алерте усечена. (R-1/R-2.)
+- **−** Новая поверхность совместимости с `/proc`-форматом (Linux-специфично); на не-Linux/битом
+  `/proc` коллектор → `[]` (один сигнал тих). Митигейшн: чистый разбор + фикстуры.
+- **−** Канон тиража: при добавлении ключей/правке compose — синхронизировать в **том же PR**
+  `.env.watchdog.example` ↔ блок `WATCHDOG_*` `.env.example`, `docs/deployment/LITE_SETUP.md`,
+  `docs/architecture/README.md` (NFR-5; key-sync `tests/test_lite_setup_doc.py`).
+- **Масштаб:** новый компонентный сигнал + изменение топологии/привилегий наблюдателя →
+  рекомендуется лейбл **`arch:major-change`**; прод-выкат — через staging-эквивалент sidecar
+  (smoke на staging-хосте), без рестарта прод-`orchestrator`.
+- **Откат:** `WATCHDOG_PROC_ENABLED=false` (мгновенный, привилегия дремлет) или удаление
+  `watchdog/collectors/proc.py` + builder/врезки + ключей + `pid: host` — без следов в БД/схеме/
+  контракте `/metrics`.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-111/01-brd.md`
+- TRZ: `docs/work-items/ORCH-111/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-111/03-acceptance-criteria.md`
+- Инфра: `docs/work-items/ORCH-111/07-infra-requirements.md`
+- Риски: `docs/work-items/ORCH-111/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md`
+- Связанные ADR: `adr-0033` (sidecar-watchdog F1b — машина `decide`/`AlertState`/never-raise),
+  `adr-0030` (контракт `/metrics`/`schema_version` — НЕ трогаем), `adr-0024` (disk-watchdog — образец
+  pure-решающей функции + dedup), `adr-0040` (ORCH-109 timeout-kill `-9` — источник осиротения).
+- Сверено по коду: `watchdog/{core,signals,config,decision,notify}.py`,
+  `watchdog/collectors/{host,orch}.py`, `docker-compose.yml` (сервис `orchestrator-watchdog`),
+  `src/merge_gate.py::retest_branch`, `src/coverage_gate.py::measure_coverage`,
+  `src/config.py` (`merge_retest_timeout_s=600`, `coverage_run_timeout_s=900`),
+  `tests/watchdog/test_compose_service.py`, `tests/test_lite_setup_doc.py`.
+</content>

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

@@ -0,0 +1,62 @@
+---
+work_item: ORCH-111
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-111 — watchdog-алерт на долго живущий тест-процесс
+
+Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: architecture
+
+> Применимо: меняется топология контейнера-наблюдателя (`pid: host`) и добавляются env-ключи
+> watchdog. Решение — `06-adr/ADR-001` + сквозной `adr-0041`.
+
+## I-1. Топология / окружения
+- **Изменение:** сервису `orchestrator-watchdog` в `docker-compose.yml` добавляется **`pid: host`**
+  (ADR-001 D6). Под `pid: host` контейнерный `/proc` отражает корневой PID-namespace хоста →
+  watchdog видит таблицу процессов хоста (включая осиротевшие pytest, репарентированные на tini
+  orchestrator-контейнера). **Отдельный mount `/proc` не требуется** (procfs зависит от namespace
+  читателя).
+- `pid: host` — **НЕ volume** → существующий тест `tests/watchdog/test_compose_service.py::
+  test_host_paths_mounted_read_only` (требует `:ro` на каждом volume) остаётся зелёным; разработчик
+  добавляет позитивный тест на наличие `pid: host`.
+- Привилегия — **только у наблюдателя** (`orchestrator-watchdog`). Прод `orchestrator` и
+  `orchestrator-staging` **не** меняются. Прочие тома/порты/сеть watchdog — без изменений
+  (`network_mode: host`, `docker.sock:ro`, `/repos:ro`, `./data:ro`, `mem_limit: 128m`).
+- **Тираж (Lite/Bundled, ORCH-102/103):** `pid: host` входит в канонический compose sidecar; сигнал
+  дефолт-off → нулевое изменение поведения у тиражных инсталляций.
+
+## I-2. Переменные окружения / секреты
+- **Новые ключи** (ADR-001 D5), парсеры never-raise:
+  | Ключ | Дефолт | Смысл |
+  |------|--------|-------|
+  | `WATCHDOG_PROC_ENABLED` | `false` | kill-switch / осознанный opt-in |
+  | `WATCHDOG_PROC_AGE_MIN` | `60` | порог возраста (мин); **обязан** > `max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)/60` |
+  | `WATCHDOG_PROC_PATTERNS` | `pytest` | CSV паттернов cmdline (substring-матч) |
+  | `WATCHDOG_PROC_COOLDOWN_S` | `1800` | per-signal cooldown |
+- **Канон тиража (NFR-5 / AC-10):** ключи добавить в **том же PR** в `.env.watchdog.example` **И** в
+  блок `WATCHDOG_*` `.env.example` (равенство множеств держит `tests/test_lite_setup_doc.py`
+  TC-02b) + описать в `docs/deployment/LITE_SETUP.md` и `docs/architecture/README.md`.
+- **Секреты:** новых нет. Канал алертов — существующий `WATCHDOG_TG_*` (свой бот sidecar, C-1).
+- **На прод-хосте (разово, человек):** в `.env.watchdog` выставить `WATCHDOG_PROC_ENABLED=true`
+  (включение сигнала; без этого — дремлет).
+
+## I-3. Деплой / рестарт
+- **Self-hosting инвариант (NFR-3):** выкат пересобирает/рестартит **только** контейнер
+  `orchestrator-watchdog` (`docker compose up -d --build orchestrator-watchdog`). Прод-контейнер
+  `orchestrator` **НЕ** перезапускается (иначе встанет конвейер всех проектов, включая enduro).
+- Прод-выкат sidecar — через staging-эквивалент (smoke на staging-хосте перед прод): проверить, что
+  под `pid: host` коллектор видит процессы, сигнал поднимается на синтетическом старом pytest и молчит
+  при дефолт-off.
+- **Откат:** `WATCHDOG_PROC_ENABLED=false` (мгновенный; привилегия дремлет) либо снятие `pid: host` +
+  рестарт только sidecar.
+
+## I-4. CI/CD
+- Без изменений `.gitea/workflows/`. Новые тесты — `tests/watchdog/test_proc_blocking_signal.py`,
+  `tests/watchdog/test_tick_proc_blocking_integration.py` (TRZ §2) — исполняются существующим
+  `pytest tests/`. Key-sync (`test_lite_setup_doc.py`) и compose-тесты watchdog должны остаться
+  зелёными.
+</content>

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

@@ -0,0 +1,38 @@
+---
+work_item: ORCH-111
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-111 — watchdog-алерт на долго живущий тест-процесс
+
+Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Расширение привилегии наблюдателя** (`pid: host`): sidecar видит таблицу процессов всего хоста (все контейнеры). | Сред. | Сред. | Привилегия **read-only** и **меньше**, чем уже-смонтированный `docker.sock` (полная интроспекция контейнеров); код читает **только** `/proc/<pid>/{stat,cmdline}`, **никогда** `/proc/<pid>/environ`; сигнал дефолт-off; обоснование в ADR-001 D1/D6 + adr-0041. (NFR-2/AC-3) |
+| TR-2 | **Утечка секретов через cmdline** в Telegram-алерт (если тест-команда содержит чувствительный аргумент). | Низ. | Сред. | Скоуп паттерна — `pytest` (не принимает секретов в аргументах); cmdline в detail **усекать** до ограниченного фрагмента; канал — приватный бот оператора (C-1). |
+| TR-3 | **Ложные срабатывания** на легитимном длинном прогоне → спам. | Низ. | Сред. | Порог возраста **обязан** > `max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)`; дефолт `WATCHDOG_PROC_AGE_MIN=60` мин (4× запас); cmdline-скоуп; дедуп/cooldown через `decision.decide`/`AlertState` (BR-4/BR-5, по построению D2). |
+| TR-4 | **Кросс-namespace PID не совпадают** (`pid: host` даёт хост-глобальные PID; `/metrics agents[].pid` — namespace орка) → ненадёжная атрибуция «процесс активного джоба». | Сред. | Низ. | Атрибуция **не** через PID, а через порог возраста (namespace-агностичен) + cmdline-скоуп; дубль с `agent_hung` исключён по построению (claude ≠ pytest). ADR-001 D2. |
+| TR-5 | **Отсутствие RECOVERY** для исчезнувшего процесса (динамический per-entity ключ — как у `agent_hung`/`stage_stuck`, которые не recovery'ятся при пропадании сущности). | Сред. | Низ. | Синтез `Signal(active=False)` для `proc_blocking`-ключей, alerting=True но исчезнувших из наблюдаемых → один RECOVERY через `decide()` (ADR-001 D4, AC-6). Покрыть интеграционным тестом tick→recovery. |
+| TR-6 | **PID-recycling**: PID переиспользован после смерти орфана → ложная пара recovery+new-alert. | Низ. | Низ. | Естественный цикл vanish→recovery→new-alert корректен; опционально усилить ключ `("proc_blocking", pid, start_ticks)`. |
+| TR-7 | **never-raise регресс**: гонка «процесс умер между `listdir(/proc)` и `read`» или битый `/proc` роняет тик. | Низ. | Выс. | Per-pid guard (skip), top-level guard → `[]`; чистый разбор отделён от I/O и покрыт фикстурами; AC-8. |
+| TR-8 | **Дрейф канона тиража**: ключи добавлены в код, но не синхронизированы в `.env.example`/`.env.watchdog.example`/`LITE_SETUP.md`. | Сред. | Низ. | Key-sync `tests/test_lite_setup_doc.py` (TC-02b) красит PR; норматив NFR-5 «обновить в том же PR»; reviewer-ось ORCH-079 (доки). |
+| TR-9 | **Не-Linux / нет `/proc`** (тиражная инсталляция на не-Linux) → сигнал не работает. | Низ. | Низ. | Коллектор → `[]` (один сигнал тих, тик жив); сигнал дефолт-off; Linux-специфичность задокументирована (как CPU-liveness `agent_hung`). |
+
+## Сводный вывод
+Доминирующий класс — **безопасность наблюдателя** (TR-1/TR-2: привилегия `pid: host` + видимость
+cmdline). Остаточный риск для прод-конвейера **низкий**: все изменения строго в наблюдателе
+(`watchdog/**` + сервис watchdog), read-only, never-raise, дефолт-off; `src/**` / `/metrics` /
+`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / схема БД — не тронуты; выкат не рестартит прод-`orchestrator`
+(NFR-3). Эскалация: рекомендуется лейбл **`arch:major-change`** (изменение топологии/привилегий
+наблюдателя + новый компонентный сигнал). Возврат в анализ **не требуется** — ТЗ удовлетворяется без
+нарушения принципов архитектуры (всё в Docker на одном сервере, stdlib-only, без новых зависимостей).
+</content>

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

@@ -0,0 +1,156 @@
+---
+verdict: APPROVED
+work_item: ORCH-111
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-111
+version: 2
+---
+
+# Review ORCH-111
+
+## Summary
+
+PR добавляет в sidecar-watchdog opt-in сигнал `proc_blocking` — алерт на долго живущий осиротевший
+тест-процесс (pytest), репарентированный на хост и грузящий CPU (инцидент: осиротевший
+`test_install_lite_script.py` жил >2 суток без единого алерта и через CPU-голодание валил merge-gate
+re-test на ORCH-109). Изменение **строго внутри наблюдателя** (`watchdog/**` + одна строка `pid: host`
+в сервисе `orchestrator-watchdog` `docker-compose.yml`).
+
+Проверено по всем 4 осям, с независимой верификацией (прогон тестов, скан запрещённых вызовов, сверка
+`src/` diff, сверка key-sync канона, атрибуция деплой-фейла). **Замечаний уровня P0/P1 нет.**
+`src/**` — байт-в-байт не тронут (`git diff origin/main…HEAD -- src/` пуст), конвейерные контракты
+сохранены, документация наблюдателя обновлена в том же PR, watchdog+key-sync тесты зелёные
+(**125 passed** на текущем HEAD). **Вердикт: APPROVED.**
+
+> **Re-review (v2).** Задача вернулась на `review` после `deploy_status: FAILED` (`hook_exit_code: 1`,
+> ORCH-036 self-deploy). Деплой-фейл **расследован и НЕ относится к диффу** (см. раздел «Атрибуция
+> деплой-фейла» ниже): normal-deploy хука рестартит **только** сервис `orchestrator` (retag
+> прев-валидированного образа + health-check порта 8500), сервис `orchestrator-watchdog` он **не
+> трогает** — правка `pid: host` физически не могла вызвать exit 1. Это деплой-инфра/окружение
+> (CPU-голодание хоста — ровно тот класс осиротевших процессов, который и закрывает эта задача), не
+> ось code-review. Дифф с момента прошлого review/testing **кодово не менялся** (поздний developer
+> commit run 680 добавил только детерминированные gate-артефакты `17-security-report.md`/
+> `18-coverage-report.md`). Подтверждаю APPROVED на тех же основаниях.
+
+### Сверка по осям
+
+**1. Соответствие ТЗ / Acceptance Criteria — PASS.**
+- FR-1 (`watchdog/signals.py::proc_signals` — чистый builder, per-entity key `("proc_blocking", pid)`,
+  active ⇔ `age_s > cfg.proc_age_s`, действенный RU-`detail`: PID + возраст(с) + усечённый cmdline
+  ≤120 + накопленное CPU) — ✓.
+- FR-2 (`watchdog/collectors/proc.py` — stdlib-only `/proc`-скан, read-only, never-raise → `[]`,
+  чистый разбор `parse_btime`/`parse_pid_stat`/`decode_cmdline`/`matches_patterns` отделён от I/O
+  `collect_candidates`, инъектируемые `proc_root`/`now`/`clk_tck`/`read_*` для тестов на фейк-`/proc`) — ✓.
+- FR-3 (4 ключа `WATCHDOG_PROC_*`, парсеры `_bool`/`_float`/`_csv` never-raise, дефолт-off,
+  derived `proc_age_s`) — ✓.
+- FR-4 (только наблюдение — нет `os.kill`/сигналов/`subprocess`/мутаций/чтения `/proc/<pid>/environ`;
+  независимо подтвердил grep'ом: совпадения только в докстрингах-контракте) — ✓.
+- FR-5 (диспетч `core.tick()` через существующую `decision.decide()`/`AlertState`; RECOVERY
+  синтезируется `_synthesize_proc_recoveries` без новой анти-спам-логики — per-family bookkeeping) — ✓.
+- FR-6 (без дубля с `agent_hung` — по построению: cmdline-скоуп `pytest` ≠ `claude` + порог возраста
+  выше бюджета; кросс-namespace матчинг PID не нужен) — ✓.
+- AC-1…AC-10 покрыты: TC-01 (red→green builder), TC-02 (граница strict `>`), TC-03 (конфиг/kill-switch),
+  TC-04 (never-raise/read-only AST), TC-05 (alert→none→realert→recovery→no-repeat), TC-06 (partition
+  vs agent_hung), TC-07 (red→green tick→dispatch «алерт даже когда ни одна стадия не stuck» + flag-off
+  + collector-explodes), TC-12 (compose `pid: host` + прод-orch его НЕ получает), key-sync.
+- §7 (порог): дефолт `WATCHDOG_PROC_AGE_MIN=60` (=3600s) > `max(merge_retest_timeout_s=600,
+  coverage_run_timeout_s=900)=900s` (4× запас) — кросс-инвариант D2 соблюдён (анти-false-positive AC-4).
+
+**2. Соответствие ADR — PASS.**
+- Реализация 1:1 соответствует ADR-001: D1 (watchdog-side `/proc` под `pid: host`, НЕ orch-side
+  `/metrics`), D2 (анти-FP/анти-дубль по построению), D3 (коллектор), D4 (builder + синтез RECOVERY
+  для исчезнувшего PID), D5 (конфиг дефолт-off), D6 (`pid: host` **только** на `orchestrator-watchdog`),
+  D7 (инварианты конвейера). PID-recycling — осознанный край ADR D4 (start_ticks в ключ не добавлен;
+  «опциональное усиление»), допустимо.
+- Сквозной `docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md` присутствует.
+- **Трассировка (TRACEABILITY.md):** правки `watchdog/{core,signals,config}.py` + сервиса watchdog —
+  аддитивные врезки, гейтированные на `proc_enabled`; маркированные инварианты предшественников
+  (ORCH-100 sidecar `decide`/`AlertState`/never-raise; read-only-маунты) не сломаны. Существующий
+  `test_host_paths_mounted_read_only` остаётся зелёным (`pid` — не volume), добавлен позитивный
+  `test_watchdog_shares_host_pid_namespace`.
+- Глобальные инварианты (AC-9): `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict /
+  схема БД / `/metrics`+`schema_version` — **байт-в-байт не тронуты** (подтверждено: `git diff` по
+  `src/` пуст).
+
+**3. Качество кода — PASS.**
+- Docstrings на всех публичных функциях (коллектор/builder/synth/tick) — содержательные, со ссылками
+  на D-решения ADR.
+- Тесты содержательные, не тривиальные: red→green регресс-якоря (TC-01 builder, TC-07 tick→dispatch),
+  граничный strict `>`, патологический `comm` со скобками/пробелами, NUL-cmdline, гонка «pid исчез
+  mid-scan», AST-скан read-only-контракта, полная последовательность alert→none→realert→recovery.
+- **Регресс-тест дефекта (ORCH-019 BR-4 / усиление):** задача эскалирована `escalate: full-cycle`
+  (прошла `architecture`, не bug-fast-track), но несёт явные тест-фиксаторы дефекта (TC-01 builder,
+  TC-07 tick→dispatch — оба red→green) — требование «фикс кода несёт тест-фиксатор» выполнено.
+- Безопасность: read-only (per-pid + top-level guard), never-raise, `/proc/<pid>/environ` не читается
+  (секреты, R-2), cmdline усечена до 120 (анти-утечка аргументов). Привилегия `pid: host` — read-only,
+  только у наблюдателя, обоснована в `07-infra-requirements.md`; меньше уже-смонтированного
+  `docker.sock`.
+- Корректность вычислений: `age_s = now − (btime + starttime/clk_tck)`, `cpu_s = (utime+stime)/clk_tck`,
+  `clk_tck` с безопасным фолбэком 100 — верно; CPU вне активации (информационно), как требует ADR.
+
+**4. Документация — PASS.**
+- `src/**` НЕ изменён → жёсткое правило «src изменён, доки нет → P0» не активируется; доки наблюдателя
+  обновлены в том же PR независимо: `CHANGELOG.md`, `docs/architecture/README.md` (раздел
+  `proc_blocking`), `docs/deployment/LITE_SETUP.md` (opt-in блок + «Проверка»), ADR work-item
+  `06-adr/ADR-001` + сквозной `adr-0041`, `.env.watchdog.example` ↔ блок `WATCHDOG_*` `.env.example`
+  (4 ключа синхронизированы 1:1, key-sync `tests/test_lite_setup_doc.py` зелёный).
+- Витрина `docs/overview/` (ORCH-011): sidecar-watchdog описан абстрактно (каталог сигналов не
+  перечисляет); новый opt-in (дефолт-off) сигнал абстрактную формулировку не противоречит,
+  машинно-проверяемые факты не меняет → обновление витрины не обязательно (не P1).
+- Стадийное владение артефактами соблюдено (rule 3/4): ретроактивных правок ТЗ/ADR нет.
+
+## Атрибуция деплой-фейла (вне оси code-review, информационно)
+
+`14-deploy-log.md` фиксирует `deploy_status: FAILED` / `hook_exit_code: 1`. Расследование:
+- Normal-deploy `scripts/orchestrator-deploy-hook.sh` (шаги 2b/3/4) выполняет **retag
+  прев-валидированного `SOURCE_IMAGE`** на `orchestrator` + `docker compose up -d --no-build
+  $TARGET_SERVICE` **только для сервиса `orchestrator`** + health-check **порта 8500**. Сервис
+  `orchestrator-watchdog` хук **не пересобирает и не рестартит**.
+- Следовательно правка `pid: host` (только в watchdog-сервисе) и весь код `watchdog/**`
+  **физически не участвуют** в этом деплое и не могли дать exit 1.
+- Признаки в истории (`chore: retrigger merge-gate re-test (flaked under host CPU starvation)`)
+  указывают на CPU-голодание хоста — ровно тот класс осиротевших pytest-процессов, который и
+  закрывает ORCH-111. Это деплой-инфра/окружение, не дефект диффа.
+- **Путь вперёд** — повторный прод-деплой после стабилизации хоста (вне ответственности reviewer);
+  блокировать review по инфра-фейлу деплоя нет оснований.
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice to have (не блокируют)
+- [ ] `watchdog/collectors/proc.py:202` — опечатка в комментарии top-level `except`: «one signal tih»
+  → «one signal **тих**» (косметика).
+- [ ] `core.py::_dispatch`: после RECOVERY ключ `("proc_blocking", pid)` остаётся в `self._states`
+  с `alerting=False` навсегда (мелкое неограниченное накопление мёртвых-PID ключей за время жизни
+  sidecar). Эффект пренебрежимо мал (запись крошечная; алертящий PID требует процесс >1ч matching
+  `pytest` — событие исключительное), зеркалит существующий паттерн `container_down`; повторный
+  RECOVERY не синтезируется (`state.alerting` уже False). Опционально — очищать ключ после RECOVERY.
+- [ ] Индекс `docs/architecture/adr/README.md` не содержит `adr-0041` — **предсуществующий долг**
+  (нет также `adr-0038/0039/0040`), не свойство этого PR и не per-PR-контракт. Не вменяется ORCH-111.
+
+## Документация
+
+Документация обновлена корректно и в полном объёме **в том же PR**:
+- `CHANGELOG.md` — запись с разбивкой по D-решениям. ✓
+- `docs/architecture/README.md` — раздел `proc_blocking` в описании sidecar-watchdog. ✓
+- `docs/deployment/LITE_SETUP.md` — opt-in блок с «Проверкой» (NFR-5). ✓
+- `docs/work-items/ORCH-111/06-adr/ADR-001-...` + сквозной `docs/architecture/adr/adr-0041-...`. ✓
+- `.env.watchdog.example` ↔ блок `WATCHDOG_*` `.env.example` — синхронизированы (4 ключа), key-sync
+  тест зелёный. ✓
+
+`src/**` байт-в-байт не тронут → жёсткое правило P0 не активируется; функционал наблюдателя
+задокументирован, конвейерные контракты сохранены, выкат пересобирает только `orchestrator-watchdog`
+(прод `orchestrator` не рестартится, NFR-3). **Документация = golden source: требование выполнено.**

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

@@ -0,0 +1,77 @@
+---
+result: PASS
+work_item: ORCH-111
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-111
+---
+
+# Test Report — ORCH-111
+
+BUG: watchdog must alert on long-lived pytest/child processes that block the pipeline.
+Новый opt-in сигнал sidecar-watchdog `proc_blocking` (дефолт-off, never-raise, read-only).
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-111-bug-watchdog-must-alert-on-lon/`
+- Branch: `feature/ORCH-111-bug-watchdog-must-alert-on-lon`
+- Дата: 2026-06-15
+
+## Smoke API (read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — OK
+- `GET /status` → 200, активная задача `ORCH-111` (task 99) на стадии `testing` — OK
+- `GET /queue` → 200; блок `serial_gate` присутствует (orchestrator: active=ORCH-111),
+  блок `auto_labels` присутствует — OK; counts: done=1873, failed=8, breaker=closed
+
+## Результаты — покрытие тест-плана (04-test-plan.yaml)
+
+| TC ID | Описание | Тест(ы) | Результат |
+|-------|----------|---------|-----------|
+| TC-01 | РЕГРЕСС (red→green): builder активирует `proc_blocking` для долгоживущего pytest-процесса вне активного джоба (AC-1) | `test_proc_blocking_signal.py::test_tc01_builder_emits_active_proc_blocking_signal` | PASS |
+| TC-02 | Анти-false-positive: возраст ниже порога / атрибуция активному джобу → сигнал неактивен (AC-4) | `test_tc02_below_threshold_is_inactive`, `test_tc02_boundary_is_strict_greater_than` | PASS |
+| TC-03 | Конфиг/kill-switch: `WATCHDOG_PROC_*` парсятся с безопасными дефолтами; дефолт-off инертен; порог > merge_retest_timeout (AC-7) | `test_tc03_defaults_are_off_and_safe`, `test_tc03_env_overrides_and_malformed_degrade`, `test_tc03_killswitch_off_makes_collector_inert`, `test_config_killswitch.py::test_proc_blocking_*` | PASS |
+| TC-04 | never-raise/read-only коллектора: битый/пустой/недоступный источник → `[]`; нет os.kill/signal/subprocess (AC-3/AC-8) | `test_tc04_collector_degrades_to_empty_on_broken_source`, `test_tc04_collector_empty_when_btime_unreadable`, `test_tc04_collector_source_is_read_only`, `test_tc04_builder_skips_records_missing_fields` | PASS |
+| TC-05 | Анти-спам/recovery через decision.decide+AlertState: ALERT→NONE→REALERT→однократный RECOVERY (AC-6) | `test_tc05_alert_throttle_realert_then_recovery` | PASS |
+| TC-06 | Без дубля с `agent_hung`: процесс из /metrics agents[] / claude-агент не порождает `proc_blocking` (AC-5) | `test_tc06_claude_agent_cmdline_never_matches_pytest_pattern`, `test_tc06_collector_excludes_non_matching_processes` | PASS |
+| TC-07 | РЕГРЕСС tick→dispatch: `Watchdog.tick()` диспетчеризует `proc_blocking`-алерт; флаг-off → ничего; never-raise (AC-1/AC-7) | `test_tick_proc_blocking_integration.py::test_tc07_tick_dispatches_proc_blocking_alert`, `test_tc07_killswitch_off_dispatches_nothing`, `test_tc07_in_budget_process_does_not_alert`, `test_tc07_tick_never_raises_when_collector_explodes` | PASS |
+| TC-08 | Конфиг-канон/тираж: key-set `.env.watchdog.example` ↔ блок `WATCHDOG_*` в `.env.example` синхронизирован (AC-10) | `test_config_killswitch.py` + key-sync (`test_lite_setup_doc.py`) | PASS |
+| TC-09 | Полный регресс `pytest tests/` зелёный; конвейер/QG не затронуты; schema_version /metrics не бампнут (AC-9) | `pytest tests/` (1933 passed) | PASS |
+
+Дополнительно зелёный leaf-набор коллектора `tests/watchdog/test_proc_collector.py`
+(13 тестов: разбор `/proc/stat` btime, `pid/stat` с comm в скобках/пробелах, NUL-cmdline,
+паттерны, фильтрация, гонка «pid исчез mid-scan») и compose-инвариант
+`test_compose_service.py::test_watchdog_shares_host_pid_namespace` + read-only маунты.
+
+Все TC сопоставлены с критериями приёмки `03-acceptance-criteria.md` (AC-1…AC-10) и выполнены.
+
+## Сверка инвариантов (AC-3 / AC-9)
+- `git diff origin/main...HEAD -- src/` — **пуст**: `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+  machine-verdict/схема БД байт-в-байт не тронуты. Изменения только в `watchdog/**`, `tests/**`, docs,
+  `.env*.example` и одна строка `pid: host` сервиса `orchestrator-watchdog` в `docker-compose.yml`.
+- Read-only/без ремедиации: grep `os.kill|subprocess.(Popen|run|call)|send_signal|terminate|kill` по
+  `watchdog/**` даёт единственное совпадение — докстринг `collectors/proc.py`, явно фиксирующий
+  read-only-инвариант (`/proc/stat`, `/proc/<pid>/stat`, `/proc/<pid>/cmdline` только на чтение).
+
+## Вывод pytest
+Независимый прогон tester (HEAD `521a72e`, worktree ветки задачи):
+```
+$ cd /repos/_wt/orchestrator/feature_ORCH-111-bug-watchdog-must-alert-on-lon && \
+    python -m pytest tests/ -q --tb=short
+.............................................................            [100%]
+================ 1933 passed, 1 warning in 447.41s (0:07:27) ==================
+EXIT=0
+```
+Целевые watchdog-модули детально: `37 passed` (proc_blocking_signal + tick_integration +
+config_killswitch + proc_collector).
+Единственный warning — предсуществующий `PydanticDeprecatedSince20` в `src/config.py:8`
+(не связан с ORCH-111, не блокирует).
+
+## Итог
+PASS — полный регресс зелёный (1933 passed), smoke API (`/health`, `/status`, `/queue`
+с блоками `serial_gate`/`auto_labels`) — OK, каждый TC из `04-test-plan.yaml` выполнен и
+сопоставлен с критериями приёмки. Задача готова к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,33 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-111
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T05:46:24Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance (port 8501,
+mode=stub), 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 → `staging_status: SUCCESS`.**
+
+- REAL failed: none — all real checks green.
+- SANDBOX_INFRA failed (tolerated, 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
+
+## Blocks
+- Block A (SMOKE): A1, A2, A3 — PASS
+- Block B (ACCESS): B4, B5, B6 (registry isolation: sandbox present, prod ET/ORCH absent) — PASS
+- Block C (E2E, stub): C7, C8 — PASS; C9a, C9b — sandbox-infra waived (exit 0)
+
+Tolerance active: `staging_infra_tolerance_enabled=True`. Exit-code → verdict mapping unchanged;
+waived checks not re-judged.

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

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

docs/work-items/ORCH-111/18-coverage-report.md

@@ -0,0 +1,22 @@
+---
+coverage_status: PASS
+work_item: ORCH-111
+measured_coverage: 79.94
+baseline: 79.95
+floor: 0.00
+policy: both
+epsilon: 0.50
+delta: -0.01
+---
+# Coverage Report — ORCH-111
+
+Детерминированный гейт покрытия (ORCH-027) — под-гейт ребра `deploy-staging→deploy` (ПОСЛЕ merge-gate, ДО image-freshness). Машинный вердикт читается ТОЛЬКО из `coverage_status:` frontmatter выше.
+
+## Verdict
+measured=79.94% policy=both eps=0.50: absolute 79.94% >= floor 0.00%-eps0.50 -> PASS; baseline 79.94% >= base 79.95%-eps0.50 -> PASS
+
+## Measurement
+pytest --cov=src: line coverage src/ = 79.94%
+
+## Policy
+policy=both, floor=0.0%, baseline=79.95%, epsilon=0.5%

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: failed/cancelled task artifacts must be cleaned from shared checkout
+
+Work Item ID: ORCH-112
+
+## Description
+
+TBD

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

@@ -0,0 +1,169 @@
+---
+work_item: ORCH-112
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 01 — BRD / Bug-report: ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
+
+Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в full-cycle**
+
+> ⚠️ **`escalate: full-cycle` (ADR-001 D5 ORCH-019).** Баг помечен `Bug`, но по сути это
+> **архитектурный + safety-critical (self-hosting)** дефект: правка лежит в самом опасном пути
+> прод-деплоя (хост-хук, прямо перед рестартом прод-контейнера) и требует **решения о политике
+> жизненного цикла** shared checkout (ADR). Поэтому выпускается **полный** analysis-пакет, а не
+> облегчённый bug-пакет. Оператор снимает багфикс-трек: `POST /bug-fast-track/escalate?work_item=ORCH-112`
+> → задача пойдёт через стадию `architecture` (architect выпустит ADR для политики cleanup/изоляции).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### Симптом (наблюдаемое)
+Self-deploy задачи **ORCH-111** упал на шаге `git pull origin main` хост-хука деплоя с ошибкой:
+```
+error: Your local changes to the following files would be overwritten by merge:
+        src/config.py
+Please commit your changes or stash them before you merge.
+```
+Деплой прерван, конвейер потребовал **ручного вмешательства оператора** (на self-hosting это
+групповой риск — встаёт деплой и всех других проектов).
+
+### Причина симптома (установленный факт)
+В **общем (shared) checkout** `/home/slin/repos/orchestrator` оставались грязные файлы от
+ранее **неуспешной/отменённой/перезапущенной задачи ORCH-104** (тема Lite installer):
+- модифицированный tracked-файл: `src/config.py`;
+- модифицированный/untracked: `docs/deployment/LITE_SETUP.md`;
+- untracked: `scripts/install_lite.py`, `tests/test_install_lite.py`,
+  `docs/deployment/lite-install.example.yaml`.
+
+Через несколько дней эти остатки **заблокировали** `git pull` другой задачи (ORCH-111).
+
+### Локализация (анализ — куда смотреть архитектору/разработчику)
+
+**Установленный факт о топологии (CLAUDE.md / `docs/architecture/README.md`):**
+`/home/slin/repos/orchestrator` (хост) == `/repos/orchestrator` (контейнер, bind-mount) ==
+**main clone** (`settings.repos_dir/<repo>` = `settings.deploy_host_repo_path`). Это **deploy-база
+и база управления worktree'ами**, а НЕ рабочая копия агента.
+
+1. **Первичный дефект — нерезистентный `git pull`.**
+   `scripts/orchestrator-deploy-hook.sh:224-226` делает `cd "$REPO"` (= deploy-база) и
+   **голый** `git pull origin main` **без гигиены рабочего дерева**. Любая локальная правка
+   tracked-файла блокирует merge → деплой падает. Проверено: во всём `src/`+`scripts/` **нет ни
+   одного** `git reset --hard` / `git clean` / `git stash` для приведения базы к чистому состоянию.
+   Shared checkout трактуется как «всегда чистый», что не гарантировано.
+
+2. **Невыполненный/неэнфорснутый инвариант + отсутствие «дворника».**
+   Нормальный конвейер **не пишет** в рабочее дерево main clone: агенты работают в изолированных
+   worktree'ах `/repos/_wt/<repo>/<branch>` (`git_worktree.ensure_worktree`); `docker build`
+   использует контекст **worktree** (`image_freshness._host_worktree_path`), не main clone;
+   fallback'и гейтов на main clone — **только чтение** (`git show origin/main:...`,
+   `qg/checks.py:451`, `coverage_gate.py:297`, `stage_engine.py:145`). Поэтому грязь ORCH-104
+   почти наверняка — **ручной/брошенный WIP** в shared checkout во время инцидента ORCH-104
+   (косвенное подтверждение: файлы `install_lite.py`/`test_install_lite.py`/`lite-install.example.yaml`
+   **никогда не существовали в git-истории** — закоммиченный артефакт ORCH-104 это
+   `scripts/setup_lite.py`, commit `e2cf883`). Вне зависимости от источника: **нет механизма**,
+   который детектирует/чистит грязную базу и **нет задокументированного/энфорснутого инварианта**
+   «main checkout — неизменяемая deploy-база, не workspace».
+
+3. **`cancel_task` чистит worktree + remote-ветку, но НЕ shared checkout.**
+   `stage_engine.cancel_task` (шаг 3d, строки ~2330-2343): `remove_worktree(repo, branch)` +
+   `gitea.delete_remote_branch(repo, branch)`. Это корректно (конвейер в main clone не пишет), но
+   означает **нулевое покрытие** случая «грязная deploy-база» в каскадах failed/cancelled.
+
+**Вывод:** даже если первопричина грязи — ручное действие, устойчивость должна быть на стороне
+системы: deploy-база обязана **самовосстанавливаться** в чистый `origin/main` перед pull, а
+политика жизненного цикла — гарантировать, что остатки failed/cancelled задач не клинят будущие
+операции.
+
+## 2. Объём (scope)
+
+### В объёме
+- Сделать self-deploy `git pull origin main` (shared deploy-база) **устойчивым к грязному рабочему
+  дереву** — приведение базы к чистому `origin/main` **автономно**, без ручного вмешательства.
+- Гарантировать, что после **failed / cancelled / брошенной** задачи в shared checkout не остаётся
+  рабочих остатков, способных заблокировать будущий деплой/операцию (сходимость базы к чистому
+  `origin/main`).
+- Задокументировать (и где осуществимо — мягко энфорснуть/гардить) инвариант
+  «shared main checkout — deploy/worktree-management база, НЕ редактируемый workspace».
+- Наблюдаемость: лог + Telegram-алерт, когда deploy-база найдена грязной и автоочищена (или отказ).
+
+### Вне объёма
+- ❌ Запрет/контроль ручных операций оператора в shared checkout (вне технической власти системы;
+  закрываем устойчивостью, а не запретом).
+- ❌ Изменение модели worktree per-task (`git_worktree`, ORCH-2) — она корректна и не трогается.
+- ❌ Любое изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей / схемы БД.
+- ❌ Изменение поведения деплоя на чистой базе (happy-path должен остаться байт-в-байт).
+- ❌ Выбор конкретного механизма (reset --hard vs janitor vs guard) — это **зона архитектора** (ADR).
+
+## 3. Заинтересованные стороны
+- **Заказчик/оператор (Слава)** — страдает от ручного разруливания залипших деплоев; принимает результат.
+- **Self-hosting конвейер orchestrator** — прямой потребитель (надёжность прод-деплоя).
+- **Все проекты на общем инстансе (enduro-trails)** — косвенно: залипший self-deploy орка
+  останавливает обслуживание их задач.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Грязное рабочее дерево shared deploy-базы (модифицированные tracked-файлы и/или
+  untracked-файлы) **НЕ должно блокировать** self-deploy `git pull origin main`: деплой обязан
+  привести базу к чистому, актуальному `origin/main` **без ручного вмешательства**.
+- **BR-2** — После failed / cancelled / брошенной задачи в shared checkout **не должно оставаться**
+  рабочих остатков этой задачи, способных заблокировать будущий деплой/git-операцию; база
+  **сходится** к чистому `origin/main`.
+- **BR-3** — Инвариант «shared main checkout (`<host_repos_dir>/<repo>`) — deploy/worktree-management
+  база, НЕ workspace» должен быть **задокументирован** (`docs/operations/INFRA.md` +
+  `docs/architecture/README.md`) и, где осуществимо, **энфорснут/гардирован**; конвейер/агенты
+  **никогда** не пишут рабочие изменения в main clone (верифицировать, что это так).
+- **BR-4** — **Наблюдаемость:** обнаружение грязной базы и факт автоочистки (или отказ) должны
+  логироваться и алертиться (Telegram, кликабельный номер) — оператор видит, что гигиена сработала.
+- **BR-5** — На **чистой** базе поведение деплоя — **байт-в-байт прежнее** (обычный fast-forward
+  `git pull`); никакого регресса happy-path.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (self-hosting safety)** — гигиена **никогда** не трогает ветку `main` на remote, не делает
+  force-push, не рестартит прод-контейнер вне штатного гейта, не удаляет worktree/ветки **других
+  активных** задач. Оперирует **только** настроенным путём deploy-базы.
+- **NFR-2 (сохранность deploy-состояния)** — автоочистка **не должна** удалять артефакты, легитимно
+  живущие под `$REPO`/рядом: rollback-снимки `$REPO/.deploy-prev-image-*`
+  (`deploy_prod_prev_image_file`), `deploy-hook.log`, sibling-состояния
+  `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json`, и админ-записи worktree в `.git/worktrees`.
+  (Наивный `git clean -xfd` в `$REPO` уничтожил бы `.deploy-prev-image-*` и сломал rollback — это
+  **жёсткое ограничение** для архитектора/разработчика.)
+- **NFR-3 (обратимость / kill-switch)** — новое поведение под флагом; выключенный флаг → деплой
+  байт-в-байт как до ORCH-112 (голый `git pull origin main`).
+- **NFR-4 (надёжность)** — never-raise / fail-safe (по образцу leaf'ов `serial_gate`/`cancel`);
+  идемпотентность; restart-safe; сбой гигиены не должен маскировать или ухудшать исход деплоя сверх
+  текущего.
+- **NFR-5 (нулевая регрессия конвейера)** — `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
+  machine-verdict ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт**.
+- **NFR-6 (область)** — изменение скоупится на self-hosting (`orchestrator`); поведение для прочих
+  репо/синхронного деплоя агентом — не ухудшается.
+
+## 6. Допущения и ограничения
+- Shared checkout и хост-хук физически разделяют один путь с контейнером через bind-mount
+  (`repos_dir`↔`host_repos_dir`); хук исполняется на **хосте** по ssh (ORCH-036, detached).
+- Build-once путь (`SOURCE_IMAGE` retag) **не** зависит от содержимого рабочего дерева main clone —
+  прод получает ровно staging-валидированный образ; значит дискард рабочего дерева base перед pull
+  **безопасен для деплоимого артефакта**. (`--build-staging` собирается из **worktree**, не из main —
+  отдельный контур.)
+- Источник истины кода — `origin/main`; локальные правки в deploy-базе **по определению** не должны
+  существовать (это deploy-база, а не место работы).
+- Конкретный механизм (resilient pull через reset+clean со скоуп-исключениями / активный janitor /
+  guard инварианта / комбинация) — **открытый вопрос для архитектуры**, решается в `06-adr/`.
+
+## 7. Критерии успеха
+Self-deploy успешно выполняет `git pull` на ранее грязной shared-базе **без ручного вмешательства**;
+deploy-база сходится к чистому `origin/main`; rollback-состояние и sibling-артефакты сохранены;
+happy-path и весь конвейер — без регресса; обязательный регресс-тест **красный до фикса, зелёный
+после**. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- Деструктивная гигиена (`reset --hard`/`clean`) в **прод-deploy-базе** рядом с рестартом прода —
+  ошибка скоупа может удалить rollback-state/логи (см. NFR-2) → ADR обязателен.
+- Маскировка реальной первопричины: если в будущем какой-то код **начнёт** писать в main clone,
+  «тихая автоочистка» это скроет → нужна наблюдаемость (BR-4).
+- Кросс-каттинг с ORCH-036 (self-deploy), ORCH-058 (image-freshness/provenance), ORCH-090 (cancel),
+  ORCH-2 (worktree-модель). Детали/митигации — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,110 @@
+---
+work_item: ORCH-112
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
+
+Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **требования и ограничения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное **решение** (какой механизм гигиены/изоляции выбрать) — задача архитектора (`06-adr/`),
+> т.к. задача эскалирована в full-cycle (`01-brd.md` → `escalate: full-cycle`).
+
+## 1. Сводка изменения
+Сделать self-deploy устойчивым к **грязной shared deploy-базе** и гарантировать сходимость базы к
+чистому `origin/main` после failed/cancelled/брошенных задач. Корень симптома — голый
+`git pull origin main` в `scripts/orchestrator-deploy-hook.sh` (строка 226), исполняемый в
+`$REPO` (= `settings.deploy_host_repo_path` = main clone), который падает при любой локальной правке
+tracked-файла. Требуется: (а) приведение deploy-базы к чистому `origin/main` перед/в момент pull
+**без ручного вмешательства**, со строгим сохранением deploy-rollback-состояния; (б) документирование
++ (по возможности) энфорс инварианта «main checkout — deploy-база, не workspace»; (в) наблюдаемость.
+
+## 2. Задействованные модули / пути
+| Путь | Действие | Примечание |
+|------|----------|-----------|
+| `scripts/orchestrator-deploy-hook.sh` | изменить | строки 224-226: голый `git pull origin main` в `$REPO` — точка отказа (FR-1) |
+| `src/self_deploy.py` | возможно изменить | `build_deploy_command` / `initiate_deploy` / `rebuild_staging_image` строят инвокацию хука — возможная точка передачи гигиены/флага (решает архитектор) |
+| `src/stage_engine.py` | возможно изменить | `cancel_task` (шаг 3d, ~2330-2343) — каскад cancel; расширение гигиены на shared-базу (FR-2, если выбран этот путь) |
+| `src/git_worktree.py` | возможно изменить | модель main clone ↔ worktree; возможный helper приведения базы к чистоте / верификация инварианта (BR-3) |
+| `src/config.py` | изменить | новый kill-switch + флаги области (FR-5) |
+| `src/<new_leaf>.py` (напр. `checkout_hygiene.py`) | возможно создать | чистый never-raise leaf политики гигиены (по образцу `serial_gate`/`cancel`) — **создавать ли** решает архитектор |
+| `docs/operations/INFRA.md` | изменить | инвариант «shared checkout — deploy-база, не workspace» (BR-3) |
+| `docs/architecture/README.md` | изменить | описать политику гигиены/жизненного цикла deploy-базы |
+| `CHANGELOG.md`, `CLAUDE.md` | изменить | правило «docs = golden source» (CLAUDE.md §2) |
+| `tests/test_<...>.py` | создать | регресс + покрытие (см. `04-test-plan.yaml`) |
+
+## 3. Функциональные требования
+
+### FR-1 — Устойчивый self-deploy `git pull` (BR-1, BR-5)
+- На пути self-deploy (`scripts/orchestrator-deploy-hook.sh`, шаг «2. Pull latest code»)
+  `git pull origin main` **не должен падать** из-за грязного рабочего дерева `$REPO`.
+- Перед обновлением база приводится к чистому, актуальному `origin/main` (приведение tracked- и
+  untracked-изменений к состоянию `origin/main`), **с сохранением** артефактов из NFR-2.
+- На **уже чистой** базе результат — обычный fast-forward; наблюдаемое поведение и exit-коды
+  (0/1/2, ORCH-036) — **байт-в-байт прежние** (BR-5).
+- Контракт: never-break — сбой шага гигиены не должен ухудшать исход относительно текущего голого
+  pull (fail-safe).
+
+### FR-2 — Сходимость shared-базы после failed/cancelled/брошенной задачи (BR-2)
+- После терминации задачи (`failed` job-исход / `cancelled` через STOP / брошенный WIP) в shared
+  checkout **не остаётся** рабочих остатков, способных заблокировать будущий деплой/git-операцию.
+- Допустимая трактовка «сходимости» (на выбор архитектора, **не** прескриптивно здесь): автоочистка
+  непосредственно в self-deploy перед pull (FR-1) **и/или** активный «дворник», приводящий
+  `<host_repos_dir>/<repo>` к чистому `origin/main`.
+- Каскад `cancel_task` (ORCH-090) уже чистит **worktree + remote-ветку**; расширение на shared-базу
+  (если выбрано) делается тем же never-raise best-effort способом.
+
+### FR-3 — Инвариант deploy-базы (BR-3)
+- Задокументировать: `<host_repos_dir>/<repo>` — deploy/worktree-management база; рабочие изменения
+  туда **не пишутся** конвейером/агентами (агенты — worktree `git_worktree`; build — worktree-контекст;
+  fallback'и гейтов — read-only `git show origin/main`).
+- Верифицировать, что текущий код этот инвариант соблюдает (анализ ORCH-112: соблюдает; единственные
+  обращения к main clone — read-only/fetch/worktree-управление). Где осуществимо — добавить
+  лёгкий guard/проверку (решает архитектор), **без** изменения горячих путей.
+
+### FR-4 — Наблюдаемость (BR-4)
+- Обнаружение грязной deploy-базы и факт автоочистки (число/имена сброшенных путей) или **отказ**
+  гигиены — лог (структурная запись) + Telegram-алерт (`send_telegram`, кликабельный номер задачи,
+  best-effort, never-raise). Опционально — read-only снапшот в `GET /queue` (решает архитектор).
+
+### FR-5 — Условность / kill-switch (BR-5, NFR-3, NFR-6)
+- Новое поведение под **kill-switch** (env `ORCH_*`, по образцу `serial_gate_enabled`/`stop_status_enabled`);
+  выключенный флаг → деплой байт-в-байт прежний (голый `git pull origin main`).
+- Область — self-hosting (`orchestrator`); прочие репо/синхронный деплой агентом — не ухудшаются.
+- `applies(repo)` (локальный, без сети) проверяется первым.
+
+## 4. Изменения API
+**Нет** обязательных. Опционально (на усмотрение архитектора) — read-only блок (напр. `checkout_hygiene`)
+в существующем `GET /queue` для наблюдаемости. Новых управляющих эндпоинтов не требуется.
+
+## 5. Изменения схемы БД
+**Нет.** Состояние гигиены, если нужно, — in-memory / sentinel-файлы (паттерн `self_deploy`/`merge_gate`),
+без миграции БД. Аддитивная таблица не требуется.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Это **не** Quality Gate и не стадия — это устойчивость deploy-пути и политика гигиены.
+`STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи
+(`deploy_status:`/`staging_status:`/…) — **байт-в-байт не тронуты** (NFR-5).
+
+## 7. Совместимость / регресс
+- **Обратная совместимость:** kill-switch off → голый `git pull origin main` (1:1 до ORCH-112);
+  чистая база → fast-forward без изменений (BR-5).
+- **Область раската:** self-hosting `orchestrator`; enduro/прочие — нулевая регрессия.
+- **Обратимость:** выключение флага мгновенно возвращает прежнее поведение.
+- **Сохранность (жёсткое ограничение, NFR-2):** гигиена **не удаляет** `$REPO/.deploy-prev-image-*`
+  (rollback), `deploy-hook.log`, sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json`,
+  админ-записи `.git/worktrees`. Любой `clean`-скоуп обязан их исключать.
+- **Self-hosting инварианты (NFR-1):** никогда не трогать `main` на remote, не force-push, не
+  рестартить прод вне гейта, не сносить worktree/ветки других активных задач, оперировать только
+  настроенным путём deploy-базы. Exit-code-контракт хука (0/1/2) сохранён.
+- **Артефакты pipeline:** создаются/обновляются обычные docs work item (`01..04` этой задачи,
+  `06-adr/` на стадии architecture после эскалации, `14-deploy-log.md` при деплое). Новых
+  pipeline-артефактов задача не вводит.
+- **Трассировка (CLAUDE.md §9 / ORCH-078):** правки маркированных блоков (ORCH-036 self-deploy,
+  ORCH-058 image-freshness, ORCH-090 cancel) — сверять с их `06-adr/` перед изменением, инварианты
+  не ломать.

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

@@ -0,0 +1,128 @@
+---
+work_item: ORCH-112
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
+
+Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Reviewer/CI проверяют их буквально по файлам репозитория и тестам.
+
+---
+
+## AC-1 — Грязная tracked-правка не блокирует self-deploy pull (регресс ORCH-104/ORCH-111)
+
+**Условие:** shared deploy-база имеет локальную модификацию tracked-файла (напр. `src/config.py`),
+self-deploy выполняет шаг pull.
+- **PASS:** база приводится к чистому актуальному `origin/main` без ручного вмешательства; шаг pull
+  не возвращает «local changes would be overwritten by merge»; деплой продолжается; есть тест,
+  воспроизводящий точный сценарий ORCH-111 (**красный до фикса, зелёный после**).
+- **FAIL:** pull/деплой падает на грязной tracked-правке; или сценарий не покрыт тестом.
+
+---
+
+## AC-2 — Untracked WIP-файлы не блокируют и не «протекают» в деплой
+
+**Условие:** в shared-базе лежат untracked-файлы failed/брошенной задачи (напр.
+`scripts/install_lite.py`, `tests/test_install_lite.py`, `docs/deployment/lite-install.example.yaml`).
+- **PASS:** база сходится к чистому `origin/main`; untracked-остатки не блокируют операцию и не
+  попадают в деплоимый/собираемый артефакт.
+- **FAIL:** untracked-остатки блокируют операцию либо остаются и клинят будущий деплой.
+
+---
+
+## AC-3 — Сохранность deploy-rollback-состояния и sibling-артефактов (жёсткое ограничение)
+
+**Условие:** в `$REPO`/рядом присутствуют `.deploy-prev-image-*` (rollback), `deploy-hook.log`,
+`<repos_dir>/.deploy-state-*`, `.merge-lease-*.json`, `.git/worktrees/*`.
+- **PASS:** после гигиены **все** перечисленные артефакты на месте; rollback по
+  `.deploy-prev-image-*` остаётся работоспособным; есть тест, доказывающий их неудаление.
+- **FAIL:** гигиена удаляет хотя бы один из этих артефактов (особенно `.deploy-prev-image-*`).
+
+---
+
+## AC-4 — Happy-path без регресса (чистая база)
+
+**Условие:** shared-база чистая, self-deploy выполняет pull.
+- **PASS:** поведение и exit-коды (0/1/2, ORCH-036) — байт-в-байт прежние (обычный fast-forward);
+  полный `pytest tests/ -q` зелёный.
+- **FAIL:** изменилось наблюдаемое поведение/exit-код на чистой базе, либо красный регресс.
+
+---
+
+## AC-5 — Self-hosting safety
+
+**Условие:** исполнение пути гигиены/деплоя.
+- **PASS:** нет операций над веткой `main` на remote, нет force-push, нет рестарта прод-контейнера
+  вне штатного гейта, нет удаления worktree/веток других активных задач; операции строго в пределах
+  настроенного пути deploy-базы; тест/анализ это подтверждает.
+- **FAIL:** любое из перечисленных нарушений присутствует или возможно.
+
+---
+
+## AC-6 — Kill-switch и обратимость
+
+**Условие:** новый флаг выключен.
+- **PASS:** деплой ведёт себя байт-в-байт как до ORCH-112 (голый `git pull origin main`); включение
+  флага активирует устойчивое поведение; область скоупится на self-hosting (прочие репо не затронуты).
+- **FAIL:** выключенный флаг меняет поведение, либо нет kill-switch, либо затронуты прочие репо.
+
+---
+
+## AC-7 — Сходимость после cancel/failed
+
+**Условие:** задача отменена (STOP/ORCH-090) или job завершился `failed`, оставив остатки в
+рабочем дереве deploy-базы.
+- **PASS:** shared-база сходится к чистому `origin/main` (через автоочистку в деплое и/или дворник),
+  и последующий self-deploy проходит без ручного вмешательства; покрыто интеграционным тестом.
+- **FAIL:** остатки сохраняются и блокируют последующий деплой/git-операцию.
+
+---
+
+## AC-8 — Наблюдаемость
+
+**Условие:** обнаружена грязная deploy-база.
+- **PASS:** факт обнаружения и автоочистки (или отказ) — в логах (структурно) и в Telegram-алерте
+  (кликабельный номер); алерт best-effort, never-raise (его сбой не валит деплой).
+- **FAIL:** тихая очистка без следа в логах/уведомлениях, либо сбой алерта роняет деплой.
+
+---
+
+## AC-9 — Инвариант конвейера и БД не тронуты
+
+**Условие:** диф задачи.
+- **PASS:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict
+  ключи / схема БД / exit-code-контракт хука — байт-в-байт; структурные тесты конвейера зелёные.
+- **FAIL:** любой из перечисленных контрактов изменён.
+
+---
+
+## AC-10 — Документация (golden source)
+
+**Условие:** изменён функционал deploy-базы/гигиены.
+- **PASS:** обновлены `docs/operations/INFRA.md` (инвариант deploy-база ≠ workspace) и
+  `docs/architecture/README.md`; `CHANGELOG.md`/`CLAUDE.md` отражают изменение; ADR заведён на
+  стадии `architecture` (после эскалации `escalate: full-cycle`).
+- **FAIL:** функционал изменён, доки/ADR не обновлены (reviewer → finding ≥P1, CLAUDE.md §6).
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-1, BR-2 / FR-1, FR-2 |
+| AC-3 | NFR-2 / FR-1 (ограничение) |
+| AC-4 | BR-5 / FR-1 |
+| AC-5 | NFR-1 / FR-1, FR-2 |
+| AC-6 | NFR-3, NFR-6 / FR-5 |
+| AC-7 | BR-2 / FR-2 |
+| AC-8 | BR-4 / FR-4 |
+| AC-9 | NFR-5 / FR-1…FR-5 |
+| AC-10 | BR-3 / FR-3 |