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

Create docs/operations/FAQ_STOP.md — a user-facing "вопрос → ответ" FAQ for
Plane board users explaining the STOP status: what it does, how to cancel a
task, step-by-step consequences (agent stops → jobs cancelled → working branch
and worktree removed → task → cancelled → Telegram+Plane; docs artifacts
preserved, main/prod untouched), deferred cancellation in the critical
merge/deploy window, explicit "STOP does NOT revert merged/deployed code"
(revert is a separate task), restart only via "To Analyse" from scratch, no-op
causes, where to observe the result, and STOP/Approved/Confirm Deploy disambig.

docs-only: src/**, STAGE_TRANSITIONS, QG_CHECKS, check_*, machine-verdict keys
and the DB schema are byte-for-byte untouched. STOP behaviour source of truth
remains ORCH-090 (adr-0026); the FAQ documents and links to it (link-first:
machine details markers/lease/tombstone given by reference, not duplicated).

Add two-way cross-links: docs/overview/business.md (Сценарий 6) and
docs/overview/tech-pipeline.md (Отмена: STOP → cancelled) → FAQ; FAQ → overview
+ ADR ORCH-090. Structure guarded by deterministic anti-drift test
tests/test_faq_stop_doc.py (offline, no network/LLM/subprocess; mirrors
tests/test_lite_setup_doc.py): existence + 8 section anchors + fact bricks +
cross-links + claim-level negative scan (sentence-level, not bare substrings,
so it never false-fails on correctly negating phrases — TR-3, with a
non-evergreen self-check). Full pytest tests/ green (2227 passed).

Refs: ORCH-108

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

.env.example

@@ -230,9 +230,28 @@ 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)
@@ -447,6 +466,18 @@ 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`)

.openclaw/agents/analyst.md

@@ -40,6 +40,21 @@ 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>
@@ -52,6 +67,10 @@ bug-report (симптом / шаги воспроизведения / лока
 | `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** —
 ориентируйся на их детальность и формат.

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-116
+Work item: ORCH-108
 Repo: orchestrator
-Branch: feature/ORCH-116-orch-replace-llm-tester-with-d
+Branch: feature/ORCH-108-19c40858
 Stage: development

CHANGELOG.md

@@ -3,6 +3,48 @@
 Формат: [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).

docs/_standards/PIPELINE_DOCS.md

@@ -47,6 +47,7 @@ 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` | то же | — |
@@ -72,6 +73,10 @@ 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

@@ -0,0 +1,43 @@
+---
+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/README.md

@@ -621,10 +621,63 @@ ORCH-027 вводит детерминированный (без LLM) **гейт
   `serial_gate_freeze_enabled`. Наблюдаемость — аддитивный блок `serial_gate` в `GET /queue`
   (per-repo `active_task` / `waiting` / `frozen`). Cross-repo параллелизм сохранён (FR-3); при
   выключенном флаге — нулевая регрессия (enduro не затронут).
+- **Ось «пауза без блокировки» (ORCH-124 — [adr-0051](adr/adr-0051-serial-gate-pause-without-blocking.md)).**
+  Баг (инцидент ORCH-116/ORCH-123): serial-gate считал «активной» задачу **исключительно по машинной
+  стадии**, а Plane-статусы Backlog/Blocked/Needs-Input (слой B индикации, ORCH-066) **не меняют
+  `tasks.stage`** ⇒ приостановленный предшественник держал FIFO закрытым против срочного успешника, и у
+  оператора не было чистого механизма «пауза без блокировки», отдельного от cancel (терминал) и от
+  глобального выключения гейта. Решение — **явный per-task park-сигнал**: аддитивная колонка
+  `tasks.paused_at TEXT` (NULL = не на паузе; паттерн `cancelled_at`/`track`) + **новая ортогональная ось
+  планировщика «пауза»**, отделённая от оси «терминальность». serial-gate «активна» ⇔
+  `stage NOT IN ('done','cancelled') AND paused_at IS NULL` (терм `AND t2.paused_at IS NULL` во всех 3
+  точках под под-флагом). **Терминал `{done,cancelled}` в `serial_gate`/`task_deps`/`stages.py` —
+  байт-в-байт (adr-0026 не регрессирует)**: `task_deps`/`stages.py` колонку `paused_at` НЕ читают ⇒
+  паузнутая объявленная зависимость и `repo_freeze` **по-прежнему блокируют** (пауза их не обходит — разные
+  оси). Намерение — явные эндпоинты `POST /serial-gate/pause|resume?work_item=<id>` (по образцу
+  `unfreeze`), durable/offline/webhook-независимо (NFR-2). **Анти-stale-base (ORCH-088) не регрессирует:**
+  нормальная задача (`paused_at IS NULL`) держит гейт; при resume свежесть базы дают существующие механизмы
+  — отложенный срез (для паузнутой-в-`analysis`) и pre-merge `auto_rebase_onto_main` + merge-gate re-test
+  (ORCH-026/093/110) для материализованной ветки; новой rebase-машинерии нет. Наблюдаемость — ключ `paused`
+  + `reason` ожидания (`active-task`/`dependency`/`freeze`) в блоке `serial_gate` `GET /queue`. Под-флаг
+  `serial_gate_pause_enabled` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`, дефолт `True`; зеркало
+  `serial_gate_freeze_enabled`); `False` ⇒ pause-терм опущен, serial-gate байт-в-байт ORCH-088/090. Дефолт
+  безопасен (no-op, пока ничего не паузнуто — enduro не затронут). `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+  схемы существующих таблиц — не тронуты. Детали —
+  `docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`.
 
-Подробнее: [adr-0017](adr/adr-0017-serial-gate.md), детально —
-`docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`,
-`docs/work-items/ORCH-088/08-data-requirements.md`.
+Подробнее: [adr-0017](adr/adr-0017-serial-gate.md) + [adr-0051](adr/adr-0051-serial-gate-pause-without-blocking.md)
+(пауза), детально — `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`,
+`docs/work-items/ORCH-088/08-data-requirements.md`,
+`docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`.
+
+### Открытые вопросы аналитика → Needs Input (ORCH-120 — реализовано, [adr-0053](adr/adr-0053-analyst-open-questions-needs-input-flow.md))
+При неоднозначном бизнес-запросе у аналитика не было рабочего канала уточнения — он **фабриковал**
+требования, чтобы сдать обязательные 4 файла. Механизм «вопросы → Needs Input» в
+`_handle_analysis_approved_flow` (`src/stage_engine.py`) существовал, но был **мёртв** (контракт не в
+промпте; ветка `files_ok` имела приоритет; Needs Input клинил serial-gate; нет гигиены устаревшего
+`01-questions.md`). ORCH-120 **активирует и достраивает** путь — аддитивно, под kill-switch, скоуп
+self-hosting, never-raise; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД —
+**байт-в-байт не тронуты** (поток — pre-gate-ветка движка, **не** QG; `01-questions.md` — сигнальный
+артефакт, **не** machine-verdict).
+- **Контракт + канон.** `.openclaw/agents/analyst.md` документирует «блокирующие вопросы →
+  `01-questions.md`, НЕ фабриковать deliverables»; `01-questions.md` стандартизирован как
+  `when-applicable` сигнальный артефакт (скелет `docs/_templates/` + строка `PIPELINE_DOCS.md`).
+- **Приоритет «вопросы активны» > «файлы готовы»** в `_handle_analysis_approved_flow` (DQ-3) →
+  блокирующие вопросы достигают Needs Input даже при частичных/сфабрикованных deliverables. Чистая
+  логика решения — leaf `src/analyst_questions.py` (`questions_gate_applies`/`autopause_applies`/
+  `questions_active`, never-raise); side-effects (`set_issue_needs_input`/коммент/Telegram/park) —
+  в `stage_engine` (`_decide_analysis_outcome`/`_emit_analysis_*`).
+- **Авто-park (DQ-1)** через ось «пауза» ORCH-124 (`db.set_task_paused` при Needs Input) → задача
+  исключается из «активного» предиката serial-gate, FIFO репо не клинит, пока ждём человека;
+  **resume + unpark** в `handle_status_start` (analysis-ветка, `clear_task_paused`).
+- **Устаревание (DQ-2)** — детерминированный offline freshness-supersede по mtime (вопросы активны,
+  пока пакет неполон ИЛИ `01-questions.md` не старше всех 4 deliverables) → полный свежий пакет
+  supersede’ит старый файл без зависимости от LLM.
+- **Флаги** (`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 только у аналитика) не расширяется.
+  Детали — `docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md`.
 
 ### Авто-режим по лейблам: autoApprove + autoDeploy (ORCH-089 — реализовано)
 Конвейер имеет два **человеческих** гейта, тормозящих пакетный автономный прогон (эпик
@@ -1245,7 +1298,11 @@ ORCH-065 вводит фоновый watchdog, чтобы смерть проц
 - **Job-reaper** (`src/job_reaper.py`) — daemon-поток по образцу `reconciler`,
   работает **без рестарта**. Трёхуровневая liveness: Tier-1 мёртвый `jobs.pid`
   (новая колонка) после `reaper_dead_ticks` подряд тиков (анти-ложноположительность
-  — живой долгий агент не реапится); Tier-2 `agent_runs.exit_code` записан, а job
+  — живой долгий агент не реапится; `pid IS NULL`/живой → streak сбрасывается, не
+  реапит). **Предусловие Tier-1 (ORCH-126, adr-0052):** `jobs.pid` отражает процесс
+  ИМЕННО текущего run'а — обеспечивается инвариантом «`queued ⇒ run_id/pid IS NULL`»
+  (queued-job не несёт stale pid; переиспользованный pid иначе дал бы фантомный
+  «живой» `running`, клинящий очередь). Tier-2 `agent_runs.exit_code` записан, а job
   ещё `running` — но это окно неоднозначно (живой monitor пишет exit_code ПЕРВЫМ,
   затем git push/PR/Plane-комментарии), поэтому Tier-2 реапит только после
   finalization-grace `reaper_finalize_grace_s` (живой финализирующий monitor НЕ
@@ -1410,9 +1467,9 @@ Monitoring after Deploy → Done
 
 ## База данных (SQLite)
 - `events` — входящие вебхуки (дедуп)
-- `tasks` — задачи и их стадии; колонки `cancelled_at`/`cancel_requested_at` (ORCH-090) — durable-метки STOP-отмены (вторая — отложенная отмена в критичном окне merge/deploy). Терминальная стадия `cancelled` (сток, параллельно `done`); натуральные ключи отменённой строки тумбстонятся суффиксом `#cancelled-<id>` (`plane_id`/`work_item_id`/`plane_issue_id`)
+- `tasks` — задачи и их стадии; колонки `cancelled_at`/`cancel_requested_at` (ORCH-090) — durable-метки STOP-отмены (вторая — отложенная отмена в критичном окне merge/deploy). Терминальная стадия `cancelled` (сток, параллельно `done`); натуральные ключи отменённой строки тумбстонятся суффиксом `#cancelled-<id>` (`plane_id`/`work_item_id`/`plane_issue_id`). Колонка `paused_at` (ORCH-124, adr-0051) — durable per-task park-сигнал serial-gate (NULL = не на паузе): **ортогональная** оси «терминальность» ось «пауза» (`paused_at IS NOT NULL`), читается **только** serial-gate (`task_deps`/`stages.py` её не читают); паузнутый предшественник не держит FIFO, но не обходит `repo_freeze`/`task_deps`
 - `agent_runs` — запуски агентов (run_id, usage, cost)
-- `jobs` — очередь задач (ORCH-1); статусы `queued|running|done|failed|cancelled` (ORCH-090: `cancelled` — терминальный исход STOP, нигде не реквью'ится); колонка `pid` (ORCH-065) — pid агентского процесса для liveness-детекции зомби job-reaper'ом
+- `jobs` — очередь задач (ORCH-1); статусы `queued|running|done|failed|cancelled` (ORCH-090: `cancelled` — терминальный исход STOP, нигде не реквью'ится); колонка `pid` (ORCH-065) — pid агентского процесса для liveness-детекции зомби job-reaper'ом. **Инвариант run-ownership (ORCH-126, adr-0052): `status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`** — queued-job никогда не несёт run-ownership (она принадлежит ровно одной активной попытке `running` после стампа в `_spawn`; история — в `agent_runs`). Все пути возврата в `queued` (`requeue_running_jobs`/`mark_job('queued')`/`mark_job_transient`/`reap_running_job('queued')`) сбрасывают `run_id`/`pid`; `claim_next_job` — defense-in-depth-сброс при флипе в `running`. Stale run-ownership искажала бы Tier-1 liveness reaper'а (переиспользованный pid → фантомный `running` клинит `max_concurrency=1`-очередь всех проектов) и `/metrics` (ORCH-099). «Невозможные» строки само-лечатся при старте/реапе + счётчик в `GET /queue`. **Норматив:** новый путь возврата в `queued` обязан соблюсти инвариант (reviewer: нарушение = ≥P1)
 - `job_deps` — декларативные зависимости задач (ORCH-026, Уровень B): `(task_id, depends_on_task_id)`, аддитивная; источник истины планировщика для гейта «B ждёт A»
 - `repo_freeze` — durable per-repo rollback-freeze (ORCH-088, FR-5): `(id, repo, frozen_at, reason, work_item_id, cleared_at)`, аддитивная append-only; активный freeze ⇔ строка репо с `cleared_at IS NULL`. Выставляется post-deploy `DEGRADED` (`set_repo_freeze`), снимается вручную (`POST /serial-gate/unfreeze` → `cleared_at=now`). Гейтит serial-claim безусловно (деградировавшая задача уже `done`)
 - `lessons` — машинный журнал отклонений конвейера (ORCH-098, FR-1): `(id, created_at, updated_at, lesson_type, work_item_id, task_id, stage, agent, repo, root_cause, suggestion, status, related_task, attribution, target_repo, target_domain, source, detail)`, аддитивная идемпотентная (`CREATE TABLE IF NOT EXISTS` + три индекса); колонки атрибуции (`attribution`/`target_repo`/`target_domain`) — нуллабельны и присутствуют сразу (NFR-6), без `enum`-констрейнтов (слаги forward-compatible). Автозапись 4 типов (`gate_failure`/`merge_hold`/`transient_retry`/`deploy_degraded`, `source="auto"`, дедуп в окне `lessons_dedup_window_s`) + ручная (`source="manual"`); observer-only (не участвует в решении гейта). Leaf `src/lessons.py` never-raise, kill-switch `lessons_enabled` (без `*_repos` — журнал не скоупится по репо, репо-разрез на выборке)
@@ -1429,6 +1486,8 @@ Monitoring after Deploy → Done
 | GET | `/queue` | очередь: counts + max_concurrency + resilience + reconcile (ORCH-053) + reaper (ORCH-065) + post_deploy (ORCH-021) + task_deps (ORCH-026) + serial_gate (ORCH-088) + auto_labels (ORCH-089) + stop (ORCH-090) + lessons (ORCH-098) + transition_lease (ORCH-114) + последние jobs |
 | GET | `/metrics` | ORCH-099 (FND/F1a): read-only машинное «сырьё» для sidecar F1b — конверт `schema_version`/`generated_at`/`clk_tck` + разделы `stages`/`queue`/`agents` (liveness: pid/runtime/cpu_ticks)/`cost`. never-raise по разделам; kill-switch `ORCH_METRICS_ENABLED` (дефолт `True`). Контракт — см. раздел «Сырьё-эндпоинт `/metrics`» |
 | POST | `/serial-gate/unfreeze` | ORCH-088 (FR-5): ручное снятие per-repo rollback-freeze (query/body `repo=<repo>`) → `{ok, repo, cleared, frozen}`; идемпотентно. Альтернатива — `UPDATE repo_freeze SET cleared_at=datetime('now') WHERE repo=? AND cleared_at IS NULL` |
+| POST | `/serial-gate/pause` | ORCH-124 (D7): поставить задачу на паузу для serial-gate (query/body `work_item=<id>`) → `{ok, work_item, task_id, paused_at}`; идемпотентно. Паузнутый предшественник не держит FIFO против срочного успешника (пауза ≠ cancel, ≠ глобальный kill-switch); НЕ обходит `repo_freeze`/`task_deps` |
+| POST | `/serial-gate/resume` | ORCH-124 (D7): снять паузу (query/body `work_item=<id>`) → `{ok, work_item, task_id, paused_at: null}`; идемпотентно. Возобновлённая задача снова участвует в serial-gate; свежесть базы — существующие отложенный срез / merge-gate rebase+re-test |
 | POST | `/transition-lease/release` | ORCH-114 (FR-6, **опц.**): операторский ручной реклейм застрявшего владения переходом (query/body `work_item=<id>`) → `{ok, task_id, released}`; идемпотентно (паттерн `/serial-gate/unfreeze`). При выключенном `transition_lease_enabled` → no-op |
 | GET | `/lessons` | ORCH-098 (FR-4): read-only выборка журнала уроков; query-фильтры `type`/`status`/`repo`/`work_item`/`limit` → `{enabled, lessons:[…]}` (всегда `200`, чтение не мутирует). При `lessons_enabled=False` → `{enabled:false, lessons:[]}` |
 | POST | `/lessons` | ORCH-098 (FR-5): ручная запись урока (JSON-тело, `lesson_type` обязателен, `source="manual"` не дедупится) → `{id}`; при выключенном флаге → `{enabled:false}` |

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

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

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

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

@@ -0,0 +1,82 @@
+---
+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,6 +70,14 @@ STAGE_TRANSITIONS = {
 рёбер не меняются), а терминал STOP-отмены. Системный предикат «задача завершена» —
 `stage ∈ {done, cancelled}` (синхронно в `reconciler`/`serial_gate`/`task_deps`; adr-0026).
 
+**Ось «пауза» ⊥ оси «терминальность» (ORCH-124, adr-0051):** serial-gate вводит **отдельную** ось
+паузы `tasks.paused_at IS NOT NULL` (durable per-task park-сигнал) — **ортогональную** терминалу. Для
+serial-gate «активная задача» ⇔ `stage NOT IN ('done','cancelled') AND paused_at IS NULL` (паузнутый
+предшественник не держит FIFO). **Терминал `{done,cancelled}` НЕ расширяется паузой:** `task_deps` и
+`stages.py` колонку `paused_at` НЕ читают (паузнутая объявленная зависимость по-прежнему блокирует
+зависимый job; пауза не обходит `repo_freeze`). Пауза — признак планировщика очереди, не стадия и не
+терминальное состояние.
+
 ### 3. Quality Gates (`src/qg/checks.py`)
 
 | Check | Метод проверки |
@@ -394,8 +402,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` после старта |
-| `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent) |
+| `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 и клинит очередь |
 | `task_content` | ТЗ, которое пишется в task-файл агента |
 | `error` | последняя ошибка |
 
@@ -411,6 +419,10 @@ 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 переисполняют свои
@@ -467,6 +479,35 @@ 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/operations/FAQ_STOP.md

@@ -0,0 +1,87 @@
+# 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/overview/business.md

@@ -97,6 +97,7 @@
 Передумали — переводите задачу в статус «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` | — (гейт проверяет полноту пакета + одобрение человека) |
+| `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` | — (гейт проверяет полноту пакета + одобрение человека) |
 | `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,6 +18,15 @@
 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).
+
 ## Модель и эффорт
 
 Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие

docs/overview/tech-data-model.md

@@ -19,7 +19,8 @@ Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N─
 
 ### Work-Item / Task — задача конвейера
 Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
-багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
+багфикс), рабочая **ветка**, счётчики откатов, отметки отмены и **паузы** (`paused_at` —
+durable-сигнал «пропустить меня в serial gate», не терминальный). Натуральные ключи — ID задачи
 в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
 **артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
 deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).

docs/overview/tech-observability.md

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

docs/overview/tech-pipeline.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,46 @@
+---
+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-116/16-post-deploy-log.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,46 @@
+---
+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-124/00-business-request.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,139 @@
+---
+work_item: ORCH-126
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+track: bug
+---
+
+# 01 — BRD / Bug-report: ORCH-126 — queued-job хранит протухший run_id/pid и не клеймится даже при выключенном serial-gate
+
+Work Item: **ORCH-126** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug (укороченный маршрут, ORCH-019)**
+
+> 🐞 **Багфикс-трек, облегчённый пакет (ORCH-019).** Дефект контрол-плейна **локализован, причина
+> установлена по коду**, корректное поведение однозначно (queued-job не должен нести run-ownership).
+> Правка — точечная гигиена жизненного цикла строки `jobs` + диагностика, по существующим паттернам;
+> **ADR/макет не требуются** → стадия `architecture` пропускается, `escalate: full-cycle` НЕ ставится.
+> ⚠️ **Трассировка (CLAUDE.md §9):** правка затрагивает инварианты **ORCH-065** (Tier-1 pid-liveness
+> reaper'а), **ORCH-113** (finalizer-liveness), **ORCH-114** (`recover_on_startup`), **ORCH-099**
+> (`/metrics` читает `pid`/`run_id`) — перед изменением прочитать их `06-adr/` и не сломать.
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+### Симптом (наблюдаемое, из инцидента)
+Второй дефект контрол-плейна, найденный при попытке провести срочные задачи **ORCH-124/125** мимо
+serial-gate. Даже при `ORCH_SERIAL_GATE_ENABLED=false` queued analyst-job'ы зависают и **никогда не
+переходят в `running`**:
+- **job 2286 (ORCH-125):** `status=queued` при `run_id=759/760` **и** `pid=35/42`, тогда как
+  `started_at=NULL` — **физически невозможное состояние** (run-ownership выставлен, но запуск не
+  состоялся).
+- **job 2303 (ORCH-124):** при выключенном serial-gate **минутами** оставался `queued`; счётчики
+  очереди `queued=1, running=0` — задача не клеймится, хотя слот свободен.
+
+Вывод инцидента: это **claim/restart/zombie-state баг, независимый от семантики serial-gate**.
+
+### Причина симптома (установленный факт — по коду)
+Ни один путь возврата job'а в `queued` **не сбрасывает run-ownership** (`run_id`, `pid`). Эти колонки
+выставляются в `launcher._spawn` (`run_id` после INSERT в `agent_runs`, `pid` после `Popen`), но при
+любом откате в `queued` остаются «протухшими» от прошлой попытки. Затронуты **5 точек**:
+
+| # | Путь | Что чистит | `run_id`/`pid` |
+|---|------|-----------|----------------|
+| 1 | `db.requeue_running_jobs()` (restart-recovery, `src/db.py:1475`) | `started_at` | **НЕ чистит** |
+| 2 | `db.mark_job(status='queued')` (`src/db.py:1239`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 3 | `db.mark_job_transient()` (`src/db.py:1213`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 4 | `db.reap_running_job(status='queued')` (`src/db.py:1619`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 5 | `db.claim_next_job()` (`src/db.py:1143`) | ставит `started_at`, `attempts++` | **НЕ сбрасывает** stale `pid` |
+
+Это в точности воспроизводит наблюдаемое `queued + run_id=759/760 + pid=35/42 + started_at=NULL`
+(пути 1–4: задача требовала рестарта/ретрая/реапа).
+
+### Механизм «никогда не клеймится» (гипотеза к подтверждению в development — взаимодействие с reaper)
+`claim_next_job` сам по себе на `run_id`/`pid` **не смотрит** (SELECT гейтит лишь
+`status='queued' AND available_at<=now` + dep/serial-gate), поэтому stale-метаданные **не блокируют
+SELECT напрямую**. Старвейшн рождается из взаимодействия stale-`pid` с job-reaper'ом (ORCH-065),
+который сканирует `status='running'` и судит Tier-1 liveness по `jobs.pid` через `merge_gate.pid_alive`:
+
+1. **Окно claim→spawn.** `claim_next_job` ставит `running`+`started_at`, но `pid` остаётся **stale**;
+   реальный `pid` пишется только в `_spawn` **после `Popen`** (`launcher.py:711`). Между этими шагами
+   (или если `_spawn` упал на `ensure_worktree`/`_materialize_deferred_branch` до строки 711) reaper
+   видит `running` со **старым** `pid`.
+2. **pid переиспользован** (вероятно после рестарта контейнера) → `pid_alive(stale)=True` → reaper
+   «видит живой процесс» и **никогда не реапит** действительно застрявшую строку; при
+   `max_concurrency=1` (дефолт) этот фантомный `running` блокирует клейм **всей** очереди.
+3. **pid мёртв** → reaper копит dead-тики (`reaper_dead_ticks=2`) против **чужого** pid и может
+   отбросить легитимно-стартующий job обратно в `queued`/`failed` — «выглядит частично стартовавшим,
+   но фактически не запускается».
+
+Таким образом stale run-ownership **искажает сигналы liveness/диагностики** (reaper + `/metrics`
+`get_running_agents`), делая клейм/рестарт ненадёжным. Точный путь старвейшна подтверждается
+добавляемой авто-санацией/диагностикой (см. 04-test-plan).
+
+## 2. Объём (scope)
+
+### В объёме
+- Аудит и фикс гигиены строки `jobs` вокруг возврата в `queued`: `claim_next_job`,
+  `requeue_running_jobs`, `mark_job`, `mark_job_transient`, `reap_running_job`, окно `_spawn`.
+- Гарантия: queued-job либо чисто клеймится, либо детерминированно сбрасывается/реквью́ится при
+  рестарте — **без** удержания stale run-ownership.
+- Авто-санация **или** явная диагностика «невозможного» queued-состояния (`run_id`/`pid` есть, а
+  `started_at` нет).
+- Тесты на restart/requeue и stale queued-run-метаданные.
+
+### Вне объёма
+- Семантика serial-gate (ORCH-088/124), dep-gate (ORCH-026) — НЕ трогаем (баг от них независим).
+- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключей / **схемы БД**
+  (новых колонок не вводим — фикс на существующих).
+- Переписывание reaper'а (ORCH-065/113) и transition-lease (ORCH-114) — лишь не сломать их инварианты.
+
+## 3. Заинтересованные стороны
+- **Оператор** (заказчик фикса) — нуждается в надёжном bypass'е: при выключенном serial-gate срочная
+  задача обязана стартовать.
+- **Self-hosting orchestrator** + все проекты на общем инстансе/очереди — фантомный `running` при
+  `max_concurrency=1` клинит очередь **всех** проектов.
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — При выключенном serial-gate (`ORCH_SERIAL_GATE_ENABLED=false`) валидный queued ORCH-job
+  клеймится и переходит в `running` штатно (без зависания).
+- **BR-2** — Job, возвращённый в `queued` (рестарт / ретрай / transient / reap), **не несёт** stale
+  run-ownership: после возврата `run_id IS NULL` и `pid IS NULL`.
+- **BR-3** — Свежеклеймленный, ещё не заспавненный job **не несёт** stale `pid` (reaper не судит
+  liveness по чужому процессу).
+- **BR-4** — «Невозможные» queued-состояния (`run_id`/`pid` при отсутствии `started_at`)
+  авто-санируются **или** явно сигнализируются (лог + наблюдаемость в `GET /queue`).
+- **BR-5** — Регресс-тест: до фикса воспроизводит stale-состояние/старвейшн (красный), после — зелёный.
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1 (never-raise / never-wedge):** правки в горячем пути клейма не должны ронять или
+  заклинивать очередь всех проектов; ошибка диагностики — изолирована и не влияет на клейм.
+- **NFR-2 (offline hot-path):** `claim_next_job` остаётся offline (только локальная БД), без сети.
+- **NFR-3 (совместимость):** схема БД не меняется; поведение для не-stale job'ов байт-в-байт;
+  enduro-trails не затронут.
+- **NFR-4 (self-hosting safety):** правка не рестартит/не роняет прод-контейнер, не трогает `main`,
+  без новых процессов; миграция БД не требуется (правки на существующих колонках).
+- **NFR-5 (restart-safe / идемпотентность):** санация выдерживает повторный рестарт и гонку
+  worker↔reaper↔monitor (атомарные guard'ы по `status` сохранены).
+
+## 6. Допущения и ограничения
+- Дефолт `max_concurrency=1` (`config.py:114`) — единственный stuck-`running` клинит очередь;
+  поэтому корректность liveness reaper'а критична.
+- `run_id` для queued-job — мёртвая ссылка на прошлую попытку (текущего run'а нет), её сброс безопасен;
+  история живёт в таблице `agent_runs`, не в `jobs.run_id`.
+- Env читается на старте процесса: на self-hosting выключение флага требует управляемого рестарта
+  (вне объёма этого фикса; здесь — гарантия корректного клейма после рестарта).
+
+## 7. Критерии успеха
+Queued ORCH-job при выключенном serial-gate стартует штатно; queued-job'ы никогда не удерживают stale
+run-ownership после рестарта/ретрая; невозможные queued-состояния авто-санируются или явно видны;
+регресс-тесты покрывают restart/requeue и stale queued-run-метаданные. Полный `pytest tests/ -q`
+зелёный. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
+
+## 8. Риски
+- Сброс `run_id`/`pid` в неверной точке мог бы стереть идентичность активного run'а → строго на
+  переходе **в `queued`** и/или в claim **до** `_spawn` (детали — TRZ FR-1..FR-3, решает developer).
+- Взаимодействие с reaper Tier-1/Tier-3 и transition-lease — см. трассировку выше; детальный
+  риск-разбор — `10-tech-risks.md` (на укороченном маршруте не обязателен).

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

@@ -0,0 +1,97 @@
+---
+work_item: ORCH-126
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+track: bug
+---
+
+# 02 — ТЗ (TRZ): ORCH-126 — гигиена run-ownership queued-job + диагностика невозможных состояний
+
+Work Item: **ORCH-126** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug**
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> «Как именно» (точка сброса, форма диагностики) — в пределах FR; финальный выбор — за developer.
+> Архитектурного решения/ADR не требуется (укороченный маршрут ORCH-019).
+
+## 1. Сводка изменения
+Сбрасывать run-ownership строки `jobs` (`run_id`, `pid`) **во всех путях возврата job'а в `queued`**
+и/или в момент claim **до** `_spawn`, чтобы (а) queued-job никогда не нёс протухший `run_id`/`pid`,
+(б) свежеклеймленный-ещё-не-заспавненный job не нёс stale `pid`, который job-reaper примет за чужой
+живой/мёртвый процесс. Плюс — детектор «невозможного» queued-состояния: авто-санация при старте/реапе
+**и** наблюдаемость (лог + счётчик в `GET /queue`). Схема БД и контракты гейтов не меняются.
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/db.py` | изменить: `requeue_running_jobs` / `mark_job('queued')` / `mark_job_transient` / `reap_running_job('queued')` — добавить сброс `run_id=NULL, pid=NULL`; `claim_next_job` — сброс stale `pid` (и `run_id`) при флипе в `running` |
+| `src/agents/launcher.py` | проверить окно `_spawn` (claim→`run_id`/`started_at`→`Popen`→`pid`): убедиться, что при провале `_spawn` до строки 711 job не остаётся со stale `pid` (опирается на сброс в `claim`/`mark_job`) |
+| `src/job_reaper.py` | (опц., по выбору developer) Tier-1 анти-false-positive: `pid IS NULL` у свежего `running` уже трактуется как «нет pid → не реапить»; добавить авто-санацию/счётчик невозможных queued-строк, если фикс на стороне reaper |
+| `src/main.py` | (опц.) при старте после `requeue_running_jobs` — лог/санация обнаруженных невозможных queued-состояний (наблюдаемость BR-4) |
+| `tests/test_orch126_queued_stale_run.py` | создать: регресс + покрытие FR-1..FR-4 |
+
+## 3. Функциональные требования
+
+### FR-1 — Сброс run-ownership на всех путях возврата в `queued` (BR-2)
+Каждый путь, переводящий job в `queued`, обязан выставить `run_id=NULL` **и** `pid=NULL` той же
+UPDATE-транзакцией, что уже чистит `started_at`/`finished_at`:
+`db.requeue_running_jobs()` (restart-recovery), `db.mark_job(status='queued')`,
+`db.mark_job_transient()`, `db.reap_running_job(status='queued')`.
+Инвариант: **`status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`**.
+Атомарные guard'ы по `status` (`reap_running_job ... WHERE status='running'`) — сохранить байт-в-байт.
+
+### FR-2 — Чистый claim (BR-1, BR-3)
+`db.claim_next_job` при флипе `queued→running` не должен оставлять stale `pid` (и `run_id`) от прошлой
+попытки: либо сбросить их в том же UPDATE (`pid=NULL, run_id=NULL`), либо опираться на FR-1 (тогда
+queued-job их уже не несёт). Defense-in-depth (оба) — предпочтительно. SELECT-гейт
+(`status='queued' AND available_at<=now` + dep/serial-gate) — **не трогать** (NFR-2 offline).
+Результат: между claim и стампом `pid` в `_spawn` job имеет `pid IS NULL` (не чужой pid).
+
+### FR-3 — Безопасность окна `_spawn` (BR-3)
+Если `_spawn` падает **до** стампа `pid` (`launcher.py:711`) — `ensure_worktree`/
+`_materialize_deferred_branch`/`_write_task_file`, — обработчик `queue_worker._drain_once`
+(`mark_job('queued'|'failed')`) обязан, по FR-1, оставить job без stale `pid`. Проверить, что
+повторный claim после такого провала стартует штатно (а не оседает «частично стартовавшим»).
+
+### FR-4 — Детект и обработка невозможного состояния (BR-4)
+«Невозможное» queued-состояние = `status='queued' AND (run_id IS NOT NULL OR pid IS NOT NULL OR
+started_at IS NOT NULL)`. Поведение:
+- **Авто-санация** при старте (`main.lifespan` после `requeue_running_jobs`) и/или при реап-тике —
+  привести такие строки к чистому `queued` (FR-1) идемпотентно, never-raise.
+- **Наблюдаемость** — структурный WARNING с `job_id`/`run_id`/`pid` + read-only счётчик в блоке
+  очереди `GET /queue` (например `queue.impossible_queued` или поле в существующем снимке worker'а).
+
+### FR-5 — Корректность reaper-liveness (BR-1, NFR-5)
+После FR-1..FR-3 job-reaper (ORCH-065) на свежеклеймленном `running` видит `pid IS NULL` → Tier-1
+не копит dead-тики против чужого pid и не реапит легитимный старт; фантомный «живой» pid не блокирует
+очередь. Инварианты ORCH-065/113/114 (Tier-2 finalize-grace, finalizer-liveness, transition-lease) —
+не нарушать.
+
+## 4. Изменения API
+Нет новых эндпоинтов. **Расширение наблюдаемости** read-only снимка `GET /queue` — добавить
+счётчик/индикатор обнаруженных и санированных невозможных queued-состояний (BR-4); существующие поля
+снимка не переименовывать.
+
+## 5. Изменения схемы БД
+**Нет.** Колонки `jobs.run_id` / `jobs.pid` / `jobs.started_at` уже существуют; фикс — корректное
+заполнение/сброс. Никаких `_ensure_column`/новых таблиц/индексов.
+
+## 6. Требования к новым/изменённым QG checks
+**Нет.** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / `check_*` / machine-verdict-ключи — байт-в-байт.
+Дефект — свойство гигиены данных планировщика, не Quality Gate.
+
+## 7. Совместимость / регресс
+- **Обратная совместимость:** для не-stale job'ов поведение байт-в-байт (они и так не несут
+  `run_id`/`pid` в `queued`); фикс лишь нормализует аномальные строки.
+- **Область:** общий планировщик/очередь (не self-hosting-scoped leaf) — затрагивает все проекты, но
+  семантически нейтрально (приведение к уже-документированному инварианту «queued = без run-ownership»).
+- **Kill-switch:** правка — исправление инварианта данных, не новая фича; отдельный флаг не требуется.
+  Опциональную авто-санацию/диагностику (FR-4) допустимо закрыть под флаг, если developer сочтёт
+  нужным (дефолт = включено), но базовый сброс FR-1..FR-3 — безусловен.
+- **Обратимость:** изменения локальны (UPDATE-наборы в `db.py`); откат — ревертом PR.
+- **Миграция:** не требуется; существующие аномальные строки санируются при первом старте (FR-4).
+- **Трассировка (CLAUDE.md §9):** перед правкой `pid`/`run_id`-логики прочитать ADR ORCH-065
+  (reaper Tier-1), ORCH-113 (finalizer-liveness), ORCH-114 (transition-lease/`recover_on_startup`),
+  ORCH-099 (`/metrics`); не сломать их инварианты.

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

@@ -0,0 +1,107 @@
+---
+work_item: ORCH-126
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+track: bug
+---
+
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-126 — гигиена run-ownership queued-job
+
+Work Item: **ORCH-126** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug**
+
+Формат: каждый критерий имеет **PASS** / **FAIL**. Reviewer проверяет буквально по файлам репозитория
+и прогону тестов.
+
+---
+
+## AC-1 — Инвариант чистого queued после возврата
+
+**Условие:** job возвращён в `queued` любым путём — `requeue_running_jobs` (restart),
+`mark_job('queued')` (retry), `mark_job_transient` (transient), `reap_running_job('queued')` (reaper).
+- **PASS:** после операции строка имеет `run_id IS NULL` **И** `pid IS NULL` **И** `started_at IS NULL`.
+- **FAIL:** хотя бы один из `run_id`/`pid`/`started_at` остаётся непустым у `status='queued'`.
+
+---
+
+## AC-2 — Клейм при выключенном serial-gate стартует штатно
+
+**Условие:** `ORCH_SERIAL_GATE_ENABLED=false`, есть один валидный queued ORCH-job, `running=0`,
+`max_concurrency≥1`.
+- **PASS:** `claim_next_job` выбирает job, флипает в `running`, `_spawn` стартует; задача не зависает.
+- **FAIL:** job остаётся `queued` при свободном слоте (повтор `queued=1, running=0`).
+
+---
+
+## AC-3 — Свежеклеймленный job не несёт чужой pid
+
+**Условие:** job клеймится из `queued`, который ранее нёс stale `pid`/`run_id`; до выполнения стампа
+`pid` в `_spawn`.
+- **PASS:** сразу после `claim_next_job` (до `_spawn` Popen-стампа) `jobs.pid IS NULL` (не stale).
+- **FAIL:** после claim строка несёт `pid` от прошлой попытки.
+
+---
+
+## AC-4 — Reaper не реапит легитимный старт по чужому pid
+
+**Условие:** job только что склеймлен (`running`, `started_at=now`, `pid IS NULL`), job-reaper
+делает тик.
+- **PASS:** reaper не считает строку мёртвой (Tier-1 пропускает `pid IS NULL`); не возвращает её в
+  `queued`/`failed`; легитимный старт не сбивается. Фантомный «живой» stale-pid больше не блокирует
+  клейм очереди.
+- **FAIL:** reaper реапит стартующий job по чужому pid, либо вечно держит фантомный `running`.
+
+---
+
+## AC-5 — Невозможное queued-состояние авто-санируется / явно видно
+
+**Условие:** в БД присутствует строка `status='queued'` с непустым `run_id`/`pid`/`started_at`
+(например после апгрейда на проблемной БД или гонки).
+- **PASS:** состояние приводится к чистому `queued` (авто-санация при старте/реапе, идемпотентно,
+  never-raise) **и/или** явно сигнализируется (структурный WARNING с `job_id`/`run_id`/`pid` +
+  счётчик в `GET /queue`).
+- **FAIL:** аномальная строка остаётся незамеченной и неисправленной.
+
+---
+
+## AC-6 — Окно `_spawn` устойчиво к провалу до стампа pid
+
+**Условие:** `_spawn` падает до стампа `pid` (`ensure_worktree`/материализация ветки/запись task-файла);
+job уходит назад в `queued` обработчиком `_drain_once`.
+- **PASS:** строка в `queued` чистая (AC-1); повторный claim стартует штатно; нет «частично
+  стартовавшего» зависания.
+- **FAIL:** после провала job несёт stale `pid`/`run_id` или не клеймится повторно.
+
+---
+
+## AC-7 — Без регрессов контрактов и схемы
+
+**Условие:** прогон полного `pytest tests/ -q`; проверка диффа.
+- **PASS:** все тесты зелёные; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / `check_*` /
+  machine-verdict-ключи / схема БД (`jobs`) — без изменений; новых колонок/таблиц нет;
+  поведение для не-stale job'ов неизменно; enduro не затронут.
+- **FAIL:** падение тестов, изменён контракт гейта/схема БД, или регресс для здоровых job'ов.
+
+---
+
+## AC-8 — Обязательный регресс-тест красный→зелёный
+
+**Условие:** тест из `04-test-plan.yaml`, фиксирующий stale-состояние и/или старвейшн.
+- **PASS:** тест красный на коде ДО фикса, зелёный ПОСЛЕ.
+- **FAIL:** тест зелёный до фикса (не воспроизводит баг) или красный после.
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-2 / FR-1 |
+| AC-2 | BR-1 / FR-2 |
+| AC-3 | BR-3 / FR-2 |
+| AC-4 | BR-1, BR-3 / FR-5 |
+| AC-5 | BR-4 / FR-4 |
+| AC-6 | BR-3 / FR-3 |
+| AC-7 | NFR-1..NFR-4 |
+| AC-8 | BR-5 / FR-1..FR-4 |

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

@@ -0,0 +1,102 @@
+work_item: ORCH-126
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+title: "ORCH-126 — гигиена run-ownership queued-job + диагностика невозможных состояний"
+framework: pytest
+track: bug
+scope: >
+  Покрывает: сброс run_id/pid на всех путях возврата job в queued (restart/retry/transient/reap),
+  чистый claim без stale pid, устойчивость окна _spawn, детект/санацию невозможных queued-состояний,
+  корректность Tier-1 reaper-liveness. Вне покрытия: семантика serial-gate (ORCH-088/124) и dep-gate
+  (ORCH-026), переписывание reaper/transition-lease, изменение схемы БД.
+notes: >
+  TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест бага: красный на коде ДО фикса, зелёный ПОСЛЕ (BR-5 / AC-8).
+  Тесты используют изолированную временную SQLite-БД (db.init_db во временной директории), без сети,
+  без Claude CLI, без реального Popen (spawn мокается/подменяется). Полный регресс pytest tests/ -q
+  должен оставаться зелёным (AC-7).
+
+tests:
+  - id: TC-01
+    type: integration
+    description: >
+      РЕГРЕСС (red→green): job в running со stale run_id+pid (started_at set) проходит
+      requeue_running_jobs() (имитация рестарта); ассерт — строка queued с run_id IS NULL,
+      pid IS NULL, started_at IS NULL. До фикса pid/run_id остаются (красный), после — чисто.
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      mark_job(job_id, 'queued') сбрасывает run_id и pid (а не только started_at/finished_at).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      mark_job_transient(...) на job со stale run_id/pid возвращает чистый queued (run_id/pid NULL),
+      сохраняя инкремент transient_attempts и backoff available_at.
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      reap_running_job(job_id, 'queued', ...) сбрасывает run_id/pid; атомарный guard
+      WHERE status='running' сохранён (повторный вызов на уже-queued строке -> rowcount 0).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-05
+    type: integration
+    description: >
+      claim_next_job() флипает queued->running и не оставляет stale pid: сразу после claim
+      jobs.pid IS NULL (до _spawn-стампа). Подтверждает чистый старт (AC-3).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-06
+    type: integration
+    description: >
+      При выключенном serial-gate (ORCH_SERIAL_GATE_ENABLED=false) валидный queued ORCH-job
+      выбирается claim_next_job при running=0 и не зависает (AC-2).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: >
+      Reaper-тик на свежеклеймленном running с pid IS NULL не реапит строку (Tier-1 пропускает
+      pid IS NULL), легитимный старт сохраняется (AC-4).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: >
+      Детект/санация невозможного состояния: предзаписанная строка queued с непустым pid/run_id/
+      started_at приводится к чистому queued (авто-санация при старте/реапе) И/ИЛИ фиксируется
+      счётчиком в снимке очереди; операция идемпотентна и never-raise (AC-5).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: >
+      Окно _spawn: при провале launch (launch_job/_spawn бросает до стампа pid) обработчик
+      _drain_once возвращает job в queued чистым (pid/run_id NULL); повторный claim стартует
+      штатно (AC-6).
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: >
+      Анти-регресс: для здорового job (никогда не стартовал) поведение mark_job/claim байт-в-байт;
+      терминальные исходы (done/failed/cancelled) и стамп finished_at не затронуты сбросом ownership.
+    module: tests/test_orch126_queued_stale_run.py
+    expected: PASS

docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md

@@ -0,0 +1,164 @@
+---
+work_item: ORCH-126
+stage: architecture
+author_agent: architect
+status: accepted
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+track: bug
+---
+
+# ADR-001: Гигиена run-ownership строки `jobs` — инвариант «queued ⇒ нет run-ownership»
+
+Work Item: **ORCH-126** — queued-job хранит протухший `run_id`/`pid` и не клеймится даже при выключенном serial-gate
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-0052-queued-job-run-ownership-invariant.md`** (решение кросс-каттинговое — инвариант данных, на который опираются reaper / `/metrics` / scheduler).
+
+> 🐞 **Контекст маршрута.** Задача классифицирована как **Bug** (трек ORCH-019); аналитик отметил, что
+> ADR/макет «не требуются». Однако задача дошла до стадии `architecture` (bug-fast-track не сработал —
+> метка `Bug` не была проставлена в Plane на момент `start_pipeline`, либо флаг выключен), а
+> детерминированный exit-гейт `check_architecture_done` требует артефакт `06-adr/` **или**
+> `07-infra-requirements.md`. Поэтому фиксирую **минимальный, но настоящий** архитектурный артефакт:
+> правка трогает **4 маркированных инварианта** (ORCH-065 / ORCH-113 / ORCH-114 / ORCH-099), и их
+> валидация (CLAUDE.md §9) — это именно архитектурная работа. **Не** `arch:major-change` (нет новой
+> стадии / компонента / QG / смены БД).
+
+## Статус
+Accepted
+
+## Контекст
+
+Корневая проблема — **отсутствие принудительного инварианта**, связывающего `jobs.status` с
+колонками run-ownership `jobs.run_id` / `jobs.pid` / `jobs.started_at`. Run-ownership выставляется
+**вперёд** в `launcher._spawn` (`run_id` после INSERT в `agent_runs`, `pid` после `Popen`,
+`launcher.py:711`), но **ни один** из путей возврата job'а в `queued` его не сбрасывает. Сверено по коду:
+
+| # | Путь (`src/db.py`) | Что чистит | `run_id`/`pid` |
+|---|--------------------|-----------|----------------|
+| 1 | `requeue_running_jobs()` (`:1483`, restart-recovery) | `started_at` | **НЕ чистит** |
+| 2 | `mark_job(status='queued')` (`:1264`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 3 | `mark_job_transient()` (`:1226`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 4 | `reap_running_job(status='queued')` (`:1648`) | `started_at`/`finished_at` | **НЕ чистит** |
+| 5 | `claim_next_job()` (`:1196`, флип `queued→running`) | ставит `started_at`, `attempts++` | **НЕ сбрасывает** stale `pid` |
+
+Итог — `queued`-строка может нести «протухшую» run-ownership: физически невозможное состояние
+(run-ownership выставлен, но запуск не состоялся: `run_id`/`pid` ≠ NULL при `started_at IS NULL` —
+ровно наблюдаемое в инциденте: job 2286 `queued + run_id=759/760 + pid=35/42`).
+
+Колонки `run_id`/`pid` — **общий контракт liveness**, который читают два подсистемы:
+- **job-reaper (ORCH-065):** Tier-1 судит liveness по `jobs.pid` через `merge_gate.pid_alive`
+  (`job_reaper.py:245`). Stale-**но-переиспользованный** pid → `pid_alive(stale)=True` → reaper
+  «видит живой процесс» → **никогда не реапит** фантомный `running`; при `max_concurrency=1` (дефолт)
+  это клинит клейм **всей** очереди (общий инстанс/очередь всех проектов).
+- **`/metrics` (ORCH-099):** `get_running_agents` отдаёт `run_id`/`pid` running-job'ов.
+
+«Как есть» не годится: без сброса run-ownership на возврате в `queued` сигналы liveness/диагностики
+искажены, и при выключенном serial-gate срочная задача всё равно не стартует.
+
+## Решение
+
+### Сводка
+Ввести и **повсеместно соблюсти** инвариант жизненного цикла строки `jobs`:
+
+> **`status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`.**
+
+Сбрасывать run-ownership (`run_id=NULL, pid=NULL`) той же UPDATE-транзакцией, что уже чистит
+`started_at`, на **всех** путях возврата в `queued`; в `claim` — defense-in-depth-сброс stale `pid`/
+`run_id` при флипе в `running` (до стампа в `_spawn`). Плюс — детект/санация «невозможного» состояния
+(старт + реап-тик) и наблюдаемость. **Схема БД, `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`,
+machine-verdict-ключи — байт-в-байт.** Это исправление инварианта данных планировщика, **не** новая
+фича и **не** Quality Gate.
+
+### 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` в тот же `SET`, что чистит `started_at`/`finished_at`. Атомарные
+guard'ы по `status` (`reap_running_job ... WHERE status='running'`, rowcount-проверка) — **сохранить
+байт-в-байт** (restart-safe, гонка worker↔reaper↔monitor). Точка сброса — **строго на переходе В
+`queued`**: сброс run-ownership активного `running`-job стёр бы идентичность живого run'а (ключевое
+ограничение корректности — см. TR-1).
+
+### 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). Сброс — часть уже существующего `UPDATE … SET status='running', …` (без
+нового SELECT/сети).
+
+### D3 — Окно `_spawn` (FR-3 / AC-6)
+При провале `_spawn` **до** стампа `pid` (`ensure_worktree` / `_materialize_deferred_branch` /
+`_write_task_file`) обработчик `queue_worker._drain_once` возвращает job через `mark_job('queued'|
+'failed')` → по D1 строка остаётся без stale `pid`/`run_id`. Новый код в launcher не нужен —
+устойчивость обеспечивается D1; в development подтвердить, что повторный claim после такого провала
+стартует штатно.
+
+### D4 — Детект и санация «невозможного» состояния (FR-4 / AC-5)
+«Невозможное» = `status='queued' AND (run_id IS NOT NULL OR pid IS NOT NULL OR started_at IS NOT NULL)`.
+- **Авто-санация** при старте (`main.lifespan`, после `requeue_running_jobs`) и/или на реап-тике —
+  идемпотентное приведение к чистому `queued` (по D1), never-raise. Закрывает уже-существующие
+  аномальные строки на проблемной БД без миграции.
+- **Наблюдаемость** — структурный WARNING (`job_id`/`run_id`/`pid`) + read-only счётчик в блоке
+  очереди `GET /queue` (поле/`queue.impossible_queued`); существующие поля снимка не переименовывать.
+
+### 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
+(`:257-258` «Alive / no pid → reset»); Tier-3 backstop (`reaper_max_running_s`) — без изменений
+ловит реально застрявший claim→spawn в ограниченное время. **Правка reaper'а не требуется** — фикс
+**восстанавливает предусловие**, на котором reaper уже спроектирован («`pid` отражает процесс ЭТОГО
+run'а»).
+
+### D6 — Без kill-switch для базового сброса (D1–D3); опц. флаг для D4
+Базовый сброс run-ownership (D1–D3) — **безусловен** (исправление инварианта данных, для здоровых
+job'ов байт-в-байт). Опциональную авто-санацию/диагностику D4 допустимо закрыть флагом (дефолт =
+включено) на усмотрение developer. Отдельный фичефлаг для D1–D3 не вводится (NFR-3).
+
+## Альтернативы
+
+- **DB-level enforcement (CHECK-констрейнт / триггер `status='queued' ⇒ run_id/pid IS NULL`)** —
+  отвергнуто: правка **схемы БД** (вне объёма, NFR-3); раняющий констрейнт нарушает never-raise и мог
+  бы заклинить очередь всех проектов; самолечение на старте (D4) безопаснее жёсткого констрейнта.
+- **Только reaper-side эвристика (игнорировать `pid`, если `started_at` подозрителен)** — отвергнуто:
+  не лечит корень — другие читатели (`/metrics`) по-прежнему видят stale-данные; reaper уже корректно
+  обрабатывает `pid IS NULL` — правильнее **гарантировать** NULL, а не плодить эвристики в reaper'е.
+- **Новая колонка (`run_epoch`/`claim_token`)** — отвергнуто: смена схемы (вне объёма), избыточно —
+  инвариант выразим на существующих колонках.
+- **Сброс run-ownership где угодно (в т.ч. у активного `running`)** — отвергнуто: стёр бы идентичность
+  живого run'а; сброс строго на переходе В `queued` и в claim ДО `_spawn`.
+
+## Последствия
+
+- **+** Закрыт класс «фантомный `running` клинит `max_concurrency=1` очередь всех проектов»;
+  восстановлена корректность Tier-1 liveness reaper'а; чище `/metrics`.
+- **+** Инвариант «queued = без run-ownership» **назван и зафиксирован** (этот ADR + сквозной
+  adr-0052) → защита от рецидива (новый 6-й путь возврата в `queued` обязан его соблюсти; D4
+  само-лечит пропуск).
+- **+** Для не-stale job'ов поведение байт-в-байт (NFR-3); enduro-trails не затронут;
+  миграция БД не требуется.
+- **−** 4–5 точек правки → риск забыть будущий путь возврата (митигейшн: D4 startup/reap self-heal +
+  счётчик в `/queue` + named-инвариант) — **TR-2**.
+- **−** Точка сброса критична: ошибочный сброс у активного `running` стёр бы идентичность live-run'а
+  (митигейшн: строго на переходе В `queued` / в claim ДО `_spawn`) — **TR-1**.
+- **Откат:** изменения локальны (наборы `SET` в `src/db.py` + опц. startup-хук) → ревертом PR;
+  опц. D4 — выключением его флага.
+
+### Трассировка маркированных инвариантов (CLAUDE.md §9) — все сохранены
+- **ORCH-065 (reaper Tier-1):** сохранён и **восстановлен** (`job_reaper.py:245/257`); Tier-3 backstop
+  без изменений.
+- **ORCH-113 (finalizer-liveness):** ортогонален — process-local маркер по `job_id`, только для
+  `running`+exit_code на ребре `deploy-staging`; у queued-job финализатора нет.
+- **ORCH-114 (transition-lease / `recover_on_startup`):** ортогонален — своя таблица
+  `transition_lease`, свои `owner_pid`/`owner_boot_id`; recovery по boot-id, не по `jobs.pid`/`run_id`.
+- **ORCH-099 (`/metrics`):** улучшен — `get_running_agents` фильтрует `status='running'` и уже
+  допускает `pid IS NULL`; фикс убирает утечку stale-pid, контракт держится.
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-126/01-brd.md`
+- TRZ: `docs/work-items/ORCH-126/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-126/03-acceptance-criteria.md`
+- Test-plan: `docs/work-items/ORCH-126/04-test-plan.yaml`
+- Технические риски: `docs/work-items/ORCH-126/10-tech-risks.md`
+- Сквозной ADR: `docs/architecture/adr/adr-0052-queued-job-run-ownership-invariant.md`
+- Сверено по коду: `src/db.py` (`claim_next_job`/`requeue_running_jobs`/`mark_job`/`mark_job_transient`/`reap_running_job`/`get_running_agents`), `src/job_reaper.py` (`:245`/`:257`), `src/agents/launcher.py` (`_spawn` `:711`), `src/transition_lease.py`
+- Маркированные инварианты: `docs/work-items/ORCH-065/06-adr/`, `ORCH-113/06-adr/`, `ORCH-114/06-adr/`, `ORCH-099/06-adr/`
+</content>
+</invoke>

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

@@ -0,0 +1,41 @@
+---
+work_item: ORCH-126
+stage: architecture
+author_agent: architect
+status: accepted
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+track: bug
+---
+
+# 10 — Технические риски: ORCH-126 — гигиена run-ownership queued-job
+
+Work Item: **ORCH-126** · Repo: **orchestrator** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Риски реализации сброса `run_id`/`pid` на путях возврата в
+> `queued` и их митигейшн. На bug-маршруте необязателен, но включён: правка — горячий путь клейма,
+> затрагивает 4 маркированных инварианта (ORCH-065/113/114/099) на **общей** очереди всех проектов.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | **Сброс run-ownership не в той точке** — обнуление `run_id`/`pid` у **активного** `running`-job стёрло бы идентичность живого run'а (reaper/`/metrics` потеряли бы pid живого процесса; зомби-детекция сломалась бы). | Низ. | Выс. | Сброс **строго на переходе В `queued`** (D1) и в `claim` **до** `_spawn` (D2). Активный `running` не трогается. TC-10 (анти-регресс здорового job'а) + TC-04 (атомарный `WHERE status='running'`-guard сохранён). |
+| TR-2 | **Забытый будущий путь возврата в `queued`** (6-й путь мимо инварианта) воскрешает класс «stale run-ownership». | Сред. | Сред. | Named-инвариант (adr-0052) + D4 startup/reap self-heal (идемпотентно лечит пропуск) + счётчик `impossible_queued` в `GET /queue` + reviewer-норматив «нарушение = ≥P1». |
+| TR-3 | **Регресс reaper Tier-1** — неверная трактовка `pid IS NULL` как «dead → reap» реапнула бы легитимный старт. | Низ. | Выс. | Правка reaper НЕ требуется: `job_reaper.py:245` реапит лишь `pid is not None and not pid_alive(pid)`, `:257` сбрасывает streak при «no pid». Фикс **восстанавливает** предусловие. Покрыто TC-07. |
+| TR-4 | **Гонка worker↔reaper↔monitor** на возврате в `queued` (двойная обработка строки). | Низ. | Сред. | Атомарные `status`-guard'ы (`reap_running_job ... WHERE status='running'`, rowcount) сохранены байт-в-байт (FR-1). Restart-safe (TC-04 повторный вызов → rowcount 0). |
+| TR-5 | **Окно claim→spawn без pid** — job, чей `_spawn` упал до стампа pid и не был реквью́ен, висит `running` с `pid IS NULL` до Tier-3 backstop. | Низ. | Низ. | Штатный путь — немедленный реквью через `_drain_once`+D1 (TC-09). Worst-case ловит Tier-3 `reaper_max_running_s` (без изменений). Поведение не хуже текущего. |
+| TR-6 | **Ошибка в горячем пути клейма роняет/клинит очередь всех проектов** (NFR-1). | Низ. | Выс. | Сброс — часть существующего `UPDATE` (без нового SELECT/сети, offline NFR-2); D4-диагностика изолирована (never-raise) от клейма. Полный `pytest tests/ -q` зелёный (AC-7). |
+| TR-7 | **Невозможные строки на проде на момент апгрейда** (job 2286/2303) не санируются. | Низ. | Сред. | D4 авто-санация при первом старте `main.lifespan` (миграция не требуется); идемпотентно, выдерживает повторный рестарт (NFR-5). Покрыто TC-08. |
+
+## Сводный вывод
+
+Доминирующий класс — **точечная гигиена данных в горячем пути** при сохранении атомарных guard'ов и
+4 маркированных инвариантов. Все риски — низкой вероятности; высокое влияние (TR-1/TR-3/TR-6) полностью
+снимается тем, что (а) сброс ограничен переходом В `queued`/claim-до-`_spawn`, (б) reaper не правится и
+его предусловие лишь восстанавливается, (в) изменения — внутри существующих UPDATE без сети.
+**Эскалация не требуется** (`arch:major-change` — нет; возврат в анализ — нет): схема БД / `STAGE_TRANSITIONS`
+/ `QG_CHECKS` / `check_*` / machine-verdict — байт-в-байт, решение реализуемо без нарушения принципов.
+Остаточный риск для прод-конвейера (self-hosting) — **низкий**; обязательный регресс-тест (TC-01,
+red→green) + анти-регресс здорового job'а (TC-10) фиксируют корректность.
+</content>

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

@@ -0,0 +1,118 @@
+---
+verdict: APPROVED
+work_item: ORCH-126
+stage: review
+author_agent: reviewer
+status: approved
+created_at: 2026-06-17
+model_used: claude-opus-4-8
+type: review
+work_item_id: ORCH-126
+version: 1
+---
+
+# Review ORCH-126 — гигиена run-ownership строки `jobs` (инвариант «queued ⇒ run_id/pid/started_at IS NULL»)
+
+## Summary
+
+Точечный, корректно-локализованный багфикс контрол-плейна (трек **Bug**, инцидент ORCH-124/125,
+job 2286). Реализация **полностью соответствует ТЗ/AC и ADR-001 + сквозному adr-0052**, не меняет
+схему БД, `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*` и machine-verdict-ключи (AC-7), несёт
+обязательный регресс-тест красный→зелёный (AC-8/TC-01) и обновляет документацию в том же PR. Все
+4 маркированных инварианта (ORCH-065/113/114/099) сохранены и трассированы. **P0/P1 findings нет.**
+
+Проверка выполнена по коммиту `d7e7a4d` (фактический объём ORCH-126); широкий `main...HEAD` раздут
+устаревшим локальным `main` и к ревью не относится.
+
+### Соответствие ТЗ / AC (ось 1) — выполнено
+- **FR-1 / AC-1:** сброс `run_id=NULL, pid=NULL` той же UPDATE-транзакцией во всех 4 путях возврата
+  в `queued` — `requeue_running_jobs` (`db.py:1506`), `mark_job('queued')` (`:1264`),
+  `mark_job_transient` (`:1226`), `reap_running_job('queued')` (`:1668`). Атомарные `status`-guard'ы
+  (`WHERE status='running'`, rowcount) сохранены байт-в-байт (TC-04 проверяет «второй reap проигрывает»).
+- **FR-2 / AC-3:** `claim_next_job` сбрасывает `pid=NULL, run_id=NULL` внутри существующего одного
+  UPDATE флипа `queued→running`; SELECT-гейт не тронут (offline hot-path, NFR-2). Возврат — re-SELECT
+  после UPDATE → отдаваемый dict корректно несёт `pid IS NULL` (TC-05).
+- **FR-3 / AC-6:** окно `_spawn` устойчиво за счёт D1 (нового кода в launcher не требуется); TC-09
+  подтверждает чистый requeue + повторный claim без «частично стартовавшего» зависания.
+- **FR-4 / AC-5:** `find_impossible_queued_jobs` / `sanitize_impossible_queued` (идемпотентно,
+  never-raise) + вызов при старте (`main.lifespan` после `requeue_running_jobs`) и на каждом
+  реап-тике; счётчик `impossible_queued_total`/`last_impossible_queued` в блоке `reaper` снимка
+  `GET /queue` (TC-08/08b, kill-switch проверен).
+- **FR-5 / AC-4:** reaper Tier-1 не правился (подтверждено diff'ом) — `if pid is not None and not
+  pid_alive(pid)` пропускает `pid IS NULL`, `else` сбрасывает streak (`job_reaper.py:290/302`);
+  Tier-3 backstop неизменен. TC-07 фиксирует «свежий running с pid IS NULL не реапится».
+- **AC-7:** схема БД (`jobs`) без изменений, новых колонок/таблиц нет; для здоровых job'ов поведение
+  байт-в-байт (TC-10 — терминальные исходы и `run_id`-линк не затронуты); enduro не затронут.
+
+### Соответствие ADR / трассировка (ось 2) — выполнено
+- ADR-001 (`06-adr/`) + сквозной `adr-0052` присутствуют, согласованы с кодом, статус `accepted`.
+- Маркированные инварианты (CLAUDE.md §9): **ORCH-065** Tier-1 — восстановлен и не изменён;
+  **ORCH-113** finalizer-liveness и **ORCH-114** transition-lease — ортогональны (свои маркеры/таблицы,
+  recovery по `boot_id`, не по `jobs.pid`); **ORCH-099** `/metrics` — улучшен (убрана утечка stale-pid).
+  Проверено: коммит **не трогает** `_reap_job`/`pid_alive` — только аддитивный sanitize-метод/вызов/поля
+  `status()`.
+- **Багфикс-трек (ORCH-019, BR-4):** обязательный регресс-фиксатор присутствует — **TC-01** красный на
+  коде до фикса (старый `requeue_running_jobs` оставлял `run_id=759`), зелёный после.
+
+### Качество кода (ось 3) — приемлемо
+- never-raise соблюдён: sanitize обёрнут в `try/except` в reaper и в `main.lifespan`; db-функции —
+  `try/finally` на соединении.
+- `mark_job`/`reap_running_job`: каллер-переданный `run_id` для `status='queued'` корректно
+  игнорируется (`if run_id is not None and status != "queued"`) и принудительно зануляется в
+  `elif`-ветке — без конфликта двойного SET.
+- Docstrings на новых публичных функциях есть; тесты содержательные (seeded-DB, без сети/Popen).
+- env-маппинг корректен: `impossible_queued_sanitize_enabled` ↔ `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED`
+  (env_prefix `ORCH_`), флаг задокументирован в `.env.example`.
+
+### Документация (ось 4, приоритет) — выполнено
+`src/` изменён → документация обновлена в том же PR:
+- `docs/architecture/internals.md` — новый раздел «Инвариант run-ownership строки `jobs`» +
+  аннотации `jobs.run_id`/`pid` + queue-recovery (корректный дом для внутренностей очереди/reaper).
+- `.env.example` — флаг `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED` в блоке reaper.
+- `CHANGELOG.md` — детальная запись (D1–D5 + покрытие).
+- ADR-001 + сквозной `adr-0052` — заведены.
+- README API-таблица **не требует** правки: новых эндпоинтов нет (TRZ §4) — лишь read-only под-поле
+  в существующем блоке `reaper` снимка `GET /queue` (паттерн прошлых reaper-метрик, напр.
+  `finalizer_defers_total` ORCH-113).
+- Витрина `docs/overview/` (ORCH-011) **не требует** правки: grep по витрине не нашёл упоминаний
+  run-ownership/reaper/impossible-queued — фикс внутренней гигиены данных не меняет описанных в
+  витрине стадий/гейтов/агентов/интеграций; ничего не выдаётся за устаревшее.
+- Обзорный `README.md` «Известные ограничения» (ORCH-079): данный дефект там не числился пунктом —
+  обновления не требуется.
+
+## Findings
+
+### P0 — Blocker
+- Нет.
+
+### P1 — Must fix
+- Нет.
+
+### P2 — Should fix
+- Нет.
+
+### P3 — Nice to have (не влияет на вердикт)
+- [ ] `sanitize_impossible_queued()` (`db.py`) делает `find_*` (откр/закр соединение) и затем
+  **отдельный** UPDATE в новом соединении; возвращаемый `anomalies` — pre-heal снимок. При редкой
+  гонке (claim флипнул строку `queued→running` между find и UPDATE) защитный `WHERE status='queued'`
+  корректно пропустит строку, но функция всё равно отчитается о ней как «исцелённой» → косметический
+  пере-подсчёт счётчика `impossible_queued_total`. Безвреден и идемпотентен; при желании — считать по
+  фактическому `rowcount` UPDATE.
+- [ ] В коммит попал рабочий файл-черновик `.task-dev.md` (`ORCH-124 → ORCH-126`). Это **не** регресс
+  данного PR — файл коммитится во всех прошлых задачах, влитых в `main` (ORCH-124/116/115/112…);
+  housekeeping-замечание: уместно добавить `.task-dev.md`/`.task-review.md` в `.gitignore` отдельной
+  задачей.
+
+## Документация
+**Обновлена в том же PR — требование выполнено.** `internals.md` (раздел инварианта + аннотации
+колонок + queue-recovery), `.env.example` (новый флаг), `CHANGELOG.md`, ADR-001 + сквозной `adr-0052`.
+README API-таблица и витрина `docs/overview/` правки **не требуют** (новых эндпоинтов нет — read-only
+под-поле существующего блока `reaper`; в витрине нет затронутых фактов). Документация консистентна с
+реализацией; стейл-ссылок не обнаружено.
+
+## Проверка тестами
+- `pytest tests/test_orch126_queued_stale_run.py -q` → **11 passed**.
+- Регресс смежных подсистем: `test_orch113_reaper_finalizer_liveness.py`,
+  `test_orch114_transition_ownership.py`, `test_webhooks.py` → **63 passed**.
+- TC-01 — обязательный регресс красный→зелёный (подтверждено по семантике до-фиксового
+  `requeue_running_jobs`).

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

@@ -0,0 +1,40 @@
+---
+result: PASS
+work_item: ORCH-126
+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%]
+........................................................................ [ 69%]
+........................................................................ [ 72%]
+........................................................................ [ 75%]
+........................................................................ [ 78%]
+........................................................................ [ 82%]
+........................................................................ [ 85%]
+........................................................................ [ 88%]
+........................................................................ [ 92%]
+........................................................................ [ 95%]
+........................................................................ [ 98%]
+.............................                                            [100%]
+=============================== warnings summary ===============================
+src/config.py:8
+  /repos/_wt/orchestrator/feature_ORCH-126-bug-queued-job-can-keep-stale-/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
+2189 passed, 1 warning in 95.34s (0:01:35)
+```

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

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

@@ -0,0 +1,46 @@
+---
+staging_status: SUCCESS
+work_item: ORCH-126
+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 bd1cf253-c962-40cc-9d09-80b8fb11dfcc (HTTP 204)
+  ·      CLEANUP DB: no task row found for plane_id=bd1cf253-c962-40cc-9d09-80b8fb11dfcc
+  ·      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
+```

src/agents/launcher.py

@@ -512,7 +512,8 @@ class AgentLauncher:
         return None
 
     def _materialize_deferred_branch(
-        self, repo: str, branch: str, work_item_id: str | None, title: str | None
+        self, repo: str, branch: str, work_item_id: str | None, title: str | None,
+        description: str | None = None,
     ) -> None:
         """ORCH-088 (ADR-001 D1): create the deferred Gitea branch + initial docs.
 
@@ -524,6 +525,12 @@ class AgentLauncher:
         Both are idempotent (409/422 -> no-op) so a re-claim after a restart is safe.
         A transient Gitea error PROPAGATES so the caller (_spawn) fails the launch and
         the queue worker requeues the job for a later tick (never a half-cut state).
+
+        ORCH-119 (FR-3 / AC-3): ``description`` (read from the tasks row by ``_spawn``,
+        durable since task creation) is passed through to ``_create_initial_docs`` so
+        the artifact materialised at claim carries the real request text, not ``TBD``.
+        The branch-cut MOMENT/CONDITION are unchanged — only the data source is enriched
+        (ORCH-088 anti-stale-base invariant preserved, NFR-3).
         """
         import asyncio
         from ..webhooks.plane import _create_gitea_branch, _create_initial_docs
@@ -535,7 +542,9 @@ class AgentLauncher:
         )
         asyncio.run(_create_gitea_branch(repo, branch))
         if work_item_id:
-            asyncio.run(_create_initial_docs(repo, branch, work_item_id, name))
+            asyncio.run(
+                _create_initial_docs(repo, branch, work_item_id, name, description)
+            )
 
     def _spawn(self, agent: str, repo: str, task_content: str = None,
                task_id: int = None, job_id: int = None) -> int:
@@ -556,9 +565,14 @@ class AgentLauncher:
             raise FileNotFoundError(f"Repo not found: {local_repo_path}")
 
         # Determine branch (needed before we touch the worktree / task file).
+        # ORCH-119: also read the durable `description` so the deferred branch
+        # materialisation (path B) renders the real request text into
+        # 00-business-request.md instead of `TBD`. No network call (read from the
+        # tasks row) -> the hot claim path stays network-free (NFR-4).
         _br_row = (
             get_db().execute(
-                "SELECT branch, work_item_id, title FROM tasks WHERE id=?", (task_id,)
+                "SELECT branch, work_item_id, title, description FROM tasks WHERE id=?",
+                (task_id,),
             ).fetchone()
             if task_id else None
         )
@@ -580,7 +594,7 @@ class AgentLauncher:
                 _applies = False
             if _applies:
                 self._materialize_deferred_branch(
-                    repo, agent_branch, _br_row[1], _br_row[2]
+                    repo, agent_branch, _br_row[1], _br_row[2], _br_row[3]
                 )
 
         # ORCH-41: resolve the Plane project uuid for this repo so per-project

src/analyst_questions.py

@@ -0,0 +1,169 @@
+"""ORCH-120 (adr-0053): analyst open-questions -> Needs Input — pure leaf helpers.
+
+Activates and completes the dead "analyst asks BLOCKING questions ->
+``01-questions.md`` -> Needs Input" path in
+``stage_engine._handle_analysis_approved_flow``. This module holds ONLY the pure,
+unit-testable decision logic; the side effects (set_issue_needs_input / Plane
+comment / Telegram / auto-park) stay in ``stage_engine``.
+
+Leaf pattern (mirror of ``coverage_gate`` / ``serial_gate`` / ``labels``): imports
+only ``os`` / ``logging`` / ``config`` and lazily ``qg.checks.is_self_hosting_repo``;
+NEVER imports ``stage_engine`` / ``launcher`` / ``db``.
+
+What it decides (ADR-001 D2/D3):
+  * ``questions_gate_applies(repo)`` — whether the ORCH-120 priority+supersede
+    behaviour is REAL for this repo (kill-switch + scope, mirror of
+    ``coverage_gate_applies``). OFF / out-of-scope -> ``stage_engine`` runs its
+    ORIGINAL byte-for-byte order (AC-9).
+  * ``autopause_applies(repo)`` — whether the engine auto-parks a task on Needs
+    Input (and unparks on resume). Independent sub-tumbler AND the questions gate
+    (a task is only ever auto-parked from within the questions-active branch).
+  * ``questions_active(worktree, work_item_id, files_ok)`` — the pure freshness-gated
+    supersede predicate (DQ-2): are there ACTIVE blocking questions that must win
+    over "files ready"?
+
+never-raise contract (self-hosting safety): every public function degrades
+conservatively and NEVER propagates into the stage engine / launcher / webhook.
+"""
+from __future__ import annotations
+
+import logging
+import os
+
+from .config import settings
+
+logger = logging.getLogger("orchestrator.analyst_questions")
+
+# The analyst's signal artifact (DQ-4: path kept as-is; the engine already reads
+# exactly this file — see stage_engine._handle_analysis_approved_flow).
+QUESTIONS_FILENAME = "01-questions.md"
+
+# The 4 mandatory analysis deliverables that ``check_analysis_complete`` gates on.
+# Used by the mtime freshness-supersede check (DQ-2): a full FRESH package
+# supersedes a stale, untouched 01-questions.md left over from a prior run.
+DELIVERABLES = (
+    "01-brd.md",
+    "02-trz.md",
+    "03-acceptance-criteria.md",
+    "04-test-plan.yaml",
+)
+
+
+# ---------------------------------------------------------------------------
+# Conditionality (mirrors coverage_gate_applies / serial_gate_applies)
+# ---------------------------------------------------------------------------
+def questions_gate_applies(repo: str) -> bool:
+    """Whether the ORCH-120 questions priority+supersede is REAL for this repo.
+
+    Mirrors the ORCH-22 / ORCH-27 / ORCH-43 pattern:
+      * ``analyst_questions_gate_enabled=False`` -> always False (kill-switch; the
+        engine runs its ORIGINAL pre-ORCH-120 branch order — zero regression, AC-9).
+      * ``analyst_questions_gate_repos`` (CSV) non-empty -> real only for the listed
+        repos.
+      * empty CSV -> real ONLY for the self-hosting repo (``orchestrator``).
+    Never raises (AC-10): any error -> False (the safe no-op default that matches
+    the kill-switch-off behaviour).
+    """
+    try:
+        if not getattr(settings, "analyst_questions_gate_enabled", False):
+            return False
+        raw = (getattr(settings, "analyst_questions_gate_repos", "") or "").strip()
+        if raw:
+            allowed = {r.strip().lower() for r in raw.split(",") if r.strip()}
+            return (repo or "").strip().lower() in allowed
+        # Lazy import keeps this module a leaf (no qg import at module load).
+        from .qg.checks import is_self_hosting_repo
+        return is_self_hosting_repo(repo)
+    except Exception as e:  # noqa: BLE001 - never-raise contract
+        logger.warning("questions_gate_applies error for %s: %s", repo, e)
+        return False
+
+
+def autopause_applies(repo: str) -> bool:
+    """Whether the engine auto-parks on Needs Input / unparks on resume (D4/D5).
+
+    Two independent conditions, BOTH required:
+      * ``analyst_needs_input_autopause_enabled`` (independent sub-tumbler; False ->
+        operator-park only, via ``POST /serial-gate/pause``), AND
+      * ``questions_gate_applies(repo)`` — a task is only ever auto-parked from
+        within the questions-active branch, so the auto-park scope can never exceed
+        the questions gate (keeps the off/out-of-scope path byte-for-byte, AC-9).
+    Never raises (AC-10): any error -> False (degrade to operator-park).
+    """
+    try:
+        if not getattr(settings, "analyst_needs_input_autopause_enabled", False):
+            return False
+        return questions_gate_applies(repo)
+    except Exception as e:  # noqa: BLE001 - never-raise contract
+        logger.warning("autopause_applies error for %s: %s", repo, e)
+        return False
+
+
+# ---------------------------------------------------------------------------
+# Pure freshness-gated supersede predicate (DQ-2)
+# ---------------------------------------------------------------------------
+def _work_item_dir(worktree_path: str, work_item_id: str) -> str:
+    return os.path.join(worktree_path, "docs", "work-items", work_item_id)
+
+
+def questions_active(worktree_path: str, work_item_id: str, files_ok: bool) -> bool:
+    """Are there ACTIVE blocking questions that must win over "files ready" (DQ-2)?
+
+    Deterministic and OFFLINE (filesystem only — no network, no git):
+
+      * ``01-questions.md`` absent -> NOT active (``False``).
+      * package incomplete (``files_ok is False``) and the file is present -> active
+        (``True``): questions exist, deliverables do not -> questions win (AC-2).
+      * package complete (``files_ok is True``) and the file is present -> freshness
+        check: **superseded iff ALL 4 deliverables are strictly newer** than
+        ``01-questions.md`` (by ``os.path.getmtime``). Superseded -> NOT active
+        (``False`` -> In Review, AC-6); otherwise -> active (``True`` -> Needs Input,
+        AC-1). A full FRESH analyst run always writes the 4 deliverables with a newer
+        mtime, so a stale untouched 01-questions.md is deterministically superseded
+        without depending on any LLM action.
+
+    Fail directions (never-raise, AC-10 / DQ-2):
+      * a ``getmtime``/comparison error while the file PROVABLY exists -> treat
+        questions as **active** (``True``, Needs Input) — safe for "don't build on
+        guesses".
+      * a catastrophic error (cannot even determine file presence) -> ``False`` so
+        ``stage_engine`` degrades to its prior ``files_ok`` order + WARNING.
+    """
+    try:
+        questions_path = os.path.join(
+            _work_item_dir(worktree_path, work_item_id), QUESTIONS_FILENAME
+        )
+        present = os.path.isfile(questions_path)
+    except Exception as e:  # noqa: BLE001 - catastrophic: cannot determine presence
+        logger.warning(
+            "questions_active: cannot determine 01-questions.md presence for %s: %s",
+            work_item_id, e,
+        )
+        return False
+
+    if not present:
+        return False
+    if not files_ok:
+        # Questions present, deliverables incomplete -> questions take priority.
+        return True
+
+    # Package complete: superseded iff every deliverable is strictly newer than
+    # the questions file. Any mtime error on a proven-existing file -> active.
+    try:
+        q_mtime = os.path.getmtime(questions_path)
+        base = _work_item_dir(worktree_path, work_item_id)
+        for name in DELIVERABLES:
+            dp = os.path.join(base, name)
+            if not os.path.isfile(dp) or not (os.path.getmtime(dp) > q_mtime):
+                # A deliverable is missing or not strictly newer -> NOT superseded
+                # -> questions still active (Needs Input). (files_ok True means the
+                # gate saw all 4; a missing file here is defensive only.)
+                return True
+        # All 4 deliverables strictly newer -> superseded -> In Review.
+        return False
+    except Exception as e:  # noqa: BLE001 - mtime error on existing file -> active
+        logger.warning(
+            "questions_active: freshness check failed for %s -> active (Needs Input): %s",
+            work_item_id, e,
+        )
+        return True

src/config.py

@@ -722,6 +722,17 @@ class Settings(BaseSettings):
     lease_reclaim_enabled: bool = True
     reaper_finalizer_liveness_enabled: bool = True
 
+    # ORCH-126 (D4/FR-4): detect + self-heal "impossible" queued rows — a job that
+    # is `status='queued'` while still carrying run-ownership (run_id/pid/started_at),
+    # which is physically impossible (the incident state of job 2286: `queued +
+    # run_id=759 + pid=35 + started_at=NULL`). The BASE run-ownership reset on every
+    # requeue/claim path (D1-D3 in src/db.py) is UNCONDITIONAL — this kill-switch
+    # gates ONLY the optional detect/sanitize sweep (run at startup in main.lifespan
+    # and on each job-reaper tick) plus its read-only /queue counter. Default on;
+    # False -> the sweep is a no-op (D1-D3 still enforce the invariant going forward).
+    # never-raise: a sweep error is isolated and never wedges startup / the reaper.
+    impossible_queued_sanitize_enabled: bool = 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 to a DURABLE, cross-path owner-exclusion (additive table
@@ -1001,9 +1012,56 @@ class Settings(BaseSettings):
     #                                layer (env ORCH_SERIAL_GATE_FREEZE_ENABLED). False
     #                                -> freeze is neither set (post-deploy DEGRADED) nor
     #                                consulted in the claim gate.
+    #   serial_gate_pause_enabled -> ORCH-124 (adr-0051 D6): independent tumbler for
+    #                                the per-task "park" axis (env
+    #                                ORCH_SERIAL_GATE_PAUSE_ENABLED). True (default) ->
+    #                                a task with tasks.paused_at NOT NULL is excluded
+    #                                from the serial-gate "active task" predicate so an
+    #                                URGENT successor may overtake a paused predecessor.
+    #                                Default is a TRUE no-op until an operator pauses a
+    #                                task (paused_at is NULL for all rows). False ->
+    #                                pause-term omitted, serial-gate is byte-for-byte
+    #                                ORCH-088/090 (deliberate rollback). Scope reuses
+    #                                serial_gate_repos (no new *_repos flag); subordinate
+    #                                to the serial_gate_enabled kill-switch.
     serial_gate_enabled: bool = True
     serial_gate_repos: str = ""
     serial_gate_freeze_enabled: bool = True
+    serial_gate_pause_enabled: bool = True
+
+    # ORCH-120 (adr-0053): analyst open-questions -> Needs Input. Activates and
+    # completes 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
+    # keys / DB schema are byte-for-byte UNCHANGED (the flow is a pre-gate engine
+    # branch, NOT a Quality Gate; 01-questions.md is a SIGNAL artifact, NOT a
+    # machine-verdict). See docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-
+    # questions-needs-input.md.
+    #   analyst_questions_gate_enabled       -> kill-switch (env
+    #                                ORCH_ANALYST_QUESTIONS_GATE_ENABLED) of the
+    #                                priority+supersede behaviour (D3). False ->
+    #                                _handle_analysis_approved_flow runs its ORIGINAL
+    #                                pre-ORCH-120 order (files_ok first, then a flat
+    #                                isfile(01-questions.md) check) byte-for-byte (AC-9).
+    #   analyst_questions_gate_repos         -> CSV scope (env
+    #                                ORCH_ANALYST_QUESTIONS_GATE_REPOS). Empty -> real
+    #                                ONLY for the self-hosting repo (orchestrator) via
+    #                                is_self_hosting_repo; non-empty -> membership.
+    #                                Mirrors coverage_gate_repos -> enduro untouched.
+    #   analyst_needs_input_autopause_enabled -> independent sub-tumbler (env
+    #                                ORCH_ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED) for
+    #                                auto-park on Needs Input / unpark on resume (D4/D5)
+    #                                via the ORCH-124 pause axis (db.set_task_paused /
+    #                                clear_task_paused). True -> a Needs-Input task is
+    #                                excluded from the serial-gate "active task"
+    #                                predicate so the repo FIFO does not wedge while we
+    #                                wait for a human. False -> operator-park only
+    #                                (POST /serial-gate/pause). Subordinate to the
+    #                                questions gate (auto-park only fires from the
+    #                                questions-active branch).
+    analyst_questions_gate_enabled: bool = True
+    analyst_questions_gate_repos: str = ""
+    analyst_needs_input_autopause_enabled: bool = True
 
     # ORCH-090: STOP-status task cancellation (stop active agent + full progress
     # reset) and the relaunch-hole close. A new logical Plane key `stop` (fail-closed,

src/db.py

@@ -123,6 +123,16 @@ def init_db():
     # ("🛠️ ET-012 · <title>"). Populated from the Plane work-item name at task
     # creation; falls back to the work_item_id when absent. Idempotent ALTER.
     _ensure_column(conn, "tasks", "title", "TEXT")
+    # ORCH-119 (08-data-requirements.md): durable source-backed Plane-issue
+    # `description` (plain-text, preferably description_stripped). Mirrors tasks.title
+    # 1:1 — additive, idempotent (_ensure_column is a no-op once present) -> safe on
+    # the live shared prod DB (enduro untouched). Written inside the atomic INSERT in
+    # create_task_atomic so it is race-safe vs the ORCH-053 anti-dup claim (no window
+    # where the task exists but the description is missing). The deferred branch cut
+    # (path B, ORCH-088, dominates on self-hosting) reads it from the tasks row at
+    # claim time and renders it into 00-business-request.md instead of the historic
+    # hardcoded `TBD`. NULL for pre-existing rows -> renders the safe fallback marker.
+    _ensure_column(conn, "tasks", "description", "TEXT")
     # Telegram live tracker: "BRD review" is the only HUMAN gate time — the delta
     # between "BRD ready / approve requested" and the analysis->architecture
     # advance (human flipped Plane to Approved). Persisted on the task so the
@@ -147,6 +157,17 @@ def init_db():
     # after a successful atomic create). Read in advance_stage for the routing-override
     # (skips architecture) — from the DB, NEVER from the network (NFR-4).
     _ensure_column(conn, "tasks", "track", "TEXT DEFAULT 'full'")
+    # ORCH-124 (08-data-requirements.md, ADR-001 D2): per-task durable "park"
+    # signal for the serial gate. Additive, idempotent (_ensure_column is a no-op
+    # once present) -> safe on the live shared prod DB (enduro untouched), exactly
+    # like tasks.cancelled_at / tasks.cancel_requested_at / tasks.track above.
+    #   paused_at -> NULL = not paused; ISO timestamp (datetime('now')) = an
+    #                operator explicitly parked the task (POST /serial-gate/pause).
+    # Read ONLY by the serial-gate "active task" predicate (ORTHOGONAL to the
+    # {done,cancelled} terminal axis — task_deps/stages.py do NOT read it, adr-0026
+    # is untouched). All existing rows default to NULL -> pre-ORCH-124 behaviour
+    # holds until the first explicit operator pause.
+    _ensure_column(conn, "tasks", "paused_at", "TEXT")
     # ORCH-026 (Level B): declarative task dependencies. job_deps stores the
     # directed edge "task_id (B) is blocked-by depends_on_task_id (A)". The
     # scheduler gate in claim_next_job keeps B queued until every A reaches
@@ -651,6 +672,7 @@ def create_task_atomic(
     branch: str,
     stage: str,
     title: str,
+    description: str | None = None,
 ) -> tuple[dict, bool]:
     """ORCH-053 (AC-4): atomically claim creation of a task for a plane_id.
 
@@ -665,6 +687,14 @@ def create_task_atomic(
       * ``created=False`` -> a task for this plane_id already existed (the other
         racer won); ``row`` is the existing task and the caller must NOT duplicate
         the follow-up work.
+
+    ORCH-119 (ADR-001 D1): ``description`` (the source-backed Plane-issue text) is
+    persisted durable INSIDE this same atomic INSERT — never a separate UPDATE — so
+    there is no race window (ORCH-053) where the task exists but the description is
+    missing. The parameter is additive with a default so the other callers (e.g. the
+    F-2 reconciler) stay backward-compatible (NULL description -> render falls back to
+    a safe marker). The deferred branch cut (path B, ORCH-088) reads it from the row
+    at claim time.
     """
     with _CREATE_TASK_LOCK:
         conn = get_db()
@@ -677,9 +707,11 @@ def create_task_atomic(
                 return dict(existing), False
             cur = conn.execute(
                 "INSERT INTO tasks "
-                "(plane_id, work_item_id, repo, branch, stage, plane_issue_id, title) "
-                "VALUES (?, ?, ?, ?, ?, ?, ?)",
-                (plane_id, work_item_id, repo, branch, stage, plane_id, title),
+                "(plane_id, work_item_id, repo, branch, stage, plane_issue_id, title, "
+                "description) "
+                "VALUES (?, ?, ?, ?, ?, ?, ?, ?)",
+                (plane_id, work_item_id, repo, branch, stage, plane_id, title,
+                 description),
             )
             conn.commit()
             row = conn.execute(
@@ -776,6 +808,95 @@ def get_task_track(task_id: int) -> str:
         return "full"
 
 
+# ---------------------------------------------------------------------------
+# ORCH-124: serial-gate per-task park signal (tasks.paused_at) helpers
+# ---------------------------------------------------------------------------
+def set_task_paused(task_id: int) -> bool:
+    """ORCH-124 (ADR-001 D7): park a task for the serial gate (idempotent).
+
+    Stamps ``tasks.paused_at=datetime('now')`` so the serial-gate "active task"
+    predicate stops counting this task as a FIFO blocker (an URGENT successor may
+    overtake it). Durable (survives restart) and DB-resolvable — the hot-claim SQL
+    reads it locally without any network call. Re-pausing an already-paused task
+    keeps the original timestamp (``WHERE paused_at IS NULL``), so the park moment
+    is stable. never-raise -> False on error (a write failure must not crash the
+    operator endpoint / worker).
+    """
+    if task_id is None:
+        return False
+    try:
+        conn = get_db()
+        try:
+            conn.execute(
+                "UPDATE tasks SET paused_at=datetime('now') "
+                "WHERE id=? AND paused_at IS NULL",
+                (task_id,),
+            )
+            conn.commit()
+        finally:
+            conn.close()
+        return True
+    except Exception as e:  # noqa: BLE001 - never-raise
+        import logging
+        logging.getLogger("orchestrator.db").warning(
+            "set_task_paused error for task %s: %s", task_id, e
+        )
+        return False
+
+
+def clear_task_paused(task_id: int) -> bool:
+    """ORCH-124 (ADR-001 D7): resume a parked task (idempotent).
+
+    Clears ``tasks.paused_at`` back to NULL so the task re-enters the serial-gate
+    FIFO (holds the gate as active again, or re-enters with a deferred branch cut —
+    see ADR-001 D8). Resuming a task that is not paused is a no-op. never-raise ->
+    False on error.
+    """
+    if task_id is None:
+        return False
+    try:
+        conn = get_db()
+        try:
+            conn.execute(
+                "UPDATE tasks SET paused_at=NULL WHERE id=?",
+                (task_id,),
+            )
+            conn.commit()
+        finally:
+            conn.close()
+        return True
+    except Exception as e:  # noqa: BLE001 - never-raise
+        import logging
+        logging.getLogger("orchestrator.db").warning(
+            "clear_task_paused error for task %s: %s", task_id, e
+        )
+        return False
+
+
+def is_task_paused(task_id: int) -> bool:
+    """ORCH-124: read whether a task is currently parked; missing/error -> False.
+
+    Conservative fail direction (ADR-001 D9): on any read error we report "not
+    paused" so the task is treated as active -> the serial gate stays CLOSED rather
+    than wrongly opening (anti-stale-base safe). Mirror of ``get_task_track``.
+    """
+    if task_id is None:
+        return False
+    try:
+        conn = get_db()
+        try:
+            row = conn.execute(
+                "SELECT paused_at FROM tasks WHERE id=?", (task_id,)
+            ).fetchone()
+        finally:
+            conn.close()
+        if not row:
+            return False
+        return row["paused_at"] is not None
+    except Exception:  # noqa: BLE001 - conservative: not paused -> stays active
+        return False
+
+
 # ---------------------------------------------------------------------------
 # Telegram live tracker helpers (feat/telegram-live-tracker)
 # ---------------------------------------------------------------------------
@@ -1094,8 +1215,16 @@ def claim_next_job() -> dict | None:
                 return None
             job_id = row["id"]
             cur = conn.execute(
+                # ORCH-126 (D2/FR-2): reset run-ownership on the queued->running flip
+                # (defense-in-depth over D1). Between this claim and the launcher
+                # stamping the real pid in _spawn, the row MUST carry pid IS NULL —
+                # not a stale (possibly OS-reused) pid that the job-reaper's Tier-1
+                # liveness probe (ORCH-065) would mistake for this run's process. The
+                # SELECT gate above is untouched (offline hot path, NFR-2); this is
+                # part of the existing single UPDATE (no new SELECT / network).
                 "UPDATE jobs SET status='running', "
-                "attempts = attempts + 1, started_at = datetime('now') "
+                "attempts = attempts + 1, started_at = datetime('now'), "
+                "pid = NULL, run_id = NULL "
                 "WHERE id = ? AND status='queued'",
                 (job_id,),
             )
@@ -1117,12 +1246,19 @@ def mark_job_transient(job_id: int, available_at_sql_offset_seconds: int,
     Increments `transient_attempts` (separate from the code-fault `attempts`),
     sets status back to 'queued', and gates re-pickup via `available_at` =
     now + backoff seconds. started_at/finished_at are cleared.
+
+    ORCH-126 (D1/FR-1): also resets run-ownership (run_id/pid) so the requeued job
+    obeys the invariant `status='queued' ⇒ run_id IS NULL AND pid IS NULL AND
+    started_at IS NULL` (see mark_job). The transient bookkeeping
+    (transient_attempts / available_at backoff) is preserved.
     """
     conn = get_db()
     sets = [
         "status='queued'",
         "transient_attempts = transient_attempts + 1",
         "available_at = datetime('now', ?)",
+        "run_id = NULL",
+        "pid = NULL",
         "started_at = NULL",
         "finished_at = NULL",
     ]
@@ -1149,11 +1285,23 @@ def mark_job(
     - 'done'/'failed'/'cancelled' (ORCH-090) also stamp finished_at.
     - 'queued' (requeue for retry) clears started_at/finished_at so the next
       claim treats it as fresh.
+
+    ORCH-126 (D1/FR-1): a 'queued' requeue ALSO resets run-ownership
+    (run_id/pid), enforcing the lifecycle invariant
+      ``status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL``.
+    A requeued job must carry NO run-ownership: a stale (and possibly OS-reused)
+    pid would fool the job-reaper's Tier-1 liveness probe (ORCH-065) into either
+    guarding a phantom 'running' forever (wedging the shared queue at
+    max_concurrency=1) or reaping a fresh start. The run history lives in
+    agent_runs, not jobs.run_id, so dropping the link is safe. Any caller-supplied
+    run_id is therefore IGNORED for 'queued' (the link is cleared) — callers such
+    as launcher._finalize_permanent / reaper still pass the old run_id for the
+    non-queued paths, where it is preserved as before.
     """
     conn = get_db()
     sets = ["status = ?"]
     params: list = [status]
-    if run_id is not None:
+    if run_id is not None and status != "queued":
         sets.append("run_id = ?")
         params.append(run_id)
     if error is not None:
@@ -1162,6 +1310,8 @@ def mark_job(
     if status in ("done", "failed", "cancelled"):
         sets.append("finished_at = datetime('now')")
     elif status == "queued":
+        sets.append("run_id = NULL")
+        sets.append("pid = NULL")
         sets.append("started_at = NULL")
         sets.append("finished_at = NULL")
     params.append(job_id)
@@ -1377,10 +1527,17 @@ def requeue_running_jobs() -> int:
     died on restart -> put it back to 'queued'. attempts are kept as-is (the next
     claim does NOT re-increment beyond what is needed; claim_next_job increments on
     pickup). Returns the number of requeued jobs.
+
+    ORCH-126 (D1/FR-1): also resets run-ownership (run_id/pid). The dead worker's
+    run_id/pid are stale by construction after a restart; leaving them would make a
+    just-requeued job carry a phantom pid that the job-reaper's Tier-1 probe could
+    mistake for a live process (incident: job 2286 ``queued + run_id=759 + pid=35 +
+    started_at=NULL``). Enforces ``status='queued' ⇒ run_id/pid/started_at IS NULL``.
     """
     conn = get_db()
     cur = conn.execute(
-        "UPDATE jobs SET status='queued', started_at = NULL "
+        "UPDATE jobs SET status='queued', started_at = NULL, "
+        "run_id = NULL, pid = NULL "
         "WHERE status='running'"
     )
     conn.commit()
@@ -1532,12 +1689,17 @@ def reap_running_job(
 
     Status semantics match ``mark_job``: done/failed stamp ``finished_at``; queued
     clears ``started_at``/``finished_at`` so the next claim treats it as fresh.
+
+    ORCH-126 (D1/FR-1): a 'queued' reap ALSO resets run-ownership (run_id/pid),
+    mirroring ``mark_job`` — the invariant ``status='queued' ⇒ run_id/pid/started_at
+    IS NULL`` (a reaper-requeued job must not carry the dead run's pid). Any
+    caller-supplied run_id is ignored for 'queued'.
     """
     conn = get_db()
     try:
         sets = ["status = ?"]
         params: list = [status]
-        if run_id is not None:
+        if run_id is not None and status != "queued":
             sets.append("run_id = ?")
             params.append(run_id)
         if error is not None:
@@ -1546,6 +1708,8 @@ def reap_running_job(
         if status in ("done", "failed", "cancelled"):  # ORCH-090: cancelled is terminal
             sets.append("finished_at = datetime('now')")
         elif status == "queued":
+            sets.append("run_id = NULL")
+            sets.append("pid = NULL")
             sets.append("started_at = NULL")
             sets.append("finished_at = NULL")
         params.append(job_id)
@@ -1559,6 +1723,54 @@ def reap_running_job(
         conn.close()
 
 
+def find_impossible_queued_jobs() -> list[dict]:
+    """ORCH-126 (D4/FR-4): rows that violate the queued lifecycle invariant.
+
+    An "impossible" queued state is ``status='queued' AND (run_id IS NOT NULL OR
+    pid IS NOT NULL OR started_at IS NOT NULL)`` — run-ownership is set but the run
+    never actually started (the incident state of job 2286). Read-only; returns the
+    offending rows' identity columns (id/run_id/pid/started_at + agent/repo) for
+    diagnostics. Empty list when the invariant holds everywhere.
+    """
+    conn = get_db()
+    try:
+        rows = conn.execute(
+            "SELECT id, run_id, pid, started_at, agent, repo FROM jobs "
+            "WHERE status='queued' AND (run_id IS NOT NULL OR pid IS NOT NULL "
+            "OR started_at IS NOT NULL)"
+        ).fetchall()
+    finally:
+        conn.close()
+    return [dict(r) for r in rows]
+
+
+def sanitize_impossible_queued() -> list[dict]:
+    """ORCH-126 (D4/FR-4): idempotently restore the queued invariant for any
+    "impossible" queued row (run-ownership set while queued).
+
+    Returns the rows it healed (pre-heal id/run_id/pid/started_at) so the caller can
+    log them; empty list when nothing was anomalous. The UPDATE carries the same
+    ``status='queued'`` guard, so it can never touch a live ``running`` row (TR-1).
+    Used at startup (``main.lifespan``) and on each reaper tick to self-heal both a
+    forgotten future requeue path (TR-2) and pre-existing rows on a problematic DB
+    (TR-7) without a schema migration.
+    """
+    anomalies = find_impossible_queued_jobs()
+    if not anomalies:
+        return []
+    conn = get_db()
+    try:
+        conn.execute(
+            "UPDATE jobs SET run_id = NULL, pid = NULL, started_at = NULL "
+            "WHERE status='queued' AND (run_id IS NOT NULL OR pid IS NOT NULL "
+            "OR started_at IS NOT NULL)"
+        )
+        conn.commit()
+    finally:
+        conn.close()
+    return anomalies
+
+
 def get_job(job_id: int) -> dict | None:
     """Fetch a single job by id."""
     conn = get_db()

src/job_reaper.py

@@ -154,10 +154,55 @@ class JobReaper:
         # monitor still owns a deploy-staging finalization. Reset on restart (safe:
         # startup requeue_running_jobs covers the restart path).
         self.finalizer_defers_total: int = 0
+        # ORCH-126 (D4/FR-4): count of "impossible" queued rows self-healed (queued
+        # while carrying stale run-ownership) + the last healed batch. Reset on
+        # restart (safe: the startup sweep + every tick re-detect any residue).
+        self.impossible_queued_total: int = 0
+        self.last_impossible_queued: dict | None = None
+
+    # -- ORCH-126 (D4/FR-4): impossible-queued self-heal -------------------
+    def sanitize_impossible_queued_once(self) -> int:
+        """Detect + self-heal "impossible" queued rows (queued while carrying stale
+        run-ownership run_id/pid/started_at — the incident state of job 2286).
+
+        Idempotent, never-raise, gated by ``impossible_queued_sanitize_enabled``
+        (default on; D1-D3 enforce the invariant going forward regardless). Bumps the
+        observability counters + logs one WARNING per healed row. Used both at startup
+        (``main.lifespan``) and on every reaper tick. Returns the count healed.
+        """
+        if not getattr(settings, "impossible_queued_sanitize_enabled", True):
+            return 0
+        try:
+            from .db import sanitize_impossible_queued
+            healed = sanitize_impossible_queued()
+        except Exception as e:  # noqa: BLE001 - never break the tick / startup
+            logger.error("reaper: impossible-queued sanitize failed: %s", e)
+            return 0
+        if healed:
+            self.impossible_queued_total += len(healed)
+            self.last_impossible_queued = {
+                "count": len(healed),
+                "jobs": [
+                    {"job_id": r.get("id"), "run_id": r.get("run_id"),
+                     "pid": r.get("pid")}
+                    for r in healed
+                ],
+            }
+            for r in healed:
+                logger.warning(
+                    "reaper: sanitized impossible queued job %s (run_id=%s, pid=%s, "
+                    "started_at=%s) -> clean queued (ORCH-126 invariant)",
+                    r.get("id"), r.get("run_id"), r.get("pid"), r.get("started_at"),
+                )
+        return len(healed)
 
     # -- A: zombie-job reaping --------------------------------------------
     def reap_once(self) -> None:
         """One scan over all ``running`` jobs (per-job never-raise) + lease reclaim."""
+        # ORCH-126 (D4/FR-4): self-heal impossible queued rows first (independent of
+        # reaper_enabled — own kill-switch, never-raise) so a stale run-ownership row
+        # is normalised before the running-scan reasons about liveness.
+        self.sanitize_impossible_queued_once()
         if settings.reaper_enabled:
             try:
                 running = get_running_jobs()
@@ -570,6 +615,13 @@ class JobReaper:
             "finalizer_liveness_enabled": settings.reaper_finalizer_liveness_enabled,
             "finalizer_defers_total": self.finalizer_defers_total,
             "finalizer_owned": _owned,
+            # ORCH-126 (D4/FR-4): impossible-queued self-heal observability
+            # (read-only) — kill-switch + cumulative healed count + last batch.
+            "impossible_queued_sanitize_enabled": getattr(
+                settings, "impossible_queued_sanitize_enabled", True
+            ),
+            "impossible_queued_total": self.impossible_queued_total,
+            "last_impossible_queued": self.last_impossible_queued,
         }
 
 

src/main.py

@@ -60,6 +60,23 @@ async def lifespan(app: FastAPI):
     if requeued:
         log.warning(f"Queue-recovery: requeued {requeued} running job(s) after restart")
 
+    # ORCH-126 (D4/FR-4): self-heal any "impossible" queued rows — a job left
+    # `status='queued'` while still carrying run-ownership (run_id/pid/started_at),
+    # which is physically impossible (the incident state of job 2286). Runs right
+    # after requeue_running_jobs so a row the dead worker left half-claimed is
+    # normalised before the worker/reaper start. Routed through the reaper so the
+    # cumulative /queue counter has a single owner. Idempotent + never-raise; the
+    # recurring reaper tick keeps it clean thereafter.
+    try:
+        from .job_reaper import reaper as _reaper
+        healed = _reaper.sanitize_impossible_queued_once()
+        if healed:
+            log.warning(
+                f"Queued-hygiene: sanitized {healed} impossible queued job(s) at startup"
+            )
+    except Exception as e:
+        log.warning(f"Queued-hygiene sanitize skipped: {e}")
+
     # ORCH-114 (adr-0045 / D7 / FR-4): clear durable transition-leases left by the
     # PREVIOUS process boot. This process has a fresh boot_id, so every prior lease is
     # stale by construction -> reclaim it so the just-requeued jobs can re-drive their
@@ -376,6 +393,84 @@ async def serial_gate_unfreeze(repo: str = ""):
     return {"ok": True, "repo": repo, "cleared": cleared, "frozen": frozen}
 
 
+@app.post("/serial-gate/pause")
+async def serial_gate_pause(work_item: str = ""):
+    """ORCH-124 (adr-0051 D7): park a task so the serial gate stops counting it as
+    an active FIFO blocker — an urgent successor may overtake it.
+
+    Explicit, durable, DB-resolvable operator intent (NOT a Plane-status gesture):
+    stamps ``tasks.paused_at`` so the offline hot-claim SQL reads it locally without
+    a network call. Pause does NOT bypass a ``repo_freeze`` or a declared dependency
+    (different axes) and is NOT terminal (distinct from STOP/cancel). By образцу
+    ``POST /serial-gate/unfreeze``; never-raise. Pausing a terminal (done/cancelled)
+    task is a no-op. When the pause sub-flag is off the call is a no-op + warning
+    (the pause-term is omitted from the gate, so a column write would be latent).
+    """
+    from . import db
+    from . import serial_gate
+    if not work_item or not work_item.strip():
+        return {"ok": False, "error": "missing 'work_item'", "work_item": work_item}
+    work_item = work_item.strip()
+    if not serial_gate._pause_layer_enabled():
+        return {"ok": False, "error": "serial_gate_pause_enabled is off (no-op)",
+                "work_item": work_item}
+    task = db.get_task_by_work_item_id(work_item)
+    if not task:
+        return {"ok": False, "error": "unknown work_item", "work_item": work_item}
+    task_id = task["id"]
+    stage = task.get("stage")
+    if stage in ("done", "cancelled"):
+        return {"ok": False, "error": f"task is terminal (stage={stage})",
+                "work_item": work_item, "task_id": task_id, "stage": stage}
+    ok = db.set_task_paused(task_id)
+    refreshed = db.get_task_by_work_item_id(work_item) or {}
+    paused_at = refreshed.get("paused_at")
+    if ok:
+        try:
+            from .notifications import send_telegram, link_for
+            send_telegram(
+                f"⏸️ {link_for(work_item)}: задача поставлена на ПАУЗУ для serial-gate "
+                f"(task {task_id}, stage={stage}). Срочный успешник репо может обогнать; "
+                f"resume — POST /serial-gate/resume."
+            )
+        except Exception:
+            pass
+    return {"ok": ok, "work_item": work_item, "task_id": task_id,
+            "stage": stage, "paused_at": paused_at}
+
+
+@app.post("/serial-gate/resume")
+async def serial_gate_resume(work_item: str = ""):
+    """ORCH-124 (adr-0051 D7 / AC-10): resume a parked task — it re-enters the
+    serial gate (holds it as active again / re-enters FIFO with the deferred branch
+    cut, D8). Inverse of ``POST /serial-gate/pause``; idempotent (resuming a task
+    that is not paused clears nothing). Anti-stale-base on resume is guaranteed by
+    the EXISTING mechanisms (deferred branch cut + pre-merge auto_rebase_onto_main +
+    merge-gate re-test, ORCH-088/093/110) — no new rebase machinery. never-raise.
+    """
+    from . import db
+    if not work_item or not work_item.strip():
+        return {"ok": False, "error": "missing 'work_item'", "work_item": work_item}
+    work_item = work_item.strip()
+    task = db.get_task_by_work_item_id(work_item)
+    if not task:
+        return {"ok": False, "error": "unknown work_item", "work_item": work_item}
+    task_id = task["id"]
+    was_paused = task.get("paused_at") is not None
+    ok = db.clear_task_paused(task_id)
+    if ok and was_paused:
+        try:
+            from .notifications import send_telegram, link_for
+            send_telegram(
+                f"▶️ {link_for(work_item)}: задача СНЯТА С ПАУЗЫ (task {task_id}) — "
+                f"снова участвует в serial-gate."
+            )
+        except Exception:
+            pass
+    return {"ok": ok, "work_item": work_item, "task_id": task_id,
+            "was_paused": was_paused, "paused_at": None}
+
+
 @app.post("/transition-lease/release")
 async def transition_lease_release(work_item: str = ""):
     """ORCH-114 (adr-0045 / D10): operator manual reclaim of a stuck transition-lease.

src/serial_gate.py

@@ -23,6 +23,16 @@ Two deliberately different failure directions (ADR-001 D10, NFR-1):
     must not wedge the queue of ALL projects (AC-8).
   * freeze decision (``is_repo_frozen``) -> fail-CLOSED (``True``): when we cannot
     confirm the ABSENCE of a freeze we keep the gate closed for prod safety (AC-9).
+
+ORCH-124 (adr-0051): adds an ORTHOGONAL "pause" axis to the "active task" predicate
+of all three points (``build_claim_clause`` / ``repo_has_active_task`` /
+``_per_repo_snapshot``). A task with ``tasks.paused_at`` NOT NULL (an operator
+``POST /serial-gate/pause``) is excluded from the FIFO "active" set so an URGENT
+successor may overtake a paused predecessor — fixing incident ORCH-116/ORCH-123. The
+terminal set ``{done,cancelled}`` (adr-0026) is UNCHANGED; ``task_deps`` / ``stages.py``
+do NOT read ``paused_at`` (pause never bypasses a freeze or a declared dependency).
+Gated by the independent sub-flag ``serial_gate_pause_enabled`` (default True is a true
+no-op until the first explicit pause).
 """
 from __future__ import annotations
 
@@ -97,6 +107,22 @@ def _freeze_layer_enabled() -> bool:
         return False
 
 
+def _pause_layer_enabled() -> bool:
+    """ORCH-124 (adr-0051 D6): whether the per-task pause axis is active.
+
+    Independent tumbler ``serial_gate_pause_enabled`` (mirror of
+    ``_freeze_layer_enabled``). When True the "active task" predicate of all three
+    serial-gate points additionally excludes paused tasks (``paused_at IS NULL``);
+    when False the pause-term is omitted and serial-gate behaves byte-for-byte as
+    ORCH-088/090. Default True is a true no-op until an operator parks a task
+    (``paused_at`` is NULL for every row). never-raise -> False (pause inert).
+    """
+    try:
+        return bool(getattr(settings, "serial_gate_pause_enabled", False))
+    except Exception:  # noqa: BLE001
+        return False
+
+
 # ---------------------------------------------------------------------------
 # Read helpers (active task + freeze) — only the local DB
 # ---------------------------------------------------------------------------
@@ -113,16 +139,21 @@ def repo_has_active_task(repo: str, exclude_task_id: int | None = None) -> bool:
             # ORCH-090 (adr-0026): terminal set is {done,cancelled}. A cancelled
             # task must NOT count as "active" or it would block the repo's serial
             # gate forever.
+            # ORCH-124 (adr-0051 D4.2): under the pause layer a PARKED task
+            # (paused_at NOT NULL) is likewise NOT "active" — it must not hold the
+            # FIFO gate against an urgent successor. Same predicate as the hot SQL
+            # (D4.1) and the snapshot (D4.3) so the three points never drift (TR-7).
+            pause_term = " AND paused_at IS NULL" if _pause_layer_enabled() else ""
             if exclude_task_id is not None:
                 row = conn.execute(
                     "SELECT 1 FROM tasks WHERE repo=? AND id != ? "
-                    "AND stage NOT IN ('done','cancelled') LIMIT 1",
+                    f"AND stage NOT IN ('done','cancelled'){pause_term} LIMIT 1",
                     (repo, exclude_task_id),
                 ).fetchone()
             else:
                 row = conn.execute(
                     "SELECT 1 FROM tasks WHERE repo=? "
-                    "AND stage NOT IN ('done','cancelled') LIMIT 1",
+                    f"AND stage NOT IN ('done','cancelled'){pause_term} LIMIT 1",
                     (repo,),
                 ).fetchone()
             return row is not None
@@ -271,10 +302,18 @@ def build_claim_clause() -> str:
             repo_scope = ""
         # ORCH-090 (adr-0026): {done,cancelled} are both terminal — an EARLIER
         # cancelled task no longer holds the FIFO serial gate closed.
+        # ORCH-124 (adr-0051 D4.1): under the pause layer an EARLIER PARKED task
+        # (paused_at NOT NULL) also no longer holds the FIFO gate — an urgent
+        # successor may overtake it. The pause-term is appended INSIDE the existing
+        # EXISTS subquery (no extra JOIN/EXISTS), reads only the local DB (offline
+        # hot path, NFR-2), and is built inside the same try/except so any error in
+        # the pause sub-expression still fails-OPEN (D9). pause off / kill-switch ->
+        # pause_term is "" -> the clause is byte-for-byte ORCH-088/090.
+        pause_term = " AND t2.paused_at IS NULL" if _pause_layer_enabled() else ""
         active_clause = (
             "EXISTS (SELECT 1 FROM tasks t2 "
             "WHERE t2.repo = jobs.repo AND t2.id < jobs.task_id "
-            "AND t2.stage NOT IN ('done','cancelled')) "
+            f"AND t2.stage NOT IN ('done','cancelled'){pause_term}) "
         )
         if _freeze_layer_enabled():
             freeze_clause = (
@@ -329,23 +368,91 @@ def _known_repos() -> list[str]:
     return sorted(repos)
 
 
+def _waiting_reason(conn, repo: str, task_id: int | None, *,
+                    frozen: bool, pause_on: bool, deps_on: bool) -> str | None:
+    """ORCH-124 (adr-0051 D5): why an analyst-job is NOT claimable, or None.
+
+    Priority order (matches the precedence of the actual claim gates):
+    ``freeze`` (active repo_freeze) -> ``dependency`` (an unfinished declared
+    job_deps predecessor, only when task_deps is on) -> ``active-task`` (an EARLIER
+    NON-paused unfinished task holds the FIFO gate) -> ``None`` (claimable). A
+    paused predecessor is deliberately NOT a reason — by design it does NOT block,
+    so it surfaces only via the snapshot's ``paused`` list, never here. never-raise
+    -> None on error (observability only, conservative).
+    """
+    try:
+        if frozen:
+            return "freeze"
+        if deps_on and task_id is not None:
+            dep = conn.execute(
+                "SELECT 1 FROM job_deps d JOIN tasks t ON t.id = d.depends_on_task_id "
+                "WHERE d.task_id = ? AND t.stage NOT IN ('done','cancelled') LIMIT 1",
+                (task_id,),
+            ).fetchone()
+            if dep is not None:
+                return "dependency"
+        if task_id is not None:
+            pause_term = " AND paused_at IS NULL" if pause_on else ""
+            earlier = conn.execute(
+                "SELECT 1 FROM tasks WHERE repo=? AND id < ? "
+                f"AND stage NOT IN ('done','cancelled'){pause_term} LIMIT 1",
+                (repo, task_id),
+            ).fetchone()
+            if earlier is not None:
+                return "active-task"
+        return None
+    except Exception:  # noqa: BLE001 - observability only
+        return None
+
+
 def _per_repo_snapshot(repo: str) -> dict:
     """Per-repo gate state for the /queue snapshot (never raises here)."""
     active_task = None
     waiting: list[dict] = []
+    paused: list[dict] = []
+    # ORCH-124 (adr-0051 D5): compute frozen up-front so the per-job reason can be
+    # derived in the same pass. is_repo_frozen uses its own connection (separate
+    # from the snapshot conn below).
+    frozen = is_repo_frozen(repo)
+    pause_on = _pause_layer_enabled()
+    try:
+        deps_on = bool(getattr(settings, "task_deps_enabled", False))
+    except Exception:  # noqa: BLE001
+        deps_on = False
     try:
         conn = db.get_db()
         try:
             # ORCH-090 (adr-0026): terminal set {done,cancelled}.
+            # ORCH-124 (adr-0051 D4.3): a PARKED task is excluded from active_task
+            # (same predicate as build_claim_clause / repo_has_active_task — no
+            # drift, TR-7); it surfaces in the additive `paused` list instead.
+            pause_term = " AND paused_at IS NULL" if pause_on else ""
             row = conn.execute(
                 "SELECT work_item_id, stage FROM tasks "
-                "WHERE repo=? AND stage NOT IN ('done','cancelled') ORDER BY id LIMIT 1",
+                f"WHERE repo=? AND stage NOT IN ('done','cancelled'){pause_term} "
+                "ORDER BY id LIMIT 1",
                 (repo,),
             ).fetchone()
             if row:
                 active_task = {"work_item_id": row["work_item_id"], "stage": row["stage"]}
+            # ORCH-124: additive `paused` list — non-terminal parked tasks of the
+            # repo (visible, but NOT counted as active_task). Only meaningful while
+            # the pause layer is on.
+            if pause_on:
+                for pr in conn.execute(
+                    "SELECT work_item_id, stage, paused_at FROM tasks "
+                    "WHERE repo=? AND stage NOT IN ('done','cancelled') "
+                    "AND paused_at IS NOT NULL ORDER BY id",
+                    (repo,),
+                ).fetchall():
+                    paused.append({
+                        "work_item_id": pr["work_item_id"],
+                        "stage": pr["stage"],
+                        "paused_at": pr["paused_at"],
+                    })
             for j in conn.execute(
-                "SELECT j.id AS job_id, t.work_item_id AS work_item_id, t.stage AS stage "
+                "SELECT j.id AS job_id, j.task_id AS task_id, "
+                "t.work_item_id AS work_item_id, t.stage AS stage "
                 "FROM jobs j LEFT JOIN tasks t ON t.id = j.task_id "
                 "WHERE j.repo=? AND j.status='queued' AND j.agent='analyst' "
                 "ORDER BY j.id",
@@ -355,12 +462,17 @@ def _per_repo_snapshot(repo: str) -> dict:
                     "job_id": j["job_id"],
                     "work_item_id": j["work_item_id"],
                     "stage": j["stage"],
+                    # ORCH-124 (D5): why this job is held (freeze/dependency/
+                    # active-task) or None when claimable.
+                    "reason": _waiting_reason(
+                        conn, repo, j["task_id"],
+                        frozen=frozen, pause_on=pause_on, deps_on=deps_on,
+                    ),
                 })
         finally:
             conn.close()
     except Exception as e:  # noqa: BLE001
         logger.warning("serial_gate per-repo snapshot error for %s: %s", repo, e)
-    frozen = is_repo_frozen(repo)
     frozen_reason = None
     frozen_at = None
     if frozen:
@@ -374,6 +486,8 @@ def _per_repo_snapshot(repo: str) -> dict:
     return {
         "active_task": active_task,
         "waiting": waiting,
+        # ORCH-124 (D5): additive — parked predecessors (not shown as active_task).
+        "paused": paused,
         "frozen": frozen,
         "frozen_reason": frozen_reason,
         "frozen_at": frozen_at,

src/stage_engine.py

@@ -30,7 +30,7 @@ import os
 import time
 from dataclasses import dataclass, field
 
-from .db import get_db, update_task_stage, enqueue_job, get_task_track
+from .db import get_db, update_task_stage, enqueue_job, get_task_track, set_task_paused
 from .stages import get_next_stage, get_qg_for_stage, get_agent_for_stage
 from .git_worktree import get_worktree_path
 from .review_parse import extract_review_findings, extract_test_failures
@@ -42,6 +42,7 @@ from . import post_deploy
 from . import labels
 from . import bug_fast_track
 from . import transition_lease
+from . import analyst_questions
 from .notifications import (
     notify_stage_change,
     notify_qg_failure,
@@ -708,84 +709,195 @@ def _handle_analysis_approved_flow(
         return
 
     files_ok, _ = files_check(repo, work_item_id, branch)
-    if files_ok:
-        # Full artifacts ready -> In Review, ask for the Approved STATUS (BUG C).
-        set_issue_in_review(work_item_id)
-        plane_add_comment(
-            work_item_id,
-            # task_id is threaded through so build_status_comment can resolve the
-            # analyst duration via agent_runs (ORCH-016 AC-14 DB fallback).
-            _build_analyst_ready_comment(repo, work_item_id, branch, task_id=task_id),
-            author="analyst",
-        )
-        notify_approve_requested(task_id)
-        result.note = "analysis-in-review"
-        logger.info(
-            f"Task {task_id}: analyst finished, requested Approved status in Plane"
-        )
 
-        # --- ORCH-089 autoApprove: auto-pass the BRD human gate by label --------
-        # After In Review + the analyst comment + the approve-request (kept for the
-        # BRD-review clock, transparency and symmetry with the manual path), if the
-        # issue carries the autoApprove label AND the repo is in scope, auto-advance
-        # via the SAME path a human Approved takes — never duplicating the
-        # transition logic. applies() (local, network-free) is checked FIRST so a
-        # disabled kill-switch / out-of-scope repo costs zero network (AC-8); any
-        # error / no-label -> fall through to the prior behaviour (return, wait for
-        # a human, AC-4/AC-6).
-        if labels.auto_approve_applies(repo) and labels.has_label(
-            work_item_id, settings.auto_approve_label
-        ):
-            set_issue_approved(work_item_id)  # indication (AC-1), transient
-            logger.info(
-                f"Task {task_id}: label {settings.auto_approve_label} -> "
-                f"BRD auto-approved (analysis -> architecture)"
-            )
-            plane_add_comment(
-                work_item_id,
-                f"✅ BRD авто-подтверждён (лейбл {settings.auto_approve_label}). "
-                "Переход на architecture без ручного Approved.",
-                author="analyst",
-            )
-            send_telegram(
-                f"✅ {link_for(work_item_id)}: BRD авто-подтверждён "
-                f"(лейбл {settings.auto_approve_label})."
-            )
-            # Same advance the human Approved webhook uses: finished_agent=None ->
-            # check_analysis_approved approved-via-status -> advance analysis ->
-            # architecture + mark_brd_review_ended (clock) + standard post-effects.
-            # Re-entrancy is safe: the nested call passes finished_agent=None, so it
-            # does NOT re-enter this analyst branch (which requires agent=='analyst').
-            auto = advance_stage(
-                task_id, current_stage, repo, work_item_id, branch, finished_agent=None
-            )
-            result.advanced = auto.advanced
-            result.to_stage = auto.to_stage
-            result.enqueued_agent = auto.enqueued_agent
-            result.enqueued_job_id = auto.enqueued_job_id
-            result.note = "auto-approved-via-label"
+    # ORCH-120 (adr-0053 D3): decide the analyst outcome — 'needs-input' |
+    # 'in-review' | 'empty'. When the questions-gate applies, ACTIVE blocking
+    # questions (01-questions.md, freshness-supersede aware, D2) take PRIORITY over
+    # "files ready" (a fabricated full package must not bury the analyst's blocking
+    # questions, AC-1). Under the kill-switch off / out-of-scope repo the ORIGINAL
+    # pre-ORCH-120 order runs byte-for-byte (files_ok first, then a flat
+    # isfile(01-questions.md) check) — zero regression (AC-9). never-raise (AC-10):
+    # on any error the decision degrades to that original order.
+    outcome = _decide_analysis_outcome(repo, work_item_id, branch, files_ok)
+    if outcome == "needs-input":
+        _emit_analysis_needs_input(task_id, repo, work_item_id, branch, result)
         return
+    if outcome == "in-review":
+        _emit_analysis_in_review(
+            task_id, current_stage, repo, work_item_id, branch, result
+        )
+        return
+    _emit_analysis_empty(work_item_id, result)
 
-    questions_path = os.path.join(
-        get_worktree_path(repo, branch),
-        f"docs/work-items/{work_item_id}/01-questions.md",
+
+def _decide_analysis_outcome(repo, work_item_id, branch, files_ok) -> str:
+    """ORCH-120 (adr-0053 D3): 3-way decision for the analyst outcome.
+
+    Returns ``'needs-input'`` | ``'in-review'`` | ``'empty'``. never-raise (AC-10):
+    on any error degrade to the ORIGINAL pre-ORCH-120 order so behaviour is
+    byte-for-byte the same when the gate is off / out of scope.
+    """
+    try:
+        worktree = get_worktree_path(repo, branch)
+    except Exception:  # noqa: BLE001 - never-raise; treat as no worktree
+        worktree = ""
+
+    # Questions-gate ON: blocking questions take priority over files_ok (D3).
+    try:
+        gate_on = analyst_questions.questions_gate_applies(repo)
+    except Exception:  # noqa: BLE001
+        gate_on = False
+    if gate_on:
+        active = None  # None == predicate could not decide -> degrade below
+        try:
+            active = analyst_questions.questions_active(
+                worktree, work_item_id, files_ok
+            )
+        except Exception as e:  # noqa: BLE001 - never-raise; degrade to original order
+            logger.warning(
+                f"questions_active failed for {work_item_id} -> "
+                f"degrade to original order: {e}"
+            )
+            active = None
+        if active is True:
+            return "needs-input"
+        if active is False:
+            return "in-review" if files_ok else "empty"
+        # active is None: predicate degraded -> fall through to the ORIGINAL order.
+
+    # Kill-switch off / out-of-scope / degraded: ORIGINAL byte-for-byte order
+    # (files_ok first, then a flat isfile(01-questions.md) check).
+    if files_ok:
+        return "in-review"
+    try:
+        questions_path = os.path.join(
+            worktree, f"docs/work-items/{work_item_id}/01-questions.md"
+        )
+        if worktree and os.path.isfile(questions_path):
+            return "needs-input"
+    except Exception:  # noqa: BLE001 - never-raise
+        pass
+    return "empty"
+
+
+def _emit_analysis_in_review(
+    task_id, current_stage, repo, work_item_id, branch, result: AdvanceResult
+):
+    """Full artifacts ready -> In Review + request the Approved STATUS (BUG C).
+
+    Carries the ORCH-089 autoApprove insertion verbatim. Extracted from
+    ``_handle_analysis_approved_flow`` by ORCH-120 (D3) so the questions-priority
+    decision can dispatch here without changing this branch's behaviour.
+    """
+    # Full artifacts ready -> In Review, ask for the Approved STATUS (BUG C).
+    set_issue_in_review(work_item_id)
+    plane_add_comment(
+        work_item_id,
+        # task_id is threaded through so build_status_comment can resolve the
+        # analyst duration via agent_runs (ORCH-016 AC-14 DB fallback).
+        _build_analyst_ready_comment(repo, work_item_id, branch, task_id=task_id),
+        author="analyst",
     )
-    if os.path.isfile(questions_path):
-        set_issue_needs_input(work_item_id)
-        with open(questions_path, "r") as qf:
-            questions_text = qf.read()
+    notify_approve_requested(task_id)
+    result.note = "analysis-in-review"
+    logger.info(
+        f"Task {task_id}: analyst finished, requested Approved status in Plane"
+    )
+
+    # --- ORCH-089 autoApprove: auto-pass the BRD human gate by label --------
+    # After In Review + the analyst comment + the approve-request (kept for the
+    # BRD-review clock, transparency and symmetry with the manual path), if the
+    # issue carries the autoApprove label AND the repo is in scope, auto-advance
+    # via the SAME path a human Approved takes — never duplicating the
+    # transition logic. applies() (local, network-free) is checked FIRST so a
+    # disabled kill-switch / out-of-scope repo costs zero network (AC-8); any
+    # error / no-label -> fall through to the prior behaviour (return, wait for
+    # a human, AC-4/AC-6).
+    if labels.auto_approve_applies(repo) and labels.has_label(
+        work_item_id, settings.auto_approve_label
+    ):
+        set_issue_approved(work_item_id)  # indication (AC-1), transient
+        logger.info(
+            f"Task {task_id}: label {settings.auto_approve_label} -> "
+            f"BRD auto-approved (analysis -> architecture)"
+        )
         plane_add_comment(
             work_item_id,
-            f"\u2753 Analyst \u043d\u0443\u0436\u0434\u0430\u0435\u0442\u0441\u044f \u0432 \u0443\u0442\u043e\u0447\u043d\u0435\u043d\u0438\u0438:\n\n{questions_text}",
+            f"✅ BRD авто-подтверждён (лейбл {settings.auto_approve_label}). "
+            "Переход на architecture без ручного Approved.",
             author="analyst",
         )
         send_telegram(
-            f"\u2753 {link_for(work_item_id)}: Analyst \u0437\u0430\u0434\u0430\u0451\u0442 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u041e\u0442\u0432\u0435\u0442\u044c \u0432 Plane."
+            f"✅ {link_for(work_item_id)}: BRD авто-подтверждён "
+            f"(лейбл {settings.auto_approve_label})."
         )
-        result.note = "analysis-needs-input"
-        return
+        # Same advance the human Approved webhook uses: finished_agent=None ->
+        # check_analysis_approved approved-via-status -> advance analysis ->
+        # architecture + mark_brd_review_ended (clock) + standard post-effects.
+        # Re-entrancy is safe: the nested call passes finished_agent=None, so it
+        # does NOT re-enter this analyst branch (which requires agent=='analyst').
+        auto = advance_stage(
+            task_id, current_stage, repo, work_item_id, branch, finished_agent=None
+        )
+        result.advanced = auto.advanced
+        result.to_stage = auto.to_stage
+        result.enqueued_agent = auto.enqueued_agent
+        result.enqueued_job_id = auto.enqueued_job_id
+        result.note = "auto-approved-via-label"
 
-    # No artifacts and no questions.
+
+def _emit_analysis_needs_input(
+    task_id, repo, work_item_id, branch, result: AdvanceResult
+):
+    """Blocking questions -> Needs Input + Plane comment + Telegram + auto-park.
+
+    The Plane comment / Telegram are preserved verbatim from the original
+    ``_handle_analysis_approved_flow`` questions branch. ORCH-120 (D4) adds the
+    auto-park: when ``autopause_applies(repo)`` the task is parked
+    (``db.set_task_paused``) so the repo's serial-gate FIFO is not wedged while we
+    wait for a human (BR-3 / AC-4). never-raise (AC-10): a file-read or park error
+    degrades safely and never crashes ``advance_stage``.
+    """
+    set_issue_needs_input(work_item_id)
+    questions_text = ""
+    try:
+        questions_path = os.path.join(
+            get_worktree_path(repo, branch),
+            f"docs/work-items/{work_item_id}/01-questions.md",
+        )
+        with open(questions_path, "r") as qf:
+            questions_text = qf.read()
+    except Exception as e:  # noqa: BLE001 - never-raise; comment without body
+        logger.warning(
+            f"Task {task_id}: could not read 01-questions.md for {work_item_id}: {e}"
+        )
+    plane_add_comment(
+        work_item_id,
+        f"❓ Analyst нуждается в уточнении:\n\n{questions_text}",
+        author="analyst",
+    )
+    send_telegram(
+        f"❓ {link_for(work_item_id)}: Analyst задаёт вопросы. Ответь в Plane."
+    )
+    # ORCH-120 (D4): auto-park via the ORCH-124 pause axis so the parked task stops
+    # holding the repo serial-gate FIFO. autopause_applies() is gated by the
+    # questions gate, so a kill-switch-off / out-of-scope repo never parks (AC-9).
+    # set_task_paused is already never-raise (-> False); the extra guard keeps a
+    # surprise from crashing advance_stage (AC-10). Park failure does NOT undo the
+    # Needs Input transition (degrades to operator-park, DQ-1).
+    try:
+        if analyst_questions.autopause_applies(repo) and set_task_paused(task_id):
+            logger.info(
+                f"Task {task_id}: auto-parked on Needs Input "
+                f"(serial-gate FIFO freed for {repo})"
+            )
+    except Exception as e:  # noqa: BLE001 - never-raise
+        logger.warning(f"Task {task_id}: auto-park on Needs Input failed: {e}")
+    result.note = "analysis-needs-input"
+
+
+def _emit_analysis_empty(work_item_id, result: AdvanceResult):
+    """No artifacts and no questions — a warning comment (verbatim original)."""
     plane_add_comment(
         work_item_id,
         "\u26a0\ufe0f Analyst \u0437\u0430\u0432\u0435\u0440\u0448\u0438\u043b\u0441\u044f \u0431\u0435\u0437 \u0430\u0440\u0442\u0435\u0444\u0430\u043a\u0442\u043e\u0432 \u0438 \u0431\u0435\u0437 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432. \u041f\u0440\u043e\u0432\u0435\u0440\u044c\u0442\u0435 \u043b\u043e\u0433.",

src/webhooks/plane.py

@@ -355,6 +355,26 @@ async def handle_status_start(data: dict, project_id: str = ""):
             logger.error(f"Failed to post relaunch-hole comment for {work_item_id}: {e}")
         return
 
+    # ORCH-120 (adr-0053 D5): resume + unpark. The analyst (the sole Needs-Input
+    # owner, ORCH-066) was auto-parked on Needs Input (D4) so the repo serial-gate
+    # FIFO would not wedge while we waited for the stakeholder. Now that they
+    # answered and returned the issue to a working status, clear the pause so the
+    # re-enqueued analyst-job is claimable (jointly with the ORCH-126 stale
+    # run_id/pid fix). Gated on `analysis` + autopause_applies (questions gate +
+    # scope) so off/out-of-scope is byte-for-byte unchanged (AC-9); idempotent and
+    # never-raise — a resume that was never parked is a no-op.
+    if current_stage == "analysis":
+        try:
+            from .. import analyst_questions
+            from ..db import clear_task_paused
+            if analyst_questions.autopause_applies(repo) and clear_task_paused(task_id):
+                logger.info(
+                    f"Task {task_id}: unparked on analyst resume "
+                    f"(serial-gate FIFO re-entered for {repo})"
+                )
+        except Exception as e:  # noqa: BLE001 - never-raise: resume must not crash
+            logger.warning(f"Task {task_id}: unpark on resume failed: {e}")
+
     task_desc = (
         f"Work item: {work_item_id}\nRepo: {repo}\nBranch: {branch}\n"
         f"Stage: {current_stage}\nNote: Stakeholder returned the issue to In "
@@ -637,8 +657,12 @@ async def start_pipeline(data: dict, project_id: str = ""):
     # process-wide lock. If the F-2 reconciler and this live webhook race on the
     # same plane_id, exactly one wins (created=True); the loser sees the existing
     # task and returns WITHOUT creating a second branch / worktree / analyst job.
+    # ORCH-119 (FR-3 / AC-3): persist `description` DURABLE inside the same atomic
+    # INSERT (mirror of `title`) so the deferred branch cut (path B, ORCH-088 — dominates
+    # on self-hosting) can read it from the tasks row at claim time and render the real
+    # request text into 00-business-request.md instead of the hardcoded `TBD`.
     task_row, created = create_task_atomic(
-        plane_id, work_item_id, repo, branch, "analysis", name
+        plane_id, work_item_id, repo, branch, "analysis", name, description
     )
     if not created:
         logger.info(
@@ -706,8 +730,10 @@ async def start_pipeline(data: dict, project_id: str = ""):
             return
 
         # Create initial docs structure via Gitea API (create file)
+        # ORCH-119 (FR-2 / AC-2): direct path A — pass the source-backed `description`
+        # so the artifact is created with the real request text in one call.
         try:
-            await _create_initial_docs(repo, branch, work_item_id, name)
+            await _create_initial_docs(repo, branch, work_item_id, name, description)
         except Exception as e:
             logger.error(f"Failed to create initial docs: {e}")
     else:
@@ -914,15 +940,59 @@ async def _create_gitea_branch(repo: str, branch: str):
         logger.info(f"Created branch '{branch}' in {owner}/{repo}")
 
 
-async def _create_initial_docs(repo: str, branch: str, work_item_id: str, name: str):
-    """Create initial business request doc in the feature branch."""
+# ORCH-119 (FR-4 / AC-4): explicit safe marker used when the source description is
+# empty / whitespace / None / unreadable — NOT the historic bare `TBD` bug.
+_BUSINESS_REQUEST_FALLBACK = "_(описание отсутствует в источнике)_"
+
+
+def _render_business_request(
+    work_item_id: str, name: str, description: str | None
+) -> str:
+    """ORCH-119 (FR-1 / BR-1): render the body of ``00-business-request.md`` from the
+    source-backed Plane-issue ``description``.
+
+    Pure & network-free so it is unit-testable without Gitea (TC-01/TC-02/TC-06). The
+    Description section carries the ACTUAL request text plain-text and verbatim —
+    multi-line content and markdown special chars are preserved (the doc is
+    informational and NOT gate-parsed, NFR-2); only surrounding whitespace is trimmed
+    for the emptiness check. Empty / whitespace / None / any failure degrades to an
+    explicit safe marker (``_BUSINESS_REQUEST_FALLBACK``) instead of the historic bare
+    ``TBD`` (FR-4 / AC-4); never raises. The header (``# Business Request: {name}``)
+    and ``Work Item ID`` are unchanged.
+    """
+    try:
+        body = (description or "").strip()
+        if not body:
+            body = _BUSINESS_REQUEST_FALLBACK
+    except Exception:  # noqa: BLE001 - never let rendering break task creation
+        body = _BUSINESS_REQUEST_FALLBACK
+    return (
+        f"# Business Request: {name}\n\n"
+        f"Work Item ID: {work_item_id}\n\n"
+        f"## Description\n\n{body}\n"
+    )
+
+
+async def _create_initial_docs(
+    repo: str, branch: str, work_item_id: str, name: str,
+    description: str | None = None,
+):
+    """Create initial business request doc in the feature branch.
+
+    ORCH-119: the Description section now carries the source-backed Plane-issue
+    ``description`` (rendered via ``_render_business_request``) instead of the historic
+    hardcoded ``TBD``. ``description`` is additive with a default so existing callers /
+    a re-claim stay backward-compatible; empty/None degrades to a safe marker.
+    Idempotent: Gitea 422 (file already exists) -> no-op, the previously written body
+    is NOT overwritten (AC-6 / TC-06).
+    """
     owner = settings.gitea_owner
     file_path = f"docs/work-items/{work_item_id}/00-business-request.md"
     url = f"{settings.gitea_url}/api/v1/repos/{owner}/{repo}/contents/{file_path}"
     headers = {"Authorization": f"token {settings.gitea_token}"}
 
     import base64
-    content = f"# Business Request: {name}\n\nWork Item ID: {work_item_id}\n\n## Description\n\nTBD\n"
+    content = _render_business_request(work_item_id, name, description)
     encoded = base64.b64encode(content.encode()).decode()
 
     payload = {

tests/test_agent_prompts_canon.py

@@ -282,6 +282,27 @@ def test_reviewer_carries_overview_docs_axis():
     )
 
 
+def test_orch120_analyst_documents_questions_channel():
+    """ORCH-120 (adr-0053) TC-07 (AC-7): analyst.md documents the 01-questions.md
+    Needs-Input channel (blocking questions -> Needs Input, do NOT fabricate
+    deliverables) without breaking the 52d canon (guarded by the canon tests above).
+
+    Anchored explicitly so a future prompt refactor cannot silently drop the
+    working contract (the same anti-drift rationale as the traceability axis)."""
+    text = _read("analyst")
+    assert "01-questions.md" in text, (
+        "analyst.md does not document the 01-questions.md Needs-Input channel"
+    )
+    assert "Needs Input" in text, (
+        "analyst.md does not tie 01-questions.md to the Needs Input outcome"
+    )
+    # Must instruct NOT to fabricate deliverables (the core BR-1 contract).
+    assert "фабрик" in text, (
+        "analyst.md does not carry the 'do not fabricate deliverables' instruction"
+    )
+    assert "ORCH-120" in text, "analyst.md does not anchor the questions channel to ORCH-120"
+
+
 def test_reviewer_overview_axis_covers_system_showcase():
     """ORCH-011 (ADR-001 D7): the ORCH-079 overview-docs axis explicitly extends
     to the system showcase `docs/overview/` — a PR changing functionality described

tests/test_faq_stop_doc.py

@@ -0,0 +1,291 @@
+"""ORCH-108 (FR-6 / AC-1…AC-11): анти-дрейф контур пользовательского FAQ по STOP.
+
+Структурные проверки golden source `docs/operations/FAQ_STOP.md` (ADR-001 D3,
+образец — `tests/test_lite_setup_doc.py`): док существует и адресован пользователю
+(TC-01); присутствуют все 8 обязательных секций-якорей FR-2 (TC-02); несёт ключевые
+факты-«кирпичи» о последствиях STOP (TC-03), об отложенной отмене (TC-04), о том что
+STOP не откатывает прод-код (TC-05) и о перезапуске через «To Analyse» с нуля (TC-06);
+негативный скан запрещённых **утверждений** на уровне предложений, а НЕ голых подстрок
+(TC-07, ключевой нюанс D3 — иначе тест краснел бы на корректно отрицающих фразах);
+двусторонние перекрёстные ссылки витрина/обзор ⇄ FAQ ⇄ ADR ORCH-090 (TC-08);
+docs-only / детерминированность самого теста — без сети/LLM/subprocess (TC-09).
+
+Детерминировано: только парсинг файлов (read_text), без сети/LLM/subprocess.
+Поведение STOP в рантайме реализовано и протестировано в ORCH-090 — эта задача его
+НЕ меняет (docs-only), здесь проверяется лишь структурная целостность документации.
+"""
+
+import re
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+FAQ = REPO_ROOT / "docs/operations/FAQ_STOP.md"
+BUSINESS = REPO_ROOT / "docs/overview/business.md"
+TECH_PIPELINE = REPO_ROOT / "docs/overview/tech-pipeline.md"
+
+# Обязательные секции FR-2: распознаваемая (нормализованная, регистронезависимая)
+# подстрока заголовка `## ` — стабильный якорь, толерантный к полировке пунктуации.
+SECTION_ANCHORS: tuple[str, ...] = (
+    "что делает статус stop",                       # (1) назначение
+    "как отменить задачу",                          # (2) как отменить
+    "что происходит, когда я нажимаю stop",         # (3) пошагово
+    "сливается или деплоится",                      # (4) отложенная отмена
+    "откатит ли stop уже выложенный код",           # (5) не откатывает прод
+    "как перезапустить отменённую задачу",          # (6) перезапуск с нуля
+    "ничего не произошло",                          # (7) no-op причины
+    "где увидеть, что задача отменена",             # (8) где увидеть результат
+)
+
+
+# ---------------------------------------------------------------------------
+# helpers
+# ---------------------------------------------------------------------------
+def _faq_text() -> str:
+    assert FAQ.is_file(), "docs/operations/FAQ_STOP.md отсутствует (AC-1)"
+    text = FAQ.read_text(encoding="utf-8")
+    assert text.strip(), "FAQ_STOP.md пуст (AC-1)"
+    return text
+
+
+def _headers() -> list[str]:
+    """Нормализованные (lowercase) тексты markdown-заголовков `#`/`##`/…."""
+    return [
+        re.sub(r"^#+\s*", "", line).strip().lower()
+        for line in _faq_text().splitlines()
+        if line.lstrip().startswith("#")
+    ]
+
+
+def _body_sentences() -> list[str]:
+    """Предложения тела FAQ БЕЗ заголовков и без code-fence-блоков.
+
+    Заголовки этого FAQ — вопросы («Откатит ли STOP…?», «Что если…?») и по
+    построению не несут утверждений; негативный скан утверждений (TC-07)
+    исключает их, чтобы не краснеть на легитимных вопросах-якорях (D3/TR-3).
+    """
+    lines: list[str] = []
+    in_fence = False
+    for raw in _faq_text().splitlines():
+        stripped = raw.strip()
+        if stripped.startswith("```"):
+            in_fence = not in_fence
+            continue
+        if in_fence or stripped.startswith("#"):
+            continue
+        lines.append(raw)
+    body = " ".join(lines)
+    return [s.strip().lower() for s in re.split(r"[.!?\n]+", body) if s.strip()]
+
+
+_NEGATION = re.compile(r"\b(?:не|нет|никогда|нельзя|без)\b", re.IGNORECASE)
+
+# Опасные claim-триггеры (D3): ЕСЛИ предложение тела матчит триггер, оно ОБЯЗАНО
+# нести отрицание рядом, иначе это запрещённое FR-5 утверждение. Скан на уровне
+# предложений-утверждений, НЕ голых подстрок (заголовки-вопросы исключены).
+_CLAIM_TRIGGERS: tuple[tuple[str, re.Pattern[str]], ...] = (
+    # «STOP откатывает прод/влитый код» — должно встречаться только с отрицанием.
+    ("откат прод-кода", re.compile(r"откат\w*", re.IGNORECASE)),
+    # «можно продолжить отменённую с середины».
+    ("продолжить с середины", re.compile(r"продолж\w*[^.]{0,40}середин", re.IGNORECASE)),
+    # «STOP трогает main / делает force-push».
+    ("трогает main / force-push", re.compile(r"трога\w*|force[\s-]?push", re.IGNORECASE)),
+    # «STOP мгновенно убивает/прерывает идущий деплой/слияние».
+    (
+        "мгновенно убивает деплой",
+        re.compile(r"(?:мгновенн|немедленн)\w*[^.]{0,40}(?:убива|прерыва|деплой|слиян|выклад)", re.IGNORECASE),
+    ),
+)
+
+
+def _forbidden_claim_violations(sentences: list[str]) -> list[str]:
+    """Предложения, которые делают запрещённое утверждение без отрицания рядом."""
+    violations: list[str] = []
+    for name, trigger in _CLAIM_TRIGGERS:
+        for sent in sentences:
+            if trigger.search(sent) and not _NEGATION.search(sent):
+                violations.append(f"[{name}] {sent[:120]}")
+    return violations
+
+
+# ---------------------------------------------------------------------------
+# TC-01: FAQ существует, непустой, адресован пользователю (AC-1).
+# ---------------------------------------------------------------------------
+def test_faq_exists_user_oriented_with_h1():
+    text = _faq_text()
+    headers = _headers()
+    assert headers, "в FAQ_STOP.md нет ни одного заголовка"
+    assert "stop" in headers[0], f"H1 FAQ не про STOP: {headers[0]!r} (AC-1)"
+    # Вводный абзац «для кого/зачем» (тон пользовательский, без требования читать код).
+    intro = text.split("\n##", 1)[0].lower()
+    assert "для пользователя доски plane" in intro, (
+        "нет вводного абзаца «для кого» (AC-1) — FAQ должен адресоваться пользователю"
+    )
+    assert "не нужно" in intro and "код" in intro, (
+        "вводный абзац не фиксирует пользовательский тон «читать код не нужно» (AC-1)"
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-02: присутствуют все 8 обязательных секций-якорей FR-2 (AC-2).
+# ---------------------------------------------------------------------------
+def test_all_mandatory_sections_present():
+    headers_blob = " || ".join(_headers())
+    missing = [a for a in SECTION_ANCHORS if a not in headers_blob]
+    assert not missing, f"в FAQ_STOP.md отсутствуют обязательные секции FR-2 (AC-2): {missing}"
+
+
+# ---------------------------------------------------------------------------
+# TC-03: пошаговые последствия и сохранность docs (AC-3).
+# ---------------------------------------------------------------------------
+def test_step_consequences_and_docs_preserved():
+    low = _faq_text().lower()
+    bricks = {
+        "остановка агента": "останав",
+        "снятие job'ов": "job",
+        "удаление рабочей ветки": "ветк",
+        "удаление worktree": "worktree",
+        "переход в cancelled": "cancelled",
+        "уведомление telegram": "telegram",
+        "комментарий plane": "plane",
+        "docs сохраняются": "сохран",
+        "main/прод не трогаются": "main",
+    }
+    missing = [name for name, token in bricks.items() if token not in low]
+    assert not missing, f"раздел «что происходит» не несёт фактов (AC-3): {missing}"
+
+
+# ---------------------------------------------------------------------------
+# TC-04: критичное окно — отложенная отмена + main/прод не трогаются (AC-4).
+# ---------------------------------------------------------------------------
+def test_deferred_cancel_in_critical_window():
+    low = _faq_text().lower()
+    assert "отлож" in low, "нет факта отложенной отмены в критичном окне (AC-4)"
+    # «main/прод не трогаются» — явное отрицание рядом с критичным окном.
+    assert "не трогают" in low or "не трогаются" in low, (
+        "нет явного «main/прод не трогаются» (AC-4)"
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-05: STOP ≠ откат прод-кода — явный отрицательный ответ (AC-5).
+# ---------------------------------------------------------------------------
+def test_stop_does_not_revert_prod():
+    low = _faq_text().lower()
+    assert "не откатывает" in low, "нет явного «не откатывает» прод/влитый код (AC-5)"
+    assert "revert" in low or "отдельная задача" in low, (
+        "не сказано, что revert выложенного — отдельная задача (AC-5)"
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-06: перезапуск — «To Analyse» с нуля, без «продолжить с середины» (AC-6).
+# ---------------------------------------------------------------------------
+def test_restart_via_to_analyse_from_scratch():
+    text = _faq_text()
+    low = text.lower()
+    assert "to analyse" in low, "перезапуск не через «To Analyse» (AC-6)"
+    assert "с нуля" in low, "не сказано, что задача создаётся «с нуля» (AC-6)"
+    # «продолжить с середины» допустимо только в отрицающем предложении.
+    for sent in _body_sentences():
+        if "продолж" in sent and "середин" in sent:
+            assert _NEGATION.search(sent), (
+                f"обещание продолжить отменённую задачу с середины (AC-6): {sent[:120]!r}"
+            )
+
+
+# ---------------------------------------------------------------------------
+# TC-07a: «ничего не произошло» и идемпотентность — причины no-op (AC-7).
+# ---------------------------------------------------------------------------
+def test_noop_reasons_present():
+    low = _faq_text().lower()
+    assert "stop_status_enabled" in low and "stop_status_repos" in low, (
+        "не перечислены настройки отключения отмены (AC-7)"
+    )
+    assert "уже" in low and ("заверш" in low or "отмен" in low), (
+        "не описан идемпотентный no-op для уже терминальной задачи (AC-7)"
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-07b: негативный скан запрещённых утверждений (claim-level, не подстроки).
+# Инвариант D3: НЕ фолзит на верном FAQ; обязан краснеть на реально ложном (AC-9).
+# ---------------------------------------------------------------------------
+def test_no_forbidden_claims_in_real_faq():
+    violations = _forbidden_claim_violations(_body_sentences())
+    assert not violations, (
+        "FAQ_STOP.md содержит запрещённые FR-5 утверждения без отрицания (AC-9):\n"
+        + "\n".join(violations)
+    )
+
+
+def test_forbidden_claim_scanner_is_not_evergreen():
+    """Подсаженные ложные утверждения ОБЯЗАНЫ ловиться (паттерн ORCH-101/102:
+    сканер не может молча стать вечнозелёным). Зеркало
+    test_secret_heuristic_is_not_evergreen из test_lite_setup_doc.py."""
+    bad = [
+        "stop откатывает уже выложенный в прод код автоматически",
+        "отменённую задачу можно продолжить с середины конвейера",
+        "stop делает force-push в main для зачистки",
+        "stop мгновенно убивает идущий деплой на полпути",
+    ]
+    caught = _forbidden_claim_violations(bad)
+    assert len(caught) >= 4, f"сканер не ловит подсаженные ложные утверждения: {caught}"
+
+    # И обратно: корректные ОТРИЦАЮЩИЕ предложения НЕ должны ловиться (анти-TR-3).
+    good = [
+        "stop не откатывает код, уже влитый в main или выложенный в прод",
+        "отменённую задачу нельзя продолжить с середины",
+        "ветка main и прод никогда не трогаются",
+    ]
+    assert _forbidden_claim_violations(good) == [], (
+        "сканер ложно краснеет на корректно отрицающих предложениях (TR-3)"
+    )
+
+
+# ---------------------------------------------------------------------------
+# TC-08: двусторонние перекрёстные ссылки витрина/обзор ⇄ FAQ ⇄ ADR (AC-8).
+# ---------------------------------------------------------------------------
+def test_overview_docs_link_to_faq():
+    assert "FAQ_STOP.md" in BUSINESS.read_text(encoding="utf-8"), (
+        "docs/overview/business.md (Сценарий 6) не ссылается на FAQ_STOP.md (AC-8)"
+    )
+    assert "FAQ_STOP.md" in TECH_PIPELINE.read_text(encoding="utf-8"), (
+        "docs/overview/tech-pipeline.md (Отмена: STOP → cancelled) не ссылается на FAQ_STOP.md (AC-8)"
+    )
+
+
+def test_faq_links_back_to_overview_and_adr():
+    text = _faq_text()
+    assert "tech-pipeline.md" in text, "FAQ не ссылается на инженерный обзор (AC-8)"
+    assert "ORCH-090" in text and "ADR-001-stop-cancel-task.md" in text, (
+        "FAQ не ссылается на ADR ORCH-090 как источник истины (AC-8)"
+    )
+    # link-first: машинные детали не дублируются (даются ссылкой), а не копируются.
+    low = text.lower()
+    for machine_detail in ("тумбстон", "merge-lease", "_ensure_column"):
+        assert machine_detail not in low, (
+            f"FAQ дублирует машинную деталь {machine_detail!r} вместо ссылки (AC-8/D4)"
+        )
+
+
+# ---------------------------------------------------------------------------
+# TC-09: детерминированность самого теста — docs-only, без сети/LLM/subprocess.
+# ---------------------------------------------------------------------------
+def test_this_module_is_deterministic_offline():
+    """Самочек контракта D3: тест-модуль не импортирует сеть/subprocess/LLM и не
+    тянет рантайм src/ — читает только файлы docs/ (AC-10, AC-11)."""
+    # Скан реальных import-стейтментов по началу строки (а не подстрок — иначе
+    # тест ловил бы собственные строковые литералы из этого же списка).
+    banned = ("subprocess", "socket", "requests", "httpx", "urllib")
+    offenders: list[str] = []
+    for line in Path(__file__).read_text(encoding="utf-8").splitlines():
+        stripped = line.strip()
+        if not (stripped.startswith("import ") or stripped.startswith("from ")):
+            continue
+        module = stripped.split()[1].split(".", 1)[0]
+        if module in banned or module == "src":
+            offenders.append(stripped)
+    assert not offenders, (
+        f"анти-дрейф тест FAQ нарушает контракт детерминированности (сеть/subprocess/"
+        f"рантайм src): {offenders}"
+    )

tests/test_orch119_business_request.py

@@ -0,0 +1,263 @@
+"""ORCH-119: source-backed ``00-business-request.md`` (fix the hardcoded ``TBD``).
+
+The Description section of ``00-business-request.md`` must carry the ACTUAL Plane-issue
+``description`` instead of the historic hardcoded literal ``TBD``. Because the
+self-hosting ``orchestrator`` repo cuts its branch lazily at analyst-job claim (the
+deferred path B, ORCH-088), the description must be DURABLE-persisted on the ``tasks``
+row at creation time (mirror of ``tasks.title``) so it survives the gap between task
+creation and claim.
+
+These tests are network-free: the Gitea ``contents`` POST (httpx) and the deferred
+branch-cut coroutines are mocked; ``create_task_atomic`` runs against a real isolated
+SQLite DB. Mapping to ``04-test-plan.yaml``:
+
+  * TC-01 — MANDATORY regression: render contains the real description, not ``TBD``.
+  * TC-02 — fallback: empty/whitespace/None -> explicit safe marker, never raises.
+  * TC-03 — deferred path B: description persisted + rendered at materialisation.
+  * TC-04 — direct path A: ``_create_initial_docs`` writes the real description.
+  * TC-05 — schema backward-compat: ``_ensure_column`` is additive + idempotent.
+  * TC-06 — data integrity: multi-line markdown preserved; Gitea 422 -> no-op.
+  * TC-07 — anti-regression: gates / STAGE_TRANSITIONS / QG_CHECKS unchanged.
+"""
+
+import asyncio
+import base64
+import os
+import tempfile
+from types import SimpleNamespace
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch119_business_request.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db, create_task_atomic  # noqa: E402
+from src.webhooks import plane  # noqa: E402
+
+
+@pytest.fixture(autouse=True)
+def fresh_db(monkeypatch):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    yield
+
+
+# ---------------------------------------------------------------------------
+# TC-01 (MANDATORY regression): the rendered body carries the real request
+#        text, NOT the historic hardcoded ``TBD``. Red before the fix
+#        (``_render_business_request`` did not exist / body was ``TBD``).
+# ---------------------------------------------------------------------------
+def test_tc01_render_contains_real_description():
+    desc = "Users need source-backed business requests captured from the Plane issue."
+    out = plane._render_business_request("ORCH-119", "Source-backed request", desc)
+
+    # The real request text reaches the artifact body...
+    assert desc in out
+    # ...the header / Work Item ID are still present (unchanged contract)...
+    assert "# Business Request: Source-backed request" in out
+    assert "Work Item ID: ORCH-119" in out
+    # ...and the Description body is NOT the bare ``TBD`` bug.
+    body = out.split("## Description", 1)[1]
+    assert "TBD" not in body
+
+
+# ---------------------------------------------------------------------------
+# TC-02 (fallback): empty / whitespace / None description -> explicit safe
+#        marker (never the bare ``TBD`` bug), and the renderer never raises.
+# ---------------------------------------------------------------------------
+@pytest.mark.parametrize("desc", ["", "   ", "\n\t  \n", None])
+def test_tc02_fallback_marker_no_raise(desc):
+    out = plane._render_business_request("ORCH-119", "Name", desc)
+    assert "описание отсутствует в источнике" in out
+    body = out.split("## Description", 1)[1]
+    assert "TBD" not in body
+
+
+# ---------------------------------------------------------------------------
+# TC-03 (deferred path B / self-hosting): description is persisted DURABLE on
+#        the tasks row at creation and rendered into the artifact when the
+#        deferred branch is materialised at claim (launcher).
+# ---------------------------------------------------------------------------
+def test_tc03_deferred_path_persists_and_renders(monkeypatch):
+    desc = "A durable source-backed description for the deferred path B (claim-time cut)."
+    row, created = create_task_atomic(
+        "plane-b", "ORCH-201", "orchestrator",
+        "feature/ORCH-201-x", "analysis", "Title B", desc,
+    )
+    assert created
+
+    # Durable: description survives in the tasks row (readable without the network).
+    got = get_db().execute(
+        "SELECT description FROM tasks WHERE id=?", (row["id"],)
+    ).fetchone()
+    assert got[0] == desc
+
+    captured = {}
+
+    async def _branch_spy(repo, branch):
+        captured["branch_cut"] = (repo, branch)
+
+    async def _docs_spy(repo, branch, work_item_id, name, description=None):
+        captured["description"] = description
+
+    # _materialize_deferred_branch imports these names from webhooks.plane at call
+    # time, so patching the source module attributes intercepts them.
+    monkeypatch.setattr(plane, "_create_gitea_branch", _branch_spy)
+    monkeypatch.setattr(plane, "_create_initial_docs", _docs_spy)
+
+    from src.agents.launcher import AgentLauncher
+    AgentLauncher()._materialize_deferred_branch(
+        "orchestrator", "feature/ORCH-201-x", "ORCH-201", "Title B", desc
+    )
+
+    assert captured.get("branch_cut") == ("orchestrator", "feature/ORCH-201-x")
+    assert captured.get("description") == desc
+
+
+# ---------------------------------------------------------------------------
+# TC-04 (direct path A / serial gate not applicable): _create_initial_docs
+#        writes the real description into the Gitea contents body.
+# ---------------------------------------------------------------------------
+def test_tc04_direct_path_renders_description(monkeypatch):
+    desc = "Direct path A description that must reach the artifact body verbatim."
+    captured = {}
+
+    class _Resp:
+        status_code = 201
+
+        def raise_for_status(self):
+            pass
+
+    class _Client:
+        async def __aenter__(self):
+            return self
+
+        async def __aexit__(self, *a):
+            return False
+
+        async def post(self, url, json=None, headers=None, timeout=None):
+            captured["content"] = base64.b64decode(json["content"]).decode()
+            return _Resp()
+
+    monkeypatch.setattr(
+        plane, "httpx", SimpleNamespace(AsyncClient=lambda *a, **k: _Client())
+    )
+
+    asyncio.run(
+        plane._create_initial_docs("orchestrator", "feature/x", "ORCH-119", "Name", desc)
+    )
+
+    assert desc in captured["content"]
+    assert "## Description\n\nTBD\n" not in captured["content"]
+
+
+# ---------------------------------------------------------------------------
+# TC-05 (schema backward-compat): _ensure_column adds tasks.description on a
+#        pre-existing table without it; idempotent on re-run; creation works.
+# ---------------------------------------------------------------------------
+def test_tc05_schema_backward_compat(monkeypatch, tmp_path):
+    db_path = str(tmp_path / "bc.db")
+    monkeypatch.setattr(_db.settings, "db_path", db_path)
+
+    # Simulate an OLD tasks table WITHOUT the description column.
+    conn = _db.get_db()
+    conn.executescript(
+        """
+        CREATE TABLE tasks (
+            id INTEGER PRIMARY KEY AUTOINCREMENT,
+            plane_id TEXT, work_item_id TEXT, repo TEXT NOT NULL,
+            branch TEXT, stage TEXT DEFAULT 'created', plane_issue_id TEXT, title TEXT
+        );
+        """
+    )
+    conn.commit()
+    conn.close()
+
+    # init_db must add the column idempotently and never fail.
+    init_db()
+    cols = [r[1] for r in _db.get_db().execute("PRAGMA table_info(tasks)").fetchall()]
+    assert "description" in cols
+
+    init_db()  # re-run: _ensure_column is a no-op (idempotent)
+
+    # Task creation works and persists the description.
+    row, created = create_task_atomic(
+        "p1", "ORCH-1", "orchestrator", "b", "analysis", "T", "a real description"
+    )
+    assert created
+    got = get_db().execute(
+        "SELECT description FROM tasks WHERE id=?", (row["id"],)
+    ).fetchone()
+    assert got[0] == "a real description"
+
+
+# ---------------------------------------------------------------------------
+# TC-06 (data integrity): multi-line markdown with special chars is preserved
+#        verbatim (no truncation/escaping); Gitea 422 (file exists) -> no-op
+#        (single create attempt, body NOT overwritten).
+# ---------------------------------------------------------------------------
+def test_tc06_multiline_preserved_and_idempotent_422(monkeypatch):
+    desc = (
+        "# Heading\n\n- bullet with `inline code`\n"
+        "- second *italic* and __bold__\n\n"
+        "Paragraph with special chars: <>&\"' and a trailing word."
+    )
+    out = plane._render_business_request("ORCH-119", "N", desc)
+    assert desc in out  # preserved verbatim, no truncation/escaping
+
+    calls = []
+
+    class _Resp:
+        status_code = 422  # Gitea: file already exists
+
+        def raise_for_status(self):
+            raise AssertionError("422 must be a no-op, never raised")
+
+    class _Client:
+        async def __aenter__(self):
+            return self
+
+        async def __aexit__(self, *a):
+            return False
+
+        async def post(self, url, json=None, headers=None, timeout=None):
+            calls.append(json)
+            return _Resp()
+
+    monkeypatch.setattr(
+        plane, "httpx", SimpleNamespace(AsyncClient=lambda *a, **k: _Client())
+    )
+
+    asyncio.run(
+        plane._create_initial_docs("orchestrator", "b", "ORCH-119", "N", desc)
+    )
+    # Exactly one create attempt; no follow-up PUT/overwrite of the existing body.
+    assert len(calls) == 1
+
+
+# ---------------------------------------------------------------------------
+# TC-07 (anti-regression): the pipeline machinery is untouched —
+#        00-business-request.md stays informational (not gate-parsed).
+# ---------------------------------------------------------------------------
+def test_tc07_gates_unchanged():
+    from src.stages import STAGE_TRANSITIONS
+    from src.qg.checks import QG_CHECKS
+
+    # Stage graph intact.
+    for st in ("created", "analysis", "architecture", "development",
+               "review", "testing", "deploy-staging", "deploy", "done"):
+        assert st in STAGE_TRANSITIONS
+
+    # The named checks still exist with their canonical names.
+    for chk in ("check_analysis_complete", "check_architecture_done",
+                "check_ci_green", "check_tests_passed"):
+        assert chk in QG_CHECKS
+
+    # 00-business-request.md is informational: no check is keyed on it.
+    assert not any("business" in k.lower() for k in QG_CHECKS)

tests/test_orch120_analyst_needs_input.py

@@ -0,0 +1,305 @@
+"""ORCH-120 (adr-0053): analyst open-questions -> Needs Input — engine flow.
+
+Drives ``_handle_analysis_approved_flow`` through the real ``advance_stage(...,
+finished_agent='analyst')`` launcher path (pattern of
+``tests/test_auto_approve_brd.py``): mocks the Plane/Telegram setters and uses a
+temporary worktree + a patched ``check_analysis_complete``.
+
+Covers (04-test-plan.yaml):
+  TC-01  REGRESS (mandatory): 4 files + ACTIVE 01-questions.md simultaneously ->
+         Needs Input wins over "files ready" (AC-1). RED before the fix.
+  TC-02  01-questions.md present, 4 files missing -> Needs Input, question text in
+         the Plane comment + Telegram (AC-2).
+  TC-03  Happy-path: no 01-questions.md, 4 files present -> In Review (AC-3).
+  TC-06  Hygiene: full FRESH package supersedes a stale 01-questions.md -> In
+         Review, NOT a repeat Needs Input (AC-6).
+  TC-09  never-raise: a failure in the new logic degrades safely + does not crash
+         advance_stage (AC-10).
+  TC-10  Reversibility: kill-switch off OR enduro repo -> ORIGINAL byte-for-byte
+         order (files_ok first) (AC-9).
+"""
+import os
+import tempfile
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch120_needs_input.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+from unittest.mock import MagicMock  # noqa: E402
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db  # noqa: E402
+from src import stage_engine  # noqa: E402
+from src import analyst_questions  # noqa: E402
+from src import labels  # noqa: E402
+from src.config import settings  # noqa: E402
+from src.stage_engine import advance_stage  # noqa: E402
+
+_DELIVERABLES = ("01-brd.md", "02-trz.md", "03-acceptance-criteria.md", "04-test-plan.yaml")
+
+
+@pytest.fixture(autouse=True)
+def fresh(monkeypatch, tmp_path):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    # Silence Plane/Telegram side effects; capture the channels we assert on.
+    for name in ("notify_stage_change", "notify_qg_failure", "plane_notify_stage",
+                 "plane_notify_qg", "set_issue_in_review", "set_issue_needs_input",
+                 "set_issue_approved", "notify_approve_requested"):
+        monkeypatch.setattr(stage_engine, name, MagicMock(), raising=False)
+    monkeypatch.setattr(stage_engine, "_build_analyst_ready_comment",
+                        lambda *a, **k: "ready", raising=False)
+    monkeypatch.setattr(stage_engine, "plane_add_comment", MagicMock())
+    monkeypatch.setattr(stage_engine, "send_telegram", MagicMock())
+    # autoApprove off by default (TC-03 wants In Review, not auto-advance).
+    monkeypatch.setattr(labels, "auto_approve_applies", lambda repo: False)
+    monkeypatch.setattr(labels, "has_label", lambda w, name, p=None: False)
+    # Questions-gate on for orchestrator by default (mirror prod defaults).
+    monkeypatch.setattr(settings, "analyst_questions_gate_enabled", True, raising=False)
+    monkeypatch.setattr(settings, "analyst_questions_gate_repos", "", raising=False)
+    monkeypatch.setattr(settings, "analyst_needs_input_autopause_enabled", True,
+                        raising=False)
+    yield
+
+
+def _make_task(stage="analysis", repo="orchestrator", branch="feature/ORCH-120-x",
+               wi="ORCH-120"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) "
+        "VALUES (?, ?, ?, ?, ?)",
+        (f"plane-{wi}", wi, repo, branch, stage),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+def _wi_dir(worktree, wi="ORCH-120"):
+    d = os.path.join(worktree, "docs", "work-items", wi)
+    os.makedirs(d, exist_ok=True)
+    return d
+
+
+def _write(path, mtime=None, body="x"):
+    with open(path, "w") as f:
+        f.write(body)
+    if mtime is not None:
+        os.utime(path, (mtime, mtime))
+
+
+def _patch_worktree(monkeypatch, worktree):
+    monkeypatch.setattr(stage_engine, "get_worktree_path", lambda repo, branch: worktree)
+
+
+def _patch_complete_gate(monkeypatch, ok=True):
+    def gate(*a, **k):
+        return (ok, "ok" if ok else "missing artifacts")
+    monkeypatch.setattr(
+        stage_engine, "QG_CHECKS",
+        {**stage_engine.QG_CHECKS, "check_analysis_complete": gate},
+    )
+
+
+def _stage_of(task_id):
+    conn = get_db()
+    row = conn.execute("SELECT stage FROM tasks WHERE id=?", (task_id,)).fetchone()
+    conn.close()
+    return row[0]
+
+
+def _paused_at(task_id):
+    conn = get_db()
+    row = conn.execute("SELECT paused_at FROM tasks WHERE id=?", (task_id,)).fetchone()
+    conn.close()
+    return row[0]
+
+
+# --- TC-01: REGRESS — questions priority over files_ok -----------------------
+def test_tc01_questions_priority_over_files_ready(monkeypatch, tmp_path):
+    """4 deliverables + an ACTIVE (newest) 01-questions.md -> Needs Input wins."""
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    base = 1_000_000
+    for i, name in enumerate(_DELIVERABLES):
+        _write(os.path.join(d, name), mtime=base + i)
+    # 01-questions.md is the NEWEST -> NOT superseded -> active.
+    _write(os.path.join(d, "01-questions.md"), mtime=base + 100,
+           body="Q-1 нужно уточнить охват")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert res.note == "analysis-needs-input"
+    assert stage_engine.set_issue_needs_input.called
+    assert not stage_engine.set_issue_in_review.called
+    assert _stage_of(tid) == "analysis"  # NOT advanced to architecture
+
+
+# --- TC-02: questions only, no deliverables ----------------------------------
+def test_tc02_questions_only_no_deliverables(monkeypatch, tmp_path):
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    _write(os.path.join(d, "01-questions.md"), body="Q-1 какой формат вывода?")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=False)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert res.note == "analysis-needs-input"
+    assert stage_engine.set_issue_needs_input.called
+    # Question text reached the Plane comment + Telegram.
+    comment_arg = stage_engine.plane_add_comment.call_args.args[1]
+    assert "Q-1 какой формат вывода?" in comment_arg
+    assert stage_engine.send_telegram.called
+
+
+# --- TC-03: happy-path, no questions -----------------------------------------
+def test_tc03_happy_path_no_questions(monkeypatch, tmp_path):
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    for name in _DELIVERABLES:
+        _write(os.path.join(d, name))
+    # No 01-questions.md.
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert res.note == "analysis-in-review"
+    assert stage_engine.set_issue_in_review.called
+    assert not stage_engine.set_issue_needs_input.called
+    assert stage_engine.notify_approve_requested.called
+
+
+# --- TC-06: hygiene — fresh package supersedes a stale questions file --------
+def test_tc06_stale_questions_superseded(monkeypatch, tmp_path):
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    base = 2_000_000
+    # 01-questions.md is OLDER than every deliverable -> superseded -> In Review.
+    _write(os.path.join(d, "01-questions.md"), mtime=base, body="stale Q from last run")
+    for i, name in enumerate(_DELIVERABLES):
+        _write(os.path.join(d, name), mtime=base + 100 + i)
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert res.note == "analysis-in-review"
+    assert stage_engine.set_issue_in_review.called
+    assert not stage_engine.set_issue_needs_input.called
+
+
+# --- TC-09: never-raise -------------------------------------------------------
+def test_tc09_predicate_error_degrades_to_prior_order(monkeypatch, tmp_path):
+    """questions_active raising -> degrade to original order (files_ok -> In Review)."""
+    worktree = str(tmp_path)
+    _wi_dir(worktree)
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+
+    def boom(*a, **k):
+        raise RuntimeError("synthetic predicate failure")
+    monkeypatch.setattr(analyst_questions, "questions_active", boom)
+    tid = _make_task()
+
+    # Must NOT raise.
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+    assert res.note == "analysis-in-review"
+    assert stage_engine.set_issue_in_review.called
+
+
+def test_tc09_park_error_does_not_crash(monkeypatch, tmp_path):
+    """A failing set_task_paused must not undo Needs Input nor crash advance_stage."""
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    _write(os.path.join(d, "01-questions.md"), body="Q-1 ?")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=False)
+
+    def boom(task_id):
+        raise RuntimeError("synthetic park failure")
+    monkeypatch.setattr(stage_engine, "set_task_paused", boom)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+    assert res.note == "analysis-needs-input"
+    assert stage_engine.set_issue_needs_input.called
+
+
+# --- TC-10: reversibility — kill-switch off / enduro -> original order --------
+def test_tc10_kill_switch_off_original_order(monkeypatch, tmp_path):
+    """Gate off: 4 files + active questions -> In Review (original order), no park."""
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    base = 3_000_000
+    for i, name in enumerate(_DELIVERABLES):
+        _write(os.path.join(d, name), mtime=base + i)
+    _write(os.path.join(d, "01-questions.md"), mtime=base + 100, body="Q-1 ?")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+    monkeypatch.setattr(settings, "analyst_questions_gate_enabled", False, raising=False)
+    tid = _make_task()
+
+    res = advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                        "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert res.note == "analysis-in-review"
+    assert stage_engine.set_issue_in_review.called
+    assert not stage_engine.set_issue_needs_input.called
+    assert _paused_at(tid) is None  # no auto-park when the gate is off
+
+
+def test_tc10_enduro_out_of_scope_original_order(monkeypatch, tmp_path):
+    """enduro repo (empty CSV -> self-hosting only) -> gate inert -> original order."""
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree, wi="ET-9")
+    base = 4_000_000
+    for i, name in enumerate(_DELIVERABLES):
+        _write(os.path.join(d, name), mtime=base + i)
+    _write(os.path.join(d, "01-questions.md"), mtime=base + 100, body="Q-1 ?")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=True)
+    tid = _make_task(repo="enduro-trails", branch="feature/ET-9-x", wi="ET-9")
+
+    res = advance_stage(tid, "analysis", "enduro-trails", "ET-9",
+                        "feature/ET-9-x", finished_agent="analyst")
+
+    assert res.note == "analysis-in-review"
+    assert stage_engine.set_issue_in_review.called
+    assert not stage_engine.set_issue_needs_input.called
+
+
+# --- Auto-park bonus: orchestrator Needs Input parks the task ----------------
+def test_autopark_on_needs_input(monkeypatch, tmp_path):
+    """ORCH-120 D4: Needs Input on the self-hosting repo auto-parks the task."""
+    worktree = str(tmp_path)
+    d = _wi_dir(worktree)
+    _write(os.path.join(d, "01-questions.md"), body="Q-1 ?")
+    _patch_worktree(monkeypatch, worktree)
+    _patch_complete_gate(monkeypatch, ok=False)
+    tid = _make_task()
+
+    advance_stage(tid, "analysis", "orchestrator", "ORCH-120",
+                  "feature/ORCH-120-x", finished_agent="analyst")
+
+    assert _paused_at(tid) is not None  # task parked -> serial-gate FIFO freed

tests/test_orch120_questions_artifact_canon.py

@@ -0,0 +1,56 @@
+"""ORCH-120 (adr-0053) TC-08: canon of the 01-questions.md signal artifact.
+
+Pure-text structural checks (NO src/ import): the skeleton exists and the
+PIPELINE_DOCS.md manifest documents 01-questions.md as an analyst-owned,
+when-applicable, NON-machine-verdict signal artifact (AC-8).
+"""
+import os
+
+_REPO_ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
+_TEMPLATE = os.path.join(_REPO_ROOT, "docs", "_templates", "01-questions.md")
+_PIPELINE_DOCS = os.path.join(_REPO_ROOT, "docs", "_standards", "PIPELINE_DOCS.md")
+
+
+def _read(path):
+    with open(path, encoding="utf-8") as f:
+        return f.read()
+
+
+def test_questions_skeleton_exists_and_nonempty():
+    """TC-08: docs/_templates/01-questions.md exists and is non-empty."""
+    assert os.path.isfile(_TEMPLATE), "docs/_templates/01-questions.md is missing"
+    body = _read(_TEMPLATE)
+    assert body.strip(), "01-questions.md template is empty"
+    # Carries the 52c schema fields + signals the analyst stage/owner.
+    for field in ("work_item", "stage", "author_agent", "status", "created_at",
+                  "model_used"):
+        assert field in body, f"01-questions.md template omits schema field {field!r}"
+    assert "stage: analysis" in body
+    assert "author_agent: analyst" in body
+    # Documents the three required parts (context / blocking questions / unblocks).
+    assert "Блокирующие вопросы" in body
+    assert "разблокирует" in body
+
+
+def test_pipeline_docs_manifest_row_for_questions():
+    """TC-08: PIPELINE_DOCS.md has a manifest row for 01-questions.md."""
+    text = _read(_PIPELINE_DOCS)
+    # A manifest table row mentioning the file, the analyst owner and when-applicable.
+    rows = [ln for ln in text.splitlines()
+            if "`01-questions.md`" in ln and "|" in ln]
+    assert rows, "PIPELINE_DOCS.md has no manifest row for 01-questions.md"
+    row = rows[0]
+    assert "analyst" in row, "01-questions.md manifest row does not name the analyst owner"
+    assert "when-applicable" in row, "01-questions.md row not marked when-applicable"
+    # Signal artifact -> NOT a machine-verdict.
+    assert ("сигнальн" in row.lower()) or ("не machine-verdict" in row.lower()), (
+        "01-questions.md row does not mark it as a signal / non-machine-verdict artifact"
+    )
+
+
+def test_pipeline_docs_notes_the_01_prefix_convention():
+    """TC-08 (DQ-4): PIPELINE_DOCS.md notes the shared `01-` prefix convention."""
+    text = _read(_PIPELINE_DOCS)
+    assert "Префикс `01-`" in text or "префикс `01-`" in text, (
+        "PIPELINE_DOCS.md does not document the 01- prefix convention (DQ-4)"
+    )

tests/test_orch120_resume_unpark.py

@@ -0,0 +1,100 @@
+"""ORCH-120 (adr-0053) TC-05: resume + unpark on analyst relaunch.
+
+When the stakeholder answers and returns the issue to a working status on
+``analysis``, ``handle_status_start`` clears the auto-park (``paused_at`` -> NULL)
+so the re-enqueued analyst-job is claimable, and relaunches the analyst. The
+ORCH-090 relaunch-guard (relaunch only for ``analysis``) is not weakened.
+
+  TC-05  paused analysis task + To Analyse, no active job -> unpark + relaunch
+         analyst; relaunch-guard (analysis only) respected (AC-5).
+"""
+import os
+import tempfile
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch120_resume_unpark.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+from unittest.mock import patch, AsyncMock, MagicMock  # noqa: E402
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db, set_task_paused, is_task_paused  # noqa: E402
+from src import config as cfg  # noqa: E402
+from src.webhooks.plane import handle_status_start  # noqa: E402
+
+
+@pytest.fixture(autouse=True)
+def fresh(monkeypatch):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    # Questions gate + autopause ON for the self-hosting repo (prod defaults).
+    monkeypatch.setattr(cfg.settings, "analyst_questions_gate_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "analyst_questions_gate_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "analyst_needs_input_autopause_enabled", True,
+                        raising=False)
+    yield
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+
+
+def _make_task(plane_id, stage="analysis", repo="orchestrator", branch="feature/ORCH-120-x",
+               wi="ORCH-120"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) "
+        "VALUES (?, ?, ?, ?, ?)",
+        (plane_id, wi, repo, branch, stage),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+@pytest.mark.asyncio
+async def test_tc05_resume_unparks_and_relaunches_analyst():
+    tid = _make_task("resume-120", stage="analysis")
+    assert set_task_paused(tid) is True
+    assert is_task_paused(tid) is True            # parked while waiting for a human
+
+    data = {"id": "resume-120", "state": {"id": "ip-uuid", "name": "To Analyse"}}
+    with patch("src.webhooks.plane.enqueue_job", return_value=11) as mock_enqueue, \
+         patch("src.webhooks.plane.start_pipeline", new_callable=AsyncMock) as mock_start, \
+         patch("src.plane_sync.add_comment", MagicMock()), \
+         patch("src.plane_sync.set_issue_analysis") as mock_analysis:
+        await handle_status_start(data, "proj-1")
+
+    mock_start.assert_not_called()                # resume, not a fresh pipeline
+    # Unparked: the re-enqueued analyst-job is claimable again (AC-5).
+    assert is_task_paused(tid) is False
+    # Analyst relaunched exactly once (relaunch-guard: only analysis, ORCH-090).
+    assert mock_enqueue.call_count == 1
+    assert mock_enqueue.call_args.args[0] == "analyst"
+    mock_analysis.assert_called_once_with("ORCH-120")
+
+
+@pytest.mark.asyncio
+async def test_tc05_autopause_off_does_not_unpark():
+    """Reversibility: with the autopause sub-flag off the resume does not unpark
+    (operator-park stays the operator's to clear); relaunch still happens."""
+    tid = _make_task("resume-120b", stage="analysis")
+    set_task_paused(tid)
+
+    data = {"id": "resume-120b", "state": {"id": "ip-uuid", "name": "To Analyse"}}
+    with patch("src.config.settings.analyst_needs_input_autopause_enabled", False, create=True), \
+         patch("src.webhooks.plane.enqueue_job", return_value=12) as mock_enqueue, \
+         patch("src.webhooks.plane.start_pipeline", new_callable=AsyncMock), \
+         patch("src.plane_sync.add_comment", MagicMock()), \
+         patch("src.plane_sync.set_issue_analysis"):
+        await handle_status_start(data, "proj-1")
+
+    # Autopause off -> engine-side unpark is inert; the task stays parked (operator
+    # clears via POST /serial-gate/resume). The relaunch itself is unaffected.
+    assert is_task_paused(tid) is True
+    assert mock_enqueue.call_count == 1

tests/test_orch120_serial_gate_needs_input.py

@@ -0,0 +1,111 @@
+"""ORCH-120 (adr-0053) TC-04: Needs Input auto-park does not wedge serial-gate.
+
+Integration: a self-hosting task A driven into Needs Input through the real
+``advance_stage(..., finished_agent='analyst')`` path is auto-parked (D4), which
+EXCLUDES it from the serial-gate "active task" predicate (ORCH-088/124) so a later
+task B of the same repo can enter ``analysis`` (its analyst-job becomes claimable).
+
+  TC-04  earlier task A (analysis) blocks B's analyst-job; once A is driven into
+         Needs Input (auto-parked), B's analyst-job becomes claimable (AC-4).
+"""
+import os
+import tempfile
+
+import pytest
+
+_test_db = os.path.join(tempfile.gettempdir(), "test_orch120_serial_gate.db")
+os.environ["ORCH_DB_PATH"] = _test_db
+os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+from unittest.mock import MagicMock  # noqa: E402
+
+import src.db as _db  # noqa: E402
+from src.db import init_db, get_db, enqueue_job, claim_next_job  # noqa: E402
+from src import stage_engine  # noqa: E402
+from src import labels  # noqa: E402
+from src import config as cfg  # noqa: E402
+from src.stage_engine import advance_stage  # noqa: E402
+
+
+@pytest.fixture(autouse=True)
+def fresh(monkeypatch, tmp_path):
+    monkeypatch.setattr(_db.settings, "db_path", _test_db)
+    if os.path.exists(_test_db):
+        os.unlink(_test_db)
+    init_db()
+    # Serial gate + pause axis ON (empty CSV -> all repos).
+    monkeypatch.setattr(cfg.settings, "serial_gate_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_freeze_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_pause_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "task_deps_enabled", False, raising=False)
+    # Questions gate + autopause ON for orchestrator (prod defaults).
+    monkeypatch.setattr(cfg.settings, "analyst_questions_gate_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "analyst_questions_gate_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "analyst_needs_input_autopause_enabled", True,
+                        raising=False)
+    # Silence Plane/Telegram side effects.
+    for name in ("set_issue_in_review", "set_issue_needs_input", "set_issue_approved",
+                 "notify_approve_requested", "plane_notify_stage"):
+        monkeypatch.setattr(stage_engine, name, MagicMock(), raising=False)
+    monkeypatch.setattr(stage_engine, "plane_add_comment", MagicMock())
+    monkeypatch.setattr(stage_engine, "send_telegram", MagicMock())
+    monkeypatch.setattr(labels, "auto_approve_applies", lambda repo: False)
+    monkeypatch.setattr(labels, "has_label", lambda w, name, p=None: False)
+    yield
+
+
+def _make_task(wi, stage="analysis", repo="orchestrator"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) "
+        "VALUES (?, ?, ?, ?, ?)",
+        (wi, wi, repo, f"feature/{wi}", stage),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+def _paused_at(task_id):
+    conn = get_db()
+    row = conn.execute("SELECT paused_at FROM tasks WHERE id=?", (task_id,)).fetchone()
+    conn.close()
+    return row[0]
+
+
+def test_tc04_needs_input_autopark_unblocks_serial_gate(monkeypatch, tmp_path):
+    a = _make_task("ORCH-120A", stage="analysis")     # earlier active task
+    b = _make_task("ORCH-120B", stage="analysis")     # later task awaiting analysis
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+
+    # Before A is parked it holds the repo's FIFO gate -> B's analyst-job blocked.
+    assert claim_next_job() is None, "active A gates B (FIFO, ORCH-088)"
+
+    # Drive A into Needs Input via the engine (01-questions.md present, no
+    # deliverables) -> auto-park.
+    worktree = str(tmp_path)
+    d = os.path.join(worktree, "docs", "work-items", "ORCH-120A")
+    os.makedirs(d, exist_ok=True)
+    with open(os.path.join(d, "01-questions.md"), "w") as f:
+        f.write("Q-1 нужно уточнить охват")
+    monkeypatch.setattr(stage_engine, "get_worktree_path", lambda repo, br: worktree)
+    monkeypatch.setattr(
+        stage_engine, "QG_CHECKS",
+        {**stage_engine.QG_CHECKS,
+         "check_analysis_complete": lambda *a, **k: (False, "missing")},
+    )
+
+    res = advance_stage(a, "analysis", "orchestrator", "ORCH-120A",
+                        "feature/ORCH-120A", finished_agent="analyst")
+    assert res.note == "analysis-needs-input"
+    assert _paused_at(a) is not None, "A must be auto-parked on Needs Input (D4)"
+
+    # Now the parked A no longer holds the FIFO gate -> B's analyst-job is claimable.
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b, (
+        "a parked Needs-Input predecessor must not wedge the repo serial-gate (AC-4)"
+    )

tests/test_orch123_staging_runner_exec.py

@@ -50,6 +50,13 @@ def fresh_db(monkeypatch, tmp_path):
         os.unlink(_test_db)
     init_db()
     monkeypatch.setattr("src.git_worktree.settings.worktrees_dir", str(tmp_path), raising=False)
+    # Isolate repos_dir too: check_staging_status falls back to <repos_dir>/<repo>
+    # (and origin/main on it) when the feature worktree is absent. Without this the
+    # gate would read REAL on-disk artifacts from the shared clone (e.g. a merged
+    # ORCH-123/15-staging-log.md), turning the intended-RED gate in test_r2 green and
+    # making the suite order-dependent. Point it at an empty tmp subdir (no .git, no
+    # work-items) so the staging gate is deterministically "not found" -> red.
+    monkeypatch.setattr(cfg.settings, "repos_dir", str(tmp_path / "repos"), raising=False)
     # Runner ON, self-hosting scope, host-side strategy ON (defaults).
     monkeypatch.setattr(cfg.settings, "staging_runner_enabled", True, raising=False)
     monkeypatch.setattr(cfg.settings, "staging_runner_repos", "", raising=False)

tests/test_orch124_serial_gate_pause.py

@@ -0,0 +1,353 @@
+"""ORCH-124 — serial-gate wait/pause semantics (real tmp SQLite, no network).
+
+A paused predecessor must NOT block an urgent successor's analyst-job, while a
+normally-executing predecessor still holds the FIFO gate (anti-stale-base ORCH-088
+preserved). Covers 04-test-plan.yaml TC-01…TC-15. The behaviour (not the exact SQL)
+is asserted: pause is an explicit, durable, DB-resolvable per-task signal
+(``tasks.paused_at``) that the offline hot-claim SQL reads locally.
+
+  TC-01  REGRESS (mandatory): earlier PAUSED task A + later urgent B -> claim picks
+         B's analyst-job (gate open). Reproduces incident ORCH-116/ORCH-123.
+  TC-02  Predecessor parked (Backlog intent) -> build_claim_clause does NOT block B.
+  TC-03  Predecessor parked at another wait-stage (Needs-Input intent) -> still open.
+  TC-04  ANTI-REGRESS ORCH-088: a NON-paused unfinished predecessor STILL blocks B.
+  TC-05  Pause needs explicit durable intent; unpaused non-terminal task stays active.
+  TC-06  Durable: the pause signal survives a connection/restart (read from the DB).
+  TC-07  Resume restores participation in the gate (no eternal bypass).
+  TC-08  Explicit blocks kept: an active repo_freeze still gates B (pause != bypass).
+  TC-09  Explicit blocks kept: an unfinished declared dependency still gates B.
+  TC-10  /queue snapshot: paused task not shown as active_task; reason is correct.
+  TC-11  Three points agree on "active" (anti-drift): clause / mirror / snapshot.
+  TC-12  Hot-path offline: claim resolves pause with no network (Plane not consulted).
+  TC-13  never-raise / fail-directions: pause error -> build_claim_clause fail-OPEN.
+  TC-14  Kill-switch: pause sub-flag off -> byte-for-byte ORCH-088/090 (paused blocks).
+  TC-15  Structural anti-regress: STAGE_TRANSITIONS / QG_CHECKS / table schemas intact.
+"""
+import os
+import tempfile
+
+import pytest
+
+os.environ["ORCH_DB_PATH"] = os.path.join(tempfile.gettempdir(), "test_orch124_pause.db")
+os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
+os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
+
+import src.db as db  # noqa: E402
+from src.db import init_db, get_db, enqueue_job, claim_next_job  # noqa: E402
+from src import serial_gate  # noqa: E402
+from src import config as cfg  # noqa: E402
+
+
+@pytest.fixture(autouse=True)
+def fresh_db(tmp_path, monkeypatch):
+    dbfile = tmp_path / "pause.db"
+    monkeypatch.setattr(db.settings, "db_path", str(dbfile))
+    # Serial gate ON; freeze layer ON; pause layer ON; empty CSV (all repos).
+    monkeypatch.setattr(cfg.settings, "serial_gate_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_repos", "", raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_freeze_enabled", True, raising=False)
+    monkeypatch.setattr(cfg.settings, "serial_gate_pause_enabled", True, raising=False)
+    # Keep the unrelated dep-gate inert unless a test opts in.
+    monkeypatch.setattr(cfg.settings, "task_deps_enabled", False, raising=False)
+    init_db()
+    yield
+
+
+def _make_task(work_item_id, stage="analysis", repo="orchestrator"):
+    conn = get_db()
+    cur = conn.execute(
+        "INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage, title) "
+        "VALUES (?, ?, ?, ?, ?, ?)",
+        (work_item_id, work_item_id, repo, f"feature/{work_item_id}", stage, work_item_id),
+    )
+    tid = cur.lastrowid
+    conn.commit()
+    conn.close()
+    return tid
+
+
+# --------------------------------------------------------------- TC-01
+def test_paused_predecessor_does_not_block_urgent_successor():
+    """REGRESS (ORCH-116/ORCH-123): earlier PAUSED A must not gate urgent B."""
+    a = _make_task("ORCH-116", stage="development")          # earlier predecessor
+    b = _make_task("ORCH-123", stage="analysis")             # later urgent task
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+
+    # Before the pause A holds the FIFO gate -> B is blocked (the incident state).
+    assert claim_next_job() is None, "active A gates B (pre-pause, FIFO ORCH-088)"
+
+    # Operator parks A. Now B's analyst-job must become claimable.
+    assert db.set_task_paused(a) is True
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b, (
+        "a PAUSED predecessor must not gate the urgent successor (AC-1)"
+    )
+
+
+# --------------------------------------------------------------- TC-02
+def test_parked_backlog_predecessor_not_active_in_clause():
+    a = _make_task("ORCH-201", stage="analysis")             # "Backlog" intent
+    b = _make_task("ORCH-202", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    assert "paused_at IS NULL" in serial_gate.build_claim_clause()
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b
+
+
+# --------------------------------------------------------------- TC-03
+def test_parked_needs_input_predecessor_not_active():
+    # Another wait-stage (review ~ "Needs-Input" intent) — same park column.
+    a = _make_task("ORCH-203", stage="review")
+    b = _make_task("ORCH-204", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b
+
+
+# --------------------------------------------------------------- TC-04
+def test_non_paused_predecessor_still_blocks_fifo():
+    """ANTI-REGRESS ORCH-088: a normally-executing A still gates B."""
+    _make_task("ORCH-210", stage="development")              # NOT paused
+    b = _make_task("ORCH-211", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    assert claim_next_job() is None, (
+        "a non-paused unfinished predecessor must STILL hold the gate (FIFO intact)"
+    )
+
+
+# --------------------------------------------------------------- TC-05
+def test_pause_requires_explicit_durable_intent():
+    a = _make_task("ORCH-215", stage="development")
+    b = _make_task("ORCH-216", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    # No explicit pause -> A is active -> gate held (no heuristic auto-pause).
+    assert db.is_task_paused(a) is False
+    assert claim_next_job() is None
+    # The pause signal is DB-resolvable once set explicitly.
+    db.set_task_paused(a)
+    assert db.is_task_paused(a) is True
+
+
+# --------------------------------------------------------------- TC-06
+def test_pause_signal_is_durable_across_restart():
+    a = _make_task("ORCH-220", stage="development")
+    b = _make_task("ORCH-221", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    # Simulate a restart: drop in-memory state, re-run the idempotent migration.
+    init_db()
+    assert db.is_task_paused(a) is True, "pause must survive restart (read from DB)"
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b
+
+
+# --------------------------------------------------------------- TC-07
+def test_resume_restores_gate_participation():
+    a = _make_task("ORCH-225", stage="development")
+    b = _make_task("ORCH-226", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    assert claim_next_job() is not None  # B claimable while A paused
+    # Re-queue a fresh analyst-job for B (the previous one was claimed) and resume A.
+    conn = get_db()
+    conn.execute("UPDATE jobs SET status='queued', started_at=NULL WHERE task_id=?", (b,))
+    conn.commit()
+    conn.close()
+    assert db.clear_task_paused(a) is True
+    assert db.is_task_paused(a) is False
+    assert claim_next_job() is None, (
+        "after resume A holds the gate again — no eternal bypass (AC-10)"
+    )
+
+
+# --------------------------------------------------------------- TC-08
+def test_pause_does_not_bypass_freeze():
+    _make_task("ORCH-230", stage="done")                     # nothing unfinished
+    a = _make_task("ORCH-231", stage="development")
+    b = _make_task("ORCH-232", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    # Freeze the repo: even with A paused, B must stay blocked by the freeze.
+    serial_gate.set_repo_freeze("orchestrator", "DEGRADED", "ORCH-230")
+    assert claim_next_job() is None, "an active freeze gates B; pause must not bypass it"
+    # Clearing the freeze (A still paused) -> B becomes claimable.
+    serial_gate.clear_repo_freeze("orchestrator")
+    assert claim_next_job() is not None
+
+
+# --------------------------------------------------------------- TC-09
+def test_pause_does_not_bypass_declared_dependency(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "task_deps_enabled", True, raising=False)
+    a = _make_task("ORCH-240", stage="development")
+    b = _make_task("ORCH-241", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    assert db.add_dependency(b, a) is True                   # B blocked-by A
+    db.set_task_paused(a)
+    # task_deps reads the {done,cancelled} terminal only (NOT paused_at): an
+    # unfinished declared dependency keeps B blocked even though A is paused.
+    assert claim_next_job() is None, (
+        "a declared unfinished dependency gates B; pause must not bypass it (AC-5)"
+    )
+    # Once A is terminal the dependency is satisfied -> B is claimable.
+    conn = get_db()
+    conn.execute("UPDATE tasks SET stage='done' WHERE id=?", (a,))
+    conn.commit()
+    conn.close()
+    assert claim_next_job() is not None
+
+
+# --------------------------------------------------------------- TC-10
+def test_snapshot_reason_and_paused_list():
+    a = _make_task("ORCH-250", stage="development")
+    b = _make_task("ORCH-251", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+
+    # (a) A active (not paused) -> B waits with reason 'active-task'; A is active_task.
+    per = serial_gate.snapshot()["per_repo"]["orchestrator"]
+    assert per["active_task"]["work_item_id"] == "ORCH-250"
+    assert per["paused"] == []
+    wb = next(w for w in per["waiting"] if w["job_id"] == job_b)
+    assert wb["reason"] == "active-task"
+    # Existing keys preserved (BC).
+    assert set(per) >= {"active_task", "waiting", "frozen", "frozen_reason", "frozen_at"}
+
+    # (b) Pause A -> A no longer active_task; it appears in `paused`; B is claimable
+    # (reason None — a paused predecessor is by design NOT a wait reason).
+    db.set_task_paused(a)
+    per = serial_gate.snapshot()["per_repo"]["orchestrator"]
+    assert per["active_task"] is None or per["active_task"]["work_item_id"] != "ORCH-250"
+    assert any(p["work_item_id"] == "ORCH-250" for p in per["paused"])
+    wb = next(w for w in per["waiting"] if w["job_id"] == job_b)
+    assert wb["reason"] is None
+
+    # (c) Freeze -> reason 'freeze' (highest priority).
+    serial_gate.set_repo_freeze("orchestrator", "DEGRADED", "ORCH-250")
+    per = serial_gate.snapshot()["per_repo"]["orchestrator"]
+    wb = next(w for w in per["waiting"] if w["job_id"] == job_b)
+    assert wb["reason"] == "freeze"
+
+
+# --------------------------------------------------------------- TC-11
+def test_three_points_agree_on_active():
+    """Anti-drift: clause / mirror / snapshot classify predecessor A identically.
+
+    B is excluded from the mirror (``exclude_task_id=b``) to mirror the clause's
+    own-row exclusion (``t2.id < jobs.task_id``), so the three points are asked the
+    SAME question: "does the non-B predecessor A count as an active blocker?".
+    """
+    a = _make_task("ORCH-260", stage="development")
+    b = _make_task("ORCH-261", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+
+    # A NOT paused -> all three say A is active.
+    assert serial_gate.repo_has_active_task("orchestrator", exclude_task_id=b) is True
+    assert (serial_gate.snapshot()["per_repo"]["orchestrator"]["active_task"]
+            ["work_item_id"] == "ORCH-260")
+    assert claim_next_job() is None                          # clause blocks B on A
+
+    # A paused -> all three agree A is NOT active (consistent, no drift).
+    db.set_task_paused(a)
+    assert serial_gate.repo_has_active_task("orchestrator", exclude_task_id=b) is False
+    snap = serial_gate.snapshot()["per_repo"]["orchestrator"]
+    active = snap["active_task"]
+    assert active is None or active["work_item_id"] != "ORCH-260"
+    assert any(p["work_item_id"] == "ORCH-260" for p in snap["paused"])
+    assert claim_next_job() is not None                      # clause now opens for B
+
+
+# --------------------------------------------------------------- TC-12
+def test_hot_path_is_offline():
+    """The pause predicate resolves from the local DB only — no network."""
+    a = _make_task("ORCH-270", stage="development")
+    b = _make_task("ORCH-271", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    # Functional: claim works with no Plane configured/reachable.
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b
+    # Structural: the gate leaf imports no network client (offline hot path, NFR-2).
+    import inspect
+    src = inspect.getsource(serial_gate)
+    for forbidden in ("import httpx", "import requests", "plane_sync", "urllib.request"):
+        assert forbidden not in src, f"serial_gate must stay offline (found {forbidden!r})"
+
+
+# --------------------------------------------------------------- TC-13
+def test_pause_error_fails_open_and_never_raises(monkeypatch):
+    _make_task("ORCH-280", stage="development")              # would close the gate
+    b = _make_task("ORCH-281", stage="analysis")
+    job_b = enqueue_job("analyst", "orchestrator", "B", task_id=b)
+
+    def _boom():
+        raise RuntimeError("pause layer probe down")
+
+    monkeypatch.setattr(serial_gate, "_pause_layer_enabled", _boom, raising=True)
+    # build_claim_clause must fail-OPEN ('' fragment) — never raise, never wedge.
+    assert serial_gate.build_claim_clause() == ""
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_b, (
+        "a pause-layer error must fail-OPEN, not wedge the queue (AC-9)"
+    )
+    # The other public functions degrade conservatively without raising.
+    assert serial_gate.repo_has_active_task("orchestrator") in (True, False)
+    assert isinstance(serial_gate.snapshot(), dict)
+    # Freeze direction is NOT inverted by a pause error (still fail-CLOSED on doubt).
+    monkeypatch.setattr(
+        serial_gate, "_active_freeze_row",
+        lambda repo: (_ for _ in ()).throw(RuntimeError("freeze read down")),
+        raising=True,
+    )
+    assert serial_gate.is_repo_frozen("orchestrator") is True
+    # The DB mutators/readers never raise on bad input either.
+    assert db.set_task_paused(None) is False
+    assert db.clear_task_paused(None) is False
+    assert db.is_task_paused(None) is False
+
+
+# --------------------------------------------------------------- TC-14
+def test_kill_switch_off_is_byte_for_byte_orch088(monkeypatch):
+    monkeypatch.setattr(cfg.settings, "serial_gate_pause_enabled", False, raising=False)
+    a = _make_task("ORCH-290", stage="development")
+    b = _make_task("ORCH-291", stage="analysis")
+    enqueue_job("analyst", "orchestrator", "B", task_id=b)
+    db.set_task_paused(a)
+    # Pause sub-flag OFF -> the pause-term is omitted -> a paused task STILL counts
+    # as active (deliberate ORCH-088/090 rollback behaviour).
+    assert "paused_at" not in serial_gate.build_claim_clause()
+    assert claim_next_job() is None, (
+        "with the pause sub-flag off serial-gate is byte-for-byte ORCH-088/090"
+    )
+    # Outside the (empty) repo scope nothing changes for enduro either.
+    et = _make_task("ET-290", stage="analysis", repo="enduro-trails")
+    job_et = enqueue_job("analyst", "enduro-trails", "B", task_id=et)
+    claimed = claim_next_job()
+    assert claimed is not None and claimed["id"] == job_et
+
+
+# --------------------------------------------------------------- TC-15
+def test_registries_and_schemas_unchanged():
+    from src.stages import STAGE_TRANSITIONS
+    from src.qg.checks import QG_CHECKS
+    # ORCH-124 is a scheduler-only change: no new edge, no new terminal sink.
+    assert set(STAGE_TRANSITIONS) == {
+        "created", "analysis", "architecture", "development", "review",
+        "testing", "deploy-staging", "deploy", "done", "cancelled",
+    }
+    # No serial-gate / pause QG check was introduced (the gate is a scheduler cond).
+    assert not any("serial" in k or "pause" in k for k in QG_CHECKS)
+    # Existing table schemas intact; tasks gained the additive paused_at column.
+    conn = get_db()
+    try:
+        task_cols = {r[1] for r in conn.execute("PRAGMA table_info(tasks)").fetchall()}
+        job_cols = {r[1] for r in conn.execute("PRAGMA table_info(jobs)").fetchall()}
+        dep_cols = {r[1] for r in conn.execute("PRAGMA table_info(job_deps)").fetchall()}
+        frz_cols = {r[1] for r in conn.execute("PRAGMA table_info(repo_freeze)").fetchall()}
+    finally:
+        conn.close()
+    assert "paused_at" in task_cols                          # additive
+    assert {"id", "repo", "stage", "work_item_id"}.issubset(task_cols)
+    assert {"id", "agent", "repo", "status", "task_id"}.issubset(job_cols)
+    assert {"task_id", "depends_on_task_id"}.issubset(dep_cols)
+    assert {"repo", "frozen_at", "cleared_at"}.issubset(frz_cols)