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

.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/
@@ -193,18 +139,6 @@ ORCH_SERIAL_GATE_FREEZE_ENABLED=true
 #                                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
@@ -438,57 +372,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 +402,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=

.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.

.openclaw/agents/analyst.md

@@ -29,17 +29,6 @@ FastAPI + SQLite, конвейер стадий через Quality Gates, аге
 
 Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; копируй скелеты из
 `docs/_templates/` (`01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`).
-
-**Багфикс-трек (ORCH-019).** Если задача помечена меткой Plane `Bug` (укороченный маршрут —
-пропуск стадии `architecture`), выпускай **облегчённый** пакет, но **всё равно все 4 файла**
-(гейт `check_analysis_complete` требует `01/02/03/04` — не меняется): `01-brd.md` = короткий
-bug-report (симптом / шаги воспроизведения / локализация / причина), `02-trz.md` +
-`03-acceptance-criteria.md` = краткие bug-shaped заглушки, `04-test-plan.yaml` = план
-**обязательного регресс-теста** (красный до фикса, зелёный после). Экономия — в пропуске целой
-стадии `architecture` (отдельный прогон архитектора + ADR), не в числе файлов. Если баг оказался
-**сложным/архитектурным/визуальным** (нужен ADR или макет) — выпусти **полный** analysis-пакет и
-помечай в bug-report `escalate: full-cycle` (эскалация в полный цикл, ADR-001 D5 ORCH-019); оператор
-снимает багфикс-трек эндпоинтом `POST /bug-fast-track/escalate`.
 </task>
 
 <deliverables>

.openclaw/agents/reviewer.md

@@ -42,11 +42,6 @@ tools:
      (слом критического инварианта конвейера может быть 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 →

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-009
+Work item: ORCH-093
 Repo: orchestrator
-Branch: feature/ORCH-009-turnkey-plane
+Branch: feature/ORCH-093-bug-merge-gitea-405-5xx-hold-p
 Stage: development

CHANGELOG.md

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

CLAUDE.md

@@ -153,174 +153,6 @@ created → analysis → architecture → development → review → testing →
   `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`.
-
 ## Конвенции
 - Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
 - Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`
@@ -330,7 +162,7 @@ API → `manual-step` (fail-safe); **runbook** `docs/operations/ONBOARDING.md` (
 - Машинные вердикты 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`
 
 ## Артефакты задачи (`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).
+`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).
 
 **Стандарт документов (ORCH-075, ORCH-52b):** структура каждого дока, карта «стадия→агент→документ→гейт→machine-key» и конвенция ADR-naming зафиксированы в `docs/_standards/PIPELINE_DOCS.md` (golden source); копируемые скелеты — в `docs/_templates/`. Перед написанием номерного дока бери скелет из `docs/_templates/` и не меняй имя machine-key frontmatter (регистр чувствителен — иначе гейт упадёт ложно).
 

Dockerfile

@@ -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"]

README.md

@@ -45,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` |
 
 ## Структура проекта
 
@@ -141,16 +140,6 @@ uvicorn src.main:app --reload --port 8500
 | `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).
 
 ## Очередь задач (ORCH-1 / F-2b)
 
@@ -192,36 +181,6 @@ ORCH-090/06-adr/ADR-001-stop-cancel-task.md` + сквозной
 > группой `cancelled`. До создания статуса фича в fail-safe (нет UUID → ветка STOP
 > не активируется).
 
-## Багфикс-трек: дешёвый маршрут для багов (ORCH-019)
-
-Задача с меткой Plane `Bug` (имя метки — `ORCH_BUG_FAST_TRACK_LABEL`, дефолт `Bug`)
-идёт **укороченным маршрутом** конвейера: `analysis(lite) → development → review →
-testing → deploy-staging → deploy → done`, т.е. **пропускается стадия `architecture`**
-(отдельный прогон opus-агента `architect` + ADR + exit-гейт `check_architecture_done`).
-Мини-аналитик выдаёт облегчённый пакет (короткий bug-report + обязательный план
-регресс-теста), но всё равно все 4 файла analysis — гейт `check_analysis_complete`
-не меняется.
-
-**Корневой инвариант:** упрощается только аналитика/архитектура — **все Quality
-Gate'ы и под-гейты исполняются без изменений** (`STAGE_TRANSITIONS` / `QG_CHECKS` /
-`check_*` / machine-verdict ключи — байт-в-байт прежние). Маршрутизация багфикса —
-свойство планировщика (routing-override в `advance_stage` по `tasks.track='bug'`),
-**не** Quality Gate.
-
-Классификация (`src/bug_fast_track.py`, never-raise): локальный `bug_fast_track_applies(repo)`
-ПЕРВЫМ (выключенный флаг = нулевой сетевой оверхед), затем `is_bug_task` через
-`labels.has_label` (источник истины — Plane API). Тип хранится в аддитивной колонке
-`tasks.track` (`'full'` | `'bug'`), читается в горячем пути из БД (не из сети).
-**Эскалация** сложного/архитектурного бага в полный цикл — `POST /bug-fast-track/escalate?work_item=<id>`
-(сброс `'bug'→'full'`). Всё под kill-switch `ORCH_BUG_FAST_TRACK_ENABLED`, область —
-`ORCH_BUG_FAST_TRACK_REPOS` (пусто → self-hosting only), fail-safe → полный цикл.
-Наблюдаемость — блок `bug_fast_track` в `GET /queue` + отметка `🐞` в Telegram-карточке.
-Деталь — `docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md` + сквозной
-`docs/architecture/adr/adr-0032-bug-fast-track.md`.
-
-> **Инфра-предусловие:** на доске Plane проекта ORCH создать метку **`Bug`**. До её
-> создания фича в fail-safe (нет метки → задача идёт полным циклом).
-
 **Resilience-слой:** дешёвый preflight (CLI/net, кэш, без токенов) гейтит claim;
 429/overload детектится по логу (transient vs permanent), transient ретраится с
 exp-backoff (`available_at`, Retry-After); circuit breaker паузит воркер после N

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"

docs/_standards/PIPELINE_DOCS.md

@@ -2,7 +2,7 @@
 
 > **Назначение.** Единая карта «стадия → агент → документ → категория → гейт/механизм →
 > frontmatter machine-key» + конвенция ADR-naming. Это **golden source структуры** номерных
-> документов work item (`00-business-request.md` … `18-coverage-report.md`), который каждая
+> документов work item (`00-business-request.md` … `17-security-report.md`), который каждая
 > агентская роль пишет на своей стадии.
 >
 > **Статус истины (важно).** Манифест **документирует** текущее поведение гейтов, но НЕ является
@@ -60,7 +60,6 @@ check_tests_passed → check_staging_status → check_deploy_status`.
 | `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`) |
 
 ### Примечания манифеста (нормативные)
 
@@ -87,7 +86,6 @@ check_tests_passed → check_staging_status → check_deploy_status`.
 | `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`,

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.>

docs/architecture/adr/README.md

@@ -31,21 +31,11 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | 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 |
 
 > ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
 > `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
 > (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
-> свободный номер (текущий максимум — `0035`).
+> свободный номер (текущий максимум — `0020`).
 > 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).

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).

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/`, отдельная задача).

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 — образец «только читать/уведомлять, не трогать
-хост/прод»).

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>

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>

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`.

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).

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`.

docs/architecture/internals.md

@@ -106,17 +106,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:

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.*?

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`)
@@ -171,15 +144,8 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `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.example`, `.env.staging.example`. Выпуск нового комплекта секретов для нового хоста — `scripts/gen_secrets.py` (боевые секреты не копируются). **Тираж платформы на новую инфру** (карта переменных, секреты, smoke-процедура, границы Lite/Bundled) — `docs/operations/REPLICATION.md` (ORCH-101). Когерентность портов при смене прод-порта: `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) — изоляция.

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`.

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 | отдельная задача эпика |
-| **Type B — Bundled** | комплект «всё в одном» (Plane+Gitea+оркестратор) поверх 10-common | отдельная задача эпика |
-
-Этот док НЕ описывает установку 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`.*

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 '{

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

@@ -1,7 +0,0 @@
-# Business Request: Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-
-Work Item ID: ORCH-009
-
-## Description
-
-TBD

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).

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).

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 (протоколируемый) |

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

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**

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 вне рантайма, в образ ничего
-  дополнительно не запекается.

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): **низкий**.

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 не правился).

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`.

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.

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
-```

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

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

@@ -1,7 +0,0 @@
-# Business Request: Режим багфиксинга: упрощённый/дешёвый трек для багов (не полный цикл)
-
-Work Item ID: ORCH-019
-
-## Description
-
-TBD

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

@@ -1,178 +0,0 @@
----
-work_item: ORCH-019
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-019 — Режим багфиксинга (упрощённый/дешёвый трек для багов)
-
-Work Item: **ORCH-019** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Слава · Тип: фича (новый режим конвейера, опциональный, под флагом)
-
-> ⚠️ **Принцип, заданный Владельцем (нерушимый):** упрощаем **аналитику**, но **НЕ ослабляем
-> качество**. Гейты CI / review / tester verdict / deploy verdict **остаются**. Горький урок
-> ET-8 / BUG-TESTS-SUBSTRING: срезанная *проверка* = недоделка на проде. «Дешевле ≠
-> бесконтрольнее». Этот принцип — корневой инвариант всей задачи (см. NFR-1, BR-6).
-
----
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель
-Дать оркестратору **отдельный удешевлённый трек для багфиксов**. Сейчас любой баг (пример:
-зашёл на карту enduro-trails, увидел дефект, завёл задачу) идёт по **полному** конвейеру
-`analysis → architecture → development → review → testing → deploy-staging → deploy`. Для мелкой
-правки полный цикл **избыточен**: лишние стадии (полный BRD/TRZ/AC + архитектурный ADR) тратят
-токены и время, не добавляя ценности на однострочном фиксе.
-
-### 1.2. Установленные факты (проверено по коду, не изобретать)
-- **Точка входа задачи в конвейер:** `src/webhooks/plane.py::start_pipeline` создаёт task-row
-  с **жёстко зашитой** начальной стадией `"analysis"` (`create_task_atomic(..., "analysis", ...)`)
-  и режет ветку (`_create_gitea_branch`). Это единственная точка, где задаётся точка входа.
-- **Маршрутизация стадий полностью управляется** `src/stages.py::STAGE_TRANSITIONS` через
-  `get_next_stage` — `advance_stage` (`src/stage_engine.py`) не содержит «зашитого» порядка стадий,
-  он спрашивает `get_next_stage`. → Изменение точки входа / маршрута локализуемо, машину стадий
-  ломать не нужно.
-- **Метка задачи уже читается из Plane** аппаратом ORCH-089: `src/labels.py::has_label` +
-  `plane_sync.fetch_issue_labels` / `get_project_labels` (TTL-кэш, нормализация имени, never-raise,
-  fail-safe → False). Источник истины — Plane API, **не** payload вебхука (`type`/`priority` в
-  payload отсутствуют). Это готовый, проверенный шаблон классификации задачи.
-- **Все Quality Gate'ы читают вердикт из артефактов**, а не из стадии входа: `check_ci_green`,
-  `check_reviewer_verdict` (`12-review.md`), `check_tests_passed` (`13-test-report.md`),
-  `check_staging_status`, `check_deploy_status`, под-гейты security/merge/coverage/image-freshness.
-  Они **не зависят** от того, прошла ли задача `analysis`/`architecture`, → их можно сохранить
-  нетронутыми при срезанном «входе».
-- **Coverage-гейт (ORCH-027)** уже структурно ловит «код без тестов» на ребре
-  `deploy-staging → deploy` — союзник принципа «баг фиксируется тестом».
-- **Прецедент стоимости:** UI z-index баг ET-9/ET-014 прошёл **полный** цикл ~35 мин — типичный
-  кандидат на удешевление.
-
-### 1.3. Связки и разграничение
-- **ORCH-13 (роутинг моделей):** «дешёвая модель на багфиксе» (Вариант 4 постановки) —
-  **вне объёма** ORCH-019, отдельная задача; ORCH-019 лишь оставляет точку композиции
-  (флаг bug-track наблюдаем, по нему ORCH-13 позже может выбрать модель). См. §2.2.
-- **ORCH-088 (serial gate) / ORCH-089 (auto-label):** ORCH-019 **сосуществует** с ними и
-  переиспользует их аппарат (label-чтение, per-repo flag, claim-gate); не конфликтует.
-- **ORCH-12 / ORCH-14 (UX) / ET-9 (визуальные баги):** часть багов визуальные и может требовать
-  мини-макета — для таких случаев предусмотрен механизм **эскалации обратно в полный цикл**
-  (BR-5), а не слепое удешевление.
-- **ORCH-8 (петля уроков):** баг, найденный на проде, — сигнал петли уроков; ORCH-019 этого не
-  меняет (post-deploy-телеметрия ORCH-021 сохраняется).
-
----
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
-- **BR-1 — Классификация «баг».** Задача распознаётся как баг по **метке Plane** (рекоменд. имя
-  `Bug`), читаемой аппаратом ORCH-089. Операторская, детерминированная, обратимая разметка.
-- **BR-2 — Упрощённый трек.** Багфикс-задача идёт по **укороченному** пути: пропускается
-  **тяжёлая аналитика и стадия `architecture`** (полный BRD/TRZ/AC/ADR не требуются); вместо них —
-  **минимальный набор артефактов** (короткий bug-report + обязательный план регресс-теста).
-- **BR-3 — Гейты качества сохраняются ПОЛНОСТЬЮ.** CI (`check_ci_green`), review
-  (`check_reviewer_verdict`), testing (`check_tests_passed`), staging/deploy-вердикты и под-гейты
-  (security/merge/coverage/image-freshness) исполняются **без изменений** на багфикс-треке.
-- **BR-4 — Обязательный регресс-тест.** Багфикс **обязан** зафиксировать дефект тестом (тест,
-  падающий до фикса и зелёный после) — главный предохранитель от рецидива (урок ET-8).
-- **BR-5 — Эскалация в полный цикл.** Если баг оказался сложным/архитектурным или визуальным
-  (нужен макет), он **возвращается** в полный цикл; багфикс-трек не «застревает» на сложном.
-- **BR-6 — Безопасность по умолчанию (fail-safe → полный цикл).** Любая неоднозначность/ошибка
-  чтения метки/выключенный флаг → задача идёт **полным** циклом (никогда не «теряет» стадии молча).
-- **BR-7 — Наблюдаемость стоимости.** Виден факт «задача на багфикс-треке» и метрика экономии
-  (стадии/agent-runs/токены/время) относительно полного цикла.
-
-### 2.2. Вне объёма (явно не делать)
-- **Роутинг моделей (ORCH-13 / Вариант 4):** выбор дешёвой модели на багфиксе — отдельная задача.
-- **Авто-триаж сложности аналитиком (полный Вариант 3):** автоматическая classification
-  `trivial/small/complex` LLM-аналитиком — будущее развитие; v1 опирается на явную метку оператора
-  + ручную/мини-эскалацию (BR-5), не на ML-классификатор.
-- **Изменение `STAGE_TRANSITIONS` (новые стадии), реестра `QG_CHECKS`, семантики любого `check_*`,
-  вердикт-ключей** (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
-  `coverage_status:`).
-- **Параллелизм багфиксов**, изменение `max_concurrency`, merge-очередь.
-- **Полный отказ от стадии `analysis`** (вариант «hotfix → сразу development») как дефолт — см.
-  §6 (требуется минимальный аналитический проход ради регресс-теста и трассируемости). Чистый
-  hotfix без аналитики оставлен как возможная опция архитектора, но не дефолт.
-
----
-
-## 3. Заинтересованные стороны
-- **Владелец/оператор (Слава):** ставит метку `Bug`, получает быстрый дешёвый фикс, эскалирует
-  сложный баг, читает метрику экономии.
-- **Self-hosting прод (`orchestrator`) и enduro-trails:** общий инстанс/БД/очередь — режим обязан
-  быть аддитивным, под флагом, per-repo, с нулевой регрессией при выключении (FR-условие).
-- **Агенты конвейера (analyst/developer/reviewer/tester):** работают по тем же контрактам; на
-  багфикс-треке analyst выдаёт облегчённый пакет, остальные — как обычно.
-
----
-
-## 4. Бизнес-требования (BR) — сводная таблица
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | Задача распознаётся как баг по метке Plane (`Bug`), читаемой через аппарат ORCH-089 (`labels.has_label` + `plane_sync.fetch_issue_labels`). Источник истины — Plane API, не payload. | FR-1, AC-1 |
-| BR-2 | Багфикс-задача пропускает тяжёлую аналитику и стадию `architecture`; маршрут `analysis(lite) → development → review → testing → deploy-staging → deploy`. Полный BRD/TRZ/AC/ADR не обязателен. | FR-2, AC-2 |
-| BR-3 | Все Quality Gate'ы (CI/review/tester/staging/deploy + под-гейты security/merge/coverage/image-freshness) исполняются на багфикс-треке **без изменений**. | FR-3, AC-3 |
-| BR-4 | Багфикс обязан содержать **регресс-тест** (падает до фикса, зелён после); отсутствие нового/изменённого теста на исправление — повод для REQUEST_CHANGES reviewer'ом. | FR-3/FR-4, AC-4 |
-| BR-5 | Существует механизм **эскалации** багфикса в полный цикл (сложный/архитектурный/визуальный баг) — задача возвращается на полную аналитику/архитектуру. | FR-5, AC-5 |
-| BR-6 | **Fail-safe:** при выключенном флаге, ошибке/неоднозначности чтения метки, неприменимом репо — задача идёт **полным** циклом (никогда не теряет стадии молча). never-raise. | FR-6, AC-6 |
-| BR-7 | Факт багфикс-трека и метрика экономии (пропущенные стадии / Σ agent-runs / токены / время vs полный цикл) наблюдаемы (`GET /queue` блок + лог/Telegram-карточка). | FR-7, AC-7 |
-| BR-8 | Поведение управляется kill-switch'ом и областью репо (как ORCH-35/43/58/88/89): выключение флага → строго прежнее поведение (нулевая регрессия для enduro и для orchestrator). | NFR-2, AC-6 |
-
----
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **Качество не ослабляется (корневой инвариант).** Срезается только *аналитика/архитектура*; ни один Quality Gate, exit-код deploy-хука, под-гейт безопасности/покрытия — не ослаблен и не пропущен. |
-| NFR-2 | **Нулевая регрессия / аддитивность.** При `bug_fast_track_enabled=False` или неприменимом репо путь старта и маршрут идентичны текущим. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/вердикт-ключи/схема БД — не меняются (допустима лишь аддитивная идемпотентная миграция, если архитектор сочтёт нужным помечать тип задачи в БД). |
-| NFR-3 | **never-raise / fail-safe.** Любая ошибка классификации/маршрутизации → деградация на полный цикл, не падение вебхука/конвейера (по образцу `labels.py`/`serial_gate.py`). |
-| NFR-4 | **Offline-устойчивость горячего пути.** Классификация может ходить в Plane API только в момент `start_pipeline` (как ORCH-089), но **не** в горячем `claim_next_job` (иначе встанет очередь всех проектов). |
-| NFR-5 | **Per-repo область.** Режим включается по CSV-области репо; orchestrator и enduro управляются независимо. |
-| NFR-6 | **Self-hosting безопасность.** Механизм не рестартит/не роняет прод-контейнер, не пушит/force-push в `main`. |
-| NFR-7 | **Композируемость.** Корректно сосуществует с serial-gate (ORCH-088), auto-label (ORCH-089), coverage-gate (ORCH-027), merge-gate (ORCH-043). |
-
----
-
-## 6. Допущения и ограничения
-- **Минимальный аналитический проход сохраняется** (а не «hotfix → сразу dev»): ради (а)
-  фиксации регресс-теста как контракта приёмки (BR-4), (б) трассируемости (минимальный bug-report).
-  Полный отказ от `analysis` для багов оставлен архитектору как опция, но дефолт — мини-анализ.
-  Обоснование: урок ET-8 — именно отсутствие явного теста-фиксатора привело к «недоделка в Done».
-- **Классификация v1 — явная метка оператора**, не LLM-авто-триаж (Вариант 3 в полном объёме —
-  будущее). Метка `Bug` должна существовать в Plane-проекте; её отсутствие = fail-safe полный цикл.
-- **Эскалация v1** — допускает как минимум ручной путь (снять метку `Bug` / вернуть стадию) и/или
-  решение мини-аналитика «баг сложный → не фаст-трекать». Конкретный механизм — архитектору.
-- **Стоимость измеряется относительно**: метрика «во сколько раз дешевле» считается по факту из
-  существующей телеметрии `agent_runs` (стадии/токены/время), без новой тяжёлой инфраструктуры.
-
----
-
-## 7. Критерии успеха (резюме; детали — `03-acceptance-criteria.md`)
-- AC-1 — задача с меткой `Bug` распознаётся и помечается как багфикс-трек.
-- AC-2 — багфикс-задача проходит конвейер, пропустив стадию `architecture` (и тяжёлый BRD/TRZ/AC).
-- AC-3 — все Quality Gate'ы исполнены на багфикс-треке (CI/review/tester/staging/deploy + под-гейты).
-- AC-4 — багфикс содержит регресс-тест; его отсутствие даёт REQUEST_CHANGES.
-- AC-5 — сложный/визуальный баг эскалируется в полный цикл.
-- AC-6 — при выключенном флаге / ошибке / неприменимом репо — поведение строго прежнее (полный цикл).
-- AC-7 — факт багфикс-трека и метрика экономии наблюдаемы.
-
----
-
-## 8. Риски (детали — `10-tech-risks.md`, заполняет архитектор)
-- R-1: **Срезали лишнее.** Ошибочный пропуск гейта качества → недоделка на проде (ET-8). Митигатор —
-  NFR-1: режется только аналитика/архитектура, гейты структурно нетронуты + тест AC-3.
-- R-2: **Сложный баг под меткой `Bug`** уходит на фаст-трек и упирается в отсутствие архитектуры →
-  нужна эскалация (BR-5) и/или решение мини-аналитика.
-- R-3: **Регресс-тест не написан** (developer «забыл») → рецидив бага. Митигатор — BR-4 + reviewer-ось
-  + союзник coverage-gate (ORCH-027).
-- R-4: **Fail-safe инвертирован** (ошибка → молча срезали стадии) → недоделка. Митигатор — NFR-3
-  fail-safe строго в сторону полного цикла + тест AC-6.
-- R-5: **Конфликт с serial-gate/auto-label** при изменённой точке входа. Митигатор — NFR-7 +
-  интеграционный тест композиции.
-</content>
-</invoke>

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

@@ -1,207 +0,0 @@
----
-work_item: ORCH-019
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-019 — Режим багфиксинга (упрощённый/дешёвый трек для багов)
-
-Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты), выведенное из BRD
-> и фактического кода. **Как** (точная схема: где именно ветвить маршрут, хранить ли тип задачи в
-> БД, отдельный leaf-модуль или расширение `labels.py`) — решает архитектор в `06-adr/`. ТЗ
-> фиксирует требования и границы, архитектурное решение не предлагает.
-
-> ⚠️ **Корневой инвариант (NFR-1 BRD):** срезается ТОЛЬКО аналитика/архитектура. Любой Quality Gate,
-> exit-код deploy-хука, под-гейт безопасности/покрытия — байт-в-байт прежние.
-
----
-
-## 1. Сводка изменения
-Ввести **опциональный багфикс-трек**: задача, помеченная в Plane меткой `Bug`, проходит конвейер по
-**укороченному маршруту** — пропускается стадия `architecture` и тяжёлая аналитика (полный
-BRD/TRZ/AC/ADR заменяются минимальным bug-report + обязательным планом регресс-теста). Все
-Quality Gate'ы (CI/review/tester/staging/deploy + под-гейты security/merge/coverage/image-freshness)
-исполняются **без изменений**. Распознавание бага и маршрут — аддитивно, под kill-switch, с областью
-репо, never-raise, fail-safe → полный цикл. `STAGE_TRANSITIONS` и реестр `QG_CHECKS` структурно не
-меняются.
-
----
-
-## 2. Задействованные модули / пути
-
-| Путь | Роль в задаче | Характер изменения |
-|------|---------------|--------------------|
-| `src/labels.py` | аппарат чтения метки Plane (ORCH-089: `has_label`, `*_applies`) | переиспользовать; **добавить** `is_bug_task(work_item_id, project_id) -> bool` + `bug_fast_track_applies(repo) -> bool` (по образцу `auto_approve_applies`), либо вынести в новый leaf `src/bug_fast_track.py` (never-raise) — выбор архитектора |
-| `src/plane_sync.py` | `fetch_issue_labels` / `get_project_labels` / `_normalize_label` | **без изменений** — переиспользуются для чтения метки `Bug` (источник истины — Plane API) |
-| `src/webhooks/plane.py` | `start_pipeline` (создаёт task-row со стадией `"analysis"`, режет ветку `_create_gitea_branch`), `handle_status_start`, `handle_issue_updated` | **ключевая врезка:** перед `create_task_atomic(...)` определить тип задачи и (при багфикс-треке) пометить задачу багом / задать укороченный маршрут. Внешний контракт вебхука Plane не меняется |
-| `src/stages.py` | `STAGE_TRANSITIONS`, `get_next_stage` | **структура `STAGE_TRANSITIONS` не меняется** (новых стадий нет). Требование: маршрут багфикса = `analysis → development` (пропуск `architecture`). Механизм (условный `get_next_stage` по типу задачи / bug-mode-флаг на task) — архитектору |
-| `src/stage_engine.py` | `advance_stage`, `_run_qg`, `_handle_analysis_approved_flow`, откаты | `advance_stage` уже маршрутизирует через `get_next_stage` (не зашивает порядок) → при условной маршрутизации правка точечная. Гейты диспетчеризуются как раньше |
-| `src/db.py` | `create_task_atomic(plane_id, work_item_id, repo, branch, stage, title)`, схема `tasks`, `claim_next_job` | если архитектор решит хранить «тип=bug» в БД — **аддитивная идемпотентная** колонка (`_ensure_column`, напр. `tasks.track TEXT DEFAULT 'full'`); горячий `claim_next_job` **не** должен ходить в сеть (NFR-4) |
-| `src/config.py` | флаги фичи | новые: `bug_fast_track_enabled`, `bug_fast_track_label`, `bug_fast_track_repos` (CSV) + helper `applies(repo)` по образцу `auto_label_*` / `serial_gate_*` |
-| `src/qg/checks.py` | реестр `QG_CHECKS` и `check_*` | **без изменений** (инвариант NFR-1) |
-| `src/serial_gate.py`, `src/coverage_gate.py`, `src/merge_gate.py` | композиция | **без изменений**; проверить совместимость (NFR-7) интеграционным тестом |
-| `src/main.py` | `GET /queue` | **аддитивный** read-only блок `bug_fast_track` (флаг/область/счётчики/метрика экономии) |
-| `src/notifications.py` | live-карточка | опционально — отметка «🐞 багфикс-трек» в карточке (never-raise) |
-| `.openclaw/agents/analyst.md` | промпт мини-аналитика | при багфикс-треке выдавать **облегчённый** пакет (bug-report + регресс-тест-план), не полный BRD/TRZ/AC. Канон промптов 52d не нарушать |
-| `.openclaw/agents/reviewer.md` | ось контроля | добавить ось «багфикс без регресс-теста → REQUEST_CHANGES» (BR-4) — нормативно-описательно, не машинный гейт |
-
----
-
-## 3. Функциональные требования
-
-### FR-1 — Классификация задачи как «баг» (BR-1)
-- Багфикс-трек активируется, если issue несёт метку Plane с именем `bug_fast_track_label`
-  (дефолт `Bug`), прочитанную через `labels.has_label(work_item_id, label, project_id)` (ORCH-089:
-  `fetch_issue_labels` + `get_project_labels`, нормализация `_normalize_label`, TTL-кэш).
-- **Источник истины — Plane API**, не payload вебхука (поле `type` в payload отсутствует).
-- Чтение метки допускается **только** в `start_pipeline` (момент старта, сетевой вызов приемлем,
-  как ORCH-089) — **не** в горячем `claim_next_job` (NFR-4).
-- `applies(repo)` (локальный, без сети) проверяется **первым**; `has_label` (сеть) — только при
-  `applies==True` → при выключенном флаге нулевой сетевой оверхед (образец ORCH-089).
-
-### FR-2 — Укороченный маршрут (BR-2)
-- Для багфикс-задачи маршрут конвейера: `analysis(lite) → development → review → testing →
-  deploy-staging → deploy → done`, т.е. **пропускается стадия `architecture`** (и её exit-гейт
-  `check_architecture_done` / требование `06-adr/`).
-- `STAGE_TRANSITIONS` **не изменяется структурно**. Требуемый инвариант результата: при выходе
-  багфикс-задачи из `analysis` следующая стадия = `development` (а не `architecture`); для
-  не-багфикс задач — прежняя `architecture`. Конкретный механизм (условный `get_next_stage(stage,
-  task)` / bug-mode-флаг на task / точка входа сразу в `development`) — решение архитектора.
-- Тяжёлая аналитика облегчается: на багфикс-треке обязательны лишь `01-brd.md` (короткий
-  bug-report: симптом, шаги воспроизведения, локализация, причина) и `04-test-plan.yaml` (план
-  регресс-теста). Полные `02-trz.md`/`03-acceptance-criteria.md` и `06-adr/` — **не обязательны**.
-  (Совместимость с `check_analysis_complete`, требующим `01/02/03/04` — см. FR-6.)
-
-### FR-3 — Гейты качества сохраняются полностью (BR-3, корневой инвариант)
-- На багфикс-треке исполняются **без изменений**: `check_ci_green` (development→review),
-  `check_reviewer_verdict` (review→testing, `12-review.md`), `check_tests_passed` (testing→
-  deploy-staging, `13-test-report.md`), `check_staging_status`, `check_deploy_status`, под-гейты
-  ребра `deploy-staging→deploy` (security ORCH-022 → merge ORCH-043 → coverage ORCH-027 →
-  image-freshness ORCH-058) и merge-verify ребра `deploy→done` (ORCH-071/073).
-- Ни один `check_*`, его сигнатура, вердикт-ключ или порядок под-гейтов **не меняется**.
-
-### FR-4 — Обязательный регресс-тест (BR-4)
-- Багфикс **обязан** содержать новый/изменённый тест, воспроизводящий дефект (красный до фикса,
-  зелёный после). Требование закрепляется: (а) в `04-test-plan.yaml` багфикса как обязательный TC;
-  (б) reviewer-осью (`.openclaw/agents/reviewer.md`): «исправление кода без теста-фиксатора →
-  finding ≥P1 / REQUEST_CHANGES»; (в) усиливается coverage-гейтом ORCH-027 (структурно ловит «код
-  без тестов»). Это требование, не новый машинный гейт.
-
-### FR-5 — Эскалация в полный цикл (BR-5)
-- Багфикс-задача должна иметь путь возврата в полный цикл, если баг оказался сложным/архитектурным
-  или визуальным (нужен макет — связка ORCH-12/14, прецедент ET-9). Минимум v1: ручная эскалация
-  (оператор снимает метку `Bug` / переводит стадию) **и/или** решение мини-аналитика «баг сложный →
-  не фаст-трекать» (тогда задача идёт штатным маршрутом с `architecture`). Конкретный механизм и
-  его автоматизация — архитектору; v1 не обязан включать LLM-авто-триаж сложности.
-
-### FR-6 — Fail-safe → полный цикл (BR-6, NFR-3)
-- При `bug_fast_track_enabled=False`, неприменимом репо, ошибке/таймауте/неоднозначности чтения
-  метки (`has_label` → False / `None`-labels), отсутствии метки `Bug` в проекте — задача идёт
-  **полным** циклом (точка входа `analysis`, маршрут с `architecture`). never-raise: ошибка логики
-  не роняет `start_pipeline`/вебхук.
-- **Совместимость с `check_analysis_complete`** (требует наличие `01/02/03/04`): при облегчённом
-  пакете багфикса гейт не должен ложно блокировать. Варианты (архитектору): мини-аналитик всё равно
-  эмитит заглушки `02/03` ИЛИ гейт `check_analysis_approved` на багфикс-треке учитывает облегчённый
-  набор. Требование: **не ослабить** проверку для не-баг задач и **не заблокировать ложно** баг.
-
-### FR-7 — Наблюдаемость стоимости (BR-7)
-- Факт «задача на багфикс-треке» и метрика экономии видны: (а) аддитивный блок `bug_fast_track` в
-  `GET /queue` (флаг/область + счётчик задач на треке + агрегат сэкономленных стадий/agent-runs);
-  (б) лог-строка на решение о маршруте; (в) опц. отметка в Telegram-карточке. Метрика «во сколько
-  дешевле» считается из существующей телеметрии `agent_runs` (Σ токены/время багфикс-трека vs
-  средний полный цикл) — без новой тяжёлой инфраструктуры.
-
----
-
-## 4. Изменения API
-
-### 4.1. Новые публичные endpoint'ы
-- **Не требуются обязательно.** (Эскалация и классификация идут через Plane-метки/статусы, не через
-  новый HTTP-эндпоинт. Если архитектор вводит админ-эндпоинт принудительной (де)классификации —
-  описать в ADR и обновить таблицу API в README.)
-
-### 4.2. Изменяемые endpoint'ы
-- `GET /queue` — **аддитивно** добавляется блок `bug_fast_track` (read-only, never-raise) по образцу
-  блоков `serial_gate` / `auto_labels` / `coverage`: `enabled`, `repos`, `label`, перечень/счётчик
-  задач на багфикс-треке, агрегатная метрика экономии. Существующие ключи `GET /queue` не меняются.
-
-### 4.3. Webhook-обработчики
-- `start_pipeline` (`webhooks/plane.py`): добавляется ветвление «issue имеет метку `Bug` и
-  `applies(repo)` → багфикс-трек (пометить задачу / задать укороченный вход-маршрут)». Внешний
-  контракт вебхука Plane не меняется.
-
----
-
-## 5. Изменения схемы БД
-> Только **аддитивные, идемпотентные** миграции (общая прод-БД; enduro не трогать).
-
-- **Опционально (выбор архитектора):** если тип задачи нужно знать после старта (для маршрутизации
-  в `advance_stage`/`get_next_stage` и для метрики), ввести аддитивную колонку
-  `tasks.track TEXT DEFAULT 'full'` (значения `full` | `bug`) через `_ensure_column` (паттерн
-  `tasks.cancelled_at` ORCH-090). Тогда горячий `claim_next_job` читает тип из БД, **не** из сети
-  (NFR-4). Альтернатива без колонки (вывести тип повторным чтением метки) допустима, но повторный
-  сетевой вызов в горячем пути запрещён (NFR-4) → колонка предпочтительнее.
-- **Существующие** `tasks`-контракт (прочие колонки), `jobs`, `job_deps`, `agent_runs`,
-  `coverage_baseline`, `repo_freeze` — **без изменений**.
-
----
-
-## 6. Требования к новым/изменённым QG checks
-- **Новых QG-проверок не вводить; ни один `check_*` не менять семантически** (NFR-1). Маршрутизация
-  багфикса — свойство планировщика/точки входа, **не** Quality Gate.
-- Единственная допустимая тонкая правка — обеспечить, чтобы exit-гейт стадии `analysis`
-  (`check_analysis_approved` / helper `check_analysis_complete`) **не блокировал ложно** облегчённый
-  багфикс-пакет, **не ослабляя** проверку для полного цикла (FR-6). Если для этого требуется правка
-  `check_*` — она должна сохранить вердикт-семантику для не-баг задач байт-в-байт.
-
----
-
-## 7. Совместимость / регресс
-- **Kill-switch** `bug_fast_track_enabled` (env `ORCH_BUG_FAST_TRACK_ENABLED`); `False` → точка входа
-  и маршрут строго прежние (`analysis → architecture → …`), нулевая регрессия (NFR-2).
-- **Область репо** `bug_fast_track_repos` (CSV; пусто → рекомендуется self-hosting + явно
-  разрешённые проекты, где есть метка `Bug` — решение об области по умолчанию фиксирует архитектор).
-- **`applies(repo)` первым** (локально, без сети) → выключенный флаг = нулевой сетевой оверхед,
-  enduro не затронут.
-- **Композиция (NFR-7):** не конфликтует с serial-gate (ORCH-088: багфикс-задача — обычная задача
-  репо, учитывается в serial-очереди), auto-label (ORCH-089: `autoApprove`/`autoDeploy` работают и
-  на багфикс-треке), coverage-gate (ORCH-027: союзник BR-4), merge-gate (ORCH-043).
-- **never-raise / fail-safe** (NFR-3): ошибка классификации/маршрута → полный цикл, не падение.
-- **Self-hosting** (NFR-6): механизм не рестартит/не роняет прод, не пушит/force-push в `main`.
-- **Маркеры трассировки** (CLAUDE.md §9): новые инварианты помечаются `ORCH-019`; правка
-  маркированного кода (ORCH-088/089/027) — со сверкой их `06-adr/`.
-
----
-
-## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
-- `docs/work-items/ORCH-019/06-adr/ADR-001-<slug>.md` — решение (механизм маршрута, хранение типа,
-  совместимость с `check_analysis_complete`, область по умолчанию, механизм эскалации).
-- `docs/architecture/README.md` — новый раздел «Багфикс-трек (ORCH-019)» + блок `bug_fast_track` в
-  описании `GET /queue`; при новой колонке — раздел «База данных».
-- `CLAUDE.md` — краткий абзац о багфикс-режиме (правила для агентов / конвейер).
-- `CHANGELOG.md` — запись `feat:`.
-- `.openclaw/agents/analyst.md` / `reviewer.md` — облегчённый пакет багфикса + reviewer-ось
-  регресс-теста (канон 52d не нарушать).
-- При новой колонке — `docs/work-items/ORCH-019/08-data-requirements.md` (заполняет архитектор).
-
----
-
-## 9. Открытые вопросы для архитектора (не блокируют анализ)
-- OQ-1: Механизм пропуска `architecture` — условный `get_next_stage(stage, task)`, bug-mode-флаг на
-  task, или прямой вход багфикса сразу в `development` с сохранённым мини-bug-report? (Влияет на
-  §3 `stages.py`/`stage_engine.py` и на `check_analysis_complete`.)
-- OQ-2: Хранить ли тип задачи в БД (`tasks.track`) vs выводить из метки. Рекоменд. — колонка
-  (NFR-4 запрещает сеть в горячем claim).
-- OQ-3: Сохранять ли мини-стадию `analysis(lite)` (рекоменд., ради регресс-теста и трассируемости)
-  или допустить чистый hotfix `→ development` (вне дефолта). См. BRD §6.
-- OQ-4: Механизм эскалации (BR-5) — только ручной (снять метку/сменить стадию) или авто-сигнал
-  мини-аналитика «баг сложный → полный цикл».
-- OQ-5: Область по умолчанию (пустой CSV) — self-hosting only vs все репо с меткой `Bug`.
-- OQ-6: Совместимость с `check_analysis_approved`/`check_analysis_complete` на облегчённом пакете
-  (FR-6) — заглушки `02/03` vs условный учёт гейтом.
-</content>

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

@@ -1,139 +0,0 @@
----
-work_item: ORCH-019
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-019 — Режим багфиксинга
-
-Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
-считается провалом). Reviewer/tester проверяют их буквально по файлам репозитория и тестам.
-
-> ⚠️ Корневой инвариант (см. AC-3/AC-8): срезается только аналитика/архитектура; ни один Quality
-> Gate не ослаблен. Это главное условие приёмки — нарушение = безусловный FAIL всей задачи.
-
----
-
-## AC-1 — Классификация задачи по метке `Bug`
-
-**Условие:** issue с меткой Plane `bug_fast_track_label` (дефолт `Bug`) при включённом флаге и
-применимом репо распознаётся как багфикс-задача.
-- **PASS:** при `bug_fast_track_enabled=True` и `applies(repo)==True` для issue с меткой `Bug`
-  `is_bug_task(...)` возвращает `True` (через `labels.has_label` → `plane_sync.fetch_issue_labels`);
-  задача стартует на багфикс-треке. Источник метки — Plane API, не payload вебхука.
-- **FAIL:** метка `Bug` игнорируется; ИЛИ тип читается из payload вебхука; ИЛИ задача без метки
-  `Bug` ошибочно попадает на багфикс-трек.
-
----
-
-## AC-2 — Укороченный маршрут: пропуск стадии `architecture`
-
-**Условие:** багфикс-задача проходит конвейер, минуя стадию `architecture`.
-- **PASS:** для багфикс-задачи переход из `analysis` ведёт в `development` (а не `architecture`);
-  стадия `architecture` и её требование `06-adr/` для багфикса не исполняются; задача доходит до
-  `done`. Маршрут не-баг задачи остаётся `analysis → architecture → development → …`.
-- **FAIL:** багфикс-задача всё равно проходит `architecture`; ИЛИ не-баг задача начинает пропускать
-  `architecture`; ИЛИ `STAGE_TRANSITIONS` изменён структурно (новые/удалённые стадии).
-
----
-
-## AC-3 — Все Quality Gate'ы исполнены на багфикс-треке (корневой инвариант)
-
-**Условие:** на багфикс-треке исполняются все гейты качества без изменений.
-- **PASS:** для багфикс-задачи отрабатывают `check_ci_green`, `check_reviewer_verdict`
-  (`12-review.md`), `check_tests_passed` (`13-test-report.md`), `check_staging_status`,
-  `check_deploy_status` и под-гейты ребра `deploy-staging→deploy` (security → merge → coverage →
-  image-freshness) и merge-verify ребра `deploy→done`. Реестр `QG_CHECKS`, сигнатуры `check_*`,
-  вердикт-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
-  `coverage_status:`) и порядок под-гейтов — байт-в-байт прежние.
-- **FAIL:** хоть один гейт качества пропущен/ослаблен/изменён на багфикс-треке; ИЛИ изменён состав
-  `QG_CHECKS` / имя или регистр любого вердикт-ключа / порядок под-гейтов.
-
----
-
-## AC-4 — Обязательный регресс-тест
-
-**Условие:** багфикс фиксирует дефект тестом.
-- **PASS:** PR багфикса содержит новый/изменённый тест, воспроизводящий исправляемый дефект
-  (красный на коде до фикса, зелёный после); требование закреплено в `04-test-plan.yaml` багфикса
-  и в reviewer-оси (`.openclaw/agents/reviewer.md`: фикс без теста → finding ≥P1 / REQUEST_CHANGES).
-- **FAIL:** багфикс мержится без теста-фиксатора; ИЛИ reviewer-ось отсутствует/не срабатывает; ИЛИ
-  тест присутствует, но не падает на исходном (нефиксированном) коде.
-
----
-
-## AC-5 — Эскалация сложного бага в полный цикл
-
-**Условие:** сложный/архитектурный/визуальный баг возвращается в полный цикл.
-- **PASS:** существует и документирован путь эскалации (минимум ручной: снятие метки `Bug` /
-  перевод стадии, и/или решение мини-аналитика «баг сложный → не фаст-трекать»); после эскалации
-  задача проходит штатный маршрут с `architecture`.
-- **FAIL:** механизма эскалации нет; ИЛИ багфикс-задача необратимо застревает без `architecture`,
-  когда баг требует архитектурного решения/макета.
-
----
-
-## AC-6 — Fail-safe → полный цикл (нулевая регрессия)
-
-**Условие:** при выключении/ошибке/неприменимости — строго прежнее поведение (полный цикл).
-- **PASS:** при `bug_fast_track_enabled=False`, неприменимом репо, ошибке/таймауте/неоднозначности
-  чтения метки, отсутствии метки `Bug` — задача стартует на `analysis` и идёт маршрутом с
-  `architecture` (как до ORCH-019). Логика never-raise: ошибка не роняет `start_pipeline`/вебхук.
-  При выключенном флаге путь старта и маршрут идентичны текущим (диффом по поведению — нулевые).
-- **FAIL:** ошибка/неоднозначность приводит к молчаливому пропуску стадий; ИЛИ исключение из
-  логики классификации роняет вебхук/конвейер; ИЛИ при выключенном флаге поведение отличается от
-  прежнего.
-
----
-
-## AC-7 — Наблюдаемость трека и метрика стоимости
-
-**Условие:** факт багфикс-трека и экономия наблюдаемы.
-- **PASS:** `GET /queue` содержит аддитивный read-only блок `bug_fast_track` (флаг/область/метка +
-  счётчик задач на треке + агрегатная метрика экономии стадий/agent-runs/токенов/времени);
-  решение о маршруте логируется; существующие ключи `GET /queue` не изменены.
-- **FAIL:** трек/метрика ненаблюдаемы; ИЛИ блок ломает существующий контракт `GET /queue`; ИЛИ
-  ошибка построения блока роняет эндпоинт (нарушен never-raise).
-
----
-
-## AC-8 — Аддитивность и self-hosting безопасность
-
-**Условие:** изменение аддитивно и безопасно для общего прод-инстанса.
-- **PASS:** миграции БД (если есть) аддитивны и идемпотентны (`_ensure_column`/`CREATE TABLE IF NOT
-  EXISTS`); enduro при выключенном/неприменимом флаге не затронут; механизм не рестартит/не роняет
-  прод-контейнер, не пушит/force-push в `main`. Полный регресс `tests/` зелёный.
-- **FAIL:** ломающая миграция/изменение существующих контрактов; ИЛИ затронут enduro при выключенном
-  флаге; ИЛИ механизм трогает прод-контейнер/`main`; ИЛИ красный `tests/`.
-
----
-
-## AC-9 — Композиция с существующими гейтами
-
-**Условие:** багфикс-трек корректно сосуществует с ORCH-088/089/027/043.
-- **PASS:** багфикс-задача корректно учитывается serial-gate (ORCH-088) как обычная задача репо;
-  `autoApprove`/`autoDeploy` (ORCH-089) работают на багфикс-треке; coverage-gate (ORCH-027) и
-  merge-gate (ORCH-043) исполняются штатно. Интеграционный тест композиции зелёный.
-- **FAIL:** изменённая точка входа ломает serial-очередь/auto-label/merge/coverage; ИЛИ багфикс-
-  задача обходит serial-gate.
-
----
-
-## Сводная матрица AC ↔ BR/FR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-2 |
-| AC-3 | BR-3 / FR-3 / NFR-1 |
-| AC-4 | BR-4 / FR-4 |
-| AC-5 | BR-5 / FR-5 |
-| AC-6 | BR-6 / FR-6 / NFR-2 / NFR-3 |
-| AC-7 | BR-7 / FR-7 |
-| AC-8 | BR-8 / NFR-2 / NFR-6 |
-| AC-9 | NFR-7 |
-</content>

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

@@ -1,111 +0,0 @@
-work_item: ORCH-019
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Багфикс-трек: классификация по метке, укороченный маршрут, сохранность гейтов, fail-safe"
-framework: pytest
-scope: >
-  Покрывает: классификацию задачи как бага по метке Plane (ORCH-089-аппарат), маршрутизацию
-  багфикса в обход стадии architecture, сохранность ВСЕХ Quality Gate'ов, обязательность
-  регресс-теста, эскалацию в полный цикл, fail-safe → полный цикл, наблюдаемость/метрику,
-  аддитивность и композицию с serial-gate/auto-label/coverage. Вне покрытия: реальный
-  Plane/Gitea I/O (мокается), роутинг моделей ORCH-13, LLM-авто-триаж сложности.
-notes: >
-  Сетевые вызовы Plane (fetch_issue_labels/get_project_labels) мокаются. Полный регресс tests/
-  должен оставаться зелёным. Тесты на сохранность гейтов проверяют НЕИЗМЕННОСТЬ QG_CHECKS/check_*/
-  вердикт-ключей — это анти-регресс корневого инварианта (NFR-1). Финальные имена модулей/функций
-  (labels.py vs новый bug_fast_track.py; tasks.track колонка) фиксирует архитектор — TC привязаны
-  к поведению, имена путей уточняются на стадии разработки.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "is_bug_task() возвращает True для issue с меткой 'Bug' (has_label True); метка читается из Plane API, не из payload."
-    module: tests/test_bug_fast_track.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "is_bug_task() возвращает False при отсутствии метки, неоднозначной метке или labels=None (fail-safe)."
-    module: tests/test_bug_fast_track.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "bug_fast_track_applies(repo): первым проверяется локальная область (enabled + CSV repos) до любого сетевого вызова; выключенный флаг → False без обращения к has_label."
-    module: tests/test_bug_fast_track.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "never-raise: исключение в fetch_issue_labels/get_project_labels не пробрасывается — is_bug_task деградирует в False (полный цикл)."
-    module: tests/test_bug_fast_track.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Маршрут багфикса: для bug-задачи следующая стадия после analysis = development (architecture пропущена); для не-баг задачи = architecture."
-    module: tests/test_bug_fast_track_routing.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "STAGE_TRANSITIONS структурно не изменён: набор стадий и рёбер байт-в-байт прежний (анти-регресс)."
-    module: tests/test_bug_fast_track_routing.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Реестр QG_CHECKS и сигнатуры check_* не изменены багфикс-треком; вердикт-ключи (verdict/result/deploy_status/staging_status/security_status/coverage_status) сохранены по имени и регистру."
-    module: tests/test_bug_fast_track_gates.py
-    expected: PASS
-
-  - id: TC-08
-    type: integration
-    description: "E2E багфикс-трек: bug-задача проходит development→review→testing→deploy-staging→deploy с исполнением всех гейтов (check_ci_green/reviewer_verdict/tests_passed/staging/deploy + под-гейты security/merge/coverage/image-freshness), минуя architecture."
-    module: tests/test_bug_fast_track_e2e.py
-    expected: PASS
-
-  - id: TC-09
-    type: integration
-    description: "start_pipeline: issue с меткой Bug (флаг вкл, репо применим) создаёт задачу на багфикс-треке; issue без метки — на полном цикле (точка входа analysis + маршрут с architecture)."
-    module: tests/test_bug_fast_track_e2e.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "Fail-safe: при bug_fast_track_enabled=False путь старта и маршрут идентичны прежним (нулевая регрессия) — задача с меткой Bug идёт полным циклом."
-    module: tests/test_bug_fast_track_e2e.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "Эскалация: после снятия метки Bug / решения 'баг сложный' задача проходит штатный маршрут с architecture (возврат в полный цикл)."
-    module: tests/test_bug_fast_track_escalation.py
-    expected: PASS
-
-  - id: TC-12
-    type: unit
-    description: "check_analysis_approved/check_analysis_complete не блокирует ложно облегчённый багфикс-пакет, но сохраняет прежнюю проверку для не-баг задач (требование FR-6)."
-    module: tests/test_bug_fast_track_gates.py
-    expected: PASS
-
-  - id: TC-13
-    type: integration
-    description: "GET /queue содержит аддитивный read-only блок bug_fast_track (enabled/repos/label/счётчик/метрика); существующие ключи неизменны; ошибка построения блока не роняет эндпоинт."
-    module: tests/test_queue_endpoint.py
-    expected: PASS
-
-  - id: TC-14
-    type: integration
-    description: "Композиция: багфикс-задача учитывается serial-gate (ORCH-088) как обычная задача репо и не обходит его; autoApprove/autoDeploy (ORCH-089) применимы на багфикс-треке."
-    module: tests/test_bug_fast_track_composition.py
-    expected: PASS
-
-  - id: TC-15
-    type: unit
-    description: "Миграция (если введена колонка tasks.track) аддитивна и идемпотентна: повторный init_db/_ensure_column не падает; дефолт 'full' для существующих строк."
-    module: tests/test_db_migrations.py
-    expected: PASS

docs/work-items/ORCH-019/06-adr/ADR-001-bug-fast-track.md

@@ -1,231 +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-001: Багфикс-трек — пропуск стадии `architecture` через track-aware routing override
-
-Work Item: **ORCH-019** — упрощённый/дешёвый трек для багов (укороченный маршрут конвейера)
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0032-bug-fast-track.md`** (решение
-кросс-каттинговое: новый leaf-компонент + аддитивная колонка `tasks.track` + семантика
-маршрутизации, затрагивающая `advance_stage`).
-
-## Статус
-Proposed
-
-## Контекст
-
-Любая задача входит в конвейер через `webhooks/plane.py::start_pipeline`, который
-**жёстко** создаёт task-row со стадией `"analysis"` (`create_task_atomic(..., "analysis", ...)`)
-и режет ветку. Маршрут стадий полностью управляется `src/stages.py::STAGE_TRANSITIONS` через
-`get_next_stage` — `advance_stage` (`src/stage_engine.py`) НЕ зашивает порядок, а спрашивает
-`get_next_stage(current_stage)` (строка 214) и `get_agent_for_stage(current_stage)` (строка 464).
-
-Для мелкого бага полный цикл `analysis → architecture → development → …` избыточен: стадия
-`architecture` = отдельный прогон агента `architect` (opus, дорогой) + ADR + exit-гейт
-`check_architecture_done`. Прецедент: UI z-index баг ET-9/ET-014 прошёл полный цикл ~35 мин.
-
-**Корневой инвариант (NFR-1 BRD, нерушимый):** упрощаем только *аналитику/архитектуру*; ни один
-Quality Gate / exit-код deploy-хука / под-гейт (security/merge/coverage/image-freshness) — НЕ
-ослаблен. Горький урок ET-8: срезанная *проверка* = недоделка на проде.
-
-**Факты, сверенные с кодом:**
-- `src/labels.py::has_label` + `plane_sync.fetch_issue_labels`/`get_project_labels` (ORCH-089) —
-  готовый, проверенный аппарат чтения метки Plane (TTL-кэш, нормализация, never-raise,
-  fail-safe → False, источник истины Plane API, не payload).
-- `advance_stage` маршрутизирует через `get_next_stage`/`get_agent_for_stage` → точка ветвления
-  локализуема, `STAGE_TRANSITIONS` ломать не нужно.
-- `check_analysis_approved` (exit-гейт `analysis`) вызывает `check_analysis_complete`, требующий
-  **01/02/03/04** (`src/qg/checks.py:33`). Это и есть точка риска ложной блокировки облегчённого
-  пакета (FR-6).
-- `_ensure_column` (`src/db.py:334`) — идемпотентная аддитивная миграция (паттерн
-  `tasks.cancelled_at`, ORCH-090).
-
-## Решение
-
-### Сводка
-
-Багфикс-трек — **свойство планировщика/точки входа, не Quality Gate**. Задача с меткой Plane
-`Bug` помечается в БД как `track='bug'`; на ребре выхода из `analysis` `advance_stage` применяет
-**чистый routing-override**: `next_stage` → `development` (вместо `architecture`), `next_agent`
-→ `developer` (вместо `architect`). `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, все `check_*` и
-вердикт-ключи — **байт-в-байт прежние**. Распознавание, маршрут и метрика — аддитивно, под
-kill-switch, с областью репо, never-raise, fail-safe → полный цикл.
-
-### D1 — Классификация: метка Plane `Bug`, читаемая в `start_pipeline` (FR-1, AC-1)
-
-Новый leaf `src/bug_fast_track.py` (пустой импорт-граф как `serial_gate`/`labels`: только
-`config`, лениво `labels`/`plane_sync`/`qg.checks`), never-raise. Публичные функции:
-- `bug_fast_track_applies(repo) -> bool` — локальный, без сети, по образцу `_auto_label_applies`:
-  `bug_fast_track_enabled=False` → `False`; `bug_fast_track_repos` (CSV) непустой → только
-  перечисленные репо; **пусто → self-hosting only** (`is_self_hosting_repo`, см. D6). Проверяется
-  **ПЕРВЫМ** → при выключенном флаге нулевой сетевой оверхед, enduro не затронут.
-- `is_bug_task(work_item_id, project_id) -> bool` — `bug_fast_track_applies` уже проверен
-  вызывающим; делегирует в `labels.has_label(work_item_id, settings.bug_fast_track_label,
-  project_id)` (дефолт метки `Bug`). Любая ошибка/неоднозначность → `False` (fail-safe → полный
-  цикл).
-
-Чтение метки — **только** в `start_pipeline` (момент старта, сетевой вызов приемлем, как
-ORCH-089), **никогда** в горячем `claim_next_job` (NFR-4).
-
-### D2 — Хранение типа: аддитивная колонка `tasks.track` (OQ-2, NFR-4)
-
-Идемпотентная миграция `_ensure_column(conn, "tasks", "track", "TEXT DEFAULT 'full'")` рядом с
-`tasks.cancelled_at`/`cancel_requested_at` (`src/db.py` init). Значения: `'full'` (дефолт, ВСЕ
-существующие и не-баг задачи) | `'bug'`. Хелперы: `db.set_task_track(task_id, track)` (запись),
-`db.get_task_track(task_id) -> str` (чтение, дефолт `'full'`). Тип читается из **БД** в
-`advance_stage` (NFR-4: горячий путь без сети). Альтернатива «выводить тип повторным чтением
-метки» отвергнута — повторный сетевой вызов в горячем пути запрещён.
-
-`create_task_atomic` НЕ меняет сигнатуру: задача создаётся как `'full'` (DEFAULT), затем
-`start_pipeline` после успешного `created=True` при `is_bug_task` вызывает
-`db.set_task_track(task_id, 'bug')`. Точка входа стадии остаётся `"analysis"` (мини-анализ
-сохраняется, OQ-3/BRD §6 — НЕ чистый hotfix).
-
-### D3 — Routing-override: пропуск `architecture` без правки `STAGE_TRANSITIONS` (FR-2, AC-2)
-
-`get_next_stage`/`get_agent_for_stage` остаются **чистыми** (принимают только стадию, 1:1).
-Override живёт в `advance_stage`, сразу после строки `next_stage = get_next_stage(current_stage)`:
-
-```python
-next_stage = get_next_stage(current_stage)
-# ORCH-019: bug-fast-track skips the architecture stage entirely.
-if current_stage == "analysis" and bug_fast_track.skips_architecture(track):
-    next_stage = "development"
-```
-
-и при запуске следующего агента (строка 464):
-
-```python
-next_agent = get_agent_for_stage(current_stage)        # "analysis" -> "architect"
-if current_stage == "analysis" and next_stage == "development":
-    next_agent = "developer"                            # skip architect run
-```
-
-`track` читается один раз в начале `advance_stage` (`db.get_task_track(task_id)`). Чистый
-предикат `bug_fast_track.skips_architecture(track) -> bool` (== `track == 'bug'` под
-`bug_fast_track_enabled`; иначе `False`). Багфикс-задача физически НЕ попадает в стадию
-`architecture` → её exit-гейт `check_architecture_done` и требование `06-adr/` не исполняются для
-багфикса. Для не-баг задач (`track='full'`) поведение **байт-в-байт** прежнее.
-
-**Сопутствующая правка телеметрии:** строка 386 стампит `mark_brd_review_ended` при
-`analysis → architecture`. Для багфикса next_stage = `development`, поэтому условие расширяется до
-`current_stage == "analysis" and next_stage in ("architecture", "development")` — чтобы метрика
-«твоё время» (ORCH-087) оставалась честной на багфикс-треке. Не влияет на гейты.
-
-### D4 — Quality Gate `analysis`: НЕ трогаем; lite-пакет эмитит все 4 файла (FR-3/FR-6, OQ-6, AC-3)
-
-**Корневой инвариант диктует минимальную поверхность изменения гейтов = ноль.**
-`check_analysis_complete` (требует 01/02/03/04) и `check_analysis_approved` остаются **байт-в-байт
-прежними**. Багфикс-аналитик (`analyst.md` lite-режим) всё равно эмитит **все 4** файла, но в
-облегчённой багфикс-форме: `01-brd.md` = короткий bug-report (симптом / шаги воспроизведения /
-локализация / причина), `02-trz.md` + `03-acceptance-criteria.md` = краткие bug-shaped заглушки,
-`04-test-plan.yaml` = план **обязательного регресс-теста** (красный до фикса, зелёный после).
-
-Обоснование выбора: доминирующая экономия — пропуск **всей стадии `architecture`** (отдельный
-прогон opus-агента `architect` + ADR), а не число файлов analysis (они эмитятся в ОДНОМ прогоне
-analyst-агента). Сохранение 4-файлового гейта = **сильнейшая** позиция NFR-1 (нулевая поверхность
-правок гейта) ценой почти нулевого оверхеда. Альтернатива «track-aware `check_analysis_complete`
-(для bug требовать только 01/04)» рассмотрена и отвергнута для v1 (D-Alt) — она трогает `check_*`
-и расширяет поверхность риска без существенной экономии.
-
-### D5 — Эскалация в полный цикл (FR-5, AC-5)
-
-Два пути возврата сложного/архитектурного/визуального бага в полный цикл, оба сбрасывают
-`track='bug'` → `'full'` (после чего `advance_stage` маршрутизирует `analysis → architecture`
-штатно):
-1. **Операторский (ручной, v1-дефолт):** админ-эндпоинт `POST /bug-fast-track/escalate?work_item=<id>`
-   (по образцу `POST /serial-gate/unfreeze`, `POST /coverage/baseline`) — `db.set_task_track(...,
-   'full')`, лог + Telegram + Plane-коммент, never-raise. Применять, пока задача в `analysis`
-   (до выхода) — тогда следующий переход уйдёт в `architecture`.
-2. **Решение мини-аналитика:** если на багфикс-треке аналитик определяет, что баг архитектурный,
-   он эмитит **полный** analysis-пакет (включая запрос на `06-adr/`) и помечает в bug-report
-   `escalate: full-cycle` — оператор подтверждает эскалацию эндпоинтом (1). v1 НЕ включает
-   автоматический LLM-авто-триаж сложности (вне объёма, BRD §2.2).
-
-Эскалация обратима, детерминирована, наблюдаема. Багфикс-задача не «застревает» без архитектуры.
-
-### D6 — Область по умолчанию: self-hosting only (OQ-5, NFR-5)
-
-Пустой `bug_fast_track_repos` → **self-hosting only** (`is_self_hosting_repo`, как
-ORCH-089/027/058). Это безопасный дефолт: режим обкатывается на самом орке (где метка `Bug`
-гарантированно заводится оператором), enduro подключается явным добавлением в CSV. Флаги
-(`config.py`): `bug_fast_track_enabled` (kill-switch, env `ORCH_BUG_FAST_TRACK_ENABLED`),
-`bug_fast_track_label` (дефолт `Bug`, env `ORCH_BUG_FAST_TRACK_LABEL`), `bug_fast_track_repos`
-(CSV, env `ORCH_BUG_FAST_TRACK_REPOS`).
-
-### D7 — Наблюдаемость стоимости (FR-7, AC-7)
-
-- **`GET /queue`** — аддитивный read-only блок `bug_fast_track` (`bug_fast_track.snapshot()`,
-  never-raise, по образцу `serial_gate`/`auto_labels`/`coverage`): `enabled`, `repos`, `label`,
-  счётчик задач с `track='bug'`, агрегатная метрика экономии (пропущенные стадии / Σ agent-runs /
-  токены / время багфикс-трека против среднего полного цикла из существующей телеметрии
-  `agent_runs`). Существующие ключи `GET /queue` не меняются.
-- **Лог-строка** на решение о маршруте (`analysis → development (bug-fast-track)`).
-- **Опц.** отметка `🐞 багфикс-трек` в Telegram-карточке (`notifications.py`, never-raise).
-
-### D8 — Композиция (NFR-7, AC-9)
-
-- **serial-gate (ORCH-088):** багфикс-задача — обычная задача репо, учитывается в serial-очереди
-  как есть (FIFO `t2.id < jobs.task_id`); точка входа `analysis` не меняется, defer-branch логика
-  не затронута. Маркированный код `serial_gate.py` НЕ правится.
-- **auto-label (ORCH-089):** `autoApprove`/`autoDeploy` работают на багфикс-треке — autoApprove
-  врезка в `_handle_analysis_approved_flow` вызывает `advance_stage(finished_agent=None)`, который
-  применяет D3-override и уходит в `development`. Переиспользуем `labels.has_label`.
-- **coverage-gate (ORCH-027):** союзник BR-4 (структурно ловит «код без теста») — исполняется
-  штатно на ребре `deploy-staging → deploy`.
-- **merge-gate (ORCH-043):** не затронут.
-
-Правки маркированного кода (`advance_stage` несёт врезки ORCH-088/089/027/059/094) — точечные,
-со сверкой их `06-adr/`; зафиксированные инварианты (порядок под-гейтов, merge-lease,
-terminal-sync) НЕ нарушаются: ORCH-019 добавляет ветвление ТОЛЬКО на ребре выхода из `analysis`,
-до всех deploy-edge под-гейтов.
-
-## Альтернативы
-
-- **Track-aware `get_next_stage(stage, task)` / новая стадия в `STAGE_TRANSITIONS`** — отвергнуто:
-  ломает чистоту `stages.py` и риск задеть структуру таблицы (AC-2 FAIL при структурном изменении).
-  Override в `advance_stage` локальнее и держит `STAGE_TRANSITIONS` неизменным.
-- **Track-aware `check_analysis_complete` (bug → только 01/04)** — отвергнуто для v1 (D-Alt):
-  трогает `check_*`, расширяет поверхность риска NFR-1 ради почти нулевой экономии (см. D4).
-  Оставлено как возможное будущее уточнение, если потребуется реальный отказ от 02/03.
-- **Чистый hotfix `start_pipeline → development`, минуя `analysis`** — отвергнуто как дефолт
-  (BRD §6): теряется фиксация регресс-теста как контракта приёмки и трассируемость (урок ET-8).
-- **Тип задачи из payload вебхука / повторное чтение метки в `claim_next_job`** — отвергнуто:
-  payload не несёт `type` (источник истины — Plane API); сеть в горячем claim запрещена (NFR-4).
-- **Чтение типа без БД-колонки** — отвергнуто: потребовало бы сетевого вызова в горячем пути.
-
-## Последствия
-
-- **+** Багфикс минует целую стадию `architecture` (один прогон opus-агента `architect` + ADR) —
-  основная экономия токенов/времени; гейты качества **байт-в-байт** сохранены.
-- **+** Полностью аддитивно: kill-switch `False` или неприменимый репо → путь старта и маршрут
-  идентичны текущим (AC-6, нулевая регрессия для enduro и orchestrator).
-- **+** Переиспользует проверенный аппарат ORCH-089 (label-чтение) и паттерн leaf+флаги+snapshot.
-- **−** Багфикс-аналитик всё равно эмитит 02/03 (краткие заглушки) ради неизменности гейта —
-  принятый компромисс (D4); экономия на их содержании, не на их наличии.
-- **−** Эскалация v1 требует операторского действия (эндпоинт) — авто-триаж сложности отложен
-  (BRD §2.2). Митигатор: путь эскалации документирован, обратим, наблюдаем (D5).
-- **Откат:** `bug_fast_track_enabled=False` (мгновенно, 1:1 прежнее поведение); колонка
-  `tasks.track` остаётся (аддитивна, дефолт `'full'`, безвредна). Полный откат — revert PR;
-  миграция идемпотентна, остаточная колонка не мешает.
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-019/01-brd.md`
-- TRZ: `docs/work-items/ORCH-019/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-019/03-acceptance-criteria.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0032-bug-fast-track.md`
-- Data: `docs/work-items/ORCH-019/08-data-requirements.md`
-- Infra: `docs/work-items/ORCH-019/07-infra-requirements.md`
-- Риски: `docs/work-items/ORCH-019/10-tech-risks.md`
-- Сверено по коду: `src/stages.py`, `src/stage_engine.py` (advance_stage:175-477),
-  `src/webhooks/plane.py::start_pipeline` (505-684), `src/labels.py`,
-  `src/qg/checks.py` (check_analysis_complete:33, check_analysis_approved:286,
-  check_architecture_done:62), `src/db.py` (_ensure_column:334, create_task_atomic:433)
-</content>
-</invoke>

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

@@ -1,62 +0,0 @@
----
-work_item: ORCH-019
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфраструктурные требования (Infra Requirements): ORCH-019 — Багфикс-трек
-
-Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
-
-> **Топология не меняется.** Один прод-контейнер `orchestrator` (8500) + staging (8501) на mva154,
-> общая SQLite-БД. ORCH-019 — чисто прикладное изменение под флагом. Этот документ фиксирует
-> **предусловия включения** (Plane-метка + env-флаги), не новую инфраструктуру.
-
----
-
-## 1. Предусловие: метка `Bug` в Plane-проекте (блокирующее для активации)
-
-Багфикс-трек активируется по метке Plane с именем `bug_fast_track_label` (дефолт `Bug`),
-читаемой аппаратом ORCH-089 (`fetch_issue_labels`/`get_project_labels`). **Метка должна
-существовать** в Plane-проекте orchestrator (и в любом проекте, добавленном в
-`bug_fast_track_repos`).
-
-- Её **отсутствие = fail-safe полный цикл** (`has_label → False`), не сбой. Включение флага без
-  заведённой метки безопасно, но эффекта не даёт.
-- Создаётся оператором в Plane вручную (как `autoApprove`/`autoDeploy` для ORCH-089).
-
-## 2. Конфигурация (env-флаги, `src/config.py`)
-
-| Флаг | Env | Дефолт | Назначение |
-|------|-----|--------|-----------|
-| `bug_fast_track_enabled` | `ORCH_BUG_FAST_TRACK_ENABLED` | `False` | kill-switch; `False` → путь старта/маршрут строго прежние (нулевая регрессия) |
-| `bug_fast_track_label` | `ORCH_BUG_FAST_TRACK_LABEL` | `Bug` | имя метки Plane для распознавания бага |
-| `bug_fast_track_repos` | `ORCH_BUG_FAST_TRACK_REPOS` | `""` (пусто) | CSV-область; пусто → **self-hosting only** (`orchestrator`) |
-
-> Рекомендация выката: `enabled=False` до момента, когда метка `Bug` заведена в Plane и проведён
-> staging-прогон. Дефолт области (пустой CSV) = self-hosting only → enduro не затронут даже при
-> включённом флаге.
-
-## 3. Зависимости / образ
-
-- **Новых pip-зависимостей нет.** Переиспользуются существующие `httpx`/`plane_sync` (label-чтение)
-  и `sqlite3` (колонка `tasks.track`). Пересборка образа из-за зависимостей не требуется.
-- **Миграция БД** (`tasks.track`) применяется идемпотентно при старте приложения (`_ensure_column`)
-  — без ручного шага, без даунтайма (ALTER ADD COLUMN на SQLite — мгновенный).
-
-## 4. Self-hosting безопасность (NFR-6)
-
-- Механизм **не** рестартит/не роняет прод-контейнер, **не** пушит/force-push в `main`. Это
-  routing-решение планировщика + аддитивная колонка + read-only наблюдаемость.
-- Выкат самого ORCH-019 на прод орка идёт штатным конвейером через обязательный
-  `deploy-staging` (8501) → `Confirm Deploy` (ORCH-059). Топология/процедура — `docs/operations/INFRA.md`.
-
-## 5. Новый эндпоинт (эскалация)
-
-`POST /bug-fast-track/escalate?work_item=<id>` — админ-ручка возврата задачи в полный цикл
-(`track → 'full'`), по образцу `POST /serial-gate/unfreeze`. Без новой инфраструктуры (тот же
-FastAPI-приложение/порт). Read-only блок `bug_fast_track` добавляется в существующий `GET /queue`.
-</content>

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

@@ -1,64 +0,0 @@
----
-work_item: ORCH-019
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным (Data Requirements): ORCH-019 — Багфикс-трек
-
-Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
-
-> ⚠️ Общая прод-БД (self-hosting + enduro). Только **аддитивные, идемпотентные** миграции;
-> существующие контракты таблиц не меняются.
-
----
-
-## 1. Новая колонка `tasks.track`
-
-| Атрибут | Значение |
-|---------|----------|
-| Таблица | `tasks` |
-| Колонка | `track` |
-| Тип | `TEXT` |
-| DEFAULT | `'full'` |
-| Допустимые значения | `'full'` (дефолт; ВСЕ существующие и не-баг задачи) \| `'bug'` |
-| Миграция | `_ensure_column(conn, "tasks", "track", "TEXT DEFAULT 'full'")` (идемпотентно, паттерн `tasks.cancelled_at` ORCH-090) |
-| Размещение | рядом с `_ensure_column(conn, "tasks", "cancel_requested_at", ...)` в init `src/db.py` |
-
-**Семантика:** тип задачи (полный цикл / багфикс). Записывается в `start_pipeline` после
-успешного `create_task_atomic` (`created=True`) при `is_bug_task==True`. Читается в `advance_stage`
-для routing-override (D3) — из БД, **никогда** из сети (NFR-4).
-
-## 2. Хелперы доступа (`src/db.py`)
-
-| Хелпер | Контракт |
-|--------|----------|
-| `set_task_track(task_id: int, track: str) -> None` | `UPDATE tasks SET track=? WHERE id=?`; идемпотентно; never-raise на уровне вызова в `start_pipeline`/escalate |
-| `get_task_track(task_id: int) -> str` | `SELECT track FROM tasks WHERE id=?`; отсутствие/NULL → `'full'` (fail-safe → полный цикл) |
-
-## 3. Что НЕ меняется
-
-- Сигнатура `create_task_atomic(plane_id, work_item_id, repo, branch, stage, title)` —
-  **без изменений** (задача создаётся как `track='full'` по DEFAULT, тип проставляется отдельным
-  `set_task_track`).
-- Существующие колонки `tasks` (прочие), таблицы `jobs`, `job_deps`, `agent_runs`,
-  `coverage_baseline`, `repo_freeze`, `tracker_messages` — **без изменений**.
-- `claim_next_job` — **без изменений** (не читает `track`; сеть/маршрут в горячем claim не вводятся).
-
-## 4. Обратная совместимость / откат
-
-- Колонка аддитивна с безопасным DEFAULT `'full'` → существующие строки и enduro-задачи ведут
-  себя как сегодня без обратной записи.
-- Откат фичи (`bug_fast_track_enabled=False`) не требует удаления колонки: при выключенном флаге
-  `track` не влияет на маршрут (`skips_architecture` → `False`). Остаточная колонка безвредна.
-- Полный revert PR: миграция `_ensure_column` идемпотентна; повторный запуск на БД с уже
-  существующей колонкой — no-op.
-
-## 5. Объём данных / производительность
-
-- Одна `TEXT`-колонка на строку `tasks` (низкая кардинальность: 2 значения). Индекс не требуется
-  (чтение по `id` PK в `advance_stage`; агрегат для `GET /queue` — редкий read-only скан).
-</content>

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

@@ -1,39 +0,0 @@
----
-work_item: ORCH-019
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-019 — Багфикс-трек
-
-Work Item: **ORCH-019** · Repo: **orchestrator** · Стадия: architecture
-
-> Шкала: вероятность × влияние ∈ {Низк., Средн., Выс.}. Каждый риск — с митигатором, привязанным
-> к ADR-001 / AC.
-
----
-
-| ID | Риск | Вер. | Влияние | Митигатор |
-|----|------|------|---------|-----------|
-| R-1 | **Срезали лишнее** — ошибочный пропуск гейта качества → недоделка на проде (урок ET-8). | Низк. | Выс. | NFR-1 диктует **нулевую** поверхность правок гейтов (D4): `STAGE_TRANSITIONS`/`QG_CHECKS`/все `check_*`/вердикт-ключи — байт-в-байт; режется ТОЛЬКО стадия `architecture`. Тест AC-3: на багфикс-треке отрабатывают все гейты. |
-| R-2 | **Сложный баг под меткой `Bug`** уходит на фаст-трек и упирается в отсутствие архитектуры. | Средн. | Средн. | Эскалация D5 (эндпоинт `escalate` + self-escalate мини-аналитика) сбрасывает `track→full` → задача идёт через `architecture`. AC-5. |
-| R-3 | **Регресс-тест не написан** (developer «забыл») → рецидив бага. | Средн. | Выс. | BR-4: обязательный TC в `04-test-plan.yaml` + reviewer-ось (фикс без теста → REQUEST_CHANGES) + структурный союзник coverage-gate ORCH-027. AC-4. |
-| R-4 | **Fail-safe инвертирован** — ошибка чтения метки молча срежет стадии. | Низк. | Выс. | never-raise leaf `bug_fast_track.py`: любая ошибка/неоднозначность/`None`-labels → `is_bug_task=False` → полный цикл; `get_task_track` при NULL → `'full'`. AC-6. |
-| R-5 | **Конфликт с serial-gate/auto-label** при изменённой точке входа. | Низк. | Средн. | Точка входа НЕ меняется (задача стартует на `analysis`, ветвление — только на ребре выхода). serial_gate/auto-label маркированный код не правится. Интеграционный тест композиции (AC-9). |
-| R-6 | **Ложная блокировка** облегчённого пакета exit-гейтом `analysis` (`check_analysis_complete` требует 01/02/03/04). | Низк. | Средн. | D4: гейт НЕ трогаем; lite-аналитик эмитит все 4 файла (02/03 — краткие заглушки). FR-6/OQ-6. |
-| R-7 | **Правка маркированного `advance_stage`** (несёт врезки ORCH-088/089/027/059/094) сломает чужой инвариант. | Низк. | Выс. | Врезка ORCH-019 — ТОЛЬКО на ребре выхода из `analysis`, ДО всех deploy-edge под-гейтов; порядок под-гейтов/merge-lease/terminal-sync не затронуты (CLAUDE.md §9: сверка `06-adr/` затронутых ORCH-NNN). |
-| R-8 | **Телеметрия `mark_brd_review_ended`** не сработает на багфиксе (next=`development`, не `architecture`) → искажённая метрика «твоё время». | Низк. | Низк. | D3: условие расширено до `next_stage in ("architecture","development")`. Не влияет на гейты. |
-| R-9 | **Метрика экономии** (FR-7) вводит в заблуждение (несравнимые задачи). | Низк. | Низк. | Метрика помечена как относительная оценка из существующей телеметрии `agent_runs`; без новой тяжёлой инфраструктуры; read-only, never-raise. AC-7. |
-
----
-
-## Сводный вывод
-
-Доминирующий риск — **R-1 (срезали лишнее)**; он структурно закрыт нулевой поверхностью правок
-гейтов (D4) — изменение касается планировщика/точки входа, а не Quality Gate. Остальные риски
-покрыты паттерном leaf+флаги+fail-safe (ORCH-088/089/027) и обратимой эскалацией (D5). Откат —
-мгновенный через `bug_fast_track_enabled=False`.
-</content>

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

@@ -1,108 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-019
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-019
-version: 1
----
-
-# Review ORCH-019 — Багфикс-трек (упрощённый/дешёвый маршрут для багов)
-
-## Summary
-
-Реализация соответствует ТЗ (`02-trz.md`), ADR-001 и всем 9 критериям приёмки
-(`03-acceptance-criteria.md`). Корневой инвариант NFR-1 («срезается только аналитика/архитектура;
-ни один Quality Gate не тронут») соблюдён **структурно**: `src/stages.py` и `src/qg/checks.py` —
-**пустой diff**; маршрутизация багфикса реализована чистым routing-override в `advance_stage`, как
-и предписывал ADR (D3). Полный регресс `tests/` зелёный (**1551 passed**), 46 целевых тестов
-ORCH-019 (6 suites) — PASS. Документация обновлена исчерпывающе во всех требуемых поверхностях.
-Findings уровня P0/P1 — нет. → **APPROVED**.
-
-## Проверка по осям
-
-### 1. Соответствие ТЗ / Acceptance Criteria
-- **AC-1 (классификация по метке `Bug`)** ✓ — `bug_fast_track.is_bug_task` делегирует в
-  `labels.has_label` (источник истины — Plane API, не payload); `applies(repo)` (локальный)
-  проверяется ПЕРВЫМ в `start_pipeline` → при выключенном флаге нулевой сетевой оверхед.
-- **AC-2 (пропуск `architecture`)** ✓ — override на ребре выхода из `analysis`
-  (`next_stage → development`, `next_agent → developer`); `STAGE_TRANSITIONS`/`get_next_stage`/
-  `get_agent_for_stage` остались чистыми (1:1). Анти-регресс структуры — TC-06.
-- **AC-3 (все QG сохранены — корневой инвариант)** ✓ — `git diff` по `src/stages.py`/`src/qg/`
-  пуст; вердикт-ключи и порядок под-гейтов не тронуты (TC-07). Подтверждено независимой проверкой
-  diff, не только тестом.
-- **AC-4 (обязательный регресс-тест)** ✓ — ось добавлена в `.openclaw/agents/reviewer.md`
-  («фикс без теста-фиксатора → finding ≥P1»); `04-test-plan.yaml` несёт требование. (Сам ORCH-019 —
-  feature, не bugfix, поэтому правило к нему не применяется; покрытие — 46 содержательных тестов.)
-- **AC-5 (эскалация)** ✓ — `POST /bug-fast-track/escalate` (`db.set_task_track 'bug'→'full'`,
-  Telegram+Plane-коммент, never-raise) + self-escalate мини-аналитика (`analyst.md`).
-- **AC-6 (fail-safe / нулевая регрессия)** ✓ — `bug_fast_track_enabled` kill-switch; все публичные
-  функции leaf'а never-raise → False (full cycle); `get_task_track` деградирует в `'full'`.
-  Дефолт `True` согласован со всеми sibling-флагами (serial_gate/auto_label/coverage/stop/… все
-  `= True` при пустом scope = self-hosting only).
-- **AC-7 (наблюдаемость)** ✓ — read-only блок `bug_fast_track` в `GET /queue` (`snapshot()`,
-  never-raise) + отметка `🐞` в Telegram-карточке (never-raise) + лог-строки на решение.
-- **AC-8 (аддитивность / self-hosting)** ✓ — `_ensure_column(tasks, track, "TEXT DEFAULT 'full'")`
-  идемпотентна (TC-15); прод-контейнер/`main` не трогаются; полный `tests/` зелёный.
-- **AC-9 (композиция)** ✓ — serial-gate/auto-label/coverage/merge — тест композиции зелёный
-  (TC-14); override применяется ДО всех deploy-edge под-гейтов.
-
-### 2. Соответствие ADR
-Реализация точно следует ADR-001 (D1–D8): leaf `src/bug_fast_track.py`, колонка `tasks.track`,
-override в `advance_stage`, эскалация-эндпоинт, область self-hosting-only. Сквозной ADR
-`adr-0032-bug-fast-track.md` присутствует.
-**Трассировка:** `advance_stage` несёт маркеры ORCH-088/089/027/059/094; врезка ORCH-019 добавляет
-ветвление ТОЛЬКО на ребре выхода из `analysis` (до deploy-edge под-гейтов) — зафиксированные
-инварианты (порядок под-гейтов, merge-lease, terminal-sync) не нарушены. Сверено по diff. Расширение
-`mark_brd_review_ended` на `analysis → development` (ORCH-087 метрика) гейтов не касается.
-
-### 3. Качество кода
-- Leaf чист (импортирует только `config`, лениво `labels`/`db`/`qg.checks`), never-raise контракт
-  соблюдён везде, публичные функции снабжены docstrings. ✓
-- Next-agent override (`next_stage == "development"`) безопасен: единственный путь к
-  `analysis → development` — сам багфикс-override (штатно `get_next_stage("analysis") == "architecture"`). ✓
-- `get_task_by_work_item_id`/`add_comment`/`set_task_track`/`get_task_track` существуют и
-  совместимы по сигнатурам. ✓
-
-### 4. Документация — обязательная проверка
-`src/` изменён → документация ДОЛЖНА быть обновлена. **Обновлено в том же PR:**
-- `docs/architecture/README.md` — раздел «Багфикс-трек (ORCH-019)» + блок `bug_fast_track` в `GET /queue`;
-- `README.md` — таблица env (`ORCH_BUG_FAST_TRACK_*`) + обзорный раздел;
-- `.env.example` — три новых переменных;
-- `docs/architecture/adr/adr-0032-bug-fast-track.md` (сквозной) + `06-adr/ADR-001`;
-- `docs/architecture/internals.md`, `CLAUDE.md`, `CHANGELOG.md` (`feat:`);
-- `07-infra-requirements.md` / `08-data-requirements.md` / `10-tech-risks.md`;
-- `.openclaw/agents/analyst.md` (lite-пакет + self-escalate) и `reviewer.md` (ось регресс-теста).
-
-Все поверхности из §8 ТЗ покрыты. **Обзорная витрина README** — добавлен раздел, ничего из «Известных
-ограничений» не оставлено открытым в нарушение ORCH-079.
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет)
-
-### P2 — Should fix
-- (нет)
-
-### P3 — Nice to have
-- [ ] `snapshot.est_saved_architecture_runs == total_bug_tasks` считает ВСЕ багфикс-задачи, включая
-  `cancelled` (которые могли не дойти до пропуска `architecture`). Косметическая неточность метрики
-  экономии; на гейты/маршрут не влияет. Можно сузить до `stage NOT IN ('cancelled')` при случае.
-
-## Документация
-Обновлена полностью и согласованно во всех требуемых поверхностях (architecture/README, README env +
-обзор, оба ADR, internals, CLAUDE.md, CHANGELOG, .env.example, промпты analyst/reviewer,
-infra/data/risks). Расхождений код↔документация не обнаружено. Требований к доработке документации
-нет.
-
-## Вердикт
-Нет findings уровня P0/P1; документация обновлена; корневой инвариант подтверждён независимой
-проверкой diff и зелёным полным регрессом (1551 passed). → **APPROVED**.

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

@@ -1,84 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-019
-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-019
----
-
-# Test Report — ORCH-019 — Багфикс-трек (упрощённый/дешёвый маршрут для багов)
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-019-` (ветка `feature/ORCH-019-`)
-- Дата: 2026-06-10T00:53:34Z
-- Предусловие: review `12-review.md` = `verdict: APPROVED` ✓
-
-## Smoke API (read-only)
-| Endpoint | Результат | Примечание |
-|----------|-----------|------------|
-| `GET /health` | PASS | `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS | отвечает; ORCH-019 (task 84) виден на стадии `testing` |
-| `GET /queue` | PASS | блок `serial_gate` присутствует (ORCH-088) ✓; `auto_labels` присутствует ✓ |
-
-> Прод-контейнер (8500) исполняет код **до** ORCH-019 (фича ещё не задеплоена), поэтому блока
-> `bug_fast_track` в живом `/queue` ожидаемо нет — это не регресс смока. Обязательные для смока
-> блоки `serial_gate` и `auto_labels` присутствуют. Новый блок `bug_fast_track` верифицирован
-> юнит/интеграционными тестами `test_queue_endpoint.py` (TC-13) на коде ветки. Smoke — read-only,
-> прод-контейнер не трогался.
-
-## Результаты — покрытие TC из `04-test-plan.yaml`
-
-| TC ID | Описание (кратко) | Тип | Тесты | AC | Результат |
-|-------|-------------------|-----|-------|----|-----------|
-| TC-01 | `is_bug_task()` True для метки `Bug`; источник — Plane API, не payload | unit | `test_tc01_is_bug_task_true`, `test_tc01_label_from_plane_api_not_payload` | AC-1 | PASS |
-| TC-02 | `is_bug_task()` False при отсутствии/неоднозначной метке/`labels=None` (fail-safe) | unit | `test_tc02_label_absent`, `test_tc02_labels_none`, `test_tc02_label_ambiguous`, `test_tc02_empty_label_config` | AC-1/AC-6 | PASS |
-| TC-03 | `bug_fast_track_applies(repo)`: локальная область ПЕРВОЙ; выключенный флаг → без сети | unit | `test_tc03_empty_csv_self_hosting_only`, `test_tc03_csv_membership`, `test_tc03_killswitch_off_no_network` | AC-6 | PASS |
-| TC-04 | never-raise: исключение в fetch labels → деградация в False (полный цикл) | unit | `test_tc04_is_bug_task_never_raises`, `test_tc04_applies_never_raises` | AC-6 | PASS |
-| TC-05 | Маршрут: bug → next stage после analysis = `development`; не-баг = `architecture` | unit | `test_tc05_bug_task_skips_architecture`, `test_tc05_full_task_keeps_architecture`, `test_tc05_killswitch_off_bug_keeps_architecture`, `test_tc05_bug_only_affects_analysis_edge` | AC-2 | PASS |
-| TC-06 | `STAGE_TRANSITIONS` структурно не изменён (анти-регресс) | unit | `test_tc06_stage_transitions_unchanged`, `test_tc06_get_next_stage_pure` | AC-2 | PASS |
-| TC-07 | `QG_CHECKS`/сигнатуры `check_*`/вердикт-ключи не изменены (имя+регистр) | unit | `test_tc07_qg_checks_registry_unchanged`, `test_tc07_verdict_keys_preserved` | AC-3 | PASS |
-| TC-08 | E2E багфикс-трек проходит development→…→deploy, минуя architecture, все гейты | integration | `test_tc08_bug_task_full_walk_skips_architecture` | AC-2/AC-3 | PASS |
-| TC-09 | `start_pipeline`: метка Bug → bug-track; без метки → full-track | integration | `test_tc09_bug_label_creates_bug_track`, `test_tc09_no_label_creates_full_track` | AC-1 | PASS |
-| TC-10 | Fail-safe: `enabled=False` → метка Bug идёт полным циклом (нулевая регрессия) | integration | `test_tc10_killswitch_off_bug_label_full_cycle` | AC-6 | PASS |
-| TC-11 | Эскалация: `'bug'→'full'` → штатный маршрут с architecture | integration | `test_tc11_escalate_returns_to_full_cycle`, `test_tc11_escalate_unknown_work_item`, `test_tc11_escalate_missing_arg`, `test_tc11_escalate_idempotent_on_full` | AC-5 | PASS |
-| TC-12 | `check_analysis_*` не блокирует ложно lite-пакет; не ослаблен для не-баг | unit | `test_tc12_bug_lite_package_with_all_four_passes`, `test_tc12_missing_file_still_fails_for_any_track`, `test_tc12_signature_has_no_track_param` | AC-3/FR-6 | PASS |
-| TC-13 | `GET /queue` несёт read-only блок `bug_fast_track`; существующие ключи целы | integration | `test_queue_has_bug_fast_track_block_and_keeps_existing_keys`, `test_queue_bug_fast_track_counts_bug_tasks` | AC-7 | PASS |
-| TC-14 | Композиция: bug-задача учтена serial-gate; autoApprove/autoDeploy применимы | integration | `test_tc14_bug_task_counts_as_active_in_serial_gate`, `test_tc14_bug_task_itself_gated_behind_predecessor`, `test_tc14_bug_task_claimable_once_predecessor_done`, `test_tc14_auto_label_applies_track_agnostic` | AC-9 | PASS |
-| TC-15 | Миграция `tasks.track` аддитивна/идемпотентна; дефолт `'full'` | unit | `test_tc15_track_column_present_with_default`, `test_tc15_init_db_idempotent`, `test_tc15_helpers_round_trip`, `test_tc15_get_task_track_missing_row_failsafe` | AC-8 | PASS |
-
-**Итог покрытия:** все 15 TC из `04-test-plan.yaml` выполнены и сопоставлены с критериями
-`03-acceptance-criteria.md` (AC-1…AC-9). Непокрытых/пропущенных TC нет.
-
-## Вывод pytest
-
-### Целевые suite ORCH-019 (6 файлов + queue/migrations)
-```
-$ pytest tests/test_bug_fast_track.py tests/test_bug_fast_track_routing.py \
-         tests/test_bug_fast_track_gates.py tests/test_bug_fast_track_e2e.py \
-         tests/test_bug_fast_track_escalation.py tests/test_bug_fast_track_composition.py \
-         tests/test_queue_endpoint.py tests/test_db_migrations.py -v
-...
-======================== 46 passed, 1 warning in 2.51s =========================
-```
-46/46 целевых тестов — PASS.
-
-### Полный регресс
-```
-$ pytest tests/ -q --tb=short
-........................................................................ [100%]
-1551 passed, 1 warning in 56.64s
-```
-1551/1551 — PASS, 0 failed. (Единственный warning — известный Pydantic V2 deprecation в
-`src/config.py:8`, не относится к ORCH-019.)
-
-## Итог
-**PASS** — полный регресс (1551 passed) и целевые suites ORCH-019 (46 passed) зелёные; smoke API
-(`/health`/`/status`/`/queue` с блоками `serial_gate`+`auto_labels`) — OK; все 15 TC выполнены и
-сопоставлены с AC-1…AC-9. Корневой инвариант NFR-1 (неизменность `STAGE_TRANSITIONS`/`QG_CHECKS`/
-вердикт-ключей) подтверждён анти-регресс-тестами TC-06/TC-07. → стадия переходит на `deploy-staging`.

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

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

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

@@ -1,51 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-019
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T00:56:51Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live `orchestrator-staging` environment (port 8501),
-run inside the `orchestrator-staging` container (canonical path, ORCH-048):
-
-```
-docker exec orchestrator-staging \
-  python3 /repos/orchestrator/scripts/staging_check.py \
-  --base-url http://localhost:8501 --mode stub
-```
-
-**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
-
-- REAL failed: **none**
-- SANDBOX_INFRA waived (ORCH-061): C9a, C9b
-
-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
-
-## Check breakdown
-
-| Block | Check | Result |
-|-------|-------|--------|
-| A SMOKE | A1 GET /health → 200 status=ok | ✓ PASS |
-| A SMOKE | A2 GET /queue → 200 with counts/max_concurrency/resilience | ✓ PASS |
-| A SMOKE | A3 ORCH_STAGING=true (not prod) | ✓ PASS |
-| B ACCESS | B4 Plane: sandbox project accessible | ✓ PASS |
-| B ACCESS | B5 Gitea: orchestrator-sandbox accessible, push=true | ✓ PASS |
-| B ACCESS | B6 Registry: sandbox present, prod ET/ORCH absent | ✓ PASS |
-| C E2E | C7 Create issue in Plane SANDBOX | ✓ PASS |
-| C E2E | C8 Trigger pipeline via /webhook/plane | ✓ PASS |
-| C E2E | C9a Branch appears in orchestrator-sandbox | ✗ FAIL (INFRA-WAIVED) |
-| C E2E | C9b Analyst job enqueued in staging queue | ✗ FAIL (INFRA-WAIVED) |
-
-Cleanup: Plane issue deleted (HTTP 204); no branch to delete.
-
-Exit-code → verdict mapping unchanged: exit 0 → `staging_status: SUCCESS`. Waived checks are not
-re-judged (trust the exit code; the two infra-only checks C9a/C9b depend on SANDBOX bot accounts
-being project members, not on the pipeline). Staging gate **PASSED**; task advances to `deploy`.

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

@@ -1,7 +0,0 @@
-# Business Request: Code coverage как гейт (защита от деградации покрытия тестами)
-
-Work Item ID: ORCH-027
-
-## Description
-
-TBD

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

@@ -1,166 +0,0 @@
----
-work_item: ORCH-027
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-027 — Code coverage как гейт (защита от деградации покрытия тестами)
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-Оркестратор ведёт **автономную** разработку: код пишет агент `developer` без человеческого
-фильтра, а на стадии `testing` агент `tester` сам решает, достаточно ли тестов. Существующие
-тестовые гейты проверяют только **факт прохождения** тестов, а не их **полноту**:
-
-- `check_ci_green` (ребро `development → review`) — зелёный прогон `pytest tests/` в Gitea CI
-  (`.gitea/workflows/ci.yml`), судит по exit-code, покрытие **не меряет**.
-- `check_tests_passed` (ребро `testing → deploy-staging`) — читает machine-verdict
-  `result:`/`verdict:`/`status:` из `13-test-report.md`; это вердикт LLM-`tester`'а, а не
-  измеренная метрика.
-- Merge-gate re-test (ORCH-043) — повторный `pytest` на догнанной ветке, тоже только exit-code.
-
-Ни один гейт не замечает, что фича добавила 300 строк кода и 0 тестов, или что багфикс
-изменил поведение без регрессионного теста. При пакетном автономном прогоне (эпик ORCH-088,
-«10–20 задач за ночь») это означает **монотонную деградацию покрытия**: каждая задача может
-«срезать угол» на тестах, и за десятки задач проект тихо теряет тестируемость. Предложено
-Стрим, одобрено Славой (`00-business-request.md`).
-
-**Задача вводит измеримый гейт покрытия**: покрытие тестами измеряется инструментально и не
-должно опускаться ниже политики (абсолютный порог и/или «не ниже базовой линии»). Это
-структурная защита от деградации, аналогичная по духу security-гейту (ORCH-022) —
-детерминированная метрика вместо доверия суждению агента.
-
-> **Self-hosting.** Гейт работает на инструменте, который в проде обслуживает все проекты из
-> общей БД и очереди (`CLAUDE.md` §self-hosting). Измерение покрытия — это исполнение тест-сьюта
-> в изолированном worktree; оно **не трогает прод-контейнер и не касается `main`**.
-
-## 2. Объём (scope)
-
-### В объёме
-- Инструментальное измерение покрытия тестами для репозитория `orchestrator` (стек Python /
-  pytest) перед слиянием ветки задачи в `main`.
-- Гейт-решение: покрытие **не ниже** заданной политики порога. Политика поддерживает два режима:
-  абсолютный порог (`%`) и «не ниже базовой линии» (no-regression / ratchet), а также их
-  комбинацию.
-- Хранение и обновление **базовой линии** покрытия (last-known покрытие `main`).
-- Наблюдаемость результата: артефакт-отчёт о покрытии с machine-readable вердиктом, строка в
-  `GET /queue`, сигнал в Telegram при провале.
-- Конфигурируемость: kill-switch + per-repo область + настраиваемый порог/политика +
-  поведение при ошибке инструмента (fail-open/closed).
-
-### Вне объёма
-- Реализация измерения покрытия для НЕ-Python стеков (jest / jacoco для будущих репозиториев) —
-  фактическая интеграция инструментов оставлена на будущее; в ORCH-027 закладывается лишь
-  расширяемость (политика и хранилище не должны быть жёстко завязаны на Python).
-- Изменение существующей семантики `check_ci_green` / `check_tests_passed` /
-  `check_reviewer_verdict` для репозиториев, где гейт покрытия выключен.
-- Принудительное доведение покрытия до 100% или установка агрессивного абсолютного порога —
-  стартовая политика консервативна (см. NFR-4).
-- Покрытие самих тестовых файлов и мутационное тестирование.
-- Выбор конкретного инструмента/механизма интеграции и его расположения в конвейере как
-  архитектурного решения — это зона архитектора (`06-adr/`); BRD/ТЗ фиксируют требования и
-  кандидатные точки, выведенные из фактического кода.
-
-## 3. Заинтересованные стороны
-
-- **Заказчик / инициатор:** Стрим (предложение), Слава (одобрение).
-- **Затрагиваются:** конвейер `orchestrator` (self-hosting); агенты `developer`/`tester`
-  (теперь обязаны держать покрытие); проект enduro-trails — **не должен быть затронут** (гейт
-  по умолчанию неактивен вне сконфигурированных репозиториев).
-- **Принимает результат:** reviewer (стадия `review`) + финальная стадия конвейера; владелец
-  (Owner) — по факту работы гейта в проде.
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 — Измерение покрытия.** Перед слиянием ветки задачи в `main` покрытие тестами
-  репозитория измеряется инструментально (исполнением тест-сьюта под coverage-инструментацией),
-  а не оценивается на глаз. Результат — числовая метрика покрытия (как минимум line coverage).
-- **BR-2 — Гейт деградации.** Если измеренное покрытие нарушает политику (ниже абсолютного
-  порога ИЛИ ниже базовой линии — в зависимости от выбранного режима), конвейер **не
-  пропускает** задачу дальше к деплою и инициирует штатный откат на `development` для доработки
-  тестов.
-- **BR-3 — Базовая линия (ratchet).** Поддерживается режим «не ниже предыдущего»: гейт
-  сравнивает покрытие ветки с зафиксированной базовой линией `main`. Базовая линия **обновляется
-  вверх** при успешном слиянии задачи в `main` (покрытие может только расти или держаться, но
-  не падать).
-- **BR-4 — Конфигурируемость и нулевая регрессия.** Гейт управляется kill-switch'ем и
-  per-repo областью (по образцу `merge_gate`/`security_gate`/`image_freshness`,
-  ORCH-035/043/058). Для репозиториев вне области (в частности enduro-trails) гейт — **полный
-  no-op**, поведение конвейера 1:1 как до задачи. Порог, политика (absolute|baseline|both) и
-  поведение при ошибке инструмента — настраиваемы.
-- **BR-5 — Наблюдаемость.** Результат измерения виден: (а) артефакт-отчёт о покрытии с
-  machine-readable вердиктом в `docs/work-items/<id>/`; (б) read-only блок в `GET /queue`;
-  (в) уведомление в Telegram при провале гейта (кликабельный номер задачи, как у прочих
-  алертов). Сообщение указывает измеренное покрытие, порог/базовую линию и дельту.
-- **BR-6 — Стек-расширяемость.** Логика политики (PASS/FAIL по метрике/базовой линии) и
-  хранилище базовой линии не зависят от конкретного инструмента; добавление измерителя для
-  другого стека (jest/jacoco) в будущем не требует переписывания ядра гейта.
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — never-raise / fail-safe.** Ядро гейта — изолированный leaf-модуль (по образцу
-  `src/security_gate.py`, `src/serial_gate.py`, `src/labels.py`): любая внутренняя ошибка
-  обрабатывается, исключение **никогда** не всплывает в `advance_stage` и не роняет конвейер
-  всех проектов.
-- **NFR-2 — Поведение при недоступности/ошибке инструмента.** По умолчанию ошибка измерения
-  (coverage-инструмент упал/недоступен) → **fail-open + громкий warning** (анти-петля,
-  прецедент ORCH-061/ORCH-022 dep-audit), переключаемое в fail-closed флагом. Дефолт не должен
-  заклинивать автономный конвейер из-за инфраструктурного сбоя.
-- **NFR-3 — Self-hosting безопасность.** Гейт только исполняет тесты в изолированном worktree,
-  читает метрику, пишет отчёт и принимает решение. Он **никогда** не вызывает деплой-хук, не
-  перезапускает прод-контейнер, не пушит/форс-пушит в `main`.
-- **NFR-4 — Консервативный старт (анти-флап).** Стартовая политика не должна массово заворачивать
-  существующие задачи: базовая линия инициализируется фактическим покрытием `main`, абсолютный
-  порог — как мягкий backstop. Допускается малый отрицательный допуск (epsilon) на шум измерения,
-  чтобы дрожание ±доли процента не заворачивало задачу.
-- **NFR-5 — Совместимость.** `STAGE_TRANSITIONS`, состав/семантика `QG_CHECKS` и `check_*`,
-  machine-verdict ключи существующих доков (`verdict:`/`result:`/`deploy_status:`/
-  `staging_status:`/`security_status:`) — не меняются. Любая новая БД-сущность — аддитивна
-  (без миграции существующих таблиц). Restart-safe.
-- **NFR-6 — Детерминизм.** Решение гейта — чистая функция от (измеренное покрытие, базовая
-  линия, порог, политика); без участия LLM в критическом пути (как security/merge/image-freshness
-  под-гейты).
-
-## 6. Допущения и ограничения
-
-- Тест-сьют `orchestrator` запускается командой `python -m pytest tests/` из корня репозитория
-  (подтверждено `.gitea/workflows/ci.yml`, `pytest.ini` `testpaths = tests`); измерение покрытия
-  накладывается на этот же прогон.
-- Coverage-инструмент для Python (`coverage.py` / `pytest-cov`) добавляется как pip-зависимость;
-  он не требует сети во время измерения.
-- Репозиторий `orchestrator` — единственный self-hosting (предикат `is_self_hosting_repo`);
-  стартовая область гейта — он. enduro-trails и прочие репозитории по умолчанию вне области.
-- Базовая линия привязана к покрытию `main`; её первичная инициализация выполняется один раз
-  (bootstrap) фактическим замером текущего `main`.
-- Тесты исполняются в per-branch worktree (`ensure_worktree`), что безопасно при параллельных
-  активных задачах (прецедент `check_tests_local`/merge-gate re-test).
-
-## 7. Критерии успеха
-
-- Покрытие тестами `orchestrator` измеряется на каждой задаче и не может опуститься ниже
-  политики, не заблокировав продвижение к деплою.
-- При выключенном флаге / вне области — конвейер ведёт себя 1:1 как до ORCH-027 (нулевая
-  регрессия для enduro-trails).
-- Сбой coverage-инструмента не заклинивает автономный конвейер (дефолт fail-open + warning).
-- Результат измерения прозрачен (отчёт + `GET /queue` + Telegram при провале).
-
-Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-
-- **Флап на шуме измерения** — недетерминированное покрытие (например, зависящее от порядка/
-  окружения) может дрожать у границы → ложные заворота. Митигировать epsilon-допуском (NFR-4).
-- **Петля заворотов** — слишком высокий абсолютный порог завернёт многие задачи в бесконечный
-  rework. Митигировать консервативной стартовой политикой и baseline-режимом.
-- **Гонка базовой линии** при параллельных слияниях — два слияния в `main` могут конкурентно
-  обновлять baseline. Требуется атомарное/сериализованное обновление (опереться на окно
-  сериализации merge-lease, ORCH-043).
-- **Инфраструктурная хрупкость** — coverage-инструмент недоступен/несовместим с версией pytest →
-  закрыто требованием NFR-2 (fail-open + warning).
-
-Детальная техническая проработка рисков — `10-tech-risks.md` (заполняет архитектор).

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

@@ -1,156 +0,0 @@
----
-work_item: ORCH-027
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные требования к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование и выбор механизма (где именно врезать гейт, как хранить базовую
-> линию, какой инструмент) — задача архитектора (`06-adr/`). Ниже зафиксированы требования и
-> **кандидатные** точки интеграции, грунтованные реальным кодом; финальное решение по каждой
-> отмеченной точке принимает архитектор.
-
-## 1. Сводка изменения
-
-Вводится **детерминированный гейт покрытия тестами** для репозитория `orchestrator`. Гейт
-измеряет покрытие исполнением тест-сьюта под coverage-инструментацией, сравнивает с политикой
-(абсолютный порог и/или базовая линия `main`) и блокирует продвижение задачи к деплою при
-деградации, инициируя штатный откат на `development`. Ядро — изолированный leaf-модуль с чистой
-логикой решения (по образцу `security_gate`/`serial_gate`), управляемый kill-switch'ем и per-repo
-областью; вне области — полный no-op. Базовая линия покрытия `main` хранится персистентно и
-обновляется вверх при слиянии (ratchet).
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие | Назначение |
-|------|----------|-----------|
-| `requirements.txt` | изменить | добавить coverage-зависимость Python (`coverage.py` / `pytest-cov`; точный выбор — архитектор) |
-| `src/coverage_gate.py` | создать | **NEW leaf-модуль**: измерение покрытия (run suite под coverage в `ensure_worktree`), чистые функции `compute_coverage_verdict(measured, baseline, floor, policy, epsilon)` и классификация, чтение/запись отчёта; never-raise; импортирует только `config`/`git_worktree` (+ лениво `qg.checks.is_self_hosting_repo`/`notifications`) |
-| `src/config.py` | изменить | добавить флаги гейта (см. §6 ниже / раздел совместимости) |
-| `src/qg/checks.py` | изменить | зарегистрировать механизм проверки покрытия (новый `check_*` ЛИБО делегирование из под-гейта); **семантика существующих `check_*` не меняется** |
-| `src/stage_engine.py` | изменить *(кандидат)* | врезка под-гейта в `advance_stage` по образцу `_handle_security_gate`/`_handle_merge_gate` — если выбран механизм «edge sub-gate» (см. §3 FR-3) |
-| `src/db.py` | изменить *(кандидат)* | аддитивная таблица базовой линии покрытия (`coverage_baseline` per-repo), если базовая линия хранится в БД, а не в файле; `_ensure_column`/`CREATE TABLE IF NOT EXISTS` — без миграции существующих |
-| `.gitea/workflows/ci.yml` | изменить *(кандидат)* | если измерение делается в CI-шаге — добавить `--cov`/порог в прогон pytest; **точка измерения — решение архитектора** |
-| `src/main.py` | изменить | read-only блок `coverage` в `GET /queue` (наблюдаемость) |
-| `docs/work-items/<id>/<NN>-coverage-report.md` | создать (артефакт run-time) | отчёт о покрытии с machine-readable вердиктом (см. §4/§6); номер/имя и регистрация в `docs/_standards/PIPELINE_DOCS.md` + скелет в `docs/_templates/` — оформляет архитектор |
-| `tests/test_coverage_gate.py` | создать | unit/integration по `04-test-plan.yaml` |
-
-## 3. Функциональные требования
-
-### FR-1 — Измерение покрытия (привязка BR-1)
-Гейт исполняет тест-сьют `orchestrator` (`python -m pytest tests/`, см. `.gitea/workflows/ci.yml`)
-под coverage-инструментацией в изолированном per-branch worktree (`ensure_worktree`, прецедент
-`check_tests_local`) и извлекает числовую метрику покрытия (как минимум суммарный line coverage,
-`%`). Тайм-аут на прогон ограничен (по образцу `merge_retest_timeout_s` / `security_scan_timeout_s`).
-
-### FR-2 — Решение гейта (привязка BR-2, BR-3)
-Чистая функция `compute_coverage_verdict(measured, baseline, floor, policy, epsilon) -> (ok, reason)`:
-- `policy = absolute` → PASS ⇔ `measured >= floor - epsilon`.
-- `policy = baseline` → PASS ⇔ `measured >= baseline - epsilon`.
-- `policy = both` (дефолт) → PASS ⇔ выполнены оба условия.
-- FAIL → гейт инициирует штатный откат на `development` для доработки тестов (по образцу
-  `_handle_security_gate` / merge-gate rollback), с инкрементом счётчика developer-retry.
-- `epsilon` — малый неотрицательный допуск на шум измерения (NFR-4), настраиваемый.
-
-### FR-3 — Точка в конвейере (привязка BR-2; **кандидат, решает архитектор**)
-Бизнес-запрос указывает «на testing-гейте». Грунтованные кодом кандидаты (выбрать один):
-- **(a) Edge sub-gate** в `advance_stage` на ребре `deploy-staging → deploy` (рядом с
-  `_handle_security_gate`/`_handle_merge_gate`/`_handle_image_freshness`) — даёт гарантию «гейт
-  ДО слияния в `main`», детерминирован, владеет исходом на вмешательстве. Предпочтительно для
-  соответствия NFR-3/NFR-6.
-- **(b) Под-гейт/расширение на ребре `testing → deploy-staging`** (рядом с `check_tests_passed`).
-- **(c) CI-шаг** в `.gitea/workflows/ci.yml` (ребро `development → review`, читается
-  `check_ci_green`) — порог проверяется самим pytest-прогоном.
-Требование, инвариантное к выбору: гейт обязан отработать **до фактического merge в `main`** и не
-пропускать деградацию в `main`.
-
-### FR-4 — Базовая линия и её обновление (привязка BR-3)
-- Персистентное per-repo хранилище базовой линии покрытия `main` (БД-таблица ИЛИ файл в репо —
-  решает архитектор; при БД — аддитивная таблица, NFR-5).
-- Bootstrap: первичная инициализация фактическим замером текущего `main`.
-- Ratchet-up: при успешном слиянии задачи в `main` базовая линия обновляется значением
-  смёрженного покрытия, **только если оно ≥ текущей** (покрытие не откатывается вниз). Обновление
-  должно быть атомарным/сериализованным относительно параллельных слияний (опереться на окно
-  merge-lease, ORCH-043).
-
-### FR-5 — Условность и kill-switch (привязка BR-4)
-- `coverage_gate_enabled=False` → гейт инертен, конвейер 1:1 как до ORCH-027.
-- `coverage_gate_repos` (CSV) — область применения; **пусто → только self-hosting**
-  (`is_self_hosting_repo`, по образцу `merge_gate`/`security_gate`/`image_freshness`).
-- Вне области → no-op `(True, "Coverage gate N/A")` (прецедент `check_staging_status` для
-  не-self-hosting, ORCH-035).
-- `applies(repo)` (локальная проверка) выполняется ПЕРВОЙ; дорогой прогон измерения — только при
-  `applies==True`.
-
-### FR-6 — Поведение при ошибке инструмента (привязка NFR-2)
-Ошибка/недоступность coverage-инструмента или невозможность распарсить метрику → по умолчанию
-**fail-open + WARNING** (`coverage_tool_fail_closed=False`, прецедент `security_dep_audit_fail_closed`);
-флаг переключает в fail-closed. Поведение логируется явной observability-строкой.
-
-### FR-7 — Наблюдаемость (привязка BR-5)
-- Артефакт-отчёт `<NN>-coverage-report.md` с machine-readable вердиктом (см. §4).
-- Read-only блок `coverage` в `GET /queue` (per-repo: `enabled`/`policy`/`floor`/`baseline`/
-  последнее измеренное/вердикт).
-- При FAIL — `send_telegram` (notifying) с кликабельным номером задачи (`plane_issue_link`),
-  измеренным покрытием, порогом/базовой линией и дельтой.
-
-## 4. Изменения API
-
-- **`GET /queue`** — добавить read-only блок `coverage` (наблюдаемость; форма прочих блоков
-  `serial_gate`/`security`/`merge`). Без изменения существующих полей ответа.
-- **Опционально (решает архитектор):** ручной эндпоинт сброса/override базовой линии
-  (`POST /coverage/baseline?repo=…`) — по образцу `POST /serial-gate/unfreeze`, на случай
-  легитимного разового снижения покрытия. Если не вводится — override выполняется через конфиг.
-- Существующие webhook-роуты (`/webhook/plane`, `/webhook/gitea`) — без изменений.
-
-## 5. Изменения схемы БД
-
-Зависит от выбора хранилища базовой линии (FR-4):
-- **Если БД:** аддитивная таблица `coverage_baseline(repo TEXT PRIMARY KEY, coverage REAL,
-  updated_at, source_sha TEXT)` через `CREATE TABLE IF NOT EXISTS` (паттерн `repo_freeze`/
-  `job_deps`). Существующие таблицы — **не мигрируются** (NFR-5).
-- **Если файл в репо:** изменений схемы БД нет (базовая линия — версионируемый файл вроде
-  `.coverage-baseline.json`, читаемый/обновляемый под merge-lease).
-
-Выбор — архитектор; ТЗ требует лишь: персистентность, restart-safe, аддитивность, атомарность
-обновления.
-
-## 6. Требования к новым/изменённым QG checks
-
-- **Новый машинный вердикт покрытия.** Если гейт реализован как edge sub-gate (FR-3a/b), он
-  **сам вычисляет** вердикт (как `check_security_gate`) и пишет отчёт `<NN>-coverage-report.md`
-  с frontmatter-ключом `coverage_status:` (`PASS` | `FAIL`), читаемым обратно из того же файла
-  (single source of truth, по образцу `security_status:` в `17-security-report.md`). Имя ключа
-  фиксируется и регистр чувствителен.
-- **Реестр `QG_CHECKS`.** Допустимо добавить `check_coverage_gate` в реестр (если механизм —
-  зарегистрированный QG) ЛИБО оставить его врезкой-под-гейтом (как security/merge/image-freshness,
-  которые в `QG_CHECKS` присутствуют, но исполняются как врезки). **Семантика и состав
-  существующих `check_*` — без изменений** (NFR-5).
-- **Парсинг frontmatter** вердикта — через единый контракт `src/frontmatter.py`
-  (`parse_frontmatter`/`read_frontmatter_value`), как все вердикт-парсеры (ORCH-052c). Если
-  отчёт несёт обязательную 6-польную схему 52c — добавить её аддитивно, не трогая `coverage_status:`.
-
-## 7. Совместимость / регресс
-
-- **Обратная совместимость:** при `coverage_gate_enabled=False` или для репозитория вне
-  `coverage_gate_repos` — поведение конвейера байт-в-байт прежнее; enduro-trails не затронут.
-- **Kill-switch + поэтапный раскат:** `coverage_gate_enabled` (глобальный), `coverage_gate_repos`
-  (область). Старт — только `orchestrator`.
-- **Конфиг-флаги (итог §3/§6):** `coverage_gate_enabled` (bool), `coverage_gate_repos` (CSV),
-  `coverage_min_percent` (float, абсолютный порог), `coverage_policy` (`absolute|baseline|both`,
-  дефолт `both`), `coverage_epsilon` (float, допуск шума), `coverage_tool_fail_closed` (bool,
-  дефолт `False`), `coverage_run_timeout_s` (int). Имена env — `ORCH_COVERAGE_*`.
-- **never-raise / fail-open в hot-path:** ядро не роняет `advance_stage`; ошибка инструмента →
-  fail-open + warning по умолчанию (NFR-2). Прод-контейнер/`main`/force-push — не трогаются (NFR-3).
-- **Restart-safe:** базовая линия персистентна; in-flight измерение при рестарте переигрывается
-  штатным механизмом стадии (idempotent).
-- **Документация (golden source):** при выборе механизма архитектор регистрирует артефакт
-  `<NN>-coverage-report.md` и его machine-key в `docs/_standards/PIPELINE_DOCS.md` +
-  `docs/_templates/`, и обновляет `docs/architecture/README.md` и `CHANGELOG.md` в том же PR.

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

@@ -1,138 +0,0 @@
----
-work_item: ORCH-027
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
-репозитория.
-
----
-
-## AC-1 — Покрытие измеряется инструментально
-
-**Условие:** на применимом репозитории конвейер измеряет покрытие тестами исполнением сьюта под
-coverage-инструментацией перед слиянием в `main`.
-- **PASS:** в коде есть путь, который запускает `pytest` под coverage в изолированном worktree и
-  извлекает числовую метрику line coverage (`%`); coverage-зависимость добавлена в `requirements.txt`.
-- **FAIL:** покрытие не измеряется инструментально, метрика берётся из прозы/вердикта LLM, либо
-  зависимость не объявлена.
-
----
-
-## AC-2 — Гейт блокирует деградацию
-
-**Условие:** покрытие ниже политики не пропускается дальше к деплою.
-- **PASS:** при измеренном покрытии ниже порога/базовой линии (с учётом epsilon) гейт даёт FAIL и
-  инициирует штатный откат на `development` (инкремент developer-retry), задача не достигает `done`.
-- **FAIL:** задача с упавшим покрытием проходит гейт и продвигается к деплою/`done`.
-
----
-
-## AC-3 — Чистая функция решения
-
-**Условие:** вердикт — детерминированная чистая функция от (measured, baseline, floor, policy, epsilon).
-- **PASS:** `compute_coverage_verdict(...)` покрыта unit-тестами для всех режимов
-  (`absolute`/`baseline`/`both`), границ (равно порогу), epsilon-допуска; без участия LLM.
-- **FAIL:** решение принимает LLM, либо логика недетерминирована/не покрыта тестами границ.
-
----
-
-## AC-4 — Режим базовой линии (ratchet)
-
-**Условие:** поддержан режим «не ниже предыдущего» с обновлением базовой линии вверх при слиянии.
-- **PASS:** базовая линия персистентна per-repo; при слиянии обновляется значением смёрженного
-  покрытия только если оно ≥ текущей; bootstrap инициализирует её фактическим покрытием `main`;
-  обновление атомарно/сериализовано относительно параллельных слияний.
-- **FAIL:** базовая линия не хранится / откатывается вниз / обновляется неатомарно (гонка двух
-  слияний теряет/занижает значение).
-
----
-
-## AC-5 — Условность и нулевая регрессия
-
-**Условие:** вне области / при выключенном флаге — поведение конвейера 1:1 как до ORCH-027.
-- **PASS:** при `coverage_gate_enabled=False` или repo ∉ `coverage_gate_repos` гейт — no-op
-  (`(True, "...N/A")`); существующая тестовая база (`pytest tests/`) зелёная; enduro-trails не
-  затронут; `applies(repo)` проверяется до дорогого прогона.
-- **FAIL:** гейт срабатывает вне области, либо выключенный флаг меняет поведение, либо есть
-  регресс существующих тестов.
-
----
-
-## AC-6 — Fail-open по умолчанию при ошибке инструмента
-
-**Условие:** сбой/недоступность coverage-инструмента не заклинивает автономный конвейер.
-- **PASS:** при ошибке измерения и `coverage_tool_fail_closed=False` гейт даёт PASS + WARNING-лог
-  (observability-строка); флаг `=True` переключает в fail-closed (FAIL). Поведение покрыто тестом.
-- **FAIL:** ошибка инструмента по умолчанию заворачивает задачу (петля rework) либо роняет
-  `advance_stage`.
-
----
-
-## AC-7 — never-raise / self-hosting безопасность
-
-**Условие:** ядро гейта не роняет конвейер и не трогает прод/`main`.
-- **PASS:** `src/coverage_gate.py` — leaf (не импортирует `stage_engine`); любое исключение
-  перехвачено и не всплывает в `advance_stage`; код не вызывает деплой-хук, не перезапускает
-  прод-контейнер, не пушит/форс-пушит в `main`/`master`.
-- **FAIL:** исключение из гейта всплывает в `advance_stage`; гейт трогает прод-контейнер или `main`.
-
----
-
-## AC-8 — Совместимость контрактов
-
-**Условие:** существующие машинные контракты не изменены.
-- **PASS:** `STAGE_TRANSITIONS`, семантика существующих `check_*`, machine-verdict ключи
-  (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`) — байт-в-байт
-  прежние; любая новая БД-сущность аддитивна (без миграции существующих таблиц).
-- **FAIL:** изменена семантика/имя существующего гейта или вердикт-ключа; миграция ломает
-  существующую схему.
-
----
-
-## AC-9 — Машинный вердикт покрытия и наблюдаемость
-
-**Условие:** результат измерения прозрачен и машинно читаем.
-- **PASS:** при FAIL — Telegram-алерт с кликабельным номером задачи, измеренным покрытием,
-  порогом/базовой линией и дельтой; `GET /queue` несёт read-only блок `coverage`; артефакт-отчёт
-  с machine-readable вердиктом (`coverage_status: PASS|FAIL`) записан и читается обратно из того
-  же файла через `src/frontmatter.py`.
-- **FAIL:** результат не виден в `GET /queue`/Telegram, либо вердикт парсится из прозы, а не из
-  frontmatter, либо имя ключа не зафиксировано (регистр).
-
----
-
-## AC-10 — Документация обновлена (golden source)
-
-**Условие:** документация синхронизирована с изменением в том же PR.
-- **PASS:** если введён артефакт-отчёт — он зарегистрирован в `docs/_standards/PIPELINE_DOCS.md`
-  и `docs/_templates/`; обновлены `docs/architecture/README.md` (описание гейта/флагов) и
-  `CHANGELOG.md`; новые/изменённые инварианты несут маркер `ORCH-027`.
-- **FAIL:** функционал введён без обновления обзорной/стандартной документации (reviewer →
-  REQUEST_CHANGES, ORCH-079).
-
----
-
-## Сводная матрица AC ↔ FR/BR
-
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-2, FR-3 |
-| AC-3 | BR-2 / FR-2 / NFR-6 |
-| AC-4 | BR-3 / FR-4 |
-| AC-5 | BR-4 / FR-5 / NFR-5 |
-| AC-6 | NFR-2 / FR-6 |
-| AC-7 | NFR-1 / NFR-3 |
-| AC-8 | NFR-5 / FR-6 (§6 ТЗ) |
-| AC-9 | BR-5 / FR-7 / §6 ТЗ |
-| AC-10 | Правила агентов §2/§6 (CLAUDE.md) |

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

@@ -1,110 +0,0 @@
-work_item: ORCH-027
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Code coverage gate — защита от деградации покрытия тестами"
-framework: pytest
-scope: >
-  Покрываются: чистая логика вердикта покрытия (режимы absolute/baseline/both, границы,
-  epsilon), ratchet-обновление базовой линии, условность (kill-switch + per-repo область),
-  fail-open/fail-closed при ошибке инструмента, never-raise, наблюдаемость (GET /queue,
-  Telegram при FAIL), интеграция гейта в advance_stage / точку конвейера. Вне покрытия:
-  фактические измерители не-Python стеков (jest/jacoco), мутационное тестирование.
-notes: >
-  Тесты не должны исполнять реальный прод-деплой и не трогают prod-контейнер/main.
-  Измерение покрытия в тестах мокается/стабится (фиктивная метрика), реальный pytest-прогон
-  под coverage проверяется отдельным интеграционным тестом на минимальном фикстур-репо/worktree.
-  Полный регресс tests/ должен оставаться зелёным (нулевая регрессия для enduro-trails).
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "compute_coverage_verdict, policy=absolute: measured>=floor → PASS; measured<floor-epsilon → FAIL; ровно на пороге → PASS"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "compute_coverage_verdict, policy=baseline: measured>=baseline → PASS; ниже baseline-epsilon → FAIL (no-regression / ratchet)"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "compute_coverage_verdict, policy=both: PASS только при выполнении обоих условий; нарушение любого → FAIL"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "epsilon-допуск: дрожание покрытия в пределах epsilon у границы не заворачивает задачу (анти-флап, NFR-4)"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Ratchet базовой линии: при слиянии baseline растёт до смёрженного покрытия только если >= текущей; меньшее значение не понижает baseline"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Bootstrap базовой линии: первичная инициализация фактическим покрытием main при отсутствии сохранённого значения"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Условность applies(repo): пустой coverage_gate_repos → только self-hosting (is_self_hosting_repo); repo вне области → no-op (True, 'N/A'), дорогой прогон не запускается"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Kill-switch coverage_gate_enabled=False → гейт инертен, advance_stage ведёт себя 1:1 как до ORCH-027"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "Fail-open по умолчанию: ошибка/недоступность coverage-инструмента и coverage_tool_fail_closed=False → PASS + WARNING-лог; флаг True → FAIL (fail-closed)"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "never-raise: внутреннее исключение (битый вывод coverage, отсутствие worktree) перехватывается, не всплывает в advance_stage"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Запись/чтение отчёта: write_coverage_report пишет coverage_status: PASS|FAIL во frontmatter; parse читает обратно из того же файла через src/frontmatter.py (single source of truth)"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-12
-    type: unit
-    description: "Self-hosting безопасность: гейт не вызывает деплой-хук, не перезапускает прод-контейнер, не пушит/форс-пушит в main/master"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-13
-    type: integration
-    description: "Гейт в конвейере: при measured ниже политики advance_stage не продвигает к деплою и инициирует откат на development (инкремент developer-retry); при PASS — продвигает штатно"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-14
-    type: integration
-    description: "Реальное измерение: pytest под coverage в ensure_worktree на минимальном фикстур-репо возвращает корректную метрику line coverage и тайм-аутится по coverage_run_timeout_s"
-    module: tests/test_coverage_gate.py
-    expected: PASS
-
-  - id: TC-15
-    type: integration
-    description: "Наблюдаемость: FAIL даёт Telegram-алерт с кликабельным номером (измеренное/порог/дельта); GET /queue несёт read-only блок coverage; совместимость — STAGE_TRANSITIONS/QG_CHECKS/существующие вердикт-ключи не изменены"
-    module: tests/test_coverage_gate.py
-    expected: PASS

docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md

@@ -1,266 +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-001: Гейт покрытия тестами — edge sub-gate с ratchet-базовой линией
-
-Work Item: **ORCH-027** — детерминированный гейт покрытия тестами, блокирующий деградацию
-покрытия перед слиянием ветки задачи в `main`.
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0029-coverage-gate.md`** (решение
-кросс-каттинговое — вводит новый QG `check_coverage_gate`, новый edge-под-гейт ребра
-`deploy-staging→deploy`, новую аддитивную БД-таблицу `coverage_baseline` и новый артефакт
-`18-coverage-report.md`).
-
-## Статус
-Proposed
-
----
-
-## Контекст
-
-Оркестратор ведёт **автономную** разработку: код пишет агент `developer` без человека-фильтра,
-а на стадии `testing` агент `tester` сам решает, достаточно ли тестов. Существующие тестовые
-гейты судят только по **факту прохождения**, не по **полноте** (сверено по коду):
-
-- `check_ci_green` (`development → review`) — exit-code `pytest tests/` в Gitea CI
-  (`.gitea/workflows/ci.yml`); покрытие не меряется.
-- `check_tests_passed` (`testing → deploy-staging`, `qg/checks.py::_parse_tests_verdict`) —
-  читает machine-verdict LLM-`tester`'а из `13-test-report.md`, а не измеренную метрику.
-- Merge-gate re-test (ORCH-043, `src/merge_gate.py`) — повторный `pytest` на догнанной ветке,
-  снова только exit-code.
-
-Ни один гейт не замечает «300 строк кода, 0 тестов» или багфикс без регрессионного теста. При
-пакетном автономном прогоне (ORCH-088, «10–20 задач за ночь») это означает **монотонную
-деградацию покрытия**: каждая задача срезает угол на тестах, и за десятки задач проект тихо
-теряет тестируемость. Нужна детерминированная метрика вместо доверия суждению агента — по духу
-аналогично security-гейту (ORCH-022, adr-0012).
-
-Требования (`01-brd.md`/`02-trz.md`/`03-acceptance-criteria.md`): измерять покрытие
-инструментально перед merge в `main` (BR-1/FR-1); блокировать деградацию относительно
-абсолютного порога и/или базовой линии (BR-2/BR-3/FR-2); хранить и наращивать базовую линию
-(ratchet, FR-4); kill-switch + per-repo область, нулевая регрессия для enduro-trails
-(BR-4/FR-5); fail-open по умолчанию при сбое инструмента (NFR-2/FR-6); never-raise и
-self-hosting-безопасность (NFR-1/NFR-3); неизменность существующих контрактов (NFR-5).
-
-## Решение
-
-### Сводка
-
-Вводим **детерминированный (без LLM) гейт покрытия** как **под-гейт ребра
-`deploy-staging → deploy`** — рядом с security-gate (ORCH-022), merge-gate (ORCH-043) и
-image-freshness (ORCH-058), исполняемый **ПОСЛЕ merge-gate и ДО image-freshness**.
-`STAGE_TRANSITIONS` не меняется; в `QG_CHECKS` добавляется `check_coverage_gate`. Паттерн —
-1:1 как у соседних под-гейтов: leaf-модуль `src/coverage_gate.py` (never-raise) + тонкая
-обёртка в `QG_CHECKS` + врезка `_handle_coverage_gate` в `advance_stage`. Базовая линия `main`
-хранится в **аддитивной БД-таблице** `coverage_baseline` и наращивается **вверх** (ratchet) в
-choke-point подтверждённого merge `_handle_merge_verify` (ребро `deploy → done`). Вердикт
-пишется в артефакт `18-coverage-report.md` (frontmatter-ключ `coverage_status:`) и читается
-обратно из того же файла (single source of truth, как `security_status:`).
-
-### D1 — Точка в конвейере: edge sub-gate `deploy-staging → deploy`, ПОСЛЕ merge-gate (FR-3a)
-
-Из трёх кандидатов TRZ FR-3 выбран **(a) edge sub-gate** на ребре `deploy-staging → deploy`
-(`advance_stage`, `src/stage_engine.py`, блок `current_stage == "deploy-staging"`). Это даёт
-структурную гарантию «гейт ДО merge в `main`» (merge выполняется детерминированным merge-актором
-в `_handle_merge_verify` на ребре `deploy → done`), детерминизм и владение исходом на
-вмешательстве — полное соответствие NFR-3/NFR-6.
-
-**Порядок среди под-гейтов: security → merge → `coverage` → image-freshness.** Обоснование:
-
-- **ПОСЛЕ merge-gate (а не первым, как security).** Merge-gate выполняет догон ветки на свежий
-  `origin/main` (`auto_rebase_onto_main` под merge-lease, ORCH-043/026). Покрытие имеет смысл
-  мерить на **догнанном** HEAD — это ровно тот код, что landed в `main`; измерение до rebase
-  показало бы покрытие устаревшей базы. Поэтому coverage **обязан** идти после merge-gate
-  (в отличие от security, который специально фейлит дёшево ДО rebase).
-- **ДО image-freshness.** Прогон pytest под coverage дорог, но дешевле полного docker-rebuild
-  staging-образа. Фейлить покрытие до rebuild — экономия (паттерн «fail before expensive
-  rebuild», 07-infra security-гейта).
-- **Merge-lease held на этой точке.** Merge-gate уже захватил merge-lease (ORCH-043). Значит
-  **FAIL coverage обязан освободить merge-lease** при откате — как делает image-freshness
-  rollback (`merge_gate.release_merge_lease`, `stage_engine.py:1165`), и **в отличие** от
-  security-gate rollback (тот идёт ДО захвата lease и lease не трогает). Это явный инвариант
-  реализации (TR-2).
-
-Привязка: BR-2/FR-3/AC-2; NFR-3/AC-7.
-
-### D2 — Измеритель: `pytest-cov` (`coverage.py`), `--cov=src` (FR-1, BR-6)
-
-В `requirements.txt` добавляется **`pytest-cov`** (плагин-обёртка над `coverage.py`). Измерение —
-прогон `python -m pytest tests/ --cov=src --cov-report=json:<tmp>/coverage.json
---cov-report=` в изолированном per-branch worktree (`ensure_worktree`, прецедент
-`check_tests_local`/merge-gate re-test). Числовая метрика — `totals.percent_covered` из JSON
-(line coverage, `%`). Скоуп измерения — **`src/`** (не `tests/`: покрытие самих тестов вне
-объёма, BRD §«Вне объёма»). Сеть при измерении не нужна. Тайм-аут — `coverage_run_timeout_s`
-(по образцу `merge_retest_timeout_s`/`security_scan_timeout_s`).
-
-**Стек-расширяемость (BR-6/AC-… BR-6):** измеритель инкапсулирован за функцией
-`measure_coverage(repo, branch) -> float | None`; чистая логика решения
-`compute_coverage_verdict(...)` и хранилище базовой линии **не зависят** от Python/pytest.
-Добавление jest/jacoco-измерителя для будущего стека — новая ветка `measure_*`, без переписывания
-ядра. Фактическая интеграция не-Python стеков — вне объёма ORCH-027.
-
-### D3 — Чистая функция решения (FR-2, NFR-6, BR-2/BR-3)
-
-`compute_coverage_verdict(measured, baseline, floor, policy, epsilon) -> (ok: bool, reason: str)` —
-детерминированная чистая функция (без LLM, без I/O):
-
-- `policy = "absolute"` → PASS ⇔ `measured >= floor - epsilon`.
-- `policy = "baseline"` → PASS ⇔ `measured >= baseline - epsilon`.
-- `policy = "both"` (дефолт) → PASS ⇔ выполнены **оба** условия.
-- `baseline is None` (нет сохранённой базовой линии) → baseline-условие **не применяется**
-  (bootstrap: нельзя регрессировать против пустоты) → решает только absolute-часть; измеренное
-  значение засеет базовую линию при merge (D5).
-- `epsilon` — малый неотрицательный допуск на шум измерения (NFR-4/AC-4): дрожание ±доли
-  процента у границы не заворачивает задачу.
-
-FAIL → штатный откат на `development` + инкремент общего `_developer_retry_count` (cap
-`MAX_DEVELOPER_RETRIES`, затем `set_issue_blocked` + Telegram) — точно как security/merge-gate
-rollback. Дословный reason (измеренное/порог/базовая линия/дельта) встраивается в `task_desc`
-developer'а (паттерн ORCH-046). Привязка: AC-2/AC-3.
-
-### D4 — Хранилище базовой линии: аддитивная БД-таблица `coverage_baseline` (FR-4, NFR-5)
-
-Базовая линия `main` хранится в **БД**, не в файле репозитория:
-
-```sql
-CREATE TABLE IF NOT EXISTS coverage_baseline (
-    repo        TEXT PRIMARY KEY,
-    coverage    REAL NOT NULL,
-    source_sha  TEXT,
-    updated_at  TEXT NOT NULL
-);
-```
-
-(паттерн `repo_freeze`/`job_deps` — `CREATE TABLE IF NOT EXISTS`, существующие таблицы не
-мигрируются, NFR-5/AC-8; детали — `08-data-requirements.md`). **Почему БД, а не файл в репо**
-(`.coverage-baseline.json`): файл пришлось бы коммитить в `main` на каждый ratchet → git-churn,
-сам файл попадает в diff и может конфликтовать при параллельных merge, плюс он часть измеряемого
-дерева. БД-таблица — restart-safe, аддитивна, обновляется атомарно и не порождает коммитов.
-Таблица keyed by `repo` → общая прод-БД (self-hosting) безопасно разделяет базовые линии разных
-репозиториев.
-
-### D5 — Ratchet-up в choke-point подтверждённого merge (FR-4, BR-3)
-
-Базовая линия наращивается **только вверх** и **только при подтверждённом** слиянии в `main`.
-Единственный авторитетный choke-point подтверждённого merge — `_handle_merge_verify` (ребро
-`deploy → done`, ORCH-071/073, доказательство SHA-in-main). Туда добавляется never-raise врезка
-`coverage_gate.ratchet_baseline_on_merge(repo, work_item_id, branch, sha)`, вызываемая **после**
-того как merge подтверждён (`_handle_merge_verify` вернул `False` = confirmed) и **до** перехода
-в `done`:
-
-1. Читает измеренное покрытие смёрженной ветки из артефакта `18-coverage-report.md` (single
-   source of truth — то же значение, что гейт записал на ребре `deploy-staging→deploy`).
-2. **Атомарный compare-and-set:** `UPDATE coverage_baseline SET coverage=?, source_sha=?,
-   updated_at=? WHERE repo=? AND coverage <= ?` (или `INSERT` при отсутствии строки —
-   bootstrap). Условие `coverage <= measured` гарантирует, что базовая линия **никогда не
-   падает** (FR-4), даже при гонке.
-
-**Сериализация (анти-гонка, NFR-5/AC-4):** на этой точке merge-lease ещё **held** (release на
-`done`/rollback, `stage_engine.py:446`), а merge репо сериализован per-repo (ORCH-043). Плюс
-атомарный compare-and-set в SQL — **двойная защита**: даже без lease два параллельных merge не
-понизят и не потеряют значение. Bootstrap — первый merge применимого репо засевает базовую линию
-своим измеренным покрытием.
-
-### D6 — Условность, kill-switch, наблюдаемость (FR-5/FR-7, BR-4/BR-5)
-
-- **Флаги (`config.py`, env `ORCH_COVERAGE_*`):** `coverage_gate_enabled` (bool, kill-switch),
-  `coverage_gate_repos` (CSV; **пусто → только self-hosting** `is_self_hosting_repo`, по образцу
-  `merge_gate`/`security_gate`/`image_freshness`), `coverage_min_percent` (float, абсолютный
-  порог-floor), `coverage_policy` (`absolute|baseline|both`, дефолт `both`), `coverage_epsilon`
-  (float, дефолт малый, напр. `0.5`), `coverage_tool_fail_closed` (bool, дефолт `False`),
-  `coverage_run_timeout_s` (int).
-- **`applies(repo)`** (локальная проверка) выполняется **ПЕРВОЙ**; дорогой прогон измерения —
-  только при `applies==True`. Вне области → no-op `(True, "Coverage gate N/A")` (прецедент
-  `check_staging_status` для не-self, ORCH-035). При `coverage_gate_enabled=False` — гейт инертен,
-  конвейер 1:1 как до ORCH-027 (AC-5).
-- **FR-6 (ошибка инструмента):** `measure_coverage` вернул `None` (инструмент упал/недоступен/
-  метрика не распарсилась) → по умолчанию **fail-open + WARNING** (observability-строка),
-  `coverage_tool_fail_closed=True` → fail-closed (FAIL). Дефолт анти-петля (прецедент
-  ORCH-061/ORCH-022 dep-audit), чтобы инфра-сбой не заклинил автономный конвейер.
-- **FR-7 (наблюдаемость):** артефакт `18-coverage-report.md` (frontmatter `coverage_status:
-  PASS|FAIL` + `measured_coverage`/`baseline`/`floor`/`policy`/`delta`); read-only блок
-  `coverage` в `GET /queue` (`src/main.py`); при FAIL — `send_telegram` с кликабельным номером
-  (`plane_issue_link`/`link_for`), измеренным покрытием, порогом/базовой линией и дельтой.
-
-### D7 — Машинный вердикт и парсинг (§6 ТЗ, AC-9)
-
-Гейт **сам вычисляет** вердикт (как `check_security_gate`) и пишет
-`18-coverage-report.md` с YAML-frontmatter `coverage_status:` (`PASS` | `FAIL`); регистр
-чувствителен, имя фиксируется. Чтение обратно — через единый контракт `src/frontmatter.py`
-(`parse_frontmatter`/`read_frontmatter_value`, ORCH-052c), как все вердикт-парсеры. Артефакт
-несёт **аддитивно** обязательную 6-польную схему 52c, не трогая `coverage_status:`. В `QG_CHECKS`
-добавляется `check_coverage_gate` (тонкая обёртка, делегирующая в leaf); **семантика и состав
-существующих `check_*` / machine-verdict ключей (`verdict:`/`result:`/`deploy_status:`/
-`staging_status:`/`security_status:`) — байт-в-байт прежние** (NFR-5/AC-8).
-
-### D8 — Опциональный override базовой линии (FR-4 / §4 API)
-
-Для легитимного разового снижения покрытия (напр. удаление большого протестированного модуля)
-вводится опциональный ручной эндпоинт `POST /coverage/baseline?repo=<repo>&value=<float>` (по
-образцу `POST /serial-gate/unfreeze`) — устанавливает/сбрасывает базовую линию вручную.
-Альтернатива без эндпоинта — временно переключить `coverage_policy=absolute`. Эндпоинт
-рекомендован для эксплуатационной гибкости, но не критичен для v1.
-
-## Альтернативы
-
-- **Точка измерения — CI-job (`check_ci_green`, FR-3c).** Пороги/политика/базовая линия/артефакт
-  плохо выражаются статусом коммита; ratchet требует записи в общую БД, недоступную из CI-раннера
-  чисто. Коуплинг с раннером. Отклонено для v1 (точка расширения), как у security-гейта.
-- **Точка измерения — `testing → deploy-staging` (рядом с `check_tests_passed`, FR-3b).** Ветка
-  ещё не догнана на свежий `main` → измеренное покрытие может не соответствовать landed-коду;
-  откат отсюда не освобождает merge-lease иначе. Edge `deploy-staging→deploy` после merge-gate —
-  точнее. Отклонено.
-- **Базовая линия в файле репо (`.coverage-baseline.json`).** Git-churn на каждый ratchet,
-  конфликты при параллельных merge, файл — часть измеряемого дерева. Отклонено в пользу
-  аддитивной БД-таблицы (D4).
-- **Складывание измерения в merge-gate re-test (один pytest-прогон).** Снижает дабл-ран, но
-  коуплит coverage-логику с merge_gate; нарушает leaf-изоляцию ТЗ. Отклонено для v1 (возможный
-  follow-up — измерять покрытие в том же прогоне).
-- **Новый stage `coverage`.** «Пустая» стадия без агента не имеет триггера (как в ORCH-043/022).
-  Отклонено.
-- **Жёсткий абсолютный порог без baseline/epsilon.** Массовые ложные заворота → петля rework.
-  Отклонено в пользу консервативного `both` + epsilon (NFR-4).
-
-## Последствия
-
-- **+** Класс «тихо просевшее покрытие» закрыт детерминированной метрикой; защита от монотонной
-  деградации в пакетном автономном прогоне (ORCH-088). Базовая линия может только расти (ratchet).
-- **+** Нулевая регрессия: при выключенном флаге / вне области (enduro-trails) — конвейер
-  байт-в-байт прежний; `STAGE_TRANSITIONS`/`QG_CHECKS`-семантика/вердикт-ключи не тронуты.
-- **+** Self-hosting-безопасно: гейт только мерит/читает/пишет/решает; не деплоит, не рестартит
-  прод, не пушит/форс-пушит в `main` (NFR-3).
-- **−** Дополнительный прогон pytest под coverage на каждой применимой задаче (после merge-gate
-  re-test) → ещё один полный тест-ран. Митигейшн: ограничен `coverage_run_timeout_s`; фейлит до
-  дорогого image-rebuild; follow-up — слияние с merge-gate re-test.
-- **−** Ещё один «скрытый» под-гейт ребра (нет в `STAGE_TRANSITIONS`); новая pip-зависимость
-  (`pytest-cov`); v1 — Python-only (мульти-стек — точка расширения BR-6).
-- **−** Дефолтный fail-open означает, что устойчивый сбой инструмента **тихо** пропускает задачи
-  (с WARNING). Митигейшн: громкий лог + переключатель `coverage_tool_fail_closed`.
-- **Сквозное изменение** (новый QG + edge-под-гейт + новая БД-таблица + новый артефакт) →
-  лейбл `arch:major-change`; прод-деплой ORCH-027 — строго через staging-гейт (8501), без
-  рестарта прод-контейнера.
-- **Откат:** `coverage_gate_enabled=False` → полный no-op (мгновенный обратимый kill-switch).
-  Полное удаление — снять врезки `_handle_coverage_gate`/`ratchet_baseline_on_merge`, удалить
-  leaf-модуль, `check_coverage_gate` из `QG_CHECKS`, флаги, артефакт-шаблон; таблица
-  `coverage_baseline` аддитивна и может остаться (инертна).
-
-## Ссылки
-
-- BRD: `docs/work-items/ORCH-027/01-brd.md`
-- TRZ: `docs/work-items/ORCH-027/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-027/03-acceptance-criteria.md`
-- Data: `docs/work-items/ORCH-027/08-data-requirements.md`
-- Risks: `docs/work-items/ORCH-027/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0029-coverage-gate.md`
-- Сверено по коду: `src/stage_engine.py` (`_handle_security_gate`/`_handle_merge_gate`/
-  `_handle_image_freshness`/`_handle_merge_verify`), `src/security_gate.py`, `src/merge_gate.py`,
-  `src/qg/checks.py`, `.gitea/workflows/ci.yml`, `pytest.ini`
-- Прецеденты: adr-0012 (security-гейт), adr-0006 (merge-gate — edge-под-гейт/откат/lease),
-  adr-0008 (image-freshness — условность/fail-closed), adr-0003 (`is_self_hosting_repo`),
-  adr-0009 (анти-петля ложных FAIL), adr-0014 (SHA-in-main как source of truth для merge)

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

@@ -1,64 +0,0 @@
----
-work_item: ORCH-027
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфраструктурные требования: ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable. Топология **не меняется** (всё в существующем Docker-контейнере на одном
-> сервере mva154, SQLite, собственная очередь). Затрагивается только зависимостный и
-> конфигурационный слой.
-
-## Топология / окружение
-
-- **Без изменений топологии** — никаких новых контейнеров/сервисов/нод. Гейт исполняется внутри
-  существующего процесса оркестратора, измерение — в per-branch worktree (`ensure_worktree`),
-  как merge-gate re-test. `docs/operations/INFRA.md` — без правок.
-- **Self-hosting безопасность (NFR-3):** гейт не вызывает деплой-хук, не рестартит прод-контейнер
-  `orchestrator` (8500), не пушит в `main`. Прод-деплой ORCH-027 — **только** через
-  staging-гейт (8501) → выделенный статус «Confirm Deploy» (ORCH-059), без рестарта прод
-  случайным approve.
-
-## Зависимости
-
-| Зависимость | Где | Назначение |
-|-------------|-----|-----------|
-| `pytest-cov` (обёртка `coverage.py`) | `requirements.txt` | измерение line coverage прогоном `pytest --cov=src --cov-report=json`. Offline (сеть при измерении не нужна). Попадает в прод-образ при пересборке. |
-
-- Версия фиксируется совместимой с текущим `pytest` (см. `requirements.txt`/`pytest.ini`).
-- Новых системных пакетов в `Dockerfile` не требуется (чистый pip-пакет).
-
-## Конфигурация (env, `.env` на хосте)
-
-Новые флаги (`config.py`, префикс `ORCH_COVERAGE_*`; дефолты безопасны — нулевая регрессия):
-
-| Env | Дефолт | Назначение |
-|-----|--------|-----------|
-| `ORCH_COVERAGE_GATE_ENABLED` | `false` (раскат поэтапный) | kill-switch |
-| `ORCH_COVERAGE_GATE_REPOS` | пусто → только self-hosting | CSV область применения |
-| `ORCH_COVERAGE_MIN_PERCENT` | консервативно (напр. backstop) | абсолютный порог-floor |
-| `ORCH_COVERAGE_POLICY` | `both` | `absolute\|baseline\|both` |
-| `ORCH_COVERAGE_EPSILON` | малый (напр. `0.5`) | допуск на шум измерения |
-| `ORCH_COVERAGE_TOOL_FAIL_CLOSED` | `false` | поведение при сбое инструмента |
-| `ORCH_COVERAGE_RUN_TIMEOUT_S` | по образцу `merge_retest_timeout_s` | тайм-аут прогона |
-
-## Эксплуатационные предусловия
-
-- **Bootstrap базовой линии:** при первом merge применимого репо базовая линия `main`
-  засевается автоматически фактическим измеренным покрытием (D5). Ручной первичный замер не
-  обязателен; при необходимости — `POST /coverage/baseline?repo=orchestrator&value=<%>` (D8).
-- **Раскат:** включать `ORCH_COVERAGE_GATE_ENABLED=true` только после прод-деплоя кода и
-  прогона на staging (8501); стартовая область — только `orchestrator`.
-- **Override (легитимное снижение покрытия):** `POST /coverage/baseline` (по образцу
-  `POST /serial-gate/unfreeze`) либо временный `ORCH_COVERAGE_POLICY=absolute`.
-
-## Секреты / сеть
-
-- Новых секретов нет. Сетевого доступа при измерении нет (coverage offline).
-- enduro-trails и прочие репозитории — вне области по умолчанию, нулевое влияние.

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

@@ -1,67 +0,0 @@
----
-work_item: ORCH-027
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable / информационный (гейтом не парсится). Затрагивается схема БД — вводится
-> **одна аддитивная таблица** базовой линии покрытия. Существующие таблицы не мигрируются.
-
-## Изменения схемы БД
-
-Новая аддитивная таблица `coverage_baseline` (паттерн `repo_freeze`/`job_deps` —
-`CREATE TABLE IF NOT EXISTS` в `init_db`, `src/db.py`; без `ALTER`/миграции существующих):
-
-```sql
-CREATE TABLE IF NOT EXISTS coverage_baseline (
-    repo        TEXT PRIMARY KEY,   -- репозиторий (напр. "orchestrator")
-    coverage    REAL NOT NULL,      -- last-known базовая линия покрытия main (%, line coverage)
-    source_sha  TEXT,               -- SHA main, на котором зафиксирована базовая линия (аудит)
-    updated_at  TEXT NOT NULL       -- ISO-таймстамп последнего ratchet/bootstrap
-);
-```
-
-Доступ — через аддитивные read-only/мутирующие хелперы `src/db.py`:
-- `get_coverage_baseline(repo) -> float | None` (None ⇒ bootstrap-режим, базовой линии ещё нет);
-- `ratchet_coverage_baseline(repo, coverage, sha) -> bool` — **атомарный compare-and-set**:
-  `INSERT` при отсутствии строки; иначе `UPDATE ... SET coverage=?, source_sha=?, updated_at=?
-  WHERE repo=? AND coverage <= ?` (базовая линия **никогда не понижается**);
-- `set_coverage_baseline(repo, coverage, sha)` — безусловная установка (ручной override D8 /
-  `POST /coverage/baseline`).
-
-## Новые/изменённые сущности
-
-- **`coverage_baseline`** — одна строка на репозиторий; keyed by `repo`. Инвариант: `coverage`
-  монотонно не убывает через `ratchet_coverage_baseline` (только `set_coverage_baseline`/ручной
-  override может понизить — легитимный разовый случай, D8). На общей прод-БД (self-hosting)
-  строки разных репозиториев изолированы первичным ключом.
-- **Артефакт `18-coverage-report.md`** — НЕ БД-сущность: файл в `docs/work-items/<id>/`,
-  несёт frontmatter `coverage_status: PASS|FAIL` + `measured_coverage`/`baseline`/`floor`/
-  `policy`/`delta`. Source of truth измеренного значения для ratchet (D5).
-
-Существующие таблицы (`tasks`, `jobs`, `job_deps`, `repo_freeze`, `agent_runs`,
-`tracker_messages`, …) — **не изменяются** (NFR-5/AC-8).
-
-## Совместимость данных / миграции
-
-- **Аддитивность:** только `CREATE TABLE IF NOT EXISTS` — ни один существующий столбец/таблица
-  не трогается; миграции существующих данных нет.
-- **Идемпотентность:** `CREATE TABLE IF NOT EXISTS` безопасен при повторном старте; bootstrap
-  (первый `INSERT`) выполняется один раз на репозиторий.
-- **Restart-safe:** базовая линия персистентна; in-flight измерение при рестарте переигрывается
-  штатным механизмом стадии (idempotent — гейт пересчитает вердикт, ratchet — атомарный
-  compare-and-set, повтор не понизит и не задвоит).
-- **Атомарность / анти-гонка:** ratchet — единичный SQL `UPDATE ... WHERE coverage <= ?` (или
-  `INSERT`), выполняется под held merge-lease (ORCH-043, per-repo сериализация merge) → двойная
-  защита от параллельных слияний.
-- **Влияние на общую прод-БД:** одна маленькая таблица (≤ числа репозиториев строк); нулевой
-  риск для enduro-trails и прочих проектов (строки изолированы по `repo`, гейт для них no-op).
-- При `coverage_gate_enabled=False` таблица может существовать пустой/инертной — нулевая
-  регрессия.

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

@@ -1,42 +0,0 @@
----
-work_item: ORCH-027
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Флап на шуме измерения** — недетерминированное покрытие (порядок тестов/окружение) дрожит у границы → ложные заворота, петля rework. | Сред. | Сред. | `coverage_epsilon` (NFR-4/D3): дрожание ±доли % не заворачивает. Дефолт `policy=both` мягкий; абсолютный порог — backstop, не агрессивный. |
-| TR-2 | **Не освобождён merge-lease при FAIL.** Coverage идёт ПОСЛЕ merge-gate (lease уже held) — забытый release при откате заклинит serial-gate репо (другие задачи репо в defer навсегда). | Сред. | Выс. | Явный инвариант D1: rollback coverage вызывает `merge_gate.release_merge_lease` (как image-freshness rollback, `stage_engine.py:1165`); покрыто тестом TC-13. Backstop — crash-реклейм lease по возрасту (ORCH-043). |
-| TR-3 | **Гонка базовой линии** — два параллельных слияния в `main` конкурентно обновляют baseline, теряя/занижая значение. | Низ. | Сред. | Атомарный SQL compare-and-set `UPDATE ... WHERE coverage <= ?` (D5/08-data) + held merge-lease + per-repo сериализация merge (ORCH-043) → тройная защита. Покрыто TC-05. |
-| TR-4 | **Инфра-хрупкость инструмента** — `pytest-cov` несовместим с версией pytest / упал / метрика не парсится → конвейер клинит. | Низ. | Сред. | NFR-2/FR-6/D6: дефолт fail-open + громкий WARNING (анти-петля ORCH-061); `coverage_tool_fail_closed` для строгого режима. `measure_coverage`→`None` обрабатывается, не всплывает. Покрыто TC-09. |
-| TR-5 | **Исключение всплывает в `advance_stage`** — ошибка leaf-модуля роняет конвейер ВСЕХ проектов (общий прод-инстанс). | Низ. | Выс. | NFR-1/AC-7: `src/coverage_gate.py` — leaf (не импортирует `stage_engine`), контракт never-raise; любое исключение → `(False/True, reason)` по политике fail-open/closed. Покрыто TC-10. |
-| TR-6 | **Дабл-ран pytest** — coverage-прогон после merge-gate re-test удваивает время тестов на применимой задаче. | Выс. | Низ. | Ограничен `coverage_run_timeout_s`; фейлит ДО дорогого image-rebuild; follow-up — слияние измерения с merge-gate re-test (вне объёма v1). Влияет только на self-hosting `orchestrator`. |
-| TR-7 | **Стартовая петля заворотов** — высокий `coverage_min_percent` массово заворачивает существующие задачи в rework. | Сред. | Сред. | NFR-4/D3: bootstrap инициализирует baseline фактическим покрытием `main`; absolute-порог — мягкий backstop; cap `MAX_DEVELOPER_RETRIES` → Blocked+alert вместо бесконечной петли. |
-| TR-8 | **Self-hosting побочка** — гейт случайно трогает прод-контейнер/`main`/force-push. | Низ. | Выс. | NFR-3/AC-7: гейт только мерит/читает/пишет/решает в изолированном worktree; не вызывает деплой-хук, не рестартит прод, не пушит в `main`. Покрыто TC-12. |
-| TR-9 | **Регресс контрактов** — затронуты `STAGE_TRANSITIONS`/существующие `check_*`/вердикт-ключи. | Низ. | Выс. | NFR-5/AC-8: новый QG аддитивен, edge-врезка не меняет `STAGE_TRANSITIONS`; вердикт-ключи прежних доков байт-в-байт. Покрыто TC-15. |
-
-## Сводный вывод
-
-Доминирующий класс рисков — **эксплуатация автономного self-hosting-конвейера**: самые
-тяжёлые по влиянию (TR-2 заклинивание serial-gate, TR-5 падение конвейера всех проектов, TR-8
-побочка на прод) имеют **низкую вероятность** и закрыты структурными инвариантами, повторяющими
-проверенные паттерны соседних под-гейтов (security/merge/image-freshness): leaf never-raise,
-fail-open дефолт, явный release merge-lease при откате, kill-switch. Остаточный риск для
-прод-конвейера — **низкий** при условии тестового покрытия инвариантов TR-2/TR-5/TR-8
-(`04-test-plan.yaml` TC-09…TC-13) и поэтапного раската через staging-гейт (8501).
-
-Решение **сквозное** (новый QG + edge-под-гейт + новая БД-таблица + новый артефакт) → эскалация
-лейблом **`arch:major-change`**. Возврат в анализ не требуется — ТЗ реализуемо без нарушения
-принципов архитектуры (Docker/один сервер/SQLite/собственная очередь сохранены).

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

@@ -1,121 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-027
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-027
-version: 2
----
-
-# Review ORCH-027 — Code coverage как гейт
-
-## Summary
-
-Дисциплинированная реализация детерминированного coverage-гейта строго по образцу
-security/merge/image-freshness под-гейтов. Соответствие ТЗ/ADR — полное; код качественный,
-тесты содержательны (`test_coverage_gate.py` — 30 тестов; **полный регресс `tests/ -q`
-зелёный: 1466 passed**); документация обновлена исчерпывающе.
-
-**Единственный прежний блокер закрыт.** Ревизия v1 выносила P1 за повреждённую (дословно
-продублированную) запись ORCH-095 в `CHANGELOG.md` — коммит `75c33ab docs(changelog): repair
-duplicated ORCH-095 entry body` устранил дубль: тело bullet ORCH-095 теперь присутствует ровно
-один раз (`git revert occurrences on line 16: 1`), артефакт чужой задачи восстановлен. Новых
-P0/P1 не выявлено.
-
-Проверено: 4 оси (ТЗ / ADR / качество кода / документация) + трассировка маркеров + полный
-прогон тест-сьюта.
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет) — прежний P1 (дубль записи ORCH-095 в CHANGELOG) исправлен коммитом `75c33ab`.
-
-### P2 — Should fix
-- [ ] **Несоответствие формулировки ADR-001 D7 фактическому артефакту: 6-польная схема 52c
-  не эмитится.** `ADR-001-coverage-gate.md` D7 утверждает: «Артефакт несёт **аддитивно**
-  обязательную 6-польную схему 52c, не трогая `coverage_status:`». Фактически и генератор
-  (`coverage_gate.render_coverage_report`), и скелет `docs/_templates/18-coverage-report.md`
-  эмитят только `coverage_status`/`work_item` + coverage-поля; отсутствуют 5 из 6 полей схемы
-  52c (`stage`/`author_agent`/`status`/`created_at`/`model_used`). **Почему не блокер:** (а)
-  TRZ §6 формулирует это условно («*Если* отчёт несёт обязательную 6-польную схему 52c —
-  добавить её аддитивно»), (б) валидация схемы warning-only по умолчанию
-  (`frontmatter_validation_strict=False`), (в) гейт-генерируемые артефакты (прецедент
-  `17-security-report.md`) исторически несут лишь свой machine-key — эпик 52c (ORCH-077)
-  скоупил схему на 6 агент-промптов, не на машинные отчёты. Машинный вердикт читается из
-  `coverage_status:` корректно, контракт не нарушен. **Действие (на усмотрение, не блокирует
-  приёмку):** привести формулировку D7 к факту (отчёт несёт `coverage_status:` + coverage-поля,
-  без полной 52c-схемы) ЛИБО добавить 5 полей в генератор+шаблон.
-
-## Документация
-
-**Статус: обновлена исчерпывающе** (golden source синхронизирован в том же PR, AC-10 PASS):
-
-- `docs/architecture/README.md` — реестр `QG_CHECKS` дополнен `check_coverage_gate (ORCH-027)`;
-  добавлен раздел «Coverage-гейт: защита от деградации покрытия» (точка/порядок, измерение,
-  чистая функция, baseline+ratchet, условность/fail-open, артефакт/наблюдаемость). ✅
-- `docs/_standards/PIPELINE_DOCS.md` — диапазон доков `…18-coverage-report.md`; строка карты
-  `стадия→агент→документ→гейт→machine-key` + строка таблицы вердикт-парсеров
-  (`coverage_status:` → `check_coverage_gate`). ✅
-- `docs/_templates/18-coverage-report.md` — скелет с frontmatter зарегистрирован. ✅
-- `docs/work-items/ORCH-027/06-adr/ADR-001-coverage-gate.md` (D1…D8) +
-  сквозной `docs/architecture/adr/adr-0029-coverage-gate.md`. ✅
-- `CHANGELOG.md` — детальная корректная запись ORCH-027; повреждение соседней записи ORCH-095
-  устранено (v1-P1 закрыт). ✅
-- `CLAUDE.md` — паспортный блок «Гейт покрытия тестами (ORCH-027)» добавлен. ✅
-- `.env.example` / `src/config.py` — флаги `ORCH_COVERAGE_*` задокументированы. ✅
-- Маркеры `ORCH-027` проставлены в коде/доках (AC-10). ✅
-
-`src/` изменён → документация обновлена в том же PR: **да** (P0-условие выполнено).
-**Обзорные доки (ORCH-079):** PR не закрывает ни один пункт `README.md` «Известные ограничения»
-(coverage-деградация там не значилась) → обновление витрины не требуется, finding отсутствует.
-
-## Оси проверки (детально)
-
-**1. Соответствие ТЗ (02-trz / 03-acceptance) — PASS.**
-AC-1 измерение инструментально (`measure_coverage` → `pytest --cov=src` → `totals.percent_covered`,
-`pytest-cov==5.0.0` в `requirements.txt`); AC-2 блокировка деградации + откат на `development` с
-release merge-lease (`_handle_coverage_gate`); AC-3 чистая функция `compute_coverage_verdict`
-покрыта по всем режимам/границам/epsilon (TC-01…04); AC-4 ratchet up-only + bootstrap + per-repo
-изоляция + атомарный compare-and-set `UPDATE … WHERE coverage <= ?` (`db.ratchet_coverage_baseline`);
-AC-5 kill-switch/scope + `applies(repo)` ПЕРВЫМ (дорогой прогон только при `applies==True`) —
-регресс зелёный, enduro не затронут; AC-6 fail-open дефолт / fail-closed по флагу; AC-7 never-raise
-+ leaf (не импортирует `stage_engine`) + AST-проверка отсутствия деплой/force-push токенов; AC-8
-контракты `STAGE_TRANSITIONS`/`check_*`/вердикт-ключи байт-в-байт, таблица `coverage_baseline`
-аддитивна; AC-9 вердикт только из frontmatter (`parse_coverage_status` через
-`frontmatter.parse_frontmatter`) + `GET /queue` блок `coverage` + Telegram с кликабельным номером.
-
-**2. Соответствие ADR (ADR-001 D1…D8 / adr-0029) — PASS** (с P2-оговоркой по тексту D7).
-Порядок под-гейтов `security → merge → coverage → image-freshness` реализован ровно как в D1
-(врезка `_handle_coverage_gate` между merge-handling и ORCH-058 freshness в `advance_stage`);
-coverage ПОСЛЕ merge-gate (догнанный HEAD) и `merge_gate.release_merge_lease` при FAIL —
-соответствует D1/TR-2 (зеркало image-freshness rollback, в отличие от security — тот до захвата
-lease). Ratchet в choke-point `_handle_merge_verify` (ребро `deploy→done`, D5), БД-таблица
-`coverage_baseline` (D4), машинный вердикт/парсинг (D7), override `POST /coverage/baseline` (D8).
-Глобальные ADR (INV-4 merge только через Gitea API; не трогать `main`/прод) не нарушены — leaf
-только мерит/читает/пишет/решает.
-
-**3. Качество кода — PASS.**
-Docstrings на всех публичных функциях; never-raise контракт выдержан последовательно (все
-внешние границы обёрнуты, исключение не всплывает в `advance_stage`); единый frontmatter-контракт
-переиспользован (нет дублирования парс-логики); тесты содержательные (режимы/границы/epsilon,
-ratchet up-only + bootstrap + per-repo изоляция, fail-open/closed, never-raise, write/read-back
-отчёта, self-hosting AST-инвариант, интеграция в `advance_stage` с откатом+release lease).
-Фикс `sys.executable` вместо bare `python` (коммит `8cd7c20`) корректен — pytest-cov живёт в
-интерпретаторе орка. Нет утечек/security-дыр; измерение offline. Замечание (не finding):
-синхронный `pytest --cov` в hot-path `advance_stage` (тайм-аут `coverage_run_timeout_s=900`)
-наследует established-паттерн merge-gate re-test/security-gate — нового класса риска не вводит.
-
-**4. Документация — см. раздел «Документация» выше (P0-условие выполнено; обзорные доки N/A).**
-
-**Трассировка маркеров (TRACEABILITY).** Правки рядом с маркерами `ORCH-022`/`ORCH-043`/`ORCH-058`
-в `advance_stage` — аддитивная врезка между merge-gate и image-freshness; инварианты соседних
-под-гейтов не сломаны (release-lease зеркалит image-freshness rollback, merge через Gitea API
-не тронут). Врезка в `_handle_merge_verify` (ORCH-071/073) — never-raise best-effort ratchet,
-SHA-in-main choke-point не изменён. Чужие артефакты не повреждены (восстановлена запись ORCH-095).

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

@@ -1,76 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-027
-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-027
----
-
-# Test Report — ORCH-027 — Code coverage как гейт
-
-Work Item: **ORCH-027** · Repo: **orchestrator** · Branch: **feature/ORCH-027-code-coverage** · Стадия: testing
-Предусловие: `12-review.md` → `verdict: APPROVED` ✅ (проверено).
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-027-code-coverage` (HEAD `619fd0c`)
-- Дата: 2026-06-10
-
-## Smoke API (read-only)
-| Endpoint | Результат |
-|----------|-----------|
-| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS — активные задачи отдаются, ORCH-027 в `testing` |
-| `GET /queue` | PASS — блоки `serial_gate` (ORCH-088) **и** `auto_labels` присутствуют в payload; добавлен read-only блок `coverage`-наблюдаемости по ТЗ FR-7 (через общий снапшот) |
-
-`serial_gate.per_repo.orchestrator.active_task = ORCH-027 (testing)` — гейт сериализации виден, регресса смока нет.
-
-## Результаты — покрытие ТЗ (каждый TC из 04-test-plan.yaml ↔ AC из 03-acceptance-criteria.md)
-
-| TC ID | Тип | Описание | Тест-функция(и) | AC | Результат |
-|-------|-----|----------|-----------------|----|-----------|
-| TC-01 | unit | `compute_coverage_verdict` policy=absolute (порог/ниже/ровно) | `test_tc01_policy_absolute` | AC-3 | PASS |
-| TC-02 | unit | policy=baseline (no-regression / ratchet) | `test_tc02_policy_baseline` | AC-3/AC-4 | PASS |
-| TC-03 | unit | policy=both — оба условия | `test_tc03_policy_both` | AC-3 | PASS |
-| TC-04 | unit | epsilon-допуск (анти-флап, NFR-4) | `test_tc04_epsilon_tolerance` | AC-3 | PASS |
-| TC-05 | unit | Ratchet базовой линии up-only + per-repo изоляция | `test_tc05_ratchet_up_only`, `test_tc05_ratchet_per_repo_isolated` | AC-4 | PASS |
-| TC-06 | unit | Bootstrap baseline при отсутствии значения | `test_tc06_bootstrap` | AC-4 | PASS |
-| TC-07 | unit | `applies(repo)`: пустой CSV → self-hosting only; вне области → no-op без прогона | `test_tc07_applies_self_hosting_only`, `test_tc07_applies_csv_scope`, `test_tc07_out_of_scope_noop_no_measure` | AC-5 | PASS |
-| TC-08 | unit | Kill-switch `coverage_gate_enabled=False` → инертен (1:1 до ORCH-027) | `test_tc08_kill_switch_off` | AC-5 | PASS |
-| TC-09 | unit | Fail-open дефолт + fail-closed по флагу | `test_tc09_fail_open_default`, `test_tc09_fail_closed_when_configured` | AC-6 | PASS |
-| TC-10 | unit | never-raise: битый вывод/отсутствие worktree не всплывает | `test_tc10_verdict_never_raises_on_bad_inputs`, `test_tc10_parse_coverage_percent_tolerant`, `test_tc10_check_never_raises`, `test_tc10_ratchet_never_raises_on_missing_report` | AC-7 | PASS |
-| TC-11 | unit | write/read-back отчёта `coverage_status:` через `src/frontmatter.py` | `test_tc11_report_roundtrip`, `test_tc11_parse_missing_frontmatter`, `test_tc11_bootstrap_report_blank_baseline` | AC-9 | PASS |
-| TC-12 | unit | Self-hosting безопасность: leaf без engine-импорта; нет деплой/force-push | `test_tc12_leaf_no_engine_import`, `test_tc12_delta_signed` | AC-7 | PASS |
-| TC-13 | integration | Гейт в конвейере: FAIL → откат на development; PASS → штатное продвижение | `test_tc13_advance_rolls_back_on_fail`, `test_tc13_advance_passes_through_on_ok` | AC-2 | PASS |
-| TC-14 | integration | Реальное измерение pytest под coverage в worktree + тайм-аут | `test_tc14_real_measurement`, `test_tc14_measure_timeout_returns_none` | AC-1 | PASS |
-| TC-15 | integration | Наблюдаемость `GET /queue` блок coverage + контракты не изменены | `test_tc15_snapshot_shape`, `test_tc15_snapshot_never_raises`, `test_tc15_registry_and_transitions_unchanged` | AC-8/AC-9 | PASS |
-
-**Итог покрытия ТЗ:** все 15 TC выполнены и сопоставлены с AC-1…AC-10; ни одного непокрытого/пропущенного TC.
-
-## Вывод pytest
-
-### Целевой набор — `tests/test_coverage_gate.py`
-```
-collected 29 items
-tests/test_coverage_gate.py::test_tc01_policy_absolute PASSED
-... (29 тестов, TC-01…TC-15) ...
-tests/test_coverage_gate.py::test_tc15_registry_and_transitions_unchanged PASSED
-======================== 29 passed, 1 warning in 2.28s =========================
-```
-
-### Полный регресс — `pytest tests/ -q`
-```
-1466 passed, 1 warning in 48.89s
-```
-(Единственное предупреждение — PydanticDeprecatedSince20 в `src/config.py:8`, не связано с ORCH-027, регрессом не является.)
-
-## Итог
-**PASS** — целевой набор coverage-гейта зелёный (29/29), полный регресс зелёный (1466/1466,
-нулевая регрессия для enduro-trails), smoke API read-only OK (`serial_gate` + `auto_labels`
-присутствуют). Каждый TC из `04-test-plan.yaml` выполнен и сопоставлен с критериями приёмки.
-Задача готова к продвижению на `deploy-staging`.

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

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

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

@@ -1,32 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-027
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-timestamp: 2026-06-09T22:25:00Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live `orchestrator-staging` stand (8501), run canonically
-inside the container (`docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py
---base-url http://localhost:8501 --mode stub`). **Exit code 0 → SUCCESS.** All REAL pipeline checks
-passed; the only failures are the two known waived sandbox-infra checks (C9a/C9b), tolerated under
-ORCH-061 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
-
-## Results
-- **Block A (SMOKE)**: PASS — A1 `/health` 200 ok; A2 `/queue` 200 with counts/max_concurrency/resilience; A3 `ORCH_STAGING=true` (not prod).
-- **Block B (ACCESS)**: PASS — B4 Plane sandbox project accessible (sandbox=YES); B5 Gitea `orchestrator-sandbox` accessible push=true; B6 Registry isolation (sandbox present, prod ET/ORCH absent).
-- **Block C (E2E, mode=stub)**: C7 create issue in Plane SANDBOX PASS; C8 trigger pipeline via `/webhook/plane` PASS; C9a/C9b FAIL — **waived sandbox-infra** (SANDBOX bot-accounts not members of the sandbox Plane project; not a pipeline regression).
-
-REAL failed: none.
-SANDBOX_INFRA failed (waived): C9a Branch appears in orchestrator-sandbox; C9b Analyst job enqueued in staging queue.
-
-Result: 8/10 checks PASS, exit 0. Tolerance `staging_infra_tolerance_enabled=True`. Cleanup OK (Plane test issue deleted, HTTP 204; no branch created to delete).

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

@@ -1,7 +0,0 @@
-# Business Request: BUG/follow-up ORCH-040: normalize legacy root-owned файлы при миграции на uid 1000 (one-time + защита)
-
-Work Item ID: ORCH-057
-
-## Description
-
-TBD

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

@@ -1,140 +0,0 @@
----
-work_item: ORCH-057
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000 (one-time + защита)
-
-Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-ORCH-040 перевёл оба контейнера (`orchestrator` 8500, `orchestrator-staging` 8501) с root
-на `user: "1000:1000"` (slin). Изменён был **только** `docker-compose.yml`. Однако bind-mount
-`/home/slin/repos → /repos` уже содержал файлы и каталоги, созданные **прежним root-контейнером**
-(`root:root`). Смена `user:` владельца существующих файлов НЕ меняет.
-
-**Реальный инцидент (прод, 06.06, поймали на первом запуске ORCH-043).** Первый job под uid 1000
-упал на стадии **launch** (НЕ на коде задачи):
-
-```
-fatal: could not create leading directories of
-'/repos/_wt/orchestrator/feature_ORCH-043-.../.git': Permission denied
-```
-
-Причина: `/repos/_wt/` и старые worktree-папки = `root:root` → uid 1000 не может создать рядом
-новый каталог worktree. Установлено фактически: ошибка возникает в `src/git_worktree.py::ensure_worktree`
-(вызов `git worktree add`), куда конвейер приходит из `src/agents/launcher.py::_spawn` (стр. 500)
-и `_materialize_deferred_branch` (ORCH-088). Агент даже не стартует — падает создание worktree.
-
-**Ручной workaround (применён Стрим, прод снова рабочий, ОДНОРАЗОВО):**
-```
-sudo chown -R 1000:1000 /home/slin/repos/_wt
-sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git /home/slin/repos/enduro-trails/.git
-sudo chown -R 1000:1000 /home/slin/repos/orchestrator   # +data/runs/*.log (37 root-логов)
-```
-
-ADR-001 ORCH-040 упоминал «массовый chown старых root-файлов» лишь абстрактно («вне объёма кода»,
-«разовая операция Owner») и НЕ дал конкретной процедуры чистки legacy worktree — поэтому deployer
-её не выполнил, и баг проявился в проде. Прод сейчас рабочий (ручной фикс наложен), но проблема
-**воспроизведётся** на чистой среде, новом репо или после любого исторического запуска под root,
-если её не закрыть кодом + процедурой.
-
-**Это follow-up / закрытие недоделанного AC ORCH-040** (legacy-файлы), а не новая фича.
-
-## 2. Объём (scope)
-
-### В объёме
-- **Защита launcher (код):** при `Permission denied` на создании worktree выдавать **внятную,
-  диагностируемую** ошибку «legacy root-файлы в `/repos/_wt` — требуется нормализация прав»
-  с указанием команды, а НЕ сырой `git fatal`.
-- **Раннее обнаружение (код):** детектирование наличия файлов с `uid != <target_uid>` в
-  `ORCH_REPOS_DIR` (включая `_wt`, `.git/objects`, `.git/worktrees`, `data/runs`) при старте
-  контейнера / перед претензией на job — чтобы конвейер падал **внятно и заранее**, а не сырым
-  git-фаталом на launch.
-- **Процедура нормализации (документация):** в `docs/operations/INFRA.md` (и собственный ADR
-  ORCH-057) — обязательная одноразовая процедура нормализации legacy root-файлов при миграции uid,
-  с точными командами и областью охвата (`_wt`, `.git`, `data/runs`).
-- **Опционально (по решению архитектора):** механизм one-time нормализации при буте/деплое —
-  init-контейнер/хук под root, либо blocking-entrypoint-проверка.
-
-### Вне объёма
-- Изменение логики конвейера, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, схемы БД.
-- Пересмотр самого решения ORCH-040 (uid 1000) — оно принято и остаётся.
-- Перенос инстанса на другой хост / другой uid (отдельная задача при миграции хоста).
-- Массовая ретроактивная переработка ADR-001 ORCH-040 (его история не переписывается;
-  допускается forward-breadcrumb-ссылка на ORCH-057 — решает архитектор).
-- Выбор конкретного варианта реализации one-time нормализации (a/b/в) — зона архитектора (06-adr).
-
-## 3. Заинтересованные стороны
-
-- **Заказчик / Owner** — Слава (homenet542), инициатор; принимает результат.
-- **Эксплуатация** — Стрим (применял ручной workaround); потребитель процедуры в INFRA.md.
-- **Затронутые проекты** — `orchestrator` (self-hosting) и `enduro-trails` (общий инстанс, общая
-  очередь, общий bind-mount `/repos`): нормализация прав `/repos` касается обоих репо.
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1** — После миграции контейнера на новый uid конвейер запускается **без ручного `chown`**:
-  либо авто-нормализация прав, либо **явная блокирующая ошибка с инструкцией** (никогда не сырой
-  `git fatal` на launch).
-- **BR-2** — На свежей среде / новом репо / после исторического запуска под root проблема
-  **не воспроизводится** (детект + понятная диагностика срабатывают до падения агента).
-- **BR-3** — `INFRA.md` и ADR содержат **конкретную процедуру** нормализации legacy root-файлов
-  (точные команды, область: `_wt`, `.git/objects`, `.git/worktrees`, `data/runs`), помеченную как
-  обязательный шаг миграции uid.
-- **BR-4** — Несоответствие владельца наблюдаемо: оператор узнаёт о проблеме из лога/уведомления/
-  read-only статуса, а не по падению задачи на launch.
-- **BR-5** — Защита `ensure_worktree` распознаёт класс ошибки «нет прав на создание worktree» и
-  сообщает причину + лечащую команду (опц. — авто-самолечение, если процесс имеет права).
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 (self-hosting безопасность)** — Решение **никогда** не перезапускает/не роняет
-  прод-контейнер `orchestrator`, не трогает `main`/force-push/прод-образ. Контейнер бежит под
-  uid 1000 (без root) → код **не может** делать `chown` без root; код ограничивается
-  детектом + внятной диагностикой/блокировкой, а фактический `chown` — операторская/init-процедура.
-- **NFR-2 (общий инстанс)** — Нулевая регрессия для `enduro-trails`: feature под kill-switch и
-  scope-флагом (по образцу `serial_gate`/`coverage_gate`); выключено → поведение 1:1 как до ORCH-057.
-- **NFR-3 (never-raise / fail-safe)** — Детект-леаф никогда не бросает наружу неожиданное исключение
-  и не блокирует старт сервиса по своей ошибке; деградирует в WARNING.
-- **NFR-4 (идемпотентность)** — Повторный запуск детекта/нормализации на уже корректной среде —
-  no-op без побочных эффектов.
-- **NFR-5 (обратимость)** — Поведение откатывается выключением kill-switch без миграций/правки схемы.
-- **NFR-6 (наблюдаемость)** — Вердикт (есть/нет mismatch, сколько файлов, какие корни) логируется
-  структурно; при проблеме — Telegram с кликабельным номером задачи (если применимо) + read-only
-  отражение в `GET /queue`.
-
-## 6. Допущения и ограничения
-
-- Целевой uid:gid рантайма = `1000:1000` (slin), подтверждён ORCH-040 (P-3); на хосте `/repos`,
-  `/app/data` штатно `1000:1000`.
-- Контейнер бежит под numeric uid 1000 без записи в `/etc/passwd` базового образа; в образе создан
-  реальный user `slin` (uid 1000) для `getpwuid()` (ORCH-058, Dockerfile). Под uid 1000 `chown`
-  чужих (root) файлов **невозможен** без CAP_CHOWN/root.
-- `git config --system --add safe.directory '*'` уже в образе — git доверяет bind-mount.
-- Корни проверки: `ORCH_REPOS_DIR` (`/repos`), включая `_wt`, `<repo>/.git/objects`,
-  `<repo>/.git/worktrees`, и `data/runs` (37 root-логов в инциденте).
-- `start_pipeline` (ORCH-088) отложил срез ветки на момент claim analyst-job → детект уместен
-  и на старте сервиса, и перед claim'ом (точку выбирает архитектор).
-
-## 7. Критерии успеха
-
-После миграции uid (или на чистой среде) первый же job проходит launch без ручного `chown`, либо —
-если права не нормализованы — конвейер выдаёт **понятную блокирующую диагностику** с командой
-исправления вместо сырого `git fatal`. INFRA.md/ADR содержат воспроизводимую процедуру.
-Для `enduro-trails` — нулевая регрессия. Детальные PASS/FAIL — в `03-acceptance-criteria.md`.
-
-## 8. Риски
-
-- Контейнер без root не может `chown` → авто-самолечение возможно только частично/при наличии прав;
-  основной гарант — детект+диагностика+процедура (детали — `10-tech-risks.md`, архитектор).
-- Рекурсивный обход больших `.git/objects` / `_wt` может быть дорог → нужен дешёвый/семплированный
-  детект и кэш (как preflight TTL).
-- Ложно-блокирующая ошибка может застопорить и enduro-trails (общий `/repos`) → строгий scope/fail-safe.
-- Правка `docker-compose.yml`/entrypoint (init-контейнер) = деплой self → групповой риск (NFR-1),
-  обязательная страховка staging.

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

@@ -1,117 +0,0 @@
----
-work_item: ORCH-057
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
-
-Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование/выбор варианта one-time нормализации (init-контейнер vs blocking-entrypoint
-> vs ансибл) — задача архитектора (`06-adr/`). Здесь — требования, контракты и ограничения.
-
-## 1. Сводка изменения
-
-Закрыть недоделанный AC ORCH-040 по legacy-файлам. Три слоя:
-1. **Защита launcher** — `ensure_worktree` распознаёт `Permission denied`/git-fatal на создании
-   worktree и поднимает **внятную** ошибку с диагнозом «legacy root-файлы в `/repos/_wt` — нужна
-   нормализация прав» + лечащая команда (опц. авто-самолечение при наличии прав).
-2. **Ранний детект** — новый чистый леаф находит файлы с `uid != target_uid` в `ORCH_REPOS_DIR`
-   (`_wt`, `.git/objects`, `.git/worktrees`, `data/runs`); вызывается на старте сервиса и/или перед
-   claim'ом job; never-raise, config-gated, с наблюдаемостью.
-3. **Процедура** — `INFRA.md` + ADR ORCH-057: точные команды разовой нормализации как обязательный
-   шаг миграции uid. Опционально — one-time нормализация под root через init-механизм (решает архитектор).
-
-Инвариант: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема БД —
-**байт-в-байт прежние**. Изменение аддитивно и обратимо kill-switch'ем.
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `src/git_worktree.py` (`ensure_worktree`, `remove_worktree`) | изменить — классификация `Permission denied`/git-fatal на `git worktree add` / `os.makedirs` → внятный actionable `RuntimeError` (опц. self-heal при правах) |
-| `src/fs_normalize.py` | **создать** — чистый леаф (never-raise): `scan_ownership(roots, target_uid) -> результат`; опц. `normalize(...)` (chown только при наличии прав); хелпер `applies(repo)` + кэш (TTL, как preflight) |
-| `src/config.py` | изменить — добавить флаги (см. §7); без правки существующих значений |
-| `src/main.py` (`lifespan`) | изменить — добавить startup-вызов детекта (best-effort, never-fatal по образцу L-2/lease-reclaim), лог + Telegram при mismatch; read-only блок в `GET /queue` |
-| `src/preflight.py` **или** `src/queue_worker.py` | изменить (на выбор архитектора) — опц. гейт claim'а job при обнаруженном mismatch, чтобы падать внятно ДО launch (по образцу preflight-гейта) |
-| `docker-compose.yml` / `Dockerfile` / `scripts/*entrypoint*` | **кандидат** (решает архитектор) — one-time root-нормализация (init-контейнер/хук) ПЕРЕД стартом app; если выбрано — деплой self, обязательная staging-страховка |
-| `docs/operations/INFRA.md` | изменить — раздел «Миграция uid: обязательная нормализация legacy root-файлов» (команды + область) |
-| `docs/work-items/ORCH-057/06-adr/ADR-001-*.md` | создать (architect) — решение + процедура; опц. forward-breadcrumb из ADR-001 ORCH-040 (без переписывания истории) |
-| `CHANGELOG.md` | изменить — запись о ORCH-057 |
-| `tests/test_*` | создать — см. `04-test-plan.yaml` |
-
-## 3. Функциональные требования
-
-### FR-1 — Внятная ошибка `ensure_worktree` (BR-1, BR-5)
-При неуспехе `git worktree add` / `os.makedirs(os.path.dirname(wt))` по причине отказа доступа
-(`Permission denied`, `could not create leading directories`, `insufficient permission for adding an
-object`) `ensure_worktree` поднимает `RuntimeError` с сообщением, которое: (а) называет корневую
-причину (legacy root-owned файлы в `/repos/_wt` или `.git` после миграции uid ORCH-040); (б) указывает
-лечащую команду (`chown -R <uid>:<gid> …`) или ссылку на процедуру INFRA.md; (в) НЕ является сырым
-git stderr. Прочие (нет-прав-несвязанные) ошибки сохраняют текущий контракт (никакой подмены смысла).
-
-### FR-2 — Детект несоответствия владельца (BR-2, BR-4)
-Леаф `fs_normalize.scan_ownership` обходит корни (`/repos/_wt`, `<repo>/.git/objects`,
-`<repo>/.git/worktrees`, `data/runs`) и возвращает: есть ли файлы с `uid != target_uid`, их число
-(или флаг «≥1»), список затронутых корней. Обход дешёвый/ограниченный (ранний выход при первом
-mismatch для быстрого вердикта; полный подсчёт — опционально/семплировано). Результат кэшируется по
-TTL (по образцу `preflight._cache`). `target_uid` = `os.getuid()` или конфиг (дефолт 1000).
-
-### FR-3 — Реакция на детект (BR-1, BR-4)
-- **Startup (main.lifespan):** вызвать детект best-effort; при mismatch — структурный WARNING +
-  Telegram (если включён) с числом/корнями и лечащей командой. Никогда не падать на старте по
-  ошибке детекта (NFR-3).
-- **Опц. гейт claim'а:** при обнаруженном mismatch и `target_uid` без прав на chown — не претендовать
-  на job (или претендовать и сразу честно фейлить с FR-1-сообщением), чтобы исход был внятным до launch.
-  Конкретную точку (preflight vs queue_worker) выбирает архитектор; требование — «внятно и заранее».
-
-### FR-4 — Опциональная авто-нормализация (BR-1)
-`fs_normalize.normalize` выполняет `chown -R target_uid:target_gid` по корням **только если процесс
-имеет на это право** (CAP_CHOWN/root). Под uid 1000 без прав — no-op + честный лог «нужна операторская
-процедура» (НЕ ошибка). Включается отдельным флагом (`*_AUTO`), по умолчанию — выкл (детект-only).
-Если архитектор выбирает init-контейнер под root — это и есть носитель FR-4 на буте.
-
-### FR-5 — Документированная процедура (BR-3)
-`INFRA.md` получает раздел с точными командами разовой нормализации (`_wt`, оба `.git`, `data/runs`),
-помеченный как **обязательный** шаг миграции uid и часть чеклиста деплоя self. ADR ORCH-057 фиксирует
-решение и ссылается на процедуру; ADR-001 ORCH-040 опц. получает forward-ссылку.
-
-## 4. Изменения API
-
-Нет новых обязательных эндпоинтов. **Опционально** (наблюдаемость, решает архитектор):
-- расширить `GET /queue` read-only блоком `fs_ownership` (`{enabled, target_uid, mismatch, roots, checked_at}`);
-- ручной триггер `POST /fs-normalize/check` (форс-пересчёт детекта) — по образцу `POST /serial-gate/unfreeze`.
-
-## 5. Изменения схемы БД
-
-Нет. Состояние детекта — в памяти (TTL-кэш), как `preflight`. Таблицы/миграции/индексы не вводятся.
-
-## 6. Требования к новым/изменённым QG checks
-
-Нет. Это **не** stage-гейт и **не** под-гейт ребра. `QG_CHECKS` / `check_*` / `STAGE_TRANSITIONS` /
-machine-verdict-ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
-`coverage_status:`) — не трогаются. (В описании баг-репорта «deploy-гейт ORCH-040» — это деплой-хук/
-процедура, а не зарегистрированный QG.)
-
-## 7. Совместимость / регресс
-
-- **Kill-switch** `ORCH_FS_NORMALIZE_ENABLED` (дефолт по решению архитектора; `False` → весь код инертен,
-  поведение 1:1 как до ORCH-057).
-- **Scope** `ORCH_FS_NORMALIZE_REPOS` (CSV; пусто → **self-hosting only**, как `coverage_gate_repos` →
-  enduro-trails не затронут). Локальный `applies(repo)` проверяется ПЕРВЫМ (дешёвый обход только при applies).
-- **Флаги** (рабочие имена, финал — за архитектором): `ORCH_FS_TARGET_UID` (дефолт 1000),
-  `ORCH_FS_NORMALIZE_AUTO` (дефолт `False` — детект-only; `True` → попытка chown при наличии прав),
-  `ORCH_FS_SCAN_ROOTS` (CSV переопределения корней), `ORCH_FS_SCAN_CACHE_TTL_S`.
-- **Never-raise / fail-safe** — ошибка детекта/нормализации деградирует в WARNING, не блокирует старт
-  сервиса по своей вине; FR-1 меняет лишь **формулировку** ошибки worktree, не её факт.
-- **Self-hosting** (NFR-1) — код только читает/детектит/диагностирует (и chown ТОЛЬКО при наличии прав);
-  не деплоит/не рестартит прод/не трогает `main`. Любое касание `docker-compose.yml`/entrypoint требует
-  staging-прогона (8501) перед прод-рестартом в окно тишины.
-- **Обратимость** — выкл kill-switch → прежнее поведение; миграций/правки схемы нет.
-- **Пайплайн-артефакты:** обновляются `01..04` (analysis), `06-adr/`+`07-infra-requirements.md`+`10-tech-risks.md`
-  (architecture), `12/13/15/14` (review/testing/staging/deploy), `INFRA.md`, `CHANGELOG.md`.

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

@@ -1,99 +0,0 @@
----
-work_item: ORCH-057
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-057 — нормализация legacy root-owned файлов
-
-Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория.
-
----
-
-## AC-1 — Конвейер стартует без ручного chown (или внятная блокирующая ошибка)
-
-**Условие:** после миграции контейнера на новый uid первый job не падает сырым git-фаталом на launch.
-- **PASS:** при нормализованных правах worktree создаётся и агент стартует; при НЕнормализованных
-  правах конвейер выдаёт понятную блокирующую ошибку с диагнозом и лечащей командой (НЕ сырой
-  `fatal: could not create leading directories … Permission denied`).
-- **FAIL:** на launch всплывает сырой git-fatal/Permission denied без диагноза причины и инструкции.
-
----
-
-## AC-2 — `ensure_worktree` даёт actionable-ошибку при отказе доступа
-
-**Условие:** `src/git_worktree.py::ensure_worktree` классифицирует ошибки прав.
-- **PASS:** при `Permission denied`/`could not create leading directories`/`insufficient permission`
-  поднимается `RuntimeError`, текст которого называет причину (legacy root-файлы в `/repos/_wt`/`.git`
-  после миграции uid) и указывает команду/ссылку на процедуру; ошибки, не связанные с правами,
-  сохраняют прежний контракт.
-- **FAIL:** сырой git stderr пробрасывается без диагноза; либо подменяется смысл не-прав-ошибок;
-  либо `ensure_worktree` падает необработанно.
-
----
-
-## AC-3 — Детект несоответствия владельца
-
-**Условие:** новый леаф `src/fs_normalize.py` обнаруживает файлы с `uid != target_uid` в корнях
-(`/repos/_wt`, `<repo>/.git/objects`, `<repo>/.git/worktrees`, `data/runs`).
-- **PASS:** на среде с root-файлами `scan_ownership` возвращает mismatch=True + затронутые корни;
-  на чистой (`1000:1000`) среде — mismatch=False (no-op, идемпотентно); леаф never-raise.
-- **FAIL:** mismatch не обнаружен на грязной среде / ложный mismatch на чистой / леаф бросает наружу.
-
----
-
-## AC-4 — Наблюдаемость детекта
-
-**Условие:** результат детекта виден оператору без падения задачи.
-- **PASS:** при mismatch — структурный лог-WARNING (число/корни/лечащая команда) и Telegram (если
-  включён); опц. read-only отражение в `GET /queue`.
-- **FAIL:** mismatch обнаружен, но никак не сообщён; оператор узнаёт о проблеме только по упавшей задаче.
-
----
-
-## AC-5 — Self-hosting безопасность и нулевая регрессия enduro-trails
-
-**Условие:** изменение безопасно для общего инстанса.
-- **PASS:** код не рестартит/не роняет прод, не трогает `main`/force-push/прод-образ; chown — только
-  при наличии прав; при выключенном kill-switch поведение 1:1 как до ORCH-057; при пустом scope-CSV
-  feature активен только для self-hosting (enduro-trails не затронут); регресс `pytest tests/ -q` зелёный.
-- **FAIL:** любой рестарт/деградация прода из кода задачи; ненулевая регрессия enduro-trails;
-  поведение меняется при выключенном флаге; падение всего регресса.
-
----
-
-## AC-6 — Инварианты конвейера сохранены
-
-**Условие:** изменение аддитивно.
-- **PASS:** `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict-ключи и схема БД —
-  байт-в-байт прежние; новые флаги аддитивны и обратимы.
-- **FAIL:** затронут любой exit/под-гейт, изменён machine-key, добавлена миграция схемы.
-
----
-
-## AC-7 — Документированная процедура нормализации
-
-**Условие:** процедура воспроизводима.
-- **PASS:** `INFRA.md` содержит раздел «Миграция uid: обязательная нормализация legacy root-файлов»
-  с точными командами (`_wt`, оба `.git`, `data/runs`) как обязательный шаг миграции; ADR ORCH-057
-  фиксирует решение и ссылается на процедуру.
-- **FAIL:** процедура отсутствует/абстрактна (как было в ORCH-040) либо не покрывает все корни.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1, FR-3 |
-| AC-2 | BR-1, BR-5 / FR-1 |
-| AC-3 | BR-2 / FR-2 |
-| AC-4 | BR-4 / FR-3 |
-| AC-5 | NFR-1, NFR-2, NFR-5 / FR-4 |
-| AC-6 | NFR-5 (инварианты) |
-| AC-7 | BR-3 / FR-5 |

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

@@ -1,92 +0,0 @@
-work_item: ORCH-057
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Нормализация legacy root-owned файлов при миграции на uid 1000 (детект + защита worktree)"
-framework: pytest
-scope: >
-  Покрывается: классификация ошибки прав в ensure_worktree (внятная actionable-ошибка),
-  детект несоответствия владельца (fs_normalize.scan_ownership), идемпотентность на чистой среде,
-  fail-safe/never-raise, scope/kill-switch (self-hosting only при пустом CSV), опц. self-heal-noop
-  без прав. ВНЕ покрытия: реальный chown под root (требует привилегий — проверяется на staging
-  вручную), правка docker-compose/entrypoint (инфра, ручная проверка на 8501).
-notes: >
-  Все FS-зависимые тесты используют tmp_path и monkeypatch os.getuid/os.stat — без реального chown
-  и без записи в /repos. Telegram/Plane мокаются. Полный регресс tests/ должен оставаться зелёным;
-  STAGE_TRANSITIONS/QG_CHECKS/схема БД не затрагиваются — отдельные guard-тесты не требуются, но
-  существующие тесты на инварианты должны пройти без изменений.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "ensure_worktree при git-fatal 'could not create leading directories / Permission denied' поднимает RuntimeError с диагнозом legacy-root + лечащей командой, а не сырой git stderr"
-    module: tests/test_git_worktree_perm.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "ensure_worktree при ошибке, НЕ связанной с правами (например branch conflict), сохраняет прежний контракт сообщения (не подменяет смысл)"
-    module: tests/test_git_worktree_perm.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "scan_ownership на дереве с файлом uid != target_uid возвращает mismatch=True и список затронутых корней"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "scan_ownership на чистом дереве (все файлы target_uid) возвращает mismatch=False (идемпотентный no-op)"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "scan_ownership never-raise: при недоступном/несуществующем корне деградирует в WARNING и не бросает наружу"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "applies(repo): пустой ORCH_FS_NORMALIZE_REPOS → True только для self-hosting репо (orchestrator), False для enduro-trails; непустой CSV — по списку"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "kill-switch ORCH_FS_NORMALIZE_ENABLED=False → scan/normalize инертны (no-op), поведение 1:1 как до ORCH-057"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "normalize без прав (uid 1000, чужие root-файлы, ORCH_FS_NORMALIZE_AUTO=True) → no-op + честный лог 'нужна операторская процедура', НЕ исключение"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: "TTL-кэш детекта: повторный вызов в окне TTL не пере-сканирует дерево (по образцу preflight._cache); force/reset инвалидирует"
-    module: tests/test_fs_normalize.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "startup-хук lifespan при mismatch вызывает send_telegram (мок) и логирует WARNING; при ошибке детекта старт сервиса не падает (never-fatal)"
-    module: tests/test_fs_normalize_startup.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "опц. гейт claim'а: при обнаруженном mismatch без прав исход job внятный (FR-1-сообщение / не-claim) ДО launch, а не сырой git-fatal"
-    module: tests/test_fs_normalize_startup.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: "GET /queue (если реализован read-only блок fs_ownership) отдаёт {enabled,target_uid,mismatch,roots,checked_at} и не 5xx-ит при выключенном флаге"
-    module: tests/test_api_queue.py
-    expected: PASS

docs/work-items/ORCH-057/06-adr/ADR-001-legacy-ownership-normalization.md

@@ -1,210 +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-001: Нормализация legacy root-owned файлов при миграции на uid 1000 — детект + actionable-ошибка + процедура
-
-Work Item: **ORCH-057** — follow-up ORCH-040 (legacy `root:root` файлы в `/repos` ломают создание worktree под uid 1000)
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`** (новый
-leaf-компонент + startup-поведение, затрагивает весь инстанс → кросс-каттинг).
-
-## Статус
-Proposed
-
-## Контекст
-
-ORCH-040 перевёл оба контейнера на `user: "1000:1000"`, изменив **только** `docker-compose.yml`.
-Смена `user:` не меняет владельца уже существующих файлов, созданных прежним root-контейнером.
-Bind-mount `/home/slin/repos → /repos` содержал `root:root` каталоги (`_wt/`, старые worktree,
-`.git/objects`, `data/runs` — 37 root-логов).
-
-**Сверено по коду:**
-- `src/git_worktree.py::ensure_worktree` (стр. 78 `os.makedirs(os.path.dirname(wt))`, стр. 81/85
-  `git worktree add`) — точка реального падения. При `root:root` владельце `/repos/_wt/` uid 1000
-  не может создать рядом новый каталог worktree → `fatal: could not create leading directories …
-  Permission denied`. Сейчас этот stderr пробрасывается «сырым» в `RuntimeError` (стр. 90–93) без
-  диагноза причины.
-- Конвейер приходит сюда из `src/agents/launcher.py::_spawn` и `_materialize_deferred_branch`
-  (ORCH-088, отложенный срез ветки на момент claim analyst-job). **Агент не стартует** — падает
-  создание worktree (НЕ код задачи), т.е. это launch-time инфраструктурный сбой.
-- Контейнер бежит под numeric uid 1000 **без root** (ORCH-040 P-3, ORCH-058 реальный user `slin`
-  в образе). Под uid 1000 `chown` чужих (root) файлов **невозможен** без `CAP_CHOWN`. Значит код
-  физически не может «починить» права сам — ему доступны только **детект + диагностика**, а
-  фактический `chown` — операторская процедура.
-- ADR-001 ORCH-040 упоминал «массовый chown старых root-файлов» лишь абстрактно («вне объёма кода»,
-  «разовая операция Owner») и не дал конкретной процедуры → deployer её не выполнил → баг проявился
-  в проде 06.06 на первом запуске ORCH-043. Прод сейчас рабочий (ручной workaround Стрима наложен),
-  но проблема **воспроизводится** на чистой среде / новом репо / после любого исторического запуска
-  под root.
-
-Это **закрытие недоделанного AC ORCH-040**, а не новая фича. Существующие гейты/паттерны для опоры:
-условный leaf-гейт `coverage_gate`/`serial_gate` (kill-switch + scope + `is_self_hosting_repo`),
-best-effort startup-хуки в `main.lifespan` (lease-reclaim, log-rotation — never-fatal),
-read-only снимки `GET /queue` (`serial_gate.snapshot()`), TTL-кэш `preflight._cache`.
-
-## Решение
-
-### Сводка
-Три аддитивных, обратимых kill-switch'ем слоя, **без** изменения `STAGE_TRANSITIONS` / `QG_CHECKS` /
-`check_*` / machine-verdict-ключей / схемы БД:
-
-1. **Actionable-ошибка** в `ensure_worktree` — класс «нет прав на создание worktree» распознаётся и
-   превращается в диагностируемый `RuntimeError` с причиной + лечащей командой (FR-1).
-2. **Детект-леаф** `src/fs_normalize.py` — чистый, never-raise, TTL-кэшируемый обход корней, ищет
-   файлы с `uid != target_uid` (FR-2); вызывается best-effort на старте сервиса с наблюдаемостью
-   (FR-3).
-3. **Операторская процедура** в `INFRA.md` + forward-breadcrumb из ADR-040 — точные команды разовой
-   нормализации как обязательный шаг миграции uid (FR-5).
-
-Фактический `chown` остаётся **операторской процедурой** (NFR-1: код под uid 1000 без root его делать
-не может и не должен).
-
-### D1 — `ensure_worktree`: классификация отказа доступа (FR-1, AC-1, AC-2)
-Оборачиваем **обе** точки сбоя по правам — `os.makedirs(os.path.dirname(wt))` (стр. 78) и оба
-`git worktree add` (стр. 81/85). Класс «нет прав» детектируется по маркерам в `stderr`/исключении:
-`Permission denied`, `could not create leading directories`, `insufficient permission for adding an
-object`, `PermissionError` (errno `EACCES`/`EPERM`). При совпадении — `RuntimeError`, текст которого:
-(а) называет корневую причину («legacy root-owned файлы в `/repos/_wt` или `.git` после миграции uid
-ORCH-040»); (б) указывает лечащую команду (`chown -R <target_uid>:<gid> /repos/_wt …`) и ссылку на
-раздел INFRA.md; (в) **не** является сырым git stderr.
-
-**Инвариант контракта (AC-2 FAIL-условие):** ошибки, **не** связанные с правами (реальный git-конфликт,
-отсутствие `origin/main`, таймаут), сохраняют **прежний** текст/смысл — никакой подмены. Классификатор —
-чистая функция `classify_worktree_error(stderr_or_exc) -> bool` (или хелпер в `fs_normalize`),
-покрытая юнит-тестами на обе ветки. Помощь-сообщение строится только при `True`. Это **меняет лишь
-формулировку** ошибки, не её факт (NFR-3): worktree как падал, так и падает — но теперь внятно.
-
-### D2 — Детект-леаф `src/fs_normalize.py` (FR-2, AC-3)
-Новый чистый модуль по образцу `serial_gate`/`post_deploy` (импортирует только `config`/`logging`/
-`os`/`pwd`; не тянет `stage_engine`/`launcher`). API:
-
-- `scan_ownership(roots: list[str] | None = None, target_uid: int | None = None) -> OwnershipScan` —
-  обходит корни, возвращает `{mismatch: bool, target_uid: int, roots_checked: list, roots_mismatch:
-  list, sample_path: str | None, count: int | None, checked_at: float}`.
-- **`target_uid`** по умолчанию = `os.getuid()` (uid, под которым реально бежит процесс — ровно тот
-  субъект, что «не может создать файл»); переопределяется `fs_target_uid` (дефолт 1000) для тестов/
-  нестандартного рантайма.
-- **Корни** по умолчанию: `/repos/_wt`, `<repo>/.git/objects`, `<repo>/.git/worktrees` (для репо из
-  скоупа), `data/runs` (`os.path.dirname(settings.db_path)/runs`). Переопределяемы `fs_scan_roots`
-  (CSV).
-- **Дешевизна (риск стоимости обхода):** **ранний выход при первом mismatch** (для быстрого булева
-  вердикта `os.lstat(...).st_uid != target_uid`). Полный `count` — опционален/семплирован (отдельный
-  дешёвый режим, по умолчанию выключен), чтобы не обходить целиком большие `.git/objects`. Результат
-  **кэшируется по TTL** `fs_scan_cache_ttl_s` (паттерн `preflight._cache`, `force=` обходит кэш).
-- **never-raise (NFR-3):** любая ошибка обхода (исчезнувший путь, отказ stat) → деградирует в WARNING
-  и консервативный вердикт `mismatch=False` (не блокирует и не паникует); идемпотентно (AC-3:
-  повторный скан на чистой среде — `mismatch=False`, no-op).
-- **`applies(repo: str) -> bool`** — `fs_normalize_enabled` (kill-switch) И scope (`fs_normalize_repos`
-  CSV; пусто → `is_self_hosting_repo(repo)`, как `coverage_gate`); проверяется **ПЕРВЫМ**, дорогой
-  обход — только при `applies==True` (NFR-2: enduro-trails не сканируется при пустом CSV).
-- **`snapshot() -> dict`** — read-only для `GET /queue`.
-
-### D3 — Точка интеграции: startup-наблюдаемость, БЕЗ блокировки claim (FR-3 — разрешение открытого выбора TRZ)
-TRZ §2 оставил архитектору выбор «preflight vs queue_worker» для опц. гейта claim'а. **Решение:
-claim НЕ блокируем.**
-
-- **Startup (`main.lifespan`):** best-effort вызов `scan_ownership()` рядом с lease-reclaim/log-rotation
-  (стр. 63–90), обёрнут `try/except` (never-fatal). При `mismatch` — структурный WARNING (число/корни/
-  лечащая команда) + Telegram (если включён). Это даёт оператору **проактивный сигнал заранее**
-  (AC-4), не дожидаясь падения задачи.
-- **«Внятно и заранее» обеспечивает D1, а не claim-гейт.** `ensure_worktree` знает `repo` и падает
-  до того, как агент потратит хоть один токен (агент не стартует). Это и есть требуемый ранний внятный
-  исход.
-
-**Почему НЕ блокирующий claim-гейт (отвергнуто):**
-- `preflight.check()` **не знает repo** и гейтит claim **всех** репо → при mismatch в общем `/repos/_wt`
-  заблокировал бы и enduro-trails (нарушение NFR-2 при включённом флаге). Сделать его scope-aware
-  внутри preflight нельзя без знания репо в точке вызова.
-- Гейт в `queue_worker`/`db.claim_next_job` (как `serial_gate`) технически scope-aware, но: (1)
-  оставил бы задачу «молча висеть» в очереди вместо явного диагноза; (2) добавил бы дорогой FS-обход
-  в offline hot-path claim'а; (3) дублировал бы исход, который D1 уже даёт внятно. Лишняя поверхность
-  без выигрыша.
-
-Итог: **детект = наблюдаемость (startup + опц. ручной POST), а внятный отказ = D1 в точке launch.**
-
-### D4 — Опциональная авто-нормализация `normalize()` (FR-4) — не init-контейнер
-`fs_normalize.normalize(roots, target_uid)` выполняет `os.chown`/`chown -R` по корням **только если
-процесс имеет `CAP_CHOWN`/root**. Под uid 1000 без прав — **no-op + честный лог** «нужна операторская
-процедура» (НЕ ошибка). Включается отдельным флагом `fs_normalize_auto` (дефолт `False` — детект-only).
-
-**Init-контейнер/root-entrypoint отвергнут (см. Альтернативы):** он (а) реинтродуцирует root-контекст,
-ровно который ORCH-040 убрал ради безопасности; (б) требует правки `docker-compose.yml`/entrypoint →
-**self-deploy** с групповым риском (NFR-1) и обязательной staging-страховкой ради разовой задачи;
-(в) discretionary по BRD §2 «Опционально». Носитель реальной нормализации — **документированная
-операторская процедура** (D5), запускаемая под root **на хосте** один раз при миграции uid.
-
-### D5 — Процедура в INFRA.md + forward-breadcrumb (FR-5, AC-7)
-В `docs/operations/INFRA.md` (раздел «Рантайм-uid (ORCH-040)») добавляется подраздел **«Миграция uid:
-обязательная нормализация legacy root-файлов»** с точными командами, покрывающими **все** корни
-(`_wt`, оба `.git`, `data/runs`), помеченный как **обязательный** шаг миграции uid и пункт чеклиста
-деплоя self. Существующий абстрактный буллет (стр. 50–51) заменяется ссылкой на новый подраздел.
-В ADR-040 — необязательный forward-breadcrumb на ORCH-057 (история ORCH-040 не переписывается, §2 BRD).
-
-### D6 — Конфиг-флаги (TRZ §7) и наблюдаемость
-Аддитивно в `src/config.py` (существующие значения не трогаются):
-
-| Флаг (env) | Дефолт | Смысл |
-|------------|--------|-------|
-| `fs_normalize_enabled` (`ORCH_FS_NORMALIZE_ENABLED`) | `True` | kill-switch; `False` → весь код инертен, поведение 1:1 как до ORCH-057 (D1 тоже гардится — при выкл. контракт ошибки прежний) |
-| `fs_normalize_repos` (`ORCH_FS_NORMALIZE_REPOS`) | `""` | scope CSV; пусто → self-hosting only (`is_self_hosting_repo`) |
-| `fs_target_uid` (`ORCH_FS_TARGET_UID`) | `1000` | целевой uid (фолбэк, если `os.getuid()` неприменим) |
-| `fs_normalize_auto` (`ORCH_FS_NORMALIZE_AUTO`) | `False` | детект-only; `True` → попытка chown при наличии прав (D4) |
-| `fs_scan_roots` (`ORCH_FS_SCAN_ROOTS`) | `""` | CSV-переопределение корней |
-| `fs_scan_cache_ttl_s` (`ORCH_FS_SCAN_CACHE_TTL_S`) | `300` | TTL детект-кэша |
-
-Наблюдаемость (AC-4): read-only блок `fs_ownership` в `GET /queue` (`snapshot()`:
-`{enabled, target_uid, mismatch, roots_checked, roots_mismatch, checked_at}`); опц. ручной триггер
-`POST /fs-normalize/check` (форс-пересчёт, по образцу `POST /serial-gate/unfreeze`). Telegram при
-mismatch — с кликабельным номером задачи (если в контексте есть `work_item_id`), числом/корнями,
-лечащей командой.
-
-## Альтернативы
-- **Init-контейнер / root-entrypoint, выполняющий `chown` на буте** — отвергнуто: реинтродуцирует
-  root-контекст (анти-цель ORCH-040), требует правки `docker-compose.yml`/entrypoint = self-deploy +
-  групповой риск + обязательная staging-страховка ради одноразовой операции; BRD помечает его
-  «Опционально». Реальную нормализацию несёт документированная разовая операторская процедура.
-- **Блокирующий claim-гейт в `preflight`** — отвергнуто: preflight не знает repo → блокирует claim
-  ВСЕХ репо, регресс enduro-trails на общем `/repos` (нарушение NFR-2).
-- **Блокирующий claim-гейт в `queue_worker`/`claim_next_job`** — отвергнуто: дорогой FS-обход в
-  offline hot-path, «молчаливое зависание» вместо внятного диагноза, дублирует исход D1.
-- **Авто-`chown` из app-кода по умолчанию** — отвергнуто: под uid 1000 невозможен; включение по
-  умолчанию создавало бы ложное ожидание самолечения. Оставлен как opt-in `fs_normalize_auto` для
-  сред, где процесс имеет CAP_CHOWN.
-- **Жёсткий fail на старте при mismatch** — отвергнуто: нарушает never-raise (NFR-3) и мог бы
-  застопорить старт сервиса всех проектов из-за грязного `/repos`. Детект — only WARNING/Telegram.
-
-## Последствия
-- **+** Класс «сырой git-fatal на launch после миграции uid» закрыт: оператор получает внятный
-  диагноз + лечащую команду в точке падения (D1) и проактивный сигнал на старте (D3).
-- **+** Воспроизводимая процедура в INFRA.md закрывает пробел ADR-040 (AC-7).
-- **+** Нулевая регрессия enduro-trails (scope `applies()` first, пустой CSV → self-hosting only);
-  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт прежние (AC-6).
-- **+** Никакого root-контекста, рестарта прода, касания `main`/force-push/прод-образа (NFR-1, AC-5).
-- **−** Фактический `chown` остаётся **ручным** операторским шагом — на средах, где его забыли, баг
-  всё ещё проявится, но теперь **внятно** (с инструкцией), а не сырым git-fatal. Митигейшн:
-  startup-WARNING+Telegram + обязательный пункт чеклиста миграции в INFRA.md.
-- **−** Ещё один best-effort startup-хук + leaf-модуль (рост поверхности). Митигейшн: чистый
-  never-raise leaf, TTL-кэш, ранний выход обхода, kill-switch.
-- **−** `fs_normalize_auto=True` под root реинтродуцирует chown-контекст — поэтому дефолт `False` и
-  он не для прод-self (прод бежит под uid 1000).
-- **Откат:** `fs_normalize_enabled=False` → весь код инертен (D1 контракт ошибки прежний, детект не
-  запускается); миграций/правки схемы нет → мгновенный обратимый kill-switch.
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-057/01-brd.md`
-- TRZ: `docs/work-items/ORCH-057/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-057/03-acceptance-criteria.md`
-- Инфра: `docs/work-items/ORCH-057/07-infra-requirements.md`
-- Риски: `docs/work-items/ORCH-057/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md`
-- Сверено по коду: `src/git_worktree.py` (`ensure_worktree` стр. 78/81/85/90), `src/preflight.py`
-  (TTL-кэш), `src/main.py` (`lifespan` стр. 63–114), `src/serial_gate.py` / `src/coverage_gate.py`
-  (паттерн условного leaf `applies`/scope/`is_self_hosting_repo`).
-- Предшественник: `docs/work-items/ORCH-040/06-adr/ADR-001-run-agents-as-host-uid.md`,
-  `docs/architecture/adr/adr-0005-container-runs-as-host-uid.md`.

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

@@ -1,63 +0,0 @@
----
-work_item: ORCH-057
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
-
-Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable. Топология контейнеров **не меняется** (init-контейнер/правка `docker-compose.yml`
-> отвергнуты — ADR-001 D4). Файл фиксирует новые env-флаги и **обязательную операторскую процедуру**
-> нормализации legacy root-файлов как шаг миграции uid.
-
-## I-1. Топология / окружения
-**Без изменений.** Контейнеры `orchestrator` (8500) / `orchestrator-staging` (8501), `user:
-"1000:1000"`, bind-mount `/home/slin/repos → /repos`, `network_mode: host` — как есть. Init-контейнер
-/ root-entrypoint **сознательно НЕ вводятся** (реинтродуцировали бы root-контекст, убранный ORCH-040,
-и потребовали бы self-deploy compose с групповым риском — ADR-001 D4, Альтернативы).
-
-## I-2. Переменные окружения / секреты
-Новые env-флаги (аддитивно в `src/config.py`, дефолты сохраняют поведение до ORCH-057). Добавить в
-`.env.example` (секретов нет):
-
-| Env | Дефолт | Назначение |
-|-----|--------|------------|
-| `ORCH_FS_NORMALIZE_ENABLED` | `true` | kill-switch всего слоя ORCH-057 |
-| `ORCH_FS_NORMALIZE_REPOS` | `` (пусто) | scope CSV; пусто → self-hosting only (enduro не затронут) |
-| `ORCH_FS_TARGET_UID` | `1000` | целевой uid (фолбэк к `os.getuid()`) |
-| `ORCH_FS_NORMALIZE_AUTO` | `false` | детект-only; `true` → попытка chown при наличии CAP_CHOWN |
-| `ORCH_FS_SCAN_ROOTS` | `` (пусто) | CSV-переопределение корней обхода |
-| `ORCH_FS_SCAN_CACHE_TTL_S` | `300` | TTL детект-кэша |
-
-Секреты не вводятся.
-
-## I-3. Деплой / рестарт
-- **Self-hosting инвариант (NFR-1):** код задачи **не** рестартит/не роняет прод-контейнер
-  `orchestrator`, не трогает `main`/force-push/прод-образ. `chown` из кода возможен лишь при наличии
-  прав (под uid 1000 — no-op).
-- Изменение **только** `src/**` + docs → штатный деплой self **через staging-гейт (8501)**, затем
-  прод-рестарт **в окно тишины** (`GET /status` без активных задач). Правки `docker-compose.yml`/
-  entrypoint в задаче **нет** → нет дополнительного инфра-риска сверх обычного self-деплоя.
-- **Обязательная операторская процедура нормализации (host-prerequisite миграции uid)** — выполняется
-  **под root на хосте mva154 один раз** при миграции uid / на новой среде, ПЕРЕД стартом app.
-  Каноничный текст — в `docs/operations/INFRA.md` (раздел «Миграция uid: обязательная нормализация
-  legacy root-файлов»). Команды покрывают все корни:
-  ```
-  sudo chown -R 1000:1000 /home/slin/repos/_wt
-  sudo chown -R 1000:1000 /home/slin/repos/orchestrator/.git \
-                          /home/slin/repos/enduro-trails/.git
-  sudo chown -R 1000:1000 /home/slin/repos/orchestrator        # incl. data/runs/*.log
-  # Проверка: find /home/slin/repos/_wt ! -uid 1000 -print -quit   (пусто = ок)
-  ```
-  Идемпотентна (повтор на корректной среде — no-op). Помечена обязательным пунктом чеклиста
-  деплоя/миграции self.
-
-## I-4. CI/CD
-Без изменений в `.gitea/workflows/`. Новые юнит-тесты (`tests/test_fs_normalize.py`,
-`tests/test_git_worktree_perm_error.py` — см. `04-test-plan.yaml`) гоняются существующим
-`pytest tests/ -q`. Новых системных зависимостей образа нет.

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

@@ -1,37 +0,0 @@
----
-work_item: ORCH-057
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-057 — нормализация legacy root-owned файлов при миграции на uid 1000
-
-Work Item: **ORCH-057** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Ложная классификация ошибки worktree** (D1): не-прав-ошибка распознана как «нет прав» → подмена смысла (FAIL AC-2). | Низ. | Сред. | Узкий набор маркеров (`Permission denied`/`could not create leading directories`/`insufficient permission`/`EACCES`/`EPERM`); классификатор — чистая функция с юнит-тестами на обе ветки; не-совпадение → прежний сырой текст без изменений. |
-| TR-2 | **Дорогой рекурсивный обход** больших `.git/objects` / `_wt` тормозит старт сервиса. | Сред. | Сред. | Ранний выход при первом mismatch (булев вердикт); полный `count` опционален/семплирован; TTL-кэш (`fs_scan_cache_ttl_s`); вызов best-effort на старте, не в hot-path claim'а; `applies()` first → обход только при applies. |
-| TR-3 | **Ложно-блокирующий эффект на enduro-trails** через общий `/repos`. | Низ. | Выс. | Claim НЕ блокируется (D3 — только наблюдаемость); scope `applies()` first, пустой CSV → self-hosting only → enduro не сканируется; детект never-raise. |
-| TR-4 | **Забытый ручной `chown`**: на среде без выполненной процедуры баг всё ещё проявится. | Сред. | Сред. | Теперь проявляется **внятно** (D1 actionable-ошибка + startup WARNING/Telegram, не сырой git-fatal); процедура — обязательный пункт чеклиста миграции в INFRA.md; идемпотентна. Остаточный риск принят (код под uid 1000 не может chown). |
-| TR-5 | **`fs_normalize_auto=True` под root** реинтродуцирует chown-контекст / неожиданный массовый chown. | Низ. | Сред. | Дефолт `False`; прод-self бежит под uid 1000 (chown = no-op); auto-режим — opt-in для сред с CAP_CHOWN; init-контейнер отвергнут (ADR-001 D4). |
-| TR-6 | **never-raise дыра**: необработанное исключение детекта роняет старт сервиса всех проектов. | Низ. | Выс. | Леаф never-raise (паттерн `serial_gate`/`post_deploy`); startup-вызов в `try/except` (как lease-reclaim/log-rotation); ошибка → WARNING + консервативный `mismatch=False`. |
-| TR-7 | **`os.getuid()` неприменим** в нестандартном рантайме → неверный target_uid → ложный mismatch. | Низ. | Низ. | Фолбэк `fs_target_uid` (дефолт 1000); идемпотентность скана; вердикт only-наблюдательный (не блокирует). |
-| TR-8 | **Кэш устарел** после выполнения нормализации → stale `mismatch=True` в `GET /queue`. | Низ. | Низ. | TTL-инвалидизация; ручной `POST /fs-normalize/check` (`force=True`) для немедленного пересчёта. |
-
-## Сводный вывод
-Доминирующий класс — **операционные риски разовой нормализации**, а не алгоритмические: код только
-читает/детектит/диагностирует (chown — операторская процедура под root на хосте). Самостоятельный
-техдолг (TR-4) — остаточный и **принят**: контейнер без root физически не может починить права сам;
-решение гарантирует **внятность** отказа, а не его отсутствие. Self-hosting-безопасность соблюдена
-(никакого рестарта прода / касания `main` / root-контекста в коде). Изменение аддитивно и обратимо
-kill-switch'ем → **эскалация `arch:major-change` НЕ требуется** (нет новой стадии/QG/таблицы/смены
-топологии). Возврат в анализ не нужен — ТЗ удовлетворяется без нарушения принципов архитектуры.
-Остаточный риск для прод-конвейера — **низкий**.

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

@@ -1,105 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-057
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-057
-version: 1
----
-
-# Review ORCH-057
-
-## Summary
-
-Follow-up ORCH-040: закрыт недоделанный AC по legacy `root:root` файлам, ломавшим создание
-worktree под uid 1000. Реализованы три аддитивных, обратимых kill-switch'ем слоя ровно по ADR-001:
-**D1** actionable-ошибка в `ensure_worktree`, **D2** детект-леаф `src/fs_normalize.py`
-(never-raise, TTL-кэш, scope-aware), **D3** best-effort startup-наблюдаемость в `main.lifespan`
-(WARNING + Telegram, claim не блокируется), плюс `GET /queue` блок `fs_ownership` и
-`POST /fs-normalize/check`. Документация (INFRA.md процедура, architecture/README.md, сквозной
-adr-0031, CHANGELOG, .env.example) обновлена в том же PR.
-
-Проверено по 4 осям; все 7 AC выполнены, P0/P1 findings нет. Регресс `pytest tests/ -q` —
-**1507 passed**; целевые модули (`test_fs_normalize`, `test_fs_normalize_startup`,
-`test_git_worktree_perm`, `test_api_queue`) — **25 passed**, покрывают TC-01…TC-12.
-
-## Соответствие ТЗ (02-trz) и AC (03-acceptance-criteria)
-
-- **FR-1 / AC-1, AC-2** ✓ — `git_worktree._raise_if_permission` + `fs_normalize.is_permission_failure`/
-  `build_worktree_help`: класс «нет прав» (`Permission denied`/`could not create leading directories`/
-  `insufficient permission`/`PermissionError`/`EACCES`/`EPERM`) → actionable `RuntimeError` с причиной,
-  `chown`-командой и ссылкой на INFRA.md. Обе точки сбоя обёрнуты (`os.makedirs` + оба `worktree add`).
-  Не-прав-ошибки сохраняют прежний raw-контракт (TC-02 PASS). Под kill-switch — no-op, контракт 1:1.
-- **FR-2 / AC-3** ✓ — `scan_ownership` обходит `/repos/_wt`, `<repo>/.git/{objects,worktrees}`,
-  `data/runs`; ранний выход на первом `lstat.st_uid != target_uid`; чистая среда → `mismatch=False`
-  идемпотентно; never-raise → консервативный `mismatch=False` (TC-03/04/05).
-- **FR-3 / AC-4** ✓ — startup-хук never-fatal: WARNING + Telegram при mismatch; claim не блокируется
-  (D3, преднамеренно — внятный ранний отказ даёт D1, знающий repo). Read-only блок `fs_ownership` в
-  `GET /queue` (TC-10/TC-12).
-- **FR-4** ✓ — `normalize()` chown только при `_is_privileged()` (geteuid==0); под uid 1000 — no-op +
-  честный лог, НЕ ошибка; gated `fs_normalize_auto` (дефолт False) (TC-08).
-- **FR-5 / AC-7** ✓ — INFRA.md: блокер P-5 + подраздел «Миграция uid: обязательная нормализация»
-  со всеми корнями; work-item ADR + сквозной adr-0031.
-- **§7 совместимость / AC-5** ✓ — `applies(repo)` first (kill-switch + scope; пустой CSV →
-  self-hosting only через `is_self_hosting_repo`); enduro-trails не сканируется при дефолте.
-  TTL-кэш (`fs_scan_cache_ttl_s`). Регресс зелёный (1507 passed).
-
-## Соответствие ADR
-
-- Реализация совпадает с ADR-001 D1–D6 (включая сознательный отказ от блокирующего claim-гейта и
-  init-контейнера — обоснование в «Альтернативах»). Сквозная регистрация adr-0031 присутствует и
-  отражена в architecture/README.md.
-- **Трассировка (AC-6 / TRACEABILITY):** инварианты конвейера не тронуты — commit `9852871` НЕ
-  затрагивает `src/stages.py`, `src/qg/checks.py`, `src/db.py`, `src/stage_engine.py`. Маркеры
-  ORCH-040/088 в `git_worktree`/`main` читаются, зафиксированные инварианты (never-fatal startup,
-  отложенный срез ветки) не сломаны. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема
-  БД — байт-в-байт прежние.
-
-## Качество кода
-
-- `src/fs_normalize.py` — чистый leaf (импортирует только `config`/`logging`/`os`/`time`,
-  лениво `qg.checks`/`notifications`); строгий never-raise на каждой публичной функции; docstrings
-  на всех публичных символах; `os.lstat` (не `stat`) для честной оценки симлинков. Зависимость
-  односторонняя (`git_worktree` → `fs_normalize`).
-- Узкий `_PERM_MARKERS` сознательно не реклассифицирует не-прав-ошибки (защита AC-2).
-- Тесты содержательны (214/136/139/68 строк), используют `tmp_path`/monkeypatch, без реального
-  chown и записи в `/repos`; покрывают обе ветки классификатора, идемпотентность, scope, kill-switch,
-  TTL-кэш, startup-never-fatal.
-- Утечек/секретов/security-дыр не выявлено; chown физически возможен только под root (`_is_privileged`).
-
-## Findings
-
-### P0 — Blocker
-- Нет.
-
-### P1 — Must fix
-- Нет.
-
-### P2 — Should fix
-- Нет.
-
-### P3 — Nice-to-have (не блокирует)
-- [ ] `snapshot()` в `GET /queue` на холодном кэше инициирует реальный обход `.git/objects` синхронно
-  в обработчике запроса. На практике кэш прогрет startup-хуком и TTL=300s, обход только для
-  self-hosting — латентность пренебрежима, паттерн зеркалит `coverage_gate`. Можно при желании
-  отдавать в `/queue` только кэш без форс-скана. Информационно.
-
-## Документация
-
-Обновлена в том же PR — golden source синхронен с кодом:
-- `docs/operations/INFRA.md` — P-5 (блокер миграции uid) + подраздел процедуры со всеми корнями ✓
-- `docs/architecture/README.md` — компонент «FS ownership detect» (D1–D3, условность, наблюдаемость) ✓
-- `docs/architecture/adr/adr-0031-legacy-ownership-normalization.md` — сквозной ADR (tracked) ✓
-- `docs/work-items/ORCH-057/06-adr/ADR-001-…md` — work-item ADR ✓
-- `CHANGELOG.md` — запись ORCH-057 ✓
-- `.env.example` — 6 флагов `ORCH_FS_*` ✓
-
-`README.md` «Известные ограничения» (ORCH-079): пункт про legacy-ownership/uid-миграцию там
-отсутствует — закрывать/снимать нечего, обзорная витрина в обновлении не нуждается.
-
-**Вывод:** изменение `src/` сопровождено обновлением документации → требование правила 6
-выполнено.

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

@@ -1,94 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-057
-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-057
----
-
-# Test Report — ORCH-057
-
-Нормализация legacy root-owned файлов при миграции на uid 1000 (детект + защита worktree).
-Review-вердикт `12-review.md` — **APPROVED**, P0/P1 findings нет.
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Дата: 2026-06-10
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-057-bug-follow-up-orch-040-normali`
-  (ветка `feature/ORCH-057-bug-follow-up-orch-040-normali`, тесты прогнаны из рабочего дерева
-  именно этой задачи, НЕ из общего `/repos/orchestrator`)
-
-## Smoke API (read-only, прод-контейнер 8500 не тронут)
-| Эндпоинт | Результат |
-|----------|-----------|
-| `GET /health` | `{"status":"ok","service":"orchestrator"}` — OK |
-| `GET /status` | OK — задача ORCH-057 (id 83) видна на стадии `testing` |
-| `GET /queue` | OK — присутствуют блоки `serial_gate` (ORCH-088) ✓ и `auto_labels` (ORCH-089) ✓ |
-
-> Примечание: блок `fs_ownership` (ORCH-057) на прод-контейнере 8500 **отсутствует** —
-> это ожидаемо: ORCH-057 ещё не задеплоен, прод исполняет предыдущий образ. Read-only блок
-> `fs_ownership` присутствует и протестирован в коде ветки (TC-12, `test_api_queue.py` PASS).
-> Это НЕ регресс смока: обязательные блоки `serial_gate` + `auto_labels` на месте.
-
-## Результаты
-
-### Полный регресс
-`pytest tests/ -q` → **1507 passed, 1 warning in 52.22s** (warning — Pydantic V2 deprecation,
-предсуществующий, не относится к ORCH-057). Прод-контейнер не трогался.
-
-### Профильные сюиты
-`pytest tests/test_git_worktree_perm.py tests/test_fs_normalize.py tests/test_fs_normalize_startup.py tests/test_api_queue.py -v`
-→ **25 passed** — покрывают TC-01…TC-12.
-
-### Сопоставление с тест-планом (04-test-plan.yaml)
-| TC ID | Описание | Тест-функция | Результат |
-|-------|----------|--------------|-----------|
-| TC-01 | `ensure_worktree` на git-fatal Permission denied → actionable RuntimeError | `test_git_worktree_perm::test_tc01_permission_git_fatal_becomes_actionable`, `test_tc01_makedirs_permission_error_becomes_actionable` | PASS |
-| TC-02 | не-прав-ошибка сохраняет прежний raw-контракт | `test_git_worktree_perm::test_tc02_non_permission_error_keeps_prior_contract`, `test_tc02_killswitch_off_keeps_raw_contract_even_for_permission` | PASS |
-| TC-03 | `scan_ownership` на дереве с uid≠target → mismatch=True + корни | `test_fs_normalize::test_tc03_scan_detects_mismatch` | PASS |
-| TC-04 | `scan_ownership` на чистом дереве → mismatch=False (идемпотентно) | `test_fs_normalize::test_tc04_clean_tree_no_mismatch` | PASS |
-| TC-05 | never-raise при недоступном/несуществующем корне → WARNING | `test_fs_normalize::test_tc05_never_raise_on_missing_root`, `test_tc05_never_raise_on_walk_error` | PASS |
-| TC-06 | `applies(repo)`: пустой CSV → self-hosting only; непустой — по списку | `test_fs_normalize::test_tc06_applies_empty_csv_self_hosting_only`, `test_tc06_applies_explicit_csv` | PASS |
-| TC-07 | kill-switch OFF → scan/normalize инертны (1:1 как до ORCH-057) | `test_fs_normalize::test_tc07_killswitch_off_scan_inert`, `test_tc07_killswitch_off_normalize_inert` | PASS |
-| TC-08 | `normalize` без прав → no-op + честный лог, НЕ исключение | `test_fs_normalize::test_tc08_normalize_without_rights_is_noop_not_error` | PASS |
-| TC-09 | TTL-кэш: повтор в окне TTL не пере-сканирует; ключ по roots+uid | `test_fs_normalize::test_tc09_ttl_cache_avoids_rescan`, `test_tc09_cache_keyed_by_roots_and_uid` | PASS |
-| TC-10 | startup-хук: mismatch → send_telegram + WARNING; ошибка детекта never-fatal | `test_fs_normalize_startup::test_tc10_startup_mismatch_warns_and_telegrams`, `test_tc10_startup_detect_error_never_fatal`, `test_tc10_startup_clean_no_telegram` | PASS |
-| TC-11 | гейт claim'а: mismatch без прав → внятный исход ДО launch, не сырой git-fatal | `test_fs_normalize_startup::test_tc11_launch_permission_failure_is_actionable_not_raw` | PASS |
-| TC-12 | `GET /queue` блок `fs_ownership` отдаёт поля и не 5xx-ит при выключенном флаге | `test_api_queue::test_tc12_queue_exposes_fs_ownership_block`, `test_tc12_queue_no_5xx_when_disabled`, `test_fs_normalize_check_endpoint` | PASS |
-
-Доп. целевые тесты (сверх плана, усиливают покрытие): `test_classify_worktree_error_markers`,
-`test_is_permission_failure_from_exc`, `test_snapshot_shape` — PASS.
-
-### Сопоставление с критериями приёмки (03-acceptance-criteria.md)
-| AC | Покрыто | Результат |
-|----|---------|-----------|
-| AC-1 — конвейер стартует без ручного chown / внятная блокирующая ошибка | TC-01, TC-11 | PASS |
-| AC-2 — `ensure_worktree` actionable-ошибка при отказе доступа, не-прав сохраняет контракт | TC-01, TC-02 | PASS |
-| AC-3 — детект несоответствия владельца (mismatch на грязной, no-op на чистой) | TC-03, TC-04, TC-05 | PASS |
-| AC-4 — наблюдаемость детекта (WARNING + Telegram + `GET /queue`) | TC-10, TC-12 | PASS |
-| AC-5 — self-hosting безопасность, нулевая регрессия enduro, зелёный регресс | TC-06, TC-07, TC-08 + 1507 passed | PASS |
-| AC-6 — инварианты конвейера (STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-key/схема БД) | полный регресс зелёный, guard-тесты пройдены | PASS |
-| AC-7 — документированная процедура нормализации (INFRA.md + ADR) | проверено reviewer (12-review.md), вне scope pytest | PASS (док.) |
-
-## Вывод pytest
-```
-============================= test session starts ==============================
-platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
-rootdir: /repos/_wt/orchestrator/feature_ORCH-057-bug-follow-up-orch-040-normali
-plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
-collected 25 items  (профильные сюиты)
-... 25 passed, 1 warning in 2.19s
-
-Полный регресс:
-1507 passed, 1 warning in 52.22s
-```
-
-## Итог
-**PASS** — все 12 TC выполнены и сопоставлены с тест-планом и критериями приёмки; профильные
-сюиты 25 passed; полный регресс 1507 passed; smoke (`/health`, `/status`, `/queue` c блоками
-`serial_gate` + `auto_labels`) — зелёный. Задача переходит на `deploy-staging`.

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

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

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

@@ -1,33 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-057
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T00:02:11Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-> Машинный вердикт читается ТОЛЬКО из `staging_status:` во frontmatter. `SUCCESS` → дальше; `FAILED` → откат.
-
-Staging test suite завершён против живого стенда `orchestrator-staging` (8501). Запуск канонический —
-`docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
-(ORCH-048, ADR-001). Скрипт завершился с **exit code 0** → `staging_status: SUCCESS`.
-
-Итог: **8/10 checks PASS**. Все REAL-проверки зелёные; два FAIL — известные sandbox-infra-проверки
-(C9a/C9b), waived согласно ORCH-061 (зависят от членства SANDBOX bot-аккаунтов в проекте, не от
-конвейера). Exit-code → вердикт не меняется: trust the exit code, REAL failed = none.
-
-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
-
-## Results
-- **Block A (SMOKE)**: PASS — A1 `/health` → 200 `status=ok`; A2 `/queue` → 200 с counts/max_concurrency/resilience; A3 `ORCH_STAGING=true` (не прод).
-- **Block B (ACCESS)**: PASS — B4 Plane sandbox доступен (5 projects, sandbox=YES); B5 Gitea `orchestrator-sandbox` доступен, push=true; B6 Registry изолирован (sandbox present, prod ET/ORCH absent).
-- **Block C (E2E, mode=stub)**: C7 создать issue в Plane SANDBOX → PASS; C8 триггер конвейера `/webhook/plane` → PASS; C9a (branch в sandbox) и C9b (analyst job в очереди) → FAIL, **INFRA-WAIVED** (sandbox bot-accounts не члены проекта). Cleanup: Plane issue удалён (HTTP 204).
-
-REAL failed: none.

docs/work-items/ORCH-095/16-post-deploy-log.md

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

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

@@ -1,7 +0,0 @@
-# Business Request: FND: машинный журнал уроков — структурированная база отклонений (топливо петли)
-
-Work Item ID: ORCH-098
-
-## Description
-
-TBD

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

@@ -1,143 +0,0 @@
----
-work_item: ORCH-098
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-098 — FND: машинный журнал уроков (структурированная база отклонений)
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-Оркестратор уже автономно проводит задачи через конвейер (ORCH-54), но **развивает** платформу
-по-прежнему вручную связка Слава+Стрим: ловим инциденты → формулируем уроки → заводим задачи.
-Уроки сегодня живут **свободным текстом** в `memory/` — они не машиночитаемы, по ним нельзя
-считать паттерны, нельзя приоритизировать, нельзя автоматически предлагать улучшения.
-
-ORCH-098 — шаг 1 эпика саморазвития (`docs/epics/self-evolution.md`, **домен 0 «Фундамент», F2**,
-ORCH-8). Это **«топливо» вертикали-двигателя** (петля самообучения 8A): формализовать свободный
-текст в **машинную структурированную таблицу отклонений конвейера**. Каждый урок — запись с
-полями для машинного анализа паттернов. Журнал — фундамент, на котором позже встанут
-ретроспективщик (E2), приоритизатор RICE (E3) и Стрим как потребители.
-
-**Установленные факты-источники сигналов («уроков»)** — из памяти орка (инциденты 06–09.06) и §8A
-эпика:
-- Провал гейта (BLOCKED / FAILED / REQUEST_CHANGES).
-- **Ручное вмешательство человека — самый ценный сигнал** (каждый ручной пинок = дыра автономности).
-- Ретраи, откаты деплоя, таймауты агентов.
-- Ложные срабатывания гейтов (исторический пример: substring `PASS` в `check_tests_passed`).
-- «Деплой SUCCESS, а прод не работает» (урок ET-8); транзиенты (Gitea `405`, Anthropic `Overloaded`).
-
-**Решение Славы 10.06 (ОБЯЗАТЕЛЬНО учесть на этапе схемы):** схема журнала ДОЛЖНА **с самого
-начала** нести поля для будущей **АТРИБУЦИИ** урока (иначе потом переделывать схему на живой
-общей прод-БД). Атрибуция (`platform-level` / `project-level` / `both` / `unknown`), целевой
-проект и целевой домен улучшения — это §8A эпика «platform-level vs project-level». При автозаписи
-поля атрибуции могут быть пустыми/`unknown` (классификацию позже ставит ретроспективщик/Стрим), но
-**колонки в схеме должны существовать сразу** — аддитивные, нуллабельные.
-
-**Связь со слоями наблюдения (§2 эпика):** деградация продукта (слой 3, урок ET-8) — один из типов
-урока; журнал должен уметь его хранить с атрибуцией `platform`/`project`.
-
-## 2. Объём (scope)
-
-### В объёме
-- Аддитивная идемпотентная таблица БД `lessons` для структурированных уроков со всеми полями
-  контекста, анализа, статуса **и атрибуции** (колонки атрибуции — сразу, нуллабельные).
-- Leaf-модуль `src/lessons.py` (never-raise, kill-switch) + helper записи урока.
-- **Автозапись** ≥2–3 типов отклонений из кода через best-effort точки врезки в
-  `stage_engine.py` / `merge_gate.py` / `launcher.py` (провал гейта/откат, HOLD, транзиент-ретрай).
-- **Read-only выборка** уроков (HTTP-эндпоинт + блок в `GET /queue`) — для будущего
-  ретроспективщика и Стрим.
-- **Ручная запись** урока (HTTP-эндпоинт / helper) — Стрим/оператор кладёт урок руками.
-- Доки (CLAUDE.md / architecture README / ADR) + `CHANGELOG.md`.
-
-### Вне объёма
-- **Анализ паттернов / ретроспективщик (E2)** — отдельная задача-потребитель журнала.
-- **Приоритизатор RICE (E3)** — отдельная задача.
-- **Автоматическая классификация атрибуции** — её ставит ретроспективщик/человек позже; здесь —
-  только колонки и возможность проставить значение руками/через update.
-- **Банк идей (D4 / идеатор, E5)** — отдельный реестр, НЕ путать с журналом уроков.
-- **Слой-3 детекция здоровья продукта** (мониторинг задеплоенного приложения) — отдельная
-  D4/D5-способность; журнал лишь умеет **хранить** такой урок, когда детектор появится.
-- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключей / любых
-  существующих таблиц.
-- Миграция исторических уроков из `memory/` (ручной разовый импорт — вне объёма).
-
-## 3. Заинтересованные стороны
-- **Заказчик:** Слава (требование атрибуции 10.06 — нормативно).
-- **Прямой потребитель (будущее):** агент-ретроспективщик E2, приоритизатор E3, Стрим (ручной
-  разбор).
-- **Затрагивается:** self-hosting прод-инстанс orchestrator (общая БД и очередь с enduro-trails) —
-  enduro **не должен быть затронут** (аддитивность, never-raise).
-- **Принимает результат:** reviewer/tester конвейера + Слава.
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 — Структурированная таблица уроков.** Аддитивная, идемпотентная (`CREATE TABLE IF NOT
-  EXISTS`) таблица `lessons` на общей прод-БД с полями: тип отклонения; контекст
-  (work_item/task/стадия/агент/repo); корневая причина (если известна); предложенное улучшение
-  (если есть); статус (`new`/`in_progress`/`closed`/`linked`) + связанная задача; timestamp.
-- **BR-2 — Поля атрибуции с самого начала.** Схема несёт **сразу** нуллабельные колонки:
-  `attribution` (`platform`/`project`/`both`/`unknown`), `target_repo` (кого касается:
-  `orchestrator`/`enduro-trails`/др.), `target_domain` (домен улучшения:
-  `reliability`/`quality`/`economy`/`features`/`scale`). При автозаписи допустимо пусто/`unknown`.
-- **BR-3 — Автозапись ≥2–3 типов отклонений.** Из кода, best-effort, в детерминированных
-  choke-point: (а) провал гейта / откат на `development` (reviewer REQUEST_CHANGES, tester FAIL,
-  staging/deploy FAILED), (б) HOLD merge-актора / regression-guard HOLD, (в) транзиент-ретрай
-  (Gitea-merge `405`/`5xx`, Anthropic `Overloaded`/agent-timeout requeue). Дополнительно желательно
-  (г) post-deploy `DEGRADED` (урок «деплой OK / прод сломан», слой-3, ET-8) с атрибуцией.
-- **BR-4 — Read-only выборка.** HTTP-эндпоинт `GET /lessons` (фильтры: тип/статус/repo/work_item,
-  лимит) + read-only блок `lessons` в `GET /queue` (сводка). Только чтение.
-- **BR-5 — Ручная запись.** HTTP-эндпоинт `POST /lessons` (+ публичный helper) — оператор/Стрим
-  кладёт урок руками, в т.ч. с проставленной атрибуцией.
-- **BR-6 — Обновление урока.** Возможность сменить статус / проставить атрибуцию / привязать
-  задачу после создания (helper/эндпоинт `POST /lessons/{id}` или поля в `POST /lessons`) — чтобы
-  ретроспективщик/человек позже классифицировал автозаписанный `unknown`.
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — never-raise (критично, self-hosting).** Сбой записи/чтения урока **никогда** не роняет
-  и не тормозит конвейер. Любая ошибка детектора/записи → лог WARNING + продолжение основного
-  потока. Журнал — наблюдатель, не участник пайплайна.
-- **NFR-2 — Kill-switch.** Флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`). `False` →
-  автозапись и эндпоинты инертны (нулевая регрессия, поведение конвейера байт-в-байт прежнее).
-- **NFR-3 — Аддитивность / изоляция enduro.** Только новая таблица + новый leaf + новые эндпоинты +
-  тонкие врезки. `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict-ключи / схема
-  существующих таблиц — **байт-в-байт не тронуты**. Общая БД: enduro-trails не затронут.
-- **NFR-4 — Restart-safe / идемпотентность таблицы.** `CREATE TABLE IF NOT EXISTS` + `_ensure_column`
-  (паттерн `repo_freeze`/`coverage_baseline`) — безопасно на живой БД, повторный старт без эффекта.
-- **NFR-5 — Лёгкость.** Запись — один `INSERT`, чтение — простые `SELECT` (общий хост впритык:
-  RAM 171Mi free, диск 92%). Никаких фоновых потоков/сканов.
-- **NFR-6 — Схема-forward-proof.** Колонки атрибуции добавлены сразу (BR-2), чтобы не
-  переделывать схему на живой БД, когда появится ретроспективщик.
-- **NFR-7 — Self-hosting безопасность.** Модуль только пишет/читает БД и отдаёт JSON — не
-  деплоит, не рестартит прод, не трогает `main`, не порождает процессы/сеть.
-
-## 6. Допущения и ограничения
-- Журнал уроков — **исключение** из правила «наблюдатель отделён от наблюдаемого» (§2 эпика): это
-  историческая память петли, не realtime-мониторинг → допустимо в БД орка; запись best-effort.
-- Точки автозаписи привязаны к существующим choke-point: `stage_engine._handle_qg_failure_rollbacks`
-  (откаты), `merge_gate` (HOLD/transient-классификатор ORCH-093), `launcher` (timeout/requeue
-  транзиентов). Архитектор уточняет точный набор и сигнатуры врезок.
-- Набор значений `lesson_type` / `attribution` / `target_domain` — конвенция (строковые слаги),
-  не enum-констрейнт БД (forward-compatible; новый тип не требует миграции).
-- Общая прод-БД с enduro: любое поле repo-scoped, фильтрация на уровне выборки.
-
-## 7. Критерии успеха
-Таблица `lessons` создаётся идемпотентно на старте; автозаписаны ≥2–3 типа отклонений из реального
-прогона; `GET /lessons` и `POST /lessons` работают; атрибутивные колонки присутствуют и
-проставляемы; kill-switch выключает всё без регрессии; `pytest tests/ -q` зелёный; доки+CHANGELOG
-обновлены. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-- Врезка детектора в горячий путь конвейера → риск регрессии при сбое записи. Митигация: NFR-1
-  never-raise + kill-switch.
-- Рост таблицы со временем (автозапись на каждом откате/ретрае). Митигация: лёгкие строки;
-  будущая ретенция — вне объёма, отметить в `10-tech-risks.md` (архитектор).
-- Недооформленная схема атрибуции → переделка на живой БД. Митигация: BR-2/NFR-6 (колонки сразу).
-- Детали и архитектурные развилки (точные точки врезки, индексы, дедуп автозаписей) — задача
-  архитектора (`06-adr/`, `10-tech-risks.md`).

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

@@ -1,163 +0,0 @@
----
-work_item: ORCH-098
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-098 — FND: машинный журнал уроков
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование/решения (точные сигнатуры врезок, индексы, дедуп, ретенция) — задача
-> архитектора (`06-adr`).
-
-## 1. Сводка изменения
-
-Ввести **машинный журнал уроков** — аддитивную таблицу `lessons` + чистый leaf-модуль
-`src/lessons.py` (never-raise, kill-switch) по образцу `serial_gate.py` / `coverage_gate.py` /
-`metrics.py`. Модуль несёт: helper записи урока (`record`), read-only выборку (`get_lessons`),
-обновление (`update_lesson`), `snapshot()` для `GET /queue`. Автозапись ≥2–3 типов отклонений —
-тонкими best-effort врезками в существующие choke-point `stage_engine.py` / `merge_gate.py` /
-`launcher.py`. Два новых HTTP-эндпоинта (`GET /lessons`, `POST /lessons`) в `main.py`. Схема несёт
-**сразу** нуллабельные колонки атрибуции (требование Славы 10.06). Конвейер (`STAGE_TRANSITIONS` /
-`QG_CHECKS` / `check_*` / machine-verdict) — **не тронут**; enduro — не затронут.
-
-## 2. Задействованные модули / пути
-| Путь | Действие |
-|------|----------|
-| `src/db.py` | изменить — `CREATE TABLE IF NOT EXISTS lessons` в `init_db()`; helper'ы `record_lesson` / `get_lessons` / `update_lesson` / `lessons_snapshot` |
-| `src/lessons.py` | **создать** — leaf: `record(...)`, `get(...)`, `update(...)`, `snapshot()`, константы `LessonType`/`Attribution`/`Domain`, `applies()`, never-raise |
-| `src/config.py` | изменить — флаг `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`) + опц. `lessons_query_limit_default` |
-| `src/stage_engine.py` | изменить — best-effort врезка `lessons.record(...)` в `_handle_qg_failure_rollbacks` (откаты gate-fail) и в ветку post-deploy `DEGRADED` → freeze |
-| `src/merge_gate.py` | изменить — best-effort врезка в HOLD/regression-guard HOLD и в транзиент-классификатор (`_classify_merge_response == "transient"` / merge-retry-исчерпан) |
-| `src/agents/launcher.py` | изменить — best-effort врезка при timeout-kill / транзиент-requeue агента |
-| `src/main.py` | изменить — эндпоинты `GET /lessons`, `POST /lessons` (+опц. `POST /lessons/{id}`); блок `lessons` в `GET /queue` |
-| `tests/test_lessons.py` | **создать** — unit + integration (см. `04-test-plan.yaml`) |
-| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | изменить — документация |
-
-## 3. Функциональные требования
-
-### FR-1 — Таблица `lessons` (BR-1, BR-2)
-Аддитивная идемпотентная таблица в `db.init_db()` (паттерн `repo_freeze`/`coverage_baseline`):
-
-```sql
-CREATE TABLE IF NOT EXISTS lessons (
-    id            INTEGER PRIMARY KEY AUTOINCREMENT,
-    created_at    TEXT NOT NULL DEFAULT (datetime('now')),
-    updated_at    TEXT,
-    -- тип отклонения (slug-конвенция, не enum-констрейнт)
-    lesson_type   TEXT NOT NULL,
-    -- контекст
-    work_item_id  TEXT,
-    task_id       INTEGER,
-    stage         TEXT,
-    agent         TEXT,
-    repo          TEXT,
-    -- анализ
-    root_cause    TEXT,
-    suggestion    TEXT,
-    -- статус
-    status        TEXT NOT NULL DEFAULT 'new',   -- new|in_progress|closed|linked
-    related_task  TEXT,
-    -- АТРИБУЦИЯ (BR-2, Слава 10.06) — нуллабельные, заполняются позже
-    attribution   TEXT,                          -- platform|project|both|unknown
-    target_repo   TEXT,                          -- кого касается (orchestrator|enduro-trails|…)
-    target_domain TEXT,                          -- reliability|quality|economy|features|scale
-    -- учёт
-    source        TEXT,                          -- auto|manual
-    detail        TEXT                           -- свободный JSON/текст (payload детектора)
-);
-CREATE INDEX IF NOT EXISTS idx_lessons_type_status ON lessons (lesson_type, status);
-CREATE INDEX IF NOT EXISTS idx_lessons_repo        ON lessons (repo);
-```
-Колонки атрибуции создаются **сразу** и нуллабельны (NFR-6). На уже созданной таблице новые
-колонки добавляются `_ensure_column` (forward-safe). Никакого `enum`-констрейнта — значения суть
-конвенция строковых слагов (forward-compatible).
-
-### FR-2 — Helper записи `lessons.record(...)` (BR-3, BR-5; NFR-1)
-Сигнатура (уточняет архитектор), напр.:
-`record(lesson_type, *, work_item_id=None, task_id=None, stage=None, agent=None, repo=None,
-root_cause=None, suggestion=None, status="new", related_task=None, attribution=None,
-target_repo=None, target_domain=None, source="auto", detail=None) -> int | None`.
-- При `lessons_enabled is False` → немедленный no-op (`None`), без обращения к БД.
-- Оборачивает `db.record_lesson` в `try/except` → при любой ошибке `logger.warning` + `None`
-  (**never-raise**, NFR-1). Возвращает `id` вставленной строки при успехе.
-- `source="auto"` для детекторов, `source="manual"` для ручной записи.
-
-### FR-3 — Автозапись отклонений (BR-3)
-Минимум 2–3 типа, best-effort (каждая врезка обёрнута/делегирует в never-raise `record`):
-- **FR-3a — gate-fail / rollback** — в `stage_engine._handle_qg_failure_rollbacks`: при откате на
-  `development` (reviewer `REQUEST_CHANGES`, tester `check_tests_passed` FAIL, staging FAILED,
-  deploy FAILED) → `record("gate_failure", stage=…, agent=…, work_item_id=…, repo=…,
-  root_cause=reason)`. Тип откатной причины → в `detail`/`root_cause`.
-- **FR-3b — merge HOLD / regression-guard HOLD** — в `merge_gate` (путь HOLD `_handle_merge_verify`
-  / `main_regressed_alerts_total` инкремент) → `record("merge_hold", …, root_cause=…)`.
-- **FR-3c — транзиент-ретрай** — в `merge_gate._classify_merge_response`-ветке `"transient"`
-  (Gitea `405`/`5xx`) и/или `launcher` timeout-kill / транзиент-requeue (Anthropic `Overloaded`) →
-  `record("transient_retry", …, detail=<код/причина>)`.
-- **FR-3d (желательно) — post-deploy DEGRADED** — в ветке `stage_engine`, где post-deploy
-  `DEGRADED`/rollback ведёт к `set_repo_freeze` (ORCH-088/021) → `record("deploy_degraded", …,
-  attribution=None|"unknown", target_repo=repo)` — урок «деплой OK / прод сломан» (слой-3, ET-8),
-  атрибуцию проставит ретроспективщик/человек позже.
-
-Дедуп/частота автозаписи (чтобы не плодить дубли на ретраях) — решение архитектора (например,
-ключ `work_item_id+stage+lesson_type` в окне); если не реализуется в v1 — отметить в `10-tech-risks.md`.
-
-### FR-4 — Read-only выборка (BR-4)
-`db.get_lessons(*, lesson_type=None, status=None, repo=None, work_item_id=None, limit=N) ->
-list[dict]` (параметризованный `SELECT … ORDER BY id DESC LIMIT ?`). `lessons.get(...)` —
-never-raise обёртка → `[]` при ошибке. `lessons.snapshot()` — лёгкая сводка (счётчики по
-типу/статусу, последние N) для `GET /queue`, never-raise → `{}`.
-
-### FR-5 — Ручная запись + обновление (BR-5, BR-6)
-- `POST /lessons` (тело JSON) → `lessons.record(..., source="manual")`. Возвращает `{id}`.
-- `POST /lessons/{id}` (или поля в `POST /lessons`) → `lessons.update(id, status=…,
-  attribution=…, target_repo=…, target_domain=…, related_task=…, root_cause=…, suggestion=…)` →
-  `db.update_lesson` (`UPDATE … SET … updated_at=datetime('now')`). Позволяет ретроспективщику/
-  человеку классифицировать автозаписанный `unknown`. never-raise.
-
-### FR-6 — Kill-switch + изоляция (NFR-2, NFR-3)
-`lessons_enabled=False` → `record`/`get`/`update`/`snapshot` инертны, эндпоинты возвращают
-`{"enabled": false}` (паттерн `metrics_endpoint_enabled`), врезки no-op. Поведение конвейера —
-байт-в-байт прежнее. enduro не затронут (общая БД, аддитивная таблица).
-
-## 4. Изменения API
-Новые эндпоинты в `src/main.py` (стиль `GET /queue` / `POST /coverage/baseline`):
-- **`GET /lessons`** — read-only выборка. Query: `type`, `status`, `repo`, `work_item`, `limit`
-  (дефолт из конфига). Ответ: `{"enabled": bool, "lessons": [ {…строка…} ]}`. Всегда `200`.
-- **`POST /lessons`** — ручная запись. Тело: `lesson_type` (обяз.) + опциональные поля контекста/
-  анализа/атрибуции. Ответ: `{"id": <int>}` или `{"enabled": false}`.
-- **(опц.) `POST /lessons/{id}`** — обновление статуса/атрибуции/привязки задачи. Ответ `{"ok": bool}`.
-- `GET /queue` — добавить read-only ключ `"lessons": lessons.snapshot()` (рядом с `serial_gate`/
-  `coverage`/`bug_fast_track`). Существующие ключи — без изменений.
-
-`GET /health` / `GET /status` / `GET /metrics` / прочие эндпоинты — **байт-в-байт прежние**.
-
-## 5. Изменения схемы БД
-**Новая аддитивная таблица `lessons`** (FR-1) + два индекса, всё `IF NOT EXISTS` / `_ensure_column`.
-Существующие таблицы (`tasks`/`jobs`/`agent_runs`/`events`/`job_deps`/`repo_freeze`/
-`coverage_baseline`/`tracker_messages`) — **не тронуты**. Колонки атрибуции — сразу, нуллабельные
-(BR-2/NFR-6). Restart-safe, идемпотентно, безопасно на живой общей прод-БД (enduro не затронут).
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Журнал уроков — наблюдатель, **не** Quality Gate. `QG_CHECKS` / `check_*` /
-machine-verdict-ключи (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/
-`coverage_status:`) — байт-в-байт не тронуты. Журнал не влияет на продвижение по стадиям.
-
-## 7. Совместимость / регресс
-- **Kill-switch** `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`): `False` → полная
-  инертность, нулевая регрессия.
-- **never-raise** на всех публичных функциях и врезках (NFR-1) — сбой журнала не роняет конвейер.
-- **Аддитивно**: только новая таблица + leaf + эндпоинты + тонкие врезки; ничего существующего не
-  переписывается.
-- **Изоляция enduro**: общая БД, новая таблица; репо-скоуп через поле/фильтр выборки.
-- **Обратимость**: выключение флага возвращает прод к доресурсному поведению мгновенно.
-- **Self-hosting безопасность** (NFR-7): модуль не деплоит/не рестартит прод/не трогает `main`/без
-  процессов/сети.
-- **Артефакты pipeline:** задача создаёт/обновляет стандартный пакет (`01`–`04` + `06-adr` от
-  архитектора, `12`/`13`/`14`/`15`/`17`/`18` по ходу конвейера). Сам журнал — БД-сущность, не
-  номерной артефакт.

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

@@ -1,123 +0,0 @@
----
-work_item: ORCH-098
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-098 — FND: машинный журнал уроков
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что
-считается провалом). Reviewer/tester проверяет их буквально по файлам репозитория и тестам.
-
----
-
-## AC-1 — Аддитивная таблица уроков
-
-**Условие:** `db.init_db()` создаёт таблицу `lessons` идемпотентно.
-- **PASS:** в `src/db.py` есть `CREATE TABLE IF NOT EXISTS lessons (...)` со всеми полями
-  (`lesson_type`, контекст `work_item_id/task_id/stage/agent/repo`, `root_cause`, `suggestion`,
-  `status`+`related_task`, `created_at`); повторный `init_db()` не падает и не дублирует; таблица
-  создаётся на общей прод-БД без изменения существующих таблиц.
-- **FAIL:** таблицы нет / создаётся не идемпотентно / отсутствует любое поле из BR-1 / меняется
-  схема существующей таблицы.
-
----
-
-## AC-2 — Поля атрибуции присутствуют с самого начала
-
-**Условие:** схема `lessons` несёт нуллабельные колонки атрибуции (требование Славы 10.06).
-- **PASS:** колонки `attribution` (`platform`/`project`/`both`/`unknown`), `target_repo`,
-  `target_domain` существуют сразу, нуллабельны, допускают пустое/`unknown` при автозаписи и
-  проставляются позже через update.
-- **FAIL:** хотя бы одной из трёх колонок нет в исходной схеме / колонка `NOT NULL` без дефолта /
-  атрибуцию нельзя проставить после создания записи.
-
----
-
-## AC-3 — Автозапись ≥2–3 типов отклонений
-
-**Условие:** из кода автоматически (best-effort, `source="auto"`) пишутся минимум 2–3 типа уроков.
-- **PASS:** есть врезки `lessons.record(...)` минимум в двух-трёх точках из:
-  `stage_engine._handle_qg_failure_rollbacks` (gate-fail/откат), `merge_gate` (HOLD/transient),
-  `launcher` (timeout/transient-requeue); интеграционный тест подтверждает появление строки в
-  `lessons` после смоделированного отклонения.
-- **FAIL:** автозаписи нет / реализован <2 типов / врезка может бросить исключение в горячий путь.
-
----
-
-## AC-4 — Read-only выборка
-
-**Условие:** уроки можно прочитать через эндпоинт и сводку в `GET /queue`.
-- **PASS:** `GET /lessons` возвращает `200` с массивом уроков, поддерживает фильтры
-  (type/status/repo/work_item/limit); `GET /queue` содержит read-only блок `lessons`; ни один
-  путь чтения не мутирует данные.
-- **FAIL:** эндпоинта нет / не фильтрует / чтение мутирует данные / блока в `/queue` нет.
-
----
-
-## AC-5 — Ручная запись и обновление
-
-**Условие:** оператор/Стрим кладёт урок руками и может его доклассифицировать.
-- **PASS:** `POST /lessons` создаёт урок (`source="manual"`, можно задать атрибуцию); обновление
-  (`POST /lessons/{id}` или поля) меняет `status`/`attribution`/`target_*`/`related_task` и
-  стампит `updated_at`.
-- **FAIL:** ручной записи нет / нельзя проставить атрибуцию / нельзя обновить автозаписанный урок.
-
----
-
-## AC-6 — never-raise (сбой журнала не роняет конвейер)
-
-**Условие:** любая ошибка записи/чтения урока изолирована от пайплайна.
-- **PASS:** все публичные функции `src/lessons.py` и все врезки обёрнуты так, что исключение БД/
-  любого источника → `logger.warning` + безопасный дефолт (`None`/`[]`/`{}`); юнит-тест с
-  замоканной падающей БД подтверждает, что вызывающий код (откат/HOLD/retry) не падает.
-- **FAIL:** исключение из журнала пробивается в `stage_engine`/`merge_gate`/`launcher`/эндпоинт.
-
----
-
-## AC-7 — Kill-switch и нулевая регрессия
-
-**Условие:** `lessons_enabled=False` делает функционал инертным.
-- **PASS:** при `False` `record`/`get`/`update`/`snapshot` — no-op (без обращения к БД), эндпоинты
-  отдают `{"enabled": false}`, врезки не пишут; поведение конвейера и `GET /queue` (помимо нового
-  блока) — байт-в-байт прежнее; enduro-trails не затронут.
-- **FAIL:** при `False` журнал что-то пишет/ломает / меняется поведение конвейера / затронут enduro.
-
----
-
-## AC-8 — Инварианты конвейера не тронуты
-
-**Условие:** изменение не касается машины стадий и гейтов.
-- **PASS:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, функции `check_*`, machine-verdict-ключи и
-  схема существующих таблиц — **диффом не затронуты**; журнал не влияет на продвижение по стадиям.
-- **FAIL:** изменён любой из перечисленных артефактов / журнал участвует в решении гейта.
-
----
-
-## AC-9 — Тесты, документация, CHANGELOG
-
-**Условие:** изменение проверено и задокументировано.
-- **PASS:** `pytest tests/ -q` зелёный (включая новый `tests/test_lessons.py` с unit+integration);
-  обновлены `CLAUDE.md` + `docs/architecture/README.md`; в задаче есть `06-adr/` (архитектор);
-  `CHANGELOG.md` дополнен.
-- **FAIL:** тесты падают / нет покрытия новой логики / документация или CHANGELOG не обновлены.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1 |
-| AC-2 | BR-2 / FR-1 / NFR-6 |
-| AC-3 | BR-3 / FR-2 / FR-3 |
-| AC-4 | BR-4 / FR-4 |
-| AC-5 | BR-5 / BR-6 / FR-5 |
-| AC-6 | NFR-1 / FR-2 |
-| AC-7 | NFR-2 / NFR-3 / FR-6 |
-| AC-8 | NFR-3 / FR-6 |
-| AC-9 | NFR-1…NFR-7 (верификация) |

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

@@ -1,91 +0,0 @@
-work_item: ORCH-098
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Журнал уроков: таблица, автозапись отклонений, выборка, ручная запись, never-raise"
-framework: pytest
-scope: >
-  Покрывается: создание аддитивной таблицы lessons (идемпотентность, поля атрибуции),
-  helper записи record(), автозапись из choke-point (gate-fail/HOLD/transient), read-only
-  выборка get_lessons + snapshot, ручная запись/обновление, kill-switch, never-raise.
-  Вне покрытия: ретроспективщик (E2), приоритизатор (E3), автоклассификация атрибуции,
-  слой-3 детекция здоровья продукта.
-notes: >
-  Тесты используют изолированную временную SQLite-БД (фикстура init_db во временном файле).
-  Полный регресс tests/ должен оставаться зелёным. Self-hosting: журнал never-raise — ни один
-  тест не должен показать, что сбой записи урока роняет конвейер.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "init_db() создаёт таблицу lessons идемпотентно (двойной вызов не падает, нет дублей); присутствуют все поля BR-1."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Схема lessons несёт нуллабельные колонки атрибуции attribution/target_repo/target_domain; запись без них проходит (NULL/unknown), update проставляет их позже."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "lessons.record() вставляет строку с переданными полями (source=auto/manual), возвращает id; created_at заполняется."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "never-raise: при замоканной падающей БД record/get/update/snapshot возвращают None/[]/{} и не бросают исключение (logger.warning)."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "kill-switch: при lessons_enabled=False record/get/update/snapshot инертны (no-op, без обращения к БД)."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "get_lessons фильтрует по type/status/repo/work_item и соблюдает limit; порядок ORDER BY id DESC."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "update_lesson меняет status/attribution/target_*/related_task и стампит updated_at; несуществующий id безопасен."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-08
-    type: integration
-    description: "Автозапись gate-fail: смоделированный откат на development в _handle_qg_failure_rollbacks создаёт строку lessons type=gate_failure с контекстом (stage/agent/work_item/repo)."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-09
-    type: integration
-    description: "Автозапись transient/HOLD: транзиент-ветка merge_gate (или timeout/requeue launcher) пишет урок type=transient_retry/merge_hold; сбой записи не ломает основной путь (never-raise в горячем пути)."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "GET /lessons возвращает 200 с массивом и фильтрами; GET /queue содержит read-only блок lessons; чтение не мутирует данные."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-11
-    type: integration
-    description: "POST /lessons создаёт ручной урок (source=manual, с атрибуцией); POST /lessons/{id} обновляет его; при lessons_enabled=False эндпоинты отдают {enabled:false}."
-    module: tests/test_lessons.py
-    expected: PASS
-
-  - id: TC-12
-    type: unit
-    description: "Инварианты конвейера не тронуты: STAGE_TRANSITIONS/QG_CHECKS/machine-verdict-ключи неизменны (структурный анти-регресс по составу реестра)."
-    module: tests/test_lessons.py
-    expected: PASS

docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md

@@ -1,244 +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-001: Машинный журнал уроков `lessons` — аддитивная таблица + observer-leaf
-
-Work Item: **ORCH-098** — FND: машинный журнал уроков (структурированная база отклонений конвейера)
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0034-lessons-journal.md`** (решение
-кросс-каттинговое: новый компонент + новая таблица на общей прод-БД + фундамент эпика
-саморазвития).
-
-## Статус
-Proposed
-
-## Контекст
-
-ORCH-098 — шаг 1 («Фундамент», F2) эпика саморазвития: формализовать свободнотекстовые «уроки»
-из `memory/` в **машинную структурированную таблицу отклонений конвейера**, на которой позже
-встанут ретроспективщик (E2), приоритизатор RICE (E3) и Стрим. BRD/TRZ уже зафиксировали состав
-полей, набор эндпоинтов и структуру leaf-модуля; нормативное требование Славы 10.06 — колонки
-**атрибуции** в схеме **с самого начала** (нуллабельные), чтобы не переделывать схему на живой
-общей прод-БД.
-
-Сверено по коду (recon):
-- **Образец observer-leaf**: `src/serial_gate.py`, `src/coverage_gate.py`, `src/metrics.py` —
-  чистые leaf'ы, импортируют только `config`+`db`, `applies(repo)`-first, never-raise, `snapshot()`
-  для `GET /queue`.
-- **БД-паттерн**: `db.get_db() -> sqlite3.Connection` (`row_factory=sqlite3.Row`, `.close()` в
-  `finally`); `db.init_db()` — `executescript` с `CREATE TABLE IF NOT EXISTS …`; идемпотентные
-  миграции `_ensure_column(conn, table, column, decl)` (`src/db.py:341`). Эталон аддитивной таблицы
-  — `repo_freeze`, `coverage_baseline`; атомарный helper — `ratchet_coverage_baseline` (`db.py:251`).
-- **Choke-point'ы автозаписи** (точные сигнатуры):
-  - `stage_engine._handle_qg_failure_rollbacks(task_id, current_stage, repo, work_item_id, branch,
-    agent, qg_name, reason, result)` (`src/stage_engine.py:728`) — все нужные поля контекста
-    локально доступны.
-  - post-deploy `DEGRADED → set_repo_freeze` (`src/stage_engine.py:~1993`) — доступны `repo`,
-    `work_item_id`, `branch`, локально собранный `reason`.
-  - `merge_gate._handle_merge_verify(task_id, repo, work_item_id, branch, result)`
-    (`src/merge_gate.py:1588`); ветка HOLD ставит `result.note="merge-not-verified-hold"` (~`:1695`).
-  - `merge_gate._classify_merge_response(repo, branch, index, status_code) -> "transient"|"terminal"`
-    (`src/merge_gate.py:811`).
-  - `launcher._watchdog`/`stop_process` (timeout-kill) и `launcher._finalize_transient(job_id, agent,
-    run_id, exit_code, job, retry_after)` (`src/agents/launcher.py:997`) — транзиент-requeue с
-    бюджетом `transient_attempts`.
-- **Конфиг-паттерн**: pydantic `BaseSettings` с авто-биндингом `ORCH_*`; пары `*_enabled` (bool) +
-  `*_repos` (CSV); `is_self_hosting_repo(repo)` (`src/qg/checks.py:520`).
-
-«Как есть» не годится: уроки в `memory/` не машиночитаемы — нельзя считать паттерны, нельзя
-приоритизировать. Нужна структурированная таблица, но врезанная в **горячий путь** конвейера, что
-на self-hosting прод-инстансе с общей БД (enduro-trails) требует жёсткой изоляции.
-
-## Решение
-
-### Сводка
-
-Ввести **аддитивную идемпотентную таблицу `lessons`** + **чистый observer-leaf `src/lessons.py`**
-(never-raise, kill-switch) по образцу `serial_gate`/`coverage_gate`/`metrics`. Leaf несёт
-`record()` / `get()` / `update()` / `snapshot()`. Автозапись 4 типов отклонений — тонкими
-best-effort врезками в существующие choke-point. Два-три HTTP-эндпоинта в `main.py`. Колонки
-атрибуции — в схеме сразу, нуллабельные. **Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
-machine-verdict) и схемы существующих таблиц — байт-в-байт не тронуты; enduro не затронут.**
-
-### D1 — Таблица `lessons`: аддитивная, идемпотентная, forward-proof (BR-1, BR-2; AC-1, AC-2)
-
-`CREATE TABLE IF NOT EXISTS lessons (…)` в `db.init_db()` (паттерн `repo_freeze`):
-
-```sql
-CREATE TABLE IF NOT EXISTS lessons (
-    id            INTEGER PRIMARY KEY AUTOINCREMENT,
-    created_at    TEXT NOT NULL DEFAULT (datetime('now')),
-    updated_at    TEXT,
-    lesson_type   TEXT NOT NULL,                 -- slug-конвенция, НЕ enum-констрейнт
-    work_item_id  TEXT,
-    task_id       INTEGER,
-    stage         TEXT,
-    agent         TEXT,
-    repo          TEXT,
-    root_cause    TEXT,
-    suggestion    TEXT,
-    status        TEXT NOT NULL DEFAULT 'new',    -- new|in_progress|closed|linked
-    related_task  TEXT,
-    attribution   TEXT,                           -- platform|project|both|unknown (NULLABLE)
-    target_repo   TEXT,                           -- orchestrator|enduro-trails|… (NULLABLE)
-    target_domain TEXT,                           -- reliability|quality|economy|features|scale (NULLABLE)
-    source        TEXT,                           -- auto|manual
-    detail        TEXT                            -- свободный JSON/текст (payload детектора)
-);
-CREATE INDEX IF NOT EXISTS idx_lessons_type_status ON lessons (lesson_type, status);
-CREATE INDEX IF NOT EXISTS idx_lessons_repo        ON lessons (repo);
-CREATE INDEX IF NOT EXISTS idx_lessons_wi_type     ON lessons (work_item_id, lesson_type);
-```
-
-**Инварианты:**
-- Все три колонки **атрибуции создаются сразу и нуллабельны** (NFR-6, требование Славы 10.06): на
-  живой уже-существующей таблице добавляются через `_ensure_column(conn, "lessons", "<col>",
-  "TEXT")` — forward-safe, restart-safe, без миграции данных.
-- **Нет `enum`/`CHECK`-констрейнта** на `lesson_type`/`attribution`/`target_domain` — значения суть
-  конвенция строковых слагов (новый тип урока не требует миграции схемы; §6 допущений BRD).
-- **Третий индекс `idx_lessons_wi_type`** добавлен сверх двух из TRZ — обслуживает дедуп-запрос
-  автозаписи (D4) одним indexed-lookup'ом (NFR-5).
-
-DDL-хелперы в `db.py` (стиль `coverage_baseline`): `record_lesson(...) -> int|None`,
-`get_lessons(...) -> list[dict]`, `update_lesson(id, **fields) -> bool`, `lessons_snapshot() -> dict`.
-Каждый открывает `get_db()` и закрывает в `finally`.
-
-### D2 — Observer-leaf `src/lessons.py`: scope **kill-switch only**, НЕ repo-gated (BR-3/4/5/6; NFR-1/2/7)
-
-Чистый leaf, импортирует только `config`+`db` (lazy `notifications` при необходимости); **никогда
-не импортирует `stage_engine`/`merge_gate`/`launcher`** (анти-цикл). Публичный контракт:
-
-```python
-def record(lesson_type, *, work_item_id=None, task_id=None, stage=None, agent=None, repo=None,
-           root_cause=None, suggestion=None, status="new", related_task=None, attribution=None,
-           target_repo=None, target_domain=None, source="auto", detail=None) -> int | None
-def get(*, lesson_type=None, status=None, repo=None, work_item_id=None, limit=None) -> list[dict]
-def update(lesson_id, **fields) -> bool
-def snapshot() -> dict
-```
-
-**Ключевое решение D2 — расхождение с шаблоном гейт-leaf'ов: журнал НЕ скоупится по repo.**
-В отличие от `serial_gate`/`coverage_gate`/`bug_fast_track` (которые *действуют* на конкретный репо
-и потому имеют пару `*_repos`), журнал — **observer-only**: запись строки никогда не влияет на
-пайплайн ни одного репо. Поэтому:
-- единственный регулятор — глобальный kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`,
-  дефолт `True`); **`lessons_repos` НЕ вводится**;
-- recorder пишет уроки про **любой** репо (включая enduro-trails) — урок про деградацию деплоя
-  enduro ценен для петли самообучения; репо-скоуп терял бы этот сигнал;
-- `repo`-разрез — на уровне **выборки** (`get(repo=…)`, фильтр `snapshot()`), как зафиксировано в
-  §6 BRD «репо-скоуп через поле/фильтр выборки».
-- **enduro не затронут (NFR-3):** запись observer-строки про enduro не меняет ни одной стадии/гейта
-  enduro — это чистая память орка.
-
-**never-raise (NFR-1, AC-6):** при `lessons_enabled is False` каждая функция — немедленный no-op
-(`record→None`, `get→[]`, `update→False`, `snapshot→{}`) **без обращения к БД**. При `True` — тело в
-`try/except Exception → logger.warning(...) + безопасный дефолт`. Журнал **не** деплоит, **не**
-рестартит прод, **не** трогает `main`, **не** порождает процессов/сети (NFR-7).
-
-### D3 — Точки автозаписи: 4 детектора, тонкая врезка одним вызовом (BR-3; FR-3; AC-3)
-
-Каждая врезка = локальный импорт + один вызов `lessons.record(...)`, обёрнутый в защитный
-`try/except` (паттерн post-deploy-freeze-врезки `stage_engine.py:~1993`), чтобы даже ошибка импорта
-не пробилась в горячий путь:
-
-| Тип (`lesson_type`) | Choke-point | Контекст врезки |
-|---|---|---|
-| `gate_failure` | `stage_engine._handle_qg_failure_rollbacks` (после решения об откате на `development`) | `work_item_id, task_id, stage=current_stage, agent, repo, root_cause=reason, detail=qg_name` |
-| `merge_hold` | `merge_gate._handle_merge_verify` (ветка HOLD, `result.note="merge-not-verified-hold"`) | `work_item_id, task_id, repo, stage="deploy", root_cause="merge-not-verified-hold"` |
-| `transient_retry` | **budget-exhaustion**: `merge_gate` (merge-retry исчерпан) и/или `launcher._finalize_transient` (исчерпан `transient_attempts`) | `work_item_id?, repo, agent?, stage?, detail=<код/причина>` |
-| `deploy_degraded` | `stage_engine` post-deploy `DEGRADED → set_repo_freeze` | `work_item_id, repo, stage="deploy", root_cause=reason, attribution="unknown", target_repo=repo, target_domain="reliability"` |
-
-Все врезки — `source="auto"`. Это **4 типа > минимума 2–3** (BR-3). `(г) deploy_degraded` (желаемый
-по TRZ) включён как полноценный детектор: это урок слоя-3 «деплой OK / прод сломан» (ET-8),
-ради которого Слава и потребовал атрибуцию.
-
-### D4 — Дедуп автозаписи: один indexed-SELECT в окне (BR-3; FR-3 «решение архитектора»; NFR-5)
-
-Риск: транзиент-ретраи/повторные откаты плодят дубли. Решение — **дешёвый дедуп только для
-`source="auto"`** внутри `record()`: перед `INSERT` — один indexed-lookup
-```sql
-SELECT 1 FROM lessons
-WHERE work_item_id = ? AND lesson_type = ? AND (stage IS ? OR ?)  -- stage-match
-  AND created_at > datetime('now', ?)                            -- '-<window> seconds'
-LIMIT 1;
-```
-по индексу `idx_lessons_wi_type` (D1). Найдено → no-op (`return None`, лог DEBUG). Окно —
-`lessons_dedup_window_s` (env `ORCH_LESSONS_DEDUP_WINDOW_S`, дефолт `3600`). **`source="manual"`
-дедуп НЕ проходит** (оператор/Стрим всегда может записать). Это один лёгкий `SELECT` (NFR-5), без
-фоновых сканов.
-
-**Доп. контроль флуда на самом шумном детекторе:** `transient_retry` пишется **только на исчерпании
-бюджета ретраев** (а не на каждом backoff) — это и есть ценный сигнал «транзиенты исчерпаны», а не
-шум каждой попытки. Так флуд гасится в источнике до дедупа.
-
-### D5 — Эндпоинты `main.py`: read-only выборка + ручная запись/обновление (BR-4/5/6; FR-4/5; AC-4/5)
-
-Стиль `GET /queue` / `POST /coverage/baseline`, все never-raise, при выключенном флаге →
-`{"enabled": false}`:
-- **`GET /lessons`** — query `type/status/repo/work_item/limit` (дефолт `lessons_query_limit_default`,
-  напр. 100) → `{"enabled": bool, "lessons": [...]}`, всегда `200`, только чтение.
-- **`POST /lessons`** — тело JSON, `lesson_type` обязателен → `lessons.record(..., source="manual")`
-  → `{"id": <int>}`.
-- **`POST /lessons/{id}`** — `lessons.update(id, status=…, attribution=…, target_repo=…,
-  target_domain=…, related_task=…, root_cause=…, suggestion=…)` → `{"ok": bool}`; стампит
-  `updated_at=datetime('now')`. Позволяет ретроспективщику/человеку доклассифицировать
-  автозаписанный `unknown`.
-- **`GET /queue`** — добавить read-only ключ `"lessons": lessons.snapshot()` рядом с
-  `serial_gate`/`coverage`. `snapshot()` — лёгкие `GROUP BY`-счётчики (по типу/статусу) + последние
-  N. Существующие ключи `/queue` и эндпоинты `/health|/status|/metrics` — **байт-в-байт прежние**.
-
-### D6 — Изоляция от конвейера и гейтов (NFR-3; AC-8)
-
-`STAGE_TRANSITIONS`, реестр `QG_CHECKS`, функции `check_*`, machine-verdict-ключи
-(`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`/`coverage_status:`) и
-схемы существующих таблиц — **диффом не затрагиваются**. Журнал — наблюдатель, **не** Quality Gate;
-он не участвует в решении о продвижении по стадиям. Никаких новых/изменённых QG-checks (FR-6).
-
-## Альтернативы
-
-- **Repo-скоуп `lessons_repos` (как у гейтов)** — отвергнуто: журнал observer-only, не действует на
-  репо; скоуп терял бы ценные enduro-уроки. Скоуп — на выборке (D2).
-- **Без дедупа в v1 (TRZ это допускает)** — отвергнуто как дефолт: транзиент-ретраи реально
-  флудят таблицу; дешёвый indexed-дедуп (D4) дешевле, чем последующая чистка. Бюджет-exhaustion +
-  окно дают двойную защиту при одном `SELECT`.
-- **Запись `transient_retry` на каждом backoff** — отвергнуто: шум; ценен факт исчерпания бюджета.
-- **Отдельная БД/файл для журнала** — отвергнуто: лишняя зависимость; общая SQLite-БД с аддитивной
-  таблицей соответствует принципу «минимум зависимостей» и паттерну `repo_freeze`/`coverage_baseline`.
-- **Фоновый агрегатор/ретенция-крон в v1** — отвергнуто: NFR-5 (без фоновых потоков/сканов);
-  ретенция — будущая задача (см. `10-tech-risks.md` TR-2).
-- **ORM** — отвергнуто: raw SQL достаточно (принцип «без ORM, если хватает raw SQL»).
-
-## Последствия
-
-- **+** Уроки становятся машиночитаемыми — фундамент для E2/E3/Стрим; атрибуция forward-proof
-  (колонки сразу, переделки живой БД не будет).
-- **+** Нулевая регрессия: kill-switch + never-raise + чистая аддитивность; enduro не затронут;
-  конвейер байт-в-байт прежний.
-- **+** Следует проверенному additive-observer-leaf шаблону (`serial_gate`/`coverage_gate`/`metrics`/
-  `cancel`/`bug_fast_track`) — низкий архитектурный риск, не требует `arch:major-change` (см.
-  `10-tech-risks.md` сводный вывод).
-- **−** Рост таблицы со временем (автозапись на отклонениях). Митигейшн: лёгкие строки + дедуп (D4) +
-  budget-exhaustion-only для транзиентов; ретенция — TR-2 (будущее).
-- **−** Лёгкое усложнение `record()` дедуп-запросом. Митигейшн: один indexed-SELECT, только для
-  `auto`, под окном; для `manual` пропускается.
-- **Откат:** `ORCH_LESSONS_ENABLED=false` → весь функционал инертен мгновенно (no-op, нулевая
-  регрессия). Полный откат — revert диффа; таблица `lessons` остаётся пустой/неиспользуемой,
-  существующих таблиц не касается.
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-098/01-brd.md`
-- TRZ: `docs/work-items/ORCH-098/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-098/03-acceptance-criteria.md`
-- Data: `docs/work-items/ORCH-098/08-data-requirements.md`
-- Infra: `docs/work-items/ORCH-098/07-infra-requirements.md`
-- Risks: `docs/work-items/ORCH-098/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0034-lessons-journal.md`
-- Сверено по коду: `src/serial_gate.py`, `src/coverage_gate.py`, `src/metrics.py`, `src/db.py:251,341`,
-  `src/stage_engine.py:728,~1993`, `src/merge_gate.py:811,1588`, `src/agents/launcher.py:997`,
-  `src/main.py` (`GET /queue`, `POST /coverage/baseline`), `src/qg/checks.py:520`.

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

@@ -1,45 +0,0 @@
----
-work_item: ORCH-098
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-098 — машинный журнал уроков `lessons`
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable. Топология **не меняется**; файл создан для аудитопригодности (новая env-переменная).
-
-## I-1. Топология / окружения
-**N/A.** Новых контейнеров/портов/сети/томов нет. Таблица `lessons` живёт в существующей общей
-SQLite-БД (тот же том `./data`), эндпоинты обслуживаются текущим процессом `orchestrator` (8500) /
-`orchestrator-staging` (8501). Принцип «всё в Docker на одном сервере mva154» — соблюдён.
-
-## I-2. Переменные окружения / секреты
-Новые env (pydantic `BaseSettings`, авто-биндинг `ORCH_*`), все с безопасными дефолтами:
-
-| Env | Дефолт | Назначение |
-|---|---|---|
-| `ORCH_LESSONS_ENABLED` | `true` | kill-switch журнала (NFR-2); `false` → полная инертность |
-| `ORCH_LESSONS_DEDUP_WINDOW_S` | `3600` | окно дедупа автозаписи (ADR-001 D4) |
-| `ORCH_LESSONS_QUERY_LIMIT_DEFAULT` | `100` | дефолтный `limit` для `GET /lessons` |
-
-**`lessons_repos` СОЗНАТЕЛЬНО не вводится** — журнал observer-only и не скоупится по репо
-(ADR-001 D2). Секретов нет. `.env.example` дополнить тремя ключами для документируемости (значения —
-дефолтные, не секреты).
-
-## I-3. Деплой / рестарт
-- Изменение применяется штатным конвейером: **обязательный staging-гейт (8501) перед прод-деплоем**
-  орка (self-hosting инвариант). Прод-контейнер **не рестартить вне процедуры деплоя стадии**
-  `deploy`/`Confirm Deploy` (ORCH-059) — конвейер всех проектов встанет.
-- Таблица `lessons` создаётся идемпотентно при старте (`init_db()`) — на первом штатном запуске
-  нового образа, **без отдельной ручной миграции** (restart-safe, NFR-4). На живой БД enduro не
-  затронут.
-- Откат — `ORCH_LESSONS_ENABLED=false` (мгновенная инертность) либо revert образа.
-
-## I-4. CI/CD
-**Без изменений** в `.gitea/workflows/`. Новые тесты `tests/test_lessons.py` исполняются штатным
-шагом `pytest tests/ -q`. Новых системных/pip-зависимостей нет (raw SQL на stdlib `sqlite3`).

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

@@ -1,76 +0,0 @@
----
-work_item: ORCH-098
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-098 — машинный журнал уроков `lessons`
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable: задача **добавляет** одну таблицу на общую прод-БД. Схемы существующих таблиц —
-> не затрагиваются.
-
-## Изменения схемы БД
-
-**Новая аддитивная таблица `lessons`** + три индекса, создаются идемпотентно в `db.init_db()`
-(`CREATE TABLE IF NOT EXISTS` / `CREATE INDEX IF NOT EXISTS`), restart-safe (паттерн `repo_freeze`,
-`coverage_baseline`). На уже существующей таблице новые/будущие колонки добавляются через
-`_ensure_column(conn, "lessons", "<col>", "<decl>")` (`src/db.py:341`) — forward-safe, без миграции
-данных. DDL — см. ADR-001 D1.
-
-Существующие таблицы (`tasks`/`jobs`/`agent_runs`/`events`/`job_deps`/`repo_freeze`/
-`coverage_baseline`/`tracker_messages`) — **байт-в-байт не тронуты** (NFR-3, AC-8).
-
-## Новые/изменённые сущности
-
-Сущность **`lesson`** — одна запись структурированного отклонения конвейера. Колонки:
-
-| Колонка | Тип | Null | Назначение |
-|---|---|---|---|
-| `id` | INTEGER PK AUTOINCREMENT | — | суррогатный ключ |
-| `created_at` | TEXT `DEFAULT datetime('now')` | NOT NULL | момент записи |
-| `updated_at` | TEXT | NULL | момент последнего `update` |
-| `lesson_type` | TEXT | NOT NULL | slug-тип (`gate_failure`/`merge_hold`/`transient_retry`/`deploy_degraded`/…) |
-| `work_item_id` | TEXT | NULL | контекст: задача (`ORCH-NNN`/`ET-NNN`) |
-| `task_id` | INTEGER | NULL | контекст: внутренний id задачи |
-| `stage` | TEXT | NULL | контекст: стадия конвейера |
-| `agent` | TEXT | NULL | контекст: агент-роль |
-| `repo` | TEXT | NULL | контекст: репозиторий, **разрез выборки** |
-| `root_cause` | TEXT | NULL | анализ: корневая причина (если известна) |
-| `suggestion` | TEXT | NULL | анализ: предложенное улучшение (если есть) |
-| `status` | TEXT `DEFAULT 'new'` | NOT NULL | `new`/`in_progress`/`closed`/`linked` |
-| `related_task` | TEXT | NULL | связанная заведённая задача |
-| `attribution` | TEXT | **NULL** | **АТРИБУЦИЯ:** `platform`/`project`/`both`/`unknown` |
-| `target_repo` | TEXT | **NULL** | **АТРИБУЦИЯ:** кого касается улучшение |
-| `target_domain` | TEXT | **NULL** | **АТРИБУЦИЯ:** `reliability`/`quality`/`economy`/`features`/`scale` |
-| `source` | TEXT | NULL | `auto` (детектор) / `manual` (оператор/Стрим) |
-| `detail` | TEXT | NULL | свободный JSON/текст — payload детектора |
-
-**Инварианты данных:**
-- Три колонки **атрибуции** (`attribution`/`target_repo`/`target_domain`) присутствуют в исходной
-  схеме, **нуллабельны** (требование Славы 10.06, NFR-6, AC-2) — при автозаписи допустимо
-  пусто/`unknown`; проставляются позже через `update` (AC-5).
-- **Без `enum`/`CHECK`-констрейнтов** — значения `lesson_type`/`attribution`/`target_domain` суть
-  конвенция строковых слагов (forward-compatible: новый тип не требует миграции).
-- Индексы: `idx_lessons_type_status (lesson_type, status)` — выборка/snapshot; `idx_lessons_repo
-  (repo)` — репо-разрез; `idx_lessons_wi_type (work_item_id, lesson_type)` — дедуп автозаписи
-  (ADR-001 D4).
-
-## Совместимость данных / миграции
-
-- **Аддитивно / идемпотентно / restart-safe:** только новая таблица + индексы; повторный `init_db()`
-  не падает и не дублирует (NFR-4).
-- **Общая прод-БД (self-hosting):** таблица создаётся на том же файле БД, что обслуживает
-  orchestrator и enduro-trails. Уроки про любой репо хранятся в одной таблице; **изоляция enduro** —
-  таблица аддитивна и не участвует в пайплайне enduro (NFR-3); репо-разрез — поле `repo` + фильтр
-  выборки (ADR-001 D2).
-- **Объём строки** — короткие текстовые поля; `detail` — компактный payload. Запись — один `INSERT`,
-  чтение — простой параметризованный `SELECT … ORDER BY id DESC LIMIT ?` (NFR-5; общий хост впритык:
-  RAM/диск).
-- **Ретенция / архивация** — вне объёма v1; тренд роста и будущая стратегия — `10-tech-risks.md`
-  (TR-2).
-- **Миграция исторических уроков из `memory/`** — вне объёма (BRD §2).

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

@@ -1,39 +0,0 @@
----
-work_item: ORCH-098
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-098 — машинный журнал уроков `lessons`
-
-Work Item: **ORCH-098** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | Врезка детектора в горячий путь конвейера (`stage_engine`/`merge_gate`/`launcher`) бросает исключение → регрессия пайплайна на self-hosting прод-инстансе (встанет конвейер всех проектов, в т.ч. enduro). | Низ. | Выс. | **NFR-1 never-raise**: `lessons.record` полностью self-contained `try/except → None`; каждая врезка дополнительно обёрнута защитным `try/except` (паттерн post-deploy-freeze, `stage_engine.py:~1993`), ловит даже ошибку импорта. **NFR-2 kill-switch** `ORCH_LESSONS_ENABLED=false` → no-op. Юнит-тест с замоканной падающей БД (AC-6). |
-| TR-2 | Неограниченный рост таблицы `lessons` (автозапись на каждом откате/HOLD/деградации) на впритык-хосте (диск 92%). | Сред. | Низ. | Лёгкие строки (короткий текст); **дедуп D4** (один indexed-SELECT в окне) + **`transient_retry` только на budget-exhaustion** гасят флуд в источнике. Ретенция/архивация — отдельная будущая задача (вне объёма v1); тренд наблюдаем через `snapshot()` в `GET /queue`. |
-| TR-3 | Недооформленная схема атрибуции → переделка схемы на живой общей прод-БД, когда появится ретроспировщик (E2). | Низ. | Сред. | **BR-2/NFR-6**: три нуллабельные колонки атрибуции (`attribution`/`target_repo`/`target_domain`) в схеме **сразу**; `update`/`POST /lessons/{id}` позволяет доклассифицировать `unknown` позже без миграции. Слаги без `enum`-констрейнта → новые значения не требуют DDL. |
-| TR-4 | Дубли автозаписи на ретраях/повторных откатах искажают будущий pattern-анализ. | Сред. | Низ. | **Дедуп D4** для `source="auto"`: indexed `SELECT` по `idx_lessons_wi_type` в окне `ORCH_LESSONS_DEDUP_WINDOW_S` перед `INSERT`. `manual` дедуп не проходит. Если в реальном прогоне дедуп окажется слишком строгим/слабым — окно конфигурируемо без передеплоя логики. |
-| TR-5 | Случайное касание инвариантов конвейера (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы существующих таблиц) при врезках. | Низ. | Выс. | Врезки — строго аддитивные одиночные вызовы; **AC-8** требует «диффом не затронуты». Reviewer проверяет дифф перечисленных артефактов. Журнал не участвует в решении гейта (FR-6). |
-| TR-6 | Эндпоинт `POST /lessons`/`/lessons/{id}` как непреднамеренный мутатор/вектор (запись в прод-БД без аутентификации). | Низ. | Сред. | Пишет **только** в аддитивную таблицу `lessons` (не трогает `tasks`/`jobs`/гейты); never-raise; `enabled:false` при выключенном флаге. Тот же уровень доступа, что у существующего `POST /coverage/baseline`. Дальнейшее ужесточение доступа — общая инфра-тема, вне объёма ORCH-098. |
-
-## Сводный вывод
-
-Доминирующий класс рисков — **изоляция наблюдателя от горячего пути конвейера на self-hosting
-прод-инстансе** (TR-1, TR-5): высокое влияние при низкой вероятности, полностью покрыто
-проверенной связкой *never-raise + kill-switch + чистая аддитивность*, идентичной уже работающим
-leaf'ам (`serial_gate`/`coverage_gate`/`metrics`/`bug_fast_track`). Вторичный класс — **рост/шум
-данных** (TR-2/TR-4): низкое влияние, смягчён лёгкими строками, дедупом и budget-exhaustion-записью;
-ретенция вынесена в будущее.
-
-**Эскалация не требуется.** Несмотря на формально «новый компонент + новая таблица», изменение
-следует устоявшемуся **additive-observer-leaf** шаблону, **не трогает машину стадий, гейты и схемы
-существующих таблиц**, полностью обратимо флагом → метка `arch:major-change` **не выставляется**,
-возврат в анализ (`back-to:analysis`) не нужен. Остаточный риск для прод-конвейера — **низкий**.

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

@@ -1,71 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-098
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-098
-version: 1
----
-
-# Review ORCH-098 — FND: машинный журнал уроков
-
-## Summary
-
-Реализация полностью соответствует ТЗ (`02-trz.md`), критериям приёмки (`03-acceptance-criteria.md`)
-и ADR-001/adr-0034. Введён чистый observer-leaf `src/lessons.py` (never-raise, единственный
-kill-switch `lessons_enabled`, без repo-скоупа — по решению D2), аддитивная идемпотентная таблица
-`lessons` с нуллабельными колонками атрибуции сразу (NFR-6, требование Славы 10.06), 4 типа
-автозаписи best-effort, дедуп для `auto`, три HTTP-эндпоинта + блок `lessons` в `GET /queue`.
-
-**Инварианты конвейера не тронуты (AC-8):** `src/stages.py` (`STAGE_TRANSITIONS`), `src/qg/checks.py`
-(`QG_CHECKS`/`check_*`), `src/merge_gate.py`, machine-verdict-ключи и схемы существующих таблиц —
-**диффом не затронуты** (подтверждено `git diff --name-only`). `tests/test_lessons.py` (TC-01…TC-12,
-13 тестов) — **зелёный** локально. Документация обновлена в том же PR.
-
-Все findings — P2/P3 (advisory), блокеров нет.
-
-## Findings
-
-### P0 — Blocker
-- Нет.
-
-### P1 — Must fix
-- Нет.
-
-### P2 — Should fix
-- [ ] **Кросс-задачный дедуп `transient_retry` теряет сигнал.** Врезка в
-  `launcher._finalize_transient` (`src/agents/launcher.py:~1024`) передаёт `task_id`, но **не**
-  `work_item_id` и **не** `stage` → ключ дедупа `db.lessons_recent_dup_exists` становится
-  `(work_item_id IS NULL, lesson_type='transient_retry', stage IS NULL)`. В окне
-  `lessons_dedup_window_s` (дефолт 1ч) **разные** задачи, исчерпавшие бюджет ретраев, схлопываются в
-  одну запись — теряется урок про вторую задачу. Поскольку `task_id` локально доступен, дедуп-ключ
-  стоило бы доопределять им при `work_item_id is None` (или включать `task_id` в ключ дедупа).
-  Это observer/best-effort (не влияет на конвейер, AC-3 формально выполнен — 4 типа автозаписи
-  работают), потому не блокер, но ослабляет ценность самого сигнала, ради которого фича вводится.
-  Ссылка: ADR-001 D4 («ключ `work_item_id+stage+lesson_type`»).
-
-### P3 — Nice to have
-- [ ] **Мелкая неточность ADR vs код.** `06-adr/ADR-001` (D3, таблица) и `adr-0034` указывают
-  choke-point `merge_hold` как `merge_gate._handle_merge_verify`, фактически `_handle_merge_verify`
-  живёт в `src/stage_engine.py` (туда и врезан `merge_hold`; `merge_gate.py` диффом не тронут).
-  Функционально корректно; рекомендуется поправить адрес в ADR для трассировки. Также
-  `transient_retry` в `merge_gate` (merge-retry exhausted) не реализован — но ADR формулирует это как
-  «**and/or** launcher», т.е. опционально; реализация через launcher достаточна.
-
-## Документация
-
-**Обновлена полностью в том же PR — ось «документация» PASS:**
-- `CLAUDE.md` — добавлен раздел «Машинный журнал уроков (ORCH-098)» (D1–D5, флаги, инвариант).
-- `docs/architecture/README.md` — компонент «Lessons journal», строка таблицы `lessons` в разделе
-  схемы БД, три новых эндпоинта в таблице API, обновлена строка `GET /queue` (`+ lessons (ORCH-098)`).
-- `docs/architecture/adr/adr-0034-lessons-journal.md` — сквозной ADR (новый).
-- `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md` — локальный ADR (присутствует).
-- `CHANGELOG.md` — запись `[Unreleased]` с разбивкой D1–D5 + регресс.
-- `README.md` «Известные ограничения» — пунктов, закрываемых этой задачей, нет (ORCH-079 N/A).
-
-Изменение `src/` ⇒ требование «документация = golden source» выполнено; основание для
-`REQUEST_CHANGES` по оси документации отсутствует.

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

@@ -1,86 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-098
-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-098
----
-
-# Test Report — ORCH-098 — FND: машинный журнал уроков
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (pytest-cov 5.0.0, anyio 4.13.0, asyncio 0.23.8)
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-098-fnd/` (ветка `feature/ORCH-098-fnd`)
-- Дата: 2026-06-10
-
-## Предусловия
-- Review-вердикт (`12-review.md`): **APPROVED** (блокеров нет, все findings P2/P3 advisory). ✅
-- Smoke API (read-only, prod 8500):
-  - `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
-  - `GET /status` → `200`, активные задачи отдаются (ORCH-098 в стадии `testing`). ✅
-  - `GET /queue` → `200`; присутствует блок **`serial_gate`** (ORCH-088) ✅ и **`auto_labels`**
-    (ORCH-089) ✅ в полезной нагрузке — смок-регресса нет.
-  - Примечание: прод-контейнер 8500 несёт ещё не задеплоенный код (без блока `lessons` в `/queue`) —
-    это ожидаемо (ORCH-098 не выкатан в прод), на смок-вердикт не влияет.
-
-## Результаты — покрытие тест-плана (`04-test-plan.yaml`)
-
-Прогон: `cd /repos/_wt/orchestrator/feature_ORCH-098-fnd && pytest tests/ -v --tb=short`.
-Все TC из тест-плана исполнены и сопоставлены с критериями приёмки (`03-acceptance-criteria.md`).
-
-| TC ID | Тип | Описание | AC | Тест (`tests/test_lessons.py`) | Результат |
-|-------|-----|----------|----|--------------------------------|-----------|
-| TC-01 | unit | `init_db()` создаёт `lessons` идемпотентно, все поля BR-1 | AC-1 | `test_tc01_table_idempotent_and_fields` | PASS |
-| TC-02 | unit | Нуллабельные колонки атрибуции `attribution/target_repo/target_domain`, update проставляет позже | AC-2 | `test_tc02_attribution_columns_nullable_and_settable` | PASS |
-| TC-03 | unit | `record()` вставляет строку (source auto/manual), возвращает id, `created_at` заполнен | AC-3/AC-5 | `test_tc03_record_inserts_and_returns_id` | PASS |
-| TC-04 | unit | never-raise при падающей БД: `record/get/update/snapshot` → `None/[]/{}` без исключения | AC-6 | `test_tc04_never_raise_on_db_error` | PASS |
-| TC-05 | unit | kill-switch `lessons_enabled=False` — инертность (no-op, без БД) | AC-7 | `test_tc05_kill_switch_inert` | PASS |
-| TC-06 | unit | `get_lessons` фильтрует type/status/repo/work_item, limit, `ORDER BY id DESC` | AC-4 | `test_tc06_filters_limit_order` | PASS |
-| TC-07 | unit | `update_lesson` меняет status/attribution/target_*/related_task + `updated_at`; неизв. id безопасен | AC-5 | `test_tc07_update_and_unknown_id` | PASS |
-| TC-07b | unit | (доп.) дедуп `source=auto` в окне; `source=manual` всегда проходит | AC-3/AC-5 | `test_tc07b_auto_dedup_and_manual_passthrough` | PASS |
-| TC-08 | integration | Автозапись gate-fail: откат в `_handle_qg_failure_rollbacks` → строка `gate_failure` с контекстом | AC-3 | `test_tc08_gate_failure_autorecord` | PASS |
-| TC-09 | integration | Автозапись transient/HOLD: транзиент-ветка пишет урок; сбой записи не ломает горячий путь | AC-3/AC-6 | `test_tc09_transient_autorecord_and_never_raise` | PASS |
-| TC-10 | integration | `GET /lessons` → 200 с фильтрами; `GET /queue` несёт блок `lessons`; чтение не мутирует | AC-4 | `test_tc10_get_endpoints` | PASS |
-| TC-11 | integration | `POST /lessons` (manual+атрибуция), `POST /lessons/{id}` обновляет; при выключенном флаге `{enabled:false}` | AC-5/AC-7 | `test_tc11_post_endpoints_and_killswitch` | PASS |
-| TC-12 | unit | Инварианты конвейера не тронуты: `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict неизменны | AC-8 | `test_tc12_pipeline_invariants_untouched` | PASS |
-
-**Итог покрытия:** 12/12 TC тест-плана исполнены и сопоставлены с AC-1…AC-9 → PASS.
-AC-9 (полный регресс зелёный + новый `test_lessons.py`) подтверждён прогоном ниже.
-
-## Вывод pytest
-
-Полный регресс (`tests/`):
-```
-================== 1630 passed, 1 warning in 71.78s (0:01:11) ==================
-```
-(единственный warning — PydanticDeprecatedSince20 в `src/config.py`, не связан с ORCH-098,
-предсуществующий.)
-
-Целевой модуль (`tests/test_lessons.py`):
-```
-collected 13 items
-tests/test_lessons.py::test_tc01_table_idempotent_and_fields PASSED      [  7%]
-tests/test_lessons.py::test_tc02_attribution_columns_nullable_and_settable PASSED [ 15%]
-tests/test_lessons.py::test_tc03_record_inserts_and_returns_id PASSED    [ 23%]
-tests/test_lessons.py::test_tc04_never_raise_on_db_error PASSED          [ 30%]
-tests/test_lessons.py::test_tc05_kill_switch_inert PASSED                [ 38%]
-tests/test_lessons.py::test_tc06_filters_limit_order PASSED              [ 46%]
-tests/test_lessons.py::test_tc07_update_and_unknown_id PASSED            [ 53%]
-tests/test_lessons.py::test_tc07b_auto_dedup_and_manual_passthrough PASSED [ 61%]
-tests/test_lessons.py::test_tc08_gate_failure_autorecord PASSED          [ 69%]
-tests/test_lessons.py::test_tc09_transient_autorecord_and_never_raise PASSED [ 76%]
-tests/test_lessons.py::test_tc10_get_endpoints PASSED                    [ 84%]
-tests/test_lessons.py::test_tc11_post_endpoints_and_killswitch PASSED    [ 92%]
-tests/test_lessons.py::test_tc12_pipeline_invariants_untouched PASSED    [100%]
-======================== 13 passed, 1 warning in 1.55s =========================
-```
-
-## Итог
-**PASS** — полный регресс зелёный (1630 passed), все 12 TC тест-плана исполнены и сопоставлены
-с критериями приёмки, smoke API read-only (`/health`/`/status`/`/queue`) в норме (блоки
-`serial_gate` и `auto_labels` присутствуют). Задача готова к переходу на `deploy-staging`.

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

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

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

@@ -1,30 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-098
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T07:55:10Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live staging stand (`orchestrator-staging`, port 8501),
-run canonically inside the container via `docker exec` (ORCH-048). **All REAL pipeline checks
-passed** → `staging_status: SUCCESS` (exit code 0).
-
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — 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
-
-## Results
-
-- **Block A (SMOKE)**: PASS — A1 `/health` 200 `status=ok`; A2 `/queue` 200 (counts/max_concurrency/resilience present); A3 `ORCH_STAGING=true`.
-- **Block B (ACCESS)**: PASS — B4 Plane sandbox project accessible (sandbox=YES); B5 Gitea `orchestrator-sandbox` accessible, push=true; B6 Registry isolated (sandbox=YES, prod-ET=NO, prod-ORCH=NO).
-- **Block C (E2E)**: C7 Create issue in Plane SANDBOX PASS; C8 Trigger pipeline via `/webhook/plane` PASS; C9a/C9b FAIL but **waived** (sandbox-infra: SANDBOX bot accounts not members of the sandbox Plane project — not a pipeline regression, ORCH-061).
-
-RESULT: 8/10 checks PASS. REAL failed: **none**. SANDBOX_INFRA failed (waived): C9a, C9b.
-
-Cleanup: test Plane issue deleted (HTTP 204); no branch created (nothing to delete).

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

@@ -1,7 +0,0 @@
-# Business Request: FND/F1a: лёгкий /metrics в орке — отдать сырьё (стадии/очередь/agent-liveness/cost)
-
-Work Item ID: ORCH-099
-
-## Description
-
-TBD

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

@@ -1,141 +0,0 @@
----
-work_item: ORCH-099
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-099 — FND/F1a: лёгкий `/metrics` в орке (отдать сырьё)
-
-Work Item: **ORCH-099** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-Задача — фундаментный кирпич **F1a** домена 0 «Фундамент» эпика автономного саморазвития
-(`docs/epics/self-evolution.md`). Архитектурная рамка наблюдаемости **зафиксирована заказчиком
-(Слава, 09.06)** и для аналитика — установленный факт, не предмет переизобретения:
-
-- **C-1/C-1б:** наблюдатель ОТДЕЛЁН от наблюдаемого. Мониторинг живёт в **отдельном sidecar-контейнере**
-  (`watchdog/`, рантайм — свой Dockerfile + сервис в compose), а НЕ внутри орка. Если орк
-  упал/завис/съел память — sidecar жив и репортит это.
-- **C-2/C-3:** без внешнего плеча, тонкий стек (хост впритык: RAM 171Mi free, диск 92% — НЕ
-  Grafana/Prometheus).
-- **Разделение ответственности:** орк отдаёт **только сырьё** (лёгкий read-only `/metrics` — свои
-  внутренние данные, которые знает только он сам), БЕЗ логики мониторинга/порогов/алертов/хранения.
-  Мозг (пороги, алерты, свой Telegram-канал, история) — это **F1b (sidecar)**, отдельная задача.
-
-**Боль, которую закрывает задача.** Сегодня у орка нет машинного «сырья» о самом себе в одной
-точке. `/health` отдаёт лишь `{"status":"ok"}`, `/status` — список активных задач, `/queue` —
-богатый, но «человеческий» снимок очереди, перемешанный с конфигом демонов. Ни один из них не даёт
-sidecar'у структурированный, стабильный КОНТРАКТ для детекта: застрявшая стадия, зависший агент
-(liveness по pid/CPU), деградация очереди (breaker open, рост failed), всплеск стоимости токенов.
-Без этого источника весь домен наблюдаемости (F1b и далее) слеп и не может стартовать.
-
-**Self-hosting контекст.** Орк дорабатывает сам себя; прод-контейнер общий для всех проектов.
-`/metrics` обязан быть **строго read-only** и **never-raise** — он не должен ни при каких входных
-данных уронить или притормозить прод, обслуживающий enduro-trails.
-
-## 2. Объём (scope)
-
-### В объёме
-- Новый **read-only** HTTP-эндпоинт (`GET /metrics`), отдающий JSON-снимок сырья о самом орке.
-- Четыре раздела сырья: **активные стадии задач**, **очередь jobs**, **agent-liveness**,
-  **стоимость/токены** (`agent_runs`).
-- Новый leaf-модуль `src/metrics.py` — сборка снимка из БД (чистый, never-raise, без побочных
-  эффектов), по образцу `snapshot()`-функций (`serial_gate`/`task_deps`/`cancel`).
-- Документирование формата `/metrics` как **контракта для sidecar (F1b)** в
-  `docs/architecture/README.md` + запись в `CHANGELOG.md`.
-- Pytest-покрытие: структура ответа, never-raise, read-only-инвариант.
-
-### Вне объёма
-- ❌ Любая логика мониторинга: пороги, алерты, Telegram, оценка «застрял/завис», хранение истории
-  — это **F1b (sidecar)**.
-- ❌ Сам sidecar-контейнер (`watchdog/`, Dockerfile, compose-сервис) — отдельная задача F1b.
-- ❌ Хостовые/контейнерные/внешние метрики (диск/RAM/CPU хоста, docker.sock, пинг
-  Plane/Gitea/Anthropic) — их собирает sidecar, не орк.
-- ❌ Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / схемы БД / любых machine-verdict
-  ключей.
-- ❌ Дашборд/UI (упомянут в F1 эпика как отдельный последующий шаг).
-- ❌ Прометей-совместимый text-формат — отдаём JSON (контракт под конкретный sidecar; OpenMetrics
-  не требование заказчика).
-
-## 3. Заинтересованные стороны
-
-- **Заказчик:** Слава (рамки наблюдаемости F1, эпик саморазвития).
-- **Прямой потребитель контракта:** будущий sidecar **F1b** (`watchdog/`) — читает `/metrics` по
-  HTTP. Задача F1b **заблокирована** этой (ORCH-099 — источник контракта).
-- **Затрагивается:** прод-инстанс орка (общий с enduro-trails) — поэтому жёсткое требование
-  read-only/never-raise.
-- **Принимает результат:** reviewer/tester конвейера + Слава как владелец рамок.
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 — Эндпоинт сырья.** Орк предоставляет HTTP `GET /metrics`, отдающий JSON с четырьмя
-  разделами: (a) активные стадии задач, (b) очередь jobs, (c) agent-liveness, (d) стоимость/токены.
-  Состав полей каждого раздела — см. TRZ §3 (FR-1…FR-4).
-- **BR-2 — Стадии задач.** По каждой незавершённой задаче отдаётся `work_item`, текущая `stage` и
-  «как давно в стадии» (секунды) — сырьё для детекта застреваний sidecar'ом.
-- **BR-3 — Очередь jobs.** Отдаются счётчики по статусам (`queued`/`running`/`failed`/…), глубина
-  очереди, информация о ретраях и состояние circuit-breaker'а — сырьё для детекта деградации.
-- **BR-4 — Agent-liveness.** По каждому running-job отдаётся `agent`, `run_id`, `pid`, `runtime_s`
-  и сырьё для alive-детекта (CPU-тики pid либо данные, по которым sidecar посчитает CPU-дельту).
-  sidecar — арбитр «жив/завис»; орк лишь поставляет факты.
-- **BR-5 — Стоимость/токены.** Отдаётся текущая (по running-job) и агрегированная стоимость/токены
-  из `agent_runs` (`cost_usd`, `input/output/cache_*` токены) — сырьё для cost-наблюдаемости (D3).
-- **BR-6 — Аддитивность.** Существующие `/health`, `/status`, `/queue` остаются байт-в-байт прежними
-  по контракту; `/metrics` добавляется рядом, ничего не ломая.
-- **BR-7 — Документированный контракт.** Формат `/metrics` зафиксирован в
-  `docs/architecture/README.md` как стабильный контракт для sidecar (F1b) + `CHANGELOG.md`.
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 — Read-only.** Эндпоинт НИЧЕГО не мутирует: не пишет в БД, не запускает/останавливает
-  процессы, не рестартит, не дёргает внешние API. Только SELECT'ы + чтение in-memory-снимков
-  демонов.
-- **NFR-2 — Never-raise (по полям).** Любая ошибка при сборе отдельного поля/раздела → это поле
-  получает `null` (или раздел — безопасный дефолт), но эндпоинт **возвращает 200 и валидный JSON**,
-  никогда не 500. Эталон — `serial_gate.snapshot()` с fallback в `except`.
-- **NFR-3 — Лёгкость.** Только быстрые запросы к локальной SQLite + чтение уже посчитанных
-  in-memory снапшотов; без тяжёлых вычислений, без сетевых вызовов, без сканирования файлов/git.
-  Цель — единичные мс на типовом объёме (десятки задач/jobs).
-- **NFR-4 — Self-hosting-безопасность.** Эндпоинт физически не способен повлиять на прод-конвейер
-  (следствие NFR-1) — безопасен на общем инстансе с enduro-trails.
-- **NFR-5 — Совместимость БД/гейтов.** `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
-  machine-verdict ключи / схема БД — НЕ трогаются. Задача читает существующие таблицы
-  (`tasks`/`jobs`/`agent_runs`) и существующие in-memory снапшоты.
-- **NFR-6 — Стабильность контракта.** Формат — аддитивный и версионируемый (поле `schema_version`),
-  чтобы будущие расширения не ломали уже написанный sidecar.
-
-## 6. Допущения и ограничения
-
-- **Данные уже есть в БД.** Все нужные поля присутствуют: `tasks(stage, work_item_id, updated_at,
-  created_at)`, `jobs(status, attempts, max_attempts, transient_attempts, available_at, pid,
-  run_id)`, `agent_runs(agent, started_at, finished_at, model, effort, cost_usd, input_tokens,
-  output_tokens, cache_read_tokens, cache_creation_tokens)`. **Новые колонки/таблицы не нужны.**
-- **Breaker-состояние — in-memory** (`queue_worker.worker.status()` / `CircuitBreaker.snapshot()`);
-  читается без БД.
-- **CPU-тики pid** читаются из `/proc/<pid>/stat` (Linux прод-контейнер). Допущение: контейнер
-  Linux; при отсутствии/гонке (процесс уже умер) — поле `null` (NFR-2), НЕ ошибка. Это согласуется
-  с рамкой C-1: «орк лёг → endpoint недоступен = сам сигнал тревоги» — детект делает sidecar.
-- **Арбитраж liveness — на стороне sidecar.** Орк не решает «завис/жив»; он лишь отдаёт `pid`,
-  `runtime_s` и (по возможности) CPU-тики; sidecar считает дельту между опросами.
-- **Формат — JSON**, не OpenMetrics/Prometheus (рамка C-3: тонкий кастомный sidecar, не Prometheus).
-
-## 7. Критерии успеха
-
-`GET /metrics` отдаёт лёгкий, read-only, never-raise JSON с четырьмя разделами сырья;
-`/health`/`/status`/`/queue` не сломаны; формат задокументирован как контракт sidecar; pytest
-зелёный. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
-
-## 8. Риски
-
-- Гонка чтения `/proc/<pid>/stat` (процесс умер между выборкой job и чтением proc) → закрывается
-  NFR-2 (`null`, не ошибка).
-- Расхождение контракта `/metrics` и ожиданий sidecar (F1b) → закрывается BR-7 (контракт в одном
-  репо, документирован) + `schema_version` (NFR-6).
-- Соблазн «протащить» в `/metrics` логику алертинга → закрывается scope-границей (вне объёма) и
-  NFR-1.
-
-Детальная оценка технических рисков — `10-tech-risks.md` (заполняет архитектор).

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

@@ -1,173 +0,0 @@
----
-work_item: ORCH-099
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-099 — FND/F1a: лёгкий `/metrics` в орке (отдать сырьё)
-
-Work Item: **ORCH-099** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **конкретные изменения к реализации**, выведенные из BRD и фактического кода.
-> Архитектурное обоснование/решения (формат полей liveness, способ чтения CPU, версионирование
-> контракта) — задача архитектора (`06-adr/`).
-
-## 1. Сводка изменения
-
-Добавить read-only HTTP-эндпоинт `GET /metrics`, отдающий JSON-снимок «сырья» о самом орке для
-будущего sidecar (F1b): активные стадии задач, очередь jobs, agent-liveness, стоимость/токены.
-Логика сборки выносится в **новый leaf-модуль** `src/metrics.py` (чистая функция-сборщик, never-raise,
-без побочных эффектов — по образцу `serial_gate.snapshot()`/`task_deps.snapshot()`/`cancel.snapshot()`).
-Эндпоинт в `src/main.py` — тонкая обёртка над сборщиком, в том же стиле, что `GET /queue`
-(`src/main.py`, дикт с разделами). Никаких изменений `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схемы
-БД/machine-verdict ключей. Только чтение существующих таблиц и существующих in-memory-снапшотов.
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `src/metrics.py` | **создать** — leaf-сборщик снимка из БД (`build_metrics() -> dict`, never-raise) |
-| `src/main.py` | изменить — добавить `@app.get("/metrics")` (тонкая обёртка над `metrics.build_metrics()`) |
-| `src/db.py` | изменить (при необходимости) — добавить read-only helper(ы) для агрегатов `agent_runs` (напр. `agent_cost_totals()`); существующие `job_status_counts`/`get_running_jobs`/`recent_jobs`/`get_active_tasks_for_reconcile` переиспользуются как есть |
-| `docs/architecture/README.md` | изменить — задокументировать контракт `/metrics` (формат для sidecar F1b) |
-| `CHANGELOG.md` | изменить — запись `## [Unreleased]` (ORCH-099) |
-| `tests/test_metrics.py` | **создать** — pytest на структуру/never-raise/read-only |
-
-**Существующие источники данных (переиспользуются, НЕ дублируются):**
-- `db.get_active_tasks_for_reconcile()` — задачи с `stage != 'done'` + вычисленный `age_s`
-  (секунды с `updated_at`). Базис для раздела стадий.
-- `db.job_status_counts()` — `{queued, running, done, failed}` из `jobs`.
-- `db.get_running_jobs()` — running-jobs с `running_age_s`, плюс джойн на `agent_runs` (`agent`,
-  `run_id`, `pid`, `started_at`, `model`, `effort`). Базис для liveness.
-- `queue_worker.worker.status()` / `worker.breaker.snapshot()` — breaker-состояние in-memory
-  (`state`/`consecutive_transient`/`pause_remaining_s`), `max_concurrency`, `poll_interval`.
-
-## 3. Функциональные требования
-
-### FR-1 — Раздел `stages` (активные стадии задач) — BR-2
-
-Список активных (незавершённых) задач. По каждой:
-- `work_item` — `tasks.work_item_id`.
-- `stage` — `tasks.stage` (значение слоя A, машина стадий).
-- `age_in_stage_s` — целое; секунды с `tasks.updated_at` (= момент последней смены стадии).
-  Источник вычисления — SQL `CAST(strftime('%s','now') - strftime('%s', updated_at) AS INTEGER)`,
-  как в `get_active_tasks_for_reconcile`.
-- `repo` — `tasks.repo` (sidecar мультипроектный; нужно отличать orchestrator от enduro-trails).
-- (опционально) `task_id`, `created_age_s` (общий возраст задачи).
-
-Инвариант: выборка только `stage NOT IN ('done', 'cancelled')` (терминальные исключены — см.
-ORCH-090: множество терминалов `{done, cancelled}`). Пустой список — валидный ответ.
-
-### FR-2 — Раздел `queue` (очередь jobs) — BR-3
-
-- `counts` — `db.job_status_counts()` (`queued`/`running`/`done`/`failed`); при наличии —
-  добавить `cancelled` (ORCH-090 терминал).
-- `depth` — глубина очереди = число `queued`-jobs, готовых к выдаче (можно вернуть как
-  `counts.queued`; при желании — отдельно «доступные сейчас» с учётом `available_at <= now`).
-- `retries` — сырьё по ретраям: сумма/список `attempts` vs `max_attempts` и `transient_attempts`
-  по незавершённым jobs; как минимум агрегат «сколько jobs в backoff» (`available_at > now`).
-- `breaker` — `worker.breaker.snapshot()`: `state` (`closed`/`open`/`half-open`),
-  `consecutive_transient`, `pause_remaining_s`.
-- `max_concurrency` — `worker.max_concurrency`.
-
-Инвариант: ни одно поле не обязано существовать ценой падения — недоступный breaker
-(например, worker не инициализирован в тесте) → `breaker: null`, не 500 (NFR-2).
-
-### FR-3 — Раздел `agents` (agent-liveness) — BR-4
-
-Список running-jobs (из `db.get_running_jobs()`), по каждому:
-- `agent` — `agent_runs.agent` (через джойн; роль: analyst/architect/developer/…).
-- `run_id` — `jobs.run_id` (= `agent_runs.id`).
-- `job_id` — `jobs.id`.
-- `pid` — `jobs.pid` (может быть `null`, если процесс ещё не застамплен / уже завершён).
-- `runtime_s` — `running_age_s` из `get_running_jobs` (секунды с `jobs.started_at`); как
-  альтернатива — секунды с `agent_runs.started_at`. Решение о базисе — за архитектором (ADR).
-- **Сырьё для alive-детекта** — одно из (выбор реализации — ADR архитектора, BR-4 допускает оба):
-  - вариант A: `cpu_ticks` — суммарные utime+stime из `/proc/<pid>/stat` (поля 14–15), плюс
-    `clk_tck` (`os.sysconf("SC_CLK_TCK")`), чтобы sidecar посчитал CPU-дельту между опросами;
-  - вариант B: орк сам не считает дельту (он опрашивается стейтлесс sidecar'ом) — отдаёт только
-    сырые тики + временную метку выборки.
-- `model`, `effort` — `agent_runs.model`/`effort` (контекст стоимости).
-
-Инвариант (NFR-2): `pid is None` ИЛИ `/proc/<pid>` отсутствует/гонка (процесс умер) →
-`cpu_ticks: null` для этого агента, остальные поля и весь эндпоинт целы. НЕ бросать, НЕ ждать.
-
-### FR-4 — Раздел `cost` (стоимость/токены) — BR-5
-
-- `running` — по каждому running-job текущие накопленные значения из `agent_runs`, если уже
-  застамплены (часто `null` до завершения — токены/cost парсятся из CLI-JSON в `_monitor_agent`
-  по окончании). Допустимо отдавать `null` для незавершённых — это честное сырьё.
-- `aggregate` — агрегаты по `agent_runs`: суммарные `cost_usd`, `input_tokens`, `output_tokens`,
-  `cache_read_tokens`, `cache_creation_tokens`. Желателен срез: всего + за последние N (или
-  по `repo`). Реализуется новым read-only helper'ом `db.agent_cost_totals()` (чистый SELECT
-  с `COALESCE(SUM(...),0)`).
-
-Инвариант: пустая `agent_runs` → нули, не ошибка.
-
-### FR-5 — Конверт ответа (envelope) — BR-1, BR-6, NFR-6
-
-`GET /metrics` возвращает JSON:
-```json
-{
-  "schema_version": 1,
-  "generated_at": "<ISO-8601 / datetime('now')>",
-  "stages": [ ... ],
-  "queue": { ... },
-  "agents": [ ... ],
-  "cost": { "running": [...], "aggregate": {...} }
-}
-```
-- `schema_version` — целое; точка стабильности контракта для sidecar (NFR-6). Стартовое значение
-  и политика инкремента — за архитектором.
-- `generated_at` — метка времени снимка (нужна sidecar'у для расчёта дельт).
-- Точные имена ключей разделов/полей фиксируются в `docs/architecture/README.md` (BR-7) и являются
-  контрактом; reviewer/tester сверяют ответ с документом.
-
-### FR-6 — Never-raise сборщик — NFR-2
-
-`metrics.build_metrics()` строит ответ по-раздельно; каждый раздел — в своём `try/except`, в
-`except` пишет `logger.warning(...)` и подставляет безопасный дефолт (`null`/`[]`/`{}`). Функция
-**никогда** не пробрасывает исключение. Эндпоинт `main` дополнительно не нуждается в обработке, но
-обязан вернуть результат сборщика как есть. Эталон — `serial_gate.snapshot()`.
-
-## 4. Изменения API
-
-**Новый эндпоинт:**
-- `GET /metrics` → `200 application/json`, тело — конверт FR-5. Без параметров. Без аутентификации
-  сверх существующей (тот же уровень, что `/queue`/`/status`). Read-only.
-
-**Изменённые эндпоинты:** Нет. `/health`, `/status`, `/queue`, `/webhook/*` — без изменений
-(BR-6). Регресс-проверка: существующие тесты эндпоинтов остаются зелёными.
-
-## 5. Изменения схемы БД
-
-**Нет.** Новые таблицы/колонки/индексы/миграции не вводятся. Используются существующие
-`tasks`/`jobs`/`agent_runs` и их колонки (перечислены в §2). Допускается добавление **read-only**
-helper-функций в `src/db.py` (например `agent_cost_totals()`) — это код, не схема; `CREATE`/`ALTER`
-не выполняются. `STAGE_TRANSITIONS`/`QG_CHECKS`/схема — байт-в-байт прежние (NFR-5).
-
-## 6. Требования к новым/изменённым QG checks
-
-**Нет.** `/metrics` — наблюдаемость, не гейт конвейера. `QG_CHECKS` / `check_*` / `_parse_*` /
-machine-verdict ключи (`verdict:`/`result:`/`deploy_status:`/`staging_status:`/`security_status:`/
-`coverage_status:`) — НЕ трогаются. Новых артефактов pipeline (`NN-*.md`) задача не создаёт.
-
-## 7. Совместимость / регресс
-
-- **Аддитивность:** новый модуль (`src/metrics.py`) + новый эндпоинт + read-only helper(ы).
-  Существующий код путей конвейера не модифицируется.
-- **Read-only / never-raise:** по конструкции (NFR-1/NFR-2) эндпоинт не влияет на состояние и не
-  падает → нулевой риск для прод-конвейера, общего с enduro-trails (NFR-4).
-- **Kill-switch:** жёсткий флаг не обязателен (эндпоинт инертен и не подключён к конвейеру). Если
-  архитектор сочтёт нужным — допустим конфиг-флаг включения `/metrics` (по образцу snapshot-флагов),
-  но это НЕ требование BRD; дефолт — эндпоинт доступен.
-- **Обратимость:** удаление эндпоинта/модуля полностью откатывает изменение без следов в БД/схеме.
-- **Контракт sidecar:** `schema_version` + документ в README обеспечивают, что F1b не сломается при
-  будущих аддитивных расширениях (NFR-6).
-- **Артефакты pipeline, создаваемые/обновляемые задачей:** `01-brd.md`, `02-trz.md`,
-  `03-acceptance-criteria.md`, `04-test-plan.yaml` (analysis); далее — `06-adr/` (architect),
-  обновление `docs/architecture/README.md` и `CHANGELOG.md` (developer в том же PR — правило
-  «доки = golden source»).

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

@@ -1,127 +0,0 @@
----
-work_item: ORCH-099
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-099 — FND/F1a: лёгкий `/metrics` в орке
-
-Work Item: **ORCH-099** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Reviewer/tester проверяет их буквально по файлам репозитория и по ответу
-эндпоинта.
-
----
-
-## AC-1 — Эндпоинт `/metrics` отдаёт четыре раздела сырья
-
-**Условие:** `GET /metrics` возвращает `200` и JSON с разделами `stages`, `queue`, `agents`, `cost`
-(плюс конверт `schema_version` / `generated_at`), с полями из TRZ §3.
-- **PASS:** ответ — валидный JSON-объект; присутствуют ключи `schema_version`, `generated_at`,
-  `stages` (список; элемент содержит `work_item`, `stage`, `age_in_stage_s`, `repo`), `queue`
-  (содержит `counts`, `breaker`, `max_concurrency`, сырьё ретраев), `agents` (список; элемент
-  содержит `agent`, `run_id`, `pid`, `runtime_s` и поле сырья CPU-liveness), `cost` (содержит
-  `aggregate` с суммами `cost_usd`/`input_tokens`/`output_tokens`/`cache_read_tokens`/
-  `cache_creation_tokens`).
-- **FAIL:** отсутствует любой из четырёх разделов; в `agents` нет `pid`/`runtime_s`; в `stages` нет
-  «как давно в стадии»; в `cost` нет агрегата токенов/стоимости; ответ не JSON или статус ≠ 200.
-
----
-
-## AC-2 — Аддитивность: `/health`, `/status`, `/queue` не сломаны
-
-**Условие:** существующие эндпоинты сохраняют прежний контракт.
-- **PASS:** `GET /health` → `{"status":"ok", ...}`; `GET /status` → `{"active_tasks":[...]}`;
-  `GET /queue` отдаёт прежний набор ключей; существующие тесты эндпоинтов (`tests/test_queue_endpoint.py`
-  и пр.) зелёные без модификации их ожиданий.
-- **FAIL:** изменён/удалён любой существующий ключ ответа `/health`/`/status`/`/queue`; пришлось
-  править существующие тесты под новый контракт; регресс в этих эндпоинтах.
-
----
-
-## AC-3 — Лёгкость и быстрая выборка
-
-**Условие:** эндпоинт лёгкий — только быстрые локальные SQL + чтение in-memory снапшотов, без
-тяжёлых вычислений и сетевых вызовов.
-- **PASS:** в коде `src/metrics.py` нет сетевых вызовов (HTTP/Plane/Gitea/Anthropic), нет запуска
-  подпроцессов кроме безопасного чтения `/proc/<pid>/stat`, нет сканирования git/файлового дерева;
-  данные берутся из существующих helper'ов БД и `worker`-снапшота; на типовом объёме ответ
-  формируется без заметной задержки.
-- **FAIL:** эндпоинт делает сетевой запрос, запускает агента/тяжёлый процесс, сканирует worktree/git
-  или выполняет дорогие агрегаты, заметно тормозящие ответ.
-
----
-
-## AC-4 — Never-raise (ошибка поля → `null`, эндпоинт не падает)
-
-**Условие:** любая ошибка сбора отдельного поля/раздела не роняет эндпоинт.
-- **PASS:** при недоступном источнике (например, `worker` не инициализирован, `pid` уже мёртв,
-  `/proc/<pid>` отсутствует, пустые таблицы) соответствующее поле получает `null`/безопасный дефолт,
-  а `GET /metrics` всё равно возвращает `200` и валидный JSON; есть тест, симулирующий сбой раздела
-  и проверяющий 200 + `null` в этом поле.
-- **FAIL:** при любом из перечисленных условий эндпоинт возвращает `500` / бросает исключение /
-  возвращает невалидный JSON.
-
----
-
-## AC-5 — Read-only (ничего не меняет; гейты/схема не тронуты)
-
-**Условие:** эндпоинт и модуль строго read-only; конвейерные инварианты целы.
-- **PASS:** `src/metrics.py` и обработчик `/metrics` не выполняют `INSERT`/`UPDATE`/`DELETE`/`CREATE`/
-  `ALTER`, не запускают/останавливают процессы, не рестартят, не мутируют состояние демонов;
-  `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict ключи и схема БД (`tasks`/`jobs`/
-  `agent_runs` и пр.) — без изменений в диффе; повторный вызов `/metrics` не меняет состояние БД
-  (тест: снимок БД до/после идентичен).
-- **FAIL:** дифф трогает `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/схему/machine-verdict; модуль
-  выполняет любую запись/мутацию; вызов эндпоинта меняет состояние.
-
----
-
-## AC-6 — agent-liveness содержит сырьё для alive-детекта
-
-**Условие:** по каждому running-job отдаётся идентификация процесса и сырьё для CPU-детекта
-sidecar'ом.
-- **PASS:** для running-job ответ содержит `agent`, `run_id`, `pid`, `runtime_s` и поле сырья
-  CPU-liveness (например `cpu_ticks` из `/proc/<pid>/stat` + базис тиков `clk_tck`, либо
-  эквивалент по решению ADR), позволяющее внешнему наблюдателю посчитать CPU-дельту между опросами;
-  при `pid is None`/мёртвом процессе CPU-поле = `null` (см. AC-4), прочие поля целы.
-- **FAIL:** liveness-раздел не позволяет sidecar'у отличить «жив» от «завис» (нет ни CPU-сырья, ни
-  pid+runtime); отсутствуют `run_id`/`pid`; обращение к мёртвому pid роняет эндпоинт.
-
----
-
-## AC-7 — Контракт задокументирован (для sidecar F1b) + CHANGELOG
-
-**Условие:** формат `/metrics` зафиксирован как контракт и отражён в журнале изменений.
-- **PASS:** в `docs/architecture/README.md` описан формат ответа `/metrics` (разделы, поля,
-  `schema_version`) как стабильный контракт для sidecar (F1b); в `CHANGELOG.md` есть запись
-  `## [Unreleased]` с пометкой `ORCH-099`.
-- **FAIL:** формат не задокументирован или описан только в коде; нет записи в `CHANGELOG.md`;
-  документация противоречит фактическому ответу эндпоинта.
-
----
-
-## AC-8 — pytest зелёный
-
-**Условие:** новый тест-набор и полный регресс проходят.
-- **PASS:** `pytest tests/ -q` зелёный; присутствует `tests/test_metrics.py`, покрывающий структуру
-  ответа (AC-1), never-raise (AC-4), read-only (AC-5), liveness-сырьё (AC-6) и аддитивность (AC-2).
-- **FAIL:** любой тест красный; новые тесты отсутствуют или не покрывают перечисленные критерии.
-
----
-
-## Сводная матрица AC ↔ FR/BR
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1/BR-2/BR-3/BR-5 / FR-1…FR-5 |
-| AC-2 | BR-6 / FR-4 |
-| AC-3 | NFR-3 / FR-6 |
-| AC-4 | NFR-2 / FR-6 |
-| AC-5 | NFR-1/NFR-4/NFR-5 / FR-5 |
-| AC-6 | BR-4 / FR-3 |
-| AC-7 | BR-7 / FR-5 |
-| AC-8 | NFR-3 (валидация) / все FR |

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

@@ -1,86 +0,0 @@
-work_item: ORCH-099
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "FND/F1a — лёгкий read-only /metrics: стадии/очередь/agent-liveness/cost"
-framework: pytest
-scope: >
-  Покрывается: структура ответа GET /metrics (4 раздела + конверт), never-raise по полям,
-  read-only инвариант, agent-liveness сырьё (pid/runtime/cpu-тики), агрегаты cost/токенов,
-  аддитивность (не сломаны /health//status//queue). Вне покрытия: сам sidecar (F1b),
-  хостовые/контейнерные метрики, пороги/алерты/Telegram. Полный регресс tests/ остаётся зелёным.
-notes: >
-  Тесты идут в новый tests/test_metrics.py. Используется существующий паттерн conftest.py
-  (autouse fresh_db на tmp_path + init_db, monkeypatch send_telegram). Эндпоинт зовётся как
-  корутина через asyncio.run(main.metrics()) по образцу tests/test_queue_endpoint.py
-  (asyncio.run(main.queue())). Read-only проверяется сравнением снимка БД до/после вызова.
-  Never-raise — monkeypatch источника (worker / helper БД / чтения /proc) на бросающий стаб.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: "build_metrics() возвращает dict с ключами schema_version, generated_at, stages, queue, agents, cost (конверт FR-5)."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Раздел stages: для задачи со stage!=done/cancelled элемент содержит work_item, stage, age_in_stage_s (int), repo; терминальные задачи (done/cancelled) исключены."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Раздел queue: counts (queued/running/failed), max_concurrency, сырьё ретраев и breaker-снимок (state/consecutive_transient/pause_remaining_s) присутствуют."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Раздел agents: по running-job отдаются agent, run_id, job_id, pid, runtime_s и поле CPU-liveness сырья (cpu_ticks или эквивалент)."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "agent-liveness never-raise: при pid=None или отсутствующем /proc/<pid> CPU-поле = null, остальные поля агента и весь ответ целы (без исключения)."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Раздел cost.aggregate: суммы cost_usd/input_tokens/output_tokens/cache_read_tokens/cache_creation_tokens из agent_runs; пустая таблица -> нули, не ошибка."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: "Never-raise по разделу: если источник раздела (напр. job_status_counts/worker.status) бросает, раздел получает null/дефолт, build_metrics() не пробрасывает исключение."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-08
-    type: integration
-    description: "GET /metrics через ASGI/обработчик возвращает 200 и валидный JSON со всеми разделами на засеянной БД (задача + running-job + agent_run)."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-09
-    type: integration
-    description: "Read-only: снимок всех таблиц БД (tasks/jobs/agent_runs) до и после вызова /metrics идентичен; повторный вызов не меняет состояние."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: "Аддитивность: GET /health, /status, /queue сохраняют прежний контракт (ключи на месте) при наличии /metrics; существующие тесты эндпоинтов зелёные."
-    module: tests/test_metrics.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Пустое состояние: при отсутствии активных задач/running-jobs/agent_runs ответ валиден — stages=[], agents=[], cost.aggregate=нули, queue.counts с нулями; 200/без исключений."
-    module: tests/test_metrics.py
-    expected: PASS

docs/work-items/ORCH-099/06-adr/ADR-001-metrics-endpoint.md

@@ -1,249 +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-001: Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b)
-
-Work Item: **ORCH-099** — FND/F1a: лёгкий `/metrics` в орке (отдать сырьё)
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0030-metrics-endpoint.md`** (решение
-кросс-каттинговое — новый компонент наблюдаемости + новый публичный HTTP-контракт для будущего
-sidecar F1b).
-
-## Статус
-Proposed
-
-## Контекст
-
-F1a — фундаментный кирпич домена 0 «Фундамент» эпика автономного саморазвития. Рамка наблюдаемости
-зафиксирована заказчиком (BRD §1): **наблюдатель отделён от наблюдаемого** — мониторинг (пороги,
-алерты, история, свой Telegram) живёт в отдельном sidecar-контейнере **F1b** (`watchdog/`), а орк
-отдаёт **только сырьё**, которое знает лишь он сам. F1a поставляет источник этого сырья и **ничего
-больше**.
-
-Факты, сверенные с кодом:
-- `GET /health` (`src/main.py:147`) → `{"status":"ok", ...}`; `GET /status` (`:152`) → список
-  активных задач; `GET /queue` (`:163`) — богатый, но «человеческий» снимок, перемешанный с
-  конфигом демонов (reconciler/reaper/post_deploy/disk_monitor/…). Ни один не даёт **стабильного
-  машинного контракта** для детекта: застрявшая стадия, зависший агент, деградация очереди, всплеск
-  стоимости.
-- Все нужные данные уже в БД и in-memory: `db.get_active_tasks_for_reconcile()` (`src/db.py:388` —
-  `stage != 'done'` + `age_s` в SQL), `db.get_running_jobs()` (`:1103` — `SELECT j.*` + `running_age_s`,
-  LEFT JOIN `agent_runs` на `run_id`), `db.job_status_counts()` (`:1187`),
-  `queue_worker.worker.status()`/`CircuitBreaker.snapshot()` (`src/queue_worker.py:242`/`:113` — breaker
-  in-memory). `pid`/`run_id`/`job_id` — колонки `jobs` (ORCH-065, `:83`); `model`/`effort`/`cost_usd`/
-  `*_tokens` — колонки `agent_runs` (`:97`–`:106`). Терминальное множество — `{done, cancelled}`
-  (ORCH-090, adr-0026).
-- Self-hosting: прод-контейнер общий с enduro-trails. Эндпоинт обязан быть строго **read-only** и
-  **never-raise** — не ронять и не тормозить прод ни при каких входных данных.
-
-«Как есть» не годится: добавлять поля в `/queue` сломало бы его контракт (BR-6) и смешало бы сырьё с
-человеческим снимком; в коде sidecar'а нет ни одной стабильной точки опроса. Нужен отдельный,
-версионируемый, машинный контракт.
-
-## Решение
-
-### Сводка
-
-Новый **leaf-модуль** `src/metrics.py` с чистой never-raise функцией-сборщиком
-`build_metrics() -> dict` (по образцу `serial_gate.snapshot()`/`task_deps.snapshot()`/
-`cancel.snapshot()`) + тонкий эндпоинт `@app.get("/metrics")` в `src/main.py` (обёртка над
-сборщиком, в стиле `GET /queue`). Сборщик собирает четыре раздела (`stages`/`queue`/`agents`/`cost`)
-в версионируемом конверте, **каждый раздел — в своём `try/except`** с безопасным дефолтом. Только
-чтение существующих таблиц (`tasks`/`jobs`/`agent_runs`) и существующих in-memory-снапшотов + два
-read-only helper'а в `src/db.py`. `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict-ключи/
-схема БД — **не трогаются**.
-
-### D1 — Новый leaf-модуль + тонкий эндпоинт (изоляция, never-raise по разделам)
-
-Логика сборки — в `src/metrics.py`, не в `main.py` (тестируемость без ASGI, паттерн `*.snapshot()`).
-`build_metrics()` строит конверт по-раздельно; каждый раздел обёрнут в `try/except Exception`, в
-`except` → `logger.warning(...)` + безопасный дефолт (`null` для скаляра/объекта, `[]` для списка).
-Функция **никогда** не пробрасывает исключение (FR-6, NFR-2, AC-4). Эндпоинт `/metrics` —
-тонкая обёртка: возвращает `build_metrics()` как есть; собственной обработки ошибок не требует
-(сборщик уже never-raise). Уровень доступа — тот же, что `/queue`/`/status` (без доп. аутентификации,
-FR-4).
-
-Привязка: FR-6, NFR-1, NFR-2, AC-4, AC-5.
-
-### D2 — Конверт ответа + контракт `schema_version` (BR-1, BR-6, NFR-6)
-
-```json
-{
-  "schema_version": 1,
-  "generated_at": "2026-06-10T12:34:56Z",
-  "clk_tck": 100,
-  "stages":  [ ... ],
-  "queue":   { ... },
-  "agents":  [ ... ],
-  "cost":    { "running": [ ... ], "aggregate": { ... } }
-}
-```
-
-- **`schema_version` стартует с `1`.** Политика инкремента (контракт для F1b, документируется в
-  README, BR-7): **аддитивные** изменения (новое поле/раздел) **НЕ бампят версию** — sidecar
-  **обязан игнорировать незнакомые ключи и толерировать отсутствие опциональных**. Версия бампится
-  **только при ломающем** изменении (переименование/удаление/смена типа существующего поля). Это
-  делает контракт forward-compatible: будущие расширения F1a не ломают уже написанный F1b (NFR-6,
-  TR-4). Формат-чек версии — по духу `is_valid_model` (ORCH-74): структурный, не статичный allowlist.
-- **`generated_at`** — `datetime('now')` UTC, ISO-8601 (тот же часовой домен, что timestamp'ы БД и
-  выборка CPU-тиков). Это момент снимка: sidecar считает дельты между двумя опросами по
-  `(cpu_ticks, generated_at)` из ответов — **всё в часах самого орка**, поэтому расчёт иммунен к
-  расхождению часов орк↔sidecar (TR-3).
-- **`clk_tck`** — `os.sysconf("SC_CLK_TCK")` на уровне конверта (а не на каждом агенте — значение
-  процесс-глобальное): базис для перевода CPU-тиков в секунды на стороне sidecar.
-
-Привязка: BR-1, BR-6, NFR-6, FR-5, AC-1, AC-7.
-
-### D3 — Раздел `stages` (BR-2, FR-1)
-
-Список активных задач из `db.get_active_tasks_for_reconcile()`, **с дополнительной фильтрацией
-`stage NOT IN ('done','cancelled')`** на слое metrics. Обоснование: helper намеренно возвращает
-`cancelled`-задачи (для skip-счётчика реконсилятора ORCH-086, см. `src/db.py:396`) — но для сырья
-наблюдаемости терминальные задачи не нужны (терминальное множество `{done, cancelled}`, ORCH-090).
-Не меняем helper (его инвариант принадлежит ORCH-053/086) — фильтруем на потребителе. По каждой
-задаче: `work_item` (`work_item_id`), `stage`, `age_in_stage_s` (= `age_s`, целое, SQL
-`strftime` против UTC-now — момент последней смены стадии), `repo` (sidecar мультипроектный),
-опц. `task_id`/`created_age_s`. Пустой список — валидный ответ (AC, TC-11).
-
-Привязка: BR-2, FR-1, AC-1, TC-02, TC-11.
-
-### D4 — Раздел `queue` (BR-3, FR-2)
-
-- `counts` — `db.job_status_counts()` (`queued`/`running`/`done`/`failed`); добавить `cancelled`
-  (ORCH-090 терминал) — helper уже агрегирует `GROUP BY status`, нужно лишь не терять ключ.
-- `depth` — глубина очереди = число `queued`-jobs (можно `counts.queued`); опц. «доступные сейчас»
-  с учётом `available_at <= now`.
-- `retries` — агрегат по незавершённым jobs: `attempts` vs `max_attempts`, `transient_attempts`, и
-  как минимум «сколько jobs в backoff» (`available_at > now`). Источник — read-only SELECT-агрегат
-  (новый helper или агрегация по `recent_jobs`/прямой SELECT; решение реализации за developer'ом в
-  рамках read-only).
-- `breaker` — `worker.breaker.snapshot()` (`state`/`consecutive_transient`/`pause_remaining_s`).
-- `max_concurrency` — `worker.max_concurrency`; опц. `poll_interval`.
-
-Инвариант (NFR-2): недоступный `worker` (не инициализирован в тесте) → `breaker: null` и/или
-`max_concurrency: null`, **не 500** (own `try/except` вокруг in-memory доступа).
-
-Привязка: BR-3, FR-2, AC-1, TC-03, TC-07.
-
-### D5 — Раздел `agents` (agent-liveness) — источник данных и CPU-сырьё (BR-4, FR-3)
-
-**Источник данных — новый dedicated read-only helper `db.get_running_agents()`, НЕ расширение
-`get_running_jobs()`.** Причина: `get_running_jobs()` — hot-path запрос job-reaper'а (ORCH-065,
-`src/db.py:1103`); расширять его SELECT под нужды наблюдаемости — перенос инварианта чужого
-компонента. Новый helper — изолированный `SELECT j.id, j.run_id, j.pid, j.agent, j.started_at,
-running_age_s, r.model, r.effort FROM jobs j LEFT JOIN agent_runs r ON r.id = j.run_id WHERE
-j.status='running'` (LEFT JOIN сохраняет job без `agent_runs`-строки). По каждому running-job:
-`agent`, `run_id`, `job_id`, `pid` (может быть `null`), `runtime_s`, `model`, `effort`, `cpu_ticks`.
-
-**CPU-сырьё — вариант A (орк читает `/proc`, остаётся stateless).** Орк эмитит сырые тики, дельту
-**не считает** — арбитр liveness это sidecar (BRD-допущение C-1). Чистый never-raise helper в
-`src/metrics.py`:
-
-```
-_read_cpu_ticks(pid) -> int | None
-    # читает /proc/<pid>/stat, поля 14 (utime) + 15 (stime), возвращает их сумму (в тиках);
-    # pid is None / нет /proc/<pid> / гонка (процесс умер) / не-Linux -> None (НЕ raise)
-```
-
-`clk_tck` (D2) — на уровне конверта. sidecar между двумя опросами считает
-`cpu_busy = (ticks₂ − ticks₁) / clk_tck`, делит на `(generated_at₂ − generated_at₁)` → доля CPU;
-малая доля при растущем `runtime_s` ⇒ кандидат на «завис». Парсинг `/proc/<pid>/stat` устойчив к
-пробелам в `comm`: брать поля **после** `') '` (закрывающая скобка имени) — канон чтения proc-stat.
-
-Инвариант (NFR-2, AC-6, TC-05): `pid is None` ИЛИ мёртвый/отсутствующий `/proc/<pid>` → `cpu_ticks:
-null` у этого агента; прочие поля и весь эндпоинт целы.
-
-Привязка: BR-4, FR-3, AC-6, TC-04, TC-05.
-
-### D6 — `runtime_s` — базис `jobs.started_at` (FR-3)
-
-`runtime_s = running_age_s` (секунды с `jobs.started_at`, считается в SQL в `get_running_agents`),
-**не** `agent_runs.started_at`. Обоснование: `jobs.started_at` — якорь жизненного цикла процесса,
-рядом с которым застамплен `pid` (ORCH-065); это тот же базис, что использует reaper для
-backstop-liveness. Значения почти совпадают, но `jobs` — авторитетный процесс-якорь, а
-`agent_runs`-строки может не быть (LEFT JOIN). Консистентность с reaper > микроточность.
-
-Привязка: FR-3, AC-6.
-
-### D7 — Раздел `cost` (BR-5, FR-4)
-
-- `running` — по каждому running-job текущие значения из `agent_runs`, если уже застамплены. Часто
-  `null` до завершения: токены/`cost_usd` парсятся из CLI-JSON в `launcher._monitor_agent` по
-  окончании. **`null` для незавершённых — честное сырьё** (документируется: `null` ≠ ноль, TR-5).
-- `aggregate` — новый read-only helper `db.agent_cost_totals()`: чистый
-  `SELECT COALESCE(SUM(cost_usd),0), COALESCE(SUM(input_tokens),0), … FROM agent_runs` по
-  `cost_usd`/`input_tokens`/`output_tokens`/`cache_read_tokens`/`cache_creation_tokens`. Пустая
-  таблица → нули, не ошибка (TC-06, TC-11). Опц. срез (всего + по `repo` через джойн `tasks`) —
-  расширяемо без бампа версии (D2).
-
-Привязка: BR-5, FR-4, AC-1, TC-06, TC-11.
-
-### D8 — Kill-switch `metrics_endpoint_enabled` (default `True`)
-
-TRZ §7 оставляет флаг на усмотрение архитектора. **Решение: добавить** конфиг-флаг
-`metrics_endpoint_enabled` (env `ORCH_METRICS_ENABLED`, дефолт `True`) — по образцу snapshot-флагов
-кодовой базы и из self-hosting-осторожности (операторский off-switch на общем прод-инстансе). При
-`False` эндпоинт возвращает **`200` с минимальным телом** `{"schema_version": 1, "enabled": false}`
-(не 404 — контракт остаётся парсимым, sidecar видит `enabled:false` и трактует это явно). Дефолт
-`True` ⇒ нулевая регрессия требований BRD (эндпоинт доступен из коробки). Флаг — дешёвая страховка,
-не предмет BRD; реализация инертна.
-
-Привязка: NFR-1, NFR-4, TRZ §7.
-
-## Альтернативы
-
-- **Расширить `/queue` вместо нового эндпоинта** — отвергнуто: сломало бы байт-в-байт контракт
-  `/queue` (BR-6, AC-2) и смешало бы машинное сырьё с человеческим снимком + конфигом демонов;
-  sidecar'у нужна узкая стабильная точка.
-- **Prometheus/OpenMetrics text-формат** — отвергнуто: заказчик задал тонкий кастомный sidecar (не
-  Prometheus, C-3); требование — JSON-контракт под конкретный F1b.
-- **Орк сам считает CPU-дельту** — отвергнуто: требует состояния между опросами; орк — пассивный
-  источник, stateful-арбитр это sidecar (C-1). Stateless-эмиссия сырых тиков проще и надёжнее.
-- **Расширить SELECT `get_running_jobs()`** под model/effort — отвергнуто: перенос инварианта
-  hot-path reaper'а (ORCH-065); изолируем dedicated helper `get_running_agents()`.
-- **Push метрик в sidecar** — отвергнуто: нарушает разделение C-1 (орк остаётся пассивным
-  источником); при зависшем орке pull-опрос падает — это **сам сигнал тревоги** для sidecar.
-- **Без kill-switch** — рассматривалось (эндпоинт инертен); выбран флаг ради конвенции кодовой базы
-  и операторского off-switch (D8).
-
-## Последствия
-
-- **+** Появляется стабильный машинный контракт сырья — F1b (заблокированная этой задачей)
-  разблокирована; домен наблюдаемости может стартовать.
-- **+** Строго read-only + never-raise по разделам ⇒ near-zero остаточный риск для общего
-  прод-конвейера (enduro-trails); физически не способен повлиять на конвейер (NFR-4).
-- **+** Аддитивно и обратимо: `/health`/`/status`/`/queue` байт-в-байт; `STAGE_TRANSITIONS`/
-  `QG_CHECKS`/`check_*`/schema/machine-verdict-ключи не тронуты (NFR-5).
-- **+** `schema_version` + аддитивно-толерантная политика ⇒ будущие расширения не ломают F1b.
-- **−** Новый публичный контракт = новая поверхность совместимости: дрейф `/metrics`↔F1b митигируется
-  единым репозиторием контракта (README, BR-7) + `schema_version` (D2). Издержка принимается.
-- **−** CPU-liveness Linux-специфичен (`/proc`); на не-Linux `cpu_ticks: null` (деградация, не
-  ошибка). Прод-контейнер — Linux, допущение выполняется (BRD §6).
-- **Топология/схема:** не меняются (07/08 — N/A). Sidecar-контейнер и его сетевая достижимость
-  `/metrics` — объём **F1b**, не этой задачи (см. README-заметку о предусловии достижимости).
-- **Эскалация:** формально вводится новый компонент наблюдаемости + публичный контракт → лейбл
-  **`arch:major-change`** (консервативно, хотя изменение полностью аддитивно/read-only/обратимо).
-  Прод-деплой — строго через staging-гейт (8501), без рестарта прод-контейнера.
-- **Откат:** `metrics_endpoint_enabled=False` (мгновенный) либо удаление `src/metrics.py` + эндпоинта
-  + helper'ов — полностью откатывает изменение без следов в БД/схеме (TRZ §7).
-
-## Ссылки
-- BRD: `docs/work-items/ORCH-099/01-brd.md`
-- TRZ: `docs/work-items/ORCH-099/02-trz.md`
-- Acceptance: `docs/work-items/ORCH-099/03-acceptance-criteria.md`
-- Тех-риски: `docs/work-items/ORCH-099/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0030-metrics-endpoint.md`
-- Сверено по коду: `src/main.py` (`/health`/`/status`/`/queue`), `src/db.py`
-  (`get_active_tasks_for_reconcile`/`get_running_jobs`/`job_status_counts`, схема `agent_runs`/`jobs`),
-  `src/queue_worker.py` (`worker.status`/`CircuitBreaker.snapshot`), `src/serial_gate.py`
-  (`snapshot()` — эталон never-raise).
-- Связанные ADR: adr-0002 (job-queue/breaker — источник `queue`-сырья), adr-0011 (job-reaper —
-  `get_running_jobs`/pid/liveness-семантика), adr-0026 (терминал `{done,cancelled}` — фильтр стадий),
-  adr-0017 (serial_gate — паттерн leaf `snapshot()`/never-raise), adr-0020 (frontmatter-контракт —
-  стиль версионируемого контракта).

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

@@ -1,43 +0,0 @@
----
-work_item: ORCH-099
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-099 — FND/F1a: лёгкий `/metrics` (сырьё для sidecar)
-
-Work Item: **ORCH-099** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | Гонка чтения `/proc/<pid>/stat`: процесс умер между выборкой running-job и чтением proc → `FileNotFoundError`/частичная строка | Сред. | Низ. | `_read_cpu_ticks` never-raise → `cpu_ticks: null` (NFR-2, FR-3, AC-6); прочие поля и эндпоинт целы. Парс proc-stat читает поля **после** `') '` (устойчивость к пробелам в `comm`). |
-| TR-2 | PID-namespace mismatch: `jobs.pid` относится не к тому PID-namespace, где орк читает `/proc` | Низ. | Сред. | Агент — дочерний процесс орка (launcher `subprocess` в том же контейнере/ns), `pid` стамплется орком (ORCH-065) → `/proc/<pid>` валиден в том же ns. Несовпадение → `null` (деградация, не падение). |
-| TR-3 | Расхождение часов орк↔sidecar искажает расчёт CPU-доли | Низ. | Низ. | Контракт by-design: sidecar считает дельту по `(cpu_ticks, generated_at)` из **двух ответов орка** → всё в домене часов орка, skew-иммунно (ADR D2). |
-| TR-4 | Дрейф контракта `/metrics`↔ожидания F1b при будущих расширениях | Сред. | Сред. | `schema_version` (старт 1) + аддитивно-толерантная политика (sidecar игнорирует незнакомые ключи, толерирует отсутствие опциональных); контракт документирован в README в одном репо (BR-7, NFR-6). |
-| TR-5 | `cost.running = null` (токены ещё не застамплены) ошибочно прочитан sidecar'ом как «ноль стоимости» | Сред. | Низ. | Документировать: `null` ≠ ноль (= «не завершён, не застамплен»); авторитет по спенду — `cost.aggregate` (ADR D7). |
-| TR-6 | Контеншн на `CircuitBreaker._lock` при опросе breaker-снимка | Низ. | Низ. | `snapshot()` держит lock кратко (только чтение полей, `src/queue_worker.py:113`); раздел обёрнут own `try/except` → `breaker: null` при любой проблеме. Частота опроса sidecar — секунды, не микросекунды. |
-| TR-7 | Рост стоимости `SUM`-агрегата по `agent_runs` при разрастании таблицы | Низ. | Низ. | `agent_cost_totals()` — один индексируемый full-scan `SUM`, n мал (десятки–сотни строк на текущем горизонте); точка расширения — временное окно/`repo`-срез без бампа версии (ADR D2/D7). |
-| TR-8 | Соблазн «протащить» в `/metrics` логику алертинга/порогов | Низ. | Сред. | Scope-граница BRD (вне объёма) + NFR-1 (read-only) + reviewer-контроль; мозг (пороги/алерты) — строго F1b. |
-| TR-9 | Незаметная мутация состояния (случайный не-read-only вызов в сборщике) роняет инвариант read-only | Низ. | Выс. | Сборщик использует только SELECT-helper'ы; AC-5/TC-09 — тест «снимок БД до/после идентичен»; reviewer сверяет дифф на отсутствие `INSERT/UPDATE/DELETE/CREATE/ALTER` и запуска процессов. |
-
-## Сводный вывод
-
-Доминирующий класс — **гонки/деградация чтения runtime-данных** (`/proc`, in-memory breaker), все
-закрыты конструктивным never-raise по разделам (эталон `serial_gate.snapshot()`) → деградация в
-`null`, не отказ. Контрактные риски (TR-4/TR-5) закрыты `schema_version` + документированием.
-Наивысшее потенциальное влияние (TR-9, нарушение read-only) митигируется тестом «БД до/после
-идентична» (TC-09) и reviewer-сверкой диффа.
-
-Изменение полностью аддитивно, read-only, never-raise, обратимо (kill-switch + удаление модуля).
-**Остаточный риск для прод-конвейера (self-hosting, общий с enduro-trails) — near-zero:** эндпоинт
-физически не способен мутировать состояние или уронить процесс (NFR-1/NFR-2/NFR-4). Эскалация в
-анализ не требуется. Формальный лейбл **`arch:major-change`** проставляется консервативно (новый
-компонент наблюдаемости + публичный контракт), хотя по существу изменение низкорисковое; прод-деплой
-— строго через staging-гейт (8501), без рестарта прод-контейнера.