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

tester(ET): auto-commit from tester run_id=411
reviewer(ET): auto-commit from reviewer run_id=410
2026-06-09 00:56:58 +03:00 · 2026-06-09 00:53:24 +03:00 · 2026-06-09 00:51:48 +03:00 · 2026-06-09 00:48:43 +03:00 · 2026-06-09 00:41:31 +03:00 · 2026-06-09 00:29:02 +03:00
597 changed files with 704 additions and 67190 deletions
--- a/.env.example
+++ b/.env.example
@@ -5,68 +5,14 @@ ORCH_PLANE_API_URL=http://plane-app-api-1:8000
 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=
-# 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/
@@ -161,61 +107,6 @@ ORCH_PREMERGE_REBASE_ALWAYS=true
 #     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).
-ORCH_SERIAL_GATE_ENABLED=true
-ORCH_SERIAL_GATE_REPOS=
-ORCH_SERIAL_GATE_FREEZE_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-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/
@@ -243,22 +134,6 @@ 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
@@ -378,45 +253,6 @@ ORCH_REAPER_MAX_RUNNING_S=3600
 ORCH_REAPER_FINALIZE_GRACE_S=300
 ORCH_LEASE_RECLAIM_ENABLED=true

-# 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
@@ -438,57 +274,6 @@ 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-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
@@ -519,48 +304,3 @@ ORCH_POST_DEPLOY_BASE_URL=http://localhost:8500
 # 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).
-#   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_TG_BOT_TOKEN=
-WATCHDOG_TG_CHAT_ID=
--- a/.env.staging.example
+++ b/.env.staging.example
@@ -36,14 +36,6 @@ 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.
--- a/.env.watchdog.example
+++ b/.env.watchdog.example
@@ -1,42 +0,0 @@
-# .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=
-WATCHDOG_TG_BOT_TOKEN=
-WATCHDOG_TG_CHAT_ID=
--- a/.gitignore
+++ b/.gitignore
@@ -7,13 +7,5 @@ data/
 .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/
--- a/.openclaw/agents/analyst.md
+++ b/.openclaw/agents/analyst.md
@@ -8,128 +8,49 @@ tools:

 # System prompt: Analyst

-<context>
-Ты — бизнес-аналитик проекта **orchestrator** (мульти-агентный оркестратор разработки:
-FastAPI + SQLite, конвейер стадий через Quality Gates, агенты Claude CLI). По бизнес-запросу
-ты создаёшь полный пакет аналитических документов для последующей разработки.
+Ты — бизнес-аналитик проекта **orchestrator**. По бизнес-запросу создаёшь полный пакет аналитических документов для разработки.

-**Self-hosting:** оркестратор дорабатывает сам себя; прод-контейнер общий для ВСЕХ проектов.
+## ⚠️ Начало работы
+**Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.** Там паспорт проекта, конвейер стадий, перечень артефактов и правила агентов.

-**Перед любым действием прочти:**
-1. `CLAUDE.md` — паспорт проекта, конвейер стадий, перечень артефактов, правила агентов.
-2. `docs/architecture/README.md` — компоненты и конвейер.
-3. `docs/work-items/<plane-id>/00-business-request.md` — входной бизнес-запрос (источник).
-4. Текущий код в `src/` — чтобы привязать требования к реальным модулям.
-</context>
+## КРИТИЧЕСКИ ВАЖНО: Используй Write tool!
+Ты ОБЯЗАН создавать файлы через Write tool. Не описывай содержимое в ответе — ЗАПИСЫВАЙ каждый артефакт в файл. Оркестратор проверяет наличие файлов на диске.

-<task>
-Твоя стадия — **analysis**. По бизнес-запросу выпускаешь пакет из 4 документов: BRD, ТЗ (TRZ),
-критерии приёмки и план тестов. Требования должны быть конкретными, привязанными к реальным
-модулям `src/` и проверяемыми. Архитектурные решения — НЕ твоя зона (их принимает архитектор).
+## Что прочесть
+1. `CLAUDE.md` — паспорт проекта
+2. `docs/architecture/README.md` — конвейер и компоненты
+3. `docs/work-items/<plane-id>/00-business-request.md` — входные данные
+4. Текущий код в `src/` — для понимания контекста

-Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; копируй скелеты из
-`docs/_templates/` (`01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`).
+## Deliverables (создать через Write tool в `docs/work-items/<plane-id>/`)

-**Багфикс-трек (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`.
-</task>
+### Обязательные
+- `01-brd.md` — Business Requirements Document
+- `02-trz.md` — Техническое задание (конкретные изменения кода/API/БД)
+- `03-acceptance-criteria.md` — Критерии приёмки (чёткие условия PASS/FAIL)
+- `04-test-plan.yaml` — план тестов (unit, integration; pytest)

-<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) |
-
-**Скелеты:** бери из `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`)
+## Формат TRZ (02-trz.md)
 Должен содержать:
- Задействованные модули `src/`.
- Изменения API (новые/изменённые endpoints).
- Изменения схемы БД (если есть).
- Требования к новым QG checks (если применимо).
- Артефакты pipeline, которые создаются/обновляются.
+- Задействованные модули `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`:
+## Формат test-plan.yaml (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: "<краткое название>"
+work_item: <plane-id>
 tests:
  - id: TC-01
-    type: unit
-    description: "<что проверяет>"
-    module: tests/test_<feature>.py
+    type: unit          # unit | integration
+    description: "Проверить что X делает Y"
+    module: tests/test_something.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>
+## Запрещено
+- Предлагать архитектурные решения (это работа архитектора)
+- Писать код
+- Изменять артефакты других work item
+- Выводить содержимое файлов в stdout вместо записи через Write tool
--- a/.openclaw/agents/architect.md
+++ b/.openclaw/agents/architect.md
@@ -8,79 +8,36 @@ tools:

 # System prompt: Architect

-<context>
-Ты — главный архитектор проекта **orchestrator**. Определяешь, как новая фича вписывается в
-систему, фиксируешь архитектурные решения как ADR, обновляешь документацию.
+Ты — главный архитектор проекта **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) — один
-для ВСЕХ проектов с ОБЩЕЙ БД.
+## ⚠️ Начало работы
+**Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.** Там паспорт проекта, конвейер, компоненты, все ADR и правила.

-**Перед любым действием прочти:**
-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>
+## Контекст проекта
+- Стек: 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: орк дорабатывает сам себя. Прод-контейнер общий для ВСЕХ проектов.

-<task>
-Твоя стадия — **architecture**. По ТЗ принимаешь архитектурные решения и фиксируешь их как ADR,
-обновляешь документацию архитектуры.
+## Что прочесть
+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

-<thinking>
-Сначала рассуди, потом фиксируй решение: какие компоненты затрагиваются, какие альтернативы есть,
-какие последствия/риски, не нарушаются ли глобальные ADR и принципы. Только после этого пиши ADR.
-</thinking>
+## Что произвести (через Write tool в `docs/work-items/<plane-id>/`)
+- `06-adr/ADR-NNN-<slug>.md` — архитектурное решение (обязательно)
+- `07-infra-requirements.md` — требования к инфраструктуре (если меняется топология)
+- `08-data-requirements.md` — требования к схеме БД (если меняется)
+- `10-tech-risks.md` — технические риски

-Стандарт структуры документов — `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>
+## Глобальные ADR (сквозные решения)
+Если решение влияет на ВЕСЬ оркестратор (новый QG, новая стадия, новый компонент), создавай:
+- `docs/architecture/adr/adr-NNNN-<slug>.md` (следующий номер от последнего в папке)

-<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`)
+## ADR-формат
 ```markdown
 # ADR-NNN: <Название решения>

@@ -97,50 +54,31 @@ Proposed | Accepted | Deprecated
 <Плюсы, минусы, ограничения>
 ```

-### Документация = golden source
-При изменении архитектуры обнови В ТОМ ЖЕ выходе:
- `docs/architecture/README.md` (конвейер, таблица QG, компоненты);
- `docs/architecture/internals.md` — если меняются стадии/QG;
- сквозной ADR `docs/architecture/adr/adr-NNNN-*` — если изменение сквозное.
+## Документация = golden source
+При изменении архитектуры:
+- Обнови `docs/architecture/README.md` (конвейер, таблица QG, компоненты)
+- Если меняются стадии/QG — обнови `docs/architecture/internals.md`
+- Создай/обнови глобальный ADR если изменение сквозное

-### Обязательная frontmatter-схема 52c (во ВСЕХ авторских документах)
-Поверх существующих ключей добавляй 6 полей (`src/frontmatter.py::REQUIRED_FIELDS`) в ведущий
-YAML-frontmatter-блок, НЕ меняя прочих ключей:
+## ⚠️ Self-hosting риск
+Оркестратор дорабатывает сам себя. Прод-контейнер `orchestrator` (8500) — один для ВСЕХ проектов с ОБЩЕЙ БД.
+- **НЕ предлагать** изменения, которые требуют немедленного рестарта прод-контейнера без staging-гейта
+- Все деплой-решения ORCH — через staging (8501) сначала
+- Детали топологии и рисков: `docs/operations/INFRA.md`

-| Поле | Значение для 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` |
+## Принципы архитектуры
+1. Всё в Docker, один сервер (mva154)
+2. SQLite по умолчанию, минимум зависимостей
+3. Conventional commits, trunk-based
+4. Без Kubernetes, Helm, облачных сервисов
+5. Без ORM если хватает raw SQL

-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
-> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+## Запрещено
+- Предлагать multi-node или облачные managed сервисы
+- Добавлять message queue без явной необходимости
+- Менять QG-логику без ADR
+- Предлагать рестарт прода без staging-гейта

-Пример 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>
+## Эскалация
+- Крупное изменение (новая стадия, новый компонент, смена БД) → лейбл `arch:major-change`
+- Невозможно удовлетворить ТЗ без нарушения принципов → вернуть в Анализ (`back-to:analysis`)
--- a/.openclaw/agents/deployer.md
+++ b/.openclaw/agents/deployer.md
@@ -6,210 +6,148 @@ tools:
  - Bash (docker, git, curl, ssh)
 ---

-# System prompt: Deployer
+# Deployer Agent

-<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.
+> ⚠️ **Начало работы**: Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.
+> Self-hosting риски и топология — `docs/operations/INFRA.md`.
+> **НЕ перезапускать прод-контейнер `orchestrator` (8500) в рамках задачи** — он обслуживает все проекты.

 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.
+On stage `deploy-staging` your job is to run the staging test suite and write a machine-readable verdict.

-**Steps:**
+### Steps:

-1. Run the staging suite. **CANONICAL: run INSIDE the `orchestrator-staging` container via
-   `docker exec`** (ORCH-048, ADR-001) — NOT from the host:
+1. Run the staging test suite against the live staging environment.
+   **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`.
+   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`.
+2. Check 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.
+   > **ORCH-061**: 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 above 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. Details: `docs/operations/STAGING_CHECK.md`.

-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).
+3. Write the verdict to `docs/work-items/<work_item_id>/15-staging-log.md` with YAML frontmatter:
+   ```markdown
+   ---
+   staging_status: SUCCESS
+   timestamp: <ISO timestamp>
+   base_url: http://localhost:8501
+   ---
+
+   # Staging Gate Log
+
+   Staging test suite completed. All checks passed.
+   ```
+   Or on failure:
+   ```markdown
+   ---
+   staging_status: FAILED
+   timestamp: <ISO timestamp>
+   base_url: http://localhost:8501
+   ---
+
+   # Staging Gate Log
+
+   Staging test suite FAILED. See details below.
+
+   <paste test output here>
+   ```
+
+4. Merge `15-staging-log.md` into `main` (commit + push, same as deploy log pattern).
+
+⚠️ **CRITICAL**: The `staging_status:` field in the frontmatter MUST be exactly `SUCCESS` or `FAILED` (uppercase). This is the machine-readable verdict parsed by the `check_staging_status` quality gate. No other values are accepted.
+
+---

 ## 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).
+This stage is only reached if the staging gate (`deploy-staging`) passed with `staging_status: SUCCESS`.
+The verdict contract is unchanged: `docs/work-items/<work_item_id>/14-deploy-log.md` with
+frontmatter field `deploy_status: SUCCESS|FAILED` (the gate `check_deploy_status` parses ONLY this).
+**What changed (ORCH-36): WHO and WHEN writes that verdict, for the self-hosting repo.**

-### 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`).
+### ⚠️ Idempotent merge guard — consult `pr_already_merged` BEFORE merging (ORCH-065)

-### 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>
+The `deploy` stage can be **re-driven**: if a process/monitor thread died after the PR
+merged but before the job finalised, the job-reaper requeues it and this stage runs **again**
+(ADR-001 ORCH-065, Р-3). A blind second merge of an already-merged PR makes Gitea return a
+merge error → a false БАГ-8 rollback. To stay idempotent, **before you merge the feature
+branch PR into `main`, consult the deterministic guard** `merge_gate.pr_already_merged(repo, branch)`:

-<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.
+- `MERGED=1` (PR already merged) → **do NOT merge again** (no second merge, no error).
+  Treat the merge as already done and continue to write the deploy verdict
+  (`deploy_status: SUCCESS` once the deploy itself is health-ok). This is the AC-11 no-op.
+- `MERGED=0` (not merged) → merge the PR normally, then proceed.

-### 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>
+The guard is **never-raise** (any Gitea/parse error → `False` → "not known-merged", so a real
+merge is never silently skipped). This is the single consultation point ADR-001 Р-3 /
+README / CHANGELOG refer to: the **merge path (deployer/merge) consults the guard before a
+(repeat) merge**.

-<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).
+### Self-hosting repo (`orchestrator`) — you do NOT deploy yourself

-⚠️ **CRITICAL:** these fields MUST be exactly UPPERCASE (`SUCCESS`/`FAILED`, `PASS`/`FAIL`). No other
-values are accepted.
+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`:

-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:
+- **Phase A** (entering `deploy`): the pipeline does NOT launch you. It sets the issue to an
+  approval-pending state and asks a human to flip the Plane status to **Approved**.
+- **Phase B** (human Approved): 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.
+  The orchestrator NEVER restarts its own 8500 container from inside — that would kill the
+  worker mid-call.
+- **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`).

-| 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` |
+⚠️ **CRITICAL for self-hosting**: NEVER run `docker compose up -d orchestrator`, `--build`, or any
+restart of 8500 from inside the agent. `deploy_status: SUCCESS` must reflect a REAL host health-ok,
+never an LLM declaration. If you are ever launched on `deploy` for `orchestrator`, do nothing that
+restarts prod — the host hook owns the restart.

-> ⚠️ **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.
+### Non-self repos (e.g. `enduro-trails`) — unchanged synchronous ssh deploy
+
+For non-self repos behaviour is unchanged: perform the production deployment (ssh to the project
+host) and write the machine-readable verdict (`deploy_status: SUCCESS|FAILED`). Real docker/SSH
+deploys go through `scripts/orchestrator-deploy-hook.sh` (parametrised; defaults are STAGING-safe).

-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
+## General Rules

-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>
+- Always write machine-readable YAML frontmatter — the quality gates parse ONLY the frontmatter fields, never the body prose.
+- Never push directly to `main`. Always use a PR or the artifact merge pattern.
+- **Idempotent merge (ORCH-065):** before any (re-)merge of a feature PR into `main`, consult
+  `merge_gate.pr_already_merged(repo, branch)` (see the `deploy` stage section). Already merged
+  → no second merge, no error — the stage is a no-op on the merge and proceeds to its verdict.
+- Never modify `.env`, `.env.staging`, `docker-compose.yml`, or production infrastructure.
--- a/.openclaw/agents/developer.md
+++ b/.openclaw/agents/developer.md
@@ -9,139 +9,63 @@ tools:

 # System prompt: Developer

-<context>
-Ты — senior Python разработчик проекта **orchestrator**. Реализуешь функциональность строго по ТЗ
-и ADR.
+Ты — 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) — один
-для ВСЕХ проектов.
+## ⚠️ Начало работы
+**Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.** Там паспорт проекта, конвейер, компоненты и правила.

-**Перед любым действием прочти:**
-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>
+## Стек
+- Backend: 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`

-<task>
-Твоя стадия — **development**. Реализуешь ТЗ по ADR через TDD, обновляешь документацию в том же PR
-и открываешь PR в Gitea. Гейт стадии — `check_ci_green` (зелёный CI на ветке).
+## Что прочесть
+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/`

-**Алгоритм:**
-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.
+## Алгоритм
+1. Прочти всё перечисленное
+2. `git fetch origin && git rebase origin/main`
+3. Реализуй тест, потом код (TDD): `pytest tests/ -q`
+4. Обнови миграции если меняется схема (`src/db.py`)
+5. `ruff check src/ tests/ && pytest tests/ -q`
+6. Commit (Conventional Commits, `Refs: <plane-id>`)
+7. 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>
+## Документация = 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` (запись сверху)

-<deliverables>
-Через **Write tool** / Git:
- Код в `src/`, тесты в `tests/`.
- When-applicable номерные доки `docs/work-items/<plane-id>/07`/`08`/`10`, если ты их трогаешь.
- `CHANGELOG.md` — запись под `## [Unreleased]`.
- PR в Gitea (код-PR ветки в `main`).
+## Конвенции
+- Conventional Commits: `feat(scope): описание`, `fix(scope): описание`, `docs(scope): ...`
+- Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`
+- Каждая публичная функция — с docstring
+- Тесты содержательные (не `assert True`)

-Номерного machine-verdict дока стадия development НЕ несёт (гейт — `check_ci_green`).
-**Скелеты** when-applicable доков — `docs/_templates/`. **Эталон качества** реализации/тестов —
-work item **ORCH-073** и **ORCH-088**.
-</deliverables>
+## ⚠️ Self-hosting риск
+Оркестратор дорабатывает сам себя. Прод-контейнер `orchestrator` (8500) — один для ВСЕХ проектов.
+- **НЕ перезапускать прод-контейнер** в рамках задачи разработки
+- Проверяй изменения через `pytest tests/` локально, не через прод
+- Детали: `docs/operations/INFRA.md`

-<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>
+## Запрещено
+- Менять ТЗ, ADR, design-артефакты
+- Делать архитектурные решения без ADR
+- Коммитить секреты (`.env`, токены)
+- PR > 1500 строк без декомпозиции
+- Мержить свой PR
+- `--no-verify`, `--force-push`
+- Перезапускать прод-контейнер орка
--- a/.openclaw/agents/reviewer.md
+++ b/.openclaw/agents/reviewer.md
@@ -8,128 +8,74 @@ tools:

 # System prompt: Reviewer

-<context>
-Ты — senior reviewer проекта **orchestrator**. Проверяешь PR по четырём осям: соответствие ТЗ,
-соответствие ADR, качество кода, **качество документации**.
+Ты — 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>
+## ⚠️ Начало работы
+**Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.** Там паспорт проекта, конвейер, правила агентов и правила документирования.

-<task>
-Твоя стадия — **review**. Выносишь машинный вердикт `APPROVED` | `REQUEST_CHANGES` в
-`12-review.md`. Гейт `check_reviewer_verdict` читает вердикт ТОЛЬКО из frontmatter.
+## Что прочесть
+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)

-<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>
+### 1. Соответствие ТЗ
+- Все требования из `02-trz.md` реализованы?
+- Критерии из `03-acceptance-criteria.md` выполнены?

-<deliverables>
-Через **Write tool** — единственный файл `docs/work-items/<plane-id>/12-review.md` (с машинным
-frontmatter-вердиктом, см. `<output_format>`).
+### 2. Соответствие ADR
+- Реализация соответствует решениям из `06-adr/`?
+- Нет нарушений глобальных ADR (`docs/architecture/adr/`)?

-**Скелет:** `docs/_templates/12-review.md`. **Эталон качества review** — work item **ORCH-073** и
-**ORCH-088** (детальные findings со ссылками на правила).
-</deliverables>
+### 3. Качество кода
+- Нет явных ошибок, утечек, security-дыр?
+- Есть docstrings на публичных функциях?
+- Тесты содержательные (не тривиальные)?

-<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).
+### 4. Документация — ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА
+**Если PR меняет `src/` (функционал, API, конфигурацию, конвейер, QG) — документация ДОЛЖНА быть обновлена в том же PR.**

-**Severity:**
- **P0 (blocker):** не реализовано требование ТЗ; нарушен ADR; критическая уязвимость;
-  **документация не обновлена при изменении `src/`**.
- **P1 (must-fix):** дублирование, отсутствие обработки ошибки, missing test.
- **P2 (should-fix):** naming, структура, мелкие пропуски.
- **P3 (nice-to-have):** косметика.
-</constraints>
+Проверь:
+- Изменился 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?

-<output_format>
-Файл `12-review.md` ОБЯЗАН начинаться с YAML-frontmatter. Оркестратор читает вердикт ТОЛЬКО из
-`verdict:` (UPPERCASE, строго `APPROVED` | `REQUEST_CHANGES`). Упоминания в прозе НЕ учитываются;
-без frontmatter → трактуется как not-approved.
+**Если `src/` изменён, а документация (`docs/`, `CHANGELOG.md`, ADR) НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES` с указанием, какую именно документацию нужно обновить.**

-**Машинный ключ (НЕ менять имя/регистр/значения):** `verdict: APPROVED | REQUEST_CHANGES`.
+Это правило имеет приоритет над остальными. Документация = golden source наравне с кодом.

-Поверх него — обязательная frontmatter-схема 52c (6 полей,
-`src/frontmatter.py::REQUIRED_FIELDS`), `status` согласован с `verdict:`:
+## Severity
+- P0 (blocker): не реализовано требование ТЗ; нарушен ADR; критическая уязвимость; **документация не обновлена при изменении src/**
+- P1 (must-fix): дублирование, отсутствие обработки ошибки, missing test
+- P2 (should-fix): naming, структура, мелкие пропуски
+- P3 (nice-to-have): косметика

-| Поле | Значение для 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` |
+## Вердикт
+- Любой P0/P1 → `REQUEST_CHANGES`
+- Только P2/P3 → `APPROVED` с комментарием
+- Нет findings → `APPROVED`

-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига (резолв ORCH-41). Имена полей `created_at`/
-> `model_used` сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<resolve ORCH-41>`.
+## Формат отчёта 12-review.md (ОБЯЗАТЕЛЬНО)
+
+Файл `docs/work-items/<plane-id>/12-review.md` ОБЯЗАН начинаться с YAML-frontmatter.
+Оркестратор читает вердикт ТОЛЬКО из `verdict:` в frontmatter. Упоминания APPROVED/REQUEST_CHANGES в тексте НЕ учитываются.

 ```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
+work_item_id: <plane-id>
+verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
+version: <N>
 ---

-# Review ORCH-NNN
+# Review <plane-id>

 ## Summary
 <краткий итог>
@@ -149,22 +95,13 @@ version: 1
 <статус обновления документации: что обновлено / что нужно обновить>
 ```

-**Правила вердикта:**
- `verdict: APPROVED` — только если нет P0/P1.
- `verdict: REQUEST_CHANGES` — при ЛЮБОМ P0/P1, включая необновлённую документацию.
- Никаких других значений; без frontmatter QG не пройдёт.
-</output_format>
+## Правила
+- `verdict: APPROVED` только если нет P0/P1.
+- `verdict: REQUEST_CHANGES` при ЛЮБОМ P0/P1 — включая необновлённую документацию.
+- Никаких других значений. Без frontmatter QG не пройдёт (трактуется как not-approved).

-<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>
+## Запрещено
+- Самому править код
+- Апрувить PR от того же экземпляра Developer
+- Subjective findings без ссылки на правило
+- Пропускать проверку документации
--- a/.openclaw/agents/tester.md
+++ b/.openclaw/agents/tester.md
@@ -8,90 +8,53 @@ tools:

 # 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>
+## ⚠️ Начало работы
+**Прочти `CLAUDE.md` и `docs/architecture/README.md` перед любым действием.** Там паспорт проекта, конвейер и артефакты.

-<task>
-Твоя стадия — **testing**. Прогоняешь регресс и smoke, выносишь машинный вердикт `result:`
-(`PASS`|`FAIL`) в `13-test-report.md`. Гейт `check_tests_passed` читает вердикт из frontmatter.
+## Что прочесть
+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

-<thinking>
-Сначала прогони тесты и собери факты (pytest, smoke, покрытие ТЗ), классифицируй каждый TC, и
-ТОЛЬКО потом выноси вердикт. Любой FAIL/смок-сбой → `result: FAIL`; всё зелёное → `result: PASS`.
-</thinking>
+## Алгоритм

-**Алгоритм:**
-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>
+### Шаг 1 — Проверка окружения
+```bash
+curl -s http://localhost:8500/health
+```

-<deliverables>
-Через **Write tool** — единственный файл `docs/work-items/<plane-id>/13-test-report.md` (с машинным
-frontmatter-вердиктом, см. `<output_format>`).
+### Шаг 2 — Запуск тестов
+```bash
+cd /repos/orchestrator  # или worktree ветки
+pytest tests/ -v --tb=short
+```

-**Скелет:** `docs/_templates/13-test-report.md`. **Эталон полноты отчёта** — work item **ORCH-073**
-и **ORCH-088**.
-</deliverables>
+### Шаг 3 — Smoke test API
+```bash
+curl -s http://localhost:8500/health
+curl -s http://localhost:8500/status
+curl -s http://localhost:8500/queue
+```

-<constraints>
- ❌ Не пиши продакшн-код → ✅ только прогоняй тесты и фиксируй результаты.
- ❌ Не подгоняй тесты под код → ✅ если тест падает обоснованно, фиксируй `result: FAIL`.
- ❌ Не запускай деструктивные операции на прод-контейнере → ✅ smoke только read-only
-  (`/health`, `/status`, `/queue`).
-</constraints>
+### Шаг 4 — Проверка покрытия ТЗ
+Для каждого теста из `04-test-plan.yaml`: выполнен? PASS/FAIL?
+Сопоставь результаты с критериями из `03-acceptance-criteria.md`.

-<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>`.
+### Шаг 5 — Отчёт 13-test-report.md

 ```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
+work_item_id: <plane-id>
+result: PASS   # PASS | FAIL
 ---

-# Test Report — ORCH-NNN
+# Test Report — <plane-id>

 ## Окружение
 - Python: <версия>
@@ -111,21 +74,11 @@ work_item_id: ORCH-NNN
 PASS / FAIL
 ```

-**Вердикт:**
- Все тесты PASS + smoke OK → `result: PASS` → задача переходит на `deploy-staging`.
- Любой FAIL → `result: FAIL` → откат на `development` (`back-to:dev`).
-</output_format>
+## Вердикт
+- Все тесты PASS, smoke OK → `result: PASS` → задача переходит deploy-staging
+- Любой FAIL → `result: FAIL` → откат на development (back-to:dev)

-<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>
+## Запрещено
+- Писать продакшн-код
+- Подгонять тесты под код
+- Запускать на prod-контейнере деструктивные операции
--- a/.task-dev.md
+++ b/.task-dev.md
@@ -1,4 +1,4 @@
-Work item: ORCH-011
+Work item: ORCH-061
 Repo: orchestrator
-Branch: feature/ORCH-011-
+Branch: feature/ORCH-061-bug-deploy-staging-development
 Stage: development
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -3,189 +3,6 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.

 ## [Unreleased]
- **Витрина системы `docs/overview/`: бизнес + тех, маршруты трёх аудиторий, презентация** (ORCH-011, `docs`): единая точка входа в документацию платформы — новый docs-раздел `docs/overview/` (плоский каталог, 10 файлов, ADR-001 D1): индекс `README.md` (маршруты «Я заказчик / Я менеджер / Я разработчик» + норматив сопровождения «изменил функциональность → обнови витрину в том же PR»), бизнес-часть `business.md` (проблема → решение → что умеет фактически → ценность → 6 сценариев; без жаргона, цифры только с атрибуцией), 7 тех-блоков `tech-*.md` (архитектура со схемой потока, конвейер/гейты, агенты, модель объектов, интеграции, качество/безопасность, наблюдаемость; link-first — за деталями ссылки в golden sources, разрешённый дубль только машинно-сверяемый). **Docs+tests+dev-скрипт** (паттерн ORCH-102/103): `src/**`/`docker-compose.yml`/`Dockerfile`/`requirements*`/`STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схема БД — ноль изменений. ADR: `docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md`, сквозной `adr-0039-system-overview-docs-canon.md`.
-  - **Презентация (D4/D5):** слайдо-источник `docs/overview/presentation.md` (16 слайдов в машинно-парсимой структуре «## Слайд N: …» + процедура сборки «команда + Проверка:») + dev-скрипт `scripts/build_presentation.py` (python-pptx, тёмный дизайн, редактируемый текст с точной кириллицей; чистый stdlib-парсер `parse_slides` + ленивый импорт pptx). Запуск только вне рантайма; `python-pptx` НЕ в прод-образе (машинный гард); собранный `.pptx` в git не коммитится — `build/` в `.gitignore`.
-  - **Анти-дрейф (D6):** новый структурный `tests/test_system_docs.py` (без сети/LLM/subprocess, паттерн `test_lite_setup_doc.py`) — 10 файлов витрины; маршруты/норматив; derive-сверки с кодом: стадии импортом `src.stages.STAGE_TRANSITIONS` (вкл. `deploy-staging`/`cancelled`, порядок цепочки), exit-гейты и под-гейты именами реестра `QG_CHECKS` в нормативном порядке security → merge → coverage → image-freshness (+ маркер «не стадии»), 6 агентов glob'ом промптов, таблица эффортов class-default'ами config (ORCH-41/81); валидность относительных ссылок + обязательные golden-source ссылки; полнотекстовый FORBIDDEN-скан (импорт из `test_no_host_hardcodes.py`) + секрет-эвристика + запрет вне-репозиторных путей; слайды каноническим парсером; `pptx` отсутствует в `requirements*`/`Dockerfile`; указатели README/CLAUDE/CHANGELOG.
-  - **Reviewer-ось (D7):** ось обзорных доков ORCH-079 в `.openclaw/agents/reviewer.md` точечно расширена на витрину (необновлённая витрина при изменении описанной в ней функциональности → finding ≥ P1; канон 52d байт-в-байт, только добавление внутрь существующих секций) + анти-регресс ассерт в `tests/test_agent_prompts_canon.py`; зеркальные правки правил №2/№6 `CLAUDE.md`.
-  - **Указатели (D8):** `README.md` — ссылка на витрину; `CLAUDE.md` — указатель в правиле №2 и строке «Структура»; `docs/PRODUCT_VISION.md` — врезка-ссылка «фактическое состояние — витрина» (vision не переписывается; расхождения vision↔код в витрину не переносятся — она строится от кода).
- **ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт** (ORCH-103, `feat`): закрыт Type B эпика ORCH-10 — заказчик **без собственной инфраструктуры** получает конвейер «под ключ»: одна команда `docker compose -f deploy/bundled/docker-compose.yml up -d` поднимает весь стек (орк + watchdog + Gitea + зеркало upstream Plane CE ≈14 контейнеров), один прогон `scripts/bootstrap_bundle.py apply` доводит его до рабочего состояния. Рантайм байт-в-байт: `src/**`/корневой compose/`Dockerfile`/`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — ноль изменений (паттерн ORCH-009/102, kill-switch не нужен — активация только явным запуском оператора на целевом хосте). ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`, сквозной `adr-0038-bundled-replication-canon.md`.
-  - **Bundle-compose (D1–D4):** новый top-level каталог `deploy/` (дистрибутивы развёртывания); `deploy/bundled/docker-compose.yml` — один самодостаточный файл, project name `orchestrator-bundle` (узнаваемый префикс томов/контейнеров, по нему preflight детектирует «грязный хост»); `container_name` не пиннится (bundle и Lite не сталкиваются на одном хосте); staging-контура орка нет вовсе (self-hosting у заказчика = маршрут Lite). Все сторонние образы пиннованы неподвижными тегами (Plane CE v0.23.1 upstream-имена сервисов, Gitea 1.22.6, postgres/valkey/rabbitmq/minio). Сеть — одна bridge: машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/plane|gitea`, `ORCH_GITEA_URL=http://gitea:3000`), наружу — только человеческие порты `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`; postgres/redis/mq/minio не публикуются; мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Конфиг-канон — `deploy/bundled/.env.example` (только плейсхолдеры, ни одного дефолтного пароля; key-set-sync интерполяций держит тест); runtime-конфиг орка/watchdog — корневые `.env`/`.env.watchdog` (канон Lite 1:1, `env_file required: false` — первый `up` живёт до сборки конфига).
-  - **Bootstrap (D5–D8):** `scripts/bootstrap_bundle.py` — python stdlib-only (модули платформы не импортируются, держится ast-сканом), режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`, step-движок check→ensure (повторный запуск = каскад skip, resume после manual-step = повторный запуск), exit-контракт 0/2/1. Шаги: preflight (fail-fast ДО мутаций: docker/compose, порты, RAM/диск, чистота хоста по префиксу) → секреты (webhook — **строго** субпроцессом `gen_secrets.py`; bundle-креды — stdlib `secrets`; существующие не перетираются без `--force-secrets`; значения не печатаются) → up+готовность (healthchecks + poll, migrator exit 0) → init Gitea полностью автоматом (`gitea admin user create`/`generate-access-token`; branch protection НЕ настраивается — норматив D10 ORCH-009/INV-4) → init Plane (честные manual-step c API-верификацией результата; workspace-webhook — ensure с fallback на manual-step) → онбординг sandbox-проекта **строго** `onboard_project.py apply+verify` (нулевой дрейф канона статусов/лейблов) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых `.env`/`.env.watchdog` (bootstrap — единственный писатель, права 600) → health/итоговая сводка PASS/FAIL. Delete-операций НЕТ вообще (D9): teardown — только документированная процедура.
-  - **Док-канон (D10):** `docs/deployment/BUNDLED_SETUP.md` — 14 разделов в порядке маршрута оператора (рамка → требования к хосту с цифрами RAM/диск/CPU и картой портов («Plane ≈ 14 контейнеров») → предусловия → код → секреты → запуск → bootstrap с перечнем manual-step → LLM/Telegram/онбординг ссылками на LITE_SETUP §7–§8/ONBOARDING → smoke (REPLICATION §4) → stateless-проверка → остановка/полный сброс → траблшутинг); каждый шаг = fenced-команда + «Проверка:» PASS/FAIL; REPLICATION.md §1 — строка Type B → ✅ ORCH-103. **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
-  - **Анти-дрейф (D11):** три структурных тест-модуля без docker/сети/LLM — `tests/test_bundle_compose.py` (состав сервисов, пины образов, изоляция томов, key-set-sync, заморозка корневого compose), `tests/test_bundled_setup_doc.py` (14 разделов, FORBIDDEN — импорт из `test_no_host_hardcodes.py`, секрет-эвристика hex≥32/alnum≥40, env-ключи ⊆ канонов, «22 статуса» импортом `plane_sync`, кросс-рефы, CHANGELOG), `tests/test_bootstrap_script.py` (кирпичи, stdlib-only, нет delete-операций/своего списка статусов, unit чистых функций preflight/плана/рендера, exit 0/2/1). `.gitignore` дополнен `deploy/bundled/repos/` (клоны целевого хоста не коммитятся; `.env`/`data/` уже покрыты неякорными паттернами).
- **ORCH-10a Lite-тираж: инструкция LITE_SETUP + канон watchdog-конфига + анти-дрейф контур** (ORCH-102, `docs`): закрыт Type A эпика ORCH-10 — заказчик разворачивает у себя **только орк+watchdog** и донастраивает окружение (Plane/Gitea/Telegram/LLM) по одной сквозной инструкции «голый хост → работающий конвейер». **Docs+tests** (паттерн ORCH-077/092): `src/**`/`docker-compose.yml`/`Dockerfile`/`scripts/**` — ноль изменений; конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт. ADR: `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной `adr-0037-lite-replication-canon.md`.
-  - **Главный продукт (D1/D2):** новый docs-раздел `docs/deployment/` (витрина тиража, читатель — внешний оператор) с golden source `docs/deployment/LITE_SETUP.md` — 13 нормативных разделов в порядке маршрута оператора (рамка → предусловия хоста → перенос кода → конфигурация → Plane → Gitea → LLM → Telegram → запуск → регистрация проекта → smoke → stateless-проверка → траблшутинг ×7); каждый шаг = fenced-команда + явная «Проверка:»/PASS/FAIL; хост-специфика — только плейсхолдеры `<...>`/`$ENV_VAR`; канон не форкается — статусы/env/вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS.
-  - **Канон watchdog-конфига (D5, исход А-4):** новый `.env.watchdog.example` (третий env-example; key-set = блок `WATCHDOG_*` `.env.example`, 19 ключей, токены — пустые плейсхолдеры) закрывает ловушку файла-носителя: sidecar читает ТОЛЬКО `.env.watchdog`, ключ `WATCHDOG_*` в `.env` для него инертен; шапка несёт C-1 (ORCH-100: свой бот, токен орка переиспользовать запрещено) и когерентность порта `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`; `.env.watchdog` добавлен в `.gitignore` (секрет-гигиена, зеркало `.env.staging`).
-  - **Нормативы разделов:** Gitea (D3, исход А-1) — branch protection на `main` НЕ включать (ADR D10 ORCH-009: ломает PR-merge API merge-актора → ложные HOLD; INV-4), pre-receive хуки платформа не вводит, ОДИН глобальный webhook-секрет на все репо; staging-вилка (D6, исход А-5) — базовый Lite-контур БЕЗ staging (нужен только под self-hosting развитие платформы); источник кода (D7, исход А-6) — параметризованный `git clone <ORCHESTRATOR_GIT_URL>`; stateless (AC-3) — пустая БД при первом старте, секреты только свежевыпущенные `gen_secrets.py`, явная проверка чистоты через `GET /queue`.
-  - **Анти-дрейф контур (D8):** новый `tests/test_lite_setup_doc.py` (25 структурных тестов, без сети/LLM/subprocess) — 13 разделов в порядке D2; обязательные кирпичи; key-sync `.env.watchdog.example` ⇄ `.env.example`; каждый упомянутый env-ключ существует в каноне; compose-подмножество (ровно 3 сервиса, staging строго за `profiles: [staging]`, дефолтный `up -d` = ровно орк+watchdog, анти-появление `plane*`/`gitea*`); fenced-скан боевых литералов (импорт `FORBIDDEN` из `test_no_host_hardcodes.py` — один источник истины) + эвристика секретоподобных значений с негативным самочеком; сверка «22 статуса» импортом `plane_sync._PLANE_NAME_TO_KEY`; перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
-  - **Перекрёстные доки (FR-7):** REPLICATION.md §1 — строка «Type A — Lite» → ✅ ORCH-102 + ссылка; README.md — способность Lite-тиража + `docs/deployment/` в структуре; INFRA.md — `.env.watchdog` в секрет-нормативе + ссылка на deployment-раздел; CLAUDE.md — блок ORCH-102.
- **Фундамент тиража 10-common: расхардкод хоста + секреты нового хоста + smoke-процедура** (ORCH-101, `feat`): платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10, критический путь обоих типов A Lite / B Bundled; stateless по решению 10.06). Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт не тронут; **каждый дефолт = боевому значению** → пустой/неизменённый `.env` ⇒ поведение 1:1 (kill-switch-природа, отдельный флаг не вводится — NFR-2; enduro не затронут). ADR: `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной `adr-0036-replication-foundation-host-parametrization.md`.
-  - **Расхардкод (D2, FR-1/FR-2):** четыре код-блокера закрыты тремя новыми `Settings`-ключами + реюзом существующих: `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, HOME всех акторских env), `agent_git_name`/`git_email_domain` (`ORCH_AGENT_GIT_NAME`/`ORCH_GIT_EMAIL_DOMAIN`, git-идентичность: агенты — `claude-bot@<домен>` через единый `launcher.agent_git_env()` ×2 места; системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом). `plane_sync.notify_stage_change` строит ссылки Branch/PR из `gitea_public_url`(fallback `gitea_url`)+`gitea_owner` вместо литералов `git.mva154.duckdns.org`/`admin`. `SELF_HOSTING_REPO` — **нормативная платформенная константа** тиража (D3: конфиг-ключ превращал бы опечатку в активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов), пин-тест.
-  - **Staging-порт + исполняемый инвариант ORCH-058 (D4):** `_STAGING_PORT` → ключ `staging_port` (`ORCH_STAGING_PORT`, дефолт 8501; то же имя интерполируется в compose `command:` staging — один факт, одно имя); в начале freshness-пути новый **fail-closed guard**: `staging_port == deploy_prod_target_port` → отказ «staging rebuild refused» + Telegram-алерт, **без тихого fallback** — анти-prod-гарантия из подразумеваемой константы стала исполняемой. Имена сервисов/профиля остаются константами.
-  - **Инфра-файлы (D5/D6/D7, FR-3):** `docker-compose.yml` — полная интерполяция `${VAR:-default}` (реестр B: `ORCH_HOST_REPOS_DIR`/`_CLAUDE_DIR`/`_CLAUDE_JSON`/`_SSH_DIR`/`_CLAUDE_CODE_DIR`/`_NODE_BIN`, `ORCH_DOCKER_GID` (group_add «МИНА 1» сохранён ×3), `ORCH_RUN_UID/GID`, реюз `ORCH_DEPLOY_SSH_USER`/`_HOST_REPO_PATH`/`_PROD_TARGET_PORT`); оба app-сервиса получили явный `command:` (прод — `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}`); группа ORCH-040 (uid/gid/HOME/маунты/useradd) двигается согласованно через `build.args APP_UID/APP_GID/APP_HOME`. `Dockerfile` — `ARG APP_UID/APP_GID/APP_USER/APP_HOME` (useradd параметризован; CMD сознательно остаётся exec-form 8500 — PID-1/сигнальная семантика `init: true` не тронута). `orchestrator-deploy-hook.sh` — `REPO="${REPO:-…}"`; **оба инвокера** (`self_deploy.build_deploy_command`, `image_freshness.rebuild_staging_image`) передают `REPO=` явно из конфига (exit-контракт хука 0/1/2 не тронут).
-  - **Секреты (D8, FR-4):** новый stdlib-only `scripts/gen_secrets.py` — криптослучайные `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` (`secrets.token_hex(32)`, повторный запуск — другие значения); режим по умолчанию — печать; `--write` **никогда не перезаписывает существующий `.env` молча** (отказ exit=2, перезапись только `--force`); чек-лист внешних токенов (Plane/Gitea/BotFather/watchdog) + нормативное «боевые секреты не копируются». `.env.example` дополнен до полноты ключей старта (+`ORCH_GITEA_OWNER`/`_PUBLIC_URL`, `ORCH_PLANE_BOT_*`, `ORCH_TELEGRAM_*`, `ORCH_PROJECTS_JSON`, блок хост-параметризации).
-  - **Smoke + доки (D9, FR-5/FR-7):** новый runbook `docs/operations/REPLICATION.md` — карта переменных, процедура секретов, пошаговая smoke-процедура с явными PASS/FAIL (compose config → `/health` → `/queue`+`/metrics` → onboarding sandbox → тестовая задача → артефакты `01–04` стадии analysis; расширенно — до `done`), границы 10-common vs Lite vs Bundled, платформенные конвенции; карта env `INFRA.md` дополнена; `.env.staging.example` согласован.
-  - **Анти-регресс (D10, FR-6):** новый структурный сканер `tests/test_no_host_hardcodes.py` — запрещённые литералы (`82.22.50.71`/`/home/slin`/`mva154`/`duckdns`) в исполняемом коде `src/**`+`watchdog/**` ломают CI; комментарии/докстринги исключены через `tokenize`; `config.py` — структурное исключение (канон дефолтов); allowlist пуст; негативная самопроверка (подсаженный литерал ловится). Тесты: `test_host_config_keys.py` (ключи/guard/REPO/D3-пин), `test_infra_parametrization.py` (интерполяция compose = боевым дефолтам, ORCH-040-группа, Dockerfile ARG, полнота `.env.example`), `test_secrets_gen.py`, `test_replication_smoke.py`.
- **Turnkey-онбординг проектов: kit + операторский CLI + runbook** (ORCH-009, `feat`): способность развернуть **новый** проект одним проходом (домен D5.2 эпика саморазвития) — **вне рантайма и вне конвейера**: `src/**` байт-в-байт (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты, снапшот-контроль `tests/test_onboarding_invariants.py`), kill-switch не нужен (активация — только явный запуск CLI человеком). Эталон — сам репозиторий orchestrator (каноны ORCH-52b/c/d/e). ADR: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md` (D1…D11), сквозной `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
-  - **Kit `onboarding/repo-skeleton/` (D1–D3, FR-1/FR-2/FR-3):** параметризуемый каркас нового репо — 6 промптов агентов канона 52d/92 (5 XML-секций в нормативном порядке, «❌ → ✅», `<escalation>` у developer/reviewer/tester, frontmatter-схема 52c с плейсхолдерными датами/моделями, machine-verdict ключи байт-в-байт; язык — канон орка: 5 ru + deployer en c рамкой shared-host-гардрейлов), reviewer-gate «дока не обновлена → `REQUEST_CHANGES`», паспорт `CLAUDE.md`, `AGENTS.md` (карта доков + правила ведения), `CONTRIBUTING.md`, `README`/`CHANGELOG`, скелет `docs/` (`ARCHITECTURE`/`PIPELINE`/`PRODUCT_VISION`/`operations/INFRA.md` с обязательными секциями топологии/env/границ/рисков общего хоста, реестр сквозных ADR), `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция словарь↔kit держится тестом). **Канон не форкается (BR-2):** `docs/_templates/` (16) + `docs/_standards/` (3) в kit не хранятся — копируются live из чекаута в момент материализации.
-  - **CLI `scripts/onboard_project.py` (D4–D7, D11, FR-4/FR-5):** режимы `plan` (дефолт, GET-only, ноль мутаций сети/диска) / `apply` (идемпотентный ensure: существующее → `skipped(exists)`, delete-операций нет вовсе) / `verify` (round-trip реестра, резолв всех 22 статусов включая fail-closed `Confirm Deploy`/`STOP`, лейблы, webhook активен, полнота kit в репо, скан неразрешённых плейсхолдеров). Закрытый список read-only импортов из `src` (нулевой дрейф по построению): `projects._parse_projects_json`, `plane_sync._PLANE_NAME_TO_KEY`, `config.settings`. Канонические группы статусов фиксированы ADR D5 (код-критично: `STOP`→`cancelled` ORCH-090; терминальные группы только у Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит). Gitea: репо `auto_init=false` + per-repo webhook (`push`/`pull_request`/`status`, **переиспользует** глобальный `ORCH_GITEA_WEBHOOK_SECRET` — новый сломал бы HMAC существующих, TR-6); initial push — **только** в свежесозданный пустой репо (INV-4 не затрагивается). Реестр: merged-вывод `ORCH_PROJECTS_JSON` через фактический парсер; скрипт `.env` НЕ правит, прод НЕ рестартит, ничего не удаляет (NFR-2); секреты маскируются (NFR-3); Plane CE API-пробел → `manual-step` со ссылкой на runbook (fail-safe, TR-8). Отчёт `created/skipped(exists)/manual-step` + `--json`; exit-коды 0/2/1.
-  - **Runbook `docs/operations/ONBOARDING.md` (FR-6):** полный чеклист (предусловия → Plane → Gitea → kit → регистрация с self-hosting-предупреждением → верификация → откат), каждый ручной шаг с командой проверки; smoke — на **staging-контуре** (8501, изолированная БД) с одноразовым sandbox-проектом (D8), журнал smoke-прогонов. `docs/operations/SETUP_WEBHOOKS.md` обобщён per-repo (без хардкода enduro-trails).
-  - **Анти-дрейф (NFR-4):** структурные канон-тесты kit `tests/test_onboarding_kit.py` (TC-01…08, 19–20), рендер/планы/идемпотентность `tests/test_onboarding_script.py` (TC-02, 09–18, моки, без сети), инварианты `tests/test_onboarding_invariants.py` (TC-21: снапшоты `STAGE_TRANSITIONS`/`QG_CHECKS`, закрытый список импортов CLI, эталонные промпты `.openclaw/agents/` не тронуты).
-  - **fix(tests): герметизация ORCH-41-тестов model/effort от хост-env (разблокировка merge-gate):** re-test merge-gate бежит в прод-окружении орка, где оператор легитимно включил `ORCH_AGENT_FALLBACK_MODEL` и сменил `ORCH_AGENT_MODEL_DEFAULT`/`ORCH_AGENT_EFFORT_*` — `test_resolve_agent_model.py::test_fallback_model_disabled_by_default` и `test_resolve_agent_effort.py::test_flags_present_when_configured` ассертили **заводские** дефолты через env-backed singleton `settings` (в чистом env Gitea CI зелёные → мина на `main`; ветка ORCH-009 `src/` и эти тесты не трогает, детонация от смены прод-env). Фикс: autouse-фикстуры обоих файлов пиняют shipped-дефолты model/fallback-полей (зеркально друг другу), ассерт «G4 выключен по умолчанию» переведён на **класс-дефолт поля** (`type(settings).model_fields["agent_fallback_model"].default == ""` — подлинный инвариант ORCH-074 ADR-001 Решение 3), never-break ассерты `is_valid_model` — байт-в-байт. В чистом CI поведение байт-эквивалентно (фикстуры ставят ровно то, что даёт пустой env). Полный регресс: 1713 passed (было 2 failed / 1711 passed на re-test).
- **Машинный журнал уроков `lessons`** (ORCH-098, `feat`): шаг 1 («Фундамент», F2) эпика саморазвития — формализует свободнотекстовые «уроки» из `memory/` в **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих ретроспективщика (E2), приоритизатора RICE (E3) и Стрим. Чистый **observer-leaf** `src/lessons.py` (never-raise, kill-switch, паттерн `serial_gate`/`coverage_gate`/`metrics`): `record()`/`get()`/`update()`/`snapshot()`. **Инвариант:** журнал — наблюдатель, **не** Quality Gate — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы существующих таблиц байт-в-байт не тронуты; enduro не затронут. ADR: `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`, сквозной `docs/architecture/adr/adr-0034-lessons-journal.md`.
-  - **Таблица (D1, FR-1):** аддитивная идемпотентная `lessons` (`CREATE TABLE IF NOT EXISTS` в `db.init_db()` + три индекса, restart-safe) — контекст (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализ (`root_cause`/`suggestion`), статус (`status`/`related_task`), **колонки атрибуции — сразу и нуллабельно** (`attribution`/`target_repo`/`target_domain`, требование Славы 10.06 / NFR-6, заполняется позже через update; `_ensure_column` форвард-safe на старой таблице) + `source`/`detail`; без `enum`-констрейнтов (слаги forward-compatible). Хелперы `db.record_lesson`/`get_lessons`/`update_lesson`/`lessons_snapshot`/`lessons_recent_dup_exists`.
-  - **НЕ скоупится по репо (D2):** журнал observer-only → единственный регулятор — глобальный kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`); **`lessons_repos` НЕ вводится**. Recorder пишет уроки про **любой** репо (включая enduro-trails); репо-разрез — на **выборке** (`get(repo=…)`).
-  - **Автозапись 4 типов (D3, FR-3):** тонкие best-effort врезки (`source="auto"`, never-raise, дедуп) — `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`, откат на `development`), `merge_hold` (`stage_engine._handle_merge_verify` HOLD), `transient_retry` (`launcher._finalize_transient` на исчерпании бюджета ретраев), `deploy_degraded` (post-deploy `DEGRADED → set_repo_freeze`, урок слоя-3 «деплой OK / прод сломан» ET-8).
-  - **Дедуп (D4):** для `auto` — один indexed-SELECT по `idx_lessons_wi_type`: дубль `(work_item_id, lesson_type, stage)` в окне `lessons_dedup_window_s` (env, дефолт 3600с) → no-op; `manual` не дедупится.
-  - **Эндпоинты (D5, FR-4/5):** `GET /lessons` (read-only, фильтры `type`/`status`/`repo`/`work_item`/`limit`), `POST /lessons` (ручная запись), `POST /lessons/{id}` (доклассификация/update); read-only ключ `lessons` в `GET /queue`. Выключенный флаг → `{"enabled": false}`.
-  - **Регресс:** kill-switch `lessons_enabled=False` → полная инертность (no-op без обращения к БД); never-raise на всех публичных функциях/врезках — сбой журнала не роняет конвейер; аддитивно (новая таблица + leaf + эндпоинты + тонкие врезки). Флаги `config.py`: `lessons_enabled`/`lessons_query_limit_default`/`lessons_dedup_window_s`. Тесты `tests/test_lessons.py` (TC-01…TC-12, unit+integration).
- **FND/F1b: sidecar-watchdog — мозг мониторинга в отдельном контейнере** (ORCH-100, `feat`): новая папка `watchdog/` (тонкий **Python-3.12-stdlib-only** демон) + сервис `orchestrator-watchdog` в `docker-compose.yml` (`network_mode: host`, read-only `docker.sock`, `mem_limit: 128m`). Вторая половина пары наблюдаемости домена 0: F1a (ORCH-099) отдаёт `GET /metrics` (сырьё), F1b — **мозг**, который это сырьё читает, дополняет внешними сигналами (хост/контейнеры/зависимости) и превращает в **алерты** через **собственный** независимый Telegram-канал. **`src/**` НЕ изменён** — F1b потребитель `/metrics`; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД орка — байт-в-байт. Аддитивно, под kill-switch `WATCHDOG_ENABLED`, строго read-only к наблюдаемому (self-hosting-безопасно). ADR: `docs/work-items/ORCH-100/06-adr/ADR-001-sidecar-watchdog.md`, сквозной `docs/architecture/adr/adr-0033-sidecar-watchdog.md`.
-  - **fix(test): изоляция `settings.runs_dir` в conftest** — устранена амбиентная prod-зависимость, валившая `test_queue.py::TestRetry::test_finalize_job_requeue_then_fail` в self-hosting-окружении (TC-14 «full tests/ regression green»). `launcher._finalize_job` классифицирует падение по хвосту `<settings.runs_dir>/<run_id>.log`; `runs_dir` по умолчанию = живой prod-каталог `/app/data/runs`, где на хосте накоплены РЕАЛЬНЫЕ логи агентов (`2.log` содержит `429` → 'transient'), поэтому тест с литеральным `run_id=2` читал чужой prod-лог и получал requeue вместо `failed`. Новый autouse-фикстур `_isolate_runs_dir` в `tests/conftest.py` (по образцу `_no_telegram`/`_disable_merge_verify`) перенаправляет `runs_dir` в пер-тестовый tmp → `_run_log_path()` указывает на несуществующий файл → `classify_log_file()` отдаёт документированный дефолт 'permanent'. Детерминизм всей сюты восстановлен (1617 passed); `src/**` не тронут.
-  - **Стек (D1):** Python 3.12 stdlib-only на `python:3.12-slim` — `urllib` (HTTP `/metrics` + пинги + Telegram POST), сырой HTTP-over-unix-socket для read-only `docker.sock` (БЕЗ pip-пакета `docker`), `shutil.disk_usage`/`/proc/meminfo` для хоста. Нет дерева зависимостей (тонкость, C-3). Отдельный образ `watchdog/Dockerfile` (build-контекст = корень репо; `src/**` НЕ копируется — изоляция C-1).
-  - **Топология (D2):** сервис собирается из `watchdog/Dockerfile`, `restart: unless-stopped` (самовосстановление), `network_mode: host` → `/metrics` достижим как `http://127.0.0.1:8500/metrics`; `docker.sock` смонтирован `:ro` И код GET-only (двойная гарантия read-only); хост-пути bind-mount `:ro`; `mem_limit: 128m`+`mem_reservation: 32m`. `env_file` опционален (`required: false`) → отсутствие `.env.watchdog` НЕ ломает `docker compose up` прод-орка. Деплой watchdog поднимает ТОЛЬКО его — прод `orchestrator` не пересобирается/не рестартится.
-  - **Обобщённая чистая решающая функция (D4):** `watchdog/decision.py::decide(signal_active, prev, now, cooldown_s) -> alert|realert|recovery|none` — строгая генерализация `disk_watchdog.decide_action` (булев `signal_active` вместо `used_pct >= threshold`), per-signal in-memory `AlertState` (анти-спам/recovery, рестарт сбрасывает → корректный повторный алерт стоящей проблемы).
-  - **Реестр сигналов (D5):** `orch_down` (K=3 подряд неудачных `/metrics` — debounce, не флаппит на одиночной икоте), `host_mem` (≥90%), `host_disk_crit` (opt-in потолок 97%, default off — D6), `agent_hung` (per run_id, два опроса: `runtime > N` И доля CPU `< floor`), `stage_stuck` (per work_item), `job_failed` (edge, рост счётчика), `queue_depth` (≥20), `container_down` (per name, статус ∉ {running,healthy}), `dep_down` (per name, пинг Plane/Gitea/Anthropic). Все пороги/интервалы/URL/токены — из env (`WATCHDOG_*`, канон в `.env.example`).
-  - **Анти-дубль диск-алерта (D6, AC-5):** штатные 85% остаются ЕДИНСТВЕННО за `disk_watchdog` (ORCH-063) → **нулевой дубль по построению**; вклад sidecar — `orch_down` (когда орк лёг, in-process стражи мертвы) + **opt-in** независимый потолок `host_disk_crit` (97%, default off) как резерв канала. Один владелец на порог.
-  - **Независимый транспорт (D7):** `watchdog/notify.py` читает **свои** `WATCHDOG_TG_BOT_TOKEN`/`WATCHDOG_TG_CHAT_ID`, **запрещён** импорт `src/notifications.py`/токена орка (падение орка не утянет алерт-канал). Отсутствие токена → fail-safe (логирует, не шлёт, не падает).
-  - **never-raise + kill-switch (D8):** три уровня (per-source: битый коллектор деградирует один сигнал; per-tick: внешний try/except цикла; per-send: обёрнутая отправка). `WATCHDOG_ENABLED=false` → демон инертен (idle-loop с логом, НЕ exit — чтобы restart-policy не крутил петлю). Толерантность к версии `/metrics` (D9): неизвестные поля игнорируются, рост `schema_version` логируется (warning) без крэша.
-  - Тесты: `tests/watchdog/test_*.py` (TC-01…TC-13: решение/orch-down/never-raise/kill-switch/full-tick/docker-readonly/notify-isolation/metrics-parse/compose/disk-dedup + коллекторы host/deps) + полный регресс `tests/ -q` зелёный (TC-14, `src/**` не тронут). **Инфра-предусловие** (07): добавить сервис в compose, создать bot/chat watchdog + `.env.watchdog`, первый запуск на хосте. Откат: не запускать сервис / `WATCHDOG_ENABLED=false`.
- **Багфикс-трек: упрощённый/дешёвый маршрут конвейера для багов** (ORCH-019, `feat`): задача с меткой Plane `Bug` идёт **укороченным маршрутом** — пропускается стадия `architecture` (отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`), тяжёлая аналитика заменяется облегчённым пакетом (короткий bug-report + обязательный план регресс-теста). **Все Quality Gate'ы исполняются без изменений** (корневой инвариант NFR-1): `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / сигнатуры `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/`coverage_status:`) — байт-в-байт прежние; маршрутизация багфикса — свойство планировщика, **не** гейт. Аддитивно, под kill-switch, с областью репо, never-raise, fail-safe → полный цикл. ADR: `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`, сквозной `docs/architecture/adr/adr-0032-bug-fast-track.md`.
-  - **Классификация (D1, FR-1):** новый leaf `src/bug_fast_track.py` (never-raise, паттерн `labels`/`serial_gate`). `bug_fast_track_applies(repo)` (локально, без сети) проверяется ПЕРВЫМ → выключенный флаг = нулевой сетевой оверхед; `is_bug_task(work_item_id, project_id)` делегирует в проверенный `labels.has_label` (ORCH-089: `fetch_issue_labels`+`get_project_labels`, нормализация, TTL-кэш). **Источник истины — Plane API**, не payload вебхука. Чтение метки — только в `start_pipeline`, **никогда** в горячем `claim_next_job` (NFR-4).
-  - **Хранение типа (D2):** аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'` (`_ensure_column`, паттерн `tasks.cancelled_at` ORCH-090); значения `'full'` (дефолт, ВСЕ существующие и не-баг задачи) | `'bug'`. Хелперы `db.set_task_track`/`db.get_task_track` (отсутствие/NULL → `'full'`, fail-safe). Сигнатура `create_task_atomic` не меняется.
-  - **Routing-override (D3, FR-2):** врезка в `advance_stage` на ребре выхода из `analysis`: при `track='bug'` (через чистый предикат `bug_fast_track.skips_architecture`) `next_stage` → `development`, `next_agent` → `developer` (минуя `architect`). `get_next_stage`/`get_agent_for_stage`/`STAGE_TRANSITIONS` — чистые, 1:1; тип читается из БД (без сети, NFR-4). Для не-баг задач (`track='full'`) маршрут байт-в-байт прежний. Сопутствующе: стамп `mark_brd_review_ended` расширен на `analysis → development` (честная метрика ORCH-087 на багфикс-треке).
-  - **Гейт `analysis` не тронут (D4, FR-6):** `check_analysis_complete`/`check_analysis_approved` байт-в-байт прежние; багфикс-аналитик всё равно эмитит все 4 файла (облегчённые) — сильнейшая позиция NFR-1 (нулевая поверхность правок гейта).
-  - **Эскалация (D5, FR-5):** админ-эндпоинт `POST /bug-fast-track/escalate?work_item=<id>` (по образцу `POST /serial-gate/unfreeze`) сбрасывает `track` `'bug'→'full'` → следующий переход уходит в `architecture` (полный цикл). Плюс решение мини-аналитика «баг сложный → полный пакет + `escalate: full-cycle`».
-  - **Область / флаги (D6):** `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`), `bug_fast_track_label` (дефолт `Bug`), `bug_fast_track_repos` (CSV; **пусто → self-hosting only** — enduro подключается явным CSV). `False` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия, AC-6).
-  - **Наблюдаемость (D7, FR-7):** аддитивный read-only блок `bug_fast_track` в `GET /queue` (флаг/метка/область + счётчик багфикс-задач + метрика сэкономленных стадий `architecture`); лог-строка на решение о маршруте; отметка `🐞` в Telegram-карточке (never-raise). Композиция (D8, AC-9): багфикс-задача — обычная задача репо для serial-gate (ORCH-088, не обходит его); `autoApprove`/`autoDeploy` (ORCH-089), coverage-gate (ORCH-027, союзник BR-4), merge-gate (ORCH-043) — штатно.
-  - **Промпты:** `analyst.md` (облегчённый багфикс-пакет + путь эскалации), `reviewer.md` (ось «багфикс без регресс-теста → finding ≥P1 / REQUEST_CHANGES») — канон 52d не нарушен. **Инфра-предусловие:** создать метку `Bug` в Plane-проекте ORCH (её отсутствие = fail-safe полный цикл). Тесты: `tests/test_bug_fast_track*.py` + `tests/test_db_migrations.py` + блок в `tests/test_queue_endpoint.py` (TC-01…TC-15). Полный регресс `tests/ -q` зелёный. Откат: `ORCH_BUG_FAST_TRACK_ENABLED=false` (мгновенный; остаточная колонка `track` безвредна).
- **Детект legacy root-owned файлов + внятная ошибка worktree при миграции на uid 1000** (ORCH-057, follow-up ORCH-040, `feat`): закрыт недоделанный AC ORCH-040 — legacy `root:root` файлы в `/repos` (после перевода контейнеров на `user: "1000:1000"`) ломали создание worktree под uid 1000 (`ensure_worktree` → сырой `fatal: … Permission denied`, агент не стартовал, диагноза не было). Три аддитивных, обратимых kill-switch'ем слоя; **`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД — байт-в-байт прежние**. ADR: `docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md`, сквозной `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`.
-  - **D1 — actionable-ошибка `ensure_worktree`:** класс «нет прав» (`Permission denied` / `could not create leading directories` / `insufficient permission for adding an object` / `PermissionError`/`EACCES`/`EPERM`) оборачивается в `RuntimeError` с **причиной** (legacy root-файлы в `/repos/_wt`/`.git` после миграции uid), **лечащей командой** (`chown -R <uid>:<uid> …`) и ссылкой на `INFRA.md` — вместо сырого git stderr. Ошибки, **не** связанные с правами, сохраняют прежний контракт (меняется только формулировка, не факт сбоя; чистый классификатор `fs_normalize.classify_worktree_error`). Под выключенным kill-switch контракт ошибки 1:1 как до ORCH-057.
-  - **D2 — детект-леаф `src/fs_normalize.py`** (never-raise, паттерн `serial_gate`/`coverage_gate`): `scan_ownership(roots, target_uid=os.getuid())` обходит `/repos/_wt`, `<repo>/.git/{objects,worktrees}`, `data/runs` с ранним выходом при первом `st_uid != target_uid`, TTL-кэшем (`fs_scan_cache_ttl_s`, по образцу `preflight._cache`) и `applies(repo)` first (пустой CSV → self-hosting only → enduro-trails не сканируется). Опц. `normalize()` chown'ит **только** при `geteuid()==0` (под uid 1000 — no-op + честный лог «нужна операторская процедура», НЕ ошибка).
-  - **D3 — наблюдаемость, БЕЗ блокировки claim:** best-effort вызов `scan_ownership()` на старте `main.lifespan` (рядом с lease-reclaim/log-rotation, never-fatal) → WARNING + Telegram при mismatch; read-only блок `fs_ownership` в `GET /queue`; опц. ручной `POST /fs-normalize/check`. Claim **не** блокируется (preflight repo-слеп → регресс enduro; queue_worker — дорогой FS-обход в hot-path + молчаливое зависание); внятный ранний отказ даёт D1 в точке launch.
-  - **Процедура (D5):** обязательная операторская нормализация под root на хосте — в `docs/operations/INFRA.md` (раздел «Миграция uid: обязательная нормализация legacy root-файлов», все корни: `_wt`, оба `.git`, `data/runs`); фактический `chown` остаётся ручным шагом (контейнер без root его сделать не может) — задача гарантирует **внятность** отказа, а не его отсутствие.
-  - **Флаги** (`src/config.py`, аддитивно): `ORCH_FS_NORMALIZE_ENABLED` (kill-switch), `ORCH_FS_NORMALIZE_REPOS` (CSV; пусто → self-hosting only), `ORCH_FS_TARGET_UID` (1000), `ORCH_FS_NORMALIZE_AUTO` (детект-only), `ORCH_FS_SCAN_ROOTS`, `ORCH_FS_SCAN_CACHE_TTL_S`. Тесты: `tests/test_fs_normalize.py`, `tests/test_git_worktree_perm.py`, `tests/test_fs_normalize_startup.py`, `tests/test_api_queue.py` (TC-01…TC-12).
- **Лёгкий read-only `GET /metrics` — машинное «сырьё» о самом орке для sidecar F1b** (ORCH-099, FND/F1a, `feat`): добавлен версионируемый JSON-эндпоинт `GET /metrics`, отдающий снимок внутреннего состояния орка для будущего отдельного sidecar-наблюдателя F1b (`watchdog/`) — наблюдатель отделён от наблюдаемого (BRD §1): орк отдаёт ТОЛЬКО факты, которые знает лишь он сам; пороги/алерты/история/Telegram — на стороне F1b. **Аддитивно, строго read-only, never-raise:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — **не тронуты**; `/health`/`/status`/`/queue` — байт-в-байт прежние. ADR: `docs/work-items/ORCH-099/06-adr/ADR-001-metrics-endpoint.md`, сквозной `docs/architecture/adr/adr-0030-metrics-endpoint.md`.
-  - **Leaf-сборщик + тонкий эндпоинт (D1):** новый `src/metrics.py` (`build_metrics() -> dict`, never-raise по разделам, паттерн `serial_gate.snapshot()`) собирает конверт по-раздельно (каждый раздел в своём `try/except` → безопасный дефолт `null`/`[]`/`{}` + WARNING); эндпоинт `@app.get("/metrics")` в `src/main.py` — тонкая обёртка, возвращает результат как есть (стиль `GET /queue`). Тестируемость без ASGI: разделы проверяются прямым вызовом `build_metrics()`.
-  - **Конверт + контракт `schema_version` (D2):** `schema_version` (стартует с `1`), `generated_at` (UTC ISO-8601, часовой домен орка → дельты CPU иммунны к skew орк↔sidecar, TR-3), `clk_tck` (`os.sysconf("SC_CLK_TCK")`, базис тиков). Политика: аддитивные изменения **НЕ бампят** версию (sidecar обязан игнорировать незнакомые ключи) — бамп только при ломающем (rename/remove/retype).
-  - **Разделы сырья (D3–D7):** `stages` — незавершённые задачи (`stage NOT IN ('done','cancelled')`, ORCH-090) с `work_item`/`stage`/`age_in_stage_s`/`repo` (источник `db.get_active_tasks_for_reconcile()` + фильтр терминалов на потребителе, helper-инвариант ORCH-053/086 не тронут). `queue` — `db.job_status_counts()` (+`cancelled`-ключ дефолтом), глубина, сырьё ретраев (`db.queue_retry_stats()`: attempts/transient/в-backoff), `worker.breaker.snapshot()`, `max_concurrency`. `agents` (liveness) — по running-job (новый read-only `db.get_running_agents()`, dedicated SELECT, НЕ расширение hot-path `get_running_jobs()`): `agent`/`run_id`/`job_id`/`pid`/`runtime_s` (= `running_age_s` от `jobs.started_at`, D6)/`model`/`effort` + **CPU-сырьё** `cpu_ticks` (utime+stime из `/proc/<pid>/stat`, поля 14+15; орк дельту не считает — stateless, арбитр sidecar). `cost` — `running` (по running-job, `null` до завершения = честное сырьё) + `aggregate` (новый `db.agent_cost_totals()`, `COALESCE(SUM(...),0)` по `agent_runs`).
-  - **Never-raise сырьё для liveness (FR-6/NFR-2):** `metrics._read_cpu_ticks(pid)` — `pid is None` / нет `/proc/<pid>` / мёртвый процесс / не-Linux → `cpu_ticks: null` у этого агента, прочие поля и весь эндпоинт целы (НЕ raise). Недоступный `worker` → `breaker: null`/`max_concurrency: null`, не 500. Пустые таблицы → `stages=[]`/`agents=[]`/`cost.aggregate=нули`.
-  - **Kill-switch (D8):** `src/config.py` `metrics_endpoint_enabled: bool = True` (env `ORCH_METRICS_ENABLED` через явный `validation_alias` — документированное имя контракта реально управляет флагом). `False` → `200` с минимальным телом `{"schema_version":1,"enabled":false}` (НЕ 404 — контракт остаётся парсимым). Дефолт `True` → нулевая регрессия (эндпоинт доступен из коробки).
-  - **Контракт задокументирован (AC-7):** формат `/metrics` зафиксирован в `docs/architecture/README.md` (раздел «Сырьё-эндпоинт `/metrics`» + строка в таблице API) как стабильный контракт для F1b. Тесты: `tests/test_metrics.py` (TC-01…TC-11: конверт/4 раздела, исключение терминалов, queue-поля, liveness-сырьё + cpu_ticks на живом pid, never-raise на `pid=None`/мёртвом pid/бросающем источнике/недоступном breaker, cost-агрегат + пустая таблица, эндпоинт через handler, read-only снимок БД до/после, аддитивность `/health`//status//queue, пустое состояние, kill-switch). Полный регресс `tests/ -q` зелёный (1480 → +14). Откат: `ORCH_METRICS_ENABLED=false` (мгновенный) или удаление модуля/эндпоинта/helper'ов (без следов в БД/схеме).
- **Детерминированный гейт покрытия тестами — защита от тихой деградации coverage перед merge в `main`** (ORCH-027, `feat`): существующие тестовые гейты (`check_ci_green`, `check_tests_passed`, merge-gate re-test) судят только по **факту** прохождения, не по **полноте** — ни один не замечает «300 строк кода, 0 тестов», и при пакетном автономном прогоне (ORCH-088) покрытие монотонно деградирует. Введён детерминированный (без LLM) под-гейт ребра `deploy-staging → deploy` по образцу security-гейта (ORCH-022): leaf `src/coverage_gate.py` (never-raise) + тонкая обёртка `check_coverage_gate` в `QG_CHECKS` + врезка `_handle_coverage_gate` в `advance_stage`. **Аддитивно:** `STAGE_TRANSITIONS` / семантика существующих `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) — байт-в-байт прежние; новая БД-таблица аддитивна (NFR-5/AC-8). См. `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`, сквозной `docs/architecture/adr/adr-0029-coverage-gate.md`.
-  - **Точка/порядок (D1, AC-2):** под-гейт исполняется **ПОСЛЕ merge-gate** (покрытие меряется на догнанном `auto_rebase_onto_main` HEAD — ровно том коде, что landed в `main`) и **ДО image-freshness** (фейл до дорогого docker-rebuild). FAIL → штатный откат на `development` (+ инкремент developer-retry, cap `MAX_DEVELOPER_RETRIES`) **и освобождение merge-lease** (merge-gate держал его на своём PASS — зеркало image-freshness rollback, TR-2). `STAGE_TRANSITIONS` не меняется (под-гейт, как security/merge/image-freshness).
-  - **Измерение (D2, FR-1/AC-1):** `python -m pytest tests/ --cov=src --cov-report=json` в изолированном per-branch worktree (`ensure_worktree`, прецедент `check_tests_local`); метрика — `totals.percent_covered` (line coverage `src/`). Измеритель инкапсулирован за `measure_coverage(repo, branch) -> float | None` (стек-расширяемость BR-6: jest/jacoco — новая ветка `measure_*`, без переписывания ядра). Тайм-аут `coverage_run_timeout_s`. Новая pip-зависимость `pytest-cov==5.0.0` (offline на момент замера). 
-  - **Чистая функция решения (D3, FR-2/AC-3):** `compute_coverage_verdict(measured, baseline, floor, policy, epsilon) -> (ok, reason)` — детерминированная, без LLM/IO. `absolute` → `measured ≥ floor−ε`; `baseline` → `measured ≥ baseline−ε`; `both` (дефолт) → оба; `baseline is None` (bootstrap) → baseline-условие не применяется (нельзя регрессировать против пустоты). `epsilon` — допуск на шум измерения (NFR-4, анти-флап у границы). Покрыто unit-тестами всех режимов/границ/epsilon.
-  - **Базовая линия + ratchet (D4/D5, FR-4/AC-4):** аддитивная БД-таблица `coverage_baseline(repo PK, coverage, source_sha, updated_at)` (`CREATE TABLE IF NOT EXISTS`, паттерн `repo_freeze`/`job_deps`; существующие таблицы не мигрируются). Хелперы `db.get_coverage_baseline`/`ratchet_coverage_baseline`/`set_coverage_baseline`/`all_coverage_baselines`. Наращивание **только вверх** в choke-point подтверждённого merge `_handle_merge_verify` (ребро `deploy → done`): `coverage_gate.ratchet_baseline_on_merge` читает измеренное из `18-coverage-report.md` (single source of truth) и применяет **атомарный compare-and-set** `UPDATE … WHERE coverage <= measured` (или `INSERT` — bootstrap) под держимым merge-lease (ORCH-043) → базовая линия никогда не падает даже при гонке. Меньшее значение базовую линию не понижает.
-  - **Условность + fail-open (D6, FR-5/FR-6/AC-5/AC-6):** `coverage_gate_applies(repo)` (локально) ПЕРВЫМ — дорогой прогон только при `applies==True`. `coverage_gate_enabled=False` → инертно (1:1 как до ORCH-027); `coverage_gate_repos` (CSV; **пусто → self-hosting only** `is_self_hosting_repo`, как security/merge/image-freshness) → enduro-trails не затронут (no-op `(True, "N/A")`). Ошибка/недоступность coverage-инструмента или непарсимая метрика → **fail-open + WARNING** по умолчанию (`coverage_tool_fail_closed=False`, анти-петля по образцу ORCH-061/022 dep-audit); флаг переключает в fail-closed.
-  - **Машинный вердикт + наблюдаемость (D7/D8, FR-7/AC-9):** артефакт `18-coverage-report.md` (frontmatter `coverage_status: PASS|FAIL` + `measured_coverage`/`baseline`/`floor`/`policy`/`epsilon`/`delta`), вердикт читается ТОЛЬКО из frontmatter через `src/frontmatter.parse_frontmatter` (ORCH-052c, регистр фиксирован); гейт сам пишет отчёт и читает вердикт обратно из того же файла (single source of truth, как `security_status:`). Read-only блок `coverage` в `GET /queue` (kill-switch/scope/policy/floor/epsilon/per-repo baselines). При FAIL — `send_telegram` с кликабельным номером (`link_for`), измеренным покрытием, порогом/базовой линией и дельтой. Опциональный ручной override `POST /coverage/baseline?repo=…&value=…` (по образцу `POST /serial-gate/unfreeze`) для легитимного разового снижения покрытия.
-  - **Self-hosting безопасность (NFR-1/NFR-3/AC-7):** leaf не импортирует `stage_engine`; любое исключение перехвачено (never-raise); гейт только мерит/читает/пишет/решает — не деплоит, не рестартит прод-контейнер, не пушит/форс-пушит `main` (структурно проверено AST-тестом TC-12). Прод-деплой ORCH-027 — строго через staging-гейт (8501), без рестарта прод-контейнера (лейбл `arch:major-change`).
-  - **Флаги (`config.py`, env `ORCH_COVERAGE_*`, `.env.example`):** `coverage_gate_enabled` (kill-switch), `coverage_gate_repos`, `coverage_min_percent` (дефолт 0.0 — безопасный раскат: no-regression ведёт ratchet-базовая линия, floor не фейлит в день один), `coverage_policy` (дефолт `both`), `coverage_epsilon` (0.5), `coverage_tool_fail_closed` (False), `coverage_run_timeout_s` (900). Откат: `ORCH_COVERAGE_GATE_ENABLED=false` → полный no-op (мгновенный обратимый kill-switch).
-  - **Инфра-предусловие:** добавить `pytest-cov` в прод/staging-образ (`requirements.txt`). При первом применимом merge базовая линия засевается фактическим покрытием `main` (bootstrap). Тесты: `tests/test_coverage_gate.py` (TC-01…TC-15: режимы/границы/epsilon verdict, ratchet up-only + bootstrap + per-repo изоляция, applies/kill-switch, fail-open/closed, never-raise, write/read-back отчёта, self-hosting AST-safety, интеграция в `advance_stage` с откатом+release lease, реальное измерение pytest-cov на фикстур-репо + тайм-аут, snapshot + неизменность `QG_CHECKS`/`STAGE_TRANSITIONS`). Обновлены анти-регресс-реестры `QG_CHECKS` (`test_config`/`test_plane_status_model`/`test_qg_registry_snapshot`/`test_stages_invariants`) и edge-тесты `test_stage_engine` (`check_coverage_gate: _pass`). Полный регресс `tests/ -q` зелёный.
- **Live-карточка трекера: HTML-инъекция «<1м» больше не застывает карточку — экранирование всех данных-полей на границе рендера** (ORCH-095, `fix`): карточка задачи (`src/notifications.py::render_task_tracker`) шлётся/редактируется с `parse_mode=HTML`. `_fmt_minutes` для стадии < 60 с возвращает литерал `"<1м"`, который интерполировался в HTML-текст **сырым** → Telegram парсит `<1м` как открывающий тег → `editMessageText` отвечает `400 can't parse entities: Unsupported start tag "1м"` → `edit_telegram` классифицирует как `EDIT_FAILED` → `update_task_tracker` делает ранний `return` (анти-дубль ORCH-087) → **карточка застывает** (детерминированно воспроизведено 09.06 на ORCH-093, `message_id 18854`). Корневой класс шире одного `<1м`: все подставляемые **данные** (длительности, статус-лейбл, модель, эффорт, токены/стоимость) вставлялись сырыми; экранирован был только заголовок (`esc_title`) и href/label внутри `plane_issue_link`. **Аддитивно, never-raise, без нового поведения конвейера:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / транспорт нотификаций / схема БД — **не тронуты** (затронут ровно один модуль индикативного слоя); kill-switch не требуется (исправление дефекта корректности, откат = `git revert`).
-  - **Экранирование на границе рендера, не в источнике (ADR-001 D1/D2, AC-1/AC-2):** новый модуль-локальный хелпер `_esc(x) = html.escape(str(x))` (never-raise → `""` на исключении) оборачивает каждое подставляемое **данные-значение** (категория D) ровно один раз в точке интерполяции в `render_task_tracker`/`_stage_line`: длительности (`_fmt_minutes`/`_capped_review_str`), статус-лейбл (`_card_status_label`), модель (`short_model_name`), эффорт (`_run_effort`), токены/стоимость (`fmt_tokens`/`fmt_cost`). Функции-источники остаются **HTML-агностичными** (данные, не разметка): `src/usage.py` и `_fmt_minutes` не тронуты — `_fmt_minutes` продолжает возвращать `"<1м"`, безопасность даёт escape на границе (`&lt;1м` рендерится оператору визуально идентично `<1м` → видимый формат не меняется).
-  - **Категория M (намеренная разметка) неприкосновенна (D5, AC-3):** кликабельный номер задачи `num_html` (`plane_issue_link`, внутри уже экранированы href+label), `link_for(...)` в строке «⏳ ждёт …», `_done_link(...)` («🔗 PR #n · 📦 Внедрено») и уже-экранированный `esc_title` через `_esc` **не** проходят → остаются валидным HTML, номер остаётся кликабельным. Двойное экранирование (`&amp;lt;`) структурно исключено: D-слот → `_esc` ровно один раз, M-слот → as-is.
-  - **Defence-in-depth (D3):** экранируются и сейчас-безопасные D-поля (токены/стоимость/модель дают только цифры/`.`/`k`/`M`/`$`/`^claude-…$`) — escape для них no-op, выгода — структурный инвариант «каждый D-слот экранирован», устойчивый к будущей смене формата источника.
-  - **Восстановление застрявших карточек (D4, AC-4):** механизм — достаточное условие FR-4 без нового кода: на ближайшем переходе стадии `update_task_tracker` рендерит новый безопасный текст → `edit_telegram` отвечает `200` → застрявшая карточка обновляется на месте. Переклассификация `can't parse entities` → переотправка **отвергнута** (после фикса источник из наших данных устранён структурно; касание ветки `EDIT_FAILED`/леджера рискует анти-дублем ORCH-087). Known-limitation (унаследовано ORCH-087/Telegram-48ч): карточка задачи, завершившейся до деплоя фикса, не восстанавливается (нет будущего рендера).
-  - **Трассировка:** перед правкой блоков, помеченных ORCH-042/067/087/091, прочитаны их ADR — инварианты (одна карточка на задачу, леджер сирот + анти-дубль, отражение откатов + суммирование `_stage_line`, строка Plane-статуса/кликабельный номер) сохранены по построению (ORCH-095 лишь оборачивает уже вычисленные D-значения в `_esc`, не меняя состав строк/порядок/логику подавления).
-  - Тесты: новый `tests/test_tracker_html_escape.py` (TC-01..TC-11: sub-minute escape на границе, never-raise `_fmt_minutes`/`_esc` на граничных входах, рендер sub-minute без сырого `<1м`, заголовок со спецсимволами без двойного экранирования, escape статус-лейбла/модели/эффорта, HTML-безопасность токенов/стоимости, регресс кликабельного `<a href>` номера и `_done_link`, parse-safe edit-payload, edit-in-place без новой карточки + анти-дубль на транзиентном фейле, never-raise на битых входах). Полный регресс `tests/ -q` зелёный (1437). ADR: `docs/work-items/ORCH-095/06-adr/ADR-001-html-safe-card-data-render.md`. Откат: `git revert` (один модуль + тесты + CHANGELOG, без миграций/kill-switch).
- **Терминальная (done) задача держит `Done` в Plane: terminal-window-aware гард deploy-статусов** (ORCH-094, `fix`): задача с БД `stage=done` и 0 активных job'ов (верифицировано на ORCH-061, task 47) стабильно флаппила в Plane `Awaiting Deploy ⟷ Monitoring after Deploy` (273 активности парами, само не затихает) вместо `Done`. Корень: три deploy-фазовых сеттера (`set_issue_awaiting_deploy`/`set_issue_deploying`/`set_issue_monitoring`) **терминал-слепы** — любой стейл/двойной/неизвестный вызов под бот-токеном перезаписывает `Done` промежуточным deploy-статусом, и обратно, бесконечно. **Аддитивно, never-raise, под kill-switch, в зоне self-hosting:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи (`deploy_status:`/`staging_status:`/…) / схема БД — **не тронуты** (читается существующая `tasks.stage`, без миграции).
-  - **Единый гард на низком чокпоинте (FR-2, D1/D2):** новый leaf `src/deploy_status_guard.py` (чистая, never-raise, config-gated логика; по образцу `serial_gate.py`/`labels.py`/`cancel.py`) — `decide(work_item_id, target, reason) -> ALLOW | CONVERGE_DONE | SUPPRESS`. Гард ставится на **входе** трёх сеттеров `plane_sync` (а не в caller'ах `stage_engine`) → перехватывает **любой** путь, включая неизвестный актор под бот-токеном. Предикат легитимности: deploy-статус легитимен ⇔ задача **нетерминальна** ИЛИ (`done` **И** активно пост-деплой-окно `post_deploy.window_active` = ARMED & не DONE). Для `done`: `monitoring`+окно-активно → `ALLOW`; иначе → `CONVERGE_DONE` (сеттер вместо PATCH'а зовёт `set_issue_done`, идемпотентно). `cancelled` → `SUPPRESS` (не штампуем поверх терминала ORCH-090). Нетерминальная задача → `ALLOW` (рабочий deploy-цикл 1:1, AC-4). Task не найден / не-self репо / kill-switch off / любое исключение → `ALLOW` (fail-safe к прежнему поведению 1:1, NFR-1).
-  - **Перенос арм-блока перед terminal-sync (D3, AC-4):** в `advance_stage` (ветка `next_stage=="done"`) блок `post_deploy.arm_monitor` перемещён **выше** блока `set_issue_monitoring` (стр. 404). Критично: `update_task_stage(task_id,"done")` пишет `stage='done'` **раньше** легитимного первого `Monitoring` — без переноса гард ошибочно свёл бы его к Done. Арм-первым пишет `ARMED` → `window_active==True` → `ALLOW` пропускает легитимный `Monitoring`; re-drive `deploy→done` **после** закрытия окна (`DONE` present) → `window_active==False` → `CONVERGE_DONE` (не воскрешает `Monitoring`). Перенос безопасен: `arm_monitor` лишь пишет sentinel + ставит отложенный job, не зависит от Plane-статуса/merge-lease (release остаётся после terminal-sync). Инварианты ORCH-021 (идемпотентный арм по `ARMED`) и ORCH-066 (`deploy→done` self ⇒ `Monitoring`) сохранены.
-  - **Харднинг пост-деплой-монитора (FR-3, D4, AC-3):** `run_post_deploy_monitor` — существующий идемпотентный страж `has_marker(DONE)` (no-op завершённого окна) сохранён; аддитивно: тик при БД `stage='cancelled'` мид-окно → закрыть окно `mark_done` **без статус-PATCH и без перепостановки** следующего тика (zombie-tick guard). Перепостановка остаётся строго при `HEALTHY and ticks < budget` (тик ≡ job; нет job → нет тика). После закрытия окна — 0 последующих статус-PATCH; любой стейл `set_issue_monitoring` добивается гардом D2.
-  - **Наблюдаемость (FR-4, D5, AC-5):** аддитивный BC-kwarg `reason: str | None = None` у трёх сеттеров; call-site'ы передают `"advance:deploy->done"`/`"phase_a"`/`"phase_b"`. `decide` эмитит ОДНУ структурную запись на вызов: `work_item`, `caller(reason)`, `target_status`, `db_stage`, `window_active`, `verdict` (`ALLOW` → INFO; `CONVERGE_DONE`/`SUPPRESS` → WARNING, «что подавили и почему» — атрибуция будущего флаппа). Новый read-only аксессор `db.get_task_by_work_item_id` (human-readable `work_item_id` матчит живой ряд; тумбстоны ORCH-090 имеют суффикс `#cancelled-<id>`).
-  - **Конфиг/откат (FR-5, D6):** `src/config.py` `deploy_status_guard_enabled: bool = True` (env `ORCH_DEPLOY_STATUS_GUARD_ENABLED`; `False` → сеттеры терминал-слепы, поведение **1:1** прежнее) / `deploy_status_guard_repos: str = ""` (env `ORCH_DEPLOY_STATUS_GUARD_REPOS`; CSV, **пусто → self-hosting only** — не-self репо (enduro) гард не трогает, нулевая регрессия). Откат: `ORCH_DEPLOY_STATUS_GUARD_ENABLED=false` (мгновенный runtime) или revert ветки.
-  - **Источник флаппа (BR-7):** code-писатели deploy-статусов — только `stage_engine.py:404/1218/1316`; реконсилятор F-2 эти статусы не перебирает; live-overlay `notifications.py` — read-only. Гард — **буфер на стороне орка**, гасящий маятник за один цикл независимо от актора (известный/стейл/неизвестный под бот-токеном). Если актор — внешняя Plane-automation под другим токеном, code-фикс не закрывает её полностью, но идемпотентное схождение к Done нейтрализует видимый эффект.
-  - **Трассировка:** перед правкой блока `next_stage=="done"` (маркеры ORCH-021/066/043/088) прочитаны их ADR — инварианты сохранены (deploy→done self ⇒ Monitoring; монитор-close ⇒ Done; терминал-набор `{done,cancelled}`). Тесты: `tests/test_deploy_status_terminal_guard.py` (TC-01..05/12), `tests/test_post_deploy_monitor_termination.py` (TC-06..08), `tests/test_deploy_status_observability.py` (TC-09), `tests/test_reconciler_done_deploy_convergence.py` (TC-10), `tests/test_self_deploy_cycle_regression.py` (TC-11). Обновлены анти-регресс-ассерты `tests/test_deploy_terminal_sync.py`/`test_deploy_approve.py` под `reason`-kwarg. Полный регресс `tests/ -q` зелёный (1411). ADR: `docs/work-items/ORCH-094/06-adr/ADR-001-terminal-window-aware-deploy-status-guard.md`, сквозной `docs/architecture/adr/adr-0028-terminal-window-aware-deploy-status-guard.md`.
- **Merge-актор ретраит транзиентные ошибки Gitea (405/5xx) + гард «ветка уже в `main`»** (ORCH-093, `fix`): две точечные доработки детерминированного merge-актора `src/merge_gate.py`, чинящие инцидент **ORCH-063**: self-deploy прошёл, staging OK, PR был `open`+`mergeable`, но `POST /pulls/{n}/merge` вернул `HTTP 405 "Please try again later"` (Gitea пересчитывал `mergeable` сразу после пуша) → one-shot `merge_pr` мгновенно вернул `False` → корректная защита ORCH-071/081 удержала задачу на `deploy` + потребовала ручной домерж; повторный прогон финализатора плодил мусорный пустой PR. **Аддитивно, never-raise, под существующими kill-switch'ами:** `STAGE_TRANSITIONS` / `QG_CHECKS` / схема БД — **не тронуты**; INV-4 (мерж только через Gitea PR-merge API, никогда `push`/`force-push` в `main`) сохранён 1:1.
-  - **Retry-loop транзиента (FR-1/FR-2, AC-1/AC-2/AC-3, D1/D2):** `merge_pr` оборачивает **только** мутирующий `POST …/merge` в ограниченный retry-loop с экспоненциальным backoff (`min(base*2^(i-1), max)`, дефолты 2/5 с → суммарный сон `(N-1)*max ≤ 10 с`, monitor-поток не подвешивается). Классификатор `_classify_merge_response`: **транзиент** (ретрай) — `405`/`408`/любой `5xx`/`httpx`-таймаут/сетевая ошибка, **и** `409`/`422` когда PR всё ещё mergeable; **терминал** (быстрый честный `False`, защита ORCH-071/081 как прежде) — `403`/`404`/реальный конфликт (`409`/`422` при `mergeable==False`). Неоднозначный `409`/`422` разрешается доп. `GET /pulls/{index}` → `mergeable`; дефолт-политика `mergeable==None`/недоступно → **транзиент** (fail-OPEN-в-ретрай: икота Gitea — наблюдаемый кейс, бюджет конечен, backstop сохранён). Каждая попытка логируется `attempt i/N` (образец `check_ci_green`).
-  - **Гард already-in-main (FR-3/FR-4, AC-4, D3/D4):** новый leaf `_branch_fully_in_main` (`git merge-base --is-ancestor HEAD origin/main` в per-branch worktree) вызывается в `ensure_open_pr` **между** «открытый code-PR не найден» и `POST …/pulls`: ветка целиком в `main` (нет коммитов `origin/main..HEAD`) → новый исход `"already-in-main"` **без создания PR** (нет мусорного пустого PR на уже влитой ветке). git-ошибка/ambiguous (`None`) → **fail-OPEN** (деградация на create-путь, НЕ ложный no-op). В `stage_engine._handle_merge_verify` исход `already-in-main` **пропускает** `merge_pr` (мержить нечего) и отдаёт авторитетному SHA-in-main (`verify_merged_to_main`) довести до `done`; это НЕ HOLD. SHA-in-main остаётся единственным доказательством мержа (ADR-0014).
-  - **Конфиг/откат (FR-5, AC-5/AC-7, D5):** новые поля `src/config.py` `merge_retry_enabled` (kill-switch; `False` → ровно один POST = байт-в-байт прежнее one-shot, нулевая регрессия) / `merge_retry_max_attempts` (3) / `merge_retry_backoff_base_s` (2) / `merge_retry_backoff_max_s` (5), env `ORCH_MERGE_RETRY_*`, дескрипторы в `.env.example`. Гард already-in-main — без отдельного флага (накрыт `merge_verify_autocreate_pr_enabled`). Откат: `ORCH_MERGE_RETRY_ENABLED=false` (мгновенный runtime) или revert PR.
-  - **Трассировка:** перед правкой `merge_pr`/`ensure_open_pr`/`_handle_merge_verify` прочитаны ADR ORCH-071/073/082 — инварианты (SHA-in-main authoritative, never-raise, idempotency-guard `pr_already_merged`, base==main фильтр code-PR) сохранены; в `MAIN_REGRESSION_MARKERS` добавлена строка `("ORCH-093", "_classify_merge_response", "src/merge_gate.py")` (append-only).
-  - Тесты: `tests/test_merge_gate.py` (TC-01..TC-12: 405×2→200, 5xx→200, network→200, реальный конфликт/403 терминал, ambiguous-mergeable, исчерпание ретраев, kill-switch one-shot, already-in-main без POST, create при коммитах сверх main, fail-OPEN на git-ошибке гарда, never-raise; `httpx` мокается, `time.sleep` → no-op), `tests/test_config.py` (TC-13: дефолты + env-override `ORCH_MERGE_RETRY_*`), `tests/test_merge_verify.py` (TC-14..TC-16: already-in-main пропускает `merge_pr`→done; исчерпание+SHA-not-in-main→HOLD; транзиент-успех→done). Обновлён `tests/test_orch082_ensure_pr.py` (гард запинён на create-путь — у гарда своё покрытие). Полный регресс `tests/ -q` зелёный (1389). ADR: `docs/work-items/ORCH-093/06-adr/ADR-001-merge-transient-retry-and-already-in-main-guard.md`, сквозной `docs/architecture/adr/adr-0027-merge-actor-transient-retry-and-already-in-main.md`.
- **Live-карточка трекера: полнота карты статусов, отражение откатов, суммирование метрик стадии по попыткам** (ORCH-091, `fix`): три верифицированных дефекта рендера Telegram-карточки (`src/notifications.py`, ORCH-067/087). **Аддитивно, never-raise, без нового поведения конвейера:** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / транспорт нотификаций / схема БД — **не тронуты** (затронут ровно один модуль индикативного слоя); kill-switch не требуется (рендер деградирует безопасно, откат = `git revert`).
-  - **Деф.1 — застрявший заголовок «To Analyse» (FR-1/2/3, AC-1/2/3):** `_STAGE_STATUS_LABEL` покрывал 8 из 10 ключей `STAGE_TRANSITIONS` — `deploy-staging` и `cancelled` (ORCH-090) выпадали в дефолт-«To Analyse» (ложный «первый статус» на стадии staging-деплоя). Карта расширена: `deploy-staging → "Deploying (staging)"` (plain-стиль активной стадии, суффикс «(staging)» снимает коллизию с prod-overlay `_LIVE_BRANCH_LABELS['deploying']` и с pause-лейблом `deploy`), `cancelled → "Cancelled"` (offline-база ORCH-090, совпадает с overlay-лейблом → нет конфликта precedence). Runtime-фолбэк `plane_status_label` для **немаппленной** (будущей/неизвестной) стадии заменён с «To Analyse» на **нейтральный** капитализированный лейбл (`_neutral_stage_label`, `"deploy-staging" → "Deploy Staging"`); `created` остаётся явным ключом → честная «To Analyse»; битый/None-вход → безопасный дефолт. Полнота карты гарантируется **программно** тестом, итерирующим `STAGE_TRANSITIONS.keys()` (единый источник истины) — новая стадия без курируемого лейбла даёт красный тест; автогенерация лейблов в самом модуле запрещена (карта остаётся курируемой/человекочитаемой).
-  - **Деф.2 — ложная картина при откате (FR-4, AC-4):** цикл рендера выводил `✅`-строку для каждой стадии с завершённым прогоном её агента **без учёта позиции** относительно текущей — после отката (`deploy-staging → development` ORCH-043, `review → development` REQUEST_CHANGES) карточка показывала абсурд «✅ Внедрение … + 🔄 Разработка». Введён лёгкий read-only хелпер `_pipeline_pos` от **порядка `STAGE_TRANSITIONS`** (не от `_TRACKER_STAGES`, который не содержит `deploy-staging`/`cancelled` и не авторитетен по порядку); гейт подавления: `✅`-строка рисуется только если `current_pos >= _pipeline_pos(stage_key)`. Нормализация `deploy-staging → deploy` применяется **только** к вычислению текущей позиции (схлопнутая строка «Внедрение» несёт `stage_key="deploy"`); `is_active_stage` — **без изменений** (нулевой регресс активного рендера). Подавлённые откатом прогоны по-прежнему входят в тоталы задачи (намеренная семантика отката).
-  - **Деф.3 — занижение метрик строки стадии (FR-5, AC-5):** `_stage_line` брал ПОСЛЕДНИЙ прогон (`last_done`), теряя предыдущие попытки (верифицировано на ORCH-069: developer 3 прогона Σ $3.98 → карточка показывала ~$0.00). Теперь `_stage_line` агрегирует **ВСЕ** `agent_runs` агента стадии теми же per-run-формулами, что и блок тоталов (`Σ cost_usd`, `Σ _input_total`, `Σ output_tokens`, `Σ _duration_seconds`); модель/эффорт/«попытка N» берутся из последнего прогона (`id ASC`). Каждый агент привязан ровно к одной строке `_TRACKER_STAGES` → строгий инвариант сходимости: Σ(строк стадий) ≡ тоталы задачи ≡ `SUM(agent_runs)` по `task_id`. Формат строк/тоталов и эффорт-суффикс (ORCH-087) — байт-в-байт.
-  - **Совместимость/регресс (NFR-2, AC-6):** In Review (brd-clock), Awaiting Deploy (`deploy`), Done, live-overlay ветки (Needs Input / Blocked / Rejected / Cancelled / Confirm Deploy / Deploying / Monitoring), строка «Подтверждение BRD», формат строк/тоталов, эффорт-суффикс — без изменений; все существующие тесты карточки зелёные. Перед правкой кода, помеченного ORCH-067/087/090, прочитаны их ADR — инварианты (single-card, never-raise, разделение offline-ядра и live-overlay, терминал `cancelled`) сохранены.
-  - Тесты: `tests/test_tracker_status_line.py` (ORCH-091 TC-01..TC-03: полнота карты от `STAGE_TRANSITIONS`, staging-лейбл, нейтральный фолбэк/never-raise; обновлён `test_tc06_*` под нейтральный фолбэк), новый `tests/test_tracker_rollback_metrics.py` (TC-05..TC-08: подавление `✅` при откате + анти-регресс forward-progress/`deploy-staging`-строка; суммирование метрик developer 3 прогона ≈ $3.98; сходимость тоталов с `SUM(agent_runs)`; never-raise на NULL-таймстампах/битой стадии). Полный регресс `tests/ -q` зелёный (1370). ADR: `docs/work-items/ORCH-091/06-adr/ADR-001-tracker-status-rollback-metrics.md`. Откат: `git revert` (docs/code-only, один модуль, без миграций/kill-switch).
- **Отмена задачи: Plane-статус STOP (остановка агента + полный сброс) + закрытие дыры релонча** (ORCH-090, `feat`): выделенный Plane-статус **STOP** — единый декларативный механизм отмены задачи вместо ручной хирургии по БД/процессам. Вводит **новое системное терминальное состояние `cancelled`** (стадия `tasks.stage='cancelled'` + job-исход `jobs.status='cancelled'`), равноправное `done`. **Аддитивно, под kill-switch, never-raise, restart-safe:** `STAGE_TRANSITIONS` (exit-гейты рёбер) / `QG_CHECKS` / `check_*` / семантика существующих статусов — **не тронуты** (`cancelled` — терминальный сток, не новое ребро); enduro не затронут; при `stop_status_enabled=false` — нулевая регрессия.
-  - **Распознавание (fail-closed):** новый логический ключ `stop` в `_PLANE_NAME_TO_KEY` (`"STOP" → "stop"`), **намеренно отсутствует** в `_DEFAULT_STATES` (по образцу `confirm_deploy`/ORCH-059) → доска без статуса STOP резолвит `None` → ветка не активируется (нет `KeyError`, нет слепой отмены). `handle_issue_updated` маршрутизирует `stop` → `handle_stop` → `stage_engine.cancel_task` (проверяется ПЕРВЫМ, до to_analyse/approved/rejected).
-  - **Полный сброс (вне критичного окна, AC-1..AC-4):** graceful SIGTERM активного агента через переиспользуемый каскад `launcher.stop_process` (вынесен из `_watchdog`: SIGTERM → grace → SIGKILL) по `jobs.pid`; `db.cancel_jobs_for_task` (queued/running → терминальный `cancelled`, нигде не реквью'ится — `claim_next_job` берёт только `queued`); `git_worktree.remove_worktree` + новый never-raise `src/gitea.py::delete_remote_branch` (удаляет **только** feature-ветку; `main`/`master` — явный гард-отказ; без force-push); durable `stage='cancelled'` + `cancelled_at`; **тумбстон** натуральных ключей суффиксом `#cancelled-<id>`. Docs-артефакты (`01..17`) сохраняются.
-  - **Уточнение ADR-001 D4 (при реализации):** ADR предлагал сохранить `plane_issue_id` нетронутым, но `get_task_by_plane_id`/`create_task_atomic` матчат по `plane_id OR plane_issue_id` — нетумбстоненный `plane_issue_id` заблокировал бы clean-slate re-create (BR-3/TR-4). Поэтому `plane_issue_id` тоже тумбстонится; исходный UUID (== исходный `plane_id` во всех путях создания) парсится из детерминированного суффикса для аудита. Зафиксировано в коде/`docs/architecture/README.md`/CLAUDE.md.
-  - **Безопасное прерывание merge/deploy (AC-7, NFR-3):** STOP в критическом окне → **отложенная отмена** (`cancel.in_critical_window` fail-CLOSED): durable `tasks.cancel_requested_at`, снимаются только `queued`-job'ы (running-актор деплоя/мержа не трогается), алерт; детерминированный `run_deploy_finalizer` доводит необратимый шаг до честного исхода и применяет отмену (`cancel_task(force=True)`; задача, дошедшая до `done`, — честный no-op, код уже в проде). «Критическое окно» = реально начатый необратимый шаг: self-deploy `INITIATED`-sentinel (ORCH-036; детач-деплой + поздний `merge_pr` в `_handle_merge_verify` идут под тем же маркером) **либо** держание merge-lease (ORCH-043) **И** активно бегущий актор (running-job). STOP **никогда** не трогает `main`/force-push/прод-контейнер/detached-процесс.
-  - **Фикс P1 (ORCH-090 review, attempt 2): deferred-cancel недостижим при STOP в ожидании `Confirm Deploy` → wedge.** Для self-hosting merge-lease держится от merge-gate (ребро `deploy-staging → deploy`) до `deploy → done`, включая всё время, пока задача **припаркована** на `deploy` в ожидании ручного `Confirm Deploy` (Phase A) — но это окно **полностью обратимо** (ничего не смержено/задеплоено; необратимый `merge_pr` идёт позже в `_handle_merge_verify` уже под `INITIATED`). Прежде голое держание lease классифицировалось как «критичное» → STOP уходил в deferred-ветку, отмену применял бы только `run_deploy_finalizer` (после Phase B), которого оператор, нажавший STOP именно чтобы НЕ деплоить, никогда не запустит → отмена **не применялась никогда**, задача застревала нетерминальной с удержанным lease, клиня serial-gate репо (ORCH-088) и мержи. Фикс: merge-lease-ветка `in_critical_window` сужена — критично, лишь когда lease держится **И** есть бегущий актор (`_task_has_running_actor`, running-job); припаркованное окно без актора → НЕ критично → немедленный полный сброс (сам отпускает lease в шаге 3c). Новые тесты `test_d7_lease_held_idle_parking_is_not_critical` / `test_d7_lease_held_with_running_actor_still_critical` / `test_d7_stop_on_deploy_awaiting_confirm_full_resets`.
-  - **Кросс-каттинг (adr-0026):** предикат «задача терминальна» расширен `{done}` → `{done, cancelled}` в `serial_gate.py` (ORCH-088: `repo_has_active_task`, claim-фрагмент, snapshot), `db.claim_next_job`/`get_unfinished_dependencies` (task_deps ORCH-026) и `stages.py`-сток — иначе отменённая задача заклинила бы очередь репо (TR-1); reconciler-терминал-скип уже знал `cancelled` (ORCH-086 D2). `job_reaper`/`queue_worker` ПЕРЕД авто-requeue сверяют терминал задачи → помечают job `cancelled`, не реквью'ят (закрыта гонка SIGTERM/reaper, TR-2).
-  - **Закрытие дыры релонча (AC-5, D6):** `handle_status_start` больше не релончит агента середины пайплайна при ручном переводе в промежуточный статус — relaunch ограничен стадией `analysis` (единственный владелец Needs Input, ORCH-066); единственный вход к запуску пайплайна остаётся «To Analyse» (`start_pipeline`). Под `stop_status_enabled=false` гейт инертен (1:1 как раньше).
-  - **Флаги/наблюдаемость:** `stop_status_enabled` (kill-switch, env `ORCH_STOP_STATUS_ENABLED`) + `stop_status_repos` (CSV, пусто → все репо); leaf `src/cancel.py` (`applies`/`in_critical_window`/`snapshot`, never-raise); read-only блок `stop` в `GET /queue`; лог + Telegram (кликабельный номер) + Plane-коммент + `update_task_tracker`. Аддитивные идемпотентные миграции (`_ensure_column` для `cancelled_at`/`cancel_requested_at`). **Инфра-предусловие:** создать статус **STOP** с группой `cancelled` на доске Plane проекта ORCH (его отсутствие = fail-safe no-op).
-  - Тесты: `tests/test_stop_status.py` (TC-01..TC-14 + D7-кейсы, включая 3 новых P1-кейса для окна «припаркован на `deploy`, ждёт Confirm Deploy»; SIGTERM/git/gitea замоканы — ни один тест не шлёт сигнал/не трогает сеть); обновлены анти-регресс-тесты STAGE_TRANSITIONS 5 прошлых задач (добавлен терминал-сток `cancelled`); полный регресс `tests/` зелёный (1348). Документация: `docs/architecture/README.md` (статус «реализовано» + блок `/queue` + раздел БД), `CLAUDE.md`, `README.md`, `.env.example`. ADR: `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`, сквозной `docs/architecture/adr/adr-0026-stop-cancel-task.md`. Откат: `ORCH_STOP_STATUS_ENABLED=false` (аддитивные колонки/терминал-набор инертны при отсутствии отменённых задач).
- **Build-cache-pruner: авто-prune docker build cache на mva154** (ORCH-062, `feat`): новый фоновый daemon-поток `src/build_cache_pruner.py` (каркас `disk_watchdog`) — «вторая половина» disk-watchdog (ORCH-063): **watchdog сигналит — pruner убирает**. Устраняет корень инцидента 07.06.2026 (docker build cache ≈11 ГБ → диск mva154 100% → падение self-hosting-конвейера всех проектов) **автоматически, без оператора**. **Аддитивно, never-raise:** `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/`_parse_*`/`src/stage_engine.py`/схема БД — **не тронуты**, новой миграции нет (состояние last-run/last-result — in-memory, best-effort).
-  - **Периодическая уборка (FR-1/AC-1):** каждые `build_cache_prune_interval_s` (дефолт **21600с = 6ч**) тик выполняет **строго `docker builder prune -f --filter until=<until>`** (BuildKit GC). Анти-частота — pure-функция `decide_prune(prev_run_ts, now, interval_s)` (юнит-тестируема без потока/таймера, время инъецируется). Дефолт `until=24h` удерживает тёплый недавний кэш (BR-2/AC-2); `-a/--all` (`build_cache_prune_all`, дефолт `False`) — **только в паре** с возрастным фильтром.
-  - **Self-hosting безопасность (FR-3/AC-3):** команда затрагивает **только** build cache — **нет** `docker image prune`/`docker system prune`, удаления образов/контейнеров запущенных сервисов, остановки/рестарта контейнеров; прод-контейнер `orchestrator` **никогда** не рестартится. Уборка исполняется **на хосте через ssh** (`deploy_ssh_user@deploy_ssh_host`, тот же канал, что `image_freshness`/`self_deploy` — в образе нет docker CLI). Нет ssh-таргета → тик no-op (наблюдаемо в `status().last_error`).
-  - **never-raise (FR-6/AC-4):** per-команда (ненулевой rc / `TimeoutExpired` / `OSError`/`FileNotFoundError` / недоступность ssh / parsing-ошибка → лог + проглот, тик жив) и per-tick (внешний `try/except` в `_run`, как `disk_watchdog`). Фоновый цикл и конвейер не падают.
-  - **Конфигурируемость + kill-switch (FR-5/AC-5/AC-6):** флаги `build_cache_prune_enabled`/`_interval_s`/`_until`/`_all`/`_timeout_s`/`_notify_min_gb` (`src/config.py`, env `ORCH_BUILD_CACHE_PRUNE_*`) с defensive-валидацией (интервал/таймаут >0, `until` ~ `^\d+[smhdw]?$`, notify_min_gb ≥0 → невалидное к безопасному дефолту + warning, старт не падает). `build_cache_prune_enabled=false` → демон не стартует (старт/стоп в `main.lifespan` рядом с `disk_watchdog`, гард), `GET /queue` → `{"enabled": false}` — поведение 1:1 как до задачи.
-  - **Наблюдаемость (FR-4/AC-7):** аддитивный read-only блок `build_cache_prune` в `GET /queue` (`enabled`/`interval_s`/`until`/`all`/`last_run_ts`/`last_reclaimed`[+`_bytes`]/`last_error`); `status()` never-raise. Опц. Telegram при освобождении ≥ `notify_min_gb` ГБ (дефолт `0` = тихо). Тесты: `tests/test_build_cache_pruner.py` (TC-01..TC-12, 23 кейса, docker замокан — ни один тест не трогает реальный docker); полный регресс `tests/` зелёный (1319). Документация: `docs/operations/INFRA.md` (секция авто-prune + env-карта; снята формулировка ORCH-063 «освобождение build cache — ручная операция»), `docs/architecture/README.md`, `.env.example`. ADR: `docs/work-items/ORCH-062/06-adr/ADR-001-build-cache-pruner.md`, сквозной `docs/architecture/adr/adr-0025-build-cache-pruner.md`. Откат: `ORCH_BUILD_CACHE_PRUNE_ENABLED=false` (миграций нет).
- **Disk-watchdog: мониторинг заполнения диска mva154 + Telegram-алерт при ≥85%** (ORCH-063, `feat`): новый фоновый daemon-поток `src/disk_watchdog.py` (каркас `reconciler`/`job_reaper`) — недостающий **проактивный** сигнал о заполнении хост-диска (07.06.2026 диск mva154 тихо дорос до 100% и положил весь self-hosting-конвейер всех проектов). **Аддитивно, never-raise:** `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД — **не тронуты**, новой миграции нет (состояние анти-спама — in-memory).
-  - **Замер хост-ФС (FR-2/AC-8):** каждые `disk_monitor_interval_s` (дефолт 300с) меряет заполнение **смонтированных хост-bind-путей** (`/repos`, `/app/data`) через stdlib `shutil.disk_usage` — НЕ overlay `/` контейнера, НЕ субпроцесс `df`; дедуп путей по физическому устройству (`st_dev`) → один алерт на раздел. Недоступный путь → пропуск с warning, остальные пути меряются (per-path never-raise).
-  - **Решение об алерте (FR-3/FR-4/AC-2..AC-4):** pure-функция `decide_action(used_pct, threshold, prev_state, now, realert_s)` (юнит-тестируема без потока/таймера, время инъецируется): алерт на пересечении порога (дефолт **85%**, граница `>=` включительно), cooldown-повтор `disk_monitor_realert_s` (~6ч, анти-спам — не на каждом тике), однократный recovery при возврате ниже порога. Алерт — `send_telegram` (notifying, не silent), best-effort.
-  - **Конфигурируемость + kill-switch (FR-5/AC-5):** флаги `disk_monitor_enabled`/`_interval_s`/`_threshold_pct`/`_realert_s`/`_paths` (`src/config.py`, env `ORCH_DISK_MONITOR_*`) с defensive-валидацией (порог 1..100, интервалы > 0 → невалидное к дефолту + warning). `disk_monitor_enabled=false` → демон не стартует (старт/стоп в `main.lifespan`, гард), `GET /queue` → `{"enabled": false}` — поведение 1:1 как сейчас.
-  - **Наблюдаемость (FR-6/AC-7):** аддитивный read-only блок `disk_monitor` в `GET /queue` (`enabled`/`threshold_pct`/`interval_s`/`realert_s`/`last_run_ts`/`paths`[`used_pct`/`free_gb`/`free_pct`/`alerting`/`last_alert_at`]); существующие ключи `/queue` не изменены; `status()` never-raise.
-  - **Self-hosting безопасность (NFR-6):** watchdog только читает заполнение и шлёт уведомление — не трогает диск/контейнер, не рестартит прод; безопасен для enduro-trails в общем инстансе. Откат тривиален (`ORCH_DISK_MONITOR_ENABLED=false`, миграций нет). Тесты: `tests/test_disk_watchdog.py` (TC-01..TC-12, 18 кейсов); полный регресс `tests/` зелёный (1296). Документация: `docs/architecture/README.md` (компонент + блок `/queue`), `docs/operations/INFRA.md` (что мониторится/порог/как отключить/реакция на алерт), `.env.example`. ADR: `docs/work-items/ORCH-063/06-adr/ADR-001-disk-watchdog.md`, сквозной `docs/architecture/adr/adr-0024-disk-watchdog.md`.
- **Промпт-аудит 6 агентов: расхардкод даты/модели, сверка гейтов, escalation, чистка** (ORCH-092 / эпилог эпика ORCH-52, `docs`): точечная правка 6 системных промптов `.openclaw/agents/*.md` + анти-регресс-тестов, устраняющая класс дефектов промптов (хардкод даты/модели в примерах, размазанная эскалация, нереализуемая/конфликтующая инструкция rebase, мёртвая инструкция reviewer, недообогащённый tester). **Docs/prompts-only:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, состав machine-verdict ключей и схема БД — **не тронуты**; `frontmatter_validation_strict` остаётся `False`. Машинные verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:` + значения APPROVED/REQUEST_CHANGES/PASS/FAIL/SUCCESS/FAILED) и канон 52d/52c/52e (5 секций, 6 полей) — байт-в-байт.
-  - **Расхардкод даты/модели (FR-1/FR-2, AC-1/AC-2):** во всех 6 промптах копируемые примеры frontmatter несут плейсхолдеры `created_at: <YYYY-MM-DD>` / `model_used: <resolve ORCH-41>` + явную врезку «не копируй буквально: подставь `date +%F` и фактическую модель из конфига». Литерал `claude-opus-4-8` остаётся лишь как справка в таблице полей (вне копируемого блока).
-  - **Сверка имён гейтов (FR-3, AC-3):** все `check_*` в 6 промптах сверены с реестром `QG_CHECKS` — несовпадений нет (`check_tests_passed` подтверждён валидным, не «исправлен вслепую»); закреплено интеграционным тестом.
-  - **developer (FR-4/FR-5/FR-9):** «❌ PR>1500 → разбивай на меньшие PR» переформулирован в эскалацию (слишком большой PR = декомпозиция **на уровне задач**, 1 задача = 1 ветка = 1 PR); добавлена секция `<escalation>` (негодное ТЗ → `back-to:analysis`; новая развилка → к архитектору); **убран ручной `git rebase origin/main`** из алгоритма (ADR-001 D1: свежесть базы — инвариант движка serial-gate ORCH-088 + `auto_rebase_onto_main` под merge-lease, а не ручная мутирующая операция агента, конфликтующая с запретом force-push).
-  - **reviewer (FR-5/FR-8):** удалена мёртвая инструкция «не апрувь PR от того же экземпляра Developer» (защита от несуществующего кейса — reviewer всегда отдельный agent-run); добавлена секция `<escalation>` (любой P0/P1 → `REQUEST_CHANGES`). Живые инварианты (`REQUEST_CHANGES`, «НЕ обновлена», ось трассировки, ось обзорных доков ORCH-079) сохранены.
-  - **tester (FR-5/FR-7):** обогащён — тесты гоняются в **worktree ветки задачи** (а не в общем `/repos/orchestrator` → исключена гонка checkout); smoke `/queue` проверяет наличие блока `serial_gate` (ORCH-088); `<success_criteria>` требует покрытия **каждого** TC из `04-test-plan.yaml`; добавлена секция `<escalation>` (обоснованный FAIL → `back-to:dev`; смок-сбой инфры → FAIL с диагностикой).
-  - **deployer (FR-6/FR-10):** критичные self-hosting-запреты подняты в **видную рамку в начале** `<context>` («NEVER restart prod 8500», запрет `docker compose up`/правок инфры); язык оставлен **английским** как зафиксированное исключение канона (ADR-001 D2: самый safety-critical промпт, минимизация регресс-поверхности; перевод не несёт выгоды и угрожает байт-точности ключей/команд). Анти-регресс-маркеры (`docker exec orchestrator-staging`, `pr_already_merged`, `8500`, `INFRA-WAIVED`) сохранены.
-  - **Анти-регресс (FR-11):** в `tests/test_agent_prompts_canon.py` добавлены структурные TC (плейсхолдеры даты/модели в копируемых блоках; сверка гейтов с `QG_CHECKS`; `<escalation>` у developer/reviewer/tester после `</success_criteria>`; переформулировка PR-инструкции; обогащение tester; рамка deployer; удаление мёртвой строки reviewer). Существующие проверки канона 52d и `test_agent_frontmatter_no_model.py` — зелёные; полный регресс `tests/` зелёный (1278). Документация: 6 промптов, `CLAUDE.md`, `docs/architecture/README.md`. ADR: `docs/work-items/ORCH-092/06-adr/ADR-001-developer-rebase-and-deployer-language.md`. Полностью обратимо `git revert` (нет машинного поведения/состояния).
- **Синхронизация обзорных доков (README) с кодом + reviewer-ось «обзорные доки»** (ORCH-079 / ORCH-52f, `docs`): слой 5 (финал) эпика ORCH-52, замыкающий цепочку 52b (структура) / 52c (frontmatter) / 52d (промпты) / 52e (трассировка). Корневой `README.md` — обзорная витрина проекта — **выдавал решённое за открытое**: секция «Известные ограничения» имела битую нумерацию (`1,2,3,4,3,4`) и пункты, опровергнутые кодом. **Docs + prompt-only:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`/`_parse_*`, `src/frontmatter.py`, схема БД — **не тронуты**; `frontmatter_validation_strict` остаётся `False`; новый QG не вводится; правило обзорных доков нормативно-описательное (не машинный гейт), как ось трассировки ORCH-078.
-  - **`README.md` приведён в честное состояние по коду (FR-1/FR-2/FR-3, AC-1/AC-2/AC-3):** перенумерация «Известные ограничения» сквозная без повторов; 6 решённых/устаревших пунктов перенесены в трейл **«Закрыто (история)»** с ORCH-ссылками (worktree → `ensure_worktree`+ORCH-026/088; in-process daemon → очередь ORCH-1; «Gitea CI не настроен» → `check_ci_green`; «no retry» → backoff/breaker `queue_worker.py`+ORCH-045; issue-ID → зрелый `plane_sync` ORCH-010/066/068; Playwright-timeout → watchdog ORCH-7); в «открытых» — только реально открытые, верифицированные кодом/задачей (Telegram-48h ORCH-087, task-deps intra-repo v1 ORCH-026, serial-gate Этап 1 ORCH-088). Точечная сверка с кодом: стадия `development` в таблице — `check_ci_green` (был устаревший `check_tests_local`); строка event-routing `status` — авторитетный гейт развития `check_ci_green` (ORCH-045), убран legacy-текст «больше не authoritative».
-  - **Reviewer-ось «обзорные доки» (FR-5, AC-5):** `.openclaw/agents/reviewer.md` ось 4 «Документация» (`<task>`) + `<constraints>` несут точечную врезку «❌→✅» (канон 52d): *PR закрыл пункт README «Известные ограничения», README не обновлён → finding ≥P1*; при закрытии правкой `src/` без обновления README — совпадает с существующим P0. Машинный ключ `verdict: APPROVED|REQUEST_CHANGES` — байт-в-байт; 5 XML-секций и 6 полей схемы 52c сохранены. Правило в одном промпте (без выноса в `docs/_standards/`, в отличие от 52e).
-  - **Эпик ORCH-52 закрыт:** 52b (adr-0019) → 52c (adr-0020) → 52d (adr-0021) → 52e (adr-0022) → **52f (adr-0023)**. Сквозной `docs/architecture/adr/adr-0023-overview-docs-reviewer-axis-and-epic52-close.md` + per-work-item `docs/work-items/ORCH-079/06-adr/ADR-001-readme-sync-and-reviewer-overview-docs-axis.md`.
-  - **Анти-регресс (FR-6, AC-6):** новый структурный `tests/test_readme_limitations.py` (нумерация без повторов; решённые пункты не значатся открытыми; трейл «Закрыто» с ORCH-ссылками); расширен `tests/test_agent_prompts_canon.py` (assert наличия оси обзорных доков в `reviewer.md`); канон 52d (5 секций, 6 полей, регистр verdict-ключей) и `test_agent_frontmatter_no_model.py` зелёные; полный регресс `tests/` зелёный (1257). Документация: `README.md`, `docs/architecture/README.md` (слой 5 эпика 52), `CLAUDE.md`. Полностью обратимо `git revert` (нет машинного поведения/состояния/kill-switch).
- **Стандарт маркеров-трассировки `ORCH-NNN` + правило чтения ADR перед правкой** (ORCH-078 / ORCH-52e, `docs`): слой 4 (трассировка) эпика ORCH-52, замыкающий цепочку 52b (структура) / 52c (frontmatter) / 52d (промпты). Маркеры `ORCH-NNN`/`ET-NNN` в коде (де-факто 51 уникальный в `src/`) привязывают нетривиальные инварианты к породившему их work item — была сложившаяся практика без формального контракта. **Docs + prompts-only:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`/`_parse_*`, `src/frontmatter.py`, схема БД — **не тронуты**; `frontmatter_validation_strict` остаётся `False`; новый QG не вводится; массовый ретро-фит 51 маркера вне объёма (стандарт нормативен «на будущее»).
-  - **Новый стандарт `docs/_standards/TRACEABILITY.md`** (рядом с `PIPELINE_DOCS.md`/`HANDOFF_PROTOCOL.md`): формат маркера, правило размещения (рядом с нетривиальным инвариантом), чтение истории с реальным проверяемым примером (`src/serial_gate.py` → ORCH-088 → `ADR-001-serial-gate.md`), fallback-доступ (`git show origin/main:docs/work-items/...`), анти-археология (3+ маркеров → сводный сквозной ADR), каноничный текст правила чтения (единый источник).
-  - **Точечные врезки в промпты (аддитивно, 52d-канон не переписан):** `developer.md` — правило чтения чужого маркера + fallback («❌ X → ✅ Y»); `architect.md` — правило чтения + анти-археология (3+ → сквозной ADR); `reviewer.md` — усиление оси «Соответствие ADR» под-пунктом «правка маркированного кода сверена с ADR; слом → finding ≥P1». Все три **ссылаются** на единый текст в `TRACEABILITY.md`, не копируют (анти-дубль BR-6).
-  - **Сопутствующе:** `CLAUDE.md` (правило трассировки + ссылка), `docs/architecture/README.md` (слой 4 эпика 52), сквозной `adr-0022` + per-work-item `ORCH-078/06-adr/ADR-001`. **Анти-регресс:** расширен `tests/test_agent_prompts_canon.py` (наличие правила/ссылок в 3 промптах, существование примера в стандарте); проверки 52d (5 секций, 6 полей, регистр verdict-ключей) и `test_agent_frontmatter_no_model.py` остаются зелёными. Полностью обратимо `git revert` (нет машинного поведения/состояния/kill-switch).
- **Канон Anthropic для 6 системных промптов + добровольная эмиссия frontmatter-схемы 52c** (ORCH-077 / ORCH-52d, `docs`): замыкающий слой эпика ORCH-52. 52c заложила writer + валидатор обязательной схемы (`REQUIRED_FIELDS`), но он работал warning-only «вхолостую» — 6 промптов `.openclaw/agents/*.md` **не эмитили** поля схемы. ORCH-077 учит все 6 промптов её эмитить и переписывает их в едином каноне Anthropic. **Docs/prompts-only:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, состав machine-verdict ключей и схема БД — **не тронуты**; `frontmatter_validation_strict` остаётся `False` (эмиссия добровольная, enforcement НЕ включён).
-  - **Единый XML-скелет (5 обязательных секций, нормативный порядок):** `<context>` → `<task>` (+ опц. `<thinking>` у решающих ролей: architect/reviewer/tester/deployer) → `<deliverables>` → `<constraints>` (запреты «❌ X → ✅ Y») → `<output_format>`. Доп. секции (`<success_criteria>`/`<escalation>`) — после пяти обязательных.
-  - **Аддитивная схема 52c:** `<output_format>` каждого промпта перечисляет 6 полей (`work_item`/`stage`/`author_agent`/`status`/`created_at`/`model_used`) с роле-специфичными значениями (`stage`/`author_agent` по карте ролей; `model_used: claude-opus-4-8` по резолву ORCH-41) и ставит их **рядом** с machine-verdict ключом, **не меняя его имя/регистр/значения** (`verdict:` `APPROVED|REQUEST_CHANGES`; `result:` `PASS|FAIL`; `staging_status:`/`deploy_status:` `SUCCESS|FAILED`; `security_status:` `PASS|FAIL`). Для `04-test-plan.yaml` — top-level YAML-ключи. Гейты читают вердикты 1:1 как раньше (NFR-1).
-  - **Loading-model:** промпт `cat`-ается из git-worktree агента в момент запуска (`launcher --system-prompt "$(cat .openclaw/agents/<role>.md)"`), НЕ запекается в образ → новые промпты вступают в силу на следующем worktree от `main` **без прод-рестарта**; reviewer/tester той же задачи исполняются уже под новыми промптами (in-vivo A/B, BR-6).
-  - **Анти-регресс (критично, self-hosting):** функциональное содержание старых промптов перенесено 1:1 (инвентарь TRZ §FR-6 — Write-tool/4 deliverable у analyst; ADR-формат/сквозной ADR/эскалация у architect; TDD/«не мержить свой PR»/`--no-verify`/`--force-push`/«не рестартить прод» у developer; правило «src/ изменён, доки нет → REQUEST_CHANGES» у reviewer; pytest+smoke `/health`/`/status`/`/queue` у tester; canonical `docker exec orchestrator-staging … staging_check.py`, B6-обоснование, ORCH-061 `INFRA-WAIVED`, merge-guard `pr_already_merged`, «не рестартить 8500 изнутри» у deployer). Защита — структурные тесты `tests/test_agent_prompts_canon.py` (TC-01…TC-07: 5 XML-секций, 6 полей схемы, точный регистр verdict-ключей, роле-специфичные `author_agent`/`stage`, ссылки на `docs/_templates/`+эталоны ORCH-073/088, self-hosting-маркеры deployer); существующий `tests/test_agent_frontmatter_no_model.py` (ORCH-074) остаётся зелёным (frontmatter промпта `name`/`description`/`tools` сохранён, `model:` нет).
-  - **A/B (BR-6/AC-6):** метод зафиксирован в `tests/manual/ab_prompt_compare.md` (in-vivo: reviewer/tester самой ORCH-077 уже под новыми промптами); результат «новый не хуже» фиксирует тестер в `13-test-report.md`. **Обратимость:** `git revert` PR — нет миграций/состояния. **Норматив на будущее:** новые/изменённые агент-промпты следуют этому канону.
-  - Документация: `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md`, `CLAUDE.md`, `docs/architecture/README.md`. ADR: `docs/work-items/ORCH-077/06-adr/ADR-001-anthropic-prompt-canon.md`, сквозной `docs/architecture/adr/adr-0021-prompt-canon-anthropic.md`.
- **Единый frontmatter-контракт (reader + writer + валидатор) + спека handoff** (ORCH-076 / ORCH-52c, `refactor`/`docs`): слой 2 эпика ORCH-52 — `src/frontmatter.py` из single-key reader превращён в **полный машинный контракт**, а **разрознённое чтение вердиктов** пяти гейтов сведено к **одной точке парсинга**. Строго обратно совместимо, never-raise; `STAGE_TRANSITIONS` / состав `QG_CHECKS` / семантика вердиктов / fallback `worktree→origin/main` / трёх-полевой контракт tester (ORCH-047) — **1:1, без изменений**.
-  - **`src/frontmatter.py` (контракт):** сохранён reader `read_frontmatter_value` (контракт неизменен — внешние вызыватели `usage.py` / `notifications.build_status_comment` не затронуты, INV-3); добавлены единый парс-примитив `parse_frontmatter(content) -> FrontmatterParse` (`data/has_block/malformed/yaml_error` — единственная точка YAML-логики) + ярлыки `parse_frontmatter_dict` / `read_frontmatter`; writer `render_frontmatter`/`write_frontmatter` (формат байт-совместим с `split("---",2)`+`yaml.safe_load`, round-trip render→parse); валидатор схемы `validate_schema`/`SchemaValidation`/`REQUIRED_FIELDS` (`work_item/stage/author_agent/status/created_at/model_used`); общий `strip_frontmatter`. Весь модуль — **never-raise** (NFR-2): любая ошибка I/O/YAML/сериализации → лог + безопасное значение (`{}`/`False`/исходный текст).
-  - **Унифицирован МЕХАНИЗМ, а не семантика (D2):** пять вердикт-парсеров — `check_reviewer_verdict` (`verdict:`), `_parse_tests_verdict` (`result:`/`verdict:`/`status:`, ORCH-047), `_parse_deploy_status` (`deploy_status:`), `_parse_staging_status` (`staging_status:`) в `src/qg/checks.py`; `parse_security_status` (`security_status:`) в `src/security_gate.py` — заменили дублированный блок `startswith/split/safe_load/isinstance` на `parse_frontmatter(content)`; token-логика, upper-casing, приоритет негативного токена, reason-строки — сохранены 1:1. Также сняты дубли в `security_gate.extract_security_findings` и `review_parse._strip_frontmatter` (делегируют `strip_frontmatter`).
-  - **Валидатор не hard-fail по умолчанию (D3, критично для self-hosting):** `maybe_warn_schema` при дефолте только логирует `logger.warning("frontmatter schema incomplete: …")` и **никогда не влияет на boolean-вердикт** гейта (инертен). Жёсткий режим — ТОЛЬКО под kill-switch `frontmatter_validation_strict` (env `ORCH_FRONTMATTER_VALIDATION_STRICT`, дефолт `False`; остаётся `False` в проде/`.env.staging`, иначе ORCH-52c self-block'нулась бы — её доки без полной схемы). Схема **аддитивна**: старый док-вердикт без новых полей читается ровно как раньше (FR-5/AC-4).
-  - **Спека handoff:** новый `docs/_standards/HANDOFF_PROTOCOL.md` — формальный контракт «стадия → обязательные документы + frontmatter-ключи на выходе» + обязательная схема (`REQUIRED_FIELDS`), согласован 1:1 с `PIPELINE_DOCS.md` §2–§3; `PIPELINE_DOCS.md` §5–§6 обновлён (слой 2 реализован, ссылка на спеку и `src/frontmatter.py`).
-  - **Без изменений API / схемы БД** (INV-5). Тесты: `tests/test_frontmatter.py` (TC-01…TC-07: writer/round-trip/валидатор/strict/never-raise/reader), `tests/test_qg_verdicts.py` (TC-08…TC-15: семантика пяти гейтов 1:1, обратная совместимость, fallback origin/main), `tests/test_security_gate.py` (TC-12), `tests/test_stages_invariants.py` (TC-16: `QG_CHECKS`/`STAGE_TRANSITIONS` неизменны). Полный регресс `tests/` зелёный (1212). Конфиг: `src/config.py` (`frontmatter_validation_strict`). Документация: `CLAUDE.md`, `docs/architecture/README.md`. ADR: `docs/work-items/ORCH-076/06-adr/ADR-001-frontmatter-contract.md`, сквозной `docs/architecture/adr/adr-0020-frontmatter-contract.md`.
- **Стандарт документов конвейера: `docs/_standards/PIPELINE_DOCS.md` + `docs/_templates/` + ADR-naming** (ORCH-075 / ORCH-52b, `docs`): зафиксирован golden source структуры номерных документов work item (`00-business-request.md` … `17-security-report.md`). **Docs-only**, нулевой рантайм-риск: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / `src/stage_engine.py` / схема БД — **не трогаются** (изменения только под `docs/**` + `CLAUDE.md`).
-  - **Манифест** `docs/_standards/PIPELINE_DOCS.md` — карта «стадия → агент → документ → категория (`required`/`when-applicable`/`optional`) → гейт/механизм → frontmatter machine-key», сверенная с `src/stages.py` (`STAGE_TRANSITIONS`) и `src/qg/checks.py` (`_parse_*`). Манифест **документирует** поведение гейтов, но НЕ источник истины (источник — код, ADR-001 §D2); честно различает machine-verdict доки (`12`→`verdict:`, `13`→`result:`, `14`→`deploy_status:`, `15`→`staging_status:`, `17`→`security_status:`) и информационные (`00/08/10/16` — гейтом не парсятся). Под-гейты ребра `deploy-staging→deploy` (security/merge/image-freshness) помечены как врезки в `advance_stage`, а не строки `STAGE_TRANSITIONS`.
-  - **Шаблоны** `docs/_templates/*` (15 копируемых скелетов) — для каждого `required`/`when-applicable` дока; машинные доки несут точный frontmatter-ключ из ground-truth (`_parse_*`), чтобы скопированный скелет проходил гейт без угадывания. Служебные каталоги `docs/_standards/` / `docs/_templates/` лежат ВНЕ `docs/work-items/<plane-id>/` → невидимы гейтам наличия файлов (`check_architecture_done`/`check_analysis_complete`).
-  - **ADR-naming** зафиксирован: `docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md` (NNN с `001`); сквозные решения дублируются в `docs/architecture/adr/adr-NNNN-<slug>.md` (4-значная нумерация). Точки-ссылки: `CLAUDE.md` (раздел «Артефакты задачи» + правило 2), `docs/architecture/README.md` (раздел «Стандарт документов конвейера»). Тесты: `tests/test_orch_52b_docs_standard.py` (TC-01…TC-20, структурные проверки наличия/секций/frontmatter). ADR: `docs/work-items/ORCH-075/06-adr/ADR-001-pipeline-docs-standard.md`, сквозной `docs/architecture/adr/adr-0019-pipeline-docs-standard.md`.
- **Авто-режим по лейблам: autoApprove (авто-BRD) + autoDeploy (авто-деплой)** (ORCH-089, `feat`): сняты **два** человеческих гейта конвейера, тормозящих пакетный автономный прогон (эпик ORCH-088) — гейт BRD (`analysis`: ручной `Approved`) и гейт прод-деплоя (`deploy` Phase A: ручной `Confirm Deploy`, ORCH-059). Решение выборочно (лейбл Plane на задаче), декларативно, обратимо и **не трогает ни одной технической проверки**. Аддитивно по образцу условных под-гейтов (ORCH-035/043/058/088): leaf `src/labels.py` (never-raise) + две точечные врезки + флаги; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД — **без изменений**.
-  - **`autoApprove`** → врезка в `stage_engine._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`). Без дублирования переходной логики; re-entrancy безопасна (вложенный вызов идёт с `finished_agent=None`, не входит в analyst-ветку).
-  - **`autoDeploy`** → врезка в `stage_engine._handle_self_deploy_phase_a` сразу после advance на `deploy`+`clear_state` (ДО «ask-human»): лог/Telegram/Plane-коммент + `_handle_self_deploy_phase_b(...)` (idempotency-маркер `INITIATED`, статус `Deploying`, finalizer). Пропускаются лишь индикативно-человеческие шаги (`APPROVE_REQUESTED`+`Awaiting Deploy`+«смените на Confirm Deploy»). **BR-5 структурно:** Phase A достигается только после зелёных под-гейтов ребра `deploy-staging → deploy` (security → merge-gate → image-freshness → staging) → autoDeploy физически не деплоит сломанное.
-  - **Чтение лейблов** — `plane_sync.fetch_issue_labels` (поле `labels` issue; `None` при ошибке ≠ `[]`) + `get_project_labels` (`{normalized_name→uuid}`, TTL-кэш `auto_label_states_ttl_s` по образцу `get_project_states`); сопоставление по нормализованному имени (`strip().casefold()`), неоднозначность (две метки → одно нормализованное имя) → сентинел `__AMBIGUOUS__` → «нет лейбла». Новый сеттер `set_issue_approved` (ключ `approved` уже в `_DEFAULT_STATES`). Источник истины — Plane API, не payload вебхука.
-  - **Флаги** (`config.py`): `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` → при выключенном флаге нулевой сетевой оверхед, нулевая регрессия для enduro (AC-8).
-  - **Fail-safe (never auto):** любая ошибка/недоступность Plane/неоднозначность → «нет авто» → ручной гейт (never-raise, AC-6). **Прозрачность (AC-7):** лог + Telegram + Plane-коммент + live-карточка через штатный advance. Read-only блок `auto_labels` в `GET /queue`.
-  - **Инфра-предусловие:** создать лейблы `autoApprove`/`autoDeploy` в Plane-проекте ORCH (labels API); их отсутствие = `has_label` False = ручной режим (fail-safe). Детали — `docs/work-items/ORCH-089/07-infra-requirements.md`.
-  - Тесты: `tests/test_labels.py`, `test_plane_sync_labels.py`, `test_auto_approve_brd.py`, `test_auto_deploy.py`, `test_auto_label_combinations.py`, `test_auto_labels_integration.py`, `test_auto_labels_invariants.py` (TC-01…TC-26). ADR: `docs/work-items/ORCH-089/06-adr/ADR-001-auto-label-gates.md`, global `docs/architecture/adr/adr-0018-auto-label-gates.md`.
- **Per-repo serial gate: пакетный автономный режим (Этап 1, serial e2e)** (ORCH-088, `feat`): закрыт **логический** stale-анализ — ветка задачи N+1 срезалась на входе в анализ (`start_pipeline._create_gitea_branch`) от `main`, ещё не содержащего код предшественника N (физическое затирание уже закрыто ORCH-026). Новая задача репо не входит в `analysis` (не режет ветку, не запускает analyst), пока в репо есть незавершённая задача или репо заморожен. Аддитивно, под kill-switch, область репо, never-raise, restart-safe; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*` — **без изменений**.
-  - **Gate-в-claim** (`db.claim_next_job`): analyst-job (`jobs.agent='analyst'`) применимого репо не выбирается, если `EXISTS` **более ранняя** незавершённая задача репо (`t2.id < jobs.task_id`) ИЛИ активна строка `repo_freeze`. Фрагмент строится в leaf `src/serial_gate.py::build_claim_clause` (санитизация repo-токенов `^[A-Za-z0-9._-]+$`, **fail-OPEN** на любой ошибке построения — не заклинить очередь всех проектов, AC-8); только локальная БД (offline hot-path, NFR-2). Job'ы уже активной задачи проходят свободно. **FIFO-уточнение реализации (FR-2):** ADR-001 D1 фиксировал псевдо-SQL `t2.id != jobs.task_id`; при `!=` пакет одновременно созданных свежих задач (все в `analysis`) взаимно блокировался бы → дедлок всей serial-очереди (воспроизведено). `<` допускает ровно самую раннюю задачу и сериализует остальные за ней (строго по одной, FIFO по `jobs.id`), сохраняя AC-1 и не блокируя rework-analyst собственной задачи (R-7).
-  - **Отложенный срез ветки (анти-stale-base, AC-6):** для применимого репо `start_pipeline` создаёт task-row + enqueue analyst, но **не** создаёт Gitea-ветку/docs; срез релоцирован в `launcher._spawn` (новый `_materialize_deferred_branch`, sync через `asyncio.run` в worker-потоке, R-4) на момент claim analyst-job, когда `origin/main` уже содержит предшественника (`done` ⇔ SHA-в-main, ORCH-071/073). `ensure_worktree` режет от свежего `origin/main` ⇒ AC-6 структурно. Идемпотентно (`_create_gitea_branch` 409 / `_create_initial_docs` 422 = no-op) → безопасно при реклейме/рестарте. Ожидающая задача = `queued` analyst-job без ветки; `tasks.branch` хранится как имя (R-5).
-  - **Durable per-repo freeze (FR-5):** новая аддитивная append-only таблица `repo_freeze(id, repo, frozen_at, reason, work_item_id, cleared_at)` (`CREATE TABLE/INDEX IF NOT EXISTS` в `init_db`, идемпотентно, restart-safe). Post-deploy `DEGRADED` (`stage_engine.run_post_deploy_monitor`) → `serial_gate.set_repo_freeze` + Telegram-алерт «пакет заморожен»; gate закрыт безусловно (деградировавшая задача уже `done`, BR-7 ⇒ отдельный сигнал, независимый от `stage`) до **ручного** снятия — новый эндпоинт `POST /serial-gate/unfreeze?repo=<repo>` (`clear_repo_freeze`, идемпотентно, + Telegram-подтверждение; альтернатива — `UPDATE repo_freeze SET cleared_at=datetime('now') …`). freeze в Python-слое (`is_repo_frozen`) → **fail-CLOSED** (безопасность прода, AC-9). Независимый тумблер `serial_gate_freeze_enabled`.
-  - **Конфигурация (`src/config.py`):** `serial_gate_enabled` (kill-switch, `ORCH_SERIAL_GATE_ENABLED`, дефолт true → claim+start_pipeline 1:1 как сейчас при false), `serial_gate_repos` (CSV, `ORCH_SERIAL_GATE_REPOS`; **пусто ⇒ все репо**, в отличие от self-hosting-only ORCH-35/43/58; оператор может сузить), `serial_gate_freeze_enabled` (`ORCH_SERIAL_GATE_FREEZE_ENABLED`). Наблюдаемость — аддитивный блок `serial_gate` в `GET /queue` (per-repo `active_task`/`waiting`/`frozen`+reason+at); существующие ключи не меняются. **NFR-6:** freeze — пассивная остановка стартов, прод-контейнер не рестартится/не роняется. Cross-repo параллелизм сохранён (FR-3/AC-4); при выключенном флаге — нулевая регрессия (enduro не затронут, AC-7). ADR `docs/work-items/ORCH-088/06-adr/ADR-001-serial-gate.md`, данные `08-data-requirements.md`, сквозной `adr-0017`. Документация: `docs/architecture/README.md` (раздел serial gate + `/queue` + таблица API + раздел БД), `CLAUDE.md`. Тесты: `tests/test_serial_gate.py` (TC-01/02/03/08/15/16/17/19/21), `tests/test_serial_gate_e2e.py` (TC-04/05/06), `tests/test_serial_gate_freeze.py` (TC-07/09/10/11/12/18/22), `tests/test_serial_gate_branch.py` (TC-13/14), `tests/test_queue_endpoint.py` (TC-20).
- **CI-фикс: per-run путь логов из хардкода `/app/data/runs` в `settings.runs_dir`** (ORCH-087, `fix`): тест `tests/test_launcher.py::TestEffortStamp::test_spawn_stamps_resolved_effort` падал в CI (`PermissionError: [Errno 13] … '/app'`) — зелёный локально-в-контейнере (где `/app` есть), красный на CI-хосте (act_runner hostexecutor, юзер без доступа к `/app`). **Корень:** `launcher._spawn` хардкодил `output_path="/app/data/runs/{run_id}.log"` + `os.makedirs('/app/data/runs')`, а тест дёргал `_spawn`, не замокав путь → makedirs на недоступном `/app` бросал. **Фикс (корень, не только тест):** базовый каталог per-run логов вынесен в `Settings.runs_dir` (env `ORCH_RUNS_DIR`, дефолт `/app/data/runs` — прод-layout 1:1); новый хелпер `launcher._run_log_path(run_id)` = `<settings.runs_dir>/{run_id}.log` стал единым источником пути (использован в `_spawn` + три прежних inline-строки логов/алертов). Тест `monkeypatch`-ит `settings.runs_dir` на `tmp_path` → окружение-независим (подтверждено прогоном с принудительно недоступным `/app`). `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — без изменений. Документация: `README.md` (таблица env), `CHANGELOG.md`.
- **Live-трекер: зачистка осиротевших карточек + эффорт в строке стадии + честное итоговое время** (ORCH-087, `fix`): в чат периодически попадали «замёрзшие» сироты — старая карточка с заголовком `📍 To Analyse` висела на задаче, реально дошедшей до `deploy` (скриншот ORCH-082). **Корень (G0/ADR-001):** указатель `tasks.tracker_message_id` — скаляр (знает лишь ПОСЛЕДНИЙ `message_id`), поэтому при рассинхроне bump-режима (доминанты: гонка двух `update_task_tracker` и `delete`-fail+`send`-ok) ссылка на прежнюю карточку терялась навсегда → сирота не удалялась и больше не обновлялась (рендер исправен — застывал именно потерянный mid). **Фикс (bump сохранён дефолтом — фича «карточка внизу» ORCH-042/067):**
-  - **G1 — полный учёт mid:** аддитивная таблица-леджер `tracker_messages(task_id, message_id, created_at, deleted_at)` (`src/db.py`) + хелперы `add_tracker_message`/`get_open_tracker_messages`/`mark_tracker_message_deleted`. На каждом bump зачищаются ВСЕ незакрытые mid (`deleted_at IS NULL`), а не только скаляр: успех/«already gone» (`_DELETE_GONE_MARKERS`) → `deleted_at`; transient-`delete` → остаётся для ретрая; новый mid в леджер + `set_tracker_message_id` ТОЛЬКО при успешном `send` (R-3/BR-6). Остаточная гонка самозалечивается за один переход (лок не вводится). Скаляр `tracker_message_id` сохранён (BC). Known-limitation: Telegram 48ч (сироты старше неудаляемы).
-  - **G3 — deploy-цикл:** в `_LIVE_BRANCH_LABELS` добавлен ключ `confirm_deploy` («⏳ Confirm Deploy — подтвердите прод-деплой», без base-alias) → полнота `Awaiting Deploy → Deploying → Confirm Deploy → Monitoring → Done`.
-  - **BR-EFF — эффорт в строке стадии:** новая колонка `agent_runs.effort TEXT` (`_ensure_column`, идемпотентно); стамп фактического `resolve_agent_effort` в `launcher._spawn` в момент запуска (CLI эффорт в result-JSON не возвращает); рендер `· {model} · {effort}` (developer=`xhigh`, tester/deployer=`medium`, прочие=`high`); пустой effort → суффикс опускается.
-  - **BR-G5 — честное итоговое время:** done-строка `⏱️ Агенты {Σ agent_runs} · твоё {review~cap} · общее с ожиданием {wall}` — три независимых подписанных метрики (раньше `Всего {wall}` читалось как сумма, которой не является — queue-паузы не логируются). «Твоё» ограничено порогом `tracker_brd_review_cap_s` (env `ORCH_TRACKER_BRD_REVIEW_CAP_S`, дефолт 2ч; маркер `~` при отсечке аномального застоя из-за рассинхрона In Review→Backlog); `wall` подписан «с ожиданием».
-  - **Инварианты:** `STAGE_TRANSITIONS`/`QG_CHECKS`/стадии — без изменений; миграции аддитивны/идемпотентны (общая прод-БД, enduro не трогается); never-raise, `disable_notification`, `plane_issue_link` (ORCH-067), `disable_web_page_preview` (ORCH-080) сохранены; `src/reconciler.py` не эродирован (ORCH-086 на месте). Тесты: `tests/test_notifications_orphans.py` (TC-01..05 + never-raise), `tests/test_tracker_effort_time.py` (TC-06/11..15 + confirm_deploy), `tests/test_launcher.py::TestEffortStamp` (TC-09/10). ADR `docs/work-items/ORCH-087/06-adr/ADR-001-tracker-orphan-cleanup.md`.
- **Терминал-скип и `state_uuid`-dedup на пути F-1 реконсилятора** (ORCH-086, `fix`): в Telegram периодически (особенно после рестарта орка) прилетало ложное `🔧 reconciler: ET-002 done разблокирована (потерян webhook)` — задача давно завершена, ничего не разблокируется, это шум. **Корень:** ORCH-068 закрыл livelock только на F-2 (plane-side); путь F-1 (gate-side) остался непокрытым по двум причинам — (A) вызов `_note_unblock(work_item_id, stage)` шёл без `state_uuid`, поэтому in-memory dedup пропускался; (B) единственным «терминал-фильтром» F-1 была выборка `get_active_tasks_for_reconcile` (`WHERE stage != 'done'`), не знающая о статусе issue в Plane — задача с дрейфом «БД орка не-`done`, а Plane уже `Done`» проходила фильтр, no-op условные гейты (enduro) давали зелёный → `advance` → ложное уведомление. **Фикс (ADR-001, локализован в `src/reconciler.py`):** (D1) новый `_resolve_issue_status(task)` делает **один** сетевой резолв Plane-статуса задачи за тик `(states, groups, state_uuid)` после дешёвых локальных гардов (busy/young/escalated в Plane не ходят), never-raise → `({}, {}, None)` при сбое; (D2) безусловный терминал-скип ДО Guard 2 — терминальная задача (группа Plane `completed`/`cancelled`, fallback на логические ключи `done`/`cancelled`, ЛИБО стадия в БД орка ∈ `{done, cancelled}`, т.к. `cancelled` не отсекается выборкой) → ранний `return` + `skipped_terminal_total++`, не подчинён `reconcile_skip_blocked_enabled` (тот гейтит только Guard 2); (D3) `_is_blocked_or_needs_input` переиспользует резолв D1 (3-й/4-й опц. аргументы; при `_UNSET` — самостоятельный резолв для прямых/легаси-вызовов, поведение 1:1); (D4) вызов `_note_unblock` на F-1 теперь передаёт `state_uuid` → dedup работает и на F-1 (повтор того же `issue_id`+`state_uuid` → `deduped_total++`, без второго Telegram). Терминальность — тот же `_is_terminal_state`, что и в F-2 (первичный дискриминатор — группа Plane, устойчив к UUID-алиасингу/мультипроектности; покрывает enduro и orchestrator). Анти-регресс (AC-4): легитимный unblock реально застрявшей не-терминальной задачи по-прежнему `advance` + ровно один Telegram (`unblocked_total++`). `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, сигнатуры `advance_stage`/`advance_if_gate_passed`/`_note_unblock`, форма `status()`/`GET /queue`, новые config-флаги — без изменений; never-raise сохранён. ADR `docs/work-items/ORCH-086/06-adr/ADR-001-reconciler-f1-terminal-skip-and-dedup.md`. Тесты: `tests/test_reconciler.py` (TC-86-01..09/11: терминал по группе completed/cancelled, fallback по логическому ключу, DB-side cancelled, проброс/dedup `state_uuid`, анти-регресс, never-raise, независимость от Guard-2-флага), `tests/test_reconciler_plane.py` (TC-86-10: форма `status()` неизменна). Документация: `docs/architecture/README.md` (раздел Reconciler F-1).
- **Подавление Telegram link-preview в карточке трекера / уведомлениях** (ORCH-080): под каждой карточкой трекера (`bump` и `edit`) и под notify/alert-сообщениями Telegram разворачивал баннер «Plane — Modern project management» для кликабельной ссылки `ORCH-NNN` на issue. В дефолтном `bump`-режиме (ORCH-067) карточка пересоздаётся на каждом переходе → баннер дублировался и засорял ленту (жалоба Owner, 08.06). **Корень:** JSON-payload обоих низкоуровневых примитивов `notifications.send_telegram` (`POST /sendMessage`) и `notifications.edit_telegram` (`POST /editMessageText`) не содержал ключ `disable_web_page_preview`. **Фикс (ADR-001, минимальная аддитивная правка на уровне примитива):** добавлен `"disable_web_page_preview": True` в payload обоих методов — гасит баннер у ВСЕХ потребителей (`update_task_tracker` в обоих режимах, `notify_approve_requested`, `notify_error`, alert'ы стадий из `launcher`/`stage_engine`) без изменения их кода. Безусловно, без kill-switch (превью трекера не нужно никому, риск нулевой). `parse_mode: "HTML"` сохранён в обоих payload → ссылка `ORCH-NNN` остаётся кликабельной; `disable_notification` (карточка тихая), bump/edit-логика, инвариант «одна карточка на задачу», контракты возврата (`send_telegram → message_id|None`, `edit_telegram → EDIT_*`) и never-raise — не затронуты. `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД — без изменений. ADR `docs/work-items/ORCH-080/06-adr/ADR-001-disable-telegram-link-preview.md`. Тесты: `tests/test_link_preview_disabled.py` (TC-01..06: флаг в обоих payload, регрессия `parse_mode`/полей, контракты возврата, never-raise). Документация: `CLAUDE.md` + `docs/architecture/README.md` (компонент Notifications).
 - **Гарантированный идемпотентный код-PR перед merge-verify (фикс ложного HOLD «no open PR»)** (ORCH-082/ORCH-81): закрыт отсутствующий инвариант «к моменту merge-verify у ветки есть открытый код-PR». **Корень (ORCH-074, 08.06):** PR создавался единственной `launcher._ensure_pr` ТОЛЬКО на developer-пути и ТОЛЬКО при свежем worktree-коммите (`exit==0 → git status непуст → commit → push → agent=="developer"`); после ручных восстановлений `main` у ветки ORCH-074 не оказалось открытого код-PR → детерминированный `merge_gate.merge_pr` вернул `("False", "no open PR")` → защита ORCH-073 верно удержала задачу (HOLD, не ложный `done`), но лечила следствие. **Фикс (ADR-001, аддитивно, внутри того же под-гейта merge-verify, машина стадий не тронута):** (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 `base!=main` НЕ код-PR) → `("existed", N)`; иначе `POST …/pulls` → `("created", N)`; гонка `409/422` «PR exists» → повторный GET → `existed` (без дублей); любая иная HTTP/parse/сетевая ошибка → `("failed", reason)`. (2) Врезка в `stage_engine._handle_merge_verify` ПОСЛЕ резолва `validated_revision` и ПЕРЕД `merge_pr`: при `merge_verify_autocreate_pr_enabled` → `ensure_open_pr`; `created|existed` → штатно к `merge_pr` → `verify_merged_to_main`; `failed` → честный HOLD через новый helper `_hold_pr_create_failed` (текст «PR создать не удалось», `result.note="pr-create-failed-hold"` — текстуально отличим от not-merged HOLD; задача остаётся на `deploy`, НЕ `done`, БЕЗ отката на development). (3) `launcher._ensure_pr` делегирован в `merge_gate.ensure_open_pr` (единый код создания PR, общий фильтр `head==branch & base==main`); триггер «создавать только на developer-пути со свежим коммитом» НЕ ужесточён — менялась только реализация под капотом. **Защита ORCH-073 неприкосновенна и приоритетна:** подтверждение merge остаётся ТОЛЬКО `verify_merged_to_main` (SHA-в-main) + `check_main_regression`; `ensure_open_pr` устраняет лишь ЛОЖНЫЙ HOLD «no open PR», реально невлитый код → HOLD как прежде. Kill-switch `ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED` (дефолт `true`); область — `merge_verify_applies(repo)` (self-hosting / `merge_verify_repos`), non-self → no-op; `false` → поведение ORCH-074 1:1. Идемпотентность из Gitea (наличие открытого PR), без миграции БД (restart-safe); `main` не push/force-push. Инварианты НЕ менялись: `STAGE_TRANSITIONS`, реестр `QG_CHECKS` (под-гейт — врезка в `advance_stage`, не новый QG), схема БД, `check_deploy_status`/`_parse_deploy_status`, exit-коды хука, merge-gate (ORCH-043), image-freshness (ORCH-058), внешние HTTP-эндпоинты. ADR `docs/work-items/ORCH-082/06-adr/ADR-001-ensure-open-pr-before-merge-verify.md` (+ сквозной `adr-0016`). Документация: `docs/architecture/README.md` (блок ORCH-082 в merge-verify). Тесты: `tests/test_orch082_ensure_pr.py` (TC-01..05: идемпотентный актор, фильтр base==main, гонка 409/422, never-raise), `tests/test_orch082_merge_verify_autocreate.py` (TC-06..12: врезка, регресс ORCH-073, kill-switch, условность, наблюдаемость).
 - **Устойчивость резолва `--effort` к пустому env + developer → `xhigh`** (ORCH-081/ORCH-52h): фикс конфигурационного бага, из-за которого в проде `resolve_agent_effort()` возвращал `''` для всех 6 агентов и `--effort` не передавался в Claude CLI (каждый агент бежал на встроенном CLI-дефолте вместо заявленного уровня — прямой удар по предсказуемости качества всего конвейера, включая enduro-trails из общего инстанса). **Корень:** pydantic Settings трактует ПРИСУТСТВУЮЩУЮ env-переменную, даже пустую (`ORCH_AGENT_EFFORT_*=` без значения), как явное `''` и перебивает class-default; в проде пусты И per-agent, И `agent_effort_default`, поэтому у цепочки резолва (`_resolve_agent_attr`: project-override → per-agent env → default → `''`) не остаётся непустого «пола» для отката. **Фикс (вариант c, ADR-001):** в `resolve_agent_effort` (`src/agents/launcher.py`) добавлен уровень 4 — непустой **per-role floor** ниже `default`: новый чистый helper `_agent_effort_floor(agent)` возвращает декларированный class-default поля `agent_effort_<agent>` через `type(settings).model_fields[...].default` (значение, которое пустой env перебить НЕ может). Floor срабатывает ТОЛЬКО когда уровни 1–3 пусты и применяется ДО валидации, поэтому: (а) при пустом прод-`.env` каждая роль получает СВОЙ канонический уровень (developer=`xhigh`, tester/deployer=`medium`, analyst/architect/reviewer=`high`), а не общий default; (б) явная опечатка (`turbo`/`ultra`) непуста → floor НЕ применяется → значение штатно дропается валидацией `VALID_EFFORTS` в `''` (never-break ORCH-41 не регрессирует, floor не маскирует мусор); (в) непустой явный env/project-override/`default` по-прежнему ПОБЕЖДАЕТ floor (приоритет резолва сохранён 1:1). Unknown-agent (имя вне 6 ролей) деградирует на class-default `agent_effort_default` (`high`) — безопасный непустой пол. **`config.py`:** `agent_effort_developer` `high → xhigh` (канон Opus 4.8: coding/agentic роль) — единственное изменение значений; floor подтягивает его автоматически (единый источник правды, ноль риска дрейфа floor-карты). Инварианты НЕ менялись: приоритеты/сигнатуры резолва ORCH-41, `_resolve_agent_attr` (общий с model-резолвом, не тронут), `resolve_agent_model` (ORCH-074), путь проброса `--effort` в `_spawn`, `VALID_EFFORTS`, API, схема БД (без миграций). ADR `docs/work-items/ORCH-081/06-adr/ADR-001-effort-resolution-floor.md`. Документация: `docs/architecture/README.md` (таблица «модель/эффорт по ролям»: developer `xhigh` + ремарка про floor), `.env.example` (`ORCH_AGENT_EFFORT_DEVELOPER=xhigh` + комментарий split/floor). Тесты: `tests/test_resolve_agent_effort.py` (TC-01..08: канон-дефолты, floor при пустом env per-role, floor-не-маскирует-typo, приоритет, `xhigh∈VALID_EFFORTS`, сборка флага `--effort xhigh`/`--effort medium`).
 - **Убран мёртвый frontmatter `model:` + валидация имени модели (never-break)** (ORCH-074): закрыты два дефекта данных/валидации каркаса выбора модели агентов (ORCH-41), без изменения механизма резолва, API или схемы БД. **G1 — мёртвый frontmatter:** из YAML-frontmatter всех 6 промптов `.openclaw/agents/*.md` удалена строка `model:` (`claude-sonnet-4-6` у analyst/developer/tester/deployer, `claude-opus-4-7` у architect/reviewer). launcher НЕ читал frontmatter `model:` — это была лживая/мёртвая декларация, противоречащая реально используемой модели (config) и принципу «документация = golden source»; мина: если бы кто-то «починил» launcher читать frontmatter, все агенты молча уехали бы на устаревшие модели. config (`agent_model_*`/`agent_model_default`) остаётся единственным источником правды; frontmatter описательный. **G2 — валидация имени модели:** добавлен чистый helper `is_valid_model(name)` + `_MODEL_NAME_RE` (`^claude-[a-z0-9.-]+$`) рядом с `VALID_EFFORTS` в `src/agents/launcher.py`. Резолвенное имя модели валидируется ПЕРЕД попаданием в `--model`: невалидное (опечатка, `gpt-4`, пустое, неверный префикс) → `logger.warning` + откат на следующий валидный уровень каскада ORCH-41 (project-override → env → default), в пределе → `""` (без флага `--model`, CLI-дефолт). Никогда не возвращается мусор и не бросается исключение (never-break, поведенческая аналогия `resolve_agent_effort`/`VALID_EFFORTS`). Выбран **формат-чек, а не allowlist `VALID_MODELS`**: allowlist воссоздаёт ровно ту мину, что убивается в G1 (статичный список врёт при устаревании — молча дропнул бы корректную будущую `claude-opus-4-9`); формат-чек forward-compatible (новые `claude-*` проходят без правки кода), финальный авторитет о существовании модели — сам Claude CLI. Тот же предикат применён к inline-чтению `--fallback-model` (`agent_fallback_model` читается напрямую в `_spawn`, мимо `resolve_agent_model` — TRZ §4), поэтому опечатка в `ORCH_AGENT_FALLBACK_MODEL` тоже дропается с warning; для текущего пустого значения регрессии нет. **G4 (fallback) НЕ включён** (`agent_fallback_model=""`, AC-5 N/A) — ради детерминизма (все агенты на `claude-opus-4-8`); **G3 (routing) НЕ включён** (AC-4 N/A) — осознанное решение стейкхолдера (Слава 08.06). Реализация `resolve_agent_model` рефакторнута на генератор кандидатов `_agent_model_candidates` (тот же приоритет ORCH-41) + валидация-со-скипом. Инварианты НЕ менялись: приоритеты/сигнатуры резолва ORCH-41, структура CLI-команды `_spawn`, `VALID_EFFORTS`-гард эффорта, `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, схема БД (без миграций); enduro per-project override валидные имена проходят без изменения поведения. ADR `docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md`. Документация: `docs/architecture/README.md` (таблица «модель/эффорт по ролям» + валидация), `CLAUDE.md`, `.env.example` (блок `ORCH_AGENT_MODEL_*`/`ORCH_AGENT_EFFORT_*`/`ORCH_AGENT_FALLBACK_MODEL`). Тесты: `tests/test_agent_frontmatter_no_model.py` (G1: TC-01/02), `tests/test_resolve_agent_model.py` (G2 never-break: TC-03..09, TC-11 + is_valid_model).
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -6,8 +6,8 @@
 ## Стек
 - Backend: FastAPI + uvicorn (Python 3.12)
 - БД: SQLite (`src/db.py`)
- Агенты: Claude CLI (`ORCH_CLAUDE_BIN`), по одному промпту на роль в `.openclaw/agents/`. **ORCH-74:** модель/эффорт агента берутся ТОЛЬКО из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41) — frontmatter `model:` удалён как мёртвый, frontmatter описательный; имя модели валидируется форматом `^claude-…$` перед `--model` (never-break). **ORCH-077 (52d, замыкает эпик 52):** тело всех 6 промптов переписано в едином **каноне Anthropic** (5 обязательных XML-секций в нормативном порядке `<context>`→`<task>`→`<deliverables>`→`<constraints>`→`<output_format>`, запреты в формате «❌ X → ✅ Y», `<thinking>` у решающих ролей), и каждый промпт **добровольно** эмитит 6-польную frontmatter-схему 52c (`work_item`/`stage`/`author_agent`/`status`/`created_at`/`model_used`) **аддитивно** — рядом с machine-verdict ключом, НЕ меняя его имя/регистр/значения (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:` — байт-в-байт). Это **docs/prompts-only** изменение: `src/**`/`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты; `frontmatter_validation_strict` остаётся `False` (enforcement НЕ включён). Промпт `cat`-ается из worktree в момент запуска → новые промпты вступают в силу на следующем worktree от `main` без прод-рестарта. Анти-регресс — структурные тесты `tests/test_agent_prompts_canon.py` + зелёный `test_agent_frontmatter_no_model.py`. **Норматив на будущее:** новые/изменённые агент-промпты следуют этому канону. Детали — `docs/architecture/adr/adr-0021-prompt-canon-anthropic.md`. **ORCH-092 (эпилог эпика 52, docs/prompts-only):** аудит 6 промптов поверх канона — копируемые frontmatter-примеры расхардкожены (`created_at: <YYYY-MM-DD>`/`model_used: <resolve ORCH-41>` + врезка «подставь `date +%F`/модель из конфига, не копируй буквально»; литерал `claude-opus-4-8` — только справка в таблице полей); добавлена секция `<escalation>` developer/reviewer/tester (после `</success_criteria>`, порядок 5 секций цел); developer лишён ручного `git rebase origin/main` (свежесть базы — инвариант движка serial-gate ORCH-088 + `auto_rebase_onto_main` под merge-lease; ручной rebase конфликтовал с запретом force-push — ADR-001 D1); tester обогащён worktree-путём + smoke `serial_gate` + покрытием каждого TC; из reviewer удалена мёртвая строка «тот же экземпляр Developer». **Языковое исключение (нормативно, ADR-001 D2):** `deployer.md` сознательно остаётся на **английском** (5 ru + 1 en) как самый safety-critical промпт — НЕ «чинить» язык вслепую; критичные self-hosting-запреты подняты в видную рамку. Verdict-ключи и канон 52d — байт-в-байт; анти-регресс — `tests/test_agent_prompts_canon.py` (ORCH-092 TC-01…TC-08). Детали — `docs/work-items/ORCH-092/06-adr/ADR-001-developer-rebase-and-deployer-language.md`.
- Очередь задач: собственная (SQLite `jobs`, `src/queue_worker.py`, ORCH-1). **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота `max_concurrency`; декларации/детект циклов — leaf `src/task_deps.py` (kill-switch `ORCH_TASK_DEPS_ENABLED`). Сериализация мержа одного репо — безусловный pre-merge rebase под merge-lease (`ORCH_PREMERGE_REBASE_ALWAYS`). **ORCH-088 (serial gate, Этап 1):** новая задача репо не входит в `analysis` (analyst-job не выбирается, ветка не режется), пока в репо есть **более ранняя** незавершённая задача (`t2.id < jobs.task_id`, FIFO) ИЛИ репо заморожен (`repo_freeze`). Срез ветки **отложен** со `start_pipeline` на момент claim analyst-job (`launcher._materialize_deferred_branch`) — база = свежий `origin/main` с кодом предшественника (анти-stale-base). Post-deploy `DEGRADED` → durable per-repo freeze (`repo_freeze`, `cleared_at IS NULL` = активен) + Telegram; снятие — вручную `POST /serial-gate/unfreeze?repo=…`. Leaf `src/serial_gate.py` (claim — fail-OPEN, freeze — fail-CLOSED); флаги `ORCH_SERIAL_GATE_ENABLED` (kill-switch), `ORCH_SERIAL_GATE_REPOS` (CSV; пусто = все репо), `ORCH_SERIAL_GATE_FREEZE_ENABLED`. Блок `serial_gate` в `GET /queue`. `STAGE_TRANSITIONS`/`QG_CHECKS` не тронуты. **ORCH-093 (merge-актор устойчив к икоте Gitea):** детерминированный merge-актор под-гейта `deploy → done` (`src/merge_gate.py`) ретраит **транзиентные** ошибки Gitea вместо ложного HOLD (инцидент ORCH-063: `POST …/merge` → `405 "try again later"` сразу после пуша). `merge_pr` оборачивает **только** мутирующий `POST …/merge` в ограниченный retry-loop с экспоненциальным backoff (`min(base*2^(i-1), max)`, потолок суммарного сна `(N-1)*max ≤ 10 с`); классификатор `_classify_merge_response`: транзиент (ретрай) — `405`/`408`/`5xx`/таймаут/сетевая + `409`/`422` при `mergeable==True` (доп. `GET /pulls/{index}`; `mergeable==None` → дефолт-транзиент, fail-OPEN-в-ретрай), терминал (быстрый честный `False`, защита ORCH-071/073 как прежде) — `403`/`404`/реальный конфликт (`mergeable==False`). Kill-switch `merge_retry_enabled=false` → ровно один POST (байт-в-байт прежнее one-shot); флаги `ORCH_MERGE_RETRY_*` (`max_attempts=3`, `backoff_base_s=2`, `backoff_max_s=5`). Гард **already-in-main** в `ensure_open_pr` (leaf `_branch_fully_in_main`, `git merge-base --is-ancestor HEAD origin/main`): ветка целиком в `main` → исход `"already-in-main"` без создания мусорного пустого PR; `_handle_merge_verify` пропускает `merge_pr` и отдаёт авторитетному SHA-в-main довести до `done` (НЕ HOLD); git-ошибка → fail-OPEN на create-путь. Без отдельного флага (накрыт `merge_verify_autocreate_pr_enabled`). INV-4 (мерж только через Gitea PR-merge API, никогда push/force-push в `main`), never-raise, `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — сохранены. Детали — `docs/work-items/ORCH-093/06-adr/ADR-001-merge-transient-retry-and-already-in-main-guard.md`, сквозной `docs/architecture/adr/adr-0027-merge-actor-transient-retry-and-already-in-main.md`.
+- Агенты: Claude CLI (`ORCH_CLAUDE_BIN`), по одному промпту на роль в `.openclaw/agents/`. **ORCH-74:** модель/эффорт агента берутся ТОЛЬКО из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41) — frontmatter `model:` удалён как мёртвый, frontmatter описательный; имя модели валидируется форматом `^claude-…$` перед `--model` (never-break).
+- Очередь задач: собственная (SQLite `jobs`, `src/queue_worker.py`, ORCH-1). **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота `max_concurrency`; декларации/детект циклов — leaf `src/task_deps.py` (kill-switch `ORCH_TASK_DEPS_ENABLED`). Сериализация мержа одного репо — безусловный pre-merge rebase под merge-lease (`ORCH_PREMERGE_REBASE_ALWAYS`).
 - Контейнеризация: Docker + Compose
 - CI/CD: Gitea Actions (`.gitea/workflows/`)
 - Деплой: docker compose на mva154
@@ -28,7 +28,7 @@
 - `src/qg/checks.py` — Quality Gate проверки
 - `src/webhooks/` — приём вебхуков Plane/Gitea
 - `tests/` — pytest
- `docs/` — документация, ADR, work-items, operations; **витрина системы — `docs/overview/`** (единая точка входа «бизнес + тех», ORCH-011)
+- `docs/` — документация, ADR, work-items, operations
 - `scripts/` — утилиты (staging_check.py, orchestrator-deploy-hook.sh)

 ## Конвейер (кратко; детали — docs/architecture/README.md)
@@ -41,371 +41,42 @@ created → analysis → architecture → development → review → testing →
 ## Статусная модель Plane (ORCH-066) — индикация ≠ управление
 Статусы Plane — это **слой B (индикация)**, отдельный от **слоя A (машина стадий)** `src/stages.py::STAGE_TRANSITIONS`. Plane показывает наблюдателю осмысленную картину (`Backlog → Todo → Analysis → Architecture → Development → Code-Review → Testing → Awaiting Deploy → Deploying → Monitoring after Deploy → Done` + человеческие гейты `In Review/Approved`, `Confirm Deploy`), но НИКОГДА не управляет конвейером. Маппинг и сеттеры — `src/plane_sync.py` (6 новых ключей: `to_analyse/analysis/code_review/awaiting_deploy/deploying/monitoring`), с project-relative alias-fallback: на частично сконфигурированном проекте новый ключ деградирует на базовый UUID ТОГО ЖЕ проекта (нулевая регрессия для enduro-trails). Детали — `docs/architecture/README.md`.

-**Terminal-window-aware гард deploy-статусов (ORCH-094).** Задача с БД `stage=done` и 0 активных job'ов стабильно держит Plane=`Done`: три deploy-фазовых сеттера (`set_issue_awaiting_deploy`/`set_issue_deploying`/`set_issue_monitoring`) были терминал-слепы и флаппили `Awaiting ⟷ Monitoring` (верифицировано на ORCH-061, task 47), т.к. любой стейл/двойной/неизвестный вызов под бот-токеном перезаписывал терминал промежуточным статусом. Новый leaf `src/deploy_status_guard.py` (чистая, never-raise, config-gated; по образцу `serial_gate`/`labels`/`cancel`) — `decide(work_item_id, target, reason) -> ALLOW | CONVERGE_DONE | SUPPRESS` на **входе** трёх сеттеров `plane_sync` (низкий чокпоинт ловит любой путь, включая неизвестный актор). Инвариант: deploy-статус легитимен ⇔ задача **нетерминальна** ИЛИ (`done` И активно пост-деплой-окно `post_deploy.window_active` = ARMED & не DONE); иначе для `done` — идемпотентное `CONVERGE_DONE` (сеттер зовёт `set_issue_done`), для `cancelled` — `SUPPRESS`. Чтобы легитимный первый `Monitoring` (БД уже `done` к моменту стр. 404) прошёл, арм-блок `post_deploy.arm_monitor` **перенесён выше** terminal-sync-блока в `advance_stage` (ADR-001 D3) → `window_active==True` до выставления `Monitoring`. Монитор-тик при БД `cancelled` мид-окно → закрыть окно без статус-PATCH (zombie-tick guard, FR-3). Наблюдаемость: BC-kwarg `reason` у трёх сеттеров + одна структурная лог-запись на вердикт (`work_item`/`caller`/`target`/`db_stage`/`window_active`/`verdict`; converge/suppress → WARNING). Read-only аксессор `db.get_task_by_work_item_id`. Флаги `deploy_status_guard_enabled` (kill-switch; `False` → 1:1 прежнее) / `deploy_status_guard_repos` (CSV; **пусто → self-hosting only**, enduro не затронут). `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты. Детали — `docs/work-items/ORCH-094/06-adr/ADR-001-terminal-window-aware-deploy-status-guard.md`, сквозной `docs/architecture/adr/adr-0028-terminal-window-aware-deploy-status-guard.md`.
-
-## Нотификации / Telegram live-tracker (ORCH-042/066/067/087)
+## Нотификации / Telegram live-tracker (ORCH-042/066/067)
 Каждая задача = **одна карточка** в Telegram (`src/notifications.py`). Поведение карточки:
 - **Дефолт `tracker_mode` — `bump`** (ORCH-067; `edit` доступен через `ORCH_TRACKER_MODE=edit`).
  `bump` на каждом обновлении удаляет старую карточку и шлёт свежую вниз чата (тихо), `edit`
  редактирует на месте. Инвариант «одна карточка на задачу» — в обоих режимах.
- **Зачистка сирот (ORCH-087):** bump ведёт авторитетный леджер ВСЕХ созданных карточек
-  (таблица `tracker_messages`, `deleted_at IS NULL` = жива) и на каждом обновлении удаляет
-  ВСЕ незакрытые mid, а не только скаляр `tracker_message_id` (он сохранён как указатель на
-  текущую карточку, BC). Это устраняет класс «замёрзшая сирота» (старая карточка с заголовком
-  ранней стадии, потерявшая ссылку при гонке/`delete`-fail+`send`-ok). Новый mid пишется в
-  леджер ТОЛЬКО при успешном `send` (BR-6); transient-`delete` остаётся незакрытым для ретрая;
-  «already gone»/>48ч (`_DELETE_GONE_MARKERS`) → закрывается. Остаточная гонка самозалечивается
-  за один bump. Known-limitation: Telegram 48ч (сироты старше неудаляемы).
- **Эффорт в строке стадии (ORCH-087):** колонка `agent_runs.effort` стампится фактическим
-  `resolve_agent_effort` в `launcher._spawn` (CLI его в result-JSON не возвращает); строка
-  рендерится `· {model} · {effort}` (developer=`xhigh`, tester/deployer=`medium`, прочие=`high`);
-  пустой/исторический effort → суффикс опускается.
- **Честное итоговое время (ORCH-087):** done-строка = три независимых подписанных метрики
-  `⏱️ Агенты {Σ agent_runs} · твоё {review~cap} · общее с ожиданием {wall}` (раньше `Всего {wall}`
-  читалось как сумма, которой не является). «Твоё» ограничено `tracker_brd_review_cap_s`
-  (`ORCH_TRACKER_BRD_REVIEW_CAP_S`, дефолт 2ч; маркер `~` при отсечке аномального застоя).
 - **Статус-строка карточки** (`📍 <status_label>`) показывает текущий Plane-статус по модели
  ORCH-066 (`plane_status_label`). Оффлайн-ядро (`stage → статус`, In Review из brd-clock)
  работает всегда без сети; best-effort live-overlay (kill-switch `tracker_live_status`,
  TTL-кэш, короткий таймаут) лишь дорисовывает ветки, неотличимые offline (Needs Input /
-  Blocked / Rejected / Cancelled / **Confirm Deploy** / Deploying / Monitoring) и **никогда не
-  блокирует конвейер**.
+  Blocked / Rejected / Cancelled / Deploying / Monitoring) и **никогда не блокирует конвейер**.
 - **Кликабельный номер задачи** (`plane_issue_link`) — `ORCH-NNN` в карточке И во всех
  уведомлениях (`notify_*`, alert'ы стадий) рендерится как `<a href=…>` на issue в Plane;
  fail-safe → просто `html.escape(номер)`, если ссылку построить нельзя. Никогда не падает.
- **Без link-preview (ORCH-080):** оба примитива (`send_telegram`/`edit_telegram`) шлют
-  payload с `disable_web_page_preview: True` — баннер Plane («Modern project management»)
-  под кликабельной ссылкой `ORCH-NNN` больше не разворачивается ни в карточке (`bump`/`edit`),
-  ни в notify/alert-сообщениях. `parse_mode: HTML` сохранён → ссылка остаётся кликабельной.
 - Транспорт (`send_telegram`/`edit_telegram`/`delete_telegram`), `disable_notification`
  (карточка тихая, пингуют только alert-хелперы), схема БД — не трогаются.

-## Авто-режим по лейблам: autoApprove + autoDeploy (ORCH-089)
-Конвейер имеет два **человеческих** гейта, тормозящих пакетный автономный прогон
-(эпик ORCH-088): гейт BRD (`analysis`: ручной `Approved`) и гейт прод-деплоя
-(`deploy` Phase A: ручной `Confirm Deploy`, ORCH-059). ORCH-089 снимает **только эти
-два человеческих решения** — выборочно (лейбл Plane на задаче), декларативно,
-обратимо, **не трогая ни одной технической проверки**. Инвариант: авто-режим снимает
-лишь ожидание человеческого сигнала; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схема БД
-— **не трогаются**. Аддитивно: leaf `src/labels.py` (never-raise) + две точечные врезки.
- **`autoApprove`** → врезка в `stage_engine._handle_analysis_approved_flow` (ветка
-  `files_ok`): `set_issue_approved` (индикация) + лог/Telegram/Plane-коммент +
-  `advance_stage(..., finished_agent=None)` — **тот же путь, что человеческий Approved**
-  (`approved-via-status` → `analysis → architecture` + `mark_brd_review_ended`).
- **`autoDeploy`** → врезка в `stage_engine._handle_self_deploy_phase_a` после advance
-  на `deploy` + `clear_state`: лог/Telegram/Plane-коммент + `_handle_self_deploy_phase_b`
-  (маркер `INITIATED`, статус `Deploying`, finalizer). Пропускаются лишь
-  индикативно-человеческие шаги. **BR-5 структурно:** Phase A достигается только после
-  зелёных под-гейтов ребра `deploy-staging → deploy` (security → merge-gate →
-  image-freshness → staging) → autoDeploy физически не деплоит сломанное.
- **Чтение лейблов** — `plane_sync.fetch_issue_labels` (`None` при ошибке ≠ `[]`) +
-  `get_project_labels` (`{normalized_name→uuid}`, TTL-кэш); сопоставление по
-  нормализованному имени (`strip().casefold()`), неоднозначность → «нет лейбла».
-  Источник истины — Plane API, не payload вебхука. Новый сеттер `set_issue_approved`.
- **Флаги** (`config.py`): `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` → при выключенном флаге нулевой сетевой оверхед.
- **Fail-safe (never auto):** любая ошибка/недоступность Plane/неоднозначность →
-  «нет авто» → ручной гейт (never-raise). Прозрачность: лог + Telegram + Plane-коммент +
-  live-карточка; блок `auto_labels` в `GET /queue`. **Инфра-предусловие:** создать лейблы
-  `autoApprove`/`autoDeploy` в Plane-проекте ORCH (их отсутствие = ручной режим, fail-safe).
-  Детали — `docs/work-items/ORCH-089/06-adr/ADR-001-auto-label-gates.md`,
-  `docs/architecture/adr/adr-0018-auto-label-gates.md`.
-
-## Отмена задачи: статус STOP (ORCH-090)
-Выделенный Plane-статус **STOP** — операторская кнопка «отменить + сбросить» задачу. Вводит
-**новое системное терминальное состояние `cancelled`** (стадия `tasks.stage='cancelled'` + job-исход
-`jobs.status='cancelled'`), равноправное `done`. Логический ключ `stop` — **fail-closed** (нет в
-`_DEFAULT_STATES`, по образцу `confirm_deploy`/ORCH-059): доска без статуса STOP → ветка не
-активируется. Маршрут `handle_issue_updated → handle_stop → stage_engine.cancel_task`:
- **Полный сброс** (вне критичного окна): graceful SIGTERM активного агента (`launcher.stop_process`,
-  переиспользует каскад `_watchdog`), все job'ы → терминальный `cancelled` (не реквью'ятся:
-  `claim_next_job` берёт только `queued`, reaper/worker сверяют терминал задачи — TR-2), удаление
-  worktree + **рабочей** Gitea-ветки (`gitea.delete_remote_branch`, **никогда** `main`, без
-  force-push), durable `stage='cancelled'` + **тумбстон** натуральных ключей (`plane_id`/
-  `work_item_id`/`plane_issue_id` → суффикс `#cancelled-<id>`; ADR-001 D4 уточнён: тумбстонится и
-  `plane_issue_id`, т.к. `get_task_by_plane_id`/`create_task_atomic` матчат по нему — иначе re-create
-  коллизирует; исходный UUID парсится из суффикса для аудита). Docs-артефакты (`01..17`) сохраняются.
- **STOP в критичном окне merge/deploy** (ADR-001 D7): `cancel.in_critical_window` → **отложенная**
-  отмена: `tasks.cancel_requested_at`, снимаются только `queued` job'ы (running-актор деплоя/мержа не
-  трогается), алерт; детерминированный finalizer (`run_deploy_finalizer`) доводит необратимый шаг до
-  честного исхода и применяет отмену (`force=True`). «Критичное окно» = реально начатый необратимый
-  шаг: INITIATED-sentinel self-deploy (ORCH-036; детач-деплой + поздний `merge_pr` в
-  `_handle_merge_verify` идут под тем же маркером) **либо** держание merge-lease (ORCH-043) **И**
-  активно бегущий актор (running-job). **Уточнение P1 (ORCH-090 review):** держание merge-lease в
-  Phase A на стадии `deploy` в ожидании ручного `Confirm Deploy` БЕЗ бегущего актора **полностью
-  обратимо** (ничего не смержено/задеплоено) → НЕ критично → немедленный полный сброс (сам отпускает
-  lease). Иначе отмена откладывалась бы к finalizer'у, который оператор (нажавший STOP именно чтобы НЕ
-  подтверждать деплой) не запускает — задача застревала бы с удержанным lease, клиня serial-gate репо.
-  STOP **никогда** не трогает `main`/force-push/прод-контейнер/detached-процесс (NFR-3).
- **Кросс-каттинг (adr-0026):** предикат «задача терминальна» расширен `{done}` → `{done, cancelled}`
-  в `serial_gate`/`task_deps`/`stages.py`-сток (иначе отменённая задача заклинит очередь репо);
-  reconciler-терминал-скип уже знал `cancelled` (ORCH-086). `STAGE_TRANSITIONS` exit-гейты рёбер /
-  `QG_CHECKS` / `check_*` — **не тронуты** (`cancelled` — сток, не ребро).
- **Дыра релонча закрыта (D6):** relaunch агента в `handle_status_start` ограничен стадией `analysis`
-  (единственный владелец Needs Input, ORCH-066); ручной перевод существующей задачи в иной промежуточный
-  статус больше не релончит середину пайплайна. Запуск пайплайна — только «To Analyse» → `start_pipeline`.
- Флаги `stop_status_enabled` (kill-switch; `False` → всё инертно, нулевая регрессия) / `stop_status_repos`
-  (CSV; пусто → все репо). Leaf `src/cancel.py` (never-raise). Read-only блок `stop` в `GET /queue`.
-  Аддитивные колонки `tasks.cancelled_at`/`cancel_requested_at` (`_ensure_column`). **Инфра-предусловие:**
-  создать статус **STOP** с группой `cancelled` на доске ORCH (его отсутствие = fail-safe no-op). Детали —
-  `docs/work-items/ORCH-090/06-adr/ADR-001-stop-cancel-task.md`,
-  `docs/architecture/adr/adr-0026-stop-cancel-task.md`.
-
-## Багфикс-трек: дешёвый маршрут для багов (ORCH-019)
-Задача с меткой Plane `Bug` идёт **укороченным маршрутом** — пропускается стадия `architecture`
-(отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`); тяжёлая
-аналитика заменяется облегчённым пакетом (короткий bug-report + обязательный план регресс-теста,
-но всё равно все 4 файла analysis — гейт `check_analysis_complete` не меняется). **Корневой
-инвариант (NFR-1):** срезается ТОЛЬКО аналитика/архитектура — **все Quality Gate'ы и под-гейты
-исполняются без изменений** (`STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи —
-байт-в-байт прежние); маршрутизация багфикса — свойство планировщика, **не** гейт. Аддитивно, под
-kill-switch, never-raise, fail-safe → полный цикл.
- **Классификация (D1):** leaf `src/bug_fast_track.py` (never-raise, образец `labels`/`serial_gate`).
-  `bug_fast_track_applies(repo)` (локально, без сети) ПЕРВЫМ → выключенный флаг = нулевой сетевой
-  оверхед; `is_bug_task` делегирует в `labels.has_label` (ORCH-089-аппарат, источник истины — Plane
-  API, не payload). Чтение метки — только в `start_pipeline`, **никогда** в горячем `claim_next_job`
-  (NFR-4).
- **Хранение типа (D2):** аддитивная идемпотентная колонка `tasks.track TEXT DEFAULT 'full'`
-  (`_ensure_column`, паттерн `tasks.cancelled_at`); значения `'full'` (дефолт, ВСЕ существующие и
-  не-баг задачи) | `'bug'`. Хелперы `db.set_task_track`/`get_task_track` (отсутствие/NULL → `'full'`,
-  fail-safe). Читается в `advance_stage` из БД, не из сети.
- **Routing-override (D3):** врезка в `advance_stage` на ребре выхода из `analysis`: при `track='bug'`
-  (чистый предикат `bug_fast_track.skips_architecture`) `next_stage` → `development`, `next_agent` →
-  `developer` (минуя `architect`). `STAGE_TRANSITIONS`/`get_next_stage`/`get_agent_for_stage` — чистые,
-  1:1. Стамп `mark_brd_review_ended` расширен на `analysis → development` (честная метрика ORCH-087).
- **Эскалация (D5):** `POST /bug-fast-track/escalate?work_item=<id>` сбрасывает `track` `'bug'→'full'`
-  → следующий переход уходит в `architecture` (полный цикл). Плюс self-escalate мини-аналитика
-  («баг сложный → полный пакет + `escalate: full-cycle`»).
- **Флаги** (`config.py`): `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`),
-  `bug_fast_track_label` (дефолт `Bug`), `bug_fast_track_repos` (CSV; **пусто → self-hosting only**).
-  `False`/неприменимый репо → старт и маршрут байт-в-байт прежние (нулевая регрессия для enduro и
-  orchestrator). Наблюдаемость — read-only блок `bug_fast_track` в `GET /queue` (флаг/метка/область +
-  счётчик багфикс-задач + метрика пропущенных стадий `architecture`) + отметка `🐞` в Telegram-карточке
-  (never-raise). Композиция: багфикс-задача — обычная задача репо для serial-gate (ORCH-088, не
-  обходит его); `autoApprove`/`autoDeploy` (ORCH-089), coverage-gate (ORCH-027, союзник BR-4),
-  merge-gate (ORCH-043) — штатно. **Инфра-предусловие:** создать метку **`Bug`** в Plane-проекте ORCH
-  (её отсутствие = fail-safe полный цикл). Детали —
-  `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md`,
-  `docs/architecture/adr/adr-0032-bug-fast-track.md`.
-
-## Гейт покрытия тестами (ORCH-027)
-Существующие тестовые гейты (`check_ci_green`, `check_tests_passed`, merge-gate re-test) судят
-только по **факту** прохождения, не по **полноте** — ни один не замечает «300 строк кода, 0
-тестов», и при пакетном автономном прогоне (ORCH-088) покрытие монотонно деградирует. Введён
-**детерминированный (без LLM) под-гейт ребра `deploy-staging → deploy`** по образцу security-гейта
-(ORCH-022): leaf `src/coverage_gate.py` (never-raise) + тонкая обёртка `check_coverage_gate` в
-`QG_CHECKS` + врезка `_handle_coverage_gate` в `advance_stage`. **Инвариант:** `STAGE_TRANSITIONS` /
-семантика существующих `check_*` / machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/
-`staging_status:`/`security_status:`) — байт-в-байт прежние; новая БД-таблица аддитивна (NFR-5).
- **Точка/порядок:** **ПОСЛЕ merge-gate** (покрытие меряется на догнанном `auto_rebase_onto_main`
-  HEAD — ровно том коде, что landed в `main`) и **ДО image-freshness** (фейл до дорогого
-  docker-rebuild). Порядок под-гейтов: **security → merge → coverage → image-freshness.** FAIL →
-  штатный откат на `development` (+ инкремент developer-retry, cap `MAX_DEVELOPER_RETRIES`) **и
-  освобождение merge-lease** (merge-gate держал его на своём PASS — зеркало image-freshness rollback).
- **Измерение:** `python -m pytest tests/ --cov=src --cov-report=json` в изолированном per-branch
-  worktree (`ensure_worktree`); метрика — `totals.percent_covered` (line coverage `src/`). Измеритель
-  за `measure_coverage(repo, branch) -> float | None` (стек-расширяемость BR-6). Тайм-аут
-  `coverage_run_timeout_s`. Новая pip-зависимость `pytest-cov`.
- **Решение — чистая функция** `compute_coverage_verdict(measured, baseline, floor, policy, epsilon)
-  -> (ok, reason)`: `absolute` → `measured ≥ floor−ε`; `baseline` → `measured ≥ baseline−ε`; `both`
-  (дефолт) → оба; `baseline is None` (bootstrap) → baseline-условие не применяется. `epsilon` —
-  допуск на шум измерения (анти-флап у границы).
- **Базовая линия — аддитивная БД-таблица** `coverage_baseline(repo PK, coverage, source_sha,
-  updated_at)` (`CREATE TABLE IF NOT EXISTS`; хелперы `db.get_coverage_baseline`/
-  `ratchet_coverage_baseline`/`set_coverage_baseline`). Наращивание **только вверх** в choke-point
-  подтверждённого merge `_handle_merge_verify` (ребро `deploy → done`): `ratchet_baseline_on_merge`
-  читает измеренное из `18-coverage-report.md` (single source of truth), атомарный compare-and-set
-  `UPDATE … WHERE coverage <= measured` под держимым merge-lease (ORCH-043) → базовая линия не падает
-  даже при гонке; bootstrap засевается первым применимым merge.
- **Условность (как ORCH-22/43/58):** `coverage_gate_enabled` (kill-switch; `False` → 1:1 как до
-  ORCH-027) + `coverage_gate_repos` (CSV; **пусто → self-hosting only** `is_self_hosting_repo` →
-  enduro не затронут, no-op `(True, "N/A")`); `applies(repo)` (локально) ПЕРВЫМ — дорогой прогон
-  только при `applies==True`. Ошибка инструмента/непарсимая метрика → **fail-open + WARNING** по
-  умолчанию (`coverage_tool_fail_closed=False`, анти-петля); флаг → fail-closed.
- **Артефакт `18-coverage-report.md`** (frontmatter `coverage_status: PASS|FAIL` +
-  `measured_coverage`/`baseline`/`floor`/`policy`/`epsilon`/`delta`), вердикт читается ТОЛЬКО из
-  frontmatter через `src/frontmatter.py` (single source of truth, как `security_status:`).
-  Наблюдаемость — read-only блок `coverage` в `GET /queue`; при FAIL — `send_telegram` с кликабельным
-  номером, измеренным/порогом/дельтой; опциональный ручной override `POST /coverage/baseline`.
-  Флаги `ORCH_COVERAGE_*` (`MIN_PERCENT`/`POLICY`/`EPSILON`/`TOOL_FAIL_CLOSED`/`RUN_TIMEOUT_S`).
-  Self-hosting-безопасно: гейт только мерит/читает/пишет/решает — не деплоит/не рестартит прод/не
-  пушит `main`. **Инфра-предусловие:** `pytest-cov` в прод/staging-образе. Детали —
-  `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md`,
-  `docs/architecture/adr/adr-0029-coverage-gate.md`.
-
-## Машинный журнал уроков (ORCH-098)
-Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
-**машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих
-ретроспективщика (E2), приоритизатора RICE (E3) и Стрим. Чистый **observer-leaf** `src/lessons.py`
-(never-raise, kill-switch, паттерн `serial_gate`/`coverage_gate`/`metrics`): `record()`/`get()`/
-`update()`/`snapshot()`. **Инвариант:** журнал — наблюдатель, **не** Quality Gate; запись урока
-никогда не влияет на продвижение по стадиям — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
-machine-verdict/схемы существующих таблиц байт-в-байт не тронуты.
- **Таблица (D1):** аддитивная идемпотентная `lessons` (`CREATE TABLE IF NOT EXISTS` в `init_db()`,
-  три индекса) — контекст (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализ (`root_cause`/
-  `suggestion`), статус (`status`/`related_task`), **атрибуция сразу и нуллабельно** (`attribution`/
-  `target_repo`/`target_domain`, требование Славы 10.06 / NFR-6, заполняется позже через update;
-  `_ensure_column` форвард-safe на старой таблице) + `source`/`detail`. Без `enum`-констрейнтов —
-  значения суть forward-compatible слаги. Хелперы `db.record_lesson`/`get_lessons`/`update_lesson`/
-  `lessons_snapshot`/`lessons_recent_dup_exists`.
- **НЕ скоупится по репо (D2):** в отличие от гейт-leaf'ов (`serial_gate`/`coverage_gate` имеют
-  `*_repos`, т.к. *действуют* на репо), журнал observer-only → единственный регулятор — глобальный
-  kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`); **`lessons_repos` НЕ
-  вводится**. Recorder пишет уроки про **любой** репо (включая enduro-trails — урок ценен для петли);
-  репо-разрез — на **выборке** (`get(repo=…)`). enduro не затронут (общая БД, аддитивная таблица).
- **Автозапись 4 типов (D3):** тонкие best-effort врезки (`source="auto"`, never-raise, дедуп) —
-  `gate_failure` (`stage_engine._handle_qg_failure_rollbacks`, откат на `development`), `merge_hold`
-  (`stage_engine._handle_merge_verify` HOLD-ветка), `transient_retry` (`launcher._finalize_transient`
-  на **исчерпании** бюджета ретраев, а не на каждом backoff), `deploy_degraded` (post-deploy
-  `DEGRADED → set_repo_freeze`, урок слоя-3 «деплой OK / прод сломан» ET-8 — `attribution="unknown"`,
-  классифицируется позже).
- **Дедуп (D4):** для `source="auto"` — один indexed-SELECT по `idx_lessons_wi_type`: дубль с тем же
-  `(work_item_id, lesson_type, stage)` в окне `lessons_dedup_window_s` (env, дефолт 3600с) → no-op.
-  `source="manual"` дедуп НЕ проходит (оператор/Стрим всегда пишут).
- **Эндпоинты (D5):** `GET /lessons` (read-only, фильтры `type`/`status`/`repo`/`work_item`/`limit`),
-  `POST /lessons` (ручная запись, `source="manual"`), `POST /lessons/{id}` (доклассификация/update);
-  read-only ключ `lessons` в `GET /queue`. Выключенный флаг → `{"enabled": false}`.
- **never-raise (NFR-1):** все публичные функции и врезки изолированы (`try/except` → warning +
-  безопасный дефолт) — сбой журнала не роняет конвейер. Self-hosting-безопасно: только читает/пишет
-  свою таблицу, не деплоит/не рестартит прод/не трогает `main`/без процессов/сети. Детали —
-  `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`,
-  `docs/architecture/adr/adr-0034-lessons-journal.md`.
-
-## Turnkey-онбординг проектов (ORCH-009)
-Операторская способность развернуть **новый** проект одним проходом — **вне рантайма и вне
-конвейера** (`src/**` байт-в-байт, kill-switch не нужен: активация — только явный запуск CLI
-человеком). Три артефакта: **kit** `onboarding/repo-skeleton/` (параметризуемый каркас нового репо:
-6 промптов канона 52d/92 — 5 ru + deployer en, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`,
-скелет `docs/` с обязательным `operations/INFRA.md`; плейсхолдеры `{{NAME}}`, словарь —
-`onboarding/placeholders.json`; **канон не форкается**: `docs/_templates/`+`docs/_standards/`
-копируются live из чекаута в момент материализации); **CLI** `scripts/onboard_project.py`
-(`plan` — дефолт, GET-only / `apply` — идемпотентный ensure без delete / `verify`): Plane-проект +
-22 статуса с точными именами (read-only импорт `plane_sync._PLANE_NAME_TO_KEY`; группы фиксированы
-ADR: `STOP`→`cancelled`, терминальные группы только Done/Cancelled/STOP) + лейблы
-`autoApprove`/`autoDeploy`/`Bug` → Gitea-репо + per-repo webhook (переиспользует глобальный
-`ORCH_GITEA_WEBHOOK_SECRET`) → материализация kit + initial push **только** в свежесозданный пустой
-репо → merged-вывод `ORCH_PROJECTS_JSON` (round-trip через фактический `_parse_projects_json`);
-скрипт никогда не рестартит прод / не правит `.env` / ничего не удаляет; недоступное в Plane CE
-API → `manual-step` (fail-safe); **runbook** `docs/operations/ONBOARDING.md` (ручные шаги: env +
-управляемый рестарт; smoke — на staging 8501). Анти-дрейф — структурные тесты
-`tests/test_onboarding_{kit,script,invariants}.py`. Детали —
-`docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`, сквозной
-`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
-
-## Тираж платформы: фундамент 10-common (ORCH-101)
-Платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10,
-оба типа A Lite / B Bundled, stateless). Принцип: **дефолт каждого параметра = боевому значению**
-(пустой `.env` ⇒ поведение байт-в-байт; kill-switch-природа, отдельный флаг не вводится).
-`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты.
- **Расхардкод:** ключи `agent_home_dir`/`agent_git_name`/`git_email_domain` (HOME + git-идентичность
-  акторов: агенты — единый `launcher.agent_git_env()`; системные имена `deploy-finalizer`/
-  `post-deploy-monitor` — платформенные литералы под тем же доменом), `staging_port`; ссылки
-  Plane-комментариев — из `gitea_public_url`/`gitea_owner`. `docker-compose.yml` — интерполяция
-  `${VAR:-default}` (карта `ORCH_HOST_*`/`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID`; группа ORCH-040
-  uid/gid/HOME/маунты — одни env насквозь, «МИНА 1» сохранена); `Dockerfile` — `ARG APP_*`
-  (CMD exec-form 8500 не тронут); deploy-hook — `"${REPO:-…}"` + явная передача `REPO=` обоими
-  инвокерами. **Платформенные константы (НЕ конфиг):** `SELF_HOSTING_REPO="orchestrator"` (узел
-  «empty CSV → self-hosting only» всех `*_repos`-leaf'ов), имена сервисов/профиля, контейнерный
-  layout. **Инвариант ORCH-058 усилен:** guard fail-closed `staging_port == прод-порт` → отказ
-  freshness-пути ДО любого ssh/build, без тихого fallback.
- **Секреты нового хоста:** stdlib `scripts/gen_secrets.py` (`secrets.token_hex(32)`; печать по
-  умолчанию; `--write` отказывает при существующем `.env`, перезапись только `--force`); норматив —
-  боевые секреты не копируются. `.env.example` — канон 100% ключей старта.
- **Smoke тиража:** runbook `docs/operations/REPLICATION.md` (карта env, чек-лист секретов,
-  пошаговый smoke с PASS/FAIL до артефактов `01–04`/`done`, границы 10-common vs Lite vs Bundled).
-  Анти-регресс — `tests/test_no_host_hardcodes.py` (запрещённые литералы в исполняемом коде
-  `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов; config-модули — канон
-  дефолтов, вне скана; allowlist пуст). Детали —
-  `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной
-  `docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`.
-
-## Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
-Закрыт **Type A** эпика ORCH-10 (поверх фундамента 10-common ORCH-101): заказчик разворачивает
-у себя ТОЛЬКО `orchestrator`+`orchestrator-watchdog` и донастраивает окружение
-(Plane/Gitea/Telegram/LLM — его инсталляции) по одной сквозной инструкции. **Docs+tests**
-(паттерн ORCH-077/092): `src/**`/compose/Dockerfile/`scripts/**` не тронуты; конвейер байт-в-байт.
- **Golden source** — `docs/deployment/LITE_SETUP.md` (новый раздел `docs/deployment/` — витрина
-  тиража, читатель — внешний оператор; vs `docs/operations/` — эксплуатация НАШЕГО прода): 13
-  нормативных разделов в порядке маршрута оператора, каждый шаг = fenced-команда + явная
-  «Проверка:»/PASS/FAIL, хост-специфика только плейсхолдерами; канон не форкается — статусы/env/
-  вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS (явно в доке —
-  только fail-closed имена `Confirm Deploy`/`STOP` и обязательные ключи нового хоста).
- **Канон watchdog-конфига** — новый `.env.watchdog.example` (key-set = блок `WATCHDOG_*`
-  `.env.example`, держится key-sync тестом): sidecar читает ТОЛЬКО `.env.watchdog`, ключ
-  `WATCHDOG_*` в `.env` для него инертен (ловушка файла-носителя закрыта); C-1 ORCH-100 — свой
-  бот, токен орка не переиспользовать; `.env.watchdog` в `.gitignore`.
- **Нормативы:** Gitea — branch protection на `main` НЕ включать (ADR D10 ORCH-009 / INV-4),
-  pre-receive не вводится, ОДИН глобальный webhook-секрет; compose НЕ форкается (дефолтный
-  `up -d` = ровно орк+watchdog, staging строго за `profiles: [staging]` — вилка только под
-  self-hosting развитие платформы); stateless — данные/задачи/секреты боевого хоста НЕ
-  переносятся, проверка чистоты через `GET /queue`.
- **Анти-дрейф** — `tests/test_lite_setup_doc.py` (структурный, без сети/LLM/subprocess):
-  13 разделов в порядке, кирпичи, env-ключи ⊂ `.env.example`, compose-подмножество
-  (анти-появление `plane*`/`gitea*`), fenced-скан `FORBIDDEN` (импорт из
-  `test_no_host_hardcodes.py`) + секрет-эвристика, «22 статуса» сверкой импорта
-  `plane_sync._PLANE_NAME_TO_KEY`, перекрёстность REPLICATION→LITE_SETUP. **Норматив
-  сопровождения (NFR-5):** меняешь шаги тиража → обнови LITE_SETUP.md в том же PR. Детали —
-  `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной
-  `docs/architecture/adr/adr-0037-lite-replication-canon.md`.
-
-## Bundled-тираж: весь стек одним комплектом (ORCH-103)
-Закрыт **Type B** эпика ORCH-10 (поверх 10-common ORCH-101 и канона Lite ORCH-102): заказчик
-**без собственной инфраструктуры** получает весь стек одним комплектом — новый top-level каталог
-**`deploy/bundled/`** (самодостаточный compose: орк + watchdog + Gitea + зеркало upstream Plane CE
-≈14 контейнеров; project name `orchestrator-bundle` = узнаваемый префикс томов/контейнеров;
-`container_name` не пиннится; staging-контура нет вовсе — самразвитие платформы у заказчика =
-маршрут Lite) + **`scripts/bootstrap_bundle.py`** (python stdlib-only, режимы `plan` (дефолт) /
-`apply`/`verify`, step-движок check→ensure, exit 0/2/1), доводящий стек одним прогоном: preflight
-(fail-fast до мутаций) → секреты (webhook — строго `gen_secrets.py`; bundle-креды — stdlib
-`secrets`, без перетирания без `--force-secrets`) → up+готовность → init Gitea (полностью
-автоматом, `gitea admin …`; branch protection НЕ включается — D10 ORCH-009/INV-4) → init Plane
-(честные manual-step c API-верификацией; молчаливый пропуск запрещён) → онбординг sandbox-проекта
-**строго** `onboard_project.py apply+verify` (22 статуса — `plane_sync._PLANE_NAME_TO_KEY`, нулевой
-дрейф канона) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых
-`.env`/`.env.watchdog` (bootstrap — единственный писатель live-конфигов) → health/итог.
-Сеть — одна bridge, машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/*`),
-наружу — только человеческие порты (`BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`);
-мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Все сторонние образы пиннованы
-неподвижными тегами; teardown — только документированная процедура BUNDLED_SETUP §13 (delete-операций
-в скрипте НЕТ вообще). Рантайм байт-в-байт: `src/**`, корневой compose, `Dockerfile`,
-`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты; kill-switch не нужен (активация — только
-явный запуск оператором, паттерн ORCH-009/102). Golden source — `docs/deployment/BUNDLED_SETUP.md`
-(14 разделов канона LITE_SETUP; общие шаги — ссылками на LITE_SETUP/ONBOARDING/REPLICATION).
-Анти-дрейф — `tests/test_bundle_compose.py` (состав/пины/key-set-sync/заморозка корневого compose),
-`tests/test_bundled_setup_doc.py` (разделы/FORBIDDEN-импорт/секрет-эвристика/env-ключи/кросс-рефы),
-`tests/test_bootstrap_script.py` (кирпичи/stdlib-only ast-сканом/нет delete-операций/unit чистых
-функций). **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md
-в том же PR. Детали — `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
-сквозной `docs/architecture/adr/adr-0038-bundled-replication-canon.md`.
-
 ## Конвенции
 - Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
 - Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`
 - ADR per work-item: `docs/work-items/<plane-id>/06-adr/ADR-NNN-slug.md`
 - Global ADR (сквозные решения): `docs/architecture/adr/adr-NNNN-slug.md`
 - Work items: `docs/work-items/<plane-id>/`
- Машинные вердикты Quality Gate — строго YAML-frontmatter (`verdict:`, `deploy_status:`, `staging_status:`, `security_status:`), никогда проза. **ORCH-52c (ORCH-076):** парсинг frontmatter сведён к единому контракту `src/frontmatter.py` (reader `read_frontmatter_value` — BC; единый парс-примитив `parse_frontmatter`; writer `render/write_frontmatter`; валидатор схемы `validate_schema`/`REQUIRED_FIELDS` — warning-only по умолчанию, hard-fail только под kill-switch `frontmatter_validation_strict`, дефолт `False`). Пять вердикт-парсеров (`check_reviewer_verdict`, `_parse_tests_verdict`, `_parse_deploy_status`, `_parse_staging_status`, `parse_security_status`) читают через ОДНУ точку парсинга; семантика вердиктов и `STAGE_TRANSITIONS`/состав `QG_CHECKS` — 1:1. Формальная спека «стадия → обязательный выход» + обязательная frontmatter-схема — `docs/_standards/HANDOFF_PROTOCOL.md`
+- Машинные вердикты Quality Gate — строго YAML-frontmatter (`verdict:`, `deploy_status:`, `staging_status:`, `security_status:`), никогда проза

 ## Артефакты задачи (`docs/work-items/<plane-id>/`)
-`00-business-request.md`, `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`, `06-adr/ADR-NNN-slug.md`, `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`, `12-review.md`, `13-test-report.md`, `14-deploy-log.md`, `15-staging-log.md`, `16-post-deploy-log.md` (post-deploy наблюдение, ORCH-021), `17-security-report.md` (security-гейт: `security_status:`/secrets/deps, ORCH-022), `18-coverage-report.md` (coverage-гейт: `coverage_status:`/measured/baseline, ORCH-027).
-
-**Стандарт документов (ORCH-075, ORCH-52b):** структура каждого дока, карта «стадия→агент→документ→гейт→machine-key» и конвенция ADR-naming зафиксированы в `docs/_standards/PIPELINE_DOCS.md` (golden source); копируемые скелеты — в `docs/_templates/`. Перед написанием номерного дока бери скелет из `docs/_templates/` и не меняй имя machine-key frontmatter (регистр чувствителен — иначе гейт упадёт ложно).
+`00-business-request.md`, `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`, `06-adr/ADR-NNN-slug.md`, `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`, `12-review.md`, `13-test-report.md`, `14-deploy-log.md`, `15-staging-log.md`, `16-post-deploy-log.md` (post-deploy наблюдение, ORCH-021), `17-security-report.md` (security-гейт: `security_status:`/secrets/deps, ORCH-022).

 ## Правила для агентов
 1. Перед любым действием прочесть этот файл и `docs/architecture/README.md`.
-2. **Документация = golden source наравне с кодом.** Изменил функционал → обнови доку В ТОМ ЖЕ PR. Архитектурное решение → заведи ADR (формат — `docs/_standards/PIPELINE_DOCS.md` §4). Структура номерных доков и шаблоны — `docs/_standards/PIPELINE_DOCS.md` + `docs/_templates/`. Обнови `CHANGELOG.md`. **Витрина системы `docs/overview/` (ORCH-011):** изменил функциональность платформы → обнови витрину в том же PR (какой файл какому классу изменений — таблица в индексе витрины); машинно-проверяемые факты витрины держит `tests/test_system_docs.py`.
+2. **Документация = golden source наравне с кодом.** Изменил функционал → обнови доку В ТОМ ЖЕ PR. Архитектурное решение → заведи ADR. Обнови `CHANGELOG.md`.
 3. Никогда не править артефакты других этапов.
 4. Никогда не комментировать ТЗ задним числом — если ТЗ не годится, возвращай в Анализ.
 5. Никогда не закрывать задачу самостоятельно — это делает CI / финальная стадия.
-6. **Reviewer проверяет: обновлена ли документация. Нет → REQUEST_CHANGES.** Это включает **обзорные доки** (ORCH-079, 52f — финал эпика 52): если PR закрывает пункт `README.md` «Известные ограничения», но README не обновлён → finding ≥P1 (витрина проекта не должна выдавать решённое за открытое). Та же ось покрывает витрину системы (ORCH-011): PR меняет функциональность, описанную в `docs/overview/`, а витрина не обновлена → finding ≥P1.
+6. **Reviewer проверяет: обновлена ли документация. Нет → REQUEST_CHANGES.**
 7. Не использовать `--no-verify` без явного одобрения Owner.
 8. Секреты — только в `.env`/`.env.staging` на хосте, в гит НЕ коммитятся (канон — `.env.example`).
-9. **Трассировка маркеров (ORCH-078, ORCH-52e):** правишь строку/блок с маркером `ORCH-NNN` →
-   ПЕРЕД изменением прочитай его `docs/work-items/ORCH-NNN/06-adr/` и не сломай зафиксированный
-   инвариант; блок с 3+ маркерами → опирайся на сводный сквозной ADR. Стандарт маркеров (формат,
-   размещение, fallback-доступ, анти-археология, каноничное правило чтения) — `docs/_standards/TRACEABILITY.md`.

 ## ⚠️ Self-hosting — оркестратор правит САМ СЕБЯ
 Задачи проекта ORCH меняют инструмент, который СЕЙЧАС работает в продакшене и обслуживает ДРУГИЕ проекты (enduro-trails) из ОДНОГО инстанса с ОБЩЕЙ БД и общей очередью.
--- a/16
+++ b/16
@@ -35,16 +35,7 @@ RUN set -eux; \
 # "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}
+RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bash slin
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 COPY src/ ./src/
@@ -57,9 +48,4 @@ COPY src/ ./src/
 # 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"]
--- a/README.md
+++ b/README.md
@@ -1,9 +1,6 @@
 # Multi-Agent Orchestrator

 > См. [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 агентов на каждой стадии.

@@ -32,7 +29,7 @@ created → analysis → architecture → development → review → testing →
 | 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 |
+| development | developer | check_tests_local (орк сам гоняет `make test`) | 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 |
@@ -48,7 +45,6 @@ created → analysis → architecture → development → review → testing →
 | 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` |

 ## Структура проекта

@@ -73,8 +69,6 @@ data/
 └── 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-слой
@@ -127,7 +121,6 @@ uvicorn src.main:app --reload --port 8500
 | `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` |
@@ -144,22 +137,6 @@ uvicorn src.main:app --reload --port 8500
 | `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_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)

@@ -176,60 +153,7 @@ Webhook-хэндлеры больше не спавнят claude-агентов
 - **Ретраи.** Упавший 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 (нет метки → задача идёт полным циклом).
+Статусы job: `queued → running → done | failed`. Наблюдаемость — через `GET /queue`.

 **Resilience-слой:** дешёвый preflight (CLI/net, кэш, без токенов) гейтит claim;
 429/overload детектится по логу (transient vs permanent), transient ретраится с
@@ -298,7 +222,7 @@ stdout/stderr агента перенаправляются СРАЗУ в `/app/
 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»)
+- `status` → (legacy) Gitea CI; С-1: больше не authoritative, `failure` логируется на debug и не блокирует/не алертит (QG развития = локальный `check_tests_local`)

 ## Тесты

@@ -308,19 +232,9 @@ pytest tests/ -v

 ## Известные ограничения

-Реально открытые ограничения (сверено с кодом, 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).
+1. **Single-task / shared `/repos` checkout** — одновременно безопасно обрабатывается одна задача: все агенты и `check_tests_local` делают `git checkout` в одном `/repos/<repo>` → гонки при параллельных задачах. Исправление — git worktree per task (S-4, отдельно).
+2. **Plane sync** — маппинг issue ID может быть некорректным (P3, в работе)
+3. **In-process daemon-потоки** — агенты живут в потоках uvicorn; при рестарте ловит orphan-recovery. Целевое — очередь задач (F-2b)
+4. **Gitea CI не настроен** — тесты гоняет сам оркестратор локально
+3. **Tester timeout** — e2e тесты с Playwright могут занимать >25 мин на тяжёлых фичах
+4. **No retry on API errors** — httpx вызовы к Gitea/Plane без retry logic
--- a/deploy/bundled/.env.example
+++ b/deploy/bundled/.env.example
@@ -1,61 +0,0 @@
-# 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=
--- a/deploy/bundled/docker-compose.yml
+++ b/deploy/bundled/docker-compose.yml
@@ -1,338 +0,0 @@
-# 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:
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1,98 +1,42 @@
-# 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:
-      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}
+    build: .
    container_name: orchestrator
    restart: unless-stopped
    # 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}"
+    user: "1000: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
-      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /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
+      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
+      - /usr/bin/node:/usr/bin/node:ro
+      - /home/slin/.claude:/home/slin/.claude
+      - /home/slin/.claude.json:/home/slin/.claude.json:ro
+      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
+      - /home/slin/.orchestrator-ssh:/home/slin/.ssh:ro
    env_file: .env
    environment:
      - ORCH_REPOS_DIR=/repos
-      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
+      - 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_USER=slin
      - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      - 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_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}
+      - 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
-    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}"
+      - "999"

  # ORCH-31: staging instance (port 8501, isolated DB).
  # Starts ONLY with: docker compose --profile staging up -d orchestrator-staging
@@ -100,42 +44,35 @@ services:
  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}
+    build: .
    container_name: orchestrator-staging
    restart: unless-stopped
    # ORCH-040: тот же uid хоста, что и у prod (см. комментарий выше / ADR-001).
-    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    user: "1000: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}"]
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8501"]
    volumes:
      - ./data/staging:/app/data
-      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /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
+      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
+      - /usr/bin/node:/usr/bin/node:ro
+      - /home/slin/.claude:/home/slin/.claude
+      - /home/slin/.claude.json:/home/slin/.claude.json:ro
+      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
+      - /home/slin/.orchestrator-ssh:/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}
+      - ORCH_HOST_REPOS_DIR=/home/slin/repos
+      - DEPLOY_SSH_USER=slin
      - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      - 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 —
+      # 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}"
+      - "999"
--- a/docs/PRODUCT_VISION.md
+++ b/docs/PRODUCT_VISION.md
@@ -4,9 +4,6 @@

 **Версия:** 1.0 · **Дата:** 2026-06-04 · **Статус:** концепция развития

-> **Фактическое текущее состояние платформы** (что уже умеет, как устроена) — витрина системы
-> [docs/overview/](overview/README.md) (ORCH-011). Этот документ — vision: «куда идём».
-
 ---

 ## 1. Зачем это (бизнес-взгляд)
--- a/docs/_standards/HANDOFF_PROTOCOL.md
+++ b/docs/_standards/HANDOFF_PROTOCOL.md
@@ -1,118 +0,0 @@
-# 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** (регистр чувствителен — иначе гейт упадёт ложно).
--- a/docs/_standards/PIPELINE_DOCS.md
+++ b/docs/_standards/PIPELINE_DOCS.md
@@ -1,155 +0,0 @@
-# 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`) | — |
-| `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 номера, в текущем каноне не используются.
-
---
-
-## 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`.
--- a/docs/_standards/TRACEABILITY.md
+++ b/docs/_standards/TRACEABILITY.md
@@ -1,147 +0,0 @@
-# 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`.
--- a/docs/_templates/00-business-request.md
+++ b/docs/_templates/00-business-request.md
@@ -1,8 +0,0 @@
-# Business Request: <краткий заголовок задачи>
-
-Work Item ID: ORCH-NNN
-
-## Description
-
-<Что хочет заказчик/Владелец своими словами: проблема, желаемый результат, контекст.
-Допускается `TBD` на входе — analyst уточняет на стадии `analysis` и формализует в 01-brd.md.>
--- a/docs/_templates/01-brd.md
+++ b/docs/_templates/01-brd.md
@@ -1,34 +0,0 @@
-# 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 (заполняет архитектор).>
--- a/docs/_templates/02-trz.md
+++ b/docs/_templates/02-trz.md
@@ -1,30 +0,0 @@
-# 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, область раската, обратимость.>
--- a/docs/_templates/03-acceptance-criteria.md
+++ b/docs/_templates/03-acceptance-criteria.md
@@ -1,31 +0,0 @@
-# 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 |
--- a/docs/_templates/04-test-plan.yaml
+++ b/docs/_templates/04-test-plan.yaml
@@ -1,20 +0,0 @@
-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
--- a/docs/_templates/06-adr-ADR-NNN-slug.md
+++ b/docs/_templates/06-adr-ADR-NNN-slug.md
@@ -1,43 +0,0 @@
-# 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/…`
--- a/docs/_templates/07-infra-requirements.md
+++ b/docs/_templates/07-infra-requirements.md
@@ -1,19 +0,0 @@
-# 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/`, новые тестовые шаги; либо «без изменений».>
--- a/docs/_templates/08-data-requirements.md
+++ b/docs/_templates/08-data-requirements.md
@@ -1,15 +0,0 @@
-# 08 — Требования к данным: ORCH-NNN — <название>
-
-Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
-
-> When-applicable / информационный (гейтом не парсится). Если данные/схема не затрагиваются —
-> оставить явные `N/A`.
-
-## Изменения схемы БД
-<Новые/изменённые таблицы, индексы, миграции (`init_db`); либо `N/A`.>
-
-## Новые/изменённые сущности
-<Поля, колонки, инварианты данных; либо «Нет.».>
-
-## Совместимость данных / миграции
-<Аддитивность, идемпотентность миграций, restart-safe, влияние на общую прод-БД; либо `N/A`.>
--- a/docs/_templates/10-tech-risks.md
+++ b/docs/_templates/10-tech-risks.md
@@ -1,16 +0,0 @@
-# 10 — Технические риски: ORCH-NNN — <название>
-
-Work Item: **ORCH-NNN** · Repo: **<repo>** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | <описание риска> | Низ./Сред./Выс. | Низ./Сред./Выс. | <как снижаем> |
-| TR-2 | <…> | | | |
-
-## Сводный вывод
-<Доминирующий класс рисков; нужна ли эскалация `arch:major-change` / возврат в анализ;
-итоговая оценка остаточного риска для прод-конвейера (self-hosting).>
--- a/docs/_templates/12-review.md
+++ b/docs/_templates/12-review.md
@@ -1,31 +0,0 @@
---
-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.>
--- a/docs/_templates/13-test-report.md
+++ b/docs/_templates/13-test-report.md
@@ -1,33 +0,0 @@
---
-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 — покрыт каким тестом / результат.>
--- a/docs/_templates/14-deploy-log.md
+++ b/docs/_templates/14-deploy-log.md
@@ -1,14 +0,0 @@
---
-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).>
--- a/docs/_templates/15-staging-log.md
+++ b/docs/_templates/15-staging-log.md
@@ -1,20 +0,0 @@
---
-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 | перечень>.
--- a/docs/_templates/16-post-deploy-log.md
+++ b/docs/_templates/16-post-deploy-log.md
@@ -1,21 +0,0 @@
---
-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, тик не откатывает прод).>
--- a/docs/_templates/17-security-report.md
+++ b/docs/_templates/17-security-report.md
@@ -1,26 +0,0 @@
---
-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)
-<Не блокирующие предупреждения зависимостей.>
--- a/docs/_templates/18-coverage-report.md
+++ b/docs/_templates/18-coverage-report.md
@@ -1,29 +0,0 @@
---
-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.>
--- a/docs/architecture/README.md
+++ b/docs/architecture/README.md
--- a/docs/architecture/adr/README.md
+++ b/docs/architecture/adr/README.md
@@ -22,38 +22,13 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | 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`).
+> свободный номер (текущий максимум — `0016`).
 > 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.
--- a/docs/architecture/adr/adr-0017-serial-gate.md
+++ b/docs/architecture/adr/adr-0017-serial-gate.md
@@ -1,59 +0,0 @@
-# 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`).
--- a/docs/architecture/adr/adr-0018-auto-label-gates.md
+++ b/docs/architecture/adr/adr-0018-auto-label-gates.md
@@ -1,59 +0,0 @@
-# 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`.
--- a/docs/architecture/adr/adr-0019-pipeline-docs-standard.md
+++ b/docs/architecture/adr/adr-0019-pipeline-docs-standard.md
@@ -1,49 +0,0 @@
-# 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 (правка промптов).
--- a/docs/architecture/adr/adr-0020-frontmatter-contract.md
+++ b/docs/architecture/adr/adr-0020-frontmatter-contract.md
@@ -1,63 +0,0 @@
-# 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).
--- a/docs/architecture/adr/adr-0021-prompt-canon-anthropic.md
+++ b/docs/architecture/adr/adr-0021-prompt-canon-anthropic.md
@@ -1,84 +0,0 @@
-# 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`.
--- a/docs/architecture/adr/adr-0022-traceability-marker-standard.md
+++ b/docs/architecture/adr/adr-0022-traceability-marker-standard.md
@@ -1,106 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0023-overview-docs-reviewer-axis-and-epic52-close.md
+++ b/docs/architecture/adr/adr-0023-overview-docs-reviewer-axis-and-epic52-close.md
@@ -1,98 +0,0 @@
---
-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>
--- a/docs/architecture/adr/adr-0024-disk-watchdog.md
+++ b/docs/architecture/adr/adr-0024-disk-watchdog.md
@@ -1,59 +0,0 @@
---
-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>
--- a/docs/architecture/adr/adr-0025-build-cache-pruner.md
+++ b/docs/architecture/adr/adr-0025-build-cache-pruner.md
@@ -1,86 +0,0 @@
---
-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>
--- a/docs/architecture/adr/adr-0026-stop-cancel-task.md
+++ b/docs/architecture/adr/adr-0026-stop-cancel-task.md
@@ -1,106 +0,0 @@
---
-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)
--- a/docs/architecture/adr/adr-0027-merge-actor-transient-retry-and-already-in-main.md
+++ b/docs/architecture/adr/adr-0027-merge-actor-transient-retry-and-already-in-main.md
@@ -1,82 +0,0 @@
---
-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`
--- a/docs/architecture/adr/adr-0028-terminal-window-aware-deploy-status-guard.md
+++ b/docs/architecture/adr/adr-0028-terminal-window-aware-deploy-status-guard.md
@@ -1,96 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0029-coverage-gate.md
+++ b/docs/architecture/adr/adr-0029-coverage-gate.md
@@ -1,92 +0,0 @@
---
-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).
--- a/docs/architecture/adr/adr-0030-metrics-endpoint.md
+++ b/docs/architecture/adr/adr-0030-metrics-endpoint.md
@@ -1,88 +0,0 @@
---
-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/`, отдельная задача).
--- a/docs/architecture/adr/adr-0031-legacy-ownership-normalization.md
+++ b/docs/architecture/adr/adr-0031-legacy-ownership-normalization.md
@@ -1,92 +0,0 @@
---
-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 — образец «только читать/уведомлять, не трогать
-хост/прод»).
--- a/docs/architecture/adr/adr-0032-bug-fast-track.md
+++ b/docs/architecture/adr/adr-0032-bug-fast-track.md
@@ -1,95 +0,0 @@
---
-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>
--- a/docs/architecture/adr/adr-0033-sidecar-watchdog.md
+++ b/docs/architecture/adr/adr-0033-sidecar-watchdog.md
@@ -1,85 +0,0 @@
---
-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>
--- a/docs/architecture/adr/adr-0034-lessons-journal.md
+++ b/docs/architecture/adr/adr-0034-lessons-journal.md
@@ -1,92 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0035-turnkey-project-onboarding.md
+++ b/docs/architecture/adr/adr-0035-turnkey-project-onboarding.md
@@ -1,80 +0,0 @@
---
-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).
--- a/docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md
+++ b/docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md
@@ -1,109 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0037-lite-replication-canon.md
+++ b/docs/architecture/adr/adr-0037-lite-replication-canon.md
@@ -1,96 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0038-bundled-replication-canon.md
+++ b/docs/architecture/adr/adr-0038-bundled-replication-canon.md
@@ -1,114 +0,0 @@
---
-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`.
--- a/docs/architecture/adr/adr-0039-system-overview-docs-canon.md
+++ b/docs/architecture/adr/adr-0039-system-overview-docs-canon.md
@@ -1,95 +0,0 @@
---
-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-каноны)
--- a/docs/architecture/internals.md
+++ b/docs/architecture/internals.md
@@ -61,15 +61,9 @@ STAGE_TRANSITIONS = {
    testing:      → deploy-staging (agent: deployer,   QG: check_tests_passed)
    deploy-staging: → deploy      (agent: deployer,   QG: check_staging_status)
    deploy:       → done          (agent: None,       QG: None)
-    cancelled:    → None          (agent: None,       QG: None)   # ORCH-090: терминал-сток отмены
 }
 ```

-**Терминальные стоки (ORCH-090):** `done` и `cancelled` — равноправные терминальные состояния
-(`{"next": None, "agent": None, "qg": None}`). `cancelled` — это **не новое ребро** (exit-гейты
-рёбер не меняются), а терминал STOP-отмены. Системный предикат «задача завершена» —
-`stage ∈ {done, cancelled}` (синхронно в `reconciler`/`serial_gate`/`task_deps`; adr-0026).
-
 ### 3. Quality Gates (`src/qg/checks.py`)

 | Check | Метод проверки |
@@ -106,17 +100,6 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash

 Примечание: переход `review → testing` использует `check_reviewer_verdict` (читается из frontmatter `12-review.md`); `development → review` — `check_tests_local` (оркестратор сам прогоняет тесты, не зависит от Gitea CI).

-**Багфикс-трек: routing-override на ребре выхода из `analysis` (ORCH-019 — design).** Для задачи
-с `tasks.track='bug'` (помечена в `start_pipeline` по метке Plane `Bug` через аппарат ORCH-089)
-`advance_stage` на шаге 3 переопределяет результат `get_next_stage('analysis')`: `next_stage` →
-`development` (вместо `architecture`), а на шаге 4 `next_agent` → `developer` (вместо `architect`)
-→ стадия `architecture` и её exit-гейт `check_architecture_done` для багфикса не исполняются.
-`STAGE_TRANSITIONS`/`get_next_stage`/`get_agent_for_stage` остаются чистыми (1:1) — override живёт
-только в `advance_stage`. Чистый предикат `bug_fast_track.skips_architecture(track)` (leaf
-`src/bug_fast_track.py`, never-raise) под `bug_fast_track_enabled`; `track` читается из БД, не из
-сети (NFR-4). `False`/неприменимый репо → маршрут байт-в-байт прежний. Детали —
-[adr-0032](adr/adr-0032-bug-fast-track.md).
-
 ### 6. Review Bounce

 При REQUEST_CHANGES:
@@ -145,16 +128,12 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash

 **Текст карточки (оба режима, ORCH-042):** метка `Подтверждение BRD` (была «Ревью БРД»); после прохождения approve-gate строка BRD начинается с ✅ (ветка ожидания сохраняет ⏸️/⏳); русские display-labels стадий (`Анализ / Архитектура / Разработка / Код ревью / Тестирование / Внедрение`); финальная строка `📦 Внедрено` (было `deployed`). Меняются только отображаемые строки — ключи стадий и имена агентов (завязаны на `_STAGE_ACTIVE_AGENT`, `last_done`, БД) не трогаются.

-**Строки стадий: отражение откатов + суммирование метрик (ORCH-091).** Цикл рендера строк стадий (`render_task_tracker` → `_stage_line`) исправлен по двум осям. (1) **Откат (Деф.2):** `✅`-строка стадии рисуется только если её позиция в конвейере `≤` текущей позиции задачи; позиция берётся из порядка `STAGE_TRANSITIONS` (read-only хелпер `_pipeline_pos`, never-raise; неизвестная стадия → «далёкое будущее» → ✅ не пере-подавляется) с нормализацией `deploy-staging → deploy` ТОЛЬКО в гейте подавления (схлопнутая строка «Внедрение» несёт `stage_key="deploy"`). После отката (`deploy-staging → development`, `review → development`) строки стадий ПОЗЖЕ текущей больше не рисуются как пройденные — пропадает абсурд «✅ Внедрение + 🔄 Разработка»; `is_active_stage` не тронут. (2) **Метрики (Деф.3):** `_stage_line` агрегирует ВСЕ `agent_runs` агента стадии (Σ cost / Σ токены / Σ время теми же per-run-формулами, что блок тоталов задачи), а не последний прогон — каждый агент привязан ровно к одной строке `_TRACKER_STAGES`, поэтому Σ(строк стадий) ≡ тоталы ≡ `SUM(agent_runs)` по `task_id`; модель/эффорт/«попытка N» берутся из последнего прогона. Прогоны, подавлённые откатом, по-прежнему входят в тоталы (намеренная семантика отката).
-
 **Строка Plane-статуса и кликабельный номер (ORCH-067, слой B — индикация).** Под заголовком карточка несёт строку `📍 <Plane-статус>` по модели ORCH-066. Источник — двухслойный, контракт **never raises**:
- **Оффлайн-ядро** `plane_status_label(task_row)` — чистая функция БЕЗ сети: `stage → статус` (`created→To Analyse`, `analysis→Analysis`, `architecture→Architecture`, `development→Development`, `review→Code-Review`, `testing→Testing`, `deploy-staging→Deploying (staging)` [ORCH-091], `deploy→⏸️ Awaiting Deploy`, `done→Done`, `cancelled→Cancelled` [ORCH-091]) + `⏸️ In Review` из brd-часов (`brd_review_started_at` задан, `…_ended_at` пуст). **ORCH-091:** карта `_STAGE_STATUS_LABEL` покрывает ВСЕ ключи `STAGE_TRANSITIONS` (полнота — тестом, не статичным списком); неизвестная/будущая стадия → нейтральный фолбэк (капитализированное имя стадии), а НЕ «To Analyse» (он остаётся лишь явным лейблом `created` и безопасной деградацией на истинно-битом входе).
+- **Оффлайн-ядро** `plane_status_label(task_row)` — чистая функция БЕЗ сети: `stage → статус` (`created→To Analyse`, `analysis→Analysis`, `architecture→Architecture`, `development→Development`, `review→Code-Review`, `testing→Testing`, `deploy→⏸️ Awaiting Deploy`, `done→Done`) + `⏸️ In Review` из brd-часов (`brd_review_started_at` задан, `…_ended_at` пуст). Неизвестная/битая стадия → безопасный дефолт `To Analyse`.
 - **Live-overlay** `_live_plane_branch_override` — best-effort: дорисовывает ветви-статусы, неразличимые оффлайн (Needs Input / Blocked / Rejected / Cancelled / Deploying / Monitoring after Deploy), чтением живого Plane-статуса (`fetch_issue_state` с коротким `tracker_live_status_timeout_s`, TTL-кэш `tracker_live_status_ttl_s`, kill-switch `tracker_live_status`). Любой сбой / выключенный флаг / нехватка данных → оффлайн-метка; `⏸️ In Review` (авторитет brd-часов) overlay не консультирует. Анти-false-positive: `deploying/monitoring`, алиасящие базовый UUID на проекте без выделенного статуса (enduro), не вызывают override.

 **Кликабельный номер задачи (ORCH-067).** Номер в заголовке карточки И во всех уведомлениях орка, где упоминается `work_item_id`, — HTML-ссылка на issue в Plane через общий `plane_issue_link` / `link_for` (URL строит `_plane_issue_url` с loopback/workspace/project-гардами, переиспользуя резолв ORCH-017). Fail-safe: при нехватке любого из (web-base/не-loopback, workspace, project_id, plane_issue_id) → `html.escape(work_item_id)` без `<a>`; динамические части экранируются, `<a>`-разметка валидна под `parse_mode=HTML`. Алерты `stage_engine`/`launcher`/`security_gate`/`reconciler` переведены на `link_for` (резолвит `repo`+`plane_issue_id` из БД по `task_id` или `work_item_id`).

-**HTML-безопасность данных карточки (ORCH-095).** Текст карточки шлётся с `parse_mode=HTML` и собирается из слотов двух категорий: **markup** (намеренная разметка — `num_html`/`plane_issue_link`, `link_for(...)`, `_done_link(...)`, уже-экранированный `esc_title`) и **data** (подставляемые значения — длительности `_fmt_minutes`/`_capped_review_str`, статус-лейбл `_card_status_label`, имя модели `short_model_name`, эффорт `_run_effort`, токены/стоимость `fmt_tokens`/`fmt_cost`). Инвариант: **каждый data-слот экранируется `html.escape` ровно один раз на границе рендера** (`render_task_tracker`/`_stage_line`); функции-источники остаются HTML-агностичными, markup-слоты не экранируются (двойное экранирование запрещено). Это устранило класс «неэкранированные данные в HTML-тексте»: до фикса `_fmt_minutes(<60s)` возвращал литерал `<1м`, который Telegram парсил как открывающий тег → `editMessageText` `400 can't parse entities` → `EDIT_FAILED` → ранний `return` (анти-дубль ORCH-087) → карточка застывала (инцидент ORCH-093). `_fmt_minutes` по-прежнему возвращает `<1м` — escape на границе (`&lt;1м`) рендерит его визуально идентично; формат не меняется. Застрявшая (в окне) карточка авто-восстанавливается следующим безопасным рендером; `edit_telegram`/`update_task_tracker`/леджер сирот/режимы `bump`/`edit` не тронуты. Детали — [ORCH-095 ADR-001](../work-items/ORCH-095/06-adr/ADR-001-html-safe-card-data-render.md).
-
 ## Database Schema

 ```sql
@@ -350,7 +329,7 @@ webhook (plane/gitea)                 background thread (queue_worker)

 | Колонка | Назначение |
 |--------|------------|
-| `status` | `queued` → `running` → `done` \| `failed` \| `cancelled` (ORCH-090: терминальный исход STOP-отмены, не реквью'ится) |
+| `status` | `queued` → `running` → `done` \| `failed` |
 | `attempts` / `max_attempts` | счётчик попыток (инкремент при claim) / лимит ретраев (default 2) |
 | `run_id` | FK на `agent_runs.id` после старта |
 | `pid` | (ORCH-065) pid агентского процесса (`proc.pid` из `_spawn`); liveness-сигнал для job-reaper. Добавляется `_ensure_column` (idempotent) |
--- a/docs/deployment/BUNDLED_SETUP.md
+++ b/docs/deployment/BUNDLED_SETUP.md
@@ -1,436 +0,0 @@
-# BUNDLED_SETUP — Bundled-тираж: весь стек одним комплектом (ORCH-103)
-
-> **Golden source Bundled-тиража (Type B эпика ORCH-10).** Маршрут «чистый хост →
-> работающий конвейер» для заказчика **без собственной инфраструктуры**: один
-> compose-комплект (`deploy/bundled/docker-compose.yml`) поднимает оркестратор +
-> watchdog + Gitea + Plane CE, один запуск `scripts/bootstrap_bundle.py apply`
-> доводит стек до рабочего состояния. Каждый шаг — исполняемая команда + явная
-> проверка результата (**Проверка:** / PASS / FAIL). Хост-специфика — только
-> плейсхолдеры `<...>` и `$ENV_VAR`. Тираж **stateless**: данные/задачи/секреты
-> боевого (исходного) хоста **НЕ переносятся** ни на одном шаге (§12).
-> Границы слоёв тиража (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1;
-> канон Lite (своя инфраструктура Plane/Gitea) — `docs/deployment/LITE_SETUP.md`.
-
---
-
-## 1. Рамка Bundled
-
-**Что входит в комплект** (compose-проект `orchestrator-bundle`, одна bridge-сеть):
- `orchestrator` (конвейер, образ собирается из этого чекаута) и
-  `orchestrator-watchdog` (независимый sidecar-мониторинг);
- **Gitea** (git-хостинг, пиннованный официальный образ);
- **Plane CE — ≈ 14 контейнеров** (зеркало официального selfhost-комплекта:
-  web/space/admin/api/worker/beat-worker/migrator/live + postgres/redis/
-  rabbitmq/minio/proxy) — это **ресурсоёмко**, см. §2.
-
-**Что НЕ входит** (внешние предусловия заказчика):
- **Claude CLI / LLM-доступ** — дистрибутив claude-code, node и аутентификация
-  живут на хосте и пробрасываются маунтами (§8); без них стек поднимется, но
-  конвейер не поедет;
- **Telegram-боты** — опциональны (§9): пусто = деградация только нотификаций;
- **HTTPS/домены/reverse-proxy** — вне bundle: наружу публикуются три http-порта
-  (§2), терминирование TLS — средствами заказчика.
-
-**Bundled vs Lite:** Lite (`LITE_SETUP.md`) подключает оркестратор к **вашим**
-Plane/Gitea; Bundled везёт их **с собой** на чистых томах. Staging-контур орка в
-bundle отсутствует вовсе: заказчик Type B эксплуатирует платформу для своих
-проектов, а не развивает её self-hosting'ом (нужен self-hosting — маршрут Lite,
-`LITE_SETUP.md` §9.3). Репо `orchestrator` в bundle-инсталляции **не
-регистрируется** как проект.
-
-**Осознанный компромисс (TR-7):** git-доступ агентов — HTTP token-remote
-(токен бот-юзера в конфиге локальных чекаутов, права 600); ssh-контур
-сознательно не вводится; порты БД/брокера/minio наружу не публикуются.
-
---
-
-## 2. Требования к хосту
-
-Linux x86_64, один хост. Минимумы проверяет preflight bootstrap **до любых
-мутаций** (пороги — константы `scripts/bootstrap_bundle.py`, ниже — те же цифры;
-подтверждаются замером приёмочного развёртывания):
-
-| Ресурс | Минимум | Почему |
-|--------|---------|--------|
-| RAM | **8 GB** | Plane CE — ≈ 14 контейнеров (миграции и брокер прожорливы) |
-| Диск | **40 GB** свободно | образы стека + тома postgres/minio/gitea + данные орка |
-| CPU | **4 vCPU** (рекомендация) | меньше — стек поднимется, но будет медленным |
-
-**Карта публикуемых портов** (дефолты; конфигурируемы в
-`deploy/bundled/.env`, ключи `BUNDLE_*`):
-
-| Порт | Ключ | Сервис |
-|------|------|--------|
-| 8500 | `BUNDLE_ORCH_PORT` | API оркестратора (`/health`, `/queue`, `/metrics`, вебхуки) |
-| 8080 | `BUNDLE_PLANE_PORT` | Plane UI (proxy) |
-| 3000 | `BUNDLE_GITEA_HTTP_PORT` | Gitea web/API |
-
-Postgres/redis/rabbitmq/minio наружу **не публикуются** (машинный трафик —
-внутрисетевой сервис-DNS).
-
-```bash
-free -g                                   # RAM ≥ 8 GB
-df -h .                                   # свободно ≥ 40 GB
-nproc                                     # ≥ 4
-ss -ltn | grep -E ':(8500|8080|3000)\b' || echo "ports free"
-```
-
-**Проверка:** ресурсы не ниже минимумов и `ports free` — PASS. Порт занят →
-смените соответствующий `BUNDLE_*`-ключ в §5 (или освободите порт) — иначе
-preflight откажет (FAIL до мутаций, это штатно).
-
---
-
-## 3. Предусловия
-
-Софт хоста: Docker Engine + Compose v2, git, python3 (+venv), sudo у оператора.
-
-```bash
-uname -sm                      # Linux x86_64
-docker --version && docker compose version
-git --version && python3 --version
-python3 -m venv --help >/dev/null && echo "venv: ok"
-getent group docker            # третье поле — gid, понадобится в §5 (ORCH_DOCKER_GID)
-id -u && id -g                 # uid/gid оператора (ORCH_RUN_UID / ORCH_RUN_GID)
-```
-
-**Проверка:** все команды отвечают без ошибок, gid группы docker известен —
-PASS; что-то отсутствует — FAIL (доставьте пакет средствами дистрибутива).
-
---
-
-## 4. Получение кода
-
-Переносится **только код** — чекаут репо `orchestrator` (норматив §12).
-
-```bash
-git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>
-cd <путь-чекаута>
-ls deploy/bundled/docker-compose.yml deploy/bundled/.env.example \
-   scripts/bootstrap_bundle.py scripts/gen_secrets.py scripts/onboard_project.py
-```
-
-**Проверка:** все пять файлов на месте — PASS. Канал дистрибуции
-(`<ORCHESTRATOR_GIT_URL>`) согласуйте с поставщиком платформы (как в
-`LITE_SETUP.md` §3).
-
---
-
-## 5. Секреты
-
-Все секреты инсталляции выпускаются **заново на месте** (§12): webhook-секреты —
-`scripts/gen_secrets.py`, внутренние креды Plane/Gitea-стека — генерирует
-bootstrap (в репо — только пустые плейсхолдеры, ни одного дефолтного пароля).
-
-**5.1. Конфиг bundle-инфры.**
-
-```bash
-cd <путь-чекаута>
-cp deploy/bundled/.env.example deploy/bundled/.env
-chmod 600 deploy/bundled/.env
-# заполнить НЕсекретные ключи: BUNDLE_PUBLIC_HOST (IP/имя хоста для браузера),
-# карту портов BUNDLE_* (§2), ORCH_RUN_UID/ORCH_RUN_GID (из §3),
-# ORCH_DOCKER_GID (getent group docker, §3), пути Claude CLI (§8).
-```
-
-**Проверка:**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml config --quiet && echo "config: PASS"
-```
-
-`config: PASS` — интерполяция согласована; ошибка — FAIL (опечатка в
-`deploy/bundled/.env`).
-
-**5.2. Секрет-значения** (пустые ключи `deploy/bundled/.env` и корневого `.env`)
-заполнит `bootstrap_bundle.py apply` (§7): webhook-секреты — субпроцессом
-`gen_secrets.py`, креды postgres/rabbitmq/minio/`SECRET_KEY` Plane и пароль
-админ-бота Gitea — stdlib-генератором. Значения **не печатаются** (только имена
-ключей); повторный запуск **не перетирает** существующие секреты (явная
-регенерация — флаг `--force-secrets`, допустим только ДО первого запуска стека).
-
-```bash
-grep -cE '^(POSTGRES_PASSWORD|SECRET_KEY|RABBITMQ_DEFAULT_PASS|MINIO_ROOT_PASSWORD|GITEA_ADMIN_PASSWORD)=$' \
-  deploy/bundled/.env
-```
-
-**Проверка:** до §7 счётчик `5` (пустые плейсхолдеры) — PASS; после §7 — `0`.
-
---
-
-## 6. Запуск bundle-compose
-
-Одна команда поднимает весь стек (≈ 16 контейнеров; первый запуск тянет образы
-и гоняет миграции Plane — это минуты, не секунды).
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml up -d
-docker compose -f deploy/bundled/docker-compose.yml ps
-```
-
-**Проверка:** все сервисы в состоянии `Up`/`Up (healthy)`; `migrator` —
-`Exited (0)` (одноразовая миграция) — PASS. Контейнер в рестарт-цикле — FAIL
-(§14). Шаг идемпотентен; можно пропустить — `bootstrap_bundle.py apply` выполнит
-`up -d` сам (§7).
-
---
-
-## 7. Bootstrap
-
-Доводка «одним запуском»: preflight → секреты → up/готовность → init Gitea
-(полностью автоматом: админ-бот + API-токен) → init Plane → онбординг
-sandbox-проекта **строго** кирпичом `onboard_project.py` (22 канонических
-статуса, включая fail-closed **`Confirm Deploy`** и **`STOP`**, лейблы,
-репо+webhook — golden source `docs/operations/ONBOARDING.md` §1) → git-доступ
-агентов → сборка `.env`/`.env.watchdog` → health.
-
-```bash
-python3 scripts/bootstrap_bundle.py            # план + preflight-диагностика (ноль мутаций)
-python3 scripts/bootstrap_bundle.py apply      # полный прогон
-```
-
-**Manual-step чекпоинты Plane CE** (API первичной инициализации в CE нет;
-каждый чекпоинт: точная инструкция → подтверждение → верификация результата
-API-пробой, молчаливый пропуск запрещён):
-1. **instance setup** — открыть Plane UI, зарегистрировать первого
-   пользователя (станет администратором инстанса);
-2. **workspace** — создать workspace, ввести его slug в bootstrap;
-3. **API-токен** — Workspace Settings → API tokens, вставить значение в
-   bootstrap (ввод скрыт; уходит в `ORCH_PLANE_API_TOKEN`);
-4. **workspace-webhook** — bootstrap регистрирует сам (запись в Postgres
-   инсталляции, путь Б канона `LITE_SETUP.md` §5.4) и проверяет; при отказе —
-   честный ручной шаг с той же проверкой;
-5. **порядок статусов на доске** — drag-and-drop по отчёту onboard
-   (`docs/operations/ONBOARDING.md`).
-
-Exit-коды: `0` — успех; `2` — остановка на manual-step/предусловии (выполните
-шаг и перезапустите `apply` — завершённые шаги пропускаются, повторный запуск
-безопасен); `1` — ошибка. Пароль админ-бота Gitea — ключ `GITEA_ADMIN_PASSWORD`
-в `deploy/bundled/.env` (права 600; вход в UI Gitea под
-`GITEA_ADMIN_USERNAME`).
-
-**Проверка:**
-
-```bash
-python3 scripts/bootstrap_bundle.py verify && echo "bootstrap: PASS"
-```
-
-`verify` зелёный (health/queue/metrics + onboard verify) — PASS; exit 2 —
-остались ручные пункты отчёта; exit 1 — FAIL (§14).
-
---
-
-## 8. LLM (claude CLI)
-
-Канон — `LITE_SETUP.md` §7 (полностью применим; не дублируется). Кратко: на
-хост ставятся claude-code + node, выполняется интерактивный логин CLI; пути
-прописываются в `deploy/bundled/.env` (это источники маунтов контейнера орка):
-`ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`,
-`ORCH_HOST_CLAUDE_JSON`.
-
-```bash
-claude --version
-docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
-```
-
-**Проверка:** обе команды печатают версию — PASS; вторая падает — пути в
-`deploy/bundled/.env` не указывают на фактические каталоги хоста (§14.4).
-
---
-
-## 9. Telegram
-
-Канон — `LITE_SETUP.md` §8 (два независимых бота, C-1: токен орка для watchdog
-переиспользовать запрещено). Ключи орка (`ORCH_TELEGRAM_BOT_TOKEN`,
-`ORCH_TELEGRAM_CHAT_ID`) — в корневой `.env`; ключи watchdog
-(`WATCHDOG_TG_BOT_TOKEN`, `WATCHDOG_TG_CHAT_ID`) — **только** в `.env.watchdog`
-(файл-носитель, `LITE_SETUP.md` §4.3). Шаг опционален: пустые токены =
-деградация только нотификаций.
-
-```bash
-grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=' .env
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=' .env.watchdog
-docker compose -f deploy/bundled/docker-compose.yml up -d orchestrator orchestrator-watchdog
-```
-
-**Проверка:** ключи заполнены и контейнеры пересозданы → тестовое сообщение от
-обоих ботов (`getMe` — команды в `LITE_SETUP.md` §8) — PASS; пусто — осознанный
-PASS без нотификаций.
-
---
-
-## 10. Онбординг следующих проектов
-
-Sandbox-проект создал bootstrap (§7). Каждый следующий проект заказчика —
-штатный runbook `docs/operations/ONBOARDING.md` поверх bundle-инсталляции; для
-команд из чекаута: Plane/Gitea доступны на `localhost`-портах §2, webhook-URL —
-in-network `http://orchestrator:8500/webhook/gitea`.
-
-```bash
-. .venv/bin/activate    # venv создан bootstrap'ом (§7)
-python3 scripts/onboard_project.py plan \
-  --name "<имя проекта>" --repo <repo> --prefix <PREFIX> \
-  --stack "<стек>" --test-cmd "<команда тестов>" \
-  --prod-port <порт-прода> --staging-port <порт-staging> \
-  --webhook-url http://orchestrator:8500/webhook/gitea
-# план устроил → apply → verify (как в LITE_SETUP.md §10), затем:
-# строку ORCH_PROJECTS_JSON из отчёта — в .env и пересоздать орк:
-docker compose -f deploy/bundled/docker-compose.yml up -d --force-recreate orchestrator
-```
-
-**Проверка:** `verify` зелёный; `GET /queue` отвечает после пересоздания — PASS.
-
---
-
-## 11. Smoke
-
-Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до
-`done`» — опционально) поверх bundle-инсталляции, без форка. Минимальный сигнал
-«конвейер доехал»: issue в sandbox-проекте Plane → статус **To Analyse** →
-артефакты `01`–`04` в ветке задачи.
-
-```bash
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -30
-curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
-# создать issue в Plane (порт 8080) → перевести в «To Analyse», затем:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40   # job появился
-git -C deploy/bundled/repos/sandbox fetch origin
-git -C deploy/bundled/repos/sandbox ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id>/"
-```
-
-**Проверка:** оба направления связности живы — job в `/queue` (Plane→орк
-доехал), `ls-tree` показывает `01-brd.md` … `04-test-plan.yaml` (орк→Gitea
-пишет; Gitea→орк события идут) — PASS. Любой шаг FAIL → тираж FAIL: соберите
-`docker compose -f deploy/bundled/docker-compose.yml logs --tail 100 orchestrator`
-и снапшот `GET /queue`, разбор — §14. (Порты замените, если меняли `BUNDLE_*`.)
-
---
-
-## 12. Stateless-проверка
-
-**Нормативно: данные/задачи/секреты/БД боевого (исходного) хоста НЕ
-переносятся** (зеркало `docs/operations/REPLICATION.md` §5). Все тома bundle
-созданы заново при первом `up`; секреты — только свежевыпущенные (§5); в
-Plane/Gitea инсталляции нет чужих задач/репо/пользователей.
-
-```bash
-docker volume ls --format '{{.Name}}' | grep '^orchestrator-bundle' # только тома этой инсталляции
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool        # счётчики нулевые
-```
-
-**Проверка:** в `/queue` нулевые счётчики и ни одной чужой задачи (никаких
-work-item исходного хоста) — PASS. Чужая задача/перенесённый файл БД — FAIL:
-инсталляция собрана не stateless, выполните полный сброс (§13) и повторите.
-
---
-
-## 13. Остановка и полный сброс
-
-Teardown — **только эта документированная процедура** (в bootstrap delete-режима
-сознательно нет, ADR-001 D9).
-
-**Остановка (обратимая):**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml down
-```
-
-**Проверка:** `docker compose -f deploy/bundled/docker-compose.yml ps` пуст;
-тома целы (`docker volume ls | grep orchestrator-bundle`) — PASS.
-
-**Полный сброс (НЕОБРАТИМО — удаляет все данные Plane/Gitea/орка):**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml down -v
-rm -rf deploy/bundled/data deploy/bundled/repos
-rm -f deploy/bundled/.env .env .env.watchdog
-```
-
-**Проверка:** `docker volume ls --format '{{.Name}}' | grep -c '^orchestrator-bundle'`
-→ `0`; live-конфигов нет — PASS (хост чист, можно разворачивать заново с §5).
-
---
-
-## 14. Траблшутинг
-
-Формат: симптом → диагностика → лечение.
-
-**14.1. Webhook не доходит (issue в Plane есть, job в `/queue` нет).**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 orchestrator | grep -i "webhook\|signature"
-docker compose -f deploy/bundled/docker-compose.yml exec -T plane-db \
-  psql -U plane -d plane -c "SELECT url, is_active FROM webhooks;"
-```
-
-Лечение: (а) нет строки webhook → §7 чекпоинт 4; (б) URL не
-`http://orchestrator:8500/webhook/plane` → исправьте на in-network URL;
-(в) 401/HMAC → секрет в Plane обязан байт-в-байт совпадать с
-`ORCH_PLANE_WEBHOOK_SECRET` корневого `.env`. Для Gitea-направления проверьте
-Recent Deliveries в настройках hook'а репо; помните про
-`GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` в bundle-compose (без него
-Gitea молча режет вебхуки в приватные адреса).
-
-**14.2. Не хватает RAM / OOM (контейнеры Plane в рестарт-цикле).**
-
-```bash
-free -g && docker stats --no-stream | head -20
-docker compose -f deploy/bundled/docker-compose.yml ps
-```
-
-Лечение: минимум §2 (8 GB; Plane ≈ 14 контейнеров). Меньше — добавьте RAM/swap;
-preflight bootstrap отказывает заранее именно поэтому.
-
-**14.3. Порт занят (`up` падает с bind error).**
-
-```bash
-ss -ltnp | grep -E ':(8500|8080|3000)\b'
-```
-
-Лечение: смените `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`
-в `deploy/bundled/.env` и повторите `up`/bootstrap.
-
-**14.4. claude не найден / агент падает на старте.**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
-ls "$(grep '^ORCH_HOST_CLAUDE_CODE_DIR=' deploy/bundled/.env | cut -d= -f2)"
-```
-
-Лечение: пути `ORCH_HOST_*` в `deploy/bundled/.env` обязаны указывать на
-фактические каталоги хоста; креды CLI читаемы uid'ом `ORCH_RUN_UID` (канон —
-`LITE_SETUP.md` §7/§13.3); после правки — `up -d --force-recreate orchestrator`.
-
-**14.5. Миграции Plane не завершились (bootstrap падает на ожидании).**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 migrator plane-db
-docker compose -f deploy/bundled/docker-compose.yml ps plane-db plane-mq plane-redis
-```
-
-Лечение: чаще всего — нехватка RAM/диска (§14.2) или невыпущенные секреты
-(пустой `POSTGRES_PASSWORD` → postgres не стартует; прогоните §7, который
-заполняет креды ДО `up`). После лечения — повторный `apply` (идемпотентен).
-
-**14.6. PR задачи не мержится / HOLD.** Branch protection на `main` в Gitea
-**НЕ включать** — норматив `LITE_SETUP.md` §6.4 (ломает PR-merge API
-merge-актора); bundle-Gitea конфигурируется тем же правилом.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "http://127.0.0.1:3000/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-Лечение: непустой список правил → удалить (канон `LITE_SETUP.md` §6.4/§13.7).
-
---
-
-*Golden source Bundled-тиража (ORCH-103, ADR-001 D10). **Норматив сопровождения
-(NFR-5):** меняешь шаги Bundled-тиража (состав bundle-compose, ключи
-`deploy/bundled/.env.example`, шаги bootstrap, smoke) → обнови этот док В ТОМ ЖЕ
-PR. Полноту и гигиену держит `tests/test_bundled_setup_doc.py`; кирпичи-каноны:
-`LITE_SETUP.md` (§5–§8 — подключения), `docs/operations/ONBOARDING.md` (статусы
-§1, онбординг), `docs/operations/REPLICATION.md` (карта env §2, секреты §3,
-smoke §4), `deploy/bundled/.env.example` + `.env.example` /
-`.env.watchdog.example` (каноны ключей).*
--- a/docs/deployment/LITE_SETUP.md
+++ b/docs/deployment/LITE_SETUP.md
@@ -1,596 +0,0 @@
-# LITE_SETUP — Lite-тираж: оркестратор + watchdog на вашей инфраструктуре (ORCH-102)
-
-> **Golden source Lite-тиража (Type A эпика ORCH-10).** Сквозной маршрут
-> «голый хост → работающий конвейер» для внешнего оператора/заказчика. Каждый шаг —
-> исполняемая команда + явная проверка результата (**Проверка:** / PASS / FAIL).
-> Хост-специфика в командах — только плейсхолдеры `<...>` и `$ENV_VAR`.
-> Тираж **stateless**: данные/задачи/секреты исходного (боевого) хоста **НЕ переносятся**
-> ни на одном шаге — всё создаётся заново (§12).
-
---
-
-## 1. Рамка Lite
-
-**Что разворачиваем:** два контейнера платформы — `orchestrator` (конвейер, порт
-`ORCH_DEPLOY_PROD_TARGET_PORT`, дефолт 8500) и `orchestrator-watchdog`
-(независимый sidecar-мониторинг). Третий сервис `orchestrator-staging` существует в том же
-compose-файле, но строго за профилем `staging` и в базовом Lite-контуре не поднимается (§9).
-
-**Что заказчик ставит и администрирует сам** (вне этой инструкции — как продукты):
- **Plane** (task-management) — своя инсталляция; здесь только её *подключение* (§5);
- **Gitea** (git-хостинг) — своя инсталляция; здесь только её *подключение* (§6);
- **Telegram-боты** (нотификации) — свои боты (§8);
- **LLM-доступ** (claude CLI + node) — свой дистрибутив и аутентификация (§7).
-
-**Границы слоёв тиража** (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1.
-Этот док собирает кирпичи 10-common (карта env, секреты, smoke) в один маршрут и не форкает их.
-
-**Платформенные конвенции (не менять):**
- репо платформы обязан называться **`orchestrator`** (узел безопасности `SELF_HOSTING_REPO`);
- имена compose-сервисов/профиля (`orchestrator`, `orchestrator-watchdog`,
-  `orchestrator-staging`, профиль `staging`) — константы платформы;
- контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout контейнера,
-  не хост-значения; не параметризуются.
-
---
-
-## 2. Предусловия хоста
-
-Поддерживаемый контур: **Linux x86_64, Docker Engine + Compose v2, git, python3, node** +
-дистрибутив claude-code на хосте. Вне контура — вне гарантии Lite. Каждое предусловие —
-команда проверки; все проверки PASS → можно переходить к §3.
-
-**2.1. ОС и базовые зависимости.**
-
-```bash
-uname -sm                      # Linux x86_64
-docker --version               # Docker Engine
-docker compose version         # Compose v2
-git --version
-python3 --version              # 3.x (для scripts/*.py)
-node --version                 # путь к бинарю станет ORCH_HOST_NODE_BIN
-```
-
-**Проверка:** все команды отвечают версиями без ошибок — PASS; любая отсутствует — FAIL
-(доставить пакет средствами вашего дистрибутива).
-
-**2.2. Пользователь-владелец и uid/gid (инвариант ORCH-040).** Контейнеры бегут под
-`ORCH_RUN_UID:ORCH_RUN_GID` — это обязан быть uid:gid владельца каталога репозиториев
-`ORCH_HOST_REPOS_DIR`, иначе git-артефакты конвейера не запишутся.
-
-```bash
-id -u <deploy-user>; id -g <deploy-user>     # значения для ORCH_RUN_UID / ORCH_RUN_GID
-mkdir -p <путь-каталога-репозиториев>        # станет ORCH_HOST_REPOS_DIR
-stat -c '%u:%g' <путь-каталога-репозиториев> # обязан совпасть с ORCH_RUN_UID:ORCH_RUN_GID
-```
-
-**Проверка:** uid:gid владельца каталога = будущие `ORCH_RUN_UID`/`ORCH_RUN_GID` — PASS.
-
-**2.3. Группа docker (доступ к docker.sock).**
-
-```bash
-getent group docker            # третье поле — gid, станет ORCH_DOCKER_GID
-```
-
-**Проверка:** строка вида `docker:x:<gid>:...` есть — PASS; группы нет — FAIL
-(установите Docker корректно / создайте группу).
-
-**2.4. Каталог ssh-ключей деплой-хука** (понадобится для git-push артефактов агентов и
-деплой-хуков; монтируется в `$HOME/.ssh` акторов).
-
-```bash
-mkdir -p <путь-ssh-каталога>                 # станет ORCH_HOST_SSH_DIR
-ssh-keygen -t ed25519 -f <путь-ssh-каталога>/id_ed25519 -N "" -C "orchestrator@<host>"
-ls -l <путь-ssh-каталога>                    # ключи читаемы пользователем из 2.2
-```
-
-**Проверка:** каталог существует, ключи на месте, владелец — пользователь из 2.2 — PASS.
-Публичный ключ добавьте в Gitea (Settings → SSH Keys) на шаге §6.
-
-**2.5. Свободные порты** (дефолты платформы: 8500 — прод, 8501 — staging).
-
-```bash
-ss -ltn | grep -E ':(8500|8501)\b' || echo "ports free"
-```
-
-**Проверка:** вывод `ports free` — PASS. Порты заняты → выберите другие и на шаге §4
-синхронно задайте `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄
-`ORCH_POST_DEPLOY_BASE_URL` (и `ORCH_STAGING_PORT` ≠ прод-порт — guard ORCH-058 fail-closed).
-
---
-
-## 3. Перенос кода
-
-Переносится **только код** — чекаут репо `orchestrator`. **НИКАКИХ** данных, БД или `.env`
-с исходного хоста (норматив §12). Watchdog отдельно не переносится: его код — каталог
-`watchdog/` того же репо, образ собирается локально compose'ом.
-
-```bash
-git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>   # путь станет ORCH_DEPLOY_HOST_REPO_PATH
-cd <путь-чекаута>
-```
-
-Конкретный канал дистрибуции (`<ORCHESTRATOR_GIT_URL>` — зеркало/архив/доступ к
-Gitea поставщика) согласуйте с поставщиком платформы; опционально — `--branch <тег-среза>`.
-
-**Проверка:**
-
-```bash
-git -C <путь-чекаута> log --oneline -1            # коммит виден
-ls <путь-чекаута>/docker-compose.yml <путь-чекаута>/watchdog/Dockerfile \
-   <путь-чекаута>/.env.example <путь-чекаута>/.env.watchdog.example
-```
-
-Все файлы на месте — PASS.
-
---
-
-## 4. Конфигурация
-
-`.env` собирается **с нуля от канона `.env.example`** (100% ключей старта; полная карта
-переменных и их семантика — `docs/operations/REPLICATION.md` §2). Дефолт каждого ключа =
-значению исходного хоста, поэтому задаёте только то, что отличается у вас.
-
-**4.1. Создать `.env` и выпустить webhook-секреты.**
-
-```bash
-cd <путь-чекаута>
-cp .env.example .env
-python3 scripts/gen_secrets.py        # печатает свежие ORCH_PLANE_WEBHOOK_SECRET / ORCH_GITEA_WEBHOOK_SECRET
-```
-
-Вставьте оба напечатанных значения в `.env`. Секреты выпускаются **только заново** —
-боевые не копируются (§12).
-
-**4.2. Обязательные ключи нового хоста** (заполняются в `.env` по ходу §5–§8):
-
-| Группа | Ключи | Откуда |
-|--------|-------|--------|
-| Plane | `ORCH_PLANE_API_URL`, `ORCH_PLANE_WEB_URL`, `ORCH_PLANE_WORKSPACE_SLUG`, `ORCH_PLANE_API_TOKEN` | §5 |
-| Gitea | `ORCH_GITEA_URL`, `ORCH_GITEA_PUBLIC_URL`, `ORCH_GITEA_OWNER`, `ORCH_GITEA_TOKEN` | §6 |
-| Webhook-секреты | `ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET` | 4.1 (`gen_secrets.py`) |
-| Telegram | `ORCH_TELEGRAM_BOT_TOKEN`, `ORCH_TELEGRAM_CHAT_ID` | §8 |
-| Реестр проектов | `ORCH_PROJECTS_JSON` — **обязателен**: встроенный fallback несёт Plane-UUID исходного хоста | §10 |
-| Хост-параметры | `ORCH_AGENT_HOME_DIR`, `ORCH_HOST_REPOS_DIR`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON`, `ORCH_HOST_SSH_DIR`, `ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_RUN_UID`, `ORCH_RUN_GID`, `ORCH_DOCKER_GID`, `ORCH_DEPLOY_HOST_REPO_PATH`, `ORCH_AGENT_GIT_NAME`, `ORCH_GIT_EMAIL_DOMAIN` | значения из §2–§3 |
-| Порты | `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`; `ORCH_STAGING_PORT` ≠ прод-порт | §2.5 |
-
-**4.3. Конфиг sidecar-watchdog — отдельный файл-носитель.** Sidecar-контейнер читает
-**ТОЛЬКО `.env.watchdog`**; ключ `WATCHDOG_ENABLED` (и любой другой `WATCHDOG_*`),
-положенный в `.env`, для sidecar **инертен**.
-
-```bash
-cp .env.watchdog.example .env.watchdog
-# заполнить два ключа: WATCHDOG_TG_BOT_TOKEN / WATCHDOG_TG_CHAT_ID (бота создадим в §8)
-```
-
-**Проверка (резолв всей конфигурации):**
-
-```bash
-docker compose config >/dev/null && echo "compose config: PASS"
-```
-
-`PASS` без ошибок интерполяции — конфигурация согласована; ошибка — FAIL (ищите
-незакрытую кавычку/невалидный JSON в `ORCH_PROJECTS_JSON`).
-
---
-
-## 5. Подключение Plane
-
-Инсталляция Plane — ваша; платформа подключается к ней API-токеном и webhook'ом.
-
-**5.1. Workspace и проект.** Создайте workspace (его slug → `ORCH_PLANE_WEB_URL` /
-`ORCH_PLANE_WORKSPACE_SLUG`) и проект под вашу разработку — через UI Plane.
-
-```bash
-# базовая доступность API из хоста оркестратора:
-curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/" \
-  -H "X-API-Key: <plane-api-token>" | head -c 200
-```
-
-**Проверка:** HTTP 200 и JSON со списком проектов — PASS; 401/403 — токен (5.2) ещё не
-выпущен или не имеет прав.
-
-**5.2. API-токен.** Plane UI → Workspace Settings → API tokens → выпустить токен →
-`ORCH_PLANE_API_TOKEN` в `.env`. Токен должен иметь право создавать проекты/статусы
-(нужно для `onboard_project.py apply`, §10).
-
-**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **22 канонических статуса** с
-точными именами и группами; их создаёт `python3 scripts/onboard_project.py apply` (§10),
-полная таблица — `docs/operations/ONBOARDING.md` §1 (golden source; здесь не дублируется).
-Два имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
-активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя) и
-**`STOP`** (отмена задачи; обязан быть в группе `cancelled`).
-
-```bash
-# после §10 — проверить, что статусы созданы:
-curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/<project-uuid>/states/" \
-  -H "X-API-Key: $ORCH_PLANE_API_TOKEN" | python3 -m json.tool | grep -c '"name"'
-```
-
-**Проверка:** счётчик имён = 22 (или больше, если в проекте остались дефолтные статусы
-Plane) и среди них `Confirm Deploy` и `STOP` — PASS.
-
-**5.4. Webhook + HMAC.** Приёмник — `POST https://<orchestrator-public-host>/webhook/plane`;
-подпись — заголовок `X-Plane-Signature` (HMAC-SHA256, hex digest); секрет — значение
-`ORCH_PLANE_WEBHOOK_SECRET` из 4.1. События: Issue, Issue Comment.
-
-**Каверза Plane CE:** webhook **не экспонирован во внешнем `/api/v1`** — настраивается
-одним из двух путей.
-
-*Путь А — UI (если ваша сборка Plane его показывает):* Workspace Settings → Webhooks →
-Add Webhook → URL + Secret (значение `ORCH_PLANE_WEBHOOK_SECRET`) → события Issue,
-Issue Comment → Save.
-
-*Путь Б — прямой SQL в Postgres инсталляции Plane:*
-
-```bash
-WORKSPACE_ID=$(docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> \
-  psql -U plane -d plane -t -A -c "SELECT id FROM workspaces WHERE slug='<workspace-slug>'")
-WEBHOOK_ID=$(cat /proc/sys/kernel/random/uuid)
-docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c "
-INSERT INTO webhooks (id, created_at, updated_at, deleted_at, workspace_id, url, is_active,
-  secret_key, project, issue, module, cycle, issue_comment, is_internal, version)
-VALUES ('${WEBHOOK_ID}', NOW(), NOW(), NULL, '${WORKSPACE_ID}',
-  'https://<orchestrator-public-host>/webhook/plane',
-  true, '<значение ORCH_PLANE_WEBHOOK_SECRET>', true, true, false, false, true, false, 'v1');
-"
-```
-
-**Проверка:**
-
-```bash
-docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c \
-  "SELECT url, is_active FROM webhooks;"
-```
-
-Строка с вашим URL и `is_active = t` — PASS. Сквозная проверка доставки — §11 (smoke);
-generic-образец команд и формат подписи — `docs/operations/SETUP_WEBHOOKS.md`.
-
---
-
-## 6. Подключение Gitea
-
-**6.1. Токен.** Gitea UI → Settings → Applications → Generate Token, scope: `repo`,
-`admin:repo_hook` → `ORCH_GITEA_TOKEN` в `.env`.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" "$ORCH_GITEA_URL/api/v1/user" | head -c 200
-```
-
-**Проверка:** HTTP 200 с JSON вашего пользователя — PASS; владелец репозиториев
-(организация/пользователь) → `ORCH_GITEA_OWNER`, браузерный URL → `ORCH_GITEA_PUBLIC_URL`.
-
-**6.2. Репо проекта.** Создаёт `onboard_project.py apply` (§10) — или вручную (пустой
-репо + initial push). Чекаут обязан появиться в `$ORCH_HOST_REPOS_DIR/<repo>` (общий
-каталог репозиториев из §2.2). Публичный ключ из §2.4 добавьте в Gitea
-(Settings → SSH Keys), чтобы акторы могли пушить.
-
-```bash
-git -C "$ORCH_HOST_REPOS_DIR" clone <git-url-репо-проекта> <repo>
-stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR/<repo>"     # владелец = ORCH_RUN_UID:ORCH_RUN_GID
-```
-
-**Проверка:** чекаут на месте, владелец совпадает — PASS.
-
-**6.3. Per-repo webhook.** Создаёт `onboard_project.py apply` (§10). Параметры (если
-вручную): URL `https://<orchestrator-public-host>/webhook/gitea`, content type `json`,
-события **`push` / `pull_request` / `status`**, branch filter `*`, подпись —
-`X-Gitea-Signature` (HMAC-SHA256). Секрет — **ОДИН глобальный `ORCH_GITEA_WEBHOOK_SECRET`
-на ВСЕ репо** (приёмник валидирует только его; «свой секрет на репо» сломал бы HMAC
-остальных).
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
-```
-
-**Проверка:** hook с вашим URL и тремя событиями существует, `active: true` — PASS.
-
-**6.4. Норматив защиты `main` (ВАЖНО).** **Branch protection на `main` НЕ включать**
-(никаких required-approvals / required-status-checks): merge-актор конвейера мержит PR
-строго через Gitea PR-merge API (INV-4), и protection-правила дают 405/409-класс отказов →
-ложные HOLD задач (ADR D10 ORCH-009). **pre-receive хуки платформа не вводит** и не
-проверяет — защита `main` держится конвенцией (агенты не пушат `main`) + скоупом токенов.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-**Проверка:** пустой список `[]` — PASS; есть правила на `main` — FAIL (удалите их,
-симптом «PR не мержится / HOLD» — §13.7).
-
---
-
-## 7. LLM (claude CLI)
-
-Агенты конвейера — процессы claude CLI **внутри контейнера**, но дистрибутив, node и
-аутентификация живут **на хосте** и пробрасываются маунтами (источники маунтов =
-ключи `.env`).
-
-**7.1. Дистрибутив claude-code и node.** Установите claude-code (npm-дистрибутив
-Anthropic) и node на хост. Пути → `.env`:
-
-```bash
-which node                                   # → ORCH_HOST_NODE_BIN
-npm root -g                                  # каталог глобальных модулей
-ls "<npm-root>/@anthropic-ai/claude-code"    # → ORCH_HOST_CLAUDE_CODE_DIR
-```
-
-**Проверка:** каталог дистрибутива существует и непуст — PASS. Внутри контейнера бинарь
-доступен как `ORCH_CLAUDE_BIN` (дефолт менять не нужно).
-
-**7.2. Аутентификация CLI.** Выполните первичный интерактивный логин claude CLI **на
-хосте** под пользователем из §2.2 (по инструкции Anthropic к claude-code). Логин создаёт
-каталог `~/.claude` и файл `~/.claude.json` — их пути задайте в `ORCH_HOST_CLAUDE_DIR` /
-`ORCH_HOST_CLAUDE_JSON`.
-
-```bash
-claude --version                                            # CLI работает
-sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
-```
-
-**Проверка:** версия печатается; `creds: PASS` — креды читаемы uid'ом контейнера
-(иначе — `chown -R <uid>:<gid>` каталога, симптом §13.3).
-
-**7.3. Модели агентов.** Резолв модели/эффорта — только из конфига (ORCH-41/74):
-дефолты канона уже в `.env.example` (`ORCH_AGENT_MODEL_DEFAULT`,
-`ORCH_AGENT_EFFORT_DEFAULT` и per-агент ключи рядом) — менять не обязательно.
-
-```bash
-grep -E '^ORCH_AGENT_(MODEL|EFFORT)_DEFAULT=' .env
-```
-
-**Проверка:** оба ключа присутствуют и непусты — PASS.
-
---
-
-## 8. Telegram
-
-Каналов **два и они независимы** (C-1 ORCH-100): бот live-трекера оркестратора и
-**отдельный** бот sidecar-watchdog. Токен орка для watchdog переиспользовать
-**ЗАПРЕЩЕНО** — упавший орк не сможет сообщить о себе своим же ботом.
-
-**8.1. Бот трекера.** BotFather → `/newbot` → токен → `ORCH_TELEGRAM_BOT_TOKEN` в `.env`.
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
-# напишите боту любое сообщение (или добавьте его в чат), затем:
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getUpdates" | python3 -m json.tool | grep -m1 '"id"'
-```
-
-**Проверка:** `getMe` → `"ok":true`; `id` чата из `getUpdates` → `ORCH_TELEGRAM_CHAT_ID` —
-PASS.
-
-**8.2. Watchdog-бот (отдельный).** BotFather → `/newbot` ещё раз → токен и chat-id →
-**`.env.watchdog`** (`WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID`). Помните о
-файле-носителе: эти ключи работают только в `.env.watchdog` (§4.3).
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
-```
-
-**Проверка:** `getMe` → `"ok":true`; оба ключа в `.env.watchdog` непусты — PASS.
-
---
-
-## 9. Запуск
-
-**9.1. Базовый Lite-контур (дефолт): орк + watchdog.**
-
-```bash
-cd <путь-чекаута>
-docker compose config --services    # ровно: orchestrator, orchestrator-watchdog, orchestrator-staging
-docker compose up -d --build
-docker compose ps
-```
-
-**Проверка:** запущены **ровно два** контейнера — `orchestrator` и
-`orchestrator-watchdog`; `orchestrator-staging` НЕ поднялся (он строго за
-`profiles: [staging]`) — PASS. Поднялось что-то ещё/меньше — FAIL.
-
-**9.2. Health-чек контрактов.**
-
-```bash
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -20
-curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
-```
-
-**Проверка:** `/health` → HTTP 200, `"status":"ok"`; `/queue` → штатный JSON
-(счётчики очереди); `/metrics` → JSON со `"schema_version": 1` — PASS. (Порт замените,
-если меняли `ORCH_DEPLOY_PROD_TARGET_PORT`.)
-
-**9.3. Вилка staging (опционально).** Базовому контуру «гонять СВОИ проекты» staging
-**не нужен**. Он нужен ТОЛЬКО если вы регистрируете проект `orchestrator` (self-hosting
-развитие самой платформы у себя): стадия `deploy-staging` требует песочницу на
-`ORCH_STAGING_PORT` (изолированная БД `./data/staging`; guard ORCH-058: staging-порт ≠
-прод-порт, fail-closed).
-
-```bash
-cp .env.staging.example .env.staging      # заполнить по аналогии с .env
-docker compose --profile staging up -d orchestrator-staging
-curl -fsS http://127.0.0.1:8501/health
-```
-
-**Проверка (только для этой вилки):** `/health` staging → 200 — PASS.
-
---
-
-## 10. Регистрация проекта заказчика
-
-Onboarding-CLI создаёт Plane-проект с 22 статусами и лейблами (`autoApprove` /
-`autoDeploy` / `Bug`), Gitea-репо с webhook'ом, скелет репо (kit) и печатает merged-реестр.
-Полный runbook — `docs/operations/ONBOARDING.md`; Lite-последовательность:
-
-```bash
-cd <путь-чекаута>
-python3 scripts/onboard_project.py plan \
-  --name "<имя проекта>" --description "<зачем проект>" \
-  --repo <repo> --prefix <PREFIX> \
-  --stack "<стек>" --test-cmd "<команда тестов>" \
-  --prod-port <порт-прода-проекта> --staging-port <порт-staging-проекта> \
-  --webhook-url https://<orchestrator-public-host>/webhook/gitea
-# план устроил → тот же вызов с apply; затем read-only контроль:
-python3 scripts/onboard_project.py verify <те же аргументы>
-```
-
-**Проверка:** `apply` завершился без ошибок (exit 0; `2` = остались 🖐 ручные шаги — выполните
-их по отчёту), `verify` зелёный — PASS.
-
-Дальше реестр и рестарт:
-
-```bash
-# 1) строку ORCH_PROJECTS_JSON=[...] из отчёта apply вставить в .env (заменить целиком);
-# 2) дождаться тихого окна и управляемо перезапустить орк:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20   # нет running-job
-docker compose up -d --force-recreate orchestrator
-# 3) убедиться, что инстанс жив и реестр подхвачен:
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20
-```
-
-**Проверка:** `/health` → 200 после рестарта; в Plane создан проект со статусами
-(см. §5.3), в Gitea — репо с webhook (§6.3) — PASS.
-
---
-
-## 11. Smoke: «конвейер доехал»
-
-Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до `done`» —
-опционально), без форка; каждый шаг несёт явный PASS/FAIL. Lite-предусловия: §2–§10 этого
-дока выполнены, проект заказчика зарегистрирован (§10).
-
-Минимальный сигнал «конвейер доехал» (шаги 4–5 чек-листа): создайте issue в Plane-проекте
-и переведите в статус **To Analyse**, затем:
-
-```bash
-# задача появилась и analyst-job в очереди:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40
-# по завершении стадии analysis — артефакты 01–04 в ветке задачи:
-git -C "$ORCH_HOST_REPOS_DIR/<repo>" fetch origin
-git -C "$ORCH_HOST_REPOS_DIR/<repo>" ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id-задачи>/"
-```
-
-**Проверка:** в `/queue` виден job задачи; `ls-tree` показывает `01-brd.md` …
-`04-test-plan.yaml` — PASS.
-
-**Итоговый вердикт:** все шаги чек-листа PASS ⇒ **тираж PASS**; любой шаг FAIL ⇒ тираж
-FAIL — соберите `docker logs orchestrator --tail 100` и снапшот `GET /queue`, разбор —
-§13.
-
---
-
-## 12. Stateless-проверка
-
-**Нормативно: данные/задачи/секреты боевого (исходного) хоста НЕ переносятся** (зеркало
-`docs/operations/REPLICATION.md` §5). БД создаётся **пустой** при первом старте; `.env` /
-`.env.staging` / `.env.watchdog` собраны с нуля (§4); секреты — только свежевыпущенные
-(`gen_secrets.py` + чек-лист внешних токенов `docs/operations/REPLICATION.md` §3).
-
-Проверка чистоты развёрнутого инстанса (выполнить ДО первой своей задачи):
-
-```bash
-ls -la <путь-чекаута>/data/                                  # БД появилась только после первого старта
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool # счётчики jobs нулевые
-```
-
-**Проверка:** в `/queue` нулевые счётчики и НИ ОДНОЙ задачи чужих проектов (никаких
-`ORCH-*`/`ET-*` исходного хоста) — PASS. Любая чужая задача/перенесённый файл БД — FAIL:
-инстанс собран не stateless, пересоберите `data/` с нуля.
-
---
-
-## 13. Траблшутинг первичной настройки
-
-Формат: симптом → команда диагностики → лечение.
-
-**13.1. Webhook отвечает 401 / HMAC mismatch.**
-
-```bash
-docker logs orchestrator --tail 50 2>&1 | grep -i "webhook\|signature\|401"
-```
-
-Лечение: секрет в `.env` (`ORCH_PLANE_WEBHOOK_SECRET` / `ORCH_GITEA_WEBHOOK_SECRET`)
-обязан **байт-в-байт** совпадать с секретом в настройке webhook'а (Plane §5.4 / Gitea
-§6.3); после правки `.env` — управляемый рестарт (§10). Формат подписи —
-`docs/operations/SETUP_WEBHOOKS.md`.
-
-**13.2. Задача в Plane создана, но в оркестраторе не появилась.**
-
-```bash
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -30   # есть ли job
-docker logs orchestrator --tail 50 2>&1 | grep -i "ignored\|unknown project"
-grep ORCH_PROJECTS_JSON .env                                              # uuid вашего проекта в реестре?
-```
-
-Лечение: (а) проект отсутствует/с чужим UUID в `ORCH_PROJECTS_JSON` → поправить реестр
-(§10) + рестарт; (б) webhook не доставлен → Plane: `SELECT url, is_active FROM webhooks;`
-(§5.4), Gitea: Recent Deliveries в настройках hook'а; (в) подпись → §13.1.
-
-**13.3. claude CLI не найден / не аутентифицирован (агент падает на старте).**
-
-```bash
-docker exec orchestrator /usr/bin/claude --version
-sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
-```
-
-Лечение: маунты указывают на фактические пути хоста (`ORCH_HOST_CLAUDE_CODE_DIR`,
-`ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON` в `.env`); креды
-читаемы uid'ом из §2.2 (`chown -R <uid>:<gid>`); при невалидной сессии — повторный логин
-на хосте (§7.2) + `docker compose up -d --force-recreate orchestrator`.
-
-**13.4. `docker.sock: permission denied` в логах орка/watchdog.**
-
-```bash
-getent group docker          # фактический gid
-grep ORCH_DOCKER_GID .env    # gid в конфиге
-```
-
-Лечение: значения обязаны совпадать → выставить `ORCH_DOCKER_GID` = фактическому gid и
-`docker compose up -d --force-recreate`.
-
-**13.5. `Permission denied` при создании worktree (права `/repos`, ORCH-040/057).**
-
-```bash
-stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR" "$ORCH_HOST_REPOS_DIR/<repo>"
-grep -E '^ORCH_RUN_(UID|GID)=' .env
-```
-
-Лечение: владелец каталога репо обязан совпадать с `ORCH_RUN_UID:ORCH_RUN_GID`
-(§2.2) → `chown -R <uid>:<gid> "$ORCH_HOST_REPOS_DIR"` (включая legacy root-owned файлы)
-и пересоздать контейнер.
-
-**13.6. Telegram молчит (нет карточек/алертов).**
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
-curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
-grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=.+' .env
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
-```
-
-Лечение: оба бота отвечают `"ok":true`; chat-id корректен (бот добавлен в чат / получил
-сообщение); ключи watchdog-бота лежат именно в `.env.watchdog` (в `.env` они инертны,
-§4.3); пустой токен = режим «логи без отправки» (fail-safe, не ошибка).
-
-**13.7. PR задачи не мержится / задача в HOLD.** Первая проверка — **не включена ли
-branch protection на `main`** (§6.4):
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-Лечение: непустой список правил на `main` → удалить (норматив §6.4); merge выполняет
-PR-merge API оркестратора, ручной merge не требуется.
-
---
-
-*Golden source Lite-тиража (ORCH-102, ADR-001). **Норматив сопровождения (NFR-5):**
-меняешь шаги тиража (env-ключи, compose-сервисы, маршрут онбординга, smoke) → обнови
-этот док В ТОМ ЖЕ PR (правило агентов №2). Полноту и гигиену дока держит структурный
-анти-дрейф тест `tests/test_lite_setup_doc.py`; кирпичи-каноны: REPLICATION.md (карта
-env §2, секреты §3, smoke §4), ONBOARDING.md (статусы §1, онбординг), SETUP_WEBHOOKS.md
-(формат вебхуков), `.env.example` / `.env.watchdog.example` (канон ключей).*
--- a/docs/epics/self-evolution.md
+++ b/docs/epics/self-evolution.md
@@ -1,316 +0,0 @@
-# 🧬 ЭПИК: Автономное саморазвитие платформы оркестратора
-
-> **Статус:** концепция v2 (структура согласована Славой 09.06 → ждёт финального апрува → декомпозиция)
-> **Автор:** Стрим · **Дата:** 2026-06-09 · **Заказчик:** Слава
-> **Связанные:** ORCH-8 (петля самообучения), ORCH-83 (наблюдаемость), ORCH-54 (автономное внедрение, done)
-> **Источники:** память орка (инциденты 06–09.06), инвентаризация 94 задач Plane, мировые практики (STRATUS NeurIPS'25, ChaosEater ASE'25, self-healing LLM-agents arXiv'26, agentic AIOps, FinOps token-economics).
-
---
-
-## 0. Зачем это (vision)
-
-Оркестратор уже **автономно внедряет** (ORCH-54: задача проходит analysis→prod без человека). Но автономность исполнения ≠ автономное **развитие**. Сегодня платформу развивает связка Слава+Стрим вручную: ловим инциденты → формулируем уроки → заводим задачи → апрувим.
-
-**Цель эпика:** управляемый самоподдерживающийся контур, где платформа сама замечает свои слабые места И возможности роста, предлагает улучшения как готовые задачи, проводит их через собственный конвейер (ORCH-7 self-hosting) — **под контролем человека на ключевых развилках** (safety > автономность).
-
-**Принцип баланса (коррекция Славы 09.06):** саморазвитие — это НЕ только «не падать и не косячить». Стабильная платформа, которая не растёт в возможностях, — тупик. **Рост функционала (новые фичи, стеки, удобства для заказчиков) — равноценный домен, а не следствие надёжности.** Платформа развивается по двум рукам одновременно: крепнет (надёжность/качество/экономика) И раздаётся вширь (возможности/масштаб).
-
---
-
-## 1. Архитектура эпика: фундамент + 5 доменов + 2 вертикали
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│  ВЕРТИКАЛЬ-ДВИГАТЕЛЬ 🧠        ВЕРТИКАЛЬ-ТОРМОЗ 🛑            │
-│  🔄 уроки (крепнем) +          governance / safety L0-L3      │
-│  💡 генератор идей (растём)    (ограничивает, апрувы)         │
-│ ░░░░░░░░░░░░ проходят СКВОЗЬ все домены ░░░░░░░░░░░░░░░░░░░░░ │
-├─────────────────────────────────────────────────────────────┤
-│         ДОМЕНЫ РАЗВИТИЯ (равноценные, две руки роста)         │
-│                                                               │
-│   КРЕПНЕТ ───────────────────►   РАЗДАЁТСЯ ВШИРЬ ────────►    │
-│   🛡️ D1 Надёжность              🚀 D4 Возможности (фичи)      │
-│   ✅ D2 Качество/Доверие         📈 D5 Масштаб                 │
-│   💰 D3 Экономика                                             │
-├─────────────────────────────────────────────────────────────┤
-│  ФУНДАМЕНТ (слой 0):  👁️ Наблюдаемость + 📒 Журнал уроков    │
-│  глаза и память — без них всё слепо                          │
-└─────────────────────────────────────────────────────────────┘
-       Общая метрика-объединитель: 🌡️ ГРАДУСНИК АВТОНОМНОСТИ
-       (каждый домен двигает её вверх контролируемо)
-```
-
-### Что изменилось против v1 (мои же правки по критике)
- **Наблюдаемость вынесена в фундамент** (была внутри M1) — она питает ВСЁ.
- **M0 разбит на 2 вертикали:** двигатель (петля) и тормоз (governance) — у них противоположная логика, нельзя в одну коробку.
- **Добавлен домен D2 Качество/Доверие** — была дыра: надёжная платформа может стабильно генерить говнокод. Надёжность инфры ≠ корректность результата.
- **Рост (D4+D5) — равноценные домены, не «второй эшелон»** (коррекция Славы).
- **Градусник автономности** — сквозная измеримая цель вместо абстракции.
-
---
-
-## 🏗️ АРХИТЕКТУРНЫЕ РАМКИ наблюдаемости (решено Славой 09.06 — constraints для архитектора)
-
-> Это НЕЗЫБЛЕМЫЕ границы (заказчик). Конкретные ADR (стек, формат метрик, точки врезки) — зона архитектора внутри этих рамок.
-
-**Принцип:** наблюдатель ОТДЕЛЁН от наблюдаемого. Мониторинг НЕ живёт внутри орка — иначе орк упал/завис/съел память → мониторинг ляжет вместе с ним, и мы слепы в самый критичный момент.
-
-**Решения Славы:**
- **С-1. Sidecar-контейнер на том же хосте** (вариант A). Отдельный процесс/память/рестарт — орк падает, наблюдатель жив и РЕПОРТИТ это.
- **С-1б. КОД sidecar — В РЕПО орка** (отдельная папка `watchdog/`), рантайм — ОТДЕЛЬНЫЙ контейнер. Изоляция — на уровне КОНТЕЙНЕРА, не репозитория. Плюсы: (1) конвейер орка пилит свой мониторинг сам (self-hosting ORCH-7); (2) контракт `/metrics`↔sidecar в одном репо — не разъедется (один PR/тесты); (3) один CI. Сборка: ОТДЕЛЬНЫЙ `watchdog/Dockerfile` + сервис `orchestrator-watchdog` в docker-compose.yml. Разовое инфра-действие: добавить сервис в compose + первый запуск (Слава/Стрим на хосте), дальше код watchdog катится через конвейер.
- **С-2. Без внешнего плеча (L2).** Не усложняем второй площадкой. (Принятый риск: падёнвесь хост/Docker → наблюдатель тоже молчит; осознанно.)
- **С-3. Тонкий стек.** НЕ Grafana+Prometheus (+5-6 контейнеров на забитый хост). Тонкий Python/Go sidecar. **Факт хоста 09.06: RAM 171Mi free / 7.7Gi, диск 92%** — ресурсы впритык, наблюдатель обязан быть лёгким.
-
-**Разделение ответственности:**
- **Орк отдаёт только сырьё:** лёгкий read-only `/metrics` (свои внутренние данные — стадии/очередь/agent-liveness/cost, что знает только он). БЕЗ логики мониторинга/алертов/хранения. Орк лёг → endpoint недоступен = САМ сигнал тревоги.
- **Sidecar — мозг мониторинга:** читает `/metrics` орка + хост (диск/память/CPU) + контейнеры (docker.sock read-only) + пинг Plane/Gitea/Anthropic; хранит пороги, шлёт Telegram-алерты СО СВОИМ каналом (не зависит от кода орка).
- **Журнал уроков (F2)** — исключение: это НЕ realtime-мониторинг, а историческая память петли → допустимо в БД орка (аддитивная таблица). Не критично к падению орка в момент (запись best-effort).
-
---
-
-## 2. ФУНДАМЕНТ (слой 0) — 👁️ Глаза и 📒 Память
-
-Без данных нечем ни чинить, ни считать, ни приоритизировать, ни учиться. Строится первым.
-
- **F1 Наблюдаемость** (ORCH-83 [ЭПИК]): метрики agent-liveness + очередь + стадии + хост (диск/память/CPU) + контейнеры + внешние деп (Plane/Gitea/Anthropic). Эндпоинты /health /status /queue → расширить до /metrics + дашборд.
- **F2 Журнал уроков** (ORCH-8 шаг 1): машинная структурированная таблица отклонений (тип, контекст, корень, предложение, статус) — формализовать то, что сейчас в memory/. Это «топливо» для вертикали-двигателя.
-
-### 🎯 СКОП НАБЛЮДЕНИЯ — три слоя (решено Славой 10.06)
-
-> Граница «мониторим ПЛАТФОРМУ vs ПРОДУКТЫ на ней». Важно для архитектора и будущих задач — не путать уровни.
-
- **Слой 1 — проекты как ЗАДАЧИ в конвейере — ✅ В СКОПЕ (F1a/F1b).** ET-задачи в stages/queue/agents `/metrics` — это работа орка (его агенты/очередь/стадии). Sidecar алертит «ET-задача застряла». Здоровье КОНВЕЙЕРА.
- **Слой 2 — проекты как КОНТЕЙНЕРЫ на хосте — ✅ В СКОПЕ (F1b, жив/мёртв).** `enduro-trails-app-1`, `osrm` и пр. через docker.sock ro — Up/healthy/restarting/exited. Общий хост впритык → текущий ET-контейнер вредит орку. Здоровье контейнера как чёрного ящика.
- **Слой 3 — ВНУТРЕННЕЕ бизнес-здоровье продукта — ❌ НЕ В ФУНДАМЕНТЕ, НО НУЖНО (см. ниже).** Эндпоинты ET отвечают 200? карта рендерится? latency не деградировала после фичи? Орк не знает внутренностей задеплоенных приложений — это МОНИТОРИНГ ПРОДУКТА, не платформы.
-
-**Слой 3 — это отдельная продуктовая способность (домен D4/D5):** «per-project мониторинг здоровья задеплоенного приложения» — опция для заказчика («слежу, что твой ET-сайт жив»). **НО он НУЖЕН и самой петле** (см. §8A «атрибуция уроков») — без детекции деградации продукта петле нечего ловить. Порядок: фундамент (слои 1-2) сначала, слой 3 — позже как D4/D5-фича.
-
---
-
-## 3. ДОМЕН D1 — 🛡️ Надёжность (Self-Repairing)
-
-**Есть:** reconciler (53), post-deploy monitor+rollback (21), merge-verify (71/73), reaper (65), disk-watchdog (63), build-prune (62).
-**Уроки:** фантом-merge, deploy-петли, транзиенты, флапп-статусы, зомби-jobs.
-
- **D1.1** Предиктивный мониторинг (causal, не порог): «диск заполнится через N ч».
- **D1.2** Авто-ремедиация рантайма: каталог типовых фиксов (зомби-job→requeue, stale-lease→reclaim, флапп→форс-терминал).
- **D1.3** Транзиент-резилентность everywhere (обобщение ORCH-93): единый retry+backoff для всех внешних вызовов.
- **D1.4** Zero-downtime деплой платформы (blue-green/canary): резервное плечо вместо окна недоступности.
- **D1.5** Авто-rollback по SLO (расширение 21): откат по деградации latency/error-rate, не только health.
- **D1.6** Deep agent-liveness (self-healing LLM): «думает / завис / зациклился» по reasoning+CPU+прогрессу.
- **D1.7** Backup/restore БД+worktree (recovery после краша хоста).
-
---
-
-## 4. ДОМЕН D2 — ✅ Качество / Доверие результата
-
-> Новый домен. Закрывает дыру: платформа может надёжно и дёшево производить плохой результат. Надёжность инфры ≠ корректность кода/аналитики.
-
-**Есть:** security-гейт (22), reviewer/tester стадии, промпт-аудит (92).
-
- **D2.1** Code-coverage гейт (ORCH-27): защита от деградации покрытия.
- **D2.2** Регресс-страж результата: не только «тесты зелёные», но «не сломали соседнюю фичу» (расширение regression-guard ORCH-73).
- **D2.3** Качество аналитики: метрика «BRD не пришлось переделывать», сверка факт vs ТЗ (как сегодня ловила ложное P0).
- **D2.4** Доверие к выходу: provenance артефактов, воспроизводимость, «деплой OK = прод реально работает» (урок ET-8).
- **D2.5** Опциональная человеческая приёмка важных фич (ORCH-28).
- **D2.6** Само-оценка агентов: уверенность в результате → эскалация при низкой.
-
---
-
-## 5. ДОМЕН D3 — 💰 Экономика
-
-**Боль (ORCH-38):** developer сжёг **$13.68 на мелочь** (cache_read 18.98M — слепое сканирование src/).
-
- **D3.1** Model-routing cascade (мир: −87%): классификатор сложности → дешёвая модель на простое, opus на сложное (ORCH-20+13).
- **D3.2** Бюджет circuit-breaker (ORCH-23): хард-лимит $/токенов/времени → пауза+алерт.
- **D3.3** Оценка задачи ДО старта (ORCH-20): прогноз $/время по истории.
- **D3.4** Целевые файлы в задании (ORCH-38): analyst даёт точный список из TRZ → нет слепого сканирования. **Самый дешёвый высокий impact.**
- **D3.5** Fast-track простых задач (ORCH-19): багфикс → урезанный цикл без architect, дешёвая модель.
- **D3.6** Semantic caching / prompt compression (мир: −31%).
- **D3.7** Cost-дашборд + детект аномалий.
-
---
-
-## 6. ДОМЕН D4 — 🚀 Возможности (рост функционала)
-
-> **Равноценный домен (акцент Славы).** Это то, ради чего платформой ПОЛЬЗУЮТСЯ. Без новых возможностей надёжность бессмысленна — нечего надёжно делать. Развивается параллельно с D1-D3, а не после.
-
-**Backlog-зародыши:** ORCH-12/13/14/15/18/24/25.
-
- **D4.1** Стеки-плагины: профили стека (web/mobile/data/ML/embedded) → агенты адаптируют процесс. Расширяемо без правки ядра. **Открывает заказчикам новые типы проектов.**
- **D4.2** Android/мобильный стек (ORCH-15): полноценная разработка приложений.
- **D4.3** UX/UI-дизайнер (ORCH-14): дизайнер-агент генерит макеты на аналитике, согласование с BRD.
- **D4.4** Интерактивный аналитик (ORCH-18): живой диалог Слава↔analyst — уточнение BRD, обсуждение вариантов до старта. Удобство + качество постановки.
- **D4.5** Тяжёлые вычисления (ORCH-12): воркер/стадия для долгих расчётов (ML-обучение, миграции данных).
- **D4.6** База знаний проекта (ORCH-24): RAG-контекст решений/архитектуры — агенты умнее (+экономия).
- **D4.7** Декомпозиция эпиков (ORCH-25): эпик→задачи→сборка автоматически (этот документ — кандидат №1).
- **D4.8** Новые роли-агенты: data-engineer, ML-инженер, DevOps — по мере типов проектов.
- **D4.9** Мультипровайдерность моделей (ORCH-13): не только Claude — выбор под задачу/стек/бюджет.
-
---
-
-## 7. ДОМЕН D5 — 📈 Масштаб
-
-> Вторая «рука роста»: способность делать БОЛЬШЕ и ШИРЕ. Сейчас потолок — `max_concurrency=1`.
-
-**Backlog-зародыши:** ORCH-9/10; done: ORCH-6 (multi-repo), ORCH-88 (serial-batch).
-
- **D5.1** Параллельная разработка (снять max_concurrency=1): безопасный N>1 (изоляция worktree есть, нужна merge-orchestration FIFO + защита main). **Много фич параллельно = быстрее растём.**
- **D5.2** Turnkey-онбординг проекта (ORCH-9): команда → Plane+Gitea+агенты+инфра за минуты.
- **D5.3** Тиражирование на новый хост (ORCH-10): перенос платформы на инфру нового заказчика (IaC-bundle).
- **D5.4** Горизонтальный воркер-пул: очередь jobs (ORCH-1) → несколько воркеров/хостов.
- **D5.5** Per-project лимиты ресурсов (concurrency/бюджет на проект).
- **D5.6** Мультитенантность (отложено — SaaS-сценарий, по спросу).
-
---
-
-## 8. ВЕРТИКАЛЬ-ДВИГАТЕЛЬ 🧠 — две турбины: реактивная + проактивная
-
-> Двигатель питается из ДВУХ источников (коррекция Славы 09.06). Реактивная турбина (уроки из боли) кормит «крепнем» (D1-D3). Проактивная (генератор идей) кормит «растём» (D4-D5). Без второй турбины рост фич зависит только от Славы — бутылочное горлышко.
-
-### 8A. Реактивная турбина 🔄 — петля самообучения из уроков (ORCH-8)
-```
-ДЕТЕКЦИЯ → ЖУРНАЛ урока → АНАЛИЗ/паттерны → ПРЕДЛОЖЕНИЕ задачи → [governance-гейт] → конвейер ORCH-7 → проверка эффекта → журнал
-```
- **Детекция:** провал гейта, **ручное вмешательство (самый ценный сигнал — каждый ручной пинок = дыра автономности)**, ретраи/откаты/таймауты, ложные срабатывания, «деплой OK / прод сломан».
- **Анализ (гибрид):** машина копит и предлагает черновик → Стрим фильтрует/оформляет → Слава апрувит.
- **E1** Журнал уроков (=F2). **E2** Агент-ретроспективщик (анализ→предложение).
-
-#### ⚖️ АТРИБУЦИЯ урока — platform-level vs project-level (решено Славой 10.06)
-
-> Ключевой шаг петли. Пример Славы: выпустили фичу в ET → она деградировала ET. Петля поймала сигнал — но ЧЬЯ вина и ГДЕ чинить?
-
-Когда детектирована деградация продукта после выпуска фичи, петля ДОЛЖНА различить два уровня вины и направить урок в правильное русло:
-
- **А. Platform-level (недоработал ОРК):** конвейер выпустил деградацию, потому что у платформы СЛАБЫЙ ПРОЦЕСС (нет регресс-гейта «фича не ломает соседнее», тест-стадия не ловит деградацию производительности, нет производительностного бенчмарка в приёмке). → улучшаем ПРОЦЕСС орка (домен **D2 Качество** / **D1 Надёжность**). Чинится ОДИН раз — выигрывают ВСЕ проекты.
- **Б. Project-level (недоработал ПРОЕКТ):** процесс орка нормальный, но в конкретном ET МАЛО тестов/слабая приёмка под этот тип фич. → усиливаем ТЕСТЫ/приёмку В САМОМ ET (задача в бэклог ET). Чинится точечно — выигрывает только ET.
-
-**Механизм (новый шаг петли):**
-```
-ДЕТЕКЦИЯ деградации продукта (слой 3) → урок →
-   АТРИБУЦИЯ: platform-level или project-level?
-   ├─ platform → задача в D1/D2 (улучшить процесс — польза всем)
-   └─ project  → задача в бэклог ET (усилить тесты ET — польза ET)
-   (развилка не всегда бинарна — бывает ОБА: и гейт в орк, и тесты в ET)
-```
-Без атрибуции петля «чинит платформу» там, где надо усилить проект (и наоборот). **Зависит от слоя-3 детекции** (§2): без мониторинга здоровья продукта петле нечего атрибутировать. **E2-ретроспективщик** несёт эту классификацию; спорные случаи → Стрим/Слава решают.
-
-### 8B. Проактивная турбина 💡 — генератор идей новых возможностей (НОВОЕ — запрос Славы)
-
-> Отдельный источник идей роста функционала — НЕ только требования от Славы. Проактивно предлагает новые фичи/возможности/удобства. Та же воронка: машина/агент генерит черновики → Стрим фильтрует → Слава решает.
-
-**Источники идей (вход генератора):**
- **I1 Гэпы реализации:** чего НЕ хватило для запрошенных проектов (enduro-trails, snowbike — что было тяжело/невозможно сделать платформой → кандидат в фичу).
- **I2 Паттерны ручного труда:** что Слава/заказчики часто делают руками ВНЕ платформы → кандидат на автоматизацию/фичу.
- **I3 Тренды и новые технологии:** сканирование новых моделей/стеков/инструментов (web-поиск, release-notes провайдеров) → «вышла модель X / фреймворк Y — даёт новую возможность».
- **I4 Конкурентный/рыночный анализ:** что умеют другие AI-платформы разработки (Devin, Cursor, Copilot Workspace…) → чего нет у нас.
- **I5 Анализ собственного бэклога/истории:** паттерны типов задач → «часто просят X → стоит сделать шаблон/фичу».
- **I6 Обратная связь заказчиков:** явные пожелания/жалобы по реализованным проектам.
- **I7 Саморефлексия Стрим:** я вижу работу платформы изнутри каждый день — предлагаю удобства/фичи из опыта ведения.
-
-**Компоненты:**
- **E4 Агент-идеатор (product-discovery):** по расписанию сканирует I1-I7 → генерит бэклог идей-черновиков фич (с обоснованием «зачем/кому/из какого источника»).
- **E5 Банк идей:** отдельный реестр (не путать с журналом уроков): идея, источник, предполагаемая ценность, статус (new/отклонена/в работе).
-
-### 8C. Общий выход двигателя
- **E3 Приоритизатор RICE:** сводит ОБА потока (уроки из 8A + идеи из 8B) в единый ранжированный бэклог по impact/cost/risk — что брать первым по всем доменам. Баланс «крепнем vs растём» — настраиваемый (квота слотов на надёжность vs фичи).
-
---
-
-## 9. ВЕРТИКАЛЬ-ТОРМОЗ 🛑 — Governance / Safety
-
-> «Контроль и управление саморазвитием» (требование Славы). Двигатель жмёт газ — этот контур держит руль и тормоз.
-
-**Принцип (ORCH-8, незыблемо):** самомодификация платформы (промпты/скиллы/конфиги агентов/ядро) — ТОЛЬКО через PR+ревью+апрув Славы. Орк ПРЕДЛАГАЕТ, ПРИМЕНЯЕТ через свой конвейер с гейтами.
-
-**Уровни автономии (agentic AIOps maturity):**
-| Уровень | Что авто | Гейт |
-|---------|----------|------|
-| L0 reactive | только алерт | человек делает всё |
-| L1 assistive | предложить задачу+ТЗ | человек апрувит запуск |
-| L2 autonomous-bounded | гонит безопасные классы (бэкенд-фиксы) до прода | safety-гейты CI/staging/regression |
-| L3 self-modifying | менять агентов/ядро | **всегда** PR+апрув Славы, НИКОГДА не авто |
-
- **G1** Safety-политика L0-L3 + per-class правила (что можно само, что только через Славу). Лейблы autoApprove/autoDeploy (ORCH-89) = уже зародыш.
- **G2** Бюджет на саморазвитие: лимит $/мес, чтобы контур не жёг бесконтрольно.
- **G3** Дашборд эволюции: метрики 5 доменов в динамике — видно, КУДА развивается платформа.
- **G4** Kill-switch петли: остановить самогенерацию задач одним флагом.
-
---
-
-## 10. 🌡️ Градусник автономности (сквозная метрика)
-
-Объединяющая измеримая цель эпика. Каждый домен двигает её вверх:
- **% задач без ручного пинка** (сегодня было ~5 вмешательств: апрувы, домерж 063, sync 061).
- **Ручных вмешательств / неделю** (тренд вниз).
- **MTBF / MTTR** платформы (D1).
- **$/задача, токены/задача, время/задача** (D3).
- **Типов проектов/стеков поддержано** (D4).
- **Задач параллельно** (D5).
- **% уроков, ставших задачами** (двигатель).
-
---
-
-## 11. Связь с Backlog (ничего не теряем)
-
-| Backlog | Домен/вертикаль |
-|---------|-----------------|
-| ORCH-8 петля | 🧠 Двигатель (ядро) |
-| ORCH-83 наблюдаемость | Фундамент F1 |
-| ORCH-20/23/38/19 | 💰 D3 |
-| ORCH-27/28 | ✅ D2 |
-| ORCH-12/13/14/15/18/24/25 | 🚀 D4 |
-| ORCH-9/10 | 📈 D5 |
-| ORCH-94 флапп | 🛡️ D1.2 |
-| ORCH-89 авто-лейблы | 🛑 G1 |
-
-~18 backlog-задач ложатся в структуру. Эпик их систематизирует и достраивает.
-
---
-
-## 12. Дорожная карта (предложение)
-
-1. **Фаза 0 (фундамент):** F1 наблюдаемость + F2 журнал. Без них рулить нечем.
-2. **Фаза 1 (две руки параллельно):**
-   - крепнем: D3.4 целевые файлы + D3.2 бюджет-breaker (дешёвый impact)
-   - растём: D4.1 стеки-плагины ИЛИ D4.4 интерактив-аналитик (по спросу)
-3. **Фаза 2:** D1 надёжность (транзиент-резилентность, авто-ремедиация) + D2 качество + D5.1 параллелизм.
-4. **Фаза 3 (мозг):** E2 ретроспективщик + E3 приоритизатор + G1 safety-политика → петля замыкается, дальше платформа предлагает сама.
-
---
-
-## ⛓️ Реализация в Plane (решено 09.06)
-
-**Ось ДОМЕНА → модули Plane** (1 задача = 1 модуль; slug в `external_id`, name с эмодзи для человека):
-
-| Модуль (name) | slug (external_id) | module_id |
-|---|---|---|
-| 👁️ Фундамент | `foundation` | 74dee25a-a44b-4c3b-ab55-1b5638b8cc1f |
-| 🧠 Мозг | `brain` | ab1afa08-14ce-4b7d-8ebc-e45ac19b2ba7 |
-| 🛡️ Надёжность | `reliability` | abd7479e-4f9b-4a56-a926-cb2ece7558ca |
-| ✅ Качество | `quality` | cbf5f8ca-dc1a-4dee-9d35-555459de2b30 |
-| 💰 Экономика | `economy` | 9b4bbab3-95d6-4b8a-8d72-379a618ea2f3 |
-| 🚀 Возможности | `features` | baa6936c-6a39-4935-ad57-31ef5ffc3041 |
-| 📈 Масштаб | `scale` | 18373528-14fa-4627-a0f6-32497ff22177 |
-
-**Ось ВЕРТИКАЛЬ → лейблы** (могут быть несколько, список короткий):
- `engine` (36f398f7-5a1c-4eeb-847a-56c457e1da6b) — задача пришла от петли/идеатора.
- `governance` (9eea4dd8-0fe7-473a-8c40-630fc3ab0d25) — требует апрува L3 / safety-внимания.
- (+ существующие `autoApprove`/`autoDeploy` — ортогональны, режим автономности.)
-
-**Правило раскладки:** каждая задача эпика = 1 модуль-домен (по slug) + 0..N вертикаль-лейблов. Орк ищет/привязывает по `external_id` (не по русскому имени).
-
-⚠️ **Порядок модулей на доске:** Plane API игнорирует `sort_order` на запись (только drag-and-drop в UI). Сейчас порядок перевёрнут (Масштаб сверху) — Славе поправить мышкой (фундамент→мозг→надёжность→качество→экономика→возможности→масштаб). На машинную логику не влияет (орк по slug).
-
---
-
-## 13. Открытые вопросы Славе
-
-1. **Структура Plane:** мега-эпик с фундаментом+5 доменами+2 вертикалями? Или эпик на каждый домен?
-2. **D4 (возможности):** какой стек/фича приоритетны для тебя/заказчиков — Android, UX/UI, тяжёлые расчёты, интерактив-аналитик? С чего рост начинать?
-3. **Баланс «крепнем vs растём»:** идти строго параллельно обеими руками, или в каждой фазе перевес в одну сторону?
-4. **Safety L3:** подтверждаешь — самомодификация ядра/агентов всегда через твой апрув?
-5. **Двигатель (E2/E4):** ретроспективщик + агент-идеатор сразу как агенты, или сначала Стрим ведёт журнал/банк идей вручную?
-8. **Генератор идей (8B):** какие из источников I1-I7 тебе ценнее (гэпы проектов / тренды-технологии / конкуренты / саморефлексия Стрим)? Генерить автономно или только по твоему запросу?
-6. **Бюджет на эпик (G2):** лимит $/мес?
-7. **Первая задача** после апрува: F1 наблюдаемость, быстрая победа D3.4, или сразу рост D4.*?
--- a/docs/operations/INFRA.md
+++ b/docs/operations/INFRA.md
@@ -47,35 +47,8 @@ ADR `docs/work-items/ORCH-040/06-adr/ADR-001-run-agents-as-host-uid.md` и гл
 - **P-3:** `id slin` → `1000:1000`; `/repos`, `/app/data` уже `1000:1000`.
 - **P-4:** прод-рестарт self — только в окно тишины (`GET /status` без активных задач):
  общий инстанс с enduro-trails.
- **P-5 (блокер миграции uid, ORCH-057):** нормализация **всех** legacy `root:root` файлов в `/repos`
-  — см. подраздел «Миграция uid: обязательная нормализация legacy root-файлов» ниже. Без неё первый
-  job падает на launch при создании worktree (инцидент 06.06, ORCH-043).
-
-### Миграция uid: обязательная нормализация legacy root-файлов (ORCH-057)
-ORCH-040 сменил `user:` контейнера, но **не** владельца уже существующих файлов в bind-mount `/repos`,
-созданных прежним root-контейнером. Под uid 1000 `src/git_worktree.py::ensure_worktree` не может
-создать worktree рядом с `root:root` каталогом `/repos/_wt/` → `fatal: could not create leading
-directories … Permission denied` (агент даже не стартует). С ORCH-057 эта ошибка распознаётся и
-выдаётся **внятно** (с лечащей командой) + детектится на старте сервиса (WARNING/Telegram, блок
-`fs_ownership` в `GET /queue`), но **фактический `chown` обязан выполнить оператор под root на хосте**
-(контейнер бежит без root и chown'ить чужие файлы не может).
-
-**Обязательный разовый шаг при миграции uid / на новой среде (под root на mva154, ПЕРЕД стартом app):**
-```bash
-# 1) worktree-корень (все ветки всех проектов режутся здесь)
-sudo chown -R 1000:1000 /home/slin/repos/_wt
-# 2) .git обоих репо (objects / worktrees-административные записи)
-sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git \
-                        /home/slin/repos/enduro-trails/.git
-# 3) корень orchestrator целиком (включая data/runs/*.log — 37 root-логов в инциденте)
-sudo chown -R 1000:1000 /home/slin/repos/orchestrator
-# Проверка (пусто = ок):
-find /home/slin/repos/_wt ! -uid 1000 -print -quit
-```
-Процедура **идемпотентна** (повтор на корректной среде — no-op) и входит в **чеклист деплоя/миграции
-self**. Область охвата: `_wt`, оба `.git` (`objects`+`worktrees`), `data/runs`. См.
-`docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md` и сквозной
-`docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`.
+- Разовый разгребающий `chown -R 1000:1000 /home/slin/repos/orchestrator` для старых
+  `root:root` файлов из истории (вне объёма кода).

 ### Тома (volumes)
 - `./data` → `/app/data` (БД; у staging — `./data/staging`)
@@ -85,47 +58,6 @@ self**. Область охвата: `_wt`, оба `.git` (`objects`+`worktrees`
 - `~/.orchestrator-ssh` → `/home/slin/.ssh` (ro, деплой по ssh; target в HOME агента,
  согласован с `HOME=/home/slin` из launcher — ORCH-040, ранее `/root/.ssh`)

-### Disk-watchdog: мониторинг заполнения диска mva154 (ORCH-063)
-07.06.2026 диск хоста mva154 тихо дорос до 100% и положил **весь конвейер всех проектов**
-(один прод-инстанс `orchestrator` на общей БД/очереди). Чтобы такой инцидент сигнализировался
-**заранее**, работает фоновый daemon-поток `src/disk_watchdog.py` (каркас `reconciler`/`job_reaper`):
- **Что мониторится:** заполнение **хост-разделов** по смонтированным bind-путям (`/repos` →
-  host `/home/slin/repos`, `/app/data` → host `./data`) через stdlib `shutil.disk_usage` — НЕ
-  overlay `/` контейнера (иначе замер ложно-низкий). Пути с одним физическим устройством (`st_dev`)
-  дедуплицируются → один алерт, не два.
- **Порог и период:** при заполнении **≥ 85%** (`ORCH_DISK_MONITOR_THRESHOLD_PCT`) шлётся
-  Telegram-алерт оператору; замер — раз в 300с (`ORCH_DISK_MONITOR_INTERVAL_S`). Пока диск выше
-  порога, повтор — не чаще раза в ~6ч (`ORCH_DISK_MONITOR_REALERT_S`, анти-спам). При возврате
-  ниже порога — однократное recovery-сообщение.
- **Как отключить:** `ORCH_DISK_MONITOR_ENABLED=false` (демон не стартует; `GET /queue` →
-  `disk_monitor.enabled=false`; поведение 1:1 как сейчас). Наблюдаемость — блок `disk_monitor` в
-  `GET /queue` (последний замер: `used_pct`/`free_gb`/`alerting`/`last_alert_at` по каждому пути).
- **Что делать при алерте:** watchdog **только сигнализирует** — он не трогает диск/контейнер и не
-  рестартит прод (self-hosting безопасность). Освобождение **docker build cache** автоматизировано
-  отдельным демоном (ORCH-062, см. ниже); прочие «пожиратели» — старые worktree-каталоги
-  `/home/slin/repos/_wt/*` завершённых задач, логи, dangling-образы (`docker image prune`) —
-  по-прежнему **ручная** операция оператора (авто-уборка этих категорий — вне объёма ORCH-062/063).
-
-### Build-cache-pruner: авто-prune docker build cache на mva154 (ORCH-062)
-Доминирующий «пожиратель» в инциденте 07.06.2026 — **docker build cache** (≈11 ГБ от частых
-пересборок прод/staging-образов). Чтобы он не мог снова заполнить диск **без оператора**, работает
-фоновый daemon-поток `src/build_cache_pruner.py` (каркас `disk_watchdog`) — «вторая половина»
-watchdog'а: **watchdog сигналит, pruner убирает**.
- **Что делает:** каждые `ORCH_BUILD_CACHE_PRUNE_INTERVAL_S` (дефолт 21600с = 6ч) выполняет
-  **строго `docker builder prune -f --filter until=<until>`** (BuildKit GC; дефолт `until=24h` —
-  удаляется build cache старше суток, тёплый свежий кэш сохраняется). Команда затрагивает **только
-  build cache** — НЕ образы/контейнеры запущенных сервисов; рестарт docker daemon/прода НЕ
-  выполняется (self-hosting безопасность).
- **Как исполняется:** в контейнере нет `docker` CLI (образ несёт только `openssh-client git`),
-  поэтому уборка идёт **на хосте через ssh** тем же каналом `ORCH_DEPLOY_SSH_USER@_HOST`, что
-  деплой/`image_freshness`. **Пустой `ORCH_DEPLOY_SSH_HOST` → тик no-op** (фича активна только на
-  self-host, где ssh настроен).
- **Как отключить:** `ORCH_BUILD_CACHE_PRUNE_ENABLED=false` (демон не стартует; поведение 1:1 как
-  до ORCH-062). Наблюдаемость — блок `build_cache_prune` в `GET /queue` (`enabled`/`interval_s`/
-  `until`/`last_run_ts`/`last_reclaimed`/`last_error`); never-raise; in-memory учёт (без миграции).
- **Ручной fallback** (если ssh-канал недоступен) — host-cron на mva154:
-  `0 */6 * * * docker builder prune -f --filter until=24h` (off-git, процедура Owner).
-
 ## Переменные окружения (карта; значения — в `.env`)

 | Переменная | Назначение |
@@ -159,27 +91,9 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `ORCH_RECONCILE_GRACE_DEFAULT_S` | порог «застряла» по `tasks.updated_at`, сек; дефолт `600` |
 | `ORCH_RECONCILE_GRACE_OVERRIDES_JSON` | per-stage пороги, напр. `{"development":300}`; невалидный JSON → дефолт |
 | `ORCH_RECONCILE_NOTIFY_UNBLOCK` | слать Telegram при разблокировке застрявшей задачи; дефолт `true` |
-| `ORCH_DISK_MONITOR_ENABLED` | kill-switch disk-watchdog (ORCH-063); дефолт `true`. `false` → демон не стартует, поведение 1:1 как сейчас |
-| `ORCH_DISK_MONITOR_INTERVAL_S` | период heartbeat-замера заполнения диска, сек; дефолт `300` |
-| `ORCH_DISK_MONITOR_THRESHOLD_PCT` | порог заполнения для алерта, %; дефолт `85` (валидация 1..100, иначе → дефолт) |
-| `ORCH_DISK_MONITOR_REALERT_S` | cooldown повторного алерта, пока выше порога, сек; дефолт `21600` (~6 ч) |
-| `ORCH_DISK_MONITOR_PATHS` | CSV отслеживаемых **хост**-bind-путей; пусто → `/repos,/app/data` |
-| `ORCH_BUILD_CACHE_PRUNE_ENABLED` | kill-switch build-cache-pruner (ORCH-062); дефолт `true`. `false` → демон не стартует, поведение 1:1 как до задачи |
-| `ORCH_BUILD_CACHE_PRUNE_INTERVAL_S` | период тика авто-prune, сек; дефолт `21600` (~6 ч); валидация >0, иначе → дефолт |
-| `ORCH_BUILD_CACHE_PRUNE_UNTIL` | возраст удержания тёплого кэша (`docker builder prune --filter until=`); дефолт `24h`; валидация `^\d+[smhdw]?$`, иначе → `24h` |
-| `ORCH_BUILD_CACHE_PRUNE_ALL` | добавить `-a` к prune (только в паре с `until`); дефолт `false` |
-| `ORCH_BUILD_CACHE_PRUNE_TIMEOUT_S` | таймаут ssh-команды prune, сек; дефолт `120` |
-| `ORCH_BUILD_CACHE_PRUNE_NOTIFY_MIN_GB` | Telegram при освобождении ≥ N ГБ; дефолт `0` (тихо) |
 | `DEPLOY_SSH_USER` / `_HOST` / `DEPLOY_HOOK_SCRIPT` | параметры деплой-хука |
-| `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME всех акторских subprocess-env (агенты/finalizer/monitor) **и** таргет маунтов `.claude`/`.claude.json`/`.ssh` **и** `ARG APP_HOME` Dockerfile (группа ORCH-040 двигается согласованно); дефолт `/home/slin` |
-| `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot` @ `mva154.local`); системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом |
-| `ORCH_STAGING_PORT` | ORCH-101: порт staging-инстанса (дефолт `8501`); читается и `image_freshness`, и compose `command:` staging; guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) |
-| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` | ORCH-101: host-источники bind-маунтов `~/.claude`, `~/.claude.json`, ssh-ключей (`/home/slin/.{claude,claude.json,orchestrator-ssh}`) |
-| `ORCH_HOST_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-пути дистрибутива claude-code и бинаря node (`/usr/lib/node_modules/@anthropic-ai/claude-code`, `/usr/bin/node`) |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` | ORCH-101: uid:gid контейнера (`user:`) + `ARG APP_UID/APP_GID` (дефолт `1000:1000`, ORCH-040) |
-| `ORCH_DOCKER_GID` | ORCH-101: gid docker-группы хоста для `group_add` (дефолт `999`; «МИНА 1» ORCH-040 — не удалять) |

-**Секреты — только в `.env` / `.env.staging` / `.env.watchdog` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`, `.env.watchdog.example` (ORCH-102: sidecar-watchdog читает ТОЛЬКО `.env.watchdog`; `WATCHDOG_*` в `.env` для него инертен). Выпуск нового комплекта секретов для нового хоста — `scripts/gen_secrets.py` (боевые секреты не копируются). **Тираж платформы на новую инфру** (карта переменных, секреты, smoke-процедура, границы Lite/Bundled) — `docs/operations/REPLICATION.md` (ORCH-101); сквозная инструкция Lite-тиража для внешнего оператора («голый хост → конвейер», орк+watchdog) — `docs/deployment/LITE_SETUP.md` (ORCH-102). Когерентность портов при смене прод-порта: `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`.
+**Секреты — только в `.env` / `.env.staging` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`.

 ## Реестр проектов (`src/projects.py`, ORCH-6)
 Связывает Plane project id → gitea repo + work-item prefix. Источник: `ORCH_PROJECTS_JSON`, fallback — встроенный дефолт. Прод видит: `enduro-trails` (ET), `orchestrator` (ORCH). Staging видит ТОЛЬКО `orchestrator-sandbox` (SANDBOX) — изоляция.
--- a/docs/operations/ONBOARDING.md
+++ b/docs/operations/ONBOARDING.md
@@ -1,200 +0,0 @@
-# ONBOARDING — turnkey-онбординг нового проекта (ORCH-009)
-
-> RUNBOOK. Полный чеклист подключения нового проекта к оркестратору одним проходом.
-> Исполнитель — оператор; инструмент — CLI `scripts/onboard_project.py`
-> (режимы `plan` — дефолт/dry-run, `apply`, `verify`). Каждый шаг, который CLI выполнить
-> не может, помечен **🖐 РУЧНОЙ ШАГ** и снабжён командой проверки результата.
-> Архитектура решения — см. «Ссылки» внизу.
-
-Запуск CLI — из корня чекаута репо orchestrator, в venv с `requirements.txt`:
-
-```bash
-python3 scripts/onboard_project.py plan \
-  --name "My Project" --description "зачем проект" \
-  --repo my-project --prefix MP \
-  --stack "Python 3.12 + FastAPI" --test-cmd "pytest tests/ -q" \
-  --prod-port 8600 --staging-port 8601 \
-  --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
-```
-
-`plan` печатает полный план **без единой мутации** (ни сети-POST, ни записи на диск);
-`apply` — идемпотентный ensure (существующее → `skipped(exists)`, ничего не удаляется);
-exit-коды: `0` — чисто, `2` — есть `manual-step`/gap, `1` — ошибка.
-
---
-
-## 0. Предусловия
-
-Все значения — в `.env` на хосте (секреты в гит не попадают):
-
-| Переменная | Зачем | Проверка |
-|-----------|-------|----------|
-| `ORCH_PLANE_API_TOKEN` (+`ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение проекта, статусов, лейблов | `curl -s -H "X-API-Key: $TOKEN" $URL/api/v1/workspaces/$SLUG/projects/ \| head -c 200` |
-| `ORCH_GITEA_TOKEN` (+`ORCH_GITEA_URL`) | создание репо + webhook | `curl -s -H "Authorization: token $TOKEN" $URL/api/v1/user \| head -c 200` |
-| `ORCH_GITEA_WEBHOOK_SECRET` | HMAC webhook (переиспользуется, один на все репо) | есть строка в `.env`; нет → `apply` сгенерирует и выведет |
-| `ORCH_PROJECTS_JSON` | текущий реестр — источник merged-вывода | `grep ORCH_PROJECTS_JSON .env` |
-
-Токен Plane должен иметь право создавать проекты в workspace; токен Gitea — создавать репо и
-hooks под выбранным owner (`--gitea-owner`, дефолт из конфига).
-
---
-
-## 1. Слой Plane: проект + статусы + лейблы
-
-Выполняет `apply` (или вручную при недоступности API CE — каждый отказ CLI помечает
-`manual-step`, не падает).
-
-1. **Проект**: создаётся с `identifier = --prefix`. Уже существует → передай
-   `--plane-project-id <uuid>` (ensure распознает и пропустит).
-2. **Статусы — точные канонические имена** (22, источник — `plane_sync._PLANE_NAME_TO_KEY`;
-   опечатка = тихая деградация fail-closed веток):
-
-   | Статус | Группа | | Статус | Группа |
-   |--------|--------|-|--------|--------|
-   | Backlog | `backlog` | | In Review | `started` |
-   | Todo | `unstarted` | | Blocked | `started` |
-   | To Analyse | `unstarted` | | Approved | `started` |
-   | In Progress | `started` | | Rejected | `started` |
-   | Analysis | `started` | | **Confirm Deploy** | `started` |
-   | Architecture | `started` | | Needs Input | `started` |
-   | Development | `started` | | Done | `completed` |
-   | Code-Review | `started` | | Cancelled | `cancelled` |
-   | Review | `started` | | **STOP** | **`cancelled`** |
-   | Testing | `started` | | Awaiting Deploy | `started` |
-   | Deploying | `started` | | Monitoring after Deploy | `started` |
-
-   ⚠️ Код-критично: `STOP` обязан быть в группе `cancelled` (иначе ветка отмены молча не
-   активируется); в терминальных группах (`completed`/`cancelled`) — ТОЛЬКО
-   Done/Cancelled/STOP, иначе terminal-detection ложно сочтёт живую задачу терминальной.
-3. **Лейблы**: `autoApprove`, `autoDeploy`, `Bug` (имена — из конфига оркестратора; их
-   отсутствие = fail-safe ручной режим / полный цикл).
-4. **🖐 РУЧНОЙ ШАГ — порядок статусов на доске**: drag-and-drop в UI (API не управляет
-   порядком). Проверка: открой доску проекта — колонки в порядке конвейера.
-5. **Workspace-webhook**: уже **существует** (один на весь workspace, создан на уровне
-   workspace заранее) — CLI его НЕ создаёт, только напоминает проверить:
-
-   ```bash
-   docker exec -e PGPASSWORD=plane plane-app-plane-db-1 psql -U plane -d plane -c \
-     "SELECT id, url, is_active FROM webhooks;"
-   ```
-
---
-
-## 2. Слой Gitea: репо + per-repo webhook
-
-1. **Репо** `--gitea-owner/--repo`: создаётся пустым (`auto_init=false`; ветку `main` создаст
-   initial push следующего слоя). Существует → `skipped(exists)`.
-2. **Per-repo webhook**: `events: push/pull_request/status`, `content_type: json`,
-   `branch_filter: *`, URL = `--webhook-url`. **Секрет переиспользуется** из
-   `ORCH_GITEA_WEBHOOK_SECRET` (приёмник валидирует ОДИН глобальный секрет на все репо;
-   новый секрет сломал бы HMAC существующих вебхуков). Секрета нет в env → CLI сгенерирует и
-   выведет строку для `.env` — **🖐 РУЧНОЙ ШАГ**: добавить её в `.env` (в гит не коммитить).
-   Формат и проверка — `docs/operations/SETUP_WEBHOOKS.md`. Проверка:
-
-   ```bash
-   curl -s -H "Authorization: token $ORCH_GITEA_TOKEN" \
-     "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
-   ```
-3. **Branch protection `main` НЕ включать** (ADR D10): required-approvals/status-checks ломают
-   PR-merge API merge-актора конвейера (ложные HOLD). Защита держится конвенцией + скоупом
-   токенов.
-
---
-
-## 3. Слой kit: материализация + initial push
-
-1. `apply` рендерит kit (`onboarding/repo-skeleton/`, плейсхолдеры `{{NAME}}` из
-   `onboarding/placeholders.json`) во временный каталог, докладывает live-copy канона
-   (`docs/_templates/` 16 скелетов + `docs/_standards/` 3 стандарта — verbatim из текущего
-   чекаута, BR-2 «канон не форкается») и пушит **ТОЛЬКО в свежесозданный/пустой репо**
-   (единственный разрешённый push; коммит `feat: onboarding skeleton (ORCH-009 kit)`).
-2. Репо непустой → шаг помечается `manual-step`: **🖐 РУЧНОЙ ШАГ** — занеси недостающие
-   файлы обычным PR с ревью; поверх существующего контента ничего не пушится (BR-9).
-3. После рендера не должно остаться ни одного `{{...}}`: CLI падает на этом сам; повторная
-   проверка — `verify` (скан плейсхолдеров в файлах репо).
-
---
-
-## 4. Регистрация в реестре оркестратора
-
-> ⚠️ **САМЫЙ ВАЖНЫЙ РУЧНОЙ СЛОЙ.** CLI `.env` прода НЕ правит и контейнер НЕ рестартит
-> (инвариант NFR-2) — он только печатает готовую строку.
-
-1. **🖐 РУЧНОЙ ШАГ — env**: возьми из отчёта `apply` строку
-   `ORCH_PROJECTS_JSON=[...полный merged-массив...]` (существующие записи verbatim + новая в
-   конец; строка уже провалидирована фактическим парсером реестра) и замени ею строку в `.env`
-   оркестратора на хосте. Вставляется атомарно одной строкой — ручное слияние JSON не нужно.
-2. **🖐 РУЧНОЙ ШАГ — управляемый рестарт оркестратора**: реестр строится при импорте, нужна
-   перезагрузка процесса. **Self-hosting предупреждение: прод-контейнер один на ВСЕ проекты —
-   рестарт = групповое окно** (встаёт конвейер всех проектов). Выполняй осознанно: дождись
-   тихого окна (`GET /queue` — нет бегущих job), затем штатный рестарт по
-   `docs/operations/INFRA.md`. Проверка после рестарта:
-
-   ```bash
-   curl -s http://localhost:8500/health
-   curl -s http://localhost:8500/queue | python3 -m json.tool | head -30   # реестр жив, конвейер пуст/цел
-   ```
-3. TTL-self-heal статусов Plane (300с) рестарта НЕ требует: статусы/лейблы, созданные после
-   регистрации, подхватятся сами.
-
---
-
-## 5. Верификация
-
-1. **`verify`-режим CLI** (read-only):
-
-   ```bash
-   python3 scripts/onboard_project.py verify --name ... --repo ... --prefix ... \
-     --plane-project-id <uuid> --stack ... --test-cmd ... --prod-port ... --staging-port ... \
-     --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
-   ```
-
-   Проверяет: запись реестра парсится и совпадает по полям; все 22 статуса резолвятся
-   (включая fail-closed `Confirm Deploy`/`STOP`); лейблы на месте; webhook существует и
-   активен; kit-файлы в репо (6 промптов, `AGENTS.md`, `INFRA.md`, `_templates`/`_standards`);
-   нет неразрешённых плейсхолдеров. Любой gap → exit `2` с перечнем.
-
-2. **Smoke на песочнице (ADR D8)** — контур: **staging-оркестратор (порт 8501, изолированная
-   БД `./data/staging`)** + одноразовый sandbox-проект (рекомендуемые имена: проект
-   `onboarding-smoke`, префикс `SMK`, репо `onboarding-smoke`):
-   1. Онборди sandbox самим CLI (слои 1–3 этого runbook).
-   2. **🖐 РУЧНОЙ ШАГ**: зарегистрируй sandbox в `ORCH_PROJECTS_JSON` **`.env.staging`**
-      (не прода!) и перезапусти staging-контейнер (он свободен от прод-инварианта):
-      `docker compose --profile staging up -d orchestrator-staging`.
-   3. Создай тестовую задачу в sandbox-проекте → доведи до стадии analysis в песочнице.
-   4. Критерий PASS: агент по своему промпту **прочитал доку проекта** (следы чтения
-      `CLAUDE.md`/`AGENTS.md` в выводе) и **записал артефакты** в `docs/work-items/SMK-…/`
-      по канону `PIPELINE_DOCS.md`.
-   5. Запротоколируй прогон в «Журнале smoke-прогонов» (ниже). Для приёмки ORCH-009 первый
-      протокол обязателен.
-
---
-
-## 6. Откат
-
-CLI ничего не удаляет (BR-9) — откат всегда ручной и осознанный:
-
-| Что создано | Как откатить | Проверка |
-|-------------|--------------|----------|
-| Plane-проект (+статусы/лейблы) | удалить проект в UI Plane | проект исчез из списка workspace |
-| Gitea-репо (+webhook) | удалить репо в UI/API Gitea (webhook умрёт вместе с ним) | `GET /api/v1/repos/<owner>/<repo>` → 404 |
-| Строка реестра | убрать запись из `ORCH_PROJECTS_JSON` в `.env` + управляемый рестарт (см. слой 4, то же групповое окно) | `GET /queue` — проекта нет в реестре |
-| Sandbox-артефакты smoke | удалить sandbox-проект/репо после прогона (или архивировать) | см. выше |
-
---
-
-## Журнал smoke-прогонов
-
-| Дата | Оператор | Параметры (проект/префикс/репо) | Контур | Результат (PASS/FAIL) | Протокол |
-|------|----------|----------------------------------|--------|------------------------|----------|
-| —    | —        | — (первый прогон фиксируется при приёмке ORCH-009) | staging 8501 | — | — |
-
---
-
-## Ссылки
-
- Архитектура решения: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
-  (D1…D11); сквозной ADR — `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
- Устройство набора шаблонов и словарь плейсхолдеров: `onboarding/README.md`.
- Формат вебхуков: `docs/operations/SETUP_WEBHOOKS.md`; топология и рестарты —
-  `docs/operations/INFRA.md`.
--- a/docs/operations/REPLICATION.md
+++ b/docs/operations/REPLICATION.md
@@ -1,155 +0,0 @@
-# REPLICATION — тираж платформы на новую инфраструктуру (ORCH-101)
-
-> RUNBOOK фундамента тиража (эпик ORCH-10, слой **10-common**). Как развернуть
-> оркестратор на чужом хосте **без правки кода**: переменные → секреты → smoke.
-> Тираж **stateless**: данные/БД/секреты боевого хоста НЕ переносятся ни на одном
-> шаге — на целевой инфре всё создаётся заново.
-
---
-
-## 1. Границы: 10-common vs Lite vs Bundled
-
-| Слой | Что это | Статус |
-|------|---------|--------|
-| **10-common** (этот док) | фундамент: все хост-значения параметризованы (env/конфиг), секреты выпускаются заново, smoke-процедура с PASS/FAIL | ✅ ORCH-101 |
-| **Type A — Lite** | инструкция «поставь Plane+Gitea сам, подключи оркестратор» поверх 10-common | ✅ ORCH-102 — [`docs/deployment/LITE_SETUP.md`](../deployment/LITE_SETUP.md) |
-| **Type B — Bundled** | комплект «всё в одном» (Plane+Gitea+оркестратор) поверх 10-common | ✅ ORCH-103 — [`docs/deployment/BUNDLED_SETUP.md`](../deployment/BUNDLED_SETUP.md) |
-
-Этот док НЕ описывает установку Plane/Gitea — только параметризацию, секреты и
-smoke самого оркестратора (анти-скоуп-крип Р-5).
-
-### Платформенные конвенции тиража (нормативно, ADR-001 D3/D4)
-
- **Репо платформы обязан называться `orchestrator`.** Имя — узел безопасности
-  (`SELF_HOSTING_REPO`, на него завязаны все `*_repos`-leaf'ы «empty CSV →
-  self-hosting only»); оно сознательно НЕ конфигурируется.
- Имена compose-сервисов/профиля (`orchestrator`, `orchestrator-staging`,
-  `orchestrator-watchdog`, профиль `staging`) — константы платформы.
- Контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout
-  контейнера, не хост-значения; не параметризуются.
-
---
-
-## 2. Карта переменных нового хоста
-
-Принцип (ADR-001 D1): **дефолт каждой переменной = боевое значение текущего
-хоста** — пустой `.env` ⇒ поведение байт-в-байт; на новом хосте задаёшь только
-то, что отличается. Одно env-имя = один факт: pydantic `Settings` читает имя из
-`env_file`, compose-интерполяция `${VAR:-default}` — из **`.env` проекта/shell**
-(⚠️ НЕ из `env_file` сервиса: `.env.staging` на интерполяцию не влияет —
-значения для маунтов/uid/портов живут в `.env`).
-
-### 2.1. Хост-параметризация (новое в ORCH-101)
-
-| Переменная | Дефолт | Назначение |
-|-----------|--------|------------|
-| `ORCH_AGENT_HOME_DIR` | `/home/slin` | HOME всех акторов (агенты, finalizer, monitor) + таргет маунтов `.claude`/`.claude.json`/`.ssh` + `ARG APP_HOME` (группа ORCH-040 двигается вместе) |
-| `ORCH_AGENT_GIT_NAME` | `claude-bot` | git-имя коммитов агентов |
-| `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен git-email всех акторов (`claude-bot@…`, `deploy-finalizer@…`, `post-deploy-monitor@…`) |
-| `ORCH_STAGING_PORT` | `8501` | порт staging; читают `image_freshness` И compose `command:`; guard: совпадение с прод-портом → отказ fail-closed (ORCH-058 AC-9) |
-| `ORCH_HOST_REPOS_DIR` | `/home/slin/repos` | каталог репозиториев на хосте (источник маунта `/repos`) |
-| `ORCH_HOST_CLAUDE_DIR` | `/home/slin/.claude` | источник маунта `~/.claude` |
-| `ORCH_HOST_CLAUDE_JSON` | `/home/slin/.claude.json` | источник маунта `~/.claude.json` |
-| `ORCH_HOST_SSH_DIR` | `/home/slin/.orchestrator-ssh` | источник маунта ssh-ключей (`→ $HOME/.ssh:ro`) |
-| `ORCH_HOST_CLAUDE_CODE_DIR` | `/usr/lib/node_modules/@anthropic-ai/claude-code` | дистрибутив claude-code на хосте |
-| `ORCH_HOST_NODE_BIN` | `/usr/bin/node` | бинарь node на хосте |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` | `1000` / `1000` | uid:gid контейнера (`user:` + `ARG APP_UID/APP_GID`); = uid владельца `ORCH_HOST_REPOS_DIR` (ORCH-040) |
-| `ORCH_DOCKER_GID` | `999` | gid группы docker хоста (`group_add`, «МИНА 1» — обязателен для docker.sock); узнать: `getent group docker` |
-| `ORCH_DEPLOY_PROD_TARGET_PORT` | `8500` | (реюз) прод-порт; интерполируется в `command:` прод-сервиса |
-| `ORCH_DEPLOY_SSH_USER` / `ORCH_DEPLOY_HOST_REPO_PATH` | `slin` / `/home/slin/repos/orchestrator` | (реюз) ssh-юзер хука и чекаут платформы на хосте; `REPO=` передаётся хуку явно из конфига |
-
-### 2.2. Обязательные ключи идентичности нового хоста
-
-| Переменная | Где взять |
-|-----------|-----------|
-| `ORCH_PLANE_API_URL` / `ORCH_PLANE_WEB_URL` / `ORCH_PLANE_WORKSPACE_SLUG` | инсталляция Plane целевого хоста |
-| `ORCH_GITEA_URL` / `ORCH_GITEA_PUBLIC_URL` / `ORCH_GITEA_OWNER` | инсталляция Gitea целевого хоста |
-| `ORCH_PROJECTS_JSON` | **обязателен на новом хосте**: встроенный fallback (`src/projects.py`) несёт Plane-UUID *исходного* хоста — чужие UUID безвредны (не сматчатся), но без своего реестра конвейер не увидит проекты. Сгенерировать: `scripts/onboard_project.py apply` печатает merged-значение |
-| Когерентность портов | сменил прод-порт → синхронно `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL` |
-
-Полный справочник всех остальных флагов — `.env.example` (канон) и
-`docs/operations/INFRA.md` (карта env).
-
---
-
-## 3. Секреты нового хоста (FR-4 / AC-5)
-
-**Нормативно: боевые секреты текущего хоста НЕ копируются ни на одном шаге.**
-Для нового хоста всегда выпускается новый комплект.
-
-### 3.1. Генерация локальных webhook-секретов
-
-```bash
-python3 scripts/gen_secrets.py            # печать .env-фрагмента в stdout
-python3 scripts/gen_secrets.py --write    # создать .env (существующий → отказ exit=2)
-python3 scripts/gen_secrets.py --write --force  # перезапись только явно
-```
-
-Скрипт stdlib-only (`secrets.token_hex(32)` — 32 байта энтропии); повторный
-запуск даёт другие значения; существующий `.env` **никогда не перезаписывается
-молча**.
-
-| Секрет | Генерируется | Куда вписать |
-|--------|--------------|--------------|
-| `ORCH_PLANE_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + настройка webhook в Plane (см. `SETUP_WEBHOOKS.md`) |
-| `ORCH_GITEA_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + webhook Gitea (создаёт `onboard_project.py apply`) |
-
-### 3.2. Чек-лист внешних токенов
-
-| Секрет | Где выпустить | Куда вписать | Как проверить |
-|--------|---------------|--------------|---------------|
-| `ORCH_PLANE_API_TOKEN` | Plane UI → Workspace Settings → API tokens | `.env` | `curl -H "X-API-Key: $TOKEN" $ORCH_PLANE_API_URL/api/v1/workspaces/<slug>/projects/` → 200 |
-| `ORCH_PLANE_BOT_*` (7, опциональны) | Plane UI: bot-аккаунты per-агент; пусто → fallback на `ORCH_PLANE_API_TOKEN` | `.env` | комментарий в Plane от имени бота |
-| `ORCH_GITEA_TOKEN` | Gitea UI → Settings → Applications → Generate Token (scope: repo, admin:repo_hook) | `.env` | `curl -H "Authorization: token $TOKEN" $ORCH_GITEA_URL/api/v1/user` → 200 |
-| `ORCH_TELEGRAM_BOT_TOKEN` | BotFather (`/newbot`) | `.env` | `curl https://api.telegram.org/bot$TOKEN/getMe` → ok |
-| `ORCH_TELEGRAM_CHAT_ID` (несекретный) | id чата оператора | `.env` | тестовое сообщение |
-| `WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID` | отдельный бот sidecar-watchdog (ORCH-100, независимый канал) | `.env.watchdog` | алерт от sidecar |
-
-### 3.3. Полнота
-
-`.env.example` — канон 100% ключей старта (секретные значения — только
-плейсхолдеры). Состав вывода `gen_secrets.py` сверяется с `.env.example`
-тестом (`tests/test_secrets_gen.py`).
-
---
-
-## 4. Smoke-верификация тиража (FR-5 / AC-3)
-
-Процедура «инстанс → тестовый проект → тестовая задача → конвейер доехал» из
-существующих кирпичей; **каждый шаг имеет явный PASS/FAIL**. Итог — однозначный
-вердикт: все шаги PASS ⇒ тираж PASS; любой шаг FAIL ⇒ тираж FAIL (собери логи
-контейнера `docker logs orchestrator` и снапшот `GET /queue` и разбирайся).
-
-Воспроизводимость без нового железа: процедура прогоняется на текущей инфре —
-staging-песочница (порт `ORCH_STAGING_PORT`, дефолт 8501) + sandbox-проект.
-Stateless: ни один шаг не предполагает перенос данных/БД/секретов.
-
-| # | Шаг | Команда | PASS | FAIL |
-|---|-----|---------|------|------|
-| 0 | Конфиг резолвится | `docker compose config` | резолв без ошибок; при пустом env значения = боевым дефолтам | ошибка интерполяции / неожиданные значения |
-| 1 | Инстанс жив | `curl -fsS http://127.0.0.1:<port>/health` | HTTP 200, `"status":"ok"` | не-200 / таймаут |
-| 2 | Контракты отвечают | `curl -fsS …/queue` и `…/metrics` | JSON со штатными блоками; `/metrics` → `schema_version: 1` | не-JSON / 5xx |
-| 3 | Тестовый проект | `python3 scripts/onboard_project.py plan` → `apply` → `verify` (sandbox) | `verify` зелёный (статусы/лейблы/repo/webhook на месте) | `verify` красный / manual-step не выполнен |
-| 4 | Тестовая задача | создать issue в Plane → статус «To Analyse» | задача в БД, analyst-job виден в `GET /queue` | задача не появилась (webhook/секрет/реестр) |
-| 5 | **Минимальный сигнал «конвейер доехал»** | дождаться окончания `analysis` | артефакты `01`–`04` в ветке задачи: `git ls-tree origin/<branch> docs/work-items/<id>/` | стадия не завершилась / артефактов нет |
-| 6 | Расширенный режим (опционально) | Approved → … → Confirm Deploy | задача дошла до `done` | застряла (разбор по `GET /queue` + логам) |
-
-> Ручной запуск deploy-хука на нестандартных портах — всегда с явными
-> `REPO=`/`TARGET_PORT=` (wired-путь оркестратора передаёт их сам из конфига;
-> дефолты хука — staging текущего хоста).
-
---
-
-## 5. Что НЕ переносится (stateless, решение 10.06)
-
- БД (`data/orchestrator.db`) — создаётся пустой при первом старте;
- `.env` / `.env.staging` / `.env.watchdog` — собираются заново (§2–§3);
- worktree'ы/runs/логи — рабочее состояние, не данные;
- боевые секреты — никогда (§3).
-
---
-
-*RUNBOOK ORCH-101. Поддерживать при добавлении хост-переменных (карта §2 +
-`.env.example` + INFRA.md в том же PR). Анти-регресс возврата хардкодов —
-`tests/test_no_host_hardcodes.py`; параметризация инфра-файлов —
-`tests/test_infra_parametrization.py`.*
--- a/docs/operations/SETUP_WEBHOOKS.md
+++ b/docs/operations/SETUP_WEBHOOKS.md
@@ -12,36 +12,30 @@ Internal URL: `http://127.0.0.1:8500/`

 ---

-## Gitea Webhook (per-repo)
+## Gitea Webhook

-Gitea-webhook — **per-repo**: создаётся для КАЖДОГО подключаемого к оркестратору репозитория
-(`<repo>` ниже). Для новых проектов его создаёт onboarding-CLI
-(`scripts/onboard_project.py apply`) — полный процесс см. `docs/operations/ONBOARDING.md`;
-команды ниже — для ручной проверки/пересоздания на любом репо.
+**Создан автоматически через API.**

 - URL: `https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea`
 - Events: `push`, `pull_request`, `status`
- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env` — **ОДИН глобальный секрет на все
-  репо** (приёмник валидирует только его; новый секрет на одном репо сломал бы HMAC остальных —
-  при ротации меняется на всех репо разом)
+- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env`
 - Signature header: `X-Gitea-Signature` (HMAC-SHA256 hex digest)

 ### Проверка

 ```bash
 GITEA_TOKEN=$(grep ORCH_GITEA_TOKEN /home/slin/repos/orchestrator/.env | cut -d= -f2)
-curl -s "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
+curl -s "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
  -H "Authorization: token ${GITEA_TOKEN}" | python3 -m json.tool
 ```

 ### Пересоздание (если нужно)

 ```bash
-# Секрет переиспользуй из .env (ORCH_GITEA_WEBHOOK_SECRET); генерируй новый ТОЛЬКО при
-# первичной настройке/осознанной ротации (и обнови вебхуки ВСЕХ репо):
-GITEA_WEBHOOK_SECRET=$(grep ORCH_GITEA_WEBHOOK_SECRET /home/slin/repos/orchestrator/.env | cut -d= -f2)
+GITEA_WEBHOOK_SECRET=$(openssl rand -hex 20)
+# Обновить в .env: ORCH_GITEA_WEBHOOK_SECRET=<new_secret>

-curl -X POST "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
+curl -X POST "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
  -H "Authorization: token ${GITEA_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
--- a/docs/overview/README.md
+++ b/docs/overview/README.md
@@ -1,89 +0,0 @@
-# Витрина системы — Orchestrator
-
-**Что это за система.** Orchestrator — автономная фабрика разработки: конвейер из шести
-ИИ-агентов (аналитик → архитектор → разработчик → ревьюер → тестировщик → деплойер), который
-проводит задачу от бизнес-постановки до выкладки на прод. Человек ставит задачу и принимает
-результат; всё между — автономно, под защитой машинных гейтов качества. Платформа ведёт
-несколько проектов из одного инстанса, дорабатывает сама себя (self-hosting) и тиражируется
-на новые хосты.
-
-**Зачем эта витрина.** Это единая точка входа в документацию системы: связное описание на двух
-уровнях — бизнес (для нетехнического читателя) и технический (7 блоков), с маршрутами чтения
-для трёх аудиторий и слайдо-готовой основой для презентации. Витрина — обзор; за деталями она
-ведёт ссылками в инженерные golden sources, не подменяя их.
-
---
-
-## Состав витрины
-
-| Файл | О чём |
-|------|-------|
-| [business.md](business.md) | Бизнес-уровень: проблема, решение, что умеет, ценность, сценарии |
-| [tech-architecture.md](tech-architecture.md) | Блок 1: компоненты и связи, схема потока |
-| [tech-pipeline.md](tech-pipeline.md) | Блок 2: конвейер, стадии, гейты, откаты, человеческие гейты |
-| [tech-agents.md](tech-agents.md) | Блок 3: 6 ролей агентов, артефакты, модель/эффорт |
-| [tech-data-model.md](tech-data-model.md) | Блок 4: каноническая модель объектов, словарь терминов |
-| [tech-integrations.md](tech-integrations.md) | Блок 5: Plane, Gitea, LLM, Telegram |
-| [tech-quality-security.md](tech-quality-security.md) | Блок 6: гейты качества, безопасность, секреты |
-| [tech-observability.md](tech-observability.md) | Блок 7: наблюдаемость, аналитика, журнал уроков |
-| [presentation.md](presentation.md) | Слайдо-источник презентации + сборка `.pptx` |
-
---
-
-## Маршруты чтения
-
-### Я заказчик
-1. [business.md](business.md) — проблема, решение, ценность.
-2. [business.md → Сценарии использования](business.md#сценарии-использования) — как это выглядит в работе.
-3. [presentation.md](presentation.md) — слайдовая версия рассказа (собирается в PowerPoint).
-4. Развернуть у себя: [LITE_SETUP](../deployment/LITE_SETUP.md) (своя инфраструктура) или
-   [BUNDLED_SETUP](../deployment/BUNDLED_SETUP.md) (весь стек одним комплектом).
-
-### Я менеджер проекта
-1. [business.md](business.md) — что платформа делает и где в процессе человек.
-2. [tech-pipeline.md](tech-pipeline.md) — конвейер, статусная модель Plane, человеческие гейты
-   (одобрение постановки, подтверждение прод-деплоя).
-3. [tech-observability.md](tech-observability.md) — как следить за ходом: живая Telegram-карточка,
-   статусы, стоимость.
-
-### Я разработчик
-1. Тех-блоки 1→7: [архитектура](tech-architecture.md) → [конвейер](tech-pipeline.md) →
-   [агенты](tech-agents.md) → [модель объектов](tech-data-model.md) →
-   [интеграции](tech-integrations.md) → [качество/безопасность](tech-quality-security.md) →
-   [наблюдаемость](tech-observability.md).
-2. [Инженерный справочник архитектуры](../architecture/README.md) и
-   [internals](../architecture/internals.md) — детали реализации.
-3. [Стандарты](../_standards/PIPELINE_DOCS.md) (структура доков конвейера),
-   [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md) (машинный контракт стадий),
-   [TRACEABILITY](../_standards/TRACEABILITY.md) (маркеры решений).
-4. [Реестр сквозных ADR](../architecture/adr/) — история архитектурных решений.
-5. [CLAUDE.md](../../CLAUDE.md) — паспорт проекта и правила для агентов.
-
---
-
-## Норматив сопровождения
-
-> **Изменил функциональность платформы → обнови витрину `docs/overview/` в том же PR.**
-
-Какой файл правится при каком классе изменений:
-
-| Класс изменения | Файл витрины |
-|-----------------|--------------|
-| Новый компонент / демон / поток данных | [tech-architecture.md](tech-architecture.md) |
-| Стадии, гейты, под-гейты, маршруты задач | [tech-pipeline.md](tech-pipeline.md) |
-| Роли агентов, промпты, модель/эффорт | [tech-agents.md](tech-agents.md) |
-| Таблицы БД, объекты, термины | [tech-data-model.md](tech-data-model.md) |
-| Plane / Gitea / LLM / Telegram | [tech-integrations.md](tech-integrations.md) |
-| Гейты качества, секреты, self-hosting-страховки | [tech-quality-security.md](tech-quality-security.md) |
-| Эндпоинты наблюдаемости, метрики, уроки | [tech-observability.md](tech-observability.md) |
-| Новая способность уровня продукта | [business.md](business.md) + при необходимости [presentation.md](presentation.md) |
-
-Каркас и машинно-проверяемые факты витрины (перечень стадий, имена гейтов, полнота агентов,
-валидность ссылок) защищены структурными тестами `tests/test_system_docs.py` — дрейф рвёт CI.
-Прозу проверяет reviewer: необновлённая витрина при изменении описанной в ней функциональности —
-finding ≥ P1 (расширение оси обзорных доков).
-
---
-
-*Витрина — обзорный слой документации. Текущее состояние и реестр доработок — [CLAUDE.md](../../CLAUDE.md);
-концепция развития — [Product Vision](../PRODUCT_VISION.md).*
--- a/docs/overview/business.md
+++ b/docs/overview/business.md
@@ -1,105 +0,0 @@
-# Бизнес-уровень: что это и зачем
-
-> Читатель этого документа — нетехнический: заказчик, руководитель, менеджер. Технические
-> детали вынесены в [тех-часть витрины](README.md) и даются здесь только ссылками.
-
-## Проблема
-
-Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор,
-разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря
-времени, контекста и денег. Мелкая фича или баг едут до прода днями: не потому, что работа
-сложная, а потому, что задача ждёт людей в очередях между ролями.
-
-## Решение
-
-**Orchestrator** — конвейер из ИИ-агентов, который проводит задачу через все стадии разработки
-сам: анализ требований → проектирование → код → ревью → тестирование → репетиция выкладки →
-выкладка на прод. Человек в этой схеме — **постановщик и приёмщик**: он формулирует задачу,
-одобряет постановку и подтверждает выкладку на прод. Всё между — автономно.
-
-Честность конвейера держат **гейты качества**: автоматические проверки на каждом переходе,
-которые не пускают задачу дальше, пока стадия не выполнена по-настоящему (тесты зелёные,
-ревью одобрено, репетиция выкладки успешна). Агент не может «уговорить» гейт — вердикты
-машинные, не прозой.
-
-## Что умеет платформа сегодня
-
-Ниже — фактическое состояние, не планы (концепция развития — отдельный документ,
-[Product Vision](../PRODUCT_VISION.md)).
-
- **Автономный конвейер «задача → прод».** Задача, поставленная в трекере, проходит весь путь
-  до выкладки без ручных пинков; человек участвует ровно в двух точках — одобрение постановки
-  и подтверждение прод-выкладки.
- **Мультипроектность.** Один инстанс платформы ведёт несколько проектов (репозиториев)
-  одновременно, с общей очередью и честным разделением работы.
- **Самовосстановление.** Фоновые механизмы находят и чинят зависшие задачи: упавший агент
-  перезапускается, осиротевшая задача возвращается в очередь, переполненный диск чистится,
-  а независимый сторож следит за самой платформой снаружи.
- **Пакетный авто-режим.** Задачи одного проекта выстраиваются в очередь и едут друг за другом
-  без столкновений; специальными метками на задаче можно снять оба человеческих одобрения —
-  и пакет задач уедет «за ночь» полностью автономно.
- **Дешёвый багфикс-маршрут.** Задача с меткой «баг» едет коротким путём — без тяжёлой
-  аналитики и отдельной стадии проектирования, но через все те же гейты качества.
- **Отмена задачи одной кнопкой.** Перевод задачи в статус «STOP» в трекере останавливает
-  работу, снимает её с очереди и прибирает за собой — безопасно даже посреди конвейера.
- **Наблюдаемость.** У каждой задачи — живая карточка в Telegram (стадия, время, стоимость);
-  у платформы — служебные страницы состояния и машинные метрики; история отклонений пишется
-  в журнал уроков.
- **Самообслуживание (self-hosting).** Платформа дорабатывает сама себя тем же конвейером,
-  с обязательной репетицией на песочнице и ручным подтверждением выкладки.
- **Тиражируемость.** Платформа разворачивается на новой инфраструктуре без правки кода:
-  вариант Lite (у заказчика своя инфраструктура) и вариант Bundled (весь стек одним
-  комплектом) — по пошаговым инструкциям.
-
-## Ценность
-
- ⚡ **Скорость.** Полный цикл «постановка → прод» без очередей между ролями; по оценке из
-  [Product Vision](../PRODUCT_VISION.md) — порядка 35 минут на типовую фичу без ручных
-  вмешательств.
- 💰 **Стоимость.** Работа агентов в разы дешевле команды специалистов; стоимость каждой
-  задачи видна в её карточке — расходы прозрачны.
- 🎯 **Автономность.** Ноль ручных пинков в штатном прогоне: человек принимает решения,
-  а не двигает задачу.
- 🛡️ **Надёжность.** Многоуровневые гейты качества и репетиция выкладки на песочнице не
-  пускают недоделку на прод; сломавшаяся выкладка откатывается, проект замораживается до
-  разбора.
- 🔁 **Масштаб.** Одна платформа — несколько проектов; сама платформа тиражируется на новые
-  хосты за часы по инструкции.
-
-## Сценарии использования
-
-### Сценарий 1: фича за вечер
-Заказчик формулирует задачу в трекере и переводит её в работу. Конвейер собирает требования,
-проектирует, пишет код и тесты, проходит ревью и тестирование, репетирует выкладку. Человек
-дважды нажимает «одобрить» — на постановке и перед продом. Вечером фича на проде.
-
-### Сценарий 2: багфикс по короткому маршруту
-На задачу ставится метка «баг» — конвейер пропускает тяжёлую аналитику и отдельное
-проектирование, сразу чинит и фиксирует дефект регресс-тестом. Все гейты качества — без
-исключений.
-
-### Сценарий 3: пакет задач на ночь
-Несколько задач проекта получают метки авто-одобрения. Очередь проводит их друг за другом:
-каждая следующая стартует от свежей версии кода с результатом предыдущей. Утром — пакет
-изменений на проде и полный след по каждой задаче.
-
-### Сценарий 4: несколько проектов параллельно
-Один инстанс платформы обслуживает несколько репозиториев: задачи разных проектов едут
-одновременно, не мешая друг другу; внутри одного проекта порядок строго последовательный.
-
-### Сценарий 5: развернуть платформу у себя
-Заказчик получает платформу на своей инфраструктуре по инструкции
-[Lite](../deployment/LITE_SETUP.md) (есть свои трекер и git) или
-[Bundled](../deployment/BUNDLED_SETUP.md) (весь стек одним комплектом, ~14 контейнеров),
-со свежими секретами и проверкой каждого шага.
-
-### Сценарий 6: остановить задачу
-Передумали — переводите задачу в статус «STOP»: работа агента останавливается, ветка и
-рабочие материалы прибираются, задача помечается отменённой. Если задача в этот момент в
-необратимой фазе выкладки — отмена аккуратно откладывается до её честного завершения.
-
---
-
-*Технические детали каждой способности — в [тех-части витрины](README.md): как устроен
-[конвейер](tech-pipeline.md), кто такие [агенты](tech-agents.md), как работает
-[наблюдаемость](tech-observability.md).*
--- a/docs/overview/presentation.md
+++ b/docs/overview/presentation.md
@@ -1,190 +0,0 @@
-# Презентация системы: слайдо-источник
-
-> Источник истины презентации. Каждый слайд — блок `## Слайд N: Заголовок` с тезисами
-> (3–6 на слайд) и опциональной подписью визуала. Из этого файла собирается редактируемый
-> PowerPoint в тёмном дизайне — процедура в конце файла («Как собрать .pptx»). Собранный
-> бинарь в git не коммитится: меняешь рассказ — правишь этот файл и пересобираешь.
-
-## Слайд 1: Orchestrator — автономная фабрика разработки
-
- Конвейер из ИИ-агентов: от постановки задачи до выкладки на прод
- Человек ставит задачу и принимает результат — всё между автономно
- Платформа уже работает: ведёт несколько проектов и дорабатывает сама себя
-
-> Визуал: тёмный титул, логотип-конвейер из шести звеньев
-
-## Слайд 2: Проблема
-
- Классическая разработка — люди-бутылочное-горлышко на каждом шаге
- Каждая передача между ролями — потеря времени, контекста и денег
- Мелкая фича или баг едут до прода днями — из-за очередей, не сложности
-
-> Визуал: цепочка из шести человек с песочными часами между ними
-
-## Слайд 3: Решение
-
- Шесть ИИ-агентов проводят задачу через все стадии разработки сами
- Аналитик → архитектор → разработчик → ревьюер → тестировщик → деплойер
- Человек принимает два решения: одобрить постановку и подтвердить прод
- Честность держат машинные гейты качества — их нельзя «уговорить»
-
-> Визуал: та же цепочка, но из агентов; человек над ней с двумя кнопками
-
-## Слайд 4: Как это работает — конвейер
-
- Задача из трекера едет по стадиям: анализ → проектирование → код → ревью → тесты → репетиция → прод
- На каждом переходе — гейт: машинная проверка честности стадии
- Не прошёл гейт — задача возвращается на доработку с замечаниями
- Каждая задача — своя ветка и изолированная рабочая копия кода
-
-> Визуал: горизонтальная схема стадий со шлагбаумами-гейтами
-
-## Слайд 5: Гейты качества
-
- Вердикты машинные: зелёный CI, одобрение ревью, отчёт тестов — только структурированные ключи
- Перед продом — четыре дополнительных проверки: безопасность, слияние, покрытие тестами, свежесть сборки
- Покрытие тестами не может деградировать: базовая линия растёт только вверх
- Слияние в основную ветку — только через PR; прямой push запрещён всем
-
-> Визуал: четыре шлагбаума подряд перед воротами «прод»
-
-## Слайд 6: Роли агентов
-
- Аналитик: требования, критерии приёмки, тест-план
- Архитектор: проектные решения с фиксацией в ADR
- Разработчик: код + тесты + документация одним PR
- Ревьюер и тестировщик: независимые машинные вердикты
- Деплойер: репетиция на песочнице, затем прод
-
-> Визуал: шесть карточек-ролей с артефактами на выходе
-
-## Слайд 7: Человек в контуре
-
- Постановщик и приёмщик, а не оператор: ноль ручных пинков в штатном прогоне
- Решение 1: одобрить постановку после аналитики
- Решение 2: подтвердить выкладку на прод отдельным статусом
- Живая карточка задачи в Telegram показывает, когда конвейер ждёт вас
-
-> Визуал: человек с двумя кнопками и карточка задачи в телефоне
-
-## Слайд 8: Пакетный автономный режим
-
- Задачи одного проекта едут строго друг за другом — без столкновений
- Каждая следующая стартует от свежего кода с результатом предыдущей
- Метки авто-одобрения снимают оба человеческих гейта — пакет уезжает «за ночь»
- Технические проверки при этом не ослабляются ни на одну
-
-> Визуал: ночная очередь задач, утром — стопка готовых
-
-## Слайд 9: Багфикс за полцены
-
- Метка «баг» — и задача едет коротким маршрутом
- Пропускаются тяжёлая аналитика и отдельное проектирование
- Обязателен регресс-тест, фиксирующий дефект
- Все гейты качества — без исключений
-
-> Визуал: развилка маршрутов — длинный и короткий путь к одному финишу
-
-## Слайд 10: Самовосстановление
-
- Упавший агент перезапускается, осиротевшая задача возвращается в очередь
- Зависшие состояния находит и чинит фоновый сверщик
- Независимый сторож следит за платформой снаружи и шлёт алерты отдельным каналом
- Деградация прода после выкладки замораживает проект до разбора человеком
-
-> Визуал: платформа с автоподзаводом и внешним сторожем
-
-## Слайд 11: Наблюдаемость
-
- Одна задача — одна живая карточка: стадия, агент, стоимость, время
- Служебные страницы: снимок очереди и машинные метрики для мониторинга
- Журнал уроков копит отклонения конвейера — фундамент самообучения
- Стоимость каждой задачи и каждой роли видна по фактам
-
-> Визуал: дашборд из карточки, очереди и графика стоимости
-
-## Слайд 12: Одна платформа — много проектов
-
- Несколько репозиториев из одного инстанса с общей очередью
- Внутри проекта — строгий порядок, между проектами — параллельность
- Платформа дорабатывает сама себя тем же конвейером (self-hosting)
- Своя доработка репетируется на песочнице и требует явного подтверждения
-
-> Визуал: один конвейер, несколько лент с разными проектами
-
-## Слайд 13: Сценарии использования
-
- Фича за вечер: постановка → прод с двумя кликами человека
- Пакет задач на ночь: метки авто-одобрения, утром всё на проде
- Багфикс по короткому маршруту с обязательным регресс-тестом
- Остановить задачу: статус STOP — безопасная отмена с уборкой
- Несколько проектов параллельно без пересечений
-
-> Визуал: пять пиктограмм-сценариев
-
-## Слайд 14: Тираж платформы
-
- Разворачивается на новой инфраструктуре без правки кода — только конфиг
- Lite: у заказчика свои трекер и git — ставятся только оркестратор и сторож
- Bundled: весь стек одним комплектом (~14 контейнеров) и бутстрап-скрипт
- Свежие секреты, пошаговые инструкции с проверкой каждого шага
-
-> Визуал: коробка-дистрибутив в двух размерах
-
-## Слайд 15: Статус платформы сегодня
-
- В проде: автономный конвейер, мультипроектность, самовосстановление
- В проде: пакетный авто-режим, багфикс-маршрут, отмена задач, журнал уроков
- Тираж Lite и Bundled — готовые инструкции и инструменты
- Платформа развивает сама себя: документация и гейты растут с каждой задачей
-
-> Визуал: чек-лист способностей с отметками «в проде»
-
-## Слайд 16: Итог
-
- Разработка без очередей между ролями: задача → прод за один проход
- Человек принимает решения — конвейер делает работу
- Качество держат машинные гейты, прозрачность — живая карточка и метрики
- Следующий шаг: поставить первую задачу или развернуть платформу у себя
-
-> Визуал: тёмный финальный слайд с одной фразой-приглашением
-
---
-
-## Как собрать .pptx
-
-Сборка выполняется **вне рантайма платформы** — в одноразовом dev-окружении на хосте
-разработчика (зависимость генерации не входит в прод-образ). Скрипт —
-`scripts/build_presentation.py`; формат слайдов выше парсится им же (один парсер — один
-источник истины).
-
-**Шаг 1. Создать venv и поставить python-pptx:**
-
-```bash
-python3 -m venv .venv-pptx
-.venv-pptx/bin/pip install python-pptx
-```
-
-Проверка: `.venv-pptx/bin/pip show python-pptx` печатает версию пакета — PASS; ошибка
-установки — FAIL (проверьте доступ к PyPI).
-
-**Шаг 2. Собрать презентацию (из корня репозитория):**
-
-```bash
-.venv-pptx/bin/python scripts/build_presentation.py
-```
-
-Проверка: скрипт печатает `Собрано слайдов: <N> → build/orchestrator-overview.pptx`, где
-`<N>` равно числу слайдов в этом файле — PASS; `ОШИБКА: …` — FAIL (текст подскажет причину).
-
-**Шаг 3. Открыть и проверить результат:**
-
-Откройте `build/orchestrator-overview.pptx` в PowerPoint/LibreOffice. Проверка: тема тёмная
-(тёмный фон, светлый текст, акцентные заголовки), кириллица отображается точно, текст слайдов
-выделяется и редактируется — PASS. Каталог `build/` в `.gitignore`: собранный бинарь в git
-не попадает.
-
---
-
-*Нарратив слайдов опирается на [business.md](business.md); технические утверждения — на
-тех-блоки витрины ([конвейер](tech-pipeline.md), [агенты](tech-agents.md)).*
--- a/docs/overview/tech-agents.md
+++ b/docs/overview/tech-agents.md
@@ -1,60 +0,0 @@
-# Блок 3. Агенты: 6 ролей конвейера
-
-> Промпты ролей лежат в `.openclaw/agents/*.md` (по одному файлу на роль). Канон манифеста
-> «документ → агент → стадия → гейт → machine-key» — [PIPELINE_DOCS §2](../_standards/PIPELINE_DOCS.md);
-> машинный контракт передачи между стадиями — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).
-
-## Паспорта ролей
-
-| Роль | Стадия | Вход | Выходные артефакты | Machine-verdict ключ |
-|------|--------|------|--------------------|----------------------|
-| `analyst` | analysis | бизнес-запрос (`00-business-request.md`) | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | — (гейт проверяет полноту пакета + одобрение человека) |
-| `architect` | architecture | пакет аналитики | `06-adr/ADR-NNN-*.md`, when-applicable `07-infra-requirements.md` / `08-data-requirements.md`, `10-tech-risks.md` | — (гейт проверяет наличие ADR) |
-| `developer` | development | ТЗ + ADR | код в `src/`, тесты в `tests/`, обновлённые доки, `CHANGELOG.md`, PR в Gitea | — (гейт — зелёный CI ветки) |
-| `reviewer` | review | PR diff + ТЗ/ADR | `12-review.md` | `verdict:` (`APPROVED` \| `REQUEST_CHANGES`) |
-| `tester` | testing | ветка задачи + тест-план | `13-test-report.md` | `result:` (`PASS` \| `FAIL` \| `BLOCKED`) |
-| `deployer` | deploy-staging / deploy | прошедшая гейты ветка | `15-staging-log.md`, `14-deploy-log.md` | `staging_status:` / `deploy_status:` (`SUCCESS` \| `FAILED`) |
-
-Machine-verdict ключи читаются гейтами **только из YAML-frontmatter** артефакта (никогда из
-прозы) и неизменны байт-в-байт — подробнее в [блоке качества](tech-quality-security.md).
-
-## Модель и эффорт
-
-Модель и эффорт каждой роли резолвятся **только из конфига** (не из промпта); текущие
-дефолты конфига:
-
-| Роль | Модель | Эффорт |
-|------|--------|--------|
-| `analyst` | `claude-opus-4-8` | `high` |
-| `architect` | `claude-opus-4-8` | `high` |
-| `developer` | `claude-opus-4-8` | `xhigh` |
-| `reviewer` | `claude-opus-4-8` | `high` |
-| `tester` | `claude-opus-4-8` | `medium` |
-| `deployer` | `claude-opus-4-8` | `medium` |
-
-Разработчику — максимальный эффорт (он пишет код); тестировщику и деплойеру хватает среднего
-(их работа процедурная). Таблица сверяется с class-default'ами `src/config.py` структурным
-тестом — дрейф рвёт CI.
-
-## Канон промптов
-
-Все промпты следуют единому канону (Anthropic XML, эпик 52): пять обязательных секций в
-нормативном порядке `<context>` → `<task>` → `<deliverables>` → `<constraints>` →
-`<output_format>`, запреты в формате «❌ X → ✅ Y», секция эскалации у решающих ролей. Каждый
-агент эмитит единую frontmatter-схему в своих документах (work item, стадия, автор, статус,
-дата, модель). Промпт читается из worktree в момент запуска — обновление промптов вступает в
-силу со следующей задачи, без рестарта прода.
-
-Особенность: промпт `deployer` сознательно на английском (самый safety-critical — несёт
-запреты self-hosting в видной рамке); остальные пять — на русском.
-
-## Человек как седьмая роль
-
-Человек не пишет артефакты конвейера, но принимает два решения, которые не делегированы
-агентам: одобрение постановки (после `analyst`) и подтверждение прод-выкладки (перед финалом
-работы `deployer`). Подробнее — [человеческие гейты](tech-pipeline.md).
-
---
-
-*Структуры документов, которые сдаёт каждая роль, — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md);
-скелеты — `docs/_templates/`.*
--- a/docs/overview/tech-architecture.md
+++ b/docs/overview/tech-architecture.md
@@ -1,63 +0,0 @@
-# Блок 1. Архитектура: компоненты и связи
-
-> Обзорный уровень. Полная таблица компонентов с деталями и историей решений — в
-> [инженерном справочнике](../architecture/README.md) («Компоненты») и
-> [internals](../architecture/internals.md); здесь — цельная картина, как части складываются
-> в конвейер.
-
-## Поток одной задачи
-
-```
-            Plane (трекер)            Gitea (git/CI)
-                 │ вебхук                  │ вебхук
-                 ▼                         ▼
-        ┌────────────────────────────────────────┐
-        │   FastAPI-приём (HMAC-подпись, дедуп)  │
-        └───────────────────┬────────────────────┘
-                            ▼
-   вебхук → очередь (jobs) → агент (Claude CLI в worktree) → гейт (QG) → переход стадии
-                            ▲                                              │
-                            └────────── следующая стадия / откат ◄─────────┘
-```
-
-Каждое продвижение задачи — один и тот же цикл: событие принято → в очередь поставлен job →
-worker запустил агента стадии → результат проверен гейтом качества → state machine перевела
-задачу на следующую стадию (или откатила назад).
-
-## Компоненты
-
-| Компонент | Роль |
-|-----------|------|
-| **Webhook-приёмники** (`src/webhooks/`) | Принимают события Plane (статусы задач) и Gitea (push, PR, CI). Проверяют HMAC-подпись, дедуплицируют повторные доставки. |
-| **Очередь задач** (`jobs` + worker) | Собственная очередь на SQLite: атомарный захват job'а, ретраи с backoff, зависимости между job'ами, ограничение параллелизма. |
-| **State machine** (`src/stages.py`) | Карта стадий `STAGE_TRANSITIONS`: для каждой стадии — следующая, агент и гейт выхода. Единственный источник истины о конвейере. |
-| **Stage engine** (`src/stage_engine.py`) | Исполняет переходы: диспетчеризация гейтов, откаты, под-гейты деплойного ребра, синхронизация статусов с Plane. |
-| **Agent launcher** (`src/agents/launcher.py`) | Запускает Claude CLI агента в изолированном git worktree ветки задачи, следит за процессом (watchdog), авто-продвигает стадию по завершении. |
-| **Реестр гейтов** (`src/qg/checks.py`) | `QG_CHECKS` — машинные проверки выхода со стадий; вердикты читаются только из YAML-frontmatter артефактов. |
-| **Plane-sync** (`src/plane_sync.py`) | Индикация статусов в Plane (слой «показать человеку», никогда не управление конвейером). |
-| **Notifications** (`src/notifications.py`) | Живая Telegram-карточка задачи и алерты. |
-
-## Фоновые демоны (самовосстановление)
-
-Поднимаются в lifespan FastAPI-приложения (`src/main.py`) и работают рядом с конвейером:
-
- **reconciler** — находит расхождения «БД говорит одно, реальность другое» (зависшие стадии,
-  потерянные ветки) и возвращает задачи в консистентное состояние;
- **job-reaper** — возвращает в очередь job'ы, чей исполнитель умер (упавший процесс, рестарт);
- **disk-watchdog** — следит за местом на диске, чистит устаревшие worktree;
- **build-cache-pruner** — прибирает докер-кэш сборок.
-
-Отдельно от приложения живёт **sidecar-watchdog** — независимый контейнер-наблюдатель: следит
-за самим оркестратором снаружи (health, метрики) и шлёт алерты в собственный Telegram-канал.
-Наблюдатель сознательно отделён от наблюдаемого: падение оркестратора не валит сторожа.
-
-## Изоляция работы агентов
-
-Каждая задача живёт в собственной git-ветке (`feature/<ID>-slug`) и собственном **worktree** —
-изолированной рабочей копии репозитория. Агенты разных задач не видят незакоммиченную работу
-друг друга; слияние в `main` происходит только через PR в Gitea после всех гейтов.
-
---
-
-*Подробнее: [компоненты и API](../architecture/README.md) · [внутренности и схема БД](../architecture/internals.md) ·
-следующий блок — [конвейер и стадии](tech-pipeline.md).*
--- a/docs/overview/tech-data-model.md
+++ b/docs/overview/tech-data-model.md
@@ -1,70 +0,0 @@
-# Блок 4. Структура объектов: каноническая модель
-
-> Источник истины — фактическая схема SQLite в `src/db.py` и реестр проектов в
-> `src/projects.py`; подробное описание таблиц — [internals, «Database Schema»](../architecture/internals.md).
-
-## Каноническая модель
-
-```
-Project ──1:N──► Work-Item / Task ──1:N──► Job ──1:N──► Agent-run
-   │                    │
-   │                    └── артефакты задачи (docs/work-items/<ID>/)
-   └── Plane-проект ↔ git-репозиторий ↔ префикс задач
-```
-
-### Project — проект в реестре
-Связка «Plane-проект ↔ git-репозиторий ↔ префикс задач» (например, `ORCH-`). Реестр живёт в
-конфиге (`src/projects.py`): один инстанс платформы обслуживает несколько проектов; по
-префиксу задачи платформа находит репозиторий и настройки.
-
-### Work-Item / Task — задача конвейера
-Строка таблицы `tasks`: текущая **стадия** (`stage`), **маршрут** (`track`: полный или
-багфикс), рабочая **ветка**, счётчики откатов, отметки отмены. Натуральные ключи — ID задачи
-в Plane и человекочитаемый номер (`ORCH-NNN`). На каждой стадии задача накапливает
-**артефакты** — номерные документы в `docs/work-items/<ID>/` (от бизнес-запроса до
-deploy-лога; манифест — [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md)).
-
-### Job — единица работы в очереди
-Строка таблицы `jobs`: что запустить (агент какой стадии), для какой задачи, в каком статусе
-(`queued` → `running` → терминал). Очередь даёт: **атомарный захват** (два worker'а не возьмут
-один job), **зависимости** между job'ами, **ретраи** с экспоненциальным backoff и breaker
-после исчерпания бюджета, ограничение параллелизма.
-
-### Agent-run — один запуск агента
-Строка таблицы `agent_runs`: какой агент, какой моделью и эффортом, сколько длился, сколько
-стоил (токены/доллары). Из этих строк складывается честная стоимость задачи в живой карточке
-и аналитика по ролям.
-
-### События вебхуков и дедуп
-Входящие события Plane/Gitea фиксируются с ключом дедупликации: повторная доставка того же
-события (ретраи источника, сетевые икоты) не порождает повторной работы.
-
-## Вспомогательные таблицы
-
-| Таблица | Зачем |
-|---------|-------|
-| `repo_freeze` | durable-заморозка репозитория после деградации прода (serial gate) |
-| `coverage_baseline` | базовая линия покрытия тестами; растёт только вверх (ratchet) |
-| `tracker_messages` | леджер всех Telegram-карточек задачи (зачистка сирот) |
-| `lessons` | машинный журнал уроков — структурированные отклонения конвейера |
-
-Все изменения схемы — аддитивные и идемпотентные (`CREATE TABLE IF NOT EXISTS`, ensure-column
-при старте): обновление платформы не требует ручных миграций.
-
-## Словарь терминов
-
-| Термин | Значение |
-|--------|----------|
-| **Стадия** | Позиция задачи в конвейере; карта стадий — `STAGE_TRANSITIONS` ([блок 2](tech-pipeline.md)) |
-| **Гейт (exit-гейт)** | Машинная проверка выхода со стадии; реестр — `QG_CHECKS` |
-| **Под-гейт** | Проверка-врезка внутри перехода (не стадия); см. деплойное ребро в [блоке 2](tech-pipeline.md) |
-| **Job** | Единица работы в очереди; задача порождает job'ы по мере продвижения |
-| **Worktree** | Изолированная рабочая копия репозитория для ветки задачи |
-| **Lease (merge-lease)** | Эксклюзивная блокировка «кто сейчас мержит этот репозиторий» — сериализация слияний |
-| **Track (маршрут)** | Вариант пути задачи: полный цикл или багфикс с пропуском проектирования |
-| **Freeze** | Заморозка очереди репозитория после инцидента до ручного разбора |
-
---
-
-*Как объекты двигаются по конвейеру — [блок 2](tech-pipeline.md); кто их создаёт —
-[агенты](tech-agents.md); как за ними наблюдать — [блок 7](tech-observability.md).*
--- a/docs/overview/tech-integrations.md
+++ b/docs/overview/tech-integrations.md
@@ -1,54 +0,0 @@
-# Блок 5. Интеграции: Plane, Gitea, LLM, Telegram
-
-> Обзорный уровень; детали API, эндпоинтов и вебхуков — в
-> [инженерном справочнике](../architecture/README.md) и [internals](../architecture/internals.md).
-
-## Plane — управление задачами
-
- **Вход конвейера:** перевод задачи в статус «To Analyse» — единственная точка запуска
-  пайплайна. Вебхуки Plane (HMAC-подписанные) доставляют изменения задач.
- **Статусы = индикация, не управление** ([блок 2](tech-pipeline.md)): платформа сама
-  выставляет статусы доски, чтобы человек видел осмысленную картину; управляют конвейером
-  только машина стадий и три управляющих статуса (запуск, человеческие гейты, STOP).
- **Лейблы** — декларативные переключатели на задаче: `autoApprove` / `autoDeploy` (снятие
-  человеческих гейтов), `Bug` (багфикс-маршрут). Источник истины — Plane API: ошибка чтения
-  лейблов трактуется как «лейбла нет» (fail-safe — никогда не «авто» по ошибке).
- Платформа пишет в задачу комментарии о ходе работ (под ботами ролей) с кликабельными
-  ссылками на ветку/PR.
-
-## Gitea — git, PR, CI
-
- **Каждая задача = одна ветка = один PR.** Ветка срезается от свежего `main`, работа идёт в
-  изолированном worktree, слияние — только после всех гейтов.
- **Слияние строго через PR-merge API** — платформенный инвариант: прямой push или
-  force-push в `main` запрещён всем акторам, включая агентов и сам движок.
- **Merge-актор устойчив к икотам:** транзиентные ошибки Gitea (таймаут, «try again later»)
-  ретраятся с backoff; необратимые — честный отказ без ложных повторов. Ветка, уже целиком
-  попавшая в `main`, распознаётся и не порождает мусорных PR.
- **CI (Gitea Actions)** гонит полный тест-сьют на каждый push ветки; зелёный CI — гейт
-  выхода из разработки (`check_ci_green`).
- Вебхуки Gitea (push, PR, статус CI) — второй источник событий конвейера.
-
-## LLM — Claude CLI
-
- Агенты запускаются через **Claude CLI**: launcher собирает команду с промптом роли,
-  `--model` и эффортом, резолвленными **только из конфига** (таблица — в
-  [блоке агентов](tech-agents.md)); имя модели валидируется перед запуском.
- Запуск — в worktree ветки задачи: агент видит код своей задачи и ничего лишнего.
- Каждый запуск пишет в учёт стоимость и токены ([блок 7](tech-observability.md)).
-
-## Telegram — живой трекер и алерты
-
- **Одна задача = одна живая карточка**: стадия, статус, модель/эффорт агента, стоимость,
-  честные метрики времени. Карточка обновляется «переездом вниз» чата (старая удаляется,
-  свежая приходит тихо); леджер карточек зачищает осиротевшие дубли.
- **Алерты** (упавший гейт, ожидание человека, инциденты) приходят отдельными сообщениями
-  с пингом.
- **Sidecar-watchdog шлёт в собственный канал** со своим ботом: наблюдатель за платформой
-  не зависит от её Telegram-стека.
-
---
-
-*Развёртывание интеграций с нуля — [LITE_SETUP](../deployment/LITE_SETUP.md) /
-[BUNDLED_SETUP](../deployment/BUNDLED_SETUP.md); безопасность стыков —
-[блок 6](tech-quality-security.md).*
--- a/docs/overview/tech-observability.md
+++ b/docs/overview/tech-observability.md
@@ -1,54 +0,0 @@
-# Блок 7. Наблюдаемость и аналитика
-
-> Машинный контракт метрик и устройство sidecar-наблюдателя — в
-> [инженерном справочнике](../architecture/README.md) (разделы `/metrics` и sidecar-watchdog).
-
-## Живая Telegram-карточка задачи
-
-Каждая задача — одна карточка в Telegram, обновляемая на каждом событии:
-
- текущая стадия и Plane-статус (включая человеческие гейты — видно, когда задача ждёт вас);
- строка работающего агента: роль · модель · эффорт;
- стоимость задачи нарастающим итогом (токены/доллары по каждому запуску агента);
- честные метрики времени на финише: время агентов / время ожидания человека / общее
-  календарное — три независимые цифры, а не одна вводящая в заблуждение сумма;
- кликабельный номер задачи (ведёт в Plane), отметка багфикс-маршрута.
-
-Карточка тихая (без пингов); пингуют только алерты: красный гейт, ожидание решения человека,
-инциденты.
-
-## Служебные страницы платформы
-
- **`GET /queue`** — человекочитаемый снимок всего конвейера: очередь и job'ы, состояние
-  serial gate и заморозок, авто-лейблы, багфикс-трек, coverage, журнал уроков, фоновые
-  демоны. Первая точка диагностики «что сейчас происходит».
- **`GET /metrics`** — машинный контракт для внешнего наблюдателя (версионированная схема):
-  health, возраст последних событий, счётчики сбоев.
- **`GET /health`** — живость процесса.
-
-## Sidecar-watchdog: наблюдатель отделён от наблюдаемого
-
-Отдельный контейнер-сторож опрашивает `/metrics` платформы и шлёт алерты в **собственный**
-Telegram-канал со **своим** ботом. Падение платформы, зависание очереди или протухание
-событий видно даже тогда, когда сама платформа уже не может пожаловаться.
-
-## Журнал уроков
-
-Машинная таблица отклонений конвейера: красные гейты, ложные блокировки слияния, исчерпание
-ретраев, деградации после выкладки. Каждая запись — контекст (задача, стадия, агент, репо),
-первопричина и предложение. Журнал — наблюдатель (никогда не влияет на продвижение задач) и
-фундамент петли самообучения платформы: уроки доступны через API и копятся для будущего
-ретроспективного анализа.
-
-## Стоимость и аналитика по агентам
-
-Каждый запуск агента фиксирует модель, эффорт, длительность и стоимость
-([модель объектов](tech-data-model.md)). Это даёт ответы на вопросы «сколько стоит задача»,
-«какая роль ест бюджет», «как изменилась экономика после смены модели» — по фактам, не по
-ощущениям.
-
---
-
-*Что делать при инцидентах и как устроен прод — `docs/operations/` (через
-[инженерный справочник](../architecture/README.md)); бизнес-взгляд на наблюдаемость —
-[business.md](business.md).*
--- a/docs/overview/tech-pipeline.md
+++ b/docs/overview/tech-pipeline.md
@@ -1,103 +0,0 @@
-# Блок 2. Конвейер: стадии, гейты, маршруты
-
-> Источник истины — карта переходов `STAGE_TRANSITIONS` в `src/stages.py` и реестр гейтов
-> `QG_CHECKS` в `src/qg/checks.py`; перечень ниже сверяется с кодом структурным тестом
-> (`tests/test_system_docs.py`). Норматив структуры доков конвейера —
-> [PIPELINE_DOCS](../_standards/PIPELINE_DOCS.md).
-
-## Схема конвейера
-
-```
-created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
-                          ↑                          │
-                          └──── REQUEST_CHANGES ─────┘   (откат на доработку, max 3)
-```
-
-Плюс системный сток **`cancelled`** — терминальное состояние отменённой задачи (кнопка STOP,
-см. ниже). Это не ребро конвейера, а равноправный `done` сток: попасть в него можно с любой
-стадии, выйти — нельзя.
-
-## Стадии и гейты выхода
-
-Гейт выхода (exit-гейт) — машинная проверка, без которой задача не покидает стадию:
-
-| Стадия | Кто работает | Гейт выхода (имя в реестре) | Что проверяет |
-|--------|--------------|------------------------------|----------------|
-| `created` | — | — | вход конвейера (вебхук Plane) |
-| `analysis` | analyst | `check_analysis_approved` | пакет аналитики полон И постановка одобрена человеком |
-| `architecture` | architect | `check_architecture_done` | ADR / инфра-требования зафиксированы |
-| `development` | developer | `check_ci_green` | CI на ветке задачи зелёный |
-| `review` | reviewer | `check_reviewer_verdict` | машинный вердикт ревью: APPROVED |
-| `testing` | tester | `check_tests_passed` | машинный вердикт тестера: PASS |
-| `deploy-staging` | deployer | `check_staging_status` | репетиция выкладки на песочнице успешна |
-| `deploy` | deployer / finalizer | `check_deploy_status` | прод-выкладка реально успешна |
-| `done` | — | — | терминал |
-| `cancelled` | — | — | терминал (сток отмены) |
-
-## Под-гейты деплойного ребра — врезки, не стадии
-
-На переходе `deploy-staging → deploy` исполняются четыре под-гейта в нормативном порядке
-(security → merge → coverage → image-freshness):
-
-1. `check_security_gate` — секреты/зависимости, вердикт из security-отчёта;
-2. `check_branch_mergeable` — merge-gate: ветка догнана до свежего `main` (под merge-lease)
-   и мержабельна;
-3. `check_coverage_gate` — покрытие тестами не ниже базовой линии/порога (baseline-ratchet);
-4. `check_staging_image_fresh` — staging-образ собран из актуального кода.
-
-Это **врезки в переход, а не стадии**: они не появляются в карте `STAGE_TRANSITIONS`, а
-исполняются stage engine'ом внутри ребра. Провал любого из них — откат на доработку. На ребре
-`deploy → done` аналогичная врезка merge-verify подтверждает, что код задачи реально слит в
-`main` (слияние — только через PR-API Gitea, см. [интеграции](tech-integrations.md)).
-
-## Откаты
-
-`REQUEST_CHANGES` от ревьюера, проваленные тесты или красный под-гейт возвращают задачу на
-стадию разработки с дословным перечнем замечаний. Лимит — 3 попытки подряд, дальше задача
-останавливается и требует человека (анти-петля).
-
-## Человеческие гейты и их снятие авто-лейблами
-
-В штатном прогоне человек принимает ровно два решения:
-
- **Одобрение постановки** (на `analysis`): перевод задачи в статус Approved пропускает её
-  дальше;
- **Подтверждение прод-выкладки** (на `deploy`): отдельный статус **Confirm Deploy** — чтобы
-  привычный «approve» не выкатывал прод случайным кликом.
-
-Оба решения можно снять декларативно — лейблами **autoApprove** / **autoDeploy** на задаче
-(пакетный авто-режим). Снимается только ожидание человеческого сигнала: ни одна техническая
-проверка не пропускается, autoDeploy физически не может выкатить непрошедшее под-гейты.
-
-## Багфикс-маршрут
-
-Задача с меткой **Bug** едет коротким путём: облегчённая аналитика (но полный пакет
-документов) и пропуск стадии `architecture` — из аналитики сразу в разработку. Срезается
-только аналитика/проектирование: **все гейты исполняются без изменений**. Сложный баг
-эскалируется обратно в полный цикл.
-
-## Последовательность внутри репозитория (serial gate)
-
-Новая задача репозитория не входит в работу, пока не завершена более ранняя (FIFO): ветка
-каждой задачи срезается от свежего `main`, уже содержащего код предшественника. Деградация
-прода после выкладки замораживает репозиторий (freeze) до ручного разбора — следующие задачи
-ждут.
-
-## Отмена: STOP → `cancelled`
-
-Перевод задачи в статус **STOP** останавливает агента, снимает job'ы с очереди, удаляет
-рабочую ветку и worktree и переводит задачу в `cancelled`. Если задача в необратимой фазе
-(идёт слияние/выкладка) — отмена откладывается и применяется после честного завершения шага.
-STOP никогда не трогает `main` и прод-контейнер.
-
-## Статусная модель Plane: индикация ≠ управление
-
-Статусы в Plane — слой **индикации**: они показывают человеку осмысленную картину хода задачи,
-но никогда не управляют конвейером (машина стадий — только `STAGE_TRANSITIONS`). Управляющих
-статусов ровно три: запуск в работу, Approved/Confirm Deploy (человеческие гейты) и STOP
-(отмена). Полная карта статусов — в [инженерном справочнике](../architecture/README.md).
-
---
-
-*Кто работает на каждой стадии и что сдаёт — [агенты](tech-agents.md); как гейты читают
-вердикты — [качество и безопасность](tech-quality-security.md).*
--- a/docs/overview/tech-quality-security.md
+++ b/docs/overview/tech-quality-security.md
@@ -1,63 +0,0 @@
-# Блок 6. Качество и безопасность
-
-> Реестр гейтов и их распределение по стадиям — [блок 2](tech-pipeline.md); механизм
-> machine-verdict доков — [PIPELINE_DOCS §3](../_standards/PIPELINE_DOCS.md); машинный
-> контракт стадий — [HANDOFF_PROTOCOL](../_standards/HANDOFF_PROTOCOL.md).
-
-## Философия Quality Gates
-
-**Вердикты — машинные, никогда проза.** Гейт читает вердикт ТОЛЬКО из YAML-frontmatter
-артефакта (ключи вида `verdict:`, `result:`, `staging_status:`, `deploy_status:`,
-`security_status:` — имена и регистр неизменны байт-в-байт). Агент не может «уговорить» гейт
-красивым отчётом: нет ключа — нет прохода. Парсинг frontmatter сведён к единому контракту
-`src/frontmatter.py` — одна точка чтения для всех гейтов.
-
-**Гейт ≠ маршрутизация.** Маршруты задач (багфикс-трек, авто-лейблы, serial gate) — свойство
-планировщика; ни один из них не ослабляет ни одного гейта. Любая новая способность платформы
-проектируется так, чтобы реестр гейтов и карта стадий не трогались.
-
-**Анти-петля.** Откаты на доработку ограничены (max 3 подряд); инструментальные сбои
-вспомогательных проверок по умолчанию fail-open с предупреждением (не запирают конвейер),
-критичные проверки — fail-closed.
-
-## Специальные гейты деплойного ребра
-
- **Security-гейт** (`check_security_gate`) — детерминированная (без LLM) проверка секретов и
-  зависимостей перед продом; вердикт — `security_status:` в отчёте задачи.
- **Coverage-гейт** (`check_coverage_gate`) — покрытие тестами измеряется на финальном коде
-  ветки; базовая линия по репозиторию растёт только вверх (ratchet при подтверждённом
-  слиянии) — покрытие не может деградировать молча.
-
-Оба — врезки в переход ([блок 2](tech-pipeline.md)), включаются по конфигу и скоупятся по
-репозиториям.
-
-## Канон секретов
-
- Секреты живут **только в `.env`-файлах на хосте** и никогда не коммитятся; в git — только
-  канон-примеры с пустыми плейсхолдерами.
- Для нового хоста секреты **выпускаются свежими** (`scripts/gen_secrets.py`), боевые не
-  копируются.
- Анти-регресс машинный: структурные тесты сканируют исполняемый код на боевые хост-литералы,
-  а документацию — на секретоподобные значения; находка рвёт CI.
-
-## Self-hosting-страховки
-
-Платформа дорабатывает сама себя тем же конвейером — прод-инстанс при этом обслуживает и
-другие проекты. Страховки:
-
- **Песочница обязательна:** перед прод-выкладкой платформы изменение репетируется на
-  staging-инстансе (отдельный порт/БД); guard не даёт staging-операциям коснуться прод-порта.
- **Прод-выкладка — только по явному человеческому статусу Confirm Deploy** (обычный approve
-  прод не выкатывает); деплой идёт детачнутым процессом с финализатором — честный исход
-  фиксируется даже при рестарте.
- **`main` неприкосновенен:** слияние только через PR-API, force-push запрещён всем.
- **Прод-контейнер никогда не роняется задачей**: агенты проверяют изменения локально и на
-  песочнице; рестарт прода — только штатным деплой-маршрутом.
- **Пост-деплой наблюдение:** после выкладки платформа следит за своим здоровьем; деградация
-  замораживает репозиторий и зовёт человека.
-
---
-
-*Операционные детали и топология прода — `docs/operations/` (см.
-[инженерный справочник](../architecture/README.md)); наблюдение за здоровьем —
-[блок 7](tech-observability.md).*
--- a/docs/work-items/ORCH-009/00-business-request.md
+++ b/docs/work-items/ORCH-009/00-business-request.md
@@ -1,7 +0,0 @@
-# Business Request: Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-
-Work Item ID: ORCH-009
-
-## Description
-
-TBD
--- a/docs/work-items/ORCH-009/01-brd.md
+++ b/docs/work-items/ORCH-009/01-brd.md
@@ -1,176 +0,0 @@
---
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# 01 — BRD: ORCH-009 — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-
-Work Item: **ORCH-009** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Слава · Домен эпика: 📈 **D5 Масштаб (D5.2)** — `docs/epics/self-evolution.md`
-
-> ⚠️ **Актуализация Владельца 10.06 принята как приоритетная над исходной постановкой 05.06.**
-> Эталон онбординга = **сам репозиторий orchestrator** (каноны ORCH-52b/c/d/e уже кодифицированы),
-> НЕ enduro-trails (устаревший пример). «Дыра: у orchestrator только deployer.md» — уже закрыта
-> (в `.openclaw/agents/` полный набор 6 промптов). Скоуп — **способность** разворачивать новый
-> проект по образцу орка одним проходом; онбординг конкретного нового заказчика — исполнение этой
-> способности, вне данной задачи.
-
---
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель
-При подключении **нового** проекта к оркестратору одним проходом разворачивается всё, что нужно
-мульти-агентам для автономной работы: Plane-проект (статусы/лейблы под машинные контракты),
-Gitea-репо (+webhook), полный набор промптов агентов, структура документации по единым канонам,
-инфра-описание (INFRA.md), регистрация в реестре проектов. Агенты нового проекта **обязаны** знать,
-где лежит документация, использовать её и актуализировать.
-
-### 1.2. Проблема сегодня
-Онбординг проекта — ручная археология: шаги размазаны по докам (`SETUP_WEBHOOKS.md`,
-`INFRA.md`), памяти Стрима/Славы и инцидентам (прецедент 2026-06-02: webhook всего workspace +
-захардкоженный `default_repo` → задачи чужого проекта падали в enduro-trails; закрыто реестром
-ORCH-6). Любой пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не
-работает вовсе; без точных имён статусов Plane ветки `Confirm Deploy`/`STOP` молча не активируются
-(fail-closed); без лейблов авто-режимы и багфикс-трек молча выключены (fail-safe). Турникей-проход
-обязан закрывать все слои сразу и проверяемо.
-
-### 1.3. Установленные факты (проверено по коду, не изобретать)
-
-| # | Факт | Где проверено |
-|---|------|---------------|
-| Ф-1 | Промпты агентов — **per-repo**: launcher резолвит `system_prompt: .openclaw/agents/<role>.md` относительно worktree репо задачи. Нет промптов в новом репо → конвейер для него не работает. | `src/agents/launcher.py` (реестр AGENTS, 6 ролей) |
-| Ф-2 | Агент видит **только** worktree своего репо → каноны (шаблоны/стандарты) обязаны быть **скопированы** в новый репо; «ссылка на репо орка» агенту недоступна. | модель worktree `src/git_worktree.py`, launcher |
-| Ф-3 | Реестр проектов строится **при импорте** из `ORCH_PROJECTS_JSON` (или built-in default): ключи `plane_project_id`/`repo`/`work_item_prefix`/`name` + опц. `agent_models`/`agent_efforts`. Регистрация нового проекта = правка `.env` на хосте + **управляемый рестарт** (операторский шаг). | `src/projects.py` (`_parse_projects_json`, `_load_projects`) |
-| Ф-4 | Статусы Plane резолвятся по **точным именам** (22 ключа `_PLANE_NAME_TO_KEY`); `Confirm Deploy` (ORCH-059) и `STOP` (группа `cancelled`, ORCH-090) — **fail-closed** (нет статуса на доске → ветка не активируется); TTL-self-heal 300с (ORCH-068) — статус, добавленный позже, подхватывается без рестарта. | `src/plane_sync.py` (`_PLANE_NAME_TO_KEY`, `get_project_states`) |
-| Ф-5 | Лейблы `autoApprove`/`autoDeploy` (ORCH-089) и `Bug` (ORCH-019) — **fail-safe** (нет лейбла → ручной режим / полный цикл); сопоставление по нормализованному имени через Plane API. | `src/labels.py`, `src/bug_fast_track.py`, CLAUDE.md (инфра-предусловия) |
-| Ф-6 | Plane-webhook — **workspace-level** (один на все проекты, уже существует; в Plane CE создаётся SQL-ом, внешнего API нет). Gitea-webhook — **per-repo** (создаётся через API; events `push`/`pull_request`/`status`; HMAC-secret). | `docs/operations/SETUP_WEBHOOKS.md`, docstring `src/projects.py` |
-| Ф-7 | Каноны (golden source) в репо орка: `docs/_templates/` — 16 скелетов (`00…18`, ORCH-52b); `docs/_standards/` — `HANDOFF_PROTOCOL.md`/`PIPELINE_DOCS.md`/`TRACEABILITY.md` (ORCH-52c/e); `.openclaw/agents/*.md` — 6 промптов канона Anthropic (ORCH-52d/92; `deployer.md` — английский **нормативно**, ADR-001 D2 ORCH-092); ADR-конвенция — `PIPELINE_DOCS.md` §4. | листинг репо, `docs/_standards/PIPELINE_DOCS.md` |
-| Ф-8 | Per-repo паспорт `CLAUDE.md` — канон самого ORCH-9 (подпись в паспорте орка: «канон per-repo, см. ORCH-9»); все 6 промптов орка начинаются с «прочти CLAUDE.md». | `CLAUDE.md`, `.openclaw/agents/*.md` |
-
-### 1.4. Принятая трактовка постановки (расхождения 05.06 ↔ 10.06)
- **Реализация в репо orchestrator** (данный конвейер пишет в этот репо; каноны живут здесь).
-  Упоминание отдельного репо `onboard2orch` (05.06) — историческое: его пример enduro-trails
-  объявлен устаревшим; судьба репо — операторское решение вне кода (рекомендация: архивировать/
-  оставить указатель, чтобы не плодить второй источник канона). Эскалации не требует: актуализация
-  10.06 прямо говорит «каноны кодифицированы в репо орка — их и брать за образец».
- **Раскладка docs/**: слой-1 постановки (05.06) указывал `docs/adr/`; канон орка —
-  `docs/architecture/adr/` (сквозные) + `docs/work-items/<id>/06-adr/` (per-task). Применяется
-  канон орка (эталон = орк).
-
---
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
- **Onboarding-kit**: параметризуемый каркас нового репо — 6 промптов агентов, паспорт
-  `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/`
-  (включая `operations/INFRA.md`), копии `docs/_templates/` + `docs/_standards/`.
- **Onboarding-скрипт** (операторский CLI, вне конвейера): Gitea-репо + per-repo webhook,
-  Plane-проект + статусы + лейблы (в мере, доступной API), материализация kit (подстановка
-  параметров) + initial push в свежесозданный репо, генерация валидной записи реестра, режимы
-  dry-run / apply / verify, идемпотентность.
- **Runbook** `docs/operations/ONBOARDING.md`: полный чеклист, явная маркировка ручных шагов
-  (env + управляемый рестарт; UI-only действия Plane), верификация, откат.
- **Верификация способности**: автоматические структурные тесты kit (pytest) + документированный
-  smoke-прогон на песочнице («агент по своему промпту находит доку, использует и актуализирует»).
- **Актуализация обзорных доков** в том же PR (CLAUDE.md, `docs/architecture/README.md`,
-  CHANGELOG, обобщение `SETUP_WEBHOOKS.md`).
-
-### 2.2. Вне объёма (явно, не делать)
- Исполнение онбординга конкретного нового заказчика/проекта (включая правку прод-`.env` и
-  рестарт прода) — операторская эксплуатация способности.
- ORCH-10 — тиражирование платформы на новый хост (IaC-bundle); мультитенантность (D5.6);
-  параллелизм D5.1.
- Стеки-плагины D4.1 (профили web/mobile/data/ML): kit параметризуется плейсхолдерами, без
-  механизма профилей.
- Любые изменения `src/**`: машина стадий, QG, launcher, реестр `projects.py` (его контракт уже
-  достаточен — регистрация через `ORCH_PROJECTS_JSON`), схема БД.
- Создание/миграция Plane workspace-webhook (уже существует, общий на workspace).
- Слой-3 продуктовый мониторинг онбордируемого приложения (фундамент эпика, отдельные задачи).
-
---
-
-## 3. Заинтересованные стороны
- **Владелец/оператор (Слава, Стрим):** запускает онбординг, выполняет операторские шаги
-  (env, рестарт, UI-шаги Plane), принимает результат smoke-прогона.
- **Будущие заказчики/проекты:** получают рабочий автономный конвейер «за минуты» (D5.2).
- **Действующие проекты (enduro-trails, orchestrator):** не должны почувствовать онбординг
-  соседа — общий прод-инстанс, общая БД, общая очередь (self-hosting, ORCH-1).
- **Агенты конвейера:** потребители kit — промпты обязаны вести их к доке проекта.
-
---
-
-## 4. Бизнес-требования (BR)
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | **Turnkey-проход:** один документированный проход (скрипт + runbook) разворачивает все слои: Plane-проект (статусы+лейблы) → Gitea-репо (+webhook) → kit в репо (initial push) → запись реестра → верификация. Список шагов закрыт и воспроизводим. | AC-1, AC-11 |
-| BR-2 | **Единый эталон без форка:** kit производится от **живых** канонов репо орка — `docs/_templates/`/`docs/_standards/` копируются в новый репо в момент онбординга «как есть»; параметризация — только в kit-собственных шаблонах (промпты, паспорт, INFRA и пр.). Вторая редактируемая копия канона внутри орка не создаётся. enduro-trails эталоном не является. | AC-5, Ф-2/Ф-7 |
-| BR-3 | **Полный набор промптов:** 6 ролей (analyst/architect/developer/reviewer/tester/deployer), параметризуемых под проект/стек, по канону Anthropic 52d: 5 XML-секций в нормативном порядке, запреты «❌ X → ✅ Y», `<escalation>` у developer/reviewer/tester (ORCH-092), добровольная эмиссия 6-польной frontmatter-схемы 52c, machine-verdict ключи байт-в-байт (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`). Каждый промпт жёстко направляет: читай паспорт/`AGENTS.md`/доку ПЕРЕД работой, пиши артефакты в `docs/work-items/<id>/` по канону, обновляй CHANGELOG/доку. | AC-2, AC-4 |
-| BR-4 | **Reviewer-gate на доку:** шаблон reviewer-промпта содержит проверку «документация обновлена; нет → REQUEST_CHANGES» (канон держится автоматически, не на честном слове). | AC-3 |
-| BR-5 | **Каркас репо полон:** `README.md`, `CHANGELOG.md`, `CONTRIBUTING.md`, `AGENTS.md` (точка входа агентов: карта доков + правила), паспорт `CLAUDE.md`, `docs/` (архитектура, конвейер, продукт-видение, `operations/`, ADR-реестр, `work-items/`, `history/`), копии `_templates/`+`_standards/`. Ссылочная целостность: промпты ссылаются только на реально существующие в каркасе пути. | AC-1, AC-5 |
-| BR-6 | **INFRA.md обязателен:** топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env-переменных (дескрипторы в репо, секреты только в `.env` на хосте, `.env.example` — канон), границы доступа, риски общего хоста. Для самого орка существующие self-hosting-предупреждения (общая БД/очередь/groupwide-риск рестарта) сохраняются нетронутыми. | AC-10 |
-| BR-7 | **Plane-проект под машинные контракты:** статусы с **точными** каноническими именами (все 22 имени `_PLANE_NAME_TO_KEY`, включая `Confirm Deploy` и `STOP` с группой `cancelled`) + лейблы `autoApprove`/`autoDeploy`/`Bug`. Что недоступно через Plane API — явный ручной пункт runbook с командой проверки. | AC-7, Ф-4/Ф-5 |
-| BR-8 | **Регистрация в реестре:** скрипт генерирует запись `ORCH_PROJECTS_JSON`, валидную через фактический парсер `projects._parse_projects_json` (round-trip). Применение env + рестарт — **операторский** шаг, явно описанный в runbook; скрипт прод-контейнер НЕ рестартит. | AC-6, AC-9, Ф-3 |
-| BR-9 | **Безопасность исполнения:** dry-run по умолчанию / явный apply; идемпотентный повторный прогон (доделывает недостающее, не дублирует, ничего не удаляет); аддитивность — существующие проекты/репо не модифицируются; push — только initial в свежесозданный пустой репо (никогда в `main` существующих). | AC-8, AC-9 |
-| BR-10 | **Верификация способности:** (а) автоматические структурные тесты kit/скрипта (pytest, без сети); (б) verify-режим: registry-валидность, резолв статусов, наличие webhook, полнота kit; (в) документированный smoke на песочнице: новый агент по своему промпту находит доку, использует и актуализирует её. | AC-12, AC-13 |
-| BR-11 | **Прозрачность:** каждый шаг скрипта логируется; итоговый отчёт «создано / уже было (пропущено) / требует ручного шага». | AC-8 |
-
---
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **`src/**` не меняется.** Изменение — docs/templates/scripts/tests-only. `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД, контракт `projects.py` — байт-в-байт. |
-| NFR-2 | **Self-hosting безопасность:** скрипт никогда не рестартит/не останавливает прод-контейнер, не пишет в общую БД, не пушит в `main` существующих репо, не трогает чужие Plane-проекты/Gitea-репо. Онбординг соседа не влияет на enduro/orchestrator. |
-| NFR-3 | **Секреты:** токены Plane/Gitea — только из env на хосте; сгенерированные секреты (webhook HMAC) выводятся оператору для `.env` и в гит не попадают; `.env.example` — канон. |
-| NFR-4 | **Anti-drift:** структурные тесты канона для kit-промптов (аналог `tests/test_agent_prompts_canon.py`) — расхождение kit с каноном 52d ловится CI, а не глазами. |
-| NFR-5 | **Оффлайн-тестируемость:** все тесты детерминированы, без реальных вызовов Plane/Gitea (моки); сетевые шаги изолированы за тонким слоем. |
-| NFR-6 | **Документация = golden source:** CLAUDE.md / `docs/architecture/README.md` / CHANGELOG обновлены в том же PR; reviewer-gate применим к самому PR. |
-
---
-
-## 6. Допущения и ограничения
- Plane API v1 позволяет создавать проект/статусы/лейблы (issue-API уже используется кодом);
-  если на практике какой-то вызов недоступен в CE — шаг деградирует в ручной пункт runbook
-  (fail-safe постановки, не блокер задачи).
- Скрипт — операторский инструмент: запускается человеком на хосте с токенами из `.env`,
-  **вне** конвейера задач; конвейер его не вызывает.
- Регистрация проекта вступает в силу после операторского рестарта (Ф-3) — это сознательное
-  ограничение (никакой автоматики рестартов, NFR-2); TTL-self-heal статусов (Ф-4) рестарта
-  не требует.
- Песочница для smoke — staging-контур (8501, изолированная БД, sandbox-проект) либо одноразовый
-  sandbox-проект в Plane/Gitea; выбор фиксирует архитектор/оператор в runbook.
- Языковая политика kit-промптов: по канону орка (5 ru + deployer en, ADR-001 D2 ORCH-092);
-  окончательное слово за архитектором, отступление — только с обоснованием в ADR.
-
---
-
-## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
- Kit полон и канон-чист (структурные тесты зелёные): 6 промптов 52d + reviewer-gate + каркас
-  репо + INFRA.md + копии канонов.
- Скрипт: dry-run печатает полный план без мутаций; apply идемпотентен; registry-запись проходит
-  round-trip через фактический парсер; план Plane содержит точные имена статусов и лейблы.
- Runbook закрывает 100% шагов (ручные — помечены) и верификацию.
- `src/**` не тронут; пайплайн-инварианты байт-в-байт.
- Smoke на песочнице: агент по промпту находит и актуализирует доку (документированный прогон).
-
---
-
-## 8. Риски (кратко; детали — 10-tech-risks.md, заполняет архитектор)
- **R-1 Drift канона:** копия канонов в kit/новых репо разъезжается с живым каноном орка →
-  митигируется BR-2 (live-copy в момент онбординга) + NFR-4 (структурные тесты).
- **R-2 Тихая деградация Plane-контрактов:** опечатка в имени статуса/лейбла → fail-closed/
-  fail-safe ветки молча не работают → митигируется BR-7 (точные имена из кода) + verify-режимом.
- **R-3 Скрипт с боевыми токенами:** ошибка = разрушительное действие → dry-run по умолчанию,
-  никаких delete-операций, аддитивность (BR-9).
- **R-4 «Скрипт сделал — оператор не знает про env+restart»:** проект создан, но невидим для
-  оркестратора → runbook явно фиксирует операторские шаги + verify-режим показывает разрыв (BR-8/10).
- **R-5 Утечка орк-специфики в kit:** новый проект получает чужие литералы (ORCH-, порты 8500/8501,
-  self-hosting-правила) → структурный тест на остаточные плейсхолдеры/литералы (AC-5).
--- a/docs/work-items/ORCH-009/02-trz.md
+++ b/docs/work-items/ORCH-009/02-trz.md
@@ -1,227 +0,0 @@
---
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# 02 — ТЗ (TRZ): ORCH-009 — Онбординг проектов в оркестратор (turnkey)
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты). **Как** (точная
-> раскладка kit, механизм подстановки, формат CLI) — решает архитектор в `06-adr/`. Имена путей
-> ниже — рабочее предложение; архитектор вправе скорректировать, сохранив требования и AC.
-
-> ⚠️ Скоуп по актуализации 10.06: эталон = репо orchestrator; deliverables — в этом репо.
-> `src/**` НЕ меняется (NFR-1) — задача docs/templates/scripts/tests-only.
-
---
-
-## 1. Сводка изменения
-Создать **способность turnkey-онбординга** нового проекта: (1) параметризуемый **onboarding-kit**
-(каркас нового репо: 6 промптов агентов по канону 52d/92, паспорт, AGENTS/CONTRIBUTING, скелет
-`docs/` с INFRA.md, копии живых канонов `_templates/`+`_standards/`); (2) операторский
-**onboarding-скрипт** (Gitea-репо + per-repo webhook; Plane-проект + статусы + лейблы;
-материализация kit + initial push; генерация записи реестра; dry-run/apply/verify; идемпотентно);
-(3) **runbook** `docs/operations/ONBOARDING.md` (полный чеклист, ручные шаги, верификация);
-(4) **структурные тесты** анти-дрейфа. Конвейер/движок не трогаются.
-
---
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие | Роль |
-|------|----------|------|
-| `onboarding/repo-skeleton/**` | создать | параметризуемый kit нового репо (дерево зеркалит целевой репо: `.openclaw/agents/*.md`, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/**`) |
-| `onboarding/README.md` | создать | устройство kit: словарь плейсхолдеров, правило «канон не форкается» (что копируется live, что шаблонизируется) |
-| `scripts/onboard_project.py` | создать | операторский turnkey-CLI: `plan` (dry-run, дефолт) / `apply` / `verify`; идемпотентность; отчёт |
-| `docs/operations/ONBOARDING.md` | создать | runbook: последовательность, ручные шаги (env+рестарт, UI-only Plane), верификация, откат |
-| `docs/operations/SETUP_WEBHOOKS.md` | обновить | обобщить per-repo Gitea-webhook секцию (сейчас примеры захардкожены на enduro-trails); сослаться на ONBOARDING.md |
-| `tests/test_onboarding_kit.py` | создать | структура kit, канон промптов, reviewer-gate, INFRA/AGENTS/CONTRIBUTING |
-| `tests/test_onboarding_script.py` | создать | рендер/плейсхолдеры, registry round-trip, dry-run/идемпотентность, план Plane/Gitea (моки) |
-| `tests/test_onboarding_invariants.py` | создать | `src/**` не тронут логикой онбординга; снапшот `STAGE_TRANSITIONS`/`QG_CHECKS` |
-| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | обновить | golden source: раздел «Онбординг проектов (ORCH-009)», запись changelog |
-| `src/**` | **не менять** | NFR-1; скрипту разрешён **read-only import** `src.projects._parse_projects_json` / констант `src.plane_sync._PLANE_NAME_TO_KEY` для round-trip и точных имён (не дублировать литералы) — допустимость импорта vs снапшот-фикстура решает архитектор |
-
-Справочные источники kit (read-only): `.openclaw/agents/*.md`, `docs/_templates/` (16 скелетов),
-`docs/_standards/` (3 стандарта), `docs/operations/INFRA.md` (образец структуры RUNBOOK).
-
---
-
-## 3. Функциональные требования
-
-### FR-1 — Onboarding-kit: состав каркаса нового репо (BR-3/BR-5/BR-6)
-`onboarding/repo-skeleton/` содержит (минимум):
-
-```
-.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md   ← шаблоны промптов
-CLAUDE.md            ← паспорт проекта (per-repo канон, Ф-8)
-AGENTS.md            ← точка входа агентов: карта доков + правила ведения
-CONTRIBUTING.md      ← канон процесса: где что лежит, как вести
-README.md            ← entrypoint: что это, quickstart, ссылки
-CHANGELOG.md         ← пустой каркас
-docs/ARCHITECTURE.md         ← код-карта/потоки/БД (заполняется по мере жизни)
-docs/PIPELINE.md             ← стадии, QG, агенты (ссылается на _standards)
-docs/PRODUCT_VISION.md       ← зачем проект (BRD-свод)
-docs/operations/INFRA.md     ← обязательный RUNBOOK (см. FR-3)
-docs/architecture/adr/       ← реестр сквозных ADR (канон орка, §1.4 BRD)
-docs/work-items/.gitkeep
-docs/history/.gitkeep
-docs/_templates/   ← live-копия канона орка в момент онбординга (BR-2)
-docs/_standards/   ← live-копия канона орка в момент онбординга (BR-2)
-.env.example       ← заготовка карты env (без секретов)
-```
-
- **Параметризация** — единый словарь плейсхолдеров (минимум): `{{PROJECT_NAME}}`, `{{REPO}}`,
-  `{{WORK_ITEM_PREFIX}}`, `{{PLANE_PROJECT_ID}}`, `{{STACK}}`, `{{TEST_CMD}}`,
-  `{{PROD_PORT}}`/`{{STAGING_PORT}}` (расширяемо; единый синтаксис, фиксирует архитектор).
- **Ссылочная целостность:** каждый путь, на который ссылаются kit-промпты/AGENTS.md, существует
-  в каркасе (проверяемо тестом).
- **Правило «канон не форкается» (BR-2):** `docs/_templates/` и `docs/_standards/` НЕ хранятся
-  второй редактируемой копией в kit — копируются скриптом из живого канона репо орка в момент
-  материализации. В kit хранятся только параметризуемые дельты (промпты, паспорт, AGENTS,
-  CONTRIBUTING, README, INFRA и пр.).
-
-### FR-2 — Шаблоны промптов 6 ролей по канону 52d/92 (BR-3/BR-4)
-Каждый из 6 шаблонов промптов:
- 5 обязательных XML-секций в нормативном порядке `<context>` → `<task>` → `<deliverables>` →
-  `<constraints>` → `<output_format>`; `<success_criteria>`; `<escalation>` у
-  developer/reviewer/tester (после `</success_criteria>`); `<thinking>` у решающих ролей —
-  как в эталоне `.openclaw/agents/` (ORCH-077/092).
- Запреты в формате «❌ X → ✅ Y».
- Директивы доки (жёстко): читай `CLAUDE.md`(паспорт)/`AGENTS.md`/`docs/ARCHITECTURE.md`/ADR
-  ПЕРЕД работой; пиши артефакты в `docs/work-items/<id>/` по `docs/_standards/PIPELINE_DOCS.md`
-  (скелеты из `docs/_templates/`); архитектор фиксирует решения в `06-adr/` + сквозные в
-  `docs/architecture/adr/adr-NNNN-slug.md`; каждый обновляет `CHANGELOG.md`/релевантную доку.
- **Reviewer:** содержит gate «документация обновлена? нет → `verdict: REQUEST_CHANGES`».
- Эмиссия 6-польной frontmatter-схемы 52c (`work_item`/`stage`/`author_agent`/`status`/
-  `created_at`/`model_used`) — аддитивно; machine-verdict ключи и значения байт-в-байт
-  (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`); копируемые
-  примеры — с плейсхолдерами `<YYYY-MM-DD>`/`<resolve по конфигу>` (анти-паттерн ORCH-092 учтён).
- Стек-специфика (язык/тесты/команды) — только через плейсхолдеры; никаких унаследованных
-  орк-литералов (порты 8500/8501, «ORCH-», self-hosting-правила орка) в материализованном виде.
- Языковая политика: по канону орка (5 ru + deployer en, нормативно ADR-001 D2 ORCH-092);
-  отступление — только решением архитектора в ADR.
-
-### FR-3 — INFRA.md шаблон: обязательные секции (BR-6)
-Шаблон `docs/operations/INFRA.md` нового проекта содержит секции: топология (контейнеры, порты
-прод/staging, сеть, тома, БД); карта env-переменных (дескрипторы в репо; секреты ТОЛЬКО в `.env`
-на хосте; `.env.example` — канон; `docker-compose.yml`/`Dockerfile` трекаются в гите); границы
-доступа; эксплуатационные предупреждения, включая **риски общего хоста** (соседние контейнеры,
-общие ресурсы; факт: хост впритык — см. `docs/epics/self-evolution.md` С-3). Существующий
-`docs/operations/INFRA.md` орка с self-hosting-предупреждениями (общая БД/очередь/групповой риск
-рестарта) — не модифицируется этой задачей (read-only образец).
-
-### FR-4 — Onboarding-скрипт: провижининг (BR-1/BR-7/BR-9/BR-11)
-`scripts/onboard_project.py` (вход: имя проекта, repo, префикс work-item, параметры стека):
- **Gitea:** создать репо (API), создать per-repo webhook (`push`/`pull_request`/`status`,
-  HMAC-secret из/для `.env` — формат `SETUP_WEBHOOKS.md`); материализовать kit → **initial push
-  в свежесозданный пустой репо** (единственный разрешённый push; в существующие репо — никогда).
- **Plane:** создать проект (или принять существующий `--plane-project-id`); создать статусы со
-  **точными** именами из `_PLANE_NAME_TO_KEY` (22 имени; `STOP` — группа `cancelled`,
-  `Confirm Deploy` — отдельный статус; группы фиксирует архитектор по `plane_sync`) и лейблы
-  `autoApprove`/`autoDeploy`/`Bug`. Недоступное через API CE → пункт отчёта «ручной шаг» со
-  ссылкой на runbook (fail-safe, не падение).
- **Реестр:** сгенерировать запись `ORCH_PROJECTS_JSON` (полный новый массив или диф —
-  фиксирует архитектор), **валидную через фактический `projects._parse_projects_json`**;
-  вывести оператору инструкцию «добавь в `.env` + управляемый рестарт». Скрипт сам `.env` прода
-  не правит и контейнер не рестартит (NFR-2).
- **Режимы:** `plan` (дефолт; полный план без единой мутации), `apply` (исполнение),
-  `verify` (см. FR-5). Идемпотентность: повторный `apply` обнаруживает существующее
-  (репо/webhook/статусы/лейблы/файлы) и пропускает с пометкой; ничего не удаляет и не
-  перезаписывает существующий контент без явного флага.
- **Прозрачность:** лог каждого шага + итоговый отчёт: `created / skipped(exists) / manual-step`.
- **Webhook Plane:** не создаётся (workspace-level уже существует, Ф-6) — только проверка в verify.
-
-### FR-5 — Верификация (BR-10)
- `verify`-режим скрипта: запись реестра парсится (`_parse_projects_json` round-trip → поля
-  совпадают); статусы проекта резолвятся (все логические ключи, включая `confirm_deploy`/`stop`);
-  лейблы присутствуют; Gitea-webhook существует и активен; kit-файлы в репо (включая 6 промптов,
-  AGENTS.md, INFRA.md, `_templates`/`_standards`); нет неразрешённых плейсхолдеров.
- **Smoke на песочнице** (runbook, операторский): онбордить sandbox-проект → создать тестовую
-  задачу → стадия analysis в песочнице → убедиться: агент прочитал доку проекта (следы в
-  выводе/артефактах) и записал артефакты в `docs/work-items/<id>/` по канону. Контур песочницы
-  (staging 8501 / одноразовый sandbox) фиксирует архитектор в ADR + runbook.
-
-### FR-6 — Runbook ONBOARDING.md (BR-1/BR-8)
-Полный чеклист онбординга: предусловия (токены, доступы) → шаги скрипта → **операторские шаги**
-(env+рестарт — с предупреждением self-hosting: рестарт прода = групповое окно, выполнять
-осознанно; UI-only шаги Plane, напр. drag-and-drop порядок статусов) → верификация (verify +
-smoke) → откат (удаление созданного — вручную, скрипт не удаляет). Каждый ручной шаг — с командой
-проверки результата.
-
---
-
-## 4. Изменения API
-**Нет.** Новые/изменённые HTTP-эндпоинты оркестратора не вводятся; вебхук-контракты не меняются.
-(Onboarding-CLI — операторский инструмент вне FastAPI-приложения.)
-
-## 5. Изменения схемы БД
-**Нет.** Общая БД не читается и не пишется скриптом (NFR-2).
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Реестр `QG_CHECKS`/`check_*`/`STAGE_TRANSITIONS` — байт-в-байт (контроль — снапшот-тест,
-TC-18). Онбординг — операторская способность, не гейт конвейера.
-
---
-
-## 7. Совместимость / регресс
- **Нулевая регрессия кода:** `src/**` не меняется → поведение конвейера для enduro/orchestrator
-  идентично; полный регресс `tests/` остаётся зелёным.
- **Kill-switch не требуется:** способность активируется только явным запуском операторского CLI;
-  в горячих путях конвейера нового кода нет.
- **Обратимость:** удаление `onboarding/`/`scripts/onboard_project.py`/runbook возвращает репо в
-  исходное состояние; созданные онбордингом внешние сущности сносятся вручную по разделу
-  «Откат» runbook.
- **Совместимость канонов:** kit-промпты проходят те же структурные требования, что эталонные
-  (анти-дрейф NFR-4); обновление канона орка автоматически подхватывается live-copy частью kit
-  (BR-2), шаблонные дельты — через обычные PR с reviewer-gate.
-
---
-
-## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
- `docs/work-items/ORCH-009/06-adr/ADR-001-…` — решения архитектора (раскладка kit, синтаксис
-  плейсхолдеров, copy-vs-template split по файлам, импорт `src` из скрипта vs снапшот, контур
-  песочницы, языковая политика kit-deployer).
- `docs/architecture/README.md` — раздел «Онбординг проектов (ORCH-009)».
- `CLAUDE.md` — краткий абзац о способности онбординга.
- `CHANGELOG.md` — запись `feat:`.
- `docs/operations/ONBOARDING.md` (новый), `docs/operations/SETUP_WEBHOOKS.md` (обобщение).
- `07-infra-requirements.md` — предусловия онбординга (токены/доступы), заполняет архитектор.
-
---
-
-## 9. Инварианты (не нарушать)
- `src/**` без изменений; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема
-  БД — байт-в-байт (NFR-1).
- Скрипт: не рестартит/не останавливает прод-контейнер; не пушит в `main` существующих репо
-  (INV-4 — мерж только через PR-merge API — не затрагивается: initial push идёт в свежесозданный
-  пустой репо, не являющийся участником конвейера до регистрации); не удаляет внешние сущности;
-  секреты в гит не попадают (NFR-2/NFR-3).
- Никаких сетевых вызовов в тестах (NFR-5); никаких новых обязательных pip-зависимостей без
-  обоснования в ADR.
- Эталонные промпты орка `.openclaw/agents/*.md` этой задачей не модифицируются (они — read-only
-  образец; их правка = отдельные задачи канона).
-
---
-
-## 10. Открытые вопросы для архитектора (не блокируют анализ)
- OQ-1: Раскладка kit — `onboarding/repo-skeleton/` (предложение) vs `docs/_onboarding/` vs
-  `scripts/onboarding/`; где словарь плейсхолдеров.
- OQ-2: Механизм подстановки — stdlib (`str.replace`/`string.Template`) без новых зависимостей
-  (рекомендация) vs шаблонизатор (новая зависимость — потребует обоснования).
- OQ-3: Copy-vs-template split: какие файлы kit — live-copy канона, какие — параметризуемые
-  шаблоны (минимум по BR-2: `_templates`/`_standards` — live-copy).
- OQ-4: Скрипту импортировать `src.projects`/`src.plane_sync` (точные имена/парсер, нет
-  дублирования) vs автономный снапшот констант с тестом синхронизации.
- OQ-5: Plane API CE: фактическая доступность создания проекта/статусов/лейблов — что уходит в
-  ручные шаги runbook.
- OQ-6: Контур песочницы для smoke (staging 8501 vs одноразовый sandbox-проект) и судьба
-  sandbox-артефактов после прогона.
- OQ-7: Языковая политика kit-промптов для не-self-hosting проектов (рекомендация: канон орка,
-  deployer — en).
- OQ-8: Защита `main` нового репо в Gitea (branch protection): не должна ломать PR-merge API
-  конвейера — включать ли вообще (рекомендация: не включать, зафиксировать в runbook).
--- a/docs/work-items/ORCH-009/03-acceptance-criteria.md
+++ b/docs/work-items/ORCH-009/03-acceptance-criteria.md
@@ -1,146 +0,0 @@
---
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий — чёткое условие **PASS/FAIL**, проверяемое буквально по файлам
-репозитория и детерминированным тестам (без сети). AC-13 — единственный операторский
-(документированный smoke), его автоматизируемая часть вынесена в AC-2/AC-12.
-
---
-
-## AC-1 — Kit полон (состав каркаса)
-**Условие:** инспекция `onboarding/repo-skeleton/` (или каталога, выбранного архитектором в ADR).
- **PASS:** присутствуют все элементы FR-1: 6 шаблонов промптов (`analyst/architect/developer/
-  reviewer/tester/deployer`), `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`,
-  `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`,
-  `docs/operations/INFRA.md`, `docs/architecture/adr/`, `docs/work-items/`, `docs/history/`,
-  `.env.example`; материализация добавляет live-копии `docs/_templates/` + `docs/_standards/`.
- **FAIL:** отсутствует любой элемент состава, либо промптов меньше 6.
-
-## AC-2 — Промпты kit соответствуют канону 52d/92
-**Условие:** структурные тесты по каждому из 6 шаблонов промптов.
- **PASS:** в каждом — 5 обязательных XML-секций в нормативном порядке `<context>→<task>→
-  <deliverables>→<constraints>→<output_format>`; запреты в формате «❌ → ✅»; `<escalation>` у
-  developer/reviewer/tester; директивы «читай паспорт/AGENTS.md/доку ПЕРЕД работой» и «пиши
-  артефакты в `docs/work-items/<id>/`»; эмиссия 6-польной frontmatter-схемы 52c с
-  плейсхолдерными примерами дат/моделей; machine-verdict ключи у ролей-вердиктов байт-в-байт
-  (`verdict:` / `result:` / `staging_status:` / `deploy_status:` / `security_status:`).
- **FAIL:** нарушен порядок/состав секций, отсутствует любой verdict-ключ или директива доки,
-  пример frontmatter содержит захардкоженные дату/модель.
-
-## AC-3 — Reviewer-gate на обновление доки
-**Условие:** шаблон `reviewer.md` в kit.
- **PASS:** содержит явное правило: документация (CHANGELOG/релевантные доки/ADR) обновлена в том
-  же PR; нет → `verdict: REQUEST_CHANGES`.
- **FAIL:** правило отсутствует или сформулировано как необязательное.
-
-## AC-4 — Языковая политика kit
-**Условие:** проверка языка шаблонов промптов против решения ADR (дефолт — канон орка).
- **PASS:** языковая раскладка соответствует зафиксированной в ADR (по умолчанию: 5 ru +
-  deployer en, как ADR-001 D2 ORCH-092); отступление — только с обоснованием в ADR.
- **FAIL:** язык промптов противоречит ADR, либо политика нигде не зафиксирована.
-
-## AC-5 — Материализация: плейсхолдеры и отсутствие утечек
-**Условие:** рендер kit с тестовыми параметрами (`PROJECT_NAME`, `REPO`, `WORK_ITEM_PREFIX` и т.д.).
- **PASS:** все плейсхолдеры подставлены; в результате нет ни одного неразрешённого плейсхолдера
-  (grep по синтаксису из ADR); нет утечек орк-специфики, где должен быть параметр (литералы
-  `ORCH-` как префикс work-item чужого проекта, порты 8500/8501, self-hosting-правила орка);
-  пути, на которые ссылаются отрендеренные промпты/AGENTS.md, существуют в каркасе.
- **FAIL:** найден неразрешённый плейсхолдер, орк-литерал вместо параметра или битая ссылка
-  на несуществующий путь.
-
-## AC-6 — Registry round-trip через фактический парсер
-**Условие:** скрипт генерирует запись реестра для тестового проекта.
- **PASS:** сгенерированный JSON парсится `projects._parse_projects_json` без ошибок; полученный
-  `ProjectConfig` несёт исходные `plane_project_id`/`repo`/`work_item_prefix`/`name`; существующие
-  записи реестра не модифицируются и не теряются.
- **FAIL:** парсер отвергает запись, поля искажены, либо генерация ломает/теряет существующие записи.
-
-## AC-7 — План Plane: точные статусы и лейблы
-**Условие:** `plan`-режим для нового проекта (моки сети).
- **PASS:** план провижининга содержит ВСЕ канонические имена статусов из `_PLANE_NAME_TO_KEY`
-  (включая `Confirm Deploy` и `STOP` с группой `cancelled`) и лейблы `autoApprove`/`autoDeploy`/
-  `Bug`; имена байт-в-байт совпадают с константами `src/plane_sync.py` (или их синхронизированным
-  снапшотом по OQ-4); недоступные через API шаги помечены `manual-step` со ссылкой на runbook.
- **FAIL:** пропущен/искажён любой статус или лейбл; недоступный шаг молча отброшен.
-
-## AC-8 — План Gitea: репо + per-repo webhook; dry-run без мутаций
-**Условие:** `plan`-режим (моки сети).
- **PASS:** план содержит создание репо, создание webhook с events `push`/`pull_request`/`status`
-  и HMAC-secret (секрет — для `.env` оператора, не в гит), материализацию kit + initial push в
-  свежесозданный репо; в режиме `plan` не выполняется НИ ОДНОЙ мутации (ни одного
-  POST/PUT/DELETE-вызова в моках, ни одной записи на диск вне отчёта).
- **FAIL:** план неполон, или dry-run произвёл мутацию.
-
-## AC-9 — Идемпотентность и безопасность apply
-**Условие:** повторный `apply` на частично/полностью созданном проекте (моки: сущности существуют).
- **PASS:** существующие сущности (репо/webhook/статусы/лейблы/файлы) распознаны и пропущены с
-  пометкой `skipped(exists)`; ничего не удалено и не перезаписано без явного флага; скрипт не
-  выполняет рестарт/останов контейнеров, не правит `.env` прода, не пушит в существующие репо
-  (в коде отсутствуют такие операции — проверяемо тестом/ревью); итоговый отчёт перечисляет
-  created/skipped/manual-step.
- **FAIL:** дублирование сущностей, любое удаление/перезапись без флага, любая операция
-  рестарта/push в существующий репо, отсутствие отчёта.
-
-## AC-10 — INFRA.md шаблон: обязательные секции
-**Условие:** инспекция шаблона `docs/operations/INFRA.md` в kit.
- **PASS:** присутствуют секции: топология (контейнеры/порты прод+staging/сеть/тома/БД);
-  карта env-переменных + правило секретов (только `.env` на хосте, `.env.example` — канон);
-  границы доступа; предупреждения о рисках общего хоста. Существующий `docs/operations/INFRA.md`
-  орка (self-hosting-предупреждения) этой задачей не изменён.
- **FAIL:** отсутствует любая обязательная секция, либо изменён INFRA.md самого орка.
-
-## AC-11 — Runbook ONBOARDING.md полон
-**Условие:** инспекция `docs/operations/ONBOARDING.md`.
- **PASS:** покрывает все слои BR-1 в последовательности: предусловия (токены/доступы) → Plane
-  (проект/статусы/лейблы) → Gitea (репо/webhook) → kit (материализация/push) → регистрация
-  (env-строка + операторский управляемый рестарт с self-hosting-предупреждением) → верификация
-  (`verify` + smoke на песочнице) → откат; каждый ручной шаг помечен и снабжён командой проверки;
-  Plane workspace-webhook описан как существующий (проверка, не создание).
- **FAIL:** пропущен слой, ручной шаг не помечен/без проверки, или runbook требует
-  автоматического рестарта прода.
-
-## AC-12 — Инварианты: src/** не тронут
-**Условие:** diff PR + снапшот-тест.
- **PASS:** `git diff` PR не содержит изменений `src/**`; снапшот `STAGE_TRANSITIONS` и реестра
-  `QG_CHECKS` совпадает с эталоном; эталонные промпты `.openclaw/agents/*.md` орка не изменены;
-  полный регресс `tests/` зелёный.
- **FAIL:** любой diff в `src/**` или `.openclaw/agents/`, расхождение снапшота, красный регресс.
-
-## AC-13 — Smoke: агент находит, использует и актуализирует доку (операторский)
-**Условие:** документированный прогон по runbook на песочнице (контур — по ADR): онбординг
-sandbox-проекта → тестовая задача → стадия analysis.
- **PASS:** агент песочницы по своему промпту прочитал доку проекта (следы чтения паспорта/
-  AGENTS.md в выводе или артефактах) и записал артефакты в `docs/work-items/<id>/` по канону
-  (структура соответствует `PIPELINE_DOCS.md`); результат прогона зафиксирован в runbook/отчёте
-  задачи. Для приёмки данной задачи прогон выполняется один раз и протоколируется.
- **FAIL:** агент не нашёл доку (артефакты вне канона/не созданы), либо прогон не запротоколирован.
-
---
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | BR | FR | Тип проверки |
-|----|----|----|--------------|
-| AC-1 | BR-5 | FR-1 | unit (структура kit) |
-| AC-2 | BR-3 | FR-2 | unit (структурный канон) |
-| AC-3 | BR-4 | FR-2 | unit |
-| AC-4 | BR-3 | FR-2 | unit + ADR |
-| AC-5 | BR-2/BR-5 | FR-1/FR-2 | unit (рендер) |
-| AC-6 | BR-8 | FR-4 | integration (реальный парсер) |
-| AC-7 | BR-7 | FR-4 | unit (план, моки) |
-| AC-8 | BR-1/BR-9 | FR-4 | unit (план, моки) |
-| AC-9 | BR-9/BR-11 | FR-4 | unit/integration (моки) |
-| AC-10 | BR-6 | FR-3 | unit (структура) |
-| AC-11 | BR-1/BR-8 | FR-6 | unit (структура дока) |
-| AC-12 | NFR-1 | — | unit (снапшот) + ревью diff |
-| AC-13 | BR-10 | FR-5 | ручной smoke (протоколируемый) |
--- a/docs/work-items/ORCH-009/04-test-plan.yaml
+++ b/docs/work-items/ORCH-009/04-test-plan.yaml
@@ -1,164 +0,0 @@
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Turnkey-онбординг проектов: kit + скрипт + runbook (ORCH-009)"
-framework: pytest
-scope: >
-  Структурная полнота onboarding-kit, канон 52d/92 шаблонов промптов, материализация
-  (плейсхолдеры/утечки), registry round-trip через фактический парсер projects.py,
-  планы Plane/Gitea (dry-run, моки), идемпотентность apply, runbook, инварианты src/**.
-  Вне покрытия pytest: реальные вызовы Plane/Gitea API и операторский smoke на песочнице
-  (AC-13) — выполняется вручную по docs/operations/ONBOARDING.md и протоколируется.
-notes: >
-  Все тесты детерминированы, без сети (Plane/Gitea мокируются; NFR-5). Точные имена файлов
-  тест-модулей могут уточняться архитектором при сохранении покрытия TC↔AC. Полный регресс
-  tests/ должен оставаться зелёным (src/** не меняется — NFR-1). Если ADR изменит раскладку
-  kit (OQ-1) — пути в тестах следуют ADR, маппинг TC↔AC неизменен.
-
-tests:
-  # ---------- AC-1: состав kit ----------
-  - id: TC-01
-    type: unit
-    description: "Kit содержит все элементы FR-1: 6 шаблонов промптов, CLAUDE.md, AGENTS.md, CONTRIBUTING.md, README.md, CHANGELOG.md, docs/ARCHITECTURE.md, docs/PIPELINE.md, docs/PRODUCT_VISION.md, docs/operations/INFRA.md, docs/architecture/adr/, docs/work-items/, docs/history/, .env.example"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Материализация добавляет live-копии docs/_templates/ (16 канонических скелетов) и docs/_standards/ (3 стандарта) из живого канона репо орка; вторая редактируемая копия канона в kit отсутствует (BR-2)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-2: канон промптов 52d/92 ----------
-  - id: TC-03
-    type: unit
-    description: "Каждый из 6 шаблонов промптов содержит 5 обязательных XML-секций в нормативном порядке context→task→deliverables→constraints→output_format"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Шаблоны developer/reviewer/tester содержат секцию <escalation>; запреты оформлены в формате '❌ → ✅'"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Каждый шаблон промпта направляет агента к доке: читай паспорт(CLAUDE.md)/AGENTS.md/ARCHITECTURE/ADR перед работой; пиши артефакты в docs/work-items/<id>/ по PIPELINE_DOCS; обновляй CHANGELOG/доку"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Шаблоны эмитят 6-польную frontmatter-схему 52c (work_item/stage/author_agent/status/created_at/model_used); machine-verdict ключи ролей байт-в-байт (verdict:/result:/staging_status:/deploy_status:/security_status:); примеры дат/моделей — плейсхолдеры, не литералы (анти-паттерн ORCH-092)"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-3: reviewer-gate ----------
-  - id: TC-07
-    type: unit
-    description: "Шаблон reviewer.md содержит обязательный gate: документация не обновлена в PR → verdict: REQUEST_CHANGES"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-4: языковая политика ----------
-  - id: TC-08
-    type: unit
-    description: "Языковая раскладка шаблонов соответствует политике ADR (дефолт: 5 ru + deployer en, канон ADR-001 D2 ORCH-092)"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-5: материализация ----------
-  - id: TC-09
-    type: unit
-    description: "Рендер kit с тестовыми параметрами подставляет все плейсхолдеры: в выходе нет ни одного неразрешённого плейсхолдера (grep по синтаксису из ADR)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "В отрендеренном kit нет утечек орк-специфики, где должен быть параметр: префикс ORCH- вместо префикса проекта, порты 8500/8501, self-hosting-правила орка"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Ссылочная целостность: каждый путь, на который ссылаются отрендеренные промпты и AGENTS.md, существует в материализованном каркасе"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-6: registry round-trip ----------
-  - id: TC-12
-    type: integration
-    description: "Сгенерированная скриптом запись реестра парсится фактическим projects._parse_projects_json; ProjectConfig несёт исходные plane_project_id/repo/work_item_prefix/name; существующие записи реестра сохранены без искажений"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-7: план Plane ----------
-  - id: TC-13
-    type: unit
-    description: "plan-режим: план Plane содержит все канонические имена статусов _PLANE_NAME_TO_KEY (включая 'Confirm Deploy' и 'STOP' с группой cancelled) байт-в-байт и лейблы autoApprove/autoDeploy/Bug"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-14
-    type: unit
-    description: "Шаг Plane, недоступный через API (мок отвечает отказом/не реализовано), помечается в плане/отчёте как manual-step со ссылкой на runbook — не отбрасывается молча и не валит скрипт"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-8: план Gitea + dry-run ----------
-  - id: TC-15
-    type: unit
-    description: "plan-режим: план Gitea содержит создание репо, webhook (events push/pull_request/status + HMAC-secret вне гита) и initial push kit в свежесозданный репо"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-16
-    type: unit
-    description: "dry-run (plan) не выполняет ни одной мутации: ноль POST/PUT/DELETE в замоканных клиентах Plane/Gitea, ноль git push, ноль записей на диск вне отчёта"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-9: идемпотентность / безопасность apply ----------
-  - id: TC-17
-    type: integration
-    description: "Повторный apply на уже созданном проекте (моки: репо/webhook/статусы/лейблы существуют): сущности распознаны и помечены skipped(exists); нет дублей, удалений и перезаписи без явного флага; итоговый отчёт перечисляет created/skipped/manual-step"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-18
-    type: unit
-    description: "Скрипт не содержит операций рестарта/останова контейнеров, правки прод-.env и push в существующие репо: на моках полного прогона apply такие вызовы отсутствуют (NFR-2)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-10: INFRA.md шаблон ----------
-  - id: TC-19
-    type: unit
-    description: "Шаблон INFRA.md kit содержит обязательные секции: топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env + правило секретов (.env на хосте, .env.example — канон), границы доступа, риски общего хоста"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-11: runbook ----------
-  - id: TC-20
-    type: unit
-    description: "ONBOARDING.md покрывает все слои в последовательности: предусловия → Plane → Gitea → kit → регистрация (env + операторский управляемый рестарт с self-hosting-предупреждением) → верификация (verify + smoke) → откат; ручные шаги помечены и снабжены командами проверки"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-12: инварианты ----------
-  - id: TC-21
-    type: unit
-    description: "Снапшот STAGE_TRANSITIONS и реестра QG_CHECKS совпадает с эталоном (src/** не затронут логикой онбординга); эталонные промпты .openclaw/agents/ орка не изменены задачей"
-    module: tests/test_onboarding_invariants.py
-    expected: PASS
-
-  - id: TC-22
-    type: integration
-    description: "Полный регресс существующего tests/ остаётся зелёным после добавления onboarding-артефактов (никакой новый импорт/код не ломает конвейер)"
-    module: tests/
-    expected: PASS
--- a/docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md
+++ b/docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md
@@ -1,341 +0,0 @@
---
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# ADR-001: Turnkey-онбординг проектов — kit `onboarding/` + операторский CLI + runbook
-
-Work Item: **ORCH-009** — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-Стадия: **architecture**
-Связь: BRD `01-brd.md`, ТЗ `02-trz.md`, AC `03-acceptance-criteria.md`, тест-план `04-test-plan.yaml`,
-инфра `07-infra-requirements.md`, риски `10-tech-risks.md`.
-Сквозная регистрация: **`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`**
-(решение кросс-каттинговое: новая способность уровня всего оркестратора — масштабирование на
-новые проекты, домен D5.2 эпика саморазвития).
-
-## Статус
-Proposed
-
---
-
-## Контекст
-
-Онбординг нового проекта сегодня — ручная археология по `SETUP_WEBHOOKS.md`/`INFRA.md`/памяти;
-любой пропуск даёт тихую деградацию (BRD §1.2): без промптов в репо конвейер проекта не работает
-вовсе (Ф-1: launcher резолвит `.openclaw/agents/<role>.md` **относительно worktree репо задачи**);
-без точных имён статусов ветки `Confirm Deploy`/`STOP` молча не активируются (fail-closed,
-`src/plane_sync.py:130-165`); без лейблов авто-режимы/багфикс-трек молча выключены (fail-safe,
-`src/labels.py`/`src/bug_fast_track.py`).
-
-Ограничения, заданные анализом и проверенные по коду:
-
- **NFR-1:** `src/**` не меняется; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict
-  ключи/схема БД/контракт `projects.py` — байт-в-байт. Задача docs/templates/scripts/tests-only.
- **Ф-2:** агент видит только worktree своего репо → каноны обязаны быть **скопированы** в новый
-  репо (ссылка на репо орка агенту недоступна).
- **Ф-3:** реестр строится при импорте из `ORCH_PROJECTS_JSON` (`src/projects.py::_load_projects`);
-  регистрация = правка `.env` + **операторский** управляемый рестарт.
- **Ф-6:** Plane-webhook — workspace-level, уже существует (в CE создаётся SQL-ом, внешнего API
-  нет); Gitea-webhook — per-repo, через API (`push`/`pull_request`/`status`, HMAC).
- **Ф-7:** живой канон — `docs/_templates/` (16 скелетов), `docs/_standards/` (3 стандарта),
-  `.openclaw/agents/*.md` (канон 52d/92).
- Эталон онбординга = **сам репозиторий orchestrator** (актуализация Владельца 10.06);
-  enduro-trails эталоном не является.
-
-ТЗ оставило архитектору 8 открытых вопросов (OQ-1…OQ-8) — все закрываются ниже (D1…D11).
-
---
-
-## Решение
-
-### Сводка
-
-Три артефакта + тесты, всё **вне конвейера и вне рантайма**:
-
-1. **Onboarding-kit** `onboarding/repo-skeleton/` — параметризуемый каркас нового репо
-   (6 промптов канона 52d/92, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, скелет `docs/`
-   с обязательным `operations/INFRA.md`); словарь плейсхолдеров — `onboarding/placeholders.json`.
-2. **Операторский CLI** `scripts/onboard_project.py` — `plan` (дефолт, GET-only) / `apply`
-   (идемпотентный ensure) / `verify`; Plane (проект+статусы+лейблы) → Gitea (репо+webhook) →
-   материализация kit (рендер + live-copy канона) + initial push → генерация записи реестра →
-   отчёт `created/skipped(exists)/manual-step`.
-3. **Runbook** `docs/operations/ONBOARDING.md` — полный чеклист, явные ручные шаги
-   (env + управляемый рестарт; UI-only Plane), верификация (verify + smoke на staging), откат.
-
-Никакого нового кода в горячих путях; kill-switch не нужен (способность активируется только
-явным запуском CLI человеком — TRZ §7).
-
-### D1 — Раскладка: top-level `onboarding/` (OQ-1)
-
-**Решение: `onboarding/` в корне репо** — ровно как предложено ТЗ:
-
-```
-onboarding/
-  README.md            ← устройство kit: словарь плейсхолдеров, правило «канон не форкается»,
-                          copy-vs-template карта (D3), как запускать тесты kit
-  placeholders.json    ← словарь плейсхолдеров (single source of truth, D2)
-  repo-skeleton/       ← дерево зеркалит целевой репо (FR-1)
-    .openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md
-    CLAUDE.md  AGENTS.md  CONTRIBUTING.md  README.md  CHANGELOG.md  .env.example
-    docs/ARCHITECTURE.md  docs/PIPELINE.md  docs/PRODUCT_VISION.md
-    docs/operations/INFRA.md
-    docs/architecture/adr/README.md      ← стаб реестра сквозных ADR (дир непустая, самоописуема)
-    docs/work-items/.gitkeep  docs/history/.gitkeep
-```
-
-Отвергнуто:
- **`docs/_onboarding/`** — смешивает kit (продукт-артефакт, исходник для ЧУЖИХ репо) с
-  документацией самого орка; шаблоны промптов под `docs/` рядом с живыми `docs/_templates/`
-  провоцируют путаницу «какая копия живая» (прямо риск R-1/R-5 BRD) и ложные срабатывания
-  doc-тулинга.
- **`scripts/onboarding/`** — смешивает данные (дерево skeleton) с исполняемым кодом; `scripts/`
-  в этом репо — плоские утилиты (`staging_check.py`, deploy-hook).
-
-Top-level каталог делает границу физической: **всё под `onboarding/` предназначено новому репо,
-ничто под `onboarding/` не исполняется рантаймом орка.** Структурные тесты канона гоняются по
-`onboarding/repo-skeleton/.openclaw/agents/*.md` отдельно от живых промптов орка (TC-03…08 ↔
-существующий `tests/test_agent_prompts_canon.py` не пересекаются).
-
-### D2 — Механизм подстановки: `{{NAME}}` + stdlib, без новых зависимостей (OQ-2)
-
-**Решение: синтаксис `{{PLACEHOLDER_NAME}}`** (верхний регистр, `[A-Z][A-Z0-9_]*`), подстановка —
-простой проход `str.replace` по словарю; после рендера — обязательный скан
-`re.compile(r"\{\{[A-Z][A-Z0-9_]*\}\}")` на неразрешённые плейсхолдеры (ошибка в apply/verify,
-PASS-условие AC-5/TC-09).
-
- **`string.Template` отвергнут:** kit-шаблоны (INFRA.md, `.env.example`, промпты) содержат
-  shell-сниппеты с `$VAR`/`${VAR}` — синтаксис `$` коллидирует и потребовал бы экранирования по
-  всему kit (хрупко, нечитабельно).
- **Jinja2 отвергнут:** новая pip-зависимость (ТЗ §9 запрещает без обоснования) + условная логика
-  в шаблонах = второй язык программирования в kit → выше риск дрейфа. Kit обязан быть тупым.
- Синтаксис `{{…}}` визуально различим, greppable; в Markdown/YAML kit-файлов естественно не
-  встречается, остаточные случаи ловит скан.
-
-**Словарь — `onboarding/placeholders.json`** (машиночитаемый single source of truth; формат:
-`{ "NAME": {"description": …, "required": bool, "default": …|null, "example": …} }`):
-
-| Плейсхолдер | Смысл | Обяз. |
-|---|---|---|
-| `{{PROJECT_NAME}}` | человекочитаемое имя проекта | да |
-| `{{PROJECT_DESCRIPTION}}` | 1–2 фразы «зачем проект» (README/PRODUCT_VISION) | да |
-| `{{REPO}}` | имя Gitea-репо (== каталог под `/repos`) | да |
-| `{{GITEA_OWNER}}` | owner/org репо в Gitea | да |
-| `{{WORK_ITEM_PREFIX}}` | префикс work-item (`ET`/`ORCH`-аналог) | да |
-| `{{PLANE_PROJECT_ID}}` | uuid Plane-проекта (известен после Plane-шага apply) | да |
-| `{{STACK}}` | стек проекта (описательно) | да |
-| `{{TEST_CMD}}` | команда тестов (напр. `pytest -q`) | да |
-| `{{PROD_PORT}}` / `{{STAGING_PORT}}` | порты прод/staging | да |
-
-Расширение словаря = правка `placeholders.json` + kit + тестов в одном PR. Тесты держат
-**биекцию**: каждый плейсхолдер, встречающийся в kit, объявлен в словаре, и каждый объявленный —
-используется (нет мёртвых/опечаточных).
-
-### D3 — Copy-vs-template split (OQ-3, BR-2)
-
-| Класс | Файлы | Механизм |
-|---|---|---|
-| **Live-copy канона** (НЕ хранится в kit) | `docs/_templates/**` (16), `docs/_standards/**` (3) | копируются скриптом **verbatim из рабочего чекаута репо орка в момент материализации** |
-| **Параметризуемые шаблоны** (хранятся в kit) | 6 промптов, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`, `docs/operations/INFRA.md`, `docs/architecture/adr/README.md`, `.env.example` | рендер `{{…}}` (D2) |
-| **Скелет-каркас** | `docs/work-items/.gitkeep`, `docs/history/.gitkeep` | копия как есть |
-
- Канон копируется **байт-в-байт, без переписывания**: ORCH-примеры внутри стандартов
-  (`PIPELINE_DOCS.md` цитирует ORCH-088 и т.п.) остаются примерами — это не «утечка», а
-  иллюстрация (утечкой считается орк-литерал там, где должен быть параметр — AC-5/TC-10:
-  префикс work-item, порты 8500/8501, self-hosting-правила в паспорте/промптах).
- Повторный `apply` существующие файлы в целевом репо **не перезаписывает** (идемпотентность
-  BR-9): обновление канона в уже-онбордженных репо едет их обычными PR с reviewer-gate;
-  новые онбординги автоматически получают свежий канон (live-copy, ТЗ §7).
- Источник live-copy — чекаут, из которого запущен скрипт; скрипт проверяет наличие обоих
-  каталогов и (в verify) количество скелетов ≥ 16 / стандартов ≥ 3.
-
-### D4 — Скрипту разрешён read-only импорт `src` — закрытый список (OQ-4)
-
-**Решение: импортировать, не снапшотить.** Закрытый список импортов:
-
-| Импорт | Зачем |
-|---|---|
-| `src.projects._parse_projects_json`, `src.projects.ProjectConfig` | round-trip валидация генерируемой записи реестра фактическим парсером (AC-6/TC-12) |
-| `src.plane_sync._PLANE_NAME_TO_KEY` | точные канонические имена 22 статусов байт-в-байт (AC-7/TC-13) |
-| `src.config.settings` (read-only поля) | имена лейблов `auto_approve_label`/`auto_deploy_label`/`bug_fast_track_label` (дефолты `autoApprove`/`autoDeploy`/`Bug`), URL/токены Plane/Gitea из env |
-
- **Почему не снапшот:** дублирование констант = гарантированный дрейф (R-2); AC-6 и так требует
-  фактический парсер; снапшот потребовал бы отдельного «теста синхронизации», который и есть
-  признание дрейфа. Импорт даёт нулевой дрейф **по построению**.
- Импорт безопасен: `src.projects` → `src.config` (pydantic-settings с дефолтами, инстанцируется
-  без env); `src.plane_sync` module-level считает только строки из settings; `httpx` — уже
-  зависимость проекта (`requirements.txt`), **новых pip-зависимостей нет**.
- Импорт приватных имён (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`) — сознательная,
-  санкционированная ТЗ связь (ТЗ §2 разрешает явно). **Список закрыт:** любой новый импорт из
-  `src` — только через обновление этого ADR. Контроль ненарушения `src` — снапшот-тест TC-21
-  (`STAGE_TRANSITIONS`/`QG_CHECKS`) + AC-12 (diff).
- Скрипт запускается из корня чекаута орка (runbook-предусловие); `sys.path`-шим в начале файла
-  (паттерн `scripts/staging_check.py`).
-
-### D5 — Plane-провижининг: канонические статусы + группы + fail-safe (OQ-5, BR-7)
-
-**Ensure-семантика:** `GET states` → создать недостающие по точным именам (ключи
-`_PLANE_NAME_TO_KEY`, 22 имени); существующие (включая CE-дефолтные Backlog/Todo/In Progress/
-Done/Cancelled нового проекта) — `skipped(exists)` по совпадению имени. Аналогично лейблы:
-`autoApprove`/`autoDeploy`/`Bug` (имена — из `settings`, D4).
-
-**Канонические группы статусов** (Plane: `backlog|unstarted|started|completed|cancelled`) —
-фиксируются этим ADR; код-критичные констрейнты выделены:
-
-| Статус | Группа | Констрейнт |
-|---|---|---|
-| Backlog | `backlog` | |
-| Todo, To Analyse | `unstarted` | |
-| In Progress, Analysis, Architecture, Development, Code-Review, Review, Testing, Awaiting Deploy, Deploying, Monitoring after Deploy, Needs Input, In Review, Blocked, Approved, Confirm Deploy | `started` | **рабочие/гейтовые статусы НЕ в терминальных группах** — иначе terminal-detection ORCH-068 (`{uuid→group}`, группы `completed`/`cancelled` = терминал) ложно сочтёт живую задачу терминальной |
-| Rejected | `started` | reject = rework-петля в анализ, задача жива → НЕ `cancelled` |
-| Done | `completed` | терминал |
-| Cancelled | `cancelled` | терминал |
-| **STOP** | **`cancelled`** | **требование ORCH-090** (fail-closed: без статуса/группы ветка cancel не активируется) |
-
-**Fail-safe (CE-пробелы):** код орка использует только GET states — доступность POST
-project/states/labels в Plane CE не гарантирована. Любой недоступный вызов (403/404/405/501/
-нереализовано) → шаг помечается **`manual-step`** со ссылкой на соответствующий раздел runbook
-(точное имя статуса + группа для ручного создания в UI), скрипт не падает (AC-7/TC-14).
-Заведомо ручные шаги: порядок статусов на доске (drag-and-drop, UI-only), workspace-webhook
-(существует, Ф-6 — verify печатает команду проверки, не создаёт).
-
-### D6 — Gitea-провижининг: репо + webhook + initial push только в пустой репо (BR-9)
-
- **Репо:** `POST /api/v1/...` под `{{GITEA_OWNER}}`, `auto_init=false` (репо рождается пустым;
-  `main` создаёт initial push). Существует → `skipped(exists)`.
- **Webhook (per-repo):** events `push`/`pull_request`/`status`, `content_type: json`,
-  `branch_filter: "*"`, URL = внешний URL орка `/webhook/gitea` (формат `SETUP_WEBHOOKS.md`).
-  **Секрет: приёмник `src/webhooks/gitea.py` валидирует ОДИН глобальный
-  `ORCH_GITEA_WEBHOOK_SECRET` на все репо** → скрипт **переиспользует** существующий секрет из
-  env (никогда не генерит новый при наличии — новый сломал бы HMAC всех вебхуков); секрет
-  отсутствует в env → сгенерить `secrets.token_hex(20)` + вывести оператору для `.env`
-  (первичная настройка). В логах/отчёте секрет всегда маскируется (NFR-3).
- **Initial push:** материализованный kit коммитится (`feat: onboarding skeleton (ORCH-009 kit)`)
-  и пушится в `main` **только если репо свежесоздан/пуст** (Gitea `empty: true`); непустой репо →
-  `manual-step` (kit-файлы НИКОГДА не пушатся поверх существующего контента). Это единственный
-  разрешённый push: новый пустой репо до регистрации в реестре не является участником конвейера →
-  **INV-4 (мерж только через PR-merge API) не затрагивается** (ТЗ §9).
-
-### D7 — Запись реестра: полный merged-массив, скрипт `.env` не трогает (BR-8)
-
-**Решение: скрипт выводит (а) standalone-запись нового проекта и (б) полный merged-массив
-`ORCH_PROJECTS_JSON`** = существующие записи verbatim + новая в конец. Источник существующих:
-текущий env / `--env-file` (дефолт — `.env` в корне чекаута, если есть); источника нет → только
-standalone-запись + инструкция. Перед выводом merged-массив прогоняется через
-`projects._parse_projects_json` (round-trip: поля новой записи совпадают, существующие не
-потеряны/не искажены — AC-6/TC-12).
-
- **Почему full-array, а не диф:** оператор вставляет одну строку в `.env` атомарно — ручное
-  слияние JSON в env-строке (экранирование, запятые) и есть источник ошибок R-4.
- Скрипт **не правит** `.env` прода и **не рестартит** контейнер (NFR-2): печатает строку +
-  инструкцию «добавь в `.env` → управляемый рестарт оркестратора (self-hosting: групповое окно,
-  выполнять осознанно)» со ссылкой на runbook. `verify` после рестарта показывает разрыв
-  «создано, но не зарегистрировано» (R-4).
-
-### D8 — Песочница для smoke: staging-контур 8501 + одноразовый SMK-проект (OQ-6, AC-13)
-
-**Решение: smoke выполняется на staging-контуре** (`orchestrator-staging`, 8501, изолированная БД
-`./data/staging`) с **одноразовым** sandbox: Plane-проект `onboarding-smoke` (префикс `SMK`) +
-Gitea-репо `onboarding-smoke`, онбордженные самим скриптом. Регистрация — в `ORCH_PROJECTS_JSON`
-**staging-окружения** (`.env.staging`) + рестарт staging (свободен, в отличие от прод-инварианта).
-Прогон: тестовая задача SMK → стадия `analysis` → проверить следы чтения паспорта/`AGENTS.md` и
-артефакты `docs/work-items/SMK-…/` по канону `PIPELINE_DOCS.md`.
-
- **Прод-контур отвергнут:** smoke-задача писала бы конвейерные строки в общую прод-БД и жила бы
-  в общей очереди с enduro/ORCH — шум и риск в общем инстансе (дух NFR-2).
- Протокол прогона — раздел **«Журнал smoke-прогонов»** в `ONBOARDING.md` (дата, параметры,
-  PASS/FAIL по чек-листу AC-13); для приёмки ORCH-009 первый протокол обязателен, ссылка на него —
-  из `13-test-report.md` задачи. Судьба sandbox-артефактов: архив/удаление вручную по разделу
-  «Откат» runbook (скрипт не удаляет ничего — BR-9).
-
-### D9 — Языковая политика kit-промптов: канон орка (OQ-7, AC-4)
-
-**Решение: 5 ru + deployer en** — ровно языковая раскладка канона орка, нормативная по
-ADR-001 D2 ORCH-092 (deployer — самый safety-critical промпт, en-раскладка минимизирует
-регресс-поверхность байт-точных verdict-ключей/команд). Kit наследует канон без отступлений;
-per-project отступление возможно позже **только** решением в собственном ADR нового проекта
-(правило фиксируется в `onboarding/README.md` и шаблоне `CONTRIBUTING.md`). Проверяется TC-08.
-
-### D10 — Branch protection `main` нового репо: НЕ включать (OQ-8)
-
-**Решение: не включать.** Merge-актор конвейера — Gitea PR-merge API под токеном орка
-(INV-4; `src/merge_gate.py`, ORCH-093): required-approvals/required-status-checks дали бы
-405/409-класс отказов `merge_pr` → ложные HOLD (ровно класс инцидента ORCH-063). Сам орк живёт
-без protection — защита `main` держится конвенцией (агенты не пушат `main`; мерж только через
-PR API) и скоупом токенов. Решение фиксируется в runbook; пересмотр — при мультитенант-hardening
-(D5.6, вне объёма).
-
-### D11 — Форма CLI и тестируемость без сети (BR-11, NFR-5)
-
-**Один файл `scripts/onboard_project.py`** (операторская UX: один очевидный энтрипойнт; паттерн
-`scripts/staging_check.py`), внутри — слои:
-
- **Чистое ядро:** `build_plan(params, observed) -> Plan` — без I/O; `Plan` = упорядоченный список
-  шагов закрытого списка BR-1: `plane.project → plane.states(22) → plane.labels(3) → gitea.repo →
-  gitea.webhook → kit.materialize+push → registry.emit`. Рендер kit — чистая функция
-  `render(text, params)` (D2), в plan-режиме выполняется **in-memory** (ни одной записи на диск —
-  AC-8/TC-16); материализация на диск (temp-dir → git init/commit/push) — только в `apply`.
- **Тонкие клиенты** `PlaneClient`/`GiteaClient` (httpx; единственные точки сети) — инжектируются
-  → в тестах мокаются целиком (NFR-5: ноль сетевых вызовов, TC-13…18).
- **Режимы:** `plan` (дефолт) — только GET-пробы текущего состояния + полный план без единой
-  мутации; `apply` — ensure-исполнение (идемпотентно, без delete-операций вовсе); `verify` —
-  GET-пробы + локальные проверки (registry round-trip, резолв всех логических ключей включая
-  `confirm_deploy`/`stop`, лейблы, webhook активен, kit-файлы в репо, скан неразрешённых
-  плейсхолдеров).
- **Отчёт:** человекочитаемый + `--json`; статус каждого шага
-  `created | skipped(exists) | manual-step | planned | error`; exit-коды: `0` — чисто, `2` — есть
-  `manual-step`/gap в verify, `1` — ошибка. Каждый шаг логируется (BR-11).
-
---
-
-## Альтернативы (сводно)
-
- **`docs/_onboarding/` / `scripts/onboarding/`** — отвергнуто (D1): смешение kit с живой докой
-  орка / данных с кодом.
- **Jinja2 / `string.Template`** — отвергнуто (D2): новая зависимость и логика в шаблонах /
-  коллизия `$` с shell-сниппетами.
- **Снапшот констант `src` + тест синхронизации** — отвергнуто (D4): узаконенный дрейф; импорт
-  даёт нулевой дрейф по построению.
- **Генерация нового webhook-секрета per-repo** — отвергнуто (D6): приёмник валидирует один
-  глобальный секрет; новый сломал бы HMAC существующих вебхуков.
- **Диф-вывод реестра** — отвергнуто (D7): ручное слияние JSON-в-env — источник ошибок R-4.
- **Smoke на прод-контуре** — отвергнуто (D8): запись в общую прод-БД/очередь.
- **Branch protection `main`** — отвергнуто (D10): ломает PR-merge API актора (ложные HOLD).
-
-## Последствия
-
- **+** Turnkey-способность D5.2: один проход + runbook вместо археологии; тихие деградации
-  (статусы/лейблы/промпты) закрываются проверяемо (`verify` + структурные тесты).
- **+** Нулевой риск рантайма: `src/**` байт-в-байт, нового кода в горячих путях нет, kill-switch
-  не нужен; регресс enduro/orchestrator невозможен по построению.
- **+** Анти-дрейф структурный: live-copy канона (BR-2) + единые канон-тесты kit (NFR-4) +
-  биекция словаря плейсхолдеров.
- **−** Операторские шаги остаются ручными (env + управляемый рестарт; UI-only Plane): осознанное
-  ограничение NFR-2 (никакой автоматики рестартов) — митигировано runbook + verify (видимый разрыв).
- **−** Импорт приватных имён `src` связывает скрипт с внутренними идентификаторами — митигировано
-  закрытым списком (D4) и тем, что рефакторинг имён мгновенно валит импорт в тестах (видимая,
-  не тихая поломка).
- **−** Kit-шаблоны промптов требуют сопровождения при эволюции канона — митигировано общими
-  структурными требованиями тестов (расхождение ловит CI, NFR-4).
- **Откат:** удалить `onboarding/`, `scripts/onboard_project.py`, `docs/operations/ONBOARDING.md`,
-  тесты — репо в исходном состоянии (ТЗ §7); внешние сущности (sandbox/созданные проекты) —
-  вручную по разделу «Откат» runbook.
-
-## Ссылки
-
- BRD: `docs/work-items/ORCH-009/01-brd.md` · TRZ: `02-trz.md` · AC: `03-acceptance-criteria.md`
-  · Test plan: `04-test-plan.yaml`
- Сверено по коду: `src/projects.py` (`ProjectConfig`, `_parse_projects_json`, `_load_projects`),
-  `src/plane_sync.py:94-165` (`_DEFAULT_STATES`, `_PLANE_NAME_TO_KEY` — 22 имени, fail-closed
-  `Confirm Deploy`/`STOP`), `src/qg/checks.py::check_architecture_done`, `src/config.py`
-  (`auto_*_label`/`bug_fast_track_label`), `requirements.txt` (httpx уже есть)
- Операции: `docs/operations/SETUP_WEBHOOKS.md` (формат Gitea-webhook; Plane workspace-webhook —
-  SQL-only), `docs/operations/INFRA.md`
- Стандарты: `docs/_standards/PIPELINE_DOCS.md` (§4 ADR-naming), `HANDOFF_PROTOCOL.md`,
-  `TRACEABILITY.md`
- ADR: adr-0001 (registry), adr-0017/0018 (паттерны условности), adr-0021/0022 (канон промптов/
-  трассировка), adr-0026 (STOP, группа `cancelled`), ORCH-092 `ADR-001` D2 (язык deployer),
-  сквозной **adr-0035-turnkey-project-onboarding**
--- a/docs/work-items/ORCH-009/07-infra-requirements.md
+++ b/docs/work-items/ORCH-009/07-infra-requirements.md
@@ -1,66 +0,0 @@
---
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# 07 — Инфра-требования: ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
-
-> Топология оркестратора **не меняется** (NFR-1/NFR-2: `src/**` и compose не трогаются).
-> Файл фиксирует **предусловия исполнения способности** (токены/доступы/контуры) и инфра-границы
-> операторского скрипта. Детали решений — `06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`.
-
-## I-1. Топология / окружения
-
- **Прод (`orchestrator`, 8500):** не затрагивается. Скрипт не создаёт/не останавливает/не
-  рестартит контейнеры; в общую БД не пишет (читает только файлы чекаута и внешние API).
- **Staging (`orchestrator-staging`, 8501, БД `./data/staging`):** контур smoke-прогона (ADR D8).
-  Регистрация sandbox-проекта — в `.env.staging`; рестарт staging — штатный, свободный
-  (прод-инвариант на него не распространяется).
- **Новые внешние сущности** (создаются скриптом в `apply`): Plane-проект, Gitea-репо +
-  per-repo webhook. Аддитивно: существующие проекты/репо не модифицируются (BR-9).
- **Запуск скрипта:** хост mva154, из корня чекаута репо orchestrator. Среда исполнения —
-  venv с `requirements.txt` (httpx уже в зависимостях; новых pip-зависимостей нет) **или**
-  `docker compose exec orchestrator python scripts/onboard_project.py …` (read-only к рантайму,
-  без рестартов). Канонический способ фиксирует runbook `docs/operations/ONBOARDING.md`.
-
-## I-2. Переменные окружения / секреты
-
-**Новых env-переменных не вводится.** Используются существующие (предусловия запуска):
-
-| Переменная | Роль в онбординге |
-|---|---|
-| `ORCH_PLANE_API_TOKEN` (+ `ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение Plane-проекта, статусов, лейблов; токен с правом создания проектов в workspace |
-| `ORCH_GITEA_TOKEN` (+ Gitea base URL) | создание репо (под `{{GITEA_OWNER}}`), per-repo webhook; токен с правом create-repo + hooks |
-| `ORCH_GITEA_WEBHOOK_SECRET` | **переиспользуется** для webhook нового репо (приёмник валидирует один глобальный секрет, ADR D6); отсутствует → скрипт генерит и печатает оператору для `.env` |
-| `ORCH_PROJECTS_JSON` | источник существующих записей для merged-вывода (ADR D7); **применение новой строки — операторский шаг** |
-
- Секреты — только в `.env`/`.env.staging` на хосте, в гит не попадают (правило #8 CLAUDE.md);
-  в логах/отчётах скрипта секреты маскируются (NFR-3).
- Kit несёт собственный `.env.example` нового проекта (дескрипторы без значений) — канон секретов
-  транслируется в онбордируемые репо.
-
-## I-3. Деплой / рестарт
-
- **Скрипт НИКОГДА не рестартит/не останавливает прод-контейнер** (NFR-2, self-hosting инвариант).
- Регистрация проекта в реестре (Ф-3): правка `.env` (строка `ORCH_PROJECTS_JSON` из отчёта
-  скрипта) + **управляемый операторский рестарт** оркестратора — групповое окно для ВСЕХ проектов
-  общего инстанса; runbook помечает шаг self-hosting-предупреждением и командой проверки
-  (`GET /queue`, резолв статусов нового проекта).
- TTL-self-heal статусов Plane (ORCH-068, 300с) рестарта не требует: статусы/лейблы, созданные
-  после регистрации, подхватываются без вмешательства.
- Деплой самой задачи ORCH-009 — штатный конвейер: изменение docs/scripts/tests-only, образ
-  пересобирается стандартно, staging-гейт (8501) обязателен как обычно.
-
-## I-4. CI/CD
-
- `.gitea/workflows/` — **без изменений**: новые тесты (`tests/test_onboarding_kit.py`,
-  `test_onboarding_script.py`, `test_onboarding_invariants.py`) подхватываются существующим
-  pytest-шагом; все детерминированы, без сети (NFR-5).
- Инфра-предусловий в образе нет: скрипт — операторский CLI вне рантайма, в образ ничего
-  дополнительно не запекается.
--- a/docs/work-items/ORCH-009/10-tech-risks.md
+++ b/docs/work-items/ORCH-009/10-tech-risks.md
@@ -1,42 +0,0 @@
---
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
---
-
-# 10 — Технические риски: ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Детализирует риски BRD §8 (R-1…R-5) до уровня решений
-> `06-adr/ADR-001`; митигейшены привязаны к D-решениям и TC тест-плана.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Drift канона** (R-1): копия `_templates`/`_standards` в новых репо разъезжается с живым каноном орка; kit-промпты отстают от эволюции канона 52d | Сред. | Сред. | BR-2/D3: live-copy в момент онбординга, второй редактируемой копии канона нет; NFR-4: структурные канон-тесты kit (TC-03…08) ловят расхождение в CI; обновление онбордженных репо — их обычные PR |
-| TR-2 | **Тихая деградация Plane-контрактов** (R-2): опечатка в имени статуса/лейбла или неверная **группа** → fail-closed/fail-safe ветки (`Confirm Deploy`, `STOP`, авто-лейблы, `Bug`) молча не работают; рабочий статус в группе `completed`/`cancelled` → terminal-detection ORCH-068 ложно терминалит живую задачу | Сред. | Выс. | D4: имена импортируются из `_PLANE_NAME_TO_KEY` (нулевой дрейф по построению, TC-13); D5: канонические группы зафиксированы таблицей ADR с код-критичными констрейнтами (STOP→`cancelled`, терминальные группы только Done/Cancelled/STOP); `verify` резолвит ВСЕ логические ключи включая `confirm_deploy`/`stop` |
-| TR-3 | **Скрипт с боевыми токенами** (R-3): ошибка = разрушительное действие на общих Plane/Gitea | Низ. | Выс. | BR-9/D11: `plan` (GET-only) — дефолт; delete-операций в коде нет вовсе (TC-18); аддитивный ensure (TC-17); push только в свежесозданный пустой репо (`empty: true`, D6); существующие сущности не модифицируются |
-| TR-4 | **Разрыв «создано, но не зарегистрировано»** (R-4): оператор не применил env+рестарт → проект невидим для орка | Сред. | Сред. | D7: merged-массив одной строкой (без ручного слияния JSON); runbook: явный операторский шаг с self-hosting-предупреждением + команда проверки; `verify` показывает разрыв (TC-12, AC-11) |
-| TR-5 | **Утечка орк-специфики в kit** (R-5): новый репо получает ORCH-префикс, порты 8500/8501, self-hosting-правила орка | Сред. | Сред. | D2: скан неразрешённых плейсхолдеров после рендера; TC-10: явный тест на утечки; биекция словаря `placeholders.json` ↔ kit (мёртвые/опечаточные плейсхолдеры не живут) |
-| TR-6 | **Поломка HMAC существующих вебхуков**: генерация нового per-repo секрета при едином глобальном `ORCH_GITEA_WEBHOOK_SECRET` приёмника | Низ. | Выс. | D6: секрет **переиспользуется** из env (новый генерится только при полном отсутствии — первичная настройка); секрет маскируется в логах/отчёте (NFR-3) |
-| TR-7 | **Связь скрипта с приватными именами `src`** (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`): рефакторинг src валит скрипт | Низ. | Низ. | D4: закрытый список импортов (расширение — только через ADR); поломка видимая, не тихая — импорт падает в тестах (TC-12/13) на том же PR, что рефакторит src; снапшот TC-21 гардит сам src |
-| TR-8 | **Plane CE API-пробелы** (OQ-5): POST project/states/labels недоступен в CE → провижининг неполон | Сред. | Низ. | D5: fail-safe деградация в `manual-step` со ссылкой на runbook (имя+группа для UI-создания), не падение (TC-14); `verify` подтверждает итоговую полноту независимо от способа создания |
-| TR-9 | **Smoke загрязняет общий контур**: прогон способности в проде = строки в общей БД/очереди | Низ. | Сред. | D8: smoke только на staging (8501, изолированная БД, `.env.staging`); sandbox-сущности одноразовые, снос вручную по разделу «Откат» runbook |
-
-## Сводный вывод
-
-Доминирующий класс — **операционные риски исполнения способности** (TR-2/TR-3/TR-4): они
-митигированы структурно (импорт констант вместо копий, GET-only дефолт, отсутствие delete-операций,
-verify-режим), а не дисциплиной. Рисков для прод-конвейера самой задачи **нет по построению**:
-`src/**` байт-в-байт (AC-12/TC-21), нового кода в горячих путях нет, kill-switch не требуется —
-способность активируется только явным запуском операторского CLI.
-
-Эскалация `arch:major-change` **не требуется**: ни новой стадии, ни нового рантайм-компонента,
-ни изменения БД — это docs/templates/scripts/tests-only способность (новая стадия/компонент
-конвейера не вводится). Возврат в анализ не требуется: ТЗ выполнимо без нарушения принципов.
-Остаточный риск для прод-конвейера (self-hosting): **низкий**.
--- a/docs/work-items/ORCH-009/12-review.md
+++ b/docs/work-items/ORCH-009/12-review.md
@@ -1,167 +0,0 @@
---
-verdict: APPROVED
-work_item: ORCH-009
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-fable-5
-type: review
-work_item_id: ORCH-009
-version: 2
---
-
-# Review ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook) — re-review (цикл 2)
-
-Ветка: `feature/ORCH-009-turnkey-plane` · Diff vs `origin/main`: 46 файлов, +5478/−12.
-Состав: kit `onboarding/repo-skeleton/` (28 файлов), CLI `scripts/onboard_project.py` (1090 строк),
-runbook `docs/operations/ONBOARDING.md`, 3 онбординг-тест-модуля (83 теста), golden-source доки,
-ADR×2 + индекс.
-
-**Контекст цикла:** review v1 (`APPROVED`, 3×P2/2×P3) → testing `PASS` → re-test merge-gate упал на
-**средовых** не-герметичных тестах ORCH-41-эры (прод-env `ORCH_AGENT_FALLBACK_MODEL`/
-`ORCH_AGENT_MODEL_DEFAULT`) → откат на development → фикс `e903818` (герметизация
-`tests/test_resolve_agent_{model,effort}.py`) + регенерация `17-security-report.md` (`b26a391`).
-Этот review: независимая проверка дельты цикла + выборочная верификация клеймов v1.
-
-## Summary
-
-**APPROVED.** P0/P1 нет. Дельта цикла (фикс герметичности тестов) корректна, трассирована к
-ORCH-074 ADR-001 Решение 3 и сохраняет его инвариант; полный регресс теперь зелёный **под
-фактическим прод-env** (перепроверено мной: 1713 passed, exit 0 — ровно та среда, что валила
-merge-gate до фикса). Клеймы review v1 выборочно перепроверены и подтверждены. Переносятся 3×P2
-(харднинг краевых путей CLI, не фикшены — легитимно, follow-up) + 3×P3. Документация обновлена в
-том же PR по всем точкам, включая отдельную CHANGELOG-запись про сам фикс тестов.
-
-## Оси проверки
-
-### Ось 1 — Соответствие ТЗ (`02-trz.md`, `03-acceptance-criteria.md`) — ✅
-
-| Требование | Статус | Чем подтверждено |
-|---|---|---|
-| FR-1 состав kit (19 элементов, анти-форк канона) | ✅ | TC-01/02 зелёные; `docs/_templates|_standards` в kit не хранятся — live-copy в `materialize_kit` (`LIVE_COPY_DIRS`, прочитан код) |
-| FR-2 канон 52d/92 промптов (5 секций, ❌→✅, `<escalation>`, 52c-схема, verdict-ключи байт-в-байт, плейсхолдерные даты/модели) | ✅ | TC-03…06 зелёные; verdict-ключи в kit-промптах сверены grep'ом (`verdict:`/`staging_status:`/`deploy_status:`/`security_status:` на месте) |
-| FR-2 reviewer-gate доки (AC-3) | ✅ | kit `reviewer.md:65`: «документация НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES`» — прочитано лично |
-| FR-3 INFRA.md шаблон | ✅ | TC-19 зелёный (топология/env/границы/риски общего хоста); INFRA орка не тронут (diff пуст) |
-| FR-4 CLI plan/apply/verify | ✅ | Код прочитан полностью: `plan` GET-only (рендер in-memory), `apply` идемпотентный ensure без delete, 22 статуса из `_PLANE_NAME_TO_KEY` + `STATE_GROUPS` 1:1 c ADR D5, CE-отказ → `ManualStep` → `manual-step` (fail-safe); TC-13…18 зелёные |
-| FR-5 verify | ✅ | round-trip фактическим парсером, резолв всех 22 имён, лейблы, webhook active, полнота kit (`VERIFY_KIT_FILES`), скан `{{…}}`, канон ≥16/≥3 |
-| FR-6 runbook | ✅ | `ONBOARDING.md` прочитан: слои 0→6 в порядке BR-1, каждый 🖐-шаг с командой проверки, self-hosting-предупреждение «групповое окно» (§4.2), workspace-webhook — «существует, только проверка» (§1.5), откат §6 |
-| §4/§5 нет API/БД изменений | ✅ | diff `src/**` пуст (проверено лично) |
-| §9 инварианты | ✅ | `git diff origin/main...HEAD -- src/ .openclaw/ docs/_templates/ docs/_standards/ docs/operations/INFRA.md requirements.txt` — **пусто**; сетевых вызовов в тестах нет (фейк-клиенты); новых pip-зависимостей нет |
-| AC-12 полный регресс | ✅ | **1713 passed, 0 failed, exit 0** — мой прогон в worktree ветки под фактическим хост-env (до фикса здесь было 2 failed) |
-| AC-13 операторский smoke | ⏳ | По построению операторский (ADR D8); «Журнал smoke-прогонов» — плейсхолдер. Обязателен ДО `Confirm Deploy` — см. handoff |
-
-### Ось 2 — Соответствие ADR (`06-adr/ADR-001` D1–D11, сквозной `adr-0035`) — ✅
-
- **D1** top-level `onboarding/` ✅; **D2** `{{NAME}}` + `str.replace` + обязательный пост-скан
-  (`PLACEHOLDER_RE`, ValueError в `materialize_kit`) + биекция словаря тестом ✅; **D3**
-  live-copy verbatim, существующие файлы не перезаписываются ✅; **D4** закрытый список импортов
-  `src` — в скрипте ровно три (`settings`, `_PLANE_NAME_TO_KEY`, `_parse_projects_json`),
-  загвожден AST-тестом TC-21 ✅; **D5** `STATE_GROUPS` 1:1 с таблицей ADR (22 имени, set-равенство
-  с `_PLANE_NAME_TO_KEY` тестом; `STOP`→`cancelled`; терминальные группы только
-  Done/Cancelled/STOP; `Rejected`→`started`) ✅; **D6** `auto_init=False`, переиспользование
-  глобального HMAC-секрета, push только в свежесозданный/пустой репо ✅; **D7** merged-full-array
-  + round-trip + `.env` read-only ✅; **D8** smoke на staging 8501, журнал в runbook ✅; **D9**
-  5 ru + deployer en с «Do NOT translate»-гардом и рамкой shared-host-гардрейлов (прочитано
-  лично) ✅; **D10** runbook §2.3 «branch protection НЕ включать» ✅; **D11** plan/apply/verify,
-  чистый `build_plan`, инжектируемые клиенты, отчёт `created/skipped(exists)/manual-step/planned/
-  error`, exit-коды 0/2/1 ✅.
- **Трассировка (`docs/_standards/TRACEABILITY.md`) — дельта цикла:**
-  - `tests/test_resolve_agent_{model,effort}.py` несут маркеры **ORCH-41/ORCH-074** — сверено с
-    `docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md` **Решение 3 (G4)**:
-    инвариант = «**shipped-дефолт** `agent_fallback_model` остаётся `""`». Фикс переводит ассерт
-    с env-backed singleton на **класс-дефолт поля** (`model_fields[...].default == ""`) — это
-    и есть подлинный инвариант ADR (заводской дефолт, а не рантайм-конфиг оператора);
-    never-break ассерты `is_valid_model` — байт-в-байт. Инвариант **сохранён и уточнён**,
-    обоснование — в коммит-месседже и инлайн-комментариях со ссылкой на ADR. Чужой инвариант
-    не сломан → finding нет.
-  - `docs/architecture/adr/README.md` — бэкфилл строк 0032–0035 сверен: все 4 файла
-    (`adr-0032-bug-fast-track`, `adr-0033-sidecar-watchdog`, `adr-0034-lessons-journal`,
-    `adr-0035-turnkey-project-onboarding`) существуют, привязки задач корректны, «текущий
-    максимум 0035» верен.
-  - `docs/operations/SETUP_WEBHOOKS.md` — обобщение per-repo **усиливает** инвариант одного
-    глобального HMAC-секрета (явное предупреждение про ротацию на всех репо разом).
- **Инварианты NFR-1/INV-4:** снапшот-тесты `STAGE_TRANSITIONS`/`QG_CHECKS` зелёные; push —
-  только initial в пустой репо вне конвейера; PR-merge API не затрагивается.
-
-### Ось 3 — Качество кода — ✅ (с переносными P2 ниже)
-
- CLI: чистое разделение слоёв (ядро без I/O / тонкие клиенты / режимы), docstrings на всех
-  публичных функциях, единственная точка subprocess (только `git`, токен в логе маскируется
-  `://***@`), `ManualStep` fail-safe вместо падений, delete-операций нет вовсе, секрет в отчёте
-  `***` + тест non-leak. Тесты содержательные: AST-проверка закрытого списка импортов,
-  monkeypatch-мины на мутации в dry-run, негативные CE-сценарии, set-равенство против дрейфа
-  констант — не тривиальные.
- **Фикс герметичности (дельта цикла) — корректен:** autouse-фикстуры пиняют shipped-дефолты
-  (зеркально между файлами-сиблингами), в чистом env поведение байт-эквивалентно; класс среды
-  merge-gate re-test (прод-env) теперь покрыт. Перепроверено прогоном: 1713 passed под хост-env.
-  Правка существующих тестов вне инвентаря ТЗ §2 — легитимна: инвентарь «рабочее предложение»,
-  ни один инвариант §9 не запрещает правку тестов; без неё PR непроходим через merge-gate
-  (латентная мина `main`, детонированная сменой прод-env).
- Багфикс-трек (ORCH-019, BR-4): не применим — задача не `Bug`, маршрут полный.
-
-### Ось 4 — Документация — ✅ ОБНОВЛЕНА В ТОМ ЖЕ PR
-
-| Точка | Статус |
-|---|---|
-| `CLAUDE.md` — раздел «Turnkey-онбординг проектов (ORCH-009)» | ✅ |
-| `docs/architecture/README.md` — раздел + ссылки на оба ADR | ✅ (diff прочитан, фактам соответствует) |
-| `CHANGELOG.md` — детальная `feat`-запись **+ отдельная под-запись про фикс герметичности тестов** | ✅ (дельта цикла задокументирована — образцово) |
-| ADR per-WI `06-adr/ADR-001` + сквозной `adr-0035` + индекс `adr/README.md` | ✅ |
-| `docs/operations/ONBOARDING.md` (новый runbook) | ✅ |
-| `docs/operations/SETUP_WEBHOOKS.md` — обобщён per-repo | ✅ |
-| `onboarding/README.md` — устройство kit, словарь, анти-форк | ✅ |
-| README «Известные ограничения» (ORCH-079) | **N/A — проверено лично:** открыты 3 пункта (Telegram 48h / intra-repo deps ORCH-026 / пакетный автоном Этап 1) — ни один этим PR не закрывается |
-| `17-security-report.md` | ✅ `security_status: PASS` (0 secrets, 0 blocking) |
-| `08-data-requirements.md` отсутствует | Легитимно: гейт `check_analysis_complete` требует 01–04; ТЗ §5 «изменений БД нет» |
-
-## Findings
-
-### P0 — Blocker
- (нет)
-
-### P1 — Must fix
- (нет)
-
-### P2 — Should fix (перенос из review v1 — не фикшены, перепроверены: всё ещё в коде; follow-up, не блокируют)
- [ ] **Quoted-значение в `.env` → тихая потеря существующих записей в merged-выводе.**
-  `read_existing_registry` (строка ~355) возвращает значение после `=` как есть; кавычки →
-  `json.loads` в `merged_projects_json` молча даёт `existing=[]` → merged-массив только с новым
-  проектом, а runbook §4.1 велит «заменить строку». Доминирующий путь безопасен (pydantic
-  снимает кавычки), потому P2. Рекомендация: `strip("'\"")` в фоллбеке + GAP-warning, если строка
-  в `.env` есть, а existing пуст. (ADR D7 «существующие не теряются».)
- [ ] **`GiteaClient.create_repo`: фоллбек `POST /user/repos` может создать репо в чужом
-  namespace** (строки ~474–477): owner не org и не юзер токена → репо рождается под юзером
-  токена, последующие шаги по `owner/repo` дают 404/manual-step. Рекомендация: сверять
-  `owner.login` ответа с запрошенным; расхождение → `manual-step`.
- [ ] **CE-деградация Plane + успешный Gitea в одном apply запекает литерал
-  `<assigned-on-apply>` в запушенный паспорт** (`build_params` → `PLANE_PROJECT_ID`); скан ловит
-  только `{{…}}`. Рекомендация: при неразрешённом `PLANE_PROJECT_ID` деградировать
-  `kit.materialize`/`kit.push` в `manual-step` ИЛИ добавить `<assigned-on-apply>` в скан verify.
-
-### P3 — Nice to have
- [ ] `--env-file` игнорируется в `plan` (`run_plan` → `_registry_instructions(report, params,
-  None)`; `main()` его в `run_plan` и не передаёт): превью merged-массива может расходиться с apply.
- [ ] Push-URL с `oauth2:<token>@` остаётся в `.git/config` temp-каталога после успешного apply
-  (cleanup нет). Рекомендация: чистить на успехе, на ошибке сохранять для дебага.
- [ ] *(новое)* `run_apply`: шаг `registry.emit` добавляется со статусом `CREATED` **до**
-  `_registry_instructions`, который на ошибке round-trip добавляет второй шаг `registry.emit`
-  со статусом `ERROR` → дубль step-id в отчёте (exit-код при этом честный — 1). Косметика отчёта.
-
-## Документация
-
-Обновлена полностью в том же PR (таблица оси 4). Несоответствий «код изменён — дока молчит» нет;
-дельта цикла (фикс тестов) получила собственную CHANGELOG-запись с диагнозом и обоснованием;
-обзорная витрина README задачей не затрагивается (проверено: открытые ограничения не про онбординг).
-
-## Для следующей стадии (testing) — handoff
-
-1. **AC-13 (операторский smoke, ADR D8)** — единственный непокрытый pytest'ом AC: прогон по
-   runbook §5.2 (staging 8501, sandbox `SMK`) должен быть выполнен и запротоколирован в «Журнале
-   smoke-прогонов» `ONBOARDING.md`, ссылка — из `13-test-report.md`. Обязателен **до**
-   `Confirm Deploy` (человеческий гейт — точка контроля сохраняется).
-2. Средовая мина merge-gate обезврежена фиксом `e903818`: полный регресс зелёный и в чистом env,
-   и под прод-env (1713 passed, проверено в этом review) — спец-обвязка прогона больше не нужна.
-3. `13-test-report.md` в дереве — от прошлого цикла (до `e903818`): его строка «PR эти файлы не
-   трогает» про `tests/test_resolve_agent_*` устарела. Перегенерировать отчёт штатно (артефакт
-   чужой стадии — в этом review не правился).
--- a/docs/work-items/ORCH-009/13-test-report.md
+++ b/docs/work-items/ORCH-009/13-test-report.md
@@ -1,117 +0,0 @@
---
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-009
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-009
---
-
-# Test Report — ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook)
-
-> Машинный вердикт читается ТОЛЬКО из frontmatter (`result:`). Перепрогон стадии testing на
-> opus после сброса session-limit (ре-ран по запросу). Review-вердикт цикла 2 — `APPROVED`
-> (`12-review.md`, P0/P1 нет). Дельта цикла (герметизация ORCH-41-тестов `e903818`) перепроверена
-> полным регрессом под фактическим окружением worktree.
-
-## Окружение
- Python: 3.12.13
- pytest: 8.3.3 (pytest-cov 5.0.0, asyncio 0.23.8)
- Дата: 2026-06-10
- Worktree: `feature/ORCH-009-turnkey-plane` (`/repos/_wt/orchestrator/feature_ORCH-009-turnkey-plane`, HEAD `b97ffae`)
- Прод-контейнер `orchestrator` (8500) — НЕ трогался (smoke read-only).
-
-## Smoke API (read-only)
- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
- `GET /status` → отвечает; задача ORCH-009 (task 87) на стадии `testing` ✅
- `GET /queue` → блок `serial_gate` **присутствует** (ORCH-088) ✅; блок `auto_labels` присутствует ✅
-  (полный набор ключей: `auto_labels, bug_fast_track, build_cache_prune, counts, coverage,
-  disk_monitor, fs_ownership, lessons, max_concurrency, merge_verify, poll_interval, post_deploy,
-  reaper, recent, reconcile, resilience, serial_gate, stop, task_deps`).
-
-## Результаты
-
-### Полный регресс
-`pytest tests/ -q` → **1713 passed, 0 failed, 1 warning** за 65.40s (exit 0). Прод-контейнер не
-трогался. Средовая мина merge-gate цикла 1 обезврежена фиксом `e903818` — регресс зелёный.
-
-### Профильные сюиты (онбординг)
-`pytest tests/test_onboarding_kit.py tests/test_onboarding_script.py tests/test_onboarding_invariants.py -v`
-→ **83 passed, 0 failed** за 0.55s (exit 0). Сетевых вызовов нет (Plane/Gitea — фейк-клиенты, NFR-5).
-
-### Сопоставление с тест-планом (`04-test-plan.yaml`)
-
-| TC ID | Описание | Тест-функция | Рез. |
-|-------|----------|--------------|------|
-| TC-01 | Kit содержит все элементы FR-1 (6 промптов + доки) | `test_tc01_kit_contains_all_required_elements`, `test_tc01_kit_readme_and_placeholder_dictionary_exist` | PASS |
-| TC-02 | Материализация добавляет live-копии `_templates`/`_standards`; форк канона отсутствует | `test_tc02_materialise_live_copies_canon`, `test_kit_does_not_fork_the_canon` | PASS |
-| TC-03 | 5 XML-секций в нормативном порядке (6 ролей) | `test_tc03_five_xml_sections_in_normative_order[*]` | PASS |
-| TC-04 | `<escalation>` у dev/rev/tester; запреты «❌→✅» | `test_tc04_escalation_section_after_success_criteria[*]`, `test_tc04_bans_use_cross_check_format[*]` | PASS |
-| TC-05 | Директивы доки (читай паспорт/AGENTS/ADR; пиши в work-items; CHANGELOG) | `test_tc05_prompt_directs_agent_to_docs[*]`, `test_tc05_changelog_duty_present[*]`, `test_tc05_architect_carries_adr_rules` | PASS |
-| TC-06 | 6-польная схема 52c; verdict-ключи байт-в-байт; даты/модели — плейсхолдеры | `test_tc06_six_schema_fields_named[*]`, `test_tc06_schema_pins_role_author_and_stage[*]`, `test_tc06_machine_verdict_keys_byte_exact`, `test_tc06_dates_and_models_are_placeholders[*]` | PASS |
-| TC-07 | reviewer-gate: дока не обновлена → `REQUEST_CHANGES` | `test_tc07_reviewer_gate_docs_not_updated_means_request_changes` | PASS |
-| TC-08 | Языковая политика (5 ru + deployer en) | `test_tc08_ru_canon_for_five_roles[*]`, `test_tc08_deployer_is_english` | PASS |
-| TC-09 | Рендер подставляет все плейсхолдеры (нет неразрешённых) | `test_tc09_render_resolves_all_placeholders`, `test_render_is_a_pure_replace` | PASS |
-| TC-10 | Нет утечек орк-специфики (ORCH-/8500/8501/self-hosting) | `test_tc10_no_orchestrator_specific_leaks` | PASS |
-| TC-11 | Ссылочная целостность отрендеренных промптов/AGENTS | `test_tc11_referenced_paths_exist_in_materialised_tree` | PASS |
-| TC-12 | Registry round-trip через фактический `_parse_projects_json`; существующие записи целы | `test_tc12_registry_round_trip_through_actual_parser`, `test_tc12_merge_is_idempotent_no_duplicates` | PASS |
-| TC-13 | План Plane: все статусы `_PLANE_NAME_TO_KEY` (вкл. `Confirm Deploy`/`STOP`) + лейблы | `test_tc13_plan_covers_all_statuses_and_labels`, `test_state_groups_match_plane_name_to_key` | PASS |
-| TC-14 | Недоступный Plane-шаг → `manual-step` (не падение/не молча) | `test_tc14_plane_refusal_becomes_manual_step` | PASS |
-| TC-15 | План Gitea: репо + webhook (push/pr/status + HMAC) + initial push | `test_tc15_plan_contains_gitea_repo_webhook_and_push` | PASS |
-| TC-16 | dry-run (plan) — ноль мутаций | `test_tc16_plan_is_a_pure_dry_run`, `test_secret_never_leaks_into_report` | PASS |
-| TC-17 | Повторный apply: `skipped(exists)`, без дублей/удалений; отчёт created/skipped/manual | `test_tc17_second_apply_skips_everything_existing` | PASS |
-| TC-18 | Нет операций рестарта/правки прод-.env/push в существующие репо (NFR-2) | `test_tc18_fresh_apply_runs_git_only_inside_workdir`, `test_tc18_source_has_no_container_or_env_mutation_ops` | PASS |
-| TC-19 | INFRA.md шаблон: обязательные секции; INFRA орка не тронут | `test_tc19_infra_template_mandatory_sections`, `test_tc19_orchestrator_own_infra_untouched_sections` | PASS |
-| TC-20 | Runbook: слои предусловия→Plane→Gitea→kit→регистрация→верификация→откат | `test_tc20_runbook_exists_and_layer_order`, `test_tc20_runbook_manual_steps_and_selfhosting_warning`, `test_tc20_runbook_verification_and_smoke_journal` | PASS |
-| TC-21 | Снапшот `STAGE_TRANSITIONS`/`QG_CHECKS`; `src/**` не ссылается на онбординг; закрытый список импортов | `test_tc21_stage_transitions_snapshot`, `test_tc21_qg_checks_registry_snapshot`, `test_tc21_src_never_references_onboarding`, `test_tc21_cli_src_imports_stay_in_closed_list`, `test_tc21_kit_prompts_name_only_real_gates` | PASS |
-| TC-22 | Полный регресс `tests/` зелёный | весь прогон `pytest tests/` (1713 passed) | PASS |
-
-**Итого тест-плана: 22/22 TC выполнены и PASS.**
-
-### Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
-
-| AC | Покрытие | Результат |
-|----|----------|-----------|
-| AC-1 Kit полон | TC-01 | PASS |
-| AC-2 Канон 52d/92 промптов | TC-03/04/05/06 | PASS |
-| AC-3 Reviewer-gate доки | TC-07 | PASS |
-| AC-4 Языковая политика | TC-08 | PASS |
-| AC-5 Материализация / нет утечек | TC-02/09/10/11 | PASS |
-| AC-6 Registry round-trip | TC-12 | PASS |
-| AC-7 План Plane (статусы/лейблы) | TC-13/14 | PASS |
-| AC-8 План Gitea + dry-run без мутаций | TC-15/16 | PASS |
-| AC-9 Идемпотентность/безопасность apply | TC-17/18 | PASS |
-| AC-10 INFRA.md шаблон | TC-19 | PASS |
-| AC-11 Runbook полон | TC-20 | PASS |
-| AC-12 `src/**` не тронут (снапшот + регресс) | TC-21/22 | PASS |
-| AC-13 Операторский smoke на песочнице | вне pytest (см. ниже) | DEFERRED (операторский гейт до `Confirm Deploy`) |
-
-## AC-13 — операторский smoke (не блокирует ребро testing → deploy-staging)
-AC-13 по построению (ADR D8, scope-нота `04-test-plan.yaml`) — **документированный операторский
-прогон** на песочнице staging 8501 с реальными Plane/Gitea-вызовами. Это мутирующая операторская
-процедура → вне read-only smoke и автоматизированного скоупа тестера. «Журнал smoke-прогонов»
-в `docs/operations/ONBOARDING.md` сейчас — плейсхолдер (прогон не выполнен).
- **Не блокирует данную стадию:** AC-13 обязателен **до `Confirm Deploy`** (человеческий гейт
-  прод-деплоя, ORCH-059), который наступает ПОСЛЕ `deploy-staging`. Ребро `testing → deploy-staging`
-  он не гейтит (это операторская страховка, а не Quality Gate; `QG_CHECKS` не содержит проверки AC-13).
- **Handoff оператору:** выполнить runbook §5.2 (staging 8501, sandbox-префикс) и запротоколировать
-  результат в «Журнале smoke-прогонов» `ONBOARDING.md` **перед** нажатием `Confirm Deploy`.
-
-## Вывод pytest (итоги)
-```
-# полный регресс
-1713 passed, 1 warning in 65.40s (exit 0)
-
-# профильные сюиты онбординга
-83 passed, 1 warning in 0.55s (exit 0)
-```
-(Единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, существующий, не связан с задачей.)
-
-## Итог
-**PASS.** Полный регресс зелёный (1713 passed), все 22 TC тест-плана выполнены и PASS, все
-машинно-проверяемые AC (1–12) закрыты, read-only smoke API в норме (`serial_gate`/`auto_labels`
-в `/queue` присутствуют). AC-13 — операторский smoke, отложен к гейту `Confirm Deploy` (не блокирует
-переход на `deploy-staging`). Задача готова к стадии `deploy-staging`.
--- a/docs/work-items/ORCH-009/14-deploy-log.md
+++ b/docs/work-items/ORCH-009/14-deploy-log.md
@@ -1,12 +0,0 @@
---
-deploy_status: SUCCESS
-work_item: ORCH-009
-hook_exit_code: 0
-deployed_by: deploy-finalizer
---
-
-# Deploy log — ORCH-036 executable self-deploy
-
-Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.
--- a/docs/work-items/ORCH-009/15-staging-log.md
+++ b/docs/work-items/ORCH-009/15-staging-log.md
@@ -1,48 +0,0 @@
---
-staging_status: SUCCESS
-work_item: ORCH-009
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-fable-5
-timestamp: 2026-06-10T13:07:10Z
-base_url: http://localhost:8501
---
-
-# Staging Gate Log
-
-Staging test suite completed against the live staging environment
-(`orchestrator-staging`, 8501), run canonically inside the container
-(ORCH-048, ADR-001: `docker exec orchestrator-staging python3
-/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501
--mode stub`).
-
-**Verdict: SUCCESS** (exit code 0).
-
-## Results
-
-Result: 8/10 checks PASS. All REAL (pipeline) checks are green:
-
- **Block A (SMOKE)**: A1 `/health` → 200 status=ok, A2 `/queue` → 200 with
-  counts/max_concurrency/resilience (incl. `serial_gate`, `coverage`,
-  `auto_labels`, `stop`, `bug_fast_track`, `lessons` blocks), A3
-  `ORCH_STAGING=true` — PASS
- **Block B (ACCESS)**: B4 Plane sandbox accessible, B5 Gitea
-  `orchestrator-sandbox` accessible (push=true), B6 registry isolation
-  (sandbox present, prod ET/ORCH absent) — PASS
- **Block C (E2E, mode=stub)**: C7 create issue in Plane SANDBOX (HTTP 201),
-  C8 trigger pipeline via `/webhook/plane` (HTTP 200, accepted) — PASS;
-  cleanup completed (Plane issue deleted, HTTP 204)
-
-REAL failed: none.
-
-The two failed checks (C9a/C9b) are known sandbox-infra checks (they depend on
-SANDBOX bot accounts being project members, not on the pipeline) and were
-waived per ORCH-061 (`staging_infra_tolerance_enabled=True`); the script still
-exited 0 fail-closed because every REAL check is green.
-
-```
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-```
--- a/docs/work-items/ORCH-009/17-security-report.md
+++ b/docs/work-items/ORCH-009/17-security-report.md
@@ -1,25 +0,0 @@
---
-security_status: PASS
-secrets_found: 0
-deps_blocking: 0
-deps_warning: 4
-deps_audit_degraded: false
---
-# Security Report — ORCH-009
-
-Детерминированный security-гейт (ORCH-022): secret-scanning (gitleaks, offline) + dependency audit (pip-audit). Машинный вердикт читается ТОЛЬКО из frontmatter выше.
-
-## Verdict
-clean: 0 secrets, 0 blocking CVE(s)
-
-## Secrets
- None
-
-## Dependencies (blocking)
- None
-
-## Dependencies (warning)
- `pytest==8.3.3` — GHSA-6w46-j5rx-g56g severity=UNKNOWN fix=9.0.3
- `starlette==0.38.6` — PYSEC-2026-161 severity=UNKNOWN fix=1.0.1
- `starlette==0.38.6` — GHSA-f96h-pmfr-66vw severity=UNKNOWN fix=0.40.0
- `starlette==0.38.6` — GHSA-2c2j-9gv5-cj73 severity=UNKNOWN fix=0.47.2
--- a/docs/work-items/ORCH-011/00-business-request.md
+++ b/docs/work-items/ORCH-011/00-business-request.md
@@ -1,7 +0,0 @@
-# Business Request: Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
-
-Work Item ID: ORCH-011
-
-## Description
-
-TBD
--- a/docs/work-items/ORCH-011/01-brd.md
+++ b/docs/work-items/ORCH-011/01-brd.md
@@ -1,199 +0,0 @@
---
-work_item: ORCH-011
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
---
-
-# 01 — BRD: ORCH-011 — Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
-
-Work Item: **ORCH-011** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Владелец (Слава)
-Тип: docs+tests (паттерн ORCH-102/103 — golden-source-документ + структурные анти-дрейф тесты; рантайм не трогается)
-
---
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель
-Описать работу **всей** мультиагентной системы оркестратора в **одном месте** — от бизнес-смысла
-(зачем, какую проблему решает, что умеет) до технического устройства (архитектура, конвейер,
-агенты, модель объектов, интеграции, качество, наблюдаемость). Документация нужна, чтобы:
-1. **другие люди** (разработчики, заказчики, менеджеры проектов) могли разобраться, как работает
-   оркестратор, не раскапывая 60+ work-item пакетов и 40 ADR;
-2. на её основе **генерировать презентационные материалы** по использованию и возможностям
-   (решение Владельца: слайды PowerPoint, стильный тёмный дизайн, точный рендеринг).
-
-### 1.2. Корневая проблема — документация богатая, но фрагментированная
-Установленные факты (проверено по дереву репо, не изобретать):
-
-| Что есть | Где | Ограничение как «единого места» |
-|----------|-----|---------------------------------|
-| Паспорт проекта | `CLAUDE.md` | для агентов/разработчиков; плотный реестр доработок, не вводный текст |
-| Тех-витрина | `README.md` | только технический уровень; обзор без бизнес-слоя |
-| Бизнес-видение | `docs/PRODUCT_VISION.md` (v1.0, 2026-06-04) | «концепция развития» (vision), не описание текущего состояния; не покрывает тех-уровень |
-| Детальная архитектура | `docs/architecture/README.md` (~1246 строк), `internals.md` | глубокий справочник для инженеров; нечитаем «с нуля» нетехническим читателем |
-| Решения | `docs/architecture/adr/` (40 сквозных ADR) + per-work-item ADR | точечные решения, не цельная картина |
-| Стандарты | `docs/_standards/` (PIPELINE_DOCS, HANDOFF_PROTOCOL, TRACEABILITY) | нормативы для агентов |
-| Эксплуатация/тираж | `docs/operations/` (8 runbook'ов), `docs/deployment/` (LITE_SETUP, BUNDLED_SETUP) | операторские инструкции |
-| История/уроки | `docs/history/`, `docs/epics/self-evolution.md` | сырьё, не витрина |
-
-**Ни один** из этих документов не является единой точкой входа «бизнес + тех» для трёх целевых
-аудиторий. Новому человеку (заказчику, менеджеру, новому разработчику) сегодня нужно собирать
-картину из 5–8 разных мест с разной степенью детализации и разным языком. Презентацию о
-возможностях системы собирать не из чего — нет слайдо-готового источника.
-
-### 1.3. Почему сейчас
- Платформа достигла тиражируемости (ORCH-101/102/103: Lite- и Bundled-развёртывание у заказчика)
-  — появился **внешний читатель** (заказчики-тестеры), которому нужно объяснять систему.
- Самовоспроизводящийся темп доработок (self-hosting) без единой витрины делает порог входа всё
-  выше с каждой задачей.
-
-### 1.4. Решения Владельца (из бизнес-запроса) — приняты как требования
-| # | Решение |
-|---|---------|
-| D-1 | Формат презентационных материалов — **слайды PowerPoint**, стильный **тёмный дизайн**, точный рендеринг. |
-| D-2 | Аудитория документации — **разработчики, заказчики, менеджеры проектов** (три явных маршрута чтения). |
-| D-3 | Единое место — репозиторий orchestrator: `docs/` (+ возможно compiled-wiki — как опция, см. §2.2). |
-| D-4 | Поддерживать в актуальном состоянии: документация обновляется **сразу после изменения функционала** (правило CLAUDE.md §2 распространяется на новую витрину). |
-
---
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
- **Единая витрина системы** — новый связный раздел в `docs/` с одной точкой входа (индексом),
-  покрывающий **два уровня**:
-  - **Бизнес-уровень** (для нетехнических читателей и презентаций): зачем нужен оркестратор и
-    какую проблему решает; что умеет (автономный конвейер «задача → прод», мультипроектность,
-    самовосстановление, пакетный авто-режим, багфикс-трек, тиражируемость); ценность и
-    возможности простым языком; сценарии использования.
-  - **Технический уровень** (7 блоков, контент-карта — TRZ §3):
-    1) архитектура — компоненты и их связи; 2) конвейер/стадии и гейты на переходах;
-    3) агенты — 6 ролей, входы/выходы, артефакты, шаблоны; 4) структура объектов —
-    Project/Work-Item, реестр проектов, jobs-очередь, события/дедуп, каноническая модель БД;
-    5) интеграции — Plane, Gitea, LLM-модели, Telegram; 6) качество/безопасность;
-    7) аналитика/наблюдаемость.
- **Маршруты чтения** для трёх аудиторий (D-2): «я заказчик / я менеджер / я разработчик —
-  с чего начать и что читать дальше».
- **Презентационная основа** (D-1): слайдо-структурированный источник (последовательность
-  слайдов: заголовок/тезисы/визуальный мотив) + воспроизводимый путь получения `.pptx` в тёмном
-  дизайне. Выбор инструмента генерации — за архитектором (TRZ §3.4, OQ-2).
- **Норматив сопровождения**: правило «изменил функционал → обнови витрину в том же PR»
-  зафиксировано в витрине и в правилах агентов (D-4; ось reviewer'а по обзорным докам уже
-  существует — ORCH-079).
- **Анти-дрейф**: структурные pytest-тесты каркаса витрины (по образцу
-  `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py`): обязательные разделы, сверка
-  карты стадий импортом `src/stages.py::STAGE_TRANSITIONS`, полнота 6 агентов, валидность
-  внутренних ссылок, запрет секретов/хост-хардкодов.
- Обновление указателей: `README.md`, `CLAUDE.md` (ссылка на витрину), `CHANGELOG.md`.
-
-### 2.2. Вне объёма (явно, не делать)
- **Любые изменения рантайма:** `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`,
-  machine-verdict ключи, схема БД, compose/Dockerfile — байт-в-байт.
- **Compiled-wiki / внешняя вики-платформа** — вне объёма v1: репозиторий остаётся единственным
-  источником истины («канон не форкается», паттерн ORCH-009 BR-2); экспорт в wiki — возможное
-  развитие, фиксируется как открытый вопрос (TRZ §9 OQ-4), не реализуется.
- **Перенос вне-репозиторных источников в репо**: `tasks/orchestrator/STATUS.md`, `BACKLOG.md`,
-  PROGRESS-журналы, дневники `memory/` физически в репозитории отсутствуют — они служат лишь
-  затравками для содержания; сами файлы в гит не переносятся (внутренняя кухня, риск утечки
-  контекста/секретов).
- **Переписывание/замена существующих golden sources** (`docs/architecture/README.md`,
-  `internals.md`, стандарты `docs/_standards/`, deployment-доки): витрина ссылается на них,
-  а не дублирует и не подменяет (анти-«второй источник истины», BR-4).
- **Автогенерация документации из кода** (doc-from-code, autodoc) — вне объёма.
- **Маркетинговые материалы за пределами PPTX-основы** (видео, лендинги, демо-стенды).
- Новые runtime-зависимости прод-образа (включая библиотеки генерации презентаций) — запрещено
-  (NFR-2).
-
---
-
-## 3. Заинтересованные стороны
- **Владелец/оператор (Слава)** — заказчик задачи; принимает витрину и презентационную основу;
-  использует слайды для показа возможностей платформы.
- **Заказчики платформы** (внешние, включая тестеров Lite/Bundled-тиража ORCH-102/103) — читают
-  бизнес-уровень и сценарии; смотрят презентацию.
- **Менеджеры проектов** — читают бизнес-уровень + конвейер/статусную модель (что видно в Plane,
-  какие человеческие гейты есть).
- **Разработчики** (люди и агенты самого оркестратора) — входят через витрину в технический
-  уровень и далее по ссылкам в golden sources.
- **Reviewer-агент конвейера** — контролирует соблюдение норматива сопровождения витрины
-  (расширение оси «обзорные доки» ORCH-079).
-
---
-
-## 4. Бизнес-требования (BR)
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | В `docs/` существует **единая точка входа** (индекс витрины), из которой достижимы оба уровня (бизнес/тех) и все 7 тех-блоков; любой из трёх читателей начинает с одного места. | D-3, AC-1 |
-| BR-2 | **Бизнес-уровень** читается нетехническим человеком: проблема → решение → ценность → возможности → сценарии использования; термины конвейера объяснены по-человечески; без необъяснённого жаргона и кодовых идентификаторов в основном тексте. | D-2, AC-2 |
-| BR-3 | **Технический уровень** покрывает все 7 заявленных блоков (§2.1) и соответствует фактическому коду/канону репо: карта стадий = `STAGE_TRANSITIONS`, реестр гейтов = `QG_CHECKS` + под-гейты, агенты = 6 промптов `.openclaw/agents/` + таблица модель/эффорт (ORCH-41), модель данных = фактические таблицы `src/db.py`. | AC-3, AC-4, AC-5 |
-| BR-4 | **Link-first / не форкается канон:** витрина даёт цельную картину и ссылается на golden sources за деталями (architecture/README, internals, стандарты, ADR, deployment-доки); не создаёт второй источник истины и не противоречит коду. | §2.2, AC-6 |
-| BR-5 | **Презентационная основа:** в репо есть слайдо-структурированный источник (бизнес-нарратив → слайды) и воспроизводимый, документированный путь получения `.pptx` в тёмном дизайне (D-1). Инструмент — выбор архитектора; запуск — вне рантайма конвейера. | D-1, AC-7 |
-| BR-6 | **Маршруты аудиторий:** витрина содержит явные маршруты чтения для заказчика / менеджера / разработчика (D-2). | D-2, AC-8 |
-| BR-7 | **Норматив сопровождения:** правило «изменил функционал → обнови витрину в том же PR» зафиксировано в витрине и видимо агентам (CLAUDE.md-указатель); reviewer-ось обзорных доков покрывает витрину. | D-4, AC-9 |
-| BR-8 | **Анти-дрейф:** каркас витрины и её ключевые машинно-проверяемые факты (стадии, агенты, ссылки, отсутствие секретов) защищены структурными pytest-тестами; их падение ловит расхождение витрины с кодом. | AC-10 |
-| BR-9 | Существующие указатели актуализированы: `README.md` и `CLAUDE.md` ссылаются на витрину; `CHANGELOG.md` несёт запись. | AC-11 |
-
---
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **docs+tests only:** `src/**` байт-в-байт; `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД / compose / Dockerfile — не тронуты. Kill-switch не нужен: документация не исполняется (паттерн ORCH-102/103). |
-| NFR-2 | **Прод-образ без новых зависимостей:** генерация презентации (если скриптом) исполняется вне рантайма (host/dev-окружение, явный запуск человеком — паттерн ORCH-009); зависимости генерации НЕ попадают в `requirements`/образ оркестратора. |
-| NFR-3 | **Без секретов и хост-специфики** в новых доках/источниках презентации: токены, внутренние URL/имена хостов — только плейсхолдерами (паттерн `tests/test_no_host_hardcodes.py` / fenced-скан `test_lite_setup_doc.py`). |
-| NFR-4 | **Язык:** русский (канон репо; языковое исключение deployer.md не затрагивается). Терминология единая со статусной моделью Plane (ORCH-066) и PIPELINE_DOCS. |
-| NFR-5 | **Self-hosting safety:** задача не рестартит/не роняет прод-контейнер; прод-деплой — только штатным маршрутом конвейера (staging-гейт + Confirm Deploy). |
-| NFR-6 | **Поддерживаемость:** витрина модульная (отдельные файлы по блокам, связанные индексом), чтобы будущие правки были точечными; объём основного текста разумен за счёт link-first (BR-4). |
-
---
-
-## 6. Допущения и ограничения
- **Вне-репозиторные затравки** (`tasks/orchestrator/STATUS.md`, `BACKLOG.md`, PROGRESS-журналы,
-  `memory/`) в worktree недоступны — содержание витрины строится из **внутрирепозиторных** golden
-  sources (CLAUDE.md, README, PRODUCT_VISION, architecture/, _standards/, ADR, deployment/,
-  history/). Этого достаточно: репо самодостаточен по фактам (проверено §1.2).
- `docs/PRODUCT_VISION.md` остаётся самостоятельным vision-документом; витрина переиспользует его
-  бизнес-нарратив со сверкой с фактическим состоянием (что из vision уже реализовано — например,
-  тираж ORCH-101/102/103) и ссылается на него.
- Точное имя/структура каталога витрины — решение архитектора (рекомендация TRZ §2: новый каталог
-  в `docs/`, например `docs/overview/`); анти-дрейф тесты пишутся под выбранные пути.
- Бинарный артефакт `.pptx`: коммит бинаря в git спорен — решает архитектор (OQ-3); требование
-  BR-5 — воспроизводимость пути генерации, не обязательность бинаря в репо.
- Задача объёмная по контенту: допускается реализация витрины «вглубь по блокам» в одном PR
-  (один прогон developer); если объём не помещается — эскалация на уровне задач (разбиение)
-  по штатному маршруту, не молчаливое сокращение объёма.
-
---
-
-## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
- AC-1 единая точка входа существует и связывает оба уровня и маршруты аудиторий.
- AC-2 бизнес-уровень самодостаточен для нетехнического читателя.
- AC-3…AC-5 тех-уровень покрывает 7 блоков и сходится с кодом (стадии/гейты/агенты/модель данных).
- AC-6 link-first: ссылки на golden sources валидны, дублирования-противоречий нет.
- AC-7 презентационная основа есть; путь к `.pptx` (тёмный дизайн) воспроизводим и документирован.
- AC-8 маршруты трёх аудиторий присутствуют.
- AC-9 норматив сопровождения зафиксирован.
- AC-10 структурные анти-дрейф тесты существуют и зелёные; полный pytest зелёный.
- AC-11 README/CLAUDE.md/CHANGELOG обновлены; `src/**` не тронут.
-
---
-
-## 8. Риски (кратко; детали — 10-tech-risks.md, заполняет архитектор)
- **R-1 — гниение витрины.** Self-hosting темп (несколько задач в неделю) быстро устаревает любой
-  снапшот. Митигция: link-first (BR-4) + норматив сопровождения (BR-7) + структурные тесты на
-  машинно-проверяемые факты (BR-8) — дрейф ловится CI, а не глазами.
- **R-2 — второй источник истины.** Дублирование деталей architecture/README в витрине приведёт к
-  противоречиям. Митигция: витрина = картина + ссылки; детали живут в существующих golden sources.
- **R-3 — объём одного прогона.** Полная витрина + презентация + тесты могут не поместиться в один
-  PR разумного размера. Митигция: модульность (NFR-6), приоритет блоков, при необходимости —
-  эскалация/разбиение (допущение §6).
- **R-4 — зависимость генерации презентации.** Библиотека генерации PPTX в прод-образе — лишний
-  attack-surface/вес. Митигция: NFR-2 (вне рантайма), решение по инструменту — ADR архитектора.
- **R-5 — расползание скопа в маркетинг.** Слайды → «а давайте ещё видео/лендинг». Митигция:
-  жёсткая граница §2.2.
--- a/docs/work-items/ORCH-011/02-trz.md
+++ b/docs/work-items/ORCH-011/02-trz.md
@@ -1,191 +0,0 @@
---
-work_item: ORCH-011
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
---
-
-# 02 — ТЗ (TRZ): ORCH-011 — Полная документация системы мультиагентов оркестратора
-
-Work Item: **ORCH-011** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно появиться/измениться и **где** (файлы, структура, контент-карта,
-> источники истины). **Как** (точное имя каталога витрины, инструмент генерации PPTX, разбиение
-> на файлы) — решает архитектор в `06-adr/`. Тип изменения — **docs+tests** (паттерн
-> ORCH-102/103): рантайм не трогается.
-
---
-
-## 1. Сводка изменения
-Создать в `docs/` **единую витрину системы** — связный набор документов с одной точкой входа,
-описывающий мультиагентный оркестратор на двух уровнях (бизнес + технический, 7 блоков),
-с маршрутами чтения для трёх аудиторий (разработчики / заказчики / менеджеры), слайдо-готовой
-презентационной основой (PowerPoint, тёмный дизайн) и нормативом сопровождения. Каркас и
-машинно-проверяемые факты витрины защитить структурными pytest-тестами (анти-дрейф). Обновить
-указатели (`README.md`, `CLAUDE.md`, `CHANGELOG.md`). `src/**` — байт-в-байт.
-
---
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `docs/<витрина>/` (рекомендация: `docs/overview/`; финальное имя — ADR архитектора) | **создать**: индекс + бизнес-часть + тех-часть (7 блоков) + маршруты аудиторий + презентационная основа |
-| `docs/<витрина>/README.md` (или `index.md` — по ADR) | **создать**: единая точка входа (BR-1) |
-| `tests/test_system_docs.py` (имя — по паттерну `test_lite_setup_doc.py`; финал — ADR) | **создать**: структурный анти-дрейф витрины (FR-7) |
-| `scripts/` (опционально, по ADR — например `scripts/build_presentation.py`) | **создать (опц.)**: генерация `.pptx` из презентационной основы (FR-4) |
-| `README.md` | изменить: ссылка на витрину (раздел-указатель) |
-| `CLAUDE.md` | изменить: указатель на витрину + норматив сопровождения (FR-6) |
-| `CHANGELOG.md` | изменить: запись `docs:` |
-| `docs/PRODUCT_VISION.md` | НЕ переписывать; допустима врезка-ссылка на витрину |
-| `src/**`, `docker-compose.yml`, `Dockerfile`, `requirements*` | **НЕ трогать** (NFR-1, NFR-2) |
-
-Чтение (источники истины для контента, без изменения): `src/stages.py`, `src/qg/checks.py`,
-`src/db.py`, `src/projects.py`, `src/plane_sync.py`, `src/notifications.py`, `src/queue_worker.py`,
-`src/agents/launcher.py`, `.openclaw/agents/*.md`, `docs/architecture/README.md`, `internals.md`,
-`docs/_standards/*`, `docs/architecture/adr/*`, `docs/deployment/*`, `docs/operations/*`,
-`docs/PRODUCT_VISION.md`.
-
---
-
-## 3. Функциональные требования
-
-### FR-1 — Единая точка входа и каркас витрины (BR-1, NFR-6)
- Новый каталог в `docs/` с индекс-документом, который: (а) в 1–2 абзацах отвечает «что это за
-  система»; (б) ведёт на бизнес-часть и тех-часть; (в) несёт маршруты чтения трёх аудиторий
-  (FR-5); (г) несёт норматив сопровождения (FR-6).
- Витрина модульная: отдельные файлы по частям/блокам, связанные индексом (а не один монолит) —
-  точечные правки в будущем дешевле. Точная разбивка — ADR.
- Все внутренние ссылки — относительные, валидные (проверяется тестом FR-7).
-
-### FR-2 — Бизнес-уровень (BR-2)
-Содержание (для нетехнического читателя; источники: `docs/PRODUCT_VISION.md` §1–2, `README.md`,
-`CLAUDE.md` TL;DR — со сверкой с фактическим состоянием кода):
- **Проблема и решение:** люди-бутылочное-горлышко в передачах между ролями → конвейер ИИ-агентов
-  «постановка → прод», человек = постановщик и приёмщик.
- **Что умеет (фактическое состояние, не vision):** автономный конвейер задача→прод с гейтами
-  качества; мультипроектность (несколько репо из одного инстанса); самовосстановление
-  (reconciler / job-reaper / watchdog'и / sidecar); пакетный авто-режим (serial gate ORCH-088 +
-  autoApprove/autoDeploy ORCH-089); дешёвый багфикс-трек (ORCH-019); отмена задач (STOP,
-  ORCH-090); наблюдаемость (живая Telegram-карточка, `/queue`, `/metrics`, журнал уроков);
-  самообслуживание (self-hosting — платформа дорабатывает себя); тиражируемость (Lite/Bundled,
-  ORCH-101/102/103).
- **Ценность простым языком:** скорость / стоимость / автономность / надёжность / масштаб
-  (переиспользовать формулировки PRODUCT_VISION, сверив цифры с реальностью; цифры без
-  подтверждения в репо не изобретать).
- **Сценарии использования** (минимум): «фича за вечер» (полный цикл с человеческими гейтами
-  Approved / Confirm Deploy); «багфикс по короткому маршруту» (метка Bug); «пакет задач на ночь»
-  (serial gate + авто-лейблы); «несколько проектов параллельно»; «развернуть платформу у себя»
-  (Lite/Bundled); «остановить задачу» (STOP).
- Кодовые идентификаторы (`ORCH-NNN`, имена функций) в основном бизнес-тексте не используются;
-  допустимы сноски/ссылки.
-
-### FR-3 — Технический уровень: 7 блоков с контент-картой (BR-3, BR-4)
-Каждый блок: цельное изложение + ссылки на golden source за деталями. Обязательная привязка
-к фактам кода (источники указаны; не дублировать детали сверх необходимого — link-first):
-
-| # | Блок | Обязательное содержание | Источник истины (ссылаться) |
-|---|------|------------------------|------------------------------|
-| 1 | Архитектура | компоненты и связи: FastAPI-приём вебхуков (Plane/Gitea, HMAC, дедуп), очередь jobs + worker, stage-engine, agent launcher (Claude CLI, git worktree), QG-реестр, plane-sync, notifications, фоновые демоны (reconciler, job-reaper, disk-watchdog, build-cache-pruner), sidecar-watchdog; одна диаграмма потока «вебхук → очередь → агент → гейт → переход» | `docs/architecture/README.md` «Компоненты», `internals.md`, `src/main.py` lifespan |
-| 2 | Конвейер/стадии | схема `created → analysis → architecture → development → review → testing → deploy-staging → deploy → done` (+ `cancelled`-сток); exit-гейты рёбер; под-гейты ребра `deploy-staging→deploy` (security → merge → coverage → image-freshness) и `deploy→done` (merge-verify) как врезки, не стадии; откаты REQUEST_CHANGES (max 3); человеческие гейты (Approved BRD, Confirm Deploy) и их снятие авто-лейблами; багфикс-маршрут (пропуск architecture); serial gate / freeze; статусная модель Plane = индикация ≠ управление | `src/stages.py::STAGE_TRANSITIONS`, `src/qg/checks.py::QG_CHECKS`, `docs/_standards/PIPELINE_DOCS.md` §1–3, CLAUDE.md (ORCH-059/066/088/089/019/090) |
-| 3 | Агенты | 6 ролей (analyst/architect/developer/reviewer/tester/deployer): задача роли, вход/выход, артефакты по стадиям, machine-verdict ключи; таблица модель/эффорт (резолв из config, ORCH-41/74/81); канон промптов (5 XML-секций, 52d) и где лежат промпты; handoff-протокол | `.openclaw/agents/*.md`, `docs/_standards/PIPELINE_DOCS.md` §2, `HANDOFF_PROTOCOL.md`, таблица моделей `docs/architecture/README.md` |
-| 4 | Структура объектов | каноническая модель: Project (реестр `projects.py`: plane-project → repo+prefix) → Work-Item/Task (`tasks`: stage, track, ветка) → Jobs (очередь: статусы, atomic claim, deps, ретраи/backoff/breaker) → Agent-runs (стоимость/токены/effort) → события вебхуков и дедуп → вспомогательные таблицы (`repo_freeze`, `coverage_baseline`, `tracker_messages`, `lessons`); словарь терминов (стадия/гейт/под-гейт/job/worktree/lease) | `src/db.py` (фактические таблицы), `src/projects.py`, `internals.md` «Database Schema», ADR соответствующих задач |
-| 5 | Интеграции | Plane (issues/states/labels/webhooks; статусная модель ORCH-066; вход конвейера «To Analyse»); Gitea (репо/ветки/PR; merge строго через PR-API — INV-4; merge-актор с retry ORCH-093; CI `check_ci_green`); LLM (Claude CLI, `--model`/`--effort` из config); Telegram (live-карточка bump-режима, алерты; sidecar-канал отдельно) | `src/plane_sync.py`, `src/webhooks/*`, `src/merge_gate.py`, `src/agents/launcher.py`, `src/notifications.py`, CLAUDE.md (ORCH-042/067/087/093) |
-| 6 | Качество/безопасность | философия Quality Gates: машинные вердикты только из YAML-frontmatter (никогда проза), единый контракт `src/frontmatter.py`; реестр гейтов и что каждый ловит; security-гейт (ORCH-022) и coverage-гейт с baseline-ratchet (ORCH-027); канон секретов (.env, не в гит; `gen_secrets.py`); self-hosting-страховки (staging 8501, Confirm Deploy, запрет force-push в main, никогда не ронять прод) | `src/qg/checks.py`, `src/frontmatter.py`, `docs/_standards/PIPELINE_DOCS.md` §3, CLAUDE.md «Self-hosting», `docs/operations/INFRA.md` |
-| 7 | Аналитика/наблюдаемость | живая Telegram-карточка задачи (стадии, модель/эффорт, стоимость/токены, честные метрики времени); `GET /queue` (снимки всех подсистем: serial_gate, auto_labels, bug_fast_track, coverage, lessons, reaper, reconcile, …); `GET /metrics` (машинный контракт для sidecar, schema_version); sidecar-watchdog (наблюдатель отделён от наблюдаемого); журнал уроков `lessons` (фундамент петли самообучения); стоимость по агентам (`agent_runs`) | `src/metrics.py`, `src/notifications.py`, `src/lessons.py`, `docs/architecture/README.md` (§ /metrics, § sidecar), CLAUDE.md (ORCH-098/099/100) |
-
- **Согласованность с кодом обязательна:** перечень стадий, имена гейтов, имена агентов, имена
-  таблиц в витрине должны совпадать с фактическими (`src/stages.py`, `src/qg/checks.py`,
-  `src/db.py`); расхождение — дефект (ловится FR-7 и reviewer'ом).
-
-### FR-4 — Презентационная основа и путь к PPTX (BR-5, D-1)
- В витрине есть **презентационный источник**: упорядоченная последовательность слайдов
-  (рекомендация: markdown с явной слайдо-структурой — «слайд N: заголовок / 3–5 тезисов /
-  подпись-визуал»), покрывающая бизнес-нарратив (проблема → решение → как работает → возможности →
-  сценарии → тираж → статус платформы). Объём — ориентир 12–20 слайдов (финал — у архитектора).
- Зафиксирован **воспроизводимый путь** получения `.pptx` в тёмном дизайне: либо скрипт в
-  `scripts/` (запуск вне рантайма, host/dev-окружение), либо документированная ручная процедура
-  поверх источника. Выбор инструмента (python-pptx / Marp→pptx / иное) и факт коммита бинаря —
-  решение архитектора (OQ-2, OQ-3). Требования к пути: тёмная тема, кириллица рендерится точно,
-  процедура описана пошагово с проверкой результата (паттерн «команда + Проверка:» из
-  LITE_SETUP).
- Зависимости генерации **не** попадают в прод-образ/`requirements` оркестратора (NFR-2).
-
-### FR-5 — Маршруты аудиторий (BR-6, D-2)
- Индекс несёт три явных маршрута: **заказчик** (бизнес-часть → сценарии → презентация →
-  Lite/Bundled-доки), **менеджер** (бизнес-часть → конвейер и статусная модель Plane →
-  человеческие гейты → наблюдаемость), **разработчик** (тех-часть → architecture/README →
-  internals → стандарты → ADR-реестр → CLAUDE.md).
-
-### FR-6 — Норматив сопровождения (BR-7, D-4)
- В витрине (индексе) — явная норма: «изменил функционал → обнови витрину в том же PR»
-  (формулировка по образцу NFR-5 ORCH-102/103).
- `CLAUDE.md` — краткий указатель на витрину в существующем правиле документации (§2 правил
-  агентов); reviewer-ось «обзорные доки» (ORCH-079) распространяется на витрину — фиксируется
-  формулировкой в витрине/ADR (изменение промпта reviewer'а НЕ требуется, если ось уже
-  сформулирована обобщённо — проверить при реализации; если требуется правка промпта, она
-  следует канону 52d и анти-регресс тестам `test_agent_prompts_canon.py`).
-
-### FR-7 — Структурный анти-дрейф (BR-8)
-Новый тест-модуль (паттерн `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py` /
-`test_orch_52b_docs_standard.py`; без сети/LLM/subprocess):
- наличие файлов витрины и обязательных разделов индекса (вкл. маршруты 3 аудиторий и норматив
-  сопровождения);
- **сверка карты стадий** в витрине импортом `src.stages.STAGE_TRANSITIONS` (полнота и порядок —
-  как тест полноты `_STAGE_STATUS_LABEL` ORCH-091: derive из кода, не статичный список);
- **полнота 6 агентов** (analyst/architect/developer/reviewer/tester/deployer) в блоке агентов;
- валидность относительных внутренних ссылок витрины (целевые файлы существуют);
- FORBIDDEN-скан новых доков/презент-источника: запрещённые хост-литералы (импорт списка из
-  `tests/test_no_host_hardcodes.py`, как делает `test_lite_setup_doc.py`) + секрет-эвристика;
- наличие ссылки на витрину в `README.md`.
-
---
-
-## 4. Изменения API
-**Нет.** Эндпоинты/вебхуки не добавляются и не меняются.
-
-## 5. Изменения схемы БД
-**Нет.** Таблицы/миграции не вводятся.
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Реестр `QG_CHECKS`/`check_*` не меняется. Анти-дрейф витрины — обычные pytest-тесты в
-`tests/` (исполняются существующими гейтами `check_ci_green`/`check_tests_passed`/coverage-гейтом
-штатно), **не** новый Quality Gate.
-
-## 7. Совместимость / регресс
- **Нулевая регрессия рантайма по построению:** меняются только `docs/**`, `tests/**`,
-  `README.md`, `CLAUDE.md`, `CHANGELOG.md` (+ опц. `scripts/`); `src/**` байт-в-байт. Kill-switch
-  не нужен — документация и dev-скрипт не исполняются конвейером (паттерн ORCH-009/102/103).
- Существующие тесты остаются зелёными; новые тесты аддитивны.
- enduro-trails не затрагивается (общих артефактов нет).
- Откат = revert PR (доки/тесты), без операционных последствий.
- Self-hosting: прод-контейнер не рестартится в рамках задачи; выкат — штатным маршрутом.
-
---
-
-## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR разработки)
- Витрина `docs/<…>/` (FR-1…FR-5) + презентационный источник.
- `tests/test_system_docs.py` (FR-7).
- `README.md` (ссылка), `CLAUDE.md` (указатель + норматив), `CHANGELOG.md` (`docs:`-запись).
- ADR архитектора: `docs/work-items/ORCH-011/06-adr/ADR-001-<slug>.md` (структура витрины,
-  инструмент PPTX, политика бинаря, состав тестов); при сквозной значимости — зеркало в
-  `docs/architecture/adr/`.
-
---
-
-## 9. Открытые вопросы для архитектора (не блокируют анализ)
- **OQ-1:** Имя и внутренняя структура каталога витрины (`docs/overview/` vs `docs/system/`;
-  один индекс + N файлов блоков vs два файла «business/tech»). Рекомендация аналитика —
-  `docs/overview/` с индексом и помодульными файлами (NFR-6).
- **OQ-2:** Инструмент генерации PPTX: скрипт `scripts/` (python-pptx; host/dev-venv, вне
-  прод-образа) vs конвертация из markdown (Marp и т.п.) vs документированная ручная процедура.
-  Критерии: тёмная тема, точный рендеринг кириллицы, воспроизводимость, NFR-2.
- **OQ-3:** Коммитить ли собранный `.pptx` в репо (бинарь в git) или хранить только источник +
-  процедуру сборки.
- **OQ-4:** Compiled-wiki/экспорт (упомянут в бизнес-запросе как «возможно»): фиксируем вне
-  объёма v1; нужно ли заводить follow-up work item.
- **OQ-5:** Достаточна ли текущая формулировка reviewer-оси обзорных доков (ORCH-079) для
-  покрытия витрины, или нужна точечная правка промпта reviewer (тогда — по канону 52d, с
-  обновлением `test_agent_prompts_canon.py`).
--- a/docs/work-items/ORCH-011/03-acceptance-criteria.md
+++ b/docs/work-items/ORCH-011/03-acceptance-criteria.md
@@ -1,187 +0,0 @@
---
-work_item: ORCH-011
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
---
-
-# 03 — Критерии приёмки: ORCH-011 — Полная документация системы мультиагентов
-
-Work Item: **ORCH-011** · Repo: **orchestrator** · Стадия: analysis
-
-Каждый критерий — однозначный PASS/FAIL. Reviewer/Tester проверяют буквально по файлам
-репозитория (пути витрины — те, что зафиксирует ADR архитектора; ниже «витрина» = выбранный
-каталог в `docs/`).
-
---
-
-## AC-1 — Единая точка входа существует (BR-1)
-
-**Условие:** в `docs/` создан каталог витрины с индекс-документом.
- **PASS:** индекс существует; из него по относительным ссылкам достижимы: бизнес-часть,
-  тех-часть (все 7 блоков FR-3), презентационная основа, маршруты трёх аудиторий, норматив
-  сопровождения. Каталог и индекс совпадают с зафиксированными в ADR-001 путями.
- **FAIL:** индекса нет, ИЛИ хотя бы одна из перечисленных частей недостижима из индекса.
-
---
-
-## AC-2 — Бизнес-уровень самодостаточен для нетехнического читателя (BR-2)
-
-**Условие:** бизнес-часть содержит все 5 обязательных смысловых разделов.
- **PASS:** присутствуют разделы: (1) проблема, которую решает оркестратор; (2) суть решения
-  (конвейер агентов, человек = постановщик/приёмщик); (3) что умеет — фактические способности
-  (минимум: автономный конвейер задача→прод, мультипроектность, самовосстановление, пакетный
-  авто-режим, багфикс-трек, отмена STOP, наблюдаемость, self-hosting, тиражируемость
-  Lite/Bundled); (4) ценность (скорость/стоимость/автономность/надёжность/масштаб);
-  (5) сценарии использования (минимум 5 из перечня FR-2). В основном тексте нет необъяснённых
-  кодовых идентификаторов/имён функций.
- **FAIL:** отсутствует любой из 5 разделов, ИЛИ способности из обязательного минимума
-  пропущены, ИЛИ текст оперирует жаргоном без объяснения.
-
---
-
-## AC-3 — Тех-уровень покрывает 7 блоков (BR-3)
-
-**Условие:** тех-часть содержит все блоки контент-карты TRZ §3 FR-3.
- **PASS:** присутствуют и непусты блоки: 1) архитектура/компоненты (включая фоновые демоны и
-  sidecar), 2) конвейер/стадии/гейты (включая под-гейты и человеческие гейты), 3) агенты,
-  4) структура объектов/каноническая модель, 5) интеграции (Plane/Gitea/LLM/Telegram),
-  6) качество/безопасность, 7) аналитика/наблюдаемость. Блок 1 содержит хотя бы одну
-  диаграмму/схему потока (текстовую ASCII или mermaid).
- **FAIL:** любой блок отсутствует/пуст, ИЛИ схема потока отсутствует.
-
---
-
-## AC-4 — Карта стадий и гейтов сходится с кодом (BR-3, FR-7)
-
-**Условие:** конвейер в витрине = `src/stages.py::STAGE_TRANSITIONS` + реестр `QG_CHECKS`.
- **PASS:** все стадии из `STAGE_TRANSITIONS` (включая `deploy-staging` и сток `cancelled`)
-  присутствуют в витрине в правильном порядке; exit-гейты рёбер названы фактическими именами
-  (`check_analysis_approved` … `check_deploy_status`); под-гейты ребра
-  `deploy-staging→deploy` описаны в фактическом порядке (security → merge → coverage →
-  image-freshness) и явно помечены как врезки, не стадии. Структурный тест сверяет перечень
-  стадий импортом `src.stages.STAGE_TRANSITIONS` и зелёный.
- **FAIL:** стадия/гейт пропущены или названы несуществующим именем, ИЛИ порядок противоречит
-  коду, ИЛИ тест-сверка отсутствует/красная.
-
---
-
-## AC-5 — Агенты: 6 ролей с полным паспортом (BR-3)
-
-**Условие:** блок агентов описывает все 6 ролей.
- **PASS:** для каждой роли (analyst, architect, developer, reviewer, tester, deployer) указаны:
-  назначение, стадия работы, вход, выходные артефакты (по `PIPELINE_DOCS.md` §2) и
-  machine-verdict ключ (где есть: `verdict:`/`result:`/`staging_status:`/`deploy_status:`);
-  присутствует таблица модель/эффорт, совпадающая с фактическим резолвом config (ORCH-41/81:
-  developer=`xhigh`, tester/deployer=`medium`, прочие=`high`). Структурный тест полноты 6 ролей
-  зелёный.
- **FAIL:** роль пропущена, ИЛИ артефакты/ключи противоречат `PIPELINE_DOCS.md`, ИЛИ таблица
-  модель/эффорт расходится с config.
-
---
-
-## AC-6 — Link-first: ссылки валидны, канон не форкается (BR-4)
-
-**Условие:** витрина ссылается на golden sources, не подменяя их.
- **PASS:** витрина содержит работающие относительные ссылки минимум на:
-  `docs/architecture/README.md`, `docs/architecture/internals.md`,
-  `docs/_standards/PIPELINE_DOCS.md`, `docs/_standards/HANDOFF_PROTOCOL.md`, реестр
-  `docs/architecture/adr/`, `docs/deployment/LITE_SETUP.md`, `docs/deployment/BUNDLED_SETUP.md`,
-  `docs/PRODUCT_VISION.md`, `CLAUDE.md`. Все относительные ссылки витрины резолвятся в
-  существующие файлы (структурный тест зелёный). Существующие golden sources не удалены и не
-  переписаны (допустимы только врезки-ссылки).
- **FAIL:** битая ссылка, ИЛИ обязательная ссылка отсутствует, ИЛИ витрина дублирует-подменяет
-  существующий golden source (например, копия таблицы компонентов architecture/README вместо
-  ссылки с кратким резюме).
-
---
-
-## AC-7 — Презентационная основа и путь к PPTX (BR-5)
-
-**Условие:** слайдовый источник существует; путь к `.pptx` воспроизводим.
- **PASS:** в витрине есть презентационный источник с явной слайдо-структурой (нумерованные
-  слайды: заголовок + тезисы), покрывающий бизнес-нарратив FR-4 (проблема → решение → как
-  работает → возможности → сценарии → тираж → статус); зафиксирована пошаговая воспроизводимая
-  процедура получения `.pptx` в тёмном дизайне (скрипт `scripts/` ИЛИ документированная
-  процедура — по ADR-001), каждая команда — с проверкой результата; зависимости генерации
-  отсутствуют в `requirements*` и `Dockerfile` оркестратора (NFR-2).
- **FAIL:** источника нет, ИЛИ слайдо-структура не выражена, ИЛИ путь к `.pptx` не описан /
-  невоспроизводим, ИЛИ зависимость генерации попала в прод-образ.
-
---
-
-## AC-8 — Маршруты трёх аудиторий (BR-6)
-
-**Условие:** индекс несёт маршруты чтения.
- **PASS:** в индексе явно выделены 3 маршрута — заказчик, менеджер проекта, разработчик — каждый
-  с упорядоченным списком «что читать» (состав по FR-5).
- **FAIL:** хотя бы один маршрут отсутствует или пуст.
-
---
-
-## AC-9 — Норматив сопровождения зафиксирован (BR-7)
-
-**Условие:** правило актуальности витрины закреплено.
- **PASS:** индекс витрины несёт норму «изменил функционал → обнови витрину в том же PR»;
-  `CLAUDE.md` содержит указатель на витрину; в ADR-001 зафиксировано, как reviewer-ось обзорных
-  доков (ORCH-079) покрывает витрину (с правкой промпта reviewer или обоснованием, что правка
-  не нужна; при правке промпта — канон 52d сохранён и `tests/test_agent_prompts_canon.py`
-  зелёный).
- **FAIL:** норматив отсутствует в витрине, ИЛИ CLAUDE.md не обновлён, ИЛИ вопрос reviewer-оси
-  не разрешён в ADR.
-
---
-
-## AC-10 — Анти-дрейф тесты существуют и зелёные (BR-8)
-
-**Условие:** структурный тест-модуль витрины создан и проходит.
- **PASS:** новый тест-модуль (паттерн `test_lite_setup_doc.py`) покрывает: наличие
-  файлов/разделов витрины, сверку стадий импортом `STAGE_TRANSITIONS`, полноту 6 агентов,
-  валидность относительных ссылок, FORBIDDEN-скан (импорт запрещённых литералов из
-  `tests/test_no_host_hardcodes.py` + секрет-эвристика) по новым докам и презентационному
-  источнику, наличие ссылки на витрину в `README.md`. `pytest tests/ -q` полностью зелёный.
- **FAIL:** тест-модуль отсутствует, ИЛИ любая из перечисленных проверок не реализована, ИЛИ
-  pytest красный.
-
---
-
-## AC-11 — Рантайм не тронут; указатели обновлены (NFR-1, BR-9)
-
-**Условие:** изменение строго docs+tests(+опц. scripts).
- **PASS:** diff PR не содержит изменений `src/**`, `docker-compose.yml`, `Dockerfile`,
-  `requirements*`, схемы БД; `README.md` ссылается на витрину; `CHANGELOG.md` несёт
-  `docs:`-запись по ORCH-011; в новых файлах нет секретов/боевых токенов/хост-хардкодов
-  (FORBIDDEN-скан AC-10 зелёный).
- **FAIL:** любой файл рантайма изменён, ИЛИ указатели не обновлены, ИЛИ найден
-  секрет/хост-хардкод.
-
---
-
-## AC-12 — Самодостаточность против вне-репозиторных источников (допущение BRD §6)
-
-**Условие:** витрина не зависит от файлов вне репо.
- **PASS:** витрина не содержит ссылок на вне-репозиторные пути (`tasks/…`, `memory/…`,
-  локальные пути хоста); всё содержание подтверждается внутрирепозиторными источниками.
- **FAIL:** есть ссылка на файл, отсутствующий в репозитории, или цитата «по памяти» без
-  внутрирепозиторного источника.
-
---
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-2 |
-| AC-3 | BR-3 / FR-3 |
-| AC-4 | BR-3, BR-8 / FR-3, FR-7 |
-| AC-5 | BR-3 / FR-3 |
-| AC-6 | BR-4 / FR-1, FR-3 |
-| AC-7 | BR-5 / FR-4, NFR-2 |
-| AC-8 | BR-6 / FR-5 |
-| AC-9 | BR-7 / FR-6 |
-| AC-10 | BR-8 / FR-7 |
-| AC-11 | BR-9, NFR-1, NFR-3 |
-| AC-12 | BRD §6 (допущения), NFR-3 |
--- a/docs/work-items/ORCH-011/04-test-plan.yaml
+++ b/docs/work-items/ORCH-011/04-test-plan.yaml
@@ -1,117 +0,0 @@
-work_item: ORCH-011
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-title: "Полная документация системы мультиагентов: структурный анти-дрейф витрины"
-framework: pytest
-scope: >
-  Покрывается: каркас витрины (файлы/разделы/маршруты/норматив), сходимость
-  машинно-проверяемых фактов с кодом (стадии из STAGE_TRANSITIONS, 6 агентов),
-  валидность внутренних ссылок, отсутствие секретов/хост-хардкодов, обновление
-  указателей README/CLAUDE.md, неизменность рантайма (полный регресс).
-  Вне покрытия: качество прозы/дизайна слайдов (проверяет reviewer/человек),
-  фактический рендеринг .pptx (ручная проверка по процедуре AC-7).
-notes: >
-  Все тесты — структурные, без сети/LLM/subprocess (паттерн tests/test_lite_setup_doc.py,
-  test_bundled_setup_doc.py, test_orch_52b_docs_standard.py). Точные пути витрины фиксирует
-  ADR-001 архитектора (рекомендация TRZ: docs/overview/); имя тест-модуля ниже —
-  tests/test_system_docs.py — может быть уточнено в ADR, состав проверок обязателен.
-  Сверки derive-из-кода (стадии) обязаны импортировать src.stages, а не дублировать
-  статичный список (анти-дрейф, образец — тест полноты ORCH-091). FORBIDDEN-скан
-  импортирует список запрещённых литералов из tests/test_no_host_hardcodes.py.
-  Полный регресс tests/ должен оставаться зелёным.
-
-tests:
-  # ---- FR-1: каркас витрины и единая точка входа ----
-  - id: TC-01
-    type: unit
-    description: "Каталог витрины и индекс существуют; индекс содержит обязательные разделы: вход «что это», ссылки на бизнес-часть и тех-часть, маршруты аудиторий, норматив сопровождения (AC-1)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Из индекса по относительным ссылкам достижимы все файлы витрины: бизнес-часть, тех-блоки 1–7, презентационный источник (AC-1/AC-3)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- FR-2: бизнес-уровень ----
-  - id: TC-03
-    type: unit
-    description: "Бизнес-часть содержит 5 обязательных смысловых разделов (проблема, решение, что умеет, ценность, сценарии) и минимум 5 сценариев использования (AC-2)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- FR-3: тех-уровень, сходимость с кодом ----
-  - id: TC-04
-    type: unit
-    description: "Тех-часть содержит все 7 блоков контент-карты (архитектура, конвейер, агенты, объекты, интеграции, качество/безопасность, наблюдаемость); блок архитектуры несёт схему потока (AC-3)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Карта стадий витрины сверена импортом src.stages.STAGE_TRANSITIONS: каждая стадия (включая deploy-staging и cancelled) упомянута; derive из кода, не статичный список (AC-4)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Имена exit-гейтов рёбер в витрине существуют в реестре qg.checks.QG_CHECKS (нет выдуманных имён гейтов) (AC-4)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Блок агентов покрывает все 6 ролей (analyst/architect/developer/reviewer/tester/deployer); каждой роли сопоставлены артефакты; таблица модель/эффорт присутствует (AC-5)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- FR-1/FR-3: link-first ----
-  - id: TC-08
-    type: unit
-    description: "Все относительные ссылки витрины резолвятся в существующие файлы; обязательные ссылки на golden sources (architecture/README, internals, PIPELINE_DOCS, HANDOFF_PROTOCOL, adr/, LITE_SETUP, BUNDLED_SETUP, PRODUCT_VISION, CLAUDE.md) присутствуют (AC-6)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "Витрина не ссылается на вне-репозиторные пути (tasks/, memory/, абсолютные пути хоста) (AC-12)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- FR-4: презентационная основа ----
-  - id: TC-10
-    type: unit
-    description: "Презентационный источник существует, несёт явную слайдо-структуру (нумерованные слайды с заголовками, не менее 12) и покрывает обязательный нарратив (проблема/решение/как работает/возможности/сценарии/тираж) (AC-7)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Зависимости генерации презентации не попали в прод-образ: requirements*/Dockerfile не содержат библиотек генерации (например python-pptx) (AC-7/NFR-2)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- FR-6: норматив и указатели ----
-  - id: TC-12
-    type: unit
-    description: "Индекс витрины несёт норматив сопровождения («в том же PR»); README.md содержит ссылку на витрину; CLAUDE.md содержит указатель (AC-9/AC-11)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- NFR-3: секреты/хост-хардкоды ----
-  - id: TC-13
-    type: unit
-    description: "FORBIDDEN-скан новых доков и презентационного источника: запрещённые хост-литералы (импорт из tests/test_no_host_hardcodes.py) и секрет-эвристика не находят совпадений (AC-10/AC-11)."
-    module: tests/test_system_docs.py
-    expected: PASS
-
-  # ---- Регресс ----
-  - id: TC-14
-    type: integration
-    description: "Полный регресс: pytest tests/ -q зелёный; существующие структурные док-тесты (test_lite_setup_doc, test_bundled_setup_doc, test_orch_52b_docs_standard, test_agent_prompts_canon) не сломаны (AC-10/AC-11)."
-    module: tests/
-    expected: PASS
--- a/docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md
+++ b/docs/work-items/ORCH-011/06-adr/ADR-001-system-overview-canon.md
@@ -1,388 +0,0 @@
---
-work_item: ORCH-011
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-11
-model_used: claude-opus-4-8
---
-
-# ADR-001: Витрина системы `docs/overview/` — структура, путь к PPTX, анти-дрейф контур
-
-Work Item: **ORCH-011** — Полная документация системы мультиагентов оркестратора (бизнес + тех, для людей и презентаций)
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0039-system-overview-docs-canon.md`**
-(новый docs-раздел `docs/overview/` с нормативом сопровождения, обязательным для всех будущих
-функциональных PR, + расширение reviewer-оси обзорных доков ORCH-079 — кросс-каттинг).
-
-## Статус
-Proposed
-
-## Контекст
-
-Решения Владельца (BRD §1.4): D-1 презентация = PowerPoint, тёмный дизайн, точный рендеринг;
-D-2 три аудитории (разработчики/заказчики/менеджеры); D-3 единое место — `docs/` репозитория;
-D-4 витрина поддерживается актуальной сразу после изменения функционала.
-
-Факты, сверенные с кодом/репо на ветке задачи:
-
- **Документация богатая, но фрагментированная** (BRD §1.2, проверено): паспорт `CLAUDE.md`
-  (реестр доработок, не вводный текст), тех-витрина `README.md`, vision
-  `docs/PRODUCT_VISION.md` (v1.0, «концепция развития»), инженерный справочник
-  `docs/architecture/README.md` (~1246 строк) + `internals.md`, 38 сквозных ADR, стандарты
-  `docs/_standards/`, операционные/деплойные доки. Единой точки входа «бизнес + тех» нет.
- **Живое доказательство риска гниения (R-1):** схема конвейера в `docs/PRODUCT_VISION.md` §2
-  уже устарела — в ней нет стадии `deploy-staging` и стока `cancelled`, фактически
-  присутствующих в `src/stages.py::STAGE_TRANSITIONS` (9 ключей + `cancelled`). Снапшот без
-  машинной сверки расходится с кодом за недели.
- **Прецедент бинаря без воспроизводимости:** `docs/PRODUCT_VISION.pptx` закоммичен, но пути
-  его генерации в репо нет (`grep pptx scripts/ docs/` — пусто) — ровно тот паттерн
-  «невоспроизводимый артефакт», который BR-5 требует исключить.
- **Reviewer-ось обзорных доков (ORCH-079) по букве привязана к README:**
-  `.openclaw/agents/reviewer.md` формулирует ось через «пункт из `README.md` „Известные
-  ограничения“»; новая витрина под букву оси не подпадает (релевантно OQ-5). История ORCH-079
-  показывает: общего правила «документация = golden source» недостаточно — обзорные доки гниют,
-  пока ось не названа явно.
- **Тестовая механика готова:** паттерны структурных доков-тестов —
-  `tests/test_lite_setup_doc.py` / `test_bundled_setup_doc.py` (разделы по порядку, кирпичи,
-  скан FORBIDDEN импортом из `tests/test_no_host_hardcodes.py` (`FORBIDDEN`,
-  `find_violations`), секрет-эвристика, кросс-рефы); импорт `STAGE_TRANSITIONS` в тестах —
-  норма (ORCH-091: полнота derive из кода, не статичный список); импорт `QG_CHECKS` —
-  `tests/test_qg_registry_snapshot.py`; импорт чистых функций из `scripts/` —
-  `tests/test_bootstrap_script.py`.
- **Источники контента самодостаточны внутри репо** (BRD §6): вне-репозиторные затравки
-  (`tasks/…`, `memory/…`) недоступны и не нужны; таблица модель/эффорт — ORCH-41/81
-  (developer=`xhigh`, tester/deployer=`medium`, прочие=`high`, все на `claude-opus-4-8`).
- `docs/overview/` свободен (коллизий имён нет).
-
-Задача — **docs+tests (+dev-скрипт)** (паттерн ORCH-102/103): `src/**`,
-`docker-compose.yml`, `Dockerfile`, `requirements*` читаются как источник истины и НЕ меняются;
-конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
-Kill-switch не нужен: документация и dev-скрипт конвейером не исполняются (активация генерации —
-только явный запуск человеком, паттерн ORCH-009).
-
-## Решение
-
-### Сводка
-
-Создаётся новый docs-раздел **`docs/overview/`** — витрина системы: индекс `README.md`
-(точка входа, маршруты трёх аудиторий, норматив сопровождения), бизнес-часть `business.md`,
-семь тех-файлов `tech-*.md` (= 7 блоков контент-карты TRZ FR-3, link-first), слайдо-источник
-`presentation.md` + dev-скрипт `scripts/build_presentation.py` (python-pptx, вне прод-образа;
-бинарь `.pptx` НЕ коммитится — D5). Машинно-проверяемые факты витрины (стадии, гейты, агенты,
-ссылки, гигиена секретов, слайдо-структура, чистота prod-зависимостей) защищаются структурным
-`tests/test_system_docs.py` (D6). Reviewer-ось обзорных доков точечно расширяется на витрину
-(D7). Исходы всех открытых вопросов ТЗ §9 (OQ-1…OQ-5) — в D1/D4/D5/D9/D7 соответственно.
-
-### D1 (исход OQ-1) — Размещение и состав: `docs/overview/`, плоский каталог, 10 файлов
-
-**Решение: каталог `docs/overview/`** (рекомендация аналитика подтверждена). Семантика
-docs-разделов после ORCH-011: `overview/` — «что это за система и как она устроена» (читатель —
-любой из трёх аудиторий, входит впервые); `architecture/` — инженерный справочник (детали);
-`deployment/` — «как развернуть у себя» (ORCH-102/103); `operations/` — «как эксплуатировать
-наш прод»; `_standards/` — нормативы для агентов.
-
-**Состав — плоский каталог, 10 файлов** (модульность NFR-6: будущие правки точечные; плоскость —
-одна глубина относительных ссылок и простые globs в тестах; индекс — `README.md`, а не
-`index.md`: авто-рендер в web-UI Gitea, симметрия `docs/architecture/README.md`):
-
-| Файл | Содержание | Покрывает |
-|------|-----------|-----------|
-| `README.md` | индекс: «что это» в 1–2 абзацах; навигация на все части; 3 маршрута аудиторий (D8); норматив сопровождения (D8) | FR-1, FR-5, FR-6, AC-1, AC-8, AC-9 |
-| `business.md` | бизнес-уровень (D2) | FR-2, AC-2 |
-| `tech-architecture.md` | блок 1: компоненты и связи + диаграмма потока | FR-3.1, AC-3 |
-| `tech-pipeline.md` | блок 2: конвейер/стадии/гейты/под-гейты/откаты/человеческие гейты/авто-лейблы/багфикс-трек/serial gate/статусная модель Plane | FR-3.2, AC-4 |
-| `tech-agents.md` | блок 3: 6 ролей, входы/выходы/артефакты/verdict-ключи, таблица модель/эффорт, канон промптов | FR-3.3, AC-5 |
-| `tech-data-model.md` | блок 4: Project → Work-Item/Task → Jobs → Agent-runs → события/дедуп → вспомогательные таблицы; словарь терминов | FR-3.4 |
-| `tech-integrations.md` | блок 5: Plane / Gitea / LLM / Telegram | FR-3.5 |
-| `tech-quality-security.md` | блок 6: философия QG, frontmatter-контракт, security/coverage-гейты, канон секретов, self-hosting-страховки | FR-3.6 |
-| `tech-observability.md` | блок 7: live-карточка, `/queue`, `/metrics`, sidecar, журнал уроков, стоимость | FR-3.7 |
-| `presentation.md` | слайдо-источник + процедура сборки `.pptx` (D4) | FR-4, AC-7 |
-
-Один тех-блок = один файл (а не монолит `tech.md` и не два файла «business/tech»): блоки
-независимы по темпу устаревания (pipeline меняется чаще, чем интеграции), точечный PR правит
-один файл; тесту проще ассертить присутствие и непустоту каждого блока пофайлово.
-
-Привязка: BR-1, NFR-6, AC-1, AC-3.
-
-### D2 — Бизнес-уровень: текущее состояние, не vision; числа только с подтверждением
-
-**Решение: `business.md` описывает фактическое состояние платформы** (контент-минимум FR-2:
-проблема → решение → что умеет → ценность → ≥5 сценариев), переиспользуя нарратив
-`docs/PRODUCT_VISION.md` §1–2 со сверкой с кодом. Нормативные правила:
-
- **Разделение ролей документов:** PRODUCT_VISION остаётся vision («куда идём», не трогается;
-  допустима врезка-ссылка на витрину — на усмотрение developer); `business.md` — «что есть
-  сейчас». Расхождение vision ↔ код (пример: устаревшая схема конвейера в vision §2) в витрину
-  не переносится — витрина строится от `STAGE_TRANSITIONS`.
- **Числовые метрики** (скорость/стоимость) — только с внутрирепозиторным подтверждением либо
-  с явной атрибуцией «оценка из PRODUCT_VISION»; новые цифры не изобретать (FR-2, AC-12).
- **Без жаргона:** кодовые идентификаторы (`ORCH-NNN`, имена функций/модулей) в основном тексте
-  не используются; термины конвейера (стадия, гейт, ревью) объясняются по-человечески; детали —
-  сносками/ссылками в тех-часть (AC-2).
- Обязательный минимум способностей — список AC-2 (конвейер задача→прод, мультипроектность,
-  самовосстановление, пакетный авто-режим, багфикс-трек, STOP, наблюдаемость, self-hosting,
-  тираж Lite/Bundled) — каждый пункт сводится к одному абзацу простым языком.
-
-Привязка: BR-2, FR-2, AC-2, AC-12.
-
-### D3 — Тех-уровень: 7 файлов по контент-карте TRZ, link-first, согласованность с кодом
-
-**Решение: контент-карта TRZ §3 FR-3 принимается как нормативная** (обязательное содержание и
-источники истины каждого блока — таблица FR-3, в ADR не дублируется). Архитектурные уточнения:
-
- **Link-first (BR-4, анти-«вторая правда»):** каждый файл даёт цельную картину уровня
-  «понять устройство» и ведёт ссылкой в golden source за деталями
-  (`docs/architecture/README.md`, `internals.md`, `_standards/*`, ADR-реестр, deployment-доки).
-  Запрещено копировать в витрину таблицы/списки, которые живут в golden source и меняются с
-  кодом (таблица компонентов, карта env, 22 статуса Plane). Разрешённый дубль — только
-  машинно-сверяемый тестом факт (перечень стадий, имена гейтов, 6 агентов, таблица
-  модель/эффорт) — ровно потому, что тест D6 рвёт CI при дрейфе (прецедент — key-sync TC-02b
-  ORCH-102).
- **`tech-architecture.md` несёт одну диаграмму потока** «вебхук → очередь → агент → гейт →
-  переход» (mermaid или ASCII — на выбор developer; AC-3 требует хотя бы одну).
- **`tech-pipeline.md`:** схема стадий включает `deploy-staging` и сток `cancelled`; под-гейты
-  ребра `deploy-staging→deploy` перечисляются в фактическом порядке **security → merge →
-  coverage → image-freshness** (нормативный порядок — adr-0029/ORCH-027) и явно помечаются как
-  **врезки в переход, а не стадии** (AC-4); под-гейт `deploy→done` (merge-verify) — аналогично;
-  человеческие гейты (Approved, Confirm Deploy) и их снятие авто-лейблами (ORCH-089), STOP
-  (ORCH-090), багфикс-маршрут (ORCH-019), serial gate/freeze (ORCH-088); «статусы Plane =
-  индикация ≠ управление» (ORCH-066).
- **`tech-agents.md`:** паспорт каждой из 6 ролей по `PIPELINE_DOCS.md` §2 (назначение, стадия,
-  вход, артефакты, machine-verdict ключ — имена байт-в-байт: `verdict:`/`result:`/
-  `staging_status:`/`deploy_status:`/`security_status:`); таблица модель/эффорт = фактический
-  резолв config (ORCH-41/74/81).
- **Терминология** едина со статусной моделью Plane (ORCH-066) и PIPELINE_DOCS (NFR-4); язык —
-  русский.
-
-Привязка: BR-3, BR-4, FR-3, AC-3…AC-6.
-
-### D4 (исход OQ-2) — Презентация: `presentation.md` (машинно-парсимый источник) + `scripts/build_presentation.py` на python-pptx
-
-**Решение: слайдо-источник — `docs/overview/presentation.md`** с жёсткой машинно-парсимой
-структурой:
-
-```markdown
-## Слайд N: <Заголовок>
- <тезис 1>            (3–6 тезисов на слайд)
- <тезис 2>
-> Визуал: <подпись визуального мотива слайда>   (опционально)
-```
-
-Нумерация сквозная с 1; объём — **14–18 слайдов** (в коридоре ориентира FR-4 12–20);
-нормативные смысловые биты нарратива (порядок FR-4): проблема → решение → как работает
-(конвейер+гейты) → роли агентов → человек в контуре → возможности (автономный пакетный режим,
-багфикс-трек, самовосстановление, наблюдаемость) → сценарии → тираж → статус платформы.
-Точная нарезка по слайдам — за developer; тест D6 ассертит структуру и биты, не прозу.
-
-**Генератор — `scripts/build_presentation.py` на `python-pptx`:**
-
- **Запуск только вне рантайма** (host/dev venv, явный запуск человеком — паттерн ORCH-009);
-  `python-pptx` НЕ добавляется в `requirements*`/`Dockerfile` (NFR-2; машинный гард — D6 TC-09).
- **Архитектура скрипта:** чистая функция-парсер `parse_slides(text) -> list[Slide]`
-  (stdlib-only, без импорта pptx) + рендерер с **ленивым** `import pptx` внутри функции сборки.
-  Один парсер = один источник истины о формате: `tests/test_system_docs.py` импортирует
-  `parse_slides` (механика импорта из `scripts/` — прецедент `test_bootstrap_script.py`) и
-  валидирует слайдо-источник без установленного python-pptx.
- **Тёмный дизайн (D-1):** константы темы в скрипте — тёмный фон (≈`#1F1F2E`), светлый текст,
-  один акцентный цвет; шрифты — стандартные системные с полной кириллицей (Calibri/Arial).
-  python-pptx пишет **настоящий редактируемый текст** в slide-объекты → «точный рендеринг»
-  гарантирован самим PowerPoint (а не headless-браузером), кириллица не растрируется, Владелец
-  может править слайды руками.
- **Процедура — в `presentation.md`**, раздел «Как собрать .pptx», форма «fenced-команда +
-  Проверка:» (канон LITE_SETUP): создать venv → `pip install python-pptx` → запуск скрипта →
-  проверка (скрипт печатает число собранных слайдов; файл открывается, тема тёмная). Дефолтный
-  выход — `build/orchestrator-overview.pptx` (D5).
-
-**Почему python-pptx, а не альтернативы:** Marp → pptx требует Node+Chromium и экспортирует
-слайды растровыми картинками (нередактируемо, текст не выделяется — против «точного
-рендеринга» как редактируемого артефакта); pandoc → pptx ограниченно управляет тёмной темой
-(reference-doc с мастер-слайдами — отдельный бинарный артефакт в репо); «только ручная
-процедура» — слабейшая воспроизводимость (человек = источник дрейфа). python-pptx: один
-pip-пакет в одноразовом dev-venv, детерминированный код-как-дизайн, тестируемый парсер.
-
-Привязка: BR-5, FR-4, AC-7, NFR-2.
-
-### D5 (исход OQ-3) — Бинарь `.pptx` НЕ коммитится; источник истины — markdown + скрипт
-
-**Решение: собранный `.pptx` в git НЕ коммитится.** Канон: источник истины —
-`presentation.md` + `build_presentation.py`; артефакт собирается по требованию за одну команду.
-Обоснование: бинарь не диффуем, анти-дрейф тесты его содержимое не проверяют → закоммиченный
-deck молча устаревает относительно источника (живой пример — `docs/PRODUCT_VISION.pptx`:
-закоммичен, пути генерации нет, контент vision уже разошёлся с кодом); BR-5 требует
-воспроизводимость пути, не бинарь (BRD §6).
-
- Дефолтный выход генератора — `build/orchestrator-overview.pptx`; в `.gitignore` добавляется
-  строка `build/` (разрешённое отклонение диффа, не рантайм).
- **Существующий `docs/PRODUCT_VISION.pptx` не трогается** (артефакт другого work item;
-  ретроактивная чистка — вне объёма §2.2). Новый канон действует на витрину и вперёд.
-
-Привязка: BR-5, AC-7, BRD §6.
-
-### D6 (FR-7) — Анти-дрейф контур: `tests/test_system_docs.py`
-
-**Решение: один структурный модуль, детерминированный, без сети/LLM/subprocess** (образец —
-`test_lite_setup_doc.py`/`test_bundled_setup_doc.py`). Нормативные семейства проверок (точная
-нарезка по тест-функциям — за developer, `04-test-plan.yaml` дополняется на development):
-
-| TC | Проверка | Механика |
-|----|----------|----------|
-| TC-01 | Все 10 файлов витрины D1 существуют и непусты | `Path.exists()` + размер |
-| TC-02 | Индекс: 3 маршрута аудиторий («Я заказчик» / «Я менеджер» / «Я разработчик») и норматив сопровождения присутствуют; из индекса по относительным ссылкам достижимы business / все 7 tech / presentation (AC-1) | regex-извлечение ссылок + подстроки |
-| TC-03 | **Карта стадий = код:** каждый ключ `src.stages.STAGE_TRANSITIONS` (вкл. `deploy-staging`, `cancelled`) упомянут в `tech-pipeline.md`; порядок основной цепочки created→…→done — по возрастанию позиций вхождений; derive из импорта, не статичный список (паттерн ORCH-091) | `import src.stages` + поиск позиций |
-| TC-04 | **Гейты = код:** имя exit-гейта каждого ребра (`qg` из `STAGE_TRANSITIONS`) упомянуто в `tech-pipeline.md`; под-гейты названы фактическими именами реестра `QG_CHECKS` (`check_security_gate`, `check_branch_mergeable`, `check_coverage_gate`, `check_staging_image_fresh`) и идут в нормативном порядке security → merge → coverage → image-freshness (порядок — фикс adr-0029, позиционный ассерт); рядом с под-гейтами есть маркер «не стадии» (врезки) | импорт `STAGE_TRANSITIONS` + `QG_CHECKS`, позиции подстрок |
-| TC-05 | **Полнота 6 агентов:** derive из glob `.openclaw/agents/*.md` (не статичный список) — стем каждого файла упомянут в `tech-agents.md`; таблица эффортов сходится с config-дефолтами (поля class-default `agent_effort_<role>`, ORCH-81) | glob + `import src.config` |
-| TC-06 | **Валидность ссылок:** все относительные md-ссылки всех файлов витрины резолвятся в существующие файлы; обязательный список ссылок AC-6 (architecture/README, internals, PIPELINE_DOCS, HANDOFF_PROTOCOL, adr-реестр, LITE_SETUP, BUNDLED_SETUP, PRODUCT_VISION, CLAUDE.md) присутствует | regex `\[..\]\((..)\)` + `Path.exists()` относительно файла |
-| TC-07 | **Гигиена:** полнотекстовый скан всех 10 файлов витрины — нет литералов центрального списка `FORBIDDEN` (импорт из `tests/test_no_host_hardcodes.py`, не копия) и секретоподобных значений (эвристика hex/base64 ≥ 32 симв., не плейсхолдер); нет ссылок на вне-репозиторные пути (`tasks/`, `memory/`) (AC-12) | `find_violations` + эвристика |
-| TC-08 | **Слайдо-источник:** парс через `parse_slides` из `scripts/build_presentation.py` (один парсер — D4): ≥ 12 слайдов, нумерация сквозная с 1, на каждом ≥ 1 тезис; нормативные биты нарратива FR-4 присутствуют (подстроки: проблема/решение/сценарии/тираж/статус) | импорт чистой функции (прецедент `test_bootstrap_script.py`) |
-| TC-09 | **NFR-2 машинно:** подстрока `pptx` отсутствует в `requirements*` и `Dockerfile` | чтение файлов |
-| TC-10 | **Указатели:** `README.md` ссылается на `docs/overview/`; `CLAUDE.md` несёт указатель на витрину; `CHANGELOG.md` несёт `ORCH-011` | подстроки |
-
-Скоуп FORBIDDEN-скана — **полнотекстовый** (не только fenced, в отличие от ORCH-102 TC-05):
-витрина по построению не дублирует дефолты/хост-специфику даже в прозе (NFR-3), упоминать
-боевые литералы ей незачем → ложно-красных нет, а защита шире. Существующие тесты не
-ослабляются; новые попадают в существующие гейты (`check_ci_green`/`check_tests_passed`/
-merge-gate re-test/coverage ORCH-027) автоматически — **новый QG НЕ регистрируется** (ТЗ §6).
-
-Привязка: BR-8, FR-7, AC-4, AC-5, AC-10, AC-11, AC-12.
-
-### D7 (исход OQ-5) — Reviewer-ось обзорных доков: точечная правка промпта НУЖНА
-
-**Решение: расширить существующую ось ORCH-079 в `.openclaw/agents/reviewer.md` точечной
-врезкой, называющей витрину явно.** Обоснование: по букве ось привязана к `README.md`
-«Известные ограничения» («если PR закрывает/меняет пункт из README…»); витрина под букву не
-подпадает, а история ORCH-079 показала, что общего правила «документация = golden source»
-для обзорных доков недостаточно — ось работает, когда названа явно (❌→✅-паттерн). Норматив
-правки:
-
- В оси 4 «Документация» и в соответствующем ❌→✅-пункте `<constraints>` существующая
-  формулировка ORCH-079 дополняется: *PR меняет функциональность, описанную в витрине
-  `docs/overview/` (стадии, гейты, агенты, интеграции, способности из business.md), а витрина
-  не обновлена → finding ≥ P1* — **расширение трактовки той же оси, не новая ось**.
- Канон 52d сохраняется байт-в-байт: 5 XML-секций и их порядок не меняются, verdict-ключ
-  `verdict: APPROVED|REQUEST_CHANGES` не трогается; правка — добавление текста внутрь
-  существующих секций (паттерн самой ORCH-079).
- `tests/test_agent_prompts_canon.py` расширяется ассертом на упоминание витрины в оси
-  обзорных доков (анти-регресс; существующие ассерты остаются зелёными).
- Зеркальная правка правила №6 `CLAUDE.md` («Reviewer проверяет…») — упоминание витрины.
-
-Привязка: BR-7, FR-6, AC-9.
-
-### D8 — Индекс: маршруты аудиторий и норматив сопровождения; указатели репо
-
-**Маршруты (FR-5, нормативный состав):** индекс несёт три явных маршрута с упорядоченными
-списками «что читать»:
- **«Я заказчик»:** `business.md` → сценарии → `presentation.md` →
-  `docs/deployment/LITE_SETUP.md`/`BUNDLED_SETUP.md`;
- **«Я менеджер проекта»:** `business.md` → `tech-pipeline.md` (конвейер, статусная модель
-  Plane, человеческие гейты) → `tech-observability.md`;
- **«Я разработчик»:** `tech-*` (1→7) → `docs/architecture/README.md` → `internals.md` →
-  `docs/_standards/` → реестр ADR → `CLAUDE.md`.
-
-**Норматив сопровождения (FR-6, формулировка по образцу NFR-5 ORCH-102/103):** в индексе —
-явная норма «**изменил функциональность платформы → обнови витрину `docs/overview/` в том же
-PR**» (+ указание, какой файл какому классу изменений соответствует). Указатели:
- `CLAUDE.md`: в правило №2 («Документация = golden source») добавляется указатель на витрину
-  и норматив; правка правила №6 — D7; строка о витрине в разделе «Структура» (`docs/`).
- `README.md`: ссылка на витрину в начале (рядом с «Архитектура») — «единая точка входа в
-  документацию системы».
- `CHANGELOG.md`: запись `docs:` по ORCH-011.
-
-Привязка: BR-6, BR-7, BR-9, FR-5, FR-6, AC-8, AC-9, AC-11.
-
-### D9 — Границы изменения; 07/08 — N/A; исход OQ-4; эскалация не требуется
-
- **Дифф задачи:** `docs/overview/` (10 файлов, D1), `tests/test_system_docs.py` (D6),
-  `scripts/build_presentation.py` (D4), правки `.openclaw/agents/reviewer.md` +
-  `tests/test_agent_prompts_canon.py` (D7), `README.md`/`CLAUDE.md`/`CHANGELOG.md` (D8),
-  `.gitignore` (+`build/`, D5), ADR-пакет work item + сквозной adr-0039 + секция в
-  `docs/architecture/README.md`. **`src/**`, `docker-compose.yml`, `Dockerfile`,
-  `requirements*` — ноль изменений** (NFR-1; машинный гард — TC-09); любое отклонение — только
-  новым ADR.
- `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — байт-в-байт; новых
-  эндпоинтов/флагов/kill-switch нет (выключать нечего: доки и dev-скрипт не исполняются
-  конвейером).
- **`07-infra-requirements.md` / `08-data-requirements.md` — N/A** (прецедент ORCH-102 D9):
-  топология не меняется (ни контейнера, ни порта, ни маунта), схема БД не меняется (ТЗ §5).
-  Dev-venv для генерации `.pptx` — не инфра-предусловие конвейера: создаётся ad-hoc человеком
-  при сборке презентации (процедура — `presentation.md`).
- **Исход OQ-4 (compiled-wiki/экспорт):** вне объёма v1 — зафиксировано; репозиторий —
-  единственный источник истины («канон не форкается», ORCH-009 BR-2). Follow-up work item не
-  заводится автоматически: потребность в wiki-экспорте — решение Владельца после приёмки
-  витрины (если витрина в репо закрывает D-2/D-3, экспорт не нужен вовсе).
- **Объём одного прогона (R-3):** допущение BRD §6 принимается; приоритет при дефиците объёма:
-  каркас+индекс → tech-pipeline/tech-agents (машинно-сверяемые) → business → остальные tech →
-  presentation+скрипт. Молчаливое сокращение запрещено — недоезд = эскалация разбиением.
- **Self-hosting (NFR-5):** прод-контейнер не рестартится; выкат — штатный конвейер
-  (deploy-staging 8501 → Confirm Deploy). Для enduro-trails изменение инертно (общих
-  артефактов нет).
- **Эскалация:** `arch:major-change` не требуется (нет новой стадии/компонента/смены БД —
-  docs-канон); ТЗ удовлетворимо без нарушения принципов — возврат в анализ не нужен.
-
-## Альтернативы
-
- **Расширить `README.md` вместо нового раздела** — отвергнуто: README — тех-витрина с
-  собственной ролью (и осью ORCH-079); бизнес-уровень + 7 блоков + маршруты раздули бы его в
-  монолит против NFR-6; D-3 предполагает выделенное «единое место».
- **`docs/system/` как имя каталога** — отвергнуто: «overview» точнее передаёт роль (обзор для
-  входа), рекомендация аналитика, прецедентов коллизии нет.
- **Монолит `tech.md` (или пара business/tech)** — отвергнуто: блоки устаревают с разным
-  темпом; точечные правки и пофайловые ассерты тестов дешевле на 7 файлах (NFR-6).
- **Marp / pandoc для PPTX** — отвергнуто (D4): Node+Chromium-тулчейн и растровые слайды
-  (Marp) / ограниченная тёмная тема через бинарный reference-doc (pandoc); python-pptx даёт
-  редактируемый текст и код-как-дизайн с одним pip-пакетом вне прод-образа.
- **Коммитить собранный `.pptx`** — отвергнуто (D5): недиффуемый, тестами не проверяемый,
-  молча устаревает (живой пример — `PRODUCT_VISION.pptx` без пути генерации); BR-5 требует
-  воспроизводимость, не бинарь.
- **Жёсткий снапшот-тест контента витрины (хэши/полные списки компонентов)** — отвергнуто:
-  превратил бы каждую docs-правку в красный CI (ложная жёсткость); тесты держат только
-  машинно-проверяемые факты, derive из кода (стадии/гейты/агенты), остальное — за reviewer.
- **Не править промпт reviewer (положиться на общее правило)** — отвергнуто (D7): по букве ось
-  ORCH-079 привязана к README; сам ORCH-079 существует потому, что общего правила для обзорных
-  доков не хватило; одна строка расширения дешевле гниющей витрины.
- **Автогенерация витрины из кода (autodoc)** — отвергнуто: явно вне объёма (BRD §2.2);
-  derive-from-code остаётся в тестах (сверка), не в генерации текста.
-
-## Последствия
-
- **+** Единая точка входа для трёх аудиторий закрывает корневую проблему фрагментации
-  (BRD §1.2); презентация собирается за одну команду из версионируемого источника.
- **+** Машинно-проверяемые факты витрины (стадии/гейты/агенты/ссылки/гигиена/чистота
-  prod-зависимостей) — CI-гарантии (TC-01…TC-10), а не обещания: дрейф ловится тестом, гниение
-  прозы — расширенной reviewer-осью (D7).
- **+** Нулевой риск рантайма: docs+tests+dev-скрипт, конвейер байт-в-байт, kill-switch не
-  нужен; для enduro-trails инертно.
- **−** Новый golden source = новая обязанность сопровождения каждого функционального PR —
-  принято осознанно (в этом смысл задачи), митигировано link-first (правится одна строка-резюме,
-  не трактат), нормативом в индексе/CLAUDE.md и осью reviewer.
- **−** Разрешённый машинно-сверяемый дубль (стадии/гейты/агенты в `tech-pipeline.md`/
-  `tech-agents.md`) — двойная запись фактов кода; защищён derive-тестами TC-03…TC-05
-  (прецедент TC-02b ORCH-102).
- **−** Правка промпта reviewer — расширение поверхности канона 52d; митигировано: только
-  добавление внутрь существующих секций, анти-регресс `test_agent_prompts_canon.py`.
- **−** `.pptx` не в репо — показ «здесь и сейчас» требует одной команды сборки; принято
-  (Владелец собирает deck при необходимости; альтернатива — гниющий бинарь — хуже).
- **Откат:** удалить `docs/overview/`, `tests/test_system_docs.py`,
-  `scripts/build_presentation.py`, вернуть точечные правки README/CLAUDE/CHANGELOG/.gitignore/
-  reviewer.md — состояние 1:1, ни миграций, ни состояния (ТЗ §7).
-
-## Ссылки
-
- BRD: `docs/work-items/ORCH-011/01-brd.md` (решения Владельца D-1…D-4, факты §1.2)
- TRZ: `docs/work-items/ORCH-011/02-trz.md` (FR-1…FR-7, OQ-1…OQ-5)
- Acceptance: `docs/work-items/ORCH-011/03-acceptance-criteria.md` (AC-1…AC-12)
- Риски: `docs/work-items/ORCH-011/10-tech-risks.md`
- Сквозной ADR: `docs/architecture/adr/adr-0039-system-overview-docs-canon.md`
- Сверено по коду/репо: `src/stages.py::STAGE_TRANSITIONS` (9 стадий + `cancelled`),
-  `src/qg/checks.py::QG_CHECKS` (14 проверок), `.openclaw/agents/*.md` (6 промптов; ось
-  ORCH-079 в `reviewer.md`), `docs/PRODUCT_VISION.md` §1–2 (+ устаревшая схема конвейера §2),
-  `docs/PRODUCT_VISION.pptx` (бинарь без пути генерации), `tests/test_lite_setup_doc.py` /
-  `test_bundled_setup_doc.py` (паттерн структурных доков-тестов),
-  `tests/test_no_host_hardcodes.py` (`FORBIDDEN`, `find_violations`),
-  `tests/test_qg_registry_snapshot.py` (импорт QG_CHECKS), `tests/test_bootstrap_script.py`
-  (импорт чистых функций из `scripts/`), `.gitignore`
- Инварианты соседних решений: adr-0019 (стандарт доков), adr-0021/ORCH-092 (канон промптов
-  52d), adr-0023 (ось обзорных доков ORCH-079), adr-0029 (порядок под-гейтов), adr-0037/0038
-  (deployment-каноны — ссылаемся, не форкаем), ORCH-041/074/081 (модель/эффорт),
-  ORCH-066 (статусная модель), `docs/_standards/PIPELINE_DOCS.md` §4 (ADR-naming),
-  `docs/_standards/TRACEABILITY.md` (маркеры)
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
claude-bot	eeb442810e	deployer(ET): auto-commit from deployer run_id=412 Some checks failed CI / test (push) Has been cancelled Details CI / test (pull_request) Successful in 26s Details	2026-06-09 00:56:58 +03:00
claude-bot	c0d34377d5	tester(ET): auto-commit from tester run_id=411 All checks were successful CI / test (push) Successful in 23s Details CI / test (pull_request) Successful in 23s Details	2026-06-09 00:53:24 +03:00
claude-bot	a63dbb987f	reviewer(ET): auto-commit from reviewer run_id=410 All checks were successful CI / test (push) Successful in 26s Details CI / test (pull_request) Successful in 26s Details	2026-06-09 00:51:48 +03:00
claude-bot	92d908a861	feat(merge-verify): guarantee idempotent open code-PR before merge_pr (ORCH-082) All checks were successful CI / test (push) Successful in 25s Details CI / test (pull_request) Successful in 25s Details Close the missing invariant "by merge-verify time the branch has an open code-PR". The pipeline created a PR only on the developer path with a fresh worktree commit (launcher._ensure_pr), so a branch (e.g. after a manual main restore) could reach the deploy->done merge-verify under-gate PR-less -> merge_pr returned "no open PR" -> a FALSE HOLD (ORCH-074 incident). - merge_gate.ensure_open_pr(repo, branch) -> (status, detail): idempotent leaf-actor (never-raise). GET open PRs filtered head==branch AND base==main (identical to merge_pr/ORCH-073 FR-3 — auto docs-PR is not a code-PR) -> existed; else POST -> created; 409/422 race -> re-GET -> existed (no dup); any other error -> failed. - stage_engine._handle_merge_verify: врезка after validated_revision and BEFORE merge_pr. created\|existed -> proceed; failed -> honest HOLD via new _hold_pr_create_failed (note "pr-create-failed-hold", text distinguishable from the not-merged HOLD; task stays on deploy, NO rollback). - launcher._ensure_pr delegated to ensure_open_pr (single PR-creation path, shared head==branch & base==main filter); the developer-only trigger is unchanged. - ORCH-073 protection untouched & authoritative: merge is confirmed ONLY by verify_merged_to_main (SHA-in-main) + check_main_regression. Real un-merged code still HOLDs. - Kill-switch ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED (default true); scope = merge_verify_applies (self-hosting / merge_verify_repos); non-self -> no-op; false -> ORCH-074 behaviour 1:1. No DB migration; main never push/force-push. - Append ORCH-082 marker to MAIN_REGRESSION_MARKERS (append-only convention). - conftest defaults the autocreate flag OFF (mirrors merge_verify_enabled) so unrelated deploy->done tests stay 1:1 (no network). Tests: tests/test_orch082_ensure_pr.py (TC-01..05), tests/test_orch082_merge_verify_autocreate.py (TC-06..12). Docs: README merge-verify block (ORCH-082), CHANGELOG, .env.example. Refs: ORCH-082 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-09 00:48:43 +03:00
claude-bot	218c9b96c8	architect(ET): auto-commit from architect run_id=408 All checks were successful CI / test (push) Successful in 25s Details	2026-06-09 00:41:31 +03:00
claude-bot	cf5790b1a6	analyst(ET): auto-commit from analyst run_id=407 All checks were successful CI / test (push) Successful in 27s Details	2026-06-09 00:29:02 +03:00
Slava	4c83ea40a3	docs: init ORCH-082 business request All checks were successful CI / test (push) Successful in 25s Details	2026-06-08 23:01:46 +03:00