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

.env.example

@@ -24,19 +24,6 @@ ORCH_PLANE_BOT_REVIEWER=
 ORCH_PLANE_BOT_TESTER=
 ORCH_PLANE_BOT_DEPLOYER=
 ORCH_PLANE_BOT_STREAM=
-# ORCH-117: sandbox-only fail-closed guard for Plane WRITES from a test/worktree
-# process (regression of ORCH-114, where pytest mutated a live prod board issue).
-# In the live runtime (uvicorn, no pytest) the guard is a no-op; in a test process
-# it BLOCKS every Plane write unless BOTH the opt-in is true AND the target project
-# is in the sandbox allowlist. Defaults are SAFE (default-deny): leave both as-is.
-#   ORCH_PLANE_TEST_WRITE_ENABLED -> opt-in for REAL Plane writes from a test process.
-#     false (default) = no test may write to Plane. NOT a kill-switch for the prod
-#     block: even true, only the sandbox allowlist below is writable (a prod write
-#     from pytest stays impossible).
-#   ORCH_PLANE_TEST_SANDBOX_PROJECTS -> CSV allowlist of sandbox project ids the
-#     opt-in may write to. Default = the single SANDBOX project; empty = none.
-ORCH_PLANE_TEST_WRITE_ENABLED=false
-ORCH_PLANE_TEST_SANDBOX_PROJECTS=8c5a3025-4f9d-4190-b79f-fa06276bb27e
 # Telegram live-tracker / alerts (empty -> notifications are logged, not sent).
 ORCH_TELEGRAM_BOT_TOKEN=
 ORCH_TELEGRAM_CHAT_ID=
@@ -230,28 +217,9 @@ ORCH_TASK_DEPS_SOURCE=db
 #   SERIAL_GATE_ENABLED=false -> claim AND start_pipeline are 1:1 as before ORCH-088.
 #   SERIAL_GATE_REPOS (CSV) -> scope; EMPTY = ALL repos (not self-hosting-only).
 #   SERIAL_GATE_FREEZE_ENABLED=false -> the rollback-freeze layer is off (not set/read).
-#   SERIAL_GATE_PAUSE_ENABLED (ORCH-124) -> per-task "park" axis. true (default) -> a
-#     task with tasks.paused_at NOT NULL (POST /serial-gate/pause?work_item=<id>) is
-#     excluded from the "active task" predicate so an URGENT successor may overtake a
-#     paused predecessor. TRUE no-op until an operator pauses a task. false -> pause-term
-#     omitted, serial-gate byte-for-byte ORCH-088/090. Scope reuses SERIAL_GATE_REPOS.
 ORCH_SERIAL_GATE_ENABLED=true
 ORCH_SERIAL_GATE_REPOS=
 ORCH_SERIAL_GATE_FREEZE_ENABLED=true
-ORCH_SERIAL_GATE_PAUSE_ENABLED=true
-# ORCH-120 (adr-0053): analyst open-questions -> Needs Input. Activates the dead
-# "analyst asks BLOCKING questions -> 01-questions.md -> Needs Input" path in
-# _handle_analysis_approved_flow. Additive, never-raise, self-hosting scope;
-# STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict / DB schema UNCHANGED.
-#   ANALYST_QUESTIONS_GATE_ENABLED=false -> _handle_analysis_approved_flow runs its
-#     ORIGINAL pre-ORCH-120 order (files_ok first, then flat isfile check) byte-for-byte.
-#   ANALYST_QUESTIONS_GATE_REPOS (CSV) -> scope; EMPTY = self-hosting only (orchestrator).
-#   ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED=true (default) -> auto-park a Needs-Input task
-#     (db.set_task_paused) so the repo serial-gate FIFO does not wedge while we wait for a
-#     human; unpark on resume. false -> operator-park only (POST /serial-gate/pause).
-ORCH_ANALYST_QUESTIONS_GATE_ENABLED=true
-ORCH_ANALYST_QUESTIONS_GATE_REPOS=
-ORCH_ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED=true
 # ORCH-090: STOP-status task cancellation (stop active agent + full progress reset)
 # and the relaunch-hole close. A dedicated Plane "STOP" status (logical key `stop`,
 # fail-closed: absent from _DEFAULT_STATES, so a board without the status -> no-op)
@@ -282,32 +250,6 @@ ORCH_STOP_STATUS_REPOS=
 ORCH_BUG_FAST_TRACK_ENABLED=true
 ORCH_BUG_FAST_TRACK_LABEL=Bug
 ORCH_BUG_FAST_TRACK_REPOS=
-# ORCH-020: task-estimation side-mechanism, triggered by the operator Plane status
-# «Оценка» (3rd action-status, family STOP/Confirm Deploy). A leaf src/estimator.py
-# (never-raise) forecasts cost/time/tokens/story-points from the history of completed
-# tasks (deterministic, NO LLM), writes the forecast to Plane (estimate_point + comment),
-# the Telegram card and the additive task_estimates ledger, then returns the issue to
-# Backlog. On completion the fact is written to Plane `point`. OBSERVER/PRODUCER, never a
-# Quality Gate / stage. Infra precondition: create a board status «Оценка» (group
-# backlog/unstarted, NEVER completed/cancelled) + a Points estimate-system 1,2,3,5,8.
-#   ESTIMATOR_ENABLED=false   -> the «Оценка» status is not handled, nothing written
-#                                (1:1 as before ORCH-020, zero regression).
-#   ESTIMATOR_REPOS (CSV)     -> scope; EMPTY = self-hosting only (orchestrator).
-#   ESTIMATOR_MIN_SAMPLES     -> history size below which the bootstrap default blends in.
-#   ESTIMATOR_BOOTSTRAP_*     -> cold-start tokens/cost_usd/seconds when history is empty.
-#   ESTIMATOR_SP_COST_THRESHOLDS -> 4 ascending cost cut-offs (t1,t2,t3,t5) for the
-#                                story-point bucket (<=t1->1 .. <=t5->5, else 8).
-#   ESTIMATOR_WALL_CAP_S      -> cap on anomalous wall-time in history (default 24h).
-#   ESTIMATOR_MAX_INFLIGHT    -> optional bulk-smoothing semaphore (v1 generous/off).
-ORCH_ESTIMATOR_ENABLED=true
-ORCH_ESTIMATOR_REPOS=
-ORCH_ESTIMATOR_MIN_SAMPLES=3
-ORCH_ESTIMATOR_BOOTSTRAP_TOKENS=2000000
-ORCH_ESTIMATOR_BOOTSTRAP_COST_USD=3.0
-ORCH_ESTIMATOR_BOOTSTRAP_SECONDS=1800
-ORCH_ESTIMATOR_SP_COST_THRESHOLDS=0.50,2.00,5.00,12.00
-ORCH_ESTIMATOR_WALL_CAP_S=86400
-ORCH_ESTIMATOR_MAX_INFLIGHT=64
 # ORCH-094: terminal-window-aware guard for the three deploy-phase Plane status
 # setters (set_issue_awaiting_deploy / set_issue_deploying / set_issue_monitoring).
 # A DB stage=done task converges to Done idempotently instead of flapping
@@ -492,18 +434,6 @@ ORCH_REAPER_MAX_RUNNING_S=5400
 ORCH_REAPER_FINALIZE_GRACE_S=300
 ORCH_LEASE_RECLAIM_ENABLED=true
 
-# ORCH-126 (adr-0052): run-ownership hygiene of the `jobs` row — invariant
-# `status='queued' => run_id IS NULL AND pid IS NULL AND started_at IS NULL`. The BASE
-# reset on every requeue/claim path (requeue_running_jobs / mark_job('queued') /
-# mark_job_transient / reap_running_job('queued') / claim_next_job) is UNCONDITIONAL
-# (no flag — it fixes a data invariant). This kill-switch gates ONLY the optional
-# detect/self-heal sweep of "impossible" queued rows (a queued job still carrying
-# run_id/pid/started_at — the incident state of job 2286) run at startup + on each
-# reaper tick, plus its read-only /queue counter (reaper.impossible_queued_total).
-#   IMPOSSIBLE_QUEUED_SANITIZE_ENABLED -> default true; false -> the sweep is a no-op
-#                                         (D1-D3 still enforce the invariant going forward).
-ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED=true
-
 # ORCH-114 (adr-0045): durable transition-ownership lease + expected-stage CAS for
 # side-effectful stage transitions. Generalises the process-local ORCH-113 finalizer-
 # liveness into a DURABLE, cross-path owner-exclusion (additive table `transition_lease`)
@@ -614,62 +544,6 @@ ORCH_COVERAGE_EPSILON=0.5
 ORCH_COVERAGE_TOOL_FAIL_CLOSED=false
 ORCH_COVERAGE_RUN_TIMEOUT_S=900
 
-# ORCH-115: deterministic staging-runner replacing the LLM `deployer` on the
-# `deploy-staging` stage (self-hosting orchestrator). Intercepted in launch_job
-# BEFORE _spawn (deploy-finalizer / post-deploy-monitor precedent): runs the same
-# staging suite, maps exit-code -> staging_status:, writes 15-staging-log.md and
-# initiates the UNCHANGED check_staging_status gate. Replaces only the producer of
-# the artifact; the gate / STAGE_TRANSITIONS / DB schema are byte-for-byte unchanged.
-# See ADR-001-deterministic-staging-runner.md / adr-0048.
-#   STAGING_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM deployer
-#                                        runs on deploy-staging via _spawn 1:1.
-#   STAGING_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only.
-#   STAGING_RUNNER_TIMEOUT_S          -> wall-clock budget for the docker-exec suite
-#                                        (malformed/non-positive -> default 600 + WARNING).
-#   STAGING_RUNNER_INFRA_MAX_RETRIES  -> transient-infra (timeout/ssh) bounded DEFER
-#                                        budget before an infra-HOLD (anti ORCH-110).
-#   STAGING_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued deployer job.
-#   STAGING_RUNNER_EXEC_HOST_SIDE     -> ORCH-123 (adr-0049): true (default = prod) wraps
-#                                        the `docker exec` in `ssh <user@host> '<...>'` so
-#                                        the suite runs HOST-SIDE (the prod container ships
-#                                        no docker CLI; incident ORCH-116). false -> the
-#                                        prior in-container `docker exec` (valid only where
-#                                        a docker CLI is baked into the image). Rollback knob.
-ORCH_STAGING_RUNNER_ENABLED=true
-ORCH_STAGING_RUNNER_REPOS=
-ORCH_STAGING_RUNNER_TIMEOUT_S=600
-ORCH_STAGING_RUNNER_INFRA_MAX_RETRIES=2
-ORCH_STAGING_RUNNER_INFRA_RETRY_DELAY_S=30
-ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true
-
-# ORCH-116: deterministic test-runner replacing the LLM `tester` agent on the
-# `testing` stage for the self-hosting orchestrator (2nd determinization slice,
-# mirror of the ORCH-115 staging-runner). A leaf src/test_runner.py is intercepted
-# in launch_job BEFORE _spawn: it runs the SAME regression `python -m pytest <target>`
-# in the task worktree (+ optional read-only smoke), maps the exit-code -> result:
-# PASS|FAIL, writes 13-test-report.md and initiates the UNCHANGED check_tests_passed
-# gate. Replaces only the producer of the artifact; the gate / STAGE_TRANSITIONS / DB
-# schema are byte-for-byte unchanged. See ADR-001-deterministic-test-runner.md / adr-0050.
-#   TEST_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM tester runs on
-#                                     testing via _spawn 1:1.
-#   TEST_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only. A repo with
-#                                     no resolvable test-contract is never intercepted (BR-9).
-#   TEST_RUNNER_TARGET            -> pytest target of the test-contract (default tests/).
-#   TEST_RUNNER_TIMEOUT_S          -> wall-clock budget for the pytest regression
-#                                     (malformed/non-positive -> default 900 + WARNING).
-#   TEST_RUNNER_SMOKE_ENABLED      -> optional read-only smoke (/health,/status,/queue +
-#                                     serial_gate block); false -> pytest exit-code is the sole signal.
-#   TEST_RUNNER_INFRA_MAX_RETRIES  -> tool-error (suite did NOT execute) bounded DEFER
-#                                     budget before a fail-closed FAIL (anti ORCH-110).
-#   TEST_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued tester job.
-ORCH_TEST_RUNNER_ENABLED=true
-ORCH_TEST_RUNNER_REPOS=
-ORCH_TEST_RUNNER_TARGET=tests/
-ORCH_TEST_RUNNER_TIMEOUT_S=900
-ORCH_TEST_RUNNER_SMOKE_ENABLED=true
-ORCH_TEST_RUNNER_INFRA_MAX_RETRIES=2
-ORCH_TEST_RUNNER_INFRA_RETRY_DELAY_S=30
-
 # ORCH-057 (follow-up ORCH-040): legacy root-owned ownership detect + actionable
 # worktree error. After the uid migration (user: "1000:1000") legacy root:root files
 # in /repos broke worktree creation under uid 1000 with a raw "Permission denied".

.openclaw/agents/analyst.md

@@ -40,21 +40,6 @@ bug-report (симптом / шаги воспроизведения / лока
 **сложным/архитектурным/визуальным** (нужен ADR или макет) — выпусти **полный** analysis-пакет и
 помечай в bug-report `escalate: full-cycle` (эскалация в полный цикл, ADR-001 D5 ORCH-019); оператор
 снимает багфикс-трек эндпоинтом `POST /bug-fast-track/escalate`.
-
-**Блокирующие вопросы → Needs Input (ORCH-120, adr-0053).** Если бизнес-запрос **блокирующе**
-неоднозначен и выпустить корректные 4 deliverables нельзя без ответа заказчика — **НЕ фабрикуй**
-требования ради сдачи файлов. Вместо этого через **Write tool** запиши
-`docs/work-items/<plane-id>/01-questions.md` (скелет — `docs/_templates/01-questions.md`) со списком
-**конкретных** блокирующих вопросов (с вариантами и тем, что разблокирует анализ). Наличие активных
-вопросов уводит задачу в **Needs Input** (движок `_handle_analysis_approved_flow` ставит статус +
-комментирует вопросы в Plane) — **приоритетно** над «файлы готовы». Это сигнальный артефакт (гейтом
-не парсится), пиши его ТОЛЬКО при реальных блокерах.
-
-**Поведение на перезапуске (resume).** После ответа заказчика в Plane тебя перезапускают: прочитай
-**свежие комментарии-ответы**, затем (а) если все блокеры сняты — выпусти **полный** валидный пакет
-(4 файла); свежий пакет автоматически **supersede’ит** старый `01-questions.md` по mtime (повторного
-Needs Input не будет); (б) если часть вопросов осталась — **перепиши** `01-questions.md`, оставив
-только актуальные блокеры (снова Needs Input). Не оставляй устаревшие вопросы вперемешку с новыми.
 </task>
 
 <deliverables>
@@ -67,10 +52,6 @@ Needs Input не будет); (б) если часть вопросов оста
 | `03-acceptance-criteria.md` | Критерии приёмки (чёткие условия PASS/FAIL) |
 | `04-test-plan.yaml` | План тестов (unit, integration; pytest) |
 
-**When-applicable (сигнальный, ORCH-120):** `01-questions.md` — пишется **только** при блокирующих
-открытых вопросах (см. `<task>`) **вместо** сфабрикованных 4 файлов; скелет —
-`docs/_templates/01-questions.md`. Не machine-verdict, гейтом не парсится.
-
 **Скелеты:** бери из `docs/_templates/` (одноимённые файлы) — не угадывай структуру.
 **Эталон качества/полноты:** заполненные work item **ORCH-088** и **ORCH-073** —
 ориентируйся на их детальность и формат.

.openclaw/agents/deployer.md

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

.openclaw/agents/tester.md

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

.task-dev.md

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

CHANGELOG.md

@@ -3,106 +3,6 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
-- **Оценка задачи, запускаемая Plane-статусом «Оценка»** (ORCH-020, `feat`): новый операторский
-  Plane-статус **«Оценка»** — третий член семейства action-статусов (STOP/Confirm Deploy) — запускает
-  **новый leaf `src/estimator.py`** (never-raise, kill-switch + скоуп), прогнозирующий
-  **стоимость / время / токены / сложность (story points `{1,2,3,5,8}`)** по истории завершённых задач
-  (детерминированная эвристика, **без LLM** — ADR-001 D1). Перевод issue в «Оценка» (в т.ч. **массово**
-  через Plane multi-select → N независимых вебхуков) → `handle_estimate`: прогноз (a) пишется в Plane-поле
-  `estimate_point` (через estimate-систему Fibonacci) + Plane-комментом, (b) добавляется пунктом «Оценка»
-  (время·токены·стоимость·SP) в Telegram-карточку, (c) сохраняется в **новой аддитивной таблице**
-  `task_estimates` (UPSERT по `work_item_id` → идемпотентная пере-оценка), после чего issue **возвращается
-  в Backlog** (анти-loop: Backlog не совпадает ни с одной триггер-веткой). По завершении задачи (переход в
-  `done`) **факт** (из `usage.py`) пишется в Plane-поле `point` (не затирая прогноз). Анти-disruption:
-  issue с активным job не выдёргивается (`should_estimate`). story-points — чистая функция-бакетизатор по
-  стоимости (пороги конфигурируемы). **Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не**
-  Quality Gate и **не** ребро стадий — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи/схемы
-  существующих таблиц байт-в-байт не тронуты; горячий путь `resolve_agent_model`/`_spawn` не трогается.
-  Fail-closed: ключ `estimate` отсутствует в `_DEFAULT_STATES` → доска без статуса → ветка инертна
-  (зеркало STOP/Confirm Deploy). Опц. эндпоинты `POST /estimate`/`GET /estimate` (то же ядро) + read-only
-  блок `estimator` в `GET /queue`. Флаги `ORCH_ESTIMATOR_*` (`enabled` kill-switch, `repos` CSV — **пусто →
-  self-hosting only**, bootstrap-дефолты, пороги story-points). Откат = `ORCH_ESTIMATOR_ENABLED=false` →
-  модуль инертен (нулевая регрессия; enduro не затронут). Онбординг-канон расширен 23-м статусом «Оценка»
-  (группа `unstarted`, НЕ терминальная). Витрина системы `docs/overview/` обновлена под новую
-  операторскую способность «Оценка» (бизнес-способность + сценарий в `business.md`, слайды
-  `presentation.md`, статус-жест в `tech-pipeline.md`/`tech-integrations.md`, таблица
-  `task_estimates` в `tech-data-model.md`, блок `estimator`/пункт карточки в `tech-observability.md`;
-  переформулировано устаревшее «управляющих статусов ровно три» → семейство операторских
-  статусов-действий). Покрытие — `tests/test_orch020_estimator.py` (TC-01…TC-20) +
-  `tests/test_orch020_estimator_branches.py` (ветви never-raise / fail-safe / edge: история-форкаст,
-  bootstrap-блендинг, все `except`-арки leaf'а, малформ-входы бакетизатора, опц. `/estimate`-эндпоинты,
-  парс estimate-системы Plane и degenerate-пути вебхука — `src/estimator.py` 74%→99.5%, гейт покрытия
-  `src/` зелёный). Детали —
-  `docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md`, сквозной
-  `docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`.
-- **FAQ по статусу STOP для пользователя доски** (ORCH-108, `docs`): создан пользовательский
-  FAQ `docs/operations/FAQ_STOP.md` в формате «вопрос → ответ» — что делает STOP, как отменить
-  задачу, что происходит пошагово (агент останавливается → job'ы снимаются → рабочая ветка и
-  worktree удаляются → задача → `cancelled` → Telegram+Plane; **docs-артефакты сохраняются**,
-  `main`/прод не трогаются), отложенная отмена в критичном окне (merge/deploy), явное «STOP **не
-  откатывает** влитый в `main`/прод код» (revert — отдельная задача), перезапуск только через
-  «To Analyse» с нуля, причины no-op («ничего не произошло»), где увидеть результат, и разведение
-  STOP/Approved/Confirm Deploy. **docs-only:** `src/**` / `STAGE_TRANSITIONS` / `QG_CHECKS` /
-  `check_*` / machine-verdict / схема БД — байт-в-байт не тронуты; поведение STOP — источник истины
-  ORCH-090 (`adr-0026`), FAQ его лишь документирует и ссылается, не форкая (link-first: машинные
-  детали маркеры/lease/тумбстон — только ссылками). Добавлены двусторонние перекрёстные ссылки:
-  витрина `docs/overview/business.md` (Сценарий 6) и обзор `docs/overview/tech-pipeline.md`
-  («Отмена: STOP → `cancelled`») → FAQ; FAQ → обзор + ADR ORCH-090. Структуру FAQ закрывает
-  детерминированный анти-дрейф тест `tests/test_faq_stop_doc.py` (offline, без сети/LLM/subprocess;
-  образец `tests/test_lite_setup_doc.py`): существование + 8 секций-якорей + факты-«кирпичи» +
-  кросс-ссылки + **негативный скан запрещённых утверждений на уровне предложений, а не голых
-  подстрок** (не фолзит на корректно отрицающих фразах — TR-3, проверено non-evergreen-самочеком).
-  **Норматив сопровождения:** правишь поведение STOP (`src/cancel.py` / `cancel_task` / маршрут
-  `stop`) → обнови `docs/operations/FAQ_STOP.md` в том же PR. ADR:
-  `docs/work-items/ORCH-108/06-adr/ADR-001-faq-stop-placement-and-anti-drift.md`.
-- **Source-backed `00-business-request.md` вместо хардкода `TBD`** (ORCH-119, `fix`, Bug-трек): раздел «Description» файла `00-business-request.md` теперь несёт **фактический текст запроса** из Plane-issue (`description`/`description_stripped`) вместо литерала `TBD` — терялся source-backed контекст запроса. Фикс работает на **обоих** путях создания: прямой (путь A, `serial_gate` не применим — `start_pipeline` передаёт `description` в `_create_initial_docs`) и **отложенный срез ветки** (путь B, ORCH-088, доминирует на self-hosting `orchestrator`). Для пути B `description` **персистится durable** при создании задачи (аддитивная колонка `tasks.description` через `_ensure_column`, зеркало `tasks.title`, записывается **внутри того же атомарного INSERT** `create_task_atomic` — race-safe относительно анти-dup-claim ORCH-053) и читается из строки `tasks` в `launcher._spawn` → `_materialize_deferred_branch` на момент claim (без сетевого вызова в горячем пути, NFR-4). **Fail-safe (FR-4):** пустое/whitespace/`None`/нечитаемое описание → явный безопасный маркер `_(описание отсутствует в источнике)_` через чистый рендер-хелпер `_render_business_request` (never-raise; создание задачи не падает). **Идемпотентность:** Gitea 422 (файл существует) → no-op, ранее записанное тело не перезаписывается. **Инвариант (AC-5):** `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи — байт-в-байт; единственное изменение схемы — аддитивная `tasks.description` (базовый `CREATE TABLE tasks` не тронут); анти-stale-base инвариант ORCH-088 цел (момент/условие среза не меняются — только источник данных дополняется). Обратимость — revert PR (колонка остаётся инертной). Покрытие — `tests/test_orch119_business_request.py` (TC-01 обязательный регресс red→green; TC-02…TC-07). Дополнительно в том же PR починена **тест-гермеичность** `tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_not_rolled_back`: тест переиспользовал собственный (теперь смерженный в `main`) work-item id `ORCH-123`, и при дефолтном `repos_dir=/repos` staging-гейт через origin/main-fallback (`check_staging_status` → `_staging_log_from_main`) находил **реальный** `staging_status: SUCCESS`-лог ORCH-123 в `origin/main`, делая намеренно-красный гейт зелёным (флак проявлялся только в полном прогоне сьюта — singleton `repos_dir` берётся из первого импортирующего config файла, побеждая import-time `ORCH_REPOS_DIR=/tmp` этого модуля); autouse-фикстура `fresh_db` теперь пинит `repos_dir` в изолированный пустой tmp-каталог (зеркало уже пиннимого `worktrees_dir`), сохраняя проверяемость инварианта ORCH-123 R-2 (infra-held `deploy-staging` удерживается, не откатывается в `development`) независимо от порядка тестов. ADR: `docs/work-items/ORCH-119/06-adr/ADR-001-source-backed-business-request-doc.md`.
-- **Открытые вопросы аналитика → Needs Input (приоритет, неблокирование serial-gate, resume)** (ORCH-120, `fix`, трек Bug→escalate full-cycle): активирован и достроен ранее **мёртвый** путь «аналитик задаёт блокирующие вопросы → `01-questions.md` → Needs Input». Четыре согласованных изменения, аддитивно, под kill-switch, скоуп self-hosting, never-raise; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты** (поток — pre-gate-ветка движка, **не** Quality Gate; `01-questions.md` — **сигнальный** артефакт, **не** machine-verdict). (1) **Контракт + канон.** `.openclaw/agents/analyst.md` документирует канал «блокирующие вопросы → `01-questions.md`, НЕ фабриковать deliverables» + поведение на resume; новый скелет `docs/_templates/01-questions.md`; строка манифеста + примечание о префиксе `01-` в `docs/_standards/PIPELINE_DOCS.md`. (2) **Приоритет «вопросы активны» > «файлы готовы»** в `_handle_analysis_approved_flow` (DQ-3): чистая логика решения вынесена в leaf `src/analyst_questions.py` (`questions_gate_applies`/`autopause_applies`/`questions_active`), side-effects — в `stage_engine` (`_decide_analysis_outcome`/`_emit_analysis_needs_input`/`_emit_analysis_in_review`/`_emit_analysis_empty`); блокирующие вопросы достигают Needs Input даже при сфабрикованном полном пакете. (3) **Авто-park (DQ-1)** при Needs Input через ось «пауза» ORCH-124 (`db.set_task_paused`) → задача исключается из «активного» предиката serial-gate (ORCH-088), FIFO репо не клинит, пока ждём человека; **resume + unpark** в `handle_status_start` (analysis-ветка, `db.clear_task_paused`). (4) **Гигиена устаревания (DQ-2)** — детерминированный offline freshness-supersede по `mtime` (вопросы активны, пока пакет неполон ИЛИ `01-questions.md` не старше всех 4 deliverables) → полный свежий пакет supersede’ит старый файл без зависимости от LLM (нет бесконечной петли Needs Input). Флаги (`config.py`, безопасные дефолты): `analyst_questions_gate_enabled` (kill-switch) / `analyst_questions_gate_repos` (CSV; **пусто → self-hosting only**) / `analyst_needs_input_autopause_enabled` (независимый тумблер авто-park/unpark; `False` → operator-park `POST /serial-gate/pause`). off/out-of-scope → байт-в-байт как до ORCH-120 (enduro не затронут); ORCH-066 (Needs Input только у аналитика) не расширяется. Покрытие — `tests/test_orch120_analyst_needs_input.py` (TC-01 обязательный регресс: красный до фикса, зелёный после), `tests/test_orch120_serial_gate_needs_input.py`, `tests/test_orch120_resume_unpark.py`, `tests/test_orch120_questions_artifact_canon.py` + assert в `tests/test_agent_prompts_canon.py`. Витрина системы `docs/overview/` обновлена в том же PR (ось ORCH-011): абзац пауз `tech-pipeline.md` и пункт `GET /queue` в `tech-observability.md` теперь называют **два** источника паузы (оператор + авто-park движком на Needs Input), `tech-agents.md` — when-applicable сигнальный канал `01-questions.md` у `analyst` (`tests/test_system_docs.py` зелёный). ADR: `docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md`, сквозной `docs/architecture/adr/adr-0053-analyst-open-questions-needs-input-flow.md`.
-- **Гигиена run-ownership строки `jobs` — инвариант «queued ⇒ run_id/pid/started_at IS NULL»** (ORCH-126, `fix`, трек Bug): багфикс контрол-плейна (инцидент ORCH-124/125) — при `ORCH_SERIAL_GATE_ENABLED=false` queued analyst-job'ы зависали навсегда (job 2286: `status=queued + run_id=759/760 + pid=35/42 + started_at=NULL` — физически невозможное состояние). **Причина:** ни один путь возврата job в `queued` (restart `requeue_running_jobs` / retry `mark_job('queued')` / transient `mark_job_transient` / reap `reap_running_job('queued')`) **не сбрасывал run-ownership** (`run_id`/`pid`); после рестарта контейнера pid мог быть **переиспользован** ОС → `pid_alive(stale)=True` → job-reaper (ORCH-065) Tier-1 «видел живой» фантомный `running` и при `max_concurrency=1` клинил клейм **всей** общей очереди всех проектов. **Инвариант (adr-0052):** `status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL` — queued-job никогда не несёт run-ownership (история run'а — в `agent_runs`, не в `jobs.run_id`). Фикс на **существующих колонках**: `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / `check_*` / machine-verdict-ключи / **схема БД** — байт-в-байт не тронуты; для здоровых job'ов и enduro поведение байт-в-байт; миграция не требуется. ADR: `docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md`, сквозной `docs/architecture/adr/adr-0052-queued-job-run-ownership-invariant.md`.
-  - **D1 — Forward-cleanup на всех путях возврата в `queued` (FR-1/AC-1):** `requeue_running_jobs` / `mark_job('queued')` / `mark_job_transient` / `reap_running_job('queued')` выставляют `run_id=NULL, pid=NULL` той же UPDATE-транзакцией, что чистит `started_at`/`finished_at`. Атомарные `status`-guard'ы (`reap_running_job … WHERE status='running'`, rowcount) — **сохранены байт-в-байт** (restart-safe, гонка worker↔reaper↔monitor — TR-4). Каллер-переданный `run_id` для `queued` **игнорируется** (инвариант важнее: `launcher._finalize_permanent`/reaper по-прежнему передают старый `run_id`, но для `queued` он сбрасывается). Безусловно — исправление инварианта данных, без флага (D6).
-  - **D2 — Чистый claim (FR-2/AC-3):** `claim_next_job` при флипе `queued→running` сбрасывает `pid=NULL, run_id=NULL` тем же существующим UPDATE (defense-in-depth поверх D1) → между claim и стампом `pid` в `_spawn` строка несёт `pid IS NULL`, не чужой pid. SELECT-гейт (`status='queued' AND available_at<=now` + dep/serial-gate) — **не тронут** (offline hot-path, NFR-2; без нового SELECT/сети).
-  - **D3 — Окно `_spawn` (FR-3/AC-6):** провал `_spawn` до стампа `pid` (`ensure_worktree`/материализация ветки/запись task-файла) → `queue_worker._drain_once` возвращает job через `mark_job('queued')` → по D1 строка чистая; повторный claim стартует штатно (без «частично стартовавшего» зависания). Нового кода в launcher не потребовалось.
-  - **D4 — Детект + self-heal невозможного состояния (FR-4/AC-5):** `db.find_impossible_queued_jobs()`/`db.sanitize_impossible_queued()` идемпотентно приводят «невозможные» queued-строки (`queued` с непустым `run_id`/`pid`/`started_at`) к чистому `queued`; вызывается при старте (`main.lifespan` после `requeue_running_jobs`) и на каждом реап-тике (`JobReaper.sanitize_impossible_queued_once`, never-raise) — закрывает уже-существующие аномалии на проблемной БД **без миграции** (TR-7) и забытый будущий 6-й путь возврата (TR-2). Наблюдаемость: структурный WARNING (`job_id`/`run_id`/`pid`) + read-only счётчик `impossible_queued_total`/`last_impossible_queued` в блоке `reaper` снимка `GET /queue`. Kill-switch `impossible_queued_sanitize_enabled` (env `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED`, дефолт on; гейтит **только** D4-sweep, базовый сброс D1-D3 безусловен).
-  - **D5 — Корректность reaper-liveness (FR-5/AC-4) — валидация, не правка:** после D1-D3 reaper на свежеклеймленном `running` видит `pid IS NULL` → Tier-1 (`job_reaper.py:245`: `if pid is not None and not pid_alive(pid)`) пропускает, сбрасывает streak; Tier-3 backstop (`reaper_max_running_s`) — без изменений. **Правка reaper не требуется** — фикс восстанавливает предусловие «`pid` отражает процесс ЭТОГО run'а». Маркированные инварианты ORCH-065/113/114/099 — сохранены (трассировка CLAUDE.md §9).
-  - **Покрытие:** `tests/test_orch126_queued_stale_run.py` (TC-01 — обязательный регресс, КРАСНЫЙ до фикса / ЗЕЛЁНЫЙ после: stale `running` → `requeue_running_jobs` → чистый `queued`; TC-02…TC-10: сброс на каждом пути, чистый claim, claim без старвейшна при serial-gate off, reaper не реапит `pid IS NULL`, self-heal идемпотентность + счётчик + kill-switch, окно `_spawn`, анти-регресс здорового job'а — терминальные исходы/`run_id`-линк не затронуты). Полный `pytest tests/ -q` — зелёный.
-  - **Доки:** `docs/architecture/internals.md` (раздел «Инвариант run-ownership строки `jobs`» + аннотации `jobs.run_id`/`pid` + queue-recovery), `.env.example` (флаг `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED` в блоке reaper); сквозной ADR `adr-0052` (уже заведён архитектором).
-- **Serial-gate «пауза без блокировки» — явный per-task park-сигнал** (ORCH-124, `fix`): багфикс (метка `Bug`, эскалирован в full-cycle) инцидента **ORCH-116/ORCH-123**. `serial_gate` определял «активную задачу репо» **исключительно по машинной стадии** `tasks.stage NOT IN ('done','cancelled')`, а Plane-статусы Backlog/Blocked/Needs-Input (слой B индикации, ORCH-066) **не меняют `tasks.stage`** (слой A) ⇒ приостановленный предшественник был неотличим от активного и держал FIFO-гейт закрытым против срочного успешника (ORCH-116 поставлен на паузу, чтобы пропустить фикс ORCH-123 — фикс не стартовал, пока ORCH-116 формально не `done`). У оператора не было чистого механизма «пауза без блокировки», отдельного от cancel (терминал) и от глобального выключения гейта. **Инвариант:** правка **планировщика очереди** (claim) и наблюдаемости, **не** Quality Gate — `STAGE_TRANSITIONS` / состав `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) / схемы существующих таблиц — **байт-в-байт не тронуты**. Аддитивно, под независимым под-флагом, never-raise, restart-safe, fail-OPEN на hot-claim сохранён. ADR: `docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`, сквозной `docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md`.
-  - **Механизм (D1):** явный durable DB-сигнал «park» на уровне задачи, инициируемый оператором через API — **не** маппинг Plane-статуса (перегружал бы слой A/B ORCH-066 / анти-паттерн ORCH-059) и **не** `task_deps` (моделирует обратное направление «B ждёт A»). Чистое намерение, отличное от cancel и от kill-switch; DB-резолвимо, offline, webhook-независимо (потерянный webhook не рассинхронит сигнал).
-  - **Хранилище (D2):** аддитивная нуллабельная колонка `tasks.paused_at TEXT` через `_ensure_column` (паттерн `tasks.cancelled_at`/`cancel_requested_at`/`track`; `src/db.py`) — NULL = не на паузе; ISO-таймстамп = поставлена оператором на паузу. На уже-мигрированной БД — no-op; все существующие строки дефолтят в NULL ⇒ поведение до ORCH-124 до первой явной паузы (enduro не затронут на общей прод-БД). Хелперы `db.set_task_paused`/`clear_task_paused`/`is_task_paused` (never-raise; `is_task_paused` на ошибке → «не на паузе» = задача активна = гейт скорее закрыт = анти-stale-base-safe).
-  - **Ортогональная ось (D3, критично):** «активность» для serial-gate = `stage NOT IN ('done','cancelled') AND paused_at IS NULL`; **терминал `{done,cancelled}` остаётся байт-в-байт** в `serial_gate`/`task_deps`/`stages.py` (adr-0026 не регрессирует). `task_deps`/`stages.py` колонку `paused_at` **НЕ читают** ⇒ паузнутая объявленная зависимость (`job_deps`) и `repo_freeze` **по-прежнему блокируют** claim (пауза их **не** обходит — разные оси: freeze = весь репо, dependency = конкретная пара, пауза = «пропустите меня в FIFO»).
-  - **Три точки согласованно (D4, анти-дрейф):** один предикат «активна» под под-флагом — терм `AND t2.paused_at IS NULL` внутри существующего `EXISTS`-подзапроса `build_claim_clause` (горячий offline SQL, без лишнего JOIN), `AND paused_at IS NULL` в `repo_has_active_task` и в выборе `active_task` `_per_repo_snapshot` (`src/serial_gate.py`). Помечено маркером `ORCH-124` рядом с `ORCH-088`/`ORCH-090`.
-  - **Операторские эндпоинты (D7):** `POST /serial-gate/pause?work_item=<id>` (стамп `paused_at`; терминальная/неизвестная задача → no-op-ответ; под-флаг off → no-op-предупреждение) и `POST /serial-gate/resume?work_item=<id>` (сброс `paused_at` → задача снова участвует в гейте; идемпотентно) — по образцу `POST /serial-gate/unfreeze`, never-raise, с Telegram-подтверждением (`src/main.py`).
-  - **Анти-stale-base при resume (D8, R-1):** новой rebase-машинерии **нет** — свежесть базы гарантируют существующие механизмы: паузнутая-в-`analysis` задача при resume режет ветку отложенно (ORCH-088) от свежего `origin/main` с кодом успешника; материализованная — ребейзится на merge-gate (`auto_rebase_onto_main` под merge-lease ORCH-026/093) + re-test (ORCH-110). Нормальная задача (`paused_at IS NULL`) по-прежнему держит гейт ⇒ анти-stale-base для нормального случая (ORCH-088) **не регрессирует**.
-  - **Наблюдаемость (D5):** блок `serial_gate` в `GET /queue` дополнен ключом `paused` (список приостановленных незавершённых задач репо — НЕ показываются как `active_task`) и `reason` ожидания у каждого waiting-job с приоритетом `freeze` → `dependency` → `active-task` → `null`; существующие ключи снапшота (`active_task`/`waiting`/`frozen`/`frozen_reason`/`frozen_at`) — байт-в-байт (BC).
-  - **Условность/откат (D6):** независимый под-флаг `serial_gate_pause_enabled` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`, дефолт `True`; зеркало `serial_gate_freeze_enabled`; область переиспользует `serial_gate_repos`, новый `*_repos` не вводится). Дефолт `True` — **истинный no-op** до явной операторской паузы (`paused_at` всюду NULL). `False` ⇒ pause-терм опущен из SQL, эндпоинты no-op, serial-gate **байт-в-байт ORCH-088/090** (осознанный rollback-режим). Глубже — `serial_gate_enabled=false`.
-  - **Покрытие:** `tests/test_orch124_serial_gate_pause.py` (TC-01 обязательный регресс инцидента ORCH-116/ORCH-123 — красный до фикса, зелёный после; TC-02…TC-15: анти-регресс ORCH-088, durable/restart, resume, сохранность freeze/dependency, снапшот-reason, анти-дрейф 3 точек, offline hot-path, never-raise/fail-OPEN, kill-switch-нейтральность, структурный анти-регресс реестров/схем).
-  - **Доки:** обновлены `docs/architecture/README.md` (раздел serial-gate + ось «пауза без блокировки») и `docs/architecture/internals.md` (ось «пауза» ⊥ оси «терминальность»); сквозной ADR `adr-0051`. **Витрина системы `docs/overview/` (ORCH-011, синхронно в том же PR):** `tech-pipeline.md` (исключение FIFO «пауза без блокировки» рядом с freeze), `tech-data-model.md` (durable-сигнал `tasks.paused_at`), `tech-observability.md` (`paused`/`reason` в блоке `serial_gate` `GET /queue` + эндпоинты `pause|resume`). Зачищены протёкшие хвостовые теги tool-call (`</content>`/`</invoke>`) в 4 golden-source доках этого PR (`06-adr/ADR-001`, `adr-0051`, `08-data-requirements.md`, `10-tech-risks.md`).
-  - **Тест-гигиена (development-стадия, латентный регресс ORCH-123):** изолирован `settings.repos_dir` в фикстуре `tests/test_orch123_staging_runner_exec.py` (зеркально уже имевшейся изоляции `worktrees_dir`). `check_staging_status` при отсутствии фиче-worktree фолбэчит на `<repos_dir>/<repo>` (и его `origin/main`); после мержа ORCH-123 реальный `/repos/orchestrator/docs/work-items/ORCH-123/15-staging-log.md` (вердикт SUCCESS) появился на диске и делал предполагавшийся-КРАСНЫМ staging-гейт в `test_r2_held_deploy_staging_not_rolled_back` зелёным при полном прогоне `pytest tests/` (order-dependent: тест проходил в одиночку, падал в сьюте). Инвариант ORCH-123 R-2 («held `deploy-staging` не откатывается на `development`», adr-0049/ADR-001 D4) **сохранён и усилен** — изоляция лишь восстанавливает заявленную предпосылку теста «15-staging-log.md отсутствует ⇒ гейт красный». `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*` не тронуты (правка только теста).
-- **Детерминированный test-раннер вместо LLM-тестера на `testing`** (ORCH-116, `feat`): второй реализованный срез determinization-roadmap (ORCH-118 A5, `needs-hybrid-fallback`) — на стадии `testing` для self-hosting `orchestrator` **LLM-агент `tester` заменён детерминированным кодом** (`src/test_runner.py`). PASS/FAIL-ядро агента было деривируемым (регресс `pytest` + read-only smoke → `result:`); каждый прогон жёг токены/время opus-агента (~60–150k / 5–20 мин) и встраивал недетерминизм LLM в точку ветвления `testing → deploy-staging` / `testing → development`. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `13-test-report.md`, гейт `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`, machine-verdict `result:` (+ legacy `verdict:`/`status:`), схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting, гибрид (LLM строго off-control-path). Эталон — `src/staging_runner.py` (ORCH-115). ADR: `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`, сквозной `docs/architecture/adr/adr-0050-deterministic-test-runner.md`.
-  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="tester" and test_runner.should_intercept(job)` → `_run_test_runner_job` (зеркало `_run_staging_runner_job`, прецедент `deploy-finalizer`/`post-deploy-monitor`/`staging-runner` `launcher.py:397/402/405`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`, нет токенов). Дискриминатор — роль `tester` **И** стадия задачи `testing` (defense-in-depth: `tester` — единственный агент входа в `testing`, коллизии стадий нет, в отличие от общей роли `deployer`) **И** `applies(repo)`; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути).
-  - **Leaf `src/test_runner.py` (новый, чистый never-raise):** по образцу `staging_runner`/`self_deploy`/`proc_group` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications` — лениво). `applies(repo)` = kill-switch `test_runner_enabled` + скоуп `test_runner_repos` (пусто → self-hosting only) **И** резолв тест-контракта `_has_test_contract` (BR-9: репо без контракта → `False` → LLM-tester — enduro-trails 1:1 как до ORCH-116, даже если руками добавлен в CSV). Исполняет регресс `python -m pytest <test_runner_target>` **в worktree ветки** (`git_worktree.get_worktree_path`, анти checkout-гонка ORCH-112) через `proc_group.run_in_process_group` (tree-kill, таймаут `test_runner_timeout_s=900`, малформ/непозитив → дефолт + WARNING) + опц. **read-only smoke** (`/health`/`/status`/`/queue` + блок `serial_gate`, stdlib `urllib`; транзиентная недостижимость — ограниченный ретрай, не-200/нет блока — немедленный FAIL; `test_runner_smoke_enabled`). Маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе/None→`FAIL`, fail-closed; smoke-провал AND-ится в `FAIL`); пишет `13-test-report.md` (тот же machine-key `result:` UPPERCASE + 52c-схема, `author_agent: test-runner`/`model_used: n/a`) + best-effort push в **фичеветку**; вызывает **существующий** `advance_stage(current_stage="testing", finished_agent="tester")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage` — граница O1).
-  - **Анти-коллизия 52c-`status:` ↔ парсер (D6.1, специфично для tester):** `_parse_tests_verdict` читает вердикт из **трёх** равноранговых полей (`verdict:`/`status:`/`result:`) с negative-token-priority. 52c-обязательное `status:` поэтому читается тем же парсером → раннер **ВСЕГДА выравнивает** `status:` по вердикту (`PASS → status: success`, `FAIL → status: failed`) — иначе негативный токен в `status:` при `result: PASS` дал бы ложный FAIL здорового прогона. Прибито unit-тестом через **неизменённый** парсер.
-  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAIL → тот же откат `testing → development` + developer-retry, что у FAIL-вердикта LLM, `stage_engine.py:849`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue **`tester`**-джоба с задержкой + restart-safe маркер `test-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `test_runner_infra_max_retries=2` → fail-closed `FAIL` + advance + INFRA-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь, **не** жжёт developer-retry на транзиентной инфре.
-  - **Гибрид (D11/BR-8/NFR-7):** в Phase 1 на `testing` (in-scope) вердикт `result:` производит **только** детерминированный раннер; LLM **не** вызывается в потоке управления вердикта. Архитектура не запрещает будущий **off-control-path** LLM-триаж падений / маппинг TC↔критерии после детерминированного FAIL (отдельная роль/джоб, **не** выносит и **не** переопределяет `result:`, **не** добавляет ребро в `STAGE_TRANSITIONS`) — в этом срезе не реализуется. Self-hosting safety: в командах раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push / правок `.env`; smoke строго read-only. Наблюдаемость — in-process счётчики (`runs`/`pass`/`fail`/`tool_error`/`deferred`) + read-only блок `test_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `test_runner_enabled`/`test_runner_repos`/`test_runner_target`/`test_runner_timeout_s`/`test_runner_smoke_enabled`/`test_runner_infra_max_retries`/`test_runner_infra_retry_delay_s` (env `ORCH_TEST_RUNNER_*`). Откат = `ORCH_TEST_RUNNER_ENABLED=false` → на `testing` снова LLM-`tester` через `_spawn` **байт-в-байт**.
-  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A5 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет tester как `avoidable=yes`/`axis=C`/`needs-hybrid-fallback`), `llm-determinization-roadmap.md` (rank 2 tester — ✅ реализован; инвариант «ровно один `first_slice = yes`» у rank 1 deployer цел), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/tester.md` (LLM-ветвь `testing` — fallback), `docs/architecture/README.md`/`internals.md`, витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`/`tech-quality-security.md`. Покрытие — `tests/test_orch116_test_runner.py` (TC-01…TC-14) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-15).
-- **Host-side исполнение staging-раннера + классификация environment-дефекта** (ORCH-123, `fix`, bug→escalate full-cycle): устранён инцидент **ORCH-116** — детерминированный staging-раннер (ORCH-115) вызывал `docker exec` **изнутри** прод-контейнера `orchestrator`, где **нет бинаря `docker`** (образ несёт только `openssh-client git curl`, `Dockerfile:11`; `/var/run/docker.sock` смонтирован, но клиента нет) → `Popen(["docker", …])` падал `FileNotFoundError` → ветка tool-error → инфра-DEFER×2 → fail-closed `FAILED` → **ложный** откат `deploy-staging → development` (как код-фейл, с расходом developer-retry). Так до фикса **любая** self-hosting задача, дойдя до `deploy-staging`, была обречена на ложный откат. Аддитивно, под флагами, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_staging_status`/`_parse_staging_status` / machine-verdict-ключи (`staging_status:`/`deploy_status:`) / схема БД — **байт-в-байт не тронуты** (замена *стратегии исполнения продюсера* `15-staging-log.md`, **не** гейта/стадии; зеркало инварианта ORCH-115 NFR-1). ADR: `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`, сквозной `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`.
-  - **Host-side ssh-стратегия (D1):** `staging_runner.build_staging_command()` теперь обёртывает ту же `docker exec orchestrator-staging python3 … staging_check.py … --mode stub` в `ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> '<docker exec …>'` (зеркало `self_deploy.build_deploy_command` / `image_freshness.image_revision(ssh_target=…)`); канал — существующий доверенный (`ORCH_DEPLOY_SSH_HOST=127.0.0.1`, ssh-ключ смонтирован `:ro`, `openssh-client` в образе) → **новых секретов/привилегий не вводится** (NFR-3). Меняется **инициатор/канал** запуска, **не** сама сюита (она по-прежнему бежит **внутри** `orchestrator-staging` 8501). **Security (D2):** docker CLI/SDK в контейнер **не добавляется**, `docker.sock` **не используется изнутри** — это было бы root-эквивалентным расширением поверхности атаки (доступным и LLM-агентам); host-side ssh достигает цели без расширения привилегий.
-  - **Трёхсторонняя классификация исхода (D3, чистая `classify_staging_outcome`, зеркало `merge_gate.classify_retest_failure`):** `suite-ran` (распознанный exit-код, кроме 255, **без** env-маркера в stderr → доверяем коду: `0→SUCCESS`/`≠0→FAILED`; анти-over-tolerance BR-3 — реальный фейл сюиты **никогда** не реклассифицируется в инфру), `permanent-env` (spawn-error `rc=None` без таймаута / нет ssh-target / `rc∈{126,127}` / env-маркер `No such container`/`Cannot connect to the Docker daemon`/`command not found` → ретрай бессмыслен), `transient-infra` (timeout / ssh transport `rc=255` / неизвестный сигнал → ретрай осмыслен). Дизамбигуация коллизии `exit=1` (`docker exec` «No such container»=1 vs суита fail=1) — **скан stderr на env-маркеры**, не голый exit-код; fail-safe при неоднозначности → `transient-infra` (DEFER), никогда тихий `suite-ran`.
-  - **Маршрутизация исходов (D4) — инвариант «инфра ≠ код-фейл»:** `suite-ran` → **без изменений** (ORCH-115): write `15-staging-log.md` + `advance_stage` (FAILED → прежний откат `deploy-staging → development` + developer-retry, байт-в-байт). `permanent-env` → **немедленный infra-HOLD**: DEFER пропускается (FR-3), `15-staging-log.md` **не** пишется (нет ложного FAILED), `advance` **не** зовётся, developer-retry **не** жжётся; структурный ERROR + операторский alert «инфра/окружение, НЕ дефект кода». `transient-infra` → существующий bounded DEFER, **но на исчерпании бюджета** — тоже **infra-HOLD + alert** (СУПЕРСЕД ORCH-115 D5: прежний fail-closed `write_staging_log("FAILED") + advance` ложно откатывал не-прояснившуюся инфру как код-фейл, нарушая BR-2). Корневой инвариант: «сюита **не** исполнилась» (environment ИЛИ инфра) **никогда** не оканчивается код-фейл-откатом `→ development` и **никогда** не жжёт developer-retry — закрывает RCA-класс ORCH-110 на staging-ребре. Задача **держится** на `deploy-staging`; reconciler `advance_if_gate_passed` на red-гейте возвращает `None` (без отката, R-2 верифицирован) → оператор re-drive после починки окружения.
-  - **Prod-like preflight (D5):** `staging_runner.preflight()` (bounded, never-raise, self-hosting-скоуп — `applies()` первым) пробит host-side канал на **старте сервиса** в `main.lifespan` (best-effort, после `requeue_running_jobs`/`recover_on_startup`, **никогда не блокирует старт**): ssh-зонд `command -v docker && docker inspect -f '{{.State.Running}}' orchestrator-staging` распознаёт «нет docker на хосте» / «staging-контейнер не поднят» / «ssh недоступен» / «нет ssh-target» **до** того, как реальная задача дойдёт до ложного исхода. Чисто наблюдательный — не гейтит конвейер; лог + Telegram-алерт + поле в `snapshot()`.
-  - **Условность / обратимость (D6):** новый флаг `staging_runner_exec_host_side: bool = True` (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`, дефолт = боевое) — `True` → host-side ssh; `False` → прежний in-container `docker exec` (валиден лишь там, где docker CLI запечён в образ). Переиспользуются `staging_runner_enabled`/`_repos`/`_timeout_s`/`_infra_max_retries`/`_retry_delay_s` + `deploy_ssh_user`/`deploy_ssh_host`. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (in-container 1:1) или `ORCH_STAGING_RUNNER_ENABLED=false` (LLM-deployer 1:1). Наблюдаемость (D8): счётчик `permanent_env` (infra-HOLD; отличён от `failed`=код-фейл и `deferred`=транзиент) + `exec_host_side` + `preflight` в блоке `staging_runner` `GET /queue`; один структурный лог-вердикт на прогон (`outcome ∈ {code-pass,code-fail,transient-infra,permanent-env}`).
-  - **Документация границы исполнения (D9):** `docs/operations/INFRA.md` (новый под-раздел «Граница исполнения docker-операций — host-side») + `docs/architecture/README.md` (host-side стратегия + трёхсторонняя классификация) — зафиксировано, что **все** docker-операции self-hosting (прод-деплой ORCH-036, image-freshness ORCH-058, staging-runner ORCH-123) исполняются host-side через ssh, docker CLI в контейнере нет, `docker.sock` сознательно не используется изнутри. Покрытие — `tests/test_orch123_staging_runner_exec.py` (TC-01 — обязательный регресс ORCH-116: КРАСНЫЙ до фикса / ЗЕЛЁНЫЙ после; TC-02…TC-14 + регресс R-2 «held не становится rollback») + зелёный анти-дрейф `tests/test_orch115_staging_runner.py` (TC-14: инварианты ORCH-115 целы; 3 теста обновлены под суперсед D4/D8/D1).
-- **Детерминированный staging-раннер вместо LLM-деплойера на `deploy-staging`** (ORCH-115, `feat`): первый реализованный срез determinization-roadmap (ORCH-118 A6, `replace-deterministic-now`) — на стадии `deploy-staging` для self-hosting `orchestrator` **LLM-агент `deployer` заменён детерминированным кодом** (`src/staging_runner.py`). Работа агента на этой стадии была чисто механической (запуск staging-сюиты + маппинг exit-кода `staging_check.py` → `staging_status:`); каждый прогон жёг токены/время opus-агента (~40–120k / 3–15 мин) и встраивал недетерминизм LLM в точку ветвления гейта. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `15-staging-log.md`, гейт `check_staging_status`/`_parse_staging_status`, `STAGE_TRANSITIONS`, machine-verdict `staging_status:`, схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting. ADR: `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`, сквозной `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`.
-  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="deployer" and staging_runner.should_intercept(job)` → `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`, прецедент `deploy-finalizer`/`post-deploy-monitor` `launcher.py:389/394`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`-строки, нет токенов). Дискриминатор «staging vs prod» — **стадия задачи** `deploy-staging` (роль `deployer` общая для `deploy-staging`/`deploy`), не имя роли; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути). Для не-self репо `applies==False` → прод-`deployer` никогда не перехватывается.
-  - **Leaf `src/staging_runner.py` (новый, чистый never-raise):** по образцу `self_deploy`/`proc_group`/`staging_verdict` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/`qg.checks`/`notifications` — лениво). Исполняет ту же сюиту (`docker exec orchestrator-staging python3 <repos_dir>/<self-repo>/scripts/staging_check.py --base-url http://localhost:<staging_port> --mode stub`, арги из config — ORCH-101, без host-хардкодов) через `proc_group.run_in_process_group` (tree-kill, таймаут `staging_runner_timeout_s=600`, малформ/непозитив → дефолт + WARNING); маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` (`0→SUCCESS`/иначе/None→`FAILED`, fail-closed; ORCH-061 infra-tolerance остаётся внутри `staging_check.py`, раннер не пересуживает — BR-4); пишет `15-staging-log.md` (тот же machine-key `staging_status:` UPPERCASE + 52c-схема, `author_agent: staging-runner`/`model_used: n/a`) + best-effort commit/push в **фичеветку** (не в `main` — гейт читает worktree первым, усиливает AC-8/BR-7); вызывает **существующий** `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage`, раннер не трогает — граница O1).
-  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAILED → тот же откат `deploy-staging → development` + developer-retry, что у FAILED-вердикта LLM, `stage_engine.py:932`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue `deployer`-джоба с задержкой + restart-safe маркер `staging-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `staging_runner_infra_max_retries=2` → fail-closed `FAILED` + advance + инфра-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь и **не** жжёт developer-retry на транзиентной инфре.
-  - **Self-hosting safety (BR-7/AC-8):** в командной строке раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push в `main` / правок `.env` — раннер только читает/исполняет staging-сюиту (8501) и пишет лог. Наблюдаемость (D10) — in-process счётчики (`runs`/`success`/`failed`/`tool_error`/`deferred`) + read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `staging_runner_enabled` (env `ORCH_STAGING_RUNNER_ENABLED`), `staging_runner_repos` (CSV; пусто → self-hosting only), `staging_runner_timeout_s`, `staging_runner_infra_max_retries`, `staging_runner_infra_retry_delay_s`. Откат = `ORCH_STAGING_RUNNER_ENABLED=false` → на `deploy-staging` снова LLM-`deployer` через `_spawn` **байт-в-байт**.
-  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A6 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет deployer как `avoidable=yes`/`axis=C` — LLM-ветвь жива как fallback), `llm-determinization-roadmap.md` (rank 1 deployer — ✅ реализован; машинный блок/инвариант «ровно один `first_slice = yes`» целы), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/deployer.md` (LLM-ветвь `deploy-staging` — fallback), витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`. Покрытие — `tests/test_orch115_staging_runner.py` (TC-01…TC-13) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-14).
-- **Карта LLM-консультаций + control-path-ось «avoidable» + roadmap + нормативная политика** (ORCH-118, `docs`+`test`, inventory-first, docs+tests only): зонтичный follow-up RCA-трека ORCH-114/117 — у оркестратора не было ни нормативного критерия «где LLM нужен, а где это avoidable control path», ни карты мест вызова LLM, прибитой к коду. Выпущена **доказательная карта** каждого места, где control-path потребляет (или способен потребить) суждение LLM, с control-path-разметкой и классификацией; **упорядоченный roadmap** детерминированных замен; **нормативная политика** использования LLM; набор **структурных анти-дрейф тестов**. Это **docs + tests only**: `src/**`-рантайм не меняется → `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен **не** реализуются (FR-7); конкретные follow-up Plane-ID **не** фиксируются (R3/NFR-6 — кандидаты по роли). kill-switch не нужен (нет рантайм-поведения), как ORCH-077/079/101/102/103/011. ADR: `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`, сквозной `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`.
-  - **Единица инвентаря — LLM-консультация** (control-path потребляет суждение LLM), а **не** «спавн процесса / существование Claude CLI» (R4, capability ≠ consultation). Карта разводит **три ортогональных факта**: (1) consultation ≠ transport/slot (единственный транспорт LLM-консультации в `src/**` — `launcher._spawn`, `launcher.py:472`/CLI-сборка `610-614`; иного транспорта нет; job-роли `deploy-finalizer`/`post-deploy-monitor` занимают слот, но перехватываются в `launch_job` **до** `_spawn`, `launcher.py:389/394` — консультации нет); (2) **control-path (C) ≠ artifact-producer (P)** по коду-потребителю в `src/qg/checks.py` (C: гейт ветвится на LLM-вердикте; P: детерминированный гейт судит артефакт независимо — файлы/CI); (3) деривируемость вердикта из tool-сигналов.
-  - **Нормативное определение** «avoidable LLM control path» = двухбитный предикат (C-консультация **И** вердикт деривируем из exit-кодов `pytest`/smoke/`staging_check.py`/деплоя). Поимённый целевой набор (доказательно, прибит тестами): **avoidable = `{tester, deployer}`**; control-path-но-keep = `{reviewer}` (вердикт «приемлемость кода/решения» НЕ деривируем); не-control-path (P, keep) = `{analyst, architect, developer}`; уже детерминированы (эталон) = `{deploy-finalizer, post-deploy-monitor}`.
-  - **Документы (durable, `docs/architecture/`):** `llm-call-sites.md` (карта + машинно-читаемый блок инвентаря + control-path-разметка + классификация, снимок), `llm-determinization-roadmap.md` (порядок замен; рекомендованный первый срез — **deployer staging-status**, чистый маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C ORCH-036), `llm-usage-policy.md` (нормативный принцип + критерии keep/replace через ось + определение «avoidable»). Витрина `docs/overview/tech-quality-security.md` и `docs/architecture/README.md` ссылаются на карту и политику.
-  - **Анти-дрейф тесты (offline, без сети/LLM/subprocess-к-модели):** `tests/test_llm_call_site_inventory.py` (TC-01 единственный транспорт = `_spawn`; TC-12 отсутствие иного LLM-транспорта; TC-02 детерминированные модули без консультации; TC-03 промпты↔файлы; TC-04 тотальность+согласованность класса с осью; TC-05 keep-LLM именует суждение; TC-06 capability≠consultation; TC-09 снимок рантайм-контрактов; **TC-13** control-path-разметка сверена с потребителем в `src/qg/checks.py`; **TC-14** avoidable-набор = `{tester, deployer}`) и `tests/test_llm_determinization_docs.py` (TC-07 полнота roadmap+первый срез; TC-08 политика нормативна+определяет термин; TC-11 анти-фабрикация follow-up ID). Дискриминатор всех проверок — **«консультирует LLM», а не «спавнит subprocess»**. Норматив сопровождения: менял место вызова LLM или потребителя вердикта в `src/qg/checks.py` → обнови карту/разметку и политику в том же PR.
-- **Sandbox-only fail-closed изоляция записи в Plane из тест-процесса** (ORCH-117, `fix`, bug→escalate full-cycle): закрыт корневой класс инцидента **ORCH-114** — тест/worktree-процесс выполнил РЕАЛЬНУЮ запись (`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого** Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** — подмена env/токена постфактум бесполезна, NFR-4), и **ничто** не принуждало их писать только в sandbox. Симметрия прецеденту `tests/conftest.py::_no_telegram` (autouse-глушилка Telegram «pytest на проде слал реальные сообщения») — для Plane-**записи** такой защиты не было. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента Plane, **не** Quality Gate и **не** стадия). Новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op, work_item) -> (ALLOW|BLOCK, reason)`, по образцу `deploy_status_guard`/`serial_gate`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и **до** любого сетевого шага (ни GET, ни PATCH/POST). Гард активен **только в тест-процессе** (детект `"pytest" in sys.modules` / `PYTEST_CURRENT_TEST`); боевой и staging рантаймы (`uvicorn src.main:app`, без pytest в процессе) — строгий **no-op** (NFR-2/NFR-3). В тест-процессе запись разрешена **только** при одновременном (а) opt-in `plane_test_write_enabled=True` **и** (б) целевом проекте ∈ sandbox-allowlist `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-…`); иначе — default-deny; нерезолвимый проект → блок (fail-closed, NFR-1); боевой проект запрещён **даже при opt-in** (allowlist sandbox-only). Второй независимый sandbox-bound слой — autouse-floor `tests/conftest.py::_plane_sandbox_only` (opt-in OFF для всего сьюта, по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит opt-in в своей фикстуре поверх floor. **Умышленно БЕЗ kill-switch прод-блока** (NFR-6/FR-7/anti-drift): выключателя, переоткрывающего прод-запись из pytest, нет — единственный реверс — sandbox-bound opt-in. Аудит: блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason` — делает инцидент класса ORCH-114 очевидным), разрешённая sandbox-запись → INFO. Новые ключи `ORCH_PLANE_TEST_WRITE_ENABLED` (дефолт `false`) / `ORCH_PLANE_TEST_SANDBOX_PROJECTS` (дефолт = SANDBOX id) с безопасными дефолтами; `scripts/staging_check.py` Block C (E2E в SANDBOX) — отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие — `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до врезки, зелёный после; TC-02…TC-14). ADR: `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`, сквозной `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`.
 - **Ownership-lease для side-effectful переходов стадий + умное восстановление при старте** (ORCH-114, `fix`, bug→escalate full-cycle): закрыт **корневой класс** инцидент-цепочки ORCH-110/111/112/113 — у side-effectful переходов стадий не было единого владения. `advance_stage` ре-ентерабельна и пишет стадию «голым» `UPDATE … WHERE id=?` (без compare-and-swap), а ≥5 акторов (монитор / Plane-webhook / reconciler F-1 / job-reaper / deploy-finalizer) входят в один переход независимо → конкурентный или после-рестартовый повторный вход **дважды** применял необратимые эффекты (merge_pr / coverage-ratchet / image-rebuild / инициация прод-деплоя) и давал **противоречие rollback↔done** (инцидент ORCH-111, job 1914 / PR #130). Два комплементарных слоя, оба аддитивные, под единым kill-switch, never-raise: **(1) durable transition-lease** (новая таблица `transition_lease`) — владение на ВХОДЕ в side-effectful регион (второй актор, увидев живого владельца, не стартует тяжёлые под-гейты вовсе — предотвращение, не починка постфактум); **(2) expected-stage CAS** (`update_task_stage_cas`) — на ЗАПИСИ стадии (проигравший гонку — аборт без побочных эффектов), что закрывает и **6 путей записи стадии в обход `advance_stage`** (gitea×5 + plane rollback). Liveness владельца = `owner_pid` + `owner_boot_id` (НЕ heartbeat: блокирующий 900s merge re-test не может бить heartbeat — довод самого ORCH-113), что делает рестарт-recovery бесплатным (новый процесс → новый boot-id → все прежние lease мгновенно устаревшие → реклеймятся). Lease без собственного TTL: его потолок возраста = Tier-3 backstop `reaper_max_running_s` (5400) → сквозной бюджет ORCH-065/109/110/113 не тронут. `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / **схемы существующих таблиц** — байт-в-байт (одна аддитивная таблица, без epoch-колонки на `tasks`). Скоуп self-hosting (`transition_lease_repos=""` → только `orchestrator`; enduro не затронут); kill-switch `ORCH_TRANSITION_LEASE_ENABLED=false` → CAS вырождается в прежний безусловный `update_task_stage`, lease инертен → поведение байт-в-байт до ORCH-114. ADR: `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`, сквозной `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`.
   - **Leaf `src/transition_lease.py` (новый, чистый never-raise):** по образцу `serial_gate`/`coverage_gate`/`finalizer_liveness` (импортирует только `db`+`config`, лениво `merge_gate.pid_alive`/`qg.checks`/`notifications`; НЕ импортирует `stage_engine`/`launcher`) — `applies(repo)` / `acquire(task_id, owner, run_id, stage)` (атомарный rowcount-guard `INSERT … ON CONFLICT DO NOTHING` после очистки stale-строки) / `is_held_by_live_owner(task_id)` (fail-closed → defer на сомнении) / `release(task_id, force=False)` (holder-aware по boot) / `reclaim_if_stale` / `recover_on_startup` / `commit_stage_cas(task_id, expected, new, repo)` (flag-off → unconditional `update_task_stage`; flag-on → CAS) / `snapshot()`.
   - **Интеграция:** `advance_stage` захватывает lease на входе в side-effectful ребро (`deploy-staging`/`deploy`), пишет стадию через CAS, освобождает lease в `try/finally` (на любом исходе, включая исключение/откат); **rollback-записи side-effectful под-гейтов** (`_handle_merge_gate_rollback`/`_handle_security_gate`/`_handle_coverage_gate`/`_handle_image_freshness`) пишут `development` через тот же CAS (общий хелпер `_rollback_stage_cas`, ADR-001 D4: защита rollback↔done — под держимым lease это единственный владелец, проигранный CAS → аборт без side-effects, не слепой перетир `done`); job-reaper `_finalizer_owns` обобщён с процесс-локального ORCH-113 (Tier-2/`deploy-staging`) на **durable cross-path** lease (defer при живом владельце; Tier-3 backstop игнорирует маркер → bounded reclaim; реап force-освобождает lease); reconciler F-1 и Plane-webhook (`_try_advance_stage`) делают **defer** при активном lease; `main.lifespan` зовёт `recover_on_startup()` после `requeue_running_jobs`. Наблюдаемость — read-only блок `transition_lease` в `GET /queue` + Telegram-алерт на форсированный/устаревший реклейм + опциональный `POST /transition-lease/release?work_item=<id>`. Покрытие — `tests/test_orch114_transition_ownership.py` (TC-01 обязательный регресс класса ORCH-111: красный до фикса, зелёный после; TC-02…TC-14 + регресс CAS на in-region rollback). Флаги (`config.py`, дефолт = боевое): `transition_lease_enabled` (env `ORCH_TRANSITION_LEASE_ENABLED`), `transition_lease_repos` (env `ORCH_TRANSITION_LEASE_REPOS`).

CLAUDE.md

@@ -366,190 +366,6 @@ lease **не консультирует** (fail-open, очередь репо н
   `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`, сквозной
   `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`.
 
-## Sandbox-only fail-closed изоляция записи в Plane (ORCH-117)
-Закрыт корневой класс инцидента **ORCH-114**: тест/worktree-процесс выполнил РЕАЛЬНУЮ запись
-(`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого**
-Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен
-(`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** `plane_sync` — подмена env/токена
-постфактум бесполезна, NFR-4) и **ничто** не принуждало их писать только в sandbox. Прямой
-прецедент — `tests/conftest.py::_no_telegram` (autouse-глушилка «pytest на проде слал реальные
-Telegram-сообщения»); симметричной защиты для Plane-**записи** не было. **Инвариант:** запись в
-боевой Plane-проект из любого pytest/worktree-процесса **физически невозможна** независимо от
-токена. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и
-имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента
-Plane, **не** Quality Gate и **не** стадия).
-- **Чокпоинт (D1):** новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op,
-  work_item) -> (ALLOW|BLOCK, reason)`, never-raise, по образцу `deploy_status_guard`/`serial_gate`/
-  `cancel`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state` / `add_comment` /
-  `_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и
-  **до** любого сетевого шага (ни GET, ни PATCH/POST). Все `set_issue_*`/`notify_*` сводятся к этим
-  трём примитивам → один гард ловит любой путь, включая будущие.
-- **Детект тест-процесса (D2):** `"pytest" in sys.modules` ∨ `PYTEST_CURRENT_TEST` (на момент
-  вызова). Боевой и staging рантаймы — `uvicorn src.main:app`, pytest в процесс **не** импортируют →
-  гард там строгий **no-op** (NFR-2/NFR-3); worktree `python -m pytest` (инцидентный путь)
-  гарантированно имеет pytest в `sys.modules` → ловится.
-- **Решение (D3):** default-deny. Запись из тест-процесса разрешена ⇔ одновременно (а) opt-in
-  `plane_test_write_enabled=True` **и** (б) целевой проект ∈ sandbox-allowlist
-  `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-4f9d-4190-b79f-fa06276bb27e`).
-  Нерезолвимый/пустой проект → блок (fail-closed, NFR-1). Боевой проект запрещён **даже при opt-in**
-  (allowlist sandbox-only). Внутренняя ошибка `decide` в тест-контексте → fail-CLOSED (`guard-error`).
-- **Второй слой (D5):** независимый autouse-floor `tests/conftest.py::_plane_sandbox_only` форсит
-  opt-in OFF для **всего** сьюта (по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит
-  opt-in в своей фикстуре поверх floor. Два sandbox-bound слоя → нет одиночной точки, чьё выключение
-  переоткрывает прод.
-- **Умышленно БЕЗ kill-switch прод-блока (D4, NFR-6/FR-7, anti-drift):** выключателя,
-  переоткрывающего прод-запись из pytest, **нет** — единственный реверс — sandbox-bound opt-in. Не
-  добавлять «общий kill-switch гарда» (реинтродуцирует дефект ORCH-114; reviewer ловит как ≥P1).
-- **Аудит (D7):** блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason`:
-  `prod-project-in-test`/`opt-in-disabled`/`ambiguous-target`/`guard-error`); разрешённая
-  sandbox-запись → INFO. **Флаги** (`config.py`, дефолты безопасные): `plane_test_write_enabled`
-  (env `ORCH_PLANE_TEST_WRITE_ENABLED`, дефолт `False`), `plane_test_sandbox_projects` (env
-  `ORCH_PLANE_TEST_SANDBOX_PROJECTS`, CSV). `scripts/staging_check.py` Block C (E2E в SANDBOX) —
-  отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие —
-  `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до
-  врезки, зелёный после; TC-02…TC-14). Детали —
-  `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`, сквозной
-  `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`.
-
-## Детерминированный staging-раннер вместо LLM-деплойера (ORCH-115)
-Первый реализованный срез determinization-roadmap (ORCH-118 A6, `replace-deterministic-now`): на
-стадии `deploy-staging` для self-hosting `orchestrator` **LLM-агент `deployer` заменён
-детерминированным кодом** (`src/staging_runner.py`). Работа агента на этой стадии была чисто
-механической (запуск staging-сюиты + маппинг exit-кода) — теперь её делает leaf, перехватываемый в
-`launch_job` **до `_spawn`** (прецедент `deploy-finalizer`/`post-deploy-monitor`,
-`launcher.py:389/394`). **Инвариант (NFR-1):** замена *продюсера* артефакта, **не** гейта —
-контракт `15-staging-log.md`, гейт/`_parse_staging_status`/имя `check_staging_status`,
-`STAGE_TRANSITIONS`, machine-verdict `staging_status:`, схема БД — **байт-в-байт не тронуты**.
-Аддитивно, под kill-switch, never-raise, fail-closed.
-- **Перехват (D1):** `launch_job` — `if job.agent=="deployer" and staging_runner.should_intercept(job)`
-  → `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`): синхронно ведёт `jobs`-строку
-  через `mark_job`, возвращает `None` (нет `agent_runs`). Дискриминатор «staging vs prod» —
-  **стадия задачи** `deploy-staging` (роль `deployer` общая для `deploy-staging`/`deploy`), не имя
-  роли; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути).
-- **Раннер (D2-D7):** leaf по образцу `self_deploy`/`proc_group`/`staging_verdict` (на импорте только
-  `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/`qg.checks`/`notifications` — лениво).
-  Исполняет ту же сюиту (`docker exec orchestrator-staging python3 .../staging_check.py --base-url
-  http://localhost:8501 --mode stub`, арги из config — ORCH-101) через `proc_group` (tree-kill,
-  таймаут `staging_runner_timeout_s=600`); маппит exit-код **единым** контрактом
-  `self_deploy.map_exit_code_to_status` (`0→SUCCESS`/иначе/None→`FAILED`; ORCH-061 infra-tolerance
-  остаётся внутри `staging_check.py`, раннер не пересуживает); пишет `15-staging-log.md`
-  (`author_agent: staging-runner`/`model_used: n/a`, 52c-схема) + best-effort push в **фичеветку**
-  (не в `main` — гейт читает worktree первым, усиливает AC-8); вызывает **существующий**
-  `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — без новых
-  рёбер/исходов (lease ORCH-114 берётся внутри `advance_stage`, раннер не трогает).
-- **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→
-  advance (FAILED → тот же откат `deploy-staging → development` + developer-retry, что у LLM); сюита
-  **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл →
-  bounded **DEFER** (re-queue `deployer`-джоба + restart-safe маркер `staging-runner infra-retry` в
-  `task_content`, без правки схемы БД), на исчерпании `staging_runner_infra_max_retries` → fail-closed
-  `FAILED` + advance + alert. Никогда тихий advance/ложный green; не клинит очередь; не жжёт
-  developer-retry на транзиентной инфре.
-- **Флаги** (`config.py`, дефолт = боевое): `staging_runner_enabled` (kill-switch, env
-  `ORCH_STAGING_RUNNER_ENABLED`), `staging_runner_repos` (CSV; **пусто → self-hosting only**),
-  `staging_runner_timeout_s=600`, `staging_runner_infra_max_retries=2`,
-  `staging_runner_infra_retry_delay_s=30`. Откат = `ORCH_STAGING_RUNNER_ENABLED=false` → на
-  `deploy-staging` снова LLM-`deployer` через `_spawn` **байт-в-байт**. Наблюдаемость — in-process
-  счётчики + read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт на прогон
-  (различает код-фейл и tool-error). Норматив сопровождения ORCH-118: обновлены
-  `llm-call-sites.md`/`llm-determinization-roadmap.md`/`llm-usage-policy.md` (A6 — реализован, машинные
-  блоки/инвариант «единственный транспорт S0» целы) + `deployer.md` (LLM-ветвь — fallback). Покрытие —
-  `tests/test_orch115_staging_runner.py` (TC-01…TC-13) + зелёные LLM-анти-дрейф тесты (TC-14). Детали —
-  `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`, сквозной
-  `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`.
-- **ORCH-123 (host-side исполнение + классификация environment-дефекта, bug→escalate full-cycle,
-  adr-0049):** фикс инцидента **ORCH-116** — раннер ORCH-115 вызывал `docker exec` **изнутри**
-  прод-контейнера, где **нет docker CLI** (`Dockerfile:11` несёт только `openssh-client git curl`;
-  `docker.sock` смонтирован, клиента нет) → `FileNotFoundError` → постоянный environment-дефект
-  ложно маршрутизировался как код-фейл-откат `deploy-staging → development` (с расходом
-  developer-retry); любая self-hosting задача на `deploy-staging` была обречена. Аддитивно, под
-  флагами, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена
-  `check_staging_status`/`_parse_staging_status`/machine-verdict-ключи/схема БД — **байт-в-байт не
-  тронуты** (замена *стратегии исполнения продюсера*, **не** гейта; зеркало ORCH-115 NFR-1).
-  **(D1)** `build_staging_command` обёртывает ту же `docker exec orchestrator-staging … staging_check.py
-  … --mode stub` в `ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> '<…>'`
-  (зеркало `self_deploy`/`image_freshness`; канал доверенный `ORCH_DEPLOY_SSH_HOST=127.0.0.1`,
-  ssh-ключ `:ro`, `openssh-client` в образе — новых секретов/привилегий нет; сюита по-прежнему бежит
-  **внутри** `orchestrator-staging` 8501, меняется лишь инициатор `docker exec`). **(D2 security)**
-  docker CLI/SDK в контейнер **не** добавляется, `docker.sock` **не** используется изнутри (это
-  root-эквивалентное расширение поверхности атаки, доступное и LLM-агентам). **(D3)** двухуровневый
-  исход ORCH-115 заменён **трёхсторонней** чистой `classify_staging_outcome` (зеркало
-  `merge_gate.classify_retest_failure`): `suite-ran` (распознанный exit-код ≠255 **без** env-маркера в
-  stderr → доверяем коду `0→SUCCESS`/`≠0→FAILED`; анти-over-tolerance BR-3), `permanent-env`
-  (spawn-error `rc=None`/нет ssh-target/`rc∈{126,127}`/env-маркер `No such container`/`Cannot connect
-  to the Docker daemon` → ретрай бессмыслен), `transient-infra` (timeout/ssh `rc=255`/неизвестно →
-  ретрай осмыслен); дизамбигуация `exit=1`-коллизии — скан stderr на env-маркеры, не голый код;
-  fail-safe → `transient-infra`. **(D4 инвариант «инфра ≠ код-фейл»)** `permanent-env` → немедленный
-  **infra-HOLD** (DEFER пропускается, `15-staging-log.md` НЕ пишется, advance НЕ зовётся, developer-retry
-  НЕ жжётся, alert «НЕ дефект кода»); `transient-infra` → bounded DEFER, на исчерпании — тоже
-  infra-HOLD+alert (**супершид ORCH-115 D5** fail-closed-FAILED-отката). «Сюита **не** исполнилась»
-  (env ИЛИ инфра) **никогда** не оканчивается код-фейл-откатом — закрывает RCA-класс ORCH-110 на
-  staging-ребре; задача держится на `deploy-staging` (reconciler `advance_if_gate_passed` на red-гейте
-  → `None`, без отката, R-2). **(D5)** `preflight()` пробит host-side канал на старте `main.lifespan`
-  (best-effort, never-blocks). **(D6)** новый флаг `staging_runner_exec_host_side=True`
-  (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`); откат — `=false` (in-container 1:1) или
-  `ORCH_STAGING_RUNNER_ENABLED=false` (LLM-deployer 1:1). **(D8)** счётчик `permanent_env` + `exec_host_side`
-  + `preflight` в блоке `staging_runner` `GET /queue`. Покрытие — `tests/test_orch123_staging_runner_exec.py`
-  (TC-01 обязательный регресс ORCH-116 red→green; TC-02…TC-14 + R-2) + зелёный анти-дрейф ORCH-115.
-  Детали — `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`,
-  сквозной `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`.
-
-## Детерминированный test-раннер вместо LLM-тестера (ORCH-116)
-Второй реализованный срез determinization-roadmap (ORCH-118 A5, `needs-hybrid-fallback`): на стадии
-`testing` для self-hosting `orchestrator` **LLM-агент `tester` заменён детерминированным кодом**
-(`src/test_runner.py`). PASS/FAIL-ядро было деривируемо (регресс `pytest` + read-only smoke) — теперь
-его делает leaf, перехватываемый в `launch_job` **до `_spawn`** (прецедент `deploy-finalizer`/
-`post-deploy-monitor`/`staging-runner`, `launcher.py:397/402/405`). **Инвариант (NFR-1):** замена
-*продюсера* артефакта, **не** гейта — контракт `13-test-report.md`, гейт/`_parse_tests_verdict`/имя
-`check_tests_passed`, `STAGE_TRANSITIONS`, machine-verdict `result:` (+ legacy `verdict:`/`status:`),
-схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, гибрид
-(LLM строго off-control-path).
-- **Перехват (D1):** `launch_job` — `if job.agent=="tester" and test_runner.should_intercept(job)`
-  → `_run_test_runner_job` (зеркало `_run_staging_runner_job`): синхронно ведёт `jobs`-строку через
-  `mark_job`, возвращает `None` (нет `agent_runs`). Дискриминатор — роль `tester` **И** стадия задачи
-  `testing` (defense-in-depth: `tester` — единственный агент входа в `testing`, коллизии стадий нет, в
-  отличие от общей роли `deployer`/ORCH-115) **И** `applies(repo)`; `should_intercept` never-raise →
-  `False` → штатный `_spawn` (fail-safe к LLM-пути).
-- **Раннер (D2-D7):** leaf по образцу `staging_runner`/`self_deploy`/`proc_group` (на импорте только
-  `config`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications`
-  — лениво). `applies` = kill-switch `test_runner_enabled` + скоуп `test_runner_repos` (пусто →
-  self-hosting only) **И** резолв тест-контракта `_has_test_contract` (BR-9: репо без контракта →
-  LLM-tester, enduro-trails 1:1 даже если руками в CSV). Исполняет `python -m pytest
-  <test_runner_target>` **в worktree ветки** (анти checkout-гонка) через `proc_group`
-  (tree-kill, таймаут `test_runner_timeout_s=900`) + опц. read-only smoke (`/health`/`/status`/`/queue`
-  + блок `serial_gate`, stdlib `urllib`; транзиент → ограниченный ретрай, не-200/нет блока → немедленный
-  FAIL; `test_runner_smoke_enabled`); маппит exit-код **единым** `self_deploy.map_exit_code_to_status`
-  в токенах `result:` (`0→PASS`/иначе/None→`FAIL`, fail-closed; smoke-провал AND-ится в `FAIL`); пишет
-  `13-test-report.md` (`author_agent: test-runner`/`model_used: n/a`, 52c-схема) + best-effort push в
-  фичеветку; вызывает **существующий** `advance_stage(current_stage="testing", finished_agent="tester")`
-  — без новых рёбер/исходов (lease ORCH-114 берётся внутри `advance_stage`).
-- **Анти-коллизия 52c-`status:` ↔ парсер (D6.1, специфично для tester):** `_parse_tests_verdict` читает
-  вердикт из **трёх** равноранговых полей (`verdict:`/`status:`/`result:`) с negative-token-priority →
-  52c-обязательное `status:` раннера **ВСЕГДА выровнено** по вердикту (`PASS → status: success`, `FAIL
-  → status: failed`), иначе негативный токен в `status:` при `result: PASS` дал бы ложный FAIL. Прибито
-  unit-тестом через неизменённый парсер.
-- **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→
-  advance (FAIL → тот же откат `testing → development` + developer-retry, что у LLM); сюита **не
-  исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded
-  **DEFER** (re-queue **`tester`**-джоба + restart-safe маркер `test-runner infra-retry` в
-  `task_content`, без правки схемы БД), на исчерпании `test_runner_infra_max_retries` → fail-closed
-  `FAIL` + advance + alert. Никогда тихий advance/ложный green; не клинит очередь; не жжёт
-  developer-retry на транзиентной инфре.
-- **Флаги** (`config.py`, дефолт = боевое): `test_runner_enabled` (kill-switch, env
-  `ORCH_TEST_RUNNER_ENABLED`), `test_runner_repos` (CSV; **пусто → self-hosting only**),
-  `test_runner_target=tests/`, `test_runner_timeout_s=900`, `test_runner_smoke_enabled`,
-  `test_runner_infra_max_retries=2`, `test_runner_infra_retry_delay_s=30`. Откат =
-  `ORCH_TEST_RUNNER_ENABLED=false` → на `testing` снова LLM-`tester` через `_spawn` **байт-в-байт**.
-  Наблюдаемость — in-process счётчики + read-only блок `test_runner` в `GET /queue` + один структурный
-  лог-вердикт на прогон (различает код-фейл и tool-error). **Гибрид (BR-8/NFR-7):** LLM строго
-  off-control-path — детерминированный раннер единственный продюсер `result:`; будущий триаж падений не
-  выносит/не переопределяет вердикт и не добавляет ребро в `STAGE_TRANSITIONS` (Phase 1 не реализован).
-  Норматив сопровождения ORCH-118: обновлены `llm-call-sites.md`/`llm-determinization-roadmap.md`/
-  `llm-usage-policy.md` (A5/rank 2 — реализован, машинные блоки/инвариант «ровно один `first_slice`»
-  целы) + `tester.md` (LLM-ветвь — fallback). Покрытие — `tests/test_orch116_test_runner.py`
-  (TC-01…TC-14) + зелёные LLM-анти-дрейф тесты (TC-15). Детали —
-  `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`, сквозной
-  `docs/architecture/adr/adr-0050-deterministic-test-runner.md`.
-
 ## Машинный журнал уроков (ORCH-098)
 Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
 **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих

README.md

@@ -149,12 +149,6 @@ uvicorn src.main:app --reload --port 8500
 | `ORCH_BUG_FAST_TRACK_ENABLED` | Kill-switch багфикс-трека (ORCH-019): задача с меткой Plane `Bug` пропускает стадию `architecture`; `false` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия) | `true` |
 | `ORCH_BUG_FAST_TRACK_LABEL` | Имя метки Plane, активирующей багфикс-трек (ORCH-019) | `Bug` |
 | `ORCH_BUG_FAST_TRACK_REPOS` | CSV область репо для багфикс-трека; **пусто → self-hosting only** (`orchestrator`) — enduro подключается явным CSV (ORCH-019) | `""` |
-| `ORCH_ESTIMATOR_ENABLED` | Kill-switch оценки задачи (ORCH-020): Plane-статус «Оценка» прогнозирует стоимость/время/токены/story-points по истории; `false` → статус не обрабатывается, ничего не пишется (нулевая регрессия) | `true` |
-| `ORCH_ESTIMATOR_REPOS` | CSV область репо для оценки; **пусто → self-hosting only** (`orchestrator`) — enduro не затронут (ORCH-020) | `""` |
-| `ORCH_ESTIMATOR_MIN_SAMPLES` | Порог истории, ниже которого подмешивается bootstrap-дефолт прогноза (ORCH-020) | `3` |
-| `ORCH_ESTIMATOR_BOOTSTRAP_TOKENS` / `_COST_USD` / `_SECONDS` | Bootstrap-прогноз при пустой истории (токены/стоимость/время; ORCH-020) | `2000000`/`3.0`/`1800` |
-| `ORCH_ESTIMATOR_SP_COST_THRESHOLDS` | 4 возрастающих кат-оффа стоимости (t1,t2,t3,t5) для бакета story-points (`<=t1→1`…`<=t5→5`, иначе `8`; ORCH-020) | `0.50,2.00,5.00,12.00` |
-| `ORCH_ESTIMATOR_WALL_CAP_S` / `_MAX_INFLIGHT` | Отсечка аномального wall-времени в истории / опц. семафор сглаживания массовой нагрузки (ORCH-020) | `86400`/`64` |
 | `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME акторских процессов + таргет маунтов `.claude`/`.ssh` + `ARG APP_HOME` (группа ORCH-040) | `/home/slin` |
 | `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot@mva154.local` при дефолтах) | `claude-bot` / `mva154.local` |
 | `ORCH_STAGING_PORT` | ORCH-101: порт staging (читают `image_freshness` и compose); guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) | `8501` |

docs/_standards/PIPELINE_DOCS.md

@@ -47,7 +47,6 @@ check_tests_passed → check_staging_status → check_deploy_status`.
 |----------|----------------|-----------|------------------|--------------------------|-------------------------|
 | `00-business-request.md` | система (Plane webhook `_create_initial_docs`) / заказчик | required | `created` (инициализация) | не гейтится (вход) | — |
 | `01-brd.md` | analyst | required | `analysis` | exit-гейт `analysis→architecture` = `check_analysis_approved` (Approved + полнота файлов); helper `check_analysis_complete` (наличие `01/02/03/04`) | — |
-| `01-questions.md` | analyst | when-applicable | `analysis` | **сигнальный** (гейтом НЕ парсится); механизм — ветка Needs Input в `_handle_analysis_approved_flow` (ORCH-120, adr-0053): активные блокирующие вопросы → `set_issue_needs_input` (приоритет над «файлы готовы») | — (не machine-verdict) |
 | `02-trz.md` | analyst | required | `analysis` | то же | — |
 | `03-acceptance-criteria.md` | analyst | required | `analysis` | то же | — |
 | `04-test-plan.yaml` | analyst | required | `analysis` | то же | — |
@@ -73,10 +72,6 @@ check_tests_passed → check_staging_status → check_deploy_status`.
 - **Категория `when-applicable`** = документ пишется при наличии соответствующего предмета
   (инфра / данные / security / post-deploy). Его отсутствие — не нарушение приёмки.
 - **`05-…` / `09-…` / `11-…`** — зарезервированные/legacy номера, в текущем каноне не используются.
-- **Префикс `01-` (DQ-4 ORCH-120)** — общий для артефактов стадии `analysis` владельца `analyst`:
-  `01-brd.md` — обязательный deliverable (гейтится `check_analysis_complete`), `01-questions.md` —
-  **сигнальный** when-applicable артефакт того же владельца/стадии. Коллизии нет: файлы разноимённые,
-  `check_analysis_complete` проверяет ровно `01-brd.md`/`02`/`03`/`04` (`01-questions.md` им не парсится).
 
 ---
 

docs/_templates/01-questions.md

@@ -1,43 +0,0 @@
----
-work_item: ORCH-NNN
-stage: analysis
-author_agent: analyst
-status: needs-input
-created_at: <YYYY-MM-DD>
-model_used: <resolve ORCH-41>
----
-
-# 01 — Открытые вопросы (Open Questions): ORCH-NNN — <название>
-
-Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
-
-> **Сигнальный** when-applicable артефакт (ORCH-120, adr-0053). Пишется аналитиком через **Write
-> tool** ТОЛЬКО при **блокирующей** неоднозначности бизнес-запроса, когда выпустить корректные 4
-> deliverables нельзя без ответа заказчика. Наличие этого файла с **активными** вопросами уводит
-> задачу в **Needs Input** (приоритет над «файлы готовы»). **Не** machine-verdict: гейтом
-> (`check_analysis_complete`/`check_analysis_approved`) НЕ парсится — это сигнал движку
-> (`_handle_analysis_approved_flow`).
->
-> ⚠️ Если блокирующих вопросов НЕТ — **не создавай** этот файл; выпускай полный пакет (`01-brd.md`/
-> `02-trz.md`/`03-acceptance-criteria.md`/`04-test-plan.yaml`). Не фабрикуй требования ради сдачи 4
-> файлов.
-
-## 1. Контекст
-<Что именно в бизнес-запросе (`00-business-request.md`) блокирует выпуск корректного пакета. Какие
-факты установлены, а какие — нет. На какой код `src/` это влияет.>
-
-## 2. Блокирующие вопросы
-> Каждый вопрос — конкретный, отвечаемый, с вариантами (где уместно) и указанием, почему ответ
-> блокирует анализ. Нумеруй (Q-1, Q-2, …).
-
-- **Q-1** — <вопрос>
-  - Вариант A: <…> (последствие)
-  - Вариант B: <…> (последствие)
-  - Почему блокирует: <без ответа нельзя выпустить BR/TRZ, т.к. …>
-- **Q-2** — …
-
-## 3. Что разблокирует анализ
-<Какие ответы переводят задачу из Needs Input обратно в работу: после ответов заказчика в Plane
-аналитик перезапускается (resume), читает свежие комментарии и выпускает полный пакет. Если часть
-вопросов снята, а часть осталась — **перепиши** этот файл (оставь только актуальные блокеры), иначе
-выпусти 4 deliverables (свежий пакет supersede’ит этот файл по mtime, DQ-2).>

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

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

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

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

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

@@ -1,92 +0,0 @@
----
-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

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

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

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

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

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

docs/architecture/adr/adr-0052-queued-job-run-ownership-invariant.md

@@ -1,99 +0,0 @@
----
-work_item: ORCH-126
-stage: architecture
-author_agent: architect
-status: accepted
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# adr-0052: Инвариант run-ownership строки `jobs` — «queued ⇒ run_id/pid/started_at IS NULL»
-
-- **Статус:** accepted
-- **Дата:** 2026-06-17
-- **Задача:** ORCH-126 (bug-fix контрол-плейна)
-- **Детальный ADR:** `docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md`
-
-## Контекст
-
-Колонки `jobs.run_id` и `jobs.pid` — **общий контракт liveness/идентичности run'а**, на который
-опираются несколько подсистем контрол-плейна:
-- **job-reaper (ORCH-065, adr-0011/adr-0043):** Tier-1 судит liveness running-job'а по `jobs.pid`
-  (`merge_gate.pid_alive`);
-- **`/metrics` (ORCH-099, adr-0030):** `get_running_agents` отдаёт `run_id`/`pid` running-job'ов
-  как «сырьё» для sidecar;
-- **scheduler/launcher (ORCH-1/ORCH-088):** `_spawn` выставляет `run_id` (после INSERT в `agent_runs`)
-  и `pid` (после `Popen`) **вперёд**.
-
-Но ни один путь возврата job'а в `queued` (restart-recovery `requeue_running_jobs`,
-retry `mark_job('queued')`, transient `mark_job_transient`, reaper `reap_running_job('queued')`) не
-сбрасывал run-ownership — он оставался «протухшим» от прошлой попытки. Возникало физически невозможное
-состояние `status='queued'` с непустыми `run_id`/`pid` при `started_at IS NULL`. Поскольку pid после
-рестарта контейнера может быть **переиспользован** ОС, `pid_alive(stale)` ложно возвращает `True`,
-reaper видит «живой» фантомный `running` и при `max_concurrency=1` (дефолт) клинит клейм **всей**
-очереди — а это **общий** инстанс/очередь всех проктов (self-hosting). Инцидент ORCH-124/125: queued
-analyst-job'ы зависали навсегда даже при `ORCH_SERIAL_GATE_ENABLED=false`.
-
-Корень — **отсутствие именованного, принудительно соблюдаемого инварианта**, связывающего
-`jobs.status` с его run-ownership-колонками.
-
-## Решение
-
-Зафиксировать как **системный инвариант данных контрол-плейна**:
-
-> **`status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`.**
-
-То есть: **queued-job никогда не несёт run-ownership.** Run-ownership принадлежит ровно одной активной
-попытке (`running` после стампа в `_spawn`) и история живёт в таблице `agent_runs`, а не в
-`jobs.run_id`.
-
-Соблюдение (ORCH-126, без смены схемы БД, на существующих колонках):
-- **Forward-cleanup:** каждый путь перехода в `queued` выставляет `run_id=NULL, pid=NULL` той же
-  UPDATE-транзакцией, что чистит `started_at`/`finished_at` (атомарные `status`-guard'ы сохранены).
-- **Clean claim (defense-in-depth):** `claim_next_job` при флипе `queued→running` сбрасывает stale
-  `pid`/`run_id` тем же UPDATE — между claim и стампом `pid` в `_spawn` строка несёт `pid IS NULL`,
-  не чужой pid (offline hot-path не трогается).
-- **Self-heal + наблюдаемость:** «невозможные» queued-строки санируются идемпотентно при старте/реапе
-  (never-raise) и видны счётчиком в `GET /queue` — защита от рецидива, если будущий путь возврата в
-  `queued` забудет инвариант.
-
-**Норматив на будущее:** любой новый путь, переводящий job в `queued`, **обязан** соблюсти инвариант
-(сбросить `run_id`/`pid`). Reviewer ловит нарушение как ≥P1 (фантомный `running` способен заклинить
-очередь всех проектов).
-
-`STAGE_TRANSITIONS` / реестр `QG_CHECKS` / `check_*` / machine-verdict-ключи / **схема БД** —
-байт-в-байт. Это инвариант данных планировщика, **не** Quality Gate и **не** стадия.
-
-## Альтернативы
-
-- **DB-level CHECK/триггер** — отвергнуто: смена схемы; раняющий констрейнт нарушает never-raise и мог
-  бы заклинить очередь всех проектов. Инвариант лучше держать кодом + self-heal, чем раняющим
-  констрейнтом.
-- **Reaper-side эвристика поверх stale pid** — отвергнуто: лечит симптом у одного читателя, оставляет
-  stale-данные другим (`/metrics`); reaper уже корректно трактует `pid IS NULL`.
-- **Новая колонка-эпоха run'а** — отвергнуто: смена схемы, избыточно; инвариант выразим на
-  существующих колонках.
-
-## Последствия
-
-- Класс «фантомный `running` клинит `max_concurrency=1`-очередь всех проектов» закрыт у корня;
-  восстановлена корректность Tier-1 reaper-liveness; чище `/metrics`.
-- Инвариант **назван** → перестаёт быть «неявным предположением» reaper'а/metrics и становится
-  проверяемым контрактом (reviewer + self-heal).
-- Нулевая регрессия для здоровых job'ов и enduro-trails; миграция БД не требуется (аномальные строки
-  санируются при первом старте).
-- Аддитивно/обратимо: **не** `arch:major-change` (нет новой стадии / QG / таблицы / смены топологии).
-- **Откат:** ревертом ORCH-126 PR; опц. self-heal/диагностика — своим флагом.
-
-## Связи
-
-- adr-0011 / `docs/work-items/ORCH-065/06-adr/` (job-reaper Tier-1 по `jobs.pid` — читатель инварианта;
-  фикс восстанавливает его предусловие).
-- adr-0043 / `docs/work-items/ORCH-113/06-adr/` (finalizer-liveness — ортогонален: process-local,
-  по `job_id`).
-- adr-0045 / `docs/work-items/ORCH-114/06-adr/` (transition-lease — ортогонален: своя таблица/колонки,
-  recovery по boot-id).
-- adr-0030 / `docs/work-items/ORCH-099/06-adr/` (`/metrics` `get_running_agents` — читатель `pid`/
-  `run_id`; уже допускает `pid IS NULL`).
-- adr-0002 (job-queue ORCH-1 — порождающая модель `jobs`).
-</content>

docs/architecture/adr/adr-0053-analyst-open-questions-needs-input-flow.md

@@ -1,82 +0,0 @@
----
-work_item: ORCH-120
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# ADR-0053: Поток «открытые вопросы аналитика → Needs Input» (приоритет + пауза + resume)
-
-Сквозной (cross-cutting) ADR. Детальное решение задачи —
-`docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md`.
-
-Статус: **Proposed** · Дата: 2026-06-17 · Источник: **ORCH-120** (bug → escalate full-cycle)
-
-## Контекст
-
-Конвейер обязывает аналитика выпустить 4 файла (`01-brd`/`02-trz`/`03-acceptance-criteria`/
-`04-test-plan.yaml`), иначе exit-гейт `analysis` не пройдёт. При неоднозначном бизнес-запросе
-(классика — `Description: TBD`) у аналитика нет рабочего канала уточнения → он **фабрикует**
-требования. Механизм «вопросы → Needs Input» в `_handle_analysis_approved_flow`
-(`src/stage_engine.py`) **существует, но мёртв** из-за четырёх смежных дефектов: контракт не
-доведён до промпта; ветка `files_ok` имеет приоритет над веткой вопросов; Needs Input клинит
-serial-gate репо (ORCH-088); нет гигиены устаревшего `01-questions.md`.
-
-Поток пересекает несколько подсистем, поэтому фиксируется сквозным ADR (анти-археология ORCH-078:
-блок `_handle_analysis_approved_flow` несёт 3+ маркера — ORCH-066/088/089/124):
-- **ORCH-066** — Needs Input принадлежит **только** аналитику (слой B индикации ≠ слой A стадий).
-- **ORCH-088** — per-repo serial-gate: «активная задача» по `tasks.stage NOT IN ('done','cancelled')`.
-- **ORCH-124** (adr-0051) — ортогональная ось «пауза» (`tasks.paused_at`): исключает задачу из
-  «активного» предиката, **не** обходя оси `task_deps`/`repo_freeze`/терминал.
-- **ORCH-089** — autoApprove (человеческий BRD-гейт по лейблу) в той же ветке `files_ok`.
-
-## Решение
-
-**Активировать мёртвый путь четырьмя согласованными изменениями** — аддитивно, под kill-switch,
-скоуп self-hosting, never-raise:
-
-1. **Контракт промпта + канон артефакта.** `.openclaw/agents/analyst.md` документирует канал
-   «блокирующие вопросы → `01-questions.md`, НЕ фабриковать deliverables»; `01-questions.md`
-   стандартизирован как **сигнальный** when-applicable артефакт (скелет `docs/_templates/` +
-   строка манифеста `PIPELINE_DOCS.md`) — **не** machine-verdict (гейтом не парсится, BR-6).
-2. **Приоритет «вопросы активны» > «файлы готовы».** В `_handle_analysis_approved_flow` предикат
-   активных вопросов проверяется **до** ветки `files_ok` → блокирующие вопросы надёжно достигают
-   Needs Input даже при частичных/сфабрикованных deliverables.
-3. **Авто-park через ось «пауза» ORCH-124.** Переход в Needs Input вызывает `db.set_task_paused`
-   → задача исключается из «активного» предиката serial-gate → следующая задача репо входит в
-   `analysis`, пока первая ждёт человека (не клинит FIFO неопределённо долго).
-4. **Resume + unpark.** `handle_status_start` (analysis-resume) снимает паузу (`clear_task_paused`)
-   и перезапускает аналитика; relaunch-guard ORCH-090 (только `analysis`) не ослаблен.
-
-**Устаревание `01-questions.md` (детерминированно, offline):** freshness-gated supersede по mtime —
-вопросы «активны», пока пакет неполон ИЛИ `01-questions.md` не старше всех 4 deliverables; полный
-свежий пакет supersede’ит старый файл (выбор механизма и отвергнутые альтернативы — ADR-001 DQ-2).
-
-## Инварианты (нормативно)
-
-- **Поток — pre-gate-ветка движка, НЕ Quality Gate.** `STAGE_TRANSITIONS` / реестр и имена
-  `QG_CHECKS` / семантика `check_analysis_complete`/`check_analysis_approved` / machine-verdict-ключи
-  / схемы существующих таблиц — **байт-в-байт не тронуты**.
-- **Без схемы БД:** переиспользуется `tasks.paused_at` (ORCH-124); новых таблиц/колонок нет.
-- **ORCH-066 не расширяется:** Needs Input остаётся **только** у аналитика.
-- **ORCH-124 не регрессирует:** пауза ортогональна — оси `task_deps`/`repo_freeze`/терминал
-  `{done,cancelled}` `paused_at` **не читают**; анти-stale-base ORCH-088 цел (нормальная задача
-  `paused_at IS NULL` держит гейт; свежесть базы на resume — существующими механизмами).
-- **Self-hosting-безопасность:** поток только меняет Plane-статус/паузу/коммент и читает worktree —
-  не деплоит, не рестартит прод-контейнер, не пушит в `main`, не трогает detached-процессы.
-- **never-raise / обратимость:** все врезки изолированы и деградируют к прежнему поведению;
-  3 флага (`analyst_questions_gate_enabled` / `analyst_questions_gate_repos` /
-  `analyst_needs_input_autopause_enabled`) с безопасными дефолтами → off/out-of-scope = байт-в-байт
-  как до ORCH-120 (enduro не затронут).
-
-## Последствия
-
-Конвейер перестаёт строить решения поверх домыслов; serial-gate не клинит на задаче, ждущей
-человека (поддержка автономного пакетного прогона ORCH-088); аналитик получает легитимный канал
-уточнения. Цена — узкое связывание индикации с осью планировщика при авто-park (смягчено флагом +
-узким триггером + never-raise) и зависимость supersede от mtime (смягчено: полный прогон всегда
-пишет свежие deliverables + контракт промпта). Детали, альтернативы и риски —
-`docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md`,
-`docs/work-items/ORCH-120/10-tech-risks.md`.

docs/architecture/adr/adr-0054-task-estimation-status-trigger.md

@@ -1,94 +0,0 @@
----
-work_item: ORCH-020
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# ADR-0054: Оценка задачи — операторский статус-триггер «Оценка» + детерминированная эвристика по истории
-
-Сквозной (cross-cutting) ADR. Детальное решение задачи —
-`docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md`.
-
-Статус: **Proposed** · Дата: 2026-06-17 · Источник: **ORCH-020**
-
-## Контекст
-
-Заказчик планирует бэклог вручную и хочет видеть прогноз **стоимости / времени / токенов / сложности
-(story points `{1,2,3,5,8}`)** до отправки задачи в работу. Ключевое требование триггера (после REJECT
-2026-06-17): оценка — **операторский жест в Plane** (перевод issue в выделенный статус «Оценка»,
-**массово** через multi-select), а не невидимый авто-шаг на `start_pipeline`. Шаг 2 (адаптивный выбор
-модели) — **вне объёма**.
-
-Решение пересекает несколько подсистем (webhook-роутинг, `plane_sync`, БД, `notifications`, `stage_engine`
-done-хук), поэтому фиксируется сквозным ADR. Опирается на установленные инварианты платформы:
-- **Семейство операторских action-статусов** STOP (ORCH-090) / Confirm Deploy (ORCH-059): fail-closed
-  `.get("<key>")`-ветка в `handle_issue_updated`, ключ **намеренно отсутствует** в `_DEFAULT_STATES`.
-- **Write-guard ORCH-117** — все записи в Plane изолированы от тест/worktree-процессов.
-- **leaf-паттерн** (serial_gate/coverage_gate/bug_fast_track/lessons): never-raise, kill-switch, скоуп
-  `*_repos` (пусто → self-hosting only), read-only блок в `GET /queue`.
-- **determinization-политика ORCH-118** (`llm-usage-policy.md`): не вводить avoidable LLM-пути.
-
-## Решение
-
-**Вводим третий член семейства action-статусов — «Оценка» — как side-механизм, делегирующий новому leaf
-`src/estimator.py`.** Механизм прогноза — **детерминированная эвристика по истории** (чистые функции, без
-LLM-вызова). Аддитивно, под kill-switch, скоуп self-hosting, never-raise, fail-safe:
-
-1. **Триггер (D4).** `_PLANE_NAME_TO_KEY["Оценка"]="estimate"` (НЕ в `_DEFAULT_STATES`); fail-closed ветка
-   `proj_states.get("estimate")` → `handle_estimate` (off-loop `to_thread`, зеркало `handle_stop`).
-   Взаимоисключение жестов — по различию UUID статусов, не по порядку.
-2. **Анти-disruption + авто-возврат + анти-loop (D5).** Guard `applies(repo)` ПЕРВЫМ (локально) +
-   `has_active_job_for_task` (активный job → no-op, не выдёргивать in-flight). После оценки —
-   `set_issue_backlog`; `backlog` не совпадает ни с одной триггер-веткой → возврат = no-op-эхо.
-3. **Механизм прогноза (D1/D2/D3).** **Без LLM:** прогноз = средние токены/время/стоимость похожих
-   `done`-задач (`repo` + `track` ORCH-019, через read-only `usage.py`-агрегаты), bootstrap при пустой
-   истории; story-points — чистая функция-бакетизатор по `forecast_cost_usd` с конфигурируемыми порогами.
-4. **Запись в Plane (D6).** Прогноз story-points → `set_issue_estimate_point` (FK на estimate-point,
-   резолв `value→uuid`); факт → `set_issue_point` (устойчивый int); коммент → `add_comment`. Все под
-   `_guard_allows_write` (ORCH-117); отсутствие estimate-системы → best-effort пропуск + лог (NFR-7).
-5. **Персистентность (D7).** Новая аддитивная таблица `task_estimates` (`UNIQUE(work_item_id)`,
-   UPSERT-идемпотентность пере-оценки; `task_id` нуллабелен — issue на бэклоге). Фундамент петли калибровки
-   (ORCH-8).
-6. **Поверхности (D8).** Пункт «Оценка» (время·токены·стоимость) в общей Telegram-карточке
-   (`notifications`, never-raise, ORCH-087/095-совместимо).
-7. **Факт на `done` (D9).** Best-effort врезка в `stage_engine.advance_stage` (блок `next_stage=="done"`,
-   после terminal-sync): факт из `usage.py` → `set_actual` + `set_issue_point`; `estimate_point` не
-   перезаписывается.
-
-**Главное архитектурное решение — отказ от LLM-оценщика (D1).** Причины: NFR-5 (massive multi-select
-умножил бы LLM-вызовы и конкурировал бы за единственный транспорт `launcher._spawn` с боевыми агентами,
-рискуя обслуживанием enduro), NFR-4 (стоимость самой оценки), и политика ORCH-118 (размер задачи
-деривируем из tool-сигналов — суждение LLM не требуется). Контракт `estimate()` — граница расширения под
-будущий гибрид без переписывания вызывающих (но он сейчас НЕ строится).
-
-## Инварианты (нормативно)
-
-- **Оценка — наблюдатель/продюсер, НЕ Quality Gate и НЕ переход стадии.** `STAGE_TRANSITIONS` / реестр и
-  имена `QG_CHECKS` / семантика `check_*` / machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/
-  `staging_status:`/`security_status:`/`coverage_status:`) / **схемы существующих таблиц** — **байт-в-байт
-  не тронуты**. Статус «Оценка» не добавляет ребра в машину стадий.
-- **Горячий путь не тронут:** `resolve_agent_model`/`resolve_agent_effort`/`_spawn` без изменений (Шаг 2
-  вне объёма — отдельный work item с зависимостью на ORCH-13).
-- **Схема БД:** ровно **одна** аддитивная таблица `task_estimates` (`CREATE TABLE IF NOT EXISTS`);
-  существующие таблицы не изменяются (NFR-8). Hot-path `claim_next_job`/очередь её не читают.
-- **Self-hosting-безопасность:** модуль только читает/пишет свою таблицу, читает usage-агрегаты и пишет в
-  Plane/Telegram — не деплоит, не рестартит прод-контейнер, не трогает `main`/force-push, без процессов.
-- **never-raise / обратимость:** все публичные функции и врезки изолированы; `estimator_enabled=false` /
-  доска без статуса «Оценка» / репо вне `estimator_repos` → байт-в-байт как до ORCH-020 (enduro и текущий
-  orchestrator не затронуты).
-- **Без kill-switch обхода write-guard:** записи `estimate_point`/`point`/коммент/состояние подчиняются
-  ORCH-117 (anti-drift: тест-процесс физически не пишет в боевой Plane).
-
-## Последствия
-
-Оператор получает прогноз для планирования бэклога одним массовым жестом; пере-оценка идемпотентна;
-заложен леджер прогноз↔факт под петлю калибровки (ORCH-8). Цена — net-new интеграция с Plane-estimate API
-(`estimate_point` — FK; смягчено best-effort/fail-safe + устойчивым int-`point`) и начальные пороги
-story-points (смягчено конфигурируемостью + леджером). Решение сознательно консервативно (детерминировано,
-обратимо, согласовано с ORCH-118) и **не требует** `arch:major-change` (аддитивный leaf по устоявшемуся
-паттерну, без новой стадии/правки таблиц/смены БД). Детали, альтернативы и риски —
-`docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md`,
-`docs/work-items/ORCH-020/07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`.

docs/architecture/internals.md

@@ -70,14 +70,6 @@ STAGE_TRANSITIONS = {
 рёбер не меняются), а терминал STOP-отмены. Системный предикат «задача завершена» —
 `stage ∈ {done, cancelled}` (синхронно в `reconciler`/`serial_gate`/`task_deps`; adr-0026).
 
-**Ось «пауза» ⊥ оси «терминальность» (ORCH-124, adr-0051):** serial-gate вводит **отдельную** ось
-паузы `tasks.paused_at IS NOT NULL` (durable per-task park-сигнал) — **ортогональную** терминалу. Для
-serial-gate «активная задача» ⇔ `stage NOT IN ('done','cancelled') AND paused_at IS NULL` (паузнутый
-предшественник не держит FIFO). **Терминал `{done,cancelled}` НЕ расширяется паузой:** `task_deps` и
-`stages.py` колонку `paused_at` НЕ читают (паузнутая объявленная зависимость по-прежнему блокирует
-зависимый job; пауза не обходит `repo_freeze`). Пауза — признак планировщика очереди, не стадия и не
-терминальное состояние.
-
 ### 3. Quality Gates (`src/qg/checks.py`)
 
 | Check | Метод проверки |
@@ -104,33 +96,6 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash
 3. Стартует **watchdog thread** (per-role wall-clock бюджет → SIGTERM→grace→SIGKILL по pid; ORCH-109: developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт, `_resolve_timeout`)
 4. Стартует **monitor thread**: `proc.wait()` (гарантированный reap → реальный exit_code в БД) → закрывает log_fh → git commit/push → auto-advance
 
-**Детерминированные перехваты `launch_job` ДО `_spawn` (no-LLM джобы).** Перед `_spawn` `launch_job`
-перехватывает зарезервированные роли и исполняет их детерминированно, сам ведя `jobs`-строку через
-`mark_job` (нет `agent_runs`, нет токенов): `deploy-finalizer` (D1, ORCH-036 Phase C) и
-`post-deploy-monitor` (D2, ORCH-021). **ORCH-115 ([adr-0048](adr/adr-0048-deterministic-staging-runner.md)):**
-тем же паттерном перехватывается джоб `deployer` на стадии `deploy-staging` для in-scope репо
-(дискриминатор — **стадия задачи**, не имя роли: роль `deployer` общая для `deploy-staging`/`deploy`;
-+`staging_runner.applies(repo)` под kill-switch `staging_runner_enabled`, скоуп `staging_runner_repos`,
-пусто → self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к
-LLM). Leaf `src/staging_runner.py` (зеркало `run_deploy_finalizer`) исполняет staging-сюиту через
-`proc_group` (tree-kill, таймаут `staging_runner_timeout_s`), маппит exit-код
-`self_deploy.map_exit_code_to_status`, пишет `15-staging-log.md` (тот же machine-key `staging_status:`)
-и вызывает существующий `advance_stage(finished_agent="deployer")` (см. §5). Так LLM-агент `deployer`
-на `deploy-staging` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты.
-**ORCH-116 ([adr-0050](adr/adr-0050-deterministic-test-runner.md)):** тем же паттерном (рядом с
-ORCH-115) перехватывается джоб `tester` на стадии `testing` для in-scope репо с тест-контрактом
-(дискриминатор — роль `tester` **И** `tasks.stage == "testing"` **И** `test_runner.applies(repo)` под
-kill-switch `test_runner_enabled`, скоуп `test_runner_repos`, резолв `_has_test_contract`; пусто →
-self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к LLM). Leaf
-`src/test_runner.py` (зеркало `run_staging_gate`) исполняет регресс `pytest <target>` **в worktree
-ветки** через `proc_group` (tree-kill, таймаут `test_runner_timeout_s`) + read-only smoke, маппит
-exit-код `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе→`FAIL`), пишет
-`13-test-report.md` (тот же machine-key `result:`; 52c-`status:` выровнен по вердикту — D6.1) и вызывает
-существующий `advance_stage(finished_agent="tester")` (см. §5). Двухуровневый исход (анти-ORCH-110):
-сюита НЕ исполнилась → bounded defer re-queue **`tester`**-джоба, не код-фейл-откат. Так LLM-агент
-`tester` на `testing` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_tests_passed`/схема
-БД не тронуты.
-
 ### 5. Auto-advance (`launcher._try_advance_stage`)
 
 После успешного завершения агента:
@@ -402,8 +367,8 @@ webhook (plane/gitea)                 background thread (queue_worker)
 |--------|------------|
 | `status` | `queued` → `running` → `done` \| `failed` \| `cancelled` (ORCH-090: терминальный исход STOP-отмены, не реквью'ится) |
 | `attempts` / `max_attempts` | счётчик попыток (инкремент при claim) / лимит ретраев (default 2) |
-| `run_id` | FK на `agent_runs.id` после старта. **ORCH-126 (adr-0052):** run-ownership; `queued ⇒ run_id IS NULL` (история run'а живёт в `agent_runs`, не в `jobs.run_id`) |
-| `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent). **ORCH-126 (adr-0052):** `queued ⇒ pid IS NULL` — иначе протухший (возможно переиспользованный ОС) pid ложно «оживает» в Tier-1 reaper и клинит очередь |
+| `run_id` | FK на `agent_runs.id` после старта |
+| `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent) |
 | `task_content` | ТЗ, которое пишется в task-файл агента |
 | `error` | последняя ошибка |
 
@@ -419,10 +384,6 @@ status='queued'` и проверяет `rowcount`. При гонке двух т
 
 В `main.py` lifespan **после** M-1 orphan-recovery вызывается `requeue_running_jobs()`:
 jobs со статусом `running` (воркер умёр на рестарте) → возвращаются в `queued`.
-**ORCH-126 (adr-0052):** возврат в `queued` сбрасывает run-ownership (`run_id=NULL, pid=NULL`
-вместе с `started_at`) — мёртвый воркер оставил их протухшими, и фантомный pid заклинил бы
-Tier-1 reaper. Сразу следом `reaper.sanitize_impossible_queued_once()` идемпотентно санирует
-любые «невозможные» queued-строки (`queued` с непустым `run_id`/`pid`/`started_at`).
 **ORCH-114 (adr-0045):** сразу следом вызывается `transition_lease.recover_on_startup()` —
 новый процесс имеет свежий `boot_id`, поэтому ВСЕ записанные ранее `transition_lease`
 устарели (boot-id mismatch) → реклеймятся, и только что requeued-jobs переисполняют свои
@@ -479,35 +440,6 @@ claim делает `_try_advance_stage` (advance+enqueue) — проигравш
 / `ORCH_LEASE_RECLAIM_ENABLED`; снимок в `GET /queue` (блок `reaper`). Подробнее —
 adr-0011.
 
-### Инвариант run-ownership строки `jobs` (ORCH-126, adr-0052)
-
-Колонки `jobs.run_id`/`jobs.pid` — **общий контракт liveness/идентичности run'а** (читают
-job-reaper Tier-1 по `pid`, `/metrics` `get_running_agents`). Системный инвариант данных:
-
-> **`status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`.**
-
-То есть **queued-job никогда не несёт run-ownership** — оно принадлежит ровно одной активной
-попытке (`running` после стампа в `_spawn`). Корень дефекта (инцидент ORCH-124/125, job 2286
-`queued + run_id=759 + pid=35 + started_at=NULL`): ни один путь возврата в `queued` не сбрасывал
-run-ownership, а после рестарта контейнера pid мог быть **переиспользован** ОС → `pid_alive(stale)`
-ложно `True` → reaper «видел живой» фантомный `running` и при `max_concurrency=1` клинил клейм
-**всей** общей очереди. Соблюдение (без смены схемы БД):
-- **Forward-cleanup** — каждый путь перехода в `queued` (`requeue_running_jobs`,
-  `mark_job('queued')`, `mark_job_transient`, `reap_running_job('queued')`) выставляет
-  `run_id=NULL, pid=NULL` той же UPDATE-транзакцией, что чистит `started_at` (атомарные
-  `status`-guard'ы сохранены). Безусловно (исправление инварианта данных, без флага).
-- **Clean claim (defense-in-depth)** — `claim_next_job` при флипе `queued→running` сбрасывает
-  stale `pid`/`run_id` тем же UPDATE → между claim и стампом `pid` в `_spawn` строка несёт
-  `pid IS NULL`. SELECT-гейт не тронут (offline hot-path).
-- **Self-heal + наблюдаемость** — `db.sanitize_impossible_queued()` идемпотентно санирует
-  «невозможные» queued-строки при старте (`main.lifespan`) и на каждом реап-тике (never-raise,
-  kill-switch `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED`, дефолт on); счётчик
-  `impossible_queued_total` в блоке `reaper` снимка `GET /queue`.
-
-**Норматив:** любой новый путь возврата job в `queued` ОБЯЗАН соблюсти инвариант (сбросить
-`run_id`/`pid`); reviewer ловит нарушение как ≥P1. Подробнее — adr-0052,
-`docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md`.
-
 ### Конфиг
 
 - `ORCH_MAX_CONCURRENCY` (default 1) — лимит параллельных jobs.

docs/architecture/llm-call-sites.md

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

docs/architecture/llm-determinization-roadmap.md

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

docs/architecture/llm-usage-policy.md

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

docs/deployment/BUNDLED_SETUP.md

@@ -179,8 +179,8 @@ docker compose -f deploy/bundled/docker-compose.yml ps
 
 Доводка «одним запуском»: preflight → секреты → up/готовность → init Gitea
 (полностью автоматом: админ-бот + API-токен) → init Plane → онбординг
-sandbox-проекта **строго** кирпичом `onboard_project.py` (23 канонических
-статуса, включая fail-closed **`Confirm Deploy`**, **`STOP`** и **`Оценка`**, лейблы,
+sandbox-проекта **строго** кирпичом `onboard_project.py` (22 канонических
+статуса, включая fail-closed **`Confirm Deploy`** и **`STOP`**, лейблы,
 репо+webhook — golden source `docs/operations/ONBOARDING.md` §1) → git-доступ
 агентов → сборка `.env`/`.env.watchdog` → health.
 

docs/deployment/LITE_SETUP.md

@@ -206,13 +206,12 @@ curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/" \
 `ORCH_PLANE_API_TOKEN` в `.env`. Токен должен иметь право создавать проекты/статусы
 (нужно для `onboard_project.py apply`, §10).
 
-**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **23 канонических статуса** с
+**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **22 канонических статуса** с
 точными именами и группами; их создаёт `python3 scripts/onboard_project.py apply` (§10),
 полная таблица — `docs/operations/ONBOARDING.md` §1 (golden source; здесь не дублируется).
-Три имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
-активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя),
-**`STOP`** (отмена задачи; обязан быть в группе `cancelled`) и **`Оценка`** (триггер
-оценки задачи, ORCH-020; группа `unstarted`/`backlog`, НЕ терминальная).
+Два имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
+активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя) и
+**`STOP`** (отмена задачи; обязан быть в группе `cancelled`).
 
 ```bash
 # после §10 — проверить, что статусы созданы:
@@ -220,7 +219,7 @@ curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/<proj
   -H "X-API-Key: $ORCH_PLANE_API_TOKEN" | python3 -m json.tool | grep -c '"name"'
 ```
 
-**Проверка:** счётчик имён = 23 (или больше, если в проекте остались дефолтные статусы
+**Проверка:** счётчик имён = 22 (или больше, если в проекте остались дефолтные статусы
 Plane) и среди них `Confirm Deploy` и `STOP` — PASS.
 
 **5.4. Webhook + HMAC.** Приёмник — `POST https://<orchestrator-public-host>/webhook/plane`;
@@ -433,7 +432,7 @@ curl -fsS http://127.0.0.1:8501/health
 
 ## 10. Регистрация проекта заказчика
 
-Onboarding-CLI создаёт Plane-проект с 23 статусами и лейблами (`autoApprove` /
+Onboarding-CLI создаёт Plane-проект с 22 статусами и лейблами (`autoApprove` /
 `autoDeploy` / `Bug`), Gitea-репо с webhook'ом, скелет репо (kit) и печатает merged-реестр.
 Полный runbook — `docs/operations/ONBOARDING.md`; Lite-последовательность:
 

docs/operations/FAQ_STOP.md

@@ -1,87 +0,0 @@
-# FAQ: отмена задачи через статус STOP
-
-Эта страница — для пользователя доски Plane. Она объясняет простыми словами, что делает статус
-**STOP**, как им безопасно остановить задачу и чего от него ждать. Читать код для этого не нужно.
-
-Технические детали механизма — в
-[инженерном обзоре конвейера](../overview/tech-pipeline.md#отмена-stop--cancelled) и в
-[ADR ORCH-090](../work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md) (источник истины
-поведения). Эта страница их **не дублирует**, а пересказывает «для человека» и ссылается на них.
-
-## Что делает статус STOP?
-
-STOP — это «кнопка отмены» задачи. Перевод задачи в статус STOP останавливает работу агента,
-снимает задачу с очереди, прибирает рабочие материалы (ветку и worktree) и помечает задачу
-отменённой (`cancelled`). Нажимать его безопасно даже посреди конвейера.
-
-## Как отменить задачу?
-
-Переведите issue в статус **STOP** на доске Plane — так же, как меняете любой другой статус.
-
-Предусловие: на доске должен быть заведён статус **STOP** (группа `cancelled`). Если его нет, STOP
-не сработает (см. раздел «Я нажал STOP, но ничего не произошло — почему?»).
-
-## Что происходит, когда я нажимаю STOP?
-
-По шагам:
-
-1. Активный агент **останавливается** (мягкая остановка процесса).
-2. Все **job'ы** этой задачи в очереди снимаются и больше не перезапускаются.
-3. Рабочая **ветка** задачи и её **worktree** удаляются. Ветка `main` и прод-контейнер при этом
-   никогда не трогаются.
-4. Задача переходит в терминальное состояние **`cancelled`**.
-5. Приходит уведомление в **Telegram** («🛑 … задача ОТМЕНЕНА (STOP)») и **комментарий в Plane**.
-
-При этом **документы задачи** (бизнес-запрос, анализ, ТЗ, ADR и т.д.) **сохраняются** — удаляются
-только рабочая ветка и worktree, не история документов.
-
-## Что если задача в этот момент сливается или деплоится?
-
-Если STOP пришёл во время **необратимого шага** (слияние в `main` или выкладка в прод), отмена
-**аккуратно откладывается** до честного завершения этого шага. Вы увидите уведомление вида
-«⏸️ … отмена ОТЛОЖЕНА». Ветка `main` и прод при этом не трогаются; как только шаг честно
-завершится, отмена применяется автоматически.
-
-Иными словами: STOP **не прерывает** уже начатый необратимый шаг на полпути — он дожидается его
-честного завершения, а затем отменяет задачу.
-
-## Откатит ли STOP уже выложенный код?
-
-**Нет.** STOP сбрасывает **незавершённый прогресс** задачи (рабочую ветку, worktree, очередь), но
-**не откатывает** код, который уже влит в `main` или выложен в прод. Откат уже выложенного —
-это отдельная задача (revert), и STOP её **не делает**.
-
-## Как перезапустить отменённую задачу?
-
-Отменённую задачу **нельзя «продолжить с середины»**. Чтобы начать заново, переведите её в статус
-**«To Analyse»** — задача будет создана **с нуля**: новая ветка от актуального `main`, новый анализ
-и полный проход конвейера.
-
-## Я нажал STOP, но ничего не произошло — почему?
-
-Вероятные причины:
-
-- На доске **нет статуса STOP** — переход не распознаётся (безопасный no-op). Заведите статус STOP
-  (группа `cancelled`) и попробуйте снова.
-- Задача **уже завершена или уже отменена** — повторный STOP ничего не меняет (это нормально,
-  идемпотентный no-op, задача не ломается).
-- Отмена **отключена для репозитория** настройкой оператора (`stop_status_enabled` /
-  `stop_status_repos`) — обратитесь к оператору.
-
-## Где увидеть, что задача отменена?
-
-- **Карточка задачи в Telegram** покажет «🛑 … ОТМЕНЕНА (STOP)».
-- В **Plane** появится комментарий об отмене.
-- Оператор может увидеть отмену на служебной странице состояния `GET /queue` — в блоке `stop`.
-
-## STOP, Approved и Confirm Deploy — в чём разница?
-
-Это разные управляющие статусы, их легко перепутать:
-
-- **STOP** — *отменить* задачу и сбросить её незавершённый прогресс.
-- **Approved** — *одобрить* артефакт анализа (двигает задачу дальше по конвейеру); деплой он **не**
-  запускает.
-- **Confirm Deploy** — *подтвердить* выкладку в прод.
-
-Подробнее об управляющих статусах и их семантике — в
-[инженерном обзоре конвейера](../overview/tech-pipeline.md). Эта страница описывает только STOP.

docs/operations/INFRA.md

@@ -141,8 +141,6 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `ORCH_PLANE_API_URL` / `_TOKEN` / `_WORKSPACE_SLUG` | доступ к Plane API |
 | `ORCH_PLANE_WEB_URL` | внешний (браузерный) web-URL Plane для кликабельных ссылок на issue в уведомлениях (ORCH-017); пусто → фолбэк на `ORCH_PLANE_API_URL`, loopback-фолбэк → ссылка опускается |
 | `ORCH_PLANE_WEBHOOK_SECRET` | HMAC-проверка вебхуков Plane |
-| `ORCH_PLANE_TEST_WRITE_ENABLED` | ORCH-117: opt-in реальной записи в Plane из **тест-процесса** (дефолт `false` = default-deny). НЕ kill-switch прод-блока: даже `true` пишет только в sandbox-allowlist (прод-запись из pytest невозможна). В боевом/staging рантайме гард — no-op |
-| `ORCH_PLANE_TEST_SANDBOX_PROJECTS` | ORCH-117: CSV-allowlist sandbox-проектов, куда opt-in разрешает запись из тестов (дефолт = единственный SANDBOX `8c5a3025-…`; пусто → ни один проект из тестов не пишется) |
 | `ORCH_GITEA_URL` / `_TOKEN` / `_WEBHOOK_SECRET` | доступ к Gitea + HMAC |
 | `ORCH_CLAUDE_BIN` | путь к claude CLI |
 | `ORCH_REPOS_DIR` / `ORCH_HOST_REPOS_DIR` | каталог репозиториев (в контейнере / на хосте) |
@@ -226,57 +224,16 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 **Что изолировано (безопасно):**
 - Staging (8501) — отдельная БД (`./data/staging`), отдельный реестр (`ORCH_PROJECTS_JSON` = только sandbox). Прод-проекты не видит.
 - Репозитории разделены, изоляция веток через git worktree (ORCH-2).
-- **Запись в Plane из тест-процесса — sandbox-only fail-closed (ORCH-117).** Тест/worktree-процесс
-  наследует живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены на импорте `plane_sync`);
-  раньше **ничто** не мешало pytest смутировать боевую доску (инцидент ORCH-114 — «ложный Done»).
-  Теперь leaf `src/plane_write_guard.py` врезан в 3 примитива записи `plane_sync`
-  (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) и **в тест-процессе** (детект
-  `pytest`-в-процессе) блокирует запись по умолчанию; разрешена только при opt-in
-  `ORCH_PLANE_TEST_WRITE_ENABLED=true` **И** целевом проекте ∈ `ORCH_PLANE_TEST_SANDBOX_PROJECTS`
-  (sandbox-only — боевой проект запрещён даже при opt-in). Боевой и staging рантаймы
-  (`uvicorn src.main:app`, без pytest в процессе) — гард **no-op**, запись как прежде. Прод-блок
-  **без kill-switch** (выключателя-чёрного-хода нет); второй слой — autouse-floor
-  `tests/conftest.py::_plane_sandbox_only` (по образцу `_no_telegram`). Детали — `CLAUDE.md`
-  «Sandbox-only fail-closed изоляция записи в Plane (ORCH-117)», adr-0046.
 
 **Страховки:**
 - Стадия `deploy-staging` (порт 8501) — обязательный гейт перед прод-деплоем орка. Прод-деплой недостижим, пока staging-гейт не зелёный (см. `STAGING.md`, ORCH-35). Гейт условный: реален только для self-hosting (repo=orchestrator), для остальных проектов — no-op.
 - **Свежесть staging-образа (ORCH-058):** на ребре `deploy-staging → deploy` (ПОСЛЕ merge-gate, ДО Phase A) QG-под-чек `check_staging_image_fresh` пересобирает staging-образ из валидированного коммита и пересоздаёт 8501 (Strategy A), а хук перед build-once retag fail-closed сверяет OCI-лейбл `revision` с `EXPECTED_REVISION` (Strategy B). Гарантирует: в прод промоутится РОВНО провалидированный артефакт (инцидент LESSONS_ORCH-036 п.4 — тихий промоут устаревшего образа). Сборки/recreate — ТОЛЬКО staging (8501); FAIL → откат на `development`. Условный: реален только для self-hosting.
 - **Гигиена shared deploy-базы (ORCH-112):** self-deploy `git pull origin main` устойчив к грязному рабочему дереву deploy-базы (модифицированные tracked + untracked-остатки failed/cancelled/брошенных задач). Хук `--deploy` перед pull приводит базу к чистому `origin/main` (resilient-pull: `git fetch` + `git reset --hard origin/main` + `git clean -fd`), **строго сохраняя** rollback-снимки `.deploy-prev-image-*`, `deploy-hook.log`, gitignored `.env`/`data/`/`*.db` (НИКОГДА `-x`!), sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*`. Гейт — kill-switch `ORCH_CHECKOUT_HYGIENE_ENABLED` (дефолт `True`; off → голый pull 1:1); скоуп `ORCH_CHECKOUT_HYGIENE_REPOS` (пусто → self-hosting only). Грязь базы детектируется → лог + Telegram-алерт (Phase-C finalizer). Решает инцидент ORCH-111 (грязь ORCH-104 заблокировала `git pull`). Детально — `docs/work-items/ORCH-112/06-adr/ADR-001`, сквозной adr-0044.
 
-### Граница исполнения docker-операций — host-side, НЕ изнутри прод-контейнера (ORCH-123)
-
-**Инвариант (нормативно, adr-0049):** прод-контейнер `orchestrator` несёт **только**
-`openssh-client git curl` (+ pinned gitleaks) — **бинаря `docker` в образе НЕТ** (`Dockerfile:11`,
-`python:3.12-slim` его не несёт). `/var/run/docker.sock` **смонтирован** (`docker-compose.yml`,
-rw + `group_add 999`, «МИНА 1» ORCH-040), но **сознательно НЕ используется изнутри** контейнера: нет
-docker-клиента, и добавлять его (CLI/SDK) **нельзя** — это активировало бы дремлющий
-root-эквивалентный путь для всего, что бежит в контейнере, включая LLM-агентов (security-разбор —
-ADR-001 D2 / adr-0049 / R-1).
-
-Поэтому **все** docker-операции self-hosting исполняются **host-side** через **ssh на `127.0.0.1`**
-(`ORCH_DEPLOY_SSH_HOST`/`ORCH_DEPLOY_SSH_USER`, ssh-ключ смонтирован `:ro`), где docker CLI есть:
-- **прод-деплой** (ORCH-036, `self_deploy.build_deploy_command`) — `ssh … setsid bash hook --deploy`;
-- **image-freshness** (ORCH-058, `image_freshness.image_revision`/`rebuild_staging_image`) — `ssh … docker …`;
-- **staging-runner** (ORCH-123, `staging_runner.build_staging_command`) — `ssh … docker exec orchestrator-staging python3 … staging_check.py … --mode stub`.
-
-Сама staging-сюита (`scripts/staging_check.py`) **по-прежнему** исполняется **внутри** контейнера
-`orchestrator-staging` (8501) — меняется лишь **кто инициирует** `docker exec` (хост через ssh, а не
-прод-контейнер). До ORCH-123 staging-runner (ORCH-115) вызывал `docker exec` **изнутри**
-прод-контейнера → `FileNotFoundError` (нет `docker`) → постоянный environment-дефект ложно
-маршрутизировался как код-фейл-откат `deploy-staging → development` (инцидент ORCH-116). Фикс:
-host-side ssh-обёртка (флаг `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true`, дефолт) + трёхсторонняя
-классификация (suite-ran / permanent-env / transient-infra), где environment/инфра **никогда** не
-оканчивается код-фейл-откатом (infra-HOLD + алерт «инфра, НЕ дефект кода»), и prod-like preflight
-канала на старте сервиса. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (прежний in-container
-вызов — валиден лишь там, где docker CLI запечён в образ) или `ORCH_STAGING_RUNNER_ENABLED=false`
-(LLM-deployer 1:1). Детали — `docs/work-items/ORCH-123/06-adr/ADR-001`, сквозной adr-0049.
-
 **Правила для агентов при задачах ORCH:**
 1. НЕ перезапускать / не ронять прод-контейнер `orchestrator` в рамках задачи.
 2. Все проверки деплоя — на staging (8501), боевой 8500 не трогать.
 3. Деплой self — только через хук с health-check + авто-rollback (`DEPLOY_HOOK.md`).
-4. docker-операции исполняются **host-side через ssh** — в контейнере `docker` CLI нет (ORCH-123).
 
 ## Эксплуатация (быстрые команды)
 ```bash

docs/operations/ONBOARDING.md

@@ -46,7 +46,7 @@ hooks под выбранным owner (`--gitea-owner`, дефолт из кон
 
 1. **Проект**: создаётся с `identifier = --prefix`. Уже существует → передай
    `--plane-project-id <uuid>` (ensure распознает и пропустит).
-2. **Статусы — точные канонические имена** (23, источник — `plane_sync._PLANE_NAME_TO_KEY`;
+2. **Статусы — точные канонические имена** (22, источник — `plane_sync._PLANE_NAME_TO_KEY`;
    опечатка = тихая деградация fail-closed веток):
 
    | Статус | Группа | | Статус | Группа |
@@ -62,11 +62,9 @@ hooks под выбранным owner (`--gitea-owner`, дефолт из кон
    | Review | `started` | | **STOP** | **`cancelled`** |
    | Testing | `started` | | Awaiting Deploy | `started` |
    | Deploying | `started` | | Monitoring after Deploy | `started` |
-   | **Оценка** | **`unstarted`** | | | |
 
    ⚠️ Код-критично: `STOP` обязан быть в группе `cancelled` (иначе ветка отмены молча не
-   активируется); **`Оценка`** (триггер оценки задачи, ORCH-020) — группа `unstarted`/`backlog`,
-   **НЕ** терминальная; в терминальных группах (`completed`/`cancelled`) — ТОЛЬКО
+   активируется); в терминальных группах (`completed`/`cancelled`) — ТОЛЬКО
    Done/Cancelled/STOP, иначе terminal-detection ложно сочтёт живую задачу терминальной.
 3. **Лейблы**: `autoApprove`, `autoDeploy`, `Bug` (имена — из конфига оркестратора; их
    отсутствие = fail-safe ручной режим / полный цикл).
@@ -151,7 +149,7 @@ hooks под выбранным owner (`--gitea-owner`, дефолт из кон
      --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
    ```
 
-   Проверяет: запись реестра парсится и совпадает по полям; все 23 статуса резолвятся
+   Проверяет: запись реестра парсится и совпадает по полям; все 22 статуса резолвятся
    (включая fail-closed `Confirm Deploy`/`STOP`); лейблы на месте; webhook существует и
    активен; kit-файлы в репо (6 промптов, `AGENTS.md`, `INFRA.md`, `_templates`/`_standards`);
    нет неразрешённых плейсхолдеров. Любой gap → exit `2` с перечнем.

docs/overview/business.md

@@ -42,10 +42,6 @@
   аналитики и отдельной стадии проектирования, но через все те же гейты качества.
 - **Отмена задачи одной кнопкой.** Перевод задачи в статус «STOP» в трекере останавливает
   работу, снимает её с очереди и прибирает за собой — безопасно даже посреди конвейера.
-- **Оценка задачи до запуска.** Перевод задачи в статус «Оценка» в трекере даёт прогноз её
-  стоимости, времени и сложности (story points) по истории похожих задач — можно оценить
-  сразу пачку задач и спланировать, что и когда брать в работу. По завершении задачи рядом
-  с прогнозом ложится факт — оценки калибруются на реальных данных.
 - **Наблюдаемость.** У каждой задачи — живая карточка в Telegram (стадия, время, стоимость);
   у платформы — служебные страницы состояния и машинные метрики; история отклонений пишется
   в журнал уроков.
@@ -101,13 +97,6 @@
 Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и
 рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в
 необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения.
-Подробнее — [FAQ по статусу STOP](../operations/FAQ_STOP.md).
-
-### Сценарий 7: оценить бэклог перед планированием
-Оператор выделяет несколько задач в бэклоге и переводит их в статус «Оценка». По каждой
-платформа считает прогноз стоимости, времени и сложности по истории завершённых задач и
-возвращает задачу в бэклог с проставленной оценкой и комментарием. Видно, что дорого, а что
-дёшево — и чем наполнить ближайший прогон. По завершении задачи рядом ляжет факт.
 
 ---
 

docs/overview/presentation.md

@@ -71,7 +71,7 @@
 
 - Запуск: перевод задачи в статус «To Analyse» — единственная точка входа в конвейер
 - Статусы Plane — индикация, а не управление: платформа выставляет их сама (Backlog → … → Done)
-- Статусы-действия, на которые платформа реагирует: запуск, человеческие гейты, отмена (STOP) и оценка задачи («Оценка»)
+- Управляющих статусов ровно три: запуск, человеческие гейты и отмена
 - Ход задачи виден сразу: статусы доски, живая карточка в Telegram, комментарии в задаче со ссылками на ветку и PR
 
 > Визуал: доска Plane с движущейся карточкой и зеркальное уведомление в Telegram
@@ -83,7 +83,6 @@
 - Лейблы «autoApprove» / «autoDeploy» снимают эти два решения для пакетного авто-режима
 - Авто-режим убирает только ожидание человека — ни одна техническая проверка не пропускается
 - Лейбл «Bug» — короткий багфикс-маршрут; статус «STOP» — безопасная отмена с уборкой ветки и worktree, не трогает прод
-- Статус «Оценка» — прогноз стоимости, времени и сложности задачи (можно пачкой) с возвратом в бэклог, без запуска LLM
 
 > Визуал: две кнопки человека, переключатели авто-лейблов и стоп-кран STOP
 
@@ -138,7 +137,6 @@
 - Пакет задач на ночь: метки авто-одобрения, утром всё на проде
 - Багфикс по короткому маршруту с обязательным регресс-тестом
 - Остановить задачу: статус STOP — безопасная отмена с уборкой
-- Оценить бэклог: пачка задач в статус «Оценка» — прогноз и возврат в бэклог
 - Несколько проектов параллельно без пересечений
 
 > Визуал: пять пиктограмм-сценариев

docs/overview/tech-agents.md

@@ -8,7 +8,7 @@
 
 | Роль | Стадия | Вход | Выходные артефакты | Machine-verdict ключ |
 |------|--------|------|--------------------|----------------------|
-| `analyst` | analysis | бизнес-запрос (`00-business-request.md`) | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`; when-applicable сигнальный `01-questions.md` | — (гейт проверяет полноту пакета + одобрение человека) |
+| `analyst` | analysis | бизнес-запрос (`00-business-request.md`) | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | — (гейт проверяет полноту пакета + одобрение человека) |
 | `architect` | architecture | пакет аналитики | `06-adr/ADR-NNN-*.md`, when-applicable `07-infra-requirements.md` / `08-data-requirements.md`, `10-tech-risks.md` | — (гейт проверяет наличие ADR) |
 | `developer` | development | ТЗ + ADR | код в `src/`, тесты в `tests/`, обновлённые доки, `CHANGELOG.md`, PR в Gitea | — (гейт — зелёный CI ветки) |
 | `reviewer` | review | PR diff + ТЗ/ADR | `12-review.md` | `verdict:` (`APPROVED` \| `REQUEST_CHANGES`) |
@@ -18,15 +18,6 @@
 Machine-verdict ключи читаются гейтами **только из YAML-frontmatter** артефакта (никогда из
 прозы) и неизменны байт-в-байт — подробнее в [блоке качества](tech-quality-security.md).
 
-> **Сигнальный канал аналитика → Needs Input (ORCH-120).** Если на стадии `analysis` аналитик
-> упирается в блокирующие открытые вопросы, он не фабрикует обязательные deliverables, а выпускает
-> when-applicable артефакт `01-questions.md` — задача уходит в **Needs Input** и (под флагом
-> `analyst_needs_input_autopause_enabled`, скоуп self-hosting) автоматически встаёт на паузу, чтобы
-> не клинить очередь репозитория, пока ждём ответа человека; ответ возобновляет анализ и снимает
-> паузу. `01-questions.md` — сигнальный артефакт того же владельца/стадии, **не** machine-verdict и
-> **не** один из 4 обязательных deliverables (exit-гейт `check_analysis_complete` его не парсит). Как
-> это вплетено в serial-gate — [конвейер](tech-pipeline.md).
-
 ## Модель и эффорт
 
 Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
@@ -57,20 +48,6 @@ Machine-verdict ключи читаются гейтами **только из Y
 Особенность: промпт `deployer` сознательно на английском (самый safety-critical — несёт
 запреты self-hosting в видной рамке); остальные пять — на русском.
 
-Особенность (ORCH-115): на стадии `deploy-staging` для self-hosting `orchestrator` LLM-`deployer`
-заменён **детерминированным staging-раннером** (`src/staging_runner.py`) — его работа была чисто
-механической (запуск staging-сюиты + маппинг exit-кода). LLM-промпт `deployer` остаётся fallback'ом
-под выключенным флагом / для не-self репо и продолжает вести прод-стадию `deploy`. Подробнее —
-[конвейер](tech-pipeline.md) и [карта LLM-консультаций](../architecture/llm-call-sites.md).
-
-Особенность (ORCH-116): на стадии `testing` для self-hosting `orchestrator` LLM-`tester` заменён
-**детерминированным test-раннером** (`src/test_runner.py`) — его PASS/FAIL-ядро деривируемо (exit-код
-`pytest` в worktree + read-only smoke), вердикт `result:` производит детерминированный код. Это
-гибрид (`needs-hybrid-fallback`): LLM-промпт `tester` остаётся fallback'ом под выключенным флагом / для
-репо без тест-контракта, а будущий off-control-path триаж падений не выносит и не переопределяет
-`result:`. Подробнее — [конвейер](tech-pipeline.md) и
-[карта LLM-консультаций](../architecture/llm-call-sites.md).
-
 ## Человек как седьмая роль
 
 Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы

docs/overview/tech-data-model.md

@@ -19,8 +19,7 @@ Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N─
 
 ### Work-Item / Task — задача конвейера
 Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
-багфикс), рабочая **ветка**, счётчики откатов, отметки отмены и **паузы** (`paused_at` —
-durable-сигнал «пропустить меня в serial gate», не терминальный). Натуральные ключи — ID задачи
+багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
 в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
 **артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
 deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).
@@ -49,7 +48,6 @@ deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOC
 | `tracker_messages` | леджер всех Telegram-карточек задачи (зачистка сирот) |
 | `lessons` | машинный журнал уроков — структурированные отклонения конвейера |
 | `transition_lease` | durable-владение side-effectful переходом стадии: один владелец на задачу, liveness по pid+boot-id (предотвращает двойное применение необратимых эффектов) |
-| `task_estimates` | леджер прогноз↔факт оценки задачи (стоимость/время/токены/story points), ключ `work_item_id` — фундамент калибровки оценок |
 
 Все изменения схемы — аддитивные и идемпотентные (`CREATE TABLE IF NOT EXISTS`, ensure-column
 при старте): обновление платформы не требует ручных миграций.

docs/overview/tech-integrations.md

@@ -8,15 +8,13 @@
 - **Вход конвейера:** перевод задачи в статус «To Analyse» — единственная точка запуска
   пайплайна. Вебхуки Plane (HMAC-подписанные) доставляют изменения задач.
 - **Статусы = индикация, не управление** ([блок 2](tech-pipeline.md)): платформа сама
-  выставляет статусы доски, чтобы человек видел осмысленную картину; саму машину стадий не
-  подменяет ни один статус. Платформа реагирует лишь на **операторские статусы-действия**:
-  запуск, человеческие гейты (Approved/Confirm Deploy), STOP (отмена) и «Оценка» (прогноз
-  задачи с возвратом в Backlog).
+  выставляет статусы доски, чтобы человек видел осмысленную картину; управляют конвейером
+  только машина стадий и три управляющих статуса (запуск, человеческие гейты, STOP).
 - **Лейблы** — декларативные переключатели на задаче: `autoApprove` / `autoDeploy` (снятие
   человеческих гейтов), `Bug` (багфикс-маршрут). Источник истины — Plane API: ошибка чтения
   лейблов трактуется как «лейбла нет» (fail-safe — никогда не «авто» по ошибке).
 - Платформа пишет в задачу комментарии о ходе работ (под ботами ролей) с кликабельными
-  ссылками на ветку/PR; для оценённых задач — прогноз (в поле оценки) и факт по завершении.
+  ссылками на ветку/PR.
 
 ## Gitea — git, PR, CI
 

docs/overview/tech-observability.md

@@ -12,7 +12,6 @@
 - стоимость задачи нарастающим итогом (токены/доллары по каждому запуску агента);
 - честные метрики времени на финише: время агентов / время ожидания человека / общее
   календарное — три независимые цифры, а не одна вводящая в заблуждение сумма;
-- пункт «Оценка» (прогноз стоимости · времени · токенов), если задача оценивалась;
 - кликабельный номер задачи (ведёт в Plane), отметка багфикс-маршрута.
 
 Карточка тихая (без пингов); пингуют только алерты: красный гейт, ожидание решения человека,
@@ -21,13 +20,9 @@
 ## Служебные страницы платформы
 
 - **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
-  serial gate (заморозки, паузы задач, причина ожидания успешника), авто-лейблы, багфикс-трек,
-  coverage, журнал уроков, владение переходами (`transition_lease`), оценки задач (`estimator`),
-  фоновые демоны. Первая
-  точка диагностики «что сейчас происходит». Паузу/возобновление задачи в serial gate включают
-  два источника: **оператор** — явными эндпоинтами `POST /serial-gate/pause|resume`, и **движок** —
-  автоматически, когда аналитик задаёт блокирующие вопросы и задача уходит в Needs Input (авто-park;
-  снимается на возобновлении; под флагом `analyst_needs_input_autopause_enabled`, скоуп self-hosting).
+  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, владение
+  переходами (`transition_lease`), фоновые демоны. Первая точка диагностики «что сейчас
+  происходит».
 - **`GET /metrics`** — машинный контракт для внешнего наблюдателя (версионированная схема):
   health, возраст последних событий, счётчики сбоев.
 - **`GET /health`** — живость процесса.

docs/overview/tech-pipeline.md

@@ -34,27 +34,6 @@ created → analysis → architecture → development → review → testing →
 | `done` | — | — | терминал |
 | `cancelled` | — | — | терминал (сток отмены) |
 
-> **Детерминированный staging-раннер (ORCH-115).** На стадии `deploy-staging` для self-hosting
-> `orchestrator` работу ведёт **детерминированный код** (`src/staging_runner.py`), а не LLM-агент
-> `deployer`: он перехватывается в `launch_job` до запуска агента (как Phase A/B/C прод-деплоя),
-> исполняет ту же staging-сюиту, маппит exit-код в `staging_status:` и инициирует **тот же** гейт
-> `check_staging_status`. Это замена *продюсера* артефакта, а не гейта: контракт `15-staging-log.md`,
-> имя/семантика `check_staging_status`, `STAGE_TRANSITIONS` — не изменились. Под kill-switch
-> `staging_runner_enabled` (скоуп `staging_runner_repos`, пусто → self-hosting only); при выключении
-> на стадии снова работает LLM-`deployer` байт-в-байт. Это первый реализованный срез
-> determinization-roadmap (см. `docs/architecture/llm-determinization-roadmap.md`).
-
-> **Детерминированный test-раннер (ORCH-116).** На стадии `testing` для self-hosting `orchestrator`
-> работу ведёт **детерминированный код** (`src/test_runner.py`), а не LLM-агент `tester`: он
-> перехватывается в `launch_job` до запуска агента (тем же паттерном, что staging-раннер), исполняет
-> регресс `pytest` в worktree ветки + read-only smoke, маппит exit-код в `result:` и инициирует **тот
-> же** гейт `check_tests_passed`. Это замена *продюсера* артефакта, а не гейта: контракт
-> `13-test-report.md`, имя/семантика `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`
-> — не изменились. Под kill-switch `test_runner_enabled` (скоуп `test_runner_repos`, пусто →
-> self-hosting only; репо без тест-контракта → LLM-tester); при выключении снова работает LLM-`tester`
-> байт-в-байт. Это второй реализованный срез determinization-roadmap (гибрид: LLM-фолбэк остаётся на
-> off-control-path триаж, не на вынесение `result:`).
-
 ## Под-гейты деплойного ребра — врезки, не стадии
 
 На переходе `deploy-staging → deploy` исполняются четыре под-гейта в нормативном порядке
@@ -107,18 +86,6 @@ created → analysis → architecture → development → review → testing →
 прода после выкладки замораживает репозиторий (freeze) до ручного разбора — следующие задачи
 ждут.
 
-У FIFO-порядка есть управляемое исключение — **пауза без блокировки**: более раннюю задачу можно
-снять с активной очереди репозитория, не дожидаясь её завершения, и тогда срочный успешник её
-обгоняет. Паузу (durable-сигнал `tasks.paused_at`) ставят два источника. **Оператор** — явно
-(`POST /serial-gate/pause`, снять — `/resume`). **Движок** — автоматически, когда аналитик
-упирается в блокирующие открытые вопросы и задача уходит в **Needs Input** (узкий триггер под
-флагом `analyst_needs_input_autopause_enabled`, скоуп self-hosting); на возобновлении (ответ
-человека) движок снимает паузу симметрично. Авто-park нужен, чтобы задача, ждущая человека часы
-или дни, не клинила FIFO-очередь репозитория в автономном пакетном прогоне. Пауза — отдельная ось:
-она ≠ отмена (задача не терминальна и возвращается в гейт обратной командой) и **не** обходит ни
-freeze, ни объявленные зависимости. Свежесть базы возобновлённой задачи гарантируют те же
-механизмы (отложенный срез ветки + ребейз на слиянии), что и для обычного FIFO.
-
 ## Отмена: STOP → `cancelled`
 
 Перевод задачи в статус **STOP** останавливает агента, снимает job'ы с очереди, удаляет
@@ -126,27 +93,12 @@ freeze, ни объявленные зависимости. Свежесть б
 (идёт слияние/выкладка) — отмена откладывается и применяется после честного завершения шага.
 STOP никогда не трогает `main` и прод-контейнер.
 
-Пользовательская инструкция «как этим пользоваться» — [FAQ по статусу STOP](../operations/FAQ_STOP.md).
-
-## Оценка задачи: статус «Оценка»
-
-Перевод backlog-задачи в статус **«Оценка»** (в т.ч. **массово** — multi-select Plane)
-запускает прогноз её стоимости, времени, токенов и сложности (story points `1/2/3/5/8`) по
-истории похожих завершённых задач — детерминированной эвристикой, **без запуска LLM**. Прогноз
-пишется в поле оценки задачи, публикуется комментарием и пунктом «Оценка» в Telegram-карточке,
-после чего задача **возвращается в Backlog**. Это операторский side-жест: он **не двигает задачу
-по конвейеру** (не ребро `STAGE_TRANSITIONS`), не занимает слот очереди и не выдёргивает
-in-flight работу. Пере-оценка — повторный перевод в «Оценка» (идемпотентно). По завершении самой
-задачи рядом с прогнозом сохраняется **факт** — фундамент калибровки оценок.
-
 ## Статусная модель Plane: индикация ≠ управление
 
 Статусы в Plane — слой **индикации**: они показывают человеку осмысленную картину хода задачи,
-но никогда не управляют конвейером (машина стадий — только `STAGE_TRANSITIONS`). Отдельно стоят
-**операторские статусы-действия**, на которые платформа реагирует: запуск в работу,
-Approved/Confirm Deploy (человеческие гейты), STOP (отмена) и «Оценка» (прогноз с возвратом в
-Backlog, см. выше). Они инициируют действие или снимают ожидание человека, но саму машину стадий
-не подменяют. Полная карта статусов — в [инженерном справочнике](../architecture/README.md).
+но никогда не управляют конвейером (машина стадий — только `STAGE_TRANSITIONS`). Управляющих
+статусов ровно три: запуск в работу, Approved/Confirm Deploy (человеческие гейты) и STOP
+(отмена). Полная карта статусов — в [инженерном справочнике](../architecture/README.md).
 
 ---
 

docs/overview/tech-quality-security.md

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

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

@@ -1,7 +0,0 @@
-# Business Request: Оценка задачи: стоимость, время и сложность (адаптивный выбор моделей)
-
-Work Item ID: ORCH-020
-
-## Description
-
-Оценка задачи: стоимость, время и сложность (для адаптивного выбора моделей)Цель: добавить оркестратору функцию ОЦЕНКИ задачи — прогноз стоимости и времени реализации. Шаг 2: оценка СЛОЖНОСТИ задачи для адаптивного выбора моделей агентов.📊 Шаг 1 — Оценка стоимости и времениПеред запуском (или на этапе аналитики) оркестратор прогнозирует: сколько будет стоить задача (токены × тариф = $) и сколько займёт времени.Данные уже есть: учёт токенов и cost_usd по прошлым задачам (наблюдаемость из PR #20). ET-014 ~35 мин — есть фактура для калибровки.База оценки — история похожих задач (по типу/стадиям/стеку): средние токены/время/стоимость.Где показывать: коммент в Plane / Telegram-уведомление при заведении задачи — Слава видит прогноз до старта.Post-factum: сравнение прогноз vs факт → уточнение модели оценки (петля, связь с ORCH-8 саморазвитие).🧠 Шаг 2 — Оценка сложности → адаптивный выбор моделейКлассификация сложности задачи (trivial / small / medium / complex) на этапе триажа/аналитики.На основе сложности — адаптивно выбирать модель агента: простая задача → дешёвая/быстрая модель; сложная → сильная модель. Прямая связь с ORCH-13 (мультипровайдерность).Оптимизация: не жечь дорогую модель на тривиальной правке (экономия), но не недокормить сложную задачу слабой моделью (качество).Сложность также влияет на выбор трека (связь с ORCH-19 багфикс: trivial → hotfix, complex → полный цикл).🔧 Что проработатьСигналы для оценки сложности: текст постановки, тип (фича/баг), затронутые файлы/стек, исторические аналоги.Кто оценивает: отдельный шаг-оценщик, под-функция аналитика, или эвристика на входе.Модель оценки: эвристика по истории / отдельный LLM-вызов-оценщик / гибрид.Точность vs стоимость самой оценки (оценка не должна стоить дороже экономии).Маппинг сложность → модель (конфигурируемый, связь с ORCH-13 и манифестом проекта ORCH-9).🔗 СвязкиORCH-13 (мультипровайдерность) — оценка сложности кормит адаптивный выбор модели. Тесная пара.ORCH-19 (багфикс-трек) — сложность определяет глубину пайплайна.ORCH-8 (саморазвитие) — петля прогноз vs факт уточняет модель оценки.PR #20 (наблюдаемость, токены/cost_usd) — фактура для калибровки.❓ Открытые вопросы СлавеГде показывать прогноз стоимости/времени — Telegram при заведении, Plane-коммент, оба?Оценка обязательна для каждой задачи или по запросу/для крупных?Адаптивный выбор модели — автоматический по сложности, или с твоим подтверждением для дорогих?Шкала сложности — фиксированная (trivial/small/medium/complex) или числовая (story points)?Создано 2026-06-04. Статус: Backlog, на проработку. Источник: голосовая постановка Славы + раскладка Стрим.

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

@@ -1,238 +0,0 @@
----
-work_item: ORCH-020
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-020 — Оценка задачи (прогноз стоимости/времени/story points), запускаемая статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
-
-> **Revision после REJECT (Plane, 2026-06-17).** Заказчик отклонил предыдущий пакет: «**что я не
-> увидел в БРД — как запускать оценку?** Я хотел бы переводить задачу в статус "Оценка", после чего
-> запускался бы механизм оценки, и после завершения оценки задача бы меняла статус на backlog. На
-> оценку я буду отправлять задачи **массово через Plane**. Также я могу **переоценивать задачи много
-> раз**.» Этот раунд **переписывает модель триггера**: оценка теперь — **операторское действие,
-> запускаемое выделенным Plane-статусом «Оценка»** (а не «автоматически для каждой задачи на
-> `start_pipeline`», как в отклонённой версии). Прочие требования (что прогнозируем, куда пишем,
-> леджер прогноз↔факт, leaf-инварианты) сохранены и согласованы с новым триггером. Полный пакет
-> `01`–`04` supersede’ит прежний по mtime.
-
-## 1. Бизнес-контекст и проблема
-
-Заказчик планирует работу по бэклогу вручную и хочет **до отправки задачи в работу** видеть прогноз:
-сколько задача будет стоить (токены × тариф = $), сколько займёт времени и насколько она сложна
-(размер в story points). Сейчас этих данных до старта нет: оркестратор собирает фактуру
-(`input_tokens`/`output_tokens`/`cache_*`/`cost_usd`/`model`/`effort`, тайминги
-`agent_runs.started_at/finished_at`, `tasks.created_at/updated_at`) **только постфактум** через
-`src/usage.py` (`task_usage_summary`, `agent_cost_totals`, `record_usage`). Контур **прогноза до
-старта** отсутствует.
-
-**Корень REJECT — отсутствовал способ ЗАПУСКА оценки.** Заказчик мыслит оценку как **операторский
-жест в Plane**, а не как невидимый авто-шаг: он сам решает, какие задачи бэклога оценить, **массово**
-переводит их в выделенный статус, получает прогнозы и продолжает планирование. Отклонённая версия
-прятала триггер в `start_pipeline` («оценка обязательна для каждой задачи автоматически») и явно
-называла точку триггера «реализационной деталью» — это и есть то, что заказчик «не увидел» и
-отверг.
-
-Цитаты заказчика (Plane, 2026-06-17):
-- REJECT: «как запускать оценку? Я хотел бы **переводить задачу в статус "Оценка"**, после чего
-  запускался бы механизм оценки, и после завершения оценки задача бы **меняла статус на backlog**. На
-  оценку я буду отправлять задачи **массово через Plane**. Также я могу **переоценивать задачи много
-  раз**.»
-- Раунд Needs Input: «В Plane есть поле оценка, туда и нужно записывать оценку. По факту завершения
-  задачи вписать в смежное поле… для оценки есть два поля.»; «Только Шаг 1, без выбора модели»;
-  «Модели не выбираем и не меняем. Это вне скоупа».
-
-Установленные факты по коду (на которые опирается решение, не изобретать):
-- **Прецедент «статус-триггер уже есть в платформе.** Plane-статусы — слой B (индикация, ORCH-066) и
-  НЕ управляют машиной стадий; но платформа уже имеет **операторские action-статусы**, запускающие
-  side-механизмы: **STOP** (ORCH-090, отмена задачи) и **Confirm Deploy** (ORCH-059, прод-деплой).
-  Оба разбираются в `webhooks/plane.py::handle_issue_updated` через
-  `proj_states.get("<key>")` и оба **намеренно отсутствуют** в `plane_sync._DEFAULT_STATES`
-  (fail-closed: доска без статуса → `None` → ветка не активируется). Статус «Оценка» — **третий
-  представитель этого же семейства**.
-- **Маппинг имени статуса → логический ключ** — `plane_sync._PLANE_NAME_TO_KEY` (`"STOP"→"stop"`,
-  `"Confirm Deploy"→"confirm_deploy"`); `get_project_states` резолвит UUID статуса per-project из
-  Plane API.
-- **Массовость — «бесплатно».** Plane multi-select по N задачам в статус «Оценка» порождает N
-  отдельных `issue.updated`-вебхуков (по одному на issue); каждый обрабатывается независимо. Отдельный
-  «batch-UX» в оркестраторе не требуется — массовость обеспечивает сам Plane.
-- **Фактура для калибровки уже накоплена** (`agent_runs`, агрегаты `task_usage_summary` /
-  `agent_cost_totals`, тайминги). Это сырьё для «истории похожих задач».
-- **Plane-поля существуют.** На issue присутствуют поля `estimate_point` (ОЦЕНКА) и `point` (ФАКТ);
-  estimate-система на проекте (`project.estimate`) на момент анализа **не настроена** — инфра-
-  предусловие (NFR-7).
-- **Выбор модели/эффорта статичен по роли** (`resolve_agent_model`/`resolve_agent_effort`,
-  ORCH-41/74; дефолт `claude-opus-4-8`) и в этой задаче **не трогается** (Шаг 2 вне объёма).
-- **leaf-паттерн платформы** (`serial_gate`/`coverage_gate`/`labels`/`lessons`/`cancel`): never-raise,
-  kill-switch `*_enabled`, `*_repos` CSV (пусто → self-hosting only), read-only блок в `GET /queue`.
-
-## 2. Объём (scope)
-
-### В объёме (Шаг 1 — Оценка, запускаемая статусом)
-- **Триггер «Оценка» (ядро правки).** Перевод issue в выделенный Plane-статус **«Оценка»** запускает
-  механизм оценки этой задачи. Оператор делает это **вручную и массово** (multi-select в Plane).
-- **Жизненный цикл статуса:** `Backlog → (оператор) «Оценка» → [оркестратор: оценка] → (оркестратор)
-  Backlog`. По завершении оценки оркестратор **сам возвращает** issue в статус **`Backlog`**.
-- **Пере-оценка много раз.** Повторный перевод в «Оценка» переоценивает задачу заново (идемпотентно:
-  перезапись `estimate_point` и строки леджера). Применимо при изменении скоупа.
-- **Прогноз четырёх величин:** стоимость ($), время, токены и **сложность в story points** из
-  фиксированной шкалы `{1, 2, 3, 5, 8}`.
-- **Шкала story points (фиксированная, ответ Q-3 = вариант A):** `1` — мелкая docs/label/config;
-  `2` — небольшой фикс; `3` — средняя; `5` — сложная (код + тесты); `8` — эпик / разбивать.
-- **Запись прогноза в Plane-поле `estimate_point`** (это ОЦЕНКА).
-- **Запись факта в Plane-поле `point`** по завершении задачи (фактическая реализованная сложность в
-  story points из фактических токенов/времени/стоимости по той же шкале) — для калибровки.
-- **Отображение прогноза на двух поверхностях** (ответ Q-5 = оба): Plane-коммент + пункт **«Оценка»**
-  в общей Telegram-карточке задачи (`src/notifications.py`) — **время, токены, стоимость**.
-- **Локальный леджер прогноз↔факт** (фундамент петли калибровки, связь с ORCH-8): хранение прогноза,
-  факта и дельты, **ключ — `work_item_id`** (issue может ещё не иметь pipeline-задачи на момент
-  оценки — она на бэклоге).
-
-### Вне объёма
-- **Шаг 2 — адаптивный выбор моделей агентов** (ответы Q-1/Q-2: «Только Шаг 1, без выбора модели»;
-  «Модели не выбираем и не меняем. Это вне скоупа»). Горячий путь `resolve_agent_model`/
-  `resolve_agent_effort`/`_spawn` **не модифицируется**.
-  > **ACTION (поручение заказчика, Plane 16:34):** «заведи отдельную задачу в Plane для адаптивного
-  > выбора модели и укажи зависимость на мультипровайдеров (ORCH-13)». Создание Plane-issue — действие
-  > уровня заказчика/PM и **вне write-объёма аналитика** (Write ограничен `docs/work-items/<id>/*`).
-  > Фиксирую как обязательный follow-up: новый work item «Адаптивный выбор модели агента по сложности»
-  > с зависимостью на **ORCH-13**; оценщик сложности из ORCH-020 — его вход. Оператору: подтвердить
-  > создание или создать вручную.
-- **Автопереключение трека по сложности** (связка с ORCH-19) — позже; здесь сложность лишь
-  вычисляется и публикуется как сигнал.
-- **Авто-ретроспективщик / RICE-приоритизатор** (E2/E3 ORCH-8) — вне объёма; леджер — фундамент.
-- **Автоматическая оценка КАЖДОЙ задачи на `start_pipeline`** — **исключена явно** (модель
-  отклонённой версии). Оценка — операторский on-demand жест через статус «Оценка».
-- **Изменение тарифной/биллинговой модели** — используется существующий `cost_usd` из `usage.py`.
-- **Новый «batch-UX»/массовый эндпоинт как ОСНОВНОЙ путь** — не нужен (массовость даёт Plane
-  multi-select → N вебхуков). Программный `POST /estimate*` допустим лишь как **опциональное**
-  удобство/диагностика, не как основной триггер (см. TRZ §4).
-
-## 3. Заинтересованные стороны
-- **Заказчик / владелец продукта (Слава)** — инициатор оценки (переводит задачи в «Оценка»),
-  потребитель прогноза для планирования бэклога; принимает результат.
-- **Оркестратор (self-hosting)** — носитель функции; общий прод обслуживает и `enduro-trails`.
-- **Будущая петля саморазвития (ORCH-8)** — потребитель леджера прогноз↔факт для калибровки.
-- **ORCH-13 (мультипровайдерность)** — будущий потребитель сигнала сложности (через follow-up Шаг 2).
-
-## 4. Бизнес-требования (BR)
-
-### Триггер и жизненный цикл (ядро ревизии)
-- **BR-T1 — Запуск оценки статусом «Оценка».** Перевод issue в выделенный Plane-статус **«Оценка»**
-  запускает оценку именно этой задачи. Это **единственный обязательный** способ запуска (массовый и
-  ручной), реализуемый по образцу операторских action-статусов STOP (ORCH-090) / Confirm Deploy
-  (ORCH-059).
-- **BR-T2 — Авто-возврат в Backlog.** По завершении оценки (успех или best-effort-пропуск)
-  оркестратор **сам** переводит issue обратно в статус **`Backlog`**. Заказчик видит задачу
-  вернувшейся в бэклог с заполненным `estimate_point`.
-- **BR-T3 — Массовость через Plane.** Массовый перевод N задач в «Оценка» (multi-select Plane)
-  оценивает все N; каждый issue обрабатывается независимо (N вебхуков). Отдельный массовый UX в
-  оркестраторе не требуется.
-- **BR-T4 — Пере-оценка много раз (идемпотентно).** Повторный перевод задачи в «Оценка»
-  переоценивает её заново; прогноз и строка леджера **перезаписываются** (не дублируются). Число
-  пере-оценок не ограничено.
-- **BR-T5 — Fail-closed статус.** На доске без статуса «Оценка» (enduro / частичная конфигурация /
-  Plane недоступен) триггер **не активируется** (ключ резолвится в `None`) — нулевая регрессия;
-  это инфра-предусловие (NFR-7), а не ошибка.
-- **BR-T6 — Не нарушать машину стадий и in-flight работу.** Статус «Оценка» запускает **side-
-  механизм**, а не переход стадии. Если у issue есть **активная** pipeline-задача (queued/running
-  job), триггер — **no-op + лог** (не выдёргивать выполняемую работу в Backlog, не трогать
-  `STAGE_TRANSITIONS`). Авто-возврат в Backlog **не** создаёт цикла: статус `Backlog` ни одной веткой
-  `handle_issue_updated` не обрабатывается (no-op-эхо).
-
-### Содержание оценки (сохранено, согласовано с триггером)
-- **BR-1 — Прогноз.** Для задачи оркестратор производит прогноз четырёх величин: **стоимость ($)**,
-  **время**, **токены** и **сложность в story points** из фиксированной шкалы `{1,2,3,5,8}`.
-- **BR-2 — База оценки — история.** Прогноз строится на истории похожих **завершённых** задач (по
-  типу/стадиям/стеку): средние токены/время/стоимость из уже накопленной фактуры (`agent_runs`,
-  `task_usage_summary`, `agent_cost_totals`, тайминги). При отсутствии истории — разумный bootstrap-
-  дефолт (не блокирует).
-- **BR-3 — Шкала story points фиксированная** с точной семантикой `1/2/3/5/8` (см. §2). Значение `8` —
-  «эпик: разбивать».
-- **BR-4 — On-demand, не блокирующая.** Оценка производится **по запросу** (перевод в «Оценка»), а не
-  для каждой задачи автоматически; строго best-effort — сбой/выключение оценки **никогда** не тормозит
-  конвейер и не меняет маршрут.
-- **BR-5 — Доступность до старта работы.** Поскольку оператор оценивает задачи на **бэклоге** (до
-  `To Analyse`/`start_pipeline`), прогноз доступен **до** перевода задачи в работу — он и нужен для
-  планирования отправки задач.
-- **BR-7 — Запись прогноза в Plane.** Прогноз сложности (story points) записывается в поле issue
-  **`estimate_point`** (= ОЦЕНКА).
-- **BR-8 — Запись факта в Plane.** По завершении задачи (переход в `done`) фактическая реализованная
-  сложность (story points из фактических токенов/времени/стоимости по той же шкале) записывается в
-  смежное поле **`point`** — для калибровки; прогноз `estimate_point` при этом **не перезаписывается**.
-- **BR-9 — Отображение на двух поверхностях.** Прогноз публикуется: (a) **Plane-комментом**;
-  (b) пунктом **«Оценка»** в общей Telegram-карточке задачи — **время, токены, стоимость**.
-- **BR-10 — Леджер прогноз↔факт (калибровка).** Прогноз и факт сохраняются локально вместе с дельтой
-  (ключ `work_item_id`); фундамент петли уточнения модели оценки (связь с ORCH-8). Достаточно
-  фиксировать обе величины и дельту (авто-уточнение модели — позже).
-
-## 5. Нефункциональные требования (NFR)
-- **NFR-1 — Оценка ≠ Quality Gate / ≠ переход стадии.** Модуль — наблюдатель/продюсер.
-  `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи (`verdict:`/`result:`/
-  `deploy_status:`/`staging_status:`/`security_status:`/`coverage_status:`) / схемы **существующих**
-  таблиц — **байт-в-байт не тронуты**. Статус «Оценка» не добавляет ребра в машину стадий; он
-  запускает side-механизм и сам возвращает issue в Backlog.
-- **NFR-2 — leaf-паттерн.** never-raise (любой сбой → warning + безопасный дефолт), kill-switch
-  `*_enabled`, скоуп `*_repos` (CSV; **пусто → self-hosting only**), read-only блок в `GET /queue`.
-- **NFR-3 — self-hosting safety.** Модуль не рестартит/не роняет прод-контейнер, не трогает `main`/
-  force-push, **не вмешивается в горячий путь запуска агентов** (`resolve_agent_model`/
-  `resolve_agent_effort`/`_spawn` не модифицируются). Выключенный флаг / неприменимый репо → нулевая
-  регрессия для `enduro-trails` и `orchestrator`.
-- **NFR-4 — Стоимость оценки ≪ её ценности.** Сама оценка должна быть дешёвой и быстрой относительно
-  выгоды планирования. Выбор механизма (эвристика по истории / отдельный LLM-вызов / гибрид) и баланс
-  «точность vs стоимость» — **архитектурное** решение (`06-adr`); в TRZ — лишь требование-ограничение.
-- **NFR-5 — Толерантность к массовости.** Массовый перевод (десятки задач разом → десятки вебхуков
-  почти одновременно) **не должен** перегружать прод/конвейер: оценка best-effort, изолирована от
-  control-path; механизм сглаживания нагрузки (дешёвая эвристика / очередь / троттлинг) — деталь
-  `06-adr`. Требование: bulk не роняет и не тормозит обслуживание других проектов.
-- **NFR-6 — Запись в Plane через существующие примитивы.** `estimate_point`/`point`/коммент/возврат в
-  Backlog пишутся через `plane_sync` и подчиняются sandbox write-guard (ORCH-117): в боевом рантайме
-  (`uvicorn`) — штатная запись, из тест/worktree-процесса — заблокирована. **Новых секретов/токенов не
-  вводится.**
-- **NFR-7 — Fail-safe и инфра-предусловия Plane.** (a) Статус **«Оценка»** должен существовать на
-  доске проекта (его отсутствие = fail-closed no-op, BR-T5). (b) estimate-система Plane со значениями
-  `1/2/3/5/8` (Fibonacci) для `estimate_point` должна быть настроена; при её отсутствии запись
-  `estimate_point`/`point` **best-effort пропускается** (+ лог) и **не роняет** конвейер. Детали и
-  точные группы статуса — `07-infra-requirements.md` (архитектор).
-- **NFR-8 — Обратная совместимость данных.** Хранение прогноз↔факт — **аддитивная** новая таблица
-  (`CREATE TABLE IF NOT EXISTS`); существующие таблицы/колонки не изменяются.
-
-## 6. Допущения и ограничения
-- Оценка на бэклоге работает по **issue** (описание/тип/лейблы из Plane API + история похожих), а не
-  по локальной pipeline-задаче: на момент оценки `tasks`-строки может **не быть** → леджер и запись
-  ключуются по `work_item_id`, `task_id` — нуллабелен до старта пайплайна.
-- Статус «Оценка» — транзиентный (issue в нём лишь на время оценки, затем Backlog); его Plane-группа
-  (`backlog`/`unstarted`) косметична — деталь онбординга/инфры (ORCH-009 расширяется на 23-й статус).
-- Фактура `usage.py`/`agent_runs` достаточна для расчёта факта при завершении; «фактические story
-  points» выводятся из факта по той же шкале `{1,2,3,5,8}`.
-- Без ORCH-13 «выбор модели» бессмыслен (один дефолт) — Шаг 2 корректно вынесен в follow-up.
-- Точная Plane-семантика `estimate_point` (FK на estimate-point estimate-системы) vs `point`
-  (целочисленный) — деталь реализации/инфры (архитектор + NFR-7).
-
-## 7. Критерии успеха
-Заказчик **массово переводит** задачи бэклога в статус **«Оценка»**; по каждой оркестратор
-производит прогноз (стоимость/время/токены/story points), пишет его в `estimate_point`, публикует в
-Plane-комменте и пункте «Оценка» Telegram-карточки, сохраняет в леджер прогноз↔факт и **возвращает
-issue в Backlog**; пере-оценка повтором перевода идемпотентна; по завершении задачи факт пишется в
-`point`. Всё это — без единого изменения control-path/гейтов, без касания горячего пути запуска
-агентов, без выдёргивания in-flight работы; на доске без статуса «Оценка» / при выключенном флаге —
-нулевая регрессия. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-- **Статус «Оценка» дёргает in-flight задачу** → снимается BR-T6 (no-op при активном job) + авто-
-  возврат только в Backlog, никогда не трогая стадии.
-- **Цикл вебхуков** (возврат в Backlog → новый webhook) → снимается тем, что `Backlog` не
-  обрабатывается ни одной веткой `handle_issue_updated` (no-op-эхо) — анти-loop по построению.
-- **Перегрузка от массового перевода** → снимается NFR-5 (best-effort, дешёвый механизм/сглаживание —
-  `06-adr`).
-- **Запись в боевой Plane** (`estimate_point`/`point`/коммент/состояние) на общей доске → снимается
-  write-guard (ORCH-117) + best-effort/fail-safe (NFR-6/NFR-7).
-- **Неточность прогноза на холодном старте** (мало истории) → bootstrap-дефолт + петля калибровки
-  (BR-10).
-- **Расползание в Шаг 2** (control-path) → жёсткий out-of-scope + NFR-3.
-Детальный разбор — `10-tech-risks.md` (архитектор).

docs/work-items/ORCH-020/01-questions.md

@@ -1,132 +0,0 @@
----
-work_item: ORCH-020
-stage: analysis
-author_agent: analyst
-status: needs-input
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 01 — Открытые вопросы (Open Questions): ORCH-020 — Оценка задачи: стоимость, время и сложность (адаптивный выбор моделей)
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
-
-> **Сигнальный** when-applicable артефакт (ORCH-120, adr-0053). Пишется аналитиком ТОЛЬКО при
-> **блокирующей** неоднозначности, когда выпустить корректные 4 deliverables (`01-brd`/`02-trz`/
-> `03-acceptance-criteria`/`04-test-plan`) нельзя без ответа заказчика. **Не** machine-verdict;
-> гейтом не парсится — сигнал движку (`_handle_analysis_approved_flow`) увести задачу в **Needs
-> Input**. После ответов в Plane аналитик перезапускается (resume), читает свежие комментарии и
-> выпускает полный пакет.
-
-## 1. Контекст
-
-Бизнес-запрос (`00-business-request.md`) ставит **две связанные, но разные по риску** функции и
-**сам перечисляет 4 нерешённых вопроса для Славы** («❓ Открытые вопросы Славе»). Это решения
-уровня владельца продукта, а не аналитические дефолты: они определяют **объём**, **модель данных**
-и — главное — затрагивается ли **прод-control-path выбора модели агента** на self-hosting инстансе,
-который из ОДНОГО процесса с ОБЩЕЙ БД обслуживает и `enduro-trails`.
-
-**Что установлено по фактическому коду (карта src/, на которую опираются вопросы):**
-
-- **Фактура для оценки уже есть, но только post-run.** `src/usage.py` парсит токены/`cost_usd`/
-  модель из вывода Claude CLI ПОСЛЕ финиша агента; `agent_runs` несёт `input_tokens`/`output_tokens`/
-  `cache_*`/`cost_usd`/`model`/`effort`; есть агрегаты `task_usage_summary`/`agent_cost_totals` и
-  тайминги (`agent_runs.started_at/finished_at`, `tasks.created_at/updated_at/brd_review_*`).
-  → **Прогноз ДО старта** как контур сейчас отсутствует — это новый продюсер, не правка гейта.
-- **Выбор модели/эффорта статичен по роли.** `resolve_agent_model`/`resolve_agent_effort`
-  (`src/agents/launcher.py`, ORCH-41/74) резолвят модель из config/project-override и применяют её в
-  `_spawn` (`--model`/`--effort`, launch-стамп ORCH-109). **Хука «варьировать модель по сложности
-  задачи нет».** Любой адаптивный per-task override — это вмешательство в горячий путь запуска
-  агентов на общем проде.
-- **ORCH-13 (мультипровайдерность) ещё не реализован.** Дефолт один — `claude-opus-4-8`; реально
-  различимы лишь **тиры эффорта** (`low/medium/high/xhigh/max`). Без ORCH-13 «выбор модели»
-  фактически вырождается в «выбор эффорта».
-- **`tasks.track` (ORCH-019) уже существует** (`'full'|'bug'`) — связка «сложность → трек»
-  опирается на готовый механизм, отдельной модели данных под трек не требует.
-- **`lessons` (ORCH-098)** — журнал ОТКЛОНЕНИЙ, НЕ леджер «прогноз vs факт»: готовой калибровочной
-  основы под петлю прогноз↔факт (связь с ORCH-8) пока нет.
-- **Leaf-паттерн** (`serial_gate`/`coverage_gate`/`labels`/`lessons`): never-raise, kill-switch
-  `*_enabled`, `*_repos` CSV (**пусто → self-hosting only**), read-only блок в `GET /queue`. Любой
-  новый модуль оценки обязан ему следовать — это ограничение, а не предмет вопроса.
-
-Без ответов ниже корректные BR/TRZ/AC/тест-план выпустить нельзя: для пунктов Q-2/Q-3 существуют
-**взаимоисключающие** варианты спецификации (разные AC, разная модель данных, разный контракт), а
-Q-1 определяет, какие из «Шаг 1 / Шаг 2» вообще входят в этот work item.
-
-## 2. Блокирующие вопросы
-
-> Q-1…Q-4 — жёсткие блокеры. Q-5 — вопрос самого Славы с безопасным дефолтом (включён, чтобы
-> закрыть все его вопросы за один раунд Needs Input и не плодить второй цикл).
-
-- **Q-1 — Объём и очерёдность: ORCH-020 = «Шаг 1 + Шаг 2» сразу, или «Шаг 1 сейчас» + «Шаг 2 после
-  ORCH-13»?**
-  - Вариант A *(рекомендуемый)*: **Шаг 1 (прогноз стоимости/времени) сейчас**; Шаг 2 (адаптивный
-    выбор модели) — отдельным work item ПОСЛЕ ORCH-13, т.к. без мультипровайдерности «выбор модели»
-    сводится к выбору эффорта, а сам по себе оценщик сложности можно поставлять как сигнал.
-  - Вариант B: **оба шага в одном work item** — тогда оценщик сложности обязан выдавать решение,
-    готовое кормить адаптивный выбор уже сейчас (на тирах эффорта, до ORCH-13).
-  - Вариант C: **только Шаг 2** (классификация сложности + маппинг), прогноз стоимости/времени — позже.
-  - Почему блокирует: определяет, выпускаю ли я deliverables на Шаг 2 вообще и какие BR/AC в них
-    попадут. Объём — зона аналитика, угадывать его нельзя.
-
-- **Q-2 — Адаптивный выбор модели: автоматический по сложности, или с твоим подтверждением для
-  «дорогих»/нетривиальных?** *(вопрос Славы №3; самый критичный — self-hosting safety)*
-  - Вариант A *(рекомендуемый)*: **advisory-only** — оценщик лишь предлагает класс/модель (коммент +
-    карточка), фактический `resolve_agent_model` НЕ трогается; смена модели — ручной/конфиг-шаг.
-    Прод-control-path неизменен, риск для `enduro-trails` нулевой.
-  - Вариант B: **авто-override на self-hosting только** — per-task выбор модели/эффорта применяется
-    автоматически, под kill-switch, скоуп `*_repos` пустой = только `orchestrator`, никогда не влияет
-    на чужой репозиторий и на уже запущенные задачи.
-  - Вариант C: **авто для дешёвых тиров, подтверждение для дорогих** (порог по прогнозу $/сложности).
-  - Почему блокирует: A и B/C — это **разные спецификации** (advisory ⇒ AC про коммент/карточку и
-    отсутствие правок горячего пути; auto ⇒ AC про безопасный gated override, скоуп, инвариант «не
-    трогает enduro и in-flight»). Невозможно написать корректные FR/AC, не зная, ввязываемся ли мы в
-    прод-путь запуска агентов на общем проде.
-
-- **Q-3 — Шкала сложности: фиксированные категории (`trivial/small/medium/complex`) или числовая
-  (story points)?** *(вопрос Славы №4)*
-  - Вариант A *(рекомендуемый)*: **фиксированные категории** (как в постановке) — простая модель
-    данных (`tasks.complexity TEXT`, аддитивно по паттерну `tasks.track`), прозрачный маппинг
-    «класс → эффорт/модель/трек».
-  - Вариант B: **числовая** (story points / 1–N) — гибче для калибровки, но требует решить пороги
-    отображения и маппинг диапазон→модель.
-  - Вариант C: **гибрид** (число внутри + ярлык-категория для людей).
-  - Почему блокирует: задаёт контракт выхода оценщика, тип новой колонки и форму маппинга
-    «сложность → модель/трек». Это часть требований (модель данных), не реализационная деталь.
-
-- **Q-4 — Оценка обязательна для КАЖДОЙ задачи, или по запросу / только для крупных?** *(вопрос Славы №2)*
-  - Вариант A *(рекомендуемый)*: **для каждой задачи автоматически** на входе/в аналитике
-    (`start_pipeline`), но строго never-raise/best-effort — сбой оценки никогда не тормозит конвейер.
-  - Вариант B: **по запросу** (эндпоинт/лейбл Plane) и/или только при превышении порога размера.
-  - Вариант C: **только self-hosting `orchestrator`** на первом этапе (обкатка), enduro — позже.
-  - Почему блокирует: определяет точку интеграции (триггер в `start_pipeline` для всех проектов
-    общего прода vs опциональный путь) и формулировку NFR про область раската и обратимость.
-
-- **Q-5 — Где показывать прогноз стоимости/времени: Telegram при заведении, Plane-коммент, оба?**
-  *(вопрос Славы №1; мягкий — есть безопасный дефолт)*
-  - Вариант A *(рекомендуемый дефолт)*: **оба** — Plane-коммент (`plane_sync.add_comment`) +
-    live-карточка/уведомление в Telegram (`notifications.send_telegram`); это безопасный суперсет
-    поверх уже существующих поверхностей.
-  - Вариант B: только Telegram. Вариант C: только Plane-коммент.
-  - Почему (мягко) блокирует: влияет на объём (одна поверхность vs две) и на AC отображения; если
-    промолчишь — зафиксирую дефолт A.
-
-## 3. Что разблокирует анализ
-
-- **Ответы на Q-1…Q-4** (и подтверждение/override Q-5) комментарием в Plane к ORCH-020.
-- Минимально для старта достаточно: **Q-1** (объём), **Q-2** (advisory vs auto — определяет, трогаем
-  ли control-path) и **Q-3** (шкала). Q-4/Q-5 имеют безопасные дефолты (A), которые я приму при
-  молчании.
-- На **resume**: прочту свежие комментарии-ответы и (а) если все блокеры сняты — выпущу **полный**
-  валидный пакет из 4 файлов (он автоматически supersede’ит этот файл по mtime, повторного Needs
-  Input не будет); (б) если часть вопросов осталась — **перепишу** этот файл, оставив только
-  актуальные блокеры (снова Needs Input). Устаревшие вопросы вперемешку с новыми оставлять не буду.
-
-> Подразумеваемые инварианты, которые я зафиксирую в пакете при ЛЮБЫХ ответах (не вопросы — границы):
-> новый функционал следует leaf-паттерну (never-raise, kill-switch, `*_repos` пусто → self-hosting
-> only, блок в `GET /queue`); `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи/схемы
-> существующих таблиц — не трогаются (оценка — наблюдатель/продюсер, **не** Quality Gate); прод-
-> контейнер не рестартится; `main`/force-push не затрагиваются. Выбор механизма оценки (эвристика по
-> истории / LLM-оценщик / гибрид) и «точность vs стоимость самой оценки» — **архитектурное** решение
-> (06-adr), его я не предрешаю; в TRZ зафиксирую лишь требование-ограничение «стоимость оценки ≪
-> ожидаемой экономии».

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

@@ -1,166 +0,0 @@
----
-work_item: ORCH-020
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-020 — Оценка задачи, запускаемая Plane-статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование/решения (выбор механизма оценки эвристика vs LLM vs гибрид, точные
-> сигнатуры врезок, индексы, формулы маппинга, сглаживание массовой нагрузки, Plane-группа статуса
-> «Оценка») — задача архитектора (`06-adr`).
-
-## 1. Сводка изменения
-
-Вводится **новый операторский Plane-статус «Оценка»** — триггер механизма оценки (по образцу
-action-статусов **STOP**/ORCH-090 и **Confirm Deploy**/ORCH-059). Перевод issue в «Оценка»
-(в т.ч. **массово** через Plane multi-select) запускает **новый leaf-модуль оценки**
-(`src/estimator.py`, never-raise), который прогнозирует **стоимость / время / токены / сложность
-(story points `{1,2,3,5,8}`)** на основе истории завершённых задач (агрегаты `src/usage.py`).
-Прогноз: (a) пишется в Plane-поле `estimate_point`, (b) публикуется Plane-комментом, (c) добавляется
-пунктом «Оценка» (время/токены/стоимость) в общую Telegram-карточку, (d) сохраняется в **новой
-аддитивной таблице** `task_estimates` (леджер прогноз↔факт, ключ `work_item_id`). По завершении
-оценки оркестратор **возвращает issue в статус `Backlog`**. По завершении самой задачи (переход в
-`done`) **факт** пишется в Plane-поле `point`. Пере-оценка — повтор перевода в «Оценка»
-(идемпотентно).
-
-**Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не** Quality Gate и **не** переход
-стадии. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схемы существующих
-таблиц — байт-в-байт; горячий путь `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — не
-трогается. Статус «Оценка» не добавляет ребра в машину стадий.
-
-## 2. Задействованные модули / пути
-| Путь | Действие |
-|------|----------|
-| `src/plane_sync.py` | **изменить** — (1) `_PLANE_NAME_TO_KEY += {"Оценка": "estimate"}`; ключ `estimate` **НЕ добавлять** в `_DEFAULT_STATES` (fail-closed, как `stop`/`confirm_deploy`); (2) новые write-хелперы `set_issue_estimate_point(work_item, value)`, `set_issue_point(work_item, value)`, `set_issue_backlog(work_item)` (все через guard `_guard_allows_write`, ORCH-117); (3) read-хелпер текущих полей `estimate_point`/`point`. fail-safe при отсутствии estimate-конфига |
-| `src/webhooks/plane.py` | **изменить** — в `handle_issue_updated` добавить **fail-closed ветку** `estimate_state = proj_states.get("estimate")` → `handle_estimate(data, project_id)` (распознаётся как **отдельный** жест, не алиасит stop/to_analyse/confirm_deploy/approved/rejected). Новый `handle_estimate`: резолв issue (pipeline-задачи может не быть), guard `estimator.applies(repo)`, guard «нет активного job» (BR-T6), запуск оценки, затем `set_issue_backlog` |
-| `src/estimator.py` | **создать** — leaf: `estimate(work_item_id, issue|description, repo)` → прогноз `{tokens,seconds,cost_usd,story_points}`; маппинг величин → story-point bucket `{1,2,3,5,8}` (чистая функция); расчёт факта из `usage.py`; `applies(repo)`, `should_estimate(task|None)` (анти-disruption), `snapshot()`; never-raise |
-| `src/db.py` | **изменить** — аддитивная таблица `task_estimates` (`CREATE TABLE IF NOT EXISTS` в `init_db()`) + хелперы `record_estimate`/`set_actual`/`get_estimate`/`estimates_snapshot`; существующие таблицы/колонки не трогать |
-| `src/usage.py` | **переиспользовать** (read-only) — `task_usage_summary`/`agent_cost_totals`/тайминги для **факта**; при необходимости тонкий read-only агрегат «история похожих задач» |
-| `src/notifications.py` | **изменить** — пункт «Оценка» (время · токены · стоимость) в рендере общей карточки; never-raise, пустой прогноз → пункт опускается |
-| `src/main.py` | **изменить** — (опц.) `POST /estimate?work_item=<id>` / `POST /estimate/backlog` как программное удобство; **read-only блок `estimator` в `GET /queue`** |
-| `src/config.py` | **изменить** — флаги (см. §7) |
-| `tests/test_orch020_estimator.py` | **создать** — покрытие (см. `04-test-plan.yaml`) |
-
-## 3. Функциональные требования
-
-### FR-T1 — Статус «Оценка» как триггер (BR-T1, BR-T5)
-`_PLANE_NAME_TO_KEY["Оценка"] = "estimate"`; ключ `estimate` **отсутствует** в `_DEFAULT_STATES`.
-В `handle_issue_updated` — отдельная ветка: `estimate_state = proj_states.get("estimate")`;
-`if estimate_state and new_state == estimate_state: await handle_estimate(...)`. Доска без статуса →
-`estimate_state is None` → ветка инертна (fail-closed, зеркало `stop`/`confirm_deploy`). Ветка не
-должна аннулировать/перехватывать STOP/`to_analyse`/`confirm_deploy`/approved/rejected (UUID
-«Оценка» отличен от всех; порядок ветки выбирает архитектор, инвариант — взаимоисключение жестов).
-
-### FR-T2 — Обработчик `handle_estimate` (BR-T1, BR-T6)
-`handle_estimate(data, project_id)`: резолвит `plane_id`/`work_item_id`; `repo` определяется по
-проекту. Guard-цепочка (все — no-op-with-log при невыполнении, never-raise):
-1. `estimator.applies(repo)` — kill-switch + скоуп (False → no-op);
-2. **анти-disruption (BR-T6):** если у issue есть pipeline-задача с **активным** job
-   (`has_active_job_for_task`) → no-op + лог (не выдёргивать in-flight работу). Issue без задачи
-   (бэклог) или с терминальной/idle-задачей → оценка допустима.
-Далее: `estimator.estimate(...)` → запись прогноза (FR-T3) → **`set_issue_backlog(work_item)`**
-(BR-T2). Контракт never-raise: любая ошибка логируется, вебхук-флоу не падает.
-
-### FR-T3 — Прогноз задачи (BR-1, BR-2, BR-3)
-`estimator.estimate(work_item_id, description|issue, repo)` возвращает `{forecast_tokens,
-forecast_seconds, forecast_cost_usd, story_points}`, `story_points ∈ {1,2,3,5,8}`. База — история
-похожих **завершённых** задач (средние токены/время/стоимость из `usage.py`-агрегатов); пустая
-история → bootstrap-дефолт. Маппинг величин → bucket — чистая функция (пороги — `06-adr`).
-never-raise: сбой → безопасный дефолт + warning.
-
-### FR-T4 — Семантика story points (BR-3)
-Шкала фиксированная: `1` docs/label/config · `2` небольшой фикс · `3` средняя · `5` сложная
-(код+тесты) · `8` эпик/разбивать. Значения вне набора не выдаются.
-
-### FR-T5 — Авто-возврат в Backlog + анти-loop (BR-T2, BR-T6)
-После оценки `handle_estimate` зовёт `set_issue_backlog(work_item)` → issue возвращается в `Backlog`.
-Это **не** создаёт цикла: `Backlog`-UUID не совпадает ни с одной триггер-веткой `handle_issue_updated`
-(`stop`/`to_analyse`/`confirm_deploy`/`approved`/`rejected`/`estimate`) → входящий webhook «state →
-Backlog» = no-op-эхо. Возврат best-effort: сбой записи статуса не роняет флоу (прогноз уже записан).
-
-### FR-T6 — Массовость и пере-оценка (BR-T3, BR-T4)
-Массовый перевод N задач в «Оценка» = N независимых `issue.updated`-вебхуков → N вызовов
-`handle_estimate` (никакого спец-batch-кода). Пере-оценка = повторный перевод: `estimate`
-идемпотентно **перезаписывает** прогноз в `task_estimates` (UPSERT по `work_item_id`) и
-`estimate_point`; дублей строк нет.
-
-### FR-T7 — Запись прогноза и факта в Plane (BR-7, BR-8, NFR-6, NFR-7)
-- Прогноз story points → `set_issue_estimate_point` → поле issue `estimate_point`.
-- По завершении задачи (переход в `done`, врезка в существующий done-путь): из `usage.py` считается
-  факт (токены/время/стоимость) → маппится в story-point bucket → `set_issue_point` → поле `point`;
-  `estimate_point` не перезаписывается.
-- Все записи через `plane_sync` под guard ORCH-117; отсутствие estimate-конфига/поля → best-effort
-  пропуск + лог (не падать).
-
-### FR-T8 — Отображение (BR-9)
-- **Plane-коммент** с прогнозом (стоимость/время/токены/story points) — `plane_sync.add_comment`.
-- **Telegram-карточка** — пункт **«Оценка»**: время · токены · стоимость (`notifications`).
-Обе поверхности — best-effort, не блокируют конвейер.
-
-### FR-T9 — Леджер прогноз↔факт (BR-10)
-`task_estimates` хранит прогноз (на момент оценки) и факт (на момент `done`) + дельту, ключ
-`work_item_id` (т.к. на момент оценки `task_id` может быть `NULL` — issue на бэклоге). Фундамент
-калибровки (ORCH-8); авто-уточнение модели в объём не входит.
-
-### FR-T10 — leaf-инварианты (NFR-2, NFR-3)
-`applies(repo)` = `estimator_enabled` ∧ скоуп `estimator_repos` (пусто → self-hosting only),
-проверяется локально и ПЕРВЫМ (без сети). Выключено → весь модуль инертен (нулевая регрессия:
-статус «Оценка» не обрабатывается, ничего не пишется). read-only блок `estimator` в `GET /queue`
-(флаг/скоуп/счётчики прогнозов/записей/возвратов-в-Backlog).
-
-## 4. Изменения API
-| Метод/путь | Назначение |
-|------------|-----------|
-| **Plane-статус «Оценка»** (не HTTP-эндпоинт) | **Основной триггер**: перевод issue в статус → `handle_estimate`. Массовость — multi-select Plane. |
-| `POST /estimate?work_item=<id>` *(опц.)* | Программно произвести/обновить прогноз одной задачи (то же ядро, что статус-триггер) — удобство/диагностика, не основной путь |
-| `POST /estimate/backlog` *(опц.)* | Программно оценить backlog-задачи проекта — удобство; основной массовый путь — статус «Оценка» |
-| `GET /estimate?work_item=<id>` *(опц.)* | Прочитать текущий прогноз vs факт из `task_estimates` |
-| `GET /queue` | **+ read-only блок `estimator`**; existing-поля не меняются |
-
-Существующие эндпоинты/контракты не изменяются. Webhook-контракт `issue.updated` не меняется —
-добавляется лишь распознавание ещё одного целевого статуса.
-
-## 5. Изменения схемы БД
-**Новая аддитивная таблица** `task_estimates` (`CREATE TABLE IF NOT EXISTS`, без правки существующих):
-`work_item_id` (ключ/UPSERT-цель) · `task_id` (нуллабелен до старта пайплайна) · `repo` · прогноз
-(`forecast_tokens`, `forecast_seconds`, `forecast_cost_usd`, `forecast_story_points`) · факт
-(`actual_tokens`, `actual_seconds`, `actual_cost_usd`, `actual_story_points`) · дельта (`delta_*`
-или вычисляемая) · `source` (`status`/`manual`/`api`) · `estimate_count` (число пере-оценок,
-опц.) · `created_at` · `updated_at`. Точные типы/индексы/уникальность (UNIQUE по `work_item_id`
-для идемпотентного UPSERT) — `06-adr`. Существующие таблицы (`tasks`/`agent_runs`/`jobs`/…) — **не
-изменяются** (NFR-8).
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Оценка — наблюдатель/продюсер, не Quality Gate; статус «Оценка» — операторский side-триггер,
-не ребро `STAGE_TRANSITIONS`. `QG_CHECKS` / `check_*` / machine-verdict-ключи / `STAGE_TRANSITIONS` —
-**не трогаются**. Новых номерных артефактов pipeline (`NN-*.md`) и новых вердикт-парсеров нет (оценка
-публикуется в Plane/Telegram/`task_estimates`, не во frontmatter-гейтах).
-
-## 7. Совместимость / регресс
-- **Флаги** (`config.py`, дефолты безопасные): `estimator_enabled` (kill-switch, env
-  `ORCH_ESTIMATOR_ENABLED`), `estimator_repos` (CSV, env `ORCH_ESTIMATOR_REPOS`; **пусто →
-  self-hosting only**). Доп. тюнинг (bootstrap-дефолты, пороги bucket, целевой возврат-статус,
-  сглаживание массовой нагрузки) — конфиг-ключи на усмотрение `06-adr`.
-- **Откат** = `ORCH_ESTIMATOR_ENABLED=false` → модуль инертен: статус «Оценка» не обрабатывается
-  (`applies`=False до сети), ни записи в Plane, ни строки карточки, ни обращений к таблице; конвейер
-  байт-в-байт до ORCH-020. Доп. откат «на уровне доски» — не создавать статус «Оценка» (fail-closed,
-  BR-T5).
-- **Область раската:** по умолчанию self-hosting `orchestrator`; `enduro-trails` не затронут (скоуп
-  `estimator_repos` пуст + на его доске статуса «Оценка» нет → fail-closed).
-- **never-raise / fail-safe:** все публичные функции и врезки изолированы (`try/except` → warning +
-  безопасный дефолт). Сбой оценки/записи в Plane/возврата статуса/рендера карточки — не роняет
-  конвейер (NFR-2/6/7).
-- **Анти-disruption / анти-loop:** активный job → no-op (BR-T6); возврат в Backlog — no-op-эхо
-  (FR-T5). Машина стадий и in-flight задачи не затрагиваются.
-- **Горячий путь не тронут:** `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — без изменений
-  (NFR-3).
-- **Инфра-предусловия (NFR-7):** (a) статус **«Оценка»** на доске проекта (онбординг ORCH-009 →
-  23-й статус; группа — `06-adr`/`07-infra-requirements.md`); (b) estimate-система Plane
-  (`1/2/3/5/8`) для `estimate_point`; их отсутствие → fail-closed/best-effort пропуск, не падение.

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

@@ -1,221 +0,0 @@
----
-work_item: ORCH-020
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-020 — Оценка задачи, запускаемая статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
-считается провалом). Reviewer/тестер проверяет их буквально по файлам репозитория и поведению.
-
----
-
-## AC-T1 — Запуск оценки статусом «Оценка» (ядро ревизии)
-
-**Условие:** перевод issue в Plane-статус «Оценка» запускает оценку этой задачи.
-- **PASS:** `_PLANE_NAME_TO_KEY` содержит `"Оценка" → "estimate"`; `handle_issue_updated` имеет
-  отдельную ветку `proj_states.get("estimate")` → `handle_estimate(...)`; при переводе issue в
-  «Оценка» вызывается оценка (прогноз вычислен и записан).
-- **FAIL:** триггера-статуса нет; оценка по-прежнему авто-запускается на каждой задаче в
-  `start_pipeline`; ветка «Оценка» аннулирует/перехватывает STOP/`to_analyse`/`confirm_deploy`/
-  approved/rejected.
-
----
-
-## AC-T2 — Авто-возврат в Backlog
-
-**Условие:** по завершении оценки issue возвращается в статус `Backlog`.
-- **PASS:** после записи прогноза `handle_estimate` вызывает `set_issue_backlog(work_item)` и issue
-  оказывается в `Backlog`; возврат best-effort (сбой записи статуса не роняет флоу, прогноз уже
-  записан).
-- **FAIL:** issue остаётся в «Оценка»/ином статусе; возврат отсутствует; сбой возврата роняет вебхук.
-
----
-
-## AC-T3 — Массовость через Plane
-
-**Условие:** массовый перевод задач в «Оценка» оценивает их все.
-- **PASS:** N задач, переведённых в «Оценка» (multi-select Plane → N `issue.updated`-вебхуков),
-  дают N независимых вызовов `handle_estimate`; каждая получает прогноз; спец-batch-кода для этого не
-  требуется.
-- **FAIL:** часть задач не оценивается; обработка зависит от несуществующего «batch-режима»; один
-  webhook гасит остальные.
-
----
-
-## AC-T4 — Пере-оценка много раз (идемпотентно)
-
-**Условие:** повторный перевод в «Оценка» переоценивает задачу без дублей.
-- **PASS:** повтор обновляет прогноз в `task_estimates` (UPSERT по `work_item_id`) и `estimate_point`;
-  строка одна, не дублируется; число пере-оценок не ограничено.
-- **FAIL:** повтор создаёт дубль строки в `task_estimates`; повтор игнорируется/падает.
-
----
-
-## AC-T5 — Fail-closed статус «Оценка»
-
-**Условие:** на доске без статуса «Оценка» триггер не активируется.
-- **PASS:** `estimate` отсутствует в `_DEFAULT_STATES`; на проекте без статуса
-  `proj_states.get("estimate") is None` → ветка инертна (нет KeyError, нет оценки); enduro-trails не
-  затронут.
-- **FAIL:** `estimate` добавлен в `_DEFAULT_STATES`; отсутствие статуса даёт KeyError/ошибку; чужой
-  репо триггерится.
-
----
-
-## AC-T6 — Анти-disruption in-flight + анти-loop
-
-**Условие:** статус «Оценка» — side-механизм, не трогает выполняемую работу и не зацикливается.
-- **PASS:** issue с активным (queued/running) job → `handle_estimate` = no-op + лог (in-flight работа
-  не выдёргивается в Backlog, стадии не трогаются); возврат в `Backlog` — no-op-эхо (`Backlog`-UUID не
-  совпадает ни с одной триггер-веткой → входящий webhook ничего не запускает).
-- **FAIL:** активную задачу выдёргивает в Backlog/прерывает; возврат в Backlog порождает повторный
-  запуск оценки (цикл); меняется `STAGE_TRANSITIONS`.
-
----
-
-## AC-1 — Прогноз четырёх величин
-
-**Условие:** `estimator.estimate(...)` возвращает прогноз стоимости, времени, токенов и сложности.
-- **PASS:** структура с `forecast_cost_usd`, `forecast_seconds`, `forecast_tokens` и `story_points`,
-  `story_points ∈ {1,2,3,5,8}`; пустая история → bootstrap-дефолт (не исключение).
-- **FAIL:** отсутствует любая из четырёх величин; `story_points` вне `{1,2,3,5,8}`; функция бросает
-  исключение при отсутствии истории.
-
----
-
-## AC-2 — Фиксированная семантика story points
-
-**Условие:** маппинг величин → story-point bucket соответствует шкале заказчика.
-- **PASS:** значения и смысл строго `1` (docs/label/config) · `2` (небольшой фикс) · `3` (средняя) ·
-  `5` (сложная код+тесты) · `8` (эпик/разбивать); чистая функция маппинга покрыта unit-тестом.
-- **FAIL:** иные значения/градации (`4`, `7`, свободное число) или произвольная числовая шкала.
-
----
-
-## AC-3 — Запись прогноза в Plane `estimate_point`
-
-**Условие:** прогноз story points записывается в поле issue `estimate_point`.
-- **PASS:** при оценке вызывается `set_issue_estimate_point` (через `plane_sync`/guard ORCH-117); при
-  настроенной estimate-системе значение оказывается в `estimate_point`.
-- **FAIL:** прогноз пишется в `point` (перепутаны поля), не пишется, либо запись обходит guard.
-
----
-
-## AC-4 — Запись факта в Plane `point` по завершении
-
-**Условие:** по завершении задачи (переход в `done`) факт пишется в смежное поле `point`.
-- **PASS:** на `done` факт вычисляется из `usage.py` (токены/время/стоимость), маппится в story-point
-  bucket и пишется в `point`; `estimate_point` не перезаписывается.
-- **FAIL:** факт пишется в `estimate_point`, не пишется, либо затирает прогноз.
-
----
-
-## AC-5 — Пункт «Оценка» в Telegram-карточке
-
-**Условие:** общая карточка задачи показывает прогноз.
-- **PASS:** в карточке присутствует пункт **«Оценка»** с **временем, токенами и стоимостью**; пустой
-  прогноз → пункт опускается (never-raise); инвариант «одна карточка на задачу» не нарушен.
-- **FAIL:** пункт отсутствует; его рендер роняет/ломает карточку; нарушен инвариант одной карточки.
-
----
-
-## AC-6 — Plane-коммент с прогнозом
-
-**Условие:** прогноз публикуется комментом в Plane.
-- **PASS:** постится коммент со стоимостью/временем/токенами/story points (best-effort, через
-  `add_comment`).
-- **FAIL:** коммент не постится при включённом флаге на применимом репо без причины в логе.
-
----
-
-## AC-7 — Программные эндпоинты (опциональны, не основной триггер)
-
-**Условие:** программный путь, если реализован, использует то же ядро.
-- **PASS:** `POST /estimate?work_item=<id>` / `POST /estimate/backlog` (если есть) дают тот же
-  результат, что статус-триггер (UPSERT в `task_estimates` + `estimate_point` + коммент + карточка),
-  идемпотентны; их отсутствие не нарушает приёмку (основной путь — статус «Оценка»).
-- **FAIL:** эндпоинт расходится с поведением статус-триггера; преподносится как ЕДИНСТВЕННЫЙ способ
-  запуска (триггер-статуса нет).
-
----
-
-## AC-8 — On-demand + доступность до старта, best-effort
-
-**Условие:** оценка запускается по требованию (статус), доступна до старта работы и никогда не
-блокирует конвейер.
-- **PASS:** оценка идёт по переводу в «Оценка» на бэклоге (до `To Analyse`/`start_pipeline`); при
-  сбое оценки конвейер не затрагивается (best-effort, лог-warning); НЕ авто-обязательна на каждой
-  задаче.
-- **FAIL:** оценка — блокирующий шаг (сбой тормозит/меняет маршрут); оценка авто-навязана каждой
-  задаче на `start_pipeline`.
-
----
-
-## AC-9 — leaf-инварианты (kill-switch / скоуп / GET /queue)
-
-**Условие:** модуль следует leaf-паттерну.
-- **PASS:** `estimator_enabled=false` → модуль полностью инертен (статус «Оценка» не обрабатывается,
-  нет записей в Plane/карточку/таблицу); `estimator_repos` пуст → активен только на self-hosting
-  `orchestrator`; есть read-only блок `estimator` в `GET /queue`; все публичные функции never-raise.
-- **FAIL:** при выключенном флаге что-то пишется/меняется; enduro-trails затронут при пустом скоупе;
-  нет блока в `GET /queue`; функция бросает наружу.
-
----
-
-## AC-10 — Control-path и гейты не тронуты (NFR-1/NFR-3)
-
-**Условие:** оценка ничего не меняет в машине стадий и горячем пути.
-- **PASS:** `git diff` не затрагивает `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict-
-  ключи и схемы существующих таблиц; `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — без
-  изменений; статус «Оценка» не добавлен как ребро стадий; зелёный анти-регресс существующих тестов.
-- **FAIL:** любое из перечисленного изменено; маршрут задачи зависит от результата оценки.
-
----
-
-## AC-11 — Шаг 2 (выбор модели) вне объёма
-
-**Условие:** адаптивный выбор модели не реализуется.
-- **PASS:** нет кода, выбирающего/меняющего модель/эффорт по сложности; в `01-brd.md` зафиксирован
-  out-of-scope + follow-up на отдельный work item с зависимостью на ORCH-13.
-- **FAIL:** добавлена логика per-task override модели/эффорта; follow-up не зафиксирован.
-
----
-
-## AC-12 — Леджер прогноз↔факт + fail-safe записи
-
-**Условие:** прогноз и факт сохраняются; запись в Plane fail-safe.
-- **PASS:** `task_estimates` (новая аддитивная таблица, ключ `work_item_id`, `task_id` нуллабелен)
-  хранит прогноз, факт и дельту; при ненастроенной estimate-системе Plane запись `estimate_point`/
-  `point` best-effort пропускается с логом, конвейер не падает.
-- **FAIL:** существующая схема БД изменена; отсутствие estimate-конфига роняет оценку/конвейер.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-T1 | BR-T1, BR-T5 / FR-T1 |
-| AC-T2 | BR-T2 / FR-T5 |
-| AC-T3 | BR-T3 / FR-T6 |
-| AC-T4 | BR-T4 / FR-T6 |
-| AC-T5 | BR-T5 / FR-T1 |
-| AC-T6 | BR-T6 / FR-T2, FR-T5 |
-| AC-1 | BR-1, BR-2 / FR-T3 |
-| AC-2 | BR-3 / FR-T4 |
-| AC-3 | BR-7 / FR-T7 |
-| AC-4 | BR-8 / FR-T7 |
-| AC-5 | BR-9 / FR-T8 |
-| AC-6 | BR-9 / FR-T8 |
-| AC-7 | §2 «Вне объёма» / FR-T6, TRZ §4 |
-| AC-8 | BR-4, BR-5 / FR-T2 |
-| AC-9 | NFR-2 / FR-T10 |
-| AC-10 | NFR-1, NFR-3 |
-| AC-11 | §2 «Вне объёма» (Q-1/Q-2) |
-| AC-12 | BR-10, NFR-7, NFR-8 / FR-T7, FR-T9 |

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

@@ -1,149 +0,0 @@
-work_item: ORCH-020
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-title: "Оценка задачи, запускаемая Plane-статусом «Оценка»: триггер/возврат в Backlog/массовость/пере-оценка + прогноз {токены,время,стоимость,story points}, запись в Plane, карточка, леджер прогноз↔факт, leaf-инварианты"
-framework: pytest
-scope: >
-  Покрывается: распознавание статуса «Оценка» как триггера (handle_estimate),
-  fail-closed при отсутствии статуса, авто-возврат issue в Backlog + анти-loop,
-  анти-disruption in-flight (no-op при активном job), массовость (N вебхуков -> N оценок),
-  идемпотентная пере-оценка (UPSERT по work_item_id), расчёт прогноза из истории (usage-агрегаты),
-  маппинг величин -> story-point bucket {1,2,3,5,8} (чистая функция), never-raise/bootstrap при
-  пустой истории, запись прогноза в estimate_point и факта в point (через guard ORCH-117, fail-safe
-  при отсутствии estimate-конфига), пункт "Оценка" в Telegram-карточке, read-only блок estimator в
-  GET /queue, аддитивная таблица task_estimates (ключ work_item_id, task_id нуллабелен),
-  kill-switch + скоуп (пусто -> self-hosting only).
-  Вне покрытия: адаптивный выбор модели (Шаг 2, вне объёма), авто-уточнение модели оценки (ORCH-8),
-  автопереключение трека по сложности (ORCH-19).
-notes: >
-  Тесты используют изолированную временную SQLite-БД (фикстура init_db во временном файле) и
-  замоканные plane_sync/notifications/usage/get_project_states — без сети, без боевого Plane/Telegram,
-  без LLM. Триггер тестируется на уровне handle_issue_updated/handle_estimate с подставленными
-  proj_states (UUID статуса "Оценка"). Запись в Plane проверяется на уровне вызова write-хелперов под
-  guard (ORCH-117 autouse-floor conftest держит opt-in OFF — сетевая запись физически невозможна из
-  теста). Control-path анти-регресс: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/схемы
-  существующих таблиц не меняются; полный регресс tests/ остаётся зелёным.
-
-tests:
-  - id: TC-01
-    type: integration
-    description: "Триггер: new_state == proj_states['estimate'] -> handle_estimate вызывается; estimate-статус добавлен в _PLANE_NAME_TO_KEY как 'Оценка'->'estimate' (AC-T1)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-02
-    type: integration
-    description: "Fail-closed: 'estimate' отсутствует в _DEFAULT_STATES; на проекте без статуса proj_states.get('estimate') is None -> ветка инертна, handle_estimate не зовётся, нет KeyError (AC-T5)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-03
-    type: integration
-    description: "handle_estimate на backlog-issue (нет pipeline-задачи): прогноз вычислен, записан, затем set_issue_backlog -> issue возвращён в Backlog (AC-T1, AC-T2)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-04
-    type: integration
-    description: "Анти-disruption: issue с активным job (has_active_job_for_task=True) -> handle_estimate no-op + лог, оценка не запускается, статус не меняется (AC-T6)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-05
-    type: integration
-    description: "Анти-loop: возврат в Backlog не алиасит триггер-ветки (Backlog-UUID != estimate/stop/to_analyse/confirm_deploy/approved/rejected) -> входящий 'state->Backlog' webhook = no-op-эхо (AC-T6)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-06
-    type: integration
-    description: "Массовость: N issue.updated со state='Оценка' -> N независимых вызовов handle_estimate, каждый даёт прогноз; один webhook не гасит остальные (AC-T3)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-07
-    type: integration
-    description: "Идемпотентная пере-оценка: повторный перевод в 'Оценка' -> UPSERT по work_item_id обновляет одну строку task_estimates и estimate_point, не дублирует (AC-T4)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "estimate() возвращает {forecast_tokens,forecast_seconds,forecast_cost_usd,story_points}, story_points в {1,2,3,5,8} (AC-1)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "Маппинг величин -> story-point bucket: точная семантика 1/2/3/5/8 на граничных входах (AC-2)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "Пустая история -> bootstrap-дефолт, не исключение; estimate() never-raise при битых данных (AC-1, AC-9)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Расчёт факта на done из usage-агрегатов (токены/время/стоимость) маппится в story-point bucket (AC-4)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: "Прогноз пишется в estimate_point через set_issue_estimate_point; факт — в point через set_issue_point; поля не перепутаны, прогноз не затирается (AC-3, AC-4)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-13
-    type: integration
-    description: "Telegram-карточка содержит пункт 'Оценка' (время/токены/стоимость); пустой прогноз -> пункт опускается, карточка не падает (AC-5)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-14
-    type: integration
-    description: "Plane-коммент с прогнозом постится через add_comment (best-effort) (AC-6)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-15
-    type: unit
-    description: "kill-switch estimator_enabled=false -> модуль инертен (handle_estimate no-op, нет записей в Plane/карточку/таблицу); applies() локален и first (AC-9)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-16
-    type: unit
-    description: "Скоуп estimator_repos пуст -> активен только self-hosting orchestrator; enduro-trails -> no-op (AC-9)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-17
-    type: integration
-    description: "GET /queue содержит read-only блок estimator (флаг/скоуп/счётчики прогнозов/записей/возвратов); existing-поля не меняются (AC-9)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-18
-    type: unit
-    description: "Аддитивная таблица task_estimates: CREATE TABLE IF NOT EXISTS идемпотентна; record_estimate/set_actual/get_estimate хранят прогноз+факт+дельту с ключом work_item_id (task_id нуллабелен); существующие таблицы не изменены (AC-12)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-19
-    type: integration
-    description: "fail-safe записи в Plane: estimate-система не настроена -> set_issue_estimate_point/point best-effort пропуск + лог, без падения; авто-возврат в Backlog всё равно отрабатывает (AC-12, AC-T2, NFR-7)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS
-
-  - id: TC-20
-    type: unit
-    description: "Анти-регресс control-path: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict-ключи, resolve_agent_model/resolve_agent_effort не изменены; статус 'Оценка' не добавлен как ребро стадий (AC-10, AC-11)"
-    module: tests/test_orch020_estimator.py
-    expected: PASS

docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md

@@ -1,262 +0,0 @@
----
-work_item: ORCH-020
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# ADR-001: Оценка задачи как side-механизм, запускаемый операторским Plane-статусом «Оценка», с детерминированной эвристикой по истории
-
-Work Item: **ORCH-020** — Оценка задачи (прогноз стоимости/времени/токенов/story points), запускаемая статусом «Оценка»
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`** (решение кросс-каттинговое: новый член семейства операторских action-статусов + новая аддитивная таблица + новый primitive записи в Plane + новый leaf).
-
-## Статус
-Proposed
-
-## Контекст
-
-BRD/TRZ (`01-brd.md`/`02-trz.md`, ревизия после REJECT 2026-06-17) требуют: оператор **массово**
-переводит backlog-задачи в выделенный Plane-статус **«Оценка»**, по каждой оркестратор прогнозирует
-**стоимость / время / токены / сложность (story points `{1,2,3,5,8}`)**, пишет прогноз в Plane-поле
-`estimate_point`, публикует в Plane-комменте и пункте «Оценка» Telegram-карточки, сохраняет в леджер
-прогноз↔факт и **возвращает issue в Backlog**; пере-оценка повтором идемпотентна; по завершении задачи
-факт пишется в `point`. Шаг 2 (адаптивный выбор модели) — **вне объёма** (заказчик: «Модели не выбираем
-и не меняем»).
-
-Факты, сверенные с кодом (не изобретать):
-- **Семейство операторских action-статусов уже существует.** `webhooks/plane.py::handle_issue_updated`
-  (строки 163–181) разбирает STOP (ORCH-090) и Confirm Deploy (ORCH-059) через `proj_states.get("<key>")`;
-  оба **намеренно отсутствуют** в `plane_sync._DEFAULT_STATES` (fail-closed) и сопоставляются именем через
-  `_PLANE_NAME_TO_KEY` (`src/plane_sync.py:131`). Статус «Оценка» — третий представитель того же семейства.
-- **Массовость «бесплатна»:** Plane multi-select → N независимых `issue.updated`-вебхуков; спец-batch-кода не нужно.
-- **Фактура для калибровки накоплена:** `usage.task_usage_summary(task_id)` (`src/usage.py:834`) агрегирует
-  токены/стоимость per-task из `agent_runs`; тайминги — `tasks.created_at/updated_at`,
-  `agent_runs.started_at/finished_at`. Колонка `tasks.track` (ORCH-019) различает `full`/`bug`.
-- **Запись в Plane идёт через guard ORCH-117:** все три примитива записи (`update_issue_state`/`add_comment`/
-  `_set_issue_state_direct`) проходят `_guard_allows_write` (`src/plane_sync.py:847`) — из тест/worktree-процесса
-  запись в боевой проект физически заблокирована.
-- **estimate-система Plane не настроена** на момент анализа; `estimate_point` — FK на estimate-point estimate-системы,
-  `point` — целочисленное поле issue. В `src/` **нет** кода работы с Plane-estimate (net-new интеграция).
-- **leaf-паттерн платформы** (`serial_gate`/`coverage_gate`/`bug_fast_track`/`lessons`): never-raise, kill-switch
-  `*_enabled`, скоуп `*_repos` (пусто → self-hosting only через `qg.checks.is_self_hosting_repo`), read-only блок
-  в `GET /queue`, `applies(repo)` локально и ПЕРВЫМ.
-- **Хук done-факта:** блок `if next_stage == "done"` в `stage_engine.advance_stage` (`src/stage_engine.py:521`)
-  — единственная авторитетная точка перехода в терминал.
-
-**Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не** Quality Gate и **не** переход стадии.
-`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схемы существующих таблиц —
-байт-в-байт. Горячий путь `resolve_agent_model`/`resolve_agent_effort`/`_spawn` — не трогается.
-
-## Решение
-
-### Сводка
-Вводим **новый операторский Plane-статус «Оценка»** как третий член семейства action-статусов
-(STOP/Confirm Deploy) — fail-closed `.get("estimate")`-ветка в `handle_issue_updated`, делегирующая
-**новому leaf-модулю `src/estimator.py`** (never-raise, kill-switch, скоуп). Механизм прогноза —
-**детерминированная эвристика по истории завершённых задач** (чистые функции, **без LLM-вызова**):
-прогноз = средние токены/время/стоимость похожих `done`-задач того же репо/трека, story-points —
-чистая функция-бакетизатор. Прогноз пишется в Plane (`estimate_point` + коммент), Telegram-карточку и
-**новую аддитивную таблицу `task_estimates`** (UPSERT по `work_item_id`); затем issue возвращается в
-`Backlog`. По завершении задачи факт (из `usage.py`) пишется в `point` и в леджер. Всё — аддитивно,
-под флагами, fail-safe, без касания control-path.
-
-### D1 — Механизм прогноза: детерминированная эвристика по истории, **без LLM** (NFR-4, NFR-5; решение Q открытого вопроса TRZ §NFR-4)
-Это **главное архитектурное решение**, которое TRZ явно делегировал архитектору.
-
-- **Выбор: чистая детерминированная эвристика** (in-process, без сетевого LLM-вызова и без субпроцесса).
-  Прогноз вычисляется парой индексированных SQL-чтений + чистыми функциями за микросекунды.
-- **Почему не LLM-оценщик / не гибрид (на этом шаге):**
-  1. **NFR-5 (массовость).** Multi-select десятков задач → десятки почти одновременных вебхуков. LLM-вызов
-     на оценку умножился бы на N и конкурировал бы за **единственный транспорт LLM** (`launcher._spawn`) с
-     боевыми агентами, рискуя замедлить обслуживание **других** проектов (enduro) из общего прода.
-  2. **NFR-4 (стоимость ≪ ценности).** Opus-вызов на каждую из десятков backlog-задач — это реальные $ за
-     саму оценку; эвристика бесплатна.
-  3. **Политика ORCH-118 (determinization-roadmap).** Платформа целенаправленно **сокращает** avoidable
-     LLM-пути (`llm-usage-policy.md`: «LLM — только где нужно настоящее суждение»). Оценка размера по истории
-     — деривируемая из tool-сигналов величина, **не** требующая суждения LLM. Вводить здесь новый LLM-путь
-     прямо противоречит действующей политике.
-  4. **Воспроизводимость/тестируемость.** Детерминированный бакетизатор покрывается unit-тестами на границах
-     (AC-2 / TC-09), чего LLM не даёт.
-- **Стек-расширяемость (BR-6 содержания, без реализации сейчас):** контракт `estimator.estimate(work_item_id,
-  description|issue, repo) -> {forecast_tokens, forecast_seconds, forecast_cost_usd, story_points}` —
-  **граница расширения**. Будущий гибридный LLM-рефайнер (если когда-нибудь понадобится) встраивается
-  ЗА этой границей без изменения вызывающих. Сейчас LLM-рефайнер **не строится** (Шаг 2 / выбор модели вне
-  объёма, AC-11).
-
-### D2 — Модель прогноза: средние по «похожим» завершённым задачам + bootstrap (BR-1, BR-2)
-- **«Похожие» = тот же `repo` И тот же `track`** (`full`/`bug`, ORCH-019) среди задач со `stage='done'`.
-  Трек — дешёвый, уже хранимый, осмысленный разрез сложности (багфикс короче полного цикла).
-- **Источник фактуры (read-only):** тонкий агрегат `db.completed_task_stats(repo, track) ->
-  {n, mean_tokens, mean_cost_usd, mean_seconds}` поверх `agent_runs` (токены/стоимость, как
-  `task_usage_summary`, но сгруппировано по завершённым задачам) и `tasks` (время = `updated_at - created_at`,
-  отсечка аномалий по `estimator_wall_cap_s`, зеркало `tracker_brd_review_cap_s` ORCH-087). `usage.py`
-  переиспользуется read-only.
-- **Прогноз = средние** по выборке. `forecast_tokens = mean_tokens`, `forecast_cost_usd = mean_cost_usd`,
-  `forecast_seconds = mean_seconds`.
-- **Bootstrap (пустая/малая история):** `n < estimator_min_samples` (дефолт 3) → значения берутся из
-  конфиг-дефолтов `estimator_bootstrap_{tokens,cost_usd,seconds}` (или смешиваются с имеющейся выборкой —
-  деталь реализации; разработчику разрешена линейная интерполяция). **Никогда не исключение** (AC-1/TC-10).
-- **Сигналы описания (опц., v1 — не обязательны):** длина текста постановки / наличие метки `Bug` могут
-  скорректировать выбор трека; в v1 достаточно `repo+track`. Расширение — за границей D1.
-
-### D3 — Бакетизатор story points: чистая функция, конфигурируемые пороги (BR-3, AC-2)
-- **Чистая функция** `estimator.story_points_for(forecast) -> int ∈ {1,2,3,5,8}`. Первичный сигнал —
-  **`forecast_cost_usd`** (прямая ось «сколько будет стоить», запрошенная заказчиком; легко
-  ре-калибруется конфигом при смене тарифа/провайдера ORCH-13).
-- **Пороги** — конфиг `estimator_sp_cost_thresholds` (CSV из 4 возрастающих кат-оффов `t1,t2,t3,t5`),
-  семантика `<=` по возрастанию:
-  `cost ≤ t1 → 1` · `≤ t2 → 2` · `≤ t3 → 3` · `≤ t5 → 5` · `иначе → 8`.
-  **Дефолты (bootstrap, подлежат калибровке):** `0.50, 2.00, 5.00, 12.00` ($).
-- **Семантика шкалы (фиксирована, BR-3/FR-T4):** `1` docs/label/config · `2` небольшой фикс · `3` средняя ·
-  `5` сложная (код+тесты) · `8` эпик/разбивать. Значения вне `{1,2,3,5,8}` не выдаются.
-- **Факт-story-points** считаются той же функцией по фактической стоимости (консистентность прогноз↔факт).
-- Калибровка порогов — задача петли ORCH-8 поверх леджера D7; пороги конфигурируемы именно ради этого.
-
-### D4 — Триггер: fail-closed ветка `estimate`, взаимоисключение жестов (BR-T1, BR-T5, AC-T1, AC-T5)
-- `plane_sync._PLANE_NAME_TO_KEY["Оценка"] = "estimate"`; ключ `estimate` **НЕ добавляется** в
-  `_DEFAULT_STATES` (fail-closed, как `stop`/`confirm_deploy`). На доске без статуса
-  `proj_states.get("estimate") is None` → ветка инертна (нет KeyError, нет оценки).
-- В `handle_issue_updated` — отдельная ветка `estimate_state = proj_states.get("estimate")`;
-  `if estimate_state and new_state == estimate_state: await handle_estimate(...)`. **Размещение:** сразу
-  после ветки `stop` (раннее, рядом с прочими `.get`-action-статусами). Корректность взаимоисключения
-  обеспечена **различием UUID** статусов (а не порядком); порядок выбран для читаемости. Ветка не
-  алиасит STOP/`to_analyse`/`confirm_deploy`/`approved`/`rejected`.
-
-### D5 — `handle_estimate`: анти-disruption, авто-возврат, анти-loop (BR-T2, BR-T6, FR-T2, FR-T5, AC-T2, AC-T6)
-- `handle_estimate(data, project_id)` резолвит `plane_id`/`work_item_id`; `repo` — по проекту
-  (`projects.get_project_by_repo`/реестр). **Исполнение off-loop** через `asyncio.to_thread` (зеркало
-  `handle_stop`), т.к. ядро синхронно и делает сетевые Plane-вызовы. Контракт never-raise.
-- **Guard-цепочка (каждый — no-op-with-log при невыполнении):**
-  1. `estimator.applies(repo)` — kill-switch + скоуп, локально и ПЕРВЫМ (без сети при выключенном флаге);
-  2. **анти-disruption (BR-T6):** issue с pipeline-задачей, у которой есть **активный** job
-     (`db.has_active_job_for_task(task_id)`, `src/db.py:1323`) → no-op + лог (не выдёргивать in-flight
-     работу). Backlog-issue (нет задачи) или терминальная/idle-задача → оценка допустима.
-- Далее: `estimator.estimate(...)` → запись прогноза (D6/D7/D8) → **`set_issue_backlog(work_item)`** (D6).
-- **Анти-loop:** `backlog` не совпадает ни с одной триггер-веткой → входящий «state→Backlog» webhook —
-  no-op-эхо. Возврат best-effort: сбой записи статуса не роняет флоу (прогноз уже записан).
-
-### D6 — Запись в Plane: `estimate_point` (FK) + `point` (int) + коммент + Backlog (BR-7, BR-8, FR-T7, NFR-6, NFR-7)
-Новые write-хелперы в `plane_sync.py`, все через `_guard_allows_write` (ORCH-117), все never-raise:
-- **`set_issue_backlog(work_item)`** — `get_project_states(pid)["backlog"]` → `_set_issue_state_direct`
-  (ключ `backlog` уже в `_DEFAULT_STATES`). Зеркало `set_issue_done`/`set_issue_in_review`.
-- **`set_issue_point(work_item, value:int)`** — PATCH `{"point": int(value)}` (легаси целочисленное поле,
-  устойчиво — не зависит от estimate-системы). Это запись **факта** (BR-8).
-- **`set_issue_estimate_point(work_item, value)`** — резолв estimate-point UUID через новый
-  `get_project_estimate_points(project_id)` (GET project → `estimate` id → GET estimate-points → map
-  `value→uuid`, TTL-кэш по образцу `get_project_states`/ORCH-068), затем PATCH `{"estimate_point": <uuid>}`.
-  Это запись **прогноза** (BR-7).
-- **fail-safe (NFR-7):** estimate-система не настроена / значение вне системы / поле отсутствует / 4xx →
-  **best-effort пропуск + лог**, не падение. `point` устойчивее `estimate_point` (сырой int), но оба
-  best-effort.
-- **Коммент** — `add_comment` с прогнозом (стоимость/время/токены/story points), `author="stream"`.
-- Прогноз пишется в `estimate_point`, факт — в `point`; поля **не перепутаны**; факт **не перезаписывает**
-  `estimate_point` (AC-3/AC-4).
-
-### D7 — Персистентность: аддитивная `task_estimates`, UPSERT по `work_item_id` (BR-10, FR-T9, NFR-8, AC-T4, AC-12)
-- **Новая аддитивная таблица** `task_estimates` (`CREATE TABLE IF NOT EXISTS` в `init_db()`, паттерн
-  `coverage_baseline`/`lessons`/`transition_lease`), **`UNIQUE(work_item_id)`** для идемпотентного UPSERT.
-  Полная схема, типы, индексы — `08-data-requirements.md`.
-- Хелперы `db.record_estimate(**)` (UPSERT прогноза по `work_item_id`), `db.set_actual(work_item_id, ...)`
-  (запись факта+дельты), `db.get_estimate(work_item_id)`, `db.estimates_snapshot()`.
-- Ключ — `work_item_id` (на момент оценки `task_id` может быть `NULL` — issue на бэклоге, строки `tasks`
-  ещё нет). `task_id` заполняется позже, когда оценённый issue входит в пайплайн (best-effort).
-- Существующие таблицы — **не изменяются** (NFR-8).
-
-### D8 — Поверхности отображения: Plane-коммент + пункт «Оценка» в Telegram-карточке (BR-9, FR-T8, AC-5, AC-6)
-- **Plane-коммент** — D6.
-- **Telegram-карточка** — пункт **«Оценка»** (время · токены · стоимость) в рендере общей карточки
-  (`notifications.update_task_tracker`), читается из `task_estimates` по `work_item_id`; never-raise; пустой
-  прогноз → пункт опускается; инвариант «одна карточка на задачу» (ORCH-087) не нарушается;
-  HTML-data-слоты экранируются `html.escape` ровно один раз (канон ORCH-095).
-- **Замечание о времени появления строки:** карточка существует у pipeline-задачи; если оценка сделана на
-  бэклоге до старта пайплайна — строка «Оценка» появится при первом рендере карточки после старта
-  (`task_estimates` хранится по `work_item_id`, переживает старт). Приемлемо и задокументировано.
-
-### D9 — Запись факта на `done` (BR-8, FR-T7, AC-4)
-- Тонкая **best-effort врезка** `estimator.record_actual_on_done(task_id, repo, work_item_id)` в
-  `stage_engine.advance_stage` в существующем блоке `if next_stage == "done"` (`src/stage_engine.py:521`),
-  ПОСЛЕ terminal-sync, в своём `try/except` (never-raise; зеркало release-merge-lease-врезки рядом).
-- Считает факт из `usage.task_usage_summary(task_id)` + тайминги → `story_points_for(actual)` →
-  `db.set_actual(...)` + `set_issue_point(work_item, actual_sp)`. **Не** перезаписывает `estimate_point`.
-- `STAGE_TRANSITIONS`/гейт `check_deploy_status`/machine-verdict — не трогаются (врезка после решения о
-  переходе, не влияет на него).
-
-### D10 — Толерантность к массовости (NFR-5, AC-T3)
-- **Сглаживание встроено в выбор D1:** детерминированная эвристика без LLM/субпроцесса → per-issue ядро
-  O(1) (пара индексированных чтений). Доминирующая стоимость — несколько ограниченных Plane HTTP-раундов на
-  issue, исполняемых off-loop (`to_thread`).
-- **Новой очереди НЕ вводим:** очередь `jobs`/`max_concurrency` — для агентов (control-path); оценка не
-  занимает её слот (NFR-3). Опциональный простой in-process семафор `estimator_max_inflight` (дефолт
-  «щедрый», эффективно off) — конфиг-семя на случай измеренной перегрузки; в v1 не активничает.
-- Один webhook не гасит остальные (N независимых вызовов).
-
-### D11 — leaf-инварианты, флаги, наблюдаемость (NFR-2, NFR-3, FR-T10, AC-9)
-- **Leaf `src/estimator.py`** (never-raise, паттерн `bug_fast_track`/`coverage_gate`): импортирует только
-  `config` (+ лениво `db`/`usage`/`plane_sync`/`notifications`/`qg.checks`), не импортирует `stage_engine`/
-  `launcher`. Публичные: `applies(repo)`, `estimate(...)`, `story_points_for(...)`,
-  `record_actual_on_done(...)`, `snapshot()`.
-- **Флаги** (`config.py`, дефолты безопасные): `estimator_enabled` (kill-switch, env
-  `ORCH_ESTIMATOR_ENABLED`), `estimator_repos` (CSV, env `ORCH_ESTIMATOR_REPOS`; **пусто → self-hosting
-  only**), + тюнинг `estimator_min_samples`, `estimator_bootstrap_tokens/cost_usd/seconds`,
-  `estimator_sp_cost_thresholds`, `estimator_wall_cap_s`, `estimator_max_inflight`.
-- `applies(repo)` локально и ПЕРВЫМ → выключенный флаг = нулевой сетевой оверхед, нулевая регрессия для
-  enduro/orchestrator.
-- **Наблюдаемость:** read-only блок `estimator` в `GET /queue` (флаг/скоуп + счётчики прогнозов/записей в
-  Plane/возвратов-в-Backlog/фактов); при невозможности записи в Plane — лог-warning.
-
-### D12 — Опциональные программные эндпоинты (TRZ §4, AC-7)
-- `POST /estimate?work_item=<id>`, `POST /estimate/backlog`, `GET /estimate?work_item=<id>` — **то же ядро**
-  `estimator.estimate(...)`, идемпотентны. Удобство/диагностика, **не** основной триггер. Их отсутствие не
-  нарушает приёмку. Не преподносить как единственный способ запуска.
-
-## Альтернативы
-- **LLM-оценщик (отдельный вызов на задачу) / гибрид** — отвергнуто на этом шаге: нарушает NFR-4
-  (стоимость самой оценки), NFR-5 (массовость конкурирует за единственный LLM-транспорт), и политику
-  ORCH-118 (avoidable LLM control/consultation path). Граница `estimate()` оставляет место под будущий
-  гибрид без переписывания вызывающих.
-- **Авто-оценка каждой задачи на `start_pipeline`** — отвергнуто: это модель, которую заказчик **явно
-  отклонил** (REJECT 2026-06-17). Оценка — операторский on-demand жест.
-- **Новый массовый `POST /estimate-batch` как основной путь** — отвергнуто: массовость даёт сам Plane
-  multi-select (N вебхуков); batch-эндпоинт — лишний код и второй источник истины.
-- **Отдельная стадия/ребро `STAGE_TRANSITIONS` для оценки** — отвергнуто: нарушает NFR-1; оценка не есть
-  переход стадии. Side-механизм по образцу STOP/Confirm Deploy.
-- **Бакетизация по токенам вместо стоимости** — рассмотрено: токены модель-независимы, но заказчик мыслит
-  осью «сколько стоит». Выбрана стоимость с конфигурируемыми порогами (ре-калибруемыми при ORCH-13);
-  переключение сигнала — локальная правка за чистой функцией.
-- **Хранение оценки в `tasks` колонками** — отвергнуто: на момент оценки строки `tasks` может не быть
-  (бэклог); ключ по `work_item_id` в отдельной таблице корректнее (NFR-8, аддитивность).
-
-## Последствия
-- **+** Оператор видит прогноз (стоимость/время/токены/story points) до отправки задачи в работу; массовая
-  оценка одним multi-select; пере-оценка идемпотентна; фундамент петли калибровки (ORCH-8) заложен (леджер).
-- **+** Нулевая нагрузка на LLM-транспорт и нулевая $-стоимость самой оценки; bulk-безопасно; полностью
-  детерминировано и тестируемо; согласовано с determinization-политикой ORCH-118.
-- **+** Control-path/гейты/горячий путь не тронуты; enduro и текущий orchestrator при выключенном флаге /
-  на доске без статуса — нулевая регрессия.
-- **−** Точность прогноза на холодном старте ограничена (мало истории) → митигейшн: bootstrap-дефолты +
-  петля калибровки порогов поверх леджера (BR-10). Пороги story-points — начальные, подлежат калибровке.
-- **−** Net-new интеграция с Plane-estimate API (`estimate_point` — FK) добавляет инфра-предусловие
-  (estimate-система с Fibonacci) и хрупкость записи → митигейшн: best-effort/fail-safe (NFR-7), устойчивый
-  `point` (raw int) для факта, точная спека — `07-infra-requirements.md`.
-- **− (масштаб)** Это **аддитивный leaf по устоявшемуся паттерну** (как serial_gate/coverage_gate/lessons),
-  без новой стадии, без правки существующих таблиц, без смены БД-движка. **`arch:major-change` не требуется.**
-- **Откат:** `ORCH_ESTIMATOR_ENABLED=false` → весь модуль инертен (статус «Оценка» не обрабатывается, нет
-  записей в Plane/карточку/таблицу; конвейер байт-в-байт до ORCH-020). Доп. откат «на уровне доски» — не
-  создавать статус «Оценка» (fail-closed). Таблица `task_estimates` остаётся (аддитивна, безвредна).
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-020/01-brd.md`
-- TRZ: `docs/work-items/ORCH-020/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-020/03-acceptance-criteria.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`
-- Инфра/данные/риски: `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`
-- Сверено по коду: `src/plane_sync.py` (`_PLANE_NAME_TO_KEY`/`_DEFAULT_STATES`/`_guard_allows_write`/write-хелперы),
-  `src/webhooks/plane.py` (`handle_issue_updated`/`handle_stop`), `src/usage.py:834` (`task_usage_summary`),
-  `src/db.py` (`has_active_job_for_task`/`_ensure_column`/leaf-DDL-паттерн), `src/stage_engine.py:521`
-  (`next_stage=="done"`), `src/bug_fast_track.py` (`applies`/label-аппарат), `src/qg/checks.py`
-  (`is_self_hosting_repo`)
-- Прецеденты: ORCH-090 (STOP), ORCH-059 (Confirm Deploy), ORCH-117 (write-guard), ORCH-019 (`track`),
-  ORCH-118 (LLM-политика), ORCH-098 (leaf-таблица), ORCH-087/095 (Telegram-карточка)

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

@@ -1,76 +0,0 @@
----
-work_item: ORCH-020
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-020 — Оценка задачи, запускаемая статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable. Топология контейнеров/сети **не меняется**; затрагиваются только
-> Plane-конфигурация (новый статус + estimate-система), env-флаги и онбординг-канон.
-> Это инфра-предусловия записи/триггера (NFR-7), а не изменение хост-топологии.
-
-## I-1. Топология / окружения
-**N/A для контейнеров/портов/сети/томов.** Новых сервисов/контейнеров/портов нет. Модуль `estimator`
-работает внутри существующего процесса `orchestrator` (8500); никаких новых демонов/потоков.
-
-**Plane-конфигурация (предусловия, разовые, человек/онбординг):**
-- **P-1. Статус «Оценка» на доске проекта ORCH.** Создать board-статус с **точным именем** `Оценка`.
-  Его отсутствие = fail-closed no-op (BR-T5): `proj_states.get("estimate") is None` → ветка инертна.
-  - **Группа статуса.** «Оценка» — транзиентный backlog-side статус (issue в нём лишь на время оценки,
-    затем оркестратор возвращает в `Backlog`). Рекомендуемая Plane-группа — **`backlog`** или
-    `unstarted` (косметика индикации). **Запрещена** группа `completed`/`cancelled`: терминал-детект
-    ORCH-068 (по `group`) иначе ложно посчитает оценку терминалом. Это **обязательный** инвариант группы
-    (зеркало правила ORCH-009: терминальные группы только у Done/Cancelled/STOP).
-- **P-2. estimate-система Plane (для `estimate_point`).** Настроить на проекте ORCH estimate-систему типа
-  **Points** со значениями Fibonacci **`1, 2, 3, 5, 8`** (под `project.estimate`). `estimate_point` — FK
-  на estimate-point этой системы; запись прогноза резолвит `value → estimate_point UUID`
-  (`plane_sync.get_project_estimate_points`, TTL-кэш). **Отсутствие/частичная конфигурация → best-effort
-  пропуск записи `estimate_point` + лог, без падения конвейера** (NFR-7). Поле факта `point` —
-  целочисленное, устойчиво и пишется сырым int независимо от estimate-системы.
-
-## I-2. Переменные окружения / секреты
-**Новых секретов/токенов НЕТ** (NFR-6). Запись в Plane идёт существующими `PLANE_HEADERS` под guard
-ORCH-117. Новые конфиг-флаги (`config.py`, env-префикс `ORCH_`; дефолты безопасные — пустой `.env` = off
-для не-self-hosting, self-hosting-only при пустом скоупе):
-
-| Ключ | env | Дефолт | Назначение |
-|------|-----|--------|-----------|
-| `estimator_enabled` | `ORCH_ESTIMATOR_ENABLED` | `True` | kill-switch (False → модуль инертен, нулевая регрессия) |
-| `estimator_repos` | `ORCH_ESTIMATOR_REPOS` | `""` | CSV-скоуп; **пусто → self-hosting only** (`orchestrator`) |
-| `estimator_min_samples` | `ORCH_ESTIMATOR_MIN_SAMPLES` | `3` | порог истории ниже которого включается bootstrap |
-| `estimator_bootstrap_tokens` | `ORCH_ESTIMATOR_BOOTSTRAP_TOKENS` | *(реализация)* | дефолт токенов при пустой истории |
-| `estimator_bootstrap_cost_usd` | `ORCH_ESTIMATOR_BOOTSTRAP_COST_USD` | *(реализация)* | дефолт стоимости при пустой истории |
-| `estimator_bootstrap_seconds` | `ORCH_ESTIMATOR_BOOTSTRAP_SECONDS` | *(реализация)* | дефолт времени при пустой истории |
-| `estimator_sp_cost_thresholds` | `ORCH_ESTIMATOR_SP_COST_THRESHOLDS` | `0.50,2.00,5.00,12.00` | пороги бакета story-points (t1,t2,t3,t5), `<=` по возрастанию |
-| `estimator_wall_cap_s` | `ORCH_ESTIMATOR_WALL_CAP_S` | *(реализация)* | отсечка аномального wall-времени в истории (зеркало `tracker_brd_review_cap_s`) |
-| `estimator_max_inflight` | `ORCH_ESTIMATOR_MAX_INFLIGHT` | *(щедрый/off)* | опц. семафор сглаживания массовой нагрузки (v1 неактивен) |
-
-`.env.example` — добавить блок `ORCH_ESTIMATOR_*` как канон ключей старта (норматив ORCH-101: дефолт =
-боевое значение).
-
-## I-3. Деплой / рестарт
-- **Прод-рестарт `orchestrator` в рамках задачи — НЕ выполнять** (self-hosting инвариант: общий прод
-  обслуживает enduro). Изменения вступают штатно: код — через прод-выкат **только** после staging-гейта
-  (8501) по `docs/operations/INFRA.md`; флаги — через управляемый рестарт оператором по runbook.
-- **Plane-предусловия P-1/P-2 настраиваются в Plane UI/API** оператором — вне рантайма, вне деплоя орка.
-- **Миграция БД** — аддитивная (`CREATE TABLE IF NOT EXISTS task_estimates` в `init_db()`), применяется
-  идемпотентно на старте; рестарт прод-контейнера ради неё не нужен (применится при следующем штатном
-  старте). Детали — `08-data-requirements.md`.
-- **Онбординг нового проекта (ORCH-009).** Канон онбординга расширяется: статус «Оценка» становится
-  **23-м** статусом (`onboard_project.py` импортирует имена из `plane_sync._PLANE_NAME_TO_KEY` —
-  добавление `"Оценка"→"estimate"` автоматически попадает в проверку; группа `backlog`/`unstarted`
-  фиксируется в каноне групп). estimate-система Fibonacci — добавить как `manual-step`/ensure в
-  онбординг-runbook (Plane CE API может не покрывать estimate-настройку → честный `manual-step`,
-  fail-safe). Это **follow-up по онбордингу**, не блокер ORCH-020 (на существующем проекте ORCH
-  предусловия настраиваются руками).
-
-## I-4. CI/CD
-**Без изменений `.gitea/workflows/`.** Новый тест-модуль `tests/test_orch020_estimator.py` исполняется
-существующим `pytest tests/` (CI / coverage-gate / merge-gate re-test) штатно — без новых шагов CI.
-Новых внешних зависимостей нет (эвристика — stdlib + существующие `httpx`/`db`).

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

@@ -1,85 +0,0 @@
----
-work_item: ORCH-020
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-020 — Оценка задачи, запускаемая статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable / информационный (гейтом не парсится). Одна **новая аддитивная** таблица; существующие
-> таблицы (`tasks`/`agent_runs`/`jobs`/…) — **не изменяются** (NFR-8).
-
-## Изменения схемы БД
-
-**Новая аддитивная таблица `task_estimates`** (`CREATE TABLE IF NOT EXISTS` в `db.init_db()`, паттерн
-`coverage_baseline`/`lessons`/`transition_lease`; идемпотентно, restart-safe на общей прод-БД):
-
-```sql
-CREATE TABLE IF NOT EXISTS task_estimates (
-    id                    INTEGER PRIMARY KEY AUTOINCREMENT,
-    work_item_id          TEXT NOT NULL UNIQUE,   -- ключ/UPSERT-цель (issue может не иметь task на момент оценки)
-    task_id               INTEGER,                -- FK tasks.id; НУЛЛАБЕЛЕН до старта пайплайна
-    repo                  TEXT,
-    -- Прогноз (на момент перевода в «Оценка»):
-    forecast_tokens       INTEGER,
-    forecast_seconds      INTEGER,
-    forecast_cost_usd     REAL,
-    forecast_story_points INTEGER,                -- из {1,2,3,5,8}
-    -- Факт (на момент перехода задачи в `done`):
-    actual_tokens         INTEGER,
-    actual_seconds        INTEGER,
-    actual_cost_usd       REAL,
-    actual_story_points   INTEGER,                -- из {1,2,3,5,8}
-    -- Метаданные:
-    source                TEXT,                   -- 'status' | 'manual' | 'api'
-    estimate_count        INTEGER NOT NULL DEFAULT 1,  -- число пере-оценок (инкремент при UPSERT)
-    created_at            TEXT NOT NULL DEFAULT (datetime('now')),
-    updated_at            TEXT
-);
-CREATE INDEX IF NOT EXISTS idx_task_estimates_repo    ON task_estimates (repo);
-CREATE INDEX IF NOT EXISTS idx_task_estimates_task_id ON task_estimates (task_id);
-```
-
-- **`UNIQUE(work_item_id)`** — несущий инвариант идемпотентной пере-оценки (BR-T4/AC-T4): повторный перевод
-  в «Оценка» делает **UPSERT** (`INSERT … ON CONFLICT(work_item_id) DO UPDATE …`), обновляя одну строку и
-  инкрементируя `estimate_count`; дублей строк нет.
-- **Дельта** прогноз↔факт **не хранится отдельной колонкой** — вычисляется на чтение из forecast/actual
-  (избегаем рассинхрона; калибровке достаточно обеих величин). При желании реализатор может добавить
-  материализованные `delta_*` — не обязательно (BR-10 требует «обе величины + дельту»; вычисляемая дельта
-  это удовлетворяет).
-- **Индексы:** по `repo` (выборка/снапшот по проекту) и `task_id` (связь с задачей). По `work_item_id`
-  индекс создаётся автоматически (UNIQUE).
-
-## Новые/изменённые сущности
-
-- **Хелперы `db.py`** (каждый открывает/закрывает свою connection, паттерн `coverage_baseline`/`lessons`;
-  leaf `estimator`/вызывающие оборачивают в never-raise):
-  - `record_estimate(work_item_id, repo, task_id=None, forecast_*=…, source='status') -> int` — UPSERT
-    прогноза по `work_item_id`; инкремент `estimate_count`, стамп `updated_at`.
-  - `set_actual(work_item_id, actual_tokens, actual_seconds, actual_cost_usd, actual_story_points,
-    task_id=None) -> bool` — запись факта; **не трогает** forecast-поля.
-  - `get_estimate(work_item_id) -> dict | None` — текущая строка прогноз/факт.
-  - `estimates_snapshot(limit=…) -> dict` — read-only для блока `estimator` в `GET /queue`.
-- **Read-only агрегат истории** `db.completed_task_stats(repo, track) -> {n, mean_tokens, mean_cost_usd,
-  mean_seconds}` — поверх `agent_runs` (токены/стоимость, как `task_usage_summary`) и `tasks`
-  (`stage='done'`, время = `updated_at − created_at` с отсечкой `estimator_wall_cap_s`). **Только чтение**
-  существующих таблиц; новых колонок не вводит.
-
-## Совместимость данных / миграции
-
-- **Аддитивность (NFR-8):** только новая таблица + новые read/write-хелперы; **ни одной** правки
-  существующих таблиц/колонок/индексов. `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict-ключи независимы
-  от данных оценки.
-- **Идемпотентность миграции:** `CREATE TABLE IF NOT EXISTS` + `CREATE INDEX IF NOT EXISTS` — no-op на уже
-  созданной таблице; безопасно на живой общей прод-БД (enduro не затронут — таблица общая, но писать в неё
-  будет только self-hosting-скоуп; строки enduro не появляются, пока репо вне `estimator_repos`).
-- **Restart-safe:** строки `task_estimates` переживают рестарт; прогноз, сделанный на бэклоге (с
-  `task_id=NULL`), сохраняется до старта пайплайна и связывается с `task_id` позже (best-effort).
-- **Влияние на общую прод-БД:** таблица малая (одна строка на оценённый issue), индексы лёгкие; нагрузка на
-  hot-path **нулевая** (claim/queue не читают `task_estimates`). Откат (`ORCH_ESTIMATOR_ENABLED=false`)
-  оставляет таблицу пустой/неиспользуемой — безвредно.

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

@@ -1,47 +0,0 @@
----
-work_item: ORCH-020
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-020 — Оценка задачи, запускаемая статусом «Оценка»
-
-Work Item: **ORCH-020** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Массовый перевод (десятки issue → десятки вебхуков) перегружает прод**, тормозя обслуживание enduro | Сред. | Выс. | D1: детерминированная эвристика **без LLM/субпроцесса** (ядро O(1)); off-loop `to_thread`; **не** занимает слот `jobs/max_concurrency`; опц. семафор `estimator_max_inflight` как семя; никакого LLM-fan-out за единственный транспорт |
-| TR-2 | **Статус «Оценка» выдёргивает in-flight задачу** в Backlog / прерывает работу | Низ. | Выс. | D5: guard `has_active_job_for_task` → no-op при активном job; авто-возврат только в `Backlog`, никогда не трогает `STAGE_TRANSITIONS`/стадии |
-| TR-3 | **Цикл вебхуков** (возврат в Backlog → новый webhook → повторная оценка) | Низ. | Сред. | D4/D5: `backlog` не совпадает ни с одной триггер-веткой → входящий «state→Backlog» = no-op-эхо (анти-loop по построению) |
-| TR-4 | **estimate-система Plane не настроена / `estimate_point` — FK** → запись прогноза падает/невозможна | Сред. | Сред. | D6/NFR-7: best-effort пропуск + лог, never-raise; факт пишется в устойчивый int-`point`; точная спека и предусловие — `07-infra-requirements.md` (P-2) |
-| TR-5 | **Запись в боевой Plane из теста/worktree** (общая доска) | Низ. | Выс. | D6: все три записи (`estimate_point`/`point`/коммент/состояние) под `_guard_allows_write` (ORCH-117) → из pytest-процесса физически заблокированы |
-| TR-6 | **Неточность прогноза на холодном старте** (мало истории) подрывает доверие | Выс. | Низ. | D2: bootstrap-дефолты ниже `estimator_min_samples`; леджер `task_estimates` (D7) + конфигурируемые пороги D3 как фундамент петли калибровки (ORCH-8) |
-| TR-7 | **Пороги story-points произвольны** (нет калиброванных данных day-1) | Сред. | Низ. | D3: пороги вынесены в конфиг `estimator_sp_cost_thresholds`; дефолты помечены как bootstrap; ре-калибровка поверх леджера без правки кода |
-| TR-8 | **Расползание в Шаг 2** (per-task override модели/эффорта = касание control-path) | Низ. | Выс. | NFR-1/NFR-3/AC-11: жёсткий out-of-scope; горячий путь `resolve_agent_model`/`resolve_agent_effort`/`_spawn` не трогается; follow-up на отдельный work item (зависимость ORCH-13) |
-| TR-9 | **Идемпотентность пере-оценки нарушена** (дубли строк) | Низ. | Сред. | D7: `UNIQUE(work_item_id)` + UPSERT; покрыто TC-07 |
-| TR-10 | **Дрейф канона онбординга** (23-й статус «Оценка» не учтён) | Низ. | Низ. | D4 + `07` I-3: имя статуса берётся из `_PLANE_NAME_TO_KEY` (онбординг-проверка ловит автоматически); группа фиксирована каноном; estimate-система — `manual-step` |
-| TR-11 | **Строка «Оценка» в Telegram-карточке роняет рендер** | Низ. | Сред. | D8: never-raise; пустой прогноз → пункт опускается; `html.escape` один раз (ORCH-095); инвариант «одна карточка» (ORCH-087) не нарушается |
-| TR-12 | **Врезка факта на `done` влияет на переход** | Низ. | Выс. | D9: best-effort `try/except` ПОСЛЕ решения о переходе; `check_deploy_status`/`STAGE_TRANSITIONS`/machine-verdict не трогаются |
-
-## Сводный вывод
-
-Доминирующий класс рисков — **операционные** (массовость TR-1, инфра-предусловия Plane TR-4/TR-10) и
-**точностные** (TR-6/TR-7), а **не** архитектурно-структурные: control-path, гейты, горячий путь запуска
-агентов и схемы существующих таблиц **не затрагиваются** (NFR-1/NFR-3), всё аддитивно, под kill-switch,
-never-raise, fail-safe, скоуп self-hosting.
-
-Выбор детерминированной эвристики (D1) **снимает корневой риск масштаба** (TR-1) и согласован с
-determinization-политикой ORCH-118 — это сознательно консервативное, обратимое решение.
-
-**Эскалация `arch:major-change` не требуется:** изменение — аддитивный leaf по устоявшемуся паттерну
-(serial_gate/coverage_gate/lessons/cancel), без новой стадии, без правки существующих таблиц, без смены
-БД-движка. **Возврат в анализ не требуется:** ТЗ реализуемо без нарушения принципов архитектуры.
-Остаточный риск для прод-конвейера (self-hosting) — **низкий**; точность прогноза — итеративно улучшаемая
-через заложенный леджер калибровки.

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

@@ -1,106 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-020
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-020
-version: 2
----
-
-# Review ORCH-020 — Оценка задачи, запускаемая Plane-статусом «Оценка»
-
-## Summary
-
-Реализация **технически сильная и полная**: новый leaf `src/estimator.py` (never-raise, kill-switch
-`estimator_enabled` + скоуп `estimator_repos`), детерминированная эвристика по истории завершённых
-задач **без LLM** (как требует ADR-001 D1 и политика determinization ORCH-118), точечные аддитивные
-врезки в `webhooks/plane.py` / `plane_sync.py` / `stage_engine.py` / `db.py` / `notifications.py` /
-`main.py` / `config.py`. Все критерии приёмки (AC-T1…AC-T6, AC-1…AC-12) покрыты тестами
-`tests/test_orch020_estimator.py` (TC-01…TC-20).
-
-**Прогон тестов (зелёный):**
-- `tests/test_orch020_estimator.py` + анти-дрейф доков (`test_system_docs`, `test_bundled_setup_doc`,
-  `test_lite_setup_doc`) — **92 passed**.
-- Регрессы интеграционных точек (webhook/plane/config/stage/notif/db/queue/estimator) — **540 passed**.
-
-**Соответствие ТЗ (ось 1) — полное.** FR-T1…FR-T10 реализованы: статус «Оценка» как fail-closed-триггер
-(`_PLANE_NAME_TO_KEY["Оценка"]="estimate"`, отсутствует в `_DEFAULT_STATES`), `handle_estimate`
-(guard-цепочка applies→анти-disruption), прогноз 4 величин + story-points `{1,2,3,5,8}`,
-авто-возврат в Backlog (анти-loop), массовость (N вебхуков), идемпотентный UPSERT по `work_item_id`,
-запись прогноза в `estimate_point` / факта в `point` (не перепутаны, факт не затирает прогноз),
-Telegram-пункт + Plane-коммент, леджер `task_estimates`, опциональные `POST/GET /estimate`, read-only
-блок `estimator` в `GET /queue`.
-
-**Соответствие ADR (ось 2) — полное.** D1–D12 реализованы дословно. Трассировка (ORCH-078): правки
-маркированных блоков (`handle_issue_updated` — семейство STOP/Confirm Deploy; `_PLANE_NAME_TO_KEY`;
-done-блок `stage_engine` с ORCH-114 lease/merge-lease-release) **аддитивны** и не ломают
-зафиксированных инвариантов — ветка `estimate` стоит после `stop`, взаимоисключение жестов держится
-различием UUID (проверено TC-02b), done-врезка идёт в своём `try/except` ПОСЛЕ решения о переходе.
-
-**Качество кода (ось 3) — высокое.** never-raise-контракт выдержан во всех публичных функциях и
-врезках; leaf не импортирует `stage_engine`/`launcher` на загрузке (TC-20). Сверено по коду:
-колонки `agent_runs` (`input_tokens`/`output_tokens`/`cache_read_tokens`/`cache_creation_tokens`),
-используемые `completed_task_stats`, существуют; `add_comment(..., author=)` — корректная сигнатура;
-базис токенов прогноза (`completed_task_stats`) и факта (`task_usage_summary.total_in+total_out`)
-**консистентен** (оба = input+cache_read+cache_creation+output) → дельта прогноз↔факт осмысленна.
-
-**Документация (ось 4, приоритет) — обновлена в том же PR.** `src/` изменён И документация обновлена:
-инженерный справочник, ADR (work-item + сквозной adr-0054), CHANGELOG, README (env-таблица), онбординг/
-Lite/Bundled-доки + анти-дрейф тесты, **и бизнес-витрина `docs/overview/` (ORCH-011)** — устранён
-блокер предыдущего ревью (run_id=800).
-
-**Control-path не тронут (AC-10 подтверждён):** `git diff` не затрагивает `src/stages.py` и
-`src/qg/checks.py`; `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схемы
-существующих таблиц — байт-в-байт; `task_estimates` — единственный аддитивный объект
-(`CREATE TABLE/INDEX IF NOT EXISTS`).
-
-> **Контекст вердикта.** Предыдущее ревью (run_id=800) вынесло `REQUEST_CHANGES` c единственным P1 —
-> витрина `docs/overview/` не отражала новую операторскую способность «Оценка». Блокер **устранён**
-> коммитом `375bd46 docs(overview): отразить операторскую способность «Оценка» в витрине (ORCH-020)`;
-> попутно ужесточена тавтологичная строка TC-20 (бывший P3). Оставшихся P0/P1 нет → `APPROVED`.
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет — предыдущий P1 «витрина `docs/overview/` не обновлена» закрыт коммитом `375bd46`; см.
-  раздел «Документация»)
-
-### P2 — Should fix
-- (нет)
-
-### P3 — Nice-to-have
-- [ ] `src/plane_sync.py::_patch_issue_fields` — PATCH полей issue (`point`/`estimate_point`) проходит
-  guard ORCH-117 с меткой `plane_write_guard.OP_STATE`, хотя это не смена state. Функционально
-  безопасно (решение guard'а зависит от sandbox/prod-проекта, не от op-метки; op влияет лишь на
-  аудит-лог), но метка семантически неточна. Опционально — ввести/использовать op-константу для
-  field-PATCH ради точности аудит-лога. **Не блокирует.**
-
-## Документация
-
-**Обновлено в PR (корректно, golden source наравне с кодом):**
-- `docs/architecture/README.md` — новый компонент «Task estimator», секция «Оценка задачи (ORCH-020)»,
-  таблица `task_estimates` в data-model, эндпоинты `POST/GET /estimate`, блок `estimator` в `GET /queue`,
-  статусная модель.
-- ADR: `docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md` + сквозной
-  `docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`.
-- `CHANGELOG.md` (`[Unreleased]`), `README.md` (env-таблица `ORCH_ESTIMATOR_*`, 9 ключей).
-- `docs/operations/ONBOARDING.md`, `docs/deployment/LITE_SETUP.md`, `docs/deployment/BUNDLED_SETUP.md`
-  + анти-дрейф тесты (22→23 статуса, сверка импортом `_PLANE_NAME_TO_KEY`); `scripts/onboard_project.py`
-  — 23-й статус «Оценка» (группа `unstarted`, не терминальная — корректно, иначе ложно сработал бы
-  терминал-детект ORCH-068).
-- **Бизнес-витрина `docs/overview/` (ORCH-011) — обновлена в этом же PR (закрытие P1 прошлого ревью):**
-  `business.md` (способность «Оценка задачи до запуска» + сценарий 7), `presentation.md`
-  (исправлено «управляющих статусов ровно три» → жесты + оценка; добавлены жест и сценарий),
-  `tech-pipeline.md` (новая секция «Оценка задачи» + исправление статусной модели), `tech-integrations.md`
-  (исправлено «три управляющих статуса»), `tech-observability.md` (пункт «Оценка» в карточке + блок
-  `estimator` в `GET /queue`), `tech-data-model.md` (таблица `task_estimates`). Машинные факты витрины
-  (`tests/test_system_docs.py`) — зелёные.
-
-**Требует обновления:** нет (документация полна и консистентна реализации).

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

@@ -1,41 +0,0 @@
----
-result: PASS
-work_item: ORCH-020
-stage: testing
-author_agent: test-runner
-status: success
-created_at: 2026-06-17
-model_used: n/a
-exit_code: 0
-smoke: ok
----
-
-# Test Gate Log (deterministic runner, ORCH-116)
-
-pytest exit-code `0` -> `result: PASS` (smoke: ok).
-
-Вердикт зафиксирован детерминированным test-раннером (ORCH-116), не LLM. PASS/FAIL = exit-код `pytest` + read-only smoke (`/health`, `/status`, `/queue` + блок `serial_gate`).
-
-pytest stdout (tail):
-```
-%]
-........................................................................ [ 67%]
-........................................................................ [ 70%]
-........................................................................ [ 73%]
-........................................................................ [ 76%]
-........................................................................ [ 80%]
-........................................................................ [ 83%]
-........................................................................ [ 86%]
-........................................................................ [ 89%]
-........................................................................ [ 92%]
-........................................................................ [ 96%]
-........................................................................ [ 99%]
-................                                                         [100%]
-=============================== warnings summary ===============================
-src/config.py:8
-  /repos/_wt/orchestrator/feature_ORCH-020-/src/config.py:8: PydanticDeprecatedSince20: Support for class-based `config` is deprecated, use ConfigDict instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.13/migration/
-    class Settings(BaseSettings):
-
--- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
-2248 passed, 1 warning in 116.06s (0:01:56)
-```

docs/work-items/ORCH-020/15-staging-log.md

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-020
-stage: deploy-staging
-author_agent: staging-runner
-status: success
-created_at: 2026-06-17
-model_used: n/a
-exit_code: 0
-base_url: http://localhost:8501
----
-
-# Staging Gate Log (deterministic runner, ORCH-115)
-
-Staging suite exit-code `0` -> `staging_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным staging-раннером (ORCH-115), не LLM. infra-tolerance (ORCH-061) уже учтена внутри `staging_check.py` — раннер её не пересуживает.
-
-INFRA-WAIVED lines (ORCH-061, copied for observability):
-- INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-
-Staging suite stdout (tail):
-```
- (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ✗ FAIL  C9b Analyst job enqueued in staging queue
-
-[CLEANUP]
-  ·      CLEANUP: no branch to delete
-  ✓ PASS  CLEANUP: deleted Plane issue df2396e6-fec8-403a-9fa5-9587d0c8465d (HTTP 204)
-  ·      CLEANUP DB: no task row found for plane_id=df2396e6-fec8-403a-9fa5-9587d0c8465d
-  ·      CLEANUP DB dedup: no such table: events_dedup
-
-============================================================
-  RESULT: 8/10 checks PASS
-  REAL failed         : none
-  SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
-============================================================
-  ·      tolerance: staging_infra_tolerance_enabled=True
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-```

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

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

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

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

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

@@ -1,7 +0,0 @@
-# Business Request: FAQ: как использовать STOP для отмены задачи
-
-Work Item ID: ORCH-108
-
-## Description
-
-_(описание отсутствует в источнике)_

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

@@ -1,181 +0,0 @@
----
-work_item: ORCH-108
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-108 — FAQ: как использовать STOP для отмены задачи
-
-Work Item: **ORCH-108** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Тип: документация (пользовательский FAQ). Объём — **только аналитик** (docs-only, без правки `src/**`).
-
----
-
-## 1. Бизнес-контекст и проблема
-
-Механизм отмены задачи через выделенный Plane-статус **STOP** реализован (ORCH-090,
-`docs/architecture/adr/adr-0026-stop-cancel-task.md`): оператор переводит задачу в статус STOP, и
-оркестратор останавливает агента, снимает job'ы с очереди, прибирает ветку/worktree и переводит
-задачу в терминальное состояние `cancelled`. **Но пользовательской документации «как этим
-пользоваться» нет.** Упоминания STOP разрознены и адресованы разным читателям:
-- `docs/overview/business.md` — «Сценарий 6: остановить задачу» (витрина, 1 абзац);
-- `docs/overview/tech-pipeline.md` — «Отмена: STOP → `cancelled`» (инженерный обзор);
-- ADR ORCH-090 — глубокое архитектурное обоснование (не для конечного пользователя).
-
-Пользователь доски Plane (тот, кто заводит/ведёт задачи) не имеет **единой пошаговой инструкции**:
-что именно делает STOP, что происходит с веткой/статусом/уведомлениями, что будет, если нажать STOP
-во время деплоя, откатывается ли уже влитый в `main` код, и как перезапустить отменённую задачу.
-Из-за этого вероятны ошибочные ожидания (например: «STOP откатит мой код из прода» — **неверно**) и
-лишние обращения к оператору.
-
-**Боль/риск, который закрываем:** отсутствие самодостаточного FAQ → неверная ментальная модель STOP
-→ ошибочные действия на проде (self-hosting: один инстанс обслуживает все проекты) и нагрузка на
-оператора.
-
-**Установленные факты (сверено по коду, не изобретать):**
-- Маршрут STOP: `src/webhooks/plane.py::handle_issue_updated` распознаёт логический ключ `stop`
-  (fail-closed: на доске без статуса STOP ветка не активируется) → `handle_stop` →
-  `src/stage_engine.py::cancel_task`.
-- `cancel_task` (сверено, `src/stage_engine.py:2443`):
-  1. **Идемпотентно** — отсутствующая или уже терминальная (`done`/`cancelled`) задача → no-op.
-  2. **Критичное окно** (`src/cancel.py::in_critical_window`) — задача в необратимой фазе
-     merge/deploy → **отложенная отмена** (`cancel_requested_at`, снимаются только `queued`-job'ы,
-     алерт «⏸️ … отложена»; finalizer применяет отмену после честного завершения шага). STOP
-     **никогда** не трогает `main`, не делает force-push, не рестартит прод-контейнер.
-  3. **Полный сброс** (вне критичного окна) — SIGTERM агента (graceful-каскад), все job'ы →
-     терминальный `cancelled`, очистка deploy-state + освобождение merge-lease, снятие worktree,
-     удаление **рабочей** Gitea-ветки (**не** `main`, без force-push), тумбстон натуральных ключей +
-     `stage='cancelled'`. **Docs-артефакты сохраняются.**
-  4. **Наблюдаемость** — Telegram «🛑 … задача ОТМЕНЕНА (STOP)» + Plane-комментарий + обновление
-     карточки.
-- **Перезапуск с нуля** — только «To Analyse» (тумбстон ключей → `get_task_by_plane_id` вернёт
-  `None` → создаётся свежая задача от актуального `origin/main`). Релонч середины пайплайна закрыт:
-  «To Analyse» на существующей не-`analysis` задаче → no-op + подсказка «STOP → To Analyse».
-- **Простой на `deploy` в ожидании `Confirm Deploy`** (lease держится, но актор не бежит) — **не**
-  критичен → немедленный полный сброс (ORCH-090 review P1).
-- Конфиг: `stop_status_enabled` (kill-switch), `stop_status_repos` (CSV; пусто → все репо). При
-  выключенном флаге / отсутствии статуса STOP — fail-safe no-op.
-- Наблюдаемость для оператора: read-only блок `stop` в `GET /queue` (`src/cancel.py::snapshot`):
-  `enabled`/`repos`/счётчик `cancelled`/`deferred_pending`/последние отмены.
-
-> **Уточнение к формулировке бизнес-запроса.** В описании сказано: «орк запускает cancel_request,
-> откат, затем cancelled». Здесь «откат» = **сброс прогресса задачи** (снятие job'ов, удаление
-> рабочей ветки/worktree, возврат задачи в терминал `cancelled`), а **НЕ** git-revert уже влитого в
-> `main` кода. `cancel_request` — это путь **отложенной** отмены в критичном окне
-> (`cancel_requested_at`), он срабатывает **не всегда**, а только если STOP пришёл во время
-> необратимого шага. FAQ обязан развести эти понятия явно (см. BR-4, BR-5).
-
----
-
-## 2. Объём (scope)
-
-### В объёме
-- Создать **пользовательский FAQ** о статусе STOP — единый, самодостаточный, пошаговый документ для
-  пользователя доски Plane.
-- FAQ покрывает: назначение STOP; как отменить задачу; что происходит пошагово (агент, job'ы,
-  ветка/worktree, статус, уведомления); поведение в критичном окне merge/deploy (отложенная отмена);
-  явный ответ «STOP не откатывает влитый в `main` код»; как перезапустить отменённую задачу
-  («To Analyse»); идемпотентность повторного STOP; что делать, если STOP «не сработал»
-  (инфра-предусловие — статус STOP на доске, kill-switch); где увидеть результат (Telegram /
-  Plane-комментарий / `GET /queue`).
-- Перекрёстные ссылки между новым FAQ и существующими упоминаниями STOP (витрина / инженерный
-  обзор), без дублирования источника истины.
-
-### Вне объёма
-- Любые изменения кода `src/**`, поведения STOP, `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схемы БД.
-  Это **docs-only** задача; функциональность STOP уже реализована (ORCH-090) и не меняется.
-- Изменение архитектуры/механики отмены, добавление новых статусов/эндпоинтов.
-- Перевод FAQ на другие языки, видео/скриншоты-гайды.
-- Документирование смежных гейтов (Confirm Deploy / Approved) сверх ссылки-разграничения «STOP ≠
-  Confirm Deploy».
-
----
-
-## 3. Заинтересованные стороны
-- **Заказчик:** владелец продукта (нужен понятный пользовательский FAQ по STOP).
-- **Затрагивает:** пользователей доски Plane (заводят/ведут/отменяют задачи), оператора
-  (меньше обращений), будущих внешних операторов Lite/Bundled-тиража.
-- **Принимает результат:** reviewer (стадия `review`) — проверяет наличие, полноту и фактическую
-  корректность FAQ против кода.
-
----
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 — Единый пользовательский FAQ.** Существует один самодостаточный документ-FAQ о статусе
-  STOP, написанный для пользователя доски Plane (не для разработчика), в формате «вопрос → ответ».
-- **BR-2 — Пошаговая инструкция отмены.** FAQ объясняет, как отменить задачу (перевести issue в
-  статус STOP на доске) и что для этого нужно (статус STOP должен существовать на доске).
-- **BR-3 — Что происходит при STOP.** FAQ описывает наблюдаемые пользователем последствия: агент
-  останавливается, job'ы снимаются, рабочая ветка/worktree удаляются, задача переходит в
-  `cancelled`, приходит уведомление в Telegram и комментарий в Plane; **docs-артефакты задачи
-  сохраняются**.
-- **BR-4 — Отложенная отмена в критичном окне.** FAQ объясняет: если STOP нажат во время
-  необратимого шага (слияние/выкладка), отмена **откладывается** до честного завершения шага;
-  `main`/прод при этом не трогаются.
-- **BR-5 — STOP ≠ откат прод-кода.** FAQ содержит **явный** ответ: STOP сбрасывает незавершённый
-  прогресс задачи, но **не откатывает** код, уже влитый в `main`/прод (revert — отдельная задача).
-- **BR-6 — Перезапуск отменённой задачи.** FAQ объясняет: отменённую задачу нельзя «продолжить с
-  середины»; перезапуск — только «To Analyse», который создаёт задачу **с нуля** (новая ветка от
-  актуального `main`).
-- **BR-7 — Идемпотентность и «не сработало».** FAQ объясняет: повторный STOP по уже отменённой/
-  завершённой задаче безопасен (no-op); если STOP «ничего не сделал» — вероятные причины (статус
-  STOP не заведён на доске / задача уже терминальна / отмена отключена для репо).
-- **BR-8 — Где увидеть результат.** FAQ указывает источники подтверждения отмены: карточка
-  Telegram, комментарий в Plane, read-only блок `stop` в `GET /queue`.
-- **BR-9 — Согласованность с витриной.** FAQ не противоречит существующим упоминаниям STOP в
-  `docs/overview/business.md` и `docs/overview/tech-pipeline.md`; ссылки связывают их без
-  дублирования источника истины.
-
----
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — Docs-only, нулевой рантайм-риск.** Никаких изменений `src/**`, конвейера, гейтов, схемы
-  БД. Self-hosting-безопасно: задача не деплоит/не рестартит прод/не трогает `main`.
-- **NFR-2 — Фактическая точность.** Каждое утверждение FAQ verifiable против кода (`src/cancel.py`,
-  `src/stage_engine.py::cancel_task`, `src/webhooks/plane.py`, `src/config.py`). Запрещены неверные
-  обещания (например «STOP откатит прод»).
-- **NFR-3 — Язык и аудитория.** Русский, тон — пользовательский (без требования читать код/ADR);
-  термины пайплайна поясняются простыми словами.
-- **NFR-4 — Сопровождаемость / анти-дрейф.** Структуру FAQ закрывает детерминированный структурный
-  тест (без сети/LLM/subprocess), по образцу `tests/test_lite_setup_doc.py`, чтобы будущие правки не
-  «отклеивали» FAQ от фактов.
-- **NFR-5 — Без форка источника истины.** FAQ ссылается на канон (ADR ORCH-090, инженерный обзор), а
-  не копирует его дословно; машинные детали — ссылками.
-
----
-
-## 6. Допущения и ограничения
-
-- **Допущение A1 (размещение).** FAQ размещается как новый документ `docs/operations/FAQ_STOP.md`
-  (раздел эксплуатации/операторских runbook'ов — там же `ONBOARDING.md`, `PHANTOM_MERGE_RUNBOOK.md`).
-  Это **разумный дефолт** исходя из аудитории «оператор/пользователь доски»; точное имя/раздел
-  reviewer/architect может скорректировать, но это не блокирует анализ (не сигнальный вопрос).
-- **Допущение A2 (язык).** Русский — основной язык пользовательской документации проекта
-  (соответствует `docs/overview/*`).
-- **Ограничение C1.** Поведение STOP фиксировано ORCH-090; FAQ его **документирует**, а не меняет.
-  Если по ходу обнаружится расхождение «доки vs код» — это дефект, заводится отдельно (правило
-  агентов №4: не комментировать ТЗ задним числом, возвращать в анализ).
-- **Ограничение C2.** Никаких блокирующих неоднозначностей не выявлено → файл `01-questions.md`
-  **не создаётся** (ORCH-120): сделанных допущений (A1/A2) достаточно для корректного пакета.
-
----
-
-## 7. Критерии успеха
-
-Документ-FAQ создан, покрывает все темы BR-1…BR-9, фактически согласован с кодом, перекрёстно связан
-с витриной, и закрыт структурным анти-дрейф тестом. Полный регресс `tests/` остаётся зелёным.
-Детальные PASS/FAIL — в `03-acceptance-criteria.md`.
-
-## 8. Риски
-
-- **R1 — Дрейф «доки ↔ код».** Будущая правка STOP сделает FAQ неверным. Митигейшн — структурный
-  тест (NFR-4) + правило «правишь STOP → обнови FAQ в том же PR».
-- **R2 — Ошибочное размещение/дубль.** FAQ продублирует витрину вместо ссылки. Митигейшн — BR-9 +
-  AC на перекрёстные ссылки.
-- Детали/полный перечень — `10-tech-risks.md` (заполняет архитектор; для docs-only задачи риски
-  минимальны).

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

@@ -1,189 +0,0 @@
----
-work_item: ORCH-108
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-108 — FAQ: как использовать STOP для отмены задачи
-
-Work Item: **ORCH-108** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Это **docs-only** задача: код `src/**` и поведение STOP не меняются. Источник истины поведения —
-> ORCH-090 (`adr-0026`); здесь — требования к **документации** этого поведения.
-> Архитектурное обоснование (если потребуется) — задача архитектора (`06-adr`).
-
-## 1. Сводка изменения
-
-Создать пользовательский **FAQ по статусу STOP** — новый Markdown-документ
-`docs/operations/FAQ_STOP.md` в формате «вопрос → ответ», для пользователя доски Plane. Добавить
-перекрёстные ссылки из существующих упоминаний STOP (витрина / инженерный обзор) на FAQ. Закрыть
-структуру FAQ детерминированным анти-дрейф тестом. **Никаких изменений `src/**`, конвейера, гейтов,
-схемы БД, API.** Полный черновик содержания FAQ — в Приложении A (готов к переносу разработчиком;
-объём «только аналитик» → существенное наполнение сделано на стадии анализа).
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `docs/operations/FAQ_STOP.md` | **создать** — пользовательский FAQ по STOP (основной deliverable; содержание — Приложение A) |
-| `docs/overview/business.md` | изменить — добавить ссылку «Подробнее: FAQ по STOP» в «Сценарий 6: остановить задачу» |
-| `docs/overview/tech-pipeline.md` | изменить — добавить ссылку на FAQ в раздел «Отмена: STOP → `cancelled`» |
-| `CHANGELOG.md` | изменить — запись `docs: ORCH-108 FAQ по статусу STOP` |
-| `tests/test_faq_stop_doc.py` | **создать** — структурный анти-дрейф тест FAQ (образец `tests/test_lite_setup_doc.py`) |
-
-**Описываемые (read-only) модули — FAQ их излагает, НЕ меняет** (для верификации фактов reviewer'ом):
-- `src/webhooks/plane.py` — `handle_issue_updated` (распознавание ключа `stop`, fail-closed),
-  `handle_stop` (делегирование в `cancel_task`), `handle_status_start` (гейт релонча: «To Analyse»
-  перезапускает только с нуля, не середину пайплайна).
-- `src/stage_engine.py::cancel_task` — оркестрация отмены (идемпотентность / критичное окно /
-  полный сброс / наблюдаемость).
-- `src/cancel.py` — `applies` (kill-switch + repo-scope), `in_critical_window` (классификация
-  необратимого окна), `snapshot` (блок `stop` в `GET /queue`).
-- `src/config.py` — `stop_status_enabled` (env `ORCH_STOP_STATUS_ENABLED`), `stop_status_repos`
-  (env `ORCH_STOP_STATUS_REPOS`, CSV; пусто → все репо).
-- `src/main.py` — read-only блок `stop` в `GET /queue`.
-
-## 3. Функциональные требования
-
-### FR-1 — Документ FAQ существует и адресован пользователю (BR-1)
-Создать `docs/operations/FAQ_STOP.md`: H1-заголовок про STOP, вводный абзац «для кого/зачем», далее
-секции «вопрос → ответ». Тон — пользовательский (без требования читать код). Язык — русский.
-
-### FR-2 — Обязательные секции FAQ (BR-2…BR-8)
-FAQ содержит как минимум следующие тематические секции (заголовки — стабильные якоря для теста
-NFR-4 / TC-02), каждая отвечает на свой вопрос:
-1. **«Что делает статус STOP?»** — назначение: отмена + сброс прогресса задачи.
-2. **«Как отменить задачу?»** — перевести issue в статус **STOP** на доске Plane; предусловие —
-   статус STOP заведён на доске.
-3. **«Что происходит, когда я нажимаю STOP?»** — пошагово: агент останавливается → job'ы снимаются
-   → рабочая ветка и worktree удаляются → задача переходит в `cancelled` → приходит уведомление в
-   Telegram и комментарий в Plane. **Docs-артефакты задачи сохраняются.**
-4. **«Что если задача в этот момент сливается или деплоится?»** — отложенная отмена: отмена
-   откладывается до честного завершения необратимого шага; `main`/прод не трогаются.
-5. **«Откатит ли STOP уже выложенный код?»** — **Нет.** STOP сбрасывает незавершённый прогресс
-   задачи, но не делает git-revert уже влитого в `main`/прод кода (это отдельная задача).
-6. **«Как перезапустить отменённую задачу?»** — только через «To Analyse»; задача создаётся **с
-   нуля** (новая ветка от актуального `main`); «продолжить с середины» нельзя.
-7. **«Я нажал STOP, но ничего не произошло — почему?»** — вероятные причины: статус STOP не заведён
-   на доске (fail-closed no-op); задача уже завершена/отменена (идемпотентный no-op); отмена
-   отключена для репозитория (`stop_status_enabled`/`stop_status_repos`).
-8. **«Где увидеть, что задача отменена?»** — карточка Telegram («🛑 … ОТМЕНЕНА (STOP)»), комментарий
-   в Plane, read-only блок `stop` в `GET /queue`.
-
-### FR-3 — Разграничение STOP ↔ другие управляющие статусы (BR-9)
-FAQ кратко разграничивает STOP и человеческие гейты `Approved`/`Confirm Deploy` (STOP — отмена, не
-одобрение/деплой), ссылкой на инженерный обзор, без переписывания их семантики.
-
-### FR-4 — Перекрёстные ссылки без дублирования (BR-9, NFR-5)
-- В `docs/overview/business.md` («Сценарий 6») и `docs/overview/tech-pipeline.md` («Отмена: STOP →
-  `cancelled`») добавить ссылку на `FAQ_STOP.md`.
-- В FAQ — обратные ссылки на инженерный обзор и ADR ORCH-090 как на источник истины поведения.
-- **Не дублировать** машинные детали (маркеры/lease/тумбстон) — давать ссылками.
-
-### FR-5 — Фактическая корректность (NFR-2)
-Каждое утверждение FAQ соответствует коду на момент написания (см. §2 read-only модули). Запрещены
-утверждения, противоречащие коду — в частности: «STOP откатывает прод», «STOP трогает `main`/делает
-force-push», «отменённую задачу можно продолжить с середины», «STOP мгновенно убивает идущий
-деплой».
-
-### FR-6 — Анти-дрейф тест (NFR-4)
-Создать `tests/test_faq_stop_doc.py` (детерминированный, без сети/LLM/subprocess; только парсинг
-файла): FAQ существует; присутствуют все обязательные секции-якоря (FR-2); присутствуют ключевые
-факты-«кирпичи» (STOP, `cancelled`, «To Analyse», «main … не», отложенная/deferred); присутствуют
-перекрёстные ссылки (FR-4); отсутствуют запрещённые неверные утверждения (FR-5, негативный скан).
-
-## 4. Изменения API
-Нет. (FAQ лишь упоминает существующий read-only `GET /queue` блок `stop`.)
-
-## 5. Изменения схемы БД
-Нет.
-
-## 6. Требования к новым/изменённым QG checks
-Нет. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict — не затрагиваются.
-Замечание по coverage-гейту (ORCH-027): docs-only изменение не добавляет строк `src/` → базовая
-линия покрытия не меняется; новый `tests/test_faq_stop_doc.py` не покрывает `src/` (структурный
-тест документа) и на метрику не влияет.
-
-## 7. Совместимость / регресс
-- **Обратная совместимость — полная.** Только добавление/правка docs + новый структурный тест.
-  Поведение рантайма байт-в-байт прежнее; kill-switch не требуется (нет исполняемого кода).
-- **Self-hosting-безопасно.** Не деплоит/не рестартит прод/не трогает `main`; реальный прод-деплой
-  этой задачи безопасен (docs).
-- **Регресс.** Полный `tests/` остаётся зелёным; новый тест читает только файл FAQ.
-- **Сопровождение (норматив).** Правишь поведение STOP (`src/cancel.py`/`cancel_task`/маршрут
-  `stop`) → обнови `docs/operations/FAQ_STOP.md` в том же PR (правило агентов №2 / №6: reviewer
-  требует обновлённую доку).
-
----
-
-## Приложение A — Черновик содержания FAQ (готов к переносу в `docs/operations/FAQ_STOP.md`)
-
-> Нормативный ориентир содержания (объём «только аналитик»). Разработчик переносит как тело
-> документа; точные формулировки можно полировать, фактическую часть менять нельзя без возврата в
-> анализ (правило №4).
-
-```markdown
-# FAQ: отмена задачи через статус STOP
-
-Эта страница — для пользователя доски Plane. Она объясняет, что делает статус **STOP**, как им
-безопасно остановить задачу и чего от него ждать. Технические детали механизма — в
-[инженерном обзоре](../overview/tech-pipeline.md#отмена-stop--cancelled) и
-[ADR ORCH-090](../work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md).
-
-## Что делает статус STOP?
-STOP — это «кнопка отмены» задачи. Перевод задачи в статус STOP останавливает работу агента, снимает
-задачу с очереди, прибирает рабочие материалы (ветку и worktree) и помечает задачу отменённой
-(`cancelled`). Безопасно нажимать даже посреди конвейера.
-
-## Как отменить задачу?
-Переведите issue в статус **STOP** на доске Plane — так же, как меняете любой другой статус.
-Предусловие: на доске должен быть заведён статус **STOP** (группа `cancelled`). Если его нет, STOP
-не сработает (см. «ничего не произошло»).
-
-## Что происходит, когда я нажимаю STOP?
-По шагам:
-1. Активный агент останавливается (мягкая остановка процесса).
-2. Все задачи в очереди по этой задаче снимаются и больше не перезапускаются.
-3. Рабочая ветка задачи и её worktree удаляются. **Ветка `main` и прод никогда не трогаются.**
-4. Задача переходит в терминальное состояние `cancelled`.
-5. Приходит уведомление в Telegram («🛑 … задача ОТМЕНЕНА (STOP)») и комментарий в Plane.
-
-**Документы задачи (анализ, ТЗ и т.д.) сохраняются** — удаляются только рабочая ветка и worktree.
-
-## Что если задача в этот момент сливается или деплоится?
-Если STOP пришёл во время необратимого шага (слияние в `main` или выкладка), отмена **аккуратно
-откладывается** до честного завершения этого шага. Вы увидите уведомление «⏸️ … отмена отложена».
-`main` и прод при этом не трогаются; после завершения шага отмена применяется автоматически.
-
-## Откатит ли STOP уже выложенный код?
-**Нет.** STOP сбрасывает **незавершённый прогресс** задачи (ветку/worktree/очередь), но **не
-откатывает** код, который уже влит в `main` или выложен в прод. Откат выложенного — это отдельная
-задача (revert), STOP её не делает.
-
-## Как перезапустить отменённую задачу?
-Отменённую задачу нельзя «продолжить с середины». Чтобы начать заново, переведите её в статус
-**«To Analyse»** — задача будет создана **с нуля** (новая ветка от актуального `main`, новый анализ).
-
-## Я нажал STOP, но ничего не произошло — почему?
-Вероятные причины:
-- На доске **нет статуса STOP** — переход не распознаётся (безопасный no-op). Заведите статус STOP
-  (группа `cancelled`).
-- Задача **уже завершена или уже отменена** — повторный STOP ничего не меняет (это нормально).
-- Отмена **отключена для репозитория** настройкой (`stop_status_enabled` / `stop_status_repos`) —
-  обратитесь к оператору.
-
-## Где увидеть, что задача отменена?
-- Карточка задачи в **Telegram** покажет «🛑 … ОТМЕНЕНА (STOP)».
-- В **Plane** появится комментарий об отмене.
-- Оператор может увидеть отмену в служебной странице состояния `GET /queue` (блок `stop`).
-
-## STOP, Approved и Confirm Deploy — в чём разница?
-- **STOP** — отменить задачу.
-- **Approved** — одобрить артефакт анализа (двигает задачу дальше), деплой не запускает.
-- **Confirm Deploy** — подтвердить прод-выкладку.
-Подробнее об управляющих статусах — в [инженерном обзоре](../overview/tech-pipeline.md).
-```

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

@@ -1,141 +0,0 @@
----
-work_item: ORCH-108
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-108 — FAQ: как использовать STOP
-
-Work Item: **ORCH-108** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
-считается провалом). Reviewer проверяет их буквально по файлам репозитория.
-
----
-
-## AC-1 — FAQ-документ существует и адресован пользователю
-
-**Условие:** создан `docs/operations/FAQ_STOP.md` в формате «вопрос → ответ» для пользователя Plane.
-- **PASS:** файл существует; есть H1 про STOP и вводный абзац «для кого/зачем»; тон
-  пользовательский (не требует чтения кода); язык русский.
-- **FAIL:** файла нет; либо это разработческий/архитектурный текст, а не пользовательский FAQ; либо
-  нет формата «вопрос → ответ».
-
----
-
-## AC-2 — Покрыты все обязательные темы
-
-**Условие:** FAQ содержит секции, отвечающие на 8 обязательных вопросов TRZ §FR-2.
-- **PASS:** присутствуют все темы — (1) что делает STOP; (2) как отменить; (3) что происходит
-  пошагово; (4) отложенная отмена в критичном окне; (5) STOP не откатывает прод-код; (6) перезапуск
-  через «To Analyse» с нуля; (7) «ничего не произошло — почему»; (8) где увидеть результат.
-- **FAIL:** отсутствует хотя бы одна из тем (1)–(8).
-
----
-
-## AC-3 — Пошаговые последствия STOP описаны верно
-
-**Условие:** тема (3) перечисляет наблюдаемые последствия согласно `cancel_task`.
-- **PASS:** перечислены — остановка агента; снятие job'ов; удаление рабочей ветки и worktree; явное
-  «`main`/прод не трогаются»; переход в `cancelled`; уведомление Telegram + комментарий Plane; явное
-  «docs-артефакты сохраняются».
-- **FAIL:** пропущен или искажён любой из этих пунктов (например утверждается, что удаляются docs,
-  или что трогается `main`).
-
----
-
-## AC-4 — Отложенная отмена в критичном окне
-
-**Условие:** тема (4) корректно описывает поведение при STOP во время merge/deploy.
-- **PASS:** сказано, что отмена **откладывается** до честного завершения необратимого шага; что
-  `main`/прод не трогаются; что после завершения шага отмена применяется.
-- **FAIL:** утверждается мгновенное прерывание деплоя/слияния, либо что STOP убивает идущий
-  необратимый шаг, либо тема отсутствует.
-
----
-
-## AC-5 — STOP ≠ откат прод-кода (явный ответ)
-
-**Условие:** тема (5) явно разводит «сброс прогресса» и «revert выложенного».
-- **PASS:** есть явное «Нет»: STOP **не откатывает** код, уже влитый в `main`/прод; revert — отдельная
-  задача.
-- **FAIL:** FAQ обещает/намекает, что STOP откатит прод-код, либо тема отсутствует.
-
----
-
-## AC-6 — Перезапуск отменённой задачи
-
-**Условие:** тема (6) описывает перезапуск.
-- **PASS:** сказано, что перезапуск — только «To Analyse»; задача создаётся **с нуля** (новая ветка
-  от актуального `main`); «продолжить с середины» нельзя.
-- **FAIL:** утверждается возможность продолжить отменённую задачу с середины, либо неверный
-  механизм перезапуска, либо тема отсутствует.
-
----
-
-## AC-7 — «Не сработало» и идемпотентность
-
-**Условие:** тема (7) перечисляет причины no-op.
-- **PASS:** перечислены — статус STOP не заведён на доске (fail-closed); задача уже терминальна
-  (идемпотентный no-op); отмена отключена для репо (`stop_status_enabled`/`stop_status_repos`).
-- **FAIL:** причины не описаны или описаны неверно (например, утверждается, что повторный STOP
-  ломает задачу).
-
----
-
-## AC-8 — Перекрёстные ссылки без дублирования
-
-**Условие:** FAQ связан с витриной/обзором двусторонними ссылками (TRZ §FR-4).
-- **PASS:** `docs/overview/business.md` («Сценарий 6») и `docs/overview/tech-pipeline.md` («Отмена:
-  STOP → `cancelled`») содержат ссылку на `FAQ_STOP.md`; FAQ ссылается на инженерный обзор и ADR
-  ORCH-090 как на источник истины; машинные детали не дублируются, а даются ссылками.
-- **FAIL:** ссылок нет (FAQ-«сирота»); либо FAQ дословно копирует ADR/обзор вместо ссылки.
-
----
-
-## AC-9 — Фактическая корректность (нет ложных утверждений)
-
-**Условие:** утверждения FAQ соответствуют коду (`src/cancel.py`, `src/stage_engine.py::cancel_task`,
-`src/webhooks/plane.py`, `src/config.py`); запрещённых неверных утверждений нет.
-- **PASS:** в FAQ отсутствуют утверждения «STOP трогает `main`/делает force-push», «STOP откатывает
-  прод», «отменённую задачу можно продолжить с середины», «STOP мгновенно убивает идущий деплой».
-- **FAIL:** присутствует хотя бы одно противоречащее коду утверждение.
-
----
-
-## AC-10 — Docs-only, нулевой рантайм-регресс
-
-**Условие:** изменения ограничены документацией + структурным тестом.
-- **PASS:** `git diff` не затрагивает `src/**`, `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схему БД;
-  изменены только `docs/**`, `CHANGELOG.md`, `tests/test_faq_stop_doc.py`; полный `tests/` зелёный.
-- **FAIL:** затронут `src/**` или поведение гейтов/конвейера; либо регресс `tests/` красный.
-
----
-
-## AC-11 — Анти-дрейф тест присутствует и зелёный
-
-**Условие:** структурную целостность FAQ закрывает детерминированный тест (TRZ §FR-6).
-- **PASS:** `tests/test_faq_stop_doc.py` существует; проверяет наличие файла, обязательных
-  секций-якорей, ключевых фактов-«кирпичей», перекрёстных ссылок и отсутствие запрещённых
-  утверждений; не делает сети/LLM/subprocess; проходит зелёным.
-- **FAIL:** теста нет; либо он не детерминирован (сеть/LLM/subprocess); либо красный.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2…BR-8 / FR-2 |
-| AC-3 | BR-3 / FR-2(3) |
-| AC-4 | BR-4 / FR-2(4) |
-| AC-5 | BR-5 / FR-2(5) |
-| AC-6 | BR-6 / FR-2(6) |
-| AC-7 | BR-7 / FR-2(7) |
-| AC-8 | BR-9 / FR-3, FR-4 |
-| AC-9 | NFR-2 / FR-5 |
-| AC-10 | NFR-1 / FR (docs-only), §7 |
-| AC-11 | NFR-4 / FR-6 |

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

@@ -1,74 +0,0 @@
-work_item: ORCH-108
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-title: "Анти-дрейф структурного FAQ по статусу STOP (docs-only)"
-framework: pytest
-scope: >
-  Покрывается СТРУКТУРНАЯ целостность и фактическая непротиворечивость нового
-  пользовательского документа docs/operations/FAQ_STOP.md (детерминированно: только
-  парсинг файлов, без сети/LLM/subprocess; образец tests/test_lite_setup_doc.py).
-  Вне покрытия: поведение STOP в рантайме — оно реализовано и протестировано в
-  ORCH-090 (tests/ по cancel_task/cancel.py), эта задача его НЕ меняет (docs-only).
-notes: >
-  Docs-only задача: src/** не меняется, поэтому юнит/интеграционных тестов кода нет —
-  только структурные тесты документа. Полный регресс tests/ должен оставаться зелёным
-  (новый тест читает лишь файлы docs/, на src/-покрытие/coverage-baseline не влияет).
-  Все тесты — type: unit (без сети/LLM/subprocess), модуль tests/test_faq_stop_doc.py.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "FAQ существует: docs/operations/FAQ_STOP.md присутствует, непустой, есть H1 про STOP и вводный абзац для пользователя (AC-1)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Обязательные секции-якоря присутствуют: все 8 тем FR-2 (что делает STOP / как отменить / пошагово / отложенная отмена / не откатывает прод / перезапуск To Analyse / 'ничего не произошло' / где увидеть) (AC-2)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Пошаговые последствия и сохранность: упомянуты остановка агента, снятие job'ов, удаление рабочей ветки/worktree, переход в cancelled, уведомление Telegram+Plane, явное 'docs сохраняются' (AC-3)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Критичное окно: присутствует факт отложенной отмены (deferred / 'отложена') и явное 'main/прод не трогаются' (AC-4)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "STOP ≠ откат прод-кода: присутствует явный отрицательный ответ ('не откатывает' влитый в main/прод код) (AC-5)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Перезапуск: упомянуто 'To Analyse' и создание задачи 'с нуля', отсутствует обещание 'продолжить с середины' (AC-6)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Негативный скан фактов: в FAQ НЕТ запрещённых утверждений — 'откатит прод', 'трогает main/force-push', 'продолжить отменённую с середины', 'мгновенно убивает деплой' (AC-9)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Перекрёстные ссылки: business.md (Сценарий 6) и tech-pipeline.md (Отмена: STOP → cancelled) содержат ссылку на FAQ_STOP.md; FAQ ссылается на инженерный обзор/ADR ORCH-090 (AC-8)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "Docs-only регресс-инвариант: полный прогон tests/ зелёный; новый тест не импортирует src/ рантайм и не делает сети/subprocess (AC-10, AC-11)."
-    module: tests/test_faq_stop_doc.py
-    expected: PASS

docs/work-items/ORCH-108/06-adr/ADR-001-faq-stop-placement-and-anti-drift.md

@@ -1,173 +0,0 @@
----
-work_item: ORCH-108
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# ADR-001: Размещение пользовательского FAQ по STOP и контур анти-дрейфа
-
-Work Item: **ORCH-108** — FAQ: как использовать статус STOP для отмены задачи
-Стадия: **architecture**
-Сквозная регистрация: **N/A — локальное решение задачи** (docs-only; новых QG/стадий/
-компонентов/таблиц нет, маркеры `ORCH-NNN` в `src/**` не вводятся → сквозной
-`docs/architecture/adr/adr-NNNN-*` не требуется; критерий — `docs/_standards/PIPELINE_DOCS.md` §4).
-
-## Статус
-Proposed
-
-## Контекст
-
-Механизм отмены задачи через Plane-статус **STOP** реализован в ORCH-090
-(`docs/architecture/adr/adr-0026-stop-cancel-task.md`, `src/cancel.py`,
-`src/stage_engine.py::cancel_task`, `src/webhooks/plane.py`). Пользовательской
-инструкции «как этим пользоваться» нет — упоминания STOP разрознены и адресованы разным
-читателям (витрина `docs/overview/business.md` «Сценарий 6», инженерный обзор
-`docs/overview/tech-pipeline.md` «Отмена: STOP → `cancelled`», глубокий ADR ORCH-090). Это
-порождает неверную ментальную модель («STOP откатит мой код из прода» — **неверно**) и нагрузку
-на оператора (self-hosting: один инстанс на все проекты).
-
-Аналитик (BRD/TRZ/AC, `ready-for-review`) полностью описал требуемый артефакт и приложил готовый
-черновик содержания (TRZ Приложение A). Это **docs-only** задача: `src/**`, `STAGE_TRANSITIONS`,
-`QG_CHECKS`, `check_*`, схема БД — не меняются; поведение STOP фиксировано ORCH-090 и FAQ его лишь
-**документирует**. Архитектурных решений по существу два: (1) куда положить FAQ в дереве доков и
-(2) как структурно защитить его от дрейфа «доки ↔ код». Остальное — исполнение на стадии
-development.
-
-Факты, сверенные на ветке задачи (read-only):
-- Цели перекрёстных ссылок **существуют**: `docs/overview/business.md` §«Сценарий 6: остановить
-  задачу» (стр. 96), `docs/overview/tech-pipeline.md` §«Отмена: STOP → `cancelled`» (стр. 122),
-  `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`. Ссылки FR-4 не «висячие».
-- Семантика разделов доков (ORCH-011, `adr-0039`): `overview/` — витрина «что за система»,
-  `architecture/` — инженерный справочник, `deployment/` — «как развернуть у себя»,
-  `operations/` — «как эксплуатировать наш прод» (runbook'и: `ONBOARDING.md`,
-  `PHANTOM_MERGE_RUNBOOK.md`, `STAGING.md`, …).
-- `docs/overview/` — **курируемый плоский каталог из 10 файлов**, чьё содержимое прибито
-  структурным тестом `tests/test_system_docs.py` (витрина — не свалка произвольных доков).
-- Прецедент анти-дрейф теста документа — `tests/test_lite_setup_doc.py` (детерминированный,
-  offline; позитивные якоря-секции + «кирпичи» + кросс-ссылки + негативный скан запрещённых
-  литералов по `FORBIDDEN`).
-
-## Решение
-
-### Сводка
-Размещаем FAQ как **`docs/operations/FAQ_STOP.md`** — пользовательский документ «вопрос → ответ»,
-прилинкованный из витрины/обзора и закрытый детерминированным структурным тестом
-`tests/test_faq_stop_doc.py`. Утверждаем разумный дефолт аналитика (A1) как архитектурное решение,
-с явной фиксацией ключевого нюанса теста — **негативный скан проверяет запрещённые
-утверждения, а не голые подстроки** (иначе он ложно срабатывал бы на предложениях, которые эти же
-термины корректно **отрицают**).
-
-### D1 — Размещение: `docs/operations/FAQ_STOP.md` (BR-1, A1)
-FAQ ложится в `docs/operations/` рядом с операторскими runbook'ами.
-
-Обоснование выбора между тремя кандидатами (аудитория FAQ «пользователь доски + оператор»
-неоднородна, поэтому секция не очевидна):
-- **`docs/overview/` — отвергнуто.** Это курируемая витрина фиксированного состава (10 файлов),
-  защищённая `tests/test_system_docs.py`; добавление отдельного FAQ нарушит инвариант каталога
-  витрины и саму семантику «обзор, а не справочник процедур».
-- **Новый раздел `docs/faq/` — отвергнуто.** Заведение top-level раздела ради одного документа —
-  scope-creep; нет канона/индекса/норматива сопровождения для нового раздела.
-- **`docs/operations/FAQ_STOP.md` — выбрано.** Это де-факто дом человеко-ориентированных процедур
-  и «что делать, если…» (тробл-шутинг STOP в FR-2 п.7 ссылается на `stop_status_enabled`/
-  `stop_status_repos`, а «где увидеть результат» в п.8 — на read-only блок `stop` в `GET /queue`;
-  обе темы — операторская территория). Пользователь доски и оператор на self-hosting сильно
-  пересекаются; именно к operations-доке оператор отсылает пользователя.
-
-Документированная остаточная издержка: лёгкое несоответствие «аудитория-пользователь ↔
-секция-operations». Принимается осознанно (см. «Последствия»); пере-размещение в будущий
-`docs/faq/` остаётся дешёвым (один файл + правка двух ссылок + одного теста).
-
-### D2 — Граница объёма: docs-only, без рантайм-поверхности (NFR-1, AC-10)
-Подтверждаю и фиксирую как архитектурный инвариант:
-- `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД — **не
-  трогаются**; kill-switch не требуется (нет исполняемого кода).
-- **`07-infra-requirements.md` — N/A** (топология/контейнеры/сеть не меняются).
-- **`08-data-requirements.md` — N/A** (таблиц/колонок/индексов не добавляется).
-- `docs/architecture/README.md` / `internals.md` — **не обновляются**: задача не затрагивает
-  стадии/QG/компоненты (новый operations-FAQ описывает уже задокументированную фичу ORCH-090, не
-  вводя архитектурных сущностей). Внесение FAQ в архитектурный справочник было бы дублированием
-  источника истины (нарушение NFR-5).
-- Coverage-гейт (ORCH-027): docs-only не добавляет строк `src/` → базовая линия покрытия не
-  меняется; `tests/test_faq_stop_doc.py` — структурный тест документа, `src/` не покрывает и на
-  метрику не влияет.
-
-### D3 — Контур анти-дрейфа: `tests/test_faq_stop_doc.py`, негативный скан на уровне утверждений (NFR-4, FR-6, AC-11)
-Структурный тест по образцу `tests/test_lite_setup_doc.py` — детерминированный, **без сети/LLM/
-subprocess**, только парсинг файла. Обязательный состав проверок:
-1. **Существование** `docs/operations/FAQ_STOP.md`.
-2. **Позитивные якоря** — все 8 обязательных секций-вопросов TRZ §FR-2 присутствуют (заголовки —
-   стабильные якоря; тест матчит по нормализованному заголовку, не по точной пунктуации).
-3. **«Кирпичи»-факты** — присутствуют ключевые токены (`STOP`, `cancelled`, «To Analyse»,
-   «отлож…»/`deferred`, упоминание `GET /queue`/блока `stop`).
-4. **Кросс-ссылки** (FR-4) — ссылка на `tech-pipeline.md` и на ADR ORCH-090 присутствует.
-5. **Негативный скан (КЛЮЧЕВОЙ нюанс).** Запрещённые **утверждения** FR-5 («STOP откатывает
-   прод», «STOP трогает `main`/force-push», «продолжить с середины», «STOP мгновенно убивает
-   деплой») детектируются как **утверждения целиком**, а **НЕ** как голые подстроки. Причина:
-   корректный FAQ закономерно содержит слова `main`, «откатыва…», «force-push», «деплой» внутри
-   **отрицающих** предложений («STOP **не откатывает** … `main`»). Наивный substring-скан по этим
-   словам ложно завалит именно те фразы, которые требование AC-9 предписывает иметь. Реализация:
-   матчить нормативно-запрещённые фразы (например, утверждение отката прод-кода **без**
-   отрицания рядом), либо проверять, что запрещённый токен встречается только в соседстве с
-   отрицанием. Конкретную форму выбирает разработчик; инвариант — **тест не должен фолзить на
-   фактически верном FAQ** и **обязан краснеть на реально ложном утверждении**.
-
-Контракт теста — никогда не делать сеть/LLM/subprocess (как и эталон), чтобы оставаться частью
-обычного зелёного `tests/` без инфра-зависимостей.
-
-### D4 — Целостность ссылок и link-first (FR-4, NFR-5, AC-8)
-Перекрёстные ссылки добавляются **в обе стороны** (витрина/обзор → FAQ; FAQ → обзор + ADR
-ORCH-090). Источник истины поведения остаётся за ADR ORCH-090 и инженерным обзором — FAQ их
-**не форкает** (машинные детали: маркеры/lease/тумбстон — только ссылками). Цели ссылок
-проверены существующими (см. Контекст). Якорь-слаг на секцию обзора
-(`tech-pipeline.md` «Отмена: STOP → `cancelled`») разработчик обязан сверить с фактической
-генерацией якоря при переносе (риск TR-4).
-
-### D5 — Норматив сопровождения (traceability)
-Фиксируется правило: **правишь поведение STOP** (`src/cancel.py` / `cancel_task` / маршрут `stop`
-в `src/webhooks/plane.py`) → **обнови `docs/operations/FAQ_STOP.md` в том же PR** (правило агентов
-№2/№6; reviewer-ось «документация»). Машинный маркер `ORCH-108` в `src/**` НЕ вводится (docs-only),
-поэтому анти-археологии маркеров (`docs/_standards/TRACEABILITY.md`) этот PR не порождает; связь
-«код STOP ↔ FAQ» держится нормативом сопровождения + структурным тестом D3.
-
-## Альтернативы
-- **FAQ в `docs/overview/`** — отвергнуто: курируемая витрина фиксированного состава под
-  `tests/test_system_docs.py`; FAQ ≠ обзорный слайд (см. D1).
-- **Новый раздел `docs/faq/`** — отвергнуто: scope-creep ради одного файла (см. D1).
-- **Без анти-дрейф теста, полагаясь на reviewer** — отвергнуто: NFR-4 требует структурной
-  защиты от дрейфа «доки ↔ код»; ручная проверка не воспроизводима.
-- **Негативный скан по голым подстрокам** — отвергнуто: ложные срабатывания на корректно
-  отрицающих предложениях (см. D3) — это сделало бы тест либо красным на верном FAQ, либо
-  вынудило бы выкинуть из FAQ обязательные явные отрицания.
-- **Сквозной (global) ADR** — отвергнуто: решение не кросс-каттинговое (нет нового QG/стадии/
-  компонента/таблицы; не меняет канон доков как такой).
-
-## Последствия
-- **+** Единый самодостаточный источник для пользователя доски → меньше неверных ожиданий и
-  обращений к оператору (self-hosting-выгода).
-- **+** Структурный тест (D3) делает дрейф «доки ↔ код» воспроизводимо ловимым; норматив D5
-  закрывает процессный пробел.
-- **+** Нулевой рантайм-риск: docs-only, прод-деплой этой задачи безопасен.
-- **−** Лёгкое несоответствие «пользовательская аудитория ↔ секция operations» (D1). Митигейшн:
-  явный вводный абзац «для кого» в FAQ + дешёвое будущее пере-размещение.
-- **−** Риск чрезмерно строгого негативного скана (D3). Митигейшн: матч на уровне утверждений +
-  явный инвариант «не фолзить на верном FAQ» (TR-3).
-- **Откат:** удалить `docs/operations/FAQ_STOP.md` и `tests/test_faq_stop_doc.py`, снять
-  добавленные ссылки из `business.md`/`tech-pipeline.md` и запись из `CHANGELOG.md`. Рантайм не
-  затрагивается.
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-108/01-brd.md`
-- TRZ: `docs/work-items/ORCH-108/02-trz.md` (+ Приложение A — черновик содержания FAQ)
-- Acceptance: `docs/work-items/ORCH-108/03-acceptance-criteria.md`
-- Tech-risks: `docs/work-items/ORCH-108/10-tech-risks.md`
-- Источник истины поведения STOP: `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`,
-  `docs/architecture/adr/adr-0026-stop-cancel-task.md`
-- Сверено по коду: `src/cancel.py`, `src/stage_engine.py::cancel_task`,
-  `src/webhooks/plane.py` (`handle_issue_updated`/`handle_stop`/`handle_status_start`),
-  `src/config.py` (`stop_status_enabled`/`stop_status_repos`), `src/main.py` (блок `stop` в
-  `GET /queue`)
-- Эталон анти-дрейф теста: `tests/test_lite_setup_doc.py`
-- Семантика разделов доков: `docs/architecture/adr/adr-0039-system-overview-docs-canon.md`

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

@@ -1,39 +0,0 @@
----
-work_item: ORCH-108
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-108 — FAQ по статусу STOP
-
-Work Item: **ORCH-108** · Repo: **orchestrator** (self-hosting) · Стадия: architecture
-
-> Информационный документ (гейтом не парсится). Перечисляет риски реализации **docs-only**
-> задачи и их митигейшн. Класс рисков — минимальный: рантайм/конвейер не затрагиваются.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Дрейф «доки ↔ код».** Будущая правка поведения STOP (`src/cancel.py`/`cancel_task`/маршрут `stop`) сделает FAQ неверным. | Сред. | Сред. | Структурный анти-дрейф тест `tests/test_faq_stop_doc.py` (ADR D3) + норматив сопровождения «правишь STOP → обнови FAQ в том же PR» (ADR D5) + reviewer-ось «документация». |
-| TR-2 | **FAQ-«сирота» / дубль источника истины.** FAQ не связан с витриной или дословно копирует ADR/обзор вместо ссылки. | Низ. | Низ. | Link-first (ADR D4): двусторонние ссылки (AC-8), машинные детали — только ссылками; тест проверяет наличие кросс-ссылок. |
-| TR-3 | **Ложно-строгий негативный скан.** Тест ищет запрещённые слова (`main`, «откатыва…», `force-push`) как голые подстроки → краснеет на корректно **отрицающих** предложениях FAQ (которые AC-9 предписывает иметь). | Сред. | Сред. | Негативный скан — на уровне **утверждений**, а не подстрок (ADR D3); инвариант «тест не фолзит на верном FAQ, но краснеет на реально ложном». Зеркало эталона `tests/test_lite_setup_doc.py`. |
-| TR-4 | **Битый якорь кросс-ссылки.** Ссылка `tech-pipeline.md#отмена-stop--cancelled` не совпадёт с фактически генерируемым slug заголовка «Отмена: STOP → `cancelled`». | Низ. | Низ. | Разработчик сверяет slug при переносе (ADR D4); цели секций подтверждены существующими (business.md §«Сценарий 6», tech-pipeline.md §«Отмена», ADR ORCH-090). |
-| TR-5 | **Фактическая неточность FAQ.** Утверждение расходится с кодом (напр. «STOP откатит прод», «убивает деплой мгновенно»). | Низ. | Выс. | NFR-2/FR-5/AC-9: каждое утверждение verifiable против read-only модулей (ADR §Ссылки); reviewer сверяет с кодом; негативный скан (TR-3) ловит запрещённый класс. Содержание выверено аналитиком (TRZ Приложение A). |
-| TR-6 | **Ошибочное размещение раздела.** Аудитория FAQ — «пользователь доски», секция — `operations/` («наш прод»). | Низ. | Низ. | Осознанный компромисс (ADR D1): альтернативы (`overview/` под тестом витрины, новый `docs/faq/`) хуже; вводный абзац «для кого»; будущее пере-размещение дёшево (1 файл + 2 ссылки + 1 тест). |
-
-## Сводный вывод
-
-Доминирующий класс — **дрейф документации** (TR-1) и **хрупкость анти-дрейф теста** (TR-3); оба
-структурно снижены решением D3 (claim-level негативный скан + детерминированный offline-тест) и
-нормативом сопровождения D5. Рантайм-рисков **нет**: задача docs-only, не трогает `src/**`/
-`STAGE_TRANSITIONS`/`QG_CHECKS`/схему БД, не деплоит/не рестартит прод/не трогает `main` →
-self-hosting-безопасна, прод-деплой безвреден.
-
-**Эскалация не требуется.** Не `arch:major-change` (нет новой стадии/компонента/смены БД), возврат
-в анализ не нужен (BRD/TRZ/AC полны и согласованы с кодом; блокирующих неоднозначностей нет —
-`01-questions.md` аналитиком осознанно не создан). Остаточный риск для прод-конвейера —
-**пренебрежимо мал**.

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

@@ -1,85 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-108
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-108
-version: 1
----
-
-# Review ORCH-108 — FAQ: как использовать STOP для отмены задачи
-
-## Summary
-
-Docs-only задача: создаёт пользовательский FAQ `docs/operations/FAQ_STOP.md` (формат «вопрос →
-ответ»), двусторонние перекрёстные ссылки витрина/обзор ⇄ FAQ ⇄ ADR ORCH-090 и детерминированный
-анти-дрейф тест `tests/test_faq_stop_doc.py`. Поведение STOP — источник истины ORCH-090
-(`adr-0026`) — **не меняется**.
-
-Проверены все 4 оси. **Соответствие ТЗ/AC (1–11)** — полное. **Соответствие ADR** — все решения
-D1–D5 реализованы. **Качество** — тест содержателен, детерминирован, с non-evergreen-самочеком.
-**Документация (приоритетная ось)** — CHANGELOG обновлён, витрина `docs/overview/` обновлена, ADR
-заведён, `src/**` не тронут → нет необновлённой документации. **P0/P1 findings отсутствуют.**
-
-Верификация по ключевым осям:
-- **AC-9 (фактическая корректность) — самая важная для docs-FAQ.** Все 9 утверждений FAQ сверены с
-  кодом (`src/stage_engine.py::cancel_task`, `src/cancel.py`, `src/webhooks/plane.py`,
-  `src/gitea.py`, `src/db.py`) — **каждое CONFIRMED**, противоречий коду нет: graceful SIGTERM-стоп
-  (`launcher.stop_process`); job'ы → терминальный `cancelled`, не реквью'ятся (`claim_next_job`
-  берёт только `queued`); удаление worktree + рабочей ветки с guard `_PROTECTED_BRANCHES={main,
-  master}` (никогда `main`/force-push); docs-артефакты сохраняются; отложенная отмена в критичном
-  окне (`cancel.in_critical_window` → только `queued`-job'ы, running-актор не трогается, finalizer
-  применяет позже); STOP не делает revert влитого; релонч гейтится строго стадией `analysis`
-  (дыра релонча ORCH-090 D6 закрыта); fail-closed no-op (нет `stop` в `_DEFAULT_STATES`) +
-  идемпотентный no-op для терминальной задачи + kill-switch `stop_status_enabled`/`stop_status_repos`.
-- **AC-8 / TR-4 (риск висячего якоря).** Внутренняя ссылка FAQ `…tech-pipeline.md#отмена-stop--cancelled`
-  корректно резолвится в заголовок `## Отмена: STOP → \`cancelled\`` (slug с двойным дефисом от
-  удалённого `→` — совпадает байт-в-байт). Цель ADR-ссылки
-  `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md` существует. Обратные ссылки из
-  `business.md` (Сценарий 6) и `tech-pipeline.md` (Отмена: STOP → `cancelled`) присутствуют.
-- **AC-10 / AC-11.** `git diff origin/main...HEAD`: только `docs/**`, `CHANGELOG.md`,
-  `tests/test_faq_stop_doc.py` (+ scratch `.task-dev.md`); `src/**` / `STAGE_TRANSITIONS` /
-  `QG_CHECKS` / `check_*` / схема БД — не тронуты. `tests/test_faq_stop_doc.py` — 12 passed;
-  `tests/test_system_docs.py` (витрина) — 29 passed.
-
-## Findings
-
-### P0 — Blocker
-- _нет_
-
-### P1 — Must fix
-- _нет_
-
-### P2 — Should fix
-- _нет_
-
-### P3 — Nice-to-have
-- [ ] `.task-dev.md` (scratch-файл dev-трекинга в корне) попал в коммит, обновлён с `ORCH-126` на
-  `ORCH-108`. Это существующий трекируемый файл, к deliverables не относится, рантайм/конвейер не
-  затрагивает — инконсеквентно, фиксации не требует. Отмечено только для полноты.
-
-## Документация
-
-Приоритетная ось пройдена. Это **docs-задача**, `src/**` не изменён → требование «изменил `src/` →
-обнови доку в том же PR» не активируется; при этом всё, что задача обязана обновить, обновлено:
-- **`CHANGELOG.md`** — запись ORCH-108 присутствует (раздел `[Unreleased]`), с инвариантом docs-only
-  и нормативом сопровождения. ✓
-- **Витрина системы `docs/overview/` (ORCH-011)** — `business.md` (Сценарий 6) и `tech-pipeline.md`
-  (Отмена: STOP → `cancelled`) дополнены ссылкой на FAQ; `tests/test_system_docs.py` зелёный
-  (инвариант курируемого каталога витрины не нарушен — FAQ положен в `docs/operations/`, не в
-  `docs/overview/`, см. ADR D1). ✓
-- **ADR** — `docs/work-items/ORCH-108/06-adr/ADR-001-faq-stop-placement-and-anti-drift.md` заведён;
-  сквозной global-ADR обоснованно N/A (локальное docs-only решение, нет нового QG/стадии/компонента/
-  таблицы — критерий `PIPELINE_DOCS.md` §4). ✓
-- **README «Известные ограничения» (ORCH-079)** — ORCH-108 не закрывает ни один из открытых пунктов
-  (Telegram 48h / intra-repo deps / пакетный автоном); STOP уже документирован в README §«Отмена
-  задачи: статус STOP». Обновление README не требуется. ✓
-- **link-first (ADR D4)** — машинные детали (`тумбстон`/`merge-lease`/`_ensure_column`) в FAQ не
-  дублируются, даются ссылками; проверено тестом (`test_faq_links_back_to_overview_and_adr`). ✓
-
-Документация = golden source: обновлена корректно и согласованно. Нет необновлённой документации →
-блокирующего finding'а по этой оси нет.

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

@@ -1,40 +0,0 @@
----
-result: PASS
-work_item: ORCH-108
-stage: testing
-author_agent: test-runner
-status: success
-created_at: 2026-06-17
-model_used: n/a
-exit_code: 0
-smoke: ok
----
-
-# Test Gate Log (deterministic runner, ORCH-116)
-
-pytest exit-code `0` -> `result: PASS` (smoke: ok).
-
-Вердикт зафиксирован детерминированным test-раннером (ORCH-116), не LLM. PASS/FAIL = exit-код `pytest` + read-only smoke (`/health`, `/status`, `/queue` + блок `serial_gate`).
-
-pytest stdout (tail):
-```
-.................................................................... [ 64%]
-........................................................................ [ 67%]
-........................................................................ [ 71%]
-........................................................................ [ 74%]
-........................................................................ [ 77%]
-........................................................................ [ 80%]
-........................................................................ [ 84%]
-........................................................................ [ 87%]
-........................................................................ [ 90%]
-........................................................................ [ 93%]
-........................................................................ [ 96%]
-...................................................................      [100%]
-=============================== warnings summary ===============================
-src/config.py:8
-  /repos/_wt/orchestrator/feature_ORCH-108-19c40858/src/config.py:8: PydanticDeprecatedSince20: Support for class-based `config` is deprecated, use ConfigDict instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.13/migration/
-    class Settings(BaseSettings):
-
--- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
-2227 passed, 1 warning in 99.72s (0:01:39)
-```

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

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

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-108
-stage: deploy-staging
-author_agent: staging-runner
-status: success
-created_at: 2026-06-17
-model_used: n/a
-exit_code: 0
-base_url: http://localhost:8501
----
-
-# Staging Gate Log (deterministic runner, ORCH-115)
-
-Staging suite exit-code `0` -> `staging_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным staging-раннером (ORCH-115), не LLM. infra-tolerance (ORCH-061) уже учтена внутри `staging_check.py` — раннер её не пересуживает.
-
-INFRA-WAIVED lines (ORCH-061, copied for observability):
-- INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-
-Staging suite stdout (tail):
-```
- (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ·        waiting... (waiting for analyst job in queue)
-  ✗ FAIL  C9b Analyst job enqueued in staging queue
-
-[CLEANUP]
-  ·      CLEANUP: no branch to delete
-  ✓ PASS  CLEANUP: deleted Plane issue a38f627e-4ba4-47c3-a19f-3bb939a79a37 (HTTP 204)
-  ·      CLEANUP DB: no task row found for plane_id=a38f627e-4ba4-47c3-a19f-3bb939a79a37
-  ·      CLEANUP DB dedup: no such table: events_dedup
-
-============================================================
-  RESULT: 8/10 checks PASS
-  REAL failed         : none
-  SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
-============================================================
-  ·      tolerance: staging_infra_tolerance_enabled=True
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-```

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

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

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

@@ -1,7 +0,0 @@
-# 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

@@ -1,175 +0,0 @@
----
-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

@@ -1,158 +0,0 @@
----
-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

@@ -1,166 +0,0 @@
----
-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

@@ -1,104 +0,0 @@
-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

@@ -1,335 +0,0 @@
----
-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

@@ -1,61 +0,0 @@
----
-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

@@ -1,43 +0,0 @@
----
-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

@@ -1,44 +0,0 @@
----
-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

@@ -1,134 +0,0 @@
----
-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

@@ -1,95 +0,0 @@
----
-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

@@ -1,12 +0,0 @@
----
-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,12 +0,0 @@
----
-deploy_status: SUCCESS
-work_item: ORCH-116
-hook_exit_code: 0
-deployed_by: deploy-finalizer
----
-
-# Deploy log — ORCH-036 executable self-deploy
-
-Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-116/15-staging-log.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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