analyst(ET): auto-commit from analyst run_id=725

Close the root class of incident ORCH-114: a pytest/worktree process performed a
REAL write (PATCH issues state=<Done> + comment) against the PRODUCTION Plane
project, because test/staging processes inherit the live Plane token
(PLANE_HEADERS/PROJECT_ID are captured at import — a post-hoc env/token swap is a
no-op) and nothing forced them to write only to the sandbox. Symmetric to the
existing _no_telegram autouse floor.

- New pure never-raise leaf src/plane_write_guard.py (decide/audit_block/
  audit_allow), wired into the 3 plane_sync write primitives (update_issue_state /
  add_comment / _set_issue_state_direct) via _guard_allows_write, AT CALL TIME,
  before any network step. Active ONLY in a test process (pytest in sys.modules /
  PYTEST_CURRENT_TEST); live + staging runtimes (uvicorn) are a strict no-op.
- In a test process: default-deny. A write is allowed iff opt-in
  (plane_test_write_enabled) AND target project in the sandbox allowlist
  (plane_test_sandbox_projects, default = the one SANDBOX id). Prod is blocked even
  with opt-in (allowlist sandbox-only); unresolved project -> block (fail-closed).
- Independent second layer: tests/conftest.py::_plane_sandbox_only autouse floor.
  Intentionally NO prod-block kill-switch (anti back-door, NFR-6).
- Audit: block -> loud ERROR; sandbox-allow -> INFO.
- Bypass fixtures for the 3 (+1) pre-existing tests that assert on the mocked
  write primitive's httpx call (header/URL/state logic), the guard is no Quality
  Gate: STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict / DB schema
  untouched.
- Tests: tests/test_orch117_plane_write_isolation.py (TC-01 mandatory ORCH-114
  regression + TC-02..TC-14). Docs: CLAUDE.md, architecture/README.md,
  operations/INFRA.md, .env.example, CHANGELOG.md.

Refs: ORCH-117
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=
@@ -164,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
@@ -319,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:
@@ -404,6 +447,34 @@ 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
@@ -569,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
@@ -588,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=

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-011
+Work item: ORCH-112
 Repo: orchestrator
-Branch: feature/ORCH-011-
+Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
 Stage: development

CHANGELOG.md

@@ -3,6 +3,33 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
+- **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`).

CLAUDE.md

@@ -235,6 +235,182 @@ kill-switch, never-raise, fail-safe → полный цикл.
   `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`,
   `docs/architecture/adr/adr-0029-coverage-gate.md`.
 
+## Merge-gate re-test: инфра-толерантность + tree-kill + контракт re-test (ORCH-110)
+Багфикс инцидента **ORCH-109/PR #129** (bug → escalate full-cycle): локальный re-test merge-gate
+(`check_branch_mergeable`, ребро `deploy-staging → deploy`) падал по **таймауту** (516.7s-сюит упёрся
+в бюджет 600s под CPU-голоданием от **осиротевших** pytest-процессов) при зелёных CI+tester+staging →
+маршрутизировался как **код-фейл** в `_handle_merge_gate_rollback` (откат на `development` + расход
+developer-retry) → каждый retry падал так же → «Merge-gate still failing after 3 developer retries» →
+ручное вмешательство. Аддитивно, под **5 независимыми kill-switch**, never-raise, скоуп self-hosting;
+`STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика/имя `check_branch_mergeable`/machine-verdict-ключи/
+схема БД — **байт-в-байт не тронуты** (merge-gate остаётся под-гейтом-врезкой, не новой стадией/QG);
+INV-4 (никогда push/force-push `main`) и запрет рестарта прод-контейнера — соблюдены.
+- **D1 (tree-kill, корень утечки):** новый stdlib-only leaf `src/proc_group.py`
+  (`run_in_process_group`, паттерн чистоты `serial_gate`) спавнит спавненный pytest в **отдельной
+  группе процессов** (`start_new_session`) и при таймауте убивает **всё дерево** (`os.killpg`, каскад
+  SIGTERM→grace→SIGKILL, зеркало `launcher.stop_process`, грейс = `agent_kill_grace_seconds`).
+  Используют его `merge_gate.retest_branch` И `coverage_gate.measure_coverage` (сиблинг-источник
+  утечки). Контракты возврата сохранены — меняется лишь отсутствие сирот. Fallback never-break:
+  `subprocess_tree_kill_enabled=False`/не-POSIX → прежний `subprocess.run`.
+- **D2/D3 (классификация + маршрутизация):** чистый предикат `merge_gate.classify_retest_failure`
+  различает `timeout`/`red`/`lock-busy`/`other` (scope-guard: «rebase timeout» git'а — НЕ инфра-таймаут
+  re-test). Инфра-таймаут → `_handle_merge_gate_infra_retry` (зеркало `_handle_merge_gate_defer`:
+  задача **остаётся на `deploy-staging`**, staging-deployer перезапускается с задержкой, **БЕЗ** отката
+  на `development` и **БЕЗ** developer-retry; restart-safe счётчик `_merge_infra_retry_count` по маркеру
+  `merge-gate infra-timeout retry` в `task_content`). Анти-над-толерантность (BR-6): детерминированно
+  **красный** re-test / конфликт → прежний `_handle_merge_gate_rollback`. Anti-loop: исчерпание
+  `merge_retest_infra_max_retries` (дефолт 2) → один **инфра-alert** (явно «НЕ дефект кода»,
+  кликабельный номер), задача НЕ уходит в `development`. Kill-switch `merge_retest_infra_tolerance_enabled`
+  off → таймаут = прежний rollback (байт-в-байт).
+- **D4 (контракт необходимости re-test):** при `premerge_rebase_always=True` re-test **пропускается**,
+  когда rebase — доказанный no-op (`merge_gate.head_sha` до==после, обе непусты = ветка уже содержит
+  свежий `origin/main`, тот же коммит уже прошёл CI+tester+staging) → лиз HELD, без re-test. Распространяет
+  на путь `=True` ту же оптимизацию, что путь `=False` уже имеет для не-behind ветки. Fail-safe: любая
+  неопределённость (`head_sha` пуст / git-ошибка) → re-test **выполняется** (BR-6/AC-3 не ослаблен).
+  Kill-switch `merge_retest_skip_when_current_enabled`.
+- **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 счётчики (`_MERGE_GATE_COUNTERS`) + 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`.
+- **Флаги** (`config.py`, дефолт = боевое): `subprocess_tree_kill_enabled`/
+  `merge_retest_infra_tolerance_enabled`/`merge_retest_infra_max_retries`/`merge_retest_infra_retry_delay_s`/
+  `merge_retest_skip_when_current_enabled` (env `ORCH_*`). Откат = выставить 4 kill-switch в `False` +
+  `ORCH_MERGE_RETEST_TIMEOUT_S=600` → байт-в-байт до-ORCH-110. Детали —
+  `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`.
+
+## Гигиена shared deploy-базы: устойчивый self-deploy `git pull` (ORCH-112)
+Багфикс инцидента **ORCH-111** (bug → escalate full-cycle): прод-self-deploy падал на шаге
+`git pull origin main` хост-хука (`scripts/orchestrator-deploy-hook.sh`) с `error: Your local changes
+to the following files would be overwritten by merge: src/config.py` — грязь, оставленная
+неуспешной/отменённой/брошенной задачей ORCH-104 в **общем** main checkout (`settings.deploy_host_repo_path`).
+Деплой вставал → ручное вмешательство; на self-hosting (один прод-инстанс на все проекты) — групповой
+риск. **Инвариант (нормативно):** shared main checkout `<host_repos_dir>/<repo>` — **deploy/worktree-management
+база, НЕ редактируемый workspace** (агенты — worktree `git_worktree`, build — worktree-контекст, fallback'и
+гейтов — read-only `git show origin/main`); локальных правок там быть не должно. Решение — **resilient-pull,
+встроенный в хук** (`--deploy`): перед `git pull` хук при грязи приводит базу к чистому актуальному
+`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 и **не** стадия).
+- **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-команду `self_deploy.build_deploy_command` только при `applies==True`, иначе `""` →
+  хук видит `CHECKOUT_HYGIENE` неустановленным → голый `git pull` 1:1 до ORCH-112), `read_report`/`alert_dirty`
+  (наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
+- **Хук-блок «2a. Resilient pull»:** между шагом «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` и `.git/worktrees/*` —
+  вне области `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`; 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` (шелл-симуляция реального
+  хука во временном git-репо без сети/прода/ssh + unit; TC-01 — обязательный регресс ORCH-111: красный до
+  фикса, зелёный после). Детали — `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`,
+  сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
+
+## Единое владение side-effectful переходами: durable-lease + expected-stage CAS (ORCH-114)
+Закрыт **корневой класс** инцидент-цепочки **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). Это **обобщение** процесс-локальной finalizer-liveness
+ORCH-113 в **durable cross-path** владение. Аддитивно, под единым kill-switch, never-raise; новый
+leaf `src/transition_lease.py`. **Инвариант:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика
+и имена `check_*` / machine-verdict-ключи / **схемы существующих таблиц** — байт-в-байт (одна
+аддитивная таблица `transition_lease`, без epoch-колонки на `tasks`); hot-path `claim_next_job`
+lease **не консультирует** (fail-open, очередь репо никогда не клинится).
+- **Два комплементарных слоя (оба под `transition_lease_enabled`):** (1) **durable transition-lease**
+  (таблица `transition_lease`) — владение на ВХОДЕ в side-effectful регион: второй актор, увидев
+  живого владельца (`is_held_by_live_owner`), не стартует тяжёлые под-гейты вовсе (предотвращение,
+  не починка постфактум); (2) **expected-stage CAS** (`db.update_task_stage_cas` ↔
+  `commit_stage_cas`) — на ЗАПИСИ стадии: проигравший гонку аборт без побочных эффектов. 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 мгновенно устаревшие → реклеймятся).
+  `main.lifespan` зовёт `recover_on_startup()` после `requeue_running_jobs`. Lease **без
+  собственного TTL**: его потолок возраста = Tier-3 backstop `reaper_max_running_s` (5400) →
+  сквозной бюджет ORCH-065/109/110/113 не тронут.
+- **Интеграция:** `advance_stage` захватывает lease на входе в side-effectful ребро
+  (`deploy-staging`/`deploy`), пишет стадию через CAS, освобождает lease в `try/finally` (на
+  любом исходе, включая исключение/откат); job-reaper `_finalizer_owns` обобщён с процесс-локального
+  ORCH-113 на durable cross-path (defer при живом владельце; Tier-3 backstop игнорирует маркер →
+  bounded reclaim; реап force-освобождает lease); reconciler F-1 и Plane-webhook (`_try_advance_stage`)
+  делают **defer** при активном lease.
+- **Флаги** (`config.py`, дефолт = боевое): `transition_lease_enabled` (env
+  `ORCH_TRANSITION_LEASE_ENABLED`; `False` → lease не пишется/не читается, CAS вырождается в прежний
+  безусловный `update_task_stage` → байт-в-байт до ORCH-114: reaper → ORCH-113 in-memory fallback,
+  reconciler/webhook skip-guard инертны), `transition_lease_repos` (env `ORCH_TRANSITION_LEASE_REPOS`;
+  CSV; **пусто → self-hosting only** — где живут необратимые рёбра; зеркало `coverage_gate_repos`,
+  enduro не затронут). Наблюдаемость — 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). Детали —
+  `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`.
+
+## Sandbox-only fail-closed изоляция записи в Plane (ORCH-117)
+Закрыт корневой класс инцидента **ORCH-114**: тест/worktree-процесс выполнил РЕАЛЬНУЮ запись
+(`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого**
+Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен
+(`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** `plane_sync` — подмена env/токена
+постфактум бесполезна, NFR-4) и **ничто** не принуждало их писать только в sandbox. Прямой
+прецедент — `tests/conftest.py::_no_telegram` (autouse-глушилка «pytest на проде слал реальные
+Telegram-сообщения»); симметричной защиты для Plane-**записи** не было. **Инвариант:** запись в
+боевой Plane-проект из любого pytest/worktree-процесса **физически невозможна** независимо от
+токена. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и
+имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента
+Plane, **не** Quality Gate и **не** стадия).
+- **Чокпоинт (D1):** новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op,
+  work_item) -> (ALLOW|BLOCK, reason)`, never-raise, по образцу `deploy_status_guard`/`serial_gate`/
+  `cancel`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state` / `add_comment` /
+  `_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и
+  **до** любого сетевого шага (ни GET, ни PATCH/POST). Все `set_issue_*`/`notify_*` сводятся к этим
+  трём примитивам → один гард ловит любой путь, включая будущие.
+- **Детект тест-процесса (D2):** `"pytest" in sys.modules` ∨ `PYTEST_CURRENT_TEST` (на момент
+  вызова). Боевой и staging рантаймы — `uvicorn src.main:app`, pytest в процесс **не** импортируют →
+  гард там строгий **no-op** (NFR-2/NFR-3); worktree `python -m pytest` (инцидентный путь)
+  гарантированно имеет pytest в `sys.modules` → ловится.
+- **Решение (D3):** default-deny. Запись из тест-процесса разрешена ⇔ одновременно (а) opt-in
+  `plane_test_write_enabled=True` **и** (б) целевой проект ∈ sandbox-allowlist
+  `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-4f9d-4190-b79f-fa06276bb27e`).
+  Нерезолвимый/пустой проект → блок (fail-closed, NFR-1). Боевой проект запрещён **даже при opt-in**
+  (allowlist sandbox-only). Внутренняя ошибка `decide` в тест-контексте → fail-CLOSED (`guard-error`).
+- **Второй слой (D5):** независимый autouse-floor `tests/conftest.py::_plane_sandbox_only` форсит
+  opt-in OFF для **всего** сьюта (по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит
+  opt-in в своей фикстуре поверх floor. Два sandbox-bound слоя → нет одиночной точки, чьё выключение
+  переоткрывает прод.
+- **Умышленно БЕЗ kill-switch прод-блока (D4, NFR-6/FR-7, anti-drift):** выключателя,
+  переоткрывающего прод-запись из pytest, **нет** — единственный реверс — sandbox-bound opt-in. Не
+  добавлять «общий kill-switch гарда» (реинтродуцирует дефект ORCH-114; reviewer ловит как ≥P1).
+- **Аудит (D7):** блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason`:
+  `prod-project-in-test`/`opt-in-disabled`/`ambiguous-target`/`guard-error`); разрешённая
+  sandbox-запись → INFO. **Флаги** (`config.py`, дефолты безопасные): `plane_test_write_enabled`
+  (env `ORCH_PLANE_TEST_WRITE_ENABLED`, дефолт `False`), `plane_test_sandbox_projects` (env
+  `ORCH_PLANE_TEST_SANDBOX_PROJECTS`, CSV). `scripts/staging_check.py` Block C (E2E в SANDBOX) —
+  отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие —
+  `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до
+  врезки, зелёный после; TC-02…TC-14). Детали —
+  `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`.
+
 ## Машинный журнал уроков (ORCH-098)
 Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
 **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих

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/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/internals.md

@@ -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
@@ -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/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/tech-architecture.md

@@ -32,6 +32,7 @@ worker запустил агента стадии → результат про
 | **Очередь задач** (`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 (слой «показать человеку», никогда не управление конвейером). |

docs/overview/tech-data-model.md

@@ -47,6 +47,7 @@ deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOC
 | `coverage_baseline` | базовая линия покрытия тестами; растёт только вверх (ratchet) |
 | `tracker_messages` | леджер всех Telegram-карточек задачи (зачистка сирот) |
 | `lessons` | машинный журнал уроков — структурированные отклонения конвейера |
+| `transition_lease` | durable-владение side-effectful переходом стадии: один владелец на задачу, liveness по pid+boot-id (предотвращает двойное применение необратимых эффектов) |
 
 Все изменения схемы — аддитивные и идемпотентные (`CREATE TABLE IF NOT EXISTS`, ensure-column
 при старте): обновление платформы не требует ручных миграций.

docs/overview/tech-observability.md

@@ -20,8 +20,9 @@
 ## Служебные страницы платформы
 
 - **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
-  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, фоновые
-  демоны. Первая точка диагностики «что сейчас происходит».
+  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, владение
+  переходами (`transition_lease`), фоновые демоны. Первая точка диагностики «что сейчас
+  происходит».
 - **`GET /metrics`** — машинный контракт для внешнего наблюдателя (версионированная схема):
   health, возраст последних событий, счётчики сбоев.
 - **`GET /health`** — живость процесса.

docs/overview/tech-pipeline.md

@@ -46,7 +46,10 @@ created → analysis → architecture → development → review → testing →
 4. `check_staging_image_fresh` — staging-образ собран из актуального кода.
 
 Это **врезки в переход, а не стадии**: они не появляются в карте `STAGE_TRANSITIONS`, а
-исполняются stage engine'ом внутри ребра. Провал любого из них — откат на доработку. На ребре
+исполняются stage engine'ом внутри ребра. Провал любого из них — откат на доработку. Исключение
+(ORCH-110): **инфра-таймаут** локального re-test merge-gate (а не детерминированный красный тест) —
+это транзиент, а не дефект кода → ограниченный повтор + отдельный инфра-alert, без отката на
+доработку и без расхода developer-retry (красный re-test/конфликт по-прежнему откатывают). На ребре
 `deploy → done` аналогичная врезка merge-verify подтверждает, что код задачи реально слит в
 `main` (слияние — только через PR-API Gitea, см. [интеграции](tech-integrations.md)).
 

docs/work-items/ORCH-109/16-post-deploy-log.md

@@ -1,14 +0,0 @@
----
-post_deploy_status: HEALTHY
-action_taken: NONE
-work_item: ORCH-109
-window_s: 900
-checks_total: 30
-checks_failed: 0
----
-
-# Post-deploy log — ORCH-021 post-deploy monitor
-
-Наблюдение прода завершено: `post_deploy_status: HEALTHY`, `action_taken: NONE`.
-
-Окно наблюдения: 900s; опросов всего: 30, из них с провалом: 0.

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 |

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

@@ -0,0 +1,83 @@
+work_item: ORCH-112
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+title: "Гигиена shared deploy-базы: устойчивость self-deploy git pull к грязному дереву"
+framework: pytest
+scope: >
+  Покрывается: устойчивость self-deploy `git pull origin main` к грязной shared deploy-базе
+  (модифицированные tracked + untracked файлы), сходимость базы к чистому origin/main после
+  failed/cancelled задач, сохранность deploy-rollback-состояния, kill-switch/область, наблюдаемость,
+  self-hosting safety. Вне покрытия: модель worktree per-task (ORCH-2, не трогается), запрет ручных
+  операций оператора, изменения STAGE_TRANSITIONS/QG_CHECKS/схемы БД (их нет).
+notes: >
+  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест воспроизведения инцидента ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ
+  после. Шелл-симуляции хука моделировать по образцу tests/test_deploy_hook_rollback_sim.py
+  (временный git-репо во временной директории, без сети/прода/ssh). Полный регресс `pytest tests/ -q`
+  обязан оставаться зелёным (NFR-5). Точные имена тест-модулей/функций уточнит разработчик; тип
+  гигиены (resilient-pull / janitor / guard) выберет архитектор — тесты сформулированы так, чтобы
+  проверять ТРЕБУЕМЫЙ ИНВАРИАНТ (база сходится к чистому origin/main, артефакты сохранены), а не
+  конкретный механизм.
+
+tests:
+  - id: TC-01
+    type: integration
+    description: "РЕГРЕСС (обязательный, red→green): shared deploy-база с локальной модификацией tracked-файла src/config.py + untracked файлами — симуляция шага git pull хука приводит базу к чистому origin/main и НЕ падает с 'local changes would be overwritten by merge' (воспроизводит ORCH-111; красный до фикса)."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-02
+    type: integration
+    description: "Untracked WIP-файлы (install_lite.py / test_install_lite.py / lite-install.example.yaml) в shared-базе не блокируют операцию и база сходится к чистому origin/main."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-03
+    type: integration
+    description: "Сохранность (NFR-2): после гигиены файлы $REPO/.deploy-prev-image-* , deploy-hook.log, sibling .deploy-state-* / .merge-lease-*.json и .git/worktrees/* НЕ удалены; rollback по .deploy-prev-image-* остаётся работоспособным."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Happy-path без регресса: на ЧИСТОЙ shared-базе шаг pull — обычный fast-forward; наблюдаемое поведение и exit-коды (0/1/2, ORCH-036) байт-в-байт прежние."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Self-hosting safety: путь гигиены никогда не оперирует веткой main на remote, не делает force-push, не рестартит прод и не сносит worktree/ветки других задач; операции ограничены настроенным путём deploy-базы (статический/поведенческий ассерт)."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Kill-switch off → деплой/pull байт-в-байт прежний (голый git pull origin main); on → активна устойчивая гигиена. Область applies(repo): self-hosting orchestrator real, прочие репо — no-op."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "Сходимость после cancel/failed: cancel_task (ORCH-090) / failed-исход не оставляет рабочих остатков в shared-базе, блокирующих будущий деплой; последующий self-deploy проходит без ручного вмешательства."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Наблюдаемость: обнаружение грязной базы и факт автоочистки (или отказ) попадают в лог; Telegram-алерт best-effort/never-raise (его сбой не валит деплой), номер задачи кликабельный."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Инвариант конвейера: STAGE_TRANSITIONS / реестр QG_CHECKS / имена и семантика check_* / machine-verdict ключи / exit-code-контракт хука — не изменены (структурный анти-регресс)."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "Документация-инвариант: docs/operations/INFRA.md и docs/architecture/README.md содержат правило «shared main checkout — deploy/worktree-management база, не workspace» (структурная сверка)."
+    module: tests/test_deploy_checkout_hygiene.py
+    expected: PASS

docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md

@@ -0,0 +1,244 @@
+---
+work_item: ORCH-112
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Гигиена shared deploy-базы — устойчивый self-deploy `git pull` через resilient-pull в хуке
+
+Work Item: **ORCH-112** — failed/cancelled task artifacts must be cleaned from shared checkout
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`** (решение
+кросс-каттинговое: новый leaf-компонент на глобальном пути прод-деплоя + изменение прод-deploy-хука).
+
+## Статус
+Proposed
+
+## Контекст
+
+Self-deploy задачи **ORCH-111** упал на шаге `git pull origin main` хост-хука с
+`error: Your local changes to the following files would be overwritten by merge: src/config.py`.
+Деплой прерван → потребовал ручного вмешательства (на self-hosting это групповой риск — встаёт
+деплой всех проектов). Грязь оставлена ранее **неуспешной/отменённой/перезапущенной** задачей
+ORCH-104 в общем (shared) checkout.
+
+Факты, сверенные с кодом:
+
+1. **Точка отказа — голый pull.** `scripts/orchestrator-deploy-hook.sh:223-226` делает `cd "$REPO"`
+   (= `settings.deploy_host_repo_path` = main clone, строка 73) и **голый** `git pull origin main`
+   **без гигиены рабочего дерева**. Любая локальная правка tracked-файла блокирует merge. Во всём
+   `src/`+`scripts/` нет ни одного `git reset --hard` / `git clean` / `git stash` для приведения базы
+   к чистому состоянию.
+
+2. **Инвариант «main clone ≠ workspace» соблюдён, но не задокументирован и не энфорснут.** Агенты
+   работают в worktree'ах `/repos/_wt/<repo>/<branch>` (`git_worktree.ensure_worktree`); `docker build`
+   берёт контекст **worktree** (`image_freshness._host_worktree_path`); fallback'и гейтов на main clone —
+   **только чтение** (`git show origin/main:...`). Значит грязь — почти наверняка ручной/брошенный WIP.
+   Но **нет механизма**, детектирующего/чистящего грязную базу, и **нет задокументированного
+   инварианта**.
+
+3. **`cancel_task` чистит worktree + remote-ветку, но не shared checkout.** `stage_engine.cancel_task`
+   (строки 2333-2342): `remove_worktree(repo, branch)` + `gitea.delete_remote_branch(repo, branch)` —
+   нулевое покрытие случая «грязная deploy-база».
+
+4. **NFR-2 (сохранность) — жёсткое ограничение.** Сверено `.gitignore` + `src/config.py`:
+   - `.env`, `data/`, `*.db`, `.venv/`, `__pycache__/`, `build/`, `.env.staging`, `.env.watchdog`,
+     `deploy/bundled/repos/` — **gitignored** → переживают `git clean -fd` (без `-x`) автоматически.
+     **Прод-секреты `.env` и БД `data/*.db` пропадут только при ошибочном `-x`.**
+   - `.deploy-prev-image-prod` (`deploy_prod_prev_image_file`) / `.deploy-prev-image-staging`,
+     а также `deploy-hook.log` (fallback-локация лога, хук строки 60-65) — **untracked, НЕ gitignored**
+     → голый `git clean -fd` их **удалит** → сломает rollback (`do_rollback`, хук строки 107-139).
+   - Sibling-состояния `<repos_dir>/.deploy-state-<repo>/...` (`self_deploy._state_dir`) и
+     `<repos_dir>/.merge-lease-<repo>.json` (`merge_gate`, строка 315) лежат под **родителем** `$REPO`
+     (`settings.repos_dir`, не `$REPO`) → `git clean` в `$REPO` их физически не достаёт.
+   - `.git/worktrees/*` (админ-записи worktree) — внутри `.git/`, `git clean` его **никогда** не трогает.
+
+«Как есть» не годится: deploy-база трактуется как «всегда чистая», что не гарантировано; устойчивость
+должна быть на стороне системы — база обязана **самовосстанавливаться** в чистый `origin/main` перед pull.
+
+## Решение
+
+### Сводка
+
+Сделать self-deploy `git pull` **устойчивым к грязной shared deploy-базе** через **resilient-pull,
+встроенный в хук** (`--deploy`): перед `git pull origin main` добавляется детерминированный
+hygiene-блок, который при обнаружении грязного дерева приводит базу к чистому актуальному `origin/main`
+(`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`), **строго сохраняя**
+rollback/лог-артефакты (NFR-2). Блок гейтится env-переменной `CHECKOUT_HYGIENE`, которую инжектит
+`self_deploy.build_deploy_command` **только** когда новый leaf `src/checkout_hygiene.py`-`applies(repo)`
+истинен (kill-switch + self-hosting-скоуп). Сходимость базы после failed/cancelled (FR-2) достигается
+этим же deploy-time self-heal — **без** расширения `cancel_task` и **без** фонового «дворника».
+Наблюдаемость — sentinel-файл от хука, который читает Phase-C finalizer и шлёт Telegram-алерт.
+
+**Инвариант (NFR-5):** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` /
+machine-verdict ключи (`deploy_status:`/`staging_status:`/`security_status:`) / схема БД /
+exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты**. Это устойчивость deploy-пути
+и политика гигиены, **не** Quality Gate и **не** стадия.
+
+### D1 — Механизм: resilient-pull в хуке (а не janitor / не container-side clean) — FR-1, AC-1/AC-2
+
+Падающий `git pull` исполняется **на хосте** внутри detached-хука (`self_deploy.build_deploy_command`
+→ ssh + setsid). Поэтому гигиена обязана выполняться **в самом хуке, на хосте, непосредственно перед
+pull** — это исключает TOCTOU-гонку, которая возникла бы при чистке shared-mount из контейнера
+параллельно бегущему detached-хуку.
+
+Новый блок «2a. Resilient pull» в `scripts/orchestrator-deploy-hook.sh` **между** шагом «1. Capture
+PREV_IMG» и шагом «2. Pull latest code», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`:
+
+```bash
+# 2a. ORCH-112: resilient pull — converge the shared deploy-base to a clean
+#     origin/main BEFORE the pull, so a dirty working tree (manual/abandoned WIP)
+#     never blocks the deploy. Gated by CHECKOUT_HYGIENE (Python kill-switch +
+#     self-hosting scope). NEVER `-x` (would delete .env/data/*.db); EXCLUDES the
+#     rollback/log artefacts (NFR-2). Best-effort: any failure is logged and the
+#     bare `git pull` below still runs (never-break).
+if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]; then
+    dirty="$(git status --porcelain 2>/dev/null || true)"
+    if [[ -n "$dirty" ]]; then
+        log "HYGIENE: dirty deploy-base detected, converging to origin/main:"
+        log "$dirty"
+        git fetch origin main           >> "$LOG" 2>&1 || log "HYGIENE: fetch failed (continuing)"
+        git reset --hard origin/main    >> "$LOG" 2>&1 || log "HYGIENE: reset failed (continuing)"
+        git clean -fd \
+            -e '.deploy-prev-image-*' \
+            -e 'deploy-hook.log' \
+            >> "$LOG" 2>&1 || log "HYGIENE: clean failed (continuing)"
+        if [[ -n "${HYGIENE_REPORT:-}" ]]; then
+            { printf 'dirty=1\n'; printf '%s\n' "$dirty"; } > "$HYGIENE_REPORT" 2>/dev/null || true
+        fi
+    else
+        log "HYGIENE: deploy-base already clean (no-op)"
+    fi
+fi
+```
+
+- `git status --porcelain` детектирует грязь; **чистая база → блок no-op** (порожний вывод) → дальше
+  обычный `git pull` (AC-4, happy-path байт-в-байт).
+- `git fetch origin main` обновляет `origin/main`-ref, чтобы `reset --hard origin/main` сходился к
+  **актуальному** источнику истины; tracked-правки (`src/config.py`) дискардятся (AC-1).
+- `git clean -fd` снимает untracked-остатки (AC-2). **`-x` запрещён** (см. D2). Последующий
+  `git pull origin main` (строка 226, **не изменяется**) становится no-op fast-forward.
+- Шаг 1 хука пишет `.deploy-prev-image-prod` **до** hygiene → exclude `-e '.deploy-prev-image-*'`
+  сохраняет rollback-снимок **этого** деплоя (AC-3).
+
+### D2 — Сохранность deploy-состояния: NFR-2 как жёсткий контракт — AC-3
+
+**INV-HYGIENE-1 (никогда `-x`).** Hygiene-`git clean` исполняется **только** как `git clean -fd`
+(без `-x`). `-x` удалил бы gitignored `.env` (прод-секреты), `data/*.db` (БД прода), `build/` — что
+катастрофично. Анти-регресс: статический тест ассертит, что hygiene-блок хука **не содержит** токена
+`-x` (TC-05/TC-09).
+
+**INV-HYGIENE-2 (явные excludes).** `.deploy-prev-image-*` и `deploy-hook.log` untracked-но-НЕ-ignored
+→ обязательны `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'`. TC-03 доказывает их неудаление и
+работоспособность rollback после гигиены.
+
+**INV-HYGIENE-3 (скоуп = `$REPO`).** Hygiene оперирует **только** рабочим деревом `$REPO`. Sibling
+`.deploy-state-*` / `.merge-lease-*.json` (под `<repos_dir>`, родитель `$REPO`) и `.git/worktrees/*`
+(внутри `.git/`) **вне** области `git clean` в `$REPO` — подтверждено топологией; гигиена их не достаёт.
+
+### D3 — Гейтинг: leaf `src/checkout_hygiene.py` + инжекция env в `build_deploy_command` — FR-5, AC-6
+
+Новый чистый never-raise leaf `src/checkout_hygiene.py` (по образцу `serial_gate`/`cancel`/`self_deploy`;
+импортирует только `config`, лениво — `qg.checks.is_self_hosting_repo`):
+
+- `applies(repo) -> bool` — `checkout_hygiene_enabled=False` → `False` (kill-switch, голый pull 1:1 до
+  ORCH-112); `checkout_hygiene_repos` (CSV) непуст → только перечисленные репо; **пусто →
+  self-hosting only** (`is_self_hosting_repo`, как `self_deploy_repos`). Локальный, без сети, **первым**.
+- `hook_env(repo, work_item_id) -> str` — возвращает префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<path>`
+  (через `shlex.quote`) **только** при `applies==True`; иначе `""`. `HYGIENE_REPORT` =
+  `os.path.join(self_deploy.host_state_dir(repo, work_item_id), "hygiene")` — в том же deploy-state
+  каталоге, что и `result` (shared mount, читается контейнером).
+- `read_report(repo, work_item_id) -> dict | None` — читает sentinel `hygiene` через
+  `self_deploy.container_state_dir`; never-raise.
+- `alert_dirty(...)` — best-effort `send_telegram` (кликабельный номер), never-raise (D5).
+- `snapshot() -> dict` — read-only блок для `GET /queue` (флаг/скоуп; опционально).
+
+`self_deploy.build_deploy_command` (строки 253-261) добавляет `checkout_hygiene.hook_env(repo, wi)` в
+`env_assignments` (одна строка-присваивание в префиксе detached-команды; точно как ORCH-058
+`EXPECTED_REVISION`). Когда `applies==False` → префикс пуст → хук видит `CHECKOUT_HYGIENE` неустановленным
+→ блок 2a — no-op → **голый `git pull` (1:1 до ORCH-112)**.
+
+Флаги в `src/config.py` (дефолт = боевое):
+- `checkout_hygiene_enabled: bool = True` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`);
+- `checkout_hygiene_repos: str = ""` (env `ORCH_CHECKOUT_HYGIENE_REPOS`; пусто → self-hosting only).
+
+### D4 — Сходимость после failed/cancelled: deploy-time self-heal достаточен; `cancel_task` НЕ расширяется — FR-2, AC-7
+
+Нормальный конвейер **не пишет** в main clone (факт 2 контекста) → грязь — ручной/брошенный WIP.
+Resilient-pull (D1) приводит базу к чистому `origin/main` **на следующем же self-deploy** → база
+**сходится** независимо от источника остатков → FR-2/AC-7 удовлетворены deploy-time self-heal.
+
+`stage_engine.cancel_task` (ORCH-090) **намеренно не расширяется** на shared-базу:
+- избегаем касания критично-оконного каскада ORCH-090 (`cancel.in_critical_window`, adr-0026);
+- избегаем container-side мутации deploy-базы (гонка с возможным параллельным деплоем);
+- расширение было бы избыточным — self-heal в D1 уже гарантирует сходимость.
+
+**Отвергнут активный «дворник» (janitor)** (фоновый актор, приводящий базу к чистоте по таймеру/событию):
+новый background-поток + дополнительная гонка с detached-деплоем и держателем merge-lease, без выигрыша
+сверх deploy-time self-heal.
+
+### D5 — Наблюдаемость: sentinel хука → Telegram-алерт finalizer'а — FR-4, AC-8
+
+Detached-хук (bash) не шлёт Telegram сам. Он пишет sentinel `hygiene` (`HYGIENE_REPORT`) в deploy-state
+каталог. Phase-C finalizer (`stage_engine`, уже читает `result` через `self_deploy.read_result`) после
+маппинга exit-code вызывает `checkout_hygiene.read_report` + `alert_dirty` (best-effort):
+структурный лог + Telegram (`send_telegram`, кликабельный `ORCH-112` через `plane_issue_link`,
+`disable_web_page_preview`). Сбой алерта **не валит** деплой (never-raise, AC-8). Опционально — блок
+`checkout_hygiene` в `GET /queue`.
+
+### D6 — Инвариант deploy-базы: документирование + de-facto энфорс — FR-3, AC-10
+
+Инвариант «`<host_repos_dir>/<repo>` (main checkout) — deploy/worktree-management база, **НЕ**
+редактируемый workspace; рабочие изменения туда не пишутся конвейером/агентами» документируется в
+`docs/operations/INFRA.md` (топология + self-hosting) и `docs/architecture/README.md` (раздел ORCH-36).
+**De-facto энфорс** — сам resilient-pull (D1): любая локальная правка дискардится при следующем деплое.
+**Отвергнут** тяжёлый рантайм-guard на горячих путях (FR-3 «где осуществимо, без изменения горячих
+путей») — он не нужен: self-heal уже обеспечивает сходимость, а guard добавил бы риск/латентность.
+
+### D7 — Скоуп пути: только `--deploy` pull, не `--build-staging`
+
+Hygiene врезается **только** в режим `--deploy` (где есть падающий `git pull`). Режим `--build-staging`
+(хук строки 166-204) собирает образ из `BUILD_CONTEXT` = **worktree** и **не делает** `git pull` →
+hygiene там не нужна и не добавляется.
+
+## Альтернативы
+
+- **`git stash` вместо `reset --hard`** — отвергнуто: накапливает stash-записи в deploy-базе, не
+  «сходится к чистому origin/main», прячет источник грязи; сложнее и менее детерминирован.
+- **Container-side Python clean перед ssh-dispatch** — отвергнуто (D1): TOCTOU-гонка с detached-хуком,
+  дублирование пути deploy-базы.
+- **Активный фоновый janitor** — отвергнуто (D4): новый актор + гонки, нулевой выигрыш над self-heal.
+- **Расширить `cancel_task` на shared-базу** — отвергнуто (D4): касание критично-оконного каскада
+  ORCH-090 + container-side мутация; избыточно.
+- **Тяжёлый рантайм-guard инварианта** — отвергнуто (D6): не нужен при self-heal, риск на горячем пути.
+- **`git clean -xfd`** — **категорически** отвергнуто (D2/INV-HYGIENE-1): удалит `.env`/`data/*.db`.
+
+## Последствия
+
+- **+** Self-deploy `git pull` устойчив к грязной shared-базе → нет ручного разруливания (BR-1, AC-1/2).
+- **+** База **сходится** к чистому `origin/main` после failed/cancelled/брошенных задач (BR-2, AC-7).
+- **+** Happy-path и kill-switch-off — байт-в-байт (BR-5, AC-4/AC-6); конвейер/БД/exit-коды не тронуты.
+- **+** Наблюдаемость: оператор видит факт автоочистки (BR-4, AC-8); инвариант задокументирован (AC-10).
+- **−** `reset --hard` **дискардит** локальные правки deploy-базы безвозвратно. Митигейшн: это **ровно**
+  инвариант (база = `origin/main`, источник истины — remote; deploy лишь fast-forward'ит); скоуп —
+  self-hosting; наблюдаемость показывает, что именно сброшено.
+- **−** Новый leaf + хук-блок + флаги = площадь сопровождения. Митигейшн: leaf минимальный, образец
+  существующих leaf'ов; never-raise; полный набор анти-регресс-тестов (`04-test-plan.yaml`).
+- **Откат:** `ORCH_CHECKOUT_HYGIENE_ENABLED=false` → деплой байт-в-байт до ORCH-112 (голый
+  `git pull origin main`); полный откат — revert leaf + хук-блок + флагов.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-112/01-brd.md`
+- TRZ: `docs/work-items/ORCH-112/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-112/03-acceptance-criteria.md`
+- Test-plan: `docs/work-items/ORCH-112/04-test-plan.yaml`
+- Infra-requirements: `docs/work-items/ORCH-112/07-infra-requirements.md`
+- Tech-risks: `docs/work-items/ORCH-112/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`
+- Сверено по коду: `scripts/orchestrator-deploy-hook.sh:73,107-139,223-226`, `src/self_deploy.py:119-135,
+  220-278`, `src/merge_gate.py:315`, `src/config.py:285-291`, `.gitignore`, `src/stage_engine.py:2333-2342`
+- Трассировка (CLAUDE.md §9 / ORCH-078): ORCH-036 (self-deploy, adr-0007), ORCH-058 (image-freshness,
+  adr-0008), ORCH-090 (cancel, adr-0026) — инварианты не нарушаются.

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

@@ -0,0 +1,59 @@
+---
+work_item: ORCH-112
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-112 — гигиена shared deploy-базы
+
+Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Затрагивается **жизненный цикл shared deploy-базы** (`<host_repos_dir>/<repo>`),
+> а не топология контейнеров/портов/томов. Контейнеры/сеть/тома — `N/A`.
+
+## I-1. Топология / окружения
+**Без изменений в составе.** Контейнеры (`orchestrator` 8500 / `orchestrator-staging` 8501), сеть
+(`network_mode: host`), порты, тома — прежние.
+
+Затрагивается **deploy-база** `<host_repos_dir>/<repo>` (= `/home/slin/repos/orchestrator` ==
+`/repos/orchestrator` в контейнере через bind-mount == `settings.deploy_host_repo_path`). **Нормативно
+закрепляется инвариант:** deploy-база — **deploy/worktree-management база, НЕ редактируемый workspace**.
+Рабочие изменения туда не пишутся конвейером/агентами (агенты — worktree `/repos/_wt/<repo>/<branch>`,
+build — worktree-контекст, fallback'и гейтов — read-only `git show origin/main`). Документируется в
+`docs/operations/INFRA.md` (топология + self-hosting) и `docs/architecture/README.md` (раздел ORCH-36).
+
+**Контракт сохранности рабочего дерева deploy-базы (NFR-2, жёсткий):** автоочистка hygiene
+(`git clean -fd`, **без** `-x`) **обязана сохранять**:
+| Артефакт | Расположение | Почему сохраняется |
+|----------|--------------|--------------------|
+| `.deploy-prev-image-prod` / `.deploy-prev-image-staging` | `$REPO/` (untracked, НЕ ignored) | rollback-снимок → `-e '.deploy-prev-image-*'` |
+| `deploy-hook.log` | `$REPO/` (fallback-лог) | аудит → `-e 'deploy-hook.log'` |
+| `.env`, `data/`, `*.db`, `build/` | `$REPO/` (gitignored) | прод-секреты/БД → переживают `git clean` **без** `-x` |
+| `.deploy-state-<repo>/*`, `.merge-lease-<repo>.json` | `<repos_dir>/` (sibling, родитель `$REPO`) | вне области `git clean` в `$REPO` |
+| `.git/worktrees/*` | `$REPO/.git/` | `git clean` никогда не трогает `.git/` |
+
+## I-2. Переменные окружения / секреты
+Две новые env-переменные (`src/config.py`, дефолт = боевое; **обновить `.env.example`**):
+| Ключ | Env | Дефолт | Назначение |
+|------|-----|--------|-----------|
+| `checkout_hygiene_enabled` | `ORCH_CHECKOUT_HYGIENE_ENABLED` | `True` | kill-switch resilient-pull; `False` → голый `git pull` (1:1 до ORCH-112) |
+| `checkout_hygiene_repos` | `ORCH_CHECKOUT_HYGIENE_REPOS` | `""` | CSV-скоуп; пусто → self-hosting only (`orchestrator`) |
+
+Внутренние env, инжектируемые в detached-хук `self_deploy.build_deploy_command` (не операторские):
+`CHECKOUT_HYGIENE=1`, `HYGIENE_REPORT=<host_state_dir>/hygiene`. Новых секретов нет.
+
+## I-3. Деплой / рестарт
+**Рестарт прод-контейнера задачей ORCH-112 — НЕ требуется и ЗАПРЕЩЁН** (self-hosting инвариант,
+CLAUDE.md). Изменение активируется штатно: новый промпт/хук/код `cat`-ается/деплоится в обычном
+self-deploy-цикле через **staging-гейт (8501)** сначала, затем `Confirm Deploy` (ORCH-059). Хук-блок
+hygiene исполняется **только** в `--deploy` режиме (где есть `git pull`); `--build-staging` собирает из
+worktree и не пуллит → не затронут. Exit-code-контракт хука (0/1/2, ORCH-036) — байт-в-байт.
+
+## I-4. CI/CD
+**Без изменений** `.gitea/workflows/`. Новый тест-модуль `tests/test_deploy_checkout_hygiene.py`
+(шелл-симуляция хука во временном git-репо, без сети/прода/ssh — образец
+`tests/test_deploy_hook_rollback_sim.py`) исполняется обычным `pytest tests/ -q`. Полный регресс обязан
+оставаться зелёным (NFR-5).

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

@@ -0,0 +1,42 @@
+---
+work_item: ORCH-112
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-112 — гигиена shared deploy-базы
+
+Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации resilient-pull и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **`git clean -x`** ошибочно добавлен → удалит gitignored `.env` (прод-секреты) / `data/*.db` (БД прода) / `build/` — катастрофа на прод-deploy-базе | Низ. | **Выс.** | INV-HYGIENE-1 (ADR D2): только `git clean -fd`, **никогда** `-x`. Статический анти-регресс-тест ассертит отсутствие `-x` в hygiene-блоке хука (TC-05/TC-09); явная рамка в ADR + INFRA |
+| TR-2 | Неверный/отсутствующий `-e` exclude → `git clean -fd` удалит `.deploy-prev-image-*` → сломан rollback (`do_rollback`) | Сред. | **Выс.** | INV-HYGIENE-2: обязательные `-e '.deploy-prev-image-*'` + `-e 'deploy-hook.log'`; TC-03 доказывает неудаление и работоспособность rollback; шаг 1 хука пишет prev-image **до** hygiene |
+| TR-3 | Сбой шага hygiene (fetch/reset/clean) маскирует/ухудшает исход деплоя | Низ. | Сред. | never-break (ADR D1): каждая git-операция `\|\| log "...continuing"`; деплой продолжается к голому `git pull`; sentinel-отчёт фиксирует факт; fail-safe, исход не хуже текущего |
+| TR-4 | `reset --hard origin/main` безвозвратно дискардит локальные правки deploy-базы, которые кто-то «нужными» считал | Низ. | Сред. | Это **ровно** инвариант: deploy-база = `origin/main` (источник истины — remote); deploy лишь fast-forward'ит. Наблюдаемость (D5) показывает сброшенное; скоуп — self-hosting; документировано (INFRA/README) |
+| TR-5 | Гонка: hygiene на хосте чистит mount, пока контейнер читает deploy-базу | Низ. | Низ. | Деплой сериализован (serial-gate ORCH-088, один деплой за раз); hygiene в detached-хуке непосредственно перед pull; нормальный конвейер deploy-базу не читает в этот момент (worktree-изоляция). TOCTOU между `status` и `reset` пренебрежимо (один процесс) |
+| TR-6 | Скоуп-leak: hygiene затронет прочие репо / синхронный деплой агентом | Низ. | Сред. | `applies(repo)` (локально, первым): пусто → self-hosting only; инжекция env только на self-deploy-пути (сам self-hosting-скоупленный, `self_deploy_applies`); TC-06 |
+| TR-7 | Стейл `origin/main` (fetch не выполнился) → `reset --hard` сходится к устаревшему коммиту | Низ. | Низ. | `git fetch origin main` перед reset; при сбое fetch — `\|\| log` + продолжение; последующий `git pull origin main` (строка 226, не тронута) до-тянет недостающее; deploy промоутит build-once `SOURCE_IMAGE` (артефакт не зависит от дерева main clone) |
+| TR-8 | Расширение объёма (касание `cancel_task`/`STAGE_TRANSITIONS`/QG) при реализации | Низ. | Сред. | ADR D4 явно запрещает расширение `cancel_task`; NFR-5 байт-в-байт; TC-09 структурно ассертит неизменность контрактов; трассировка ORCH-036/058/090 |
+
+## Сводный вывод
+
+Доминирующий класс — **деструктивная гигиена рядом с прод-rollback-состоянием** (TR-1/TR-2): низкая
+вероятность, высокое влияние, **полностью** снимается контрактом сохранности (INV-HYGIENE-1/2) + явными
+тестами (TC-03/TC-05/TC-09). Изменение аддитивно, под kill-switch (`checkout_hygiene_enabled`, дефолт
+`True`; off → байт-в-байт до ORCH-112), never-raise, self-hosting-скоупленное, **не трогает**
+`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схему БД/exit-code-контракт хука.
+
+**Эскалация:** вводится новый leaf-компонент (`src/checkout_hygiene.py`) на глобальном пути прод-деплоя
++ правка прод-deploy-хука + сквозной ADR adr-0044 → рекомендуется лейбл **`arch:major-change`** для
+reviewer-внимания (изменение safety-critical, в прод-deploy-пути). Возврат в анализ **не** требуется:
+ТЗ удовлетворяется без нарушения принципов архитектуры (всё в Docker на одном сервере, без новых
+зависимостей/очередей/k8s, без рестарта прода вне staging-гейта). Остаточный риск для прод-конвейера —
+**низкий** при соблюдении INV-HYGIENE-1/2/3.

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

@@ -0,0 +1,123 @@
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-112
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-112
+version: 1
+---
+
+# Review ORCH-112 — deploy-base checkout-hygiene (resilient-pull)
+
+## Summary
+
+Багфикс инцидента **ORCH-111** (bug → escalate full-cycle): прод-self-deploy падал на голом
+`git pull origin main` хост-хука из-за грязного shared main checkout (остатки ORCH-104 от ORCH-104).
+Реализован **resilient-pull в хуке** (`--deploy`): перед pull при обнаружении грязи база сводится к
+чистому `origin/main` (`git fetch` + `git reset --hard origin/main` + скоупленный `git clean -fd`),
+под kill-switch, never-raise, скоуп self-hosting.
+
+Проверены все 4 оси. Реализация **точно соответствует** ADR-001 (D1–D7) и сквозному adr-0044, все
+10 критериев приёмки (AC-1…AC-10) покрыты содержательными тестами, документация (golden source)
+обновлена в том же PR, инварианты конвейера/БД/exit-code-контракт хука — байт-в-байт не тронуты.
+
+**Вердикт: APPROVED.** P0/P1/P2 findings отсутствуют.
+
+### Что сверено (доказательная база)
+
+**Ось 1 — соответствие ТЗ (02-trz) / критериям (03-acceptance-criteria):**
+- FR-1 (устойчивый pull) / AC-1 — ✅ хук-блок «2a. Resilient pull» + регресс **TC-01** (зелёный после
+  фикса) и **TC-01b** (тот же грязный base без гигиены → `would be overwritten by merge`, репро инцидента).
+- FR-1 / AC-2 (untracked WIP) — ✅ **TC-02** (остатки сняты, не протекают в деплой).
+- NFR-2 / AC-3 (сохранность) — ✅ **TC-03** (`.deploy-prev-image-*`, `deploy-hook.log`, gitignored
+  `.env`/`data/*.db`, sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*` — на месте) +
+  **TC-05** статический контракт (`git clean -fd`, **никогда `-x`**, явные excludes).
+- BR-5 / AC-4 (happy-path) — ✅ **TC-04** (чистая база → no-op + fast-forward, exit-коды байт-в-байт).
+- NFR-1 / AC-5 (self-hosting safety) — ✅ скоуп `$REPO`, `reset --hard origin/main` (не локальная
+  догадка), нет push/force-push (TC-05 ассерт).
+- FR-5 / AC-6 (kill-switch + обратимость) — ✅ **TC-06** (off → инертно; пустой CSV → self-hosting only;
+  enduro не затронут).
+- FR-2 / AC-7 (сходимость после cancel/failed) — ✅ **TC-07** (deploy-time self-heal; `cancel_task`
+  корректно НЕ расширён — D4).
+- FR-4 / AC-8 (наблюдаемость) — ✅ **TC-08** (`read_report`/`alert_dirty` never-raise) + врезка в
+  `run_deploy_finalizer` (sentinel → Telegram, best-effort).
+- NFR-5 / AC-9 (инвариант конвейера/БД) — ✅ **TC-09** + проверка дифа: `STAGE_TRANSITIONS`/`QG_CHECKS`/
+  `check_*`/machine-verdict/схема БД/exit-code-контракт хука (0/1/2) не тронуты.
+- BR-3 / AC-10 (документация) — ✅ см. ось 4.
+
+**Ось 2 — соответствие ADR:**
+- ADR-001 D1–D7 реализованы дословно: resilient-pull в хуке (не janitor/не container-side, D1),
+  NEVER `-x` + excludes (D2), leaf `checkout_hygiene.py` + инжекция env в `build_deploy_command` (D3),
+  `cancel_task` не расширяется / janitor не вводится (D4), sentinel → finalizer-alert (D5), docs (D6),
+  только `--deploy` не `--build-staging` (D7, подтверждено размещением блока между шагами 1 и 2 пути
+  `--deploy`).
+- Трассировка (ORCH-078): правка `build_deploy_command` (маркеры ORCH-101/ORCH-058) — чисто аддитивна
+  (одно env-присваивание после `EXPECTED_REVISION`), инвариант image-freshness не сломан; ORCH-036
+  exit-code-контракт и ORCH-090 cancel-каскад не нарушены; INV-4 (никогда push/force-push `main`)
+  соблюдён.
+
+**Ось 3 — качество кода:**
+- Leaf чистый, never-raise, ленивые импорты (`self_deploy`/`qg.checks`/`notifications`) — leaf-инвариант
+  доказан **TC-05** (`leaf_is_a_pure_leaf`). Docstrings на всех публичных функциях. `shlex.quote` на
+  инжектируемом пути. Env-проводка консистентна с существующим паттерном `result`-sentinel
+  (`initiate_deploy` пред-создаёт `container_state_dir` → запись `hygiene` гарантированно проходит).
+- **Багфикс-трек регресс-тест (ORCH-019 / BR-4):** присутствует — **TC-01** (фиксатор дефекта,
+  зелёный после фикса) в паре с **TC-01b** (репродукция инцидента: голый pull аборт без гигиены).
+- Все ссылки на API существуют (`notifications.link_for`/`send_telegram`, `self_deploy.host_state_dir`/
+  `container_state_dir`, `qg.checks.is_self_hosting_repo`). `repo`/`work_item_id`/`task_id` в скоупе
+  финализатора.
+- Тесты содержательные: 17 TC (шелл-симуляция реального хука в герметичном git-репо без сети/прода/ssh
+  + unit). Прогон: **17/17 зелёные**; смежные deploy/config/stage_engine/frontmatter — **200/200 зелёные**;
+  docs/hardcode/canon — **101/101 зелёные**.
+
+**Ось 4 — документация (golden source):**
+- `src/` изменён → документация обновлена **в том же PR**: `docs/operations/INFRA.md` (инвариант
+  deploy-база ≠ workspace), `docs/architecture/README.md` (раздел ORCH-112 design), `CHANGELOG.md`,
+  `CLAUDE.md` (паспортный блок), `.env.example` (новые ключи), ADR-001 + сквозной
+  `docs/architecture/adr/adr-0044`. Консистентны между собой и с кодом.
+- Обзорные доки (ORCH-079): открытые пункты `README.md` «Известные ограничения» (Telegram 48h /
+  intra-repo deps / batch-автоном) этим PR **не закрываются** → обновление не требуется. ✅
+- Витрина системы (ORCH-011): фикс — внутренняя устойчивость deploy-пути, **не** новая
+  стадия/гейт/агент/интеграция/способность → витрина `docs/overview/` не затронута;
+  `tests/test_system_docs.py` зелёный. ✅
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice-to-have (не блокирует, на усмотрение)
+- `tests/test_deploy_checkout_hygiene.py::test_tc05_hook_clean_is_never_destructive` ассертит
+  `assert "-x" not in code` по **всем** исполняемым строкам хука. Текущий хук токена `-x` не содержит
+  (тест зелёный), но будущая легитимная конструкция (`set -x`, `[ -x file ]`, `chmod +x`) ложно уронит
+  ассерт. Можно сузить проверку до строки(ок) `git clean` — но это страховка критичного инварианта
+  INV-HYGIENE-1, поэтому строгость намеренна и допустима. Не блокирует.
+
+## Документация
+
+**Статус: обновлена полностью, в том же PR (golden source соблюдён).**
+
+| Документ | Статус |
+|----------|--------|
+| `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md` | ✅ заведён (architecture, после escalate full-cycle) |
+| `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md` | ✅ сквозной ADR заведён |
+| `docs/operations/INFRA.md` | ✅ инвариант deploy-база ≠ workspace + страховка resilient-pull |
+| `docs/architecture/README.md` | ✅ раздел ORCH-112 (design) |
+| `CHANGELOG.md` | ✅ запись [Unreleased] |
+| `CLAUDE.md` | ✅ паспортный блок |
+| `.env.example` | ✅ `ORCH_CHECKOUT_HYGIENE_ENABLED` / `_REPOS` |
+| `docs/overview/` (витрина, ORCH-011) | ➖ не требуется (внутренний deploy-fix, не новая способность) |
+| `README.md` «Известные ограничения» (ORCH-079) | ➖ не требуется (открытые пункты не закрываются) |
+
+Необновлённой документации при изменённом `src/` **нет** → ось 4 пройдена, P0 по документации
+отсутствует.

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

@@ -0,0 +1,71 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-112
+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-112
+---
+
+# Test Report — ORCH-112
+
+Гигиена shared deploy-базы: устойчивость self-deploy `git pull` к грязному дереву
+(багфикс инцидента ORCH-111). Review-вердикт: **APPROVED** (`12-review.md`).
+
+## Окружение
+- 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-112-bug-failed-cancelled-task-arti/`
+- Ветка: `feature/ORCH-112-bug-failed-cancelled-task-arti`
+- Дата: 2026-06-15
+
+## Smoke API (read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — задача 102 ORCH-112 на стадии `testing`, ветка совпадает |
+| `GET /queue` | PASS — блок `serial_gate` присутствует (ORCH-088); `auto_labels` присутствует |
+
+Блок `checkout_hygiene`/`serial_gate`/`auto_labels` — все на месте в полезной нагрузке `/queue`,
+регресса смока нет.
+
+## Покрытие ТЗ (TC из 04-test-plan.yaml ↔ 03-acceptance-criteria)
+
+| TC ID | Описание | AC | Тест | Результат |
+|-------|----------|----|------|-----------|
+| TC-01 | Регресс ORCH-111: грязный tracked `src/config.py` + untracked → база сходится к чистому `origin/main`, pull не падает (red→green) | AC-1 | `test_tc01_dirty_tracked_edit_converges_and_deploys` (+ `test_tc01b_bare_pull_aborts_without_hygiene_documents_incident`) | PASS |
+| TC-02 | Untracked WIP-файлы не блокируют и не протекают в деплой | AC-2 | `test_tc02_untracked_wip_does_not_block` | PASS |
+| TC-03 | Сохранность `.deploy-prev-image-*`/`deploy-hook.log`/sibling `.deploy-state-*`/`.merge-lease-*.json`/`.git/worktrees/*` (NFR-2) | AC-3 | `test_tc03_preserves_rollback_and_sibling_artifacts` | PASS |
+| TC-04 | Happy-path: чистая база → fast-forward, exit-коды байт-в-байт | AC-4 | `test_tc04_clean_base_fast_forwards_no_op_hygiene` | PASS |
+| TC-05 | Self-hosting safety: нет операций над `main`/force-push/рестарта прода; `git clean -fd` (никогда `-x`); leaf чист | AC-5 | `test_tc05_hook_clean_is_never_destructive`, `test_tc05_leaf_is_a_pure_leaf` | PASS |
+| TC-06 | Kill-switch off → инертно; пустой CSV → self-hosting only; скоуп репо | AC-6 | `test_tc06_kill_switch_off_is_inert`, `test_tc06_empty_csv_is_self_hosting_only`, `test_tc06_csv_scope_limits_repos` | PASS |
+| TC-07 | Сходимость после cancel/failed → следующий self-deploy чист | AC-7 | `test_tc07_convergence_then_next_deploy_is_clean` | PASS |
+| TC-08 | Наблюдаемость: `read_report`/`alert_dirty`, Telegram best-effort/never-raise | AC-8 | `test_tc08_read_report_none_when_absent`, `test_tc08_read_report_parses_dirty_sentinel`, `test_tc08_alert_dirty_never_raises_on_send_failure` | PASS |
+| TC-09 | Инвариант конвейера: `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/exit-code-контракт хука не тронуты | AC-9 | `test_tc09_pipeline_contracts_untouched`, `test_tc09_hook_exit_code_contract_intact` | PASS |
+| TC-10 | Документация-инвариант: INFRA.md и architecture/README.md содержат правило «main checkout — deploy-база, не workspace» | AC-10 | `test_tc10_docs_state_deploy_base_invariant` | PASS |
+
+Каждый TC из `04-test-plan.yaml` выполнен и сопоставлен с критерием приёмки `03-acceptance-criteria.md`.
+TC-01 (обязательный red→green регресс инцидента ORCH-111) — зелёный; парный TC-01b документирует
+аборт голого pull без гигиены.
+
+## Вывод pytest
+
+### Целевой модуль `tests/test_deploy_checkout_hygiene.py`
+```
+collected 17 items
+... 17 passed, 1 warning in 7.51s
+```
+
+### Полный регресс `pytest tests/ -q`
+```
+2018 passed, 1 warning in 342.01s (0:05:42)
+```
+(единственный warning — Pydantic V2 deprecation в `src/config.py:8`, существующий, не связан с задачей)
+
+## Итог
+PASS — все 10 TC (17 тест-функций) зелёные, полный регресс 2018/2018 зелёный, smoke API OK
+(`/health`, `/status`, `/queue` с блоками `serial_gate` и `auto_labels`). Задача готова к переходу
+на `deploy-staging`.

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

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

@@ -0,0 +1,38 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-112
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T12:11:26Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment (`orchestrator-staging`,
+port 8501), executed inside the container via the canonical path
+`/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
+(ORCH-048: B6 registry-isolation reads `.env.staging` from the running instance's own process-env).
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+- REAL failed: none
+- SANDBOX_INFRA failed (waived, ORCH-061): C9a, C9b
+
+The two failing checks (C9a "Branch appears in orchestrator-sandbox", C9b "Analyst job enqueued in
+staging queue") are the known sandbox-infra checks that depend on SANDBOX bot accounts being project
+members — not on the pipeline. With every REAL check green, the suite waives them and exits 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) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+```
+
+Block A (SMOKE): A1 /health 200, A2 /queue 200, A3 ORCH_STAGING=true — all PASS.
+Block B (ACCESS): B4 Plane sandbox, B5 Gitea push, B6 registry isolation — all PASS.
+Block C (E2E, stub): C7 create issue PASS, C8 trigger pipeline PASS, C9a/C9b waived sandbox-infra.
+
+Staging gate passed. Task may advance to the `deploy` stage.

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: job-reaper must not re-run deploy-staging finalization while original finalizer is alive
+
+Work Item ID: ORCH-113
+
+## Description
+
+TBD

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

@@ -0,0 +1,167 @@
+---
+work_item: ORCH-113
+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-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
+
+> **Багфикс-трек → эскалация в полный цикл (`escalate: full-cycle`).** Задача помечена `Bug`, но
+> сама баг-карточка явно требует «анализ контракта reaper, статуса `running/finalizing`, длительности
+> grace и идемпотентности edge-гейтов» (см. «Ограничение» в бизнес-запросе) — это решение с
+> несколькими проектными альтернативами (liveness-heartbeat finalizer'а / явный sub-state
+> `finalizing` / per-stage grace / ownership-lease на edge-гейты) и нетривиальными инвариантами
+> self-hosting, затрагивающее **задокументированный сквозной инвариант ORCH-065** (контракт
+> живости reaper, `adr-0011`). По правилу ORCH-019 (ADR-001 D5) выпускается **полный** analysis-пакет,
+> а трек эскалируется (`POST /bug-fast-track/escalate?work_item=ORCH-113`) → задача проходит стадию
+> `architecture`. Прецедент — родственные задачи того же инцидент-кластера: ORCH-110 / ORCH-111
+> («bug → escalate full-cycle»).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+Оркестратор — self-hosting инструмент: его прод-контейнер обслуживает конвейер **всех** проектов из
+одного инстанса с общей БД и общей очередью и дорабатывает сам себя. Фоновый демон **job-reaper**
+(`src/job_reaper.py`, ORCH-065) — страховочный слой: он добивает «зомби»-job'ы, чей монитор умер,
+не записав терминальный статус. Его Tier-2-ветка (процесс агента завершился — `agent_runs.exit_code`
+записан, — но job всё ещё `running`) **неоднозначна**: это одновременно «монитор умер посреди
+финализации» И «живой монитор ещё финализирует». Reaper разрешает неоднозначность таймером —
+**finalization grace** `reaper_finalize_grace_s = 300` (db.py:1345-1348, job_reaper.py:36-44): если
+`exit_code` записан дольше grace — трактует ситуацию как **мёртвый монитор** и сам до-водит стадию.
+
+**Корневая ошибка контракта:** grace=300с построен на задокументированном допущении, что после записи
+`finished_at` монитор делает лишь «git commit/push (+PR), БАГ-8-проверку и сетевые Plane-комментарии —
+**секунды…десятки секунд**, и ТОЛЬКО ПОТОМ `_try_advance_stage`». Для ребра `deploy-staging → deploy`
+это **неверно**: `_try_advance_stage` (`launcher._monitor_agent`, строка 998) синхронно, в потоке
+монитора, прогоняет **весь набор тяжёлых детерминированных edge-под-гейтов** —
+`security` → `merge-gate` (полный локальный re-test, бюджет `merge_retest_timeout_s = 900`) →
+`coverage` (ещё один полный `pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание
+staging). Это **минуты**, и весь этот объём идёт **ПОСЛЕ** штампа `finished_at` (launcher:861) и
+**ДО** `_finalize_job` (launcher:1003). `finished_age_s` reaper меряет именно от `finished_at`
+(db.py:1360) — то есть от **начала** финализации. Итог: пока живой монитор ещё внутри edge-гейтов,
+reaper по истечении 300с считает его мёртвым и **независимо запускает тот же тяжёлый набор edge-гейтов
+повторно**.
+
+**Установленные факты инцидента (ORCH-111, deployer job `1914`, run_id `683`):**
+- deployer завершился `exit_code=0` и записал `15-staging-log.md` со `staging_status: SUCCESS`;
+- после выхода агента job `1914` оставалась `running`, т.к. монитор ещё финализировал стадию;
+- финализация `deploy-staging` заняла **дольше 300с** (полный локальный re-test + coverage);
+- reaper после `reaper_finalize_grace_s=300` трактовал это как умерший monitor и повторно вызвал
+  gate-driven advance (`_reap_exit0` → `_gate_driven_advance` → `_try_advance_stage` → `advance_stage`);
+- edge-гейты `deploy-staging` исполнились **повторно**: `security-gate`, `merge-gate`, rebase, полный
+  локальный re-test;
+- один из повторных re-test стал **красным**: `3 failed, 1916 passed, 1 warning, 14 errors in 444.79s`;
+- задача была откатана `deploy-staging → development` (+ ложный developer-retry), хотя **параллельно**
+  исходный prod-deploy/finalizer дошёл до `deploy_status: SUCCESS`, **PR #130 был смержен**, задача
+  перешла `deploy → done`.
+
+**Симптом:** две ветки системы расходятся по состоянию **одной** задачи — одна повторно откатывает
+`deploy-staging`, другая успешно завершает deploy. Гонка + ложный rollback + ложный developer-retry +
+шумные алерты + несогласованное состояние Plane/БД.
+
+**Почему существующие гарды reaper не спасли:** атомарный claim-before-act
+(`reap_running_job(... WHERE status='running')`, job_reaper.py:280) защищает **строку job** от
+двойного терминального флипа, но **не защищает побочное исполнение edge-гейтов**: reaper вызывает
+`_gate_driven_advance → advance_stage`, который и прогоняет тяжёлые под-гейты, **до/независимо** от
+монитора. Гонка — в **side-effectful исполнении edge-гейтов**, а не в флипе строки. Дешёвая
+read-only пред-проверка `_gate_is_green('deploy-staging')` читает лишь `check_staging_status`
+(frontmatter `15-staging-log.md` = `SUCCESS`, зелёный) → reaper уверенно идёт в тяжёлый advance.
+Tier-3 backstop (`reaper_max_running_s = 5400`) при этом не срабатывает — баг чисто в Tier-2 grace.
+
+## 2. Объём (scope)
+
+### В объёме
+- Reaper **не должен** повторно исполнять тяжёлую финализацию `deploy-staging`/merge-gate (security /
+  merge-gate / локальный re-test / coverage / image-freshness), пока исходный monitor/finalizer ещё
+  **жив** или пока edge-гейты для этого job/stage **уже исполняются**.
+- Повторная обработка завершившегося-но-ещё-`running` job на `deploy-staging` должна быть
+  **идемпотентной**: без второго локального re-test/merge-gate для того же job/stage без **строгого
+  владения состоянием**.
+- Согласование Tier-2 grace (`reaper_finalize_grace_s`) с **фактической** wall-clock-длительностью
+  финализации `deploy-staging` ИЛИ замена таймерного критерия живости на сигнал, переживающий
+  «долгую, но живую» финализацию.
+- Сохранение основной функции reaper (ORCH-065): реально **мёртвый** finalizer на `deploy-staging`
+  по-прежнему добивается за ограниченное время.
+
+### Вне объёма
+- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / семантики любого `check_*` / machine-verdict ключей /
+  схемы существующих таблиц (правки — только аддитивные).
+- Инфра-толерантность merge-gate к таймауту re-test и tree-kill осиротевших pytest-процессов — это
+  **ORCH-110** (союзная задача того же инцидента; не дублировать).
+- Починка конкретных «мигающих» тестов, давших `3 failed … 14 errors`.
+- Полный редизайн reaper или модели финализации монитора.
+- **Выбор механизма** решения (heartbeat / sub-state `finalizing` / per-stage grace / ownership-lease)
+  — это **архитектурное решение** (06-adr), не зона аналитика.
+
+## 3. Заинтересованные стороны
+- **Owner / Слава** — заказчик исправления, держатель инвариантов self-hosting.
+- **Конвейер всех проектов** (orchestrator self-hosting + enduro-trails) — общий инстанс/БД/очередь:
+  ложный rollback и гонка состояния касаются стабильности платформы в целом.
+- **Операторы** — получатели алертов; именно их будят ложные «merge-gate FAILED / rolled back».
+- **Архитектор** — принимает решение по механизму владения/живости (06-adr) после эскалации.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Reaper **не должен** запускать второй прогон edge-гейтов ребра `deploy-staging → deploy`
+  (security / merge-gate / re-test / coverage / image-freshness) для job, чей исходный
+  monitor/finalizer **ещё жив**.
+- **BR-2** — Повторная обработка завершившегося-но-`running` job на `deploy-staging` **идемпотентна**:
+  не более **одного** локального re-test/merge-gate на пару (job, stage) без строгого владения
+  состоянием; второй актор, не владеющий состоянием, **не исполняет** побочных шагов.
+- **BR-3** — Критерий живости Tier-2 должен учитывать **реальную** wall-clock-длительность
+  финализации `deploy-staging` (включающую полный набор edge-гейтов), ИЛИ живость должна определяться
+  сигналом, который **переживает** долгую-но-живую финализацию (не одним `finished_age_s`).
+- **BR-4** — Реально **мёртвый** монитор (краш посреди финализации `deploy-staging`) по-прежнему
+  должен добиваться reaper'ом за ограниченное время — основная функция ORCH-065 **сохраняется**;
+  фикс не превращает reaper в no-op для `deploy-staging`.
+- **BR-5** — После согласования у задачи — **единственное** консистентное состояние: **никакого**
+  ложного отката `deploy-staging → development` и **никакого** ложного developer-retry после
+  фактически успешного deploy; ветки системы сходятся, не расходятся.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1** — Контракт reaper сохранён: **never-raise** на единицу работы, **kill-switch**,
+  fail-safe; reaper остаётся наблюдателем-страховкой, не Quality Gate'ом.
+- **NFR-2** — `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
+  существующих таблиц — **байт-в-байт**; любые БД-правки — только **аддитивные** (`_ensure_column` /
+  `CREATE TABLE IF NOT EXISTS`).
+- **NFR-3** — Self-hosting-безопасно: фикс **никогда** не рестартит/не роняет прод-контейнер и
+  **никогда** не пушит/force-push'ит `main`.
+- **NFR-4** — Обратная совместимость и обратимость: поведение reaper для **не-`deploy-staging`** стадий
+  и путь добивания **мёртвого** монитора сохранены; выключенный kill-switch → строго прежнее
+  поведение; раскат обратим.
+- **NFR-5** — Restart-safe: in-memory состояние reaper сбрасывается при рестарте (это покрыто
+  стартовым `requeue_running_jobs`); любой **новый** маркер владения/живости должен быть либо durable,
+  либо безопасно восстановимым после рестарта.
+- **NFR-6** — Сквозной инвариант ORCH-065/109/110 сохранён: `reaper_max_running_s (5400) >
+  Σ(deploy-staging gate-work) + grace` (Tier-3 backstop). Любая правка grace/таймаутов не должна его
+  нарушить.
+
+## 6. Допущения и ограничения
+- Задача помечена `Bug`; ввиду архитектурной природы — **эскалация в полный цикл** (нужен ADR +
+  анализ тех-рисков архитектором: 06-adr / 07 / 08 / 10).
+- Инстанс общий для всех проектов (общая БД/очередь) — фикс не должен вносить регрессию для
+  enduro-trails и не-self репо.
+- Выбор конкретного механизма владения/живости — за архитектором; настоящий BRD фиксирует **требования
+  и инварианты**, а не реализацию.
+- Источник истины о «жив ли finalizer» сегодня отсутствует: pid агента в Tier-2 **уже мёртв** в обоих
+  случаях (`proc.wait()` вернулся), а живости **потока-монитора/финализатора** система не наблюдает —
+  это и есть пробел, который закрывает фикс.
+
+## 7. Критерии успеха
+Reaper при живом finalizer'е `deploy-staging` не запускает второй прогон edge-гейтов и не откатывает
+задачу; повторная обработка идемпотентна; мёртвый finalizer по-прежнему добивается; после фикса нет
+ложного rollback/developer-retry и расхождения состояния; инварианты ORCH-065/NFR-2 целы; полный
+регресс `tests/` зелёный. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Гонка/расхождение состояния** (наблюдалось): повторный откат после успешного deploy. **Высокий.**
+- **Над-толерантность**: слишком «доверять живости» → реально мёртвый finalizer не добивается (регресс
+  ORCH-065). Сдерживается BR-4 + Tier-3 backstop.
+- **Нарушение сквозного бюджета** при правке grace/таймаутов (NFR-6).
+Детальная проработка и контрмеры — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,106 @@
+---
+work_item: ORCH-113
+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-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **требования к изменению**, выведенные из BRD и фактического кода. Конкретный
+> механизм (heartbeat живости / sub-state `finalizing` / per-stage grace / ownership-lease на
+> edge-гейты), точные имена символов/колонок/флагов и порядок врезок — **архитектурное решение**
+> (06-adr), не зона аналитика. Модули-плейсхолдеры ниже выровнены под манифест `PIPELINE_DOCS.md`.
+
+## 1. Сводка изменения
+
+Сделать повторную обработку reaper'ом завершившегося-но-ещё-`running` job на стадии `deploy-staging`
+**идемпотентной и владеющей состоянием**: пока исходный monitor/finalizer **жив** (или edge-гейты для
+пары `(job, stage)` уже исполняются), reaper **не должен** независимо запускать второй прогон edge-
+под-гейтов ребра `deploy-staging → deploy` (security / merge-gate / локальный re-test / coverage /
+image-freshness) и **не должен** на этом основании откатывать задачу. Корень — ошибочное допущение
+Tier-2 finalization-grace (`reaper_finalize_grace_s=300`), что финализация после штампа `finished_at`
+длится «секунды…десятки секунд»; для `deploy-staging` она длится **минуты** (полный re-test + coverage
++ rebuild), потому что `_try_advance_stage` (тяжёлые edge-гейты) выполняется **после** штампа
+`finished_at` и **до** `_finalize_job`. Фикс должен дать reaper'у способ отличить «живой, долго
+финализирующий монитор» от «мёртвого монитора» и обеспечить строгое владение исполнением edge-гейтов.
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/job_reaper.py` | изменить — Tier-2-ветка `_reap_job` (строки ~197-209), `_reap_known_outcome` / `_reap_exit0` / `_gate_driven_advance`: ввести проверку живости/владения перед side-effectful re-drive `advance_stage` для `deploy-staging`; при живом finalizer'е — **defer**, не reap |
+| `src/agents/launcher.py` | изменить (вероятно) — `_monitor_agent`: место/порядок штампа `finished_at` (строка ~861) относительно `_try_advance_stage` (строка ~998) и/или эмиссия durable-сигнала «finalizer жив/финализирует» перед запуском тяжёлых edge-гейтов |
+| `src/db.py` | изменить (вероятно) — `get_running_jobs` (строки ~1337-1367, источник `finished_age_s`) и/или аддитивная колонка владения/живости (`_ensure_column`, паттерн `tasks.cancelled_at`); `reap_running_job` — без изменения контракта атомарного флипа |
+| `src/config.py` | изменить (вероятно) — kill-switch фикса и/или per-stage/finalize-aware grace; сохранить сквозной инвариант `reaper_max_running_s > Σ gate-work + grace` (NFR-6) |
+| `src/stage_engine.py` | **только чтение/ссылка** — `advance_stage` ребро `deploy-staging` (строки ~321-383): эталон того, какие edge-гейты дублируются. Изменение нежелательно; идемпотентность предпочтительно решать на стороне reaper/launcher |
+
+> Точный набор затронутых модулей и распределение логики (reaper-only vs launcher-сигнал vs db-колонка)
+> архитектор фиксирует в 06-adr. Аналитик фиксирует, что центр тяжести правки — `src/job_reaper.py`.
+
+## 3. Функциональные требования
+
+### FR-1 — Распознавание живости финализирующего монитора (BR-1, BR-3)
+Reaper в Tier-2 для стадии `deploy-staging` должен распознавать ситуацию «процесс агента завершён,
+но monitor/finalizer ещё **жив** и исполняет edge-гейты» и **не** трактовать её как мёртвый монитор по
+одному лишь `finished_age_s >= reaper_finalize_grace_s`. Сигнал живости должен переживать долгую
+(минуты) финализацию `deploy-staging`. **Инвариант:** живой finalizer **никогда** не reap'ается.
+
+### FR-2 — Идемпотентность и строгое владение edge-гейтами (BR-2)
+Для пары `(job, stage)` на `deploy-staging` тяжёлый прогон edge-гейтов (security / merge-gate /
+локальный re-test / coverage / image-freshness) исполняется **не более одного раза одновременно**:
+актор, не владеющий состоянием, **не** запускает второй `advance_stage`/re-test/merge-gate. Текущий
+атомарный claim-before-act (`reap_running_job ... WHERE status='running'`) защищает только флип строки
+job — требование расширяет защиту на **side-effectful исполнение edge-гейтов**.
+
+### FR-3 — Согласование grace/бюджета (BR-3, NFR-6)
+Длительность finalization-grace (или заменяющий её сигнал живости) должна покрывать фактический
+wall-clock финализации `deploy-staging` = Σ(security + merge re-test `merge_retest_timeout_s=900` +
+coverage + image rebuild). Любая правка grace/таймаутов сохраняет сквозной инвариант ORCH-065/109/110:
+`reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace`.
+
+### FR-4 — Сохранение добивания мёртвого finalizer'а (BR-4)
+Реально **мёртвый** monitor/finalizer на `deploy-staging` (краш посреди финализации, сигнал живости
+отсутствует/протух) по-прежнему добивается reaper'ом за ограниченное время по существующему контракту
+(retry в пределах бюджета, иначе `failed` + Telegram; Tier-3 backstop как крайний предохранитель).
+Reaper не становится no-op для `deploy-staging`.
+
+### FR-5 — Отсутствие расхождения состояния (BR-5)
+Исключить одновременный ложный откат `deploy-staging → development` и успешное завершение
+`deploy → done` для одной задачи. После согласования у задачи — единственное консистентное
+терминальное/стадийное состояние; ложный developer-retry не инкрементируется. Под-гейт merge-verify
+(`deploy → done`, ORCH-071) остаётся единственным choke-point'ом в `done` — он **не** ослабляется.
+
+## 4. Изменения API
+Новых публичных эндпоинтов **не требуется**. Допустима **аддитивная read-only** наблюдаемость в
+`GET /queue` (например, отметка «deploy-staging finalize in-progress / deferred-by-liveness» в блоке
+`reaper`) — без изменения существующих ключей ответа.
+
+## 5. Изменения схемы БД
+Возможна **аддитивная** колонка владения/живости finalizer'а (например, durable-таймштамп
+«finalizing heartbeat» или owner-токен на job/agent_run), вводимая идемпотентно через `_ensure_column`
+(паттерн `tasks.cancelled_at` / `tasks.track`). Существующие таблицы/колонки/индексы и их семантика —
+**без изменений**. Точная необходимость и форма — за архитектором (06-adr / 08-data-requirements).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** `QG_CHECKS` и любой `check_*` (включая `check_staging_status`, `check_branch_mergeable`,
+`check_coverage_gate`, `check_security_gate`, `check_staging_image_fresh`, `check_deploy_status`) — не
+трогаются ни по составу, ни по семантике, ни по machine-verdict ключам. Багфикс — свойство страховочного
+демона/финализатора, **не** Quality Gate.
+
+## 7. Совместимость / регресс
+- **Kill-switch:** фикс под выделенным флагом; `False` → строго прежнее поведение reaper (нулевая
+  регрессия).
+- **Область:** поведение для **не-`deploy-staging`** стадий и путь добивания мёртвого монитора —
+  сохранены; self-hosting-only/скоуп репо согласовать с существующими leaf-паттернами (если вводится
+  per-repo разрез).
+- **Обратимость:** раскат обратим выключением флага (+ откатом значений grace/таймаутов к дефолтам).
+- **Never-raise / restart-safe / self-hosting (NFR-1/3/5):** любой сбой нового пути живости/владения
+  деградирует безопасно (reaper-тик продолжается); новый durable-маркер восстановим после рестарта;
+  фикс не рестартит прод и не пушит `main`.
+- **Сквозной инвариант (NFR-6):** `reaper_max_running_s > Σ gate-work + grace` сохранён.
+- **Анти-регресс:** структурный тест-гард (см. `04-test-plan.yaml`), полный `tests/` остаётся зелёным.

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

@@ -0,0 +1,98 @@
+---
+work_item: ORCH-113
+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-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
+провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория и тестам.
+
+---
+
+## AC-1 — Нет второго прогона edge-гейтов при живом finalizer'е
+
+**Условие:** job на `deploy-staging` с `exit_code=0`, `finished_age_s >= reaper_finalize_grace_s`, но
+исходный monitor/finalizer ещё **жив** (сигнал живости присутствует).
+- **PASS:** reaper **не** вызывает `_gate_driven_advance`/`advance_stage` для этого job; второй прогон
+  security / merge-gate / локального re-test / coverage / image-freshness **не** запускается; reaper
+  логирует defer.
+- **FAIL:** reaper запускает повторный `advance_stage` / любой edge-под-гейт, пока finalizer жив.
+
+---
+
+## AC-2 — Идемпотентность и строгое владение состоянием
+
+**Условие:** монитор финализирует `deploy-staging` и параллельно срабатывает reaper-тик для того же
+job/stage.
+- **PASS:** тяжёлый прогон edge-гейтов (merge-gate / локальный re-test) исполняется **ровно один раз**
+  для пары `(job, stage)`; актор без владения состоянием не выполняет побочных шагов (мерж/re-test/
+  rollback).
+- **FAIL:** второй локальный re-test/merge-gate запускается для того же job/stage без владения
+  состоянием (двойное исполнение edge-гейтов).
+
+---
+
+## AC-3 — Мёртвый finalizer по-прежнему добивается
+
+**Условие:** monitor/finalizer на `deploy-staging` реально **умер** посреди финализации (сигнал
+живости отсутствует/протух), job завис в `running`.
+- **PASS:** reaper за ограниченное время добивает job по существующему контракту (retry в пределах
+  бюджета, иначе `failed` + Telegram; Tier-3 backstop как предохранитель); reaper для `deploy-staging`
+  **не** превращён в no-op.
+- **FAIL:** мёртвый finalizer на `deploy-staging` не добивается reaper'ом (зомби-job блокирует очередь).
+
+---
+
+## AC-4 — Нет ложного отката и расхождения состояния после успешного deploy
+
+**Условие:** сценарий инцидента ORCH-111 — долгая (> grace) финализация `deploy-staging` при зелёном
+`staging_status: SUCCESS`, deploy/finalizer параллельно доходит до `deploy_status: SUCCESS` / merge PR.
+- **PASS:** задача **не** откатывается `deploy-staging → development` параллельной reaper-веткой;
+  developer-retry **не** инкрементируется ложно; у задачи единственное консистентное
+  терминальное/стадийное состояние (сходимость, не расхождение).
+- **FAIL:** задача откатана `deploy-staging → development` и/или начислен ложный developer-retry, в то
+  время как deploy фактически успешен; ветки состояния расходятся.
+
+---
+
+## AC-5 — Инварианты и контракт reaper сохранены
+
+**Условие:** аудит диффа и поведения при выключенном kill-switch.
+- **PASS:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
+  существующих таблиц — **байт-в-байт**; БД-правки только аддитивные (`_ensure_column` /
+  `CREATE TABLE IF NOT EXISTS`); reaper остаётся never-raise per unit; выключенный флаг → прежнее
+  поведение; правки не рестартят прод и не пушат `main`; сквозной инвариант
+  `reaper_max_running_s > Σ gate-work + grace` (ORCH-065/109/110) сохранён.
+- **FAIL:** изменены `STAGE_TRANSITIONS`/`QG_CHECKS`/семантика `check_*`/machine-verdict ключи или
+  схема существующих таблиц; reaper может бросить исключение из тика; флаг `False` меняет поведение;
+  нарушен сквозной бюджетный инвариант.
+
+---
+
+## AC-6 — Обязательный регресс-тест и зелёный полный прогон
+
+**Условие:** запуск тест-сюита репозитория.
+- **PASS:** добавлен регресс-тест инцидента ORCH-111 (TC-05 в `04-test-plan.yaml`), **красный** на
+  коде до фикса и **зелёный** после; полный `pytest tests/ -q` зелёный.
+- **FAIL:** регресс-теста нет, либо он зелёный и до фикса (не воспроизводит баг), либо полный регресс
+  `tests/` красный.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / BR-3 / FR-1 |
+| AC-2 | BR-2 / FR-2 |
+| AC-3 | BR-4 / FR-4 |
+| AC-4 | BR-5 / FR-5 |
+| AC-5 | NFR-1 / NFR-2 / NFR-3 / NFR-6 / FR-3 |
+| AC-6 | BR-1…BR-5 (регресс-доказательство) |

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

@@ -0,0 +1,76 @@
+work_item: ORCH-113
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+title: "job-reaper не повторяет финализацию deploy-staging при живом finalizer'е: живость + идемпотентность + строгое владение"
+framework: pytest
+scope: >
+  Покрывает: распознавание живого финализирующего монитора в Tier-2 reaper на стадии deploy-staging
+  (не reap по одному finished_age_s); идемпотентность и строгое владение исполнением edge-гейтов
+  (не более одного локального re-test/merge-gate на (job, stage)); сохранение добивания РЕАЛЬНО
+  мёртвого finalizer'а; отсутствие ложного отката deploy-staging -> development и расхождения состояния
+  после успешного deploy; сохранение инвариантов (STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/
+  схема существующих таблиц байт-в-байт; never-raise; kill-switch; сквозной бюджет ORCH-065/109/110).
+  Вне покрытия: инфра-толерантность merge-gate к таймауту re-test и tree-kill осиротевших процессов
+  (ORCH-110); починка конкретных мигающих тестов; поведение enduro/не-self репо (только проверяется
+  отсутствие регрессии / no-op).
+notes: >
+  TC-05 — ОБЯЗАТЕЛЬНЫЙ регресс-тест инцидента ORCH-111 (deployer job 1914 / run_id 683): КРАСНЫЙ на
+  коде до фикса (reaper при живом долгом finalizer'е deploy-staging независимо запускает второй прогон
+  edge-гейтов и откатывает задачу), ЗЕЛЁНЫЙ после фикса. Подпроцессы (pytest re-test / coverage /
+  docker), сеть, Plane и Gitea — мокаются; «живой/мёртвый finalizer» и «долгая финализация > grace»
+  моделируются управляемо, без обращения наружу. Полный регресс tests/ должен оставаться зелёным.
+  Точные имена символов/колонок/флагов уточняет архитектор (06-adr); модули-плейсхолдеры выровнены под
+  манифест PIPELINE_DOCS.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "Tier-2 reaper на deploy-staging: exit_code=0 и finished_age_s >= grace, но finalizer ЖИВ (сигнал живости присутствует) -> reaper НЕ вызывает _gate_driven_advance/advance_stage; второй прогон edge-гейтов не запускается; логируется defer (AC-1/FR-1)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Строгое владение: при попытке повторной обработки того же (job, stage) актор без владения состоянием НЕ исполняет merge-gate/локальный re-test/advance (claim/ownership проигран -> ноль побочных эффектов), AC-2/FR-2."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Мёртвый finalizer на deploy-staging (сигнал живости отсутствует/протух) -> reaper по-прежнему добивает job за ограниченное время по существующему контракту (retry в пределах бюджета, иначе failed+Telegram; Tier-3 backstop срабатывает) — reaper не no-op для deploy-staging (AC-3/FR-4)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Идемпотентность под гонкой: монитор финализирует deploy-staging и параллельно срабатывает reaper-тик -> тяжёлый прогон edge-гейтов (merge-gate/re-test) исполняется РОВНО ОДИН раз для (job, stage); нет второго re-test и нет ложного rollback (AC-2/AC-4/FR-2/FR-5)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-05
+    type: integration
+    description: "ОБЯЗАТЕЛЬНЫЙ регресс ORCH-111: долгая (> grace) финализация deploy-staging при staging_status=SUCCESS, deploy/finalizer параллельно доходит до успеха/merge PR -> reaper НЕ откатывает deploy-staging -> development и НЕ инкрементирует developer-retry; у задачи единственное консистентное состояние. КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после (AC-4/FR-5)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Регресс-гард совместимости: kill-switch выключен ИЛИ стадия не deploy-staging -> поведение reaper байт-в-байт прежнее (Tier-2 grace, claim-before-act, dead-pid/Tier-3 пути неизменны), NFR-4/AC-5."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Сквозной инвариант бюджета (ORCH-065/109/110): при дефолтном конфиге reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace; любая правка grace/таймаутов фикса инвариант не нарушает (NFR-6/AC-5)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "never-raise: сбой/исключение в новом пути распознавания живости/владения деградирует безопасно — reaper-тик не падает, прочие job обрабатываются, прод не трогается, main не пушится (NFR-1/NFR-3/AC-5)."
+    module: tests/test_orch113_reaper_finalizer_liveness.py
+    expected: PASS

docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md

@@ -0,0 +1,158 @@
+---
+work_item: ORCH-113
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Reaper Tier-2 — in-memory ownership-маркер финализации `deploy-staging` (живой finalizer не реапится)
+
+Work Item: **ORCH-113** — BUG: job-reaper повторно запускает финализацию `deploy-staging`, пока жив исходный finalizer
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`** (решение кросс-каттинговое — уточняет контракт reaper ORCH-065/adr-0011).
+
+## Статус
+Proposed
+
+## Контекст
+
+Оркестратор self-hosting: один инстанс, общая БД/очередь, `max_concurrency=1`. Финальный статус job
+(`done`/`queued`/`failed`/`cancelled`) пишется **только** в живом процессе
+(`launcher._monitor_agent → _finalize_job`). Сверено по коду:
+
+- `_monitor_agent` штампит `agent_runs.finished_at`/`exit_code` **ПЕРВЫМ** (`launcher.py:861`), затем
+  делает git commit/push (+PR), usage-комментарии Plane (секунды…десятки секунд), затем
+  `_try_advance_stage` (`launcher.py:998`) и лишь потом `_finalize_job` (`launcher.py:1003`).
+- На ребре `deploy-staging → deploy` `_try_advance_stage → advance_stage` синхронно, **в потоке
+  монитора**, прогоняет тяжёлый набор edge-под-гейтов (`stage_engine.py:327–368`):
+  `security` → `merge-gate` (полный локальный re-test, бюджет `merge_retest_timeout_s=900`) →
+  `coverage` (`pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание staging) — это
+  **минуты**, и весь объём идёт **после** штампа `finished_at` и **до** `_finalize_job`.
+- Reaper Tier-2 (`job_reaper._reap_job`, `job_reaper.py:197–209`) меряет `finished_age_s` от
+  `agent_runs.finished_at` (`db.get_running_jobs`, `db.py:1360`) = **от начала** финализации. По
+  истечении `reaper_finalize_grace_s=300` он трактует живого, долго финализирующего монитора как
+  мёртвого и независимо запускает тот же тяжёлый advance (`_reap_exit0 → _gate_driven_advance →
+  _try_advance_stage → advance_stage`).
+
+Дешёвая read-only пред-проверка `_gate_is_green('deploy-staging')` читает лишь `check_staging_status`
+(frontmatter `15-staging-log.md` = `SUCCESS`) → reaper уверенно идёт в тяжёлый advance. Атомарный
+claim-before-act (`reap_running_job ... WHERE status='running'`) защищает **флип строки** job, но **не
+side-effectful исполнение edge-гейтов**: монитор не claim'ит строку перед `advance_stage`, поэтому
+монитор и reaper выполняют `advance_stage` **параллельно**.
+
+**Инцидент ORCH-111 (deployer job 1914, run_id 683):** финализация `deploy-staging` заняла >300с;
+reaper повторил edge-гейты; один повторный re-test стал красным (`3 failed … 14 errors in 444.79s`);
+задача ложно откатана `deploy-staging → development` (+ ложный developer-retry), **параллельно**
+исходный finalizer довёл deploy до `SUCCESS` и смержил PR #130 (`deploy → done`). Состояние раздвоилось.
+
+Источника истины «жив ли finalizer» сегодня нет: pid агента в Tier-2 уже мёртв в **обоих** случаях
+(`proc.wait()` вернулся), а живость **потока-монитора** система не наблюдает. Per-stage grace,
+покрывающая Σ финализации (`Σ ≈ 4160с`), невозможна без нарушения сквозного бюджета ORCH-065/109/110
+`reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace (≈4460)`.
+
+**Решающий факт (проверен):** монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без
+`--workers`; `_monitor_agent` стартует `threading.Thread`, `launcher.py:661`; reaper — daemon-поток,
+`main.py:144`), разделяющие одну SQLite-БД. Значит, живость finalizer'а можно определить **in-memory**.
+Рестарт покрыт существующим `requeue_running_jobs()` (`running → queued`), который в `main.lifespan`
+вызывается (`main.py:59`) **до** старта reaper (`main.py:144`).
+
+## Решение
+
+### Сводка
+Ввести **процесс-локальный реестр владения финализацией**: живой монитор регистрирует «я финализирую
+job X», а reaper в Tier-2 на стадии `deploy-staging` **не реапит** job, чьё владение активно, и
+переходит к Tier-3 backstop. Реестр in-memory — авторитетен в рамках одного процесса/БД; рестарт
+покрыт `requeue_running_jobs`. Grace и `reaper_max_running_s` не меняются → сквозной бюджет цел. Под
+глобальным kill-switch; **нулевое** изменение схемы БД и контрактов.
+
+### D1 — Leaf `src/finalizer_liveness.py` (владение, FR-2)
+Новый чистый процесс-локальный модуль (паттерн `serial_gate`/`coverage_gate`: never-raise, без сети/БД):
+- `mark(job_id, run_id, stage)` — зарегистрировать активную финализацию;
+- `clear(job_id)` — снять;
+- `is_active(job_id) -> bool` — есть ли живое владение;
+- `snapshot() -> dict` — read-only для наблюдаемости.
+
+Состояние — `{job_id: {"run_id", "stage", "started_ts"}}` + `threading.Lock`. Собственного TTL нет —
+ограничение по времени даёт Tier-3 (см. D3). Все функции изолированы `try/except` → дефолт
+(`is_active` при ошибке → `False`, консервативно: не блокировать добивание).
+
+### D2 — Эмиссия владения в `launcher._monitor_agent` (FR-1)
+`mark(job_id, run_id, stage)` вызывается **сразу после** штампа `exit_code` (`launcher.py:864`, самый
+ранний момент, когда reaper переходит в Tier-2; до этого pid агента жив → Tier-1 защищает). Хвост
+финализации (git push … `_try_advance_stage` … `_finalize_job`) оборачивается в `try/finally`, в
+`finally` — `clear(job_id)`. Так исключение **в потоке монитора** гарантированно снимает владение →
+reaper добивает (FR-4). Только при `job_id is not None` (legacy `launch()` с `job_id=None` не в
+`get_running_jobs`). Гибель **всего процесса** → рестарт → `requeue_running_jobs` → реестр пуст
+(restart-safe без durable, NFR-5).
+
+### D3 — Консультация reaper, scoped + Tier-3 backstop (FR-3, FR-4)
+В `job_reaper._reap_job`, Tier-2-ветка (`exit_code` записан, `finished_age >= grace`): **перед**
+`_reap_known_outcome` — если `settings.reaper_finalizer_liveness_enabled` **И** стадия задачи
+(`_task_meta`) `== "deploy-staging"` **И** `finalizer_liveness.is_active(job_id)` → **defer** (лог +
+счётчик), **не** реапить через Tier-2, провалиться к Tier-3. Иначе — прежний путь
+(`_reap_known_outcome; return`), байт-в-байт. **Tier-3** (`age >= reaper_max_running_s`) маркер
+**игнорирует** — добивает всегда (ограниченное время; бюджет `5400 > Σ+grace ≈ 4460` гарантирует, что
+легитимная финализация завершится до 5400 → ложного Tier-3-реапа живого finalizer'а нет).
+
+### D4 — Скоуп и kill-switch (NFR-4)
+Только глобальный `reaper_finalizer_liveness_enabled` (`config.py`, env
+`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`). **Без** per-repo разреза: баг общий для
+любого репо со стадией `deploy-staging` (enduro тоже); per-repo оставил бы баг активным для части
+репо. Это сознательный отход от leaf-паттерна `*_repos` (он для **гейтов, действующих на репо**; здесь
+— наблюдатель-безопасность глобального демона). `False` → reaper никогда не консультирует маркер →
+поведение байт-в-байт прежнее; стадии `!= deploy-staging` не консультируются → не тронуты.
+
+### D5 — Наблюдаемость (TZ §4)
+Счётчик `finalizer_defers_total` + размер `finalizer_liveness.snapshot()` в блоке `reaper`
+`GET /queue`. Существующие ключи ответа не меняются; новых эндпоинтов нет.
+
+### Инварианты
+`STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема существующих
+таблиц — **байт-в-байт**; **нулевое** изменение схемы БД; reaper остаётся never-raise per-unit;
+`reaper_finalize_grace_s` и `reaper_max_running_s` **не меняются** (NFR-6 цел); фикс не рестартит прод
+и не пушит `main` (NFR-3). Merge-verify (`deploy → done`, ORCH-071) — единственный choke-point в
+`done`, не ослабляется (FR-5).
+
+## Альтернативы
+- **Per-stage grace, покрывающая Σ** — отвергнуто: нарушает бюджет `5400 > Σ+grace` (Σ≈4160 ⇒ grace
+  пришлось бы <1240, не покрывает Σ); таймер — это и есть источник бага.
+- **Durable-колонка (finalizing-heartbeat / owner-токен)** — отвергнуто: один процесс/одна БД →
+  in-memory авторитетно; рестарт покрыт requeue; блокирующий re-test (900с) не может бить периодический
+  heartbeat из того же потока; durable добавляет миграцию и запись ради нулевой выгоды.
+- **Sub-state `finalizing` в `jobs.status`** — отвергнуто: меняет семантику статуса, который читают
+  `claim_next_job`/`requeue_running_jobs`/`reconciler`/`reaper` (`WHERE status='running'`) — нарушение
+  NFR-2 и высокий радиус поражения.
+- **Lease-файл на `(job, stage)` (как merge-lease)** — отвергнуто: тяжелее (файловый I/O, TTL,
+  reclaim), дублирует merge-lease; in-memory достаточно при одном процессе; TTL возвращает таймер-проблему.
+- **Флип job из `running` до тяжёлых гейтов** — отвергнуто: ломает `get_running_jobs`/метрики и
+  restart-requeue (краш мид-гейт оставит job non-running и нереквью'имым).
+
+## Последствия
+- **+** Устранены повторный прогон edge-гейтов, ложный откат `deploy-staging → development` и
+  расхождение состояния при живом долгом finalizer'е; идемпотентность edge-гейтов через владение
+  (AC-1/AC-2/AC-4).
+- **+** Реально мёртвый/застрявший finalizer добивается (finally-clear → Tier-2; иначе Tier-3);
+  основная функция reaper ORCH-065 сохранена (AC-3).
+- **+** Нулевое изменение схемы и контрактов; сквозной бюджет ORCH-065/109/110 не тронут (AC-5).
+- **−** Гарантия владения валидна при **одном процессе/одной БД** (проверено: один uvicorn-воркер);
+  ввод `--workers>1` потребует durable-сигнала — зафиксировано в `10-tech-risks.md` (TR-3).
+- **−** Окно «штамп `finished_at` → `mark()`» (git push) маркером не покрыто — закрыто прежним
+  grace=300 (окно ≪ grace), TR-2.
+- **Откат:** `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED=false` → reaper байт-в-байт прежний (маркер
+  по-прежнему пишется монитором, но не консультируется — инертен). Полный откат — удаление leaf +
+  двух врезок.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-113/01-brd.md`
+- TRZ: `docs/work-items/ORCH-113/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-113/03-acceptance-criteria.md`
+- Test-plan: `docs/work-items/ORCH-113/04-test-plan.yaml`
+- Сквозной ADR: `docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`
+- Базовые ADR: `adr-0011` (reaper/lease ORCH-065), `adr-0040` (timeout-бюджеты ORCH-109),
+  `adr-0042` (merge-gate re-test ORCH-110)
+- Сверено по коду: `src/job_reaper.py`, `src/agents/launcher.py` (`_monitor_agent`/`_try_advance_stage`),
+  `src/db.py` (`get_running_jobs`/`requeue_running_jobs`), `src/stage_engine.py` (`advance_stage` ребро
+  `deploy-staging`), `src/config.py` (`reaper_*`), `src/main.py` (`lifespan`)
+</content>

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

@@ -0,0 +1,40 @@
+---
+work_item: ORCH-113
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-113 — reaper finalizer-liveness ownership
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable / информационный. Топология **не меняется**; ниже — только конфиг и операционные
+> инварианты, которые сопровождающий обязан удержать.
+
+## Изменения топологии
+**N/A.** Ни новых сервисов/контейнеров, ни портов, ни томов, ни сетевых правил. Решение целиком внутри
+процесса `orchestrator` (новый leaf + две врезки в существующие потоки monitor/reaper).
+
+## Новый конфиг (env)
+| Ключ | Дефолт | Назначение |
+|------|--------|-----------|
+| `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED` | `true` | Kill-switch. `false` → reaper байт-в-байт прежний (маркер пишется, но не консультируется). Откат фикса = установить `false`. |
+
+Существующие `reaper_finalize_grace_s` (300) и `reaper_max_running_s` (5400) — **не меняются**.
+`.env.example` пополнить новым ключом (дефолт = боевое значение, паттерн ORCH-101: пустой `.env` ⇒
+прежнее поведение).
+
+## Операционные инварианты (сопровождение)
+- **Одно-процессная модель — несущий инвариант.** Авторитетность in-memory реестра владения держится
+  на том, что монитор и reaper — потоки **одного** uvicorn-процесса. CMD/команда compose **не должны**
+  получать `uvicorn --workers>1` без перевода сигнала в durable (см. `10-tech-risks.md` TR-3, ADR-001).
+  Сверено: `Dockerfile:65`, `docker-compose.yml:36` (prod), `docker-compose.yml:123` (staging) — без
+  `--workers`.
+- **Сквозной бюджет ORCH-065/109/110** `reaper_max_running_s (5400) > Σ(deploy-staging gate-work)+grace
+  (≈4460)` остаётся в силе и фиксом не затрагивается (TR-4).
+- **Self-hosting-страховка:** обкатка — на staging (8501, изолированная БД) до прод-деплоя; деплой
+  орка — только через статус «Confirm Deploy». Фикс не рестартит прод и не пушит `main`.
+</content>

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

@@ -0,0 +1,43 @@
+---
+work_item: ORCH-113
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным: ORCH-113 — reaper finalizer-liveness ownership
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable / информационный (гейтом не парсится).
+
+## Изменения схемы БД
+
+**N/A — нулевое изменение схемы.** Сознательное архитектурное решение (ADR-001 / adr-0043): сигнал
+владения финализацией — **in-memory** (leaf `src/finalizer_liveness.py`), а не durable-колонка. Ни
+новых таблиц, ни новых колонок, ни индексов; `init_db()` / `_ensure_column` не трогаются. Схема
+существующих таблиц (`jobs`, `agent_runs`, `tasks`, …) и их семантика — **байт-в-байт** (NFR-2/AC-5).
+
+## Новые/изменённые сущности
+
+**Процесс-локальный реестр владения** (не БД): `finalizer_liveness` хранит
+`{job_id: {"run_id", "stage", "started_ts"}}` под `threading.Lock`. Запись/снятие — живой
+монитор-поток (`launcher._monitor_agent`); чтение — reaper-поток (`job_reaper`). Ключ — `jobs.id`
+(существующая сущность). Никаких новых персистентных данных.
+
+## Совместимость данных / миграции
+
+- **Миграций нет** — нечего мигрировать (нет схемных изменений); общая прод-БД (self-hosting +
+  enduro-trails) не затрагивается.
+- **Restart-safe без durable (NFR-5):** in-memory реестр сбрасывается при рестарте процесса, что
+  **безопасно** по существующему контракту: `main.lifespan` вызывает `requeue_running_jobs()`
+  (`running → queued`, `main.py:59`) **до** старта reaper (`main.py:144`). После рестарта нет ни одного
+  `running`-job, ссылающегося на потерянный маркер → отсутствие маркера корректно (нет живых
+  finalizer'ов). Гибель **потока** монитора (не процесса) покрыта `try/finally`-снятием маркера; гибель
+  **процесса** → рестарт → requeue.
+- **Авторитетность in-memory** опирается на одно-процессную модель (один uvicorn-воркер, общая
+  SQLite-БД; проверено: CMD без `--workers`). Условие задокументировано как инвариант сопровождения —
+  при вводе `--workers>1` сигнал должен стать durable (см. `10-tech-risks.md` TR-3).
+</content>

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

@@ -0,0 +1,37 @@
+---
+work_item: ORCH-113
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-113 — reaper finalizer-liveness ownership
+
+Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Над-толерантность:** маркер «жив» застрял (не снят) → реально мёртвый finalizer не добивается, зомби клинит очередь (регресс ORCH-065). | Низ. | Выс. | `try/finally`-снятие в `_monitor_agent` (исключение потока снимает владение); гибель процесса → рестарт → `requeue_running_jobs`. **Tier-3 backstop игнорирует маркер** и добивает при `age >= reaper_max_running_s=5400` → ограниченное время гарантировано (FR-4/AC-3). Покрытие — TC-03. |
+| TR-2 | **Окно без владения** между штампом `finished_at` (launcher:861) и `mark()` (после exit_code, launcher:864): reaper мог бы реапнуть в этом окне. | Низ. | Сред. | Окно = git push/PR/Plane-комментарии (секунды…десятки секунд) ≪ `reaper_finalize_grace_s=300` → прежний grace покрывает его; маркер ставится самым ранним возможным моментом Tier-2 (до этого pid агента жив → Tier-1 защищает). |
+| TR-3 | **Многопроцессность:** при `uvicorn --workers>1` монитор и reaper окажутся в разных процессах → in-memory реестр не разделяется → возможна двойная финализация. | Низ. | Выс. | Сейчас CMD без `--workers` (проверено: `Dockerfile:65`, `docker-compose.yml:36`). Инвариант сопровождения зафиксирован в ADR-001/adr-0043 и 08-data-requirements: ввод `--workers>1` ⇒ перевести сигнал в durable (heartbeat-колонка) — отдельная задача. Анти-дрейф можно усилить структурным тестом (нет `--workers` в CMD). |
+| TR-4 | **Нарушение сквозного бюджета** ORCH-065/109/110 при правке grace/таймаутов. | Оч. низ. | Выс. | Решение **не меняет** `reaper_finalize_grace_s` (300) и `reaper_max_running_s` (5400) — инвариант `5400 > Σ(deploy-staging gate-work)+grace ≈ 4460` тривиально цел; покрытие — TC-07/AC-5. |
+| TR-5 | **Гонка чтения/записи** реестра (монитор пишет, reaper читает). | Низ. | Сред. | `threading.Lock` вокруг операций реестра; `is_active`/`snapshot` атомарны под локом; never-raise → ошибка чтения = `False` (консервативно, не блокирует добивание). Покрытие — TC-02/TC-04/TC-08. |
+| TR-6 | **Регресс не-deploy-staging / выключенного флага** (NFR-4): фикс случайно меняет прежние пути reaper. | Низ. | Сред. | Консультация маркера gated `enabled AND stage=="deploy-staging"`; Tier-1/Tier-3/exit≠0/claim-before-act не трогаются; `False` → reaper байт-в-байт прежний. Покрытие — TC-06. |
+| TR-7 | **Ложный regression-тест** TC-05: зелёный и до фикса (не воспроизводит баг). | Сред. | Сред. | TC-05 моделирует «живой долгий finalizer > grace» управляемо (моки подпроцессов/сети); обязан быть **красным до** фикса и **зелёным после** (AC-6). Reviewer/tester проверяют красноту на базе. |
+
+## Сводный вывод
+
+Доминирующий класс — **над-толерантность** (TR-1) и **многопроцессная авторитетность** (TR-3); оба
+имеют низкую вероятность и закрыты соответственно Tier-3 backstop'ом (без правки бюджета) и
+зафиксированным инвариантом одно-процессной модели. Решение аддитивно, под kill-switch, без изменения
+схемы/контрактов и без правки сквозного бюджета. Эскалация `arch:major-change` **не требуется**
+(нет новой стадии/QG, нет изменения схемы БД, центр тяжести — один leaf + две точечные врезки).
+Остаточный риск для прод-конвейера (self-hosting) — **низкий**; полностью обратим выключением
+`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`.
+</content>

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

@@ -0,0 +1,86 @@
+---
+verdict: APPROVED
+work_item: ORCH-113
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-113
+version: 1
+---
+
+# Review ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
+
+## Summary
+
+Фикс инцидента ORCH-111 реализован чисто и полно. Введён процесс-локальный реестр владения
+финализацией (`src/finalizer_liveness.py`, never-raise leaf по паттерну `serial_gate`/`coverage_gate`):
+монитор `mark()`-ит владение сразу после штампа `exit_code` и `clear()`-ит его в `finally` хвоста
+финализации; reaper в Tier-2 при `stage=="deploy-staging"` И активном владении делает **defer** вместо
+повторного `advance_stage`, проваливаясь к Tier-3 backstop (который маркер игнорирует → застрявший
+finalizer всё равно добивается).
+
+Проверено по всем 4 осям; блокирующих findings нет.
+
+- **ТЗ:** FR-1…FR-5 реализованы; AC-1…AC-6 покрыты тестами `tests/test_orch113_reaper_finalizer_liveness.py`
+  (TC-01…TC-08). Схема БД — **нулевое** изменение (выбран in-memory реестр), что строже допущенной ТЗ §5
+  «аддитивная колонка». API §4 (read-only ключи в `GET /queue`) и QG §6 (не трогать) — соблюдены.
+- **ADR:** реализация байт-в-байт соответствует ADR-001 / сквозному adr-0043 (D1–D5). Трассировка
+  сохранена: авторитет Tier-3 (adr-0011/ORCH-065) и сквозной бюджет `reaper_max_running_s (5400) >
+  Σ(gate-work)+grace` (ORCH-109/110) не нарушены — зафиксировано регресс-тестом TC-07. Ни один
+  маркированный инвариант не сломан.
+- **Качество кода:** хвост `_monitor_agent` вынесен в `_run_monitor_finalization` **дословно** —
+  подтверждено `git diff -w` (+49/−0, нулевое изменение логики); все переменные, на которые ссылается
+  извлечённое тело, — параметры/локальные/модульные (нет риска `NameError`, проверено вручную).
+  never-raise во всех публичных функциях и врезках. Обязательный регресс-тест багфикс-трека (ORCH-019
+  BR-4 / coverage ORCH-027) присутствует: TC-05 по построению КРАСНЫЙ до фикса (assert `calls == []`,
+  который pre-fix reaper нарушил бы вызовом `_try_advance_stage`) и ЗЕЛЁНЫЙ после.
+- **Документация:** обновлены в том же PR — `docs/architecture/README.md` (описание Job-reaper +
+  раздел Tier-2 + список kill-switch + ссылки на ADR), `docs/architecture/internals.md` (детализация
+  Tier-2), `CHANGELOG.md`, ADR-001 (work-item) и сквозной adr-0043; все номерные доки задачи (00–04,
+  06-adr, 07, 08, 10) на месте.
+
+**Проверка прогона:** `pytest tests/ -q` → **2001 passed**, 0 failures (AC-6); целевой файл — 13 passed.
+
+## Findings
+
+### P0 — Blocker
+- _нет_
+
+### P1 — Must fix
+- _нет_
+
+### P2 — Should fix
+- _нет_
+
+### P3 — Nice-to-have (не блокирует приёмку)
+- [ ] Frontmatter обоих ADR (`ADR-001` и `adr-0043`) держит `status: proposed`. По мере мержа фикса
+  статус естественно становится принятым решением — стоит при следующем касании обновить на `accepted`
+  (косметика трассировки, не влияет на гейт).
+- [ ] В врезке `mark()` (`launcher._monitor_agent`, стр. ~884) делается отдельный
+  `get_task_by_repo_branch(repo, branch)` ради `stage`-контекста, хотя тот же lookup повторяется ниже в
+  хвосте финализации (стр. ~984). Дублирование на пути, и так делающем БД-работу, обёрнуто never-raise;
+  `stage` здесь — best-effort контекст для `snapshot()` (reaper резолвит стадию независимо через
+  `_task_meta`), так что корректность не зависит от него. Можно при желании переиспользовать один lookup.
+
+## Документация
+
+**Статус: полностью обновлена в том же PR (golden source соблюдён).**
+
+| Артефакт | Изменение | Оценка |
+|----------|-----------|--------|
+| `docs/architecture/README.md` | Job-reaper компонент + раздел Tier-2 + список kill-switch (`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`) + ссылки на adr-0043 | ✅ |
+| `docs/architecture/internals.md` | Детализация Tier-2 deploy-staging defer | ✅ |
+| `CHANGELOG.md` | Развёрнутая запись `[Unreleased]` с подпунктами (leaf / эмиссия / консультация / наблюдаемость) | ✅ |
+| `docs/work-items/ORCH-113/06-adr/ADR-001-…` | Детальный ADR (D1–D5, альтернативы, последствия) | ✅ |
+| `docs/architecture/adr/adr-0043-…` | Сквозной ADR (уточняет adr-0011/0040/0042/0041) | ✅ |
+| `docs/work-items/ORCH-113/{00..04,07,08,10}` | Полный пакет номерных доков | ✅ |
+
+**Обзорные доки / витрина:** правка внутренняя для job-reaper; высокоуровневые описания в
+`docs/overview/tech-architecture.md` («job-reaper возвращает в очередь job'ы, чей исполнитель умер») и
+`README.md` остаются корректными — обновления не требуют (ORCH-079/ORCH-011 не задеты). Раздел README
+«Известные ограничения» не содержит пункта, закрываемого этим PR (баг был инцидентом, не значился
+ограничением) — обновление не требуется. Известное ограничение `--workers>1` (TR-3) — системное
+пред-допущение, документировано в `10-tech-risks.md` и обоих ADR; вынос в README не обязателен.

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

@@ -0,0 +1,66 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-113
+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-113
+---
+
+# Test Report — ORCH-113
+
+BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer.
+
+## Окружение
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-113-bug-job-reaper-must-not-re-run` (ветка `feature/ORCH-113-bug-job-reaper-must-not-re-run`)
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Дата: 2026-06-15
+- Review verdict (12-review.md): `APPROVED`
+
+## Smoke API (read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok","service":"orchestrator"}` — PASS |
+| `GET /status` | Отвечает; ORCH-113 (task 101) виден на стадии `testing` — PASS |
+| `GET /queue` | Блоки `serial_gate` (ORCH-088) **и** `auto_labels` (ORCH-089) присутствуют — PASS |
+
+## Результаты — покрытие тест-плана (04-test-plan.yaml)
+
+Все TC реализованы в `tests/test_orch113_reaper_finalizer_liveness.py` (13 тест-функций на 8 TC).
+
+| TC ID | Описание | AC / FR | Тест-функция | Результат |
+|-------|----------|---------|--------------|-----------|
+| TC-01 | Живой finalizer на `deploy-staging` (exit=0, age≥grace) → reaper НЕ вызывает `_gate_driven_advance`/`advance_stage`, логирует defer | AC-1/FR-1 | `test_tc01_live_finalizer_deploy_staging_not_reaped` | PASS |
+| TC-02 | Строгое владение: актор без владения НЕ исполняет merge-gate/re-test/advance (ноль побочных эффектов) | AC-2/FR-2 | `test_tc02_non_owner_runs_no_edge_gates` | PASS |
+| TC-03 | Мёртвый finalizer → reaper по-прежнему добивает job (Tier-2 retry + Tier-3 backstop игнорирует маркер); reaper не no-op | AC-3/FR-4 | `test_tc03_dead_finalizer_still_reaped_tier2`, `test_tc03_tier3_backstop_ignores_marker` | PASS |
+| TC-04 | Идемпотентность под гонкой: тяжёлый прогон edge-гейтов исполняется ровно один раз для `(job, stage)`, нет второго re-test/ложного rollback | AC-2/AC-4/FR-2/FR-5 | `test_tc04_idempotent_no_second_advance_under_race` | PASS |
+| TC-05 | **ОБЯЗАТЕЛЬНЫЙ регресс ORCH-111:** долгая (>grace) финализация при `staging_status=SUCCESS` → нет отката `deploy-staging → development`, нет ложного developer-retry; единственное консистентное состояние (красный до фикса, зелёный после) | AC-4/FR-5 | `test_tc05_orch111_no_false_rollback_no_retry_increment` | PASS |
+| TC-06 | Регресс-гард совместимости: kill-switch off ИЛИ не-`deploy-staging` → поведение reaper байт-в-байт прежнее | NFR-4/AC-5 | `test_tc06_killswitch_off_byte_for_byte_prior`, `test_tc06_non_deploy_staging_stage_not_consulted`, `test_tc06_within_grace_unchanged` | PASS |
+| TC-07 | Сквозной инвариант бюджета: `reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace` (ORCH-065/109/110) | NFR-6/AC-5 | `test_tc07_budget_invariant_preserved` | PASS |
+| TC-08 | never-raise: сбой пути живости/владения деградирует безопасно — reaper-тик не падает, прочие job обрабатываются | NFR-1/NFR-3/AC-5 | `test_tc08_liveness_error_never_breaks_tick`, `test_tc08_reap_once_isolates_and_never_raises`, `test_tc08_finalizer_liveness_leaf_never_raises` | PASS |
+
+**Сопоставление с 03-acceptance-criteria.md:** AC-1…AC-6 покрыты (AC-1→TC-01, AC-2→TC-02/TC-04, AC-3→TC-03, AC-4→TC-04/TC-05, AC-5→TC-06/TC-07/TC-08, AC-6→полный зелёный прогон + TC-05 как регресс-доказательство). Каждый TC из тест-плана выполнен и сопоставлен.
+
+## Вывод pytest
+
+Целевой файл:
+```
+tests/test_orch113_reaper_finalizer_liveness.py ... 13 passed, 1 warning in 3.60s
+```
+
+Полный регресс:
+```
+$ python -m pytest tests/ -q
+........................................................................ [ 39%]
+... (snip) ...
+.........................................................                [100%]
+2001 passed, 1 warning in 316.72s (0:05:16)
+```
+(единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, не относится к задаче, присутствует исторически)
+
+## Итог
+**PASS** — целевой файл 13/13 PASS, полный регресс `tests/` 2001 passed / 0 failed, smoke API (`/health`, `/status`, `/queue` с блоками `serial_gate` + `auto_labels`) зелёный, каждый TC тест-плана выполнен и сопоставлен с критериями приёмки. Задача переходит на `deploy-staging`.

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

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

@@ -0,0 +1,42 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-113
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T10:04:59Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment
+(`orchestrator-staging`, port 8501, mode=stub), run inside the container via the
+Docker Exec API (canonical `docker exec` path — host `docker` CLI unavailable;
+ADR-001/ORCH-048 invariant preserved: B6 registry-isolation reads the running
+instance's own `.env.staging` process-env).
+
+## 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']
+tolerance: staging_infra_tolerance_enabled=True
+```
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Verdict mapping (ORCH-061)
+
+- Suite exit code: **0** → `staging_status: SUCCESS`.
+- All REAL checks green (Blocks A/B SMOKE+ACCESS, C7/C8 E2E).
+- C9a/C9b are the two tolerated sandbox-infra checks (depend on SANDBOX bot
+  accounts being project members — not on the pipeline). They were waived per
+  ORCH-061; the script printed the `INFRA-WAIVED:`/`VERDICT:` lines and exited 0.
+  Exit code is trusted; waived checks are not re-judged.
+
+Staging gate passed → advance to `deploy`.

docs/work-items/ORCH-113/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-113
+
+Детерминированный 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-113/18-coverage-report.md

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

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: pipeline stage transitions need ownership lease and smart startup recovery
+
+Work Item ID: ORCH-114
+
+## Description
+
+TBD

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

@@ -0,0 +1,186 @@
+---
+work_item: ORCH-114
+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-114 — Ownership-lease для side-effectful переходов стадий + умное восстановление при старте
+
+Work Item: **ORCH-114** · Repo: **orchestrator** · Стадия: analysis
+
+> **Багфикс-трек → ЭСКАЛАЦИЯ В ПОЛНЫЙ ЦИКЛ (`escalate: full-cycle`).** Задача пришла под меткой
+> `Bug` (укороченный маршрут ORCH-019, пропуск `architecture`), но дефект **системный и
+> архитектурный**: вводится глобальный инвариант владения переходом, durable-механизм, переживающий
+> рестарт процесса, и compare-and-swap на запись стадии. Это требует **ADR** (выбор механизма:
+> lease / heartbeat / transition-epoch / CAS) и затрагивает поведение всего конвейера и нескольких
+> фоновых акторов. Поэтому выпускается **полный** analysis-пакет; оператор снимает багфикс-трек
+> эндпоинтом `POST /bug-fast-track/escalate?work_item=ORCH-114` → задача уходит в `architecture`
+> (ADR-001 D5 ORCH-019).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+ORCH-114 — **системный наследник** инцидент-цепочки ORCH-110 / ORCH-111 / ORCH-112 / ORCH-113.
+Каждый предшественник закрыл **точечный** симптом, но **корневой класс** остался открыт:
+**у side-effectful переходов стадий нет единого владения (ownership)**.
+
+### Корень (установленный факт, верифицировано кодом)
+
+`stage_engine.advance_stage(...)` — единая точка перехода между стадиями и исполнения тяжёлых
+под-гейтов ребра `deploy-staging → deploy` (security → merge-gate re-test → coverage →
+image-freshness) и под-гейта `deploy → done` (`_handle_merge_verify`: `merge_pr`, ratchet
+coverage-baseline, запись proof-of-merge). При этом:
+
+- **Запись стадии не атомарна по предусловию.** `db.update_task_stage(task_id, stage)` —
+  «голый» `UPDATE tasks SET stage=? WHERE id=?` **без** `WHERE stage=?` (нет compare-and-swap, нет
+  epoch/version-колонки). Любой второй вызов безусловно перезатирает результат первого.
+- **`advance_stage` ре-ентерабельна без защиты.** Внутри неё нет ни in-memory-лока на `task_id`,
+  ни durable-маркера «переход в процессе». Два конкурентных вызова для одной задачи оба читают
+  `stage='deploy-staging'`, оба прогоняют ВСЕ под-гейты, оба пишут `deploy`, оба ставят
+  следующего агента.
+- **Минимум 5 путей входят в переход независимо:** (1) монитор агента (`launcher._try_advance_stage`,
+  auto-advance по `exit_code==0`), (2) Plane-webhook (`webhooks/plane._try_advance_stage`,
+  Approved / Confirm Deploy), (3) reconciler F-1 (`advance_if_gate_passed → advance_stage`,
+  `finished_agent=None`), (4) job-reaper (`job_reaper._gate_driven_advance → launcher._try_advance_stage`),
+  (5) deploy-finalizer Phase C (`run_deploy_finalizer → advance_stage(finished_agent="deployer")`).
+  Ни один не проверяет, не находится ли **другой** актор уже внутри того же перехода.
+
+### Почему предшественники не закрыли класс
+
+| Задача | Что закрыла | Что осталось открытым |
+|--------|-------------|------------------------|
+| **ORCH-110** | merge-gate re-test: ложный rollback по инфра-таймауту + tree-kill осиротевших pytest | Только merge-gate re-test; не вводит владения переходом |
+| **ORCH-112** | гигиена общего deploy-checkout (грязь блокировала `git pull`) | Только чистка артефактов; не про конкурентные переходы |
+| **ORCH-113** | reaper не пере-исполняет **живую** финализацию `deploy-staging` (Tier-2) | **process-local in-memory** реестр (`finalizer_liveness`), **только reaper**, **только Tier-2**, **только `deploy-staging`**; **теряется при рестарте**; **НЕ** покрывает reconciler / webhook / restart-recovery |
+
+Таким образом, **остаточный кросс-путь** (ORCH-113 §ограничения сам это фиксирует): живой монитор
+внутри `advance_stage(deploy-staging)` — и параллельно reaper (при выключенном liveness-флаге или
+**после рестарта**, когда in-memory реестр пуст), либо reconciler F-1, либо webhook-путь — повторно
+входят в тот же переход. Результат — **двойные** эффекты (security/merge/coverage/image-freshness/
+прод-деплой) и **противоречивые** исходы (один путь откатывает на `development`, другой доводит до
+`done`). Именно это наблюдалось в инциденте ORCH-111 (job 1914 / PR #130): повторный re-test покраснел
+и дал ложный откат `deploy-staging → development` с ложным developer-retry, **одновременно** с успешной
+финализацией и мержем оригинального монитора.
+
+### Особый разрез — рестарт процесса (self-hosting)
+
+Прод-контейнер `orchestrator` рестартится при self-деплое. Если процесс умирает **в середине**
+финализации, in-memory `finalizer_liveness._OWNED` исчезает, `requeue_running_jobs` переводит
+`running → queued`, и переход может быть **пере-исполнен с нуля** без знания, что часть необратимых
+шагов (мерж в `main`, ratchet baseline, прод-деплой) уже применена. **Durable**-сигнал владения,
+переживающий рестарт, отсутствует — это ключевая дельта ORCH-114 над ORCH-113.
+
+---
+
+## 2. Объём (scope)
+
+### В объёме
+- Единый **инвариант владения** side-effectful переходом/финализацией: в любой момент времени
+  переход конкретной задачи исполняет **не более одного** актора.
+- **Compare-and-swap (CAS)** / transition-epoch на запись стадии: писатель применяет переход
+  только если предусловие (текущая стадия / эпоха) не изменилось с момента чтения; проигравший —
+  аборт **без** побочных эффектов.
+- **Durable** механизм владения (lease/heartbeat/epoch — выбор за архитектором), переживающий
+  рестарт процесса.
+- Осведомлённость **job-reaper** и **startup-requeue** о живой / устаревшей финализации (обобщение
+  ORCH-113 за пределы Tier-2 / `deploy-staging` / in-memory).
+- **Reconciler F-1** и **webhook**-пути: skip/defer при активном lease перехода.
+- **Умное восстановление при старте**: после смерти процесса в середине финализации система сходится
+  к **единственному** согласованному исходу (без двойных необратимых эффектов и без противоречий
+  rollback↔done).
+- **Наблюдаемость**: read-only блок в `GET /queue` + алерт на форсированный/устаревший реклейм lease.
+- **Регресс-тесты**: `deploy-staging`-ребро, deploy-finalizer (Phase C), restart-recovery.
+
+### Вне объёма
+- Изменение состава/порядка стадий (`STAGE_TRANSITIONS`), реестра `QG_CHECKS`, семантики/имён
+  `check_*`, машинных вердикт-ключей (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/
+  `security_status:`/`coverage_status:`) — **байт-в-байт не трогаются**.
+- Повторная починка частных симптомов ORCH-110/112 (merge-retest tree-kill, checkout-hygiene) —
+  они уже закрыты; ORCH-114 их **переиспользует**, не переписывает.
+- Переход на `uvicorn --workers>1` / мульти-процессную модель (остаётся одно-процессной; durable-lease
+  лишь делает инвариант корректным и на этот случай, но миграция модели — отдельная задача).
+- Выбор конкретного механизма (lease vs heartbeat vs epoch), точная форма хранения (доп. таблица vs
+  доп. колонки) и порядок старта демонов — **решает архитектор** в `06-adr/` (это требования к
+  свойствам, не к реализации).
+
+---
+
+## 3. Заинтересованные стороны
+- **Owner / оператор self-hosting** — заказчик; страдает от ложных откатов, двойных деплоев и ручного
+  разбора расхождений состояния.
+- **Все проекты в общем инстансе** (orchestrator + enduro-trails) — групповой риск: расхождение
+  состояния и ложный freeze репо клинят общую очередь.
+- **Принимает результат:** Owner; технически — финальная стадия конвейера (CI/гейты), не агент сам.
+
+---
+
+## 4. Бизнес-требования (BR)
+
+| ID | Требование (проверяемое) | Покрытие |
+|----|---------------------------|----------|
+| **BR-1** | Side-effectful переход/финализацию задачи в любой момент исполняет **не более одного** актора (единое владение). | FR-1 / AC-1 |
+| **BR-2** | Запись стадии для side-effectful переходов защищена **compare-and-swap / epoch**: проигравший гонку писатель не мутирует стадию и **не выполняет** побочных эффектов. | FR-2 / AC-1, AC-2 |
+| **BR-3** | **job-reaper** осведомлён о живой vs устаревшей финализации на **всех** релевантных путях (не только Tier-2/`deploy-staging`): defer при живом владении, реклейм мёртвого/устаревшего владельца в **ограниченное** время. | FR-3 / AC-4, AC-5 |
+| **BR-4** | **Startup-requeue / восстановление при старте** учитывает незавершённую финализацию через durable-состояние: не пере-исполняет уже применённый необратимый шаг. | FR-4 / AC-6 |
+| **BR-5** | **Reconciler F-1** и **webhook**-пути продвижения **пропускают/откладывают** переход, пока активен lease владения для задачи. | FR-5 / AC-7, AC-8 |
+| **BR-6** | После смерти процесса в середине финализации система сходится к **единственному** согласованному исходу: **нет** двойного `merge_pr` / ratchet baseline / image-rebuild / инициации прод-деплоя и **нет** противоречия rollback↔done. | FR-1…FR-4 / AC-1, AC-6 |
+| **BR-7** | Состояние владения переходом **наблюдаемо**: read-only блок в `GET /queue` + алерт при форсированном/устаревшем реклейме. | FR-6 / AC-12 |
+| **BR-8** | Поставляются **регресс-тесты** на конкурентный двойной эффект (`deploy-staging`), deploy-finalizer (Phase C) и restart-recovery; обязательный регресс воспроизводит исходный класс (красный до фикса, зелёный после). | FR-7 / AC-1, AC-6, тест-план |
+| **BR-9** | Механизм **обратим**: kill-switch возвращает поведение **байт-в-байт** к состоянию до ORCH-114. | FR-7 / AC-9 |
+
+---
+
+## 5. Нефункциональные требования (NFR)
+
+| ID | Требование |
+|----|------------|
+| **NFR-1** | **never-raise.** Любая ошибка механизма владения изолируется. Горячий путь claim/guard — **fail-open** (не заклинить общую очередь всех проектов, AC-8 ORCH-088); решения, критичные для безопасности прода/необратимости — **fail-closed**. |
+| **NFR-2** | **Kill-switch + область раската** по образцу leaf-гейтов (`serial_gate`/`coverage_gate`/`finalizer_liveness`): глобальный флаг + при необходимости CSV-скоуп репо (пусто → self-hosting only). При выключенном флаге — нулевая регрессия (enduro не затронут). |
+| **NFR-3** | **Инварианты конвейера не тронуты:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / машинные вердикт-ключи / схемы существующих таблиц — байт-в-байт. Любое новое хранилище — **аддитивно и идемпотентно** (`CREATE TABLE IF NOT EXISTS` / `_ensure_column`). |
+| **NFR-4** | **Durable / restart-safe.** Сигнал владения переживает рестарт процесса (ключевая дельта над in-memory `finalizer_liveness` ORCH-113); после рестарта восстановление детерминированно решает «дорешать vs уже применено». |
+| **NFR-5** | **Self-hosting безопасность.** Механизм владения сам по себе **никогда** не рестартит прод-контейнер, не пушит/force-push в `main`, не трогает detached deploy-процесс (NFR-3 ORCH-090/112). |
+| **NFR-6** | **Сквозной бюджет reaper сохранён:** инвариант ORCH-065/109/110/113 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work ≈4460) + grace`. Lease **не** удлиняет финализацию за backstop без согласованной правки бюджета; устаревший/мёртвый владелец добивается Tier-3 в ограниченное время. |
+| **NFR-7** | **Идемпотентность.** Повторный заход в уже применённый переход — **no-op** (по epoch / SHA-in-main / lease), никогда не второй побочный эффект. |
+| **NFR-8** | **Обратная совместимость.** При флаге off / репо вне области — путь старта, claim и переходы байт-в-байт прежние (enduro и текущий orchestrator). |
+
+---
+
+## 6. Допущения и ограничения
+- **Одно-процессная модель сейчас** (один uvicorn-воркер без `--workers`), но требование NFR-4
+  (durable) делает инвариант корректным и при будущем рестарте/мульти-процессности — без переписывания.
+- **Источник истины планировщика — локальная БД** (offline hot-path, NFR-2/ORCH-026/088): механизм
+  владения не должен вносить сетевых зависимостей в горячий claim.
+- **Переиспользуются существующие durable-примитивы:** атомарный `reap_running_job` (rowcount-guard),
+  `claim_next_job` (rowcount-guard), `requeue_running_jobs`, merge-lease (ORCH-043). ORCH-114 **достраивает**
+  владение поверх них, а не дублирует.
+- **`finalizer_liveness` (ORCH-113)** — отправная точка: ORCH-114 обобщает её до durable, кросс-путевого
+  владения; решение «расширить / заменить / надстроить» принимает архитектор.
+- Точные **D-решения** (durable shape, эпоха vs lease-таблица, набор покрываемых рёбер сверх
+  `deploy-staging`/`deploy→done`, порядок старта демонов) — за архитектором (`06-adr/`, `10-tech-risks.md`).
+
+## 7. Критерии успеха
+Кратко (детальные PASS/FAIL — `03-acceptance-criteria.md`):
+- Конкурентный/после-рестартовый повторный вход в side-effectful переход **не** даёт двойных эффектов
+  и противоречивых исходов; ровно один актор владеет и доводит переход.
+- CAS/epoch на запись стадии: проигравший — чистый аборт.
+- reaper / startup / reconciler / webhook осведомлены о живом lease (defer) и о мёртвом (реклейм в
+  ограниченное время).
+- Полный `pytest tests/` зелёный; новые регресс-тесты (двойной эффект, restart-recovery) зелёные;
+  при выключенном kill-switch — поведение байт-в-байт прежнее.
+
+## 8. Риски
+Краткий перечень (детали — `10-tech-risks.md`, заполняет архитектор):
+- **Дедлок / over-block:** слишком «жёсткое» владение может заклинить легитимный путь (reaper не
+  добьёт зависший финализатор) → требование NFR-6 (bounded reclaim) и fail-open на hot-path.
+- **Бюджет vs lease:** lease, удерживаемый дольше `reaper_max_running_s`, конфликтует со сквозным
+  бюджетом → согласование с ORCH-065/109/110/113.
+- **Durable-состояние и гонки на рестарте:** некорректный «умный recovery» может сам стать источником
+  двойного применения → обязательный restart-recovery регресс (BR-8).
+- **Скрытые пути перехода** (gitea-webhook `handle_push`/`handle_ci_status`/`handle_pr` пишут стадию
+  **в обход** `advance_stage` через прямой `update_task_stage`) → охват CAS должен учитывать и их
+  (архитектор фиксирует границу).

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

@@ -0,0 +1,143 @@
+---
+work_item: ORCH-114
+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-114 — Ownership-lease для side-effectful переходов стадий + умное восстановление при старте
+
+Work Item: **ORCH-114** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные требования к реализации**, выведенные из BRD (`01-brd.md`) и фактического
+> кода. **Выбор механизма** (durable lease / heartbeat / transition-epoch / форма хранения, набор
+> покрываемых рёбер) и архитектурное обоснование — задача архитектора (`06-adr/`). Здесь — *что*
+> должно быть истинно и *какие модули* затрагиваются, не *как* именно.
+
+## 1. Сводка изменения
+
+Вводится **единый инвариант владения** side-effectful переходом стадии: запись стадии и исполнение
+тяжёлых под-гейтов/финализации защищаются **durable-механизмом владения** (lease/epoch) + **CAS** на
+запись стадии, так что в любой момент переход конкретной задачи доводит **ровно один** актор, а
+конкурентный/после-рестартовый повторный вход (reaper / reconciler / webhook / startup-requeue)
+**откладывается или становится no-op** вместо повторного применения необратимых эффектов
+(merge_pr / coverage-ratchet / image-rebuild / инициация прод-деплоя / противоречивый rollback↔done).
+Аддитивно, под kill-switch, never-raise; `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / вердикт-ключи
+/ схемы существующих таблиц — не трогаются (обобщает и делает durable процесс-локальный
+`finalizer_liveness` ORCH-113).
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие | Назначение в ORCH-114 |
+|------|----------|------------------------|
+| `src/stage_engine.py` | изменить | `advance_stage`: захват владения на границе side-effectful перехода/финализации; CAS на запись стадии; release в `try/finally`; проигравший — чистый аборт. Покрыть `_handle_merge_verify`, под-гейты `deploy-staging→deploy`, `run_deploy_finalizer` (Phase C), `advance_if_gate_passed` (F-1). |
+| `src/db.py` | изменить | CAS-вариант записи стадии (запись только при совпадении ожидаемой текущей стадии/эпохи; rowcount-результат). Durable-хелперы владения (acquire / heartbeat-touch / release / reclaim / snapshot) — форму хранилища задаёт архитектор. |
+| `src/finalizer_liveness.py` | изменить/обобщить | Отправная точка: обобщить process-local реестр до **durable, кросс-путевого** владения (или надстроить durable-слой поверх). Сохранить контракт never-raise + kill-switch. |
+| `src/job_reaper.py` | изменить | Tier-2/Tier-3 осведомлены о durable-владении на **всех** релевантных путях (не только Tier-2/`deploy-staging`): defer при живом, реклейм мёртвого/устаревшего в ограниченное время (NFR-6). |
+| `src/queue_worker.py` | изменить | `requeue_running_jobs` / стартовое восстановление сверяется с durable-владением: не пере-исполнять уже применённый необратимый шаг (умное восстановление). `claim_next_job` — не вносить сетевых зависимостей. |
+| `src/reconciler.py` | изменить | F-1 (`advance_if_gate_passed`) — defer при активном lease перехода (по образцу skip-guard'ов escalated/Blocked/deps). |
+| `src/webhooks/plane.py` | изменить | Пути продвижения (`_try_advance_stage`, Approved / Confirm Deploy) — defer при активном lease. |
+| `src/webhooks/gitea.py` | изменить (учесть) | Прямые записи стадии в обход `advance_stage` (`handle_push`/`handle_ci_status`/`handle_pr`) должны попадать под тот же CAS-инвариант либо явно исключаться архитектором (граница в ADR). |
+| `src/main.py` | изменить | Порядок старта демонов / точка восстановления; read-only блок в `GET /queue`; опц. operator-эндпоинт реклейма. |
+| `src/config.py` | изменить | Kill-switch(и) + бюджеты/таймауты владения + (опц.) CSV-скоуп репо. |
+| `tests/test_orch114_transition_ownership.py` | создать | Покрытие FR-1…FR-7 (см. `04-test-plan.yaml`). |
+
+## 3. Функциональные требования
+
+### FR-1 — Единое владение side-effectful переходом (BR-1, BR-6)
+На границе, где начинается side-effectful финализация/переход (минимум: под-гейты
+`deploy-staging→deploy`, `_handle_merge_verify` на `deploy→done`, Phase C `run_deploy_finalizer`),
+актор **захватывает владение** задачей. Пока владение активно, другой актор не исполняет тот же
+переход. Release — детерминированно в `try/finally` (в т.ч. на исключении/откате). Владение
+**durable** (NFR-4): переживает рестарт и доступно для проверки другому актору/новому процессу.
+
+### FR-2 — Compare-and-swap / epoch на запись стадии (BR-2)
+Запись стадии для side-effectful переходов выполняется только если предусловие (ожидаемая текущая
+стадия и/или эпоха перехода) не изменилось с момента чтения. Реализуется через CAS-вариант
+`update_task_stage` (`UPDATE … SET stage=?[, epoch=epoch+1] WHERE id=? AND stage=?[ AND epoch=?]`,
+решение по форме — архитектор). Проигравший гонку писатель получает «lost-race» результат, **не**
+мутирует стадию и **не** выполняет ни одного побочного эффекта (merge_pr / ratchet / rebuild /
+deploy-init / enqueue следующего агента). Инвариант распространяется и на пути, пишущие стадию в
+обход `advance_stage` (gitea-webhook), — либо CAS, либо явное исключение (граница в ADR).
+
+### FR-3 — Reaper, осведомлённый о владении на всех путях (BR-3, NFR-6)
+Job-reaper перед реклеймом сверяется с durable-владением **не только** в Tier-2 для `deploy-staging`
+(текущая область ORCH-113), а на всех релевантных тирах/рёбрах: **живой** владелец → **defer**
+(лог + счётчик, без повторного advance); **мёртвый/устаревший** владелец → реклейм в ограниченное
+время (Tier-3 backstop `reaper_max_running_s` добивает зависшего; маркер владения backstop не
+обходит инвариант бюджета). Сохранить атомарный `reap_running_job` rowcount-guard.
+
+### FR-4 — Умное восстановление при старте (BR-4, BR-6, NFR-7)
+Стартовое восстановление (`requeue_running_jobs` + последующий цикл) использует durable-владение/эпоху,
+чтобы **детерминированно** различить: (a) финализация не начиналась / безопасно перезапустить →
+re-drive; (b) необратимый шаг уже применён (мерж в `main` / ratchet / прод-деплой инициирован) →
+**сойтись к done/консистентному исходу без повторного применения**. Источник истины для «уже
+применено» — авторитетные durable-факты (SHA-in-main ORCH-071/073, маркер `INITIATED` self-deploy,
+durable-lease/эпоха), а не in-memory состояние.
+
+### FR-5 — Skip/defer в reconciler и webhook (BR-5)
+Reconciler F-1 (`advance_if_gate_passed`) и webhook-пути продвижения (`plane._try_advance_stage`,
+Approved/Confirm Deploy) при **активном** lease перехода для задачи **откладывают** действие
+(silent skip + наблюдаемость), по образцу существующих skip-guard'ов F-1 (escalated / Blocked /
+task-deps). Fail-safe: неопределённость состояния lease → консервативный skip (не дублировать).
+
+### FR-6 — Наблюдаемость (BR-7)
+Аддитивный read-only блок в `GET /queue` (по образцу `serial_gate`/`merge_gate`/`reaper`):
+держатели lease, возраст владения, defer-счётчики, форсированные/устаревшие реклеймы. Алерт
+(`send_telegram`, кликабельный номер) на форсированный/устаревший реклейм. Опц. запись в
+lessons-journal (ORCH-098, `source="auto"`). Опц. operator-эндпоинт ручного реклейма (по образцу
+`POST /serial-gate/unfreeze`).
+
+### FR-7 — Конфигурация, обратимость, never-raise (BR-9, NFR-1, NFR-2, NFR-8)
+Все публичные функции владения — never-raise (ошибка → безопасный дефолт + WARNING). Kill-switch
+возвращает поведение **байт-в-байт** к до-ORCH-114 (lease не пишется/не читается, CAS вырождается в
+прежний безусловный `update_task_stage`). Hot-path — fail-open; prod-safety — fail-closed.
+
+## 4. Изменения API
+- **`GET /queue`** — аддитивный read-only блок владения переходом (имя ключа уточнит архитектор,
+  напр. `transition_ownership` / `transition_lease`). Существующие ключи `/queue` — байт-в-байт.
+- **(Опционально, по решению архитектора)** `POST /transition-lease/release?work_item=<id>` —
+  операторский ручной реклейм застрявшего владения (паттерн `POST /serial-gate/unfreeze`).
+- `GET /metrics` (ORCH-099) — при необходимости аддитивное поле без бампа `schema_version` (sidecar
+  обязан толерировать незнакомые ключи). Прочие эндпоинты — не трогаются.
+
+## 5. Изменения схемы БД
+**Требование (форму выбирает архитектор, `06-adr/` + `08-data-requirements.md`):** для durable-владения
+(NFR-4) и CAS/epoch (FR-2) требуется **аддитивное, идемпотентное** durable-состояние. Кандидаты
+(не предписание):
+- доп. аддитивная таблица владения (`CREATE TABLE IF NOT EXISTS`, паттерн `repo_freeze`/
+  `coverage_baseline`/`lessons`) с `(task_id/job_id, owner, run_id, stage, acquired_at, heartbeat_at,
+  expires_at)`; **либо**
+- аддитивные колонки на `tasks`/`jobs` (`_ensure_column`, паттерн `tasks.track`/`tasks.cancelled_at`),
+  включая возможную `epoch/version`-колонку для CAS.
+
+**Жёсткие ограничения (NFR-3):** только аддитивно/идемпотентно; **схемы существующих таблиц
+(`tasks`/`jobs`/`agent_runs` и пр.) — байт-в-байт**; никаких изменений существующих столбцов/индексов,
+ломающих обратную совместимость; restart-safe инициализация в `init_db()`.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** `QG_CHECKS` / `check_*` / `_parse_*` / машинные вердикт-ключи — **не трогаются**. Владение
+переходом — свойство **движка переходов и фоновых акторов**, а **не** Quality Gate и **не** стадия
+(аналогично тому, как merge-lease/serial-gate/finalizer-liveness — врезки/leaf'ы, а не QG). Никаких
+новых стадий/рёбер в `STAGE_TRANSITIONS`.
+
+## 7. Совместимость / регресс
+- **Kill-switch** (новый флаг в `config.py`, env `ORCH_*`): `False` → CAS вырождается в прежний
+  безусловный `update_task_stage`, lease не пишется/не читается, reaper/reconciler/webhook ведут себя
+  как до ORCH-114 — **байт-в-байт** (включая зелёный существующий `pytest tests/`).
+- **Область раската:** по образцу leaf-гейтов; durable-lease минимально применяется к self-hosting
+  рёбрам (`deploy-staging`/`deploy→done`, где живут необратимые эффекты); generic-CAS инертен при
+  отсутствии гонки (нулевая стоимость на не-затронутых переходах). Точную область фиксирует архитектор.
+- **Обратимость:** механизм аддитивен и изолирован; откат = выключить kill-switch (durable-таблица/
+  колонки остаются инертными).
+- **never-raise / fail-open / fail-closed:** hot-path claim/guard — fail-open (не клинить общую
+  очередь, AC-8 ORCH-088); prod-safety/необратимость — fail-closed; любой сбой механизма — WARNING +
+  безопасный дефолт.
+- **Сквозной бюджет:** lease согласован с `reaper_max_running_s`/`reaper_finalize_grace_s` (ORCH-065/
+  109/110/113) — не удлиняет финализацию за backstop; устаревший владелец добивается в ограниченное время.
+- **Маркеры трассировки (ORCH-078):** правки в блоках с маркерами ORCH-065/109/110/111/113 (reaper,
+  finalizer-liveness, merge-gate) сверяются с их ADR перед изменением; новый код помечается `ORCH-114`.
+- **enduro-trails:** при флаге off / репо вне области — нулевая регрессия.

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

@@ -0,0 +1,177 @@
+---
+work_item: ORCH-114
+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-114 — Ownership-lease для side-effectful переходов + умное восстановление при старте
+
+Work Item: **ORCH-114** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
+считается провалом). Reviewer/CI проверяет их буквально по файлам и тестам репозитория.
+
+---
+
+## AC-1 — Обязательный регресс: нет двойного эффекта при конкурентном входе в переход
+
+**Условие:** два актора одновременно входят в `advance_stage(deploy-staging)` для одной задачи
+(живой монитор-финализатор + второй путь: reaper / reconciler F-1 / webhook). Тест-двойники для
+`merge_pr` / coverage-ratchet / image-rebuild / deploy-init считают число вызовов.
+- **PASS:** side-effectful шаги (merge_pr, ratchet baseline, image-rebuild, инициация прод-деплоя,
+  enqueue следующего агента) выполняются **ровно один раз**; персистится **ровно один** согласованный
+  исход стадии; второй актор получает «lost-race»/defer и **не** выполняет побочных эффектов. Тест
+  **красный до фикса, зелёный после** (воспроизводит класс инцидента ORCH-111).
+- **FAIL:** любой side-effectful шаг вызван дважды; либо два противоречивых исхода (один откатил на
+  `development`, другой довёл до `done`); либо тест не воспроизводит проблему до фикса.
+
+---
+
+## AC-2 — Compare-and-swap на запись стадии
+
+**Условие:** CAS-вариант записи стадии вызывается двумя писателями с одинаковым ожидаемым предусловием;
+первый применяется, второй приходит со «устаревшим» ожиданием.
+- **PASS:** первый writer применяет переход (rowcount=1); второй получает «lost-race» (rowcount=0),
+  стадия **не** мутируется повторно; при выключенном kill-switch CAS вырождается в прежний безусловный
+  `update_task_stage` (байт-в-байт).
+- **FAIL:** второй writer перезатирает стадию; либо CAS меняет семантику записи при выключенном флаге.
+
+---
+
+## AC-3 — Жизненный цикл владения: acquire / release / реклейм
+
+**Условие:** актор начинает side-effectful финализацию.
+- **PASS:** владение захватывается на границе финализации и освобождается в `try/finally` — в т.ч.
+  при исключении и при откате (rollback); durable-запись владения видна другому актору; после release
+  владение реклеймится/свободно.
+- **FAIL:** владение не освобождается при исключении/откате (lease «течёт» и клинит задачу); либо не
+  захватывается на границе.
+
+---
+
+## AC-4 — Reaper откладывает реклейм при живом владении (все пути, не только Tier-2/deploy-staging)
+
+**Условие:** durable-владение активно (живой финализатор), reaper делает тик.
+- **PASS:** reaper **defer** (лог + счётчик, без повторного `advance_stage`) пока владение живо и в
+  пределах бюджета; область defer обобщена за пределы Tier-2/`deploy-staging` ORCH-113 на релевантные
+  пути; атомарный `reap_running_job` rowcount-guard сохранён.
+- **FAIL:** reaper повторно исполняет финализацию при живом владельце; либо defer ограничен только
+  прежней узкой областью, оставляя кросс-путь открытым.
+
+---
+
+## AC-5 — Reaper добивает мёртвое/устаревшее владение в ограниченное время
+
+**Условие:** владелец провально мёртв/завис (lease устарел), финализация не прогрессирует.
+- **PASS:** reaper реклеймит задачу в пределах Tier-3 backstop `reaper_max_running_s` (маркер владения
+  backstop не обходит); задача не остаётся навсегда заклиненной; сквозной инвариант
+  `reaper_max_running_s > Σ(deploy-staging gate-work) + grace` сохранён.
+- **FAIL:** мёртвое владение блокирует задачу бессрочно; либо нарушен бюджетный инвариант ORCH-065/
+  109/110/113.
+
+---
+
+## AC-6 — Умное восстановление при рестарте процесса
+
+**Условие:** процесс убит **в середине** финализации `deploy-staging`/`deploy` (in-memory состояние
+потеряно); процесс перезапущен (`requeue_running_jobs` + цикл).
+- **PASS:** восстановление через durable-владение/эпоху + авторитетные факты (SHA-in-main ORCH-071/073,
+  маркер `INITIATED`) детерминированно сходится к **единственному** согласованному исходу: незавершённое
+  дорешается, **уже применённый** необратимый шаг (мерж/ratchet/прод-деплой) **не** применяется повторно.
+- **FAIL:** после рестарта переход исполняется заново с двойным необратимым эффектом; либо возникает
+  противоречие rollback↔done; либо задача застревает нетерминальной с удержанным lease.
+
+---
+
+## AC-7 — Reconciler F-1 пропускает переход при активном lease
+
+**Условие:** lease перехода активен; reconciler F-1 сканирует задачу.
+- **PASS:** F-1 **defer/skip** (silent, наблюдаемо), не вызывает `advance_stage`, по образцу skip-guard'ов
+  escalated/Blocked/task-deps; fail-safe: неопределённость lease → консервативный skip.
+- **FAIL:** F-1 продвигает стадию параллельно живому владельцу.
+
+---
+
+## AC-8 — Webhook-путь пропускает переход при активном lease
+
+**Условие:** lease перехода активен; приходит Plane-webhook (Approved / Confirm Deploy) на ту же задачу.
+- **PASS:** webhook-путь продвижения **defer**, не дублирует переход/финализацию при живом владельце;
+  поздний легитимный сигнал не теряется (повторно отработает после release или станет идемпотентным no-op).
+- **FAIL:** webhook повторно входит в переход параллельно владельцу и даёт двойной эффект.
+
+---
+
+## AC-9 — Kill-switch off → поведение байт-в-байт прежнее
+
+**Условие:** новый kill-switch выключен.
+- **PASS:** lease не пишется/не читается; CAS вырождается в прежний безусловный `update_task_stage`;
+  reaper/reconciler/webhook/startup ведут себя как до ORCH-114; существующий `pytest tests/` зелёный
+  без правок ожиданий; enduro не затронут.
+- **FAIL:** при выключенном флаге наблюдается любое отличие от до-ORCH-114 поведения.
+
+---
+
+## AC-10 — never-raise + fail-open (hot-path) / fail-closed (prod-safety)
+
+**Условие:** механизм владения сталкивается с ошибкой (БД-сбой/повреждённая запись lease/исключение).
+- **PASS:** ни одна публичная функция владения не роняет конвейер; горячий путь claim/guard —
+  **fail-open** (общая очередь всех проектов не клинится); решения, критичные для необратимости/прода —
+  **fail-closed**; на ошибке — WARNING + безопасный дефолт.
+- **FAIL:** ошибка механизма роняет claim/конвейер; либо hot-path заклинивает очередь; либо
+  prod-критичное решение фейлит «открыто».
+
+---
+
+## AC-11 — Инварианты конвейера не тронуты
+
+**Условие:** аудит диффа против `src/stages.py`, `src/qg/checks.py`, схемы БД.
+- **PASS:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / машинные
+  вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+  `coverage_status:`) — **байт-в-байт**; любое новое хранилище аддитивно/идемпотентно
+  (`CREATE TABLE IF NOT EXISTS` / `_ensure_column`), схемы существующих таблиц неизменны.
+- **FAIL:** изменены состав/порядок стадий, реестр/семантика гейтов, вердикт-ключи или существующие
+  столбцы/индексы.
+
+---
+
+## AC-12 — Наблюдаемость
+
+**Условие:** `GET /queue` при включённом флаге.
+- **PASS:** присутствует аддитивный read-only блок владения (держатели/возраст/defer-счётчики/реклеймы);
+  существующие ключи `/queue` не сломаны; форсированный/устаревший реклейм даёт Telegram-алерт с
+  кликабельным номером.
+- **FAIL:** блок отсутствует/ломает существующий вывод; реклейм происходит молча без наблюдаемости.
+
+---
+
+## AC-13 — Self-hosting безопасность
+
+**Условие:** аудит механизма владения на побочные действия.
+- **PASS:** механизм **никогда** не рестартит прод-контейнер `orchestrator`, не пушит/force-push в
+  `main`, не трогает detached deploy-процесс; деплой орка по-прежнему только через staging-гейт (8501)
+  и `Confirm Deploy`.
+- **FAIL:** механизм владения инициирует рестарт прода/мутацию `main`/вмешательство в detached-деплой.
+
+---
+
+## Сводная матрица AC ↔ FR/BR/NFR
+
+| AC | Покрывает | Тип проверки |
+|----|-----------|--------------|
+| AC-1 | BR-1, BR-6, BR-8 / FR-1, FR-2 | integration (regression, red→green) |
+| AC-2 | BR-2 / FR-2 | unit |
+| AC-3 | BR-1 / FR-1 | unit |
+| AC-4 | BR-3 / FR-3 | integration |
+| AC-5 | BR-3, NFR-6 / FR-3 | unit/integration |
+| AC-6 | BR-4, BR-6, NFR-4, NFR-7 / FR-1…FR-4 | integration (restart-recovery) |
+| AC-7 | BR-5 / FR-5 | unit/integration |
+| AC-8 | BR-5 / FR-5 | unit/integration |
+| AC-9 | BR-9, NFR-8 / FR-7 | regression (kill-switch off) |
+| AC-10 | NFR-1 / FR-7 | unit |
+| AC-11 | NFR-3 / FR-6 (negative) | structural audit |
+| AC-12 | BR-7 / FR-6 | unit/integration |
+| AC-13 | NFR-5 / FR-1 | structural audit |

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

@@ -0,0 +1,107 @@
+work_item: ORCH-114
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+escalate: full-cycle
+title: "Ownership-lease для side-effectful переходов стадий + умное восстановление при старте"
+framework: pytest
+scope: >
+  Покрывается: единое владение side-effectful переходом (FR-1), CAS/epoch на запись стадии (FR-2),
+  осведомлённость reaper о живом/мёртвом владении на всех путях (FR-3), умное восстановление при
+  рестарте (FR-4), skip/defer в reconciler F-1 и webhook (FR-5), наблюдаемость (FR-6), kill-switch
+  и never-raise (FR-7). Вне покрытия: переход на uvicorn --workers>1, частные симптомы ORCH-110/112
+  (уже закрыты и переиспользуются), изменение STAGE_TRANSITIONS/QG_CHECKS/check_*.
+notes: >
+  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс класса инцидента ORCH-111: красный до фикса, зелёный после.
+  Все side-effectful вызовы (merge_pr / coverage-ratchet / image-rebuild / deploy-init) проверяются
+  через тест-двойники со счётчиком вызовов — без сети/реального git/прода/ssh. Restart-recovery
+  моделируется сбросом in-memory состояния + повторным прогоном стартового восстановления над durable
+  состоянием БД. Полный регресс tests/ должен оставаться зелёным; при выключенном kill-switch
+  поведение байт-в-байт прежнее.
+
+tests:
+  - id: TC-01
+    type: integration
+    description: "ОБЯЗАТЕЛЬНЫЙ РЕГРЕСС. Два конкурентных входа в advance_stage(deploy-staging) одной задачи (живой финализатор + reaper/reconciler/webhook): каждый side-effectful шаг (merge_pr/ratchet/rebuild/deploy-init/enqueue) вызывается ровно один раз; персистится один согласованный исход; второй актор — lost-race/defer без побочных эффектов. Красный до фикса, зелёный после."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "CAS-запись стадии: первый writer применяет (rowcount=1), второй с устаревшим предусловием получает lost-race (rowcount=0) и не мутирует стадию (FR-2/AC-2)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Жизненный цикл владения: acquire на границе финализации; release в try/finally при нормальном завершении, при исключении и при откате (lease не течёт); durable-запись видна другому актору (FR-1/AC-3)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Reaper defer при живом владении на путях за пределами Tier-2/deploy-staging ORCH-113: повторный advance не выполняется, атомарный reap_running_job rowcount-guard сохранён, ведётся счётчик defer (FR-3/AC-4)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Reaper добивает мёртвое/устаревшее владение в пределах Tier-3 backstop reaper_max_running_s; маркер владения backstop не обходит; задача не клинится бессрочно (FR-3/AC-5/NFR-6)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-06
+    type: integration
+    description: "Умное восстановление при рестарте: процесс убит в середине финализации, in-memory сброшен; стартовое восстановление над durable-состоянием + авторитетными фактами (SHA-in-main, INITIATED) сходится к единственному исходу без повторного необратимого эффекта (FR-4/AC-6)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "Reconciler F-1 (advance_if_gate_passed) делает defer/skip при активном lease перехода; fail-safe: неопределённость lease → консервативный skip (FR-5/AC-7)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "Webhook-путь (plane._try_advance_stage, Approved/Confirm Deploy) делает defer при активном lease; поздний легитимный сигнал не теряется (повтор после release / идемпотентный no-op) (FR-5/AC-8)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "Kill-switch off: lease не пишется/не читается, CAS вырождается в прежний безусловный update_task_stage, reaper/reconciler/webhook/startup — байт-в-байт до ORCH-114; существующий pytest tests/ зелёный (FR-7/AC-9/NFR-8)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "never-raise + fail-open/fail-closed: ошибка/повреждённая запись lease/исключение БД не роняют конвейер; hot-path claim/guard fail-open; prod-safety решение fail-closed; WARNING + безопасный дефолт (FR-7/AC-10/NFR-1)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Структурный аудит инвариантов: STAGE_TRANSITIONS / QG_CHECKS / имена-семантика check_* / вердикт-ключи байт-в-байт; новое хранилище аддитивно/идемпотентно (CREATE TABLE IF NOT EXISTS / _ensure_column), схемы существующих таблиц неизменны (NFR-3/AC-11)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-12
+    type: integration
+    description: "Наблюдаемость: GET /queue несёт аддитивный read-only блок владения (держатели/возраст/defer/реклеймы), существующие ключи не сломаны; форсированный/устаревший реклейм даёт Telegram-алерт с кликабельным номером (FR-6/AC-12)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-13
+    type: unit
+    description: "Self-hosting безопасность: механизм владения не инициирует рестарт прод-контейнера, не пушит/force-push в main, не трогает detached deploy-процесс (NFR-5/AC-13)."
+    module: tests/test_orch114_transition_ownership.py
+    expected: PASS
+
+  - id: TC-14
+    type: integration
+    description: "Полный регресс конвейера: pytest tests/ остаётся зелёным; deploy-staging-ребро и deploy-finalizer (Phase C) проходят при включённом механизме без двойных эффектов в одно-акторном happy-path (BR-8)."
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md

@@ -0,0 +1,300 @@
+---
+work_item: ORCH-114
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Durable transition-ownership lease + expected-stage CAS для side-effectful переходов стадий
+
+Work Item: **ORCH-114** — Ownership-lease для side-effectful переходов стадий + умное восстановление при старте
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`** (решение кросс-каттинговое: новый durable-механизм владения трогает движок переходов и ≥5 фоновых акторов).
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-114 — **системный наследник** инцидент-цепочки ORCH-110/111/112/113. Каждый предшественник
+закрыл точечный симптом, но **корневой класс остался открыт: у side-effectful переходов стадий нет
+единого владения**. Факты сверены по коду:
+
+- **Запись стадии не атомарна по предусловию.** `db.update_task_stage` (`src/db.py:671–679`) —
+  голый `UPDATE tasks SET stage=?, updated_at=… WHERE id=?` **без** `WHERE stage=?` (нет CAS, нет
+  epoch/version-колонки). Второй вызов безусловно перезатирает первый.
+- **`advance_stage` ре-ентерабельна без защиты** (`src/stage_engine.py:176–507`). Внутри нет ни
+  in-memory-лока на `task_id`, ни durable-маркера «переход идёт». `current_stage` читается на входе
+  (параметр), тяжёлые под-гейты ребра `deploy-staging → deploy` (security → merge-gate re-test →
+  coverage → image-freshness, **минуты**) и `_handle_merge_verify` (`deploy → done`: `merge_pr`,
+  ratchet baseline, proof-of-merge) исполняются **до** единственной записи стадии на `:402`. Два
+  конкурентных вызова оба читают `deploy-staging`, оба гоняют ВСЕ под-гейты, оба пишут `deploy`.
+- **Минимум 5 путей входят в переход независимо:** монитор (`launcher._try_advance_stage`),
+  Plane-webhook (`plane._try_advance_stage:865`), reconciler F-1 (`advance_if_gate_passed →
+  advance_stage`, `stage_engine.py:573`), job-reaper (`_gate_driven_advance → launcher._try_advance_stage`,
+  `job_reaper.py:406`), deploy-finalizer Phase C (`run_deploy_finalizer → advance_stage`,
+  `stage_engine.py:1980`). Ни один не проверяет, не в этом ли переходе уже другой актор.
+- **6 путей пишут стадию в ОБХОД `advance_stage`** прямым `update_task_stage` (риск BRD §8): 5 в
+  `webhooks/gitea.py` (`:127` arch→dev по ADR-push, `:242` dev→review по CI-green, `:333` review→testing
+  по PR-approved, `:359` review→dev по REQUEST_CHANGES, `:398` *→done по PR-merge) и 1 в
+  `webhooks/plane.py:806` (rollback Rejected).
+- **ORCH-113 (`finalizer_liveness`, adr-0043)** — отправная точка, но: **process-local in-memory**,
+  **только reaper Tier-2**, **только `deploy-staging`**, **теряется при рестарте**. Остаточный кросс-путь
+  (живой монитор внутри `advance_stage(deploy-staging)` + reaper после рестарта / reconciler F-1 /
+  webhook) повторно входит в тот же переход → двойные эффекты и противоречие rollback↔done (инцидент
+  ORCH-111, job 1914 / PR #130).
+
+**Решающий факт, проверенный по коду:** механизм владения по pid уже существует и испытан — merge-lease
+(`merge_gate.py`) штампит `os.getpid()` (`:360`) в lease-файл и реклеймит держателя по `pid_alive`
+(`:452,526`); reaper Tier-1 тоже судит по `pid_alive` (`job_reaper.py:245`). ORCH-114 строит durable
+владение **тем же испытанным pid-приёмом**, а не вводит новый таймер (таймер был источником бага
+ORCH-111).
+
+## Решение
+
+### Сводка
+
+Вводятся **два комплементарных слоя**, оба аддитивные, под единым kill-switch, never-raise:
+
+1. **Durable transition-lease** (владение на **входе** в side-effectful регион) — новая аддитивная
+   таблица `transition_lease` (`src/db.py`, паттерн `repo_freeze`/`coverage_baseline`). Актор
+   **захватывает** владение задачей перед тяжёлой финализацией; второй актор, увидев живого владельца,
+   **не стартует** под-гейты вовсе. Это и убивает класс двойного эффекта (предотвращение, а не починка
+   постфактум). Release — в `try/finally`. **Liveness владельца = `owner_pid` + `owner_boot_id`** (НЕ
+   heartbeat), что делает рестарт-recovery бесплатным (boot-id новый ⇒ старые lease мертвы) и не
+   страдает от блокирующего re-test.
+2. **Expected-stage CAS** (корректность на **коммите** записи стадии) — CAS-вариант
+   `update_task_stage_cas(task_id, expected_stage, new_stage)` →
+   `UPDATE tasks SET stage=?, updated_at=… WHERE id=? AND stage=?`, rowcount==1 ⇒ выиграл, 0 ⇒
+   проиграл гонку → **аборт без побочных эффектов**. Покрывает узкое остаточное окно гонки И 6 путей
+   в обход `advance_stage`.
+
+Слой 1 гарантирует «двое не начнут»; слой 2 гарантирует «даже если начали — запишет один». Defense in
+depth. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/вердикт-ключи/схемы существующих таблиц — байт-в-байт.
+
+### D1 — Механизм: durable-lease (вход) + CAS (коммит), оба обязательны (FR-1, FR-2 / BR-1, BR-2, BR-6)
+
+Почему **оба**, а не один:
+- **CAS-only недостаточно.** CAS стоит на записи стадии — в *конце* `advance_stage` (`:402`). К этому
+  моменту проигравший актор **уже исполнил** `merge_pr` / docker-rebuild / re-test. CAS на коммите не
+  предотвращает двойной побочный эффект *в полёте*. → нужен lease на **входе** в регион.
+- **Lease-only недостаточно** для 6 путей в обход `advance_stage` (gitea/plane прямой
+  `update_task_stage`) и для остаточного окна между «consult lease» и «acquire». → нужен CAS как
+  backstop записи.
+
+Lease — это owner-эксклюзия; CAS — это атомарность-записи. Они ортогональны и складываются.
+
+### D2 — Форма хранения: новая таблица `transition_lease`, без новых колонок на `tasks`/`jobs` (NFR-3, NFR-4)
+
+Durable-владение хранится в **новой аддитивной таблице** (`CREATE TABLE IF NOT EXISTS`, паттерн
+`repo_freeze`/`coverage_baseline`/`lessons`), а **не** в колонках `tasks`/`jobs`. Это **усиливает**
+NFR-3: схемы существующих таблиц остаются буквально байт-в-байт; добавляется ровно один объект.
+
+```sql
+CREATE TABLE IF NOT EXISTS transition_lease (
+    task_id       INTEGER PRIMARY KEY,   -- одна задача = ≤1 активный владелец перехода
+    owner         TEXT NOT NULL,         -- актор: monitor|reaper|reconciler|webhook|finalizer
+    owner_pid     INTEGER,               -- pid процесса-держателя (как merge-lease)
+    owner_boot_id TEXT,                  -- нонс старта процесса (рестарт ⇒ смена ⇒ старый lease мёртв)
+    run_id        INTEGER,               -- agent_runs.id, если применимо
+    stage         TEXT,                  -- from-стадия, на которой захвачено (контекст/наблюдаемость)
+    acquired_at   TEXT NOT NULL DEFAULT (datetime('now'))
+);
+```
+
+**CAS на запись стадии — через предикат ожидаемой стадии, без epoch-колонки.** В текущей одно-процессной
+модели каждое side-effectful ребро ведёт в **отличную** стадию, поэтому `WHERE id=? AND stage=?` —
+полный и корректный compare-and-swap (стадия *и есть* версия). Отдельная `epoch/version`-колонка была бы
+неиспользуемой машинерией → отвергнута; задокументирована как форвард-расширение под будущий
+`--workers>1` (если появится same-stage ре-ентерабельность). Это решает FR-2 «ожидаемая текущая стадия
+**и/или** эпоха» в пользу стадии.
+
+### D3 — Liveness владельца = pid + boot-id, НЕ heartbeat (NFR-4, NFR-6)
+
+Владелец считается **живым** ⇔ `owner_boot_id == <текущий boot-id процесса>` **И**
+`merge_gate.pid_alive(owner_pid)`. Иначе lease **устарел** → реклеймится.
+
+Почему не heartbeat: ORCH-113 (adr-0043, раздел «Альтернативы») **сам отверг** durable-heartbeat
+доводом «блокирующий re-test не может бить heartbeat» — `merge_retest_timeout_s=900` синхронно держит
+поток монитора, heartbeat с коротким окном дал бы ложное «мёртв». pid-liveness свободна от этого: процесс
+жив весь re-test → lease жив; **никакого heartbeat-кода в блокирующей финализации**.
+
+- **Рестарт (self-deploy):** новый процесс имеет новый `boot_id` → все ранее записанные lease мгновенно
+  «мертвы» (boot-id mismatch) → реклеймятся → requeued job (после `requeue_running_jobs`) переисполняет
+  переход идемпотентно (D7). Это durable-аналог «in-memory реестр обнуляется на рестарте» (на чём держится
+  ORCH-113), но **переживает** рестарт как durable-запись для проверки другим актором/тиром.
+- **Реальная смерть pid в том же процессе:** `pid_alive` False → реклейм немедленно (как reaper Tier-1).
+- **Живой, но зависший владелец (pid жив, не прогрессирует):** добивается **Tier-3 backstop**
+  `reaper_max_running_s` (ниже, D8) — ограниченное время, маркер владения backstop **не обходит**.
+
+### D4 — Область охвата: lease на side-effectful рёбрах, CAS — на всех записях стадии + 6 обходных путях
+
+| Путь записи стадии | Lease | CAS | Обоснование |
+|--------------------|:-----:|:---:|-------------|
+| `deploy-staging → deploy` под-гейты (`stage_engine.py:321–402`) | **да** | да | необратимо: merge re-test/rebuild/инициация |
+| `deploy → done` `_handle_merge_verify` (`:397–402,1726`) | **да** | да | необратимо: `merge_pr`, ratchet baseline |
+| Phase C `run_deploy_finalizer` (`:1898–2009`) | **да** | да | необратимо: прод-деплой/мерж |
+| прочие рёбра `advance_stage` (created→…→testing) | нет | да | обратимы; CAS инертен без гонки |
+| rollback-записи `_handle_*_rollback` (`:740…1422`) | нет¹ | да | защита от rollback↔done (BR-6) |
+| 5× `gitea.py` прямой `update_task_stage` | нет | **да** | закрыть обход (BRD §8) |
+| 1× `plane.py:806` rollback | нет | **да** | закрыть обход (BRD §8) |
+
+¹ rollback исполняет тот же единственный владелец lease (он держит lease на входе в регион), поэтому
+отдельный lease на rollback-запись не нужен — достаточно CAS.
+
+**Граница (фиксируется здесь):** обходные пути gitea/plane получают **CAS** (дёшево, закрывает дыру
+BRD §8), но **не** полный lease — они не исполняют необратимых шагов (только enqueue агента/флип
+индикативной стадии). CAS не даёт им перетереть авторитетную запись владельца.
+
+### D5 — Интеграция в `advance_stage` (FR-1, FR-2, AC-1, AC-3)
+
+```
+advance_stage(...):
+  if transition_lease.applies(repo) and <ребро side-effectful>:
+      if not transition_lease.acquire(task_id, owner, run_id, current_stage):
+          return AdvanceResult(advanced=False, note="transition-lease-busy")  # чистый аборт
+      try:
+          <под-гейты / _handle_merge_verify / финализация — как сейчас>
+          # запись стадии — через CAS:
+          if not update_task_stage_cas(task_id, current_stage, next_stage):
+              return AdvanceResult(advanced=False, note="stage-cas-lost")     # без побочных эффектов
+          <enqueue next agent, notify, …>
+      finally:
+          transition_lease.release(task_id, owner)   # в т.ч. на исключении/откате (AC-3)
+```
+
+Проигравший acquire или CAS — **не** мутирует стадию и **не** исполняет ни одного side-effect. Release
+гарантирован `finally` (lease «не течёт» на исключении/rollback). Когда kill-switch off — `acquire`
+no-op→True, CAS вырождается в прежний безусловный `update_task_stage` → байт-в-байт (D9, AC-9).
+
+### D6 — Reaper / reconciler / webhook / startup осведомлены о владении (FR-3, FR-5, BR-3, BR-5)
+
+- **Reaper** (`job_reaper.py`): перед реклеймом/re-drive консультирует durable-lease на **всех**
+  релевантных путях (обобщение ORCH-113 за пределы Tier-2/`deploy-staging`): **живой** владелец → defer
+  (лог + счётчик); **мёртвый/устаревший** → реклейм. Tier-3 (`reaper_max_running_s`) маркер **игнорирует**
+  (добивает зависшего). Атомарный `reap_running_job` rowcount-guard сохранён. **Реклейм/реап освобождает
+  lease задачи** (force) — lease не переживает реап.
+- **Reconciler F-1** (`reconciler.py`, перед `advance_if_gate_passed` на `:249`): новый skip-guard по
+  образцу escalated/Blocked/task-deps — активный живой lease → silent defer.
+- **Webhook** (`plane.py` Approved/`:413` + Confirm Deploy/`:219`): активный живой lease → defer; поздний
+  легитимный сигнал отработает после release или станет идемпотентным no-op.
+- **`finalizer_liveness` (ORCH-113) сохраняется без правок** как поведение при **выключенном** ORCH-114
+  (надстройка durable-слоя поверх, TRZ §2): kill-switch off ⇒ reaper консультирует in-memory
+  `finalizer_liveness` (Tier-2/`deploy-staging`, ровно ORCH-113); kill-switch on ⇒ reaper консультирует
+  durable `transition_lease` (cross-path). Так ORCH-114 **обобщает** ORCH-113, не ломая его контракт/тест.
+
+### D7 — Умное восстановление = stale-clear + авторитетные факты, БЕЗ нового «recovery-мозга» (FR-4, BR-4, BR-6, NFR-7)
+
+Ключевое архитектурное решение, снимающее риск BRD §8 («некорректный smart-recovery сам станет источником
+двойного применения»): ORCH-114 **не строит** новую машину восстановления. Восстановление = композиция:
+
+1. **`requeue_running_jobs()`** (существует, `db.py:1320`; в `main.lifespan` до старта reaper) — running→queued.
+2. **`transition_lease.recover_on_startup()`** — boot-id новый ⇒ все ранее записанные lease мертвы;
+   reaper/claim их реклеймят (наблюдаемо: лог + алерт на форсированный реклейм).
+3. **Идемпотентность re-drive — уже обеспечена авторитетными durable-фактами предшественников**, lease их
+   не дублирует, а лишь гарантирует **последовательную** (не конкурентную) их проверку:
+   - **SHA-in-main** (ORCH-071/073/093): `merge_gate.verify_merged_to_main` / `ensure_open_pr →
+     "already-in-main"` → повторный `_handle_merge_verify` доводит до `done` **без** второго `merge_pr`.
+   - **Маркер `INITIATED`** (self-deploy ORCH-036): Phase B idempotency-guard (`stage_engine.py:1567`) →
+     повторный заход не инициирует второй прод-деплой.
+   - **Coverage-ratchet CAS** (ORCH-027): `ratchet_coverage_baseline` (`UPDATE … WHERE coverage<=?`) —
+     повторный ratchet идемпотентен по построению.
+
+Итог: после смерти процесса в середине финализации система сходится к **единственному** исходу —
+незавершённое дорешается, уже применённый необратимый шаг **не** повторяется (источник истины «уже
+применено» = авторитетные факты, не in-memory).
+
+### D8 — Сквозной бюджет reaper: без новых таймаутов (NFR-6)
+
+Lease **не вводит** собственный долгий TTL. Его жёсткий потолок возраста **совпадает** с Tier-3
+`reaper_max_running_s` (5400): reaper при реапе job на Tier-3 force-освобождает lease — lease и job
+реклеймятся в один момент. Раннее обнаружение смерти — через pid+boot (D3), а не таймер. Поэтому
+сквозной инвариант ORCH-065/109/110/113 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work ≈4460)
++ grace` **остаётся нетронутым**, `reaper_finalize_grace_s`/`reaper_max_running_s` **не меняются**. Новых
+бюджетных констант, требующих согласования, нет.
+
+### D9 — never-raise / fail-open / fail-closed / kill-switch (FR-7, NFR-1, NFR-8, AC-9, AC-10)
+
+- **Hot-path `claim_next_job` НЕ трогается** — lease консультируется на пути перехода/финализации и в
+  reaper/reconciler/webhook, **не** в claim. → общая очередь всех проектов не может заклиниться на баге
+  lease (fail-open по построению, AC-8 ORCH-088 цел).
+- **acquire/guard-ошибка** (БД-сбой/повреждённая строка): на side-effectful пути → консервативный
+  **defer/abort текущей попытки без побочных эффектов** (fail-closed к недвоению; не вечный клин — следующий
+  тик/reaper переисполнит, в пределе Tier-3 добьёт). guard reconciler/webhook → консервативный skip.
+- **CAS-ошибка** → аборт записи (не слепой write).
+- **Kill-switch `transition_lease_enabled=False`** → lease не пишется/не читается; CAS вырождается в
+  прежний `update_task_stage`; reaper → ORCH-113 fallback; reconciler/webhook skip-guard инертен → **байт-в-байт**
+  до-ORCH-114 (зелёный существующий `pytest tests/` без правок ожиданий).
+
+### D10 — Наблюдаемость и конфигурация (FR-6, BR-7, NFR-2, AC-12)
+
+- `GET /queue` — аддитивный read-only блок `transition_lease` (держатели/owner/stage/возраст/defer-счётчики/
+  форсированные/устаревшие реклеймы); существующие ключи не тронуты.
+- **Telegram-алерт** (`send_telegram`, кликабельный номер) на форсированный/устаревший реклейм.
+- **Опц.** `POST /transition-lease/release?work_item=<id>` — операторский ручной реклейм (паттерн
+  `POST /serial-gate/unfreeze`).
+- **Опц.** lessons-journal автозапись (ORCH-098, `source="auto"`) на форсированный реклейм.
+- **Флаги** (`config.py`): `transition_lease_enabled: bool = True` (env `ORCH_TRANSITION_LEASE_ENABLED`,
+  kill-switch); `transition_lease_repos: str = ""` (CSV; **пусто → self-hosting only**, паттерн
+  `coverage_gate_repos`/`serial_gate_repos` → enduro не затронут). Новых таймаутов нет (D8).
+- **Leaf `src/transition_lease.py`** (never-raise, паттерн `serial_gate`/`coverage_gate`/`finalizer_liveness`):
+  `applies(repo)` / `acquire(task_id, owner, run_id, stage) -> bool` / `is_held_by_live_owner(task_id) -> bool`
+  / `release(task_id, owner=None)` / `reclaim_if_stale(task_id) -> bool` / `recover_on_startup()` / `snapshot()`.
+
+## Альтернативы
+
+- **Только CAS/epoch, без lease** — отвергнуто: CAS на коммите не предотвращает двойной side-effect
+  *в полёте* (re-test/rebuild/merge исполняются до записи стадии). Не закрывает класс ORCH-111.
+- **Только durable-lease, без CAS** — отвергнуто: не покрывает 6 путей в обход `advance_stage` и узкое
+  окно «consult→acquire».
+- **Heartbeat-liveness** — отвергнуто доводом самого ORCH-113: блокирующий 900s re-test не может бить
+  heartbeat → ложное «мёртв». pid+boot свободна от этого.
+- **Lease-файл per-task** (клон merge-lease) — отвергнуто: CAS на запись стадии — DB-операция; держать
+  владение в той же транзакционной БД когерентнее и позволяет атомарный acquire тем же rowcount-guard
+  идиомом (`claim_next_job`/`reap_running_job`), что код уже доверяет. merge-lease-файл остаётся per-**repo**
+  для **другой** задачи (сериализация мержей между задачами репо) — не дублируется.
+- **`epoch/version`-колонка на `tasks`** — отвергнуто (для текущей модели): стадия *и есть* версия для
+  side-effectful рёбер; колонка была бы неиспользуемой. Задокументирована как форвард-расширение.
+- **Sub-state `finalizing` в `jobs.status`** — отвергнуто (как в ORCH-113): меняет семантику статуса для
+  claim/requeue/reconciler/reaper — нарушение NFR-3.
+- **Per-stage grace, покрывающая Σ финализации** — отвергнуто (как в ORCH-113): нарушает бюджет
+  `5400 > Σ+grace`; таймер = источник бага.
+- **Бесшовно для всех репо (без self-hosting-скоупа)** — отвергнуто: по образцу coverage/serial-gate
+  область по умолчанию self-hosting (необратимые эффекты живут на self-hosting-рёбрах); enduro инертен.
+- **Новый бесшовный «recovery-мозг»** — отвергнуто (BRD §8 риск): композиция requeue + stale-clear +
+  авторитетные факты (D7) проще и не вносит нового источника двойного применения.
+
+## Последствия
+
+- **+** Класс двойного эффекта/противоречия rollback↔done закрыт **в корне** (предотвращение на входе),
+  а не починкой постфактум; покрыты конкурентный, reaper-после-рестарта, reconciler и webhook пути.
+- **+** Рестарт-safe без нового таймера и без переписывания на multi-process (boot-id готовит почву под
+  будущий `--workers>1`, NFR-4).
+- **+** Сквозной бюджет reaper и все инварианты конвейера (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+  вердикт-ключи) не тронуты; схемы существующих таблиц байт-в-байт; +1 аддитивная таблица.
+- **+** Дыра обходных путей gitea/plane (BRD §8) закрыта CAS.
+- **−** Гарантия эксклюзии валидна при одном процессе/одной БД (как ORCH-113); durable-lease лишь делает
+  её **корректной** и для рестарта/будущей multi-process — но полноценная multi-writer верификация — вне
+  объёма (риск TR-6 в `10-tech-risks.md`).
+- **−** Узкое окно «штамп `finished_at` → acquire» (как ORCH-113) маркером не покрыто — закрыто прежним
+  grace=300 + CAS-backstop.
+- **Откат:** `ORCH_TRANSITION_LEASE_ENABLED=false` → байт-в-байт до-ORCH-114 (таблица остаётся инертной).
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-114/01-brd.md`
+- TRZ: `docs/work-items/ORCH-114/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-114/03-acceptance-criteria.md`
+- Данные: `docs/work-items/ORCH-114/08-data-requirements.md`
+- Риски: `docs/work-items/ORCH-114/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`
+- Предшественники: `adr-0043` (ORCH-113 finalizer-liveness), `adr-0042` (ORCH-110 merge-retest),
+  `adr-0027`/`merge-lease` (ORCH-043), `adr-0040` (ORCH-109 бюджеты), `adr-0011` (ORCH-065 reaper),
+  `adr-0029` (ORCH-027 coverage-ratchet)
+- Сверено по коду: `src/db.py:671–679,1320–1335,1464–1505,988–1055`, `src/stage_engine.py:176–507,1726–2009`,
+  `src/finalizer_liveness.py`, `src/job_reaper.py:245,406,436–461`, `src/reconciler.py:249,515–575`,
+  `src/webhooks/plane.py:219,413,806`, `src/webhooks/gitea.py:127,242,333,359,398`,
+  `src/merge_gate.py:311–411,452,526`
+</content>
+</invoke>

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

@@ -0,0 +1,66 @@
+---
+work_item: ORCH-114
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным: ORCH-114 — Durable transition-ownership lease + expected-stage CAS
+
+Work Item: **ORCH-114** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable / информационный (гейтом не парсится). Сверено по `src/db.py`.
+
+## Изменения схемы БД
+
+**Ровно один новый объект — аддитивная таблица `transition_lease`** (`CREATE TABLE IF NOT EXISTS` в
+`init_db()`, паттерн `repo_freeze`/`coverage_baseline`/`lessons`):
+
+```sql
+CREATE TABLE IF NOT EXISTS transition_lease (
+    task_id       INTEGER PRIMARY KEY,   -- одна задача = ≤1 активный владелец side-effectful перехода
+    owner         TEXT NOT NULL,         -- актор-держатель: monitor|reaper|reconciler|webhook|finalizer
+    owner_pid     INTEGER,               -- pid процесса-держателя (liveness, как merge-lease os.getpid())
+    owner_boot_id TEXT,                  -- нонс старта процесса; рестарт ⇒ смена ⇒ прежний lease мёртв
+    run_id        INTEGER,               -- agent_runs.id если применимо (контекст)
+    stage         TEXT,                  -- from-стадия захвата (наблюдаемость/контекст)
+    acquired_at   TEXT NOT NULL DEFAULT (datetime('now'))
+);
+```
+
+Индекс не требуется (доступ по PK `task_id`); `snapshot()` для `GET /queue` — full-scan по малой таблице
+(в любой момент строк ≈ числу активных side-effectful переходов, единицы).
+
+**Изменений существующих таблиц НЕТ.** `tasks` / `jobs` / `agent_runs` / `events` / `job_deps` /
+`repo_freeze` / `coverage_baseline` / `lessons` — схемы **байт-в-байт** (NFR-3, AC-11). **Колонка
+`epoch/version` НЕ добавляется** (ADR-001 D2: для одно-процессной модели стадия *и есть* версия CAS;
+epoch — форвард-расширение, не вводится сейчас).
+
+## Новые/изменённые сущности
+
+- **Таблица `transition_lease`** — durable-владение side-effectful переходом задачи. Инвариант:
+  активная строка для `task_id` ⇔ некий актор держит владение переходом этой задачи. **Живой** владелец ⇔
+  `owner_boot_id == <boot-id текущего процесса>` И `merge_gate.pid_alive(owner_pid)`; иначе **устарел** →
+  реклеймится. Захват — атомарный rowcount-guard (паттерн `claim_next_job`/`reap_running_job`): `INSERT … ON
+  CONFLICT(task_id)` берётся только при отсутствии живого владельца (иначе rowcount==0 → busy).
+- **Функция `update_task_stage_cas(task_id, expected_stage, new_stage) -> bool`** (новая, в `db.py`):
+  `UPDATE tasks SET stage=?, updated_at=datetime('now') WHERE id=? AND stage=?`; возвращает `cur.rowcount==1`
+  (выиграл CAS) / `False` (проиграл — стадия уже не та, что читали → аборт без побочных эффектов).
+  Прежний `update_task_stage` **сохраняется без изменений** (путь kill-switch-off и записи вне
+  side-effectful области).
+
+## Совместимость данных / миграции
+
+- **Аддитивно/идемпотентно/restart-safe:** `CREATE TABLE IF NOT EXISTS` в `init_db()` — повторный старт
+  no-op; на живой общей прод-БД данные enduro-trails не затрагиваются (новая таблица изолирована).
+- **Никакого backfill** существующих строк не требуется (таблица заполняется рантаймом при захвате владения).
+- **Рестарт-семантика:** durable-строки lease переживают рестарт физически; новый процесс получает новый
+  `owner_boot_id` → ранее записанные строки трактуются как устаревшие и реклеймятся (ADR-001 D3/D7);
+  `recover_on_startup()` зачищает их наблюдаемо (после `requeue_running_jobs`).
+- **Откат (NFR-8):** при `transition_lease_enabled=False` таблица не читается/не пишется и остаётся
+  инертной; удалять её при откате не требуется. Поведение БД-слоя — байт-в-байт до-ORCH-114.
+- **enduro-trails:** при `transition_lease_repos=""` (self-hosting only) механизм для enduro не активируется
+  — нулевая регрессия.
+</content>

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

@@ -0,0 +1,47 @@
+---
+work_item: ORCH-114
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-114 — Durable transition-ownership lease + expected-stage CAS
+
+Work Item: **ORCH-114** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации и митигейшн. Сверено по коду.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| **TR-1** | **Дедлок / over-block:** «жёсткое» владение заклинивает легитимный путь — reaper не добивает зависший finalizer, задача висит нетерминальной с удержанным lease (клинит serial-gate репо). | Сред. | Выс. | ADR D3/D8: liveness = pid+boot (мёртвый владелец реклеймится немедленно); Tier-3 `reaper_max_running_s` **игнорирует** lease и добивает зависшего живого; reaper при реапе force-освобождает lease. `release` в `try/finally`. Опц. `POST /transition-lease/release`. Обязательный тест AC-3 (release на исключении/откате) + AC-5 (bounded reclaim). |
+| **TR-2** | **Lease «течёт»** при исключении/откате в `advance_stage` → задача навсегда заблокирована. | Сред. | Выс. | `release` строго в `finally` вокруг всего side-effectful региона (ADR D5); регресс-тест AC-3 (acquire→raise→release). Бэкстоп: stale-реклейм по pid/boot + Tier-3. |
+| **TR-3** | **Buggy «smart recovery»** сам становится источником двойного применения необратимого шага после рестарта. | Сред. | Выс. | ADR D7: НЕ новый recovery-мозг, а композиция `requeue_running_jobs` + stale-clear + **существующие авторитетные факты** (SHA-in-main ORCH-071/073, `INITIATED` ORCH-036, coverage-ratchet CAS). Обязательный restart-recovery регресс (BR-8/AC-6): процесс убит в середине финализации → ровно один исход, без второго `merge_pr`/ratchet/deploy. |
+| **TR-4** | **Скрытые обходные пути** (gitea `handle_push`/`handle_ci_status`/`handle_pr`, plane `_rollback_stage:806`) пишут стадию мимо `advance_stage` → CAS-инвариант обходится. | Выс. | Сред. | ADR D4: 6 обходных `update_task_stage` переведены на `update_task_stage_cas`; граница зафиксирована в ADR. Структурный аудит (AC-11): ни одного безусловного `update_task_stage` на side-effectful/конкурентных путях при флаге on. |
+| **TR-5** | **Гонка consult→acquire:** актор A прошёл guard «lease свободен», но B захватил между проверкой и acquire A. | Сред. | Сред. | Двойной слой (ADR D1): даже если оба прошли consult, `acquire` атомарен (rowcount-guard, один INSERT выигрывает), а проигравший CAS на коммите не пишет стадию и не делает side-effect. Consult — лишь дешёвый front-defer, не источник истины. |
+| **TR-6** | **Multi-process (`--workers>1`):** pid+boot-liveness и SQLite-CAS на одной БД корректны для одного процесса; ввод воркеров потребует верификации (SQLite write-lock contention, boot-id на процесс). | Низ. | Сред. | Вне объёма (BRD §scope: модель остаётся одно-процессной). Durable-форма (таблица + pid/boot + CAS) спроектирована совместимой; epoch-колонка — документированное форвард-расширение (ADR D2). Зафиксировано как ограничение в adr-0045 «Последствия (−)». |
+| **TR-7** | **Бюджетный конфликт:** lease, удерживаемый дольше `reaper_max_running_s`, нарушает сквозной инвариант ORCH-065/109/110/113. | Низ. | Выс. | ADR D8: lease без собственного TTL, потолок = Tier-3 `reaper_max_running_s` (5400); `reaper_finalize_grace_s`/`reaper_max_running_s` НЕ меняются; инвариант `5400 > Σ(≈4460)+grace` цел. Новых бюджетных констант нет. |
+| **TR-8** | **Регрессия ORCH-113:** обобщение `finalizer_liveness` ломает его контракт/тест или меняет поведение при выключенном ORCH-114. | Сред. | Сред. | ADR D6: `finalizer_liveness.py` **не правится**, остаётся поведением kill-switch-off (reaper → in-memory, Tier-2/`deploy-staging`); on → durable cross-path. Зелёный существующий тест ORCH-113 + AC-9 (флаг off → байт-в-байт). Сверка маркеров ORCH-113 (TRACEABILITY/ORCH-078). |
+| **TR-9** | **Сбой механизма заклинивает общую очередь** всех проектов (enduro + orchestrator), нарушая AC-8 ORCH-088. | Низ. | Выс. | ADR D9: hot-path `claim_next_job` **не трогается** (lease консультируется на пути перехода/reaper/reconciler/webhook, не в claim). never-raise; acquire/guard-ошибка → defer (не клин), CAS-ошибка → аборт записи. Регресс AC-10. |
+| **TR-10** | **Ложная stale-реклейм** живого владельца (pid переиспользован ОС после рестарта, boot-id совпал случайно). | Низ. | Сред. | `owner_boot_id` — достаточно энтропийный нонс старта процесса (не предсказуемый), плюс pid-проверка; коллизия (тот же boot-id И тот же pid у нового процесса) практически невозможна. Бэкстоп: CAS на коммите не даст двойной записи даже при ложном реклейме. |
+
+## Сводный вывод
+
+Доминирующий класс рисков — **корректность владения и восстановления на необратимых рёбрах**
+(TR-1/TR-2/TR-3) и **полнота охвата путей** (TR-4/TR-5). Все они снимаются архитектурой defense-in-depth
+(lease на входе + CAS на коммите) и принципом «не строить новый recovery-мозг, опереться на существующие
+авторитетные факты» (D7) — это сознательно минимизирует площадь нового кода, способного двоить
+необратимый шаг.
+
+**Эскалация `arch:major-change`: рекомендуется.** Изменение вводит новый durable-компонент (leaf
+`transition_lease` + таблица), трогает движок переходов и ≥5 фоновых акторов и помечается сводным сквозным
+ADR (adr-0045). Реализующему агенту (developer) обязательны: регресс двойного эффекта (AC-1, red→green),
+restart-recovery (AC-6), kill-switch-off байт-в-байт (AC-9), сохранность бюджета (AC-5/NFR-6) и аудит
+обходных путей (TR-4/AC-11). Возврата в анализ не требуется — требования полны и реализуемы без нарушения
+архитектурных принципов (всё в Docker/одном процессе/SQLite, без новых внешних зависимостей и без рестарта
+прода). Остаточный риск для прод-конвейера (self-hosting) при дисциплине тестов — **низкий**; единственное
+осознанное ограничение — multi-process (TR-6), явно вне объёма.
+</content>

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

@@ -0,0 +1,119 @@
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-114
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-114
+version: 2
+---
+
+# Review ORCH-114 — Durable transition-ownership lease + expected-stage CAS
+
+## Summary
+
+Повторное ревью (цикл 2). Прошлый вердикт был `REQUEST_CHANGES` из-за **частичной
+незавершённости документации golden-source** (два P1 + три P2/P3). Кода-корректность и
+инварианты конвейера уже тогда были без P0/P1. В этом цикле developer **закрыл все ранее
+поднятые findings**:
+
+- **P1 `.env.example`** → закрыт: добавлены `ORCH_TRANSITION_LEASE_ENABLED=true` /
+  `ORCH_TRANSITION_LEASE_REPOS=` с подробной нормативной шапкой (рядом с блоком reaper-флагов).
+- **P1 `CLAUDE.md`** → закрыт: добавлена полноценная паспорт-секция «Единое владение
+  side-effectful переходами: durable-lease + expected-stage CAS (ORCH-114)» (механизм, два
+  слоя, инвариант, флаги, ADR-ссылки) — по образцу ORCH-112/113.
+- **P2 витрина `docs/overview/`** → закрыта: `tech-data-model.md` (строка таблицы
+  `transition_lease`), `tech-observability.md` (упоминание блока `/queue`),
+  `tech-architecture.md` (компонент `Transition-lease`).
+- **P2 расхождение код↔ADR D4 (CAS на rollback-записях)** → закрыто: введён общий хелпер
+  `_rollback_stage_cas`, и все четыре in-region rollback-записи (`_handle_merge_gate_rollback`/
+  `_handle_security_gate`/`_handle_coverage_gate`/`_handle_image_freshness`) теперь пишут
+  `development` через тот же expected-stage CAS. Реализация совпала с собственным ADR D4;
+  добавлены целевые тесты (TC-11 `test_tc11_inregion_rollback_writes_use_cas`,
+  `test_tc11_rollback_cas_lost_aborts_without_overwriting_done`).
+- **P2 изоляция тестов** → закрыта: убран module-level `os.environ.setdefault("ORCH_DB_PATH")`,
+  `test_webhooks.py` пинит собственный реестр per-test, добавлен autouse-fixture
+  `_disable_transition_lease` (kill-switch off для всего suite по образцу `_disable_merge_verify`).
+
+Архитектура реализована **в точном соответствии с ADR-001 D1–D10**: durable-lease на входе
+(`acquire`/`release` в `try/finally`) + expected-stage CAS на записи (включая 6 путей в обход
+`advance_stage`), liveness по `pid`+`boot_id` без heartbeat, реклейм при рестарте
+(`recover_on_startup` в `main.lifespan`), reaper/reconciler/webhook defer при живом владельце,
+Tier-3 backstop добивает зависшего. `src/transition_lease.py` — чистый never-raise leaf
+(импортирует только `db`+`config`, лениво `merge_gate.pid_alive`/`qg.checks`/`notifications`).
+
+**Инварианты конвейера (AC-11):** `src/stages.py` и `src/qg/checks.py` **не тронуты** (нет в
+диффе), `STAGE_TRANSITIONS`/`QG_CHECKS` встречаются в src-диффе только в комментарии;
+machine-verdict ключи не тронуты; БД аддитивна (одна таблица `transition_lease`,
+`CREATE TABLE IF NOT EXISTS`, без epoch-колонки). hot-path `claim_next_job` lease не
+консультирует (AC-10/fail-open).
+
+**Багфикс-трек (ORCH-019/BR-4):** задача `bug→escalate full-cycle`. Регресс-тест-фиксатор
+**присутствует**: `test_tc01_concurrent_entry_no_double_effect` (зелёный с lease) +
+`test_tc01_red_before_fix_demonstration` (красный при kill-switch off — второй актор
+переисполняет все под-гейты, воспроизводя класс ORCH-111). Требование выполнено.
+
+**Прогоны (verified):**
+- `pytest tests/test_orch114_transition_ownership.py tests/test_webhooks.py` — **50 passed**
+  (именно та комбинация двух модулей, что в прошлом цикле давала 4 падения — изоляция
+  подтверждённо починена).
+- `pytest tests/` (полный) — **2052 passed** в детерминированном порядке → AC-9 (байт-в-байт
+  при kill-switch off) и CI-green выполняются операционно; ORCH-113-тесты в наборе зелёные
+  (контракт предшественника не сломан, ORCH-078).
+
+## Findings
+
+### P0 — Blocker
+- _(нет)_
+
+### P1 — Must fix
+- _(нет)_
+
+### P2 — Should fix
+- _(нет)_
+
+### P3 — Nice to have
+- [ ] **Merge-lease не освобождается на (практически недостижимой) ветке CAS-lost в
+  rollback'е coverage/image-freshness.** В `_handle_coverage_gate`/`_handle_image_freshness`
+  `release_merge_lease` стоит **после** `_rollback_stage_cas`, поэтому при проигранном CAS
+  (`return True`) штатное освобождение merge-lease пропускается. Под держимым transition-lease
+  эта ветка практически недостижима (единственный владелец → CAS почти всегда выигрывает; чтобы
+  проиграть, нужен аномальный bypass-писатель, сдвинувший стадию с `deploy-staging`). Даже в
+  этом крайнем случае утечка **ограничена** собственным TTL+reclaim merge-lease (ORCH-043/065).
+  Корректность недвоения не нарушена. При желании — продублировать holder-aware
+  `release_merge_lease` до CAS-проверки (или задокументировать намеренный аборт). Не блокер.
+  _Ссылка: ADR-001 D1/D4, ORCH-027/058 rollback._
+- [ ] **`reconciler`/`plane._try_advance_stage` зовут `is_held_by_live_owner(task_id)` без
+  предварительного `applies(repo)`** (в отличие от reaper). Для out-of-scope, но включённого
+  репо (enduro при дефолте) это безвредный лишний `SELECT` (строк нет → `False`). Функционально
+  корректно; ради нулевого оверхеда можно добавить дешёвый `applies`-гард. (Перенос P3 из цикла 1
+  — остаётся косметикой.)
+
+## Документация
+
+**Обновлено и проверено (полно):**
+- `.env.example` — `ORCH_TRANSITION_LEASE_ENABLED` / `ORCH_TRANSITION_LEASE_REPOS` (канон ключей
+  старта, ORCH-101).
+- `CLAUDE.md` — паспорт-секция ORCH-114.
+- `docs/overview/` — `tech-data-model.md` / `tech-observability.md` / `tech-architecture.md`
+  (витрина системы, ORCH-011).
+- `CHANGELOG.md` — подробная запись ORCH-114 в `[Unreleased]`.
+- `docs/architecture/README.md` + `internals.md` — компонент, секция, таблица БД, API-эндпоинт
+  `POST /transition-lease/release`, блок `/queue`.
+- ADR: `docs/work-items/ORCH-114/06-adr/ADR-001-…` + сквозной
+  `docs/architecture/adr/adr-0045-…` — полные, со сверкой по коду.
+- Work-item доки `02-trz`/`03-acceptance-criteria`/`04-test-plan`/`08-data-requirements`/
+  `10-tech-risks` — на месте.
+
+**Необновлённой документации при изменении `src/` не выявлено.** Пунктов README «Известные
+ограничения», закрываемых этим PR, нет.
+
+## Verdict rationale
+Все P0/P1/P2 прошлого цикла закрыты; новых P0/P1 не выявлено по всем четырём осям
+(ТЗ/AC, ADR, качество кода + обязательный регресс-тест багфикс-трека, документация
+golden-source). Остаются только два P3-наблюдения (косметика/недостижимая граница), не
+блокирующие приёмку. Полный `pytest tests/` зелёный (2052 passed), инварианты конвейера и
+схемы существующих таблиц — байт-в-байт. → **APPROVED**.

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

@@ -0,0 +1,85 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-114
+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-114
+---
+
+# Test Report — ORCH-114
+
+Durable transition-ownership lease + expected-stage CAS для side-effectful переходов стадий
+(закрытие корневого класса инцидент-цепочки ORCH-110/111/112/113).
+
+## Окружение
+- 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-114-bug-pipeline-stage-transitions/`
+- Branch: `feature/ORCH-114-bug-pipeline-stage-transitions`
+- Дата: 2026-06-15
+
+## Предусловия
+- Review-вердикт `12-review.md`: **APPROVED** (цикл 2, нет P0/P1/P2; только два P3-наблюдения).
+- Тесты прогнаны в worktree ветки задачи (не в общем `/repos/orchestrator`) — анти-гонка checkout.
+
+## Smoke API (read-only, prod 8500)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — **OK**.
+- `GET /status` → активная задача 103 (ORCH-114, stage=testing) видна — **OK**.
+- `GET /queue` → блок `serial_gate` присутствует (ORCH-088), блок `auto_labels` присутствует
+  (ORCH-089) — **OK** (смок-инвариант соблюдён).
+- Блок `transition_lease` в `/queue` прод-инстанса (8500) **отсутствует** — это **ожидаемо**, не
+  регресс: новый код ORCH-114 живёт в ветке/worktree и ещё не задеплоен в прод (стадия testing
+  предшествует deploy-staging/deploy). Наблюдаемость блока `transition_lease` покрыта unit-тестами
+  TC-12 (`test_tc12_queue_block_wired`).
+
+## Результаты — покрытие каждого TC из 04-test-plan.yaml
+
+| TC ID | Тип | Описание (кратко) | AC | Результат |
+|-------|-----|-------------------|----|-----------|
+| TC-01 | integration | ОБЯЗ. РЕГРЕСС: конкурентный вход в `advance_stage(deploy-staging)` — каждый side-effect ровно раз; красный до фикса, зелёный после | AC-1 | PASS |
+| TC-02 | unit | CAS-запись стадии: первый writer rowcount=1, второй lost-race rowcount=0, без мутации | AC-2 | PASS |
+| TC-03 | unit | Жизненный цикл владения: acquire/release в `try/finally` (норм + исключение), durable-видимость | AC-3 | PASS |
+| TC-04 | integration | Reaper defer при живом владении за пределами Tier-2/deploy-staging; rowcount-guard сохранён | AC-4 | PASS |
+| TC-05 | unit/integration | Reaper добивает мёртвое/устаревшее владение в Tier-3 backstop; бюджет-инвариант сохранён | AC-5 | PASS |
+| TC-06 | integration | Умное восстановление при рестарте: сходимость к единственному исходу без повторного эффекта | AC-6 | PASS |
+| TC-07 | integration | Reconciler F-1 defer/skip при активном lease; fail-safe консервативный skip | AC-7 | PASS |
+| TC-08 | integration | Webhook-путь (Approved/Confirm Deploy) defer при активном lease; поздний сигнал не теряется | AC-8 | PASS |
+| TC-09 | integration | Kill-switch off: lease инертен, CAS вырождается в безусловный write — байт-в-байт | AC-9 | PASS |
+| TC-10 | unit | never-raise + fail-open (hot-path) / fail-closed (prod-safety) на ошибках БД/lease | AC-10 | PASS |
+| TC-11 | unit | Структурный аудит: `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/вердикт-ключи байт-в-байт; хранилище аддитивно | AC-11 | PASS |
+| TC-12 | integration | Наблюдаемость: блок `/queue`, Telegram-алерт на форсированный реклейм | AC-12 | PASS |
+| TC-13 | unit | Self-hosting безопасность: нет рестарта прода / push в `main` / detached-вмешательства | AC-13 | PASS |
+| TC-14 | integration | Полный регресс конвейера зелёный; happy-path deploy-staging/finalizer без двойных эффектов | BR-8 | PASS |
+
+**Сопоставление с `03-acceptance-criteria.md`:** все 13 AC покрыты соответствующими TC (см. колонку
+AC). Каждый TC из `04-test-plan.yaml` (TC-01…TC-14) выполнен и совпал с `expected: PASS`.
+
+Детализация по dedicated-модулю `tests/test_orch114_transition_ownership.py` (34 теста, разбивка
+TC-01…TC-13 на под-кейсы) — все PASSED. TC-14 — полный регресс `tests/`.
+
+## Вывод pytest
+
+Dedicated-модуль:
+```
+tests/test_orch114_transition_ownership.py — 34 passed, 1 warning in 3.84s
+```
+
+Полный регресс (TC-14 / AC-9 / CI-green):
+```
+2052 passed, 1 warning in 106.62s (0:01:46)
+```
+(единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, преждесуществующий,
+не связан с ORCH-114.)
+
+Обязательный регресс класса ORCH-111 присутствует и зелёный:
+`test_tc01_concurrent_entry_no_double_effect` (PASS с lease) +
+`test_tc01_red_before_fix_demonstration` (демонстрация красного при kill-switch off).
+
+## Итог
+**PASS** — полный pytest зелёный (2052 passed), все 14 TC выполнены и сопоставлены с 13 AC, smoke
+read-only (`/health`/`/status`/`/queue` c блоками `serial_gate` + `auto_labels`) OK. Задача готова
+к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,33 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-114
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T16:25:50Z
+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`,
+ORCH-048/ADR-001). Exit code **0** → advance.
+
+All REAL pipeline checks passed. The only two failures are the known sandbox-infra checks
+C9a/C9b, which are waived per ORCH-061 (they depend on SANDBOX bot accounts being project
+members, not on the pipeline). The script printed the waiver and still exited 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) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Results
+- **Block A (SMOKE)**: PASS — A1 `/health` 200 ok, A2 `/queue` 200 with counts/max_concurrency/resilience, A3 `ORCH_STAGING=true`.
+- **Block B (ACCESS)**: PASS — B4 Plane sandbox accessible (sandbox=YES), B5 Gitea orchestrator-sandbox accessible push=true, B6 registry isolation (sandbox present, prod ET/ORCH absent).
+- **Block C (E2E, mode=stub)**: C7 create Plane issue PASS, C8 trigger `/webhook/plane` PASS; C9a/C9b FAIL → **INFRA-WAIVED** (sandbox-infra). Cleanup: Plane issue deleted (HTTP 204).
+
+RESULT: 8/10 checks PASS. REAL failed: none. SANDBOX_INFRA failed (waived): C9a, C9b.
+Tolerance: `staging_infra_tolerance_enabled=True`.

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: test/staging Plane writes must be sandbox-only and never mutate prod
+
+Work Item ID: ORCH-117
+
+## Description
+
+TBD

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

@@ -0,0 +1,213 @@
+---
+work_item: ORCH-117
+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-117 — test/staging Plane writes must be sandbox-only and never mutate prod
+
+Work Item: **ORCH-117** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в full-cycle**
+
+> ⚠️ **`escalate: full-cycle` (ADR-001 D5 ORCH-019).** Задача помечена `Bug`, но по сути это
+> **архитектурный + safety-critical (self-hosting)** дефект изоляции окружений: нужно решение о
+> том, **где** ставить fail-closed-чокпоинт записи в Plane, **как** детектировать тест-процесс
+> (pytest/worktree) в отличие от staging-runtime, и **как** устроен явный аудируемый opt-in для
+> sandbox-интеграции. Это требует ADR (политика изоляции + точка перехвата). Поэтому выпускается
+> **полный** analysis-пакет, а не облегчённый bug-пакет. Оператор снимает багфикс-трек:
+> `POST /bug-fast-track/escalate?work_item=ORCH-117` → задача пойдёт через стадию `architecture`
+> (architect выпустит ADR для политики изоляции/чокпоинта).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### Симптом (наблюдаемое — установленный факт из инцидента ORCH-114)
+Во время тестирования ORCH-114 **тестовый/worktree-путь выполнил РЕАЛЬНУЮ запись в Plane против
+ПРОДАКШН-проекта ORCH**. В логах Plane зафиксировано:
+```
+PATCH /issues/dd57ad23... state=3738cd3c...   # 3738cd3c == Done
++ comment: "Stage: deploy → done" (branch feature/orch114)
+```
+То есть `notify_stage_change("ORCH-114", "deploy", "done")`, запущенный из тестового процесса,
+смутировал боевую задачу в Plane — поставил **Done** и оставил комментарий. Это «ложный Done»:
+прод-доска показала задачу завершённой по действию тестов, а не конвейера.
+
+### Причина симптома (установленный факт, верифицировано в коде)
+Тест/staging-процессы **имеют доступ к живому Plane-токену и workspace** и **не принуждаются**
+писать только в ORCH Sandbox:
+
+1. **Токен берётся из боевого окружения контейнера.** В `src/plane_sync.py:17`
+   `PLANE_HEADERS = {"X-API-Key": settings.plane_api_token}` фиксируется **на импорте модуля**;
+   `settings.plane_api_token` читается из env контейнера, где боевой токен **уже установлен**.
+2. **Защита в тестах не работает.** Тестовые модули делают
+   `os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")` (например
+   `tests/test_deploy_terminal_sync.py:19`, `tests/test_orch026_serialize_integration.py:16` и ~20
+   др.). `os.environ.setdefault` **НЕ перекрывает** уже установленную в контейнере переменную →
+   в проде это **no-op** → тесты наследуют **реальный** токен. Вдобавок, даже если бы env
+   переписывался ПОСЛЕ импорта `plane_sync`, `PLANE_HEADERS` уже захвачен литералом на импорте и
+   не пересчитывается (см. п.1) — подмена токена постфактум бесполезна.
+3. **Целевой проект по умолчанию — боевой.** `src/plane_sync.py:57`
+   `PROJECT_ID = settings.plane_project_id or "7a79f0a9-5278-49cd-9007-9a338f238f9c"` — дефолт
+   указывает на **боевой ORCH-проект**; ничто не принуждает тест-процесс адресовать только
+   sandbox `8c5a3025-4f9d-4190-b79f-fa06276bb27e` (identifier `SANDBOX`).
+4. **Нет fail-closed-гарда на путях записи.** Все мутирующие вызовы Plane проходят через **три**
+   примитива в `src/plane_sync.py` — `update_issue_state` (`httpx.patch`, стр. 861),
+   `add_comment` (`httpx.post`, стр. 885), `_set_issue_state_direct` (`httpx.patch`, стр. 1047) —
+   и **ни один** не проверяет, выполняется ли он в тест-процессе и легитимен ли целевой проект.
+
+### Прецедент в кодовой базе (почему фикс уместен и как его форму подсказать)
+`tests/conftest.py` уже содержит **ровно тот же класс защиты для Telegram**: autouse-фикстура
+`_no_telegram` глушит `send_telegram`, потому что «pytest на проде слал РЕАЛЬНЫЕ Telegram-сообщения
+Славе» (дословно из докстринга conftest). Аналогичная autouse-страховка для **Plane-записи**
+**отсутствует** — это пробел того же рода, который и реализовался инцидентом ORCH-114. Sandbox как
+понятие уже существует: `scripts/staging_check.py:283` фиксирует
+`SANDBOX_PROJECT_ID = "8c5a3025-4f9d-4190-b79f-fa06276bb27e"`, а проверка B6 утверждает инвариант
+«sandbox present ∧ prod-ET absent ∧ prod-ORCH absent» — но **только как read-only верификация
+доступа**, а не как **гард записи**.
+
+### Локализация (куда смотреть архитектору/разработчику)
+- **Чокпоинт записи** — три примитива в `src/plane_sync.py` (`update_issue_state`, `add_comment`,
+  `_set_issue_state_direct`); все `set_issue_*`/`notify_*` сводятся к ним. Гард логично ставить
+  максимально близко к фактическому `httpx.patch/post` (низкий чокпоинт ловит любой путь, включая
+  будущие).
+- **Захват токена на импорте** — `PLANE_HEADERS`/`PROJECT_ID` модульного уровня (`plane_sync.py:17,57`):
+  подмена env после импорта не лечит; гард обязан перехватывать **на момент вызова**.
+- **Дефолт тестового окружения** — `tests/conftest.py` (autouse, fail-closed по образцу `_no_telegram`).
+- **Конфиг opt-in** — `src/config.py` (новые ключи интеграционного включения + sandbox-allowlist).
+- **Детект тест-процесса** — в `src/` сейчас **нет** механизма (`PYTEST_CURRENT_TEST`/`sys.modules`
+  не используются для этого); его предстоит ввести и/или опереть на явный конфиг-флаг.
+
+**Вывод:** устойчивость должна быть на стороне системы — запись в Plane из тест/worktree-процесса в
+**боевой** проект должна быть **физически невозможна** (fail-closed), независимо от того, какой
+токен оказался в окружении; sandbox-запись разрешается только при **явном аудируемом opt-in** и
+**только** в проект SANDBOX.
+
+## 2. Объём (scope)
+
+### В объёме
+- **Жёсткая fail-closed изоляция записи в Plane:** прогон unit/test/full-regression (pytest, в т.ч.
+  из worktree) **не может** мутировать боевые Plane-проекты (state-PATCH и/или comment-POST) —
+  даже при наличии **живого боевого токена** в окружении.
+- **Sandbox-only для реальных тестов:** staging / full-real e2e-тесты, которым нужна настоящая
+  запись в Plane, адресуют **только** проект ORCH Sandbox (`8c5a3025-…`); любой другой целевой
+  проект (особенно боевой `7a79f0a9-…`) — запрещён.
+- **Явный аудируемый opt-in:** запись в Plane из тест-процесса возможна **исключительно** при
+  одновременном выполнении: (а) включён выделенный интеграционный флаг, (б) целевой проект ∈
+  sandbox-allowlist. Отсутствие любого условия → запись блокируется.
+- **Дефолт тестов fail-closed:** autouse-страховка в `tests/conftest.py` (по образцу `_no_telegram`)
+  блокирует Plane-запись по умолчанию во **всех** тестах.
+- **Наблюдаемость/аудит:** каждая заблокированная запись логируется структурно (WARNING/ERROR с
+  целевым project_id, work_item, операцией); каждая разрешённая sandbox-запись — audit-строкой.
+- **Док/конфиг:** обновить `.env.example`, `CLAUDE.md`, `docs/architecture/README.md`,
+  `docs/operations/INFRA.md` (и, при необходимости, `docs/deployment/*` про тестовую изоляцию).
+- **Обязательный регресс-тест:** воспроизводит инцидент ORCH-114 — красный до фикса, зелёный после.
+
+### Вне объёма
+- ❌ Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей / схемы БД
+  (это bugfix-изоляция, а **не** Quality Gate и **не** стадия).
+- ❌ Изменение поведения **боевого рантайма** оркестратора (не-pytest процесс): прод обязан писать
+  в Plane как прежде, гард для него — no-op.
+- ❌ Изменение поведения **staging-рантайма** (8501): staging — реальный процесс оркестратора,
+  работающий **только** с sandbox-проектом по конфигу; он должен по-прежнему писать в SANDBOX.
+- ❌ Запрет/контроль ручных операций оператора (вне технической власти системы).
+- ❌ Выбор конкретного механизма детекта тест-процесса и точки перехвата (гард в `plane_sync` vs
+  обёртка `httpx` vs autouse-фикстура vs комбинация) — **зона архитектора** (ADR).
+- ❌ Массовая чистка/нормализация существующих `os.environ.setdefault(...)` строк в тестах сверх
+  необходимого (можно оставить как есть — гард не должен от них зависеть; см. NFR-4).
+
+## 3. Заинтересованные стороны
+- **Заказчик/оператор (Слава)** — страдает от «ложных Done» и шумных комментариев в боевой Plane,
+  порождённых тестами; принимает результат.
+- **Self-hosting конвейер orchestrator** — прямой потребитель: целостность боевой Plane-доски как
+  источника индикации (слой B, ORCH-066) не должна искажаться тест-прогонами.
+- **Все проекты на общем инстансе (enduro-trails)** — косвенно: тестовая запись не должна задевать
+  чужие боевые проекты в общем workspace.
+- **Разработчики/CI** — потребители sandbox-e2e: должны сохранить возможность реальной проверки
+  против SANDBOX.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Прогон pytest (unit/integration/full-regression), в том числе из worktree,
+  **НЕ должен** выполнять мутирующую запись в Plane (state-PATCH и/или comment-POST) против
+  **боевых** проектов — **даже при наличии живого боевого токена** в окружении. Это **fail-closed**
+  свойство: запись в боевой проект из тест-процесса **невозможна**.
+- **BR-2** — Реальная запись в Plane из тест/staging-контекста разрешена **только** в проект
+  **ORCH Sandbox** (`8c5a3025-4f9d-4190-b79f-fa06276bb27e`); любой иной целевой проект (в т.ч.
+  боевой ORCH `7a79f0a9-…` и боевой enduro-проект) — запрещён.
+- **BR-3** — Реальная sandbox-запись из тест-процесса включается **только** явным аудируемым opt-in:
+  одновременно (а) выделенный интеграционный флаг включён **и** (б) целевой проект ∈ sandbox-allowlist.
+  Отсутствие любого условия → запись блокируется (default-deny).
+- **BR-4** — Дефолтная тестовая поза — **fail-closed**: при обычном `pytest tests/` (без явного
+  opt-in) **ни один** тест не может писать в Plane (autouse-страховка в `conftest.py`, по образцу
+  существующего `_no_telegram`).
+- **BR-5** — **Sandbox e2e сохраняется:** с включённым opt-in и целевым проектом SANDBOX реальная
+  запись в Plane успешно проходит (регрессии sandbox-сценария нет).
+- **BR-6** — **Наблюдаемость/аудит:** каждая заблокированная попытка записи логируется структурно
+  (целевой project_id, work_item, операция, причина блокировки); каждая разрешённая sandbox-запись —
+  audit-строкой. Инцидент класса ORCH-114 должен быть **видимым**, а не молчаливым.
+- **BR-7** — **Документация и конфиг обновлены** в том же PR (golden source наравне с кодом):
+  `.env.example`, `CLAUDE.md`, `docs/architecture/README.md`, `docs/operations/INFRA.md`.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (fail-closed / default-deny)** — при любой неопределённости (не удаётся достоверно
+  определить целевой проект / окружение / тест-контекст) запись в тест-контексте **запрещается**.
+  «Не знаю» ⇒ «не пишу».
+- **NFR-2 (нулевая регрессия боевого рантайма)** — реальный прод-процесс оркестратора (не pytest)
+  пишет в Plane **байт-в-байт** как до ORCH-117; гард для него — no-op. `STAGE_TRANSITIONS` /
+  `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — **не тронуты**.
+- **NFR-3 (staging-рантайм не сломан)** — staging-инстанс (8501) — **реальный** процесс
+  оркестратора (не pytest), сконфигурированный на sandbox-проект; он должен **по-прежнему** писать
+  в SANDBOX. Детект обязан отличать **тест-процесс (pytest/worktree)** от **staging-runtime**.
+- **NFR-4 (устойчивость к захвату токена на импорте)** — фикс **не должен** полагаться на подмену
+  `settings.plane_api_token`/env постфактум (бесполезно из-за модульного захвата `PLANE_HEADERS`/
+  `PROJECT_ID`, `plane_sync.py:17,57`) и **не должен** зависеть от неработающего
+  `os.environ.setdefault(...)` в тестах. Перехват — **на момент вызова** примитива записи.
+- **NFR-5 (надёжность / self-hosting safety)** — гард изолирован и **never-raise в боевом пути**
+  (по образцу leaf'ов `serial_gate`/`cancel`/`deploy_status_guard`): сбой/недоступность логики
+  гарда не роняет боевой конвейер и не блокирует легитимную боевую запись. В **тест-процессе**
+  срабатывание гарда должно быть **громким** (блок + аудит, при необходимости — жёсткий fail),
+  чтобы дефект всплыл, а не замаскировался.
+- **NFR-6 (обратимость / kill-switch)** — поведение под флагом по конвенции проекта, **но**
+  дефолт = **безопасный** (fail-closed в тестах). Kill-switch **не должен** позволять случайно
+  переоткрыть запись в боевой проект из тестов без явного аудируемого opt-in (BR-3); т.е.
+  «выключить защиту полностью» не равно «разрешить запись в прод из pytest».
+- **NFR-7 (область / композиция)** — изменение скоупится на изоляцию тест/staging-записи; не
+  ухудшает поведение для прочих репо/боевого рантайма; совместимо с ORCH-066 (статусная модель),
+  ORCH-094 (deploy-status guard), ORCH-061 (sandbox-infra tolerance staging_check).
+
+## 6. Допущения и ограничения
+- **Все** мутирующие записи в Plane проходят через 3 примитива `src/plane_sync.py`
+  (`update_issue_state`, `add_comment`, `_set_issue_state_direct`) — это единый узкий чокпоинт
+  (верифицировано: все `set_issue_*`/`notify_*` сводятся к ним).
+- Боевой проект ORCH = `7a79f0a9-5278-49cd-9007-9a338f238f9c` (дефолт `PROJECT_ID`); sandbox =
+  `8c5a3025-4f9d-4190-b79f-fa06276bb27e` (`SANDBOX`, уже зафиксирован в `scripts/staging_check.py:283`).
+- `PLANE_HEADERS`/`PROJECT_ID` захватываются на импорте модуля — гард обязан читать актуальное
+  состояние/контекст **в момент вызова**, не на импорте.
+- Тест-процесс достоверно отличим (например по `PYTEST_CURRENT_TEST` в env, по наличию `pytest`
+  в `sys.modules`, и/или по явному конфиг-флагу тест-режима) — **выбор признака — вопрос ADR**;
+  признак должен быть надёжным и не давать ложноположительных срабатываний в боевом/staging
+  рантайме (NFR-2/NFR-3).
+- Конкретный механизм (гард-leaf в `plane_sync` / обёртка над `httpx` / autouse-фикстура /
+  их комбинация) и протокол opt-in — **открытый вопрос архитектуры**, решается в `06-adr/`.
+
+## 7. Критерии успеха
+Прогон pytest с **живым боевым токеном** в окружении **физически не может** смутировать боевой
+ORCH-проект (0 PATCH/POST в боевой проект); sandbox-e2e против SANDBOX по-прежнему работает при
+явном opt-in; боевой и staging рантаймы — без регресса; каждая блокировка/разрешение записи —
+наблюдаема (аудит-лог); док/конфиг обновлены; обязательный регресс-тест **красный до фикса,
+зелёный после**. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Ложноположительный детект тест-процесса** в боевом/staging рантайме → блокировка легитимной
+  боевой/sandbox записи (молчаливая потеря индикации Plane). Митигирует NFR-2/NFR-3 + аудит (BR-6).
+- **Ложноотрицательный детект** (тест-процесс не распознан) → дефект остаётся → нужен надёжный
+  признак + fail-closed по умолчанию (NFR-1) + дефолтная autouse-страховка (BR-4).
+- **Захват на импорте** (`PLANE_HEADERS`/`PROJECT_ID`): неверная точка перехвата (на импорте, а не
+  на вызове) даст ложное чувство защиты — жёсткое ограничение для архитектора (NFR-4).
+- **Kill-switch как чёрный ход:** грубо реализованный «выключатель» может переоткрыть запись в прод
+  из тестов — запрещено (NFR-6).
+- Кросс-каттинг с ORCH-066 (Plane-индикация), ORCH-094 (deploy-status guard), ORCH-061
+  (staging sandbox-infra). Детали/митигации — `10-tech-risks.md` (заполняет архитектор).

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

@@ -0,0 +1,132 @@
+---
+work_item: ORCH-117
+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-117 — sandbox-only fail-closed изоляция записи в Plane
+
+Work Item: **ORCH-117** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения (точка перехвата, признак тест-процесса, протокол opt-in) —
+> задача архитектора (`06-adr/`). Ниже — требования и ограничения, привязанные к реальным модулям.
+
+## 1. Сводка изменения
+Ввести **fail-closed гард записи в Plane**: любая мутирующая запись (state-PATCH / comment-POST),
+исходящая из **тест-процесса** (pytest/worktree), блокируется по умолчанию и допускается **только**
+при явном аудируемом opt-in **и** целевом проекте из **sandbox-allowlist**. Боевой
+рантайм-процесс оркестратора и staging-рантайм (8501) не затронуты (гард для них — no-op). Перехват
+выполняется **на момент вызова** примитивов записи `src/plane_sync.py` (а не на импорте, где токен
+уже захвачен). Дефолтная тестовая поза — блокировка, через autouse-страховку в `tests/conftest.py`
+(по образцу `_no_telegram`). Изменение — bugfix-изоляция: **не** Quality Gate, **не** стадия;
+`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не трогаются.
+
+## 2. Задействованные модули / пути
+| Путь | Действие | Зачем |
+|------|----------|-------|
+| `src/plane_sync.py` | изменить | Врезать гард в 3 примитива записи: `update_issue_state` (`httpx.patch`, стр. 861), `add_comment` (`httpx.post`, стр. 885), `_set_issue_state_direct` (`httpx.patch`, стр. 1047). Учесть захват `PLANE_HEADERS`/`PROJECT_ID` на импорте (стр. 17/57). |
+| `src/plane_write_guard.py` *(кандидат, имя — на усмотрение архитектора)* | создать *(вероятно)* | Чистый leaf-гард (never-raise в боевом пути, по образцу `serial_gate`/`cancel`/`deploy_status_guard`): `decide(project_id, op, work_item) -> ALLOW \| BLOCK` + детект тест-процесса + sandbox-allowlist. Альтернатива/комбинация — обёртка над `httpx`/autouse-фикстура (решает ADR). |
+| `src/config.py` | изменить | Новые ключи: интеграционный opt-in флаг записи из тестов, sandbox-allowlist проектов, (опц.) kill-switch гарда. Дефолты = безопасные (fail-closed в тестах). |
+| `tests/conftest.py` | изменить | Новая autouse-фикстура fail-closed (блок Plane-записи во всех тестах по умолчанию), по образцу `_no_telegram`. Тесты sandbox-e2e переопределяют её своим opt-in (как `test_*` переопределяют `_disable_*`). |
+| `.env.example` | изменить | Канон новых `ORCH_*` ключей (opt-in/allowlist/kill-switch) с безопасными дефолтами. |
+| `scripts/staging_check.py` | проверить/при необходимости адаптировать | Block C (E2E в SANDBOX) должен остаться рабочим: реальная запись в sandbox под opt-in. `SANDBOX_PROJECT_ID` (стр. 283) — источник идентификатора sandbox. |
+| `CLAUDE.md`, `docs/architecture/README.md`, `docs/operations/INFRA.md` | изменить | Документировать инвариант изоляции тест/staging-записи (golden source наравне с кодом). |
+| `tests/test_orch117_plane_write_isolation.py` *(имя — кандидат)* | создать | Покрытие FR-1…FR-6, включая обязательный регресс ORCH-114 (TC-01). |
+
+> ⚠️ Список модулей **не** предписывает архитектуру. Точку перехвата (низкий чокпоинт в `plane_sync`
+> у `httpx.patch/post` vs обёртка транспорта vs autouse-фикстура) и признак тест-процесса выбирает
+> архитектор в ADR. ТЗ фиксирует **требования к поведению**, а не способ реализации.
+
+## 3. Функциональные требования
+
+### FR-1 — Fail-closed блок записи в боевой проект из тест-процесса (BR-1, BR-2)
+В **тест-процессе** (pytest/worktree) любой вызов `update_issue_state` / `add_comment` /
+`_set_issue_state_direct` с целевым `project_id` **вне** sandbox-allowlist (в частности боевой ORCH
+`7a79f0a9-5278-49cd-9007-9a338f238f9c` и любой боевой enduro-проект) **НЕ должен** выполнять
+`httpx.patch`/`httpx.post` — запись блокируется. Свойство **fail-closed**: при невозможности
+достоверно определить целевой проект → блокировать (NFR-1). Гард читает контекст **в момент вызова**
+(NFR-4), не полагается на токен/`os.environ.setdefault`.
+
+### FR-2 — Разрешение только в sandbox при явном аудируемом opt-in (BR-2, BR-3, BR-5)
+Запись из тест-процесса допускается ⇔ **одновременно**: (а) включён выделенный интеграционный
+opt-in-флаг **и** (б) целевой `project_id` ∈ sandbox-allowlist (по умолчанию — единственный
+`8c5a3025-4f9d-4190-b79f-fa06276bb27e`). При выполнении обоих условий примитив выполняет реальный
+`httpx`-вызов в SANDBOX. Отсутствие любого условия → блок (default-deny). Запись в боевой проект
+запрещена **даже при включённом opt-in** (allowlist sandbox-only).
+
+### FR-3 — Дефолтная тестовая поза fail-closed (BR-4)
+При обычном `pytest tests/` (без явного opt-in) autouse-страховка `conftest.py` гарантирует, что
+**ни один** тест не пишет в Plane (все 3 примитива заблокированы/застаблены). Тесты sandbox-e2e,
+которым нужна реальная запись, **явно** включают opt-in в собственной фикстуре/монкипатче (поверх
+autouse), ограничивая реальную запись своим scope — паттерн уже применён для
+`_disable_merge_verify`/`_disable_transition_lease`/`_no_telegram` в `conftest.py`.
+
+### FR-4 — Детект тест-процесса vs боевой/staging рантайм (NFR-2, NFR-3)
+Гард активен **только** в тест-процессе. Признак тест-процесса (например `PYTEST_CURRENT_TEST`
+в env / `pytest` в `sys.modules` / явный конфиг-флаг тест-режима — выбор за ADR) обязан:
+- **не** срабатывать в боевом рантайм-процессе оркестратора → боевая запись в Plane = байт-в-байт
+  как прежде (no-op гарда);
+- **не** срабатывать в staging-рантайме (8501) → staging пишет в SANDBOX как прежде (staging —
+  реальный процесс, не pytest).
+
+### FR-5 — Аудит/наблюдаемость (BR-6)
+- Каждая **заблокированная** запись → структурный лог уровня WARNING/ERROR с полями: целевой
+  `project_id`, `work_item`, операция (`state`/`comment`), причина (`prod-project-in-test` /
+  `opt-in-disabled` / `ambiguous-target`). Сообщение должно делать инцидент класса ORCH-114
+  **очевидным**.
+- Каждая **разрешённая** sandbox-запись из тест-процесса → audit-строка (INFO) с `project_id` и
+  операцией.
+- (Опц., на усмотрение архитектора) read-only-видимость состояния гарда (флаг/allowlist) — без
+  обязательного нового эндпоинта.
+
+### FR-6 — Поведение блокировки (NFR-5)
+- В **боевом пути** гард **never-raise**: его внутренний сбой/недоступность не роняет конвейер и
+  не блокирует легитимную боевую запись (для боевого процесса гард в принципе no-op — FR-4).
+- В **тест-процессе** срабатывание гарда — **громкое**: запись подавляется и аудируется; допустимо
+  жёсткое исключение/ассерт-фрэндли поведение, чтобы регресс-тест (TC-01) был детерминированно
+  красным до фикса и зелёным после. Конкретная семантика (no-op-стаб vs raise) — решение ADR, но
+  **наблюдаемый контракт**: «0 реальных PATCH/POST в боевой проект из pytest».
+
+### FR-7 — Kill-switch без чёрного хода (NFR-6)
+Если вводится kill-switch гарда — он **не должен** при выключении переоткрывать запись в **боевой**
+проект из тест-процесса. Допустимое поведение «выключено» = деградация к прежнему (до-ORCH-117), но
+без молчаливого разрешения прод-записи из pytest сверх того, что было; запись в SANDBOX из тестов
+управляется **только** opt-in-флагом + allowlist (FR-2), а не общим kill-switch.
+
+## 4. Изменения API
+**Нет** обязательных. Никаких новых публичных эндпоинтов изоляция не требует. (Опционально архитектор
+может добавить read-only-видимость состояния гарда, например блок в `GET /queue` — не обязательно.)
+
+## 5. Изменения схемы БД
+**Нет.** Изоляция — рантайм-гард по конфигу/окружению; персистентного состояния не требует. Схема БД
+не трогается (NFR-2).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Это **не** Quality Gate и **не** под-гейт. `QG_CHECKS` / `check_*` / `STAGE_TRANSITIONS` /
+machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
+`coverage_status:`) — **байт-в-байт не тронуты** (инвариант ORCH-019 NFR-1: срезается/меняется только
+не-гейтовое поведение; здесь — изоляция записи). Гард — свойство клиента Plane, не гейт конвейера.
+
+## 7. Совместимость / регресс
+- **Боевой рантайм:** гард — no-op (FR-4) → запись в Plane байт-в-байт как до ORCH-117 (NFR-2).
+- **Staging-рантайм (8501):** реальный процесс, sandbox-проект по конфигу → пишет в SANDBOX как
+  прежде (NFR-3). `scripts/staging_check.py` Block C (E2E) должен остаться зелёным.
+- **Существующий тест-сьют:** autouse fail-closed-фикстура не должна ломать существующие тесты —
+  большинство тестов **мокируют** `plane_*`/`add_comment` (например `tests/test_auto_labels_integration.py:58`
+  `monkeypatch.setattr(stage_engine, "plane_add_comment", MagicMock())`), поэтому реальная запись и
+  так не происходит; гард лишь делает это **гарантией по умолчанию**. Прежние неработающие
+  `os.environ.setdefault("ORCH_PLANE_API_TOKEN","test-token")` строки можно не трогать — гард не
+  зависит от них (NFR-4).
+- **Sandbox-e2e:** под явным opt-in + allowlist реальная запись в SANDBOX сохраняется (BR-5).
+- **Kill-switch:** при выключении гарда (если введён) — деградация к прежнему поведению, **без**
+  переоткрытия прод-записи из тестов (FR-7/NFR-6).
+- **Обратимость:** дефолты безопасные (fail-closed в тестах); включение реальной записи —
+  только явным opt-in.
+- **Артефакты pipeline:** создаёт/обновляет `docs/work-items/ORCH-117/06-adr/ADR-001-*.md`
+  (architect, после эскалации), `10-tech-risks.md`; в этом PR — обновление `.env.example`,
+  `CLAUDE.md`, `docs/architecture/README.md`, `docs/operations/INFRA.md`.

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

@@ -0,0 +1,145 @@
+---
+work_item: ORCH-117
+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-117 — sandbox-only fail-closed изоляция записи в Plane
+
+Work Item: **ORCH-117** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — Регресс ORCH-114: живой прод-токен + pytest не мутируют боевой проект (ОБЯЗАТЕЛЬНЫЙ)
+
+**Условие:** В тест-процессе с **живым боевым** `ORCH_PLANE_API_TOKEN` в окружении вызывается
+`notify_stage_change("ORCH-114", "deploy", "done")` (и/или прямые `update_issue_state`/`add_comment`/
+`_set_issue_state_direct`) с целевым боевым проектом `7a79f0a9-5278-49cd-9007-9a338f238f9c`.
+- **PASS:** **ноль** реальных `httpx.patch`/`httpx.post` уходит в боевой проект (мок `httpx` не
+  вызван для prod-URL **или** гард блокирует до сетевого вызова). Существует тест, который **красный
+  до фикса** (воспроизводит запись инцидента) и **зелёный после**.
+- **FAIL:** хоть один PATCH/POST достигает боевого проекта из тест-процесса; либо регресс-тест
+  отсутствует; либо он зелёный и до фикса (значит ничего не проверяет).
+
+---
+
+## AC-2 — Sandbox-e2e сохранён: запись в SANDBOX под opt-in проходит
+
+**Условие:** В тест-процессе включён явный интеграционный opt-in **и** целевой проект — SANDBOX
+`8c5a3025-4f9d-4190-b79f-fa06276bb27e`.
+- **PASS:** примитивы записи выполняют реальный `httpx`-вызов в SANDBOX (в тесте — через мок,
+  подтверждающий, что вызов разрешён и адресован sandbox-URL); `scripts/staging_check.py` Block C
+  (E2E в SANDBOX) остаётся работоспособным.
+- **FAIL:** запись в SANDBOX заблокирована при корректном opt-in; либо sandbox-e2e сломан.
+
+---
+
+## AC-3 — Sandbox-only даже с opt-in: боевой проект запрещён всегда
+
+**Условие:** В тест-процессе включён opt-in, но целевой проект — боевой (`7a79f0a9-…` ORCH или
+боевой enduro-проект).
+- **PASS:** запись блокируется (allowlist sandbox-only) независимо от opt-in; аудит-лог фиксирует
+  причину `prod-project-in-test`.
+- **FAIL:** включённый opt-in разрешает запись в любой проект, включая боевой.
+
+---
+
+## AC-4 — Default-deny: без opt-in запись из тестов заблокирована (fail-closed)
+
+**Условие:** Обычный `pytest tests/` без явного opt-in; целевой проект — любой (sandbox или боевой).
+- **PASS:** все 3 примитива (`update_issue_state`, `add_comment`, `_set_issue_state_direct`) не
+  делают реальной записи; autouse-фикстура `conftest.py` обеспечивает это по умолчанию во всех
+  тестах. Неопределённый/неразрешимый целевой проект → блок (NFR-1).
+- **FAIL:** без opt-in возможна реальная запись в Plane; либо autouse-страховка отсутствует.
+
+---
+
+## AC-5 — Нулевая регрессия боевого рантайма
+
+**Условие:** Процесс — **не** pytest (боевой рантайм оркестратора).
+- **PASS:** гард — no-op; запись в Plane выполняется как до ORCH-117 (тот же URL/headers/payload).
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — **байт-в-байт не
+  изменены** (проверяемо diff'ом / структурными тестами).
+- **FAIL:** боевая запись подавлена/изменена; либо изменены гейты/схема БД.
+
+---
+
+## AC-6 — Staging-рантайм пишет в SANDBOX
+
+**Условие:** Процесс — staging-рантайм (8501), **не** pytest; сконфигурирован на sandbox-проект.
+- **PASS:** детект тест-процесса **не** срабатывает для staging → запись в SANDBOX проходит как
+  прежде; staging не приравнивается к pytest.
+- **FAIL:** staging-запись в SANDBOX заблокирована (ложноположительный детект тест-процесса).
+
+---
+
+## AC-7 — Устойчивость к захвату токена на импорте
+
+**Условие:** `PLANE_HEADERS`/`PROJECT_ID` захвачены на импорте `plane_sync` (стр. 17/57); тест
+выполняет запись, не подменяя токен/env постфактум.
+- **PASS:** гард срабатывает **на момент вызова** примитива и блокирует прод-запись независимо от
+  того, какой токен в `PLANE_HEADERS`; защита **не** опирается на `os.environ.setdefault(...)`/
+  подмену `settings.plane_api_token`.
+- **FAIL:** защита зависит от подмены токена/env и потому не срабатывает в проде (как было до фикса).
+
+---
+
+## AC-8 — Аудит/наблюдаемость блокировок и разрешений
+
+**Условие:** Происходит блокировка записи (или разрешённая sandbox-запись).
+- **PASS:** на блокировку эмитится структурный WARNING/ERROR с `project_id`, `work_item`, операцией и
+  причиной; на разрешённую sandbox-запись — audit-INFO. Сообщения делают инцидент видимым.
+- **FAIL:** блокировка/разрешение происходят молча (нет логов с требуемыми полями).
+
+---
+
+## AC-9 — Kill-switch без чёрного хода
+
+**Условие:** Если введён kill-switch гарда — он выключен.
+- **PASS:** выключение деградирует к прежнему (до-ORCH-117) поведению, но **не** разрешает молча
+  запись в **боевой** проект из pytest сверх того, что было; реальная sandbox-запись из тестов
+  управляется только opt-in + allowlist (не общим kill-switch).
+- **FAIL:** общий kill-switch служит чёрным ходом, переоткрывающим прод-запись из тест-процесса.
+
+---
+
+## AC-10 — Документация и конфиг обновлены (golden source)
+
+**Условие:** PR закрывает ORCH-117.
+- **PASS:** обновлены `.env.example` (новые `ORCH_*` ключи с безопасными дефолтами), `CLAUDE.md`,
+  `docs/architecture/README.md`, `docs/operations/INFRA.md` — описан инвариант изоляции тест/staging
+  записи в Plane. ADR выпущен (`06-adr/ADR-001-*.md`).
+- **FAIL:** код есть, документация/конфиг не обновлены (по правилу reviewer'а ORCH — finding ≥P1).
+
+---
+
+## AC-11 — Полный регресс зелёный
+
+**Условие:** `pytest tests/ -q` после фикса.
+- **PASS:** весь сьют зелёный (автоматическая autouse-страховка не ломает существующие тесты).
+- **FAIL:** появились падения/флапы из-за внедрённого гарда/фикстуры.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 / FR-6 (обязательный регресс ORCH-114) |
+| AC-2 | BR-5 / FR-2 |
+| AC-3 | BR-2 / FR-2 |
+| AC-4 | BR-3 / BR-4 / FR-2 / FR-3 / NFR-1 |
+| AC-5 | NFR-2 / FR-4 |
+| AC-6 | NFR-3 / FR-4 |
+| AC-7 | NFR-4 / FR-1 |
+| AC-8 | BR-6 / FR-5 |
+| AC-9 | NFR-6 / FR-7 |
+| AC-10 | BR-7 |
+| AC-11 | NFR-2 (регресс-нейтральность) |

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

@@ -0,0 +1,113 @@
+work_item: ORCH-117
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+title: "Sandbox-only fail-closed изоляция записи в Plane (регресс ORCH-114)"
+framework: pytest
+scope: >
+  Покрывает fail-closed гард записи в Plane: блок прод-записи из тест-процесса даже при живом
+  боевом токене (обязательный регресс ORCH-114), sandbox-only-разрешение под явным opt-in,
+  default-deny по умолчанию, отличие тест-процесса от боевого/staging рантайма, перехват на
+  момент вызова (устойчивость к захвату токена на импорте), аудит. ВНЕ покрытия: реальные сетевые
+  вызовы к боевому Plane (запрещены самим фиксом) — всё через мок httpx; выбор механизма детекта —
+  зона ADR (тесты проверяют поведение, не реализацию).
+notes: >
+  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс инцидента ORCH-114: красный до фикса, зелёный после. Все три
+  примитива записи (update_issue_state / add_comment / _set_issue_state_direct) проверяются на
+  блок/разрешение через мок httpx.patch/httpx.post (никаких реальных сетевых вызовов). Полный
+  регресс tests/ должен оставаться зелёным (autouse fail-closed-фикстура не ломает существующие
+  тесты, большинство из которых уже мокируют plane_*/add_comment). Боевой ID проекта в тестах —
+  7a79f0a9-5278-49cd-9007-9a338f238f9c; sandbox — 8c5a3025-4f9d-4190-b79f-fa06276bb27e.
+
+tests:
+  - id: TC-01
+    type: integration
+    description: "РЕГРЕСС ORCH-114: pytest-env + живой прод-токен → notify_stage_change('ORCH-114','deploy','done') на боевой проект НЕ делает ни одного httpx.patch/post (мок httpx не вызван для prod-URL / гард блокирует). Красный до фикса, зелёный после."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "update_issue_state в тест-процессе с целевым боевым проектом 7a79f0a9-… → блок (httpx.patch не вызван); аудит-причина prod-project-in-test."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "add_comment в тест-процессе с боевым проектом → блок (httpx.post не вызван)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "_set_issue_state_direct в тест-процессе с боевым проектом → блок (httpx.patch не вызван). Покрывает все set_issue_* (Done/In Review/Blocked/…), сводящиеся к этому примитиву."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Default-deny: без явного opt-in запись в тест-процессе блокируется для ЛЮБОГО целевого проекта (в т.ч. sandbox)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Sandbox-разрешение: opt-in включён + целевой проект SANDBOX 8c5a3025-… → реальный httpx-вызов разрешён и адресован sandbox-URL (мок подтверждает вызов)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Sandbox-only даже с opt-in: opt-in включён, но целевой проект боевой → блок (allowlist sandbox-only), независимо от opt-in."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Fail-closed при неопределённости: целевой project_id неразрешим/пуст в тест-процессе → блок (NFR-1 'не знаю ⇒ не пишу')."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Устойчивость к захвату на импорте: PLANE_HEADERS содержит реальный токен, env/settings не подменяются постфактум → гард всё равно блокирует прод-запись на момент вызова (не зависит от os.environ.setdefault / подмены plane_api_token)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "Нулевая регрессия боевого рантайма: при имитации НЕ-pytest процесса гард = no-op, httpx.patch/post вызывается с прежним URL/headers/payload (запись в Plane как до ORCH-117)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Staging != pytest: имитация staging-рантайма (sandbox-проект, не тест-процесс) → запись в SANDBOX проходит (детект тест-процесса не срабатывает ложно)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "Аудит: на блокировку эмитится структурный WARNING/ERROR с project_id/work_item/операцией/причиной (caplog); на разрешённую sandbox-запись — audit-INFO."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-13
+    type: integration
+    description: "Дефолтная autouse-страховка conftest: репрезентативный advance стадии в обычном тесте не делает реальной записи в боевой Plane (страховка активна по умолчанию для всего сьюта)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-14
+    type: unit
+    description: "Kill-switch без чёрного хода: при выключенном kill-switch гарда запись в БОЕВОЙ проект из pytest всё равно не разрешается молча (реальная sandbox-запись управляется только opt-in+allowlist)."
+    module: tests/test_orch117_plane_write_isolation.py
+    expected: PASS
+
+  - id: TC-15
+    type: integration
+    description: "Полный регресс tests/ зелёный — внедрённая autouse fail-closed-фикстура не ломает существующие тесты (smoke: pytest tests/ -q)."
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md

@@ -0,0 +1,251 @@
+---
+work_item: ORCH-117
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Sandbox-only fail-closed гард записи в Plane из тест-процесса
+
+Work Item: **ORCH-117** — test/staging Plane writes must be sandbox-only and never mutate prod
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`**
+(кросс-каттинговое: вводит новый рантайм-leaf поверх **общего** Plane-клиента `plane_sync`,
+используемого ВСЕМИ проектами общего инстанса, + новый тест-харнесс-инвариант в `conftest.py`).
+
+## Статус
+Proposed
+
+## Контекст
+
+**Инцидент (установленный факт, ORCH-114).** Тестовый/worktree-процесс выполнил РЕАЛЬНУЮ запись в
+Plane против **боевого** проекта ORCH: `PATCH …/issues/dd57ad23… state=<Done>` + комментарий
+«Stage: deploy → done». То есть `notify_stage_change("ORCH-114","deploy","done")`, запущенный из
+pytest, смутировал боевую задачу — «ложный Done» на боевой доске (источник индикации, слой B
+ORCH-066).
+
+**Корень (сверено по коду).** Тест/staging-процессы имеют доступ к живому боевому Plane-токену и
+**ничто не принуждает** их писать только в sandbox:
+
+- `src/plane_sync.py:17` `PLANE_HEADERS = {"X-API-Key": settings.plane_api_token}` и `:57`
+  `PROJECT_ID = settings.plane_project_id or "7a79f0a9-…"` (боевой ORCH) **захватываются на импорте
+  модуля** → подмена env/токена постфактум бесполезна (NFR-4).
+- Тестовые `os.environ.setdefault("ORCH_PLANE_API_TOKEN","test-token")` — **no-op** в контейнере с
+  уже установленной боевой переменной → тесты наследуют **реальный** токен.
+- Все мутирующие записи сходятся в **три** примитива: `update_issue_state` (`httpx.patch`, стр. 861),
+  `add_comment` (`httpx.post`, стр. 885), `_set_issue_state_direct` (`httpx.patch`, стр. 1047) — и
+  **ни один** не проверяет тест-контекст и легитимность целевого проекта.
+
+**Прецедент в репозитории.** `tests/conftest.py::_no_telegram` — autouse-фикстура, глушащая
+`send_telegram` во ВСЕХ тестах, ровно потому что «pytest на проде слал РЕАЛЬНЫЕ Telegram-сообщения
+Славе». Симметричной защиты для **Plane-записи** не было — это пробел того же класса, реализованный
+ORCH-114. Идентификатор sandbox уже зафиксирован: `scripts/staging_check.py:283`
+`SANDBOX_PROJECT_ID = "8c5a3025-4f9d-4190-b79f-fa06276bb27e"`.
+
+**Почему «как есть» не годится.** Устойчивость стоит на стороне тестов (надеяться, что каждый тест
+замокает Plane), а не на стороне системы. Любой новый/будущий путь записи, забывший мок, снова
+смутирует боевую доску. Требуется **fail-closed**-инвариант: запись в боевой проект из
+тест/worktree-процесса должна быть **физически невозможна**, независимо от токена в окружении.
+
+## Решение
+
+### Сводка
+
+Вводим **fail-closed гард записи в Plane на низком чокпоинте** — на входе трёх примитивов записи
+`plane_sync`, **в момент вызова** (не на импорте). Чистую логику держит **новый leaf
+`src/plane_write_guard.py`** (never-raise, по образцу `serial_gate`/`cancel`/`deploy_status_guard`):
+`decide(project_id, op, work_item_id) -> (ALLOW | BLOCK, reason)`. Гард активен **только в
+тест-процессе** (детект `pytest`-в-процессе) — для боевого и staging рантайма он **no-op**
+(byte-for-byte, NFR-2/NFR-3). В тест-процессе запись разрешена **исключительно** при
+одновременном (а) включённом opt-in-флаге **и** (б) целевом проекте ∈ sandbox-allowlist; иначе —
+блок (default-deny). Дополнительно — **независимый conftest-floor** (autouse-фикстура), который
+форсит безопасные дефолты во ВСЕХ тестах (BR-4). Изменение — bugfix-изоляция: **не** Quality Gate и
+**не** стадия; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт не
+тронуты.
+
+### D1 — Точка перехвата: низкий чокпоинт в 3 примитивах `plane_sync`, на момент вызова
+
+Гард врезается в `update_issue_state` / `add_comment` / `_set_issue_state_direct` **сразу после**
+`_resolve_project_id(...)` (локальное чтение БД) и **до** любого сетевого шага (`stage_to_state`,
+`find_issue_id`, `httpx.patch/post`):
+
+```python
+project_id = _resolve_project_id(work_item_id, project_id)
+ok, reason = plane_write_guard.decide(project_id, "state", work_item_id)   # op ∈ {"state","comment"}
+if not ok:
+    plane_write_guard.audit_block(project_id, "state", work_item_id, reason)
+    return                                # никакой сети — ни GET, ни PATCH/POST
+# ... обычный путь (ALLOW)
+```
+
+**Почему этот чокпоинт (а не обёртка `httpx` и не только autouse-фикстура):**
+
+- **Низкий и полный.** Все `set_issue_*`/`notify_*` сводятся к этим трём примитивам (верифицировано
+  BRD §6) → один гард ловит любой путь, включая будущие (тот же довод, что у `deploy_status_guard` на
+  входе сеттеров).
+- **На момент вызова → иммунитет к захвату на импорте (NFR-4/AC-7).** `PLANE_HEADERS`/`PROJECT_ID`
+  захвачены литералами на импорте; гард читает контекст (тест-процесс + резолвенный `project_id`) при
+  каждом вызове, поэтому защита не зависит от того, какой токен в `PLANE_HEADERS`, и не опирается на
+  неработающий `os.environ.setdefault`.
+- **До сети.** Размещение до `find_issue_id`/`stage_to_state` исключает даже «безобидный» GET в
+  боевой workspace из тестов.
+- Обёртка над транспортом `httpx` отвергнута (см. «Альтернативы») — она ниже уровня, на котором
+  известны `project_id`/`work_item`/`op` для аудита, и хрупка к смене HTTP-клиента.
+
+### D2 — Детект тест-процесса: `pytest`-в-процессе (call-time)
+
+```python
+def _in_test_process() -> bool:
+    import sys, os
+    return ("pytest" in sys.modules) or bool(os.environ.get("PYTEST_CURRENT_TEST"))
+```
+
+- **`"pytest" in sys.modules`** истинно на всём прогоне pytest (collection + выполнение) в **этом**
+  процессе. Боевой и staging рантаймы запускаются `uvicorn src.main:app` и **не импортируют** pytest
+  в свой процесс → детект там **никогда** не срабатывает (NFR-2/NFR-3, AC-5/AC-6). pytest установлен в
+  образе (для merge-gate/coverage re-test), но запускается **отдельным субпроцессом** `python -m
+  pytest` — он-то и есть worktree-тест-процесс из инцидента, и его гард **должен** ловить (✓).
+- **`PYTEST_CURRENT_TEST`** — вторичный сигнал (выставляется pytest на время тела теста), добавлен как
+  дешёвый подтверждающий признак; основной — `sys.modules`.
+- Оба читаются **в момент вызова** (NFR-4). Признак консервативный: ложноположительное срабатывание в
+  боевом рантайме требует, чтобы кто-то импортировал `pytest` в процесс uvicorn — чего штатный
+  entrypoint не делает (зафиксировано как допущение, см. `10-tech-risks.md` TR-1).
+
+### D3 — Решение `decide`: default-deny, sandbox-allowlist, опт-ин
+
+`decide(project_id, op, work_item_id) -> (bool ok, str reason)` — чистая, never-raise:
+
+| Шаг | Условие | Исход | reason |
+|-----|---------|-------|--------|
+| 1 | `not _in_test_process()` | **ALLOW** | `live-runtime` (прод/staging — no-op, NFR-2/3) |
+| 2 | `project_id` пуст/None/нерезолвим | **BLOCK** | `ambiguous-target` (NFR-1: «не знаю → не пишу») |
+| 3 | `not settings.plane_test_write_enabled` | **BLOCK** | `opt-in-disabled` |
+| 4 | `project_id ∉ sandbox_allowlist` | **BLOCK** | `prod-project-in-test` |
+| 5 | иначе | **ALLOW** | `sandbox-opt-in` (audit INFO) |
+
+- **Allowlist sandbox-only (BR-2, AC-3).** Шаг 4 запрещает боевой ORCH (`7a79f0a9-…`) и любой боевой
+  enduro-проект **даже при включённом opt-in** — opt-in лишь снимает шаг 3, allowlist остаётся
+  жёстким полом.
+- **Fail-closed по неопределённости (NFR-1, AC-4).** Нерезолвимый целевой проект → блок (шаг 2).
+- **never-raise (NFR-5).** Любое внутреннее исключение `decide` интерпретируется вызывающим примитивом
+  по контексту: в боевом пути это уже ALLOW (шаг 1 не достигнут — `_in_test_process` False); в
+  тест-пути исключение трактуется как **BLOCK** (громко, fail-closed) — дефект всплывает, а не
+  маскируется. (Реализация: `decide` ловит свои ошибки и в тест-контексте возвращает
+  `(False, "guard-error")`, в live-контексте — `(True, …)`.)
+
+### D4 — Kill-switch: его нет (умышленно, NFR-6/FR-7) — реверс через opt-in
+
+**Сознательное расхождение с конвенцией «у каждого leaf есть `*_enabled` kill-switch».** Гард,
+делающий прод-запись из pytest *физически невозможной*, **не должен** поставляться с конфигом,
+который её переоткрывает — это и есть «чёрный ход», запрещённый NFR-6. Прямой прецедент в репозитории:
+`_no_telegram` тоже **не имеет** флага «разрешить реальный Telegram в тестах» — это безусловный
+страховочный пол.
+
+- **Единственный реверсивный регулятор — opt-in** `plane_test_write_enabled` (default `False` =
+  безопасно) + allowlist `plane_test_sandbox_projects` (default = единственный SANDBOX id). Он
+  управляет **только sandbox-записью**; его off-состояние — безопасный дефолт, on-состояние —
+  sandbox-bound. «Выключить защиту» ≠ «разрешить прод из pytest»: такого перехода в дизайне **нет**.
+- Рантайм-leaf **инертен в боевом рантайме** по построению (`_in_test_process()` False) → отдельный
+  «выключатель» для безопасности прода не нужен; leaf never-raises → не может уронить боевой путь.
+- **Норматив на будущее (анти-дрейф):** не добавлять «общий kill-switch гарда», обнуляющий
+  prod-блок в тест-процессе — это реинтродуцирует дефект ORCH-114. Зафиксировано в `10-tech-risks.md`
+  (TR-4) и в сквозном adr-0046.
+
+### D5 — Conftest-floor: независимый default-deny во всех тестах (BR-4, FR-3)
+
+Autouse-фикстура `tests/conftest.py::_plane_sandbox_only` (по образцу `_reset_webhook_secrets` /
+`_disable_merge_verify`) форсит безопасные дефолты для **каждого** теста через `monkeypatch`,
+**перекрывая** любую боевую переменную, унаследованную из окружения контейнера:
+
+```python
+@pytest.fixture(autouse=True)
+def _plane_sandbox_only(monkeypatch):
+    from src import config as _cfg
+    monkeypatch.setattr(_cfg.settings, "plane_test_write_enabled", False, raising=False)
+    monkeypatch.setattr(_cfg.settings, "plane_test_sandbox_projects",
+                        "8c5a3025-4f9d-4190-b79f-fa06276bb27e", raising=False)
+    yield
+```
+
+- С opt-in `False` гард блокирует **все** записи в тестах (и sandbox, и прод) → AC-4 default-deny.
+- **Sandbox-e2e переопределяет** в собственной фикстуре *после* autouse (точно как
+  `test_merge_verify`/`test_orch114_*` ре-энейблят свои флаги): `plane_test_write_enabled=True`
+  (+ allowlist уже содержит sandbox) → запись в SANDBOX проходит (AC-2), в прод — по-прежнему блок
+  (allowlist, AC-3).
+- Floor **независим от рантайм-логики**: даже если рантайм-leaf по ошибке вернёт ALLOW, инвариант
+  «opt-in off» делает прод-запись из обычного pytest невозможной. Два слоя, оба sandbox-bound →
+  ни один не способен разрешить прод-запись из pytest (двойной NFR-6).
+
+### D6 — Конфиг-ключи
+
+В `src/config.py` (дефолты = безопасные):
+
+| Ключ | Env | Дефолт | Назначение |
+|------|-----|--------|------------|
+| `plane_test_write_enabled` | `ORCH_PLANE_TEST_WRITE_ENABLED` | `False` | opt-in реальной записи из тест-процесса |
+| `plane_test_sandbox_projects` | `ORCH_PLANE_TEST_SANDBOX_PROJECTS` | `"8c5a3025-4f9d-4190-b79f-fa06276bb27e"` | CSV allowlist sandbox-проектов |
+
+- **НЕ `*_repos`-scope.** В отличие от гейт-leaf'ов (`serial_gate`/`coverage_gate` *действуют* на
+  репо), этот гард защищает запись в **любой** боевой проект общего workspace (включая боевой enduro,
+  BR-2). Регуляторов scope по репо нет; единственные гейты — `_in_test_process()` (рантайм) + opt-in
+  (как у observer-leaf `lessons`, который тоже не скоупится по репо). Зафиксировано в adr-0046.
+- `.env.example` дополняется обоими ключами с безопасными дефолтами (deliverable developer'а).
+
+### D7 — Аудит/наблюдаемость (BR-6, FR-5, AC-8)
+
+- **Блок** → структурный `logger.warning`/`error` с полями `project_id`, `work_item`, `op`
+  (`state`/`comment`), `reason` (`prod-project-in-test`/`opt-in-disabled`/`ambiguous-target`/
+  `guard-error`). Формулировка делает инцидент класса ORCH-114 **очевидным** (не молчаливым).
+- **Разрешённая sandbox-запись** → audit `logger.info` с `project_id` и `op`.
+- Новый эндпоинт **не вводится** (TRZ §4): состояние гарда (флаг/allowlist) при желании дорисовывается
+  read-only в `GET /queue` — **необязательно**, оставлено на усмотрение developer'а.
+
+## Альтернативы
+
+- **Только autouse-фикстура в `conftest.py` (без рантайм-leaf)** — отвергнуто: не делает прод-запись
+  *физически невозможной* (AC-7) — любой путь, обошедший мок/фикстуру (прямой импорт `plane_sync` в
+  скрипте под pytest, sandbox-e2e с опечаткой проекта), снова смутирует прод. Нужен рантайм-floor на
+  момент вызова. Фикстура остаётся как **дополнительный** независимый слой (D5), не единственный.
+- **Обёртка/монки над `httpx`-транспортом** — отвергнуто: уровень ниже, чем известны
+  `project_id`/`work_item`/`op` (хуже аудит); хрупко к смене HTTP-клиента; ловит и легитимные GET.
+  Низкий чокпоинт в примитивах точнее и стабильнее.
+- **Подмена `settings.plane_api_token`/env на тестовый токен** — отвергнуто прямо BRD/NFR-4:
+  `PLANE_HEADERS`/`PROJECT_ID` захвачены на импорте → подмена постфактум бесполезна; `setdefault`
+  no-op в проде. Не лечит корень.
+- **Гонять тесты в sandbox-проекте по дефолту (сменить дефолтный `PROJECT_ID`)** — отвергнуто: не
+  fail-closed (живой токен + забытый мок всё равно может адресовать прод явным `project_id`); не
+  отличает прод от sandbox по *намерению*.
+- **Конвенциональный `plane_write_guard_enabled` kill-switch** — отвергнуто (D4): его off-состояние
+  было бы «чёрным ходом» к прод-записи из pytest (NFR-6). Реверс обеспечивает opt-in.
+
+## Последствия
+
+- **+** Прод-запись в Plane из любого pytest/worktree-процесса **физически невозможна** независимо от
+  токена (AC-1/AC-7); инцидент класса ORCH-114 закрыт у источника и стал **видимым** (аудит).
+- **+** Боевой и staging рантаймы — **байт-в-байт** (no-op гарда, `_in_test_process()` False);
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД не тронуты (NFR-2/NFR-3, AC-5/AC-6).
+- **+** Два независимых sandbox-bound слоя (рантайм-leaf + conftest-floor) → нет одиночной точки, чьё
+  выключение переоткрывает прод (NFR-6).
+- **+** Sandbox-e2e сохранён (opt-in + allowlist, AC-2); `scripts/staging_check.py` Block C
+  работоспособен.
+- **−** Детект тест-процесса завязан на «pytest-в-процессе» → теоретический ложноположительный риск,
+  если кто-то импортирует `pytest` в боевой uvicorn-процесс (не делает штатный entrypoint). Митигейшн:
+  TR-1, консервативный признак, аудит-видимость; в худшем случае под opt-in остаётся sandbox-запись.
+- **−** Намеренный отказ от kill-switch расходится с привычной конвенцией → требует явной фиксации,
+  чтобы будущий агент не «добавил выключатель» (D4-норматив, TR-4, adr-0046).
+- **Откат:** удалить врезку гарда из 3 примитивов + autouse-фикстуру + 2 конфиг-ключа → поведение
+  байт-в-байт до ORCH-117 (дефект возвращается). Частичный «мягкий» откат (oct-in `True` глобально) —
+  **запрещён** как небезопасный (вернёт прод-риск только при условии allowlist; всё равно
+  sandbox-bound).
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-117/01-brd.md`
+- TRZ: `docs/work-items/ORCH-117/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-117/03-acceptance-criteria.md`
+- Tech-risks: `docs/work-items/ORCH-117/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`
+- Сверено по коду: `src/plane_sync.py:17,57,846-889,1038-1051`, `tests/conftest.py` (`_no_telegram`),
+  `scripts/staging_check.py:283`, `src/deploy_status_guard.py` (образец leaf), `src/config.py`
+- Прецедент-инвариант: `_no_telegram` (autouse safety-floor), `docs/_standards/TRACEABILITY.md`

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

@@ -0,0 +1,41 @@
+---
+work_item: ORCH-117
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-117 — sandbox-only fail-closed изоляция записи в Plane
+
+Work Item: **ORCH-117** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации решения ADR-001 и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Ложноположительный детект тест-процесса** в боевом/staging рантайме (`pytest` каким-то образом импортирован в процесс uvicorn) → блокировка легитимной боевой/sandbox записи (молчаливая потеря Plane-индикации, слой B ORCH-066). | Низ. | Сред. | Штатный entrypoint `uvicorn src.main:app` **не** импортирует `pytest`; merge-gate/coverage гоняют pytest **отдельным субпроцессом** (его блок легитимен). Признак консервативный (`sys.modules`+`PYTEST_CURRENT_TEST`), читается на момент вызова. Аудит-WARNING делает любой блок видимым (BR-6) → ложный блок в проде немедленно заметен, а не молчалив. Зафиксированное допущение: «прод-процесс не импортирует pytest». |
+| TR-2 | **Ложноотрицательный детект** (worktree-тест-процесс не распознан как pytest) → дефект ORCH-114 остаётся. | Низ. | Выс. | Инцидентный путь (worktree `python -m pytest`) **гарантированно** имеет `pytest` в `sys.modules`. Двойной слой: даже при сбое рантайм-leaf conftest-floor (D5) держит default-deny. Обязательный регресс-тест AC-1/TC-01 (красный до фикса) доказывает покрытие именно инцидентного пути. |
+| TR-3 | **Захват на импорте** (`PLANE_HEADERS`/`PROJECT_ID`, стр. 17/57): размещение гарда не там → ложное чувство защиты (NFR-4). | Низ. | Выс. | Архитектурно жёстко: гард — на момент **вызова** примитива, до сети, не зависит от токена/`os.environ.setdefault` (ADR-001 D1/D2). AC-7 проверяет это буквально. |
+| TR-4 | **Kill-switch как чёрный ход:** будущий агент «добавляет общий выключатель гарда», который в off-состоянии переоткрывает прод-запись из pytest (NFR-6). | Сред. | Выс. | Дизайн **умышленно без** prod-блок kill-switch (ADR-001 D4): реверс — только sandbox-bound opt-in. Норматив зафиксирован в ADR-001, adr-0046 и `10-tech-risks` как анти-дрейф; прецедент `_no_telegram` (тоже без «разрешить» флага). Reviewer ловит реинтродукцию выключателя как finding ≥P1. |
+| TR-5 | **Регрессия существующего сьюта:** autouse-фикстура `_plane_sandbox_only` ломает тесты, которые ждали реальную/иную запись или ассертили на мок-вызов. | Низ. | Сред. | Большинство тестов уже **мокируют** `plane_*`/`add_comment` (TRZ §7) → реальной записи и так нет; гард лишь делает это гарантией по умолчанию. Фикстура форсит лишь безопасные дефолты (opt-in off), не подменяет сами примитивы. AC-11 (полный регресс зелёный) — обязательный гейт. |
+| TR-6 | **Sandbox-e2e ложно блокируется** (opt-in не доезжает / порядок фикстур). | Низ. | Сред. | Прецедент уже отработан в репозитории: `test_merge_verify`/`test_orch114_*` ре-энейблят свои флаги **после** autouse. AC-2 проверяет реальную sandbox-запись под opt-in; `staging_check.py` Block C — smoke. |
+| TR-7 | **Утечка GET до гарда:** даже без PATCH/POST примитив мог бы сходить в боевой workspace `find_issue_id`/`stage_to_state`. | Низ. | Низ. | Гард размещён **до** любого сетевого шага (сразу после локального `_resolve_project_id`) — ни GET, ни мутации (ADR-001 D1). |
+| TR-8 | **Кросс-каттинг с ORCH-066/094/061:** гард меняет поведение общего `plane_sync`, потенциально задевая deploy-status guard (ORCH-094), staging-tolerance (ORCH-061), статусную модель (ORCH-066). | Низ. | Сред. | Гард — no-op в боевом/staging рантайме (`_in_test_process()` False) → ORCH-094/061/066 в проде/стейджинге **не затронуты**. В тестах те фичи и так под своими дефолтами/моками. Маркер-инвариант не ломается (правка примитивов аддитивна, не трогает машинные ключи). |
+
+## Сводный вывод
+
+Доминирующий класс — **корректность детекта тест-процесса** (TR-1/TR-2) и **анти-дрейф kill-switch**
+(TR-4). Все три закрываются архитектурно: консервативный признак «pytest-в-процессе» на момент
+вызова + двойной независимый sandbox-bound слой (рантайм-leaf + conftest-floor) + обязательный
+регресс-тест инцидентного пути (AC-1). Остаточный риск для прод-конвейера (self-hosting) — **низкий**:
+гард инертен в боевом и staging рантайме по построению и never-raises, поэтому не способен ни уронить
+конвейер, ни заблокировать легитимную боевую запись; худший реалистичный исход (ложный блок в проде)
+требует несуществующего в штатном entrypoint импорта pytest и был бы немедленно виден через аудит.
+
+**Эскалация не требуется:** решение аддитивно, в границах принципов (Docker/SQLite/leaf-pattern/
+never-raise), не трогает `STAGE_TRANSITIONS`/`QG_CHECKS`/схему БД, не вводит новую стадию/QG/компонент
+инфраструктуры. Лейбл `arch:major-change` не ставится; возврат в анализ не нужен.

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

@@ -0,0 +1,107 @@
+---
+verdict: APPROVED
+work_item: ORCH-117
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-117
+version: 1
+---
+
+# Review ORCH-117 — sandbox-only fail-closed изоляция записи в Plane
+
+## Summary
+Багфикс-трек (bug → escalate full-cycle) закрывает корневой класс инцидента **ORCH-114**: тест/
+worktree-процесс выполнял РЕАЛЬНУЮ запись (`PATCH …/issues/… state=<Done>` + комментарий) против
+**боевого** Plane-проекта, наследуя живой боевой токен. Реализован чистый never-raise leaf
+`src/plane_write_guard.py` (`decide()` + `audit_*` + `snapshot`), врезанный через тонкий хелпер
+`_guard_allows_write` в **3 (все) примитива записи** `plane_sync` (`update_issue_state`/`add_comment`/
+`_set_issue_state_direct`) на момент вызова — сразу после `_resolve_project_id` и до любого сетевого
+шага. Второй sandbox-bound слой — autouse-floor `tests/conftest.py::_plane_sandbox_only`.
+
+Реализация **точно** соответствует ADR-001 (D1–D7) и сквозному adr-0046. Все четыре оси проверки
+пройдены, P0/P1-findings нет.
+
+**Проведённая верификация (фактический прогон):**
+- `pytest tests/test_orch117_plane_write_isolation.py` → **16 passed** (TC-01…TC-14).
+- **Обязательный регресс ORCH-019 BR-4 подтверждён вручную:** откатил врезку `plane_sync.py` на
+  версию `origin/main` → **TC-01 КРАСНЫЙ** (`httpx.patch` уходит на боевой проект
+  `7a79f0a9-…` с `LIVE-PROD-TOKEN` — воспроизводит инцидент); с фиксом — **ЗЕЛЁНЫЙ**. Тест-фиксатор
+  дефекта содержателен.
+- `pytest tests/ -q` → **2068 passed** (AC-11 — нулевая регрессия, включая `test_system_docs.py`).
+- `grep httpx.(patch|post|put|delete)` по `plane_sync.py` → ровно 3 write-call-site, **все**
+  под гардом; необёрнутых примитивов записи нет.
+- `git diff --name-only src/` → изменены **только** `config.py`/`plane_sync.py`/`plane_write_guard.py`;
+  `stages.py`/`qg/`/`db.py`/`stage_engine.py` — **не тронуты**.
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice-to-have (не блокирует)
+- [ ] Четыре существующих теста (`test_plane_author.py`, `test_plane_status_model.py`,
+  `test_plane_sync_labels.py`, `test_stage_visibility.py`) обходят гард монкипатчем
+  `decide → (True, "test-bypass")`. Это легитимно (per-test autouse, авто-revert; `httpx` в этих
+  тестах замокан → реальной записи быть не может; сам гард покрыт отдельным сьютом; паттерн —
+  аналог `_disable_merge_verify`). Чуть более хирургичной альтернативой был бы opt-in + добавление
+  целевого проекта в allowlist, но тесты проверяют маршрутизацию именно в НЕ-sandbox проекты, так
+  что полный bypass оправдан и явно задокументирован в каждом docstring. Менять не требуется.
+
+## Ось 1 — Соответствие ТЗ (02-trz / 03-acceptance-criteria)
+- **FR-1** (fail-closed блок прод-записи из теста) — ✅ TC-01/02/03/04/09.
+- **FR-2** (разрешено только sandbox + opt-in) — ✅ TC-06/07; `decide` шаги 3–5 1:1 с таблицей ADR.
+- **FR-3** (дефолтная поза fail-closed через conftest-floor) — ✅ TC-05/13.
+- **FR-4** (детект тест-процесса; no-op в боевом/staging) — ✅ TC-10/11; `_in_test_process` =
+  `"pytest" in sys.modules` / `PYTEST_CURRENT_TEST`, call-time.
+- **FR-5** (аудит блок ERROR / allow INFO с полями) — ✅ TC-12.
+- **FR-6** (never-raise в боевом пути; громко в тесте) — ✅ live-path возвращает ALLOW ДО try-блока;
+  in-test исключение → fail-CLOSED `guard-error`.
+- **FR-7** (kill-switch без чёрного хода) — ✅ TC-14 (ассерт отсутствия `plane_write_guard_enabled`).
+- **AC-1…AC-11** — все выполнены; AC-1 (обязательный регресс) и AC-11 (полный регресс) подтверждены
+  фактическим прогоном (см. Summary).
+
+## Ось 2 — Соответствие ADR (06-adr/ADR-001 + adr-0046)
+- D1 чокпоинт (после `_resolve_project_id`, до сети, 3 примитива) — ✅ сверено по diff.
+- D2 детект тест-процесса — ✅. D3 `decide` default-deny/sandbox-allowlist/opt-in — ✅ 1:1 с таблицей.
+- D4 **умышленно без kill-switch прод-блока** — ✅ соблюдено (важный анти-дрейф: добавление общего
+  выключателя реинтродуцировало бы дефект ORCH-114; reviewer ловил бы как ≥P1 — здесь его нет).
+- D5 conftest-floor — ✅. D6 конфиг-ключи (`plane_test_write_enabled=False`,
+  `plane_test_sandbox_projects=8c5a3025-…`) — ✅. D7 аудит — ✅.
+- **Инварианты не сломаны:** `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена `check_*`/
+  machine-verdict-ключи/схема БД — байт-в-байт (диф трогает только 3 src-файла; гейтовые модули
+  не изменены). Трассировка (ORCH-078): врезка в 3 примитива не ломает чужих маркированных
+  инвариантов.
+
+## Ось 3 — Качество кода
+- never-raise дисциплина корректна: внешний (боевой) путь физически не может упасть из-за гарда
+  (return до try); внутренний тест-путь fail-CLOSED.
+- Полные docstrings на всех публичных функциях; стабильные reason-слаги вынесены константами и
+  проверяются тестами.
+- **Багфикс-регресс (ORCH-019 BR-4):** TC-01 — фиксатор дефекта, красный до фикса / зелёный после
+  (проверено вручную). Требование выполнено.
+- Покрытие всех 3 точек записи; необёрнутых write-примитивов не осталось.
+
+## Документация
+Обновлена полностью (golden source наравне с кодом), AC-10 выполнен:
+- `CLAUDE.md` — новый раздел «Sandbox-only fail-closed изоляция записи в Plane (ORCH-117)». ✅
+- `docs/architecture/README.md` — новый компонент «Plane write guard». ✅
+- `docs/operations/INFRA.md` — таблица env (`ORCH_PLANE_TEST_WRITE_ENABLED`/
+  `ORCH_PLANE_TEST_SANDBOX_PROJECTS`) + раздел «что изолировано». ✅
+- `.env.example` — оба ключа с безопасными дефолтами. ✅
+- `CHANGELOG.md` — запись `[Unreleased]`. ✅
+- ADR: `06-adr/ADR-001-sandbox-only-plane-write-guard.md` + сквозной
+  `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`. ✅
+- **Обзорные доки (ORCH-079) / витрина `docs/overview/` (ORCH-011):** обновлять не требуется —
+  ORCH-117 это защитный тест-изоляционный гард, а не ранее задокументированное «Известное
+  ограничение» README и не изменение функциональности конвейера/стадий/гейтов/агентов/интеграций,
+  показываемой в витрине; `test_system_docs.py` зелёный в полном прогоне.

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

@@ -0,0 +1,69 @@
+---
+result: PASS
+work_item: ORCH-117
+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-117
+---
+
+# Test Report — ORCH-117 — sandbox-only fail-closed изоляция записи в Plane
+
+## Окружение
+- 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-117-bug-test-staging-plane-writes-`
+- Ветка: `feature/ORCH-117-bug-test-staging-plane-writes-`
+- Дата: 2026-06-15
+
+## Smoke API (read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
+- `GET /status` → 200, ORCH-117 (task 104) на стадии `testing`, `agent_running: null` ✅
+- `GET /queue` → 200; блок `serial_gate` присутствует ✅; блок `auto_labels` присутствует ✅
+  (регресс смока ORCH-088 не обнаружен).
+
+## Результаты — покрытие test-plan (04-test-plan.yaml)
+
+| TC ID | Описание | Тест | Результат |
+|-------|----------|------|-----------|
+| TC-01 | РЕГРЕСС ORCH-114: pytest-env + живой прод-токен → `notify_stage_change('ORCH-114','deploy','done')` на боевой проект делает 0 httpx.patch/post | `test_tc01_notify_stage_change_prod_makes_zero_writes` | PASS |
+| TC-02 | `update_issue_state` в тест-процессе с боевым проектом → блок; аудит `prod-project-in-test` | `test_tc02_update_issue_state_prod_blocked` | PASS |
+| TC-03 | `add_comment` в тест-процессе с боевым проектом → блок (httpx.post не вызван) | `test_tc03_add_comment_prod_blocked` | PASS |
+| TC-04 | `_set_issue_state_direct` + `set_issue_done` в тест-процессе с боевым проектом → блок | `test_tc04_set_issue_state_direct_prod_blocked`, `test_tc04_set_issue_done_prod_blocked` | PASS |
+| TC-05 | Default-deny: без opt-in запись блокируется для ЛЮБОГО проекта (вкл. sandbox) | `test_tc05_default_deny_blocks_sandbox_and_prod` | PASS |
+| TC-06 | Sandbox-разрешение: opt-in + SANDBOX `8c5a3025-…` → реальный httpx-вызов разрешён | `test_tc06_sandbox_optin_allows_write` | PASS |
+| TC-07 | Sandbox-only даже с opt-in: opt-in включён, боевой проект → блок | `test_tc07_optin_still_blocks_prod` | PASS |
+| TC-08 | Fail-closed при неопределённости: пустой/неразрешимый project_id → блок | `test_tc08_ambiguous_target_blocked` | PASS |
+| TC-09 | Устойчивость к захвату токена на импорте: гард блокирует на момент вызова | `test_tc09_blocks_regardless_of_captured_token` | PASS |
+| TC-10 | Нулевая регрессия боевого рантайма: НЕ-pytest → гард no-op, реальный httpx-вызов | `test_tc10_live_runtime_is_noop` | PASS |
+| TC-11 | Staging != pytest: staging-рантайм (sandbox) → запись проходит | `test_tc11_staging_writes_sandbox` | PASS |
+| TC-12 | Аудит: блок → структурный WARNING/ERROR с полями; sandbox-allow → audit-INFO | `test_tc12_block_audited_loudly`, `test_tc12_sandbox_allow_audited_info` | PASS |
+| TC-13 | Дефолтная autouse-страховка conftest: обычный тест не пишет в боевой Plane | `test_tc13_conftest_floor_default_deny` | PASS |
+| TC-14 | Kill-switch без чёрного хода: прод-запись из pytest не разрешается молча | `test_tc14_no_killswitch_backdoor` | PASS |
+| TC-15 | Полный регресс `tests/ -q` зелёный (autouse-фикстура не ломает существующие тесты) | `pytest tests/` | PASS |
+
+Сопоставление с `03-acceptance-criteria.md`: AC-1↔TC-01, AC-2↔TC-06, AC-3↔TC-07,
+AC-4↔TC-05/08, AC-5↔TC-10, AC-6↔TC-11, AC-7↔TC-09, AC-8↔TC-12, AC-9↔TC-14,
+AC-10 (docs/config — проверено reviewer'ом, APPROVED), AC-11↔TC-15. Все AC покрыты.
+
+## Вывод pytest
+
+Целевой файл:
+```
+tests/test_orch117_plane_write_isolation.py ... 16 passed, 1 warning in 0.40s
+(TC-01…TC-14; TC-04 и TC-12 — по два теста)
+```
+
+Полный регресс:
+```
+2068 passed, 1 warning in 88.02s (0:01:28)
+```
+(единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, не связан с ORCH-117.)
+
+## Итог
+**PASS** — все 15 TC выполнены и сопоставлены с критериями приёмки; целевой сьют (16 тестов) и
+полный регресс (2068 passed) зелёные; smoke API (`/health`, `/status`, `/queue` с блоками
+`serial_gate`/`auto_labels`) — OK. Задача готова к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,34 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-117
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T18:30:57Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance
+(port 8501, executed inside the `orchestrator-staging` container per ORCH-048).
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+- REAL failed: none
+- SANDBOX_INFRA failed (waived, ORCH-061): C9a, C9b
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+## Block detail
+
+- **Block A (SMOKE):** A1 `/health` 200 ✓, A2 `/queue` 200 ✓, A3 `ORCH_STAGING=true` ✓
+- **Block B (ACCESS):** B4 Plane sandbox project ✓, B5 Gitea `orchestrator-sandbox` push=true ✓,
+  B6 registry isolation (sandbox present, prod ET/ORCH absent) ✓
+- **Block C (E2E, mode=stub):** C7 create issue ✓, C8 trigger pipeline ✓,
+  C9a/C9b — sandbox-infra (bot accounts not project members), waived; exit 0 preserved.
+
+Staging gate passed. Cleanup completed (sandbox Plane issue deleted, HTTP 204).

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH: replace avoidable LLM control paths with deterministic implementations
+
+Work Item ID: ORCH-118
+
+## Description
+
+TBD

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

@@ -0,0 +1,248 @@
+---
+work_item: ORCH-118
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-118 — replace avoidable LLM control paths with deterministic implementations
+
+Work Item: **ORCH-118** · Repo: **orchestrator** · Стадия: analysis
+
+> ⚠️ **Inventory-first.** Это **зонтичная inventory/architecture-задача**, а НЕ реализация
+> детерминированных раннеров. Её результат — **карта** всех мест вызова LLM + классификация +
+> упорядоченный roadmap + нормативная политика использования LLM, защищённая структурными тестами.
+> Реализация конкретных замен — **последующие задачи**, запускаемые ПОСЛЕ утверждения карты. Их код
+> в ORCH-118 **не вносится** (см. §2 «Вне объёма»).
+
+> 📌 **Follow-up'ы именуются по РОЛИ, без выдуманных Plane-ID.** Roadmap рекомендует отдельные
+> follow-up задачи по ролям-кандидатам (**deployer-замена**, **tester-гибрид** и т.д.). Конкретные
+> Plane-ID этих задач в артефактах ORCH-118 **НЕ фиксируются** — они присваиваются при фактическом
+> заведении задач в backlog. Аналитик не имеет доказательного источника на конкретные ID и не должен
+> их выдумывать (см. NFR-6).
+
+> 🔁 **Revision R3 (2026-06-15).** Из пакета **удалена** нормативная привязка follow-up'ов к
+> конкретным ID `ORCH-115`/`ORCH-116` (этих work item нет ни в репозитории, ни в подтверждённом
+> backlog — claim «источник истины: live Plane backlog» был **непроверяемым**). Вместе с ней удалены
+> навязывавший её структурный тест (бывш. TC-11) и отдельный критерий приёмки (бывш. AC-9). Follow-up'ы
+> теперь описаны **по роли**, ID — TBD. Содержательная классификация ролей не менялась
+> (deployer = кандидат на детерминированную замену, tester = кандидат на hybrid-fallback).
+> *(R1→R2 ранее «чинил» порядок этих ID; R3 убирает корень проблемы — фиксацию несуществующих ID.)*
+
+> 🔁 **Revision R4 (2026-06-15) — единственный оставшийся блокер R3-ревью.** Рецензент подтвердил:
+> follow-up'ы по роли / TBD — ОК, `00-business-request.md=TBD` (конвенция репо) — НЕ блокер, скоуп
+> docs+tests — ОК; **менять их не нужно**. Закрывается **один** блокер: инвариант «места вызова LLM»
+> **смешивал** факт *«существует процесс Claude CLI / спавнится subprocess»* (транспорт/механизм) с
+> фактом *«на control-path происходит **LLM-консультация** — поток управления потребляет суждение
+> LLM»* (семантическая единица, ради которой и существует задача «replace avoidable **LLM** control
+> paths»). R4 **разводит** эти два понятия во всех артефактах (см. новый блок «Единица анализа» ниже,
+> уточнённые BR-1/BR-3/BR-6, FR-1/FR-3/FR-6, AC-1/AC-3/AC-6, TC-01/TC-02 + новый TC-12). Содержательная
+> классификация ролей и весь R3-материал (анти-фабрикация ID) — **без изменений**.
+
+---
+
+## 0. Единица анализа: «LLM-консультация» ≠ «процесс Claude CLI» (R4)
+
+Задача — про **LLM control paths**, поэтому единица инвентаря/классификации/инвариантов — это
+**LLM-консультация (call-site)**, а НЕ «спавн процесса / существование Claude CLI». Три ортогональных
+факта фиксируются **раздельно** (их смешение и было блокером R3-ревью):
+
+1. **LLM-консультация (семантическая единица).** Точка потока управления, где решение/артефакт
+   конвейера **потребляет суждение LLM** (инференс модели). Именно её перечисляет и классифицирует
+   карта. «Заменить avoidable LLM control path» = убрать *консультацию* там, где суждение не нужно, —
+   независимо от того, каким транспортом она реализована.
+2. **Транспорт (механизм) ≠ консультация.** Claude CLI-subprocess через `launcher._spawn`
+   (`src/agents/launcher.py`, сборка `CLAUDE_BIN --print … --system-prompt "$(cat …)"` + `Popen`) —
+   **текущий единственный транспорт**, которым реализуется LLM-консультация. Транспорт — это одна
+   *реализация* понятия, а НЕ его *определение*. «Существует процесс Claude CLI» само по себе **не**
+   равно «принято решение на основе суждения LLM».
+3. **Capability ≠ consultation (способность ≠ факт консультации).** Спавн процесса делает site
+   *LLM-capable*; происходит ли консультация фактически — **гейтится потоком управления**:
+   - `D1/D2` (`deploy-finalizer`/`post-deploy-monitor`) — job-роли, **занимающие слот агента**, но
+     перехватываемые в `launch_job` **до** `_spawn` (`src/agents/launcher.py`, код прямо помечает
+     «Not an LLM spawn») → **консультации LLM нет**, хотя «агент» как job существует;
+   - timeout-kill (`exit_code=-9`) / salvage-guard (`if exit_code==0`) → спавненный процесс может **не
+     произвести** потреблённого суждения.
+   Поэтому «процесс спавнится» **переоценивает** «суждение потреблено».
+
+Следствие для инварианта единственной точки (детализируется в BR-1/BR-6): он должен быть
+**транспорт-агностичным и двусторонним** — (i) единственный транспорт LLM-консультации в `src/**` —
+`_spawn`, И (ii) **отсутствует любой иной транспорт** (импорт `anthropic`/`openai`/LLM-SDK, прямой
+HTTP-эндпоинт Anthropic/Claude, второй model-invoking subprocess-сборщик `--system-prompt`/`--model`).
+Дискриминатор — **«консультирует LLM», а не «спавнит subprocess»**: десятки subprocess-вызовов в
+`src/**` (`git`/`pytest`/`docker`/`ssh`/сканеры/`staging_check.py`) **не** являются LLM-консультациями
+и не должны попадать под инвариант (см. FR-6 матчинг).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+Зонтичный follow-up по итогам RCA-цепочки **ORCH-114/117** (и предшествующих ORCH-110/111/112/113):
+корневым классом инцидентов было то, что **side-effectful и решающие control-path'ы не имели единого
+детерминированного владения** — где-то решение принималось «потому что так удобно» через LLM-агента,
+хотя по сути это исполнение фиксированных команд и маппинг результата.
+
+Установленный факт по текущему коду (инвентаризация — §1 TRZ, артефакт-карта):
+
+- В оркестраторе **единственный транспорт LLM-консультации** — `src/agents/launcher.py::_spawn` (одна
+  `subprocess.Popen` сборка Claude CLI: `CLAUDE_BIN --print … --system-prompt "$(cat …)"`), которым
+  пользуются **6 ролей-агентов** (analyst, architect, developer, reviewer, tester, deployer).
+  Прямых вызовов Anthropic API / LLM-SDK / иных model-invoking транспортов в `src/**` **нет**
+  (подтверждено инвентаризацией; впредь — держится тестом FR-6). ⚠️ Это утверждение про **транспорт**,
+  а не про «единственный subprocess»: в `src/**` десятки прочих `subprocess`-вызовов (`git`/`pytest`/
+  `docker`/`ssh`/сканеры) — они **не** консультируют LLM (см. §0).
+- **Все остальные control-path'ы уже детерминированы (без LLM):** маршрутизация стадий
+  (`STAGE_TRANSITIONS`/`advance_stage`), все Quality Gate'ы и под-гейты (`check_*`, security/merge/
+  coverage/image-freshness), парсеры вердиктов (`_parse_*` через `frontmatter.py`), классификатор
+  ретраев (`error_classifier.py`), serial-gate/transition-lease/reconciler/reaper, а также **две
+  зарезервированные job-роли** `deploy-finalizer` и `post-deploy-monitor` (перехватываются в
+  `launch_job` **до** `_spawn` — это рабочий прецедент детерминированной замены агента).
+- Среди 6 LLM-ролей **tester** и **deployer** по факту почти полностью исполняют детерминированные
+  команды (`pytest`, `staging_check.py`, exit-code → вердикт; прод-деплой на self-hosting уже идёт
+  детерминированным путём Phase A/B/C, ORCH-036), завёрнутые в LLM «для удобства».
+
+Боль/риск, который закрывает задача: LLM на механических путях — это (а) лишний источник
+недетерминизма и инцидентов (ложный вердикт/действие), (б) задержка (запуск opus-агента вместо
+прямого вызова), (в) расход токенов/денег. При этом «вслепую» убирать LLM нельзя — часть путей несёт
+**настоящее суждение** (анализ, архитектура, написание кода, ревью), и автономность/гибкость должны
+сохраниться.
+
+ORCH-118 даёт **доказательную карту** «где LLM действительно нужен, а где это удобство» и
+**упорядоченный план** безопасных замен — фундамент, на котором последующие срезы (по ролям-кандидатам)
+выполняются предсказуемо и без регресса.
+
+## 2. Объём (scope)
+
+### В объёме
+- **BR-1** Полная инвентаризация всех мест вызова LLM и всех ролей-агентов (карта call-site'ов).
+- **BR-2** Классификация каждого call-site в один из 4 классов (keep / replace-now / replace-later /
+  hybrid-fallback) с явным обоснованием.
+- **BR-3** Доказательное подтверждение (с привязкой `file:line`), что не-агентские control-path'ы
+  (маршрутизация / ретраи / QG / парсеры / finalizer'ы) уже детерминированы.
+- **BR-4** Упорядоченный roadmap замен: зависимости, оценка экономии токенов/времени, риски
+  безопасности, потребность в hybrid-fallback, рекомендованный **первый срез** — кандидаты названы
+  **по роли** (follow-up ID — TBD).
+- **BR-5** Нормативная **политика использования LLM** («LLM — только там, где нужно настоящее
+  суждение») как durable-документ.
+- **BR-6** Структурные regression-тесты, **прибивающие инварианты карты к коду** (транспорт-агностичный
+  двусторонний инвариант: единственный транспорт LLM-консультации `_spawn` **и** отсутствие иного
+  LLM-транспорта; детерминированные модули не консультируют LLM; карта покрывает все промпты; тотальность
+  классификации) — анти-дрейф.
+- **BR-7** Явно позиционировать **роль deployer** и **роль tester** как **кандидаты-follow-up** для
+  детерминированной замены — **по роли, без привязки к конкретным Plane-ID** (см. NFR-6).
+
+### Вне объёма
+- ❌ **Реализация** детерминированных раннеров deployer / tester и любых других замен — это отдельные
+  follow-up задачи ПОСЛЕ утверждения карты (явное требование заказчика в business request).
+- ❌ **Выдумывание/фиксация конкретных follow-up Plane-ID** (напр. `ORCH-115`/`ORCH-116`) в любых
+  артефактах ORCH-118 — ID присваиваются при заведении задач (NFR-6).
+- ❌ Изменение `STAGE_TRANSITIONS` / реестра `QG_CHECKS` / семантики и имён `check_*` /
+  machine-verdict-ключей (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
+  `coverage_status:`) / схемы БД.
+- ❌ Включение model-routing (G3 ORCH-41) или смена модели/эффорта ролей.
+- ❌ Любая правка поведения `src/**` в рантайме (ORCH-118 — **docs + tests only**, по образцу
+  ORCH-077/079/101/102/103/011).
+- ❌ Снижение автономности или гибкости конвейера.
+
+## 3. Заинтересованные стороны
+- **Заказчик / Owner** — инициатор RCA-трека ORCH-114/117; принимает карту и roadmap (gate утверждения).
+- **Сопровождающие платформы (self-hosting)** — выигрывают в стабильности, скорости, экономии токенов.
+- **Downstream-проекты (enduro-trails)** — делят общий прод/очередь; для них требуется **нулевая
+  регрессия** (NFR-1).
+- **Будущие исполнители follow-up'ов** — потребители карты, roadmap и политики.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 — Инвентарь LLM-консультаций (call-site'ов).** Выпустить durable-документ, перечисляющий
+  **каждое** место, где control-path **потребляет суждение LLM** или может его потребить (единица —
+  *LLM-консультация*, §0, а не «спавн процесса»): единственный транспорт `_spawn`, все 6 ролей-агентов
+  и обе зарезервированные job-роли `D1/D2` (включаются как доказательство «слот агента есть, но
+  консультации LLM нет» — перехват до `_spawn`). Для каждого — `file:line`, триггер, стадия/владелец,
+  выходной артефакт, machine-verdict-ключ (если есть), оценка токенов/времени, **признак
+  capability-vs-consultation** (LLM-capable vs фактически консультирует, §0.3). Проверяемо: каждый
+  `file:line` резолвится в реальный код.
+- **BR-2 — Классификация.** Каждому call-site присвоить **ровно один** класс из таксономии:
+  `keep-LLM` (нужно настоящее суждение), `replace-deterministic-now` (безопасная замена сейчас),
+  `replace-later/risky` (замена позже / рискованно), `needs-hybrid-fallback` (детерминированное ядро +
+  LLM-фолбэк на суждение). Для `keep-LLM` — **назвать конкретное суждение**, ради которого LLM
+  сохраняется.
+- **BR-3 — Подтверждение детерминизма не-агентских путей.** Документально, с `file:line`-доказательством,
+  зафиксировать, что маршрутизация стадий, ретраи, QG-проверки, парсеры вердиктов и finalizer'ы **не
+  консультируют LLM** (не зависят от суждения LLM — ни через `_spawn`, ни через иной транспорт; их
+  subprocess-вызовы git/pytest/docker/ssh/сканеров — детерминированные инструменты, не LLM, §0). Если
+  инвентаризация найдёт неожиданную LLM-консультацию — она попадает в карту (BR-1) и классификацию
+  (BR-2).
+- **BR-4 — Упорядоченный roadmap.** Ранжированный план замен: для каждого кандидата (названного **по
+  роли**) — зависимости, **оценка** экономии токенов/времени (из телеметрии `agent_runs`), риск
+  безопасности, нужен ли hybrid-fallback, ожидание kill-switch/обратимости. Явно указать
+  **рекомендованный первый срез** и обоснование выбора. Привязка к follow-up задаче — **по роли**;
+  конкретный Plane-ID НЕ фиксируется (заводится отдельно, NFR-6).
+- **BR-5 — Политика использования LLM.** Нормативный durable-документ: «LLM — только там, где требуется
+  настоящее суждение»; критерии решения keep vs replace; требование к новым/изменённым control-path'ам
+  обосновывать любое использование LLM против этой политики.
+- **BR-6 — Анти-дрейф структурными тестами.** Тесты, привязывающие инварианты карты к коду. Инвариант
+  единственной точки формулируется **транспорт-агностично и двусторонне** (R4, §0): (i) единственный
+  транспорт LLM-консультации в `src/**` — `_spawn`; **и** (ii) **отсутствует любой иной LLM-транспорт**
+  (импорт `anthropic`/`openai`/LLM-SDK, прямой HTTP-эндпоинт Anthropic/Claude, второй model-invoking
+  subprocess-сборщик `--system-prompt`/`--model`) — это и закрывает дыру «один `_spawn` зелёный, а
+  рядом проросла новая консультация другим транспортом». Дискриминатор теста — **«консультирует LLM»,
+  а не «спавнит subprocess»** (прочие subprocess git/pytest/docker/ssh/сканеров явно исключены из
+  матчинга). Плюс: перечисленные детерминированные модули/job-роли не несут LLM-консультации; карта
+  перечисляет ровно те 6 промптов, что лежат в `.openclaw/agents/`; классификация покрывает все
+  call-site'ы по одному разу. Тесты — offline (без сети/LLM/subprocess-к-модели). **Тест на привязку
+  к конкретным follow-up ID не вводится** (анти-паттерн: прибивал бы карту к непроверяемым ID, R3).
+- **BR-7 — Позиционирование follow-up'ов по роли.** Карта/roadmap явно отмечают **роль deployer** и
+  **роль tester** как кандидаты-замены, **не** реализуемые в ORCH-118; их старт гейтится утверждением
+  карты. Привязка — **по роли**, без конкретных Plane-ID (NFR-6).
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — Сохранение поведения (нулевая регрессия).** ORCH-118 — docs+tests only:
+  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи/схема БД — **байт-в-байт**; поведение
+  конвейера 1:1; enduro-trails не затронут.
+- **NFR-2 — Сохранение автономности и гибкости.** Ни инвентаризация, ни политика не должны
+  предлагать решений, снижающих автономный/пакетный режим (ORCH-088/089) или гибкость; политика
+  **защищает** автономность как инвариант любой будущей замены.
+- **NFR-3 — Self-hosting безопасность.** Задача только **читает** код и пишет docs+tests — не
+  деплоит, не рестартит прод-контейнер, не трогает `main`/force-push, не запускает процессов/сети.
+- **NFR-4 — Трассируемость и сопровождаемость.** Карта привязана к коду маркерами/тестом и остаётся
+  честной при эволюции кода; формат — по `docs/_standards/PIPELINE_DOCS.md` и `TRACEABILITY.md`.
+- **NFR-5 — Доказательность экономии.** Цифры экономии берутся из реальной телеметрии `agent_runs`
+  (модель/эффорт/токены/стоимость/время по ролям) и помечаются как **оценки** до фактического замера
+  после реализации.
+- **NFR-6 — Только проверяемые ссылки (анти-фабрикация, R3).** В артефактах фиксируются только
+  ссылки, резолвящиеся в код/документы репозитория. Конкретные **follow-up Plane-ID не выдумываются**:
+  кандидаты-замены именуются по роли; ID присваивается при заведении задачи. (Это закрывает корень
+  отклонённой ревизии R2.)
+
+## 6. Допущения и ограничения
+- Единственный транспорт LLM сейчас — Claude CLI через `launcher._spawn`; прямых вызовов Anthropic API
+  в `src/**` нет (подтверждается инвентаризацией).
+- Model-routing не включён — все 6 ролей на `claude-opus-4-8` (ORCH-41), что упрощает оценку экономии.
+- Карта — **снимок на момент задачи**, защищённый структурными тестами от тихого расхождения с кодом.
+- Прецедент детерминированной замены агента уже существует и работает (`deploy-finalizer`/
+  `post-deploy-monitor` в `launch_job` до `_spawn`) — это снижает архитектурный риск follow-up'ов.
+- На момент анализа конкретные follow-up work item для замены ролей в backlog **не подтверждены** —
+  поэтому ID не фиксируются (NFR-6).
+
+## 7. Критерии успеха
+Карта LLM-консультаций полна и привязана к коду, и **разводит транспорт/слот («процесс Claude CLI
+существует») от факта консультации («поток управления потребляет суждение LLM»)** (R4, §0); каждый
+site классифицирован с обоснованием; детерминизм не-агентских путей доказан (отсутствием LLM-консультации,
+не отсутствием subprocess); есть упорядоченный roadmap с зависимостями/экономией/рисками и
+рекомендованным первым срезом (кандидаты — по роли); есть нормативная политика; структурные тесты
+зелёные и осмысленные — инвариант единственной точки **транспорт-агностичен и двусторонен** (единственный
+транспорт `_spawn` **и** отсутствие иного LLM-транспорта); ни один рантайм-инвариант не тронут; раннеры
+замен НЕ реализованы; ни один артефакт не фиксирует непроверяемых follow-up ID. Детальные PASS/FAIL —
+в `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Недо-/пере-классификация** (LLM убран там, где нужно суждение, или сохранён там, где не нужен) →
+  митигирует требование «назвать конкретное суждение» для `keep-LLM` и ревью карты.
+- **Дрейф карты** относительно кода со временем → митигируют структурные тесты (BR-6).
+- **Преждевременная замена** в погоне за экономией ценой автономности/гибкости → инвентаризация
+  отделена от реализации; первый срез — самый низкорисковый.
+- **Фабрикация ссылок/ID** (рецидив дефекта R2) → митигирует NFR-6 (только проверяемые ссылки;
+  follow-up'ы — по роли) и ревью. Детали техн.рисков — `10-tech-risks.md` (архитектор).

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

@@ -0,0 +1,200 @@
+---
+work_item: ORCH-118
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-118 — replace avoidable LLM control paths with deterministic implementations
+
+Work Item: **ORCH-118** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **что** должно измениться и **где** (артефакты/контракты/тесты), выведено из BRD и
+> фактического кода. **Как** (точная структура/размещение документов карты, формат классификации,
+> схема структурных тестов) — решает архитектор в `06-adr/`. ТЗ фиксирует требования и границы.
+>
+> ⚠️ **Скоуп — inventory + классификация + roadmap + политика + структурные тесты.** Реализация
+> детерминированных раннеров — **вне скоупа** (FR-7). Это **docs + tests only**: `src/**`-рантайм не
+> меняется.
+>
+> 📌 **Follow-up'ы — по роли, без выдуманных Plane-ID** (R3, NFR-6). Конкретные ID (напр.
+> `ORCH-115`/`ORCH-116`) в артефактах **не фиксируются** — этих work item нет в репо/подтверждённом
+> backlog; ID присваивается при заведении задачи.
+>
+> 🔁 **R4 — единственный блокер R3-ревью.** Единица инвентаря/инварианта — **LLM-консультация**
+> (control-path потребляет суждение LLM), **не** «спавн процесса / существование Claude CLI». Claude
+> CLI-subprocess через `_spawn` — лишь **текущий транспорт**; «процесс существует» ≠ «LLM
+> консультирован» (capability ≠ consultation). Развёрнуто — BRD §0; затрагивает FR-1/FR-3/FR-6.
+
+---
+
+## 1. Сводка изменения
+
+Выпустить **доказательную карту** всех мест вызова LLM в оркестраторе с классификацией и
+упорядоченным roadmap'ом детерминированных замен, а также нормативную **политику использования LLM**;
+прибить инварианты карты к коду набором **структурных тестов**. Реализация замен не входит. Все
+рантайм-контракты (`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД) —
+**не меняются**.
+
+Опорный факт инвентаризации (ground-truth кода на момент задачи; line-привязки уточняет карта):
+
+> Единица — **LLM-консультация** (потребление суждения LLM), а не «спавн процесса» (R4, BRD §0).
+> Колонка ниже помечает, является ли site фактической консультацией или лишь *LLM-capable* транспортом/
+> слотом.
+
+| # | Call-site | Где | Что делает | Консультирует LLM? |
+|---|-----------|-----|------------|--------------------|
+| S0 | **Единственный транспорт LLM-консультации** | `src/agents/launcher.py::_spawn` (сборка `CLAUDE_BIN --print … --system-prompt "$(cat …)"` + `subprocess.Popen`) | реализует консультацию для любой из 6 ролей | транспорт (capability) |
+| A1 | analyst | промпт `.openclaw/agents/analyst.md`, стадия `analysis` | анализ бизнес-запроса → 01–04 | да (через S0) |
+| A2 | architect | `.openclaw/agents/architect.md`, стадия `architecture` | архитектурные решения → 06-adr | да (через S0) |
+| A3 | developer | `.openclaw/agents/developer.md`, стадия `development` | реализация + PR | да (через S0) |
+| A4 | reviewer | `.openclaw/agents/reviewer.md`, стадия `review` | ревью → `12-review.md` (`verdict:`) | да (через S0) |
+| A5 | tester | `.openclaw/agents/tester.md`, стадия `testing` | `pytest`+smoke → `13-test-report.md` (`result:`) | да (через S0) |
+| A6 | deployer | `.openclaw/agents/deployer.md`, стадии `deploy-staging`/`deploy` | `staging_check.py`/exit-code → `15`/`14` логи | да (через S0) |
+| D1 | deploy-finalizer | `launch_job` перехват **до** `_spawn` (`launcher.launch_job`) | детерминированный (LLM не консультируется) | **нет** (слот агента, перехват до `_spawn`) |
+| D2 | post-deploy-monitor | `launch_job` перехват **до** `_spawn` (`launcher.launch_job`) | детерминированный (LLM не консультируется) | **нет** (слот агента, перехват до `_spawn`) |
+
+> Не-агентские control-path'ы (маршрутизация `advance_stage`, `QG_CHECKS`/`check_*`/`_parse_*`,
+> `error_classifier`, `serial_gate`/`merge_gate`/`coverage_gate`/`security_gate`/`staging_verdict`/
+> `review_parse`/`frontmatter`, `self_deploy` Phase A/B/C) — **уже детерминированы** (FR-3).
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие |
+|------|----------|
+| `src/agents/launcher.py` | **читать** (инвентарь S0/D1/D2; `_spawn`, `launch_job`, `AGENT_CONFIGS`, `resolve_agent_model/effort`) — **не менять** |
+| `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md` | **читать** (инвентарь 6 ролей) — **не менять** |
+| `src/stages.py`, `src/stage_engine.py` | **читать** (доказать детерминизм маршрутизации) — **не менять** |
+| `src/qg/checks.py` | **читать** (`QG_CHECKS`/`check_*`/`_parse_*` — детерминизм) — **не менять** |
+| `src/{serial_gate,merge_gate,coverage_gate,security_gate,staging_verdict,review_parse,error_classifier,frontmatter,self_deploy,post_deploy,transition_lease,reconciler,job_reaper}.py` | **читать** (детерминированные leaf'ы — доказательная база) — **не менять** |
+| `src/usage.py`, `src/db.py` (`agent_runs`) | **читать** (источник оценок экономии токенов/времени) — **не менять** |
+| `docs/architecture/llm-call-sites.md` *(имя — пример; финально решает архитектор)* | **создать**: карта call-site'ов + классификация (FR-1/FR-2/FR-3) |
+| `docs/architecture/llm-determinization-roadmap.md` *(имя — пример)* | **создать**: упорядоченный roadmap (FR-4) |
+| `docs/architecture/llm-usage-policy.md` *(имя — пример)* | **создать**: нормативная политика (FR-5) |
+| `docs/work-items/ORCH-118/06-adr/ADR-001-*.md` | **создать** (архитектор): фиксация карты/таксономии/первого среза как ADR |
+| `tests/test_llm_call_site_inventory.py` *(имя — пример)* | **создать**: структурные анти-дрейф тесты (FR-6) |
+| `docs/architecture/README.md`, `docs/overview/*`, `CHANGELOG.md` | **обновить** (ссылка на карту/политику; норматив golden-source) |
+
+> Документы карты/политики целесообразно разместить в `docs/architecture/` (durable, сквозное), а не
+> только в `docs/work-items/ORCH-118/` — окончательное размещение/формат решает архитектор.
+
+## 3. Функциональные требования
+
+### FR-1 — Полнота и привязка инвентаря LLM-консультаций (BR-1)
+Единица — **LLM-консультация** (control-path потребляет суждение LLM), а не «спавн процесса» (R4, BRD
+§0). Карта перечисляет **каждый** call-site: `S0` (единственный транспорт `_spawn`), `A1…A6` (6 ролей,
+консультируют через S0), `D1/D2` (job-роли, **занимают слот агента, но НЕ консультируют LLM** —
+перехват в `launch_job` до `_spawn`; включены как доказательство паттерна). Поля записи: `id`,
+`location` (`file:line`), `trigger`, `stage/owner`, `output artifact`, `machine-verdict key` (если
+есть), `est. tokens/runtime`, **`consults-LLM` (consultation vs LLM-capable transport/slot, §0.3)**,
+`classification`, `rationale`, `dependency`, `risk`. Каждый `file:line` обязан резолвиться в реальный
+код. Инвариант (транспорт-агностичный, двусторонний): единственный транспорт LLM-консультации в
+`src/**` — `S0`; **иного LLM-транспорта нет** — подтверждается тестами FR-6(a)+(f). «Процесс Claude
+CLI существует» ≠ «вторая точка запуска LLM не появилась»: дыру закрывает именно (f), а не подсчёт
+`Popen`.
+
+### FR-2 — Таксономия классификации (BR-2)
+Ровно 4 взаимоисключающих класса с определениями:
+- `keep-LLM` — нужно настоящее суждение; **обязательно назвать** конкретное суждение.
+- `replace-deterministic-now` — безопасная детерминированная замена сейчас.
+- `replace-later/risky` — замена возможна, но позже / с риском (нужны предпосылки).
+- `needs-hybrid-fallback` — детерминированное ядро + LLM-фолбэк только на суждение.
+
+Каждому call-site присвоен **ровно один** класс. Ожидаемое (из инвентаризации; финальное решение
+фиксирует архитектор в ADR): `analyst/architect/developer/reviewer → keep-LLM`;
+`deployer → replace-deterministic-now` или `replace-later/risky` (staging = exit-code-маппинг; прод
+self-hosting уже детерминирован Phase A/B/C) — **кандидат-замена по роли deployer**;
+`tester → needs-hybrid-fallback` (детерминированный прогон `pytest`+smoke, LLM-суждение только на
+маппинг TC↔критерии / триаж падений) — **кандидат-замена по роли tester**;
+`deploy-finalizer/post-deploy-monitor → already-deterministic` (вне таксономии замен, как эталон).
+
+> 📌 **Follow-up'ы — по роли, без Plane-ID (R3, NFR-6).** Кандидаты обозначаются ролью
+> (deployer-замена, tester-гибрid), а не конкретными ID. Привязка к будущему work item делается при
+> заведении задачи; ORCH-118 ID не выдумывает.
+
+### FR-3 — Подтверждение детерминизма не-агентских путей (BR-3)
+Карта отдельным разделом фиксирует, с `file:line`-доказательством, что НЕ консультируют LLM (не зависят
+от суждения LLM ни через `_spawn`, ни иным транспортом): маршрутизация (`advance_stage`/
+`STAGE_TRANSITIONS`), все `QG_CHECKS`/`check_*`, парсеры вердиктов (`_parse_*` через
+`frontmatter.parse_frontmatter`), `error_classifier` (regex), под-гейты (security/merge/coverage/
+image-freshness), `self_deploy` Phase A/B/C, reconciler/reaper/serial-gate/transition-lease. ⚠️ Эти
+модули **спавнят subprocess'ы** (`git`/`pytest`/`docker`/`ssh`/сканеры) — это детерминированные
+инструменты, **не** LLM-консультации (§0): доказательство детерминизма — отсутствие *LLM*-транспорта,
+а не отсутствие *subprocess*. Любая найденная неожиданная LLM-консультация добавляется в инвентарь
+(FR-1) и классифицируется (FR-2).
+
+### FR-4 — Упорядоченный roadmap замен (BR-4)
+Ранжированный список кандидатов (названных **по роли**); для каждого: зависимости (предпосылки/блокеры),
+**оценка** экономии токенов/времени (из `agent_runs`), риск безопасности, нужен ли hybrid-fallback,
+ожидание kill-switch/обратимости, и **тип будущей follow-up задачи по роли** (без конкретного
+Plane-ID — заводится отдельно, NFR-6). Явно: **рекомендованный первый срез** + обоснование (самый
+низкорисковый, опирающийся на существующий прецедент D1/D2).
+
+### FR-5 — Политика использования LLM (BR-5)
+Нормативный durable-документ: принцип «LLM — только где нужно настоящее суждение»; критерии решения
+keep vs replace (детерминируемость выхода, наличие machine-verdict, обратимость, влияние на
+автономность); требование к новым/изменённым control-path'ам обосновывать любое использование LLM
+против политики. Может включать рекомендацию reviewer-оси (как ORCH-079) — **как требование, не как
+реализацию гейта** (новый QG не вводится, FR-6 §QG).
+
+### FR-6 — Структурные анти-дрейф тесты (BR-6)
+Новый offline-тест-файл (без сети/LLM/subprocess-к-модели), проверяющий инварианты карты. ⚠️ **R4 —
+инвариант формулируется вокруг LLM-консультации/транспорта, а не «существования процесса Claude CLI».**
+Дискриминатор тестов — **«консультирует LLM», а не «спавнит subprocess»**; десятки прочих subprocess
+(`git`/`pytest`/`docker`/`ssh`/сканеры/`staging_check.py`) явно исключаются из матчинга, иначе тест
+выродился бы в «подсчёт всех `Popen`».
+- **(a) Единственный транспорт.** В `src/**` ровно **одна** точка сборки/запуска Claude CLI (матчинг
+  по совокупности признаков LLM-транспорта: `CLAUDE_BIN` + `--system-prompt` + `Popen`/`bash -c`), и
+  это `launcher._spawn`. *(Необходимое, но не достаточное условие — дополняется (f).)*
+- **(f) Отсутствие иного LLM-транспорта (новое, R4).** В `src/**` **нет** альтернативного транспорта
+  LLM-консультации: ни импорта `anthropic`/`openai`/иного LLM-SDK, ни прямого HTTP-эндпоинта
+  Anthropic/Claude (`api.anthropic.com`, `/v1/messages` и т.п.), ни второго model-invoking
+  subprocess-сборщика (другой бинарь с `--system-prompt`/`--model`). Это закрывает дыру «один `_spawn`
+  зелёный, а рядом проросла новая консультация другим транспортом» — то, чего тест (a) в одиночку **не**
+  ловит. Allowlist единственного разрешённого транспорта = `S0`.
+- **(b) Нет консультации в детерминированных путях.** Перечисленные детерминированные модули и
+  обработчики `D1/D2` **не** консультируют LLM (не содержат ни `_spawn`-транспорта, ни альтернативного
+  по (f)); их subprocess-вызовы инструментов LLM-консультацией не считаются.
+- **(c)** Карта перечисляет ровно те промпт-файлы, что физически лежат в `.openclaw/agents/`
+  (двусторонняя сверка — нет дрейфа).
+- **(d)** Классификация покрывает каждый перечисленный call-site **ровно один раз** (тотальность,
+  без дублей/пропусков).
+- **(e) Capability ≠ consultation.** `D1/D2` действительно перехватываются в `launch_job` **до**
+  `_spawn` → занимают слот агента, но **консультации LLM не происходит** (эталон «процесс/слот есть —
+  суждение не потребляется», §0.3).
+
+> ❌ **Не вводить** тест, прибивающий карту к конкретным follow-up Plane-ID → ✅ тесты проверяют
+> только инварианты, резолвящиеся в код/файлы репозитория (R3, NFR-6). Привязка к несуществующим ID
+> была корнем отклонённой R2.
+
+### FR-7 — Скоуп-гард (BR-7)
+Раннеры замен **не реализуются** в ORCH-118. Карта/roadmap явно помечают кандидатов **по роли**
+(deployer-замена, tester-гибрid) как follow-up, старт которых гейтится утверждением карты. Тест/диф не
+должны содержать новых детерминированных раннеров tester/deployer. **Конкретные follow-up Plane-ID не
+фиксируются** ни в одном артефакте (NFR-6).
+
+## 4. Изменения API
+Нет. (Опциональная read-only наблюдаемость в `GET /queue`/`GET /metrics` — **вне скоупа** ORCH-118;
+если архитектор сочтёт полезным — отдельная аддитивная врезка, но не требуется этой задачей.)
+
+## 5. Изменения схемы БД
+Нет. (Источник оценок экономии — существующие колонки `agent_runs`: `model`/`effort`/токены/стоимость/
+время; только чтение.)
+
+## 6. Требования к новым/изменённым QG checks
+Нет. `QG_CHECKS` / `check_*` / `_parse_*` / machine-verdict-ключи — **байт-в-байт**. Структурные тесты
+FR-6 — обычные `pytest`-тесты, **не** Quality Gate и **не** стадия. Политика LLM (FR-5) — нормативный
+документ, а не машинный гейт.
+
+## 7. Совместимость / регресс
+- **Docs + tests only:** рантайм `src/**` не меняется → нулевая регрессия; enduro-trails не затронут;
+  kill-switch не нужен (нет рантайм-поведения), как в ORCH-077/079/101/102/103/011.
+- **Обратимость:** артефакты — документы и тесты; откат = удаление/правка docs (рантайм-риска нет).
+- **Анти-дрейф:** структурные тесты держат карту синхронной с кодом; норматив сопровождения — «менял
+  места вызова LLM → обнови карту и политику в том же PR» (фиксируется в политике и golden-source
+  docs).
+- **Анти-фабрикация (R3):** артефакты фиксируют только проверяемые ссылки; follow-up'ы — по роли,
+  без выдуманных Plane-ID (NFR-6).
+- **Self-hosting:** не деплоит/не рестартит прод/не трогает `main` — безопасно для общего инстанса.