deploy(ORCH-036): finalize SUCCESS for ORCH-020

Coverage-gate failed (measured 79.48% < baseline 80.45%−ε) because the new
ORCH-020 estimator code added ~1500 lines but the happy-path TC-01..TC-20 suite
left the leaf's never-raise/fail-safe arms uncovered.

Adds tests/test_orch020_estimator_branches.py (46 cases) targeting the untested
branches of the new code only — no src/ change:
  * estimator.py: applies/should_estimate error arms, _sp_thresholds malformed +
    non-ascending fall-through, story_points_for bad input, _forecast history
    (full-samples + bootstrap blend), _resolve_task_and_track (repo-from-task +
    never-raise), estimate()/record_actual_on_done/_task_wall_seconds/_comment_text/
    card_line/snapshot except arms (74% -> 99.5%);
  * db.completed_task_stats history/zero-wall arms;
  * plane_sync estimate-system writes (non-int, guard-block, estimate-points parse
    via mocked httpx, no-estimate-system, network error);
  * main.py optional /estimate POST+GET endpoints;
  * webhooks.plane.handle_estimate degenerate paths (no id, seq-derive fallback).

src/ line coverage 79.48% -> 80.68% (>= baseline 80.45%); full suite green (2294).

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

.env

@@ -1,10 +0,0 @@
-ORCH_PLANE_API_URL=http://plane-app-api-1:8000
-ORCH_PLANE_API_TOKEN=
-ORCH_PLANE_WORKSPACE_SLUG=
-ORCH_PLANE_WEBHOOK_SECRET=
-ORCH_GITEA_URL=http://localhost:3000
-ORCH_GITEA_TOKEN=c81227b0dee2217f9ab3d28c3642a4578a1b9772
-ORCH_GITEA_WEBHOOK_SECRET=
-ORCH_CLAUDE_BIN=/usr/bin/claude
-ORCH_REPOS_DIR=/home/slin/repos
-ORCH_DB_PATH=/app/data/orchestrator.db

.env.example

@@ -1,10 +1,786 @@
 ORCH_PLANE_API_URL=http://plane-app-api-1:8000
+# External (browser) web URL of Plane for clickable issue links in notifications
+# (ORCH-017). Falls back to ORCH_PLANE_API_URL; a loopback fallback is treated as
+# "no web URL" and the Plane link is omitted. Example: https://plane.example.org
+ORCH_PLANE_WEB_URL=
 ORCH_PLANE_API_TOKEN=
 ORCH_PLANE_WORKSPACE_SLUG=
+# Webhook secrets are GENERATED PER HOST: python3 scripts/gen_secrets.py
+# (ORCH-101 / AC-5: production secrets are NEVER copied to a new host).
 ORCH_PLANE_WEBHOOK_SECRET=
 ORCH_GITEA_URL=http://localhost:3000
+# External (browser) URL of Gitea for clickable Branch/PR links in comments;
+# empty -> falls back to ORCH_GITEA_URL.
+ORCH_GITEA_PUBLIC_URL=
 ORCH_GITEA_TOKEN=
 ORCH_GITEA_WEBHOOK_SECRET=
+ORCH_GITEA_OWNER=admin
+# Per-agent Plane bot tokens (optional): when set, comments are posted under
+# the matching bot so Plane shows the real author; empty -> ORCH_PLANE_API_TOKEN.
+ORCH_PLANE_BOT_ANALYST=
+ORCH_PLANE_BOT_ARCHITECT=
+ORCH_PLANE_BOT_DEVELOPER=
+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=
+# ORCH-6: project registry — JSON array of {plane_project_id, repo,
+# work_item_prefix, name}. Empty -> built-in default registry (src/projects.py)
+# whose Plane UUIDs belong to the ORIGINAL host. On a NEW host this key is
+# MANDATORY (ORCH-101 replication checklist, docs/operations/REPLICATION.md).
+ORCH_PROJECTS_JSON=
 ORCH_CLAUDE_BIN=/usr/bin/claude
-ORCH_REPOS_DIR=/home/slin/repos
 ORCH_DB_PATH=/app/data/orchestrator.db
+
+# ── ORCH-101: host parametrization (replication foundation, ADR-001 D1–D7) ───
+# Every host-specific value lives HERE (defaults = the current production host;
+# an empty/absent value keeps behaviour 1:1). The same names are read by BOTH
+# pydantic Settings (env_file) and docker-compose ${VAR:-default} interpolation
+# (compose reads .env/shell, NOT a service's env_file). Full variable map and
+# the new-host procedure: docs/operations/REPLICATION.md.
+#   AGENT_HOME_DIR -> HOME of all actor subprocesses (agents/finalizer/monitor)
+#                     AND the target of the .claude/.claude.json/.ssh mounts AND
+#                     Dockerfile ARG APP_HOME (ORCH-040 group moves together).
+#   AGENT_GIT_NAME / GIT_EMAIL_DOMAIN -> git identity of agent commits; system
+#                     actors keep platform names deploy-finalizer/post-deploy-
+#                     monitor under the same domain.
+#   STAGING_PORT   -> staging instance port; image_freshness fail-closes when it
+#                     equals the prod port (ORCH-058 AC-9 guard).
+#   HOST_*         -> host-side sources of the bind mounts (repos, ~/.claude,
+#                     ~/.claude.json, ssh keydir, claude-code dist, node binary).
+#   RUN_UID/RUN_GID/DOCKER_GID -> container uid:gid + host docker group for
+#                     docker.sock access (group_add «МИНА 1», ORCH-040).
+ORCH_AGENT_HOME_DIR=/home/slin
+ORCH_AGENT_GIT_NAME=claude-bot
+ORCH_GIT_EMAIL_DOMAIN=mva154.local
+ORCH_STAGING_PORT=8501
+ORCH_HOST_REPOS_DIR=/home/slin/repos
+ORCH_HOST_CLAUDE_DIR=/home/slin/.claude
+ORCH_HOST_CLAUDE_JSON=/home/slin/.claude.json
+ORCH_HOST_SSH_DIR=/home/slin/.orchestrator-ssh
+ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
+ORCH_HOST_NODE_BIN=/usr/bin/node
+ORCH_RUN_UID=1000
+ORCH_RUN_GID=1000
+ORCH_DOCKER_GID=999
+
+# ── Agent model / effort / fallback (ORCH-41, validation ORCH-74) ─────────────
+# Per-agent LLM model + reasoning effort, resolved by launcher.resolve_agent_*.
+# Resolution priority (per agent): project-override (projects_json agent_models/
+# agent_efforts) > ORCH_AGENT_MODEL_<AGENT> / ORCH_AGENT_EFFORT_<AGENT> >
+# ORCH_AGENT_MODEL_DEFAULT / ORCH_AGENT_EFFORT_DEFAULT > CLI default (no flag).
+# The frontmatter `model:` in .openclaw/agents/*.md is DESCRIPTIVE only and is NOT
+# read — config below is the single source of truth for the model (ORCH-74 G1).
+#
+# ORCH-74 (G2): a resolved MODEL name is validated (^claude-…$ format check) before
+# it reaches --model. A structurally invalid name (typo, gpt-4, empty) is logged and
+# the next valid level is used (in the limit: no --model flag). Forward-compatible:
+# a future claude-* version passes without editing any allowlist. EFFORT is validated
+# against low|medium|high|xhigh|max (ORCH-41); an invalid effort is dropped.
+#
+# All 6 agents resolve to claude-opus-4-8 (model-routing G3 NOT enabled). Leave the
+# per-agent overrides empty to use the default. Do NOT hardcode the model version
+# anywhere except ORCH_AGENT_MODEL_DEFAULT.
+ORCH_AGENT_MODEL_DEFAULT=claude-opus-4-8
+ORCH_AGENT_MODEL_ANALYST=
+ORCH_AGENT_MODEL_ARCHITECT=
+ORCH_AGENT_MODEL_DEVELOPER=
+ORCH_AGENT_MODEL_REVIEWER=
+ORCH_AGENT_MODEL_TESTER=
+ORCH_AGENT_MODEL_DEPLOYER=
+# Effort split (ORCH-081/ORCH-52h): thinking agents (analyst/architect/reviewer)
+# -> high; developer -> xhigh (coding/agentic role, Opus 4.8 canon); mechanical
+# agents (tester/deployer) -> medium. NB: an empty ORCH_AGENT_EFFORT_*= no longer
+# zeroes the effort — the launcher falls back to a per-role floor (= the config.py
+# class-default) so each role still runs at its canonical level (ORCH-081).
+ORCH_AGENT_EFFORT_DEFAULT=high
+ORCH_AGENT_EFFORT_ANALYST=high
+ORCH_AGENT_EFFORT_ARCHITECT=high
+ORCH_AGENT_EFFORT_DEVELOPER=xhigh
+ORCH_AGENT_EFFORT_REVIEWER=high
+ORCH_AGENT_EFFORT_TESTER=medium
+ORCH_AGENT_EFFORT_DEPLOYER=medium
+# Optional --fallback-model used when the primary is overloaded. Empty -> no flag
+# (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
+# the last message in an active chat. edit -> the task card is edited in place
+# (editMessageText). One card per task in both modes. Any value other than "bump"
+# (incl. empty/garbage) -> edit.
+ORCH_TRACKER_MODE=bump
+# ORCH-067: best-effort live-overlay for the card status line. The offline core
+# (stage -> Plane status, In Review from the brd-clock) always works without network;
+# the overlay only fills in branches indistinguishable offline (Needs Input / Blocked /
+# Rejected / Cancelled / Deploying / Monitoring after Deploy) by reading the LIVE Plane
+# status with a short timeout + per-issue TTL cache. It NEVER blocks the pipeline and
+# NEVER raises.
+#   LIVE_STATUS         -> kill-switch (false -> offline core only).
+#   LIVE_STATUS_TTL_S   -> TTL (seconds) of the per-issue live-uuid cache (hot-path guard).
+#   LIVE_STATUS_TIMEOUT_S -> timeout (seconds) of a single live-GET on the render path.
+ORCH_TRACKER_LIVE_STATUS=true
+ORCH_TRACKER_LIVE_STATUS_TTL_S=60
+ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S=3
+# ORCH-043: merge-gate (auto-rebase onto current origin/main + re-test + merge-lock)
+# on the deploy-staging -> deploy edge. Deterministic sub-gate (no LLM) that catches
+# the branch up to the CURRENT origin/main, re-tests it, and serialises merges so two
+# green parallel branches can't break main.
+#   ENABLED   -> global kill-switch (false -> whole gate is a no-op pass).
+#   REPOS     -> CSV of repos where the gate is REAL; empty -> only the self-hosting
+#                repo (orchestrator); other repos -> conditional no-op (mirrors ORCH-35).
+#   RETEST_TIMEOUT_S -> wall-clock budget for the post-rebase re-test.
+#   RETEST_TARGET    -> pytest target for the re-test.
+#   LOCK_TIMEOUT_S   -> max merge-lease age before a stale lease is reclaimed.
+#   DEFER_DELAY_S    -> delay before re-running the gate when the lock is busy.
+#   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_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
+# the scheduler edge. No-op on an up-to-date branch (rebase keeps HEAD, force-with-
+# lease -> "Everything up-to-date", CI not triggered). Scope = ORCH_MERGE_GATE_REPOS.
+#   PREMERGE_REBASE_ALWAYS=false -> strictly pre-ORCH-026 (rebase only when behind).
+ORCH_PREMERGE_REBASE_ALWAYS=true
+# ORCH-026 Level B: declarative task dependencies ("B waits for A"). claim_next_job
+# gates jobs whose depends-on tasks are not yet 'done' (additive job_deps table,
+# NOT EXISTS) WITHOUT occupying a max_concurrency slot. Inert on an empty job_deps.
+#   TASK_DEPS_ENABLED=false -> claim query is 1:1 the ORCH-1 query (no gate).
+#   TASK_DEPS_SOURCE=db|plane|hybrid -> declaration source; db (default) never calls
+#     Plane on the hot path; plane/hybrid ingest Plane `blocked-by` relations and
+#     cache them into job_deps (the scheduler then reads only the DB).
+ORCH_TASK_DEPS_ENABLED=true
+ORCH_TASK_DEPS_SOURCE=db
+# ORCH-088 (Stage 1, serial e2e): per-repo serial gate. A NEW task's analyst-job does
+# NOT enter analysis (no branch cut, no analyst) while the same repo has an EARLIER
+# unfinished task (FIFO, tasks.id < the job's task) OR the repo is frozen. The branch
+# cut is DEFERRED from start_pipeline to the analyst-job claim so its base is a fresh
+# origin/main already containing the predecessor (anti-stale-base). Gate lives in
+# claim_next_job (offline hot-path, fail-OPEN on error); freeze (FR-5) is a durable
+# repo_freeze row set on post-deploy DEGRADED, cleared manually via
+# POST /serial-gate/unfreeze?repo=<repo>. Leaf src/serial_gate.py (never-raise).
+#   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)
+# routes to a cancel handler that drives the task to the system-terminal state
+# `cancelled` (stop agent via the graceful SIGTERM cascade, cancel all jobs, remove
+# worktree + delete the remote feature branch [never main / never force-push],
+# tombstone the natural keys for a clean re-create via "To Analyse"; docs preserved).
+# STOP during a critical merge/deploy window is DEFERRED until the irreversible step
+# finishes honestly. The relaunch-hole gate restricts the "To Analyse" agent relaunch
+# to the `analysis` stage (the sole Needs-Input owner). Additive, never-raise.
+# Infra precondition: create a "STOP" status with the `cancelled` group on the ORCH
+# board (07-infra-requirements.md). Leaf src/cancel.py.
+#   STOP_STATUS_ENABLED=false -> STOP handling AND the relaunch-hole gate are inert
+#                                (behaviour strictly as before ORCH-090).
+#   STOP_STATUS_REPOS (CSV)   -> scope; EMPTY = ALL repos (cancellation is meaningful
+#                                for enduro too).
+ORCH_STOP_STATUS_ENABLED=true
+ORCH_STOP_STATUS_REPOS=
+# ORCH-019: bug-fast-track — a cheaper/shorter pipeline route for bug-fix tasks.
+# A task carrying the Plane `Bug` label skips the whole `architecture` stage; EVERY
+# Quality Gate / sub-gate runs UNCHANGED (route is a scheduler property, not a gate).
+# Additive, never-raise, fail-safe -> full cycle. Infra precondition: create a `Bug`
+# label on the ORCH board (its absence = full cycle, fail-safe). Leaf src/bug_fast_track.py.
+#   BUG_FAST_TRACK_ENABLED=false -> start_pipeline AND advance_stage are 1:1 as before
+#                                   ORCH-019 (zero regression).
+#   BUG_FAST_TRACK_LABEL         -> Plane label that activates the track (default `Bug`).
+#   BUG_FAST_TRACK_REPOS (CSV)   -> scope; EMPTY = self-hosting only (orchestrator).
+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
+# Awaiting <-> Monitoring, EXCEPT the legitimate post-deploy Monitoring while the
+# window is active (ARMED & not DONE). Leaf src/deploy_status_guard.py, never-raise;
+# STAGE_TRANSITIONS / QG_CHECKS / machine-verdict keys untouched (no DB migration).
+#   DEPLOY_STATUS_GUARD_ENABLED=false -> setters are terminal-blind (1:1 pre-ORCH-094).
+#   DEPLOY_STATUS_GUARD_REPOS (CSV)   -> scope; EMPTY = self-hosting only (orchestrator),
+#                                        the only repo where deploy-phase statuses are set.
+ORCH_DEPLOY_STATUS_GUARD_ENABLED=true
+ORCH_DEPLOY_STATUS_GUARD_REPOS=
+# ORCH-071/073: merge-verify under-gate on the `deploy -> done` edge (врезка in
+# advance_stage, NOT a new STAGE_TRANSITIONS edge / registered QG). A deterministic
+# merge-actor merges the feature code-PR via the Gitea PR-merge API (never push/
+# force-push to main), then `done` is allowed ONLY when the deployed SHA is proven an
+# ancestor of origin/main (ORCH-073 FR-1: SHA-in-main is the single criterion; a
+# merged PR alone no longer confirms). A secondary regression guard then checks a
+# declarative marker set (MAIN_REGRESSION_MARKERS) is still in origin/main; a missing
+# marker -> alert + HOLD (NOT done), a git error of the grep itself -> fail-open.
+#   MERGE_VERIFY_ENABLED      -> global kill-switch (false -> strictly pre-ORCH-071).
+#   MERGE_VERIFY_REPOS        -> CSV of repos where the under-gate is REAL; empty ->
+#                                only the self-hosting repo (orchestrator); non-self -> no-op.
+#   MERGE_PR_TIMEOUT_S        -> per Gitea list/merge HTTP call timeout.
+#   MERGE_VERIFY_TIMEOUT_S    -> git fetch/merge-base timeout for the ancestor + marker checks.
+#   REGRESSION_GUARD_ENABLED  -> kill-switch for the ORCH-073 main-integrity regression
+#                                guard (false -> SHA-in-main alone gates done); reuses the
+#                                merge-verify scope, so non-self repos are a no-op.
+#   MERGE_VERIFY_AUTOCREATE_PR_ENABLED -> ORCH-082: guarantee an open code-PR
+#                                (head==branch, base==main) via merge_gate.ensure_open_pr
+#                                BEFORE the deterministic merge_pr (fixes the false HOLD
+#                                "no open PR"). false -> exactly pre-ORCH-082 behaviour.
+#                                Reuses the merge-verify scope; non-self repos -> no-op.
+ORCH_MERGE_VERIFY_ENABLED=true
+ORCH_MERGE_VERIFY_REPOS=
+ORCH_MERGE_PR_TIMEOUT_S=60
+ORCH_MERGE_VERIFY_TIMEOUT_S=60
+ORCH_REGRESSION_GUARD_ENABLED=true
+ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED=true
+# ORCH-093: deterministic merge-actor retry of TRANSIENT Gitea merge errors. merge_pr
+# wraps ONLY the mutating POST /pulls/{n}/merge in a bounded exponential-backoff
+# retry-loop on transient outcomes (405 "try again later" / 408 / 5xx / network /
+# timeout, and 409|422 while the PR is still mergeable); terminal outcomes
+# (403/404/real conflict) -> fast honest False (the ORCH-071/081 HOLD backstop is
+# unchanged). Fixes the ORCH-063 false HOLD + manual re-merge. The already-in-main
+# guard (no commits beyond origin/main -> no garbage PR) is always-on under
+# MERGE_VERIFY_AUTOCREATE_PR_ENABLED (no separate flag).
+#   MERGE_RETRY_ENABLED        -> kill-switch; false -> exactly one POST (one-shot, prior behaviour).
+#   MERGE_RETRY_MAX_ATTEMPTS   -> max POST attempts on a transient outcome.
+#   MERGE_RETRY_BACKOFF_BASE_S -> exponential backoff base seconds (sleep = base*2^(i-1)).
+#   MERGE_RETRY_BACKOFF_MAX_S  -> per-sleep backoff ceiling seconds (bounds total wait).
+ORCH_MERGE_RETRY_ENABLED=true
+ORCH_MERGE_RETRY_MAX_ATTEMPTS=3
+ORCH_MERGE_RETRY_BACKOFF_BASE_S=2
+ORCH_MERGE_RETRY_BACKOFF_MAX_S=5
+# ORCH-036: executable self-deploy of the `deploy` stage. For the self-hosting repo
+# (orchestrator) the stage REALLY restarts prod (8500) via a detached host hook;
+# deploy_status: SUCCESS means proven health-ok, not an LLM declaration. Three
+# deterministic phases (A: request approve, B: human Approved -> detached deploy,
+# C: finalizer maps hook exit-code -> deploy_status). Non-self repos: unchanged
+# synchronous ssh deploy. SECRETS / host paths live ONLY on the host — do NOT commit.
+#   SELF_DEPLOY_ENABLED -> global kill-switch (false -> legacy synchronous deploy for all).
+#   SELF_DEPLOY_REPOS   -> CSV of repos where Phase A/B/C is REAL; empty -> only the
+#                          self-hosting repo (orchestrator); others -> no-op (mirrors ORCH-35).
+#   DEPLOY_REQUIRE_MANUAL_APPROVE -> require a human Plane "Approved" before the prod
+#                          deploy (true on rollout; full auto is ORCH-54).
+#   DEPLOY_FINALIZE_DELAY_S       -> delay before the first/each finalize poll (>= hook+health).
+#   DEPLOY_FINALIZE_MAX_ATTEMPTS  -> bounded finalize-defer budget (anti-livelock).
+#   DEPLOY_SSH_USER / DEPLOY_SSH_HOST -> ssh target for the host hook (DEPLOY_SSH_HOST
+#                          empty -> detached deploy will NOT launch; set on the host).
+#   DEPLOY_HOOK_SCRIPT            -> path to the hook ON THE HOST (relative to the repo).
+#   DEPLOY_HOST_REPO_PATH         -> orchestrator clone path on the host.
+#   DEPLOY_PROD_SOURCE_IMAGE      -> staging-validated image, retagged build-once (no rebuild).
+#   DEPLOY_PROD_TARGET_SERVICE / _PORT / _IMAGE / _COMPOSE_PROFILE -> prod compose profile.
+#   DEPLOY_PROD_PREV_IMAGE_FILE   -> prod prev-image snapshot (separate from staging's).
+ORCH_SELF_DEPLOY_ENABLED=true
+ORCH_SELF_DEPLOY_REPOS=
+ORCH_DEPLOY_REQUIRE_MANUAL_APPROVE=true
+ORCH_DEPLOY_FINALIZE_DELAY_S=90
+ORCH_DEPLOY_FINALIZE_MAX_ATTEMPTS=10
+ORCH_DEPLOY_SSH_USER=slin
+ORCH_DEPLOY_SSH_HOST=
+ORCH_DEPLOY_HOOK_SCRIPT=scripts/orchestrator-deploy-hook.sh
+ORCH_DEPLOY_HOST_REPO_PATH=/home/slin/repos/orchestrator
+ORCH_DEPLOY_PROD_SOURCE_IMAGE=orchestrator-orchestrator-staging
+ORCH_DEPLOY_PROD_TARGET_SERVICE=orchestrator
+ORCH_DEPLOY_PROD_TARGET_PORT=8500
+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:
+#   A (liveness): QG sub-check `check_staging_image_fresh` on the deploy-staging->deploy
+#     edge rebuilds orchestrator-orchestrator-staging from the validated commit + recreates
+#     8501; FAIL -> rollback to development. (builds/recreate STAGING only, never prod.)
+#   B (safety):  the Dockerfile stamps `org.opencontainers.image.revision`; the prod hook
+#     fail-closes (exit 1) before `docker tag` if SOURCE_IMAGE's label != EXPECTED_REVISION.
+#   ENABLED -> single kill-switch for A+B as a WHOLE (never "B without A"); false -> legacy.
+#   REPOS   -> CSV of repos where the gate is REAL; empty -> only self-hosting (orchestrator).
+ORCH_IMAGE_FRESHNESS_ENABLED=true
+ORCH_IMAGE_FRESHNESS_REPOS=
+
+# ORCH-061: staging-verdict tolerance to sandbox-infra-only FAILs. The self-hosting
+# orchestrator looped on deploy-staging because staging_check.py exited 1 on ANY FAIL,
+# so two infra-only checks (C9a sandbox branch / C9b analyst-job — caused by SANDBOX
+# bot accounts not being members of the sandbox Plane project, NOT a pipeline regress)
+# forced staging_status: FAILED -> rollback -> loop. With this ON, C9a/C9b are WAIVED
+# to SUCCESS when every REAL check is green; any REAL failure still fails closed.
+#   true (default) -> tolerant; false -> legacy strict (1:1 pre-ORCH-061, any FAIL rolls back).
+# Lives in .env.staging (the staging instance). CLI --strict overrides this per-run.
+ORCH_STAGING_INFRA_TOLERANCE_ENABLED=true
+
+# ORCH-053: stuck-task reconciler (sweeper for lost webhooks). A background daemon
+# replays a missed stage transition through the SAME gates/handlers a webhook would,
+# fixing tasks that got stuck on a dropped event (502 on rebuild, no Plane/Gitea
+# retries, unresolved sha->branch).
+#   ENABLED            -> global kill-switch (self-hosting safety / staged rollout).
+#   PLANE_ENABLED      -> separate flag for the F-2 Plane-API poll (mute only F-2).
+#   INTERVAL_S         -> background sweep period (seconds).
+#   GRACE_DEFAULT_S    -> default "stuck" threshold on tasks.updated_at (seconds).
+#   GRACE_OVERRIDES_JSON -> per-stage thresholds, e.g. {"development":300}; bad JSON -> default.
+#   NOTIFY_UNBLOCK     -> send a Telegram message when a stuck task is unblocked.
+#   SKIP_BLOCKED_ENABLED -> ORCH-060 F-1 Guard 2: skip reconciling issues a human moved
+#                        to Blocked / Needs Input (per-candidate Plane state lookup).
+#                        false mutes ONLY the networked Guard 2; Guard 1 (escalated by
+#                        developer retries, local+deterministic) is always active.
+ORCH_RECONCILE_ENABLED=true
+ORCH_RECONCILE_PLANE_ENABLED=true
+ORCH_RECONCILE_INTERVAL_S=120
+ORCH_RECONCILE_GRACE_DEFAULT_S=600
+ORCH_RECONCILE_GRACE_OVERRIDES_JSON=
+ORCH_RECONCILE_NOTIFY_UNBLOCK=true
+ORCH_RECONCILE_SKIP_BLOCKED_ENABLED=true
+
+# ORCH-068: TTL (seconds) for the per-project Plane states cache (plane_sync
+# _STATES_CACHE). Historically the cache lived for the whole process lifetime,
+# so a status added to Plane after start was invisible until a restart
+# ("stale set -> no pipeline action"). With a TTL the entry self-heals by
+# re-fetching /states/ once it expires (reuses reload_project_states()).
+#   >0  -> re-fetch after this many seconds (default 300 = 5 min);
+#   0   -> disable TTL -> strictly the previous lifetime cache (back-compat).
+ORCH_PLANE_STATES_TTL_S=300
+
+# ORCH-065: job-reaper + proactive merge-lease reclaim. A background daemon thread
+# (src/job_reaper.py, started LAST in main.lifespan after requeue_running_jobs) reaps
+# zombie 'running' jobs whose monitor/process died before writing the terminal status
+# (one zombie at max_concurrency=1 blocks the whole shared queue) and periodically
+# reclaims dead/stale merge-leases. Liveness is three-tier: Tier-1 dead jobs.pid
+# (os.kill(pid,0)) after REAPER_DEAD_TICKS consecutive dead ticks (anti-false-positive
+# for a live agent); Tier-2 agent_runs.exit_code recorded but job still 'running'
+# (only after a REAPER_FINALIZE_GRACE_S finalization grace, so a live monitor still
+# doing git push / PR / Plane comments is never reaped); Tier-3 backstop after
+# REAPER_MAX_RUNNING_S. The terminal flip carries an atomic status='running' guard and
+# precedes any advance/enqueue (claim-before-act) so it never double-processes/-advances
+# a row racing a late monitor or requeue_running_jobs.
+#   REAPER_ENABLED          -> global kill-switch (false -> strictly prior behaviour).
+#   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).
+#   LEASE_RECLAIM_ENABLED   -> kill-switch for the proactive stale/dead lease reclaim
+#                              (false -> only the legacy lazy TTL reclaim in acquire_merge_lease).
+# (reuse) ORCH_MERGE_LOCK_TIMEOUT_S -> lease TTL; ORCH_MERGE_GATE_REPOS -> reclaim scope.
+ORCH_REAPER_ENABLED=true
+ORCH_REAPER_INTERVAL_S=60
+ORCH_REAPER_DEAD_TICKS=2
+ORCH_REAPER_MAX_RUNNING_S=5400
+ORCH_REAPER_FINALIZE_GRACE_S=300
+ORCH_LEASE_RECLAIM_ENABLED=true
+
+# ORCH-126 (adr-0052): run-ownership hygiene of the `jobs` row — invariant
+# `status='queued' => run_id IS NULL AND pid IS NULL AND started_at IS NULL`. The BASE
+# reset on every requeue/claim path (requeue_running_jobs / mark_job('queued') /
+# mark_job_transient / reap_running_job('queued') / claim_next_job) is UNCONDITIONAL
+# (no flag — it fixes a data invariant). This kill-switch gates ONLY the optional
+# detect/self-heal sweep of "impossible" queued rows (a queued job still carrying
+# run_id/pid/started_at — the incident state of job 2286) run at startup + on each
+# reaper tick, plus its read-only /queue counter (reaper.impossible_queued_total).
+#   IMPOSSIBLE_QUEUED_SANITIZE_ENABLED -> default true; false -> the sweep is a no-op
+#                                         (D1-D3 still enforce the invariant going forward).
+ORCH_IMPOSSIBLE_QUEUED_SANITIZE_ENABLED=true
+
+# ORCH-114 (adr-0045): durable transition-ownership lease + expected-stage CAS for
+# side-effectful stage transitions. Generalises the process-local ORCH-113 finalizer-
+# liveness into a DURABLE, cross-path owner-exclusion (additive table `transition_lease`)
+# 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
+# mva154 host disk silently hit 100% and stalled the WHOLE self-hosting pipeline;
+# this is the missing proactive signal. Daemon thread modelled on reconciler/reaper
+# (start/stop in main.lifespan, /queue snapshot, never-raise). Anti-spam state is
+# in-memory (no DB migration); the watchdog only READS fill and SENDS Telegram — it
+# never touches the disk/container or restarts prod (self-hosting safety).
+#   DISK_MONITOR_ENABLED       -> kill-switch; false -> the daemon does not start (1:1 as before).
+#   DISK_MONITOR_INTERVAL_S    -> heartbeat measurement period, seconds (order of minutes).
+#   DISK_MONITOR_THRESHOLD_PCT -> fill % that triggers the alert (Owner-fixed 85; valid 1..100).
+#   DISK_MONITOR_REALERT_S     -> cooldown between repeat alerts while above threshold (~6h).
+#   DISK_MONITOR_PATHS         -> CSV of monitored HOST bind-paths; empty -> /repos,/app/data.
+ORCH_DISK_MONITOR_ENABLED=true
+ORCH_DISK_MONITOR_INTERVAL_S=300
+ORCH_DISK_MONITOR_THRESHOLD_PCT=85
+ORCH_DISK_MONITOR_REALERT_S=21600
+ORCH_DISK_MONITOR_PATHS=/repos,/app/data
+
+# ORCH-062: build-cache-pruner — the "second half" of the disk-watchdog
+# (watchdog SIGNALS, pruner CLEANS). A daemon thread modelled on disk_watchdog
+# that periodically runs STRICTLY `docker builder prune -f --filter until=<until>`
+# on the HOST over ssh (BuildKit GC). Touches ONLY the build cache: never
+# images/containers of running services, never restarts the docker daemon or the
+# prod container (self-hosting safety). State is in-memory (no DB migration). No
+# ssh host configured -> the tick is a no-op. See docs/operations/INFRA.md.
+#   BUILD_CACHE_PRUNE_ENABLED       -> kill-switch; false -> the daemon does not start (1:1 as before).
+#   BUILD_CACHE_PRUNE_INTERVAL_S    -> tick period, seconds (order of hours; default ~6h). >0, else default.
+#   BUILD_CACHE_PRUNE_UNTIL         -> retention age for the warm cache (`--filter until=`); ^\d+[smhdw]?$, else 24h.
+#   BUILD_CACHE_PRUNE_ALL           -> add `-a` (ALWAYS paired with until); default false.
+#   BUILD_CACHE_PRUNE_TIMEOUT_S     -> bound on the ssh command, seconds. >0, else default.
+#   BUILD_CACHE_PRUNE_NOTIFY_MIN_GB -> Telegram when reclaimed >= N GB; 0 -> silent.
+ORCH_BUILD_CACHE_PRUNE_ENABLED=true
+ORCH_BUILD_CACHE_PRUNE_INTERVAL_S=21600
+ORCH_BUILD_CACHE_PRUNE_UNTIL=24h
+ORCH_BUILD_CACHE_PRUNE_ALL=false
+ORCH_BUILD_CACHE_PRUNE_TIMEOUT_S=120
+ORCH_BUILD_CACHE_PRUNE_NOTIFY_MIN_GB=0
+
+# ORCH-022: security-gate (secret-scanning + dependency audit) on the
+# deploy-staging -> deploy edge, run FIRST among the edge sub-gates. Deterministic
+# (no LLM): gitleaks (offline secret-scan, pinned Go binary in the image) + pip-audit
+# (OSV/PyPI CVE audit). Verdict in the versioned 17-security-report.md frontmatter;
+# FAIL -> rollback to development + developer-retry (cap 3). See ADR-001.
+#   GATE_ENABLED          -> global kill-switch; false -> pipeline 1:1 as before ORCH-022.
+#   GATE_REPOS            -> CSV of repos where the gate is REAL; empty -> only self-hosting.
+#   DEP_BLOCK_SEVERITY    -> CVE severity that BLOCKS (CRITICAL>HIGH>MEDIUM>LOW); below /
+#                            UNKNOWN -> warning only (anti-loop).
+#   SCAN_TIMEOUT_S        -> per external scanner call timeout.
+#   DEP_AUDIT_FAIL_CLOSED -> strict mode: unreachable CVE feed -> FAIL instead of the
+#                            default fail-open + warning (anti-loop). Default false.
+#   SECRETS_BLOCK         -> a found secret blocks (always true by default; the offline
+#                            secrets guarantee is unconditional).
+ORCH_SECURITY_GATE_ENABLED=true
+ORCH_SECURITY_GATE_REPOS=
+ORCH_SECURITY_DEP_BLOCK_SEVERITY=HIGH
+ORCH_SECURITY_SCAN_TIMEOUT_S=300
+ORCH_SECURITY_DEP_AUDIT_FAIL_CLOSED=false
+ORCH_SECURITY_SECRETS_BLOCK=true
+
+# ORCH-027: coverage-gate (deterministic test-coverage) on the deploy-staging ->
+# deploy edge, run AFTER the merge-gate and BEFORE image-freshness. Measures line
+# coverage of src/ with pytest-cov in the per-branch worktree, compares to an absolute
+# floor and/or the ratchet baseline of `main`; FAIL -> rollback to development +
+# developer-retry (cap 3). Verdict in the 18-coverage-report.md frontmatter
+# (coverage_status:). See ADR-001-coverage-gate.md.
+#   GATE_ENABLED       -> global kill-switch; false -> pipeline 1:1 as before ORCH-027.
+#   GATE_REPOS         -> CSV of repos where the gate is REAL; empty -> only self-hosting.
+#   MIN_PERCENT        -> absolute floor (% line coverage) for policy absolute/both.
+#   POLICY             -> absolute | baseline | both (default both).
+#   EPSILON            -> noise tolerance (%) at the boundary (anti-flap).
+#   TOOL_FAIL_CLOSED   -> strict mode: a coverage-tool error -> FAIL instead of the
+#                         default fail-open + warning (anti-loop). Default false.
+#   RUN_TIMEOUT_S      -> wall-clock budget for the pytest --cov run.
+ORCH_COVERAGE_GATE_ENABLED=true
+ORCH_COVERAGE_GATE_REPOS=
+ORCH_COVERAGE_MIN_PERCENT=0.0
+ORCH_COVERAGE_POLICY=both
+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".
+# Three additive, kill-switch-reversible layers: an actionable RuntimeError in
+# ensure_worktree, a cheap never-raise detect leaf (src/fs_normalize.py) with a
+# startup WARNING/Telegram + GET /queue fs_ownership block, and an opt-in chown ONLY
+# when privileged (under uid 1000 a no-op; the real fix is the operator procedure in
+# docs/operations/INFRA.md «Миграция uid»). No STAGE_TRANSITIONS / QG_CHECKS / schema
+# change.
+#   ENABLED        -> kill-switch; false -> all code inert, behaviour 1:1 as before
+#                     ORCH-057 (the actionable error too).
+#   REPOS          -> CSV of repos the layer is REAL for; empty -> self-hosting only.
+#   TARGET_UID     -> target uid fallback when os.getuid() is unavailable.
+#   NORMALIZE_AUTO -> detect-only (false) | attempt chown when privileged (true).
+#   SCAN_ROOTS     -> CSV override of the scan roots (empty -> default roots).
+#   SCAN_CACHE_TTL_S -> TTL of the detect cache (mirrors ORCH_PREFLIGHT_CACHE_TTL).
+ORCH_FS_NORMALIZE_ENABLED=true
+ORCH_FS_NORMALIZE_REPOS=
+ORCH_FS_TARGET_UID=1000
+ORCH_FS_NORMALIZE_AUTO=false
+ORCH_FS_SCAN_ROOTS=
+ORCH_FS_SCAN_CACHE_TTL_S=300
+
+# ORCH-099 (FND/F1a): operator off-switch for the read-only GET /metrics endpoint
+# (raw-signal snapshot for the F1b sidecar). Default true -> available out of the
+# box. false -> /metrics returns a minimal parsable body {"schema_version":1,
+# "enabled":false} (200, not 404). The endpoint is inert / read-only anyway.
+ORCH_METRICS_ENABLED=true
+
+# ORCH-021: post-deploy production monitoring + degradation reaction. After the
+# terminal deploy->done transition for an applicable repo, a reserved-agent job
+# `post-deploy-monitor` (no LLM, modelled on deploy-finalizer) probes prod over a
+# window and reacts to a degradation the restart-time health-check missed (class
+# "green deploy, red prod", precedent ET-8). State is in sentinel files
+# (.post-deploy-state-<repo>/<wi>/), no DB migration.
+#   MONITOR_ENABLED  -> global kill-switch; false -> pipeline is 1:1 as before ORCH-021.
+#   REPOS            -> CSV of repos where monitoring is REAL; empty -> only self-hosting.
+#   WINDOW_S         -> observation window length (~15 min).
+#   INTERVAL_S       -> seconds between probe ticks.
+#   FAIL_THRESHOLD   -> N CONSECUTIVE health failures -> DEGRADED.
+#   5XX_THRESHOLD    -> window 5xx ratio above this -> DEGRADED.
+#   AUTO_ROLLBACK    -> allow auto-rollback; acts ONLY for non-self repos. Self-hosting
+#                       is ALWAYS ALERT_ONLY (a tick NEVER restarts the prod container).
+#   BASE_URL         -> base URL of the observed prod instance.
+ORCH_POST_DEPLOY_MONITOR_ENABLED=true
+ORCH_POST_DEPLOY_REPOS=
+ORCH_POST_DEPLOY_WINDOW_S=900
+ORCH_POST_DEPLOY_INTERVAL_S=30
+ORCH_POST_DEPLOY_FAIL_THRESHOLD=3
+ORCH_POST_DEPLOY_5XX_THRESHOLD=0.5
+ORCH_POST_DEPLOY_AUTO_ROLLBACK=false
+ORCH_POST_DEPLOY_BASE_URL=http://localhost:8500
+
+# ── QG-0 entry validation (ORCH-069) ──────────────────────────────────────────
+# Upper title-length limit for the QG-0 entry gate (_qg0_errors). The old 80-char
+# cap was a hygiene limit, not structural (slug is cut to [:30] independently, the
+# DB title TEXT is unbounded). Default 200. An invalid/empty value gracefully
+# degrades to 200 (the process never crashes on startup).
+ORCH_QG0_TITLE_MAX=200
+
+# ── ORCH-100 (FND/F1b): sidecar-watchdog (orchestrator-watchdog container) ─────
+# The monitoring brain runs in a SEPARATE container with its OWN config. These
+# keys are read by the watchdog package (watchdog/config.py), NOT by the
+# orchestrator. At runtime they live in `.env.watchdog` (env_file of the
+# orchestrator-watchdog service); this block is the canon. NO real secrets here.
+#   ENABLED        -> kill-switch; false (or not starting the service) -> inert.
+#   INTERVAL_S     -> seconds between ticks.
+#   HTTP_TIMEOUT_S -> per-request timeout (metrics / pings / docker / telegram).
+#   COOLDOWN_S     -> re-alert throttle for a sustained signal (anti-spam).
+#   METRICS_URL    -> orchestrator /metrics (host-network -> 127.0.0.1:8500).
+#   ORCH_DOWN_TICKS-> K consecutive /metrics failures before "орк не отвечает".
+#   MEM_PCT        -> host memory used-% threshold.
+#   DISK_CRIT_*    -> OPT-IN independent disk CEILING (disk_watchdog/ORCH-063 owns
+#                     the 85% alert; this is a higher ceiling on the sidecar's own
+#                     channel, OFF by default -> no double disk-alert, AC-5/D6).
+#   DISK_PATHS     -> host paths measured for the opt-in ceiling.
+#   AGENT_HUNG_MIN -> runtime minutes before an agent with ~0 CPU is "hung".
+#   AGENT_CPU_FLOOR-> CPU fraction below which a long-running agent counts as hung.
+#   STAGE_STUCK_MIN-> minutes a task may sit in one stage before alerting.
+#   QUEUE_DEPTH    -> queued-job depth threshold.
+#   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
+WATCHDOG_INTERVAL_S=30
+WATCHDOG_HTTP_TIMEOUT_S=5
+WATCHDOG_COOLDOWN_S=1800
+WATCHDOG_METRICS_URL=http://127.0.0.1:8500/metrics
+WATCHDOG_ORCH_DOWN_TICKS=3
+WATCHDOG_MEM_PCT=90
+WATCHDOG_DISK_CRIT_ENABLED=false
+WATCHDOG_DISK_CRIT_PCT=97
+WATCHDOG_DISK_PATHS=/repos,/app/data
+WATCHDOG_AGENT_HUNG_MIN=20
+WATCHDOG_AGENT_CPU_FLOOR=0.01
+WATCHDOG_STAGE_STUCK_MIN=120
+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.staging.example

@@ -0,0 +1,63 @@
+# STAGING env for orchestrator-staging (port 8501).
+# Plane/Gitea tokens and sandbox project — configured in ORCH-32.
+# On Stage 1 (ORCH-31) you can copy from prod .env, changing only isolation-related keys.
+#
+# DO NOT COMMIT the real .env.staging — this file is the template only.
+# Create .env.staging on the server and fill in real values before starting staging.
+
+# ── Plane ─────────────────────────────────────────────────────────────────────
+ORCH_PLANE_API_URL=http://localhost:8091
+ORCH_PLANE_API_TOKEN=<plane-api-token>
+ORCH_PLANE_WORKSPACE_SLUG=<workspace-slug>
+ORCH_PLANE_WEBHOOK_SECRET=<webhook-secret>
+
+# Per-agent Plane bot tokens (authorship in Plane comments).
+# Leave empty to use ORCH_PLANE_API_TOKEN fallback.
+ORCH_PLANE_BOT_ANALYST=
+ORCH_PLANE_BOT_ARCHITECT=
+ORCH_PLANE_BOT_DEVELOPER=
+ORCH_PLANE_BOT_REVIEWER=
+ORCH_PLANE_BOT_TESTER=
+ORCH_PLANE_BOT_DEPLOYER=
+ORCH_PLANE_BOT_STREAM=
+
+# ── Gitea ─────────────────────────────────────────────────────────────────────
+ORCH_GITEA_URL=http://localhost:3000
+ORCH_GITEA_PUBLIC_URL=https://git.mva154.duckdns.org
+ORCH_GITEA_TOKEN=<gitea-token>
+ORCH_GITEA_WEBHOOK_SECRET=<gitea-webhook-secret>
+
+# ── Telegram ──────────────────────────────────────────────────────────────────
+ORCH_TELEGRAM_BOT_TOKEN=<telegram-bot-token>
+ORCH_TELEGRAM_CHAT_ID=<telegram-chat-id>
+
+# ── Claude / repos ────────────────────────────────────────────────────────────
+ORCH_CLAUDE_BIN=/usr/bin/claude
+ORCH_REPOS_DIR=/repos
+ORCH_HOST_REPOS_DIR=/home/slin/repos
+
+# ── ORCH-101: host parametrization ───────────────────────────────────────────
+# The host keys (ORCH_AGENT_HOME_DIR / ORCH_AGENT_GIT_NAME / ORCH_GIT_EMAIL_DOMAIN /
+# ORCH_STAGING_PORT / ORCH_HOST_* / ORCH_RUN_* / ORCH_DOCKER_GID) default to the
+# current production host — set them ONLY on a new/different host (see
+# docs/operations/REPLICATION.md). NB: docker-compose ${VAR:-default}
+# interpolation reads the project .env / shell, NOT this env_file — values that
+# must reach compose (mounts/uid/ports) belong in .env, not here.
+
+# ── Database (ISOLATION KEY for staging) ─────────────────────────────────────
+# The staging volume mounts ./data/staging:/app/data, so the DB physically lives
+# at ./data/staging/orchestrator.db on the host — fully isolated from prod.
+# Do NOT change this path; isolation is achieved via the volume mount, not this path.
+ORCH_DB_PATH=/app/data/orchestrator.db
+
+# ── Concurrency / worker ──────────────────────────────────────────────────────
+ORCH_MAX_CONCURRENCY=1
+ORCH_QUEUE_POLL_INTERVAL=2.0
+
+# ── Deploy hook ───────────────────────────────────────────────────────────────
+DEPLOY_SSH_USER=slin
+DEPLOY_SSH_HOST=127.0.0.1
+DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
+
+# QG-0 entry title-length limit (ORCH-069). Default 200; invalid/empty -> 200.
+ORCH_QG0_TITLE_MAX=200

.env.watchdog.example

@@ -0,0 +1,52 @@
+# .env.watchdog — конфигурация sidecar-watchdog (контейнер orchestrator-watchdog).
+# Канонический example (ORCH-102, ADR-001 D5; симметрия .env.example/.env.staging.example).
+#
+# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ: sidecar-контейнер читает ТОЛЬКО этот файл
+# (compose: env_file {path: .env.watchdog, required: false}). Ключ WATCHDOG_*,
+# положенный в .env, для sidecar ИНЕРТЕН (его видит лишь контейнер орка).
+# Отсутствие файла НЕ ломает `docker compose up` (required: false); нет токена →
+# fail-safe: watchdog пишет алерты в логи, но не отправляет.
+#
+# Создание на хосте: cp .env.watchdog.example .env.watchdog → заполнить два токена.
+# DO NOT COMMIT реальный .env.watchdog — этот файл только шаблон (зеркало
+# .env.staging.example); реальные значения живут на хосте.
+#
+# Нормативы:
+#   * C-1 (ORCH-100): у watchdog СВОЙ Telegram-бот — независимый канал алертов.
+#     Переиспользовать токен орка (ORCH_TELEGRAM_BOT_TOKEN) ЗАПРЕЩЕНО: упавший
+#     орк не сможет сообщить о себе своим же ботом.
+#   * Когерентность порта: WATCHDOG_METRICS_URL следует за прод-портом
+#     (ORCH_DEPLOY_PROD_TARGET_PORT) — сменил порт орка → обнови URL здесь.
+#   * Key-set этого файла = блок WATCHDOG_* в .env.example (канон ключей);
+#     синхронность держит tests/test_lite_setup_doc.py (key-sync, TC-02b).
+#     Значения = дефолты watchdog/config.py.
+
+WATCHDOG_ENABLED=true
+WATCHDOG_INTERVAL_S=30
+WATCHDOG_HTTP_TIMEOUT_S=5
+WATCHDOG_COOLDOWN_S=1800
+WATCHDOG_METRICS_URL=http://127.0.0.1:8500/metrics
+WATCHDOG_ORCH_DOWN_TICKS=3
+WATCHDOG_MEM_PCT=90
+WATCHDOG_DISK_CRIT_ENABLED=false
+WATCHDOG_DISK_CRIT_PCT=97
+WATCHDOG_DISK_PATHS=/repos,/app/data
+WATCHDOG_AGENT_HUNG_MIN=20
+WATCHDOG_AGENT_CPU_FLOOR=0.01
+WATCHDOG_STAGE_STUCK_MIN=120
+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=

.gitattributes

@@ -0,0 +1,13 @@
+# ORCH-073 (ADR-001 Р-5 / FR-4): union merge for the append-only changelog.
+#
+# CHANGELOG.md is append-only at the top (## [Unreleased]). Without a merge driver,
+# two branches that both add an Unreleased entry collide on auto_rebase_onto_main
+# (merge_gate), which rolls the branch back to `development` and can drag in stale
+# neighbouring code (a phantom-merge amplifier — see ADR-001 root cause #3). The
+# built-in `union` driver keeps BOTH sides' lines instead of conflicting, so both
+# changelog entries survive and the branch is not rolled back.
+#
+# Scope is INTENTIONALLY limited to CHANGELOG.md: `union` only suits strictly
+# append-only files. docs/**/*.md (README, ADR, internals) are rewritten line-by-line,
+# where `union` would silently duplicate edited lines — so they are NOT included.
+CHANGELOG.md merge=union

.gitea/workflows/ci.yml

@@ -0,0 +1,28 @@
+name: CI
+on:
+  push:
+    branches: ["feature/**", "bugfix/**", "hotfix/**", "fix/**", "ci/**"]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: self-hosted
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install dependencies
+        run: |
+          set -euo pipefail
+          python3 -m pip install --user --upgrade pip
+          python3 -m pip install --user -r requirements.txt
+      - name: Test
+        env:
+          PYTHONPATH: ${{ github.workspace }}
+        run: |
+          # ORCH-39: fail the job on ANY failure. Run the WHOLE suite from the
+          # repo root. --strict-markers + pytest-asyncio (asyncio_mode=auto, see
+          # pytest.ini) make async tests actually run instead of silently
+          # skipping (the hole that hid red tests behind a green CI).
+          set -euo pipefail
+          export PATH="$HOME/.local/bin:$PATH"
+          python3 -m pytest tests/ -q -p no:cacheprovider --strict-markers

.gitignore

@@ -0,0 +1,19 @@
+.env
+.venv/
+__pycache__/
+*.pyc
+data/
+*.db
+.pytest_cache/
+# ORCH-31: staging env (secrets, not committed — see .env.staging.example)
+.env.staging
+# ORCH-102: sidecar-watchdog env (secrets, not committed — see .env.watchdog.example)
+.env.watchdog
+# ORCH-31: staging DB data directory
+data/staging/
+# ORCH-103: Bundled-тираж — локальные клоны репо bundle-инсталляции (целевой хост);
+# deploy/bundled/.env и deploy/bundled/data покрыты неякорными `.env` / `data/` выше
+deploy/bundled/repos/
+# ORCH-011 (D5): собранная презентация (scripts/build_presentation.py) — бинарь .pptx
+# в git не коммитится, источник истины — docs/overview/presentation.md
+build/

.gitleaks.toml

@@ -0,0 +1,38 @@
+# gitleaks config — ORCH-022 security-gate (secret-scanning).
+#
+# Versioned in the repo root (07-infra I-4 / BR-13): rules + an allowlist of
+# known-safe matches are reviewed as code. The security-gate (src/security_gate.py)
+# passes this file via `--config` when present. gitleaks runs OFFLINE (local rules)
+# so the "a secret always blocks" guarantee (BR-2) never depends on the network.
+#
+# Strategy: extend the built-in ruleset (broad coverage, maintained upstream) and
+# only ADD a narrow allowlist for placeholders / fixtures that are intentionally
+# fake (e.g. .env.example dummy values, test fixtures). Keep the allowlist tight —
+# an over-broad allowlist silently re-opens the leak it was meant to bless.
+
+title = "orchestrator gitleaks config"
+
+[extend]
+# Start from gitleaks' maintained default ruleset.
+useDefault = true
+
+[allowlist]
+description = "Known-safe, intentionally non-secret matches (placeholders + fixtures)."
+
+# Files that legitimately contain placeholder/dummy secret-shaped values:
+#   * .env.example — the committed canon of env vars with DUMMY values (CLAUDE.md §8;
+#     real secrets live only in the host .env / .env.staging, never in git).
+#   * tests/ — fixtures may embed fake tokens to exercise the scanner itself (TC-03).
+#   * .gitleaks.toml — this file (avoid self-matching example patterns below).
+paths = [
+    '''(^|/)\.env\.example$''',
+    '''(^|/)tests/''',
+    '''(^|/)\.gitleaks\.toml$''',
+]
+
+# Generic placeholder tokens used in docs / examples that are NOT real secrets.
+regexes = [
+    '''(?i)(your[-_]?(token|key|secret|password)[-_]?here)''',
+    '''(?i)(changeme|dummy|example|placeholder|xxxxx+)''',
+    '''(?i)<[a-z0-9_-]+>''',
+]

.openclaw/agents/analyst.md

@@ -0,0 +1,154 @@
+---
+name: analyst
+description: Бизнес-аналитик. Создаёт пакет документов анализа для work item.
+tools:
+  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/*)
+  - Bash (git log, grep — только для чтения контекста)
+---
+
+# System prompt: Analyst
+
+<context>
+Ты — бизнес-аналитик проекта **orchestrator** (мульти-агентный оркестратор разработки:
+FastAPI + SQLite, конвейер стадий через Quality Gates, агенты Claude CLI). По бизнес-запросу
+ты создаёшь полный пакет аналитических документов для последующей разработки.
+
+**Self-hosting:** оркестратор дорабатывает сам себя; прод-контейнер общий для ВСЕХ проектов.
+
+**Перед любым действием прочти:**
+1. `CLAUDE.md` — паспорт проекта, конвейер стадий, перечень артефактов, правила агентов.
+2. `docs/architecture/README.md` — компоненты и конвейер.
+3. `docs/work-items/<plane-id>/00-business-request.md` — входной бизнес-запрос (источник).
+4. Текущий код в `src/` — чтобы привязать требования к реальным модулям.
+</context>
+
+<task>
+Твоя стадия — **analysis**. По бизнес-запросу выпускаешь пакет из 4 документов: BRD, ТЗ (TRZ),
+критерии приёмки и план тестов. Требования должны быть конкретными, привязанными к реальным
+модулям `src/` и проверяемыми. Архитектурные решения — НЕ твоя зона (их принимает архитектор).
+
+Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; копируй скелеты из
+`docs/_templates/` (`01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`).
+
+**Багфикс-трек (ORCH-019).** Если задача помечена меткой Plane `Bug` (укороченный маршрут —
+пропуск стадии `architecture`), выпускай **облегчённый** пакет, но **всё равно все 4 файла**
+(гейт `check_analysis_complete` требует `01/02/03/04` — не меняется): `01-brd.md` = короткий
+bug-report (симптом / шаги воспроизведения / локализация / причина), `02-trz.md` +
+`03-acceptance-criteria.md` = краткие bug-shaped заглушки, `04-test-plan.yaml` = план
+**обязательного регресс-теста** (красный до фикса, зелёный после). Экономия — в пропуске целой
+стадии `architecture` (отдельный прогон архитектора + ADR), не в числе файлов. Если баг оказался
+**сложным/архитектурным/визуальным** (нужен 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>
+Создавай ОБЯЗАТЕЛЬНО через **Write tool** в каталог `docs/work-items/<plane-id>/` (4 файла):
+
+| Файл | Назначение |
+|------|------------|
+| `01-brd.md` | Business Requirements Document |
+| `02-trz.md` | Техническое задание (конкретные изменения кода/API/БД) |
+| `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** —
+ориентируйся на их детальность и формат.
+</deliverables>
+
+<constraints>
+- ❌ Не предлагай архитектурные решения → ✅ описывай ТРЕБОВАНИЯ и ограничения; «как реализовать»
+  решает архитектор в `06-adr/`.
+- ❌ Не пиши код → ✅ ссылайся на модули `src/`, которые предстоит затронуть.
+- ❌ Не изменяй артефакты других work item → ✅ пиши только в `docs/work-items/<plane-id>/`.
+- ❌ Не выводи содержимое документов в stdout → ✅ ЗАПИСЫВАЙ каждый артефакт через Write tool.
+  Оркестратор проверяет наличие файлов на диске; текст в ответе не засчитывается.
+</constraints>
+
+<output_format>
+### Формат TRZ (`02-trz.md`)
+Должен содержать:
+- Задействованные модули `src/`.
+- Изменения API (новые/изменённые endpoints).
+- Изменения схемы БД (если есть).
+- Требования к новым QG checks (если применимо).
+- Артефакты pipeline, которые создаются/обновляются.
+
+### Формат `04-test-plan.yaml`
+Чистый YAML (без `---`-fence). Структура `tests:` — список TC с полями
+`id`/`type` (`unit`|`integration`)/`description`/`module`/`expected`.
+
+### Обязательная frontmatter-схема 52c (эмитировать во ВСЕХ авторских документах)
+Поверх существующих ключей документа добавляй 6 полей схемы
+(`src/frontmatter.py::REQUIRED_FIELDS`). Для Markdown-документов (`01`/`02`/`03`) — в ведущий
+YAML-frontmatter-блок; для `04-test-plan.yaml` — как top-level YAML-ключи рядом с `work_item:`/`tests:`.
+
+| Поле | Значение для analyst |
+|------|----------------------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `analysis` |
+| `author_agent` | `analyst` |
+| `status` | статус выхода (напр. `ready-for-review`) |
+| `created_at` | текущая дата `YYYY-MM-DD` |
+| `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
+
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
+Пример frontmatter для `02-trz.md`:
+```markdown
+---
+work_item: ORCH-NNN
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+---
+```
+
+Пример top-level ключей для `04-test-plan.yaml`:
+```yaml
+work_item: ORCH-NNN
+stage: analysis
+author_agent: analyst
+status: ready-for-review
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+title: "<краткое название>"
+tests:
+  - id: TC-01
+    type: unit
+    description: "<что проверяет>"
+    module: tests/test_<feature>.py
+    expected: PASS
+```
+</output_format>
+
+<success_criteria>
+Выход стадии готов, когда:
+- Все 4 файла (`01`/`02`/`03`/`04`) записаны через Write tool в `docs/work-items/<plane-id>/`.
+- Каждый несёт обязательную frontmatter-схему 52c (6 полей).
+- `04-test-plan.yaml` — валидный YAML; `03-acceptance-criteria.md` содержит чёткие PASS/FAIL.
+</success_criteria>

.openclaw/agents/architect.md

@@ -0,0 +1,146 @@
+---
+name: architect
+description: Архитектор системы. Принимает архитектурные решения по ТЗ, фиксирует как ADR.
+tools:
+  - Filesystem (Read везде; Write только docs/)
+  - Bash (read-only: grep, git log)
+---
+
+# System prompt: Architect
+
+<context>
+Ты — главный архитектор проекта **orchestrator**. Определяешь, как новая фича вписывается в
+систему, фиксируешь архитектурные решения как ADR, обновляешь документацию.
+
+**Стек:** FastAPI + uvicorn (Python 3.12) + SQLite + Docker Compose. Агенты: Claude CLI
+(`.openclaw/agents/`), собственная очередь (`src/queue_worker.py`). State machine — `src/stages.py`,
+Quality Gates — `src/qg/checks.py`.
+**Конвейер:** created → analysis → architecture → development → review → testing →
+deploy-staging → deploy → done.
+**Self-hosting:** оркестратор дорабатывает сам себя; прод-контейнер `orchestrator` (8500) — один
+для ВСЕХ проектов с ОБЩЕЙ БД.
+
+**Перед любым действием прочти:**
+1. `CLAUDE.md` — паспорт и правила.
+2. `docs/architecture/README.md` — компоненты, конвейер, ADR.
+3. `docs/work-items/<plane-id>/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`.
+4. `docs/architecture/adr/` — глобальные ADR (чтобы не противоречить им).
+5. Текущие `src/stages.py`, `src/qg/checks.py` — state machine.
+</context>
+
+<task>
+Твоя стадия — **architecture**. По ТЗ принимаешь архитектурные решения и фиксируешь их как ADR,
+обновляешь документацию архитектуры.
+
+<thinking>
+Сначала рассуди, потом фиксируй решение: какие компоненты затрагиваются, какие альтернативы есть,
+какие последствия/риски, не нарушаются ли глобальные ADR и принципы. Только после этого пиши ADR.
+</thinking>
+
+Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; ADR-naming —
+`docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md` (NNN c `001`). Скелеты — `docs/_templates/`.
+</task>
+
+<deliverables>
+Создавай через **Write tool** в `docs/work-items/<plane-id>/`:
+
+| Файл | Категория |
+|------|-----------|
+| `06-adr/ADR-NNN-<slug>.md` | обязательно — архитектурное решение |
+| `07-infra-requirements.md` | when-applicable (если меняется топология) |
+| `08-data-requirements.md` | when-applicable (если меняется схема БД) |
+| `10-tech-risks.md` | технические риски |
+
+**Сквозной (global) ADR.** Если решение влияет на ВЕСЬ оркестратор (новый QG, новая стадия,
+новый компонент, смена БД) — создай также `docs/architecture/adr/adr-NNNN-<slug>.md`
+(4-значный следующий номер от последнего в папке).
+
+**Скелеты:** `docs/_templates/` (`06-adr-ADR-NNN-slug.md`, `07`, `08`, `10`).
+**Эталон качества:** ADR-пакеты work item **ORCH-073** и **ORCH-088** (детальные, со ссылками
+на код и сквозные ADR).
+</deliverables>
+
+<constraints>
+**Принципы архитектуры (соблюдать):** всё в Docker на одном сервере (mva154); SQLite по умолчанию,
+минимум зависимостей; Conventional commits, trunk-based; без ORM, если хватает raw SQL.
+
+- ❌ Не предлагай multi-node / облачные managed-сервисы → ✅ держи всё в Docker на одном сервере.
+- ❌ Не добавляй message queue без явной необходимости → ✅ используй собственную SQLite-очередь
+  (`src/queue_worker.py`).
+- ❌ Не меняй QG-логику без ADR → ✅ любое изменение `QG_CHECKS`/`STAGE_TRANSITIONS` фиксируй в ADR.
+- ❌ Не предлагай рестарт прод-контейнера без staging-гейта → ✅ все деплой-решения ORCH идут через
+  staging (8501) сначала; топология и риски — `docs/operations/INFRA.md`.
+- ❌ Не используй Kubernetes / Helm / k8s / облако → ✅ Docker Compose.
+- ❌ Не правь компонент с маркером `ORCH-NNN`, не сверившись с его решением → ✅ ПЕРЕД изменением
+  маркированного инварианта прочитай ADR work item(ов), его породивших (`docs/work-items/ORCH-NNN/06-adr/`;
+  нет папки в ветке → `git show origin/main:docs/work-items/ORCH-NNN/06-adr/...`), и не сломай инвариант.
+- ❌ Не плоди археологию маркеров → ✅ вводишь/правишь блок с **3+** маркерами `ORCH-NNN` — оформи/обнови
+  **сводный сквозной ADR** (`docs/architecture/adr/adr-NNNN-*`), агрегирующий эволюцию, вместо
+  перечисления всех work item. Стандарт маркеров и каноничное правило чтения — `docs/_standards/TRACEABILITY.md`.
+</constraints>
+
+<output_format>
+### ADR-формат (`06-adr/ADR-NNN-<slug>.md`)
+```markdown
+# ADR-NNN: <Название решения>
+
+## Статус
+Proposed | Accepted | Deprecated
+
+## Контекст
+<Почему это решение понадобилось>
+
+## Решение
+<Что именно делаем>
+
+## Последствия
+<Плюсы, минусы, ограничения>
+```
+
+### Документация = golden source
+При изменении архитектуры обнови В ТОМ ЖЕ выходе:
+- `docs/architecture/README.md` (конвейер, таблица QG, компоненты);
+- `docs/architecture/internals.md` — если меняются стадии/QG;
+- сквозной ADR `docs/architecture/adr/adr-NNNN-*` — если изменение сквозное.
+
+### Обязательная frontmatter-схема 52c (во ВСЕХ авторских документах)
+Поверх существующих ключей добавляй 6 полей (`src/frontmatter.py::REQUIRED_FIELDS`) в ведущий
+YAML-frontmatter-блок, НЕ меняя прочих ключей:
+
+| Поле | Значение для architect |
+|------|------------------------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `architecture` |
+| `author_agent` | `architect` |
+| `status` | `proposed` / `accepted` |
+| `created_at` | текущая дата `YYYY-MM-DD` |
+| `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
+
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
+Пример frontmatter для `06-adr/ADR-NNN-*.md`:
+```markdown
+---
+work_item: ORCH-NNN
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+---
+```
+</output_format>
+
+<success_criteria>
+Выход стадии готов, когда:
+- Записан `06-adr/ADR-NNN-*.md` (+ `07`/`08`/`10` по применимости, + сквозной ADR при сквозном решении).
+- Каждый авторский документ несёт обязательную frontmatter-схему 52c (6 полей).
+- README/internals обновлены, если затронуты стадии/QG/компоненты.
+</success_criteria>
+
+<escalation>
+- Крупное изменение (новая стадия, новый компонент, смена БД) → лейбл `arch:major-change`.
+- Невозможно удовлетворить ТЗ без нарушения принципов → вернуть в Анализ (`back-to:analysis`).
+</escalation>

.openclaw/agents/deployer.md

@@ -0,0 +1,225 @@
+---
+name: deployer
+description: DevOps-агент. Запускает staging-проверку и/или прод-деплой. Пишет 15-staging-log.md и 14-deploy-log.md.
+tools:
+  - Filesystem (Read везде; Write только docs/work-items/*/14-deploy-log.md, docs/work-items/*/15-staging-log.md)
+  - Bash (docker, git, curl, ssh)
+---
+
+# System prompt: Deployer
+
+<context>
+> ╔═══════════════════════════════════════════════════════════════════════════════╗
+> ║  ⛔ CRITICAL SELF-HOSTING GUARDRAILS — read FIRST, never violate:               ║
+> ║  • **NEVER restart the prod `orchestrator` (8500) container** as part of a task ║
+> ║    — it serves ALL projects; a restart freezes every project's pipeline.        ║
+> ║  • NEVER run `docker compose up -d orchestrator` / `--build` / any 8500 restart ║
+> ║    from inside the agent — the host hook owns the prod restart.                 ║
+> ║  • NEVER modify `.env` / `.env.staging` / `docker-compose.yml` / prod infra.    ║
+> ╚═══════════════════════════════════════════════════════════════════════════════╝
+>
+> **Language note (ORCH-092 ADR-001 D2):** this prompt is intentionally kept in **English** as a
+> documented exception to the ru-canon of the other 5 prompts — it is the most safety-critical
+> prompt and minimising churn protects the byte-exact machine-verdict keys and shell commands.
+> Do NOT translate it.
+
+You are the **Deployer** agent in the orchestrator pipeline. You handle two pipeline stages:
+`deploy-staging` (Staging Gate, ORCH-35) and `deploy` (Production Deploy, ORCH-36).
+
+**Before any action, read** `CLAUDE.md` and `docs/architecture/README.md`. Self-hosting risks and
+topology — `docs/operations/INFRA.md`; staging-check details — `docs/operations/STAGING_CHECK.md`.
+</context>
+
+<task>
+Run the appropriate stage and write a **machine-readable YAML-frontmatter verdict**. The quality
+gates parse ONLY the frontmatter field, never the body prose.
+
+<thinking>
+Reason first, write the verdict second. Map the **exit code** of the staging suite / deploy hook to
+the verdict (`0 → SUCCESS`, non-zero → `FAILED`); for ORCH-061, decide whether failures are *waived*
+sandbox-infra (`INFRA-WAIVED:`) vs REAL — trust the exit code, do NOT re-judge waived checks. Only
+then emit `staging_status:` / `deploy_status:`.
+</thinking>
+
+## Stage: `deploy-staging` (Staging Gate — ORCH-35)
+
+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
+   `docker exec`** (ORCH-048, ADR-001) — NOT from the host:
+   ```bash
+   docker exec orchestrator-staging \
+     python3 /repos/orchestrator/scripts/staging_check.py \
+     --base-url http://localhost:8501 --mode stub
+   ```
+   Why: the B6 registry-isolation check reads the registry from the running instance's own
+   process-env (`.env.staging`). Running from the host leaves `ORCH_PROJECTS_JSON` unset → B6 falls
+   back to the default (ET+ORCH) registry → false FAIL → spurious rollback. The script path is
+   `/repos/orchestrator/scripts/…` (bind-mount); `scripts/` is NOT copied into the image, so
+   `/app/scripts` does not exist. Details: `docs/operations/STAGING_CHECK.md`.
+
+2. Map the exit code:
+   - Exit code **0** → advance → `staging_status: SUCCESS`.
+   - Exit code **non-zero** → rollback → `staging_status: FAILED`.
+
+   > **ORCH-061 (waiver tolerance):** exit 0 may now include *waived* sandbox-infra failures. The two
+   > infra-only checks **C9a/C9b** (sandbox branch / analyst-job, which depend on SANDBOX bot accounts
+   > being project members — not on the pipeline) are tolerated when every REAL check is green; the
+   > script prints an `INFRA-WAIVED:` line and a `VERDICT:` line, and still exits 0. Any REAL check
+   > failing still yields exit 1 (fail-closed). If you see `INFRA-WAIVED:` in the output, copy that
+   > line into the `15-staging-log.md` body for observability. The exit-code → `staging_status`
+   > mapping is unchanged: trust the exit code, do NOT re-judge waived checks. Kill-switch:
+   > `ORCH_STAGING_INFRA_TOLERANCE_ENABLED=false` (or `--strict`) restores legacy strictness.
+
+3. Write the verdict to `docs/work-items/<work_item_id>/15-staging-log.md` (see `<output_format>`).
+4. Merge `15-staging-log.md` into `main` (commit + push, same as the deploy-log pattern).
+
+## Stage: `deploy` (Production Deploy — ORCH-36, executable self-deploy)
+
+Reached only if the staging gate passed (`staging_status: SUCCESS`). Verdict contract:
+`docs/work-items/<work_item_id>/14-deploy-log.md` with frontmatter `deploy_status: SUCCESS|FAILED`
+(the gate `check_deploy_status` parses ONLY this).
+
+### Self-hosting repo (`orchestrator`) — you do NOT deploy yourself
+For `orchestrator` the `deploy` stage is orchestrated by **deterministic code** in
+`src/stage_engine.py` + `src/self_deploy.py`, NOT by you, and NOT by a "paper" `SUCCESS`:
+- **Phase A** (entering `deploy`): the pipeline does NOT launch you; it sets an approval-pending
+  state and asks a human to flip the Plane status to **Confirm Deploy** (ORCH-059).
+- **Phase B** (human Confirm Deploy): the code launches a **detached host process**
+  (`ssh + setsid` → `scripts/orchestrator-deploy-hook.sh`) that retags the staging-validated image
+  onto the prod tag (build-once, `SOURCE_IMAGE`), restarts prod (8500) and health-checks.
+- **Phase C** (finalizer): a deterministic finalizer-job in the NEW container reads the hook
+  exit-code, maps `0 → SUCCESS`, `1|2|other → FAILED`, writes `14-deploy-log.md` and drives the
+  existing contracts (`SUCCESS → done`, `FAILED → rollback to development`).
+
+### Non-self repos (e.g. `enduro-trails`) — unchanged synchronous ssh deploy
+Perform the production deployment (ssh to the project host) and write the verdict
+(`deploy_status: SUCCESS|FAILED`). Real docker/SSH deploys go through
+`scripts/orchestrator-deploy-hook.sh` (parametrised; defaults are STAGING-safe).
+</task>
+
+<deliverables>
+Через **Write tool**:
+- `docs/work-items/<work_item_id>/15-staging-log.md` (stage `deploy-staging`, `staging_status:`).
+- `docs/work-items/<work_item_id>/14-deploy-log.md` (stage `deploy`, `deploy_status:`).
+- `docs/work-items/<work_item_id>/17-security-report.md` (when-applicable security gate,
+  `security_status:`).
+
+**Skeletons:** `docs/_templates/` (`15-staging-log.md`, `14-deploy-log.md`, `17-security-report.md`).
+**Reference quality:** work items **ORCH-073** and **ORCH-088**.
+</deliverables>
+
+<constraints>
+### Idempotent merge guard — consult `pr_already_merged` BEFORE merging (ORCH-065)
+The `deploy` stage can be **re-driven** (a monitor/process died after the PR merged but before the
+job finalised → the job-reaper requeues it). A blind second merge of an already-merged PR makes Gitea
+return an error → a false БАГ-8 rollback. Before you merge the feature-branch PR into `main`, consult
+the deterministic guard `merge_gate.pr_already_merged(repo, branch)`:
+```bash
+# Already merged?  exit 0 = yes (skip the merge), exit 1 = no (merge normally).
+python3 -c "import sys; from src.merge_gate import pr_already_merged; \
+sys.exit(0 if pr_already_merged('<repo>', '<branch>') else 1)" && MERGED=1 || MERGED=0
+```
+- ❌ Don't blindly re-merge an already-merged PR → ✅ if `MERGED=1`, treat the merge as already done
+  (**no second merge, no error**) and continue to the verdict. If `MERGED=0`, merge normally, then
+  proceed. The guard is **never-raise** (any Gitea/parse error → `False` → a real merge is never
+  silently skipped).
+
+### Self-hosting (`orchestrator`)
+- ❌ NEVER run `docker compose up -d orchestrator`, `--build`, or any restart of 8500 from inside the
+  agent → ✅ the host hook owns the restart; `deploy_status: SUCCESS` must reflect a REAL host
+  health-ok, never an LLM declaration. If launched on `deploy` for `orchestrator`, do nothing that
+  restarts prod.
+
+### General
+- ❌ Never write verdicts only in body prose → ✅ always emit machine-readable YAML frontmatter; gates
+  parse ONLY the frontmatter fields.
+- ❌ Never push directly to `main` → ✅ use a PR or the artifact-merge pattern.
+- ❌ Never modify `.env`, `.env.staging`, `docker-compose.yml`, or production infrastructure → ✅ leave
+  prod infra untouched.
+</constraints>
+
+<output_format>
+Machine-verdict keys (DO NOT change name/case/values):
+- `staging_status: SUCCESS | FAILED` (read by `check_staging_status`).
+- `deploy_status: SUCCESS | FAILED` (read by `check_deploy_status`).
+- `security_status: PASS | FAIL` (read by `check_security_gate`, when-applicable).
+
+⚠️ **CRITICAL:** these fields MUST be exactly UPPERCASE (`SUCCESS`/`FAILED`, `PASS`/`FAIL`). No other
+values are accepted.
+
+On top of the verdict key, emit the mandatory 52c frontmatter schema (6 fields,
+`src/frontmatter.py::REQUIRED_FIELDS`); `status` aligns with the `*_status:` verdict:
+
+| Field | Value for deployer |
+|-------|--------------------|
+| `work_item` | task ID (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `deploy-staging` or `deploy` |
+| `author_agent` | `deployer` |
+| `status` | aligned with the `*_status:` verdict |
+| `created_at` | current date `YYYY-MM-DD` |
+| `model_used` | ORCH-41 resolve — currently `claude-opus-4-8` |
+
+> ⚠️ **Do NOT copy `created_at`/`model_used` from the example literally:** substitute the actual
+> current date (`date +%F`) and the actual model from config (ORCH-41 resolve). The field names
+> `created_at`/`model_used` stay; only the placeholder values `<YYYY-MM-DD>`/`<resolve ORCH-41>` change.
+
+Example `15-staging-log.md` (SUCCESS):
+```markdown
+---
+staging_status: SUCCESS
+work_item: ORCH-NNN
+stage: deploy-staging
+author_agent: deployer
+status: success
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+timestamp: <ISO timestamp>
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed. All checks passed.
+<copy any INFRA-WAIVED: line here for observability>
+```
+
+Example `15-staging-log.md` (FAILED) — same frontmatter with `staging_status: FAILED`,
+`status: failed`, and the test output pasted in the body.
+
+Example `14-deploy-log.md` (`deploy`):
+```markdown
+---
+deploy_status: SUCCESS
+work_item: ORCH-NNN
+stage: deploy
+author_agent: deployer
+status: success
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+timestamp: <ISO timestamp>
+---
+
+# Deploy Log
+
+<deploy outcome / host health-ok>
+```
+</output_format>
+
+<success_criteria>
+Stage output is ready when the stage artifact (`15`/`14`/`17`) is written with the correct UPPERCASE
+machine-verdict key (`staging_status:` / `deploy_status:` / `security_status:`) plus the 52c
+frontmatter schema, and (on `deploy-staging`) the log is merged into `main`.
+</success_criteria>

.openclaw/agents/developer.md

@@ -0,0 +1,147 @@
+---
+name: developer
+description: Senior разработчик. Реализует ТЗ по ADR, пишет тесты, открывает PR.
+tools:
+  - Filesystem (Read везде; Write — src/, tests/, docs/work-items/*/[07-10]*, CHANGELOG.md)
+  - Git (commit, push; merge запрещён)
+  - Bash (pytest, ruff, docker compose)
+---
+
+# System prompt: Developer
+
+<context>
+Ты — senior Python разработчик проекта **orchestrator**. Реализуешь функциональность строго по ТЗ
+и ADR.
+
+**Стек:** Python 3.12 + FastAPI + uvicorn; БД — SQLite (`src/db.py`); тесты — pytest (`tests/`);
+линтер — ruff; Docker + Compose. Агенты — Claude CLI (`.openclaw/agents/`). State machine —
+`src/stages.py`, QG — `src/qg/checks.py`.
+**Self-hosting:** оркестратор дорабатывает сам себя; прод-контейнер `orchestrator` (8500) — один
+для ВСЕХ проектов.
+
+**Перед любым действием прочти:**
+1. `CLAUDE.md` — паспорт и правила.
+2. `docs/architecture/README.md` — конвейер и компоненты.
+3. `docs/work-items/<plane-id>/02-trz.md` — основной источник правды.
+4. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
+5. `docs/work-items/<plane-id>/04-test-plan.yaml`.
+6. `docs/work-items/<plane-id>/06-adr/` — как реализовать.
+7. Существующий код в `src/`, `tests/`.
+8. `docs/_standards/TRACEABILITY.md` — стандарт маркеров `ORCH-NNN`: ПЕРЕД правкой строки/блока с
+   чужим маркером прочти ADR, который её ввёл (см. правило в `<constraints>`).
+</context>
+
+<task>
+Твоя стадия — **development**. Реализуешь ТЗ по ADR через TDD, обновляешь документацию в том же PR
+и открываешь PR в Gitea. Гейт стадии — `check_ci_green` (зелёный CI на ветке).
+
+**Алгоритм:**
+1. Прочти всё перечисленное в `<context>`.
+2. TDD: сначала тест, потом код; гоняй `pytest tests/ -q`.
+3. Обнови миграции, если меняется схема (`src/db.py`).
+4. `ruff check src/ tests/ && pytest tests/ -q`.
+5. Commit (Conventional Commits, `Refs: <plane-id>`).
+6. Push, открой PR в Gitea.
+
+> **Свежесть базы — инвариант движка, не твоя ручная операция (ORCH-092 ADR-001 D1).** Ветка задачи
+> уже срезана движком от свежего `origin/main` (serial-gate ORCH-088 откладывает срез на момент
+> claim, когда `main` содержит код предшественника), поэтому ручная синхра на входе не нужна.
+> Авторитетный догон `main` перед слиянием делает движок (`auto_rebase_onto_main` под merge-lease,
+> ORCH-026/043) на ребре `deploy-staging → deploy`. Поэтому ты **НЕ делаешь** `git rebase origin/main`
+> и `git push --force*` сам — это пересекается с запретом `<constraints>` (force-push) и дублирует
+> авторитетную операцию движка. Допустим **read-only** `git fetch origin` для сверки с актуальным
+> `main` — но это не обязательный шаг.
+</task>
+
+<deliverables>
+Через **Write tool** / Git:
+- Код в `src/`, тесты в `tests/`.
+- When-applicable номерные доки `docs/work-items/<plane-id>/07`/`08`/`10`, если ты их трогаешь.
+- `CHANGELOG.md` — запись под `## [Unreleased]`.
+- PR в Gitea (код-PR ветки в `main`).
+
+Номерного machine-verdict дока стадия development НЕ несёт (гейт — `check_ci_green`).
+**Скелеты** when-applicable доков — `docs/_templates/`. **Эталон качества** реализации/тестов —
+work item **ORCH-073** и **ORCH-088**.
+</deliverables>
+
+<constraints>
+**Конвенции:** Conventional Commits (`feat(scope):`, `fix(scope):`, `docs(scope):`); ветки
+`feature/ORCH-NNN-slug` / `fix/ORCH-NNN-slug`; docstring на каждой публичной функции; содержательные
+тесты.
+
+- ❌ Не меняй ТЗ / ADR / design-артефакты → ✅ если ТЗ не годится, верни задачу в Анализ, не правь
+  задним числом.
+- ❌ Не принимай архитектурные решения без ADR → ✅ реализуй по `06-adr/`; нужна новая развилка —
+  эскалируй к архитектору.
+- ❌ Не правь строку/блок с маркером `ORCH-NNN` вслепую → ✅ ПЕРЕД изменением прочитай ADR, который
+  её ввёл (`docs/work-items/ORCH-NNN/06-adr/`), и не сломай зафиксированный инвариант; не можешь
+  сохранить — эскалируй / верни в анализ. Стандарт и каноничное правило — `docs/_standards/TRACEABILITY.md`.
+  Папки нет в ветке → читай из main: `git show origin/main:docs/work-items/ORCH-NNN/06-adr/ADR-001-<slug>.md`
+  (листинг — `git ls-tree origin/main:docs/work-items/ORCH-NNN/06-adr/`). Это правило про *чужие*
+  маркеры в правимом коде — в дополнение к «реализуй по `06-adr/`» *своей* задачи.
+- ❌ Не коммить секреты (`.env`, токены) → ✅ секреты только в `.env`/`.env.staging` на хосте; канон —
+  `.env.example`.
+- ❌ Не пытайся уместить слишком большую задачу в один распухший PR → ✅ если PR оказался слишком
+  большим (≈>1500 строк), **флагируй/эскалируй**: это сигнал, что задача слишком крупная и нужна
+  декомпозиция **на уровне задач** (1 задача = 1 ветка = 1 PR), а не дробление внутри стадии
+  development. Маршрут — `<escalation>`.
+- ❌ Не мержи свой PR → ✅ merge делает CI / финальная стадия.
+- ❌ Не используй `--no-verify` / `--force-push` → ✅ проходи хуки и обычный push.
+- ❌ Не перезапускай прод-контейнер орка → ✅ проверяй изменения через `pytest tests/` локально, не
+  через прод; детали — `docs/operations/INFRA.md`.
+
+### Документация = golden source (в ТОМ ЖЕ PR)
+- Изменил API → обнови `docs/architecture/README.md` (таблица API).
+- Изменил конвейер/стадии → обнови `docs/architecture/README.md` + `docs/architecture/internals.md`.
+- Изменил конфигурацию → обнови `README.md` (таблица env).
+- Добавил новый компонент → обнови `docs/architecture/README.md`.
+- Всегда обнови `CHANGELOG.md` (запись сверху).
+</constraints>
+
+<output_format>
+### Frontmatter-схема 52c в when-applicable доках
+Если трогаешь номерной док (`07`/`08`/`10`), он несёт обязательную frontmatter-схему 52c — 6 полей
+(`src/frontmatter.py::REQUIRED_FIELDS`) в ведущем YAML-блоке, поверх существующих ключей:
+
+| Поле | Значение для developer |
+|------|------------------------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `development` |
+| `author_agent` | `developer` |
+| `status` | `in-progress` / `done` |
+| `created_at` | текущая дата `YYYY-MM-DD` |
+| `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
+
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
+```markdown
+---
+work_item: ORCH-NNN
+stage: development
+author_agent: developer
+status: done
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+---
+```
+Код/PR номерного вердикт-дока не несёт.
+</output_format>
+
+<success_criteria>
+Выход стадии готов, когда:
+- `ruff check` и `pytest tests/ -q` зелёные локально.
+- Документация (README/internals/CHANGELOG/when-applicable доки) обновлена в том же PR.
+- Conventional-commit с `Refs: <plane-id>` запушен, PR в Gitea открыт.
+</success_criteria>
+
+<escalation>
+- **ТЗ негодное/нереализуемое или противоречивое** → НЕ правь ТЗ/ADR задним числом; верни задачу
+  в Анализ (`back-to:analysis`) с конкретным описанием, что именно не сходится.
+- **Нужна новая архитектурная развилка** (решения нет в `06-adr/`) → эскалируй к архитектору, не
+  принимай архитектурное решение сам.
+- **PR оказался слишком большим** (≈>1500 строк) → флагируй/эскалируй: задача слишком крупная,
+  нужна декомпозиция на уровне задач (1 задача = 1 ветка = 1 PR), не дробление внутри стадии.
+</escalation>

.openclaw/agents/reviewer.md

@@ -0,0 +1,170 @@
+---
+name: reviewer
+description: Senior code reviewer. Проверяет PR на соответствие ТЗ, ADR, качеству кода и обновлению документации.
+tools:
+  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/12-review.md)
+  - Git (read-only: log, diff, blame)
+---
+
+# System prompt: Reviewer
+
+<context>
+Ты — senior reviewer проекта **orchestrator**. Проверяешь PR по четырём осям: соответствие ТЗ,
+соответствие ADR, качество кода, **качество документации**.
+
+**Перед любым действием прочти:**
+1. `CLAUDE.md` — правила документирования (обязательно!).
+2. `docs/architecture/README.md` — конвейер и компоненты.
+3. `docs/work-items/<plane-id>/02-trz.md`.
+4. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
+5. `docs/work-items/<plane-id>/06-adr/` — архитектурные решения.
+6. PR diff (через `git diff` или Bash).
+</context>
+
+<task>
+Твоя стадия — **review**. Выносишь машинный вердикт `APPROVED` | `REQUEST_CHANGES` в
+`12-review.md`. Гейт `check_reviewer_verdict` читает вердикт ТОЛЬКО из frontmatter.
+
+<thinking>
+Сначала рассуди по всем 4 осям и собери findings с severity, ТОЛЬКО потом выноси вердикт.
+Правило вердикта: любой P0/P1 → `REQUEST_CHANGES`; только P2/P3 или нет findings → `APPROVED`.
+Отдельно проверь: если `src/` изменён, а документация не обновлена — это P0.
+</thinking>
+
+**Оси проверки:**
+1. **Соответствие ТЗ** — все требования `02-trz.md` реализованы? Критерии `03-acceptance-criteria.md`
+   выполнены?
+2. **Соответствие ADR** — реализация соответствует `06-adr/`? Нет нарушений глобальных ADR
+   (`docs/architecture/adr/`)?
+   - **Трассировка (`docs/_standards/TRACEABILITY.md`):** если PR правит строку/блок с **чужим**
+     маркером `ORCH-NNN`, проверь, что правка **сверена** с его `06-adr` и не ломает зафиксированный
+     инвариант. Правка маркированного инварианта без обоснования / со сломом → **finding ≥ P1**
+     (слом критического инварианта конвейера может быть P0). Это усиление оси, а не отдельная ось.
+3. **Качество кода** — нет явных ошибок/утечек/security-дыр? Есть docstrings на публичных функциях?
+   Тесты содержательные (не тривиальные)?
+   - **Багфикс-трек: регресс-тест (ORCH-019, BR-4).** Если задача — багфикс (метка `Bug` /
+     укороченный маршрут с пропуском `architecture`), исправление кода **обязано** нести
+     новый/изменённый тест-фиксатор дефекта (красный до фикса, зелёный после). Фикс кода без
+     теста-фиксатора → **finding ≥ P1 / REQUEST_CHANGES**. Это усиление оси «качество», а не
+     отдельная ось (структурно дублируется coverage-гейтом ORCH-027).
+4. **Документация — ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА** (приоритет над остальным): если PR меняет `src/`
+   (функционал, API, конфигурацию, конвейер, QG) — документация ДОЛЖНА быть обновлена в том же PR.
+   Проверь: API → `docs/architecture/README.md` (таблица API)? стадии/QG →
+   `docs/architecture/README.md` и/или `docs/architecture/internals.md`? конфигурация → `README.md`
+   (таблица env)? новый компонент → `docs/architecture/README.md`? обновлён `CHANGELOG.md`?
+   архитектурное решение → есть ADR?
+   - **Обзорные доки (ORCH-079):** если PR закрывает/меняет пункт из `README.md` «Известные
+     ограничения» (обзорная витрина проекта), README ДОЛЖЕН быть обновлён в том же PR — пункт снят
+     или помечен закрытым с ORCH-ссылкой. Необновление обзорных доков → **finding ≥ P1**; если
+     ограничение закрыто правкой `src/` без обновления README — это совпадает с P0 «`src/` изменён,
+     документация не обновлена». Это усиление трактовки оси, а не отдельная ось. Та же ось
+     покрывает **витрину системы** (ORCH-011): PR меняет функциональность, описанную в витрине
+     `docs/overview/` (стадии, гейты, агенты, интеграции, способности из `business.md`), а витрина
+     не обновлена → **finding ≥ P1** — расширение трактовки той же оси, не новая ось.
+</task>
+
+<deliverables>
+Через **Write tool** — единственный файл `docs/work-items/<plane-id>/12-review.md` (с машинным
+frontmatter-вердиктом, см. `<output_format>`).
+
+**Скелет:** `docs/_templates/12-review.md`. **Эталон качества review** — work item **ORCH-073** и
+**ORCH-088** (детальные findings со ссылками на правила).
+</deliverables>
+
+<constraints>
+- ❌ Не правь код сам → ✅ фиксируй findings в `12-review.md`, исправляет developer.
+- ❌ Не давай subjective findings без ссылки на правило → ✅ каждый finding привязан к ТЗ/ADR/правилу.
+- ❌ Не пропускай проверку документации → ✅ **если `src/` изменён, а документация (`docs/`,
+  `CHANGELOG.md`, ADR) НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES`** с указанием, какую
+  именно документацию нужно обновить. Документация = golden source наравне с кодом.
+- ❌ PR закрыл пункт из `README.md` «Известные ограничения», но README не обновлён (пункт остался
+  открытым) → ✅ требуй обновления обзорных доков — пункт снят либо помечен закрытым с ORCH-ссылкой;
+  необновление обзорной витрины → **finding ≥ P1** (ORCH-079).
+- ❌ PR меняет функциональность, описанную в витрине `docs/overview/` (стадии, гейты, агенты,
+  интеграции, способности из `business.md`), но витрина не обновлена → ✅ требуй обновления витрины
+  в том же PR; необновление → **finding ≥ P1** (расширение оси обзорных доков ORCH-079 — ORCH-011).
+
+**Severity:**
+- **P0 (blocker):** не реализовано требование ТЗ; нарушен ADR; критическая уязвимость;
+  **документация не обновлена при изменении `src/`**.
+- **P1 (must-fix):** дублирование, отсутствие обработки ошибки, missing test.
+- **P2 (should-fix):** naming, структура, мелкие пропуски.
+- **P3 (nice-to-have):** косметика.
+</constraints>
+
+<output_format>
+Файл `12-review.md` ОБЯЗАН начинаться с YAML-frontmatter. Оркестратор читает вердикт ТОЛЬКО из
+`verdict:` (UPPERCASE, строго `APPROVED` | `REQUEST_CHANGES`). Упоминания в прозе НЕ учитываются;
+без frontmatter → трактуется как not-approved.
+
+**Машинный ключ (НЕ менять имя/регистр/значения):** `verdict: APPROVED | REQUEST_CHANGES`.
+
+Поверх него — обязательная frontmatter-схема 52c (6 полей,
+`src/frontmatter.py::REQUIRED_FIELDS`), `status` согласован с `verdict:`:
+
+| Поле | Значение для reviewer |
+|------|-----------------------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `review` |
+| `author_agent` | `reviewer` |
+| `status` | согласован с `verdict:` (напр. `approved` / `changes-requested`) |
+| `created_at` | текущая дата `YYYY-MM-DD` |
+| `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
+
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
+```markdown
+---
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+work_item: ORCH-NNN
+stage: review
+author_agent: reviewer
+status: approved
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+type: review
+work_item_id: ORCH-NNN
+version: 1
+---
+
+# Review ORCH-NNN
+
+## Summary
+<краткий итог>
+
+## Findings
+
+### P0 — Blocker
+- [ ] <описание> (если есть)
+
+### P1 — Must fix
+- [ ] <описание> (если есть)
+
+### P2 — Should fix
+- [ ] <описание> (если есть)
+
+## Документация
+<статус обновления документации: что обновлено / что нужно обновить>
+```
+
+**Правила вердикта:**
+- `verdict: APPROVED` — только если нет P0/P1.
+- `verdict: REQUEST_CHANGES` — при ЛЮБОМ P0/P1, включая необновлённую документацию.
+- Никаких других значений; без frontmatter QG не пройдёт.
+</output_format>
+
+<success_criteria>
+Выход стадии готов, когда `12-review.md` записан, несёт корректный машинный `verdict:`
+(`APPROVED`|`REQUEST_CHANGES`, UPPERCASE) + frontmatter-схему 52c, а проверка документации выполнена
+явно.
+</success_criteria>
+
+<escalation>
+- **Любой finding P0/P1** (не реализовано требование ТЗ, нарушен ADR, критическая уязвимость,
+  необновлённая документация при изменении `src/`, слом маркированного инварианта) → единая точка:
+  вердикт `REQUEST_CHANGES` с перечнем findings и ссылками на ТЗ/ADR/правило.
+- **Неоднозначность/противоречивость требований** (не ясно, что считать корректным) → finding со
+  ссылкой на конкретное место `02-trz.md`/`03-acceptance-criteria.md`/`06-adr/`, а не subjective-оценка.
+</escalation>

.openclaw/agents/tester.md

@@ -0,0 +1,142 @@
+---
+name: tester
+description: QA-инженер. Прогоняет тесты, оформляет отчёт.
+tools:
+  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/13-test-report.md)
+  - Bash (pytest, curl)
+---
+
+# System prompt: Tester
+
+<context>
+Ты — QA-инженер проекта **orchestrator**. Прогоняешь полный регресс и оформляешь отчёт.
+
+**Перед любым действием прочти:**
+1. `CLAUDE.md` — паспорт и правила.
+2. `docs/architecture/README.md` — конвейер и компоненты.
+3. `docs/work-items/<plane-id>/02-trz.md`.
+4. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
+5. `docs/work-items/<plane-id>/04-test-plan.yaml`.
+6. `docs/work-items/<plane-id>/12-review.md` — убедись, что вердикт `APPROVED`.
+</context>
+
+<task>
+Твоя стадия — **testing**. Прогоняешь регресс и smoke, выносишь машинный вердикт `result:`
+(`PASS`|`FAIL`) в `13-test-report.md`. Гейт `check_tests_passed` читает вердикт из frontmatter.
+
+<thinking>
+Сначала прогони тесты и собери факты (pytest, smoke, покрытие ТЗ), классифицируй каждый TC, и
+ТОЛЬКО потом выноси вердикт. Любой 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` из
+   рабочего дерева именно этой задачи (`/repos/_wt/orchestrator/<branch-slug>/`, например
+   `feature_ORCH-NNN-slug`), где лежит код ветки. Общий чекаут `/repos/orchestrator` могут
+   параллельно переключать другие задачи (гонка checkout) → можно прогнать чужой код. Команда:
+   `cd <worktree-ветки> && pytest tests/ -v --tb=short`.
+3. **Smoke API (read-only):** `curl -s http://localhost:8500/health`, `…/status`, `…/queue`.
+   В ответе `/queue` проверь наличие блока `serial_gate` (ORCH-088) — он должен присутствовать в
+   полезной нагрузке (наряду с `auto_labels`); его отсутствие = регресс смока.
+4. **Покрытие ТЗ:** для **каждого** TC из `04-test-plan.yaml` — выполнен? PASS/FAIL? Сопоставь с
+   критериями `03-acceptance-criteria.md`. Готовность = каждый TC сопоставлен, а не «файл записан».
+</task>
+
+<deliverables>
+Через **Write tool** — единственный файл `docs/work-items/<plane-id>/13-test-report.md` (с машинным
+frontmatter-вердиктом, см. `<output_format>`).
+
+**Скелет:** `docs/_templates/13-test-report.md`. **Эталон полноты отчёта** — work item **ORCH-073**
+и **ORCH-088**.
+</deliverables>
+
+<constraints>
+- ❌ Не пиши продакшн-код → ✅ только прогоняй тесты и фиксируй результаты.
+- ❌ Не подгоняй тесты под код → ✅ если тест падает обоснованно, фиксируй `result: FAIL`.
+- ❌ Не запускай деструктивные операции на прод-контейнере → ✅ smoke только read-only
+  (`/health`, `/status`, `/queue`).
+</constraints>
+
+<output_format>
+Файл `13-test-report.md` ОБЯЗАН начинаться с YAML-frontmatter. Машинный ключ (НЕ менять
+имя/регистр/значения): `result: PASS | FAIL`.
+
+Поверх него — обязательная frontmatter-схема 52c (6 полей, `src/frontmatter.py::REQUIRED_FIELDS`),
+`status` согласован с `result:`:
+
+| Поле | Значение для tester |
+|------|---------------------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) |
+| `stage` | `testing` |
+| `author_agent` | `tester` |
+| `status` | согласован с `result:` (`pass` / `fail`) |
+| `created_at` | текущая дата `YYYY-MM-DD` |
+| `model_used` | резолв ORCH-41 — сейчас `claude-opus-4-8` |
+
+> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
+> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
+> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+
+```markdown
+---
+result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
+work_item: ORCH-NNN
+stage: testing
+author_agent: tester
+status: pass
+created_at: <YYYY-MM-DD>
+model_used: <resolve ORCH-41>
+type: test-report
+work_item_id: ORCH-NNN
+---
+
+# Test Report — ORCH-NNN
+
+## Окружение
+- Python: <версия>
+- pytest: <версия>
+- Дата: <ISO дата>
+
+## Результаты
+
+| TC ID | Описание | Результат |
+|-------|----------|-----------|
+| TC-01 | ... | PASS |
+
+## Вывод pytest
+<вставь вывод>
+
+## Итог
+PASS / FAIL
+```
+
+**Вердикт:**
+- Все тесты PASS + smoke OK → `result: PASS` → задача переходит на `deploy-staging`.
+- Любой FAIL → `result: FAIL` → откат на `development` (`back-to:dev`).
+</output_format>
+
+<success_criteria>
+Выход стадии готов, когда `13-test-report.md` записан, несёт корректный машинный `result:`
+(`PASS`|`FAIL`, UPPERCASE) + frontmatter-схему 52c, таблицу TC и вывод pytest, И **каждый TC из
+`04-test-plan.yaml` выполнен и сопоставлен** с `03-acceptance-criteria.md` (а не только «файл
+записан»).
+</success_criteria>
+
+<escalation>
+- **Обоснованный FAIL** (тест/смок падает по делу) → `result: FAIL` → откат на development
+  (`back-to:dev`); НЕ подгоняй тесты под код.
+- **Смок-сбой инфраструктуры** (окружение/`/health`/`/queue` недоступны) → зафиксируй как
+  `result: FAIL` с диагностикой (что именно недоступно), а не «зелено по умолчанию».
+</escalation>

.task-arch.md

@@ -0,0 +1,4 @@
+Work item: ORCH-061
+Repo: orchestrator
+Branch: feature/ORCH-061-bug-deploy-staging-development
+Stage: architecture

.task-dev.md

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

.task.md

@@ -0,0 +1,8 @@
+Work item: ORCH-061
+Repo: orchestrator
+Branch: feature/ORCH-061-bug-deploy-staging-development
+Stage: analysis
+Title: BUG: deploy-staging петля — откат на development (self-deploy)
+
+Description:
+Симптом: на стадии deploy-staging для self-hosting orchestrator задача откатывается deploy-staging -> development и крутится по кругу.ДВЕ подтверждённые причины (ORCH-58 + ORCH-60):1. check_staging_status FAILED (ложный). deployer гоняет staging_check.py, тот падает на C9a/C9b (sandbox e2e: branch not found + analyst job in queue) с пометкой «Plane comment check skipped: bot-tokens not added to SANDBOX project». 8/10 PASS, 2 ложных FAIL из-за ненастроенных bot-токенов SANDBOX-проекта. QG check_staging_status -> FAILED -> rollback deploy-staging->development. Это НЕ регресс кода, а отсутствие sandbox-настроек.2. no changes to commit. для action-стадий (деплой = рестарт/retag, не правка кода) deployer exit0 + «no changes» тоже трактуется stage_engine как недовыполнение -> откат.Последствие: прод-деплой self-hosting репо НЕВОЗМОЖЕН автономно — ORCH-58 и ORCH-60 доводились ВРУЧНУЮ (merge PR + build-once retag + --deploy). Прямой блокер автономного внедрения (эпик ORCH-54).Fix-направления (одно или оба):(а) Настроить sandbox bot-токены в SANDBOX Plane-проект, чтобы staging_check C9a/C9b проходили честно (10/10). Тогда check_staging_status не будет ложно падать.(б) Отвязать advance deploy-стадии от git-changes для self-deploy репо: успех = exit0 + health PASS (+ опц. staging_check), а не наличие коммита.Acceptance: ORCH-задача для self-hosting orchestrator проходит deploy-staging -> deploy -> Done БЕЗ ручного вмешательства и без петли. Priority P0.

Dockerfile

@@ -1,7 +1,65 @@
 FROM python:3.12-slim
+# ORCH-058 (Strategy B): stamp the image with the git commit it was built from so
+# the deploy hook can fail-close if a stale staging image would be promoted to prod
+# (INV-FRESH). Passed at build time via `--build-arg GIT_SHA=<sha>` (the staging
+# rebuild in check_staging_image_fresh / the --build-staging hook mode supplies it).
+# Without the build-arg the label is empty -> the hook treats it as a mismatch
+# (fail-closed). The OCI-standard key is read by `docker image inspect`.
+ARG GIT_SHA=""
+LABEL org.opencontainers.image.revision=$GIT_SHA
 WORKDIR /app
+RUN apt-get update -qq && apt-get install -y -qq openssh-client git curl ca-certificates && rm -rf /var/lib/apt/lists/*
+# git operations run as root over bind-mounted /repos (may be owned by host uid) -> trust it.
+RUN git config --system --add safe.directory '*'
+# ORCH-022: pinned gitleaks static Go binary for the offline secret-scan sub-gate
+# (07-infra I-1). Baked into the image (NOT a pip package): the gate runs INSIDE the
+# orchestrator container over a per-task worktree. Pinned release => deterministic
+# rules; gitleaks needs no network so the "a secret always blocks" guarantee (BR-2)
+# is independent of internet access. Multi-arch aware (amd64/arm64).
+ARG GITLEAKS_VERSION=8.18.4
+RUN set -eux; \
+    arch="$(dpkg --print-architecture)"; \
+    case "$arch" in \
+      amd64) gl_arch="x64" ;; \
+      arm64) gl_arch="arm64" ;; \
+      *) echo "unsupported arch: $arch" >&2; exit 1 ;; \
+    esac; \
+    curl -fsSL -o /tmp/gitleaks.tar.gz \
+      "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_${gl_arch}.tar.gz"; \
+    tar -xzf /tmp/gitleaks.tar.gz -C /usr/local/bin gitleaks; \
+    chmod +x /usr/local/bin/gitleaks; \
+    rm -f /tmp/gitleaks.tar.gz; \
+    gitleaks version
+# ORCH-58: compose runs the container as uid:gid 1000:1000 (ORCH-40), but the base
+# image has no passwd entry for uid 1000 -> ssh/whoami fail with
+# "No user exists for uid 1000" (rc=255), breaking the detached self-deploy ssh
+# launch (ORCH-36 Phase B). Create a real user 1000 with a home dir so getpwuid()
+# resolves and ssh can start.
+# ORCH-101 (D5): uid/gid/home/username are build ARGs (defaults = current prod
+# values); compose build.args wires APP_UID/APP_GID/APP_HOME from the SAME env
+# vars as the runtime user: and the mount targets, so the ORCH-040 group
+# (uid/gid/HOME/mounts/useradd) moves coherently. APP_USER is passwd cosmetics
+# (the ENTRY matters for getpwuid/ssh, not the name) — Dockerfile-default only.
+ARG APP_UID=1000
+ARG APP_GID=1000
+ARG APP_USER=slin
+ARG APP_HOME=/home/slin
+RUN groupadd -g ${APP_GID} app && useradd -u ${APP_UID} -g ${APP_GID} -m -d ${APP_HOME} -s /bin/bash ${APP_USER}
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
-COPY src/ src/
-RUN mkdir -p /app/data/runs
+COPY src/ ./src/
+# ORCH-021: do NOT `COPY data/ ./data/`. `data/` is gitignored (SQLite DB dir) and
+# is provided at runtime as a bind-mount volume (`./data:/app/data`, see
+# docker-compose.yml) which shadows anything baked into the image — so the COPY was
+# dead weight. Worse, the ORCH-058 staging rebuild (`check_staging_image_fresh`)
+# builds with the task *worktree* as the docker build context; a fresh worktree never
+# contains the untracked `data/`, so `COPY data/` failed `docker build` with exit 1
+# and bounced the task off `deploy-staging`. We just ensure the mountpoint exists.
+RUN mkdir -p /app/data
+ENV PYTHONPATH=/app
+# ORCH-101 (D5): CMD deliberately stays exec-form with the documented 8500
+# default — an ARG cannot reach a runtime CMD, and a shell-form CMD would break
+# the verified `init: true` + exec-form PID-1/signal semantics (B-2). The prod
+# port is parametrised on the compose layer (`command:` with
+# ${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}), which overrides this CMD.
 CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]

README.md

@@ -1,70 +1,332 @@
 # Multi-Agent Orchestrator
 
-FastAPI-сервис для оркестрации мульти-агентного пайплайна разработки.
+> См. [CLAUDE.md](CLAUDE.md) (паспорт проекта) и [docs/architecture/README.md](docs/architecture/README.md) (архитектура).
+>
+> **Витрина системы — [docs/overview/](docs/overview/README.md)**: единая точка входа в документацию
+> (бизнес + тех, 7 блоков, маршруты для заказчика / менеджера / разработчика, презентация). ORCH-011.
 
-## Что делает
+FastAPI-сервис для оркестрации мульти-агентного пайплайна разработки. Принимает webhooks от Plane и Gitea, управляет жизненным циклом задач через Quality Gates, запускает Claude CLI агентов на каждой стадии.
 
-- Принимает webhooks от **Plane** (task management) и **Gitea** (git events)
-- Проверяет Quality Gates перед переходом между стадиями
-- Запускает **Claude CLI** агентов (analyst, architect, developer, reviewer, tester)
-- Ведёт журнал событий в SQLite
+## Архитектура
+
+```
+Plane (task mgmt) ──webhook──┐
+                              ├──► Orchestrator (FastAPI) ──► Quality Gates ──► Agent Launcher
+Gitea (git events) ─webhook──┘         │                                            │
+                                        ▼                                            ▼
+                                   SQLite DB                                   Claude CLI
+                                (events, tasks,                            (analyst, architect,
+                                 agent_runs)                              developer, reviewer, tester)
+```
+
+## Стадии пайплайна
+
+```
+created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
+                          ↑                          │
+                          └───── REQUEST_CHANGES ─────┘  (max 3 retries)
+```
+
+| Стадия | Агент | Quality Gate (выход) | Триггер перехода |
+|--------|-------|---------------------|------------------|
+| created | — | — | Plane webhook (work_item.created) |
+| analysis | analyst | Файлы BRD/TRZ/AC/TestPlan | Push docs/ |
+| architecture | architect | ADR или infra-requirements | Push docs/ |
+| development | developer | check_ci_green (Gitea CI зелёный на ветке) | Auto-advance после developer |
+| review | reviewer | check_reviewer_verdict (`verdict:` во frontmatter 12-review.md) | Auto-advance после reviewer |
+| testing | tester | check_tests_passed (test-report.md) | Auto-advance после tester |
+| deploy-staging | deployer | check_staging_status (15-staging-log.md) | Auto-advance после tester |
+| deploy | deployer | check_deploy_status (14-deploy-log.md) | Auto-advance после staging |
+| done | — | — | — |
 
 ## API Endpoints
 
 | Method | Path | Описание |
 |--------|------|----------|
 | GET | `/health` | Health check |
-| GET | `/status` | Активные задачи |
+| GET | `/status` | Активные задачи (stage != done) |
+| GET | `/queue` | Очередь задач (ORCH-1): counts по статусам + max_concurrency + последние 10 jobs |
 | POST | `/webhook/plane` | Plane webhook receiver |
 | POST | `/webhook/gitea` | Gitea webhook receiver |
+| POST | `/bug-fast-track/escalate?work_item=<id>` | Эскалация багфикс-задачи в полный цикл (ORCH-019): сброс `track` `'bug'→'full'` → следующий переход уходит в `architecture` |
 
-## Настройка
+## Структура проекта
 
-```bash
-cp .env.example .env
-# Заполнить токены в .env
+```
+src/
+├── main.py              # FastAPI app, lifespan (orphan recovery)
+├── config.py            # Pydantic settings (env vars)
+├── db.py                # SQLite: init, get_db, update_task_stage
+├── stages.py            # State machine (transitions, agents, QG)
+├── notifications.py     # Уведомления (логирование)
+├── plane_sync.py        # Синхронизация статусов с Plane API
+├── queue_worker.py      # ORCH-1: фоновый воркер очереди (claim → launch_job)
+├── agents/
+│   └── launcher.py      # AgentLauncher: launch/launch_job, monitor, watchdog, auto-advance
+├── webhooks/
+│   ├── plane.py         # Plane webhook handler
+│   └── gitea.py         # Gitea webhook handler (push, PR, CI status)
+└── qg/
+    └── checks.py        # Quality Gate checks (filesystem + Gitea API)
+data/
+├── orchestrator.db      # SQLite database
+└── runs/                # Agent output logs ({run_id}.log)
+docs/
+├── PRODUCT_VISION.md            # Видение продукта
+├── deployment/
+│   └── LITE_SETUP.md            # Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
+├── architecture/
+│   ├── README.md                # Обзор архитектуры, компоненты, API
+│   ├── internals.md             # Схема БД, потоки, resilience-слой
+│   └── adr/                     # Архитектурные решения (ADR-0001, ADR-0002, ADR-0003)
+├── operations/
+│   ├── INFRA.md                 # Топология, порты, env, self-hosting риски
+│   ├── DEPLOY_HOOK.md           # Деплой-хук
+│   ├── STAGING.md               # Staging-окружение
+│   ├── STAGING_CHECK.md         # Проверки staging
+│   └── SETUP_WEBHOOKS.md        # Настройка webhooks
+├── work-items/                  # Артефакты задач (00-15-*)
+└── history/                     # Исторические записи (BUGFIXES, INCIDENTS, ADR-архив)
+docker-compose.yml       # Deployment config
+Dockerfile               # Python 3.12 + Docker CLI + tini
 ```
 
-## Запуск (Docker)
+## Запуск
+
+### Docker (production)
 
 ```bash
 docker compose up -d --build
 ```
 
-## Запуск (dev)
+### Dev
 
 ```bash
 pip install -r requirements.txt
 uvicorn src.main:app --reload --port 8500
 ```
 
-## Тесты
+## Конфигурация
 
-```bash
-pip install pytest
-pytest tests/ -v
-```
-
-## Переменные окружения
+Все переменные с префиксом `ORCH_`:
 
 | Переменная | Описание | Default |
 |-----------|----------|---------|
 | `ORCH_PLANE_API_URL` | Plane API URL | `http://localhost:8091` |
 | `ORCH_PLANE_API_TOKEN` | Plane API token | — |
-| `ORCH_PLANE_WEBHOOK_SECRET` | Webhook secret для верификации | — |
+| `ORCH_PLANE_WEBHOOK_SECRET` | Webhook secret | — |
+| `ORCH_PLANE_WORKSPACE_SLUG` | Workspace slug | — |
+| `ORCH_PLANE_PROJECT_ID` | Project UUID | — |
 | `ORCH_GITEA_URL` | Gitea URL | `http://localhost:3000` |
 | `ORCH_GITEA_TOKEN` | Gitea API token | — |
 | `ORCH_GITEA_WEBHOOK_SECRET` | Gitea webhook secret | — |
-| `ORCH_CLAUDE_BIN` | Путь к Claude CLI | `/usr/bin/claude` |
-| `ORCH_REPOS_DIR` | Директория с репозиториями | `/home/slin/repos` |
-| `ORCH_DB_PATH` | Путь к SQLite БД | `/app/data/orchestrator.db` |
+| `ORCH_GITEA_OWNER` | Gitea repo owner | `admin` |
+| `ORCH_DEFAULT_REPO` | Default repository (fallback) | `enduro-trails` |
+| `ORCH_PROJECTS_JSON` | Multi-repo реестр (JSON-массив, ORCH-6) | `""` → дефолт в `src/projects.py` |
+| `ORCH_CLAUDE_BIN` | Путь к Claude CLI | `/opt/claude-code/bin/claude.exe` |
+| `ORCH_REPOS_DIR` | Repos dir (container) | `/repos` |
+| `ORCH_HOST_REPOS_DIR` | Repos dir (host) | `/home/slin/repos` |
+| `ORCH_DB_PATH` | SQLite path | `/app/data/orchestrator.db` |
+| `ORCH_RUNS_DIR` | Базовый каталог per-run логов агентов (`<runs_dir>/{run_id}.log`, ORCH-087) | `/app/data/runs` |
+| `ORCH_MAX_CONCURRENCY` | Сколько jobs воркер запускает параллельно (ORCH-1) | `1` |
+| `ORCH_QUEUE_POLL_INTERVAL` | Период опроса очереди воркером, сек (ORCH-1) | `2.0` |
+| `ORCH_PREFLIGHT_CACHE_TTL` | Кэш preflight (CLI/net), сек (ORCH-1 resilience) | `45` |
+| `ORCH_BACKOFF_BASE_SECONDS` | База exp-backoff для transient (429) | `10` |
+| `ORCH_BACKOFF_MAX_SECONDS` | Потолок backoff | `600` |
+| `ORCH_TRANSIENT_MAX_ATTEMPTS` | Ретраи для 429/недоступности | `5` |
+| `ORCH_BREAKER_THRESHOLD` | transient подряд до открытия breaker | `3` |
+| `ORCH_BREAKER_PAUSE_SECONDS` | Пауза при открытом breaker | `300` |
+| `ORCH_RECONCILE_ENABLED` | Kill-switch sweeper потерянных webhook (ORCH-053) | `true` |
+| `ORCH_RECONCILE_PLANE_ENABLED` | Отдельный флаг F-2 (опрос Plane API) | `true` |
+| `ORCH_RECONCILE_INTERVAL_S` | Период фонового прохода reconciler, сек | `120` |
+| `ORCH_RECONCILE_GRACE_DEFAULT_S` | Порог «застряла» по `tasks.updated_at`, сек | `600` |
+| `ORCH_RECONCILE_GRACE_OVERRIDES_JSON` | Per-stage пороги, напр. `{"development":300}` | `""` |
+| `ORCH_RECONCILE_NOTIFY_UNBLOCK` | Telegram при разблокировке застрявшей задачи | `true` |
+| `ORCH_RECONCILE_SKIP_BLOCKED_ENABLED` | F-1 Guard 2 (ORCH-060): пропуск задач в Plane-статусе Blocked / Needs Input; `false` глушит только сетевой Guard 2 (Guard 1 escalated всегда активен) | `true` |
+| `ORCH_QG0_TITLE_MAX` | Верхний лимит длины заголовка QG-0 (вход `_qg0_errors`); невалидное/пустое значение → дефолт (ORCH-069) | `200` |
+| `ORCH_STOP_STATUS_ENABLED` | Kill-switch отмены задачи по Plane-статусу **STOP** + закрытия дыры релонча (ORCH-090); `false` → поведение 1:1 как до ORCH-090 | `true` |
+| `ORCH_STOP_STATUS_REPOS` | CSV область репо для STOP-отмены; пусто = все репо (ORCH-090) | `""` |
+| `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` |
+| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` / `_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-источники bind-маунтов (compose-интерполяция) | боевые пути mva154 |
+| `ORCH_RUN_UID` / `ORCH_RUN_GID` / `ORCH_DOCKER_GID` | ORCH-101: uid:gid контейнера и gid docker-группы (`group_add`, ORCH-040) | `1000`/`1000`/`999` |
 
-## Архитектура
+Тираж платформы на новый хост (полная карта, секреты, smoke) — `docs/operations/REPLICATION.md` (ORCH-101).
+**Lite-тираж под ключ (ORCH-102):** разворачивание орк+watchdog на инфраструктуре заказчика
+по одной сквозной инструкции «голый хост → работающий конвейер» (Plane/Gitea/Telegram/LLM
+заказчик ставит сам и подключает по шагам) — `docs/deployment/LITE_SETUP.md`; канон конфига
+sidecar-watchdog — `.env.watchdog.example`; анти-дрейф — `tests/test_lite_setup_doc.py`.
 
+## Очередь задач (ORCH-1 / F-2b)
+
+Webhook-хэндлеры больше не спавнят claude-агентов синхронно в процессе uvicorn.
+Вместо этого они кладут **job** в персистентную SQLite-таблицу `jobs`
+(`enqueue_job`, мгновенный ответ), а фоновый воркер (`src/queue_worker.py`)
+забирает jobs с учётом `ORCH_MAX_CONCURRENCY` и запускает агента (`launch_job`,
+та же Popen-логика, что и раньше).
+
+Преимущества:
+- **Рестарт-safe.** При старте jobs со статусом `running` возвращаются в `queued`
+  (queue-recovery в lifespan) — работа не теряется.
+- **Лимит параллелизма.** Воркер не превышает `ORCH_MAX_CONCURRENCY`.
+- **Ретраи.** Упавший job (exit≠0) ретраится пока `attempts < max_attempts`,
+  потом `failed` + Telegram-нотификация.
+
+Статусы job: `queued → running → done | failed`; **`cancelled`** — терминальный
+исход STOP-отмены (ORCH-090), нигде не реквью'ится. Наблюдаемость — через `GET /queue`.
+
+## Отмена задачи: статус STOP (ORCH-090)
+
+Перевод задачи в выделенный Plane-статус **STOP** отменяет её: оркестратор
+останавливает активного агента (graceful SIGTERM-каскад), снимает все job'ы
+(терминальный `cancelled`, без авто-requeue), удаляет worktree и **рабочую**
+ветку в Gitea (**никогда** `main`, без force-push), сбрасывает прогресс в
+durable-терминал `tasks.stage='cancelled'` и тумбстонит натуральные ключи
+(`#cancelled-<id>`), чтобы повторный «To Analyse» создал задачу **с нуля**.
+Docs-артефакты (`01..17`) сохраняются. STOP во время критичного шага merge/deploy
+— **откладывается** до его честного завершения (никакого half-merge / рестарта
+прода). Параллельно закрыта «дыра релонча»: ручной перевод в промежуточный рабочий
+статус больше не релончит агента — единственный вход к запуску пайплайна остаётся
+«To Analyse» (релонч агента сменой статуса разрешён только на стадии `analysis` —
+владельце Needs Input). Всё под kill-switch `ORCH_STOP_STATUS_ENABLED`, аддитивно,
+never-raise. Наблюдаемость — блок `stop` в `GET /queue`. Деталь — `docs/work-items/
+ORCH-090/06-adr/ADR-001-stop-cancel-task.md` + сквозной
+`docs/architecture/adr/adr-0026-stop-cancel-task.md`.
+
+> **Инфра-предусловие:** на доске Plane проекта ORCH создать статус **«STOP»** с
+> группой `cancelled`. До создания статуса фича в fail-safe (нет UUID → ветка STOP
+> не активируется).
+
+## Багфикс-трек: дешёвый маршрут для багов (ORCH-019)
+
+Задача с меткой Plane `Bug` (имя метки — `ORCH_BUG_FAST_TRACK_LABEL`, дефолт `Bug`)
+идёт **укороченным маршрутом** конвейера: `analysis(lite) → development → review →
+testing → deploy-staging → deploy → done`, т.е. **пропускается стадия `architecture`**
+(отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`).
+Мини-аналитик выдаёт облегчённый пакет (короткий bug-report + обязательный план
+регресс-теста), но всё равно все 4 файла analysis — гейт `check_analysis_complete`
+не меняется.
+
+**Корневой инвариант:** упрощается только аналитика/архитектура — **все Quality
+Gate'ы и под-гейты исполняются без изменений** (`STAGE_TRANSITIONS` / `QG_CHECKS` /
+`check_*` / machine-verdict ключи — байт-в-байт прежние). Маршрутизация багфикса —
+свойство планировщика (routing-override в `advance_stage` по `tasks.track='bug'`),
+**не** Quality Gate.
+
+Классификация (`src/bug_fast_track.py`, never-raise): локальный `bug_fast_track_applies(repo)`
+ПЕРВЫМ (выключенный флаг = нулевой сетевой оверхед), затем `is_bug_task` через
+`labels.has_label` (источник истины — Plane API). Тип хранится в аддитивной колонке
+`tasks.track` (`'full'` | `'bug'`), читается в горячем пути из БД (не из сети).
+**Эскалация** сложного/архитектурного бага в полный цикл — `POST /bug-fast-track/escalate?work_item=<id>`
+(сброс `'bug'→'full'`). Всё под kill-switch `ORCH_BUG_FAST_TRACK_ENABLED`, область —
+`ORCH_BUG_FAST_TRACK_REPOS` (пусто → self-hosting only), fail-safe → полный цикл.
+Наблюдаемость — блок `bug_fast_track` в `GET /queue` + отметка `🐞` в Telegram-карточке.
+Деталь — `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md` + сквозной
+`docs/architecture/adr/adr-0032-bug-fast-track.md`.
+
+> **Инфра-предусловие:** на доске Plane проекта ORCH создать метку **`Bug`**. До её
+> создания фича в fail-safe (нет метки → задача идёт полным циклом).
+
+**Resilience-слой:** дешёвый preflight (CLI/net, кэш, без токенов) гейтит claim;
+429/overload детектится по логу (transient vs permanent), transient ретраится с
+exp-backoff (`available_at`, Retry-After); circuit breaker паузит воркер после N
+transient подряд. Подробности: `docs/history/ORCH-1_JOB_QUEUE.md`.
+
+## Multi-repo: реестр проектов (ORCH-6)
+
+Оркестратор обслуживает несколько репозиториев через реестр проектов
+(`src/projects.py`), ключ = **Plane project id**. Plane-webhook фильтрует события
+по проекту (неизвестный проект → `ignored`) и резолвит `repo` / `work_item_prefix` /
+Plane-проект из маппинга.
+
+По умолчанию (если `ORCH_PROJECTS_JSON` пуст) зарегистрированы два проекта:
+
+| Проект | Plane project id | repo | prefix |
+|--------|------------------|------|--------|
+| enduro-trails | `7a79f0a9-5278-49cd-9007-9a338f238f9c` | `enduro-trails` | `ET` |
+| orchestrator | `8da6aa25-a60e-44d6-a1e2-d8ae59aa7d6a` | `orchestrator` | `ORCH` |
+
+### Как добавить новый проект
+
+1. Убедись, что gitea-репо уже клонировано в `/repos/<repo>` (авто-clone — отдельно).
+2. Узнай Plane project uuid (из URL проекта в Plane или через Plane API).
+3. Добавь запись в `ORCH_PROJECTS_JSON` в `.env` (JSON-массив). **Важно:** если
+   задаёшь `ORCH_PROJECTS_JSON`, он полностью заменяет дефолт — перечисли **все**
+   нужные проекты (включая enduro-trails и orchestrator):
+
+   ```bash
+   ORCH_PROJECTS_JSON='[
+     {"plane_project_id":"7a79f0a9-5278-49cd-9007-9a338f238f9c","repo":"enduro-trails","work_item_prefix":"ET","name":"enduro-trails"},
+     {"plane_project_id":"8da6aa25-a60e-44d6-a1e2-d8ae59aa7d6a","repo":"orchestrator","work_item_prefix":"ORCH","name":"orchestrator"},
+     {"plane_project_id":"<новый-uuid>","repo":"<новый-repo>","work_item_prefix":"<PREFIX>","name":"<имя>"}
+   ]'
+   ```
+
+4. Пересобери: `docker compose up -d --build`.
+5. Проверь резолв:
+   ```bash
+   docker exec orchestrator python3 -c "from src.projects import get_project_by_plane_id as g; print(g('<новый-uuid>'))"
+   ```
+
+Поля `name` опционально (по умолчанию = `repo`). Подробности — `docs/architecture/internals.md`.
+
+## Ключевые механизмы
+
+### Auto-advance
+После успешного завершения агента (exit_code=0), `_try_advance_stage()` проверяет QG и автоматически продвигает задачу + запускает следующего агента.
+
+### Review bounce
+При REQUEST_CHANGES от reviewer задача откатывается в development, developer перезапускается (до 3 попыток). При исчерпании — эскалация.
+
+### Orphan recovery (M-1)
+При старте контейнера каждый run с `finished_at IS NULL` старше 35 минут помечается exit_code=-1, логируется per-run warning и отправляется Telegram-уведомление «нужна ручная проверка/перезапуск» (не молча).
+
+### Запись task-файлов (B-1)
+Task-файлы `.task-*.md` пишутся **прямой записью в смонтированный volume `/repos/<repo>/`** (без docker). При ошибке записи — RuntimeError (не молчит). В `.gitignore` проекта.
+
+### Логи агентов (B-2)
+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).
+
+### Event routing
+Gitea events роутятся по типу:
+- `push` → проверка файлов, advance architecture/development
+- `pull_request*` (wildcard) → review approved/rejected, PR merge
+- `status` → Gitea CI статус; ORCH-045: авторитетный гейт развития (`development → review`) — `check_ci_green` читает статус ветки с polling-retry (устраняет гонку «pending сразу после push»)
+
+## Тесты
+
+```bash
+pytest tests/ -v
 ```
-Plane webhook ──┐
-                ├──► Orchestrator ──► Quality Gates ──► Agent Launcher ──► Claude CLI
-Gitea webhook ──┘         │
-                          ▼
-                      SQLite (events, tasks, agent_runs)
-```
+
+## Известные ограничения
+
+Реально открытые ограничения (сверено с кодом, ORCH-079):
+
+1. **Telegram 48h** — карточки-сироты старше 48 часов неудаляемы (лимит Telegram Bot API); зачистка сирот самозалечивает только свежие (ORCH-087).
+2. **Зависимости задач — только intra-repo (v1)** — `job_deps` выражают связи в пределах одного репозитория; кросс-репо зависимости пока не поддержаны (ORCH-026).
+3. **Пакетный автоном — Этап 1** — per-repo serial gate сериализует задачи одного репо (ORCH-088); полный пакетный автономный прогон «10–20 задач за ночь» — в развитии (эпик ORCH-088).
+
+### Закрыто (история)
+
+Пункты, ранее значившиеся ограничениями, закрыты кодом — оставлены как трассировка:
+
+- **Single-task / shared `/repos` checkout** → git worktree per task (`ensure_worktree`) + serial-gate (ORCH-088) + task-deps (ORCH-026).
+- **In-process daemon-потоки** → персистентная очередь задач (SQLite `jobs`, `src/queue_worker.py`), restart-safe (ORCH-1).
+- **Gitea CI не настроен** → активный гейт стадии `development` — `check_ci_green` (`src/qg/checks.py`); `check_tests_local` помечен DEPRECATED.
+- **No retry on API errors** → exp-backoff + circuit breaker в `queue_worker.py` (`ORCH_BACKOFF_*` / `ORCH_BREAKER_*` / `ORCH_TRANSIENT_MAX_ATTEMPTS`) + retry-loop в `check_ci_green` (ORCH-1 resilience / ORCH-045).
+- **Plane sync — маппинг issue ID** → зрелый `src/plane_sync.py` (`find_issue_id`, `fetch_issue_sequence_id`) со статус-моделью и TTL-самозалечиванием (ORCH-010 / 066 / 068).
+- **Tester timeout — Playwright e2e** → orchestrator является pytest-сервисом (Playwright неприменим); реальный механизм — конфигурируемый watchdog (`agent_timeout_seconds`, ORCH-7).

deploy/bundled/.env.example

@@ -0,0 +1,61 @@
+# deploy/bundled/.env — конфиг bundle-ИНФРЫ (ORCH-103, ADR-001 D2).
+# Канонический example: 100% ключей интерполяции deploy/bundled/docker-compose.yml
+# (key-set-sync держит tests/test_bundle_compose.py) + ключи init-кред, которые
+# заполняет bootstrap. Создание: cp .env.example .env (или это сделает
+# scripts/bootstrap_bundle.py apply); права 600.
+#
+# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ (TR-8): этот файл читает ТОЛЬКО compose-интерполяция
+# bundle (авто-чтение .env из project dir deploy/bundled/). Runtime-конфиг самого
+# оркестратора и watchdog — КОРНЕВЫЕ .env / .env.watchdog (каноны Lite 1:1:
+# .env.example / .env.watchdog.example, карта — docs/operations/REPLICATION.md §2).
+# Единственный писатель всех live-файлов — scripts/bootstrap_bundle.py: дублируемые
+# ключи (uid/gid, HOME, пути Claude CLI) когерентны механически, не дисциплиной.
+#
+# DO NOT COMMIT реальный deploy/bundled/.env (покрыт неякорным `.env` в .gitignore).
+# Секреты: НИ ОДНОГО дефолтного пароля — пустые значения ниже генерирует bootstrap
+# (stdlib secrets) и никогда не печатает (NFR-3); повторный запуск НЕ перетирает
+# существующие значения без явного --force-secrets.
+
+# --- Публичная точка инсталляции -------------------------------------------
+# Хост, по которому браузер оператора открывает Plane/Gitea и по которому
+# строятся публичные ссылки (ORCH_GITEA_PUBLIC_URL / ORCH_PLANE_WEB_URL / WEB_URL
+# Plane / ROOT_URL Gitea). HTTPS/домены/reverse-proxy заказчика — вне bundle.
+BUNDLE_PUBLIC_HOST=localhost
+
+# --- Карта публикуемых портов (D4: только человеческие точки) ---------------
+# Конфликт порта на хосте → отказ preflight bootstrap ДО любых мутаций (BR-7).
+BUNDLE_ORCH_PORT=8500
+BUNDLE_PLANE_PORT=8080
+BUNDLE_GITEA_HTTP_PORT=3000
+
+# --- Идентичность контейнера орка (реюз имён ORCH-101: один факт = одно имя) --
+# uid:gid владельца deploy/bundled/repos (инвариант ORCH-040); docker-gid хоста
+# («МИНА 1», узнать: getent group docker). Заполняет bootstrap из id -u/-g/getent.
+ORCH_RUN_UID=1000
+ORCH_RUN_GID=1000
+ORCH_DOCKER_GID=999
+# HOME всех акторов в контейнере (группа ORCH-040 двигается одной переменной).
+ORCH_AGENT_HOME_DIR=/home/orchestrator
+
+# --- LLM-предусловие хоста заказчика (bundle НЕ поставляет Claude CLI) -------
+# Пути дистрибутива claude-code/node и кред CLI на хосте (канон — LITE_SETUP §7).
+ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
+ORCH_HOST_NODE_BIN=/usr/bin/node
+ORCH_HOST_CLAUDE_DIR=~/.claude
+ORCH_HOST_CLAUDE_JSON=~/.claude.json
+
+# --- Внутренние креды Plane CE-стека (upstream-имена; значения — bootstrap) --
+POSTGRES_USER=plane
+POSTGRES_PASSWORD=
+POSTGRES_DB=plane
+SECRET_KEY=
+RABBITMQ_DEFAULT_USER=plane
+RABBITMQ_DEFAULT_PASS=
+RABBITMQ_DEFAULT_VHOST=plane
+MINIO_ROOT_USER=plane-minio-admin
+MINIO_ROOT_PASSWORD=
+
+# --- Init-креды Gitea (D6: один пользователь-бот = админ, владелец репо,
+#     носитель API-токена; создаёт bootstrap через `gitea admin user create`) --
+GITEA_ADMIN_USERNAME=orchestrator-bot
+GITEA_ADMIN_PASSWORD=

deploy/bundled/docker-compose.yml

@@ -0,0 +1,338 @@
+# ORCH-103 (Type B Bundled, ADR-001 D1–D4): самодостаточный compose ВСЕГО стека
+# для тиража «под ключ» на хост заказчика: orchestrator + orchestrator-watchdog +
+# Gitea + Plane CE (зеркало официального selfhost-référence makeplane/plane
+# v0.23.1: имена сервисов и env-контракт — upstream, анти-дрейф к их докам; наши
+# отличия от référence: пиннинг неподвижными тегами литералом вместо ${APP_RELEASE}
+# (NFR-6, держится tests/test_bundle_compose.py), убраны replicas/platform/SENTRY,
+# секреты БЕЗ дефолтных значений — их генерирует scripts/bootstrap_bundle.py).
+#
+# Этот файл НЕ исполняется в нашем прод-контуре (корневой docker-compose.yml —
+# байт-в-байт, заморожен анти-дрейфом ORCH-102); активация — только явный запуск
+# оператором на целевом хосте (паттерн ORCH-009, kill-switch не нужен).
+#
+# Конфиг-слои (D2): интерполяции ${VAR} читаются compose'ом из deploy/bundled/.env
+# (авто-чтение из project dir — без --env-file-футгана); канон ключей —
+# deploy/bundled/.env.example (key-set-sync держит тест). Runtime-конфиг орка и
+# watchdog — КОРНЕВЫЕ .env / .env.watchdog (канон Lite 1:1, REPLICATION §2);
+# их единственный писатель — bootstrap_bundle.py.
+#
+# Сеть (D4): одна bridge-сеть проекта; машинный трафик — строго сервис-DNS
+# (Plane→орк http://orchestrator:8500/webhook/plane, Gitea→орк .../webhook/gitea,
+# орк→Plane http://proxy, орк→Gitea http://gitea:3000); network_mode: host НЕ
+# используется (ssh-деплой-контур нашего хоста в bundle структурно спит —
+# ORCH_DEPLOY_SSH_HOST пуст). Наружу публикуются ТОЛЬКО человеческие порты
+# (орк/Plane proxy/Gitea web); postgres/redis/mq/minio не публикуются.
+#
+# Project name = узнаваемый префикс томов/контейнеров orchestrator-bundle_* (D1);
+# container_name сознательно НЕ пиннится ни у кого — bundle и Lite/корневой
+# compose не сталкиваются по именам на одном хосте.
+name: orchestrator-bundle
+
+networks:
+  default:
+    name: orchestrator-bundle
+    driver: bridge
+
+# Env-контракт Plane CE — upstream-имена (référence v0.23.1). Значения секретов
+# (POSTGRES_PASSWORD/SECRET_KEY/RABBITMQ_DEFAULT_PASS/MINIO_ROOT_PASSWORD) живут
+# ТОЛЬКО в deploy/bundled/.env (генерирует bootstrap); дефолтных паролей нет.
+x-plane-env: &plane-env
+  environment:
+    - WEB_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
+    - DEBUG=0
+    - CORS_ALLOWED_ORIGINS=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
+    - GUNICORN_WORKERS=1
+    # db (upstream-имена; host/port — фиксированные сервис-DNS этого файла)
+    - PGHOST=plane-db
+    - PGDATABASE=${POSTGRES_DB:-plane}
+    - POSTGRES_USER=${POSTGRES_USER:-plane}
+    - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
+    - POSTGRES_DB=${POSTGRES_DB:-plane}
+    - POSTGRES_PORT=5432
+    - PGDATA=/var/lib/postgresql/data
+    - DATABASE_URL=postgresql://${POSTGRES_USER:-plane}:${POSTGRES_PASSWORD}@plane-db:5432/${POSTGRES_DB:-plane}
+    # redis
+    - REDIS_HOST=plane-redis
+    - REDIS_PORT=6379
+    - REDIS_URL=redis://plane-redis:6379/
+    # rabbitmq
+    - RABBITMQ_HOST=plane-mq
+    - RABBITMQ_PORT=5672
+    - RABBITMQ_DEFAULT_USER=${RABBITMQ_DEFAULT_USER:-plane}
+    - RABBITMQ_DEFAULT_PASS=${RABBITMQ_DEFAULT_PASS}
+    - RABBITMQ_DEFAULT_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
+    - RABBITMQ_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
+    - AMQP_URL=amqp://${RABBITMQ_DEFAULT_USER:-plane}:${RABBITMQ_DEFAULT_PASS}@plane-mq:5672/${RABBITMQ_DEFAULT_VHOST:-plane}
+    # application secret (генерирует bootstrap; дефолта сознательно НЕТ)
+    - SECRET_KEY=${SECRET_KEY}
+    # datastore (minio)
+    - USE_MINIO=1
+    - AWS_REGION=
+    - AWS_ACCESS_KEY_ID=${MINIO_ROOT_USER:-plane-minio-admin}
+    - AWS_SECRET_ACCESS_KEY=${MINIO_ROOT_PASSWORD}
+    - AWS_S3_ENDPOINT_URL=http://plane-minio:9000
+    - AWS_S3_BUCKET_NAME=uploads
+    - MINIO_ROOT_USER=${MINIO_ROOT_USER:-plane-minio-admin}
+    - MINIO_ROOT_PASSWORD=${MINIO_ROOT_PASSWORD}
+    - BUCKET_NAME=uploads
+    - FILE_SIZE_LIMIT=5242880
+    # live server
+    - API_BASE_URL=http://api:8000
+    # proxy
+    - NGINX_PORT=80
+
+services:
+  # ── Платформа: орк + sidecar-watchdog (образы собираются из этого же чекаута;
+  #    корневой Dockerfile / watchdog/Dockerfile — без правок, NFR-1) ──────────
+  orchestrator:
+    build:
+      context: ../..
+      # ORCH-101 (D5): uid/gid/home двигаются ОДНОЙ группой с user: и таргетами
+      # маунтов ниже (инвариант ORCH-040). Дефолты bundle нейтральны (D2).
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/orchestrator}
+    restart: unless-stopped
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    init: true
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]
+    ports:
+      # человеческая точка: операторский smoke `curl /health` (D4)
+      - "${BUNDLE_ORCH_PORT:-8500}:8500"
+    volumes:
+      # данные/репозитории — bind ВНУТРИ project dir (uid-причины ORCH-040;
+      # покрыты .gitignore: неякорный data/ + deploy/bundled/repos/)
+      - ./data:/app/data
+      - ./repos:/repos
+      - /var/run/docker.sock:/var/run/docker.sock
+      # LLM-предусловие хоста заказчика (bundle его НЕ поставляет, BRD §1.3)
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-~/.claude}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-~/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude.json:ro
+      # ssh-контур в bundle сознательно НЕ вводится (ADR D8): git-доступ агентов
+      # — HTTP token-remote, деплой-хуки нашего хоста структурно спят.
+    # runtime-конфиг орка собирает bootstrap (шаг 8); required:false — первый
+    # `up -d` поднимает стек ДО сборки конфига (AC-1), орк жив без него.
+    env_file:
+      - path: ../../.env
+        required: false
+    environment:
+      - ORCH_REPOS_DIR=/repos
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  orchestrator-watchdog:
+    build:
+      context: ../..
+      dockerfile: watchdog/Dockerfile
+    restart: unless-stopped
+    init: true
+    mem_limit: 128m
+    mem_reservation: 32m
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+      - ./repos:/repos:ro
+      - ./data:/app/data:ro
+    env_file:
+      - path: ../../.env.watchdog
+        required: false
+    environment:
+      # bundle-сеть ≠ host-network Lite: метрики — по сервис-DNS; имя контейнера
+      # орка детерминировано project name (container_name не пиннится, D1).
+      # environment перекрывает env_file → когерентность механическая (TR-8).
+      - WATCHDOG_METRICS_URL=http://orchestrator:8500/metrics
+      - WATCHDOG_CONTAINERS=orchestrator-bundle-orchestrator-1
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  # ── Gitea (D6): официальный образ, НЕ rootless; init полностью автоматом —
+  #    bootstrap создаёт админа/токен через `gitea admin ...` CLI в контейнере.
+  #    Branch protection на main НЕ настраивается (норматив D10 ORCH-009/INV-4).
+  gitea:
+    image: gitea/gitea:1.22.6
+    restart: unless-stopped
+    ports:
+      - "${BUNDLE_GITEA_HTTP_PORT:-3000}:3000"
+    environment:
+      - GITEA__database__DB_TYPE=sqlite3
+      - GITEA__security__INSTALL_LOCK=true
+      - GITEA__server__DOMAIN=${BUNDLE_PUBLIC_HOST:-localhost}
+      - GITEA__server__ROOT_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_GITEA_HTTP_PORT:-3000}/
+      # ssh-контур не вводится (D8): порт не публикуется, ssh выключен.
+      - GITEA__server__DISABLE_SSH=true
+      - GITEA__service__DISABLE_REGISTRATION=true
+      # МИНА TR-4 (D4): Gitea по умолчанию режет webhook'и в приватные адреса —
+      # без этой строки «задача не появилась» гарантирован.
+      - GITEA__webhook__ALLOWED_HOST_LIST=orchestrator
+    volumes:
+      - gitea-data:/data
+    healthcheck:
+      test: ["CMD", "curl", "-fsS", "http://localhost:3000/api/healthz"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  # ── Plane CE — зеркало upstream selfhost-référence v0.23.1 (D3) ────────────
+  web:
+    <<: *plane-env
+    image: makeplane/plane-frontend:v0.23.1
+    restart: unless-stopped
+    command: node web/server.js web
+    depends_on:
+      - api
+      - worker
+
+  space:
+    <<: *plane-env
+    image: makeplane/plane-space:v0.23.1
+    restart: unless-stopped
+    command: node space/server.js space
+    depends_on:
+      - api
+      - worker
+      - web
+
+  admin:
+    <<: *plane-env
+    image: makeplane/plane-admin:v0.23.1
+    restart: unless-stopped
+    command: node admin/server.js admin
+    depends_on:
+      - api
+      - web
+
+  live:
+    <<: *plane-env
+    image: makeplane/plane-live:v0.23.1
+    restart: unless-stopped
+    command: node live/dist/server.js live
+    depends_on:
+      - api
+      - web
+
+  api:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-api.sh
+    volumes:
+      - logs_api:/code/plane/logs
+    depends_on:
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  worker:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-worker.sh
+    volumes:
+      - logs_worker:/code/plane/logs
+    depends_on:
+      - api
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  beat-worker:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: unless-stopped
+    command: ./bin/docker-entrypoint-beat.sh
+    volumes:
+      - logs_beat-worker:/code/plane/logs
+    depends_on:
+      - api
+      - plane-db
+      - plane-redis
+      - plane-mq
+
+  migrator:
+    <<: *plane-env
+    image: makeplane/plane-backend:v0.23.1
+    restart: "no"
+    command: ./bin/docker-entrypoint-migrator.sh
+    volumes:
+      - logs_migrator:/code/plane/logs
+    depends_on:
+      - plane-db
+      - plane-redis
+
+  plane-db:
+    <<: *plane-env
+    image: postgres:15.7-alpine
+    restart: unless-stopped
+    command: postgres -c 'max_connections=1000'
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  plane-redis:
+    <<: *plane-env
+    image: valkey/valkey:7.2.5-alpine
+    restart: unless-stopped
+    volumes:
+      - redisdata:/data
+    healthcheck:
+      test: ["CMD", "valkey-cli", "ping"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  plane-mq:
+    <<: *plane-env
+    image: rabbitmq:3.13.6-management-alpine
+    restart: always
+    volumes:
+      - rabbitmq_data:/var/lib/rabbitmq
+    healthcheck:
+      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
+      interval: 15s
+      timeout: 10s
+      retries: 12
+
+  plane-minio:
+    <<: *plane-env
+    # upstream-référence держит latest — bundle пиннит неподвижный тег (NFR-6)
+    image: minio/minio:RELEASE.2024-05-28T17-19-04Z
+    restart: unless-stopped
+    command: server /export --console-address ":9090"
+    volumes:
+      - uploads:/export
+    healthcheck:
+      test: ["CMD", "curl", "-fsS", "http://localhost:9000/minio/health/live"]
+      interval: 10s
+      timeout: 5s
+      retries: 12
+
+  proxy:
+    <<: *plane-env
+    image: makeplane/plane-proxy:v0.23.1
+    restart: unless-stopped
+    ports:
+      # человеческая точка: UI Plane в браузере оператора (D4)
+      - "${BUNDLE_PLANE_PORT:-8080}:80"
+    depends_on:
+      - web
+      - api
+      - space
+
+# Состояние Plane/Gitea — именованные тома проекта (префикс orchestrator-bundle_,
+# D1/D2); preflight bootstrap детектирует «грязный хост» по этому префиксу.
+volumes:
+  pgdata:
+  redisdata:
+  uploads:
+  logs_api:
+  logs_worker:
+  logs_beat-worker:
+  logs_migrator:
+  rabbitmq_data:
+  gitea-data:

docker-compose.yml

@@ -1,13 +1,147 @@
+# ORCH-101 (replication foundation): every host-specific value is interpolated
+# as ${VAR:-default}; the defaults equal the current production values, so an
+# empty environment resolves to a byte-for-byte equivalent of the previous file
+# (zero regression, BR-5). Compose reads ${VAR} from the project `.env` /shell —
+# NOT from a service's env_file (so .env.staging does NOT interpolate); the
+# Settings-shared names (ORCH_AGENT_HOME_DIR, ORCH_STAGING_PORT, ...) are read
+# by pydantic from env_file AND by compose from .env — one name per fact (D1).
+# Container-side paths (/app/data, /repos, /opt/claude-code, docker.sock) are a
+# container-layout convention, NOT host values — deliberately not parametrised.
+# See docs/operations/REPLICATION.md for the full variable map.
 services:
   orchestrator:
-    build: .
+    build:
+      context: .
+      # ORCH-101 (D5): uid/gid/home move as ONE coherent group with the runtime
+      # user: and the mount targets below (ORCH-040 invariant).
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
     container_name: orchestrator
     restart: unless-stopped
-    ports:
-      - "127.0.0.1:8500:8500"
+    # ORCH-040: бежим под uid:gid хоста (slin=1000:1000), а не root, чтобы
+    # артефакты конвейера (worktree + docs) создавались как slin:slin и git на
+    # хосте работал без ручного chown. Доступ к docker.sock сохранён через
+    # group_add: ["999"] (МИНА 1 — НЕ удалять). См. ADR-001 ORCH-040.
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    # init: true injects docker-init (tini) as PID 1 so reparented grandchild
+    # processes from the claude/node subprocess tree are reaped (no zombies, B-2).
+    init: true
+    network_mode: host
+    # ORCH-101 (D5): the prod port is configurable on the compose layer (the
+    # Dockerfile CMD keeps its exec-form 8500 default — ADR-001 D5); the default
+    # resolves byte-for-byte to the previous image CMD. Reuses the existing
+    # ORCH_DEPLOY_PROD_TARGET_PORT (no second truth about the prod port).
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}"]
     volumes:
       - ./data:/app/data
-      - /home/slin/repos:/repos:ro
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /var/run/docker.sock:/var/run/docker.sock
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
+      # ORCH-040: target согласован с HOME (launcher: settings.agent_home_dir),
+      # не /root/.ssh — обе стороны двигаются одной переменной ORCH_AGENT_HOME_DIR.
+      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
     env_file: .env
     environment:
       - ORCH_REPOS_DIR=/repos
+      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
+      # legacy enduro deployer (read via os.environ, keep as-is):
+      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - DEPLOY_SSH_HOST=127.0.0.1
+      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      # ORCH-036 self-deploy (read via pydantic ORCH_ prefix; host-network -> 127.0.0.1, ssh key mounted):
+      - ORCH_DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - ORCH_DEPLOY_SSH_HOST=127.0.0.1
+      - ORCH_DEPLOY_HOOK_SCRIPT=scripts/orchestrator-deploy-hook.sh
+      - ORCH_DEPLOY_HOST_REPO_PATH=${ORCH_DEPLOY_HOST_REPO_PATH:-/home/slin/repos/orchestrator}
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  # ORCH-100 (FND/F1b): sidecar-watchdog — the monitoring brain in a SEPARATE
+  # container (observer separated from observed, ADR-001 D2). Deploying it builds
+  # ONLY this service — the prod `orchestrator` is NOT rebuilt/restarted.
+  #   * network_mode: host -> /metrics reachable at http://127.0.0.1:8500/metrics
+  #     and host interfaces visible for memory/disk reads.
+  #   * docker.sock mounted :ro AND the code is GET-only (double read-only guard).
+  #   * host disk paths bind-mounted :ro so shutil.disk_usage sees the host FS but
+  #     can never write (opt-in disk ceiling, D6).
+  #   * mem_limit caps the thin stdlib daemon (D2): OOM = early "sidecar grew" signal.
+  #   * WATCHDOG_ENABLED=false (or simply not starting the service) -> inert.
+  orchestrator-watchdog:
+    build:
+      context: .
+      dockerfile: watchdog/Dockerfile
+    container_name: orchestrator-watchdog
+    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:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos:ro
+      - ./data:/app/data:ro
+    # Optional env_file (required: false): a missing .env.watchdog must NOT fail
+    # `docker compose up` for the prod orchestrator (self-hosting safety). Absent
+    # file -> WATCHDOG_* defaults, no token -> fail-safe (logs, does not send).
+    env_file:
+      - path: .env.watchdog
+        required: false
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"
+
+  # ORCH-31: staging instance (port 8501, isolated DB).
+  # Starts ONLY with: docker compose --profile staging up -d orchestrator-staging
+  # Normal "docker compose up -d" does NOT start this service.
+  orchestrator-staging:
+    profiles:
+      - staging
+    build:
+      context: .
+      args:
+        APP_UID: ${ORCH_RUN_UID:-1000}
+        APP_GID: ${ORCH_RUN_GID:-1000}
+        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
+    container_name: orchestrator-staging
+    restart: unless-stopped
+    # ORCH-040: тот же uid хоста, что и у prod (см. комментарий выше / ADR-001).
+    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    init: true
+    network_mode: host
+    # ORCH-101 (D4): the same ORCH_STAGING_PORT that settings.staging_port reads —
+    # the image_freshness rebuild target and the listening port can never drift.
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_STAGING_PORT:-8501}"]
+    volumes:
+      - ./data/staging:/app/data
+      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /var/run/docker.sock:/var/run/docker.sock
+      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
+      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
+      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
+      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
+      # ORCH-040: target согласован с HOME (settings.agent_home_dir), не /root/.ssh.
+      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
+    env_file: .env.staging
+    environment:
+      - ORCH_REPOS_DIR=/repos
+      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
+      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - DEPLOY_SSH_HOST=127.0.0.1
+      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      # Staging DB is isolated via ./data/staging volume mount.
+      # Inside the container the path remains /app/data/orchestrator.db (same default),
+      # but on the host it physically lives at ./data/staging/orchestrator.db —
+      # completely separate from prod ./data/orchestrator.db.
+      - ORCH_DB_PATH=/app/data/orchestrator.db
+    group_add:
+      - "${ORCH_DOCKER_GID:-999}"

docs/PRODUCT_VISION.md

@@ -0,0 +1,135 @@
+# Product Vision — Автономная фабрика разработки (Orchestrator)
+
+> Мультиагентная платформа, которая превращает идею или баг в задеплоенный на прод результат — автономно, надёжно и дёшево.
+
+**Версия:** 1.0 · **Дата:** 2026-06-04 · **Статус:** концепция развития
+
+> **Фактическое текущее состояние платформы** (что уже умеет, как устроена) — витрина системы
+> [docs/overview/](overview/README.md) (ORCH-011). Этот документ — vision: «куда идём».
+
+---
+
+## 1. Зачем это (бизнес-взгляд)
+
+### Проблема
+Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор, разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря времени, контекста и денег. Мелкая фича или баг едут днями.
+
+### Решение
+**Orchestrator** — это конвейер из ИИ-агентов, который проводит задачу через все стадии разработки сам: от бизнес-постановки до релиза на прод. Человек ставит задачу и принимает результат. Всё между — автономно.
+
+### Ценность
+- ⚡ **Скорость:** фича проходит полный цикл (анализ → архитектура → код → ревью → тесты → деплой) за ~35 минут без ручных вмешательств.
+- 💰 **Стоимость:** работа агентов в разы дешевле команды; адаптивный выбор моделей экономит на простых задачах.
+- 🎯 **Автономность:** 0 ручных пинков в штатном прогоне. Человек — постановщик и приёмщик, а не оператор.
+- 🛡️ **Надёжность:** многоуровневые гейты качества не пускают недоделку на прод.
+- 🔁 **Масштаб:** одна платформа ведёт несколько проектов; саму платформу можно тиражировать на новые хосты.
+
+---
+
+## 2. Как это работает (обзор)
+
+### Конвейер
+```
+created → analysis → architecture → development → review → testing → deploy → done
+```
+На каждом переходе стоит **quality gate** — автоматическая проверка, которая не пускает задачу дальше, пока стадия не выполнена честно:
+
+| Переход | Гейт | Что проверяет |
+|---|---|---|
+| analysis → architecture | check_analysis_approved | BRD/TRZ/AC готовы + апрув человека |
+| architecture → development | check_architecture_done | Архитектура/ADR зафиксированы |
+| development → review | check_ci_green | CI зелёный (тесты проходят) |
+| review → testing | check_reviewer_verdict | Машинный вердикт ревьюера: APPROVED |
+| testing → deploy | check_tests_passed | Машинный вердикт тестера (не подделать) |
+| deploy → done | check_deploy_status | Деплой реально успешен, лог в origin/main |
+
+### Агенты
+- **Analyst** — собирает бизнес-требования, пишет BRD/TRZ/критерии приёмки.
+- **Architect** — проектирует решение, фиксирует ADR.
+- **Developer** — пишет код в изолированном git-worktree.
+- **Reviewer** — ревьюит, выносит машинный вердикт.
+- **Tester** — прогоняет тесты, фиксирует результат в отчёте.
+- **Deployer** — мержит, тегирует, деплоит на прод, пишет deploy-log.
+
+### Объекты
+- **Project** — проект в реестре (Plane project ↔ git-репозиторий ↔ префикс задач).
+- **Work-Item** — задача, проходящая конвейер; на каждой стадии накапливает артефакты (00-business-request … 14-deploy-log).
+- **Job** — единица работы в очереди (atomic claim, ретраи, restart-safe).
+
+### Интеграции
+- **Plane** — управление задачами, статусы как триггеры конвейера, webhooks.
+- **Gitea** — репозитории, PR, защита main (pre-receive hook).
+- **Telegram** — живой трекер прогресса, апрувы, уведомления.
+- **LLM** — модели агентов (сейчас Claude, в планах мультипровайдерность).
+
+---
+
+## 3. Что уже сделано (фундамент)
+
+✅ **Автономный конвейер** — подтверждён живым прогоном: задача от issue до Done без ручных вмешательств (~35 мин).
+✅ **Очередь задач** — atomic claim, max_concurrency, ретраи, restart-safe.
+✅ **Изоляция через git-worktree** — каждая задача в своём дереве, без конфликтов в shared-репо.
+✅ **Машинные гейты качества** — вердикты читаются из структурированных артефактов, а не угадываются по тексту.
+✅ **Multi-repo** — платформа ведёт несколько проектов (enduro-trails, сам orchestrator).
+✅ **Идемпотентность webhooks** — дедуп по delivery-id, защита от дублей.
+✅ **Наблюдаемость** — учёт токенов и стоимости каждой задачи.
+✅ **Живой Telegram-трекер** — прогресс редактируется в одном сообщении, без спама.
+
+---
+
+## 4. Куда движемся (дорожная карта)
+
+Развитие сгруппировано в 5 стратегических направлений.
+
+### 🛡️ Надёжность и безопасность
+- **Post-deploy мониторинг + авто-rollback** — следить за продом после релиза, откатывать при деградации.
+- **Security-гейт** — secret-scanning + аудит зависимостей перед мержем.
+- **Бюджетный circuit-breaker** — хард-лимит стоимости на задачу, защита от «убегающих» расходов.
+- **Опциональная human-приёмка** — финальный взгляд человека для критичных фич.
+
+### 💰 Экономика и интеллект
+- **Мультипровайдерность LLM** — Claude, OpenRouter, другие провайдеры на выбор.
+- **Оценка задачи** — прогноз стоимости/времени до старта.
+- **Адаптивный выбор модели** — по сложности: тривиальное на дешёвой, сложное на сильной.
+- **Багфикс-трек** — упрощённый дешёвый путь для багов (без потери качества).
+
+### 🏗️ Платформа и масштаб
+- **Self-hosting** — оркестратор пилит сам себя через собственный конвейер.
+- **Саморазвитие** — петля уроков: ловить отклонения → фиксировать → предлагать улучшения.
+- **Онбординг проектов** — turnkey-заведение нового проекта в систему.
+- **Тиражирование** — развернуть платформу на новой инфраструктуре под ключ.
+
+### 💬 Взаимодействие с человеком
+- **UX/UI дизайнер** — макеты интерфейсов на этапе аналитики.
+- **Интерактивный аналитик** — живой диалог для уточнения требований и обсуждения макетов.
+- **Единые коммент-артефакты** — все агенты прикладывают результаты с кликабельными ссылками.
+- **Прямые ссылки в Telegram** — апрув в один клик, без блужданий.
+
+### 🧩 Расширение возможностей
+- **Тяжёлые расчёты данных** — опциональная стадия для миграций/обработки больших данных.
+- **Android-разработка** — мобильный стек через тот же конвейер.
+- **Декомпозиция эпиков** — большая фича → подзадачи → сборка.
+- **Управление зависимостями** — задача B ждёт задачу A.
+- **Code coverage gate** — защита покрытия тестами от деградации.
+- **База знаний проекта** — персистентный контекст для агентов.
+
+---
+
+## 5. Принципы (что для нас неизменно)
+
+1. **Автономность по умолчанию, человек — на ключевых развилках.** Машина делает, человек ставит и принимает.
+2. **Качество не приносится в жертву скорости/цене.** Удешевляем аналитику — гейты качества остаются. Урок дорого выученный: срезанная проверка = недоделка на проде.
+3. **Машинные вердикты, а не угадывание.** Гейты читают структурированные поля, а не ищут слова в тексте.
+4. **Самоизменение — только через PR + ревью + апрув.** Агент, меняющий агентов, всегда под контролем человека.
+5. **Документация — сразу, не потом.** Изменил функционал → обновил доки.
+6. **Прод — источник правды.** «Деплой прошёл» ≠ «работает». Проверяем реальный результат.
+
+---
+
+## 6. Видение в одну фразу
+
+> **Самодостаточная фабрика разработки, которая размножается, учится на ошибках, оценивает себя, бережёт бюджет и не ломает прод — превращая намерение человека в работающий продукт почти без его участия.**
+
+---
+
+*Документ поддерживается в репозитории orchestrator. Источник дорожной карты — задачи проекта ORCH в Plane (ORCH-7…ORCH-28).*

docs/_standards/HANDOFF_PROTOCOL.md

@@ -0,0 +1,118 @@
+# HANDOFF_PROTOCOL — формальный контракт handoff «стадия → обязательный выход»
+
+> **Назначение.** Нормативная спека: что КАЖДАЯ стадия конвейера обязана оставить на выходе —
+> какие документы и какие frontmatter-ключи. Дополняет [`PIPELINE_DOCS.md`](PIPELINE_DOCS.md)
+> (карта «документ → агент → стадия → гейт → machine-key») «вертикальным» срезом по стадиям и
+> вводит **обязательную frontmatter-схему** для машинной проверки.
+>
+> **Статус истины (важно).** Источник истины поведения — **код**: `src/stages.py`
+> (`STAGE_TRANSITIONS`), `src/qg/checks.py` (`QG_CHECKS` / `check_*` / `_parse_*`),
+> `src/stage_engine.py` (врезки под-гейтов). Машинный контракт чтения/записи/валидации
+> frontmatter — `src/frontmatter.py`. Эта спека **документирует**; при расхождении первичен код
+> (правило ORCH-075).
+
+Введено задачей **ORCH-076** (ORCH-52c — слой 2 эпика ORCH-52: машинный контракт). Слой 1
+(ORCH-075/52b) дал описательный стандарт документов; ORCH-52c реализовала единый машинный
+frontmatter-контракт (reader + writer + валидатор) и свела чтение пяти вердиктов к одной точке
+парсинга. Сквозной ADR: [`adr-0020-frontmatter-contract.md`](../architecture/adr/adr-0020-frontmatter-contract.md);
+детально — [`ORCH-076/06-adr/ADR-001-frontmatter-contract.md`](../work-items/ORCH-076/06-adr/ADR-001-frontmatter-contract.md).
+
+---
+
+## 1. Обязательная frontmatter-схема (машинный источник: `frontmatter.REQUIRED_FIELDS`)
+
+Forward-looking аддитивная схема: набор полей, которые handoff-документ стадии **должен** нести
+в ведущем YAML-frontmatter. Машинный источник истины — кортеж
+[`src/frontmatter.py`](../../src/frontmatter.py) `REQUIRED_FIELDS`:
+
+| Поле | Смысл |
+|------|-------|
+| `work_item` | ID задачи (`ORCH-NNN` / `ET-NNN`) — к какой задаче относится выход |
+| `stage` | стадия, на выходе которой написан документ (`analysis` … `deploy`) |
+| `author_agent` | роль-автор (`analyst` / `architect` / `developer` / `reviewer` / `tester` / `deployer`) |
+| `status` | человеко/машинно-читаемый статус выхода стадии |
+| `created_at` | дата создания артефакта (YYYY-MM-DD) |
+| `model_used` | модель агента, сгенерировавшего артефакт (`claude-…`) |
+
+**Режим проверки (ORCH-52c, критично для self-hosting).** Валидатор схемы
+`frontmatter.validate_schema` / `maybe_warn_schema` по умолчанию **warning-only** и **никогда не
+влияет на boolean-вердикт ни одного гейта**: отсутствие полей логируется (`logger.warning`), но не
+роняет конвейер и не заваливает гейт. Жёсткий режим (hard-fail) зарезервирован на будущее
+(ORCH-52d) и включается ТОЛЬКО kill-switch'ем `frontmatter_validation_strict`
+(env `ORCH_FRONTMATTER_VALIDATION_STRICT`, дефолт `False`). Схема **аддитивна**: старый
+документ-вердикт без этих полей читается гейтом ровно как раньше (см. §3).
+
+---
+
+## 2. Контракт handoff по стадиям
+
+Категории документов — как в `PIPELINE_DOCS.md` §2: **required** (всегда), **when-applicable**
+(при наличии предмета: инфра / данные / security / post-deploy — отсутствие не нарушение).
+«Machine-verdict ключ» — поле, которое exit-гейт/под-гейт ребра читает ТОЛЬКО из frontmatter
+(никогда из прозы). Набор документов/ключей/гейтов **согласован 1:1 с `PIPELINE_DOCS.md` §2–§3**.
+
+| Стадия (выход) | Агент | Обязательные документы на выходе | Machine-verdict ключ (читает гейт ребра) | Гейт ребра |
+|----------------|-------|----------------------------------|------------------------------------------|------------|
+| `created` | система (`_create_initial_docs`) / заказчик | `00-business-request.md` | — (вход, не гейтится) | — |
+| `analysis` | analyst | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | — (гейт проверяет наличие файлов + Approved) | `check_analysis_approved` |
+| `architecture` | architect | `06-adr/ADR-NNN-<slug>.md` (≥1); `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md` (when-applicable/required-info) | — (гейт проверяет наличие `06-adr/` ≥1 ИЛИ `07-…`) | `check_architecture_done` |
+| `development` | developer | код + тесты в ветке (артефакт-док не пишется; гейт — зелёный CI) | — (гейт читает CI-статус Gitea) | `check_ci_green` |
+| `review` | reviewer | `12-review.md` | `verdict:` (`APPROVED` \| `REQUEST_CHANGES`) | `check_reviewer_verdict` |
+| `testing` | tester | `13-test-report.md` | `result:` / `verdict:` / `status:` (`PASS` \| `FAIL` \| `BLOCKED`; три равноранговых, ORCH-047) | `check_tests_passed` |
+| `deploy-staging` | deployer | `15-staging-log.md` (required для self-hosting); `17-security-report.md` (security-под-гейт, when-applicable) | `staging_status:` (`SUCCESS` \| `FAILED`); `security_status:` (`PASS` \| `FAIL`) | `check_staging_status` (ребро); под-гейты ребра `deploy-staging→deploy`: `check_security_gate` → `check_branch_mergeable` → `check_staging_image_fresh` |
+| `deploy` | deployer / deploy-finalizer | `14-deploy-log.md` | `deploy_status:` (`SUCCESS` \| `FAILED`) | `check_deploy_status` |
+| `done` | — | — (терминал) | — | — |
+| пост-`done` наблюдение | post-deploy-monitor | `16-post-deploy-log.md` (when-applicable, ORCH-021) | `post_deploy_status:` (`HEALTHY` \| `DEGRADED`) — **информационный, не гейт** | — (телеметрия петли уроков / наблюдаемость) |
+
+### Примечания (нормативные)
+
+- **Под-гейты ребра `deploy-staging → deploy`** (`check_security_gate` → `check_branch_mergeable`
+  → `check_staging_image_fresh`) — это **врезки в `advance_stage`**, а НЕ строки
+  `STAGE_TRANSITIONS`. Их порядок и условность раската не меняются этой спекой.
+- **`15-staging-log.md`** обязателен только для self-hosting репо (`orchestrator`); для прочих
+  репо staging-гейт — N/A (ORCH-35), документ не требуется.
+- **`16-post-deploy-log.md`** несёт `post_deploy_status:`, но это **информационный** ключ
+  (телеметрия ORCH-8 / наблюдаемость), гейтом он НЕ парсится.
+- **`09-…` / `05-…` / `11-…`** — зарезервированные/legacy номера; канон reviewer'а — `12-review.md`.
+
+---
+
+## 3. Machine-verdict доки vs информационные (честный механизм проверки)
+
+Полностью согласовано с `PIPELINE_DOCS.md` §3. Machine-verdict док — гейт читает ТОЛЬКО
+YAML-frontmatter (через единый `frontmatter.parse_frontmatter`), маппит ключ в вердикт; имя ключа
+чувствительно к регистру, значение парсер приводит к верхнему регистру.
+
+| Документ | Machine-key | Парсер | Эффект вердикта |
+|----------|-------------|--------|-----------------|
+| `12-review.md` | `verdict:` | `check_reviewer_verdict` | `APPROVED` → дальше; `REQUEST_CHANGES` → откат на `development` |
+| `13-test-report.md` | `result:` / `verdict:` / `status:` | `_parse_tests_verdict` | `PASS` → дальше; `FAIL`/`BLOCKED` → откат (негативный токен авторитетен) |
+| `14-deploy-log.md` | `deploy_status:` | `_parse_deploy_status` | `SUCCESS` → `done`; `FAILED` → откат (БАГ-8) |
+| `15-staging-log.md` | `staging_status:` | `_parse_staging_status` | `SUCCESS` → дальше; `FAILED` → откат (self-hosting; иначе N/A) |
+| `17-security-report.md` | `security_status:` | `check_security_gate` → `parse_security_status` | `PASS` → дальше; `FAIL` → откат |
+
+**Информационные доки** (гейтом НЕ парсятся): `00-business-request.md`, `08-data-requirements.md`,
+`10-tech-risks.md`, `16-post-deploy-log.md`.
+
+**Аддитивность схемы (§1).** Документ-вердикт БЕЗ полей схемы из §1, но с вердикт-ключом, читается
+гейтом РОВНО как раньше: схема не участвует в вычислении вердикта при дефолтном
+`frontmatter_validation_strict=False`.
+
+---
+
+## 4. Единый машинный контракт — `src/frontmatter.py`
+
+Все операции с frontmatter сведены в один leaf-модуль (never-raise):
+
+- `read_frontmatter_value(path, key) -> str | None` — single-key reader (контракт неизменен, BC).
+- `parse_frontmatter(content) -> FrontmatterParse` — **единственная точка** парсинга YAML-frontmatter
+  (`data` / `has_block` / `malformed` / `yaml_error`); пять вердикт-парсеров делегируют сюда.
+- `parse_frontmatter_dict` / `read_frontmatter` — ярлыки к распарсенному mapping.
+- `render_frontmatter` / `write_frontmatter` — writer (формат совместим с существующими парсерами).
+- `validate_schema` / `REQUIRED_FIELDS` / `maybe_warn_schema` — схема §1 (warning-only по умолчанию).
+- `strip_frontmatter` — общий хелпер тела (заменил дубли).
+- Kill-switch жёсткой валидации: `config.frontmatter_validation_strict`
+  (env `ORCH_FRONTMATTER_VALIDATION_STRICT`, дефолт `False`).
+
+> Перед написанием номерного дока бери скелет из [`docs/_templates/`](../_templates/) и **не меняй
+> имя machine-key frontmatter** (регистр чувствителен — иначе гейт упадёт ложно).

docs/_standards/PIPELINE_DOCS.md

@@ -0,0 +1,160 @@
+# PIPELINE_DOCS — стандарт документов конвейера (golden source структуры)
+
+> **Назначение.** Единая карта «стадия → агент → документ → категория → гейт/механизм →
+> frontmatter machine-key» + конвенция ADR-naming. Это **golden source структуры** номерных
+> документов work item (`00-business-request.md` … `18-coverage-report.md`), который каждая
+> агентская роль пишет на своей стадии.
+>
+> **Статус истины (важно).** Манифест **документирует** текущее поведение гейтов, но НЕ является
+> их источником истины. Источник истины — код: `src/stages.py` (`STAGE_TRANSITIONS`),
+> `src/qg/checks.py` (`QG_CHECKS` / `check_*` / `_parse_*`), `src/stage_engine.py`. При будущей
+> правке гейта первична правка кода, манифест обновляется следом (ORCH-075 / ADR-001 §D2).
+>
+> **Копируемые скелеты** каждого документа — в каталоге [`docs/_templates/`](../_templates/):
+> «скопировал → заполнил → не угадываешь структуру/ключ».
+
+Введён задачей **ORCH-075** (ORCH-52b — слой 1 эпика ORCH-52). Сквозной ADR:
+[`docs/architecture/adr/adr-0019-pipeline-docs-standard.md`](../architecture/adr/adr-0019-pipeline-docs-standard.md);
+детально — `docs/work-items/ORCH-075/06-adr/ADR-001-pipeline-docs-standard.md`.
+
+---
+
+## 1. Конвейер стадий (ground-truth `STAGE_TRANSITIONS`)
+
+```
+created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
+                          ↑                          │
+                          └──── REQUEST_CHANGES ──────┘  (откат на development, max 3 retries)
+```
+
+Каждое ребро несёт ровно один exit-гейт (`src/stages.py`):
+`check_analysis_approved → check_architecture_done → check_ci_green → check_reviewer_verdict →
+check_tests_passed → check_staging_status → check_deploy_status`.
+
+**Под-гейты ребра `deploy-staging → deploy`** (`check_security_gate` → `check_branch_mergeable` →
+`check_staging_image_fresh`) — это **врезки в `advance_stage`**, а НЕ строки `STAGE_TRANSITIONS`.
+Аналогично под-гейт ребра `deploy → done` (`_handle_merge_verify`, ORCH-071/073) — врезка, не
+зарегистрированный QG. Карта стадий о них не «лжёт»: они не являются стадиями.
+
+---
+
+## 2. Манифест: документ → агент → категория → стадия → гейт → machine-key
+
+Категории: **required** (пишется всегда), **when-applicable** (пишется при наличии предмета:
+инфра / данные / security / post-deploy — отсутствие не нарушение), **optional** / **legacy**.
+
+| Документ | Владелец-агент | Категория | Стадия написания | Гейт / механизм проверки | Frontmatter machine-key |
+|----------|----------------|-----------|------------------|--------------------------|-------------------------|
+| `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` | то же | — |
+| `06-adr/ADR-NNN-<slug>.md` | architect | required | `architecture` | `check_architecture_done` (наличие каталога `06-adr/` ≥1 файл ИЛИ `07-infra-requirements.md`) | — |
+| `07-infra-requirements.md` | architect | when-applicable | `architecture` | `check_architecture_done` (учитывается при наличии) | — |
+| `08-data-requirements.md` | architect | when-applicable | `architecture` | информационный (гейтом не парсится) | — |
+| `10-tech-risks.md` | architect | required | `architecture` | информационный (гейтом не парсится) | — |
+| `12-review.md` | reviewer | required | `review` | `check_reviewer_verdict` | `verdict:` (`APPROVED` \| `REQUEST_CHANGES`) |
+| `13-test-report.md` | tester | required | `testing` | `check_tests_passed` (`_parse_tests_verdict`) | `result:` / `verdict:` / `status:` (`PASS` \| `FAIL` \| `BLOCKED`; три равноранговых, ORCH-047) |
+| `14-deploy-log.md` | deployer / deploy-finalizer | required | `deploy` | `check_deploy_status` (`_parse_deploy_status`) | `deploy_status:` (`SUCCESS` \| `FAILED`) |
+| `15-staging-log.md` | deployer | required (self-hosting) | `deploy-staging` | `check_staging_status` (self-hosting; иначе N/A — ORCH-35) | `staging_status:` (`SUCCESS` \| `FAILED`) |
+| `16-post-deploy-log.md` | post-deploy-monitor | when-applicable | пост-`done` наблюдение (ORCH-021; не ребро `STAGE_TRANSITIONS`) | информационный (гейтом не парсится) | `post_deploy_status:` (`HEALTHY` \| `DEGRADED`) |
+| `17-security-report.md` | security-гейт (детерминированный, ORCH-022) | when-applicable | под-гейт ребра `deploy-staging→deploy` | `check_security_gate` (врезка в `advance_stage`) | `security_status:` (`PASS` \| `FAIL`) |
+| `18-coverage-report.md` | coverage-гейт (детерминированный, ORCH-027) | when-applicable | под-гейт ребра `deploy-staging→deploy` (ПОСЛЕ merge-gate, ДО image-freshness) | `check_coverage_gate` (врезка в `advance_stage`) | `coverage_status:` (`PASS` \| `FAIL`) |
+
+### Примечания манифеста (нормативные)
+
+- **Под-гейты ребра `deploy-staging→deploy`** (`check_security_gate` → `check_branch_mergeable` →
+  `check_staging_image_fresh`) исполняются как врезки в `advance_stage`, а НЕ строки
+  `STAGE_TRANSITIONS`. Не путать с exit-гейтами рёбер.
+- **`09-review.md`** — legacy fallback от старой нумерации; **канон — `12-review.md`**. В основную
+  таблицу как канон не вносится; reviewer пишет `12-review.md`.
+- **Категория `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` им не парсится).
+
+---
+
+## 3. Machine-verdict доки vs информационные (честный механизм проверки)
+
+**Machine-verdict доки** — гейт читает ТОЛЬКО YAML-frontmatter (никогда прозу), маппит ключ в
+вердикт. Имя ключа чувствительно к регистру; значение парсер приводит к верхнему регистру.
+
+| Документ | Machine-key | Парсер (`src/qg/checks.py`) | Эффект вердикта |
+|----------|-------------|-----------------------------|-----------------|
+| `12-review.md` | `verdict:` | `check_reviewer_verdict` | `APPROVED` → дальше; `REQUEST_CHANGES` → откат на `development` |
+| `13-test-report.md` | `result:` / `verdict:` / `status:` | `_parse_tests_verdict` | `PASS` → дальше; `FAIL`/`BLOCKED` → откат |
+| `14-deploy-log.md` | `deploy_status:` | `_parse_deploy_status` | `SUCCESS` → `done`; `FAILED` → откат (БАГ-8) |
+| `15-staging-log.md` | `staging_status:` | `_parse_staging_status` | `SUCCESS` → дальше; `FAILED` → откат (self-hosting; иначе N/A) |
+| `17-security-report.md` | `security_status:` | `check_security_gate` | `PASS` → дальше; `FAIL` → откат |
+| `18-coverage-report.md` | `coverage_status:` | `check_coverage_gate` | `PASS` → дальше; `FAIL` → откат на `development` |
+
+**Информационные доки** — гейтом НЕ парсятся (структура ничего не блокирует):
+`00-business-request.md` (вход), `08-data-requirements.md`, `10-tech-risks.md`,
+`16-post-deploy-log.md` (несёт `post_deploy_status:`, но это телеметрия петли уроков ORCH-8 /
+наблюдаемость, не гейт).
+
+---
+
+## 4. Конвенция ADR-naming
+
+### Per-work-item ADR (основное)
+
+- **Путь:** `docs/work-items/<plane-id>/06-adr/`
+- **Имя файла:** `ADR-NNN-<kebab-slug>.md`
+  - `NNN` — 3-значный, начинается с `001`; инкремент при нескольких ADR в одной задаче
+    (`ADR-001-…`, `ADR-002-…`).
+  - `<kebab-slug>` — kebab-case (нижний регистр, слова через дефис), отражает суть решения.
+- **Стадия:** пишет **architect** на стадии `architecture`; гейтится `check_architecture_done`
+  (наличие каталога `06-adr/` ≥ 1 файла).
+
+### Сквозной (cross-cutting) ADR
+
+Решения, затрагивающие несколько компонентов/ролей или поведение всего конвейера, **дублируются**
+в глобальный реестр:
+
+- **Путь:** `docs/architecture/adr/`
+- **Имя файла:** `adr-NNNN-<kebab-slug>.md` (4-значная сквозная нумерация, последовательная по
+  всему репозиторию; на момент ORCH-075 реестр доходит до `adr-0019`).
+
+### Примеры из репозитория (реальные, проверенные)
+
+- `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`
+- `docs/work-items/ORCH-089/06-adr/ADR-001-auto-label-gates.md`
+- `docs/work-items/ORCH-071/06-adr/ADR-001-merge-verify-gate.md`
+- Сквозные: `docs/architecture/adr/adr-0017-serial-gate.md`,
+  `docs/architecture/adr/adr-0018-auto-label-gates.md`.
+
+---
+
+## 5. Как пользоваться шаблонами
+
+1. Скопируй нужный скелет из [`docs/_templates/`](../_templates/) в
+   `docs/work-items/<plane-id>/` под канонным именем (для ADR — `06-adr/ADR-001-<slug>.md`).
+2. Заполни секции; **не удаляй** machine-key frontmatter у machine-verdict доков и **не меняй имя
+   ключа** (регистр чувствителен — иначе гейт упадёт ложно).
+3. Сверяйся с манифестом (§2–§3): какой агент, на какой стадии, какой гейт читает документ.
+
+> Стандарт **описательный** (слой 1). **Машинный слой реализован в ORCH-52c (ORCH-076):** единый
+> frontmatter-контракт (reader + writer + валидатор) в [`src/frontmatter.py`](../../src/frontmatter.py)
+> и формальная спека handoff [`HANDOFF_PROTOCOL.md`](HANDOFF_PROTOCOL.md) («стадия → обязательный
+> выход» + обязательная frontmatter-схема `REQUIRED_FIELDS`). Пять вердикт-парсеров
+> (`check_reviewer_verdict`, `_parse_tests_verdict`, `_parse_deploy_status`, `_parse_staging_status`,
+> `parse_security_status`) читают вердикт через ОДНУ точку парсинга (`parse_frontmatter`); семантика
+> вердиктов 1:1. Валидатор обязательной схемы по умолчанию **warning-only** (kill-switch
+> `frontmatter_validation_strict`, дефолт `False`) — соблюдение схемы пока на ответственности агента
+> и reviewer'а, enforcement придёт с ORCH-52d.
+
+---
+
+## 6. Спека handoff (машинный контракт, ORCH-52c)
+
+Вертикальный срез «стадия → обязательные документы + frontmatter-ключи на выходе» и обязательная
+frontmatter-схема вынесены в отдельную нормативную спеку [`HANDOFF_PROTOCOL.md`](HANDOFF_PROTOCOL.md)
+(набор документов/ключей/гейтов согласован 1:1 с §2–§3 этого манифеста). Машинный источник
+обязательной схемы — `frontmatter.REQUIRED_FIELDS`.

docs/_standards/TRACEABILITY.md

@@ -0,0 +1,147 @@
+# TRACEABILITY — стандарт маркеров-трассировки `ORCH-NNN` (golden source трассировки)
+
+> **Назначение.** Единый нормативный контракт: как нетривиальная строка/блок/инвариант в коде
+> привязывается к work item, который его ввёл, и к его архитектурному решению (ADR). Это **слой 4
+> (трассировка)** эпика **ORCH-52** — рядом с `PIPELINE_DOCS.md` (слой 1, структура документов) и
+> `HANDOFF_PROTOCOL.md` (слой 2, машинный frontmatter-контракт).
+>
+> **Статус истины.** Документ **кодифицирует сложившуюся практику**, а не вводит новый синтаксис.
+> Источник истины о *поведении* остаётся код (`src/stages.py`, `src/qg/checks.py`,
+> `src/stage_engine.py`); этот стандарт — описательно-нормативный, **не машинный гейт конвейера**.
+> Соблюдение держится на дисциплине агентов + оси ревью (`reviewer.md`), а не на CI-lint.
+
+Введён задачей **ORCH-078** (ORCH-52e). Сквозной ADR:
+[`docs/architecture/adr/adr-0022-traceability-marker-standard.md`](../architecture/adr/adr-0022-traceability-marker-standard.md);
+детально — `docs/work-items/ORCH-078/06-adr/ADR-001-traceability-marker-standard.md`. Продолжает
+цепочку стандартов эпика 52: adr-0019 (52b), adr-0020 (52c), adr-0021 (52d).
+
+---
+
+## 1. Назначение и определение
+
+**Маркер `ORCH-NNN`** (а для проекта enduro-trails — `ET-NNN`) в коде = обязательный стандарт
+трассировки: он привязывает нетривиальную строку / блок / инвариант к work item, который его ввёл,
+и к его ADR. Это даёт читающему агенту прямой путь «строка кода → решение, которое её породило»,
+вместо `git blame`-археологии.
+
+**Факт (сверено на 2026-06-09):** в `src/` де-факто живёт **51 уникальный** маркер `ORCH-NNN`
+(`grep -rhoE 'ORCH-[0-9]+' src/ | sort -u | wc -l` → `51`) — сложившаяся практика. Этот стандарт её
+формализует. **Массовый ретро-фит существующих 51 маркера вне объёма** — стандарт нормативен «на
+будущее»: его правила применяются к **новому и правимому** коду.
+
+---
+
+## 2. Формат маркера
+
+Маркер — это **inline-комментарий** (или фрагмент docstring модуля/функции), содержащий идентификатор
+work item `ORCH-NNN`. Рекомендуется рядом указывать ссылку на конкретное решение в ADR, чтобы трасса
+вела не просто к задаче, а к пункту решения:
+
+```python
+# Ordering term — ``t2.id < jobs.task_id`` (FIFO, ORCH-088, ADR-001 D1 / FR-2): a task
+# does not enter `analysis` while an earlier unfinished task exists in the same repo.
+```
+
+Нового синтаксиса не вводится — кодифицируется уже сложившийся стиль (`ORCH-NNN[, ADR-001 D1]`).
+
+---
+
+## 3. Где ставится маркер
+
+Маркер ставится рядом с **нетривиальным инвариантом**, понимание которого требует контекста решения:
+
+- выбор fail-open / fail-closed поведения;
+- точное условие сериализации / упорядочивания (FIFO, lease, барьер);
+- идемпотентность / защита от повторной обработки;
+- обходимая «дыра» конвейера, которую блок закрывает;
+- любое условие, чьё «почему именно так» зафиксировано в ADR.
+
+Маркер **НЕ ставится** на тривиальном/самоочевидном коде (геттеры, простые присваивания, очевидные
+проверки) — это только зашумляет.
+
+**Правило для нового кода:** вводишь значимый инвариант → ставь маркер своей задачи (`ORCH-NNN`)
+рядом, по возможности со ссылкой на пункт ADR.
+
+---
+
+## 4. Как читать историю (с реальным проверяемым примером)
+
+Пошагово, от строки кода к решению:
+
+1. Видишь в коде маркер `ORCH-NNN` у строки/блока, который собираешься менять.
+2. Открываешь его архитектурное решение: `docs/work-items/ORCH-NNN/06-adr/`.
+3. Читаешь зафиксированный инвариант ПЕРЕД правкой; не ломаешь его (см. §7).
+
+**Проверяемый пример из реального кода (`main`):**
+
+> `src/serial_gate.py` несёт условие сериализации `t2.id < jobs.task_id` с маркером **ORCH-088**
+> и отсылкой `ADR-001 D1 / FR-2` (FIFO-уточнение serial-gate). Чтобы понять, почему задача не входит
+> в `analysis`, пока в репо есть более ранняя незавершённая задача, читаешь:
+> `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`.
+
+Пример ссылается на **реально существующие** в `main` файл и ADR — иначе стандарт опровергал бы сам
+себя (нерабочая трассировка).
+
+---
+
+## 5. Fallback-доступ к чужому ADR
+
+Папки `docs/work-items/ORCH-NNN/` может **не быть в текущей ветке** (она срезана от `main` без неё —
+типично для ветки другой задачи). Штатный способ прочитать чужой ADR — взять его из `origin/main`:
+
+```bash
+git fetch origin                                                  # при необходимости заранее
+git ls-tree origin/main:docs/work-items/ORCH-NNN/06-adr/          # листинг доступных ADR
+git show origin/main:docs/work-items/ORCH-NNN/06-adr/ADR-001-<slug>.md   # прочитать конкретный
+```
+
+Это не блокер: отсутствие папки в ветке ≠ отсутствие решения — оно всегда есть в `main`.
+
+---
+
+## 6. Анти-археология: 3+ маркеров → сводный сквозной ADR
+
+Если функция/блок несёт **3+** маркеров `ORCH-NNN` (эволюционировал через много задач), раскопки по
+каждому work item нечитаемы. Вместо перечисления всех задач ставится **одна сводная ссылка на
+сквозной ADR** (`docs/architecture/adr/adr-NNNN-*`), агрегирующий эволюцию.
+
+Числовой порог `3` — граница, за которой inline-перечисление перестаёт быть читаемым (один-два
+маркера ещё информативны, три и больше — уже археология).
+
+**Пример из кода:** `src/merge_gate.py` несёт маркеры ORCH-043/065/071/073 (и ещё несколько) →
+читать сводные сквозные `adr-0006` (merge-gate), `adr-0013` (merge-verify-gate),
+`adr-0014` (sha-source-of-truth), `adr-0016` (ensure-open-PR) в `docs/architecture/adr/`, а не 8
+отдельных work item.
+
+Это конвенция для **нового/правимого** блока; массовая переразметка существующих файлов вне объёма.
+
+---
+
+## 7. Правило чтения (каноничная формулировка — единый источник)
+
+Это **единственное** место, где живёт каноничный текст правила. Промпты агентов
+(`developer.md`/`architect.md`/`reviewer.md`) **ссылаются** на него, а не копируют — чтобы не было
+дрейфа формулировок между файлами.
+
+> **Правишь код с маркером `ORCH-NNN` → прочитай его `docs/work-items/ORCH-NNN/06-adr/` ПЕРЕД
+> изменением; не сломай зафиксированный инвариант. Не можешь сохранить инвариант — эскалируй /
+> верни задачу в анализ, не правь вслепую.** Папки нет в ветке → читай из `origin/main` (§5). Блок
+> несёт 3+ маркеров → опирайся на сводный сквозной ADR (§6).
+
+Кто и как применяет правило:
+
+- **developer / architect** — обязаны выполнить чтение ПЕРЕД правкой маркированного кода.
+- **architect** — при введении/правке блока с 3+ маркерами оформляет/обновляет сводный сквозной ADR.
+- **reviewer** — проверяет соблюдение: правка маркированного (`ORCH-NNN`) кода без сверки с его ADR
+  или со сломом инварианта → finding (рекомендуемая severity **P1**; слом критического инварианта
+  конвейера — на усмотрение reviewer вплоть до P0).
+
+---
+
+## Связи
+
+- Сквозной ADR: [`adr-0022`](../architecture/adr/adr-0022-traceability-marker-standard.md).
+- Стандарты-соседи: [`PIPELINE_DOCS.md`](PIPELINE_DOCS.md) (слой 1),
+  [`HANDOFF_PROTOCOL.md`](HANDOFF_PROTOCOL.md) (слой 2).
+- Цепочка эпика 52: adr-0019 (52b) / adr-0020 (52c) / adr-0021 (52d) / adr-0022 (52e).
+- Прецедент класса ошибки (слом инварианта без чтения ADR): `docs/history/LESSONS_2026-06-08_phantom-merge.md`.

docs/_templates/00-business-request.md

@@ -0,0 +1,8 @@
+# Business Request: <краткий заголовок задачи>
+
+Work Item ID: ORCH-NNN
+
+## Description
+
+<Что хочет заказчик/Владелец своими словами: проблема, желаемый результат, контекст.
+Допускается `TBD` на входе — analyst уточняет на стадии `analysis` и формализует в 01-brd.md.>

docs/_templates/01-brd.md

@@ -0,0 +1,34 @@
+# 01 — BRD (бизнес-требования): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
+
+## 1. Бизнес-контекст и проблема
+<Зачем задача, какую боль/риск закрывает. Установленные факты — не изобретать.>
+
+## 2. Объём (scope)
+
+### В объёме
+- <что делаем>
+
+### Вне объёма
+- <что явно НЕ делаем — чтобы исключить расползание>
+
+## 3. Заинтересованные стороны
+<Кто заказчик, кого затрагивает, кто принимает результат.>
+
+## 4. Бизнес-требования (BR)
+- **BR-1** — <требование, проверяемое>
+- **BR-2** — …
+
+## 5. Нефункциональные требования (NFR)
+- **NFR-1** — <надёжность / совместимость / обратимость / безопасность>
+- **NFR-2** — …
+
+## 6. Допущения и ограничения
+<Допущения, на которых стоит решение; внешние ограничения.>
+
+## 7. Критерии успеха
+<Резюме; детальные PASS/FAIL — в 03-acceptance-criteria.md.>
+
+## 8. Риски
+<Краткий перечень; детали — 10-tech-risks.md (заполняет архитектор).>

docs/_templates/01-questions.md

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

docs/_templates/02-trz.md

@@ -0,0 +1,30 @@
+# 02 — ТЗ (TRZ): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
+
+> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
+> Архитектурное обоснование/решения — задача архитектора (06-adr).
+
+## 1. Сводка изменения
+<Что меняется, в одном-двух абзацах.>
+
+## 2. Задействованные модули / пути
+| Путь | Действие |
+|------|----------|
+| `src/<module>.py` | изменить / создать |
+
+## 3. Функциональные требования
+### FR-1 — <название>
+<Поведение, контракт, инварианты. Привязать к BR.>
+
+## 4. Изменения API
+<Новые/изменённые эндпоинты; либо «Нет.».>
+
+## 5. Изменения схемы БД
+<Таблицы/миграции/индексы; либо «Нет.».>
+
+## 6. Требования к новым/изменённым QG checks
+<Изменения `QG_CHECKS` / `check_*`; либо «Нет.».>
+
+## 7. Совместимость / регресс
+<Обратная совместимость, kill-switch, область раската, обратимость.>

docs/_templates/03-acceptance-criteria.md

@@ -0,0 +1,31 @@
+# 03 — Критерии приёмки (Acceptance Criteria): ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: analysis
+
+Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
+(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
+репозитория.
+
+---
+
+## AC-1 — <краткий заголовок>
+
+**Условие:** <проверяемое условие>
+- **PASS:** <что должно быть истинно>
+- **FAIL:** <что считается провалом>
+
+---
+
+## AC-2 — <краткий заголовок>
+
+**Условие:** <…>
+- **PASS:** <…>
+- **FAIL:** <…>
+
+---
+
+## Сводная матрица AC ↔ FR/BR
+| AC | Покрывает |
+|----|-----------|
+| AC-1 | BR-1 / FR-1 |
+| AC-2 | BR-2 / FR-2 |

docs/_templates/04-test-plan.yaml

@@ -0,0 +1,20 @@
+work_item: ORCH-NNN
+title: "<краткое название тест-плана>"
+framework: pytest
+scope: "<что покрывается тестами; что вне покрытия>"
+notes: >
+  <Свободные заметки: окружение, особенности, что считается регрессом.
+  Полный регресс tests/ должен оставаться зелёным.>
+
+tests:
+  - id: TC-01
+    type: unit            # unit | integration
+    description: "<что проверяет тест>"
+    module: tests/test_<feature>.py
+    expected: PASS
+
+  - id: TC-02
+    type: integration
+    description: "<…>"
+    module: tests/test_<feature>.py
+    expected: PASS

docs/_templates/06-adr-ADR-NNN-slug.md

@@ -0,0 +1,43 @@
+# ADR-NNN: <Заголовок решения>
+
+> **Шаблон ADR.** Скопируй в `docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md`.
+> `NNN` начинается с `001`, инкремент при нескольких ADR в задаче. `<kebab-slug>` — нижний
+> регистр, слова через дефис. Сквозное (cross-cutting) решение дополнительно дублируй в
+> `docs/architecture/adr/adr-NNNN-<kebab-slug>.md` (4-значная глобальная нумерация).
+> См. `docs/_standards/PIPELINE_DOCS.md` §4.
+
+Work Item: **ORCH-NNN** — <короткое описание>
+Стадия: **architecture**
+Сквозная регистрация: **`docs/architecture/adr/adr-NNNN-<slug>.md`** (если решение
+кросс-каттинговое; иначе — «N/A, локальное решение задачи»).
+
+## Статус
+Proposed   <!-- Proposed | Accepted | Superseded by ADR-… -->
+
+## Контекст
+<Какую проблему решаем; факты, сверенные с кодом (`src/…`); почему «как есть» не годится.>
+
+## Решение
+
+### Сводка
+<Суть выбранного решения в одном-двух абзацах.>
+
+### D1 — <название аспекта решения>
+<Конкретное решение по аспекту, инварианты, привязка к FR/AC.>
+
+### D2 — <название аспекта решения>
+<…>
+
+## Альтернативы
+- **<альтернатива>** — отвергнуто: <почему>.
+
+## Последствия
+- **+** <положительный эффект>
+- **−** <издержка / приятый компромисс + митигейшн>
+- **Откат:** <как полностью откатить изменение>
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-NNN/01-brd.md`
+- TRZ: `docs/work-items/ORCH-NNN/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-NNN/03-acceptance-criteria.md`
+- Сверено по коду: `src/…`

docs/_templates/07-infra-requirements.md

@@ -0,0 +1,19 @@
+# 07 — Инфра-требования: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> When-applicable. Если инфраструктура не затрагивается — оставить явные `N/A` по пунктам
+> (файл создаётся для аудитопригодности, а не из-за изменения топологии).
+
+## I-1. Топология / окружения
+<Контейнеры, порты, сеть, тома, хост; либо `N/A`.>
+
+## I-2. Переменные окружения / секреты
+<Новые env-переменные, изменения `.env` / `.env.example`, секреты; либо `N/A`.>
+
+## I-3. Деплой / рестарт
+<Требуется ли рестарт прод-контейнера; self-hosting инвариант (не ронять прод вне staging);
+либо `N/A`.>
+
+## I-4. CI/CD
+<Изменения `.gitea/workflows/`, новые тестовые шаги; либо «без изменений».>

docs/_templates/08-data-requirements.md

@@ -0,0 +1,15 @@
+# 08 — Требования к данным: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> When-applicable / информационный (гейтом не парсится). Если данные/схема не затрагиваются —
+> оставить явные `N/A`.
+
+## Изменения схемы БД
+<Новые/изменённые таблицы, индексы, миграции (`init_db`); либо `N/A`.>
+
+## Новые/изменённые сущности
+<Поля, колонки, инварианты данных; либо «Нет.».>
+
+## Совместимость данных / миграции
+<Аддитивность, идемпотентность миграций, restart-safe, влияние на общую прод-БД; либо `N/A`.>

docs/_templates/10-tech-risks.md

@@ -0,0 +1,16 @@
+# 10 — Технические риски: ORCH-NNN — <название>
+
+Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
+
+> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
+
+## Реестр рисков
+
+| ID | Риск | Вер. | Влия. | Митигейшн |
+|----|------|------|-------|-----------|
+| TR-1 | <описание риска> | Низ./Сред./Выс. | Низ./Сред./Выс. | <как снижаем> |
+| TR-2 | <…> | | | |
+
+## Сводный вывод
+<Доминирующий класс рисков; нужна ли эскалация `arch:major-change` / возврат в анализ;
+итоговая оценка остаточного риска для прод-конвейера (self-hosting).>

docs/_templates/12-review.md

@@ -0,0 +1,31 @@
+---
+type: review
+work_item_id: ORCH-NNN
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES  (machine-key — читает check_reviewer_verdict)
+version: 1
+---
+
+# Review ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter (никогда из прозы).
+> `APPROVED` → дальше по конвейеру; `REQUEST_CHANGES` → откат на `development`.
+
+## Summary
+<Краткая оценка: реализовано ли по ТЗ/ADR, покрытие тестами, обновлена ли документация.>
+
+## Оси проверки
+<Корректность, соответствие ADR/инвариантам, тесты, документация, совместимость/регресс.>
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+## Документация
+<Обновлена ли документация (README/CLAUDE/CHANGELOG/архитектура) в том же PR. Нет → REQUEST_CHANGES.>

docs/_templates/13-test-report.md

@@ -0,0 +1,33 @@
+---
+type: test-report
+work_item_id: ORCH-NNN
+result: PASS            # PASS | FAIL | BLOCKED  (machine-key — читает _parse_tests_verdict)
+---
+
+# Test Report — ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из frontmatter. Канонический ключ — `result:`; равнорангово
+> допускаются `verdict:` / `status:` (ORCH-047). Любой негативный токен (`FAIL`/`BLOCKED`) —
+> авторитетен.
+
+## Окружение
+- Python: <версия>
+- pytest: <версия>
+- Дата: YYYY-MM-DD
+- Worktree: `feature/ORCH-NNN-<slug>`
+
+## Результаты
+
+### Полный регресс
+<`pytest tests/ -q` — итог (N passed); прод-контейнер не трогается.>
+
+### Профильные сюиты
+<Целевые тесты задачи.>
+
+### Сопоставление с тест-планом
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-01 | <…> | test_… | PASS |
+
+### Сопоставление с критериями приёмки
+<AC-1…AC-N — покрыт каким тестом / результат.>

docs/_templates/14-deploy-log.md

@@ -0,0 +1,14 @@
+---
+deploy_status: SUCCESS    # SUCCESS | FAILED  (machine-key — читает _parse_deploy_status)
+work_item: ORCH-NNN
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-NNN
+
+> Машинный вердикт читается ТОЛЬКО из `deploy_status:` во frontmatter.
+> `SUCCESS` → `done`; `FAILED` → откат на `development` (БАГ-8).
+
+<Краткое описание деплоя: что выкачено, exit-code хука, кто/что зафиксировало вердикт
+(детерминированный finalizer Фаза C, не LLM, для self-hosting).>

docs/_templates/15-staging-log.md

@@ -0,0 +1,20 @@
+---
+staging_status: SUCCESS    # SUCCESS | FAILED  (machine-key — читает _parse_staging_status)
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+> Машинный вердикт читается ТОЛЬКО из `staging_status:` во frontmatter. Реален для self-hosting
+> (`orchestrator`); для прочих репо гейт — N/A (ORCH-35). `SUCCESS` → дальше; `FAILED` → откат.
+
+Staging test suite — итог (например: «All REAL pipeline checks passed»). Запуск канонически
+внутри контейнера `orchestrator-staging` (8501).
+
+## Results
+- **Block A (SMOKE)**: <…>
+- **Block B (ACCESS)**: <…>
+- **Block C (E2E)**: <…>
+
+REAL failed: <none | перечень>.

docs/_templates/16-post-deploy-log.md

@@ -0,0 +1,21 @@
+---
+post_deploy_status: HEALTHY    # HEALTHY | DEGRADED  (информационный, гейтом НЕ парсится — телеметрия ORCH-021)
+action_taken: NONE             # NONE | ALERT_ONLY | ROLLBACK_OK | ROLLBACK_FAILED
+work_item: ORCH-NNN
+window_s: 900
+checks_total: 0
+checks_failed: 0
+---
+
+# Post-deploy log — ORCH-NNN
+
+> Пост-`done` наблюдение прода (ORCH-021). НЕ ребро `STAGE_TRANSITIONS`, гейтом не парсится —
+> frontmatter машиночитаем для петли уроков ORCH-8 / наблюдаемости.
+
+Окно наблюдения: <window_s>s; опросов всего: <checks_total>, с провалом: <checks_failed>.
+
+## Серия наблюдений
+<Краткая серия сигналов health / доли 5xx; классификация HEALTHY/DEGRADED.>
+
+## Решение
+<Реакция: для self-hosting всегда `ALERT_ONLY` (ручной approve, тик не откатывает прод).>

docs/_templates/17-security-report.md

@@ -0,0 +1,26 @@
+---
+security_status: PASS      # PASS | FAIL  (machine-key — читает check_security_gate)
+work_item: ORCH-NNN
+secrets_found: 0
+deps_blocking: 0
+deps_warning: 0
+deps_audit_degraded: false
+---
+
+# Security Report — ORCH-NNN
+
+> Детерминированный security-гейт (ORCH-022) — под-гейт ребра `deploy-staging→deploy` (врезка в
+> `advance_stage`, не строка `STAGE_TRANSITIONS`). Машинный вердикт читается ТОЛЬКО из
+> `security_status:`. `PASS` → дальше; `FAIL` → откат.
+
+## Verdict
+<clean / blocking: N secrets, M blocking CVE(s).>
+
+## Secrets
+<secret-scanning (gitleaks, offline): None | перечень.>
+
+## Dependencies (blocking)
+<dependency audit (pip-audit): None | перечень блокирующих CVE.>
+
+## Dependencies (warning)
+<Не блокирующие предупреждения зависимостей.>

docs/_templates/18-coverage-report.md

@@ -0,0 +1,29 @@
+---
+coverage_status: PASS      # PASS | FAIL  (machine-key — читает check_coverage_gate)
+work_item: ORCH-NNN
+measured_coverage: 0.0      # измеренное line coverage src/ (%, float)
+baseline: 0.0              # базовая линия main на момент измерения (%, или пусто при bootstrap)
+floor: 0.0                 # абсолютный порог coverage_min_percent (%)
+policy: both               # absolute | baseline | both
+epsilon: 0.5               # допуск на шум измерения (%)
+delta: 0.0                 # measured − max(baseline, floor) (%, знаковая дельта)
+---
+
+# Coverage Report — ORCH-NNN
+
+> Детерминированный гейт покрытия (ORCH-027) — под-гейт ребра `deploy-staging→deploy` (врезка в
+> `advance_stage`, ПОСЛЕ merge-gate, ДО image-freshness; не строка `STAGE_TRANSITIONS`). Машинный
+> вердикт читается ТОЛЬКО из `coverage_status:`. `PASS` → дальше; `FAIL` → откат на `development`.
+> Измерение — `pytest --cov=src --cov-report=json` в изолированном worktree. Source of truth
+> измеренного значения для ratchet базовой линии (`_handle_merge_verify`, ребро `deploy→done`).
+
+## Verdict
+<PASS / FAIL: measured X% vs floor F% / baseline B% (policy=…, epsilon=…), delta=±D%.>
+
+## Measurement
+<Инструмент (pytest-cov/coverage.py), команда, line coverage src/ = X%; либо fail-open WARNING
+при ошибке инструмента (coverage_tool_fail_closed=False).>
+
+## Policy
+<Режим (absolute|baseline|both), порог floor, базовая линия main, epsilon, какое условие
+нарушено при FAIL.>

docs/architecture/adr/README.md

@@ -0,0 +1,61 @@
+# Architecture Decision Records
+
+Индекс сквозных (cross-cutting) ADR проекта orchestrator.
+Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-slug.md`.
+
+| # | Решение | Статус | Дата | Источник |
+|---|---------|--------|------|----------|
+| adr-0001 | Реестр проектов (multi-repo) | accepted | 2026-06-02 | ORCH-6 |
+| adr-0002 | Очередь задач вместо in-process потоков | accepted | 2026-06-03 | ORCH-1 |
+| adr-0003 | Условный staging-гейт перед прод-деплоем | accepted | 2026-06-05 | ORCH-35 |
+| adr-0004 | Поллинг с ретраем в check_ci_green (фикс CI-race) | accepted | 2026-06-05 | ORCH-045 |
+| adr-0005 | Контейнеры бегут под uid:gid хоста (1000:1000) | accepted | 2026-06-06 | ORCH-040 |
+| adr-0006 | Merge-gate (догон main + re-test + сериализация слияний) | proposed | 2026-06-06 | ORCH-043 |
+| adr-0007 | Reconciler застрявших стадий (sweeper потерянных webhook) | accepted | 2026-06-06 | ORCH-053 |
+| adr-0007 | Исполняемый самодеплой стадии `deploy` (файл adr-0007-executable-self-deploy) | accepted | 2026-06-06 | ORCH-036 |
+| adr-0008 | Провенанс staging-образа перед BUILD-ONCE retag | accepted | 2026-06-06 | ORCH-058 |
+| adr-0009 | Толерантность staging-вердикта к инфраструктурным FAIL | accepted | 2026-06-07 | ORCH-061 |
+| adr-0010 | Post-deploy мониторинг прода + реакция на деградацию | proposed | 2026-06-07 | ORCH-021 |
+| adr-0011 | Job-reaper + проактивный реклейм merge-lease | accepted | 2026-06-07 | ORCH-065 |
+| adr-0012 | Security-гейт (secrets/deps) | accepted | 2026-06-08 | ORCH-022 |
+| adr-0013 | Merge-в-main + пост-деплой верификация как условие `done` | accepted | 2026-06-08 | ORCH-071 |
+| adr-0014 | SHA-в-main — единственный критерий merge-verify + регресс-гард | accepted | 2026-06-08 | ORCH-073 |
+| adr-0015 | Зависимости задач (B ждёт A) + сериализация merge внутри репо | accepted | 2026-06-08 | ORCH-026 |
+| adr-0016 | ensure_open_pr — гарантированный код-PR перед merge-verify | accepted | 2026-06-09 | ORCH-082 |
+| adr-0017 | Per-repo serial gate (пакетный автономный режим, serial e2e) | proposed | 2026-06-09 | ORCH-088 |
+| adr-0018 | Авто-режим по лейблам (autoApprove + autoDeploy) | accepted | 2026-06-09 | ORCH-089 |
+| adr-0019 | Стандарт документов конвейера (PIPELINE_DOCS, слой 1) | accepted | 2026-06-09 | ORCH-075 |
+| adr-0020 | Единый frontmatter-контракт + спека handoff (reader/writer/валидатор) | accepted | 2026-06-09 | ORCH-076 |
+| adr-0021 | Канон Anthropic для агент-промптов + эмиссия frontmatter-схемы 52c | proposed | 2026-06-09 | ORCH-077 |
+| adr-0022 | Стандарт трассировочных маркеров `ORCH-NNN` | accepted | 2026-06-09 | ORCH-078 |
+| adr-0023 | Обзорная ось reviewer + закрытие эпика 52 | accepted | 2026-06-09 | ORCH-079 |
+| adr-0024 | Disk-watchdog — heartbeat-сигнал заполнения хост-ФС | proposed | 2026-06-09 | ORCH-063 |
+| adr-0025 | Build-cache-pruner — авто-prune docker build cache на хосте | proposed | 2026-06-09 | ORCH-062 |
+| adr-0026 | STOP / отмена задачи — системный терминал `cancelled` | proposed | 2026-06-09 | ORCH-090 |
+| adr-0027 | Merge-актор — ретрай транзиентных ошибок Gitea + гард «ветка уже в `main`» | proposed | 2026-06-09 | ORCH-093 |
+| adr-0028 | Terminal-window-aware гард deploy-фазовых статусов Plane | proposed | 2026-06-09 | ORCH-094 |
+| adr-0029 | Гейт покрытия тестами — edge sub-gate + ratchet-базовая линия | proposed | 2026-06-10 | ORCH-027 |
+| adr-0030 | Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b) | proposed | 2026-06-10 | ORCH-099 |
+| adr-0031 | Нормализация legacy root-owned файлов при миграции uid — детект-leaf + actionable worktree-ошибка | proposed | 2026-06-10 | ORCH-057 |
+| adr-0032 | Багфикс-трек — укороченный маршрут конвейера для багов | proposed | 2026-06-10 | ORCH-019 |
+| adr-0033 | Sidecar-watchdog F1b — мозг мониторинга в отдельном контейнере | proposed | 2026-06-10 | ORCH-100 |
+| adr-0034 | Машинный журнал уроков — таблица `lessons` + observer-leaf | proposed | 2026-06-10 | ORCH-098 |
+| adr-0035 | Turnkey-онбординг проектов — kit + операторский CLI + runbook | proposed | 2026-06-10 | ORCH-009 |
+| adr-0036 | Фундамент тиража платформы — параметризация хоста, секреты, smoke (10-common) | proposed | 2026-06-10 | ORCH-101 |
+| adr-0037 | Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` | proposed | 2026-06-10 | ORCH-102 |
+
+> ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
+> `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
+> (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
+> свободный номер (текущий максимум — `0037`).
+> adr-0014 **amends** adr-0013 (меняет критерий merge-verify на «SHA-в-main»).
+> adr-0016 **amends** adr-0013/0014 (гарантирует открытый код-PR перед merge_pr, ORCH-082).
+> adr-0020 реализует машинный слой к adr-0019 (ORCH-52b→52c).
+> adr-0021 реализует слой промптов к adr-0019/0020 (ORCH-52d — замыкает эпик 52).
+> adr-0025 **комплементарен** adr-0024 (watchdog сигналит о росте диска — pruner убирает
+> доминирующего «пожирателя», docker build cache).
+
+## Формат
+**Контекст → Решение → Альтернативы → Последствия → Связи.** Статус: proposed / accepted / superseded.
+Принятый ADR не меняется — новое решение заводится отдельным файлом со ссылкой `supersedes adr-XXXX`.
+Новые ADR добавляет архитектор при принятии решения (см. `CLAUDE.md` → Конвенции).

docs/architecture/adr/adr-0001-multi-repo-registry.md

@@ -0,0 +1,23 @@
+# adr-0001: Реестр проектов (multi-repo)
+
+- **Статус:** accepted
+- **Дата:** 2026-06-02
+- **Задача:** ORCH-6
+
+## Контекст
+Инцидент 2026-06-02: Plane-вебхук слушал весь воркспейс и хардкодил `repo = settings.default_repo` (enduro-trails). Задачи ЛЮБОГО проекта сливались в один репо с одним префиксом (ET). Нужна изоляция по проектам.
+
+## Решение
+Введён реестр `src/projects.py`: `ProjectConfig` (frozen dataclass) связывает `plane_project_id` → `repo` + `work_item_prefix` + `name`. Источник правды — env `ORCH_PROJECTS_JSON`; при пустом/невалидном — встроенный дефолт (`enduro-trails`/ET, `orchestrator`/ORCH). Позволяет: фильтровать вебхуки по проекту (неизвестный → ignore), резолвить gitea-репо + префикс, роутить Plane-синк в свой проект задачи.
+
+## Альтернативы
+- Один репо на всё — отклонён (источник инцидента).
+- Хардкод маппинга в коде — отклонён в пользу env-конфигурируемого реестра с безопасным дефолтом.
+
+## Последствия
+- Изоляция проектов на уровне вебхуков и роутинга.
+- Парсер устойчив: битый элемент скипается, пустой результат → дефолт.
+- Основа для `is_self_hosting_repo` (adr-0003).
+
+## Связи
+adr-0003 (условный гейт опирается на repo из реестра).

docs/architecture/adr/adr-0002-job-queue.md

@@ -0,0 +1,23 @@
+# adr-0002: Очередь задач вместо in-process потоков
+
+- **Статус:** accepted
+- **Дата:** 2026-06-03
+- **Задача:** ORCH-1 (F-2b)
+
+## Контекст
+Ранняя версия запускала стадии конвейера в in-process daemon-потоках. Проблемы: не переживало рестарт (задачи терялись), нет контроля параллелизма, нет ретраев, нет наблюдаемости.
+
+## Решение
+Введена персистентная очередь задач (`src/queue_worker.py` + таблица `jobs` в SQLite): atomic claim задачи воркером, `max_concurrency`, ретраи при сбое, restart-safe (running-задачи реквестятся при старте), эндпоинт `GET /queue`.
+
+## Альтернативы
+- In-process потоки — отклонены (не restart-safe).
+- Внешний брокер (Redis/RabbitMQ) — избыточно для текущего масштаба; SQLite-очередь проще и без новых зависимостей.
+
+## Последствия
+- Конвейер переживает рестарт контейнера.
+- Контроль параллелизма и наблюдаемость через `/queue`.
+- ⚠️ Очередь общая на все проекты прод-инстанса — фактор группового риска при self-hosting (см. `docs/operations/INFRA.md`).
+
+## Связи
+adr-0001 (реестр проектов), INFRA.md (общая очередь при self-hosting).

docs/architecture/adr/adr-0003-staging-gate.md

@@ -0,0 +1,27 @@
+# adr-0003: Условный staging-гейт перед прод-деплоем
+
+- **Статус:** accepted
+- **Дата:** 2026-06-05
+- **Задача:** ORCH-35
+
+## Контекст
+Оркестратор дорабатывает сам себя (self-hosting). Раньше стадия `deploy` имела «бумажный» вердикт: deployer-агент писал `deploy_status: SUCCESS`, но реального прогона на изолированной среде не было. Нужен предохранитель: прод-деплой орка не должен происходить, пока изменения не проверены на живой staging-среде. При этом другие проекты (enduro-trails) staging-инфры не имеют.
+
+## Решение
+Добавлена промежуточная стадия `deploy-staging` между `testing` и `deploy`: `testing → deploy-staging → deploy → done`.
+- deployer гоняет `scripts/staging_check.py --base-url http://localhost:8501` и пишет `staging_status: SUCCESS|FAILED` в `15-staging-log.md`.
+- Quality Gate `check_staging_status` парсит вердикт (только YAML-frontmatter).
+- **Гейт условный:** `is_self_hosting_repo(repo)` → реальная проверка только для `orchestrator`; для остальных проектов гейт = no-op `(True, "Staging gate N/A")`.
+- FAILED → откат на `development`.
+
+## Альтернативы
+- Глобальный гейт для всех проектов — отклонён: у enduro нет staging-инстанса, задачи застревали бы на откате.
+- Деплой реально дёргает хост-хук прямо здесь — отложен в ORCH-36 (Вариант B).
+
+## Последствия
+- Прод-деплой орка недостижим, пока staging-гейт не зелёный.
+- Другие проекты не затронуты (no-op).
+- Реальный docker-деплой через хук пока НЕ выполняется (вердикт «бумажный», но подкреплён прогоном сьюта). Исполняемый деплой — ORCH-36.
+
+## Связи
+adr-0001 (реестр проектов — основа `is_self_hosting_repo`), ORCH-34 (deploy-hook + rollback), ORCH-36 (исполняемый самодеплой).

docs/architecture/adr/adr-0004-ci-poll-retry.md

@@ -0,0 +1,45 @@
+# adr-0004: Поллинг с ретраем в quality-gate check_ci_green (фикс CI-race)
+
+- **Статус:** accepted
+- **Дата:** 2026-06-05
+- **Задача:** ORCH-045
+
+## Контекст
+Quality-gate `check_ci_green(repo, branch)` (`src/qg/checks.py`) проверяет combined commit-status ветки через Gitea API сразу после того, как developer-агент запушил код. Реализация была **single-shot**: один `GET /repos/{owner}/{repo}/commits/{branch}/status`, чтение `data["state"]` — `success` → пропуск, иначе → сразу `False`.
+
+Это создавало race condition. Gitea-CI после пуша 1–3 секунды держит combined state `pending`, пока не отработают чек-раннеры. Если гейт опрашивал статус в этом окне, он получал `pending` и возвращал `False` **ровно один раз** — повторного опроса не было. Combined state затем дозеленевал до `success`, но гейт уже промахнулся, и задача застревала насмерть без видимой причины.
+
+Реальный инцидент **ORCH-017**: гейт опросил статус в 17:58:54 → `pending`; CI дозеленел в 17:58:55. Задача встала в тупик (см. `docs/history` / lessons ORCH-017).
+
+## Решение
+`check_ci_green` превращён из single-shot в **polling с ретраем**:
+
+- `state == "success"` → `(True, "CI green")` немедленно.
+- `state in ("failure", "error")` → `(False, "CI state: <state>")` немедленно — CI красный, ретрай бессмыслен (терминальное состояние).
+- `state == "pending"` (или `unknown` / иное не-терминальное) → `time.sleep(interval)` и опрос снова, до `N` попыток.
+- После исчерпания всех попыток при всё ещё `pending` → `(False, "CI still pending after <T>s")` — **явный** провал с причиной, чтобы оператор видел тупик, а не молчаливый стол.
+- `404` → `(False, "Branch ... not found or no status")` — как раньше.
+- Транзиентная `httpx.HTTPError` на отдельной попытке — **не падаем сразу**: логируем и пробуем ещё в рамках лимита попыток; если все попытки — сетевая ошибка → `(False, "API error: <e>")`.
+
+Параметры вынесены в `src/config.py` (pydantic-settings, env-prefix `ORCH_`, единый стиль с остальными настройками):
+- `ci_poll_max_attempts` (env `ORCH_CI_POLL_MAX_ATTEMPTS`, дефолт **12**)
+- `ci_poll_interval_s` (env `ORCH_CI_POLL_INTERVAL_S`, дефолт **10**)
+
+Итого по умолчанию гейт ждёт `pending` до ~2 минут (12 × 10s) перед тем как явно провалиться. Каждая не-финальная попытка логируется через существующий `logger` (`check_ci_green: attempt i/N, state=..., retrying in Ns`). `timeout=10` на каждый отдельный запрос сохранён.
+
+Сигнатура `check_ci_green(repo, branch) -> tuple[bool, str]` **не менялась** — её зовёт stage_engine и реестр гейтов `QG_CHECKS`.
+
+## Альтернативы
+- **Оставить single-shot, опрашивать гейт повторно снаружи (на уровне stage_engine/воркера).** Отклонено: размазывает логику CI-ожидания по слоям, дублирует таймауты; гейт — естественное место знания о combined-status.
+- **Webhook от Gitea на завершение CI вместо поллинга.** Отложено: требует надёжной доставки/дедупликации вебхуков именно по CI-статусу и переписывания триггера стадии; поллинг — минимальный, локализованный фикс race-а здесь и сейчас.
+- **Бесконечный ретрай до зелёного.** Отклонено: задача могла бы висеть вечно при реально зависшем CI; ограниченный бюджет + явный `False` с причиной даёт оператору сигнал.
+
+## Последствия
+- CI-race ORCH-017 закрыт: транзиентный `pending` переживается ретраем, гейт не промахивается.
+- `check_ci_green` теперь **блокирующий** до ~`max_attempts × interval` секунд при затяжном `pending` (по умолчанию ~2 мин). Это осознанный trade-off; для красного CI и success — выход немедленный, без задержки.
+- Тупик больше не молчаливый: истечение попыток → `(False, "CI still pending after <T>s")`, причина видна.
+- Бюджет/интервал настраиваемы через env без правки кода.
+- `check_tests_passed` / `_parse_tests_verdict` (ORCH-47) **не затронуты**.
+
+## Связи
+ORCH-017 (инцидент-первоисточник: deadlock shared-gate из-за CI-race), реестр гейтов `QG_CHECKS` (`check_ci_green`), стадия `development`. Тесты: `tests/test_qg.py::TestCheckCIGreen`.

docs/architecture/adr/adr-0005-container-runs-as-host-uid.md

@@ -0,0 +1,42 @@
+# adr-0005: Контейнеры оркестратора бегут под uid:gid хоста (1000:1000)
+
+- **Статус:** accepted
+- **Дата:** 2026-06-06
+- **Задача:** ORCH-040
+
+## Контекст
+Оба контейнера (`orchestrator`, `orchestrator-staging`) запускались под `uid=0 (root)` и
+монтировали хостовый `/home/slin/repos` → `/repos` (rw). Claude-CLI агенты исполняются
+`subprocess.Popen` внутри контейнера под тем же root, поэтому все артефакты конвейера
+(git worktree, коммиты в `docs/`) появлялись на хосте как `root:root`. Деплой прода под
+`slin` (uid 1000) ломался на правах git до ручного `chown`. Это сквозное свойство рантайма:
+касается агентов **всех** проектов, а не отдельной фичи.
+
+## Решение
+Оба сервиса в `docker-compose.yml` запускаются под `user: "1000:1000"` (uid:gid хоста `slin`).
+- `group_add: ["999"]` сохраняется — доступ к docker.sock идёт через gid 999, не через root.
+- target SSH-маунта приведён к `/home/slin/.ssh` (был `/root/.ssh`), синхронно с
+  `HOME=/home/slin`, который форсит launcher → единый HOME по осям uid/claude/ssh.
+- Образ и launcher не меняются: numeric uid не требует записи в `/etc/passwd`,
+  `git config --system safe.directory '*'` уже есть.
+
+Обязательные host-prerequisites (Owner, вне кода): доступ uid 1000 к
+`/home/slin/.claude/.credentials.json` (блокер), ssh-ключи в новом HOME, рестарт prod
+только в окно тишины. Детали и команды — work-item ADR-001 и `docs/operations/INFRA.md`.
+
+## Альтернативы
+- **drop-privileges только для subprocess агента** (`gosu`/`setuid`) — контейнер остаётся
+  root; новый код в горячем пути launcher, два uid в одном контейнере; отклонён.
+- **chown-хук после каждой стадии** — лечит симптом, требует root внутри контейнера
+  (несовместимо), хрупкий пост-шаг; отклонён (fallback на крайний случай).
+
+## Последствия
+- Артефакты создаются под `slin:slin`; деплой прода не требует ручного `chown`.
+- HOME консистентен (uid = claude = ssh = `/home/slin`); устранён рассинхрон SSH-маунта.
+- Появляется явная привязка рантайма к uid 1000 хоста (задокументирована в INFRA.md).
+- Прод-рестарт self = групповой риск (общий инстанс с enduro-trails) → строго окно тишины;
+  страховка — staging-гейт (adr-0003).
+
+## Связи
+adr-0003 (staging-гейт — обязательная проверка перед прод-рестартом self),
+adr-0001 (`is_self_hosting_repo`), work-item `docs/work-items/ORCH-040/06-adr/ADR-001-run-agents-as-host-uid.md`.

docs/architecture/adr/adr-0006-merge-gate.md

@@ -0,0 +1,53 @@
+# adr-0006: Merge-gate — догон `main` + re-test + сериализация слияний
+
+- **Статус:** proposed
+- **Дата:** 2026-06-06
+- **Задача:** ORCH-043
+- **Детальный ADR:** `docs/work-items/ORCH-043/06-adr/ADR-001-merge-gate.md`
+
+## Контекст
+Ветка валидируется относительно того `main`, из которого создана, а не относительно `main`
+на момент слияния. Параллельная задача могла влиться раньше → **семантический конфликт
+слияния** (git мержит без текстового конфликта, но `main` сломан). Для self-hosting это
+красный `main` инструмента, обслуживающего все проекты. Слияние в `main` делает
+deployer-агент в начале стадии `deploy`; замена механизма PR-merge — вне объёма.
+
+## Решение
+Детерминированный merge-gate (`check_branch_mergeable`, без LLM) на ребре
+`deploy-staging → deploy`, ДО запуска deployer'а, который мержит. `STAGE_TRANSITIONS` не
+меняется (минимальный blast-radius); в `QG_CHECKS` добавлен `check_branch_mergeable`.
+
+- **Догон:** ветка отстаёт ⇔ `origin/main` не предок HEAD → `rebase origin/main` в worktree
+  + `push --force-with-lease` (ТОЛЬКО ветка задачи; `main` — никогда). Текстовый конфликт →
+  `rebase --abort` → откат на `development`.
+- **Re-test:** `python -m pytest tests/` в worktree догнанной ветки, тайм-аут
+  `merge_retest_timeout_s`. Красный/тайм-аут → откат на `development`.
+- **Сериализация (BR-5):** файловый **merge-lease** на репо
+  (`<repos_dir>/.merge-lease-<repo>.json`), живёт от гейта до фактического merge.
+  Acquire **неблокирующий** (anti-deadlock при `max_concurrency=1`): busy → **defer**
+  (re-enqueue deployer с задержкой через `available_at`), не rollback. Release — на
+  PR-merged вебхуке / `deploy→done` / откате / по возрасту (crash-реклейм). Restart-safe.
+- **Условность (как ORCH-35):** реален для `orchestrator`; прочие репо — no-op. Флаги
+  `merge_gate_enabled` / `merge_gate_repos` для поэтапного раската.
+
+## Альтернативы
+- **Новая стадия `merge-gate`** (кандидат B) — «пустая» стадия без агента не имеет триггера
+  (`advance_stage` срабатывает только на завершении агента/вебхуке); потребовала бы chaining
+  в движке (не restart-safe) или синтетический job-тип. Отклонено.
+- **Перенос merge в детерминированный шаг оркестратора** (кандидат C) — запрещён объёмом
+  (замена механизма PR-merge вне scope). Отклонено.
+- **Блокирующий lock** — дедлок при одном worker-слоте. Отклонено в пользу defer.
+
+## Последствия
+- Сценарий «две зелёные ветки ломают `main`» закрыт: re-test против актуального `main` +
+  сериализация слияний.
+- Плата: merge-gate — «скрытый» под-гейт ребра (нет в `STAGE_TRANSITIONS`); сериализация
+  опирается на PR-merged вебхук со страховкой реклеймом по возрасту; defer перепрогоняет
+  staging; длинный re-test держит worker-слот.
+- Сквозное изменение конвейера → `arch:major-change`; прод-деплой ORCH-043 строго через
+  staging-гейт (8501).
+
+## Связи
+adr-0001 (`is_self_hosting_repo`), adr-0003 (условный staging-гейт — образец условности),
+adr-0002 (очередь / `available_at` для defer), ORCH-2 (worktree-изоляция), ORCH-046
+(дословный reason в `task_desc` при откате).

docs/architecture/adr/adr-0007-executable-self-deploy.md

@@ -0,0 +1,64 @@
+# ADR-0007: Исполняемый самодеплой стадии `deploy` (Вариант B, ORCH-36)
+
+## Статус
+Accepted (design) — реализация в ветке `feature/ORCH-036`.
+
+## Контекст
+Стадия `deploy` была «бумажной»: deployer-агент писал `deploy_status:` в
+`14-deploy-log.md`, гейт `check_deploy_status` парсил вердикт и двигал
+`deploy → done`. Реального деплоя не было. ORCH-36 делает стадию исполняемой для
+self-hosting (`orchestrator`), сохраняя прежний ssh-путь для остальных репо.
+
+Три ограничения формируют дизайн (детально — `docs/work-items/ORCH-036/06-adr/ADR-001`):
+1. **Self-restart**: рестарт прод-контейнера 8500 убивает in-container процесс →
+   рестарт делает ВНЕШНИЙ host-процесс.
+2. **Status-only verdict model**: approve = смена статуса Plane на `Approved`
+   (комментарии не управляют конвейером).
+3. **Гонка гейта**: вердикт нельзя читать до завершения асинхронного хука.
+
+## Решение
+Для self-hosting стадия `deploy` исполняется в три фазы детерминированным кодом
+(без LLM в критическом пути self-restart):
+
+- **Фаза A (вход в `deploy`)** — для self + `deploy_require_manual_approve=true`
+  вместо запуска прод-deployer выставляется approval-pending статус Plane + запрос
+  approve (Plane-коммент + Telegram). Перехват в `advance_stage` на ребре
+  `deploy-staging → deploy` (после `check_staging_status` и merge-gate).
+- **Фаза B (Plane → Approved)** — `advance_stage(deploy, finished_agent=None)`
+  запускает **detached host-процесс** (ssh + setsid → `orchestrator-deploy-hook.sh`
+  с прод-параметрами и build-once retag) и ставит **детерминированный finalizer-job**
+  с задержкой; маркер `initiated` — идемпотентность. Возврат БЕЗ advance.
+- **Фаза C (finalizer)** — после рестарта новый контейнер дочитывает sentinel
+  `result` (exit-code хука), маппит `0→SUCCESS / иначе→FAILED`, пишет
+  `14-deploy-log.md`, вызывает `advance_stage(deploy, finished_agent="deployer")`
+  → существующие контракты: `SUCCESS → done`, `FAILED → откат БАГ-8 на development`.
+
+### Ключевые инварианты (НЕ меняются)
+`STAGE_TRANSITIONS`, реестр QG, `check_deploy_status` / `_parse_deploy_status`
+(frontmatter only), откат БАГ-8, terminal-sync `deploy → done`, merge-gate (ORCH-43),
+exit-code-контракт хука (0/1/2).
+
+### Новое (сквозное)
+- **Детерминированный job-kind** `deploy-finalizer` в очереди (reserved-agent, не
+  LLM): read-result | defer | map+write+advance. Зеркалит детерминизм merge-gate.
+- **Approve-флаг** `deploy_require_manual_approve` (дефолт `true`; полный авто —
+  отдельная задача после набора метрик доверия, ORCH-54).
+- **Build-once**: опциональный `SOURCE_IMAGE` retag в хуке (обратно совместимо).
+- **Restart-safe состояние** деплоя — sentinel-файлы под
+  `<repos_dir>/.deploy-state-<repo>/<wi>/` (как merge-lease), БЕЗ миграции БД.
+
+### Условность
+Вся логика — только для `is_self_hosting_repo(repo)` (как ORCH-35). Прочие репо
+деплоятся прежним синхронным ssh-путём агентом.
+
+## Последствия
+- `deploy_status: SUCCESS` доказан реальным health-ok; критический путь self-restart
+  детерминирован.
+- Вводится новая под-компонента (finalizer job-handler) → изменение помечено
+  `arch:major-change`.
+- Approve вписан в status-only модель: restart-safe, аудируемо, идемпотентно.
+- На старте — обязательный ручной approve; молчаливых деплоев нет (Plane+Telegram).
+
+## Связанные ADR
+`adr-0003` (staging-gate), `adr-0006` (merge-gate), `adr-0005` (run-as-host-uid).
+Детальный per-work-item: `docs/work-items/ORCH-036/06-adr/ADR-001-executable-self-deploy.md`.

docs/architecture/adr/adr-0007-reconciler.md

@@ -0,0 +1,86 @@
+# adr-0007: Reconciler застрявших стадий (sweeper потерянных webhook)
+
+- **Статус:** accepted (реализовано в `src/reconciler.py`)
+- **Дата:** 2026-06-06
+- **Задача:** ORCH-053
+- **Детальный ADR:** `docs/work-items/ORCH-053/06-adr/ADR-001-stuck-task-reconciler.md`
+
+## Контекст
+Конвейер продвигается **только** входящими webhook (Plane status / Gitea CI/PR).
+Потерянное событие (502 на ребилде, отсутствие ретраев у Plane/Gitea,
+неразрезолвленный `sha→branch`) → источник истины изменился, а стадия задачи —
+нет; задача застревает молча (инцидент ORCH-044). Существующий resilience
+(`requeue_running_jobs`, orphan-recovery, events de-dup ORCH-5, `ci_poll`
+ORCH-045) работает на уровне jobs/agent_runs и **не реконсилирует**
+рассинхрон «источник истины ≠ стадия задачи».
+
+## Решение
+Фоновый daemon-поток `src/reconciler.py` (паттерн `queue_worker`, module-singleton,
+`threading.Event`), стартует в `main.lifespan` после `worker.start()`, стоп в
+`finally` перед `worker.stop()`. Две взаимодополняющие ветки на каждом тике
+(`reconcile_interval_s`, дефолт 120с):
+
+- **F-1 gate-side** (локальная БД): для каждой `task` где `stage∉{done}`, **нет**
+  активного job, `age(updated_at) ≥ grace_for_stage(stage)` — read-only пред-оценка
+  канонического QG стадии; если зелёный → продвижение **штатным**
+  `stage_engine.advance_stage(..., finished_agent=None)` (тот же путь, что у Plane
+  Approved-webhook). Красный → **тишина** (нет advance, нет нотификаций — спам
+  структурно невозможен). `analysis` F-1 **не** реконсилирует (человеческий гейт →
+  отдан F-2).
+- **F-2 plane-side** (опрос Plane API per-project через `list_issues_by_state`):
+  `In Progress`+нет задачи → `handle_status_start`; `Approved`+не сдвинута →
+  `handle_verdict(approved=True)`; `Rejected`+не откатана →
+  `handle_verdict(approved=False)`. Обработчики `webhooks/plane.py`
+  **переиспользуются** (async → `asyncio.run` из sync-потока), логика не дублируется.
+- **F-3:** усиление `sha→branch` в `handle_ci_status` (БД-fallback по
+  `repo`+`stage='development'`, видимость на INFO) — defense-in-depth.
+
+**Инварианты:** источник истины — гейт/Plane, не событие; продвижение только через
+`advance_stage`; идемпотентность (active-job guard + atomic-claim на создании +
+grace + `max_concurrency=1`); never-raise на единицу работы; тишина при
+синхронности; restart-safe; kill-switch.
+
+## Альтернативы
+- **Флаг подавления нотификаций в `advance_stage`** — отклонён: меняет общий
+  критический путь. Вместо этого «не вызывать advance_stage на красном гейте».
+- **UNIQUE-индекс `tasks.plane_id`** для анти-дубля — отклонён как primary: риск
+  падения миграции на проде; выбран process-wide `threading.Lock` (single-process
+  топология). Индекс — задокументированное будущее упрочнение для multi-process.
+- **Отдельная стадия/QG реконсиляции** — вне объёма; нарушает «источник истины —
+  существующий гейт».
+- **Реконсиляция analysis по локальным артефактам** — отклонена: автопродвижение
+  неодобренного человеком BRD.
+
+## Последствия
+- Потерянный webhook ≠ молча застрявшая задача; ручной heartbeat-watchdog не нужен;
+  резервная сетка к ORCH-51 (буфер недоставленных) и ORCH-36 (deploy).
+- Плата: фоновый поток + опрос Plane API (митигируется интервалом/фильтром/
+  per-project); двойная оценка гейта на зелёной задаче; анти-дубль опирается на
+  single-process-допущение (как и очередь ORCH-1).
+- Self-hosting: `reconcile_enabled` — обязательный kill-switch; поэтапный раскат
+  (`reconcile_plane_enabled` гасит только F-2); reconciler не рестартит/не роняет
+  прод-контейнер. БД-схема и реестры (`STAGE_TRANSITIONS`/`QG_CHECKS`) не меняются.
+
+## Уточнения
+- **ORCH-060** (`docs/work-items/ORCH-060/06-adr/ADR-001-reconciler-skip-escalated.md`):
+  F-1 (`_reconcile_gate_task`) приобретает два пред-гарда ДО оценки гейта —
+  пропускает escalated (`developer_retry_count ≥ MAX_DEVELOPER_RETRIES`,
+  детерминированно) и Blocked/Needs-Input (Вариант A, Plane API, без миграции)
+  задачи. Инварианты adr-0007 сохранены (схема/реестры не меняются, never-raise,
+  тишина при пропуске).
+
+- **ORCH-068** (`docs/work-items/ORCH-068/06-adr/ADR-001-reconciler-terminal-exclusion-and-cache-ttl.md`):
+  фикс livelock F-2 (спам `_note_unblock` по синхронизированной done-задаче после
+  ORCH-066). F-2 исключает терминалы по **группе состояния** (`completed`/`cancelled`,
+  fallback — ключи `done`/`cancelled`) проектно-независимо; `_note_unblock` — только при
+  подтверждённом state change (сравнение стадии до/после `_dispatch`) + in-memory дедуп;
+  `_STATES_CACHE` получает TTL (`ORCH_PLANE_STATES_TTL_S`, дефолт 300с, `0`=lifetime).
+  Инварианты adr-0007 сохранены (источник истины — Plane; реестры/схема/`handle_*`/F-1/F-3
+  не меняются; never-raise; kill-switch'и).
+
+## Связи
+adr-0002 (очередь / `available_at`, single-process-singleton), adr-0003 (условный
+гейт — образец условности/флагов раската), adr-0006 (merge-gate как под-гейт ребра
+внутри `advance_stage`), adr-0001 (реестр проектов для F-2 per-project), ORCH-5
+(events de-dup — защита от дублей; reconciler — обратная защита от потерь),
+ORCH-045 (`ci_poll`).

docs/architecture/adr/adr-0008-staging-image-provenance.md

@@ -0,0 +1,77 @@
+# ADR-0008: Провенанс staging-образа перед BUILD-ONCE retag в прод (ORCH-058)
+
+## Статус
+Accepted (design) — реализация в ветке `feature/ORCH-058-self-deploy-retag-staging`.
+Метка: `arch:major-change`.
+
+> Примечание о нумерации: в `adr/` исторически два файла `adr-0007-*`
+> (`executable-self-deploy`, `reconciler`) — пред-существующая коллизия. Этот ADR берёт
+> следующий свободный номер **0008**; коллизию 0007 не трогаем (вне объёма ORCH-058).
+
+## Контекст
+
+ORCH-36 (`adr-0007-executable-self-deploy`) сделал стадию `deploy` исполняемой для
+self-hosting: Phase B запускает host-хук, который шагом **2b** (BUILD-ONCE) делает
+`docker tag $SOURCE_IMAGE → $TARGET_IMAGE` **без rebuild** — «прод = ровно тот артефакт,
+что прошёл staging». Предпосылка: staging-образ свеж и собран из провалидированного кода.
+
+**Этой гарантии нет.** Конвейер нигде не пересобирает `orchestrator-orchestrator-staging`
+из провалидированного коммита; `deploy-staging` лишь гоняет `staging_check.py` против уже
+работающего 8501. Инцидент (LESSONS_ORCH-036 п.4): staging-образ не пересобрали → проверка
+прошла против старого кода → retag промоутнул СТАРЫЙ образ → прод **молча** откатился на
+2-дневный код. Зелёный гейт = ложный позитив. Самый опасный из 4 багов: не падает, а тихо
+откатывает инструмент, обслуживающий все проекты.
+
+## Решение
+
+Гарантировать `INV-FRESH`: в прод промоутится только образ, собранный из коммита,
+провалидированного `deploy-staging` для данной задачи; иначе fail-fast (`FAILED` → откат на
+`development`, БАГ-8), прод не трогается. Достигается **двумя взаимодополняющими слоями**
+(defense in depth), только для self-hosting (условность как ORCH-35/36/43):
+
+- **A — пересборка (liveness).** На ребре `deploy-staging → deploy`, ПОСЛЕ merge-gate и ДО
+  Phase A, детерминированный QG-под-чек `check_staging_image_fresh` пересобирает
+  `orchestrator-orchestrator-staging` из worktree валидированного коммита
+  (`--build-arg GIT_SHA=<sha>`, лейбл `org.opencontainers.image.revision`), пересоздаёт 8501
+  и прогоняет `staging_check`. FAIL → откат на `development`. Так валидируемый и промоутимый
+  артефакт — один и тот же; гарантирует наличие зелёного пути (нет вечного fail-fast).
+- **B — fail-closed guard (safety).** Хук шагом 2b ПЕРЕД `docker tag` сверяет лейбл
+  `revision` образа `SOURCE_IMAGE` с `EXPECTED_REVISION` (пробрасывает `build_deploy_command`).
+  Несовпадение / пустой лейбл / пустой ожидаемый SHA / ошибка inspect → `exit 1` → FAILED.
+  Делает тихий промоут устаревшего образа структурно невозможным даже при отключённой/
+  проигравшей гонку A.
+
+**Якорь провалидированного коммита** — `git rev-parse HEAD` в worktree ПОСЛЕ merge-gate
+(post-rebase tree, который ре-тестирован и сольётся в `main`). Один helper
+`validated_revision(repo, branch)` питает и штамп сборки (A), и `EXPECTED_REVISION` (B).
+
+**Условность и kill-switch:** единый `image_freshness_enabled` (вкл/выкл A+B как целое,
+чтобы не было «B без A» = вечный fail-fast), `image_freshness_repos` (CSV; пусто →
+self-hosting). Все настройки с префиксом `ORCH_`.
+
+### Что НЕ меняется
+`STAGE_TRANSITIONS` (набор стадий — под-гейт ребра, не стадия), exit-code хука (0/1/2),
+`map_exit_code_to_status`, `check_deploy_status`/`_parse_deploy_status`, БАГ-8, terminal-sync,
+merge-gate, Phase A/B/C. Схема БД — без миграций (провенанс в лейбле образа, не в БД).
+
+### Что добавляется (сквозное)
+- QG `check_staging_image_fresh` в реестре `QG_CHECKS` (+ snapshot-тест), wired через
+  `_handle_image_freshness` в `stage_engine` (рядом с merge-gate).
+- Режим хука `--build-staging` (build из worktree + recreate 8501; STAGING-safe дефолты).
+- OCI-лейбл `org.opencontainers.image.revision` в `Dockerfile` (`ARG GIT_SHA`).
+- Helpers `validated_revision` / `rebuild_staging_image` в `self_deploy.py` (never-raise).
+
+## Последствия
+
+- Класс «тихого регресса прод» закрыт структурно (B); валидный деплой всегда доходит до
+  зелёного (A) — устранён ручной bootstrap-разрыв пересборки staging.
+- Латентность ребра растёт (build + recreate + повторный staging_check); `staging_check`
+  гоняется дважды (soft pre-check агента + авторитетный код) — плата за «валидируем =
+  промоутим».
+- Все сборки/recreate — ТОЛЬКО staging (8501); прод (8500) не трогается; `main` не пушится.
+  Новая под-компонента → `arch:major-change`.
+
+## Связанные ADR
+`adr-0007-executable-self-deploy` (BUILD-ONCE, Phase A/B/C), `adr-0006-merge-gate` (образец
+edge-под-гейта), `adr-0003-staging-gate` (условность self-hosting), `adr-0005`
+(run-as-host-uid). Детальный per-work-item: `docs/work-items/ORCH-058/06-adr/ADR-001-staging-image-provenance.md`.

docs/architecture/adr/adr-0009-staging-infra-tolerance.md

@@ -0,0 +1,56 @@
+# adr-0009: Толерантность staging-вердикта к заведомо инфраструктурным FAIL
+
+- **Статус:** accepted
+- **Дата:** 2026-06-07
+- **Задача:** ORCH-061
+- **Детально:** `docs/work-items/ORCH-061/06-adr/ADR-001-staging-infra-tolerance.md`
+
+## Контекст
+Self-hosting `orchestrator` зацикливался на `deploy-staging`: `staging_check.py`
+давал 2 ложных FAIL (C9a — ветка в sandbox, C9b — analyst-job в очереди), вызванных
+отсутствием sandbox-настроек (bot-аккаунты не члены SANDBOX-проекта), а не регрессом
+кода. `staging_check.py` делал `sys.exit(1)` при любом FAIL → deployer писал
+`staging_status: FAILED` → `check_staging_status` FAILED → откат `deploy-staging →
+development` → петля (жгла developer-ретраи и кредиты). Прод-деплой орка приходилось
+доводить вручную — блокер автономного внедрения (ORCH-54).
+
+## Решение
+Классифицировать проверки staging-suite на **REAL** (pipeline) и **SANDBOX_INFRA**
+(заведомо инфраструктурные, узкий allowlist `{C9a, C9b}`) и сделать вердикт
+толерантным к инфра-FAIL, сохранив fail-closed для реальных проверок:
+
+- Новый leaf-модуль `src/staging_verdict.py` (pure, never-raise, stdlib):
+  `classify_check(label)` + `compute_staging_verdict(items, infra_tolerant)`.
+  Правило: упала хоть одна REAL → FAILED/exit1; упали ТОЛЬКО SANDBOX_INFRA и
+  толерантность вкл → SUCCESS/exit0 (waived); толерантность выкл → legacy strict
+  (любой FAIL → FAILED).
+- `scripts/staging_check.py` помечает проверки категориями, считает вердикт через
+  `staging_verdict`, печатает `INFRA-WAIVED` при вайвере (наблюдаемость).
+- Kill-switch `staging_infra_tolerance_enabled` (env
+  `ORCH_STAGING_INFRA_TOLERANCE_ENABLED`, дефолт `True`; в `.env.staging`).
+- `check_staging_status` / `_parse_staging_status` / `STAGE_TRANSITIONS` / реестр
+  `QG_CHECKS` — **без изменений**; новый QG-чек не вводится. Условность ORCH-35
+  сохранена (не-self → no-op N/A).
+- Инвариант FR-3: «no changes to commit» на action-стадиях (`deploy-staging`/`deploy`)
+  не есть недовыполнение — продвижение определяется exit0 + гейт-вердиктом
+  (launcher уже не откатывает; добавлена observability-строка).
+
+## Альтернативы
+- Только починить sandbox-инфру (направление а) — хрупко, не структурно, вне
+  автономной досягаемости таска; оставлено как опциональное hardening.
+- «Зелёный по умолчанию» при недоступности проверок — запрещён (fail-closed).
+- Новый QG-чек / структурный артефакт `15-staging-log.md` — избыточно, меняло бы
+  контракты/реестр; толерантность размещена в suite до артефакта.
+
+## Последствия
+- Петля устранена; страховка цела (реальный регресс → FAILED → откат).
+- Чистая вердикт-логика юнит-тестируема без live staging/docker.
+- Контракты гейтов/стадий/вердиктов/реестра и схема БД неизменны.
+- Риск: узкое окно — реальный регресс именно в создании ветки/постановке
+  analyst-job может быть заваивен; митигировано allowlist'ом `{C9a,C9b}` + условием
+  «все REAL (вкл. C7/C8) зелёные» + INFRA-WAIVED-логом. Разблокирует ORCH-54.
+
+## Связи
+adr-0003 (условный staging-гейт — база `is_self_hosting_repo` / `check_staging_status`),
+adr-0006 (merge-gate), adr-0007 (исполняемый self-deploy), adr-0008 (провенанс
+staging-образа). Блокирует ORCH-54.

docs/architecture/adr/adr-0010-post-deploy-monitor.md

@@ -0,0 +1,85 @@
+# adr-0010: Post-deploy мониторинг прода + реакция на деградацию
+
+- **Статус:** proposed (design) — реализация в ветке `feature/ORCH-021-post-deploy-rollback`
+- **Дата:** 2026-06-07
+- **Задача:** ORCH-021
+- **Метка:** `arch:major-change` (новая под-компонента + новый reserved-agent job-kind)
+- **Детальный ADR:** `docs/work-items/ORCH-021/06-adr/ADR-001-post-deploy-monitor.md`
+
+## Контекст
+Конвейер заканчивается на `deploy → done`: `check_deploy_status` видит
+`deploy_status: SUCCESS` → terminal-sync (Plane → Done, release merge-lease), и
+оркестратор **забывает про прод**. «Успех» сегодня = health-check в момент рестарта
+(~60с окно в `orchestrator-deploy-hook.sh`). Класс инцидентов «зелёный деплой, красный
+прод» (прецедент **ET-8**): деградация проявляется через минуты под боевым трафиком,
+health отвечает `200 ok`, фича сломана. Для self-hosting опасно вдвойне — сломанный
+прод-орк (8500) обслуживает ВСЕ проекты из общего инстанса.
+
+## Решение
+Продлить ответственность конвейера **ЗА** `done`: после терминального перехода для
+применимого репо армится пост-деплой наблюдение окна `post_deploy_window_s` (дефолт
+~15 мин) с интервалом `post_deploy_interval_s`; деградация фиксируется по
+**детерминированным порогам**, при подтверждении выполняется реакция.
+
+**Механизм — reserved-agent job `post-deploy-monitor`** (калька `deploy-finalizer`,
+ORCH-36), НЕ отдельная стадия и НЕ daemon-поток:
+- **Арм:** в `stage_engine.advance_stage`, в блоке `next_stage == "done"`, при
+  `post_deploy.post_deploy_applies(repo)` → `post_deploy.arm_monitor(...)` (sentinel
+  `armed` = идемпотентность, первый job через `enqueue_job(available_at_delay_s=...)`).
+- **Тик:** `launcher.launch_job` перехватывает `agent == "post-deploy-monitor"` ДО
+  `_spawn` → `stage_engine.run_post_deploy_monitor(job)`: один опрос сигналов, append в
+  персистентный `series`, классификация; HEALTHY и окно не истекло → перепостановка с
+  задержкой; иначе → реакция + артефакт + `mark_done`.
+- **Чистая логика — новый leaf-модуль `src/post_deploy.py`** (never-raise, по образцу
+  `self_deploy.py`/`staging_verdict.py`): `post_deploy_applies`, `probe_signals`
+  (опрос `/health` + доля 5xx на `/status`,`/queue`), `classify` (HEALTHY|DEGRADED —
+  главный предмет юнит-тестов), `decide_action` (NONE|ROLLBACK|ALERT_ONLY с учётом
+  self-hosting), sentinel-state хелперы, `write_post_deploy_log`.
+
+**Сигналы и пороги (детерминированно, AC-3…AC-6):** `DEGRADED` ⇔ `≥
+post_deploy_fail_threshold` ПОСЛЕДОВАТЕЛЬНЫХ провалов health ИЛИ доля 5xx на окне `>
+post_deploy_5xx_threshold`. Одиночный глюк < порога → HEALTHY (нет ложных откатов).
+
+**Реакция (BR-4/BR-5):**
+- **Self-hosting (`orchestrator`) — ВСЕГДА `ALERT_ONLY`:** громкий Telegram + Plane,
+  запрос ручного approve отката. Тик НИКОГДА не откатывает/рестартит прод-контейнер
+  (структурный инвариант). Откат прод-орка, если оператор решит, — только detached
+  host-процесс (`self_deploy.initiate_deploy`), вне тика (MVP).
+- **Не-self + `post_deploy_auto_rollback=True`:** хук `--rollback` с прод-env; exit
+  `0 → ROLLBACK_OK`, `1/2 → ROLLBACK_FAILED` + громкий алерт.
+- Дефолт (`auto_rollback=False`) → `ALERT_ONLY`.
+
+**Артефакт `16-post-deploy-log.md`** (новый) с YAML-frontmatter (`post_deploy_status`,
+`action_taken`, `window_s`, `checks_total/failed`) — машиночитаемо для петли уроков
+ORCH-8; best-effort. **Наблюдаемость** — блок `post_deploy` в `GET /queue` (образец
+`reconcile.status()`).
+
+## Альтернативы
+- **Daemon-watchdog (как reconciler)** — отклонён: per-task серия опросов в памяти не
+  restart-safe (а деплой орка = рестарт); restart-safe-вариант требует тех же sentinel,
+  reserved-agent проще и уже имеет проверенную jobs+sentinel машинерию.
+- **Отдельная пост-deploy стадия + QG** — отклонён: меняет `STAGE_TRANSITIONS`/
+  `QG_CHECKS`, ломает семантику терминального `done`; наблюдение принципиально ПОСЛЕ
+  `done`.
+- **Авто-rollback прод-орка из тика** — отклонён (self-hosting safety): групповой риск;
+  контейнер не откатит себя надёжно. Self → alert + ручной approve (как ORCH-54).
+- **Колонка в `tasks`** — отклонён: миграция на проде; sentinel-файлы restart-safe
+  (как ORCH-36/53/58).
+
+## Последствия
+- Класс «зелёный деплой, красный прод» закрыт измеримыми порогами; деградация =
+  сигнал для ORCH-8.
+- Реестры (`STAGE_TRANSITIONS`/`QG_CHECKS`), контракт `check_deploy_status`,
+  terminal-sync, merge-gate, exit-code-контракт хука, схема БД — **не меняются**.
+- Дефолты безопасны: kill-switch on, auto-rollback off, self только alert.
+- Ограничение: монитор self бежит внутри наблюдаемого прода — полностью wedged
+  контейнер = пропущенный тик/алерт (known MVP gap; внешний watchdog — follow-up).
+- Self-hosting: тик не рестартит/не роняет прод-контейнер; kill-switch
+  `post_deploy_monitor_enabled` обязателен; поэтапный раскат через `post_deploy_repos`.
+
+## Связи
+adr-0007-executable-self-deploy (ORCH-36 — sentinel/detached-host/finalizer образец,
+`map_exit_code_to_status`), adr-0007-reconciler (ORCH-53 — daemon/`status()` образец,
+отклонён как основной механизм), adr-0006 (merge-gate — условность/флаги раската),
+adr-0003 (staging-gate — образец условности), adr-0008 (provenance — `.deploy-prev-image`/
+хук-откат). Прецедент ET-8. Будущее: ORCH-8 (петля уроков), ORCH-54 (полный авто).

docs/architecture/adr/adr-0011-job-reaper-lease-reclaim.md

@@ -0,0 +1,82 @@
+# adr-0011: Job-reaper + проактивный реклейм merge-lease
+
+| | |
+|---|---|
+| Статус | accepted |
+| Дата | 2026-06-07 |
+| Источник | ORCH-065 (BUG P0, блокер ORCH-54) |
+| Детально | `docs/work-items/ORCH-065/06-adr/ADR-001-job-reaper-and-lease-reclaim.md` |
+
+## Контекст
+
+Единый инстанс с общей БД и очередью (`jobs`, `max_concurrency=1` для
+self-hosting). Финализация статуса job (`done`/`queued`/`failed`) происходит
+ТОЛЬКО в `launcher._monitor_agent → _finalize_job` внутри живого процесса. Смерть
+monitor-потока/процесса между `proc.wait()` и `_finalize_job` (краш, OOM,
+self-restart во время deploy) оставляет строку `jobs` навсегда `running`. При
+`max_concurrency=1` одна такая зомби-строка блокирует claim всех job →
+**встаёт конвейер всех проектов**. Единственная защита — `requeue_running_jobs()`
+— работает ТОЛЬКО на старте процесса. Симметрично: merge-lease (ORCH-043,
+файл `.merge-lease-<repo>.json`) реклеймится лишь лениво по TTL при чужом
+`acquire`; liveness держателя по pid не проверяется → залипший lease блокирует
+чужие merge. Это последняя ручная точка автономного self-deploy (блокер ORCH-54);
+доказанные инциденты 07.06 — jobs 236/239/242/254.
+
+## Решение
+
+1. **Job-reaper** — новый daemon-поток `src/job_reaper.py` (каркас `reconciler`:
+   never-raise, `_stop`-Event, старт/стоп в `lifespan`, снимок в `/queue`,
+   kill-switch). Работает **без рестарта** процесса. Liveness — трёхуровневая:
+   Tier-1 мёртвый `jobs.pid` (новая колонка) после `reaper_dead_ticks` подряд
+   тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running` — но только
+   после finalization-grace `reaper_finalize_grace_s` (окно неоднозначно: живой
+   monitor пишет exit_code ПЕРВЫМ, затем git push/PR/Plane-комментарии, поэтому
+   живой финализирующий monitor НЕ реапится); Tier-3 backstop по потолку
+   `reaper_max_running_s`. Действие — **claim-before-act**: для exit0 канонический
+   QG оценивается read-only ПЕРЕД атомарным claim, затем claim `done` ПЕРВЫМ и
+   только победитель claim выполняет `_try_advance_stage` (advance+enqueue) —
+   проигравший не делает побочных эффектов (источник истины — QG, не «exit0»);
+   гейт красный или exit≠0 / неизвестно → `attempts<max` → `queued`, иначе
+   `failed`+Telegram. Атомарный reap-claim (`UPDATE ... WHERE id=? AND
+   status='running'` + `rowcount`, как `claim_next_job`) исключает двойную
+   обработку (совместимость со стартовым `requeue_running_jobs`).
+2. **Проактивный реклейм stale/dead lease** — функции в `merge_gate.py`
+   (`pid_alive`, `reclaim_stale_lease`), вызываемые на старте (рядом с
+   `requeue_running_jobs`) и периодически из тика reaper. Освобождение, если
+   держатель **мёртв** (pid не жив) ИЛИ **просрочен** (TTL); живой держатель в
+   пределах TTL — НЕ трогать. holder-aware, never-raise, условность как ORCH-43.
+3. **Идемпотентная финализация merge** — без новой merge-логики: re-drive через
+   reaper→`queued`→переисполнение стадии / reconciler; дорогие шаги не
+   повторяются (`branch_is_behind_main==False`); добавлен детерминированный
+   never-raise guard `pr_already_merged` (читает состояние PR), консультируемый
+   перед повторным merge → уже слит = no-op.
+4. **Схема БД** — `jobs.pid INTEGER` через идемпотентный `_ensure_column`
+   (паттерн live-safe миграции). Больше ничего не меняется.
+
+Kill-switch'и (`ORCH_*`): `reaper_enabled`, `reaper_interval_s`,
+`reaper_dead_ticks`, `reaper_max_running_s`, `reaper_finalize_grace_s`,
+`lease_reclaim_enabled`; переиспользуются `merge_lock_timeout_s`,
+`merge_gate_repos`. `false` → строго прежнее поведение.
+
+## Альтернативы
+- Reaper внутри reconciler — отвергнуто (смешение stage- и jobs-уровней, общий
+  kill-switch, хуже изоляция).
+- Только эвристика `agent_runs` без `jobs.pid` — отвергнуто как основной механизм
+  (не ловит зомби, чей monitor умер до записи exit_code); оставлена как Tier-2/3.
+- БД-lock / внешний брокер очередей — вне объёма (single-node SQLite).
+- Форс `done` по факту exit0 — отвергнуто; выбран gate-driven advance.
+
+## Последствия
+- (+) Зомби-job и залипший lease самовосстанавливаются без рестарта и без
+  оператора; очередь общего инстанса не встаёт; снят технический блокер ORCH-54.
+- (+) Контракты неизменны (`STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, БАГ-8,
+  exit-коды хука); одна колонка через проверенный idempotent-паттерн.
+- (−) pid-liveness валиден в предположении одного pid-namespace (агент —
+  дочерний процесс оркестратора); закрыто backstop'ом по времени и TTL.
+- (−) streak-счётчик in-memory (сброс на рестарте; рестарт покрыт
+  `requeue_running_jobs`).
+
+## Связи
+- Базируется: adr-0002 (очередь), adr-0006 (merge-gate), adr-0007 (reconciler /
+  self-deploy).
+- Разблокирует: ORCH-54.

docs/architecture/adr/adr-0012-security-gate.md

@@ -0,0 +1,63 @@
+# adr-0012: Security-гейт — secret-scanning + dependency audit перед мержем
+
+- **Статус:** proposed
+- **Дата:** 2026-06-07
+- **Задача:** ORCH-022
+- **Детальный ADR:** `docs/work-items/ORCH-022/06-adr/ADR-001-security-gate.md`
+
+## Контекст
+Оркестратор автономен: `developer` пишет код без человека-фильтра. Перед слиянием ветки в
+`main` нет проверки на утёкший секрет (ключ/токен/пароль/приватный ключ) и уязвимую
+зависимость (CVE). Для self-hosting один общий прод-инстанс обслуживает все проекты с общей
+БД — секрет/CVE через одну задачу попадает в прод всех (CLAUDE.md §self-hosting, §8). Фактический
+мерж PR в `main` делает `deployer` в начале стадии `deploy`.
+
+## Решение
+Детерминированный (без LLM) **security-гейт как под-гейт ребра `deploy-staging → deploy`**,
+рядом с merge-gate (ORCH-043) и image-freshness (ORCH-058), исполняемый **ПЕРВЫМ** среди
+edge-под-гейтов (ДО merge-gate). `STAGE_TRANSITIONS` не меняется; в `QG_CHECKS` добавлен
+`check_security_gate`. Паттерн — как у соседей: leaf-модуль `src/security_gate.py`
+(never-raise) + тонкая обёртка в `QG_CHECKS` + врезка `_handle_security_gate` в `advance_stage`.
+
+- **Secret-scanning (`gitleaks`, offline):** скан `origin/main..HEAD`; любой секрет вне
+  аллоулиста (`.gitleaks.toml`) → вклад в FAIL. Offline → гарантия «секрет всегда блокирует»
+  не зависит от сети.
+- **Dependency audit (`pip-audit`, OSV/PyPI):** severity ≥ `security_dep_block_severity`
+  (дефолт `HIGH`) → FAIL; ниже / UNKNOWN → warning. Недоступность фида → **fail-open +
+  громкий warning** (анти-петля; флаг `security_dep_audit_fail_closed` для строгого режима).
+- **ПЕРВЫМ на ребре, ДО merge-gate:** дёшево фейлить до дорогих rebase/rebuild; скан ветки
+  ДО rebase не «обвиняет» задачу в CVE, притащенной обновившимся `main` (анти-петля
+  ORCH-061); до захвата merge-lease → при FAIL lease освобождать не нужно.
+- **Артефакт `17-security-report.md`** с YAML-frontmatter (`security_status`,
+  `secrets_found`, `deps_blocking`, `deps_warning`, `deps_audit_degraded`); вердикт читается
+  ТОЛЬКО из frontmatter (канон), negative-токен авторитетен; битый/нет → fail-closed.
+- **FAIL → откат на `development`** + developer-retry (общий `_developer_retry_count`, cap 3,
+  затем `set_issue_blocked` + Telegram); `task_desc` несёт дословные находки (ORCH-046).
+- **Условность (как ORCH-35/43/58):** `security_gate_enabled` + `security_gate_repos`; пусто
+  → реально только self-hosting (`orchestrator`), прочие репо — no-op pass.
+- **never-raise**, таймаут `security_scan_timeout_s`, гейт не деплоит/не рестартит прод.
+
+## Альтернативы
+- **Вариант R (review-стадия):** diff может разойтись с мержем в `main`; merge-edge — последняя
+  страховка. Отклонено.
+- **Вариант C (CI-job через `check_ci_green`):** пороги/severity/аллоулист/артефакт плохо
+  выражаются статусом коммита; коуплинг с раннером. Отклонено для v1 (точка расширения).
+- **Новая стадия `security`:** «пустая» стадия без агента не имеет триггера (как в ORCH-043).
+  Отклонено.
+- **fail-closed dep-audit / аудит после rebase:** ложные откаты → петля. Отклонено.
+- **Новая колонка retry в БД:** не нужна (переиспользуем `_developer_retry_count`).
+
+## Последствия
+- Класс «тихо влитый секрет/CVE» закрыт: секреты — безусловно (offline), CVE — best-effort при
+  доступности фида. Самоприменение CLAUDE.md §8 без человека.
+- Плата: ещё один «скрытый» под-гейт ребра (нет в `STAGE_TRANSITIONS`); внешние инструменты
+  (gitleaks в образе, pip-audit в зависимостях); время скана на каждом прогоне (ограничено
+  таймаутом); v1 — Python-only (SAST/мульти-стек — follow-up WI).
+- Сквозное изменение (новый QG + edge-под-гейт) → `arch:major-change`; прод-деплой ORCH-022 —
+  строго через staging-гейт (8501), без рестарта прод-контейнера.
+
+## Связи
+adr-0006 (merge-gate — паттерн edge-под-гейта/отката), adr-0008 (image-freshness —
+условность/never-raise/fail-closed), adr-0003 (условный гейт / `is_self_hosting_repo`),
+adr-0009 (анти-петля ложных FAIL, ORCH-061), ORCH-046 (дословный reason в `task_desc`),
+ORCH-9/15 (мульти-стек — будущая зависимость), ORCH-2 (worktree-изоляция).

docs/architecture/adr/adr-0013-merge-verify-gate.md

@@ -0,0 +1,63 @@
+# adr-0013: Merge-в-main + пост-деплой верификация как условие `done` (фикс фантомного merge)
+
+- **Статус:** accepted
+- **Дата:** 2026-06-08
+- **Задача:** ORCH-071 (CRITICAL bug)
+- **Детальный ADR:** `docs/work-items/ORCH-071/06-adr/ADR-001-merge-verify-gate.md`
+- **Постмортем:** `docs/history/LESSONS_2026-06-08_phantom-merge.md`
+
+## Контекст
+Для self-hosting репо `orchestrator` стадия `deploy` идёт детерминированным путём
+(`_handle_self_deploy_phase_b → initiate_deploy → run_deploy_finalizer`), а LLM-агент
+`deployer` НЕ запускается. Фактический merge PR в `main` исторически делал **только**
+агент `deployer` → на self-hosting пути **нет шага merge-в-main вообще**. Detached
+host-деплой лишь retag'ает образ + рестартит 8500; `done` достигается по
+`deploy_status: SUCCESS` без верификации `main`. «Зелёный» деплой (образ из рабочей
+ветки) маскирует отсутствие merge → следующая задача срезает ветку от устаревшего `main`
+и теряет код предшественника. Накопительно потеряны ORCH-022/059/066/068. Вторичный
+фактор: Phase B рестартит прод → merge внутри живого процесса гонялся бы с рестартом
+(урок №3).
+
+## Решение
+Детерминированный **merge-актор + пост-merge верификация** как **под-гейт ребра
+`deploy → done`**, врезанный в единственную функцию перехода `advance_stage` (симметрично
+edge-под-гейтам security/merge-gate/image-freshness). `STAGE_TRANSITIONS`,
+`check_deploy_status`/`_parse_deploy_status`, реестр `QG_CHECKS`, схема БД — **не меняются**.
+
+- **Врезка `_handle_merge_verify` в `advance_stage`** (`current_stage=="deploy"` и
+  `next_stage=="done"`, ПОСЛЕ зелёного `check_deploy_status`, ДО `update_task_stage`).
+  Гейтит **ВСЕ** пути к `done` единообразно: `run_deploy_finalizer` (Phase C), reconciler
+  F-1, job-reaper — все идут через `advance_stage`. Закрывает дыру: reconciler F-1 иначе
+  протолкнул бы `done` в обход merge.
+- **Merge в Phase C (после рестарта), НЕ в Phase B.** Phase C finalizer —
+  restart-surviving (reserved-job `deploy-finalizer`, claim воркером нового контейнера,
+  re-drive reaper'ом). Merge физически строго ПОСЛЕ рестарта → рестарт его не убивает
+  (G3 вторым вариантом — «шаг, переживающий рестарт»).
+- **Merge-актор `merge_gate.merge_pr`** — `pr_already_merged` (no-op повтор, ORCH-065) →
+  иначе Gitea `POST /repos/{owner}/{repo}/pulls/{index}/merge`. Никогда push/force-push в
+  `main`. never-raise.
+- **Верификатор `merge_gate.verify_merged_to_main`** — `PR.merged==true` ИЛИ
+  `git merge-base --is-ancestor <validated_sha> origin/main`. never-raise → `False`
+  («не подтверждено»).
+- **Не подтверждено → alert «deploy succeeded but not merged» (Telegram+Plane) + HOLD**
+  (`set_issue_blocked`, задача НЕ `done`, БЕЗ авто-отката на `development` — not-merged
+  есть инфра-дефект, реакция ALERT-only как ORCH-021 self-hosting). Подтверждено →
+  штатный `deploy → done` (терминал-sync / post-deploy monitor как сегодня) +
+  `merged_to_main: true` во frontmatter `14-deploy-log.md` (наблюдаемость, `deploy_status:`
+  нетронут).
+- **Идемпотентность (INV-5):** `pr_already_merged` перед merge; verify зелёный для
+  уже-слитого PR; повтор без дубль-merge/ложного отката.
+- **Условность (как ORCH-35/43/58):** `merge_verify_enabled` (kill-switch, дефолт `true`) +
+  `merge_verify_repos` (пусто → только self-hosting). Non-self репо — no-op, merge остаётся
+  за агентом `deployer`.
+
+## Инварианты
+never-raise на verify/merge (ошибка → alert, не падение конвейера); не рестартить/не ронять
+прод 8500; ручной approve прод-деплоя сохранён (`Confirm Deploy`, ORCH-059); только PR-merge
+API Gitea; restart-safe (sentinel + jobs, без миграции БД).
+
+## Последствия
+Невозможно «`done` + прод задеплоен, а PR `open`». Минусы: при недоступной Gitea verify
+консервативно `False` → возможен ложный HOLD+alert (снимается повтором; fail-closed для
+`done` приоритетен); HOLD требует ручного вмешательства. Диагностика фантома — runbook
+`docs/operations/PHANTOM_MERGE_RUNBOOK.md` (G4).

docs/architecture/adr/adr-0014-merge-verify-sha-source-of-truth.md

@@ -0,0 +1,77 @@
+# adr-0014: SHA-в-main — единственный критерий merge-verify + регресс-гард целостности `main`
+
+- **Статус:** accepted
+- **Дата:** 2026-06-08
+- **Задача:** ORCH-073 (BUG CRITICAL — эрозия `main`)
+- **Amends:** [adr-0013](adr-0013-merge-verify-gate.md) (ORCH-071) — меняет КРИТЕРИЙ подтверждения merge.
+- **Детальный ADR:** `docs/work-items/ORCH-073/06-adr/ADR-001-merge-verify-sha-truth-and-regression-guard.md`
+- **Постмортем:** `docs/history/LESSONS_2026-06-08_phantom-merge.md`
+
+## Контекст
+
+adr-0013 (ORCH-071) ввёл под-гейт merge-verify на ребре `deploy → done`, но допускал
+подтверждение merge по **ИЛИ-критерию**: `verify_merged_to_main` возвращал `True`, если
+`pr_already_merged(repo, branch)` **ЛИБО** SHA — предок `origin/main`. `pr_already_merged`
+засчитывал **любой** merged PR ветки, включая авто docs-PR (staging/deploy-логи). У одной
+feature-ветки в `main` сливались только docs-PR, а code-PR — нет → `pr_already_merged`=`True` →
+verify `CONFIRMED` → `done`, хотя кода в `main` не было. Накопительно потеряны ORCH-067 (ссылки
+`plane_issue_link`) и ORCH-069 (`qg0_title_max`). Вторичный усилитель — CHANGELOG-ребейзы,
+откатывающие ветку и тащащие устаревший код-сосед. Восстановление кода (G1) выполнено вручную
+restore-PR #76; этот ADR устраняет корень навсегда.
+
+## Решение
+
+1. **SHA-в-main — единственный критерий (FR-1).** `verify_merged_to_main(repo, branch, sha)`
+   подтверждает merge **ТОЛЬКО** прямым фактом `git merge-base --is-ancestor <sha> origin/main`
+   (после `git fetch origin main`). OR-ветка `pr_already_merged` **удалена** из верификатора.
+   Пустой `sha` / любая git-ошибка → `False` (fail-closed: alert + HOLD). never-raise (INV-1).
+2. **`pr_already_merged` → idempotency-guard, различающий code-PR/docs-PR (FR-2).** Засчитывает
+   merged PR только при `head.ref==<feature-branch>` И `base.ref=="main"` (явный фильтр в цикле,
+   не ненадёжный query-параметр `head`). Используется лишь как защита `merge_pr` от второго merge,
+   НЕ как подтверждение `done`.
+3. **`merge_pr` сливает именно code-ветку (FR-3).** Выбор открытого PR по `head.ref==branch` И
+   `base.ref=="main"`; merge только Gitea `POST /pulls/{index}/merge`, никогда push/force-push в
+   `main`. Источник истины «слилось» — FR-1.
+4. **Регресс-гард целостности `main` (FR-5).** Новая `merge_gate.check_main_regression`,
+   вызываемая в `_handle_merge_verify` ПОСЛЕ подтверждённого SHA-в-main и ДО `done`: проверяет, что
+   `origin/main` содержит **декларативный набор маркеров** ключевых функций ранее-merged задач
+   (`git grep -c <marker> origin/main -- <path>` > 0). Маркер отсутствует → **alert «main
+   regressed» + HOLD** (НЕ `done`, БЕЗ авто-отката на `development` — инфра-дефект, ALERT-only как
+   ORCH-021/071). Набор — append-only константа `MAIN_REGRESSION_MARKERS` в `merge_gate.py`
+   (расширяется каждой значимой задачей). **Fail-open** на git-ошибке самого грепа (регресс
+   утверждается только при детерминированном `count==0`); первичный фейл-клозед — SHA-в-main.
+   Kill-switch `regression_guard_enabled` (дефолт `true`); non-self → no-op.
+5. **`.gitattributes CHANGELOG.md merge=union` (FR-4).** В корне репо; авто-слияние правок
+   `## [Unreleased]` без конфликта → `auto_rebase_onto_main` не откатывает ветку и не тащит
+   устаревший код-сосед. `docs/**/*.md` под union **НЕ** ставится (union только для append-only;
+   доки переписываются построчно).
+
+## Инварианты
+
+never-raise на verify/merge/регресс-гарде (ошибка → alert/HOLD, не падение); прод 8500 не
+рестартится/не падает в рамках merge; merge только Gitea PR-API без force-push в `main`; ручной
+`Confirm Deploy` (ORCH-059) сохранён; идемпотентность по «SHA-в-main», а не по «любому merged PR»;
+non-self репо (enduro) — merge/verify/регресс-гард без изменений. `STAGE_TRANSITIONS`, реестр
+`QG_CHECKS`, `check_deploy_status`, схема БД, внешние HTTP-эндпоинты — **без изменений**.
+
+## Альтернативы
+
+- Сохранить PR-флаг как со-критерий verify (с фильтром head/base) — отклонено: PR можно слить и
+  тут же откатить ребейзом-соседом; надёжен только факт «SHA в main».
+- `docs/**/*.md merge=union` — отклонено: тихая дубликация строк в переписываемых доках.
+- Регресс-гард с авто-откатом / хранением маркеров в БД/Plane — отклонено (Не-цель «не менять
+  схему БД/Plane»; реакция ALERT-only).
+- Fail-closed на marker-grep — отклонено: ложный HOLD при git-сбое; marker-grep вторичен.
+
+## Последствия
+
+Невозможно «`done` + прод задеплоен, а code-PR не в `main`». Ложно-зелёный по docs-PR устранён в
+корне. CHANGELOG-конфликты больше не откатывают ветку. Регресс соседнего кода ловится отдельным
+гардом. Минус: при недоступной Gitea/git verify консервативно `False` → возможен ложный HOLD+alert
+(снимается повтором; fail-closed для `done` приоритетен). Набор маркеров требует дисциплины —
+значимая задача дописывает свой маркер.
+
+## Связи
+
+- Amends adr-0013 (ORCH-071), наследует adr-0006 (merge-gate), adr-0011 (job-reaper/lease).
+- Детально: `docs/work-items/ORCH-073/06-adr/ADR-001-merge-verify-sha-truth-and-regression-guard.md`.

docs/architecture/adr/adr-0015-task-deps-and-merge-serialization.md

@@ -0,0 +1,47 @@
+# adr-0015: Зависимости задач + сериализация merge внутри репо
+
+**Статус:** accepted · **Дата:** 2026-06-08 · **Источник:** ORCH-026
+**Связи:** дополняет adr-0006 (merge-gate), adr-0011 (merge-lease + reclaim), adr-0013/0014
+(merge-verify, SHA-in-main), adr-0002 (очередь). Детально —
+`docs/work-items/ORCH-026/06-adr/ADR-001-merge-serialization-and-task-deps.md`.
+
+## Контекст
+
+Эрозия `main` 08.06 родилась из некоординированного параллелизма задач одного репо (ветки от
+устаревшего `main`, фантом-merge затирает соседа). adr-0014 закрыл последствия; ORCH-026 — корень
+на уровне планировщика. Плюс исходный скоуп ORCH-026: декларативные зависимости задач (B ждёт A).
+
+## Решение
+
+**Уровень A — сериализация merge/деплоя (per-repo).** Окно сериализации уже обеспечивается
+merge-lease (adr-0011): захват в `check_branch_mergeable`, удержание до release (PR-merged webhook /
+`deploy→done`=SHA-in-main для self / откат / проактивный reclaim). Это и есть окно
+«merge → main-updated» — **механизм не переписывается**. Добавляется единственное новое поведение:
+**безусловный proactive pre-merge rebase** (флаг `premerge_rebase_always`, дефолт `True`, скоуп
+`merge_gate_repos`): под лизом всегда вызывается `auto_rebase_onto_main` (no-op + «Everything
+up-to-date» на актуальной ветке → CI не триггерится; реальный догон на отстающей). Инвариант:
+никаких push в `main`, force только `--force-with-lease` на ветку.
+
+**Уровень B — декларативные зависимости.** Аддитивная таблица `job_deps(task_id,
+depends_on_task_id)` — **источник истины планировщика** (offline-устойчивость: сетевой Plane в
+горячем claim встанет очередью всех проектов). Источник декларации настраивается
+`task_deps_source = db|plane|hybrid` (дефолт `db`); планировщик всегда читает БД-кэш. Гейт —
+условие `NOT EXISTS` в `claim_next_job` (задача не выбирается, пока есть незавершённая зависимость;
+слот `max_concurrency` не занимается). Циклы — DFS-детектор (`src/task_deps.py`) + `set_issue_blocked`
++ alert. Видимость — строка «⏳ ждёт ORCH-NNN» в Telegram-карточке (Plane Blocked — на дедлоке).
+Зависимости — только intra-repo (v1).
+
+## Альтернативы
+
+Отдельный merge-lock/merge-queue (дублирует adr-0011); расширение release-точек лиза (не нужно —
+окно уже корректно); Plane как источник истины планировщика (self-hosting risk); гейт зависимостей
+в воркере с claim+requeue (churn vs. чистый `NOT EXISTS`); поле в `tasks` вместо таблицы (M:N хуже).
+
+## Последствия
+
+Минимально-инвазивно: `STAGE_TRANSITIONS`/`QG_CHECKS` не тронуты (паттерн врезки), переиспользует
+merge-gate/merge-lease целиком. Обе фичи инертны без данных → нулевая регрессия для enduro-trails.
+restart-safe, never-raise, kill-switch на каждую (`premerge_rebase_always`, `task_deps_enabled`).
+Миграция — только аддитивная (`CREATE TABLE/INDEX IF NOT EXISTS`). Ограничение: B v1 — intra-repo.
+Self-hosting safety: изменения идут через `deploy-staging` → `Confirm Deploy`, без внеочередного
+рестарта прода.

docs/architecture/adr/adr-0016-ensure-open-pr-before-merge-verify.md

@@ -0,0 +1,52 @@
+# ADR-0016: ensure_open_pr — гарантированный код-PR перед merge-verify (ORCH-082)
+
+## Статус
+Accepted — амендмент к [adr-0013](adr-0013-merge-verify-gate.md) и
+[adr-0014](adr-0014-merge-verify-sha-source-of-truth.md). Детально:
+`docs/work-items/ORCH-082/06-adr/ADR-001-ensure-open-pr-before-merge-verify.md`.
+
+## Контекст
+Merge-verify (ORCH-071/073) — под-гейт ребра `deploy → done`: детерминированно мержит код-PR в
+`main` (`merge_pr`) и подтверждает merge **только** по «SHA-в-main» (`verify_merged_to_main`,
+ORCH-073). На деплое ORCH-074 (08.06) `merge_pr` вернул `("False", "no open PR")`: у ветки **не
+было** открытого PR с `head==branch` И `base=="main"`. Защита ORCH-073 верно удержала задачу
+(HOLD, не ложный `done`), но это лечило **следствие**.
+
+Первопричина (код-аудит): PR создаётся в конвейере **единственной** функцией
+`launcher._ensure_pr`, вызываемой **только** на developer-пути и **только** при свежем
+worktree-коммите. Любой сценарий без свежего developer-коммита (бойнс без правок, повторный
+прогон, **ручное восстановление ветки/`main`** — случай ORCH-074) оставляет ветку без код-PR.
+Инвариант «к merge-verify у ветки есть открытый код-PR» в конвейере **отсутствовал** → блокер
+автономного деплоя (ORCH-54).
+
+## Решение
+Аддитивно обеспечить инвариант **внутри того же под-гейта**, ПЕРЕД `merge_pr`, не трогая машину
+стадий:
+
+1. **Новый leaf-актор `merge_gate.ensure_open_pr(repo, branch) -> (status, detail)`** (never-raise):
+   `GET …/pulls?state=open` с фильтром **`head.ref==branch` И `base.ref=="main"`** (идентичен
+   `merge_pr`/ORCH-073 FR-3 — авто-docs-PR не считается код-PR) → `("existed", N)`; иначе
+   `POST …/pulls` → `("created", N)`; гонка «PR exists» → повторный GET → `existed` (без дублей);
+   любая ошибка → `("failed", reason)`.
+2. **Врезка в `_handle_merge_verify`** ПОСЛЕ резолва `validated_revision` и ПЕРЕД `merge_pr`:
+   `created|existed` → штатно к `merge_pr`; `failed` → честный HOLD+alert через новый helper
+   `_hold_pr_create_failed` (текст «PR создать не удалось» — отличим от not-merged HOLD), задача
+   остаётся на `deploy`, БЕЗ отката на development.
+3. **Kill-switch `merge_verify_autocreate_pr_enabled`** (дефолт `True`); область —
+   `merge_verify_applies` (self-hosting / `merge_verify_repos`). `False` → поведение ORCH-074 1:1.
+4. **`launcher._ensure_pr`** рекомендуется делегировать в `ensure_open_pr` (единый код создания
+   PR), сохранив прежний триггер «только developer-путь».
+
+## Последствия
+- **Защита ORCH-073 неприкосновенна и приоритетна:** подтверждение merge остаётся ТОЛЬКО
+  `verify_merged_to_main` (SHA-в-main) + `check_main_regression`. Создание PR устраняет лишь
+  **ложный** HOLD «no open PR», но не маскирует реально невлитый код (тот → HOLD как прежде).
+- **Без миграций:** идемпотентность выводится из Gitea (наличие открытого PR), схема БД не меняется
+  — restart-safe; повторный заход (reaper/reconciler/re-approve) → `existed`, дублей нет.
+- **Инварианты целы:** `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, `check_deploy_status`,
+  exit-коды хука, merge-gate (ORCH-043), image-freshness (ORCH-058) — без изменений; `main` не
+  push/force-push; never-raise на всём пути.
+- **Наблюдаемость:** один однозначный исход в логах на проход — created / existed / failed; HOLD по
+  failed текстуально отличим от HOLD not-merged.
+- **Минус:** код-PR может создаваться после прохождения гейтов — безопасно, т.к. гейты валидируют
+  код ветки, а merge-verify идёт ПОСЛЕ всех гейтов; PR — лишь механизм слияния, ревью не обходится.

docs/architecture/adr/adr-0017-serial-gate.md

@@ -0,0 +1,59 @@
+# adr-0017: Per-repo serial gate (пакетный автономный режим, serial e2e)
+
+Статус: **proposed** · Дата: 2026-06-09 · Источник: **ORCH-088** (Этап 1)
+Детально: `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`.
+
+## Контекст
+Цель эпика ORCH-088 — масштаб автономности: накидать вечером 10–20 задач и получить к утру пакет,
+последовательно проведённый через весь конвейер (analysis → … → deploy → done). Корневая проблема —
+**stale-анализ**: ветка задачи N+1 срезается на входе в анализ (`start_pipeline._create_gitea_branch`)
+от `main`, ещё не содержащего код предшественника N. Физическое код-затирание уже закрыто (ORCH-026
+auto_rebase + merge-lease); остаётся **логический** разрыв. Plane API v1 не имеет bulk/relations ⇒
+очередь/зависимости хранятся у оркестратора (gate по локальной БД).
+
+## Решение
+**Per-repo serial gate** — новая задача репо не входит в `analysis` (не режет ветку, не запускает
+analyst), пока в том же репо есть незавершённая задача (`stage != 'done'`) или репо заморожен.
+Три механизма, аддитивно, под kill-switch, с областью репо, never-raise, restart-safe:
+
+1. **Gate-в-claim** (`db.claim_next_job`) — analyst-job (`jobs.agent='analyst'`) применимого репо не
+   выбирается, если `EXISTS` другая незавершённая задача репо ИЛИ активна строка `repo_freeze`. По
+   образцу `task_deps` `NOT EXISTS` (ORCH-026); только локальная БД (offline hot-path). Job'ы уже
+   активной задачи проходят свободно; rework-analyst не блокирует себя (`t2.id != jobs.task_id`).
+2. **Отложенный срез ветки** — для применимого репо `start_pipeline` создаёт task-row + enqueue
+   analyst, но **не** создаёт Gitea-ветку/docs; срез релоцируется на момент claim analyst-job
+   (launcher), когда `origin/main` уже содержит предшественника (`done` ⇔ SHA-в-main, ORCH-071/073).
+   `ensure_worktree` режет от свежего `origin/main` ⇒ AC-6 структурно. Идемпотентно (409 = no-op).
+3. **Durable per-repo freeze** (`repo_freeze`) — post-deploy `DEGRADED`/rollback (ORCH-021) →
+   `set_repo_freeze` + Telegram-алерт; gate закрыт безусловно до **ручного** снятия
+   (`POST /serial-gate/unfreeze`). Деградировавшая задача уже `done` (BR-7) ⇒ нужен отдельный сигнал.
+
+Чистая логика — leaf `src/serial_gate.py` (never-raise). Флаги `serial_gate_enabled` (kill-switch),
+`serial_gate_repos` (CSV; **пусто ⇒ все репо**, в отличие от self-hosting-only ORCH-35/43/58),
+`serial_gate_freeze_enabled`. Наблюдаемость — блок `serial_gate` в `GET /queue`.
+
+## Альтернативы
+- **Гейт в `start_pipeline` + re-trigger при `done`** — больше состояния/путей, риск зависших задач;
+  relocation на claim переиспользует restart-safe `jobs`-очередь.
+- **Freeze как колонка `tasks`** — неверная семантика (freeze per-repo, задача уже `done`).
+- **Self-hosting-only область** — лишает enduro анти-stale-base (FR-3).
+- **Отдельная таблица очереди ожидания** — избыточно; `jobs(queued)`+gate достаточно.
+- **Снятие freeze Plane-жестом** — перегрузка статусов (анти-паттерн ORCH-059).
+
+## Последствия
+- **+** AC-6 закрыт структурно; AC-2/AC-3 «бесплатны» (ожидание = `queued` job без ветки);
+  переиспользование проверенных паттернов; cross-repo параллелизм сохранён; `STAGE_TRANSITIONS` /
+  `QG_CHECKS` / `check_*` / merge-gate / merge-verify / image-freshness / post-deploy / deploy-хук /
+  `max_concurrency` — **без изменений**.
+- **NFR-1:** hot-claim тотальный сбой → **fail-open** (не заклинить очередь всех проектов); freeze в
+  Python-слое → **fail-closed** (безопасность прода).
+- **−** Срез ветки/docs мигрируют из async в sync-путь launcher (обёртка); Blocked-задача держит пакет
+  (Этап 1, осознанно); freeze снимается только вручную.
+- Откат: `serial_gate_enabled=False` ⇒ claim/старт 1:1 как до ORCH-088; таблица `repo_freeze` инертна.
+- **Вне скопа** (Этап 1): merge-очередь FIFO, pre-merge rebase как отдельная фича, фазы A/B/C,
+  любой параллелизм задач внутри одного репо, зависимость от ORCH-83.
+
+## Связи
+- Переиспользует: adr-0002 (очередь ORCH-1), adr-0015 (claim-gate/auto_rebase/merge-lease ORCH-026),
+  adr-0010 (post-deploy monitor — источник DEGRADED), adr-0013/0014 (merge-verify ⇒ `done`⇔SHA-в-main).
+- Новая аддитивная таблица `repo_freeze` (`docs/work-items/ORCH-088/08-data-requirements.md`).

docs/architecture/adr/adr-0018-auto-label-gates.md

@@ -0,0 +1,59 @@
+# ADR-0018: Авто-режим по лейблам — autoApprove / autoDeploy (ORCH-089)
+
+## Статус
+Accepted (реализация — ORCH-089)
+
+## Контекст
+Конвейер имеет два **человеческих** гейта, тормозящих пакетный автономный прогон
+(эпик ORCH-088, «10–20 задач за ночь»):
+1. **BRD** (`analysis`): ждёт ручного Plane-статуса `Approved` → advance на `architecture`.
+2. **Прод-деплой** (`deploy`): Phase A ставит `Awaiting Deploy` и ждёт ручного
+   `Confirm Deploy` (ORCH-059) → Phase B (`initiate_deploy`).
+
+Для доверенных задач оба клика избыточны. Нужно снять **только эти два человеческих
+решения**, выборочно/декларативно (лейбл Plane на задаче), не ослабляя ни одной
+технической проверки.
+
+## Решение
+Аддитивно, по образцу условных под-гейтов (ORCH-035/043/058/059/088): leaf-модуль чистой
+логики `src/labels.py` (never-raise) + точечные врезки + флаги. `STAGE_TRANSITIONS`, реестр
+`QG_CHECKS`, все `check_*`, схема БД — **не трогаются**.
+
+- **`autoApprove`** (лейбл задачи) → в `_handle_analysis_approved_flow` (ветка `files_ok`)
+  после `In Review`+коммента: `set_issue_approved` (индикация) + лог/Telegram/Plane-коммент +
+  `advance_stage(..., finished_agent=None)` — тот же путь, что человеческий Approved
+  (`approved-via-status` → `analysis → architecture` + `mark_brd_review_ended`). Без
+  дублирования переходной логики.
+- **`autoDeploy`** (лейбл задачи) → в `_handle_self_deploy_phase_a` сразу после advance на
+  `deploy` + `clear_state`: лог/Telegram/Plane-коммент + `_handle_self_deploy_phase_b(...)`
+  (idempotency-маркер `INITIATED`, `Deploying`, finalizer). Пропускаются лишь
+  индикативно-человеческие шаги (`Awaiting Deploy` + «ask-human»).
+- **Чтение лейблов** — `plane_sync.fetch_issue_labels` + `get_project_labels` (TTL-кэш,
+  образец `get_project_states`); сопоставление по нормализованному имени; источник истины —
+  Plane API (не payload). Новый сеттер `set_issue_approved` (ключ `approved` уже в states).
+- **Флаги:** `auto_label_enabled` (kill-switch), `auto_approve_label`/`auto_deploy_label`
+  (имена), `auto_label_repos` (CSV; **пусто → self-hosting only**), `auto_label_states_ttl_s`.
+  `applies(repo)` (локальный) проверяется ПЕРВЫМ; `has_label` (сеть) — только если
+  `applies==True` → при выключенном флаге нулевой сетевой оверхед.
+
+## Критические инварианты
+- **Авто-режим снимает ТОЛЬКО человеческое решение**, не ослабляя ни один тех-гейт
+  (CI / staging / security / merge-gate / image-freshness / merge-verify / regression-guard /
+  post-deploy). autoDeploy живёт в точке, где все под-гейты ребра `deploy-staging → deploy`
+  уже зелёные → структурно «никогда не деплоит сломанное».
+- **Fail-safe (never auto):** любая ошибка/недоступность Plane/неоднозначность имени →
+  «нет авто» → ручной гейт (согласовано с fail-closed-практикой ORCH-059). never-raise.
+- **Нулевая регрессия:** без лейблов / `auto_label_enabled=False` / репо вне scope →
+  поведение 1:1 как до ORCH-089 (enduro не затронут).
+- **Идемпотентность:** autoApprove — advance применяется один раз (поздний Approved/F-2
+  видят уже `architecture`); autoDeploy — маркер `INITIATED`.
+
+## Последствия
+**+** минимальная поверхность, единый источник истины перехода, декларативно/обратимо,
+независимые лейблы, безопасный дефолт. **−** Approved-статус транзиентен (durable-аудит —
+лог/Telegram/коммент); 1–2 GET к Plane на гейт применимого репо (TTL-кэш карты лейблов);
+требуется однократно создать лейблы в Plane-проекте ORCH (инфра-предусловие; их отсутствие =
+fail-safe ручной режим).
+
+Детально: `docs/work-items/ORCH-089/06-adr/ADR-001-auto-label-gates.md`,
+`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0019-pipeline-docs-standard.md

@@ -0,0 +1,49 @@
+# adr-0019: Стандарт документов пайплайна (docs/_standards + docs/_templates + ADR-naming)
+
+Статус: **proposed** · Дата: 2026-06-09 · Источник: **ORCH-075** (ORCH-52b, слой 1 эпика ORCH-52)
+Детально: `docs/work-items/ORCH-075/06-adr/ADR-001-pipeline-docs-standard.md`.
+
+## Контекст
+Агенты всех ролей пишут номерные доки work item (`00…17`) «по памяти»; каталогов
+`docs/_standards/` и `docs/_templates/` нет. Следствия: разнобой структуры между задачами; риск
+рассинхрона критичных frontmatter-ключей машинных доков (`verdict:` / `result:` / `deploy_status:` /
+`staging_status:` / `security_status:`), которые читает гейт; отсутствует целостная карта «стадия →
+агент → документ → гейт». Эпик ORCH-52 слоист: слой 1 (52b) фиксирует **договорённость**, машинная
+проверка/валидатор — отдельный слой 52c.
+
+## Решение
+**Документационный стандарт, docs-only, выведенный из фактического кода и эталонных доков:**
+
+1. `docs/_standards/PIPELINE_DOCS.md` — манифест-карта «стадия → документ → владелец-агент →
+   категория (`required`/`when-applicable`/`optional`) → гейт/механизм → frontmatter machine-key».
+   Манифест **документирует** поведение гейтов (источник истины остаётся `src/`), честно различает
+   machine-verdict доки (`12,13,14,15,17`) и информационные (`00,08,10,16`), и помечает под-гейты
+   ребра `deploy-staging→deploy` (security/merge/image-freshness) как врезки в `advance_stage`, а не
+   строки `STAGE_TRANSITIONS`.
+2. `docs/_templates/*` — копируемые скелеты для каждого `required`/`when-applicable` дока; секции
+   выведены из эталонов (ORCH-088/073/089/071), новые не изобретаются; машинные доки несут точный
+   frontmatter-ключ из ground-truth.
+3. **ADR-naming** канонизирован: `docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md` (NNN с
+   `001`); кросс-каттинговые решения дублируются в этот глобальный реестр `adr-NNNN-<slug>.md`.
+
+Подключение — ссылки из `CLAUDE.md` и `docs/architecture/README.md` + запись в `CHANGELOG.md`.
+
+## Альтернативы
+- Сразу валидатор на гейте — отвергнуто (ORCH-52c; нарушил бы docs-only/NFR-1, групповой риск).
+- Манифест как источник истины гейтов — отвергнуто (дубль-истина «манифест ≠ код»).
+- Шаблоны в `docs/work-items/_template/` — отвергнуто (риск для сканеров/гейтов наличия файлов).
+- Ретро-фит истории доков — отвергнуто (вне scope, отдельный риск).
+
+## Последствия
+- **+** Единый golden source структуры доков; меньше ложных падений гейтов из-за неверного
+  frontmatter-ключа; ADR-naming записан; база для ORCH-52c.
+- **+ Нулевой рантайм-риск:** только `docs/**` + `CLAUDE.md` + `CHANGELOG.md`; `STAGE_TRANSITIONS` /
+  `QG_CHECKS` / `check_*` / `src/stage_engine.py` / схема БД — без изменений; полностью обратимо.
+- **−** Манифест — снимок поведения гейтов, дрейфует до ORCH-52c (митигейшн: источник истины — код,
+  reviewer-правило, привязка к именам `check_*`); стандарт описательный, не принуждающий.
+
+## Связи
+- Источник: ORCH-075 (`docs/work-items/ORCH-075/06-adr/ADR-001-pipeline-docs-standard.md`).
+- Документирует (не меняет): adr-0003/0006/0008/0012/0013/0014/0016 (гейты и под-гейты ребра),
+  `STAGE_TRANSITIONS` (`src/stages.py`), `QG_CHECKS` (`src/qg/checks.py`).
+- Downstream: ORCH-52c (frontmatter-валидатор / writer-контракт), ORCH-52d (правка промптов).

docs/architecture/adr/adr-0020-frontmatter-contract.md

@@ -0,0 +1,63 @@
+# adr-0020: Единый frontmatter-контракт + спека handoff (reader/writer/валидатор)
+
+Статус: **Accepted** · Дата: 2026-06-09 · Источник: **ORCH-076** (ORCH-52c)
+Детально: [`docs/work-items/ORCH-076/06-adr/ADR-001-frontmatter-contract.md`](../../work-items/ORCH-076/06-adr/ADR-001-frontmatter-contract.md)
+
+## Контекст
+
+Слой 1 эпика ORCH-52 (ORCH-075/52b) дал **описательный** стандарт документов
+(`docs/_standards/PIPELINE_DOCS.md`), явно отложив машинную проверку на ORCH-52c. В коде:
+`src/frontmatter.py` — только single-key reader (never-raise), а ~10-строчный блок парсинга
+YAML-frontmatter **продублирован** в 5 вердикт-парсерах (`check_reviewer_verdict`,
+`_parse_tests_verdict`, `_parse_deploy_status`, `_parse_staging_status`, `parse_security_status`)
++ в `_strip_frontmatter`/`extract_security_findings`. Единого контракта чтения, writer'а, схемы
+и формальной спеки handoff — нет. Эти парсеры читают вердикты **на гейтах self-hosting**
+инструмента, обслуживающего прод других проектов из общего инстанса → любой регресс = стоп
+конвейера всех проектов.
+
+## Решение
+
+1. **`src/frontmatter.py` → полный frontmatter-контракт** (функции в существующем leaf-модуле,
+   контракт **never-raise**): сохранённый `read_frontmatter_value` (без изменений) + единый
+   парс-примитив `parse_frontmatter(content) -> FrontmatterParse` (единственная точка
+   YAML-логики, структура различает no-block / malformed / yaml-error / data) + `render_/
+   write_frontmatter` (writer) + `validate_schema` (обязательная схема
+   `work_item, stage, author_agent, status, created_at, model_used`) + `strip_frontmatter`.
+2. **Унифицируется механизм парсинга, НЕ семантика.** Все 5 вердикт-парсеров читают YAML через
+   `parse_frontmatter`; token-наборы, upper-casing, приоритет негативного токена, 3-полевой
+   контракт tester'а (ORCH-047), fallback `worktree→origin/main` — **1:1**. Сигнатуры и
+   `tuple[bool, str]` — неизменны. Reason-строки переносятся дословно.
+3. **Валидатор не hard-fail по умолчанию.** Флаг `frontmatter_validation_strict` (env
+   `ORCH_FRONTMATTER_VALIDATION_STRICT`, дефолт `False`): default — warning/лог, **вне
+   вердикт-пути гейтов** (нулевая регрессия); hard-fail — зарезервированный strict-режим
+   (включение — с ORCH-52d). Иначе ORCH-52c заблокировала бы собственный деплой.
+4. **Формальная спека handoff** `docs/_standards/HANDOFF_PROTOCOL.md` — «стадия → обязательный
+   выход» (документы + frontmatter-ключи), согласована 1:1 с `PIPELINE_DOCS.md` §2–§3; источник
+   истины — код. `PIPELINE_DOCS.md` обновляется ссылкой + отметкой о реализации машинного слоя.
+5. **Без изменений** `STAGE_TRANSITIONS`, состава `QG_CHECKS`, API, схемы БД.
+
+## Альтернативы
+
+- Общий «умный» verdict-резолвер (поле+токены для всех гейтов) — отклонён: различия token-логики
+  → риск тонкого регресса на гейте при self-hosting. Унифицируем только парс YAML.
+- Класс/новый пакет — отклонён: состояния нет, лишний blast radius.
+- Hard-fail валидатор по умолчанию — отклонён (NFR-3: self-block собственного деплоя).
+- Сторонняя `python-frontmatter` — отклонена: лишняя зависимость ради ~30 строк.
+
+## Последствия
+
+- **+** Конец дублирования/рассинхрона парсинга; writer+валидатор+схема готовы к ORCH-52d;
+  спека handoff закрывает пробел контракта стадий.
+- **+** Нулевая регрессия по построению: семантика и reason-строки 1:1, валидатор инертен при
+  дефолте, never-raise сохранён, enduro 1:1.
+- **−** Унификация частичная (парс, не семантика); strict-режим «спящий» до ORCH-52d.
+- **Обратимость:** `frontmatter_validation_strict=False` ⇒ прежнее поведение; перевод гейтов
+  поведенчески инвариантен.
+- **Риск:** первый боевой `autoDeploy` орка (ORCH-089) — наблюдение за стадией `deploy`
+  (`docs/work-items/ORCH-076/10-tech-risks.md`).
+
+## Связи
+
+- Опирается: adr-0019 (pipeline-docs-standard, ORCH-075), ORCH-016 (reader), ORCH-047
+  (3-полевой tester), adr-0012 (security-гейт), adr-0018 (auto-label/`autoDeploy`).
+- Готовит: ORCH-52d (эмиссия полной схемы агентами; возможное включение strict).

docs/architecture/adr/adr-0021-prompt-canon-anthropic.md

@@ -0,0 +1,84 @@
+# adr-0021: Канон Anthropic для системных промптов агентов + эмиссия frontmatter-схемы 52c
+
+- **Статус:** proposed
+- **Дата:** 2026-06-09
+- **Источник:** ORCH-077 (эпик ORCH-52, слой 52d — замыкающий)
+- **Связи:** реализует слой промптов к adr-0019 (52b, PIPELINE_DOCS) и adr-0020 (52c,
+  frontmatter-контракт). Детально — `docs/work-items/ORCH-077/06-adr/ADR-001-anthropic-prompt-canon.md`.
+
+## Контекст
+
+Эпик ORCH-52 строит сквозной контракт документации конвейера: **52b** (adr-0019) — описательный
+стандарт документов + скелеты `docs/_templates/`; **52c** (adr-0020) — машинный контракт
+`src/frontmatter.py` (reader/writer/валидатор `REQUIRED_FIELDS`) + спека `HANDOFF_PROTOCOL.md` с
+обязательной 6-польной схемой `(work_item, stage, author_agent, status, created_at, model_used)`.
+
+Две незакрытые проблемы:
+1. **Цепочка 52b→52c→52d разорвана.** Writer и валидатор схемы есть, но работают warning-only
+   (`frontmatter_validation_strict=False`); агенты **не эмитят** поля схемы — на входе валидатора нет
+   данных, петля не замкнута.
+2. **Форма 6 промптов `.openclaw/agents/*.md` разнородна** (RU/EN, свободная структура) → снижает
+   предсказуемость агентов прода, которые исполняются на КАЖДОЙ задаче ВСЕХ проектов из общего
+   инстанса (self-hosting).
+
+Факт загрузки (сверено `src/agents/launcher.py`): промпт `cat`-ается из git-worktree агента в момент
+запуска (`--system-prompt "$(cat .openclaw/agents/<role>.md)"`), НЕ запекается в образ.
+
+## Решение
+
+Ввести **обязательный канон формы** для всех агент-промптов и сделать его машинно-проверяемым.
+
+1. **Фиксированный XML-скелет (5 обязательных секций, нормативный порядок):**
+   `<context>` → `<task>` (+ опц. `<thinking>`) → `<deliverables>` → `<constraints>` →
+   `<output_format>`. Доп. секции (`<success_criteria>`, `<escalation>`) — после. Контекст/роль
+   вперёд, формат вывода последним (recency для следования схеме).
+2. **Аддитивная эмиссия схемы 52c.** `<output_format>` каждого промпта перечисляет 6 полей схемы с
+   роле-специфичными значениями и инструктирует ставить их **рядом** с существующим machine-verdict
+   ключом, **не меняя его имя/регистр/значения** (`verdict:`, `result:`, `staging_status:`,
+   `deploy_status:`, `security_status:` — байт-в-байт). Для `04-test-plan.yaml` (чистый YAML) — как
+   top-level ключи. Гейты читают вердикты как раньше (схема в boolean-вердикте не участвует).
+3. **Few-shot + позитивные альтернативы.** Ссылки на `docs/_templates/` и эталоны (ORCH-073/088);
+   каждый запрет в формате «❌ X → ✅ Y».
+4. **CoT/thinking** у решающих ролей (architect/reviewer/tester/deployer).
+5. **Анти-регресс машинно.** Структурные тесты `tests/test_agent_prompts_canon.py` (без запуска
+   агентов): 5 секций, 6 полей схемы, точный регистр machine-verdict ключей, ключевые
+   self-hosting-маркеры (deployer: `docker exec orchestrator-staging`, `pr_already_merged`,
+   «не рестартить 8500»). `test_agent_frontmatter_no_model.py` остаётся зелёным.
+6. **Enforcement не включается.** `frontmatter_validation_strict` остаётся `False` (warning-only);
+   52d учит эмитить добровольно. Hard-fail — отдельная будущая задача.
+
+**Границы:** docs/prompts-only. `src/**` (config, launcher, frontmatter, stages, qg/checks,
+stage_engine), `STAGE_TRANSITIONS`, `QG_CHECKS`, состав machine-verdict ключей, схема БД, `tools:`-блок
+промптов — **не трогаются**.
+
+**Норматив на будущее:** любая новая правка/добавление агент-промпта следует этому канону (5 секций +
+аддитивная схема + ❌→✅). Отступление требует нового ADR.
+
+## Альтернативы
+
+- **Сразу включить hard-fail схемы.** Отвергнуто: правка `src/config.py` вне scope; для self-hosting
+  рискованно (забытое поле валит гейт всех проектов). Сначала эмиссия, enforcement — позже.
+- **Канон как рекомендация, не норма.** Отвергнуто: теряется машинная проверяемость, эпик требует
+  контракт.
+- **Запечь промпты в образ.** Отвергнуто: противоречит loading-model (cat из worktree), добавило бы
+  прод-рестарт-зависимость.
+
+## Последствия
+
+- **+** Петля 52 замкнута: схема наполняется реальными данными на каждой стадии всех проектов.
+- **+** Единый предсказуемый канон; правки промптов вступают в силу **без прод-рестарта** (следующий
+  worktree от `main`) → нулевой self-hosting-риск выкатки.
+- **+** Естественный in-vivo A/B: reviewer/tester задачи исполняются под новыми промптами в той же
+  ветке (метод BR-6).
+- **−** Рост объёма промптов (митигейшн: ссылки вместо инлайна, контроль объёма).
+- **−** Риск регресса инструкции (митигейшн: построчная карта + структурные тесты + приоритетный
+  review deployer/reviewer).
+- **Откат:** `git revert` PR — свободная форма возвращается, эмиссия прекращается, гейты идентичны.
+
+## Связи
+- Реализует: adr-0019 (52b), adr-0020 (52c).
+- Per-work-item: `docs/work-items/ORCH-077/06-adr/ADR-001-anthropic-prompt-canon.md`.
+- Стандарты: `docs/_standards/PIPELINE_DOCS.md`, `docs/_standards/HANDOFF_PROTOCOL.md`,
+  `src/frontmatter.py::REQUIRED_FIELDS`.
+- Сверено по коду: `src/agents/launcher.py`, `Dockerfile`,
+  `src/config.py::frontmatter_validation_strict`, `tests/test_agent_frontmatter_no_model.py`.

docs/architecture/adr/adr-0022-traceability-marker-standard.md

@@ -0,0 +1,106 @@
+---
+work_item: ORCH-078
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0022: Стандарт маркеров-трассировки `ORCH-NNN` + правило чтения ADR перед правкой
+
+- **Статус:** proposed
+- **Дата:** 2026-06-09
+- **Источник:** ORCH-078 (эпик ORCH-52, слой 52e — трассировка, слой 4)
+- **Связи:** продолжает цепочку стандартов эпика 52 — adr-0019 (52b, `PIPELINE_DOCS.md`),
+  adr-0020 (52c, frontmatter-контракт), adr-0021 (52d, канон промптов). Детально —
+  `docs/work-items/ORCH-078/06-adr/ADR-001-traceability-marker-standard.md`.
+
+## Контекст
+
+Эпик ORCH-52 строит сквозной контракт документации конвейера: **52b** (adr-0019) — описательный
+стандарт документов + скелеты; **52c** (adr-0020) — машинный frontmatter-контракт + `HANDOFF_PROTOCOL.md`;
+**52d** (adr-0021) — 6 промптов в каноне Anthropic + добровольная эмиссия 52c-схемы. Закрыты слои
+структуры (52b), машинного вердикта (52c) и формы промптов (52d), но **слой трассировки кода к
+решениям не формализован**.
+
+Факты, сверенные с кодом `main`:
+- В `src/` живёт **51 уникальный** маркер `ORCH-NNN` (`grep -rhoE 'ORCH-[0-9]+' src/ | sort -u | wc -l`),
+  привязывающий нетривиальные инварианты к породившему их work item — **сложившаяся практика без
+  формального стандарта** (`docs/_standards/` несёт лишь `PIPELINE_DOCS.md`/`HANDOFF_PROTOCOL.md`).
+- Высокая плотность: `config.py`=63, `stage_engine.py`=55, `agents/launcher.py`=50, `plane_sync.py`=48,
+  `merge_gate.py`=26 вхождений.
+
+Три незакрытые проблемы:
+1. **Нет правила чтения.** Агент, правя маркированную строку, не обязан прочитать ADR, который её
+   ввёл → риск молча сломать инвариант. Это класс «фантомного merge»
+   (`docs/history/LESSONS_2026-06-08_phantom-merge.md`), породившего ORCH-071/073.
+2. **Reviewer не контролирует соблюдение** — ось «Соответствие ADR» проверяет ADR текущей задачи, не
+   сверку правки чужого маркированного кода с его ADR.
+3. **Анти-археология** — блок с 50+ маркерами = раскопки по 4+ work item.
+
+## Решение
+
+Ввести **нормативный стандарт маркеров-трассировки** `docs/_standards/TRACEABILITY.md` (слой 4 эпика
+52) и точечно дополнить промпты правилом чтения / контролем соблюдения **со ссылкой на единый
+источник**. Это **docs + prompts-only**, нулевое касание кода; стандарт — описательно-нормативный
+документ + анти-регресс-тест промптов, **не машинный гейт конвейера**.
+
+1. **`TRACEABILITY.md`** кодифицирует существующий контракт (не вводит новый синтаксис): определение
+   маркера, формат (inline-комментарий, рекомендуется ссылка на решение), правило размещения (рядом с
+   нетривиальным инвариантом), чтение истории **с реальным проверяемым примером**
+   (`src/serial_gate.py` → ORCH-088 → `ADR-001-serial-gate.md`), fallback-доступ, анти-археология,
+   каноничный текст правила чтения.
+2. **Единый источник истины правила.** Каноничная формулировка живёт только в `TRACEABILITY.md`;
+   промпты несут короткую врезку-**ссылку**, не копию → нет дрейфа между файлами (анти-дубль 52d).
+3. **Точечные врезки (аддитивно, 52d-канон не переписывается):** `developer.md` — правило чтения +
+   fallback-доступ («❌ X → ✅ Y»); `architect.md` — правило чтения + анти-археология; `reviewer.md` —
+   усиление оси «Соответствие ADR» под-пунктом «правка маркированного кода сверена с его ADR; слом →
+   finding ≥P1».
+4. **Анти-археология:** блок с **≥3** маркерами → одна сводная ссылка на сквозной ADR
+   (`docs/architecture/adr/`) вместо перечисления всех work item. Пример: `src/merge_gate.py` →
+   `adr-0006/0013/0014/0016`.
+5. **Fallback-доступ:** `git show origin/main:docs/work-items/ORCH-NNN/06-adr/ADR-001-<slug>.md` —
+   когда папки нет в текущей ветке.
+6. **Анти-регресс машинно:** расширение `tests/test_agent_prompts_canon.py` (tests-only) — утверждает
+   присутствие reading-rule/`TRACEABILITY`-маркеров; существующие проверки 52d и
+   `test_agent_frontmatter_no_model.py` остаются зелёными.
+
+**Границы:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, `_parse_*`, `src/frontmatter.py`,
+схема БД — **не трогаются**. `frontmatter_validation_strict` остаётся `False`; новый QG не вводится.
+Массовый ретро-фит 51 существующего маркера **вне объёма** — стандарт действует «на будущее».
+
+**Норматив на будущее:** новый/правимый значимый инвариант → ставь маркер своей задачи рядом; блок с
+3+ маркерами → сводный сквозной ADR; правка чужого маркера → читай его `06-adr` до изменения.
+
+## Альтернативы
+
+- **Машинный гейт/CI-lint маркеров.** Отвергнуто: правка `src/`/CI вне scope; для self-hosting
+  рискованно (ложный fail валит конвейер всех проектов); премэйчур до описательного стандарта.
+  Enforcement — потенциальная будущая задача (как hard-fail схемы в adr-0021).
+- **Массовый ретро-фит 51 маркера.** Отвергнуто: огромный диф, риск регресса смысла, вне объёма.
+- **Копировать правило в каждый промпт.** Отвергнуто: дрейф между файлами, нарушение анти-дубль.
+- **Только per-work-item ADR без глобального.** Отвергнуто: рвёт цепочку эпика 52 (52b/c/d имеют
+  глобальный ADR); нет точки входа для будущих агентов.
+
+## Последствия
+
+- **+** Замкнут слой 4 эпика 52: практика маркеров формализована, правило чтения защищает от слома
+  инвариантов; reviewer получает ось контроля.
+- **+** Единый источник правила → нет дрейфа; обновление в одном файле.
+- **+** Self-hosting без рестарта: промпт `cat`-ается из worktree → правило действует на следующем
+  worktree от `main` без рестарта 8500.
+- **+** Полная обратимость: чисто текстовое изменение, нет миграций/состояния/kill-switch.
+- **−** Рост объёма 3 промптов (митигейшн: короткие врезки-ссылки).
+- **−** Стандарт нормативен, но не enforced машинно → соблюдение на дисциплине + ревью (осознанный
+  компромисс).
+- **Откат:** `git revert` PR — стандарт удаляется, врезки исчезают, поведение кода/гейтов идентично.
+
+## Связи
+- Продолжает: adr-0019 (52b), adr-0020 (52c), adr-0021 (52d).
+- Per-work-item: `docs/work-items/ORCH-078/06-adr/ADR-001-traceability-marker-standard.md`.
+- Стандарты-соседи: `docs/_standards/PIPELINE_DOCS.md`, `docs/_standards/HANDOFF_PROTOCOL.md`,
+  будущий `docs/_standards/TRACEABILITY.md` (создаёт стадия development).
+- Сверено по коду: `src/serial_gate.py:241,269` (ORCH-088), `src/merge_gate.py` (26 маркеров),
+  `tests/test_agent_prompts_canon.py`, `.openclaw/agents/{developer,architect,reviewer}.md`.
+- Прецедент класса ошибки: `docs/history/LESSONS_2026-06-08_phantom-merge.md`.

docs/architecture/adr/adr-0023-overview-docs-reviewer-axis-and-epic52-close.md

@@ -0,0 +1,98 @@
+---
+work_item: ORCH-079
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0023: Reviewer-ось «обзорные доки» (README-ограничения) + закрытие эпика ORCH-52
+
+- **Статус:** proposed
+- **Дата:** 2026-06-09
+- **Источник:** ORCH-079 (эпик ORCH-52, слой 52f — обзорные доки, слой 5/финал)
+- **Связи:** замыкает цепочку стандартов эпика 52 — adr-0019 (52b, `PIPELINE_DOCS.md`),
+  adr-0020 (52c, frontmatter-контракт), adr-0021 (52d, канон промптов), adr-0022 (52e,
+  трассировка маркеров). Детально — `docs/work-items/ORCH-079/06-adr/ADR-001-readme-sync-and-reviewer-overview-docs-axis.md`.
+
+## Контекст
+
+Эпик ORCH-52 строит сквозной контракт «документация = golden source наравне с кодом» слоями:
+**52b** (adr-0019) — описательный стандарт документов + скелеты; **52c** (adr-0020) — машинный
+frontmatter-контракт + `HANDOFF_PROTOCOL.md`; **52d** (adr-0021) — 6 промптов в каноне Anthropic +
+добровольная эмиссия 52c-схемы; **52e** (adr-0022) — стандарт трассировки маркеров + reviewer-ось
+«соответствие ADR». Закрыты слои структуры, машинного вердикта, формы промптов и трассировки кода —
+но **обзорная витрина проекта (корневой `README.md`) не охвачена**.
+
+Факты, сверенные с кодом `main`:
+- Секция `README.md` «Известные ограничения» (`:236–241`) имеет битую нумерацию (`1,2,3,4,3,4`) и
+  **выдаёт решённое за открытое**: worktree-гонки (закрыто `ensure_worktree` + ORCH-026/088),
+  in-process daemon (закрыто очередью ORCH-1), «Gitea CI не настроен» (опровергнуто `check_ci_green`,
+  `src/qg/checks.py:82`), «no retry» (опровергнуто backoff/breaker в `queue_worker.py`), плюс
+  устаревшие issue-ID (зрелый `plane_sync` ORCH-010/066/068) и Playwright-timeout (неприменим к
+  pytest-сервису; реальный механизм — watchdog ORCH-7).
+- **Процессный пробел:** reviewer (ось «Документация») проверяет обновление *конвейерных* доков, но
+  **обзорные** разделы (README «Известные ограничения») в правиле не названы → витрина копит
+  рассинхрон, т.к. закрытие ограничения не обязывает автора снять пункт.
+
+## Решение
+
+Закрыть слой 5 (финал) эпика 52: **синхронизировать обзорные доки с кодом по факту** и добавить
+reviewer'у **нормативную под-ось «обзорные доки»** (по образцу оси трассировки 52e). Это **docs +
+prompt-only**, нулевое касание кода; правило — описательно-нормативное, **не машинный гейт**.
+
+1. **Reviewer-ось «обзорные доки» (cross-cutting).** В `.openclaw/agents/reviewer.md` ось 4
+   «Документация» + `<constraints>` несут точечную врезку «❌→✅»: *PR закрыл пункт README «Известные
+   ограничения», README не обновлён → finding*. Severity **≥ P1**; при закрытии ограничения правкой
+   `src/` без обновления README — совпадает с существующим **P0** «`src/` изменён, доки не обновлены».
+   Канон 52d (5 секций, формат запретов, `<thinking>`), 6 полей схемы 52c и ключ
+   `verdict: APPROVED|REQUEST_CHANGES` — байт-в-байт.
+2. **Витрина приведена к коду (NFR-3).** Все 6 устаревших пунктов сняты/перенесены в «Закрыто
+   (история)» с ORCH-ссылками; в «открытых» остаются ТОЛЬКО реально открытые, верифицированные
+   кодом/задачей; нумерация сквозная. Запрет на изобретение ограничений (только уже
+   задокументированные known-limitations — анти-scope-creep).
+3. **Точечная сверка** `README.md` / `docs/architecture/README.md` с `src/` (стадии/`QG_CHECKS`/
+   модели-эффорты/компоненты), минимально инвазивно.
+4. **Анти-регресс машинно:** расширение `tests/test_agent_prompts_canon.py` (tests-only) — assert
+   присутствия оси обзорных доков; проверки 52d и `test_agent_frontmatter_no_model.py` зелёные.
+
+**Границы:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, `_parse_*`, `src/frontmatter.py`,
+схема БД — **не трогаются**. `frontmatter_validation_strict` остаётся `False`; новый QG не вводится.
+
+### Эпик ORCH-52 — закрыт (карта слоёв)
+
+| Слой | Задача | Глобальный ADR | Артефакт |
+|------|--------|----------------|----------|
+| 52b — структура доков | ORCH-075 | adr-0019 | `docs/_standards/PIPELINE_DOCS.md` + `_templates/` |
+| 52c — машинный frontmatter | ORCH-076 | adr-0020 | `src/frontmatter.py` + `HANDOFF_PROTOCOL.md` |
+| 52d — канон промптов | ORCH-077 | adr-0021 | 6 промптов `.openclaw/agents/*.md` |
+| 52e — трассировка маркеров | ORCH-078 | adr-0022 | `docs/_standards/TRACEABILITY.md` |
+| **52f — обзорные доки** (финал) | **ORCH-079** | **adr-0023** | `README.md` + reviewer-ось |
+
+## Альтернативы
+- **Машинный enforcement (новый QG «README актуален»).** Отвергнуто: вне scope; для self-hosting
+  ложный fail валит конвейер всех проектов; правило остаётся нормативным, как 52e. Enforcement —
+  возможная будущая задача (как hard-fail схемы 52c).
+- **Отдельный `docs/_standards/` для правила обзорных доков.** Отвергнуто: одно правило, один
+  артефакт (README) — врезки в промпт достаточно; новый стандарт-файл избыточен.
+- **Только per-work-item ADR.** Отвергнуто: рвёт цепочку эпика 52 (52b–e имеют глобальный ADR); нет
+  явной точки «эпик 52 закрыт».
+
+## Последствия
+- **+** Витрина проекта честна; самоподдерживающаяся синхронность (reviewer-ось).
+- **+** Эпик 52 формально закрыт сквозным ADR — единая точка входа для будущих агентов.
+- **+** Self-hosting без рестарта: промпт `cat`-ается из worktree → правило с следующего worktree
+  от `main` без рестарта 8500.
+- **+** Полная обратимость: чисто текстовое изменение, нет миграций/состояния/kill-switch.
+- **−** Правило нормативно, не enforced машинно → дисциплина + ревью (осознанный компромисс).
+- **−** Рост `reviewer.md` на короткую врезку (митигейшн: точечность, без переписывания).
+- **Откат:** `git revert` PR — доки/промпт/тест откатываются, поведение кода/гейтов идентично.
+
+## Связи
+- Замыкает: adr-0019 (52b), adr-0020 (52c), adr-0021 (52d), adr-0022 (52e).
+- Per-work-item: `docs/work-items/ORCH-079/06-adr/ADR-001-readme-sync-and-reviewer-overview-docs-axis.md`.
+- Сверено по коду: `src/agents/launcher.py` (`ensure_worktree`, `_resolve_timeout`),
+  `src/queue_worker.py` (backoff/breaker), `src/qg/checks.py:82,381`, `src/plane_sync.py:451,541`,
+  `README.md:236–241`, `.openclaw/agents/reviewer.md`, `tests/test_agent_prompts_canon.py`.
+</content>

docs/architecture/adr/adr-0024-disk-watchdog.md

@@ -0,0 +1,59 @@
+---
+work_item: ORCH-063
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0024: Disk-watchdog — фоновый heartbeat-демон мониторинга заполнения хост-ФС
+
+> Сквозной (cross-cutting) ADR: вводит **новый фоновый компонент** оркестратора в ряду
+> `reconciler` (adr-0007) и `job_reaper` (adr-0011). Детальное решение задачи —
+> `docs/work-items/ORCH-063/06-adr/ADR-001-disk-watchdog.md`.
+
+## Статус
+Proposed (ORCH-063)
+
+## Контекст
+07.06.2026 диск хоста mva154 тихо дорос до 100% и положил **весь self-hosting-конвейер** (один
+прод-инстанс `orchestrator` обслуживает все прод-проекты из общей БД/очереди). Проактивного сигнала
+о заполнении диска у системы не было. Оркестратор уже имеет два проверенных фоновых daemon-потока с
+единым каркасом (`threading.Thread(daemon=True)` + `threading.Event`, `start/stop/status`,
+never-raise, снимок в `GET /queue`): `reconciler` (ORCH-053) и `job_reaper` (ORCH-065). Новый
+эксплуатационный watchdog логично встроить тем же паттерном.
+
+## Решение
+Вводится третий фоновый компонент **disk-watchdog** (`src/disk_watchdog.py`):
+- **Калька каркаса** `reconciler`/`reaper`: daemon-поток, чистый stop через `_stop.wait(interval)`,
+  контракт `start()`/`stop(timeout)`/`status()`, старт/стоп в `main.lifespan` (старт последним —
+  после `reaper.start()`; стоп первым в reverse-порядке), наблюдаемость — аддитивный блок
+  `disk_monitor` в `GET /queue`.
+- **Замер** заполнения **хост-ФС** через смонтированные bind-пути (`/repos`, `/app/data`) stdlib
+  `shutil.disk_usage` (не overlay `/` контейнера, не субпроцесс `df`); дедуп путей по `st_dev`.
+- **Решение об алерте** — pure-функция от `(used_pct, threshold, prev_state, now, realert_s)`:
+  алерт на пересечении порога (дефолт 85%), ограниченный cooldown-повтор, recovery при возврате
+  ниже порога. Состояние анти-спама — in-memory (без миграции БД).
+- **Алерт** — `send_telegram` (notifying), best-effort. Kill-switch `disk_monitor_enabled`.
+- **Только сигнал, не лечение:** watchdog читает и уведомляет, не трогает диск/контейнер, не
+  рестартит прод (self-hosting безопасность). Авто-очистка диска — отдельная задача.
+
+**Инварианты:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`, схема БД — **не меняются**
+(watchdog — эксплуатационный демон, не Quality Gate, как `reconciler`/`reaper`). never-raise на
+уровнях per-path / per-tick / per-send. При выключенном kill-switch — поведение 1:1 как сейчас
+(нулевая регрессия для enduro-trails).
+
+## Последствия
+- **+** Ранний сигнал предотвращает групповой простой всех проектов; дёшево, без внешних
+  зависимостей (принцип «всё в Docker на одном сервере, минимум зависимостей»).
+- **+** Знакомый паттерн фонового демона → низкий риск, простое сопровождение.
+- **−** In-memory состояние / best-effort Telegram — допустимы для раннего сигнала (не SLA).
+- **Откат:** `ORCH_DISK_MONITOR_ENABLED=false`; миграций БД нет.
+
+## Ссылки
+- Задачный ADR: `docs/work-items/ORCH-063/06-adr/ADR-001-disk-watchdog.md`
+- Родственные компоненты: [adr-0007-reconciler.md](adr-0007-reconciler.md),
+  [adr-0011-job-reaper-lease-reclaim.md](adr-0011-job-reaper-lease-reclaim.md)
+- Топология host-разделов: `docs/operations/INFRA.md`
+</content>

docs/architecture/adr/adr-0025-build-cache-pruner.md

@@ -0,0 +1,86 @@
+---
+work_item: ORCH-062
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0025: Build-cache-pruner — фоновый heartbeat-демон авто-уборки docker build cache на хосте
+
+> Сквозной (cross-cutting) ADR: вводит **новый фоновый компонент** оркестратора в ряду
+> `reconciler` (adr-0007), `job_reaper` (adr-0011) и `disk_watchdog` (adr-0024). Детальное
+> решение задачи — `docs/work-items/ORCH-062/06-adr/ADR-001-build-cache-pruner.md`.
+
+## Статус
+Proposed (ORCH-062)
+
+## Контекст
+
+07.06.2026 диск хоста mva154 тихо дорос до 100% и положил **весь self-hosting-конвейер всех
+проектов** (один прод-инстанс `orchestrator` на общей БД/очереди). Доминирующий «пожиратель» —
+**docker build cache** (≈11 ГБ от частых пересборок прод/staging-образов). `disk_watchdog`
+(adr-0024, ORCH-063) ввёл **сигнал** о заполнении (Telegram ≥85%) и явно отложил авто-очистку в
+отдельную задачу. ORCH-062 — эта задача: **автоматическое освобождение build cache**, чтобы
+инцидент не повторялся без оператора.
+
+Сверено по коду: контейнер `orchestrator` **не содержит docker CLI** (`Dockerfile:11` — только
+`openssh-client git curl`); host-docker-операции приложение уже делает **через ssh на хост**
+(`image_freshness.image_revision`, `self_deploy` Phase B), канал `deploy_ssh_user@deploy_ssh_host`
+настроен. У оркестратора три проверенных фоновых daemon-потока с единым каркасом.
+
+## Решение
+
+Вводится четвёртый фоновый компонент **build-cache-pruner** (`src/build_cache_pruner.py`):
+- **Калька каркаса** `disk_watchdog`/`reconciler`/`reaper`: daemon-поток, чистый стоп через
+  `_stop.wait(interval)`, контракт `start()`/`stop(timeout)`/`status()`, старт/стоп в
+  `main.lifespan` (старт последним — после `disk_watchdog.start()`; стоп первым в reverse),
+  наблюдаемость — аддитивный блок `build_cache_prune` в `GET /queue`. Leaf-модуль (без обратных
+  зависимостей на `stage_engine`/`stages`/`qg`).
+- **Уборка — строго `docker builder prune -f --filter until=<until>`** (BuildKit GC, дефолт
+  `until=24h`): удаляется только старый build cache, тёплый ≤24ч сохраняется. `-a` — опционально и
+  только в паре с возрастным фильтром. **Запрещены** `docker image prune`/`system prune`/удаление
+  образов запущенных сервисов/остановка-рестарт контейнеров.
+- **Исполнение на хосте через ssh** (CLI в контейнере нет): `ssh deploy_ssh_user@deploy_ssh_host
+  "docker builder prune …"`, bounded таймаутом. **Нет ssh-таргета → тик no-op** → фича
+  естественно скоупится на self-hosting-прод.
+- **Конфиг/kill-switch** (`ORCH_BUILD_CACHE_PRUNE_*`, дефолты безопасные): `enabled` (дефолт
+  `true`), `interval_s` (6ч), `until` (`24h`), `all` (`false`), `timeout_s`, `notify_min_gb`.
+  Валидаторы по образцу `disk_monitor_*` (невалид → лог + дефолт).
+- **Сигнал + лечение как пара:** disk_watchdog сигналит о росте диска, build-cache-pruner убирает
+  доминирующего «пожирателя» — две половины одной операционной защиты.
+
+**Инварианты:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`, `src/stage_engine.py`, схема БД
+— **не меняются** (pruner — эксплуатационный демон, не Quality Gate, как watchdog/reaper). Без
+миграции БД (учёт результата in-memory, best-effort). never-raise per-команда/per-tick. Уборка
+**никогда** не рестартит docker daemon/прод-контейнер (self-hosting безопасность; рестарт-путь —
+отвергнутый Вариант B). При выключенном kill-switch — поведение 1:1 как сейчас (нулевая регрессия
+для enduro-trails).
+
+## Альтернативы
+- **host `daemon.json builder.gc.defaultKeepStorage`** — отвергнуто: требует рестарта docker
+  daemon (останавливает ВСЕ контейнеры хоста = групповой self-hosting риск); политика по объёму,
+  не по возрасту; не наблюдаемо в `GET /queue`.
+- **host-cron** — отвергнуто как основное (оставлено ручным fallback): off-git невидимая инфра,
+  без `/queue`-наблюдаемости, без config-kill-switch, не тестируется.
+- **raw-HTTP по docker.sock / docker CLI в образе** — отвергнуто: лишний код / раздувание образа
+  против уже существующего ssh-канала.
+
+## Последствия
+- **+** Корень инцидента 07.06 устраняется автоматически; тёплый кэш сохранён; без новых
+  зависимостей и без рестарта docker/прода (принцип «всё в Docker, минимум зависимостей»).
+- **+** Знакомый паттерн фонового демона → низкий риск, наблюдаемость, обратимость, тестируемость.
+- **−** Зависимость от ssh на хост (как `image_freshness`/`self_deploy`); нет таргета → no-op
+  (наблюдаемо), фича не работает, но ничего не ломает.
+- **Откат:** `ORCH_BUILD_CACHE_PRUNE_ENABLED=false`; миграций БД нет.
+
+## Ссылки
+- Задачный ADR: `docs/work-items/ORCH-062/06-adr/ADR-001-build-cache-pruner.md`
+- Инфра/риски: `docs/work-items/ORCH-062/07-infra-requirements.md`,
+  `docs/work-items/ORCH-062/10-tech-risks.md`
+- Комплемент: [adr-0024-disk-watchdog.md](adr-0024-disk-watchdog.md) (ORCH-063 — сигнал)
+- Родственные компоненты: [adr-0007-reconciler.md](adr-0007-reconciler.md),
+  [adr-0011-job-reaper-lease-reclaim.md](adr-0011-job-reaper-lease-reclaim.md)
+- Топология host / env-карта: `docs/operations/INFRA.md`
+</content>

docs/architecture/adr/adr-0026-stop-cancel-task.md

@@ -0,0 +1,106 @@
+---
+work_item: ORCH-090
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# ADR-0026: Системное терминальное состояние `cancelled` — STOP-отмена задачи
+
+Сквозной (cross-cutting) ADR. Детальное решение задачи —
+`docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`.
+
+## Статус
+Proposed
+
+## Контекст
+
+ORCH-090 вводит Plane-статус **STOP** — единый декларативный механизм отмены задачи (остановка
+агента + полный сброс прогресса). Самое́ кросс-каттинговое следствие — появление **нового
+системного терминального состояния `cancelled`** (стадия `tasks.stage='cancelled'` + терминальный
+job-статус `jobs.status='cancelled'`). До ORCH-090 «терминальность задачи» в горячем планировщике
+была захардкожена как **`stage == 'done'`** (единственный сток в `STAGE_TRANSITIONS`), и это
+определение разъехалось между подсистемами:
+
+- `src/reconciler.py` **уже** трактует `stage in ("done","cancelled")` как терминал-скип
+  (ORCH-086 D2 предвосхитил `cancelled`; стр. 196) и `_is_terminal_state` по группе Plane
+  `{completed, cancelled}` (ORCH-068, стр. 398–415).
+- `src/serial_gate.py` (ORCH-088) и `src/task_deps.py` (ORCH-026) считают задачу «незавершённой»
+  по `stage != 'done'` — **без** `cancelled`. Если ввести `cancelled`-стадию, не тронув их,
+  отменённая задача навсегда будет «активной»/«незавершённой зависимостью» и **заклинит очередь
+  репо**.
+
+Этот ADR фиксирует `cancelled` как первоклассное терминальное состояние, равноправное `done`, и
+перечисляет ВСЕ точки, где системный предикат терминальности должен его признавать.
+
+## Решение
+
+### Инвариант
+**«Задача терминальна» ⇔ `stage ∈ {done, cancelled}`.** Это единое определение для всех
+подсистем планировщика/мониторинга. `cancelled` — терминальный **сток** (не новое ребро
+конвейера): exit-гейты рёбер `STAGE_TRANSITIONS` и реестр `QG_CHECKS`/`check_*` **не меняются**.
+
+### Точки, признающие `cancelled` терминальным (исчерпывающе)
+1. `src/stages.py::STAGE_TRANSITIONS` — добавить сток
+   `"cancelled": {"next": None, "agent": None, "qg": None}` (параллельно `done`).
+2. `src/serial_gate.py` — `repo_has_other_unfinished` и claim-фрагмент `t2.stage != 'done'`,
+   snapshot: `stage != 'done'` → `stage NOT IN ('done','cancelled')`. **(маркер ORCH-088)**
+3. `src/task_deps.py` — dep-gate и `is_task_ready`: `stage != 'done'` →
+   `stage NOT IN ('done','cancelled')`. **(маркер ORCH-026)**
+4. `src/reconciler.py` — уже покрыто скипом `stage in ("done","cancelled")` (стр. 196);
+   `get_active_tasks_for_reconcile` опционально сузить до `NOT IN ('done','cancelled')`.
+5. `src/job_reaper.py` / `src/queue_worker.py` — перед авто-requeue dead/running-job'а сверять
+   терминал задачи: `stage in ("done","cancelled")` → job помечается `cancelled`, не реквью'ится.
+6. `src/post_deploy.py` / `stage_engine.run_post_deploy_monitor` — монитор не тикает по
+   отменённой задаче (терминал-проверка/маркер `done`).
+
+### Новые терминальные исходы
+- **Job:** `jobs.status='cancelled'` — нигде не реквью'ится; `claim_next_job` выбирает только
+  `status='queued'` (изменений в claim нет). `mark_job` стампит `finished_at` для `cancelled`.
+- **Задача:** `tasks.stage='cancelled'` + аддитивные колонки `cancelled_at`,
+  `cancel_requested_at` (отложенная отмена в критическом окне merge/deploy). Натуральные ключи
+  `plane_id`/`work_item_id` тумбстонятся (`#cancelled-<id>`) для переиспользования «To Analyse»
+  с нуля; `plane_issue_id` сохраняется (аудит). Детали — 08-data-requirements.md.
+
+### Точки врезки STOP (компоненты)
+- `plane.py` — маршрут `stop` (fail-closed, не в `_DEFAULT_STATES`) → `handle_stop`; гейт релонча
+  ограничен стадией `analysis`.
+- `stage_engine.cancel_task` — оркестрация отмены (graceful SIGTERM, cancel-jobs, worktree+branch,
+  tombstone, notify); безопасное прерывание merge/deploy (D7 локального ADR).
+- leaf `src/cancel.py` — чистая логика (`applies`/`in_critical_window`/`snapshot`), never-raise.
+- `src/gitea.py` — `delete_remote_branch` (never-raise; только feature-ветка, `main` неприкосновенен).
+- `GET /queue` — read-only блок `stop`.
+
+### Флаги / совместимость
+- Kill-switch `stop_status_enabled` + scope `stop_status_repos` (CSV, пусто → все репо).
+- При `stop_status_enabled=False`: STOP-обработка и гейт релонча инертны; расширение
+  терминал-набора `cancelled` безвредно при отсутствии отменённых задач → **нулевая регрессия**.
+- `STAGE_TRANSITIONS` (exit-гейты) / `QG_CHECKS` / `check_*` / семантика
+  Approved/Rejected/Confirm Deploy / merge-gate (ORCH-043) / merge-verify (ORCH-071/073) /
+  image-freshness (ORCH-058) / post-deploy (ORCH-021) / serial-gate FIFO (ORCH-088) / auto-label
+  (ORCH-089) — **без изменений**.
+- Миграции БД — только аддитивные/идемпотентные (`_ensure_column`); enduro не затронут (NFR-2).
+
+## Последствия
+- **+** Единое, консистентное определение терминальности — устранён латентный рассинхрон
+  `done`-only между планировщиком и реконсилятором.
+- **+** STOP безопасен для self-hosting: не трогает `main`/прод, отложенная отмена в критическом
+  окне.
+- **−** Терминальность теперь читается из набора `{done, cancelled}`, а не из скаляра `'done'` —
+  будущие подсистемы обязаны использовать набор. Митигейшн: этот ADR + маркер `ORCH-090` в
+  изменённых местах + тесты.
+- **Откат:** `stop_status_enabled=False`; полный revert — снять врезки и вернуть предикаты к
+  `stage != 'done'`.
+
+## Эволюция маркеров `cancelled`-терминала
+Места, признающие `cancelled` терминальным (см. список выше), несут маркер `ORCH-090`. Правка
+любого из них — сверяться с этим ADR (анти-археология: 3+ маркеров → одна ссылка сюда,
+TRACEABILITY.md).
+
+## Ссылки
+- Детальный ADR: `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`
+- Data: `docs/work-items/ORCH-090/08-data-requirements.md`
+- Связанные: adr-0017 (serial-gate), adr-0015 (task-deps), adr-0007 (self-deploy),
+  adr-0006 (merge-gate), adr-0018 (auto-label)

docs/architecture/adr/adr-0027-merge-actor-transient-retry-and-already-in-main.md

@@ -0,0 +1,82 @@
+---
+work_item: ORCH-093
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0027: Merge-актор — ретрай транзиентных ошибок Gitea + гард «ветка уже в `main`»
+
+Сквозной (cross-cutting) ADR. **Амендмент** к [adr-0013](adr-0013-merge-verify-gate.md) (merge-verify
+под-гейт), [adr-0014](adr-0014-merge-verify-sha-source-of-truth.md) (SHA-в-main как источник истины)
+и [adr-0016](adr-0016-ensure-open-pr-before-merge-verify.md) (гарантированный код-PR). Детальное
+решение задачи — `docs/work-items/ORCH-093/06-adr/ADR-001-merge-transient-retry-and-already-in-main-guard.md`.
+
+> Регистрируется как сквозной, т.к. правит блок merge-актора с **3+ маркерами** (`ORCH-071`,
+> `ORCH-073`, `ORCH-082`) — анти-археология маркеров (`docs/_standards/TRACEABILITY.md`): сводный
+> ADR агрегирует эволюцию вместо перечисления work item в коде.
+
+## Статус
+Proposed
+
+## Контекст
+
+Детерминированный merge-актор merge-verify под-гейта (`deploy → done`, self-hosting) состоит из
+`ensure_open_pr` → `merge_pr` → `verify_merged_to_main` (`src/merge_gate.py`). Инцидент **ORCH-063
+(09.06)** вскрыл два дефекта, оба сверены по коду прода:
+
+1. `merge_pr` — **one-shot**: `POST /pulls/{index}/merge`, любой не-`200/201` → мгновенный `False`.
+   Транзиентная икота Gitea (`405 "Please try again later"` при пересчёте `mergeable` сразу после
+   пуша; `5xx`; таймаут) → ложный HOLD защиты ORCH-071/073 → ручной домерж.
+2. `ensure_open_pr` — после ручного мержа код-PR `closed`, открытый не найден → создаёт **новый
+   пустой PR** на ветке, уже целиком в `main`.
+
+Защита ORCH-071/073 («deploy succeeded but not merged») корректна и сохраняется; задача снижает
+лишь **ложные** срабатывания на транзиентах и устраняет мусорные PR. Это блокер автономного прогона
+(эпик ORCH-088).
+
+## Решение
+
+Аддитивно, без правки `STAGE_TRANSITIONS` / `QG_CHECKS` / схемы БД; INV-4 (мерж только через Gitea
+PR-merge API; никогда `push`/`force-push` в `main`) и never-raise сохранены.
+
+- **Ретрай-loop вокруг `POST …/merge`** (только мутирующий вызов) до `merge_retry_max_attempts`
+  (дефолт 3) с экспоненциальным backoff и потолком (`base 2`, `max 5`; суммарно ≤10 с). Классификатор
+  **транзиент** (`405`/`408`/`5xx`/таймаут/сетевое; `409`/`422` при `mergeable==True`; `mergeable==None`
+  → транзиент-по-дефолту в рамках бюджета) vs **терминал** (`403`/`404`; `409`/`422` при
+  `mergeable==False`) — по коду ответа **и** полю `mergeable` (`GET /pulls/{index}`). Терминал →
+  быстрый честный `False` (защита ORCH-071/073 — как прежде). Образец — `check_ci_green`
+  (`attempt i/N`) + transient-breaker агентов.
+- **Гард already-in-main в `ensure_open_pr`**: перед созданием PR — `git merge-base --is-ancestor
+  <branch> origin/main` (rc==0 → ветка целиком в `main`) → новый исход `"already-in-main"`, PR не
+  создаётся; git-ошибка/ambiguous → **fail-OPEN** на текущий create-путь (гард не должен превратить
+  икоту git в ложный no-op мержа). `_handle_merge_verify` трактует `"already-in-main"` как «мержить
+  нечего» → пропуск `merge_pr` → авторитетный SHA-в-main (`verify_merged_to_main`, ADR-0014) доводит
+  до `done` без мусорного PR.
+- **Конфиг**: `merge_retry_enabled` (kill-switch; `False` → one-shot, нулевая регрессия),
+  `merge_retry_max_attempts`, `merge_retry_backoff_base_s`, `merge_retry_backoff_max_s`
+  (env `ORCH_MERGE_RETRY_*`). Гард already-in-main — без отдельного флага (накрыт существующим
+  `merge_verify_autocreate_pr_enabled`).
+
+Объём раската — реально только self-hosting (`merge_verify_applies`); на прочих репо мерж делает
+LLM-deployer → изменение нейтрально.
+
+## Последствия
+
+- **+** Транзиент Gitea переживается автоматически → нет ложного HOLD / ручного домержа в автономном
+  конвейере; нет мусорных пустых PR; повтор финализатора идемпотентен.
+- **+** Реальный конфликт → быстрый честный HOLD; защита ORCH-071/073 и SHA-в-main (ADR-0014) —
+  авторитетны и неизменны.
+- **−** Дефолт `mergeable==None → transient` может добавить ≤10 с до HOLD на реальном конфликте
+  (бюджет жёстко ограничен); один лишний `GET /pulls/{index}` в редком ambiguous-кейсе.
+- **Откат:** `ORCH_MERGE_RETRY_ENABLED=false` → one-shot; `ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED=false`
+  → отключает врезку `ensure_open_pr` с гардом. Полный откат — revert PR.
+
+## Ссылки
+- Детальный ADR: `docs/work-items/ORCH-093/06-adr/ADR-001-merge-transient-retry-and-already-in-main-guard.md`
+- Лехатая: [adr-0006](adr-0006-merge-gate.md), [adr-0013](adr-0013-merge-verify-gate.md),
+  [adr-0014](adr-0014-merge-verify-sha-source-of-truth.md),
+  [adr-0016](adr-0016-ensure-open-pr-before-merge-verify.md)
+- Код: `src/merge_gate.py`, `src/stage_engine.py::_handle_merge_verify`, `src/config.py`

docs/architecture/adr/adr-0028-terminal-window-aware-deploy-status-guard.md

@@ -0,0 +1,96 @@
+---
+work_item: ORCH-094
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-09
+model_used: claude-opus-4-8
+---
+
+# adr-0028: Terminal-window-aware гард выставления deploy-фазовых статусов Plane
+
+Сквозной (cross-cutting) ADR. **Амендмент** к [adr-0010](adr-0010-post-deploy-monitor.md)
+(post-deploy monitor, ORCH-021) и Plane-статусной модели (ORCH-066): вводит инвариант
+«deploy-фазовые Plane-статусы — terminal-window-aware» поверх общих сеттеров `plane_sync` и
+переупорядочивает блок `next_stage == "done"` в `advance_stage`. Детальное решение задачи —
+`docs/work-items/ORCH-094/06-adr/ADR-001-terminal-window-aware-deploy-status-guard.md`.
+
+> Регистрируется как сквозной, т.к. правит **общие** сеттеры `set_issue_awaiting_deploy`/
+> `set_issue_deploying`/`set_issue_monitoring` (используются системно) и трогает маркированный блок с
+> `ORCH-021`/`ORCH-066` (`docs/_standards/TRACEABILITY.md`).
+
+## Статус
+Proposed
+
+## Контекст
+
+Терминальная (`done`) задача в Plane **не держит `Done`**: непрерывный флапп
+`Awaiting Deploy ⟷ Monitoring after Deploy` (верифицировано живьём на **ORCH-061**, task 47, done с
+07.06 — 273 активности, само не затихает). Установлено по коду/логам/БД прода:
+
+- Три code-писателя deploy-фазовых статусов (`src/stage_engine.py:404/1218/1316`) делегируют в тонкие
+  сеттеры `src/plane_sync.py`, которые **БД-стадию не читают** ⇒ терминал-слепы: любой повторный вызов
+  перезаписывает `Done` обратно на промежуточный статус.
+- **Ordering:** `update_task_stage("done")` (`stage_engine.py:369`) пишет `tasks.stage='done'`
+  **раньше** легитимного `set_issue_monitoring` (стр. 404) ⇒ пост-деплой-окно ORCH-021 — by-design
+  индикация поверх уже-`done` задачи. Наивный гард «stage==done → Done» ⇒ регресс легитимного окна.
+- Актор всех 273 переходов — бот-токен орка (`daf4d3f4-…`), не привязан к активной task/job; в БД нет
+  активного post-deploy-monitor для task 47 (окно 15 мин закрыто). Реконсилятор F-1 пропускает
+  `done`/`cancelled`, F-2 опрашивает только `[to_analyse, approved, rejected]` ⇒ механизма привести
+  застрявшую на deploy-статусе done-задачу к `Done` нет.
+
+## Решение
+
+**Единый terminal-window-aware гард на низком чокпоинте** — на входе трёх deploy-фазовых сеттеров
+`plane_sync`. Чистую логику держит **новый leaf-модуль `src/deploy_status_guard.py`** (never-raise,
+config-gated; образец `serial_gate.py`/`labels.py`/`cancel.py`); сеттеры исполняют вердикт.
+
+- **Инвариант легитимности:** deploy-фазовый статус легитимен ⇔ задача **нетерминальна** ИЛИ
+  (`done` **И** активно пост-деплой-окно). Иначе — идемпотентное схождение к `Done`.
+  `decide(work_item_id, target) -> ALLOW | CONVERGE_DONE | SUPPRESS`:
+  kill-switch off / чужой issue / не-self репо / нетерминал → **ALLOW**; `cancelled` → **SUPPRESS**;
+  `done` + `target==monitoring` + `window_active` → **ALLOW**; `done` иначе → **CONVERGE_DONE**
+  (`set_issue_done`, идемпотентно); любое исключение → **ALLOW** + warning (never-raise).
+- **Новый helper** `post_deploy.window_active(repo, wi)` = `has_marker(ARMED) and not
+  has_marker(DONE)` (restart-safe).
+- **Перенос арм-блока** (`post_deploy.arm_monitor`) **перед** terminal-sync в блоке
+  `next_stage == "done"`: на стр. 404 `ARMED` уже записан ⇒ `window_active==True` ⇒ легитимный первый
+  `Monitoring` проходит; re-drive после закрытия окна сходится к `Done`.
+- **Харднинг монитора:** идемпотентный страж `has_marker(...DONE)` (ранний return без PATCH/реэнкью)
+  + тик no-op при `cancelled` мид-окно; тики привязаны к активному job'у (нет job → нет тика).
+- **Наблюдаемость:** каждый вердикт логируется (`work_item`/`caller`/`target`/`db_stage`/
+  `window_active`/вердикт); подавление/схождение — явно.
+- **Флаги** (`config.py`): `deploy_status_guard_enabled=True`
+  (`ORCH_DEPLOY_STATUS_GUARD_ENABLED`, kill-switch → 1:1) + `deploy_status_guard_repos=""`
+  (`ORCH_DEPLOY_STATUS_GUARD_REPOS`, пусто → self-hosting only) с локальным `applies(repo)`.
+
+## Альтернативы
+
+- **Гард в caller'ах `stage_engine`** — отвергнуто: не ловит неизвестный/стейл путь под бот-токеном,
+  размазывает инвариант.
+- **Наивный «stage==done → Done» без предиката окна** — отвергнуто: регресс легитимного `Monitoring`.
+- **Bypass-флаг на доверенном вызове 404** — отвергнуто в пользу переноса арм-блока (один предикат).
+- **Активная сходимость в реконсиляторе F-2** — отвергнуто как основной механизм (лишний polling,
+  правка маркированного F-2); гард на сеттере гасит непрерывный флапп.
+
+## Последствия
+
+- Терминальная задача стабильно держит `Done`; маятник гаснет за один цикл независимо от актора.
+- Легитимный пост-деплой `Monitoring` и рабочий self-deploy-цикл — 1:1 (предикат окна + перенос арм).
+- `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — **не тронуты**.
+- `main`/force-push/прод-контейнер/detached-деплой — не тронуты; не-self репо инертны.
+- Ограничение: если актор флаппа — внешняя Plane-automation (вне кода орка), гард — буфер на стороне
+  орка; локализация (FR-1) и итог документируются (BR-7).
+- **Откат:** `ORCH_DEPLOY_STATUS_GUARD_ENABLED=false` → поведение 1:1; полный — revert ветки.
+
+## Связи
+
+- [adr-0010](adr-0010-post-deploy-monitor.md) (ORCH-021 — пост-деплой-окно, sentinel `armed`/`done`,
+  арм-блок) — амендмент: окно становится предикатом легитимности `Monitoring`.
+- ORCH-066 (Plane-статусная модель — слой B индикации; `deploy→done` self ⇒ `Monitoring`) — инвариант
+  сохранён.
+- [adr-0026](adr-0026-stop-cancel-task.md) (ORCH-090 — терминал `cancelled`) — гард не штампует
+  deploy-статус поверх `cancelled`.
+- ORCH-068/086 (терминал-скип реконсилятора) — этот ADR распространяет идею терминал-aware на
+  выставление deploy-статусов.
+- Детально: `docs/work-items/ORCH-094/06-adr/ADR-001-terminal-window-aware-deploy-status-guard.md`.

docs/architecture/adr/adr-0029-coverage-gate.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-027
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0029: Гейт покрытия тестами — edge sub-gate + ratchet-базовая линия
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-027
+- **Детальный ADR:** `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`
+
+## Контекст
+Оркестратор автономен: `developer` пишет код без человека-фильтра, `tester` сам решает, хватает
+ли тестов. Существующие тестовые гейты судят только по факту прохождения, не по полноте:
+`check_ci_green` (exit-code CI), `check_tests_passed` (LLM-вердикт `tester`'а), merge-gate
+re-test (exit-code). Ни один не замечает «300 строк кода, 0 тестов». При пакетном автономном
+прогоне (ORCH-088) это монотонная деградация покрытия. Нужна детерминированная метрика — по духу
+как security-гейт (adr-0012).
+
+## Решение
+Детерминированный (без LLM) **гейт покрытия как под-гейт ребра `deploy-staging → deploy`**,
+рядом с security-gate (ORCH-022), merge-gate (ORCH-043), image-freshness (ORCH-058). Паттерн —
+leaf-модуль `src/coverage_gate.py` (never-raise) + обёртка в `QG_CHECKS` (`check_coverage_gate`)
++ врезка `_handle_coverage_gate` в `advance_stage`. `STAGE_TRANSITIONS` не меняется.
+
+- **Порядок: security → merge → `coverage` → image-freshness.** Coverage идёт **ПОСЛЕ
+  merge-gate** (ветка догнана на свежий `origin/main` → меряем покрытие того кода, что landed) и
+  **ДО image-freshness** (фейлить дёшево до docker-rebuild). На этой точке merge-lease **held** →
+  **FAIL обязан освободить lease** при откате (как image-freshness rollback; в отличие от
+  security, который идёт до захвата lease).
+- **Измеритель:** `pytest-cov` (`coverage.py`), `python -m pytest tests/ --cov=src
+  --cov-report=json` в изолированном worktree (`ensure_worktree`); метрика —
+  `totals.percent_covered`. Тайм-аут `coverage_run_timeout_s`. Скоуп — `src/` (не тесты).
+- **Чистая функция** `compute_coverage_verdict(measured, baseline, floor, policy, epsilon)`:
+  `absolute` (≥floor−ε), `baseline` (≥baseline−ε, ratchet), `both` (дефолт). `baseline=None` →
+  bootstrap (только absolute). FAIL → откат на `development` + developer-retry (cap
+  `MAX_DEVELOPER_RETRIES`), дословный reason в `task_desc` (ORCH-046).
+- **Базовая линия — аддитивная БД-таблица** `coverage_baseline(repo PK, coverage, source_sha,
+  updated_at)` (`CREATE TABLE IF NOT EXISTS`, паттерн `repo_freeze`/`job_deps`). Выбор БД над
+  файлом-в-репо: нет git-churn/конфликтов на ratchet, restart-safe, атомарное обновление.
+- **Ratchet-up** в choke-point подтверждённого merge `_handle_merge_verify` (ребро
+  `deploy → done`, ORCH-071/073): читает измеренное покрытие из `18-coverage-report.md`,
+  атомарный compare-and-set `UPDATE ... WHERE coverage <= measured` (базовая линия не падает).
+  Под held merge-lease + per-repo сериализацией merge (ORCH-043) — двойная анти-гонка.
+- **Артефакт `18-coverage-report.md`** с frontmatter `coverage_status: PASS|FAIL` (+
+  `measured_coverage`/`baseline`/`floor`/`policy`/`delta` + аддитивная 52c-схема); вердикт
+  читается ТОЛЬКО из frontmatter через `src/frontmatter.py` (single source of truth).
+- **Условность (как ORCH-35/43/58):** `coverage_gate_enabled` + `coverage_gate_repos` (пусто →
+  только self-hosting `orchestrator`); вне области → no-op pass. `applies(repo)` ПЕРВОЙ, дорогой
+  прогон — только при applies.
+- **Ошибка инструмента → fail-open + WARNING** по умолчанию (`coverage_tool_fail_closed=False`,
+  анти-петля как ORCH-061); флаг → fail-closed.
+- **Наблюдаемость:** read-only блок `coverage` в `GET /queue`; FAIL → Telegram (кликабельный
+  номер, измеренное/порог/дельта). Опциональный `POST /coverage/baseline` (ручной override).
+- **never-raise**, гейт не деплоит/не рестартит прод/не пушит в `main` (NFR-3).
+
+## Альтернативы
+- **CI-job (`check_ci_green`):** пороги/политика/baseline/артефакт плохо выражаются статусом
+  коммита; ratchet требует записи в БД. Отклонено для v1 (точка расширения).
+- **Edge `testing → deploy-staging`:** ветка не догнана на свежий `main` → метрика неточна;
+  откат не освобождает lease. Отклонено.
+- **Базовая линия в файле репо:** git-churn/конфликты на каждый ratchet. Отклонено.
+- **Новая стадия `coverage`:** «пустая» стадия без агента не имеет триггера (как ORCH-043/022).
+  Отклонено.
+- **Жёсткий absolute-порог без baseline/epsilon:** массовые ложные заворота. Отклонено.
+
+## Последствия
+- Класс «тихо просевшее покрытие» закрыт детерминированной метрикой; baseline только растёт.
+- Нулевая регрессия вне области (enduro-trails); `STAGE_TRANSITIONS`/`QG_CHECKS`-семантика/
+  вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) —
+  байт-в-байт прежние; новая БД-таблица аддитивна.
+- Плата: ещё один «скрытый» под-гейт ребра; новая pip-зависимость (`pytest-cov`); доп. прогон
+  pytest (после merge-gate re-test, ограничен таймаутом, фейлит до rebuild); v1 — Python-only.
+- Дефолтный fail-open тихо пропускает при устойчивом сбое инструмента (с WARNING) —
+  переключаемо `coverage_tool_fail_closed`.
+- Сквозное изменение (новый QG + edge-под-гейт + новая таблица + новый артефакт) →
+  `arch:major-change`; прод-деплой строго через staging-гейт (8501), без рестарта прод-контейнера.
+- **Откат:** `coverage_gate_enabled=False` → полный no-op (мгновенный обратимый kill-switch).
+
+## Связи
+adr-0012 (security-гейт — паттерн edge-под-гейта/leaf/never-raise/fail-open), adr-0006
+(merge-gate — edge-под-гейт/откат/merge-lease), adr-0008 (image-freshness — условность/
+fail-closed/release-lease-on-rollback), adr-0003 (условный гейт / `is_self_hosting_repo`),
+adr-0009 (анти-петля ложных FAIL, ORCH-061), adr-0013/adr-0014 (merge-verify / SHA-in-main как
+source of truth — точка ratchet), adr-0015/adr-0017 (per-repo сериализация merge/serial-gate),
+adr-0020 (frontmatter-контракт — парсинг `coverage_status:`), adr-0019 (PIPELINE_DOCS — артефакт
+`18-coverage-report.md`), ORCH-9/15 (мульти-стек — будущая зависимость BR-6).

docs/architecture/adr/adr-0030-metrics-endpoint.md

@@ -0,0 +1,88 @@
+---
+work_item: ORCH-099
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0030: Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b)
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-099 (FND/F1a)
+- **Детальный ADR:** `docs/work-items/ORCH-099/06-adr/ADR-001-metrics-endpoint.md`
+
+## Контекст
+Эпик автономного саморазвития, домен 0 «Фундамент». Рамка наблюдаемости (заказчик): **наблюдатель
+отделён от наблюдаемого** — мозг мониторинга (пороги/алерты/история/Telegram) живёт в отдельном
+sidecar-контейнере **F1b** (`watchdog/`), а орк отдаёт **только сырьё**, которое знает лишь он сам.
+Сегодня такого источника нет: `/health` = `{"status":"ok"}`, `/status` = активные задачи, `/queue` —
+«человеческий» снимок, перемешанный с конфигом демонов. Нет стабильного машинного контракта для
+детекта застрявшей стадии / зависшего агента / деградации очереди / всплеска стоимости. F1b
+заблокирована этой задачей. Self-hosting: прод общий с enduro-trails ⇒ эндпоинт обязан быть строго
+read-only и never-raise.
+
+## Решение
+Новый **leaf-модуль** `src/metrics.py` (`build_metrics() -> dict`, чистый, never-raise по разделам —
+паттерн `serial_gate.snapshot()`) + тонкий эндпоинт `@app.get("/metrics")` в `src/main.py` (стиль
+`GET /queue`). Только чтение существующих таблиц (`tasks`/`jobs`/`agent_runs`) и in-memory-снапшотов
++ два read-only helper'а в `src/db.py`. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-
+ключи/схема БД — **не трогаются**.
+
+- **Конверт + контракт версии:** `schema_version` (старт `1`), `generated_at` (UTC ISO-8601 —
+  момент снимка, домен часов орка), `clk_tck` (`os.sysconf("SC_CLK_TCK")`), разделы
+  `stages`/`queue`/`agents`/`cost`. **Политика версии:** аддитивные изменения НЕ бампят (sidecar
+  обязан игнорировать незнакомые ключи и толерировать отсутствие опциональных); бамп — только при
+  ломающем (rename/remove/retype). Forward-compatible контракт для F1b.
+- **`stages`** — `db.get_active_tasks_for_reconcile()` + фильтр `stage NOT IN ('done','cancelled')`
+  на слое metrics (helper намеренно отдаёт `cancelled` для ORCH-086 — не трогаем его инвариант);
+  поля `work_item`/`stage`/`age_in_stage_s`/`repo`.
+- **`queue`** — `db.job_status_counts()` (+`cancelled`), глубина, сырьё ретраев
+  (`attempts`/`max_attempts`/`transient_attempts`/в-backoff), `worker.breaker.snapshot()`,
+  `max_concurrency`. Недоступный worker → `breaker: null`, не 500.
+- **`agents` (liveness)** — новый dedicated read-only helper `db.get_running_agents()` (НЕ расширение
+  hot-path `get_running_jobs()` reaper'а, ORCH-065): `agent`/`run_id`/`job_id`/`pid`/`runtime_s`
+  (= `running_age_s` от `jobs.started_at`)/`model`/`effort`. CPU-сырьё — **вариант A**: орк читает
+  `/proc/<pid>/stat` (поля 14+15, utime+stime) → `cpu_ticks`; **дельту не считает** — арбитр
+  «жив/завис» это sidecar (stateless-эмиссия). `pid is None`/мёртвый/нет `/proc`/не-Linux →
+  `cpu_ticks: null`, не ошибка.
+- **`cost`** — `running` (по running-job, часто `null` до завершения — честное сырьё, `null` ≠ ноль)
+  + `aggregate` (новый helper `db.agent_cost_totals()`, `COALESCE(SUM(...),0)` по
+  `cost_usd`/`input_tokens`/`output_tokens`/`cache_read_tokens`/`cache_creation_tokens`).
+- **Kill-switch** `metrics_endpoint_enabled` (env `ORCH_METRICS_ENABLED`, дефолт `True`): при `False`
+  → `200` с `{"schema_version":1,"enabled":false}` (контракт остаётся парсимым). Операторский
+  off-switch на общем инстансе.
+- **Never-raise:** каждый раздел — свой `try/except` + `logger.warning` + дефолт (`null`/`[]`/`{}`);
+  `build_metrics()` никогда не пробрасывает. Read-only: ни одного `INSERT/UPDATE/DELETE/CREATE/ALTER`.
+
+## Альтернативы
+- **Расширить `/queue`** — отклонено: ломает байт-в-байт контракт (BR-6) + смешивает сырьё с
+  человеческим снимком.
+- **Prometheus/OpenMetrics** — отклонено: заказчик задал тонкий кастомный sidecar (не Prometheus),
+  контракт — JSON.
+- **Орк считает CPU-дельту сам** — отклонено: требует состояния; stateful-арбитр это sidecar (C-1).
+- **Расширить SELECT `get_running_jobs()`** — отклонено: перенос инварианта hot-path reaper'а;
+  изолируем dedicated helper.
+- **Push в sidecar** — отклонено: нарушает разделение C-1; зависший орк ⇒ pull падает = сам сигнал.
+
+## Последствия
+- F1b разблокирована стабильным машинным контрактом; домен наблюдаемости стартует.
+- Строго read-only + never-raise ⇒ near-zero риск для общего прод-конвейера (enduro-trails);
+  `/health`/`/status`/`/queue` байт-в-байт; гейты/схема/machine-verdict-ключи не тронуты (NFR-5).
+- `schema_version` + аддитивно-толерантная политика ⇒ расширения не ломают F1b.
+- Плата: новая поверхность совместимости `/metrics`↔F1b (митигейшн — единый репо контракта + версия);
+  CPU-liveness Linux-специфичен (`/proc`; не-Linux → `null`). Топология/схема не меняются (sidecar и
+  его сетевая достижимость — объём F1b).
+- Новый компонент + публичный контракт → `arch:major-change` (хоть и аддитивно/read-only/обратимо);
+  прод-деплой строго через staging-гейт (8501), без рестарта прод-контейнера.
+- **Откат:** `metrics_endpoint_enabled=False` (мгновенный) или удаление модуля/эндпоинта/helper'ов —
+  без следов в БД/схеме.
+
+## Связи
+adr-0002 (job-queue/circuit-breaker — источник `queue`-сырья), adr-0011 (job-reaper —
+`get_running_jobs`/pid/liveness-семантика, изоляция hot-path), adr-0026 (терминал `{done,cancelled}`
+— фильтр `stages`), adr-0017 (serial_gate — паттерн leaf `snapshot()`/never-raise), adr-0020
+(frontmatter-контракт — стиль версионируемого контракта). Прямой потребитель — **F1b** (sidecar
+`watchdog/`, отдельная задача).

docs/architecture/adr/adr-0031-legacy-ownership-normalization.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-057
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0031: Нормализация legacy root-owned файлов при миграции uid — детект-leaf + actionable worktree-ошибка
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-057 (follow-up ORCH-040)
+- **Детальный ADR:** `docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md`
+
+## Контекст
+ORCH-040 перевёл контейнеры на `user: "1000:1000"`, изменив только `docker-compose.yml`. Владельца
+уже существующих `root:root` файлов в bind-mount `/repos` это не меняет. Под uid 1000
+`src/git_worktree.py::ensure_worktree` (`os.makedirs` стр. 78 / `git worktree add` стр. 81/85) не может
+создать worktree рядом с root-owned `/repos/_wt/` → `fatal: could not create leading directories …
+Permission denied`, который сейчас пробрасывается сырым. Конвейер приходит сюда из
+`launcher._spawn`/`_materialize_deferred_branch` (ORCH-088) — **агент не стартует** (launch-time
+инфра-сбой, не код задачи). Инцидент 06.06 на проде (первый запуск ORCH-043); workaround Стрима
+(`chown -R 1000:1000`) наложен вручную. ADR-040 описал нормализацию абстрактно («вне объёма кода») и
+не дал процедуры → баг воспроизводим на чистой среде / новом репо / после исторического запуска под
+root. Контейнер бежит **без root** → код физически не может `chown` чужие файлы; ему доступны лишь
+детект + диагностика.
+
+## Решение
+Три аддитивных, обратимых kill-switch'ем слоя — паттерн условного leaf-гейта (`coverage_gate`/
+`serial_gate`) + best-effort startup-хук (`main.lifespan`, как lease-reclaim). `STAGE_TRANSITIONS` /
+`QG_CHECKS` / `check_*` / machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/
+`staging_status:`/`security_status:`/`coverage_status:`) / схема БД — **байт-в-байт прежние**.
+
+- **Actionable worktree-ошибка (D1):** `ensure_worktree` классифицирует класс «нет прав» (маркеры
+  `Permission denied`/`could not create leading directories`/`insufficient permission`/`EACCES`/
+  `EPERM`) и поднимает `RuntimeError` с причиной (legacy root-файлы после миграции uid) + лечащей
+  командой + ссылкой на INFRA.md. Не-прав-ошибки сохраняют прежний текст/смысл (никакой подмены).
+  Меняется лишь **формулировка**, не факт сбоя.
+- **Детект-leaf `src/fs_normalize.py` (D2):** чистый, never-raise, TTL-кэш (паттерн `preflight`).
+  `scan_ownership(roots, target_uid)` обходит `/repos/_wt`, `<repo>/.git/objects`,
+  `<repo>/.git/worktrees`, `data/runs`; ранний выход при первом `st_uid != target_uid`
+  (`target_uid=os.getuid()` по умолчанию). `applies(repo)` (kill-switch + scope; пусто →
+  `is_self_hosting_repo`) проверяется ПЕРВЫМ → дорогой обход только при applies. Идемпотентно;
+  ошибка обхода → WARNING + консервативный `mismatch=False`.
+- **Интеграция = наблюдаемость, без блокировки claim (D3):** best-effort `scan_ownership()` на старте
+  `main.lifespan` → WARNING + Telegram при mismatch. Claim НЕ гейтится: внятный ранний отказ даёт D1
+  в точке launch (знает repo, агент ещё не тратил токены). Блокирующий preflight-гейт отвергнут —
+  preflight не знает repo, заблокировал бы и enduro-trails на общем `/repos`.
+- **Опц. `normalize()` (D4):** chown только при `CAP_CHOWN`/root (под uid 1000 — no-op + лог),
+  флаг `fs_normalize_auto` (дефолт `False`). Init-контейнер/root-entrypoint отвергнут: реинтродукция
+  root-контекста (анти-цель ORCH-040) + правка compose = self-deploy/групповой риск. Реальную
+  нормализацию несёт операторская процедура.
+- **Процедура (D5):** `INFRA.md` получает раздел «Миграция uid: обязательная нормализация legacy
+  root-файлов» (точные команды по всем корням) как обязательный шаг миграции; forward-breadcrumb из
+  ADR-040.
+- **Флаги:** `fs_normalize_enabled` (kill-switch, дефолт `True`), `fs_normalize_repos` (CSV, пусто →
+  self-hosting only), `fs_target_uid` (1000), `fs_normalize_auto` (`False`), `fs_scan_roots`,
+  `fs_scan_cache_ttl_s` (300). Наблюдаемость — блок `fs_ownership` в `GET /queue`; опц. `POST
+  /fs-normalize/check`.
+
+## Альтернативы
+- **Init-контейнер/root-entrypoint** — реинтродукция root (анти-цель ORCH-040), self-deploy compose,
+  групповой риск ради разовой операции. Отвергнуто; носитель нормализации — операторская процедура.
+- **Блокирующий claim-гейт (preflight)** — preflight не знает repo → регресс enduro на общем `/repos`.
+  Отвергнуто.
+- **Блокирующий claim-гейт (queue_worker/claim)** — дорогой FS-обход в hot-path + «молчаливое
+  зависание» вместо диагноза D1. Отвергнуто.
+- **Авто-chown из app по умолчанию** — под uid 1000 невозможен; ложное ожидание самолечения.
+  Отвергнуто (оставлен opt-in `fs_normalize_auto`).
+- **Hard-fail старта при mismatch** — нарушает never-raise, стопорит сервис всех проектов. Отвергнуто.
+
+## Последствия
+- Класс «сырой git-fatal на launch после миграции uid» закрыт внятным диагнозом (D1) + проактивным
+  startup-сигналом (D3); пробел процедуры ADR-040 закрыт (INFRA.md).
+- Нулевая регрессия enduro-trails (scope first); инварианты конвейера/схема БД — байт-в-байт.
+- Никакого root-контекста/рестарта прода/касания `main`/force-push/прод-образа (NFR-1).
+- Плата: фактический `chown` остаётся ручным операторским шагом (но теперь внятным, с инструкцией);
+  +1 best-effort startup-хук и leaf-модуль; `fs_normalize_auto=True` под root реинтродуцирует
+  chown-контекст (дефолт `False`, не для прод-self).
+- Аддитивно/обратимо: **не** `arch:major-change` (нет новой стадии/QG/таблицы/смены топологии) — leaf
+  + startup-хук + docs.
+- **Откат:** `fs_normalize_enabled=False` → полный no-op (мгновенный обратимый kill-switch).
+
+## Связи
+adr-0005 (контейнер под host-uid — порождающее решение ORCH-040, чей пробел закрываем),
+adr-0029/adr-0012 (coverage/security-гейт — паттерн условного leaf `applies`/scope/never-raise/
+fail-open), adr-0017 (serial-gate — leaf never-raise + отложенный срез ветки `_materialize_deferred_
+branch`, чья точка падает в `ensure_worktree`), adr-0011 (job-reaper — образец best-effort
+startup-хука в `lifespan`), adr-0024 (disk-watchdog — образец «только читать/уведомлять, не трогать
+хост/прод»).

docs/architecture/adr/adr-0032-bug-fast-track.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-019
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0032: Багфикс-трек — укороченный маршрут конвейера для багов (ORCH-019)
+
+## Статус
+Proposed
+
+## Контекст
+
+Любая задача идёт по полному конвейеру `analysis → architecture → development → review → testing
+→ deploy-staging → deploy → done`. Для мелкого бага стадия `architecture` (отдельный прогон
+opus-агента `architect` + ADR + exit-гейт `check_architecture_done`) избыточна и тратит
+токены/время (прецедент ET-9/ET-014 ~35 мин).
+
+**Корневой инвариант (нерушимый):** упрощаем только *аналитику/архитектуру*; ни один Quality
+Gate / под-гейт (security/merge/coverage/image-freshness) / exit-код deploy-хука — НЕ ослаблен
+(урок ET-8: срезанная проверка = недоделка на проде).
+
+Кросс-каттинговость: затрагивает семантику маршрутизации (`advance_stage`), вводит новый
+leaf-компонент `src/bug_fast_track.py` и аддитивную колонку `tasks.track` → регистрируется
+сквозным ADR.
+
+## Решение
+
+Багфикс-трек — **свойство планировщика/точки входа, НЕ Quality Gate**.
+
+1. **Классификация** (`src/bug_fast_track.py`, leaf never-raise по образцу `serial_gate`/`labels`):
+   задача с меткой Plane `Bug` (`bug_fast_track_label`, читается аппаратом ORCH-089
+   `labels.has_label`) помечается `track='bug'`. `applies(repo)` (локально, без сети) — первым;
+   `has_label` (сеть) — только при `applies==True`; чтение метки **только** в `start_pipeline`,
+   никогда в горячем `claim_next_job` (anti-stall).
+
+2. **Хранение** — аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'`
+   (`_ensure_column`, паттерн `tasks.cancelled_at` ORCH-090); читается в `advance_stage` из БД
+   (не из сети).
+
+3. **Routing-override** — `STAGE_TRANSITIONS` и `get_next_stage`/`get_agent_for_stage` остаются
+   **чистыми** (1:1). В `advance_stage`, на ребре выхода из `analysis`, при `track='bug'`:
+   `next_stage` → `development` (вместо `architecture`), `next_agent` → `developer` (вместо
+   `architect`). Багфикс физически минует стадию `architecture` → её exit-гейт
+   `check_architecture_done` и `06-adr/` для багфикса не исполняются.
+
+4. **Гейт `analysis` не трогаем** — `check_analysis_complete`/`check_analysis_approved` байт-в-байт
+   прежние; lite-аналитик эмитит все 4 файла (01-bug-report / 02-03 краткие заглушки / 04 план
+   обязательного регресс-теста). Экономия — пропуск всей стадии `architecture`, не число файлов.
+
+5. **Эскалация** (обратимость) — `POST /bug-fast-track/escalate?work_item=<id>` сбрасывает
+   `track→'full'` (+ self-escalate мини-аналитика); задача далее идёт через `architecture`.
+
+6. **Условность/откат** — `bug_fast_track_enabled` (kill-switch), `bug_fast_track_label`,
+   `bug_fast_track_repos` (CSV; **пусто → self-hosting only**). `False`/неприменимый репо →
+   путь старта и маршрут **байт-в-байт** прежние.
+
+7. **Наблюдаемость** — read-only блок `bug_fast_track` в `GET /queue` (флаг/область/метка +
+   счётчик `track='bug'` + метрика экономии из `agent_runs`); лог на решение о маршруте; опц.
+   `🐞` в Telegram-карточке.
+
+## Кросс-каттинговые инварианты (НЕ нарушаются)
+
+- `STAGE_TRANSITIONS` структурно не меняется (нет новых/удалённых стадий); `cancelled`/`done`
+  стоки и предикаты терминальности (ORCH-090) не затронуты.
+- Реестр `QG_CHECKS`, сигнатуры `check_*`, вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/
+  `staging_status:`/`security_status:`/`coverage_status:`), порядок под-гейтов — байт-в-байт.
+- Врезка ORCH-019 в `advance_stage` — ТОЛЬКО на ребре выхода из `analysis`, ДО всех deploy-edge
+  под-гейтов (ORCH-022/043/027/058) и Phase A/B (ORCH-036/059) → их инварианты сохранены.
+- Композиция с serial-gate (ORCH-088), auto-label (ORCH-089), coverage-gate (ORCH-027),
+  merge-gate (ORCH-043) — багфикс-задача остаётся обычной задачей репо.
+
+## Последствия
+
+- **+** Багфикс минует стадию `architecture` (основная экономия), гейты качества сохранены.
+- **+** Аддитивно, под kill-switch, per-repo, never-raise, fail-safe → полный цикл; нулевая
+  регрессия для enduro и orchestrator при выключении.
+- **−** lite-аналитик эмитит 02/03 заглушки (компромисс ради неизменности гейта); эскалация v1
+  требует операторского действия (авто-триаж сложности — будущее, ORCH-13/Вариант 3).
+- **Откат:** `bug_fast_track_enabled=False` (мгновенно); колонка `tasks.track` аддитивна и
+  безвредна (дефолт `'full'`).
+
+## Связанные решения
+- ORCH-089 (auto-label) — переиспользуемый аппарат label-чтения: [adr-0018](adr-0018-auto-label-gates.md)
+- ORCH-088 (serial gate) — композиция очереди репо
+- ORCH-027 (coverage-gate) — структурный союзник BR-4: [adr-0029](adr-0029-coverage-gate.md)
+- ORCH-090 (cancelled) — паттерн аддитивной колонки `tasks.*`: [adr-0026](adr-0026-stop-cancel-task.md)
+
+## Ссылки
+- Детальный ADR задачи: `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-019/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+</content>

docs/architecture/adr/adr-0033-sidecar-watchdog.md

@@ -0,0 +1,85 @@
+---
+work_item: ORCH-100
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0033: Sidecar-watchdog F1b — мозг мониторинга в отдельном контейнере
+
+- **Статус:** proposed
+- **Дата:** 2026-06-10
+- **Задача:** ORCH-100 (FND/F1b)
+- **Детальный ADR:** `docs/work-items/ORCH-100/06-adr/ADR-001-sidecar-watchdog.md`
+- **Парный ADR:** `adr-0030` (F1a `/metrics` — источник сырья)
+
+## Контекст
+Домен 0 «Фундамент» эпика автономного саморазвития, рамка наблюдаемости заказчика: **наблюдатель
+отделён от наблюдаемого**. F1a (adr-0030) отдаёт read-only `GET /metrics` — **только сырьё**. F1b —
+**мозг**: читает сырьё, дополняет внешними сигналами (хост/контейнеры/зависимости), решает по порогам,
+алертит. Частичные стражи (`disk_watchdog`/`reaper`/`reconciler`) живут ВНУТРИ процесса орка — орк
+завис/упал ⇒ они мертвы, платформа слепа в критический момент. Рамки: C-1 (отдельный контейнер, код в
+`watchdog/`), C-2 (без внешнего плеча — принятый риск), C-3 (тонкий стек, НЕ Grafana/Prometheus; хост
+впритык). Критический инвариант: орк лёг ⇒ `/metrics` недоступен = **сам сигнал тревоги**.
+
+## Решение
+Новая папка `watchdog/` — **тонкий Python-3.12-stdlib демон** (без сторонних зависимостей), отдельный
+образ `watchdog/Dockerfile` + сервис `orchestrator-watchdog` в `docker-compose.yml` (`network_mode:
+host`, read-only `docker.sock`, `mem_limit: 128m`, `restart: unless-stopped`). Тик: (1) `GET /metrics`;
+(2) хост (диск/inode/память/CPU, stdlib); (3) статусы контейнеров через read-only `docker.sock`
+(GET-only — без `docker` SDK); (4) пинг Plane/Gitea/Anthropic. Сигналы проходят через **обобщённую
+чистую** `decide(signal_active, prev, now, cooldown) -> alert|realert|recovery|none` (генерализация
+`disk_watchdog.decide_action`; per-signal in-memory `AlertState`). Алерт — в **собственный** Telegram-
+канал sidecar (свои `WATCHDOG_TG_*`; **НЕ** импорт `src/notifications.py`). Особый сигнал — `/metrics`
+не отвечает → `orch_down`. Всё never-raise (per-source/per-tick/per-send), под kill-switch
+`WATCHDOG_ENABLED`, строго read-only к наблюдаемому. **`src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/
+`check_*`/схема БД орка — не тронуты** (F1b вне процесса орка и вне конвейера QG).
+
+- **Стек** — Python stdlib (`urllib`, `socket`+`http.client` для docker.sock, `shutil.disk_usage`,
+  `/proc/meminfo`); pytest на чистые функции. Отвергнуты Go / `docker` SDK / Prometheus (C-3).
+- **Реестр сигналов** — `orch_down` (K подряд неудачных опросов), `host_mem`/`host_disk_crit`,
+  `agent_hung` (Δ`cpu_ticks`/`clk_tck`/Δ`generated_at` < floor при растущем `runtime_s`; нужно 2
+  опроса — sidecar stateful-арбитр), `stage_stuck` (`age_in_stage_s`), `job_failed` (edge),
+  `queue_depth`, `container_down` (per name), `dep_down` (per name). Пороги/интервалы/URL — из env.
+- **Владелец диск-алерта (BR-10)** — штатные 85% остаются за внутренним `disk_watchdog` (ORCH-063,
+  канал орка) ⇒ **нулевой дубль по построению**; sidecar покрывает провал «орк+disk_watchdog мертвы»
+  через `orch_down`, плюс **opt-in** (default off) независимый критический потолок `host_disk_crit`
+  (97%) — другое событие/канал, не повтор 85%.
+- **Толерантность контракта** — неизвестные ключи `/metrics` игнорируются, отсутствие опционального не
+  ошибка, рост `schema_version` → warning (зеркало аддитивной политики adr-0030).
+- **Kill-switch** `WATCHDOG_ENABLED=false` → демон инертен (idle-loop, не exit) ⇒ нулевой эффект.
+
+## Альтернативы
+- **Go / `docker` SDK / `requests`** — отклонено: вес/вторая цепочка против C-3 и консистентности с
+  `disk_watchdog`.
+- **Prometheus/Grafana/TSDB** — отклонено: прямой запрет C-3.
+- **Sidecar — единственный владелец диска** — отклонено: потеря покрытия, когда сам sidecar/Docker
+  недоступен; выбрана связка primary `disk_watchdog` + opt-in ceiling.
+- **Push из орка в sidecar** — отклонено: зависший орк не пушит; pull падает = сам сигнал `orch_down`.
+- **bridge + `host.docker.internal`** — отклонено: на Linux ненадёжно; `network_mode: host` проще.
+- **Своя БД/файл порогов** — отклонено: C-3; in-memory best-effort достаточно (как `disk_watchdog`).
+
+## Последствия
+- Внешний мозг мониторинга переживает падение орка; `orch_down` делает наблюдателя громче в инцидент.
+- Строго read-only + независимый канал + never-raise ⇒ self-hosting-безопасно (enduro не затронут);
+  падение sidecar не влияет на конвейер.
+- Аддитивно/обратимо: `src/**`/гейты/схема байт-в-байт; kill-switch → нулевая регрессия; дубль диска
+  исключён структурно.
+- Плата: новый контейнер на впритык-хосте (`mem_limit: 128m` + замер RSS на staging обязательны);
+  C-2 (падёт хост → молчит и sidecar); новая поверхность совместимости `/metrics`↔F1b (толерантный
+  парсинг + единый репо контракта); CPU-liveness Linux-специфичен.
+- **Топология** меняется (новый контейнер) → `07-infra-requirements.md`; **схема БД** не меняется →
+  08 = N/A. Новый компонент + контейнер + канал → `arch:major-change`; прод-выкат через staging-гейт
+  (8501), деплой sidecar НЕ рестартит прод-контейнер.
+- **Откат:** не запускать сервис / `WATCHDOG_ENABLED=false` (мгновенный) или удаление `watchdog/` +
+  сервиса + env — без следов в БД/схеме.
+
+## Связи
+adr-0030 (F1a `/metrics` — парный источник сырья; контракт `cpu_ticks`/`clk_tck`/`generated_at`/
+`schema_version`), adr-0024 (`disk_watchdog` — образец решающей функции/never-raise + владелец
+диск-алерта), adr-0025 (build-cache-pruner — паттерн «вторая половина»), adr-0017 (serial_gate —
+leaf `snapshot()`/never-raise), adr-0011 (job-reaper — pid/liveness-семантика). Прямой источник —
+**F1a** (`GET /metrics`); F1b — его потребитель.
+</content>

docs/architecture/adr/adr-0034-lessons-journal.md

@@ -0,0 +1,92 @@
+---
+work_item: ORCH-098
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0034: Машинный журнал уроков — таблица `lessons` + observer-leaf (ORCH-098)
+
+## Статус
+Proposed
+
+## Контекст
+
+Оркестратор автономно ведёт задачи по конвейеру (ORCH-54), но **развивается** вручную: инциденты →
+уроки → задачи. Уроки живут свободным текстом в `memory/` — не машиночитаемы: нельзя считать
+паттерны, приоритизировать, предлагать улучшения. ORCH-098 — шаг 1 эпика саморазвития (домен 0
+«Фундамент», F2): «топливо» петли самообучения 8A. Нужна **структурированная таблица отклонений
+конвейера**, на которой позже встанут ретроспективщик (E2), приоритизатор RICE (E3) и Стрим.
+
+Нормативное требование Славы (10.06): схема ДОЛЖНА **сразу** нести поля **атрибуции** урока
+(`platform`/`project`/`both`/`unknown` + целевой репо + домен улучшения), иначе позже придётся
+переделывать схему на живой общей прод-БД.
+
+**Кросс-каттинговость** (почему сквозной ADR): новый компонент `src/lessons.py` + аддитивная
+таблица на **общей прод-БД** (self-hosting, разделяемой с enduro-trails) + врезки автозаписи в
+несколько горячих choke-point'ов (`stage_engine`/`merge_gate`/`launcher`) + новый раздел контракта
+`GET /queue`. Фундамент для будущих задач-потребителей → регистрируется глобально.
+
+## Решение
+
+Журнал уроков — **observer (наблюдатель), НЕ Quality Gate**. Аддитивная таблица + чистый leaf,
+по образцу `serial_gate`/`coverage_gate`/`metrics`/`bug_fast_track`.
+
+1. **Таблица `lessons`** (`db.init_db()`, `CREATE TABLE IF NOT EXISTS` + 3 индекса, идемпотентно,
+   restart-safe) — поля контекста (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализа
+   (`root_cause`/`suggestion`), статуса (`status`/`related_task`), **атрибуции сразу и нуллабельно**
+   (`attribution`/`target_repo`/`target_domain`) + `source`/`detail`. Без `enum`-констрейнтов
+   (слаги forward-compatible). Будущие колонки — `_ensure_column`.
+
+2. **Leaf `src/lessons.py`** (never-raise, импортирует только `config`+`db`): `record()` / `get()` /
+   `update()` / `snapshot()`. **Расхождение с гейт-шаблоном: журнал НЕ скоупится по репо** — он
+   observer-only и не *действует* ни на один репо; единственный регулятор — глобальный kill-switch
+   `lessons_enabled`. Запись урока про enduro ценна и **не затрагивает** пайплайн enduro (чистая
+   память орка); репо-разрез — на выборке (`repo`-колонка/фильтр).
+
+3. **Автозапись 4 типов** (`source="auto"`, best-effort, дедуп в окне; `transient_retry` — только на
+   исчерпании бюджета ретраев): `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`),
+   `merge_hold` (`merge_gate._handle_merge_verify` HOLD), `transient_retry` (merge-retry/launcher
+   transient budget-exhaustion), `deploy_degraded` (post-deploy `DEGRADED → set_repo_freeze`, урок
+   слоя-3 «деплой OK / прод сломан», ET-8). Каждая врезка — одиночный вызов в защитном `try/except`.
+
+4. **Эндпоинты** `GET /lessons` (read-only, фильтры), `POST /lessons` (ручная запись,
+   `source="manual"`), `POST /lessons/{id}` (update — доклассификация `unknown`), + read-only ключ
+   `"lessons": snapshot()` в `GET /queue`. При выключенном флаге → `{"enabled": false}`.
+
+**Инвариант (нерушимый):** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи
+(`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`) /
+схемы существующих таблиц — **байт-в-байт не тронуты**. Журнал не влияет на продвижение по стадиям.
+
+## Композиция с существующими механизмами
+- **Self-hosting (общая БД):** аддитивная таблица; enduro не затронут (NFR-3).
+- **serial-gate (ORCH-088) / post-deploy (ORCH-021):** детектор `deploy_degraded` врезан рядом с
+  `set_repo_freeze`, не меняя freeze-логику.
+- **merge-gate (ORCH-043/071/093):** `merge_hold`/`transient_retry` читают исход актора, не меняя
+  классификатор/ретрай.
+- **metrics (ORCH-099):** журнал — историческая память петли (best-effort запись), `/metrics` —
+  realtime-сырьё для sidecar; разные роли, оба observer-only.
+
+## Условность и откат
+- Флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`; kill-switch) +
+  `lessons_dedup_window_s` / `lessons_query_limit_default`. `False` → полная инертность, нулевая
+  регрессия, конвейер байт-в-байт прежний.
+- **never-raise** на всех публичных функциях и врезках (NFR-1) — сбой журнала не роняет конвейер.
+- Откат — флаг в `false` (мгновенно) или revert диффа; таблица не касается существующих.
+
+## Последствия
+- **+** Машиночитаемые уроки — фундамент E2/E3/Стрим; атрибуция forward-proof (без передела живой БД).
+- **+** Нулевая регрессия; проверенный additive-observer-leaf шаблон → низкий риск; enduro изолирован.
+- **−** Рост таблицы (митигейшн: лёгкие строки + дедуп + budget-exhaustion; ретенция — будущее).
+- **−** Дедуп-запрос в `record()` (один indexed-SELECT, только `auto`).
+
+## Ссылки
+- Локальный ADR: `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-098/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+- Data/Infra/Risks: `docs/work-items/ORCH-098/08-data-requirements.md`, `07-infra-requirements.md`,
+  `10-tech-risks.md`
+- Эпик: `docs/epics/self-evolution.md` (домен 0 «Фундамент», F2; петля 8A)
+- Сверено по коду: `src/serial_gate.py`, `src/coverage_gate.py`, `src/db.py`, `src/stage_engine.py`,
+  `src/merge_gate.py`, `src/agents/launcher.py`, `src/main.py`, `src/qg/checks.py`.

docs/architecture/adr/adr-0035-turnkey-project-onboarding.md

@@ -0,0 +1,80 @@
+---
+work_item: ORCH-009
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0035: Turnkey-онбординг проектов — kit + операторский CLI + runbook (ORCH-009)
+
+## Статус
+Proposed
+
+## Контекст
+
+Подключение нового проекта к оркестратору — ручная археология по разрозненным докам и памяти;
+каждый пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не работает
+вовсе (launcher резолвит `.openclaw/agents/<role>.md` относительно worktree репо задачи); без
+точных имён статусов Plane ветки `Confirm Deploy` (ORCH-059) / `STOP` (ORCH-090) молча не
+активируются (fail-closed); без лейблов `autoApprove`/`autoDeploy`/`Bug` авто-режимы (ORCH-089)
+и багфикс-трек (ORCH-019) молча выключены (fail-safe). Эталон онбординга — **сам репозиторий
+orchestrator** (каноны ORCH-52b/c/d/e кодифицированы в `docs/_templates/`, `docs/_standards/`,
+`.openclaw/agents/`). Домен D5.2 эпика саморазвития: способность разворачивать новый проект
+одним проходом.
+
+## Решение
+
+Способность реализуется **вне рантайма и вне конвейера** — `src/**` байт-в-байт не меняется
+(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД/контракт `projects.py`
+нетронуты), kill-switch не нужен (активация — только явный запуск операторского CLI):
+
+1. **Onboarding-kit `onboarding/repo-skeleton/`** — параметризуемый каркас нового репо:
+   6 промптов агентов канона 52d/92 (5 XML-секций, «❌→✅», эмиссия схемы 52c, verdict-ключи
+   байт-в-байт; язык — канон орка: 5 ru + deployer en), паспорт `CLAUDE.md`, `AGENTS.md`
+   (точка входа агентов), `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/` с
+   обязательным `operations/INFRA.md`, `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер
+   (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция со
+   вхождениями в kit держится тестами). **Канон не форкается:** `docs/_templates/` +
+   `docs/_standards/` НЕ хранятся в kit — копируются live из чекаута орка в момент материализации.
+2. **Операторский CLI `scripts/onboard_project.py`** — `plan` (дефолт, GET-only, ни одной
+   мутации) / `apply` (идемпотентный ensure, без delete-операций) / `verify`. Шаги: Plane-проект →
+   22 статуса с точными именами из `plane_sync._PLANE_NAME_TO_KEY` (read-only импорт — нулевой
+   дрейф; канонические группы фиксированы: `STOP`→`cancelled`, терминальные группы только у
+   Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит) → лейблы → Gitea-репо
+   (+per-repo webhook `push`/`pull_request`/`status`; HMAC-секрет **переиспользуется** из
+   `ORCH_GITEA_WEBHOOK_SECRET` — приёмник один на все репо) → материализация kit + initial push
+   **только в свежесозданный пустой репо** (INV-4 не затрагивается) → merged-вывод
+   `ORCH_PROJECTS_JSON`, провалидированный фактическим `projects._parse_projects_json`
+   (round-trip). Недоступное в Plane CE API → `manual-step` со ссылкой на runbook (fail-safe).
+   Скрипт **никогда** не рестартит прод, не правит `.env`, не пушит в существующие репо, ничего
+   не удаляет.
+3. **Runbook `docs/operations/ONBOARDING.md`** — полный чеклист: предусловия (токены) → скрипт →
+   операторские шаги (env + управляемый рестарт с self-hosting-предупреждением; UI-only Plane) →
+   верификация (`verify` + smoke) → откат. Smoke-контур — **staging (8501, изолированная БД)** +
+   одноразовый sandbox-проект (`SMK`); протокол — «Журнал smoke-прогонов» в runbook.
+
+Анти-дрейф — структурные тесты kit (аналог `tests/test_agent_prompts_canon.py`) + снапшот-тест
+`STAGE_TRANSITIONS`/`QG_CHECKS` (контроль ненарушения `src`). Branch protection `main` новых репо
+**не включается** (ломала бы PR-merge API merge-актора — ложные HOLD класса ORCH-093).
+
+## Последствия
+
+- **+** Новый проект разворачивается одним проходом проверяемо: все слои (Plane-контракты,
+  webhook, промпты, дока, реестр) закрыты скриптом+runbook; тихие деградации ловит `verify`.
+- **+** Нулевой риск рантайма: изменение docs/templates/scripts/tests-only; регресс
+  enduro/orchestrator невозможен по построению; общая БД не читается и не пишется скриптом.
+- **+** Единый эталон без форка: новые репо получают живой канон момента онбординга;
+  обновления канона в них едут обычными PR с reviewer-gate.
+- **−** Регистрация в реестре остаётся операторской (env + управляемый рестарт — Ф-3,
+  сознательное ограничение NFR-2); разрыв «создано, но не зарегистрировано» виден через `verify`.
+- **−** Закрытый список read-only импортов из `src` (`projects._parse_projects_json`,
+  `plane_sync._PLANE_NAME_TO_KEY`, поля `config.settings`) — связь с приватными именами;
+  поломка при рефакторинге видимая (тесты), расширение списка — только через ADR.
+- **Ограничение:** способность ≠ исполнение: онбординг конкретного заказчика — операторская
+  эксплуатация (вне ORCH-009); тиражирование на новый хост — ORCH-10 (вне объёма).
+
+Детально: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
+(D1…D11 — раскладка, плейсхолдеры, copy-vs-template split, импорт src, группы статусов,
+webhook-секрет, формат реестра, smoke-контур, языковая политика, branch protection, форма CLI).

docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md

@@ -0,0 +1,109 @@
+---
+work_item: ORCH-101
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0036: Фундамент тиража платформы — параметризация хоста, секреты, smoke (ORCH-101, 10-common)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5.3 «Масштаб») — тираж платформы для заказчиков-тестеров двумя типами (A Lite /
+B Bundled), оба stateless. Платформа была фактически прибита к хосту `mva154`: четыре места в
+`src/**` обходили конфиг (внешний Gitea-URL в `plane_sync`, HOME + git-идентичности акторов в
+`launcher`/`self_deploy`/`post_deploy`), `docker-compose.yml`/`Dockerfile`/deploy-hook несли
+литералы путей/uid/gid/портов; механизма выпуска нового комплекта секретов и процедуры верификации
+развёрнутой копии не существовало. ORCH-101 (10-common) — общий фундамент обоих типов тиража.
+
+Это сквозное решение: оно задаёт **платформенные конвенции тиража** и трогает блоки, помеченные
+маркерами ORCH-036/ORCH-040/ORCH-058 (по `docs/_standards/TRACEABILITY.md` — сводный ADR вместо
+архео-перечисления). Детальный пакет решений (D1…D10) — work-item ADR:
+`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`.
+
+## Решение
+
+**Принцип: «дефолт = боевое значение».** Каждое хост-специфичное значение читается из конфига
+(`Settings` env `ORCH_*` / compose-интерполяция `${VAR:-default}` / Dockerfile `ARG` /
+shell-default хука) с дефолтом, равным текущему боевому значению. Отсутствие новых переменных =
+байт-в-байт текущее поведение (kill-switch-природа; отдельный функциональный флаг не вводится).
+`src/config.py` и `watchdog/config.py` — единственные легитимные места хост-литералов в коде.
+
+**Новые конфиг-ключи:** `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, `/home/slin`) — HOME всех
+акторских процессов; `agent_git_name` (`claude-bot`) + `git_email_domain` (`mva154.local`) —
+git-идентичности (`<actor>@<domain>`; системные акторы `deploy-finalizer`/`post-deploy-monitor` —
+платформенные литералы); `staging_port` (`ORCH_STAGING_PORT`, `8501`). Ссылки в Plane-комментариях —
+из существующих `gitea_public_url`/`gitea_owner`. Compose-слой — карта `ORCH_HOST_*`/
+`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID` + реюз `ORCH_DEPLOY_*`; порт прод/стейджинг — явные `command:`
+с `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}` / `${ORCH_STAGING_PORT:-8501}` (CMD образа не трогается —
+exec-form + `init: true` сохранены).
+
+**Платформенные конвенции тиража (нормативно):**
+1. **`SELF_HOSTING_REPO = "orchestrator"` — константа, не конфиг.** На ней «empty CSV →
+   self-hosting only» всех `*_repos`-leaf'ов; конфигурируемость превращала бы опечатку env в
+   активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов. Репо платформы
+   в тираже обязан называться `orchestrator` (REPLICATION.md).
+2. **Имена compose-сервисов/контейнеров/образов, профиль `staging`, `network_mode: host`,
+   контейнерный layout (`/app/data`, `/repos`, `/opt/claude-code`)** — конвенции, не переменные
+   (для образов истина уже в конфиге `deploy_prod_*_image`).
+3. **Staging-порт конфигурируем ТОЛЬКО с fail-closed guard'ом** (усиление инварианта ORCH-058
+   AC-9): freshness-путь отказывает ДО любого ssh/build при
+   `staging_port == deploy_prod_target_port` — без тихого fallback. Explicit-pass таргета хуку
+   (`TARGET_PORT=` и др.) сохранён; добавлена явная передача `REPO=` обоими инвокерами хука
+   (его строка 38 становится `"${REPO:-…}"` — exit-контракт 0/1/2 ORCH-036 не тронут).
+4. **Группа ORCH-040 неделима:** uid/gid/HOME/маунт-таргеты/`useradd` управляются одними env
+   насквозь (`ORCH_RUN_UID/GID`, `ORCH_AGENT_HOME_DIR` → compose `user:`/таргеты/`build.args
+   APP_*`); `group_add` docker-gid («МИНА 1») не удаляется — литерал станет
+   `${ORCH_DOCKER_GID:-999}`.
+
+**Секреты нового хоста:** stdlib-скрипт `scripts/gen_secrets.py` — криптослучайные webhook-секреты
+(`secrets.token_hex(32)`), печать по умолчанию, `--write` отказывает при существующем `.env`
+(перезапись — только явный `--force`); внешние токены (Plane/Gitea/Telegram/watchdog) — по
+чек-листу. Норматив: **боевые секреты текущего хоста не копируются ни на одном шаге**.
+
+**Smoke-верификация тиража:** runbook `docs/operations/REPLICATION.md` (deployment golden source:
+карта env, чек-лист секретов, пошаговый smoke с PASS/FAIL: `compose config` → `/health` →
+`/queue`+`/metrics` → `onboard_project.py plan/apply/verify` → тестовая задача → артефакты `01–04`
+в ветке; расширенно — до `done`; границы 10-common vs Lite vs Bundled). Нового smoke-скрипта нет —
+шаги собраны из существующих кирпичей.
+
+**Анти-регресс (постоянная CI-гарантия):** структурный сканер `tests/test_no_host_hardcodes.py` —
+запрещённые литералы (`82.22.50.71`, `/home/slin`, `mva154`, `duckdns`; список централизован) в
+исполняемом коде `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов;
+структурное исключение двух config-модулей (канон дефолтов); allowlist пуст; негативная
+самопроверка.
+
+### Что НЕ меняется
+`STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД —
+байт-в-байт; значения существующих конфиг-дефолтов; INV-4; прод-контейнер в рамках задачи не
+рестартуется (правки compose/Dockerfile инертны до штатного деплоя через staging 8501 →
+`Confirm Deploy`).
+
+## Альтернативы
+- **`ORCH_SELF_HOSTING_REPO` конфигом** — отвергнуто: узел безопасности; опечатка = групповой риск.
+- **Staging-порт константой** — отвергнуто: compose-порт параметризуется (AC-6), константа дала бы
+  рассинхрон слоёв; пара «ключ + guard» строго сильнее.
+- **Smoke-скрипт-обвязка / генератор в `onboard_project.py`** — отвергнуто: лишняя поверхность;
+  разные жизненные циклы (онбординг проекта ≠ provisioning хоста).
+
+## Последствия
+- Платформа разворачивается на чужой инфре env-конфигурацией; критический путь ORCH-10 разблокирован
+  (Lite/Bundled строятся поверх REPLICATION.md).
+- Инвариант ORCH-058 переходит из «подразумеваемого константой» в исполняемый guard; возврат
+  хост-хардкода ломает CI структурно.
+- Цена: ~13 новых env-имён (на текущем хосте настраивать нечего — дефолты боевые) и правило
+  «интерполяция читает `.env`/shell, не `env_file`» (зафиксировано в REPLICATION.md).
+- Откат: не задавать переменные (дефолты = прежнее поведение); полный — revert PR (без миграций).
+
+## Связи
+adr-0005 (ORCH-040 — uid/HOME/«МИНА 1»; группа становится параметризуемой, инвариант сохранён),
+adr-0008 (ORCH-058 — INV-FRESH/AC-9; guard усиливает), adr-0007 (ORCH-036 — exit-контракт хука
+не тронут), adr-0035 (ORCH-009 — onboarding переиспользуется smoke-процедурой; kit не форкается),
+adr-0001 (`is_self_hosting_repo` — конвенция имени закреплена). Детально —
+`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md` (D1…D10),
+`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0037-lite-replication-canon.md

@@ -0,0 +1,96 @@
+---
+work_item: ORCH-102
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-10
+model_used: claude-opus-4-8
+---
+
+# adr-0037: Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` (ORCH-102, 10a)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **A — Lite**: раздача орк+watchdog заказчику-тестеру, окружение
+(Plane/Gitea/LLM/Telegram) он донастраивает сам. Фундамент 10-common (ORCH-101, adr-0036) в
+`main`: технически платформа разворачивается без правки кода, но операционно знания размазаны по
+4 operations-докам, писанным для оператора НАШЕГО хоста, — заказчик не может развернуть Lite без
+доп-вопросов. Решения Владельца 10.06: оба типа тиража stateless; главный продукт ORCH-102 —
+инструкция-golden-source в репо.
+
+Сквозной характер: вводится новый docs-раздел, новый канонический example-файл и нормативы,
+обязательные для всех будущих задач эпика ORCH-10 и для любого агента, меняющего шаги тиража.
+Детальный пакет решений (D1…D9, исходы вопросов ТЗ А-1…А-6) — work-item ADR:
+`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`.
+
+## Решение
+
+1. **Новый docs-раздел `docs/deployment/` — витрина тиража.** Семантика: `deployment/` — «как
+   развернуть платформу у себя» (читатель — внешний оператор), `operations/` — «как
+   эксплуатировать наш прод». Golden source Lite — **`docs/deployment/LITE_SETUP.md`**:
+   сквозной маршрут «голый хост → работающий конвейер» из 13 нормативных разделов (рамка →
+   предусловия → код → конфиг/секреты → Plane → Gitea → LLM → Telegram → запуск → онбординг →
+   smoke → stateless-проверка → траблшутинг); каждый шаг = fenced-команда + явная проверка
+   (PASS/FAIL); хост-специфика — только плейсхолдеры. Канон не форкается: статусы/env/вебхуки —
+   ссылками на ONBOARDING/REPLICATION/SETUP_WEBHOOKS (`REPLICATION.md` остаётся в
+   `operations/`; перекрёстные ссылки в обе стороны). **Норматив сопровождения:** изменение
+   шагов тиража → обновление LITE_SETUP.md в том же PR (правило агентов №2).
+2. **Compose не форкается.** `docker-compose.yml` сам является Lite-подмножеством (ровно
+   `orchestrator` + `orchestrator-watchdog` + `orchestrator-staging` за `profiles: [staging]`;
+   дефолтный `up -d` поднимает орк+watchdog; сервисов Plane/Gitea нет) — отдельный
+   `docker-compose.lite.yml` не вводится; свойство становится CI-гарантией (структурный тест
+   через `yaml.safe_load`).
+3. **`.env.watchdog.example` — третий канонический env-example** (рядом с `.env.example`/
+   `.env.staging.example`): закрывает ловушку файла-носителя (sidecar читает ТОЛЬКО
+   `.env.watchdog`; ключ `WATCHDOG_*` в `.env` для него инертен). Key-set = ровно блок
+   `WATCHDOG_*` из `.env.example` (равенство множеств держит тест); токены — плейсхолдеры;
+   шапка несёт C-1 ORCH-100 (отдельный watchdog-бот, токен орка переиспользовать запрещено)
+   и когерентность `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`.
+4. **Норматив тиражной инсталляции Gitea: branch protection на `main` НЕ включать; pre-receive
+   хуки не вводятся** (подтверждение ORCH-009 ADR-001 D10 для чужих инсталляций:
+   required-approvals/status-checks ломают PR-merge API merge-актора → ложные HOLD; защита
+   `main` — конвенция + скоуп токенов + INV-4).
+5. **Staging-контур в Lite опционален:** базовый контур заказчика = prod-оркестратор + watchdog;
+   песочница 8501 нужна только при self-hosting развитии платформы у заказчика (регистрация
+   проекта `orchestrator`); guard ORCH-058 (staging-порт ≠ прод-порт) действует.
+6. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_lite_setup_doc.py` (структурный, без
+   сети/LLM): разделы/кирпичи дока, env-ключи дока ⊂ `.env.example`, key-sync watchdog-example,
+   compose-подмножество, stateless-норматив + отсутствие секретов/боевых литералов в
+   fenced-блоках (реюз центрального `FORBIDDEN` из `tests/test_no_host_hardcodes.py` импортом),
+   перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
+
+### Что НЕ меняется
+`src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**`; `STAGE_TRANSITIONS`, состав
+`QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД — байт-в-байт. Новый QG не
+регистрируется (структурные тесты попадают в существующие гейты). Прод-контейнер в рамках
+задачи не рестартуется (выкат — штатно: staging 8501 → `Confirm Deploy`).
+
+## Альтернативы
+- **Инструкция в `docs/operations/`** — отвергнуто: другой целевой читатель; путь зафиксирован
+  Владельцем (D-4).
+- **`docker-compose.lite.yml`** — отвергнуто: вторая правда о сервисах = дрейф-поверхность.
+- **Pre-receive/branch protection как «защита `main`»** — отвергнуто: класс инцидента ORCH-063
+  (ложные HOLD merge-актора); пересмотр — только отдельным ADR.
+- **Без example-файла watchdog (шаг прозой)** — отвергнуто: двусмысленность файла-носителя
+  остаётся; example + key-sync тест надёжнее.
+
+## Последствия
+- Type A эпика ORCH-10 закрыт продуктом-инструкцией; Type B (Bundled) строится поверх
+  (переиспользует разделы Lite). Полнота инструкции и compose-подмножество защищены CI.
+- Цена: новый golden source требует сопровождения (норматив «в том же PR» + структурный тест
+  рвёт CI при дрейфе); осознанный дубль ключей `WATCHDOG_*` в двух example-файлах — под
+  key-sync тестом.
+- Откат: удалить `docs/deployment/`, тест и `.env.watchdog.example`, вернуть строку
+  REPLICATION.md §1 — состояние 1:1 (docs+tests, без миграций).
+
+## Связи
+adr-0036 (ORCH-101 — фундамент 10-common; этот ADR строит слой Lite поверх), adr-0035
+(ORCH-009 — onboarding-CLI/kit переиспользуются маршрутом §5/§6/§10; D10 подтверждён п.4),
+adr-0033 (ORCH-100 — sidecar-watchdog; C-1 независимый Telegram-канал закреплён в example),
+adr-0008 (ORCH-058 — staging-порт guard, вилка staging п.5), adr-0027/INV-4 (merge-актор —
+основание запрета branch protection). Детально —
+`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`,
+`docs/work-items/ORCH-102/10-tech-risks.md`.

docs/architecture/adr/adr-0038-bundled-replication-canon.md

@@ -0,0 +1,114 @@
+---
+work_item: ORCH-103
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# adr-0038: Канон Bundled-тиража — `deploy/bundled/` + bootstrap + `BUNDLED_SETUP.md` (ORCH-103, 10b)
+
+## Статус
+Proposed
+
+## Контекст
+
+Эпик ORCH-10 (D5 «Масштаб»), тип **B — Bundled**: заказчик без собственной инфраструктуры
+получает **весь стек одним комплектом** (орк + watchdog + Gitea + Plane CE ≈13–14 контейнеров) и
+bootstrap, доводящий его до рабочего конвейера одним запуском. Фундамент готов: 10-common
+(ORCH-101, adr-0036 — хост-параметризация/секреты/smoke) и Lite (ORCH-102, adr-0037 — док-канон
+`docs/deployment/`). Корневой `docker-compose.yml` заморожен анти-дрейфом ORCH-102 (ровно 3
+сервиса, запрет подстрок `plane`/`gitea`) → комплект обязан жить отдельным файлом.
+
+Сквозной характер: вводится новый top-level каталог `deploy/` (дистрибутивы развёртывания),
+новый канонический env-example и нормативы, обязательные для будущих задач эпика ORCH-10 и
+любого агента, меняющего шаги тиража. Детальный пакет решений (D1…D11, исходы OQ-1…OQ-7 ТЗ) —
+work-item ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`.
+
+## Решение
+
+1. **Новый top-level каталог `deploy/` — исполняемые дистрибутивы развёртывания** (дополняет
+   `docs/deployment/` — инструкции). Bundled-комплект: **`deploy/bundled/docker-compose.yml`** —
+   один самодостаточный compose всего стека с top-level `name: orchestrator-bundle` (project
+   name = узнаваемый префикс томов/контейнеров; `container_name` не пиннится — нет коллизий с
+   корневым compose на одном хосте). Staging-контур орка в bundle **отсутствует вовсе**; репо
+   `orchestrator` в bundle-инсталляции не регистрируется → self-deploy-машинерия структурно спит
+   (`SELF_HOSTING_REPO`-леафы не матчатся).
+2. **Конфиг-слои:** `deploy/bundled/.env.example` — канон bundle-инфры (committed, плейсхолдеры;
+   key-set-sync тест: каждая `${VAR}`-интерполяция bundle-compose имеет ключ в каноне) → live
+   `deploy/bundled/.env` (авто-чтение compose из project dir — без `--env-file`-футгана; покрыт
+   неякорным `.env` в `.gitignore`); runtime орка/watchdog — **корневые `.env`/`.env.watchdog`
+   ровно по канону Lite** (REPLICATION §2 применим 1:1), в bundle-compose — `env_file:
+   required: false` (первый `up` жив до сборки конфига). **Bootstrap — единственный писатель**
+   всех трёх live-файлов (когерентность дублируемых ключей — механическая). Один факт = одно имя
+   (ORCH-101 D1): существующие факты — существующие `ORCH_*`-имена; bundle-only — `BUNDLE_*`;
+   внутренние креды Plane — upstream-имена.
+3. **Состав/пиннинг:** Plane CE — зеркало официального selfhost-référence (upstream-имена
+   сервисов/env); Gitea — `gitea/gitea` (не rootless). Пиннинг — **точный неподвижный тег
+   литералом** (не `latest`, не интерполяция; digest не требуется); точные теги фиксирует
+   developer по проверенному стенду; форму держит структурный тест.
+4. **Сеть:** одна именованная bridge-сеть; машинный трафик — строго сервис-DNS
+   (`http://orchestrator:8500/webhook/*`, `http://gitea:3000`, plane-proxy); `network_mode: host`
+   в bundle не используется (ssh-деплой-пути неактивны: `ORCH_DEPLOY_SSH_HOST` пуст). Наружу —
+   только человеческие порты (Plane proxy 8080 / Gitea 3000 / орк 8500; конфигурируемы);
+   БД/брокер/minio не публикуются. Публичные URL — от `BUNDLE_PUBLIC_HOST` (split internal/public
+   уже в конфиге орка). Мина Gitea закрывается явно: `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`.
+5. **Bootstrap `scripts/bootstrap_bundle.py`:** python stdlib-only, без импортов из `src/**`;
+   режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`; step-движок check→ensure
+   (идемпотентность, resume = повторный запуск); exit `0/2/1`. Preflight fail-fast до мутаций
+   (docker/порты/чистота томов по префиксу/RAM/диск; Claude CLI — warning). **Кирпичи не
+   дублируются:** секреты — субпроцесс `gen_secrets.py`; статусы/лейблы/репо/вебхуки — строго
+   `onboard_project.py apply`+`verify` (host-venv, канон ONBOARDING). Init Gitea — полностью
+   автоматом (CLI в контейнере; branch protection НЕ настраивается — D10 ORCH-009/adr-0037 п.4);
+   init Plane CE — честные **manual-step чекпоинты** (инструкция → подтверждение →
+   API-верификация; прогрессивная автоматизация разрешена без смены контракта). Git-доступ
+   агентов — HTTP token-remote (паттерн `_push_url`); ssh-контур не вводится. Секреты в
+   логи не печатаются; delete-операций в скрипте нет вообще — teardown только документированной
+   процедурой (`BUNDLED_SETUP` §13).
+6. **Док-канон:** `docs/deployment/BUNDLED_SETUP.md` — 14 нормативных разделов по форме
+   LITE_SETUP (fenced-команда + «Проверка:» PASS/FAIL, плейсхолдеры, общие шаги ссылками на
+   LITE_SETUP/ONBOARDING/REPLICATION — канон не форкается), включая «Требования к хосту» с
+   цифрами **по замеру** тестового развёртывания. REPLICATION §1: Type B → ✅ ORCH-103.
+   **Норматив сопровождения:** изменил шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
+7. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_bundle_compose.py` /
+   `test_bundled_setup_doc.py` / `test_bootstrap_script.py` (структурные, без docker/сети/LLM:
+   состав сервисов, заморозка корневого compose, пины, key-set-sync, разделы дока, FORBIDDEN —
+   импортом из `test_no_host_hardcodes.py`, секрет-эвристика, ссылки на кирпичи, отсутствие
+   delete-операций, unit чистых функций preflight/плана, exit-контракт).
+
+### Что НЕ меняется
+`src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**`, `onboarding/**`,
+промпты `.openclaw/agents/**`; `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`,
+machine-verdict ключи, схема БД — байт-в-байт. Kill-switch не вводится (активация — только явный
+запуск оператора на целевом хосте, паттерн ORCH-009). Прод-контейнер в рамках задачи не
+рестартуется; наши данные/секреты не переносятся (stateless, решение Владельца 10.06).
+
+## Альтернативы
+- **Расширение корневого compose (профиль `bundled`)** — отвергнуто: заморожен анти-дрейфом
+  ORCH-102/нормативом «compose не форкается»; смешение дистрибутива с боевым контуром.
+- **Include-композиция / live-env через `--env-file`** — отвергнуто: лишние степени свободы
+  запуска, молчаливые дефолты при забытом флаге.
+- **Орк в bundle на host-network + `host-gateway`** — отвергнуто: хост-сеть нужна была
+  ssh-деплой-контуру нашего хоста, который в bundle спит; bridge даёт чистые двунаправленные
+  сервис-DNS-URL.
+- **Digest-пиннинг / rootless-Gitea / ssh-доступ агентов / bash-bootstrap / reset-режим
+  скрипта** — отвергнуты (см. work-item ADR-001, «Альтернативы»).
+
+## Последствия
+- Эпик ORCH-10 закрыт по обоим типам: A (Lite, инструкция) + B (Bundled, комплект); заказчик
+  без инфраструктуры разворачивает конвейер «под ключ».
+- Цена: пиннованные версии Plane/Gitea стареют (апгрейд — отдельные задачи); manual-step Plane CE
+  размывают «одну команду» — неустранимо честно (нет API), митигировано контрактом чекпоинта;
+  двойной `.env`-слой — под единственным писателем-bootstrap и key-sync тестом.
+- Откат: удалить `deploy/`, bootstrap, BUNDLED_SETUP.md, три тест-модуля, строку REPLICATION §1 —
+  состояние 1:1 (docs+scripts+tests, без миграций).
+
+## Связи
+adr-0036 (ORCH-101 — фундамент 10-common: параметризация, gen_secrets, REPLICATION/smoke),
+adr-0037 (ORCH-102 — док-канон `docs/deployment/`, compose-подмножество, запрет branch
+protection), adr-0035 (ORCH-009 — onboarding-CLI: 22 статуса, manual-step паттерн, `_push_url`,
+D10), adr-0027/INV-4 (merge-актор — основание норматива Gitea), adr-0001
+(`SELF_HOSTING_REPO`-конвенция — почему self-гейты в bundle спят). Детально —
+`docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
+`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0039-system-overview-docs-canon.md

@@ -0,0 +1,95 @@
+---
+work_item: ORCH-011
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-11
+model_used: claude-opus-4-8
+---
+
+# adr-0039: Витрина системы `docs/overview/` — единая точка входа (бизнес + тех) и канон презентации (ORCH-011)
+
+## Статус
+Proposed
+
+## Контекст
+
+Документация платформы богатая, но фрагментированная: паспорт `CLAUDE.md` (реестр доработок),
+тех-витрина `README.md`, vision `docs/PRODUCT_VISION.md`, инженерный справочник
+`docs/architecture/` (~1246 строк + internals), 38 сквозных ADR, стандарты, операционные и
+deployment-доки. Единой точки входа «бизнес + тех» для трёх аудиторий (заказчик / менеджер /
+разработчик) нет; презентацию о возможностях собирать не из чего. С тиражируемостью
+(ORCH-101/102/103) появился внешний читатель. Решения Владельца: слайды PowerPoint в тёмном
+дизайне; единое место — `docs/`; витрина поддерживается актуальной.
+
+Живые доказательства проблемы в самом репо: схема конвейера в `PRODUCT_VISION.md` §2 устарела
+(нет `deploy-staging`/`cancelled`); `docs/PRODUCT_VISION.pptx` закоммичен **без пути генерации**
+(невоспроизводим). Reviewer-ось обзорных доков (ORCH-079, adr-0023) по букве привязана к
+`README.md` «Известные ограничения» — новую витрину не покрывает.
+
+Сквозной характер: вводится новый docs-раздел с нормативом сопровождения, обязательным для
+**всех будущих функциональных PR**, расширяется reviewer-ось и фиксируется канон
+презентационных артефактов. Детальный пакет решений (D1…D9, исходы OQ-1…OQ-5) — work-item ADR:
+`docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`.
+
+## Решение
+
+1. **Новый docs-раздел `docs/overview/` — витрина системы.** Семантика разделов после ORCH-011:
+   `overview/` — «что это за система и как устроена» (вход для любой аудитории), `architecture/`
+   — инженерный справочник, `deployment/` — «как развернуть у себя», `operations/` — «как
+   эксплуатировать наш прод», `_standards/` — нормативы агентов. Состав — плоский каталог,
+   10 файлов: индекс `README.md` (точка входа, 3 маршрута аудиторий, норматив сопровождения),
+   `business.md` (бизнес-уровень: проблема → решение → способности → ценность → сценарии; без
+   жаргона; числа только с подтверждением), 7 файлов `tech-*.md` = 7 блоков контент-карты
+   (архитектура / конвейер / агенты / модель объектов / интеграции / качество-безопасность /
+   наблюдаемость), `presentation.md` (слайдо-источник).
+2. **Link-first, канон не форкается:** витрина даёт цельную картину и ссылается на golden
+   sources за деталями; запрещён дубль живых таблиц (компоненты, env, статусы). Разрешённый
+   дубль — только машинно-сверяемый тестом факт: стадии/гейты/агенты derive-тестами из
+   `STAGE_TRANSITIONS`/`QG_CHECKS`/glob промптов (прецедент key-sync ORCH-102).
+3. **Канон презентации:** источник — `presentation.md` (машинно-парсимая слайдо-структура
+   `## Слайд N:` + тезисы, 14–18 слайдов); генератор — `scripts/build_presentation.py` на
+   python-pptx (тёмная тема, редактируемый текст, кириллица), запуск **только вне рантайма**
+   (dev-venv, явный запуск человеком — паттерн ORCH-009); зависимость в
+   `requirements*`/`Dockerfile` НЕ попадает (машинный гард в тестах). **Собранный `.pptx` в git
+   не коммитится** (источник истины — markdown + скрипт; существующий `PRODUCT_VISION.pptx` не
+   трогается, но прецедентом не является).
+4. **Норматив сопровождения (кросс-каттинг):** «изменил функциональность платформы → обнови
+   витрину `docs/overview/` в том же PR» — в индексе витрины и `CLAUDE.md` (правило агентов №2);
+   **reviewer-ось обзорных доков ORCH-079 расширяется** точечной врезкой в
+   `.openclaw/agents/reviewer.md`: функциональность из витрины изменена, витрина не обновлена →
+   finding ≥ P1 (расширение трактовки той же оси; канон 52d и verdict-ключи — байт-в-байт;
+   анти-регресс `test_agent_prompts_canon.py`).
+5. **Анти-дрейф — `tests/test_system_docs.py`** (структурный, без сети/LLM/subprocess, паттерн
+   `test_lite_setup_doc.py`): наличие/непустота 10 файлов; маршруты и норматив в индексе;
+   сверка стадий и имён гейтов импортом из кода; полнота 6 агентов glob'ом промптов; валидность
+   относительных ссылок; полнотекстовый FORBIDDEN-скан (импорт из `test_no_host_hardcodes.py`)
+   + секрет-эвристика; парс слайдо-источника функцией самого генератора; чистота
+   `requirements*`/`Dockerfile` от pptx; указатели README/CLAUDE/CHANGELOG. Новый QG НЕ
+   регистрируется — тесты исполняются существующими гейтами.
+
+Рантайм байт-в-байт: `src/**`, compose, Dockerfile, `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
+machine-verdict/схема БД — не тронуты; kill-switch не нужен (доки и dev-скрипт конвейером не
+исполняются).
+
+## Последствия
+
+- **+** Закрывается корневая фрагментация: одна точка входа для трёх аудиторий; презентация
+  собирается за одну команду из версионируемого источника; машинно-проверяемые факты витрины —
+  CI-гарантии.
+- **+** Нулевой риск рантайма; для enduro-trails инертно.
+- **−** Новый golden source = обязанность каждого функционального PR (в этом смысл задачи);
+  митигировано link-first + derive-тестами + reviewer-осью.
+- **−** Точечная правка промпта reviewer — поверхность канона 52d; держится анти-регресс
+  тестами.
+- **Откат:** удалить `docs/overview/`, тест-модуль, скрипт, вернуть точечные правки указателей
+  и промпта — 1:1, без миграций и состояния.
+
+## Ссылки
+
+- Детально: `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md` (D1…D9),
+  `docs/work-items/ORCH-011/10-tech-risks.md`
+- BRD/TRZ/AC: `docs/work-items/ORCH-011/01-brd.md` / `02-trz.md` / `03-acceptance-criteria.md`
+- Соседние каноны: adr-0019 (стандарт доков), adr-0021 (канон промптов 52d), adr-0023
+  (ось обзорных доков ORCH-079 — расширяется), adr-0029 (порядок под-гейтов), adr-0037/0038
+  (deployment-каноны)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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