Merge pull request 'feat: ORCH-123-bug-staging-runner-assumes-doc' (#143) from feature/ORCH-123-bug-staging-runner-assumes-doc into main

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

.env.example

@@ -557,6 +557,34 @@ 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-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

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-112
+Work item: ORCH-115
 Repo: orchestrator
-Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
+Branch: feature/ORCH-115-orch-replace-llm-deployer-with
 Stage: development

CHANGELOG.md

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

CLAUDE.md

@@ -411,6 +411,88 @@ Plane, **не** Quality Gate и **не** стадия).
   `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`.
+
 ## Машинный журнал уроков (ORCH-098)
 Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
 **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих

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

@@ -96,6 +96,20 @@ 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`/схема БД не тронуты.
+
 ### 5. Auto-advance (`launcher._try_advance_stage`)
 
 После успешного завершения агента:

docs/architecture/llm-call-sites.md

@@ -58,7 +58,7 @@
 | **A3** | `.openclaw/agents/developer.md` | стадия `development` | developer | код + PR | — | `check_ci_green:82` (+ `check_branch_mergeable:657`) — CI/merge | ~150–400k / 10–40 мин | да (через S0) | **P** | `keep-LLM` | написание кода — настоящее суждение; гейт судит CI/merge, не самоотчёт |
 | **A4** | `.openclaw/agents/reviewer.md` | стадия `review` | reviewer | `12-review.md` | `verdict:` | `check_reviewer_verdict:336` (`verdict:`) | ~100–300k / 5–25 мин | да (через S0) | **C** | `keep-LLM` | control path, но вердикт «приемлемость кода/решения» **НЕ деривируем** из exit-кода — настоящее суждение |
 | **A5** | `.openclaw/agents/tester.md` | стадия `testing` | tester | `13-test-report.md` | `result:` | `check_tests_passed:182` → `_parse_tests_verdict:226` (`result:`) | ~60–150k / 5–20 мин | да (через S0) | **C** | `needs-hybrid-fallback` | **avoidable**: PASS/FAIL = exit-code `pytest`+smoke (деривируем); LLM нужен лишь на триаж падений / маппинг TC↔критерии |
-| **A6** | `.openclaw/agents/deployer.md` | стадии `deploy-staging` / `deploy` | deployer | `15-staging-log.md` / `14-deploy-log.md` | `staging_status:` / `deploy_status:` | `check_staging_status:599` → `_parse_staging_status:538` (`staging_status:`); `check_deploy_status:473` → `_parse_deploy_status:413` (`deploy_status:`) | ~40–120k / 3–15 мин | да (через S0) | **C** | `replace-deterministic-now` | **avoidable**: staging-вердикт = маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C (ORCH-036) |
+| **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 не консультируется |
 
@@ -147,8 +147,14 @@
 
 - **Docs + tests only (ORCH-118).** `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` /
   machine-verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
-  `coverage_status:`) / схема БД — **байт-в-байт не тронуты**. Раннеры замен **не** реализованы
+  `coverage_status:`) / схема БД — **байт-в-байт не тронуты** (это инвариант самой карты).
-  (см. roadmap — follow-up'ы по роли, без Plane-ID).
+- **Реализованные срезы.** Первый срез 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`) остаётся follow-up'ом по роли.
 - **Анти-дрейф тесты:** `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»**.

docs/architecture/llm-determinization-roadmap.md

@@ -15,7 +15,17 @@
 
 ---
 
-## 1. Рекомендованный первый срез — **deployer (staging-status)**
+## 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):
 

docs/architecture/llm-usage-policy.md

@@ -94,3 +94,8 @@ Call-site является **avoidable LLM control path** тогда и толь
   `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'а.

docs/operations/INFRA.md

@@ -244,10 +244,39 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 - **Свежесть 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,12 @@ 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).
+
 ## Человек как седьмая роль
 
 Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы

docs/overview/tech-pipeline.md

@@ -34,6 +34,16 @@ 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`).
+
 ## Под-гейты деплойного ребра — врезки, не стадии
 
 На переходе `deploy-staging → deploy` исполняются четыре под-гейта в нормативном порядке

docs/overview/tech-quality-security.md

@@ -50,7 +50,10 @@ LLM, и **нормативную политику** «LLM — только та
 control-path и его вердикт деривируем из exit-кодов (тогда консультацию можно заменить
 детерминированным раннером). Поимённо: avoidable = `{tester, deployer}`; настоящее суждение
 сохраняется у `{analyst, architect, developer, reviewer}`. Карта — снимок, прибитый структурными
-анти-дрейф тестами; реализация замен — отдельные follow-up'ы по роли.
+анти-дрейф тестами. **Первый срез реализован (ORCH-115):** на `deploy-staging` для self-hosting
+`orchestrator` LLM-`deployer` заменён детерминированным `src/staging_runner.py` (вердикт
+`staging_status:` = маппинг exit-кода staging-сюиты); LLM-ветвь остаётся fallback'ом, гейт
+`check_staging_status` не тронут. Замена второго кандидата (`tester`) — follow-up по роли.
 
 - Карта вызовов LLM: [`../architecture/llm-call-sites.md`](../architecture/llm-call-sites.md)
 - Нормативная политика: [`../architecture/llm-usage-policy.md`](../architecture/llm-usage-policy.md)

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-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.

src/agents/launcher.py

@@ -385,6 +385,14 @@ class AgentLauncher:
         (no-LLM) job — intercept it BEFORE _spawn (which would raise
         "Unknown agent", R-6) and run the deploy finalizer synchronously, driving
         the jobs row status itself. Returns None (no agent_run row).
+
+        ORCH-115: the LLM ``deployer`` on the ``deploy-staging`` stage (self-hosting
+        scope) is replaced by a DETERMINISTIC staging-runner — intercepted here
+        BEFORE _spawn (same precedent as deploy-finalizer / post-deploy-monitor). The
+        discriminator is the TASK STAGE (deploy-staging), not the role name, so the
+        prod ``deploy`` deployer is never caught (staging_runner.should_intercept).
+        Kill-switch off / out of scope -> should_intercept False -> the prior LLM
+        deployer runs via _spawn byte-for-byte.
         """
         if job.get("agent") == "deploy-finalizer":
             return self._run_deploy_finalizer_job(job)
@@ -393,6 +401,11 @@ class AgentLauncher:
         # observation tick synchronously. Returns None (no agent_run row).
         if job.get("agent") == "post-deploy-monitor":
             return self._run_post_deploy_monitor_job(job)
+        # ORCH-115: deterministic staging-runner intercept (BEFORE _spawn).
+        if job.get("agent") == "deployer":
+            from .. import staging_runner
+            if staging_runner.should_intercept(job):
+                return self._run_staging_runner_job(job)
         return self._spawn(
             job["agent"],
             job["repo"],
@@ -422,6 +435,28 @@ class AgentLauncher:
                 pass
         return None
 
+    def _run_staging_runner_job(self, job: dict):
+        """ORCH-115: run the deterministic staging gate for a deployer job.
+
+        Not an LLM spawn — there is no subprocess/monitor of an agent, so we mark the
+        jobs row done/failed here (mirror of _run_deploy_finalizer_job). The runner
+        never-raises, but we guard anyway so a runner fault can't wedge the worker.
+        Returns None (no agent_run row, _spawn not called).
+        """
+        from ..db import mark_job
+        from .. import staging_runner
+        try:
+            staging_runner.run_staging_gate(job)
+            mark_job(job["id"], "done")
+            logger.info(f"staging-runner job {job['id']} done")
+        except Exception as e:
+            logger.error(f"staging-runner job {job['id']} failed: {e}")
+            try:
+                mark_job(job["id"], "failed", error=f"staging-runner error: {e}")
+            except Exception:
+                pass
+        return None
+
     def _run_post_deploy_monitor_job(self, job: dict):
         """ORCH-021: run one deterministic post-deploy monitor tick for a job.
 

src/config.py

@@ -413,6 +413,68 @@ class Settings(BaseSettings):
     coverage_tool_fail_closed: bool = False
     coverage_run_timeout_s: int = 900
 
+    # ORCH-115: deterministic staging-runner replacing the LLM `deployer` agent on
+    # the `deploy-staging` stage for the self-hosting orchestrator. A new leaf
+    # src/staging_runner.py (never-raise) is intercepted in launch_job BEFORE _spawn
+    # (mirroring the deploy-finalizer / post-deploy-monitor reserved-agent
+    # precedent, launcher.py:389/394): it runs the SAME staging suite the LLM ran
+    # (`docker exec orchestrator-staging python3 .../staging_check.py`), maps the
+    # exit-code -> staging_status: via the existing self_deploy.map_exit_code_to_status
+    # contract, writes 15-staging-log.md, and initiates the EXISTING check_staging_status
+    # gate exactly as a finished LLM-deployer would. The artifact contract, the gate,
+    # STAGE_TRANSITIONS and the DB schema are byte-for-byte UNCHANGED — this only
+    # replaces the *producer* of the artifact. Pattern = coverage_gate_* / self_deploy_*.
+    # See docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md and
+    # docs/architecture/adr/adr-0048-deterministic-staging-runner.md.
+    #   staging_runner_enabled            -> SINGLE kill-switch (env
+    #                                        ORCH_STAGING_RUNNER_ENABLED). False -> the
+    #                                        intercept never fires -> the prior LLM
+    #                                        deployer runs on deploy-staging via _spawn
+    #                                        byte-for-byte as before ORCH-115 (D8/AC-6).
+    #   staging_runner_repos              -> CSV scope (env ORCH_STAGING_RUNNER_REPOS).
+    #                                        Empty -> self-hosting only (orchestrator)
+    #                                        via is_self_hosting_repo; non-empty ->
+    #                                        membership. Mirrors coverage_gate_repos.
+    #   staging_runner_timeout_s          -> wall-clock budget for the docker-exec
+    #                                        staging suite (env ORCH_STAGING_RUNNER_TIMEOUT_S).
+    #                                        Malformed/non-positive -> default + WARNING
+    #                                        (never-break). Aligned with the cross-cutting
+    #                                        budget invariant ORCH-065/109/110 WITHOUT
+    #                                        touching reaper_max_running_s (D9): it replaces
+    #                                        the up-to-900s LLM staging window with a bounded
+    #                                        <=600s deterministic one (Σ on the edge does not grow).
+    #   staging_runner_infra_max_retries  -> tool-error (suite did NOT execute: spawn-error /
+    #                                        timeout / returncode None) bounded DEFER budget
+    #                                        before a fail-closed FAILED (env
+    #                                        ORCH_STAGING_RUNNER_INFRA_MAX_RETRIES). Mirrors
+    #                                        merge_retest_infra_max_retries — infra hiccup is
+    #                                        NOT a code-fault, so it never burns a developer-retry
+    #                                        until the budget is exhausted (D5, anti ORCH-110).
+    #   staging_runner_infra_retry_delay_s-> delay before the re-queued deployer job
+    #                                        (env ORCH_STAGING_RUNNER_INFRA_RETRY_DELAY_S).
+    # ORCH-123 (D6, adr-0049): the staging suite (`docker exec orchestrator-staging
+    # ... staging_check.py`) MUST run host-side over the existing trusted ssh channel
+    # (ORCH-036/058), because the prod container ships only `openssh-client git curl`
+    # — NOT a `docker` CLI (Dockerfile:11) — so `docker exec` spawned FROM INSIDE the
+    # prod container hit FileNotFoundError -> a permanent environment defect that
+    # ORCH-115 mis-routed as a code-fail rollback (incident ORCH-116). The execution
+    # CHANNEL changes (host-side ssh wrap), the suite COMMAND/contract does not.
+    #   staging_runner_exec_host_side -> True (default = boevoe) wraps the docker-exec
+    #                                    in `ssh <deploy_ssh_user>@<deploy_ssh_host>
+    #                                    '<docker exec ...>'` (mirror self_deploy /
+    #                                    image_freshness host-side docker). False ->
+    #                                    the prior in-container `docker exec` (valid
+    #                                    ONLY where a docker CLI is baked into the
+    #                                    image; the current prod image has none). env
+    #                                    ORCH_STAGING_RUNNER_EXEC_HOST_SIDE. Rollback:
+    #                                    set False -> the prior in-container call 1:1.
+    staging_runner_enabled: bool = True
+    staging_runner_repos: str = ""
+    staging_runner_timeout_s: int = 600
+    staging_runner_infra_max_retries: int = 2
+    staging_runner_infra_retry_delay_s: int = 30
+    staging_runner_exec_host_side: bool = True
+
     # ORCH-098 (FND/F2): machine lessons-journal — additive `lessons` table + leaf
     # src/lessons.py (never-raise observer, by образцу serial_gate/coverage_gate/
     # metrics). The journal is an OBSERVER, never a Quality Gate: writing a lesson

src/main.py

@@ -79,6 +79,21 @@ async def lifespan(app: FastAPI):
     except Exception as e:
         log.warning(f"Transition-lease recovery skipped: {e}")
 
+    # ORCH-123 (adr-0049 / D5 / FR-4): prod-like preflight of the host-side staging
+    # execution channel. The deploy-staging staging-runner (ORCH-115) runs the suite
+    # HOST-SIDE over ssh because the prod container ships no docker CLI (Dockerfile:11);
+    # probe the channel at startup so a broken environment (no docker on host / staging
+    # down / ssh unreachable / no ssh target) surfaces HERE — not postfactum as a false
+    # rollback of a real task (incident ORCH-116). Purely observational: it never blocks
+    # the start / gates the pipeline. never raises (runs after requeue + lease-recovery).
+    try:
+        from . import staging_runner
+        ok, reason = staging_runner.preflight()
+        if not ok:
+            log.warning(f"Staging-runner preflight: {reason}")
+    except Exception as e:
+        log.warning(f"Staging-runner preflight skipped: {e}")
+
     # ORCH-065: proactive startup reclaim of dead/stale merge-leases, next to the
     # queue-recovery above. A lease held by the previous (now dead) process pid is
     # released at once instead of waiting for the TTL / a foreign acquire so the
@@ -235,6 +250,7 @@ async def queue():
     from . import lessons
     from . import checkout_hygiene
     from . import transition_lease
+    from . import staging_runner
     from .disk_watchdog import disk_watchdog
     from .build_cache_pruner import build_cache_pruner
     return {
@@ -283,6 +299,11 @@ async def queue():
         # (owner/stage/age/live) + defer/reclaim/CAS-lost counters. Additive block;
         # never-raise.
         "transition_lease": transition_lease.snapshot(),
+        # ORCH-115 (FR-7 / AC-10): deterministic staging-runner observability
+        # (read-only) — kill-switch, scope, timeout/infra budget + run/success/
+        # failed/tool_error/deferred counters, so a code-fail FAILED is distinguishable
+        # from an infra tool-error. Additive block; never-raise.
+        "staging_runner": staging_runner.snapshot(),
         # ORCH-098 (FR-4 / AC-4): lessons-journal observability (read-only) —
         # kill-switch + counts by type/status + last N lessons. Additive block;
         # never-raise (snapshot() returns {"enabled": ...} minimum on error).

src/staging_runner.py

@@ -0,0 +1,861 @@
+"""Deterministic staging-runner (ORCH-115).
+
+The `deploy-staging` stage for the self-hosting ``orchestrator`` repo was driven by
+the LLM ``deployer`` agent, but the actual work is purely deterministic
+(``.openclaw/agents/deployer.md`` steps 1-4): run the staging suite, map its
+**exit-code** to a verdict (``0 -> SUCCESS``, else ``FAILED``), write
+``15-staging-log.md`` and commit it. This leaf replaces that LLM consultation with
+deterministic code, intercepted in ``launcher.launch_job`` BEFORE ``_spawn`` (the
+``deploy-finalizer`` / ``post-deploy-monitor`` reserved-agent precedent,
+``launcher.py:389/394``).
+
+What is and is NOT changed (NFR-1, the critical invariant):
+  * UNCHANGED — the artifact contract (``15-staging-log.md`` with
+    ``staging_status: SUCCESS|FAILED``), the gate ``check_staging_status`` /
+    ``_parse_staging_status``, ``STAGE_TRANSITIONS``, the DB schema. This module
+    replaces only the *producer* of the artifact, never the gate that reads it.
+  * NEW — a deterministic producer + a launch_job intercept. Under a kill-switch +
+    repo-scope CSV; fail-safe back to the LLM path when off / out of scope.
+
+This module is a **leaf** (mirror of ``self_deploy`` / ``proc_group`` /
+``staging_verdict``): it imports only ``config`` / ``logging`` / ``proc_group`` at
+module load; ``db`` / ``git_worktree`` / ``self_deploy.map_exit_code_to_status`` /
+``qg.checks`` / ``stage_engine.advance_stage`` / ``notifications`` are imported
+LAZILY inside functions so the heavy ``stage_engine`` is never pulled at import and
+no import cycle forms (pattern: ``transition_lease`` / ``merge_gate``). Every public
+function honours a **never-raise** contract (AC-7): a staging-infra hiccup can never
+crash the worker / wedge the queue.
+
+Two-level outcome (D5 — the key safety decision, anti ORCH-110):
+  * the suite EXECUTED (a real exit-code, 0 or non-zero) -> trust the code:
+    ``0 -> SUCCESS -> advance``; ``!=0 -> FAILED -> the existing rollback
+    deploy-staging -> development`` (same developer-retry path as a FAILED LLM
+    verdict). ORCH-061 infra-tolerance is already INSIDE ``staging_check.py`` — the
+    runner never re-judges it (BR-4).
+  * the suite did NOT execute (tool-error: spawn-error / timeout / ``returncode is
+    None``) -> an infra fault, NOT a code fault -> a bounded DEFER (re-queue a fresh
+    ``deployer`` job with a delay + a restart-safe marker). On budget exhaustion ->
+    fail-closed ``FAILED`` + advance + alert. So the runner NEVER does a silent
+    advance / false green, and NEVER wedges the queue, but does NOT burn a
+    developer-retry on transient infra.
+"""
+
+import logging
+import shlex
+import subprocess
+import time
+
+from .config import settings
+from . import proc_group
+
+logger = logging.getLogger("orchestrator.staging_runner")
+
+# Platform service literal — the staging compose service the suite runs inside.
+# Already an accepted platform literal (mirror image_freshness._STAGING_SERVICE);
+# NOT a host hardcode (test_no_host_hardcodes forbids host IP/home/hostname only).
+STAGING_SERVICE = "orchestrator-staging"
+
+# ORCH-123 (D3): deterministic stderr markers that prove a PERMANENT environment
+# defect (no docker / container down / daemon unreachable) — NOT a transient infra
+# hiccup and NEVER a code-fail. Scanned lower-cased; mirror of merge_gate's
+# scope-guard marker approach. Recognised suite exit-codes WITHOUT any of these
+# markers are always trusted as `suite-ran` (anti-over-tolerance, BR-3).
+_ENV_MARKERS = (
+    "command not found",
+    "executable file not found",
+    "no such container",
+    "is not running",
+    "cannot connect to the docker daemon",
+    "is the docker daemon running",
+)
+
+# ORCH-123 (D5): last prod-like preflight verdict of the host-side staging channel
+# (observed at startup; surfaced in snapshot()). `ok=None` -> not probed / n/a.
+_PREFLIGHT_STATE: dict = {"ok": None, "reason": "not-probed"}
+_PREFLIGHT_TIMEOUT_S = 20
+
+# Default wall-clock budget for the docker-exec staging suite (D9). Kept <= the LLM
+# staging window it replaces so Σ(work on the deploy-staging edge) does not grow and
+# the cross-cutting reaper invariant (ORCH-065/109/110) holds WITHOUT touching
+# reaper_max_running_s.
+_DEFAULT_TIMEOUT_S = 600
+
+_GIT_TIMEOUT = 60
+
+# Restart-safe DEFER marker (counted from the persisted jobs queue, mirror of
+# stage_engine._merge_infra_retry_count). Embedded verbatim in the re-queued job's
+# task_content so a service restart never resets the infra-retry budget.
+_INFRA_RETRY_MARKER = "staging-runner infra-retry"
+
+# In-process observability counters (mirror merge_gate._MERGE_GATE_COUNTERS, ORCH-110).
+# ORCH-123 (D8): `failed` now counts ONLY a real code-fail (suite ran, exit != 0);
+# `permanent_env` counts infra-HOLD events (a permanent environment defect, OR a
+# transient-infra DEFER budget exhausted) so /queue distinguishes the THREE
+# non-success classes: code-fail (`failed`) vs transient-infra (`deferred`) vs
+# permanent-env / infra-HOLD (`permanent_env`).
+_STAGING_RUNNER_COUNTERS: dict = {
+    "runs": 0,          # run_staging_gate entered
+    "success": 0,       # suite ran, exit 0 -> SUCCESS
+    "failed": 0,        # suite ran non-zero -> FAILED (a real code-fail)
+    "tool_error": 0,    # suite did NOT execute (spawn-error / timeout / None)
+    "deferred": 0,      # bounded transient-infra DEFER (re-queued)
+    "permanent_env": 0, # infra-HOLD: permanent env defect OR transient budget exhausted
+}
+
+
+def _bump(key: str) -> None:
+    """Increment an observability counter. Never raises."""
+    try:
+        _STAGING_RUNNER_COUNTERS[key] += 1
+    except Exception:  # noqa: BLE001 - observability must never break a decision
+        pass
+
+
+# ---------------------------------------------------------------------------
+# Conditionality (D8 / FR-6 / AC-6)
+# ---------------------------------------------------------------------------
+def applies(repo: str) -> bool:
+    """Whether the deterministic staging-runner is REAL for ``repo``.
+
+    Mirrors ``self_deploy_applies`` / ``coverage_gate``:
+      * ``staging_runner_enabled=False`` -> always False (global kill-switch); the
+        legacy LLM-deployer path runs on deploy-staging via ``_spawn``.
+      * ``staging_runner_repos`` (CSV) non-empty -> only the listed repos.
+      * empty CSV -> only the self-hosting repo (``orchestrator``), which is the only
+        one with a staging instance.
+    Checked FIRST in ``should_intercept`` (local, no network, no DB) so a disabled
+    flag costs nothing. never-raise -> False (fail-safe to the prior LLM path).
+    """
+    try:
+        if not settings.staging_runner_enabled:
+            return False
+        raw = (settings.staging_runner_repos or "").strip()
+        if raw:
+            allowed = {r.strip().lower() for r in raw.split(",") if r.strip()}
+            return (repo or "").strip().lower() in allowed
+        # Lazy import keeps this module a leaf (no qg import at module load).
+        from .qg.checks import is_self_hosting_repo
+        return is_self_hosting_repo(repo)
+    except Exception as e:  # noqa: BLE001 - never-raise contract
+        logger.warning("staging_runner.applies error for %s: %s", repo, e)
+        return False
+
+
+def should_intercept(job: dict) -> bool:
+    """True iff this ``deployer`` job is the deterministic staging-suite job (D1).
+
+    The discriminator of "staging vs prod" is the TASK STAGE, not the role name
+    (``deployer`` owns both ``deploy-staging`` and ``deploy``): intercept iff
+    ``agent == "deployer"`` AND the task's ``tasks.stage == "deploy-staging"`` AND
+    ``applies(repo)``. For self-hosting the prod ``deploy`` edge runs Phase A (no
+    deployer spawn); for non-self repos ``applies`` is False, so a non-self prod
+    ``deployer`` job is never intercepted (R-1 / TC-06).
+
+    never-raise -> False (a DB-lookup failure falls through to ``_spawn``, fail-safe
+    to the prior LLM path).
+    """
+    try:
+        if (job.get("agent") or "") != "deployer":
+            return False
+        # applies() FIRST (local, no DB): disabled flag -> zero DB overhead.
+        if not applies(job.get("repo")):
+            return False
+        task_id = job.get("task_id")
+        if task_id is None:
+            return False
+        from .db import get_db
+        conn = get_db()
+        row = conn.execute("SELECT stage FROM tasks WHERE id=?", (task_id,)).fetchone()
+        conn.close()
+        if not row:
+            return False
+        return (row[0] or "") == "deploy-staging"
+    except Exception as e:  # noqa: BLE001 - never-raise contract
+        logger.warning("staging_runner.should_intercept error: %s", e)
+        return False
+
+
+# ---------------------------------------------------------------------------
+# Suite execution (D3 / FR-2 / NFR-3 / AC-8 / AC-9)
+# ---------------------------------------------------------------------------
+def _ssh_target() -> str:
+    """ssh ``user@host`` for host-side execution, or ``""`` when no host is
+    configured (mirror ``self_deploy``/``image_freshness._ssh_target``). On the prod
+    host ``ORCH_DEPLOY_SSH_HOST=127.0.0.1`` is set by compose; the config default is
+    empty so tests / non-self contexts fall back to the in-container command."""
+    host = (settings.deploy_ssh_host or "").strip()
+    if not host:
+        return ""
+    user = (settings.deploy_ssh_user or "").strip()
+    return f"{user}@{host}" if user else host
+
+
+def _channel_ssh_configured() -> bool:
+    """Whether the execution channel is viable w.r.t. ssh config (fed to
+    ``classify_staging_outcome``). In-container mode (host-side disabled) is always
+    'configured' — its viability is decided purely by the result signals; host-side
+    mode needs a non-empty ssh target (R-6: an empty target -> ``permanent-env``).
+    never-raise -> assume configured (rely on the result signals)."""
+    try:
+        if not bool(getattr(settings, "staging_runner_exec_host_side", True)):
+            return True
+        return bool(_ssh_target())
+    except Exception:  # noqa: BLE001 - never-raise
+        return True
+
+
+def build_staging_command() -> list[str]:
+    """Build the staging-suite argv (same suite command the LLM-deployer ran).
+
+    The INNER command is unchanged: ``docker exec <STAGING_SERVICE> python3
+    <repos_dir>/<self-repo>/scripts/staging_check.py --base-url
+    http://localhost:<staging_port> --mode stub``. Host-specifics come from config
+    (ORCH-101, no host hardcodes).
+
+    ORCH-123 (D1, adr-0049): ``docker`` lives on the HOST — the prod container ships
+    only ``openssh-client git curl`` (``Dockerfile:11``), so a ``docker exec`` spawned
+    FROM INSIDE the prod container hit ``FileNotFoundError`` (incident ORCH-116). When
+    ``staging_runner_exec_host_side`` (default True) is set AND an ssh target is
+    configured, the inner command is wrapped in ``ssh <user@host> '<docker exec ...>'``
+    so it runs host-side over the existing trusted ssh channel (mirror
+    ``self_deploy.build_deploy_command`` / ``image_freshness.image_revision``). With
+    the flag off OR no ssh target configured (tests / non-self contexts) it falls back
+    to the prior in-container ``docker exec`` (valid only where a docker CLI is baked
+    into the image).
+
+    Self-hosting safety (BR-7 / AC-8 / TC-08): the argv carries ONLY ``docker exec
+    <staging-service> python3 staging_check.py ... --mode stub`` — NO restart of 8500,
+    NO ``docker compose up orchestrator`` / ``--build``, NO force-push, NO ``.env``
+    edit. The runner only reads/executes the staging suite (8501) and writes a log.
+    """
+    from .qg.checks import SELF_HOSTING_REPO
+    repos_dir = (settings.repos_dir or "/repos").rstrip("/")
+    script = f"{repos_dir}/{SELF_HOSTING_REPO}/scripts/staging_check.py"
+    base_url = f"http://localhost:{int(settings.staging_port)}"
+    inner_argv = [
+        "docker", "exec", STAGING_SERVICE,
+        "python3", script,
+        "--base-url", base_url,
+        "--mode", "stub",
+    ]
+    # ORCH-123 (D1): host-side ssh-wrap when enabled AND a target is configured.
+    if bool(getattr(settings, "staging_runner_exec_host_side", True)):
+        target = _ssh_target()
+        if target:
+            remote = " ".join(shlex.quote(a) for a in inner_argv)
+            return ["ssh", "-o", "StrictHostKeyChecking=no", target, remote]
+    # Fallback: prior in-container docker exec (no ssh target / flag off).
+    return inner_argv
+
+
+def _resolve_timeout() -> int:
+    """Resolve ``staging_runner_timeout_s`` (malformed/non-positive -> default +
+    WARNING, never-break — mirror of ``merge_gate._resolve_retest_timeout``)."""
+    raw = getattr(settings, "staging_runner_timeout_s", _DEFAULT_TIMEOUT_S)
+    try:
+        t = int(raw)
+        if t > 0:
+            return t
+        logger.warning(
+            "staging_runner_timeout_s non-positive (%r) -> default %ds",
+            raw, _DEFAULT_TIMEOUT_S,
+        )
+    except (TypeError, ValueError):
+        logger.warning(
+            "staging_runner_timeout_s malformed (%r) -> default %ds",
+            raw, _DEFAULT_TIMEOUT_S,
+        )
+    return _DEFAULT_TIMEOUT_S
+
+
+def run_staging_suite() -> proc_group.ProcResult:
+    """Execute the staging suite in its own process group, tree-killed on timeout.
+
+    Reuses ``proc_group.run_in_process_group`` (ORCH-110) so a hung docker-exec /
+    pytest subtree is killed whole (no orphans, AC-9). Never raises (proc_group
+    degrades any OS error to a safe ``ProcResult``).
+    """
+    cmd = build_staging_command()
+    timeout = _resolve_timeout()
+    try:
+        grace = float(getattr(settings, "agent_kill_grace_seconds", 5) or 5)
+    except (TypeError, ValueError):
+        grace = 5.0
+    return proc_group.run_in_process_group(
+        cmd,
+        cwd=None,
+        timeout=timeout,
+        grace_s=grace,
+        tree_kill=bool(getattr(settings, "subprocess_tree_kill_enabled", True)),
+    )
+
+
+# ---------------------------------------------------------------------------
+# exit-code -> verdict (D4 / FR-3 / AC-3) — reuse the single contract, no 2nd mapping
+# ---------------------------------------------------------------------------
+def map_exit_code_to_status(exit_code) -> str:
+    """``0 -> SUCCESS``; non-zero / None / non-int -> ``FAILED`` (fail-closed).
+
+    Delegates to ``self_deploy.map_exit_code_to_status`` — the SAME pure, unit-tested
+    contract the deploy-finalizer uses (BR-4: no second, drifting mapping).
+    """
+    from .self_deploy import map_exit_code_to_status as _map
+    return _map(exit_code)
+
+
+# ---------------------------------------------------------------------------
+# Three-way outcome classification (D3 / FR-2 / FR-3 / AC-3, AC-4, AC-6)
+# ---------------------------------------------------------------------------
+def classify_staging_outcome(result, ssh_configured: bool) -> str:
+    """Classify a staging-suite ProcResult into one of three classes (D3). Pure,
+    never-raise (mirror of ``merge_gate.classify_retest_failure``, ORCH-110 D2):
+
+      * ``"suite-ran"``       — a recognised executor exit-code (any int except the
+                                ssh transport code 255) AND no environment marker in
+                                stderr: the suite DEMONSTRABLY executed -> trust the
+                                code (``0->SUCCESS``, ``!=0->FAILED``). Anti-over-
+                                tolerance (BR-3): a real suite fail is NEVER
+                                reclassified as infra/env.
+      * ``"permanent-env"``   — a deterministic PERMANENT environment defect: an
+                                stderr env-marker (no docker / no such container /
+                                daemon unreachable), a shell "command not found /
+                                cannot execute" code (126/127), no host-side ssh
+                                target configured, or a bare local spawn-error
+                                (``returncode is None`` and not a timeout). Retrying is
+                                pointless (FR-3) -> immediate distinguishable
+                                infra-HOLD (no rollback, no developer-retry).
+      * ``"transient-infra"`` — a timeout OR an ssh transport/connection failure (255)
+                                OR any unknown signal: a retry is meaningful -> the
+                                bounded DEFER.
+
+    The exit=1 collision (``docker exec`` "No such container"=1 vs a real suite fail=1)
+    is disambiguated by SCANNING stderr for env-markers, NEVER by the bare exit-code.
+    Fail-safe on doubt -> ``"transient-infra"`` (DEFER), never a silent ``"suite-ran"``
+    (a mis-routed environment->code-fail is exactly the defect this fixes; an over-
+    tolerated code-fail is guarded by trusting recognised suite exit-codes first).
+    """
+    try:
+        rc = getattr(result, "returncode", None)
+        timed_out = bool(getattr(result, "timed_out", False))
+        stderr = (getattr(result, "stderr", "") or "").lower()
+
+        # 1. env-marker in stderr -> permanent, REGARDLESS of the exit-code (this is
+        #    what disambiguates a `docker exec` "No such container" exit=1 from a real
+        #    suite fail=1 — R-3).
+        if any(m in stderr for m in _ENV_MARKERS):
+            return "permanent-env"
+        # 2. shell "command not found" (127) / "cannot execute" (126) -> permanent.
+        if rc in (126, 127):
+            return "permanent-env"
+        # 3. a recognised executor exit-code (any int except the ssh transport code
+        #    255) WITHOUT an env-marker -> the suite executed; trust it (BR-3). This is
+        #    checked BEFORE the channel guards so a real suite fail is never masked.
+        if isinstance(rc, int) and rc != 255:
+            return "suite-ran"
+        # --- below this line the suite did NOT produce a trustworthy exit-code ---
+        # 4. timeout / ssh transport failure (255) -> transient: a retry is meaningful.
+        if timed_out or rc == 255:
+            return "transient-infra"
+        # 5. host-side ssh target missing (R-6) OR a bare local spawn-error (proc_group
+        #    degraded an OSError to rc None without a timeout) -> permanent env defect.
+        if not ssh_configured:
+            return "permanent-env"
+        if rc is None:
+            return "permanent-env"
+        # 6. unknown signal -> fail-safe DEFER (never a silent suite-ran).
+        return "transient-infra"
+    except Exception:  # noqa: BLE001 - never-raise; unknown -> transient (no false rollback)
+        return "transient-infra"
+
+
+# ---------------------------------------------------------------------------
+# Artifact 15-staging-log.md (D6 / FR-4 / AC-2 / AC-8) — mirror write_deploy_log
+# ---------------------------------------------------------------------------
+def _extract_infra_waived(stdout: str) -> list[str]:
+    """Lines from the suite stdout carrying the ORCH-061 ``INFRA-WAIVED:`` marker
+    (copied into the log body for observability, as the prompt required)."""
+    if not stdout:
+        return []
+    return [ln.strip() for ln in stdout.splitlines() if "INFRA-WAIVED" in ln]
+
+
+def build_staging_log(
+    work_item_id: str, exit_code, status: str, stdout: str = "", *, tool_error: bool = False
+) -> str:
+    """Render a ``15-staging-log.md`` body whose ``staging_status:`` frontmatter is the
+    verdict ``check_staging_status`` / ``_parse_staging_status`` reads (contract
+    UNCHANGED, AC-2). Carries the mandatory 52c schema (``work_item`` / ``stage`` /
+    ``author_agent`` / ``status`` / ``created_at`` / ``model_used``); ``author_agent:
+    staging-runner`` / ``model_used: n/a`` honestly reflect the DETERMINISTIC producer.
+    The machine key ``staging_status:`` and its UPPERCASE value are NOT changed.
+
+    Written as a literal block (mirror of ``self_deploy.build_deploy_log``) so the
+    machine-read frontmatter is byte-exact; only the frontmatter is machine-read, the
+    body is informational.
+    """
+    import datetime
+    created = datetime.date.today().isoformat()
+    sub_status = "success" if status == "SUCCESS" else "failed"
+    base_url = f"http://localhost:{int(settings.staging_port)}"
+
+    waived = _extract_infra_waived(stdout)
+    waived_body = ""
+    if waived:
+        waived_body = "\nINFRA-WAIVED lines (ORCH-061, copied for observability):\n" + "\n".join(
+            f"- {ln}" for ln in waived
+        ) + "\n"
+
+    tail = ""
+    if stdout:
+        tail_text = stdout.strip()[-1500:]
+        if tail_text:
+            tail = f"\nStaging suite stdout (tail):\n```\n{tail_text}\n```\n"
+
+    note = (
+        "Staging suite did NOT execute (tool-error) and the infra-retry budget was "
+        "exhausted -> fail-closed FAILED."
+        if tool_error
+        else f"Staging suite exit-code `{exit_code}` -> `staging_status: {status}`."
+    )
+
+    return (
+        "---\n"
+        f"staging_status: {status}\n"
+        f"work_item: {work_item_id}\n"
+        "stage: deploy-staging\n"
+        "author_agent: staging-runner\n"
+        f"status: {sub_status}\n"
+        f"created_at: {created}\n"
+        "model_used: n/a\n"
+        f"exit_code: {exit_code}\n"
+        f"base_url: {base_url}\n"
+        "---\n\n"
+        "# Staging Gate Log (deterministic runner, ORCH-115)\n\n"
+        f"{note}\n\n"
+        "Вердикт зафиксирован детерминированным staging-раннером (ORCH-115), не LLM. "
+        "infra-tolerance (ORCH-061) уже учтена внутри `staging_check.py` — раннер её не "
+        "пересуживает.\n"
+        f"{waived_body}"
+        f"{tail}"
+    )
+
+
+def write_staging_log(
+    repo: str, work_item_id: str, branch: str, exit_code, status: str,
+    stdout: str = "", *, tool_error: bool = False,
+) -> bool:
+    """Write ``15-staging-log.md`` into the task worktree (so ``check_staging_status``
+    reads it) and best-effort commit+push it to the FEATURE BRANCH. Returns True iff
+    the file was written. Never raises.
+
+    Mirror of ``self_deploy.write_deploy_log`` EXCEPT: the actor name is
+    ``staging-runner`` and the log is pushed only to the feature branch — there is NO
+    separate PR-merge of the log into ``main`` (the gate reads the worktree first;
+    excluding any direct work on ``main`` strengthens AC-8 / BR-7). The feature branch
+    is merged into ``main`` later by the normal merge-gate path.
+    """
+    import os
+    import subprocess
+    from .git_worktree import get_worktree_path
+
+    rel = f"docs/work-items/{work_item_id}/15-staging-log.md"
+    try:
+        wt = get_worktree_path(repo, branch)
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.error("write_staging_log: worktree error for %s/%s: %s", repo, branch, e)
+        return False
+
+    path = os.path.join(wt, rel)
+    content = build_staging_log(work_item_id, exit_code, status, stdout, tool_error=tool_error)
+    try:
+        os.makedirs(os.path.dirname(path), exist_ok=True)
+        with open(path, "w", encoding="utf-8") as f:
+            f.write(content)
+    except OSError as e:
+        logger.error("write_staging_log: write error at %s: %s", path, e)
+        return False
+
+    # Best-effort commit + push to the feature branch (the gate also falls back to
+    # origin/main). ORCH-101: HOME + email domain from Settings; the actor NAME stays
+    # the platform literal `staging-runner` (deterministic system-actor commits).
+    _email = f"staging-runner@{settings.git_email_domain}"
+    git_env = {
+        **os.environ,
+        "HOME": settings.agent_home_dir,
+        "GIT_AUTHOR_NAME": "staging-runner",
+        "GIT_AUTHOR_EMAIL": _email,
+        "GIT_COMMITTER_NAME": "staging-runner",
+        "GIT_COMMITTER_EMAIL": _email,
+    }
+    try:
+        subprocess.run(["git", "-C", wt, "add", rel],
+                       capture_output=True, timeout=_GIT_TIMEOUT, env=git_env)
+        commit = subprocess.run(
+            ["git", "-C", wt, "commit", "-m",
+             f"staging(ORCH-115): staging gate {status} for {work_item_id}"],
+            capture_output=True, text=True, timeout=_GIT_TIMEOUT, env=git_env,
+        )
+        if commit.returncode == 0:
+            subprocess.run(["git", "-C", wt, "push", "origin", branch],
+                           capture_output=True, timeout=_GIT_TIMEOUT, env=git_env)
+    except (subprocess.SubprocessError, OSError) as e:
+        logger.warning("write_staging_log: git commit/push best-effort failed: %s", e)
+    return True
+
+
+# ---------------------------------------------------------------------------
+# Existing-gate initiation (D7 / FR-5 / AC-4) — no new routing branch
+# ---------------------------------------------------------------------------
+def _advance(task_id, repo: str, work_item_id: str, branch: str) -> None:
+    """Initiate the SAME ``advance_stage`` evaluation a finished LLM-deployer would
+    (``finished_agent="deployer"`` on ``deploy-staging``): SUCCESS -> sub-gates
+    security->merge->coverage->image-freshness (ORCH-022/043/027/058) + Phase A
+    (ORCH-036); FAILED -> the existing rollback deploy-staging -> development
+    (``stage_engine.py:932``). No new routing branch. The transition-lease (ORCH-114)
+    is taken INSIDE advance_stage on the side-effectful edge — the runner never
+    touches it (task boundary O1). never-raise."""
+    try:
+        from . import stage_engine
+        stage_engine.advance_stage(
+            task_id=task_id,
+            current_stage="deploy-staging",
+            repo=repo,
+            work_item_id=work_item_id,
+            branch=branch,
+            finished_agent="deployer",
+        )
+    except Exception as e:  # noqa: BLE001 - never-raise into the worker
+        logger.error(
+            "staging_runner._advance: advance_stage failed for task %s (%s): %s",
+            task_id, work_item_id, e,
+        )
+
+
+# ---------------------------------------------------------------------------
+# Two-level outcome (D5) — tool-error DEFER bookkeeping
+# ---------------------------------------------------------------------------
+def _infra_retry_count(task_id) -> int:
+    """How many times this task was re-queued by the tool-error DEFER path
+    (restart-safe; counted from the persisted jobs queue by the marker — mirror of
+    ``stage_engine._merge_infra_retry_count``). Never raises -> 0 on error."""
+    try:
+        from .db import get_db
+        conn = get_db()
+        n = conn.execute(
+            "SELECT COUNT(*) FROM jobs WHERE task_id=? AND task_content LIKE ?",
+            (task_id, f"%{_INFRA_RETRY_MARKER}%"),
+        ).fetchone()[0]
+        conn.close()
+        return int(n)
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.warning("staging_runner._infra_retry_count error for %s: %s", task_id, e)
+        return 0
+
+
+def _handle_transient_infra(
+    task_id, repo: str, work_item_id: str, branch: str, result: proc_group.ProcResult
+) -> None:
+    """Transient infra (timeout / ssh transport) — the suite did not execute but a
+    retry is meaningful (D4). Bounded DEFER: re-queue a fresh ``deployer`` job (which
+    re-enters this runner) with a delay + a restart-safe marker, instead of an
+    immediate rollback that would burn a developer-retry.
+
+    On budget exhaustion -> **infra-HOLD + alert** (D4, SUPERSEDES ORCH-115 D5): NOT
+    the prior fail-closed ``write_staging_log("FAILED") + advance``, which falsely
+    rolled an unresolved infra hiccup back to ``development`` as a code-fail (BR-2,
+    anti-pattern ORCH-110). The task is HELD on ``deploy-staging`` (a red/missing gate
+    keeps the reconciler's ``advance_if_gate_passed`` from rolling it back — R-2); the
+    operator re-drives it after fixing the stand. Never a silent advance / false green;
+    never wedges the queue. never-raise."""
+    retries = _infra_retry_count(task_id)
+    try:
+        max_retries = int(settings.staging_runner_infra_max_retries)
+    except (TypeError, ValueError):
+        max_retries = 2
+    try:
+        delay = int(settings.staging_runner_infra_retry_delay_s)
+    except (TypeError, ValueError):
+        delay = 30
+
+    if retries < max_retries:
+        _bump("deferred")
+        reason = "timeout" if result.timed_out else "ssh transport/connection error"
+        task_desc = (
+            f"Work item: {work_item_id}\nRepo: {repo}\nBranch: {branch}\n"
+            f"Stage: deploy-staging\nNote: {_INFRA_RETRY_MARKER} "
+            f"(attempt {retries + 1}/{max_retries}) — {reason}, retrying after {delay}s."
+        )
+        try:
+            from .db import enqueue_job
+            new_job = enqueue_job(
+                "deployer", repo, task_desc, task_id=task_id, available_at_delay_s=delay,
+            )
+            logger.warning(
+                "Task %s (%s): staging suite did not execute (%s) -> transient-infra "
+                "DEFER (job_id=%s, attempt %d/%d)",
+                task_id, work_item_id, reason, new_job, retries + 1, max_retries,
+            )
+        except Exception as e:  # noqa: BLE001 - never-raise
+            logger.error("staging_runner: infra-DEFER enqueue failed for %s: %s", task_id, e)
+        return
+
+    # Budget exhausted -> infra-HOLD (D4): NO write_staging_log("FAILED"), NO advance,
+    # NO developer-retry. The task is held on deploy-staging for the operator.
+    _bump("permanent_env")
+    logger.error(
+        "Task %s (%s): staging transient-infra DEFER budget exhausted (%d) -> "
+        "infra-HOLD on deploy-staging (NOT a code defect, no rollback)",
+        task_id, work_item_id, max_retries,
+    )
+    _alert_infra_exhausted(work_item_id, max_retries)
+
+
+def _handle_permanent_env(
+    task_id, repo: str, work_item_id: str, branch: str, result: proc_group.ProcResult
+) -> None:
+    """Permanent environment defect (D4): an immediate, distinguishable infra-HOLD.
+
+    The DEFER cycle is SKIPPED — retrying a permanent defect (no docker / no ssh
+    target / container down) is pointless (FR-3). We do NOT write a FAILED staging-log,
+    do NOT advance, do NOT burn a developer-retry — the task is HELD on
+    ``deploy-staging``: a red/missing ``check_staging_status`` keeps the reconciler's
+    ``advance_if_gate_passed`` from rolling it back to ``development`` (R-2), and the
+    rollback-to-development path (``advance_stage(finished_agent="deployer")``) is never
+    taken. A structured error log + an operator alert ("infra/environment, NOT a code
+    defect") make the hold visible; the operator re-drives after fixing the
+    environment. never-raise."""
+    detail = (getattr(result, "stderr", "") or "").strip()[:300]
+    logger.error(
+        "Task %s (%s): PERMANENT staging environment defect -> infra-HOLD on "
+        "deploy-staging (NOT a code defect, no rollback, no developer-retry): %s",
+        task_id, work_item_id, detail or "<no stderr>",
+    )
+    _alert_permanent_env(work_item_id, detail)
+
+
+def _alert_infra_exhausted(work_item_id: str, max_retries: int) -> None:
+    """Best-effort Telegram alert that the staging suite never executed (infra, NOT a
+    code defect) after the retry budget -> infra-HOLD (no rollback). never-raise."""
+    try:
+        from .notifications import send_telegram, link_for
+        send_telegram(
+            f"\U0001f6a8 {link_for(work_item_id)}: staging-сюита не запустилась "
+            f"(инфра, НЕ дефект кода) после {max_retries} попыток — задача удержана на "
+            f"deploy-staging (без отката на development). Нужно проверить staging-стенд."
+        )
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.warning("staging_runner: infra-exhausted alert failed for %s: %s", work_item_id, e)
+
+
+def _alert_permanent_env(work_item_id: str, detail: str) -> None:
+    """Best-effort Telegram alert that the staging suite could not execute due to a
+    permanent environment defect (NOT a code defect) -> infra-HOLD. never-raise."""
+    try:
+        from .notifications import send_telegram, link_for
+        tail = f": {detail}" if detail else ""
+        send_telegram(
+            f"\U0001f6a8 {link_for(work_item_id)}: staging-сюита не смогла исполниться — "
+            f"постоянный дефект окружения (инфра, НЕ дефект кода){tail}. Задача удержана "
+            f"на deploy-staging до починки окружения (без отката на development)."
+        )
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.warning("staging_runner: permanent-env alert failed for %s: %s", work_item_id, e)
+
+
+# ---------------------------------------------------------------------------
+# Entry point (D2) — owns the full deterministic flow, mirror run_deploy_finalizer
+# ---------------------------------------------------------------------------
+def run_staging_gate(job: dict) -> None:
+    """Deterministic staging gate for a ``deployer`` job on ``deploy-staging``.
+
+    Flow (mirror of ``stage_engine.run_deploy_finalizer``):
+      1. resolve ``work_item_id`` / ``branch`` by ``task_id``;
+      2. execute the staging suite (D3) -> ProcResult;
+      3. classify the outcome three ways (D3): ``suite-ran`` -> map exit-code ->
+         ``staging_status:``, write ``15-staging-log.md``, initiate the existing gate
+         via ``advance_stage`` (D7);
+      4. ``permanent-env`` -> immediate infra-HOLD (no rollback, no developer-retry);
+         ``transient-infra`` -> bounded DEFER, then infra-HOLD on exhaustion (D4);
+      5. observability counters + one structured verdict log (D8).
+    Never raises into the caller (the launcher marks the job done/failed)."""
+    started = time.time()
+    _bump("runs")
+    task_id = job.get("task_id")
+    repo = job.get("repo")
+
+    # 1. resolve task fields.
+    work_item_id, branch = None, None
+    try:
+        from .db import get_db
+        conn = get_db()
+        row = conn.execute(
+            "SELECT work_item_id, branch FROM tasks WHERE id=?", (task_id,)
+        ).fetchone()
+        conn.close()
+        if row:
+            work_item_id, branch = row[0], row[1]
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.error("staging_runner: task lookup failed for task_id=%s: %s", task_id, e)
+    if not work_item_id or not branch:
+        logger.error(
+            "staging_runner: missing work_item_id/branch for task_id=%s — aborting", task_id
+        )
+        return
+
+    # 2-4. execute + classify + route — guarded so AC-7 (never-raise) holds even if
+    # an unexpected error escapes a sub-step (the worker must never crash on staging
+    # infra; the task is left on deploy-staging for the reconciler/reaper to re-drive).
+    try:
+        result = run_staging_suite()
+        duration_s = round(time.time() - started, 1)
+        # ORCH-123 (D3): three-way classification (env != transient infra != code-fail).
+        outcome = classify_staging_outcome(result, _channel_ssh_configured())
+
+        if outcome == "suite-ran":
+            # 3. trust the exit-code (ORCH-061 already inside staging_check.py).
+            status = map_exit_code_to_status(result.returncode)
+            _bump("success" if status == "SUCCESS" else "failed")
+            logger.info(
+                "staging_runner verdict: work_item=%s repo=%s exit_code=%s status=%s "
+                "duration_s=%s outcome=%s",
+                work_item_id, repo, result.returncode, status, duration_s,
+                "code-pass" if status == "SUCCESS" else "code-fail",
+            )
+            write_staging_log(repo, work_item_id, branch, result.returncode, status, result.stdout)
+            _advance(task_id, repo, work_item_id, branch)
+            return
+
+        # The suite did NOT execute. Count it as a tool-error, then route by class
+        # (D4): permanent-env -> immediate infra-HOLD; transient-infra -> bounded DEFER.
+        # NEITHER rolls back to development or burns a developer-retry (BR-2 invariant).
+        _bump("tool_error")
+        if outcome == "permanent-env":
+            _bump("permanent_env")
+            logger.warning(
+                "staging_runner verdict: work_item=%s repo=%s exit_code=%s "
+                "duration_s=%s outcome=permanent-env (ssh_configured=%s)",
+                work_item_id, repo, result.returncode, duration_s, _channel_ssh_configured(),
+            )
+            _handle_permanent_env(task_id, repo, work_item_id, branch, result)
+            return
+
+        # transient-infra (timeout / ssh transport / unknown) -> bounded DEFER.
+        logger.warning(
+            "staging_runner verdict: work_item=%s repo=%s exit_code=%s "
+            "duration_s=%s outcome=transient-infra (timed_out=%s)",
+            work_item_id, repo, result.returncode, duration_s, result.timed_out,
+        )
+        _handle_transient_infra(task_id, repo, work_item_id, branch, result)
+    except Exception as e:  # noqa: BLE001 - never-raise into the worker (AC-7)
+        logger.error(
+            "staging_runner.run_staging_gate: unexpected error for task %s (%s): %s",
+            task_id, work_item_id, e,
+        )
+
+
+# ---------------------------------------------------------------------------
+# Prod-like preflight of the host-side execution channel (D5 / FR-4 / AC-5)
+# ---------------------------------------------------------------------------
+def _alert_preflight(reason: str) -> None:
+    """Best-effort Telegram alert that the host-side staging channel is unworkable at
+    startup (so a real task never silently false-routes later). never-raise."""
+    try:
+        from .notifications import send_telegram
+        send_telegram(
+            f"⚠️ staging-runner preflight: {reason}. Хост-сторона исполнения "
+            f"staging-сюиты неработоспособна — задачи на deploy-staging будут удержаны "
+            f"(инфра, НЕ дефект кода). Проверьте ssh/docker/staging-стенд."
+        )
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.warning("staging_runner: preflight alert failed: %s", e)
+
+
+def preflight() -> tuple[bool, str]:
+    """Prod-like preflight of the host-side staging execution channel (D5 / AC-5).
+
+    Probes the channel with a short bounded ssh probe (``command -v docker`` +
+    ``docker inspect -f '{{.State.Running}}' <staging-service>``) so a broken
+    environment (no docker on the host / staging container down / ssh unreachable / no
+    ssh target configured) surfaces at SERVICE START — NOT postfactum as a false
+    rollback of a real task. Records ``_PREFLIGHT_STATE`` + alerts on failure.
+
+    Purely observational (FR-4): it NEVER gates/blocks the pipeline, touches stages /
+    QG, or raises — called best-effort from ``main.lifespan``. Self-hosting scope:
+    ``applies()`` first (a disabled runner / out-of-scope repo -> n/a). Returns
+    ``(ok, reason)`` (``ok=True`` for n/a / in-container mode / a healthy channel).
+    """
+    try:
+        from .qg.checks import SELF_HOSTING_REPO
+        if not applies(SELF_HOSTING_REPO):
+            _PREFLIGHT_STATE.update(ok=None, reason="n/a (runner disabled / out of scope)")
+            return True, "n/a"
+        # In-container mode (host-side disabled): nothing to probe host-side.
+        if not bool(getattr(settings, "staging_runner_exec_host_side", True)):
+            _PREFLIGHT_STATE.update(ok=True, reason="in-container mode (host-side disabled)")
+            return True, "in-container mode"
+        target = _ssh_target()
+        if not target:
+            reason = "no ssh target configured (deploy_ssh_host empty) — host-side staging unworkable"
+            _PREFLIGHT_STATE.update(ok=False, reason=reason)
+            _alert_preflight(reason)
+            return False, reason
+        probe = (
+            "command -v docker >/dev/null 2>&1 && "
+            f"docker inspect -f '{{{{.State.Running}}}}' {shlex.quote(STAGING_SERVICE)}"
+        )
+        cmd = ["ssh", "-o", "StrictHostKeyChecking=no", target, probe]
+        try:
+            r = subprocess.run(cmd, capture_output=True, text=True, timeout=_PREFLIGHT_TIMEOUT_S)
+        except subprocess.TimeoutExpired:
+            reason = "preflight ssh probe timed out"
+            _PREFLIGHT_STATE.update(ok=False, reason=reason)
+            _alert_preflight(reason)
+            return False, reason
+        except (subprocess.SubprocessError, OSError) as e:
+            reason = f"preflight ssh probe error: {e}"
+            _PREFLIGHT_STATE.update(ok=False, reason=reason)
+            _alert_preflight(reason)
+            return False, reason
+        out = (r.stdout or "").strip().lower()
+        if r.returncode == 0 and out == "true":
+            _PREFLIGHT_STATE.update(ok=True, reason="host-side channel ok (docker present, staging running)")
+            return True, "ok"
+        reason = f"host-side staging channel not ready (rc={r.returncode}, running={out!r})"
+        _PREFLIGHT_STATE.update(ok=False, reason=reason)
+        _alert_preflight(reason)
+        return False, reason
+    except Exception as e:  # noqa: BLE001 - never-raise; preflight must never block start
+        logger.warning("staging_runner.preflight error: %s", e)
+        _PREFLIGHT_STATE.update(ok=None, reason=f"preflight error: {e}")
+        return True, "preflight skipped (error)"
+
+
+# ---------------------------------------------------------------------------
+# Observability (D8 / FR-7 / AC-10)
+# ---------------------------------------------------------------------------
+def snapshot() -> dict:
+    """Read-only staging-runner summary for ``GET /queue`` (FR-7 / AC-10).
+
+    Additive block; existing ``/queue`` keys are untouched. ORCH-123 adds
+    ``exec_host_side`` (the strategy flag), ``permanent_env`` (the infra-HOLD counter,
+    distinct from ``failed``=code-fail and ``deferred``=transient-infra) and the last
+    ``preflight`` verdict. never-raise: any error -> a minimal dict with the
+    kill-switch state."""
+    try:
+        return {
+            "enabled": bool(settings.staging_runner_enabled),
+            "repos": getattr(settings, "staging_runner_repos", "") or "",
+            "timeout_s": getattr(settings, "staging_runner_timeout_s", _DEFAULT_TIMEOUT_S),
+            "infra_max_retries": getattr(settings, "staging_runner_infra_max_retries", 2),
+            "exec_host_side": bool(getattr(settings, "staging_runner_exec_host_side", True)),
+            "runs": _STAGING_RUNNER_COUNTERS["runs"],
+            "success": _STAGING_RUNNER_COUNTERS["success"],
+            "failed": _STAGING_RUNNER_COUNTERS["failed"],
+            "tool_error": _STAGING_RUNNER_COUNTERS["tool_error"],
+            "deferred": _STAGING_RUNNER_COUNTERS["deferred"],
+            "permanent_env": _STAGING_RUNNER_COUNTERS["permanent_env"],
+            "preflight": dict(_PREFLIGHT_STATE),
+        }
+    except Exception as e:  # noqa: BLE001 - never-raise -> minimal dict
+        logger.warning("staging_runner.snapshot error: %s", e)
+        return {"enabled": False}

tests/test_orch115_staging_runner.py

@@ -0,0 +1,453 @@
+"""ORCH-115 — deterministic staging-runner replacing the LLM deployer on
+`deploy-staging` (self-hosting orchestrator).
+
+Covers Phase 1 (04-test-plan.yaml TC-01…TC-13): the launch_job intercept BEFORE
+_spawn, the exit-code -> staging_status: mapping, 15-staging-log.md render + the
+UNCHANGED gate contract, advance_stage initiation, kill-switch/scope, never-raise /
+fail-safe, the bounded tool-error DEFER, process timeout, self-hosting safety, the
+anti-drift invariant (STAGE_TRANSITIONS / QG_CHECKS / DB schema untouched), and the
+/queue observability block.
+
+No live Claude CLI, docker or network: the staging subprocess and advance_stage are
+mocked; the pure mapping/render is tested directly. (TC-14 — the LLM call-site map
+anti-drift — lives in tests/test_llm_call_site_inventory.py / test_llm_determinization_docs.py.)
+"""
+import os
+import tempfile
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch115_staging_runner.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+from unittest.mock import MagicMock  # noqa: E402
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db, enqueue_job  # noqa: E402
+from src import staging_runner  # noqa: E402
+from src import stage_engine  # noqa: E402
+from src import config as cfg  # noqa: E402
+from src.proc_group import ProcResult  # noqa: E402
+from src.agents.launcher import AgentLauncher  # noqa: E402
+
+
+# ---------------------------------------------------------------------------
+# Fixtures
+# ---------------------------------------------------------------------------
+@pytest.fixture(autouse=True)
+def fresh_db(monkeypatch, tmp_path):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    # Worktree artefacts land in tmp; git commit/push degrade gracefully (no repo).
+    monkeypatch.setattr("src.git_worktree.settings.worktrees_dir", str(tmp_path), raising=False)
+    # Runner ON, self-hosting scope (default).
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "staging_runner_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "staging_runner_infra_max_retries", 2, raising=False)
+    # Reset in-process counters between tests.
+    for k in staging_runner._STAGING_RUNNER_COUNTERS:
+        staging_runner._STAGING_RUNNER_COUNTERS[k] = 0
+    yield
+
+
+def _make_task(stage, repo="orchestrator", wi="ORCH-115", branch="feature/ORCH-115-x"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) VALUES (?, ?, ?, ?, ?)",
+        (f"plane-{wi}", wi, repo, branch, stage),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+def _make_job(agent, repo, task_id, content="x"):
+    return enqueue_job(agent, repo, content, task_id=task_id)
+
+
+def _job_dict(job_id, agent, repo, task_id):
+    return {"id": job_id, "agent": agent, "repo": repo, "task_id": task_id, "task_content": "x"}
+
+
+def _read_log(tmp_path, repo, branch, wi):
+    from src.git_worktree import get_worktree_path
+    p = os.path.join(get_worktree_path(repo, branch), f"docs/work-items/{wi}/15-staging-log.md")
+    with open(p, "r", encoding="utf-8") as f:
+        return f.read()
+
+
+# ---------------------------------------------------------------------------
+# TC-01 — applies(): kill-switch / scope / fail-safe (FR-6 / AC-6)
+# ---------------------------------------------------------------------------
+def test_tc01_applies_killswitch_and_scope(monkeypatch):
+    # enabled=False -> False (fall back to the LLM path) regardless of repo.
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", False)
+    assert staging_runner.applies("orchestrator") is False
+
+    # enabled, empty CSV -> self-hosting only.
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", True)
+    monkeypatch.setattr(cfg.settings, "staging_runner_repos", "")
+    assert staging_runner.applies("orchestrator") is True
+    assert staging_runner.applies("enduro-trails") is False
+    assert staging_runner.applies("") is False
+
+    # non-empty CSV -> membership (case-insensitive).
+    monkeypatch.setattr(cfg.settings, "staging_runner_repos", "enduro-trails, orchestrator")
+    assert staging_runner.applies("ENDURO-TRAILS") is True
+    assert staging_runner.applies("other-repo") is False
+
+
+def test_tc01_applies_never_raises(monkeypatch):
+    # A settings attribute that explodes on read -> applies() degrades to False.
+    class Boom:
+        @property
+        def staging_runner_enabled(self):
+            raise RuntimeError("boom")
+    monkeypatch.setattr(staging_runner, "settings", Boom())
+    assert staging_runner.applies("orchestrator") is False
+
+
+# ---------------------------------------------------------------------------
+# TC-02 — exit-code -> verdict, single shared contract (FR-3 / AC-3)
+# ---------------------------------------------------------------------------
+def test_tc02_map_exit_code():
+    from src import self_deploy
+    assert staging_runner.map_exit_code_to_status(0) == "SUCCESS"
+    for bad in (1, 2, 137, -9):
+        assert staging_runner.map_exit_code_to_status(bad) == "FAILED"
+    for noncode in (None, "x", object()):
+        assert staging_runner.map_exit_code_to_status(noncode) == "FAILED"
+    # Same contract as the deploy-finalizer (no second, drifting mapping).
+    for v in (0, 1, None, "garbage"):
+        assert staging_runner.map_exit_code_to_status(v) == self_deploy.map_exit_code_to_status(v)
+
+
+# ---------------------------------------------------------------------------
+# TC-03 — 15-staging-log.md render: machine key + 52c schema + INFRA-WAIVED (FR-4 / AC-2)
+# ---------------------------------------------------------------------------
+def test_tc03_log_render_schema_and_infra_waived():
+    stdout = "B6 OK\nINFRA-WAIVED: B9 image-build skipped (sandbox)\nDONE"
+    body = staging_runner.build_staging_log("ORCH-115", 0, "SUCCESS", stdout)
+    assert "staging_status: SUCCESS" in body  # UPPERCASE machine key
+    for field in ("work_item: ORCH-115", "stage: deploy-staging",
+                  "author_agent: staging-runner", "status: success",
+                  "created_at:", "model_used: n/a"):
+        assert field in body, f"missing 52c field: {field}"
+    # INFRA-WAIVED line copied into the body for observability.
+    assert "INFRA-WAIVED: B9 image-build skipped (sandbox)" in body
+
+    failed = staging_runner.build_staging_log("ORCH-115", 1, "FAILED", "boom")
+    assert "staging_status: FAILED" in failed
+    assert "status: failed" in failed
+
+
+# ---------------------------------------------------------------------------
+# TC-04 — generated log read by the UNCHANGED _parse_staging_status (AC-2)
+# ---------------------------------------------------------------------------
+def test_tc04_gate_parser_unchanged():
+    from src.qg.checks import _parse_staging_status
+    ok, reason = _parse_staging_status(staging_runner.build_staging_log("ORCH-115", 0, "SUCCESS"))
+    assert ok is True and "SUCCESS" in reason
+    bad, reason2 = _parse_staging_status(staging_runner.build_staging_log("ORCH-115", 2, "FAILED"))
+    assert bad is False and "FAILED" in reason2
+
+
+# ---------------------------------------------------------------------------
+# TC-05 — launch_job intercepts deployer on deploy-staging BEFORE _spawn (AC-1)
+# ---------------------------------------------------------------------------
+def test_tc05_launch_job_intercepts_before_spawn(monkeypatch):
+    tid = _make_task("deploy-staging")
+    jid = _make_job("deployer", "orchestrator", tid)
+    lr = AgentLauncher()
+    spawn = MagicMock(return_value=999)
+    monkeypatch.setattr(lr, "_spawn", spawn)
+    run_gate = MagicMock()
+    monkeypatch.setattr(staging_runner, "run_staging_gate", run_gate)
+
+    ret = lr.launch_job(_job_dict(jid, "deployer", "orchestrator", tid))
+
+    assert ret is None                      # no agent_runs row
+    spawn.assert_not_called()               # LLM path NOT taken
+    run_gate.assert_called_once()           # deterministic runner ran
+    # jobs row driven to done by the launcher (no monitor/agent).
+    conn = get_db()
+    status = conn.execute("SELECT status FROM jobs WHERE id=?", (jid,)).fetchone()[0]
+    conn.close()
+    assert status == "done"
+
+
+# ---------------------------------------------------------------------------
+# TC-06 — stage discriminator: deployer on `deploy` is NOT intercepted (AC-1 / R-1)
+# ---------------------------------------------------------------------------
+def test_tc06_stage_discriminator_prod_not_intercepted(monkeypatch):
+    tid = _make_task("deploy")  # prod edge, not deploy-staging
+    jid = _make_job("deployer", "orchestrator", tid)
+    lr = AgentLauncher()
+    spawn = MagicMock(return_value=42)
+    monkeypatch.setattr(lr, "_spawn", spawn)
+    run_gate = MagicMock()
+    monkeypatch.setattr(staging_runner, "run_staging_gate", run_gate)
+
+    ret = lr.launch_job(_job_dict(jid, "deployer", "orchestrator", tid))
+
+    assert ret == 42                        # _spawn path taken
+    spawn.assert_called_once()
+    run_gate.assert_not_called()
+    assert staging_runner.should_intercept(_job_dict(jid, "deployer", "orchestrator", tid)) is False
+
+
+def test_tc06_non_self_repo_not_intercepted(monkeypatch):
+    tid = _make_task("deploy-staging", repo="enduro-trails", wi="ET-9", branch="feature/ET-9-x")
+    jid = _make_job("deployer", "enduro-trails", tid)
+    assert staging_runner.should_intercept(_job_dict(jid, "deployer", "enduro-trails", tid)) is False
+
+
+# ---------------------------------------------------------------------------
+# TC-07 — routing equivalence: SUCCESS -> advance; FAILED -> same path (AC-4)
+# ---------------------------------------------------------------------------
+@pytest.mark.parametrize("rc,expected", [(0, "SUCCESS"), (1, "FAILED")])
+def test_tc07_advance_initiated_like_llm(monkeypatch, tmp_path, rc, expected):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=rc, stdout="out", stderr="", timed_out=False))
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_called_once()
+    kwargs = advance.call_args.kwargs
+    assert kwargs["current_stage"] == "deploy-staging"
+    assert kwargs["finished_agent"] == "deployer"
+    assert kwargs["work_item_id"] == "ORCH-115"
+    # The log written for the gate carries the matching verdict.
+    assert f"staging_status: {expected}" in _read_log(tmp_path, "orchestrator", "feature/ORCH-115-x", "ORCH-115")
+
+
+# ---------------------------------------------------------------------------
+# TC-08 — kill-switch: enabled=False -> LLM path via _spawn (AC-6)
+# ---------------------------------------------------------------------------
+def test_tc08_killswitch_falls_back_to_spawn(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", False)
+    tid = _make_task("deploy-staging")
+    jid = _make_job("deployer", "orchestrator", tid)
+    lr = AgentLauncher()
+    spawn = MagicMock(return_value=7)
+    monkeypatch.setattr(lr, "_spawn", spawn)
+    run_gate = MagicMock()
+    monkeypatch.setattr(staging_runner, "run_staging_gate", run_gate)
+
+    ret = lr.launch_job(_job_dict(jid, "deployer", "orchestrator", tid))
+
+    assert ret == 7
+    spawn.assert_called_once()              # byte-for-byte the prior LLM-deployer path
+    run_gate.assert_not_called()
+
+
+# ---------------------------------------------------------------------------
+# TC-09 — anti-drift NFR-1: STAGE_TRANSITIONS / QG_CHECKS / schema untouched (AC-5)
+# ---------------------------------------------------------------------------
+def test_tc09_pipeline_contract_unchanged():
+    from src.stages import STAGE_TRANSITIONS
+    from src.qg.checks import QG_CHECKS
+    # The deploy-staging edge + its gate are byte-for-byte the prior contract.
+    assert STAGE_TRANSITIONS["deploy-staging"] == {
+        "next": "deploy", "agent": "deployer", "qg": "check_staging_status"
+    }
+    assert "check_staging_status" in QG_CHECKS
+    # No new ORCH-115 table/column: only the existing tables exist.
+    conn = get_db()
+    tables = {r[0] for r in conn.execute(
+        "SELECT name FROM sqlite_master WHERE type='table'").fetchall()}
+    conn.close()
+    assert not any("staging_runner" in t for t in tables)
+    # The machine key is not renamed: the runner emits `staging_status:`.
+    assert "staging_status:" in staging_runner.build_staging_log("ORCH-115", 0, "SUCCESS")
+
+
+# ---------------------------------------------------------------------------
+# TC-10 — never-raise / fail-safe: tool-error never a silent advance/false green (AC-7)
+# ---------------------------------------------------------------------------
+def test_tc10_nonzero_exit_is_failed_and_advances(monkeypatch, tmp_path):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=3, stdout="fail", stderr="", timed_out=False))
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+    advance.assert_called_once()
+    assert "staging_status: FAILED" in _read_log(tmp_path, "orchestrator", "feature/ORCH-115-x", "ORCH-115")
+
+
+def test_tc10_timeout_defers_without_advance(monkeypatch):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(cfg.settings, "staging_runner_infra_max_retries", 2)
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=None, stdout="", stderr="", timed_out=True))
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()             # NO silent advance / false green on infra hiccup
+    # A fresh deployer job was re-queued with the restart-safe marker (bounded DEFER).
+    conn = get_db()
+    n = conn.execute(
+        "SELECT COUNT(*) FROM jobs WHERE task_id=? AND task_content LIKE ?",
+        (tid, f"%{staging_runner._INFRA_RETRY_MARKER}%"),
+    ).fetchone()[0]
+    conn.close()
+    assert n == 1
+    assert staging_runner._STAGING_RUNNER_COUNTERS["deferred"] == 1
+    assert staging_runner._STAGING_RUNNER_COUNTERS["tool_error"] == 1
+
+
+def test_tc10_tool_error_budget_exhausted_infra_holds(monkeypatch, tmp_path):
+    # ORCH-123 (D4) SUPERSEDES ORCH-115 D5: a transient-infra DEFER budget that is
+    # exhausted no longer writes a fail-closed FAILED log + advances (a false rollback
+    # to development of an unresolved infra hiccup — BR-2). The task is now HELD on
+    # deploy-staging (infra-HOLD): NO advance, NO FAILED log, an operator alert instead.
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(cfg.settings, "staging_runner_infra_max_retries", 0)  # exhausted immediately
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=None, stdout="", stderr="", timed_out=True))
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()             # infra-HOLD: NO rollback to development
+    # No staging-log was written (a FAILED log would mislabel infra as a code-fail).
+    from src.git_worktree import get_worktree_path
+    log_path = os.path.join(get_worktree_path("orchestrator", "feature/ORCH-115-x"),
+                            "docs/work-items/ORCH-115/15-staging-log.md")
+    assert not os.path.exists(log_path)
+    assert staging_runner._STAGING_RUNNER_COUNTERS["permanent_env"] == 1
+
+
+def test_tc10_run_gate_never_raises(monkeypatch):
+    tid = _make_task("deploy-staging")
+
+    def boom():
+        raise RuntimeError("docker exec exploded")
+    monkeypatch.setattr(staging_runner, "run_staging_suite", boom)
+    # Must NOT raise (AC-7): the worker is protected even on an unexpected error.
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+
+def test_tc10_launcher_contains_runner_fault(monkeypatch):
+    tid = _make_task("deploy-staging")
+    jid = _make_job("deployer", "orchestrator", tid)
+    lr = AgentLauncher()
+    monkeypatch.setattr(lr, "_spawn", MagicMock())
+    monkeypatch.setattr(staging_runner, "run_staging_gate",
+                        MagicMock(side_effect=RuntimeError("kaboom")))
+    # The launcher wrapper contains the fault -> job marked failed, never raises.
+    ret = lr.launch_job(_job_dict(jid, "deployer", "orchestrator", tid))
+    assert ret is None
+    conn = get_db()
+    status = conn.execute("SELECT status FROM jobs WHERE id=?", (jid,)).fetchone()[0]
+    conn.close()
+    assert status == "failed"
+
+
+# ---------------------------------------------------------------------------
+# TC-11 — timeout resolution + propagation (NFR-4 / AC-9)
+# ---------------------------------------------------------------------------
+def test_tc11_resolve_timeout_default_on_bad_value(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_timeout_s", 1234)
+    assert staging_runner._resolve_timeout() == 1234
+    for bad in (0, -5, "abc", None):
+        monkeypatch.setattr(cfg.settings, "staging_runner_timeout_s", bad)
+        assert staging_runner._resolve_timeout() == staging_runner._DEFAULT_TIMEOUT_S
+
+
+def test_tc11_timeout_passed_to_proc_group(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_timeout_s", 321)
+    monkeypatch.setattr(cfg.settings, "subprocess_tree_kill_enabled", True)
+    captured = {}
+
+    def fake_run(cmd, *, cwd, timeout, grace_s, tree_kill):
+        captured.update(cmd=cmd, timeout=timeout, tree_kill=tree_kill)
+        return ProcResult(returncode=0, stdout="", stderr="", timed_out=False)
+    monkeypatch.setattr(staging_runner.proc_group, "run_in_process_group", fake_run)
+
+    # ORCH-123 (D1): with no ssh target the command falls back to the in-container
+    # `docker exec` shape (the host-side ssh-wrap is covered in test_orch123_*). The
+    # invariant this test guards — timeout + tree_kill propagate to proc_group — is
+    # unchanged.
+    monkeypatch.setattr(cfg.settings, "deploy_ssh_host", "")
+    staging_runner.run_staging_suite()
+    assert captured["timeout"] == 321
+    assert captured["tree_kill"] is True
+    assert captured["cmd"][:2] == ["docker", "exec"]
+
+
+# ---------------------------------------------------------------------------
+# TC-12 — self-hosting safety: no forbidden literals in the runner command (AC-8)
+# ---------------------------------------------------------------------------
+def test_tc12_command_has_no_dangerous_literals():
+    cmd = " ".join(staging_runner.build_staging_command())
+    forbidden = ("compose", "up -d", "--build", "8500", "force", "push", ".env",
+                 "rm ", "restart")
+    for token in forbidden:
+        assert token not in cmd, f"forbidden literal {token!r} in runner command: {cmd}"
+    # It IS the staging suite against 8501 via docker exec.
+    assert "docker exec" in cmd
+    assert "staging_check.py" in cmd
+    assert "8501" in cmd
+    assert "--mode stub" in cmd
+
+
+# ---------------------------------------------------------------------------
+# TC-13 — observability: /queue block + structured verdict log (AC-10)
+# ---------------------------------------------------------------------------
+def test_tc13_snapshot_shape():
+    snap = staging_runner.snapshot()
+    for k in ("enabled", "repos", "timeout_s", "infra_max_retries",
+              "runs", "success", "failed", "tool_error", "deferred"):
+        assert k in snap, f"snapshot missing key {k}"
+
+
+def test_tc13_queue_endpoint_includes_block(monkeypatch):
+    import asyncio
+    from src import main
+    payload = asyncio.run(main.queue())
+    assert "staging_runner" in payload
+    assert "enabled" in payload["staging_runner"]
+
+
+def test_tc13_structured_verdict_log_distinguishes_outcomes(monkeypatch, caplog, tmp_path):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(stage_engine, "advance_stage", MagicMock())
+    # code-pass
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=0, stdout="", stderr="", timed_out=False))
+    with caplog.at_level("INFO", logger="orchestrator.staging_runner"):
+        staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+    assert any("outcome=code-pass" in r.message for r in caplog.records)
+
+    caplog.clear()
+    # ORCH-123 (D8): a timeout is now classified `transient-infra` (the outcome
+    # taxonomy is code-pass/code-fail/transient-infra/permanent-env, not "tool-error").
+    monkeypatch.setattr(cfg.settings, "staging_runner_infra_max_retries", 2)
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: ProcResult(returncode=None, stdout="", stderr="", timed_out=True))
+    with caplog.at_level("WARNING", logger="orchestrator.staging_runner"):
+        staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+    assert any("outcome=transient-infra" in r.message for r in caplog.records)
+
+
+def test_tc13_snapshot_never_raises(monkeypatch):
+    class Boom:
+        def __getattr__(self, name):
+            raise RuntimeError("boom")
+    monkeypatch.setattr(staging_runner, "settings", Boom())
+    snap = staging_runner.snapshot()
+    assert snap["enabled"] is False

tests/test_orch123_staging_runner_exec.py

@@ -0,0 +1,503 @@
+"""ORCH-123 — staging-runner execution strategy must not depend on a docker CLI
+inside the prod app-container (host-side ssh + three-way env classification).
+
+Background (incident ORCH-116): the ORCH-115 deterministic staging-runner ran the
+staging suite via ``docker exec`` FROM INSIDE the prod ``orchestrator`` container,
+which ships only ``openssh-client git curl`` — NOT a ``docker`` CLI (Dockerfile:11).
+``Popen(["docker", ...])`` hit ``FileNotFoundError`` -> a PERMANENT environment defect
+that ORCH-115 mis-routed as a code-fail rollback ``deploy-staging -> development``
+(burning developer-retries). The fix (ADR-001 / adr-0049):
+
+  * D1 — execute the suite HOST-SIDE over the existing trusted ssh channel
+    (ORCH-036/058), wrapping the SAME ``docker exec ...`` command;
+  * D3 — three-way classification ``suite-ran`` / ``permanent-env`` / ``transient-infra``;
+  * D4 — environment/transient-infra NEVER ends in a code-fail rollback (infra-HOLD);
+    a really-executed failing suite STILL rolls back (anti-over-tolerance);
+  * D5 — a prod-like preflight of the host-side channel at startup.
+
+The pipeline gate / artifact contract / STAGE_TRANSITIONS / DB schema are byte-for-byte
+unchanged (NFR-1). No live ssh / docker / network: the suite subprocess, advance_stage
+and notifications are mocked; spawn-errors are reproduced with a non-existent binary.
+"""
+import os
+import tempfile
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch123_staging_runner_exec.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+from unittest.mock import MagicMock  # noqa: E402
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db  # noqa: E402
+from src import staging_runner  # noqa: E402
+from src import stage_engine  # noqa: E402
+from src import config as cfg  # noqa: E402
+from src.proc_group import ProcResult  # noqa: E402
+
+
+# ---------------------------------------------------------------------------
+# Fixtures (mirror tests/test_orch115_staging_runner.py)
+# ---------------------------------------------------------------------------
+@pytest.fixture(autouse=True)
+def fresh_db(monkeypatch, tmp_path):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    monkeypatch.setattr("src.git_worktree.settings.worktrees_dir", str(tmp_path), raising=False)
+    # Runner ON, self-hosting scope, host-side strategy ON (defaults).
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "staging_runner_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "staging_runner_infra_max_retries", 2, raising=False)
+    monkeypatch.setattr(cfg.settings, "staging_runner_exec_host_side", True, raising=False)
+    # A configured ssh target (prod compose sets ORCH_DEPLOY_SSH_HOST=127.0.0.1).
+    monkeypatch.setattr(cfg.settings, "deploy_ssh_host", "127.0.0.1", raising=False)
+    monkeypatch.setattr(cfg.settings, "deploy_ssh_user", "slin", raising=False)
+    for k in staging_runner._STAGING_RUNNER_COUNTERS:
+        staging_runner._STAGING_RUNNER_COUNTERS[k] = 0
+    staging_runner._PREFLIGHT_STATE.update(ok=None, reason="not-probed")
+    yield
+
+
+def _make_task(stage, repo="orchestrator", wi="ORCH-123", branch="feature/ORCH-123-x"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) VALUES (?, ?, ?, ?, ?)",
+        (f"plane-{wi}", wi, repo, branch, stage),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+def _job_dict(job_id, agent, repo, task_id):
+    return {"id": job_id, "agent": agent, "repo": repo, "task_id": task_id, "task_content": "x"}
+
+
+def _infra_jobs(task_id):
+    conn = get_db()
+    n = conn.execute(
+        "SELECT COUNT(*) FROM jobs WHERE task_id=? AND task_content LIKE ?",
+        (task_id, f"%{staging_runner._INFRA_RETRY_MARKER}%"),
+    ).fetchone()[0]
+    conn.close()
+    return n
+
+
+def _read_log(repo, branch, wi):
+    from src.git_worktree import get_worktree_path
+    p = os.path.join(get_worktree_path(repo, branch), f"docs/work-items/{wi}/15-staging-log.md")
+    with open(p, "r", encoding="utf-8") as f:
+        return f.read()
+
+
+def _log_exists(repo, branch, wi):
+    from src.git_worktree import get_worktree_path
+    return os.path.exists(
+        os.path.join(get_worktree_path(repo, branch), f"docs/work-items/{wi}/15-staging-log.md")
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-01 — MANDATORY regression (red->green): no docker CLI in the container
+# ---------------------------------------------------------------------------
+def test_tc01_regression_no_docker_cli_in_container(monkeypatch):
+    """Reproduces incident ORCH-116. PRE-FIX: an in-container ``docker exec`` where the
+    container has no docker CLI -> proc_group spawn-error -> tool-error -> infra-DEFER x2
+    -> false FAILED rollback to development. POST-FIX: classified ``permanent-env`` ->
+    infra-HOLD: NO advance, NO re-queue, NO developer-retry. (Red on pre-fix code —
+    there is no permanent-env class / counter there and the path advances.)"""
+    tid = _make_task("deploy-staging")
+    # Force the pre-fix in-container shape, then make the spawn fail exactly as if
+    # `docker` were absent — no network / ssh / docker needed.
+    monkeypatch.setattr(cfg.settings, "staging_runner_exec_host_side", False)
+    monkeypatch.setattr(staging_runner, "build_staging_command",
+                        lambda: ["orch123-no-such-binary", "exec", "orchestrator-staging"])
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()                      # NO false rollback to development
+    assert _infra_jobs(tid) == 0                     # DEFER cycle skipped (FR-3)
+    assert not _log_exists("orchestrator", "feature/ORCH-123-x", "ORCH-123")  # no FAILED log
+    assert staging_runner._STAGING_RUNNER_COUNTERS["permanent_env"] == 1
+    assert staging_runner._STAGING_RUNNER_COUNTERS["tool_error"] == 1
+    assert stage_engine.developer_retry_count(tid) == 0  # developer-retry not burned
+
+
+# ---------------------------------------------------------------------------
+# TC-02 — strategy does not require a docker CLI on the container PATH
+# ---------------------------------------------------------------------------
+def test_tc02_host_side_command_does_not_assume_in_container_docker():
+    # With host-side ON + an ssh target, the suite is dispatched via ssh — the prod
+    # container's own PATH is never asked for a `docker` binary.
+    cmd = staging_runner.build_staging_command()
+    assert cmd[0] == "ssh"                           # dispatched over the trusted channel
+    assert "slin@127.0.0.1" in cmd
+    # The INNER command is the SAME staging suite (contract unchanged).
+    remote = cmd[-1]
+    assert "docker exec orchestrator-staging" in remote
+    assert "staging_check.py" in remote
+    assert "--mode stub" in remote
+    # The local executable invoked is `ssh` (in the container image), NOT `docker`.
+    assert cmd[0] != "docker"
+
+
+# ---------------------------------------------------------------------------
+# TC-03 — environment/tool-error does NOT cause a misleading code-fail rollback
+# ---------------------------------------------------------------------------
+def test_tc03_env_defect_no_code_fail_rollback_and_alerts(monkeypatch):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(
+        staging_runner, "run_staging_suite",
+        lambda: ProcResult(returncode=None, stdout="",
+                           stderr="[Errno 2] No such file or directory: 'docker'", timed_out=False),
+    )
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+    sent = []
+    monkeypatch.setattr("src.notifications.send_telegram", lambda msg, **kw: sent.append(msg))
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()                       # not a code-fail -> no rollback
+    assert _infra_jobs(tid) == 0                       # permanent defect -> no pointless retry
+    assert stage_engine.developer_retry_count(tid) == 0
+    # A distinguishable infra/environment alert ("NOT a code defect") was sent.
+    assert sent and any("НЕ дефект кода" in m for m in sent)
+
+
+# ---------------------------------------------------------------------------
+# TC-04 — anti-over-tolerance: a really-executed failing suite STILL rolls back
+# ---------------------------------------------------------------------------
+def test_tc04_real_suite_failure_still_rolls_back(monkeypatch):
+    tid = _make_task("deploy-staging")
+    # The suite executed (a real exit-code) and failed; clean stderr (no env-marker).
+    monkeypatch.setattr(
+        staging_runner, "run_staging_suite",
+        lambda: ProcResult(returncode=1, stdout="B7 FAIL: assertion", stderr="", timed_out=False),
+    )
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_called_once()                       # same rollback path as ORCH-115
+    kwargs = advance.call_args.kwargs
+    assert kwargs["current_stage"] == "deploy-staging"
+    assert kwargs["finished_agent"] == "deployer"
+    assert "staging_status: FAILED" in _read_log("orchestrator", "feature/ORCH-123-x", "ORCH-123")
+    assert staging_runner._STAGING_RUNNER_COUNTERS["failed"] == 1
+    assert staging_runner._STAGING_RUNNER_COUNTERS["permanent_env"] == 0
+
+
+def test_tc04_exit1_with_env_marker_is_not_a_code_fail(monkeypatch):
+    # The exit=1 collision: `docker exec` "No such container"=1 must NOT be read as a
+    # suite fail=1. The stderr env-marker disambiguates it -> permanent-env (no rollback).
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(
+        staging_runner, "run_staging_suite",
+        lambda: ProcResult(returncode=1, stdout="",
+                           stderr="Error: No such container: orchestrator-staging", timed_out=False),
+    )
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+    monkeypatch.setattr("src.notifications.send_telegram", lambda *a, **kw: None)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()
+    assert staging_runner._STAGING_RUNNER_COUNTERS["permanent_env"] == 1
+
+
+# ---------------------------------------------------------------------------
+# TC-05 — happy-path: suite ran, exit 0 -> SUCCESS -> advance
+# ---------------------------------------------------------------------------
+def test_tc05_happy_path_success_advances(monkeypatch):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(
+        staging_runner, "run_staging_suite",
+        lambda: ProcResult(returncode=0, stdout="ALL OK", stderr="", timed_out=False),
+    )
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_called_once()
+    assert advance.call_args.kwargs["finished_agent"] == "deployer"
+    assert "staging_status: SUCCESS" in _read_log("orchestrator", "feature/ORCH-123-x", "ORCH-123")
+    assert staging_runner._STAGING_RUNNER_COUNTERS["success"] == 1
+
+
+# ---------------------------------------------------------------------------
+# TC-06 — three-way classification (D3)
+# ---------------------------------------------------------------------------
+def _pr(rc=None, stderr="", timed_out=False):
+    return ProcResult(returncode=rc, stdout="", stderr=stderr, timed_out=timed_out)
+
+
+def test_tc06_classification_three_way():
+    C = staging_runner.classify_staging_outcome
+    # suite-ran: any recognised int (except 255) with no env-marker -> trust it.
+    assert C(_pr(rc=0), True) == "suite-ran"
+    assert C(_pr(rc=1), True) == "suite-ran"            # anti-over-tolerance (BR-3)
+    assert C(_pr(rc=2, stderr="B7 FAIL"), True) == "suite-ran"
+    # permanent-env: spawn-error (rc None, not a timeout).
+    assert C(_pr(rc=None), True) == "permanent-env"
+    # permanent-env: shell command-not-found / cannot-execute codes.
+    assert C(_pr(rc=127), True) == "permanent-env"
+    assert C(_pr(rc=126), True) == "permanent-env"
+    # permanent-env: env-marker regardless of the exit-code.
+    assert C(_pr(rc=1, stderr="Cannot connect to the Docker daemon"), True) == "permanent-env"
+    assert C(_pr(rc=1, stderr="docker: command not found"), True) == "permanent-env"
+    # permanent-env: host-side ssh target not configured (R-6).
+    assert C(_pr(rc=None), False) == "permanent-env"
+    # transient-infra: timeout / ssh transport (255) -> retry is meaningful.
+    assert C(_pr(timed_out=True), True) == "transient-infra"
+    assert C(_pr(rc=255), True) == "transient-infra"
+
+
+def test_tc06_classification_never_raises():
+    class Boom:
+        @property
+        def returncode(self):
+            raise RuntimeError("boom")
+    # An exploding result -> fail-safe transient-infra (DEFER, never a silent suite-ran).
+    assert staging_runner.classify_staging_outcome(Boom(), True) == "transient-infra"
+
+
+def test_tc06_transient_infra_defers_not_rolls_back(monkeypatch):
+    tid = _make_task("deploy-staging")
+    monkeypatch.setattr(staging_runner, "run_staging_suite",
+                        lambda: _pr(rc=255, stderr="ssh: connect: Connection refused"))
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))
+
+    advance.assert_not_called()                        # transient -> DEFER, never rollback
+    assert _infra_jobs(tid) == 1                        # a fresh deployer job re-queued
+    assert staging_runner._STAGING_RUNNER_COUNTERS["deferred"] == 1
+
+
+# ---------------------------------------------------------------------------
+# TC-07 — prod-like preflight (D5 / AC-5)
+# ---------------------------------------------------------------------------
+def test_tc07_preflight_no_ssh_target_signals_before_a_real_task(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "deploy_ssh_host", "")     # host-side, but no target
+    sent = []
+    monkeypatch.setattr("src.notifications.send_telegram", lambda msg, **kw: sent.append(msg))
+
+    ok, reason = staging_runner.preflight()
+
+    assert ok is False
+    assert "no ssh target" in reason
+    assert staging_runner._PREFLIGHT_STATE["ok"] is False
+    assert sent                                         # operator alerted at startup
+
+
+def test_tc07_preflight_probe_success(monkeypatch):
+    class _R:
+        returncode = 0
+        stdout = "true\n"
+        stderr = ""
+    monkeypatch.setattr(staging_runner.subprocess, "run", lambda *a, **kw: _R())
+    ok, reason = staging_runner.preflight()
+    assert ok is True
+    assert staging_runner._PREFLIGHT_STATE["ok"] is True
+
+
+def test_tc07_preflight_probe_failure_alerts(monkeypatch):
+    class _R:
+        returncode = 1
+        stdout = ""           # docker missing on host / container down
+        stderr = "command not found"
+    monkeypatch.setattr(staging_runner.subprocess, "run", lambda *a, **kw: _R())
+    sent = []
+    monkeypatch.setattr("src.notifications.send_telegram", lambda msg, **kw: sent.append(msg))
+    ok, _reason = staging_runner.preflight()
+    assert ok is False
+    assert sent
+
+
+def test_tc07_preflight_noop_when_disabled(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", False)
+    ok, reason = staging_runner.preflight()            # out of scope -> n/a, never blocks
+    assert ok is True
+    assert reason == "n/a"
+
+
+def test_tc07_preflight_in_container_mode_noop(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_exec_host_side", False)
+    ok, reason = staging_runner.preflight()
+    assert ok is True
+    assert "in-container" in reason
+
+
+# ---------------------------------------------------------------------------
+# TC-08 — self-hosting safety: no dangerous literals in the host-side command
+# ---------------------------------------------------------------------------
+def test_tc08_host_side_command_has_no_dangerous_literals():
+    cmd = " ".join(staging_runner.build_staging_command())
+    forbidden = ("compose", "up -d", "--build", "8500", "force", "push", ".env",
+                 "rm ", "restart")
+    for token in forbidden:
+        assert token not in cmd, f"forbidden literal {token!r} in host-side command: {cmd}"
+    assert "ssh" in cmd and "docker exec" in cmd and "staging_check.py" in cmd
+    assert "8501" in cmd and "--mode stub" in cmd
+
+
+# ---------------------------------------------------------------------------
+# TC-09 — kill-switch / scope / strategy flag default (AC-10)
+# ---------------------------------------------------------------------------
+def test_tc09_killswitch_scope_and_flag_default(monkeypatch):
+    # kill-switch off -> should_intercept False -> the prior LLM deployer via _spawn.
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", False)
+    tid = _make_task("deploy-staging")
+    assert staging_runner.should_intercept(_job_dict(1, "deployer", "orchestrator", tid)) is False
+    # enabled, empty CSV -> self-hosting only.
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", True)
+    assert staging_runner.applies("orchestrator") is True
+    assert staging_runner.applies("enduro-trails") is False
+    # the strategy flag defaults to host-side (prod).
+    assert cfg.settings.staging_runner_exec_host_side is True
+
+
+def test_tc09_host_side_off_falls_back_to_in_container(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "staging_runner_exec_host_side", False)
+    cmd = staging_runner.build_staging_command()
+    assert cmd[:2] == ["docker", "exec"]               # rollback knob -> prior 1:1 shape
+
+
+def test_tc09_host_side_on_but_no_target_falls_back(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "deploy_ssh_host", "")
+    cmd = staging_runner.build_staging_command()
+    assert cmd[:2] == ["docker", "exec"]               # no target -> in-container fallback
+
+
+# ---------------------------------------------------------------------------
+# TC-10 — artifact contract: staging_status frontmatter + 52c schema (AC-7)
+# ---------------------------------------------------------------------------
+def test_tc10_artifact_contract_unchanged():
+    body = staging_runner.build_staging_log("ORCH-123", 0, "SUCCESS", "ok")
+    assert "staging_status: SUCCESS" in body            # UPPERCASE machine key, unchanged
+    for field in ("work_item: ORCH-123", "stage: deploy-staging",
+                  "author_agent: staging-runner", "model_used: n/a"):
+        assert field in body
+    # The UNCHANGED gate parser reads the runner's frontmatter.
+    from src.qg.checks import _parse_staging_status
+    ok, _r = _parse_staging_status(body)
+    assert ok is True
+    bad, _r2 = _parse_staging_status(staging_runner.build_staging_log("ORCH-123", 1, "FAILED"))
+    assert bad is False
+
+
+# ---------------------------------------------------------------------------
+# TC-11 — pipeline anti-regress: gate / transitions / schema untouched (AC-7)
+# ---------------------------------------------------------------------------
+def test_tc11_pipeline_contract_unchanged():
+    from src.stages import STAGE_TRANSITIONS
+    from src.qg.checks import QG_CHECKS
+    assert STAGE_TRANSITIONS["deploy-staging"] == {
+        "next": "deploy", "agent": "deployer", "qg": "check_staging_status"
+    }
+    assert "check_staging_status" in QG_CHECKS
+    conn = get_db()
+    tables = {r[0] for r in conn.execute(
+        "SELECT name FROM sqlite_master WHERE type='table'").fetchall()}
+    conn.close()
+    assert not any("staging_runner" in t for t in tables)   # no DB migration
+
+
+# ---------------------------------------------------------------------------
+# TC-12 — never-raise / queue not wedged + observability distinguishes classes
+# ---------------------------------------------------------------------------
+def test_tc12_run_gate_never_raises(monkeypatch):
+    tid = _make_task("deploy-staging")
+
+    def boom():
+        raise RuntimeError("ssh exploded")
+    monkeypatch.setattr(staging_runner, "run_staging_suite", boom)
+    staging_runner.run_staging_gate(_job_dict(1, "deployer", "orchestrator", tid))  # must NOT raise
+
+
+def test_tc12_snapshot_distinguishes_classes():
+    snap = staging_runner.snapshot()
+    for k in ("enabled", "exec_host_side", "failed", "deferred", "permanent_env", "preflight"):
+        assert k in snap, f"snapshot missing key {k}"
+    # The three non-success classes are distinct keys (code-fail vs transient vs env).
+    assert {"failed", "deferred", "permanent_env"} <= set(snap)
+
+
+def test_tc12_snapshot_never_raises(monkeypatch):
+    class Boom:
+        def __getattr__(self, name):
+            raise RuntimeError("boom")
+    monkeypatch.setattr(staging_runner, "settings", Boom())
+    assert staging_runner.snapshot()["enabled"] is False
+
+
+# ---------------------------------------------------------------------------
+# R-2 — a held deploy-staging task is NOT rolled back to development by the
+# reconciler (the defect would re-appear if it were). AC-3 / AC-11.
+# ---------------------------------------------------------------------------
+def test_r2_held_deploy_staging_not_rolled_back(monkeypatch):
+    tid = _make_task("deploy-staging")
+    # No 15-staging-log.md was written (infra-HOLD) -> check_staging_status is red.
+    advance = MagicMock()
+    monkeypatch.setattr(stage_engine, "advance_stage", advance)
+
+    result = stage_engine.advance_if_gate_passed(
+        tid, "deploy-staging", "orchestrator", "ORCH-123", "feature/ORCH-123-x"
+    )
+
+    assert result is None                               # red gate -> stay, no advance call
+    advance.assert_not_called()                          # NEVER rolled back to development
+    conn = get_db()
+    stage = conn.execute("SELECT stage FROM tasks WHERE id=?", (tid,)).fetchone()[0]
+    conn.close()
+    assert stage == "deploy-staging"                     # held in place
+
+
+# ---------------------------------------------------------------------------
+# TC-13 — documentation of the execution boundary (AC-12)
+# ---------------------------------------------------------------------------
+def _repo_root():
+    return os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
+
+
+def test_tc13_docs_describe_execution_boundary():
+    root = _repo_root()
+    with open(os.path.join(root, "docs/operations/INFRA.md"), encoding="utf-8") as f:
+        infra = f.read().lower()
+    with open(os.path.join(root, "docs/architecture/README.md"), encoding="utf-8") as f:
+        readme = f.read().lower()
+    # INFRA.md fixes the boundary: no docker CLI in the container; docker ops host-side.
+    assert "host-side" in infra
+    assert "docker" in infra and "ssh" in infra
+    assert "orch-123" in infra
+    # README describes the host-side staging-runner strategy.
+    assert "orch-123" in readme
+    assert "host-side" in readme
+
+
+# ---------------------------------------------------------------------------
+# TC-14 — anti-drift ORCH-115: invariants intact (kill-switch -> LLM, shared map)
+# ---------------------------------------------------------------------------
+def test_tc14_orch115_invariants_intact(monkeypatch):
+    # Kill-switch off -> the single LLM transport path is restored (no intercept).
+    monkeypatch.setattr(cfg.settings, "staging_runner_enabled", False)
+    tid = _make_task("deploy-staging")
+    assert staging_runner.should_intercept(_job_dict(1, "deployer", "orchestrator", tid)) is False
+    # The exit-code mapping is still the SAME shared self_deploy contract (no drift).
+    from src import self_deploy
+    for v in (0, 1, None, "x"):
+        assert staging_runner.map_exit_code_to_status(v) == self_deploy.map_exit_code_to_status(v)