Merge pull request 'fix(serial-gate): pause-without-blocking via per-task park signal (ORCH-124)' (#144) from feature/ORCH-124-bug-serial-gate-treats-backlog into main

Addresses reviewer REQUEST_CHANGES (run 768) on ORCH-124 — docs-only,
no src/tests touched, fix scope unchanged.

P1: update docs/overview/ showcase for the new serial-gate "pause without
blocking" axis (changed task-routing functionality, ORCH-011/ORCH-079):
- tech-pipeline.md: FIFO exception "pause without blocking" next to freeze
- tech-data-model.md: durable signal tasks.paused_at on the Task row
- tech-observability.md: paused/reason in serial_gate GET /queue block +
  operator endpoints POST /serial-gate/pause|resume

P2: strip leaked tool-call trailing tags (</content>/</invoke>) from 4
golden-source docs of this PR (06-adr/ADR-001, adr-0051,
08-data-requirements.md, 10-tech-risks.md).

CHANGELOG "Доки" bullet extended accordingly. Full suite green (2178 passed);
test_system_docs.py green (machine-checked showcase facts intact).

Refs: ORCH-124
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=
@@ -217,9 +230,15 @@ ORCH_TASK_DEPS_SOURCE=db
 #   SERIAL_GATE_ENABLED=false -> claim AND start_pipeline are 1:1 as before ORCH-088.
 #   SERIAL_GATE_REPOS (CSV) -> scope; EMPTY = ALL repos (not self-hosting-only).
 #   SERIAL_GATE_FREEZE_ENABLED=false -> the rollback-freeze layer is off (not set/read).
+#   SERIAL_GATE_PAUSE_ENABLED (ORCH-124) -> per-task "park" axis. true (default) -> a
+#     task with tasks.paused_at NOT NULL (POST /serial-gate/pause?work_item=<id>) is
+#     excluded from the "active task" predicate so an URGENT successor may overtake a
+#     paused predecessor. TRUE no-op until an operator pauses a task. false -> pause-term
+#     omitted, serial-gate byte-for-byte ORCH-088/090. Scope reuses SERIAL_GATE_REPOS.
 ORCH_SERIAL_GATE_ENABLED=true
 ORCH_SERIAL_GATE_REPOS=
 ORCH_SERIAL_GATE_FREEZE_ENABLED=true
+ORCH_SERIAL_GATE_PAUSE_ENABLED=true
 # ORCH-090: STOP-status task cancellation (stop active agent + full progress reset)
 # and the relaunch-hole close. A dedicated Plane "STOP" status (logical key `stop`,
 # fail-closed: absent from _DEFAULT_STATES, so a board without the status -> no-op)
@@ -434,6 +453,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
@@ -516,6 +563,62 @@ ORCH_COVERAGE_EPSILON=0.5
 ORCH_COVERAGE_TOOL_FAIL_CLOSED=false
 ORCH_COVERAGE_RUN_TIMEOUT_S=900
 
+# ORCH-115: deterministic staging-runner replacing the LLM `deployer` on the
+# `deploy-staging` stage (self-hosting orchestrator). Intercepted in launch_job
+# BEFORE _spawn (deploy-finalizer / post-deploy-monitor precedent): runs the same
+# staging suite, maps exit-code -> staging_status:, writes 15-staging-log.md and
+# initiates the UNCHANGED check_staging_status gate. Replaces only the producer of
+# the artifact; the gate / STAGE_TRANSITIONS / DB schema are byte-for-byte unchanged.
+# See ADR-001-deterministic-staging-runner.md / adr-0048.
+#   STAGING_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM deployer
+#                                        runs on deploy-staging via _spawn 1:1.
+#   STAGING_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only.
+#   STAGING_RUNNER_TIMEOUT_S          -> wall-clock budget for the docker-exec suite
+#                                        (malformed/non-positive -> default 600 + WARNING).
+#   STAGING_RUNNER_INFRA_MAX_RETRIES  -> transient-infra (timeout/ssh) bounded DEFER
+#                                        budget before an infra-HOLD (anti ORCH-110).
+#   STAGING_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued deployer job.
+#   STAGING_RUNNER_EXEC_HOST_SIDE     -> ORCH-123 (adr-0049): true (default = prod) wraps
+#                                        the `docker exec` in `ssh <user@host> '<...>'` so
+#                                        the suite runs HOST-SIDE (the prod container ships
+#                                        no docker CLI; incident ORCH-116). false -> the
+#                                        prior in-container `docker exec` (valid only where
+#                                        a docker CLI is baked into the image). Rollback knob.
+ORCH_STAGING_RUNNER_ENABLED=true
+ORCH_STAGING_RUNNER_REPOS=
+ORCH_STAGING_RUNNER_TIMEOUT_S=600
+ORCH_STAGING_RUNNER_INFRA_MAX_RETRIES=2
+ORCH_STAGING_RUNNER_INFRA_RETRY_DELAY_S=30
+ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true
+
+# ORCH-116: deterministic test-runner replacing the LLM `tester` agent on the
+# `testing` stage for the self-hosting orchestrator (2nd determinization slice,
+# mirror of the ORCH-115 staging-runner). A leaf src/test_runner.py is intercepted
+# in launch_job BEFORE _spawn: it runs the SAME regression `python -m pytest <target>`
+# in the task worktree (+ optional read-only smoke), maps the exit-code -> result:
+# PASS|FAIL, writes 13-test-report.md and initiates the UNCHANGED check_tests_passed
+# gate. Replaces only the producer of the artifact; the gate / STAGE_TRANSITIONS / DB
+# schema are byte-for-byte unchanged. See ADR-001-deterministic-test-runner.md / adr-0050.
+#   TEST_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM tester runs on
+#                                     testing via _spawn 1:1.
+#   TEST_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only. A repo with
+#                                     no resolvable test-contract is never intercepted (BR-9).
+#   TEST_RUNNER_TARGET            -> pytest target of the test-contract (default tests/).
+#   TEST_RUNNER_TIMEOUT_S          -> wall-clock budget for the pytest regression
+#                                     (malformed/non-positive -> default 900 + WARNING).
+#   TEST_RUNNER_SMOKE_ENABLED      -> optional read-only smoke (/health,/status,/queue +
+#                                     serial_gate block); false -> pytest exit-code is the sole signal.
+#   TEST_RUNNER_INFRA_MAX_RETRIES  -> tool-error (suite did NOT execute) bounded DEFER
+#                                     budget before a fail-closed FAIL (anti ORCH-110).
+#   TEST_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued tester job.
+ORCH_TEST_RUNNER_ENABLED=true
+ORCH_TEST_RUNNER_REPOS=
+ORCH_TEST_RUNNER_TARGET=tests/
+ORCH_TEST_RUNNER_TIMEOUT_S=900
+ORCH_TEST_RUNNER_SMOKE_ENABLED=true
+ORCH_TEST_RUNNER_INFRA_MAX_RETRIES=2
+ORCH_TEST_RUNNER_INFRA_RETRY_DELAY_S=30
+
 # ORCH-057 (follow-up ORCH-040): legacy root-owned ownership detect + actionable
 # worktree error. After the uid migration (user: "1000:1000") legacy root:root files
 # in /repos broke worktree creation under uid 1000 with a raw "Permission denied".

.openclaw/agents/deployer.md

@@ -45,6 +45,16 @@ then emit `staging_status:` / `deploy_status:`.
 
 Run the staging test suite against the live staging environment and write the verdict.
 
+> **ORCH-115 — deterministic runner leads this stage for in-scope repos.** On `deploy-staging` for
+> the self-hosting `orchestrator` repo, this stage is now driven by **deterministic code**
+> (`src/staging_runner.py`, intercepted in `launch_job` BEFORE `_spawn`, mirroring the prod Phase
+> A/B/C pattern) — it runs the SAME canonical staging suite below, maps the exit code to
+> `staging_status:` via the same `0 → SUCCESS / non-zero → FAILED` contract, writes
+> `15-staging-log.md`, and initiates the unchanged `check_staging_status` gate. The LLM steps below
+> remain the **fallback** under a disabled kill-switch (`ORCH_STAGING_RUNNER_ENABLED=false`) or for
+> non-self repos. The artifact contract / gate / machine key `staging_status:` are unchanged. Details:
+> `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`.
+
 **Steps:**
 
 1. Run the staging suite. **CANONICAL: run INSIDE the `orchestrator-staging` container via

.openclaw/agents/tester.md

@@ -29,6 +29,17 @@ tools:
 ТОЛЬКО потом выноси вердикт. Любой FAIL/смок-сбой → `result: FAIL`; всё зелёное → `result: PASS`.
 </thinking>
 
+> **ORCH-116 — детерминированный раннер ведёт эту стадию для in-scope репо.** На `testing` для
+> self-hosting `orchestrator` (репо с тест-контрактом) стадию теперь ведёт **детерминированный код**
+> (`src/test_runner.py`, перехват в `launch_job` **до** `_spawn`, как `deploy-finalizer`/
+> `staging-runner`) — он исполняет тот же регресс `pytest tests/` в worktree ветки + read-only smoke
+> (`/health`, `/status`, `/queue` + блок `serial_gate`), маппит exit-код в `result:` тем же
+> контрактом `0 → PASS / иначе → FAIL`, пишет `13-test-report.md` и инициирует неизменный гейт
+> `check_tests_passed`. LLM-шаги ниже остаются **fallback'ом** под выключенным kill-switch
+> (`ORCH_TEST_RUNNER_ENABLED=false`) или для репо без тест-контракта. Контракт артефакта / гейт /
+> machine-key `result:` — неизменны. Детали:
+> `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`.
+
 **Алгоритм:**
 1. **Окружение:** `curl -s http://localhost:8500/health`.
 2. **Тесты — в worktree ветки задачи, НЕ в общем `/repos/orchestrator`.** Прогоняй `pytest` из

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-112
+Work item: ORCH-124
 Repo: orchestrator
-Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
+Branch: feature/ORCH-124-bug-serial-gate-treats-backlog
 Stage: development

CHANGELOG.md

@@ -3,6 +3,47 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
+- **Serial-gate «пауза без блокировки» — явный per-task park-сигнал** (ORCH-124, `fix`): багфикс (метка `Bug`, эскалирован в full-cycle) инцидента **ORCH-116/ORCH-123**. `serial_gate` определял «активную задачу репо» **исключительно по машинной стадии** `tasks.stage NOT IN ('done','cancelled')`, а Plane-статусы Backlog/Blocked/Needs-Input (слой B индикации, ORCH-066) **не меняют `tasks.stage`** (слой A) ⇒ приостановленный предшественник был неотличим от активного и держал FIFO-гейт закрытым против срочного успешника (ORCH-116 поставлен на паузу, чтобы пропустить фикс ORCH-123 — фикс не стартовал, пока ORCH-116 формально не `done`). У оператора не было чистого механизма «пауза без блокировки», отдельного от cancel (терминал) и от глобального выключения гейта. **Инвариант:** правка **планировщика очереди** (claim) и наблюдаемости, **не** Quality Gate — `STAGE_TRANSITIONS` / состав `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) / схемы существующих таблиц — **байт-в-байт не тронуты**. Аддитивно, под независимым под-флагом, never-raise, restart-safe, fail-OPEN на hot-claim сохранён. ADR: `docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`, сквозной `docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md`.
+  - **Механизм (D1):** явный durable DB-сигнал «park» на уровне задачи, инициируемый оператором через API — **не** маппинг Plane-статуса (перегружал бы слой A/B ORCH-066 / анти-паттерн ORCH-059) и **не** `task_deps` (моделирует обратное направление «B ждёт A»). Чистое намерение, отличное от cancel и от kill-switch; DB-резолвимо, offline, webhook-независимо (потерянный webhook не рассинхронит сигнал).
+  - **Хранилище (D2):** аддитивная нуллабельная колонка `tasks.paused_at TEXT` через `_ensure_column` (паттерн `tasks.cancelled_at`/`cancel_requested_at`/`track`; `src/db.py`) — NULL = не на паузе; ISO-таймстамп = поставлена оператором на паузу. На уже-мигрированной БД — no-op; все существующие строки дефолтят в NULL ⇒ поведение до ORCH-124 до первой явной паузы (enduro не затронут на общей прод-БД). Хелперы `db.set_task_paused`/`clear_task_paused`/`is_task_paused` (never-raise; `is_task_paused` на ошибке → «не на паузе» = задача активна = гейт скорее закрыт = анти-stale-base-safe).
+  - **Ортогональная ось (D3, критично):** «активность» для serial-gate = `stage NOT IN ('done','cancelled') AND paused_at IS NULL`; **терминал `{done,cancelled}` остаётся байт-в-байт** в `serial_gate`/`task_deps`/`stages.py` (adr-0026 не регрессирует). `task_deps`/`stages.py` колонку `paused_at` **НЕ читают** ⇒ паузнутая объявленная зависимость (`job_deps`) и `repo_freeze` **по-прежнему блокируют** claim (пауза их **не** обходит — разные оси: freeze = весь репо, dependency = конкретная пара, пауза = «пропустите меня в FIFO»).
+  - **Три точки согласованно (D4, анти-дрейф):** один предикат «активна» под под-флагом — терм `AND t2.paused_at IS NULL` внутри существующего `EXISTS`-подзапроса `build_claim_clause` (горячий offline SQL, без лишнего JOIN), `AND paused_at IS NULL` в `repo_has_active_task` и в выборе `active_task` `_per_repo_snapshot` (`src/serial_gate.py`). Помечено маркером `ORCH-124` рядом с `ORCH-088`/`ORCH-090`.
+  - **Операторские эндпоинты (D7):** `POST /serial-gate/pause?work_item=<id>` (стамп `paused_at`; терминальная/неизвестная задача → no-op-ответ; под-флаг off → no-op-предупреждение) и `POST /serial-gate/resume?work_item=<id>` (сброс `paused_at` → задача снова участвует в гейте; идемпотентно) — по образцу `POST /serial-gate/unfreeze`, never-raise, с Telegram-подтверждением (`src/main.py`).
+  - **Анти-stale-base при resume (D8, R-1):** новой rebase-машинерии **нет** — свежесть базы гарантируют существующие механизмы: паузнутая-в-`analysis` задача при resume режет ветку отложенно (ORCH-088) от свежего `origin/main` с кодом успешника; материализованная — ребейзится на merge-gate (`auto_rebase_onto_main` под merge-lease ORCH-026/093) + re-test (ORCH-110). Нормальная задача (`paused_at IS NULL`) по-прежнему держит гейт ⇒ анти-stale-base для нормального случая (ORCH-088) **не регрессирует**.
+  - **Наблюдаемость (D5):** блок `serial_gate` в `GET /queue` дополнен ключом `paused` (список приостановленных незавершённых задач репо — НЕ показываются как `active_task`) и `reason` ожидания у каждого waiting-job с приоритетом `freeze` → `dependency` → `active-task` → `null`; существующие ключи снапшота (`active_task`/`waiting`/`frozen`/`frozen_reason`/`frozen_at`) — байт-в-байт (BC).
+  - **Условность/откат (D6):** независимый под-флаг `serial_gate_pause_enabled` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`, дефолт `True`; зеркало `serial_gate_freeze_enabled`; область переиспользует `serial_gate_repos`, новый `*_repos` не вводится). Дефолт `True` — **истинный no-op** до явной операторской паузы (`paused_at` всюду NULL). `False` ⇒ pause-терм опущен из SQL, эндпоинты no-op, serial-gate **байт-в-байт ORCH-088/090** (осознанный rollback-режим). Глубже — `serial_gate_enabled=false`.
+  - **Покрытие:** `tests/test_orch124_serial_gate_pause.py` (TC-01 обязательный регресс инцидента ORCH-116/ORCH-123 — красный до фикса, зелёный после; TC-02…TC-15: анти-регресс ORCH-088, durable/restart, resume, сохранность freeze/dependency, снапшот-reason, анти-дрейф 3 точек, offline hot-path, never-raise/fail-OPEN, kill-switch-нейтральность, структурный анти-регресс реестров/схем).
+  - **Доки:** обновлены `docs/architecture/README.md` (раздел serial-gate + ось «пауза без блокировки») и `docs/architecture/internals.md` (ось «пауза» ⊥ оси «терминальность»); сквозной ADR `adr-0051`. **Витрина системы `docs/overview/` (ORCH-011, синхронно в том же PR):** `tech-pipeline.md` (исключение FIFO «пауза без блокировки» рядом с freeze), `tech-data-model.md` (durable-сигнал `tasks.paused_at`), `tech-observability.md` (`paused`/`reason` в блоке `serial_gate` `GET /queue` + эндпоинты `pause|resume`). Зачищены протёкшие хвостовые теги tool-call (`</content>`/`</invoke>`) в 4 golden-source доках этого PR (`06-adr/ADR-001`, `adr-0051`, `08-data-requirements.md`, `10-tech-risks.md`).
+  - **Тест-гигиена (development-стадия, латентный регресс ORCH-123):** изолирован `settings.repos_dir` в фикстуре `tests/test_orch123_staging_runner_exec.py` (зеркально уже имевшейся изоляции `worktrees_dir`). `check_staging_status` при отсутствии фиче-worktree фолбэчит на `<repos_dir>/<repo>` (и его `origin/main`); после мержа ORCH-123 реальный `/repos/orchestrator/docs/work-items/ORCH-123/15-staging-log.md` (вердикт SUCCESS) появился на диске и делал предполагавшийся-КРАСНЫМ staging-гейт в `test_r2_held_deploy_staging_not_rolled_back` зелёным при полном прогоне `pytest tests/` (order-dependent: тест проходил в одиночку, падал в сьюте). Инвариант ORCH-123 R-2 («held `deploy-staging` не откатывается на `development`», adr-0049/ADR-001 D4) **сохранён и усилен** — изоляция лишь восстанавливает заявленную предпосылку теста «15-staging-log.md отсутствует ⇒ гейт красный». `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*` не тронуты (правка только теста).
+- **Детерминированный test-раннер вместо LLM-тестера на `testing`** (ORCH-116, `feat`): второй реализованный срез determinization-roadmap (ORCH-118 A5, `needs-hybrid-fallback`) — на стадии `testing` для self-hosting `orchestrator` **LLM-агент `tester` заменён детерминированным кодом** (`src/test_runner.py`). PASS/FAIL-ядро агента было деривируемым (регресс `pytest` + read-only smoke → `result:`); каждый прогон жёг токены/время opus-агента (~60–150k / 5–20 мин) и встраивал недетерминизм LLM в точку ветвления `testing → deploy-staging` / `testing → development`. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `13-test-report.md`, гейт `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`, machine-verdict `result:` (+ legacy `verdict:`/`status:`), схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting, гибрид (LLM строго off-control-path). Эталон — `src/staging_runner.py` (ORCH-115). ADR: `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`, сквозной `docs/architecture/adr/adr-0050-deterministic-test-runner.md`.
+  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="tester" and test_runner.should_intercept(job)` → `_run_test_runner_job` (зеркало `_run_staging_runner_job`, прецедент `deploy-finalizer`/`post-deploy-monitor`/`staging-runner` `launcher.py:397/402/405`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`, нет токенов). Дискриминатор — роль `tester` **И** стадия задачи `testing` (defense-in-depth: `tester` — единственный агент входа в `testing`, коллизии стадий нет, в отличие от общей роли `deployer`) **И** `applies(repo)`; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути).
+  - **Leaf `src/test_runner.py` (новый, чистый never-raise):** по образцу `staging_runner`/`self_deploy`/`proc_group` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications` — лениво). `applies(repo)` = kill-switch `test_runner_enabled` + скоуп `test_runner_repos` (пусто → self-hosting only) **И** резолв тест-контракта `_has_test_contract` (BR-9: репо без контракта → `False` → LLM-tester — enduro-trails 1:1 как до ORCH-116, даже если руками добавлен в CSV). Исполняет регресс `python -m pytest <test_runner_target>` **в worktree ветки** (`git_worktree.get_worktree_path`, анти checkout-гонка ORCH-112) через `proc_group.run_in_process_group` (tree-kill, таймаут `test_runner_timeout_s=900`, малформ/непозитив → дефолт + WARNING) + опц. **read-only smoke** (`/health`/`/status`/`/queue` + блок `serial_gate`, stdlib `urllib`; транзиентная недостижимость — ограниченный ретрай, не-200/нет блока — немедленный FAIL; `test_runner_smoke_enabled`). Маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе/None→`FAIL`, fail-closed; smoke-провал AND-ится в `FAIL`); пишет `13-test-report.md` (тот же machine-key `result:` UPPERCASE + 52c-схема, `author_agent: test-runner`/`model_used: n/a`) + best-effort push в **фичеветку**; вызывает **существующий** `advance_stage(current_stage="testing", finished_agent="tester")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage` — граница O1).
+  - **Анти-коллизия 52c-`status:` ↔ парсер (D6.1, специфично для tester):** `_parse_tests_verdict` читает вердикт из **трёх** равноранговых полей (`verdict:`/`status:`/`result:`) с negative-token-priority. 52c-обязательное `status:` поэтому читается тем же парсером → раннер **ВСЕГДА выравнивает** `status:` по вердикту (`PASS → status: success`, `FAIL → status: failed`) — иначе негативный токен в `status:` при `result: PASS` дал бы ложный FAIL здорового прогона. Прибито unit-тестом через **неизменённый** парсер.
+  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAIL → тот же откат `testing → development` + developer-retry, что у FAIL-вердикта LLM, `stage_engine.py:849`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue **`tester`**-джоба с задержкой + restart-safe маркер `test-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `test_runner_infra_max_retries=2` → fail-closed `FAIL` + advance + INFRA-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь, **не** жжёт developer-retry на транзиентной инфре.
+  - **Гибрид (D11/BR-8/NFR-7):** в Phase 1 на `testing` (in-scope) вердикт `result:` производит **только** детерминированный раннер; LLM **не** вызывается в потоке управления вердикта. Архитектура не запрещает будущий **off-control-path** LLM-триаж падений / маппинг TC↔критерии после детерминированного FAIL (отдельная роль/джоб, **не** выносит и **не** переопределяет `result:`, **не** добавляет ребро в `STAGE_TRANSITIONS`) — в этом срезе не реализуется. Self-hosting safety: в командах раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push / правок `.env`; smoke строго read-only. Наблюдаемость — in-process счётчики (`runs`/`pass`/`fail`/`tool_error`/`deferred`) + read-only блок `test_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `test_runner_enabled`/`test_runner_repos`/`test_runner_target`/`test_runner_timeout_s`/`test_runner_smoke_enabled`/`test_runner_infra_max_retries`/`test_runner_infra_retry_delay_s` (env `ORCH_TEST_RUNNER_*`). Откат = `ORCH_TEST_RUNNER_ENABLED=false` → на `testing` снова LLM-`tester` через `_spawn` **байт-в-байт**.
+  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A5 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет tester как `avoidable=yes`/`axis=C`/`needs-hybrid-fallback`), `llm-determinization-roadmap.md` (rank 2 tester — ✅ реализован; инвариант «ровно один `first_slice = yes`» у rank 1 deployer цел), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/tester.md` (LLM-ветвь `testing` — fallback), `docs/architecture/README.md`/`internals.md`, витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`/`tech-quality-security.md`. Покрытие — `tests/test_orch116_test_runner.py` (TC-01…TC-14) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-15).
+- **Host-side исполнение staging-раннера + классификация environment-дефекта** (ORCH-123, `fix`, bug→escalate full-cycle): устранён инцидент **ORCH-116** — детерминированный staging-раннер (ORCH-115) вызывал `docker exec` **изнутри** прод-контейнера `orchestrator`, где **нет бинаря `docker`** (образ несёт только `openssh-client git curl`, `Dockerfile:11`; `/var/run/docker.sock` смонтирован, но клиента нет) → `Popen(["docker", …])` падал `FileNotFoundError` → ветка tool-error → инфра-DEFER×2 → fail-closed `FAILED` → **ложный** откат `deploy-staging → development` (как код-фейл, с расходом developer-retry). Так до фикса **любая** self-hosting задача, дойдя до `deploy-staging`, была обречена на ложный откат. Аддитивно, под флагами, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_staging_status`/`_parse_staging_status` / machine-verdict-ключи (`staging_status:`/`deploy_status:`) / схема БД — **байт-в-байт не тронуты** (замена *стратегии исполнения продюсера* `15-staging-log.md`, **не** гейта/стадии; зеркало инварианта ORCH-115 NFR-1). ADR: `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`, сквозной `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`.
+  - **Host-side ssh-стратегия (D1):** `staging_runner.build_staging_command()` теперь обёртывает ту же `docker exec orchestrator-staging python3 … staging_check.py … --mode stub` в `ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> '<docker exec …>'` (зеркало `self_deploy.build_deploy_command` / `image_freshness.image_revision(ssh_target=…)`); канал — существующий доверенный (`ORCH_DEPLOY_SSH_HOST=127.0.0.1`, ssh-ключ смонтирован `:ro`, `openssh-client` в образе) → **новых секретов/привилегий не вводится** (NFR-3). Меняется **инициатор/канал** запуска, **не** сама сюита (она по-прежнему бежит **внутри** `orchestrator-staging` 8501). **Security (D2):** docker CLI/SDK в контейнер **не добавляется**, `docker.sock` **не используется изнутри** — это было бы root-эквивалентным расширением поверхности атаки (доступным и LLM-агентам); host-side ssh достигает цели без расширения привилегий.
+  - **Трёхсторонняя классификация исхода (D3, чистая `classify_staging_outcome`, зеркало `merge_gate.classify_retest_failure`):** `suite-ran` (распознанный exit-код, кроме 255, **без** env-маркера в stderr → доверяем коду: `0→SUCCESS`/`≠0→FAILED`; анти-over-tolerance BR-3 — реальный фейл сюиты **никогда** не реклассифицируется в инфру), `permanent-env` (spawn-error `rc=None` без таймаута / нет ssh-target / `rc∈{126,127}` / env-маркер `No such container`/`Cannot connect to the Docker daemon`/`command not found` → ретрай бессмыслен), `transient-infra` (timeout / ssh transport `rc=255` / неизвестный сигнал → ретрай осмыслен). Дизамбигуация коллизии `exit=1` (`docker exec` «No such container»=1 vs суита fail=1) — **скан stderr на env-маркеры**, не голый exit-код; fail-safe при неоднозначности → `transient-infra` (DEFER), никогда тихий `suite-ran`.
+  - **Маршрутизация исходов (D4) — инвариант «инфра ≠ код-фейл»:** `suite-ran` → **без изменений** (ORCH-115): write `15-staging-log.md` + `advance_stage` (FAILED → прежний откат `deploy-staging → development` + developer-retry, байт-в-байт). `permanent-env` → **немедленный infra-HOLD**: DEFER пропускается (FR-3), `15-staging-log.md` **не** пишется (нет ложного FAILED), `advance` **не** зовётся, developer-retry **не** жжётся; структурный ERROR + операторский alert «инфра/окружение, НЕ дефект кода». `transient-infra` → существующий bounded DEFER, **но на исчерпании бюджета** — тоже **infra-HOLD + alert** (СУПЕРСЕД ORCH-115 D5: прежний fail-closed `write_staging_log("FAILED") + advance` ложно откатывал не-прояснившуюся инфру как код-фейл, нарушая BR-2). Корневой инвариант: «сюита **не** исполнилась» (environment ИЛИ инфра) **никогда** не оканчивается код-фейл-откатом `→ development` и **никогда** не жжёт developer-retry — закрывает RCA-класс ORCH-110 на staging-ребре. Задача **держится** на `deploy-staging`; reconciler `advance_if_gate_passed` на red-гейте возвращает `None` (без отката, R-2 верифицирован) → оператор re-drive после починки окружения.
+  - **Prod-like preflight (D5):** `staging_runner.preflight()` (bounded, never-raise, self-hosting-скоуп — `applies()` первым) пробит host-side канал на **старте сервиса** в `main.lifespan` (best-effort, после `requeue_running_jobs`/`recover_on_startup`, **никогда не блокирует старт**): ssh-зонд `command -v docker && docker inspect -f '{{.State.Running}}' orchestrator-staging` распознаёт «нет docker на хосте» / «staging-контейнер не поднят» / «ssh недоступен» / «нет ssh-target» **до** того, как реальная задача дойдёт до ложного исхода. Чисто наблюдательный — не гейтит конвейер; лог + Telegram-алерт + поле в `snapshot()`.
+  - **Условность / обратимость (D6):** новый флаг `staging_runner_exec_host_side: bool = True` (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`, дефолт = боевое) — `True` → host-side ssh; `False` → прежний in-container `docker exec` (валиден лишь там, где docker CLI запечён в образ). Переиспользуются `staging_runner_enabled`/`_repos`/`_timeout_s`/`_infra_max_retries`/`_retry_delay_s` + `deploy_ssh_user`/`deploy_ssh_host`. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (in-container 1:1) или `ORCH_STAGING_RUNNER_ENABLED=false` (LLM-deployer 1:1). Наблюдаемость (D8): счётчик `permanent_env` (infra-HOLD; отличён от `failed`=код-фейл и `deferred`=транзиент) + `exec_host_side` + `preflight` в блоке `staging_runner` `GET /queue`; один структурный лог-вердикт на прогон (`outcome ∈ {code-pass,code-fail,transient-infra,permanent-env}`).
+  - **Документация границы исполнения (D9):** `docs/operations/INFRA.md` (новый под-раздел «Граница исполнения docker-операций — host-side») + `docs/architecture/README.md` (host-side стратегия + трёхсторонняя классификация) — зафиксировано, что **все** docker-операции self-hosting (прод-деплой ORCH-036, image-freshness ORCH-058, staging-runner ORCH-123) исполняются host-side через ssh, docker CLI в контейнере нет, `docker.sock` сознательно не используется изнутри. Покрытие — `tests/test_orch123_staging_runner_exec.py` (TC-01 — обязательный регресс ORCH-116: КРАСНЫЙ до фикса / ЗЕЛЁНЫЙ после; TC-02…TC-14 + регресс R-2 «held не становится rollback») + зелёный анти-дрейф `tests/test_orch115_staging_runner.py` (TC-14: инварианты ORCH-115 целы; 3 теста обновлены под суперсед D4/D8/D1).
+- **Детерминированный staging-раннер вместо LLM-деплойера на `deploy-staging`** (ORCH-115, `feat`): первый реализованный срез determinization-roadmap (ORCH-118 A6, `replace-deterministic-now`) — на стадии `deploy-staging` для self-hosting `orchestrator` **LLM-агент `deployer` заменён детерминированным кодом** (`src/staging_runner.py`). Работа агента на этой стадии была чисто механической (запуск staging-сюиты + маппинг exit-кода `staging_check.py` → `staging_status:`); каждый прогон жёг токены/время opus-агента (~40–120k / 3–15 мин) и встраивал недетерминизм LLM в точку ветвления гейта. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `15-staging-log.md`, гейт `check_staging_status`/`_parse_staging_status`, `STAGE_TRANSITIONS`, machine-verdict `staging_status:`, схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting. ADR: `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`, сквозной `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`.
+  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="deployer" and staging_runner.should_intercept(job)` → `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`, прецедент `deploy-finalizer`/`post-deploy-monitor` `launcher.py:389/394`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`-строки, нет токенов). Дискриминатор «staging vs prod» — **стадия задачи** `deploy-staging` (роль `deployer` общая для `deploy-staging`/`deploy`), не имя роли; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути). Для не-self репо `applies==False` → прод-`deployer` никогда не перехватывается.
+  - **Leaf `src/staging_runner.py` (новый, чистый never-raise):** по образцу `self_deploy`/`proc_group`/`staging_verdict` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/`qg.checks`/`notifications` — лениво). Исполняет ту же сюиту (`docker exec orchestrator-staging python3 <repos_dir>/<self-repo>/scripts/staging_check.py --base-url http://localhost:<staging_port> --mode stub`, арги из config — ORCH-101, без host-хардкодов) через `proc_group.run_in_process_group` (tree-kill, таймаут `staging_runner_timeout_s=600`, малформ/непозитив → дефолт + WARNING); маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` (`0→SUCCESS`/иначе/None→`FAILED`, fail-closed; ORCH-061 infra-tolerance остаётся внутри `staging_check.py`, раннер не пересуживает — BR-4); пишет `15-staging-log.md` (тот же machine-key `staging_status:` UPPERCASE + 52c-схема, `author_agent: staging-runner`/`model_used: n/a`) + best-effort commit/push в **фичеветку** (не в `main` — гейт читает worktree первым, усиливает AC-8/BR-7); вызывает **существующий** `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage`, раннер не трогает — граница O1).
+  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAILED → тот же откат `deploy-staging → development` + developer-retry, что у FAILED-вердикта LLM, `stage_engine.py:932`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue `deployer`-джоба с задержкой + restart-safe маркер `staging-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `staging_runner_infra_max_retries=2` → fail-closed `FAILED` + advance + инфра-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь и **не** жжёт developer-retry на транзиентной инфре.
+  - **Self-hosting safety (BR-7/AC-8):** в командной строке раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push в `main` / правок `.env` — раннер только читает/исполняет staging-сюиту (8501) и пишет лог. Наблюдаемость (D10) — in-process счётчики (`runs`/`success`/`failed`/`tool_error`/`deferred`) + read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `staging_runner_enabled` (env `ORCH_STAGING_RUNNER_ENABLED`), `staging_runner_repos` (CSV; пусто → self-hosting only), `staging_runner_timeout_s`, `staging_runner_infra_max_retries`, `staging_runner_infra_retry_delay_s`. Откат = `ORCH_STAGING_RUNNER_ENABLED=false` → на `deploy-staging` снова LLM-`deployer` через `_spawn` **байт-в-байт**.
+  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A6 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет deployer как `avoidable=yes`/`axis=C` — LLM-ветвь жива как fallback), `llm-determinization-roadmap.md` (rank 1 deployer — ✅ реализован; машинный блок/инвариант «ровно один `first_slice = yes`» целы), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/deployer.md` (LLM-ветвь `deploy-staging` — fallback), витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`. Покрытие — `tests/test_orch115_staging_runner.py` (TC-01…TC-13) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-14).
+- **Карта LLM-консультаций + control-path-ось «avoidable» + roadmap + нормативная политика** (ORCH-118, `docs`+`test`, inventory-first, docs+tests only): зонтичный follow-up RCA-трека ORCH-114/117 — у оркестратора не было ни нормативного критерия «где LLM нужен, а где это avoidable control path», ни карты мест вызова LLM, прибитой к коду. Выпущена **доказательная карта** каждого места, где control-path потребляет (или способен потребить) суждение LLM, с control-path-разметкой и классификацией; **упорядоченный roadmap** детерминированных замен; **нормативная политика** использования LLM; набор **структурных анти-дрейф тестов**. Это **docs + tests only**: `src/**`-рантайм не меняется → `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен **не** реализуются (FR-7); конкретные follow-up Plane-ID **не** фиксируются (R3/NFR-6 — кандидаты по роли). kill-switch не нужен (нет рантайм-поведения), как ORCH-077/079/101/102/103/011. ADR: `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`, сквозной `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`.
+  - **Единица инвентаря — LLM-консультация** (control-path потребляет суждение LLM), а **не** «спавн процесса / существование Claude CLI» (R4, capability ≠ consultation). Карта разводит **три ортогональных факта**: (1) consultation ≠ transport/slot (единственный транспорт LLM-консультации в `src/**` — `launcher._spawn`, `launcher.py:472`/CLI-сборка `610-614`; иного транспорта нет; job-роли `deploy-finalizer`/`post-deploy-monitor` занимают слот, но перехватываются в `launch_job` **до** `_spawn`, `launcher.py:389/394` — консультации нет); (2) **control-path (C) ≠ artifact-producer (P)** по коду-потребителю в `src/qg/checks.py` (C: гейт ветвится на LLM-вердикте; P: детерминированный гейт судит артефакт независимо — файлы/CI); (3) деривируемость вердикта из tool-сигналов.
+  - **Нормативное определение** «avoidable LLM control path» = двухбитный предикат (C-консультация **И** вердикт деривируем из exit-кодов `pytest`/smoke/`staging_check.py`/деплоя). Поимённый целевой набор (доказательно, прибит тестами): **avoidable = `{tester, deployer}`**; control-path-но-keep = `{reviewer}` (вердикт «приемлемость кода/решения» НЕ деривируем); не-control-path (P, keep) = `{analyst, architect, developer}`; уже детерминированы (эталон) = `{deploy-finalizer, post-deploy-monitor}`.
+  - **Документы (durable, `docs/architecture/`):** `llm-call-sites.md` (карта + машинно-читаемый блок инвентаря + control-path-разметка + классификация, снимок), `llm-determinization-roadmap.md` (порядок замен; рекомендованный первый срез — **deployer staging-status**, чистый маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C ORCH-036), `llm-usage-policy.md` (нормативный принцип + критерии keep/replace через ось + определение «avoidable»). Витрина `docs/overview/tech-quality-security.md` и `docs/architecture/README.md` ссылаются на карту и политику.
+  - **Анти-дрейф тесты (offline, без сети/LLM/subprocess-к-модели):** `tests/test_llm_call_site_inventory.py` (TC-01 единственный транспорт = `_spawn`; TC-12 отсутствие иного LLM-транспорта; TC-02 детерминированные модули без консультации; TC-03 промпты↔файлы; TC-04 тотальность+согласованность класса с осью; TC-05 keep-LLM именует суждение; TC-06 capability≠consultation; TC-09 снимок рантайм-контрактов; **TC-13** control-path-разметка сверена с потребителем в `src/qg/checks.py`; **TC-14** avoidable-набор = `{tester, deployer}`) и `tests/test_llm_determinization_docs.py` (TC-07 полнота roadmap+первый срез; TC-08 политика нормативна+определяет термин; TC-11 анти-фабрикация follow-up ID). Дискриминатор всех проверок — **«консультирует LLM», а не «спавнит subprocess»**. Норматив сопровождения: менял место вызова LLM или потребителя вердикта в `src/qg/checks.py` → обнови карту/разметку и политику в том же PR.
+- **Sandbox-only fail-closed изоляция записи в Plane из тест-процесса** (ORCH-117, `fix`, bug→escalate full-cycle): закрыт корневой класс инцидента **ORCH-114** — тест/worktree-процесс выполнил РЕАЛЬНУЮ запись (`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого** Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** — подмена env/токена постфактум бесполезна, NFR-4), и **ничто** не принуждало их писать только в sandbox. Симметрия прецеденту `tests/conftest.py::_no_telegram` (autouse-глушилка Telegram «pytest на проде слал реальные сообщения») — для Plane-**записи** такой защиты не было. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента Plane, **не** Quality Gate и **не** стадия). Новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op, work_item) -> (ALLOW|BLOCK, reason)`, по образцу `deploy_status_guard`/`serial_gate`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и **до** любого сетевого шага (ни GET, ни PATCH/POST). Гард активен **только в тест-процессе** (детект `"pytest" in sys.modules` / `PYTEST_CURRENT_TEST`); боевой и staging рантаймы (`uvicorn src.main:app`, без pytest в процессе) — строгий **no-op** (NFR-2/NFR-3). В тест-процессе запись разрешена **только** при одновременном (а) opt-in `plane_test_write_enabled=True` **и** (б) целевом проекте ∈ sandbox-allowlist `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-…`); иначе — default-deny; нерезолвимый проект → блок (fail-closed, NFR-1); боевой проект запрещён **даже при opt-in** (allowlist sandbox-only). Второй независимый sandbox-bound слой — autouse-floor `tests/conftest.py::_plane_sandbox_only` (opt-in OFF для всего сьюта, по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит opt-in в своей фикстуре поверх floor. **Умышленно БЕЗ kill-switch прод-блока** (NFR-6/FR-7/anti-drift): выключателя, переоткрывающего прод-запись из pytest, нет — единственный реверс — sandbox-bound opt-in. Аудит: блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason` — делает инцидент класса ORCH-114 очевидным), разрешённая sandbox-запись → INFO. Новые ключи `ORCH_PLANE_TEST_WRITE_ENABLED` (дефолт `false`) / `ORCH_PLANE_TEST_SANDBOX_PROJECTS` (дефолт = SANDBOX id) с безопасными дефолтами; `scripts/staging_check.py` Block C (E2E в SANDBOX) — отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие — `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до врезки, зелёный после; TC-02…TC-14). ADR: `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`, сквозной `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`.
+- **Ownership-lease для side-effectful переходов стадий + умное восстановление при старте** (ORCH-114, `fix`, bug→escalate full-cycle): закрыт **корневой класс** инцидент-цепочки ORCH-110/111/112/113 — у side-effectful переходов стадий не было единого владения. `advance_stage` ре-ентерабельна и пишет стадию «голым» `UPDATE … WHERE id=?` (без compare-and-swap), а ≥5 акторов (монитор / Plane-webhook / reconciler F-1 / job-reaper / deploy-finalizer) входят в один переход независимо → конкурентный или после-рестартовый повторный вход **дважды** применял необратимые эффекты (merge_pr / coverage-ratchet / image-rebuild / инициация прод-деплоя) и давал **противоречие rollback↔done** (инцидент ORCH-111, job 1914 / PR #130). Два комплементарных слоя, оба аддитивные, под единым kill-switch, never-raise: **(1) durable transition-lease** (новая таблица `transition_lease`) — владение на ВХОДЕ в side-effectful регион (второй актор, увидев живого владельца, не стартует тяжёлые под-гейты вовсе — предотвращение, не починка постфактум); **(2) expected-stage CAS** (`update_task_stage_cas`) — на ЗАПИСИ стадии (проигравший гонку — аборт без побочных эффектов), что закрывает и **6 путей записи стадии в обход `advance_stage`** (gitea×5 + plane rollback). Liveness владельца = `owner_pid` + `owner_boot_id` (НЕ heartbeat: блокирующий 900s merge re-test не может бить heartbeat — довод самого ORCH-113), что делает рестарт-recovery бесплатным (новый процесс → новый boot-id → все прежние lease мгновенно устаревшие → реклеймятся). Lease без собственного TTL: его потолок возраста = Tier-3 backstop `reaper_max_running_s` (5400) → сквозной бюджет ORCH-065/109/110/113 не тронут. `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / **схемы существующих таблиц** — байт-в-байт (одна аддитивная таблица, без epoch-колонки на `tasks`). Скоуп self-hosting (`transition_lease_repos=""` → только `orchestrator`; enduro не затронут); kill-switch `ORCH_TRANSITION_LEASE_ENABLED=false` → CAS вырождается в прежний безусловный `update_task_stage`, lease инертен → поведение байт-в-байт до ORCH-114. ADR: `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`, сквозной `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`.
+  - **Leaf `src/transition_lease.py` (новый, чистый never-raise):** по образцу `serial_gate`/`coverage_gate`/`finalizer_liveness` (импортирует только `db`+`config`, лениво `merge_gate.pid_alive`/`qg.checks`/`notifications`; НЕ импортирует `stage_engine`/`launcher`) — `applies(repo)` / `acquire(task_id, owner, run_id, stage)` (атомарный rowcount-guard `INSERT … ON CONFLICT DO NOTHING` после очистки stale-строки) / `is_held_by_live_owner(task_id)` (fail-closed → defer на сомнении) / `release(task_id, force=False)` (holder-aware по boot) / `reclaim_if_stale` / `recover_on_startup` / `commit_stage_cas(task_id, expected, new, repo)` (flag-off → unconditional `update_task_stage`; flag-on → CAS) / `snapshot()`.
+  - **Интеграция:** `advance_stage` захватывает lease на входе в side-effectful ребро (`deploy-staging`/`deploy`), пишет стадию через CAS, освобождает lease в `try/finally` (на любом исходе, включая исключение/откат); **rollback-записи side-effectful под-гейтов** (`_handle_merge_gate_rollback`/`_handle_security_gate`/`_handle_coverage_gate`/`_handle_image_freshness`) пишут `development` через тот же CAS (общий хелпер `_rollback_stage_cas`, ADR-001 D4: защита rollback↔done — под держимым lease это единственный владелец, проигранный CAS → аборт без side-effects, не слепой перетир `done`); job-reaper `_finalizer_owns` обобщён с процесс-локального ORCH-113 (Tier-2/`deploy-staging`) на **durable cross-path** lease (defer при живом владельце; Tier-3 backstop игнорирует маркер → bounded reclaim; реап force-освобождает lease); reconciler F-1 и Plane-webhook (`_try_advance_stage`) делают **defer** при активном lease; `main.lifespan` зовёт `recover_on_startup()` после `requeue_running_jobs`. Наблюдаемость — read-only блок `transition_lease` в `GET /queue` + Telegram-алерт на форсированный/устаревший реклейм + опциональный `POST /transition-lease/release?work_item=<id>`. Покрытие — `tests/test_orch114_transition_ownership.py` (TC-01 обязательный регресс класса ORCH-111: красный до фикса, зелёный после; TC-02…TC-14 + регресс CAS на in-region rollback). Флаги (`config.py`, дефолт = боевое): `transition_lease_enabled` (env `ORCH_TRANSITION_LEASE_ENABLED`), `transition_lease_repos` (env `ORCH_TRANSITION_LEASE_REPOS`).
 - **Гигиена shared deploy-базы: устойчивый self-deploy `git pull` к грязному дереву** (ORCH-112, `fix`, bug→escalate full-cycle): устранён инцидент ORCH-111 — self-deploy падал на шаге `git pull origin main` хост-хука с `error: Your local changes to the following files would be overwritten by merge: src/config.py` (грязь от неуспешной/отменённой/брошенной задачи ORCH-104 в общем main checkout) → деплой вставал → ручное вмешательство (на self-hosting — групповой риск). Решение — **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`): перед `git pull` хук при обнаружении грязи приводит deploy-базу к чистому актуальному `origin/main` (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Аддитивно, под kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты** (это устойчивость deploy-пути, **не** Quality Gate и **не** стадия). ADR: `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
   - **Leaf `src/checkout_hygiene.py` (новый, чистый never-raise):** по образцу `serial_gate`/`cancel`/`self_deploy` (импортирует только `config`, лениво `self_deploy`/`qg.checks`/`notifications`) — `applies(repo)` (kill-switch `checkout_hygiene_enabled` + скоуп `checkout_hygiene_repos`, пусто → self-hosting only, локально и ПЕРВЫМ), `hook_env(repo, work_item_id)` (env-префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`, инжектится в detached-команду хука только при `applies==True`, иначе `""` → голый pull 1:1), `read_report`/`alert_dirty` (наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
   - **Хук-блок «2a. Resilient pull» (`scripts/orchestrator-deploy-hook.sh`):** между шагом «1. Capture PREV_IMG» и «2. Pull», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`. **Сохранность (NFR-2, жёсткий контракт):** `git clean` — **только `-fd`, НИКОГДА `-x`** (иначе удалил бы gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломался бы rollback `do_rollback`); sibling `<repos_dir>/.deploy-state-*`/`.merge-lease-*.json` (под родителем `$REPO`) и `.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`. Каждый git-шаг — `|| log "...continuing"` (never-break): сбой гигиены не ухудшает исход относительно текущего голого pull; на чистой базе блок — no-op (happy-path и exit-коды байт-в-байт). `--build-staging` (build из worktree, без pull) не затронут.

CLAUDE.md

@@ -323,6 +323,233 @@ to the following files would be overwritten by merge: src/config.py` — гря
   фикса, зелёный после). Детали — `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`.
+
+## Детерминированный staging-раннер вместо LLM-деплойера (ORCH-115)
+Первый реализованный срез determinization-roadmap (ORCH-118 A6, `replace-deterministic-now`): на
+стадии `deploy-staging` для self-hosting `orchestrator` **LLM-агент `deployer` заменён
+детерминированным кодом** (`src/staging_runner.py`). Работа агента на этой стадии была чисто
+механической (запуск staging-сюиты + маппинг exit-кода) — теперь её делает leaf, перехватываемый в
+`launch_job` **до `_spawn`** (прецедент `deploy-finalizer`/`post-deploy-monitor`,
+`launcher.py:389/394`). **Инвариант (NFR-1):** замена *продюсера* артефакта, **не** гейта —
+контракт `15-staging-log.md`, гейт/`_parse_staging_status`/имя `check_staging_status`,
+`STAGE_TRANSITIONS`, machine-verdict `staging_status:`, схема БД — **байт-в-байт не тронуты**.
+Аддитивно, под kill-switch, never-raise, fail-closed.
+- **Перехват (D1):** `launch_job` — `if job.agent=="deployer" and staging_runner.should_intercept(job)`
+  → `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`): синхронно ведёт `jobs`-строку
+  через `mark_job`, возвращает `None` (нет `agent_runs`). Дискриминатор «staging vs prod» —
+  **стадия задачи** `deploy-staging` (роль `deployer` общая для `deploy-staging`/`deploy`), не имя
+  роли; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути).
+- **Раннер (D2-D7):** leaf по образцу `self_deploy`/`proc_group`/`staging_verdict` (на импорте только
+  `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/`qg.checks`/`notifications` — лениво).
+  Исполняет ту же сюиту (`docker exec orchestrator-staging python3 .../staging_check.py --base-url
+  http://localhost:8501 --mode stub`, арги из config — ORCH-101) через `proc_group` (tree-kill,
+  таймаут `staging_runner_timeout_s=600`); маппит exit-код **единым** контрактом
+  `self_deploy.map_exit_code_to_status` (`0→SUCCESS`/иначе/None→`FAILED`; ORCH-061 infra-tolerance
+  остаётся внутри `staging_check.py`, раннер не пересуживает); пишет `15-staging-log.md`
+  (`author_agent: staging-runner`/`model_used: n/a`, 52c-схема) + best-effort push в **фичеветку**
+  (не в `main` — гейт читает worktree первым, усиливает AC-8); вызывает **существующий**
+  `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — без новых
+  рёбер/исходов (lease ORCH-114 берётся внутри `advance_stage`, раннер не трогает).
+- **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→
+  advance (FAILED → тот же откат `deploy-staging → development` + developer-retry, что у LLM); сюита
+  **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл →
+  bounded **DEFER** (re-queue `deployer`-джоба + restart-safe маркер `staging-runner infra-retry` в
+  `task_content`, без правки схемы БД), на исчерпании `staging_runner_infra_max_retries` → fail-closed
+  `FAILED` + advance + alert. Никогда тихий advance/ложный green; не клинит очередь; не жжёт
+  developer-retry на транзиентной инфре.
+- **Флаги** (`config.py`, дефолт = боевое): `staging_runner_enabled` (kill-switch, env
+  `ORCH_STAGING_RUNNER_ENABLED`), `staging_runner_repos` (CSV; **пусто → self-hosting only**),
+  `staging_runner_timeout_s=600`, `staging_runner_infra_max_retries=2`,
+  `staging_runner_infra_retry_delay_s=30`. Откат = `ORCH_STAGING_RUNNER_ENABLED=false` → на
+  `deploy-staging` снова LLM-`deployer` через `_spawn` **байт-в-байт**. Наблюдаемость — in-process
+  счётчики + read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт на прогон
+  (различает код-фейл и tool-error). Норматив сопровождения ORCH-118: обновлены
+  `llm-call-sites.md`/`llm-determinization-roadmap.md`/`llm-usage-policy.md` (A6 — реализован, машинные
+  блоки/инвариант «единственный транспорт S0» целы) + `deployer.md` (LLM-ветвь — fallback). Покрытие —
+  `tests/test_orch115_staging_runner.py` (TC-01…TC-13) + зелёные LLM-анти-дрейф тесты (TC-14). Детали —
+  `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`, сквозной
+  `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`.
+- **ORCH-123 (host-side исполнение + классификация environment-дефекта, bug→escalate full-cycle,
+  adr-0049):** фикс инцидента **ORCH-116** — раннер ORCH-115 вызывал `docker exec` **изнутри**
+  прод-контейнера, где **нет docker CLI** (`Dockerfile:11` несёт только `openssh-client git curl`;
+  `docker.sock` смонтирован, клиента нет) → `FileNotFoundError` → постоянный environment-дефект
+  ложно маршрутизировался как код-фейл-откат `deploy-staging → development` (с расходом
+  developer-retry); любая self-hosting задача на `deploy-staging` была обречена. Аддитивно, под
+  флагами, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена
+  `check_staging_status`/`_parse_staging_status`/machine-verdict-ключи/схема БД — **байт-в-байт не
+  тронуты** (замена *стратегии исполнения продюсера*, **не** гейта; зеркало ORCH-115 NFR-1).
+  **(D1)** `build_staging_command` обёртывает ту же `docker exec orchestrator-staging … staging_check.py
+  … --mode stub` в `ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> '<…>'`
+  (зеркало `self_deploy`/`image_freshness`; канал доверенный `ORCH_DEPLOY_SSH_HOST=127.0.0.1`,
+  ssh-ключ `:ro`, `openssh-client` в образе — новых секретов/привилегий нет; сюита по-прежнему бежит
+  **внутри** `orchestrator-staging` 8501, меняется лишь инициатор `docker exec`). **(D2 security)**
+  docker CLI/SDK в контейнер **не** добавляется, `docker.sock` **не** используется изнутри (это
+  root-эквивалентное расширение поверхности атаки, доступное и LLM-агентам). **(D3)** двухуровневый
+  исход ORCH-115 заменён **трёхсторонней** чистой `classify_staging_outcome` (зеркало
+  `merge_gate.classify_retest_failure`): `suite-ran` (распознанный exit-код ≠255 **без** env-маркера в
+  stderr → доверяем коду `0→SUCCESS`/`≠0→FAILED`; анти-over-tolerance BR-3), `permanent-env`
+  (spawn-error `rc=None`/нет ssh-target/`rc∈{126,127}`/env-маркер `No such container`/`Cannot connect
+  to the Docker daemon` → ретрай бессмыслен), `transient-infra` (timeout/ssh `rc=255`/неизвестно →
+  ретрай осмыслен); дизамбигуация `exit=1`-коллизии — скан stderr на env-маркеры, не голый код;
+  fail-safe → `transient-infra`. **(D4 инвариант «инфра ≠ код-фейл»)** `permanent-env` → немедленный
+  **infra-HOLD** (DEFER пропускается, `15-staging-log.md` НЕ пишется, advance НЕ зовётся, developer-retry
+  НЕ жжётся, alert «НЕ дефект кода»); `transient-infra` → bounded DEFER, на исчерпании — тоже
+  infra-HOLD+alert (**супершид ORCH-115 D5** fail-closed-FAILED-отката). «Сюита **не** исполнилась»
+  (env ИЛИ инфра) **никогда** не оканчивается код-фейл-откатом — закрывает RCA-класс ORCH-110 на
+  staging-ребре; задача держится на `deploy-staging` (reconciler `advance_if_gate_passed` на red-гейте
+  → `None`, без отката, R-2). **(D5)** `preflight()` пробит host-side канал на старте `main.lifespan`
+  (best-effort, never-blocks). **(D6)** новый флаг `staging_runner_exec_host_side=True`
+  (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`); откат — `=false` (in-container 1:1) или
+  `ORCH_STAGING_RUNNER_ENABLED=false` (LLM-deployer 1:1). **(D8)** счётчик `permanent_env` + `exec_host_side`
+  + `preflight` в блоке `staging_runner` `GET /queue`. Покрытие — `tests/test_orch123_staging_runner_exec.py`
+  (TC-01 обязательный регресс ORCH-116 red→green; TC-02…TC-14 + R-2) + зелёный анти-дрейф ORCH-115.
+  Детали — `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`,
+  сквозной `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`.
+
+## Детерминированный test-раннер вместо LLM-тестера (ORCH-116)
+Второй реализованный срез determinization-roadmap (ORCH-118 A5, `needs-hybrid-fallback`): на стадии
+`testing` для self-hosting `orchestrator` **LLM-агент `tester` заменён детерминированным кодом**
+(`src/test_runner.py`). PASS/FAIL-ядро было деривируемо (регресс `pytest` + read-only smoke) — теперь
+его делает leaf, перехватываемый в `launch_job` **до `_spawn`** (прецедент `deploy-finalizer`/
+`post-deploy-monitor`/`staging-runner`, `launcher.py:397/402/405`). **Инвариант (NFR-1):** замена
+*продюсера* артефакта, **не** гейта — контракт `13-test-report.md`, гейт/`_parse_tests_verdict`/имя
+`check_tests_passed`, `STAGE_TRANSITIONS`, machine-verdict `result:` (+ legacy `verdict:`/`status:`),
+схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, гибрид
+(LLM строго off-control-path).
+- **Перехват (D1):** `launch_job` — `if job.agent=="tester" and test_runner.should_intercept(job)`
+  → `_run_test_runner_job` (зеркало `_run_staging_runner_job`): синхронно ведёт `jobs`-строку через
+  `mark_job`, возвращает `None` (нет `agent_runs`). Дискриминатор — роль `tester` **И** стадия задачи
+  `testing` (defense-in-depth: `tester` — единственный агент входа в `testing`, коллизии стадий нет, в
+  отличие от общей роли `deployer`/ORCH-115) **И** `applies(repo)`; `should_intercept` never-raise →
+  `False` → штатный `_spawn` (fail-safe к LLM-пути).
+- **Раннер (D2-D7):** leaf по образцу `staging_runner`/`self_deploy`/`proc_group` (на импорте только
+  `config`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications`
+  — лениво). `applies` = kill-switch `test_runner_enabled` + скоуп `test_runner_repos` (пусто →
+  self-hosting only) **И** резолв тест-контракта `_has_test_contract` (BR-9: репо без контракта →
+  LLM-tester, enduro-trails 1:1 даже если руками в CSV). Исполняет `python -m pytest
+  <test_runner_target>` **в worktree ветки** (анти checkout-гонка) через `proc_group`
+  (tree-kill, таймаут `test_runner_timeout_s=900`) + опц. read-only smoke (`/health`/`/status`/`/queue`
+  + блок `serial_gate`, stdlib `urllib`; транзиент → ограниченный ретрай, не-200/нет блока → немедленный
+  FAIL; `test_runner_smoke_enabled`); маппит exit-код **единым** `self_deploy.map_exit_code_to_status`
+  в токенах `result:` (`0→PASS`/иначе/None→`FAIL`, fail-closed; smoke-провал AND-ится в `FAIL`); пишет
+  `13-test-report.md` (`author_agent: test-runner`/`model_used: n/a`, 52c-схема) + best-effort push в
+  фичеветку; вызывает **существующий** `advance_stage(current_stage="testing", finished_agent="tester")`
+  — без новых рёбер/исходов (lease ORCH-114 берётся внутри `advance_stage`).
+- **Анти-коллизия 52c-`status:` ↔ парсер (D6.1, специфично для tester):** `_parse_tests_verdict` читает
+  вердикт из **трёх** равноранговых полей (`verdict:`/`status:`/`result:`) с negative-token-priority →
+  52c-обязательное `status:` раннера **ВСЕГДА выровнено** по вердикту (`PASS → status: success`, `FAIL
+  → status: failed`), иначе негативный токен в `status:` при `result: PASS` дал бы ложный FAIL. Прибито
+  unit-тестом через неизменённый парсер.
+- **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→
+  advance (FAIL → тот же откат `testing → development` + developer-retry, что у LLM); сюита **не
+  исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded
+  **DEFER** (re-queue **`tester`**-джоба + restart-safe маркер `test-runner infra-retry` в
+  `task_content`, без правки схемы БД), на исчерпании `test_runner_infra_max_retries` → fail-closed
+  `FAIL` + advance + alert. Никогда тихий advance/ложный green; не клинит очередь; не жжёт
+  developer-retry на транзиентной инфре.
+- **Флаги** (`config.py`, дефолт = боевое): `test_runner_enabled` (kill-switch, env
+  `ORCH_TEST_RUNNER_ENABLED`), `test_runner_repos` (CSV; **пусто → self-hosting only**),
+  `test_runner_target=tests/`, `test_runner_timeout_s=900`, `test_runner_smoke_enabled`,
+  `test_runner_infra_max_retries=2`, `test_runner_infra_retry_delay_s=30`. Откат =
+  `ORCH_TEST_RUNNER_ENABLED=false` → на `testing` снова LLM-`tester` через `_spawn` **байт-в-байт**.
+  Наблюдаемость — in-process счётчики + read-only блок `test_runner` в `GET /queue` + один структурный
+  лог-вердикт на прогон (различает код-фейл и tool-error). **Гибрид (BR-8/NFR-7):** LLM строго
+  off-control-path — детерминированный раннер единственный продюсер `result:`; будущий триаж падений не
+  выносит/не переопределяет вердикт и не добавляет ребро в `STAGE_TRANSITIONS` (Phase 1 не реализован).
+  Норматив сопровождения ORCH-118: обновлены `llm-call-sites.md`/`llm-determinization-roadmap.md`/
+  `llm-usage-policy.md` (A5/rank 2 — реализован, машинные блоки/инвариант «ровно один `first_slice`»
+  целы) + `tester.md` (LLM-ветвь — fallback). Покрытие — `tests/test_orch116_test_runner.py`
+  (TC-01…TC-14) + зелёные LLM-анти-дрейф тесты (TC-15). Детали —
+  `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`, сквозной
+  `docs/architecture/adr/adr-0050-deterministic-test-runner.md`.
+
 ## Машинный журнал уроков (ORCH-098)
 Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
 **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих

docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md

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

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

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

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

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

docs/architecture/adr/adr-0048-deterministic-staging-runner.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-115
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# adr-0048: Детерминированный staging-раннер — первый реализованный срез determinization-roadmap
+
+> **Сквозной (cross-cutting) ADR.** Агрегирует решение ORCH-115, влияющее на **весь**
+> оркестратор: вводит новый компонент-leaf `src/staging_runner.py`, снимает первую
+> avoidable LLM-консультацию (`deployer`/`staging-status`, A6) и переводит rank-1
+> determinization-roadmap из «план» в «реализовано». Локальная детализация (все решения
+> D1–D11) — `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`.
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-118 ([adr-0047](adr-0047-llm-usage-policy-and-call-site-map.md)) зафиксировал
+нормативную политику и карту LLM-консультаций и назвал **avoidable LLM control paths =
+`{tester, deployer}`**, поставив **deployer (staging-status)** первым срезом
+(`first_slice = yes`, `replace-deterministic-now`, `hybrid_needed = no`). ORCH-118 раннеры
+**не реализовывал** (docs+tests). ORCH-115 — первая фактическая реализация этого среза.
+
+Вердикт `staging_status:` на стадии `deploy-staging` сейчас эмитит LLM-агент `deployer`, но
+он есть **чистый маппинг exit-кода** `scripts/staging_check.py` (infra-tolerance ORCH-061
+уже внутри скрипта), а гейт `check_staging_status` детерминирован. Это удовлетворяет обоим
+условиям «avoidable»: C-консультация **и** деривируемый вердикт. Прецедент детерминированной
+замены агента (`launch_job`-перехват до `_spawn`, D1/D2 `deploy-finalizer`/`post-deploy-monitor`)
+и эталон «детерминированный джоб → `advance_stage`» (`run_deploy_finalizer`) уже работают в
+проде — архитектурный риск снят.
+
+## Решение
+
+**Новый leaf `src/staging_runner.py` + перехват в `launch_job` до `_spawn`** (рядом с D1/D2).
+На `deploy-staging` для in-scope репо джоб `deployer` обрабатывает раннер: исполняет
+staging-сюиту через `proc_group` (tree-kill, ORCH-110), маппит exit-код единым контрактом
+`self_deploy.map_exit_code_to_status`, пишет `15-staging-log.md` (тот же machine-key
+`staging_status:`), вызывает **существующий** `advance_stage(finished_agent="deployer")`.
+
+Кросс-каттинговые инварианты (сохранены **байт-в-байт**):
+- `STAGE_TRANSITIONS` (`src/stages.py`), реестр и имена `QG_CHECKS`/`check_*`/`_parse_*`,
+  machine-verdict-ключи (`staging_status:`/`deploy_status:`/`verdict:`/`result:`/
+  `security_status:`/`coverage_status:`), **схема БД** — не тронуты. Это замена *продюсера*
+  артефакта, не гейта/стадии.
+- Единственный транспорт LLM-консультации (`launcher._spawn`/S0,
+  [llm-usage-policy.md](../llm-usage-policy.md) §5) — соблюдён: раннер **не зовёт LLM**;
+  второй транспорт не вводится.
+- Сквозной бюджет времени ORCH-065/109/110 (`reaper_max_running_s` > Σ(работ на ребре
+  `deploy-staging`) + grace) — соблюдён **без** правки `reaper_max_running_s` (раннер-таймаут
+  600s ≤ прежнего LLM-окна).
+- Граница ORCH-112/ORCH-114: transition-lease берётся **внутри** `advance_stage`; раннер
+  lease/гигиену не модифицирует.
+
+Скоуп — **self-hosting only** (`staging_runner_repos=""` → `is_self_hosting_repo`), под
+kill-switch `staging_runner_enabled` (off → `_spawn` LLM-deployer'а байт-в-байт). never-raise
+во всех публичных функциях; **двухуровневый исход** (verdict при исполнившейся сюите; bounded
+defer → fail-closed на tool-error/таймауте) убирает с staging-ребра RCA-класс ORCH-110 (инфра
+≠ код-фейл).
+
+**Эволюция карты LLM (норматив сопровождения, в том же PR — D11 локального ADR):**
+`llm-call-sites.md` (A6 → реализовано детерминированно), `llm-determinization-roadmap.md`
+(rank 1 deployer → реализован; инвариант «ровно один `first_slice`» цел), `llm-usage-policy.md`
+(§5 — транспорт не нарушен), плюс анти-дрейф-тесты (`test_llm_call_site_inventory.py`/
+`test_llm_determinization_docs.py`). Эти правки коуплены к коду → применяются в development
+атомарно с реализацией, не в architecture-стадии.
+
+## Последствия
+
+- **+** Минус один avoidable LLM control path; первый доказанный раннер-паттерн замены
+  C-консультации (опора для второго кандидата — `tester`-гибрид, rank 2).
+- **+** Дешевле/быстрее/детерминированнее собственный `deploy-staging`; нет токенов/латентности
+  LLM в точке ветвления.
+- **+** Паттерн переиспользуем: leaf + перехват до `_spawn` + `advance_stage` — шаблон для
+  будущих срезов и для Phase 2 (project deploy contract не-self репо).
+- **−** Новый компонент + врезка + defer-механика. Митигейшн: never-raise leaf, kill-switch
+  (fail-safe к LLM), без схемы БД, структурное покрытие.
+- **Откат:** `ORCH_STAGING_RUNNER_ENABLED=false` → прежний LLM-путь на `deploy-staging`
+  байт-в-байт.
+
+## Ссылки
+- Локальный ADR: `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`
+- Политика/карта/roadmap: [llm-usage-policy.md](../llm-usage-policy.md),
+  [llm-call-sites.md](../llm-call-sites.md), [llm-determinization-roadmap.md](../llm-determinization-roadmap.md),
+  [adr-0047](adr-0047-llm-usage-policy-and-call-site-map.md)
+- Прецеденты: D1/D2 (`launcher.py:389/394`), `run_deploy_finalizer` (`stage_engine.py:2010`),
+  `proc_group` (ORCH-110, [adr-0042](adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md)),
+  transition-lease (ORCH-114, [adr-0045](adr-0045-transition-ownership-lease-and-stage-cas.md))

docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md

@@ -0,0 +1,105 @@
+---
+work_item: ORCH-123
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# adr-0049: Граница исполнения docker — все docker-операции host-side, не изнутри app-контейнера
+
+> **Сквозной (cross-cutting) ADR.** Кодифицирует инвариант **«docker-операции оркестратора
+> исполняются host-side через доверенный ssh-канал, никогда изнутри прод-контейнера»**, охватывающий
+> компоненты ORCH-036/058/115/123/101, и **амендит** execution-strategy-решение
+> [adr-0048](adr-0048-deterministic-staging-runner.md) (D3/D5). Поводом стала задача ORCH-123 (баг:
+> staging-runner отклонился от инварианта). Локальная детализация (D1–D9) —
+> `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`.
+
+## Статус
+Proposed
+
+## Контекст
+
+Прод-контейнер `orchestrator` (8500) **не содержит docker CLI** (`Dockerfile:11`:
+`openssh-client git curl ca-certificates` + pinned gitleaks; `python:3.12-slim` docker не несёт).
+`/var/run/docker.sock` смонтирован rw + `group_add 999` (ORCH-040 «МИНА 1»), но **клиента, который
+бы им воспользовался, нет** — сознательно: добавление CLI/SDK активировало бы root-эквивалентный путь
+исполнения для всего, что бежит в контейнере (вкл. LLM-агентов). Поэтому в оркестраторе сложился
+**инвариант исполнения**, ранее не выделенный в отдельный ADR:
+
+- **ORCH-036** (`self_deploy.build_deploy_command`, [adr-0007](adr-0007-executable-self-deploy.md)) —
+  прод-деплой исполняется host-side через `ssh + setsid bash <hook> --deploy` на `127.0.0.1`.
+- **ORCH-058** (`image_freshness`, [adr-0008](adr-0008-staging-image-provenance.md)) — ребилд
+  staging-образа (`ssh … bash <hook> --build-staging`) и инспекция revision
+  (`image_revision(ssh_target=…)`) — host-side; модуль прямо документирует:
+  *«docker lives on the HOST (the container ships only openssh-client git)»*.
+- **ORCH-101** ([adr-0036](adr-0036-replication-foundation-host-parametrization.md)) — host-параметры
+  канала (`deploy_ssh_*`, `deploy_host_repo_path`, `repos_dir`/`host_repos_dir`) расхардкожены.
+
+**ORCH-115** ([adr-0048](adr-0048-deterministic-staging-runner.md)), заменяя LLM-деплойера
+детерминированным `staging_runner`, **отклонился** от инварианта: зашил `docker exec` **изнутри**
+прод-контейнера через `proc_group → Popen` → `FileNotFoundError: docker` → постоянный
+environment-дефект, ложно маршрутизированный как транзиентная инфра → DEFER → fail-closed FAILED →
+**откат `deploy-staging → development`** (винит код задачи за дефект окружения раннера). Инцидент
+ORCH-116/ORCH-123.
+
+## Решение
+
+**Кодифицировать инвариант (нормативно):** docker-операции оркестратора (`docker`/`docker compose`/
+`docker exec`/`docker inspect`/`docker tag`) исполняются **host-side** через доверенный ssh-канал
+(`deploy_ssh_host=127.0.0.1`, ключ смонтирован, `openssh-client` в образе) — **никогда** изнутри
+прод-контейнера, который docker CLI не несёт. `/var/run/docker.sock` **не используется** изнутри
+контейнера; docker CLI/SDK в образ **не добавляется** (любое исключение — отдельный явный
+security-review: socket-из-контейнера = root-эквивалент на хосте, обслуживающем все проекты).
+
+**ORCH-123 приводит `staging_runner` в соответствие** (амендит adr-0048 D3/D5):
+- **D3 (амендмент adr-0048):** `staging_runner.build_staging_command` теперь обёртывает
+  `docker exec orchestrator-staging python3 staging_check.py …` в `ssh <user>@<host> '<…>'` (зеркало
+  `image_freshness.image_revision(ssh_target=…)`). Внутренняя команда сюиты и exit-код-контракт — те
+  же; меняется лишь **инициатор/канал**.
+- **D5 (амендмент adr-0048 двухуровневого исхода):** введён **третий** класс исхода `permanent-env`
+  (зеркало `merge_gate.classify_retest_failure`, ORCH-110); корневой инвариант — **«сюита не
+  исполнилась» (environment ИЛИ транзиентная инфра) НИКОГДА не оканчивается код-фейл-откатом и не жжёт
+  developer-retry**; откат — только для реально исполнившейся сюиты с `exit≠0`. Терминал исчерпания
+  DEFER изменён с fail-closed-FAILED+advance на **infra-HOLD + alert** (как ORCH-110 D3).
+
+Кросс-каттинговые инварианты (сохранены **байт-в-байт**, как adr-0048):
+- `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_staging_status`/`_parse_staging_status` /
+  machine-verdict-ключи (`staging_status:`/`deploy_status:`/…) / **схема БД** — не тронуты (замена
+  *стратегии исполнения продюсера*, не гейта/стадии).
+- Единственный транспорт LLM-консультации (`launcher._spawn`/S0, [adr-0047](adr-0047-llm-usage-policy-and-call-site-map.md))
+  — соблюдён (раннер LLM не зовёт).
+- Сквозной бюджет времени ORCH-065/109/110 (`reaper_max_running_s` > Σ(работ на ребре) + grace) — не
+  растёт (host-side ssh заменяет in-container call, окно ≤ `staging_runner_timeout_s`).
+- Граница transition-lease ORCH-114 — берётся внутри `advance_stage`; раннер не трогает.
+
+Скоуп — **self-hosting only** (`staging_runner_repos=""` → `is_self_hosting_repo`); под флагами
+`staging_runner_enabled` (→ LLM-путь) и **новым** `staging_runner_exec_host_side` (дефолт `True` →
+фикс; `False` → прежний in-container call). never-raise во всех публичных функциях.
+
+## Последствия
+
+- **+** Инвариант «docker host-side» выделен и задокументирован → будущие компоненты не повторят
+  отклонение ORCH-115; reviewer ловит in-container docker как регресс инварианта.
+- **+** staging-сюита реально исполняется в проде; инфра/environment ≠ код-фейл на staging-ребре
+  (закрыт RCA-класс ORCH-110 на этом ребре полностью); анти-over-tolerance цел.
+- **+** Без расширения привилегий (нет docker CLI/SDK в контейнере, сокет не используется); согласовано
+  с ORCH-036/058.
+- **−** Remote tree-kill ограничен локальным ssh-клиентом (как `image_freshness.rebuild_staging_image`);
+  backstop — bounded таймаут внутри `staging_check.py`.
+- **−** Permanent-env/исчерпавшая-DEFER задача держится на `deploy-staging` (блокирует serial-gate репо
+  до починки оператором) — принятый tradeoff (зеркало ORCH-110), self-hosting only.
+- **Откат:** `ORCH_STAGING_RUNNER_ENABLED=false` (→ LLM) или `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false`
+  (→ in-container call).
+
+## Ссылки
+- Локальный ADR: `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`
+- Амендит: [adr-0048](adr-0048-deterministic-staging-runner.md) (D3/D5 ORCH-115)
+- Опирается на: [adr-0007](adr-0007-executable-self-deploy.md) (ORCH-036 self-deploy ssh),
+  [adr-0008](adr-0008-staging-image-provenance.md) (ORCH-058 image-freshness host-side docker),
+  [adr-0042](adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md) (ORCH-110 proc_group +
+  classify + infra-tolerance), [adr-0036](adr-0036-replication-foundation-host-parametrization.md)
+  (ORCH-101 host-параметризация)
+- Сверено по коду: `src/staging_runner.py`, `src/self_deploy.py:220`, `src/image_freshness.py:185/246`,
+  `scripts/orchestrator-deploy-hook.sh:166/197`, `Dockerfile:11`, `docker-compose.yml`

docs/architecture/adr/adr-0050-deterministic-test-runner.md

@@ -0,0 +1,115 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# adr-0050: Детерминированный test-раннер — второй реализованный срез determinization-roadmap (tester-гибрид)
+
+> **Сквозной (cross-cutting) ADR.** Агрегирует решение ORCH-116, влияющее на **весь**
+> оркестратор: вводит новый компонент-leaf `src/test_runner.py`, снимает вторую avoidable
+> LLM-консультацию из потока управления (`tester`/`result:`, A5) и переводит rank-2
+> determinization-roadmap из «план» в «реализовано». Локальная детализация (все решения
+> D1–D12, включая tester-специфичную анти-коллизию `status:` D6.1) —
+> `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`.
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-118 ([adr-0047](adr-0047-llm-usage-policy-and-call-site-map.md)) зафиксировал нормативную
+политику и карту LLM-консультаций и назвал **avoidable LLM control paths = `{tester, deployer}`**.
+Первый срез — **deployer (staging-status, rank 1)** — реализован **ORCH-115**
+([adr-0048](adr-0048-deterministic-staging-runner.md)). Второй кандидат — **tester (rank 2,
+`needs-hybrid-fallback`, `hybrid_needed = yes`, `first_slice = no`)**. ORCH-116 — его фактическая
+реализация.
+
+Вердикт `result:` на стадии `testing` сейчас эмитит LLM-агент `tester`, но **PASS/FAIL-ядро** есть
+**чистый маппинг** exit-кода `pytest` + read-only smoke, а гейт `check_tests_passed`
+(`_parse_tests_verdict`) детерминирован и читает **только** frontmatter `result:` (+ legacy
+`verdict:`/`status:`). Это удовлетворяет обоим условиям «avoidable»: C-консультация **и**
+деривируемый вердикт. **Гибрид-нюанс:** прежний промпт нёс ещё и настоящее суждение (триаж падений,
+маппинг TC↔критерии) — поэтому ORCH-116 выносит из потока управления **только PASS/FAIL-исполнителя**,
+оставляя LLM допустимым лишь как будущий **off-control-path** триаж (Phase 2, не control-path).
+
+Прецедент детерминированной замены агента (`launch_job`-перехват до `_spawn`, D1/D2 +
+**рабочий эталон `src/staging_runner.py`** ORCH-115) и эталон «детерминированный джоб → `advance_stage`»
+уже в проде — архитектурный риск замены снят.
+
+## Решение
+
+**Новый leaf `src/test_runner.py` + перехват в `launch_job` до `_spawn`** (рядом с D1/D2/ORCH-115).
+На `testing` для in-scope репо с резолвимым тест-контрактом джоб `tester` обрабатывает раннер:
+исполняет регресс `pytest <target>` **в worktree ветки** через `proc_group` (tree-kill, ORCH-110) +
+опциональный read-only smoke, маппит exit-код единым контрактом `self_deploy.map_exit_code_to_status`
+(транслируя токены в `PASS`/`FAIL`), пишет `13-test-report.md` (тот же machine-key `result:`),
+best-effort пушит лог в фичеветку, вызывает **существующий** `advance_stage(current_stage="testing",
+finished_agent="tester")`.
+
+Кросс-каттинговые инварианты (сохранены **байт-в-байт**):
+- `STAGE_TRANSITIONS` (`src/stages.py`), реестр и имена `QG_CHECKS`/`check_tests_passed`/
+  `_parse_tests_verdict`/прочих `check_*`/`_parse_*`, machine-verdict-ключи (`result:`/`verdict:`/
+  `status:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`), **схема БД** —
+  не тронуты. Это замена *продюсера* артефакта, не гейта/стадии.
+- Единственный транспорт LLM-консультации (`launcher._spawn`/S0,
+  [llm-usage-policy.md](../llm-usage-policy.md) §5) — соблюдён: раннер **не зовёт LLM**; второй
+  транспорт не вводится; будущий off-control-path триаж — вне control-path (не контр-пример политике).
+- Сквозной бюджет времени ORCH-065/109/110 (`reaper_max_running_s` (5400) > Σ(работ на ребре)) —
+  соблюдён **без** правки `reaper_max_running_s`: ребро `testing` отдельно от `deploy-staging`, окно
+  раннера ≤900s ≤ прежнего LLM-окна `agent_timeout_seconds` (1800s).
+- Граница ORCH-112/ORCH-114/ORCH-115: transition-lease берётся **внутри** `advance_stage`; раннер
+  lease/гигиену/`staging_runner` не модифицирует.
+
+Скоуп — **self-hosting only** (`test_runner_repos=""` → `is_self_hosting_repo` + резолв
+тест-контракта `_has_test_contract`, в Phase 1 = self-hosting), под kill-switch
+`test_runner_enabled` (off → `_spawn` LLM-tester'а байт-в-байт). never-raise во всех публичных
+функциях; **двухуровневый исход** (verdict при исполнившейся сюите; bounded defer → fail-closed на
+tool-error/таймауте) убирает с `testing`-ребра RCA-класс ORCH-110 (инфра ≠ код-фейл).
+**Backward-compat (BR-9):** репо без резолвимого тест-контракта → `applies==False` → прежний
+LLM-tester (enduro-trails не затронут).
+
+**Tester-специфичная анти-коллизия (D6.1 локального ADR, отсутствует в ORCH-115):**
+`_parse_tests_verdict` читает вердикт из **трёх** полей (`verdict:`/**`status:`**/`result:`) с
+negative-token-priority — поэтому обязательное 52c-поле `status:` раннера **жёстко выровнено** по
+вердикту (`success` для PASS / `failed` для FAIL), иначе негативный токен в `status:` при `result:
+PASS` дал бы ложный FAIL. Зафиксировано unit-тестом через неизменённый парсер.
+
+**Эволюция карты LLM (норматив сопровождения, в том же PR — D12 локального ADR):**
+`llm-call-sites.md` (A5 → реализовано детерминированно, но `avoidable=yes`/`axis=C`/
+`needs-hybrid-fallback` сохранены — LLM-ветвь как fallback / будущий off-control-path триаж),
+`llm-determinization-roadmap.md` (rank 2 tester → реализован; **инвариант «ровно один
+`first_slice = yes`» цел** — `first_slice` остаётся у rank 1/deployer, у tester — `no`),
+`llm-usage-policy.md` (§5 — транспорт не нарушен), плюс анти-дрейф-тесты
+(`test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py`). Эти правки коуплены к коду →
+применяются в development атомарно с реализацией, не в architecture-стадии (как ORCH-115).
+
+## Последствия
+
+- **+** Минус ещё один avoidable LLM control path; второй доказанный раннер-паттерн (теперь и для
+  `needs-hybrid-fallback`-кандидата, не только `replace-deterministic-now`).
+- **+** Дешевле/быстрее/детерминированнее собственный `testing`; нет токенов/латентности LLM в точке
+  ветвления `testing → deploy-staging` / `testing → development`.
+- **+** Паттерн остаётся переиспользуемым: leaf + перехват до `_spawn` + `advance_stage` — шаблон для
+  Phase 2 (project test contract не-self репо + опциональный off-control-path LLM-триаж).
+- **+** Гибрид-граница (D11 локального ADR): архитектура не закрывает будущий off-control-path триаж,
+  не пуская LLM обратно в поток управления вердикта.
+- **−** Новый компонент + врезка + defer-механика + tester-специфичная анти-коллизия `status:`.
+  Митигейшн: never-raise leaf, kill-switch (fail-safe к LLM), без схемы БД, инвариант выравнивания
+  `status:` + структурное покрытие `tests/test_orch116_test_runner.py`.
+- **Откат:** `ORCH_TEST_RUNNER_ENABLED=false` → прежний LLM-путь на `testing` байт-в-байт.
+
+## Ссылки
+- Локальный ADR: `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`
+- Первый срез: [adr-0048](adr-0048-deterministic-staging-runner.md) (ORCH-115, `src/staging_runner.py`)
+- Политика/карта/roadmap: [llm-usage-policy.md](../llm-usage-policy.md),
+  [llm-call-sites.md](../llm-call-sites.md) (A5),
+  [llm-determinization-roadmap.md](../llm-determinization-roadmap.md) (rank 2),
+  [adr-0047](adr-0047-llm-usage-policy-and-call-site-map.md)
+- Прецеденты: D1/D2 (`launcher.py:397/402`), `_run_staging_runner_job` (`launcher.py:438`),
+  `run_staging_gate` (`staging_runner.py`), `proc_group` (ORCH-110,
+  [adr-0042](adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md)),
+  transition-lease (ORCH-114, [adr-0045](adr-0045-transition-ownership-lease-and-stage-cas.md))

docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md

@@ -0,0 +1,110 @@
+---
+work_item: ORCH-124
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# ADR-0051: Ось «пауза» serial-gate — park-сигнал без блокировки FIFO
+
+Сквозной (cross-cutting) ADR. Детальное решение задачи —
+`docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`.
+
+Статус: **Proposed** · Дата: 2026-06-16 · Источник: **ORCH-124** (bug → escalate full-cycle)
+
+## Контекст
+
+ORCH-088 (serial-gate, adr-0017) определяет «активную задачу репо» **исключительно по машинной стадии**
+`tasks.stage NOT IN ('done','cancelled')` (после ORCH-090/adr-0026 — с учётом терминала `cancelled`).
+Plane-статусы Backlog/Blocked/Needs-Input — **слой B (индикация), ORCH-066** — не меняют `tasks.stage`
+(слой A); у таблицы `tasks` нет колонки статуса. ⇒ приостановленная оператором задача неотличима от
+активно исполняемой и держит FIFO-гейт (`t2.id < jobs.task_id`) закрытым для более поздних analyst-job
+того же репо.
+
+**Инцидент ORCH-116/ORCH-123:** ORCH-116 поставили на паузу, чтобы пропустить срочный фикс ORCH-123, но
+serial-gate держал analyst-job ORCH-123 в `queued`. Единственные обходы (терминальный `cancel`, довод до
+`done`, глобальное `serial_gate_enabled=false`) — грубые.
+
+Горячий путь `serial_gate.build_claim_clause` врезан в `claim_next_job` — **offline SQL** — и сетевого
+чтения Plane-статуса (как делает reconciler ORCH-060) позволить не может. Нужен **DB-резолвимый** сигнал
+паузы.
+
+## Решение
+
+### Инвариант: «пауза» — ОТДЕЛЬНАЯ ОСЬ планировщика, ортогональная «терминальности»
+
+Вводится **per-task park-сигнал** — аддитивная нуллабельная колонка **`tasks.paused_at TEXT`**
+(NULL = не на паузе) — и **новая ось планировщика «пауза»**, независимая от оси «терминальность».
+
+| Ось | Предикат | Кто использует | Меняется ORCH-124? |
+|-----|----------|----------------|--------------------|
+| **Терминальность** (adr-0026) | `stage IN ('done','cancelled')` | `serial_gate` + `task_deps` + `stages.py` | **НЕТ — байт-в-байт** |
+| **Пауза** (новая, ORCH-124) | `paused_at IS NOT NULL` | **только** FIFO «active» предикат `serial_gate` | да (аддитивно) |
+
+**serial-gate «активная задача» ⇔ `stage NOT IN ('done','cancelled') AND paused_at IS NULL`.** Это
+**осознанная, задокументированная** дивергенция serial-gate от чисто-терминального предиката (требование
+гармонизации adr-0026): пауза выводит предшественника из FIFO-учёта serial-gate, **не делая его
+терминальным**.
+
+### Что НЕ меняется (анти-регресс adr-0026)
+
+- **`task_deps`** (adr-0015) и **`stages.py::STAGE_TRANSITIONS`** колонку `paused_at` **не читают** —
+  остаются чисто терминальными. Явно объявленная зависимость (`job_deps`) на **приостановленную** задачу
+  **по-прежнему блокирует** зависимый job. Пауза («пропустите меня в FIFO») и dependency («B нужен
+  результат A») — разные оси; пауза НЕ обходит dependency и НЕ обходит per-repo `repo_freeze`.
+- `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict / схемы существующих таблиц — без
+  изменений. Пауза — не стадия и не Quality Gate, а признак планировщика очереди.
+
+### Точки, признающие ось «пауза» (исчерпывающе)
+
+1. `src/serial_gate.py::build_claim_clause` — терм `AND t2.paused_at IS NULL` внутри `active_clause`
+   (под под-флагом). **(маркер ORCH-124, рядом с ORCH-088/ORCH-090)**
+2. `src/serial_gate.py::repo_has_active_task` / `_per_repo_snapshot` — тот же предикат + наблюдаемость
+   (ключ `paused`, `reason` ожидания).
+3. `src/db.py` — колонка `tasks.paused_at` (`_ensure_column`) + хелперы `set_task_paused`/
+   `clear_task_paused`/`is_task_paused`.
+4. `src/main.py` — операторские эндпоинты `POST /serial-gate/pause|resume` (по образцу
+   `POST /serial-gate/unfreeze`).
+
+### Анти-stale-base при возобновлении (ORCH-088 не регрессирует)
+
+Пауза «демотирует» задачу в FIFO; свежесть базы при resume обеспечивают **существующие** механизмы — новой
+rebase-машинерии нет: отложенный срез ветки (ORCH-088, для паузнутой-в-`analysis`) + безусловный pre-merge
+`auto_rebase_onto_main` под merge-lease (ORCH-026/093) + merge-gate re-test (ORCH-110) для уже
+материализованной ветки. Нормальная задача (`paused_at IS NULL`) по-прежнему держит гейт.
+
+### Флаги / совместимость
+
+- Независимый под-флаг `serial_gate_pause_enabled` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`, дефолт `True`) —
+  зеркало `serial_gate_freeze_enabled`. `False` ⇒ pause-терм опущен из SQL, эндпоинты no-op ⇒ serial-gate
+  байт-в-байт как ORCH-088/090. Область — переиспользует `serial_gate_repos` (новый `*_repos` не вводится).
+- Дефолт `True` безопасен: пока ни одна задача не на паузе, `paused_at` везде `NULL` ⇒ истинный no-op
+  (enduro не затронут).
+- never-raise: pause-терм в `build_claim_clause` сохраняет **fail-OPEN**; freeze — **fail-CLOSED**.
+- Миграция — только аддитивная/идемпотентная (`_ensure_column`); общая прод-БД безопасна (NFR-3).
+
+## Последствия
+
+- **+** Чистая операторская «пауза без блокировки», отличная от cancel (терминал) и от kill-switch;
+  durable, offline, webhook-независимая; закрывает инцидент ORCH-116/ORCH-123.
+- **+** Единый, явно описанный двухосевой предикат планировщика (терминальность ⊥ пауза) — устранён риск
+  будущего рассинхрона.
+- **−** Появилась вторая ось «активности» serial-gate — будущие подсистемы планировщика обязаны помнить:
+  serial-gate «активна» = `не терминальна И не на паузе`, но **терминал** (`task_deps`/`stages.py`) ось
+  «пауза» НЕ включает. Митигейшн: этот ADR + маркер `ORCH-124` в изменённых местах + тесты.
+- **Откат:** `ORCH_SERIAL_GATE_PAUSE_ENABLED=false` (serial-gate 1:1 как ORCH-088/090; колонка `paused_at`
+  инертна).
+
+## Эволюция маркеров
+
+Горячий SQL serial-gate несёт теперь 3 маркера (`ORCH-088` FIFO-гейт, `ORCH-090` терминал `cancelled`,
+`ORCH-124` ось паузы) — правка любого из них сверяется с этим сводным ADR (анти-археология: 3+ маркеров →
+одна ссылка сюда, `docs/_standards/TRACEABILITY.md`).
+
+## Ссылки
+- Детальный ADR: `docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`
+- Данные: `docs/work-items/ORCH-124/08-data-requirements.md`
+- Связанные: adr-0017 (serial-gate ORCH-088), adr-0026 (терминал `{done,cancelled}` ORCH-090),
+  adr-0015 (task-deps), adr-0027 (merge-актор rebase/retry ORCH-093), adr-0042 (merge-gate re-test ORCH-110)

docs/architecture/internals.md

@@ -70,6 +70,14 @@ STAGE_TRANSITIONS = {
 рёбер не меняются), а терминал STOP-отмены. Системный предикат «задача завершена» —
 `stage ∈ {done, cancelled}` (синхронно в `reconciler`/`serial_gate`/`task_deps`; adr-0026).
 
+**Ось «пауза» ⊥ оси «терминальность» (ORCH-124, adr-0051):** serial-gate вводит **отдельную** ось
+паузы `tasks.paused_at IS NOT NULL` (durable per-task park-сигнал) — **ортогональную** терминалу. Для
+serial-gate «активная задача» ⇔ `stage NOT IN ('done','cancelled') AND paused_at IS NULL` (паузнутый
+предшественник не держит FIFO). **Терминал `{done,cancelled}` НЕ расширяется паузой:** `task_deps` и
+`stages.py` колонку `paused_at` НЕ читают (паузнутая объявленная зависимость по-прежнему блокирует
+зависимый job; пауза не обходит `repo_freeze`). Пауза — признак планировщика очереди, не стадия и не
+терминальное состояние.
+
 ### 3. Quality Gates (`src/qg/checks.py`)
 
 | Check | Метод проверки |
@@ -96,6 +104,33 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash
 3. Стартует **watchdog thread** (per-role wall-clock бюджет → SIGTERM→grace→SIGKILL по pid; ORCH-109: developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт, `_resolve_timeout`)
 4. Стартует **monitor thread**: `proc.wait()` (гарантированный reap → реальный exit_code в БД) → закрывает log_fh → git commit/push → auto-advance
 
+**Детерминированные перехваты `launch_job` ДО `_spawn` (no-LLM джобы).** Перед `_spawn` `launch_job`
+перехватывает зарезервированные роли и исполняет их детерминированно, сам ведя `jobs`-строку через
+`mark_job` (нет `agent_runs`, нет токенов): `deploy-finalizer` (D1, ORCH-036 Phase C) и
+`post-deploy-monitor` (D2, ORCH-021). **ORCH-115 ([adr-0048](adr/adr-0048-deterministic-staging-runner.md)):**
+тем же паттерном перехватывается джоб `deployer` на стадии `deploy-staging` для in-scope репо
+(дискриминатор — **стадия задачи**, не имя роли: роль `deployer` общая для `deploy-staging`/`deploy`;
++`staging_runner.applies(repo)` под kill-switch `staging_runner_enabled`, скоуп `staging_runner_repos`,
+пусто → self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к
+LLM). Leaf `src/staging_runner.py` (зеркало `run_deploy_finalizer`) исполняет staging-сюиту через
+`proc_group` (tree-kill, таймаут `staging_runner_timeout_s`), маппит exit-код
+`self_deploy.map_exit_code_to_status`, пишет `15-staging-log.md` (тот же machine-key `staging_status:`)
+и вызывает существующий `advance_stage(finished_agent="deployer")` (см. §5). Так LLM-агент `deployer`
+на `deploy-staging` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты.
+**ORCH-116 ([adr-0050](adr/adr-0050-deterministic-test-runner.md)):** тем же паттерном (рядом с
+ORCH-115) перехватывается джоб `tester` на стадии `testing` для in-scope репо с тест-контрактом
+(дискриминатор — роль `tester` **И** `tasks.stage == "testing"` **И** `test_runner.applies(repo)` под
+kill-switch `test_runner_enabled`, скоуп `test_runner_repos`, резолв `_has_test_contract`; пусто →
+self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к LLM). Leaf
+`src/test_runner.py` (зеркало `run_staging_gate`) исполняет регресс `pytest <target>` **в worktree
+ветки** через `proc_group` (tree-kill, таймаут `test_runner_timeout_s`) + read-only smoke, маппит
+exit-код `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе→`FAIL`), пишет
+`13-test-report.md` (тот же machine-key `result:`; 52c-`status:` выровнен по вердикту — D6.1) и вызывает
+существующий `advance_stage(finished_agent="tester")` (см. §5). Двухуровневый исход (анти-ORCH-110):
+сюита НЕ исполнилась → bounded defer re-queue **`tester`**-джоба, не код-фейл-откат. Так LLM-агент
+`tester` на `testing` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_tests_passed`/схема
+БД не тронуты.
+
 ### 5. Auto-advance (`launcher._try_advance_stage`)
 
 После успешного завершения агента:
@@ -188,6 +223,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 +419,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, рестарт НЕ требуется)
 
@@ -394,7 +450,16 @@ daemon-поток `src/job_reaper.py` (каркас `reconciler`) периоди
   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); схема БД и сквозной бюджет не тронуты;
+  `requeue_running_jobs` (до старта reaper); схема БД и сквозной бюджет не тронуты.
+  **ORCH-114 (adr-0045):** обобщает это in-memory-владение до **durable, кросс-путевого**
+  `transition_lease` (таблица `task_id PK, owner, owner_pid, owner_boot_id, …`): reaper
+  консультирует durable-lease на **всех** релевантных путях (не только Tier-2/`deploy-staging`),
+  живость владельца = `pid_alive(owner_pid)` + совпадение boot-id (рестарт ⇒ прежние lease мертвы);
+  парная CAS-запись стадии (`update_task_stage_cas`, `WHERE id=? AND stage=?`) — аборт проигравшего
+  без побочных эффектов; reconciler F-1 и webhook тоже defer при живом владельце. Kill-switch
+  `ORCH_TRANSITION_LEASE_ENABLED` (off → ровно поведение ORCH-113 выше); `finalizer_liveness.py`
+  не правится (надстройка durable-слоя поверх). Потолок возраста lease = `reaper_max_running_s`
+  (Tier-3 force-освобождает), сквозной бюджет цел;
 - **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
 
 Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,

docs/architecture/llm-call-sites.md

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

docs/architecture/llm-determinization-roadmap.md

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

docs/architecture/llm-usage-policy.md

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

docs/operations/INFRA.md

@@ -141,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` | каталог репозиториев (в контейнере / на хосте) |
@@ -224,16 +226,57 @@ 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.
 
+### Граница исполнения docker-операций — host-side, НЕ изнутри прод-контейнера (ORCH-123)
+
+**Инвариант (нормативно, adr-0049):** прод-контейнер `orchestrator` несёт **только**
+`openssh-client git curl` (+ pinned gitleaks) — **бинаря `docker` в образе НЕТ** (`Dockerfile:11`,
+`python:3.12-slim` его не несёт). `/var/run/docker.sock` **смонтирован** (`docker-compose.yml`,
+rw + `group_add 999`, «МИНА 1» ORCH-040), но **сознательно НЕ используется изнутри** контейнера: нет
+docker-клиента, и добавлять его (CLI/SDK) **нельзя** — это активировало бы дремлющий
+root-эквивалентный путь для всего, что бежит в контейнере, включая LLM-агентов (security-разбор —
+ADR-001 D2 / adr-0049 / R-1).
+
+Поэтому **все** docker-операции self-hosting исполняются **host-side** через **ssh на `127.0.0.1`**
+(`ORCH_DEPLOY_SSH_HOST`/`ORCH_DEPLOY_SSH_USER`, ssh-ключ смонтирован `:ro`), где docker CLI есть:
+- **прод-деплой** (ORCH-036, `self_deploy.build_deploy_command`) — `ssh … setsid bash hook --deploy`;
+- **image-freshness** (ORCH-058, `image_freshness.image_revision`/`rebuild_staging_image`) — `ssh … docker …`;
+- **staging-runner** (ORCH-123, `staging_runner.build_staging_command`) — `ssh … docker exec orchestrator-staging python3 … staging_check.py … --mode stub`.
+
+Сама staging-сюита (`scripts/staging_check.py`) **по-прежнему** исполняется **внутри** контейнера
+`orchestrator-staging` (8501) — меняется лишь **кто инициирует** `docker exec` (хост через ssh, а не
+прод-контейнер). До ORCH-123 staging-runner (ORCH-115) вызывал `docker exec` **изнутри**
+прод-контейнера → `FileNotFoundError` (нет `docker`) → постоянный environment-дефект ложно
+маршрутизировался как код-фейл-откат `deploy-staging → development` (инцидент ORCH-116). Фикс:
+host-side ssh-обёртка (флаг `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true`, дефолт) + трёхсторонняя
+классификация (suite-ran / permanent-env / transient-infra), где environment/инфра **никогда** не
+оканчивается код-фейл-откатом (infra-HOLD + алерт «инфра, НЕ дефект кода»), и prod-like preflight
+канала на старте сервиса. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (прежний in-container
+вызов — валиден лишь там, где docker CLI запечён в образ) или `ORCH_STAGING_RUNNER_ENABLED=false`
+(LLM-deployer 1:1). Детали — `docs/work-items/ORCH-123/06-adr/ADR-001`, сквозной adr-0049.
+
 **Правила для агентов при задачах ORCH:**
 1. НЕ перезапускать / не ронять прод-контейнер `orchestrator` в рамках задачи.
 2. Все проверки деплоя — на staging (8501), боевой 8500 не трогать.
 3. Деплой self — только через хук с health-check + авто-rollback (`DEPLOY_HOOK.md`).
+4. docker-операции исполняются **host-side через ssh** — в контейнере `docker` CLI нет (ORCH-123).
 
 ## Эксплуатация (быстрые команды)
 ```bash

docs/overview/tech-agents.md

@@ -48,6 +48,20 @@ Machine-verdict ключи читаются гейтами **только из Y
 Особенность: промпт `deployer` сознательно на английском (самый safety-critical — несёт
 запреты self-hosting в видной рамке); остальные пять — на русском.
 
+Особенность (ORCH-115): на стадии `deploy-staging` для self-hosting `orchestrator` LLM-`deployer`
+заменён **детерминированным staging-раннером** (`src/staging_runner.py`) — его работа была чисто
+механической (запуск staging-сюиты + маппинг exit-кода). LLM-промпт `deployer` остаётся fallback'ом
+под выключенным флагом / для не-self репо и продолжает вести прод-стадию `deploy`. Подробнее —
+[конвейер](tech-pipeline.md) и [карта LLM-консультаций](../architecture/llm-call-sites.md).
+
+Особенность (ORCH-116): на стадии `testing` для self-hosting `orchestrator` LLM-`tester` заменён
+**детерминированным test-раннером** (`src/test_runner.py`) — его PASS/FAIL-ядро деривируемо (exit-код
+`pytest` в worktree + read-only smoke), вердикт `result:` производит детерминированный код. Это
+гибрид (`needs-hybrid-fallback`): LLM-промпт `tester` остаётся fallback'ом под выключенным флагом / для
+репо без тест-контракта, а будущий off-control-path триаж падений не выносит и не переопределяет
+`result:`. Подробнее — [конвейер](tech-pipeline.md) и
+[карта LLM-консультаций](../architecture/llm-call-sites.md).
+
 ## Человек как седьмая роль
 
 Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы

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

@@ -19,7 +19,8 @@ Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N─
 
 ### Work-Item / Task — задача конвейера
 Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
-багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
+багфикс), рабочая **ветка**, счётчики откатов, отметки отмены и **паузы** (`paused_at` —
+durable-сигнал «пропустить меня в serial gate», не терминальный). Натуральные ключи — ID задачи
 в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
 **артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
 deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).
@@ -47,6 +48,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,10 @@
 ## Служебные страницы платформы
 
 - **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
-  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, фоновые
+  serial gate (заморозки, паузы задач, причина ожидания успешника), авто-лейблы, багфикс-трек,
-  демоны. Первая точка диагностики «что сейчас происходит».
+  coverage, журнал уроков, владение переходами (`transition_lease`), фоновые демоны. Первая
+  точка диагностики «что сейчас происходит». Паузу/возобновление задачи в serial gate оператор
+  включает явными эндпоинтами `POST /serial-gate/pause|resume`.
 - **`GET /metrics`** — машинный контракт для внешнего наблюдателя (версионированная схема):
   health, возраст последних событий, счётчики сбоев.
 - **`GET /health`** — живость процесса.

docs/overview/tech-pipeline.md

@@ -34,6 +34,27 @@ created → analysis → architecture → development → review → testing →
 | `done` | — | — | терминал |
 | `cancelled` | — | — | терминал (сток отмены) |
 
+> **Детерминированный staging-раннер (ORCH-115).** На стадии `deploy-staging` для self-hosting
+> `orchestrator` работу ведёт **детерминированный код** (`src/staging_runner.py`), а не LLM-агент
+> `deployer`: он перехватывается в `launch_job` до запуска агента (как Phase A/B/C прод-деплоя),
+> исполняет ту же staging-сюиту, маппит exit-код в `staging_status:` и инициирует **тот же** гейт
+> `check_staging_status`. Это замена *продюсера* артефакта, а не гейта: контракт `15-staging-log.md`,
+> имя/семантика `check_staging_status`, `STAGE_TRANSITIONS` — не изменились. Под kill-switch
+> `staging_runner_enabled` (скоуп `staging_runner_repos`, пусто → self-hosting only); при выключении
+> на стадии снова работает LLM-`deployer` байт-в-байт. Это первый реализованный срез
+> determinization-roadmap (см. `docs/architecture/llm-determinization-roadmap.md`).
+
+> **Детерминированный test-раннер (ORCH-116).** На стадии `testing` для self-hosting `orchestrator`
+> работу ведёт **детерминированный код** (`src/test_runner.py`), а не LLM-агент `tester`: он
+> перехватывается в `launch_job` до запуска агента (тем же паттерном, что staging-раннер), исполняет
+> регресс `pytest` в worktree ветки + read-only smoke, маппит exit-код в `result:` и инициирует **тот
+> же** гейт `check_tests_passed`. Это замена *продюсера* артефакта, а не гейта: контракт
+> `13-test-report.md`, имя/семантика `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`
+> — не изменились. Под kill-switch `test_runner_enabled` (скоуп `test_runner_repos`, пусто →
+> self-hosting only; репо без тест-контракта → LLM-tester); при выключении снова работает LLM-`tester`
+> байт-в-байт. Это второй реализованный срез determinization-roadmap (гибрид: LLM-фолбэк остаётся на
+> off-control-path триаж, не на вынесение `result:`).
+
 ## Под-гейты деплойного ребра — врезки, не стадии
 
 На переходе `deploy-staging → deploy` исполняются четыре под-гейта в нормативном порядке
@@ -86,6 +107,13 @@ created → analysis → architecture → development → review → testing →
 прода после выкладки замораживает репозиторий (freeze) до ручного разбора — следующие задачи
 ждут.
 
+У FIFO-порядка есть управляемое исключение — **пауза без блокировки**: оператор может явно
+поставить более раннюю задачу на паузу (durable-сигнал `tasks.paused_at`), и тогда срочный
+успешник её обгоняет, не дожидаясь завершения. Пауза — отдельная ось: она ≠ отмена (задача не
+терминальна и возвращается в гейт обратной командой) и **не** обходит ни freeze, ни объявленные
+зависимости. Свежесть базы возобновлённой задачи гарантируют те же механизмы (отложенный срез
+ветки + ребейз на слиянии), что и для обычного FIFO.
+
 ## Отмена: STOP → `cancelled`
 
 Перевод задачи в статус **STOP** останавливает агента, снимает job'ы с очереди, удаляет

docs/overview/tech-quality-security.md

@@ -40,6 +40,28 @@
 - Анти-регресс машинный: структурные тесты сканируют исполняемый код на боевые хост-литералы,
   а документацию — на секретоподобные значения; находка рвёт CI.
 
+## Где уместен LLM: карта вызовов и нормативная политика
+
+Платформа держит **доказательную карту** всех мест, где поток управления потребляет суждение
+LLM, и **нормативную политику** «LLM — только там, где нужно настоящее суждение». Карта разводит
+три факта: консультация ≠ транспорт/слот; **control-path** (вердикт LLM ветвит поток управления)
+≠ **artifact-producer** (детерминированный гейт судит артефакт независимо); и деривируемость
+вердикта из tool-сигналов. Путь называется **avoidable LLM control path**, когда он одновременно
+control-path и его вердикт деривируем из exit-кодов (тогда консультацию можно заменить
+детерминированным раннером). Поимённо: avoidable = `{tester, deployer}`; настоящее суждение
+сохраняется у `{analyst, architect, developer, reviewer}`. Карта — снимок, прибитый структурными
+анти-дрейф тестами. **Первый срез реализован (ORCH-115):** на `deploy-staging` для self-hosting
+`orchestrator` LLM-`deployer` заменён детерминированным `src/staging_runner.py` (вердикт
+`staging_status:` = маппинг exit-кода staging-сюиты); LLM-ветвь остаётся fallback'ом, гейт
+`check_staging_status` не тронут. **Второй срез реализован (ORCH-116):** на `testing` для self-hosting
+`orchestrator` LLM-`tester` заменён детерминированным `src/test_runner.py` (вердикт `result:` = exit-код
+`pytest` + read-only smoke); это гибрид (`needs-hybrid-fallback`) — LLM-ветвь остаётся fallback'ом /
+будущим off-control-path триажем, гейт `check_tests_passed`/`_parse_tests_verdict` не тронут.
+
+- Карта вызовов LLM: [`../architecture/llm-call-sites.md`](../architecture/llm-call-sites.md)
+- Нормативная политика: [`../architecture/llm-usage-policy.md`](../architecture/llm-usage-policy.md)
+- Порядок замен: [`../architecture/llm-determinization-roadmap.md`](../architecture/llm-determinization-roadmap.md)
+
 ## Self-hosting-страховки
 
 Платформа дорабатывает сама себя тем же конвейером — прод-инстанс при этом обслуживает и

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-115/00-business-request.md

@@ -0,0 +1,7 @@
+# Business Request: ORCH: replace LLM deployer with deterministic deploy runner
+
+Work Item ID: ORCH-115
+
+## Description
+
+TBD

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

@@ -0,0 +1,175 @@
+---
+work_item: ORCH-115
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-115 — заменить LLM-деплойера детерминированным staging-раннером
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Стадия `deploy-staging` сейчас исполняется **LLM-агентом `deployer`** (`src/stages.py:18`,
+`get_agent_for_stage("testing") = "deployer"`). Фактическая работа агента на этой стадии —
+**чисто детерминированная**: запустить staging-сюиту (`docker exec orchestrator-staging python3
+scripts/staging_check.py --base-url http://localhost:8501 --mode stub`), смаппить **exit-код**
+в вердикт (`0 → SUCCESS`, ≠0 → `FAILED`), записать `15-staging-log.md` с frontmatter
+`staging_status:` и смержить лог в `main` (`.openclaw/agents/deployer.md`, шаги 1–4).
+
+Это **avoidable LLM control path** по нормативной политике (`docs/architecture/llm-usage-policy.md`
+§3): (i) это C-консультация — её вердикт `staging_status:` потребляется гейтом
+`check_staging_status` (`src/qg/checks.py:599`), и (ii) вердикт **полностью деривируем** из
+exit-кода `staging_check.py`. Карта вызовов (`docs/architecture/llm-call-sites.md`, строка **A6**)
+классифицирует deployer как **`replace-deterministic-now`**, а roadmap
+(`docs/architecture/llm-determinization-roadmap.md`, машинный блок) ставит его **rank 1** с
+`first_slice = yes`, `hybrid_needed = no`. Эта задача — **первый срез** реализации того roadmap.
+
+**Боль / риск, который закрываем:**
+- **Недетерминизм в потоке управления.** Решение «advance или rollback» на `deploy-staging` зависит
+  от LLM-сессии (стоимость, латентность, риск галлюцинации команд), хотя сводится к одному exit-коду.
+- **Стоимость и латентность.** Каждый прогон deployer'а на staging тратит токены/время opus-агента
+  (оценка по `agent_runs`: deployer-строки ~40–120k токенов / 3–15 мин на прогон; точное число —
+  `GET /metrics`) ради действия, которое выполняется тремя shell-строками.
+- **Класс инцидентов «LLM принял решение, которое есть исполнение фиксированных команд + маппинг
+  результата»** — тот же RCA-трек, что ORCH-110/111/112/113/114/117.
+
+Установленные факты (не изобретать):
+- Пьюр-логика вердикта уже существует и юнит-тестируема: `src/staging_verdict.py::compute_staging_verdict`
+  (ORCH-061) считает infra-tolerant вердикт **внутри** `staging_check.py`; раннеру остаётся доверять
+  exit-коду (как уже делает LLM-deployer — `deployer.md` step 2).
+- Детерминированный прецедент замены агента уже работает: `launch_job` перехватывает зарезервированные
+  роли `deploy-finalizer` (D1, `src/agents/launcher.py:389`) и `post-deploy-monitor`
+  (D2, `:394`) **до `_spawn`** и исполняет их как no-LLM-джобы.
+- Прод-ребро `deploy` для self-hosting уже детерминировано (`src/self_deploy.py` Phase A/B/C,
+  ORCH-036) — LLM в критическом self-restart-пути нет. Срез не трогает критический прод-путь.
+
+## 2. Объём (scope)
+
+### В объёме (Phase 1)
+- **Детерминированный staging-раннер** для `deploy-staging` репо `orchestrator` (self-hosting):
+  исполняет staging-сюиту, маппит exit-код в `staging_status:`, пишет `15-staging-log.md`, мержит в
+  `main` — **без** запуска LLM-агента `deployer`.
+- Раннер активируется через **перехват в `launch_job` до `_spawn`** (прецедент D1/D2), **без правки
+  `src/stages.py`/`STAGE_TRANSITIONS`** (роль `deployer` в словаре остаётся; меняется лишь *кто*
+  обрабатывает джоб на стадии `deploy-staging` для in-scope репо).
+- После выпуска вердикта раннер инициирует **существующую** оценку exit-гейта `check_staging_status`
+  ровно так, как это делал завершившийся LLM-deployer (`_try_advance_stage` → `advance_stage(
+  finished_agent="deployer")`) — все нижестоящие под-гейты (security → merge → coverage →
+  image-freshness, ORCH-022/043/027/058) и Phase A (ORCH-036) ведут себя идентично.
+- Kill-switch + скоуп-CSV (паттерн ORCH-022/027/043/089/090): `*_enabled` (откат к LLM-пути) и
+  `*_repos` (пусто → self-hosting only).
+- Наблюдаемость: read-only блок в `GET /queue` + структурный лог вердикта.
+
+### Вне объёма (явно НЕ делаем в ORCH-115)
+- **Phase 2 — «project deploy contract» для не-self репо** (например `enduro-trails`): конфигурируемый
+  контракт deploy/rollback/healthcheck для произвольных репо. Описан как **forward-looking
+  follow-up** (см. §6 и `02-trz.md` §8); **в приёмку ORCH-115 не входит**. Для не-self репо
+  `deploy-staging` сейчас — мгновенный pass (`check_staging_status` → N/A, `src/qg/checks.py:620`),
+  поэтому Phase 1 их не затрагивает.
+- **Прод-ребро `deploy`** (Phase A/B/C self-deploy, ORCH-036) — уже детерминировано; не трогаем.
+- **LLM debug/triage-аналитик после детерминированного FAILED** — `replace-deterministic-now` без
+  гибрида (roadmap `hybrid_needed = no`). В этом срезе LLM на `deploy-staging` отсутствует и в
+  happy-path, и в fail-path; опциональный off-control-path debug-аналитик оставлен как будущее
+  улучшение и **требованиями не запрещён** (см. NFR-7).
+- **Любая правка `STAGE_TRANSITIONS` / реестра и имён `QG_CHECKS` / семантики `check_*` /
+  machine-verdict-ключей / схемы БД** (см. NFR-1).
+- **ORCH-112 (checkout hygiene) и ORCH-114 (transition lease)** — по явной границе задачи не
+  смешиваем: раннер вызывает `advance_stage`, который уже владеет lease ORCH-114; сам lease/гигиену
+  не модифицируем.
+
+## 3. Заинтересованные стороны
+
+- **Заказчик / Owner** (`homenet542@gmail.com`) — инициатор детерминизации LLM-control-path'ов.
+- **Платформа orchestrator (self-hosting)** — прямой потребитель: дешевле/быстрее/детерминированнее
+  собственный `deploy-staging`.
+- **Другие проекты на общем инстансе** (enduro-trails) — НЕ затронуты в Phase 1 (скоуп self-hosting),
+  выигрывают позже от Phase 2.
+- **Reviewer / Tester / Deployer-роли конвейера** — принимают результат через неизменные гейты.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 — Детерминированный staging без LLM.** На `deploy-staging` для in-scope репо вердикт
+  `staging_status:` производится детерминированным кодом (исполнение `staging_check.py` + маппинг
+  exit-кода), **без** консультации LLM. Happy-path `deploy-staging` не вызывает `_spawn`.
+- **BR-2 — Контракт артефакта неизменен.** Раннер пишет тот же `15-staging-log.md` с тем же
+  frontmatter-ключом `staging_status: SUCCESS|FAILED`, который читает `check_staging_status`/
+  `_parse_staging_status`. Гейт байт-в-байт не меняется.
+- **BR-3 — Эквивалентность маршрутизации.** SUCCESS → продвижение на `deploy` через те же под-гейты
+  и Phase A; FAILED → существующий откат `deploy-staging → development` (тот же путь, что у
+  FAILED-вердикта LLM-deployer'а, `src/stage_engine.py:932`). Никаких новых рёбер/исходов.
+- **BR-4 — Переиспользование существующей пьюр-логики.** Раннер использует уже существующий
+  exit-code→verdict маппинг (тривиальный `0→SUCCESS`/иначе`FAILED`, зеркало
+  `self_deploy.map_exit_code_to_status`); infra-tolerance (ORCH-061) остаётся **внутри**
+  `staging_check.py` — раннер ему доверяет, повторно не судит.
+- **BR-5 — Обратимость одним флагом.** Глобальный kill-switch возвращает прежний LLM-deployer-путь
+  на `deploy-staging` байт-в-байт; скоуп-CSV ограничивает раннер in-scope репо (пусто → только
+  `orchestrator`).
+- **BR-6 — Наблюдаемость.** Исход раннера (запущен / SUCCESS / FAILED / ошибка инструмента) виден в
+  `GET /queue` и в структурном логе; деградации (например staging-инстанс недоступен) различимы от
+  «код упал».
+- **BR-7 — Self-hosting safety.** Раннер на `deploy-staging` **никогда** не рестартит прод-контейнер
+  8500, не трогает `main` force-push'ем, не правит `.env`/`docker-compose.yml`. Он лишь читает,
+  исполняет staging-сюиту (порт 8501), пишет лог и мержит лог штатным PR/artifact-merge-путём.
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — Скоуп-инвариант (анти-дрейф).** `STAGE_TRANSITIONS` (`src/stages.py`), реестр и имена
+  `QG_CHECKS`/`check_*`/`_parse_*` (`src/qg/checks.py`), machine-verdict-ключи
+  (`staging_status:`/`deploy_status:`/`verdict:`/`result:`/`security_status:`/`coverage_status:`),
+  схема БД — **байт-в-байт не тронуты**. Это замена *продюсера* артефакта, не гейта.
+- **NFR-2 — never-raise / fail-safe.** Любая ошибка раннера (docker недоступен, таймаут, I/O) →
+  безопасный детерминированный исход без падения воркера: либо `FAILED` (fail-closed, никогда ложный
+  green), либо штатный requeue/defer — не «тихий advance». Сбой раннера не клинит очередь всех
+  проектов.
+- **NFR-3 — Изоляция процесса / таймаут.** Спавненный subprocess (`docker exec …`) имеет
+  ограниченный таймаут и чистое завершение дерева процессов (согласовано с прецедентом ORCH-110
+  `proc_group`/tree-kill); сирот pytest/docker не оставляет.
+- **NFR-4 — Сквозные бюджеты времени.** Таймаут раннера согласован со сквозным инвариантом
+  ORCH-065/109/110 (`reaper_max_running_s` > Σ(работ на ребре deploy-staging) + grace) — без правки
+  `reaper_max_running_s`.
+- **NFR-5 — Совместимость с не-self репо.** Для репо вне скоупа `deploy-staging` ведёт себя 1:1 как
+  до ORCH-115 (LLM-deployer либо мгновенный N/A-pass). enduro-trails не затронут.
+- **NFR-6 — Соответствие политике LLM.** Изменение снимает LLM-консультацию A6; карта
+  `docs/architecture/llm-call-sites.md` и политика/roadmap обновляются **в том же PR** (норматив
+  сопровождения ORCH-118): строка deployer переходит из «consults_llm: yes» в реализованное
+  детерминированное состояние.
+- **NFR-7 — Не запрещать будущий debug-fallback.** Архитектура раннера не должна архитектурно
+  исключать опциональный off-control-path LLM debug-аналитик после FAILED (будущее улучшение); но
+  в ORCH-115 он не реализуется.
+
+## 6. Допущения и ограничения
+
+- **Допущение А1.** staging-инстанс `orchestrator-staging` (8501) поднят и доступен на хосте; его
+  недоступность раннер трактует детерминированно (fail-closed `FAILED` или defer — решает архитектор,
+  AC-7).
+- **Допущение А2.** `scripts/staging_check.py` остаётся источником истины набора проверок и
+  exit-кода (включая infra-tolerance ORCH-061). ORCH-115 его логику не меняет.
+- **Допущение А3.** Перехват «до `_spawn`» по имени джоб-роли + стадии задачи — достаточный механизм
+  диспетчеризации (как D1/D2); конкретный механизм финализирует архитектор (06-adr).
+- **Ограничение О1.** Граница задачи: не смешивать с ORCH-112/ORCH-114 (их код не модифицируется).
+- **Ограничение О2.** Phase 2 (project deploy contract) — отдельный follow-up; ORCH-115 закрывает
+  только Phase 1.
+
+## 7. Критерии успеха
+
+`deploy-staging` для `orchestrator` проходит без запуска LLM-агента `deployer`: детерминированный
+раннер исполняет staging-сюиту, пишет корректный `15-staging-log.md` (`staging_status:`),
+мержит его в `main`, и конвейер продвигается/откатывается ровно как раньше — при неизменных
+`STAGE_TRANSITIONS`/`QG_CHECKS`/гейтах/схеме БД, под kill-switch с откатом к прежнему поведению.
+Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+
+Краткий перечень (детали — `10-tech-risks.md`, заполняет архитектор):
+- **R-1** — точка диспетчеризации «до `_spawn`» должна корректно отличать staging-deployer от
+  прод-deployer (по стадии задачи), иначе можно перехватить не тот джоб.
+- **R-2** — после выпуска вердикта нужно надёжно инициировать `advance_stage`, иначе задача зависнет
+  на `deploy-staging` (нет «финиша агента», который раньше триггерил гейт).
+- **R-3** — таймаут/изоляция docker-subprocess; утечка процессов (ср. инцидент ORCH-110).
+- **R-4** — взаимодействие с transition-lease (ORCH-114) и serial-gate (ORCH-088) на side-effectful
+  ребре — не сломать владение.
+- **R-5** — корректность отката FAILED (developer-retry cap) — должна совпасть с LLM-путём.

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

@@ -0,0 +1,158 @@
+---
+work_item: ORCH-115
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-115 — детерминированный staging-раннер вместо LLM-деплойера
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование (точный механизм перехвата, размещение раннера, способ инициации
+> `advance_stage`, лестница таймаутов) — задача архитектора (`06-adr/`). Здесь — требования и
+> привязка к реальным модулям `src/`.
+
+## 1. Сводка изменения
+
+Заменить **LLM-агента `deployer`** на стадии `deploy-staging` (для self-hosting `orchestrator`)
+**детерминированным staging-раннером**, перехватываемым в `launch_job` **до `_spawn`** (прецедент
+`deploy-finalizer`/`post-deploy-monitor`, `src/agents/launcher.py:389/394`). Раннер исполняет ту же
+staging-сюиту, что исполнял LLM (`docker exec orchestrator-staging python3
+scripts/staging_check.py …`), маппит exit-код в `staging_status:` (`0→SUCCESS`, иначе `FAILED`),
+пишет `15-staging-log.md`, best-effort мержит лог в `main`, затем инициирует **существующую** оценку
+exit-гейта `check_staging_status` ровно как завершившийся LLM-deployer. Контракт артефакта, гейт,
+`STAGE_TRANSITIONS`, схема БД — **неизменны**. Под kill-switch + скоуп-CSV; never-raise; fail-closed.
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие | Назначение |
+|------|----------|------------|
+| `src/staging_runner.py` *(новый leaf)* | создать | Детерминированный раннер: `applies(repo)` (kill-switch + скоуп), исполнение staging-сюиты, маппинг exit-кода, запись `15-staging-log.md`, best-effort merge, снапшот для `/queue`. Leaf-чистота по образцу `self_deploy.py`/`staging_verdict.py`: импортирует только `config`/`git_worktree` (+ лениво `qg.checks.is_self_hosting_repo`), never-raise. |
+| `src/agents/launcher.py` | изменить | В `launch_job` добавить перехват **до `_spawn`** (рядом с D1/D2): если джоб — `deployer` на стадии задачи `deploy-staging` и `staging_runner.applies(repo)` → исполнить раннер синхронно в воркер-треде, инициировать `advance_stage` и пометить джоб (как `_run_deploy_finalizer_job`); вернуть `None` (нет `agent_runs`-строки). |
+| `src/config.py` | изменить | Добавить ключи `staging_runner_enabled: bool = True` (env `ORCH_STAGING_RUNNER_ENABLED`) и `staging_runner_repos: str = ""` (env `ORCH_STAGING_RUNNER_REPOS`; пусто → self-hosting only) + опц. `staging_runner_timeout_s` (см. FR-5). Дефолты = боевое; паттерн `coverage_gate_enabled`/`coverage_gate_repos`/`self_deploy_*`. |
+| `src/stage_engine.py` | (потенциально) точечно | Если архитектор решит инициировать гейт из stage_engine, а не из launcher — добавить тонкий хелпер (вызов существующего `advance_stage(finished_agent="deployer")`). **Без** правки `STAGE_TRANSITIONS`/exit-гейтов. |
+| `src/main.py` (`GET /queue`) | изменить | Read-only блок `staging_runner` (флаг/скоуп/счётчики исходов) — наблюдаемость BR-6. |
+| `.openclaw/agents/deployer.md` | изменить (docs) | Отметить, что на `deploy-staging` для in-scope репо стадию ведёт детерминированный код (зеркало формулировки prod-Phase A/B/C); LLM-ветвь `deploy-staging` остаётся как fallback под выключенным флагом / для не-self репо. |
+| `docs/architecture/llm-call-sites.md`, `llm-determinization-roadmap.md`, `llm-usage-policy.md` | изменить (docs) | Норматив сопровождения ORCH-118 (NFR-6): отразить реализацию A6 (deployer staging-status) — обновить инвентарь/политику/roadmap в том же PR; синхронно поправить `tests/test_llm_call_site_inventory.py` / `tests/test_llm_determinization_docs.py`. |
+| `CLAUDE.md`, `CHANGELOG.md`, `docs/overview/` | изменить (docs) | Паспорт/чейнджлог/витрина — правило для агентов №2. |
+| `tests/test_orch115_staging_runner.py` *(новый)* | создать | Покрытие (см. `04-test-plan.yaml`). |
+
+> **Не трогать (NFR-1):** `src/stages.py::STAGE_TRANSITIONS`; имена/семантику `QG_CHECKS`/`check_*`/
+> `_parse_*` в `src/qg/checks.py`; `src/staging_verdict.py` (переиспользуем как есть); `src/self_deploy.py`
+> прод-путь; `src/transition_lease.py` (ORCH-114); `src/checkout_hygiene.py` (ORCH-112); схему БД.
+
+## 3. Функциональные требования
+
+### FR-1 — Детерминированный перехват на `deploy-staging` (без `_spawn`)
+В `launch_job` (`src/agents/launcher.py`) **до** вызова `_spawn`, по образцу D1/D2: если
+`job.agent == "deployer"` **и** стадия задачи (`tasks.stage` по `job.task_id`) == `deploy-staging`
+**и** `staging_runner.applies(job.repo)` истинно → не вызывать `_spawn`, а исполнить раннер
+синхронно. Контракт: возвращает `None` (нет `agent_runs`), сам ведёт `jobs`-строку
+(`mark_job(done|failed|queued)`) как `_run_deploy_finalizer_job`.
+- Дискриминатор «staging vs prod» — **стадия задачи**, не имя роли (роль `deployer` общая для
+  `deploy-staging` и `deploy`). Для self-hosting прод-ребро не запускает `deployer` (Phase A), поэтому
+  коллизии нет; гард по стадии — защита от перехвата не того джоба (R-1).
+- `applies(repo)`: `staging_runner_enabled=False` → `False` (откат к LLM-пути); непустой
+  `staging_runner_repos` → membership; пустой CSV → `is_self_hosting_repo(repo)`. Никакой сети,
+  проверяется **первым** (нулевой оверхед при выключенном флаге). Never-raise → `False` при ошибке
+  (fail-safe к прежнему LLM-пути).
+
+### FR-2 — Исполнение staging-сюиты
+Раннер исполняет ту же канонную команду, что исполнял LLM-deployer
+(`.openclaw/agents/deployer.md` step 1):
+`docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py
+--base-url http://localhost:8501 --mode stub` (точные аргументы/таргет — из config, не хардкодить
+host-специфику; ORCH-101). Захватывает exit-код (и stdout для observability/тела лога). infra-tolerance
+(ORCH-061) уже **внутри** `staging_check.py` → раннер вердикт повторно не судит (BR-4).
+
+### FR-3 — Маппинг exit-кода → `staging_status:`
+`0 → "SUCCESS"`, любой ненулевой / отсутствие кода / ошибка запуска → `"FAILED"` (fail-closed,
+никогда ложный green). Зеркало уже существующего `self_deploy.map_exit_code_to_status` (pure,
+unit-tested) — переиспользовать общий контракт, не плодить второй маппинг.
+
+### FR-4 — Запись и merge `15-staging-log.md`
+Раннер пишет `docs/work-items/<work_item_id>/15-staging-log.md` в worktree фичеветки с frontmatter:
+`staging_status: SUCCESS|FAILED` + обязательная 52c-схема (`work_item`/`stage=deploy-staging`/
+`author_agent`/`status`/`created_at`/`model_used`) — зеркало `self_deploy.build_deploy_log` для
+`14-deploy-log.md`. `author_agent`/`model_used` отражают **детерминированный** продюсер (например
+`author_agent: staging-runner`, `model_used: n/a` или платформенный литерал — финализирует архитектор;
+ключи и имя `staging_status:` не меняются). При INFRA-WAIVED-строке от `staging_check.py` — скопировать
+её в тело (observability, как требовал prompt). Best-effort `git add/commit/push` лога в `main`
+(зеркало `self_deploy.write_deploy_log`, тот же git-identity-паттерн ORCH-101); гейт всё равно
+читает worktree → origin/main fallback (`check_staging_status` lookup order, `src/qg/checks.py:627-638`).
+
+### FR-5 — Инициация существующего гейта после вердикта
+После записи (и best-effort merge) раннер инициирует ту же оценку exit-гейта, что триггерил
+завершившийся LLM-deployer: `advance_stage(task_id, current_stage="deploy-staging", repo,
+work_item_id, branch, finished_agent="deployer")` (через `_try_advance_stage`-эквивалент). Это
+запускает `check_staging_status` и — на SUCCESS — под-гейты security→merge→coverage→image-freshness
+(ORCH-022/043/027/058) и Phase A (ORCH-036); на FAILED — существующий rollback
+(`src/stage_engine.py:932`). **Никакой новой ветви маршрутизации.** Lease ORCH-114 берётся внутри
+`advance_stage` как сейчас — раннер его не трогает (граница задачи).
+- Таймаут раннер-subprocess — выделенный ключ `staging_runner_timeout_s` с дефолтом, согласованным
+  со сквозным бюджетом ORCH-065/109/110 (NFR-4); малформ/непозитив → дефолт + WARNING (never-break).
+
+### FR-6 — Kill-switch и скоуп (обратимость)
+`staging_runner_enabled=False` → перехват не срабатывает → на `deploy-staging` запускается прежний
+LLM-deployer (`_spawn`) **байт-в-байт** как до ORCH-115. `staging_runner_repos` ограничивает скоуп
+(пусто → только `orchestrator`); не-self репо никогда не перехватываются (для них staging-гейт и так
+N/A, `src/qg/checks.py:620`).
+
+### FR-7 — Наблюдаемость
+- Read-only блок `staging_runner` в `GET /queue`: `enabled`, `repos`, счётчики `success`/`failed`/
+  `tool_error`/`runs`.
+- Один структурный лог-вердикт на прогон (`work_item`/`repo`/`exit_code`/`status`/`duration_s`),
+  различающий «код упал» (`FAILED` от staging-сюиты) и «инструмент недоступен» (tool-error).
+
+## 4. Изменения API
+
+- **`GET /queue`** — добавить read-only ключ `staging_runner` (наблюдаемость). Существующие поля
+  ответа не меняются.
+- Опционально (на усмотрение архитектора, по образцу `POST /coverage/baseline`): нет обязательного
+  нового мутирующего эндпоинта. Откат — через env-флаг.
+- Новых вебхуков нет.
+
+## 5. Изменения схемы БД
+
+**Нет.** Раннер использует существующие таблицы (`tasks` для стадии, `jobs` для статуса джоба) и
+sentinel/worktree-механику. Никаких новых таблиц/колонок/миграций (NFR-1). Счётчики `/queue` —
+in-process (паттерн `_MERGE_GATE_COUNTERS`, ORCH-110), не БД.
+
+## 6. Требования к новым/изменённым QG checks
+
+**Нет новых QG и нет изменений существующих.** `check_staging_status` / `_parse_staging_status` /
+ключ `staging_status:` (`src/qg/checks.py:538/599`) и состав `QG_CHECKS` — **байт-в-байт неизменны**.
+ORCH-115 меняет только *продюсера* `15-staging-log.md` (детерминированный код вместо LLM); гейт,
+читающий артефакт, остаётся прежним. Это критический инвариант (NFR-1) — reviewer ловит любое
+изменение имени/семантики гейта как finding ≥P1.
+
+## 7. Совместимость / регресс
+
+- **Обратная совместимость:** `staging_runner_enabled=False` → прежний LLM-deployer-путь
+  байт-в-байт; не-self репо → 1:1 (N/A-pass либо LLM, в зависимости от скоупа). enduro-trails не
+  затронут (NFR-5).
+- **Kill-switch / область раската:** один флаг `staging_runner_enabled` + CSV `staging_runner_repos`
+  (пусто → self-hosting only). Откат = `ORCH_STAGING_RUNNER_ENABLED=false`.
+- **Обратимость:** полностью обратимо флагом; артефакт и гейт неизменны, так что переключение туда-сюда
+  не оставляет несовместимого состояния.
+- **never-raise / fail-safe (NFR-2):** ошибка раннера → `FAILED` (fail-closed) или штатный requeue,
+  не «тихий advance»; сбой не клинит очередь. Self-hosting safety (BR-7): никаких рестартов 8500 /
+  force-push в `main` / правок инфры.
+- **Граница (О1):** код ORCH-112 (checkout hygiene) и ORCH-114 (transition lease) не модифицируется.
+- **Норматив сопровождения (NFR-6):** в том же PR обновить `docs/architecture/llm-call-sites.md` /
+  `llm-determinization-roadmap.md` / `llm-usage-policy.md` + соответствующие анти-дрейф тесты;
+  `CLAUDE.md` / `CHANGELOG.md` / `docs/overview/`.
+
+## 8. Phase 2 (forward-looking, вне приёмки ORCH-115)
+
+Зафиксировано для преемственности — **не реализуется в этой задаче**, заводится отдельным follow-up:
+- **Project deploy contract** для не-self репо (enduro-trails): декларативный per-repo контракт
+  `deploy` / `rollback` / `healthcheck` (команды + ожидаемые коды/эндпоинты), исполняемый тем же
+  детерминированным раннер-паттерном (run → map exit code → verdict → artifact → healthcheck).
+- LLM остаётся допустим только как **off-control-path** debug/triage-аналитик после
+  детерминированного провала (NFR-7) — не как продюсер вердикта.
+- Зависимость: устойчивый Phase 1 (этот work item) как доказанный паттерн перехвата + маппинга.

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

@@ -0,0 +1,166 @@
+---
+work_item: ORCH-115
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-115 — детерминированный staging-раннер
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — Детерминированный перехват на `deploy-staging` (нет `_spawn`/LLM)
+
+**Условие:** При включённом флаге и in-scope репо джоб `deployer` на стадии `deploy-staging`
+обрабатывается раннером, а не LLM-агентом.
+- **PASS:** `launch_job` (`src/agents/launcher.py`) перехватывает джоб **до** `_spawn` (рядом с
+  D1/D2) при `agent=="deployer"` + стадия задачи `deploy-staging` + `staging_runner.applies(repo)`;
+  `_spawn` не вызывается; не создаётся строка `agent_runs`; джоб ведётся `mark_job(...)` самим
+  раннером. Тест воспроизводит это без живого Claude CLI.
+- **FAIL:** На `deploy-staging` для in-scope репо при включённом флаге всё ещё вызывается `_spawn` /
+  создаётся `agent_runs`-строка LLM-deployer'а.
+
+---
+
+## AC-2 — Контракт артефакта `15-staging-log.md` неизменен
+
+**Условие:** Раннер пишет тот же артефакт с тем же machine-key, что читает гейт.
+- **PASS:** Создаётся `docs/work-items/<work_item_id>/15-staging-log.md` с frontmatter
+  `staging_status: SUCCESS|FAILED` (UPPERCASE) + обязательная 52c-схема
+  (`work_item`/`stage: deploy-staging`/`author_agent`/`status`/`created_at`/`model_used`).
+  `_parse_staging_status` читает его и возвращает корректный вердикт **без изменения** парсера.
+- **FAIL:** Изменено имя/регистр ключа `staging_status:`, отсутствует frontmatter, либо вердикт
+  записан только прозой; либо парсер `_parse_staging_status` пришлось менять.
+
+---
+
+## AC-3 — Корректный exit-code → verdict маппинг
+
+**Условие:** Exit-код staging-сюиты детерминированно маппится в вердикт.
+- **PASS:** `0 → SUCCESS`; любой ненулевой / None / ошибка запуска → `FAILED` (fail-closed).
+  Маппинг — pure-функция, переиспользующая контракт `self_deploy.map_exit_code_to_status` (или
+  эквивалентный единый), покрыта unit-тестом на каждый класс входа. infra-tolerance (ORCH-061) не
+  пересуживается раннером.
+- **FAIL:** Ненулевой код даёт `SUCCESS`; ошибка/None даёт `SUCCESS` (ложный green); раннер вводит
+  второй несогласованный маппинг.
+
+---
+
+## AC-4 — Эквивалентность маршрутизации (SUCCESS / FAILED)
+
+**Условие:** После вердикта конвейер ведёт себя ровно как при завершившемся LLM-deployer'е.
+- **PASS:** SUCCESS → раннер инициирует `advance_stage(finished_agent="deployer")`, далее
+  отрабатывают под-гейты security→merge→coverage→image-freshness (ORCH-022/043/027/058) и Phase A
+  (ORCH-036) — теми же путями. FAILED → существующий откат `deploy-staging → development` с
+  инкрементом developer-retry (`src/stage_engine.py:932`), тот же исход, что у FAILED-вердикта LLM.
+- **FAIL:** Задача зависает на `deploy-staging` (гейт не инициирован); или FAILED не откатывает /
+  откатывает иначе; или появляется новое ребро/исход.
+
+---
+
+## AC-5 — Инвариант скоупа: гейты/стадии/схема БД не тронуты (анти-дрейф)
+
+**Условие:** Изменена только сторона *продюсера*, не контракт конвейера.
+- **PASS:** `git diff` не затрагивает `src/stages.py::STAGE_TRANSITIONS`; имена/семантику
+  `QG_CHECKS`/`check_*`/`_parse_*` в `src/qg/checks.py`; machine-verdict-ключи
+  (`staging_status:`/`deploy_status:`/`verdict:`/`result:`/`security_status:`/`coverage_status:`);
+  схему БД (нет новых таблиц/колонок/миграций). Анти-дрейф-тест это подтверждает.
+- **FAIL:** Любой из перечисленных артефактов изменён по имени/семантике/структуре.
+
+---
+
+## AC-6 — Kill-switch и скоуп (обратимость)
+
+**Условие:** Флаг возвращает прежнее поведение; скоуп ограничивает раннер.
+- **PASS:** `staging_runner_enabled=False` → на `deploy-staging` запускается прежний LLM-deployer
+  через `_spawn` (байт-в-байт до ORCH-115). Пустой `staging_runner_repos` → раннер активен только для
+  `orchestrator`; не-self репо никогда не перехватываются. Покрыто тестом для обоих значений флага.
+- **FAIL:** При выключенном флаге раннер всё равно перехватывает; либо не-self репо перехватывается.
+
+---
+
+## AC-7 — never-raise / fail-safe (инструмент недоступен)
+
+**Условие:** Любая ошибка раннера приводит к безопасному детерминированному исходу.
+- **PASS:** Недоступность docker/`orchestrator-staging`, таймаут, I/O-ошибка → раннер не роняет
+  воркер; исход — `FAILED` (fail-closed) **или** штатный requeue/defer, **никогда** тихий advance/
+  ложный green. Все публичные функции `staging_runner.py` — never-raise; `applies()` при ошибке → `False`.
+- **FAIL:** Ошибка раннера роняет воркер/клинит очередь; либо ошибка/таймаут даёт `SUCCESS`.
+
+---
+
+## AC-8 — Self-hosting safety
+
+**Условие:** Раннер на `deploy-staging` не выполняет опасных для прода действий.
+- **PASS:** Раннер не рестартит контейнер 8500, не выполняет `docker compose up -d orchestrator`/
+  `--build`, не пушит force в `main`, не правит `.env`/`.env.staging`/`docker-compose.yml`. Merge
+  лога идёт штатным PR/artifact-merge-путём (как `self_deploy.write_deploy_log`). Подтверждается
+  ревью кода раннера + (где применимо) тестом, что в командах раннера нет запрещённых литералов.
+- **FAIL:** Раннер содержит любой путь, рестартящий 8500 / force-push в `main` / правящий инфру.
+
+---
+
+## AC-9 — Изоляция процесса и таймаут
+
+**Условие:** docker-subprocess ограничен по времени и не оставляет сирот.
+- **PASS:** Раннер запускает staging-сюиту с ограниченным таймаутом
+  (`staging_runner_timeout_s`, согласован со сквозным бюджетом ORCH-065/109/110, не правя
+  `reaper_max_running_s`); малформ/непозитив таймаут → дефолт + WARNING; завершение чистое (без
+  осиротевших docker/pytest-процессов, согласовано с `proc_group`/tree-kill ORCH-110).
+- **FAIL:** Нет таймаута / зависший subprocess клинит воркер; остаются сироты процессов.
+
+---
+
+## AC-10 — Наблюдаемость
+
+**Условие:** Исход раннера виден и различим.
+- **PASS:** `GET /queue` содержит read-only блок `staging_runner` (`enabled`/`repos`/счётчики
+  `success`/`failed`/`tool_error`/`runs`); на каждый прогон — один структурный лог-вердикт
+  (`work_item`/`repo`/`exit_code`/`status`/`duration_s`), различающий код-фейл и tool-error.
+- **FAIL:** Нет блока в `/queue`; исход раннера не логируется/не различим.
+
+---
+
+## AC-11 — Норматив сопровождения LLM-карты/политики/витрины
+
+**Условие:** Документация обновлена в том же PR (правило агентов №2 + норматив ORCH-118).
+- **PASS:** `docs/architecture/llm-call-sites.md` (строка A6) / `llm-determinization-roadmap.md` /
+  `llm-usage-policy.md` отражают реализацию детерминированного deployer-staging; соответствующие
+  анти-дрейф-тесты (`tests/test_llm_call_site_inventory.py`, `tests/test_llm_determinization_docs.py`)
+  зелёные; `.openclaw/agents/deployer.md`, `CLAUDE.md`, `CHANGELOG.md`, `docs/overview/` обновлены.
+- **FAIL:** Карта/политика/roadmap/витрина не обновлены; анти-дрейф-тесты красные (reviewer: ≥P1).
+
+---
+
+## AC-12 — Полный регресс зелёный
+
+**Условие:** Существующий конвейер не сломан.
+- **PASS:** `pytest tests/ -q` зелёный; новый `tests/test_orch115_staging_runner.py` зелёный;
+  staging-smoke (`scripts/staging_check.py`) на 8501 проходит штатно.
+- **FAIL:** Любой ранее зелёный тест становится красным; новые тесты падают.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-4 |
+| AC-3 | BR-4 / FR-2 / FR-3 |
+| AC-4 | BR-3 / FR-5 |
+| AC-5 | NFR-1 / FR-6 |
+| AC-6 | BR-5 / FR-6 |
+| AC-7 | NFR-2 / FR-1 |
+| AC-8 | BR-7 |
+| AC-9 | NFR-3 / NFR-4 / FR-5 |
+| AC-10 | BR-6 / FR-7 |
+| AC-11 | NFR-6 |
+| AC-12 | NFR-5 / NFR-1 |

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

@@ -0,0 +1,104 @@
+work_item: ORCH-115
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+title: "Детерминированный staging-раннер вместо LLM-деплойера (deploy-staging)"
+framework: pytest
+scope: >
+  Покрывает Phase 1: перехват deployer-джоба на deploy-staging до _spawn, маппинг
+  exit-кода в staging_status:, запись/merge 15-staging-log.md, инициацию существующего
+  гейта check_staging_status, kill-switch/скоуп, never-raise/fail-safe, изоляцию
+  процесса/таймаут, наблюдаемость, и анти-дрейф инвариант (STAGE_TRANSITIONS/QG_CHECKS/
+  схема БД не тронуты). Вне покрытия: Phase 2 (project deploy contract для не-self репо),
+  прод-ребро deploy (ORCH-036), живой Claude CLI и живой staging-стенд (мокируются).
+notes: >
+  Тесты не требуют живого Claude CLI, docker или сети: subprocess/docker-exec и
+  advance_stage мокируются; пьюр-маппинг тестируется напрямую. Полный регресс tests/
+  должен оставаться зелёным. Анти-дрейф (TC-09) защищает критический инвариант NFR-1.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "applies(repo): enabled=False -> False (откат к LLM); пустой CSV -> True только для orchestrator; непустой CSV -> membership; not-self репо -> False; ошибка -> False (never-raise, fail-safe)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Маппинг exit-кода: 0 -> SUCCESS; 1/2/любой ненулевой -> FAILED; None/нечисло/ошибка запуска -> FAILED (fail-closed). Согласован с self_deploy.map_exit_code_to_status."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Рендер 15-staging-log.md: frontmatter содержит staging_status: SUCCESS|FAILED (UPPERCASE) + 52c-схему (work_item/stage=deploy-staging/author_agent/status/created_at/model_used); INFRA-WAIVED строка из stdout копируется в тело."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Сгенерированный раннером 15-staging-log.md читается НЕИЗМЕНЁННЫМ _parse_staging_status -> корректный (bool, reason) для SUCCESS и FAILED (контракт артефакта/гейта неизменен)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-05
+    type: integration
+    description: "launch_job перехватывает deployer-джоб на стадии deploy-staging для in-scope репо ДО _spawn (как D1/D2): _spawn НЕ вызывается, agent_runs не создаётся, возвращается None, jobs-строка ведётся mark_job. _spawn мокирован."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-06
+    type: integration
+    description: "Дискриминатор стадии: deployer-джоб на стадии deploy (не deploy-staging) НЕ перехватывается раннером (для self-hosting прод-ребро идёт через Phase A; для не-self остаётся прежний путь)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "После SUCCESS-вердикта раннер инициирует advance_stage(finished_agent='deployer') ровно как завершившийся LLM-deployer (advance_stage мокирован/наблюдается); после FAILED — тот же путь, что у FAILED LLM (откат deploy-staging -> development)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "Kill-switch: staging_runner_enabled=False -> на deploy-staging для orchestrator вызывается _spawn (прежний LLM-путь байт-в-байт), раннер не активируется."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Анти-дрейф NFR-1: STAGE_TRANSITIONS (src/stages.py) и реестр/имена QG_CHECKS + ключ staging_status: неизменны; в схеме БД нет новой таблицы/колонки от ORCH-115. Структурная проверка."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "never-raise/fail-safe: docker exec бросает/таймаутит/возвращает ненулевой -> раннер не падает, исход FAILED (fail-closed) или штатный requeue, никогда тихий advance/ложный green; воркер/очередь не клинятся."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Таймаут: staging_runner_timeout_s применяется к subprocess; малформ/непозитив -> дефолт + WARNING (never-break); завершение чистое (tree-kill согласован с proc_group ORCH-110)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "Self-hosting safety: в командной строке раннера нет запрещённых литералов (рестарт 8500 / docker compose up orchestrator / --build / force-push main / правки .env)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-13
+    type: integration
+    description: "Наблюдаемость: GET /queue содержит блок staging_runner (enabled/repos/счётчики success/failed/tool_error/runs); на прогон пишется один структурный лог-вердикт, различающий код-фейл и tool-error."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS
+
+  - id: TC-14
+    type: integration
+    description: "Анти-дрейф LLM-карты: llm-call-sites.md (A6)/roadmap/policy обновлены под реализацию; tests/test_llm_call_site_inventory.py и tests/test_llm_determinization_docs.py остаются зелёными после правок."
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS

docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md

@@ -0,0 +1,335 @@
+---
+work_item: ORCH-115
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Детерминированный staging-раннер вместо LLM-деплойера на `deploy-staging`
+
+Work Item: **ORCH-115** — заменить LLM-агента `deployer` на стадии `deploy-staging`
+(self-hosting `orchestrator`) детерминированным staging-раннером.
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0048-deterministic-staging-runner.md`**
+(решение кросс-каттинговое — вводит новый компонент-leaf и реализует первый срез
+determinization-roadmap; влияет на карту LLM-консультаций всего оркестратора).
+
+## Статус
+Proposed
+
+## Контекст
+
+Стадию `deploy-staging` сейчас исполняет **LLM-агент `deployer`** (`src/stages.py`:
+`get_agent_for_stage("testing") = "deployer"`; роль в `launcher.AGENTS`). Фактическая
+работа агента на этой стадии — **чисто детерминированная** (`.openclaw/agents/deployer.md`
+шаги 1–4):
+
+1. запустить staging-сюиту — `docker exec orchestrator-staging python3
+   /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`;
+2. смаппить **exit-код** в вердикт (`0 → SUCCESS`, ≠0 → `FAILED`) — infra-tolerance
+   ORCH-061 уже **внутри** `staging_check.py` (`src/staging_verdict.py::compute_staging_verdict`),
+   агент её не пересуживает;
+3. записать `15-staging-log.md` с frontmatter `staging_status:`;
+4. закоммитить лог.
+
+Вердикт `staging_status:` потребляется детерминированным гейтом `check_staging_status`
+(`src/qg/checks.py:599` → `_parse_staging_status:538`). По нормативной политике
+(`docs/architecture/llm-usage-policy.md` §3) это **avoidable LLM control path**: (i) это
+C-консультация (LLM-вердикт ветвит гейт) **и** (ii) вердикт **деривируем** из exit-кода
+инструмента, который оркестратор уже умеет вычислять сам. Карта call-site'ов
+(`docs/architecture/llm-call-sites.md`, строка **A6**) классифицирует deployer как
+`replace-deterministic-now`; roadmap (`llm-determinization-roadmap.md`, rank 1,
+`first_slice = yes`, `hybrid_needed = no`) ставит его первым срезом. ORCH-115 — реализация
+этого среза.
+
+**Установленные факты (сверено по коду, не изобретать):**
+- Детерминированный прецедент замены агента уже работает: `launch_job` перехватывает
+  зарезервированные роли `deploy-finalizer` (D1, `src/agents/launcher.py:389`) и
+  `post-deploy-monitor` (D2, `:394`) **до `_spawn`** и исполняет их как no-LLM-джобы,
+  сами ведущие `jobs`-строку через `mark_job`.
+- Эталонный поток «детерминированный джоб → вердикт → существующий контракт»:
+  `stage_engine.run_deploy_finalizer` (`:2010`) маппит exit-код, пишет `14-deploy-log.md`
+  и вызывает `advance_stage(..., finished_agent="deployer")`, после чего срабатывают
+  **существующие** контракты (`SUCCESS → done`/advance, `FAILED → откат на development`).
+- Пьюр-маппинг exit-кода уже есть: `self_deploy.map_exit_code_to_status` (`:81`,
+  `0→SUCCESS`, иначе/None/нечисло→`FAILED`, fail-closed, unit-tested).
+- Tree-kill subprocess'а под таймаутом уже есть: `proc_group.run_in_process_group`
+  (ORCH-110, stdlib-only leaf, never-raise, fallback к `subprocess.run`).
+- Прод-ребро `deploy` для self-hosting уже детерминировано (`self_deploy` Phase A/B/C,
+  ORCH-036) — `deployer` там **не спавнится** (Phase A — `finished_agent is None`-путь).
+  Срез не трогает критический прод-путь.
+
+«Как есть» не годится: каждый прогон тратит токены/время opus-агента (по `agent_runs`:
+~40–120k / 3–15 мин на прогон) ради действия в три shell-строки, встраивает недетерминизм
+LLM в точку ветвления и принадлежит к RCA-классу «LLM принял решение, которое есть
+исполнение фиксированных команд + маппинг результата» (ORCH-110/111/112/113/114/117).
+
+## Решение
+
+### Сводка
+
+Ввести **новый leaf `src/staging_runner.py`** (never-raise, по образцу
+`self_deploy.py`/`proc_group.py`/`staging_verdict.py`) и **перехват в `launch_job` до
+`_spawn`** (рядом с D1/D2). Когда на стадии `deploy-staging` для in-scope репо к запуску
+приходит джоб `deployer`, его обрабатывает раннер: исполняет ту же staging-сюиту через
+`proc_group`, маппит exit-код в `staging_status:`, пишет `15-staging-log.md`, и вызывает
+**существующий** `advance_stage(current_stage="deploy-staging", finished_agent="deployer")`
+— ровно как завершившийся LLM-deployer. Контракт артефакта, гейт `check_staging_status`,
+`STAGE_TRANSITIONS`, схема БД — **байт-в-байт неизменны** (это замена *продюсера*
+артефакта, не гейта). Под kill-switch + скоуп-CSV; fail-safe к прежнему LLM-пути.
+
+### D1 — Точка диспетчеризации: перехват в `launch_job` **до** `_spawn` (FR-1 / AC-1)
+
+В `launcher.launch_job`, рядом с существующими врезками D1/D2, **до** `_spawn`:
+
+```python
+if job.get("agent") == "deployer" and staging_runner.should_intercept(job):
+    return self._run_staging_runner_job(job)
+```
+
+- **Дискриминатор «staging vs prod» — стадия задачи, НЕ имя роли** (роль `deployer` общая
+  для `deploy-staging` и `deploy`). `should_intercept(job)` истинно ⇔ `agent=="deployer"`
+  **И** `tasks.stage` (по `job["task_id"]`) `== "deploy-staging"` **И**
+  `staging_runner.applies(job["repo"])`. Гард по стадии — защита от перехвата не того джоба
+  (R-1): для self-hosting прод-ребро `deployer` не запускает; для не-self репо прод-`deploy`
+  запускает синхронный ssh-deployer — но там `applies==False`, поэтому не перехватывается
+  (NFR-5; TC-06).
+- `should_intercept` — **never-raise**: любая ошибка (DB-lookup упал) → `False` → провал
+  в `_spawn` (fail-safe к прежнему LLM-пути).
+- `_run_staging_runner_job(job)` — тонкая обёртка-зеркало `_run_deploy_finalizer_job`
+  (`:404`): синхронно зовёт `staging_runner.run_staging_gate(job)`, затем
+  `mark_job(job["id"], "done")`; любое исключение → `mark_job(..., "failed", error=…)`;
+  возвращает `None` (нет `agent_runs`-строки, `_spawn` не вызывается).
+
+### D2 — Размещение логики: чистый leaf `src/staging_runner.py` (зеркало finalizer)
+
+`run_staging_gate(job)` живёт в leaf'е и владеет полным детерминированным потоком
+(зеркало `stage_engine.run_deploy_finalizer`):
+1. поднять `work_item_id`/`branch`/`stage` по `task_id`;
+2. исполнить staging-сюиту (D3) → `(returncode, timed_out, stdout)`;
+3. определить исход (D5);
+4. на verdict-исходе: записать `15-staging-log.md` (D6) и вызвать
+   `advance_stage(finished_agent="deployer")` (D7);
+5. на defer-исходе: requeue (D5);
+6. учесть счётчики + структурный лог (D10).
+
+**Чистота leaf'а:** импортирует на уровне модуля только `config`, `logging` (+ `proc_group`);
+лениво (внутри функций) — `db`/`git_worktree`/`self_deploy.map_exit_code_to_status`/
+`qg.checks.is_self_hosting_repo`/`stage_engine.advance_stage`/`notifications`. Лениво —
+чтобы не тащить тяжёлый `stage_engine` на импорте и не плодить цикл (паттерн
+`transition_lease`/`merge_gate`). Все публичные функции — **never-raise** (AC-7).
+
+### D3 — Исполнение сюиты: `proc_group` + config-арги (FR-2 / NFR-3 / AC-9 / AC-8)
+
+Команда строится из конфига (ORCH-101, без host-хардкодов — анти-дрейф
+`tests/test_no_host_hardcodes.py`):
+
+```
+docker exec <STAGING_SERVICE> python3 <repos_dir>/<SELF_HOSTING_REPO>/scripts/staging_check.py \
+    --base-url http://localhost:<staging_port> --mode stub
+```
+где `STAGING_SERVICE = "orchestrator-staging"` (платформенный сервис-литерал, уже допущен —
+ср. `image_freshness._STAGING_SERVICE:68`), `repos_dir`/`staging_port` из `settings`,
+`SELF_HOSTING_REPO` из `qg.checks`. Запуск — через
+`proc_group.run_in_process_group(argv, cwd=None, timeout=<staging_runner_timeout_s>,
+tree_kill=settings.subprocess_tree_kill_enabled)` → SIGTERM→grace→SIGKILL всего дерева на
+таймауте, без сирот docker/pytest (согласовано с ORCH-110). **Self-hosting safety
+(BR-7/AC-8):** в argv нет литералов рестарта 8500 / `docker compose up … orchestrator` /
+`--build` / force-push / правок `.env` — раннер только читает и исполняет staging-сюиту
+(8501) и пишет лог. Покрывается TC-12 (запрет литералов).
+
+### D4 — Маппинг exit-кода: переиспользовать единый контракт (FR-3 / AC-3)
+
+`staging_status` = `self_deploy.map_exit_code_to_status(returncode)` (`0→SUCCESS`, иначе/
+None/нечисло→`FAILED`, fail-closed). **Второй маппинг не вводится** — общий пьюр-контракт,
+уже покрытый unit-тестом. infra-tolerance ORCH-061 остаётся внутри `staging_check.py` —
+раннер вердикт повторно не судит (BR-4).
+
+### D5 — Двухуровневый исход: verdict vs tool-error (NFR-2 / AC-7 / R-3 / R-5) — **ключевое решение**
+
+`AC-7`/`NFR-2`/A1 явно оставляют обработку «инструмент недоступен» архитектору, разрешая
+**FAILED (fail-closed) ИЛИ штатный requeue/defer**. Выбран **двухуровневый исход**:
+
+- **Сюита ИСПОЛНИЛАСЬ (получен реальный exit-код, 0 или ≠0):** доверяем коду.
+  `0 → SUCCESS → advance`; `≠0 → FAILED → откат deploy-staging → development` через
+  `advance_stage` (тот же путь и developer-retry-cap, что у FAILED-вердикта LLM —
+  `stage_engine.py:932`; R-5/AC-4). ORCH-061 уже внутри exit-кода.
+- **Сюита НЕ исполнилась (tool-error: spawn-error / таймаут / `returncode is None`):**
+  это **инфра-сбой, а не код-фейл**. Раннер делает **ограниченный DEFER** — requeue
+  свежего `deployer`-джоба с задержкой и маркером в `task_content` (restart-safe счётчик
+  подсчётом маркера — зеркало `merge_gate._merge_infra_retry_count` ORCH-110 и
+  `_deploy_finalize_defer_count` ORCH-036; **без правки схемы БД**, NFR-1). На
+  **исчерпании** бюджета (`staging_runner_infra_max_retries`) — **fail-closed**: записать
+  `staging_status: FAILED` + `advance_stage` (откат) + alert (кликабельный номер). Так
+  раннер **никогда не делает тихий advance / ложный green** и **никогда не клинит очередь
+  навсегда**, но **не жжёт developer-retry на транзиентной инфре**.
+
+**Почему не «tool-error → немедленный FAILED-откат»:** это в точности анти-паттерн ORCH-110
+(инфра-таймаут, ошибочно маршрутизированный как код-фейл → откат на `development` + расход
+developer-retry; на следующем retry падает так же → ручное вмешательство). RCA-осведомлённый
+reviewer ловит это как регресс. Пьюр-маппинг D4 остаётся fail-closed (None→FAILED) — он
+терминальный fallback на исчерпании defer, а не реакция на первый же tool-error.
+
+### D6 — Артефакт `15-staging-log.md`: зеркало `write_deploy_log` (FR-4 / AC-2 / AC-8)
+
+Раннер пишет `docs/work-items/<work_item_id>/15-staging-log.md` в worktree фичеветки
+(`git_worktree.get_worktree_path`) с frontmatter:
+
+```markdown
+---
+staging_status: SUCCESS        # или FAILED — UPPERCASE, имя/регистр ключа не меняются
+work_item: <work_item_id>
+stage: deploy-staging
+author_agent: staging-runner
+status: success                # или failed — выровнен по staging_status
+created_at: <YYYY-MM-DD>
+model_used: n/a
+timestamp: <ISO>
+base_url: http://localhost:<staging_port>
+exit_code: <returncode>
+---
+
+# Staging Gate Log (deterministic runner, ORCH-115)
+<exit-код, краткий хвост stdout; строку `INFRA-WAIVED:` из stdout скопировать в тело для observability>
+```
+
+- `author_agent: staging-runner` / `model_used: n/a` честно отражают **детерминированного**
+  продюсера; **machine-key `staging_status:` и его регистр/значения не меняются** (AC-2/AC-5),
+  читается неизменённым `_parse_staging_status` (TC-04).
+- Запись через `frontmatter.render/write_frontmatter` либо литералом — обязательная 52c-схема
+  присутствует.
+- **Best-effort commit+push в ФИЧЕВЕТКУ** (зеркало `write_deploy_log` — git-identity
+  ORCH-101, `_GIT_TIMEOUT`). Гейт читает worktree **первым** (`check_staging_status` lookup
+  order, `:627`), поэтому отдельный PR-merge лога в `main` **не выполняется** — это
+  сознательное упрощение относительно шага-4 LLM-deployer'а: исключает любую прямую работу с
+  `main` (усиливает AC-8/BR-7). Итоговый мерж фичеветки в `main` идёт штатным
+  merge-gate/merge-verify-путём позже.
+
+### D7 — Инициация существующего гейта (FR-5 / AC-4 / R-2 / R-4, граница O1)
+
+После записи лога раннер вызывает:
+```python
+advance_stage(task_id, current_stage="deploy-staging", repo, work_item_id, branch,
+              finished_agent="deployer")
+```
+Это запускает `check_staging_status` и — на SUCCESS — существующие под-гейты
+security→merge→coverage→image-freshness (ORCH-022/043/027/058) и Phase A (ORCH-036); на
+FAILED — существующий откат (`stage_engine.py:932`). **Никакой новой ветви маршрутизации,
+никаких новых рёбер/исходов** (AC-4). **Граница O1/R-4:** transition-lease ORCH-114
+берётся **внутри** `advance_stage` на side-effectful ребре — раннер его **не трогает**;
+serial-gate ORCH-088 не взаимодействует (гейтит analyst-job claim, не deployer-job).
+Код ORCH-112/ORCH-114 не модифицируется.
+
+### D8 — Kill-switch и скоуп: обратимость (FR-6 / AC-6 / BR-5)
+
+`config.py` (паттерн `coverage_gate_*`/`self_deploy_*`):
+- `staging_runner_enabled: bool = True` (env `ORCH_STAGING_RUNNER_ENABLED`).
+- `staging_runner_repos: str = ""` (env `ORCH_STAGING_RUNNER_REPOS`; CSV; **пусто →
+  self-hosting only** через `is_self_hosting_repo`).
+- `staging_runner_timeout_s: int = 600` (env `ORCH_STAGING_RUNNER_TIMEOUT_S`; см. D9).
+- `staging_runner_infra_max_retries: int = 2`, `staging_runner_infra_retry_delay_s: int = 30`
+  (defer-бюджет D5; зеркало `merge_retest_infra_*`).
+
+`applies(repo)` (локально, без сети, **never-raise → False**): `staging_runner_enabled==False`
+→ `False` (откат к LLM-пути); непустой CSV → membership; пустой → `is_self_hosting_repo(repo)`.
+Проверяется **первым** в `should_intercept` → при выключенном флаге нулевой оверхед, на
+`deploy-staging` штатно вызывается `_spawn` (прежний LLM-deployer **байт-в-байт**). Откат =
+`ORCH_STAGING_RUNNER_ENABLED=false`.
+
+### D9 — Бюджет времени (NFR-4 / AC-9, сквозной инвариант ORCH-065/109/110)
+
+`staging_runner_timeout_s = 600` (дефолт; малформ/непозитив → дефолт + WARNING, never-break
+— зеркало `_resolve_retest_timeout`). Обоснование инварианта **без правки
+`reaper_max_running_s` (5400)**: окно «running» одного deployer-джоба = `staging_check`
+(≤600s) + те же edge-под-гейты, что и раньше (security + merge re-test 900 + coverage 900 +
+image-freshness rebuild). В LLM-пути это окно включало staging-прогон LLM (3–15 мин, до ~900s)
++ те же под-гейты. Раннер заменяет до-900s LLM-окна ограниченными ≤600s → **Σ(работ на ребре)
+не растёт** → инвариант `reaper_max_running_s > Σ + grace` сохранён без изменения reaper'а.
+
+### D10 — Наблюдаемость (FR-7 / AC-10 / BR-6)
+
+In-process счётчики `_STAGING_RUNNER_COUNTERS` (зеркало `_MERGE_GATE_COUNTERS`,
+`merge_gate.py:678`): `runs`/`success`/`failed`/`tool_error`/`deferred`. Read-only блок
+`staging_runner` в `GET /queue` (`enabled`/`repos`/счётчики) — `src/main.py`. Один
+структурный лог-вердикт на прогон: `work_item`/`repo`/`exit_code`/`status`/`duration_s`/
+`outcome` — различает «код упал» (`FAILED` от сюиты) и «инструмент недоступен» (`tool_error`/
+`deferred`). (Опционально, как ORCH-110: на исчерпании defer записать lesson `transient_retry`
+через `lessons.record` — не обязательно для приёмки.)
+
+### D11 — Норматив сопровождения LLM-карты (NFR-6 / AC-11) — спека для developer
+
+Карта/политика/roadmap и их анти-дрейф-тесты **связаны с состоянием кода**, поэтому правятся
+**в development-стадии атомарно с кодом** (иначе тесты покраснеют на полу-готовой ветке).
+Архитектура фиксирует **точную спеку** правок (developer применяет в том же PR):
+- `docs/architecture/llm-call-sites.md` — строка **A6** и машинный
+  `ORCH-118-INVENTORY-BLOCK`: deployer на `deploy-staging` для in-scope репо больше не
+  консультирует LLM; отразить реализованное детерминированное состояние (раннер-перехват до
+  `_spawn`, как D1/D2), сохранив парсимый заголовок таблицы; синхронно — `_parse_staging_status`
+  остаётся потребителем (имя гейта не меняется).
+- `docs/architecture/llm-determinization-roadmap.md` — машинный `ORCH-118-ROADMAP-BLOCK`:
+  rank 1 (deployer) переходит из «план» в «реализовано»; **инвариант «ровно один
+  `first_slice = yes`»** держать корректным (см. `test_llm_determinization_docs.py`).
+- `docs/architecture/llm-usage-policy.md` — §5: единственный транспорт LLM-консультации
+  (`_spawn`/S0) не нарушен; ввод второго транспорта запрещён (раннер LLM не зовёт).
+- Анти-дрейф `tests/test_llm_call_site_inventory.py` / `tests/test_llm_determinization_docs.py`
+  — обновить ожидания синхронно, держать зелёными (TC-14).
+- Прочие docs того же PR (правило агентов №2): `.openclaw/agents/deployer.md` (пометка, что
+  на `deploy-staging` для in-scope репо стадию ведёт детерминированный код; LLM-ветвь —
+  fallback под выключенным флагом / не-self репо), `CLAUDE.md`, `CHANGELOG.md`,
+  `docs/overview/`.
+
+**Обоснование против `llm-usage-policy.md` §5:** ORCH-115 **снимает** C-консультацию с
+деривируемым вердиктом (A6/staging-status) — это разрешённое `replace-deterministic-now`,
+не ввод новой LLM-консультации; политика соблюдена.
+
+## Альтернативы
+
+- **Новая стадия / новый QG для детерминированного staging** — отвергнуто: нарушает NFR-1
+  (`STAGE_TRANSITIONS`/`QG_CHECKS` байт-в-байт). Меняется только *продюсер* артефакта; гейт
+  и ребро прежние.
+- **tool-error → немедленный `FAILED`-откат на `development`** — отвергнуто: анти-паттерн
+  ORCH-110 (инфра-сбой как код-фейл → расход developer-retry → петля). Выбран двухуровневый
+  исход D5 (defer на tool-error, fail-closed на исчерпании).
+- **Merge лога отдельным PR в `main`** (как шаг-4 LLM-deployer'а) — отвергнуто: гейт читает
+  worktree первым → достаточно push в фичеветку; исключение прямой работы с `main` усиливает
+  AC-8/BR-7.
+- **Логика раннера прямо в `launcher.py`** — отвергнуто: нарушает разделение
+  транспорт/решение; leaf тестируем без живого CLI/docker (зеркало
+  `self_deploy`/`coverage_gate`).
+- **Править `llm-call-sites.md`/roadmap/policy в architecture-стадии** — отвергнуто:
+  анти-дрейф-тесты коуплены к коду; правки идут атомарно с кодом (D11).
+- **Свой второй exit-code→verdict маппинг** — отвергнуто: переиспользуем
+  `self_deploy.map_exit_code_to_status` (BR-4, единый контракт).
+
+## Последствия
+
+- **+** На `deploy-staging` для `orchestrator` исчезает LLM-консультация: дешевле/быстрее/
+  детерминированнее; минус один avoidable LLM control path (первый срез roadmap).
+- **+** Happy-path не вызывает `_spawn` (нет `agent_runs`-строки, нет токенов).
+- **+** Полная обратимость одним флагом; артефакт/гейт/ребро/схема БД неизменны → переключение
+  туда-сюда не оставляет несовместимого состояния.
+- **+** Двухуровневый исход (D5) убирает класс ORCH-110 (инфра ≠ код-фейл) с staging-ребра.
+- **−** Новый leaf + врезка в `launch_job` + defer-механика — рост поверхности кода.
+  Митигейшн: leaf never-raise + kill-switch (fail-safe к LLM), тонкая врезка-зеркало D1/D2,
+  defer-счётчик без схемы БД (маркер в `task_content`), покрытие `tests/test_orch115_*`.
+- **−** Раннер программно зависит от доступности `docker exec` в `orchestrator-staging` и от
+  поднятого staging-контейнера (раньше это делал LLM). Митигейшн: D5 (defer + fail-closed),
+  предусловие фиксировано в `07-infra-requirements.md`.
+- **Откат:** `ORCH_STAGING_RUNNER_ENABLED=false` → `applies()` → `False` → `should_intercept`
+  → `False` → штатный `_spawn` LLM-deployer'а на `deploy-staging` **байт-в-байт** до ORCH-115.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-115/01-brd.md`
+- TRZ: `docs/work-items/ORCH-115/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-115/03-acceptance-criteria.md`
+- Инфра: `docs/work-items/ORCH-115/07-infra-requirements.md`;
+  Данные: `08-data-requirements.md`; Риски: `10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`
+- Сверено по коду: `src/agents/launcher.py:389/404/1189`, `src/stage_engine.py:191/932/2010`,
+  `src/self_deploy.py:81/317`, `src/qg/checks.py:525/538/599`, `src/proc_group.py`,
+  `src/staging_verdict.py`, `src/merge_gate.py:678`, `src/config.py` (`coverage_gate_*`/
+  `reaper_max_running_s`)
+- Политика/карта/roadmap: `docs/architecture/llm-usage-policy.md`,
+  `docs/architecture/llm-call-sites.md` (A6), `docs/architecture/llm-determinization-roadmap.md`

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

@@ -0,0 +1,61 @@
+---
+work_item: ORCH-115
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-115 — детерминированный staging-раннер
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Топология **не меняется** (новых контейнеров/портов/томов/compose-правок
+> нет). Файл фиксирует **предусловия**, на которые раннер теперь опирается **программно**
+> (раньше эти же шаги исполнял LLM-deployer), чтобы предусловие было аудитопригодно (BR-7/
+> AC-8/AC-9).
+
+## I-1. Топология / окружения
+**Без изменений топологии.** Раннер исполняется в прод-контейнере `orchestrator` (8500), в
+worker-треде, как `_run_deploy_finalizer_job`. Предусловия (существующие, не вводятся
+ORCH-115):
+- staging-контейнер `orchestrator-staging` (8501) поднят и доступен на хосте (Допущение А1);
+- прод-контейнер имеет возможность `docker exec` в `orchestrator-staging` (та же возможность
+  использовал LLM-deployer — `.openclaw/agents/deployer.md` шаг 1; уже в проде);
+- `scripts/staging_check.py` доступен внутри `orchestrator-staging` по bind-mount
+  (`/repos/orchestrator/scripts/…`, паттерн B6/ORCH-048) — источник истины набора проверок и
+  exit-кода (Допущение А2), ORCH-115 его не меняет.
+
+Недоступность любого из предусловий обрабатывается **детерминированно** (раннер D5: bounded
+defer → fail-closed `FAILED` + alert на исчерпании) — никогда тихий advance / ложный green.
+
+## I-2. Переменные окружения / секреты
+**Новые env-ключи (config, дефолты = боевое; добавить в `.env.example`):**
+- `ORCH_STAGING_RUNNER_ENABLED` (`staging_runner_enabled`, дефолт `True`) — kill-switch;
+  `false` → прежний LLM-deployer-путь байт-в-байт.
+- `ORCH_STAGING_RUNNER_REPOS` (`staging_runner_repos`, дефолт `""`) — CSV скоупа; пусто →
+  self-hosting only (`orchestrator`).
+- `ORCH_STAGING_RUNNER_TIMEOUT_S` (`staging_runner_timeout_s`, дефолт `600`) — таймаут
+  subprocess'а; малформ/непозитив → дефолт + WARNING.
+- `ORCH_STAGING_RUNNER_INFRA_MAX_RETRIES` (`staging_runner_infra_max_retries`, дефолт `2`) и
+  `ORCH_STAGING_RUNNER_INFRA_RETRY_DELAY_S` (`staging_runner_infra_retry_delay_s`, дефолт `30`)
+  — бюджет defer на tool-error (D5).
+
+**Секретов не вводит.** Команда строится из существующих host-параметров (`repos_dir`/
+`staging_port`/`SELF_HOSTING_REPO`/сервис-литерал `orchestrator-staging`) — без новых
+host-хардкодов (анти-дрейф `tests/test_no_host_hardcodes.py`).
+
+## I-3. Деплой / рестарт
+**Self-hosting инвариант соблюдён.** Раннер на `deploy-staging` **никогда** не рестартит
+прод-контейнер 8500, не выполняет `docker compose up -d orchestrator`/`--build`, не пушит
+force в `main`, не правит `.env`/`.env.staging`/`docker-compose.yml` (BR-7/AC-8; TC-12 —
+запрет литералов в argv). Прод-выкат самого ORCH-115 идёт штатно через staging-гейт (8501)
+→ `Confirm Deploy` (ORCH-059). Изменение **docs/prompts/код+config**, активируется на
+следующем worktree от `main`; включение в проде — флагом (по умолчанию `True`, обратимо).
+
+## I-4. CI/CD
+**Без изменений `.gitea/workflows/`.** Новый `tests/test_orch115_staging_runner.py` исполняется
+существующим `pytest tests/ -q` (мокирует subprocess/docker-exec и `advance_stage`; живой
+Claude CLI / docker / сеть не требуются). Staging-smoke (`scripts/staging_check.py` на 8501)
+— штатный гейт, не меняется.

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

@@ -0,0 +1,43 @@
+---
+work_item: ORCH-115
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным: ORCH-115 — детерминированный staging-раннер
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. Создан **намеренно** при `N/A`-результате: «нет изменений схемы БД» — это
+> критический инвариант NFR-1/AC-5, поэтому решение фиксируется явно и аудитопригодно.
+
+## D-1. Схема БД
+**Изменений нет.** Ни новых таблиц, ни колонок, ни миграций. Раннер использует существующие
+таблицы read/write через существующие хелперы:
+- `tasks` — чтение `stage`/`work_item_id`/`branch` по `task_id` (дискриминатор стадии D1,
+  поля артефакта/гейта); запись стадии — **только внутри `advance_stage`** (его существующий
+  CAS/lease-контракт ORCH-114, раннер схему не трогает).
+- `jobs` — статус джоба ведётся `mark_job(done|failed)` самим раннером (зеркало
+  `_run_deploy_finalizer_job`); requeue defer — `enqueue_job` свежего `deployer`-джоба
+  (существующий механизм).
+
+## D-2. Restart-safe состояние без схемы (defer-счётчик D5)
+Счётчик infra-defer (ограничение петли tool-error, D5) — **без колонки БД**: подсчёт
+маркера-подстроки в `task_content` нового `deployer`-джоба (зеркало
+`merge_gate._merge_infra_retry_count` ORCH-110 и `_deploy_finalize_defer_count` ORCH-036).
+Сохраняет restart-safe семантику без миграции (NFR-1).
+
+## D-3. Артефакт `15-staging-log.md` (контракт неизменен)
+Формат/расположение/machine-key прежние: `docs/work-items/<work_item_id>/15-staging-log.md`,
+frontmatter `staging_status: SUCCESS|FAILED` (UPPERCASE) + обязательная 52c-схема. Меняется
+лишь *продюсер* (детерминированный код вместо LLM): `author_agent: staging-runner`,
+`model_used: n/a` — **имя и регистр ключа `staging_status:` не меняются**; читается
+неизменённым `_parse_staging_status` (AC-2/AC-5; TC-04).
+
+## D-4. Наблюдаемость — in-process, не БД
+Счётчики `staging_runner` (`runs`/`success`/`failed`/`tool_error`/`deferred`) — in-process
+(`_STAGING_RUNNER_COUNTERS`, паттерн `_MERGE_GATE_COUNTERS` ORCH-110), отдаются read-only в
+`GET /queue`. В БД не персистятся.

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

@@ -0,0 +1,44 @@
+---
+work_item: ORCH-115
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-115 — детерминированный staging-раннер
+
+Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации + их митигейшн; нумерация
+> наследует R-1…R-5 из BRD §8 и добавляет производные.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 (R-1) | Перехват «до `_spawn`» перехватит **не тот** джоб (прод-deployer вместо staging) | Низ. | Выс. | Дискриминатор = **стадия задачи** (`tasks.stage=="deploy-staging"`) **И** `applies(repo)`, не только имя роли (ADR D1). Для self-hosting прод-ребро `deployer` не спавнит; для не-self `applies==False`. Покрытие TC-05/TC-06. `should_intercept` never-raise → `False` → штатный `_spawn`. |
+| TR-2 (R-2) | После вердикта не инициирован `advance_stage` → задача зависает на `deploy-staging` (нет «финиша агента») | Низ. | Выс. | Раннер сам вызывает `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` (зеркало `run_deploy_finalizer`, ADR D7). На исключении джоб → `mark_job(failed)` → reaper/worker по существующим контрактам; никогда тихий advance. Покрытие TC-07. |
+| TR-3 (R-3) | Таймаут/изоляция docker-subprocess; утечка процессов (инцидент ORCH-110) | Сред. | Сред. | `proc_group.run_in_process_group` (tree-kill SIGTERM→grace→SIGKILL всего дерева), `staging_runner_timeout_s`; малформ/непозитив → дефолт + WARNING. Покрытие TC-11; запрет сирот согласован с ORCH-110. |
+| TR-4 (R-4) | Конфликт с transition-lease (ORCH-114) / serial-gate (ORCH-088) на side-effectful ребре | Низ. | Выс. | Граница O1: lease берётся **внутри** `advance_stage` — раннер его не трогает (ADR D7). serial-gate гейтит analyst-job claim, не deployer-job. Код ORCH-112/114 не модифицируется. |
+| TR-5 (R-5) | Откат FAILED (developer-retry cap) расходится с LLM-путём | Низ. | Сред. | Реальный `≠0` exit → тот же `advance_stage`-откат (`stage_engine.py:932`, тот же cap `MAX_DEVELOPER_RETRIES`), что у FAILED-вердикта LLM. Покрытие TC-07. |
+| TR-6 | **Инфра-сбой как код-фейл** (docker down / staging недоступен / таймаут → откат + расход developer-retry → петля) — анти-паттерн ORCH-110 | Сред. | Выс. | **Двухуровневый исход D5:** сюита исполнилась → verdict; tool-error/таймаут → bounded defer (`staging_runner_infra_max_retries`) → fail-closed `FAILED` + alert на исчерпании. Не жжёт developer-retry на инфре. Покрытие TC-10. |
+| TR-7 | Скоуп-дрейф: случайная правка `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-key/схемы БД | Низ. | Выс. | NFR-1 — замена только *продюсера*. Анти-дрейф структурный тест TC-09; reviewer ловит ≥P1. Раннер пишет тот же `staging_status:` key, читается неизменённым `_parse_staging_status`. |
+| TR-8 | Сквозной бюджет времени (`reaper_max_running_s`) превышен суммой работ на ребре | Низ. | Сред. | Таймаут 600s ≤ прежнего LLM-окна (3–15 мин) → Σ(работ на ребре) не растёт → инвариант ORCH-065/109/110 сохранён **без** правки `reaper_max_running_s` (ADR D9). |
+| TR-9 | Рассинхрон карты LLM (`llm-call-sites.md`/roadmap/policy) с реализацией → красные анти-дрейф-тесты | Сред. | Сред. | Норматив сопровождения NFR-6 (ADR D11): точная спека правок + `test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` обновляются **атомарно с кодом** в development. Инвариант «ровно один `first_slice`» держать корректным. Покрытие TC-14. |
+| TR-10 | Self-hosting safety: раннер случайно рестартит 8500 / force-push в `main` / правит инфру | Низ. | Выс. | BR-7/AC-8: argv не содержит запрещённых литералов (TC-12); лог пишется в worktree + push в **фичеветку** (не main PR-merge, ADR D6); только чтение + staging-сюита (8501). |
+
+## Сводный вывод
+
+Доминирующий класс — **корректность диспетчеризации и обработки инфра-сбоев** (TR-1/TR-2/TR-6)
+на side-effectful ребре общего прод-инстанса (self-hosting). Все сняты опорой на **доказанные
+прецеденты** (D1/D2 перехват, `run_deploy_finalizer`, `proc_group`, transition-lease внутри
+`advance_stage`) и **двухуровневым исходом D5**, явно адресующим RCA-класс ORCH-110.
+Изменение **аддитивное, never-raise, под kill-switch с байт-в-байт откатом**; гейт/ребро/
+схема БД неизменны. Остаточный риск для прод-конвейера — **низкий**.
+
+Эскалация **не требуется**: это не новая стадия/QG/смена БД (лейбл `arch:major-change` не
+ставится), ТЗ удовлетворяется без нарушения принципов (возврат в анализ не нужен). Единственное
+**инфра-предусловие** для включения в проде — доступность `docker exec` в `orchestrator-staging`
+(уже выполнено LLM-путём); до включения флага поведение байт-в-байт прежнее.

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

@@ -0,0 +1,134 @@
+---
+verdict: APPROVED
+work_item: ORCH-115
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-115
+version: 1
+---
+
+# Review ORCH-115 — детерминированный staging-раннер вместо LLM-деплойера
+
+## Summary
+
+Замена LLM-агента `deployer` на стадии `deploy-staging` (self-hosting `orchestrator`)
+детерминированным leaf `src/staging_runner.py`, перехватываемым в `launch_job` **до** `_spawn`
+(прецедент `deploy-finalizer`/`post-deploy-monitor`). Реализация строго соблюдает корневой
+инвариант NFR-1 — это замена **продюсера** артефакта `15-staging-log.md`, а **не** гейта:
+`STAGE_TRANSITIONS`, `QG_CHECKS`, `check_staging_status`/`_parse_staging_status`, machine-key
+`staging_status:` и схема БД — байт-в-байт не тронуты. Все FR-1…FR-7 реализованы, все
+AC-1…AC-12 выполнены, документация обновлена в том же PR на всех требуемых поверхностях,
+полный регресс зелёный (**2105 passed**), новый сьют (24 теста) зелёный, анти-дрейф LLM-карты
+зелёный.
+
+**Вердикт: APPROVED** — P0/P1 findings отсутствуют.
+
+## Проверка по осям
+
+### 1. Соответствие ТЗ (`02-trz.md`) / критериям (`03-acceptance-criteria.md`)
+- **FR-1 / AC-1** — перехват в `launch_job` до `_spawn` при `agent=="deployer"` +
+  `should_intercept` (стадия `deploy-staging` + `applies`); возвращает `None`, `_spawn` не
+  вызывается, `agent_runs` не создаётся, `jobs`-строка ведётся `mark_job` через
+  `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`). ✅ (TC-05)
+- **FR-2 / AC-9 / AC-8** — та же каноническая staging-сюита через `proc_group.run_in_process_group`
+  (tree-kill, таймаут). Команда из config (без host-хардкодов). ✅ (TC-11/TC-12)
+- **FR-3 / AC-3** — exit-код → `staging_status:` через **единый** контракт
+  `self_deploy.map_exit_code_to_status` (`0→SUCCESS`, иначе/None/нечисло→`FAILED`), второй маппинг
+  не введён. ✅ (TC-02)
+- **FR-4 / AC-2** — `15-staging-log.md` с `staging_status: SUCCESS|FAILED` (UPPERCASE) + полной
+  52c-схемой (`work_item`/`stage: deploy-staging`/`author_agent: staging-runner`/`status`/
+  `created_at`/`model_used: n/a`); INFRA-WAIVED копируется в тело; best-effort commit/push в
+  **фичеветку** (не в `main`), гейт читает worktree первым (`check_staging_status` lookup order
+  подтверждён в `src/qg/checks.py:627`). ✅ (TC-03/TC-04)
+- **FR-5 / AC-4** — после вердикта вызывается существующий
+  `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — параметры в точности
+  соответствуют сигнатуре `stage_engine.advance_stage:191` и зеркалят `run_deploy_finalizer:2092`;
+  SUCCESS → под-гейты + Phase A; FAILED → существующий откат `deploy-staging → development`
+  (`stage_engine.py:932`, ветка `agent=="deployer" and qg=="check_staging_status"`). Новой ветви
+  маршрутизации нет. ✅ (TC-07/TC-10)
+- **FR-6 / AC-6** — kill-switch `staging_runner_enabled` + скоуп `staging_runner_repos` (пусто →
+  self-hosting only через `is_self_hosting_repo`); `applies` проверяется первым, при выключенном
+  флаге `_spawn` LLM-deployer'а байт-в-байт. ✅ (TC-01/TC-08)
+- **FR-7 / AC-10** — read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт
+  на прогон, различающий `code-pass`/`code-fail`/`tool-error`. ✅ (TC-13)
+- **AC-7 (never-raise)** — все публичные функции изолированы; tool-error (spawn-error/таймаут/
+  `returncode None`) даёт bounded DEFER, затем fail-closed FAILED; никогда тихий advance/ложный
+  green. ✅ (TC-10)
+- **AC-12** — `pytest tests/ -q` зелёный (2105 passed); новый `tests/test_orch115_staging_runner.py`
+  зелёный (24 теста, покрытие leaf 83%; непокрытые строки — исключительно defensive `except`-ветви
+  never-raise). ✅
+
+### 2. Соответствие ADR (`06-adr/ADR-001` + сквозной `adr-0048`)
+- D1–D11 реализованы как зафиксировано: точка диспетчеризации (перехват до `_spawn`, дискриминатор
+  по **стадии задачи**, не по имени роли — защита от перехвата прод-`deploy` deployer'а, TC-06),
+  чистота leaf'а (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/
+  `qg.checks`/`self_deploy`/`notifications` — лениво), переиспользование `proc_group` и единого
+  маппинга, **двухуровневый исход D5 (анти-ORCH-110)** — инфра-сбой ≠ код-фейл, restart-safe
+  маркер-счётчик в `task_content` без правки схемы БД, push только в фичеветку, инициация
+  существующего гейта, бюджет времени без правки `reaper_max_running_s`, наблюдаемость.
+- **Инвариант NFR-1 / AC-5 соблюдён байт-в-байт** — анти-дрейф TC-09 подтверждает неизменность
+  `STAGE_TRANSITIONS["deploy-staging"]`, наличие `check_staging_status` в `QG_CHECKS`, отсутствие
+  новых таблиц/колонок, неизменность machine-key `staging_status:`.
+- **Граница O1 (трассировка маркеров)** — код ORCH-114 (`transition_lease`) и ORCH-112
+  (`checkout_hygiene`) не модифицируется; lease берётся **внутри** `advance_stage`, раннер его не
+  трогает — зафиксированный инвариант цепочки ORCH-110/111/112/113/114 не сломан.
+
+### 3. Качество кода
+- Docstrings на всех публичных функциях; следование установленным паттернам (`self_deploy`/
+  `proc_group`/`merge_gate`); классификация `suite_ran = returncode is not None and not timed_out`
+  корректно трактует timeout-kill (returncode может быть `-9`, но `timed_out=True`) как tool-error,
+  а не код-фейл.
+- Сверены все интеграционные сигнатуры: `ProcResult`, `run_in_process_group(grace_s/tree_kill)`,
+  `enqueue_job(available_at_delay_s)`, `mark_job`, `get_worktree_path`, `link_for`/`send_telegram`,
+  `is_self_hosting_repo`/`SELF_HOSTING_REPO` — все совпадают.
+- **Self-hosting safety (AC-8/BR-7)** — в командной строке нет рестарта 8500 / `docker compose up`
+  / `--build` / force-push / правок `.env`; git push строго в фичеветку, никогда в `main`. ✅ (TC-12)
+- Багфикс-трек (BR-4) неприменим: ORCH-115 — полный цикл (метка не `Bug`, прошёл `architecture`),
+  регресс-тест-фиксатор не требуется; покрытие обеспечено новым сьютом.
+
+### 4. Документация (обязательная проверка)
+`src/` изменён → документация обновлена **в том же PR** на всех требуемых поверхностях:
+- `CLAUDE.md` (раздел-паспорт ORCH-115), `CHANGELOG.md` (`[Unreleased]`).
+- `docs/architecture/README.md` (компонент Staging-runner + adr-link), `internals.md`
+  (детерминированные перехваты `launch_job`).
+- Норматив сопровождения ORCH-118: `llm-call-sites.md` (A6 — срез реализован, машинный
+  `ORCH-118-INVENTORY-BLOCK` сохраняет deployer `avoidable=yes`/`axis=C` как fallback),
+  `llm-determinization-roadmap.md` (rank 1 — ✅, инвариант «ровно один `first_slice`» цел),
+  `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен). Анти-дрейф
+  `tests/test_llm_call_site_inventory.py` / `test_llm_determinization_docs.py` зелёные (TC-14).
+- **Витрина системы `docs/overview/` (ORCH-011)** — обновлены `tech-pipeline.md`, `tech-agents.md`,
+  `tech-quality-security.md`; `tests/test_system_docs.py` зелёный.
+- `.openclaw/agents/deployer.md` (LLM-ветвь `deploy-staging` — fallback), `.env.example` (5 ключей),
+  ADR work-item + сквозной `adr-0048`.
+- **README «Известные ограничения» (ORCH-079)** — корректно не тронут: ни один из трёх открытых
+  пунктов (Telegram 48h / intra-repo deps / batch-autonomy) не закрывается ORCH-115; ложного
+  «решённое за открытое» нет.
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice-to-have
+- [ ] `run_staging_gate` при отсутствии `work_item_id`/`branch` (повреждённая строка `tasks` —
+  задача на `deploy-staging` без branch) делает ранний `return`; обёртка `_run_staging_runner_job`
+  затем помечает джоб `done`, оставляя задачу «висеть» на `deploy-staging` до ре-драйва
+  reconciler/reaper. Это крайний кейс (любая задача на `deploy-staging` имеет branch), логируется
+  как ERROR и согласуется с never-raise-контрактом, но опционально можно сделать defensive-defer
+  вместо `done`-без-эффекта. Не блокирует приёмку.
+
+## Документация
+Обновлена полностью и в том же PR. Изменение `src/` сопровождено синхронным обновлением паспорта,
+чейнджлога, архитектурных доков, LLM-карты/roadmap/политики (+ зелёные анти-дрейф тесты), витрины
+`docs/overview/` (ORCH-011), промпта `deployer.md`, `.env.example` и обоих ADR. Обзорная витрина
+README не требует правок (нет закрытого ORCH-115 пункта). Документационная ось — **PASS**.

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

@@ -0,0 +1,95 @@
+---
+result: PASS
+work_item: ORCH-115
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-115
+---
+
+# Test Report — ORCH-115 — детерминированный staging-раннер вместо LLM-деплойера
+
+## Окружение
+- 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-115-orch-replace-llm-deployer-with`
+- Ветка: `feature/ORCH-115-orch-replace-llm-deployer-with`
+- Дата: 2026-06-16
+- Review verdict (`12-review.md`): **APPROVED** (P0/P1 — нет) ✅ предусловие стадии выполнено
+
+## Команды
+- Полный регресс: `pytest tests/ -q --tb=short`
+- Целевой сьют + анти-дрейф LLM: `pytest tests/test_orch115_staging_runner.py tests/test_llm_call_site_inventory.py tests/test_llm_determinization_docs.py -v`
+- Покрытие leaf: `pytest tests/test_orch115_staging_runner.py --cov=src.staging_runner --cov-report=term-missing`
+- Smoke (read-only): `curl -s http://localhost:8500/{health,status,queue}`
+
+## Результаты — покрытие плана тестов (`04-test-plan.yaml`)
+
+Каждый TC сопоставлен с критериями `03-acceptance-criteria.md` и подтверждён конкретными
+тест-функциями.
+
+| TC ID | Тип | Описание (кратко) | AC | Тест-функции | Результат |
+|-------|-----|-------------------|----|--------------|-----------|
+| TC-01 | unit | `applies(repo)`: kill-switch / скоуп / not-self / never-raise→False | AC-6/AC-7 | `test_tc01_applies_killswitch_and_scope`, `test_tc01_applies_never_raises` | PASS |
+| TC-02 | unit | Маппинг exit-кода `0→SUCCESS`, иначе/None→`FAILED` (контракт `self_deploy.map_exit_code_to_status`) | AC-3 | `test_tc02_map_exit_code` | PASS |
+| TC-03 | unit | Рендер `15-staging-log.md`: `staging_status:` UPPERCASE + 52c-схема; INFRA-WAIVED в тело | AC-2 | `test_tc03_log_render_schema_and_infra_waived` | PASS |
+| TC-04 | integration | Лог читается **неизменённым** `_parse_staging_status` для SUCCESS/FAILED | AC-2 | `test_tc04_gate_parser_unchanged` | PASS |
+| TC-05 | integration | `launch_job` перехватывает до `_spawn`, нет `agent_runs`, `mark_job` ведёт строку | AC-1 | `test_tc05_launch_job_intercepts_before_spawn` | PASS |
+| TC-06 | integration | Дискриминатор стадии: `deploy` (prod) и not-self репо НЕ перехватываются | AC-1 | `test_tc06_stage_discriminator_prod_not_intercepted`, `test_tc06_non_self_repo_not_intercepted` | PASS |
+| TC-07 | integration | SUCCESS/FAILED → `advance_stage(finished_agent="deployer")` как у LLM | AC-4 | `test_tc07_advance_initiated_like_llm[0-SUCCESS]`, `[1-FAILED]` | PASS |
+| TC-08 | integration | Kill-switch `=False` → прежний LLM-путь через `_spawn` (байт-в-байт) | AC-6 | `test_tc08_killswitch_falls_back_to_spawn` | PASS |
+| TC-09 | unit | Анти-дрейф NFR-1: `STAGE_TRANSITIONS`/`QG_CHECKS`/`staging_status:`/схема БД неизменны | AC-5 | `test_tc09_pipeline_contract_unchanged` | PASS |
+| TC-10 | integration | never-raise/fail-safe: ненулевой→FAILED+advance; таймаут→DEFER; бюджет исчерпан→FAILED; раннер не падает | AC-7 | `test_tc10_nonzero_exit_is_failed_and_advances`, `test_tc10_timeout_defers_without_advance`, `test_tc10_tool_error_budget_exhausted_fails_closed`, `test_tc10_run_gate_never_raises`, `test_tc10_launcher_contains_runner_fault` | PASS |
+| TC-11 | unit | Таймаут `staging_runner_timeout_s`; малформ→дефолт+WARNING; передаётся в `proc_group` | AC-9 | `test_tc11_resolve_timeout_default_on_bad_value`, `test_tc11_timeout_passed_to_proc_group` | PASS |
+| TC-12 | unit | Self-hosting safety: нет запрещённых литералов (рестарт 8500 / `up` / `--build` / force-push) | AC-8 | `test_tc12_command_has_no_dangerous_literals` | PASS |
+| TC-13 | integration | Наблюдаемость: блок `staging_runner` в `/queue` + структурный лог-вердикт (различает код-фейл/tool-error) | AC-10 | `test_tc13_snapshot_shape`, `test_tc13_queue_endpoint_includes_block`, `test_tc13_structured_verdict_log_distinguishes_outcomes`, `test_tc13_snapshot_never_raises` | PASS |
+| TC-14 | integration | Анти-дрейф LLM-карты: `llm-call-sites.md`(A6)/roadmap/policy обновлены, анти-дрейф зелёный | AC-11 | `test_llm_call_site_inventory.py` (9 тестов), `test_llm_determinization_docs.py` (3 теста) | PASS |
+
+**Итог по плану: 14/14 TC выполнены и PASS.** Каждый AC (AC-1…AC-12) покрыт; AC-12 (полный регресс)
+подтверждён прогоном всего `tests/`.
+
+## Smoke API (read-only, prod 8500)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
+- `GET /status` → отвечает, активные задачи перечислены (включая ORCH-115 на `testing`) ✅
+- `GET /queue` → отвечает; блок **`serial_gate`** присутствует (ORCH-088) ✅; блок **`auto_labels`**
+  присутствует ✅. Полный набор ключей: `auto_labels, bug_fast_track, build_cache_prune,
+  checkout_hygiene, counts, coverage, disk_monitor, fs_ownership, lessons, max_concurrency,
+  merge_gate, merge_verify, poll_interval, post_deploy, reaper, recent, reconcile, resilience,
+  serial_gate, stop, task_deps, transition_lease`.
+
+> Примечание: read-only блок `staging_runner` (FR-7) на боевом 8500 ещё отсутствует — это ожидаемо,
+> т.к. ORCH-115 не задеплоен в прод. Наличие блока в коде ветки подтверждено тестами TC-13
+> (`test_tc13_queue_endpoint_includes_block`). Это **не** регресс смока: обязательный для смока
+> блок `serial_gate` присутствует.
+
+## Покрытие нового кода
+`src/staging_runner.py` — **83%** (211 стэйтментов, 36 непокрытых). Непокрытые строки —
+исключительно defensive `except`-ветви контракта never-raise (согласовано с `12-review.md`).
+
+## Вывод pytest
+
+Полный регресс:
+```
+........................................................................ [100%]
+2105 passed, 1 warning in 93.61s (0:01:33)
+```
+
+Целевой сьют ORCH-115 + анти-дрейф LLM:
+```
+tests/test_orch115_staging_runner.py ......................... (24 passed)
+tests/test_llm_call_site_inventory.py ......................... (9 passed)
+tests/test_llm_determinization_docs.py ...................... (3 passed)
+======================== 37 passed, 1 warning in 1.80s =========================
+```
+
+Единственное предупреждение — `PydanticDeprecatedSince20` (class-based `config`), не относится к
+ORCH-115, присутствовало до изменения.
+
+## Итог
+**PASS** — полный регресс зелёный (2105 passed), целевой сьют (24 теста) и анти-дрейф LLM-карты
+(12 тестов) зелёные, все 14 TC выполнены и сопоставлены с AC, smoke read-only OK (`serial_gate` и
+`auto_labels` присутствуют в `/queue`). Машинный вердикт: `result: PASS` → задача переходит на
+`deploy-staging`.

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

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

@@ -0,0 +1,39 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-115
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T23:14:17Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` container
+(8501) via `docker exec` (Docker Engine API over the mounted socket). The suite
+ran inside the container so the B6 registry-isolation check reads the registry
+from the running instance's own process-env (`.env.staging`).
+
+**Command:**
+```
+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 Block A (SMOKE A1–A3), Block B (ACCESS B4–B6), and Block C creation/trigger
+  checks (C7, C8) passed.
+
+INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
+
+Per ORCH-061 waiver tolerance (`staging_infra_tolerance_enabled=True`), the two
+infra-only checks C9a/C9b depend on SANDBOX bot accounts being project members —
+not on the pipeline — and are tolerated when every REAL check is green. The
+script exits 0. Exit-code → verdict mapping is unchanged: trust the exit code.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH: replace LLM tester with deterministic test runner
+
+Work Item ID: ORCH-116
+
+## Description
+
+TBD

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

@@ -0,0 +1,224 @@
+---
+work_item: ORCH-116
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 01 — BRD (бизнес-требования): ORCH-116 — заменить LLM-тестера детерминированным test-раннером
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+
+Стадия `testing` сейчас исполняется **LLM-агентом `tester`** (`src/stages.py:17`,
+`STAGE_TRANSITIONS["review"]["agent"] = "tester"` — tester запускается при входе в `testing`).
+Фактическая работа агента на этой стадии в happy-path — **в основном детерминированная**
+(`.openclaw/agents/tester.md`): прогнать регресс `pytest tests/ -v --tb=short` в worktree ветки,
+сделать read-only smoke (`/health`, `/status`, `/queue` + наличие блока `serial_gate`),
+собрать exit-код, записать `13-test-report.md` с машинным frontmatter `result: PASS|FAIL`. Гейт
+`check_tests_passed` (`src/qg/checks.py:182` → `_parse_tests_verdict:226`) читает **только** ключ
+`result:` из frontmatter — **не** прозу и **не** покрытие TC.
+
+Это **avoidable LLM control path** по нормативной политике (`docs/architecture/llm-usage-policy.md`):
+(i) это **C-консультация** — вердикт `result:` потребляется гейтом `check_tests_passed`, и
+(ii) вердикт PASS/FAIL **деривируем** из exit-кода `pytest` + smoke (детерминированные сигналы).
+Карта вызовов (`docs/architecture/llm-call-sites.md`, строка **A5**) классифицирует tester как
+**`needs-hybrid-fallback`**, а roadmap (`docs/architecture/llm-determinization-roadmap.md`, машинный
+блок §4) ставит его **rank 2** с `hybrid_needed = yes`, `first_slice = no`. Это **второй срез**
+determinization-roadmap — после реализованного первого среза **ORCH-115** (детерминированный
+`staging_runner`, deployer на `deploy-staging`).
+
+**Гибридная природа (ключевое отличие от ORCH-115).** Tester — `needs-hybrid-fallback`, не
+`replace-deterministic-now`: его **PASS/FAIL-ядро** полностью детерминируемо (exit-код pytest +
+smoke), но часть работы прежнего промпта — **триаж падений**, **анализ пробелов покрытия
+AC**, **сопоставление TC ↔ критерии приёмки** и **человекочитаемая диагностика** — это настоящее
+суждение. ORCH-116 выносит из потока управления **только PASS/FAIL-исполнителя** (его делает
+детерминированный код); опциональный LLM-аналитик допустим как **off-control-path** триаж/
+диагностика после детерминированного провала, но **никогда** как первичный исполнитель вердикта
+гейта (BR-8 / NFR-7).
+
+**Боль / риск, который закрываем:**
+- **Недетерминизм в потоке управления.** Решение «advance на `deploy-staging` или rollback на
+  `development`» на стадии `testing` зависит от LLM-сессии (стоимость, латентность, риск
+  галлюцинации/неверного вердикта), хотя сводится к exit-коду pytest + smoke.
+- **Стоимость и латентность.** Каждый прогон tester'а тратит токены/время opus-агента (оценка по
+  `agent_runs`: tester-строки ~60–150k токенов / 5–20 мин на прогон; точное число — `GET /metrics`)
+  ради действия, которое выполняется одним прогоном pytest + несколькими read-only GET.
+- **Избыточность с уже-зелёным сигналом.** Регресс уже прогоняется в CI (`check_ci_green` гейтит
+  `development → review`, `src/qg/checks.py:82`), повторно в merge-gate re-test (ORCH-043/110) и в
+  coverage-gate (ORCH-027). Повторный прогон pytest на стадии `testing` — подтверждение факта, а не
+  суждение → естественный кандидат на детерминизацию.
+- **Класс инцидентов «LLM принял решение, которое есть исполнение фиксированных команд + маппинг
+  результата»** — тот же RCA-трек, что ORCH-110/111/112/113/114/117/115.
+
+Установленные факты (не изобретать):
+- Гейт `check_tests_passed`/`_parse_tests_verdict` читает **только** `result:` (плюс legacy-поля
+  `verdict:`/`status:`, ORCH-047) из frontmatter `13-test-report.md`; покрытие TC / сопоставление с
+  AC гейтом **не парсится** (это была нагрузка промпта, не требование гейта). Значит замена
+  *продюсера* `result:` детерминированным кодом сохраняет контракт гейта байт-в-байт.
+- Детерминированный прецедент замены агента **до `_spawn`** уже работает и проверен: `launch_job`
+  перехватывает `deploy-finalizer` (D1, `src/agents/launcher.py:397`), `post-deploy-monitor`
+  (D2, `:402`) и **staging-runner** (ORCH-115, `:405-408`) до `_spawn`; `src/staging_runner.py` —
+  готовый эталон leaf-раннера (two-level outcome, never-raise, kill-switch, proc_group).
+- Изоляция спавненного pytest уже решена: `src/proc_group.py::run_in_process_group` (ORCH-110)
+  даёт tree-kill (`os.killpg`, каскад SIGTERM→grace→SIGKILL) — корень CPU-голодания от
+  осиротевших pytest (инцидент ORCH-109/111) закрыт; раннер обязан использовать его.
+- Маппинг exit-кода — тривиальная pure-функция (`0 → PASS`, иначе `FAIL`), зеркало
+  `self_deploy.map_exit_code_to_status` (но в токенах `PASS`/`FAIL`, а не `SUCCESS`/`FAILED`).
+
+## 2. Объём (scope)
+
+### В объёме (Phase 1)
+- **Детерминированный test-раннер** для стадии `testing` репо `orchestrator` (self-hosting):
+  исполняет «тест-контракт» (сконфигурированные test/smoke-команды) в worktree ветки задачи,
+  маппит exit-код в `result: PASS|FAIL`, пишет `13-test-report.md`, инициирует существующий гейт
+  `check_tests_passed` — **без** запуска LLM-агента `tester`.
+- **Тест-контракт** — сконфигурированный набор команд: обязательная регресс-команда
+  (`pytest tests/`, переиспользуя конвенцию `merge_retest_target`) + опциональные read-only
+  smoke-проверки (зеркало шага 3 промпта tester: `/health`, `/status`, `/queue` + наличие блока
+  `serial_gate`). Для self-hosting `orchestrator` контракт известен по умолчанию.
+- Раннер активируется через **перехват в `launch_job` до `_spawn`** (прецедент D1/D2/ORCH-115),
+  **без правки `src/stages.py`/`STAGE_TRANSITIONS`** (роль `tester` в словаре остаётся; меняется лишь
+  *кто* обрабатывает джоб на стадии `testing` для in-scope репо с тест-контрактом).
+- После выпуска вердикта раннер инициирует **существующую** оценку exit-гейта `check_tests_passed`
+  ровно как завершившийся LLM-tester (`advance_stage(finished_agent="tester")`): PASS → `deploy-staging`
+  (и далее под-гейты ORCH-022/043/027/058 на ребре `deploy-staging → deploy`); FAIL → существующий
+  откат `testing → development` + developer-retry (`src/stage_engine.py:849`).
+- Two-level outcome (анти-ORCH-110, по образцу `staging_runner`): сюита **исполнилась** → вердикт →
+  advance; сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → bounded
+  DEFER, на исчерпании → fail-closed `FAIL` + advance + alert. Инфра-сбой **не жжёт** developer-retry.
+- Kill-switch + скоуп-CSV + **тест-контракт** (паттерн ORCH-022/027/043/089/090/115): `*_enabled`
+  (откат к LLM-пути), `*_repos` (пусто → self-hosting only), backward-compat: репо без тест-контракта
+  → раннер не применяется → прежний LLM-tester.
+- Наблюдаемость: read-only блок в `GET /queue` + структурный лог вердикта.
+
+### Вне объёма (явно НЕ делаем в ORCH-116)
+- **ORCH-115 (детерминированный deploy/staging-раннер)** — **по явной границе задачи не смешиваем**:
+  ORCH-116 не модифицирует `src/staging_runner.py` и не трогает ребро `deploy-staging`/`deploy`.
+- **LLM-роли `reviewer` и `developer`** — **остаются без изменений** (граница задачи). reviewer —
+  control-path-но-keep (вердикт `verdict:` не деривируем из tool-сигнала, `llm-call-sites.md`).
+- **Реализация опционального off-control-path LLM-триажа/диагностики после FAIL** — не делается в
+  этом срезе (forward-looking, §6 BRD и §8 TRZ). Архитектура раннера **не должна запрещать** её
+  (NFR-7), но и не реализует.
+- **Сопоставление TC ↔ критерии приёмки / анализ пробелов покрытия AC как условие гейта** — гейт
+  `check_tests_passed` его не требует (читает только `result:`); в потоке управления его нет. Это
+  off-control-path диагностика (см. выше).
+- **Любая правка `STAGE_TRANSITIONS` / реестра и имён `QG_CHECKS` / семантики `check_tests_passed` /
+  `_parse_tests_verdict` / machine-verdict-ключей (`result:`/`verdict:`/`status:`) / схемы БД**
+  (см. NFR-1).
+- **Замена/правка `check_ci_green` / merge-gate re-test / coverage-gate** — они продолжают работать
+  как есть; ORCH-116 меняет только продюсера `13-test-report.md`.
+
+## 3. Заинтересованные стороны
+
+- **Заказчик / Owner** (`homenet542@gmail.com`) — инициатор детерминизации LLM-control-path'ов.
+- **Платформа orchestrator (self-hosting)** — прямой потребитель: дешевле/быстрее/детерминированнее
+  собственная стадия `testing`.
+- **Другие проекты на общем инстансе** (enduro-trails) — НЕ затронуты в Phase 1 (скоуп self-hosting +
+  backward-compat для репо без тест-контракта); выигрывают позже от Phase 2 (project test contract).
+- **Reviewer / Developer-роли конвейера** — принимают результат через неизменные гейты; их LLM-роли
+  не трогаются.
+
+## 4. Бизнес-требования (BR)
+
+- **BR-1 — Детерминированный PASS/FAIL без LLM.** На стадии `testing` для in-scope репо с
+  тест-контрактом вердикт `result:` производится детерминированным кодом (исполнение тест-контракта
+  + маппинг exit-кода), **без** консультации LLM. Happy-path `testing` не вызывает `_spawn`.
+- **BR-2 — Контракт артефакта неизменен.** Раннер пишет тот же `13-test-report.md` с тем же
+  frontmatter-ключом `result: PASS|FAIL`, который читает `check_tests_passed`/`_parse_tests_verdict`.
+  Гейт и парсер байт-в-байт не меняются.
+- **BR-3 — Эквивалентность маршрутизации.** PASS → продвижение на `deploy-staging` через
+  существующий путь; FAIL → существующий откат `testing → development` + инкремент developer-retry
+  (тот же путь и cap `MAX_DEVELOPER_RETRIES`, что у FAIL-вердикта LLM-tester'а, `src/stage_engine.py:849`).
+  Никаких новых рёбер/исходов.
+- **BR-4 — Переиспользование существующей инфраструктуры.** Раннер исполняет pytest через
+  `proc_group.run_in_process_group` (ORCH-110, tree-kill), переиспользует exit-code→verdict-маппинг
+  (зеркало `self_deploy.map_exit_code_to_status`, в токенах `PASS`/`FAIL`) и конвенцию таргета
+  (`merge_retest_target`/`tests/`). Не плодит второй несогласованный маппинг/механизм.
+- **BR-5 — Обратимость одним флагом.** Глобальный kill-switch возвращает прежний LLM-tester-путь на
+  `testing` байт-в-байт; скоуп-CSV ограничивает раннер in-scope репо (пусто → только `orchestrator`).
+- **BR-6 — Наблюдаемость.** Исход раннера (запущен / PASS / FAIL / tool-error / defer) виден в
+  `GET /queue` и в структурном логе; «код упал» (детерминированный FAIL) и «инструмент недоступен»
+  (tool-error) различимы.
+- **BR-7 — Self-hosting safety.** Раннер на `testing` **никогда** не рестартит прод-контейнер 8500,
+  не трогает `main` force-push'ем, не правит `.env`/`docker-compose.yml`. Он лишь читает, исполняет
+  тест-контракт в worktree (pytest) и read-only smoke против 8500, пишет лог и best-effort пушит лог
+  в фичеветку (merge в `main` — штатным merge-gate-путём).
+- **BR-8 — Гибрид: LLM только off-control-path.** Детерминированный раннер — **единственный**
+  исполнитель вердикта `result:`. LLM на стадии `testing` допустим лишь как опциональный
+  off-control-path триаж/диагностика после детерминированного FAIL и **не** выносит/не переопределяет
+  машинный вердикт гейта. В Phase 1 он не реализуется (NFR-7), но архитектурно не запрещён.
+- **BR-9 — Backward-compatibility для репо без тест-контракта.** Репо, для которого тест-контракт не
+  сконфигурирован/не резолвится, раннер **не перехватывает** → стадию `testing` ведёт прежний
+  LLM-tester (fail-safe). enduro-trails и любые будущие репо без контракта — 1:1 как до ORCH-116.
+
+## 5. Нефункциональные требования (NFR)
+
+- **NFR-1 — Скоуп-инвариант (анти-дрейф).** `STAGE_TRANSITIONS` (`src/stages.py`), реестр и имена
+  `QG_CHECKS`/`check_tests_passed`/`_parse_tests_verdict` (`src/qg/checks.py`), machine-verdict-ключи
+  (`result:`/`verdict:`/`status:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`),
+  схема БД — **байт-в-байт не тронуты**. Это замена *продюсера* артефакта, не гейта.
+- **NFR-2 — never-raise / fail-safe.** Любая ошибка раннера (pytest не запустился, таймаут, I/O) →
+  безопасный детерминированный исход без падения воркера: либо `FAIL` (fail-closed, никогда ложный
+  green), либо штатный bounded requeue/defer — **не** «тихий advance». Сбой раннера не клинит очередь
+  всех проектов. **Tool-error ≠ code-fail:** инфра-сбой не жжёт developer-retry (анти-ORCH-110).
+- **NFR-3 — Изоляция процесса / таймаут.** Спавненный pytest исполняется через `proc_group`
+  (tree-kill, ORCH-110); сирот pytest не оставляет; ограниченный таймаут.
+- **NFR-4 — Сквозные бюджеты времени.** Таймаут раннера согласован со сквозным инвариантом
+  ORCH-065/109/110 (`reaper_max_running_s` > Σ(работ на ребре) + grace) — **без** правки
+  `reaper_max_running_s`. Ребро `testing` отдельно от ребра `deploy-staging`; бюджет ≤ окна, которое
+  раннер замещает (прежний tester шёл под `agent_timeout_seconds`).
+- **NFR-5 — Совместимость с не-self репо.** Для репо вне скоупа / без тест-контракта `testing` ведёт
+  себя 1:1 как до ORCH-116 (LLM-tester). enduro-trails не затронут.
+- **NFR-6 — Соответствие политике LLM.** Изменение снимает LLM-консультацию A5 из потока управления;
+  карта `docs/architecture/llm-call-sites.md` (A5) / `llm-determinization-roadmap.md` (rank 2) /
+  `llm-usage-policy.md` и анти-дрейф-тесты обновляются **в том же PR** (норматив сопровождения ORCH-118).
+- **NFR-7 — Не запрещать будущий off-control-path LLM-триаж.** Архитектура раннера не должна
+  архитектурно исключать опциональный LLM debug/triage-аналитик после детерминированного FAIL
+  (будущее улучшение); в ORCH-116 он не реализуется.
+
+## 6. Допущения и ограничения
+
+- **Допущение А1.** Регресс-сюита `orchestrator` (`pytest tests/`) исполняема в worktree ветки задачи
+  и её exit-код — авторитетный сигнал PASS/FAIL (как уже трактуют CI / merge-gate re-test / coverage-gate).
+- **Допущение А2.** Для self-hosting `orchestrator` тест-контракт известен по умолчанию
+  (pytest + read-only smoke против 8500). Для прочих репо контракт отсутствует, пока не сконфигурирован
+  (Phase 2) → раннер их не перехватывает (BR-9).
+- **Допущение А3.** Перехват «до `_spawn`» по имени джоб-роли (`tester`) + стадии задачи (`testing`)
+  — достаточный механизм диспетчеризации (как D1/D2/ORCH-115); конкретный механизм финализирует
+  архитектор (06-adr).
+- **Ограничение О1.** Граница задачи: не смешивать с ORCH-115 (его код не модифицируется); LLM-роли
+  `reviewer`/`developer` не трогаются; код ORCH-112/114 не модифицируется.
+- **Ограничение О2.** Phase 2 (project test contract для не-self репо + опциональный off-control-path
+  LLM-триаж) — отдельный follow-up; ORCH-116 закрывает только Phase 1.
+
+## 7. Критерии успеха
+
+Стадия `testing` для `orchestrator` проходит без запуска LLM-агента `tester`: детерминированный
+раннер исполняет тест-контракт (pytest + smoke), пишет корректный `13-test-report.md` (`result:
+PASS|FAIL`), инициирует неизменный гейт `check_tests_passed`, и конвейер продвигается
+(`testing → deploy-staging`) / откатывается (`testing → development` + developer-retry) ровно как
+раньше — при неизменных `STAGE_TRANSITIONS`/`QG_CHECKS`/гейтах/схеме БД, под kill-switch с откатом к
+прежнему LLM-поведению, с backward-compat для репо без тест-контракта. Детальные PASS/FAIL —
+`03-acceptance-criteria.md`.
+
+## 8. Риски
+
+Краткий перечень (детали — `10-tech-risks.md`, заполняет архитектор):
+- **R-1** — точка диспетчеризации «до `_spawn`» должна корректно отличать testing-tester от любого
+  иного джоба (по роли + стадии задачи), иначе можно перехватить не тот джоб.
+- **R-2** — после выпуска вердикта нужно надёжно инициировать `advance_stage(finished_agent="tester")`,
+  иначе задача зависнет на `testing` (нет «финиша агента», который раньше триггерил гейт).
+- **R-3** — таймаут/изоляция pytest-subprocess; утечка процессов (корень инцидента ORCH-109/110/111) —
+  обязателен `proc_group` tree-kill.
+- **R-4** — корректность two-level outcome: tool-error не должен жечь developer-retry (анти-ORCH-110),
+  но и не давать ложный green/тихий advance.
+- **R-5** — корректность отката FAIL (developer-retry cap, встраивание `extract_test_failures`) —
+  должна совпасть с LLM-путём `src/stage_engine.py:849`.
+- **R-6** — гибрид: не протащить LLM обратно в поток управления вердикта (BR-8); off-control-path
+  триаж — отдельная роль/джоб, не выносящая `result:`.
+- **R-7** — backward-compat: репо без тест-контракта обязаны откатываться на LLM-tester (BR-9), иначе
+  enduro/новый репо «застрянет» без продюсера отчёта.

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

@@ -0,0 +1,195 @@
+---
+work_item: ORCH-116
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-116 — детерминированный test-раннер вместо LLM-тестера
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование (точный механизм перехвата, размещение раннера, способ инициации
+> `advance_stage`, форма тест-контракта, лестница таймаутов, two-level outcome) — задача
+> архитектора (`06-adr/`). Здесь — требования и привязка к реальным модулям `src/`.
+
+## 1. Сводка изменения
+
+Заменить **LLM-агента `tester`** на стадии `testing` (для self-hosting `orchestrator`)
+**детерминированным test-раннером**, перехватываемым в `launch_job` **до `_spawn`** (прецедент
+`deploy-finalizer`/`post-deploy-monitor`/`staging_runner`, `src/agents/launcher.py:397/402/405`).
+Раннер исполняет «тест-контракт» (регресс `pytest tests/` через `proc_group.run_in_process_group`
++ опциональные read-only smoke-проверки), маппит exit-код в `result:` (`0→PASS`, иначе `FAIL`),
+пишет `13-test-report.md`, best-effort пушит лог в фичеветку, затем инициирует **существующую**
+оценку exit-гейта `check_tests_passed` ровно как завершившийся LLM-tester. Контракт артефакта, гейт,
+`STAGE_TRANSITIONS`, схема БД — **неизменны**. Под kill-switch + скоуп-CSV + тест-контракт;
+never-raise; fail-closed; two-level outcome (анти-ORCH-110). Эталон реализации — `src/staging_runner.py`
+(ORCH-115).
+
+## 2. Задействованные модули / пути
+
+| Путь | Действие | Назначение |
+|------|----------|------------|
+| `src/test_runner.py` *(новый leaf)* | создать | Детерминированный раннер: `applies(repo)` (kill-switch + скоуп + наличие тест-контракта), `should_intercept(job)` (роль `tester` + стадия `testing`), исполнение тест-контракта (`pytest` через `proc_group`, опц. smoke), маппинг exit-кода → `result:`, запись `13-test-report.md`, best-effort push в фичеветку, инициация гейта через `advance_stage(finished_agent="tester")`, two-level outcome (tool-error DEFER), снапшот для `/queue`. Leaf-чистота по образцу `staging_runner.py`/`self_deploy.py`: на импорте только `config`/`logging`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications` — лениво внутри функций; never-raise. |
+| `src/agents/launcher.py` | изменить | В `launch_job` добавить перехват **до `_spawn`** (рядом с D1/D2/ORCH-115): `if job.get("agent")=="tester": from .. import test_runner; if test_runner.should_intercept(job): return self._run_test_runner_job(job)`. Новый метод `_run_test_runner_job(job)` — зеркало `_run_staging_runner_job`: синхронно ведёт `jobs`-строку через `mark_job(done|failed)`, возвращает `None` (нет `agent_runs`). |
+| `src/config.py` | изменить | Добавить ключи (зеркало `staging_runner_*`/`merge_retest_*`): `test_runner_enabled: bool = True` (env `ORCH_TEST_RUNNER_ENABLED`), `test_runner_repos: str = ""` (env `ORCH_TEST_RUNNER_REPOS`; пусто → self-hosting only), `test_runner_target: str = "tests/"` (pytest-таргет тест-контракта, конвенция `merge_retest_target`), `test_runner_timeout_s: int = 900` (см. FR-2/NFR-4), `test_runner_smoke_enabled: bool = True` (опц. read-only smoke), `test_runner_infra_max_retries: int = 2`, `test_runner_infra_retry_delay_s: int = 30`. Дефолты = боевое; пустой `.env` ⇒ поведение для in-scope. |
+| `src/main.py` (`GET /queue`) | изменить | Read-only блок `test_runner` (флаг/скоуп/таргет/счётчики исходов) — наблюдаемость BR-6 (зеркало блока `staging_runner`). |
+| `.openclaw/agents/tester.md` | изменить (docs) | Отметить, что на `testing` для in-scope репо с тест-контрактом стадию ведёт детерминированный код (зеркало формулировки `deployer.md` про staging-runner ORCH-115); LLM-ветвь `testing` остаётся fallback'ом под выключенным флагом / для репо без тест-контракта. Канон промпта 52d (5 секций, ключ `result:`) — байт-в-байт. |
+| `docs/architecture/llm-call-sites.md`, `llm-determinization-roadmap.md`, `llm-usage-policy.md` | изменить (docs) | Норматив сопровождения ORCH-118 (NFR-6): отразить реализацию A5 (tester) — обновить инвентарь/политику/roadmap (rank 2 → реализовано, инвариант «ровно один `first_slice = yes`» НЕ нарушать) в том же PR; синхронно поправить `tests/test_llm_call_site_inventory.py` / `tests/test_llm_determinization_docs.py` (машинные блоки). |
+| `docs/architecture/README.md`, `CLAUDE.md`, `CHANGELOG.md`, `docs/overview/` | изменить (docs) | Компонент-карта/паспорт/чейнджлог/витрина — правило для агентов №2 + витрина ORCH-011. |
+| `tests/test_orch116_test_runner.py` *(новый)* | создать | Покрытие (см. `04-test-plan.yaml`). |
+
+> **Не трогать (NFR-1):** `src/stages.py::STAGE_TRANSITIONS`; имена/семантику `QG_CHECKS`/
+> `check_tests_passed`/`_parse_tests_verdict`/прочих `check_*` в `src/qg/checks.py`; machine-verdict-ключи
+> (`result:`/`verdict:`/`status:`/…); `src/staging_runner.py` (ORCH-115); LLM-роли `reviewer`/`developer`
+> (`.openclaw/agents/reviewer.md`/`developer.md`); `src/transition_lease.py` (ORCH-114);
+> `src/checkout_hygiene.py` (ORCH-112); `src/proc_group.py` (переиспользуем как есть); схему БД.
+
+## 3. Функциональные требования
+
+### FR-1 — Детерминированный перехват на `testing` (без `_spawn`)
+В `launch_job` (`src/agents/launcher.py`) **до** вызова `_spawn`, по образцу D1/D2/ORCH-115: если
+`job.agent == "tester"` **и** `test_runner.should_intercept(job)` истинно → не вызывать `_spawn`, а
+исполнить раннер синхронно (`_run_test_runner_job`). Контракт: возвращает `None` (нет `agent_runs`),
+сам ведёт `jobs`-строку (`mark_job(done|failed)`) как `_run_staging_runner_job`.
+- `should_intercept(job)`: `job.agent == "tester"` **И** `applies(job.repo)` **И** стадия задачи
+  (`tasks.stage` по `job.task_id`) == `testing`. Роль `tester` исполняет **только** стадию `testing`
+  (единственный `agent` для входа в `testing`, `STAGE_TRANSITIONS["review"]["agent"]`), поэтому
+  коллизии стадий нет; гард по стадии — defense-in-depth (R-1). never-raise → `False` (DB-сбой →
+  fall-through к `_spawn`, fail-safe к LLM-пути).
+- `applies(repo)`: `test_runner_enabled=False` → `False` (откат к LLM-пути); непустой
+  `test_runner_repos` → membership; пустой CSV → `is_self_hosting_repo(repo)`; **и** тест-контракт
+  для репо резолвится (BR-9: иначе `False` → LLM-tester). Никакой сети, проверяется **первым**
+  (нулевой оверхед при выключенном флаге). never-raise → `False` (fail-safe к LLM-пути).
+
+### FR-2 — Исполнение тест-контракта (pytest + опц. smoke) через `proc_group`
+Раннер исполняет регресс-команду тест-контракта — `python -m pytest <test_runner_target>` (дефолт
+`tests/`) — **в worktree ветки задачи** (`git_worktree.get_worktree_path(repo, branch)`, НЕ в общем
+`/repos/orchestrator`: анти-checkout-гонка, как требовал промпт tester шаг 2) через
+`proc_group.run_in_process_group` (ORCH-110: отдельная группа процессов, tree-kill SIGTERM→grace→SIGKILL,
+grace = `agent_kill_grace_seconds`; `subprocess_tree_kill_enabled`). Таймаут — `test_runner_timeout_s`
+(дефолт 900; малформ/непозитив → дефолт + WARNING, never-break — зеркало
+`merge_gate._resolve_retest_timeout`/`staging_runner._resolve_timeout`). Захватывает exit-код и stdout
+(для тела отчёта/observability).
+- **Опциональный smoke** (`test_runner_smoke_enabled`, зеркало шага 3 промпта tester): read-only GET
+  `http://localhost:<port>/health`, `/status`, `/queue` + проверка наличия блока `serial_gate` в
+  `/queue`. Любой провал smoke → итоговый `FAIL` (детерминированно). Smoke — строго read-only
+  (BR-7/AC-8): никаких мутирующих запросов к 8500.
+
+### FR-3 — Маппинг exit-кода → `result:`
+`0 → "PASS"`, любой ненулевой / отсутствие кода / ошибка запуска → `"FAIL"` (fail-closed, никогда
+ложный green). Pure-функция, согласованная по контракту с `self_deploy.map_exit_code_to_status`, но в
+токенах `PASS`/`FAIL` (`result:` использует их, а не `SUCCESS`/`FAILED`; `_TESTS_POSITIVE_TOKENS`/
+`_TESTS_NEGATIVE_TOKENS`, `src/qg/checks.py:222-223`). Если архитектор предпочтёт единый маппер с
+параметризованными токенами — допустимо, но **второй несогласованный маппинг не плодить** (BR-4).
+
+### FR-4 — Запись и push `13-test-report.md`
+Раннер пишет `docs/work-items/<work_item_id>/13-test-report.md` в worktree фичеветки с frontmatter:
+`result: PASS|FAIL` (UPPERCASE) + обязательная 52c-схема (`work_item`/`stage: testing`/`author_agent`/
+`status`/`created_at`/`model_used`) + информативное тело (таблица результата pytest / хвост stdout /
+smoke-итог) — зеркало `staging_runner.build_staging_log`/`write_staging_log`. `author_agent: test-runner`,
+`model_used: n/a` честно отражают **детерминированный** продюсер; ключ `result:` и его UPPERCASE-значение
+**не** меняются. Best-effort `git add/commit/push` лога в **фичеветку** (та же git-identity ORCH-101,
+актор `test-runner`; **без** отдельного PR-merge в `main` — гейт читает worktree → origin/main fallback,
+`check_tests_passed`→`_repo_path`). Самостоятельный merge лога в `main` НЕ делать (усиливает BR-7/AC-8).
+
+### FR-5 — Инициация существующего гейта после вердикта
+После записи (и best-effort push) раннер инициирует ту же оценку exit-гейта, что триггерил
+завершившийся LLM-tester: `stage_engine.advance_stage(task_id, current_stage="testing", repo,
+work_item_id, branch, finished_agent="tester")`. Это запускает `check_tests_passed` (`_parse_tests_verdict`
+читает `result:` из `13-test-report.md`) — на PASS продвигает `testing → deploy-staging`; на FAIL
+запускает **существующий** откат `testing → development` + developer-retry (cap `MAX_DEVELOPER_RETRIES`,
+встраивание `extract_test_failures`, `src/stage_engine.py:849-892`). **Никакой новой ветви
+маршрутизации.** Lease ORCH-114 берётся внутри `advance_stage` как сейчас — раннер его не трогает
+(граница задачи О1). never-raise.
+
+### FR-6 — Two-level outcome (tool-error DEFER, анти-ORCH-110)
+По образцу `staging_runner.run_staging_gate`:
+- Сюита **исполнилась** (`returncode is not None` и не `timed_out`) → довериться exit-коду (FR-3) →
+  записать `result:` → инициировать гейт (FR-5). FAIL → существующий rollback (FR-5).
+- Сюита **не исполнилась** (tool-error: spawn-error / таймаут / `returncode None`) → **инфра-сбой, НЕ
+  код-фейл** → bounded DEFER: re-queue свежий `tester`-джоб с задержкой `test_runner_infra_retry_delay_s`
+  + restart-safe маркер (`test-runner infra-retry` в `task_content`, зеркало
+  `staging_runner._INFRA_RETRY_MARKER`/`stage_engine._merge_infra_retry_count`); счётчик из persisted
+  `jobs`. На исчерпании `test_runner_infra_max_retries` → fail-closed `result: FAIL` + запись лога +
+  инициация гейта (существующий rollback) + один INFRA-alert (явно «НЕ дефект кода», кликабельный
+  номер). **Никогда** тихий advance/ложный green; **никогда** не клинит очередь; **не** жжёт
+  developer-retry на транзиентной инфре.
+
+### FR-7 — Kill-switch, скоуп, тест-контракт (обратимость + backward-compat)
+`test_runner_enabled=False` → перехват не срабатывает → на `testing` запускается прежний LLM-tester
+(`_spawn`) **байт-в-байт** как до ORCH-116. `test_runner_repos` ограничивает скоуп (пусто → только
+`orchestrator`). Репо без резолвимого тест-контракта → `applies==False` → LLM-tester (BR-9). Переключение
+флага туда-сюда не оставляет несовместимого состояния (артефакт/гейт неизменны).
+
+### FR-8 — Наблюдаемость
+- Read-only блок `test_runner` в `GET /queue`: `enabled`, `repos`, `target`, `timeout_s`,
+  `infra_max_retries`, счётчики `runs`/`pass`/`fail`/`tool_error`/`deferred` (in-process, паттерн
+  `staging_runner._STAGING_RUNNER_COUNTERS`).
+- Один структурный лог-вердикт на прогон (`work_item`/`repo`/`exit_code`/`result`/`duration_s`/`outcome`),
+  различающий «код упал» (`FAIL` от сюиты) и «инструмент недоступен» (tool-error).
+
+### FR-9 — Гибрид: LLM строго off-control-path (BR-8 / NFR-7)
+В Phase 1 LLM на стадии `testing` **отсутствует** в потоке управления вердикта (детерминированный
+раннер — единственный продюсер `result:`). Архитектура раннера не должна архитектурно исключать
+будущий **опциональный off-control-path** LLM-триаж/диагностику после детерминированного FAIL
+(отдельная роль/джоб, **не** выносящая и **не** переопределяющая `result:`). В этом срезе он не
+реализуется и **не** добавляется в `STAGE_TRANSITIONS`.
+
+## 4. Изменения API
+
+- **`GET /queue`** — добавить read-only ключ `test_runner` (наблюдаемость). Существующие поля ответа
+  не меняются.
+- Опционально (на усмотрение архитектора, по образцу `POST /coverage/baseline`): обязательного нового
+  мутирующего эндпоинта нет. Откат — через env-флаг.
+- Новых вебхуков нет.
+
+## 5. Изменения схемы БД
+
+**Нет.** Раннер использует существующие таблицы (`tasks` для стадии/branch/work_item_id, `jobs` для
+статуса джоба и restart-safe счётчика infra-retry по маркеру в `task_content`) и worktree-механику.
+Никаких новых таблиц/колонок/миграций (NFR-1). Счётчики `/queue` — in-process (паттерн
+`_STAGING_RUNNER_COUNTERS`/`_MERGE_GATE_COUNTERS`), не БД.
+
+## 6. Требования к новым/изменённым QG checks
+
+**Нет новых QG и нет изменений существующих.** `check_tests_passed` / `_parse_tests_verdict` / ключ
+`result:` (+ legacy `verdict:`/`status:`) (`src/qg/checks.py:182/226`) и состав `QG_CHECKS` —
+**байт-в-байт неизменны**. ORCH-116 меняет только *продюсера* `13-test-report.md` (детерминированный
+код вместо LLM); гейт, читающий артефакт, остаётся прежним. Это критический инвариант (NFR-1) —
+reviewer ловит любое изменение имени/семантики гейта/парсера/токенов как finding ≥P1.
+
+## 7. Совместимость / регресс
+
+- **Обратная совместимость:** `test_runner_enabled=False` → прежний LLM-tester-путь байт-в-байт;
+  репо без тест-контракта / вне скоупа → LLM-tester (BR-9). enduro-trails не затронут (NFR-5).
+- **Kill-switch / область раската:** флаг `test_runner_enabled` + CSV `test_runner_repos` (пусто →
+  self-hosting only). Откат = `ORCH_TEST_RUNNER_ENABLED=false`.
+- **Обратимость:** полностью обратимо флагом; артефакт и гейт неизменны, переключение туда-сюда не
+  оставляет несовместимого состояния.
+- **never-raise / fail-safe (NFR-2):** ошибка раннера → `FAIL` (fail-closed) или bounded requeue, не
+  «тихий advance»; tool-error не жжёт developer-retry (анти-ORCH-110). Self-hosting safety (BR-7):
+  никаких рестартов 8500 / force-push в `main` / правок инфры; smoke строго read-only.
+- **Изоляция (NFR-3):** pytest через `proc_group` tree-kill (ORCH-110) — без сирот; таймаут согласован
+  со сквозным бюджетом ORCH-065/109/110 без правки `reaper_max_running_s` (NFR-4).
+- **Граница (О1):** код ORCH-115 (`staging_runner`), ORCH-112 (checkout hygiene), ORCH-114 (transition
+  lease) и LLM-роли `reviewer`/`developer` не модифицируются.
+- **Норматив сопровождения (NFR-6):** в том же PR обновить `docs/architecture/llm-call-sites.md` (A5) /
+  `llm-determinization-roadmap.md` (rank 2) / `llm-usage-policy.md` + анти-дрейф-тесты
+  (`tests/test_llm_call_site_inventory.py`, `tests/test_llm_determinization_docs.py`); `CLAUDE.md` /
+  `docs/architecture/README.md` / `CHANGELOG.md` / `docs/overview/`.
+
+## 8. Phase 2 (forward-looking, вне приёмки ORCH-116)
+
+Зафиксировано для преемственности — **не реализуется в этой задаче**, заводится отдельным follow-up:
+- **Project test contract** для не-self репо (enduro-trails): декларативный per-repo контракт
+  `test` / `smoke` (команды + ожидаемые коды/эндпоинты), исполняемый тем же детерминированным
+  раннер-паттерном (run → map exit code → `result:` → artifact → gate).
+- **Опциональный off-control-path LLM-триаж** после детерминированного FAIL: human-readable
+  диагностика причин падений, анализ пробелов покрытия AC, сопоставление TC ↔ критерии приёмки —
+  как обогащение отчёта/комментария, **не** как продюсер вердикта `result:` (NFR-7).
+- Зависимость: устойчивый Phase 1 (этот work item) как доказанный паттерн перехвата + маппинга +
+  two-level outcome.

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

@@ -0,0 +1,216 @@
+---
+work_item: ORCH-116
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-116 — детерминированный test-раннер
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — Детерминированный перехват на `testing` (нет `_spawn`/LLM)
+
+**Условие:** При включённом флаге и in-scope репо с тест-контрактом джоб `tester` на стадии
+`testing` обрабатывается раннером, а не LLM-агентом.
+- **PASS:** `launch_job` (`src/agents/launcher.py`) перехватывает джоб **до** `_spawn` (рядом с
+  D1/D2/ORCH-115) при `agent=="tester"` + `test_runner.should_intercept(job)` (стадия задачи
+  `testing` + `applies(repo)`); `_spawn` не вызывается; не создаётся строка `agent_runs`; джоб
+  ведётся `mark_job(...)` самим раннером (`_run_test_runner_job` → `None`). Тест воспроизводит это
+  без живого Claude CLI.
+- **FAIL:** На `testing` для in-scope репо при включённом флаге всё ещё вызывается `_spawn` /
+  создаётся `agent_runs`-строка LLM-tester'а.
+
+---
+
+## AC-2 — Контракт артефакта `13-test-report.md` неизменен
+
+**Условие:** Раннер пишет тот же артефакт с тем же machine-key, что читает гейт.
+- **PASS:** Создаётся `docs/work-items/<work_item_id>/13-test-report.md` с frontmatter
+  `result: PASS|FAIL` (UPPERCASE) + обязательная 52c-схема (`work_item`/`stage: testing`/
+  `author_agent`/`status`/`created_at`/`model_used`). **Неизменённый** `_parse_tests_verdict` читает
+  его и возвращает корректный вердикт.
+- **FAIL:** Изменено имя/регистр/токены ключа `result:` (или legacy `verdict:`/`status:`),
+  отсутствует frontmatter, вердикт записан только прозой; либо парсер `_parse_tests_verdict` пришлось
+  менять.
+
+---
+
+## AC-3 — Корректный exit-code → verdict маппинг
+
+**Условие:** Exit-код тест-контракта детерминированно маппится в вердикт.
+- **PASS:** `0 → PASS`; любой ненулевой / None / ошибка запуска → `FAIL` (fail-closed). Маппинг —
+  pure-функция, согласованная по контракту с `self_deploy.map_exit_code_to_status` (токены `PASS`/
+  `FAIL`), покрыта unit-тестом на каждый класс входа. Второй несогласованный маппинг не вводится.
+- **FAIL:** Ненулевой код даёт `PASS`; ошибка/None даёт `PASS` (ложный green); раннер вводит второй
+  несогласованный маппинг или нестандартные токены.
+
+---
+
+## AC-4 — Эквивалентность маршрутизации (PASS / FAIL)
+
+**Условие:** После вердикта конвейер ведёт себя ровно как при завершившемся LLM-tester'е.
+- **PASS:** PASS → раннер инициирует `advance_stage(finished_agent="tester")` → `check_tests_passed`
+  → продвижение `testing → deploy-staging`. FAIL → существующий откат `testing → development` с
+  инкрементом developer-retry и встраиванием `extract_test_failures` (`src/stage_engine.py:849-892`),
+  тот же исход и cap `MAX_DEVELOPER_RETRIES`, что у FAIL-вердикта LLM.
+- **FAIL:** Задача зависает на `testing` (гейт не инициирован); или FAIL не откатывает / откатывает
+  иначе; или появляется новое ребро/исход.
+
+---
+
+## AC-5 — Two-level outcome: tool-error ≠ code-fail (анти-ORCH-110)
+
+**Условие:** Невозможность исполнить сюиту трактуется как инфра-сбой, не как провал кода.
+- **PASS:** Сюита исполнилась (реальный exit-код) → вердикт → advance (FAIL → существующий rollback +
+  developer-retry). Сюита НЕ исполнилась (spawn-error / таймаут / `returncode None`) → bounded DEFER
+  (re-queue `tester`-джоба + restart-safe маркер `test-runner infra-retry`, счётчик из persisted
+  `jobs`), **без** отката на `development` и **без** расхода developer-retry; на исчерпании
+  `test_runner_infra_max_retries` → fail-closed `result: FAIL` + advance + INFRA-alert (явно «НЕ дефект
+  кода»).
+- **FAIL:** Tool-error немедленно откатывает на `development` и жжёт developer-retry; либо tool-error
+  даёт `PASS`/тихий advance; либо DEFER бесконечен (не клинит, но и не сходится к fail-closed).
+
+---
+
+## AC-6 — Инвариант скоупа: гейты/стадии/схема БД не тронуты (анти-дрейф)
+
+**Условие:** Изменена только сторона *продюсера*, не контракт конвейера.
+- **PASS:** `git diff` не затрагивает `src/stages.py::STAGE_TRANSITIONS`; имена/семантику
+  `QG_CHECKS`/`check_tests_passed`/`_parse_tests_verdict`/прочих `check_*` в `src/qg/checks.py`;
+  machine-verdict-ключи и токены (`result:`/`verdict:`/`status:`/`staging_status:`/`deploy_status:`/
+  `security_status:`/`coverage_status:`); схему БД (нет новых таблиц/колонок/миграций). Анти-дрейф-тест
+  это подтверждает.
+- **FAIL:** Любой из перечисленных артефактов изменён по имени/семантике/структуре.
+
+---
+
+## AC-7 — Kill-switch и скоуп (обратимость)
+
+**Условие:** Флаг возвращает прежнее поведение; скоуп ограничивает раннер.
+- **PASS:** `test_runner_enabled=False` → на `testing` запускается прежний LLM-tester через `_spawn`
+  (байт-в-байт до ORCH-116). Пустой `test_runner_repos` → раннер активен только для `orchestrator`.
+  Покрыто тестом для обоих значений флага.
+- **FAIL:** При выключенном флаге раннер всё равно перехватывает; либо не-self репо из скоупа
+  перехватывается ошибочно.
+
+---
+
+## AC-8 — Backward-compatibility для репо без тест-контракта
+
+**Условие:** Репо без резолвимого тест-контракта обслуживается прежним LLM-tester'ом.
+- **PASS:** `applies(repo)` → `False`, когда тест-контракт для репо не сконфигурирован/не резолвится
+  (вне скоупа или нет команды) → `should_intercept` → `False` → `_spawn` (LLM-tester). enduro-trails и
+  любой репо без контракта — 1:1 как до ORCH-116. Покрыто тестом.
+- **FAIL:** Репо без тест-контракта перехватывается раннером и остаётся без продюсера `13-test-report.md`
+  / зависает.
+
+---
+
+## AC-9 — never-raise / fail-safe (инструмент недоступен)
+
+**Условие:** Любая ошибка раннера приводит к безопасному детерминированному исходу.
+- **PASS:** pytest не запустился / worktree-ошибка / I/O / таймаут → раннер не роняет воркер; исход —
+  `FAIL` (fail-closed) **или** bounded DEFER (AC-5), **никогда** тихий advance/ложный green. Все
+  публичные функции `test_runner.py` — never-raise; `applies()`/`should_intercept()` при ошибке →
+  `False` (fall-through к `_spawn`). Очередь всех проектов не клинится.
+- **FAIL:** Ошибка раннера роняет воркер/клинит очередь; либо ошибка/таймаут даёт `PASS`.
+
+---
+
+## AC-10 — Self-hosting safety
+
+**Условие:** Раннер на `testing` не выполняет опасных для прода действий.
+- **PASS:** Раннер не рестартит контейнер 8500, не выполняет `docker compose up -d orchestrator`/
+  `--build`, не пушит force в `main`, не правит `.env`/`.env.staging`/`docker-compose.yml`. Smoke —
+  строго read-only GET (`/health`/`/status`/`/queue`). Лог пушится только в фичеветку (merge в `main`
+  — штатным merge-gate-путём). Подтверждается ревью кода раннера + тестом отсутствия запрещённых
+  литералов в его командах.
+- **FAIL:** Раннер содержит путь, рестартящий 8500 / force-push в `main` / правящий инфру / мутирующий
+  smoke-запрос.
+
+---
+
+## AC-11 — Изоляция процесса и таймаут (proc_group / tree-kill)
+
+**Условие:** pytest-subprocess ограничен по времени и не оставляет сирот.
+- **PASS:** Раннер запускает pytest **в worktree ветки** через `proc_group.run_in_process_group`
+  (отдельная группа процессов, tree-kill при таймауте, grace = `agent_kill_grace_seconds`) с таймаутом
+  `test_runner_timeout_s` (согласован со сквозным бюджетом ORCH-065/109/110, без правки
+  `reaper_max_running_s`); малформ/непозитив таймаут → дефолт + WARNING; осиротевших pytest-процессов
+  не остаётся.
+- **FAIL:** Нет таймаута / зависший subprocess клинит воркер; pytest бежит в общем `/repos/orchestrator`
+  (checkout-гонка); остаются сироты процессов; правится `reaper_max_running_s`.
+
+---
+
+## AC-12 — Гибрид: LLM не в потоке управления вердикта
+
+**Условие:** Детерминированный раннер — единственный исполнитель `result:`.
+- **PASS:** В Phase 1 на стадии `testing` (in-scope) вердикт `result:` производит **только**
+  детерминированный код; LLM не вызывается в happy-path и в fail-path для вынесения/переопределения
+  `result:`. Если добавлен off-control-path триаж — он не пишет/не меняет `result:` и не добавляет
+  ребро в `STAGE_TRANSITIONS`.
+- **FAIL:** LLM вызывается для вынесения/переопределения машинного вердикта гейта; либо триаж-роль
+  гейтит продвижение.
+
+---
+
+## AC-13 — Наблюдаемость
+
+**Условие:** Исход раннера виден и различим.
+- **PASS:** `GET /queue` содержит read-only блок `test_runner` (`enabled`/`repos`/`target`/`timeout_s`/
+  счётчики `runs`/`pass`/`fail`/`tool_error`/`deferred`); на каждый прогон — один структурный
+  лог-вердикт (`work_item`/`repo`/`exit_code`/`result`/`duration_s`/`outcome`), различающий код-фейл и
+  tool-error.
+- **FAIL:** Нет блока в `/queue`; исход раннера не логируется/не различим.
+
+---
+
+## AC-14 — Норматив сопровождения LLM-карты/политики/витрины
+
+**Условие:** Документация обновлена в том же PR (правило агентов №2 + норматив ORCH-118).
+- **PASS:** `docs/architecture/llm-call-sites.md` (строка A5) / `llm-determinization-roadmap.md`
+  (rank 2) / `llm-usage-policy.md` отражают реализацию детерминированного tester (инвариант «ровно один
+  `first_slice = yes`» НЕ нарушен); анти-дрейф-тесты (`tests/test_llm_call_site_inventory.py`,
+  `tests/test_llm_determinization_docs.py`) зелёные; `.openclaw/agents/tester.md`,
+  `docs/architecture/README.md`, `CLAUDE.md`, `CHANGELOG.md`, `docs/overview/` обновлены.
+- **FAIL:** Карта/политика/roadmap/витрина не обновлены; анти-дрейф-тесты красные (reviewer: ≥P1).
+
+---
+
+## AC-15 — Полный регресс зелёный
+
+**Условие:** Существующий конвейер не сломан.
+- **PASS:** `pytest tests/ -q` зелёный; новый `tests/test_orch116_test_runner.py` зелёный;
+  зелёные анти-дрейф LLM-тесты.
+- **FAIL:** Любой ранее зелёный тест становится красным; новые тесты падают.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-4 |
+| AC-3 | BR-4 / FR-2 / FR-3 |
+| AC-4 | BR-3 / FR-5 |
+| AC-5 | NFR-2 / FR-6 |
+| AC-6 | NFR-1 / FR-7 |
+| AC-7 | BR-5 / FR-7 |
+| AC-8 | BR-9 / FR-1 / FR-7 |
+| AC-9 | NFR-2 / FR-1 / FR-6 |
+| AC-10 | BR-7 / FR-2 / FR-4 |
+| AC-11 | NFR-3 / NFR-4 / FR-2 |
+| AC-12 | BR-8 / NFR-7 / FR-9 |
+| AC-13 | BR-6 / FR-8 |
+| AC-14 | NFR-6 |
+| AC-15 | NFR-5 / NFR-1 |

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

@@ -0,0 +1,116 @@
+work_item: ORCH-116
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+title: "Детерминированный test-раннер вместо LLM-тестера (стадия testing)"
+framework: pytest
+scope: >
+  Покрывает Phase 1: перехват tester-джоба на стадии testing до _spawn, исполнение
+  тест-контракта (pytest через proc_group + опц. read-only smoke), маппинг exit-кода
+  в result: PASS|FAIL, запись/push 13-test-report.md, инициацию существующего гейта
+  check_tests_passed, two-level outcome (tool-error DEFER, анти-ORCH-110), kill-switch/
+  скоуп/backward-compat для репо без тест-контракта, never-raise/fail-safe, изоляцию
+  процесса/таймаут (tree-kill), гибрид (LLM не в control-path вердикта), наблюдаемость,
+  и анти-дрейф инвариант (STAGE_TRANSITIONS/QG_CHECKS/check_tests_passed/_parse_tests_verdict/
+  схема БД не тронуты). Вне покрытия: Phase 2 (project test contract для не-self репо,
+  off-control-path LLM-триаж), ORCH-115 staging/deploy-раннер, LLM-роли reviewer/developer,
+  живой Claude CLI и живой прод-стенд (мокируются).
+notes: >
+  Тесты не требуют живого Claude CLI или сети: subprocess/pytest-run (proc_group) и
+  advance_stage мокируются; пьюр-маппинг и рендер frontmatter тестируются напрямую;
+  smoke-GET мокируются. Полный регресс tests/ должен оставаться зелёным. Анти-дрейф
+  (TC-09) защищает критический инвариант NFR-1. Эталон реализации/покрытия —
+  tests/test_orch115_staging_runner.py (ORCH-115).
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "applies(repo): enabled=False -> False (откат к LLM); пустой CSV -> True только для orchestrator; непустой CSV -> membership; репо без резолвимого тест-контракта -> False (BR-9 backward-compat); ошибка -> False (never-raise, fail-safe)."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Маппинг exit-кода: 0 -> PASS; 1/2/любой ненулевой -> FAIL; None/нечисло/ошибка запуска -> FAIL (fail-closed). Токены PASS/FAIL согласованы с _parse_tests_verdict; второй несогласованный маппинг не вводится."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Рендер 13-test-report.md: frontmatter содержит result: PASS|FAIL (UPPERCASE) + 52c-схему (work_item/stage=testing/author_agent=test-runner/status/created_at/model_used=n/a); хвост stdout pytest и smoke-итог копируются в тело."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-04
+    type: integration
+    description: "Сгенерированный раннером 13-test-report.md читается НЕИЗМЕНЁННЫМ _parse_tests_verdict -> корректный (bool, reason) для PASS и FAIL (контракт артефакта/гейта check_tests_passed неизменен)."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-05
+    type: integration
+    description: "launch_job перехватывает tester-джоб на стадии testing для in-scope репо ДО _spawn (как D1/D2/ORCH-115): _spawn НЕ вызывается, agent_runs не создаётся, возвращается None, jobs-строка ведётся mark_job. _spawn мокирован."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-06
+    type: integration
+    description: "Дискриминатор: tester-джоб на стадии НЕ testing (защита) и любой не-tester джоб НЕ перехватываются раннером; should_intercept never-raise -> False при DB-сбое (fall-through к _spawn)."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "После PASS-вердикта раннер инициирует advance_stage(finished_agent='tester') ровно как завершившийся LLM-tester (advance_stage мокирован/наблюдается) -> check_tests_passed -> testing->deploy-staging; после FAIL — существующий откат testing->development + developer-retry (stage_engine.py:849)."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "Kill-switch: test_runner_enabled=False -> на testing для orchestrator вызывается _spawn (прежний LLM-путь байт-в-байт), раннер не активируется."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Анти-дрейф NFR-1: STAGE_TRANSITIONS (src/stages.py), реестр/имена QG_CHECKS, check_tests_passed/_parse_tests_verdict и токены result:/verdict:/status: неизменны; в схеме БД нет новой таблицы/колонки от ORCH-116. Структурная проверка."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "Two-level outcome (анти-ORCH-110): сюита НЕ исполнилась (spawn-error/таймаут/returncode None) -> bounded DEFER (re-queue tester-джоба + restart-safe маркер), БЕЗ отката на development и БЕЗ расхода developer-retry; на исчерпании test_runner_infra_max_retries -> fail-closed FAIL + advance + INFRA-alert. Никогда тихий advance/ложный green."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "never-raise/fail-safe: pytest-run бросает/таймаутит/worktree-ошибка -> раннер не падает, исход FAIL (fail-closed) или bounded DEFER, никогда тихий advance/ложный green; воркер/очередь не клинятся. Все публичные функции test_runner.py never-raise."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "Изоляция/таймаут: pytest исполняется в worktree ветки задачи через proc_group.run_in_process_group (tree-kill); test_runner_timeout_s применяется; малформ/непозитив -> дефолт 900 + WARNING (never-break); reaper_max_running_s не правится."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-13
+    type: unit
+    description: "Self-hosting safety: в командах раннера нет запрещённых литералов (рестарт 8500 / docker compose up orchestrator / --build / force-push main / правки .env); smoke-запросы строго read-only GET (/health,/status,/queue); лог пушится только в фичеветку."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-14
+    type: integration
+    description: "Наблюдаемость + гибрид: GET /queue содержит блок test_runner (enabled/repos/target/счётчики runs/pass/fail/tool_error/deferred); на прогон пишется один структурный лог-вердикт, различающий код-фейл и tool-error; LLM не вызывается для вынесения result: в happy/fail-path."
+    module: tests/test_orch116_test_runner.py
+    expected: PASS
+
+  - id: TC-15
+    type: integration
+    description: "Анти-дрейф LLM-карты: llm-call-sites.md (A5)/roadmap (rank 2)/policy обновлены под реализацию (инвариант 'ровно один first_slice=yes' цел); tests/test_llm_call_site_inventory.py и tests/test_llm_determinization_docs.py остаются зелёными после правок."
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS

docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md

@@ -0,0 +1,471 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Детерминированный test-раннер вместо LLM-тестера на стадии `testing`
+
+Work Item: **ORCH-116** — заменить LLM-агента `tester` на стадии `testing`
+(self-hosting `orchestrator`) детерминированным test-раннером (второй срез
+determinization-roadmap, **rank 2 / tester-гибрид**).
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0050-deterministic-test-runner.md`**
+(решение кросс-каттинговое — вводит новый компонент-leaf `src/test_runner.py` и реализует
+второй срез determinization-roadmap; влияет на карту LLM-консультаций всего оркестратора).
+
+## Статус
+Proposed
+
+## Контекст
+
+Стадию `testing` сейчас исполняет **LLM-агент `tester`**. Маршрутизация (сверено по коду
+`src/stages.py:17-18`):
+
+```python
+"review":  {"next": "testing",        "agent": "tester",   "qg": "check_reviewer_verdict"},
+"testing": {"next": "deploy-staging", "agent": "deployer", "qg": "check_tests_passed"},
+```
+
+То есть `tester` — **единственный** агент, запускаемый при входе в `testing` (поле `agent`
+ребра `review → testing`); гейт выхода из `testing` — `check_tests_passed`. Фактическая работа
+агента на этой стадии в happy-path — **в основном детерминированная** (`.openclaw/agents/tester.md`):
+прогнать регресс `pytest tests/` в worktree ветки, сделать read-only smoke (`/health`, `/status`,
+`/queue` + наличие блока `serial_gate`), смаппить exit-код, записать `13-test-report.md` с
+машинным frontmatter `result: PASS|FAIL`.
+
+Вердикт `result:` потребляется **детерминированным** гейтом `check_tests_passed`
+(`src/qg/checks.py:182` → `_parse_tests_verdict:226`), который читает **только** YAML-frontmatter
+(`result:` канонический + legacy `verdict:`/`status:`, ORCH-047) — **не** прозу и **не** покрытие
+TC. По нормативной политике (`docs/architecture/llm-usage-policy.md`) это **avoidable LLM control
+path**: (i) C-консультация (вердикт `result:` ветвит гейт) **и** (ii) вердикт **деривируем** из
+exit-кода `pytest` + smoke. Карта (`docs/architecture/llm-call-sites.md`, строка **A5**)
+классифицирует tester как **`needs-hybrid-fallback`**; roadmap
+(`llm-determinization-roadmap.md`, машинный блок §4) ставит его **rank 2** (`hybrid_needed = yes`,
+`first_slice = no`). ORCH-116 — реализация этого второго среза (первый, **ORCH-115/deployer**,
+уже реализован — `src/staging_runner.py`).
+
+**Гибридная природа (ключевое отличие от ORCH-115).** Tester — `needs-hybrid-fallback`, не
+`replace-deterministic-now`: его **PASS/FAIL-ядро** полностью детерминируемо (exit-код pytest +
+smoke), но прежний промпт нёс ещё и **настоящее суждение** — триаж падений, анализ пробелов
+покрытия AC, сопоставление TC ↔ критерии приёмки, человекочитаемую диагностику. ORCH-116 выносит
+из потока управления **только PASS/FAIL-исполнителя** (его делает детерминированный код); LLM на
+стадии `testing` остаётся допустимым лишь как **off-control-path** триаж/диагностика **после**
+детерминированного провала и **никогда** как первичный исполнитель вердикта гейта (BR-8 / NFR-7).
+В Phase 1 off-control-path-триаж **не реализуется**, но архитектура его **не запрещает**.
+
+**Установленные факты (сверено по коду, не изобретать):**
+- Детерминированный прецедент замены агента **до `_spawn`** работает в проде: `launch_job`
+  перехватывает `deploy-finalizer` (D1, `src/agents/launcher.py:397`), `post-deploy-monitor`
+  (D2, `:402`) и **staging-runner** (ORCH-115, `:404-408`) до `_spawn`; `_run_staging_runner_job`
+  (`:438`) — тонкая обёртка, синхронно ведущая `jobs`-строку через `mark_job` и возвращающая `None`.
+- **Эталон leaf-раннера** — `src/staging_runner.py` (ORCH-115): two-level outcome, never-raise,
+  kill-switch + скоуп-CSV, `proc_group`, маппинг exit-кода единым контрактом, best-effort push в
+  фичеветку, инициация гейта через `advance_stage`, in-process счётчики. ORCH-116 — его зеркало для
+  роли `tester` / стадии `testing`.
+- Гейт `check_tests_passed` (`src/qg/checks.py:182`) читает `13-test-report.md` через
+  `_repo_path(repo, branch)` (`:15`), который **читает per-branch worktree первым** (если каталог
+  существует), иначе — общий клон. Значит worktree-записанный файл читается напрямую — **отдельный
+  merge лога в `main` не нужен**.
+- FAIL-маршрут существует и зафиксирован: `src/stage_engine.py:849` —
+  `if agent == "tester" and qg_name == "check_tests_passed"` → откат `testing → development` +
+  `extract_test_failures` + `enqueue_job("developer", …)` (cap `MAX_DEVELOPER_RETRIES=3`,
+  `:862-892`). Ветвь матчит по `agent == "tester"` — раннер обязан инициировать гейт с
+  `finished_agent="tester"`.
+- Tree-kill subprocess'а под таймаутом готов: `proc_group.run_in_process_group` (ORCH-110,
+  stdlib-only, never-raise, fallback к `subprocess.run`). pytest уже исполняется в worktree через
+  него в coverage-gate (ORCH-027) и merge-gate re-test (ORCH-110) — тот же контейнер, без новых
+  зависимостей образа.
+- Пьюр-маппинг exit-кода готов: `self_deploy.map_exit_code_to_status` (`0→SUCCESS`, иначе/None/
+  нечисло→`FAILED`, fail-closed, unit-tested). ORCH-116 переиспользует его, транслируя токены в
+  `PASS`/`FAIL`.
+
+«Как есть» не годится: каждый прогон tester'а тратит токены/время opus-агента (по `agent_runs`:
+~60–150k / 5–20 мин на прогон) ради действия = один прогон pytest + несколько read-only GET,
+встраивает недетерминизм LLM в точку ветвления `testing → deploy-staging` / `testing → development`
+и принадлежит к RCA-классу «LLM принял решение, которое есть исполнение фиксированных команд +
+маппинг результата» (ORCH-110/111/112/113/114/117/115).
+
+## Решение
+
+### Сводка
+
+Ввести **новый leaf `src/test_runner.py`** (never-raise, по образцу `staging_runner.py`/
+`self_deploy.py`/`proc_group.py`) и **перехват в `launch_job` до `_spawn`** (рядом с D1/D2/ORCH-115).
+Когда на стадии `testing` для in-scope репо с тест-контрактом к запуску приходит джоб `tester`, его
+обрабатывает раннер: исполняет «тест-контракт» (регресс `pytest <target>` в worktree ветки через
+`proc_group` + опциональный read-only smoke), маппит exit-код в `result:` (`0→PASS`, иначе `FAIL`),
+пишет `13-test-report.md`, best-effort пушит лог в фичеветку, и вызывает **существующий**
+`advance_stage(current_stage="testing", finished_agent="tester")` — ровно как завершившийся
+LLM-tester. Контракт артефакта, гейт `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`,
+схема БД — **байт-в-байт неизменны** (это замена *продюсера* артефакта, не гейта). Под kill-switch +
+скоуп-CSV + резолв тест-контракта; never-raise; fail-closed; two-level outcome (анти-ORCH-110);
+fail-safe к прежнему LLM-пути.
+
+### D1 — Точка диспетчеризации: перехват в `launch_job` **до** `_spawn` (FR-1 / AC-1)
+
+В `launcher.launch_job`, рядом с врезками D1/D2/ORCH-115, **до** `_spawn`:
+
+```python
+if job.get("agent") == "tester":
+    from .. import test_runner
+    if test_runner.should_intercept(job):
+        return self._run_test_runner_job(job)
+```
+
+- **Дискриминатор перехвата — роль `tester` + стадия задачи + `applies(repo)`.**
+  `should_intercept(job)` истинно ⇔ `agent == "tester"` **И** `applies(job["repo"])` **И**
+  `tasks.stage` (по `job["task_id"]`) `== "testing"`.
+- **Отличие от ORCH-115 (важно, R-1).** Роль `deployer` была **общей** для `deploy-staging` и
+  `deploy`, поэтому гард по стадии у staging-раннера был обязателен для дизамбигуации «staging vs
+  prod». Роль `tester` исполняет **только** стадию `testing` (единственный `agent` входа в `testing`,
+  `STAGE_TRANSITIONS["review"]["agent"]`), коллизии стадий нет — но гард `tasks.stage == "testing"`
+  сохраняется как **defense-in-depth** (симметрия с ORCH-115 + защита от перехвата случайного
+  будущего `tester`-джоба вне `testing`).
+- `should_intercept` / `applies` — **never-raise → False**: любая ошибка (DB-lookup упал) → провал в
+  `_spawn` (fail-safe к прежнему LLM-пути).
+- `_run_test_runner_job(job)` — тонкая обёртка-зеркало `_run_staging_runner_job` (`:438`):
+  синхронно зовёт `test_runner.run_test_gate(job)`, затем `mark_job(job["id"], "done")`; любое
+  исключение → `mark_job(..., "failed", error=…)`; возвращает `None` (нет `agent_runs`-строки,
+  `_spawn` не вызывается, токены LLM не тратятся).
+
+### D2 — Размещение логики: чистый leaf `src/test_runner.py` (зеркало `staging_runner`)
+
+`run_test_gate(job)` живёт в leaf'е и владеет полным детерминированным потоком (зеркало
+`staging_runner.run_staging_gate`):
+1. поднять `work_item_id`/`branch` по `task_id`;
+2. исполнить тест-контракт (D3) → `ProcResult` (pytest) + smoke-итог;
+3. определить исход (D5);
+4. на verdict-исходе: записать `13-test-report.md` (D6) и вызвать
+   `advance_stage(finished_agent="tester")` (D7);
+5. на tool-error-исходе: bounded DEFER (D5);
+6. учесть счётчики + структурный лог (D10).
+
+**Чистота leaf'а:** импортирует на уровне модуля только `config`, `logging` (+ `proc_group`);
+лениво (внутри функций) — `db`/`git_worktree`/`self_deploy.map_exit_code_to_status`/
+`qg.checks.is_self_hosting_repo`/`stage_engine.advance_stage`/`notifications`. Лениво — чтобы не
+тащить тяжёлый `stage_engine` на импорте и не плодить цикл (паттерн `staging_runner`/
+`transition_lease`/`merge_gate`). Все публичные функции — **never-raise** (AC-9).
+
+### D3 — Исполнение тест-контракта: pytest (в worktree) + опц. smoke через `proc_group` (FR-2 / NFR-3 / AC-10 / AC-11)
+
+**Тест-контракт = (обязательная регресс-команда) + (опциональный read-only smoke).**
+
+- **Регресс:** `python -m pytest <test_runner_target>` (дефолт `tests/`, конвенция
+  `merge_retest_target`) исполняется **в worktree ветки задачи** —
+  `git_worktree.get_worktree_path(repo, branch)`, **НЕ** в общем `/repos/orchestrator` (анти
+  checkout-гонка, как требовал промпт tester шаг 2; тот же контекст, что coverage-gate/merge-gate
+  re-test) — через `proc_group.run_in_process_group(argv, cwd=<worktree>, timeout=<test_runner_timeout_s>,
+  grace_s=agent_kill_grace_seconds, tree_kill=subprocess_tree_kill_enabled)` → SIGTERM→grace→SIGKILL
+  всего дерева на таймауте, без сирот pytest (корень ORCH-109/110/111 закрыт). Захватывает exit-код и
+  stdout (для тела отчёта/observability).
+- **Опциональный smoke** (`test_runner_smoke_enabled`, дефолт `True`; зеркало шага 3 промпта tester):
+  read-only `GET` против запущенного оркестратора (base URL из config — host-параметризация ORCH-101,
+  без host-хардкодов): `/health`, `/status`, `/queue` + проверка **наличия** блока `serial_gate` в
+  ответе `/queue`. **Smoke строго read-only** (BR-7/AC-10): никаких мутирующих запросов.
+- **Итоговый verdict-токен** = `PASS` ⇔ (exit-код pytest == 0 по маппингу D4) **И** smoke прошёл
+  (если включён); иначе `FAIL`. Smoke-провал → `FAIL` (детерминированно, FR-2).
+- **Анти-флап smoke (уточнение архитектора):** транзиентная **недостижимость** smoke-эндпоинта
+  (connection refused / таймаут на единичном GET) ретраится **ограниченно** внутри smoke-шага
+  (несколько быстрых GET с коротким backoff) перед выводом `FAIL`; «достижимо, но форма неверна»
+  (не-200 / нет блока `serial_gate`) → немедленный `FAIL`. Это снижает риск, что разовый блип
+  прод-8500 откатит здоровую ветку, не вводя нового исхода (на исчерпании smoke-ретраев — обычный
+  `FAIL`, поглощаемый developer-retry-cap). Гард `test_runner_smoke_enabled` позволяет отключить
+  smoke, если он окажется шумным, без отката всего раннера.
+
+**Self-hosting safety (BR-7 / AC-10):** в argv раннера нет литералов рестарта 8500 /
+`docker compose up … orchestrator` / `--build` / force-push / правок `.env`/`docker-compose.yml`.
+Раннер только исполняет pytest в worktree и делает read-only GET. Покрывается тестом запрета
+литералов в его командах (зеркало TC ORCH-115).
+
+### D4 — Маппинг exit-кода → `result:`: переиспользовать единый контракт (FR-3 / AC-3)
+
+`result`-токен = трансляция `self_deploy.map_exit_code_to_status(returncode)`:
+`SUCCESS → "PASS"`, `FAILED → "FAIL"` (т.е. `0 → PASS`; ненулевой / None / нечисло → `FAIL`,
+fail-closed). **Второй несогласованный маппинг не вводится** — переиспользуется тот же пьюр-контракт
+(`0→SUCCESS`-семантика, unit-tested), что у deploy-finalizer и staging-runner (BR-4). Разница лишь в
+токенах (`result:` использует `PASS`/`FAIL`, а не `SUCCESS`/`FAILED`; `_TESTS_POSITIVE_TOKENS`/
+`_TESTS_NEGATIVE_TOKENS`, `src/qg/checks.py:222-223`) — тонкая обёртка-транслятор поверх единого
+маппера, не дубль логики. Smoke-результат **AND**-ится в итог отдельно (D3), exit-маппинг остаётся
+чистой функцией одного входа (покрыт unit-тестом на каждый класс: `0`/≠0/`None`/нечисло).
+
+### D5 — Двухуровневый исход: verdict vs tool-error (NFR-2 / AC-5 / R-4) — **ключевое решение**
+
+Выбран **двухуровневый исход** (зеркало `staging_runner` D5, анти-ORCH-110):
+
+- **Сюита ИСПОЛНИЛАСЬ** (`returncode is not None` и **не** `timed_out`) → доверяем коду: маппинг D4
+  (+ smoke D3) → `result:` → инициировать гейт (D7). `PASS → testing → deploy-staging`;
+  `FAIL → существующий откат testing → development` + developer-retry (тот же путь и cap
+  `MAX_DEVELOPER_RETRIES`, что у FAIL-вердикта LLM — `stage_engine.py:849-892`; R-5/AC-4).
+- **Сюита НЕ исполнилась** (tool-error: spawn-error / таймаут / `returncode is None`) — это
+  **инфра-сбой, а не код-фейл**. Раннер делает **ограниченный DEFER**: re-queue свежего **`tester`**-джоба
+  с задержкой `test_runner_infra_retry_delay_s` и **restart-safe маркером** `test-runner infra-retry`
+  в `task_content` (счётчик — `COUNT(*)` маркера в persisted `jobs`, зеркало
+  `staging_runner._infra_retry_count` / `stage_engine._merge_infra_retry_count`; **без правки схемы
+  БД**, NFR-1). На **исчерпании** бюджета (`test_runner_infra_max_retries`) — **fail-closed**:
+  записать `result: FAIL` + `advance_stage` (существующий откат) + один INFRA-alert (кликабельный
+  номер, явно «инфра, НЕ дефект кода»). Так раннер **никогда** не делает тихий advance / ложный green
+  и **никогда** не клинит очередь навсегда, но **не жжёт developer-retry на транзиентной инфре**.
+
+**Почему не «tool-error → немедленный FAIL-откат»:** это в точности анти-паттерн ORCH-110
+(инфра-таймаут, ошибочно маршрутизированный как код-фейл → откат на `development` + расход
+developer-retry; на следующем retry падает так же → ручное вмешательство). Пьюр-маппинг D4 остаётся
+fail-closed (None→FAIL) — это терминальный fallback **на исчерпании** defer, а не реакция на первый
+же tool-error. **DEFER re-queue'ит `tester`-джоб** (не `deployer`!) — он повторно входит в этот же
+раннер.
+
+### D6 — Артефакт `13-test-report.md`: зеркало `write_staging_log` (FR-4 / AC-2 / AC-10)
+
+Раннер пишет `docs/work-items/<work_item_id>/13-test-report.md` в worktree фичеветки
+(`git_worktree.get_worktree_path`) литеральным блоком (как `staging_runner.build_staging_log`),
+чтобы машинно-читаемый frontmatter был байт-точным:
+
+```markdown
+---
+result: PASS                  # или FAIL — UPPERCASE, имя/регистр/токены ключа НЕ меняются
+work_item: <work_item_id>
+stage: testing
+author_agent: test-runner
+status: success               # или failed — ВЫРОВНЕН по result (см. D6.1!)
+created_at: <YYYY-MM-DD>
+model_used: n/a
+exit_code: <returncode>
+smoke: <ok|failed|skipped>
+---
+
+# Test Gate Log (deterministic runner, ORCH-116)
+<exit-код pytest, краткий хвост stdout, итог smoke; вердикт зафиксирован детерминированным
+test-раннером, не LLM>
+```
+
+- `author_agent: test-runner` / `model_used: n/a` честно отражают **детерминированного** продюсера;
+  **machine-key `result:` и его UPPERCASE-значения/токены не меняются** (AC-2), читается
+  неизменённым `_parse_tests_verdict`.
+- Обязательная 52c-схема присутствует (`work_item`/`stage: testing`/`author_agent`/`status`/
+  `created_at`/`model_used`).
+- **Best-effort `git add/commit/push` в ФИЧЕВЕТКУ** (git-identity ORCH-101, актор `test-runner`,
+  `_GIT_TIMEOUT`). Гейт читает worktree **первым** (`_repo_path:22-25`), поэтому **отдельный
+  PR-merge лога в `main` НЕ выполняется** — исключение любой прямой работы с `main` усиливает
+  AC-10/BR-7. Итоговый мерж фичеветки в `main` идёт штатным merge-gate/merge-verify-путём позже.
+
+#### D6.1 — Анти-коллизия 52c-`status:` ↔ парсер вердикта (**специфично для tester, отсутствует в ORCH-115**)
+
+**Сверено по коду:** `_parse_tests_verdict` (`src/qg/checks.py:263-277`) читает вердикт из **трёх**
+равноранговых полей — `verdict:`, **`status:`** и `result:` — и применяет **negative-token-priority**:
+любой негативный токен (`BLOCKED`/`FAILED`/`FAIL`/`REQUEST_CHANGES`/`REJECT`/`RED`) в `f"{verdict}
+{status} {result}"` делает вердикт `False` авторитетно. У staging-гейта (ORCH-115) такой коллизии
+**не было**: `_parse_staging_status` читает только `staging_status:`, а 52c-`status:` ему безразличен.
+Здесь 52c-обязательное поле `status:` **читается тем же парсером, что и `result:`**.
+
+**Следствие-мина:** если 52c-`status:` принимает значение, чей UPPERCASE содержит негативный токен
+(например `status: failed` → `"FAILED"`), при `result: PASS` парсер вернёт `False` (негативный токен
+авторитетнее) — **ложный FAIL** здорового прогона.
+
+**Решение (инвариант):** 52c-`status:` раннера **ВСЕГДА выровнен по вердикту** и **никогда не
+противоречит** `result:`:
+- `result: PASS` → `status: success` (`"SUCCESS"` — не позитивный и **не** негативный токен;
+  положительный токен `PASS` берётся из `result:` → парсер даёт `True`);
+- `result: FAIL` → `status: failed` (`"FAILED"` — негативный токен, согласован с `FAIL` → `False`).
+
+Это **тот же приём**, что `staging_runner.build_staging_log` (`status: success|failed` выровнен по
+verdict'у) — но здесь он **обязателен по корректности**, а не косметика. Анти-дрейф: unit-тест,
+проверяющий `_parse_tests_verdict(<тело раннера для PASS>) == (True, …)` и
+`(<тело для FAIL>) == (False, …)` **через неизменённый парсер** (фиксирует, что 52c-`status:` не
+ломает вердикт). Reviewer ловит любой `status:`-литерал с негативным токеном при `result: PASS` как
+finding ≥P1.
+
+### D7 — Инициация существующего гейта (FR-5 / AC-4 / R-2, граница O1)
+
+После записи (и best-effort push) раннер вызывает:
+```python
+advance_stage(task_id, current_stage="testing", repo, work_item_id, branch,
+              finished_agent="tester")
+```
+Это запускает `check_tests_passed` (`_parse_tests_verdict` читает `result:` из `13-test-report.md`):
+- `PASS` → продвижение `testing → deploy-staging` (и далее под-гейты ORCH-022/043/027/058 на ребре
+  `deploy-staging → deploy` — **их раннер не трогает**);
+- `FAIL` → существующий откат `testing → development` + developer-retry (`stage_engine.py:849`).
+
+**`finished_agent="tester"` обязателен** (R-2): FAIL-ветвь матчит по `agent == "tester" and
+qg_name == "check_tests_passed"` (`:849`); иной/`None` агент не запустит откат. **Никакой новой
+ветви маршрутизации, никаких новых рёбер/исходов** (AC-4). **Граница O1:** transition-lease ORCH-114
+берётся **внутри** `advance_stage` на side-effectful переходе — раннер его **не трогает**;
+serial-gate ORCH-088 не взаимодействует (гейтит analyst-job claim). Код ORCH-112/ORCH-114/ORCH-115
+(`staging_runner`) **не модифицируется**. never-raise.
+
+### D8 — Kill-switch, скоуп и резолв тест-контракта: обратимость + backward-compat (FR-7 / AC-7 / AC-8 / BR-5 / BR-9)
+
+`config.py` (паттерн `staging_runner_*`/`coverage_gate_*`):
+- `test_runner_enabled: bool = True` (env `ORCH_TEST_RUNNER_ENABLED`).
+- `test_runner_repos: str = ""` (env `ORCH_TEST_RUNNER_REPOS`; CSV; **пусто → self-hosting only**
+  через `is_self_hosting_repo`).
+- `test_runner_target: str = "tests/"` (env `ORCH_TEST_RUNNER_TARGET`; pytest-таргет, конвенция
+  `merge_retest_target`).
+- `test_runner_timeout_s: int = 900` (env `ORCH_TEST_RUNNER_TIMEOUT_S`; см. D9).
+- `test_runner_smoke_enabled: bool = True` (env `ORCH_TEST_RUNNER_SMOKE_ENABLED`).
+- `test_runner_infra_max_retries: int = 2`, `test_runner_infra_retry_delay_s: int = 30`
+  (defer-бюджет D5; зеркало `staging_runner_infra_*`).
+
+`applies(repo)` (локально, без сети, **never-raise → False**) — **проверяется первым** в
+`should_intercept` (нулевой оверхед при выключенном флаге):
+```text
+1. test_runner_enabled == False                  -> False  (откат к LLM-пути)
+2. in_scope = (membership в test_runner_repos)   если CSV непуст
+            = is_self_hosting_repo(repo)          если CSV пуст
+   not in_scope                                  -> False
+3. _has_test_contract(repo)                       -> резолв тест-контракта (BR-9)
+```
+**`_has_test_contract(repo)` (BR-9 / AC-8) — отличие от ORCH-115.** У staging-раннера тест-контракт
+был неявно self-hosting-bound (staging-контейнер существует только для `orchestrator`), отдельной
+проверки не требовалось. Здесь резолв контракта вынесен явно: в **Phase 1** контракт известен по
+умолчанию **только** для self-hosting (`return is_self_hosting_repo(repo)` — pytest+smoke);
+для прочих репо контракта нет, пока не сконфигурирован (Phase 2) → `applies == False` →
+**прежний LLM-tester** (fail-safe). Это делает AC-8 проверяемым: даже если в `test_runner_repos`
+руками добавить не-self репо (`enduro-trails`), `_has_test_contract` вернёт `False` → раннер его не
+перехватит → LLM-tester. enduro-trails и любой репо без контракта — 1:1 как до ORCH-116.
+
+Откат = `ORCH_TEST_RUNNER_ENABLED=false` → `applies()` → `False` → `should_intercept` → `False` →
+штатный `_spawn` прежнего LLM-tester'а на `testing` **байт-в-байт**.
+
+### D9 — Бюджет времени (NFR-4 / AC-11, сквозной инвариант ORCH-065/109/110)
+
+`test_runner_timeout_s = 900` (дефолт; малформ/непозитив → дефолт + WARNING, never-break — зеркало
+`staging_runner._resolve_timeout` / `merge_gate._resolve_retest_timeout`). Обоснование **без правки
+`reaper_max_running_s` (5400)**:
+
+- **Ребро `testing` отдельно от ребра `deploy-staging`.** Гейт выхода из `testing` —
+  `check_tests_passed` (читает файл, мгновенно). Окно «running» одного `tester`-джоба = только
+  pytest+smoke (≤900s); тяжёлые под-гейты (security/merge re-test/coverage/image-freshness) живут на
+  ребре `deploy-staging → deploy`, **не** на `testing`.
+- **Σ(работ на ребре `testing`) НЕ растёт.** Прежний LLM-tester шёл под `agent_timeout_seconds`
+  (сверено `config.py:159` = **1800s**; tester не имеет выделенного per-role ключа, в отличие от
+  developer=3600/reviewer=3000). Раннер заменяет ≤1800s LLM-окно ограниченными ≤900s →
+  `reaper_max_running_s (5400) > 900 + grace` сохранён **без** изменения reaper'а. Выбор 900s
+  согласован с фактической длительностью регресс-сюиты (~517s, инцидент ORCH-110) и даёт ~74% запаса —
+  тот же запас, что merge-retest-бюджет ORCH-110.
+
+### D10 — Наблюдаемость (FR-8 / AC-13 / BR-6)
+
+In-process счётчики `_TEST_RUNNER_COUNTERS` (зеркало `_STAGING_RUNNER_COUNTERS` /
+`_MERGE_GATE_COUNTERS`): `runs`/`pass`/`fail`/`tool_error`/`deferred`. Read-only блок `test_runner` в
+`GET /queue` (`enabled`/`repos`/`target`/`timeout_s`/`infra_max_retries`/счётчики) — `src/main.py`,
+аддитивно, существующие ключи не трогаются. Один структурный лог-вердикт на прогон:
+`work_item`/`repo`/`exit_code`/`result`/`duration_s`/`outcome` — различает «код упал» (`FAIL` от
+сюиты/smoke) и «инструмент недоступен» (`tool_error`/`deferred`). Новых мутирующих эндпоинтов нет;
+откат — через env-флаг.
+
+### D11 — Гибрид: LLM строго off-control-path (BR-8 / NFR-7 / FR-9 / AC-12)
+
+В Phase 1 на стадии `testing` (in-scope) вердикт `result:` производит **только** детерминированный
+раннер; LLM **не вызывается** в потоке управления вердикта (ни happy-path, ни fail-path). Архитектура
+раннера **не запрещает** будущий **опциональный off-control-path** LLM-триаж/диагностику **после**
+детерминированного FAIL — но он будет **отдельной ролью/джобом**, который **не пишет и не
+переопределяет** `result:` и **не добавляет ребро** в `STAGE_TRANSITIONS`. В этом срезе он **не
+реализуется**. Это сохраняет `needs-hybrid-fallback`-природу A5: детерминированное ядро + (будущий)
+LLM-фолбэк только на суждение.
+
+### D12 — Норматив сопровождения LLM-карты/политики/витрины (NFR-6 / AC-14) — спека для developer
+
+Карта/политика/roadmap и их анти-дрейф-тесты **связаны с состоянием кода**, поэтому правятся
+**в development-стадии атомарно с кодом** (иначе тесты покраснеют на полу-готовой ветке — это же
+причина, по которой ORCH-115 не правил их в architecture; зеркало ORCH-115 D11). README/internals/
+паспорт/чейнджлог/витрина — там же. Архитектура фиксирует **точную спеку** правок (developer
+применяет в том же PR):
+
+- `docs/architecture/llm-call-sites.md` — строка **A5** и машинный `ORCH-118-INVENTORY-BLOCK`:
+  tester на `testing` для in-scope репо больше не консультирует LLM в потоке управления; отразить
+  реализованное детерминированное состояние (раннер-перехват до `_spawn`, как D1/D2), **сохранив**
+  `avoidable=yes`/`axis=C`/`classification=needs-hybrid-fallback` (LLM-ветвь жива как fallback под
+  выключенным флагом / для не-self репо / как будущий off-control-path триаж) — **зеркало** того, как
+  ORCH-115 обновил A6/deployer. Заголовок таблицы и `output_consumer = _parse_tests_verdict` не
+  менять (имя гейта/парсера неизменно).
+- `docs/architecture/llm-determinization-roadmap.md` — §2 (tester) и машинный
+  `ORCH-118-ROADMAP-BLOCK` rank 2: «второй кандидат» → «реализован (ORCH-116)». **Инвариант «ровно
+  один `first_slice = yes`» держать корректным** — `first_slice` остаётся `yes` у **rank 1
+  (deployer)**, у rank 2 (tester) — `no`; **не переключать** (см.
+  `test_llm_determinization_docs.py`). `hybrid_needed = yes` у tester сохраняется (гибрид-природа).
+- `docs/architecture/llm-usage-policy.md` — §5: единственный транспорт LLM-консультации
+  (`_spawn`/S0) не нарушен; раннер LLM не зовёт; будущий off-control-path триаж — **не** новый
+  транспорт control-path-консультации (он вне control-path).
+- Анти-дрейф `tests/test_llm_call_site_inventory.py` / `tests/test_llm_determinization_docs.py` —
+  обновить ожидания синхронно, держать зелёными (AC-14).
+- Прочие docs того же PR (правило агентов №2 + витрина ORCH-011): `.openclaw/agents/tester.md`
+  (пометка, что на `testing` для in-scope репо стадию ведёт детерминированный код; LLM-ветвь —
+  fallback под выключенным флагом / для репо без контракта; канон промпта 52d — 5 секций, ключ
+  `result:` — байт-в-байт), `docs/architecture/README.md` (новый компонент **Test-runner** в
+  карте — зеркало записи **Staging-runner** + отметка «второй срез реализован» в блоке roadmap),
+  `docs/architecture/internals.md` (примечание о перехвате на `testing`, рядом с ORCH-115),
+  `CLAUDE.md`, `CHANGELOG.md`, `docs/overview/`.
+
+**Обоснование против `llm-usage-policy.md` §5:** ORCH-116 **снимает** C-консультацию с деривируемым
+PASS/FAIL-ядром (A5/tester) — это разрешённая реализация `needs-hybrid-fallback`, не ввод новой
+LLM-консультации; политика соблюдена.
+
+## Альтернативы
+
+- **Новая стадия / новый QG для детерминированного testing** — отвергнуто: нарушает NFR-1
+  (`STAGE_TRANSITIONS`/`QG_CHECKS` байт-в-байт). Меняется только *продюсер* артефакта; гейт и ребро
+  прежние.
+- **tool-error → немедленный `FAIL`-откат на `development`** — отвергнуто: анти-паттерн ORCH-110
+  (инфра-сбой как код-фейл → расход developer-retry → петля). Выбран двухуровневый исход D5.
+- **Свой второй exit-code→verdict маппинг** — отвергнуто: переиспользуем
+  `self_deploy.map_exit_code_to_status` (BR-4, единый контракт), тонкий транслятор токенов поверх.
+- **52c-`status:` произвольным значением (как чисто описательное поле)** — отвергнуто: `status:`
+  **читается** `_parse_tests_verdict` с negative-token-priority → негативный токен в `status:` при
+  `result: PASS` даёт ложный FAIL. Выбрано жёсткое выравнивание `status:` по вердикту (D6.1).
+- **Прогон pytest в общем `/repos/orchestrator`** — отвергнуто: checkout-гонка с другими задачами
+  (мина, закрытая ORCH-112); раннер исполняет pytest **в worktree ветки** (как coverage/merge-gate).
+- **Merge лога отдельным PR в `main`** (как прежний tester) — отвергнуто: гейт читает worktree первым
+  (`_repo_path`) → достаточно push в фичеветку; исключение прямой работы с `main` усиливает
+  AC-10/BR-7.
+- **Логика раннера прямо в `launcher.py`** — отвергнуто: нарушает разделение транспорт/решение; leaf
+  тестируем без живого CLI (зеркало `staging_runner`/`coverage_gate`).
+- **LLM-триаж как control-path-продюсер `result:`** — отвергнуто: BR-8/AC-12 (детерминированный
+  раннер — единственный исполнитель вердикта; триаж — off-control-path, Phase 2).
+- **Править `llm-call-sites.md`/roadmap/policy/README в architecture-стадии** — отвергнуто:
+  анти-дрейф-тесты коуплены к коду; правки идут атомарно с кодом (D12, как ORCH-115).
+- **DEFER через re-queue `deployer`-джоба** (копипаст из staging-раннера) — отвергнуто: DEFER должен
+  re-queue'ить **`tester`**-джоб (он повторно входит в этот раннер на стадии `testing`).
+
+## Последствия
+
+- **+** На `testing` для `orchestrator` исчезает LLM-консультация в потоке управления вердикта:
+  дешевле/быстрее/детерминированнее; минус один avoidable LLM control path (второй срез roadmap,
+  rank 2).
+- **+** Happy-path не вызывает `_spawn` (нет `agent_runs`-строки, нет токенов LLM на стадии `testing`).
+- **+** Полная обратимость одним флагом; артефакт/гейт/ребро/схема БД неизменны → переключение
+  туда-сюда не оставляет несовместимого состояния.
+- **+** Двухуровневый исход (D5) убирает класс ORCH-110 (инфра ≠ код-фейл) с `testing`-ребра.
+- **+** Гибрид-граница сохранена (D11): архитектура не закрывает путь к будущему off-control-path
+  LLM-триажу, не пуская LLM обратно в поток управления.
+- **−** Новый leaf + врезка в `launch_job` + defer-механика — рост поверхности кода. Митигейшн: leaf
+  never-raise + kill-switch (fail-safe к LLM), тонкая врезка-зеркало D1/D2/ORCH-115, defer-счётчик без
+  схемы БД (маркер в `task_content`), покрытие `tests/test_orch116_test_runner.py`.
+- **−** Smoke зависит от достижимости запущенного оркестратора (8500) — разовый блип мог бы дать
+  `FAIL`. Митигейшн: D3 (bounded smoke-ретрай транзиентной недостижимости + config-gate
+  `test_runner_smoke_enabled` + developer-retry-cap); pytest остаётся первичным сигналом.
+- **−** Тонкая мина 52c-`status:` ↔ парсер (D6.1) специфична для tester. Митигейшн: жёсткий инвариант
+  выравнивания + unit-тест через неизменённый парсер; reviewer-ось ≥P1.
+- **Откат:** `ORCH_TEST_RUNNER_ENABLED=false` → штатный `_spawn` LLM-tester'а на `testing`
+  **байт-в-байт** до ORCH-116.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-116/01-brd.md`
+- TRZ: `docs/work-items/ORCH-116/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-116/03-acceptance-criteria.md`
+- Тест-план: `docs/work-items/ORCH-116/04-test-plan.yaml`
+- Инфра: `docs/work-items/ORCH-116/07-infra-requirements.md`;
+  Данные: `08-data-requirements.md`; Риски: `10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0050-deterministic-test-runner.md`
+- Эталон реализации: `src/staging_runner.py` (ORCH-115),
+  `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`
+- Сверено по коду: `src/agents/launcher.py:397/404/438`, `src/stages.py:17-18`,
+  `src/qg/checks.py:15/182/222-223/226/263-277/528`, `src/stage_engine.py:849-892`,
+  `src/self_deploy.py` (`map_exit_code_to_status`), `src/proc_group.py`, `src/config.py:159/162`
+  (`agent_timeout_seconds`/`reaper_max_running_s`)
+- Политика/карта/roadmap: `docs/architecture/llm-usage-policy.md`,
+  `docs/architecture/llm-call-sites.md` (A5), `docs/architecture/llm-determinization-roadmap.md`
+  (rank 2)

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

@@ -0,0 +1,69 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфраструктурные требования: ORCH-116 — детерминированный test-раннер
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: architecture
+
+> Топология **не меняется** (всё в Docker на одном сервере mva154, SQLite, собственная очередь).
+> Раздел фиксирует **рантайм-предусловия** детерминированного раннера и подтверждает отсутствие
+> новых компонентов/портов/зависимостей образа.
+
+## 1. Топология — без изменений
+
+Новых контейнеров / сервисов / портов / сетей **нет**. Раннер исполняется **внутри уже работающего
+прод-контейнера `orchestrator` (8500)** как синхронный обработчик джоба `tester` (перехват в
+`launch_job` до `_spawn`) — там же, где сейчас стартует LLM-tester. Staging-контур (8501) для
+ORCH-116 **не используется** (в отличие от ORCH-115) — это ребро `testing`, а не `deploy-staging`.
+
+## 2. Рантайм-предусловия (предсуществующие, проверить)
+
+| # | Предусловие | Статус | Обоснование |
+|---|-------------|--------|-------------|
+| P-1 | `python -m pytest` исполним внутри прод/staging-образа | **уже выполнено** | pytest уже гоняется в worktree внутри этого же образа coverage-gate (ORCH-027) и merge-gate re-test (ORCH-110). Новых pip-зависимостей **нет** (в отличие от `pytest-cov` ORCH-027 — он не требуется: ORCH-116 читает только exit-код, не покрытие). |
+| P-2 | Per-branch worktree ветки задачи материализуем (`git_worktree.get_worktree_path`) | **уже выполнено** | механика worktree используется всеми гейтами/раннерами; раннер исполняет pytest **в worktree ветки** (анти checkout-гонка, ORCH-112), не в общем `/repos/orchestrator`. |
+| P-3 | `proc_group.run_in_process_group` (tree-kill) доступен на POSIX-хосте | **уже выполнено** | ORCH-110; fallback к `subprocess.run` на не-POSIX (`subprocess_tree_kill_enabled`). |
+| P-4 | Read-only smoke: запущенный оркестратор отвечает на `GET /health`, `/status`, `/queue` по config-резолвнутому base URL | **уже выполнено** | те же эндпоинты read-only опрашивал LLM-tester (шаг 3 промпта). Base URL — из config (host-параметризация ORCH-101, без host-хардкодов). Smoke **строго read-only**; опционален (`test_runner_smoke_enabled`). |
+| P-5 | git-identity актора `test-runner` для best-effort push лога в фичеветку | **уже выполнено** | HOME + email-домен из `settings` (ORCH-101), как у `staging-runner`. Push **только в фичеветку**, никогда в `main`/force-push. |
+
+## 3. Конфигурация (env, дефолт = боевое; пустой `.env` ⇒ поведение для in-scope)
+
+| Ключ | env | Дефолт | Назначение |
+|------|-----|--------|------------|
+| `test_runner_enabled` | `ORCH_TEST_RUNNER_ENABLED` | `True` | kill-switch (off → LLM-tester байт-в-байт) |
+| `test_runner_repos` | `ORCH_TEST_RUNNER_REPOS` | `""` | CSV-скоуп; пусто → self-hosting only |
+| `test_runner_target` | `ORCH_TEST_RUNNER_TARGET` | `tests/` | pytest-таргет тест-контракта |
+| `test_runner_timeout_s` | `ORCH_TEST_RUNNER_TIMEOUT_S` | `900` | таймаут pytest (D9; согласован со сквозным бюджетом ORCH-065/109/110 без правки `reaper_max_running_s`) |
+| `test_runner_smoke_enabled` | `ORCH_TEST_RUNNER_SMOKE_ENABLED` | `True` | опц. read-only smoke |
+| `test_runner_infra_max_retries` | `ORCH_TEST_RUNNER_INFRA_MAX_RETRIES` | `2` | бюджет tool-error DEFER (D5) |
+| `test_runner_infra_retry_delay_s` | `ORCH_TEST_RUNNER_INFRA_RETRY_DELAY_S` | `30` | задержка DEFER-re-queue |
+
+> `.env.example` пополнить этими ключами (канон старта, норматив ORCH-101). Изменений
+> `docker-compose.yml` / `Dockerfile` / образа **нет**.
+
+## 4. Сквозной бюджет времени (NFR-4)
+
+Ребро `testing` отдельно от `deploy-staging`. Окно «running» `tester`-джоба = только pytest+smoke
+(≤`test_runner_timeout_s`=900s); тяжёлые под-гейты (security/merge/coverage/image-freshness) живут на
+ребре `deploy-staging → deploy`. Прежний LLM-tester шёл под `agent_timeout_seconds`=1800s
+(`config.py:159`; tester без выделенного per-role ключа). 900 < 1800 → Σ(работ на ребре `testing`)
+**не растёт** → инвариант `reaper_max_running_s (5400) > Σ + grace` сохранён **без** правки reaper'а.
+
+## 5. Self-hosting safety (BR-7 / AC-10)
+
+Раннер на `testing` **никогда** не рестартит контейнер 8500, не выполняет `docker compose up -d
+orchestrator`/`--build`, не пушит force в `main`, не правит `.env`/`.env.staging`/`docker-compose.yml`.
+Он лишь исполняет pytest в worktree, делает read-only GET и пишет/пушит лог в фичеветку. Деплой-решений
+ORCH-116 не принимает (это стадия `testing`, до прод-деплоя) — staging-гейт остаётся обязательной
+страховкой на последующих рёбрах.
+
+## 6. Вывод
+
+Инфраструктурных изменений **нет** (топология/порты/образ/зависимости — без правок). Все предусловия
+P-1…P-5 предсуществуют. Эскалация `arch:major-change` **не требуется**.

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

@@ -0,0 +1,54 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 08 — Требования к данным: ORCH-116 — детерминированный test-раннер
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: architecture
+
+## 1. Изменения схемы БД — НЕТ (NFR-1)
+
+Новых таблиц / колонок / индексов / миграций **нет**. Раннер использует **существующие** структуры:
+
+| Структура | Использование | Запись? |
+|-----------|---------------|---------|
+| `tasks` (`stage`, `branch`, `work_item_id`) | резолв полей задачи по `task_id`; гард стадии `testing` в `should_intercept`; продвижение/откат — через **существующий** `advance_stage` (он же пишет стадию под transition-lease ORCH-114) | раннер сам стадию **не** пишет — только через `advance_stage` |
+| `jobs` (`status`, `task_content`) | `mark_job(done\|failed)` для строки джоба (через `_run_test_runner_job`); restart-safe счётчик tool-error DEFER — `COUNT(*)` по маркеру `test-runner infra-retry` в `task_content` re-queued джоба | да (`mark_job`, `enqueue_job` — существующие API) |
+| `agent_runs` | **НЕ создаётся** — детерминированный раннер не спавнит LLM (happy-path без `_spawn`) | нет |
+| `transition_lease` (ORCH-114) | берётся/освобождается **внутри** `advance_stage` на side-effectful переходе | раннер **не трогает** |
+
+## 2. Restart-safe счётчик DEFER — без колонки (зеркало ORCH-115/110)
+
+Бюджет tool-error DEFER (D5) считается **из persisted очереди `jobs`** подсчётом маркера
+`test-runner infra-retry` в `task_content` re-queued джоба (зеркало
+`staging_runner._infra_retry_count` / `stage_engine._merge_infra_retry_count`). Это переживает
+рестарт сервиса **без** новой колонки/таблицы — намеренно, ради NFR-1 (схема БД байт-в-байт).
+
+## 3. Артефакт `13-test-report.md` — контракт frontmatter неизменен (AC-2)
+
+Раннер пишет тот же файл с тем же machine-key, что читает гейт:
+- `result: PASS|FAIL` (UPPERCASE) — канонический ключ `_parse_tests_verdict` (`src/qg/checks.py:265`);
+  имя/регистр/токены **не меняются**.
+- Обязательная 52c-схема: `work_item` / `stage: testing` / `author_agent: test-runner` /
+  `status: success|failed` / `created_at` / `model_used: n/a`.
+- **Инвариант D6.1 (данные):** `status:` **читается** тем же парсером (`verdict:`/`status:`/`result:`,
+  negative-token-priority) → значение `status:` **обязано** быть выровнено по вердикту
+  (`success`↔PASS, `failed`↔FAIL); иначе негативный токен в `status:` при `result: PASS` исказит
+  вердикт. Это требование к **значению данных**, не к схеме.
+
+## 4. Счётчики наблюдаемости — in-process, не БД
+
+Блок `test_runner` в `GET /queue` питается **in-process** счётчиками `_TEST_RUNNER_COUNTERS`
+(`runs`/`pass`/`fail`/`tool_error`/`deferred`) — паттерн `_STAGING_RUNNER_COUNTERS`/
+`_MERGE_GATE_COUNTERS`. В БД **не** персистятся (обнуляются при рестарте — приемлемо для
+оперативной наблюдаемости).
+
+## 5. Вывод
+
+Требований к изменению данных/схемы **нет**. Совместимость с общей БД (self-hosting + enduro-trails)
+сохранена: аддитивных объектов не вводится, существующие read/write идут через существующие API.

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

@@ -0,0 +1,47 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-116 — детерминированный test-раннер
+
+Work Item: **ORCH-116** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Покрывает риски BRD §8 (R-1…R-7) + риски, выявленные
+> архитектором по коду (TR-8…TR-11, специфичные для роли `tester` / стадии `testing`).
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 (R-1) | Точка диспетчеризации «до `_spawn`» перехватывает не тот джоб | Низ. | Выс. | `should_intercept` = `agent=="tester"` **И** `applies(repo)` **И** `tasks.stage=="testing"` (D1). Роль `tester` исполняет ТОЛЬКО `testing` (`STAGE_TRANSITIONS["review"]["agent"]`) → коллизии стадий нет; гард по стадии — defense-in-depth. never-raise → `False` → `_spawn`. Покрыто тестом перехвата/не-перехвата. |
+| TR-2 (R-2) | После вердикта гейт не инициирован → задача зависает на `testing` | Низ. | Выс. | D7: раннер вызывает `advance_stage(current_stage="testing", finished_agent="tester")` в `run_test_gate` (never-raise). **`finished_agent="tester"` обязателен** — FAIL-ветвь `stage_engine.py:849` матчит по `agent=="tester"`. Покрыто тестом PASS-advance и FAIL-rollback. |
+| TR-3 (R-3) | Таймаут/изоляция pytest; утечка процессов (корень ORCH-109/110/111) | Сред. | Выс. | D3: pytest через `proc_group.run_in_process_group` (tree-kill SIGTERM→grace→SIGKILL); таймаут `test_runner_timeout_s`=900 (малформ→дефолт+WARNING); прогон **в worktree ветки**, не в общем клоне. Покрыто тестом изоляции/таймаута. |
+| TR-4 (R-4) | Two-level outcome неверен: tool-error жжёт developer-retry (регресс ORCH-110) ИЛИ ложный green | Сред. | Выс. | D5: сюита исполнилась → verdict→advance; сюита НЕ исполнилась (spawn-error/таймаут/`None`) → bounded DEFER (re-queue `tester`-джоба, restart-safe маркер) → на исчерпании fail-closed `FAIL`+advance+alert. Никогда тихий advance/ложный green; не жжёт developer-retry на инфре. Покрыто тестом обоих уровней. |
+| TR-5 (R-5) | Откат FAIL не совпадает с LLM-путём (developer-retry cap / `extract_test_failures`) | Низ. | Сред. | D7 переиспользует **существующий** откат `stage_engine.py:849-892` (тот же `MAX_DEVELOPER_RETRIES`, `extract_test_failures`, `enqueue_job("developer", …)`). Новой ветви маршрутизации нет. Покрыто тестом эквивалентности. |
+| TR-6 (R-6) | LLM протаскивается обратно в поток управления вердикта (нарушение BR-8) | Низ. | Сред. | D11: детерминированный раннер — единственный продюсер `result:`; off-control-path триаж не реализуется и не добавляет ребро в `STAGE_TRANSITIONS`. Анти-дрейф LLM-карты (D12) + reviewer-ось AC-12. |
+| TR-7 (R-7) | Backward-compat: репо без тест-контракта зависает без продюсера отчёта | Низ. | Выс. | D8: `_has_test_contract(repo)` (Phase 1 = self-hosting) — `applies==False` для не-self/без-контракта → `should_intercept==False` → прежний LLM-tester (fail-safe). Покрыто тестом для не-self репо. |
+| **TR-8** | **52c-`status:` ↔ парсер: ложный FAIL.** `_parse_tests_verdict` читает вердикт из `verdict:`/**`status:`**/`result:` с negative-token-priority. 52c-`status: failed` (`"FAILED"`) при `result: PASS` → негативный токен авторитетен → ложный FAIL здорового прогона. **(Отсутствует в ORCH-115 — там гейт читает только `staging_status:`.)** | Сред. | Выс. | D6.1: `status:` ВСЕГДА выровнен по вердикту (`success`↔PASS / `failed`↔FAIL); `"SUCCESS"` — не негативный/не позитивный токен, позитив берётся из `result: PASS`. **Обязательный** unit-тест: `_parse_tests_verdict(<тело раннера PASS>)==(True,…)` и `(FAIL)==(False,…)` через **неизменённый** парсер. Reviewer: `status:`-литерал с негативным токеном при `result: PASS` → ≥P1. |
+| **TR-9** | **Smoke против прод-8500 флапает.** Разовый блип запущенного оркестратора (connection refused/таймаут) → `FAIL` → откат здоровой ветки + расход developer-retry. | Сред. | Сред. | D3: bounded smoke-ретрай **транзиентной недостижимости** (несколько быстрых GET с коротким backoff) перед `FAIL`; «достижимо, но форма неверна» → немедленный `FAIL`. `test_runner_smoke_enabled` позволяет отключить smoke без отката раннера. pytest — первичный сигнал; developer-retry-cap поглощает остаточный шум. |
+| **TR-10** | **DEFER re-queue'ит не тот агент.** Копипаст из `staging_runner` мог бы re-queue'ить `deployer`-джоб → задача уйдёт в чужой обработчик. | Низ. | Выс. | D5: DEFER re-queue'ит **`tester`**-джоб (`enqueue_job("tester", …)`), повторно входящий в этот раннер на стадии `testing`. Покрыто тестом DEFER (проверка роли re-queued джоба). |
+| **TR-11** | **Дрейф LLM-карты/политики/витрины** при реализации (NFR-6): инвариант «ровно один `first_slice=yes`» нарушен / `avoidable=yes` снят с tester / анти-дрейф-тесты красные. | Сред. | Сред. | D12: точная спека правок (A5 → реализовано, но `avoidable=yes`/`axis=C`/`needs-hybrid-fallback` СОХРАНЯЮТСЯ; rank 2 tester → реализован, `first_slice` НЕ переключать — остаётся у rank 1/deployer). Правки атомарно с кодом в development + зелёные `test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py`. Reviewer-ось AC-14 ≥P1. |
+| TR-12 | Скоуп-дрейф: правка `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_tests_passed`/`_parse_tests_verdict`/machine-verdict/схемы БД | Низ. | Выс. | NFR-1: замена только *продюсера*. Анти-дрейф-тест на неизменность гейта/токенов/схемы (AC-6). Reviewer ловит как ≥P1. |
+
+## Сводный вывод
+
+Доминирующий класс — **корректность интеграции детерминированного раннера в существующий гейт**
+(`finished_agent="tester"`, two-level outcome, эквивалентность отката) и **две tester-специфичные
+мины, которых не было в ORCH-115**: (TR-8) коллизия 52c-`status:` с `_parse_tests_verdict` и
+(TR-9) флап smoke против прод-8500. Обе закрыты архитектурно (D6.1 — жёсткое выравнивание `status:`
++ unit-тест через неизменённый парсер; D3 — bounded smoke-ретрай + config-gate). Остаточный риск для
+прод-конвейера (self-hosting) — **низкий**: leaf never-raise + kill-switch (мгновенный откат к
+LLM-tester байт-в-байт), без правки гейта/стадии/схемы БД, граница с ORCH-112/114/115 соблюдена,
+сквозной бюджет времени сохранён без правки `reaper_max_running_s`.
+
+Эскалация `arch:major-change` **не требуется** (нет новой стадии/QG/смены БД; новый компонент-leaf —
+аддитивный, под kill-switch, по доказанному прецеденту ORCH-115). Возврат в анализ **не требуется**
+(ТЗ удовлетворяется без нарушения принципов архитектуры).

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

@@ -0,0 +1,139 @@
+---
+verdict: APPROVED
+work_item: ORCH-116
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-116
+version: 4
+---
+
+# Review ORCH-116 — детерминированный test-раннер вместо LLM-тестера
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter.
+
+## Summary
+
+Реализация **полностью соответствует ТЗ (02-trz.md), критериям приёмки (03-acceptance-criteria.md)
+и ADR-001 / adr-0050**. ORCH-116 заменяет LLM-агента `tester` на стадии `testing` детерминированным
+leaf `src/test_runner.py`, перехватываемым в `launch_job` до `_spawn` — точное зеркало эталона
+`src/staging_runner.py` (ORCH-115). Критический инвариант NFR-1 соблюдён байт-в-байт: гейт
+`check_tests_passed` / `_parse_tests_verdict`, `STAGE_TRANSITIONS`, `QG_CHECKS`, machine-key `result:`
+и схема БД **не тронуты** (это замена *продюсера* артефакта, не гейта). Тонкая мина D6.1 (52c-`status:`
+↔ парсер с negative-token-priority) обработана корректно и прибита тестом через неизменённый парсер.
+Документация обновлена в полном объёме (CLAUDE.md / CHANGELOG / README / internals / витрина
+`docs/overview/` / LLM-карта/roadmap/policy / tester.md / .env.example). Все 4 оси — зелёные. Findings
+уровня P0/P1, относящихся к ORCH-116, нет.
+
+## Оси проверки
+
+### 1. Соответствие ТЗ / AC — PASS
+- **FR-1 / AC-1** перехват до `_spawn`: `launcher.launch_job` врезка `if job.get("agent")=="tester"
+  and test_runner.should_intercept(job): return self._run_test_runner_job(job)` рядом с
+  D1/D2/ORCH-115; `_run_test_runner_job` — зеркало `_run_staging_runner_job`, ведёт `jobs` через
+  `mark_job`, возвращает `None` (нет `agent_runs`). ✔ (TC-05).
+- **FR-2/3 / AC-3/AC-11** pytest в worktree через `proc_group` (tree-kill, `_resolve_timeout`
+  fail-safe), маппинг `map_exit_code_to_result` поверх единого `self_deploy.map_exit_code_to_status`
+  (без второго маппинга). ✔ (TC-02, TC-12).
+- **FR-4 / AC-2** `write_test_report` — `result:` UPPERCASE + 52c-схема, `author_agent: test-runner` /
+  `model_used: n/a`, push только в фичеветку (без merge в `main`). ✔ (TC-03, TC-04).
+- **FR-5 / AC-4** `_advance` вызывает `advance_stage(current_stage="testing", finished_agent="tester")`
+  — FAIL-ветвь `stage_engine.py:849` матчит по `agent=="tester"`. ✔ (TC-07).
+- **FR-6 / AC-5** two-level outcome: `suite_ran=(returncode is not None) and (not timed_out)`;
+  tool-error → bounded DEFER (re-queue именно **`tester`**-джоба + restart-safe маркер), на исчерпании
+  → fail-closed `FAIL` + advance + INFRA-alert. ✔ (TC-10).
+- **FR-7 / AC-7/AC-8** `applies()` = kill-switch + скоуп + `_has_test_contract` (репо без контракта →
+  LLM-tester даже при ручном добавлении в CSV). ✔ (TC-01, TC-08).
+- **FR-8 / AC-13** блок `test_runner` в `GET /queue` + счётчики + структурный лог, различающий
+  code-fail / tool-error. ✔ (TC-14).
+- **FR-9 / AC-12** гибрид: LLM вне control-path вердикта. ✔.
+
+### 2. Соответствие ADR / инварианты — PASS
+- NFR-1 / AC-6: `git diff origin/main...HEAD` НЕ затрагивает `src/stages.py`, `src/qg/`,
+  `src/stage_engine.py`, `src/staging_runner.py`, `src/proc_group.py`, `src/transition_lease.py`,
+  `src/git_worktree.py` — проверено явно (пустой diff). ✔.
+- **D6.1 (ключевая мина)**: `_parse_tests_verdict` (`src/qg/checks.py:263-277`) читает вердикт из трёх
+  полей с приоритетом негативного токена. Раннер выравнивает `status:` по вердикту (`PASS→success`
+  «SUCCESS» — не позитивный и не негативный токен → `True` берётся из `result: PASS`; `FAIL→failed`
+  «FAILED» — негативный → `False`). Проверено вручную по логике парсера и тестом TC-04
+  (`test_tc04_status_field_never_false_negatives_a_pass`) через **неизменённый** парсер. ✔.
+- Граница O1: `staging_runner` (ORCH-115), `transition_lease` (ORCH-114), `checkout_hygiene`
+  (ORCH-112) не модифицированы — соответствует требованию. ✔.
+- Трассировка: новые врезки корректно ссылаются на прецеденты D1/D2/ORCH-115; зафиксированные
+  инварианты конвейера не сломаны. ✔.
+
+### 3. Качество кода — PASS
+- never-raise соблюдён во всех публичных функциях (`applies`/`should_intercept`/`run_test_gate`/
+  `snapshot`/`write_test_report`/`run_smoke` — guarded; TC-01/TC-06/TC-11/TC-14 покрывают).
+- Лениво импортируются тяжёлые модули — leaf-чистота сохранена (импорт на уровне модуля только
+  `config`/`logging`/`proc_group`).
+- Тесты содержательные (14 TC + анти-дрейф TC-15), без живого Claude CLI/сети; покрывают happy/FAIL/
+  tool-error/never-raise/kill-switch/scope/smoke/observability.
+- Это feature-трек (не `Bug`), регресс-тест-фиксатор (ORCH-019 BR-4) не требуется; покрытие тем не
+  менее исчерпывающее.
+
+### 4. Документация — PASS (обязательная проверка)
+`src/` изменён → документация обновлена в том же PR, проверено пофайлово:
+- `CLAUDE.md` — новый раздел «Детерминированный test-раннер (ORCH-116)». ✔
+- `CHANGELOG.md` — детальная запись `[Unreleased]`. ✔
+- `docs/architecture/README.md` — компонент **Test-runner** + блок roadmap «второй срез реализован». ✔
+- `docs/architecture/internals.md` — примечание о перехвате на `testing`. ✔
+- `docs/architecture/llm-call-sites.md` (A5), `llm-determinization-roadmap.md` (rank 2),
+  `llm-usage-policy.md` (§5) — обновлены; **инвариант «ровно один `first_slice=yes`» сохранён**
+  (deployer=yes, tester=no), анти-дрейф `tests/test_llm_call_site_inventory.py` /
+  `test_llm_determinization_docs.py` — зелёные. ✔
+- Витрина `docs/overview/` (ORCH-011): `tech-pipeline.md` / `tech-agents.md` /
+  `tech-quality-security.md` обновлены; `tests/test_system_docs.py` зелёный. ✔
+- `.openclaw/agents/tester.md` — LLM-ветвь помечена fallback'ом (канон 52d цел). ✔
+- `.env.example` — все 7 ключей `ORCH_TEST_RUNNER_*`. ✔
+- ADR + сквозной `adr-0050` присутствуют. ✔
+
+## Тесты (AC-15)
+- `tests/test_orch116_test_runner.py` + LLM анти-дрейф — **45 passed**.
+- Полный регресс `pytest tests/ -q` — **2162 passed, 1 failed** (84s). Единственный фейл —
+  `tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_not_rolled_back` (см. P2).
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- **[Вне ORCH-116, для отдельного follow-up] Pre-existing test-isolation flake в ORCH-123.**
+  В полном прогоне падает `tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_
+  not_rolled_back`. Доказано, что это **не** дефект ORCH-116: (1) тест зелёный в изоляции и в своём
+  файле; (2) фейл воспроизводится при прогоне полного сьюта **без** `tests/test_orch116_test_runner.py`
+  (`--ignore`) → 1 failed; (3) ORCH-116 не трогает `src/staging_runner.py` (граница O1, корректно).
+  Это загрязнение глобального состояния от соседнего теста в ORCH-123-коде (недавно влит в `main`).
+  AC-15 в части «ORCH-116 не краснит ранее зелёные тесты» удовлетворён. Рекомендация: завести
+  отдельный bug на изоляцию теста ORCH-123 — он вне области ORCH-116 и не должен блокировать этот PR.
+
+### P3 — Nice to have
+- `run_smoke` (`src/test_runner.py:291`) дублирует литерал `"http://localhost:8500"`, который уже
+  является дефолтом `settings.post_deploy_base_url`. Это безвредный defensive double-default
+  (`localhost`/`8500` НЕ в FORBIDDEN-списке `test_no_host_hardcodes` — нарушения нет); можно опереться
+  только на дефолт config. Косметика.
+- Smoke-провал из-за транзиентного блипа прод-8500 после bounded-ретраев даёт `FAIL` → откат +
+  расход developer-retry (формально инфра, трактуемая как код-фейл — родственно классу ORCH-110).
+  Архитектор **осознанно** взвесил это в ADR (D3 + Consequences «−»): bounded smoke-ретрай +
+  config-gate `test_runner_smoke_enabled` + developer-retry-cap; поведение эквивалентно прежнему
+  LLM-tester (`curl /health`). Принято как задокументированный компромисс; не блокирует.
+
+## Документация
+Обновлена в полном объёме в том же PR (см. ось 4). Изменение `src/` сопровождено обновлением
+паспорта, чейнджлога, архитектурной карты, internals, витрины `docs/overview/`, LLM-карты/roadmap/
+политики, промпта `tester.md`, `.env.example` и ADR (локальный + сквозной). Машинно-проверяемые факты
+витрины и LLM-карты держатся зелёными анти-дрейф-тестами. Требование «документация = golden source»
+выполнено → блокирующих документационных findings нет.
+
+## Вердикт
+Нет P0/P1, относящихся к ORCH-116. Все четыре оси (ТЗ, ADR/инварианты, качество кода, документация)
+пройдены; критические инварианты сохранены байт-в-байт; покрытие исчерпывающее. **APPROVED.**
+Единственный красный тест полного сьюта — pre-existing flake ORCH-123 (P2), доказанно независимый от
+ORCH-116 и вне его области правки.

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

@@ -0,0 +1,151 @@
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-116
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-116
+---
+
+# Test Report — ORCH-116 — детерминированный test-раннер вместо LLM-тестера
+
+> Машинный вердикт читается ТОЛЬКО из frontmatter (`result:`; равнорангово `verdict:`/`status:`,
+> ORCH-047). Любой негативный токен авторитетен.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Дата: 2026-06-16
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-116-orch-replace-llm-tester-with-d`
+  (ветка `feature/ORCH-116-orch-replace-llm-tester-with-d`) — регресс прогнан в worktree ветки
+  задачи, НЕ в общем `/repos/orchestrator` (анти checkout-гонка).
+- Прод-контейнер 8500 не трогался; smoke — строго read-only GET.
+- Review-гейт: `12-review.md` → `verdict: APPROVED` ✔ (предусловие стадии выполнено).
+
+## Smoke API (read-only)
+
+| Эндпоинт | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok","service":"orchestrator"}` — **OK** |
+| `GET /status` | 200, активные задачи отдаются (вкл. ORCH-116, stage=testing) — **OK** |
+| `GET /queue` | 200; блок `serial_gate` присутствует ✔ (ORCH-088); блок `auto_labels` присутствует ✔ — **OK** |
+
+Примечание: блок `test_runner` (ORCH-116) в `/queue` прод-инстанса отсутствует — ожидаемо, т.к.
+прод исполняет до-ORCH-116 код (эта ветка ещё не задеплоена). Это не регресс смока: контрактные
+блоки `serial_gate`/`auto_labels` на месте.
+
+## Результаты
+
+### Полный регресс (`pytest tests/ -v --tb=short`, worktree ветки)
+- **2162 passed, 1 failed** (105.31s).
+- Профильная сюита `tests/test_orch116_test_runner.py` — **32 passed** (в изоляции, 2.64s).
+- Анти-дрейф LLM-карты `tests/test_llm_call_site_inventory.py` + `test_llm_determinization_docs.py`
+  — зелёные (в составе полного регресса).
+
+### Единственный красный — pre-existing flake ORCH-123, НЕ дефект ORCH-116
+
+`tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_not_rolled_back`.
+
+Доказано независимым воспроизведением, что фейл **полностью независим** от ORCH-116 и пред-существует
+в `main` (анти-ложная-маршрутизация инфра/чужого фейла как код-фейла — класс ORCH-110):
+
+1. **Изоляция:** `pytest …::test_r2_held_deploy_staging_not_rolled_back` отдельно → **1 passed**.
+2. **Профильный файл ORCH-116:** `tests/test_orch116_test_runner.py` → **32 passed** (зелёный).
+3. **Полный регресс БЕЗ файла ORCH-116** (`--ignore=tests/test_orch116_test_runner.py`) → всё равно
+   **1 failed, 2130 passed** — тот же тест красный без участия нового кода тестов ORCH-116.
+4. **Чистый `origin/main` (`9c88fdd`), полный регресс** во временном worktree → **1 failed, 2130
+   passed**, падает РОВНО тот же тест. → флейк пред-существует в `main`, идентичный счётчик фейлов.
+5. **Граница правки:** `git diff origin/main...HEAD` НЕ затрагивает `src/staging_runner.py`,
+   `src/stages.py`, `src/qg/`, `src/stage_engine.py`. ORCH-116 физически не может влиять на этот тест.
+
+Итог сопоставления: ветка ORCH-116 = `2162 passed / 1 failed`; `main` = `2130 passed / 1 failed`.
+ORCH-116 добавляет **32 зелёных** теста и **не делает красным ни один ранее зелёный** — это
+кросс-тестовое загрязнение глобального состояния в коде ORCH-123 (недавно влит в `main`).
+**AC-15 FAIL-условие** («любой ранее зелёный тест становится красным / новые тесты падают») —
+**не наступило**; AC-15-интент NFR-1/NFR-5 («существующий конвейер не сломан») — выполнен.
+Рекомендация: завести отдельный bug на изоляцию `test_orch123_staging_runner_exec.py` (вне области
+ORCH-116, не должен блокировать этот PR). Согласуется с вердиктом reviewer (P2, APPROVED).
+
+### Сопоставление с тест-планом (`04-test-plan.yaml`)
+
+| TC ID | Тип | Описание (кратко) | Тест-функция / проверка | Результат |
+|-------|-----|-------------------|--------------------------|-----------|
+| TC-01 | unit | `applies(repo)`: kill-switch/CSV/контракт (BR-9)/never-raise | `test_tc01_*` | PASS |
+| TC-02 | unit | Маппинг exit→verdict (0→PASS, иначе/None→FAIL, единый контракт) | `test_tc02_map_exit_code` | PASS |
+| TC-03 | unit | Рендер `13-test-report.md`: `result:` UPPERCASE + 52c-схема | `test_tc03_report_render_schema_and_status_alignment` | PASS |
+| TC-04 | integration | Артефакт читается **неизменённым** `_parse_tests_verdict` | `test_tc04_gate_parser_unchanged`, `test_tc04_status_field_never_false_negatives_a_pass` | PASS |
+| TC-05 | integration | Перехват tester на `testing` до `_spawn`, нет `agent_runs`, `None` | `test_tc05_launch_job_intercepts_before_spawn` | PASS |
+| TC-06 | integration | Дискриминатор: не-`testing`/не-`tester` не перехват; never-raise→`False` | `test_tc06_*` | PASS |
+| TC-07 | integration | PASS→`advance_stage(finished_agent='tester')`; FAIL→откат+retry | `test_tc07_advance_initiated_like_llm[0-PASS]`, `[1-FAIL]` | PASS |
+| TC-08 | integration | Kill-switch off → `_spawn` (LLM-путь байт-в-байт) | `test_tc08_killswitch_falls_back_to_spawn` | PASS |
+| TC-09 | unit | Анти-дрейф NFR-1: STAGE_TRANSITIONS/QG_CHECKS/парсер/токены/схема БД целы | `test_tc09_pipeline_contract_unchanged` | PASS |
+| TC-10 | integration | Two-level outcome: tool-error→bounded DEFER→fail-closed FAIL+alert | `test_tc10_*` | PASS |
+| TC-11 | unit | never-raise/fail-safe: pytest бросает/таймаут→FAIL/DEFER, не клинит | `test_tc11_run_gate_never_raises`, `test_tc11_launcher_contains_runner_fault` | PASS |
+| TC-12 | unit | Изоляция/таймаут: proc_group tree-kill в worktree; малформ→дефолт 900+WARN | `test_tc12_*` | PASS |
+| TC-13 | unit | Self-hosting safety: нет запрещённых литералов; smoke read-only GET | `test_tc13_*` | PASS |
+| TC-14 | integration | Наблюдаемость: блок `test_runner` в `/queue`, структурный лог, гибрид | `test_tc14_*` | PASS |
+| TC-15 | integration | Анти-дрейф LLM-карты (A5/rank 2, «ровно один first_slice=yes») | `test_llm_call_site_inventory.py` / `test_llm_determinization_docs.py` | PASS |
+
+**Все 15 TC выполнены и сопоставлены; все PASS.**
+
+### Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
+
+| AC | Покрыт | Результат |
+|----|--------|-----------|
+| AC-1 Перехват на `testing` без `_spawn`/LLM | TC-05 | PASS |
+| AC-2 Контракт `13-test-report.md` неизменен | TC-03, TC-04 | PASS |
+| AC-3 exit-code→verdict маппинг (fail-closed) | TC-02 | PASS |
+| AC-4 Эквивалентность маршрутизации PASS/FAIL | TC-07 | PASS |
+| AC-5 Two-level outcome (tool-error ≠ code-fail) | TC-10 | PASS |
+| AC-6 Скоуп: гейты/стадии/схема БД не тронуты | TC-09 + `git diff` | PASS |
+| AC-7 Kill-switch и скоуп (обратимость) | TC-01, TC-08 | PASS |
+| AC-8 Backward-compat для репо без контракта | TC-01 | PASS |
+| AC-9 never-raise / fail-safe | TC-11 | PASS |
+| AC-10 Self-hosting safety | TC-13 | PASS |
+| AC-11 Изоляция процесса/таймаут (proc_group) | TC-12 | PASS |
+| AC-12 Гибрид: LLM не в control-path вердикта | TC-14 | PASS |
+| AC-13 Наблюдаемость | TC-14 | PASS |
+| AC-14 Норматив LLM-карты/политики/витрины | TC-15 + ревью оси 4 | PASS |
+| AC-15 Полный регресс зелёный | полный регресс | PASS* |
+
+\* AC-15: новые тесты зелёные, ни один ранее зелёный тест не покраснел из-за ORCH-116. Единственный
+красный — pre-existing flake ORCH-123 (идентичен на чистом `main`), вне области ORCH-116.
+
+## Вывод pytest (хвост полного регресса)
+
+```
+=================================== FAILURES ===================================
+_________________ test_r2_held_deploy_staging_not_rolled_back __________________
+tests/test_orch123_staging_runner_exec.py:462: in test_r2_held_deploy_staging_not_rolled_back
+    assert result is None                               # red gate -> stay, no advance call
+E   AssertionError: assert <MagicMock name='mock()' id='...'> is None
+=========================== short test summary info ============================
+FAILED tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_not_rolled_back
+============ 1 failed, 2162 passed, 1 warning in 105.31s (0:01:45) =============
+```
+
+Контрольные прогоны (доказательство независимости от ORCH-116):
+```
+# тест в изоляции
+1 passed
+# профильный файл ORCH-116
+32 passed
+# полный регресс БЕЗ файла ORCH-116 (--ignore)
+1 failed, 2130 passed   (тот же тест красный)
+# чистый origin/main (9c88fdd), полный регресс
+1 failed, 2130 passed   (тот же тест красный)
+```
+
+## Итог
+
+**PASS.** Smoke OK (read-only `/health`/`/status`/`/queue`; `serial_gate` + `auto_labels` на месте).
+Профильная сюита (32) и анти-дрейф LLM-карты зелёные. Все 15 TC и 15 AC сопоставлены и пройдены.
+Единственный красный тест полного регресса — **pre-existing flake ORCH-123**
+(`test_r2_held_deploy_staging_not_rolled_back`), доказанно идентичный на чистом `origin/main`
+(`2130 passed / 1 failed`) и полностью независимый от ORCH-116 (граница правки не затрагивает
+`src/staging_runner.py`); ORCH-116 не делает красным ни один ранее зелёный тест и добавляет 32
+зелёных. AC-15-интент «существующий конвейер не сломан» выполнен. Рекомендован отдельный bug на
+изоляцию теста ORCH-123 (вне области этой задачи). Задача переходит на `deploy-staging`.

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

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

@@ -0,0 +1,46 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-116
+stage: deploy-staging
+author_agent: staging-runner
+status: success
+created_at: 2026-06-16
+model_used: n/a
+exit_code: 0
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log (deterministic runner, ORCH-115)
+
+Staging suite exit-code `0` -> `staging_status: SUCCESS`.
+
+Вердикт зафиксирован детерминированным staging-раннером (ORCH-115), не LLM. infra-tolerance (ORCH-061) уже учтена внутри `staging_check.py` — раннер её не пересуживает.
+
+INFRA-WAIVED lines (ORCH-061, copied for observability):
+- INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
+
+Staging suite stdout (tail):
+```
+ (waiting for analyst job in queue)
+  ·        waiting... (waiting for analyst job in queue)
+  ·        waiting... (waiting for analyst job in queue)
+  ·        waiting... (waiting for analyst job in queue)
+  ·        waiting... (waiting for analyst job in queue)
+  ·        waiting... (waiting for analyst job in queue)
+  ✗ FAIL  C9b Analyst job enqueued in staging queue
+
+[CLEANUP]
+  ·      CLEANUP: no branch to delete
+  ✓ PASS  CLEANUP: deleted Plane issue d88719d1-378b-49d4-b4be-3cc30e9dca4f (HTTP 204)
+  ·      CLEANUP DB: no task row found for plane_id=d88719d1-378b-49d4-b4be-3cc30e9dca4f
+  ·      CLEANUP DB dedup: no such table: events_dedup
+
+============================================================
+  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
+```

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

@@ -0,0 +1,29 @@
+---
+security_status: PASS
+secrets_found: 0
+deps_blocking: 0
+deps_warning: 8
+deps_audit_degraded: false
+---
+# Security Report — ORCH-116
+
+Детерминированный 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
+- `starlette==0.38.6` — GHSA-wqp7-x3pw-xc5r severity=UNKNOWN fix=1.1.0
+- `starlette==0.38.6` — GHSA-x746-7m8f-x49c severity=UNKNOWN fix=1.1.0
+- `starlette==0.38.6` — GHSA-82w8-qh3p-5jfq severity=UNKNOWN fix=1.3.1
+- `starlette==0.38.6` — GHSA-jp82-jpqv-5vv3 severity=UNKNOWN fix=1.3.0

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,360 @@
+---
+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-ревью: инвариант «места вызова LLM» **смешивал**
+> факт *«существует процесс Claude CLI / спавнится subprocess»* (транспорт/механизм) с фактом
+> *«потребляется суждение LLM»* (LLM-консультация). R4 развёл **транспорт** (`_spawn`) и **слот/
+> capability** (D1/D2) от факта **консультации** во всех артефактах (см. §0). Содержательная
+> классификация ролей и весь R3-материал (анти-фабрикация ID) — без изменений.
+
+> 🔁 **Revision R5 (2026-06-15) — единственный оставшийся блокер R4-ревью.** Рецензент подтвердил R4
+> (консультация ≠ транспорт/слот; no-alternative-LLM-transport; follow-up'ы по роли/TBD; нет
+> runtime-дифа) — **менять их не нужно**. Закрывается **один** блокер: артефакты разводили
+> «консультация ≠ транспорт/слот», но **не делали явной третью ось — самую важную для названия
+> задачи** *«replace avoidable LLM **control paths**»*: среди фактических консультаций **не
+> различались** (i) **control-path-консультации** — где LLM-вердикт **потребляется потоком управления**
+> (на нём ветвится `check_*`-гейт), и (ii) **artifact-producer-консультации** — где LLM лишь
+> **производит артефакт**, а ветвление делает **детерминированный гейт** (наличие файлов / CI), и
+> суждение LLM в control flow **не входит**. И главное — нигде **явно не определена «avoidable LLM
+> control path»**. R5 добавляет эту ось и определение во **все** артефакты (новый §0-bis, уточнённые
+> BR-1/BR-2 + новые BR-8/BR-9, FR-1/FR-2 + новый FR-8, AC-1/AC-2 + новый AC-10, TC-13/TC-14).
+> Содержательная классификация (analyst/architect/developer/reviewer → keep-LLM; deployer →
+> replace-deterministic; tester → hybrid) **не меняется** — R5 даёт ей **доказательный control-path
+> вывод** из кода (`check_*`/`_parse_*` в `src/qg/checks.py`).
+
+---
+
+## 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:389,394`, код прямо
+     помечает «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 матчинг).
+
+---
+
+## 0-bis. Третья ось: control-path-консультация ≠ artifact-producer-консультация; что такое «avoidable» (R5)
+
+§0 (R4) отделил **факт консультации** от **транспорта** и **слота**. Но название задачи —
+«replace **avoidable** LLM **control paths**» — требует ещё одного, **решающего** различия **внутри
+множества фактических консультаций** (A1…A6). Без него «control path» и «avoidable» остаются
+неопределёнными, и карта не отвечает на главный вопрос задачи: *какие именно консультации — это
+avoidable LLM control paths*. Это и есть оставшийся блокер R4-ревью.
+
+### Ось 3 — как именно LLM-вывод соотносится с потоком управления
+
+Каждая фактическая консультация (роль-агент) относится **ровно к одному** из двух типов:
+
+- **(C) Control-path-консультация.** LLM эмитит **machine-verdict**, который **потребляется потоком
+  управления конвейера**: соответствующий `check_*`-гейт **ветвится на этом вердикте**
+  (PASS→дальше / FAIL→откат). Суждение LLM **входит в control flow** — это и есть «**LLM control
+  path**» в точном смысле названия задачи.
+- **(P) Artifact-producer-консультация.** LLM **производит артефакт** (документы/код/PR), а решение
+  о продвижении принимает **детерминированный гейт**, судящий артефакт **независимо** от
+  самоотчёта LLM (наличие файлов, статус CI). Суждение LLM **в control flow не входит** → это **не**
+  «LLM control path» (хотя консультация реальна и может требовать настоящего суждения).
+
+Различие доказывается кодом — **кто потребляет вывод роли** (`src/qg/checks.py`, ground-truth на
+момент задачи):
+
+| Роль | Потребитель вывода (control-flow consumer) | Тип (C/P) | Control path? |
+|------|--------------------------------------------|-----------|---------------|
+| analyst | `check_analysis_complete` (checks.py:33) — **наличие файлов** 01–04 | **P** | нет |
+| architect | `check_architecture_done` (checks.py:62) — **наличие** 06-adr/07 | **P** | нет |
+| developer | `check_ci_green` (checks.py:82) + `check_branch_mergeable` (657) — **CI/merge** | **P** | нет |
+| reviewer | `check_reviewer_verdict` (checks.py:336) читает **`verdict:`** → REQUEST_CHANGES-откат | **C** | **да** |
+| tester | `check_tests_passed` (checks.py:182) → `_parse_tests_verdict` (226) читает **`result:`** | **C** | **да** |
+| deployer | `check_staging_status` (599)→`_parse_staging_status` (538) **`staging_status:`**; `check_deploy_status` (473)→`_parse_deploy_status` (413) **`deploy_status:`** | **C** | **да** |
+
+> Для **P**-ролей гейт читает **не самоотчёт LLM**, а независимый детерминированный сигнал
+> (файлы/CI) — поэтому подделать ветвление «самооценкой» нельзя; это структурно НЕ control path.
+> Для **C**-ролей гейт читает **именно machine-verdict, который написал LLM** — суждение LLM и есть
+> точка ветвления.
+
+### Определение «avoidable LLM control path» (нормативное, R5)
+
+Call-site — **avoidable LLM control path** ⟺ выполнены **оба** условия:
+
+1. **(control path)** это **C**-консультация — её LLM-вердикт потребляется потоком управления
+   (`check_*` ветвится на нём); **и**
+2. **(deterministically derivable)** этот вердикт по сути есть **детерминированная функция от
+   tool-сигналов** (exit-code `pytest`/smoke, `staging_check.py`, exit-code деплоя), которые
+   оркестратор **уже вычисляет сам** → суждение LLM **не добавляет информации** → консультацию можно
+   снять без потери смысла.
+
+Отсюда — **точный целевой набор задачи** (доказательно, не «на глаз»):
+
+- **avoidable LLM control paths = {tester, deployer}** — C **и** вердикт деривируем из exit-кодов
+  (`_parse_tests_verdict` судит то, что есть исход `pytest`; `_parse_staging_status`/
+  `_parse_deploy_status` судят то, что есть исход `staging_check.py`/деплоя; прод-деплой
+  self-hosting **уже** идёт детерминированным путём Phase A/B/C, ORCH-036).
+- **control path, но НЕ avoidable = {reviewer}** — C, но вердикт **не** деривируем: «приемлем ли
+  код?» — настоящее суждение (keep-LLM). Это показывает, что «control path» **сам по себе** не равен
+  «avoidable» — отсекает условие 2.
+- **НЕ control path (avoidable-вопрос неприменим) = {analyst, architect, developer}** — P:
+  детерминированный гейт судит артефакт, суждение LLM в control flow не входит; авторская работа
+  требует настоящего суждения (keep-LLM). Это отсекает условие 1.
+- **уже детерминированы (вне консультаций) = {deploy-finalizer, post-deploy-monitor}** — §0.3.
+
+Эта ось **выводит** R3/R4-классификацию из кода, а не постулирует её: класс call-site'а есть
+**функция** его (C/P)-типа и деривируемости вердикта (см. BR-2). «Avoidable» больше не «удобство на
+глаз», а проверяемый двухбитный предикат над `src/qg/checks.py`.
+
+---
+
+## 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).
+- **Из 6 консультаций только 3 — это LLM control paths** (вердикт потребляется потоком управления,
+  §0-bis): **reviewer / tester / deployer**. Остальные 3 (**analyst / architect / developer**) —
+  artifact-producer'ы: их выход судит **детерминированный** гейт (наличие файлов / CI), суждение LLM
+  в control flow не входит. Среди 3 control path'ов **avoidable** — те, чей вердикт деривируем из
+  exit-кодов: **tester** и **deployer**; **reviewer** — control path с **настоящим** суждением
+  (keep).
+- **Все остальные 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` — это рабочий прецедент детерминированной замены агента).
+
+Боль/риск, который закрывает задача: LLM на **механических control path'ах** — это (а) лишний
+источник недетерминизма и инцидентов (ложный вердикт/действие в точке ветвления), (б) задержка
+(запуск opus-агента вместо прямого вызова), (в) расход токенов/денег. При этом «вслепую» убирать LLM
+нельзя — часть путей несёт **настоящее суждение** (анализ, архитектура, написание кода, **ревью**), и
+автономность/гибкость должны сохраниться. Точный дискриминатор «убирать/оставить» — определение
+«avoidable LLM control path» (§0-bis).
+
+ORCH-118 даёт **доказательную карту** «где LLM действительно нужен, а где это avoidable control path»
+и **упорядоченный план** безопасных замен — фундамент, на котором последующие срезы (по
+ролям-кандидатам) выполняются предсказуемо и без регресса.
+
+## 2. Объём (scope)
+
+### В объёме
+- **BR-1** Полная инвентаризация всех мест вызова LLM и всех ролей-агентов (карта call-site'ов).
+- **BR-2** Классификация каждого call-site в один из 4 классов (keep / replace-now / replace-later /
+  hybrid-fallback) с явным обоснованием, **выведенным** из control-path-оси (§0-bis): класс есть
+  функция (C/P)-типа и деривируемости вердикта.
+- **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-тесты, **прибивающие инварианты карты к коду** (транспорт-агностичный
+  двусторонний инвариант + control-path-ось) — анти-дрейф.
+- **BR-7** Явно позиционировать **роль deployer** и **роль tester** как **кандидаты-follow-up** для
+  детерминированной замены — **по роли, без привязки к конкретным Plane-ID** (см. NFR-6).
+- **BR-8 (R5)** Карта **явно** размечает каждую консультацию по оси (C) control-path /
+  (P) artifact-producer с доказательством — **кто потребляет вывод роли** (`check_*`/`_parse_*` с
+  `file:line`).
+- **BR-9 (R5)** Карта/политика **явно** определяют термин **«avoidable LLM control path»** (двухбитный
+  предикат §0-bis) и **поимённо** называют целевой набор `{tester, deployer}`, явно отделяя его от
+  control-path-но-keep (`reviewer`) и от не-control-path (`analyst`/`architect`/`developer`).
+
+### Вне объёма
+- ❌ **Реализация** детерминированных раннеров 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-ключ (если есть), **потребитель вывода (`check_*`/`_parse_*` с
+  `file:line`)**, оценка токенов/времени, **признак capability-vs-consultation** (§0.3) и **признак
+  оси (C) control-path / (P) artifact-producer** (§0-bis, BR-8). Проверяемо: каждый `file:line`
+  резолвится в реальный код.
+- **BR-2 — Классификация.** Каждому call-site присвоить **ровно один** класс из таксономии:
+  `keep-LLM` (нужно настоящее суждение), `replace-deterministic-now` (безопасная замена сейчас),
+  `replace-later/risky` (замена позже / рискованно), `needs-hybrid-fallback` (детерминированное ядро +
+  LLM-фолбэк на суждение). Класс **выводится** из control-path-оси (§0-bis): **P** → `keep-LLM`
+  (артефактная авторская работа); **C + не-деривируемый вердикт** → `keep-LLM` (reviewer); **C +
+  деривируемый вердикт** → `replace-*` / `needs-hybrid-fallback` (tester/deployer = avoidable). Для
+  `keep-LLM` — **назвать конкретное суждение**, ради которого LLM сохраняется (для **C**-keep —
+  почему вердикт **не** деривируем).
+- **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/обратимости. Явно указать
+  **рекомендованный первый срез** и обоснование выбора (опора на control-path-вывод: первым берётся
+  самый «чисто деривируемый» control path). Привязка к follow-up задаче — **по роли**; конкретный
+  Plane-ID НЕ фиксируется (заводится отдельно, NFR-6).
+- **BR-5 — Политика использования LLM.** Нормативный durable-документ: «LLM — только там, где требуется
+  настоящее суждение»; критерии решения keep vs replace, **сформулированные через ось §0-bis**
+  (является ли путь control path; деривируем ли вердикт); требование к новым/изменённым control-path'ам
+  обосновывать любое использование LLM против этой политики.
+- **BR-6 — Анти-дрейф структурными тестами.** Тесты, привязывающие инварианты карты к коду:
+  транспорт-агностичный двусторонний инвариант единственной точки (§0); перечисленные
+  детерминированные модули/job-роли не несут LLM-консультации; карта перечисляет ровно те 6 промптов,
+  что лежат в `.openclaw/agents/`; тотальность классификации; **плюс control-path-ось (R5):** карта
+  размечает каждую роль (C/P) согласованно с фактическим потребителем в `src/qg/checks.py`, а
+  avoidable-набор = `{tester, deployer}`. Тесты — offline. **Тест на привязку к конкретным follow-up
+  ID не вводится** (анти-паттерн R3).
+- **BR-7 — Позиционирование follow-up'ов по роли.** Карта/roadmap явно отмечают **роль deployer** и
+  **роль tester** как кандидаты-замены, **не** реализуемые в ORCH-118; их старт гейтится утверждением
+  карты. Привязка — **по роли**, без конкретных Plane-ID (NFR-6).
+- **BR-8 (R5) — Явная control-path-разметка.** Карта несёт для каждой консультации поле оси
+  **(C) control-path / (P) artifact-producer** + доказательство (потребитель вывода с `file:line`).
+  Разметка **проверяема** структурным тестом против `src/qg/checks.py` (BR-6, TC-13).
+- **BR-9 (R5) — Явное определение «avoidable LLM control path» и поимённый целевой набор.** Карта/
+  политика дают нормативное определение термина (двухбитный предикат §0-bis) и **поимённо** называют
+  `{tester, deployer}` как avoidable, явно отделяя их от `reviewer` (control path, keep) и от
+  `analyst/architect/developer` (не control path). Набор **проверяем** тестом (BR-6, TC-14).
+
+## 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.)
+- **NFR-7 (R5) — Контроль-ориентированность определений.** «LLM control path» и «avoidable»
+  определяются **через потребление вывода потоком управления** (кто из `check_*` ветвится на выводе),
+  а не через «есть ли вообще LLM-вызов на стадии». Любое утверждение «это avoidable LLM control path»
+  обязано резолвиться в конкретный `check_*`/`_parse_*` + tool-сигнал, из которого вердикт деривируем.
+
+## 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).
+- **(R5)** Control-path-разметка опирается на ground-truth `src/qg/checks.py` на момент задачи; при
+  эволюции кода её честность держит структурный тест (TC-13/TC-14).
+
+## 7. Критерии успеха
+Карта LLM-консультаций полна и привязана к коду, и **разводит три ортогональных факта**: транспорт/слот
+(«процесс Claude CLI существует», R4 §0), факт консультации, **и — control-path-ось (R5 §0-bis):
+потребляется ли LLM-вывод потоком управления (`check_*` ветвится на нём) или его независимо судит
+детерминированный гейт**. Термин **«avoidable LLM control path» явно определён** (двухбитный предикат)
+и целевой набор **поимённо** назван `{tester, deployer}` с доказательным отделением от `reviewer`
+(control path, keep) и от `analyst/architect/developer` (не control path). Каждый site классифицирован
+с обоснованием, **выведенным** из этой оси; детерминизм не-агентских путей доказан (отсутствием
+LLM-консультации, не отсутствием subprocess); есть упорядоченный roadmap с зависимостями/экономией/
+рисками и рекомендованным первым срезом (кандидаты — по роли); есть нормативная политика; структурные
+тесты зелёные и осмысленные (инвариант единственной точки транспорт-агностичен и двусторонен; control-path
+-разметка сверена с `src/qg/checks.py`; avoidable-набор зафиксирован); ни один рантайм-инвариант не
+тронут; раннеры замен НЕ реализованы; ни один артефакт не фиксирует непроверяемых follow-up ID.
+Детальные PASS/FAIL — в `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Недо-/пере-классификация** (LLM убран там, где нужно суждение, или сохранён там, где не нужен) →
+  митигирует **control-path-вывод** (§0-bis: класс выводится из (C/P)-типа и деривируемости вердикта,
+  а не «на глаз») + требование «назвать конкретное суждение» для `keep-LLM` + ревью карты.
+- **Конфляция «есть LLM на стадии» с «это control path»** (рецидив корня R4-блокера) → митигирует
+  явная разметка оси и тест TC-13 (сверка с фактическим потребителем `check_*`).
+- **Дрейф карты** относительно кода со временем → митигируют структурные тесты (BR-6), включая
+  control-path-инварианты (TC-13/TC-14).
+- **Преждевременная замена** в погоне за экономией ценой автономности/гибкости → инвентаризация
+  отделена от реализации; первый срез — самый низкорисковый «чисто деривируемый» control path.
+- **Фабрикация ссылок/ID** (рецидив дефекта R2) → митигирует NFR-6 (только проверяемые ссылки;
+  follow-up'ы — по роли) и ревью. Детали техн.рисков — `10-tech-risks.md` (архитектор).

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

@@ -0,0 +1,234 @@
+---
+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.
+>
+> 🔁 **R5 — единственный оставшийся блокер R4-ревью.** Артефакты разводили «консультация ≠ транспорт/
+> слот», но **не делали явной control-path-ось** — самую важную для названия задачи: среди реальных
+> консультаций **не различались** (C) control-path (LLM-вердикт потребляется потоком управления —
+> `check_*` ветвится на нём) и (P) artifact-producer (детерминированный гейт судит артефакт; суждение
+> LLM в control flow не входит); и нигде **не был определён** термин **«avoidable LLM control path»**.
+> R5 добавляет ось + определение (BRD §0-bis) и тянет их в FR-1/FR-2 + новый **FR-8**, в инвентарь
+> §1 (новая колонка), в тесты FR-6 (**TC-13/TC-14**). Содержательная классификация не меняется —
+> R5 **выводит** её из `src/qg/checks.py`.
+
+---
+
+## 1. Сводка изменения
+
+Выпустить **доказательную карту** всех мест вызова LLM в оркестраторе с классификацией и
+упорядоченным roadmap'ом детерминированных замен, а также нормативную **политику использования LLM**;
+прибить инварианты карты к коду набором **структурных тестов**. Реализация замен не входит. Все
+рантайм-контракты (`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД) —
+**не меняются**.
+
+Опорный факт инвентаризации (ground-truth кода на момент задачи; line-привязки уточняет карта):
+
+> Единица — **LLM-консультация** (потребление суждения LLM), а не «спавн процесса» (R4, BRD §0).
+> R5: дополнительно размечается **ось (C) control-path / (P) artifact-producer** и **потребитель
+> вывода** (`check_*`/`_parse_*`), доказывающий ось. Колонка `Консультирует LLM?` помечает транспорт/
+> слот vs факт консультации; колонка `Control path?` помечает, входит ли LLM-вывод в поток управления.
+
+| # | Call-site | Где | Что делает | Консультирует LLM? | Потребитель вывода (control-flow consumer) | Control path? (C/P) | Avoidable LLM control path? |
+|---|-----------|-----|------------|--------------------|--------------------------------------------|---------------------|-----------------------------|
+| S0 | **Единственный транспорт LLM-консультации** | `src/agents/launcher.py::_spawn` (`CLAUDE_BIN --print … --system-prompt "$(cat …)"` + `Popen`) | реализует консультацию для любой из 6 ролей | транспорт (capability) | — | — | — (транспорт, не call-site решения) |
+| A1 | analyst | `.openclaw/agents/analyst.md`, стадия `analysis` | анализ → 01–04 | да (через S0) | `check_analysis_complete` (`src/qg/checks.py:33`) — **наличие файлов** | **P** (artifact-producer) | **нет** (не control path) → keep-LLM |
+| A2 | architect | `.openclaw/agents/architect.md`, стадия `architecture` | архитектура → 06-adr | да (через S0) | `check_architecture_done` (`checks.py:62`) — **наличие** 06-adr/07 | **P** | **нет** → keep-LLM |
+| A3 | developer | `.openclaw/agents/developer.md`, стадия `development` | реализация + PR | да (через S0) | `check_ci_green` (`checks.py:82`) + `check_branch_mergeable` (`checks.py:657`) — **CI/merge** | **P** | **нет** → keep-LLM |
+| A4 | reviewer | `.openclaw/agents/reviewer.md`, стадия `review` | ревью → `12-review.md` (`verdict:`) | да (через S0) | `check_reviewer_verdict` (`checks.py:336`) читает **`verdict:`** → REQUEST_CHANGES-откат | **C** (control path) | **нет** (вердикт НЕ деривируем — настоящее суждение) → keep-LLM |
+| A5 | tester | `.openclaw/agents/tester.md`, стадия `testing` | `pytest`+smoke → `13-test-report.md` (`result:`) | да (через S0) | `check_tests_passed` (`checks.py:182`) → `_parse_tests_verdict` (`checks.py:226`) читает **`result:`** | **C** | **ДА** (вердикт = exit-code `pytest`/smoke) → needs-hybrid-fallback |
+| A6 | deployer | `.openclaw/agents/deployer.md`, стадии `deploy-staging`/`deploy` | `staging_check.py`/exit-code → `15`/`14` логи | да (через S0) | `check_staging_status` (`checks.py:599`)→`_parse_staging_status` (`checks.py:538`) **`staging_status:`**; `check_deploy_status` (`checks.py:473`)→`_parse_deploy_status` (`checks.py:413`) **`deploy_status:`** | **C** | **ДА** (вердикт = `staging_check.py`/exit-code; прод уже детерминирован Phase A/B/C) → replace-deterministic |
+| D1 | deploy-finalizer | `launch_job` перехват **до** `_spawn` (`launcher.py:389`) | детерминированный (LLM не консультируется) | **нет** (слот агента, перехват до `_spawn`) | — | — (нет консультации) | — (уже детерминирован) |
+| D2 | post-deploy-monitor | `launch_job` перехват **до** `_spawn` (`launcher.py:394`) | детерминированный (LLM не консультируется) | **нет** (слот агента, перехват до `_spawn`) | — | — (нет консультации) | — (уже детерминирован) |
+
+> **Чтение таблицы (R5).** Три ортогональных факта: (1) `Консультирует LLM?` — транспорт/слот vs факт
+> консультации (R4 §0); (2) `Control path?` — входит ли вывод роли в **поток управления** (C: `check_*`
+> ветвится на LLM-вердикте; P: детерминированный гейт судит артефакт независимо); (3) `Avoidable …?` —
+> двухбитный предикат BRD §0-bis (C **И** вердикт деривируем из tool-сигналов). Итог: **avoidable LLM
+> control paths = {tester, deployer}**; control-path-но-keep = `{reviewer}`; не-control-path =
+> `{analyst, architect, developer}`.
+>
+> Не-агентские 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:389/394`, `AGENT_CONFIGS`, `resolve_agent_model/effort`) — **не менять** |
+| `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md` | **читать** (инвентарь 6 ролей) — **не менять** |
+| `src/qg/checks.py` | **читать** (доказательство control-path-оси: кто потребляет вывод каждой роли — `check_analysis_complete:33`/`check_architecture_done:62`/`check_ci_green:82`/`check_reviewer_verdict:336`/`check_tests_passed:182`+`_parse_tests_verdict:226`/`check_staging_status:599`+`_parse_staging_status:538`/`check_deploy_status:473`+`_parse_deploy_status:413`; `QG_CHECKS`-реестр) — **не менять** |
+| `src/stages.py`, `src/stage_engine.py` | **читать** (доказать детерминизм маршрутизации) — **не менять** |
+| `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'ов + классификация + **control-path-разметка** (FR-1/FR-2/FR-3/FR-8) |
+| `docs/architecture/llm-determinization-roadmap.md` *(имя — пример)* | **создать**: упорядоченный roadmap (FR-4) |
+| `docs/architecture/llm-usage-policy.md` *(имя — пример)* | **создать**: нормативная политика + определение «avoidable LLM control path» (FR-5/FR-8) |
+| `docs/work-items/ORCH-118/06-adr/ADR-001-*.md` | **создать** (архитектор): фиксация карты/таксономии/control-path-оси/первого среза как ADR |
+| `tests/test_llm_call_site_inventory.py` *(имя — пример)* | **создать**: структурные анти-дрейф тесты (FR-6), включая control-path-инварианты |
+| `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` (если
+есть), **`output consumer` (`check_*`/`_parse_*` с `file:line` — кто потребляет вывод роли)**,
+`est. tokens/runtime`, **`consults-LLM`** (consultation vs LLM-capable transport/slot, §0.3),
+**`axis` (C control-path / P artifact-producer, §0-bis)**, `classification`, `rationale`, `dependency`,
+`risk`. Каждый `file:line` обязан резолвиться в реальный код. Инвариант (транспорт-агностичный,
+двусторонний): единственный транспорт LLM-консультации в `src/**` — `S0`; **иного LLM-транспорта нет** —
+тесты FR-6(a)+(f).
+
+### FR-2 — Таксономия классификации (BR-2)
+Ровно 4 взаимоисключающих класса с определениями:
+- `keep-LLM` — нужно настоящее суждение; **обязательно назвать** конкретное суждение.
+- `replace-deterministic-now` — безопасная детерминированная замена сейчас.
+- `replace-later/risky` — замена возможна, но позже / с риском (нужны предпосылки).
+- `needs-hybrid-fallback` — детерминированное ядро + LLM-фолбэк только на суждение.
+
+Каждому call-site присвоен **ровно один** класс, и класс **выводится из control-path-оси** (§0-bis,
+FR-8), а не постулируется:
+- **P (artifact-producer)** → `keep-LLM` — детерминированный гейт судит артефакт; авторская работа
+  требует суждения: `analyst`, `architect`, `developer`.
+- **C + НЕ-деривируемый вердикт** → `keep-LLM` — control path, но суждение настоящее: `reviewer`
+  (назвать суждение: «приемлемость кода/решения», не сводится к exit-коду).
+- **C + деривируемый вердикт** → avoidable → `replace-*` / `needs-hybrid-fallback`:
+  `deployer → replace-deterministic-now`/`replace-later/risky` (staging = exit-code-маппинг; прод
+  self-hosting уже детерминирован Phase A/B/C), `tester → needs-hybrid-fallback` (детерминированный
+  прогон `pytest`+smoke даёт PASS/FAIL; LLM-суждение только на триаж падений / маппинг TC↔критерии).
+- `deploy-finalizer/post-deploy-monitor → already-deterministic` (вне таксономии замен, эталон).
+
+> 📌 **Follow-up'ы — по роли, без Plane-ID (R3, NFR-6).** Кандидаты обозначаются ролью
+> (deployer-замена, tester-гибрид), а не конкретными 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). Явно: **рекомендованный первый срез** + обоснование (самый
+низкорисковый, «чисто деривируемый» control path, опирающийся на существующий прецедент D1/D2).
+
+### FR-5 — Политика использования LLM (BR-5)
+Нормативный durable-документ: принцип «LLM — только где нужно настоящее суждение»; критерии решения
+keep vs replace, **сформулированные через ось §0-bis** (является ли путь control path — ветвится ли
+`check_*` на LLM-выводе; деривируем ли вердикт из tool-сигналов; обратимость; влияние на автономность);
+требование к новым/изменённым 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`) явно исключаются из матчинга.
+- **(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-сборщика. Allowlist единственного разрешённого транспорта = `S0`.
+- **(b) Нет консультации в детерминированных путях.** Перечисленные детерминированные модули и
+  обработчики `D1/D2` **не** консультируют LLM (ни `_spawn`-транспорта, ни альтернативного по (f)).
+- **(c)** Карта перечисляет ровно те промпт-файлы, что физически лежат в `.openclaw/agents/`.
+- **(d)** Классификация покрывает каждый перечисленный call-site **ровно один раз** (тотальность).
+- **(e) Capability ≠ consultation.** `D1/D2` перехватываются в `launch_job` **до** `_spawn`
+  (`launcher.py:389/394`) → занимают слот, но консультации нет.
+- **(g) Control-path-разметка верна (R5, TC-13).** Для каждой роли поле `axis` (C/P) карты **согласовано
+  с фактическим потребителем** в `src/qg/checks.py`: P-роли (`analyst`/`architect`/`developer`)
+  потребляются детерминированными гейтами (`check_analysis_complete`/`check_architecture_done`/
+  `check_ci_green`), C-роли (`reviewer`/`tester`/`deployer`) — verdict-парсерами
+  (`check_reviewer_verdict`/`_parse_tests_verdict`/`_parse_staging_status`/`_parse_deploy_status`).
+  Дрейф (роль переразмечена или потребитель в коде сменил природу) → красный.
+- **(h) Avoidable-набор зафиксирован (R5, TC-14).** Множество «avoidable LLM control path» в карте =
+  ровно `{tester, deployer}`; `reviewer` помечен control-path-но-keep; `analyst`/`architect`/
+  `developer` — не control path. Любое добавление/удаление без обновления карты → красный.
+
+> ❌ **Не вводить** тест, прибивающий карту к конкретным follow-up Plane-ID → ✅ тесты проверяют
+> только инварианты, резолвящиеся в код/файлы репозитория (R3, NFR-6).
+
+### FR-7 — Скоуп-гард (BR-7)
+Раннеры замен **не реализуются** в ORCH-118. Карта/roadmap явно помечают кандидатов **по роли**
+(deployer-замена, tester-гибрид) как follow-up, старт которых гейтится утверждением карты. Тест/диф не
+должны содержать новых детерминированных раннеров tester/deployer. **Конкретные follow-up Plane-ID не
+фиксируются** ни в одном артефакте (NFR-6).
+
+### FR-8 (R5) — Явная control-path-ось и определение «avoidable» (BR-8/BR-9)
+1. **Разметка оси.** Карта несёт для каждой консультации поле `axis` ∈ {C, P} (§0-bis) + доказательство
+   (поле `output consumer` — `check_*`/`_parse_*` с `file:line`). Разметка проверяема (FR-6g/TC-13).
+2. **Определение термина.** Карта/политика дают **нормативное определение** «avoidable LLM control
+   path» — двухбитный предикат: (i) C-консультация (LLM-вердикт потребляется потоком управления) **И**
+   (ii) вердикт деривируем из tool-сигналов (exit-code `pytest`/smoke/`staging_check.py`/деплоя).
+3. **Поимённый целевой набор.** Карта/roadmap **явно** называют `{tester, deployer}` как avoidable LLM
+   control paths, явно отделяя их от `reviewer` (C, но keep — суждение не деривируемо) и от
+   `analyst/architect/developer` (P — не control path). Набор проверяем (FR-6h/TC-14).
+4. **Связь с классификацией.** Класс из FR-2 **выводится** из (C/P)-типа и деривируемости (а не наоборот).
+
+## 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 (включая control-path TC-13/TC-14) — обычные `pytest`-тесты, **не** Quality Gate и **не** стадия.
+Политика LLM (FR-5) — нормативный документ, а не машинный гейт. ⚠️ Control-path-ось — **аналитическая
+разметка карты**, читающая `check_*` как ground-truth; она ничего в `src/qg/checks.py` не меняет.
+
+## 7. Совместимость / регресс
+- **Docs + tests only:** рантайм `src/**` не меняется → нулевая регрессия; enduro-trails не затронут;
+  kill-switch не нужен (нет рантайм-поведения), как в ORCH-077/079/101/102/103/011.
+- **Обратимость:** артефакты — документы и тесты; откат = удаление/правка docs (рантайм-риска нет).
+- **Анти-дрейф:** структурные тесты держат карту синхронной с кодом, включая control-path-ось
+  (TC-13/TC-14); норматив сопровождения — «менял места вызова LLM или потребителя вердикта в
+  `src/qg/checks.py` → обнови карту/разметку и политику в том же PR».
+- **Анти-фабрикация (R3):** артефакты фиксируют только проверяемые ссылки; follow-up'ы — по роли,
+  без выдуманных Plane-ID (NFR-6).
+- **Self-hosting:** не деплоит/не рестартит прод/не трогает `main` — безопасно для общего инстанса.

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

@@ -0,0 +1,209 @@
+---
+work_item: ORCH-118
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-118 — replace avoidable LLM control paths with deterministic implementations
+
+Work Item: **ORCH-118** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
+провалом). Reviewer/тестер проверяет их буквально по файлам репозитория. Напоминание: ORCH-118 —
+**inventory-first**, docs+tests only; реализация раннеров приёмкой **запрещена** в этой задаче (AC-7);
+фиксация конкретных follow-up Plane-ID **запрещена** (AC-9, R3).
+
+> 🔁 **R5.** Добавлены/уточнены критерии под **control-path-ось** (BRD §0-bis): среди реальных
+> консультаций различаются (C) control-path (LLM-вердикт потребляется потоком управления) и
+> (P) artifact-producer (детерминированный гейт судит артефакт); термин **«avoidable LLM control path»**
+> явно определён, целевой набор `{tester, deployer}` поимённо назван. Затронуты **AC-1**, **AC-2** и
+> новый **AC-10**; добавлены тесты **TC-13/TC-14**.
+
+---
+
+## AC-1 — Полнота и привязка инвентаря LLM-консультаций (+ control-path-разметка)
+
+**Условие:** Документ-карта перечисляет каждый call-site, где control-path потребляет (или способен
+потребить) суждение LLM — **единица = LLM-консультация, не «спавн процесса»** (R4) — с обязательными
+полями, привязанными к коду, **включая ось (C/P) и потребителя вывода** (R5).
+- **PASS:** Карта содержит `S0` (`launcher._spawn` — **единственный транспорт LLM-консультации**), все
+  6 ролей (analyst/architect/developer/reviewer/tester/deployer, консультируют через S0) и обе job-роли
+  (deploy-finalizer/post-deploy-monitor, помеченные **«занимают слот агента, но LLM не консультируют»** —
+  перехват до `_spawn`); у каждой записи заполнены `location (file:line)` / `trigger` / `stage/owner` /
+  `output` / `machine-verdict key (если есть)` / **`output consumer` (`check_*`/`_parse_*` с `file:line`)** /
+  `est. tokens-runtime` / **`consults-LLM`** / **`axis` (C control-path / P artifact-producer)** /
+  `classification` / `rationale`; каждый `file:line` резолвится в реальный код. Карта явно разводит
+  «транспорт/слот существует» и «LLM фактически консультируется» (§0) **и** «consultation входит в поток
+  управления (C)» vs «детерминированный гейт судит артефакт (P)» (§0-bis).
+- **FAIL:** Пропущен любой call-site; отсутствует любое обязательное поле (включая `output consumer`
+  или `axis`); `file:line` не резолвится; карта смешивает «процесс Claude CLI существует» с
+  «LLM-консультация происходит» (напр. помечает `D1/D2` консультирующими LLM); **или не размечает
+  ось C/P** (напр. называет analyst «control path», или не доказывает потребителем `check_*`); заявлен
+  второй транспорт LLM, не подтверждённый кодом.
+
+---
+
+## AC-2 — Классификация по таксономии (4 класса, тотально и однозначно, выведена из control-path-оси)
+
+**Условие:** Каждый перечисленный call-site отнесён ровно к одному классу с обоснованием,
+**выведенным** из оси §0-bis.
+- **PASS:** Таксономия определена явно (`keep-LLM` / `replace-deterministic-now` /
+  `replace-later/risky` / `needs-hybrid-fallback`); каждому site присвоен **ровно один** класс; класс
+  согласован с осью: **P → keep-LLM** (analyst/architect/developer), **C + не-деривируемый вердикт →
+  keep-LLM** (reviewer, с названным конкретным суждением, не сводимым к exit-коду), **C + деривируемый
+  вердикт → replace-\*/hybrid** (tester/deployer); у `keep-LLM`-записей назван **конкретный** вид
+  суждения, ради которого LLM сохраняется.
+- **FAIL:** Site не классифицирован / классифицирован дважды; класс вне таксономии; `keep-LLM` без
+  названного суждения; **класс противоречит оси** (напр. control-path-deployer помечен `keep-LLM` без
+  доказательства не-деривируемости вердикта, или artifact-producer-analyst помечен `replace-*`).
+
+---
+
+## AC-3 — Доказанный детерминизм не-агентских путей
+
+**Условие:** Карта отдельно фиксирует, что control-path'ы вне 6 агентов не консультируют LLM, с доказательством.
+- **PASS:** Перечислены маршрутизация (`advance_stage`/`STAGE_TRANSITIONS`), все `QG_CHECKS`/`check_*`,
+  парсеры `_parse_*`, `error_classifier`, под-гейты (security/merge/coverage/image-freshness),
+  `self_deploy` Phase A/B/C, reconciler/reaper/serial-gate/transition-lease — каждый с `file:line`,
+  подтверждающим отсутствие **LLM-консультации** (ни `_spawn`-транспорта, ни альтернативного). Их
+  subprocess-вызовы инструментов (`git`/`pytest`/`docker`/`ssh`/сканеры) явно квалифицированы как
+  **не-LLM** (детерминизм доказывается отсутствием LLM-транспорта, а не отсутствием subprocess).
+- **FAIL:** Утверждение о детерминизме без `file:line`-доказательства; путь, заявленный
+  детерминированным, фактически консультирует LLM (и это не отражено в инвентаре/классификации); либо
+  детерминизм «доказан» простым отсутствием subprocess (подмена дискриминатора, §0).
+
+---
+
+## AC-4 — Упорядоченный roadmap с обязательными атрибутами и первым срезом
+
+**Условие:** Есть ранжированный roadmap детерминированных замен.
+- **PASS:** Roadmap упорядочен; для каждого кандидата (названного **по роли**) указаны зависимости,
+  **оценка** экономии токенов/времени (со ссылкой на источник — `agent_runs`/`usage`), риск
+  безопасности, потребность в hybrid-fallback, ожидание kill-switch/обратимости и **тип follow-up
+  задачи по роли** (без конкретного Plane-ID); явно назван **рекомендованный первый срез** с
+  обоснованием (самый низкорисковый «чисто деривируемый» control path).
+- **FAIL:** Roadmap не упорядочен; у кандидата отсутствует любой обязательный атрибут; оценка экономии
+  не привязана к источнику; нет рекомендованного первого среза; кандидат привязан к выдуманному
+  Plane-ID (→ см. AC-9).
+
+---
+
+## AC-5 — Нормативная политика использования LLM
+
+**Условие:** Существует durable-документ политики.
+- **PASS:** Политика формулирует принцип «LLM — только где нужно настоящее суждение», даёт критерии
+  решения keep vs replace **через ось §0-bis** (control path ли это; деривируем ли вердикт) и требование
+  обосновывать любое новое использование LLM против политики; документ нормативный (durable, в `docs/`),
+  а не разовая заметка.
+- **FAIL:** Политика отсутствует; не нормативна; не опирается на control-path-критерий; противоречит
+  сохранению автономности (NFR-2).
+
+---
+
+## AC-6 — Структурные анти-дрейф тесты: зелёные и осмысленные
+
+**Условие:** Новый offline-тест-файл прибивает инварианты карты к коду; инвариант сформулирован вокруг
+**LLM-консультации/транспорта** (R4) **и control-path-оси** (R5), а не «существования процесса Claude CLI».
+- **PASS:** Тесты проверяют: (a) единственный транспорт LLM-консультации в `src/**` (= `launcher._spawn`);
+  **(f) отсутствие любого иного LLM-транспорта** (нет импорта `anthropic`/`openai`/LLM-SDK, нет прямого
+  HTTP-эндпоинта Anthropic/Claude, нет второго model-invoking subprocess-сборщика); (b) отсутствие
+  LLM-консультации в перечисленных детерминированных модулях и в обработчиках deploy-finalizer/
+  post-deploy-monitor; (c) двустороннюю сверку списка промптов карты с `.openclaw/agents/`;
+  (d) тотальность классификации; (e) перехват `D1/D2` в `launch_job` до `_spawn`; **(g) корректность
+  control-path-разметки (TC-13)** — `axis` каждой роли согласован с фактическим потребителем в
+  `src/qg/checks.py` (P-роли → `check_analysis_complete`/`check_architecture_done`/`check_ci_green`;
+  C-роли → `check_reviewer_verdict`/`_parse_tests_verdict`/`_parse_staging_status`/`_parse_deploy_status`);
+  **(h) фиксацию avoidable-набора (TC-14)** — множество avoidable LLM control paths = `{tester, deployer}`,
+  reviewer = control-path-keep, analyst/architect/developer = не control path. Дискриминатор тестов —
+  **«консультирует LLM», а не «спавнит subprocess»**. Тесты не используют сеть/LLM/subprocess-к-модели.
+  Полный `pytest tests/ -q` — зелёный.
+- **FAIL:** Тестов нет; тест тривиально проходит (не привязан к коду); инвариант проверяет лишь «один
+  `Popen` Claude CLI» **без** (f); **отсутствует control-path-инвариант (g/h)** — карта могла бы помечать
+  analyst «control path» или забыть deployer в avoidable-наборе, и тест бы это пропустил (корень
+  R4-блокера); тест выродился в «подсчёт всех subprocess»; любой тест красный; полный прогон `tests/`
+  падает; введён тест, прибивающий карту к конкретным follow-up Plane-ID (анти-паттерн R3).
+
+---
+
+## AC-7 — Скоуп и сохранение поведения
+
+**Условие:** ORCH-118 не меняет рантайм и не реализует раннеры.
+- **PASS:** Диф не меняет `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` /
+  machine-verdict-ключи / схему БД; в `src/**` нет нового детерминированного раннера tester/deployer
+  (раннеры замен не реализованы); изменения ограничены docs + новый(е) тест-файл(ы).
+- **FAIL:** Изменён любой из перечисленных рантайм-контрактов; реализован детерминированный раннер
+  замены; правки `src/**`-поведения вне инвентаря/тестов.
+
+---
+
+## AC-8 — Синхронизация golden-source документации
+
+**Условие:** Обзорные/архитектурные доки и CHANGELOG отражают новые артефакты.
+- **PASS:** `docs/architecture/README.md` и витрина `docs/overview/*` ссылаются на карту call-site'ов
+  и политику использования LLM; `CHANGELOG.md` обновлён в том же PR.
+- **FAIL:** Карта/политика введены, но golden-source доки/витрина/CHANGELOG не обновлены (ось ORCH-079/
+  ORCH-011 → finding ≥P1).
+
+---
+
+## AC-9 — Только проверяемые ссылки; follow-up'ы — по роли, без выдуманных ID (анти-фабрикация, R3)
+
+**Условие:** Ни один артефакт не фиксирует непроверяемых follow-up Plane-ID; кандидаты-замены
+именуются по роли.
+- **PASS:** Везде, где карта/BRD/TRZ/roadmap/ADR упоминают кандидата-замену, он назван **по роли**
+  (deployer-замена, tester-гибрид); конкретные follow-up Plane-ID **не указаны**; все `file:line`/
+  ссылки на документы резолвятся в репозиторий. Тип follow-up'а описан по роли, ID — «TBD / при
+  заведении задачи».
+- **FAIL:** Любой артефакт фиксирует конкретный follow-up Plane-ID (напр. `ORCH-115`/`ORCH-116`) как
+  нормативную привязку роли; присутствует ссылка/маркер, не резолвящийся в код/документ репозитория;
+  введён структурный тест, прибивающий карту к конкретному follow-up ID.
+
+> Контекст: AC-9 заменяет ранее ошибочный «канонический-маппинг» критерий ревизии R2. Корень
+> отклонения R2 — фиксация **несуществующих** ID (`ORCH-115`/`ORCH-116`) как нормативного инварианта
+> с непроверяемым источником («live Plane backlog»). R3 запрещает фабрикацию ID и переводит follow-up'ы
+> на именование по роли.
+
+---
+
+## AC-10 (R5) — Явная control-path-ось и определение «avoidable LLM control path»
+
+**Условие:** Артефакты **явно** различают control-path-консультации и artifact-producer-консультации и
+**явно** определяют целевой термин — это закрывает единственный оставшийся блокер R4-ревью (название
+задачи — «replace avoidable LLM **control paths**»).
+- **PASS:**
+  1. **Ось определена и применена.** Карта/политика явно вводят ось (C) control-path (LLM-вердикт
+     потребляется потоком управления — `check_*` ветвится на нём) vs (P) artifact-producer
+     (детерминированный гейт судит артефакт; суждение LLM в control flow не входит), и присваивают
+     **ровно один** тип каждой из 6 ролей с доказательством-потребителем (`check_*`/`_parse_*`,
+     `file:line`): P = `analyst`/`architect`/`developer`; C = `reviewer`/`tester`/`deployer`.
+  2. **Термин определён.** Дано нормативное определение «avoidable LLM control path» = двухбитный
+     предикат: (i) C-консультация **И** (ii) вердикт деривируем из tool-сигналов (exit-code `pytest`/
+     smoke/`staging_check.py`/деплоя).
+  3. **Целевой набор поимённо назван.** Артефакты явно называют **avoidable LLM control paths =
+     {tester, deployer}**, и явно отделяют: `reviewer` — control path, но **keep** (вердикт не
+     деривируем, настоящее суждение); `analyst`/`architect`/`developer` — **не** control path
+     (artifact-producer). Это согласовано с классификацией (AC-2) и закреплено тестами TC-13/TC-14.
+- **FAIL:** Артефакты упоминают «LLM control paths» без явного определения; не размечают ось C/P
+  по ролям или размечают её без доказательства-потребителя; не определяют «avoidable» как
+  проверяемый предикат; не называют поимённо целевой набор `{tester, deployer}` **или** не отделяют его
+  от reviewer (control-path-keep) и от analyst/architect/developer (не control path); разметка не
+  согласована с `src/qg/checks.py` / не закреплена TC-13/TC-14.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 / BR-8 / FR-8 |
+| AC-2 | BR-2 / FR-2 (выведена из §0-bis) |
+| AC-3 | BR-3 / FR-3 |
+| AC-4 | BR-4 / FR-4 |
+| AC-5 | BR-5 / FR-5 |
+| AC-6 | BR-6 / FR-6 (вкл. TC-13/TC-14) |
+| AC-7 | BR-7 / FR-7 / NFR-1 / NFR-3 |
+| AC-8 | NFR-4 / правила агентов §2,§6 (golden-source) |
+| AC-9 | NFR-6 / BR-7 / FR-7 (только проверяемые ссылки; follow-up'ы по роли, без выдуманных ID) |
+| AC-10 | **BR-8 / BR-9 / FR-8 / NFR-7 (R5 — control-path-ось + определение «avoidable»)** |

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

@@ -0,0 +1,132 @@
+work_item: ORCH-118
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+title: "LLM call-site inventory + control-path axis + classification + roadmap + usage policy (inventory-first, docs+tests only)"
+framework: pytest
+scope: >
+  Покрываются СТРУКТУРНЫЕ инварианты карты LLM-консультаций и анти-дрейф (FR-6), плюс скоуп-гард
+  (рантайм-контракты не тронуты, раннеры не реализованы) и анти-фабрикация ссылок/ID (TC-11).
+  Единица — LLM-КОНСУЛЬТАЦИЯ (control-path потребляет суждение LLM), а не «спавн процесса / Claude
+  CLI существует» (R4, BRD §0). Инвариант единственной точки — транспорт-агностичный и двусторонний:
+  TC-01 (единственный транспорт = _spawn) + TC-12 (отсутствует иной LLM-транспорт).
+  R5: добавлена CONTROL-PATH-ОСЬ (BRD §0-bis) — среди реальных консультаций различаются
+  (C) control-path (LLM-вердикт потребляется потоком управления, check_* ветвится на нём) и
+  (P) artifact-producer (детерминированный гейт судит артефакт); термин «avoidable LLM control path»
+  определён как двухбитный предикат (C И вердикт деривируем из tool-сигналов), целевой набор поимённо
+  = {tester, deployer}. Эту ось проверяют TC-13 (разметка C/P согласована с потребителем в
+  src/qg/checks.py) и TC-14 (avoidable-набор зафиксирован). ВНЕ покрытия: реализация детерминированных
+  раннеров deployer / tester — отдельные follow-up задачи (именуются по роли; конкретные Plane-ID в
+  ORCH-118 не фиксируются, R3/NFR-6).
+notes: >
+  Все тесты детерминированы и offline: без сети, без запуска LLM, без subprocess-к-модели.
+  Имена файла теста и документов карты — примерные (финально решает архитектор); тест-кейсы
+  привязываются к фактическим путям артефактов, выбранным в 06-adr. Полный регресс tests/
+  должен оставаться зелёным (TC-10). Дискриминатор всех structural-тестов — "консультирует LLM",
+  а НЕ "спавнит subprocess": прочие subprocess (git/pytest/docker/ssh/сканеры/staging_check.py) явно
+  исключаются из матчинга, иначе тест выродился бы в подсчёт всех Popen. Регрессом считается:
+  появление второго ТРАНСПОРТА LLM-консультации (новый _spawn ИЛИ импорт anthropic/openai/LLM-SDK ИЛИ
+  прямой HTTP Anthropic/Claude ИЛИ второй model-invoking subprocess), LLM-консультация в
+  детерминированном модуле, дрейф карты относительно .openclaw/agents/, изменение рантайм-контрактов
+  (STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict / схема БД), рассогласование
+  control-path-разметки с фактическим потребителем в src/qg/checks.py (TC-13), либо изменение
+  avoidable-набора без обновления карты (TC-14).
+  R5 (единственный блокер R4-ревью): артефакты разводили "консультация ≠ транспорт/слот", но не делали
+  явной CONTROL-PATH-ОСЬ — самую важную для названия задачи "replace avoidable LLM CONTROL PATHS".
+  Добавлены TC-13 (control-path-разметка C/P доказывается фактическим потребителем check_*/_parse_*) и
+  TC-14 (avoidable LLM control paths = {tester, deployer}; reviewer = control-path-keep;
+  analyst/architect/developer = не control path). TC-04 (тотальность) теперь сверяет согласованность
+  класса с осью.
+  R4 (предыдущий блокер): инвариант "места вызова LLM" разведён на ТРАНСПОРТ и КОНСУЛЬТАЦИЮ;
+  TC-01 уточнён (необходимое, но не достаточное), добавлен TC-12 (no-alternative-transport),
+  TC-02 уточнён по дискриминатору, TC-06 закрепляет capability ≠ consultation (D1/D2 — слот без
+  консультации).
+  R3: тест на привязку follow-up'ов к конкретным Plane-ID УДАЛЁН (бывш. TC-11) как анти-паттерн;
+  TC-11 теперь проверяет анти-фабрикацию (ID не выдуманы).
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "Единственный ТРАНСПОРТ LLM-консультации: ровно одно место в src/** собирает/запускает Claude CLI (матчинг по совокупности признаков LLM-транспорта CLAUDE_BIN + --system-prompt + Popen/bash -c), и это launcher._spawn. Необходимое, но НЕ достаточное условие — дополняется TC-12 (отсутствие иного транспорта) (R4 / FR-6a / AC-1)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Детерминированные модули без LLM-консультации: перечисленные leaf'ы (serial_gate, merge_gate, coverage_gate, security_gate, staging_verdict, review_parse, error_classifier, frontmatter, self_deploy, post_deploy, transition_lease, reconciler, job_reaper) не консультируют LLM (нет ни _spawn-транспорта, ни альтернативного по TC-12); их subprocess-вызовы git/pytest/docker/ssh/сканеров LLM-консультацией НЕ считаются — дискриминатор 'консультирует LLM', а не 'спавнит subprocess' (R4 / FR-6b / AC-3)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Анти-дрейф промптов: карта перечисляет ровно те 6 промпт-файлов, что физически лежат в .openclaw/agents/ (двусторонняя сверка, нет лишних/пропущенных) (FR-6c / AC-1)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Тотальность классификации: каждый перечисленный в карте call-site отнесён ровно к одному классу из таксономии {keep-LLM, replace-deterministic-now, replace-later/risky, needs-hybrid-fallback}; без дублей и пропусков; класс СОГЛАСОВАН с осью §0-bis (P → keep-LLM; C+не-деривируем → keep-LLM; C+деривируем → replace-*/hybrid) (FR-6d / FR-2 / AC-2)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "keep-LLM требует обоснования: каждая запись класса keep-LLM несёт непустое поле названного конкретного суждения; для C-keep (reviewer) обоснование явно фиксирует НЕ-деривируемость вердикта (почему не сводится к exit-коду) (FR-2 / AC-2)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Capability ≠ consultation: launch_job перехватывает deploy-finalizer и post-deploy-monitor ДО _spawn (launcher.py:389/394) — job занимает слот агента, но LLM НЕ консультируется (процесс/слот существует, суждение не потребляется) — эталон паттерна замены и прямая иллюстрация R4-различия (FR-6e / AC-3)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Полнота roadmap: документ roadmap для каждого кандидата (названного ПО РОЛИ) содержит обязательные атрибуты (зависимости / оценка экономии со ссылкой на agent_runs / риск / hybrid-need / тип follow-up задачи по роли) и явно называет рекомендованный первый срез (FR-4 / AC-4)"
+    module: tests/test_llm_determinization_docs.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Политика LLM существует и нормативна: документ политики содержит принцип 'LLM только где нужно суждение', критерии keep vs replace СФОРМУЛИРОВАННЫЕ через ось §0-bis (control path ли это; деривируем ли вердикт), и нормативное определение термина 'avoidable LLM control path' (FR-5 / FR-8 / AC-5, AC-10)"
+    module: tests/test_llm_determinization_docs.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "Скоуп-гард рантайм-контрактов: снимок set ролей-агентов из STAGE_TRANSITIONS и набора имён QG_CHECKS не изменился относительно эталона — ORCH-118 не тронул машину стадий/гейты (FR-7 / AC-7)"
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "Полный регресс tests/ остаётся зелёным (pytest tests/ -q) — инвентаризация и тесты не ломают существующий конвейер (NFR-1 / AC-6, AC-7)"
+    module: tests/
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Анти-фабрикация follow-up ID (R3 / NFR-6 / AC-9): документы карты/roadmap НЕ содержат привязки кандидатов-замен к конкретным follow-up Plane-ID несуществующих work item (паттерн ORCH-1\\d\\d, не равный самому ORCH-118 и не присутствующий в docs/work-items/); кандидаты именуются по роли. Заменяет ошибочный mapping-тест R2, прибивавший карту к выдуманным ID."
+    module: tests/test_llm_determinization_docs.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "Отсутствие иного LLM-транспорта (R4 / FR-6f / AC-1, AC-6): в src/** НЕТ альтернативного транспорта LLM-консультации помимо _spawn — ни импорта anthropic/openai/иного LLM-SDK, ни прямого HTTP-эндпоинта Anthropic/Claude (api.anthropic.com, /v1/messages), ни второго model-invoking subprocess-сборщика (другой бинарь с --system-prompt/--model). Закрывает дыру 'один _spawn зелёный, а рядом проросла новая консультация другим транспортом', которую TC-01 в одиночку не ловит. Allowlist единственного разрешённого транспорта = S0/launcher._spawn."
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-13
+    type: unit
+    description: "Control-path-ось верна (R5 / FR-6g / FR-8 / AC-10): поле axis (C/P) каждой из 6 ролей в карте СОГЛАСОВАНО с фактическим потребителем вывода в src/qg/checks.py — P-роли (analyst/architect/developer) потребляются детерминированными гейтами (check_analysis_complete:33 / check_architecture_done:62 / check_ci_green:82, судящими наличие файлов / CI, НЕ самоотчёт LLM); C-роли (reviewer/tester/deployer) потребляются verdict-парсерами, читающими machine-verdict, который написал LLM (check_reviewer_verdict:336 'verdict:' / check_tests_passed:182→_parse_tests_verdict:226 'result:' / check_staging_status:599→_parse_staging_status:538 'staging_status:' + check_deploy_status:473→_parse_deploy_status:413 'deploy_status:'). Дискриминатор: 'LLM-вердикт ветвит поток управления', а не 'на стадии есть LLM'. Рассогласование (роль переразмечена ИЛИ потребитель в коде сменил природу) → красный."
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS
+
+  - id: TC-14
+    type: unit
+    description: "Avoidable-набор зафиксирован (R5 / FR-6h / FR-8 / AC-10): множество 'avoidable LLM control path' в карте = РОВНО {tester, deployer} (C И вердикт деривируем из exit-кодов); reviewer помечен control-path-но-keep (C, вердикт НЕ деривируем — настоящее суждение); analyst/architect/developer помечены НЕ control path (P, artifact-producer). Любое добавление/удаление роли в avoidable-набор без обновления карты, либо пометка analyst/architect/developer 'control path', либо пометка reviewer 'avoidable' → красный. Закрывает корень R4-блокера: 'есть LLM на стадии' ≠ 'это avoidable LLM control path'."
+    module: tests/test_llm_call_site_inventory.py
+    expected: PASS

docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md

@@ -0,0 +1,295 @@
+---
+work_item: ORCH-118
+stage: architecture
+author_agent: architect
+status: accepted
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Карта LLM-консультаций, control-path-ось «avoidable» и roadmap детерминизации
+
+Work Item: **ORCH-118** — replace avoidable LLM control paths with deterministic implementations
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`**
+(решение кросс-каттинговое — вводит нормативную политику использования LLM для всего оркестратора и
+снимок-карту, прибитую к коду тестами).
+
+## Статус
+Accepted
+
+## Контекст
+
+ORCH-118 — **зонтичная inventory/architecture-задача** (RCA-трек ORCH-114/117 и предшественники
+110/111/112/113): корневым классом инцидентов было отсутствие **единого детерминированного владения**
+у side-effectful и решающих control-path'ов — местами решение принималось LLM-агентом «потому что
+удобно», хотя по сути это исполнение фиксированных команд и маппинг результата. Задача **не**
+реализует детерминированные раннеры (это follow-up'ы); её выход — **доказательная карта** всех мест
+вызова LLM + классификация + roadmap + нормативная политика, защищённые структурными тестами.
+
+ТЗ (02-trz) оставляет **архитектору** решить «как»: структуру/размещение/формат документов карты,
+схему классификации, дизайн структурных тестов, рекомендованный первый срез. Этот ADR это фиксирует.
+
+**Факты, сверенные с кодом на момент задачи (ground-truth):**
+
+- **Единственный транспорт LLM-консультации в `src/**`** — `src/agents/launcher.py::_spawn` (`def` —
+  `launcher.py:472`; сборка CLI `f'{self.CLAUDE_BIN} --print … --system-prompt "$(cat {system_prompt})"'`
+  — `launcher.py:610-614`; парс токенов из CLI-JSON — `_monitor_agent`, `launcher.py:838`). Им
+  пользуются ровно **6 ролей** (`.openclaw/agents/{analyst,architect,developer,reviewer,tester,
+  deployer}.md` — подтверждено `ls .openclaw/agents/`). **Иного LLM-транспорта нет:**
+  `grep -rnE "import (anthropic|openai)|api\.anthropic\.com|/v1/messages" src/ watchdog/` → пусто;
+  `CLAUDE_BIN` вне `_spawn` встречается только в `src/preflight.py` (проверка `os.path.exists`, **не**
+  инференс) и `src/config.py:65` (литерал дефолта пути). Это критично для дизайна теста (D5).
+- **Потребитель вывода каждой роли** (`src/qg/checks.py`, все `file:line` резолвятся):
+  `check_analysis_complete:33` (наличие файлов), `check_architecture_done:62` (наличие 06-adr/07),
+  `check_ci_green:82` + `check_branch_mergeable:657` (CI/merge), `check_reviewer_verdict:336`
+  (`verdict:`), `check_tests_passed:182` → `_parse_tests_verdict:226` (`result:`),
+  `check_staging_status:599` → `_parse_staging_status:538` (`staging_status:`),
+  `check_deploy_status:473` → `_parse_deploy_status:413` (`deploy_status:`).
+- **Перехват D1/D2 до `_spawn`:** `launch_job:377` возвращает рано для `agent=="deploy-finalizer"`
+  (`launcher.py:389`) и `agent=="post-deploy-monitor"` (`launcher.py:394`) — код прямо помечает «Not an
+  LLM spawn» (`launcher.py:407,428`). Слот агента занят, но консультации LLM нет — **рабочий прецедент
+  детерминированной замены агента**.
+- **Не-агентские control-path'ы уже детерминированы** (LLM-консультации не несут — подтверждено
+  наличием модулей): `src/{stages,stage_engine,staging_verdict,self_deploy,error_classifier,
+  frontmatter,serial_gate,merge_gate,coverage_gate,security_gate,post_deploy,transition_lease,
+  reconciler,job_reaper}.py`. Их subprocess-вызовы (`git`/`pytest`/`docker`/`ssh`/сканеры) —
+  детерминированные **инструменты**, а не LLM.
+
+Без архитектурной фиксации «как» развести **три ортогональных факта** (транспорт/слот ≠ консультация
+≠ control-path) и без нормативного определения «avoidable LLM control path» карта осталась бы
+субъективной, а тесты — тривиальными (корень R4/R5-блокеров BRD).
+
+## Решение
+
+### Сводка
+
+Фиксируем: (D1) набор и размещение durable-документов; (D2) схему записи инвентаря; (D3) три
+ортогональных оси и **нормативное определение** «avoidable LLM control path»; (D4) таксономию и
+правило **вывода** класса из осей с поимённой канонической таблицей ролей (= «фиксация карты»);
+(D5) дизайн структурных анти-дрейф тестов; (D6) рекомендованный первый срез roadmap'а; (D7)
+скоуп-гард. ORCH-118 — **docs + tests only**: `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/
+`check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен **не**
+реализуются; конкретные follow-up Plane-ID **не** фиксируются (NFR-6).
+
+### D1 — Набор и размещение документов (BR-1/BR-4/BR-5; FR-1/FR-4/FR-5; AC-1/AC-4/AC-5)
+
+Три durable-документа размещаются в **`docs/architecture/`** (сквозные, переживают задачу, читаются
+будущими follow-up'ами) — НЕ только в `docs/work-items/ORCH-118/`:
+
+| Файл | Роль | Жизненный цикл |
+|------|------|----------------|
+| `docs/architecture/llm-call-sites.md` | **Карта** call-site'ов: инвентарь + control-path-разметка + классификация (D2/D3/D4) | **Снимок**, прибит тестами (D5); обновляется при дрейфе кода |
+| `docs/architecture/llm-determinization-roadmap.md` | **Roadmap** замен: порядок, экономия, риски, первый срез (D6) | Транзиентный план; обновляется по мере закрытия follow-up'ов |
+| `docs/architecture/llm-usage-policy.md` | **Политика**: принцип + критерии keep/replace через ось §0-bis + **определение «avoidable LLM control path»** (D3) | Нормативный durable-документ |
+
+**Решение о разделении на 3 файла** (а не один): у них разные аудитория и жизненный цикл — карта
+машинно-сверяется и есть снимок; roadmap транзиентен; политика нормативна и стабильна. Слияние
+размыло бы тестируемость карты и стабильность политики.
+
+> **Авторство.** Содержательное «как» (структура, поля, оси, классификация, дизайн тестов, первый
+> срез) фиксирует **этот ADR** (он и есть «фиксация карты» по TRZ §2). Физическое создание трёх
+> `docs/architecture/llm-*.md` + тест-файла + синхронизация golden-source (README/overview/CHANGELOG)
+> — деливерабл **стадии development** строго по этому ADR. Канонические таблицы D3/D4 ниже —
+> **source of truth**, которую развёрнутые документы и тесты **зеркалят** без расхождений.
+
+### D2 — Схема записи инвентаря (BR-1/BR-8; FR-1/FR-8; AC-1)
+
+Каждая строка карты несёт **обязательные поля** (порядок — нормативный, тест D5 проверяет наличие):
+
+`id` · `location (file:line)` · `trigger` · `stage/owner` · `output artifact` · `machine-verdict key`
+(если есть) · **`output consumer`** (`check_*`/`_parse_*` с `file:line` — кто потребляет вывод роли) ·
+`est. tokens/runtime` (источник — `agent_runs`, помечено «оценка») · **`consults-LLM`** (consultation
+vs LLM-capable transport/slot, §0.3 BRD) · **`axis`** (C control-path / P artifact-producer, §0-bis) ·
+`classification` (D4) · `rationale` · `dependency` · `risk`.
+
+Каждый `file:line` **обязан резолвиться** в реальный код (тест D5 точечно проверяет ключевые якоря).
+
+**Машинно-читаемый якорь для тестов.** Карта несёт в `llm-call-sites.md` **канонический
+markdown-блок** со стабильным заголовком таблицы (колонки `id | role | location | output_consumer |
+consults_llm | axis | avoidable | classification`). Тест D5 парсит этот блок (split по `|`, без новых
+зависимостей) и сверяет с кодом. Это держит документ человекочитаемым и одновременно
+машинно-проверяемым (вместо хрупкого regex по прозе).
+
+### D3 — Три ортогональных оси и нормативное определение «avoidable LLM control path» (BR-8/BR-9; FR-8; AC-10; NFR-7)
+
+Карта/политика **явно** вводят три раздельных факта (их смешение — корень R3→R5-блокеров):
+
+1. **Ось 1 — consultation ≠ transport/slot.** «LLM-консультация» = точка, где решение/артефакт
+   конвейера **потребляет суждение LLM**. Транспорт (`_spawn`) — реализация, не определение. Слот
+   агента (D1/D2 job-роли) делает site LLM-**capable**, но консультация гейтится потоком управления
+   (перехват до `_spawn`) → capability ≠ consultation.
+2. **Ось 2 — control-path (C) ≠ artifact-producer (P).** Определяется **кодом-потребителем**:
+   - **(C) control-path** — LLM эмитит machine-verdict, на котором **ветвится `check_*`-гейт**
+     (PASS→дальше / FAIL→откат). Суждение LLM входит в control flow.
+   - **(P) artifact-producer** — LLM производит артефакт, а продвижение решает **детерминированный
+     гейт**, судящий артефакт **независимо** (наличие файлов / CI). Суждение LLM в control flow не
+     входит.
+3. **Ось 3 — деривируемость вердикта.** Вердикт C-консультации либо есть **детерминированная функция
+   tool-сигналов** (exit-code `pytest`/smoke/`staging_check.py`/деплоя), которые оркестратор **уже
+   вычисляет сам**, либо требует **настоящего суждения**, не сводимого к exit-коду.
+
+**Нормативное определение (фиксируется в `llm-usage-policy.md`):**
+
+> Call-site — **avoidable LLM control path** ⟺ выполнены **оба** условия:
+> **(i)** это **C**-консультация (её LLM-вердикт потребляется потоком управления — `check_*` ветвится
+> на нём); **и** **(ii)** вердикт **деривируем** из tool-сигналов, которые оркестратор уже вычисляет
+> → суждение LLM не добавляет информации → консультацию можно снять без потери смысла.
+
+Это **двухбитный проверяемый предикат над `src/qg/checks.py`**, а не «удобство на глаз».
+
+### D4 — Таксономия и каноническая классификация (= «фиксация карты») (BR-2; FR-2; AC-2)
+
+Четыре взаимоисключающих класса; класс **выводится** из осей D3 (а не постулируется):
+
+- `keep-LLM` — нужно настоящее суждение (обязательно **назвать** конкретное суждение).
+- `replace-deterministic-now` — безопасная детерминированная замена сейчас.
+- `replace-later/risky` — замена возможна позже / с предпосылками.
+- `needs-hybrid-fallback` — детерминированное ядро + LLM-фолбэк только на суждение.
+
+**Правило вывода:** `P → keep-LLM`; `C + не-деривируемый вердикт → keep-LLM`; `C + деривируемый
+вердикт → replace-* / needs-hybrid-fallback (= avoidable)`.
+
+**Каноническая таблица (source of truth; карта и тесты зеркалят её байт-в-смысл):**
+
+| id | Роль | Транспорт/слот | Потребитель вывода (`src/qg/checks.py`) | Ось | Avoidable LLM control path? | Класс | Названное суждение (для keep) |
+|----|------|----------------|------------------------------------------|-----|------------------------------|-------|-------------------------------|
+| S0 | `_spawn` | транспорт | — | — | — (транспорт) | — | — |
+| A1 | analyst | да (через S0) | `check_analysis_complete:33` (наличие файлов) | **P** | нет | `keep-LLM` | анализ требований, BRD/ТЗ — суждение |
+| A2 | architect | да (через S0) | `check_architecture_done:62` (наличие 06-adr/07) | **P** | нет | `keep-LLM` | архитектурное решение/ADR — суждение |
+| A3 | developer | да (через S0) | `check_ci_green:82` + `check_branch_mergeable:657` (CI/merge) | **P** | нет | `keep-LLM` | написание кода — суждение |
+| A4 | reviewer | да (через S0) | `check_reviewer_verdict:336` (`verdict:`) | **C** | **нет** (вердикт НЕ деривируем) | `keep-LLM` | «приемлемость кода/решения» — не сводится к exit-коду |
+| A5 | tester | да (через S0) | `check_tests_passed:182`→`_parse_tests_verdict:226` (`result:`) | **C** | **ДА** | `needs-hybrid-fallback` | (ядро детерминировано; LLM — триаж падений / маппинг TC↔критерии) |
+| A6 | deployer | да (через S0) | `check_staging_status:599`→`_parse_staging_status:538` (`staging_status:`); `check_deploy_status:473`→`_parse_deploy_status:413` (`deploy_status:`) | **C** | **ДА** | `replace-deterministic-now` | (вердикт = `staging_check.py`/exit-code; прод уже детерминирован Phase A/B/C ORCH-036) |
+| D1 | deploy-finalizer | слот, перехват до `_spawn` (`launcher.py:389`) | — | — | — (уже детерминирован) | `already-deterministic` (эталон) | — |
+| D2 | post-deploy-monitor | слот, перехват до `_spawn` (`launcher.py:394`) | — | — | — (уже детерминирован) | `already-deterministic` (эталон) | — |
+
+**Итог (поимённо, проверяется тестами D5):** `avoidable LLM control paths = {tester, deployer}`;
+control-path-но-keep = `{reviewer}`; не-control-path (P) = `{analyst, architect, developer}`;
+already-deterministic-эталон = `{deploy-finalizer, post-deploy-monitor}`.
+
+> **Уточнение по deployer (точность карты).** Роль `deployer` охватывает два ребра. На `deploy-staging`
+> (`staging_status:`) её вердикт — чистый маппинг exit-кода `staging_check.py` → `replace-deterministic
+> -now`. На `deploy` (`deploy_status:`) для self-hosting `orchestrator` вердикт **уже** производит
+> детерминированный finalizer (Phase C, ORCH-036), LLM в критическом self-restart-пути нет; для прочих
+> репо deployer-агент делает синхронный ssh-деплой. Поэтому «чисто деривируемый» срез deployer'а —
+> прежде всего **staging-status** (см. D6).
+
+### D5 — Дизайн структурных анти-дрейф тестов (BR-6; FR-6; AC-6)
+
+Новый offline-файл `tests/test_llm_call_site_inventory.py` (без сети/LLM/subprocess-к-модели; маркер
+`# ORCH-118` в шапке — TRACEABILITY). Дискриминатор всех проверок — **«консультирует LLM», а не
+«спавнит subprocess»**.
+
+- **(a) Единственный транспорт.** В `src/**` ровно одна точка сборки/запуска Claude CLI — матчинг по
+  **конъюнкции** признаков LLM-транспорта (`CLAUDE_BIN` **и** `--system-prompt` **и** `Popen`/`bash -c`
+  в одном месте), и это `launcher._spawn`. ⚠️ Конъюнкция обязательна: bare-`CLAUDE_BIN` дал бы
+  false-positive на `preflight.py` (existence-check) и `config.py` (литерал пути) — они **не**
+  консультируют (см. Контекст). Allowlist единственного транспорта = `_spawn`.
+- **(f) Отсутствие иного LLM-транспорта.** В `src/**`+`watchdog/**` нет импорта `anthropic`/`openai`/
+  LLM-SDK, нет прямого HTTP-эндпоинта Anthropic/Claude (`api.anthropic.com`, `/v1/messages`), нет
+  второго model-invoking subprocess-сборщика. *(a)+(f) вместе = транспорт-агностичный двусторонний
+  инвариант.*
+- **(b) Нет консультации в детерминированных путях.** Перечисленные модули D-списка и обработчики
+  D1/D2 не содержат LLM-транспорта (ни `_spawn`, ни (f)).
+- **(c) Промпты ↔ файлы.** Карта перечисляет **ровно** те 6 промптов, что физически лежат в
+  `.openclaw/agents/` (двусторонняя сверка с `glob`).
+- **(d) Тотальность.** Каждый перечисленный в карте call-site классифицирован **ровно один раз**.
+- **(e) Capability ≠ consultation.** `launch_job` перехватывает `deploy-finalizer`/`post-deploy-monitor`
+  **до** `_spawn` (assert по `launcher.py` — наличие ранних return-веток до точки spawn).
+- **(g) Control-path-разметка верна (TC-13).** Из машинного блока карты (D2) извлекается `role→axis`;
+  тест сверяет: P-роли потребляются `check_analysis_complete`/`check_architecture_done`/`check_ci_green`,
+  C-роли — `check_reviewer_verdict`/`_parse_tests_verdict`/`_parse_staging_status`/`_parse_deploy_status`
+  (наличие этих `def` в `src/qg/checks.py` как ground-truth). Дрейф разметки → красный.
+- **(h) Avoidable-набор зафиксирован (TC-14).** Множество avoidable из карты = ровно `{tester,
+  deployer}`; `reviewer` = control-path-keep; `analyst`/`architect`/`developer` = не control path.
+
+> ❌ **Не вводить** тест, прибивающий карту к конкретным follow-up Plane-ID → ✅ только инварианты,
+> резолвящиеся в код/файлы репозитория (R3/NFR-6). Тесты — обычный `pytest`, **не** Quality Gate и
+> **не** стадия (FR-6 §QG).
+
+### D6 — Рекомендованный первый срез roadmap'а (BR-4; FR-4; AC-4)
+
+**Первый срез = deployer (staging-status).** Обоснование (самый низкорисковый «чисто деривируемый»
+control path):
+
+1. Вердикт — **чистый маппинг** exit-кода `scripts/staging_check.py` → `staging_status:` (уже есть
+   leaf `src/staging_verdict.py` с `compute_staging_verdict`, ORCH-061) — деривируемость максимальна.
+2. **Прод уже детерминирован** (Phase A/B/C, ORCH-036) → срез не трогает критический self-restart-путь
+   → минимальная поверхность риска.
+3. Опирается на **существующий прецедент** D1/D2 (`launch_job`-перехват до `_spawn`) — архитектурный
+   риск замены снижен (BRD §6).
+4. `replace-deterministic-now`, без потребности в hybrid-fallback (в отличие от tester).
+
+**Порядок roadmap'а:** (1) **deployer-замена** (staging-маппинг; prod уже детерминирован) →
+(2) **tester-гибрид** (детерминированное ядро `pytest`+smoke + LLM-фолбэк на триаж падений / маппинг
+TC↔критерии — `needs-hybrid-fallback`). Для каждого кандидата roadmap несёт: зависимости, **оценку**
+экономии токенов/времени из `agent_runs` (помечено «оценка до фактического замера», NFR-5), риск
+безопасности, потребность в hybrid-fallback, ожидание kill-switch/обратимости. Кандидаты названы
+**по роли**; конкретный Plane-ID **не** фиксируется (NFR-6) — заводится при создании задачи.
+
+### D7 — Скоуп-гард и инварианты (BR-7; FR-7; NFR-1/NFR-3; AC-7/AC-9)
+
+- **Docs + tests only.** Диф не меняет `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` /
+  machine-verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
+  `coverage_status:`) / схему БД. В `src/**` нет нового детерминированного раннера tester/deployer.
+- **Анти-фабрикация.** Ни один артефакт не фиксирует конкретный follow-up Plane-ID; все ссылки
+  резолвятся в репозиторий. Тест не пинит карту к follow-up ID.
+- **Self-hosting.** Только чтение кода + запись docs/tests — не деплоит, не рестартит прод, не трогает
+  `main`/force-push, без процессов/сети. kill-switch не нужен (нет рантайм-поведения), как
+  ORCH-077/079/101/102/103/011.
+- **Наблюдаемость в `GET /queue`/`GET /metrics`** — **вне скоупа** (TRZ §4); карта/политика —
+  документы, не рантайм.
+
+### Применимость 07/08
+- **07-infra-requirements — N/A:** топология не меняется (нет нового сервиса/контейнера/порта/маунта).
+- **08-data-requirements — N/A:** схема БД не меняется; `agent_runs` читается только для оценок (NFR-5).
+
+## Альтернативы
+
+- **Один объединённый документ (карта+roadmap+политика)** — отвергнуто: разные жизненные циклы и
+  тестируемость (D1); снижает стабильность нормативной политики и проверяемость снимка-карты.
+- **Размещение карты только в `docs/work-items/ORCH-118/`** — отвергнуто: документ сквозной и durable,
+  читается будущими follow-up'ами; work-item-папка — неверная альтитуда (теряется при навигации по
+  архитектуре).
+- **Тест по сырому regex прозы карты** — отвергнуто как хрупкое: дрейф формулировок ломал бы тест без
+  смыслового дрейфа. Выбран машинный markdown-блок (D2/D5g).
+- **Тест-матчинг по bare-`CLAUDE_BIN`** — отвергнуто: false-positive на `preflight.py`/`config.py`
+  (capability/литерал, не консультация). Выбрана конъюнкция признаков транспорта (D5a).
+- **Фиксация follow-up Plane-ID (`ORCH-115`/`ORCH-116`)** — отвергнуто нормативно (NFR-6, корень
+  отклонённой ревизии R2): этих work item нет; кандидаты — по роли.
+- **Первый срез = tester** — отвергнуто: tester требует hybrid-fallback (триаж падений), поверхность
+  риска и объём больше; deployer-staging — чище деривируем и лучше обеспечен прецедентом (D6).
+- **Включить наблюдаемость карты в `GET /queue`** — отвергнуто как scope-creep (TRZ §4): карта —
+  документ, а не рантайм-состояние.
+
+## Последствия
+
+- **+** Доказательная, код-привязанная карта разводит транспорт/слот ≠ консультация ≠ control-path и
+  даёт **проверяемый** предикат «avoidable» → закрывает блокеры R3→R5; follow-up'ы выполняются
+  предсказуемо.
+- **+** Нормативная политика делает «LLM только там, где нужно суждение» инвариантом любой будущей
+  правки control-path'а; защищает автономность (NFR-2).
+- **+** Структурные тесты держат карту синхронной с кодом (включая control-path-ось) — анти-дрейф.
+- **−** Карта — **снимок**: при эволюции `src/qg/checks.py` (смена потребителя / новая роль) тесты
+  D5g/h станут красными — требуется обновлять карту/политику в том же PR. *Митигейшн:* это
+  **запланированное** свойство (норматив сопровождения), а не дефект; тест указывает точку дрейфа.
+- **−** Машинный блок карты вводит лёгкую форматную дисциплину (стабильный заголовок таблицы).
+  *Митигейшн:* формат человекочитаемый, документирован в D2; парсер — stdlib split.
+- **Откат:** удаление/правка трёх `docs/architecture/llm-*.md` + тест-файла + секции README. Рантайм
+  не затронут (риска нет).
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-118/01-brd.md` (§0 / §0-bis / BR-1…BR-9 / NFR-1…NFR-7)
+- TRZ: `docs/work-items/ORCH-118/02-trz.md` (FR-1…FR-8 / §2 таблица модулей)
+- Acceptance: `docs/work-items/ORCH-118/03-acceptance-criteria.md` (AC-1…AC-10)
+- Tech-risks: `docs/work-items/ORCH-118/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`
+- Сверено по коду: `src/agents/launcher.py` (`_spawn:472`, CLI `610-614`, `launch_job:377`,
+  перехват `389/394`, «Not an LLM spawn» `407/428`), `src/qg/checks.py`
+  (`33/62/82/336/182/226/599/538/473/413/657`), `.openclaw/agents/*.md` (6 промптов),
+  `src/{staging_verdict,self_deploy,frontmatter,...}.py` (детерминированные leaf'ы)
+- Прецедент детерминированной замены агента: ORCH-036 (self-deploy Phase A/B/C), D1/D2 `launch_job`
+- Прецедент docs+tests-only задач: ORCH-077/079/101/102/103/011
+</content>
+</invoke>

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

@@ -0,0 +1,43 @@
+---
+work_item: ORCH-118
+stage: architecture
+author_agent: architect
+status: accepted
+created_at: 2026-06-15
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-118 — replace avoidable LLM control paths (inventory + map + policy)
+
+Work Item: **ORCH-118** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный документ (гейтом не парсится). Перечисляет риски реализации **этой** задачи
+> (docs + tests only — inventory/карта/политика/тесты). Риски будущих раннеров замен — в roadmap'е и
+> в ADR соответствующих follow-up'ов, **не здесь**.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Тривиальный тест** — структурные тесты «зелёные, но ничего не проверяют» (рецидив корня R4: проверяют «один `Popen`» без control-path-оси) | Сред. | Выс. | D5: обязательные инварианты (g) control-path-разметка сверена с `src/qg/checks.py` и (h) avoidable-набор `{tester, deployer}`; (a)+(f) двусторонний транспорт-инвариант; ревью AC-6 буквально требует (g)/(h) |
+| TR-2 | **False-positive матчинга транспорта** — тест ловит `preflight.py`/`config.py` (bare `CLAUDE_BIN` — capability/литерал, не консультация) → ложный «второй транспорт» | Сред. | Сред. | D5a: матчинг по **конъюнкции** признаков (`CLAUDE_BIN` ∧ `--system-prompt` ∧ `Popen`/`bash -c`); allowlist = `_spawn`; явный негативный кейс на `preflight`/`config` |
+| TR-3 | **Дрейф карты-снимка** — `src/qg/checks.py` эволюционирует (смена потребителя / новая роль), карта не обновлена → ложно-зелёная витрина | Сред. | Сред. | Запланированное свойство: тесты D5g/h краснеют в точке дрейфа; норматив сопровождения «менял потребителя вердикта → обнови карту в том же PR» (ADR-001 D7 / adr-0047 D6) |
+| TR-4 | **Хрупкий парс машинного блока** — regex по прозе карты ломается на переформулировке без смыслового дрейфа | Низ. | Сред. | D2/D5: стабильный markdown-блок с фиксированным заголовком таблицы, парс stdlib-split; формат документирован |
+| TR-5 | **Непроверяемые ссылки / фабрикация follow-up ID** (рецидив дефекта R2) | Низ. | Выс. | NFR-6/AC-9: только резолвящиеся `file:line`/doc-ссылки; кандидаты — по роли; тест **не** пинит карту к follow-up ID; ревью AC-9 |
+| TR-6 | **Scope-creep в рантайм** — соблазн «заодно» тронуть `QG_CHECKS`/`check_*`/раннер | Низ. | Выс. | AC-7/D7: docs+tests only; диф не меняет `STAGE_TRANSITIONS`/реестр-имена `QG_CHECKS`/machine-verdict/схему БД; нет нового раннера tester/deployer; ревью буквально |
+| TR-7 | **Пере-/недо-классификация** (LLM убран где нужно суждение / сохранён где не нужен) | Низ. | Сред. | Класс **выводится** из осей D3 (двухбитный предикат), не «на глаз»; `keep-LLM` обязан назвать конкретное суждение; ревью карты против `src/qg/checks.py` |
+| TR-8 | **Рассинхрон golden-source** — карта/политика введены, README/overview/CHANGELOG не обновлены | Сред. | Сред. | AC-8 (ось ORCH-079/011 → finding ≥P1); README-секция добавлена на стадии architecture; development досинхронизирует overview/CHANGELOG в том же PR |
+| TR-9 | **Line-привязки `file:line` устаревают** между анализом и реализацией | Низ. | Низ. | Тест проверяет якоря по **имени** `def` (наличие в `src/qg/checks.py`), а не по номеру строки; номера в карте — справочные, обновляются разработчиком при материализации |
+
+## Сводный вывод
+
+Доминирующий класс — **риски качества тестов и анти-дрейфа** (TR-1/TR-2/TR-4), не рантайм-риски:
+задача физически не меняет поведение конвейера (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict/схема БД — байт-в-байт), не деплоит и не трогает прод (self-hosting безопасно, NFR-3),
+enduro-trails не затронут. Остаточный риск для прод-конвейера — **пренебрежимо мал**.
+
+Эскалация `arch:major-change` **не требуется** (нет новой стадии/компонента/смены БД — это
+docs+tests-only задача по прецеденту ORCH-077/079/101/102/103/011). Возврат в анализ **не требуется**:
+ТЗ удовлетворяется без нарушения принципов архитектуры. Ключевой управляемый риск — не дать тестам
+выродиться в тривиальные (TR-1) и не словить false-positive транспорта (TR-2); оба сняты дизайном D5.
+</content>

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

@@ -0,0 +1,123 @@
+---
+verdict: APPROVED
+work_item: ORCH-118
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-118
+version: 1
+---
+
+# Review ORCH-118 — карта LLM-консультаций, control-path-ось «avoidable», roadmap и политика
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter. `APPROVED` → дальше по конвейеру.
+
+## Summary
+
+ORCH-118 — зонтичная **inventory-first, docs + tests only** задача (RCA-трек ORCH-110…117): выпускает
+доказательную карту LLM-консультаций, нормативную политику использования LLM, упорядоченный roadmap
+детерминизации и набор структурных анти-дрейф тестов. Реализация раннеров — вне скоупа (FR-7).
+
+Работа выполнена на эталонном уровне: скоуп выдержан **байт-в-байт** (`src/**` не тронут вообще),
+каждый `file:line`-якорь карты резолвится в реальный код, все FR-1…FR-8 и AC-1…AC-10 закрыты, golden-source
+синхронизирован, полный прогон `pytest tests/ -q` — **зелёный (2081 passed)**. Один **P2** (косметика):
+в трёх docs-артефактах (оба ADR + 10-tech-risks) на EOF протекли служебные теги `</content>`/`</invoke>`
+из механизма записи файла. Это не ломает гейты/тесты/парсинг машинных блоков и не влияет на рантайм →
+не блокирует. Рекомендуется зачистить.
+
+Проверка проведена буквально по файлам: запущены оба новых тест-файла (13 passed), `test_system_docs.py`
+(29 passed) и полный `tests/` (2081 passed); сверены ключевые якоря `launcher.py` и `src/qg/checks.py`;
+подтверждено `git diff origin/main...HEAD -- src/` = **пусто**.
+
+> ⚠️ **Замечание по базе ревью.** Локальный `main` в worktree **устаревший** (`64ba121`, до мержей
+> ORCH-112/113/114/117). Истинная база ветки — `origin/main` (`13589fc`, мерж ORCH-117). Ревью
+> проводилось против `origin/main...HEAD` (реальный changeset ORCH-118 — 16 файлов, +2365), а НЕ против
+> stale `main...HEAD` (который ложно тянет чужие уже-смерженные `src/**`-правки ORCH-110…117).
+
+## Оси проверки
+
+### 1. Соответствие ТЗ (02-trz / 03-acceptance-criteria)
+- **FR-1 / AC-1 (инвентарь полон и привязан):** карта `llm-call-sites.md` перечисляет `S0`, `A1…A6`,
+  `D1/D2` со всеми обязательными полями (`location`/`trigger`/`stage`/`output`/`machine-verdict key`/
+  `output consumer`/`est. tokens`/`consults-LLM`/`axis`/`classification`/`rationale`). **Все якоря
+  резолвятся** — сверено: `launcher.py:472`=`def _spawn(`, `610-614`=сборка `--system-prompt "$(cat …)"`,
+  `838`=`_monitor_agent`, `389/394`=перехваты `deploy-finalizer`/`post-deploy-monitor`, `407/428`=«Not an
+  LLM spawn»; `checks.py:33/62/82/182/226/336/413/473/538/599/657` — все 11 точно совпали с целевыми
+  `def`. ✔
+- **FR-2 / AC-2 (таксономия 4 класса, выведена из оси):** классы определены, каждому site присвоен ровно
+  один (TC-04 тотальность), правило вывода `P→keep`, `C+!деривируем→keep`, `C+деривируем→replace/hybrid`
+  закреплено тестом (TC-04 axis-consistency). ✔
+- **FR-3 / AC-3 (детерминизм не-агентских путей):** §3 карты + TC-02 с file:line; дискриминатор —
+  «консультирует LLM», а не «спавнит subprocess». ✔
+- **FR-4 / AC-4 (roadmap + первый срез):** машинный блок roadmap с rank/deps/savings(источник `agent_runs`)/
+  risk/hybrid/followup_type/first_slice; ровно один `first_slice=yes`=deployer (TC-07). ✔
+- **FR-5 / AC-5 (политика):** `llm-usage-policy.md` нормативна, критерии keep/replace через ось,
+  определение «avoidable» как двухбитный предикат (TC-08). ✔
+- **FR-6 / AC-6 (структурные тесты):** TC-01…TC-14 покрывают единственный транспорт (a)+отсутствие иного
+  (f/TC-12), детерминированные пути (b), промпты↔файлы (c), тотальность (d), capability≠consultation (e),
+  control-path-разметку (g/TC-13), avoidable-набор (h/TC-14). Offline, stdlib-only, осмысленные. ✔
+- **FR-7 / AC-7 (скоуп-гард):** `git diff origin/main...HEAD -- src/` пусто; `STAGE_TRANSITIONS`/
+  `QG_CHECKS`/`check_*`/machine-verdict/схема БД — нетронуты (TC-09 фиксирует снимок); новых раннеров нет. ✔
+- **FR-8 / AC-10 (control-path-ось + «avoidable»):** ось C/P размечена по ролям с доказательством-потребителем,
+  термин определён, набор `{tester, deployer}` назван поимённо и отделён от `{reviewer}` (C-keep) и
+  `{analyst,architect,developer}` (P), сверено с `src/qg/checks.py` (TC-13/TC-14). ✔
+- **AC-9 (анти-фабрикация ID):** follow-up'ы названы по роли; все `ORCH-1XX`-ссылки резолвятся в реальные
+  work-item-папки (TC-11 зелёный; подтверждено наличие ORCH-110/111/112/113/114/117). ✔
+
+### 2. Соответствие ADR (06-adr / adr-0047 / глобальные ADR)
+- Деливерабл-доки **зеркалят** канонические таблицы ADR-001 D2/D4 без расхождений (поля инвентаря,
+  классы, потребители, avoidable-набор, первый срез=deployer-staging). ✔
+- D1 (3 durable-дока в `docs/architecture/`), D3 (3 оси + определение), D5 (offline-тесты, конъюнкция
+  признаков транспорта против false-positive на `preflight.py`/`config.py`), D6 (deployer первым), D7
+  (скоуп-гард) — реализованы верно. ✔
+- **Глобальные ADR не нарушены:** machine-verdict-ключи и реестр `QG_CHECKS` байт-в-байт (TC-09);
+  трассировка ORCH-078 — маркированные инварианты `src/**` не правились (src не тронут). ✔
+
+### 3. Качество кода (тестов)
+- Тесты содержательные, не тривиальные: парсят машинные блоки карты/roadmap/политики и сверяют с
+  ground-truth кода (`src/qg/checks.py`, `launcher.py`, `.openclaw/agents/`). `_function_body` устойчив к
+  дрейфу строк; TC-01 корректно требует **конъюнкцию** `CLAUDE_BIN`+`--system-prompt`+launcher (исключая
+  ложные срабатывания); TC-12 закрывает «второй транспорт». Без сети/LLM/subprocess-к-модели. ✔
+- **Регресс-тест-фиксатор (ORCH-019 BR-4) — N/A:** ORCH-118 — не багфикс-трек, а полный маршрут
+  design/inventory; обязательного теста-фиксатора дефекта не требуется. ✔
+- Security/утечки — N/A (рантайм не меняется). ✔
+
+### 4. Документация (golden-source — обязательная ось)
+- **AC-8 синхронизация:** `docs/architecture/README.md` (секция + ссылка adr-0047), витрина
+  `docs/overview/tech-quality-security.md` (раздел «Где уместен LLM» + ссылки на все 3 дока, ORCH-011),
+  `CHANGELOG.md` — обновлены в этом же PR. `test_system_docs.py` зелёный (29 passed). ✔
+- ADR заведён (work-item ADR-001 + сквозной adr-0047). ✔
+- Поскольку `src/**` не менялся, ось «изменён src → обнови доку» неприменима как P0; обзорные доки
+  (ORCH-079/011) обновлены. ✔
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- [ ] **Протёкшие служебные теги на EOF трёх docs-артефактов.** На конце файлов остались артефакты
+  механизма записи, не относящиеся к содержимому (контент перед ними полный):
+  - `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md:294-295`
+    → `</content>` + `</invoke>`
+  - `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md:114` → `</content>`
+  - `docs/work-items/ORCH-118/10-tech-risks.md:43` → `</content>`
+
+  Правило: «Документация = golden source» (CLAUDE.md §2) — durable-ADR не должен нести постороннюю
+  разметку. Не блокирует (тесты/гейты/машинные блоки карты не затронуты, рантайм-риска нет; три
+  новых dev-дока `llm-call-sites.md`/`llm-usage-policy.md`/`llm-determinization-roadmap.md` — **чистые**).
+  Рекомендация: удалить хвостовые строки с тегами в этом же PR.
+
+## Документация
+**Обновлена полностью и корректно.** В PR синхронизированы все golden-source точки: `docs/architecture/README.md`
+(+секция ORCH-118 и ссылка на adr-0047), витрина `docs/overview/tech-quality-security.md` (раздел про
+карту LLM + ссылки на 3 дока), `CHANGELOG.md`, оба ADR (work-item + сквозной adr-0047). Три новых durable-дока
+в `docs/architecture/` (`llm-call-sites.md`/`llm-determinization-roadmap.md`/`llm-usage-policy.md`) консистентны
+между собой и с ADR; машинные блоки прибиты тестами. Единственное замечание по документации — косметический
+P2 выше (хвостовые служебные теги в 2 ADR + tech-risks), не требующий отката.

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

@@ -0,0 +1,80 @@
+---
+result: PASS
+work_item: ORCH-118
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-118
+---
+
+# Test Report — ORCH-118
+
+> Машинный вердикт читается ТОЛЬКО из `result:` во frontmatter. `PASS` → задача переходит на `deploy-staging`.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-118-orch-replace-avoidable-llm-con` (ветка `feature/ORCH-118-orch-replace-avoidable-llm-con`)
+- Дата: 2026-06-16
+
+## Предусловия
+- Review-вердикт (`12-review.md`): **APPROVED** (verdict читается из frontmatter). ✔
+- Скоуп ORCH-118 — inventory-first, docs + tests only: `git diff origin/main...HEAD -- src/` пусто (рантайм не тронут).
+
+## Smoke API (read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✔
+- `GET /status` → активная задача ORCH-118 на стадии `testing` ✔
+- `GET /queue` → присутствует блок `serial_gate` (ORCH-088: `orchestrator.active_task = ORCH-118/testing`, не frozen) ✔; присутствует блок `auto_labels` ✔; breaker `closed`, preflight OK. Смок-регресса нет.
+
+## Результаты (покрытие 04-test-plan.yaml → 03-acceptance-criteria.md)
+
+| TC ID | Описание | AC | Результат |
+|-------|----------|----|-----------|
+| TC-01 | Единственный ТРАНСПОРТ LLM-консультации = `launcher._spawn` (CLAUDE_BIN + `--system-prompt` + Popen) | AC-1/AC-6a | PASS |
+| TC-02 | Детерминированные leaf-модули не консультируют LLM (дискриминатор «консультирует LLM», не «спавнит subprocess») | AC-3/AC-6b | PASS |
+| TC-03 | Анти-дрейф промптов: карта ↔ `.openclaw/agents/` (6 файлов, двусторонняя сверка) | AC-1/AC-6c | PASS |
+| TC-04 | Тотальность классификации (4 класса) + согласованность с осью C/P | AC-2/AC-6d | PASS |
+| TC-05 | keep-LLM требует названного суждения; C-keep (reviewer) фиксирует не-деривируемость | AC-2 | PASS |
+| TC-06 | Capability ≠ consultation: deploy-finalizer/post-deploy-monitor перехвачены до `_spawn` | AC-3/AC-6e | PASS |
+| TC-07 | Полнота roadmap + ровно один `first_slice=yes` (deployer) | AC-4 | PASS |
+| TC-08 | Политика LLM нормативна + определение «avoidable LLM control path» | AC-5/AC-10 | PASS |
+| TC-09 | Скоуп-гард: снимок ролей `STAGE_TRANSITIONS` и имён `QG_CHECKS` не изменился | AC-7 | PASS |
+| TC-10 | Полный регресс `pytest tests/ -q` зелёный | AC-6/AC-7 | PASS (2081 passed) |
+| TC-11 | Анти-фабрикация follow-up Plane-ID (кандидаты по роли) | AC-9 | PASS |
+| TC-12 | Отсутствие иного LLM-транспорта (нет anthropic/openai SDK, прямого HTTP, второго model-subprocess) | AC-1/AC-6f | PASS |
+| TC-13 | Control-path-ось C/P согласована с фактическим потребителем в `src/qg/checks.py` | AC-10/AC-6g | PASS |
+| TC-14 | Avoidable-набор зафиксирован = {tester, deployer}; reviewer=C-keep; analyst/architect/developer=P | AC-10/AC-6h | PASS |
+
+Все 14 TC выполнены и сопоставлены с критериями приёмки. Пропусков нет.
+
+## Вывод pytest
+
+Целевые тесты ORCH-118:
+```
+tests/test_llm_call_site_inventory.py::test_tc01_single_llm_transport PASSED
+tests/test_llm_call_site_inventory.py::test_tc12_no_alternative_llm_transport PASSED
+tests/test_llm_call_site_inventory.py::test_tc02_deterministic_modules_no_llm_consultation PASSED
+tests/test_llm_call_site_inventory.py::test_tc03_prompt_files_match_map PASSED
+tests/test_llm_call_site_inventory.py::test_tc04_classification_total_and_axis_consistent PASSED
+tests/test_llm_call_site_inventory.py::test_tc05_keep_llm_named_judgment PASSED
+tests/test_llm_call_site_inventory.py::test_tc06_capability_not_consultation PASSED
+tests/test_llm_call_site_inventory.py::test_tc09_runtime_contract_snapshot PASSED
+tests/test_llm_call_site_inventory.py::test_tc13_control_path_axis_correct PASSED
+tests/test_llm_call_site_inventory.py::test_tc14_avoidable_set_fixed PASSED
+tests/test_llm_determinization_docs.py::test_tc07_roadmap_completeness_and_first_slice PASSED
+tests/test_llm_determinization_docs.py::test_tc08_policy_normative_and_defines_avoidable PASSED
+tests/test_llm_determinization_docs.py::test_tc11_no_fabricated_followup_ids PASSED
+======================== 13 passed, 1 warning in 0.41s =========================
+```
+
+Полный регресс (TC-10):
+```
+2081 passed, 1 warning in 89.94s (0:01:29)
+```
+(Единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, предсуществующий, не связан с ORCH-118.)
+
+## Итог
+**PASS** — все 14 тест-кейсов зелёные, полный регресс `tests/` зелёный (2081 passed), smoke API (`/health`, `/status`, `/queue` с блоками `serial_gate` + `auto_labels`) — без регресса. Задача готова к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,29 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-118
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+timestamp: 2026-06-15T21:28:29Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance (port 8501),
+run canonically inside the container (`docker exec orchestrator-staging python3
+/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`).
+
+**Result: 8/10 checks PASS — exit code 0 → `staging_status: SUCCESS`.**
+
+All REAL pipeline checks are green (Block A SMOKE: A1/A2/A3; Block B ACCESS: B4/B5/B6
+registry isolation; Block C E2E: C7 create issue, C8 trigger pipeline). The only failures
+are the two known sandbox-infra checks (C9a/C9b), which are tolerated under ORCH-061 because
+SANDBOX bot accounts are not project members — they do not reflect a pipeline regression.
+
+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
+
+Cleanup ran in `finally`: Plane SANDBOX test issue deleted (HTTP 204); no branch to delete.

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

@@ -0,0 +1,201 @@
+---
+work_item: ORCH-123
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 01 — BRD / Bug-report: ORCH-123 — staging-runner assumes Docker CLI inside the orchestrator container and false-fails deploy-staging
+
+Work Item: **ORCH-123** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в full-cycle**
+
+> ⚠️ **`escalate: full-cycle` (ADR-001 D5 ORCH-019).** Метка задачи — `Bug`, но по сути это
+> **архитектурный + safety-critical (self-hosting)** дефект: требуется **решение о стратегии
+> исполнения** staging-сюиты из прод-окружения (host-side ssh / Docker SDK поверх смонтированного
+> сокета / docker CLI в образе / выделенный hook-режим), и любой вариант с доступом к
+> `docker.sock`/CLI из контейнера требует **явного security-review** (доступ к сокету = root-эквивалент
+> на хосте). Это не «однострочная» правка кода — нужен ADR. Поэтому выпускается **полный**
+> analysis-пакет (а не облегчённый bug-пакет). Оператор снимает багфикс-трек:
+> `POST /bug-fast-track/escalate?work_item=ORCH-123` → задача пойдёт через стадию `architecture`
+> (architect выпустит ADR для стратегии исполнения staging-runner).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### Симптом (наблюдаемое — установленный факт из прод-логов)
+Задача **ORCH-116** (поверх раската ORCH-115) дошла до стадии `deploy-staging` с **зелёными
+reviewer и tester**, но **детерминированный staging-runner упал ещё до запуска staging-сюиты**.
+Запись из прод-логов:
+```
+proc_group: spawn error for [docker, exec, orchestrator-staging, python3,
+/repos/orchestrator/scripts/staging_check.py, ...]: [Errno 2] No such file or directory: docker
+```
+Далее runner отработал свой инфра-DEFER **дважды**, исчерпал `staging_runner_infra_max_retries=2`,
+записал `15-staging-log.md` с `staging_status: FAILED` и `stage_engine` **откатил ORCH-116 на
+`development`** — как будто это дефект кода/тестов задачи, чем оно не является.
+
+### Причина симптома (установленный факт — верифицировано по коду и инфраструктуре)
+ORCH-115 (`src/staging_runner.py`) исполняет staging-сюиту командой
+`docker exec orchestrator-staging python3 .../staging_check.py …` **изнутри прод-контейнера
+`orchestrator`** через `proc_group.run_in_process_group`. Прод-контейнер **не содержит docker CLI**:
+- **`Dockerfile:11`** ставит `openssh-client git curl ca-certificates` — **бинаря `docker` нет**;
+  `python:3.12-slim` его тоже не содержит. Поэтому `subprocess.Popen(["docker", …])` падает
+  `FileNotFoundError: [Errno 2] No such file or directory: docker`.
+- **`docker-compose.yml:40`** монтирует `/var/run/docker.sock` (rw) в сервис `orchestrator` и
+  добавляет `group_add: ${ORCH_DOCKER_GID}`. То есть **сокет в контейнере есть, а CLI-бинаря, который
+  бы им воспользовался, — нет**. (Это важное уточнение корня: проблема не в доступе к Docker, а в
+  **отсутствии исполняемого клиента** в образе.)
+
+Цепочка отказа в коде:
+`build_staging_command()` (`staging_runner.py:154`) → `["docker","exec",…]` → `run_staging_suite()` →
+`proc_group.run_in_process_group` → `Popen` ⇒ `OSError` ⇒ `ProcResult(returncode=None, timed_out=False)`
+⇒ в `run_staging_gate` (`staging_runner.py:528`) `suite_ran = (returncode is not None) and (not
+timed_out)` = **False** ⇒ ветка **tool-error** ⇒ `_handle_tool_error` (`staging_runner.py:415`):
+инфра-DEFER ×2 → бюджет исчерпан → `write_staging_log(..., "FAILED", tool_error=True)` +
+`_advance(...)` ⇒ существующий откат `deploy-staging → development`.
+
+### Корневая классификационная ошибка
+Двухуровневый исход ORCH-115 (D5) различает только **«сюита исполнилась» vs «сюита не исполнилась
+(транзиентная инфра)»**. Отсутствие docker CLI — это **детерминированный, постоянный дефект
+окружения**, а не транзиентная икота: ретраи бессмысленны (каждая попытка падает идентично), а
+**терминальный исход — откат на `development` с расходом developer-retry** — вводит в заблуждение
+(винит код/разработчика задачи за environment-проблему раннера). Так до фикса **любая** self-hosting
+задача, доходящая до `deploy-staging`, обречена на ложный откат.
+
+### Локализация (анализ — куда смотреть архитектору/разработчику)
+
+**Установленный факт о топологии исполнения (CLAUDE.md / `docs/operations/INFRA.md` / код):**
+прод-деплой (ORCH-036, `src/self_deploy.py`) **уже решил ровно эту проблему** и НЕ запускает docker
+изнутри контейнера. Он исполняет хост-хук **на хосте** через `ssh + setsid` (detached):
+`build_deploy_command` (`self_deploy.py:220`) формирует `ssh <user>@<host> 'setsid bash -c "… bash
+<hook> --deploy …"'`, где `deploy_ssh_host=127.0.0.1`, ssh-ключ смонтирован, `openssh-client` стоит в
+образе (`Dockerfile:11`). Хост-хук `scripts/orchestrator-deploy-hook.sh` уже выполняет `docker
+compose …` / `docker tag` / **`docker exec "$STAGING_CONTAINER" python3 staging_check.py`**
+(`--build-staging`, строки 197/261) — **на хосте**, где docker CLI есть.
+
+**Вывод:** ORCH-115 при замене LLM-деплойера детерминированным раннером **отклонился** от уже
+установленного паттерна «docker-операции исполняются host-side, не внутри app-контейнера». Дефект —
+в **стратегии исполнения** `staging_runner` (где/как запускается staging-сюита), а не в гейте
+`check_staging_status` и не в контракте `15-staging-log.md`. Поэтому фикс должен **восстановить
+работоспособную стратегию исполнения** staging-сюиты в проде, не завися от недоступного внутри
+контейнера docker CLI, и **перестать классифицировать постоянный environment-дефект как код-фейл**.
+
+> 🔎 **Точка для проверки на стадии architecture (не факт, требует верификации):** как
+> staging-сюита исполнялась **до** ORCH-115 LLM-деплойером — действительно через `docker exec` из
+> контейнера (тогда путь всегда был сломан и LLM-гейт был «бумажным»), или иным механизмом. Это
+> определяет, «сломал ли ORCH-115 рабочий путь» или «сделал давний дефект детерминированным и
+> видимым». На фикс выбор стратегии это не меняет, но влияет на формулировку регресса.
+
+## 2. Объём (scope)
+
+### В объёме
+- Исправить **стратегию исполнения staging-runner** так, чтобы `deploy-staging` для self-hosting
+  `orchestrator` **проходил в проде**, не завися от недоступного внутри прод-контейнера docker CLI.
+- Гарантировать, что **tool-error / environment-дефект** (в частности отсутствие исполняемого
+  `docker`/невозможность запустить сюиту по причине окружения) **НЕ приводит к вводящему в
+  заблуждение откату `deploy-staging → development`** как код-фейлу и **не жжёт** developer-retry;
+  постоянный environment-дефект должен быть отличим от транзиентной инфры и от настоящего код-фейла.
+- Добавить **prod-like регресс/preflight**, который ловит «нет исполняемого/стратегия неработоспособна»
+  **до раската** (а не постфактум, ложным откатом реальной задачи).
+- Задокументировать **границу исполнения** (`docs/operations/INFRA.md` + `docs/architecture/README.md`):
+  где и как staging-сюита исполняется относительно прод-контейнера, какие исполняемые/сокеты доступны.
+
+### Вне объёма
+- ❌ Изменение гейта `check_staging_status` / `_parse_staging_status`, контракта `15-staging-log.md`
+  (`staging_status:`), `STAGE_TRANSITIONS`, machine-verdict ключей, схемы БД — **байт-в-байт прежние**
+  (ORCH-115 NFR-1: меняется **продюсер/стратегия исполнения** артефакта, не гейт).
+- ❌ Изменение содержимого/логики самой `scripts/staging_check.py` (тулинг сюиты корректен; меняется
+  лишь **как/откуда** её запускают).
+- ❌ Откат ORCH-115 (детерминизация staging корректна по замыслу; чиним способ исполнения).
+- ❌ Выбор конкретного механизма (ssh host-side / Docker SDK поверх сокета / docker CLI в образе /
+  выделенный hook-режим) — это **зона архитектора** (`06-adr/`), здесь — только требования и ограничения.
+- ❌ Изменение прод-деплой-пути (ORCH-036 self_deploy) сверх возможного переиспользования его
+  ssh-механизма; happy-path прод-деплоя не трогается.
+
+## 3. Заинтересованные стороны
+- **Заказчик/оператор (Слава)** — страдает от ложных откатов и ручного разруливания залипших задач;
+  принимает результат.
+- **Self-hosting конвейер `orchestrator`** — прямой потребитель: без фикса **ни одна** self-hosting
+  задача не проходит `deploy-staging`.
+- **Все проекты на общем инстансе (enduro-trails)** — косвенно: застрявшие/откатываемые self-hosting
+  задачи занимают слоты и внимание оператора на общей очереди.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Для self-hosting `orchestrator` стадия `deploy-staging` (детерминированный staging-runner)
+  **исполняет staging-сюиту и проходит в проде** без зависимости от docker CLI, отсутствующего внутри
+  прод-контейнера. Задача уровня ORCH-116 (reviewer/tester зелёные, код корректен) **доходит до
+  `deploy`**, а не откатывается.
+- **BR-2** — **Tool-error / environment-дефект ≠ код-фейл.** Невозможность исполнить сюиту по причине
+  окружения (нет исполняемого, недоступна стратегия) **не должна** завершаться откатом
+  `deploy-staging → development` как кодовой ошибкой и **не должна** инкрементировать developer-retry;
+  такой исход должен быть **отдельным, отличимым** (хольд/алерт оператору об инфра/environment-сбое).
+- **BR-3** — **Настоящий код-фейл сохраняется (анти-over-tolerance).** Если сюита **реально
+  исполнилась** и упала (exit≠0), поведение — **прежний** откат `deploy-staging → development` +
+  developer-retry (BR-2 не должно маскировать настоящие провалы; ср. ORCH-110 BR-6).
+- **BR-4** — **Prod-like preflight/регресс.** Должен существовать механизм, ловящий «исполняемое
+  отсутствует / стратегия неработоспособна» **до раската** (preflight на старте/в smoke-проверке) и
+  **тест**, воспроизводящий «docker CLI отсутствует в контейнере» (красный до фикса, зелёный после).
+- **BR-5** — **Граница исполнения задокументирована.** `docs/operations/INFRA.md` (и
+  `docs/architecture/README.md`) явно описывают, где/как исполняется staging-сюита относительно
+  прод-контейнера, какие исполняемые/сокеты доступны, и почему docker-операции идут так, а не «изнутри
+  app-контейнера».
+- **BR-6** — **Наблюдаемость.** Различие «environment/tool-error» vs «код-фейл» видно в логе
+  (структурная запись), Telegram-алерте (кликабельный номер) и read-only блоке `staging_runner` в
+  `GET /queue`.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (нулевая регрессия конвейера)** — `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / имена и
+  семантика `check_*` (в т.ч. `check_staging_status`/`_parse_staging_status`) / machine-verdict ключи
+  (`staging_status:`/`deploy_status:`/…) / схема БД — **байт-в-байт не тронуты** (фикс — стратегия
+  исполнения продюсера, не гейт и не стадия).
+- **NFR-2 (self-hosting safety)** — путь исполнения staging-runner **никогда**: не рестартит прод
+  `orchestrator` (8500), не делает `docker compose up orchestrator`/`--build` прода, не force-push, не
+  пишет в `main`, не редактирует `.env`. Только запускает staging-сюиту (8501) и пишет лог
+  (инвариант ORCH-115 BR-7/AC-8 сохраняется).
+- **NFR-3 (security — если выбран socket/CLI-в-контейнере)** — любой вариант с прямым использованием
+  `docker.sock`/CLI из контейнера = root-эквивалент на хосте → **обязателен явный security-review** в
+  ADR (поверхность атаки, ограничение прав, :ro где возможно). Вариант host-side ssh должен
+  переиспользовать уже существующий доверенный механизм (ORCH-036) без расширения привилегий.
+- **NFR-4 (обратимость / kill-switch)** — поведение под существующим `staging_runner_enabled`
+  (+ при необходимости — новым флагом выбора стратегии); выключенный kill-switch → прежний LLM-деплойер
+  через `_spawn` **байт-в-байт** (ORCH-115 fail-safe сохраняется).
+- **NFR-5 (надёжность)** — never-raise / fail-safe / restart-safe (по образцу leaf'ов
+  `staging_runner`/`self_deploy`/`proc_group`); очередь репо **никогда не клинится**; тайм-аут сюиты не
+  растёт сверх бюджета, держащего сквозной инвариант reaper (ORCH-065/109/110).
+- **NFR-6 (область)** — изменение скоупится на self-hosting (`orchestrator`, единственный с staging
+  8501); поведение для прочих репо/синхронного LLM-деплоя — не ухудшается (`applies(repo)` первым).
+
+## 6. Допущения и ограничения
+- Прод и staging контейнеры запущены на **одном хосте**; `/var/run/docker.sock` доступен на хосте,
+  где docker CLI установлен; ssh на `127.0.0.1` под смонтированным ключом — рабочий канал (его уже
+  использует ORCH-036 self-deploy).
+- `staging_check.py` исполняется **внутри контейнера `orchestrator-staging`** (там есть python3 и
+  приложение 8501) — это контракт сюиты; меняется только то, **кто инициирует** `docker exec` (хост
+  vs прод-контейнер) или **как** (CLI vs SDK поверх сокета).
+- Источник истины «применять ли детерминированный runner» — `staging_runner.applies(repo)` (ORCH-115);
+  фикс не меняет его семантику.
+- Конкретный механизм исполнения (host-side ssh / Docker SDK поверх сокета / docker CLI в образе /
+  выделенный режим хука) — **открытый вопрос для архитектуры**, решается в `06-adr/` с security-review.
+
+## 7. Критерии успеха
+Self-hosting задача уровня ORCH-116 проходит `deploy-staging` в проде (staging-сюита реально
+исполняется, вердикт маппится из exit-кода); environment/tool-error **не** даёт ложного код-фейл-отката
+и не жжёт developer-retry; настоящий код-фейл по-прежнему откатывает на `development`; существует
+prod-like preflight + обязательный регресс-тест «нет docker CLI в контейнере» (**красный до фикса,
+зелёный после**); граница исполнения задокументирована; гейт/контракт/`STAGE_TRANSITIONS`/схема БД — без
+регресса; полный `pytest tests/ -q` зелёный. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- **Security (socket/CLI в контейнере):** прямой доступ к `docker.sock` из app-контейнера = эскалация
+  до root на хосте → ADR обязан взвесить поверхность атаки против host-side ssh-варианта.
+- **Over-tolerance:** слишком широкая трактовка «environment-дефекта» может замаскировать настоящие
+  код-фейлы/реальные сбои staging-стенда (митигация — BR-3; ср. инцидент ORCH-110).
+- **Кросс-каттинг:** ORCH-115 (staging-runner, прямой объект), ORCH-036 (self_deploy ssh-механизм —
+  потенциально переиспользуемый), ORCH-110 (proc_group tree-kill + infra-tolerance паттерн), ORCH-058
+  (`--build-staging` host-side docker exec — прецедент), ORCH-101 (host-параметризация). Правки
+  маркированных блоков сверять с их `06-adr/` (CLAUDE.md §9). Детали/митигации — `10-tech-risks.md`
+  (заполняет архитектор).

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

@@ -0,0 +1,136 @@
+---
+work_item: ORCH-123
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 02 — ТЗ (TRZ): ORCH-123 — staging-runner execution strategy must not depend on Docker CLI inside the app container
+
+Work Item: **ORCH-123** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **требования и ограничения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное **решение** (какую стратегию исполнения выбрать: host-side ssh / Docker SDK поверх
+> сокета / docker CLI в образе / выделенный hook-режим, + security-review) — задача архитектора
+> (`06-adr/`), т.к. задача эскалирована в full-cycle (`01-brd.md` → `escalate: full-cycle`).
+
+## 1. Сводка изменения
+Восстановить работоспособную стратегию исполнения staging-сюиты для self-hosting `orchestrator` на
+стадии `deploy-staging`, не завися от docker CLI, **отсутствующего внутри прод-контейнера**
+(`Dockerfile:11` ставит `openssh-client git curl ca-certificates`, не docker; `docker.sock`
+смонтирован — `docker-compose.yml:40` — но клиента нет). Сегодня `staging_runner.build_staging_command`
+(`src/staging_runner.py:154`) формирует `["docker","exec","orchestrator-staging",…]` и запускает её
+**изнутри** прод-контейнера через `proc_group` → `Popen` падает `FileNotFoundError` → ветка tool-error
+→ инфра-DEFER×2 → fail-closed `FAILED` → откат `deploy-staging → development`. Требуется: (а) исполнять
+сюиту так, чтобы она реально запускалась в проде (паттерн host-side, уже применённый прод-деплоем
+ORCH-036 / `--build-staging`); (б) **различать** постоянный environment/tool-error от настоящего
+код-фейла и не делать вводящего в заблуждение код-фейл-отката; (в) prod-like preflight + регресс;
+(г) документировать границу исполнения.
+
+## 2. Задействованные модули / пути
+| Путь | Действие | Примечание |
+|------|----------|-----------|
+| `src/staging_runner.py` | **изменить** | `build_staging_command`/`run_staging_suite` — точка, где сюита запускается «изнутри контейнера» (корень дефекта, FR-1); классификация tool-error vs environment-дефект в `run_staging_gate`/`_handle_tool_error` (FR-2) |
+| `src/self_deploy.py` | возможно переиспользовать | `build_deploy_command`/`initiate_deploy` — рабочий host-side ssh+setsid механизм (ORCH-036); кандидат на общий ssh-хелпер исполнения host-side команды (решает архитектор) |
+| `scripts/orchestrator-deploy-hook.sh` | возможно изменить | `--build-staging` уже делает host-side `docker exec "$STAGING_CONTAINER" python3 staging_check.py` (строки 197/261) — прецедент/возможная точка выделенного staging-режима |
+| `Dockerfile` | возможно изменить | строка 11 — если выбран вариант «docker CLI в образе» (тогда + security-обоснование) |
+| `docker-compose.yml` | возможно изменить | строка 40 — `docker.sock` уже смонтирован; если выбран socket/SDK-вариант, зафиксировать права (`:ro` где возможно) |
+| `src/proc_group.py` | возможно изменить | `run_in_process_group` уже корректно деградирует spawn-error в `ProcResult(returncode=None)` — кандидат на preflight «исполняемое существует» (FR-4) |
+| `src/config.py` | возможно изменить | существующие `staging_runner_*`; при необходимости — флаг выбора/режима стратегии (FR-5), дефолт = боевое |
+| `docs/operations/INFRA.md` | **изменить** | граница исполнения staging-сюиты относительно прод-контейнера (FR-6 / BR-5) |
+| `docs/architecture/README.md` | **изменить** | описать стратегию исполнения staging-runner (FR-6 / BR-5) |
+| `CHANGELOG.md`, `CLAUDE.md` | изменить | docs = golden source (CLAUDE.md §2); раздел ORCH-115 дополнить фиксом исполнения |
+| `tests/test_orch115_staging_runner.py` / `tests/test_orch123_staging_runner_exec.py` | **создать/расширить** | регресс «docker CLI отсутствует» + классификация + preflight (`04-test-plan.yaml`) |
+
+## 3. Функциональные требования
+
+### FR-1 — Работоспособная стратегия исполнения staging-сюиты в проде (BR-1)
+- На стадии `deploy-staging` для self-hosting `orchestrator` staging-сюита (`staging_check.py` внутри
+  `orchestrator-staging`) **должна реально исполняться** в боевом окружении, **не завися** от наличия
+  бинаря `docker` внутри прод-контейнера `orchestrator`.
+- Стратегия исполнения — **выбор архитектора** (ADR), из перечня BRD §2: host-side через
+  существующий ssh+setsid механизм (ORCH-036, `deploy_ssh_host=127.0.0.1`, ssh-ключ смонтирован,
+  `openssh-client` в образе) **либо** Docker SDK/`docker.sock` (уже смонтирован, + security-review)
+  **либо** docker CLI в образе **либо** выделенный режим хука. ТЗ **не** прескриптивно — фиксирует
+  лишь требуемый инвариант «сюита исполняется».
+- Команда/контракт сюиты (`python3 staging_check.py --base-url http://localhost:<staging_port>
+  --mode stub`, host-specifics из config — ORCH-101) сохраняются; меняется **инициатор/канал**
+  запуска, не сама сюита.
+
+### FR-2 — Environment/tool-error ≠ код-фейл (BR-2, BR-3)
+- Невозможность исполнить сюиту по причине **окружения** (нет исполняемого `docker`/SDK недоступен/
+  стратегия неработоспособна) **не должна** завершаться откатом `deploy-staging → development` как
+  кодовой ошибкой и **не должна** инкрементировать developer-retry. Текущий терминальный путь
+  `_handle_tool_error` → `write_staging_log("FAILED") + _advance` (= откат) для **постоянного**
+  environment-дефекта вводит в заблуждение (см. BRD §1) и должен быть заменён на **отличимый
+  инфра/environment-исход** (хольд на `deploy-staging` + алерт оператору, по образцу
+  `merge_gate` infra-tolerance ORCH-110: задача остаётся на стадии, без developer-retry).
+- **Анти-over-tolerance (BR-3):** если сюита **реально исполнилась** (получен exit-код) и упала
+  (exit≠0), исход — **прежний** откат `deploy-staging → development` + developer-retry (контракт
+  `staging_runner` D5 для «сюита исполнилась» сохраняется байт-в-байт).
+- Различение «сюита исполнилась / постоянный environment-дефект / транзиентная инфра» —
+  детерминированная классификация (по образцу `merge_gate.classify_retest_failure`, ORCH-110 D2);
+  никаких догадок — постоянный environment-дефект (spawn-error «исполняемое не найдено») трактуется
+  как НЕ-транзиентный и НЕ как код-фейл.
+
+### FR-3 — Анти-бессмысленный-ретрай (BR-2)
+- При постоянном environment-дефекте бессмысленно крутить инфра-DEFER ×N (каждая попытка падает
+  идентично, жжёт время/слот) и затем ложно откатывать. Допустимо: немедленный отличимый
+  инфра-хольд+алерт (без отката, без developer-retry) **или** preflight, не дающий задаче войти в
+  ложный путь. Конкретику решает архитектор; инвариант — **не** оканчиваться код-фейл-откатом.
+
+### FR-4 — Prod-like preflight (BR-4)
+- Должен существовать механизм, ловящий «стратегия исполнения неработоспособна (нет исполняемого/
+  канал недоступен)» **до раската** — preflight на старте сервиса и/или в `scripts/staging_check.py`/
+  smoke (`scripts/staging_check.py` Block …) / в `should_intercept`/`applies`. Условие, проявившееся
+  в инциденте (нет бинаря `docker` там, где runner его зовёт), должно детектироваться **до** того,
+  как реальная задача ложно откатится.
+- Реализационно preflight никак не должен трогать гейты/стадии; never-raise; область — self-hosting.
+
+### FR-5 — Условность / kill-switch (BR-1, NFR-4, NFR-6)
+- Поведение под существующим `staging_runner_enabled` (выключен → прежний LLM-деплойер через `_spawn`
+  байт-в-байт) + `staging_runner_repos` (область). При необходимости нового флага выбора/режима
+  стратегии — env `ORCH_*`, **дефолт = боевое** (паттерн ORCH-101); откат = выставить флаг(и) →
+  поведение до ORCH-123. `applies(repo)` (локально, без сети) проверяется первым.
+
+### FR-6 — Документирование границы исполнения (BR-5)
+- `docs/operations/INFRA.md` + `docs/architecture/README.md`: явно зафиксировать, что docker-операции
+  для self-hosting исполняются **host-side** (а не из app-контейнера, где нет docker CLI), какие
+  исполняемые/сокеты доступны прод-контейнеру (`openssh-client`/`git`/`curl`; `docker.sock` смонтирован,
+  CLI — нет), и как именно staging-runner запускает сюиту после фикса.
+
+## 4. Изменения API
+**Нет** обязательных. Существующий read-only блок `staging_runner` в `GET /queue` (ORCH-115)
+**дополняется** различием environment/tool-error vs код-фейл и (опц.) статусом preflight; новых
+управляющих эндпоинтов не требуется (на усмотрение архитектора — опц. read-only preflight-поле).
+
+## 5. Изменения схемы БД
+**Нет.** Restart-safe состояние (счётчик инфра-ретраев) уже ведётся маркером в `task_content`
+(`_INFRA_RETRY_MARKER`, ORCH-115) — без миграции. Новой таблицы/колонки не требуется.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** Это **не** Quality Gate и **не** стадия — это стратегия исполнения продюсера артефакта
+`15-staging-log.md`. `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / имена и семантика `check_*`
+(`check_staging_status`/`_parse_staging_status`) / machine-verdict ключи (`staging_status:`/
+`deploy_status:`/…) / схема БД — **байт-в-байт не тронуты** (NFR-1; зеркало инварианта ORCH-115 NFR-1).
+
+## 7. Совместимость / регресс
+- **Обратная совместимость:** `staging_runner_enabled=False` → стадию `deploy-staging` снова ведёт
+  LLM-`deployer` через `_spawn` **байт-в-байт**; для прочих репо `applies==False` → no-op (нулевая
+  регрессия enduro).
+- **Контракт артефакта:** `15-staging-log.md` (`staging_status:` + 52c-схема, `author_agent:
+  staging-runner`/`model_used: n/a`) сохраняется; вердикт по-прежнему читается ТОЛЬКО из frontmatter.
+- **Self-hosting инварианты (NFR-2):** не рестартить прод 8500, не `docker compose up orchestrator`/
+  `--build` прода, не force-push, не писать в `main`, не править `.env` — сохраняются (ORCH-115 BR-7).
+- **Security (NFR-3):** любой socket/CLI-в-контейнере вариант проходит security-review в ADR; host-side
+  ssh-вариант переиспользует доверенный ORCH-036 механизм без расширения привилегий.
+- **Бюджеты/инварианты:** тайм-аут сюиты не растёт сверх `staging_runner_timeout_s` (держит сквозной
+  reaper-инвариант ORCH-065/109/110); proc_group tree-kill (ORCH-110) сохраняется.
+- **Артефакты pipeline:** обычные docs work item (`01..04` этой задачи; `06-adr/` на стадии
+  architecture после эскалации; `15-staging-log.md` при прогоне). Новых pipeline-артефактов задача не
+  вводит.
+- **Трассировка (CLAUDE.md §9 / ORCH-078):** правки маркированных блоков — ORCH-115 (staging-runner,
+  прямой объект), ORCH-036 (self_deploy ssh), ORCH-110 (proc_group/infra-tolerance), ORCH-058
+  (`--build-staging`) — сверять с их `06-adr/` перед изменением; инварианты не ломать.

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

@@ -0,0 +1,169 @@
+---
+work_item: ORCH-123
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-123 — staging-runner execution strategy fix
+
+Work Item: **ORCH-123** · Repo: **orchestrator** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
+считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория.
+Критерии **механизм-агностичны** (конкретную стратегию выбирает архитектор), проверяют **требуемый
+инвариант**, а не способ реализации.
+
+---
+
+## AC-1 — staging-сюита реально исполняется в проде (без docker CLI в контейнере)
+
+**Условие:** Для self-hosting `orchestrator` на `deploy-staging` staging-runner запускает
+`staging_check.py` так, что сюита **исполняется** в боевом окружении, не завися от бинаря `docker`
+внутри прод-контейнера.
+- **PASS:** Стратегия исполнения staging-сюиты не требует наличия `docker` CLI **внутри**
+  прод-контейнера `orchestrator` (исполняется host-side через существующий доверенный канал, либо
+  через смонтированный сокет/SDK с security-обоснованием, либо CLI добавлен в образ — на выбор ADR);
+  тест воспроизводит окружение «нет `docker` в контейнере» и подтверждает, что сюита **исполняется**
+  (а не падает spawn-error'ом).
+- **FAIL:** staging-runner по-прежнему вызывает `docker exec` напрямую из прод-контейнера без
+  доступного исполняемого/канала → `proc_group` spawn-error → tool-error.
+
+---
+
+## AC-2 — ORCH-116-подобная задача проходит `deploy-staging`
+
+**Условие:** Задача с зелёными reviewer/tester и корректным кодом доходит до `deploy`, а не
+откатывается на `development` из-за раннера.
+- **PASS:** При успешной staging-сюите (exit 0) → `staging_status: SUCCESS` → штатное продвижение по
+  под-гейтам ребра `deploy-staging → deploy` (контракт не тронут); ORCH-116-подобный сценарий в
+  тесте/симуляции достигает `deploy`.
+- **FAIL:** Корректная задача откатывается на `development` по причине раннера/окружения.
+
+---
+
+## AC-3 — environment/tool-error НЕ даёт вводящего в заблуждение код-фейл-отката
+
+**Условие:** Невозможность исполнить сюиту по причине окружения (нет исполняемого/канал недоступен) не
+трактуется как код-фейл.
+- **PASS:** environment/tool-error → **отличимый** инфра/environment-исход (задача **не** откатывается
+  на `development` как код-фейл; developer-retry **не** инкрементируется; оператору идёт алерт «инфра/
+  окружение, НЕ дефект кода»). Подтверждено тестом: при недоступном исполняемом задача **не** уходит в
+  `development` и счётчик developer-retry не растёт.
+- **FAIL:** environment-дефект завершается `write_staging_log("FAILED") + advance` (откат на
+  `development`) и/или жжёт developer-retry.
+
+---
+
+## AC-4 — настоящий код-фейл по-прежнему откатывает (анти-over-tolerance)
+
+**Условие:** Если сюита **реально исполнилась** и упала (exit≠0), поведение не ослаблено.
+- **PASS:** exit≠0 при исполнившейся сюите → `staging_status: FAILED` → **прежний** откат
+  `deploy-staging → development` + developer-retry (байт-в-байт контракт ORCH-115 для «сюита
+  исполнилась»). Тест подтверждает, что реальный фейл сюиты НЕ маскируется как «инфра».
+- **FAIL:** Настоящий код-фейл сюиты трактуется как environment/инфра и не откатывает на `development`.
+
+---
+
+## AC-5 — prod-like preflight ловит «исполняемое/стратегия неработоспособна» до раската
+
+**Условие:** Условие инцидента детектируется заранее, а не ложным откатом реальной задачи.
+- **PASS:** Существует preflight (на старте сервиса и/или в smoke/`staging_check.py`/`applies`/
+  `should_intercept`), который при неработоспособной стратегии исполнения сигнализирует (лог/алерт/
+  отметка) **до** того, как задача дойдёт до ложного отката; есть тест, симулирующий «нет `docker` в
+  контейнере», и он проверяет именно это.
+- **FAIL:** Нет механизма раннего детекта; «исполняемое отсутствует» обнаруживается только постфактум
+  откатом реальной задачи.
+
+---
+
+## AC-6 — обязательный регресс-тест (red → green)
+
+**Условие:** Инцидент ORCH-116 воспроизводится тестом.
+- **PASS:** Есть тест, моделирующий исполнение staging-сюиты в окружении **без `docker` CLI в
+  контейнере**; он **красный на коде до фикса** (воспроизводит spawn-error → tool-error → ложный
+  откат/false-FAILED) и **зелёный после фикса** (сюита исполняется / environment-дефект не даёт
+  код-фейл-отката).
+- **FAIL:** Регресс-теста нет, либо он зелёный и до фикса (значит, не воспроизводит дефект).
+
+---
+
+## AC-7 — гейт/контракт/стадии — без регресса (NFR-1)
+
+**Условие:** Меняется продюсер/стратегия исполнения, не гейт.
+- **PASS:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, имена и семантика `check_staging_status`/
+  `_parse_staging_status`, machine-verdict ключи (`staging_status:`/`deploy_status:`/…), схема БД —
+  **байт-в-байт прежние** (структурный анти-регресс-тест зелёный); `15-staging-log.md` сохраняет
+  `staging_status:`-frontmatter + 52c-схему (`author_agent: staging-runner`/`model_used: n/a`).
+- **FAIL:** Любое из перечисленного изменено (имя/регистр/семантика/значение) либо введена миграция БД.
+
+---
+
+## AC-8 — self-hosting safety (NFR-2)
+
+**Условие:** Путь исполнения staging-runner безопасен для общего прод-инстанса.
+- **PASS:** Путь **никогда** не рестартит прод `orchestrator` (8500), не делает `docker compose up
+  orchestrator`/`--build` прода, не force-push, не пишет в `main`, не правит `.env`; оперирует только
+  запуском staging-сюиты (8501) и записью лога (статический/поведенческий ассерт зелёный).
+- **FAIL:** Путь способен затронуть прод-контейнер/`main`/`.env`/сделать force-push.
+
+---
+
+## AC-9 — security-review для socket/CLI-вариантов (NFR-3)
+
+**Условие:** Если выбран вариант с прямым `docker.sock`/CLI из контейнера.
+- **PASS:** ADR (`06-adr/`) содержит явный security-разбор (поверхность атаки `docker.sock` =
+  root-эквивалент, ограничение прав, `:ro` где возможно) **либо** выбран host-side ssh-вариант,
+  переиспользующий доверенный ORCH-036 механизм без расширения привилегий — и это зафиксировано.
+- **FAIL:** Введён доступ к `docker.sock`/CLI из контейнера без security-обоснования в ADR.
+
+---
+
+## AC-10 — kill-switch / область (NFR-4, NFR-6)
+
+**Условие:** Обратимость и скоуп сохранены.
+- **PASS:** `staging_runner_enabled=False` → `deploy-staging` снова через LLM-`deployer` (`_spawn`)
+  байт-в-байт; `applies(repo)`: self-hosting `orchestrator` — real, прочие репо — no-op; любой новый
+  флаг стратегии имеет дефолт = боевое (откат флагом → поведение до ORCH-123). Подтверждено тестом.
+- **FAIL:** Выключение kill-switch не возвращает прежний путь, либо затронуты прочие репо.
+
+---
+
+## AC-11 — never-raise / очередь не клинится (NFR-5)
+
+**Условие:** Сбой стратегии исполнения не роняет worker и не клинит очередь.
+- **PASS:** Любая ошибка исполнения/классификации изолирована (never-raise); задача либо штатно
+  продвигается, либо остаётся на `deploy-staging` для reconciler/reaper без вечного залипания; полный
+  `pytest tests/ -q` зелёный.
+- **FAIL:** Ошибка исполнения роняет worker / задача залипает на `deploy-staging` навсегда / тесты
+  красные.
+
+---
+
+## AC-12 — документация границы исполнения (BR-5)
+
+**Условие:** Граница исполнения staging-сюиты задокументирована.
+- **PASS:** `docs/operations/INFRA.md` и `docs/architecture/README.md` содержат явное описание: где/как
+  исполняется staging-сюита относительно прод-контейнера, какие исполняемые/сокеты доступны, почему
+  docker-операции идут host-side (структурная сверка зелёная); `CHANGELOG.md`/`CLAUDE.md` обновлены.
+- **FAIL:** Граница исполнения нигде не описана, или docs противоречат фактическому коду.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-1 / FR-1 |
+| AC-3 | BR-2 / FR-2, FR-3 |
+| AC-4 | BR-3 / FR-2 |
+| AC-5 | BR-4 / FR-4 |
+| AC-6 | BR-4 / FR-1, FR-2 |
+| AC-7 | NFR-1 / FR-(6) |
+| AC-8 | NFR-2 |
+| AC-9 | NFR-3 |
+| AC-10 | NFR-4, NFR-6 / FR-5 |
+| AC-11 | NFR-5 |
+| AC-12 | BR-5 / FR-6 |

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

@@ -0,0 +1,108 @@
+work_item: ORCH-123
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+title: "Staging-runner execution strategy: docker CLI absent in container must not false-fail deploy-staging"
+framework: pytest
+scope: >
+  Покрывается: исполнение staging-сюиты для self-hosting orchestrator на deploy-staging без
+  зависимости от docker CLI внутри прод-контейнера; различение environment/tool-error vs настоящего
+  код-фейла; анти-over-tolerance (реальный фейл сюиты по-прежнему откатывает); prod-like preflight;
+  сохранность контракта гейта/артефакта/STAGE_TRANSITIONS/схемы БД; self-hosting safety; kill-switch/
+  область; never-raise. Вне покрытия: логика самой staging_check.py (не трогается), выбор конкретного
+  механизма исполнения (host-side ssh / docker.sock+SDK / CLI в образе / hook-режим — решает архитектор),
+  изменения STAGE_TRANSITIONS/QG_CHECKS/схемы БД (их нет).
+notes: >
+  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест воспроизведения инцидента ORCH-116/ORCH-115: КРАСНЫЙ до фикса,
+  ЗЕЛЁНЫЙ после. Тесты механизм-агностичны: проверяют ТРЕБУЕМЫЙ ИНВАРИАНТ (сюита исполняется;
+  environment-дефект не даёт код-фейл-отката; настоящий фейл откатывает), а не конкретную стратегию.
+  Окружение «нет docker CLI» моделировать без сети/прода/ssh (монки-патч PATH/spawn-функции
+  proc_group, либо изоляция argv staging_runner). Точные имена тест-функций уточнит разработчик после
+  выбора механизма архитектором. Полный регресс `pytest tests/ -q` обязан оставаться зелёным (NFR-1).
+
+tests:
+  - id: TC-01
+    type: integration
+    description: "РЕГРЕСС (обязательный, red→green): исполнение staging-сюиты в окружении БЕЗ docker CLI в прод-контейнере. До фикса воспроизводит proc_group spawn-error '[Errno 2] No such file or directory: docker' → tool-error → инфра-DEFER×2 → ложный FAILED-откат на development. После фикса сюита ИСПОЛНЯЕТСЯ (или environment-дефект не даёт код-фейл-отката). Красный до фикса."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Стратегия исполнения не зависит от docker CLI внутри прод-контейнера: argv/канал, формируемый staging-runner, не требует наличия бинаря `docker` на PATH контейнера (host-side / socket-SDK / CLI-в-образе — в зависимости от выбора ADR; ассерт проверяет инвариант, а не конкретный механизм)."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-03
+    type: integration
+    description: "environment/tool-error НЕ даёт код-фейл-отката (AC-3): при неработоспособной стратегии (исполняемое отсутствует) задача НЕ переходит deploy-staging → development, developer-retry НЕ инкрементируется, идёт отличимый инфра/environment-алерт ('НЕ дефект кода')."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Анти-over-tolerance (AC-4): сюита РЕАЛЬНО исполнилась (получен exit-код) и упала (exit≠0) → staging_status: FAILED → ПРЕЖНИЙ откат deploy-staging → development + developer-retry. Настоящий фейл сюиты НЕ маскируется как 'инфра'."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Happy-path: сюита исполнилась, exit 0 → staging_status: SUCCESS → штатная инициация advance_stage(deploy-staging, deployer) без новых рёбер/исходов (контракт ORCH-115 D7 сохранён)."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Классификация (по образцу merge_gate.classify_retest_failure): постоянный environment-дефект (spawn-error 'исполняемое не найдено') отличается от транзиентной инфры и от настоящего код-фейла; постоянный дефект НЕ трактуется как транзиент (бессмысленный ретрай) и НЕ как код-фейл."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "Prod-like preflight (AC-5): механизм раннего детекта 'стратегия исполнения неработоспособна (нет исполняемого/канал недоступен)' сигнализирует ДО ложного отката реальной задачи (старт сервиса / smoke / applies / should_intercept — в зависимости от выбора ADR)."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Self-hosting safety (AC-8): путь исполнения никогда не рестартит прод 8500, не делает docker compose up orchestrator/--build прода, не force-push, не пишет в main, не правит .env (статический/поведенческий ассерт; инвариант ORCH-115 BR-7 сохранён)."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Kill-switch/область (AC-10): staging_runner_enabled=False → should_intercept False → прежний LLM-deployer через _spawn байт-в-байт; applies(repo): self-hosting orchestrator real, прочие репо — no-op; новый флаг стратегии (если есть) имеет дефолт = боевое."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "Контракт артефакта (AC-7): 15-staging-log.md сохраняет staging_status:-frontmatter (UPPERCASE значение) + 52c-схему (author_agent: staging-runner / model_used: n/a); вердикт читается только из frontmatter через src/frontmatter.py."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Анти-регресс конвейера (AC-7): STAGE_TRANSITIONS / реестр QG_CHECKS / имена и семантика check_staging_status / _parse_staging_status / machine-verdict ключи (staging_status:/deploy_status:) — не изменены; миграции БД нет (структурная сверка)."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-12
+    type: unit
+    description: "never-raise / очередь не клинится (AC-11): любая ошибка исполнения/классификации изолирована, worker не падает, задача не залипает на deploy-staging навсегда; снапшот staging_runner в GET /queue различает environment/tool-error vs код-фейл."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-13
+    type: unit
+    description: "Документация-инвариант (AC-12): docs/operations/INFRA.md и docs/architecture/README.md содержат описание границы исполнения staging-сюиты (host-side vs in-container, доступные исполняемые/сокеты) — структурная сверка наличия раздела."
+    module: tests/test_orch123_staging_runner_exec.py
+    expected: PASS
+
+  - id: TC-14
+    type: unit
+    description: "Анти-дрейф ORCH-115: существующие структурные тесты staging-runner (tests/test_orch115_staging_runner.py) и LLM-determinization анти-дрейф остаются ЗЕЛЁНЫМИ после фикса (фикс не ломает инварианты ORCH-115)."
+    module: tests/test_orch115_staging_runner.py
+    expected: PASS

docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md

@@ -0,0 +1,333 @@
+---
+work_item: ORCH-123
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# ADR-001: Стратегия исполнения staging-раннера — host-side ssh + классификация environment-дефекта
+
+Work Item: **ORCH-123** — staging-runner (ORCH-115) исполняет `docker exec` **изнутри**
+прод-контейнера, где нет docker CLI → постоянный environment-дефект ложно маршрутизируется как
+код-фейл (откат `deploy-staging → development`). Стадия: **architecture** (задача-`Bug`,
+эскалирована `escalate: full-cycle` — `01-brd.md`, D5 ORCH-019).
+Сквозная регистрация: **`docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`**
+(решение кросс-каттинговое — кодифицирует инвариант «docker-операции исполняются host-side»,
+охватывающий ORCH-036/058/115/123/101, и амендит execution-strategy-решение adr-0048).
+
+## Статус
+Proposed
+
+## Контекст
+
+**Установленный факт (сверено по коду и инфраструктуре, BRD §1):** ORCH-115
+(`src/staging_runner.py:154`, `build_staging_command`) исполняет staging-сюиту командой
+`["docker", "exec", "orchestrator-staging", "python3", ".../staging_check.py", …]` **изнутри
+прод-контейнера `orchestrator`** через `proc_group.run_in_process_group` → `subprocess.Popen`.
+Прод-контейнер docker CLI **не содержит**:
+
+- `Dockerfile:11` ставит `openssh-client git curl ca-certificates` (+ pinned gitleaks) — бинаря
+  `docker` нет; `python:3.12-slim` его тоже не несёт → `Popen(["docker", …])` падает
+  `FileNotFoundError: [Errno 2] No such file or directory: docker`.
+- `docker-compose.yml:40` монтирует `/var/run/docker.sock` (rw) в сервис `orchestrator` и
+  добавляет `group_add 999` (ORCH-040 «МИНА 1»). **Сокет в контейнере есть, а CLI-клиента,
+  который бы им воспользовался, — нет.** Проблема не в доступе к Docker, а в **отсутствии
+  исполняемого клиента** в образе.
+
+Цепочка отказа в проде (job ORCH-116): `Popen` → `OSError` → `proc_group` деградирует в
+`ProcResult(returncode=None, timed_out=False)` → в `run_staging_gate` (`:528`)
+`suite_ran = (returncode is not None) and (not timed_out)` = **False** → ветка tool-error →
+`_handle_tool_error` (`:415`) → инфра-DEFER ×2 → бюджет исчерпан →
+`write_staging_log(..., "FAILED", tool_error=True)` + `_advance` → **существующий откат
+`deploy-staging → development`** (как код-фейл задачи). Так до фикса **любая** self-hosting задача,
+доходящая до `deploy-staging`, обречена на ложный откат.
+
+**Корневая классификационная ошибка (BRD §1):** двухуровневый исход ORCH-115 (D5) различает только
+«сюита исполнилась» vs «сюита не исполнилась (транзиентная инфра → DEFER → fail-closed FAILED)».
+Отсутствие docker CLI — **детерминированный, постоянный environment-дефект**, а не транзиентная
+икота: ретраи бессмысленны (каждая попытка падает идентично), а терминальный
+fail-closed-FAILED-откат винит код/разработчика за дефект окружения раннера.
+
+**Установленный паттерн, от которого ORCH-115 отклонился (сверено по коду):** прод-деплой ORCH-036
+(`src/self_deploy.py:220`, `build_deploy_command`) и image-freshness ORCH-058
+(`src/image_freshness.py`) **уже** исполняют все docker-операции **host-side** через
+`ssh + setsid`/`ssh` на `deploy_ssh_host=127.0.0.1` (ssh-ключ смонтирован, `openssh-client` в
+образе). `image_freshness.image_revision` (`:185`) прямо документирует инвариант:
+> *«`docker` lives on the HOST (the container ships only `openssh-client git`)»*
+и при `ssh_target` обёртывает `docker image inspect` в ssh. Хост-хук
+`scripts/orchestrator-deploy-hook.sh --build-staging` (`:197`) уже делает host-side
+`docker exec "$STAGING_CONTAINER" python3 staging_check.py` — на хосте, где docker CLI есть.
+
+**Вывод:** ORCH-115 при замене LLM-деплойера детерминированным раннером **отклонился** от уже
+установленного инварианта «docker-операции — host-side, не изнутри app-контейнера». Дефект — в
+**стратегии исполнения** раннера, **не** в гейте `check_staging_status` и **не** в контракте
+`15-staging-log.md` (BRD §«Вне объёма»; NFR-1).
+
+> 🔎 **Проверка точки BRD (как сюита исполнялась до ORCH-115 LLM-деплойером):** до ORCH-115
+> staging-сюиту исполнял LLM-агент `deployer` (`.openclaw/agents/deployer.md` шаг 1), которому
+> формулировка шага позволяла исполнить шаги на хосте/в нужном контексте; ORCH-115 жёстко зашил
+> `docker exec` именно **изнутри** прод-контейнера через `proc_group`. То есть ORCH-115 сделал
+> ранее-гибкий путь жёстко-неработоспособным в проде. На выбор стратегии фикса это не влияет
+> (host-side восстанавливает рабочий инвариант независимо от истории).
+
+## Решение
+
+Восстановить **host-side стратегию исполнения** staging-сюиты через уже доверенный ssh-канал
+(ORCH-036/058) и ввести **трёхстороннюю классификацию исхода**, чтобы постоянный
+environment-дефект и транзиентная инфра **никогда** не оканчивались код-фейл-откатом, а только
+реально исполнившаяся упавшая сюита — откатывала (анти-over-tolerance). Гейт / контракт артефакта /
+`STAGE_TRANSITIONS` / схема БД — **байт-в-байт неизменны** (замена *стратегии исполнения продюсера*,
+не гейта). Аддитивно, под флагами, never-raise, скоуп self-hosting.
+
+### D1 — Стратегия исполнения: host-side ssh, обёртывающий `docker exec` (BR-1 / FR-1 / AC-1, AC-2)
+
+`staging_runner.build_staging_command()` теперь строит **ssh-обёрнутую** команду (зеркало
+`self_deploy.build_deploy_command` / `image_freshness.image_revision(ssh_target=…)`):
+
+```
+ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> \
+    'docker exec <STAGING_SERVICE> python3 <repos_dir>/<SELF_HOSTING_REPO>/scripts/staging_check.py \
+       --base-url http://localhost:<staging_port> --mode stub'
+```
+
+- Внутренняя команда (`docker exec … staging_check.py … --mode stub`) — **та же**, что прежде
+  (контракт сюиты и exit-кода не меняется, BRD §«Вне объёма»); собирается из config (ORCH-101, без
+  host-хардкодов), `shlex.quote`-ится в inner-строку ssh.
+- Канал — существующий: `deploy_ssh_user`/`deploy_ssh_host` (compose:
+  `ORCH_DEPLOY_SSH_HOST=127.0.0.1`, `ORCH_DEPLOY_SSH_USER=slin`); ssh-ключ смонтирован
+  (`${ORCH_HOST_SSH_DIR}:…/.ssh:ro`), `openssh-client` в образе (`Dockerfile:11`). **Новых
+  секретов/привилегий не вводится** (NFR-3).
+- Запуск по-прежнему через `proc_group.run_in_process_group` (bounded local timeout + tree-kill
+  локального ssh-клиента, ORCH-110). **Ограничение (документируется, D-Последствия):** tree-kill
+  убивает локальный ssh-клиент, но не гарантирует убийство удалённого `docker exec`-дерева на
+  хосте; backstop — bounded таймаут самой `staging_check.py` внутри сюиты. Это **то же** допущение,
+  что у уже принятого `image_freshness.rebuild_staging_image` (синхронный ssh без remote tree-kill).
+- **Self-hosting safety (NFR-2 / AC-8):** argv содержит **только** `docker exec <staging-service>
+  python3 staging_check.py … --mode stub` — **никаких** литералов рестарта прод-8500,
+  `docker compose up orchestrator`/`--build` прода, force-push, записи в `main`, правки `.env`.
+  Структурный анти-литерал-тест (ORCH-115 TC-12, расширяется TC-08 ORCH-123) держит инвариант на
+  ssh-обёрнутой команде.
+
+### D2 — Почему host-side ssh, а НЕ socket/CLI-в-контейнере — security-review (NFR-3 / AC-9) — **ключевое решение безопасности**
+
+BRD/TRZ перечисляют четыре кандидата (host-side ssh / Docker SDK поверх `docker.sock` / docker CLI
+в образе / выделенный hook-режим). Любой вариант с **прямым использованием `docker.sock`/CLI
+изнутри контейнера** = **root-эквивалент на хосте** и требует явного security-обоснования.
+
+**Разбор поверхности атаки:**
+- `/var/run/docker.sock` смонтирован rw + `group_add 999` **уже** (ORCH-040, «МИНА 1»). Это
+  **дремлющая** возможность: контейнер может *достучаться* до сокета, но **не имеет клиента**, чтобы
+  им воспользоваться. Добавление docker CLI в образ **или** Docker SDK (`pip install docker`)
+  превратило бы дремлющую возможность в **активный root-эквивалентный путь исполнения**, доступный
+  не только worker-коду, но и **любому subprocess'у в том же контейнере — включая LLM-агентов**,
+  которых оркестратор спавнит (`launcher._spawn`). Это **расширение поверхности атаки** (компрометация
+  агента/зависимости → полный контроль docker → root на хосте, обслуживающем ВСЕ проекты).
+- Host-side ssh держит docker-операции **на хосте** под **существующим** доверенным key-gated
+  каналом (ORCH-036/058), **не наделяя** in-container код docker-возможностями. Это **строго
+  безопаснее** и согласуется с задокументированным инвариантом `image_freshness`.
+
+**Решение:** выбран **host-side ssh** (D1). Docker CLI/SDK в контейнер **не добавляется**;
+использование `docker.sock` **не расширяется**. ORCH-123 поверхность ORCH-040 (смонтированный сокет)
+**не трогает и не расширяет** (правка compose вне объёма — BRD §«Вне объёма», happy-path
+прод-деплоя/ORCH-040 не трогаем). Если будущая задача потребует socket/CLI-в-контейнере — это
+**отдельный** явный security-review; этот ADR его не выдаёт (AC-9 удовлетворён выбором ssh-варианта,
+переиспользующего доверенный ORCH-036 механизм без расширения привилегий).
+
+### D3 — Трёхсторонняя классификация исхода (FR-2 / FR-3 / AC-3, AC-4, AC-6) — **ключевое решение**
+
+Чистая функция `classify_staging_outcome(result, ssh_configured) -> str` (зеркало
+`merge_gate.classify_retest_failure`, ORCH-110 D2; pure, never-raise) различает **три** класса:
+
+| Класс | Детерминированный сигнал | Семантика |
+|-------|--------------------------|-----------|
+| `permanent-env` | `returncode is None and not timed_out` (spawn-error локального бинаря) **ИЛИ** ssh-target не сконфигурирован **ИЛИ** `returncode in (126, 127)` **ИЛИ** stderr содержит маркеры `command not found` / `executable file not found` / `No such container` / `is not running` / `Cannot connect to the Docker daemon` / `Is the docker daemon running` | Постоянный дефект окружения (нет docker/ssh, контейнер не поднят, демон недоступен). Ретрай бессмыслен. |
+| `transient-infra` | `timed_out` **ИЛИ** `returncode == 255` (ssh transport/connection) | Транзиентная инфра (сеть/handshake/стенд на миг недоступен). Ретрай осмыслен. |
+| `suite-ran` | распознанный исполнительный exit-код (любой иной int) **и НЕТ** env-маркера в stderr | Сюита **реально исполнилась** — доверяем коду (`0→SUCCESS`, `≠0→FAILED`). |
+
+- **Дизамбигуация «сюита exit=1 vs `docker exec` No such container exit=1»** — по **скану stderr на
+  env-маркеры** (а не по голому exit-коду): env-маркер → `permanent-env`; нет маркера → `suite-ran`
+  (`staging_check.py` пишет PASS/FAIL в stdout, её коды — 0/≠0 без 126/127/255). Маркер-сет
+  финализирует разработчик; набор выше — стартовый, по образцу scope-guard `merge_gate`.
+- **Анти-over-tolerance (BR-3 / AC-4, зеркало ORCH-110 BR-6):** распознанный `suite-ran` exit-код
+  **никогда** не реклассифицируется в инфру → реальный фейл сюиты (`exit≠0`) идёт прежним путём.
+- **Fail-safe при неоднозначности:** неизвестный сигнал по умолчанию → `transient-infra` (DEFER), а
+  **не** `suite-ran` — mis-route environment→код-фейл есть именно тот дефект, что чиним; но
+  распознанный suite-exit без env-маркера всегда `suite-ran` (BR-3 не ослаблен).
+
+### D4 — Маршрутизация исходов (BR-2 / BR-3 / FR-2 / FR-3 / AC-3, AC-4) — **инвариант: инфра ≠ код-фейл**
+
+| Класс | Действие |
+|-------|----------|
+| `suite-ran` | **Без изменений** (ORCH-115): `write_staging_log` + `_advance` → `SUCCESS`→под-гейты+Phase A; `FAILED`→**прежний** откат `deploy-staging → development` + developer-retry (`stage_engine.py:932`). BR-3 байт-в-байт. |
+| `permanent-env` | **Немедленный отличимый infra-исход:** DEFER-цикл **пропускается** (ретрай постоянного дефекта бессмыслен — FR-3); записывается структурный `permanent-env`-лог + операторский алерт («инфра/окружение, **НЕ дефект кода**», кликабельный номер); **НЕ** `_advance`, **НЕ** откат, **НЕ** developer-retry. Задача **остаётся на `deploy-staging`** (infra-HOLD). Счётчик `permanent_env`++. |
+| `transient-infra` | **Существующий** bounded DEFER (re-queue `deployer`-джоба + delay + restart-safe маркер `_INFRA_RETRY_MARKER`, cap `staging_runner_infra_max_retries`). |
+
+**Изменение терминала исчерпания DEFER (супершид ORCH-115 ADR D5):** при исчерпании бюджета DEFER
+исход — **infra-HOLD + алерт** (как `permanent-env`), а **НЕ** прежний fail-closed
+`write_staging_log("FAILED") + _advance` (= откат). Прежний терминал нарушал BR-2 (транзиентная инфра,
+которая не прояснилась, всё равно ложно откатывалась как код-фейл). Новый терминал выравнивает
+staging-раннер с моделью `merge_gate` infra-tolerance (ORCH-110 D3: исчерпание инфра → алерт «НЕ
+дефект кода», задача **не** уходит в `development`).
+
+**Корневой инвариант (нормативно):** «сюита **не исполнилась**» (environment ИЛИ транзиентная инфра)
+**никогда** не оканчивается код-фейл-откатом `deploy-staging → development` и **никогда** не жжёт
+developer-retry. Откат — **только** для реально исполнившейся сюиты с `exit≠0` (`suite-ran`/`FAILED`).
+Это закрывает RCA-класс ORCH-110/111…117 на staging-ребре.
+
+**Re-drive / отсутствие вечного залипания (NFR-5 / AC-11):** infra-HOLD оставляет задачу на
+`deploy-staging` в восстановимом состоянии (worker не падает, тугого ретрай-цикла нет, исход виден в
+алерте + `GET /queue` + структурном логе). После починки окружения оператором задача переоткатывается
+**существующим** механизмом (оператор / reconciler ORCH-053), без нового движка. **Граница (риск
+R-2):** reconciler/reaper **должен** трактовать infra-held `deploy-staging`-задачу как удержанную
+(пере-выдать `deployer`-джоб), **не** откатывать её в `development` — иначе реинтродукция дефекта;
+developer верифицирует (`10-tech-risks.md`).
+
+### D5 — Prod-like preflight (BR-4 / FR-4 / AC-5)
+
+`staging_runner.preflight() -> tuple[bool, str]` (bounded, never-raise, self-hosting-скоуп —
+`applies(repo)` первым):
+- Пробит **канал исполнения** host-side коротким bounded ssh-зондом:
+  `ssh <target> 'command -v docker >/dev/null && docker inspect -f "{{.State.Running}}"
+  <STAGING_SERVICE>'` → распознаёт «нет docker на хосте» / «staging-контейнер не поднят» / «ssh
+  недоступен» **до** того, как реальная задача дойдёт до ложного исхода.
+- Вызывается на **старте сервиса** в `main.lifespan` (best-effort, после
+  `requeue_running_jobs`/`recover_on_startup`, **никогда не блокирует старт**) → условие инцидента
+  всплывает на рестарте/деплое самого орка, а не постфактум на реальной задаче. Эмитит структурный
+  лог + Telegram-алерт при неудаче + поле в `snapshot()`.
+- **Чисто наблюдательный:** preflight **не** гейтит/блокирует конвейер, **не** трогает стадии/QG,
+  never-raise (FR-4). Регресс-тест TC-01 моделирует «нет docker CLI в контейнере» (монки-патч
+  argv/spawn) — **красный до фикса** (in-container `docker exec` → spawn-error → tool-error → ложный
+  откат), **зелёный после** (host-side стратегия + `permanent-env`-классификация → нет код-фейл-отката).
+
+### D6 — Условность / kill-switch / обратимость (FR-5 / NFR-4 / NFR-6 / AC-10)
+
+`config.py` (паттерн `staging_runner_*` / ORCH-101 «дефолт = боевое»):
+- **Новый:** `staging_runner_exec_host_side: bool = True` (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`).
+  `True` (дефолт) → host-side ssh-стратегия (D1, фикс). `False` → прежний in-container `docker exec`
+  (валиден **только** там, где docker CLI запечён в образ; в текущем проде — нет). Добавить в
+  `.env.example`.
+- **Переиспользуются:** `staging_runner_enabled` (kill-switch; `False` → прежний LLM-`deployer` через
+  `_spawn` **байт-в-байт**, ORCH-115 fail-safe), `staging_runner_repos` (CSV; пусто → self-hosting
+  only через `is_self_hosting_repo`), `staging_runner_timeout_s`, `staging_runner_infra_max_retries`/
+  `_retry_delay_s` (DEFER-бюджет транзиентной инфры), `deploy_ssh_user`/`deploy_ssh_host`/
+  `deploy_host_repo_path` (ssh-канал).
+- `applies(repo)` (локально, без сети) — **первым** в `should_intercept`: выключенный флаг = нулевой
+  оверхед, на `deploy-staging` штатно `_spawn`. **Откат:** `ORCH_STAGING_RUNNER_ENABLED=false`
+  (→ LLM-путь) **или** `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (→ прежний in-container call).
+  Для прочих репо `applies==False` → no-op (нулевая регрессия enduro). NFR-6.
+
+### D7 — Сохранность контракта (NFR-1 / AC-7) — границы O1
+
+**Байт-в-байт неизменны:** `STAGE_TRANSITIONS` (`src/stages.py`), реестр и имена `QG_CHECKS`/
+`check_staging_status`/`_parse_staging_status`, machine-verdict-ключи (`staging_status:`/
+`deploy_status:`/…), **схема БД** (restart-safe счётчик DEFER — маркер в `task_content`, без
+миграции). `15-staging-log.md` сохраняет `staging_status:`-frontmatter (UPPERCASE) + 52c-схему
+(`author_agent: staging-runner` / `model_used: n/a`); вердикт читается ТОЛЬКО из frontmatter через
+`src/frontmatter.py`. Это замена *стратегии исполнения продюсера*, не гейта/стадии (зеркало
+инварианта ORCH-115 NFR-1). transition-lease ORCH-114 берётся **внутри** `advance_stage` — раннер
+его не трогает (граница O1, как ORCH-115 D7).
+
+### D8 — Наблюдаемость (BR-6 / AC-12-набл.)
+
+`_STAGING_RUNNER_COUNTERS` расширяется ключом `permanent_env` (+ существующие
+`runs`/`success`/`failed`/`tool_error`/`deferred`). `snapshot()` / read-only блок `staging_runner` в
+`GET /queue` различает **три** не-успешных класса: `code-fail` (исполнившаяся сюита `FAILED`) vs
+`transient-infra` (`deferred`) vs `permanent-env` (новый). Один структурный лог-вердикт на прогон
+(`work_item`/`repo`/`exit_code`/`status`/`duration_s`/`outcome` ∈ {`code-pass`,`code-fail`,
+`transient-infra`,`permanent-env`}) + Telegram-алерт на `permanent-env`/infra-исчерпание с
+кликабельным номером и явной формулировкой «инфра/окружение, НЕ дефект кода».
+
+### D9 — Норматив сопровождения docs (BR-5 / FR-6 / AC-12) — спека для development
+
+Документация границы исполнения и витрина **коуплены к состоянию кода** (описывают post-fix
+поведение; структурный анти-дрейф TC-13 проверяет наличие разделов). По прецеденту **ORCH-115 D11 /
+adr-0048** (и маршрутизации analyst'а — `02-trz.md` §2) эти правки применяет **developer атомарно с
+кодом** в том же PR, **не** architecture-стадия (иначе доки/тесты описывают не-существующий ещё код).
+Точная спека (developer применяет дословно):
+
+- **`docs/operations/INFRA.md`** — в раздел `## ⚠️ Self-hosting` (или новый под-раздел «Граница
+  исполнения docker-операций») зафиксировать: контейнер `orchestrator` несёт **только**
+  `openssh-client git curl` (docker CLI **нет**); `/var/run/docker.sock` смонтирован, но **не
+  используется изнутри** (нет клиента, сознательно — см. D2); **все** docker-операции
+  (прод-деплой ORCH-036, image-freshness ORCH-058, **staging-runner ORCH-123**) исполняются
+  **host-side** через ssh на `127.0.0.1` под смонтированным ключом; staging-сюита (`staging_check.py`)
+  по-прежнему исполняется **внутри** `orchestrator-staging` (8501) — меняется лишь **кто инициирует**
+  `docker exec` (host vs прод-контейнер).
+- **`docs/architecture/README.md`** — в секции про staging-гейт/ORCH-115 (или соседней) описать
+  host-side стратегию исполнения staging-раннера и трёхстороннюю классификацию (env ≠ код-фейл),
+  сослаться на `adr-0049`.
+- **`CLAUDE.md`** — раздел ORCH-115 дополнить фиксом ORCH-123 (host-side exec + классификация
+  environment-дефекта); **`CHANGELOG.md`** — запись `fix:`; **`docs/overview/`** — если затронут
+  машинно-проверяемый факт (`tests/test_system_docs.py`).
+- **Анти-дрейф ORCH-115 (TC-14):** существующие `tests/test_orch115_staging_runner.py` и
+  LLM-determinization-тесты остаются зелёными (фикс не ломает инварианты ORCH-115: контракт/гейт/
+  один транспорт LLM `_spawn`/«ровно один first_slice» целы).
+
+## Альтернативы
+
+- **Docker CLI в образ (`Dockerfile`) + `docker exec` через смонтированный сокет** — отвергнуто
+  (D2): активирует дремлющий root-эквивалентный путь для всего, что исполняется в контейнере (вкл.
+  LLM-агентов) — расширение поверхности атаки. Требовало бы отдельного security-review; host-side ssh
+  достигает цели без расширения привилегий.
+- **Docker SDK (`pip install docker`) поверх `docker.sock`** — отвергнуто: та же security-проблема,
+  что выше, + новая зависимость + не переиспользует доказанный канал.
+- **Выделенный режим хука (`--run-staging-check`) через ssh** — отвергнуто как избыточное: прецедент
+  `image_freshness.image_revision(ssh_target=…)` уже исполняет docker-команду через **прямой** ssh
+  (без хука); `--build-staging` хука перегружен ребилдом образа (это работа ORCH-058, не раннера) —
+  переиспользовать его нельзя, а заводить новый hook-режим тяжелее прямого ssh-wrap. Прямой
+  ssh-обёртки (D1) достаточно.
+- **tool-error → немедленный `FAILED`-откат на `development`** (исходный путь до ORCH-115 D5) —
+  отвергнуто: это в точности дефект ORCH-123 (и анти-паттерн ORCH-110).
+- **Сохранить ORCH-115 D5 терминал (исчерпание DEFER → fail-closed `FAILED` + `_advance`)** —
+  отвергнуто: нарушает BR-2 (транзиентная инфра, не прояснившаяся за N попыток, всё равно ложно
+  откатывается как код-фейл). Заменён на infra-HOLD + алерт (D4), как ORCH-110 D3.
+- **Двухсторонняя классификация (как ORCH-115)** — отвергнуто: не отличает постоянный
+  environment-дефект (ретрай бессмыслен, нужен немедленный HOLD) от транзиентной инфры (ретрай
+  осмыслен). Трёхсторонняя (D3) различает (FR-3).
+
+## Последствия
+
+- **+** На `deploy-staging` для `orchestrator` staging-сюита **реально исполняется в проде**
+  (host-side через доверенный ssh-канал); задача уровня ORCH-116 доходит до `deploy`, а не
+  откатывается (BR-1 / AC-2).
+- **+** **Инфра/environment ≠ код-фейл** на staging-ребре: ни environment-дефект, ни транзиентная
+  инфра не дают ложного отката `→ development` и не жгут developer-retry (BR-2). Закрыт RCA-класс
+  ORCH-110 на staging-ребре полностью (не только частично, как ORCH-115 D5).
+- **+** Анти-over-tolerance цел: реально исполнившаяся упавшая сюита по-прежнему откатывает (BR-3).
+- **+** Переиспользует существующий доверенный ssh-канал (ORCH-036/058) — **без** расширения
+  привилегий, **без** docker CLI/SDK в контейнере (NFR-3); согласовано с задокументированным
+  инвариантом `image_freshness`.
+- **+** Полная обратимость двумя флагами (`staging_runner_enabled` → LLM;
+  `staging_runner_exec_host_side` → in-container); контракт/гейт/ребро/схема БД неизменны.
+- **−** Remote tree-kill ограничен локальным ssh-клиентом (удалённое `docker exec`-дерево не
+  гарантированно убивается tree-kill'ом) — **то же** допущение, что у принятого
+  `image_freshness.rebuild_staging_image`; backstop — bounded таймаут внутри `staging_check.py`.
+- **−** Permanent-env / исчерпавшая-DEFER задача **держится** на `deploy-staging` до починки
+  окружения оператором → блокирует serial-gate репо (ORCH-088) для **более поздних** задач.
+  Принятый tradeoff (зеркало ORCH-110 infra-HOLD): environment-проблема, требующая оператора,
+  **должна** остановить репо, а не молча ложно-откатывать; скоуп self-hosting only.
+- **−** Классификация по stderr-маркерам имеет остаточную неоднозначность. Митигейшн: fail-safe
+  default → `transient-infra` (не `suite-ran`); распознанный suite-exit без env-маркера всегда
+  доверяется (BR-3); набор маркеров — по образцу `merge_gate` scope-guard, под покрытием TC-06.
+- **Откат:** `ORCH_STAGING_RUNNER_ENABLED=false` → прежний LLM-`deployer` на `deploy-staging`
+  байт-в-байт; либо `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` → прежний in-container `docker exec`.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-123/01-brd.md`; ТЗ: `02-trz.md`; Acceptance: `03-acceptance-criteria.md`;
+  Test-plan: `04-test-plan.yaml`
+- Инфра: `docs/work-items/ORCH-123/07-infra-requirements.md`; Риски: `10-tech-risks.md`
+  (данные — `08` N/A: схема БД не меняется, TRZ §5)
+- Сквозной ADR: `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`
+- Амендит / опирается на: ORCH-115 (`docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`,
+  `adr-0048`) — стратегия исполнения D3 и терминал D5; ORCH-036 (`adr-0007-executable-self-deploy.md` /
+  `self_deploy` ssh-механизм), ORCH-058 (`adr-0008-staging-image-provenance.md` / `image_freshness`
+  host-side docker), ORCH-110 (`adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md` / proc_group
+  + infra-tolerance + classify), ORCH-101 (`adr-0036-replication-foundation-host-parametrization.md` /
+  host-параметризация)
+- Сверено по коду: `src/staging_runner.py:154/415/487/528`, `src/self_deploy.py:220/287`,
+  `src/image_freshness.py:185/246`, `scripts/orchestrator-deploy-hook.sh:166/197`,
+  `src/proc_group.py`, `src/merge_gate.py:229`, `src/agents/launcher.py:406/438`,
+  `src/main.py:16/58/73`, `Dockerfile:11`, `docker-compose.yml` (docker.sock + ssh mounts),
+  `src/config.py:301-304/455-459`

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

@@ -0,0 +1,85 @@
+---
+work_item: ORCH-123
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 07 — Инфра-требования: ORCH-123 — host-side исполнение staging-раннера
+
+Work Item: **ORCH-123** · Repo: **orchestrator** · Стадия: architecture
+
+> When-applicable. **Топология не меняется** (новых контейнеров/портов/томов/compose-правок нет).
+> Файл фиксирует **границу исполнения** (BR-5/FR-6/AC-12) и **предусловия канала**, на которые
+> раннер теперь опирается программно после фикса (раньше тот же `docker exec` исполнялся изнутри
+> контейнера — и поэтому всегда падал в проде).
+
+## I-1. Граница исполнения docker-операций (нормативно — BR-5 / FR-6)
+
+**Прод-контейнер `orchestrator` (8500) НЕ содержит docker CLI.** `Dockerfile:11` ставит
+`openssh-client git curl ca-certificates` (+ pinned gitleaks); `python:3.12-slim` docker не несёт.
+`/var/run/docker.sock` **смонтирован** (`docker-compose.yml`, rw + `group_add 999`, ORCH-040 «МИНА 1»),
+но **изнутри контейнера не используется** (нет клиента — сознательно, см. ADR-001 D2: добавление
+клиента/SDK = активация root-эквивалентного пути для всего, что исполняется в контейнере).
+
+**Все docker-операции исполняются host-side через ssh на `127.0.0.1`** (доверенный канал, ключ
+смонтирован `${ORCH_HOST_SSH_DIR}:…/.ssh:ro`, `openssh-client` в образе):
+
+| Операция | Компонент | Канал (host-side) |
+|----------|-----------|-------------------|
+| Прод-деплой (рестарт 8500) | `self_deploy.build_deploy_command` (ORCH-036) | `ssh + setsid bash <hook> --deploy` |
+| Ребилд staging-образа из validated commit | `image_freshness.rebuild_staging_image` (ORCH-058) | `ssh … bash <hook> --build-staging` |
+| Инспекция revision-label образа | `image_freshness.image_revision(ssh_target=…)` (ORCH-058) | `ssh … docker image inspect …` |
+| **Staging-сюита на `deploy-staging`** | **`staging_runner.build_staging_command` (ORCH-123)** | **`ssh … docker exec orchestrator-staging python3 staging_check.py …`** |
+
+`scripts/staging_check.py` по-прежнему исполняется **внутри** `orchestrator-staging` (8501) — это
+контракт сюиты (там python3 + приложение 8501, bind-mount `/repos/orchestrator/scripts/…`, ORCH-048).
+**Меняется только инициатор `docker exec`** (host-side ssh вместо изнутри прод-контейнера), не сама
+сюита и не её exit-код-контракт.
+
+## I-2. Предусловия канала исполнения
+
+Раннер после фикса программно опирается на (preflight их пробит на старте сервиса — ADR-001 D5):
+- ssh-доступность `deploy_ssh_host` (`127.0.0.1`) под смонтированным ключом (та же, что использует
+  прод-деплой ORCH-036 / image-freshness ORCH-058 — уже в проде);
+- наличие `docker` CLI **на хосте** (есть; контейнер его не несёт);
+- поднятый и доступный staging-контейнер `orchestrator-staging` (8501) (Допущение А1 ORCH-115).
+
+Недоступность любого предусловия классифицируется **детерминированно** (ADR-001 D3): постоянный
+дефект (`docker`/контейнер/ssh недоступны как класс) → `permanent-env` → **infra-HOLD + алерт**
+(никогда тихий advance / ложный green / откат как код-фейл); транзиентная икота (timeout/ssh-255) →
+bounded DEFER.
+
+## I-3. Переменные окружения / секреты
+
+**Новый env-ключ** (config, дефолт = боевое; добавить в `.env.example`):
+- `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE` (`staging_runner_exec_host_side`, дефолт `True`) — выбор
+  стратегии исполнения. `True` → host-side ssh (фикс). `False` → прежний in-container `docker exec`
+  (валиден только там, где docker CLI запечён в образ). Откат фикса — без LLM-пути.
+
+**Переиспользуются (без изменений):** `ORCH_STAGING_RUNNER_ENABLED`/`_REPOS`/`_TIMEOUT_S`/
+`_INFRA_MAX_RETRIES`/`_INFRA_RETRY_DELAY_S` (ORCH-115); `ORCH_DEPLOY_SSH_USER`/`ORCH_DEPLOY_SSH_HOST`/
+`ORCH_DEPLOY_HOST_REPO_PATH` (ssh-канал ORCH-036); `ORCH_STAGING_PORT`/`ORCH_REPOS_DIR` (ORCH-101).
+**Секретов не вводит** — переиспользует существующий смонтированный ssh-ключ; команда строится из
+существующих host-параметров (анти-дрейф `tests/test_no_host_hardcodes.py`).
+
+## I-4. Деплой / рестарт (self-hosting инвариант, NFR-2 / AC-8)
+
+Раннер на `deploy-staging` **никогда** не рестартит прод-8500, не выполняет
+`docker compose up orchestrator`/`--build` прода, не пушит force в `main`, не правит `.env`/
+`docker-compose.yml`/`Dockerfile` (BR-7 ORCH-115 / AC-8; структурный анти-литерал-тест на
+ssh-обёрнутой команде — TC-08). Argv содержит только `ssh … docker exec orchestrator-staging python3
+staging_check.py … --mode stub`. ORCH-040 (смонтированный сокет) **не трогается и не расширяется**.
+Прод-выкат самого ORCH-123 — штатно через staging-гейт (8501) → `Confirm Deploy` (ORCH-059); это
+**docs/код+config**-изменение, активируется на следующем worktree от `main`, включается флагом
+(дефолт `True`, обратимо двумя флагами — ADR-001 D6).
+
+## I-5. CI/CD
+
+**Без изменений `.gitea/workflows/`.** Новый/расширенный `tests/test_orch123_staging_runner_exec.py`
+исполняется существующим `pytest tests/ -q` (моки subprocess/ssh-spawn и `advance_stage`; живой
+Claude CLI / docker / ssh / сеть не требуются — окружение «нет docker CLI» моделируется монки-патчем
+argv/spawn, `04-test-plan.yaml` notes). Существующие `tests/test_orch115_staging_runner.py` остаются
+зелёными (TC-14).

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

@@ -0,0 +1,93 @@
+---
+work_item: ORCH-123
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+---
+
+# 10 — Технические риски: ORCH-123 — host-side исполнение staging-раннера
+
+Work Item: **ORCH-123** · Repo: **orchestrator** · Стадия: architecture
+
+Формат: риск → вероятность/влияние → митигация (привязка к решению ADR-001 / AC).
+
+---
+
+## R-1 — Security: расширение поверхности атаки docker (NFR-3 / AC-9)
+**Влияние:** критичное (root-эквивалент на общем хосте). **Вероятность (при выбранной стратегии):**
+низкая.
+Любой вариант с docker CLI/SDK **в контейнере** поверх смонтированного `docker.sock` (rw + group_add
+999, ORCH-040) превращает дремлющую возможность в активный root-эквивалентный путь, доступный
+worker-коду **и любому subprocess'у** (вкл. LLM-агентов).
+**Митигация:** выбран **host-side ssh** (ADR-001 D1/D2) — docker-операции на хосте под существующим
+доверенным key-gated каналом (ORCH-036/058), **без** docker CLI/SDK в контейнере и **без** расширения
+использования сокета. ORCH-123 поверхность ORCH-040 не трогает. Любой будущий socket/CLI-в-контейнере
+вариант — отдельный явный security-review.
+
+## R-2 — Реконсилятор/reaper откатывает infra-held задачу как код-фейл (FR-2 / AC-3 / AC-11)
+**Влияние:** высокое (реинтродукция дефекта ORCH-123). **Вероятность:** средняя (зависит от
+поведения reconciler ORCH-053 на застрявшем `deploy-staging`).
+`permanent-env` / исчерпавшая-DEFER задача держится на `deploy-staging` (ADR-001 D4). Если reconciler/
+reaper трактует «застрял на deploy-staging без running-job» как повод откатить на `development` —
+дефект вернётся.
+**Митигация:** developer **обязан** верифицировать, что reconciler/reaper трактует infra-held
+deploy-staging-задачу как **удержанную** (пере-выдать `deployer`-джоб для re-drive после починки
+окружения), а **не** откатывает в `development`. Регресс-покрытие — поведенческий тест на «held не
+становится rollback». Наблюдаемость (D8) делает held видимым (alert + `GET /queue` + лог).
+
+## R-3 — Over-tolerance: реальный код-фейл сюиты замаскирован как «инфра» (BR-3 / AC-4)
+**Влияние:** высокое (сломанный код проходит staging-гейт). **Вероятность:** низкая.
+Трёхсторонняя классификация (D3) может ошибочно отнести реальный `exit≠0` сюиты к
+`permanent-env`/`transient-infra` (→ нет отката) при коллизии exit-кодов
+(`docker exec` No such container = 1, и `staging_check` fail = 1).
+**Митигация (D3):** дизамбигуация по **скану stderr на env-маркеры**, не по голому exit-коду:
+распознанный suite-exit **без** env-маркера всегда `suite-ran` (никогда не реклассифицируется в
+инфру — зеркало ORCH-110 BR-6). Fail-safe default при неоднозначности → `transient-infra` (DEFER), не
+тихий проход. Маркер-сет покрыт TC-06; reviewer проверяет анти-over-tolerance (≥P1, как ORCH-110).
+
+## R-4 — Remote tree-kill: удалённое `docker exec`-дерево переживает таймаут (NFR-5)
+**Влияние:** среднее (осиротевший pytest на хосте — класс ORCH-109/110). **Вероятность:** низкая.
+`proc_group` tree-kill убивает **локальный** ssh-клиент при таймауте, но не гарантирует убийство
+удалённого `docker exec`-дерева на хосте (процессы — дети docker-демона, не ssh-сессии).
+**Митигация:** backstop — bounded таймаут внутри самой `staging_check.py`; это **то же** принятое
+допущение, что у `image_freshness.rebuild_staging_image` (синхронный ssh без remote tree-kill).
+Документируется как known-limitation (ADR-001 D-Последствия); не блокер.
+
+## R-5 — Held-задача клинит serial-gate репо (NFR-5 / AC-11)
+**Влияние:** среднее (более поздние задачи репо ждут). **Вероятность:** средняя (при реальном
+environment-сбое).
+infra-HOLD держит задачу на `deploy-staging` → ORCH-088 serial-gate блокирует **более поздние** задачи
+того же репо до снятия.
+**Митигация:** принятый tradeoff (зеркало ORCH-110 infra-HOLD): environment-проблема, требующая
+оператора, **должна** остановить репо, а не молча ложно-откатывать (что было бы хуже — порча
+done-критериев + расход developer-retry). Скоуп **self-hosting only** (enduro не затронут). Громкий
+alert «инфра, НЕ дефект кода» (D8) → быстрая операторская реакция; `GET /queue` показывает held.
+
+## R-6 — ssh-target не сконфигурирован / пустой `deploy_ssh_host` (FR-1 / D6)
+**Влияние:** среднее. **Вероятность:** низкая (в проде `ORCH_DEPLOY_SSH_HOST=127.0.0.1` задан compose).
+Config-дефолт `deploy_ssh_host=""`; на нестандартном хосте host-side стратегия без ssh-target
+неработоспособна.
+**Митигация:** пустой ssh-target → классификация `permanent-env` (D3) → infra-HOLD + alert (никогда
+ложный откат); preflight на старте (D5) ловит это до реальной задачи. `applies(repo)` self-hosting-only
+→ прочие репо не затронуты.
+
+## R-7 — Кросс-каттинг: правка маркированных блоков (CLAUDE.md §9 / ORCH-078)
+**Влияние:** среднее. **Вероятность:** низкая.
+Затрагиваются блоки с маркерами ORCH-115 (staging_runner, прямой объект), ORCH-036 (`self_deploy`
+ssh), ORCH-058 (`image_freshness` host-side docker), ORCH-110 (`proc_group`/infra-tolerance/classify),
+ORCH-101 (host-параметризация), ORCH-040 (docker.sock mount), ORCH-114 (transition-lease граница).
+**Митигация:** developer **перед** изменением сверяет инварианты с их `06-adr/` (CLAUDE.md §9). Блок с
+≥3 маркерами агрегируется **сводным сквозным ADR** `adr-0049` (ADR-001 Сквозная регистрация). Не
+ломать: один транспорт LLM `_spawn` (`llm-usage-policy.md` §5), `STAGE_TRANSITIONS`/`QG_CHECKS`/
+machine-verdict (NFR-1), transition-lease берётся внутри `advance_stage` (граница O1), INV-4 (мерж
+только через PR-merge, никогда push в `main`).
+
+## R-8 — Регрессия конвейера / гейта (NFR-1 / AC-7)
+**Влияние:** критичное. **Вероятность:** очень низкая.
+Случайное изменение `check_staging_status`/`_parse_staging_status`/`staging_status:`/`STAGE_TRANSITIONS`/
+схемы БД.
+**Митигация:** фикс — замена **стратегии исполнения продюсера**, не гейта (зеркало ORCH-115 NFR-1).
+Структурный анти-регресс-тест (TC-11) держит имена/семантику/ключи байт-в-байт; миграции БД нет
+(restart-safe DEFER-счётчик — маркер в `task_content`, TRZ §5). Анти-дрейф ORCH-115 (TC-14) зелёный.

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

@@ -0,0 +1,153 @@
+---
+verdict: APPROVED
+work_item: ORCH-123
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-123
+version: 1
+---
+
+# Review ORCH-123
+
+## Summary
+
+Фикс инцидента **ORCH-116**: детерминированный staging-runner (ORCH-115) исполнял `docker exec`
+**изнутри** прод-контейнера `orchestrator`, где нет docker CLI (`Dockerfile:11` — только
+`openssh-client git curl`) → `FileNotFoundError` → постоянный environment-дефект ложно
+маршрутизировался как код-фейл-откат `deploy-staging → development` (с расходом developer-retry).
+Задача — `Bug`, эскалирована `escalate: full-cycle` (полный пакет analysis+architecture+ADR).
+
+Изменение точное и минимальное: 9 файлов в реальном скоупе (`65c17d8..HEAD`) —
+`src/staging_runner.py` (+343), `src/config.py` (новый флаг), `src/main.py` (preflight),
+`.env.example`, `CHANGELOG.md`, `CLAUDE.md`, `docs/architecture/README.md`,
+`docs/operations/INFRA.md`, + тесты `tests/test_orch123_staging_runner_exec.py` (503),
+`tests/test_orch115_staging_runner.py` (anti-drift).
+
+Реализация байт-в-байт соответствует ADR-001 / adr-0049 (D1 host-side ssh-wrap, D3 трёхсторонняя
+`classify_staging_outcome`, D4 инвариант «инфра ≠ код-фейл» = infra-HOLD, D5 preflight, D6 флаг,
+D7 сохранность контракта, D8 наблюдаемость). Все четыре оси проверки пройдены; P0/P1 findings нет.
+
+**Проверено фактически:**
+- Полный прогон `pytest tests/ -q` → **2131 passed** (AC-11).
+- Целевой набор `test_orch123_staging_runner_exec.py` + `test_orch115_staging_runner.py` +
+  `test_llm_determinization_docs.py` → **53 passed**.
+- Структурный анти-регресс `test_system_docs.py` + `test_no_host_hardcodes.py` +
+  `test_config.py` → **61 passed**.
+
+## Соответствие ТЗ (02-trz.md / 03-acceptance-criteria.md)
+
+Все функциональные требования и критерии приёмки реализованы и покрыты тестами:
+
+| AC | FR/BR | Статус | Где проверено |
+|----|-------|--------|---------------|
+| AC-1, AC-2 — сюита реально исполняется host-side | FR-1 | ✅ | `build_staging_command` ssh-wrap; TC-02, TC-05 |
+| AC-3 — env/tool-error ≠ код-фейл-откат | FR-2/FR-3 | ✅ | `classify_staging_outcome` + `_handle_permanent_env`/`_handle_transient_infra`; TC-01, TC-03 |
+| AC-4 — анти-over-tolerance (исполнившаяся упавшая сюита → откат) | FR-2/BR-3 | ✅ | check 3 «trust recognised exit-code first»; TC-04, TC-04-exit1-marker |
+| AC-5 — prod-like preflight | FR-4 | ✅ | `preflight()` в `main.lifespan` (best-effort, never-blocks); TC-07 |
+| AC-6 — обязательный регресс red→green | FR-1/FR-2 | ✅ | TC-01 (in-container shape + spawn-error → permanent-env, без advance/defer/retry) |
+| AC-7 — гейт/контракт/стадии/схема без регресса | NFR-1 | ✅ | TC-10, TC-11 (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_staging_status`/схема БД целы) |
+| AC-8 — self-hosting safety | NFR-2 | ✅ | TC-08 (нет `compose`/`--build`/`8500`/`force`/`push`/`.env`/`restart` в argv) |
+| AC-9 — security-review socket/CLI | NFR-3 | ✅ | ADR D2: выбран host-side ssh, docker CLI/SDK НЕ добавлен, `docker.sock` не используется изнутри |
+| AC-10 — kill-switch/область | NFR-4/NFR-6 | ✅ | TC-09 (`staging_runner_exec_host_side` default True; enduro no-op) |
+| AC-11 — never-raise / очередь не клинится | NFR-5 | ✅ | TC-12; полный suite зелёный |
+| AC-12 — документация границы исполнения | BR-5/FR-6 | ✅ | TC-13 (INFRA.md + README.md содержат host-side/ssh/ORCH-123) |
+
+Регресс R-2 (held `deploy-staging`-задача не откатывается reconciler'ом) — отдельный тест
+`test_r2_held_deploy_staging_not_rolled_back`: при отсутствии `15-staging-log.md` (infra-HOLD)
+`advance_if_gate_passed` отдаёт `None`, задача держится на `deploy-staging`, `advance_stage` не
+зовётся. Закрывает риск реинтродукции дефекта (10-tech-risks R-2).
+
+## Соответствие ADR (06-adr/ADR-001 + сквозной adr-0049)
+
+- **D1** — `build_staging_command` оборачивает ту же `docker exec … staging_check.py … --mode stub`
+  в `ssh -o StrictHostKeyChecking=no <user@host> '<inner>'` (зеркало `self_deploy.build_deploy_command`/
+  `image_freshness.image_revision`); inner-команда `shlex.quote`-ится; fallback на in-container при
+  выключенном флаге ИЛИ пустом ssh-target. ✅
+- **D3** — `classify_staging_outcome` различает три класса с корректным порядком проверок:
+  env-маркер в stderr → `permanent-env` (дизамбигуация `exit=1` коллизии «No such container» vs
+  реальный фейл, R-3); 126/127 → `permanent-env`; распознанный int≠255 без маркера → `suite-ran`
+  (проверяется **до** channel-guards → реальный фейл не маскируется, BR-3); timeout/255 →
+  `transient-infra`; нет ssh-target/`rc=None` → `permanent-env`; неизвестно → fail-safe
+  `transient-infra`. Pure, never-raise. ✅
+- **D4** — инвариант «инфра ≠ код-фейл»: `permanent-env` → немедленный infra-HOLD (без `_advance`,
+  без FAILED-лога, без developer-retry); `transient-infra` → bounded DEFER, на исчерпании — тоже
+  infra-HOLD (суперсед терминала ORCH-115 D5 fail-closed-FAILED+rollback). ✅
+- **D5** — `preflight()` зондирует host-side канал коротким bounded ssh-probe, пишет
+  `_PREFLIGHT_STATE`, алертит; вызван best-effort из `main.lifespan` после lease-recovery,
+  никогда не блокирует старт. ✅
+- **D6** — `staging_runner_exec_host_side: bool = True` (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`),
+  дефолт = боевое; откат двумя флагами. ✅
+- **D7** — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_staging_status`/`_parse_staging_status`/
+  machine-verdict `staging_status:`/схема БД — байт-в-байт (TC-10/TC-11). ✅
+- **D8** — `snapshot()` различает три не-успешных класса (`failed`=code-fail / `deferred`=transient /
+  `permanent_env`=infra-HOLD) + `exec_host_side` + `preflight`. ✅
+
+**Трассировка маркеров (CLAUDE.md §9 / TRACEABILITY.md):** ORCH-123 правит блоки ORCH-115
+(staging-runner, прямой объект), ORCH-036 (self_deploy ssh-паттерн), ORCH-110 (proc_group/classify
+/infra-tolerance), ORCH-058 (host-side docker). ADR явно сверяется с их инвариантами и не ломает
+их; анти-дрейф ORCH-115 — TC-14 (`should_intercept`/`map_exit_code_to_status` shared-контракт,
+kill-switch → LLM) зелёный.
+
+## Качество кода
+
+- Чистый leaf-стиль по образцу `merge_gate`/`self_deploy`/`image_freshness`; на импорте только
+  `config`/`shlex`/`subprocess`, тяжёлое — лениво. Все публичные функции с docstrings.
+- `never-raise` соблюдён на всех путях (classify, preflight, snapshot, run_staging_gate, alert'ы).
+- Старое имя `_handle_tool_error` чисто переименовано в `_handle_transient_infra` — висячих ссылок
+  нет (grep пуст).
+- Тесты содержательные (поведенческие, не тривиальные): мокается subprocess/advance/notifications,
+  spawn-error воспроизводится несуществующим бинарём — без живого ssh/docker/сети.
+- **Багфикс-трек (ORCH-019 BR-4):** обязательный регресс-тест-фиксатор дефекта присутствует —
+  TC-01 красный на коде до фикса (нет класса/счётчика `permanent_env`, путь advance'ит + DEFER),
+  зелёный после. Требование выполнено.
+
+## Документация
+
+`src/` изменён → документация обновлена **в том же PR** (golden source):
+- `docs/operations/INFRA.md` — новый раздел «Граница исполнения docker-операций — host-side» +
+  правило 4 для агентов (FR-6 / AC-12). ✅
+- `docs/architecture/README.md` — секция Staging-runner дополнена host-side стратегией +
+  трёхсторонней классификацией + ссылкой на adr-0049. ✅
+- `CLAUDE.md` — раздел ORCH-123 (host-side exec + классификация environment-дефекта). ✅
+- `CHANGELOG.md` — запись `fix(staging)`. ✅
+- `.env.example` — новый ключ `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true` + описание. ✅
+- ADR: `06-adr/ADR-001-…` + сквозной `docs/architecture/adr/adr-0049-…`. ✅
+
+**Витрина системы `docs/overview/` (ORCH-011)** — обновление НЕ требуется: канал исполнения
+(host-side vs in-container) — внутренняя деталь реализации; машинно-проверяемые факты витрины
+(детерминированный раннер заменил LLM-`deployer`, kill-switch, скоуп) ORCH-123 не меняет;
+`test_system_docs.py` зелёный.
+
+**Обзорные доки `README.md` «Известные ограничения» (ORCH-079)** — обновление НЕ требуется:
+ORCH-123 закрывает внутренний регресс ORCH-116, а не задокументированное ограничение; релевантного
+пункта в списке нет.
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice-to-have (не блокирует)
+- `preflight()` использует прямой `subprocess.run(timeout=20)` вместо `proc_group` — для короткого
+  read-only ssh-зонда приемлемо (тот же паттерн, что у host-side probe'ов `image_freshness`);
+  при таймауте локальный ssh-клиент завершается subprocess'ом без tree-kill, что для 20-секундного
+  inspect незначимо. Можно унифицировать в будущем, не обязательно.
+- `_channel_ssh_configured()` вызывается дважды в `run_staging_gate` (для classify и для лог-строки
+  `permanent-env`) — микро-избыточность, never-raise, влияния нет.
+
+## Вердикт
+
+**APPROVED.** Реализация полно и точно покрывает ТЗ/AC, соответствует ADR-001/adr-0049, не трогает
+гейты/стадии/контракт/схему БД, безопасна для self-hosting, документация (включая витрину-проверку
+и обзорные доки) в порядке, обязательный багфикс-регресс присутствует и зелёный, полный suite
+(2131) зелёный. P0/P1 отсутствуют.

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

@@ -0,0 +1,81 @@
+---
+result: PASS
+work_item: ORCH-123
+stage: testing
+author_agent: tester
+status: pass
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+type: test-report
+work_item_id: ORCH-123
+---
+
+# Test Report — ORCH-123
+
+Bugfix инцидента **ORCH-116**: детерминированный staging-runner (ORCH-115) вызывал `docker exec`
+**изнутри** прод-контейнера `orchestrator`, где нет docker CLI → `FileNotFoundError` → постоянный
+environment-дефект ложно маршрутизировался как код-фейл-откат `deploy-staging → development`.
+Фикс — host-side ssh-исполнение + трёхсторонняя классификация (`suite-ran` / `permanent-env` /
+`transient-infra`). Review-вердикт: **APPROVED**.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.14.0, asyncio-0.23.8)
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-123-bug-staging-runner-assumes-doc`
+- Branch: `feature/ORCH-123-bug-staging-runner-assumes-doc` (HEAD `820e534`)
+- Дата: 2026-06-16
+
+## Smoke API (read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — задача ORCH-123 (id=110) на стадии `testing` |
+| `GET /queue` | PASS — блоки `serial_gate` (ORCH-088), `auto_labels` (ORCH-089), `staging_runner` (ORCH-115/123) присутствуют в полезной нагрузке |
+
+## Результаты (покрытие test-plan `04-test-plan.yaml` ↔ AC)
+
+| TC ID | Описание | AC | Тест | Результат |
+|-------|----------|----|------|-----------|
+| TC-01 | РЕГРЕСС red→green: исполнение сюиты без docker CLI в контейнере; spawn-error → `permanent-env`, без advance/defer/retry | AC-6/AC-1 | `test_tc01_regression_no_docker_cli_in_container` | PASS |
+| TC-02 | Стратегия исполнения не зависит от docker CLI внутри контейнера (host-side argv/канал) | AC-1 | `test_tc02_host_side_command_does_not_assume_in_container_docker` | PASS |
+| TC-03 | environment/tool-error НЕ даёт код-фейл-отката; нет developer-retry; инфра-алерт | AC-3 | `test_tc03_env_defect_no_code_fail_rollback_and_alerts` | PASS |
+| TC-04 | Анти-over-tolerance: сюита исполнилась + exit≠0 → FAILED → прежний откат + developer-retry; `exit=1` с env-маркером ≠ код-фейл | AC-4 | `test_tc04_real_suite_failure_still_rolls_back`, `test_tc04_exit1_with_env_marker_is_not_a_code_fail` | PASS |
+| TC-05 | Happy-path: exit 0 → `staging_status: SUCCESS` → штатный advance (контракт ORCH-115 D7) | AC-2 | `test_tc05_happy_path_success_advances` | PASS |
+| TC-06 | Классификация три-way; постоянный env-дефект ≠ транзиент ≠ код-фейл; never-raise; transient → DEFER не откат | AC-3 | `test_tc06_classification_three_way`, `..._never_raises`, `..._transient_infra_defers_not_rolls_back` | PASS |
+| TC-07 | Prod-like preflight сигнализирует ДО ложного отката (success/failure/no-target/disabled/in-container) | AC-5 | `test_tc07_preflight_*` (5 тестов) | PASS |
+| TC-08 | Self-hosting safety: нет `compose`/`--build`/`8500`/force-push/`main`/`.env` в argv | AC-8 | `test_tc08_host_side_command_has_no_dangerous_literals` | PASS |
+| TC-09 | Kill-switch/область: `staging_runner_enabled=False` → `_spawn`; flag default = боевое; host-side off / no-target → in-container fallback | AC-10 | `test_tc09_killswitch_scope_and_flag_default`, `..._host_side_off_falls_back_to_in_container`, `..._host_side_on_but_no_target_falls_back` | PASS |
+| TC-10 | Контракт артефакта `15-staging-log.md` (`staging_status:` UPPERCASE + 52c, `author_agent: staging-runner`/`model_used: n/a`) | AC-7 | `test_tc10_artifact_contract_unchanged` | PASS |
+| TC-11 | Анти-регресс конвейера: `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_staging_status`/`_parse_staging_status`/machine-keys/схема БД — не тронуты | AC-7 | `test_tc11_pipeline_contract_unchanged` | PASS |
+| TC-12 | never-raise / очередь не клинится; snapshot различает классы (`failed`/`deferred`/`permanent_env`) | AC-11 | `test_tc12_run_gate_never_raises`, `..._snapshot_distinguishes_classes`, `..._snapshot_never_raises` | PASS |
+| TC-13 | Документация-инвариант: INFRA.md + README.md описывают границу исполнения (host-side vs in-container) | AC-12 | `test_tc13_docs_describe_execution_boundary` | PASS |
+| TC-14 | Анти-дрейф ORCH-115: структурные тесты staging-runner остаются зелёными | AC-7 | `test_tc14_orch115_invariants_intact` + полный `test_orch115_staging_runner.py` (24 теста) | PASS |
+| R-2 | Held `deploy-staging`-задача не откатывается reconciler'ом при infra-HOLD | AC-3 | `test_r2_held_deploy_staging_not_rolled_back` | PASS |
+
+Все 14 TC из `04-test-plan.yaml` выполнены и сопоставлены с критериями приёмки
+`03-acceptance-criteria.md`. Обязательный регресс-фиксатор дефекта (TC-01, ORCH-019 BR-4) присутствует
+и зелёный.
+
+## Вывод pytest
+
+Целевой набор:
+```
+tests/test_orch123_staging_runner_exec.py ... (26 tests)
+tests/test_orch115_staging_runner.py ...     (24 tests)
+======================== 50 passed, 1 warning in 3.17s =========================
+```
+
+Полный регресс (NFR-1, AC-11):
+```
+python -m pytest tests/ -q --tb=short
+........................................................................ [100%]
+2131 passed, 1 warning in 91.73s (0:01:31)
+```
+
+(Единственное warning — `PydanticDeprecatedSince20` в `src/config.py:8`, унаследованное,
+не относится к задаче.)
+
+## Итог
+**PASS** — полный регресс `2131 passed`, целевой набор `50 passed`, smoke `/health` `/status`
+`/queue` (с блоками `serial_gate`/`auto_labels`/`staging_runner`) OK, каждый TC из test-plan выполнен
+и сопоставлен с AC. Задача готова к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,35 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-123
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+timestamp: 2026-06-16T05:57:12Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging instance (`orchestrator-staging`, port 8501).
+
+**Execution strategy (ORCH-123):** the canonical `docker exec orchestrator-staging … staging_check.py
+--base-url http://localhost:8501 --mode stub` was initiated **host-side via ssh**
+(`slin@127.0.0.1`), because the prod container carries no docker CLI (`Dockerfile` ships only
+`openssh-client git curl`). The suite itself runs INSIDE `orchestrator-staging`.
+
+**Result:** `8/10 checks PASS`, exit code `0` → `staging_status: SUCCESS`.
+
+- REAL failed: none — every real check (Block A smoke, Block B access incl. B6 registry isolation
+  `sandbox=YES, prod-ET=NO, prod-ORCH=NO`, Block C create/trigger) is green.
+- Waived (ORCH-061 infra 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
+```
+
+C9a/C9b depend on SANDBOX bot accounts being project members (sandbox-infra, not the pipeline) and
+are tolerated when every REAL check is green. The exit-code → verdict mapping is unchanged: trust the
+exit code (0 → SUCCESS); waived checks are not re-judged.

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

@@ -0,0 +1,7 @@
+# Business Request: BUG: serial gate treats Backlog/Blocked paused tasks as active and blocks urgent successors
+
+Work Item ID: ORCH-124
+
+## Description
+
+TBD

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

@@ -0,0 +1,185 @@
+---
+work_item: ORCH-124
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 01 — BRD / Bug-report: ORCH-124 — serial gate treats Backlog/Blocked/Needs-Input paused tasks as active and blocks urgent successors
+
+Work Item: **ORCH-124** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в full-cycle**
+
+> ⚠️ **`escalate: full-cycle` (ADR-001 D5 ORCH-019).** Метка задачи — `Bug`, но по сути это
+> **архитектурный** дефект: требуется **определить семантику wait/terminal состояний serial-gate**
+> и выбрать механизм «пауза без блокировки» (release-on-status / явный per-task hold-флаг /
+> переиспользование `task_deps`). Любой вариант пересекается с **корневым инвариантом ORCH-088
+> (анти-stale-base)** и с гармонизированным терминальным предикатом ORCH-090 (`adr-0026`,
+> `serial_gate` + `task_deps` + `stages.py`). Это не «однострочная» правка — нужен ADR с явным
+> разрешением конфликта свойств (см. §8 и `10-tech-risks.md` архитектора). Поэтому выпускается
+> **полный** analysis-пакет (а не облегчённый bug-пакет). Оператор снимает багфикс-трек:
+> `POST /bug-fast-track/escalate?work_item=ORCH-124` → задача пойдёт через стадию `architecture`
+> (architect выпустит ADR для семантики паузы serial-gate).
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### Симптом (наблюдаемое — установленный факт инцидента)
+Во время инцидента **ORCH-116/ORCH-123**: задачу **ORCH-116** намеренно поставили на паузу
+(перевели в Plane-статус Blocked/Backlog), чтобы вперёд пропустить срочный фикс **ORCH-123**.
+Однако `serial_gate` **по-прежнему считал ORCH-116 активной задачей** (`active_task`) и держал
+analyst-job ORCH-123 в очереди (`queued`) — срочный фикс не мог стартовать, пока ORCH-116
+формально не `done`/`cancelled`.
+
+### Причина симптома (установленный факт — верифицировано по коду)
+`serial_gate` определяет «активную задачу репо» **исключительно по машинной стадии**
+`tasks.stage NOT IN ('done','cancelled')` — в трёх местах `src/serial_gate.py`:
+- `build_claim_clause()` — горячий SQL-фрагмент в `db.claim_next_job`:
+  `EXISTS (SELECT 1 FROM tasks t2 WHERE t2.repo = jobs.repo AND t2.id < jobs.task_id AND
+  t2.stage NOT IN ('done','cancelled'))`;
+- `repo_has_active_task()` — Python-зеркало для наблюдаемости;
+- `_per_repo_snapshot()` — выбор `active_task` для блока `serial_gate` в `GET /queue`.
+
+При этом **Plane-статусы Backlog / Blocked / Needs Input — это слой B (индикация), ORCH-066**, и они
+**не меняют `tasks.stage` (слой A)**. Сеттеры `set_issue_blocked` / `set_issue_needs_input`
+(`src/plane_sync.py`) делают только `PATCH` Plane-статуса; машинная стадия задачи остаётся прежней
+(`analysis` / `development` / `deploy-staging` …). Подтверждение из кода: у таблицы `tasks` **нет
+колонки статуса** (комментарий `src/reconciler.py:322`: «`tasks` has no status column, so the live
+Plane state is the source of truth»). Следовательно для serial-gate приостановленная задача неотличима
+от активно исполняемой — её стадия не входит в `{done,cancelled}`, значит она «активна» и блокирует
+FIFO всех более поздних analyst-job того же репо.
+
+### Почему это важно (бизнес-боль)
+- **Срочный фикс не запускается**, пока более ранняя задача поставлена на паузу. Единственные
+  существующие способы «разблокировать» — терминально `cancel`/довести до `done`, либо целиком
+  выключить serial-gate (`ORCH_SERIAL_GATE_ENABLED=false`) для всех репо. Все три — грубые.
+- У оператора **нет чистого механизма «пауза без блокировки»** с явным намерением — отдельного от
+  отмены (терминал) и от глобального выключения гейта.
+- На пакетном автономном прогоне (эпик ORCH-088) это превращает любую «отложенную» задачу в стоп-кран
+  очереди репо.
+
+### Прецедент в коде (контекст для архитектора, не решение)
+Reconciler уже **умеет** уважать wait-состояния: ORCH-060 Guard 2 (`reconciler._is_blocked_or_needs_input`,
+Variant A) **сетевым** запросом Plane-статуса пропускает Blocked/Needs-Input (и активные
+ORCH-066-ожидания) и не «оживляет» их. Но reconciler — фоновый тик и **может** позволить себе сетевой
+вызов; `serial_gate.build_claim_clause` врезан в `claim_next_job` (**offline hot-path**) и сетевого
+вызова позволить **не может** (NFR-2 ниже). Это центральное расхождение, которое и порождает баг:
+сигнал паузы есть в Plane, но не доступен горячему SQL гейта.
+
+## 2. Объём (scope)
+
+### В объёме
+- Определить **семантику wait/terminal** для serial-gate: какие состояния задачи-предшественника
+  НЕ должны держать FIFO-гейт закрытым для более поздней задачи.
+- Дать оператору **явный, durable, DB-резолвимый** механизм «пауза без блокировки» (или формально
+  переиспользовать существующий: freeze / task_deps), с чётким намерением, отличным от cancel.
+- Поправить определение «активной задачи» во **всех трёх** точках `serial_gate.py`, чтобы
+  приостановленная задача не считалась `active_task`.
+- Корректная **причина ожидания** в блоке `serial_gate` снапшота `GET /queue`
+  (active task / paused-predecessor / freeze / dependency).
+- Тесты: предшественник Blocked/Backlog/Needs-Input + срочный успешник; регресс-тест инцидента.
+
+### Вне объёма
+- Изменения `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей — **не трогаем**
+  (маршрутизация очереди — свойство планировщика, не Quality Gate).
+- Введение нового **машинного** статуса в `STAGE_TRANSITIONS` (это не новая стадия конвейера).
+- Изменение поведения reconciler ORCH-060 (его networked-skip уже корректен; гармонизация — на
+  усмотрение архитектора, но переписывать его не требуется).
+- Автоматическое управление паузой по данным вне явного намерения оператора (никакого эвристического
+  «само-распаузивания»).
+- Конкретный **выбор механизма** (release-on-status vs per-task hold-флаг vs task_deps) — это решение
+  **архитектора** (ADR), а не аналитика.
+
+## 3. Заинтересованные стороны
+- **Оператор/владелец конвейера (Слава)** — заказчик: нуждается в чистой паузе, чтобы пропускать
+  срочные фиксы без отмены и без выключения гейта.
+- **Self-hosting orchestrator** — затрагивается напрямую (serial-gate активен для всех репо).
+- **enduro-trails** — затрагивается косвенно (общая БД/очередь); регрессия недопустима при
+  выключенном/нейтральном поведении.
+- **Архитектор** — принимает решение о механизме и семантике (ADR), разрешает конфликт §8.
+- Принимает результат — reviewer + tester по критериям `03-acceptance-criteria.md`.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — Перевод задачи-предшественника в состояние паузы/ожидания (Backlog / Blocked /
+  Needs Input) **больше не должен случайно блокировать** более позднюю срочную задачу того же репо в
+  serial-gate. Проверяемо: analyst-job успешника становится claimable.
+- **BR-2** — У оператора есть **чистый механизм «пауза без блокировки»** с явным намерением,
+  **отличный** от `cancel` (терминал) и от глобального выключения гейта. Намерение — durable
+  (переживает рестарт процесса/контейнера).
+- **BR-3** — Пауза снимает гейт **только по явному намерению**. **Нормально исполняемая** задача
+  (реально идёт работа) **по-прежнему держит** гейт — анти-stale-base гарантия ORCH-088 не
+  регрессирует (см. §8 — конфликт свойств, разрешает архитектор).
+- **BR-4** — Снапшот `serial_gate` в `GET /queue` показывает **корректную причину** ожидания
+  успешника: активная задача / приостановленный предшественник / freeze / dependency.
+- **BR-5** — При **возобновлении** (распаузе) задачи serial-ordering корректно восстанавливается:
+  возобновлённая задача снова участвует в гейте (либо держит его, либо явно ре-входит в FIFO с
+  обязательством rebase) — нет «вечного обхода» и нет потерянного намерения.
+- **BR-6** — Существующие гарантии serial-gate сохранены: FIFO по более ранним незавершённым
+  задачам, durable per-repo `freeze` (`repo_freeze`), cross-repo параллелизм, явные `task_deps` —
+  по-прежнему блокируют, где должны.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (never-raise / fail-safe)** — Контракт leaf `serial_gate` сохранён: каждая публичная
+  функция деградирует консервативно. Сохранить два направления отказа ORCH-088: hot-claim build →
+  **fail-OPEN** (`""`-фрагмент, не заклинить очередь всех проектов, AC-8 ORCH-088); freeze-решение →
+  **fail-CLOSED** (прод-безопасность, AC-9 ORCH-088). Новая логика паузы не должна инвертировать эти
+  направления.
+- **NFR-2 (чистота hot-path)** — Гейт-в-claim остаётся **offline SQL-предикатом**; **никаких сетевых
+  вызовов** (в т.ч. Plane API) в `claim_next_job`. Сигнал «пауза» обязан быть **DB-резолвимым**
+  (durable колонка/таблица), а не считываться из Plane на горячем пути (в отличие от reconciler).
+- **NFR-3 (обратная совместимость / kill-switch / область)** — Изменение аддитивно и обратимо;
+  выключатель (существующий `serial_gate_enabled` либо новый под-флаг) → байт-в-байт прежнее поведение
+  до ORCH-124. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / **схемы
+  существующих таблиц** — без изменений (новая колонка/таблица — только аддитивно, паттерн
+  `_ensure_column` / `CREATE TABLE IF NOT EXISTS`). enduro не затронут при нейтральном поведении.
+- **NFR-4 (гармонизация предиката)** — Любой новый предикат «активна/терминальна/пауза» должен
+  оставаться согласованным с гармонизированным терминальным множеством `{done,cancelled}` в
+  `serial_gate` + `task_deps` + `stages.py` (ORCH-090 / adr-0026), либо архитектор явно описывает,
+  почему serial-gate расходится (паузой), не ломая `task_deps`.
+- **NFR-5 (self-hosting безопасность)** — Никакого рестарта/падения прод-контейнера, мутации `main`,
+  force-push; только чтение/запись своих таблиц и принятие решения о claim. Hot-path не должен
+  замедляться сетью или тяжёлым запросом.
+
+## 6. Допущения и ограничения
+- У таблицы `tasks` **сегодня нет колонки статуса**; Plane-статус (Backlog/Blocked/Needs Input) —
+  слой B индикации, в БД не отражён. Значит «пауза» для горячего пути требует **нового durable
+  DB-сигнала** (колонка `tasks` или отдельная таблица), либо переиспользования уже DB-резолвимого
+  механизма (`repo_freeze` / `task_deps`).
+- `repo_freeze` существует, но **freeze'ит весь репо** (блокирует всех успешников) — это
+  противоположность «пропустить срочного успешника», поэтому как есть не годится для BR-1 (но годится
+  как явный блок для BR-6).
+- `task_deps` (`job_deps`) — явные декларации зависимостей, уже DB-резолвимы и консультируются в
+  `claim_next_job` (`NOT EXISTS`); кандидат на «explicit intent», на усмотрение архитектора.
+- Reconciler ORCH-060 различает Blocked/Needs-Input **сетевым** запросом Plane — прецедент семантики,
+  но **не переиспользуем** на hot-path (NFR-2).
+- Серый кейс: Needs Input во время `analysis` — нормальное короткое ожидание ответа; решение, считать
+  ли его «паузой для гейта», за архитектором (важно не превратить штатное короткое ожидание в обход
+  анти-stale-base).
+
+## 7. Критерии успеха
+Кратко (детальные PASS/FAIL — `03-acceptance-criteria.md`):
+- Приостановленный предшественник (Backlog/Blocked/Needs-Input по явному намерению) не блокирует
+  срочного успешника; нормально идущая задача — блокирует; freeze/dependency блокируют, где должны;
+  `GET /queue` показывает корректную причину; всё под kill-switch; машинные инварианты байт-в-байт;
+  регресс-тест инцидента красный до фикса и зелёный после.
+
+## 8. Риски
+Кратко (детально — `10-tech-risks.md`, заполняет архитектор):
+- **R-1 (ключевой конфликт свойств) — пауза vs анти-stale-base (ORCH-088).** Если «пауза» освобождает
+  гейт, успешник срежет ветку от `main`, ещё **не** содержащего код предшественника. Когда
+  приостановленный предшественник позже возобновится и смержится — его база/ветка могут стать stale.
+  ORCH-088 был построен ровно чтобы это предотвратить. Архитектор обязан разрешить конфликт явно
+  (напр.: пауза «демотирует» задачу в FIFO и обязывает rebase при возобновлении; либо явный per-task
+  «yield» с принятием rebase). **Аналитик фиксирует конфликт, не выбирает решение.**
+- **R-2** — Случайное/неявное освобождение гейта (баг в детекте намерения) ослабит сериализацию для
+  всех — требуется строго **явное** намерение оператора.
+- **R-3** — Рассинхрон «Plane-статус ↔ DB-сигнал паузы»: если механизм опирается на webhook о смене
+  статуса, потерянный webhook оставит задачу «активной» в БД (или наоборот). Нужен durable,
+  идемпотентный, восстановимый сигнал.
+- **R-4** — Регрессия гармонизированного предиката `{done,cancelled}` в `task_deps`/`stages.py`, если
+  serial-gate изменит понимание «активности» неаккуратно.
+- **R-5** — fail-direction: ошибка в новой ветке не должна инвертировать fail-OPEN (claim) /
+  fail-CLOSED (freeze) контракты ORCH-088.

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

@@ -0,0 +1,133 @@
+---
+work_item: ORCH-124
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-16
+model_used: claude-opus-4-8
+escalate: full-cycle
+---
+
+# 02 — ТЗ (TRZ): ORCH-124 — wait/terminal-семантика serial-gate (пауза без блокировки)
+
+Work Item: **ORCH-124** · Repo: **orchestrator** · Стадия: analysis
+
+> ТЗ описывает **требования к изменениям**, выведенные из BRD и фактического кода. **Выбор
+> механизма** «паузы без блокировки» (release-on-status / per-task hold-флаг / task_deps) и его
+> архитектурное обоснование — задача **архитектора** (`06-adr`, эскалация в full-cycle). Ниже —
+> что должно стать истинным и какие модули это затронет, без предписания «как именно».
+
+## 1. Сводка изменения
+Сейчас serial-gate (`src/serial_gate.py`) считает «активной» любую задачу репо со стадией вне
+`{done,cancelled}` — в трёх точках (`build_claim_clause` / `repo_has_active_task` /
+`_per_repo_snapshot`). Поскольку Plane-статусы Backlog/Blocked/Needs-Input (слой B индикации) **не
+меняют `tasks.stage`** (слой A), приостановленная задача неотличима от активной и держит FIFO-гейт
+закрытым для более поздних analyst-job. Требуется ввести **явный, durable, DB-резолвимый** признак
+«пауза/park» и научить определение «активной задачи» его учитывать, **сохранив** анти-stale-base
+ORCH-088 при возобновлении (R-1). Машинные гейты не трогаются — это правка **планировщика очереди**.
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/serial_gate.py` | изменить — определение «активной задачи» во всех 3 точках (`build_claim_clause`, `repo_has_active_task`, `_per_repo_snapshot`); причина ожидания в снапшоте |
+| `src/db.py` | изменить (вероятно) — `claim_next_job` (учёт нового предиката в горячем SQL) + (если выбран DB-сигнал) аддитивная колонка/таблица `_ensure_column`/`CREATE TABLE IF NOT EXISTS` + read-only/мутатор-хелперы |
+| `src/config.py` | изменить — под-флаг(и) семантики паузы (kill-switch), область репо (по образцу `serial_gate_*`) |
+| `src/main.py` | изменить (вероятно) — операторский эндпоинт pause/resume **или** расширение блока `serial_gate` в `GET /queue` причиной ожидания |
+| `src/webhooks/plane.py` и/или `src/plane_sync.py` | изменить (если механизм = release-on-status) — захват намерения паузы из смены Plane-статуса в durable DB-сигнал (не на hot-path) |
+| `tests/test_serial_gate*.py` (новый `tests/test_orch124_serial_gate_pause.py`) | создать/дополнить — кейсы паузы + регресс инцидента |
+| `docs/architecture/README.md`, `CHANGELOG.md`, `docs/work-items/ORCH-124/06-adr/` | обновить — раздел serial-gate + ADR (архитектор) |
+
+> Точный набор модулей зависит от выбранного механизма (ADR). Минимально-необходимый набор —
+> `serial_gate.py` (3 точки) + `db.py` (hot-path) + `config.py` (флаг) + тесты; остальное — по решению
+> архитектора.
+
+## 3. Функциональные требования
+
+### FR-1 — Признак паузы исключает задачу из «активных» в горячем SQL (BR-1, NFR-2)
+`build_claim_clause()`: подзапрос `EXISTS (... t2.stage NOT IN ('done','cancelled'))` должен
+**дополнительно** исключать приостановленные задачи-предшественники. Предикат — **чисто SQL по
+локальной БД** (никакой сети). Форма исключения — функция выбранного DB-сигнала (доп. колонка
+`tasks.<paused>` / отдельная таблица hold / `task_deps`): архитектор фиксирует точную SQL-форму в ADR.
+Инвариант: job'ы уже активной задачи (`agent != 'analyst'`) проходят как раньше; самоблокировки
+собственной строки (R-7 ORCH-088) нет.
+
+### FR-2 — Зеркало и снапшот согласованы с FR-1 (BR-1/BR-4)
+`repo_has_active_task()` и `_per_repo_snapshot()` используют **тот же** предикат «активна», что и
+`build_claim_clause` — приостановленный предшественник не попадает в `active_task`. Все три точки
+правятся согласованно (анти-дрейф: они должны давать один ответ на один вход).
+
+### FR-3 — Явное durable намерение паузы (BR-2, BR-5, NFR-2)
+Должен существовать **явный** оператор-инициируемый сигнал «park/pause» задачи, **durable**
+(переживает рестарт) и **DB-резолвимый**. Распауза (resume) — обратная операция, восстанавливающая
+участие задачи в serial-gate (BR-5). Сигнал **отличен** от `cancel`/`done` (не терминальный) и от
+глобального kill-switch. Конкретная форма (новый эндпоинт `POST /serial-gate/pause|resume`, или
+маппинг Plane-статуса в DB-сигнал через webhook, или декларация `task_deps`) — **решение архитектора**.
+
+### FR-4 — Анти-stale-base при возобновлении (BR-3, R-1 — критично)
+Решение обязано **не регрессировать** ORCH-088: нормально исполняемая задача держит гейт; а
+возобновлённая ранее приостановленная задача не должна приводить к stale-базе у успешника, который
+прошёл вперёд. Механизм разрешения (демотирование в FIFO + обязательный rebase при resume / явный
+yield с принятием rebase / иное) фиксируется архитектором в ADR. ТЗ требует лишь: после распаузы
+ни одна из задач не остаётся на устаревшей базе незаметно.
+
+### FR-5 — Корректная причина ожидания (BR-4)
+Блок `serial_gate` в `GET /queue` для ожидающего успешника различает причины: `active-task`
+(идёт работа) / `paused-predecessor` (предшественник на паузе — не должно случаться после фикса, но
+наблюдаемо) / `freeze` / `dependency`. Аддитивно к существующим ключам снапшота (`active_task` /
+`waiting` / `frozen` / `frozen_reason` / `frozen_at`).
+
+### FR-6 — Явные блоки сохранены (BR-6)
+`repo_freeze` (durable per-repo freeze) и `task_deps` (`job_deps`) продолжают блокировать claim ровно
+как сейчас. «Пауза» НЕ должна обходить freeze/dependency — это разные оси (freeze = весь репо;
+dependency = конкретная пара; пауза = «пропустите меня»).
+
+### FR-7 — Условность и нейтральность (NFR-3)
+Поведение под выключателем (существующий `serial_gate_enabled` либо новый под-флаг паузы) → байт-в-байт
+до ORCH-124. Область репо — по образцу `serial_gate_repos` (CSV; пусто → текущая область serial-gate,
+т.е. все репо). enduro не затронут при нейтральном поведении.
+
+## 4. Изменения API
+Вероятно (на усмотрение архитектора, ADR):
+- **Новые операторские эндпоинты** `POST /serial-gate/pause?work_item=<id>` и
+  `POST /serial-gate/resume?work_item=<id>` (по образцу существующего `POST /serial-gate/unfreeze`),
+  если механизм = явный per-task hold. Возвращают новое состояние (paused/active) задачи.
+- **Расширение** `GET /queue` → блок `serial_gate` дополняется причиной ожидания (FR-5) и (если есть)
+  списком приостановленных задач репо. Существующие ключи не меняются (BC).
+
+Если механизм = release-on-status, новых ручных эндпоинтов может не быть (намерение — смена Plane-статуса,
+захватываемая webhook'ом в durable DB-сигнал); тогда раздел сводится к расширению `GET /queue`.
+
+## 5. Изменения схемы БД
+Вероятно **аддитивно** (на усмотрение архитектора):
+- Колонка `tasks.paused_at TEXT` (NULL = не на паузе), идемпотентно через `_ensure_column` — паттерн
+  существующих `tasks.cancelled_at` / `tasks.cancel_requested_at` / `tasks.track`; **или**
+- Отдельная таблица hold (по образцу `repo_freeze`: `work_item_id`/`task_id`, `paused_at`,
+  `cleared_at IS NULL` = активна), `CREATE TABLE IF NOT EXISTS`.
+Схемы **существующих** таблиц (`tasks`/`jobs`/`job_deps`/`repo_freeze`) — без деструктивных изменений.
+Если механизм = task_deps, новой схемы может не понадобиться вовсе. Финальное решение — ADR +
+`08-data-requirements.md` (архитектор).
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** `STAGE_TRANSITIONS` / состав `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи
+(`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) — **байт-в-байт не
+трогаются**. ORCH-124 — правка планировщика очереди (claim) и наблюдаемости, **не** Quality Gate и
+**не** новая стадия конвейера.
+
+## 7. Совместимость / регресс
+- **Обратная совместимость:** аддитивно; выключатель → поведение до ORCH-124 байт-в-байт (NFR-3,
+  FR-7). Существующие тесты serial-gate (`tests/test_serial_gate*.py`) остаются зелёными.
+- **Kill-switch / область:** переиспользовать `serial_gate_enabled` (kill-switch) + при необходимости
+  ввести под-флаг семантики паузы (независимый тумблер, по образцу `serial_gate_freeze_enabled`) и
+  область `*_repos` (CSV).
+- **Обратимость:** выставить под-флаг паузы в `False` → serial-gate работает как ORCH-088/090
+  (приостановленные снова считаются активными — т.е. возврат к текущему багу, но это осознанный
+  rollback-режим, не дефолт).
+- **never-raise / fail-direction (NFR-1):** сохранить fail-OPEN на hot-claim build и fail-CLOSED на
+  freeze; новая ветка паузы не инвертирует эти направления.
+- **Гармонизация предиката (NFR-4):** не сломать `task_deps`/`stages.py` терминальное множество
+  `{done,cancelled}` (ORCH-090/adr-0026); расхождение serial-gate (паузой) — только осознанно и
+  задокументированно в ADR.
+- **Артефакты pipeline:** обновляются `docs/architecture/README.md` (раздел serial-gate ORCH-088 +
+  семантика паузы), `CHANGELOG.md`, новый `docs/work-items/ORCH-124/06-adr/ADR-001-*.md` (архитектор),
+  при необходимости `08-data-requirements.md` (архитектор). Reviewer проверяет обновление доки (правило
+  агентов §6).