deployer(ET): auto-commit from deployer run_id=651

Расширяю слайдо-источник презентации docs/overview/presentation.md тремя
слайдами в каноне ORCH-011 (16 → 19, сквозная нумерация сохранена):

- Слайд «Запуск и ведение задачи через Plane» (вход «To Analyse»,
  статусы = индикация, наблюдение: доска + Telegram-карточка + комментарии).
- Слайд «Что решает человек: гейты, авто-режим, отмена» (Approved /
  Confirm Deploy; autoApprove/autoDeploy/Bug — без пропуска тех. проверок; STOP).
- Слайд «Lite-установка скриптами» (два контейнера платформы; только конфиг;
  gen_secrets.py/onboard_project.py + docker compose up -d; runbook LITE_SETUP.md;
  одношаговый bootstrap — это смежный Bundled, не Lite).

Факты сверены с golden sources (LITE_SETUP.md, tech-pipeline.md,
tech-integrations.md, CLAUDE.md). Анти-дрейф — новая функция
test_presentation_covers_lite_and_plane_usage_bits в tests/test_system_docs.py
(существующие проверки без послаблений). CHANGELOG обновлён.

Docs+tests only: src/**/STAGE_TRANSITIONS/QG_CHECKS/check_*/схема БД —
байт-в-байт; python-pptx не в прод-образе; .pptx в git не коммитится.
Ручная сборка .pptx (TC-07) проверена в dev-venv: «Собрано слайдов: 19», exit 0.

Refs: ORCH-105

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

.env.example

@@ -24,19 +24,6 @@ ORCH_PLANE_BOT_REVIEWER=
 ORCH_PLANE_BOT_TESTER=
 ORCH_PLANE_BOT_DEPLOYER=
 ORCH_PLANE_BOT_STREAM=
-# ORCH-117: sandbox-only fail-closed guard for Plane WRITES from a test/worktree
-# process (regression of ORCH-114, where pytest mutated a live prod board issue).
-# In the live runtime (uvicorn, no pytest) the guard is a no-op; in a test process
-# it BLOCKS every Plane write unless BOTH the opt-in is true AND the target project
-# is in the sandbox allowlist. Defaults are SAFE (default-deny): leave both as-is.
-#   ORCH_PLANE_TEST_WRITE_ENABLED -> opt-in for REAL Plane writes from a test process.
-#     false (default) = no test may write to Plane. NOT a kill-switch for the prod
-#     block: even true, only the sandbox allowlist below is writable (a prod write
-#     from pytest stays impossible).
-#   ORCH_PLANE_TEST_SANDBOX_PROJECTS -> CSV allowlist of sandbox project ids the
-#     opt-in may write to. Default = the single SANDBOX project; empty = none.
-ORCH_PLANE_TEST_WRITE_ENABLED=false
-ORCH_PLANE_TEST_SANDBOX_PROJECTS=8c5a3025-4f9d-4190-b79f-fa06276bb27e
 # Telegram live-tracker / alerts (empty -> notifications are logged, not sent).
 ORCH_TELEGRAM_BOT_TOKEN=
 ORCH_TELEGRAM_CHAT_ID=
@@ -120,30 +107,6 @@ ORCH_AGENT_EFFORT_DEPLOYER=medium
 # (G4 NOT enabled, ADR-001 ORCH-74: determinism — all agents stay on opus-4-8). A
 # non-empty value is validated by the SAME predicate as the model; a typo is dropped.
 ORCH_AGENT_FALLBACK_MODEL=
-
-# ── Agent timeout / wall-clock budgets (ORCH-7, raised per-role ORCH-109) ─────
-# The in-process watchdog kills a run that exceeds its wall-clock budget
-# (SIGTERM -> grace -> SIGKILL, exit_code=-9). _resolve_timeout ladder (highest
-# first): OVERRIDES_JSON[agent] > dedicated role key > SECONDS (global default).
-#   SECONDS                -> global default budget for every role WITHOUT a raised
-#                             key (analyst/architect/tester/deployer).
-#   KILL_GRACE_SECONDS     -> pause between SIGTERM and SIGKILL so claude can flush
-#                             artifacts before the hard kill.
-#   OVERRIDES_JSON         -> optional per-agent override object, e.g.
-#                             {"reviewer":3600,"architect":2700}; wins for ANY role.
-#                             Malformed JSON -> ignored + WARNING (never-break).
-# ORCH-109: the two HEAVY roles get raised dedicated budgets (defaults = prod, so an
-# empty .env reproduces prod — ORCH-101 canon). A non-positive value falls back to
-# SECONDS + WARNING.
-#   DEVELOPER_S            -> developer budget (xhigh, coding/agentic bottleneck), 60m.
-#   REVIEWER_S             -> reviewer budget (large diff + high reasoning), 50m.
-# CROSS-INVARIANT (ORCH-065): ORCH_REAPER_MAX_RUNNING_S MUST stay > max(budget)+grace;
-# it is raised to 5400 in lockstep below (5400 > 3600 + 20 = 3620).
-ORCH_AGENT_TIMEOUT_SECONDS=1800
-ORCH_AGENT_KILL_GRACE_SECONDS=20
-ORCH_AGENT_TIMEOUT_OVERRIDES_JSON=
-ORCH_AGENT_TIMEOUT_DEVELOPER_S=3600
-ORCH_AGENT_TIMEOUT_REVIEWER_S=3000
 # ORCH-042/ORCH-067: live-tracker mode. bump (DEFAULT since ORCH-067) -> on every
 # update the old card is deleted and a fresh one is sent silently to the BOTTOM of
 # the chat (deleteMessage + sendMessage + repoint), so the current status is always
@@ -177,32 +140,11 @@ ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S=3
 #   DEFER_MAX_ATTEMPTS -> defer retries before escalation (avoids livelock).
 ORCH_MERGE_GATE_ENABLED=true
 ORCH_MERGE_GATE_REPOS=
-# ORCH-110 (D5): re-test budget raised 600 -> 900 (74% headroom over the observed
-# 516.7s suite). Cross-invariant (ORCH-065/109): keep ORCH_REAPER_MAX_RUNNING_S
-# (5400) > Σ(deploy-staging gate-work) + grace if you raise this — see
-# docs/work-items/ORCH-110/07-infra-requirements.md.
-ORCH_MERGE_RETEST_TIMEOUT_S=900
+ORCH_MERGE_RETEST_TIMEOUT_S=600
 ORCH_MERGE_RETEST_TARGET=tests/
 ORCH_MERGE_LOCK_TIMEOUT_S=300
 ORCH_MERGE_DEFER_DELAY_S=60
 ORCH_MERGE_DEFER_MAX_ATTEMPTS=5
-# ORCH-110: merge-gate re-test infra-timeout tolerance + tree-kill of the
-# orchestrator-spawned pytest subprocess (re-test + coverage). Each default = the
-# desired prod behaviour; each flag is an independent kill-switch (off ->
-# byte-for-byte pre-ORCH-110). The tree-kill grace reuses ORCH_AGENT_KILL_GRACE_SECONDS.
-#   SUBPROCESS_TREE_KILL_ENABLED          -> D1: spawn re-test/coverage pytest in its
-#       own process group; tree-kill the WHOLE group on timeout (no orphan grandchildren).
-#   MERGE_RETEST_INFRA_TOLERANCE_ENABLED  -> D3: a re-test TIMEOUT is a transient
-#       (bounded infra-retry, NOT a code-fault rollback to development).
-#   MERGE_RETEST_INFRA_MAX_RETRIES        -> D3: infra-retry budget before an infra-alert.
-#   MERGE_RETEST_INFRA_RETRY_DELAY_S      -> D3: delay before the staging-deployer re-run.
-#   MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED-> D4: skip the local re-test when the
-#       pre-merge rebase was a proven no-op (HEAD already CI/tester/staging-validated).
-ORCH_SUBPROCESS_TREE_KILL_ENABLED=true
-ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED=true
-ORCH_MERGE_RETEST_INFRA_MAX_RETRIES=2
-ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S=120
-ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED=true
 # ORCH-026 Level A: unconditional pre-merge rebase. With the flag ON (default),
 # check_branch_mergeable ALWAYS rebases the branch onto origin/main under the held
 # merge-lease (not only when behind) — a deterministic structural anti-phantom on
@@ -230,28 +172,9 @@ ORCH_TASK_DEPS_SOURCE=db
 #   SERIAL_GATE_ENABLED=false -> claim AND start_pipeline are 1:1 as before ORCH-088.
 #   SERIAL_GATE_REPOS (CSV) -> scope; EMPTY = ALL repos (not self-hosting-only).
 #   SERIAL_GATE_FREEZE_ENABLED=false -> the rollback-freeze layer is off (not set/read).
-#   SERIAL_GATE_PAUSE_ENABLED (ORCH-124) -> per-task "park" axis. true (default) -> a
-#     task with tasks.paused_at NOT NULL (POST /serial-gate/pause?work_item=<id>) is
-#     excluded from the "active task" predicate so an URGENT successor may overtake a
-#     paused predecessor. TRUE no-op until an operator pauses a task. false -> pause-term
-#     omitted, serial-gate byte-for-byte ORCH-088/090. Scope reuses SERIAL_GATE_REPOS.
 ORCH_SERIAL_GATE_ENABLED=true
 ORCH_SERIAL_GATE_REPOS=
 ORCH_SERIAL_GATE_FREEZE_ENABLED=true
-ORCH_SERIAL_GATE_PAUSE_ENABLED=true
-# ORCH-120 (adr-0053): analyst open-questions -> Needs Input. Activates the dead
-# "analyst asks BLOCKING questions -> 01-questions.md -> Needs Input" path in
-# _handle_analysis_approved_flow. Additive, never-raise, self-hosting scope;
-# STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict / DB schema UNCHANGED.
-#   ANALYST_QUESTIONS_GATE_ENABLED=false -> _handle_analysis_approved_flow runs its
-#     ORIGINAL pre-ORCH-120 order (files_ok first, then flat isfile check) byte-for-byte.
-#   ANALYST_QUESTIONS_GATE_REPOS (CSV) -> scope; EMPTY = self-hosting only (orchestrator).
-#   ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED=true (default) -> auto-park a Needs-Input task
-#     (db.set_task_paused) so the repo serial-gate FIFO does not wedge while we wait for a
-#     human; unpark on resume. false -> operator-park only (POST /serial-gate/pause).
-ORCH_ANALYST_QUESTIONS_GATE_ENABLED=true
-ORCH_ANALYST_QUESTIONS_GATE_REPOS=
-ORCH_ANALYST_NEEDS_INPUT_AUTOPAUSE_ENABLED=true
 # ORCH-090: STOP-status task cancellation (stop active agent + full progress reset)
 # and the relaunch-hole close. A dedicated Plane "STOP" status (logical key `stop`,
 # fail-closed: absent from _DEFAULT_STATES, so a board without the status -> no-op)
@@ -282,32 +205,6 @@ ORCH_STOP_STATUS_REPOS=
 ORCH_BUG_FAST_TRACK_ENABLED=true
 ORCH_BUG_FAST_TRACK_LABEL=Bug
 ORCH_BUG_FAST_TRACK_REPOS=
-# ORCH-020: task-estimation side-mechanism, triggered by the operator Plane status
-# «Оценка» (3rd action-status, family STOP/Confirm Deploy). A leaf src/estimator.py
-# (never-raise) forecasts cost/time/tokens/story-points from the history of completed
-# tasks (deterministic, NO LLM), writes the forecast to Plane (estimate_point + comment),
-# the Telegram card and the additive task_estimates ledger, then returns the issue to
-# Backlog. On completion the fact is written to Plane `point`. OBSERVER/PRODUCER, never a
-# Quality Gate / stage. Infra precondition: create a board status «Оценка» (group
-# backlog/unstarted, NEVER completed/cancelled) + a Points estimate-system 1,2,3,5,8.
-#   ESTIMATOR_ENABLED=false   -> the «Оценка» status is not handled, nothing written
-#                                (1:1 as before ORCH-020, zero regression).
-#   ESTIMATOR_REPOS (CSV)     -> scope; EMPTY = self-hosting only (orchestrator).
-#   ESTIMATOR_MIN_SAMPLES     -> history size below which the bootstrap default blends in.
-#   ESTIMATOR_BOOTSTRAP_*     -> cold-start tokens/cost_usd/seconds when history is empty.
-#   ESTIMATOR_SP_COST_THRESHOLDS -> 4 ascending cost cut-offs (t1,t2,t3,t5) for the
-#                                story-point bucket (<=t1->1 .. <=t5->5, else 8).
-#   ESTIMATOR_WALL_CAP_S      -> cap on anomalous wall-time in history (default 24h).
-#   ESTIMATOR_MAX_INFLIGHT    -> optional bulk-smoothing semaphore (v1 generous/off).
-ORCH_ESTIMATOR_ENABLED=true
-ORCH_ESTIMATOR_REPOS=
-ORCH_ESTIMATOR_MIN_SAMPLES=3
-ORCH_ESTIMATOR_BOOTSTRAP_TOKENS=2000000
-ORCH_ESTIMATOR_BOOTSTRAP_COST_USD=3.0
-ORCH_ESTIMATOR_BOOTSTRAP_SECONDS=1800
-ORCH_ESTIMATOR_SP_COST_THRESHOLDS=0.50,2.00,5.00,12.00
-ORCH_ESTIMATOR_WALL_CAP_S=86400
-ORCH_ESTIMATOR_MAX_INFLIGHT=64
 # ORCH-094: terminal-window-aware guard for the three deploy-phase Plane status
 # setters (set_issue_awaiting_deploy / set_issue_deploying / set_issue_monitoring).
 # A DB stage=done task converges to Done idempotently instead of flapping
@@ -398,15 +295,6 @@ ORCH_DEPLOY_PROD_TARGET_IMAGE=orchestrator-orchestrator
 ORCH_DEPLOY_PROD_COMPOSE_PROFILE=
 ORCH_DEPLOY_PROD_PREV_IMAGE_FILE=.deploy-prev-image-prod
 
-# ORCH-112: deploy-base checkout-hygiene (resilient-pull). The self-deploy hook
-# converges a DIRTY shared deploy-base to a clean, current origin/main BEFORE the
-# `git pull` (git fetch + reset --hard + a SCOPED `git clean -fd`, NEVER `-x`), so
-# manual/abandoned WIP left by a failed/cancelled task never blocks the deploy
-# (incident ORCH-111). False -> bare `git pull origin main` 1:1 as before ORCH-112.
-# Empty REPOS -> only the self-hosting repo (orchestrator).
-ORCH_CHECKOUT_HYGIENE_ENABLED=true
-ORCH_CHECKOUT_HYGIENE_REPOS=
-
 # ORCH-058: staging-image provenance before the BUILD-ONCE prod retag (INV-FRESH).
 # Guarantees the staging image promoted to prod is the EXACT artefact rebuilt from the
 # validated commit — two layers, self-hosting only:
@@ -477,8 +365,6 @@ ORCH_PLANE_STATES_TTL_S=300
 #   REAPER_INTERVAL_S       -> background scan period (seconds).
 #   REAPER_DEAD_TICKS       -> consecutive dead-pid ticks before reaping (Tier-1, >=2).
 #   REAPER_MAX_RUNNING_S    -> Tier-3 backstop ceiling; must exceed max agent_timeout+grace.
-#                              ORCH-109: raised 3600 -> 5400 in lockstep with the developer
-#                              budget (5400 > 3600 + 20 = 3620).
 #   REAPER_FINALIZE_GRACE_S -> Tier-2 grace: how long agent_runs.exit_code must have been
 #                              recorded before a still-'running' job is reaped; MUST exceed
 #                              the max finalization window (git push + PR + Plane comments).
@@ -488,50 +374,10 @@ ORCH_PLANE_STATES_TTL_S=300
 ORCH_REAPER_ENABLED=true
 ORCH_REAPER_INTERVAL_S=60
 ORCH_REAPER_DEAD_TICKS=2
-ORCH_REAPER_MAX_RUNNING_S=5400
+ORCH_REAPER_MAX_RUNNING_S=3600
 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`)
-# so a concurrent OR post-restart re-entry into a side-effectful transition (reaper /
-# reconciler / webhook / startup-requeue) is deferred or a no-op instead of re-applying
-# an irreversible effect (merge_pr / coverage-ratchet / image-rebuild / prod-deploy
-# initiation / contradictory rollback<->done). Two layers, both gated by the SINGLE
-# kill-switch below: (1) a durable lease on ENTRY to the side-effectful region (a second
-# actor that sees a live owner does not start the heavy sub-gates at all); (2) an
-# expected-stage CAS on the stage WRITE (a lost race -> abort with NO side effect), which
-# also closes the paths that write the stage in bypass of advance_stage. Owner liveness =
-# owner_pid + owner_boot_id (NOT a heartbeat), so restart recovery is free (new process ->
-# new boot_id -> all prior leases instantly stale -> reclaimed). The lease has NO own TTL:
-# its hard age ceiling IS the reaper Tier-3 backstop (ORCH_REAPER_MAX_RUNNING_S), so the
-# cross-cutting budget invariant ORCH-065/109/110/113 is untouched. STAGE_TRANSITIONS /
-# QG_CHECKS / check_* / machine-verdict keys / existing table schemas — byte-for-byte.
-#   TRANSITION_LEASE_ENABLED -> SINGLE kill-switch. false -> the lease is neither written
-#                               nor read AND the CAS degenerates to the prior unconditional
-#                               update_task_stage -> behaviour byte-for-byte as before
-#                               ORCH-114 (reaper -> ORCH-113 in-memory fallback,
-#                               reconciler/webhook skip-guard inert). Default true.
-#   TRANSITION_LEASE_REPOS   -> CSV scope. Empty -> applies ONLY to the self-hosting repo
-#                               (orchestrator), where the irreversible side-effectful edges
-#                               live; non-empty -> only the listed repos. Mirrors
-#                               ORCH_COVERAGE_GATE_REPOS -> enduro untouched at the default.
-ORCH_TRANSITION_LEASE_ENABLED=true
-ORCH_TRANSITION_LEASE_REPOS=
-
 # ORCH-063: disk-watchdog — background heartbeat that measures HOST-FS fill via the
 # mounted bind-paths (/repos, /app/data) with shutil.disk_usage (NOT the container
 # overlay /) and Telegram-alerts the operator at >= threshold. On 07.06.2026 the
@@ -614,62 +460,6 @@ ORCH_COVERAGE_EPSILON=0.5
 ORCH_COVERAGE_TOOL_FAIL_CLOSED=false
 ORCH_COVERAGE_RUN_TIMEOUT_S=900
 
-# ORCH-115: deterministic staging-runner replacing the LLM `deployer` on the
-# `deploy-staging` stage (self-hosting orchestrator). Intercepted in launch_job
-# BEFORE _spawn (deploy-finalizer / post-deploy-monitor precedent): runs the same
-# staging suite, maps exit-code -> staging_status:, writes 15-staging-log.md and
-# initiates the UNCHANGED check_staging_status gate. Replaces only the producer of
-# the artifact; the gate / STAGE_TRANSITIONS / DB schema are byte-for-byte unchanged.
-# See ADR-001-deterministic-staging-runner.md / adr-0048.
-#   STAGING_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM deployer
-#                                        runs on deploy-staging via _spawn 1:1.
-#   STAGING_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only.
-#   STAGING_RUNNER_TIMEOUT_S          -> wall-clock budget for the docker-exec suite
-#                                        (malformed/non-positive -> default 600 + WARNING).
-#   STAGING_RUNNER_INFRA_MAX_RETRIES  -> transient-infra (timeout/ssh) bounded DEFER
-#                                        budget before an infra-HOLD (anti ORCH-110).
-#   STAGING_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued deployer job.
-#   STAGING_RUNNER_EXEC_HOST_SIDE     -> ORCH-123 (adr-0049): true (default = prod) wraps
-#                                        the `docker exec` in `ssh <user@host> '<...>'` so
-#                                        the suite runs HOST-SIDE (the prod container ships
-#                                        no docker CLI; incident ORCH-116). false -> the
-#                                        prior in-container `docker exec` (valid only where
-#                                        a docker CLI is baked into the image). Rollback knob.
-ORCH_STAGING_RUNNER_ENABLED=true
-ORCH_STAGING_RUNNER_REPOS=
-ORCH_STAGING_RUNNER_TIMEOUT_S=600
-ORCH_STAGING_RUNNER_INFRA_MAX_RETRIES=2
-ORCH_STAGING_RUNNER_INFRA_RETRY_DELAY_S=30
-ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=true
-
-# ORCH-116: deterministic test-runner replacing the LLM `tester` agent on the
-# `testing` stage for the self-hosting orchestrator (2nd determinization slice,
-# mirror of the ORCH-115 staging-runner). A leaf src/test_runner.py is intercepted
-# in launch_job BEFORE _spawn: it runs the SAME regression `python -m pytest <target>`
-# in the task worktree (+ optional read-only smoke), maps the exit-code -> result:
-# PASS|FAIL, writes 13-test-report.md and initiates the UNCHANGED check_tests_passed
-# gate. Replaces only the producer of the artifact; the gate / STAGE_TRANSITIONS / DB
-# schema are byte-for-byte unchanged. See ADR-001-deterministic-test-runner.md / adr-0050.
-#   TEST_RUNNER_ENABLED            -> kill-switch; false -> the prior LLM tester runs on
-#                                     testing via _spawn 1:1.
-#   TEST_RUNNER_REPOS              -> CSV scope; empty -> self-hosting only. A repo with
-#                                     no resolvable test-contract is never intercepted (BR-9).
-#   TEST_RUNNER_TARGET            -> pytest target of the test-contract (default tests/).
-#   TEST_RUNNER_TIMEOUT_S          -> wall-clock budget for the pytest regression
-#                                     (malformed/non-positive -> default 900 + WARNING).
-#   TEST_RUNNER_SMOKE_ENABLED      -> optional read-only smoke (/health,/status,/queue +
-#                                     serial_gate block); false -> pytest exit-code is the sole signal.
-#   TEST_RUNNER_INFRA_MAX_RETRIES  -> tool-error (suite did NOT execute) bounded DEFER
-#                                     budget before a fail-closed FAIL (anti ORCH-110).
-#   TEST_RUNNER_INFRA_RETRY_DELAY_S-> delay before the re-queued tester job.
-ORCH_TEST_RUNNER_ENABLED=true
-ORCH_TEST_RUNNER_REPOS=
-ORCH_TEST_RUNNER_TARGET=tests/
-ORCH_TEST_RUNNER_TIMEOUT_S=900
-ORCH_TEST_RUNNER_SMOKE_ENABLED=true
-ORCH_TEST_RUNNER_INFRA_MAX_RETRIES=2
-ORCH_TEST_RUNNER_INFRA_RETRY_DELAY_S=30
-
 # ORCH-057 (follow-up ORCH-040): legacy root-owned ownership detect + actionable
 # worktree error. After the uid migration (user: "1000:1000") legacy root:root files
 # in /repos broke worktree creation under uid 1000 with a raw "Permission denied".
@@ -753,12 +543,6 @@ ORCH_QG0_TITLE_MAX=200
 #   CONTAINERS     -> CSV of container names to watch (status != running/healthy).
 #   DOCKER_SOCK    -> path to the read-only docker.sock inside the container.
 #   DEPS           -> CSV of name=url dependency pings (empty -> no pings).
-#   PROC_ENABLED   -> ORCH-111 opt-in: alert on a long-lived test process (pytest)
-#                     orphaned on the host (needs `pid: host`, default OFF).
-#   PROC_AGE_MIN   -> minutes a test process may live before alerting; MUST exceed
-#                     max(merge_retest_timeout_s, coverage_run_timeout_s)/60.
-#   PROC_PATTERNS  -> CSV of cmdline substrings that mark the test-class (pytest).
-#   PROC_COOLDOWN_S-> per-signal re-alert throttle for proc_blocking.
 #   TG_BOT_TOKEN / TG_CHAT_ID -> the sidecar's OWN Telegram bot/chat (independent
 #                     of the orchestrator's; absent -> logs, does not send).
 WATCHDOG_ENABLED=true
@@ -778,9 +562,5 @@ WATCHDOG_QUEUE_DEPTH=20
 WATCHDOG_CONTAINERS=orchestrator
 WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
 WATCHDOG_DEPS=
-WATCHDOG_PROC_ENABLED=false
-WATCHDOG_PROC_AGE_MIN=60
-WATCHDOG_PROC_PATTERNS=pytest
-WATCHDOG_PROC_COOLDOWN_S=1800
 WATCHDOG_TG_BOT_TOKEN=
 WATCHDOG_TG_CHAT_ID=

.env.watchdog.example

@@ -38,15 +38,5 @@ WATCHDOG_QUEUE_DEPTH=20
 WATCHDOG_CONTAINERS=orchestrator
 WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
 WATCHDOG_DEPS=
-# proc_blocking (ORCH-111): opt-in алерт на долго живущий осиротевший тест-процесс
-# (pytest), репарентированный на хост. Требует `pid: host` на сервисе
-# orchestrator-watchdog (compose) — привилегия только у наблюдателя, read-only.
-# Дефолт-off → нулевая регрессия. PROC_AGE_MIN ОБЯЗАН превышать
-# max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)/60 = 15 мин, иначе
-# легитимный прогон даст ложный алерт. 60 мин = 4× запас.
-WATCHDOG_PROC_ENABLED=false
-WATCHDOG_PROC_AGE_MIN=60
-WATCHDOG_PROC_PATTERNS=pytest
-WATCHDOG_PROC_COOLDOWN_S=1800
 WATCHDOG_TG_BOT_TOKEN=
 WATCHDOG_TG_CHAT_ID=

.openclaw/agents/analyst.md

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

.openclaw/agents/deployer.md

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

.openclaw/agents/tester.md

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

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-108
+Work item: ORCH-011
 Repo: orchestrator
-Branch: feature/ORCH-108-19c40858
+Branch: feature/ORCH-011-
 Stage: development

CHANGELOG.md

@@ -3,136 +3,6 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
-- **Оценка задачи, запускаемая Plane-статусом «Оценка»** (ORCH-020, `feat`): новый операторский
-  Plane-статус **«Оценка»** — третий член семейства action-статусов (STOP/Confirm Deploy) — запускает
-  **новый leaf `src/estimator.py`** (never-raise, kill-switch + скоуп), прогнозирующий
-  **стоимость / время / токены / сложность (story points `{1,2,3,5,8}`)** по истории завершённых задач
-  (детерминированная эвристика, **без LLM** — ADR-001 D1). Перевод issue в «Оценка» (в т.ч. **массово**
-  через Plane multi-select → N независимых вебхуков) → `handle_estimate`: прогноз (a) пишется в Plane-поле
-  `estimate_point` (через estimate-систему Fibonacci) + Plane-комментом, (b) добавляется пунктом «Оценка»
-  (время·токены·стоимость·SP) в Telegram-карточку, (c) сохраняется в **новой аддитивной таблице**
-  `task_estimates` (UPSERT по `work_item_id` → идемпотентная пере-оценка), после чего issue **возвращается
-  в Backlog** (анти-loop: Backlog не совпадает ни с одной триггер-веткой). По завершении задачи (переход в
-  `done`) **факт** (из `usage.py`) пишется в Plane-поле `point` (не затирая прогноз). Анти-disruption:
-  issue с активным job не выдёргивается (`should_estimate`). story-points — чистая функция-бакетизатор по
-  стоимости (пороги конфигурируемы). **Инвариант (NFR-1/NFR-3):** оценка — наблюдатель/продюсер, **не**
-  Quality Gate и **не** ребро стадий — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи/схемы
-  существующих таблиц байт-в-байт не тронуты; горячий путь `resolve_agent_model`/`_spawn` не трогается.
-  Fail-closed: ключ `estimate` отсутствует в `_DEFAULT_STATES` → доска без статуса → ветка инертна
-  (зеркало STOP/Confirm Deploy). Опц. эндпоинты `POST /estimate`/`GET /estimate` (то же ядро) + read-only
-  блок `estimator` в `GET /queue`. Флаги `ORCH_ESTIMATOR_*` (`enabled` kill-switch, `repos` CSV — **пусто →
-  self-hosting only**, bootstrap-дефолты, пороги story-points). Откат = `ORCH_ESTIMATOR_ENABLED=false` →
-  модуль инертен (нулевая регрессия; enduro не затронут). Онбординг-канон расширен 23-м статусом «Оценка»
-  (группа `unstarted`, НЕ терминальная). Витрина системы `docs/overview/` обновлена под новую
-  операторскую способность «Оценка» (бизнес-способность + сценарий в `business.md`, слайды
-  `presentation.md`, статус-жест в `tech-pipeline.md`/`tech-integrations.md`, таблица
-  `task_estimates` в `tech-data-model.md`, блок `estimator`/пункт карточки в `tech-observability.md`;
-  переформулировано устаревшее «управляющих статусов ровно три» → семейство операторских
-  статусов-действий). Покрытие — `tests/test_orch020_estimator.py` (TC-01…TC-20) +
-  `tests/test_orch020_estimator_branches.py` (ветви never-raise / fail-safe / edge: история-форкаст,
-  bootstrap-блендинг, все `except`-арки leaf'а, малформ-входы бакетизатора, опц. `/estimate`-эндпоинты,
-  парс estimate-системы Plane и degenerate-пути вебхука — `src/estimator.py` 74%→99.5%, гейт покрытия
-  `src/` зелёный). Детали —
-  `docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md`, сквозной
-  `docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`.
-- **FAQ по статусу STOP для пользователя доски** (ORCH-108, `docs`): создан пользовательский
-  FAQ `docs/operations/FAQ_STOP.md` в формате «вопрос → ответ» — что делает STOP, как отменить
-  задачу, что происходит пошагово (агент останавливается → job'ы снимаются → рабочая ветка и
-  worktree удаляются → задача → `cancelled` → Telegram+Plane; **docs-артефакты сохраняются**,
-  `main`/прод не трогаются), отложенная отмена в критичном окне (merge/deploy), явное «STOP **не
-  откатывает** влитый в `main`/прод код» (revert — отдельная задача), перезапуск только через
-  «To Analyse» с нуля, причины no-op («ничего не произошло»), где увидеть результат, и разведение
-  STOP/Approved/Confirm Deploy. **docs-only:** `src/**` / `STAGE_TRANSITIONS` / `QG_CHECKS` /
-  `check_*` / machine-verdict / схема БД — байт-в-байт не тронуты; поведение STOP — источник истины
-  ORCH-090 (`adr-0026`), FAQ его лишь документирует и ссылается, не форкая (link-first: машинные
-  детали маркеры/lease/тумбстон — только ссылками). Добавлены двусторонние перекрёстные ссылки:
-  витрина `docs/overview/business.md` (Сценарий 6) и обзор `docs/overview/tech-pipeline.md`
-  («Отмена: STOP → `cancelled`») → FAQ; FAQ → обзор + ADR ORCH-090. Структуру FAQ закрывает
-  детерминированный анти-дрейф тест `tests/test_faq_stop_doc.py` (offline, без сети/LLM/subprocess;
-  образец `tests/test_lite_setup_doc.py`): существование + 8 секций-якорей + факты-«кирпичи» +
-  кросс-ссылки + **негативный скан запрещённых утверждений на уровне предложений, а не голых
-  подстрок** (не фолзит на корректно отрицающих фразах — TR-3, проверено non-evergreen-самочеком).
-  **Норматив сопровождения:** правишь поведение STOP (`src/cancel.py` / `cancel_task` / маршрут
-  `stop`) → обнови `docs/operations/FAQ_STOP.md` в том же PR. ADR:
-  `docs/work-items/ORCH-108/06-adr/ADR-001-faq-stop-placement-and-anti-drift.md`.
-- **Source-backed `00-business-request.md` вместо хардкода `TBD`** (ORCH-119, `fix`, Bug-трек): раздел «Description» файла `00-business-request.md` теперь несёт **фактический текст запроса** из Plane-issue (`description`/`description_stripped`) вместо литерала `TBD` — терялся source-backed контекст запроса. Фикс работает на **обоих** путях создания: прямой (путь A, `serial_gate` не применим — `start_pipeline` передаёт `description` в `_create_initial_docs`) и **отложенный срез ветки** (путь B, ORCH-088, доминирует на self-hosting `orchestrator`). Для пути B `description` **персистится durable** при создании задачи (аддитивная колонка `tasks.description` через `_ensure_column`, зеркало `tasks.title`, записывается **внутри того же атомарного INSERT** `create_task_atomic` — race-safe относительно анти-dup-claim ORCH-053) и читается из строки `tasks` в `launcher._spawn` → `_materialize_deferred_branch` на момент claim (без сетевого вызова в горячем пути, NFR-4). **Fail-safe (FR-4):** пустое/whitespace/`None`/нечитаемое описание → явный безопасный маркер `_(описание отсутствует в источнике)_` через чистый рендер-хелпер `_render_business_request` (never-raise; создание задачи не падает). **Идемпотентность:** Gitea 422 (файл существует) → no-op, ранее записанное тело не перезаписывается. **Инвариант (AC-5):** `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи — байт-в-байт; единственное изменение схемы — аддитивная `tasks.description` (базовый `CREATE TABLE tasks` не тронут); анти-stale-base инвариант ORCH-088 цел (момент/условие среза не меняются — только источник данных дополняется). Обратимость — revert PR (колонка остаётся инертной). Покрытие — `tests/test_orch119_business_request.py` (TC-01 обязательный регресс red→green; TC-02…TC-07). Дополнительно в том же PR починена **тест-гермеичность** `tests/test_orch123_staging_runner_exec.py::test_r2_held_deploy_staging_not_rolled_back`: тест переиспользовал собственный (теперь смерженный в `main`) work-item id `ORCH-123`, и при дефолтном `repos_dir=/repos` staging-гейт через origin/main-fallback (`check_staging_status` → `_staging_log_from_main`) находил **реальный** `staging_status: SUCCESS`-лог ORCH-123 в `origin/main`, делая намеренно-красный гейт зелёным (флак проявлялся только в полном прогоне сьюта — singleton `repos_dir` берётся из первого импортирующего config файла, побеждая import-time `ORCH_REPOS_DIR=/tmp` этого модуля); autouse-фикстура `fresh_db` теперь пинит `repos_dir` в изолированный пустой tmp-каталог (зеркало уже пиннимого `worktrees_dir`), сохраняя проверяемость инварианта ORCH-123 R-2 (infra-held `deploy-staging` удерживается, не откатывается в `development`) независимо от порядка тестов. ADR: `docs/work-items/ORCH-119/06-adr/ADR-001-source-backed-business-request-doc.md`.
-- **Открытые вопросы аналитика → Needs Input (приоритет, неблокирование serial-gate, resume)** (ORCH-120, `fix`, трек Bug→escalate full-cycle): активирован и достроен ранее **мёртвый** путь «аналитик задаёт блокирующие вопросы → `01-questions.md` → Needs Input». Четыре согласованных изменения, аддитивно, под kill-switch, скоуп self-hosting, never-raise; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты** (поток — pre-gate-ветка движка, **не** Quality Gate; `01-questions.md` — **сигнальный** артефакт, **не** machine-verdict). (1) **Контракт + канон.** `.openclaw/agents/analyst.md` документирует канал «блокирующие вопросы → `01-questions.md`, НЕ фабриковать deliverables» + поведение на resume; новый скелет `docs/_templates/01-questions.md`; строка манифеста + примечание о префиксе `01-` в `docs/_standards/PIPELINE_DOCS.md`. (2) **Приоритет «вопросы активны» > «файлы готовы»** в `_handle_analysis_approved_flow` (DQ-3): чистая логика решения вынесена в leaf `src/analyst_questions.py` (`questions_gate_applies`/`autopause_applies`/`questions_active`), side-effects — в `stage_engine` (`_decide_analysis_outcome`/`_emit_analysis_needs_input`/`_emit_analysis_in_review`/`_emit_analysis_empty`); блокирующие вопросы достигают Needs Input даже при сфабрикованном полном пакете. (3) **Авто-park (DQ-1)** при Needs Input через ось «пауза» ORCH-124 (`db.set_task_paused`) → задача исключается из «активного» предиката serial-gate (ORCH-088), FIFO репо не клинит, пока ждём человека; **resume + unpark** в `handle_status_start` (analysis-ветка, `db.clear_task_paused`). (4) **Гигиена устаревания (DQ-2)** — детерминированный offline freshness-supersede по `mtime` (вопросы активны, пока пакет неполон ИЛИ `01-questions.md` не старше всех 4 deliverables) → полный свежий пакет supersede’ит старый файл без зависимости от LLM (нет бесконечной петли Needs Input). Флаги (`config.py`, безопасные дефолты): `analyst_questions_gate_enabled` (kill-switch) / `analyst_questions_gate_repos` (CSV; **пусто → self-hosting only**) / `analyst_needs_input_autopause_enabled` (независимый тумблер авто-park/unpark; `False` → operator-park `POST /serial-gate/pause`). off/out-of-scope → байт-в-байт как до ORCH-120 (enduro не затронут); ORCH-066 (Needs Input только у аналитика) не расширяется. Покрытие — `tests/test_orch120_analyst_needs_input.py` (TC-01 обязательный регресс: красный до фикса, зелёный после), `tests/test_orch120_serial_gate_needs_input.py`, `tests/test_orch120_resume_unpark.py`, `tests/test_orch120_questions_artifact_canon.py` + assert в `tests/test_agent_prompts_canon.py`. Витрина системы `docs/overview/` обновлена в том же PR (ось ORCH-011): абзац пауз `tech-pipeline.md` и пункт `GET /queue` в `tech-observability.md` теперь называют **два** источника паузы (оператор + авто-park движком на Needs Input), `tech-agents.md` — when-applicable сигнальный канал `01-questions.md` у `analyst` (`tests/test_system_docs.py` зелёный). ADR: `docs/work-items/ORCH-120/06-adr/ADR-001-analyst-open-questions-needs-input.md`, сквозной `docs/architecture/adr/adr-0053-analyst-open-questions-needs-input-flow.md`.
-- **Гигиена run-ownership строки `jobs` — инвариант «queued ⇒ run_id/pid/started_at IS NULL»** (ORCH-126, `fix`, трек Bug): багфикс контрол-плейна (инцидент ORCH-124/125) — при `ORCH_SERIAL_GATE_ENABLED=false` queued analyst-job'ы зависали навсегда (job 2286: `status=queued + run_id=759/760 + pid=35/42 + started_at=NULL` — физически невозможное состояние). **Причина:** ни один путь возврата job в `queued` (restart `requeue_running_jobs` / retry `mark_job('queued')` / transient `mark_job_transient` / reap `reap_running_job('queued')`) **не сбрасывал run-ownership** (`run_id`/`pid`); после рестарта контейнера pid мог быть **переиспользован** ОС → `pid_alive(stale)=True` → job-reaper (ORCH-065) Tier-1 «видел живой» фантомный `running` и при `max_concurrency=1` клинил клейм **всей** общей очереди всех проектов. **Инвариант (adr-0052):** `status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL` — queued-job никогда не несёт run-ownership (история run'а — в `agent_runs`, не в `jobs.run_id`). Фикс на **существующих колонках**: `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / `check_*` / machine-verdict-ключи / **схема БД** — байт-в-байт не тронуты; для здоровых job'ов и enduro поведение байт-в-байт; миграция не требуется. ADR: `docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md`, сквозной `docs/architecture/adr/adr-0052-queued-job-run-ownership-invariant.md`.
-  - **D1 — Forward-cleanup на всех путях возврата в `queued` (FR-1/AC-1):** `requeue_running_jobs` / `mark_job('queued')` / `mark_job_transient` / `reap_running_job('queued')` выставляют `run_id=NULL, pid=NULL` той же UPDATE-транзакцией, что чистит `started_at`/`finished_at`. Атомарные `status`-guard'ы (`reap_running_job … WHERE status='running'`, rowcount) — **сохранены байт-в-байт** (restart-safe, гонка worker↔reaper↔monitor — TR-4). Каллер-переданный `run_id` для `queued` **игнорируется** (инвариант важнее: `launcher._finalize_permanent`/reaper по-прежнему передают старый `run_id`, но для `queued` он сбрасывается). Безусловно — исправление инварианта данных, без флага (D6).
-  - **D2 — Чистый claim (FR-2/AC-3):** `claim_next_job` при флипе `queued→running` сбрасывает `pid=NULL, run_id=NULL` тем же существующим UPDATE (defense-in-depth поверх D1) → между claim и стампом `pid` в `_spawn` строка несёт `pid IS NULL`, не чужой pid. SELECT-гейт (`status='queued' AND available_at<=now` + dep/serial-gate) — **не тронут** (offline hot-path, NFR-2; без нового SELECT/сети).
-  - **D3 — Окно `_spawn` (FR-3/AC-6):** провал `_spawn` до стампа `pid` (`ensure_worktree`/материализация ветки/запись task-файла) → `queue_worker._drain_once` возвращает job через `mark_job('queued')` → по D1 строка чистая; повторный claim стартует штатно (без «частично стартовавшего» зависания). Нового кода в launcher не потребовалось.
-  - **D4 — Детект + self-heal невозможного состояния (FR-4/AC-5):** `db.find_impossible_queued_jobs()`/`db.sanitize_impossible_queued()` идемпотентно приводят «невозможные» queued-строки (`queued` с непустым `run_id`/`pid`/`started_at`) к чистому `queued`; вызывается при старте (`main.lifespan` после `requeue_running_jobs`) и на каждом реап-тике (`JobReaper.sanitize_impossible_queued_once`, never-raise) — закрывает уже-существующие аномалии на проблемной БД **без миграции** (TR-7) и забытый будущий 6-й путь возврата (TR-2). Наблюдаемость: структурный WARNING (`job_id`/`run_id`/`pid`) + read-only счётчик `impossible_queued_total`/`last_impossible_queued` в блоке `reaper` снимка `GET /queue`. Kill-switch `impossible_queued_sanitize_enabled` (env `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED`, дефолт on; гейтит **только** D4-sweep, базовый сброс D1-D3 безусловен).
-  - **D5 — Корректность reaper-liveness (FR-5/AC-4) — валидация, не правка:** после D1-D3 reaper на свежеклеймленном `running` видит `pid IS NULL` → Tier-1 (`job_reaper.py:245`: `if pid is not None and not pid_alive(pid)`) пропускает, сбрасывает streak; Tier-3 backstop (`reaper_max_running_s`) — без изменений. **Правка reaper не требуется** — фикс восстанавливает предусловие «`pid` отражает процесс ЭТОГО run'а». Маркированные инварианты ORCH-065/113/114/099 — сохранены (трассировка CLAUDE.md §9).
-  - **Покрытие:** `tests/test_orch126_queued_stale_run.py` (TC-01 — обязательный регресс, КРАСНЫЙ до фикса / ЗЕЛЁНЫЙ после: stale `running` → `requeue_running_jobs` → чистый `queued`; TC-02…TC-10: сброс на каждом пути, чистый claim, claim без старвейшна при serial-gate off, reaper не реапит `pid IS NULL`, self-heal идемпотентность + счётчик + kill-switch, окно `_spawn`, анти-регресс здорового job'а — терминальные исходы/`run_id`-линк не затронуты). Полный `pytest tests/ -q` — зелёный.
-  - **Доки:** `docs/architecture/internals.md` (раздел «Инвариант run-ownership строки `jobs`» + аннотации `jobs.run_id`/`pid` + queue-recovery), `.env.example` (флаг `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED` в блоке reaper); сквозной ADR `adr-0052` (уже заведён архитектором).
-- **Serial-gate «пауза без блокировки» — явный per-task park-сигнал** (ORCH-124, `fix`): багфикс (метка `Bug`, эскалирован в full-cycle) инцидента **ORCH-116/ORCH-123**. `serial_gate` определял «активную задачу репо» **исключительно по машинной стадии** `tasks.stage NOT IN ('done','cancelled')`, а Plane-статусы Backlog/Blocked/Needs-Input (слой B индикации, ORCH-066) **не меняют `tasks.stage`** (слой A) ⇒ приостановленный предшественник был неотличим от активного и держал FIFO-гейт закрытым против срочного успешника (ORCH-116 поставлен на паузу, чтобы пропустить фикс ORCH-123 — фикс не стартовал, пока ORCH-116 формально не `done`). У оператора не было чистого механизма «пауза без блокировки», отдельного от cancel (терминал) и от глобального выключения гейта. **Инвариант:** правка **планировщика очереди** (claim) и наблюдаемости, **не** Quality Gate — `STAGE_TRANSITIONS` / состав `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) / схемы существующих таблиц — **байт-в-байт не тронуты**. Аддитивно, под независимым под-флагом, never-raise, restart-safe, fail-OPEN на hot-claim сохранён. ADR: `docs/work-items/ORCH-124/06-adr/ADR-001-serial-gate-pause-without-blocking.md`, сквозной `docs/architecture/adr/adr-0051-serial-gate-pause-without-blocking.md`.
-  - **Механизм (D1):** явный durable DB-сигнал «park» на уровне задачи, инициируемый оператором через API — **не** маппинг Plane-статуса (перегружал бы слой A/B ORCH-066 / анти-паттерн ORCH-059) и **не** `task_deps` (моделирует обратное направление «B ждёт A»). Чистое намерение, отличное от cancel и от kill-switch; DB-резолвимо, offline, webhook-независимо (потерянный webhook не рассинхронит сигнал).
-  - **Хранилище (D2):** аддитивная нуллабельная колонка `tasks.paused_at TEXT` через `_ensure_column` (паттерн `tasks.cancelled_at`/`cancel_requested_at`/`track`; `src/db.py`) — NULL = не на паузе; ISO-таймстамп = поставлена оператором на паузу. На уже-мигрированной БД — no-op; все существующие строки дефолтят в NULL ⇒ поведение до ORCH-124 до первой явной паузы (enduro не затронут на общей прод-БД). Хелперы `db.set_task_paused`/`clear_task_paused`/`is_task_paused` (never-raise; `is_task_paused` на ошибке → «не на паузе» = задача активна = гейт скорее закрыт = анти-stale-base-safe).
-  - **Ортогональная ось (D3, критично):** «активность» для serial-gate = `stage NOT IN ('done','cancelled') AND paused_at IS NULL`; **терминал `{done,cancelled}` остаётся байт-в-байт** в `serial_gate`/`task_deps`/`stages.py` (adr-0026 не регрессирует). `task_deps`/`stages.py` колонку `paused_at` **НЕ читают** ⇒ паузнутая объявленная зависимость (`job_deps`) и `repo_freeze` **по-прежнему блокируют** claim (пауза их **не** обходит — разные оси: freeze = весь репо, dependency = конкретная пара, пауза = «пропустите меня в FIFO»).
-  - **Три точки согласованно (D4, анти-дрейф):** один предикат «активна» под под-флагом — терм `AND t2.paused_at IS NULL` внутри существующего `EXISTS`-подзапроса `build_claim_clause` (горячий offline SQL, без лишнего JOIN), `AND paused_at IS NULL` в `repo_has_active_task` и в выборе `active_task` `_per_repo_snapshot` (`src/serial_gate.py`). Помечено маркером `ORCH-124` рядом с `ORCH-088`/`ORCH-090`.
-  - **Операторские эндпоинты (D7):** `POST /serial-gate/pause?work_item=<id>` (стамп `paused_at`; терминальная/неизвестная задача → no-op-ответ; под-флаг off → no-op-предупреждение) и `POST /serial-gate/resume?work_item=<id>` (сброс `paused_at` → задача снова участвует в гейте; идемпотентно) — по образцу `POST /serial-gate/unfreeze`, never-raise, с Telegram-подтверждением (`src/main.py`).
-  - **Анти-stale-base при resume (D8, R-1):** новой rebase-машинерии **нет** — свежесть базы гарантируют существующие механизмы: паузнутая-в-`analysis` задача при resume режет ветку отложенно (ORCH-088) от свежего `origin/main` с кодом успешника; материализованная — ребейзится на merge-gate (`auto_rebase_onto_main` под merge-lease ORCH-026/093) + re-test (ORCH-110). Нормальная задача (`paused_at IS NULL`) по-прежнему держит гейт ⇒ анти-stale-base для нормального случая (ORCH-088) **не регрессирует**.
-  - **Наблюдаемость (D5):** блок `serial_gate` в `GET /queue` дополнен ключом `paused` (список приостановленных незавершённых задач репо — НЕ показываются как `active_task`) и `reason` ожидания у каждого waiting-job с приоритетом `freeze` → `dependency` → `active-task` → `null`; существующие ключи снапшота (`active_task`/`waiting`/`frozen`/`frozen_reason`/`frozen_at`) — байт-в-байт (BC).
-  - **Условность/откат (D6):** независимый под-флаг `serial_gate_pause_enabled` (env `ORCH_SERIAL_GATE_PAUSE_ENABLED`, дефолт `True`; зеркало `serial_gate_freeze_enabled`; область переиспользует `serial_gate_repos`, новый `*_repos` не вводится). Дефолт `True` — **истинный no-op** до явной операторской паузы (`paused_at` всюду NULL). `False` ⇒ pause-терм опущен из SQL, эндпоинты no-op, serial-gate **байт-в-байт ORCH-088/090** (осознанный rollback-режим). Глубже — `serial_gate_enabled=false`.
-  - **Покрытие:** `tests/test_orch124_serial_gate_pause.py` (TC-01 обязательный регресс инцидента ORCH-116/ORCH-123 — красный до фикса, зелёный после; TC-02…TC-15: анти-регресс ORCH-088, durable/restart, resume, сохранность freeze/dependency, снапшот-reason, анти-дрейф 3 точек, offline hot-path, never-raise/fail-OPEN, kill-switch-нейтральность, структурный анти-регресс реестров/схем).
-  - **Доки:** обновлены `docs/architecture/README.md` (раздел serial-gate + ось «пауза без блокировки») и `docs/architecture/internals.md` (ось «пауза» ⊥ оси «терминальность»); сквозной ADR `adr-0051`. **Витрина системы `docs/overview/` (ORCH-011, синхронно в том же PR):** `tech-pipeline.md` (исключение FIFO «пауза без блокировки» рядом с freeze), `tech-data-model.md` (durable-сигнал `tasks.paused_at`), `tech-observability.md` (`paused`/`reason` в блоке `serial_gate` `GET /queue` + эндпоинты `pause|resume`). Зачищены протёкшие хвостовые теги tool-call (`</content>`/`</invoke>`) в 4 golden-source доках этого PR (`06-adr/ADR-001`, `adr-0051`, `08-data-requirements.md`, `10-tech-risks.md`).
-  - **Тест-гигиена (development-стадия, латентный регресс ORCH-123):** изолирован `settings.repos_dir` в фикстуре `tests/test_orch123_staging_runner_exec.py` (зеркально уже имевшейся изоляции `worktrees_dir`). `check_staging_status` при отсутствии фиче-worktree фолбэчит на `<repos_dir>/<repo>` (и его `origin/main`); после мержа ORCH-123 реальный `/repos/orchestrator/docs/work-items/ORCH-123/15-staging-log.md` (вердикт SUCCESS) появился на диске и делал предполагавшийся-КРАСНЫМ staging-гейт в `test_r2_held_deploy_staging_not_rolled_back` зелёным при полном прогоне `pytest tests/` (order-dependent: тест проходил в одиночку, падал в сьюте). Инвариант ORCH-123 R-2 («held `deploy-staging` не откатывается на `development`», adr-0049/ADR-001 D4) **сохранён и усилен** — изоляция лишь восстанавливает заявленную предпосылку теста «15-staging-log.md отсутствует ⇒ гейт красный». `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*` не тронуты (правка только теста).
-- **Детерминированный test-раннер вместо LLM-тестера на `testing`** (ORCH-116, `feat`): второй реализованный срез determinization-roadmap (ORCH-118 A5, `needs-hybrid-fallback`) — на стадии `testing` для self-hosting `orchestrator` **LLM-агент `tester` заменён детерминированным кодом** (`src/test_runner.py`). PASS/FAIL-ядро агента было деривируемым (регресс `pytest` + read-only smoke → `result:`); каждый прогон жёг токены/время opus-агента (~60–150k / 5–20 мин) и встраивал недетерминизм LLM в точку ветвления `testing → deploy-staging` / `testing → development`. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `13-test-report.md`, гейт `check_tests_passed`/`_parse_tests_verdict`, `STAGE_TRANSITIONS`, machine-verdict `result:` (+ legacy `verdict:`/`status:`), схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting, гибрид (LLM строго off-control-path). Эталон — `src/staging_runner.py` (ORCH-115). ADR: `docs/work-items/ORCH-116/06-adr/ADR-001-deterministic-test-runner.md`, сквозной `docs/architecture/adr/adr-0050-deterministic-test-runner.md`.
-  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="tester" and test_runner.should_intercept(job)` → `_run_test_runner_job` (зеркало `_run_staging_runner_job`, прецедент `deploy-finalizer`/`post-deploy-monitor`/`staging-runner` `launcher.py:397/402/405`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`, нет токенов). Дискриминатор — роль `tester` **И** стадия задачи `testing` (defense-in-depth: `tester` — единственный агент входа в `testing`, коллизии стадий нет, в отличие от общей роли `deployer`) **И** `applies(repo)`; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути).
-  - **Leaf `src/test_runner.py` (новый, чистый never-raise):** по образцу `staging_runner`/`self_deploy`/`proc_group` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`self_deploy`/`qg.checks`/`stage_engine`/`notifications` — лениво). `applies(repo)` = kill-switch `test_runner_enabled` + скоуп `test_runner_repos` (пусто → self-hosting only) **И** резолв тест-контракта `_has_test_contract` (BR-9: репо без контракта → `False` → LLM-tester — enduro-trails 1:1 как до ORCH-116, даже если руками добавлен в CSV). Исполняет регресс `python -m pytest <test_runner_target>` **в worktree ветки** (`git_worktree.get_worktree_path`, анти checkout-гонка ORCH-112) через `proc_group.run_in_process_group` (tree-kill, таймаут `test_runner_timeout_s=900`, малформ/непозитив → дефолт + WARNING) + опц. **read-only smoke** (`/health`/`/status`/`/queue` + блок `serial_gate`, stdlib `urllib`; транзиентная недостижимость — ограниченный ретрай, не-200/нет блока — немедленный FAIL; `test_runner_smoke_enabled`). Маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе/None→`FAIL`, fail-closed; smoke-провал AND-ится в `FAIL`); пишет `13-test-report.md` (тот же machine-key `result:` UPPERCASE + 52c-схема, `author_agent: test-runner`/`model_used: n/a`) + best-effort push в **фичеветку**; вызывает **существующий** `advance_stage(current_stage="testing", finished_agent="tester")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage` — граница O1).
-  - **Анти-коллизия 52c-`status:` ↔ парсер (D6.1, специфично для tester):** `_parse_tests_verdict` читает вердикт из **трёх** равноранговых полей (`verdict:`/`status:`/`result:`) с negative-token-priority. 52c-обязательное `status:` поэтому читается тем же парсером → раннер **ВСЕГДА выравнивает** `status:` по вердикту (`PASS → status: success`, `FAIL → status: failed`) — иначе негативный токен в `status:` при `result: PASS` дал бы ложный FAIL здорового прогона. Прибито unit-тестом через **неизменённый** парсер.
-  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAIL → тот же откат `testing → development` + developer-retry, что у FAIL-вердикта LLM, `stage_engine.py:849`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue **`tester`**-джоба с задержкой + restart-safe маркер `test-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `test_runner_infra_max_retries=2` → fail-closed `FAIL` + advance + INFRA-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь, **не** жжёт developer-retry на транзиентной инфре.
-  - **Гибрид (D11/BR-8/NFR-7):** в Phase 1 на `testing` (in-scope) вердикт `result:` производит **только** детерминированный раннер; LLM **не** вызывается в потоке управления вердикта. Архитектура не запрещает будущий **off-control-path** LLM-триаж падений / маппинг TC↔критерии после детерминированного FAIL (отдельная роль/джоб, **не** выносит и **не** переопределяет `result:`, **не** добавляет ребро в `STAGE_TRANSITIONS`) — в этом срезе не реализуется. Self-hosting safety: в командах раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push / правок `.env`; smoke строго read-only. Наблюдаемость — in-process счётчики (`runs`/`pass`/`fail`/`tool_error`/`deferred`) + read-only блок `test_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `test_runner_enabled`/`test_runner_repos`/`test_runner_target`/`test_runner_timeout_s`/`test_runner_smoke_enabled`/`test_runner_infra_max_retries`/`test_runner_infra_retry_delay_s` (env `ORCH_TEST_RUNNER_*`). Откат = `ORCH_TEST_RUNNER_ENABLED=false` → на `testing` снова LLM-`tester` через `_spawn` **байт-в-байт**.
-  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A5 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет tester как `avoidable=yes`/`axis=C`/`needs-hybrid-fallback`), `llm-determinization-roadmap.md` (rank 2 tester — ✅ реализован; инвариант «ровно один `first_slice = yes`» у rank 1 deployer цел), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/tester.md` (LLM-ветвь `testing` — fallback), `docs/architecture/README.md`/`internals.md`, витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`/`tech-quality-security.md`. Покрытие — `tests/test_orch116_test_runner.py` (TC-01…TC-14) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-15).
-- **Host-side исполнение staging-раннера + классификация environment-дефекта** (ORCH-123, `fix`, bug→escalate full-cycle): устранён инцидент **ORCH-116** — детерминированный staging-раннер (ORCH-115) вызывал `docker exec` **изнутри** прод-контейнера `orchestrator`, где **нет бинаря `docker`** (образ несёт только `openssh-client git curl`, `Dockerfile:11`; `/var/run/docker.sock` смонтирован, но клиента нет) → `Popen(["docker", …])` падал `FileNotFoundError` → ветка tool-error → инфра-DEFER×2 → fail-closed `FAILED` → **ложный** откат `deploy-staging → development` (как код-фейл, с расходом developer-retry). Так до фикса **любая** self-hosting задача, дойдя до `deploy-staging`, была обречена на ложный откат. Аддитивно, под флагами, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_staging_status`/`_parse_staging_status` / machine-verdict-ключи (`staging_status:`/`deploy_status:`) / схема БД — **байт-в-байт не тронуты** (замена *стратегии исполнения продюсера* `15-staging-log.md`, **не** гейта/стадии; зеркало инварианта ORCH-115 NFR-1). ADR: `docs/work-items/ORCH-123/06-adr/ADR-001-host-side-staging-execution-and-env-classification.md`, сквозной `docs/architecture/adr/adr-0049-host-side-docker-execution-boundary.md`.
-  - **Host-side ssh-стратегия (D1):** `staging_runner.build_staging_command()` теперь обёртывает ту же `docker exec orchestrator-staging python3 … staging_check.py … --mode stub` в `ssh -o StrictHostKeyChecking=no <deploy_ssh_user>@<deploy_ssh_host> '<docker exec …>'` (зеркало `self_deploy.build_deploy_command` / `image_freshness.image_revision(ssh_target=…)`); канал — существующий доверенный (`ORCH_DEPLOY_SSH_HOST=127.0.0.1`, ssh-ключ смонтирован `:ro`, `openssh-client` в образе) → **новых секретов/привилегий не вводится** (NFR-3). Меняется **инициатор/канал** запуска, **не** сама сюита (она по-прежнему бежит **внутри** `orchestrator-staging` 8501). **Security (D2):** docker CLI/SDK в контейнер **не добавляется**, `docker.sock` **не используется изнутри** — это было бы root-эквивалентным расширением поверхности атаки (доступным и LLM-агентам); host-side ssh достигает цели без расширения привилегий.
-  - **Трёхсторонняя классификация исхода (D3, чистая `classify_staging_outcome`, зеркало `merge_gate.classify_retest_failure`):** `suite-ran` (распознанный exit-код, кроме 255, **без** env-маркера в stderr → доверяем коду: `0→SUCCESS`/`≠0→FAILED`; анти-over-tolerance BR-3 — реальный фейл сюиты **никогда** не реклассифицируется в инфру), `permanent-env` (spawn-error `rc=None` без таймаута / нет ssh-target / `rc∈{126,127}` / env-маркер `No such container`/`Cannot connect to the Docker daemon`/`command not found` → ретрай бессмыслен), `transient-infra` (timeout / ssh transport `rc=255` / неизвестный сигнал → ретрай осмыслен). Дизамбигуация коллизии `exit=1` (`docker exec` «No such container»=1 vs суита fail=1) — **скан stderr на env-маркеры**, не голый exit-код; fail-safe при неоднозначности → `transient-infra` (DEFER), никогда тихий `suite-ran`.
-  - **Маршрутизация исходов (D4) — инвариант «инфра ≠ код-фейл»:** `suite-ran` → **без изменений** (ORCH-115): write `15-staging-log.md` + `advance_stage` (FAILED → прежний откат `deploy-staging → development` + developer-retry, байт-в-байт). `permanent-env` → **немедленный infra-HOLD**: DEFER пропускается (FR-3), `15-staging-log.md` **не** пишется (нет ложного FAILED), `advance` **не** зовётся, developer-retry **не** жжётся; структурный ERROR + операторский alert «инфра/окружение, НЕ дефект кода». `transient-infra` → существующий bounded DEFER, **но на исчерпании бюджета** — тоже **infra-HOLD + alert** (СУПЕРСЕД ORCH-115 D5: прежний fail-closed `write_staging_log("FAILED") + advance` ложно откатывал не-прояснившуюся инфру как код-фейл, нарушая BR-2). Корневой инвариант: «сюита **не** исполнилась» (environment ИЛИ инфра) **никогда** не оканчивается код-фейл-откатом `→ development` и **никогда** не жжёт developer-retry — закрывает RCA-класс ORCH-110 на staging-ребре. Задача **держится** на `deploy-staging`; reconciler `advance_if_gate_passed` на red-гейте возвращает `None` (без отката, R-2 верифицирован) → оператор re-drive после починки окружения.
-  - **Prod-like preflight (D5):** `staging_runner.preflight()` (bounded, never-raise, self-hosting-скоуп — `applies()` первым) пробит host-side канал на **старте сервиса** в `main.lifespan` (best-effort, после `requeue_running_jobs`/`recover_on_startup`, **никогда не блокирует старт**): ssh-зонд `command -v docker && docker inspect -f '{{.State.Running}}' orchestrator-staging` распознаёт «нет docker на хосте» / «staging-контейнер не поднят» / «ssh недоступен» / «нет ssh-target» **до** того, как реальная задача дойдёт до ложного исхода. Чисто наблюдательный — не гейтит конвейер; лог + Telegram-алерт + поле в `snapshot()`.
-  - **Условность / обратимость (D6):** новый флаг `staging_runner_exec_host_side: bool = True` (env `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE`, дефолт = боевое) — `True` → host-side ssh; `False` → прежний in-container `docker exec` (валиден лишь там, где docker CLI запечён в образ). Переиспользуются `staging_runner_enabled`/`_repos`/`_timeout_s`/`_infra_max_retries`/`_retry_delay_s` + `deploy_ssh_user`/`deploy_ssh_host`. Откат — `ORCH_STAGING_RUNNER_EXEC_HOST_SIDE=false` (in-container 1:1) или `ORCH_STAGING_RUNNER_ENABLED=false` (LLM-deployer 1:1). Наблюдаемость (D8): счётчик `permanent_env` (infra-HOLD; отличён от `failed`=код-фейл и `deferred`=транзиент) + `exec_host_side` + `preflight` в блоке `staging_runner` `GET /queue`; один структурный лог-вердикт на прогон (`outcome ∈ {code-pass,code-fail,transient-infra,permanent-env}`).
-  - **Документация границы исполнения (D9):** `docs/operations/INFRA.md` (новый под-раздел «Граница исполнения docker-операций — host-side») + `docs/architecture/README.md` (host-side стратегия + трёхсторонняя классификация) — зафиксировано, что **все** docker-операции self-hosting (прод-деплой ORCH-036, image-freshness ORCH-058, staging-runner ORCH-123) исполняются host-side через ssh, docker CLI в контейнере нет, `docker.sock` сознательно не используется изнутри. Покрытие — `tests/test_orch123_staging_runner_exec.py` (TC-01 — обязательный регресс ORCH-116: КРАСНЫЙ до фикса / ЗЕЛЁНЫЙ после; TC-02…TC-14 + регресс R-2 «held не становится rollback») + зелёный анти-дрейф `tests/test_orch115_staging_runner.py` (TC-14: инварианты ORCH-115 целы; 3 теста обновлены под суперсед D4/D8/D1).
-- **Детерминированный staging-раннер вместо LLM-деплойера на `deploy-staging`** (ORCH-115, `feat`): первый реализованный срез determinization-roadmap (ORCH-118 A6, `replace-deterministic-now`) — на стадии `deploy-staging` для self-hosting `orchestrator` **LLM-агент `deployer` заменён детерминированным кодом** (`src/staging_runner.py`). Работа агента на этой стадии была чисто механической (запуск staging-сюиты + маппинг exit-кода `staging_check.py` → `staging_status:`); каждый прогон жёг токены/время opus-агента (~40–120k / 3–15 мин) и встраивал недетерминизм LLM в точку ветвления гейта. **Инвариант (NFR-1):** это замена *продюсера* артефакта, **не** гейта — контракт `15-staging-log.md`, гейт `check_staging_status`/`_parse_staging_status`, `STAGE_TRANSITIONS`, machine-verdict `staging_status:`, схема БД — **байт-в-байт не тронуты**. Аддитивно, под kill-switch, never-raise, fail-closed, скоуп self-hosting. ADR: `docs/work-items/ORCH-115/06-adr/ADR-001-deterministic-staging-runner.md`, сквозной `docs/architecture/adr/adr-0048-deterministic-staging-runner.md`.
-  - **Перехват в `launch_job` до `_spawn` (D1):** `if job.agent=="deployer" and staging_runner.should_intercept(job)` → `_run_staging_runner_job` (зеркало `_run_deploy_finalizer_job`, прецедент `deploy-finalizer`/`post-deploy-monitor` `launcher.py:389/394`): синхронно ведёт `jobs`-строку через `mark_job`, возвращает `None` (нет `agent_runs`-строки, нет токенов). Дискриминатор «staging vs prod» — **стадия задачи** `deploy-staging` (роль `deployer` общая для `deploy-staging`/`deploy`), не имя роли; `should_intercept` never-raise → `False` → штатный `_spawn` (fail-safe к LLM-пути). Для не-self репо `applies==False` → прод-`deployer` никогда не перехватывается.
-  - **Leaf `src/staging_runner.py` (новый, чистый never-raise):** по образцу `self_deploy`/`proc_group`/`staging_verdict` (на импорте только `config`/`proc_group`; `db`/`git_worktree`/`stage_engine`/`qg.checks`/`notifications` — лениво). Исполняет ту же сюиту (`docker exec orchestrator-staging python3 <repos_dir>/<self-repo>/scripts/staging_check.py --base-url http://localhost:<staging_port> --mode stub`, арги из config — ORCH-101, без host-хардкодов) через `proc_group.run_in_process_group` (tree-kill, таймаут `staging_runner_timeout_s=600`, малформ/непозитив → дефолт + WARNING); маппит exit-код **единым** контрактом `self_deploy.map_exit_code_to_status` (`0→SUCCESS`/иначе/None→`FAILED`, fail-closed; ORCH-061 infra-tolerance остаётся внутри `staging_check.py`, раннер не пересуживает — BR-4); пишет `15-staging-log.md` (тот же machine-key `staging_status:` UPPERCASE + 52c-схема, `author_agent: staging-runner`/`model_used: n/a`) + best-effort commit/push в **фичеветку** (не в `main` — гейт читает worktree первым, усиливает AC-8/BR-7); вызывает **существующий** `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` — без новых рёбер/исходов (transition-lease ORCH-114 берётся внутри `advance_stage`, раннер не трогает — граница O1).
-  - **Двухуровневый исход (D5, анти-ORCH-110):** сюита **исполнилась** (реальный exit-код) → verdict→advance (FAILED → тот же откат `deploy-staging → development` + developer-retry, что у FAILED-вердикта LLM, `stage_engine.py:932`); сюита **не исполнилась** (tool-error: spawn-error/таймаут/`returncode None`) → инфра-сбой ≠ код-фейл → bounded **DEFER** (re-queue `deployer`-джоба с задержкой + restart-safe маркер `staging-runner infra-retry` в `task_content`, счётчик подсчётом маркера — без правки схемы БД), на исчерпании `staging_runner_infra_max_retries=2` → fail-closed `FAILED` + advance + инфра-alert. Раннер **никогда** не делает тихий advance/ложный green, **никогда** не клинит очередь и **не** жжёт developer-retry на транзиентной инфре.
-  - **Self-hosting safety (BR-7/AC-8):** в командной строке раннера нет рестарта 8500 / `docker compose up orchestrator` / `--build` / force-push в `main` / правок `.env` — раннер только читает/исполняет staging-сюиту (8501) и пишет лог. Наблюдаемость (D10) — in-process счётчики (`runs`/`success`/`failed`/`tool_error`/`deferred`) + read-only блок `staging_runner` в `GET /queue` + один структурный лог-вердикт на прогон (различает код-фейл и tool-error). Флаги (`config.py`, дефолт = боевое): `staging_runner_enabled` (env `ORCH_STAGING_RUNNER_ENABLED`), `staging_runner_repos` (CSV; пусто → self-hosting only), `staging_runner_timeout_s`, `staging_runner_infra_max_retries`, `staging_runner_infra_retry_delay_s`. Откат = `ORCH_STAGING_RUNNER_ENABLED=false` → на `deploy-staging` снова LLM-`deployer` через `_spawn` **байт-в-байт**.
-  - **Норматив сопровождения ORCH-118 (NFR-6):** обновлены `docs/architecture/llm-call-sites.md` (A6 — реализован; машинный `ORCH-118-INVENTORY-BLOCK` сохраняет deployer как `avoidable=yes`/`axis=C` — LLM-ветвь жива как fallback), `llm-determinization-roadmap.md` (rank 1 deployer — ✅ реализован; машинный блок/инвариант «ровно один `first_slice = yes`» целы), `llm-usage-policy.md` (§5 — единственный транспорт S0 не нарушен, раннер LLM не зовёт), `.openclaw/agents/deployer.md` (LLM-ветвь `deploy-staging` — fallback), витрина `docs/overview/tech-pipeline.md`/`tech-agents.md`. Покрытие — `tests/test_orch115_staging_runner.py` (TC-01…TC-13) + зелёные `tests/test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` (TC-14).
-- **Карта LLM-консультаций + control-path-ось «avoidable» + roadmap + нормативная политика** (ORCH-118, `docs`+`test`, inventory-first, docs+tests only): зонтичный follow-up RCA-трека ORCH-114/117 — у оркестратора не было ни нормативного критерия «где LLM нужен, а где это avoidable control path», ни карты мест вызова LLM, прибитой к коду. Выпущена **доказательная карта** каждого места, где control-path потребляет (или способен потребить) суждение LLM, с control-path-разметкой и классификацией; **упорядоченный roadmap** детерминированных замен; **нормативная политика** использования LLM; набор **структурных анти-дрейф тестов**. Это **docs + tests only**: `src/**`-рантайм не меняется → `STAGE_TRANSITIONS` / реестр и имена `QG_CHECKS`/`check_*` / machine-verdict-ключи / схема БД — **байт-в-байт не тронуты**; раннеры замен **не** реализуются (FR-7); конкретные follow-up Plane-ID **не** фиксируются (R3/NFR-6 — кандидаты по роли). kill-switch не нужен (нет рантайм-поведения), как ORCH-077/079/101/102/103/011. ADR: `docs/work-items/ORCH-118/06-adr/ADR-001-llm-call-site-map-and-determinization-roadmap.md`, сквозной `docs/architecture/adr/adr-0047-llm-usage-policy-and-call-site-map.md`.
-  - **Единица инвентаря — LLM-консультация** (control-path потребляет суждение LLM), а **не** «спавн процесса / существование Claude CLI» (R4, capability ≠ consultation). Карта разводит **три ортогональных факта**: (1) consultation ≠ transport/slot (единственный транспорт LLM-консультации в `src/**` — `launcher._spawn`, `launcher.py:472`/CLI-сборка `610-614`; иного транспорта нет; job-роли `deploy-finalizer`/`post-deploy-monitor` занимают слот, но перехватываются в `launch_job` **до** `_spawn`, `launcher.py:389/394` — консультации нет); (2) **control-path (C) ≠ artifact-producer (P)** по коду-потребителю в `src/qg/checks.py` (C: гейт ветвится на LLM-вердикте; P: детерминированный гейт судит артефакт независимо — файлы/CI); (3) деривируемость вердикта из tool-сигналов.
-  - **Нормативное определение** «avoidable LLM control path» = двухбитный предикат (C-консультация **И** вердикт деривируем из exit-кодов `pytest`/smoke/`staging_check.py`/деплоя). Поимённый целевой набор (доказательно, прибит тестами): **avoidable = `{tester, deployer}`**; control-path-но-keep = `{reviewer}` (вердикт «приемлемость кода/решения» НЕ деривируем); не-control-path (P, keep) = `{analyst, architect, developer}`; уже детерминированы (эталон) = `{deploy-finalizer, post-deploy-monitor}`.
-  - **Документы (durable, `docs/architecture/`):** `llm-call-sites.md` (карта + машинно-читаемый блок инвентаря + control-path-разметка + классификация, снимок), `llm-determinization-roadmap.md` (порядок замен; рекомендованный первый срез — **deployer staging-status**, чистый маппинг exit-кода `staging_check.py`; прод уже детерминирован Phase A/B/C ORCH-036), `llm-usage-policy.md` (нормативный принцип + критерии keep/replace через ось + определение «avoidable»). Витрина `docs/overview/tech-quality-security.md` и `docs/architecture/README.md` ссылаются на карту и политику.
-  - **Анти-дрейф тесты (offline, без сети/LLM/subprocess-к-модели):** `tests/test_llm_call_site_inventory.py` (TC-01 единственный транспорт = `_spawn`; TC-12 отсутствие иного LLM-транспорта; TC-02 детерминированные модули без консультации; TC-03 промпты↔файлы; TC-04 тотальность+согласованность класса с осью; TC-05 keep-LLM именует суждение; TC-06 capability≠consultation; TC-09 снимок рантайм-контрактов; **TC-13** control-path-разметка сверена с потребителем в `src/qg/checks.py`; **TC-14** avoidable-набор = `{tester, deployer}`) и `tests/test_llm_determinization_docs.py` (TC-07 полнота roadmap+первый срез; TC-08 политика нормативна+определяет термин; TC-11 анти-фабрикация follow-up ID). Дискриминатор всех проверок — **«консультирует LLM», а не «спавнит subprocess»**. Норматив сопровождения: менял место вызова LLM или потребителя вердикта в `src/qg/checks.py` → обнови карту/разметку и политику в том же PR.
-- **Sandbox-only fail-closed изоляция записи в Plane из тест-процесса** (ORCH-117, `fix`, bug→escalate full-cycle): закрыт корневой класс инцидента **ORCH-114** — тест/worktree-процесс выполнил РЕАЛЬНУЮ запись (`PATCH …/issues/… state=<Done>` + комментарий «Stage: deploy → done») против **боевого** Plane-проекта, т.к. тест/staging-процессы наследуют живой боевой Plane-токен (`PLANE_HEADERS`/`PROJECT_ID` захвачены литералами **на импорте** — подмена env/токена постфактум бесполезна, NFR-4), и **ничто** не принуждало их писать только в sandbox. Симметрия прецеденту `tests/conftest.py::_no_telegram` (autouse-глушилка Telegram «pytest на проде слал реальные сообщения») — для Plane-**записи** такой защиты не было. Аддитивно, never-raise в боевом пути; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имена `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты** (это изоляция клиента Plane, **не** Quality Gate и **не** стадия). Новый чистый leaf `src/plane_write_guard.py` (`decide(project_id, op, work_item) -> (ALLOW|BLOCK, reason)`, по образцу `deploy_status_guard`/`serial_gate`) врезан в **3 примитива записи** `plane_sync` (`update_issue_state`/`add_comment`/`_set_issue_state_direct`) **на момент вызова** — сразу после локального `_resolve_project_id` и **до** любого сетевого шага (ни GET, ни PATCH/POST). Гард активен **только в тест-процессе** (детект `"pytest" in sys.modules` / `PYTEST_CURRENT_TEST`); боевой и staging рантаймы (`uvicorn src.main:app`, без pytest в процессе) — строгий **no-op** (NFR-2/NFR-3). В тест-процессе запись разрешена **только** при одновременном (а) opt-in `plane_test_write_enabled=True` **и** (б) целевом проекте ∈ sandbox-allowlist `plane_test_sandbox_projects` (дефолт = единственный SANDBOX `8c5a3025-…`); иначе — default-deny; нерезолвимый проект → блок (fail-closed, NFR-1); боевой проект запрещён **даже при opt-in** (allowlist sandbox-only). Второй независимый sandbox-bound слой — autouse-floor `tests/conftest.py::_plane_sandbox_only` (opt-in OFF для всего сьюта, по образцу `_no_telegram`/`_disable_*`); sandbox-e2e ре-энейблит opt-in в своей фикстуре поверх floor. **Умышленно БЕЗ kill-switch прод-блока** (NFR-6/FR-7/anti-drift): выключателя, переоткрывающего прод-запись из pytest, нет — единственный реверс — sandbox-bound opt-in. Аудит: блок → громкий структурный ERROR (`project_id`/`work_item`/`op`/`reason` — делает инцидент класса ORCH-114 очевидным), разрешённая sandbox-запись → INFO. Новые ключи `ORCH_PLANE_TEST_WRITE_ENABLED` (дефолт `false`) / `ORCH_PLANE_TEST_SANDBOX_PROJECTS` (дефолт = SANDBOX id) с безопасными дефолтами; `scripts/staging_check.py` Block C (E2E в SANDBOX) — отдельный процесс с собственными httpx-вызовами, гардом не затронут. Покрытие — `tests/test_orch117_plane_write_isolation.py` (TC-01 — обязательный регресс ORCH-114: красный до врезки, зелёный после; TC-02…TC-14). ADR: `docs/work-items/ORCH-117/06-adr/ADR-001-sandbox-only-plane-write-guard.md`, сквозной `docs/architecture/adr/adr-0046-sandbox-only-plane-write-guard.md`.
-- **Ownership-lease для side-effectful переходов стадий + умное восстановление при старте** (ORCH-114, `fix`, bug→escalate full-cycle): закрыт **корневой класс** инцидент-цепочки ORCH-110/111/112/113 — у side-effectful переходов стадий не было единого владения. `advance_stage` ре-ентерабельна и пишет стадию «голым» `UPDATE … WHERE id=?` (без compare-and-swap), а ≥5 акторов (монитор / Plane-webhook / reconciler F-1 / job-reaper / deploy-finalizer) входят в один переход независимо → конкурентный или после-рестартовый повторный вход **дважды** применял необратимые эффекты (merge_pr / coverage-ratchet / image-rebuild / инициация прод-деплоя) и давал **противоречие rollback↔done** (инцидент ORCH-111, job 1914 / PR #130). Два комплементарных слоя, оба аддитивные, под единым kill-switch, never-raise: **(1) durable transition-lease** (новая таблица `transition_lease`) — владение на ВХОДЕ в side-effectful регион (второй актор, увидев живого владельца, не стартует тяжёлые под-гейты вовсе — предотвращение, не починка постфактум); **(2) expected-stage CAS** (`update_task_stage_cas`) — на ЗАПИСИ стадии (проигравший гонку — аборт без побочных эффектов), что закрывает и **6 путей записи стадии в обход `advance_stage`** (gitea×5 + plane rollback). Liveness владельца = `owner_pid` + `owner_boot_id` (НЕ heartbeat: блокирующий 900s merge re-test не может бить heartbeat — довод самого ORCH-113), что делает рестарт-recovery бесплатным (новый процесс → новый boot-id → все прежние lease мгновенно устаревшие → реклеймятся). Lease без собственного TTL: его потолок возраста = Tier-3 backstop `reaper_max_running_s` (5400) → сквозной бюджет ORCH-065/109/110/113 не тронут. `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / **схемы существующих таблиц** — байт-в-байт (одна аддитивная таблица, без epoch-колонки на `tasks`). Скоуп self-hosting (`transition_lease_repos=""` → только `orchestrator`; enduro не затронут); kill-switch `ORCH_TRANSITION_LEASE_ENABLED=false` → CAS вырождается в прежний безусловный `update_task_stage`, lease инертен → поведение байт-в-байт до ORCH-114. ADR: `docs/work-items/ORCH-114/06-adr/ADR-001-transition-ownership-lease-and-stage-cas.md`, сквозной `docs/architecture/adr/adr-0045-transition-ownership-lease-and-stage-cas.md`.
-  - **Leaf `src/transition_lease.py` (новый, чистый never-raise):** по образцу `serial_gate`/`coverage_gate`/`finalizer_liveness` (импортирует только `db`+`config`, лениво `merge_gate.pid_alive`/`qg.checks`/`notifications`; НЕ импортирует `stage_engine`/`launcher`) — `applies(repo)` / `acquire(task_id, owner, run_id, stage)` (атомарный rowcount-guard `INSERT … ON CONFLICT DO NOTHING` после очистки stale-строки) / `is_held_by_live_owner(task_id)` (fail-closed → defer на сомнении) / `release(task_id, force=False)` (holder-aware по boot) / `reclaim_if_stale` / `recover_on_startup` / `commit_stage_cas(task_id, expected, new, repo)` (flag-off → unconditional `update_task_stage`; flag-on → CAS) / `snapshot()`.
-  - **Интеграция:** `advance_stage` захватывает lease на входе в side-effectful ребро (`deploy-staging`/`deploy`), пишет стадию через CAS, освобождает lease в `try/finally` (на любом исходе, включая исключение/откат); **rollback-записи side-effectful под-гейтов** (`_handle_merge_gate_rollback`/`_handle_security_gate`/`_handle_coverage_gate`/`_handle_image_freshness`) пишут `development` через тот же CAS (общий хелпер `_rollback_stage_cas`, ADR-001 D4: защита rollback↔done — под держимым lease это единственный владелец, проигранный CAS → аборт без side-effects, не слепой перетир `done`); job-reaper `_finalizer_owns` обобщён с процесс-локального ORCH-113 (Tier-2/`deploy-staging`) на **durable cross-path** lease (defer при живом владельце; Tier-3 backstop игнорирует маркер → bounded reclaim; реап force-освобождает lease); reconciler F-1 и Plane-webhook (`_try_advance_stage`) делают **defer** при активном lease; `main.lifespan` зовёт `recover_on_startup()` после `requeue_running_jobs`. Наблюдаемость — read-only блок `transition_lease` в `GET /queue` + Telegram-алерт на форсированный/устаревший реклейм + опциональный `POST /transition-lease/release?work_item=<id>`. Покрытие — `tests/test_orch114_transition_ownership.py` (TC-01 обязательный регресс класса ORCH-111: красный до фикса, зелёный после; TC-02…TC-14 + регресс CAS на in-region rollback). Флаги (`config.py`, дефолт = боевое): `transition_lease_enabled` (env `ORCH_TRANSITION_LEASE_ENABLED`), `transition_lease_repos` (env `ORCH_TRANSITION_LEASE_REPOS`).
-- **Гигиена shared deploy-базы: устойчивый self-deploy `git pull` к грязному дереву** (ORCH-112, `fix`, bug→escalate full-cycle): устранён инцидент ORCH-111 — self-deploy падал на шаге `git pull origin main` хост-хука с `error: Your local changes to the following files would be overwritten by merge: src/config.py` (грязь от неуспешной/отменённой/брошенной задачи ORCH-104 в общем main checkout) → деплой вставал → ручное вмешательство (на self-hosting — групповой риск). Решение — **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`): перед `git pull` хук при обнаружении грязи приводит deploy-базу к чистому актуальному `origin/main` (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Аддитивно, под kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты** (это устойчивость deploy-пути, **не** Quality Gate и **не** стадия). ADR: `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
-  - **Leaf `src/checkout_hygiene.py` (новый, чистый never-raise):** по образцу `serial_gate`/`cancel`/`self_deploy` (импортирует только `config`, лениво `self_deploy`/`qg.checks`/`notifications`) — `applies(repo)` (kill-switch `checkout_hygiene_enabled` + скоуп `checkout_hygiene_repos`, пусто → self-hosting only, локально и ПЕРВЫМ), `hook_env(repo, work_item_id)` (env-префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`, инжектится в detached-команду хука только при `applies==True`, иначе `""` → голый pull 1:1), `read_report`/`alert_dirty` (наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
-  - **Хук-блок «2a. Resilient pull» (`scripts/orchestrator-deploy-hook.sh`):** между шагом «1. Capture PREV_IMG» и «2. Pull», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`. **Сохранность (NFR-2, жёсткий контракт):** `git clean` — **только `-fd`, НИКОГДА `-x`** (иначе удалил бы gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломался бы rollback `do_rollback`); sibling `<repos_dir>/.deploy-state-*`/`.merge-lease-*.json` (под родителем `$REPO`) и `.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`. Каждый git-шаг — `|| log "...continuing"` (never-break): сбой гигиены не ухудшает исход относительно текущего голого pull; на чистой базе блок — no-op (happy-path и exit-коды байт-в-байт). `--build-staging` (build из worktree, без pull) не затронут.
-  - **Сходимость после failed/cancelled (FR-2)** — этим же deploy-time self-heal (база сходится на следующем же self-deploy); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**. **Наблюдаемость (FR-4)** — хук пишет sentinel `hygiene` в deploy-state каталог; Phase-C finalizer (`stage_engine.run_deploy_finalizer`) читает (`read_report`) и шлёт Telegram-алерт (`alert_dirty`, кликабельный номер, best-effort, never-raise — сбой алерта не валит деплой).
-  - **Флаги** (`config.py`, дефолт = боевое): `checkout_hygiene_enabled` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`), `checkout_hygiene_repos` (env `ORCH_CHECKOUT_HYGIENE_REPOS`). Откат = `ORCH_CHECKOUT_HYGIENE_ENABLED=false` → деплой байт-в-байт до ORCH-112. Покрытие — `tests/test_deploy_checkout_hygiene.py` (TC-01…TC-10: шелл-симуляция реального хука во временном git-репо без сети/прода/ssh + unit; TC-01 — обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
-- **Job-reaper не реапит живой долго финализирующий монитор `deploy-staging`** (ORCH-113, `fix`, bug→escalate full-cycle): устранено расхождение состояния из инцидента ORCH-111 (deployer job 1914 / run_id 683). На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит `agent_runs.finished_at`/`exit_code` **первым**, затем синхронно в своём потоке прогоняет тяжёлые edge-под-гейты (`security → merge-gate re-test → coverage → image-freshness`) — **минуты** — и лишь потом `_finalize_job`. Reaper Tier-2 меряет `finished_age_s` от `finished_at` (= начала финализации), поэтому по истечении `reaper_finalize_grace_s=300` трактовал живого долго финализирующего монитора как мёртвого и **независимо** повторял тот же тяжёлый advance: повторный re-test стал красным → ложный откат `deploy-staging → development` (+ ложный developer-retry) **параллельно** с тем, что исходный finalizer довёл deploy до SUCCESS и смержил PR — состояние раздвоилось. Аддитивно, под глобальным kill-switch, never-raise; `STAGE_TRANSITIONS`/`QG_CHECKS`/каждый `check_*`/machine-verdict ключи/схема БД — **байт-в-байт не тронуты**; `reaper_finalize_grace_s`/`reaper_max_running_s` и сквозной бюджет ORCH-065/109/110 (`5400 > Σ(gate-work)+grace`) сохранены; фикс не рестартит прод и не пушит `main`. ADR: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`, сквозной `docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`.
-  - **Leaf `src/finalizer_liveness.py` (новый, процесс-локальный реестр владения):** чистый never-raise модуль (паттерн `serial_gate`/`coverage_gate`, без сети/БД) — `mark(job_id, run_id, stage)` / `clear(job_id)` / `is_active(job_id)` / `snapshot()`; состояние `{job_id: {...}}` под `threading.Lock`. Авторитетно in-memory, т.к. монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без `--workers`) с общей SQLite-БД. Собственного TTL нет — ограничение по времени даёт Tier-3 backstop. `is_active` при ошибке → `False` (консервативно: не блокировать добивание).
-  - **Эмиссия владения (`launcher._monitor_agent`):** `mark()` вызывается **сразу после** штампа `exit_code` (самый ранний момент Tier-2), хвост финализации вынесен в `_run_monitor_finalization` и обёрнут в `try/finally` с `clear()` в `finally` → исключение в потоке монитора гарантированно снимает владение, и реально мёртвый finalizer добивается. Маркер пишется **безусловно** (kill-switch гейтит только консультацию reaper, поэтому выключенный путь — байт-в-байт прежний). Хвост перенесён **дословно** (проверяется `git diff -w`: +49/−0, нулевое изменение логики).
-  - **Консультация reaper (`job_reaper._reap_job` Tier-2):** при `reaper_finalizer_liveness_enabled` **И** стадии задачи `== "deploy-staging"` **И** активном владении → **defer** (счётчик + лог, не повторять advance), провал к Tier-3. **Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — застрявший/мёртвый finalizer добивается в ограниченное время. Скоуп — только глобальный kill-switch `reaper_finalizer_liveness_enabled` (env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`; `False` → reaper байт-в-байт прежний), **без** per-repo разреза (баг общий для всех репо со стадией `deploy-staging`).
-  - **Наблюдаемость:** аддитивные ключи `finalizer_liveness_enabled`/`finalizer_defers_total`/`finalizer_owned` в блоке `reaper` ответа `GET /queue` (существующие ключи не тронуты). Покрытие — `tests/test_orch113_reaper_finalizer_liveness.py` (TC-01…TC-08, включая обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
-- **Merge-gate re-test: толерантность к инфра-таймауту + tree-kill спавненных pytest + контракт необходимости re-test** (ORCH-110, `fix`, bug→escalate full-cycle): устранён ложный откат `deploy-staging → development`, возникавший когда локальный re-test merge-gate падал по **таймауту** (инфра/ресурс) при зелёных CI + tester + staging (инцидент ORCH-109/PR #129: сюит 516.7s упёрся в бюджет 600s под CPU-голоданием от осиротевших pytest-процессов → `(False, "re-test timeout after 600s")` → `_handle_merge_gate_rollback` → каждый из 3 developer-retry падал так же → «Merge-gate still failing after 3 developer retries» → ручное вмешательство). Аддитивно, под 5 независимыми kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты**; INV-4 (никогда push/force-push `main`) и запрет рестарта прод-контейнера — соблюдены. ADR: `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`, сквозной `docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`.
-  - **D1 — process-group tree-kill (`src/proc_group.py`, новый stdlib-only leaf):** `merge_gate.retest_branch` и `coverage_gate.measure_coverage` теперь спавнят pytest в **отдельной группе процессов** (`start_new_session`) и при таймауте убивают **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL по образцу `launcher.stop_process`), а не только прямого потомка — осиротевшие внуки-pytest больше не переживают бюджет и не грузят CPU. Контракты возврата сохранены (меняется лишь побочный эффект — нет утечки). Грейс реюзит `agent_kill_grace_seconds`. Fallback never-break: `subprocess_tree_kill_enabled=False` или не-POSIX → прежний `subprocess.run(timeout=)`.
-  - **D2/D3 — классификация + маршрутизация инфра-таймаута:** чистый предикат `merge_gate.classify_retest_failure(reason)` различает `timeout`/`red`/`lock-busy`/`other` (scope-guard: `auto_rebase_onto_main`'s «rebase timeout» — НЕ инфра-таймаут re-test, остаётся на rollback-пути). Инфра-таймаут → новый `_handle_merge_gate_infra_retry` (ограниченный повтор по образцу `_handle_merge_gate_defer`: задача **остаётся на deploy-staging**, staging-deployer перезапускается с задержкой, **БЕЗ** отката на `development` и **БЕЗ** расхода developer-retry). Анти-над-толерантность (BR-6): детерминированно **красный** re-test / конфликт по-прежнему → `_handle_merge_gate_rollback`. Anti-loop: исчерпание бюджета → один **инфра-alert** (явно инфраструктурная формулировка «НЕ дефект кода» с кликабельным номером), задача НЕ уходит в `development`.
-  - **D4 — контракт необходимости re-test:** при `premerge_rebase_always=True` re-test теперь **пропускается**, когда rebase оказался доказанным no-op (HEAD не сдвинулся = ветка уже содержит свежий `origin/main`, тот же коммит уже подтвердили CI + tester + staging) — distribute той же оптимизации, что путь `premerge_rebase_always=False` уже имеет для не-behind ветки. Fail-safe: при любой неопределённости (`head_sha` пуст / git-ошибка) re-test **выполняется** (BR-6/AC-3 не ослаблен).
-  - **D5 — бюджет:** `merge_retest_timeout_s` 600 → **900** (запас 74% над 516.7s) + валидация `_resolve_retest_timeout` (малформ/непозитив → дефолт 900 + WARNING). Сквозной инвариант ORCH-065/109 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work)+grace (≈4460)` соблюдён **без** правки `reaper_max_running_s`.
-  - **D6 — наблюдаемость:** in-process счётчики (`retest_timeout_total`/`retest_infra_retry_total`/`retest_infra_exhausted_total`/`retest_skipped_current_total`/`last_infra_timeout_wi`) + read-only блок `merge_gate` в `GET /queue` (отличим от код-фейл-отката); координация с ORCH-111 (`proc_blocking`) без дубля (ORCH-110 предотвращает/толерирует, ORCH-111 наблюдает). Append-only regression-guard: добавлен `("ORCH-110", "classify_retest_failure", "src/merge_gate.py")` в `MAIN_REGRESSION_MARKERS`.
-  - **Конфиг (5 новых ключей, дефолт = боевое):** `ORCH_SUBPROCESS_TREE_KILL_ENABLED`/`ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED`/`ORCH_MERGE_RETEST_INFRA_MAX_RETRIES=2`/`ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S=120`/`ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED` + бамп `ORCH_MERGE_RETEST_TIMEOUT_S=900`. Покрытие — `tests/test_orch110_*.py` (TC-01…TC-12, включая регресс инцидента red-before/green-after).
-- **Watchdog-сигнал `proc_blocking`: алерт на долго живущий осиротевший тест-процесс** (ORCH-111, `feat`): закрыта слепая зона наблюдаемости между `agent_hung` (видит только треканые джобы по `jobs.pid`) и осиротевшими субпроцессами `pytest`, которые орк запускает сам (`merge_gate.retest_branch`/`coverage_gate.measure_coverage`) и которые при timeout-kill агента (`-9`, ORCH-109) репарентируются на tini и живут сутками, грузя CPU и валя merge-gate re-test (инцидент: процессы `test_install_lite_script.py` жили >2 суток без единого алерта). Изменения **строго внутри наблюдателя** (`watchdog/**` + сервис watchdog в compose); `src/**`/`/metrics`/`schema_version`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — **байт-в-байт не тронуты**; выкат пересобирает **только** `orchestrator-watchdog`, прод `orchestrator` не рестартится (NFR-3). ADR: `docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md`, сквозной `docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md`.
-  - **Коллектор `watchdog/collectors/proc.py` (D3):** новый stdlib-only `/proc`-скан (под `pid: host` контейнерный `/proc` отражает хост-namespace) — читает `/proc/stat` (`btime`) + `os.sysconf("SC_CLK_TCK")`, итерирует числовые `/proc/<pid>`, матчит `/proc/<pid>/cmdline` по паттерну тест-класса, парсит `/proc/<pid>/stat` (поле 22 `starttime` → `age_s`, поля 14+15 `utime+stime` → `cpu_s` информационно). Строго **read-only** (никаких `os.kill`/сигналов/`subprocess`; **никогда** не читает `/proc/<pid>/environ` — секреты); **never-raise** (per-pid гонка «процесс умер между listdir и read» пропускается, top-level → `[]`); чистый разбор отделён от I/O (тестируется на фейковом `/proc`-дереве).
-  - **Чистый builder `proc_signals` + синтез RECOVERY (D4):** per-entity `Signal("proc_blocking", pid)` active ⇔ `age_s > cfg.proc_age_s` (cmdline уже отфильтрована коллектором); действенный RU-`detail` (PID + возраст + усечённый фрагмент cmdline + CPU-время). Исчезновение процесса не оставляет «висящего» алерта: в `core.tick()` для каждого alerting-ключа без свежего сигнала **синтезируется** `Signal(active=False)` → существующая `decision.decide()`/`AlertState` даёт **однократный** RECOVERY и чистит состояние (никакой новой анти-спам-логики — FR-5).
-  - **Анти-false-positive и отсутствие дубля с `agent_hung` — по построению (D2):** cmdline-скоуп (`claude`-агент ≠ `pytest` → нулевое пересечение, NFR-4/AC-5) + дефолтный порог возраста (60 мин) **превышает** макс. легитимный бюджет тест-прогона `max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)` → in-flight прогон физически не перерастает порог (BR-4/AC-4). Без хрупкого кросс-namespace матчинга PID.
-  - **Конфиг + kill-switch (D5):** ключи `WATCHDOG_PROC_ENABLED` (дефолт **false** — opt-in) / `WATCHDOG_PROC_AGE_MIN` (60) / `WATCHDOG_PROC_PATTERNS` (`pytest`) / `WATCHDOG_PROC_COOLDOWN_S` (1800), never-raise парсеры. При выключенном флаге коллектор в `tick()` **не вызывается** → нулевой оверхед и байт-в-байт прежний тик (AC-7). Топология (D6): аддитивный `pid: host` **только** на сервисе `orchestrator-watchdog` (привилегия read-only, меньше уже-смонтированного `docker.sock`; не volume → инвариант read-only-маунтов цел).
-  - **Канон тиража (NFR-5):** новые `WATCHDOG_PROC_*` синхронизированы в `.env.watchdog.example` ↔ блок `WATCHDOG_*` `.env.example` (key-sync тест зелёный), описаны в `docs/deployment/LITE_SETUP.md` §4 и `docs/architecture/README.md` (§ proc_blocking). Покрытие — `tests/watchdog/test_proc_blocking_signal.py` (TC-01…TC-06), `test_proc_collector.py` (парсинг `/proc`), `test_tick_proc_blocking_integration.py` (TC-07 tick→dispatch + flag-off), позитивный `pid: host` в `test_compose_service.py`, proc-конфиг в `test_config_killswitch.py`. Полный `pytest tests/` зелёный (1930).
-- **Timeout-бюджеты developer/reviewer + launch-стамп модели в телеметрии** (ORCH-109, `fix`): две аддитивные изолированные правки подсистемы запуска агентов (инцидент ORCH-104, runs 658/659/660), **без** касания `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы БД. ADR: `docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md`, сквозной `docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`.
-  - **Launch-стамп модели (D1, FR-1):** резолвенная `resolve_agent_model(...)` пишется в `agent_runs.model` в **момент launch** объединённым `UPDATE agent_runs SET model=?, effort=? WHERE id=?` рядом со стампом эффорта (ORCH-087) в `launcher._spawn`. Раньше модель писалась только постфактум из финального usage-JSON (`record_usage`, `model=COALESCE(?, model)`), а убитый по тайм-ауту прогон этот JSON не эмитит → модель оставалась `NULL` ровно тогда, когда нужна для разбора инцидента. Теперь модель присутствует с launch, **переживает timeout-kill (`exit_code=-9`)**, видна in-flight в `GET /metrics`/`GET /queue` (`get_running_agents` уже отдаёт `model`) и в строке Telegram-карточки. Пустой резолв (CLI-дефолт без `--model`) → `NULL` (симметрично `effort or None`). Постфактум `record_usage` остаётся **обогащением** (COALESCE сохраняет launch-стамп при `model=None`). never-raise: сбой стампа изолирован `try/except` + WARNING, launch продолжается.
-  - **Поднятые per-role wall-clock бюджеты (D3/D4, FR-3):** выделенные типизированные ключи `agent_timeout_developer_s=3600` (60м) / `agent_timeout_reviewer_s=3000` (50м) (env `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S`). `_resolve_timeout(agent)` получил детерминированную лестницу: `agent_timeout_overrides_json[agent]` (операторский escape-hatch, высший приоритет, BC) → выделенный ключ роли → `agent_timeout_seconds=1800` (прочие роли — байт-в-байт). Малформный JSON / непозитивный/нечисловой выделенный ключ → откат на глобальный дефолт + WARNING (never-break). Дефолты = боевым значениям (канон ORCH-101): пустой `.env` воспроизводит поднятые бюджеты. **Кросс-инвариант reaper ORCH-065** сохранён синхронным поднятием `reaper_max_running_s` 3600 → **5400** (`5400 > max(timeout)3600 + grace20 = 3620`).
-  - **FR-4/NFR-6 (видимость при kill / in-flight) и FR-5 (анти-salvage) — структурно уже выполнены** существующим кодом (продвижение гейтится `if exit_code == 0`, timeout-kill → `_finalize_job` retry/fail, не advance); ORCH-109 фиксирует их **регресс-тестами**, новых ветвей не вводит. Покрытие — новый `tests/test_orch109_timeout_model.py` (TC-01…TC-12, детерминированный, без сети/CLI). Обновлены `tests/test_config.py` (reaper-дефолт 5400) и `tests/test_launcher.py` (ладдер `_resolve_timeout`). Документация — `.env.example` (блок agent-timeout + reaper), `config.py`-паспорт, `docs/architecture/README.md`/`internals.md` + front-page `README.md` (раздел «Watchdog») (per-role бюджеты).
 - **Презентация: слайды Lite-установки и использования через Plane** (ORCH-105, `docs`): слайдо-источник `docs/overview/presentation.md` расширен тремя слайдами в каноне ORCH-011 (16 → 19, сквозная нумерация сохранена): один слайд про **Lite-установку скриптами** (два контейнера платформы — оркестратор + сторож на инфре заказчика; развёртывание без правки кода, только конфиг; помощники `gen_secrets.py`/`onboard_project.py` + `docker compose up -d`; runbook `LITE_SETUP.md` с проверкой каждого шага; одношаговый bootstrap — это смежный Bundled, не Lite) и два слайда оператор-инструкции **«как пользоваться орком через Plane»** (запуск через статус «To Analyse»; статусы Plane — индикация, не управление; оба человеческих гейта «Approved»/«Confirm Deploy»; авто-лейблы `autoApprove`/`autoDeploy`/`Bug` — снимают только человеческие решения, ни одна техническая проверка не пропускается; отмена через «STOP»; наблюдение — статусы доски + живая Telegram-карточка + комментарии со ссылками на ветку/PR). Факты сверены с golden sources (`docs/deployment/LITE_SETUP.md`, `docs/overview/tech-pipeline.md`, `tech-integrations.md`, `CLAUDE.md`). **Docs+tests only:** `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД — байт-в-байт; новый QG не вводится; `python-pptx` не добавлен в прод-образ; собранный `.pptx` в git не коммитится. Анти-дрейф — новая функция `test_presentation_covers_lite_and_plane_usage_bits` в `tests/test_system_docs.py` (существующие проверки без послаблений). ADR: `docs/work-items/ORCH-105/06-adr/ADR-001-presentation-lite-and-plane-usage-slides.md` (канон витрины не меняется — `adr-0039-system-overview-docs-canon.md`).
 - **Витрина системы `docs/overview/`: бизнес + тех, маршруты трёх аудиторий, презентация** (ORCH-011, `docs`): единая точка входа в документацию платформы — новый docs-раздел `docs/overview/` (плоский каталог, 10 файлов, ADR-001 D1): индекс `README.md` (маршруты «Я заказчик / Я менеджер / Я разработчик» + норматив сопровождения «изменил функциональность → обнови витрину в том же PR»), бизнес-часть `business.md` (проблема → решение → что умеет фактически → ценность → 6 сценариев; без жаргона, цифры только с атрибуцией), 7 тех-блоков `tech-*.md` (архитектура со схемой потока, конвейер/гейты, агенты, модель объектов, интеграции, качество/безопасность, наблюдаемость; link-first — за деталями ссылки в golden sources, разрешённый дубль только машинно-сверяемый). **Docs+tests+dev-скрипт** (паттерн ORCH-102/103): `src/**`/`docker-compose.yml`/`Dockerfile`/`requirements*`/`STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схема БД — ноль изменений. ADR: `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`, сквозной `adr-0039-system-overview-docs-canon.md`.
   - **Презентация (D4/D5):** слайдо-источник `docs/overview/presentation.md` (16 слайдов в машинно-парсимой структуре «## Слайд N: …» + процедура сборки «команда + Проверка:») + dev-скрипт `scripts/build_presentation.py` (python-pptx, тёмный дизайн, редактируемый текст с точной кириллицей; чистый stdlib-парсер `parse_slides` + ленивый импорт pptx). Запуск только вне рантайма; `python-pptx` НЕ в прод-образе (машинный гард); собранный `.pptx` в git не коммитится — `build/` в `.gitignore`.

README.md

@@ -149,12 +149,6 @@ uvicorn src.main:app --reload --port 8500
 | `ORCH_BUG_FAST_TRACK_ENABLED` | Kill-switch багфикс-трека (ORCH-019): задача с меткой Plane `Bug` пропускает стадию `architecture`; `false` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия) | `true` |
 | `ORCH_BUG_FAST_TRACK_LABEL` | Имя метки Plane, активирующей багфикс-трек (ORCH-019) | `Bug` |
 | `ORCH_BUG_FAST_TRACK_REPOS` | CSV область репо для багфикс-трека; **пусто → self-hosting only** (`orchestrator`) — enduro подключается явным CSV (ORCH-019) | `""` |
-| `ORCH_ESTIMATOR_ENABLED` | Kill-switch оценки задачи (ORCH-020): Plane-статус «Оценка» прогнозирует стоимость/время/токены/story-points по истории; `false` → статус не обрабатывается, ничего не пишется (нулевая регрессия) | `true` |
-| `ORCH_ESTIMATOR_REPOS` | CSV область репо для оценки; **пусто → self-hosting only** (`orchestrator`) — enduro не затронут (ORCH-020) | `""` |
-| `ORCH_ESTIMATOR_MIN_SAMPLES` | Порог истории, ниже которого подмешивается bootstrap-дефолт прогноза (ORCH-020) | `3` |
-| `ORCH_ESTIMATOR_BOOTSTRAP_TOKENS` / `_COST_USD` / `_SECONDS` | Bootstrap-прогноз при пустой истории (токены/стоимость/время; ORCH-020) | `2000000`/`3.0`/`1800` |
-| `ORCH_ESTIMATOR_SP_COST_THRESHOLDS` | 4 возрастающих кат-оффа стоимости (t1,t2,t3,t5) для бакета story-points (`<=t1→1`…`<=t5→5`, иначе `8`; ORCH-020) | `0.50,2.00,5.00,12.00` |
-| `ORCH_ESTIMATOR_WALL_CAP_S` / `_MAX_INFLIGHT` | Отсечка аномального wall-времени в истории / опц. семафор сглаживания массовой нагрузки (ORCH-020) | `86400`/`64` |
 | `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME акторских процессов + таргет маунтов `.claude`/`.ssh` + `ARG APP_HOME` (группа ORCH-040) | `/home/slin` |
 | `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot@mva154.local` при дефолтах) | `claude-bot` / `mva154.local` |
 | `ORCH_STAGING_PORT` | ORCH-101: порт staging (читают `image_freshness` и compose); guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) | `8501` |
@@ -298,7 +292,7 @@ Task-файлы `.task-*.md` пишутся **прямой записью в с
 stdout/stderr агента перенаправляются СРАЗУ в `/app/data/runs/{id}.log` на уровне ОС (без PIPE). monitor-поток делает `proc.wait()` → реальный exit_code, нет зомби.
 
 ### Watchdog
-Каждый агент имеет per-role wall-clock бюджет (ORCH-109): developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт (`_resolve_timeout`). При превышении — SIGTERM→grace→SIGKILL + запись exit_code=-9. Tier-3 backstop `reaper_max_running_s`=90 мин > max(timeout)+grace (ORCH-065).
+Каждый агент имеет timeout 30 минут. При превышении — SIGKILL + запись exit_code=-9.
 
 ### Event routing
 Gitea events роутятся по типу:

docker-compose.yml

@@ -79,12 +79,6 @@ services:
     restart: unless-stopped
     init: true
     network_mode: host
-    # ORCH-111 (adr-0041 D6): share the host PID-namespace so the sidecar's /proc
-    # reflects the host and the proc_blocking collector can see orphaned pytest
-    # subprocesses. Privilege is read-only and ONLY on the observer; the signal
-    # is default-off (WATCHDOG_PROC_ENABLED=false) -> no behaviour change unless
-    # opted in. NOT a volume, so the host-paths-read-only compose test is unaffected.
-    pid: host
     mem_limit: 128m
     mem_reservation: 32m
     volumes:

docs/_standards/PIPELINE_DOCS.md

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

docs/_templates/01-questions.md

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

docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md

@@ -1,85 +0,0 @@
----
-work_item: ORCH-109
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# adr-0040: Per-role wall-clock бюджеты (developer/reviewer) + launch-time стамп модели
-
-- **Статус:** proposed
-- **Дата:** 2026-06-14
-- **Задача:** ORCH-109
-- **Детальный ADR:** `docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md`
-
-## Контекст
-Инцидент **ORCH-104** вскрыл два глобальных дефекта подсистемы запуска агентов (`src/agents/launcher.py`),
-затрагивающих **все** репо общего self-hosting-инстанса (orchestrator + enduro-trails):
-(A) единый wall-clock тайм-аут `agent_timeout_seconds=1800` убивает здоровые тяжёлые роли
-(`developer` xhigh, `reviewer`), т.к. в проде `agent_timeout_overrides_json` пуст; (B)
-`agent_runs.model` пишется только постфактум из usage-JSON (`record_usage`, `COALESCE`), а
-timeout-killed прогон финальный JSON не эмитит → модель остаётся `NULL` именно в момент инцидента,
-хотя эффорт уже стампится на launch (ORCH-087). Решение меняет два **глобальных per-agent
-инварианта** (бюджеты тайм-аутов + потолок Tier-3 reaper'а ORCH-065), поэтому регистрируется сквозным
-ADR, а не только work-item ADR.
-
-## Решение
-Две аддитивные правки launcher'а, **без** касания `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
-machine-verdict-ключей/схемы БД (колонка `agent_runs.model TEXT` уже существует — миграции нет):
-
-- **Launch-time стамп модели.** В `_spawn` резолвенная `resolve_agent_model(...)` пишется в
-  `agent_runs.model` рядом со стампом эффорта (объединённый `UPDATE … SET model=?, effort=?`),
-  пустой резолв → `NULL`. Постфактум `record_usage` (`model=COALESCE(?, model)`) остаётся
-  **обогащением**, перестаёт быть единственным источником истины — launch-стамп переживает kill и
-  виден in-flight (`db.get_running_agents` уже отдаёт `model`). never-raise: сбой стампа изолирован,
-  launch не падает.
-- **Per-role бюджеты через выделенные типизированные config-ключи** (по образцу
-  `agent_model_<role>`/`agent_effort_<role>`): `agent_timeout_developer_s=3600`,
-  `agent_timeout_reviewer_s=3000`. Лестница `_resolve_timeout`: `agent_timeout_overrides_json[agent]`
-  (escape-hatch, высший) → выделенный ключ роли → `agent_timeout_seconds=1800` (прочие роли —
-  байт-в-байт). never-break: малформный JSON / вне-диапазонный ключ → откат на глобальный дефолт +
-  WARNING.
-- **Синхронное поднятие reaper (инвариант ORCH-065).** `reaper_max_running_s`: **3600 → 5400**.
-  Проверка `reaper_max_running_s > max(timeout) + agent_kill_grace_seconds`: `5400 > 3600 + 20 = 3620`
-  ✓ (запас 1780s, покрывает окно финализации монитора). `5400 < ` sidecar `stage_stuck_s`=7200 →
-  легитимный длинный developer-прогон не порождает ложный `stage_stuck`-алерт.
-- **Канон дефолтов (ORCH-101).** Дефолт каждого ключа = боевому значению → пустой `.env`
-  воспроизводит прод-поведение (в т.ч. поднятые бюджеты). «Байт-в-байт прежнее» (NFR-1) строго
-  применяется к ролям вне `{developer, reviewer}`.
-- **FR-5 анти-salvage — структурно, без нового кода.** Продвижение стадии гейтится
-  `if exit_code == 0: _try_advance_stage(...)`; timeout-kill (-9) → `_finalize_job` → retry/fail,
-  никогда не advance. Добавляется регресс-тест, не новая ветвь.
-
-## Альтернативы
-- **Дефолт `agent_timeout_overrides_json={"developer":…}`** — отвергнуто: ломает канон ORCH-101
-  непустым JSON-дефолтом, хрупкая строка против типизированного int, нельзя override одной env-роли.
-- **Бюджеты ≤ 3580 без поднятия reaper** — рассмотрено (меньший blast-radius), отвергнуто как
-  доминирующее: урезает самую тяжёлую роль ради статичности backstop-числа; NFR-4 явно делегирует
-  reaper-поднятие архитектору. Остаётся операторским запасным путём (всё env-override'имо).
-- **Repo-scoped бюджеты (`*_repos`)** — отвергнуто: тайм-аут — свойство launch, не гейт-решение;
-  глобальность благоприятна enduro.
-- **Новый guard-leaf анти-salvage** — отвергнуто: продвижение уже гейтится exit-кодом; новый код =
-  лишняя ветвь риска.
-
-## Последствия
-- Модель видна (не `null`) при любом исходе прогона (трекер / status-комментарии / `/metrics` /
-  `/queue`) — ключевой контекст инцидента доступен в момент сбоя; тяжёлые роли получают реальный
-  бюджет (developer ×2, reviewer +67%) → меньше ложных timeout-kill при автономном прогоне (ORCH-088).
-- Аддитивно/обратимо/never-raise; гейты/схема/machine-verdict/деплой-путь не тронуты; прод-контейнер
-  не рестартится (self-hosting безопасность, NFR-5).
-- Плата: Tier-3 backstop 60→90м (реально зависший прогон держится дольше — митигейшн Tier-1/Tier-2 +
-  watchdog ≤ бюджета); глобальность поднимает enduro-роли (благоприятно; reaper-страховка цела);
-  sidecar `agent_hung` (alert-only) может чаще срабатывать на здоровых длинных прогонах с low-CPU
-  фазами (не влияет на конвейер).
-- **Откат:** занизить `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S` (= 1800) и вернуть
-  `ORCH_REAPER_MAX_RUNNING_S=3600`; launch-стамп модели отката не требует. Kill-switch не вводится
-  (нет рисковых ветвей: стамп безопасен, тайм-аут fail-safe на дефолт).
-
-## Связи
-adr-0011 (job-reaper — Tier-3 backstop `reaper_max_running_s`, инвариант ORCH-065 правится здесь
-синхронно), adr-0030 (metrics-endpoint — `get_running_agents().model` начинает заполняться для
-running-job), adr-0033 (sidecar-watchdog — `agent_hung`/`stage_stuck` пороги, alert-only),
-adr-0036 (replication foundation — канон «дефолт = боевое значение»). Маркер-инварианты: ORCH-065,
-ORCH-087, ORCH-101.

docs/architecture/adr/adr-0041-watchdog-orphan-test-process-alert.md

@@ -1,95 +0,0 @@
----
-work_item: ORCH-111
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# adr-0041: Watchdog-сигнал `proc_blocking` — алерт на долго живущий осиротевший тест-процесс
-
-- **Статус:** proposed
-- **Дата:** 2026-06-15
-- **Задача:** ORCH-111 (bug → escalate full-cycle)
-- **Детальный ADR:** `docs/work-items/ORCH-111/06-adr/ADR-001-watchdog-orphan-test-process-alert.md`
-- **Парные ADR:** `adr-0033` (sidecar-watchdog F1b), `adr-0030` (`/metrics` — не трогаем),
-  `adr-0024` (disk-watchdog — образец), `adr-0040` (timeout-kill `-9` — источник осиротения)
-
-## Контекст
-Sidecar-watchdog (ORCH-100, adr-0033) алертит `agent_hung`/`stage_stuck`/`container_down`/`orch_down`/
-`host_mem`/`queue_depth`/`job_failed`/`dep_down`. `agent_hung` покрывает **только** running-агент-джобы
-(по `jobs.pid` из `/metrics agents[]`). Но виновные процессы инцидента ORCH-109 — это субпроцессы
-pytest, которые орк запускает своим кодом (`merge_gate.retest_branch`, `coverage_gate.measure_coverage`);
-при timeout-kill агента (`-9`, adr-0040) или `TimeoutExpired` внук-pytest репарентируется на PID 1
-orchestrator-контейнера (tini жнёт зомби, но **не убивает живых осиротевших**) и живёт сутками, грузя
-CPU и валя merge-gate re-test. Контейнер `orchestrator-watchdog` сейчас **не видит таблицу процессов
-хоста** (`network_mode: host`, но **без** `pid: host` и mount `/proc`). Между `agent_hung` (треканые
-джобы) и осиротевшим процессом — слепая зона: блокирующий pytest **не порождает сигнала**.
-
-## Решение
-Новый per-entity сигнал **`proc_blocking`** **внутри наблюдателя** (`watchdog/**`): на каждом тике
-sidecar **сам** сканирует `/proc` хоста (stdlib), отбирает процессы тест-класса (cmdline матчит
-паттерн, дефолт `pytest`) и при возрасте > порога (заведомо > макс. легитимного бюджета тест-прогона)
-поднимает алерт через **существующую** `decision.decide()`/`AlertState` в собственный Telegram-канал
-sidecar. Watchdog процесс **не трогает** (только наблюдение, C-1). Изменения строго в наблюдателе;
-`src/**` / `/metrics`+`schema_version` / `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
-machine-verdict / схема БД — **не тронуты**.
-
-- **Механизм — watchdog-side `pid: host`, НЕ orch-side `/metrics`.** Решающее: orch-side путь правит
-  `src/metrics.py` → рестарт прод-`orchestrator` (запрет NFR-3); и слеп именно когда орк деградировал
-  (CPU-голодание), что противоречит C-1 (наблюдатель переживает падение наблюдаемого). Watchdog-side
-  читает `/proc` независимо от живости орка и не трогает контракт `/metrics`.
-- **Коллектор** `watchdog/collectors/proc.py` (новый, по образцу `collectors/host.py`): stdlib-only
-  (`/proc/stat` btime + `SC_CLK_TCK`; `/proc/<pid>/{cmdline,stat}`; возраст из starttime, CPU-время
-  из utime+stime — информационно); **read-only** (никогда `os.kill`/`Popen`/`/proc/<pid>/environ`);
-  **never-raise** (per-pid skip; top → `[]`).
-- **Builder** `proc_signals` (чистый, в `signals.py`): ключ `("proc_blocking", pid)`; `active` ⇔
-  `age_s > proc_age_s`; detail = усечённый cmdline-фрагмент + PID + возраст + CPU-время (BR-2).
-- **RECOVERY для исчезнувшего процесса (AC-6):** в `core.tick()` синтезируется `Signal(active=False)`
-  для `proc_blocking`-ключей, которые `alerting=True`, но исчезли из наблюдаемых → `decide()` даёт
-  один RECOVERY (переиспользование машины, без отдельной анти-спам-логики, FR-5).
-- **Анти-false-positive и отсутствие дубля с `agent_hung` — по построению:** (1) cmdline-скоуп —
-  `claude`-агенты не матчат `pytest` ⇒ нулевое пересечение с `agent_hung` (NFR-4); (2) порог возраста
-  > макс. бюджета (`max(merge_retest_timeout_s=600, coverage_run_timeout_s=900)=900s`) ⇒ легитимный
-  in-budget прогон всегда ниже порога (BR-4). Кросс-namespace матчинг PID не нужен (ненадёжен).
-- **Конфиг (новые `WATCHDOG_PROC_*`):** `WATCHDOG_PROC_ENABLED` (дефолт **false** — opt-in/kill-switch,
-  зеркало `WATCHDOG_DISK_CRIT_ENABLED`), `WATCHDOG_PROC_AGE_MIN` (дефолт `60` мин; **инвариант:** >
-  макс. бюджета), `WATCHDOG_PROC_PATTERNS` (CSV, дефолт `pytest`), `WATCHDOG_PROC_COOLDOWN_S`
-  (дефолт `1800`). Дефолт-off ⇒ коллектор не вызывается ⇒ нулевая регрессия (AC-7).
-- **Топология:** `pid: host` **только** на сервисе `orchestrator-watchdog` (НЕ volume → существующий
-  `:ro`-тест compose зелёный; `/proc` отражает хост автоматически, отдельный mount не нужен).
-  Привилегия — только у наблюдателя.
-
-## Альтернативы
-- **Orch-side `/metrics`-обогащение** — отвергнуто: рестарт прод-орка (NFR-3) + слепота при
-  деградации орка (C-1) + новая поверхность контракта.
-- **Bind-mount `/proc:ro` вместо `pid: host`** — эквивалентная видимость/привилегия; `pid: host`
-  идиоматичнее (согласован с уже-`network_mode: host`). Валидная замена при предпочтении не делить
-  PID-namespace.
-- **Расширить `agent_hung` на нетреканые процессы** — отвергнуто: дубль/смешение классов (NFR-4).
-- **Реакция (kill/reap)** — вне объёма (BR-3, жёсткое ограничение): только мониторинг.
-- **Дефолт-on** — отвергнуто: привилегия + риск false-positive требуют осознанного opt-in.
-
-## Последствия
-- Закрыта слепая зона: ранний адресный алерт о CPU-голодании до того, как оно завалит merge-gate
-  re-test очередной задачи; работает даже при лёгшем орке.
-- Строго read-only + never-raise + дефолт-off + только наблюдатель ⇒ self-hosting-безопасно (enduro не
-  затронут); конвейер byte-for-byte; deploy без рестарта прод-`orchestrator` (только sidecar).
-- Анти-FP и no-dup — структурно (cmdline-скоуп + порог возраста), не хрупким PID-матчингом.
-- Плата: расширение привилегии наблюдателя (`pid: host`, read-only, **меньше** уже-смонтированного
-  `docker.sock`; код читает только `/stat`+`/cmdline`, никогда `/environ`; cmdline в алерте усечена);
-  Linux-специфичность `/proc` (не-Linux → `[]`); новые `WATCHDOG_PROC_*` ключи в каноне тиража.
-- **Топология** меняется (`pid: host`) → `07-infra-requirements.md`; **схема БД** не меняется → 08 =
-  N/A. Новый компонентный сигнал + привилегия → `arch:major-change`; прод-выкат через staging-гейт
-  sidecar, без рестарта прод-контейнера.
-- **Откат:** `WATCHDOG_PROC_ENABLED=false` (мгновенный) или удаление коллектора/builder/врезок/ключей
-  + `pid: host` — без следов в БД/схеме/контракте `/metrics`.
-
-## Связи
-adr-0033 (sidecar-watchdog F1b — рантайм/машина решения/независимый канал/never-raise — прямой
-родитель), adr-0030 (контракт `/metrics`/`schema_version` — изолирован, не тронут), adr-0024
-(disk-watchdog — образец pure-`decide_action`/dedup/recovery + «только читает и уведомляет»), adr-0040
-(timeout-бюджеты + `-9` timeout-kill — механизм осиротения внука-pytest), adr-0037/0038
-(Lite/Bundled тираж — канон `WATCHDOG_*` + compose sidecar, NFR-5).
-</content>

docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md

@@ -1,84 +0,0 @@
----
-work_item: ORCH-110
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# adr-0042: Merge-gate re-test — толерантность к инфра-таймауту + tree-kill спавненных процессов + контракт re-test
-
-- **Статус:** proposed
-- **Дата:** 2026-06-15
-- **Задача:** ORCH-110 (bug → escalate full-cycle)
-- **Детальный ADR:** `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`
-- **Парные/смежные ADR:** `adr-0006` (merge-gate ORCH-043), `adr-0040` (timeout-бюджеты ORCH-109),
-  `adr-0029` (coverage-gate ORCH-027), `adr-0011` (reaper/lease ORCH-065),
-  `adr-0041` (ORCH-111 `proc_blocking` — комплементарный наблюдатель)
-
-## Контекст
-
-Merge-gate (ORCH-043) на ребре `deploy-staging → deploy` локально пере-прогоняет тест-сюит
-(`retest_branch`) для защиты от семантического конфликта слияния. Инцидент ORCH-109/PR#129: при
-зелёном tester `PASS` (1899 passed / 516.7s), зелёном CI и актуальной ветке re-test упал по
-**таймауту** (600s) из-за CPU-голодания от **осиротевших** pytest-процессов, переживших > 2 суток.
-Таймаут классифицировался как код-фейл → откат `deploy-staging → development` + 3 сожжённых
-developer-retry → manual-gate. Корни: (1) `subprocess.run(timeout=)` убивает только прямого потомка —
-внуки pytest репарентируются на PID 1 и живут (в `merge_gate.retest_branch` и
-`coverage_gate.measure_coverage`); (2) нет толерантности к инфра-таймауту; (3) тонкий бюджет (≈16%);
-(4) избыточный re-test на уже актуальной ветке (`premerge_rebase_always=True` форсит rebase+retest
-даже на no-op rebase).
-
-Решение кросс-каттинговое: затрагивает merge-gate, coverage-gate и сквозной инвариант времени
-reaper/lease — поэтому регистрируется глобально.
-
-## Решение (сводка)
-
-Аддитивно, под kill-switch, never-raise, скоуп self-hosting; исходная защита merge-gate от
-семантического конфликта сохранена (красный re-test по-прежнему откатывает).
-
-- **D1 — tree-kill.** Новый leaf `src/proc_group.py::run_in_process_group` спавнит
-  оркестратор-порождённые pytest-прогоны в отдельной группе процессов (`start_new_session`) и при
-  таймауте убивает **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL, зеркало
-  `launcher.stop_process`). Используют `retest_branch` и `measure_coverage`; контракты возврата 1:1,
-  меняется лишь побочный эффект (нет сирот). Fallback на прежний `subprocess.run` при kill-switch off
-  / не-POSIX. Kill-switch `subprocess_tree_kill_enabled`.
-- **D2 — классификация.** Чистый `merge_gate.classify_retest_failure(reason) → timeout|red|lock-busy|
-  other`; `check_branch_mergeable` не меняет имя/семантику/PASS-FAIL (реестр `QG_CHECKS` цел).
-- **D3 — маршрутизация.** Инфра-таймаут → `_handle_merge_gate_infra_retry` (ограниченный повтор/defer
-  по образцу `_handle_merge_gate_defer`, **без** отката на `development`, **без** расхода
-  developer-retry); исчерпание → отдельный **инфра-alert** (не «developer must fix»). Красный re-test
-  → прежний `_handle_merge_gate_rollback`. Kill-switch `merge_retest_infra_tolerance_enabled`,
-  бюджеты `merge_retest_infra_max_retries`/`merge_retest_infra_retry_delay_s`.
-- **D4 — контракт re-test.** Локальный re-test исполняется ⇔ rebase реально сдвинул HEAD (`main`
-  уехал); доказанный no-op rebase пропускает re-test (как уже делает путь
-  `premerge_rebase_always=False` для не-behind ветки), offline, без сетевого CI-запроса. Fail-safe: на
-  любой неопределённости re-test бежит. Kill-switch `merge_retest_skip_when_current_enabled`.
-- **D5 — бюджет.** `merge_retest_timeout_s` 600 → 900 (запас 74%) + валидация (непозитив → дефолт +
-  WARNING). Сквозной инвариант `reaper_max_running_s (5400) > Σ(deploy-staging gate-work ≈4460)+grace`
-  проверен — `reaper_max_running_s` **не меняется**.
-- **D6 — наблюдаемость.** Счётчики `merge_gate` + блок `merge_gate` в `GET /queue`; координация с
-  ORCH-111 без дубля (ORCH-110 предотвращает/толерирует у источника, ORCH-111 наблюдает).
-
-## Инварианты (неприкосновенны)
-
-- `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict ключи / схема БД —
-  **байт-в-байт** (под-гейт — врезка в `advance_stage`, не новая стадия/QG; новых таблиц/колонок нет).
-- INV-4: никогда push/force-push `main`, merge только через Gitea PR API; прод-контейнер не
-  рестартится; detached-деплой не трогается.
-- never-raise во всех новых функциях/врезках; исключение не уходит в `advance_stage`/монитор.
-- Kill-switch + нулевая регрессия: каждый флаг off → байт-в-байт до-ORCH-110; enduro (non-self) — no-op.
-
-## Последствия
-
-- **+** Устранён ложный откат/manual-gate при инфра-таймауте; устранена утечка CPU от сирот;
-  re-test не избыточен на актуальной ветке.
-- **−** До ~34 мин на инфра-ретраи перед alert (вместо мгновенного ложного отката); +5 конфиг-ключей.
-- **Откат:** вернуть 4 kill-switch и `merge_retest_timeout_s=600`.
-
-## Ссылки
-- Детально: `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`
-- Код: `src/merge_gate.py`, `src/coverage_gate.py`, `src/qg/checks.py`, `src/stage_engine.py`,
-  `src/config.py`, `src/agents/launcher.py`, `src/job_reaper.py`, новый `src/proc_group.py`
-</content>

docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md

@@ -1,95 +0,0 @@
----
-work_item: ORCH-113
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# adr-0043: Reaper Tier-2 — in-memory ownership-маркер финализации `deploy-staging` (живой finalizer не реапится)
-
-- **Статус:** proposed
-- **Дата:** 2026-06-15
-- **Задача:** ORCH-113 (bug → escalate full-cycle; кластер инцидента ORCH-111)
-- **Детальный ADR:** `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`
-- **Уточняет:** `adr-0011` (job-reaper/lease-reclaim ORCH-065), `adr-0040` (timeout-бюджеты ORCH-109),
-  `adr-0042` (merge-gate re-test infra-tolerance + tree-kill ORCH-110), `adr-0041`
-  (ORCH-111 `proc_blocking` — комплементарный наблюдатель того же инцидента)
-
-## Контекст
-
-На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит
-`agent_runs.finished_at`/`exit_code` **первым**, затем синхронно, в своём потоке, прогоняет тяжёлый
-набор edge-под-гейтов через `_try_advance_stage → advance_stage` (`stage_engine.py:327–368`):
-`security` → `merge-gate` (полный локальный re-test, `merge_retest_timeout_s=900`) → `coverage`
-(`pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание staging) — **минуты**, — и лишь
-потом `_finalize_job`. Reaper Tier-2 (`job_reaper.py:197–209`) меряет `finished_age_s` от
-`finished_at` = **начала** финализации и по `reaper_finalize_grace_s=300` считает живого, долго
-финализирующего монитора мёртвым → независимо повторяет тот же тяжёлый advance. Атомарный
-claim-before-act защищает лишь **флип строки** job, но не **side-effectful исполнение edge-гейтов**
-(монитор не claim'ит строку перед `advance_stage`) → две `advance_stage` параллельно.
-
-Инцидент ORCH-111 (job 1914): повторный re-test красный, ложный откат `deploy-staging → development`
-(+ ложный developer-retry), **параллельно** исходный finalizer довёл deploy до SUCCESS и смержил
-PR #130 — состояние раздвоилось. Реального сигнала «жив ли finalizer» нет (pid агента в Tier-2 мёртв в
-обоих случаях). Per-stage grace, покрывающая Σ финализации (≈4160с), невозможна без нарушения сквозного
-бюджета ORCH-065/109/110 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace (≈4460)`.
-
-**Решающий факт (проверен):** монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без
-`--workers`), общая SQLite-БД → живость finalizer'а определяется **in-memory**. Рестарт покрыт
-существующим `requeue_running_jobs()` (running→queued), вызываемым в `main.lifespan` **до** старта reaper.
-
-## Решение
-
-1. **Leaf `src/finalizer_liveness.py`** — чистый процесс-локальный реестр владения финализацией
-   (паттерн `serial_gate`/`coverage_gate`: never-raise, без сети/БД): `mark(job_id, run_id, stage)` /
-   `clear(job_id)` / `is_active(job_id) -> bool` / `snapshot()`; `{job_id: {...}}` + `threading.Lock`;
-   собственного TTL нет (ограничение по времени даёт Tier-3).
-2. **Эмиссия владения** — `launcher._monitor_agent`: `mark(...)` сразу после штампа `exit_code`
-   (самый ранний момент Tier-2), `clear(...)` в `try/finally` вокруг хвоста финализации → исключение
-   в потоке монитора гарантированно снимает владение (reaper добивает). Гибель процесса → рестарт →
-   `requeue_running_jobs` → реестр пуст (restart-safe без durable-хранения).
-3. **Консультация reaper** — `_reap_job` Tier-2 (`exit_code` записан, `finished_age >= grace`): если
-   `reaper_finalizer_liveness_enabled` **И** стадия `== "deploy-staging"` **И** `is_active(job_id)` →
-   **defer** (лог + счётчик), не реапить через Tier-2, провалиться к Tier-3. Иначе — прежний путь.
-   **Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — добивает всегда в ограниченное время.
-4. **Скоуп/флаг** — только глобальный kill-switch `reaper_finalizer_liveness_enabled`
-   (env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`); **без** per-repo разреза (баг общий
-   для всех репо со стадией `deploy-staging`; per-repo оставил бы баг активным для части репо).
-   `False` → reaper байт-в-байт прежний; стадии `!= deploy-staging` не консультируются.
-5. **Наблюдаемость** — счётчик `finalizer_defers_total` + размер `snapshot()` в блоке `reaper`
-   `GET /queue`; существующие ключи ответа не меняются; новых эндпоинтов нет.
-
-**Инварианты:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
-существующих таблиц — **байт-в-байт**; **нулевое** изменение схемы БД; reaper остаётся never-raise
-наблюдателем; `reaper_finalize_grace_s` и `reaper_max_running_s` **не меняются** (сквозной бюджет цел);
-фикс не рестартит прод и не пушит `main`.
-
-## Альтернативы
-- Per-stage grace, покрывающая Σ — отвергнуто (нарушает бюджет `5400 > Σ+grace`; таймер = источник бага).
-- Durable-колонка (heartbeat/owner-токен) — отвергнуто (один процесс → in-memory авторитетно; рестарт
-  покрыт requeue; блокирующий re-test не может бить heartbeat).
-- Sub-state `finalizing` в `jobs.status` — отвергнуто (меняет семантику статуса для
-  claim/requeue/reconciler/reaper — нарушение NFR-2).
-- Lease-файл на `(job, stage)` — отвергнуто (тяжелее, дублирует merge-lease, TTL = таймер-проблема).
-- Флип job из `running` до тяжёлых гейтов — отвергнуто (ломает `get_running_jobs`/метрики и
-  restart-requeue).
-
-## Последствия
-- (+) Устранены повторный прогон edge-гейтов, ложный откат и расхождение состояния при живом долгом
-  finalizer'е `deploy-staging`; идемпотентность исполнения edge-гейтов через владение.
-- (+) Реально мёртвый/застрявший finalizer добивается (finally-clear → Tier-2; иначе Tier-3); функция
-  reaper ORCH-065 сохранена.
-- (+) Нулевое изменение схемы и контрактов; сквозной бюджет ORCH-065/109/110 не тронут; откат — один
-  env-флаг.
-- (−) Гарантия владения валидна при **одном процессе/одной БД** (проверено: один uvicorn-воркер); ввод
-  `--workers>1` потребует durable-сигнала (риск в work-item 10-tech-risks).
-- (−) Окно «штамп `finished_at` → `mark()`» (git push) маркером не покрыто — закрыто прежним grace=300.
-
-## Связи
-- Базируется/уточняет: `adr-0011`, `adr-0040`, `adr-0042`, `adr-0041`.
-- Союзные задачи кластера инцидента ORCH-111: `ORCH-110` (инфра-толерантность merge-gate — отдельный
-  объём, не дублировать), `ORCH-109` (бюджеты).
-- Детально: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`.
-</content>

docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md

@@ -1,66 +0,0 @@
----
-work_item: ORCH-112
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# adr-0044: Гигиена shared deploy-базы — устойчивый self-deploy `git pull`
-
-Сквозное (cross-cutting) решение. Детальный per-work-item ADR —
-`docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`.
-
-## Статус
-Proposed (ORCH-112)
-
-## Контекст (сквозной)
-
-Глобальный путь прод-деплоя self-hosting (`deploy`-стадия, ORCH-036) исполняет хост-хук
-`scripts/orchestrator-deploy-hook.sh`, чей шаг «2. Pull latest code» — **голый** `git pull origin main`
-в shared main clone (`settings.deploy_host_repo_path`). Любая грязь рабочего дерева (модифицированный
-tracked-файл и/или untracked-остатки failed/cancelled/брошенной задачи) **блокирует** merge → деплой
-встаёт → ручное вмешательство. На self-hosting (один прод-инстанс на все проекты с общей БД/очередью)
-это **групповой риск**: залипший self-deploy орка останавливает обслуживание всех проектов
-(инцидент ORCH-111, грязь от ORCH-104).
-
-## Решение (сквозное)
-
-Вводится **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`), + новый чистый never-raise
-leaf-компонент `src/checkout_hygiene.py`:
-
-- **Хук** перед `git pull origin main` приводит грязную deploy-базу к чистому актуальному `origin/main`
-  (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`), **строго сохраняя**
-  rollback/лог-артефакты. Гейт — env `CHECKOUT_HYGIENE`, инжектится `self_deploy.build_deploy_command`.
-- **Leaf** `checkout_hygiene` решает условность (`applies(repo)`: kill-switch `checkout_hygiene_enabled`
-  + скоуп `checkout_hygiene_repos`, пусто → self-hosting only), строит env-префикс, читает sentinel
-  отчёта, шлёт Telegram-алерт. Образец `serial_gate`/`cancel`/`self_deploy`.
-- **Сходимость** базы после failed/cancelled (FR-2) — этим же deploy-time self-heal; `cancel_task`
-  (ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
-- **Наблюдаемость** — хук пишет sentinel `hygiene`, Phase-C finalizer читает и шлёт Telegram-алерт
-  (best-effort, never-raise).
-- **Инвариант** «main checkout — deploy/worktree-management база, НЕ workspace» документируется
-  (INFRA.md + architecture/README.md); de-facto энфорс — сам resilient-pull.
-
-## Кросс-каттинг-инварианты (обязательны к соблюдению будущими задачами)
-
-- **INV-HYGIENE-1 (никогда `-x`):** hygiene-`git clean` — только `git clean -fd`. `-x` удалил бы
-  gitignored `.env` (прод-секреты) / `data/*.db` (БД прода) / `build/`. Анти-регресс — статический тест.
-- **INV-HYGIENE-2 (явные excludes):** `.deploy-prev-image-*` (rollback, `deploy_prod_prev_image_file`)
-  и `deploy-hook.log` — untracked-но-НЕ-ignored → обязательны `-e`-исключения; их удаление сломало бы
-  rollback.
-- **INV-HYGIENE-3 (скоуп = `$REPO`):** гигиена оперирует только рабочим деревом deploy-базы;
-  sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json` и `.git/worktrees/*` — вне области.
-- **Self-hosting safety (NFR-1):** никогда не трогать `main` на remote, не force-push, не рестартить
-  прод вне штатного гейта, не сносить worktree/ветки других активных задач.
-- **Нулевая регрессия (NFR-5):** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` /
-  machine-verdict ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — байт-в-байт. Это
-  устойчивость deploy-пути, **не** Quality Gate и **не** стадия.
-
-## Связи
-- Дополняет: adr-0007 (executable self-deploy, ORCH-036), adr-0008 (image-freshness, ORCH-058).
-- Не нарушает: adr-0026 (STOP/cancel, ORCH-090) — каскад cancel не трогается.
-
-## Откат
-`ORCH_CHECKOUT_HYGIENE_ENABLED=false` → прод-деплой байт-в-байт до ORCH-112 (голый `git pull origin main`).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

docs/architecture/internals.md

@@ -70,14 +70,6 @@ STAGE_TRANSITIONS = {
 рёбер не меняются), а терминал STOP-отмены. Системный предикат «задача завершена» —
 `stage ∈ {done, cancelled}` (синхронно в `reconciler`/`serial_gate`/`task_deps`; adr-0026).
 
-**Ось «пауза» ⊥ оси «терминальность» (ORCH-124, adr-0051):** serial-gate вводит **отдельную** ось
-паузы `tasks.paused_at IS NOT NULL` (durable per-task park-сигнал) — **ортогональную** терминалу. Для
-serial-gate «активная задача» ⇔ `stage NOT IN ('done','cancelled') AND paused_at IS NULL` (паузнутый
-предшественник не держит FIFO). **Терминал `{done,cancelled}` НЕ расширяется паузой:** `task_deps` и
-`stages.py` колонку `paused_at` НЕ читают (паузнутая объявленная зависимость по-прежнему блокирует
-зависимый job; пауза не обходит `repo_freeze`). Пауза — признак планировщика очереди, не стадия и не
-терминальное состояние.
-
 ### 3. Quality Gates (`src/qg/checks.py`)
 
 | Check | Метод проверки |
@@ -101,36 +93,9 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash
 Каждый запуск:
 1. Записывает run в DB (agent_runs)
 2. Запускает subprocess. **stdout/stderr перенаправляются СРАЗУ в файл `/app/data/runs/{id}.log` на уровне ОС** (Popen `stdout=log_fh`). Никакого PIPE в памяти оркестратора → нет PIPE-deadlock, нет потока-читателя, нет зомби (B-2).
-3. Стартует **watchdog thread** (per-role wall-clock бюджет → SIGTERM→grace→SIGKILL по pid; ORCH-109: developer 60 мин / reviewer 50 мин / прочие 30 мин дефолт, `_resolve_timeout`)
+3. Стартует **watchdog thread** (timeout 30 мин → SIGKILL по pid)
 4. Стартует **monitor thread**: `proc.wait()` (гарантированный reap → реальный exit_code в БД) → закрывает log_fh → git commit/push → auto-advance
 
-**Детерминированные перехваты `launch_job` ДО `_spawn` (no-LLM джобы).** Перед `_spawn` `launch_job`
-перехватывает зарезервированные роли и исполняет их детерминированно, сам ведя `jobs`-строку через
-`mark_job` (нет `agent_runs`, нет токенов): `deploy-finalizer` (D1, ORCH-036 Phase C) и
-`post-deploy-monitor` (D2, ORCH-021). **ORCH-115 ([adr-0048](adr/adr-0048-deterministic-staging-runner.md)):**
-тем же паттерном перехватывается джоб `deployer` на стадии `deploy-staging` для in-scope репо
-(дискриминатор — **стадия задачи**, не имя роли: роль `deployer` общая для `deploy-staging`/`deploy`;
-+`staging_runner.applies(repo)` под kill-switch `staging_runner_enabled`, скоуп `staging_runner_repos`,
-пусто → self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к
-LLM). Leaf `src/staging_runner.py` (зеркало `run_deploy_finalizer`) исполняет staging-сюиту через
-`proc_group` (tree-kill, таймаут `staging_runner_timeout_s`), маппит exit-код
-`self_deploy.map_exit_code_to_status`, пишет `15-staging-log.md` (тот же machine-key `staging_status:`)
-и вызывает существующий `advance_stage(finished_agent="deployer")` (см. §5). Так LLM-агент `deployer`
-на `deploy-staging` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты.
-**ORCH-116 ([adr-0050](adr/adr-0050-deterministic-test-runner.md)):** тем же паттерном (рядом с
-ORCH-115) перехватывается джоб `tester` на стадии `testing` для in-scope репо с тест-контрактом
-(дискриминатор — роль `tester` **И** `tasks.stage == "testing"` **И** `test_runner.applies(repo)` под
-kill-switch `test_runner_enabled`, скоуп `test_runner_repos`, резолв `_has_test_contract`; пусто →
-self-hosting only; `should_intercept` never-raise → `False` → штатный `_spawn`, fail-safe к LLM). Leaf
-`src/test_runner.py` (зеркало `run_staging_gate`) исполняет регресс `pytest <target>` **в worktree
-ветки** через `proc_group` (tree-kill, таймаут `test_runner_timeout_s`) + read-only smoke, маппит
-exit-код `self_deploy.map_exit_code_to_status` в токенах `result:` (`0→PASS`/иначе→`FAIL`), пишет
-`13-test-report.md` (тот же machine-key `result:`; 52c-`status:` выровнен по вердикту — D6.1) и вызывает
-существующий `advance_stage(finished_agent="tester")` (см. §5). Двухуровневый исход (анти-ORCH-110):
-сюита НЕ исполнилась → bounded defer re-queue **`tester`**-джоба, не код-фейл-откат. Так LLM-агент
-`tester` на `testing` исчезает из happy-path; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_tests_passed`/схема
-БД не тронуты.
-
 ### 5. Auto-advance (`launcher._try_advance_stage`)
 
 После успешного завершения агента:
@@ -223,21 +188,6 @@ CREATE TABLE events (
     payload TEXT,
     created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
 );
-
--- ORCH-114 (adr-0045): durable transition-ownership lease. ОДНА аддитивная таблица
--- (CREATE TABLE IF NOT EXISTS, паттерн repo_freeze/coverage_baseline/lessons) — одна
--- строка = ≤1 активный владелец side-effectful перехода задачи. Живость владельца =
--- owner_boot_id (нонс старта процесса; рестарт ⇒ смена ⇒ прежний lease мёртв) +
--- pid_alive(owner_pid). БЕЗ epoch/version-колонки на tasks (стадия = версия CAS).
-CREATE TABLE transition_lease (
-    task_id       INTEGER PRIMARY KEY,
-    owner         TEXT NOT NULL,   -- monitor|reaper|reconciler|webhook|finalizer|engine
-    owner_pid     INTEGER,
-    owner_boot_id TEXT,
-    run_id        INTEGER,
-    stage         TEXT,            -- from-стадия захвата (контекст/наблюдаемость)
-    acquired_at   TEXT DEFAULT (datetime('now'))
-);
 ```
 
 ## Deployment
@@ -309,7 +259,7 @@ services:
 
 | Механизм | Описание |
 |----------|----------|
-| Watchdog | Per-role wall-clock бюджет (ORCH-109): developer 60 мин / reviewer 50 мин / прочие 30 мин (`_resolve_timeout`) → SIGTERM→grace→SIGKILL + exit_code=-9. Tier-3 backstop `reaper_max_running_s`=90 мин > max(timeout)+grace (ORCH-065) |
+| Watchdog | Каждый агент: timeout 30 мин → SIGKILL + exit_code=-9 |
 | safe.directory | git операции работают в любой директории |
 | Max retries | Developer: max 3 попытки, затем эскалация |
 | Zombie-free | stdout идёт сразу в файл + monitor `proc.wait()` → процесс всегда reap'нут (B-2) |
@@ -402,8 +352,8 @@ webhook (plane/gitea)                 background thread (queue_worker)
 |--------|------------|
 | `status` | `queued` → `running` → `done` \| `failed` \| `cancelled` (ORCH-090: терминальный исход STOP-отмены, не реквью'ится) |
 | `attempts` / `max_attempts` | счётчик попыток (инкремент при claim) / лимит ретраев (default 2) |
-| `run_id` | FK на `agent_runs.id` после старта. **ORCH-126 (adr-0052):** run-ownership; `queued ⇒ run_id IS NULL` (история run'а живёт в `agent_runs`, не в `jobs.run_id`) |
-| `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent). **ORCH-126 (adr-0052):** `queued ⇒ pid IS NULL` — иначе протухший (возможно переиспользованный ОС) pid ложно «оживает» в Tier-1 reaper и клинит очередь |
+| `run_id` | FK на `agent_runs.id` после старта |
+| `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent) |
 | `task_content` | ТЗ, которое пишется в task-файл агента |
 | `error` | последняя ошибка |
 
@@ -419,17 +369,7 @@ 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 переисполняют свои
-side-effectful переходы **последовательно** (один владелец), без двойного необратимого
-эффекта. Идемпотентность самого re-drive обеспечивают существующие авторитетные факты
-(SHA-in-main ORCH-071/073, маркер `INITIATED` ORCH-036, coverage-ratchet CAS ORCH-027) —
-НЕ новый recovery-мозг. Потом стартует воркер; на shutdown — `worker.stop()` (Event.set + join).
+Потом стартует воркер; на shutdown — `worker.stop()` (Event.set + join).
 
 ### Job-reaper (ORCH-065, рестарт НЕ требуется)
 
@@ -445,25 +385,7 @@ daemon-поток `src/job_reaper.py` (каркас `reconciler`) периоди
   git push/PR/Plane-комментарии (секунды-десятки секунд) и лишь потом
   `_finalize_job`; pid агента к этому моменту мёртв в обоих случаях. Поэтому
   Tier-2 реапит только после finalization-grace `reaper_finalize_grace_s`
-  (`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится.
-  **ORCH-113 (adr-0043):** на ребре `deploy-staging → deploy` финализация длится
-  **минуты** (тяжёлые edge-под-гейты после штампа `finished_at`, до `_finalize_job`),
-  grace=300 это не покрывал → живой долгий finalizer ошибочно реапился и повторял
-  advance (ложный откат, инцидент ORCH-111). Tier-2 консультирует процесс-локальный
-  реестр владения `src/finalizer_liveness.py` (`mark`/`clear` в потоке монитора через
-  try/finally): при `stage=="deploy-staging"` И активном владении → **defer**;
-  Tier-3 backstop маркер игнорирует (мёртвый/застрявший finalizer добивается).
-  Kill-switch `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`; in-memory, restart-safe через
-  `requeue_running_jobs` (до старта reaper); схема БД и сквозной бюджет не тронуты.
-  **ORCH-114 (adr-0045):** обобщает это in-memory-владение до **durable, кросс-путевого**
-  `transition_lease` (таблица `task_id PK, owner, owner_pid, owner_boot_id, …`): reaper
-  консультирует durable-lease на **всех** релевантных путях (не только Tier-2/`deploy-staging`),
-  живость владельца = `pid_alive(owner_pid)` + совпадение boot-id (рестарт ⇒ прежние lease мертвы);
-  парная CAS-запись стадии (`update_task_stage_cas`, `WHERE id=? AND stage=?`) — аборт проигравшего
-  без побочных эффектов; reconciler F-1 и webhook тоже defer при живом владельце. Kill-switch
-  `ORCH_TRANSITION_LEASE_ENABLED` (off → ровно поведение ORCH-113 выше); `finalizer_liveness.py`
-  не правится (надстройка durable-слоя поверх). Потолок возраста lease = `reaper_max_running_s`
-  (Tier-3 force-освобождает), сквозной бюджет цел;
+  (`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится;
 - **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
 
 Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,
@@ -479,35 +401,6 @@ claim делает `_try_advance_stage` (advance+enqueue) — проигравш
 / `ORCH_LEASE_RECLAIM_ENABLED`; снимок в `GET /queue` (блок `reaper`). Подробнее —
 adr-0011.
 
-### Инвариант run-ownership строки `jobs` (ORCH-126, adr-0052)
-
-Колонки `jobs.run_id`/`jobs.pid` — **общий контракт liveness/идентичности run'а** (читают
-job-reaper Tier-1 по `pid`, `/metrics` `get_running_agents`). Системный инвариант данных:
-
-> **`status='queued' ⇒ run_id IS NULL AND pid IS NULL AND started_at IS NULL`.**
-
-То есть **queued-job никогда не несёт run-ownership** — оно принадлежит ровно одной активной
-попытке (`running` после стампа в `_spawn`). Корень дефекта (инцидент ORCH-124/125, job 2286
-`queued + run_id=759 + pid=35 + started_at=NULL`): ни один путь возврата в `queued` не сбрасывал
-run-ownership, а после рестарта контейнера pid мог быть **переиспользован** ОС → `pid_alive(stale)`
-ложно `True` → reaper «видел живой» фантомный `running` и при `max_concurrency=1` клинил клейм
-**всей** общей очереди. Соблюдение (без смены схемы БД):
-- **Forward-cleanup** — каждый путь перехода в `queued` (`requeue_running_jobs`,
-  `mark_job('queued')`, `mark_job_transient`, `reap_running_job('queued')`) выставляет
-  `run_id=NULL, pid=NULL` той же UPDATE-транзакцией, что чистит `started_at` (атомарные
-  `status`-guard'ы сохранены). Безусловно (исправление инварианта данных, без флага).
-- **Clean claim (defense-in-depth)** — `claim_next_job` при флипе `queued→running` сбрасывает
-  stale `pid`/`run_id` тем же UPDATE → между claim и стампом `pid` в `_spawn` строка несёт
-  `pid IS NULL`. SELECT-гейт не тронут (offline hot-path).
-- **Self-heal + наблюдаемость** — `db.sanitize_impossible_queued()` идемпотентно санирует
-  «невозможные» queued-строки при старте (`main.lifespan`) и на каждом реап-тике (never-raise,
-  kill-switch `ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED`, дефолт on); счётчик
-  `impossible_queued_total` в блоке `reaper` снимка `GET /queue`.
-
-**Норматив:** любой новый путь возврата job в `queued` ОБЯЗАН соблюсти инвариант (сбросить
-`run_id`/`pid`); reviewer ловит нарушение как ≥P1. Подробнее — adr-0052,
-`docs/work-items/ORCH-126/06-adr/ADR-001-queued-job-run-ownership-hygiene.md`.
-
 ### Конфиг
 
 - `ORCH_MAX_CONCURRENCY` (default 1) — лимит параллельных jobs.

docs/architecture/llm-call-sites.md

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

docs/architecture/llm-determinization-roadmap.md

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

docs/architecture/llm-usage-policy.md

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

docs/deployment/BUNDLED_SETUP.md

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

docs/deployment/LITE_SETUP.md

@@ -163,18 +163,6 @@ cp .env.watchdog.example .env.watchdog
 # заполнить два ключа: WATCHDOG_TG_BOT_TOKEN / WATCHDOG_TG_CHAT_ID (бота создадим в §8)
 ```
 
-**Опционально (ORCH-111): алерт на осиротевший тест-процесс.** Watchdog умеет
-поднимать сигнал `proc_blocking` на долго живущий процесс тест-класса (по умолчанию
-`pytest`), репарентированный на хост и грузящий CPU. По умолчанию **выключен**
-(`WATCHDOG_PROC_ENABLED=false`) — нулевая регрессия. Чтобы включить, в `.env.watchdog`:
-`WATCHDOG_PROC_ENABLED=true`, при необходимости подстройте `WATCHDOG_PROC_AGE_MIN`
-(минуты; **обязан** превышать `max(merge_retest_timeout_s, coverage_run_timeout_s)/60`,
-дефолт 60), `WATCHDOG_PROC_PATTERNS` (CSV cmdline-подстрок), `WATCHDOG_PROC_COOLDOWN_S`.
-Для видимости процессов хоста сервису `orchestrator-watchdog` в `docker-compose.yml`
-задан `pid: host` (привилегия только у наблюдателя, read-only). **Проверка:**
-`grep -E '^WATCHDOG_PROC_ENABLED=' .env.watchdog` — если `true`, после рестарта только
-sidecar (`docker compose up -d orchestrator-watchdog`) в его логах виден тик без ошибок.
-
 **Проверка (резолв всей конфигурации):**
 
 ```bash
@@ -206,13 +194,12 @@ curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/" \
 `ORCH_PLANE_API_TOKEN` в `.env`. Токен должен иметь право создавать проекты/статусы
 (нужно для `onboard_project.py apply`, §10).
 
-**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **23 канонических статуса** с
+**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **22 канонических статуса** с
 точными именами и группами; их создаёт `python3 scripts/onboard_project.py apply` (§10),
 полная таблица — `docs/operations/ONBOARDING.md` §1 (golden source; здесь не дублируется).
-Три имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
-активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя),
-**`STOP`** (отмена задачи; обязан быть в группе `cancelled`) и **`Оценка`** (триггер
-оценки задачи, ORCH-020; группа `unstarted`/`backlog`, НЕ терминальная).
+Два имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
+активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя) и
+**`STOP`** (отмена задачи; обязан быть в группе `cancelled`).
 
 ```bash
 # после §10 — проверить, что статусы созданы:
@@ -220,7 +207,7 @@ curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/<proj
   -H "X-API-Key: $ORCH_PLANE_API_TOKEN" | python3 -m json.tool | grep -c '"name"'
 ```
 
-**Проверка:** счётчик имён = 23 (или больше, если в проекте остались дефолтные статусы
+**Проверка:** счётчик имён = 22 (или больше, если в проекте остались дефолтные статусы
 Plane) и среди них `Confirm Deploy` и `STOP` — PASS.
 
 **5.4. Webhook + HMAC.** Приёмник — `POST https://<orchestrator-public-host>/webhook/plane`;
@@ -433,7 +420,7 @@ curl -fsS http://127.0.0.1:8501/health
 
 ## 10. Регистрация проекта заказчика
 
-Onboarding-CLI создаёт Plane-проект с 23 статусами и лейблами (`autoApprove` /
+Onboarding-CLI создаёт Plane-проект с 22 статусами и лейблами (`autoApprove` /
 `autoDeploy` / `Bug`), Gitea-репо с webhook'ом, скелет репо (kit) и печатает merged-реестр.
 Полный runbook — `docs/operations/ONBOARDING.md`; Lite-последовательность:
 

docs/operations/FAQ_STOP.md

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

docs/operations/INFRA.md

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

docs/operations/ONBOARDING.md

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

docs/overview/business.md

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

docs/overview/presentation.md

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

docs/overview/tech-agents.md

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

docs/overview/tech-architecture.md

@@ -32,7 +32,6 @@ worker запустил агента стадии → результат про
 | **Очередь задач** (`jobs` + worker) | Собственная очередь на SQLite: атомарный захват job'а, ретраи с backoff, зависимости между job'ами, ограничение параллелизма. |
 | **State machine** (`src/stages.py`) | Карта стадий `STAGE_TRANSITIONS`: для каждой стадии — следующая, агент и гейт выхода. Единственный источник истины о конвейере. |
 | **Stage engine** (`src/stage_engine.py`) | Исполняет переходы: диспетчеризация гейтов, откаты, под-гейты деплойного ребра, синхронизация статусов с Plane. |
-| **Transition-lease** (`src/transition_lease.py`) | Durable-владение side-effectful переходом стадии: один владелец на задачу (lease на входе + expected-stage CAS на записи), liveness по pid+boot-id. Не даёт конкурентному или после-рестартовому повторному входу дважды применить необратимый эффект (merge / деплой / ratchet). |
 | **Agent launcher** (`src/agents/launcher.py`) | Запускает Claude CLI агента в изолированном git worktree ветки задачи, следит за процессом (watchdog), авто-продвигает стадию по завершении. |
 | **Реестр гейтов** (`src/qg/checks.py`) | `QG_CHECKS` — машинные проверки выхода со стадий; вердикты читаются только из YAML-frontmatter артефактов. |
 | **Plane-sync** (`src/plane_sync.py`) | Индикация статусов в Plane (слой «показать человеку», никогда не управление конвейером). |

docs/overview/tech-data-model.md

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

docs/overview/tech-integrations.md

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

docs/overview/tech-observability.md

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

docs/overview/tech-pipeline.md

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

docs/overview/tech-quality-security.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,102 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-020
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-17
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-020
-version: 3
----
-
-# Review ORCH-020 — Оценка задачи, запускаемая Plane-статусом «Оценка»
-
-## Summary
-
-Реализация полностью соответствует ТЗ, ADR и критериям приёмки; качество кода высокое;
-**документация обновлена исчерпывающе**. Новый leaf `src/estimator.py` (never-raise, kill-switch
-`estimator_enabled` + скоуп `estimator_repos` пусто→self-hosting only) реализует детерминированную
-эвристику по истории завершённых задач **без LLM** (ADR-001 D1 + политика determinization ORCH-118).
-Триггер — fail-closed `proj_states.get("estimate")`-ветка в `handle_issue_updated` (ключ `estimate`
-намеренно отсутствует в `_DEFAULT_STATES` — подтверждено), третий член семейства action-статусов
-STOP/Confirm Deploy. Контрол-пас не тронут (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/
-схемы существующих таблиц — байт-в-байт; `git diff` не содержит правок этих сущностей вне комментариев).
-Все кросс-модульные контракты сверены по коду и существуют.
-
-Проверки, выполненные ревьюером:
-- `git diff origin/main...HEAD` (чистый scope ORCH-020, 42 файла) — изолирован от шума устаревшего
-  локального `main`.
-- Контракты: `usage.task_usage_summary` возвращает `total_in/total_out/total_cost` (совпадает с
-  `record_actual_on_done`); `fmt_tokens/fmt_cost/fmt_duration` существуют; колонки `agent_runs`
-  (`input_tokens/cache_read_tokens/cache_creation_tokens/output_tokens/cost_usd`) существуют и точно
-  совпадают с SQL `completed_task_stats`; `has_active_job_for_task`/`get_task_by_work_item_id`/
-  `get_task_by_plane_id` существуют; `plane_write_guard.OP_STATE`/`OP_COMMENT` существуют.
-- `estimate` отсутствует в `_DEFAULT_STATES`, `backlog` присутствует (AC-T5/AC-T2).
-- Тесты: `tests/test_orch020_estimator.py` + `tests/test_orch020_estimator_branches.py` → **67 passed**.
-- Анти-регресс: `tests/test_webhooks.py` + `tests/test_plane_status_model.py` +
-  `tests/test_stage_visibility.py` → **30 passed**.
-- `src/db.py` не содержит ALTER/CREATE существующих таблиц (`tasks`/`agent_runs`/`jobs`) — только
-  аддитивная `task_estimates` (`CREATE TABLE IF NOT EXISTS`, `UNIQUE(work_item_id)`).
-
-Соответствие AC (поштучно): AC-T1✓ AC-T2✓ AC-T3✓ AC-T4 (UPSERT по `work_item_id`, `estimate_count++`)✓
-AC-T5 (fail-closed)✓ AC-T6 (anti-disruption `should_estimate` + anti-loop `backlog`-эхо)✓ AC-1
-(4 величины, bootstrap не бросает)✓ AC-2 (`story_points_for` ∈ {1,2,3,5,8}, чистая)✓ AC-3
-(`set_issue_estimate_point`→`estimate_point` под guard)✓ AC-4 (`set_issue_point`→`point` на `done`, не
-перезаписывает forecast)✓ AC-5 (`card_line` в `render_task_tracker`, never-raise)✓ AC-6 (`add_comment`)✓
-AC-7 (`POST/GET /estimate`, то же ядро — см. P3 ниже)✓ AC-8 (best-effort, не блокирует)✓ AC-9
-(leaf-инварианты + `GET /queue` блок)✓ AC-10 (control-path/hot-path не тронуты)✓ AC-11 (нет кода выбора
-модели; out-of-scope зафиксирован)✓ AC-12 (леджер + fail-safe запись)✓.
-
-## Findings
-
-### P0 — Blocker
-- Нет.
-
-### P1 — Must fix
-- Нет.
-
-### P2 — Should fix
-- Нет.
-
-### P3 — Nice-to-have (не блокируют приёмку)
-- [ ] `POST /estimate` (`src/main.py`) резолвит `repo` только из существующей строки `tasks`
-  (`db.get_task_by_work_item_id`). Для **чистой backlog-задачи без строки `tasks`** `repo=""` →
-  `estimator.applies("")` → `False` → ответ `{"enabled": false}`. Статус-триггер (`handle_estimate`)
-  такой issue оценивает (резолвит `repo` из реестра проекта). Расхождение **benign** (явный
-  `enabled:false`, не ложное поведение), эндпоинт по AC-7 опциональный и не подаётся как единственный
-  путь. Для паритета можно (в будущем) резолвить `repo` из проекта и в эндпоинте.
-- [ ] `_patch_issue_fields` (`src/plane_sync.py`) использует `plane_write_guard.OP_STATE` для PATCH
-  не-статусного поля (`estimate_point`/`point`). Семантически это field-patch, а не смена статуса; для
-  точности аудита guard'а уместен отдельный op-лейбл. Поведение корректно (guard всё равно блокирует
-  прод-запись из тест-процесса, ORCH-117).
-- [ ] Аннотации `repo: str = None` (и аналоги) в новых хелперах `db.py`/`estimator.py` — формально
-  `str | None`. Косметика; совпадает со стилем существующего кода.
-
-## Документация
-
-**Обновлена полностью (golden source наравне с кодом).** Проверено:
-- `CHANGELOG.md` — запись ORCH-020 присутствует.
-- `README.md` — таблица env: все 9 ключей `ORCH_ESTIMATOR_*`.
-- `.env.example` — все ключи `ORCH_ESTIMATOR_*` с дефолтами.
-- `docs/architecture/README.md` — добавлен компонент **Task estimator** в список + отдельная секция
-  «Оценка задачи (ORCH-020 — реализовано)».
-- ADR: per-work-item `docs/work-items/ORCH-020/06-adr/ADR-001-task-estimation-status-trigger.md` +
-  сквозной `docs/architecture/adr/adr-0054-task-estimation-status-trigger.md`.
-- **Витрина системы `docs/overview/` (ORCH-011)** — обновлена: `tech-data-model.md` (`task_estimates`),
-  `tech-pipeline.md` (секция «Оценка задачи: статус «Оценка»»), `tech-observability.md` (пункт «Оценка»
-  + блок `estimator`), `business.md` (операторская способность «Оценка задачи до запуска»),
-  `presentation.md`, `tech-integrations.md`.
-- Обзорная витрина `README.md` «Известные ограничения» — данный PR не закрывает её пунктов; обновление
-  не требуется.
-
-Артефакты задачи (`07-infra-requirements.md` — инфра-предусловие статуса «Оценка» с группой
-backlog/unstarted, `08-data-requirements.md` — схема `task_estimates`, `10-tech-risks.md`) на месте и
-согласованы с реализацией.
-
-## Вердикт
-
-`APPROVED` — нет findings P0/P1; реализация соответствует ТЗ/ADR/AC, контрол-пас не тронут,
-документация обновлена в том же PR, тесты и анти-регресс зелёные. P3-замечания — необязательные
-улучшения, приёмку не блокируют.

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

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

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

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

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

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

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

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

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

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

@@ -1,12 +0,0 @@
----
-deploy_status: SUCCESS
-work_item: ORCH-105
-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/00-business-request.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,7 +0,0 @@
-# Business Request: ORCH: timeout budgets + launch-time model telemetry for developer/reviewer
-
-Work Item ID: ORCH-109
-
-## Description
-
-TBD

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

@@ -1,167 +0,0 @@
----
-work_item: ORCH-109
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
-
-Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-Инцидент **ORCH-104** (runs 658/659/660, прод-watchdog 1800s) вскрыл **два независимых дефекта**
-в подсистеме запуска агентов и телеметрии:
-
-**Дефект A — недостаточный wall-clock бюджет для тяжёлых ролей.**
-Агенты `developer` и `reviewer` на сложных задачах **честно** упираются в общий тайм-аут
-`agent_timeout_seconds = 1800` и убиваются watchdog'ом (`launcher._watchdog → stop_process`,
-exit 143 / -9). Этот тайм-аут — единый для ВСЕХ ролей, хотя `developer` (effort `xhigh`,
-кодирующая роль) и `reviewer` объективно требуют больше времени, чем механические роли
-(`tester`/`deployer`, effort `medium`). Существует механизм per-agent override
-(`_resolve_timeout` + `agent_timeout_overrides_json`), но в проде он пуст → все роли получают 1800s.
-
-**Дефект B — потеря модели в телеметрии при оборванном прогоне.**
-Модель агента (`agent_runs.model`) пишется **только постфактум** — из финального usage-JSON
-прогона в `launcher._monitor_agent → usage.record_usage` (`_extract_model`). Убитый по тайм-ауту
-прогон **не успевает эмитить финальный JSON** → `_extract_model` возвращает `None` →
-`record_usage` пишет `model=COALESCE(None, model)` = остаётся **NULL**. В результате карточка
-Telegram-трекера (`notifications._stage_line`) и снимок `GET /metrics`/`GET /queue`
-(`db.get_running_agents`) показывают `model=null` именно тогда, когда что-то пошло не так — в
-момент, когда модель/эффорт критичны для разбора инцидента.
-
-Существующий прецедент уже решает половину задачи: **эффорт стампится в момент launch**
-(`launcher._spawn`, ORCH-087, `UPDATE agent_runs SET effort=?`), потому что CLI его в result-JSON
-не возвращает. Модель резолвится в той же точке (`resolve_agent_model`, строка 559), но **в БД на
-launch не пишется** — стампится только эффорт. ORCH-109 распространяет ту же гарантию на модель.
-
-**Сопутствующие проверки (производные от A и B):**
-- Поведение оборванного (timeout-killed) прогона в трекере и status-комментариях: модель и эффорт
-  должны быть видны даже если финальный JSON не записан.
-- Нужен ли отдельный guard: не пускать timeout-killed `developer`/`reviewer` автоматически дальше
-  по конвейеру (`development → review`, `review → testing`) без явного salvage-режима.
-
-**Установленные факты (по коду, не изобретать):**
-- `agent_runs.model` — колонка `TEXT` (NULLABLE), уже существует (`db._ensure_column`); **миграция
-  не нужна**.
-- `record_usage` уже использует `model=COALESCE(?, model)` — то есть постфактум-парс уже
-  **сохраняет** ранее проставленное значение и не затирает его `NULL`'ом. Не хватает только
-  записи на launch.
-- `_resolve_timeout(agent)` уже умеет per-agent override через `agent_timeout_overrides_json`;
-  малформный JSON → откат на глобальный дефолт + лог (never-break).
-- Кросс-инвариант reaper: `reaper_max_running_s = 3600` с зафиксированным в `config.py` правилом
-  «MUST be > max agent_timeout + grace» (Tier-3 backstop job-reaper'а, ORCH-065).
-
-## 2. Объём (scope)
-
-### В объёме
-- **Launch-time стамп модели:** записывать резолвенную `resolve_agent_model(...)` в
-  `agent_runs.model` в момент launch (`launcher._spawn`), рядом со стампом эффорта (ORCH-087).
-- **Конфигурируемый поднятый wall-clock бюджет для `developer` и `reviewer`** через config-override,
-  **без изменения** бюджета остальных ролей (`analyst`/`architect`/`tester`/`deployer`).
-- **Сохранение постфактум-enrich:** `usage.record_usage` остаётся источником обогащения
-  модели/токенов/стоимости из usage-JSON, но **перестаёт быть единственным источником истины** о
-  модели (launch-стамп — первичный, JSON — уточняющий).
-- **Видимость при timeout/kill:** строка стадии трекера и status-комментарии показывают реальные
-  модель + эффорт для оборванного прогона (model не `null`).
-- **Guard анти-salvage:** гарантия (и регресс-тест), что timeout-killed прогон
-  (`exit_code != 0`, в т.ч. -9/-15/143) **не продвигает** стадию автоматически в следующую без
-  явного решения.
-- **Обновление документации/комментариев** по конфигу тайм-аутов (`config.py`, `.env.example`).
-- **Тесты**, покрывающие все перечисленные FR.
-
-### Вне объёма
-- Изменение model-routing: все 6 агентов остаются на `claude-opus-4-8` (ORCH-41 G3 не включается).
-- Любые изменения `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей / схемы БД
-  (колонка `agent_runs.model` уже есть — миграции нет).
-- Изменение тайм-аута для ролей кроме `developer`/`reviewer`.
-- **Salvage / возобновление** недоделанной работы убитого прогона (поднять «как было», дописать,
-  переиспользовать частичный результат) — в объёме ТОЛЬКО гарантия не-продвижения, не salvage.
-- Изменения транспорта Telegram/Plane (`send_telegram`/комментарии) — только использование уже
-  доступных полей.
-- Перезапуск/деплой прод-контейнера в рамках задачи (self-hosting безопасность).
-
-## 3. Заинтересованные стороны
-
-- **Заказчик/Owner (Слава)** — инициатор; нуждается в надёжной телеметрии для разбора инцидентов и
-  в адекватных бюджетах тяжёлых ролей при пакетном автономном прогоне (эпик ORCH-088).
-- **Оператор self-hosting** — потребитель карточки трекера и `GET /metrics`/`GET /queue`; без модели
-  в карточке теряет ключевой контекст инцидента.
-- **Сам конвейер (self-hosting)** — затрагивается поведение запуска агентов; общий прод-инстанс
-  обслуживает и enduro-trails (тайм-аут — глобальная per-agent настройка, не repo-scoped).
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1** — Резолвенная модель агента сохраняется в `agent_runs.model` **в момент launch**, рядом
-  с эффортом, а не только постфактум из usage-JSON. Значение присутствует на строке прогона с
-  момента запуска и переживает любой исход прогона.
-- **BR-2** — Постфактум-парс usage/model (`usage.record_usage`) сохраняется как **обогащение**, но
-  **не как единственный источник истины**: при отсутствии/обрыве финального JSON launch-стамп модели
-  не теряется.
-- **BR-3** — Wall-clock тайм-аут для `developer` и `reviewer` поднимается и **настраивается через
-  config-override**, **без изменения** тайм-аута остальных ролей; механизм покрыт тестом/проверкой.
-- **BR-4** — При timeout/kill (оборванный прогон без финального JSON) строка стадии в трекере и
-  status-комментарии показывают **реальную модель (не `null`) и эффорт**.
-- **BR-5** — Timeout-killed прогон `developer`/`reviewer` **не продвигается** автоматически на
-  следующую стадию без явного salvage-режима; поведение зафиксировано регресс-тестом. (Анализ
-  определяет, нужен ли отдельный guard поверх существующей гарантии «advance только при чистом
-  exit + зелёный QG».)
-- **BR-6** — Документация и комментарии по конфигу тайм-аутов обновлены (паспорт изменения внутри
-  `config.py` + `.env.example`).
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — Обратная совместимость / нулевая регрессия.** Стамп модели аддитивен (колонка уже
-  существует, миграции нет). Дефолтный тайм-аут ролей, кроме `developer`/`reviewer`, не меняется;
-  при пустом override-конфиге поведение байт-в-байт прежнее.
-- **NFR-2 — never-raise / never-break.** Сбой стампа модели (ошибка БД) **не блокирует** launch
-  (та же `try/except`-изоляция, что у стампа эффорта). Малформный/невалидный timeout-конфиг →
-  откат на глобальный дефолт + WARNING, прогон не падает.
-- **NFR-3 — Неприкосновенность контрактов.** `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
-  machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
-  `coverage_status:`), схема БД — **не трогаются**.
-- **NFR-4 — Сохранение reaper-инварианта.** Любой поднятый бюджет `developer`/`reviewer` обязан
-  сохранять `reaper_max_running_s > max(резолвенный тайм-аут любого агента) + agent_kill_grace_seconds`
-  (Tier-3 backstop ORCH-065); иначе job-reaper может реапнуть **здоровый** долгоиграющий прогон до
-  срабатывания его собственного watchdog'а. Если новый бюджет нарушает неравенство —
-  `reaper_max_running_s` поднимается синхронно (решение архитектора).
-- **NFR-5 — Self-hosting безопасность.** Изменение не рестартит/не роняет прод-контейнер, не
-  трогает deploy-путь, безопасно для общего инстанса (enduro-trails не затронут негативно).
-- **NFR-6 — Наблюдаемость in-flight.** Модель становится видна в `GET /metrics`/`GET /queue`
-  (`db.get_running_agents`) **во время** прогона, а не только после завершения (побочное улучшение
-  launch-стампа).
-
-## 6. Допущения и ограничения
-
-- Тайм-аут — **глобальная per-agent** настройка (не repo-scoped): поднятие бюджета
-  `developer`/`reviewer` действует на все репо. Для enduro это благоприятно/нейтрально.
-- Колонка `agent_runs.model` уже существует и NULLABLE — повторная запись/COALESCE безопасны.
-- CLI не возвращает effort в result-JSON (причина launch-стампа эффорта ORCH-087); модель в JSON
-  возвращается, но только при успешном финале — отсюда необходимость launch-стампа модели.
-- Точные числовые значения новых бюджетов (`developer`/`reviewer`) и способ их конфигурации
-  (выделенные ключи vs `agent_timeout_overrides_json`) — решение архитектора/Owner в рамках FR-3;
-  BRD фиксирует только **способность + инвариант NFR-4 + тест**.
-- Salvage недоделанной работы — отдельная возможность, вне этой задачи.
-
-## 7. Критерии успеха
-
-Модель агента видна (не `null`) в трекере, status-комментариях и `/metrics` для ЛЮБОГО исхода
-прогона, включая timeout-kill; бюджеты `developer`/`reviewer` подняты и конфигурируемы без влияния
-на прочие роли и без нарушения reaper-инварианта; timeout-killed прогон не «протекает» в следующую
-стадию; всё покрыто тестами; конфиг задокументирован. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-
-- **R-1** — Поднятие бюджета выше `reaper_max_running_s − grace` → ложный reap здорового прогона
-  (NFR-4). Митигируется sanity-тестом конфига и/или синхронным поднятием `reaper_max_running_s`.
-- **R-2** — Постфактум-enrich затирает корректный launch-стамп при странном JSON. Митигируется
-  семантикой COALESCE (NULL не затирает) + тестом enrich-кейсов.
-- **R-3** — Гонка двух писателей `exit_code` (`_record_kill` = -9 и `_monitor_agent` = `proc.wait()`)
-  не должна влиять на телеметрию модели (модель — отдельная колонка). Подтверждается тестом FR-4.
-- **R-4** — Глобальность тайм-аута: поднятие для enduro-developer могло бы маскировать зависший
-  прогон. Митигируется тем, что Tier-3 backstop reaper'а сохраняется (NFR-4).
-
-Детали рисков и архитектурные трейд-оффы — `10-tech-risks.md` (заполняет архитектор).

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

@@ -1,145 +0,0 @@
----
-work_item: ORCH-109
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
-
-Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование/решения (выбор «выделенные config-ключи vs `agent_timeout_overrides_json`»,
-> точные числовые бюджеты, синхронная правка `reaper_max_running_s`) — задача архитектора (`06-adr`).
-
-## 1. Сводка изменения
-
-Две независимые, но связанные правки в подсистеме запуска агентов:
-
-1. **Launch-time стамп модели.** В `launcher._spawn` резолвенная `resolve_agent_model(...)` (уже
-   вычисляется на launch, строка ~559) записывается в `agent_runs.model` в той же DB-сессии, что и
-   стамп эффорта (ORCH-087, строки ~566–571). Постфактум-парс (`usage.record_usage`,
-   `model=COALESCE(?, model)`) сохраняется как **обогащение** и уже не затирает launch-значение
-   `NULL`'ом. Следствие: модель присутствует на строке прогона с момента запуска, переживает
-   timeout-kill и видна in-flight в `GET /metrics`/`GET /queue`.
-
-2. **Конфигурируемый поднятый wall-clock бюджет для `developer`/`reviewer`.** `_resolve_timeout(agent)`
-   должен возвращать поднятый бюджет для `developer` и `reviewer`, конфигурируемый и не затрагивающий
-   прочие роли; механизм покрыт тестом. Сохраняется never-break (малформный конфиг → глобальный
-   дефолт) и кросс-инвариант reaper (`reaper_max_running_s > max(timeout)+grace`).
-
-Плюс верификационные требования: телеметрия timeout-killed прогона (модель+эффорт не `null`) и
-guard анти-salvage (timeout-killed прогон не продвигает стадию).
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `src/agents/launcher.py` | изменить — стамп `model` в `_spawn` рядом с `effort` (≈ стр. 559–573); проверка `_resolve_timeout` обслуживает override `developer`/`reviewer` (≈ стр. 661–679) |
-| `src/config.py` | изменить — config для поднятого тайм-аута `developer`/`reviewer` (выделенные ключи и/или дефолт `agent_timeout_overrides_json`); обновить комментарии-паспорт (≈ стр. 115–126); проверить/при необходимости поднять `reaper_max_running_s` (≈ стр. 494–499) |
-| `src/usage.py` | проверить/зафиксировать тестом — `record_usage` (`model=COALESCE(?, model)`) НЕ затирает launch-стамп при `model=None` (≈ стр. 207–230); `_extract_model` (≈ стр. 95–118) |
-| `src/notifications.py` | проверить (правка, вероятно, не нужна) — `_stage_line` рендерит `· {model} · {effort}` из `agent_runs` для строки с `exit_code=-9` (≈ стр. 360–373, 498–542) |
-| `src/db.py` | НЕ менять схему — `agent_runs.model` TEXT уже есть; проверить, что `get_running_agents` (≈ стр. 1370–1405) отдаёт launch-стампнутую модель для running-job |
-| `src/stage_engine.py` | проверить — путь продвижения стадии не advance'ит прогон с `exit_code != 0` (guard FR-5); правка только если найден разрыв |
-| `.env.example` | обновить — задокументировать ключи тайм-аута `developer`/`reviewer` (BR-6) |
-| `tests/test_orch109_timeout_model.py` (новый) | создать — покрытие FR-1…FR-5 |
-| `CHANGELOG.md`, `CLAUDE.md` (паспорт), `docs/architecture/README.md` (модель/эффорт-секция) | обновить в том же PR (правило агентов №2) |
-
-## 3. Функциональные требования
-
-### FR-1 — Launch-time стамп модели (BR-1)
-В `launcher._spawn`, после `model = resolve_agent_model(agent, project_id)`, резолвенное значение
-записывается в `agent_runs.model` для текущего `run_id` **в момент launch**, по образцу стампа
-эффорта (ORCH-087):
-- Запись в той же открытой `conn`, что и стамп эффорта (допустимо объединить в один
-  `UPDATE agent_runs SET model=?, effort=? WHERE id=?` — решение реализации).
-- Пустой резолв (`model == ""`, CLI-дефолт без `--model`) → пишется `NULL` (как эффорт: `effort or None`),
-  чтобы суффикс модели в трекере корректно опускался.
-- **Инвариант:** значение `agent_runs.model` присутствует с момента launch и не зависит от исхода
-  прогона.
-- **never-raise (NFR-2):** сбой записи изолирован `try/except` + WARNING; launch продолжается.
-
-### FR-2 — Постфактум-enrich сохраняет launch-стамп (BR-2)
-`usage.record_usage` остаётся источником обогащения (токены/стоимость/модель из usage-JSON), но:
-- При `usage is None` или `usage.get("model") is None` (оборванный/малформный JSON) launch-стамп
-  модели **не затирается** (текущая семантика `model=COALESCE(?, model)` это уже обеспечивает —
-  требование зафиксировать тестом, не регрессировать).
-- При наличии непустой модели в JSON enrich **уточняет** значение (например, полный
-  provider-prefixed id или фактический fallback-model) — допустимая перезапись непустым на непустое.
-- Семантика парсинга `_extract_model` (приоритет `modelUsage` → top-level `model`) — без изменений.
-
-### FR-3 — Конфигурируемый поднятый тайм-аут `developer`/`reviewer` (BR-3)
-- `_resolve_timeout(agent)` возвращает поднятый бюджет для `agent in {"developer","reviewer"}`,
-  конфигурируемый, **детерминированный**, и **не затрагивающий** прочие роли (они продолжают
-  получать глобальный `agent_timeout_seconds`, если для них нет override).
-- Механизм: либо документированный дефолт `agent_timeout_overrides_json`, либо выделенные ключи
-  (например `agent_timeout_developer_s`/`agent_timeout_reviewer_s`) — выбор архитектора; контракт
-  FR-3 — резолв per-agent поднятого бюджета.
-- **never-break (NFR-2):** малформный/невалидный конфиг → откат на глобальный дефолт + WARNING
-  (поведение `_resolve_timeout` сохраняется).
-- **Кросс-инвариант (NFR-4):** итоговый `max(резолвенный тайм-аут)` + `agent_kill_grace_seconds`
-  обязан оставаться `< reaper_max_running_s`; при нарушении — синхронно поднять `reaper_max_running_s`.
-
-### FR-4 — Телеметрия timeout-killed прогона (BR-4)
-Для прогона с `exit_code != 0` без финального usage-JSON (timeout-kill, `_record_kill` стампит -9):
-- Строка стадии трекера (`notifications._stage_line`) рендерит `· {short_model} · {effort}` с
-  реальными значениями (модель **не** `null`), т.к. оба стампнуты на launch (FR-1 + ORCH-087).
-- `db.get_running_agents` (источник `GET /metrics`/`GET /queue`) отдаёт launch-стампнутую модель и
-  для **running**-job (in-flight видимость, NFR-6).
-- Изменения `notifications.py`, вероятно, не требуются (рендер уже читает `model`); требование —
-  верифицировать тестом, что при стампе на launch значение долетает.
-
-### FR-5 — Guard анти-salvage timeout-killed прогона (BR-5)
-- Timeout-killed прогон (`exit_code != 0`, в т.ч. -9/-15/143) `developer`/`reviewer` **не продвигает**
-  стадию (`development → review`, `review → testing`) автоматически.
-- Существующий контракт (advance только при чистом exit-коде + зелёный exit-гейт; иначе
-  `attempts<max → queued`, иначе `failed` + Telegram — `launcher._monitor_agent`/`queue_worker`/
-  `job_reaper`) реализует это структурно.
-- **Требование:** анализ подтверждает достаточность существующей гарантии; поведение фиксируется
-  **регресс-тестом**. Отдельный guard в коде добавляется **только если тест выявит разрыв**.
-- **salvage-режим НЕ вводится** (вне объёма) — задача гарантирует не-продвижение, не возобновление.
-
-### FR-6 — Документация конфига (BR-6)
-- Комментарий-паспорт в `config.py` (блок ORCH-7, строки ~115–126) расширяется описанием поднятых
-  бюджетов `developer`/`reviewer` и ссылкой на reaper-инвариант (NFR-4).
-- `.env.example` несёт соответствующие ключи с дефолтами = боевым значениям (канон ORCH-101).
-- Сквозная документация (`CLAUDE.md`, `docs/architecture/README.md` — таблица «модель/эффорт по
-  ролям») обновляется в том же PR.
-
-## 4. Изменения API
-
-Нет. Ни одного нового/изменённого endpoint'а. `GET /metrics` и `GET /queue` отдают тот же контракт
-(`schema_version: 1`) — поле `agents[].model` лишь **начинает заполняться** для running-job
-(аддитивное улучшение данных, не контракта; sidecar обязан толерировать, ORCH-099 NFR-6).
-
-## 5. Изменения схемы БД
-
-Нет. Колонка `agent_runs.model` (`TEXT`, NULLABLE) уже существует (`db._ensure_column`, инициализация
-`init_db`). Никаких `CREATE`/`ALTER`/новых таблиц. Меняется только **момент** и **частота** записи в
-существующую колонку (launch + опциональный постфактум-enrich).
-
-## 6. Требования к новым/изменённым QG checks
-
-Нет. `QG_CHECKS` / `check_*` / `_parse_*` / machine-verdict ключи — не трогаются. Задача целиком вне
-слоя Quality Gate (подсистема launch/телеметрия/конфиг). FR-5 опирается на **существующий**
-exit-code-контракт продвижения, не на новый гейт.
-
-## 7. Совместимость / регресс
-
-- **Обратная совместимость:** стамп модели аддитивен; при пустом timeout-override поведение
-  байт-в-байт прежнее (NFR-1). Никаких kill-switch не требуется — изменение не вводит новых ветвей
-  риска (стамп модели всегда безопасен; тайм-аут конфигурируем и fail-safe на глобальный дефолт).
-- **Область раската:** стамп модели — все репо/роли (безопасно). Поднятый тайм-аут — только
-  `developer`/`reviewer` (все репо, т.к. тайм-аут глобален per-agent); прочие роли неизменны.
-- **Обратимость:** вернуть тайм-аут — снять override-конфиг (откат на 1800s). Launch-стамп модели
-  отката не требует (чистое улучшение телеметрии).
-- **Кросс-каттинг (NFR-4):** при поднятии бюджета выше `reaper_max_running_s − grace` синхронно
-  поднять `reaper_max_running_s` (ORCH-065). Sanity-тест конфига стережёт инвариант.
-- **never-raise (NFR-2):** обе правки изолированы; сбой не роняет launch и не падает на старте при
-  плохом env.
-- **Self-hosting (NFR-5):** ни рестарта прода, ни изменения deploy-пути; общий инстанс безопасен.
-- **Полный регресс `tests/`** остаётся зелёным; coverage-гейт (ORCH-027) удовлетворён новым
-  тест-файлом (изменения в `src/` минимальны и покрыты).

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

@@ -1,139 +0,0 @@
----
-work_item: ORCH-109
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-109 — timeout budgets + launch-time model telemetry
-
-Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
-
----
-
-## AC-1 — Модель стампится в `agent_runs.model` в момент launch
-
-**Условие:** запуск любого агента через `launcher._spawn` записывает резолвенную модель в
-`agent_runs.model` строки прогона ДО завершения процесса.
-- **PASS:** после стампа на launch (`UPDATE agent_runs SET model=…`/объединённый с effort)
-  `SELECT model FROM agent_runs WHERE id=<run_id>` возвращает `resolve_agent_model(agent)` (непустую
-  модель для текущей конфигурации — `claude-opus-4-8`); при пустом резолве — `NULL`. Запись
-  происходит рядом со стампом эффорта (`launcher._spawn`).
-- **FAIL:** модель пишется только в `usage.record_usage` (постфактум); строка прогона имеет
-  `model IS NULL` до завершения; стамп не изолирован и роняет launch при ошибке БД.
-
----
-
-## AC-2 — Постфактум-enrich не затирает launch-стамп при оборванном JSON
-
-**Условие:** `usage.record_usage` с отсутствующей/`None`-моделью не обнуляет launch-стампнутую модель.
-- **PASS:** `record_usage(run_id, None)` и `record_usage(run_id, {... "model": None})` для строки с
-  launch-стампнутой моделью → `model` остаётся прежним непустым (семантика `COALESCE(?, model)`);
-  `record_usage(run_id, {... "model": "claude-opus-4-8"})` → модель проставлена/уточнена.
-- **FAIL:** оборванный/малформный JSON приводит к `model = NULL`; enrich затирает корректный
-  launch-стамп.
-
----
-
-## AC-3 — Тайм-аут `developer`/`reviewer` поднят и конфигурируем без влияния на прочие роли
-
-**Условие:** `launcher._resolve_timeout(agent)` возвращает поднятый бюджет для `developer`/`reviewer`
-и неизменный глобальный дефолт для остальных.
-- **PASS:** при сконфигурированном override `_resolve_timeout("developer")` и
-  `_resolve_timeout("reviewer")` возвращают поднятые значения; `_resolve_timeout("analyst")`,
-  `("architect")`, `("tester")`, `("deployer")` возвращают `settings.agent_timeout_seconds` (1800 по
-  умолчанию). Конфигурация описана в `config.py` и `.env.example`.
-- **FAIL:** изменён бюджет роли вне `{developer, reviewer}`; значение захардкожено; бюджет не
-  настраивается через config.
-
----
-
-## AC-4 — Малформный timeout-конфиг → безопасный откат (never-break)
-
-**Условие:** невалидный/малформный конфиг тайм-аутов не роняет прогон и не ломает старт.
-- **PASS:** при малформном `agent_timeout_overrides_json` (или невалидном выделенном ключе)
-  `_resolve_timeout(...)` возвращает глобальный дефолт + пишет WARNING; процесс не падает.
-- **FAIL:** исключение пробрасывается; прогон/старт падает на плохом env.
-
----
-
-## AC-5 — Reaper-инвариант сохранён
-
-**Условие:** `reaper_max_running_s > max(резолвенный тайм-аут любого агента) + agent_kill_grace_seconds`.
-- **PASS:** с применённой конфигурацией бюджетов sanity-тест подтверждает неравенство для всех ролей
-  (`developer`/`reviewer` включительно); при необходимости `reaper_max_running_s` поднят синхронно.
-- **FAIL:** поднятый бюджет `developer`/`reviewer` + grace ≥ `reaper_max_running_s` → job-reaper может
-  реапнуть здоровый долгий прогон.
-
----
-
-## AC-6 — Строка стадии трекера показывает модель+эффорт при timeout/kill
-
-**Условие:** для прогона с `exit_code = -9` (timeout-kill) с launch-стампнутыми model+effort строка
-стадии рендерит оба значения.
-- **PASS:** `notifications`-рендер строки стадии (`_stage_line`) для такого `agent_runs`-ряда содержит
-  ` · <short_model> · <effort>` (например `· opus-4-8 · xhigh`); модель **не** `null`/пустая.
-- **FAIL:** при `exit_code=-9` строка показывает стоимость без модели (суффикс модели опущен), т.к.
-  `model IS NULL`.
-
----
-
-## AC-7 — In-flight видимость модели в `/metrics` и `/queue`
-
-**Условие:** `db.get_running_agents` отдаёт модель для **running** job'а (до завершения прогона).
-- **PASS:** для running-job с launch-стампнутой моделью `get_running_agents()[i]["model"]` непуст;
-  `GET /metrics` `agents[].model` непуст для активного агента.
-- **FAIL:** `model` остаётся `null` для running-job до завершения прогона.
-
----
-
-## AC-8 — Timeout-killed прогон не продвигает стадию (анти-salvage)
-
-**Условие:** прогон `developer`/`reviewer` с `exit_code != 0` (timeout-kill) не вызывает переход
-`development → review` / `review → testing`.
-- **PASS:** регресс-тест подтверждает, что прогон с `exit_code = -9` не продвигает стадию
-  автоматически (следует retry/fail-пути; advance — только при чистом exit + зелёный exit-гейт).
-  Salvage-режим отсутствует.
-- **FAIL:** убитый по тайм-ауту прогон «протекает» в следующую стадию без явного решения; либо введён
-  неявный auto-salvage.
-
----
-
-## AC-9 — Неприкосновенность контрактов и схемы
-
-**Условие:** задача не трогает машину стадий, гейты и схему БД.
-- **PASS:** диффы НЕ содержат изменений `STAGE_TRANSITIONS`, реестра `QG_CHECKS`, `check_*`/`_parse_*`,
-  machine-verdict ключей, `CREATE TABLE`/`ALTER TABLE`. `agent_runs.model` используется как есть.
-- **FAIL:** любое из перечисленного изменено.
-
----
-
-## AC-10 — Документация и регресс
-
-**Условие:** конфиг задокументирован, полный регресс зелёный.
-- **PASS:** комментарий-паспорт в `config.py` (блок ORCH-7) и `.env.example` описывают бюджеты
-  `developer`/`reviewer`; `CHANGELOG.md`/`CLAUDE.md`/`docs/architecture/README.md` обновлены в том же
-  PR; `pytest tests/ -q` зелёный; новые тесты ORCH-109 проходят.
-- **FAIL:** конфиг не задокументирован; документация рассинхронизирована с кодом; регресс красный.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-2 |
-| AC-3 | BR-3 / FR-3 |
-| AC-4 | BR-3 / FR-3 / NFR-2 |
-| AC-5 | NFR-4 / FR-3 |
-| AC-6 | BR-4 / FR-4 |
-| AC-7 | BR-4 / FR-4 / NFR-6 |
-| AC-8 | BR-5 / FR-5 |
-| AC-9 | NFR-1 / NFR-3 / FR-5 |
-| AC-10 | BR-6 / FR-6 / NFR-1 |

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

@@ -1,94 +0,0 @@
-work_item: ORCH-109
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-14
-model_used: claude-opus-4-8
-title: "Timeout budgets + launch-time model telemetry для developer/reviewer"
-framework: pytest
-scope: >
-  Покрывает: launch-time стамп модели в agent_runs.model (FR-1), сохранение launch-стампа
-  постфактум-enrich'ем (FR-2), конфигурируемый поднятый тайм-аут developer/reviewer без влияния
-  на прочие роли (FR-3) + never-break на малформном конфиге, reaper-инвариант (NFR-4), видимость
-  модели+эффорта в строке трекера при timeout-kill (FR-4) и in-flight в get_running_agents (NFR-6),
-  guard анти-salvage — timeout-killed прогон не продвигает стадию (FR-5). Вне покрытия: model-routing,
-  salvage недоделанной работы, изменения STAGE_TRANSITIONS/QG_CHECKS/схемы (их и не должно быть).
-notes: >
-  Тесты детерминированы, без сети/LLM/subprocess Claude CLI: используют временную SQLite-БД и
-  синтетические agent_runs-ряды; настройки подменяются через monkeypatch/override settings.
-  Полный регресс tests/ должен оставаться зелёным; новый файл tests/test_orch109_timeout_model.py.
-  Любой найденный разрыв в FR-5 закрывается guard'ом + тестом; если разрыва нет — TC-08 фиксирует
-  существующую гарантию как анти-регресс.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "_resolve_timeout('developer') и ('reviewer') возвращают поднятый сконфигурированный бюджет"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "_resolve_timeout для analyst/architect/tester/deployer возвращает глобальный agent_timeout_seconds (1800) — прочие роли не затронуты"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Малформный/невалидный timeout-конфиг -> _resolve_timeout откатывается на глобальный дефолт + WARNING, без исключения (never-break)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-04
-    type: integration
-    description: "Launch стампит agent_runs.model: после стамп-блока _spawn строка прогона имеет model == resolve_agent_model(agent) (непустую), рядом с effort"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Стамп модели изолирован: сбой записи (битый conn) не пробрасывает исключение из launch-пути (never-raise, NFR-2)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "record_usage(run_id, None) и record_usage с model=None НЕ затирают launch-стампнутую модель (COALESCE preserve, FR-2)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "record_usage с непустой model в usage-JSON уточняет/проставляет agent_runs.model (enrich по-прежнему работает)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Sanity reaper-инварианта: reaper_max_running_s > max(резолвенный тайм-аут всех ролей) + agent_kill_grace_seconds (NFR-4)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-09
-    type: integration
-    description: "Строка стадии трекера (_stage_line) для agent_runs с exit_code=-9 и launch-стампнутыми model+effort рендерит ' · <short_model> · <effort>' (model не null)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "get_running_agents отдаёт непустую model для running-job с launch-стампнутой моделью (in-flight видимость /metrics /queue, NFR-6)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "Анти-salvage: прогон developer/reviewer с exit_code=-9 не продвигает стадию (development->review / review->testing) автоматически; следует retry/fail-пути"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: "Анти-регресс контрактов: STAGE_TRANSITIONS/QG_CHECKS/check_* и схема agent_runs не изменены (модель пишется в существующую колонку, миграции нет)"
-    module: tests/test_orch109_timeout_model.py
-    expected: PASS

docs/work-items/ORCH-109/06-adr/ADR-001-agent-timeout-budgets-and-launch-model-stamp.md

@@ -1,221 +0,0 @@
----
-work_item: ORCH-109
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# ADR-001: Поднятые wall-clock бюджеты developer/reviewer + launch-time стамп модели
-
-Work Item: **ORCH-109** — timeout budgets + launch-time model telemetry для developer/reviewer
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`**
-(решение кросс-каттинговое: меняет два глобальных per-agent инварианта подсистемы запуска —
-бюджеты тайм-аутов всех репо и потолок Tier-3 reaper'а ORCH-065).
-
-## Статус
-Proposed   <!-- Proposed | Accepted | Superseded by ADR-… -->
-
-## Контекст
-
-Инцидент **ORCH-104** (runs 658/659/660) вскрыл два независимых дефекта подсистемы запуска агентов
-(`src/agents/launcher.py`), верифицированных по коду:
-
-- **Дефект A — единый тайм-аут для всех ролей.** `_resolve_timeout(agent)` (launcher.py ≈661–679)
-  возвращает `settings.agent_timeout_seconds = 1800` (config.py:124) для **всех** ролей, если в
-  `agent_timeout_overrides_json` нет записи (в проде он пуст: `""`, config.py:126). Тяжёлые роли
-  `developer` (effort `xhigh`, кодирующая) и `reviewer` (effort `high`, читает диф + пишет ревью)
-  **честно** упираются в 1800s и убиваются watchdog'ом (`_watchdog → stop_process`, exit_code=-9
-  через `_record_kill`, launcher.py:778–786). Механические роли (`tester`/`deployer`, effort
-  `medium`) в этот бюджет укладываются.
-- **Дефект B — потеря модели в телеметрии при обрыве.** `agent_runs.model` пишется только
-  постфактум — из финального usage-JSON в `usage.record_usage` (`model=COALESCE(?, model)`,
-  usage.py:217). Убитый по тайм-ауту прогон не успевает эмитить финальный JSON → `_extract_model`
-  даёт `None` → модель остаётся `NULL` ровно тогда, когда она критична для разбора инцидента.
-  При этом **эффорт уже стампится на launch** (ORCH-087, launcher.py:566–571, `UPDATE agent_runs
-  SET effort=? WHERE id=?`), потому что CLI его в result-JSON не отдаёт; модель в той же точке
-  **резолвится** (`model = resolve_agent_model(...)`, launcher.py:559), но в БД на launch **не
-  пишется**.
-
-Установленные факты (по коду, не изобретены):
-- Колонка `agent_runs.model TEXT` (NULLABLE) уже существует (`db.py:111`, `_ensure_column`) —
-  **миграции нет**.
-- `record_usage` уже использует `model=COALESCE(?, model)` → `None` не затирает ранее проставленное
-  значение (usage.py:217). Не хватает только записи на launch.
-- `db.get_running_agents()` уже отдаёт `r.model AS model` (`db.py` ≈1370–1405) — running-job увидит
-  модель **сразу** после launch-стампа, без правки SELECT.
-- `notifications._stage_line` рендерит `· {model} · {effort}` из строки `agent_runs` — увидит
-  launch-стампнутую модель даже для `exit_code=-9`, без правки.
-- Продвижение стадии гейтится `if exit_code == 0: self._try_advance_stage(...)` (launcher.py:951–952);
-  иначе → `_finalize_job` (launcher.py:957) → retry/fail. Timeout-kill (-9) **структурно** не
-  продвигает стадию.
-- Кросс-инвариант reaper (ORCH-065): `reaper_max_running_s = 3600` (config.py:497) c зафиксированным
-  правилом «MUST be > max agent_timeout + grace» (config.py:480–482; `job_reaper.py:43,228`).
-  Сейчас `3600 > 1800 + 20 = 1820` ✓. **Любое поднятие бюджета обязано пересчитать это неравенство.**
-- Sidecar-watchdog (`watchdog/`, ORCH-100) — **наблюдатель**, процессы **не убивает**; сигнал
-  `agent_hung` (runtime > `agent_hung_min`=20м **И** cpu < 1%) — только Telegram-алерт. Кому
-  принадлежит kill — исключительно in-process `launcher._watchdog`.
-
-Почему «как есть» не годится: единый бюджет 1800 системно убивает здоровые тяжёлые прогоны при
-пакетном автономном прогоне (эпик ORCH-088), а телеметрия теряет модель именно на этих обрывах.
-
-## Решение
-
-### Сводка
-Две аддитивные, изолированные правки подсистемы запуска, **без** касания
-`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы БД:
-(1) стамп резолвенной модели в `agent_runs.model` **в момент launch** рядом со стампом эффорта;
-(2) **выделенные типизированные config-ключи** поднятого wall-clock бюджета для `developer`/`reviewer`
-с синхронным поднятием `reaper_max_running_s` (сохранение инварианта ORCH-065).
-FR-5 (анти-salvage) и FR-4/NFR-6 (видимость при kill / in-flight) — **структурно уже выполнены**
-существующим кодом; ORCH-109 добавляет к ним регресс-тесты, а не новые ветви.
-
-### D1 — Launch-time стамп модели (FR-1, AC-1)
-В `launcher._spawn`, в той же открытой `conn`, что и стамп эффорта (ORCH-087), резолвенная
-`model = resolve_agent_model(agent, project_id)` (уже вычислена, launcher.py:559) записывается в
-`agent_runs.model` текущего `run_id`. Рекомендуется **объединить** в один оператор:
-`UPDATE agent_runs SET model=?, effort=? WHERE id=?` с параметрами `(model or None, effort or None, run_id)`
-(один commit вместо двух; ровно та же `try/except`-изоляция, что у эффорта).
-- Пустой резолв (`model == ""`, CLI-дефолт без `--model`) → пишется `NULL` (симметрично `effort or None`)
-  → суффикс модели в трекере корректно опускается.
-- **Инвариант:** значение присутствует с момента launch и не зависит от исхода прогона (переживает
-  timeout-kill, виден in-flight).
-- **never-raise (NFR-2):** сбой записи изолирован существующим `try/except` + WARNING; launch
-  продолжается (`model_flag` строится из локальной `model`, а не из БД — стамп лишь телеметрия).
-
-### D2 — Постфактум-enrich сохраняет launch-стамп (FR-2, AC-2) — без кода
-`usage.record_usage` остаётся источником обогащения (токены/стоимость/модель из usage-JSON), но
-**перестаёт быть единственным источником истины** о модели. Семантика `model=COALESCE(?, model)`
-(usage.py:217) **уже** гарантирует: `usage=None` или `usage["model"]=None` → launch-стамп НЕ
-затирается; непустая модель из JSON — допустимо уточняет (полный provider-prefixed id / фактический
-fallback). **Код не меняется**; требование — зафиксировать поведение тестом (анти-регресс), не
-сломать его будущими правками `record_usage`.
-
-### D3 — Конфигурируемый поднятый бюджет: выделенные типизированные ключи (FR-3, AC-3/AC-4)
-Вводятся два **выделенных** config-ключа (по образцу `agent_model_<role>`/`agent_effort_<role>`,
-config.py:133–138/147):
-
-```python
-agent_timeout_developer_s: int = 3600   # env ORCH_AGENT_TIMEOUT_DEVELOPER_S
-agent_timeout_reviewer_s:  int = 3000   # env ORCH_AGENT_TIMEOUT_REVIEWER_S
-```
-
-`_resolve_timeout(agent)` получает детерминированную лестницу приоритетов (от высшего):
-1. **`agent_timeout_overrides_json[agent]`** — существующий операторский escape-hatch; сохраняется
-   как высший приоритет (полная BC: сконфигурированный JSON по-прежнему выигрывает для ЛЮБОЙ роли).
-2. **выделенный ключ роли** — `developer → agent_timeout_developer_s`,
-   `reviewer → agent_timeout_reviewer_s`.
-3. **`settings.agent_timeout_seconds`** (1800) — для всех прочих ролей (`analyst`/`architect`/
-   `tester`/`deployer`) — **байт-в-байт прежнее значение**.
-
-**never-break (NFR-2, AC-4):** малформный `agent_timeout_overrides_json` → уже игнорируется + WARNING
-(launcher.py:677–678). Для выделенных ключей добавляется такой же защитный гард: если резолвенное
-значение не положительный int (абсурд/0/отрицательное) → откат на `agent_timeout_seconds` + WARNING
-(зеркало защитной валидации disk_monitor, ORCH-063 D7). Прогон/старт не падает.
-
-**Почему выделенные ключи, а не дефолт `agent_timeout_overrides_json`:** см. «Альтернативы».
-
-### D4 — Числовые бюджеты + синхронное поднятие reaper (FR-3/NFR-4, AC-5)
-| Роль | Бюджет | Обоснование |
-|------|--------|-------------|
-| `developer` | **3600s (60м)** | бутылочное горло (xhigh, кодирующая); удвоение 1800→3600 — естественная разрядка для тяжёлых задач |
-| `reviewer` | **3000s (50м)** | асимметрично легче developer, но тяжелее механических ролей; большой диф + high-reasoning |
-| прочие | 1800s (без изменений) | механические/думающие роли укладываются в дефолт |
-
-`reaper_max_running_s`: **3600 → 5400 (90м)** синхронно (config.py:497).
-
-**Проверка инварианта ORCH-065** `reaper_max_running_s > max(резолвенный тайм-аут) + agent_kill_grace_seconds`:
-`5400 > 3600 + 20 = 3620` ✓ (запас **1780s** — покрывает и окно финализации монитора:
-commit/push/PR/usage-comments, Tier-2 `reaper_finalize_grace_s`=300). Дополнительно `5400 < `
-sidecar `stage_stuck_s` (7200s/120м) → легитимный длинный developer-прогон не порождает ложный
-`stage_stuck`-алерт.
-
-Бюджеты — **глобальные per-agent** (не repo-scoped): действуют на все репо, включая enduro-trails.
-Это благоприятно/нейтрально (enduro-developer тоже получает воздух; Tier-3 backstop reaper'а
-сохраняется как страховка от реально зависшего прогона — R-4).
-
-### D5 — FR-5 анти-salvage: регресс-тест, без нового кода (AC-8)
-Гарантия «timeout-killed прогон не продвигает стадию» **структурна**: `_try_advance_stage` вызывается
-только под `if exit_code == 0` (launcher.py:951–952); kill (-9/-15/143) → `_finalize_job` →
-`_finalize_transient`/`_finalize_permanent` (retry до `MAX_DEVELOPER_RETRIES`, иначе `failed` +
-Telegram). **Новый guard в коде НЕ вводится** (не плодить лишние ветви риска) — добавляется
-регресс-тест, фиксирующий, что прогон с `exit_code=-9` не вызывает `advance_stage`. salvage-режим
-вне объёма.
-
-### D6 — Документация и канон дефолтов (FR-6, AC-10)
-- `config.py` блок ORCH-7 (≈115–126): паспорт-комментарий расширяется описанием выделенных бюджетов
-  developer/reviewer + явной ссылкой на reaper-инвариант (NFR-4) с числами `5400 > 3620`.
-- `.env.example`: **сейчас агент-тайм-аут ключей нет вовсе** (`ORCH_AGENT_TIMEOUT_SECONDS`/
-  `_KILL_GRACE_SECONDS`/`_OVERRIDES_JSON` отсутствуют) → добавляется новый блок «Agent timeout
-  (ORCH-7/ORCH-109)» с пятью ключами (`SECONDS`/`KILL_GRACE_SECONDS`/`OVERRIDES_JSON`/
-  `DEVELOPER_S`/`REVIEWER_S`) **+ обновляется `ORCH_REAPER_MAX_RUNNING_S=3600 → 5400`** (line 377).
-  Дефолты = боевым значениям (канон ORCH-101): пустой `.env` воспроизводит прод-поведение, в т.ч.
-  поднятые бюджеты.
-- Архитектурная golden source (этот PR, авторство architect): `docs/architecture/README.md`
-  (бюллет Agent Launcher), `docs/architecture/internals.md` (стр. 96/262 — «timeout 30 мин»
-  расхардкоживается в per-role). Паспорт `CLAUDE.md` + `CHANGELOG.md` — обновляет developer в том
-  же PR (правило агентов №2).
-
-### Согласование BR-3 ↔ NFR-1 (важный нюанс)
-NFR-1 требует «при пустом override-конфиге поведение байт-в-байт прежнее», а BR-3 требует «бюджеты
-developer/reviewer подняты». Разрешение по канону **ORCH-101** («дефолт каждого параметра = боевому
-значению; пустой `.env` ⇒ боевое поведение»): выделенные ключи **дефолтят на поднятый прод-бюджет**,
-поэтому пустой `.env` даёт уже исправленное (поднятое) поведение для developer/reviewer — это и есть
-намеренная боевая конфигурация. «Байт-в-байт прежнее» строго применяется к **прочим ролям**
-(`analyst`/`architect`/`tester`/`deployer` остаются на 1800) — что и есть суть BR-3 (поднять ТОЛЬКО
-две роли). Зафиксировано явно, чтобы reviewer не прочитал поднятый дефолт как нарушение NFR-1.
-
-## Альтернативы
-- **Дефолт `agent_timeout_overrides_json = {"developer":3600,"reviewer":3000}`** (вместо выделенных
-  ключей) — отвергнуто: (1) ломает канон ORCH-101 «пустой = боевой» неочевидным непустым JSON-строковым
-  дефолтом; (2) JSON-строка хрупка (парс, экранирование) против типизированного int; (3) нельзя
-  переопределить одну роль одной env-переменной; (4) расходится с конвенцией per-agent скаляров
-  (`agent_model_<role>`/`agent_effort_<role>`). Выделенные ключи дают типобезопасность, индивидуальный
-  env-override и сохраняют JSON как чистый escape-hatch.
-- **Бюджет developer/reviewer ≤ 3580 без поднятия reaper** (например 3000/2700) — отвергнуто как
-  доминирующее, но рассмотрено: держит `reaper_max_running_s=3600` нетронутым (меньший blast-radius),
-  но искусственно урезает самую тяжёлую роль ради статичности backstop-числа — оптимизация не той
-  переменной. NFR-4 **явно делегирует** архитектору синхронное поднятие reaper. Оставлено как
-  операторский запасной путь: всё env-override'имо, Owner может занизить бюджеты и вернуть reaper к
-  3600 одной правкой `.env` (см. «Откат»).
-- **Новый guard-leaf анти-salvage** (FR-5) — отвергнуто: продвижение уже гейтится exit-кодом
-  (launcher.py:951); новый код = лишняя ветвь риска. Достаточно регресс-теста (D5).
-- **Repo-scoped бюджеты (`*_repos`)** — отвергнуто: тайм-аут — свойство launch, не гейт-решение;
-  глобальность благоприятна enduro и проще; гейт-паттерн `applies(repo)` тут неуместен.
-- **Стамп модели через постфактум-парс лога на kill** — отвергнуто: модель известна на launch
-  детерминированно (`resolve_agent_model`); парсить оборванный лог — хрупко и поздно.
-
-## Последствия
-- **+** Модель видна (не `null`) в трекере, status-комментариях, `/metrics`/`/queue` для **любого**
-  исхода, включая timeout-kill — ключевой контекст инцидента доступен в момент сбоя (BR-1/BR-4/NFR-6).
-- **+** Тяжёлые роли получают реальный бюджет (developer ×2, reviewer +67%) → меньше ложных
-  timeout-kill на сложных задачах при автономном прогоне (ORCH-088).
-- **+** Аддитивно/обратимо: ни схемы, ни гейтов, ни новых компонентов; `agent_runs.model` уже есть.
-- **−** `reaper_max_running_s` 60→90м: реально зависший прогон (двойной отказ — watchdog-поток **и**
-  pid-liveness) держится Tier-3 backstop'ом на 30м дольше. Митигейшн: Tier-1 (pid) и Tier-2
-  (finalize-grace) ловят типовые случаи быстрее; watchdog убивает в ≤3600s; double-fault редок.
-- **−** Глобальность бюджета поднимает и enduro-роли. Митигейшн: Tier-3 reaper сохранён (R-4);
-  поднятие благоприятно для качества enduro-прогонов.
-- **−** Sidecar `agent_hung_min`=20м теперь заметно ниже бюджета developer (60м) → возможны
-  Telegram-алерты `agent_hung` для здоровых длинных прогонов с low-CPU фазами. Митигейшн: сигнал —
-  **alert-only** (не убивает) и конъюнкция с `cpu<1%` гасит большинство ложных; тюнинг
-  `WATCHDOG_AGENT_HUNG_MIN` — вне объёма (отдельный sidecar-конфиг, alert-only). Детали — `10-tech-risks.md` TR-5.
-- **Откат:** занизить бюджеты — снять/уменьшить `ORCH_AGENT_TIMEOUT_DEVELOPER_S`/`_REVIEWER_S`
-  (или выставить = 1800) и вернуть `ORCH_REAPER_MAX_RUNNING_S=3600`; launch-стамп модели отката не
-  требует (чистое улучшение телеметрии, COALESCE безопасен). Kill-switch не вводится — изменение не
-  добавляет рисковых ветвей (стамп всегда безопасен; тайм-аут fail-safe на глобальный дефолт).
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-109/01-brd.md`
-- TRZ: `docs/work-items/ORCH-109/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-109/03-acceptance-criteria.md`
-- Tech-risks: `docs/work-items/ORCH-109/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md`
-- Сверено по коду: `src/agents/launcher.py` (`_spawn` 559–571, `_resolve_timeout` 661–679,
-  `_watchdog`/`stop_process`/`_record_kill` 681–786, advance-гейт 951–952), `src/usage.py`
-  (`_extract_model` 95–118, `record_usage` 207–230), `src/config.py` (115–126, 480–497),
-  `src/db.py` (`agent_runs.model` 111, `get_running_agents` ≈1370–1405), `src/job_reaper.py`
-  (43, 228), `watchdog/config.py`/`watchdog/signals.py` (agent_hung/stage_stuck)
-- Маркер-инвариант: ORCH-065 (reaper Tier-3), ORCH-087 (стамп эффорта), ORCH-101 (канон дефолтов)

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

@@ -1,42 +0,0 @@
----
-work_item: ORCH-109
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-14
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-109 — timeout budgets + launch-time model telemetry
-
-Work Item: **ORCH-109** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | Поднятый бюджет developer/reviewer + grace ≥ `reaper_max_running_s` → job-reaper реапает **здоровый** долгий прогон до его watchdog'а (нарушение инварианта ORCH-065) | Низ. | Выс. | reaper синхронно поднят 3600→5400; sanity-тест проверяет `reaper_max_running_s > max(timeout)+grace` для всех ролей (`5400 > 3620`, запас 1780s); число живёт в `config.py` + `.env.example` рядом с инвариантом-комментарием (ADR D4/AC-5) |
-| TR-2 | Постфактум-enrich (`record_usage`) затирает корректный launch-стамп при странном/оборванном JSON (`model=None`) | Низ. | Сред. | Семантика `model=COALESCE(?, model)` (usage.py:217) уже сохраняет launch-значение; зафиксировано регресс-тестом (AC-2); `record_usage` не правится |
-| TR-3 | Гонка двух писателей `exit_code` (`_record_kill`=-9 и `_monitor_agent`=`proc.wait()`) искажает телеметрию модели | Низ. | Низ. | Модель — отдельная колонка, стампится один раз на launch до обоих писателей exit_code; они трогают только `exit_code`/`finished_at`. Подтверждается тестом (AC-1/AC-6) |
-| TR-4 | Глобальность бюджета: поднятый developer-тайм-аут для **enduro** маскирует реально зависший прогон | Низ. | Сред. | Tier-3 backstop reaper'а (`reaper_max_running_s`) сохранён как абсолютный потолок; watchdog по-прежнему убивает в ≤ бюджета; бюджет лишь повышен, не снят |
-| TR-5 | Sidecar `agent_hung_min`=20м заметно ниже бюджета developer (60м) → Telegram-алерты `agent_hung` для здоровых длинных прогонов | Сред. | Низ. | Сигнал **alert-only** (sidecar — наблюдатель, не убивает, ORCH-100); конъюнкция с `cpu<1%` гасит активный прогон; тюнинг `WATCHDOG_AGENT_HUNG_MIN` — вне объёма (отдельный sidecar-конфиг). Бюджет 5400s < `stage_stuck_s`=7200s → `stage_stuck` не ложит |
-| TR-6 | Сбой записи launch-стампа модели (ошибка БД) роняет launch | Низ. | Выс. | Стамп в существующем `try/except` ORCH-087 + WARNING (never-raise, NFR-2); `model_flag` строится из локальной переменной, не из БД → launch не зависит от стампа (ADR D1) |
-| TR-7 | Малформный/невалидный timeout-конфиг (битый JSON, нечисловой/отрицательный ключ) роняет прогон или старт | Низ. | Сред. | Малформный JSON → игнор + WARNING (существующее, launcher.py:677); выделенный ключ вне диапазона → откат на глобальный дефолт + WARNING (защитная валидация по образцу ORCH-063 D7); pydantic ловит нечисловой env на старте (AC-4) |
-| TR-8 | Регресс прочих ролей: правка `_resolve_timeout` случайно меняет бюджет `analyst`/`architect`/`tester`/`deployer` | Низ. | Сред. | Лестница приоритетов: dev/reviewer — только по точному имени роли; прочие падают на `agent_timeout_seconds` (1800) без изменений; покрыто тестом per-role (AC-3) |
-| TR-9 | Доп. риск контрактов: правка случайно задевает `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схему | Низ. | Выс. | Задача целиком вне слоя гейтов; диф-проверка AC-9; колонка `agent_runs.model` уже есть — ни одного `CREATE/ALTER` |
-
-## Сводный вывод
-
-Доминирующий класс — **конфигурационные инварианты подсистемы запуска** (TR-1/TR-7/TR-8): все
-снимаются детерминированной лестницей `_resolve_timeout`, защитной валидацией (never-break) и
-sanity-тестом reaper-неравенства. Остаточный риск для прод-конвейера (self-hosting) — **низкий**:
-изменение аддитивно, обратимо через `.env`, не трогает гейты/схему/деплой-путь и не рестартит
-прод-контейнер (NFR-5). Единственный наблюдаемый побочный эффект — возможный рост alert-only
-`agent_hung`-нотификаций sidecar (TR-5), не влияющий на конвейер.
-
-**Эскалация:** не требуется на уровне `arch:major-change` (нет новой стадии/компонента/смены БД), но
-решение **кросс-каттинговое** (меняет два глобальных per-agent инварианта всех репо + потолок Tier-3
-reaper'а) → зарегистрировано сквозным `docs/architecture/adr/adr-0040-*`. Возврат в анализ не нужен —
-ТЗ удовлетворяется без нарушения принципов архитектуры.

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

@@ -1,119 +0,0 @@
----
-verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
-work_item: ORCH-109
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-14
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-109
-version: 3
----
-
-# Review ORCH-109
-
-## Summary
-
-Две аддитивные изолированные правки подсистемы запуска (`launcher`) — **launch-стамп модели** в
-`agent_runs.model` (D1/FR-1) и **поднятые per-role wall-clock бюджеты** developer/reviewer с
-синхронным поднятием reaper (D3/D4/FR-3) — реализованы **корректно и точно по ADR**. Контракты
-неприкосновенны: в `src/` изменены **только** `launcher.py` и `config.py`; ни одной строки
-`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / `_parse_*` / machine-verdict / `CREATE TABLE` /
-`ALTER TABLE` в диффе нет (AC-9 верифицирован grep'ом по диффу). Зафиксированные маркер-инварианты
-**ORCH-087** (стамп эффорта объединён в один `UPDATE`, `(effort or None)` сохранён) и **ORCH-065**
-(reaper поднят синхронно `3600→5400`, `5400 > 3600+20=3620`) — целы. Покрытие исчерпывающее: новый
-`tests/test_orch109_timeout_model.py` (TC-01…TC-12, детерминированный, без сети/CLI), обновлены
-`tests/test_config.py` (reaper-дефолт 5400) и `tests/test_launcher.py` (лестница `_resolve_timeout`).
-
-Независимая верификация reviewer'а: целевые тесты зелёные — `test_orch109_timeout_model.py` +
-`test_config.py` + `test_launcher.py` = **75 passed**; зависимые подсистемы FR-2/FR-4
-(`usage`/`notifications`/`tracker`) = **231 passed**. Полный регресс зелёный (см. `13-test-report.md`).
-Открытых findings P0/P1/P2 нет → вердикт **APPROVED**.
-
-## Оси проверки
-
-1. **Соответствие ТЗ (02-trz / 03-acceptance):** FR-1…FR-6 реализованы; AC-1…AC-10 покрыты тестами
-   TC-01…TC-12 буквально по матрице AC↔FR.
-   - FR-1/AC-1 (TC-04): `_spawn` пишет резолвенную модель в `agent_runs.model` объединённым
-     `UPDATE agent_runs SET model=?, effort=? WHERE id=?` с `(model or None, effort or None, run_id)`
-     рядом со стампом эффорта; пустой резолв → `NULL`; стамп = `resolve_agent_model` (single source).
-   - FR-2/AC-2 (TC-06/07): `usage.record_usage` использует `model=COALESCE(?, model)` (сверено по
-     `src/usage.py`) — `usage=None`/`model=None` не затирает launch-стамп; непустая модель уточняет.
-     Кода `usage.py` PR не трогает (корректно — семантика уже верна), зафиксировано регресс-тестом.
-   - FR-3/AC-3 (TC-01/02): `_resolve_timeout` отдаёт поднятый бюджет developer/reviewer и неизменный
-     1800 прочим ролям (analyst/architect/tester/deployer/unknown/None); бюджеты конфигурируемы.
-   - FR-3/AC-4 (TC-03): малформный `agent_timeout_overrides_json` и непозитивный/нечисловой
-     выделенный ключ `[0,-5,"abc"]` → откат на глобальный дефолт + WARNING, never-break.
-   - NFR-4/AC-5 (TC-08): инвариант reaper подтверждён на shipped-дефолтах (`5400 > 3600+20`).
-   - FR-4/AC-6 (TC-09): строка стадии рендерит `· opus-4-8 · xhigh` для `exit_code=-9`; присутствует
-     negative-guard (немаркированный -9 → суффикс опущен).
-   - FR-4/NFR-6/AC-7 (TC-10): `get_running_agents` отдаёт модель для running-job (in-flight).
-   - FR-5/AC-8 (TC-11): timeout-killed прогон developer/reviewer не вызывает `_try_advance_stage`
-     (роутится в `_finalize_job`); присутствует позитивный контроль (clean exit → advance).
-   - AC-9 (TC-12) + AC-10: контракты/схема нетронуты; документация и регресс зелёные.
-
-2. **Соответствие ADR (06-adr ADR-001 + сквозной adr-0040):** D1–D6 реализованы дословно. Лестница
-   `_resolve_timeout` (overrides_json → выделенный ключ роли → глобальный дефолт), выделенные ключи
-   `agent_timeout_developer_s=3600`/`agent_timeout_reviewer_s=3000`, `reaper_max_running_s` 3600→5400.
-   **Трассировка маркеров (TRACEABILITY):** правка касается блоков с маркерами ORCH-087 (стамп
-   эффорта) и ORCH-065 (reaper Tier-3) — оба зафиксированных инварианта сверены с их ADR и не
-   сломаны (эффорт-стамп сохранён в объединённом `UPDATE`; reaper-неравенство пересчитано и поднято
-   синхронно). Нарушений глобальных ADR нет.
-
-3. **Качество кода:** never-raise сохранён (`try/except` + WARNING вокруг стамп-`UPDATE`;
-   непозитивный/нечисловой выделенный ключ → откат + WARNING). Докстринг `_resolve_timeout` и
-   паспорт-комментарии `config.py` точны. Тесты содержательны: изоляция стамп-сбоя (TC-05,
-   `_RaisingConn` бьёт только по launch-`UPDATE`), параметризация `[0,-5,"abc"]`, негативный guard
-   (TC-09b), позитивный контроль (TC-11c). **Регресс-тест-фиксатор инцидента ORCH-104** присутствует
-   (ORCH-019 BR-4 удовлетворён) — весь тест-файл пинит дефектное и исправленное поведение.
-
-4. **Документация (приоритетная ось):** `src/` изменён → документация обновлена в том же PR
-   (golden source синхронизирован с кодом):
-   `CHANGELOG.md` / `CLAUDE.md` (паспорт) / `docs/architecture/README.md` (бюллет Agent Launcher +
-   ссылка на adr-0040) / `docs/architecture/internals.md` (оба упоминания «30 мин» → per-role) /
-   `README.md` front-page «### Watchdog» (per-role бюджеты + Tier-3 backstop 90м) / `.env.example`
-   (5 ключей agent-timeout + `ORCH_REAPER_MAX_RUNNING_S`=5400) / `config.py`-паспорт / детальный
-   ADR-001 + сквозной adr-0040. Обзорная витрина `docs/overview/` правки не требует — упоминания
-   watchdog концептуальны (sidecar-наблюдатель, «следит за процессом»), конкретного числа тайм-аута
-   витрина не несёт → устаревшего факта не возникает (ORCH-011/079 — нет finding). PR не закрывает
-   пункт `README.md` «Известные ограничения».
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет)
-
-### P2 — Should fix
-- (нет)
-
-### P3 — Nice-to-have
-- [ ] ADR-001 (`status: proposed`) и adr-0040 (`Proposed`) на merge разумно перевести в `Accepted`
-  (косметика статуса ADR; на гейты/код не влияет, не блокер).
-
-## Документация
-
-**Обновлено в этом PR (golden source синхронизирован с кодом):**
-- `CHANGELOG.md` — детальная запись ORCH-109 (`fix`, D1/D3/D4, FR-4/FR-5 структурно). ✅
-- `CLAUDE.md` — паспорт (блок «Стек», абзац launcher). ✅
-- `docs/architecture/README.md` — бюллет Agent Launcher (ссылка на adr-0040). ✅
-- `docs/architecture/internals.md` — watchdog «30 мин» → per-role (стр. ~96 и ~262). ✅
-- `README.md` — front-page «### Watchdog» (стр. ~295) → per-role бюджеты + Tier-3 backstop. ✅
-- `.env.example` — новый блок agent-timeout (5 ключей) + `ORCH_REAPER_MAX_RUNNING_S` 3600→5400. ✅
-- `src/config.py` — паспорт-комментарий ORCH-7/ORCH-109 + reaper-инвариант. ✅
-- ADR — `docs/work-items/ORCH-109/06-adr/ADR-001-…` (детальный) + `docs/architecture/adr/adr-0040-…`
-  (сквозной). ✅
-
-**Обзорная витрина `docs/overview/` (ORCH-011/ORCH-079):** правки не требует — упоминания watchdog
-концептуальны, конкретного числа тайм-аута витрина не несёт, поэтому устаревшего факта не возникает.
-
-**Прочее (не findings):**
-- AC-9 верифицирован по диффу: в `src/` изменены только `launcher.py` и `config.py`; ни одной строки
-  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/`CREATE TABLE`/`ALTER TABLE`.
-- Целевой регресс reviewer'а зелёный: 75 (ORCH-109/config/launcher) + 231 (usage/notifications/
-  tracker) passed; полный регресс — `13-test-report.md`.
-</content>
-</invoke>

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

@@ -1,82 +0,0 @@
----
-result: PASS
-work_item: ORCH-109
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-14
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-109
----
-
-# Test Report — ORCH-109 — timeout budgets + launch-time model telemetry для developer/reviewer
-
-> Машинный вердикт читается ТОЛЬКО из frontmatter. Канонический ключ — `result:`.
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Дата: 2026-06-14
-- Worktree: `feature/ORCH-109-orch-timeout-budgets-launch-ti`
-  (`/repos/_wt/orchestrator/feature_ORCH-109-orch-timeout-budgets-launch-ti/`)
-
-## Smoke API (read-only, прод не трогался)
-| Endpoint | Результат |
-|----------|-----------|
-| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS — задача 98 (ORCH-109) в стадии `testing`, агент не запущен |
-| `GET /queue` | PASS — блок `serial_gate` присутствует (ORCH-088); блок `auto_labels` присутствует (ORCH-089) |
-
-## Результаты
-
-### Полный регресс
-`pytest tests/ -q` → **1899 passed, 1 warning in 516.70s (0:08:36)** (exit 0).
-Единственное предупреждение — `PydanticDeprecatedSince20` (class-based config, pre-existing,
-не связано с ORCH-109). Прод-контейнер не затрагивался.
-
-### Профильная сюита
-`pytest tests/test_orch109_timeout_model.py -v` → **25 passed** (exit 0, 13.50s).
-Покрывает TC-01…TC-12 (+ доп. варианты: configurable-keys, overrides-json-wins, параметризация
-non-positive `[0,-5,abc]`, clean-exit advances, unstamped-killed drops suffix).
-
-## Сопоставление с тест-планом (`04-test-plan.yaml`)
-
-| TC ID | Описание | Тест-функция(и) | Результат |
-|-------|----------|-----------------|-----------|
-| TC-01 | `_resolve_timeout('developer'/'reviewer')` возвращает поднятый бюджет | `test_tc01_developer_reviewer_raised`, `test_tc01_dedicated_keys_are_configurable`, `test_tc01_overrides_json_wins_over_dedicated` | PASS |
-| TC-02 | Прочие роли (analyst/architect/tester/deployer) → глобальный 1800 | `test_tc02_other_roles_use_global_default` | PASS |
-| TC-03 | Малформный конфиг → откат на дефолт + WARNING, без исключения | `test_tc03_malformed_overrides_json_never_raises`, `test_tc03_non_positive_dedicated_falls_back[0/-5/abc]` | PASS |
-| TC-04 | Launch стампит `agent_runs.model` (непустую) рядом с effort | `test_tc04_spawn_stamps_model_and_effort` | PASS |
-| TC-05 | Стамп изолирован: сбой записи не пробрасывает исключение (never-raise) | `test_tc05_stamp_failure_is_isolated` | PASS |
-| TC-06 | `record_usage(None)`/`model=None` НЕ затирают launch-стамп (COALESCE) | `test_tc06_record_usage_none_preserves_model`, `test_tc06_record_usage_model_none_preserves_model` | PASS |
-| TC-07 | `record_usage` с непустой model уточняет/проставляет значение | `test_tc07_record_usage_nonempty_model_enriches_blank`, `test_tc07_record_usage_refines_existing_model` | PASS |
-| TC-08 | Sanity reaper-инварианта: `reaper_max_running_s > max(timeout)+grace` | `test_tc08_shipped_defaults_satisfy_invariant`, `test_tc08_resolved_max_is_developer` | PASS |
-| TC-09 | `_stage_line` для `exit_code=-9` рендерит ` · <model> · <effort>` (model не null) | `test_tc09_killed_run_renders_model_effort`, `test_tc09_unstamped_killed_run_drops_model_suffix` | PASS |
-| TC-10 | `get_running_agents` отдаёт непустую model для running-job (in-flight) | `test_tc10_running_job_exposes_model` | PASS |
-| TC-11 | Анти-salvage: killed developer/reviewer (`exit_code=-9`) не продвигает стадию | `test_tc11_killed_developer_run_does_not_advance`, `test_tc11_killed_reviewer_run_does_not_advance`, `test_tc11_clean_exit_advances` | PASS |
-| TC-12 | Анти-регресс: STAGE_TRANSITIONS/QG_CHECKS/схема `agent_runs` не изменены | `test_tc12_stage_transitions_unchanged`, `test_tc12_agent_runs_model_effort_columns_preexist`, `test_tc12_qg_checks_registry_present` | PASS |
-
-**Все 12 TC выполнены и сопоставлены.**
-
-## Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
-
-| AC | Критерий | Покрытие | Результат |
-|----|----------|----------|-----------|
-| AC-1 | Модель стампится в `agent_runs.model` на launch | TC-04 | PASS |
-| AC-2 | Постфактум-enrich не затирает launch-стамп при оборванном JSON | TC-06, TC-07 | PASS |
-| AC-3 | Тайм-аут developer/reviewer поднят и конфигурируем без влияния на прочие | TC-01, TC-02 | PASS |
-| AC-4 | Малформный timeout-конфиг → безопасный откат (never-break) | TC-03 | PASS |
-| AC-5 | Reaper-инвариант сохранён | TC-08 | PASS |
-| AC-6 | Строка стадии трекера показывает model+effort при timeout/kill | TC-09 | PASS |
-| AC-7 | In-flight видимость модели в `/metrics`/`/queue` | TC-10 | PASS |
-| AC-8 | Timeout-killed прогон не продвигает стадию (анти-salvage) | TC-11 | PASS |
-| AC-9 | Неприкосновенность контрактов и схемы | TC-12 | PASS |
-| AC-10 | Документация и полный регресс зелёный | full regress (1899 passed) + review APPROVED | PASS |
-
-**Все 10 AC покрыты и зелёные.**
-
-## Итог
-**PASS** — полный регресс зелёный (1899 passed, exit 0), профильная сюита ORCH-109 зелёная
-(25 passed), smoke API OK (`serial_gate`/`auto_labels` присутствуют в `/queue`), каждый TC из
-тест-плана выполнен и сопоставлен с критериями приёмки. Задача переходит на `deploy-staging`.

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

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

@@ -1,46 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-109
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-14
-model_used: claude-opus-4-8
-timestamp: 2026-06-14T11:21:00Z
-base_url: http://localhost:8501
-mode: stub
----
-
-# Staging Gate Log — ORCH-109
-
-Canonical staging suite (`scripts/staging_check.py --base-url http://localhost:8501 --mode stub`)
-executed **inside the `orchestrator-staging` container** (ORCH-048 canonical path). Exit code **0**
-→ `staging_status: SUCCESS`.
-
-## Result
-
-```
-RESULT: 8/10 checks PASS
-REAL failed         : none
-SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
-```
-
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-
-## Per-block detail
-
-- **Block A (SMOKE):** A1 `/health` 200 ok · A2 `/queue` 200 (counts/max_concurrency/resilience) · A3 `ORCH_STAGING=true` — all PASS.
-- **Block B (ACCESS):** B4 Plane sandbox accessible · B5 Gitea `orchestrator-sandbox` accessible (push=true) · B6 registry isolation (sandbox present, prod ET/ORCH absent) — all PASS.
-- **Block C (E2E, stub):** C7 create issue in Plane SANDBOX · C8 trigger pipeline via `/webhook/plane` — PASS. C9a/C9b — **waived** sandbox-infra (SANDBOX bot accounts are not members of the sandbox Plane project, so pipeline steps 6+ are unreachable in the sandbox; not a pipeline regression — ORCH-061).
-- **CLEANUP:** Plane test issue deleted (HTTP 204); no stray branch.
-
-## Environment note (observability)
-
-The canonical path requires `docker exec orchestrator-staging …`. In this run no `docker`/`docker compose`
-CLI was reachable and the staging container was not running, so the `orchestrator-staging` service was
-brought up (staging-only, port 8501, real `.env.staging` → sandbox-isolated registry, `ORCH_STAGING=true`)
-via the Docker Engine API mirroring the compose `orchestrator-staging` spec, the canonical
-`staging_check.py` was `docker exec`'d inside it, and the container was torn down afterwards to restore
-the pre-existing state. Prod (8500) was never touched; `.env`/`.env.staging`/`docker-compose.yml`/prod
-infra were not modified.

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

@@ -1,25 +0,0 @@
----
-security_status: PASS
-secrets_found: 0
-deps_blocking: 0
-deps_warning: 4
-deps_audit_degraded: false
----
-# Security Report — ORCH-109
-
-Детерминированный 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

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

@@ -1,7 +0,0 @@
-# Business Request: BUG: merge-gate local re-test timeout causes false rollback after green CI
-
-Work Item ID: ORCH-110
-
-## Description
-
-TBD

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

@@ -1,178 +0,0 @@
----
-work_item: ORCH-110
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 01 — BRD (бизнес-требования): ORCH-110 — BUG: merge-gate local re-test timeout causes false rollback after green CI
-
-Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
-
-> **Багфикс-трек → эскалация в полный цикл (`escalate: full-cycle`).** Задача помечена `Bug`, но
-> сама баг-карточка требует «отдельный анализ вариантов и контрактов merge-gate» (см. «Ограничение»
-> ниже) — это решение с несколькими проектными альтернативами и нетривиальными инвариантами
-> self-hosting, которому нужен ADR. По правилу ORCH-019 (ADR-001 D5) выпускается **полный**
-> analysis-пакет, а трек эскалируется (`POST /bug-fast-track/escalate?work_item=ORCH-110`) → задача
-> проходит стадию `architecture`. Прецедент — родственная задача ORCH-111 («bug → escalate
-> full-cycle»).
-
----
-
-## 1. Бизнес-контекст и проблема
-
-Оркестратор — self-hosting инструмент: его прод-контейнер обслуживает конвейер всех проектов и
-дорабатывает сам себя. На ребре `deploy-staging → deploy` исполняется детерминированный под-гейт
-**merge-gate** (`check_branch_mergeable`, ORCH-043): он догоняет ветку до текущего `origin/main`
-(`auto_rebase_onto_main`) и затем **локально пере-прогоняет весь тест-сюит** (`retest_branch` →
-`python -m pytest tests/ -q`) в worktree, чтобы поймать **семантический** конфликт слияния (ветка
-зелёная по своей базе, но ломает уехавший `main`).
-
-**Установленные факты инцидента (ORCH-109, PR #129):**
-- tester завершился `result: PASS`; полный регресс — **`1899 passed` за `516.70s`**;
-- CI Gitea по HEAD — зелёный (push + pull_request success); PR после rebase — open, `mergeable=true`;
-- merge-gate локальный re-test упал по **таймауту**: `re-test timeout after 600s`
-  (`merge_retest_timeout_s = 600`);
-- на хосте обнаружены **старые зависшие pytest-процессы** `tests/test_install_lite_script.py`,
-  жившие **> 2 суток** и грузившие CPU; прибиты вручную 2026-06-14.
-
-**Цепочка отказа.** Зависшие осиротевшие pytest-процессы (CPU-голодание) → тот же сюит, что у tester
-шёл 516.70s (запас до 600s ≈ 16%), под нагрузкой превысил 600s → `check_branch_mergeable` вернул
-`(False, "re-test timeout after 600s")` → `_handle_merge_gate_rollback`: откат `deploy-staging →
-development` + developer-retry. Каждый из 3 retry повторно падал по тому же CPU-голоданию → финальный
-alert **«Merge-gate still failing after 3 developer retries (re-test timeout after 600s)»** → задача
-застряла, потребовалось ручное вмешательство.
-
-**Корень (подтверждён по коду):**
-1. **Утечка осиротевших процессов.** `merge_gate.retest_branch` и `coverage_gate.measure_coverage`
-   запускают `subprocess.run([... pytest ...], timeout=...)` **без изоляции группы процессов**
-   (`start_new_session`/`preexec_fn`). При `TimeoutExpired` Python убивает только **прямого
-   потомка**; внуки pytest репарентируются на PID 1 (tini жнёт зомби, но не убивает живых сирот) и
-   живут сутками, грузя CPU. Это источник CPU-голодания (ровно симптом из фактов).
-2. **Нет толерантности к инфра-таймауту.** Re-test **таймаут** (ресурсная/инфра-причина)
-   классифицируется идентично **красному** re-test (реальный дефект кода): оба → откат на
-   `development` + расход developer-retry. Разработчик не может «починить» CPU-голодание → retry
-   сгорают вхолостую и упираются в alert «Manual intervention needed».
-3. **Тонкий бюджет.** Бюджет re-test `600s` практически равен фактическому времени сюита
-   (`516.70s`); запас не растёт вместе с сюитом (ср. ORCH-109, где по той же причине были подняты
-   бюджеты агентов developer/reviewer).
-4. **Контракт необходимости re-test.** На ветке, уже актуальной к `origin/main` (rebase — no-op), и
-   с зелёным CI по этому же HEAD локальный полный re-test пере-проверяет ровно тот коммит, что CI
-   уже подтвердил, — становясь избыточной единственной точкой ложного отказа.
-
-## 2. Объём (scope)
-
-### В объёме
-- Поведение merge-gate при **таймауте** локального re-test: классификация и путь восстановления
-  (толерантность к инфра-таймауту вместо ложного отката на `development`).
-- **Жизненный цикл подпроцессов**, которые оркестратор запускает САМ для проверок: re-test merge-gate
-  (`merge_gate.retest_branch`) и coverage-run (`coverage_gate.measure_coverage`) — гарантия отсутствия
-  осиротевших процессов после таймаута/kill.
-- **Согласованность бюджета** re-test с фактическим временем полного сюита (адекватный запас) с учётом
-  сквозных инвариантов reaper/lease.
-- **Контракт необходимости** локального re-test merge-gate (когда он реально нужен относительно
-  зелёного CI и состояния `branch vs origin/main`) — анализ вариантов под решение архитектора.
-- Наблюдаемость инфра-таймаута (отличить «инфра-таймаут, повтор/defer» от «дефект кода → developer»).
-
-### Вне объёма
-- **Алерт sidecar-watchdog на осиротевший тест-процесс** — это **ORCH-111** (`proc_blocking`,
-  наблюдатель только сигналит, никогда не убивает, C-1). ORCH-110 — комплементарная сторона
-  (предотвращение утечки + толерантность), дубля детекции не вводит.
-- Ручное умерщвление уже зависших хост-процессов — операционная мера (выполнена 2026-06-14), не код.
-- Любые правки `STAGE_TRANSITIONS` / реестра `QG_CHECKS` / `check_*`-семантики / machine-verdict
-  ключей / схемы БД (инвариант NFR-1).
-- Изменение конкретного теста `tests/test_install_lite_script.py` (его поведение — отдельный предмет;
-  здесь важен класс «оркестратор-спавненный pytest не должен переживать свой бюджет»).
-- Поведение не-self-hosting репозиториев (enduro-trails) — нулевая регрессия.
-- Изменение хука прод-деплоя/рестарт прод-контейнера (self-hosting безопасность).
-
-## 3. Заинтересованные стороны
-- **Owner / оператор self-hosting** — страдает от ручного разбора застрявших задач и зависших
-  процессов; заказчик исправления.
-- **Конвейер всех проектов** — общий прод-контейнер: утечка CPU деградирует обслуживание enduro.
-- **Пакетный автономный режим (эпик ORCH-088)** — ложные откаты и manual-gate'ы ломают цель
-  «10–20 задач за ночь без вмешательства».
-- **Принимает результат:** reviewer → tester → deployer штатного конвейера.
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 — Зелёный путь без ручного вмешательства.** При зелёном tester `PASS` и зелёном CI задача
-  **не должна** требовать ручного вмешательства из-за инфраструктурного/локального re-test таймаута
-  (прямое «Ожидаемое поведение» баг-карточки).
-- **BR-2 — Инфра-таймаут ≠ дефект кода.** Таймаут локального re-test merge-gate (ресурсная/инфра
-  причина) **не должен** трактоваться как код-фейл: путь восстановления **не** должен сжигать
-  developer-retry и приводить к «Manual intervention after N developer retries», если CI и tester
-  были зелёными. Реакция на таймаут — ограниченный повтор/defer и/или отдельный инфра-сигнал, не
-  безусловный откат на `development`.
-- **BR-3 — Нет осиротевших процессов.** Подпроцессы pytest, запущенные самим оркестратором для
-  re-test и coverage-run, **должны** полностью завершаться (всё дерево, включая внуков) при
-  таймауте/kill. Ни один оркестратор-спавненный pytest не должен переживать свой бюджет и продолжать
-  грузить CPU.
-- **BR-4 — Адекватный бюджет re-test.** Бюджет времени re-test **должен** иметь достаточный запас над
-  фактическим временем полного сюита, чтобы здоровый сюит при штатной нагрузке не падал по таймауту;
-  бюджет конфигурируем и со-эволюционирует с ростом сюита.
-- **BR-5 — Контракт необходимости re-test.** Merge-gate **должен** различать «ветка реально отстала
-  от уехавшего `origin/main` и была ребейзнута» (риск семантического конфликта → re-test оправдан) и
-  «ветка уже актуальна / rebase — no-op, CI по этому HEAD зелёный» (re-test избыточен). Локальный
-  re-test не должен быть избыточной единственной точкой ложного отказа на коммите, уже подтверждённом
-  CI. Конкретный контракт (skip/scope/trust-CI-SHA) выбирает архитектор и фиксирует в ADR.
-- **BR-6 — Сохранение защиты от семантического конфликта.** Толерантность к таймауту **не должна**
-  ослаблять исходную цель merge-gate (ORCH-043): **детерминированно красный** re-test (реальный сбой
-  теста, а не таймаут) по-прежнему обязан откатывать на `development`. Послабление применяется ТОЛЬКО
-  к таймауту/инфра, никогда к красному результату.
-- **BR-7 — Наблюдаемость.** Состояние «инфра-таймаут» должно быть видимым (лог + Telegram с
-  кликабельным номером + read-only в `GET /queue`) и отличимым от код-фейл-отката; согласовано с
-  сигналом ORCH-111 (без дубля).
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — Инварианты конвейера неприкосновенны.** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` /
-  семантика `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/
-  `staging_status:`/`security_status:`/`coverage_status:`) / схема БД — **байт-в-байт** прежние.
-  Исправление — аддитивное (врезка/leaf-логика), не новая стадия и не новый зарегистрированный QG.
-- **NFR-2 — Kill-switch + нулевая регрессия.** Новое поведение под флагом; при выключенном флаге —
-  поведение **байт-в-байт** как до ORCH-110 (таймаут → прежний откат). Скоуп — self-hosting
-  (`orchestrator`); enduro не затронут.
-- **NFR-3 — Self-hosting безопасность.** Исправление **никогда** не пушит/force-push в `main` (INV-4;
-  merge только через Gitea PR-merge API), не рестартит прод-контейнер, не трогает detached-деплой.
-- **NFR-4 — never-raise.** Любая ошибка в новом пути → безопасный дефолт + WARNING; исключение
-  никогда не уходит в `advance_stage`/monitor-поток (контракт merge-gate сохранён).
-- **NFR-5 — Ограниченность (anti-loop).** Любой повтор/defer таймаута строго ограничен по числу
-  попыток и суммарному времени; исчерпание → **чёткий инфра-alert**, отличный от «developer must
-  fix», а не бесконечный bounce и не молчаливое зависание.
-- **NFR-6 — Сквозные инварианты времени.** Любое изменение бюджета re-test должно уважать
-  существующие соотношения: `merge_lock_timeout_s` (TTL merge-lease), `reaper_max_running_s`
-  (Tier-3 backstop reaper, ORCH-065/109), `coverage_run_timeout_s` — без рассинхрона.
-
-## 6. Допущения и ограничения
-- **Ограничение из баг-карточки (дословно):** «Решение намеренно не описано в этой баге; нужен
-  отдельный анализ вариантов и контрактов merge-gate». → Аналитик фиксирует требования и
-  тест-план; **варианты и контракт merge-gate** прорабатывает архитектор (06-adr) — основание
-  эскалации в полный цикл.
-- Допущение: tini (PID 1) жнёт зомби, но не убивает живых осиротевших процессов (подтверждено
-  поведением инцидента) — отсюда требование tree-kill (BR-3).
-- Допущение: таймаут merge-gate re-test в зелёном инциденте вызван внешним CPU-голоданием, а не
-  реальным зависанием теста ветки; но решение обязано остаться **fail-safe** к случаю реального
-  зависшего теста (см. Риск R-2 / BR-6).
-- Среда верификации — staging-контур (8501), обязательная страховка перед прод-деплоем self.
-
-## 7. Критерии успеха
-Резюме: зелёный tester `PASS` + зелёный CI + актуальная ветка → задача доходит до `deploy` без
-ложного отката на `development` и без manual-gate из-за инфра-таймаута; оркестратор-спавненные
-pytest-процессы не переживают свой бюджет; реальный красный re-test по-прежнему откатывает на
-`development`; инварианты конвейера и self-hosting не тронуты. Детальные PASS/FAIL —
-`03-acceptance-criteria.md`.
-
-## 8. Риски
-- **R-1** — Над-толерантность маскирует реальный зависший тест (бесконечный/долгий) как «инфра» →
-  смягчение: строгая ограниченность (NFR-5) + отдельный инфра-alert + сохранение красно-откат-пути
-  (BR-6).
-- **R-2** — Поднятие бюджета без правки tree-kill лишь отодвигает отказ (сюит растёт) → исправление
-  должно бить корень (BR-3), бюджет (BR-4) — вторично.
-- **R-3** — Рассинхрон сквозных таймаутов (reaper/lease) при изменении бюджета (NFR-6).
-- **R-4** — Дубль/конфликт с сигналом ORCH-111 (`proc_blocking`) → координация: ORCH-110
-  предотвращает/толерирует, ORCH-111 наблюдает; разные слои.
-- Детальная оценка и митигации — `10-tech-risks.md` (заполняет архитектор).

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

@@ -1,129 +0,0 @@
----
-work_item: ORCH-110
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 02 — ТЗ (TRZ): ORCH-110 — merge-gate local re-test timeout: устранение ложного отката + утечки процессов
-
-Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные требования к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование, выбор вариантов и **контракт merge-gate** — задача архитектора (06-adr,
-> основание `escalate: full-cycle`). Здесь — поведение/контракты/инварианты и привязка к модулям,
-> НЕ выбор механизма.
-
-## 1. Сводка изменения
-Устранить ложный откат `deploy-staging → development`, возникающий когда локальный re-test merge-gate
-падает по **таймауту** (инфра/ресурс), при зелёном tester `PASS` и зелёном CI. Изменение бьёт по двум
-корням и одному контракту: (1) **утечка осиротевших pytest-процессов** из оркестратор-спавненных
-прогонов re-test/coverage (источник CPU-голодания) → гарантировать tree-kill дерева подпроцесса при
-таймауте/kill; (2) **классификация инфра-таймаута** как транзиента (повтор/defer/инфра-alert), а не
-код-фейла (откат + расход developer-retry); (3) **контракт необходимости** локального re-test
-относительно зелёного CI и состояния `branch vs origin/main`. Сопутствующе — согласование **бюджета**
-re-test с реальным временем сюита. Всё — аддитивно, под kill-switch, never-raise, скоуп self-hosting,
-с сохранением исходной защиты merge-gate от семантического конфликта (красный re-test по-прежнему
-откатывает).
-
-## 2. Задействованные модули / пути
-| Путь | Действие |
-|------|----------|
-| `src/merge_gate.py` | изменить — `retest_branch`: жизненный цикл подпроцесса (tree-kill при таймауте/kill); классификация исхода «timeout» как транзиента (контракт возврата) |
-| `src/coverage_gate.py` | изменить — `measure_coverage`: тот же tree-kill при таймауте (сиблинг-источник утечки, BR-3) |
-| `src/qg/checks.py` | изменить — `check_branch_mergeable`: различать «timeout/infra» от «red re-test» в возвращаемом контракте (без смены имени/семантики зарегистрированного `check_*`) |
-| `src/stage_engine.py` | изменить — `_handle_merge_gate` / маршрутизация исхода: инфра-таймаут → defer/повтор/инфра-alert (по образцу `_handle_merge_gate_defer`), НЕ `_handle_merge_gate_rollback`; красный re-test → прежний rollback |
-| `src/config.py` | изменить — флаг(и) толерантности к инфра-таймауту + (опц.) согласование `merge_retest_timeout_s`; уважить сквозные инварианты `merge_lock_timeout_s` / `reaper_max_running_s` / `coverage_run_timeout_s` |
-| `docs/architecture/README.md`, `CLAUDE.md`, `CHANGELOG.md` | обновить — описание поведения merge-gate re-test (golden source наравне с кодом) |
-| `tests/test_*` | создать — покрытие по `04-test-plan.yaml` |
-
-> Точный набор новых символов/флагов и механизм tree-kill (process-group `start_new_session`+killpg,
-> либо иной) — решение архитектора. ТЗ фиксирует **что** должно выполняться, не **как**.
-
-## 3. Функциональные требования
-
-### FR-1 — Толерантность к инфра-таймауту re-test (нет ложного отката) [BR-1, BR-2]
-Когда merge-gate локальный re-test завершается специфически по **таймауту** (а не детерминированно
-красным результатом), исход ДОЛЖЕН классифицироваться как транзиент/инфра, не код-фейл. Путь
-восстановления НЕ ДОЛЖЕН быть тем же `_handle_merge_gate_rollback` (откат на `development` + инкремент
-developer-retry), который при зелёных CI/tester ведёт к «Manual intervention needed». Допустимая
-реакция (выбор — архитектор): ограниченный повтор re-test и/или defer (по образцу существующего
-`_handle_merge_gate_defer` для `merge-lock busy`) и/или отдельный инфра-alert. Прецеденты толерантности
-к инфра: ORCH-061 (staging infra tolerance), ORCH-093 (transient vs terminal классификация merge-POST).
-
-### FR-2 — Tree-kill оркестратор-спавненных тест-процессов [BR-3]
-`merge_gate.retest_branch` и `coverage_gate.measure_coverage` ДОЛЖНЫ гарантировать, что при таймауте
-(а также при любом kill/прерывании прогона) завершается **всё дерево** подпроцесса pytest, включая
-внуков, а не только прямой потомок. После таймаута ни один оркестратор-спавненный pytest-процесс не
-должен оставаться живым и грузить CPU. Контракт возврата `retest_branch`
-(`(False, "re-test timeout after <T>s")`) сохраняется; меняется лишь побочный эффект — отсутствие
-утечки. Существующий каскад launcher `SIGTERM→grace→SIGKILL` (`stop_process`) — образец на уровне
-агентов; для этих subprocess-прогонов требуется эквивалентная гарантия на уровне группы процессов.
-
-### FR-3 — Согласованность бюджета re-test [BR-4, NFR-6]
-Бюджет `merge_retest_timeout_s` ДОЛЖЕН иметь достаточный запас над фактическим временем полного сюита
-(наблюдаемо: 600s бюджет vs 516.70s факт ≈ 16%). Бюджет остаётся конфигурируемым; при его изменении
-ДОЛЖНЫ соблюдаться сквозные инварианты: `reaper_max_running_s > max(agent_timeout, бюджеты) + grace`
-(ORCH-065/109) и согласование с `merge_lock_timeout_s` (TTL merge-lease держится на время re-test).
-Малформный/непозитивный конфиг → безопасный дефолт + WARNING (never-break).
-
-### FR-4 — Контракт необходимости локального re-test [BR-5, BR-6]
-Merge-gate ДОЛЖЕН различать риск-кейсы и применять re-валидацию пропорционально реальному риску
-слияния:
-- ветка **реально отстала** от уехавшего `origin/main` и ребейзнута → семантический риск → re-test
-  оправдан (текущая цель ORCH-043 сохраняется);
-- ветка **уже актуальна** / rebase — no-op, и CI по этому самому HEAD зелёный → локальный полный
-  re-test пере-проверяет ровно подтверждённый CI коммит и не должен быть единственной точкой ложного
-  отказа.
-Конкретный контракт (например: пропуск re-test при «не-behind + зелёный CI по HEAD», сокращённый
-scope, доверие SHA, подтверждённому CI, и т. п.) — **выбор архитектора в ADR** (ядро запрошенного
-баг-карточкой «анализа контрактов merge-gate»). Инвариант **BR-6**: детерминированно **красный**
-re-test (реальный сбой теста) обязан и далее откатывать на `development` — послабление применяется
-ТОЛЬКО к таймауту/инфра.
-
-### FR-5 — Сохранение инвариантов и kill-switch [NFR-1, NFR-2, NFR-3, NFR-4]
-Изменение аддитивно: `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict
-ключи / схема БД — без изменений; merge-gate остаётся под-гейтом-врезкой, не новой стадией/QG. Под
-kill-switch: выключенный флаг → байт-в-байт прежнее поведение (таймаут → откат). Скоуп self-hosting
-(`orchestrator`); enduro — no-op. never-raise; INV-4 (никогда push/force-push `main`; merge только
-через Gitea PR API) и запрет рестарта прод-контейнера — соблюдены.
-
-### FR-6 — Наблюдаемость и ограниченность [BR-7, NFR-5]
-Состояние «инфра-таймаут» ДОЛЖНО логироваться, уведомляться в Telegram (кликабельный номер задачи) и
-быть видимым read-only (например, расширение блока `merge`/`merge_verify` в `GET /queue`), отличимо от
-код-фейл-отката. Любой повтор/defer строго ограничен (число попыток + суммарное время); исчерпание →
-**инфра-alert** (не «developer must fix»). Координация с ORCH-111 (`proc_blocking`) — без дубля:
-ORCH-110 предотвращает/толерирует, ORCH-111 наблюдает.
-
-## 4. Изменения API
-Новых обязательных эндпоинтов **не требуется**. Допустимо (when-applicable, на усмотрение
-архитектора) **read-only** расширение существующего снимка `GET /queue` (блок merge-gate) полями
-наблюдаемости инфра-таймаута/повторов. Никаких новых управляющих эндпоинтов.
-
-## 5. Изменения схемы БД
-**Нет.** Счётчики повторов/defer — по образцу существующих (`_merge_defer_count` /
-`_developer_retry_count` поверх `jobs`/`agent_runs`) либо in-memory/sentinel; новые таблицы/колонки не
-вводятся (NFR-1).
-
-## 6. Требования к новым/изменённым QG checks
-**Нет нового зарегистрированного QG.** `check_branch_mergeable` остаётся в реестре `QG_CHECKS` с тем же
-именем и семантикой PASS/FAIL; меняется лишь **различение причины FAIL** (timeout/infra vs red) в
-возвращаемом reason и **маршрутизация исхода** во врезке `_handle_merge_gate` (`advance_stage`).
-`STAGE_TRANSITIONS` и состав `QG_CHECKS` — байт-в-байт.
-
-## 7. Совместимость / регресс
-- **Обратная совместимость:** kill-switch off → поведение байт-в-байт как до ORCH-110 (таймаут →
-  rollback на `development`), включая текст alert'ов.
-- **Область раската:** self-hosting `orchestrator` (как ORCH-035/043/058/071); прочие репо — no-op,
-  путь LLM-`deployer`/прежний merge не затронут.
-- **Обратимость:** чисто аддитивная логика под флагом; откат = выключить флаг.
-- **Self-hosting:** без рестарта прод-контейнера; merge только через Gitea PR API; никаких операций с
-  `main` (INV-4).
-- **Анти-регресс целей merge-gate:** красный re-test → прежний rollback (BR-6); защита от
-  семантического конфликта/фантомного merge (ORCH-043/071/073) — не ослаблена.
-- **Трассировка маркеров (ORCH-078):** правки в `merge_gate.py`/`coverage_gate.py`/`qg/checks.py`
-  затрагивают блоки с маркерами ORCH-043/071/073/093/027/065/109 — перед изменением сверить их
-  `06-adr` и не сломать зафиксированные инварианты (lease, never-raise, fail-open/closed, бюджеты).

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

@@ -1,123 +0,0 @@
----
-work_item: ORCH-110
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-110 — merge-gate re-test timeout
-
-Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
-провалом). Reviewer/тестировщик проверяет их буквально по файлам/тестам репозитория.
-
----
-
-## AC-1 — Зелёный путь не требует ручного вмешательства из-за инфра-таймаута
-**Условие:** tester `PASS` + зелёный CI + ветка актуальна к `origin/main`, но локальный re-test
-merge-gate упирается в таймаут (смоделированное CPU-голодание/медленный прогон).
-- **PASS:** задача НЕ откатывается ложно как код-фейл и НЕ доходит до alert «Merge-gate still failing
-  after N developer retries»; она доходит до `deploy` (возможно после ограниченного defer/повтора)
-  или поднимает **отдельный инфра-alert**, отличимый от «developer must fix».
-- **FAIL:** таймаут → `_handle_merge_gate_rollback` на `development` с расходом developer-retry →
-  manual-gate (текущее ошибочное поведение).
-
----
-
-## AC-2 — Инфра-таймаут классифицируется отдельно от красного re-test
-**Условие:** `check_branch_mergeable` вернул FAIL по причине таймаута vs по причине красного теста.
-- **PASS:** таймаут маршрутизируется в транзиент-путь (defer/повтор/инфра-alert), красный re-test —
-  в прежний rollback на `development`; пути различимы в коде и в логах/наблюдаемости.
-- **FAIL:** оба исхода идут одним путём отката на `development`.
-
----
-
-## AC-3 — Реальный красный re-test по-прежнему откатывает (анти-над-толерантность)
-**Условие:** локальный re-test даёт детерминированно красный результат (реальный сбой теста, не
-таймаут).
-- **PASS:** задача откатывается на `development` + developer-retry (цель ORCH-043 сохранена), lease
-  освобождается.
-- **FAIL:** красный re-test «толерируется» и задача продвигается/деплоится со сломанным кодом.
-
----
-
-## AC-4 — Нет осиротевших тест-процессов после таймаута
-**Условие:** `merge_gate.retest_branch` (и `coverage_gate.measure_coverage`) запущены против прогона,
-порождающего дочерние/внучатые процессы, и прогон превышает бюджет (таймаут).
-- **PASS:** по таймауту завершается всё дерево подпроцесса (включая внуков); живых
-  оркестратор-спавненных pytest-процессов не остаётся; контракт возврата
-  `(False, "re-test timeout after <T>s")` сохранён.
-- **FAIL:** прямой потомок убит, но внуки репарентируются и продолжают жить/грузить CPU.
-
----
-
-## AC-5 — Бюджет re-test согласован и уважает сквозные инварианты
-**Условие:** конфигурация бюджета re-test и связанных таймаутов.
-- **PASS:** `merge_retest_timeout_s` имеет адекватный запас над фактическим временем сюита;
-  соблюдено `reaper_max_running_s > max(agent_timeout, бюджеты) + grace` и согласование с
-  `merge_lock_timeout_s`/`coverage_run_timeout_s`; малформный конфиг → дефолт + WARNING.
-- **FAIL:** бюджет оставлен впритык к времени сюита без обоснования, либо изменение бюджета ломает
-  инвариант reaper/lease.
-
----
-
-## AC-6 — Контракт необходимости re-test зафиксирован и реализован
-**Условие:** ветка не-behind (rebase no-op) + зелёный CI по этому HEAD.
-- **PASS:** поведение локального re-test соответствует контракту, выбранному архитектором в ADR
-  (skip/scope/trust-CI-SHA и т. п.); re-test не является избыточной единственной точкой ложного
-  отказа на коммите, уже подтверждённом CI; решение и его обоснование задокументированы в `06-adr/`.
-- **FAIL:** контракт не определён/не реализован; полный re-test безусловно гоняется и при не-behind +
-  зелёном CI.
-
----
-
-## AC-7 — Kill-switch и нулевая регрессия
-**Условие:** флаг толерантности выключен; и/или не-self-hosting репозиторий (enduro).
-- **PASS:** поведение байт-в-байт как до ORCH-110 (таймаут → прежний rollback; те же тексты
-  alert'ов); enduro-путь не затронут.
-- **FAIL:** при выключенном флаге/для enduro поведение изменилось.
-
----
-
-## AC-8 — Инварианты конвейера и self-hosting не тронуты
-**Условие:** статический и поведенческий анализ изменений.
-- **PASS:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика `check_*` / machine-verdict ключи /
-  схема БД — без изменений; никаких push/force-push в `main` (INV-4), merge только через Gitea PR API,
-  прод-контейнер не рестартится; все публичные функции merge-gate/coverage остаются never-raise.
-- **FAIL:** изменён любой из перечисленных инвариантов, или исключение уходит в `advance_stage`.
-
----
-
-## AC-9 — Ограниченность транзиент-пути (anti-loop) + наблюдаемость
-**Условие:** инфра-таймаут повторяется.
-- **PASS:** число повторов/defer ограничено и по попыткам, и по суммарному времени; исчерпание →
-  один чёткий инфра-alert; событие видно в логах/`GET /queue` и отличимо от код-фейла.
-- **FAIL:** бесконечный bounce/повтор, либо молчаливое зависание без терминального сигнала.
-
----
-
-## AC-10 — Регресс-тест (красный до фикса, зелёный после)
-**Условие:** наличие автоматического теста, воспроизводящего инцидент.
-- **PASS:** в `tests/` есть тест, который на текущем коде **падал бы** (инфра-таймаут re-test →
-  ложный rollback / выживший процесс), а после фикса **зелёный**; включён в полный регресс `pytest`.
-- **FAIL:** регресс-теста нет, либо он не воспроизводит инцидент.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-1 |
-| AC-3 | BR-6 / FR-4 |
-| AC-4 | BR-3 / FR-2 |
-| AC-5 | BR-4 / FR-3 / NFR-6 |
-| AC-6 | BR-5 / FR-4 |
-| AC-7 | NFR-2 / FR-5 |
-| AC-8 | NFR-1 / NFR-3 / NFR-4 / FR-5 |
-| AC-9 | NFR-5 / BR-7 / FR-6 |
-| AC-10 | BR-1…BR-3 (регресс инцидента) |

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

@@ -1,94 +0,0 @@
-work_item: ORCH-110
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-escalate: full-cycle
-title: "merge-gate re-test timeout: tolerance + no orphan-process leak + re-test contract"
-framework: pytest
-scope: >
-  Покрывает: классификацию инфра-таймаута re-test merge-gate как транзиента (без ложного отката),
-  tree-kill оркестратор-спавненных pytest-прогонов (re-test + coverage), сохранение красно-откат-пути,
-  согласование бюджета re-test со сквозными инвариантами, контракт необходимости re-test, kill-switch
-  и наблюдаемость. Вне покрытия: алерт sidecar-watchdog (ORCH-111), правка конкретного
-  test_install_lite_script.py, поведение enduro (только проверяется no-op).
-notes: >
-  TC-10 — ОБЯЗАТЕЛЬНЫЙ регресс-тест инцидента ORCH-109/PR#129: красный на текущем коде (инфра-таймаут
-  re-test → ложный rollback / выживший процесс), зелёный после фикса. Подпроцессы в тестах мокаются
-  (управляемый "медленный/спавнящий детей pytest"), без обращения к сети/Plane/Gitea. Полный регресс
-  tests/ должен оставаться зелёным. Точные имена символов/флагов уточняет архитектор (06-adr);
-  модули-плейсхолдеры ниже выровнены под манифест PIPELINE_DOCS.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "retest_branch: таймаут возвращает (False, 're-test timeout after <T>s') И завершает всё дерево подпроцесса (внуки не переживают таймаут)."
-    module: tests/test_orch110_retest_lifecycle.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "coverage_gate.measure_coverage: таймаут завершает всё дерево подпроцесса (сиблинг-источник утечки, BR-3); возврат None сохранён."
-    module: tests/test_orch110_retest_lifecycle.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "check_branch_mergeable: исход 'timeout' различим от 'red re-test' в reason/классификации (без смены имени/семантики зарегистрированного check_*)."
-    module: tests/test_orch110_merge_gate_classify.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Маршрутизация исхода: инфра-таймаут → defer/повтор/инфра-alert путь (НЕ _handle_merge_gate_rollback на development, без инкремента developer-retry)."
-    module: tests/test_orch110_merge_gate_routing.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Анти-над-толерантность: детерминированно КРАСНЫЙ re-test по-прежнему → откат на development + developer-retry + release lease (BR-6 сохранён)."
-    module: tests/test_orch110_merge_gate_routing.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Ограниченность (anti-loop): повторы/defer инфра-таймаута лимитированы по попыткам и суммарному времени; исчерпание → один инфра-alert, не бесконечный bounce."
-    module: tests/test_orch110_merge_gate_routing.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Kill-switch off → байт-в-байт прежнее поведение (таймаут → rollback на development, прежний текст alert); not-self repo (enduro) → no-op."
-    module: tests/test_orch110_killswitch.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Бюджет/инварианты: malformed/непозитивный merge_retest_timeout_s → дефолт + WARNING; соблюдён reaper_max_running_s > max(agent_timeout, бюджеты)+grace и согласование с merge_lock_timeout_s."
-    module: tests/test_orch110_budget_invariants.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "never-raise: любая ошибка в новом транзиент-пути → безопасный дефолт + WARNING; исключение не уходит в advance_stage."
-    module: tests/test_orch110_merge_gate_routing.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "РЕГРЕСС инцидента: tester PASS + зелёный CI + ветка не-behind, но re-test таймаут — задача НЕ откатывается ложно и НЕ упирается в 'Merge-gate still failing after N developer retries'; доходит до deploy или поднимает инфра-alert. Красный до фикса, зелёный после."
-    module: tests/test_orch110_false_rollback_regression.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "Контракт необходимости re-test (FR-4/AC-6): при не-behind + зелёном CI по HEAD локальный re-test ведёт себя по выбранному в ADR контракту (skip/scope/trust-CI) и не является избыточной единственной точкой ложного отказа. Финальная форма — после решения архитектора."
-    module: tests/test_orch110_retest_contract.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: "Наблюдаемость: инфра-таймаут отражён в логах/GET /queue (read-only) и Telegram-уведомлении с кликабельным номером; отличим от код-фейл-отката; без дубля с ORCH-111."
-    module: tests/test_orch110_observability.py
-    expected: PASS

docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md

@@ -1,352 +0,0 @@
----
-work_item: ORCH-110
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# ADR-001: Merge-gate re-test — толерантность к инфра-таймауту, tree-kill спавненных процессов и контракт необходимости re-test
-
-Work Item: **ORCH-110** — BUG: merge-gate local re-test timeout causes false rollback after green CI
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`**
-(решение кросс-каттинговое: затрагивает merge-gate ORCH-043, coverage-gate ORCH-027 и
-сквозной инвариант времени reaper ORCH-065/109).
-
-## Статус
-Proposed
-
-## Контекст
-
-На ребре `deploy-staging → deploy` детерминированный под-гейт **merge-gate** (`check_branch_mergeable`,
-ORCH-043) догоняет ветку до текущего `origin/main` (`auto_rebase_onto_main`) и **локально
-пере-прогоняет весь тест-сюит** (`retest_branch` → `python -m pytest tests/ -q`, бюджет
-`merge_retest_timeout_s=600`), чтобы поймать семантический конфликт слияния (зелёная по своей базе
-ветка ломает уехавший `main`).
-
-**Инцидент (ORCH-109 / PR #129, факты сверены по коду):** tester `PASS` (полный регресс
-`1899 passed` за `516.70s`), CI Gitea зелёный, PR `mergeable=true`, ветка не-behind — но merge-gate
-re-test **упал по таймауту** (`re-test timeout after 600s`). На хосте — осиротевшие pytest-процессы
-(`tests/test_install_lite_script.py`), жившие > 2 суток и грузившие CPU. Цепочка отказа: осиротевшие
-процессы → CPU-голодание → сюит (516.7s, запас до 600s ≈ 16%) превысил бюджет →
-`check_branch_mergeable` вернул `(False, "re-test timeout after 600s")` → `_handle_merge_gate`
-маршрутизировал в `_handle_merge_gate_rollback` (откат `deploy-staging → development` +
-developer-retry) → каждый из 3 retry падал по тому же CPU-голоданию → alert «Merge-gate still failing
-after 3 developer retries» → задача застряла, потребовалось ручное вмешательство.
-
-**Корни (подтверждены по коду):**
-1. **Утечка осиротевших процессов.** `merge_gate.retest_branch` (`src/merge_gate.py:202`) и
-   `coverage_gate.measure_coverage` (`src/coverage_gate.py:156`) запускают
-   `subprocess.run([... pytest ...], timeout=...)` **без изоляции группы процессов**. При
-   `TimeoutExpired` Python убивает только **прямого потомка** (`proc.kill()`); внуки pytest
-   репарентируются на PID 1 (tini жнёт зомби, но не убивает живых сирот) и живут сутками. Это
-   источник CPU-голодания.
-2. **Нет толерантности к инфра-таймауту.** `_handle_merge_gate` (`src/stage_engine.py:967`)
-   различает лишь `"merge-lock busy"` (→ defer) от всего остального (→ rollback). Re-test **таймаут**
-   (инфра/ресурс) классифицируется идентично **красному** re-test (дефект кода) → откат на
-   `development` + расход developer-retry, который разработчик не может «починить».
-3. **Тонкий бюджет.** `merge_retest_timeout_s=600` практически равен фактическому времени сюита
-   (516.7s); запас не растёт с сюитом.
-4. **Контракт необходимости re-test.** При `premerge_rebase_always=True` (дефолт, ORCH-026 A-2)
-   `check_branch_mergeable` (`src/qg/checks.py:705`) **всегда** ребейзит и пере-тестирует — даже на
-   ветке, уже актуальной к `origin/main` (rebase — no-op). На таком HEAD локальный re-test
-   пере-проверяет ровно тот коммит, что CI + tester + staging уже подтвердили, становясь избыточной
-   единственной точкой ложного отказа. (Заметим: на пути `premerge_rebase_always=False` не-behind
-   ветка re-test **уже пропускает** — `src/qg/checks.py:707-709`.)
-
-Баг-карточка явно отложила выбор механизма архитектору: «Решение намеренно не описано; нужен
-отдельный анализ вариантов и контрактов merge-gate» — основание эскалации `escalate: full-cycle`.
-
-## Решение
-
-### Сводка
-
-Бьём по двум корням, одному контракту и одному бюджету — **аддитивно, под kill-switch, never-raise,
-скоуп self-hosting**, сохраняя исходную защиту merge-gate от семантического конфликта:
-
-- **D1 (root)** — единый leaf `src/proc_group.py` спавнит оркестратор-порождённые pytest-прогоны в
-  **отдельной группе процессов** (`start_new_session`) и при таймауте/прерывании убивает **всё
-  дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL). Используют его `retest_branch` и
-  `measure_coverage`. Контракты возврата сохранены — меняется лишь побочный эффект (нет сирот).
-- **D2 (классификация)** — чистый предикат `merge_gate.classify_retest_failure(reason)` различает
-  `timeout`/`red`/`lock-busy`/`other` без смены имени/семантики `check_branch_mergeable`.
-- **D3 (маршрутизация)** — инфра-таймаут → новый `_handle_merge_gate_infra_retry` (ограниченный
-  повтор/defer по образцу `_handle_merge_gate_defer`, **без** отката на `development` и **без**
-  расхода developer-retry); красный re-test → прежний `_handle_merge_gate_rollback`.
-- **D4 (контракт re-test)** — re-test исполняется **тогда и только тогда**, когда rebase реально
-  сдвинул HEAD (`main` уехал); no-op rebase (ветка уже актуальна) **пропускает** локальный re-test,
-  ровно как уже делает путь `premerge_rebase_always=False` для не-behind ветки.
-- **D5 (бюджет)** — `merge_retest_timeout_s` 600 → **900** (запас 74% над 516.7s) с валидацией и
-  проверкой сквозного инварианта reaper/lease — **без** изменения `reaper_max_running_s`.
-- **D6 (наблюдаемость)** — счётчики в `merge_gate`, блок `merge_gate` в `GET /queue`, отдельный
-  инфра-alert, отличимый от код-фейла; координация с ORCH-111 без дубля.
-
-### D1 — Process-group изоляция + tree-kill спавненных pytest [FR-2 / BR-3 / AC-4]
-
-Новый **leaf-модуль** `src/proc_group.py` (stdlib-only, never-raise, импортирует только `os`/`signal`/
-`subprocess`/`time`/`logging` — НЕ другие `src/*`, по образцу чистоты `serial_gate`/`staging_verdict`):
-
-```python
-def run_in_process_group(
-    cmd: list[str], *, cwd: str, timeout: float, env: dict | None = None,
-    grace_s: float = 5.0, tree_kill: bool = True,
-) -> ProcResult:   # ProcResult(returncode:int|None, stdout:str, stderr:str, timed_out:bool)
-```
-
-Механика (POSIX):
-1. `proc = subprocess.Popen(cmd, cwd=cwd, env=env, stdout=PIPE, stderr=PIPE, text=True,
-   start_new_session=True)` — `start_new_session=True` делает потомка лидером новой сессии/группы
-   (`setsid`), поэтому все его потомки (xdist-воркеры, подпроцессы тестов) разделяют один `pgid ==
-   proc.pid`.
-2. `proc.communicate(timeout=timeout)` — ждём в бюджете.
-3. На `subprocess.TimeoutExpired` — **tree-kill группы** каскадом, зеркало `launcher.stop_process`,
-   но по **группе**: `os.killpg(os.getpgid(pid), SIGTERM)` → poll `grace_s` → если жива
-   `os.killpg(..., SIGKILL)`; затем обязательный `proc.communicate()`/`proc.wait()` (reap), чтобы не
-   оставить зомби. `ProcessLookupError` толерируется на каждом шаге.
-4. Возвращает `timed_out=True` при таймауте; иначе `returncode`/stdout/stderr.
-
-**Fallback (never-break):** при `tree_kill=False` ИЛИ платформе без `os.killpg`/`start_new_session`
-(`not hasattr(os, "killpg")`) — деградирует на прежний `subprocess.run(cmd, ..., timeout=timeout)`
-(байт-в-байт прежнее поведение, прод-Linux на это не попадает).
-
-**Интеграция:**
-- `retest_branch` зовёт `run_in_process_group([... pytest target -q], cwd=wt, timeout=<resolved>,
-  tree_kill=settings.subprocess_tree_kill_enabled, grace_s=settings.agent_kill_grace_seconds)`;
-  маппинг исхода 1:1 прежнему: `timed_out → (False, "re-test timeout after <T>s")`,
-  `returncode==0 → (True, "re-test green")`, иначе `(False, "re-test failed: ...<tail>")`. **Контракт
-  возврата сохранён** (FR-2) — меняется лишь отсутствие утечки.
-- `measure_coverage` зовёт тот же helper для `pytest --cov`; исход маппится как сейчас (таймаут/ошибка
-  → `None`, иначе чтение `--cov-report=json`). Грантия tree-kill — сиблинг-источник утечки закрыт
-  (BR-3).
-
-Грейс берётся из существующего `agent_kill_grace_seconds` (новый ключ не вводим — минимизация
-конфига); для subprocess-pytest грейс короткий и без необходимости «флашить артефакты».
-
-Kill-switch `subprocess_tree_kill_enabled` (дефолт `True`). Это **глобальная** гигиена процессов (не
-гейт-решение), поэтому без `*_repos`-скоупа; на практике оба call-site исполняются лишь для
-merge_gate/coverage-репо (self-hosting).
-
-### D2 — Классификация исхода re-test [FR-1 / AC-2 / TC-03]
-
-Чистый предикат в `src/merge_gate.py` (never-raise), единая точка «магической строки» вместо россыпи
-`"timeout" in reason`:
-
-```python
-def classify_retest_failure(reason: str) -> str:
-    # "timeout"  — re-test упёрся в бюджет (инфра/ресурс)
-    # "red"      — детерминированно красный re-test (дефект кода)
-    # "lock-busy"— merge-lock busy (контеншн леза)
-    # "other"    — rebase conflict / setup error / прочее
-```
-
-`check_branch_mergeable` **не меняет** имя/семантику/PASS-FAIL контракт (NFR-1): он уже возвращает
-различимый reason (`"re-test timeout after <T>s"` vs `"re-test failed after rebase: ..."` vs
-`"merge-lock busy"` vs `"rebase conflict: ..."`). Меняется только **различение причины FAIL** на
-слое маршрутизации.
-
-**Скоуп классификации — строго re-test таймаут.** `auto_rebase_onto_main` имеет собственный
-`"rebase timeout"` (git завис) — это **другой** инфра-таймаут, но без успешного rebase ветку нельзя
-догнать до `main` → merge невозможен по существу. Он остаётся на прежнем rollback-пути (вне объёма
-ORCH-110; консервативно). Документируем границу явно.
-
-### D3 — Маршрутизация инфра-таймаута: ограниченный повтор + инфра-alert [FR-1 / FR-6 / NFR-5 / AC-1 / AC-9]
-
-В `_handle_merge_gate` (`src/stage_engine.py`) после ветки `reason == "merge-lock busy"`:
-
-```python
-if (settings.merge_retest_infra_tolerance_enabled
-        and merge_gate.classify_retest_failure(reason) == "timeout"):
-    _handle_merge_gate_infra_retry(task_id, current_stage, repo, work_item_id, branch, reason, result)
-    return True
-_handle_merge_gate_rollback(...)   # red re-test / conflict — БЕЗ изменений (BR-6/AC-3)
-```
-
-Новый `_handle_merge_gate_infra_retry` — зеркало `_handle_merge_gate_defer` (НЕ rollback):
-- Перекладывает staging-deployer обратно в очередь с задержкой `merge_retest_infra_retry_delay_s`
-  (`enqueue_job("deployer", ..., available_at_delay_s=...)`); задача **остаётся на `deploy-staging`**.
-  **Нет** `update_task_stage("development")`, **нет** инкремента developer-retry, **нет**
-  `notify_qg_failure`-код-фейл-семантики.
-- Счётчик повторов — restart-safe, по маркеру в `task_content` (`_merge_infra_retry_count`, зеркало
-  `_merge_defer_count`: `... LIKE '%merge-gate infra-timeout retry%'`). Бюджет
-  `merge_retest_infra_max_retries` (дефолт 2).
-- **Лиз уже освобождён** `check_branch_mergeable` при таймауте (`src/qg/checks.py:721`) — на повторе
-  гейт переacquire'ит штатно (как defer-путь). Согласовано с инвариантом леза.
-- **Исчерпание (anti-loop, NFR-5):** `set_issue_blocked` + **отдельный инфра-alert** (Telegram с
-  кликабельным `link_for` + Plane-коммент), формулировка **явно инфраструктурная**, отличная от
-  «developer must fix»: *«Merge-gate re-test infra-timeout сохраняется после N повторов — ресурсная
-  проблема (CPU/осиротевшие процессы), НЕ дефект кода. Нужно ручное вмешательство /
-  проверьте хост.»* Задача **не** уходит в `development`.
-
-**Ограниченность по времени (NFR-5/AC-9).** Каждый повтор — **отдельный** staging-deployer job со
-своим agent-timeout и reaper-backstop; ни один прогон не превышает `reaper_max_running_s` сам по себе.
-Суммарная стоимость худшего случая: `N × (delay + re-test ≤ timeout)` =
-`2 × (120 + 900) ≈ 34 мин` до инфра-alert — конечно и наблюдаемо. После первого таймаута D1 уже убил
-сирот, поэтому следующий re-test, как правило, проходит — повтор есть механизм восстановления, а не
-маскировки.
-
-**Скоуп.** Отдельный `*_repos` не нужен: путь достижим только когда merge-gate **реален**
-(`_merge_gate_applies` → self-hosting/`merge_gate_repos`); для прочих репо гейт N/A → PASS → ветка
-недостижима. Kill-switch off → таймаут идёт прежним rollback-путём (NFR-2, байт-в-байт).
-
-### D4 — Контракт необходимости локального re-test [FR-4 / BR-5 / BR-6 / AC-6]
-
-**Выбранный вариант — пропуск re-test при no-op rebase** (ветка уже содержит свежий `origin/main`).
-ORCH-043 защищает от семантического конфликта, который возникает **только** когда `main` уехал и
-ветка была реально ребейзнута на новые коммиты. Если rebase HEAD **не сдвинул** (ветка уже актуальна),
-«уехавшего main» нет → re-test не даёт сигнала сверх уже пройденных `check_ci_green` + tester
-`check_tests_passed` + staging на **этом же** HEAD → он избыточен.
-
-Реализация в `check_branch_mergeable` (детерминированно, **offline**, без сетевого CI-запроса):
-1. `pre = _head_sha(repo, branch)` (rev-parse HEAD в worktree, never-raise → `""`).
-2. `auto_rebase_onto_main(...)` (как сейчас; конфликт → release lease → FAIL без изменений).
-3. `post = _head_sha(repo, branch)`.
-4. Если `merge_retest_skip_when_current_enabled` И `pre` и `post` непусты И `pre == post` (rebase —
-   доказанный no-op) → **пропустить re-test**, вернуть
-   `(True, "branch up-to-date (re-test skipped: rebase no-op, HEAD CI-validated)")`; лиз HELD.
-5. Иначе (HEAD сдвинут / SHA не определить / флаг off) → `retest_branch` как сейчас.
-
-**Почему без отдельного сетевого CI-запроса (отличие от варианта C).** HEAD на момент merge-gate при
-no-op rebase — тот же коммит, что уже прошёл `check_ci_green` (ребро development→review), tester и
-staging в этом же конвейере. «CI green for this HEAD» гарантирован **транзитивно** пройденным
-конвейером; повторный сетевой запрос статуса — лишняя зависимость и хрупкость.
-
-**Fail-safe к контракту (BR-6/AC-3):** при невозможности доказать no-op (любой `pre`/`post` пуст,
-git-ошибка) — re-test **выполняется** (не пропускается на неопределённости). Когда re-test
-**исполняется** и красный → прежний rollback. Послабление применяется ТОЛЬКО к доказанному no-op, и
-только к *пропуску*, не к красному вердикту. Это симметрично уже существующему пропуску re-test на
-не-behind ветке при `premerge_rebase_always=False` — D4 лишь распространяет ту же оптимизацию на
-no-op-rebase случай `premerge_rebase_always=True`, приводя оба режима к согласованному правилу:
-«локальный re-test гоняется лишь когда ветка реально догоняла уехавший `main`».
-
-Kill-switch `merge_retest_skip_when_current_enabled` (дефолт `True`); off → re-test после rebase
-всегда (прежнее `premerge_rebase_always` поведение).
-
-### D5 — Согласование бюджета re-test [FR-3 / BR-4 / AC-5 / NFR-6]
-
-`merge_retest_timeout_s`: **600 → 900** (запас 74% над наблюдаемыми 516.7s; против прежних ≈16%).
-Бюджет — теперь **третья** линия защиты (D1 убирает корень CPU-голодания, D3 толерирует редкий
-остаточный таймаут, D4 резко сокращает частоту re-test), поэтому большой бамп не нужен; умеренные 900
-дают runway под рост сюита, оставаясь в сквозном инварианте reaper **без** правки
-`reaper_max_running_s`.
-
-**Валидация (never-break):** `retest_branch` резолвит бюджет через новый
-`_resolve_retest_timeout()` — `int(settings.merge_retest_timeout_s)` если `> 0`, иначе дефолт **900**
-+ WARNING (зеркало `launcher._resolve_timeout`). Малформ/непозитив больше не уходит в `subprocess`.
-
-**Проверка сквозного инварианта (NFR-6, AC-5).** Re-test/coverage исполняются в монитор-потоке
-**staging-deployer**-джоба (агент deployer уже завершён; `advance_stage` post-agent), поэтому суммарная
-работа джоба считается против `reaper_max_running_s`. Worst-case для deploy-staging-джоба:
-
-| Слагаемое | Бюджет, s |
-|-----------|-----------|
-| deployer-агент (deploy-staging, `agent_timeout_seconds`) | 1800 |
-| security-scan (gitleaks+pip-audit) | ~120 |
-| rebase (`_REBASE_TIMEOUT`) | 120 |
-| **re-test (`merge_retest_timeout_s`, новый)** | **900** |
-| coverage (`coverage_run_timeout_s`) | 900 |
-| image-freshness rebuild | ~600 |
-| grace | 20 |
-| **Σ** | **≈ 4460** |
-
-`reaper_max_running_s = 5400 > 4460` ✓ (запас ~940s). Инвариант ORCH-065/109
-`reaper_max_running_s > max(agent_timeout)+grace` (5400 > 3600+20 для developer-джоба) сохранён.
-`merge_lock_timeout_s = 300` (TTL леза) **меньше** держания леза на время re-test+coverage — но это
-**существующее** свойство (ORCH-043: лиз держится от гейта до merge, дольше TTL; реклейм безопасен
-holder-aware и pid-aware, ORCH-065) и **не** ухудшается ORCH-110 (re-test 900 vs прежние 600 — +300s
-держания, всё ещё покрыто pid-liveness реклеймом, который не трогает живого держателя). Поэтому
-`reaper_max_running_s` **не меняем**; D5 — только бамп `merge_retest_timeout_s` + валидация.
-
-> Если оператор поднимет `merge_retest_timeout_s` env'ом выше — обязан соблюсти
-> `reaper_max_running_s > Σ(deploy-staging gate-work) + grace` (таблица выше); зафиксировано в
-> `07-infra-requirements.md`.
-
-### D6 — Наблюдаемость и координация с ORCH-111 [FR-6 / BR-7 / AC-9 / R-4]
-
-- **Счётчики** in-process в `merge_gate.py` (`_MERGE_GATE_COUNTERS`, образец `_MERGE_VERIFY_COUNTERS`):
-  `retest_timeout_total`, `retest_infra_retry_total`, `retest_infra_exhausted_total`,
-  `retest_skipped_current_total`, `last_infra_timeout_wi`. Снимок `merge_gate_status()` → read-only
-  блок `merge_gate` в `GET /queue` (флаги/счётчики). Только информация, никогда не источник решения.
-- **Логи** — раздельные строки для infra-retry vs code-fail rollback; INFO на пропуск re-test (D4).
-- **Telegram/Plane** — инфра-alert на исчерпании (D3), формулировка инфраструктурная (не «developer
-  must fix») с кликабельным номером.
-- **Координация с ORCH-111 (`proc_blocking`, adr-0041) — без дубля (R-4):** ORCH-110
-  **предотвращает/толерирует** (tree-kill у источника + транзиент-маршрут), ORCH-111 **наблюдает**
-  (sidecar алертит на пережившие осиротевшие тест-процессы). ORCH-110 не вводит детектор процессов;
-  он убирает сирот у источника. Разные слои — нулевое пересечение.
-
-### Затронутые маркеры / трассировка (ORCH-078)
-
-Правки касаются блоков с маркерами ORCH-043 (`retest_branch`, `check_branch_mergeable`, lease),
-ORCH-026 (`premerge_rebase_always`), ORCH-027 (`measure_coverage`), ORCH-065/109 (инвариант
-reaper/timeout). 3+ маркера в `merge_gate.py` → опираемся на **сводный сквозной**
-`adr-0042` (этот пакет) + `adr-0006`/`adr-0040`. Инварианты ORCH-043/071/073/093 (лиз holder-aware,
-INV-4 «никогда push/force-push main», never-raise, fail-open/closed классификации) **не нарушаются**:
-ORCH-110 не трогает merge-актор/верификатор пути `deploy → done`.
-
-**Директива developer'у (append-only regression-guard, ORCH-073):** дописать в
-`merge_gate.MAIN_REGRESSION_MARKERS` строку `("ORCH-110", "classify_retest_failure",
-"src/merge_gate.py")`, чтобы новый инвариант был защищён от фантомного отката.
-
-## Альтернативы
-
-- **Только поднять бюджет (без D1).** Отвергнуто (R-2): не бьёт корень — растущий сюит снова упрётся;
-  сироты продолжат грузить CPU. Бюджет — вторичная мера.
-- **Tree-kill через `subprocess.run` + ручной `Popen` в каждом модуле (без общего leaf).** Отвергнуто:
-  дублирование хрупкой `killpg`-логики в двух местах → дрейф. Один тестируемый leaf
-  (`proc_group.py`) — single source of truth.
-- **Вариант C: trust-CI-SHA (сетевой запрос статуса CI HEAD → skip re-test).** Отвергнуто как контракт
-  по умолчанию: вводит сетевую зависимость в детерминированный offline-гейт и ослабляет
-  семантик-конфликт-гард (CI бежал на базе ветки, не на результате слияния). D4 (no-op-rebase skip)
-  даёт ту же выгоду детерминированно и offline.
-- **Толерировать ЛЮБОЙ FAIL merge-gate (включая красный) как транзиент.** Отвергнуто (BR-6/AC-3,
-  R-1): сломает цель ORCH-043 — красный re-test обязан откатывать. Послабление строго к таймауту.
-- **Новый зарегистрированный QG / новая стадия для инфра-ретрая.** Отвергнуто (NFR-1): под-гейт —
-  врезка в `advance_stage`; `STAGE_TRANSITIONS`/`QG_CHECKS` неприкосновенны.
-- **Init-process / убийца сирот на хосте.** Отвергнуто: реинтродукция привилегий/хост-доступа;
-  предотвращение у источника (D1) проще и self-hosting-безопасно; наблюдение оставлено ORCH-111.
-
-## Последствия
-
-- **+** Зелёный путь (tester PASS + CI green + актуальная ветка) больше не ловит ложный откат/manual-gate
-  из-за инфра-таймаута (BR-1/AC-1). Сироты не переживают бюджет (BR-3/AC-4). Re-test не гоняется
-  избыточно на актуальной ветке (BR-5/AC-6), что само снижает шанс таймаута.
-- **+** Красный re-test по-прежнему откатывает (BR-6/AC-3); инварианты конвейера/леза/INV-4
-  неприкосновенны (NFR-1/NFR-3/AC-8).
-- **−** Инфра-таймаут добавляет до `N×(delay+timeout)` (~34 мин) к худшему случаю перед инфра-alert
-  (вместо мгновенного, но ложного, отката). Митигейшн: D1 устраняет первопричину → повтор обычно
-  проходит первым; бюджет повторов мал (2).
-- **−** +5 конфиг-ключей + бамп бюджета. Митигейшн: дефолты = желаемое прод-поведение (ORCH-101
-  канон), каждый под kill-switch.
-- **−** D4 пропускает re-test на no-op rebase: теоретический пропуск семантик-конфликта, не
-  поймать который CI/tester/staging уже не смогли бы. Митигейшн: пропуск **только** при доказанном
-  no-op (нет «уехавшего main» → нет нового класса конфликта); на любой неопределённости — re-test
-  бежит (fail-safe).
-- **Откат:** `subprocess_tree_kill_enabled=False` (→ прежний `subprocess.run`),
-  `merge_retest_infra_tolerance_enabled=False` (→ таймаут=rollback),
-  `merge_retest_skip_when_current_enabled=False` (→ всегда re-test после rebase),
-  `merge_retest_timeout_s=600` (→ прежний бюджет). Каждый флаг независим; полный откат = вернуть 4
-  значения → байт-в-байт до-ORCH-110.
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-110/01-brd.md`
-- TRZ: `docs/work-items/ORCH-110/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-110/03-acceptance-criteria.md`
-- Test-plan: `docs/work-items/ORCH-110/04-test-plan.yaml`
-- Инфра: `docs/work-items/ORCH-110/07-infra-requirements.md`
-- Риски: `docs/work-items/ORCH-110/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`
-- Сверено по коду: `src/merge_gate.py` (`retest_branch`, `auto_rebase_onto_main`,
-  `MAIN_REGRESSION_MARKERS`), `src/coverage_gate.py` (`measure_coverage`),
-  `src/qg/checks.py` (`check_branch_mergeable`, `_merge_gate_applies`),
-  `src/stage_engine.py` (`_handle_merge_gate`, `_handle_merge_gate_defer`,
-  `_handle_merge_gate_rollback`, `_merge_defer_count`),
-  `src/config.py` (`merge_retest_timeout_s`, `reaper_max_running_s`, `agent_kill_grace_seconds`),
-  `src/agents/launcher.py` (`stop_process` — образец каскада),
-  `src/job_reaper.py` (`reaper_max_running_s` backstop)
-- Смежные: `adr-0006` (merge-gate ORCH-043), `adr-0040` (timeout-бюджеты ORCH-109),
-  `adr-0029` (coverage-gate ORCH-027), `adr-0011` (reaper/lease ORCH-065),
-  `adr-0041` (ORCH-111 `proc_blocking` — комплементарный наблюдатель)
-</content>
-</invoke>

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

@@ -1,68 +0,0 @@
----
-work_item: ORCH-110
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-110 — merge-gate re-test infra-tolerance + tree-kill
-
-Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable. Топология/контейнеры/порты/CI **не меняются**; файл фиксирует новые env-ключи,
-> сквозной инвариант времени и аудит self-hosting безопасности.
-
-## I-1. Топология / окружения
-**N/A.** Новых контейнеров/портов/томов/сетей нет. Изменения — только в коде приложения
-(`src/proc_group.py` новый leaf; правки `merge_gate`/`coverage_gate`/`qg.checks`/`stage_engine`/
-`config`) и в значениях конфигурации. Прод `orchestrator` (8500) / staging (8501) — без изменений
-топологии.
-
-**Требование среды:** оркестратор должен исполняться под POSIX (Linux-контейнер, как сейчас) — D1
-использует `os.setsid`/`os.killpg`/`os.getpgid`. На не-POSIX helper деградирует на прежний
-`subprocess.run` (never-break), но боевая среда — Linux.
-
-## I-2. Переменные окружения / секреты
-Секретов нет. Новые ключи (`src/config.py` + `.env.example`); **дефолт каждого = желаемому
-прод-поведению** (ORCH-101 канон: пустой `.env` воспроизводит целевое поведение):
-
-| Ключ (config) | Env | Дефолт | Назначение |
-|---------------|-----|--------|------------|
-| `subprocess_tree_kill_enabled` | `ORCH_SUBPROCESS_TREE_KILL_ENABLED` | `True` | D1 kill-switch; off → прежний `subprocess.run(timeout=)` |
-| `merge_retest_infra_tolerance_enabled` | `ORCH_MERGE_RETEST_INFRA_TOLERANCE_ENABLED` | `True` | D3 kill-switch; off → таймаут = прежний rollback |
-| `merge_retest_infra_max_retries` | `ORCH_MERGE_RETEST_INFRA_MAX_RETRIES` | `2` | D3 бюджет повторов инфра-таймаута |
-| `merge_retest_infra_retry_delay_s` | `ORCH_MERGE_RETEST_INFRA_RETRY_DELAY_S` | `120` | D3 задержка перед повтором staging-deployer |
-| `merge_retest_skip_when_current_enabled` | `ORCH_MERGE_RETEST_SKIP_WHEN_CURRENT_ENABLED` | `True` | D4 kill-switch; off → re-test после rebase всегда |
-| `merge_retest_timeout_s` (изменение значения) | `ORCH_MERGE_RETEST_TIMEOUT_S` | `600 → 900` | D5 бюджет re-test (запас 74% над 516.7s) |
-
-Реюз существующего `agent_kill_grace_seconds` (грейс tree-kill каскада) — новый ключ не вводится.
-
-## I-3. Деплой / рестарт
-- **Self-hosting инвариант соблюдён:** изменение НЕ рестартит прод-контейнер, НЕ пушит/force-push
-  `main` (INV-4), НЕ трогает detached-деплой. Выкат — штатным конвейером через **обязательный
-  staging-гейт (8501)**.
-- Дефолты вступают в силу при следующей сборке образа; ручных env-шагов на хосте не требуется
-  (дефолты = целевое поведение). Откат — выставить 4 kill-switch в `False` и
-  `ORCH_MERGE_RETEST_TIMEOUT_S=600`.
-
-## I-4. CI/CD
-**Без изменений** `.gitea/workflows/`. Новые pytest-тесты (`tests/test_orch110_*.py` по
-`04-test-plan.yaml`) исполняются существующим шагом `pytest tests/ -q`. Новых зависимостей нет
-(`proc_group` — stdlib-only; `pytest-cov` уже в образе по ORCH-027).
-
-## I-5. Сквозной инвариант времени (NFR-6 — операционно критично)
-Re-test/coverage исполняются в монитор-потоке staging-deployer-джоба, поэтому их суммарная работа
-считается против `reaper_max_running_s`. Проверенный worst-case deploy-staging-джоба:
-
-```
-deployer-агент 1800 + security ~120 + rebase 120 + re-test 900 + coverage 900 + image ~600 + grace 20
-≈ 4460 s  <  reaper_max_running_s = 5400   (запас ~940 s)  ✓
-```
-
-`reaper_max_running_s` **не меняется** (D5). При ручном повышении `ORCH_MERGE_RETEST_TIMEOUT_S` env'ом
-оператор ОБЯЗАН сохранить неравенство `reaper_max_running_s > Σ(gate-work) + grace`, иначе reaper
-(ORCH-065) может реапнуть легитимный мид-гейт джоб; при необходимости поднять
-`ORCH_REAPER_MAX_RUNNING_S` в локстеп (паттерн ORCH-109).
-</content>

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

@@ -1,40 +0,0 @@
----
-work_item: ORCH-110
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-15
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-110 — merge-gate re-test infra-tolerance + tree-kill
-
-Work Item: **ORCH-110** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Над-толерантность маскирует реально зависший тест ветки** как «инфра» (R-1 BRD): бесконечный/долгий тест ветки → таймаут → толерируется → задача не падает на дефекте | Низ. | Выс. | Строгая ограниченность D3 (`merge_retest_infra_max_retries=2`, суммарное время ≤ ~34 мин) → исчерпание = **инфра-alert** (не молчание); красно-откат-путь сохранён (BR-6); D4 не пропускает re-test когда HEAD реально сдвинут. Остаточно: «зависший тест ветки» эскалируется как инфра, а не код — приемлемо (оператор увидит alert и разберёт; тест-зависание чинит developer вручную) |
-| TR-2 | **`os.killpg`/`start_new_session` платформенная зависимость** (не-POSIX / урезанный контейнер) | Низ. | Сред. | Гард `hasattr(os, "killpg")` + kill-switch `subprocess_tree_kill_enabled` → fallback на прежний `subprocess.run` (never-break); бой — Linux |
-| TR-3 | **Tree-kill убьёт не те процессы** (неверный pgid → SIGKILL чужой группе) | Низ. | Выс. | `pgid == proc.pid` гарантирован `start_new_session` для **нашего** потомка; killpg только по `os.getpgid(proc.pid)` нашего Popen; `ProcessLookupError` толерируется; никогда не киляем pgid 0/own |
-| TR-4 | **Рассинхрон сквозных таймаутов** при бампе бюджета (R-3 BRD): re-test 900 + coverage 900 + агент → > reaper_max_running_s | Низ. | Сред. | Проверенная таблица worst-case (≈4460 < 5400, 07-infra I-5); `reaper_max_running_s` не меняется; валидация непозитивного бюджета → дефолт+WARNING; операторская заметка про ручной бамп |
-| TR-5 | **Магическая строка классификации** (`"timeout" in reason`) хрупка к смене текста reason | Низ. | Сред. | Единый предикат `classify_retest_failure` (одна тестируемая точка, TC-03) вместо россыпи; reason — стабильный контракт ORCH-043 (как `"merge-lock busy"`) |
-| TR-6 | **D4 пропустит re-test и пропустит семантический конфликт** | Оч.низ. | Сред. | Пропуск ТОЛЬКО при доказанном no-op rebase (нет «уехавшего main» → нет нового класса конфликта); на неопределённости (`pre`/`post` пуст / git-ошибка) re-test бежит (fail-safe); HEAD уже прошёл CI+tester+staging транзитивно |
-| TR-7 | **Дубль/конфликт с ORCH-111** (`proc_blocking`) | Оч.низ. | Низ. | Чёткое разделение слоёв (D6): ORCH-110 предотвращает/толерирует у источника, ORCH-111 наблюдает; ORCH-110 не вводит детектор процессов |
-| TR-8 | **Регресс при выключенном флаге** (нарушен байт-в-байт fallback) | Низ. | Выс. | TC-07 проверяет kill-switch off = прежнее поведение и enduro no-op; каждый из 4 флагов независим и off → старый путь |
-| TR-9 | **Гонка leдза на инфра-ретрае** (повторный acquire, держание дольше TTL) | Низ. | Сред. | Существующее свойство ORCH-043 (лиз держится дольше TTL; реклейм holder-aware + pid-aware, ORCH-065 не трогает живого держателя); таймаут уже освободил лиз перед ретраем — переacquire штатный |
-
-## Сводный вывод
-Доминирующий класс — **над-толерантность vs анти-регресс защиты merge-gate** (TR-1/TR-6): закрыт
-строгой ограниченностью + сохранением красно-откат-пути + пропуском re-test только на доказанном
-no-op. Остальные риски — стандартного класса (платформенная зависимость, сквозные таймауты,
-kill-switch регресс), митигированы существующими паттернами кодовой базы (never-raise, fail-safe,
-дефолт=бой, валидация). Изменение **аддитивно** и **полностью обратимо** флагами; новой стадии/QG/
-схемы БД нет. **Эскалация `arch:major-change` не требуется**; возврат в анализ не требуется. Остаточный
-риск для прод-конвейера (self-hosting) — **низкий**: critical-path не трогает `main`/прод-рестарт/
-detached-деплой, а наихудший новый сценарий (инфра-alert после ретраев) строго лучше текущего (ложный
-manual-gate).
-</content>

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

@@ -1,112 +0,0 @@
----
-verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
-work_item: ORCH-110
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-110
-version: 1
----
-
-# Review ORCH-110
-
-> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter. `APPROVED` → дальше по конвейеру.
-
-## Summary
-Багфикс инцидента ORCH-109/PR#129 (bug → escalate full-cycle): локальный re-test merge-gate падал по
-**таймауту** при зелёных CI+tester+staging → ложно маршрутизировался как код-фейл (откат
-`deploy-staging → development` + расход developer-retry) → manual-gate. Реализация **полностью
-соответствует ТЗ (FR-1…FR-6, AC-1…AC-10) и ADR-001 (D1…D6)**, аддитивна, под 5 независимыми
-kill-switch, never-raise, скоуп self-hosting. Инварианты конвейера и self-hosting — байт-в-байт целы;
-документация (golden source) обновлена в том же PR; багфикс несёт регресс-тест-фиксатор (ORCH-019 BR-4 /
-AC-10). **Вердикт: APPROVED** — P0/P1/P2 findings нет.
-
-> Замечание по ревью-процессу (не finding): локальный ref `main` в worktree устарел (6a04d0a);
-> истинная цель мержа — `origin/main` (b6c9d27, уже содержит ORCH-111). Диф против `origin/main`
-> добавляет ровно 4 ORCH-110-коммита (fix + analysis + architect + business-request); посторонних
-> изменений нет. Ревью проведено против `origin/main`.
-
-## Оси проверки
-
-### 1. Соответствие ТЗ (02-trz / 03-acceptance-criteria) — PASS
-- **FR-1/AC-1/AC-2** (толерантность к инфра-таймауту, отдельная классификация): `merge_gate.classify_retest_failure`
-  (`timeout`/`red`/`lock-busy`/`other`) + `stage_engine._handle_merge_gate_infra_retry` (зеркало
-  `_handle_merge_gate_defer`: задача остаётся на `deploy-staging`, БЕЗ отката/developer-retry). ✓
-- **FR-2/AC-4** (tree-kill): новый stdlib-only leaf `src/proc_group.py::run_in_process_group`
-  (`start_new_session` → `os.killpg` SIGTERM→grace→SIGKILL), интегрирован в `retest_branch` и
-  `measure_coverage`; реальный grandchild-тест TC-01 доказывает «сирота не переживает таймаут». ✓
-- **FR-3/AC-5** (бюджет): `merge_retest_timeout_s` 600→900 + `_resolve_retest_timeout` (малформ/непозитив
-  → дефолт 900 + WARNING); сквозной инвариант `reaper_max_running_s (5400) > Σ≈4460 + grace` проверен
-  тестом TC-08 **без** правки `reaper_max_running_s`. ✓
-- **FR-4/AC-6/AC-3 (BR-6)** (контракт необходимости re-test): пропуск re-test при доказанном no-op rebase
-  (`head_sha` до==после, обе непусты) в `check_branch_mergeable`; fail-safe — на любой неопределённости
-  re-test выполняется; красный re-test/конфликт по-прежнему откатывают (тест
-  `test_tc10_real_catchup_red_retest_still_rolls_back`). ✓
-- **FR-5/AC-7/AC-8** (kill-switch + нулевая регрессия + инварианты): 5 независимых флагов (дефолт = боевое);
-  `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика и имя `check_branch_mergeable`/machine-verdict/схема БД —
-  статически подтверждено «не тронуты»; INV-4 (никогда push/force-push `main`) соблюдён. ✓
-- **FR-6/AC-9** (наблюдаемость + anti-loop): счётчики `_MERGE_GATE_COUNTERS` + read-only блок `merge_gate`
-  в `GET /queue`; ограниченность по попыткам (`merge_retest_infra_max_retries=2`, restart-safe счётчик по
-  маркеру в `task_content`) и времени; исчерпание → один инфра-alert (явно «НЕ дефект кода»). ✓
-- **AC-10** (регресс red-before/green-after): `tests/test_orch110_false_rollback_regression.py` гоняет
-  РЕАЛЬНЫЙ `check_branch_mergeable` через `advance_stage`; на до-ORCH-110-коде оба сценария упали бы
-  (Scenario A гоняла бы обречённый re-test, Scenario B откатилась бы на `development`). ✓
-
-### 2. Соответствие ADR + трассировка маркеров (ORCH-078) — PASS
-- D1…D6 реализованы как зафиксировано в `06-adr/ADR-001` + сквозном `adr-0042`. ✓
-- Директива developer'у выполнена: `("ORCH-110", "classify_retest_failure", "src/merge_gate.py")`
-  дописан в `MAIN_REGRESSION_MARKERS` (append-only, существующие маркеры целы). ✓
-- Затронутые маркеры ORCH-043/071/073/093/027/065/109 сверены, зафиксированные инварианты **не сломаны**:
-  лиз held-on-success / released-on-failure (контракт `check_branch_mergeable` сохранён, skip-путь
-  возвращает `(True, …)` с HELD lease), anti-phantom pre-merge rebase не тронут, coverage fail-open `None`
-  сохранён, reaper-инвариант проверен численно.
-
-### 3. Качество кода — PASS
-- never-raise по всему пути (leaf `proc_group`, классификатор, врезка `_handle_merge_gate_infra_retry`
-  обёрнута в `_handle_merge_gate_infra_retry`/`_merge_gate_infra_retry_impl` с проглатыванием исключения).
-- Docstrings на всех публичных функциях; чёткое разделение чистого предиката и I/O.
-- Тесты содержательные (реальный kill дерева процессов, реальная маршрутизация через `advance_stage`,
-  валидация бюджета, kill-switch-параметризация, наблюдаемость). Прогон зелёный:
-  141 (ORCH-110 + изменённые merge/coverage/config) + 575 (широкая зона stage_engine/qg/merge/deploy/reaper)
-  + 37 (docs-инварианты, ORCH-011 + host-hardcodes) — все PASS.
-- **Багфикс-трек (ORCH-019 BR-4):** исправление несёт тест-фиксатор дефекта (AC-10) — требование выполнено.
-
-### 4. Документация — PASS (приоритетная проверка)
-`src/` изменён → документация обновлена в **том же PR**:
-- `CLAUDE.md` — добавлена секция ORCH-110 (паспорт). ✓
-- `CHANGELOG.md` — запись `[Unreleased]` с разбивкой D1…D6 + 5 ключей. ✓
-- `.env.example` — 5 новых ключей + бамп `ORCH_MERGE_RETEST_TIMEOUT_S=900` с врезкой про сквозной
-  инвариант. ✓
-- `docs/architecture/README.md` — поведение merge-gate re-test (D1…D6) + ссылки на ADR. ✓
-- `docs/overview/tech-pipeline.md` — **витрина системы (ORCH-011)** обновлена: исключение «инфра-таймаут =
-  транзиент, не откат»; `tests/test_system_docs.py` зелёный. ✓
-- Глобальный сквозной ADR `docs/architecture/adr/adr-0042-…md` + work-item `06-adr/ADR-001-…md` заведены. ✓
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет)
-
-### P2 — Should fix
-- (нет)
-
-### P3 — Nice-to-have (не блокирует)
-- В `check_branch_mergeable` (`src/qg/checks.py:750`) причина FAIL раскладывается локальной подстрокой
-  `"timeout" in t_reason`, тогда как введён точный предикат `merge_gate.classify_retest_failure`. Поведение
-  безопасно (авторитетная маршрутизация в `stage_engine._handle_merge_gate` использует классификатор; редкий
-  `"re-test error: …"` со словом «timeout» в детали безопасно уйдёт в `other`→rollback), но единая точка
-  классификации читалась бы чище. Косметика, на усмотрение.
-
-## Документация
-**Обновлена полностью в том же PR** (golden source наравне с кодом): `CLAUDE.md`, `CHANGELOG.md`,
-`.env.example`, `docs/architecture/README.md`, витрина `docs/overview/tech-pipeline.md` (ORCH-011),
-глобальный ADR `adr-0042`, work-item ADR `06-adr/ADR-001`. Машинно-проверяемые факты витрины и
-запрет хост-хардкодов — зелёные (`tests/test_system_docs.py`, `tests/test_no_host_hardcodes.py`).
-Пунктов `README.md` «Известные ограничения», требующих снятия этим PR, не затронуто. Расхождений
-документации с кодом не выявлено.

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

@@ -1,91 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-110
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-110
----
-
-# Test Report — ORCH-110
-
-Багфикс инцидента ORCH-109/PR#129: локальный re-test merge-gate падал по **таймауту** (инфра/CPU-
-голодание от осиротевших pytest-процессов) при зелёных CI+tester+staging → ложно маршрутизировался
-как код-фейл (откат `deploy-staging → development` + расход developer-retry) → manual-gate. Прогон
-регресса подтверждает: инфра-таймаут толерируется (D1…D6), tree-kill устраняет утечку, красный re-test
-по-прежнему откатывает.
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-110-bug-merge-gate-local-re-test-t`
-- Branch: `feature/ORCH-110-bug-merge-gate-local-re-test-t` (HEAD `5391c8b`; fix-коммит `b80edf3`)
-- Дата: 2026-06-15
-
-## Smoke API (read-only)
-| Эндпоинт | Результат |
-|----------|-----------|
-| `GET /health` | `{"status":"ok","service":"orchestrator"}` — OK |
-| `GET /status` | OK; задача ORCH-110 (id=100) на стадии `testing`, `agent_running=null` |
-| `GET /queue` | OK; блок `serial_gate` присутствует ✓ (наряду с `auto_labels` ✓); полезная нагрузка не деградировала |
-
-> Прим.: блок `merge_gate` (новая наблюдаемость ORCH-110, FR-6) в проде (8500) ещё отсутствует — это
-> ожидаемо, фича не задеплоена (задача на стадии `testing`). В коде ветки блок присутствует и покрыт
-> тестом TC-12 (`test_tc12_queue_endpoint_includes_merge_gate_block`). Регресса смока нет.
-
-## Результаты (покрытие ТЗ: каждый TC из 04-test-plan.yaml ↔ 03-acceptance-criteria.md)
-
-| TC ID | Описание | AC | Модуль | Результат |
-|-------|----------|----|--------|-----------|
-| TC-01 | `retest_branch`: таймаут → `(False, 're-test timeout after <T>s')` + tree-kill всего дерева (внуки не переживают) | AC-4 (BR-3) | test_orch110_retest_lifecycle.py | PASS |
-| TC-02 | `coverage_gate.measure_coverage`: таймаут → tree-kill дерева; возврат `None` сохранён | AC-4 (BR-3) | test_orch110_retest_lifecycle.py | PASS |
-| TC-03 | `classify_retest_failure`: `timeout` различим от `red`/`lock-busy`/`other` (имя/семантика `check_*` целы) | AC-2 | test_orch110_merge_gate_classify.py | PASS |
-| TC-04 | Маршрутизация: инфра-таймаут → defer/повтор/инфра-alert (НЕ `_handle_merge_gate_rollback`, без developer-retry) | AC-1 | test_orch110_merge_gate_routing.py | PASS |
-| TC-05 | Анти-над-толерантность: красный/конфликт re-test → откат на `development` + developer-retry + release lease (BR-6) | AC-3 | test_orch110_merge_gate_routing.py | PASS |
-| TC-06 | Anti-loop: повторы лимитированы по попыткам/времени; исчерпание → один инфра-alert | AC-9 | test_orch110_merge_gate_routing.py | PASS |
-| TC-07 | Kill-switch off → байт-в-байт прежнее (таймаут → rollback); not-self repo (enduro) → no-op | AC-7 | test_orch110_killswitch.py | PASS |
-| TC-08 | Бюджет: malformed/непозитив → дефолт 900 + WARNING; `reaper_max_running_s (5400) > Σ+grace`; `reaper_max_running_s` не тронут | AC-5 | test_orch110_budget_invariants.py | PASS |
-| TC-09 | never-raise: ошибка транзиент-пути → безопасный дефолт + WARNING; исключение не уходит в `advance_stage` | AC-8 | test_orch110_merge_gate_routing.py | PASS |
-| TC-10 | РЕГРЕСС инцидента: no-op rebase → skip+advance; catch-up timeout → infra-retry (НЕ rollback); красный → rollback (red-before/green-after) | AC-10 | test_orch110_false_rollback_regression.py | PASS |
-| TC-11 | Контракт необходимости re-test: no-op rebase → skip (lease HELD); HEAD сдвинулся / неопределённость SHA → re-test (fail-safe) | AC-6 | test_orch110_retest_contract.py | PASS |
-| TC-12 | Наблюдаемость: счётчики + блок `merge_gate` в `GET /queue`; инфра-alert кликабелен и отличим от код-фейла; без дубля ORCH-111 | AC-9 (FR-6) | test_orch110_observability.py | PASS |
-
-Все 12 TC выполнены и сопоставлены с критериями приёмки AC-1…AC-10. FAIL/непокрытых TC нет.
-
-## Вывод pytest
-
-### ORCH-110-специфичные модули (verbose)
-```
-collected 55 items
-tests/test_orch110_retest_lifecycle.py ........  (TC-01, TC-02)
-tests/test_orch110_merge_gate_classify.py ........  (TC-03)
-tests/test_orch110_merge_gate_routing.py ........  (TC-04, TC-05, TC-06, TC-09)
-tests/test_orch110_killswitch.py ....  (TC-07)
-tests/test_orch110_budget_invariants.py .........  (TC-08)
-tests/test_orch110_false_rollback_regression.py ...  (TC-10)
-tests/test_orch110_retest_contract.py ......  (TC-11)
-tests/test_orch110_observability.py .....  (TC-12)
-======================== 55 passed, 1 warning in 15.17s ========================
-```
-
-### Полный регресс
-```
-$ cd /repos/_wt/orchestrator/feature_ORCH-110-bug-merge-gate-local-re-test-t && python3 -m pytest tests/ -q --tb=short
-........................................................................ [100%]
-1988 passed, 1 warning in 346.71s (0:05:46)
-```
-(Единственное warning — `PydanticDeprecatedSince20` в `src/config.py:8`, предсуществующее, не связано
-с ORCH-110.)
-
-## Итог
-PASS
-
-- Полный регресс `pytest tests/` — **1988 passed** (0 failed).
-- Все 12 TC из `04-test-plan.yaml` выполнены, сопоставлены с `03-acceptance-criteria.md` (AC-1…AC-10) — **PASS**.
-- Smoke API read-only (`/health`, `/status`, `/queue`) — OK; блоки `serial_gate` и `auto_labels` присутствуют.
-- Review-вердикт — `APPROVED`.
-
-**Вердикт: `result: PASS`** → задача переходит на `deploy-staging`.

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

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

@@ -1,32 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-110
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-timestamp: 2026-06-15T07:40:28Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live staging environment (port 8501).
-
-**Execution:** canonical run INSIDE `orchestrator-staging` via the Docker Engine API
-exec endpoint (ORCH-048/ADR-001):
-`python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`.
-
-**Result:** 8/10 checks PASS, exit code **0** → advance.
-
-- REAL checks (A1–A3 SMOKE, B4–B6 ACCESS, C7–C8 E2E): all green.
-  - B6 registry-isolation: `sandbox=YES, prod-ET=NO, prod-ORCH=NO` (instance built registry
-    from its own `.env.staging` process-env — correct canonical-run behaviour).
-- SANDBOX_INFRA checks (C9a/C9b): FAIL, **waived** under ORCH-061 infra-tolerance
-  (known sandbox-infra; depend on SANDBOX bot accounts being project members, not on the
-  pipeline). All REAL checks green → exit 0.
-
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-
-VERDICT: SUCCESS (exit 0) — 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-111/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: BUG: watchdog must alert on long-lived pytest/child processes that block the pipeline
-
-Work Item ID: ORCH-111
-
-## Description
-
-TBD

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

@@ -1,145 +0,0 @@
----
-work_item: ORCH-111
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-15
-model_used: claude-opus-4-8
-escalate: full-cycle
----
-
-# 01 — BRD (бизнес-требования): ORCH-111 — watchdog должен алертить на долго живущие pytest/дочерние процессы, блокирующие конвейер
-
-Work Item: **ORCH-111** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в полный цикл**
-
-> **Эскалация (`escalate: full-cycle`).** Задача пришла как баг (`BUG:` в заголовке), но **не**
-> является дешёвым багфиксом: закрытие пробела требует **архитектурного решения** — у sidecar-watchdog
-> сейчас **нет видимости процессов хоста вообще** (`network_mode: host`, но без `pid: host` и без
-> bind-mount `/proc`). Выбор механизма наблюдения (расширение привилегий sidecar vs обогащение
-> контракта `/metrics` орком) — это развилка с последствиями для безопасности и стабильного контракта
-> `/metrics` (schema_version, ORCH-099). Поэтому пакет — **полный** (а не lite-bug), и задача
-> помечена `escalate: full-cycle`: нужен прогон стадии `architecture` + ADR (механизм видимости,
-> эвристика детекции, привилегии/безопасность). Оператор снимает багфикс-трек эндпоинтом
-> `POST /bug-fast-track/escalate?work_item=ORCH-111` (ADR-001 D5, ORCH-019).
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1 Симптом (установленный факт)
-На хосте прода были обнаружены старые зависшие процессы `python3 -m pytest tests/test_install_lite_script.py`,
-которые жили **более 2 суток**, грузили CPU и мешали локальному merge-gate re-test. Из-за конкуренции
-за CPU задача **ORCH-109 несколько раз упиралась** в `re-test timeout after 600s`
-(`merge_gate.retest_branch`). Сами эти процессы **не были подняты как отдельный alert** watchdog'а —
-оператор узнал о них случайно.
-
-### 1.2 Локализация
-- **Мониторинг-мозг** — sidecar-watchdog (ORCH-100, каталог `watchdog/`, сервис `orchestrator-watchdog`).
-  Он уже алертит на `stage_stuck` (стадия задачи застряла) и `container_down` (контейнер не в норме),
-  а также `agent_hung`, `orch_down`, `host_mem`, `queue_depth`, `job_failed`, `dep_down`.
-- **Сигнал `agent_hung`** (`watchdog/signals.py::eval_envelope`) покрывает **только running-агент-джобы**:
-  он читает раздел `agents[]` из `GET /metrics`, а тот строится `src/metrics.py::_build_agents` по
-  `db.get_running_agents()` — то есть **только по `jobs.pid` активных джобов**.
-- **Источник зависших процессов** — субпроцессы pytest, которые орк запускает в worktree:
-  `merge_gate.retest_branch` (`python -m pytest <target>`) и `coverage_gate.measure_coverage`
-  (`pytest --cov=src`). При `subprocess.TimeoutExpired` Python убивает прямого ребёнка, но
-  **внуки/репарентированные процессы переживают**; а если сам агент-процесс убит по таймауту
-  (`exit_code=-9`, ORCH-109) — его дочерний pytest **репарентируется на PID 1** и продолжает жить.
-
-### 1.3 Причина (root cause)
-Между двумя наблюдателями зияет **слепая зона**: `agent_hung` видит лишь *отслеживаемые* агент-джобы
-(по `jobs.pid`), а **осиротевшие/внебюджетные тестовые субпроцессы** (внуки pytest, репарентированные
-на PID 1) **не присутствуют ни в `/metrics`, ни в поле зрения sidecar** — у контейнера watchdog нет
-доступа к таблице процессов хоста. Поэтому долго живущий pytest, реально блокирующий конвейер через
-CPU-голодание merge-gate, **не порождает ни одного сигнала**, пока формально ни одна стадия задачи не
-«застряла».
-
-## 2. Объём (scope)
-
-### В объёме
-- Новый **отдельный класс алерта** watchdog'а: «долго живущий тестовый/дочерний процесс блокирует
-  конвейер» — поднимается, даже если стадия задачи формально не `stuck`.
-- Детекция долго живущих процессов тест-класса (pytest и родственные субпроцессы гейтов), переживших
-  свой бюджет/осиротевших, на хосте прода.
-- Актуализация конфиг-канона watchdog (`.env.watchdog.example` / блок `WATCHDOG_*` в `.env.example`)
-  и наблюдаемости.
-
-### Вне объёма
-- **Любая реакция на процесс** (kill/SIGTERM/cleanup/reap/перезапуск). Задача — **только мониторинг +
-  сигнализация** (явное ограничение заказчика). Автоматический reap осиротевших процессов — **отдельная
-  задача**.
-- Изменение конвейера: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict / схема БД — **не
-  трогаются** (watchdog — наблюдатель вне процесса орка и вне Quality Gates).
-- Расширение `agent_hung` на нетреканые процессы (это другой класс сигнала; дубль запрещён — см. NFR-4).
-- Снятие первопричины осиротения процессов в самом орке (надёжный reap внуков pytest) — ценно, но это
-  **ремедиация**, она вне объёма этой задачи.
-
-## 3. Заинтересованные стороны
-- **Заказчик/оператор прода** (Слава) — получает ранний сигнал о CPU-голодании ещё до того, как оно
-  завалит merge-gate re-test очередной задачи.
-- **Self-hosting конвейер orchestrator** — страдает напрямую (инцидент ORCH-109).
-- **Тиражные инсталляции (Lite/Bundled, ORCH-102/103)** — sidecar входит в дефолтный комплект; новый
-  сигнал должен укладываться в канон конфига и не ломать тираж.
-- **Принимает результат** — reviewer/tester + оператор (smoke на staging-эквиваленте sidecar).
-
-## 4. Бизнес-требования (BR)
-- **BR-1** — Watchdog поднимает **отдельный, узнаваемый** alert, когда на хосте обнаружен долго живущий
-  процесс тест-класса (pytest и его субпроцессы), возраст которого превышает настраиваемый порог —
-  **независимо** от того, застряла ли формально какая-либо стадия задачи.
-- **BR-2** — Текст алерта **действенно идентифицирует** виновника: фрагмент командной строки, PID,
-  возраст процесса и (при наличии) доля CPU — чтобы оператор мог сразу разобраться и вручную вмешаться.
-- **BR-3** — **Только мониторинг + сигнализация.** Watchdog **не убивает / не останавливает / не шлёт
-  сигналы** процессу и не выполняет иную ремедиацию (жёсткое ограничение заказчика, рамка C-1
-  «наблюдатель строго read-only к наблюдаемому», ORCH-100).
-- **BR-4** — **Без ложных срабатываний** на легитимных in-flight прогонах: тестовый процесс,
-  принадлежащий **активному отслеживаемому** агенту/гейту в пределах его бюджета, alert поднимать
-  **не должен**.
-- **BR-5** — Анти-спам и recovery как у прочих сигналов: один alert на пересечение порога, throttled
-  re-alert по cooldown, однократный recovery при исчезновении процесса (переиспользовать
-  `watchdog/decision.py::decide` + `AlertState`).
-- **BR-6** — Сигнал под **kill-switch** и управляется конфигом (порог возраста, cooldown, область).
-  Дефолт выбирается так, чтобы включение было **осознанным** и **self-hosting-безопасным** (см. NFR-3).
-
-## 5. Нефункциональные требования (NFR)
-- **NFR-1 (надёжность)** — **never-raise** на всех новых путях (per-source / per-tick / per-send), как
-  и весь watchdog: сбой коллектора процессов деградирует ОДИН сигнал, а не роняет тик.
-- **NFR-2 (read-only)** — строго наблюдение: **ни одного** управляющего действия над процессами/хостом
-  (нет `kill`/`signal`/`Popen`/записи). Соответствует C-1 (observer separated from observed).
-- **NFR-3 (self-hosting безопасность)** — выкат изменения **не перезапускает** прод-контейнер
-  `orchestrator` (встанет конвейер всех проектов): пересобирается/рестартится **только** контейнер
-  `orchestrator-watchdog`. Если механизм требует расширения привилегий sidecar (напр. `pid: host`) —
-  это привилегия **только наблюдателя**, обоснование и риски — задача архитектора (ADR).
-- **NFR-4 (без дубля)** — новый сигнал **не пересекается** с `agent_hung` (тот уже покрывает
-  отслеживаемые агент-джобы): новый сигнал закрывает ровно пробел «нетреканый/осиротевший процесс».
-- **NFR-5 (канон тиража)** — при изменении compose / ключей `.env.watchdog` обновить в **том же PR**:
-  `.env.watchdog.example`, блок `WATCHDOG_*` в `.env.example`, `docs/deployment/LITE_SETUP.md` и
-  `docs/architecture/README.md` (норматив сопровождения ORCH-102 NFR-5; key-set-sync тест).
-- **NFR-6 (стек)** — sidecar остаётся **stdlib-only** (C-3, ORCH-100): без новых сторонних зависимостей.
-
-## 6. Допущения и ограничения
-- **Ключевое архитектурное допущение (для архитектора):** у контейнера `orchestrator-watchdog` сейчас
-  **нет** видимости процессов хоста (`network_mode: host`, но без `pid: host` и без mount `/proc`).
-  Закрытие пробела требует выбора механизма — **развилка, решаемая ADR**, не аналитиком. Кандидаты
-  (перечислены как материал для решения, **без навязывания**): (a) расширение привилегий sidecar —
-  `pid: host` либо read-only mount хостового `/proc`, затем stdlib-скан таблицы процессов; (b)
-  обогащение `/metrics` орком новым read-only разделом о «бесхозных» тест-субпроцессах (орк видит свой
-  PID-namespace), который sidecar лишь читает. У каждого — свои trade-off'ы (привилегии vs контракт
-  `/metrics`).
-- `/metrics` — **версионированный контракт** (`schema_version`, ORCH-099): если выбран путь (b),
-  аддитивные изменения **не бампят** версию (sidecar обязан толерировать).
-- Порог возраста для детекции **должен превышать** максимальный легитимный бюджет тест-прогона
-  (`merge_retest_timeout_s` ≈ 600s, `coverage_run_timeout_s`), чтобы нормальный прогон **никогда** не
-  алертил, а 2-суточный осиротевший pytest — гарантированно (анти-false-positive, материал для ADR).
-- enduro-trails не затронут: watchdog наблюдает хост/орк self-hosting; сигнал config-gated.
-
-## 7. Критерии успеха
-Watchdog при наличии долго живущего pytest/дочернего процесса, грузящего CPU, **поднимает отдельный
-alert** в свой Telegram-канал (с PID/cmd/возрастом), **не трогая** процесс; при отсутствии такого
-процесса (или выключенном флаге) — молчит; нормальный тест-прогон под активным джобом **не** триггерит
-ложный alert. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-- **Ложные срабатывания** на легитимном длинном прогоне → спам в канал (митигируется порогом >
-  макс. бюджета + корреляцией с активным джобом).
-- **Расширение привилегий sidecar** (если выбран `pid: host`/`/proc`-mount) → увеличение поверхности
-  безопасности наблюдателя (требует явного обоснования в ADR; дефолт-off).
-- **Дубль с `agent_hung`** при небрежной реализации (NFR-4).
-- Детали и владельцы рисков — `10-tech-risks.md` (заполняет архитектор).