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

.env.example

@@ -230,28 +230,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)
@@ -466,18 +447,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`)
@@ -600,49 +569,14 @@ ORCH_COVERAGE_RUN_TIMEOUT_S=900
 #   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_MAX_RETRIES  -> tool-error (suite did NOT execute) bounded DEFER
+#                                        budget before a fail-closed FAILED (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

.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/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-115
 Repo: orchestrator
-Branch: feature/ORCH-108-19c40858
+Branch: feature/ORCH-115-orch-replace-llm-deployer-with
 Stage: development

CHANGELOG.md

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

CLAUDE.md

@@ -456,99 +456,6 @@ Plane, **не** Quality Gate и **не** стадия).
   `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/` в

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-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/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 | Метод проверки |
@@ -117,19 +109,6 @@ LLM). Leaf `src/staging_runner.py` (зеркало `run_deploy_finalizer`) ис
 `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 +381,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 +398,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 +454,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

@@ -57,7 +57,7 @@
 | **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` сохранена) |
+| **A5** | `.openclaw/agents/tester.md` | стадия `testing` | tester | `13-test-report.md` | `result:` | `check_tests_passed:182` → `_parse_tests_verdict:226` (`result:`) | ~60–150k / 5–20 мин | да (через S0) | **C** | `needs-hybrid-fallback` | **avoidable**: PASS/FAIL = exit-code `pytest`+smoke (деривируем); LLM нужен лишь на триаж падений / маппинг TC↔критерии |
 | **A6** | `.openclaw/agents/deployer.md` | стадии `deploy-staging` / `deploy` | deployer | `15-staging-log.md` / `14-deploy-log.md` | `staging_status:` / `deploy_status:` | `check_staging_status:599` → `_parse_staging_status:538` (`staging_status:`); `check_deploy_status:473` → `_parse_deploy_status:413` (`deploy_status:`) | ~40–120k / 3–15 мин | да (через S0; для 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 не консультируется |
@@ -154,13 +154,7 @@
   `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:`.
+  Второй кандидат (`tester`) остаётся follow-up'ом по роли.
 - **Анти-дрейф тесты:** `tests/test_llm_call_site_inventory.py` (TC-01…TC-06, TC-09, TC-12, TC-13,
   TC-14) и `tests/test_llm_determinization_docs.py` (TC-07/08/11). Дискриминатор всех проверок —
   **«консультирует LLM», а не «спавнит subprocess»**.

docs/architecture/llm-determinization-roadmap.md

@@ -39,24 +39,12 @@
    замены агента уже снят рабочим паттерном.
 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` — инвариант карты) как фиксация второго среза.
+## 2. Второй кандидат — **tester (гибрид)**
 
 Детерминированное ядро (`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'у
 

docs/architecture/llm-usage-policy.md

@@ -99,10 +99,3 @@ Call-site является **avoidable LLM control path** тогда и толь
   детерминированный `src/staging_runner.py` производит `staging_status:` без `_spawn` (перехват до
   него, как `D1`/`D2`) — раннер **LLM не зовёт** и **второй транспорт не вводит**, поэтому инвариант
   «единственный транспорт S0» соблюдён (TC-12 зелёный). Это образец для последующих срезов roadmap'а.
-- **Реализованный срез (ORCH-116).** ORCH-116 снял A5/tester тем же паттерном: детерминированный
-  `src/test_runner.py` производит `result:` на `testing` для in-scope репо без `_spawn` (перехват до
-  него, как `D1`/`D2`) — exit-код `pytest` в worktree + read-only smoke. Это `needs-hybrid-fallback`
-  (детерминированное ядро вынесено; LLM-фолбэк на не-деривируемое суждение — триаж падений / маппинг
-  TC↔критерии — остаётся **off-control-path** и **не** производит `result:`). Раннер **LLM не зовёт** и
-  **второй транспорт не вводит** → инвариант «единственный транспорт S0» соблюдён (TC-12 зелёный).
-  Будущий off-control-path триаж — **не** новый транспорт control-path-консультации (он вне control-path).

docs/operations/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

@@ -244,39 +244,10 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 - **Свежесть staging-образа (ORCH-058):** на ребре `deploy-staging → deploy` (ПОСЛЕ merge-gate, ДО Phase A) QG-под-чек `check_staging_image_fresh` пересобирает staging-образ из валидированного коммита и пересоздаёт 8501 (Strategy A), а хук перед build-once retag fail-closed сверяет OCI-лейбл `revision` с `EXPECTED_REVISION` (Strategy B). Гарантирует: в прод промоутится РОВНО провалидированный артефакт (инцидент LESSONS_ORCH-036 п.4 — тихий промоут устаревшего образа). Сборки/recreate — ТОЛЬКО staging (8501); FAIL → откат на `development`. Условный: реален только для self-hosting.
 - **Гигиена shared deploy-базы (ORCH-112):** self-deploy `git pull origin main` устойчив к грязному рабочему дереву deploy-базы (модифицированные tracked + untracked-остатки failed/cancelled/брошенных задач). Хук `--deploy` перед pull приводит базу к чистому `origin/main` (resilient-pull: `git fetch` + `git reset --hard origin/main` + `git clean -fd`), **строго сохраняя** rollback-снимки `.deploy-prev-image-*`, `deploy-hook.log`, gitignored `.env`/`data/`/`*.db` (НИКОГДА `-x`!), sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*`. Гейт — kill-switch `ORCH_CHECKOUT_HYGIENE_ENABLED` (дефолт `True`; off → голый pull 1:1); скоуп `ORCH_CHECKOUT_HYGIENE_REPOS` (пусто → self-hosting only). Грязь базы детектируется → лог + Telegram-алерт (Phase-C finalizer). Решает инцидент ORCH-111 (грязь ORCH-104 заблокировала `git pull`). Детально — `docs/work-items/ORCH-112/06-adr/ADR-001`, сквозной adr-0044.
 
-### Граница исполнения docker-операций — host-side, НЕ изнутри прод-контейнера (ORCH-123)
-
-**Инвариант (нормативно, adr-0049):** прод-контейнер `orchestrator` несёт **только**
-`openssh-client git curl` (+ pinned gitleaks) — **бинаря `docker` в образе НЕТ** (`Dockerfile:11`,
-`python:3.12-slim` его не несёт). `/var/run/docker.sock` **смонтирован** (`docker-compose.yml`,
-rw + `group_add 999`, «МИНА 1» ORCH-040), но **сознательно НЕ используется изнутри** контейнера: нет
-docker-клиента, и добавлять его (CLI/SDK) **нельзя** — это активировало бы дремлющий
-root-эквивалентный путь для всего, что бежит в контейнере, включая LLM-агентов (security-разбор —
-ADR-001 D2 / adr-0049 / R-1).
-
-Поэтому **все** docker-операции self-hosting исполняются **host-side** через **ssh на `127.0.0.1`**
-(`ORCH_DEPLOY_SSH_HOST`/`ORCH_DEPLOY_SSH_USER`, ssh-ключ смонтирован `:ro`), где docker CLI есть:
-- **прод-деплой** (ORCH-036, `self_deploy.build_deploy_command`) — `ssh … setsid bash hook --deploy`;
-- **image-freshness** (ORCH-058, `image_freshness.image_revision`/`rebuild_staging_image`) — `ssh … docker …`;
-- **staging-runner** (ORCH-123, `staging_runner.build_staging_command`) — `ssh … docker exec orchestrator-staging python3 … staging_check.py … --mode stub`.
-
-Сама staging-сюита (`scripts/staging_check.py`) **по-прежнему** исполняется **внутри** контейнера
-`orchestrator-staging` (8501) — меняется лишь **кто инициирует** `docker exec` (хост через ssh, а не
-прод-контейнер). До ORCH-123 staging-runner (ORCH-115) вызывал `docker exec` **изнутри**
-прод-контейнера → `FileNotFoundError` (нет `docker`) → постоянный environment-дефект ложно
-маршрутизировался как код-фейл-откат `deploy-staging → development` (инцидент ORCH-116). Фикс:
-host-side ssh-обёртка (флаг `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true`, дефолт) + трёхсторонняя
-классификация (suite-ran / permanent-env / transient-infra), где environment/инфра **никогда** не
-оканчивается код-фейл-откатом (infra-HOLD + алерт «инфра, НЕ дефект кода»), и prod-like preflight
-канала на старте сервиса. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (прежний in-container
-вызов — валиден лишь там, где docker CLI запечён в образ) или `ORCH_STAGING_RUNNER_ENABLED=false`
-(LLM-deployer 1:1). Детали — `docs/work-items/ORCH-123/06-adr/ADR-001`, сквозной adr-0049.
-
 **Правила для агентов при задачах ORCH:**
 1. НЕ перезапускать / не ронять прод-контейнер `orchestrator` в рамках задачи.
 2. Все проверки деплоя — на staging (8501), боевой 8500 не трогать.
 3. Деплой self — только через хук с health-check + авто-rollback (`DEPLOY_HOOK.md`).
-4. docker-операции исполняются **host-side через ssh** — в контейнере `docker` CLI нет (ORCH-123).
 
 ## Эксплуатация (быстрые команды)
 ```bash

docs/overview/business.md

@@ -97,7 +97,6 @@
 Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и
 рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в
 необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения.
-Подробнее — [FAQ по статусу STOP](../operations/FAQ_STOP.md).
 
 ---
 

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).
-
 ## Модель и эффорт
 
 Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
@@ -63,14 +54,6 @@ Machine-verdict ключи читаются гейтами **только из Y
 под выключенным флагом / для не-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)).

docs/overview/tech-observability.md

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

@@ -44,17 +44,6 @@ created → analysis → architecture → development → review → testing →
 > на стадии снова работает 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 +96,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,8 +103,6 @@ freeze, ни объявленные зависимости. Свежесть б
 (идёт слияние/выкладка) — отмена откладывается и применяется после честного завершения шага.
 STOP никогда не трогает `main` и прод-контейнер.
 
-Пользовательская инструкция «как этим пользоваться» — [FAQ по статусу STOP](../operations/FAQ_STOP.md).
-
 ## Статусная модель Plane: индикация ≠ управление
 
 Статусы в Plane — слой **индикации**: они показывают человеку осмысленную картину хода задачи,

docs/overview/tech-quality-security.md

@@ -53,10 +53,7 @@ control-path и его вердикт деривируем из exit-кодов
 анти-дрейф тестами. **Первый срез реализован (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` не тронут.
+`check_staging_status` не тронут. Замена второго кандидата (`tester`) — follow-up по роли.
 
 - Карта вызовов LLM: [`../architecture/llm-call-sites.md`](../architecture/llm-call-sites.md)
 - Нормативная политика: [`../architecture/llm-usage-policy.md`](../architecture/llm-usage-policy.md)

docs/work-items/ORCH-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-115/16-post-deploy-log.md

@@ -1,7 +1,7 @@
 ---
 post_deploy_status: HEALTHY
 action_taken: NONE
-work_item: ORCH-108
+work_item: ORCH-115
 window_s: 900
 checks_total: 30
 checks_failed: 0

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

@@ -1,7 +0,0 @@
-# Business Request: BUG: 00-business-request.md is always TBD, losing source-backed request context
-
-Work Item ID: ORCH-119
-
-## Description
-
-TBD

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

@@ -1,151 +0,0 @@
----
-work_item: ORCH-119
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 01 — BRD / Bug-report: ORCH-119 — `00-business-request.md` всегда `TBD`, теряется source-backed контекст запроса
-
-Work Item: **ORCH-119** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug** (укороченный маршрут, пропуск стадии `architecture`)
-
-> 🐞 **Багфикс-трек (ORCH-019).** Облегчённый пакет (bug-report + обязательный регресс-тест), но
-> все 4 файла analysis (гейт `check_analysis_complete` не меняется). Экономия — в пропуске стадии
-> `architecture`, не в числе файлов.
->
-> **Эскалация в full-cycle рассмотрена и отклонена.** Дефект — контейнерный data-flow + рендеринг,
-> чинится **точным зеркалированием уже существующего прецедента `tasks.title`** (персист при создании
-> задачи → чтение в `_materialize_deferred_branch`). Нет нового компонента, нового QG, политического
-> решения или визуального артефакта → ADR/макет не требуется. Если разработчик в ходе фикса упрётся в
-> архитектурное решение (напр. иной механизм персиста, влияющий на схему/контракты) — снять трек:
-> `POST /bug-fast-track/escalate?work_item=ORCH-119` и пометить здесь `escalate: full-cycle`.
-
----
-
-## 1. Бизнес-контекст и проблема
-
-### Симптом (наблюдаемое)
-Для **каждой** созданной задачи файл `docs/work-items/<id>/00-business-request.md` генерируется
-с телом раздела «Description» равным буквальному `TBD`. Реальный текст запроса (описание Plane-issue,
-обогащённое из Plane API) **не попадает** в персистентный артефакт. Пример — сам этот work item:
-
-```
-# Business Request: BUG: 00-business-request.md is always TBD, losing source-backed request context
-Work Item ID: ORCH-119
-## Description
-TBD
-```
-
-### Последствие (бизнес-боль)
-`00-business-request.md` — **точка входа конвейера** и источник для analyst (вход стадии `analysis`,
-см. `PIPELINE_DOCS.md` §2). Когда тело всегда `TBD`:
-- source-backed контекст запроса теряется из durable-артефакта репозитория (остаётся только эфемерно
-  в `task_content` analyst-job'а и в Plane);
-- последующее чтение work item «глазами» (reviewer, человек, ретроспектива, петля уроков) видит пустой
-  бизнес-запрос — невозможно сверить, ту ли задачу решал конвейер;
-- на **self-hosting** (`orchestrator`) задача почти всегда идёт **отложенным срезом ветки** (serial
-  gate, ORCH-088), где контекст теряется безвозвратно (см. §3, причина B).
-
-### Причина симптома (установленный факт, по коду)
-`src/webhooks/plane.py::_create_initial_docs` (строка ~925) **хардкодит** тело:
-```python
-content = f"# Business Request: {name}\n\nWork Item ID: {work_item_id}\n\n## Description\n\nTBD\n"
-```
-Функция принимает только `(repo, branch, work_item_id, name)` — **`description` ей не передаётся**,
-хотя у вызывающего `start_pipeline` оно есть в области видимости и уже используется для analyst-job
-(`task_desc`, строка ~725: `Description:\n{description}`). То есть данные **есть**, но в артефакт не
-доходят.
-
-### Локализация (куда смотреть разработчику) — два пути создания
-
-**Путь A — прямой** (`serial_gate` не применим к репо):
-`start_pipeline` (`src/webhooks/plane.py`) имеет `description` (строки ~518; обогащается из Plane API,
-~539–551) → зовёт `_create_initial_docs(repo, branch, work_item_id, name)` (строка ~710) **без**
-`description`. Достаточно дотянуть аргумент.
-
-**Путь B — отложенный (критичный для self-hosting)** (`serial_gate_applies(repo)` → для `orchestrator`):
-`start_pipeline` **не** создаёт ветку/доки (ORCH-088, анти-stale-base); срез релоцирован в
-`src/agents/launcher.py::_materialize_deferred_branch` (строки ~514–538), который вызывает то же
-`_create_initial_docs`, **располагая только `title`** из строки `tasks` (`description` нигде не
-персистится). Установленный факт схемы: таблица `tasks` **не имеет** колонки `description`; `title`
-персистится через `_ensure_column` (`src/db.py:125`) и читается в `_spawn`/`_materialize_deferred_branch`
-именно так. ⇒ Чтобы путь B рендерил описание, `description` надо **сохранить durable при создании
-задачи** (зеркало `tasks.title`).
-
-### Предусловие истинности данных (установленный факт)
-QG-0 (`_qg0_errors`, `src/webhooks/plane.py:490`) отклоняет создание при `description` короче 20
-символов (строка ~500). ⇒ любая задача, дошедшая до `_create_initial_docs`, **гарантированно имеет
-непустое осмысленное описание** — терять его тем более недопустимо. Защитный fallback на случай
-пустого описания всё равно предусмотреть (NFR-2).
-
-## 2. Объём (scope)
-
-### В объёме
-- Рендер фактического `description` (предпочтительно `description_stripped`, plain-text) в раздел
-  «Description» файла `00-business-request.md` — на **обоих** путях (A прямой, B отложенный).
-- Durable-персист `description` при создании задачи (зеркало `tasks.title`), чтобы путь B имел доступ
-  к нему на момент claim.
-- Защитный fallback при отсутствии/пустом описании (без падения).
-- Обязательный регресс-тест (красный до фикса, зелёный после).
-
-### Вне объёма
-- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключей / семантики гейтов.
-- Изменение поведения serial-gate / отложенного среза ветки ORCH-088 (только **дополнить** данными,
-  не менять момент/условие среза).
-- Ретро-генерация `00-business-request.md` для **уже существующих** задач (только новые создания).
-- Переформатирование/обогащение структуры самого `00-business-request.md` сверх вставки описания
-  (заголовки/название источника остаются как есть).
-- Любая запись в Plane (артефакт пишется только в Gitea-ветку, как сейчас).
-
-## 3. Заинтересованные стороны
-- **Заказчик/оператор** — получает читаемый durable бизнес-запрос вместо `TBD`.
-- **Агент analyst и reviewer** — могут сверять решённое с запросом по репозиторию.
-- **Петля уроков / ретроспектива (ORCH-098)** — корректный контекст в артефакте.
-- Приёмку результата выполняет конвейер (reviewer + Quality Gates), не аналитик.
-
-## 4. Бизнес-требования (BR)
-- **BR-1** — Раздел «Description» в `00-business-request.md` содержит **фактический текст запроса**
-  (из Plane-issue, как он используется для analyst-job'а), а не литерал `TBD`, для вновь создаваемых
-  задач.
-- **BR-2** — Поведение одинаково на **обоих** путях создания: прямом (A) и отложенном срезе ветки (B,
-  self-hosting/serial-gate). Путь B — приоритетный сценарий (доминирует на `orchestrator`).
-- **BR-3** — При отсутствующем/пустом описании артефакт создаётся с **явным безопасным fallback**-
-  маркером (напр. «описание отсутствует в источнике»), без падения создания задачи.
-- **BR-4** — Сохранён состав/имена артефактов: создаётся ровно `00-business-request.md` по тому же
-  пути; downstream-конвейер (analyst и далее) не затронут.
-
-## 5. Нефункциональные требования (NFR)
-- **NFR-1 (обратная совместимость / never-break)** — изменение аддитивно: создание задачи **никогда**
-  не должно падать из-за нового рендера/персиста. Любая ошибка обогащения → деградация на безопасное
-  значение (fallback-маркер), а не отказ создания. Идемпотентность `_create_initial_docs` (422 = уже
-  существует → no-op) сохранена.
-- **NFR-2 (целостность данных)** — описание рендерится **как есть** (plain-text `description_stripped`),
-  без обрезки/искажения; многострочный текст сохраняется. `00-business-request.md` — информационный
-  док (гейтом не парсится), поэтому markdown-спецсимволы в описании безопасны для гейтов.
-- **NFR-3 (инварианты ORCH-088)** — момент и условие отложенного среза ветки не меняются; описание
-  лишь дополнительно переносится через durable-хранилище (зеркало `tasks.title`), анти-stale-base
-  логика цела.
-- **NFR-4 (self-hosting-безопасность)** — фикс не деплоит/не рестартит прод, не трогает `main`, не
-  добавляет сетевых вызовов в горячий `claim_next_job`.
-
-## 6. Допущения и ограничения
-- `description`/`description_stripped` доступны в `start_pipeline` и достаточны как источник (уже
-  используются для analyst-job). Plane-обогащение (ORCH «name_missing/desc_missing» блок) остаётся
-  единственным источником описания — новых сетевых обращений не вводим.
-- QG-0 гарантирует ≥20 символов описания для прошедших задач (см. §1) — нормальный путь всегда имеет
-  реальный текст.
-- Персист описания следует **установленному прецеденту `tasks.title`** (аддитивная колонка через
-  `_ensure_column`); это не новое архитектурное решение.
-
-## 7. Критерии успеха
-Новые задачи получают `00-business-request.md` с реальным описанием на обоих путях; обязательный
-регресс-тест красный до фикса и зелёный после; полный `pytest tests/ -q` зелёный. Детальные PASS/FAIL
-— `03-acceptance-criteria.md`.
-
-## 8. Риски
-- Путь B забыт (чинят только прямой путь A) → на self-hosting баг остаётся. Митигируется обязательным
-  integration-тестом пути B (TC-03).
-- Регресс схемы/создания задачи при добавлении персиста → митигируется аддитивным `_ensure_column` и
-  тестом обратной совместимости (TC-05). Детальные тех-риски архитектором не выпускаются (bug-track).

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

@@ -1,86 +0,0 @@
----
-work_item: ORCH-119
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-119 — source-backed генерация `00-business-request.md`
-
-Work Item: **ORCH-119** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug**
-
-> Bug-track: стадия `architecture` пропускается, поэтому ТЗ конкретизирует затрагиваемые модули и
-> требование к данным. ТЗ описывает **что должно измениться и где**; точная форма реализации (имена
-> символов, сигнатуры) — за разработчиком, в рамках указанного прецедента `tasks.title`.
-
-## 1. Сводка изменения
-Source-backed `description` (текст запроса из Plane-issue) должен попадать в раздел «Description»
-файла `00-business-request.md` вместо хардкода `TBD`. Для этого: (1) `description` рендерится в тело
-артефакта; (2) `description` **персистится при создании задачи** (зеркало `tasks.title`), чтобы
-отложенный путь среза ветки (ORCH-088, доминирует на self-hosting) имел к нему доступ на момент claim.
-Изменение аддитивно, never-break, fail-safe.
-
-## 2. Задействованные модули / пути
-| Путь | Действие |
-|------|----------|
-| `src/webhooks/plane.py` | изменить — `_create_initial_docs`: принять `description`, рендерить его в тело вместо `TBD`; рекомендуется выделить чистый рендер-хелпер (напр. `_render_business_request(work_item_id, name, description) -> str`) для unit-тестируемости без сети |
-| `src/webhooks/plane.py` | изменить — `start_pipeline`: (а) прямой путь — передать `description` в `_create_initial_docs` (строка ~710); (б) персистить `description` при создании задачи (рядом со стампом `title`) |
-| `src/agents/launcher.py` | изменить — `_materialize_deferred_branch`: прочитать персистнутое `description` из строки `tasks` и передать в `_create_initial_docs` (зеркало того, как уже читается/используется `title`) |
-| `src/db.py` | изменить — аддитивная колонка `tasks.description` через `_ensure_column` (паттерн `tasks.title`, строка ~125); хелпер чтения/записи при необходимости; **не менять** базовый `CREATE TABLE tasks` |
-| `tests/test_orch119_business_request.py` | создать — регресс + edge-кейсы (см. `04-test-plan.yaml`) |
-| `CHANGELOG.md` | изменить — запись о фиксе (правило сопровождения) |
-
-## 3. Функциональные требования
-
-### FR-1 — Рендер описания в артефакт (BR-1)
-Тело раздела «Description» в `00-business-request.md` = фактический `description` (предпочтительно
-`description_stripped`, plain-text), без обрезки/искажения, многострочный текст сохраняется. Заголовок
-(`# Business Request: {name}`) и `Work Item ID` — без изменений.
-
-### FR-2 — Прямой путь (BR-2, путь A)
-`start_pipeline` при `serial_gate` НЕ применим → передаёт `description` в `_create_initial_docs`;
-артефакт создаётся с реальным описанием в одном вызове.
-
-### FR-3 — Отложенный путь / персист (BR-2, путь B — критичный)
-`description` персистится durable при создании задачи (зеркало `tasks.title`).
-`_materialize_deferred_branch` читает его из строки `tasks` и передаёт в `_create_initial_docs`, так
-что артефакт, материализованный на момент claim analyst-job, содержит реальное описание. Момент/условие
-отложенного среза (ORCH-088) **не меняются** — только источник данных дополняется (NFR-3).
-
-### FR-4 — Fallback и устойчивость (BR-3, NFR-1)
-Пустое/отсутствующее/нечитаемое `description` → явный безопасный маркер (напр.
-`_(описание отсутствует в источнике)_`), **без падения** создания задачи. Любая ошибка рендера/чтения
-персиста → деградация на fallback-маркер, не отказ. Идемпотентность сохранена: повторная
-материализация (Gitea 422 = файл уже существует) → no-op, ранее записанное тело не перезаписывается.
-
-## 4. Изменения API
-Нет. Эндпоинты не добавляются и не меняются. Запись артефакта остаётся в Gitea-ветку через
-существующий `contents` API; в Plane ничего не пишется.
-
-## 5. Изменения схемы БД
-Аддитивная колонка **`tasks.description TEXT`** через `_ensure_column` (идемпотентный ALTER, no-op на
-существующей таблице — safe на боевой БД), строго по прецеденту `tasks.title`. Базовый
-`CREATE TABLE tasks` не трогается. Индексы не требуются. Для уже существующих задач колонка `NULL`
-(ретро-генерация — вне объёма).
-
-> Допустимая эквивалентная реализация (на усмотрение разработчика): переиспользовать уже доступный
-> в `_spawn`/`_materialize_deferred_branch` источник данных, если он durable до момента claim. Если
-> такой надёжно нет — канон именно колонка `tasks.description` (как `tasks.title`). Решение не должно
-> вводить сетевой вызов в горячий путь claim (NFR-4).
-
-## 6. Требования к новым/изменённым QG checks
-Нет. `00-business-request.md` — информационный документ (гейтом не парсится, `PIPELINE_DOCS.md` §2–§3).
-`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи — байт-в-байт не трогаются.
-
-## 7. Совместимость / регресс
-- **Обратная совместимость:** аддитивная колонка + аддитивный аргумент с дефолтом; существующие задачи
-  и enduro-trails не затронуты (для них тоже просто рендерится их описание — улучшение, не регресс).
-- **Kill-switch:** отдельный флаг не требуется — изменение это исправление дефекта (улучшение
-  «всегда»), не рискованная фича; безопасность обеспечивается fail-safe fallback и never-break-контрактом.
-- **Обратимость:** revert PR полностью возвращает прежнее поведение (колонка остаётся, инертна).
-- **Self-hosting:** не деплоит/не рестартит прод, не трогает `main`, без новых сетевых вызовов в
-  `claim_next_job` (NFR-4). Анти-stale-base инвариант ORCH-088 цел (NFR-3) — перед правкой
-  `_materialize_deferred_branch`/отложенного среза свериться с `docs/work-items/ORCH-088/06-adr/`
-  (TRACEABILITY).

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

@@ -1,109 +0,0 @@
----
-work_item: ORCH-119
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки: ORCH-119 — source-backed `00-business-request.md`
-
-Work Item: **ORCH-119** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug**
-
-Формат: каждый критерий — **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
-провалом). Reviewer/тесты проверяют буквально по файлам репозитория.
-
----
-
-## AC-1 — Реальное описание в артефакте вместо `TBD`
-
-**Условие:** при создании задачи с непустым описанием раздел «Description» файла
-`00-business-request.md` содержит фактический текст запроса.
-- **PASS:** тело раздела «Description» равно переданному `description` (plain-text); подстрока с
-  реальным текстом присутствует; литерал `TBD` как ВСЁ тело раздела отсутствует.
-- **FAIL:** раздел «Description» = `TBD` (или иной плейсхолдер) при наличии непустого описания на входе.
-
----
-
-## AC-2 — Прямой путь создания (путь A)
-
-**Условие:** когда `serial_gate` не применим, `start_pipeline` передаёт `description` в
-`_create_initial_docs`.
-- **PASS:** артефакт, созданный прямым путём, содержит реальное описание (см. AC-1).
-- **FAIL:** на прямом пути `description` не доходит до артефакта (остаётся `TBD`).
-
----
-
-## AC-3 — Отложенный путь / self-hosting (путь B, критичный)
-
-**Условие:** когда `serial_gate_applies(repo)` (напр. `orchestrator`), описание персистится при
-создании задачи и рендерится при материализации ветки на момент claim
-(`launcher._materialize_deferred_branch`).
-- **PASS:** артефакт, материализованный отложенным путём, содержит реальное описание; описание
-  durable-доступно из строки `tasks` (не теряется между созданием задачи и claim).
-- **FAIL:** на отложенном пути описание утрачено → артефакт = `TBD`; либо описание нигде не
-  персистится до момента claim.
-
----
-
-## AC-4 — Безопасный fallback при пустом описании
-
-**Условие:** описание отсутствует/пустое/нечитаемо.
-- **PASS:** артефакт создаётся с явным безопасным fallback-маркером (не «голый» `TBD`-баг), создание
-  задачи не падает.
-- **FAIL:** создание задачи падает/бросает исключение, либо тихо теряет контекст без маркера.
-
----
-
-## AC-5 — Никаких изменений гейтов / схемы сверх аддитивной колонки
-
-**Условие:** правка не трогает машинерию конвейера.
-- **PASS:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, имена/семантика `check_*`, machine-verdict-ключи
-  — байт-в-байт прежние; единственное изменение схемы — аддитивная `tasks.description` (или
-  эквивалент без сетевого вызова в claim); базовый `CREATE TABLE tasks` не тронут.
-- **FAIL:** изменены гейты/переходы/вердикт-ключи; неаддитивная миграция; сетевой вызов добавлен в
-  `claim_next_job`.
-
----
-
-## AC-6 — Идемпотентность и обратная совместимость
-
-**Условие:** повторная материализация и существующие задачи.
-- **PASS:** повторный вызов (`_create_initial_docs`, Gitea 422) — no-op, не перезаписывает тело;
-  `_ensure_column` идемпотентен (no-op при существующей колонке); enduro-trails и прочие репо не
-  затронуты негативно.
-- **FAIL:** повторная материализация затирает/дублирует артефакт; миграция падает на боевой БД;
-  регресс для других репо.
-
----
-
-## AC-7 — Обязательный регресс-тест (red→green) и зелёный полный прогон
-
-**Условие:** дефект зафиксирован тестом.
-- **PASS:** `tests/test_orch119_business_request.py::TC-01` падает на коде ДО фикса (доказывает баг) и
-  проходит ПОСЛЕ; полный `pytest tests/ -q` зелёный.
-- **FAIL:** регресс-теста нет, либо он зелёный и до фикса (ничего не доказывает), либо полный прогон
-  красный.
-
----
-
-## AC-8 — Сопровождение
-
-**Условие:** документация/история обновлены в том же PR.
-- **PASS:** `CHANGELOG.md` содержит запись о фиксе ORCH-119.
-- **FAIL:** изменён функционал без обновления `CHANGELOG.md`.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-2 |
-| AC-3 | BR-2 / FR-3 / NFR-3 |
-| AC-4 | BR-3 / FR-4 / NFR-1 |
-| AC-5 | BR-4 / NFR-4 |
-| AC-6 | NFR-1 / FR-4 |
-| AC-7 | BR-1..BR-3 (доказательство) |
-| AC-8 | правило сопровождения |

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

@@ -1,64 +0,0 @@
-work_item: ORCH-119
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-title: "Source-backed генерация 00-business-request.md (фикс хардкода TBD)"
-framework: pytest
-scope: >
-  Покрывается: рендер фактического description в 00-business-request.md вместо литерала TBD на обоих
-  путях создания (прямой A и отложенный срез ветки B / self-hosting ORCH-088), durable-персист
-  description (зеркало tasks.title), безопасный fallback при пустом описании, аддитивность схемы и
-  обратная совместимость. ВНЕ покрытия: реальные сетевые вызовы Gitea/Plane (мокаются), ретро-генерация
-  артефактов для уже существующих задач.
-notes: >
-  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест: красный на коде ДО фикса (доказывает баг хардкода TBD), зелёный
-  ПОСЛЕ. Сетевые вызовы (_create_gitea_branch / _create_initial_docs httpx, Plane API) мокаются —
-  тесты без сети/прода. Рекомендуется тестировать чистый рендер-хелпер (_render_business_request) на
-  уровне unit, а пути A/B — на уровне integration с моками httpx и временной SQLite-БД. Полный регресс
-  pytest tests/ -q должен оставаться зелёным. Перед правкой отложенного среза ветки свериться с
-  docs/work-items/ORCH-088/06-adr/ (анти-stale-base инвариант, TRACEABILITY).
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "ОБЯЗАТЕЛЬНЫЙ РЕГРЕСС. Рендер 00-business-request.md при непустом description содержит фактический текст запроса в разделе 'Description' и НЕ равен литералу TBD. Красный до фикса (хардкод TBD), зелёный после."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Fallback: при пустом/whitespace/None description рендер даёт явный безопасный маркер (напр. 'описание отсутствует в источнике'), функция не бросает исключение."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-03
-    type: integration
-    description: "Путь B (отложенный, self-hosting): description персистнут при создании задачи и доступен из строки tasks; launcher._materialize_deferred_branch рендерит реальное описание в артефакт (мок httpx; description не теряется между созданием и claim)."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-04
-    type: integration
-    description: "Путь A (прямой, serial_gate не применим): start_pipeline передаёт description в _create_initial_docs; артефакт содержит реальное описание (мок httpx, перехват записанного content)."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-05
-    type: integration
-    description: "Обратная совместимость схемы: init_db на пустой БД и на БД со старой таблицей tasks (без колонки description) проходит; _ensure_column идемпотентен (повторный init_db — no-op); создание задачи не падает."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Целостность данных: многострочное описание со спецсимволами markdown рендерится без обрезки/искажения; идемпотентность — повторная материализация (Gitea 422) не перезаписывает уже записанное тело."
-    module: tests/test_orch119_business_request.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Анти-регресс гейтов: STAGE_TRANSITIONS / реестр QG_CHECKS / имена check_* импортируются без изменений (00-business-request.md остаётся информационным, не гейтится)."
-    module: tests/test_orch119_business_request.py
-    expected: PASS

docs/work-items/ORCH-119/06-adr/ADR-001-source-backed-business-request-doc.md

@@ -1,162 +0,0 @@
----
-work_item: ORCH-119
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# ADR-001: Durable-персист `description` для source-backed `00-business-request.md`
-
-Work Item: **ORCH-119** — `00-business-request.md` всегда `TBD`, теряется source-backed контекст запроса
-Стадия: **architecture**
-Сквозная регистрация: **N/A, локальное решение задачи** (аддитивная скалярная колонка по
-прецеденту `tasks.title`; не новый QG / стадия / компонент / смена БД-движка → сквозной
-`docs/architecture/adr/adr-NNNN-*` не заводится).
-
-> **Примечание по треку (Bug, ORCH-019).** Задача классифицирована как Bug и по BRD должна была
-> идти укороченным маршрутом (пропуск `architecture`). Фактически задача **дошла до стадии
-> `architecture`** (routing-override ORCH-019 не сработал — нет метки `Bug` в Plane / выключен
-> `bug_fast_track`), а exit-гейт `check_architecture_done` (`src/qg/checks.py:62`) требует ≥1 файла
-> в `06-adr/` или `07-infra-requirements.md`. Поэтому архитектурный выход выпускается штатно. ADR
-> намеренно компактный: он фиксирует **локальное** решение по data-flow и аддитивной схеме, без
-> сквозных последствий.
-
-## Статус
-Proposed
-
-## Контекст
-
-`src/webhooks/plane.py::_create_initial_docs` (`src/webhooks/plane.py:925`) **хардкодит** тело
-раздела «Description»:
-
-```python
-content = f"# Business Request: {name}\n\nWork Item ID: {work_item_id}\n\n## Description\n\nTBD\n"
-```
-
-Сигнатура `_create_initial_docs(repo, branch, work_item_id, name)` (`:917`) **не принимает**
-`description`, хотя у вызывающего `start_pipeline` оно есть в области видимости (`:518`, обогащается
-из Plane API `:540–551`) и уже используется для analyst-job (`task_desc`, `:723–725`). Данные есть —
-в durable-артефакт не доходят.
-
-Есть **два** пути создания (сверено по коду):
-
-- **Путь A (прямой)** — `serial_gate` не применим к репо: `start_pipeline` сам зовёт
-  `_create_initial_docs(repo, branch, work_item_id, name)` (`src/webhooks/plane.py:710`). `description`
-  здесь в области видимости — достаточно дотянуть аргумент.
-- **Путь B (отложенный, доминирует на self-hosting `orchestrator`)** — `serial_gate_applies(repo)`
-  (ORCH-088, анти-stale-base): `start_pipeline` **НЕ** режет ветку/доки (`:697–717`); срез
-  релоцирован на claim analyst-job в `src/agents/launcher.py::_materialize_deferred_branch`
-  (`:514–538`), который располагает только `title` из строки `tasks`
-  (`SELECT branch, work_item_id, title FROM tasks`, `:561`). **`description` в таблице `tasks` не
-  персистится** (базовый `CREATE TABLE tasks`, `src/db.py:31–42`, его не содержит) → путь B физически
-  не имеет доступа к описанию на момент claim.
-
-Предусловие истинности данных: QG-0 (`_qg0_errors`, `src/webhooks/plane.py:490–500`) отклоняет
-создание при `description` короче 20 символов ⇒ нормальный путь всегда имеет осмысленный текст; терять
-его недопустимо.
-
-Прямой прецедент: `tasks.title` — аддитивная колонка (`_ensure_column(conn,"tasks","title","TEXT")`,
-`src/db.py:125`), записываемая атомарно при создании задачи (`create_task_atomic`, `src/db.py:678–683`)
-и читаемая в `_spawn`/`_materialize_deferred_branch`. ORCH-119 решается **точным зеркалированием**
-этого прецедента для `description`.
-
-## Решение
-
-### Сводка
-Персистить `description` durable при создании задачи как **аддитивную колонку `tasks.description TEXT`**
-(зеркало `tasks.title`), записываемую **внутри того же атомарного INSERT** `create_task_atomic`
-(ORCH-053). На обоих путях создания тело `00-business-request.md` рендерится из фактического описания
-через выделенный чистый хелпер с fail-safe fallback. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
-machine-verdict-ключи / базовый `CREATE TABLE tasks` — не трогаются.
-
-### D1 — Где персистить описание (ключевое решение)
-**Решение: аддитивная колонка `tasks.description TEXT` через `_ensure_column`, записываемая атомарно
-в `create_task_atomic`.**
-
-Путь B (отложенный срез) читает данные задачи из строки `tasks` на момент claim — единственное
-durable-место, доступное и пути A, и пути B без сети. Колонка добавляется идемпотентным
-`_ensure_column(conn, "tasks", "description", "TEXT")` рядом с `tasks.title` (`src/db.py:125`); базовый
-`CREATE TABLE tasks` не меняется (no-op на боевой общей БД, restart-safe). Запись `description`
-**встраивается в существующий INSERT** `create_task_atomic` (расширяется список колонок/значений,
-`src/db.py:678–683`), а не отдельным `UPDATE` — чтобы персист был атомарен и race-safe относительно
-анти-dup-claim ORCH-053 (никакого окна, в котором задача создана, но описание ещё не записано).
-Сигнатура `create_task_atomic` расширяется аддитивным параметром `description` с дефолтом → обратная
-совместимость прочих вызывающих (напр. F-2 reconciler) сохранена. Привязка: FR-3, AC-3, NFR-3, NFR-4.
-
-### D2 — Чистый рендер-хелпер + проброс на обоих путях
-**Решение: выделить чистую функцию рендера тела и пробросить `description` в `_create_initial_docs`
-на обоих путях.**
-
-`_create_initial_docs` принимает аддитивный аргумент `description` и делегирует формирование тела
-чистому хелперу (напр. `_render_business_request(work_item_id, name, description) -> str`,
-unit-тестируемому без сети — TC-01/TC-02/TC-06). Заголовок (`# Business Request: {name}`) и
-`Work Item ID` — без изменений; меняется только тело раздела «Description».
-- **Путь A:** `start_pipeline` передаёт `description` в `_create_initial_docs` (`:710`).
-- **Путь B:** `_spawn` расширяет `SELECT` до `..., description` (`src/agents/launcher.py:561`),
-  `_materialize_deferred_branch` принимает `description` 5-м аргументом (`:514–516`, `:582–584`) и
-  передаёт в `_create_initial_docs` (`:538`).
-Привязка: FR-1, FR-2, AC-1, AC-2.
-
-### D3 — Fail-safe fallback и идемпотентность (never-break)
-**Решение: пустое/None/нечитаемое описание → явный безопасный маркер; любая ошибка рендера/чтения →
-деградация на маркер, не отказ создания.**
-
-При `description` пустом/whitespace/`None` (включая `NULL` у исторических задач, для которых колонка
-не заполнялась) хелпер возвращает явный маркер (напр. `_(описание отсутствует в источнике)_`), а не
-голый `TBD`. Создание задачи **никогда** не падает из-за рендера/персиста — все обогащения изолированы
-(`try/except` → fallback). Идемпотентность сохранена: `_create_initial_docs` на Gitea-`422`
-(файл существует) → no-op, ранее записанное тело не перезаписывается (повторная материализация после
-рестарта/реклейма безопасна). Привязка: FR-4, AC-4, AC-6, NFR-1.
-
-### D4 — Что НЕ трогаем (инварианты)
-- **ORCH-088 (анти-stale-base):** момент и условие отложенного среза ветки не меняются — только
-  источник данных дополняется durable-колонкой; `_materialize_deferred_branch` по-прежнему режет ветку
-  из свежего `origin/main` на claim. Перед правкой блока ORCH-088 свериться с
-  `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md` (TRACEABILITY). NFR-3.
-- **ORCH-053 (атомарный анти-dup-claim):** запись `description` — в том же INSERT под
-  `_CREATE_TASK_LOCK`; семантика `(row, created)` не меняется.
-- **Гейты:** `00-business-request.md` — информационный док (гейтом не парсится, `PIPELINE_DOCS.md`
-  §2–§3); `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / имена/семантика `check_*` / machine-verdict —
-  байт-в-байт. AC-5.
-- **Без kill-switch:** это исправление дефекта (улучшение «всегда»), не рискованная фича; безопасность
-  обеспечивается fail-safe fallback и never-break-контрактом (TRZ §7). Обратимость — revert PR
-  (колонка остаётся инертной).
-
-## Альтернативы
-- **Чинить только путь A (без персиста)** — отвергнуто: путь B (self-hosting `orchestrator`, доминирует)
-  останется `TBD`; нарушает BR-2 (приоритетный сценарий).
-- **Хранить описание в `task_content` / payload job'а** — отвергнуто: эфемерно, привязано к жизненному
-  циклу job'а; `_materialize_deferred_branch` читает данные из строки `tasks`, а не из job'а; нет
-  durable-доступа на момент claim.
-- **Re-fetch описания из Plane API в `_materialize_deferred_branch`** — отвергнуто: добавляет сетевой
-  вызов рядом с горячим путём claim (нарушает NFR-4) и вводит зависимость материализации от
-  доступности Plane; ORCH-088 сознательно сделал claim детерминированным.
-- **Отдельная таблица `task_metadata`** — отвергнуто: оверинжиниринг; прецедент `tasks.title` уже
-  канонизирует аддитивную скалярную колонку per-task.
-- **Эскалация в full-cycle (`arch:major-change` / `back-to:analysis`)** — отвергнуто: решение
-  аддитивно, по установленному прецеденту, без нового компонента/QG/стадии/смены БД-движка и без
-  нарушения принципов; ТЗ удовлетворяется штатно.
-
-## Последствия
-- **+** Durable source-backed контекст в `00-business-request.md` на обоих путях; зеркало проверенного
-  прецедента (низкий риск).
-- **+** Ноль изменений машинерии конвейера (гейты/переходы/вердикты/базовая схема) → ноль риска
-  регресса конвейера; enduro-trails не затронут (для него тоже просто рендерится его описание).
-- **−** Схема общей прод-БД растёт на одну колонку → митигировано аддитивным `_ensure_column` (no-op
-  при наличии, без переписывания базового `CREATE TABLE`), обратная совместимость (`NULL` у
-  существующих строк, fallback-маркер при рендере).
-- **−** Уже созданные задачи не ретро-генерируются (вне объёма, принято; колонка `NULL` → fallback).
-- **Откат:** revert PR полностью возвращает прежнее поведение; аддитивная колонка остаётся инертной
-  (без обязательной down-миграции на общей БД).
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-119/01-brd.md`
-- TRZ: `docs/work-items/ORCH-119/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-119/03-acceptance-criteria.md`
-- Data-requirements: `docs/work-items/ORCH-119/08-data-requirements.md`
-- Tech-risks: `docs/work-items/ORCH-119/10-tech-risks.md`
-- Сверено по коду: `src/webhooks/plane.py:482,490,518,710,917,925` · `src/agents/launcher.py:514,531,538,561,582` · `src/db.py:31,125,647,678` · `src/qg/checks.py:62`
-- Инвариант ORCH-088: `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`
-- Стандарт документов / ADR-naming: `docs/_standards/PIPELINE_DOCS.md` §4

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

@@ -1,49 +0,0 @@
----
-work_item: ORCH-119
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-119 — durable-персист `description` задачи
-
-Work Item: **ORCH-119** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable / информационный (гейтом не парсится). Применимо: фикс требует durable-хранения
-> `description` в строке `tasks` для пути B (отложенный срез ветки, ORCH-088).
-
-## Изменения схемы БД
-- **Новая колонка `tasks.description TEXT`** — добавляется идемпотентным
-  `_ensure_column(conn, "tasks", "description", "TEXT")` (`src/db.py`, рядом с `tasks.title`,
-  `src/db.py:125`). Прецедент 1:1 — `tasks.title` / `tasks.track` / `tasks.cancelled_at`.
-- Базовый `CREATE TABLE tasks` (`src/db.py:31–42`) **не трогается**.
-- Индексы **не требуются** (колонка не участвует в выборках/JOIN; читается по PK `tasks.id`).
-- `NULL` по умолчанию; для уже существующих задач остаётся `NULL` (ретро-генерация вне объёма).
-
-## Новые/изменённые сущности
-- **`tasks.description`** — plain-text описание запроса (предпочтительно `description_stripped`
-  Plane-issue), записывается **при создании задачи** внутри атомарного INSERT
-  `create_task_atomic` (`src/db.py:678–683`; список колонок/значений расширяется, параметр
-  `description` аддитивен с дефолтом). Читается на пути B в `_spawn`
-  (`SELECT ..., description FROM tasks`, `src/agents/launcher.py:561`) и передаётся в
-  `_materialize_deferred_branch` → `_create_initial_docs`.
-- Инвариант данных: значение пишется **как есть**, без обрезки/искажения; многострочный текст и
-  markdown-спецсимволы сохраняются (`00-business-request.md` гейтом не парсится — спецсимволы
-  безопасны, NFR-2). Пустое/`NULL` → рендер деградирует на fallback-маркер (ADR-001 D3), не на
-  отказ.
-
-## Совместимость данных / миграции
-- **Аддитивность:** только `ADD COLUMN` через `_ensure_column`; существующая боевая ОБЩАЯ БД и
-  enduro-trails не затронуты (для них `description` тоже просто рендерится — улучшение, не регресс).
-- **Идемпотентность:** `_ensure_column` — no-op при наличии колонки; повторный `init_db` безопасен
-  (TC-05). `_create_initial_docs` на Gitea-`422` — no-op (тело не перезаписывается, TC-06).
-- **Restart-safe / атомарность:** запись `description` — в том же INSERT под `_CREATE_TASK_LOCK`
-  (ORCH-053), без окна «задача создана, описание отсутствует»; реклейм/материализация после
-  рестарта безопасны.
-- **Down-миграция:** не требуется — revert PR оставляет колонку инертной (без обязательного DROP на
-  общей прод-БД).
-- **Влияние на общую прод-БД (self-hosting):** одна аддитивная колонка, без рестарта прода в рамках
-  схемы (применяется на следующем `init_db`); без новых сетевых вызовов в горячем `claim_next_job`
-  (NFR-4).

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

@@ -1,37 +0,0 @@
----
-work_item: ORCH-119
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-119 — source-backed `00-business-request.md`
-
-Work Item: **ORCH-119** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | Чинят только прямой путь A, путь B (отложенный срез, self-hosting) забыт → на `orchestrator` баг остаётся (`TBD`) | Сред. | Выс. | Обязательный integration-тест пути B (TC-03): персист в `tasks` + рендер в `_materialize_deferred_branch`; ADR-001 D1/D2 явно фиксирует оба пути |
-| TR-2 | Регресс схемы/создания задачи при добавлении персиста на ОБЩЕЙ прод-БД | Низ. | Выс. | Аддитивный идемпотентный `_ensure_column` (no-op при наличии), базовый `CREATE TABLE` не трогается; тест обратной совместимости (TC-05) |
-| TR-3 | Падение создания задачи из-за рендера/чтения описания (нарушение never-break) | Низ. | Выс. | Fail-safe fallback-маркер + изоляция обогащения (`try/except`); создание задачи не зависит от рендера (ADR-001 D3, TC-02) |
-| TR-4 | Гонка ORCH-053: окно «задача создана, описание ещё не записано» при отдельном `UPDATE` | Низ. | Сред. | Запись `description` встроена в тот же атомарный INSERT `create_task_atomic` под `_CREATE_TASK_LOCK`, отдельного `UPDATE` нет (ADR-001 D1) |
-| TR-5 | Повторная материализация (рестарт/реклейм) перезаписывает/дублирует тело артефакта | Низ. | Сред. | Идемпотентность `_create_initial_docs` (Gitea `422` → no-op), тело не перезаписывается (TC-06) |
-| TR-6 | Нарушение анти-stale-base инварианта ORCH-088 при правке отложенного среза | Низ. | Выс. | Момент/условие среза НЕ меняются — только источник данных дополняется durable-колонкой; сверка с `docs/work-items/ORCH-088/06-adr/` перед правкой (ADR-001 D4, NFR-3) |
-| TR-7 | Случайная правка `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict | Низ. | Выс. | `00-business-request.md` информационный (не гейтится); анти-регресс-тест импорта гейтов без изменений (TC-07, AC-5) |
-| TR-8 | Markdown-спецсимволы/многострочность описания искажают артефакт | Низ. | Низ. | Рендер plain-text «как есть» без обрезки; артефакт гейтом не парсится → спецсимволы безопасны (NFR-2, TC-06) |
-
-## Сводный вывод
-Доминирующий класс — **операционные риски реализации** (полнота покрытия обоих путей + сохранение
-never-break/идемпотентности/инвариантов ORCH-088/ORCH-053), не архитектурные. Все они закрываются
-обязательными регресс- и edge-тестами (`04-test-plan.yaml` TC-01…TC-07) и точным следованием
-прецеденту `tasks.title`. Эскалация **не требуется**: решение аддитивно, обратимо (revert PR),
-без нового компонента/QG/стадии/смены БД-движка → `arch:major-change` не выставляется, возврат в
-анализ (`back-to:analysis`) не нужен. Остаточный риск для прод-конвейера (self-hosting) — **низкий**:
-фикс не деплоит/не рестартит прод, не трогает `main`, не добавляет сетевых вызовов в горячий
-`claim_next_job` (NFR-4).

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

@@ -1,151 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-119
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-119
-version: 3
----
-
-# Review ORCH-119 — source-backed `00-business-request.md` вместо хардкода `TBD`
-
-## Summary
-
-Узко-скоупленный багфикс (Bug-трек). Раздел «Description» файла `00-business-request.md`
-теперь несёт **фактический текст запроса** из Plane-issue вместо литерала `TBD` — на **обоих**
-путях создания: прямой (путь A) и **отложенный срез ветки** (путь B, ORCH-088, доминирует на
-self-hosting `orchestrator`). Реализация **точно зеркалирует** прецедент `tasks.title`, как и
-предписал ADR-001: аддитивная колонка `tasks.description` через `_ensure_column`, записываемая
-**внутри того же атомарного INSERT** `create_task_atomic` (race-safe vs ORCH-053), читаемая в
-`_spawn` → `_materialize_deferred_branch` на момент claim (без сети в горячем пути, NFR-4). Тело
-рендерится чистым unit-тестируемым хелпером `_render_business_request` с fail-safe
-fallback-маркером.
-
-**Это независимый повторный review (v3).** Все 4 оси перепроверены лично против `origin/main`
-(`f50f61c`, = merge-base): скоуп `src/` — ровно 3 файла, предписанных ТЗ §2 (`webhooks/plane.py`,
-`agents/launcher.py`, `db.py`); тесты — `test_orch119_business_request.py` (новый, +263),
-`test_serial_gate_branch.py` (+spy-арг); `CHANGELOG.md` + work-item доки. **Полный прогон
-`pytest tests/ -q` — зелёный (2215 passed, изолированно от конкурентных сессий).**
-
-## Соответствие ТЗ / AC (ось 1) — PASS
-
-| AC / FR | Статус | Подтверждение |
-|---------|--------|---------------|
-| AC-1 / FR-1 — реальное описание вместо `TBD`, header/`Work Item ID` целы | ✅ | `_render_business_request` рендерит тело из `description`; TC-01 (genuine red→green). |
-| AC-2 / FR-2 — прямой путь A | ✅ | `start_pipeline` передаёт `description` в `_create_initial_docs` (`plane.py:736`); TC-04 ассертит отсутствие `## Description\n\nTBD\n`. |
-| AC-3 / FR-3 — отложенный путь B / durable-персист | ✅ | персист в атомарном INSERT `create_task_atomic` (`plane.py:665`, `db.py`); чтение `SELECT …, description` в `_spawn` → 5-й арг `_materialize_deferred_branch` (`_br_row[3]`); TC-03. |
-| AC-4 / FR-4 — fail-safe fallback | ✅ | `_BUSINESS_REQUEST_FALLBACK` + `try/except` → never-raise; TC-02 (`""`/`"   "`/`"\n\t"`/`None`). |
-| AC-5 — гейты/схема не тронуты | ✅ | коммит не касается `stages.py`/`qg/checks.py`; единственная схема — аддитивная `tasks.description`, базовый `CREATE TABLE tasks` цел; TC-07. |
-| AC-6 — идемпотентность / BC | ✅ | Gitea `422` → `return` (тело не перезаписывается, `plane.py:1006`); `_ensure_column` no-op; TC-05/TC-06. |
-| AC-7 — регресс red→green + полный прогон зелёный | ✅ | На `origin/main` `_render_business_request` **отсутствует** (grep=0) и `TBD` хардкоден (`plane.py:945`) → TC-01 настоящий red; green после. Полный прогон **2215 passed** (изолированно). |
-| AC-8 — сопровождение | ✅ | `CHANGELOG.md` содержит запись ORCH-119. |
-
-`description` определён в scope `start_pipeline` (`plane.py:538`) и **обогащается** из Plane API
-(`plane.py:560–568`) **до** обоих call-site (`:665`, `:736`) — NameError исключён; персистится тот
-же enriched-текст, что уходит analyst-job (`:751`) — консистентно.
-
-## Соответствие ADR (ось 2) — PASS
-
-- **D1** (аддитивная колонка в атомарном INSERT) — реализовано буквально:
-  `_ensure_column(conn,"tasks","description","TEXT")` рядом с `tasks.title`; запись встроена в
-  существующий INSERT `create_task_atomic`, не отдельным UPDATE → нет race-окна vs ORCH-053. ✅
-- **D2** (чистый рендер-хелпер + проброс на обоих путях) — `_render_business_request`
-  чистый/network-free; проброс A и B. ✅
-- **D3** (fail-safe fallback + идемпотентность) — маркер + never-raise + 422-no-op. ✅
-- **D4** (инварианты) — ORCH-088 момент/условие отложенного среза не меняются (дополняется только
-  источник данных), ORCH-053 семантика `(row, created)` цела, гейты байт-в-байт, без kill-switch
-  (обосновано — фикс дефекта). ✅
-- **Трассировка (TRACEABILITY):** правки блоков с маркерами **ORCH-088**
-  (`_materialize_deferred_branch`) и **ORCH-053** (`create_task_atomic`) сверены с их `06-adr` —
-  аддитивные, все новые параметры с дефолтами; зафиксированные инварианты не сломаны; комментарии
-  кода корректно ссылаются на оба ADR. ✅
-- Сквозной (global) ADR не требуется — локальное аддитивное решение по прецеденту. ✅
-
-## Качество кода (ось 3) — PASS
-
-- Чистый, network-free, unit-тестируемый хелпер; docstrings на всех новых/изменённых функциях. ✅
-- never-raise контракт соблюдён (`try/except` в рендере; создание задачи не падает). ✅
-- BC: все добавленные параметры аддитивны с дефолтами; единственный прочий потребитель сигнатуры
-  (`_docs_spy` в `test_serial_gate_branch.py`) синхронно обновлён под аддитивный `description=None`. ✅
-- **Багфикс-регресс (ORCH-019 / BR-4) — фиксатор присутствует:** TC-01 настоящий red до фикса
-  (`_render_business_request` отсутствовал + `_create_initial_docs` хардкодил `TBD` на `main`),
-  green после; усилен TC-04 (бьёт реальный баг-путь `_create_initial_docs`). ✅
-- Тесты содержательные: 7 TC покрывают регресс, fallback (4 параметра), оба пути, schema-BC,
-  идемпотентность 422, multiline/спецсимволы verbatim, анти-регресс гейтов. ✅
-- **Личная проверка:** `test_orch119_business_request.py` + `test_serial_gate_branch.py` — 13 passed;
-  `test_stage_engine.py` — 52 passed (изолированно); полный прогон — 2215 passed. ✅
-
-## Документация (ось 4) — PASS
-
-Изменён `src/` → проверка обязательна. Документация обновлена в том же PR:
-- **`CHANGELOG.md`** — подробная запись ORCH-119 (AC-8). ✅
-- **ADR-001** (`06-adr/ADR-001-source-backed-business-request-doc.md`) + **`08-data-requirements.md`**
-  (документирует схему `tasks.description`) — присутствуют, исчерпывающи. ✅
-- **API** — изменений нет (ТЗ §4) → таблица API в `docs/architecture/README.md` обновления не
-  требует. ✅
-- **Стадии/QG** — не тронуты → `docs/architecture/README.md` / `internals.md` обновления не
-  требуют. ✅
-- **Витрина `docs/overview/` (ORCH-011):** `tech-agents.md` по-прежнему верно указывает
-  `00-business-request.md` как вход аналитика; `tech-data-model.md` описывает `tasks`
-  концептуально (без перечня колонок) — добавление колонки его не устаревает; смена **тела**
-  артефакта (внутренняя деталь генерации) описанных стадий/гейтов/агентов/способностей не меняет.
-  Обновление не требуется. ✅
-- **`README.md` «Известные ограничения» (ORCH-079):** проверено — TBD-баг `00-business-request.md`
-  **не** числится среди 3 открытых ограничений (Telegram-48h / intra-repo deps / batch-автоном) —
-  закрывать/снимать нечего, обновление README не требуется. ✅
-- **Центрального schema-дока колонок `tasks` нет** — конвенция проекта: per-task скалярные колонки
-  документируются ADR задачи + data-requirements + CHANGELOG (так же оформлены `tasks.title` /
-  `tasks.track` / `tasks.cancelled_at`). ORCH-119 ей следует. ✅
-
-**Итог по документации:** при изменении `src/` документация обновлена в том же PR — P0 «`src/`
-изменён, документация не обновлена» **не наступает**.
-
-## Findings
-
-### P0 — Blocker
-- Нет.
-
-### P1 — Must fix
-- Нет.
-
-### P2 — Should fix
-- Нет.
-
-### P3 — Nice-to-have (не блокирует)
-- [ ] **`CHANGELOG.md` over-claim после rebase.** Хвост записи ORCH-119 описывает «Дополнительно в
-  том же PR починена тест-гермеичность `tests/test_orch123_staging_runner_exec.py`…». Этот файл
-  **отсутствует** в diff против `origin/main` — фикс (`fresh_db` пинит `repos_dir`) уже в `main`
-  (проверено: `git show origin/main:tests/test_orch123_staging_runner_exec.py` уже содержит пин).
-  Описывает изменение вне фактического скоупа PR (артефакт rebase). Безвредно (ядро ORCH-119
-  задокументировано точно), но для аккуратности — подрезать хвост. На корректность фикса не влияет.
-- [ ] `tests/test_orch119_business_request.py` мутирует `os.environ` (`ORCH_DB_PATH`/
-  `ORCH_REPOS_DIR`) на уровне модуля — добавляет к общей import-pollution-поверхности сьюта.
-  Соответствует существующей конвенции многих тест-файлов проекта (не новый грех), на корректность
-  не влияет.
-- [ ] `_render_business_request`: `try/except Exception` вокруг `(description or "").strip()` —
-  `.strip()` на строке не бросает, ветка недостижима. Намеренный never-break «belt-and-suspenders» в
-  стиле кодбейза; оставить как есть допустимо.
-
-## Документация
-
-**Статус: обновлена в том же PR — достаточно.** `CHANGELOG.md` (AC-8) + ADR-001 +
-`08-data-requirements.md` (схема `tasks.description`) — присутствуют и исчерпывающи. Витрина
-`docs/overview/`, обзорный `README.md` («Известные ограничения»),
-`PIPELINE_DOCS.md`/`HANDOFF_PROTOCOL.md` проверены явно — не устаревают (артефакт остаётся
-информационным, продюсер/владелец/гейт-статус не изменились; TBD-баг не числился среди открытых
-ограничений). Центрального schema-дока колонок `tasks` нет — аддитивная колонка документирована по
-конвенции (ADR + data-requirements + CHANGELOG, как `tasks.title`/`track`/`cancelled_at`).
-**Необновлённой обязательной документации не найдено.** (Единственный документ-нюанс — P3-over-claim
-в `CHANGELOG.md` про вне-скоупный `test_orch123`, не блокирует.)
-
-## Вердикт
-
-**APPROVED.** Нет P0/P1/P2. Все AC/FR/ADR удовлетворены; реализация — точное зеркало одобренного
-прецедента `tasks.title` с нулевым касанием конвейерной машинерии и сохранёнными инвариантами
-ORCH-088/ORCH-053; обязательный регресс-тест-фиксатор присутствует (genuine red→green, проверено
-против `origin/main`); полный прогон зелёный (2215 passed). Документация синхронна. Готово к стадии
-`testing`.

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

@@ -1,40 +0,0 @@
----
-result: PASS
-work_item: ORCH-119
-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):
-```
-............................................. [ 65%]
-........................................................................ [ 68%]
-........................................................................ [ 71%]
-........................................................................ [ 74%]
-........................................................................ [ 78%]
-........................................................................ [ 81%]
-........................................................................ [ 84%]
-........................................................................ [ 87%]
-........................................................................ [ 91%]
-........................................................................ [ 94%]
-........................................................................ [ 97%]
-.......................................................                  [100%]
-=============================== warnings summary ===============================
-src/config.py:8
-  /repos/_wt/orchestrator/feature_ORCH-119-bug-00-business-request-md-is-/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
-2215 passed, 1 warning in 105.47s (0:01:45)
-```

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

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

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-119
-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 0c163a41-a2a8-4884-b1f7-77017bce8d50 (HTTP 204)
-  ·      CLEANUP DB: no task row found for plane_id=0c163a41-a2a8-4884-b1f7-77017bce8d50
-  ·      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-119/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-119
-
-Детерминированный 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-120/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: BUG: analyst open questions must move task to Needs Input
-
-Work Item ID: ORCH-120
-
-## Description
-
-TBD

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

@@ -1,171 +0,0 @@
----
-work_item: ORCH-120
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 01 — BRD (бизнес-требования): ORCH-120 — Открытые вопросы аналитика должны переводить задачу в Needs Input
-
-Work Item: **ORCH-120** · Repo: **orchestrator** · Стадия: analysis
-
-> ⚠️ **Эскалация в полный цикл (`escalate: full-cycle`).** Это формально баг (метка `BUG:` в
-> заголовке), но фикс требует архитектурных решений (правило приоритета веток в
-> `_handle_analysis_approved_flow`, интеграция с осью «пауза» ORCH-124, семантика устаревания
-> `01-questions.md`, стандартизация нового pipeline-артефакта) — нужен ADR. Поэтому выпущен
-> **полный** analysis-пакет (01/02/03/04), а не облегчённый bug-shaped. Оператор снимает багфикс-трек
-> командой `POST /bug-fast-track/escalate?work_item=ORCH-120`, после чего задача идёт через стадию
-> `architecture` (ADR-001 D5 ORCH-019). Открытые проектные вопросы для архитектора — §6 (DQ-1…DQ-4).
-
-## 1. Бизнес-контекст и проблема
-
-При запуске конвейера аналитик (`analyst`) получает бизнес-запрос и **обязан** выпустить 4 файла
-(`01-brd` / `02-trz` / `03-acceptance-criteria` / `04-test-plan.yaml`), иначе exit-гейт стадии
-`analysis` не пройдёт. Если бизнес-запрос неоднозначен или неполон (классический пример — тело
-запроса `Description: TBD`), у аналитика **нет рабочего канала** запросить уточнения у заказчика: он
-вынужден **домысливать** требования и всё равно сдать 4 файла. Сфабрикованный пакет уходит в
-`In Review` / `architecture` — то есть весь конвейер строит решение поверх выдуманных требований.
-
-**Парадокс:** механизм «вопросы → Needs Input» в движке **уже есть, но мёртв**. Код
-`src/stage_engine.py::_handle_analysis_approved_flow` (стр. 769–786) читает файл
-`docs/work-items/<wid>/01-questions.md` и при его наличии вызывает `set_issue_needs_input(...)` +
-комментарий в Plane + Telegram. Однако:
-
-1. **Контракт не доведён до аналитика.** Промпт `.openclaw/agents/analyst.md` **нигде** не упоминает
-   `01-questions.md`: ни в `<deliverables>`, ни в `<task>`. Скелета `docs/_templates/01-questions.md`
-   нет, в манифесте `docs/_standards/PIPELINE_DOCS.md` артефакт не описан. Аналитик физически не
-   знает, что у него есть канал «задать блокирующий вопрос», поэтому домысливает.
-2. **Ошибка приоритета веток.** В `_handle_analysis_approved_flow` ветка `files_ok` (все 4 файла на
-   месте — `check_analysis_complete`) проверяется **первой** и делает `return` (стр. 711–767). Ветка
-   `01-questions.md` (стр. 769) достижима, только если 4 файла НЕ полны. Значит, если аналитик сдал и
-   неполный/заглушечный пакет, и `01-questions.md` — движок уйдёт в `In Review`, проигнорировав
-   блокирующие вопросы. «Есть вопросы» должно иметь приоритет над «файлы на месте».
-3. **Needs-Input блокирует serial-gate репо.** Задача в Needs Input остаётся в стадии `analysis`
-   (Plane-статус — слой B индикации, ORCH-066, **не** меняет `tasks.stage`) и при этом
-   `paused_at IS NULL`. По правилу serial-gate (ORCH-088) такая «активная» задача держит FIFO репо
-   закрытым: пока заказчик не ответит (часы/дни), ни одна следующая задача `orchestrator` не войдёт в
-   `analysis`. ORCH-124 ввёл ортогональную ось «пауза» (`tasks.paused_at` + `POST /serial-gate/pause|
-   resume`) ровно для случая «приостановлено, но не блокирует» — Needs-Input обязан её использовать.
-4. **Нет гигиены устаревшего `01-questions.md`.** После ответа заказчика `handle_status_start`
-   перезапускает аналитика (`src/webhooks/plane.py:317–381`). Если перезапущенный аналитик теперь
-   выпускает полный валидный пакет, старый `01-questions.md` остаётся в ветке. Без правила
-   «устаревания» он либо игнорируется (если `files_ok` побеждает), либо вечно перезапускает Needs
-   Input (если вопросы получат приоритет). Нужно явное правило supersede.
-
-Корень — **разрыв контракта между промптом аналитика и движком** плюс **3 смежных дефекта потока**
-(приоритет, блокировка очереди, устаревание). ORCH-120 закрывает их как единый «правильный поток
-Needs Input».
-
-**Связь с предшественниками (контекст резюма из бэклога):** задача разморожена после корневых
-фиксов **ORCH-124** (ось «пауза без блокировки» — необходимый фундамент для требования BR-3) и
-**ORCH-126** (queued-job не застревает со stale `run_id`/`pid` — гарантирует, что перезапущенный
-после ответа аналитик-job реально заберётся из очереди). Оба — предусловия, а не объём ORCH-120.
-
-## 2. Объём (scope)
-
-### В объёме
-- **Контракт промпта аналитика:** `.openclaw/agents/analyst.md` явно документирует канал
-  «блокирующие открытые вопросы → пиши `01-questions.md`, НЕ фабрикуй 4 deliverables», с форматом и
-  правилом поведения на перезапуске (прочитать ответы, снять устаревшие вопросы).
-- **Канон артефакта:** скелет `docs/_templates/01-questions.md` + строка в манифесте
-  `docs/_standards/PIPELINE_DOCS.md` (артефакт-сигнал Needs Input; **не** machine-verdict-док, гейтом
-  не парсится).
-- **Приоритет веток в движке:** в `_handle_analysis_approved_flow` блокирующие открытые вопросы
-  получают корректный приоритет → задача с вопросами надёжно достигает Needs Input.
-- **Неблокирование serial-gate:** переход в Needs Input не держит FIFO репо закрытым неопределённо
-  долго (интеграция с осью «пауза» ORCH-124).
-- **Гигиена устаревания:** перезапущенный аналитик, выпустивший полный валидный пакет без свежих
-  вопросов, приводит к `In Review`, а не к повторному Needs Input.
-- **Корректность resume-петли:** ответ заказчика → перезапуск аналитика → снятие паузы (unpark), job
-  забирается из очереди.
-- **Обязательный регресс-тест** (красный до фикса, зелёный после) + анти-дрейф структурные тесты.
-
-### Вне объёма
-- **Расширение владения Needs Input на других агентов.** ORCH-066 BR-10 фиксирует: Needs Input —
-  только у аналитика. Механизм не расширяется на architect/developer/reviewer/tester/deployer.
-- **Новые QG-проверки и новые рёбра `STAGE_TRANSITIONS`.** Поток вопросов — pre-gate-ветка движка,
-  не Quality Gate. `check_analysis_complete`/`check_analysis_approved` — байт-в-байт.
-- **Изменение семантики самого гейта `analysis`** (4 файла по-прежнему обязательны для прохождения
-  exit-гейта `analysis → architecture`).
-- **Авто-ответ на вопросы / LLM-триаж ответов заказчика.** Ответы читает человек/аналитик, а не
-  отдельный автомат.
-- **Машинерия багфикс-трека (ORCH-019)** и любые изменения вне аналитической стадии.
-
-## 3. Заинтересованные стороны
-- **Заказчик / оператор (Слава)** — получает осмысленный запрос уточнений вместо выдуманных
-  требований; отвечает в Plane и возвращает задачу в работу.
-- **Конвейер `orchestrator` (self-hosting)** — перестаёт строить решения поверх домыслов; serial-gate
-  репо не клинит на задаче, ждущей человека.
-- **Аналитик-агент** — получает легитимный канал «не знаю — спрошу» вместо принуждения к фабрикации.
-- **Другие проекты на общем инстансе (enduro-trails)** — не затронуты (нулевая регрессия при
-  отсутствии `01-questions.md` и вне self-hosting-области).
-
-## 4. Бизнес-требования (BR)
-- **BR-1** — Аналитик, столкнувшийся с **блокирующей** неоднозначностью бизнес-запроса, ОБЯЗАН иметь
-  документированный канал запроса уточнений (`01-questions.md`) и НЕ должен фабриковать 4 deliverables
-  «лишь бы пройти гейт». Промпт `.openclaw/agents/analyst.md` описывает этот канал.
-- **BR-2** — Наличие блокирующих открытых вопросов переводит задачу в Plane-статус **Needs Input** и
-  **останавливает** продвижение по конвейеру (не `In Review`, не `architecture`), даже если на диске
-  присутствуют частичные/заглушечные deliverables. Приоритет «вопросы» > «файлы на месте».
-- **BR-3** — Задача в Needs Input **не блокирует** per-repo serial-gate FIFO неопределённо долго:
-  следующая задача `orchestrator` может войти в `analysis`, пока первая ждёт ответа человека.
-- **BR-4** — После ответа заказчика (возврат issue в рабочий статус) аналитик перезапускается, читает
-  ответы и выпускает пакет. Если пакет полон и валиден и свежих блокирующих вопросов нет → задача
-  переходит в `In Review` (устаревший `01-questions.md` не должен повторно ронять её в Needs Input).
-- **BR-5** — Поведение **обратимо и выборочно**: при отсутствии `01-questions.md` и выключенных
-  под-флагах поток Needs Input/паузы — байт-в-байт как до ORCH-120 (нулевая регрессия для enduro и
-  для штатной задачи без вопросов).
-- **BR-6** — `01-questions.md` стандартизирован как pipeline-артефакт (скелет в `docs/_templates/` +
-  строка манифеста `PIPELINE_DOCS.md`): он сигнальный, **не** machine-verdict (гейтом не парсится).
-
-## 5. Нефункциональные требования (NFR)
-- **NFR-1 (never-raise / fail-safe)** — Любая ошибка новой логики (чтение файла, park-вызов,
-  определение приоритета) НЕ роняет `advance_stage`/launcher и деградирует к безопасному прежнему
-  поведению (как существующие leaf'ы `serial_gate`/`labels`/`cancel`).
-- **NFR-2 (обратная совместимость)** — Стадии, кроме `analysis`, и Needs-Input-владение (ORCH-066) —
-  не трогаются. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / семантика
-  exit-гейта `analysis` — байт-в-байт.
-- **NFR-3 (инварианты serial-gate)** — Интеграция с паузой не регрессирует ORCH-088 (анти-stale-base:
-  отложенный срез ветки) и ORCH-124 (терминал `{done,cancelled}` и оси `task_deps`/`freeze` —
-  не читают `paused_at`; пауза их не обходит).
-- **NFR-4 (self-hosting-безопасность)** — Поток только меняет Plane-статус/паузу/комментарий и читает
-  worktree: не деплоит, не рестартит прод-контейнер, не пушит в `main`, не трогает detached-процессы.
-- **NFR-5 (наблюдаемость)** — Переход в Needs Input и park/unpark логируются структурно; состояние
-  паузы видно в блоке `serial_gate` `GET /queue` (ORCH-124 уже отдаёт `paused`).
-
-## 6. Допущения и ограничения
-- **Допущение:** механизм чтения `01-questions.md` и `set_issue_needs_input` рабочие — задача в
-  основном **активирует и достраивает** существующий путь, а не строит его с нуля.
-- **Допущение:** промпт `cat`-ается из worktree в момент запуска (ORCH-077 loading-model) → новый
-  контракт аналитика вступает в силу на следующем worktree от `main` без прод-рестарта.
-- **Ограничение:** Plane-статус **Needs Input** должен существовать на доске проекта (ключ
-  `needs_input` уже в `plane_sync._DEFAULT_STATES`) — инфра-предусловие выполнено для ORCH.
-- **Открытые проектные вопросы для архитектора (решить в `06-adr/`, НЕ в analysis):**
-  - **DQ-1** — Парковать задачу при Needs Input **автоматически** (`db.set_task_paused` в момент
-    перехода) или оставить park **операторским** (`POST /serial-gate/pause`)? Trade-off:
-    авто-park снимает риск стопора очереди (BR-3), но связывает индикацию (слой B) с осью планировщика.
-  - **DQ-2** — Механизм устаревания `01-questions.md` (BR-4): удалять файл при выпуске полного пакета /
-    приоритет по «вопросы свежее deliverables» (mtime/commit) / явный маркер «answered». Любой выбор
-    обязан быть детерминированным и не зависеть от сетевого Plane.
-  - **DQ-3** — Точное правило приоритета в `_handle_analysis_approved_flow`: проверять
-    `01-questions.md` ДО `files_ok`, либо ввести предикат «вопросы активны» с учётом DQ-2.
-  - **DQ-4** — Коллизия номера `01-questions.md` с `01-brd.md`. Движок читает именно `01-questions.md`
-    (`stage_engine.py:771`) — менять путь = код-изменение; стандарт документирует фактический путь.
-- **Ограничение по флагам:** новое поведение (приоритет вопросов / авто-park) — под kill-switch с
-  безопасным дефолтом, чтобы откат был байт-в-байт (BR-5).
-
-## 7. Критерии успеха
-Аналитик при блокирующей неоднозначности пишет `01-questions.md`, задача надёжно переходит в Needs
-Input, **не** блокирует serial-gate репо, после ответа заказчика возобновляется и выпускает корректный
-пакет; при отсутствии вопросов — поведение прежнее. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-- Связывание индикации (Plane-статус) с осью планировщика (пауза) при авто-park (DQ-1) — риск
-  непреднамеренного park; смягчение — kill-switch + явный лог.
-- Устаревший `01-questions.md` зацикливает Needs Input (DQ-2) — смягчение детерминированным
-  supersede-правилом + регресс-тест BR-4.
-- Регресс serial-gate (ORCH-088/124) при неаккуратной интеграции паузы — смягчение тестами NFR-3.
-Детали и оценка — `10-tech-risks.md` (заполняет архитектор).

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

@@ -1,111 +0,0 @@
----
-work_item: ORCH-120
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-120 — Открытые вопросы аналитика → Needs Input
-
-Work Item: **ORCH-120** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование (выбор механизма приоритета, авто-park vs operator-park, способ
-> устаревания `01-questions.md`) — задача архитектора (`06-adr/`). Открытые проектные вопросы —
-> BRD §6 (DQ-1…DQ-4).
-
-## 1. Сводка изменения
-
-Активировать и достроить уже существующий, но мёртвый путь «аналитик задаёт блокирующие вопросы →
-задача в Needs Input». Четыре связанных изменения: (1) **контракт промпта** аналитика +
-**канон артефакта** `01-questions.md`; (2) **приоритет** ветки вопросов над веткой «файлы готовы» в
-`_handle_analysis_approved_flow`; (3) **неблокирование serial-gate** через ось «пауза» ORCH-124;
-(4) **гигиена устаревания** `01-questions.md` на resume-петле. `STAGE_TRANSITIONS`, реестр `QG_CHECKS`,
-семантика и имена `check_*`, machine-verdict-ключи, схема существующих таблиц — **не меняются**.
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `.openclaw/agents/analyst.md` | **изменить** — добавить контракт «блокирующие вопросы → `01-questions.md`, не фабриковать deliverables» (в `<task>` + `<deliverables>` + поведение на resume); сохранить канон 52d (5 секций, 6 полей frontmatter). |
-| `docs/_templates/01-questions.md` | **создать** — скелет артефакта открытых вопросов (формат: контекст / список блокирующих вопросов с вариантами / что разблокирует анализ). |
-| `docs/_standards/PIPELINE_DOCS.md` | **изменить** — строка манифеста §2 для `01-questions.md` (владелец `analyst`, категория `when-applicable`, стадия `analysis`, «механизм: ветка Needs Input в `_handle_analysis_approved_flow`», machine-key — «нет, сигнальный»). |
-| `src/stage_engine.py` | **изменить** — `_handle_analysis_approved_flow`: правило приоритета (вопросы активны → Needs Input до/вместо `files_ok`, см. DQ-3); опц. вызов park (DQ-1); гигиена устаревания (DQ-2). Всё never-raise. |
-| `src/webhooks/plane.py` | **изменить (точечно)** — `handle_status_start` (analysis-resume ветка, стр. 317–381): при перезапуске аналитика снять паузу (`clear_task_paused`/`POST` эквивалент), чтобы re-enqueued job был claimable. |
-| `src/db.py` | **переиспользовать** — `set_task_paused` / `clear_task_paused` / `is_task_paused` (ORCH-124, уже есть; новых колонок НЕ вводить). |
-| `src/serial_gate.py` | **не менять кодом** — ось «пауза» уже исключает `paused_at NOT NULL` (ORCH-124); ORCH-120 лишь корректно её триггерит. |
-| `src/config.py` | **изменить** — добавить kill-switch(и) нового поведения (напр. `analyst_questions_gate_enabled`, опц. `analyst_needs_input_autopause_enabled`), env `ORCH_*`, безопасные дефолты. |
-| `src/main.py` | **возможно** — наблюдаемость в блоке `GET /queue` (если потребуется доп. поле); pause/resume эндпоинты ORCH-124 переиспользуются как есть. |
-
-> Точный набор правок в `src/**` финализирует архитектор (DQ-1…DQ-3). TRZ фиксирует **наблюдаемый
-> контракт**, а не конкретную реализацию ветвления.
-
-## 3. Функциональные требования
-
-### FR-1 — Контракт промпта аналитика (BR-1, BR-6)
-`.openclaw/agents/analyst.md` явно описывает: при **блокирующей** неоднозначности бизнес-запроса
-аналитик пишет `docs/work-items/<plane-id>/01-questions.md` (через Write tool) со списком конкретных
-блокирующих вопросов и **не** выпускает сфабрикованные 4 deliverables. Указывается поведение на
-перезапуске: прочитать свежие комментарии-ответы в Plane, снять/не переписывать устаревшие вопросы,
-выпустить полный пакет. Промпт остаётся в каноне 52d (5 секций, 6 полей schema, без `model:`).
-
-### FR-2 — Приоритет «вопросы активны» (BR-2)
-В `_handle_analysis_approved_flow` наличие **активных** блокирующих вопросов (`01-questions.md`,
-с учётом supersede-правила DQ-2) ведёт к `set_issue_needs_input(...)` + комментарий + Telegram +
-`result.note = "analysis-needs-input"` **независимо** от того, присутствуют ли на диске 4 файла.
-Сейчас ветка `files_ok` (стр. 711) делает `return` до проверки вопросов (стр. 769) — порядок/предикат
-исправляется так, что вопросы имеют приоритет. Happy-path (нет вопросов, 4 файла) → `In Review`
-(`analysis-in-review`) без изменений.
-
-### FR-3 — Неблокирование serial-gate (BR-3, NFR-3)
-Переход в Needs Input приводит к тому, что задача **исключается** из «активного» предиката serial-gate
-(ORCH-088), чтобы следующая задача `orchestrator` могла войти в `analysis`. Механизм — ось «пауза»
-ORCH-124: `paused_at NOT NULL` уже исключается в `build_claim_clause`/`repo_has_active_task`/
-`_per_repo_snapshot`. Авто-park vs operator-park — DQ-1. Терминал `{done,cancelled}` и оси
-`task_deps`/`freeze` не читают `paused_at` — пауза их не обходит (инвариант ORCH-124 цел).
-
-### FR-4 — Resume + unpark (BR-4)
-`handle_status_start` (analysis-ветка) при перезапуске аналитика после ответа заказчика снимает паузу
-(`clear_task_paused`), чтобы re-enqueued analyst-job был claimable (совместно с фиксом ORCH-126 о
-stale `run_id`/`pid`). Существующий relaunch-guard ORCH-090 (relaunch только для `analysis`) — не
-ослабляется.
-
-### FR-5 — Гигиена устаревания `01-questions.md` (BR-4)
-Перезапущенный аналитик, выпустивший полный валидный пакет (4 файла) **без свежих** блокирующих
-вопросов, приводит к `In Review`, а не к повторному Needs Input. Реализация supersede — DQ-2
-(детерминированно, offline, без сетевого Plane).
-
-### FR-6 — Обратимость / kill-switch (BR-5)
-Новое поведение под kill-switch с безопасным дефолтом: при отсутствии `01-questions.md` и выключенном
-под-флаге поток Needs Input/паузы — **байт-в-байт** как до ORCH-120. Скоуп — self-hosting
-(`orchestrator`); enduro не затронут.
-
-## 4. Изменения API
-**Нет новых эндпоинтов.** Переиспользуются существующие `POST /serial-gate/pause` и
-`POST /serial-gate/resume` (ORCH-124, `src/main.py:396/442`) как операторский путь park/unpark (если
-архитектор выберет operator-park, DQ-1). При авто-park вызывается `db.set_task_paused` напрямую из
-движка. Блок `serial_gate` в `GET /queue` уже отдаёт `paused` — возможно дополнение полем-причиной.
-
-## 5. Изменения схемы БД
-**Нет.** Колонка `tasks.paused_at` уже введена ORCH-124 (`src/db.py:160`, `_ensure_column`). Новых
-таблиц/колонок/индексов ORCH-120 не вводит.
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** `01-questions.md` — сигнальный артефакт, **не** machine-verdict-док; гейтом не парсится.
-`check_analysis_complete` / `check_analysis_approved` / `_parse_*` — байт-в-байт. Поток вопросов
-остаётся pre-gate-веткой движка (`_handle_analysis_approved_flow`), как и был.
-
-## 7. Совместимость / регресс
-- **Обратная совместимость:** при отсутствии `01-questions.md` ветвление `_handle_analysis_approved_flow`
-  и serial-gate работают как прежде (NFR-2). Стадии ≠ `analysis` — не трогаются.
-- **Kill-switch:** новое поведение (приоритет вопросов / авто-park) выключаемо → откат байт-в-байт
-  (FR-6/BR-5). Область — self-hosting `orchestrator`.
-- **Инварианты:** ORCH-066 (Needs Input только у аналитика) — не расширяется; ORCH-088/124 (анти-stale-base,
-  терминал/freeze/deps оси) — не регрессируют (NFR-3); never-raise (NFR-1); self-hosting-безопасность
-  (NFR-4: без прод-рестарта/`main`-push).
-- **Полный регресс** `pytest tests/` остаётся зелёным; обязательный новый регресс-тест (TC-01) красный
-  до фикса и зелёный после.
-- **Трассировка маркеров (ORCH-078):** правки в `_handle_analysis_approved_flow`/`serial_gate`/
-  `plane.py` сверяются с ADR ORCH-066 / ORCH-088 / ORCH-124 перед изменением (не сломать инварианты).

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

@@ -1,142 +0,0 @@
----
-work_item: ORCH-120
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-120 — Открытые вопросы аналитика → Needs Input
-
-Work Item: **ORCH-120** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
-считается провалом). Reviewer проверяет их буквально по файлам репозитория и тестам.
-
----
-
-## AC-1 — Приоритет вопросов над «файлы готовы» (регресс, обязательный)
-
-**Условие:** `_handle_analysis_approved_flow` вызывается после аналитика, в worktree присутствуют
-ОДНОВРЕМЕННО все 4 файла (`01-brd`/`02-trz`/`03-acceptance-criteria`/`04-test-plan.yaml`) И
-`01-questions.md` с активными блокирующими вопросами.
-- **PASS:** вызывается `set_issue_needs_input(work_item_id)`, `result.note == "analysis-needs-input"`,
-  `set_issue_in_review` НЕ вызывается, задача НЕ продвигается на `architecture`.
-- **FAIL:** задача уходит в `In Review` / `architecture` (текущее ошибочное поведение — ветка
-  `files_ok` побеждает).
-
----
-
-## AC-2 — Только вопросы, без deliverables (сохранение существующего поведения)
-
-**Условие:** `01-questions.md` присутствует, 4 файла отсутствуют.
-- **PASS:** `set_issue_needs_input` вызван, `result.note == "analysis-needs-input"`, текст вопросов
-  передан в Plane-комментарий и Telegram.
-- **FAIL:** задача не переходит в Needs Input или падает с исключением.
-
----
-
-## AC-3 — Happy-path без регресса
-
-**Условие:** `01-questions.md` отсутствует, все 4 файла на месте.
-- **PASS:** `set_issue_in_review` вызван, `result.note == "analysis-in-review"`, запрошен статус
-  `Approved` (поведение байт-в-байт как до ORCH-120, включая autoApprove-ветку ORCH-089).
-- **FAIL:** задача ошибочно уходит в Needs Input либо happy-path-комментарий/статус изменился.
-
----
-
-## AC-4 — Needs Input не блокирует serial-gate репо
-
-**Условие:** задача A `orchestrator` в `analysis` переведена в Needs Input по `01-questions.md`;
-существует более поздняя задача B того же репо.
-- **PASS:** A исключена из «активного» предиката serial-gate (через `paused_at NOT NULL`, ось
-  ORCH-124); B может войти в `analysis` (claim analyst-job B не блокируется задачей A).
-- **FAIL:** A продолжает держать FIFO репо закрытым (`repo_has_active_task` возвращает True из-за A),
-  B не может стартовать, пока заказчик не ответит.
-
----
-
-## AC-5 — Resume снимает паузу и перезапускает аналитика
-
-**Условие:** заказчик ответил и вернул issue в рабочий статус (In Progress / To Analyse) на стадии
-`analysis`; активного job нет.
-- **PASS:** `handle_status_start` снимает паузу (`paused_at` → NULL) и enqueue'ит analyst-job; job
-  забирается из очереди (не застревает со stale `run_id`/`pid`, ср. ORCH-126); relaunch-guard ORCH-090
-  (только `analysis`) соблюдён.
-- **FAIL:** задача остаётся paused (job не claimable) ИЛИ перезапуск происходит на не-`analysis` стадии
-  (нарушение ORCH-090).
-
----
-
-## AC-6 — Гигиена устаревшего `01-questions.md`
-
-**Условие:** перезапущенный аналитик выпустил полный валидный пакет (4 файла) без свежих блокирующих
-вопросов; устаревший `01-questions.md` от прошлого прогона мог остаться.
-- **PASS:** задача переходит в `In Review` (`analysis-in-review`), а НЕ повторно в Needs Input;
-  supersede-правило (DQ-2) применено детерминированно и offline.
-- **FAIL:** устаревший `01-questions.md` повторно роняет задачу в Needs Input (бесконечная петля).
-
----
-
-## AC-7 — Контракт промпта аналитика (анти-дрейф)
-
-**Условие:** содержимое `.openclaw/agents/analyst.md`.
-- **PASS:** промпт документирует канал `01-questions.md` (блокирующие вопросы → Needs Input, не
-  фабриковать deliverables) И сохраняет канон 52d (5 XML-секций, 6 полей frontmatter-схемы, без
-  `model:`); `tests/test_agent_prompts_canon.py` зелёный, добавлен assert наличия контракта вопросов.
-- **FAIL:** канал не документирован, либо нарушен канон 52d, либо тест канона красный.
-
----
-
-## AC-8 — Канон артефакта `01-questions.md`
-
-**Условие:** наличие скелета и записи в манифесте.
-- **PASS:** `docs/_templates/01-questions.md` существует; `docs/_standards/PIPELINE_DOCS.md` содержит
-  строку манифеста для `01-questions.md` (владелец `analyst`, категория `when-applicable`, механизм
-  «ветка Needs Input», не machine-verdict).
-- **FAIL:** скелет или строка манифеста отсутствуют.
-
----
-
-## AC-9 — Обратимость / нулевая регрессия
-
-**Условие:** kill-switch нового поведения выключен ИЛИ репо вне self-hosting-области (enduro-trails).
-- **PASS:** ветвление `_handle_analysis_approved_flow` и serial-gate работают **байт-в-байт** как до
-  ORCH-120; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД не изменены.
-- **FAIL:** обнаружено отличие поведения при выключенном флаге / для enduro.
-
----
-
-## AC-10 — never-raise / self-hosting-безопасность
-
-**Условие:** сбой новой логики (ошибка чтения файла, park-вызова, определения приоритета).
-- **PASS:** `advance_stage`/launcher не падает, деградирует к безопасному прежнему поведению + WARNING;
-  поток не деплоит, не рестартит прод-контейнер, не пушит в `main`.
-- **FAIL:** исключение всплывает наружу / встаёт конвейер / затронут прод/`main`.
-
----
-
-## AC-11 — Полный регресс зелёный
-
-**Условие:** `pytest tests/ -q`.
-- **PASS:** вся сюита зелёная; новый обязательный регресс-тест (AC-1 / TC-01) красный на коде до фикса
-  и зелёный после.
-- **FAIL:** любой тест красный, либо регресс-тест проходит и на дофиксовом коде (не доказывает баг).
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-2 / FR-2 (регресс) |
-| AC-2 | BR-2 / FR-2 |
-| AC-3 | BR-5 / FR-2 |
-| AC-4 | BR-3 / FR-3 |
-| AC-5 | BR-4 / FR-4 |
-| AC-6 | BR-4 / FR-5 |
-| AC-7 | BR-1 / BR-6 / FR-1 |
-| AC-8 | BR-6 / FR-1 |
-| AC-9 | BR-5 / FR-6 / NFR-2 |
-| AC-10 | NFR-1 / NFR-4 |
-| AC-11 | NFR-2 |

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

@@ -1,88 +0,0 @@
-work_item: ORCH-120
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-title: "Аналитик: открытые вопросы → Needs Input (приоритет, неблокирование serial-gate, resume)"
-framework: pytest
-scope: >
-  Покрывает поток «блокирующие открытые вопросы аналитика → Needs Input»:
-  приоритет ветки вопросов над «файлы готовы» (_handle_analysis_approved_flow),
-  неблокирование per-repo serial-gate (ось паузы ORCH-124), resume+unpark,
-  гигиена устаревшего 01-questions.md, контракт промпта и канон артефакта,
-  never-raise и нулевая регрессия. Вне покрытия: расширение Needs Input на
-  других агентов, новые QG/рёбра STAGE_TRANSITIONS, авто-ответ на вопросы.
-notes: >
-  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест: красный на коде ДО фикса (ветка files_ok
-  побеждает → In Review), зелёный ПОСЛЕ. Тесты движка прогоняют
-  _handle_analysis_approved_flow напрямую (launcher-путь), мокая plane_sync-
-  сеттеры и используя временный worktree (паттерн tests/test_analyst_status_only_regression.py
-  и tests/test_auto_approve_brd.py). Полный регресс pytest tests/ остаётся зелёным.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "РЕГРЕСС: 4 файла + активный 01-questions.md одновременно -> set_issue_needs_input вызван, note=='analysis-needs-input', set_issue_in_review НЕ вызван (приоритет вопросов, AC-1). Красный до фикса."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "01-questions.md есть, 4 файлов нет -> Needs Input, текст вопросов в Plane-комментарии и Telegram (AC-2, сохранение существующего поведения)."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Happy-path: нет 01-questions.md, 4 файла на месте -> set_issue_in_review, note=='analysis-in-review', запрос статуса Approved (AC-3, нет регресса)."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-04
-    type: integration
-    description: "Задача A в analysis переведена в Needs Input (paused_at NOT NULL) -> serial_gate исключает её из активного предиката; задача B того же репо может войти в analysis (AC-4, неблокирование FIFO)."
-    module: tests/test_orch120_serial_gate_needs_input.py
-    expected: PASS
-
-  - id: TC-05
-    type: integration
-    description: "Resume: возврат issue в рабочий статус на analysis при отсутствии активного job -> handle_status_start снимает паузу (paused_at->NULL) и enqueue'ит analyst-job; relaunch-guard ORCH-090 (только analysis) соблюдён (AC-5)."
-    module: tests/test_orch120_resume_unpark.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Гигиена устаревания: перезапущенный аналитик выпустил полный валидный пакет без свежих вопросов -> In Review, НЕ повторный Needs Input; supersede-правило детерминировано и offline (AC-6)."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Анти-дрейф промпта: .openclaw/agents/analyst.md документирует канал 01-questions.md (блокирующие вопросы -> Needs Input, не фабриковать deliverables) и сохраняет канон 52d (5 секций, 6 полей, без model:) (AC-7)."
-    module: tests/test_agent_prompts_canon.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Канон артефакта: docs/_templates/01-questions.md существует и docs/_standards/PIPELINE_DOCS.md содержит строку манифеста для 01-questions.md (владелец analyst, when-applicable, не machine-verdict) (AC-8)."
-    module: tests/test_orch120_questions_artifact_canon.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "never-raise: сбой новой логики (ошибка чтения 01-questions.md / park-вызова) не роняет advance_stage, деградирует к безопасному прежнему поведению + WARNING (AC-10)."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "Обратимость: kill-switch выключен ИЛИ репо вне self-hosting (enduro-trails) -> ветвление _handle_analysis_approved_flow и serial-gate байт-в-байт как до ORCH-120 (AC-9)."
-    module: tests/test_orch120_analyst_needs_input.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "Полный регресс pytest tests/ зелёный; STAGE_TRANSITIONS/QG_CHECKS/check_* снапшот не изменён (AC-11, NFR-2)."
-    module: tests/test_stage_transitions_snapshot.py
-    expected: PASS

docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md

@@ -1,248 +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-001: Открытые вопросы аналитика → Needs Input (приоритет, неблокирование serial-gate, resume)
-
-Work Item: **ORCH-120** · Repo: **orchestrator** (self-hosting) · Стадия: architecture
-Связь: BRD `01-brd.md`, ТЗ `02-trz.md`, AC `03-acceptance-criteria.md`, план тестов `04-test-plan.yaml`, риски `10-tech-risks.md`.
-Сквозная регистрация: `docs/architecture/adr/adr-0053-analyst-open-questions-needs-input-flow.md`.
-
-## Статус
-Proposed
-
----
-
-## Контекст
-
-Задача — баг (`BUG:` в заголовке), **эскалированный в полный цикл** (`escalate: full-cycle`,
-ADR-001 D5 ORCH-019): фикс требует архитектурных решений, поэтому выпущен полный analysis-пакет и
-задача идёт через стадию `architecture`. Аналитик передал 4 открытых проектных вопроса (BRD §6:
-DQ-1…DQ-4), которые и решаются этим ADR.
-
-**Корень (верифицировано в коде).** Механизм «аналитик задаёт блокирующие вопросы → задача в
-Needs Input» в движке **уже есть, но мёртв**: `src/stage_engine.py::_handle_analysis_approved_flow`
-(ветка `01-questions.md`, стр. 769–786) читает файл и вызывает `set_issue_needs_input(...)` +
-коммент в Plane + Telegram. Четыре смежных дефекта делают его нерабочим:
-
-1. **Контракт не доведён до аналитика.** `.openclaw/agents/analyst.md` нигде не упоминает
-   `01-questions.md` (ни в `<task>`, ни в `<deliverables>`); скелета `docs/_templates/01-questions.md`
-   нет; в `docs/_standards/PIPELINE_DOCS.md` артефакт не описан. Аналитик не знает о канале и
-   **домысливает** требования, чтобы сдать обязательные 4 файла.
-2. **Ошибка приоритета веток.** Ветка `files_ok` (`check_analysis_complete` — все 4 файла на месте,
-   стр. 711–767) проверяется **первой** и делает `return`; ветка `01-questions.md` (стр. 769)
-   достижима только если 4 файла НЕ полны. Сфабрикованный полный пакет уходит в `In Review`,
-   игнорируя блокирующие вопросы.
-3. **Needs Input клинит serial-gate репо.** Задача в Needs Input остаётся в `stage='analysis'`
-   (Plane-статус — слой B индикации, ORCH-066, **не** меняет `tasks.stage`) и `paused_at IS NULL`.
-   По правилу ORCH-088 такая «активная» задача держит FIFO репо закрытым до ответа человека
-   (часы/дни) — ни одна следующая задача `orchestrator` не входит в `analysis`.
-4. **Нет гигиены устаревшего `01-questions.md`.** После ответа заказчика `handle_status_start`
-   (`src/webhooks/plane.py:261`, analysis-resume) перезапускает аналитика; если тот выпускает
-   полный пакет, старый `01-questions.md` остаётся в ветке. Без правила supersede он либо
-   игнорируется, либо вечно роняет задачу в Needs Input.
-
-**Что НЕ нужно строить с нуля** (BRD §6 «Допущение»): `set_issue_needs_input`, чтение файла,
-ось «пауза» (`tasks.paused_at` + `db.set_task_paused`/`clear_task_paused`/`is_task_paused`,
-ORCH-124), эндпоинты `POST /serial-gate/pause|resume` — **уже существуют**. ORCH-120 **активирует
-и достраивает** путь, а не изобретает его.
-
-**Предусловия выполнены вне объёма:** ORCH-124 (ось «пауза без блокировки» — фундамент BR-3),
-ORCH-126 (queued-job не застревает со stale `run_id`/`pid` — гарантирует claim перезапущенного
-analyst-job). Plane-статус **Needs Input** существует (ключ `needs_input` в `_DEFAULT_STATES`).
-
----
-
-## Решение (сводка)
-
-Активировать мёртвый путь четырьмя согласованными изменениями, **аддитивно, под kill-switch,
-скоуп self-hosting, never-raise**: (D1) контракт промпта + (D2) канон артефакта `01-questions.md`;
-(D3) **приоритет** ветки вопросов над `files_ok` с детерминированным supersede; (D4) **авто-park**
-при Needs Input через ось «пауза» ORCH-124; (D5) **resume + unpark** в `handle_status_start`.
-`STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS` / семантика `check_analysis_complete` /
-`check_analysis_approved` / machine-verdict-ключи / схемы существующих таблиц — **байт-в-байт не
-тронуты** (поток — pre-gate-ветка движка, **не** Quality Gate; артефакт — сигнальный, **не**
-machine-verdict). Это решение DQ-1…DQ-4.
-
----
-
-## Решения по открытым вопросам (DQ-1…DQ-4)
-
-### DQ-1 — авто-park vs operator-park при Needs Input → **авто-park, config-gated**
-
-**Решение.** В момент перехода в Needs Input движок вызывает `db.set_task_paused(task_id)`
-**автоматически** (под под-флагом `analyst_needs_input_autopause_enabled`, скоуп self-hosting),
-а на resume — `db.clear_task_paused(task_id)` (D5). Operator-park (`POST /serial-gate/pause`)
-сохраняется как ручной fallback, но **не** обязателен для BR-3.
-
-**Обоснование.** BR-3 и весь эпик ORCH-088 («10–20 задач за ночь», автономный пакетный прогон)
-требуют, чтобы Needs Input **не** клинил очередь. Operator-park вводит человеческий шаг в каждую
-итерацию — это противоречит цели автономности: пока оператор не нажал pause, FIFO репо закрыт.
-Авто-park снимает блокировку детерминированно и без человека.
-
-**Снятие риска связывания индикации (слой B) с осью планировщика** (явный риск из BRD §6 DQ-1):
-- Триггер узкий и детерминированный — **только** переход аналитика в Needs Input в
-  `_handle_analysis_approved_flow`, а не общее правило «статус → пауза».
-- Отдельный под-флаг `analyst_needs_input_autopause_enabled` (независимый от questions-gate),
-  дефолт `True` в self-hosting-области → откат до operator-park одним флагом.
-- never-raise: `set_task_paused` уже возвращает `False` на ошибке; сбой park **не** отменяет
-  переход в Needs Input (деградация к operator-park) и не роняет `advance_stage`.
-- Симметричный unpark на resume (D5) исключает «застрявшую паузу».
-
-**Инвариант ORCH-124 не нарушен:** `paused_at` исключает задачу только из оси «активная задача»
-serial-gate; оси `task_deps`/`repo_freeze`/терминал `{done,cancelled}` `paused_at` **не читают** —
-пауза их не обходит (`src/serial_gate.py:33` нормативно).
-
-### DQ-2 — устаревание `01-questions.md` (BR-4) → **freshness-gated supersede (mtime), детерминированно и offline**
-
-**Решение.** Ввести чистый предикат `_questions_active(worktree_path, work_item_id, files_ok) -> bool`
-в `stage_engine` (или leaf-хелпер), детерминированный и offline (только filesystem, без сети/git):
-
-- `01-questions.md` отсутствует → **не активны** (`False`).
-- Пакет **неполон** (`files_ok == False`) и файл присутствует → **активны** (`True`): вопросы есть,
-  deliverables нет — приоритет вопросов (AC-2).
-- Пакет **полон** (`files_ok == True`) и файл присутствует → сверка свежести:
-  **superseded ⇔ все 4 deliverables строго новее `01-questions.md`** (по `os.path.getmtime`).
-  `superseded == True` → **не активны** (`False`, → In Review, AC-6); иначе (вопросы не старше
-  новейшего deliverable) → **активны** (`True`, → Needs Input, AC-1).
-
-**Почему mtime-freshness, а не альтернативы.** Кандидаты и причины отказа:
-- **Удаление файла аналитиком** — у аналитика нет Delete-tool (только Write `docs/...`); полагаться
-  на «забыл удалить» нельзя; AC-6 явно допускает «файл **мог остаться** нетронутым».
-- **Контент-маркер `status: resolved`** — требует, чтобы аналитик **переписал** файл; при
-  «файл остался нетронутым» (AC-6) маркера нет → ложный Needs Input. Плюс вводит парсинг
-  машинного ключа в сигнальный артефакт (трение с BR-6).
-- **Git-recency коммитов** — надёжно в проде, но юнит-тесты (`04-test-plan.yaml`: временный worktree
-  с plain-файлами, паттерн `test_auto_approve_brd.py`) **не коммитят** → нетестируемо/хрупко.
-- **mtime-freshness** — единственный механизм, который (а) тестируем на plain-файлах (тест задаёт
-  порядок записи/mtime), (б) offline и без нового парсинга, (в) **не зависит от действия LLM**:
-  на полном прогоне аналитик в любом случае пишет 4 deliverables (свежий mtime), поэтому
-  оставленный нетронутым старый `01-questions.md` автоматически superseded — ровно сценарий AC-6.
-
-**Контракт промпта (D1) дополняет, не заменяет** механизм: на resume аналитик, у которого остались
-блокеры, **перезаписывает** `01-questions.md` (свежий mtime → снова активен); при полном ответе —
-просто пишет 4 deliverables, freshness supersede’ит старые вопросы. Так оба слоя согласованы.
-
-**Направление fail (never-raise, NFR-1) для DQ-2:**
-- Ошибка `getmtime`/сверки при **доказанно существующем** `01-questions.md` → считать вопросы
-  **активными** (Needs Input) — безопасно для цели «не строить на домыслах».
-- Катастрофический сбой (не можем определить даже наличие файла) → деградация к **прежнему**
-  поведению (`files_ok` → In Review) + WARNING.
-
-### DQ-3 — точное правило приоритета в `_handle_analysis_approved_flow` → **вопросы проверяются ДО `files_ok`, под kill-switch**
-
-**Решение.** Реструктурировать тело (только при `applies(repo)` и `analyst_questions_gate_enabled`):
-
-```
-files_ok, _ = QG_CHECKS["check_analysis_complete"](repo, work_item_id, branch)
-questions_active = _questions_active(worktree, work_item_id, files_ok)   # D2, never-raise
-if questions_active:
-    set_issue_needs_input(work_item_id)
-    <Plane-коммент с текстом вопросов>  +  <Telegram>          # как сейчас (стр. 770-784)
-    if analyst_needs_input_autopause_enabled and applies(repo):
-        db.set_task_paused(task_id)                            # D4 авто-park, never-raise
-    result.note = "analysis-needs-input"
-    return
-if files_ok:
-    <ветка In Review + autoApprove ORCH-089>                  # существующая, байт-в-байт
-    return
-<ветка "ни файлов, ни вопросов">                              # существующая
-```
-
-- **Приоритет вопросов > «файлы на месте»** (AC-1): `questions_active` проверяется первым.
-- **Happy-path** (нет файла вопросов): `questions_active == False` → ветка `files_ok` → In Review,
-  включая autoApprove ORCH-089 — **байт-в-байт** (AC-3).
-- **Kill-switch / out-of-scope** (`analyst_questions_gate_enabled == False` ИЛИ репо вне области):
-  исполняется **исходный** порядок (`files_ok` первым; затем плоский `os.path.isfile(questions_path)`
-  — существующая ветка) — **байт-в-байт как до ORCH-120**, включая для enduro (AC-9).
-
-### DQ-4 — коллизия номера `01-questions.md` с `01-brd.md` → **сохранить путь `01-questions.md`**
-
-**Решение.** Движок уже читает именно `docs/work-items/<wid>/01-questions.md`
-(`stage_engine.py:771`) — это **рабочий** контракт; смена пути = код-изменение + поломка читателя
-без выгоды. Путь **сохраняется**. В `PIPELINE_DOCS.md` (D2) фиксируется нормативно: префикс `01-` —
-общий для артефактов стадии `analysis` аналитика; `01-brd.md` — обязательный deliverable,
-`01-questions.md` — **сигнальный** when-applicable артефакт того же владельца/стадии; коллизии нет,
-т.к. файлы разноимённые, гейт `check_analysis_complete` проверяет ровно `01-brd.md`/`02`/`03`/`04`
-(`01-questions.md` им не парсится).
-
----
-
-## Изменения (карта, нормативно)
-
-| Путь | Действие | Примечание |
-|------|----------|------------|
-| `.openclaw/agents/analyst.md` | изменить | D1: контракт «блокирующие вопросы → `01-questions.md`, НЕ фабриковать 4 deliverables» в `<task>`+`<deliverables>`+поведение на resume; **сохранить канон 52d** (5 секций, 6 полей, без `model:`). |
-| `docs/_templates/01-questions.md` | создать | D2: скелет (контекст / список блокирующих вопросов с вариантами / «что разблокирует анализ»). |
-| `docs/_standards/PIPELINE_DOCS.md` | изменить | D2: строка манифеста §2 (`01-questions.md`, владелец `analyst`, `when-applicable`, стадия `analysis`, механизм «ветка Needs Input в `_handle_analysis_approved_flow`», machine-key — «нет, сигнальный») + примечание о префиксе `01-` (DQ-4). |
-| `src/stage_engine.py` | изменить | D3: приоритет + `_questions_active` (D2) + авто-park (D4); всё never-raise, под kill-switch. |
-| `src/webhooks/plane.py` | изменить (точечно) | D5: analysis-resume ветка `handle_status_start` (стр. 317–381) — `clear_task_paused(task_id)` (под autopause-флагом + `applies`), never-raise. |
-| `src/config.py` | изменить | 3 новых ключа (ниже), безопасные дефолты. |
-| `src/db.py` | переиспользовать | `set_task_paused`/`clear_task_paused` (ORCH-124) — **новых колонок нет**. |
-| `src/serial_gate.py` | **не менять кодом** | ось «пауза» уже исключает `paused_at NOT NULL` (ORCH-124); ORCH-120 лишь корректно её триггерит (D4/D5). |
-
-**Флаги (`src/config.py`), дефолты безопасны:**
-
-| Ключ | Env | Дефолт | Назначение |
-|------|-----|--------|------------|
-| `analyst_questions_gate_enabled` | `ORCH_ANALYST_QUESTIONS_GATE_ENABLED` | `True` | kill-switch приоритета+supersede (D3). `False` → исходный порядок байт-в-байт. |
-| `analyst_questions_gate_repos` | `ORCH_ANALYST_QUESTIONS_GATE_REPOS` | `""` | CSV; **пусто → self-hosting only** (`is_self_hosting_repo`, как ORCH-35/43/58). enduro не затронут. |
-| `analyst_needs_input_autopause_enabled` | `ORCH_ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED` | `True` | независимый под-тумблер авто-park/unpark (D4/D5). `False` → operator-park (`POST /serial-gate/pause`). |
-
-`applies(repo)` (локально, без сети) проверяется **первым** — выключенный флаг / вне области
-стоит ноль сетевых вызовов и даёт байт-в-байт прежнее ветвление (зеркало `serial_gate.applies`).
-
----
-
-## Изменения схемы БД
-**Нет.** Колонка `tasks.paused_at` введена ORCH-124 (`src/db.py:160`, `_ensure_column`). Новых
-таблиц/колонок/индексов ORCH-120 не вводит. Поэтому отдельный `08-data-requirements.md` не выпускается.
-
-## Инфраструктурные требования
-**Нет нового.** Plane-статус **Needs Input** уже на доске (ключ `needs_input` в
-`plane_sync._DEFAULT_STATES`); эндпоинты `POST /serial-gate/pause|resume` существуют (ORCH-124).
-Поэтому отдельный `07-infra-requirements.md` не выпускается.
-
-## QG / стадии
-**Не тронуты.** `01-questions.md` — сигнальный, не machine-verdict (BR-6). `check_analysis_complete`/
-`check_analysis_approved`/`_parse_*`/`STAGE_TRANSITIONS`/`QG_CHECKS` — байт-в-байт (NFR-2). Поток
-вопросов остаётся pre-gate-веткой движка.
-
----
-
-## Последствия
-
-**Плюсы.**
-- Аналитик получает легитимный канал «не знаю — спрошу» вместо принуждения к фабрикации (BR-1);
-  конвейер перестаёт строить решения поверх домыслов.
-- Блокирующие вопросы надёжно достигают Needs Input даже при частичных deliverables (BR-2/AC-1).
-- serial-gate репо не клинит на задаче, ждущей человека (BR-3/AC-4) — автономный пакетный прогон
-  (ORCH-088) не стопорится.
-- Resume-петля корректна: ответ → unpark → claim перезапущенного analyst-job (BR-4/AC-5).
-- Устаревший `01-questions.md` детерминированно supersede’ится без зависимости от LLM (AC-6).
-- Полная обратимость: 3 флага с безопасными дефолтами; вне области/выключено → байт-в-байт (AC-9).
-
-**Минусы / ограничения.**
-- Авто-park связывает индикацию (слой B) с осью планировщика — смягчено узким триггером,
-  отдельным флагом, never-raise и симметричным unpark (DQ-1).
-- mtime-freshness теоретически хрупок при экзотической re-материализации worktree — на практике
-  устойчив (полный прогон всегда пишет свежие deliverables); смягчён fail-в-сторону-Needs-Input и
-  контрактом промпта (DQ-2, см. `10-tech-risks.md` TR-2).
-- Needs Input по-прежнему **только** у аналитика (ORCH-066 BR-10 не расширяется) — намеренно.
-
-**Трассировка маркеров (ORCH-078).** Правки в `_handle_analysis_approved_flow`/`handle_status_start`
-сверены с ADR ORCH-066 (Needs-Input владение), ORCH-088/124 (serial-gate/пауза), ORCH-089
-(autoApprove), ORCH-090 (relaunch-guard) — инварианты не сломаны. Блок `_handle_analysis_approved_flow`
-несёт 3+ маркера → эволюция агрегирована в сквозном `adr-0053`.
-
-## Соответствие AC
-AC-1 → D3 (приоритет) + D2 (active при files_ok). AC-2 → D3 (questions при !files_ok). AC-3 → D3
-(happy-path байт-в-байт). AC-4 → D4 (авто-park → `paused_at` исключает из активного предиката).
-AC-5 → D5 (resume unpark). AC-6 → D2 (freshness supersede). AC-7 → D1 (контракт промпта). AC-8 → D2
-(скелет + манифест). AC-9 → флаги/скоуп (байт-в-байт off/enduro). AC-10 → never-raise во всех врезках.
-AC-11 → снапшот `STAGE_TRANSITIONS`/`QG_CHECKS` не изменён.

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

@@ -1,41 +0,0 @@
----
-work_item: ORCH-120
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-17
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-120 — Открытые вопросы аналитика → Needs Input
-
-Work Item: **ORCH-120** · Repo: **orchestrator** (self-hosting) · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Связывание индикации (слой B) с осью планировщика** при авто-park (DQ-1): непреднамеренный park из-за широкого/ошибочного триггера. | Низ. | Сред. | Триггер узкий — **только** переход аналитика в Needs Input в `_handle_analysis_approved_flow`, не общее «статус→пауза». Отдельный под-флаг `analyst_needs_input_autopause_enabled` (откат к operator-park). never-raise: сбой `set_task_paused` не отменяет Needs Input. Симметричный unpark на resume (D5) исключает «застрявшую паузу». |
-| TR-2 | **Хрупкость mtime-freshness** (DQ-2): re-материализация worktree выставляет близкие mtime → ложный supersede (AC-1 ломается) или ложная активность (AC-6 ломается). | Низ. | Сред. | Полный прогон аналитика **всегда** пишет 4 deliverables свежим mtime → старый нетронутый `01-questions.md` детерминированно старше (AC-6 устойчив). Сверка строгая (`>` для всех 4). Контракт промпта (D1): на resume с блокерами аналитик **перезаписывает** вопросы → свежий mtime (AC-1 устойчив). Fail-в-сторону-Needs-Input при ошибке `getmtime` на существующем файле. Покрыто TC-01/TC-06. |
-| TR-3 | **Регресс serial-gate** (ORCH-088/124): неаккуратная интеграция паузы обходит freeze/deps или ломает анти-stale-base. | Низ. | Выс. | `serial_gate.py`/`task_deps.py`/`stages.py` **кодом не трогаются** — пауза уже ортогональна (ORCH-124: `paused_at` не читают оси freeze/deps/терминал). Анти-stale-base цел: нормальная задача `paused_at IS NULL` держит гейт; на resume свежесть базы дают существующие механизмы (отложенный срез / `auto_rebase_onto_main`). Снапшот-тест serial-gate + TC-04. |
-| TR-4 | **Бесконечная петля Needs Input** при устаревшем `01-questions.md` (если supersede не сработал). | Низ. | Сред. | Детерминированный freshness supersede (DQ-2) + обязательный регресс TC-06 (полный пакет без свежих вопросов → In Review, не повторный Needs Input). Контракт промпта подкрепляет. |
-| TR-5 | **Застрявшая пауза на resume** (task остаётся `paused_at NOT NULL` после ответа → семантика «активна, но помечена paused»). | Низ. | Низ. | D5: `clear_task_paused` на analysis-resume ветке `handle_status_start` (под autopause-флагом + `applies`), идемпотентно/never-raise. Ручной fallback — `POST /serial-gate/resume`. Покрыто TC-05. |
-| TR-6 | **Нарушение never-raise** новой логики (чтение файла/park/приоритет) роняет `advance_stage`/launcher → встаёт конвейер всех проектов (self-hosting). | Низ. | Выс. | Все врезки в `try/except` с деградацией к **прежнему** поведению + WARNING (паттерн `serial_gate`/`labels`/`cancel`). `set_task_paused`/`clear_task_paused` уже never-raise (→ `False`). Покрыто TC-09. |
-| TR-7 | **Регресс enduro / нулевой-флаг** (поведение отличается при выключенном kill-switch или вне self-hosting). | Низ. | Сред. | `applies(repo)` первым; off/out-of-scope → исходный порядок (`files_ok` первым + плоский isfile) **байт-в-байт**. enduro-аналитик `01-questions.md` не эмитит. Покрыто TC-10 + снапшот TC-11. |
-| TR-8 | **Дрейф промпта** (контракт вопросов не задокументирован или сломан канон 52d). | Низ. | Низ. | Анти-дрейф `tests/test_agent_prompts_canon.py` (5 секций, 6 полей, без `model:`) + новый assert наличия контракта вопросов (TC-07); канон артефакта — TC-08. |
-
-## Сводный вывод
-
-Доминирующий класс — **корректность интеграции с serial-gate (ORCH-088/124) и never-raise на
-self-hosting горячем пути** (TR-3/TR-6: высокое влияние, низкая вероятность). Оба полностью
-структурно нейтрализованы: serial-gate кодом не трогается (пауза уже ортогональна), все врезки
-изолированы и деградируют к прежнему поведению. Остальные риски — низкого влияния и покрыты
-обязательными регресс-тестами (TC-01/TC-04/TC-05/TC-06/TC-09/TC-10).
-
-Остаточный риск для прод-конвейера (self-hosting) — **низкий**: изменение аддитивно, под тремя
-флагами с безопасными дефолтами (байт-в-байт откат), не деплоит / не рестартит прод / не пушит в
-`main` / не трогает detached-процессы (NFR-4). Эскалация `arch:major-change` **не требуется**
-(нет новой стадии/QG/компонента/смены БД); возврат в анализ **не требуется** (ТЗ удовлетворимо без
-нарушения принципов архитектуры).

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

@@ -1,105 +0,0 @@
----
-verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
-work_item: ORCH-120
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-120
-version: 2
----
-
-# Review ORCH-120 — Открытые вопросы аналитика → Needs Input
-
-## Summary
-
-Реализация **сильная, завершённая и корректная**. Ранее **мёртвый** путь «аналитик задаёт
-блокирующие вопросы → `01-questions.md` → Needs Input» активирован четырьмя согласованными
-изменениями (контракт промпта + канон артефакта; приоритет вопросов над `files_ok`; авто-park через
-ось «пауза» ORCH-124; resume + unpark). Чистая логика вынесена в leaf `src/analyst_questions.py`
-(never-raise, kill-switch, self-hosting-скоуп — зеркало `coverage_gate`/`serial_gate`); side-effects
-изолированы в `stage_engine` (`_decide_analysis_outcome` / `_emit_analysis_needs_input` /
-`_emit_analysis_in_review` / `_emit_analysis_empty`). ORCH-089 autoApprove-блок перенесён
-**байт-в-байт** (сверено по `git show origin/main`). `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`
-/ `check_*` / machine-verdict-ключи / схема БД — **подтверждённо не тронуты** (пустой `git diff` по
-`src/stages.py`, `src/qg/checks.py`, `src/db.py`). Все 11 AC реализованы и покрыты; обязательный
-регресс-тест TC-01 (Bug-трек, ORCH-019 BR-4) — валидный фиксатор дефекта (красный на дофиксовом
-`files_ok`-first порядке, зелёный после). Полный регресс `pytest tests/` — **2205 passed** (86s).
-
-**Блокировавший ранее дефект устранён.** Предыдущая ревизия (v1, run_id=780) выносила
-`REQUEST_CHANGES` из-за единственного P1 — необновлённой **витрины системы** `docs/overview/`
-(ось ORCH-011 / ORCH-079). Коммит `19c3177` обновил витрину в этом же PR (см. раздел «Документация»);
-ось закрыта, `tests/test_system_docs.py` зелёный. Новых P0/P1/P2 нет → **APPROVED**.
-
-## Findings
-
-### P0 — Blocker
-*(нет)*
-
-### P1 — Must fix
-*(нет)*
-
-### P2 — Should fix
-*(нет)*
-
-### P3 — Nice to have
-- [ ] Косметика (не привязано к правилу, не блокирует): `_decide_analysis_outcome` в gate-off ветке
-  повторно собирает путь `01-questions.md` (`os.path.join` + `os.path.isfile`), который уже
-  инкапсулирован в `analyst_questions.questions_active`; а `_emit_analysis_*` повторно резолвят
-  `get_worktree_path`. Дублирование намеренно (gate-off ветка = «оригинальный байт-в-байт порядок»),
-  поведенчески безвредно — при будущем рефакторе можно консолидировать резолв worktree.
-
-## Документация
-
-**Обновлено (проверено по diff) — golden source синхронизирован с кодом:**
-- `docs/overview/tech-pipeline.md` — абзац «пауза без блокировки» теперь называет **два** источника
-  паузы (оператор `POST /serial-gate/pause` + **движок** авто-park на Needs Input, под флагом
-  `analyst_needs_input_autopause_enabled`, скоуп self-hosting; симметричный unpark на resume).
-- `docs/overview/tech-observability.md` — пункт `GET /queue` обновлён: пауза/возобновление в serial
-  gate — от оператора **и** от движка (авто-park на Needs Input).
-- `docs/overview/tech-agents.md` — строка `analyst` дополнена when-applicable сигнальным
-  `01-questions.md` + врезка о канале «блокирующие вопросы → Needs Input».
-- `docs/architecture/README.md` — новый раздел «Открытые вопросы аналитика → Needs Input (ORCH-120 —
-  реализовано)» со ссылкой на adr-0053.
-- `CHANGELOG.md` — запись `[Unreleased]` с полным описанием 4 изменений, флагов и витрины.
-- `docs/_standards/PIPELINE_DOCS.md` — строка манифеста для `01-questions.md` (владелец `analyst`,
-  `when-applicable`, сигнальный, не machine-verdict) + примечание о префиксе `01-` (DQ-4).
-- `.openclaw/agents/analyst.md` — контракт «блокирующие вопросы → `01-questions.md`, НЕ фабриковать
-  deliverables» + поведение на resume; канон 52d сохранён (анти-дрейф-assert
-  `test_orch120_analyst_documents_questions_channel` + канон-тесты зелёные).
-- `docs/_templates/01-questions.md` — новый скелет (frontmatter 52c с плейсхолдерами; контекст /
-  блокирующие вопросы / что разблокирует анализ).
-- `.env.example` — 3 ключа `ORCH_ANALYST_*` с описанием и безопасными дефолтами.
-- 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`.
-
-**Обзорные доки / витрина (ORCH-011 / ORCH-079):** `README.md` «Известные ограничения» проверен —
-**нет** пункта, который закрывается этой задачей (мёртвый путь вопросов не значился ограничением),
-обновление не требуется. Витрина `docs/overview/` обновлена в том же PR (см. выше). Ось закрыта.
-
-**Нужно обновить:** ничего.
-
-## Проверки осей (для прозрачности)
-
-- **Соответствие ТЗ/AC:** AC-1…AC-11 реализованы и покрыты
-  (`tests/test_orch120_analyst_needs_input.py` TC-01…TC-10, `..._serial_gate_needs_input.py` TC-04
-  интеграционно через реальный `claim_next_job`, `..._resume_unpark.py` TC-05 + autopause-off,
-  `..._questions_artifact_canon.py`, assert канона). Полный регресс **2205 passed**. TC-01 — валидный
-  обязательный фиксатор (RED→GREEN), требование ORCH-019 BR-4 для Bug→escalate full-cycle выполнено.
-- **Соответствие ADR / трассировка (ORCH-078):** реализация = ADR-001 / adr-0053 (D1…D5, DQ-1…DQ-4).
-  `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict / схема БД — байт-в-байт (пустой
-  diff). ОRCH-089 autoApprove перенесён вербатим; ось «пауза» ORCH-124 переиспользована (новых
-  колонок нет); инварианты ORCH-066 (Needs Input только у аналитика — не расширен), ORCH-088/124
-  (serial-gate/пауза — лишь корректно триггерится, код не тронут), ORCH-090 (relaunch-guard — unpark
-  врезан ПОСЛЕ гейта, под `current_stage=='analysis'`, не ослаблен) — сверены, не сломаны.
-- **Качество кода:** leaf-паттерн чистый (импорт только `os`/`logging`/`config` + ленивый
-  `qg.checks`), never-raise во всех публичных функциях и врезках, kill-switch + скоуп корректны
-  (`questions_gate_applies`/`autopause_applies`), docstrings на публичных функциях содержательны.
-  Freshness-supersede (DQ-2) детерминирован и offline; fail-направление к Needs Input — безопасно
-  («не строить на домыслах»). Гейт-off ветка восстанавливает оригинальный порядок байт-в-байт (AC-9).
-- **Документация:** golden source (номерные/стандартные доки, ADR, CHANGELOG, `.env.example`) **и**
-  обзорная витрина `docs/overview/` обновлены в том же PR. Ось обзорных доков закрыта.
-</content>
-</invoke>

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

@@ -1,40 +0,0 @@
----
-result: PASS
-work_item: ORCH-120
-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):
-```
-............................................. [ 65%]
-........................................................................ [ 68%]
-........................................................................ [ 71%]
-........................................................................ [ 75%]
-........................................................................ [ 78%]
-........................................................................ [ 81%]
-........................................................................ [ 84%]
-........................................................................ [ 88%]
-........................................................................ [ 91%]
-........................................................................ [ 94%]
-........................................................................ [ 97%]
-.............................................                            [100%]
-=============================== warnings summary ===============================
-src/config.py:8
-  /repos/_wt/orchestrator/feature_ORCH-120-bug-analyst-open-questions-mus/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
-2205 passed, 1 warning in 102.38s (0:01:42)
-```

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

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

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-120
-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 5db228da-d4be-4001-8233-e1579c6a7074 (HTTP 204)
-  ·      CLEANUP DB: no task row found for plane_id=5db228da-d4be-4001-8233-e1579c6a7074
-  ·      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-123/01-brd.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,136 +0,0 @@
----
-work_item: ORCH-124
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-16
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-124 — wait/terminal-семантика serial-gate
-
-Work Item: **ORCH-124** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
-провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
-
----
-
-## AC-1 — Приостановленный предшественник не блокирует срочного успешника (регресс инцидента)
-
-**Условие:** репо имеет более раннюю задачу A (`A.id < B.id`) в состоянии паузы (Blocked/Backlog/
-Needs-Input по явному намерению оператора) и более позднюю срочную задачу B с queued analyst-job.
-- **PASS:** `build_claim_clause()` НЕ блокирует analyst-job задачи B; `claim_next_job()` выбирает его;
-  B входит в `analysis`. Тест воспроизводит инцидент ORCH-116/ORCH-123 (красный до фикса, зелёный
-  после).
-- **FAIL:** analyst-job B остаётся `queued`, потому что приостановленная A всё ещё считается активной.
-
----
-
-## AC-2 — Нормально исполняемая задача по-прежнему держит гейт (анти-stale-base, без регресса ORCH-088)
-
-**Условие:** репо имеет более раннюю задачу A, **реально исполняемую** (не на паузе, стадия вне
-`{done,cancelled}`) и более позднюю задачу B с queued analyst-job.
-- **PASS:** analyst-job B **остаётся заблокированным** (FIFO ORCH-088 цел); B стартует только когда A
-  становится `done`/`cancelled` (или явно поставлена на паузу оператором).
-- **FAIL:** B стартует поверх ещё не завершённой активной A → возврат stale-base дефекта, который
-  закрывал ORCH-088.
-
----
-
-## AC-3 — Пауза снимает гейт только по явному durable намерению
-
-**Условие:** способ перевода задачи в «паузу» для serial-gate.
-- **PASS:** освобождение гейта происходит **только** при явном операторском сигнале (эндпоинт
-  pause / выбранный механизм ADR), сигнал **durable** (переживает рестарт процесса/контейнера) и
-  **DB-резолвимый**. Никакого эвристического само-распаузивания.
-- **FAIL:** гейт снимается без явного намерения (например, по умолчанию для любой не-`done` задачи) ИЛИ
-  намерение теряется после рестарта.
-
----
-
-## AC-4 — Анти-stale-base при возобновлении (R-1 разрешён архитектором)
-
-**Условие:** приостановленная A возобновлена после того, как успешник B уже прошёл вперёд.
-- **PASS:** ни A, ни B не остаются незаметно на устаревшей базе — выбранный механизм (демотирование A
-  в FIFO + обязательный rebase / явный yield с rebase / иное по ADR) гарантирует, что возобновлённая
-  задача строится/мержится на актуальном `origin/main`. Поведение зафиксировано тестом по контракту ADR.
-- **FAIL:** возобновлённая A или прошедший B приводит к stale-ветке/затиранию кода без сигнала.
-
----
-
-## AC-5 — Явные блоки (freeze + dependency) сохранены
-
-**Условие:** активный `repo_freeze` для репо ИЛИ объявленная незавершённая зависимость в `job_deps`.
-- **PASS:** claim успешника по-прежнему **заблокирован** freeze'ем (до ручного
-  `POST /serial-gate/unfreeze`) и/или незавершённой зависимостью (`task_deps`) — пауза их не обходит.
-- **FAIL:** «пауза» позволяет обойти freeze или объявленную зависимость.
-
----
-
-## AC-6 — Корректная причина ожидания в `GET /queue`
-
-**Условие:** блок `serial_gate` в снапшоте `GET /queue`.
-- **PASS:** для ожидающего успешника видна корректная причина ожидания (`active-task` /
-  `paused-predecessor` / `freeze` / `dependency`); приостановленный предшественник НЕ показывается как
-  `active_task`. Существующие ключи снапшота не сломаны (BC).
-- **FAIL:** снапшот показывает приостановленную задачу как `active_task` ИЛИ причина ожидания неверна/
-  отсутствует.
-
----
-
-## AC-7 — Hot-path остаётся offline (без сети)
-
-**Условие:** путь `db.claim_next_job` → `serial_gate.build_claim_clause`.
-- **PASS:** определение «активна/пауза» резолвится **только** локальной БД (SQL); ни одного сетевого
-  вызова (Plane API и т.п.) на горячем пути claim. Проверяемо тестом (claim работает без сети / без
-  Plane).
-- **FAIL:** claim делает сетевой вызов для определения паузы.
-
----
-
-## AC-8 — Машинные инварианты байт-в-байт; kill-switch off → прежнее поведение
-
-**Условие:** реестры и выключатель.
-- **PASS:** `STAGE_TRANSITIONS` / состав `QG_CHECKS` / имена и семантика `check_*` / machine-verdict
-  ключи / схемы существующих таблиц — без изменений (структурный тест). При выключенном под-флаге паузы
-  serial-gate ведёт себя байт-в-байт как ORCH-088/090.
-- **FAIL:** изменён любой machine-verdict ключ / состав `QG_CHECKS` / `STAGE_TRANSITIONS`, либо
-  выключенный флаг меняет поведение.
-
----
-
-## AC-9 — never-raise и сохранённые fail-directions
-
-**Условие:** ошибки внутри новой логики паузы.
-- **PASS:** все публичные функции `serial_gate` never-raise; hot-claim build по-прежнему **fail-OPEN**
-  (`""`-фрагмент при ошибке), freeze-решение по-прежнему **fail-CLOSED**; новая ветка паузы не
-  инвертирует эти направления. Проверяемо тестом (инъекция ошибки → claim не падает, очередь не
-  заклинивает).
-- **FAIL:** ошибка в ветке паузы роняет claim/worker ИЛИ инвертирует fail-direction.
-
----
-
-## AC-10 — Возобновление восстанавливает участие в гейте (BR-5)
-
-**Условие:** распауза ранее приостановленной задачи.
-- **PASS:** после resume задача снова участвует в serial-gate согласно выбранной семантике (держит
-  гейт как активная либо ре-входит в FIFO); нет «вечного обхода».
-- **FAIL:** возобновлённая задача навсегда остаётся вне гейта / её намерение паузы «залипает».
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1, FR-2 |
-| AC-2 | BR-3 / FR-4 |
-| AC-3 | BR-2 / FR-3 |
-| AC-4 | BR-3, BR-5 / FR-4 |
-| AC-5 | BR-6 / FR-6 |
-| AC-6 | BR-4 / FR-5 |
-| AC-7 | NFR-2 / FR-1 |
-| AC-8 | NFR-3, NFR-4 / FR-7 |
-| AC-9 | NFR-1 / FR-7 |
-| AC-10 | BR-5 / FR-3 |

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

@@ -1,112 +0,0 @@
-work_item: ORCH-124
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-16
-model_used: claude-opus-4-8
-title: "Serial-gate wait/pause semantics — paused predecessor must not block urgent successor"
-framework: pytest
-scope: >
-  Покрывает определение "активной задачи" в serial-gate (build_claim_clause /
-  repo_has_active_task / _per_repo_snapshot), durable явный сигнал паузы и его учёт в
-  горячем SQL claim, сохранность анти-stale-base ORCH-088, явных блоков (freeze/task_deps),
-  наблюдаемости GET /queue, never-raise/fail-directions и kill-switch. Вне покрытия:
-  изменения STAGE_TRANSITIONS/QG_CHECKS/check_* (их НЕТ), сетевые вызовы Plane API на hot-path
-  (запрещены — проверяется их ОТСУТСТВИЕ), реальный прод-деплой/рестарт.
-notes: >
-  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест инцидента ORCH-116/ORCH-123: красный до фикса, зелёный
-  после. Точные имена флагов/колонок/эндпоинтов и SQL-форма предиката зависят от выбранного
-  механизма (ADR архитектора) — тест-план фиксирует ПОВЕДЕНИЕ, не реализацию. Тесты
-  работают на временной SQLite-БД без сети/Plane/прода (паттерн tests/test_serial_gate*.py).
-  Полный регресс tests/ должен оставаться зелёным (особенно test_serial_gate*.py).
-
-tests:
-  - id: TC-01
-    type: integration
-    description: "РЕГРЕСС (обязательный): репо с более ранней приостановленной задачей A + более поздняя срочная B → claim_next_job выбирает analyst-job B (гейт открыт). Красный до фикса, зелёный после. Воспроизводит ORCH-116/ORCH-123."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Предшественник в Backlog (по явному намерению) не считается активным: build_claim_clause не блокирует analyst-job успешника."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Предшественник в Needs-Input (по явному намерению) не блокирует успешника — параллельно AC-1 для иного wait-состояния."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "АНТИ-РЕГРЕСС ORCH-088: нормально исполняемый предшественник (не на паузе, стадия вне done/cancelled) ПО-ПРЕЖНЕМУ блокирует analyst-job успешника (FIFO цел)."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Пауза требует явного durable намерения: задача без операторского сигнала паузы остаётся активной (гейт держится); сигнал паузы DB-резолвим."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Durable: сигнал паузы переживает пересоздание соединения/рестарт (читается из БД, не из памяти процесса)."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Возобновление (resume) восстанавливает участие задачи в serial-gate (держит гейт / ре-входит в FIFO согласно ADR); нет вечного обхода."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Явные блоки сохранены: активный repo_freeze продолжает блокировать claim успешника; пауза freeze не обходит."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "Явные блоки сохранены: незавершённая объявленная зависимость (job_deps/task_deps) продолжает блокировать claim; пауза dependency не обходит."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "GET /queue snapshot: приостановленный предшественник НЕ показывается как active_task; причина ожидания успешника корректна (active-task/paused-predecessor/freeze/dependency); существующие ключи snapshot сохранены."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Согласованность трёх точек: build_claim_clause, repo_has_active_task и _per_repo_snapshot дают один и тот же вердикт 'активна' на одном входе (анти-дрейф)."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-12
-    type: unit
-    description: "Hot-path offline: claim_next_job + build_claim_clause резолвят паузу без сетевого вызова (Plane API не вызывается); claim работает при недоступном Plane."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-13
-    type: unit
-    description: "never-raise / fail-directions: инъекция ошибки в логику паузы → build_claim_clause fail-OPEN ('' фрагмент, очередь не клинит), freeze-решение fail-CLOSED; ни одна публичная функция не бросает."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-14
-    type: unit
-    description: "Kill-switch / нейтральность: при выключенном под-флаге паузы (и/или serial_gate_enabled) поведение serial-gate байт-в-байт как ORCH-088/090; вне области репо — не затронуто (enduro)."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS
-
-  - id: TC-15
-    type: unit
-    description: "Структурный анти-регресс: STAGE_TRANSITIONS, состав QG_CHECKS, имена check_* и machine-verdict ключи не изменены; схемы существующих таблиц tasks/jobs/job_deps/repo_freeze не сломаны."
-    module: tests/test_orch124_serial_gate_pause.py
-    expected: PASS

docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md

@@ -1,298 +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-001: Serial-gate «пауза без блокировки» — явный per-task park-сигнал (ORCH-124)
-
-Work Item: **ORCH-124** · Repo: **orchestrator** (self-hosting) · Стадия: architecture
-Связь: BRD `01-brd.md`, ТЗ `02-trz.md`, AC `03-acceptance-criteria.md`, данные `08-data-requirements.md`, риски `10-tech-risks.md`.
-Сквозная регистрация: `docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md`.
-
-## Статус
-Proposed
-
----
-
-## Контекст
-
-Баг (метка `Bug`, эскалирован в full-cycle — `escalate: full-cycle`, ADR-001 D5 ORCH-019): по сути
-**архитектурный** дефект семантики serial-gate, требующий ADR (выбор механизма «паузы» + разрешение
-конфликта с анти-stale-base ORCH-088).
-
-**Симптом (инцидент ORCH-116/ORCH-123, установленный факт).** Задачу-предшественника ORCH-116
-поставили на паузу (перевели в Plane Blocked/Backlog), чтобы пропустить вперёд срочный фикс ORCH-123.
-`serial_gate` **по-прежнему считал ORCH-116 активной** и держал analyst-job ORCH-123 в `queued` — срочный
-фикс не стартовал, пока ORCH-116 формально не `done`/`cancelled`.
-
-**Причина (верифицировано в коде).** `serial_gate.py` определяет «активную задачу репо» **исключительно
-по машинной стадии** `tasks.stage NOT IN ('done','cancelled')` в трёх точках:
-- `build_claim_clause()` — горячий SQL-фрагмент в `db.claim_next_job` (`src/serial_gate.py:274-278`):
-  `EXISTS (SELECT 1 FROM tasks t2 WHERE t2.repo = jobs.repo AND t2.id < jobs.task_id AND
-  t2.stage NOT IN ('done','cancelled'))`;
-- `repo_has_active_task()` — Python-зеркало (`src/serial_gate.py:117-127`);
-- `_per_repo_snapshot()` — выбор `active_task` для `GET /queue` (`src/serial_gate.py:340-344`).
-
-Plane-статусы Backlog/Blocked/Needs-Input — **слой B (индикация), ORCH-066** — **не меняют `tasks.stage`
-(слой A)**. Сеттеры `set_issue_blocked`/`set_issue_needs_input` делают только `PATCH` Plane-статуса; у
-таблицы `tasks` **нет колонки статуса** (`src/reconciler.py:322`: «`tasks` has no status column, so the
-live Plane state is the source of truth»). ⇒ для serial-gate приостановленная задача неотличима от активно
-исполняемой: её стадия вне `{done,cancelled}` ⇒ она «активна» ⇒ держит FIFO закрытым для всех более
-поздних analyst-job того же репо.
-
-**Прецедент, который НЕ переиспользуем.** `reconciler` уже различает Blocked/Needs-Input
-(`_is_blocked_or_needs_input`, ORCH-060 Guard 2) — но **сетевым** запросом Plane. `serial_gate.build_claim_clause`
-врезан в `claim_next_job` — **offline hot-path** — и сетевого вызова позволить **не может** (NFR-2). Это и
-есть центральное расхождение: сигнал паузы есть в Plane, но недоступен горячему SQL гейта.
-
-**Нужен** явный, durable, **DB-резолвимый** признак «пауза», который горячий SQL читает локально, при этом
-**не регрессирует** анти-stale-base ORCH-088 (R-1) и не ломает гармонизированный терминал `{done,cancelled}`
-(ORCH-090 / adr-0026, NFR-4).
-
----
-
-## Решение
-
-### Сводка
-Вводится **явный per-task park-сигнал** — аддитивная нуллабельная колонка **`tasks.paused_at TEXT`**
-(NULL = не на паузе; non-NULL = поставлена оператором на паузу) — и **новая ортогональная ось
-планировщика «пауза»**, отделённая от оси «терминальность». «Активная задача» для serial-gate
-переопределяется как **`не терминальна И не на паузе`** во всех трёх точках; терминал `{done,cancelled}`
-в `serial_gate`/`task_deps`/`stages.py` остаётся **байт-в-байт**. Намерение паузы задаётся явными
-операторскими эндпоинтами `POST /serial-gate/pause|resume` (по образцу `POST /serial-gate/unfreeze`).
-Анти-stale-base при возобновлении обеспечивают **существующие** механизмы (отложенный срез ветки ORCH-088
-+ pre-merge `auto_rebase_onto_main` под merge-lease ORCH-026/093 + merge-gate re-test ORCH-110) — **новой
-rebase-машинерии не вводится**. Аддитивно, под независимым под-флагом, never-raise, restart-safe.
-`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict / схемы существующих таблиц —
-**не трогаются** (правка планировщика очереди, не Quality Gate).
-
-### D1 — Механизм: явный per-task pause-флаг (а не release-on-status / task_deps) (FR-3, BR-2)
-
-**Решение: явный durable DB-сигнал «park» на уровне задачи**, инициируемый оператором через API, а **не**
-маппинг Plane-статуса и **не** `task_deps`.
-
-Обоснование выбора (см. «Альтернативы» для отклонённых):
-- **Чистое намерение, отличное от cancel и от kill-switch** (BR-2): park ≠ терминал (`cancelled`),
-  ≠ глобальное выключение гейта (`serial_gate_enabled=False`).
-- **DB-резолвимо и offline** (NFR-2): сигнал — колонка локальной БД, читается горячим SQL без сети.
-- **Не перегружает Plane-статус** (ORCH-066/059): pause НЕ управляется сменой Plane-статуса. Оператор
-  может **дополнительно** перевести карточку в Blocked для индикации, но это косметика — гейт ею не
-  управляется. Это прямое следование решению ORCH-088 D4 (снятие freeze Plane-жестом отвергнуто как
-  анти-паттерн ORCH-059).
-- **Durable/идемпотентно/restart-safe** (BR-2/R-3): колонка переживает рестарт; не зависит от доставки
-  webhook (потерянный webhook не рассинхронит сигнал).
-
-### D2 — Хранилище: аддитивная колонка `tasks.paused_at` (а не отдельная таблица) (NFR-3)
-
-**Решение: нуллабельная колонка `tasks.paused_at TEXT`** через `_ensure_column` — паттерн уже
-существующих per-task durable-сигналов `tasks.cancelled_at` / `tasks.cancel_requested_at` / `tasks.track`
-(`src/db.py:141-149`). NULL = не на паузе; ISO-таймстамп = на паузе (момент постановки, наблюдаемость).
-
-Почему **колонка**, а не таблица по образцу `repo_freeze`:
-- Пауза — **per-task** сигнал (кардинальность 1:1 с задачей), в отличие от `repo_freeze` (per-**repo**,
-  append-only журнал истории заморозок).
-- Горячий SQL `build_claim_clause` уже сканирует `tasks t2` — добавление `AND t2.paused_at IS NULL`
-  внутрь существующего `EXISTS`-подзапроса — **минимальная, offline, index-дружественная** правка без
-  лишнего JOIN/EXISTS. Таблица потребовала бы доп. подзапрос в горячем пути.
-- Схемы существующих таблиц (`tasks`/`jobs`/`job_deps`/`repo_freeze`) не меняются деструктивно; миграция —
-  идемпотентный `_ensure_column` (no-op на уже мигрированной БД), безопасна на общей прод-БД (enduro не
-  затронут). Детали — `08-data-requirements.md`.
-
-### D3 — Пауза — ортогональная ось; терминал `{done,cancelled}` не трогается (NFR-4, FR-6 — критично)
-
-**Решение: «активность» для serial-gate = `не терминальна И не на паузе`; терминал остаётся
-`{done,cancelled}` без изменений.**
-
-Это явная, задокументированная дивергенция, которую требует NFR-4. Две независимые оси:
-
-| Ось | Предикат | Где используется | Меняется ORCH-124? |
-|-----|----------|------------------|--------------------|
-| **Терминальность** | `stage IN ('done','cancelled')` | `serial_gate` + `task_deps` + `stages.py` (adr-0026) | **НЕТ — байт-в-байт** |
-| **Пауза (новая)** | `paused_at IS NOT NULL` | **только** FIFO «active» предикат `serial_gate` | да (аддитивно) |
-
-Следствия (закрывает R-4 и FR-6):
-- **serial-gate** «активная задача» = `stage NOT IN ('done','cancelled') AND paused_at IS NULL`. Пауза
-  выводит предшественника из FIFO-учёта serial-gate.
-- **task_deps** НЕ трогается: остаётся чисто терминальным (`stage NOT IN ('done','cancelled')`). Явно
-  объявленная зависимость (`job_deps`) на **приостановленную** задачу **по-прежнему блокирует** зависимый
-  job — пауза НЕ обходит `task_deps` (FR-6/AC-5). Пауза («пропустите меня в FIFO») и dependency
-  («B реально нужен результат A») — разные оси.
-- **stages.py** `STAGE_TRANSITIONS` не трогается: пауза — не стадия и не ребро (нет нового стока/перехода).
-
-### D4 — Три точки serial-gate правятся согласованно (FR-1, FR-2)
-
-Один предикат «активна» во всех трёх точках (анти-дрейф: одинаковый ответ на одинаковый вход), под
-под-флагом паузы (D6):
-
-1. **`build_claim_clause()`** — в `active_clause` добавить терм `AND t2.paused_at IS NULL` (только когда
-   слой паузы включён; иначе фрагмент строится байт-в-байт как ORCH-088/090):
-   ```sql
-   EXISTS (SELECT 1 FROM tasks t2
-            WHERE t2.repo = jobs.repo AND t2.id < jobs.task_id
-              AND t2.stage NOT IN ('done','cancelled')
-              {pause_term})        -- pause_term = " AND t2.paused_at IS NULL" | ""
-   ```
-   Инварианты сохранены: гейт только для `jobs.agent='analyst'`; FIFO `t2.id < jobs.task_id` (R-7,
-   нет самоблокировки); job'ы активной задачи проходят.
-2. **`repo_has_active_task()`** — добавить `AND paused_at IS NULL` (под тем же под-флагом).
-3. **`_per_repo_snapshot()`** — выбор `active_task` исключает приостановленные (`AND paused_at IS NULL`),
-   и отдельно перечисляет приостановленные (D5).
-
-### D5 — Наблюдаемость: причина ожидания + список paused (FR-5, BR-4, AC-6)
-
-`_per_repo_snapshot` расширяется **аддитивно** (существующие ключи `active_task`/`waiting`/`frozen`/
-`frozen_reason`/`frozen_at` — байт-в-байт BC):
-- `active_task` больше **не** показывает приостановленную задачу (D4.3).
-- Новый ключ `paused: [{work_item_id, stage, paused_at}, …]` — приостановленные незавершённые задачи репо
-  (видимы, но не как `active_task`).
-- Для каждого `waiting`-job добавляется `reason` — причина, по которой job НЕ claimable, с приоритетом:
-  **`freeze`** (активен `repo_freeze`) → **`dependency`** (незавершённая `task_deps` для task этого job)
-  → **`active-task`** (есть более ранняя **не-приостановленная** незавершённая задача) → **`null`**
-  (claimable). Категория `paused-predecessor` из ТЗ FR-5 — наблюдается через ключ `paused` (приостановленный
-  предшественник по дизайну **не** блокирует ⇒ не является причиной ожидания после фикса).
-
-### D6 — Условность: независимый под-флаг `serial_gate_pause_enabled` (FR-7, NFR-3)
-
-По образцу `serial_gate_freeze_enabled` (`src/config.py:1006`) — независимый тумблер для поэтапного раската
-и обратимости:
-- `serial_gate_pause_enabled: bool = True` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`). Дефолт `True` безопасен:
-  пока ни одна задача не на паузе (`paused_at` всегда NULL), предикат `AND t2.paused_at IS NULL` всегда
-  истинен ⇒ поведение **идентично** ORCH-088/090 ⇒ **истинный no-op** до явной операторской паузы (enduro
-  не затронут). Постановка на паузу возможна только через явный эндпоинт (D7).
-- `False` ⇒ pause-терм **опускается** из SQL, эндпоинты pause/resume — no-op-предупреждение; serial-gate
-  ведёт себя **байт-в-байт** как ORCH-088/090 (осознанный rollback-режим — возврат к текущему багу, не
-  дефолт).
-- Хелпер `serial_gate._pause_layer_enabled()` (never-raise, зеркало `_freeze_layer_enabled`).
-- **Область** — переиспользует `serial_gate_repos` (пауза — уточнение того же гейта; новый `*_repos`
-  **не** вводится — принцип минимума конфигурации). Под-флаг паузы независим от `serial_gate_freeze_enabled`,
-  но подчинён kill-switch `serial_gate_enabled` (при выключенном гейте паузы нет смысла).
-
-### D7 — Операторские эндпоинты pause/resume (FR-3, BR-5, AC-3, AC-10)
-
-По образцу `POST /serial-gate/unfreeze` (`src/main.py:350-376`), never-raise, с Telegram-подтверждением:
-- **`POST /serial-gate/pause?work_item=<id>`** → `db.set_task_paused(task_id)` (`paused_at=datetime('now')`,
-  идемпотентно). Применимо к **нетерминальной** задаче (паузить `done`/`cancelled` — no-op + явный ответ).
-  Возвращает `{ok, work_item, task_id, paused_at}`.
-- **`POST /serial-gate/resume?work_item=<id>`** → `db.clear_task_paused(task_id)` (`paused_at=NULL`).
-  Возобновлённая задача снова участвует в serial-gate (AC-10): если ещё в `analysis` без ветки —
-  ре-входит в FIFO с отложенным срезом ветки; если уже материализована — держит гейт как активная,
-  её свежесть гарантирует merge-gate (D8). Возвращает `{ok, work_item, task_id, paused_at: null}`.
-- DB-хелперы `db.set_task_paused`/`db.clear_task_paused`/`db.is_task_paused` (по образцу
-  `set_task_track`/`get_task_track`, `src/db.py:740-757`). never-raise.
-- Освобождение гейта — **только** по этому явному durable намерению; эвристического само-распаузивания
-  нет (AC-3, R-2).
-
-### D8 — Анти-stale-base при возобновлении: переиспользуем существующие механизмы (FR-4, R-1 — критично)
-
-**Решение: пауза «демотирует» задачу в FIFO; свежесть базы при возобновлении гарантируют УЖЕ
-существующие механизмы — новой rebase-машинерии НЕ вводится.**
-
-Два случая возобновления:
-1. **Пауза, пока задача ещё в `analysis` с queued analyst-job и НЕматериализованной веткой** (отложенный
-   срез ORCH-088 D1): при resume срез ветки происходит на момент claim analyst-job
-   (`launcher._materialize_deferred_branch`) от **тогда-актуального** `origin/main` — который уже содержит
-   любого успешника, смерженного за время паузы. База **структурно свежая** ⇒ stale-base невозможна.
-2. **Пауза после материализации ветки** (development/review/testing/deploy-staging): ветка уже срезана от
-   более раннего `main`. За время паузы успешник может смержиться ⇒ `main` уходит вперёд. При resume, когда
-   задача дойдёт до merge-gate (`deploy-staging → deploy`), **существующий безусловный pre-merge
-   `auto_rebase_onto_main` под merge-lease** (ORCH-026/088/093) перебазирует ветку на актуальный `main`, а
-   **merge-gate re-test** (ORCH-110) перепрогоняет сюиту на перебазированном HEAD. Свежесть обеспечивается
-   на merge, **не обходится**.
-
-Итог (разрешение конфликта R-1): пауза меняет **только порядок FIFO** (кто держит гейт), но **не**
-контракт свежести на merge. Нормально исполняемая задача (`paused_at IS NULL`) по-прежнему держит гейт ⇒
-анти-stale-base для нормального случая (BR-3/AC-2) не регрессирует. Порядок merge при «B обгоняет
-паузнутую A» = B, затем A (A ребейзится на B) — ровно намерение оператора. Проверяемо тестом по контракту
-ADR (AC-4).
-
-### D9 — never-raise и сохранённые fail-directions (NFR-1, AC-9)
-
-- **`build_claim_clause`** остаётся **fail-OPEN**: pause-терм строится **внутри** существующего
-  `try/except`; любая ошибка (в т.ч. в pause-подвыражении) → `""` → claim без гейта (не заклинить очередь
-  всех проектов, AC-8). Направление не инвертируется.
-- **Freeze** остаётся **fail-CLOSED** (`is_repo_frozen`, AC-9) — pause-логика его не касается.
-- Pause-зеркало/снапшот/мутаторы never-raise → консервативная деградация (на ошибке чтения паузы в зеркале
-  — «не на паузе», т.е. задача считается активной = гейт скорее закрыт = анти-stale-base-safe).
-
----
-
-## Точки врезки (для разработчика)
-
-| Файл | Изменение |
-|------|-----------|
-| `src/db.py` | `_ensure_column(conn, "tasks", "paused_at", "TEXT")` (D2); хелперы `set_task_paused`/`clear_task_paused`/`is_task_paused` (D7) |
-| `src/serial_gate.py` | `_pause_layer_enabled()` (D6); pause-терм в `build_claim_clause` (D4.1); `AND paused_at IS NULL` в `repo_has_active_task` (D4.2) и `_per_repo_snapshot` (D4.3); ключ `paused` + `reason` в снапшоте (D5). Маркер `ORCH-124` рядом с `ORCH-088`/`ORCH-090` |
-| `src/config.py` | `serial_gate_pause_enabled: bool = True` (D6) |
-| `src/main.py` | `POST /serial-gate/pause`, `POST /serial-gate/resume` (D7); блок `serial_gate` в `GET /queue` уже зовёт `snapshot()` (D5 — расширение прозрачно) |
-| `tests/test_orch124_serial_gate_pause.py` | **новый** — AC-1 регресс инцидента (красный до фикса, зелёный после), AC-2…AC-10 |
-| `docs/architecture/README.md`, `internals.md`, `CHANGELOG.md` | обновить раздел serial-gate + ось паузы (golden source) |
-
-`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / `start_pipeline` / `launcher`
-deferred-branch / merge-gate / схемы существующих таблиц — **не трогаются**.
-
----
-
-## Альтернативы (отклонены)
-
-- **Release-on-status (Plane Blocked/Backlog → DB-сигнал через webhook)** — отвергнуто: перегружает
-  Plane-статус управлением конвейером (нарушает слой A/B ORCH-066 и анти-паттерн ORCH-059, ровно как
-  ORCH-088 D4 отверг снятие freeze Plane-жестом); хрупко к потере webhook (R-3); намерение не доступно
-  offline hot-path (NFR-2).
-- **Переиспользовать `task_deps`** — отвергнуто: `task_deps` моделирует «B ждёт A», не умеет выразить
-  «A на паузе, остальных пропустить» (обратное направление). Кроме того, пауза НЕ должна обходить
-  объявленную зависимость (FR-6) — это разные оси (D3).
-- **Отдельная таблица `task_hold` (по образцу `repo_freeze`)** — отвергнуто: пауза per-task 1:1; колонка
-  минимальнее и не требует JOIN в горячем SQL (D2). `repo_freeze` — таблица, т.к. per-repo append-only журнал.
-- **Реюз `repo_freeze` для паузы** — отвергнуто: freeze замораживает **весь репо** (блокирует всех
-  успешников) — противоположность «пропустить срочного успешника».
-- **Расширить терминал `{done,cancelled,paused}`** — отвергнуто: пауза не терминальна; это сломало бы
-  `task_deps`/`stages.py` (NFR-4). Пауза — ортогональная ось, не терминальное состояние (D3).
-- **Новая rebase-машинерия при resume** — отвергнуто как избыточное: существующие отложенный срез +
-  merge-gate rebase/re-test уже покрывают свежесть (D8).
-
----
-
-## Последствия
-
-### Плюсы
-- **+** Закрывает инцидент ORCH-116/ORCH-123 (AC-1): срочный фикс стартует поверх паузнутого предшественника.
-- **+** Чистое, явное, durable намерение паузы, отличное от cancel и kill-switch (BR-2); webhook-независимо
-  (R-3); offline hot-path (NFR-2).
-- **+** Терминал `{done,cancelled}` и `task_deps`/`stages.py` — байт-в-байт (NFR-4); пауза НЕ обходит
-  freeze/dependency (FR-6).
-- **+** Анти-stale-base (ORCH-088) не регрессирует — нормальная задача держит гейт; resume опирается на
-  существующие отложенный срез + merge-gate rebase/re-test (D8, AC-2/AC-4).
-- **+** Переиспользует проверенные паттерны (`cancelled_at`-колонка, `unfreeze`-эндпоинт, leaf never-raise,
-  `/queue`-снапшот). `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схемы существующих таблиц — без изменений.
-- **+** Истинный no-op для enduro при дефолтном флаге (пауза не выставлена) и байт-в-байт откат при флаге off.
-
-### Минусы / ограничения
-- **−** Пауза — операторское действие через API (не Plane-жест). Митигейшн: симметрично существующему
-  `unfreeze`; задокументировано в README + Telegram-подтверждение; оператор может дополнительно перевести
-  карточку в Blocked для индикации.
-- **−** «Залипшая пауза» при невнимании оператора (resume забыт) → задача навсегда вне гейта. Митигейшн:
-  наблюдаемость (`paused` в `GET /queue`); resume идемпотентен; намерение durable, не теряется (R-2).
-- **−** Горячий SQL serial-gate теперь несёт 3 маркера (`ORCH-088`/`ORCH-090`/`ORCH-124`) ⇒ сводный
-  сквозной ADR `adr-0051` (анти-археология, TRACEABILITY.md).
-
-### Откат
-Полный откат — `ORCH_SERIAL_GATE_PAUSE_ENABLED=false` (serial-gate 1:1 как ORCH-088/090; pause-терм
-опущен, эндпоинты no-op). Колонка `tasks.paused_at` инертна при выключенном под-флаге. Глубже —
-`serial_gate_enabled=false` (весь гейт инертен, как до ORCH-088).
-
----
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-124/01-brd.md` · ТЗ: `02-trz.md` · Acceptance: `03-acceptance-criteria.md`
-- Данные: `docs/work-items/ORCH-124/08-data-requirements.md` · Риски: `10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md`
-- Сверено по коду: `src/serial_gate.py` (117-127, 274-278, 340-344), `src/db.py` (claim_next_job
-  1043-1110, `_ensure_column`/tasks-колонки 141-149, 740-757), `src/main.py` (350-376), `src/config.py`
-  (1004-1006), `src/reconciler.py:322`
-- Базовые решения: adr-0017 (serial-gate ORCH-088), adr-0026 (терминал `{done,cancelled}` ORCH-090),
-  adr-0015 (task-deps ORCH-026), adr-0027 (merge-актор rebase/retry ORCH-093), adr-0042 (merge-gate
-  re-test ORCH-110)

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

@@ -1,53 +0,0 @@
----
-work_item: ORCH-124
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-16
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-124 — per-task park-сигнал serial-gate
-
-Work Item: **ORCH-124** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable / информационный (гейтом не парсится).
-
-## Изменения схемы БД
-
-**Одна аддитивная нуллабельная колонка** на существующей таблице `tasks` (никаких новых таблиц):
-
-| Таблица | Колонка | Тип / дефолт | Семантика |
-|---------|---------|--------------|-----------|
-| `tasks` | `paused_at` | `TEXT` (по умолчанию отсутствует → `NULL`) | `NULL` = не на паузе; ISO-таймстамп (`datetime('now')`) = задача поставлена оператором на паузу (park) |
-
-Миграция — идемпотентный `_ensure_column(conn, "tasks", "paused_at", "TEXT")` в `init_db()`, ровно по
-образцу `tasks.cancelled_at` / `tasks.cancel_requested_at` / `tasks.track` (`src/db.py:141-149`). На уже
-мигрированной БД — no-op.
-
-**Индекс не требуется.** Горячий SQL `build_claim_clause` сканирует `tasks t2` уже сегодня (по `repo`/`id`);
-терм `AND t2.paused_at IS NULL` — дополнительный фильтр в существующем `EXISTS`-подзапросе, не новый план
-доступа. Кардинальность `tasks` per-repo мала; добавление индекса — преждевременная оптимизация (принцип
-минимума).
-
-## Новые/изменённые сущности
-
-- **`tasks.paused_at`** — единственное durable хранилище намерения паузы. Запись — `db.set_task_paused`
-  (`paused_at=datetime('now')`); сброс — `db.clear_task_paused` (`paused_at=NULL`); чтение —
-  `db.is_task_paused` и SQL-предикат serial-gate. Все хелперы never-raise.
-- **Инвариант оси:** `paused_at` — **ортогональная** ось «пауза», независимая от оси «терминальность»
-  (`stage IN ('done','cancelled')`). serial-gate «активна» = `stage NOT IN ('done','cancelled') AND
-  paused_at IS NULL`. `task_deps`/`stages.py` колонку `paused_at` **не читают** (терминал не трогается,
-  NFR-4).
-- **Существующие таблицы** (`jobs` / `job_deps` / `repo_freeze` / `agent_runs`) — без изменений.
-
-## Совместимость данных / миграции
-
-- **Аддитивно и идемпотентно:** `_ensure_column` — no-op на уже-мигрированной БД; новая колонка
-  дефолтит в `NULL` для всех существующих строк ⇒ все текущие задачи считаются «не на паузе» ⇒ поведение
-  до ORCH-124 сохраняется до первой явной операторской паузы.
-- **Restart-safe / durable:** значение в БД переживает рестарт процесса/контейнера (BR-2, R-3).
-- **Общая прод-БД (self-hosting):** колонка добавляется на общей БД; при дефолтном `serial_gate_pause_enabled`
-  и отсутствии паузнутых задач — нулевая регрессия для enduro (`paused_at` везде `NULL`).
-- **Откат:** колонка инертна при `ORCH_SERIAL_GATE_PAUSE_ENABLED=false` (pause-терм опускается из SQL).
-  Колонку можно оставить (безвредна); деструктивный drop не требуется и не рекомендуется на прод-БД.

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

@@ -1,40 +0,0 @@
----
-work_item: ORCH-124
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-16
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-124 — serial-gate «пауза без блокировки»
-
-Work Item: **ORCH-124** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и митигейшн; покрывает R-1…R-5 из BRD §8.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 (= R-1, ключевой) | **Пауза vs анти-stale-base ORCH-088.** Успешник срезает ветку от `main` без кода паузнутого предшественника; при возобновлении предшественника возможна stale-база/затирание. | Сред. | Выс. | **D8:** новой 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`) по-прежнему держит гейт (BR-3/AC-2). Тест AC-4. |
-| TR-2 (= R-2) | **Неявное/случайное освобождение гейта** (баг в детекте намерения) ослабит сериализацию для всех. | Низ. | Выс. | Освобождение **только** по явной операторской паузе через эндпоинт (D7); никакого эвристического само-распаузивания (AC-3). Дефолтный флаг безопасен (no-op без явной паузы). Тест AC-3. |
-| TR-3 (= R-3) | **Рассинхрон Plane-статус ↔ DB-сигнал паузы** (потерянный webhook оставит сигнал устаревшим). | Низ. | Сред. | Механизм НЕ опирается на webhook/Plane-статус (D1): сигнал — durable колонка `tasks.paused_at`, пишется прямым операторским вызовом, идемпотентен, переживает рестарт. Plane-статус — только косметическая индикация. |
-| TR-4 (= R-4) | **Регрессия гармонизированного терминала `{done,cancelled}`** в `task_deps`/`stages.py`. | Низ. | Выс. | **D3:** пауза — отдельная ось; терминал `{done,cancelled}` в `serial_gate`/`task_deps`/`stages.py` байт-в-байт. `task_deps` колонку `paused_at` не читает (паузнутая зависимость по-прежнему блокирует, FR-6/AC-5). Структурный тест AC-8. |
-| TR-5 (= R-5) | **Инверсия fail-direction** (ошибка в pause-ветке роняет claim или меняет fail-OPEN/fail-CLOSED). | Низ. | Выс. | **D9:** pause-терм внутри `try/except` `build_claim_clause` → fail-OPEN сохранён; freeze fail-CLOSED не тронут; все pause-функции never-raise. Тест AC-9 (инъекция ошибки → claim не падает). |
-| TR-6 | **«Залипшая пауза»** — оператор забыл `resume`, задача навсегда вне FIFO-учёта. | Сред. | Низ. | Наблюдаемость: ключ `paused` + `reason` в `GET /queue` (D5); `resume` идемпотентен; durable сигнал не теряется. Операторская гигиена (как «вечный freeze» ORCH-088). |
-| TR-7 | **Дрейф трёх точек** serial-gate (одна правится, другие нет → расхождение SQL-гейта и снапшота). | Низ. | Сред. | **D4:** один предикат «активна» во всех трёх точках, под одним под-флагом; анти-дрейф-тест (одинаковый ответ на одинаковый вход). |
-| TR-8 | **Миграция колонки на общей прод-БД** (self-hosting) затронет enduro. | Низ. | Сред. | Идемпотентный `_ensure_column`, дефолт `NULL` (паттерн `cancelled_at`/`track`); при дефолтном флаге и отсутствии паузнутых задач — нулевая регрессия (08-data-requirements). |
-
-## Сводный вывод
-
-Доминирующий класс — **семантический конфликт паузы с анти-stale-base (TR-1)**, разрешённый
-**переиспользованием существующих** механизмов свежести (D8), без новой машинерии. Остальные риски —
-стандартные для leaf-расширения serial-gate (fail-direction, дрейф точек, миграция), покрыты паттернами
-ORCH-088/090. Изменение **аддитивно, под независимым под-флагом, never-raise**, без правки
-`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/терминала/схем существующих таблиц.
-
-**Эскалация `arch:major-change` не требуется** (нет новой стадии/компонента/QG/смены БД — аддитивная
-правка планировщика внутри существующего компонента serial-gate). Возврат в анализ не требуется (ТЗ
-удовлетворяется без нарушения принципов архитектуры). Остаточный риск для прод-конвейера (self-hosting) —
-**низкий**: дефолтное поведение — истинный no-op до явной операторской паузы; полный откат — один env-флаг.

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

@@ -1,132 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-124
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-16
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-124
-version: 3
----
-
-# Review ORCH-124 — serial-gate «пауза без блокировки» (per-task park-сигнал)
-
-## Summary
-
-Багфикс (метка `Bug`, эскалирован в full-cycle) инцидента ORCH-116/ORCH-123: serial-gate считал
-«активной» любую задачу со стадией вне `{done,cancelled}`, а Plane-статусы Backlog/Blocked/Needs-Input
-(слой B) не меняют `tasks.stage` (слой A) ⇒ приостановленный предшественник держал FIFO-гейт закрытым
-против срочного успешника. Решение — **ортогональная ось планировщика «пауза»**: аддитивная колонка
-`tasks.paused_at TEXT` + терм `AND paused_at IS NULL` во всех 3 точках определения «активной задачи»
-(`build_claim_clause`/`repo_has_active_task`/`_per_repo_snapshot`), операторские эндпоинты
-`POST /serial-gate/pause|resume`, под независимым под-флагом `serial_gate_pause_enabled`.
-
-**Вердикт: APPROVED.** Оба замечания предыдущего ревью (run v2) устранены коммитом `58e5dfe`:
-- **P1 (витрина `docs/overview/`)** → исправлено: `tech-pipeline.md` (ось «пауза без блокировки» рядом
-  с исключением freeze), `tech-data-model.md` (durable-сигнал `tasks.paused_at`), `tech-observability.md`
-  (`paused`/`reason` в блоке `serial_gate` `GET /queue` + эндпоинты `pause|resume`) — синхронно в этом PR.
-- **P2 (хвостовые tool-call-теги)** → исправлено: все 4 golden-source дока этого PR
-  (`06-adr/ADR-001`, `adr-0051`, `08-data-requirements.md`, `10-tech-risks.md`) очищены (проверено
-  `tail` + grep по изменённым `.md`; оставшиеся совпадения — лишь описательная проза в `CHANGELOG.md`/
-  этом ревью).
-
-Ядро фикса (код + ТЗ + ADR + тесты) — высокого качества, P0/P1-замечаний по сути нет. Реализация 1:1
-соответствует ADR-001 (D1–D9), закрывает все FR/AC, машинные инварианты не тронуты. Целевой прогон
-`tests/test_orch124_serial_gate_pause.py` + `tests/test_orch123_staging_runner_exec.py` +
-`tests/test_system_docs.py` зелёный (**70 passed**).
-
-## Проверка по осям
-
-### 1. Соответствие ТЗ (`02-trz.md` / `03-acceptance-criteria.md`) — ✅
-- FR-1 (пауза исключает из горячего SQL): `build_claim_clause` — терм `AND t2.paused_at IS NULL` внутри
-  существующего `EXISTS`, offline, fail-OPEN сохранён (внутри того же `try/except`). ✓
-- FR-2 (зеркало + снапшот согласованы): один предикат во всех 3 точках; анти-дрейф — **TC-11**. ✓
-- FR-3 (явное durable DB-намерение): колонка `paused_at` + `set/clear/is_task_paused` + эндпоинты;
-  durable через рестарт — **TC-06**. ✓
-- FR-4 (анти-stale-base при resume): через существующие механизмы (D8), без новой rebase-машинерии. ✓
-- FR-5 (причина ожидания): `_waiting_reason` (`freeze`→`dependency`→`active-task`→`null`) + ключ
-  `paused` — **TC-10**. ✓
-- FR-6 (явные блоки сохранены): пауза НЕ обходит `repo_freeze`/`task_deps` — **TC-08/TC-09**
-  (подтверждено: `task_deps` читает только терминал `{done,cancelled}`, не `paused_at`). ✓
-- FR-7 (условность/нейтральность): под-флаг + scope `serial_gate_repos`; kill-switch off байт-в-байт —
-  **TC-14**. ✓
-- AC-1…AC-10 покрыты TC-01…TC-15 буквально по файлам/тестам; целевой прогон зелёный (70 passed).
-
-### 2. Соответствие ADR (`06-adr/ADR-001`, сквозной `adr-0051`) — ✅
-Реализация = ADR 1:1: D1 (явный per-task флаг), D2 (`tasks.paused_at` через `_ensure_column`, паттерн
-`cancelled_at`/`track`), D3 (ортогональная ось — терминал `{done,cancelled}` **байт-в-байт**), D4 (3
-точки согласованно), D5 (наблюдаемость), D6 (`serial_gate_pause_enabled`), D7 (эндпоинты), D8
-(анти-stale-base реюзом существующих механизмов), D9 (never-raise/fail-directions).
-- **Трассировка (ORCH-078/TRACEABILITY):** правка горячего SQL с маркерами `ORCH-088`/`ORCH-090` —
-  инвариант FIFO (`t2.id < jobs.task_id`, R-7) и терминал-множество `{done,cancelled}` (adr-0026) **не
-  сломаны** (структурный **TC-15** + сверка: `src/task_deps.py`/`src/stages.py` вне диффа, `paused_at` не
-  читают). Маркер `ORCH-124` размещён рядом; сводный сквозной `adr-0051` заведён. ✓
-- Нет нарушений глобальных ADR. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы
-  существующих таблиц — не тронуты (дифф `src/**` = только `config.py`/`db.py`/`main.py`/`serial_gate.py`;
-  `stages.py`/`qg/`/`frontmatter.py`/`task_deps.py` вне диффа — подтверждено `git diff --name-only`). ✓
-
-### 3. Качество кода — ✅
-- Чисто, читаемо; docstrings на всех новых публичных функциях; маркеры/ссылки на ADR в коде.
-- never-raise на всех публичных функциях `serial_gate`/`db`-хелперах; hot-claim fail-OPEN
-  (pause-терм внутри `try/except` → ошибка `_pause_layer_enabled` даёт `build_claim_clause()==""`),
-  freeze fail-CLOSED — направления не инвертированы (**TC-13**). ✓
-- Helper-сигнатуры выверены по коду: `db.get_task_by_work_item_id` существует и возвращает `dict`
-  (`SELECT *` ⇒ `paused_at` попадает в результат), `notifications.link_for`/`send_telegram` существуют
-  (паттерн `from .notifications import send_telegram, link_for` уже используют `coverage_gate`/
-  `staging_runner`). `resume`-эндпоинт сознательно НЕ гейтится `_pause_layer_enabled()` (позволяет снять
-  «залипшую» паузу после выключения слоя) — корректное решение, не дефект.
-- **Багфикс-трек (ORCH-019 BR-4) — выполнен:** обязательный регресс-тест-фиксатор **TC-01** воспроизводит
-  инцидент (красный до фикса — опирается на отсутствовавшие `set_task_paused`/`paused_at`; зелёный после);
-  «до-фикса»-поведение бага дополнительно зафиксировано в **TC-14** (kill-switch off → паузнутая задача
-  снова блокирует). ✓
-- Тесты содержательные (15 TC, не тривиальные): регресс инцидента, анти-регресс ORCH-088, durable/restart,
-  resume, сохранность freeze/dependency, снапшот-reason, анти-дрейф 3 точек, offline hot-path,
-  never-raise/fail-OPEN, kill-switch-нейтральность, структурный анти-регресс реестров/схем.
-- **Тест-гигиена (коммит `3a19728`):** изоляция `settings.repos_dir` в фикстуре
-  `tests/test_orch123_staging_runner_exec.py` устранила order-dependent FAIL `test_r2…` (фолбэк
-  `check_staging_status` на реальный `<repos_dir>/orchestrator/.../15-staging-log.md` после мержа
-  ORCH-123). `cfg` импортирован в файле (стр. 39); инвариант ORCH-123 R-2 сохранён; правка только теста;
-  прозрачно задокументирована в CHANGELOG. Не блокирует.
-
-### 4. Документация (обязательная ось) — ✅ обновлена полно
-`src/` изменён → документация обновлена синхронно в том же PR:
-- ✅ `docs/architecture/README.md` (раздел serial-gate + ось «пауза», таблица БД `paused_at`, таблица
-  API `/serial-gate/pause|resume`), `docs/architecture/internals.md` (ось «пауза» ⊥ «терминальность»),
-  `CHANGELOG.md` (развёрнуто), `.env.example` (`ORCH_SERIAL_GATE_PAUSE_ENABLED`).
-- ✅ ADR `06-adr/ADR-001` + сквозной `adr-0051`, `08-data-requirements.md`, `10-tech-risks.md`.
-- ✅ **Витрина системы `docs/overview/` (ORCH-011) — обновлена** (исправление P1 предыдущего ревью):
-  `tech-pipeline.md` (исключение FIFO «пауза без блокировки»), `tech-data-model.md` (`tasks.paused_at`),
-  `tech-observability.md` (`paused`/`reason` + эндпоинты). `tests/test_system_docs.py` — зелёный.
-- ✅ Root `README.md` «Известные ограничения»: п. про эпик ORCH-088 (пакетный автоном) данным багфиксом
-  не закрывается → обновления не требует.
-
-## Findings
-
-### P0 — Blocker
-- Нет.
-
-### P1 — Must fix
-- Нет. (Оба замечания предыдущего ревью — P1 витрина + P2 теги — устранены коммитом `58e5dfe`.)
-
-### P2 — Should fix
-- Нет открытых. (Ранее P2 «хвостовые tool-call-теги в 4 доках» устранён.)
-
-### P3 — Nice-to-have (не блокирует)
-- [ ] HTTP-уровневых тестов для `POST /serial-gate/pause|resume` нет (терминальный no-op / под-флаг-off
-  no-op / success+telegram). Не блокирует: тонкая обёртка над полностью покрытыми
-  `db.set/clear/is_task_paused`, а SQL-предикат гейта протестирован исчерпывающе; соответствует конвенции
-  репо (соседние операторские эндпоинты `/serial-gate/unfreeze`, `/transition-lease/release` тоже без
-  HTTP-тестов).
-- [ ] `.task-dev.md` (dev-скретч, обновлён метаданными ORCH-124) — pre-existing трекаемый паттерн, вне
-  области ORCH-124; кандидат на `.gitignore` отдельной задачей.
-
-## Документация
-`src/` изменён (`config`/`db`/`main`/`serial_gate`). Все классы документации обновлены синхронно и
-качественно: инженерные доки (`README.md` архитектуры, `internals.md`, `CHANGELOG.md`, `.env.example`),
-оба ADR (work-item `06-adr/ADR-001` + сквозной `adr-0051`), `08-data-requirements.md`, `10-tech-risks.md`,
-**и обзорная витрина `docs/overview/`** (`tech-pipeline.md`/`tech-data-model.md`/`tech-observability.md` —
-маршрут задач serial-gate с осью «пауза»). Машинные доковые инварианты целы (`test_system_docs.py`
-зелёный). Документация = golden source наравне с кодом — требование выполнено. Ось документации **закрыта**,
-блокирующих находок нет → `APPROVED`.

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

@@ -1,40 +0,0 @@
----
-result: PASS
-work_item: ORCH-124
-stage: testing
-author_agent: test-runner
-status: success
-created_at: 2026-06-16
-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):
-```
-.............................................. [ 66%]
-........................................................................ [ 69%]
-........................................................................ [ 72%]
-........................................................................ [ 76%]
-........................................................................ [ 79%]
-........................................................................ [ 82%]
-........................................................................ [ 85%]
-........................................................................ [ 89%]
-........................................................................ [ 92%]
-........................................................................ [ 95%]
-........................................................................ [ 99%]
-..................                                                       [100%]
-=============================== warnings summary ===============================
-src/config.py:8
-  /repos/_wt/orchestrator/feature_ORCH-124-bug-serial-gate-treats-backlog/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
-2178 passed, 1 warning in 97.64s (0:01:37)
-```

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

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

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-124
-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 730cf106-52af-43ad-b8a4-c59fd5f12277 (HTTP 204)
-  ·      CLEANUP DB: no task row found for plane_id=730cf106-52af-43ad-b8a4-c59fd5f12277
-  ·      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-126/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: BUG: queued job can keep stale run_id/pid and never be claimed even with serial gate disabled
-
-Work Item ID: ORCH-126
-
-## Description
-
-TBD