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

Закрывает F-1-пробел ORCH-068: терминал-исключение и in-memory dedup
(изначально только F-2) распространены на gate-side путь реконсилятора,
устраняя ложное «🔧 reconciler: ET-002 done разблокирована (потерян
webhook)» (особенно после рестарта).

- D1: новый _resolve_issue_status — один сетевой резолв Plane-статуса
  задачи за тик (states, groups, state_uuid) после дешёвых локальных
  гардов; never-raise -> ({}, {}, None) при сбое.
- D2: безусловный терминал-скип ДО Guard 2 (группа Plane completed/
  cancelled, fallback на логические ключи done/cancelled, либо стадия в
  БД орка ∈ {done, cancelled}); skipped_terminal_total++, не подчинён
  reconcile_skip_blocked_enabled.
- D3: _is_blocked_or_needs_input переиспользует резолв D1 (опц. аргументы,
  _UNSET -> самостоятельный резолв для прямых/легаси-вызовов; 1:1).
- D4: вызов _note_unblock на F-1 теперь передаёт state_uuid -> dedup
  работает на обоих путях (deduped_total++ на повторе).

Анти-регресс: легитимный unblock не-терминальной застрявшей задачи
по-прежнему advance + один Telegram. STAGE_TRANSITIONS / QG_CHECKS /
схема БД / сигнатуры advance_*/_note_unblock / форма status() / новые
флаги — без изменений; never-raise сохранён.

Тесты: tests/test_reconciler.py TC-86-01..09/11,
tests/test_reconciler_plane.py TC-86-10. Полный прогон зелёный (1069).

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

.env.example

@@ -12,6 +12,47 @@ ORCH_GITEA_WEBHOOK_SECRET=
 ORCH_CLAUDE_BIN=/usr/bin/claude
 ORCH_REPOS_DIR=/home/slin/repos
 ORCH_DB_PATH=/app/data/orchestrator.db
+
+# ── Agent model / effort / fallback (ORCH-41, validation ORCH-74) ─────────────
+# Per-agent LLM model + reasoning effort, resolved by launcher.resolve_agent_*.
+# Resolution priority (per agent): project-override (projects_json agent_models/
+# agent_efforts) > ORCH_AGENT_MODEL_<AGENT> / ORCH_AGENT_EFFORT_<AGENT> >
+# ORCH_AGENT_MODEL_DEFAULT / ORCH_AGENT_EFFORT_DEFAULT > CLI default (no flag).
+# The frontmatter `model:` in .openclaw/agents/*.md is DESCRIPTIVE only and is NOT
+# read — config below is the single source of truth for the model (ORCH-74 G1).
+#
+# ORCH-74 (G2): a resolved MODEL name is validated (^claude-…$ format check) before
+# it reaches --model. A structurally invalid name (typo, gpt-4, empty) is logged and
+# the next valid level is used (in the limit: no --model flag). Forward-compatible:
+# a future claude-* version passes without editing any allowlist. EFFORT is validated
+# against low|medium|high|xhigh|max (ORCH-41); an invalid effort is dropped.
+#
+# All 6 agents resolve to claude-opus-4-8 (model-routing G3 NOT enabled). Leave the
+# per-agent overrides empty to use the default. Do NOT hardcode the model version
+# anywhere except ORCH_AGENT_MODEL_DEFAULT.
+ORCH_AGENT_MODEL_DEFAULT=claude-opus-4-8
+ORCH_AGENT_MODEL_ANALYST=
+ORCH_AGENT_MODEL_ARCHITECT=
+ORCH_AGENT_MODEL_DEVELOPER=
+ORCH_AGENT_MODEL_REVIEWER=
+ORCH_AGENT_MODEL_TESTER=
+ORCH_AGENT_MODEL_DEPLOYER=
+# Effort split (ORCH-081/ORCH-52h): thinking agents (analyst/architect/reviewer)
+# -> high; developer -> xhigh (coding/agentic role, Opus 4.8 canon); mechanical
+# agents (tester/deployer) -> medium. NB: an empty ORCH_AGENT_EFFORT_*= no longer
+# zeroes the effort — the launcher falls back to a per-role floor (= the config.py
+# class-default) so each role still runs at its canonical level (ORCH-081).
+ORCH_AGENT_EFFORT_DEFAULT=high
+ORCH_AGENT_EFFORT_ANALYST=high
+ORCH_AGENT_EFFORT_ARCHITECT=high
+ORCH_AGENT_EFFORT_DEVELOPER=xhigh
+ORCH_AGENT_EFFORT_REVIEWER=high
+ORCH_AGENT_EFFORT_TESTER=medium
+ORCH_AGENT_EFFORT_DEPLOYER=medium
+# Optional --fallback-model used when the primary is overloaded. Empty -> no flag
+# (G4 NOT enabled, ADR-001 ORCH-74: determinism — all agents stay on opus-4-8). A
+# non-empty value is validated by the SAME predicate as the model; a typo is dropped.
+ORCH_AGENT_FALLBACK_MODEL=
 # ORCH-042/ORCH-067: live-tracker mode. bump (DEFAULT since ORCH-067) -> on every
 # update the old card is deleted and a fresh one is sent silently to the BOTTOM of
 # the chat (deleteMessage + sendMessage + repoint), so the current status is always
@@ -50,6 +91,49 @@ ORCH_MERGE_RETEST_TARGET=tests/
 ORCH_MERGE_LOCK_TIMEOUT_S=300
 ORCH_MERGE_DEFER_DELAY_S=60
 ORCH_MERGE_DEFER_MAX_ATTEMPTS=5
+# ORCH-026 Level A: unconditional pre-merge rebase. With the flag ON (default),
+# check_branch_mergeable ALWAYS rebases the branch onto origin/main under the held
+# merge-lease (not only when behind) — a deterministic structural anti-phantom on
+# the scheduler edge. No-op on an up-to-date branch (rebase keeps HEAD, force-with-
+# lease -> "Everything up-to-date", CI not triggered). Scope = ORCH_MERGE_GATE_REPOS.
+#   PREMERGE_REBASE_ALWAYS=false -> strictly pre-ORCH-026 (rebase only when behind).
+ORCH_PREMERGE_REBASE_ALWAYS=true
+# ORCH-026 Level B: declarative task dependencies ("B waits for A"). claim_next_job
+# gates jobs whose depends-on tasks are not yet 'done' (additive job_deps table,
+# NOT EXISTS) WITHOUT occupying a max_concurrency slot. Inert on an empty job_deps.
+#   TASK_DEPS_ENABLED=false -> claim query is 1:1 the ORCH-1 query (no gate).
+#   TASK_DEPS_SOURCE=db|plane|hybrid -> declaration source; db (default) never calls
+#     Plane on the hot path; plane/hybrid ingest Plane `blocked-by` relations and
+#     cache them into job_deps (the scheduler then reads only the DB).
+ORCH_TASK_DEPS_ENABLED=true
+ORCH_TASK_DEPS_SOURCE=db
+# ORCH-071/073: merge-verify under-gate on the `deploy -> done` edge (врезка in
+# advance_stage, NOT a new STAGE_TRANSITIONS edge / registered QG). A deterministic
+# merge-actor merges the feature code-PR via the Gitea PR-merge API (never push/
+# force-push to main), then `done` is allowed ONLY when the deployed SHA is proven an
+# ancestor of origin/main (ORCH-073 FR-1: SHA-in-main is the single criterion; a
+# merged PR alone no longer confirms). A secondary regression guard then checks a
+# declarative marker set (MAIN_REGRESSION_MARKERS) is still in origin/main; a missing
+# marker -> alert + HOLD (NOT done), a git error of the grep itself -> fail-open.
+#   MERGE_VERIFY_ENABLED      -> global kill-switch (false -> strictly pre-ORCH-071).
+#   MERGE_VERIFY_REPOS        -> CSV of repos where the under-gate is REAL; empty ->
+#                                only the self-hosting repo (orchestrator); non-self -> no-op.
+#   MERGE_PR_TIMEOUT_S        -> per Gitea list/merge HTTP call timeout.
+#   MERGE_VERIFY_TIMEOUT_S    -> git fetch/merge-base timeout for the ancestor + marker checks.
+#   REGRESSION_GUARD_ENABLED  -> kill-switch for the ORCH-073 main-integrity regression
+#                                guard (false -> SHA-in-main alone gates done); reuses the
+#                                merge-verify scope, so non-self repos are a no-op.
+#   MERGE_VERIFY_AUTOCREATE_PR_ENABLED -> ORCH-082: guarantee an open code-PR
+#                                (head==branch, base==main) via merge_gate.ensure_open_pr
+#                                BEFORE the deterministic merge_pr (fixes the false HOLD
+#                                "no open PR"). false -> exactly pre-ORCH-082 behaviour.
+#                                Reuses the merge-verify scope; non-self repos -> no-op.
+ORCH_MERGE_VERIFY_ENABLED=true
+ORCH_MERGE_VERIFY_REPOS=
+ORCH_MERGE_PR_TIMEOUT_S=60
+ORCH_MERGE_VERIFY_TIMEOUT_S=60
+ORCH_REGRESSION_GUARD_ENABLED=true
+ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED=true
 # ORCH-036: executable self-deploy of the `deploy` stage. For the self-hosting repo
 # (orchestrator) the stage REALLY restarts prod (8500) via a detached host hook;
 # deploy_status: SUCCESS means proven health-ok, not an LLM declaration. Three
@@ -213,3 +297,10 @@ ORCH_POST_DEPLOY_FAIL_THRESHOLD=3
 ORCH_POST_DEPLOY_5XX_THRESHOLD=0.5
 ORCH_POST_DEPLOY_AUTO_ROLLBACK=false
 ORCH_POST_DEPLOY_BASE_URL=http://localhost:8500
+
+# ── QG-0 entry validation (ORCH-069) ──────────────────────────────────────────
+# Upper title-length limit for the QG-0 entry gate (_qg0_errors). The old 80-char
+# cap was a hygiene limit, not structural (slug is cut to [:30] independently, the
+# DB title TEXT is unbounded). Default 200. An invalid/empty value gracefully
+# degrades to 200 (the process never crashes on startup).
+ORCH_QG0_TITLE_MAX=200

.env.staging.example

@@ -50,3 +50,6 @@ ORCH_QUEUE_POLL_INTERVAL=2.0
 DEPLOY_SSH_USER=slin
 DEPLOY_SSH_HOST=127.0.0.1
 DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
+
+# QG-0 entry title-length limit (ORCH-069). Default 200; invalid/empty -> 200.
+ORCH_QG0_TITLE_MAX=200

.gitattributes

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

.openclaw/agents/analyst.md

@@ -1,7 +1,6 @@
 ---
 name: analyst
 description: Бизнес-аналитик. Создаёт пакет документов анализа для work item.
-model: claude-sonnet-4-6
 tools:
   - Filesystem (Read везде; Write только docs/work-items/<plane-id>/*)
   - Bash (git log, grep — только для чтения контекста)

.openclaw/agents/architect.md

@@ -1,7 +1,6 @@
 ---
 name: architect
 description: Архитектор системы. Принимает архитектурные решения по ТЗ, фиксирует как ADR.
-model: claude-opus-4-7
 tools:
   - Filesystem (Read везде; Write только docs/)
   - Bash (read-only: grep, git log)

.openclaw/agents/deployer.md

@@ -1,7 +1,6 @@
 ---
 name: deployer
 description: DevOps-агент. Запускает staging-проверку и/или прод-деплой. Пишет 15-staging-log.md и 14-deploy-log.md.
-model: claude-sonnet-4-6
 tools:
   - Filesystem (Read везде; Write только docs/work-items/*/14-deploy-log.md, docs/work-items/*/15-staging-log.md)
   - Bash (docker, git, curl, ssh)

.openclaw/agents/developer.md

@@ -1,7 +1,6 @@
 ---
 name: developer
 description: Senior разработчик. Реализует ТЗ по ADR, пишет тесты, открывает PR.
-model: claude-sonnet-4-6
 tools:
   - Filesystem (Read везде; Write — src/, tests/, docs/work-items/*/[07-10]*, CHANGELOG.md)
   - Git (commit, push; merge запрещён)

.openclaw/agents/reviewer.md

@@ -1,7 +1,6 @@
 ---
 name: reviewer
 description: Senior code reviewer. Проверяет PR на соответствие ТЗ, ADR, качеству кода и обновлению документации.
-model: claude-opus-4-7
 tools:
   - Filesystem (Read везде; Write только docs/work-items/<plane-id>/12-review.md)
   - Git (read-only: log, diff, blame)

.openclaw/agents/tester.md

@@ -1,7 +1,6 @@
 ---
 name: tester
 description: QA-инженер. Прогоняет тесты, оформляет отчёт.
-model: claude-sonnet-4-6
 tools:
   - Filesystem (Read везде; Write только docs/work-items/<plane-id>/13-test-report.md)
   - Bash (pytest, curl)

CLAUDE.md

@@ -6,8 +6,8 @@
 ## Стек
 - Backend: FastAPI + uvicorn (Python 3.12)
 - БД: SQLite (`src/db.py`)
-- Агенты: Claude CLI (`ORCH_CLAUDE_BIN`), по одному промпту на роль в `.openclaw/agents/`
-- Очередь задач: собственная (SQLite `jobs`, `src/queue_worker.py`, ORCH-1)
+- Агенты: Claude CLI (`ORCH_CLAUDE_BIN`), по одному промпту на роль в `.openclaw/agents/`. **ORCH-74:** модель/эффорт агента берутся ТОЛЬКО из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41) — frontmatter `model:` удалён как мёртвый, frontmatter описательный; имя модели валидируется форматом `^claude-…$` перед `--model` (never-break).
+- Очередь задач: собственная (SQLite `jobs`, `src/queue_worker.py`, ORCH-1). **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота `max_concurrency`; декларации/детект циклов — leaf `src/task_deps.py` (kill-switch `ORCH_TASK_DEPS_ENABLED`). Сериализация мержа одного репо — безусловный pre-merge rebase под merge-lease (`ORCH_PREMERGE_REBASE_ALWAYS`).
 - Контейнеризация: Docker + Compose
 - CI/CD: Gitea Actions (`.gitea/workflows/`)
 - Деплой: docker compose на mva154
@@ -54,6 +54,10 @@ created → analysis → architecture → development → review → testing →
 - **Кликабельный номер задачи** (`plane_issue_link`) — `ORCH-NNN` в карточке И во всех
   уведомлениях (`notify_*`, alert'ы стадий) рендерится как `<a href=…>` на issue в Plane;
   fail-safe → просто `html.escape(номер)`, если ссылку построить нельзя. Никогда не падает.
+- **Без link-preview (ORCH-080):** оба примитива (`send_telegram`/`edit_telegram`) шлют
+  payload с `disable_web_page_preview: True` — баннер Plane («Modern project management»)
+  под кликабельной ссылкой `ORCH-NNN` больше не разворачивается ни в карточке (`bump`/`edit`),
+  ни в notify/alert-сообщениях. `parse_mode: HTML` сохранён → ссылка остаётся кликабельной.
 - Транспорт (`send_telegram`/`edit_telegram`/`delete_telegram`), `disable_notification`
   (карточка тихая, пингуют только alert-хелперы), схема БД — не трогаются.
 

README.md

@@ -136,6 +136,7 @@ uvicorn src.main:app --reload --port 8500
 | `ORCH_RECONCILE_GRACE_OVERRIDES_JSON` | Per-stage пороги, напр. `{"development":300}` | `""` |
 | `ORCH_RECONCILE_NOTIFY_UNBLOCK` | Telegram при разблокировке застрявшей задачи | `true` |
 | `ORCH_RECONCILE_SKIP_BLOCKED_ENABLED` | F-1 Guard 2 (ORCH-060): пропуск задач в Plane-статусе Blocked / Needs Input; `false` глушит только сетевой Guard 2 (Guard 1 escalated всегда активен) | `true` |
+| `ORCH_QG0_TITLE_MAX` | Верхний лимит длины заголовка QG-0 (вход `_qg0_errors`); невалидное/пустое значение → дефолт (ORCH-069) | `200` |
 
 ## Очередь задач (ORCH-1 / F-2b)
 

docs/architecture/README.md

@@ -9,11 +9,11 @@
 - **Stage Engine** (`src/stage_engine.py`) — исполнение переходов, диспетчеризация QG (`_run_qg`), откаты, синхронизация с Plane.
 - **Review/Test Parsers** (`src/review_parse.py`, ORCH-046) — defensive-извлечение дословного must-fix текста из артефактов для встраивания в `task_desc` заворота: `extract_review_findings` (P0/P1 из `12-review.md`), `extract_test_failures` (фрагмент тела `13-test-report.md`). Контракт «never raise»: любая ошибка → `""`.
 - **Quality Gates** (`src/qg/checks.py`) — проверки выхода со стадии, реестр `QG_CHECKS`.
-- **Agent Launcher** (`src/agents/launcher.py`) — запуск Claude CLI агентов в изолированном git worktree, мониторинг, auto-advance.
-- **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe.
+- **Agent Launcher** (`src/agents/launcher.py`) — запуск Claude CLI агентов в изолированном git worktree, мониторинг, auto-advance. Модель/эффорт каждого агента резолвятся из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41), а не из frontmatter промпта. **ORCH-74:** имя модели валидируется форматом `^claude-…$` (`is_valid_model`) перед `--model`; невалидное → лог + откат на следующий уровень/CLI-дефолт (never-break, как `VALID_EFFORTS` для эффорта). Тот же предикат гардит inline-чтение `--fallback-model`.
+- **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe. **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота; декларации/циклы — leaf `src/task_deps.py`.
 - **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max`→`queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`).
 - **Reconciler** (`src/reconciler.py`, ORCH-053 — реализовано, [adr-0007](adr/adr-0007-reconciler.md)) — фоновый daemon-поток (паттерн `queue_worker`), стартует/останавливается в `main.lifespan` (после `worker.start()` / перед `worker.stop()`). Реконсилирует рассинхрон «источник истины ≠ стадия задачи» при потерянном webhook. F-1 gate-side (продвигает застрявшую стадию по локальной БД через штатный `advance_stage(..., finished_agent=None)`), F-2 plane-side (опрос Plane API → `handle_*` из `plane.py`), F-3 (БД-fallback `sha→branch` в `handle_ci_status`). Источник истины — гейт/Plane, не событие; идемпотентность (active-job guard + atomic-claim + grace); kill-switch `ORCH_RECONCILE_ENABLED`. `analysis` F-1 не трогает (человеческий гейт). F-1 также пропускает escalated (retry≥лимита) и Blocked/Needs-Input задачи (ORCH-060). Наблюдаемость — блок `reconcile` в `GET /queue`.
-- **Notifications / Live-tracker** (`src/notifications.py`, ORCH-042/ORCH-067) — ОДНА live-карточка на задачу (`update_task_tracker`), обновляется на каждом переходе. Режим `ORCH_TRACKER_MODE` (дефолт `bump` с ORCH-067: delete+silent send+repoint внизу чата; `edit` — правка на месте). Карточка несёт строку Plane-статуса `📍 …` (оффлайн-ядро `plane_status_label` + best-effort live-overlay `_live_plane_branch_override`, kill-switch `ORCH_TRACKER_LIVE_STATUS`) и кликабельный номер задачи (`plane_issue_link`/`link_for` → ссылка в Plane, fail-safe на сырой номер). Все алерты, упоминающие `work_item_id`, делают номер кликабельным. Контракт всего компонента — never raises; карточка всегда silent. Детали — [internals.md](internals.md) §7.
+- **Notifications / Live-tracker** (`src/notifications.py`, ORCH-042/ORCH-067) — ОДНА live-карточка на задачу (`update_task_tracker`), обновляется на каждом переходе. Режим `ORCH_TRACKER_MODE` (дефолт `bump` с ORCH-067: delete+silent send+repoint внизу чата; `edit` — правка на месте). Карточка несёт строку Plane-статуса `📍 …` (оффлайн-ядро `plane_status_label` + best-effort live-overlay `_live_plane_branch_override`, kill-switch `ORCH_TRACKER_LIVE_STATUS`) и кликабельный номер задачи (`plane_issue_link`/`link_for` → ссылка в Plane, fail-safe на сырой номер). **ORCH-080:** оба низкоуровневых примитива (`send_telegram`/`edit_telegram`) шлют payload с `disable_web_page_preview: True` — Telegram больше не разворачивает баннер link-preview Plane под карточкой/уведомлениями; `parse_mode: HTML` сохранён (ссылка остаётся кликабельной), безусловно без kill-switch. Все алерты, упоминающие `work_item_id`, делают номер кликабельным. Контракт всего компонента — never raises; карточка всегда silent. Детали — [internals.md](internals.md) §7.
 - **Project Registry** (`src/projects.py`, ORCH-6) — Plane project id → repo + prefix; фильтрация вебхуков по проекту.
 - **Plane Sync** (`src/plane_sync.py`) — синхронизация статусов/комментариев в Plane. Резолв статусов проекта `get_project_states` (ORCH-10) кэширует `{logical_key→uuid}` per-project; **ORCH-068** добавляет в кэш-запись `{uuid→group}` (для терминал-исключения F-2) и **TTL** `ORCH_PLANE_STATES_TTL_S` (дефолт 300с; `0` → прежний lifetime-кэш) — устаревший набор статусов самозалечивается без рестарта процесса через существующий `reload_project_states()` (баг кэша после появления нового Plane-статуса). Форма возврата `get_project_states` неизменна (обратная совместимость).
 
@@ -41,6 +41,20 @@ created → analysis → architecture → development → review → testing →
 
 **Канон гейтов:** машинные вердикты читаются ТОЛЬКО из YAML-frontmatter, никогда из прозы. Лог-файлы мержатся в `origin/main` отдельным PR; гейт читает из `origin/main`.
 
+### Модель и эффорт по ролям (ORCH-41, валидация ORCH-74)
+Модель и `--effort` каждого агента берутся из config (`src/config.py`), резолвятся `launcher.resolve_agent_model` / `resolve_agent_effort` по приоритету **project-override (`projects_json` `agent_models`/`agent_efforts`) > `ORCH_AGENT_MODEL_<AGENT>`/`ORCH_AGENT_EFFORT_<AGENT>` > `*_default` > CLI-дефолт (без флага)**. **Эффорт (ORCH-081):** ниже `*_default` добавлен непустой **per-role floor** — class-default поля `agent_effort_<role>` из `config.py` (его пустой env перебить не может). Floor — строго последний уровень (ниже default) и срабатывает ТОЛЬКО когда все уровни пусты, поэтому пустые прод-`ORCH_AGENT_EFFORT_*=` (которые pydantic трактует как явное `''` и обнуляют дефолт) больше не приводят к запуску без `--effort`: каждая роль получает свой канонический пол (developer=`xhigh`, tester/deployer=`medium`, прочие=`high`). Непустой явный конфиг по-прежнему побеждает floor; опечатка вне `VALID_EFFORTS` дропается валидацией ДО floor (never-break, не маскируется). См. `docs/work-items/ORCH-081/06-adr/ADR-001-effort-resolution-floor.md`. frontmatter `model:` в `.openclaw/agents/*.md` **удалён** (ORCH-74 G1) — он был мёртвой/лживой декларацией (launcher его не читает); config — единственный источник правды о модели. Model-routing (G3) НЕ включён — все 6 агентов на `claude-opus-4-8`.
+
+| Агент | Модель | Эффорт |
+|-------|--------|--------|
+| analyst | claude-opus-4-8 | high |
+| architect | claude-opus-4-8 | high |
+| developer | claude-opus-4-8 | xhigh |
+| reviewer | claude-opus-4-8 | high |
+| tester | claude-opus-4-8 | medium |
+| deployer | claude-opus-4-8 | medium |
+
+**Валидация (ORCH-74 G2, never-break):** резолвенное имя модели проходит формат-чек `is_valid_model` (`^claude-[a-z0-9.-]+$`) перед попаданием в `--model`. Невалидное (опечатка, `gpt-4`, пустое) → `logger.warning` + откат на следующий валидный уровень (в пределе — без `--model`, CLI-дефолт); мусор **никогда** не уезжает в CLI и запуск не падает. Форма — формат-чек, а не статичный allowlist: forward-compatible (будущие `claude-*` проходят без правки кода). Тот же предикат гардит inline-чтение `--fallback-model` (`agent_fallback_model` читается мимо резолва — TRZ §4). Эффорт валидируется множеством `VALID_EFFORTS` (`low|medium|high|xhigh|max`). Fallback (G4) НЕ включён (`agent_fallback_model=""`). Детали — `docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md`.
+
 ### Условный staging-гейт (ORCH-35)
 `check_staging_status` реален только для self-hosting (`is_self_hosting_repo(repo)` → `orchestrator`); для остальных проектов → no-op `(True, "Staging gate N/A")`. Для orchestrator парсит `staging_status:` из `15-staging-log.md`; FAILED → откат на `development`. Подробнее: [ADR-0003](adr/adr-0003-staging-gate.md).
 
@@ -59,11 +73,24 @@ Self-hosting зацикливался на `deploy-staging`: `scripts/staging_ch
 
 Назначение: ветка валидируется относительно того `main`, из которого создана; параллельная задача могла уйти вперёд → семантический конфликт слияния (зелёная ветка ломает обновлённый `main`). Merge-gate гарантирует проверку против **актуального** `origin/main` перед слиянием:
 - **Догон:** ветка отстаёт (⇔ `origin/main` не предок HEAD) → `rebase origin/main` в worktree + `push --force-with-lease` (ТОЛЬКО ветка задачи; `main` — никогда). Текстовый конфликт → `rebase --abort` → откат на `development`.
+- **Безусловный pre-merge rebase (ORCH-026, A-2):** при `premerge_rebase_always` (дефолт `True`, скоуп `merge_gate_repos`) short-circuit `branch_is_behind_main` пропускается — `auto_rebase_onto_main` вызывается **всегда** под лизом. На актуальной ветке это no-op (`rebase` не меняет HEAD, `push --force-with-lease` → «Everything up-to-date», CI не триггерится); на отстающей — реальный догон. Детерминированный структурный анти-фантом на уровне планировщика (дополняет рубежи ORCH-073, не заменяет). Kill-switch `premerge_rebase_always=False` → прежнее поведение (ребейз только при behind).
 - **Re-test:** `python -m pytest` (`merge_retest_target`, дефолт `tests/`) в worktree догнанной ветки, тайм-аут `merge_retest_timeout_s`. Красный/тайм-аут → откат на `development`.
-- **Сериализация (merge-lock):** файловый **merge-lease** на репо (`<repos_dir>/.merge-lease-<repo>.json`), живёт от гейта до фактического merge. Acquire **неблокирующий** (anti-deadlock при `max_concurrency=1`): busy → **defer** (повторная постановка deployer'а на `deploy-staging` с задержкой через `available_at`), а не откат. Release — на PR-merged вебхуке / `deploy→done` / откате / по возрасту (crash-реклейм). Restart-safe; без изменения схемы БД.
+- **Сериализация (merge-lock):** файловый **merge-lease** на репо (`<repos_dir>/.merge-lease-<repo>.json`), живёт от гейта до фактического merge. Acquire **неблокирующий** (anti-deadlock при `max_concurrency=1`): busy → **defer** (повторная постановка deployer'а на `deploy-staging` с задержкой через `available_at`), а не откат. Release — на PR-merged вебхуке / `deploy→done` / откате / по возрасту (crash-реклейм). Restart-safe; без изменения схемы БД. **ORCH-026 (A-1):** это окно = «merge → main-updated» (для self `done` ⇔ SHA-in-main, ORCH-073) — пока A не в `main`, B того же репо получает `merge-lock busy` → defer. Окно сериализации per-repo НЕ переписывается; кросс-репо параллелизм сохранён (лиз — per-repo файл).
 - **Условность (как ORCH-35):** реален для `orchestrator`; прочие репо — no-op. Флаги `merge_gate_enabled` / `merge_gate_repos` — поэтапный раскат. Контракт **never-raise**.
 
 Подробнее: [adr-0006](adr/adr-0006-merge-gate.md), детально — `docs/work-items/ORCH-043/06-adr/ADR-001-merge-gate.md`.
+Безусловный pre-merge rebase + связь с зависимостями задач — [adr-0015](adr/adr-0015-task-deps-and-merge-serialization.md) (ORCH-026).
+
+### Зависимости задач: B ждёт A (ORCH-026, Уровень B)
+Плоская очередь ORCH-1 (FIFO по `id` + `available_at` + `max_concurrency`) не выражала логических зависимостей. ORCH-026 вводит декларативные связи «задача B не стартует, пока не готовы её depends-on» — без новой стадии и без изменения `STAGE_TRANSITIONS`/`QG_CHECKS`.
+- **Источник истины планировщика — БД** (аддитивная таблица `job_deps(task_id, depends_on_task_id)`): claim в горячем цикле обслуживает очередь ВСЕХ проектов и обязан быть offline-устойчив (сетевой Plane на каждый claim = встанет очередь всех проектов). Источник **декларации** настраивается `task_deps_source = db|plane|hybrid` (дефолт `db`; `plane`/`hybrid` читают Plane relations в `handle_work_item_created` и кэшируют в `job_deps`).
+- **Гейт планировщика (`claim_next_job`)** — условие `NOT EXISTS (job_deps d JOIN tasks t … WHERE d.task_id=j.task_id AND t.stage!='done')` при `task_deps_enabled`: задача с незавершённой зависимостью **не выбирается** (агент не запускается, слот `max_concurrency` не занимается). Инертно при пустой `job_deps` → нулевая регрессия; kill-switch `task_deps_enabled=False` → запрос 1:1 как ORCH-1.
+- **Детект дедлоков** — DFS-цикл-детектор (leaf `src/task_deps.py::detect_cycle`) при вставке связи + backstop в `reconciler`; цикл → `set_issue_blocked` + alert (Telegram/Plane) с перечислением цикла. Поток остальных задач не блокируется.
+- **Видимость** — строка «⏳ ждёт ORCH-NNN» в Telegram-карточке (`update_task_tracker`, never-raise); Plane `Blocked` — на дедлоке (не на нормальном коротком ожидании, чтобы не флаппить). Инвариант «одна карточка на задачу» сохранён.
+- **Совместимость:** `reconciler` F-1 пропускает dep-заблокированные задачи (`is_task_ready`, паттерн ORCH-060); `reaper` сканирует только `running` → dep-блок остаётся `queued`, не трогается. Зависимости — только intra-repo (v1).
+- **Наблюдаемость:** блок `task_deps` в `GET /queue` (заблокированные задачи, держатель merge-lease, defer-счётчики, обнаруженные циклы) — read-only.
+
+Подробнее: [adr-0015](adr/adr-0015-task-deps-and-merge-serialization.md), детально — `docs/work-items/ORCH-026/06-adr/ADR-001-merge-serialization-and-task-deps.md`.
 
 ### Исполняемый самодеплой стадии `deploy` (ORCH-36)
 `deploy` перестаёт быть «бумажной»: для self-hosting (`is_self_hosting_repo`) стадия
@@ -140,25 +167,77 @@ merge-в-main вообще**. Detached host-деплой лишь retag'ал о
 - **Merge в Phase C (после рестарта), НЕ в Phase B** — finalizer restart-surviving (claim воркером
   нового контейнера, re-drive reaper'ом), merge физически строго ПОСЛЕ рестарта прода → рестарт его
   не убивает (G3 «шаг, переживающий рестарт»; постмортем-урок №3).
-- **Merge-актор `merge_gate.merge_pr`** — `pr_already_merged` (no-op повтор, ORCH-065) → иначе
-  Gitea `POST /repos/{owner}/{repo}/pulls/{index}/merge`. Никогда push/force-push в `main`.
-- **Верификатор `merge_gate.verify_merged_to_main`** — `PR.merged==true` ИЛИ
-  `git merge-base --is-ancestor <validated_sha> origin/main` (`validated_revision` — тот же якорь,
-  что у ORCH-058). never-raise → `False`.
+- **Merge-актор `merge_gate.merge_pr`** — `pr_already_merged` (idempotency no-op повтор) → иначе
+  Gitea `POST /repos/{owner}/{repo}/pulls/{index}/merge`. Выбор PR строго по `head.ref==branch`
+  И `base.ref=="main"`. Никогда push/force-push в `main`.
+- **Верификатор `merge_gate.verify_merged_to_main` (семантика ORCH-073, FR-1):** подтверждение —
+  **ТОЛЬКО** `git merge-base --is-ancestor <validated_sha> origin/main` (`validated_revision` —
+  якорь ORCH-058). PR-флаг `pr_already_merged` **больше НЕ подтверждает merge** (удалён из verify):
+  он понижен до idempotency-guard `merge_pr` и засчитывает merged PR лишь при `head.ref==branch`
+  И `base.ref=="main"` (исключает авто docs-PR). Пустой SHA / git-ошибка → `False` (fail-closed),
+  never-raise.
+- **Регресс-гард целостности `main` (ORCH-073, FR-5):** `merge_gate.check_main_regression` в
+  `_handle_merge_verify` ПОСЛЕ подтверждённого SHA-в-main и ДО `done` проверяет, что `origin/main`
+  содержит декларативный набор маркеров ранее-merged задач (`MAIN_REGRESSION_MARKERS`,
+  `git grep -c <marker> origin/main -- <path>` > 0). Маркер отсутствует → alert «main regressed» +
+  HOLD (НЕ `done`, ALERT-only). Fail-open на git-ошибке грепа (регресс — только при `count==0`).
+  Kill-switch `regression_guard_enabled`; non-self → no-op. Набор — append-only константа,
+  значимая задача дописывает свой маркер.
 - **Не подтверждено → alert «deploy succeeded but not merged» (Telegram+Plane) + HOLD**
   (`set_issue_blocked`, задача НЕ `done`, БЕЗ авто-отката на `development` — not-merged есть
   инфра-дефект, реакция ALERT-only как ORCH-021 self-hosting). Подтверждено → штатный `deploy →
   done` + `merged_to_main: true` во frontmatter `14-deploy-log.md` (`deploy_status:` нетронут).
+- **Защита от CHANGELOG-затирания (ORCH-073, FR-4):** корневой `.gitattributes` с
+  `CHANGELOG.md merge=union` → правки `## [Unreleased]` авто-сливаются при `auto_rebase_onto_main`
+  без конфликта, ветка не откатывается в `development` и не тащит устаревший код-сосед. `docs/**`
+  под union НЕ ставится (union только для append-only).
 - **Условность как ORCH-35/43/58:** `merge_verify_enabled` (kill-switch, дефолт `true`) +
   `merge_verify_repos` (пусто → только self-hosting); non-self — no-op, merge остаётся за `deployer`.
-  never-raise; идемпотентность (`pr_already_merged`, INV-5); ручной approve сохранён (`Confirm Deploy`).
+  never-raise; идемпотентность по **SHA-в-main** (INV-4, не «любой merged PR»); ручной approve
+  сохранён (`Confirm Deploy`).
 - **Инварианты:** `STAGE_TRANSITIONS`, `check_deploy_status`/`_parse_deploy_status`, реестр
   `QG_CHECKS` (под-гейт — врезка в `advance_stage`, НЕ новый зарегистрированный QG), схема БД,
   БАГ-8, terminal-sync, merge-gate, image-freshness, exit-коды хука — **без изменений**.
   Диагностика фантома — runbook `docs/operations/PHANTOM_MERGE_RUNBOOK.md` (4 проверки постмортема).
 
-Подробнее: [adr-0013](adr/adr-0013-merge-verify-gate.md), детально —
-`docs/work-items/ORCH-071/06-adr/ADR-001-merge-verify-gate.md`.
+Подробнее: [adr-0013](adr/adr-0013-merge-verify-gate.md) +
+[adr-0014](adr/adr-0014-merge-verify-sha-source-of-truth.md) (amends 0013 — SHA-в-main как
+единственный критерий + регресс-гард, ORCH-073); детально —
+`docs/work-items/ORCH-071/06-adr/ADR-001-merge-verify-gate.md`,
+`docs/work-items/ORCH-073/06-adr/ADR-001-merge-verify-sha-truth-and-regression-guard.md`.
+
+#### Гарантированный код-PR перед merge-verify (ORCH-082 — фикс ложного HOLD «no open PR»)
+Под-гейт merge-verify (ORCH-071/073) детерминированно мержит **открытый** код-PR ветки в `main`
+(`merge_pr`, фильтр `head.ref==branch` И `base.ref=="main"`). Но конвейер **не гарантировал**, что
+к моменту merge у ветки этот PR есть: PR создаётся единственной `launcher._ensure_pr` **только** на
+developer-пути и **только** при свежем worktree-коммите. На деплое ORCH-074 (08.06, первая задача
+после ручных восстановлений `main`) у ветки не оказалось открытого код-PR → `merge_pr` вернул
+`("False", "no open PR")` → защита ORCH-073 верно удержала задачу (HOLD, не ложный `done`), но это
+лечило следствие. ORCH-082 закрывает **отсутствующий инвариант** «к merge-verify у ветки есть
+открытый код-PR» аддитивно, внутри того же под-гейта, не трогая машину стадий:
+- **Новый leaf-актор `merge_gate.ensure_open_pr(repo, branch) -> (status, detail)`** (never-raise):
+  `GET …/pulls?state=open` с фильтром `head.ref==branch` И `base.ref=="main"` (**идентичен**
+  `merge_pr`/ORCH-073 FR-3 — авто-docs-PR `base != main` НЕ код-PR) → `("existed", N)`; иначе
+  `POST …/pulls` → `("created", N)`; гонка «PR exists»/409/422 → повторный GET → `existed` (без
+  дублей); любая иная ошибка → `("failed", reason)`.
+- **Врезка в `_handle_merge_verify`** ПОСЛЕ резолва `validated_revision` и **ПЕРЕД** `merge_pr`:
+  `created|existed` → штатно к `merge_pr` → `verify_merged_to_main`; `failed` → честный HOLD+alert
+  через новый helper `_hold_pr_create_failed` (текст «PR создать не удалось» — отличим от
+  not-merged HOLD; `result.note="pr-create-failed-hold"`), задача остаётся на `deploy`, БЕЗ отката
+  на development.
+- **Защита ORCH-073 неприкосновенна и приоритетна:** подтверждение merge остаётся ТОЛЬКО
+  `verify_merged_to_main` (SHA-в-main) + `check_main_regression`; `ensure_open_pr` устраняет лишь
+  **ложный** HOLD «no open PR», но не маскирует реально невлитый код (тот → HOLD как прежде).
+- **`launcher._ensure_pr`** рекомендуется делегировать в `ensure_open_pr` (единый код создания PR),
+  сохранив прежний триггер «только developer-путь».
+- **Условность как ORCH-35/43/58/71:** kill-switch `merge_verify_autocreate_pr_enabled` (дефолт
+  `true`); область — `merge_verify_applies(repo)` (self-hosting / `merge_verify_repos`); non-self —
+  no-op. `False` → поведение ORCH-074 1:1. Идемпотентность из Gitea (наличие открытого PR), **без
+  миграции БД** (restart-safe). `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, `check_deploy_status`,
+  exit-коды хука, merge-gate, image-freshness — без изменений; `main` не push/force-push.
+
+Подробнее: [adr-0016](adr/adr-0016-ensure-open-pr-before-merge-verify.md) (amends 0013/0014);
+детально — `docs/work-items/ORCH-082/06-adr/ADR-001-ensure-open-pr-before-merge-verify.md`.
 
 ### Post-deploy наблюдение прода + реакция на деградацию (ORCH-021 — реализовано)
 Конвейер заканчивался на `deploy → done` и **забывал про прод**: «успех» = health-check
@@ -272,6 +351,18 @@ helper `validated_revision` питает и штамп A, и `EXPECTED_REVISION`
   ET-013) и (2) в явном Plane-статусе **Blocked** / **Needs Input** (Вариант A —
   запрос Plane API, без миграции БД; never-raise → консервативный skip). Гард
   retry-count проверяется первым (дёшево, локальный SQL).
+  **ORCH-086 (закрытие F-1-пробела ORCH-068):** терминал-исключение и `state_uuid`-dedup
+  (изначально только F-2) распространены на F-1. После дешёвых локальных гардов F-1 делает
+  **один** резолв Plane-статуса задачи на тик (общий fetch для Guard 2 + терминал-скипа +
+  `_note_unblock`); терминальная задача (группа Plane `completed`/`cancelled`, fallback —
+  логические ключи `done`/`cancelled`, ЛИБО стадия в БД орка ∈ `{done, cancelled}`) →
+  **безусловный** ранний скип (`skipped_terminal_total++`, без `advance`/уведомления; не подчинён
+  `reconcile_skip_blocked_enabled`). Вызов `_note_unblock` на F-1 теперь передаёт `state_uuid` →
+  in-memory dedup работает на обоих путях (страховка от повтора после рестарта). Лечит
+  периодическое ложное «ET-002 done разблокирована (потерян webhook)» для терминальных в Plane
+  задач (enduro/orchestrator), сохраняя легитимный unblock реально застрявшей не-терминальной
+  задачи. `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД/сигнатуры/новые флаги — без изменений. Детали —
+  `docs/work-items/ORCH-086/06-adr/ADR-001-reconciler-f1-terminal-skip-and-dedup.md`.
 - **F-2 plane-side:** опрос Plane API per-project → `handle_status_start` /
   `handle_verdict` из `webhooks/plane.py` (логика не дублируется).
   **ORCH-068 (livelock-fix):** (1) задачи в **терминальной группе** Plane
@@ -433,6 +524,7 @@ Monitoring after Deploy → Done
 - `tasks` — задачи и их стадии
 - `agent_runs` — запуски агентов (run_id, usage, cost)
 - `jobs` — очередь задач (ORCH-1); колонка `pid` (ORCH-065) — pid агентского процесса для liveness-детекции зомби job-reaper'ом
+- `job_deps` — декларативные зависимости задач (ORCH-026, Уровень B): `(task_id, depends_on_task_id)`, аддитивная; источник истины планировщика для гейта «B ждёт A»
 
 ## Изоляция (git worktree, ORCH-2)
 Каждая задача исполняется в отдельном git worktree, ветки не пересекаются. Репозитории проектов разделены под `/repos/<project>`.

docs/architecture/adr/README.md

@@ -17,11 +17,18 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | adr-0009 | Толерантность staging-вердикта к инфраструктурным FAIL | accepted | 2026-06-07 | ORCH-061 |
 | adr-0010 | Post-deploy мониторинг прода + реакция на деградацию | proposed | 2026-06-07 | ORCH-021 |
 | adr-0011 | Job-reaper + проактивный реклейм merge-lease | accepted | 2026-06-07 | ORCH-065 |
+| adr-0012 | Security-гейт (secrets/deps) | accepted | 2026-06-08 | ORCH-022 |
+| adr-0013 | Merge-в-main + пост-деплой верификация как условие `done` | accepted | 2026-06-08 | ORCH-071 |
+| adr-0014 | SHA-в-main — единственный критерий merge-verify + регресс-гард | accepted | 2026-06-08 | ORCH-073 |
+| adr-0015 | Зависимости задач (B ждёт A) + сериализация merge внутри репо | accepted | 2026-06-08 | ORCH-026 |
+| adr-0016 | ensure_open_pr — гарантированный код-PR перед merge-verify | accepted | 2026-06-09 | ORCH-082 |
 
 > ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
 > `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
 > (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
-> свободный номер (текущий максимум — `0011`).
+> свободный номер (текущий максимум — `0016`).
+> adr-0014 **amends** adr-0013 (меняет критерий merge-verify на «SHA-в-main»).
+> adr-0016 **amends** adr-0013/0014 (гарантирует открытый код-PR перед merge_pr, ORCH-082).
 
 ## Формат
 **Контекст → Решение → Альтернативы → Последствия → Связи.** Статус: proposed / accepted / superseded.

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

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

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

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

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

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

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

@@ -0,0 +1,7 @@
+# Business Request: Управление зависимостями задач (B ждёт A) в очереди
+
+Work Item ID: ORCH-026
+
+## Description
+
+TBD

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

@@ -0,0 +1,135 @@
+# 01-BRD — Управление зависимостями задач (B ждёт A) в очереди
+
+**Work Item:** ORCH-026
+**Repo:** orchestrator (self-hosting)
+**Branch:** feature/ORCH-026-b-a
+**Стадия:** analysis
+**Источник:** предложение Стрим, одобрено Славой (2026-06-04); дополнение Слава+Стрим 2026-06-08 (инцидент эрозии `main`)
+
+---
+
+## 1. Контекст и проблема
+
+### 1.1 Первопричина (мотивация СЕЙЧАС — инцидент 08.06)
+Эрозия `main` 08.06 (потеря кода ORCH-067/069, фантом-merge) родилась НЕ из логических
+зависимостей, а из **некоординированного параллелизма**: несколько self-hosting задач
+(ORCH-067/069/071) одновременно срезали ветки от `main` и правили общие файлы
+(`CHANGELOG.md`, `notifications.py`, `config.py`). Последствия:
+
+- CHANGELOG-конфликты на `auto_rebase` → откаты `deploy-staging → development` (дорого:
+  ORCH-069 = 3 попытки = $3.98);
+- тихое затирание кода соседа при merge ветки, срезанной от устаревшего `main` (фантом).
+
+**ORCH-073** закрыл ПОСЛЕДСТВИЯ (3 рубежа: CHANGELOG `merge=union` + SHA-in-main verify +
+регресс-гард маркеров). ORCH-026 должен закрыть **ПЕРВОПРИЧИНУ**: задачи одного репо не
+должны мешать друг другу в `main`.
+
+### 1.2 Исходный скоуп (плоская очередь ORCH-1)
+Очередь (`src/queue_worker.py`, ORCH-1) — плоская: `jobs` упорядочены по `id` (FIFO),
+гейтятся только `available_at` и `max_concurrency`. Нельзя выразить «задача B не стартует,
+пока не готова A». Декомпозиция эпиков (ORCH-025) порождает заведомо зависимые подзадачи.
+
+### 1.3 Что уже есть (опора, НЕ переписывать)
+- **ORCH-1** — персистентная очередь (`jobs`), atomic claim, `available_at`-defer, restart-safe.
+- **ORCH-065** — `merge-lease` (`src/merge_gate.py`): per-repo файловый лиз
+  `.merge-lease-<repo>.json`, неблокирующий acquire, holder-aware release, проактивный
+  реклейм мёртвого/устаревшего держателя. **Сейчас лиз держится только на ребре
+  `deploy-staging → deploy`** (от merge-gate до фактического merge).
+- **ORCH-043** — merge-gate: `branch_is_behind_main`, `auto_rebase_onto_main` (rebase
+  **только когда ветка отстаёт или при конфликте**), `retest_branch`.
+- **ORCH-073** — merge-verify: `verify_merged_to_main` (SHA-in-main), `check_main_regression`.
+- **Plane-статусы** `Blocked` / `Needs Input` + `set_issue_blocked` (`src/plane_sync.py`).
+- **Telegram live-tracker** (`src/notifications.py`) — одна карточка на задачу, уже умеет
+  показывать статус `Blocked`.
+
+---
+
+## 2. Цель (бизнес-результат)
+
+Задачи одного репозитория перестают повреждать `main` друг друга, а очередь умеет
+выражать логические зависимости между задачами — БЕЗ потери параллелизма между разными
+репозиториями и без риска для self-hosting прода.
+
+---
+
+## 3. Два уровня требований (объединить в одной задаче; приоритет — Уровень A)
+
+### Уровень A — Сериализация merge/деплоя внутри ОДНОГО репо (КРИТИЧНО, корень эрозии)
+Закрывает первопричину инцидента 08.06.
+
+- **A-1.** В рамках ОДНОГО репо merge-в-`main` + деплой должны быть **сериализованы**: пока
+  задача A не слита в `main` (и для self-hosting — не задеплоена), задача B того же репо НЕ
+  доходит до своего merge/деплоя от устаревшего `main`.
+- **A-2.** B перед своим merge-gate **обязана ребейзнуться на СВЕЖИЙ `main`** (где уже есть
+  A) — **proactive pre-merge rebase**, а не только при текстовом конфликте (как сейчас в
+  ORCH-043). Цель: B всегда несёт актуальный код предшественников → структурный анти-фантом
+  на уровне планировщика (дополняет рубежи ORCH-073, не заменяет).
+- **A-3.** Сериализация — **только внутри одного репо**. Задачи РАЗНЫХ репо (orchestrator vs
+  enduro-trails) параллелятся свободно (общая БД/очередь — пропускная способность не падает).
+- **A-4.** Механизм — минимально-инвазивный и **restart-safe** (как ORCH-1/065): переживает
+  рестарт прод-контейнера, не оставляет навсегда захваченных ресурсов (опора на проактивный
+  реклейм ORCH-065).
+- **A-5.** **Совместимость с self-hosting safety:** не ронять/не рестартить прод-контейнер
+  вне штатного deploy; гейт `Confirm Deploy` (ORCH-059) сохранён; никаких push/force-push в
+  `main`.
+- **A-6.** Защита от взаимоблокировки: B при занятой сериализации **defer** (повторная
+  постановка с задержкой через `available_at`), а НЕ откат на `development` и НЕ вечное
+  ожидание; bounded defer-бюджет (анти-livelock, как `merge_defer_max_attempts`).
+
+### Уровень B — Декларативные зависимости (исходный скоуп ORCH-26)
+- **B-1.** Задача может объявить связь `blocked-by` / `blocks` (depends-on).
+- **B-2.** Планировщик очереди (ORCH-1) **не запускает** заблокированную задачу, пока все её
+  depends-on не достигли терминального состояния (`done`).
+- **B-3.** **Защита от дедлоков:** циклические зависимости детектируются; задача в цикле не
+  «пропадает молча» — выставляется `Blocked` + alert (Telegram/Plane).
+- **B-4.** **Видимость:** заблокированная задача видна — Plane-статус `Blocked` и/или
+  ожидание в Telegram-карточке (что и кого ждёт).
+
+---
+
+## 4. Открытые вопросы для архитектора (НЕ решаются на этапе анализа)
+
+> Аналитик фиксирует требования; выбор механизма — за архитектором (ADR в `06-adr/`).
+
+1. **Где хранить связи (Уровень B):** Plane relations (родное, видимо в UI, но требует
+   сетевого запроса и зависит от Plane) vs таблица в БД (`job_deps`/поля `tasks`, надёжно и
+   offline, но дубль источника) vs **гибрид** (Plane — источник декларации, БД — кэш для
+   планировщика). Рекомендация анализа: гибрид с offline-fallback (см. §6).
+2. **Механизм сериализации (Уровень A):** глобальный per-repo merge-lock vs FIFO merge-queue
+   vs **обязательный pre-merge rebase + расширение окна merge-lease** (от «момента merge» до
+   «main-updated»). Выбрать минимально-инвазивный, restart-safe, переиспользующий ORCH-065/043.
+3. **Граница окна сериализации для self-hosting:** для не-self репо «merged в main» = конец
+   окна; для self (orchestrator) деплой асинхронный (Phase B/C, ORCH-036/071) — нужно решить,
+   до какого события держать лиз (до `merged_to_main: true` / до `done`).
+4. **Совместимость B и A:** depends-on (B) на уровне постановки в очередь vs merge-сериализация
+   (A) на уровне merge-gate — разные точки конвейера; убедиться, что не конфликтуют.
+
+---
+
+## 5. Вне скоупа (Non-goals)
+- Изменение машины стадий `STAGE_TRANSITIONS` (сериализация/зависимости — врезки/гейты, не
+  новые стадии — паттерн ORCH-043/058/071).
+- Приоритизация/перепланирование задач по весам (только зависимости и сериализация).
+- Кросс-репо зависимости (A-3 явно запрещает кросс-репо сериализацию; кросс-репо логические
+  зависимости — возможный follow-up, не v1).
+- Отмена/замена рубежей ORCH-073 — ORCH-026 их **дополняет** на уровне планировщика.
+
+---
+
+## 6. Заинтересованные стороны
+- **Owner (Слава)** — одобряет BRD; держатель self-hosting прод-риска.
+- **Стрим** — автор предложения.
+- **Конвейер агентов** — потребитель: developer/deployer работают с веткой, которую затрагивает
+  сериализация; reviewer проверяет обновление доки.
+
+---
+
+## 7. Критерии успеха (бизнес-уровень)
+- Две зелёные задачи одного репо больше не способны затереть код друг друга в `main` на уровне
+  планировщика (без участия рубежей-последствий ORCH-073).
+- Задача может объявить зависимость; заблокированная задача не стартует раньше времени и видна
+  наблюдателю.
+- Пропускная способность разных репо не деградирует.
+- Прод-контейнер orchestrator не падает и не рестартится вне штатного `Confirm Deploy`.
+
+Точные PASS/FAIL — `03-acceptance-criteria.md`.

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

@@ -0,0 +1,134 @@
+# 02-ТЗ — Управление зависимостями задач (B ждёт A) в очереди
+
+**Work Item:** ORCH-026 · **Repo:** orchestrator · **Стадия:** analysis
+
+> ТЗ фиксирует ТРЕБОВАНИЯ к изменениям (модули, контракты, артефакты). Конкретный механизм
+> сериализации и место хранения связей — решение архитектора (ADR в `06-adr/`); ниже отмечены
+> как «КАНДИДАТ / решает архитектор». Аналитик не предлагает архитектуру.
+
+---
+
+## 1. Задействованные модули `src/`
+
+| Модуль | Роль в задаче | Уровень |
+|--------|---------------|---------|
+| `src/queue_worker.py` | Планировщик: `_drain_once` / `claim_next_job` — точка учёта зависимостей и сериализации при выборе job. | A + B |
+| `src/db.py` | Очередь `jobs` / `tasks`; `claim_next_job`, `enqueue_job`, `count_running_jobs`. Кандидат на хранение связей и блокировки claim. | A + B |
+| `src/merge_gate.py` | merge-lease (ORCH-065), `branch_is_behind_main` / `auto_rebase_onto_main` (ORCH-043) — опора для proactive pre-merge rebase и расширения окна сериализации. | A |
+| `src/qg/checks.py` | `check_branch_mergeable` (под-гейт ребра `deploy-staging → deploy`) — точка форсированного pre-merge rebase. | A |
+| `src/stage_engine.py` | `advance_stage` — врезки гейтов; точка интеграции сериализации/верификации. | A |
+| `src/webhooks/plane.py` | `handle_work_item_created` / `start_pipeline` — приём задачи; точка чтения relations (если источник — Plane). | B |
+| `src/plane_sync.py` | `set_issue_blocked`, `get_project_states` (`blocked`/`needs_input`), relations API. | B |
+| `src/notifications.py` | live-карточка: индикация `Blocked` / «ждёт ORCH-NNN». | B |
+| `src/config.py` | Новые kill-switch + scope-настройки (паттерн `*_enabled` / `*_repos`). | A + B |
+| `src/reconciler.py` / `src/job_reaper.py` | Не ломать: skip заблокированных задач (как уже делается для Blocked/Needs-Input, ORCH-060/068); реклейм ресурсов сериализации. | A + B |
+
+---
+
+## 2. Требования к изменениям — Уровень A (сериализация merge/деплоя)
+
+### 2.1 Proactive pre-merge rebase (A-2)
+- На ребре `deploy-staging → deploy`, ДО фактического merge (в составе `check_branch_mergeable`
+  или соседнего под-гейта), ветка задачи **всегда** догоняется на свежий `origin/main` —
+  **не только при `branch_is_behind_main`/конфликте**.
+- Переиспользовать `merge_gate.auto_rebase_onto_main` (rebase + `push --force-with-lease`
+  ТОЛЬКО ветки задачи). Текстовый конфликт → существующий контракт: `rebase --abort` → откат на
+  `development` (как ORCH-043).
+- **Инвариант:** никаких push/force-push в `main`.
+
+### 2.2 Расширение окна merge-lease (A-1, A-3, A-4)
+- **КАНДИДАТ (решает архитектор):** держать per-repo merge-lease (ORCH-065) не только «на
+  момент merge», а на окно **«merge → main-updated»** (для self — до подтверждения
+  `merged_to_main: true` / `done`), чтобы B не дошла до своего merge, пока A не в `main`.
+- Acquire — **неблокирующий** (как сейчас): занято → **defer** задачи B через
+  `enqueue_job(available_at_delay_s=...)`, bounded бюджет (анти-livelock; ср.
+  `merge_defer_max_attempts`). Откат на `development` НЕ применять для defer.
+- Release — holder-aware (как `release_merge_lease`), на merged-вебхуке / `deploy→done` /
+  откате / по проактивному реклейму (ORCH-065 `reclaim_stale_lease`).
+- Сериализация **строго per-repo** (`.merge-lease-<repo>.json`) — кросс-репо параллелизм не
+  затрагивается (A-3).
+
+### 2.3 Условность и безопасность (A-5)
+- Реально только для применимых репо: kill-switch + CSV-scope (паттерн `merge_gate_repos` /
+  `merge_verify_repos`; пусто → только self-hosting `orchestrator`).
+- `STAGE_TRANSITIONS`, `Confirm Deploy` (ORCH-059), exit-коды deploy-хука, БАГ-8,
+  terminal-sync — **без изменений**.
+- Контракт **never-raise** для всех новых функций (как соседи в `merge_gate.py`).
+
+---
+
+## 3. Требования к изменениям — Уровень B (декларативные зависимости)
+
+### 3.1 Декларация связи (B-1)
+- **КАНДИДАТ хранения (решает архитектор, см. BRD §4.1):**
+  - вариант Plane relations: читать `blocked-by` через Plane API в `handle_work_item_created`;
+  - вариант БД: новая таблица `job_deps(task_id, depends_on_task_id)` или поле в `tasks`
+    (idempotent `_ensure_column` миграция, как ORCH-065 `jobs.pid`);
+  - гибрид: Plane — декларация, БД — кэш для планировщика (offline-устойчивость).
+- Миграция БД (если выбран вариант с таблицей/колонкой) — **только аддитивная**
+  (`CREATE TABLE IF NOT EXISTS` / `_ensure_column`), безопасная на живой прод-БД с общими
+  данными enduro-trails.
+
+### 3.2 Гейт планировщика (B-2)
+- При выборе job (`claim_next_job` / `_drain_once`) задача с незавершёнными depends-on
+  **не клеймится** (аналог `available_at`-gate): пропускается до тех пор, пока все depends-on
+  не `done`. Не должна занимать слот `max_concurrency`.
+- Реализация — **leaf-функция** с чистой логикой «готова ли задача к запуску» (тестируемо
+  юнитами, never-raise), по образцу `staging_verdict.py` / `post_deploy.py`.
+
+### 3.3 Защита от дедлоков (B-3)
+- Детектор циклов в графе depends-on (DFS/обнаружение цикла) — чистая функция, юнит-тестируемая.
+- Цикл → задача(и) НЕ запускается молча: `set_issue_blocked` + alert (Telegram/Plane) с
+  указанием цикла. Не блокировать поток других задач.
+
+### 3.4 Видимость (B-4)
+- Заблокированная задача: Plane-статус `Blocked` (`set_issue_blocked`) и/или строка ожидания в
+  Telegram-карточке («⏳ ждёт ORCH-NNN»). Использовать существующий механизм карточки
+  (`notifications.update_task_tracker`), контракт never-raise / silent.
+- `reconciler` F-1 уже пропускает Blocked/Needs-Input (ORCH-060/068) — убедиться, что новые
+  заблокированные-по-зависимости задачи тоже пропускаются (не «разблокируются» ошибочно).
+
+---
+
+## 4. Изменения API (endpoints)
+- **Новые HTTP endpoints не требуются.**
+- **Наблюдаемость:** расширить снимок `GET /queue` блоком о зависимостях/сериализации
+  (по образцу блоков `reconcile` / `reaper` / `post_deploy` / `merge_verify`): кол-во
+  заблокированных задач, держатель merge-lease, defer-счётчики, обнаруженные циклы. Read-only,
+  никогда не источник истины для решений.
+
+## 5. Изменения схемы БД
+- **КАНДИДАТ (если выбран БД/гибрид для Уровня B):** аддитивная таблица `job_deps` или колонка
+  в `tasks` (см. §3.1). Только `CREATE TABLE IF NOT EXISTS` / `_ensure_column`. Без изменения
+  существующих колонок `jobs`/`tasks`. Restart-safe, безопасно на общей прод-БД.
+- Уровень A (сериализация) — **без изменения схемы БД** (merge-lease файловый, как ORCH-065).
+
+## 6. Требования к новым QG checks
+- **Новый зарегистрированный QG-чек НЕ вводится** (паттерн ORCH-071/058: под-гейт — врезка в
+  `advance_stage` или расширение `check_branch_mergeable`, а не новая запись в `QG_CHECKS`).
+- Реестр `QG_CHECKS` — без изменений.
+
+## 7. Конфигурация (`src/config.py`)
+Новые настройки по паттерну `*_enabled` (kill-switch) + `*_repos` (CSV scope, пусто →
+self-hosting). КАНДИДАТ-имена (финализирует архитектор):
+- Уровень A: `merge_serialize_enabled` / `merge_serialize_repos` (или расширение
+  `merge_gate_*`); опционально `premerge_rebase_always` (вкл proactive rebase).
+- Уровень B: `task_deps_enabled` / `task_deps_source` (`plane|db|hybrid`).
+Дефолты — обратная совместимость (для не-self репо — прежнее поведение).
+
+## 8. Артефакты pipeline (создать/обновить В ТОМ ЖЕ PR)
+- `06-adr/ADR-001-*.md` — решение по сериализации (A) и хранению зависимостей (B).
+- Обновить `docs/architecture/README.md` (раздел про очередь/merge-gate/сериализацию).
+- Обновить `CLAUDE.md` (паспорт: конвейер/инварианты, если меняется поведение очереди).
+- Обновить `CHANGELOG.md` (`## [Unreleased]`).
+- Если вводится таблица БД — отразить в `08-data-requirements.md` (создаёт архитектор).
+- `07-infra-requirements.md` — если требуется новый Plane-статус/настройка relations.
+
+## 9. Инварианты (НЕ нарушать)
+1. `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_deploy_status`/`check_staging_status`,
+   `Confirm Deploy` (ORCH-059), БАГ-8, terminal-sync — без изменений.
+2. Никаких push/force-push в `main`; force только `--force-with-lease` на ветку задачи.
+3. Сериализация — строго per-repo; кросс-репо параллелизм сохранён.
+4. never-raise во всех новых функциях; restart-safe состояние.
+5. ORCH-026 дополняет рубежи ORCH-073, не заменяет.
+6. Прод-контейнер orchestrator не рестартится вне штатного `Confirm Deploy`.

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

@@ -0,0 +1,107 @@
+# 03-Критерии приёмки — ORCH-026
+
+**Work Item:** ORCH-026 · **Repo:** orchestrator · **Стадия:** analysis
+
+Каждый критерий — проверяемое условие PASS/FAIL. Маппинг на тесты — `04-test-plan.yaml`.
+
+---
+
+## Уровень A — Сериализация merge/деплоя внутри одного репо
+
+### AC-A1 — Сериализация merge внутри репо
+- **PASS:** пока задача A применимого репо удерживает окно merge (merge-lease не освобождён /
+  `main` ещё не обновлён), задача B того же репо НЕ доходит до фактического merge — она
+  **defer**-ится (повторная постановка через `available_at`), а не мержится от устаревшего `main`.
+- **FAIL:** B мержится/деплоится, пока A не в `main`; или B откатывается на `development` вместо
+  defer.
+
+### AC-A2 — Proactive pre-merge rebase
+- **PASS:** перед merge ветка задачи **всегда** догоняется на свежий `origin/main` (вызывается
+  rebase), даже когда текстового конфликта нет и ветка формально не «behind» по старой проверке;
+  после rebase ветка содержит код предшественника (A).
+- **FAIL:** rebase запускается только при конфликте/`branch_is_behind_main`, и B мержится без
+  кода A.
+
+### AC-A3 — Кросс-репо параллелизм сохранён
+- **PASS:** задача в `orchestrator` и задача в `enduro-trails` доходят до merge/деплоя
+  параллельно — сериализация одного репо не блокирует другой (lease/гейт строго per-repo).
+- **FAIL:** задача одного репо ждёт освобождения ресурса, удерживаемого задачей ДРУГОГО репо.
+
+### AC-A4 — Restart-safe
+- **PASS:** после рестарта прод-контейнера состояние сериализации восстанавливается корректно;
+  мёртвый держатель merge-lease проактивно реклеймится (ORCH-065), конвейер не встаёт навсегда.
+- **FAIL:** рестарт оставляет навсегда захваченный lease → конвейер всех проектов встаёт.
+
+### AC-A5 — Self-hosting safety
+- **PASS:** прод-контейнер orchestrator НЕ рестартится/не падает вне штатного `Confirm Deploy`
+  (ORCH-059); нет push/force-push в `main`; `STAGE_TRANSITIONS` и реестр `QG_CHECKS` не изменены.
+- **FAIL:** любой незапрошенный рестарт прода, прямой push в `main`, или изменение машины стадий.
+
+### AC-A6 — Anti-deadlock / anti-livelock при defer
+- **PASS:** при занятой сериализации B defer-ится с задержкой и bounded бюджетом; исчерпание
+  бюджета → эскалация (alert/Blocked), не бесконечный цикл и не откат.
+- **FAIL:** B уходит в вечный defer-цикл, либо немедленно откатывается на `development`.
+
+### AC-A7 — Условность (не-self репо без регресса)
+- **PASS:** при выключенном kill-switch и для репо вне scope поведение конвейера 1:1 как до
+  ORCH-026 (нулевая регрессия для enduro-trails).
+- **FAIL:** не-self репо меняет поведение merge/деплоя.
+
+---
+
+## Уровень B — Декларативные зависимости
+
+### AC-B1 — Декларация зависимости
+- **PASS:** задача может объявить `blocked-by`/`depends-on` (через выбранный источник —
+  Plane relations / БД / гибрid), и связь корректно считывается планировщиком.
+- **FAIL:** связь не считывается / теряется.
+
+### AC-B2 — Гейт планировщика (B не стартует до A)
+- **PASS:** задача с незавершённым depends-on **не клеймится** воркером (не запускается агент,
+  слот `max_concurrency` не занимается), пока все depends-on не достигли `done`; как только A
+  становится `done` — B становится claimable.
+- **FAIL:** B запускается раньше завершения A; или занимает слот, простаивая.
+
+### AC-B3 — Детект дедлоков (циклы)
+- **PASS:** циклическая зависимость (A→B→A и длиннее) детектируется детерминированно; задача(и)
+  в цикле → `Blocked` + alert (Telegram/Plane) с указанием цикла; поток остальных задач не
+  блокируется.
+- **FAIL:** цикл приводит к молчаливому вечному ожиданию или к падению воркера.
+
+### AC-B4 — Видимость заблокированной задачи
+- **PASS:** заблокированная задача видна — Plane-статус `Blocked` и/или строка ожидания в
+  Telegram-карточке (что/кого ждёт); инвариант «одна карточка на задачу» сохранён.
+- **FAIL:** заблокированная задача невидима наблюдателю.
+
+### AC-B5 — Совместимость с reconciler/reaper
+- **PASS:** `reconciler` F-1 НЕ «разблокирует» задачу, заблокированную по зависимости (как уже
+  делает для Blocked/Needs-Input, ORCH-060/068); reaper не реапит корректно ожидающую задачу.
+- **FAIL:** reconciler продвигает заблокированную задачу мимо её depends-on.
+
+---
+
+## Общие (оба уровня)
+
+### AC-G1 — never-raise
+- **PASS:** любая ошибка (git/сеть/БД/Plane) в новой логике не пробрасывается в `advance_stage`/
+  воркер; деградирует консервативно (defer/skip/fail-closed), конвейер не падает.
+- **FAIL:** необработанное исключение роняет воркер/монитор-поток.
+
+### AC-G2 — Kill-switch
+- **PASS:** глобальный kill-switch выключает фичу целиком → поведение 1:1 как до ORCH-026.
+- **FAIL:** при выключенном флаге поведение изменено.
+
+### AC-G3 — Документация обновлена (golden source)
+- **PASS:** в ТОМ ЖЕ PR обновлены `docs/architecture/README.md`, `CLAUDE.md` (если изменилось
+  поведение очереди), `CHANGELOG.md`, заведён ADR в `06-adr/`. Reviewer проверяет.
+- **FAIL:** код изменён, документация — нет (→ REQUEST_CHANGES).
+
+### AC-G4 — Миграция БД безопасна (если применимо)
+- **PASS:** миграция только аддитивная (`CREATE TABLE IF NOT EXISTS`/`_ensure_column`),
+  идемпотентна, безопасна на живой общей прод-БД; существующие данные enduro-trails не затронуты.
+- **FAIL:** деструктивная миграция / изменение существующих колонок.
+
+### AC-G5 — Тесты зелёные
+- **PASS:** новые unit+integration тесты (`04-test-plan.yaml`) проходят; существующий
+  `pytest tests/ -q` остаётся зелёным (нет регресса merge-gate/merge-verify/reconciler/reaper).
+- **FAIL:** красный pytest или регресс существующих тестов.

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

@@ -0,0 +1,169 @@
+work_item: ORCH-026
+description: >
+  План тестов для управления зависимостями задач (Уровень B) и сериализации
+  merge/деплоя внутри одного репо (Уровень A). Стек: pytest. Имена модулей/функций —
+  кандидаты; финализирует архитектор/разработчик. Все новые функции — never-raise.
+
+tests:
+  # ---------------- Уровень A: сериализация merge/деплоя ----------------
+  - id: TC-A01
+    type: unit
+    description: >
+      Proactive pre-merge rebase: ветка догоняется на свежий origin/main ДАЖЕ когда
+      branch_is_behind_main вернул бы False (нет конфликта). Проверить, что rebase
+      вызывается всегда перед merge (AC-A2).
+    module: tests/test_orch026_premerge_rebase.py
+    expected: PASS
+
+  - id: TC-A02
+    type: unit
+    description: >
+      Расширенное окно merge-lease: пока A держит lease (окно merge→main-updated),
+      acquire для B того же репо возвращает busy → defer (не откат). holder-aware
+      release не удаляет чужой lease (AC-A1, AC-A6).
+    module: tests/test_orch026_merge_serialize.py
+    expected: PASS
+
+  - id: TC-A03
+    type: unit
+    description: >
+      Сериализация строго per-repo: lease/гейт orchestrator не влияет на задачу
+      enduro-trails — обе claimable параллельно (AC-A3).
+    module: tests/test_orch026_merge_serialize.py
+    expected: PASS
+
+  - id: TC-A04
+    type: unit
+    description: >
+      Restart-safe + проактивный реклейм: мёртвый держатель lease (pid не жив)
+      реклеймится reclaim_stale_lease; конвейер не встаёт навсегда (AC-A4).
+    module: tests/test_orch026_merge_serialize.py
+    expected: PASS
+
+  - id: TC-A05
+    type: unit
+    description: >
+      Anti-livelock defer: B defer-ится с available_at-задержкой и bounded бюджетом;
+      исчерпание → эскалация (Blocked/alert), не бесконечный цикл (AC-A6).
+    module: tests/test_orch026_merge_serialize.py
+    expected: PASS
+
+  - id: TC-A06
+    type: unit
+    description: >
+      Условность/kill-switch: при выключенном флаге и для репо вне scope поведение
+      merge/деплоя 1:1 как до ORCH-026 — no-op (AC-A7, AC-G2).
+    module: tests/test_orch026_conditionality.py
+    expected: PASS
+
+  - id: TC-A07
+    type: unit
+    description: >
+      Self-hosting safety: новая логика никогда не делает push/force-push в main;
+      force только --force-with-lease на ветку задачи; STAGE_TRANSITIONS не изменены
+      (AC-A5).
+    module: tests/test_orch026_conditionality.py
+    expected: PASS
+
+  - id: TC-A08
+    type: integration
+    description: >
+      Сквозной сценарий: две задачи одного репо проходят deploy-staging→deploy; B не
+      доходит до merge, пока A не в main; после A→done B ребейзится на свежий main
+      (несёт код A) и мержится. main не теряет код A (AC-A1/AC-A2).
+    module: tests/test_orch026_serialize_integration.py
+    expected: PASS
+
+  # ---------------- Уровень B: декларативные зависимости ----------------
+  - id: TC-B01
+    type: unit
+    description: >
+      Чтение/декларация связи blocked-by из выбранного источника (Plane/БД/гибрид);
+      связь корректно резолвится в depends_on_task_id (AC-B1). never-raise при
+      недоступности источника → консервативно (нет связи или fail-closed по решению ADR).
+    module: tests/test_orch026_task_deps.py
+    expected: PASS
+
+  - id: TC-B02
+    type: unit
+    description: >
+      Гейт готовности (leaf-функция): задача с незавершённым depends-on НЕ ready;
+      все depends-on в done → ready. Чистая логика, юнит-тестируемая (AC-B2).
+    module: tests/test_orch026_task_deps.py
+    expected: PASS
+
+  - id: TC-B03
+    type: unit
+    description: >
+      Детект циклов: A→B→A (и длиннее) детектируется детерминированно; ацикличный
+      граф → циклов нет. Чистая функция (AC-B3).
+    module: tests/test_orch026_dep_cycles.py
+    expected: PASS
+
+  - id: TC-B04
+    type: unit
+    description: >
+      Цикл → set_issue_blocked + alert (Telegram/Plane), без падения воркера и без
+      блокировки потока других задач (AC-B3, AC-G1).
+    module: tests/test_orch026_dep_cycles.py
+    expected: PASS
+
+  - id: TC-B05
+    type: unit
+    description: >
+      claim_next_job не клеймит заблокированную задачу (не занимает слот
+      max_concurrency); как только depends-on done — задача становится claimable (AC-B2).
+    module: tests/test_orch026_task_deps.py
+    expected: PASS
+
+  - id: TC-B06
+    type: unit
+    description: >
+      Видимость: заблокированная задача отражается в Plane-статусе Blocked и/или
+      строке ожидания Telegram-карточки; инвариант «одна карточка на задачу» сохранён
+      (AC-B4). notifications never-raise / silent.
+    module: tests/test_orch026_dep_visibility.py
+    expected: PASS
+
+  - id: TC-B07
+    type: unit
+    description: >
+      reconciler F-1 НЕ разблокирует задачу, заблокированную по зависимости (как для
+      Blocked/Needs-Input); reaper не реапит корректно ожидающую (AC-B5).
+    module: tests/test_orch026_task_deps.py
+    expected: PASS
+
+  - id: TC-B08
+    type: integration
+    description: >
+      Сквозной сценарий: B объявлена blocked-by A; при постановке в очередь B не
+      стартует, пока A не done; после A→done воркер запускает B. Telegram/Plane
+      показывают Blocked у B до разблокировки (AC-B1/B2/B4).
+    module: tests/test_orch026_deps_integration.py
+    expected: PASS
+
+  # ---------------- Общие / миграция / регресс ----------------
+  - id: TC-G01
+    type: unit
+    description: >
+      Аддитивная миграция БД (если выбран вариант с таблицей/колонкой): идемпотентна,
+      безопасна на существующей БД с данными, не меняет существующие колонки (AC-G4).
+    module: tests/test_orch026_migration.py
+    expected: PASS
+
+  - id: TC-G02
+    type: unit
+    description: >
+      Наблюдаемость GET /queue: новый блок (заблокированные задачи / держатель lease /
+      defer-счётчики / циклы) присутствует и read-only; не источник истины.
+    module: tests/test_orch026_queue_observability.py
+    expected: PASS
+
+  - id: TC-G03
+    type: integration
+    description: >
+      Регресс: полный pytest tests/ -q остаётся зелёным — merge-gate (ORCH-043),
+      merge-verify (ORCH-073), reconciler (ORCH-053/068), reaper (ORCH-065) не
+      деградировали (AC-G5).
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-026/06-adr/ADR-001-merge-serialization-and-task-deps.md

@@ -0,0 +1,226 @@
+# ADR-001: Сериализация merge/деплоя внутри репо (A) + декларативные зависимости задач (B)
+
+**Work Item:** ORCH-026 · **Repo:** orchestrator (self-hosting) · **Стадия:** architecture
+**Статус:** Accepted
+**Связи:** дополняет ORCH-043 (merge-gate), ORCH-065 (merge-lease + reclaim), ORCH-073/071
+(merge-verify, SHA-in-main), ORCH-1 (очередь). Глобальный ADR — `adr/adr-0015`.
+
+---
+
+## Контекст
+
+ORCH-026 закрывает **первопричину** эрозии `main` 08.06 (некоординированный параллелизм
+задач одного репо: ветки от устаревшего `main`, фантом-merge затирает соседа) и попутно вводит
+исходный скоуп — декларативные зависимости задач (B ждёт A). Требования — `01-brd.md`,
+`02-trz.md`; PASS/FAIL — `03-acceptance-criteria.md`.
+
+Ключевое наблюдение архитектора: **бо́льшая часть инфраструктуры для Уровня A уже существует** и
+её НЕ нужно переписывать:
+
+- **merge-lease** (ORCH-065, `src/merge_gate.py`): per-repo файловый лиз
+  `.merge-lease-<repo>.json`, неблокирующий acquire, holder-aware release, проактивный реклейм
+  мёртвого/устаревшего держателя (`reclaim_stale_lease`, `pid_alive`). Restart-safe, per-repo.
+- **merge-gate** (ORCH-043, `check_branch_mergeable`): на ребре `deploy-staging → deploy`
+  захватывает лиз, при необходимости ребейзит, держит лиз до фактического merge.
+- **defer-механизм** (`_handle_merge_gate_defer`): `merge-lock busy` → повторная постановка
+  deployer'а через `available_at`, bounded `merge_defer_max_attempts` → эскалация (Blocked+alert).
+- **окно лиза** уже простирается от `deploy-staging → deploy` до release на одном из событий:
+  PR-merged webhook (`gitea.py`), `deploy→done` (`stage_engine.py`), откат, проактивный реклейм.
+  Для self-hosting `done` достигается ТОЛЬКО после `verify_merged_to_main` (SHA-in-main, ORCH-073).
+
+Таким образом окно сериализации A-1 («merge → main-updated») **структурно уже реализовано**:
+пока A не подтверждена в `main` (для self — SHA-in-main → `done`), лиз держится, и B того же
+репо на своём merge-gate получает `merge-lock busy` → defer. Открытый вопрос BRD §4.3 (граница
+окна для self) решается так: **окно = от acquire до release; release-события не меняем**. Для
+non-self репо граница — PR-merged webhook; для self — `deploy→done` (= SHA-in-main подтверждён).
+
+Что реально **отсутствует** для Уровня A:
+
+- **A-2: безусловный proactive pre-merge rebase.** Сейчас `check_branch_mergeable` ребейзит
+  ТОЛЬКО если `branch_is_behind_main` (⇔ `origin/main` не предок HEAD). AC-A2 требует, чтобы
+  rebase вызывался **всегда** перед merge — детерминированный структурный анти-фантом на уровне
+  планировщика, не зависящий от точности ancestor-проверки.
+
+Для Уровня B инфраструктуры нет вовсе: очередь `jobs` (ORCH-1) плоская (FIFO по `id` +
+`available_at` + `max_concurrency`), выразить «B ждёт A» нельзя.
+
+---
+
+## Решение
+
+### Уровень A — сериализация merge/деплоя (минимально-инвазивно, переиспользуя ORCH-043/065)
+
+**A-1/A-3/A-4 (окно сериализации) — без изменений механизма.** Окно сериализации обеспечивается
+существующим merge-lease: захват в `check_branch_mergeable`, удержание до release. Подтверждаем и
+фиксируем в доке, что release-события (`PR-merged` / `deploy→done` / откат / `reclaim_stale_lease`)
+формируют окно «merge → main-updated». Кросс-репо параллелизм сохранён автоматически (лиз —
+per-repo файл). Restart-safe и анти-залипание — за счёт ORCH-065 reclaim. **Кода-изменений нет.**
+
+**A-2 (безусловный pre-merge rebase) — новое поведение, флаг `premerge_rebase_always`.**
+
+- В `check_branch_mergeable` (`src/qg/checks.py`), ПОД захваченным merge-lease: когда
+  `settings.premerge_rebase_always` истинно (и merge-gate применим к репо), **пропустить
+  short-circuit `branch_is_behind_main`** и **всегда** вызвать `merge_gate.auto_rebase_onto_main`.
+- `auto_rebase_onto_main` уже идемпотентен и дёшев на актуальной ветке: `git rebase origin/main`
+  на не-отстающей ветке — no-op (rc 0, HEAD не меняется), последующий `push --force-with-lease`
+  → «Everything up-to-date» (тот же SHA, **CI не перезапускается, лишних коммитов нет**). На
+  отстающей ветке — реальный догон. Текстовый конфликт → существующий контракт: `rebase --abort`
+  → откат на `development` (как ORCH-043). **Инвариант: никаких push/force-push в `main`** —
+  единственная force-операция остаётся `--force-with-lease` на ветку задачи.
+- Когда флаг выключен → прежнее поведение (ребейз только при `branch_is_behind_main`),
+  обратная совместимость 1:1 (AC-A7/AC-G2).
+- **Скоуп — общий с merge-gate:** реально только для `merge_gate_repos` (пусто → self-hosting
+  `orchestrator`). Никакого нового scope-флага.
+
+**A-5/A-6 (safety, anti-livelock) — без изменений.** `STAGE_TRANSITIONS`, `QG_CHECKS`,
+`Confirm Deploy` (ORCH-059), exit-коды хука, terminal-sync не трогаются. defer-бюджет —
+существующий `merge_defer_max_attempts` → Blocked+alert при исчерпании. Прод-контейнер не
+рестартится вне штатного `Confirm Deploy`.
+
+### Уровень B — декларативные зависимости (новая инфраструктура)
+
+**B-источник: гибрид с БД как источником истины для планировщика; флаг `task_deps_source`.**
+
+Планировщик `claim_next_job` — горячий цикл, обслуживающий очередь ВСЕХ проектов из ОДНОГО
+инстанса. Он **обязан** быть offline-устойчивым и быстрым: сетевой запрос в Plane на каждый claim
+= при недоступности Plane встанет конвейер всех проектов (нарушение self-hosting safety). Поэтому:
+
+- **Авторитетный для планировщика стор — локальная БД**, новая аддитивная таблица
+  `job_deps(task_id, depends_on_task_id, created_at)` (детали — `08-data-requirements.md`).
+  Связь хранится по `tasks.id` (стабильный локальный ключ). Зависимости — **только внутри одного
+  репо** (v1; кросс-репо — non-goal, BRD §5).
+- **`task_deps_source = db | plane | hybrid`** (дефолт **`db`**): `db` — связи пишутся напрямую в
+  `job_deps` (потребитель — декомпозиция эпиков ORCH-025); `plane` — связи читаются из Plane
+  relations в `handle_work_item_created` и **кэшируются** в `job_deps`; `hybrid` — Plane как
+  декларация + БД-кэш. Plane-ingestion — тонкий add-on за флагом; планировщик ВСЕГДА читает БД.
+
+**B-2 (гейт планировщика) — SQL `NOT EXISTS`, без занятия слота `max_concurrency`.**
+
+Гейт готовности выражается декларативно в `claim_next_job` (`src/db.py`): задача claimable, если
+у неё нет ни одной незавершённой зависимости. Когда `settings.task_deps_enabled` — к существующему
+SELECT добавляется условие:
+
+```sql
+AND NOT EXISTS (
+    SELECT 1 FROM job_deps d
+    JOIN tasks t ON t.id = d.depends_on_task_id
+    WHERE d.task_id = j.task_id AND t.stage != 'done'
+)
+```
+
+Это: (1) **не занимает слот** — job просто не выбирается, агент не запускается (AC-B2);
+(2) restart-safe (чистая БД); (3) never-raise (это SQL); (4) при пустой `job_deps` —
+инертно (нулевая регрессия, AC-G2); (5) при выключенном `task_deps_enabled` условие НЕ
+добавляется → запрос 1:1 как в ORCH-1. Как только все зависимости достигают `stage='done'`,
+задача автоматически становится claimable.
+
+Чистая leaf-логика «готова ли задача» выносится в новый модуль `src/task_deps.py`:
+`is_task_ready(task_id) -> (bool, waiting_on: list[str])` (never-raise) — для реконсилятора,
+карточки и `/queue` (SQL в `claim_next_job` — горячий путь, дублирует ту же семантику).
+
+**B-3 (детект дедлоков) — DFS, чистая функция.**
+
+`task_deps.detect_cycle(task_id) -> list[int] | None` — обход графа `job_deps` (внутри репо),
+детерминированный, юнит-тестируемый, never-raise. Запускается: (1) при вставке связи
+(`add_dependency`) — цикл отклоняется/алертится сразу (лучший UX); (2) backstop-проход в тике
+`reconciler` (на случай связей, добавленных в обход). Цикл → `set_issue_blocked(work_item_id)` +
+Telegram/Plane alert с перечислением цикла. SQL-гейт B-2 сам по себе никогда не выберет задачу в
+цикле (её зависимости не достигнут `done`) — детектор делает это **видимым**, а не молчаливым
+вечным ожиданием (AC-B3). Поток остальных задач не блокируется.
+
+**B-4 (видимость).**
+
+- Нормальное ожидание (B ждёт A, A в работе — транзиентно и ожидаемо): строка в Telegram-карточке
+  «⏳ ждёт ORCH-NNN» через `notifications.update_task_tracker`, never-raise/silent. **Plane Blocked
+  при нормальном ожидании НЕ ставим** — иначе флаппинг Blocked на каждом коротком ожидании.
+- Дедлок/цикл (B-3): `set_issue_blocked` (Plane `Blocked`) + alert. Это «и/или» из AC-B4.
+- Инвариант «одна карточка на задачу» сохранён (ORCH-042/067).
+
+**B-5 (совместимость reconciler/reaper).**
+
+- `reconciler` F-1 не должен «разблокировать» dep-заблокированную задачу мимо её зависимостей.
+  В фильтр пригодности reconciler добавляется проверка `task_deps.is_task_ready` (по образцу
+  `reconcile_skip_blocked_enabled`, ORCH-060): не готова → skip.
+- `reaper` сканирует **`running`** jobs; dep-заблокированный job остаётся `queued` (его не
+  клеймят) → reaper его не трогает по построению. Фиксируем в доке.
+
+**Наблюдаемость (TRZ §4):** блок `task_deps` в снимке `GET /queue` (read-only, по образцу
+`reconcile`/`reaper`): кол-во заблокированных задач, держатель merge-lease, defer-счётчики,
+обнаруженные циклы. Никогда не источник решений.
+
+### Конфигурация (`src/config.py`)
+
+| Флаг | Дефолт | Назначение |
+|------|--------|-----------|
+| `premerge_rebase_always` | `True` | Уровень A: безусловный pre-merge rebase под лизом. Скоуп — `merge_gate_repos`. Kill-switch (`False` → ребейз только при behind, как ORCH-043). |
+| `task_deps_enabled` | `True` | Уровень B: глобальный kill-switch гейта зависимостей. `False` → `claim_next_job` 1:1 как ORCH-1. Инертно при пустой `job_deps`. |
+| `task_deps_source` | `"db"` | Источник деклараций: `db`\|`plane`\|`hybrid`. Планировщик всегда читает БД-кэш. |
+
+Дефолты следуют конвенции репо (`*_enabled=True` + kill-switch), при этом обе фичи инертны без
+данных (нет деклараций / нет применимых репо) → нулевая регрессия для enduro-trails.
+
+---
+
+## Альтернативы (и почему отвергнуты)
+
+1. **Уровень A — отдельный глобальный per-repo merge-lock или FIFO merge-queue.** Дублировал бы
+   уже существующий merge-lease (ORCH-065), вводил второй механизм сериализации с риском
+   рассинхрона. Отвергнуто: BRD §4.2 требует минимально-инвазивного решения, переиспользующего
+   ORCH-065/043. Окно лиза уже даёт сериализацию.
+
+2. **Уровень A — расширять release-точки лиза (держать до отдельного `main-updated`-события).**
+   Не требуется: для self `done` ⇔ SHA-in-main (ORCH-073), для non-self — PR-merged webhook;
+   окно уже корректно. Доп. событие усложнило бы reclaim без выигрыша.
+
+3. **Уровень B — Plane relations как источник истины планировщика.** Сетевой запрос в горячем
+   цикле claim; при недоступности Plane встаёт очередь всех проектов (self-hosting risk).
+   Отвергнуто; Plane оставлен опциональным источником **декларации** (`task_deps_source=plane`),
+   но планировщик читает только БД-кэш.
+
+4. **Уровень B — гейт зависимостей в воркере (`_drain_once`) поверх `claim_next_job`.** Пришлось
+   бы клеймить job, обнаруживать незавершённую зависимость и re-queue’ить — churn, расход attempts,
+   гонки. SQL `NOT EXISTS` в самом `claim_next_job` чище: job просто не выбирается, слот свободен.
+
+5. **Уровень B — поле/JSON в `tasks` вместо таблицы.** Таблица `job_deps` нормальна (M:N),
+   индексируема, проще для DFS и `NOT EXISTS`. Поле в `tasks` потребовало бы парсинг-логики.
+
+---
+
+## Последствия
+
+**Плюсы.**
+- Минимально-инвазивно: Уровень A — один флаг + снятие short-circuit; окно сериализации не
+  переписывается. Переиспользует ORCH-043/065 целиком.
+- Уровень B — одно `NOT EXISTS` в `claim_next_job` + аддитивная таблица + leaf-модуль
+  `task_deps.py`; `STAGE_TRANSITIONS`/`QG_CHECKS` не тронуты (паттерн врезки ORCH-071/058).
+- Обе фичи инертны без данных → нулевая регрессия для enduro-trails (AC-A7/AC-G2).
+- restart-safe (БД + файловый лиз), never-raise, kill-switch на каждую фичу.
+
+**Минусы / ограничения.**
+- `premerge_rebase_always=True` добавляет (дешёвый, no-op на актуальной ветке) `rebase`+`push`
+  на каждый self-merge. Цена — лишний git-вызов; компенсируется детерминизмом анти-фантома.
+- Уровень B v1 — только intra-repo зависимости; кросс-репо — follow-up (non-goal).
+- Гейт B-2 в `claim_next_job` слегка усложняет горячий SQL (один `NOT EXISTS`); защищён
+  kill-switch и инертностью при пустой таблице.
+- `task_deps.py` цикл-детектор — новая поверхность; покрывается юнит-тестами (`04-test-plan.yaml`).
+
+**Инварианты (не нарушать).**
+1. `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_deploy_status`/`check_staging_status`,
+   `Confirm Deploy` (ORCH-059), БАГ-8, terminal-sync — без изменений.
+2. Никаких push/force-push в `main`; force только `--force-with-lease` на ветку задачи.
+3. Сериализация — строго per-repo; кросс-репо параллелизм сохранён.
+4. never-raise во всех новых функциях; restart-safe состояние; миграция БД только аддитивная.
+5. ORCH-026 **дополняет** рубежи ORCH-073, не заменяет.
+6. Прод-контейнер orchestrator не рестартится вне штатного `Confirm Deploy`.
+
+**Места реализации (для developer).**
+- `src/qg/checks.py::check_branch_mergeable` — ветка `premerge_rebase_always`.
+- `src/db.py::claim_next_job` — условный `NOT EXISTS`-гейт; новые helpers `add_dependency`,
+  `get_dependencies`, `job_deps` миграция в `init_db` (`CREATE TABLE IF NOT EXISTS`).
+- `src/task_deps.py` (новый, leaf) — `is_task_ready`, `detect_cycle`, snapshot для `/queue`.
+- `src/webhooks/plane.py::handle_work_item_created` — ingestion Plane relations (за `task_deps_source`).
+- `src/reconciler.py` — skip dep-заблокированных + backstop цикл-детект.
+- `src/notifications.py` — строка ожидания в карточке.
+- `src/config.py` — `premerge_rebase_always`, `task_deps_enabled`, `task_deps_source`.
+- Документация: `docs/architecture/README.md`, `CLAUDE.md` (если меняется поведение очереди),
+  `CHANGELOG.md`, глобальный `adr/adr-0015`.

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

@@ -0,0 +1,65 @@
+# 08 — Требования к схеме БД — ORCH-026
+
+**Work Item:** ORCH-026 · **Repo:** orchestrator · **Стадия:** architecture
+**Связь:** ADR `06-adr/ADR-001-merge-serialization-and-task-deps.md` (Уровень B).
+
+> Уровень A (сериализация merge/деплоя) — **БЕЗ изменения схемы БД** (merge-lease файловый,
+> `.merge-lease-<repo>.json`, ORCH-065). Изменения схемы касаются ТОЛЬКО Уровня B.
+
+---
+
+## Новая таблица `job_deps` (аддитивная)
+
+Хранит декларативные зависимости «задача `task_id` ждёт задачу `depends_on_task_id`».
+
+```sql
+CREATE TABLE IF NOT EXISTS job_deps (
+    task_id            INTEGER NOT NULL,   -- tasks.id зависимой задачи (B)
+    depends_on_task_id INTEGER NOT NULL,   -- tasks.id задачи-предшественника (A)
+    created_at         TEXT DEFAULT (datetime('now')),
+    PRIMARY KEY (task_id, depends_on_task_id)
+);
+CREATE INDEX IF NOT EXISTS idx_job_deps_task    ON job_deps(task_id);
+CREATE INDEX IF NOT EXISTS idx_job_deps_depends ON job_deps(depends_on_task_id);
+```
+
+### Поля
+| Поле | Тип | Назначение |
+|------|-----|-----------|
+| `task_id` | INTEGER | `tasks.id` зависимой задачи (B). Не запускается, пока зависимости не `done`. |
+| `depends_on_task_id` | INTEGER | `tasks.id` предшественника (A). Терминальность — `tasks.stage = 'done'`. |
+| `created_at` | TEXT | Время декларации (диагностика). |
+
+### Ключ и индексы
+- **PK `(task_id, depends_on_task_id)`** — идемпотентность вставки (повторная декларация связи —
+  no-op через `INSERT OR IGNORE`), запрет дублей.
+- `idx_job_deps_task` — гейт планировщика (`NOT EXISTS ... WHERE d.task_id = j.task_id`).
+- `idx_job_deps_depends` — обратные рёбра для DFS цикл-детектора.
+
+### Семантика готовности (источник истины планировщика)
+Задача `task_id` **готова к запуску** ⇔ нет ни одной строки `job_deps` для неё, чей
+`depends_on_task_id` указывает на задачу с `tasks.stage != 'done'`. Терминал — только `done`
+(совпадает с тем, как `get_active_tasks_for_reconcile` трактует терминальность).
+
+### Связь по `task_id`, а не `work_item_id`
+`tasks.id` — стабильный локальный автоинкремент-ключ; `work_item_id`/`plane_id` могут
+ресолвиться/коллизиться (см. `ensure_unique_work_item_id`). FK логический (без `REFERENCES`,
+как у `jobs.task_id`) — не блокирует аддитивную миграцию и удаление строк tasks (которого в
+конвейере нет). Зависимости — **только intra-repo** (v1); кросс-репо рёбра не создаются.
+
+---
+
+## Миграция (AC-G4)
+
+- Выполняется в `src/db.py::init_db` рядом с прочими: **только** `CREATE TABLE IF NOT EXISTS` +
+  `CREATE INDEX IF NOT EXISTS`. **Идемпотентно**, restart-safe, безопасно на живой общей прод-БД.
+- **Существующие колонки/таблицы (`jobs`, `tasks`, `agent_runs`, `events`) НЕ изменяются** →
+  данные enduro-trails не затронуты.
+- Откат фичи — флагом `task_deps_enabled=False` (таблица остаётся, гейт не применяется); сама
+  таблица деструктивно не удаляется.
+
+## Что НЕ меняется
+- Схема `jobs` (включая `available_at`, `pid`, `attempts`/`transient_attempts`) — без изменений;
+  defer Уровня A/B переиспользует существующий `available_at`-механизм.
+- Схема `tasks` — без изменений (видимость через существующие `tracker_message_id` и Plane Blocked).
+- merge-lease — файловый, вне БД.

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

@@ -0,0 +1,17 @@
+# 10 — Технические риски — ORCH-026
+
+**Work Item:** ORCH-026 · **Repo:** orchestrator · **Стадия:** architecture
+**Связь:** ADR `06-adr/ADR-001-merge-serialization-and-task-deps.md`.
+
+| # | Риск | Уровень | Митигация |
+|---|------|---------|-----------|
+| R-1 | **Гейт `NOT EXISTS` в `claim_next_job` (горячий путь всех проектов) содержит баг → встаёт очередь ВСЕХ проектов** (self-hosting групповой риск). | Высокий | Условие добавляется ТОЛЬКО при `task_deps_enabled`; инертно при пустой `job_deps` (нулевая регрессия); kill-switch `task_deps_enabled=False` мгновенно возвращает поведение ORCH-1; интеграционный тест «пустые deps ⇒ FIFO 1:1» (AC-G2). |
+| R-2 | **Безусловный `premerge_rebase_always` делает лишний `push --force-with-lease` → ложный перезапуск CI / новые коммиты.** | Низкий | На актуальной ветке `rebase origin/main` — no-op (HEAD не меняется), push → «Everything up-to-date» (тот же SHA, CI не триггерится). Подтвердить тестом, что SHA не меняется на уже-актуальной ветке. |
+| R-3 | **Дедлок по циклической зависимости → задача молча ждёт вечно.** | Средний | DFS-детектор `detect_cycle` при вставке связи + backstop в `reconciler`; цикл → `set_issue_blocked` + alert с перечислением цикла (AC-B3); SQL-гейт не выбирает задачу в цикле, детектор делает это видимым. |
+| R-4 | **Livelock: B бесконечно defer’ится на `merge-lock busy`.** | Низкий | Существующий bounded-бюджет `merge_defer_max_attempts` → Blocked+alert (ORCH-043, без изменений). |
+| R-5 | **Залипший merge-lease после смерти держателя → конвейер репо встаёт навсегда.** | Средний | Переиспользуется ORCH-065: `reclaim_stale_lease` (мёртвый `pid` / TTL `merge_lock_timeout_s`) + holder-aware release. Restart-safe (AC-A4). |
+| R-6 | **Plane relations недоступны/неверно смаплены при `task_deps_source=plane`.** | Средний | Планировщик читает ТОЛЬКО БД-кэш `job_deps`; Plane-ingestion — best-effort, never-raise; дефолт `task_deps_source=db` не зависит от Plane. |
+| R-7 | **reconciler «разблокирует» dep-заблокированную задачу мимо её зависимостей.** | Средний | В фильтр reconciler добавляется `is_task_ready` (паттерн ORCH-060 skip-Blocked); reaper трогает только `running` — dep-блок остаётся `queued` (AC-B5). |
+| R-8 | **Миграция БД повреждает общую прод-БД (данные enduro-trails).** | Низкий | Только аддитивно: `CREATE TABLE/INDEX IF NOT EXISTS`; существующие колонки не меняются; идемпотентно (AC-G4). |
+| R-9 | **Self-hosting: изменения требуют рестарта прод-контейнера вне `Confirm Deploy`.** | Высокий (если нарушено) | Все изменения — обычный код, проходят `deploy-staging` (8501) → `Confirm Deploy` (ORCH-059). `STAGE_TRANSITIONS`/`QG_CHECKS` не трогаются; никакого внеочередного рестарта (AC-A5). |
+| R-10 | **Конфликт точек интеграции A (merge-gate) и B (постановка в очередь).** | Низкий | Разные точки конвейера: B гейтит claim job (вход), A гейтит merge на ребре `deploy-staging→deploy`. Независимы; покрыть интеграционным тестом совместной работы (BRD §4.4). |

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

@@ -0,0 +1,47 @@
+---
+type: review
+work_item_id: ORCH-026
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-026
+
+## Summary
+ORCH-026 реализует два уровня по ADR-001: **Уровень A** — сериализация merge/deploy внутри одного репо (переиспользует merge-lease ORCH-043/065 + единственная новая логика — безусловный pre-merge rebase под флагом `premerge_rebase_always`) и **Уровень B** — декларативные зависимости задач (аддитивная таблица `job_deps`, гейт `NOT EXISTS` в `claim_next_job`, leaf-модуль `src/task_deps.py`). Реализация минимально-инвазивна, строго соответствует ТЗ и ADR, обе фичи условны (kill-switch) и инертны без данных. Все 16 критериев приёмки выполнены. Полный прогон `pytest tests/ -q` — **991 passed**, из них 50 новых ORCH-026-тестов зелёные. Документация обновлена в том же PR. **APPROVED.**
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice to have
+- [ ] PR-ветка несёт коммиты ORCH-073 (`main` ещё не получил merge #77, merge-base = `77abfb3`). Это ожидаемо по топологии (ORCH-026 (B) построен поверх уже отревьюенного предшественника ORCH-073 (A): у ORCH-073 есть собственные `12-review.md`/`13-test-report.md`/`14-deploy-log.md`) и фактически демонстрирует саму фичу A (rebase B на код A). Не блокирует; при merge в `main` приедут оба набора изменений — это корректно.
+
+## Соответствие ТЗ и ADR
+- **Уровень A (AC-A1…A7):** окно сериализации обеспечено существующим merge-lease без нового механизма (ADR §A-1/A-3/A-4). A-2 — `check_branch_mergeable` (`src/qg/checks.py`) под лизом при `premerge_rebase_always=True` всегда вызывает `auto_rebase_onto_main`, снимая short-circuit `branch_is_behind_main`; kill-switch off → поведение ORCH-043 1:1. `STAGE_TRANSITIONS`/`QG_CHECKS`/`Confirm Deploy` не тронуты — соответствует инвариантам §9. Никаких push/force в `main` (только `--force-with-lease` ветки).
+- **Уровень B (AC-B1…B5):** гейт `NOT EXISTS (job_deps JOIN tasks WHERE stage!='done')` в `claim_next_job` (`src/db.py`) — job не выбирается, слот `max_concurrency` не занимается; при выключенном флаге / пустой таблице clause не добавляется (нулевая регрессия). `task_deps.py` — чистый leaf: `is_task_ready` (fail-open), итеративный WHITE/GREY/BLACK DFS-детектор циклов (защита от recursion-limit на проде), `handle_cycle` (Blocked+alert), `declare_dependency`, `ingest_plane_relations` (только `plane|hybrid`, дефолт `db` не ходит в сеть на горячем пути). reconciler F-1 получил Guard 3 (skip dep-заблокированных + backstop детект цикла); reaper не тронут (сканирует `running`).
+- **Общие (AC-G1…G5):** контракт never-raise выдержан во всех новых функциях (try/except, консервативная деградация). Миграция строго аддитивна — `CREATE TABLE/INDEX IF NOT EXISTS`, без `REFERENCES`, схема `tasks`/`jobs` не изменена (AC-G4 OK на живой общей БД). Наблюдаемость — read-only блок `task_deps` в `GET /queue`. Реализация в точности по местам, указанным в ADR §«Места реализации».
+
+## Качество кода
+- Docstrings на всех публичных функциях, явно документирован контракт fail-open/fail-closed.
+- SQL-гейт безопасен: `dep_gate` — константная строка (нет инъекции), таблица `job_deps` гарантированно создана в `init_db`.
+- Переменные `plane_id`/`plane_project_id`/`task_id` в `start_pipeline` — в области видимости (проверено).
+- Тесты содержательные: миграция, conditionality (kill-switch), циклы, видимость, observability, интеграция сериализации и зависимостей.
+
+## Документация — обновлена (golden source)
+Проверено: код в `src/` изменён → документация обновлена В ТОМ ЖЕ PR (разнесена по pipeline-коммитам ветки, что нормально):
+- `docs/architecture/README.md` — разделы про очередь (`claim_next_job`-гейт), pre-merge rebase, «Зависимости задач: B ждёт A», `job_deps`, наблюдаемость (architect-коммит `f8ec1c2`). ✓
+- `docs/work-items/ORCH-026/06-adr/ADR-001-merge-serialization-and-task-deps.md` + глобальный `docs/architecture/adr/adr-0015-task-deps-and-merge-serialization.md`. ✓
+- `CLAUDE.md` — паспорт (очередь/сериализация). ✓
+- `CHANGELOG.md` — запись `## [Unreleased]`. ✓
+- `.env.example` — `ORCH_PREMERGE_REBASE_ALWAYS`/`ORCH_TASK_DEPS_ENABLED`/`ORCH_TASK_DEPS_SOURCE`. ✓
+- `08-data-requirements.md` — таблица `job_deps`. ✓
+
+Документация = golden source: требование выполнено.

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

@@ -0,0 +1,75 @@
+---
+type: test-report
+work_item_id: ORCH-026
+result: PASS
+---
+
+# Test Report — ORCH-026
+
+Задача: «Управление зависимостями задач (B ждёт A) в очереди» + сериализация merge/деплоя
+одного репо. Ветка `feature/ORCH-026-b-a`. Review-вердикт: **APPROVED** (`12-review.md`).
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Ветка: `feature/ORCH-026-b-a` (HEAD `aaa4829`)
+- Прод-оркестратор (8500): `/health` → `{"status":"ok"}` (не перезапускался, self-hosting инвариант соблюдён)
+- Дата: 2026-06-08
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+### Уровень A — сериализация merge/деплоя
+
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-A01 | Proactive pre-merge rebase (всегда, даже когда не behind) | `test_orch026_premerge_rebase::test_always_rebases_even_when_not_behind` | PASS |
+| TC-A02 | Расширенное окно merge-lease, defer не откат; holder-aware release | `test_orch026_merge_serialize::test_second_task_same_repo_defers_not_rollback`, `test_holder_aware_release_keeps_foreign_lease` | PASS |
+| TC-A03 | Сериализация строго per-repo (orchestrator ≠ enduro-trails) | `test_orch026_merge_serialize::test_serialization_is_strictly_per_repo` | PASS |
+| TC-A04 | Restart-safe + реклейм мёртвого держателя lease | `test_orch026_merge_serialize::test_dead_holder_lease_is_reclaimed`, `test_stale_lease_age_reclaimed_on_acquire` | PASS |
+| TC-A05 | Anti-livelock defer: bounded бюджет, эскалация | `test_orch026_merge_serialize::test_defer_budget_is_bounded` | PASS |
+| TC-A06 | Условность/kill-switch: off + out-of-scope = no-op | `test_orch026_conditionality::test_out_of_scope_repo_is_noop_even_with_flag_on`, `test_premerge_rebase::test_flag_off_short_circuits_like_orch043` | PASS |
+| TC-A07 | Self-hosting safety: только `--force-with-lease` на ветку, STAGE_TRANSITIONS не тронуты | `test_orch026_conditionality::test_premerge_only_force_with_lease_on_branch`, `test_stage_transitions_unchanged` | PASS |
+| TC-A08 | Сквозной сценарий сериализации merge-окна | `test_orch026_serialize_integration::test_serialized_merge_window` | PASS |
+
+### Уровень B — декларативные зависимости
+
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-B01 | Декларация/резолв blocked-by; never-raise при недоступности | `test_orch026_task_deps::test_add_dependency_declares_and_resolves`, `test_add_dependency_never_raises_on_bad_input` | PASS |
+| TC-B02 | Гейт готовности: незавершённый depends-on → не ready; все done → ready | `test_orch026_task_deps::test_is_task_ready_blocked_then_ready`, `test_is_task_ready_no_deps_is_ready` | PASS |
+| TC-B03 | Детект циклов A→B→A и длиннее; ацикличный → нет | `test_orch026_dep_cycles::test_detect_two_node_cycle`, `test_detect_longer_cycle`, `test_acyclic_graph_has_no_cycle`, `test_detect_cycle_never_raises_on_garbage` | PASS |
+| TC-B04 | Цикл → Blocked + alert без падения воркера | `test_orch026_dep_cycles::test_handle_cycle_blocks_and_alerts`, `test_handle_cycle_never_raises_when_notify_fails` | PASS |
+| TC-B05 | claim_next_job не клеймит заблокированную (слот свободен), разблокируется при done | `test_orch026_task_deps::test_claim_skips_dep_blocked_job`, `test_claim_prefers_unblocked_job_over_blocked` | PASS |
+| TC-B06 | Видимость: строка ожидания в карточке; never-raise рендер | `test_orch026_dep_visibility::test_blocked_task_shows_waiting_line`, `test_render_never_raises_on_dep_error` | PASS |
+| TC-B07 | reconciler F-1 не разблокирует dep-заблокированную | `test_orch026_task_deps::test_reconciler_skip_helper_honours_block` | PASS |
+| TC-B08 | Сквозной: B стартует только после A→done; multiple predecessors | `test_orch026_deps_integration::test_b_waits_for_a_then_runs`, `test_multiple_predecessors_all_must_be_done`, `test_ingest_plane_relations_writes_db` | PASS |
+
+### Общие / миграция / регресс
+
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-G01 | Аддитивная миграция job_deps: идемпотентна, данные сохранены | `test_orch026_migration::test_job_deps_table_created`, `test_job_deps_indices_created`, `test_migration_idempotent_and_preserves_data` | PASS |
+| TC-G02 | Наблюдаемость GET /queue: read-only блок task_deps | `test_orch026_queue_observability::test_queue_endpoint_includes_task_deps`, `test_snapshot_*` | PASS |
+| TC-G03 | Регресс: полный pytest зелёный | `tests/` (991 passed) | PASS |
+
+## Smoke test API (прод 8500)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — OK
+- `GET /status` → активные задачи отдаются, ORCH-026 (id 58) в стадии `testing` — OK
+- `GET /queue` → counts/resilience/reconcile/reaper/merge_verify читаются; брейкер `closed`, preflight OK — OK
+- Примечание: блок `task_deps` в `/queue` прода 8500 ОТСУТСТВУЕТ — ожидаемо: прод-контейнер несёт текущую задеплоенную версию, ORCH-026 ещё не выкатан (self-hosting, деплой на поздних стадиях). Фича наблюдаемости верифицирована in-branch тестом `test_queue_endpoint_includes_task_deps` (PASS) через TestClient на коде ветки.
+
+## Вывод pytest
+```
+tests/test_orch026_*.py — 50 passed, 1 warning in 1.56s
+tests/                   — 991 passed, 1 warning in 26.52s
+```
+(единственный warning — PydanticDeprecatedSince20 в `src/config.py`, предсуществующий, не относится к ORCH-026)
+
+## Покрытие критериев приёмки (03-acceptance-criteria.md)
+Все 16 критериев (AC-A1…A7, AC-B1…B5, AC-G1…G5) покрыты прохождением соответствующих TC и
+подтверждены review-вердиктом APPROVED. Регрессии merge-gate (ORCH-043), merge-verify
+(ORCH-073), reconciler (ORCH-053/068), reaper (ORCH-065) не обнаружено.
+
+## Итог
+**PASS** — 50/50 новых ORCH-026-тестов зелёные, полный регресс 991 passed, smoke API OK,
+прод-контейнер не затронут. Задача готова к переходу на `deploy-staging`.

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

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

@@ -0,0 +1,34 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T16:14:11+00:00
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed. Exit code 0 → advance.
+
+Canonical run (ORCH-048, ADR-001) inside the live staging container:
+
+```
+docker exec orchestrator-staging \
+  python3 /repos/orchestrator/scripts/staging_check.py \
+  --base-url http://localhost:8501 --mode stub
+```
+
+## Result: 8/10 checks PASS
+
+- **Block A (SMOKE):** A1 /health, A2 /queue, A3 ORCH_STAGING=true — all PASS.
+- **Block B (ACCESS):** B4 Plane sandbox (R), B5 Gitea orchestrator-sandbox (R+push), B6 registry isolation (sandbox present, prod ET/ORCH absent) — all PASS.
+- **Block C (E2E, stub):** C7 create issue, C8 trigger pipeline — PASS.
+
+REAL failed: **none** — all pipeline checks green.
+
+## INFRA-WAIVED (ORCH-061)
+
+```
+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
+```
+
+C9a/C9b are the two known sandbox-infra-only checks (depend on SANDBOX bot accounts being members of the sandbox Plane project, not on the pipeline). They are tolerated because every REAL check is green; the script printed `INFRA-WAIVED:` and exited 0 (fail-closed semantics preserved: any REAL failure would still yield exit 1).

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

@@ -0,0 +1,7 @@
+# Business Request: QG-0 title-лимит → параметр ORCH_QG0_TITLE_MAX (дефолт 200)
+
+Work Item ID: ORCH-069
+
+## Description
+
+TBD

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

@@ -0,0 +1,76 @@
+# BRD — ORCH-069: QG-0 title-лимит → параметр ORCH_QG0_TITLE_MAX (дефолт 200)
+
+Work Item ID: ORCH-069
+Тип: Enhancement (QoL / конфигурируемость)
+Источник: Слава, 2026-06-08
+Связано с: QG-0 (gate входа конвейера, `_qg0_errors`)
+
+## 1. Проблема (As-Is)
+QG-0 — первый quality gate конвейера. Он валидирует заголовок и описание задачи
+до старта pipeline (`start_pipeline`) и в soft-режиме на `work_item.created`.
+
+Верхний лимит длины заголовка задачи **захардкожен** в
+`src/webhooks/plane.py:362`:
+
+```python
+if len(name) > 80:
+    errors.append("Title слишком длинный (максимум 80 символов)")
+```
+
+Лимит 80 — «гигиенический», а не структурный. Проверено, что **ниже по течению
+ничего от значения 80 не зависит**:
+- slug ветки режется независимо: `re.sub(...)[:30]` (`src/webhooks/plane.py:478`);
+- БД `tasks.title TEXT` — без ограничения длины;
+- Telegram-карточка использует `html.escape(title)` без обрезки;
+- Plane хранит `name` самостоятельно.
+
+Следствие: вполне валидные осмысленные заголовки длиной 81–200 символов
+отклоняются на входе конвейера без бизнес-причины.
+
+## 2. Цель (To-Be)
+Вынести верхний лимит длины заголовка QG-0 в конфигурируемый параметр со
+значением по умолчанию **200** (вместо текущего хардкода 80). Расширить лимит
+безопасно, сохранив возможность регулировать его через окружение, как и
+остальные `ORCH_*` настройки.
+
+## 3. Бизнес-ценность
+- Меньше ложных отклонений валидных задач на входе конвейера (QoL для постановщика).
+- Лимит становится операционно настраиваемым без правки кода и редеплоя
+  (изменение env-переменной).
+- Изменение чисто аддитивное и обратносовместимое: дефолт 200 > прежних 80, поэтому
+  все заголовки, проходившие раньше, проходят и теперь.
+
+## 4. Объём (Scope)
+### В объёме
+- Новый параметр Settings `qg0_title_max` (env `ORCH_QG0_TITLE_MAX`, дефолт 200).
+- Замена хардкода `> 80` на `> settings.qg0_title_max` в `_qg0_errors`.
+- Динамический текст ошибки с подстановкой актуального лимита.
+- Graceful-поведение при невалидном/пустом значении env → дефолт 200, без падения процесса.
+- Документация: `.env.example`, `.env.staging.example`, `CHANGELOG.md`,
+  при необходимости README-таблица конфигов / `CLAUDE.md`.
+- Юнит-тесты на `_qg0_errors` с разными лимитами.
+
+### Вне объёма (Out of scope)
+- Slug-логика `[:30]` (`src/webhooks/plane.py:478`) — самодостаточна, не трогать.
+- Нижний лимит заголовка (`< 5`) и лимит description (`< 20`) — оставить как есть.
+- Схема БД, реестры `STAGE_TRANSITIONS` / `QG_CHECKS`, контракты `handle_*`.
+- Soft-QG-0 на `work_item.created` (там только warning) — логика валидации общая
+  (`_qg0_errors`), отдельных изменений не требует и не вносит.
+
+## 5. Заинтересованные стороны
+- Owner / постановщик задач (Слава) — снижение ложных отклонений.
+- Агенты конвейера — поведение QG-0 при старте pipeline.
+
+## 6. Ограничения и риски (self-hosting)
+- Правка касается работающего в проде инструмента (self-hosting). Прод-контейнер
+  `orchestrator` в рамках задачи **не рестартить**; обязательна страховка
+  `deploy-staging` (8501).
+- Риск минимален: изменение обратносовместимо, изолировано в одной функции и одном
+  новом параметре config.
+
+## 7. Допущения
+- Механизм чтения env — стандартный `pydantic_settings.BaseSettings` с
+  `env_prefix = "ORCH_"`, как у остальных параметров.
+- «Невалидное/пустое значение → дефолт 200» — требование graceful-деградации:
+  процесс не должен падать на старте из-за мусора в `ORCH_QG0_TITLE_MAX`
+  (нюанс реализации pydantic-валидации передаётся архитектору, см. 02-trz §5).

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

@@ -0,0 +1,95 @@
+# ТЗ — ORCH-069: QG-0 title-лимит → параметр ORCH_QG0_TITLE_MAX (дефолт 200)
+
+Work Item ID: ORCH-069
+
+## 1. Задействованные модули `src/`
+| Файл | Текущее состояние | Требуемое изменение |
+|------|-------------------|---------------------|
+| `src/config.py` | `Settings(BaseSettings)`, `env_prefix = "ORCH_"` (строки 4, 347-349) | Добавить поле `qg0_title_max: int = 200` с комментарием-описанием. |
+| `src/webhooks/plane.py` | `_qg0_errors` (строки 357-367), хардкод `if len(name) > 80:` (строка 362); `from ..config import settings` уже импортирован (строка 11) | Заменить хардкод `> 80` на `> settings.qg0_title_max`; текст ошибки — динамический с подстановкой лимита. |
+
+Других модулей изменение не затрагивает.
+
+## 2. Изменение config.py
+Добавить в класс `Settings` новое поле (рядом с другими `ORCH_*` группами,
+рекомендуется отдельный блок с комментарием):
+
+```python
+# ORCH-069: QG-0 upper title-length limit (entry gate _qg0_errors). The 80-char
+# cap was a hygiene limit, not structural (slug is cut to [:30] independently,
+# DB title TEXT is unbounded). Configurable via env ORCH_QG0_TITLE_MAX; default
+# 200 (was hardcoded 80). Invalid/empty value -> default (graceful, no crash).
+qg0_title_max: int = 200
+```
+
+- Env-переменная: `ORCH_QG0_TITLE_MAX` (автоматически из `env_prefix = "ORCH_"`).
+- Тип `int`, дефолт `200`.
+
+## 3. Изменение `_qg0_errors` (src/webhooks/plane.py)
+Текущий блок (строки 362-363):
+```python
+if len(name) > 80:
+    errors.append("Title слишком длинный (максимум 80 символов)")
+```
+
+Требуемое:
+```python
+if len(name) > settings.qg0_title_max:
+    errors.append(
+        f"Title слишком длинный (максимум {settings.qg0_title_max} символов)"
+    )
+```
+
+Требования:
+- Лимит берётся из `settings.qg0_title_max` (динамически, на каждый вызов — чтобы
+  тесты могли подменять значение через мок/патч settings).
+- Текст ошибки содержит актуальное число лимита (для AC-1/AC-2: текст упоминает
+  200 / 120 соответственно).
+- Нижний лимит заголовка `< 5` (строка 360-361) и проверка description `< 20`
+  (строка 364-365) — **не трогать**.
+- Сигнатура `_qg0_errors(name, description) -> list` не меняется.
+
+## 4. Поведение границы (точная семантика)
+- Условие fail — строго `len(name) > limit`. То есть `len == limit` → PASS,
+  `len == limit + 1` → FAIL.
+- При дефолте: 200 символов → PASS, 201 → FAIL.
+- При `ORCH_QG0_TITLE_MAX=120`: 120 → PASS, 121 → FAIL.
+
+## 5. Graceful-обработка невалидного значения (требование AC-3)
+Требование: невалидное/отсутствующее `ORCH_QG0_TITLE_MAX` → используется дефолт 200,
+процесс не падает.
+
+Нюанс для архитектора/разработчика: `pydantic_settings` по умолчанию при
+непарсящемся в `int` значении env (например `ORCH_QG0_TITLE_MAX=abc` или пустая
+строка) выбрасывает `ValidationError` на инстанцировании `Settings()` —
+т.е. падение на старте процесса. Это противоречит требованию graceful.
+Реализация должна обеспечить, что:
+- отсутствие переменной → дефолт 200 (это стандартное поведение, ОК «из коробки»);
+- пустая строка / нечисловое значение → дефолт 200 без исключения.
+
+Способ (на усмотрение архитектора, без предписания со стороны аналитика) —
+например field-validator с `mode="before"`, который при невалидном входе
+возвращает дефолт. Конкретный механизм фиксируется в ADR на стадии architecture.
+
+## 6. Изменения API
+Нет. Эндпоинты не меняются.
+
+## 7. Изменения схемы БД
+Нет. `tasks.title TEXT` остаётся без ограничения длины.
+
+## 8. Новые QG checks
+Нет. Реестр `QG_CHECKS` и `STAGE_TRANSITIONS` не меняются. QG-0 — не зарегистрированный
+stage-gate, а inline-валидация входа (`_qg0_errors`), её контракт сохраняется.
+
+## 9. Артефакты pipeline, которые должны быть созданы/обновлены
+- `.env.example` — добавить `ORCH_QG0_TITLE_MAX=200` с комментарием.
+- `.env.staging.example` — добавить `ORCH_QG0_TITLE_MAX` (дефолт/комментарий).
+- `CHANGELOG.md` — запись об ORCH-069.
+- README-таблица конфигов / `CLAUDE.md` — обновить при наличии релевантной таблицы
+  параметров (по требованию reviewer; документация = golden source).
+- Юнит-тесты (`tests/`) — см. `04-test-plan.yaml`.
+
+## 10. Обратная совместимость
+- Дефолт 200 > прежних 80 → все ранее проходившие заголовки проходят и теперь.
+- Поведение при не заданном env идентично «как было», но с порогом 200 вместо 80.
+- Изменение чисто аддитивное; откатов/миграций не требует.

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

@@ -0,0 +1,56 @@
+# Критерии приёмки — ORCH-069
+
+Work Item ID: ORCH-069
+
+Формат: каждый критерий имеет чёткое условие PASS/FAIL.
+
+## AC-1 — Дефолтный лимит 200, граница на 201
+**Дано:** env `ORCH_QG0_TITLE_MAX` не задан (используется дефолт 200), description валиден (≥ 20 символов).
+**Тогда:**
+- заголовок длиной 200 символов → `_qg0_errors` НЕ содержит ошибки про длину title (PASS);
+- заголовок длиной 201 символ → `_qg0_errors` содержит ошибку про длину title, и текст ошибки упоминает «200».
+**FAIL если:** на 200 появляется ошибка длины, либо на 201 ошибки нет, либо текст не упоминает 200.
+
+## AC-2 — Настраиваемый лимит 120, граница на 121
+**Дано:** `ORCH_QG0_TITLE_MAX=120` (через мок/патч settings в тесте), description валиден.
+**Тогда:**
+- заголовок 120 символов → нет ошибки длины title (PASS);
+- заголовок 121 символ → есть ошибка длины title, текст упоминает «120».
+**FAIL если:** граница срабатывает не на 121, либо текст ошибки упоминает не 120.
+
+## AC-3 — Graceful при невалидном/пустом значении
+**Дано:** `ORCH_QG0_TITLE_MAX` пустой (`""`) или нечисловой (`"abc"`).
+**Тогда:**
+- инстанцирование `Settings()` / импорт приложения НЕ выбрасывает исключение (процесс не падает);
+- эффективное значение лимита = дефолт 200 (поведение AC-1 сохраняется).
+**FAIL если:** старт процесса падает с `ValidationError`, либо лимит != 200.
+
+## AC-4 — Нижние лимиты не сломаны
+**Дано:** любое валидное значение `ORCH_QG0_TITLE_MAX`.
+**Тогда:**
+- заголовок длиной < 5 символов → `_qg0_errors` содержит ошибку «Title слишком короткий»;
+- description длиной < 20 символов → `_qg0_errors` содержит ошибку «Description слишком короткий».
+**FAIL если:** нижний лимит title или лимит description перестал срабатывать.
+
+## AC-5 — Юнит-тесты зелёные
+**Дано:** реализованные юнит-тесты на `_qg0_errors` с разными значениями лимита (мок settings).
+**Тогда:** `pytest tests/ -q` проходит полностью (зелёный), включая новые тесты ORCH-069 и существующий набор.
+**FAIL если:** хотя бы один тест падает.
+
+## AC-6 — Документация обновлена в том же PR
+**Дано:** PR с изменениями кода.
+**Тогда в том же PR:**
+- `.env.example` содержит `ORCH_QG0_TITLE_MAX` с дефолтом и комментарием;
+- `.env.staging.example` содержит `ORCH_QG0_TITLE_MAX`;
+- `CHANGELOG.md` содержит запись об ORCH-069;
+- при наличии релевантной таблицы конфигов в README / `CLAUDE.md` — она обновлена.
+**FAIL если:** какой-либо из обязательных файлов документации не обновлён (reviewer → REQUEST_CHANGES).
+
+## AC-7 — Обратная совместимость
+**Дано:** env не задан.
+**Тогда:** любой заголовок, который проходил QG-0 при прежнем лимите 80 (len ≤ 80), проходит и теперь (len ≤ 200).
+**FAIL если:** ранее валидный заголовок отклоняется.
+
+## AC-8 — Изоляция изменений
+**Тогда:** не изменены slug-логика (`[:30]`), схема БД, реестры `STAGE_TRANSITIONS` / `QG_CHECKS`, контракты `handle_*`, soft-QG-0 поведение (warning на `work_item.created`).
+**FAIL если:** затронут любой из перечисленных вне-объёмных элементов.

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

@@ -0,0 +1,112 @@
+work_item: ORCH-069
+description: >
+  Юнит-тесты для конфигурируемого верхнего лимита длины заголовка QG-0
+  (_qg0_errors) через параметр settings.qg0_title_max (env ORCH_QG0_TITLE_MAX,
+  дефолт 200). Тесты патчат settings.qg0_title_max (monkeypatch на объекте
+  src.config.settings, который импортирован в src.webhooks.plane) и проверяют
+  границы и тексты ошибок. Файл тестов: tests/test_qg0_title_limit.py.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: "Дефолтный лимит 200: заголовок ровно 200 символов -> нет ошибки длины title (PASS на границе)."
+    module: tests/test_qg0_title_limit.py
+    setup: "settings.qg0_title_max=200 (дефолт); name='x'*200; description валиден (>=20 символов)."
+    assert: "В списке _qg0_errors нет элемента про длину title."
+    covers: [AC-1]
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "Дефолтный лимит 200: заголовок 201 символ -> ошибка длины title, текст упоминает '200'."
+    module: tests/test_qg0_title_limit.py
+    setup: "settings.qg0_title_max=200; name='x'*201; description валиден."
+    assert: "В _qg0_errors есть ошибка длины title и её текст содержит подстроку '200'."
+    covers: [AC-1]
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Настраиваемый лимит 120: заголовок 120 символов -> нет ошибки длины title."
+    module: tests/test_qg0_title_limit.py
+    setup: "monkeypatch settings.qg0_title_max=120; name='x'*120; description валиден."
+    assert: "Нет ошибки длины title."
+    covers: [AC-2]
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "Настраиваемый лимит 120: заголовок 121 символ -> ошибка длины title, текст упоминает '120'."
+    module: tests/test_qg0_title_limit.py
+    setup: "monkeypatch settings.qg0_title_max=120; name='x'*121; description валиден."
+    assert: "Есть ошибка длины title и её текст содержит подстроку '120' (и НЕ '80')."
+    covers: [AC-2]
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Graceful: невалидное (нечисловое) значение env ORCH_QG0_TITLE_MAX не роняет инстанцирование Settings и даёт дефолт 200."
+    module: tests/test_qg0_title_limit.py
+    setup: "monkeypatch.setenv('ORCH_QG0_TITLE_MAX','abc'); создать новый экземпляр Settings()."
+    assert: "Settings() не выбрасывает исключение; settings.qg0_title_max == 200."
+    covers: [AC-3]
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: "Graceful: пустая строка env ORCH_QG0_TITLE_MAX -> дефолт 200, без исключения."
+    module: tests/test_qg0_title_limit.py
+    setup: "monkeypatch.setenv('ORCH_QG0_TITLE_MAX',''); создать новый экземпляр Settings()."
+    assert: "Settings() не падает; settings.qg0_title_max == 200."
+    covers: [AC-3]
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: "Корректное числовое env -> применяется заданное значение (sanity положительного пути)."
+    module: tests/test_qg0_title_limit.py
+    setup: "monkeypatch.setenv('ORCH_QG0_TITLE_MAX','150'); создать новый экземпляр Settings()."
+    assert: "settings.qg0_title_max == 150."
+    covers: [AC-2, AC-3]
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: "Нижний лимит title не сломан: заголовок < 5 символов -> ошибка 'Title слишком короткий' при любом верхнем лимите."
+    module: tests/test_qg0_title_limit.py
+    setup: "settings.qg0_title_max=200; name='abc' (3 символа); description валиден."
+    assert: "В _qg0_errors есть ошибка короткого title."
+    covers: [AC-4]
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: "Лимит description не сломан: description < 20 символов -> ошибка 'Description слишком короткий'."
+    module: tests/test_qg0_title_limit.py
+    setup: "settings.qg0_title_max=200; name валиден (>=5, <=200); description='short'."
+    assert: "В _qg0_errors есть ошибка короткого description."
+    covers: [AC-4]
+    expected: PASS
+
+  - id: TC-10
+    type: unit
+    description: "Обратная совместимость: заголовок длиной 81-200 (ранее отклонялся лимитом 80) теперь проходит при дефолте."
+    module: tests/test_qg0_title_limit.py
+    setup: "settings.qg0_title_max=200; name='x'*100; description валиден."
+    assert: "Нет ошибки длины title (раньше при лимите 80 была бы)."
+    covers: [AC-7]
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: "Полный набор тестов зелёный (регрессия не внесена)."
+    module: tests/
+    command: "pytest tests/ -q"
+    assert: "Все тесты проходят."
+    covers: [AC-5]
+    expected: PASS
+
+notes:
+  - "settings импортирован в src.webhooks.plane как 'from ..config import settings', _qg0_errors читает settings.qg0_title_max динамически -> monkeypatch на src.config.settings.qg0_title_max (или импортируемом объекте) меняет поведение в рамках теста."
+  - "Для TC-05/06/07 нужен СВЕЖИЙ экземпляр Settings(): глобальный src.config.settings создаётся один раз на импорт, поэтому env-тесты инстанцируют Settings() локально, а не полагаются на готовый синглтон."
+  - "Тесты не требуют сети, БД, агентов или FastAPI TestClient — чистая проверка leaf-функции _qg0_errors и парсинга Settings."

docs/work-items/ORCH-069/06-adr/ADR-001-configurable-qg0-title-limit.md

@@ -0,0 +1,143 @@
+# ADR-001: Конфигурируемый QG-0 title-лимит с graceful-деградацией env
+
+## Статус
+Accepted
+
+## Контекст
+QG-0 — inline-валидация входа конвейера (`_qg0_errors` в `src/webhooks/plane.py`),
+вызывается из `start_pipeline` (hard-блок) и из `handle_work_item_created`
+(soft-warning). Верхний лимит длины заголовка захардкожен: `if len(name) > 80`.
+
+BRD/ТЗ (ORCH-069) установили, что лимит 80 — гигиенический, а не структурный:
+ниже по течению от него ничего не зависит (slug режется независимо `[:30]`,
+`tasks.title TEXT` без ограничения, Telegram/Plane хранят/экранируют сами).
+Валидные заголовки 81–200 символов отклоняются на входе без бизнес-причины.
+
+Требуется:
+1. Вынести лимит в конфигурируемый параметр `ORCH_QG0_TITLE_MAX`, дефолт 200.
+2. **Graceful-деградация** (AC-3): пустое/нечисловое значение env → дефолт 200
+   **без падения процесса**. Это и есть единственное нетривиальное архитектурное
+   решение задачи: `pydantic_settings` v2 по умолчанию при непарсящемся в `int`
+   значении env бросает `ValidationError` на инстанцировании `Settings()` —
+   т.е. краш на старте контейнера (`settings = Settings()` на module-import,
+   `src/config.py:352`). Для self-hosting это означало бы падение прод-инструмента
+   из-за опечатки в env — недопустимо.
+
+Стек подтверждён: `pydantic==2.13.4`, `pydantic-settings==2.5.0` (v2 API).
+
+## Решение
+
+### Р-1. Новый параметр Settings
+В `src/config.py`, в класс `Settings`, добавить поле (отдельный блок с
+комментарием, рядом с прочими `ORCH_*`):
+
+```python
+# ORCH-069: QG-0 upper title-length limit (entry gate _qg0_errors).
+# 80-char cap was a hygiene limit, not structural. Env ORCH_QG0_TITLE_MAX;
+# default 200 (was hardcoded 80). Invalid/empty -> default (graceful, no crash).
+qg0_title_max: int = 200
+```
+Env-имя выводится автоматически из `env_prefix = "ORCH_"` → `ORCH_QG0_TITLE_MAX`.
+
+### Р-2. Механизм graceful-деградации — `field_validator(mode="before")`
+Выбран **pydantic v2 `field_validator` с `mode="before"`** как
+минимально-инвазивный, локальный для одного поля механизм. Валидатор перехватывает
+сырое значение env ДО стандартного `int`-парсинга и при невалидном/пустом входе
+возвращает дефолт `200`, гася `ValidationError`:
+
+```python
+from pydantic import field_validator
+
+@field_validator("qg0_title_max", mode="before")
+@classmethod
+def _qg0_title_max_default(cls, v):
+    # Graceful (ORCH-069 AC-3): empty / non-numeric env -> default 200,
+    # process must not crash on startup. Never raises.
+    try:
+        if v is None or (isinstance(v, str) and v.strip() == ""):
+            return 200
+        return int(v)
+    except (TypeError, ValueError):
+        return 200
+```
+
+Семантика:
+- переменная не задана → pydantic не вызывает validator с env, берётся дефолт поля
+  `200` (стандартное поведение «из коробки»);
+- `""`, `"abc"`, мусор → validator возвращает `200`, исключения нет;
+- `"120"` → `int("120") == 120`.
+
+**Почему именно так (рассмотренные альтернативы):**
+- *`Optional[int] + None-fallback на месте чтения`* — отвергнуто: размазывает
+  дефолт по call-site'ам, легко забыть, тип поля перестаёт быть «честным `int`».
+- *try/except вокруг `Settings()` на module-level* — отвергнуто: глушит ВСЕ
+  ошибки конфигурации (маскирует реальные проблемы других полей), слишком грубо.
+- *кастомный тип / `Annotated`-валидатор* — избыточно для одного поля.
+- `field_validator(mode="before")` локален, не трогает остальные поля, не меняет
+  публичный тип `int`, тестируется напрямую через `Settings(qg0_title_max=...)` и
+  env-патч. Контракт «never-raise» консистентен с общим стилем кодовой базы
+  (`_qg0_errors`, парсеры — defensive).
+
+### Р-3. Использование лимита в `_qg0_errors`
+Хардкод `> 80` → динамическое чтение `settings.qg0_title_max` **на каждый вызов**
+(чтобы тест мог патчить `settings`), текст ошибки — f-string с актуальным числом:
+
+```python
+if len(name) > settings.qg0_title_max:
+    errors.append(
+        f"Title слишком длинный (максимум {settings.qg0_title_max} символов)"
+    )
+```
+`settings` уже импортирован в `plane.py`. Сигнатура `_qg0_errors(name, description)
+-> list` не меняется. Нижние лимиты (`< 5` title, `< 20` description) — без правок.
+
+Граница (ТЗ §4): fail строго при `len(name) > limit` → `len == limit` PASS,
+`limit + 1` FAIL.
+
+### Р-4. Что НЕ меняется (инварианты)
+- `STAGE_TRANSITIONS`, `QG_CHECKS` — QG-0 не зарегистрированный stage-gate, а
+  inline-валидация; реестры не трогаются.
+- Схема БД (`tasks.title TEXT`), API, контракты `handle_*`, slug-логика `[:30]`,
+  soft-QG-0 поведение (общая функция `_qg0_errors`, отдельной правки не требует).
+- Топология/инфраструктура (`07-infra-requirements.md` — **N/A**) и схема данных
+  (`08-data-requirements.md` — **N/A**) не затрагиваются.
+
+## Последствия
+
+### Плюсы
+- Лимит операционно настраивается через env без правки кода и редеплоя кода.
+- Чисто аддитивно и обратносовместимо: дефолт 200 > прежних 80 → все ранее
+  проходившие заголовки проходят (AC-7).
+- Опечатка в `ORCH_QG0_TITLE_MAX` не роняет прод-процесс (критично для
+  self-hosting): graceful-fallback на 200.
+- Изменение изолировано в одной функции + одном поле config + одном валидаторе.
+
+### Минусы / ограничения
+- Невалидное env «тихо» проглатывается → оператор не сразу заметит опечатку
+  (лимит молча станет 200). Принято как осознанный trade-off: устойчивость
+  процесса важнее громкости (consistency с требованием AC-3). Рекомендация:
+  при желании усилить наблюдаемость — `logger.warning` в validator; **не вводим**
+  по умолчанию, т.к. на этапе валидации settings логгер может быть не сконфигурён,
+  и это вне объёма ORCH-069 (можно отдельной QoL-задачей).
+- Дефолт 200 — тоже эвристика; структурного верхнего предела по-прежнему нет
+  (его и не требуется — БД/slug/UI к длине устойчивы).
+
+### Влияние на self-hosting
+Прод-контейнер `orchestrator` **не рестартить** в рамках задачи. Изменение
+прокатывается штатно через обязательный `deploy-staging`-гейт (8501) перед
+прод-деплоем. Риск отказа на старте после деплоя снят самим механизмом Р-2
+(graceful), что дополнительно снижает self-hosting-риск.
+
+### Тестируемость (вход для стадий development/testing)
+- `_qg0_errors`: патч `settings.qg0_title_max` → проверка границ 200/201 (AC-1),
+  120/121 (AC-2), нижних лимитов (AC-4).
+- validator: `Settings(qg0_title_max="abc")` / `=""` / env-патч → значение 200,
+  без исключения (AC-3).
+
+## Ссылки
+- BRD: `docs/work-items/ORCH-069/01-brd.md`
+- ТЗ: `docs/work-items/ORCH-069/02-trz.md`
+- Acceptance: `docs/work-items/ORCH-069/03-acceptance-criteria.md`
+- Тех-риски: `docs/work-items/ORCH-069/10-tech-risks.md`
+</content>
+</invoke>

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

@@ -0,0 +1,21 @@
+# Технические риски — ORCH-069
+
+Work Item ID: ORCH-069
+Уровень общего риска: **низкий** (аддитивное, обратносовместимое, изолированное изменение).
+
+| # | Риск | Вероятность | Влияние | Митигация |
+|---|------|-------------|---------|-----------|
+| R-1 | `ValidationError` на старте при мусоре в `ORCH_QG0_TITLE_MAX` → краш прод-процесса (self-hosting) | Средняя (опечатка в env) | Высокое (падение инструмента всех проектов) | `field_validator(mode="before")` гасит невалидный вход → дефолт 200 (ADR Р-2, AC-3). never-raise. |
+| R-2 | Чтение лимита один раз на module-import вместо per-call → тесты не смогут патчить settings | Низкая | Среднее (нетестируемость AC-2) | `_qg0_errors` читает `settings.qg0_title_max` динамически на каждый вызов (ADR Р-3). |
+| R-3 | Off-by-one на границе (`>=` вместо `>`) | Низкая | Низкое (1 символ) | Явная семантика `len > limit` зафиксирована (ТЗ §4, AC-1/AC-2); тесты на 200/201, 120/121. |
+| R-4 | Регресс нижних лимитов (`< 5` title, `< 20` description) при правке функции | Низкая | Среднее | Трогать только верхний лимит; AC-4 покрывает нижние; диф минимален. |
+| R-5 | Тихое проглатывание невалидного env → оператор не заметит опечатку | Средняя | Низкое (лимит молча = 200, конвейер работает) | Осознанный trade-off (ADR «Минусы»): устойчивость > громкость. Опц. `logger.warning` — вне объёма. |
+| R-6 | Случайное затрагивание вне-объёмных элементов (slug `[:30]`, БД, реестры, `handle_*`, soft-QG-0) | Низкая | Среднее | AC-8 — изоляция; reviewer проверяет диф; ADR Р-4 фиксирует инварианты. |
+| R-7 | Документация не обновлена в том же PR (`.env.example`, `.env.staging.example`, `CHANGELOG.md`) | Средняя | Среднее (reviewer REQUEST_CHANGES) | AC-6 чек-лист; документация = golden source (правило 2 CLAUDE.md). |
+
+## Не-риски (явно)
+- Схема БД — не меняется (`tasks.title TEXT` без ограничения).
+- API/эндпоинты — не меняются.
+- Топология/контейнеры/порты — не меняются.
+- Откат/миграция — не требуется (дефолт 200 > 80, чисто аддитивно).
+</content>

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

@@ -0,0 +1,68 @@
+---
+type: review
+work_item_id: ORCH-069
+verdict: APPROVED
+version: 3
+---
+
+# Review ORCH-069
+
+## Summary
+Реализация конфигурируемого QG-0 title-лимита `ORCH_QG0_TITLE_MAX` (дефолт 200)
+выполнена **дословно по ТЗ/ADR** и качественно. Поле `Settings.qg0_title_max`,
+graceful `field_validator(mode="before")` (never-raise → дефолт 200), динамическое
+чтение `settings.qg0_title_max` в `_qg0_errors` с f-string-текстом ошибки. Код
+изолирован (затронуты только `src/config.py` и `src/webhooks/plane.py`), инварианты
+не нарушены, нижние лимиты сохранены. Свежий полный прогон на текущем состоянии
+ветки: `pytest tests/ -q` → **863 passed** (включая 10 новых тестов ORCH-069,
+файл `tests/test_qg0_title_limit.py`, все зелёные). Документация обновлена в том же
+PR полностью. Блокирующих и must-fix findings нет → **APPROVED**.
+
+## Соответствие ТЗ / ADR
+- `src/config.py` — поле `qg0_title_max: int = 200` + валидатор `_qg0_title_max_default`
+  (`mode="before"`, try/except → 200 при `None`/пустой/нечисловой): 1:1 с ADR Р-1/Р-2
+  и ТЗ §2/§5. ✓
+- `src/webhooks/plane.py` — хардкод `> 80` заменён на `> settings.qg0_title_max`,
+  текст ошибки динамический (f-string с актуальным числом); сигнатура `_qg0_errors`,
+  нижний лимит title `< 5`, проверка description `< 20` не тронуты: ADR Р-3, ТЗ §3/§4. ✓
+- Граница строгая (`len == limit` PASS, `limit+1` FAIL) — подтверждена tc01–tc04. ✓
+- Инварианты (ADR Р-4 / AC-8): `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, slug `[:30]`,
+  soft-QG-0, API — НЕ изменены (diff `src/` = только 2 файла). ✓
+
+## Acceptance criteria
+- AC-1 (дефолт 200, граница 201, текст упоминает 200) — tc01/tc02 ✓
+- AC-2 (лимит 120, граница 121, текст 120 не 80) — tc03/tc04 ✓
+- AC-3 (graceful пустое/`abc` → 200 без краха) — tc05/tc06 + позитив tc07 + валидатор ✓
+- AC-4 (нижние лимиты title<5 / desc<20) — tc08/tc09 ✓
+- AC-5 (pytest зелёный) — 863 passed ✓
+- AC-6 (документация в том же PR) — выполнен полностью ✓
+- AC-7 (обратная совместимость, ≤80 проходит при 200) — tc10 ✓
+- AC-8 (изоляция изменений) — ✓
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice-to-have (не блокирует)
+- В конце `06-adr/ADR-001-configurable-qg0-title-limit.md` присутствуют артефактные
+  хвостовые теги (`</content>`, `</invoke>`). Косметика в артефакте стадии architecture;
+  на корректность кода/контракта не влияет. Править артефакт чужой стадии в рамках
+  ревью не уполномочен — отмечено для будущей чистки.
+
+## Документация
+- `.env.example` — добавлен `ORCH_QG0_TITLE_MAX=200` с комментарием. ✓
+- `.env.staging.example` — добавлен `ORCH_QG0_TITLE_MAX=200`. ✓
+- `CHANGELOG.md` — подробная запись об ORCH-069 (раздел Added). ✓
+- `README.md` — таблица env-конфигов дополнена строкой `ORCH_QG0_TITLE_MAX`. ✓
+- ADR `06-adr/ADR-001-configurable-qg0-title-limit.md` — присутствует, согласован
+  с кодом. ✓
+- `docs/architecture/README.md` / `CLAUDE.md` — обновления не требуют (QG-0 — inline
+  soft/hard-валидация входа, не зарегистрированный stage-gate; API/стадии/QG-реестр
+  не менялись). ОК.

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

@@ -0,0 +1,98 @@
+---
+type: test-report
+work_item_id: ORCH-069
+result: PASS
+---
+
+# Test Report — ORCH-069
+
+QG-0 title-лимит → параметр `ORCH_QG0_TITLE_MAX` (дефолт 200)
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3 (plugins: anyio-4.13.0, asyncio-0.23.8; asyncio mode=auto)
+- Ветка: `feature/ORCH-069-qg-0-title-orch-qg0-title-max-`
+- Worktree: `/repos/_wt/orchestrator/feature_ORCH-069-qg-0-title-orch-qg0-title-max-`
+- Prod-health (8500): `{"status":"ok","service":"orchestrator"}` — не трогался (self-hosting safety)
+- Дата: 2026-06-08
+
+## Предусловия
+- Review-вердикт `12-review.md`: **APPROVED** (version 3) ✓
+- Изменения изолированы: `src/config.py`, `src/webhooks/plane.py` (+ тесты, + документация)
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+| TC ID | Описание | Покрывает | Результат |
+|-------|----------|-----------|-----------|
+| TC-01 | Дефолт 200: title=200 → нет ошибки длины (граница PASS) | AC-1 | PASS |
+| TC-02 | Дефолт 200: title=201 → ошибка длины, текст упоминает «200» | AC-1 | PASS |
+| TC-03 | Лимит 120: title=120 → нет ошибки длины | AC-2 | PASS |
+| TC-04 | Лимит 120: title=121 → ошибка, текст «120» (не «80») | AC-2 | PASS |
+| TC-05 | Graceful: env `abc` → дефолт 200, без краха `Settings()` | AC-3 | PASS |
+| TC-06 | Graceful: пустой env `""` → дефолт 200, без исключения | AC-3 | PASS |
+| TC-07 | Валидный env `150` → применяется 150 (позитивный путь) | AC-2, AC-3 | PASS |
+| TC-08 | Нижний лимит title < 5 не сломан | AC-4 | PASS |
+| TC-09 | Лимит description < 20 не сломан | AC-4 | PASS |
+| TC-10 | Обратная совместимость: title 81–200 проходит при дефолте | AC-7 | PASS |
+| TC-11 | Полный набор тестов зелёный (нет регрессии) | AC-5 | PASS |
+
+## Сопоставление с критериями приёмки (03-acceptance-criteria.md)
+
+| AC | Критерий | Статус |
+|----|----------|--------|
+| AC-1 | Дефолт 200, граница на 201, текст упоминает 200 | PASS (TC-01/02) |
+| AC-2 | Настраиваемый лимит 120, граница 121, текст 120 | PASS (TC-03/04/07) |
+| AC-3 | Graceful при пустом/нечисловом значении → 200 | PASS (TC-05/06) |
+| AC-4 | Нижние лимиты title<5 / description<20 не сломаны | PASS (TC-08/09) |
+| AC-5 | Юнит-тесты зелёные (весь набор) | PASS (863 passed) |
+| AC-6 | Документация в том же PR (.env.example, .env.staging.example, CHANGELOG, README) | PASS (подтверждено review) |
+| AC-7 | Обратная совместимость (≤80 проходит при 200) | PASS (TC-10) |
+| AC-8 | Изоляция: slug `[:30]`, БД, STAGE_TRANSITIONS/QG_CHECKS, handle_* не тронуты | PASS (diff = 2 файла src/) |
+
+## Smoke test API (prod 8500, read-only)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — OK
+- `GET /status` → отдаёт активные задачи (ORCH-069 в стадии `testing`) — OK
+- `GET /queue` → `counts: queued=0 running=1 done=459 failed=4 cancelled=1`; breaker `closed`, preflight ok — OK
+
+## Целевой прогон ORCH-069 (tests/test_qg0_title_limit.py)
+```
+collected 10 items
+
+tests/test_qg0_title_limit.py::test_tc01_default_limit_200_boundary_pass PASSED
+tests/test_qg0_title_limit.py::test_tc02_default_limit_200_boundary_fail PASSED
+tests/test_qg0_title_limit.py::test_tc03_custom_limit_120_boundary_pass PASSED
+tests/test_qg0_title_limit.py::test_tc04_custom_limit_120_boundary_fail PASSED
+tests/test_qg0_title_limit.py::test_tc05_graceful_non_numeric_env PASSED
+tests/test_qg0_title_limit.py::test_tc06_graceful_empty_env PASSED
+tests/test_qg0_title_limit.py::test_tc07_valid_numeric_env PASSED
+tests/test_qg0_title_limit.py::test_tc08_short_title_still_errors PASSED
+tests/test_qg0_title_limit.py::test_tc09_short_description_still_errors PASSED
+tests/test_qg0_title_limit.py::test_tc10_backward_compat_titles_81_to_200 PASSED
+
+======================== 10 passed, 1 warning in 0.31s =========================
+```
+
+## Полный прогон (pytest tests/ -q)
+```
+........................................................................ [  8%]
+........................................................................ [ 16%]
+........................................................................ [ 25%]
+........................................................................ [ 33%]
+........................................................................ [ 41%]
+........................................................................ [ 50%]
+........................................................................ [ 58%]
+........................................................................ [ 66%]
+........................................................................ [ 75%]
+........................................................................ [ 83%]
+........................................................................ [ 91%]
+.......................................................................  [100%]
+863 passed, 1 warning in 21.49s
+```
+
+(Единственный warning — PydanticDeprecatedSince20 в `src/config.py:5`, существующий
+class-based config; к ORCH-069 не относится, не является ошибкой.)
+
+## Итог
+**PASS** — все 11 TC из тест-плана пройдены, все 8 критериев приёмки выполнены,
+полный регресс зелёный (863 passed), smoke-тесты API OK. Регрессии не внесены.
+Задача готова к переходу на стадию `deploy-staging`.

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

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

@@ -0,0 +1,25 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T11:20:02+00:00
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed via `docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub` (run through the Docker Engine API since the `docker` CLI is not installed on the host; equivalent in-container execution per ORCH-048/ADR-001).
+
+**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
+
+All REAL (pipeline) checks are green. The two failing checks are the known SANDBOX_INFRA checks (C9a/C9b), waived per ORCH-061 because every REAL check passed.
+
+```
+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
+```
+
+## Block results
+- **[Block A] SMOKE** — A1 /health 200 ok ✓ · A2 /queue 200 with counts ✓ · A3 ORCH_STAGING=true ✓
+- **[Block B] ACCESS** — B4 Plane sandbox accessible ✓ · B5 Gitea orchestrator-sandbox push=true ✓ · B6 Registry isolation (sandbox present, prod ET/ORCH absent) ✓
+- **[Block C] E2E (stub)** — C7 Create issue in Plane SANDBOX ✓ · C8 Trigger pipeline via /webhook/plane ✓ · C9a Branch appears in orchestrator-sandbox ✗ (SANDBOX_INFRA, waived) · C9b Analyst job enqueued ✗ (SANDBOX_INFRA, waived)
+
+REAL failed: none. SANDBOX_INFRA failed: C9a, C9b (waived). tolerance: staging_infra_tolerance_enabled=True.

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

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

@@ -0,0 +1,7 @@
+# Business Request: CRIT: эрозия main — код ORCH-067/069 затёрт ребейзами, не доехал
+
+Work Item ID: ORCH-073
+
+## Description
+
+TBD

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

@@ -0,0 +1,98 @@
+# 01 — BRD: ORCH-073 — CRIT: эрозия main (код ORCH-067/069 затёрт ребейзами, не доехал)
+
+- **Work Item:** ORCH-073
+- **Тип:** BUG CRITICAL — целостность `main`, накопительный регресс/эрозия
+- **Репозиторий:** orchestrator (self-hosting)
+- **Ветка:** `feature/ORCH-073-crit-main-orch-067-069`
+- **Связь:** усиливает/чинит ORCH-071 (merge-verify); НЕ покрыт ORCH-071.
+
+## 1. Бизнес-проблема
+
+Код успешно «задеплоенных» и переведённых в `done` задач **ORCH-067** (tracker bump,
+Plane-статусы, кликабельные ссылки `plane_issue_link`) и **ORCH-069** (`qg0_title_max`)
+**физически отсутствовал в `origin/main`**, хотя обе прошли весь конвейер, Confirm Deploy,
+merge-verify `CONFIRMED` и стали `done`. В `main` попадали только их **docs-коммиты**
+(staging-log / verdict через отдельные авто docs-PR), но НЕ код feature-веток.
+
+Внешнее проявление (нашёл Слава, 08.06): «ссылок на задачу в Plane нет», карточка Telegram
+показывает сырой номер задачи вместо кликабельной ссылки — потому что код ссылок есть в ветке
+ORCH-067, но не в `main`.
+
+**Накопительный характер:** каждая новая задача срезает ветку от УСТАРЕВШЕГО `main` и при merge
+тихо (без конфликт-маркеров) затирает код предшественника. Уже потеряны ORCH-067 и ORCH-069;
+без системного фикса теряется код каждой следующей задачи с правкой `CHANGELOG.md`.
+
+## 2. Подтверждённый root cause (git-аудит 08.06, не гипотеза)
+
+1. **`verify_merged_to_main` подтверждает merge по ложному признаку.**
+   `src/merge_gate.py::verify_merged_to_main` возвращает `True`, если выполнено **ЛИБО**
+   `pr_already_merged(repo, branch)`, **ЛИБО** `git merge-base --is-ancestor <sha> origin/main`.
+   Первая ветка (`pr_already_merged`) и есть дыра.
+2. **`pr_already_merged` засчитывает ЛЮБОЙ merged PR ветки.**
+   `src/merge_gate.py::pr_already_merged` делает `GET /pulls?state=all&head=<branch>` и
+   возвращает `True`, если **хоть один** PR `merged==True`. У одной ветки несколько PR
+   (code-PR + авто docs-PR со staging/deploy-логами). Сливается docs-PR → функция говорит
+   «already-merged» → `verify_merged_to_main`=`True` → merge-verify `CONFIRMED` → `done`,
+   хотя code-PR НЕ слит. **Ложно-зелёный.**
+3. **CHANGELOG.md-ребейзы — вторичный усилитель.**
+   Merge-gate `auto_rebase_onto_main` при конфликте `CHANGELOG.md` откатывает `deploy-staging →
+   development`; повторный ребейз ветки от старого `main` несёт устаревшие версии файлов
+   (`notifications.py`/`config.py`/`webhooks/plane.py`), которые при merge тихо затирают
+   соседний код (фантом-эффект, как в ORCH-071, без конфликт-маркеров).
+
+> Уточнение для архитектора: в ТЗ упомянута «инвертированная проверка `merge-base --is-ancestor
+> origin/main HEAD` (merge_gate.py ~76)» — это `branch_is_behind_main` (детектор «ветка
+> свежая»), он корректен для своей цели. Фактический дефект merge-verify — это OR-ветка
+> `pr_already_merged` в `verify_merged_to_main` (строка ~649), которая засчитывает docs-PR.
+
+## 3. Состояние на момент анализа (G1)
+
+Аудит `origin/main` показал, что **восстановительный PR #76** (`restore(main): re-merge
+ORCH-067 + ORCH-069 (ORCH-073)`) уже вернул код в `main`:
+- `plane_issue_link` присутствует (`src/notifications.py`), `qg0_title_max` присутствует
+  (`src/config.py`, `src/webhooks/plane.py`), `verify_merged_to_main` присутствует.
+
+Таким образом **G1 (восстановление кода) фактически выполнено** ручным restore-PR. Задача
+ORCH-073 должна **подтвердить и зафиксировать** это в критериях приёмки (AC-1) и сосредоточиться
+на **системном фиксе навсегда** (G2–G5 / FR-1…FR-5), иначе регресс повторится.
+
+## 4. Цели (Goals)
+
+- **G1.** КОД ORCH-067 и ORCH-069 присутствует в `origin/main` одновременно с ORCH-071
+  (подтвердить restore-PR #76, зафиксировать маркеры > 0). Pytest зелёный. Прод задеплоен.
+- **G2 (FR-2/FR-3).** `merge`/`pr_already_merged` различают **code-PR** и **docs-PR** — merge
+  засчитывается только за PR с кодом ветки (`base==main`, `head==<feature-branch>`).
+- **G3 (FR-1, ядро).** `verify_merged_to_main` подтверждает merge **ТОЛЬКО** по факту «deployed
+  SHA — предок `origin/main`». PR-флаги вспомогательны, не достаточны.
+- **G4 (FR-4).** Защита от CHANGELOG-затирания: `.gitattributes` с `CHANGELOG.md merge=union`
+  (+ опц. `docs/*.md merge=union` для append-only).
+- **G5 (FR-5, регресс-гард навсегда).** После деплоя — sanity-проверка целостности `main`:
+  deployed SHA в `main` И набор маркеров ранее-merged задач не уменьшился. Откат соседнего кода
+  → alert «main regressed», задача НЕ `done`.
+
+## 5. Не-цели (Out of scope)
+
+- Не менять Plane / схему БД.
+- Не отменять self-hosting safety (не ронять прод, merge только через PR-API, без force-push в `main`).
+- Не менять ручной гейт `Confirm Deploy`.
+- Не менять поведение merge/verify для non-self репозиториев (enduro-trails) — обратная совместимость.
+
+## 6. Инварианты
+
+- **INV-1.** never-raise на верификации (alert, не падение).
+- **INV-2.** self-hosting safety: прод не падает; merge только PR-API, без force-push в `main`.
+- **INV-3.** ручной `Confirm Deploy` сохранён.
+- **INV-4.** Идемпотентность: повторный прогон / reaper не делает второй merge; idempotency
+  опирается на «SHA-в-main», а не на «любой merged PR».
+- **INV-5.** Обратная совместимость non-self (enduro): поведение merge/verify без изменений.
+
+## 7. Заинтересованные стороны
+
+- **Owner / Слава** — потребитель (видит кликабельные ссылки в карточке; доверие к merge-verify).
+- **Все проекты на инстансе** (enduro-trails) — общий `main`/очередь/БД; регресс орка = групповой риск.
+
+## 8. Срочность
+
+КРИТИКАЛ. Без FR-1/FR-4/FR-5 каждая новая задача с правкой `CHANGELOG.md` продолжает терять код
+предшественников (уже потеряны 067, 069). Ложно-зелёный merge-verify подрывает само ядро
+автономности конвейера.

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

@@ -0,0 +1,129 @@
+# 02 — ТЗ: ORCH-073 — системный фикс эрозии main + восстановление кода 067/069
+
+> ТЗ описывает ТРЕБУЕМОЕ ПОВЕДЕНИЕ и точки изменения. Выбор конкретного дизайна
+> (где именно резать docs-PR от code-PR, формат набора регресс-маркеров) — за архитектором (`06-adr`).
+> Запрещено комментировать ТЗ задним числом: если требование не годится — вернуть в Анализ.
+
+## 1. Задействованные модули `src/`
+
+| Модуль | Роль в фиксе | FR |
+| --- | --- | --- |
+| `src/merge_gate.py` | `verify_merged_to_main`, `pr_already_merged`, `merge_pr`, новый регресс-гард | FR-1, FR-2, FR-3, FR-5 |
+| `src/stage_engine.py` | `_handle_merge_verify` (под-гейт `deploy → done`) — точка вызова FR-1/FR-5 | FR-1, FR-5 |
+| `src/config.py` | (опц.) настройки регресс-гарда: kill-switch + набор маркеров/таймаут | FR-5 |
+| `.gitattributes` (корень репо, новый) | `CHANGELOG.md merge=union` (+ опц. `docs/*.md merge=union`) | FR-4 |
+| `docs/architecture/README.md` | раздел merge-verify — обновить под новую семантику | AC-8 |
+| `CHANGELOG.md` | запись Unreleased | AC-8 |
+| `docs/work-items/ORCH-073/06-adr/` | ADR на новую семантику merge-verify + регресс-гард | AC-8 |
+
+## 2. Требуемые изменения по коду
+
+### FR-1 (G3, ядро) — `verify_merged_to_main` чинит семантику
+**Текущее (баг):** `src/merge_gate.py::verify_merged_to_main(repo, branch, sha)` возвращает `True`,
+если `pr_already_merged(...)` **ИЛИ** `git merge-base --is-ancestor <sha> origin/main`.
+OR-ветка `pr_already_merged` засчитывает docs-PR → ложно-зелёный.
+
+**Требование:** подтверждение merge — **ТОЛЬКО** прямой факт «deployed commit является предком
+`origin/main`»:
+- после `git fetch origin main` выполнить `git merge-base --is-ancestor <deployed_sha> origin/main`;
+- `rc==0` → `True` (код в main), иначе → `False`.
+- `pr_already_merged` **НЕ может быть единственным/достаточным** условием `True`. Допустимо
+  оставить PR-флаг только как **вспомогательный** сигнал (idempotency / диагностика), но он НЕ
+  должен подтверждать merge при отсутствии SHA в main.
+- Пустой `sha` → неопределённо → `False` (fail-closed: alert + HOLD), как сейчас.
+- never-raise: любая git/HTTP-ошибка → `False` (INV-1).
+
+### FR-2 (G2) — `pr_already_merged` различает code-PR и docs-PR
+**Текущее (баг):** `src/merge_gate.py::pr_already_merged` возвращает `True` за ЛЮБОЙ
+`merged==True` PR из `GET /pulls?state=all&head=<branch>` — включая авто docs-PR.
+
+**Требование (на выбор архитектора, предпочтителен вариант «б»):**
+- **(а)** засчитывать merged только для PR, реально несущего код ветки: `base.ref==main`
+  И `head.ref==<feature-branch>` (исключить docs/* ветки и docs-only PR); **или**
+- **(б, предпочтительно)** понизить роль `pr_already_merged` до **idempotency-guard**: единственный
+  критерий «merged/done» — SHA-предок-`main` (FR-1); PR-флаги вспомогательны.
+- Поведение для non-self репо (enduro) не меняется (INV-5).
+- never-raise → `False` (консервативно).
+
+### FR-3 (G2) — `merge_pr` реально сливает code-ветку
+**Требование:** `src/merge_gate.py::merge_pr` мержит ИМЕННО feature-PR с кодом (`base==main`,
+`head==<feature-branch>`), а не полагается на docs-PR. После merge — обязательная верификация
+по FR-1 (SHA в main) как единственный источник истины. Merge только через Gitea PR-merge API,
+никогда push/force-push в `main` (INV-2).
+
+### FR-5 (G3 регресс-гард, защита навсегда) — sanity-проверка целостности main
+**Требование:** перед фиксацией `done` (в `_handle_merge_verify`, ПОСЛЕ зелёного
+`check_deploy_status`, до `update_task_stage`):
+1. Подтвердить FR-1 (deployed SHA — предок `origin/main`).
+2. (опц., по дизайну) Проверить, что в `origin/main` присутствует **набор маркеров** ключевых
+   функций недавно-merged задач (regression marker set) — merge не уменьшил его.
+3. При откате соседнего кода / отсутствии маркера → **alert** «main regressed: code of <prev
+   tasks> missing» (Telegram + Plane), задача **НЕ `done`** (HOLD), как ветка not-merged в ORCH-071.
+- Реакция — **ALERT-only + HOLD**, без авто-отката на `development` (это инфра-дефект, не код-фолт).
+- never-raise (INV-1); kill-switch (как `merge_verify_enabled`); условность только для self-hosting
+  / `merge_verify_repos` (INV-5).
+- Набор маркеров — конфигурируемый/декларативный (например, в `src/config.py` или рядом), чтобы
+  следующие задачи могли его расширять. Точный формат — за архитектором.
+
+### FR-4 (G2/G4 корень) — `.gitattributes` с `merge=union`
+**Требование:** в корне репо завести `.gitattributes`:
+```
+CHANGELOG.md merge=union
+# опционально для append-only документов:
+# docs/**/*.md merge=union   # ВНИМАНИЕ: union НЕ годится для файлов, где правки
+                              # переписывают строки — применять только к append-only
+```
+- `merge=union` встроен в git (драйвер по умолчанию), доп. конфиг хоста не требуется — но
+  проверить, что атрибут реально применяется в worktree агентов (`git check-attr merge CHANGELOG.md`).
+- Эффект: при `auto_rebase_onto_main` правки `## [Unreleased]` авто-сливаются (обе записи
+  сохраняются) без конфликта → ветка не откатывается в `development` и не затирает соседний код.
+
+## 3. Изменения API
+
+- **Внешних HTTP API оркестратора (`src/main.py` endpoints) НЕ менять.**
+- Внутренние сигнатуры:
+  - `verify_merged_to_main(repo, branch, sha) -> bool` — семантика меняется, сигнатура сохраняется.
+  - `pr_already_merged(repo, branch) -> bool` — семантика/назначение уточняется.
+  - `merge_pr(repo, branch) -> tuple[bool, str]` — поведение уточняется (фильтр code-PR).
+  - (опц.) новая функция регресс-гарда в `merge_gate.py` — `tuple[bool, str]`/`bool`, never-raise.
+- `GET /queue` `merge_verify_status()` — допустимо дополнить счётчиком регресс-алертов (read-only,
+  не источник истины).
+- Внешние вызовы Gitea — те же эндпоинты (`/pulls`, `/pulls/{index}/merge`).
+
+## 4. Изменения схемы БД
+
+- **НЕТ.** Схема БД (`src/db.py`) не трогается (Не-цель). Регресс-гард опирается на git/`origin/main`,
+  не на новые таблицы.
+
+## 5. Требования к новым/изменённым QG checks
+
+- **Новых зарегистрированных QG-checks не вводить.** Логика остаётся **под-гейтом** в
+  `advance_stage` (`_handle_merge_verify`), как ORCH-071 — не новый элемент реестра `QG_CHECKS`.
+- Реестр `QG_CHECKS`, `check_deploy_status`, `_parse_deploy_status`, merge-gate
+  (`check_branch_mergeable`), image-freshness — **без изменений**.
+
+## 6. Конфигурация (`src/config.py` / `.env.example`)
+
+- Существующие `merge_verify_enabled` (kill-switch, дефолт `true`), `merge_verify_repos` (пусто →
+  только self-hosting), `merge_pr_timeout_s`, `merge_verify_timeout_s` — переиспользовать.
+- (опц., по дизайну) новые: kill-switch регресс-гарда и декларация набора маркеров. Дефолты —
+  безопасные (для non-self — no-op). Любой новый ключ задокументировать в `.env.example`.
+
+## 7. Артефакты pipeline, которые должны быть созданы/обновлены
+
+- `docs/work-items/ORCH-073/06-adr/ADR-001-*.md` — решение по новой семантике merge-verify
+  (FR-1/FR-2/FR-3) + регресс-гард (FR-5) + `.gitattributes` (FR-4).
+- `docs/architecture/README.md` — обновить раздел «Merge-в-main + пост-деплой верификация»
+  (ORCH-071) под FR-1 (SHA как единственный критерий) и добавить регресс-гард FR-5.
+- `CHANGELOG.md` — запись в `## [Unreleased]`.
+- `docs/work-items/ORCH-073/10-tech-risks.md`, `12-review.md`, `13-test-report.md`,
+  `14-deploy-log.md`, `15-staging-log.md` — по ходу конвейера.
+- `04-test-plan.yaml` (этот пакет) — реализовать тесты в `tests/`.
+
+## 8. Аудит G4 (зафиксировать в ADR / 06-adr)
+
+Зафиксировать подтверждённую причину docs-only merge: у feature-ветки 067/069 в `main` попадали
+только авто docs-PR (staging-log / deploy-log / CLAUDE.md / CHANGELOG), а code-PR не сливался,
+при этом `pr_already_merged` засчитывал docs-PR → merge-verify ложно `CONFIRMED` → `done`.
+Корень устранён FR-1+FR-2+FR-3. Восстановление кода (G1) уже выполнено restore-PR #76 —
+подтвердить маркеры в `origin/main` (AC-1).

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

@@ -0,0 +1,77 @@
+# 03 — Критерии приёмки: ORCH-073
+
+Каждый критерий — однозначный PASS/FAIL. Reviewer/Tester проверяют буквально.
+
+## AC-1 — Код 067/069/071 одновременно в main (G1)
+`origin/main` содержит **одновременно**: `plane_issue_link` + кликабельный заголовок (ORCH-067),
+`qg0_title_max` (ORCH-069), `verify_merged_to_main` (ORCH-071).
+- **PASS:** все три маркера присутствуют, счётчики > 0:
+  `git grep -c plane_issue_link origin/main -- src/notifications.py` > 0;
+  `git grep -c qg0_title_max origin/main -- src/` > 0;
+  `git grep -c verify_merged_to_main origin/main -- src/merge_gate.py` > 0.
+- **FAIL:** хотя бы один маркер == 0.
+
+## AC-2 — `verify_merged_to_main` подтверждает merge ТОЛЬКО по SHA-в-main (FR-1)
+`verify_merged_to_main(repo, branch, sha)` возвращает `True` **только** когда `sha` — реальный
+предок `origin/main`.
+- **PASS:** unit-тест: `sha` НЕ в `main` → `False`, **даже если** существует merged docs-PR той же
+  ветки (mock `pr_already_merged`/Gitea возвращает merged docs-PR). `sha` в `main` → `True`.
+- **FAIL:** функция возвращает `True` при `sha` не в `main` из-за merged docs-PR.
+
+## AC-3 — Воспроизведение исходного бага → НЕ done + alert (FR-1/FR-2)
+Задача с merged **docs-PR**, но БЕЗ merged **code-PR** (SHA не в main): merge-verify НЕ
+`CONFIRMED`.
+- **PASS:** `_handle_merge_verify` возвращает HOLD (intervened) → задача остаётся на `deploy`,
+  НЕ `done`, отправлен alert «not merged» (Telegram + Plane `set_issue_blocked`). Mock
+  воспроизводит сценарий ORCH-067/069.
+- **FAIL:** задача доходит до `done` / нет alert.
+
+## AC-4 — `.gitattributes CHANGELOG.md merge=union` (FR-4)
+В корне репо есть `.gitattributes` с `CHANGELOG.md merge=union`.
+- **PASS:** файл существует, `git check-attr merge CHANGELOG.md` → `merge: union`; тест: два
+  последовательных ребейза/слияния с правкой `## [Unreleased]` НЕ дают конфликта, обе записи
+  сохранены в результирующем `CHANGELOG.md`.
+- **FAIL:** атрибут отсутствует/не применяется ИЛИ возникает конфликт-маркер при ребейзе.
+
+## AC-5 — Регресс-гард ловит откат соседнего кода (FR-5)
+После деплоя `main` без маркера ранее-merged задачи → alert, задача НЕ `done`.
+- **PASS:** тест: симуляция `main`, где deployed SHA есть, но набор маркеров уменьшился (или
+  deployed SHA НЕ предок main) → `_handle_merge_verify` HOLD + alert «main regressed», НЕ `done`.
+- **FAIL:** регресс соседнего кода не пойман, задача `done`.
+
+## AC-6 — Happy-path без ложных alert (INV-5 / AC-5 ТЗ)
+Код реально в `main` (deployed SHA — предок `origin/main`) → задача `done` штатно, без ложного
+alert; для non-self репо (enduro) merge/verify без изменений.
+- **PASS:** тест happy-path: SHA в main → `verify_merged_to_main`=`True`, `_handle_merge_verify`
+  возвращает «advance» (не intervened); non-self репо → под-гейт no-op.
+- **FAIL:** ложный alert на корректном merge ИЛИ изменение поведения для enduro.
+
+## AC-7 — Идемпотентность по SHA-в-main (INV-4)
+Повторный прогон/reaper уже-слитой задачи (SHA в main) → no-op, без второго merge.
+- **PASS:** тест: re-drive задачи с SHA-в-main → `merge_pr` no-op («already-merged»/idempotent),
+  второго Gitea POST merge нет; задача остаётся `done`.
+- **FAIL:** второй merge / дубликат / ошибка.
+
+## AC-8 — Документация и тесты обновлены (правило агентов §2/§6)
+- **PASS:** обновлены `CHANGELOG.md` (Unreleased), `docs/architecture/README.md` (раздел
+  merge-verify под FR-1 + регресс-гард FR-5), создан ADR в `docs/work-items/ORCH-073/06-adr/`;
+  pytest зелёный (`pytest tests/ -q`).
+- **FAIL:** доки/ADR не обновлены ИЛИ pytest красный.
+
+## AC-9 — G4 аудит задокументирован
+Причина docs-only merge (code-PR не слит, `pr_already_merged` засчитал docs-PR) зафиксирована в
+ADR/06-adr, корень устранён (FR-1+FR-2+FR-3).
+- **PASS:** ADR содержит раздел «Root cause / G4 audit» с воспроизведением и устранением.
+- **FAIL:** аудит отсутствует.
+
+## AC-10 — Воспроизведение на staging «исправлено навсегда» (G3/AC-9 ТЗ)
+2 задачи, обе с правкой `CHANGELOG.md`, прогнаны через staging → обе доезжают в `main` без потери
+кода друг друга.
+- **PASS:** зафиксировано в `15-staging-log.md`: оба набора маркеров присутствуют в `main` после
+  обоих merge; ни одна правка CHANGELOG не вызвала конфликт/откат.
+- **FAIL:** код одной задачи затёрт другой ИЛИ конфликт CHANGELOG.
+
+## AC-11 — self-hosting safety сохранена (INV-2/INV-3)
+- **PASS:** merge только через PR-API (без force-push в `main`); прод-контейнер не падал в рамках
+  задачи; ручной `Confirm Deploy` сохранён.
+- **FAIL:** force-push в main / рестарт прод-контейнера в рамках merge / обход Confirm Deploy.

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

@@ -0,0 +1,117 @@
+work_item: ORCH-073
+title: "CRIT: эрозия main — системный фикс merge-verify + восстановление кода 067/069"
+notes: >
+  Покрытие FR-1..FR-5 / AC-1..AC-11. Все верификаторы — never-raise (INV-1):
+  при ошибке git/HTTP → False (fail-closed), не падение. Gitea/git вызовы мокаются
+  (monkeypatch httpx + subprocess), как в существующих тестах merge_gate/stage_engine.
+  Тесты регресс-гарда и .gitattributes используют временный git-репозиторий (tmp_path).
+
+tests:
+  # ---- FR-1: verify_merged_to_main — SHA-в-main как единственный критерий ----
+  - id: TC-01
+    type: unit
+    description: "verify_merged_to_main: sha — предок origin/main → True (happy-path, AC-6)."
+    module: tests/test_orch073_merge_verify.py
+    expected: PASS
+  - id: TC-02
+    type: unit
+    description: "verify_merged_to_main: sha НЕ предок main И существует merged docs-PR ветки → False (баг 067/069, AC-2)."
+    module: tests/test_orch073_merge_verify.py
+    expected: PASS
+  - id: TC-03
+    type: unit
+    description: "verify_merged_to_main: пустой sha → False (неопределённо, fail-closed)."
+    module: tests/test_orch073_merge_verify.py
+    expected: PASS
+  - id: TC-04
+    type: unit
+    description: "verify_merged_to_main: git fetch/merge-base бросает исключение → False (never-raise, INV-1)."
+    module: tests/test_orch073_merge_verify.py
+    expected: PASS
+
+  # ---- FR-2: pr_already_merged различает code-PR / docs-PR ----
+  - id: TC-05
+    type: unit
+    description: "pr_already_merged/идентификация PR: merged docs-PR (head=docs/*, base=main) НЕ засчитывается как merge кода ветки."
+    module: tests/test_orch073_pr_classify.py
+    expected: PASS
+  - id: TC-06
+    type: unit
+    description: "merged code-PR (head=<feature-branch>, base=main) корректно распознаётся как code-merge."
+    module: tests/test_orch073_pr_classify.py
+    expected: PASS
+  - id: TC-07
+    type: unit
+    description: "pr_already_merged: HTTP-ошибка/не-200 → False (never-raise, консервативно)."
+    module: tests/test_orch073_pr_classify.py
+    expected: PASS
+
+  # ---- FR-3: merge_pr сливает именно code-ветку ----
+  - id: TC-08
+    type: unit
+    description: "merge_pr выбирает open PR с head==<feature-branch> и base==main (не docs/*), вызывает Gitea POST merge."
+    module: tests/test_orch073_merge_pr.py
+    expected: PASS
+  - id: TC-09
+    type: unit
+    description: "merge_pr: нет open code-PR → (False, 'no open PR'); никогда не push/force-push main (INV-2)."
+    module: tests/test_orch073_merge_pr.py
+    expected: PASS
+  - id: TC-10
+    type: unit
+    description: "merge_pr идемпотентен: уже-слитый code-PR (SHA в main) → no-op, без второго POST merge (AC-7/INV-4)."
+    module: tests/test_orch073_merge_pr.py
+    expected: PASS
+
+  # ---- FR-4: .gitattributes CHANGELOG.md merge=union ----
+  - id: TC-11
+    type: integration
+    description: ".gitattributes в корне репо содержит 'CHANGELOG.md merge=union'; git check-attr подтверждает driver=union (AC-4)."
+    module: tests/test_orch073_gitattributes.py
+    expected: PASS
+  - id: TC-12
+    type: integration
+    description: "Во временном git-репо два ребейза/слияния с правкой '## [Unreleased]' НЕ дают конфликта; обе записи в CHANGELOG сохранены (AC-4)."
+    module: tests/test_orch073_gitattributes.py
+    expected: PASS
+
+  # ---- FR-5: регресс-гард целостности main + интеграция в _handle_merge_verify ----
+  - id: TC-13
+    type: unit
+    description: "_handle_merge_verify: SHA в main И маркеры на месте → return False (advance к done, happy-path AC-6)."
+    module: tests/test_orch073_regression_guard.py
+    expected: PASS
+  - id: TC-14
+    type: unit
+    description: "_handle_merge_verify: SHA НЕ в main (docs-only merge) → return True (HOLD), alert + set_issue_blocked, НЕ done (AC-3)."
+    module: tests/test_orch073_regression_guard.py
+    expected: PASS
+  - id: TC-15
+    type: unit
+    description: "Регресс-гард: deployed SHA есть, но набор маркеров ранее-merged задач уменьшился → HOLD + alert 'main regressed', НЕ done (AC-5)."
+    module: tests/test_orch073_regression_guard.py
+    expected: PASS
+  - id: TC-16
+    type: unit
+    description: "_handle_merge_verify: внутренняя ошибка верификатора → HOLD + alert, без проброса исключения в advance_stage (never-raise, INV-1)."
+    module: tests/test_orch073_regression_guard.py
+    expected: PASS
+
+  # ---- Условность / обратная совместимость ----
+  - id: TC-17
+    type: unit
+    description: "merge_verify_applies: non-self репо (enduro) или kill-switch off → под-гейт no-op, поведение merge/verify без изменений (AC-6/INV-5)."
+    module: tests/test_orch073_conditionality.py
+    expected: PASS
+  - id: TC-18
+    type: unit
+    description: "Регресс-гард уважает kill-switch (merge_verify_enabled=False) → no-op; для non-self → no-op (INV-5)."
+    module: tests/test_orch073_conditionality.py
+    expected: PASS
+
+  # ---- Регресс существующего поведения ----
+  - id: TC-19
+    type: integration
+    description: "Существующие тесты merge_gate/stage_engine (ORCH-065/071) остаются зелёными; полный pytest tests/ -q green (AC-8)."
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-073/06-adr/ADR-001-merge-verify-sha-truth-and-regression-guard.md

@@ -0,0 +1,214 @@
+# ADR-001 (ORCH-073): SHA-в-main как единственный критерий merge-verify + регресс-гард + `.gitattributes`
+
+- **Статус:** Accepted
+- **Дата:** 2026-06-08
+- **Задача:** ORCH-073 (BUG CRITICAL — эрозия `main`)
+- **Связь:** усиливает/чинит ORCH-071 (merge-verify под-гейт). Сквозной аналог — `docs/architecture/adr/adr-0014-merge-verify-sha-source-of-truth.md` (amends adr-0013).
+- **Источники:** `01-brd.md` (root-cause git-аудит 08.06), `02-trz.md` (FR-1…FR-5), `03-acceptance-criteria.md` (AC-1…AC-11).
+
+## Контекст
+
+Код «задеплоенных» и переведённых в `done` задач **ORCH-067** (`plane_issue_link`, кликабельные
+ссылки, tracker bump) и **ORCH-069** (`qg0_title_max`) физически отсутствовал в `origin/main`,
+хотя обе прошли весь конвейер, Confirm Deploy, merge-verify `CONFIRMED` и стали `done`. В `main`
+попадали только их **docs-коммиты** (staging/deploy-логи через отдельные авто docs-PR), но НЕ
+код feature-веток. Внешнее проявление (нашёл Слава, 08.06): в карточке Telegram сырой номер
+задачи вместо кликабельной ссылки — код ссылок есть в ветке ORCH-067, но не в `main`.
+
+### Root cause (G4 audit) — подтверждён git-аудитом, НЕ гипотеза
+
+1. **`verify_merged_to_main` подтверждает merge по ложному признаку.** Возвращает `True`, если
+   `pr_already_merged(repo, branch)` **ЛИБО** `git merge-base --is-ancestor <sha> origin/main`.
+   OR-ветка `pr_already_merged` — и есть дыра.
+2. **`pr_already_merged` засчитывает ЛЮБОЙ merged PR.** `GET /pulls?state=all&head=<branch>` и
+   `True`, если **хоть один** PR `merged==True`. Параметр `head` у Gitea для одиночной строки-ветки
+   фильтрует ненадёжно → в выборку попадают авто docs-PR (staging/deploy-логи) с других веток
+   (`docs/*`). Сливается docs-PR → `pr_already_merged`=`True` → `verify_merged_to_main`=`True` →
+   merge-verify `CONFIRMED` → `done`, хотя **code-PR НЕ слит**. Ложно-зелёный.
+3. **CHANGELOG-ребейзы — вторичный усилитель.** `auto_rebase_onto_main` при конфликте
+   `CHANGELOG.md` откатывает `deploy-staging → development`; повторный ребейз ветки от старого
+   `main` несёт устаревшие версии соседних файлов, которые при merge тихо затирают код-сосед
+   (фантом-эффект как в ORCH-071, без конфликт-маркеров).
+
+**G1 (восстановление кода) выполнено вручную** restore-PR #76 — `git grep` подтверждает в
+`origin/main` одновременно `plane_issue_link` (8), `qg0_title_max` (3+2), `verify_merged_to_main`
+(4). ORCH-073 фиксирует это в AC-1 и устраняет корень навсегда (FR-1…FR-5).
+
+## Решение
+
+Меняется **семантика merge-verify** (под-гейт ребра `deploy → done`, врезка `_handle_merge_verify`
+в `advance_stage`, введён ORCH-071). `STAGE_TRANSITIONS`, реестр `QG_CHECKS`,
+`check_deploy_status`/`_parse_deploy_status`, merge-gate (`check_branch_mergeable`),
+image-freshness, схема БД (`src/db.py`) — **НЕ меняются**. Внешние HTTP-эндпоинты `src/main.py` —
+**НЕ меняются**.
+
+### Р-1 (FR-1, ядро) — `verify_merged_to_main`: SHA-в-main — единственный критерий
+
+Подтверждение merge — **ТОЛЬКО** прямой факт «deployed commit является предком `origin/main`»:
+
+```
+verify_merged_to_main(repo, branch, sha) -> bool:
+    if not sha:                      # пустой SHA -> неопределённо
+        log warning; return False    # fail-closed (alert + HOLD)
+    git fetch origin main            (timeout merge_verify_timeout_s)
+    rc = git merge-base --is-ancestor <sha> origin/main
+    return rc == 0
+```
+
+- **OR-ветка `pr_already_merged` удаляется** из `verify_merged_to_main`. PR-флаг больше **не
+  подтверждает** merge.
+- Пустой `sha` → `False` (fail-closed: alert + HOLD), как сейчас.
+- never-raise: любая git-ошибка → `False` (INV-1) — фейл-клозед для `done`.
+
+> Дизайн-выбор: вариант (б) из ТЗ §2 FR-2 — единственный источник истины «merged/done» — это
+> SHA-в-main. PR-флаги остаются только как **idempotency-guard** в `merge_pr` (Р-3), не как
+> подтверждение.
+
+### Р-2 (FR-2/G2) — `pr_already_merged`: различает code-PR и docs-PR
+
+`pr_already_merged` понижается до **idempotency-guard для `merge_pr`** (не источник истины для
+`done`). Но guard обязан быть **корректным**: «слит ли именно code-PR ЭТОЙ ветки», иначе merged
+docs-PR заставил бы `merge_pr` ошибочно сделать no-op и пропустить реальный merge кода.
+Поэтому в цикле явный фильтр (НЕ полагаться на ненадёжный query-параметр `head`):
+
+```
+for pr in resp.json():
+    if pr.merged is True
+       and pr.head.ref == branch          # код именно этой feature-ветки
+       and pr.base.ref == "main":         # таргет — main, не docs-база
+        return True
+return False
+```
+
+- Исключает авто docs-PR (другой `head.ref`, напр. `docs/*`) и PR на не-`main` базу.
+- never-raise → `False` (консервативно).
+- Поведение для non-self репо (enduro) не меняется (INV-5) — `merge_pr`/verify для них как раньше.
+
+### Р-3 (FR-3/G2) — `merge_pr`: сливает именно code-ветку
+
+`merge_pr` уже выбирает открытый PR по `head.ref==branch`; добавляется фильтр `base.ref=="main"`
+при выборе PR (защита от слияния PR на чужую базу). Idempotency-guard `pr_already_merged` (Р-2,
+теперь корректный) перед merge оставляем — повторный прогон не делает второй POST. Merge —
+ТОЛЬКО Gitea `POST /pulls/{index}/merge`, никогда push/force-push в `main` (INV-2). После merge
+единственный источник истины «слилось» — FR-1 (SHA-в-main), его проверяет `_handle_merge_verify`.
+
+### Р-4 (FR-5/G5) — регресс-гард целостности `main` (защита навсегда)
+
+Новая детерминированная (no-LLM) функция в `merge_gate.py`, вызывается в `_handle_merge_verify`
+**ПОСЛЕ** подтверждённого SHA-в-main (Р-1) и **ДО** `update_task_stage(done)`:
+
+```
+check_main_regression(repo, branch) -> tuple[bool, str]
+    # ok=True  -> регресса нет (набор маркеров цел) -> пропустить к done
+    # ok=False -> маркер отсутствует -> "main regressed: <task/marker> missing"
+```
+
+**Декларативный набор маркеров** — константа в `merge_gate.py` (append-only, расширяется каждой
+будущей задачей; НЕ БД, НЕ Plane — Не-цель):
+
+```python
+MAIN_REGRESSION_MARKERS = [
+    # (task, marker_substring, path)
+    ("ORCH-067", "plane_issue_link",      "src/notifications.py"),
+    ("ORCH-069", "qg0_title_max",         "src/config.py"),
+    ("ORCH-071", "verify_merged_to_main", "src/merge_gate.py"),
+    ("ORCH-073", "check_main_regression", "src/merge_gate.py"),
+]
+```
+
+Проверка (в worktree после `git fetch origin main`): для каждого маркера
+`git grep -c <marker> origin/main -- <path>`; счётчик `0` → регресс.
+
+- **Реакция при регрессе: ALERT-only + HOLD** (`set_issue_blocked` + Telegram + Plane-коммент
+  «main regressed: code of `<task>` missing»), задача **НЕ `done`**, остаётся на `deploy`. БЕЗ
+  авто-отката на `development` (это инфра-дефект, не код-фолт), симметрично not-merged ветке
+  ORCH-071.
+- **Fail-OPEN на инфра-ошибке грепа** (намеренный trade-off): любая git/OS-ошибка самого грепа →
+  `(True, "guard inconclusive: …")` → НЕ блокировать `done`. Обоснование: первичный фейл-клозед
+  гейт — это SHA-в-main (Р-1); вторичный marker-grep не должен давать ложный HOLD на git-сбое.
+  «Регресс» утверждается только при **детерминированном `count==0`**, не при «не смог определить».
+- never-raise (INV-1). Kill-switch — новый `regression_guard_enabled` (дефолт `true`,
+  переиспользует область self-hosting через `merge_verify_applies`). Non-self репо — no-op (INV-5).
+
+### Р-5 (FR-4/G4 корень) — `.gitattributes` с `merge=union`
+
+В корне репозитория новый файл `.gitattributes`:
+
+```
+CHANGELOG.md merge=union
+```
+
+- `merge=union` — встроенный git-драйвер, доп. конфиг хоста не требуется; проверяется
+  `git check-attr merge CHANGELOG.md` → `merge: union`.
+- Эффект: при `auto_rebase_onto_main` правки `## [Unreleased]` авто-сливаются (обе записи
+  сохраняются) без конфликт-маркера → ветка не откатывается в `development` и не тащит устаревшие
+  версии соседних файлов.
+- **Решено НЕ добавлять `docs/**/*.md merge=union`:** union годится только для строго
+  append-only файлов; docs-артефакты (README, ADR, internals) регулярно **переписываются**
+  построчно — union там тихо задублировал бы строки. Ограничиваемся `CHANGELOG.md`.
+- Оговорка о самозагрузке: задача, ВПЕРВЫЕ вносящая `.gitattributes`, при собственном ребейзе
+  ещё не получает эффект union (атрибут попадёт в `main` только после её merge). Это допустимо —
+  гард действует для всех последующих задач.
+
+## Конфигурация
+
+| Ключ | Дефолт | Назначение |
+|---|---|---|
+| `merge_verify_enabled` (есть) | `true` | kill-switch всего под-гейта |
+| `merge_verify_repos` (есть) | `""` | CSV; пусто → только self-hosting |
+| `merge_pr_timeout_s` / `merge_verify_timeout_s` (есть) | `60` | таймауты Gitea/git |
+| `regression_guard_enabled` (новый) | `true` | kill-switch регресс-гарда (Р-4); non-self → no-op |
+
+Новый ключ задокументировать в `.env.example`. Дефолты безопасны (для non-self — no-op).
+
+## Сигнатуры (внутренние; внешний API не меняется)
+
+- `verify_merged_to_main(repo, branch, sha) -> bool` — семантика меняется (Р-1), сигнатура та же.
+- `pr_already_merged(repo, branch) -> bool` — назначение/фильтр уточняются (Р-2), сигнатура та же.
+- `merge_pr(repo, branch) -> tuple[bool, str]` — фильтр `base==main` (Р-3), сигнатура та же.
+- `check_main_regression(repo, branch) -> tuple[bool, str]` — **новая**, never-raise, fail-open.
+- `merge_verify_status()` — допустимо дополнить счётчиком регресс-алертов (read-only, не источник истины).
+
+## Инварианты
+
+- **INV-1** never-raise: ошибка верификации → alert/HOLD, не падение конвейера.
+- **INV-2** self-hosting safety: прод 8500 не падает/не рестартится в рамках merge; merge только
+  Gitea PR-API, без force-push в `main`.
+- **INV-3** ручной `Confirm Deploy` (ORCH-059) сохранён.
+- **INV-4** идемпотентность опирается на «SHA-в-main», а не на «любой merged PR».
+- **INV-5** обратная совместимость non-self (enduro): merge/verify/регресс-гард — no-op.
+
+## Альтернативы (отклонены)
+
+1. **Оставить `pr_already_merged` как со-критерий verify, но фильтровать по `head/base`** —
+   отклонено: PR-флаг всё равно слабее факта «SHA в main» (PR можно слить и тут же откатить
+   ребейзом-соседом). Единственный надёжный критерий — предок-`main`. PR-флаг → только idempotency.
+2. **`docs/**/*.md merge=union`** — отклонено (см. Р-5): тихая дубликация строк в переписываемых
+   доках.
+3. **Регресс-гард с авто-откатом на `development`** — отклонено: регресс соседнего кода —
+   инфра-дефект merge, не код-фолт текущей задачи; реакция ALERT-only + HOLD (как ORCH-021/071).
+4. **Хранить набор маркеров в БД/Plane** — отклонено (Не-цель «не менять схему БД/Plane»);
+   декларативная append-only константа в коде проще и версионируется вместе с фиксом.
+5. **Fail-closed на marker-grep** — отклонено: дало бы ложный HOLD при git-сбое; первичный
+   фейл-клозед — SHA-в-main (Р-1), marker-grep вторичен → fail-open.
+
+## Последствия
+
+- **Плюс:** невозможно «`done` + прод задеплоен, а code-PR не в `main`» — единственный критерий
+  `done` теперь «SHA-в-main». Ложно-зелёный по docs-PR устранён в корне (Р-1+Р-2+Р-3).
+- **Плюс:** CHANGELOG-конфликты больше не откатывают ветку и не тащат устаревший код-сосед (Р-5).
+- **Плюс:** регресс-гард ловит откат соседнего кода даже если SHA-в-main прошёл (Р-4).
+- **Минус:** при недоступной Gitea/git verify консервативно `False` → возможен ложный HOLD+alert
+  (снимается повтором; fail-closed для `done` приоритетен). Регресс-гард при git-сбое наоборот
+  fail-open (не блокирует) — осознанный trade-off, SHA-в-main остаётся первичным гейтом.
+- **Минус:** набор маркеров требует дисциплины — каждая значимая задача дописывает свой маркер
+  (иначе гард его не защитит). Документируется в `CLAUDE.md`/README.
+
+## Связи
+
+- Amends: `docs/architecture/adr/adr-0013-merge-verify-gate.md` (ORCH-071) — меняет критерий verify.
+- Сквозной: `docs/architecture/adr/adr-0014-merge-verify-sha-source-of-truth.md`.
+- Постмортем: `docs/history/LESSONS_2026-06-08_phantom-merge.md`, runbook
+  `docs/operations/PHANTOM_MERGE_RUNBOOK.md`.
+- AC: AC-1 (G1 markers), AC-2/AC-3 (Р-1/Р-2), AC-4 (Р-5), AC-5 (Р-4), AC-6 (happy-path),
+  AC-7 (idempotency), AC-8/AC-9 (docs+audit), AC-10 (staging), AC-11 (self-hosting safety).

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

@@ -0,0 +1,32 @@
+# 07 — Инфра-требования: ORCH-073
+
+## Топология
+**Без изменений.** Один сервер (mva154), prod `orchestrator` (8500), staging
+`orchestrator-staging` (8501), общая SQLite, общая очередь. Новых контейнеров/портов/сервисов нет.
+
+## Git / worktree
+- Новый корневой файл **`.gitattributes`** (`CHANGELOG.md merge=union`). Драйвер `union` —
+  встроенный в git, **доп. конфигурация хоста НЕ требуется**.
+- Проверка применения в worktree агентов: `git check-attr merge CHANGELOG.md` → `merge: union`.
+  Атрибут действует при 3-way merge/rebase, когда `.gitattributes` присутствует в дереве
+  (`auto_rebase_onto_main` выполняет `git rebase origin/main` в per-branch worktree).
+- Самозагрузка: первая задача с `.gitattributes` своего ребейза не ускоряет (атрибут попадёт в
+  `main` после её merge); эффект — для последующих задач. Допустимо.
+- Регресс-гард (`check_main_regression`) использует уже существующий per-branch worktree
+  (`ensure_worktree` + `git fetch origin main` + `git grep origin/main`). Новых клонов/worktree нет.
+
+## Сеть / внешние интеграции
+- Те же Gitea-эндпоинты: `GET /pulls`, `POST /pulls/{index}/merge`. Новых внешних вызовов нет.
+- Telegram/Plane — существующие хелперы alert (`send_telegram`, `set_issue_blocked`,
+  `plane_add_comment`). Новых интеграций нет.
+
+## Деплой self (self-hosting safety)
+- Прод-контейнер `orchestrator` (8500) **НЕ рестартить/не ронять** в рамках задачи.
+- Обязательный staging-гейт (8501) перед прод-деплоем; прод-деплой — только переводом на
+  `Confirm Deploy` (ORCH-059). Ручной гейт не меняется.
+- Merge — только Gitea PR-API, без force-push в `main`.
+
+## Конфигурация (хост `.env` / `.env.example`)
+- Новый ключ `regression_guard_enabled` (дефолт `true`) — задокументировать в `.env.example`.
+- Существующие `merge_verify_enabled`/`merge_verify_repos`/`merge_pr_timeout_s`/
+  `merge_verify_timeout_s` — переиспользуются, без изменений значений.

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

@@ -0,0 +1,23 @@
+# 08 — Требования к данным/схеме БД: ORCH-073
+
+## Схема БД
+**Без изменений.** `src/db.py` не трогается (Не-цель BRD §5, ТЗ §4). Новых таблиц/колонок/
+миграций нет.
+
+## Источник истины merge-verify
+- Подтверждение `done` опирается **только на git** (`origin/main`: `git merge-base
+  --is-ancestor <sha> origin/main`), НЕ на состояние БД и НЕ на Plane-статусы.
+- Регресс-гард (`check_main_regression`) опирается на `git grep origin/main` по декларативному
+  набору маркеров — **не на БД**.
+- Набор маркеров `MAIN_REGRESSION_MARKERS` — **append-only константа в коде** (`src/merge_gate.py`),
+  версионируется вместе с фиксом. Сознательно НЕ в БД и НЕ в Plane (Не-цель).
+
+## Состояние в БД (читается, не меняется)
+- `tasks.stage` — переходы через существующий `update_task_stage`/`advance_stage`; HOLD = задача
+  остаётся на `deploy` (не записывается `done`). Семантика та же, что у ORCH-071.
+- Счётчики `_MERGE_VERIFY_COUNTERS` — **in-process**, не БД; read-only через `GET /queue`.
+  Допустимо дополнить счётчиком регресс-алертов (наблюдаемость, не источник истины).
+
+## Plane
+**Без изменений** (Не-цель). Используются существующие сеттеры (`set_issue_blocked`,
+`plane_add_comment`) для alert/HOLD. Новых статусов/маппингов нет.

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

@@ -0,0 +1,19 @@
+# 10 — Технические риски: ORCH-073
+
+| # | Риск | Вероятность | Влияние | Митигация |
+|---|------|-------------|---------|-----------|
+| R-1 | **Ложный HOLD на сбое Gitea/git** — verify консервативно `False` при недоступности → задача не доходит до `done`, нужен повтор. | средняя | среднее | Осознанный fail-closed для `done` (приоритет: не дать ложно-зелёный). Снимается re-drive (reaper/reconciler/re-approve). Документировано в ADR «Последствия». |
+| R-2 | **`pr_already_merged` всё ещё ловит docs-PR** при иной структуре head/base в Gitea (cross-repo `owner:branch`). | низкая | высокое (возврат бага) | Явный фильтр в цикле `head.ref==branch И base.ref=="main"` (не полагаться на query-param). Тест AC-2/AC-3 мокает merged docs-PR и проверяет, что verify=`False`. |
+| R-3 | **Регресс-гард fail-open пропустит реальный регресс** во время git-сбоя грепа. | низкая | среднее | Первичный гейт `done` — SHA-в-main (fail-closed). Marker-grep вторичен; «регресс» — только при детерминированном `count==0`. Trade-off зафиксирован в ADR. |
+| R-4 | **Набор маркеров устаревает/неполный** — будущая задача не добавила свой маркер → гард её не защищает. | средняя | среднее | Append-only константа в коде + правило в `CLAUDE.md`/README «значимая задача дописывает маркер». Reviewer проверяет. Не регресс существующего поведения (только недозащита нового). |
+| R-5 | **`merge=union` тихо дублирует строки** при применении к не-append-only файлам. | низкая | среднее | Union строго ограничен `CHANGELOG.md`; `docs/**` под union НЕ ставится (решение Р-5 ADR). |
+| R-6 | **Самозагрузка `.gitattributes`** — первая задача не получает эффект union на своём ребейзе. | высокая (одноразово) | низкое | Принято: атрибут попадёт в `main` после merge ORCH-073, действует для последующих задач. Для самой ORCH-073 CHANGELOG-конфликт разрешается вручную при необходимости. |
+| R-7 | **Ложный «main regressed» при легитимном рефакторе**, переименовавшем маркер-функцию. | низкая | среднее | Маркеры выбираются как стабильные публичные имена; при намеренном переименовании задача обновляет `MAIN_REGRESSION_MARKERS` в том же PR (правило документации). |
+| R-8 | **Регресс на non-self репо (enduro)** из-за нового кода. | низкая | высокое | Вся врезка под `merge_verify_applies` (kill-switch + self-hosting scope); регресс-гард — отдельный `regression_guard_enabled`; non-self → no-op (INV-5). Тест AC-6 (enduro no-op). |
+| R-9 | **Self-hosting: рестарт/падение прода** при ошибке в merge_gate. | низкая | высокое (групповой риск) | never-raise контракт (INV-1); merge только PR-API без force-push; staging-гейт обязателен; прод не рестартится в рамках merge. Тест AC-11. |
+
+## Сводный вывод
+Изменения локализованы в `src/merge_gate.py` + врезка в `_handle_merge_verify`
+(`src/stage_engine.py`) + новый ключ конфигурации + корневой `.gitattributes`. Схема БД, Plane,
+внешние HTTP-эндпоинты, реестр QG, `STAGE_TRANSITIONS` — не затронуты. Главный остаточный риск —
+ложный HOLD на инфра-сбое (R-1), сознательно принят ради устранения ложно-зелёного merge-verify.

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

@@ -0,0 +1,75 @@
+---
+type: review
+work_item_id: ORCH-073
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-073
+
+## Summary
+Системный фикс эрозии `main` (фантомный merge ORCH-067/069) реализован строго по
+ТЗ (FR-1…FR-5) и ADR-001. Все 11 критериев приёмки выполнены, документация обновлена
+в том же PR, `pytest tests/ -q` → **941 passed**. Self-hosting-инварианты соблюдены
+(merge только через Gitea PR-API, без force-push в `main`; non-self репо — no-op).
+Блокирующих и must-fix замечаний нет.
+
+## Проверка по осям
+
+### 1. Соответствие ТЗ (02-trz.md)
+- **FR-1** — `verify_merged_to_main` подтверждает merge ТОЛЬКО `git merge-base --is-ancestor <sha> origin/main`; OR-ветка `pr_already_merged` удалена; пустой SHA / git-ошибка → `False` (fail-closed, never-raise). ✓
+- **FR-2** — `pr_already_merged` понижен до idempotency-guard, явный in-loop фильтр `merged & head.ref==branch & base.ref=="main"` (не ненадёжный query `head`). ✓
+- **FR-3** — `merge_pr` выбирает open PR по `head.ref==branch` И `base.ref=="main"`; merge только `POST /pulls/{n}/merge`. ✓
+- **FR-4** — корневой `.gitattributes` с `CHANGELOG.md merge=union`; `docs/**` намеренно НЕ включён. ✓
+- **FR-5** — `check_main_regression` (детерминированный, no-LLM) + декларативный append-only `MAIN_REGRESSION_MARKERS`; вызов в `_handle_merge_verify` ПОСЛЕ SHA-в-main и ДО `done`; ALERT-only + HOLD; fail-open на git-ошибке грепа; kill-switch `regression_guard_enabled`. ✓
+
+### 2. Соответствие ADR (06-adr/ADR-001 + adr-0014)
+Реализация 1:1 соответствует Р-1…Р-5. G4-аудит и root-cause зафиксированы в ADR
+(раздел «Root cause (G4 audit)»). Сквозной ADR-0014 заведён, `adr/README.md` обновлён,
+`adr-0013` помечен как amended. Нарушений глобальных ADR не обнаружено.
+**AC-1 подтверждён в `origin/main`:** `plane_issue_link`(8), `qg0_title_max`(config.py 3),
+`verify_merged_to_main`(4). **AC-4 подтверждён:** `git check-attr merge CHANGELOG.md → merge: union`.
+
+### 3. Качество кода
+- Строгий never-raise на всех публичных функциях merge_gate; INV-1…INV-5 соблюдены.
+- Docstrings содержательные, со ссылками на FR/AC/INV; обоснован осознанный trade-off
+  fail-open для marker-grep против fail-closed SHA-в-main.
+- `_hold_main_regressed` симметричен not-merged-HOLD; уведомления Plane/Telegram best-effort,
+  не ломают HOLD.
+- Схема БД, реестр `QG_CHECKS`, `STAGE_TRANSITIONS`, внешние HTTP-эндпоинты — не тронуты (как и заявлено).
+
+### 4. Качество тестов
+18 тест-кейсов (TC-01…18) в 6 файлах `tests/test_orch073_*.py`, не тривиальные:
+- TC-02 воспроизводит исходный баг (merged docs-PR не подтверждает merge), проверяет, что
+  PR-флаг verify-ом более не запрашивается.
+- TC-14/15 различают HOLD по «not-merged» и по «main-regressed».
+- TC-10 — идемпотентность (нет второго POST merge). TC-17/18 — conditionality/kill-switch.
+- TC-12 в throwaway-репо реально проверяет union-merge без конфликта.
+
+## Findings
+
+### P0 — Blocker
+- нет
+
+### P1 — Must fix
+- нет
+
+### P2 — Should fix
+- нет
+
+### P3 — Nice-to-have
+- Маркер `("ORCH-073", "check_main_regression", "src/merge_gate.py")` самозагрузочный
+  (попадёт в `origin/main` только после merge этой задачи) — поведение корректное и
+  оговорено в ADR (self-bootstrap), замечание чисто информационное.
+
+## Документация
+Полностью обновлена в этом же PR (правило агентов §2/§6, AC-8):
+- `docs/architecture/README.md` — раздел merge-verify переписан под FR-1 + добавлены регресс-гард (FR-5) и `.gitattributes` (FR-4).
+- `CHANGELOG.md` — запись в `## [Unreleased]`.
+- `docs/work-items/ORCH-073/06-adr/ADR-001-*.md` — новый ADR с G4-аудитом; `docs/architecture/adr/adr-0014-*.md` — сквозной ADR; `adr/README.md` обновлён.
+- `.env.example` — задокументирован новый ключ `ORCH_REGRESSION_GUARD_ENABLED` + блок merge-verify.
+
+Требование «изменён `src/` → обновлена документация» выполнено. Блокеров по документации нет.
+
+## Вердикт
+**APPROVED** — нет P0/P1; код, тесты и документация соответствуют ТЗ/ADR; self-hosting-страховки сохранены.

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

@@ -0,0 +1,83 @@
+---
+type: test-report
+work_item_id: ORCH-073
+result: PASS
+---
+
+# Test Report — ORCH-073
+
+CRIT: системный фикс эрозии `main` (фантомный merge ORCH-067/069) + восстановление кода.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Дата: 2026-06-08
+- Worktree: `feature/ORCH-073-crit-main-orch-067-069`
+- Prod health (8500): `{"status":"ok","service":"orchestrator"}` — контейнер не тронут
+
+## Smoke-тесты API (prod 8500, read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok"}` — PASS |
+| `GET /status` | active_tasks отдаётся, ORCH-073 на стадии `testing` — PASS |
+| `GET /queue` | counts/reconcile/reaper/post_deploy снимок отдаётся, breaker `closed` — PASS |
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+| TC ID | Описание | Тест-функция | Результат |
+|-------|----------|--------------|-----------|
+| TC-01 | verify_merged_to_main: sha — предок main → True (AC-6) | test_tc01_true_when_sha_is_ancestor | PASS |
+| TC-02 | sha НЕ в main + merged docs-PR → False (баг 067/069, AC-2) | test_tc02_false_when_sha_not_in_main_even_with_merged_docs_pr | PASS |
+| TC-03 | пустой sha → False (fail-closed) | test_tc03_empty_sha_is_false | PASS |
+| TC-04 | git error → False (never-raise, INV-1) | test_tc04_never_raises_on_git_error / _worktree_error | PASS |
+| TC-05 | merged docs-PR не засчитан как code-merge (FR-2) | test_tc05_merged_docs_pr_not_counted | PASS |
+| TC-06 | merged code-PR распознан (base=main, head=branch) | test_tc06_merged_code_pr_recognised / _onto_non_main_base_not_counted | PASS |
+| TC-07 | HTTP-ошибка/не-200 → False (never-raise) | test_tc07_non_200_is_false / _http_exception_is_false | PASS |
+| TC-08 | merge_pr выбирает code-PR, не docs/* (FR-3) | test_tc08_merges_code_pr_not_docs_pr / _skips_pr_onto_non_main_base | PASS |
+| TC-09 | нет open code-PR → (False,...), без push main (INV-2) | test_tc09_no_open_pr_no_shell_out | PASS |
+| TC-10 | merge_pr идемпотентен, без второго POST (AC-7/INV-4) | test_tc10_idempotent_already_merged | PASS |
+| TC-11 | .gitattributes: CHANGELOG.md merge=union (AC-4) | test_tc11_gitattributes_declares_union | PASS |
+| TC-12 | union-merge сохраняет обе записи Unreleased без конфликта | test_tc12_union_merge_keeps_both_entries | PASS |
+| TC-13 | _handle_merge_verify: SHA в main + маркеры → advance (AC-6) | test_tc13_confirmed_and_intact_advances | PASS |
+| TC-14 | docs-only merge → HOLD + alert, НЕ done (AC-3) | test_tc14_sha_not_in_main_holds | PASS |
+| TC-15 | регресс-гард: маркер ранее-merged задачи пропал → HOLD + alert (AC-5) | test_tc15_marker_missing_holds | PASS |
+| TC-16 | внутр. ошибка верификатора → HOLD + alert, never-raise (INV-1) | test_tc16_internal_error_holds_never_raises | PASS |
+| TC-17 | conditionality: non-self/kill-switch → под-гейт no-op (AC-6/INV-5) | test_tc17_merge_verify_applies_scope / _under_gate_noop_for_non_self | PASS |
+| TC-18 | регресс-гард уважает kill-switch / non-self → no-op (INV-5) | test_tc18_guard_kill_switch_skips_guard / _guard_noop_for_non_self_repo | PASS |
+| TC-19 | полный pytest tests/ -q зелёный (AC-8) | весь набор tests/ | PASS |
+
+Все 19 TC из тест-плана покрыты (24 тест-функции в 6 файлах `tests/test_orch073_*.py`).
+
+## Проверка критериев приёмки (03-acceptance-criteria.md)
+
+| AC | Проверка | Результат |
+|----|----------|-----------|
+| AC-1 | Маркеры в origin/main: plane_issue_link=8, qg0_title_max=3, verify_merged_to_main=4 (все >0) | PASS |
+| AC-2 | TC-02: sha не в main + merged docs-PR → False | PASS |
+| AC-3 | TC-14: docs-only merge → HOLD + alert, НЕ done | PASS |
+| AC-4 | `git check-attr merge CHANGELOG.md` → `merge: union`; TC-11/12 | PASS |
+| AC-5 | TC-15: уменьшение набора маркеров → HOLD + alert «main regressed» | PASS |
+| AC-6 | TC-01/13/17: happy-path done без ложного alert; enduro no-op | PASS |
+| AC-7 | TC-10: re-drive слитой задачи → no-op, без второго merge | PASS |
+| AC-8 | 941 passed; доки/ADR/CHANGELOG обновлены (см. 12-review) | PASS |
+| AC-9 | G4-аудит в ADR-001 (root cause docs-only merge) — подтверждён reviewer | PASS |
+| AC-10 | staging-проверка — стадия deploy-staging (вне scope tester) | — |
+| AC-11 | merge только PR-API; прод-контейнер не падал в рамках тестов | PASS |
+
+## Вывод pytest
+
+```
+tests/ -q --tb=short:
+........................................................................ [100%]
+941 passed, 1 warning in 25.37s
+
+tests/test_orch073_*.py -v:
+24 passed, 1 warning in 0.54s
+```
+(1 warning — PydanticDeprecatedSince20 в src/config.py, не относится к ORCH-073, не блокирует.)
+
+## Итог
+**PASS** — полный регресс зелёный (941 passed), все 24 теста ORCH-073 PASS, smoke API OK,
+маркеры AC-1 присутствуют в `origin/main`, прод-контейнер не затронут. Задача готова к
+переходу на стадию `deploy-staging` (где будет проверен AC-10 — воспроизведение «исправлено
+навсегда» на двух задачах с правкой CHANGELOG).

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

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

@@ -0,0 +1,36 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T13:29:31Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed. All REAL pipeline checks passed (8/10).
+
+Run canonically inside the `orchestrator-staging` container (ORCH-048, ADR-001):
+
+```
+docker exec orchestrator-staging \
+  python3 /repos/orchestrator/scripts/staging_check.py \
+  --base-url http://localhost:8501 --mode stub
+```
+
+Exit code: **0** → advance.
+
+## Results
+
+- **Block A (SMOKE)**: A1 /health, A2 /queue, A3 ORCH_STAGING=true — all PASS
+- **Block B (ACCESS)**: B4 Plane sandbox, B5 Gitea sandbox (push=true), B6 registry isolation (sandbox present, prod ET/ORCH absent) — all PASS
+- **Block C (E2E, stub)**: C7 create issue, C8 trigger pipeline — PASS; C9a/C9b — waived sandbox-infra
+
+REAL failed: none.
+
+## Infra waiver (ORCH-061)
+
+```
+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
+```
+
+The two waived checks (C9a branch, C9b analyst-job) depend on SANDBOX bot accounts being members of the sandbox Plane project — infra-only, not pipeline regression. Tolerated under `staging_infra_tolerance_enabled=true` since every REAL check is green. Exit code remains the source of truth (fail-closed: any REAL failure still yields exit 1).

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-52a: фикс модели/эффорта агентов (мёртвый frontmatter → routing+effort)
+
+Work Item ID: ORCH-074
+
+## Description
+
+TBD

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

@@ -0,0 +1,89 @@
+# BRD — ORCH-074: фикс модели агентов (мёртвый frontmatter → валидация имени)
+
+Work Item ID: ORCH-074
+Эпик: ORCH-052 (слой 3), под-задача ORCH-52a
+Приоритет: **urgent**
+Тип: доработка механизма выбора модели агентов (self-modifying).
+
+## 0. История ревизий
+
+- **rev.1 (08.06):** первичный пакет аналитики по фиксированному скоупу Славы.
+- **rev.2 (08.06, текущая):** задача возвращена стейкхолдером в In Progress.
+  Проверены последние комментарии и описание issue в Plane — НОВЫХ субстантивных
+  ответов/изменений скоупа нет (только bot-комменты + служебный маркер
+  «Агент перезапущен с ответами стейкхолдера»). Скоуп остаётся прежним
+  (G1 + G2 + опц. G4; G3 снят; эффорт не трогаем). Пакет переподтверждён против
+  фактического кода (`launcher.py`, `config.py`); уточнён код-факт по G4: fallback
+  читается напрямую на `launcher.py:374` мимо `resolve_agent_model`, поэтому
+  валидация G2 должна покрыть и fallback (детали — ТЗ §4, AC-5, TC-11).
+
+## 1. Контекст и проблема
+
+Каркас выбора модели агентов реализован в ORCH-041 и **работает корректно**:
+`src/agents/launcher.py::resolve_agent_model(agent, project_id)` резолвит модель
+по приоритету project-override → `ORCH_AGENT_MODEL_<AGENT>` → `agent_model_default`
+→ CLI-дефолт. Все 6 агентов сейчас резолвятся в `claude-opus-4-8` (через
+`agent_model_default`).
+
+Аудит кода (08.06) выявил два дефекта данных/валидации (НЕ дефект механизма):
+
+- **P1. Лживый/мёртвый `model:` во frontmatter `.openclaw/agents/*.md`.**
+  Все 6 промптов содержат `model:` в YAML-frontmatter:
+  `claude-sonnet-4-6` (analyst, developer, tester, deployer) и
+  `claude-opus-4-7` (architect, reviewer). launcher **НЕ читает** frontmatter
+  `model:` — это мёртвая декларация, которая лжёт о реально используемой модели
+  и нарушает принцип «документация = golden source». Мина: если кто-то «починит»
+  launcher читать frontmatter → все агенты молча упадут на устаревшие модели.
+
+- **P2. Нет валидации ИМЕНИ модели.** В отличие от effort (есть `VALID_EFFORTS`-гард,
+  невалидный effort логируется и дропается), имя модели не валидируется. Опечатка
+  в `agent_model_*` / project-override → `--model <мусор>` → CLI падает или тихо
+  деградирует. Нарушение принципа never-break.
+
+## 2. Решение Славы (08.06) — фиксированный скоп
+
+> G3 model-routing **НЕ включаем** — ВСЕ 6 агентов остаются на `claude-opus-4-8`.
+> Скоп: **G1** (убрать лживый `model:` из frontmatter) + **G2** (валидация имени
+> модели, never-break) + **опц. G4** (`fallback_model` — на усмотрение архитектора,
+> НЕ routing). **Эффорт НЕ трогать.** AC-4 (routing) снят.
+
+## 3. Бизнес-цели
+
+| ID | Цель | Драйвер |
+|----|------|---------|
+| G1 | Устранить лживый frontmatter: убрать `model:` из всех 6 `.openclaw/agents/*.md`. config — единственный источник правды модели. | Наблюдаемость (frontmatter не лжёт) |
+| G2 | Добавить валидацию имени модели: невалидное имя → лог + откат на default, никогда не передаётся в `--model`. | Надёжность (never-break) |
+| G4 | (опц., решает архитектор) Задать `agent_fallback_model` для страховки доступности. | Надёжность (availability) |
+
+## 4. Не-цели (явно вне скоупа)
+
+- **G3 routing НЕ включаем.** Все 6 агентов остаются `claude-opus-4-8`. AC-4 снят.
+- **Эффорт НЕ трогать** — уже корректно настроен (`thinking → high`, `tester/deployer → medium`).
+- **Не менять resolve-механизм ORCH-041** — он корректен. Меняются только данные
+  (frontmatter, опц. config) + добавляется валидация.
+- **Не трогать non-self поведение** — per-project override (`projects.py agent_models`)
+  для enduro-trails остаётся рабочим.
+
+## 5. Заинтересованные стороны
+
+- **Owner (Слава)** — зафиксировал скоп; деплой через штатный «Confirm Deploy».
+- **Агенты оркестратора** — потребители resolve-механизма (self-hosting).
+- **Проект enduro-trails** — НЕ должен пострадать (общий инстанс/БД/очередь).
+
+## 6. Риски и инварианты
+
+- **Self-hosting:** изменение применяется к БУДУЩИМ запускам агентов. НЕ ломать
+  текущий конвейер; не ронять прод-контейнер. Деплой только через «Confirm Deploy».
+- **never-break:** невалидная модель/эффорт НЕ должны ронять запуск агента —
+  деградация на default/CLI-дефолт + лог.
+- **frontmatter автогенерация:** убедиться, что инструмент (если автогенерит
+  frontmatter) не вернёт `model:` обратно. Frontmatter остаётся описательным
+  (`name`/`description`/`tools`).
+- **enduro per-project override** не должен сломаться валидацией (валидные имена
+  проходят без изменения поведения).
+
+## 7. Бизнес-эффект
+
+- Frontmatter перестаёт лгать → меньше риск «починки», ломающей агентов.
+- Опечатка в имени модели больше не роняет/деградирует запуск агента.
+- (опц.) fallback повышает доступность при перегрузке основной модели.

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

@@ -0,0 +1,112 @@
+# ТЗ — ORCH-074: убрать мёртвый frontmatter `model:` + валидация имени модели
+
+Work Item ID: ORCH-074
+Базируется на: BRD `01-brd.md`. Скоп фиксирован решением Славы (08.06):
+**G1 + G2 + опц. G4. G3 (routing) НЕ включаем. Эффорт НЕ трогать.**
+
+## 1. Задействованные модули `src/` и файлы
+
+| Файл | Изменение |
+|------|-----------|
+| `.openclaw/agents/analyst.md` | **G1:** удалить строку `model: claude-sonnet-4-6` из frontmatter |
+| `.openclaw/agents/architect.md` | **G1:** удалить строку `model: claude-opus-4-7` |
+| `.openclaw/agents/developer.md` | **G1:** удалить строку `model: claude-sonnet-4-6` |
+| `.openclaw/agents/reviewer.md` | **G1:** удалить строку `model: claude-opus-4-7` |
+| `.openclaw/agents/tester.md` | **G1:** удалить строку `model: claude-sonnet-4-6` |
+| `.openclaw/agents/deployer.md` | **G1:** удалить строку `model: claude-sonnet-4-6` |
+| `src/agents/launcher.py` | **G2:** добавить валидацию имени модели в `resolve_agent_model` (или helper), по образцу `VALID_EFFORTS`-гарда в `resolve_agent_effort` |
+| `src/config.py` | **G4 (опц.):** задать `agent_fallback_model` (если архитектор решит). При G2 — возможно добавить константу/настройку валидного формата модели |
+| `docs/architecture/README.md` | **AC-6:** таблица «модель/эффорт по ролям» актуализирована; нет упоминаний sonnet/opus-4-7 как «модели агента» |
+| `.env.example` | **AC-3/AC-6:** добавить блок `ORCH_AGENT_MODEL_*` / `ORCH_AGENT_EFFORT_*` / `ORCH_AGENT_FALLBACK_MODEL` (сейчас в `.env.example` их НЕТ) |
+| `CLAUDE.md` | **AC-6:** при необходимости — отметить, что модель агента берётся ТОЛЬКО из config (frontmatter описательный) |
+| `CHANGELOG.md` | запись о доработке |
+| `tests/test_resolve_agent_model.py` | **AC-2:** добавить кейсы валидации мусорного имени |
+
+## 2. G1 — убрать мёртвый frontmatter `model:`
+
+Удалить **только** строку `model: …` из YAML-frontmatter каждого из 6 файлов
+`.openclaw/agents/*.md`. Остальные ключи (`name`, `description`, `tools`/`model`-comment)
+не трогать. frontmatter остаётся валидным YAML и описательным.
+
+Проверка (AC-1):
+```
+grep -L "^model:" .openclaw/agents/*.md   # должны вернуться ВСЕ 6 файлов
+```
+(`grep -L` печатает файлы БЕЗ совпадения — все 6 не должны содержать `^model:`.)
+
+## 3. G2 — валидация имени модели (never-break)
+
+Требование (НЕ предписывает архитектуру — выбор предиката за архитектором):
+
+- Резолвенное имя модели валидируется ПЕРЕД возвратом из `resolve_agent_model`
+  (либо в общем helper). Невалидное имя → `logger.warning(...)` + откат на
+  следующий валидный уровень (в пределе — `agent_model_default`, а если и он
+  невалиден → `""`, т.е. без флага `--model`, CLI-дефолт). **Никогда** не вернуть
+  мусор, который попадёт в `--model`.
+- Поведение — точная аналогия `resolve_agent_effort` (`VALID_EFFORTS`): валидный →
+  как есть; невалидный → лог + дроп.
+- Предикат валидности (на усмотрение архитектора, рекомендация аналитика):
+  формат-чек `claude-*` (forward-compatible — новые версии моделей не требуют
+  правки allowlist) ЛИБО явный `VALID_MODELS` allowlist (строже, но требует
+  поддержки при выходе новых моделей). **Выбор и обоснование — в ADR.**
+- **Рекомендация аналитика (форма):** оформить предикат как отдельный
+  чистый helper (напр. `is_valid_model(name) -> bool` рядом с `VALID_EFFORTS`),
+  а не инлайнить в `resolve_agent_model` — тогда ОДИН валидатор переиспользуется
+  и резолвом модели, и чтением fallback (G4, см. §4). Финальная форма — за
+  архитектором.
+- Инвариант обратной совместимости: ВСЕ ныне используемые валидные имена
+  (`claude-opus-4-8`, а также enduro per-project override) проходят валидацию
+  без изменения поведения. Невалидным считается только мусор (опечатка,
+  `gpt-4`, пустая строка после strip и т.п.).
+- Контракт уровней резолва ORCH-041 сохраняется: валидация добавляется поверх,
+  механизм приоритетов не меняется.
+
+## 4. G4 — fallback_model (опционально, решает архитектор)
+
+- `src/config.py::agent_fallback_model` сейчас `""` (флаг не прокидывается).
+- Если архитектор решит включить — задать каноничное имя модели; launcher уже
+  прокидывает его в `--fallback-model` (`launcher.py:374-375`, попадает в cmd
+  на строке 388).
+- **⚠️ Код-факт (проверено 08.06):** fallback читается НАПРЯМУЮ —
+  `fb = settings.agent_fallback_model` (`launcher.py:374`) — и **НЕ проходит**
+  через `resolve_agent_model`, значит валидация G2, добавленная внутри
+  `resolve_agent_model`, его НЕ покроет. Следствие для архитектора: если G4
+  включается, валидацию имени модели (G2) надо применить ТАКЖЕ к fallback на
+  его месте чтения (или вынести валидатор в отдельный helper, который вызывают
+  ОБА: и резолв модели, и чтение fallback). Иначе опечатка в `agent_fallback_model`
+  обходит G2 и уезжает в `--fallback-model` — нарушение never-break.
+- Если архитектор решит НЕ включать — оставить `""`, AC-5 помечается N/A в ADR.
+
+## 5. Изменения API / схемы БД
+
+- **API (HTTP):** нет.
+- **Схема БД:** нет миграций.
+- **CLI-команда агента:** формируется в `launcher._spawn` (строки 384-392).
+  Меняется только КАЧЕСТВО значения `--model` (валидное/дроп), сама структура
+  команды не меняется.
+
+## 6. Требования к QG checks
+
+- Новых QG-чеков НЕ требуется. Валидация — это runtime-гард в launcher, не
+  отдельный quality-gate.
+
+## 7. Артефакты pipeline
+
+Должны быть созданы/обновлены в ЭТОМ PR (golden source = код + доки):
+- `docs/architecture/README.md` — таблица «модель/эффорт по ролям».
+- `.env.example` — блок переменных моделей/эффорта/fallback.
+- `CHANGELOG.md` — запись.
+- `06-adr/ADR-NNN-*.md` — решение по предикату валидации (G2) и по G4 (fallback вкл/выкл).
+- ADR архитектора фиксирует: выбран вариант G1 «убрать» (не «читать frontmatter»).
+
+## 8. Эффорт — НЕ ТРОГАТЬ
+
+`agent_effort_*` корректны (`thinking → high`, `tester/deployer → medium`).
+Менять только при явном отдельном обосновании (вне скоупа этой задачи).
+
+## 9. Грабли
+
+- Имена моделей — каноничные строки Claude CLI; сверить с тем, что реально
+  принимает CLI на проде (`ORCH_CLAUDE_BIN`). НЕ хардкодить версию вне `config.py`.
+- Если frontmatter автогенерится инструментом — убедиться, что `model:` не вернётся.
+- Self-hosting: НЕ ронять прод-контейнер; деплой через «Confirm Deploy».

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

@@ -0,0 +1,81 @@
+# Критерии приёмки — ORCH-074
+
+Work Item ID: ORCH-074
+Скоп (Слава 08.06): G1 + G2 + опц. G4. **G3 routing снят — AC-4 не применяется.**
+
+Каждый критерий: чёткое условие PASS/FAIL.
+
+---
+
+## AC-1 — frontmatter `model:` убран из всех 6 промптов (G1)
+
+- **PASS:** ни один файл `.openclaw/agents/*.md` не содержит строки `^model:` в
+  frontmatter. Команда `grep -L "^model:" .openclaw/agents/*.md` возвращает все 6
+  файлов (analyst, architect, developer, reviewer, tester, deployer).
+- **FAIL:** хотя бы в одном файле осталась строка `model:`.
+- Доп. инвариант: frontmatter остаётся валидным YAML; ключи `name`/`description`/`tools`
+  сохранены.
+
+## AC-2 — валидация имени модели, never-break (G2)
+
+- **PASS:** при невалидном `agent_model_*` / project-override (мусорное имя)
+  `resolve_agent_model` возвращает откат на default (или `""`), пишет
+  `logger.warning`, и мусор **никогда** не попадает в `--model`. Покрыто
+  unit-тестом с мусорным именем (см. `04-test-plan.yaml`, TC-03..TC-05).
+- **FAIL:** мусорное имя проходит насквозь в `--model`, или валидация роняет
+  запуск агента (исключение вместо graceful-деградации).
+
+## AC-3 — resolve_agent_model осмыслен для всех 6 агентов
+
+- **PASS:** для каждого из 6 агентов `resolve_agent_model(agent)` (без
+  project_id) возвращает `claude-opus-4-8` (routing G3 выключен → intelligence-
+  модель для всех). Значение документировано в README (таблица env) и `.env.example`.
+- **FAIL:** хотя бы один агент резолвится в пустую/невалидную/устаревшую модель,
+  либо документация не отражает фактическую модель.
+
+## AC-4 — routing (G3) — **СНЯТ (N/A)**
+
+- Routing НЕ включается в этой задаче. Критерий не применяется. ADR фиксирует
+  отказ от G3 как осознанное решение Славы (08.06).
+
+## AC-5 — fallback_model (G4, опционально)
+
+- **PASS (если G4 включён):** `agent_fallback_model` задан каноничным именем,
+  проходит валидацию G2, прокидывается в `--fallback-model` (launcher 374-375).
+  Доп. инвариант never-break: МУСОРНЫЙ fallback НЕ попадает в `--fallback-model`
+  (валидируется тем же предикатом G2; учтено, что fallback читается напрямую на
+  `launcher.py:374`, минуя `resolve_agent_model` — см. TRZ §4). Задокументирован.
+- **PASS (если G4 НЕ включён):** `agent_fallback_model = ""`, ADR явно фиксирует
+  отказ; AC-5 помечен N/A.
+- **FAIL:** fallback задан невалидным именем, ИЛИ невалидный fallback проходит в
+  `--fallback-model`, ИЛИ включён без документации/ADR.
+
+## AC-6 — синхронизация документации
+
+- **PASS:** `docs/architecture/README.md`, `CLAUDE.md`, `.env.example`
+  синхронизированы — таблица «модель по ролям» актуальна (все = `claude-opus-4-8`);
+  НЕТ упоминаний `claude-sonnet-4-6` / `claude-opus-4-7` как «модели агента»
+  (если они не используются). `.env.example` содержит блок
+  `ORCH_AGENT_MODEL_*` / `ORCH_AGENT_EFFORT_*` / `ORCH_AGENT_FALLBACK_MODEL`.
+- **FAIL:** документация противоречит config, или остались мёртвые упоминания
+  sonnet/opus-4-7 как модели агента.
+
+## AC-7 — pytest зелёный + never-break
+
+- **PASS:** `pytest tests/ -q` зелёный. Невалидная модель/эффорт НЕ роняет запуск
+  агента (graceful-деградация подтверждена тестами).
+- **FAIL:** падают тесты, или невалидный вход роняет запуск.
+
+## AC-8 — enduro per-project override не сломан
+
+- **PASS:** валидный per-project override (`projects.py agent_models`) для не-self
+  проекта (enduro) резолвится и проходит валидацию без изменения поведения
+  (покрыто существующими тестами `test_resolve_agent_model.py`).
+- **FAIL:** валидация ломает корректный per-project override.
+
+## AC-9 — ADR зафиксирован
+
+- **PASS:** ADR в `06-adr/` фиксирует: (а) выбран вариант G1 «убрать frontmatter»
+  (не «читать»); (б) предикат валидации G2 (формат-чек vs allowlist) с обоснованием;
+  (в) решение по G4 (вкл/выкл) и по отказу от G3.
+- **FAIL:** ADR отсутствует или не покрывает эти решения.

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

@@ -0,0 +1,103 @@
+work_item: ORCH-074
+# Скоп (Слава 08.06): G1 + G2 + опц. G4. G3 routing снят (no routing tests).
+# Эффорт не трогаем (no new effort tests beyond never-break regression).
+
+tests:
+  # ---- G1: frontmatter `model:` убран из всех 6 промптов (AC-1) ----
+  - id: TC-01
+    type: integration
+    description: >
+      Ни один .openclaw/agents/*.md не содержит строки `^model:` во frontmatter.
+      Тест итерирует по 6 файлам, ассертит отсутствие model:-строки.
+    module: tests/test_agent_frontmatter_no_model.py
+    expected: PASS
+
+  - id: TC-02
+    type: integration
+    description: >
+      frontmatter каждого из 6 промптов остаётся валидным YAML и сохраняет ключи
+      name/description (парсинг между первыми двумя '---' без ошибок).
+    module: tests/test_agent_frontmatter_no_model.py
+    expected: PASS
+
+  # ---- G2: валидация имени модели, never-break (AC-2, AC-7) ----
+  - id: TC-03
+    type: unit
+    description: >
+      Мусорное имя в agent_model_<agent> (напр. 'gpt-4' или 'claud-opus-typo')
+      -> resolve_agent_model откатывается на default (claude-opus-4-8) и НЕ
+      возвращает мусор. Проверяется также warning в логах (caplog).
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      Мусорное имя в project-override (agent_models) -> resolve_agent_model
+      откатывается на следующий валидный уровень (default), мусор не передаётся.
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      Невалиден И override, И default -> resolve_agent_model возвращает ""
+      (без флага --model, CLI-дефолт). never-break: исключение НЕ бросается.
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Валидное каноничное имя (claude-opus-4-8) проходит валидацию без изменения:
+      resolve_agent_model('developer') == 'claude-opus-4-8'. Регрессия ORCH-041.
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  # ---- AC-3: все 6 агентов резолвятся в осмысленную модель ----
+  - id: TC-07
+    type: unit
+    description: >
+      Для всех 6 агентов (analyst/architect/developer/reviewer/tester/deployer)
+      resolve_agent_model(agent) == 'claude-opus-4-8' (routing выключен).
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  # ---- AC-8: enduro per-project override не сломан валидацией ----
+  - id: TC-08
+    type: unit
+    description: >
+      Валидный per-project override (agent_models у не-self проекта) резолвится и
+      проходит валидацию без изменения поведения (регрессия ORCH-041).
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  # ---- G4: fallback_model (опц.) — условный тест ----
+  - id: TC-09
+    type: unit
+    description: >
+      ЕСЛИ G4 включён архитектором: agent_fallback_model задан валидным именем и
+      проходит валидацию G2. ЕСЛИ выключен: agent_fallback_model == "" (тест
+      подтверждает дефолт). Финальная форма теста зависит от решения в ADR.
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  # ---- G4 never-break: fallback читается напрямую (launcher.py:374), мимо
+  #      resolve_agent_model — валидация G2 должна покрыть и его (см. TRZ §4) ----
+  - id: TC-11
+    type: unit
+    description: >
+      ЕСЛИ G4 включён: мусорное agent_fallback_model НЕ попадает в --fallback-model
+      (валидируется тем же предикатом G2, дропается с warning, never-break).
+      ЕСЛИ G4 выключен: кейс помечается N/A в test-report (синхронно с ADR).
+    module: tests/test_resolve_agent_model.py
+    expected: PASS
+
+  # ---- AC-7: общий зелёный прогон / never-break regression ----
+  - id: TC-10
+    type: integration
+    description: >
+      Полный pytest зелёный; невалидная модель/эффорт не роняет запуск агента
+      (graceful-деградация). Регрессия resolve_agent_effort (VALID_EFFORTS) цела.
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md

@@ -0,0 +1,145 @@
+# ADR-001: Убрать мёртвый frontmatter `model:` + валидация имени модели через формат-чек `claude-*`
+
+Work Item ID: ORCH-074
+Эпик: ORCH-052 (слой 3), под-задача ORCH-52a
+Связан с: ORCH-041 (каркас `resolve_agent_model`/`resolve_agent_effort`), `src/config.py`, `src/agents/launcher.py`
+
+## Статус
+Accepted
+
+## Контекст
+
+Каркас выбора модели агентов (ORCH-041) работает корректно: `launcher.resolve_agent_model(agent, project_id)`
+резолвит модель по приоритету project-override → `ORCH_AGENT_MODEL_<AGENT>` → `agent_model_default`
+→ CLI-дефолт. Все 6 агентов резолвятся в `claude-opus-4-8` (через `agent_model_default`).
+
+Аудит кода (08.06) выявил два дефекта **данных/валидации** (не дефект механизма):
+
+- **P1 — лживый/мёртвый `model:` во frontmatter.** Все 6 промптов `.openclaw/agents/*.md`
+  содержат `model:` (`claude-sonnet-4-6` у analyst/developer/tester/deployer, `claude-opus-4-7`
+  у architect/reviewer). launcher **не читает** frontmatter `model:` — это мёртвая декларация,
+  которая лжёт о реально используемой модели и нарушает принцип «документация = golden source».
+  Мина: если кто-то «починит» launcher читать frontmatter → все агенты молча уедут на устаревшие
+  модели.
+- **P2 — нет валидации имени модели.** В отличие от effort (`VALID_EFFORTS`-гард в
+  `resolve_agent_effort`), имя модели не валидируется. Опечатка в `agent_model_*` / project-override
+  → `--model <мусор>` → CLI падает или тихо деградирует. Нарушение принципа never-break.
+
+Скоуп зафиксирован стейкхолдером (Слава, 08.06): **G1 + G2 + опц. G4. G3 routing НЕ включаем
+(все 6 агентов остаются `claude-opus-4-8`). Эффорт не трогаем.** rev.2 BRD подтвердила скоуп
+без изменений. Код-факт (TRZ §4): `agent_fallback_model` читается напрямую на `launcher.py:374`,
+минуя `resolve_agent_model`.
+
+Архитектор должен зафиксировать три решения: (а) форма G1, (б) предикат валидации G2,
+(в) судьба G4 (fallback) и G3 (routing).
+
+## Решение
+
+### Решение 1 (G1): убрать `model:` из frontmatter, НЕ учить launcher его читать
+
+Из YAML-frontmatter всех 6 файлов `.openclaw/agents/*.md` удаляется **только** строка `model: …`.
+Ключи `name`/`description`/`tools` сохраняются; frontmatter остаётся валидным YAML и **описательным**.
+config (`agent_model_*` / `agent_model_default`) остаётся **единственным источником правды** о модели.
+
+Отвергнутая альтернатива — научить launcher читать frontmatter `model:` — отвергнута: она вводит
+второй источник правды (frontmatter ⊕ config), усложняет резолв, и моментально активировала бы
+устаревшие значения (sonnet-4-6 / opus-4-7) для всех агентов. «Убрать» проще, безопаснее и
+устраняет мину раз и навсегда.
+
+### Решение 2 (G2): предикат валидации — формат-чек `claude-*`, оформленный отдельным helper
+
+Добавляется **чистый helper** `is_valid_model(name: str) -> bool` рядом с `VALID_EFFORTS` в
+`src/agents/launcher.py`. Предикат — **формат-чек**, а не allowlist имён:
+
+```
+strip → непустая строка → соответствует ^claude-[a-z0-9.-]+$
+```
+
+То есть: имя после `strip()` непусто, начинается с `claude-` и состоит только из строчных
+букв/цифр/точек/дефисов. Регэксп оформляется модульной константой (напр. `_MODEL_NAME_RE`).
+
+**Почему формат-чек, а не allowlist `VALID_MODELS`:**
+allowlist (по образцу `VALID_EFFORTS`) воссоздаёт ровно ту мину, которую мы убиваем в G1 — статичный
+список имён, который **врёт при устаревании**. Когда Anthropic выпустит `claude-opus-4-9`, оператор,
+корректно прописавший новую модель, получит её молчаливый дроп на устаревший default (never-break
+сработает против пользователя). Это хуже, чем пропустить структурно-корректное, но опечатанное имя:
+финальный авторитет о существовании модели — сам Claude CLI, а не наш код. Формат-чек
+**forward-compatible** (новые версии проходят без правки кода) и ловит реальные классы отказов:
+чужой провайдер (`gpt-4`), пустая строка/пробелы, мусор с недопустимыми символами, неверный префикс
+(`claud-opus-typo`). Признанное ограничение: формат-чек НЕ ловит опечатку, которая всё ещё выглядит
+как валидное claude-имя (`claude-opus-typo`) — такие отсекает CLI на запуске (контракт never-break
++ exit-code обработка в `_monitor_agent` это покрывают). Задача валидатора — не быть реестром моделей,
+а не дать **структурному мусору** уехать в `--model`.
+
+**Применение (контракт never-break):**
+- В `resolve_agent_model`: резолвенное имя валидируется **перед возвратом**. Невалидное →
+  `logger.warning(...)` + откат на следующий валидный уровень. Реализация: helper применяется внутри
+  каскада приоритетов так, что невалидный уровень пропускается (project-override невалиден → пробуем
+  env → default), а если итог всё равно невалиден → возврат `""` (без флага `--model`, CLI-дефолт).
+  **Никогда** не возвращается мусор и **никогда** не бросается исключение.
+- Контракт уровней резолва ORCH-041 сохраняется: валидация добавляется **поверх**, порядок приоритетов
+  и сигнатуры не меняются. Все ныне используемые валидные имена (`claude-opus-4-8`, валидный enduro
+  per-project override) проходят без изменения поведения.
+- Поведенческая аналогия с `resolve_agent_effort` (`VALID_EFFORTS`): валидный → как есть, невалидный →
+  лог + дроп. Разница только в форме предиката (формат-чек vs множество) по причинам выше.
+
+### Решение 3 (G4): fallback НЕ включаем; но валидатор применяем к точке чтения fallback
+
+`agent_fallback_model` остаётся `""` (флаг `--fallback-model` не прокидывается). **AC-5 помечается
+N/A.** Обоснование отказа:
+- G3 выключен ради **детерминизма**: все агенты на `claude-opus-4-8`. Fallback вернул бы скрытую
+  вариативность модели под нагрузкой (агент молча отработал бы на другой модели) — это противоречит
+  духу зафиксированного скоупа.
+- Нет наблюдаемой проблемы доступности, мотивирующей fallback. Принцип минимального изменения.
+- Self-hosting: новое рантайм-поведение под нагрузкой трудно наблюдать; не вводим без нужды.
+
+**При этом** helper `is_valid_model` применяется ТАКЖЕ на месте чтения fallback (`launcher.py:374`,
+`fb = settings.agent_fallback_model`) — **независимо** от того, что значение сейчас пустое. Причина —
+код-факт TRZ §4: fallback читается напрямую, мимо `resolve_agent_model`, поэтому валидация только
+внутри резолва его НЕ покрывает. Защитный гард на месте чтения навсегда закрывает дыру never-break:
+если кто-то позже задаст `ORCH_AGENT_FALLBACK_MODEL` с опечаткой, мусор будет залогирован и
+сброшен (`fb_flag = ""`), а не уедет в `--fallback-model`. Для текущего пустого значения регрессии нет:
+`is_valid_model("") == False` → `fb_flag = ""` — то же поведение, что и сейчас (`if fb`). Это делает
+**TC-11** проверяемым (мусорный fallback дропается) при выключенном G4.
+
+### Решение 4 (G3): routing НЕ включаем
+
+Подтверждается отказ от model-routing как осознанное решение стейкхолдера (Слава, 08.06). Все 6
+агентов резолвятся в `claude-opus-4-8`. **AC-4 = N/A.**
+
+## Размещение и форма (для разработчика)
+
+- `is_valid_model(name)` + `_MODEL_NAME_RE` — в `src/agents/launcher.py` рядом с `VALID_EFFORTS`
+  (один валидатор, два места вызова: резолв модели и чтение fallback — оба в этом модуле, без
+  кросс-модульного импорта).
+- Префикс `claude-` хардкодится в launcher: оркестратор привязан к Claude CLI (`CLAUDE_BIN`),
+  конфигурировать предикат не нужно (не over-engineering). Каноничная версия модели по-прежнему
+  живёт ТОЛЬКО в `config.py::agent_model_default` — в launcher версия не хардкодится.
+- frontmatter: удалить только `model:`-строку; не вносить генератор, возвращающий её обратно.
+
+## Последствия
+
+**Плюсы:**
+- frontmatter перестаёт лгать; config — единственный источник правды о модели (golden source цел).
+- Опечатка/чужой провайдер/мусор в имени модели больше не роняет и не деградирует запуск агента
+  (never-break соблюдён в обеих точках: резолв и fallback).
+- Forward-compatible: будущие модели Claude не требуют правки кода (в отличие от allowlist).
+- Минимальное изменение: механизм ORCH-041, API, схема БД, структура CLI-команды не меняются.
+
+**Минусы / ограничения:**
+- Формат-чек пропускает структурно-валидную опечатку вида `claude-opus-typo` (отсекается CLI на
+  запуске + never-break обработкой exit-code). Принятый компромисс ради forward-compat.
+- Префикс `claude-` зашит — при гипотетической смене CLI-провайдера потребуется правка (приемлемо:
+  оркестратор Claude-специфичен по дизайну).
+
+**Не затрагивается:**
+- API (HTTP) — нет. Схема БД — нет миграций. Стадии/QG — без изменений (это runtime-гард в launcher,
+  не quality-gate). Топология/инфра — без изменений (07/08 артефакты не требуются).
+- Эффорт (`agent_effort_*`) и `VALID_EFFORTS`-гард — не трогаются (регрессия покрыта TC-10).
+- enduro per-project override — валидные имена проходят без изменения поведения (AC-8 / TC-08).
+
+## Соответствие принципам
+
+Всё в Docker / один сервер — да. Минимум зависимостей — новых нет. Без ORM/очередей/облака — да.
+Self-hosting: изменение применяется к БУДУЩИМ запускам агентов, прод-контейнер не перезапускается
+в рамках задачи; прод-деплой орка — только через staging-гейт (8501) и Plane-статус «Confirm Deploy».

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

@@ -0,0 +1,23 @@
+# Технические риски — ORCH-074
+
+Work Item ID: ORCH-074
+Связан с: ADR-001 (`06-adr/ADR-001-model-name-validation.md`).
+
+| ID | Риск | Вероятность | Влияние | Митигация |
+|----|------|-------------|---------|-----------|
+| R-1 | **Валидация роняет запуск агента** (исключение вместо graceful-деградации) — нарушение never-break, встал бы конвейер всех проектов. | Низкая | Высокое | Helper `is_valid_model` — чистый предикат без исключений; невалидное → `logger.warning` + откат на default/`""`. Покрыто TC-03..TC-05, TC-10. |
+| R-2 | **Fallback обходит валидацию** (код-факт: `launcher.py:374` читает `agent_fallback_model` напрямую, мимо `resolve_agent_model`). | Средняя (если позже зададут fallback) | Среднее | ADR-001 решение 3: один helper применяется ТАКЖЕ на месте чтения fallback. Мусорный fallback дропается с warning. Покрыто TC-11. |
+| R-3 | **Регрессия enduro per-project override** — валидация ломает корректный не-self override (общий инстанс/БД/очередь). | Низкая | Высокое | Валидные claude-имена проходят формат-чек без изменения поведения; механизм приоритетов ORCH-041 не меняется. Покрыто TC-08. |
+| R-4 | **Формат-чек пропускает структурную опечатку** вида `claude-opus-typo` (валидный префикс, несуществующая модель). | Средняя | Низкое | Принятый компромисс (ADR-001): финальный авторитет — CLI; never-break + обработка exit-code в `_monitor_agent` покрывают отказ запуска. Allowlist отвергнут как воссоздающий мину устаревания (G1). |
+| R-5 | **frontmatter-генератор возвращает `model:` обратно** → мина P1 оживает. | Низкая | Среднее | Проверить отсутствие автогенератора, возвращающего `model:`; frontmatter остаётся описательным. Покрыто TC-01/TC-02 (CI-гард на отсутствие `^model:`). |
+| R-6 | **Хардкод версии модели в launcher** при добавлении валидации. | Низкая | Среднее | Префикс `claude-` зашит осознанно (CLI-специфика); каноничная ВЕРСИЯ остаётся только в `config.py::agent_model_default`. Регэксп версию не фиксирует. |
+| R-7 | **Self-hosting деплой** — рестарт прод-контейнера встанет конвейер всех проектов (enduro). | — | Высокое | Изменение применяется к будущим запускам; прод-деплой только через staging-гейт (8501) и Plane-статус «Confirm Deploy». Без немедленного рестарта прода. |
+
+## Инварианты (должны держаться после изменения)
+
+1. **never-break**: невалидная модель/эффорт/fallback НЕ роняет запуск агента — деградация на
+   default/CLI-дефолт + лог.
+2. **Один источник правды о модели**: config (`agent_model_*`); frontmatter — описательный.
+3. **Обратная совместимость ORCH-041**: все валидные имена (`claude-opus-4-8`, enduro override)
+   резолвятся без изменения поведения; порядок приоритетов и сигнатуры не меняются.
+4. **Детерминизм**: все 6 агентов = `claude-opus-4-8` (G3/routing выключен, G4/fallback выключен).

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

@@ -0,0 +1,69 @@
+---
+type: review
+work_item_id: ORCH-074
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-074
+
+## Summary
+PR закрывает оба зафиксированных дефекта каркаса выбора модели (ORCH-41) в рамках
+скоупа G1 + G2 (+ защитный гард точки чтения fallback при выключенном G4), без
+изменения механизма резолва, API или схемы БД. Реализация точно соответствует
+ADR-001 и ТЗ; документация синхронизирована в том же PR; все 1012 тестов зелёные.
+Вердикт — **APPROVED**, P0/P1 findings нет.
+
+## Соответствие ТЗ и AC
+- **AC-1 (G1):** `grep -L "^model:" .openclaw/agents/*.md` возвращает все 6 файлов;
+  ни одной строки `^model:` не осталось. frontmatter остаётся валидным YAML
+  (`name`/`description`/`tools` сохранены) — покрыто `test_agent_frontmatter_no_model.py`.
+- **AC-2 (G2 never-break):** `resolve_agent_model` валидирует имя через `is_valid_model`
+  ПЕРЕД возвратом, мусорный уровень логируется (`logger.warning`) и пропускается;
+  при невалидных всех уровнях → `""` (CLI-дефолт), исключение не бросается. TC-03..05.
+- **AC-3:** все 6 агентов резолвятся в `claude-opus-4-8` (TC-07), значение в README-таблице
+  и `.env.example`.
+- **AC-4 (G3):** N/A — отказ зафиксирован в ADR.
+- **AC-5 (G4):** `agent_fallback_model=""` (выкл); тот же предикат гардит inline-чтение
+  fallback в `_spawn` (код-факт TRZ §4 учтён) — мусорный fallback дропается. ADR помечает N/A.
+- **AC-6 (доки):** README (новая секция «Модель и эффорт по ролям» + валидация),
+  `CLAUDE.md`, `.env.example` синхронизированы; стале-упоминаний `claude-sonnet-4-6`/
+  `claude-opus-4-7` как модели агента в актуальных доках нет (`grep` пуст).
+- **AC-7:** `pytest tests/ -q` → 1012 passed.
+- **AC-8:** валидный enduro per-project override проходит без изменения поведения (TC-08).
+- **AC-9:** ADR-001 фиксирует G1 «убрать», предикат G2 (формат-чек vs allowlist с
+  обоснованием), решения по G4 и G3.
+
+## Соответствие ADR
+Реализация 1:1 с ADR-001: `is_valid_model` + `_MODEL_NAME_RE` (`^claude-[a-z0-9.-]+$`)
+рядом с `VALID_EFFORTS`; один предикат, две точки вызова (резолв модели и чтение
+fallback); каскад приоритетов ORCH-41 сохранён (рефакторинг на генератор
+`_agent_model_candidates` с валидацией-со-скипом); версия модели по-прежнему живёт
+только в `config.py::agent_model_default`. Глобальные ADR не нарушены.
+
+## Качество кода
+- `is_valid_model` корректно обрабатывает `None`/пустое/whitespace (`if not name`),
+  никогда не бросает; содержательные docstrings с обоснованием формат-чека.
+- never-break соблюдён в обеих точках; `if fb` short-circuit сохраняет нулевую
+  регрессию для текущего пустого fallback.
+- Тесты содержательные: предикат (accept/reject), каскад-скип, граничные кейсы,
+  регрессия per-project override, выключенный G4.
+
+## Findings
+
+### P0 — Blocker
+- нет
+
+### P1 — Must fix
+- нет
+
+### P2 — Should fix
+- нет
+
+## Документация
+Обновлена полностью в этом же PR: `docs/architecture/README.md` (компонент Agent
+Launcher + новая секция «Модель и эффорт по ролям» с таблицей и описанием валидации),
+`CLAUDE.md` (строка про источник модели и валидацию), `.env.example` (блок
+`ORCH_AGENT_MODEL_*`/`ORCH_AGENT_EFFORT_*`/`ORCH_AGENT_FALLBACK_MODEL`),
+`CHANGELOG.md` (запись по задаче), ADR `06-adr/ADR-001-model-name-validation.md`.
+Требование «изменён src/ → обновлена документация» выполнено.

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

@@ -0,0 +1,82 @@
+---
+type: test-report
+work_item_id: ORCH-074
+result: PASS
+---
+
+# Test Report — ORCH-074
+
+Убрать мёртвый frontmatter `model:` из 6 промптов + валидация имени модели (never-break).
+Скоп: G1 + G2 + опц. G4 (выключен). G3 routing снят. Review-вердикт: APPROVED.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Ветка: feature/ORCH-074-orch-52a-frontmatter-routing-e (worktree)
+- prod health (8500): `{"status":"ok","service":"orchestrator"}`
+- Дата: 2026-06-08
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+| TC ID | Описание | Тест | Результат |
+|-------|----------|------|-----------|
+| TC-01 | Ни один `.openclaw/agents/*.md` не содержит `^model:` (G1, AC-1) | test_no_model_line_in_frontmatter[×6] | PASS |
+| TC-02 | frontmatter валидный YAML, ключи name/description сохранены | test_frontmatter_still_valid_yaml_with_keys[×6] | PASS |
+| TC-03 | Мусорный `agent_model_<agent>` → откат на default, warning, мусор не в `--model` | test_garbage_per_agent_env_falls_back_to_default | PASS |
+| TC-04 | Мусорный project-override → откат на default | test_garbage_project_override_falls_back_to_default | PASS |
+| TC-05 | Невалидны override И default → `""` (CLI-дефолт), без исключения | test_all_levels_invalid_returns_empty | PASS |
+| TC-06 | Валидное `claude-opus-4-8` проходит без изменения (регрессия ORCH-041) | test_valid_canonical_unchanged | PASS |
+| TC-07 | Все 6 агентов резолвятся в `claude-opus-4-8` (routing выкл) | test_all_six_agents_resolve_to_opus_4_8 | PASS |
+| TC-08 | Валидный enduro per-project override не сломан валидацией | test_valid_per_project_override_unchanged | PASS |
+| TC-09 | G4 выключен: `agent_fallback_model == ""` (дефолт) | test_fallback_model_disabled_by_default | PASS |
+| TC-10 | Полный pytest зелёный; never-break graceful-деградация | tests/ (1012 passed) | PASS |
+| TC-11 | G4 never-break (мусорный fallback не в `--fallback-model`) | — | N/A (G4 выключен, синхр. с ADR/AC-5) |
+
+Доп. предикат-юниты: `test_is_valid_model_accepts_canonical`, `test_is_valid_model_rejects_garbage` — PASS.
+
+## Проверка критериев приёмки
+
+| AC | Статус | Подтверждение |
+|----|--------|---------------|
+| AC-1 frontmatter `model:` убран | PASS | `grep -L "^model:" .openclaw/agents/*.md` → все 6 файлов; `grep -rn "^model:"` → пусто |
+| AC-2 валидация never-break | PASS | TC-03..05 |
+| AC-3 все 6 → `claude-opus-4-8` | PASS | TC-07 |
+| AC-4 routing G3 | N/A | снят решением (ADR) |
+| AC-5 fallback G4 | PASS | G4 выключен, `agent_fallback_model=""`, ADR фиксирует отказ (TC-09) |
+| AC-6 синхронизация доков | PASS | проверено reviewer (README/CLAUDE.md/.env.example) |
+| AC-7 pytest зелёный | PASS | 1012 passed |
+| AC-8 enduro override | PASS | TC-08 |
+| AC-9 ADR | PASS | 06-adr/ADR-001 присутствует |
+
+## Smoke test API (prod, read-only)
+```
+GET /health → HTTP 200  {"status":"ok","service":"orchestrator"}
+GET /status → HTTP 200
+GET /queue  → HTTP 200
+```
+
+## Вывод pytest
+```
+$ python -m pytest tests/ -q
+1012 passed, 1 warning in 22.07s
+
+$ python -m pytest tests/test_agent_frontmatter_no_model.py tests/test_resolve_agent_model.py -v
+32 passed, 1 warning in 0.37s
+```
+(1 warning — PydanticDeprecatedSince20 в `src/config.py:5`, существующий, вне скоупа задачи.)
+
+## AC-1 grep-проверка
+```
+$ grep -L "^model:" .openclaw/agents/*.md
+.openclaw/agents/analyst.md
+.openclaw/agents/architect.md
+.openclaw/agents/deployer.md
+.openclaw/agents/developer.md
+.openclaw/agents/reviewer.md
+.openclaw/agents/tester.md
+$ grep -rn "^model:" .openclaw/agents/*.md   # пусто (exit 1)
+```
+
+## Итог
+**PASS** — все применимые тест-кейсы (TC-01..10) зелёные, TC-11 корректно N/A (G4 выключен),
+все AC выполнены (AC-4 — N/A по скоупу), smoke API OK. Задача готова к стадии deploy-staging.

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

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

@@ -0,0 +1,56 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T18:57:59+00:00
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed inside the `orchestrator-staging` container
+(`docker exec` via Docker Engine API, ADR-001 / ORCH-048 canonical method —
+preserves the running instance's process-env so the B6 registry-isolation check
+reads `.env.staging` correctly).
+
+- Command: `python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
+- Exit code: **0** → `staging_status: SUCCESS`
+- Result: **8/10 checks PASS**, REAL failed: none.
+
+## Infra waiver (ORCH-061)
+
+```
+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
+```
+
+C9a/C9b are the two sandbox-infra-only checks (depend on SANDBOX bot accounts being
+project members, not on the pipeline). Both were tolerated because every REAL check
+is green; the script still exits 0 (fail-closed for any real failure). Trusting the
+exit code per ORCH-061 — no re-judging of waived checks.
+
+## Full output
+
+```
+[Block A] SMOKE
+  ✓ PASS  A1 GET /health → 200 status=ok  [HTTP 200, body={'status': 'ok', 'service': 'orchestrator'}]
+  ✓ PASS  A2 GET /queue → 200 with counts/max_concurrency/resilience
+  ✓ PASS  A3 ORCH_STAGING=true (not prod)  [ORCH_STAGING=true]
+
+[Block B] ACCESS
+  ✓ PASS  B4 Plane: sandbox project accessible  [HTTP 200, found 5 project(s), sandbox=YES]
+  ✓ PASS  B5 Gitea: orchestrator-sandbox accessible, push=true
+  ✓ PASS  B6 Registry: sandbox present, prod ET/ORCH absent  [sandbox=YES, prod-ET=NO(good), prod-ORCH=NO(good)]
+
+[Block C] E2E  (mode=stub)
+  ✓ PASS  C7 Create issue in Plane SANDBOX  [HTTP 201]
+  ✓ PASS  C8 Trigger pipeline via /webhook/plane  [HTTP 200, resp={'status': 'accepted'}]
+  ✗ FAIL  C9a Branch appears in orchestrator-sandbox  [branch=not found]   (SANDBOX_INFRA, waived)
+  ✗ FAIL  C9b Analyst job enqueued in staging queue                        (SANDBOX_INFRA, waived)
+
+[CLEANUP]
+  ✓ PASS  CLEANUP: deleted Plane issue (HTTP 204)
+
+RESULT: 8/10 checks PASS
+  REAL failed         : none
+  SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
+  tolerance: staging_infra_tolerance_enabled=True
+```

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-52g: убрать Telegram link-preview (логотип Plane) в уведомлениях трекера
+
+Work Item ID: ORCH-080
+
+## Description
+
+TBD

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

@@ -0,0 +1,73 @@
+# 01-BRD — ORCH-080: убрать Telegram link-preview (логотип Plane) в уведомлениях трекера
+
+Work Item ID: ORCH-080
+Эпик: ORCH-052 (под-задача ORCH-52g)
+Тип: Доработка (UX уведомлений)
+Приоритет: LOW (косметика)
+Зона: `src/notifications.py`
+
+## 1. Контекст и проблема
+
+Каждая задача в Telegram сопровождается одной live-карточкой трекера (`src/notifications.py`,
+ORCH-042/066/067). С ORCH-067 в карточке появился **кликабельный номер задачи** —
+`<a href="https://plane.mva154.duckdns.org/.../issues/<id>/">ORCH-NNN</a>`.
+
+Telegram по умолчанию разворачивает **link-preview** (web page preview) для первой ссылки
+в сообщении. Из-за ссылки на Plane под каждым сообщением трекера раскрывается крупный
+баннер-превью **«Plane — Modern project management»**.
+
+**Жалоба (Слава, 08.06):** баннер уродует ленту чата и дублируется на каждой задаче/каждом
+обновлении карточки (особенно заметно в дефолтном режиме `bump`, где карточка пересоздаётся
+на каждом переходе).
+
+## 2. Диагностика (код-аудит `src/notifications.py`)
+
+| Функция | Эндпоинт | Текущий JSON-payload | Превью |
+|---------|----------|----------------------|--------|
+| `send_telegram()` (стр. 52-62) | `POST /sendMessage` | `chat_id`, `text`, `parse_mode: HTML`, `disable_notification` | **разворачивается** (нет `disable_web_page_preview`) |
+| `edit_telegram()` (стр. 165-174) | `POST /editMessageText` | `chat_id`, `message_id`, `text`, `parse_mode: HTML` | **разворачивается** (нет `disable_web_page_preview`) |
+
+Причина баннера: оба payload **не содержат** ключ `disable_web_page_preview`. Telegram Bot API
+по умолчанию (отсутствие ключа) включает превью.
+
+`delete_telegram()` (`/deleteMessage`) превью не порождает — правки не требует.
+
+## 3. Бизнес-цель
+
+Карточка трекера и уведомления в Telegram **не должны** показывать баннер link-preview Plane,
+при этом ссылка на задачу **остаётся кликабельной**.
+
+## 4. Бизнес-требования
+
+- **BR-1.** В payload `sendMessage` (`send_telegram`) присутствует `disable_web_page_preview: True`.
+- **BR-2.** В payload `editMessageText` (`edit_telegram`) присутствует `disable_web_page_preview: True`.
+- **BR-3.** Баннер-превью Plane больше не появляется ни под карточкой трекера (оба режима
+  `bump`/`edit`), ни под отдельными notify-сообщениями, которые идут через `send_telegram`
+  (`notify_approve_requested`, `notify_error`, alert'ы стадий) — все они используют тот же
+  низкоуровневый примитив.
+- **BR-4.** Кликабельная ссылка `<a href>` на задачу в Plane сохраняется (`parse_mode: HTML`
+  не меняется).
+- **BR-5.** Контракт **never-raise** сохранён: отправка/редактирование никогда не валит
+  оркестратор; `pytest` зелёный.
+
+## 5. Не-цели (вне скоупа)
+
+- Не менять текст/формат/верстку карточки.
+- Не трогать `parse_mode` (HTML нужен для `<a href>`).
+- Не трогать bump/edit-логику (`update_task_tracker`), репойнт `tracker_message_id`,
+  delete-семантику.
+- Не вводить флаги/конфиг — поведение «без превью» безусловное (превью никому не нужно).
+- Не трогать схему БД.
+
+## 6. Заинтересованные лица
+
+- **Слава (Owner)** — инициатор, конечный наблюдатель ленты Telegram.
+
+## 7. Грабли / координация
+
+- Файл `src/notifications.py` затрагивает также ORCH-067 (и потенциально другие задачи эпика).
+  Сверить, что правки (две строки) не конфликтуют при merge.
+- Один репозиторий с ORCH-74 → по ORCH-026 действует сериализация merge.
+  Запускать **после** того как ORCH-74 доедет в `main` (или когда конвейер свободен),
+  чтобы не плодить параллельный merge в `orchestrator`.
+- Деплой — штатный через **Confirm Deploy** (self-hosting, ORCH-059).

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

@@ -0,0 +1,102 @@
+# 02-TRZ — ORCH-080: убрать Telegram link-preview в уведомлениях трекера
+
+Work Item ID: ORCH-080
+Зона изменений: `src/notifications.py` (две строки)
+
+## 1. Задействованные модули `src/`
+
+- `src/notifications.py` — **единственный** изменяемый модуль:
+  - `send_telegram(text, disable_notification=False)` — обёртка `POST .../sendMessage`.
+  - `edit_telegram(message_id, text)` — обёртка `POST .../editMessageText`.
+
+Косвенно затронуты (поведение улучшается без изменения их кода — они вызывают изменённые
+примитивы): `update_task_tracker` (bump+edit), `notify_approve_requested`, `notify_error`,
+а также вызовы `send_telegram` из `launcher`/`stage_engine` (alert'ы деплоя/падений).
+
+## 2. Изменения кода
+
+### 2.1. `send_telegram()` — добавить ключ в JSON-payload `httpx.post`
+
+В словаре `json={...}` вызова `sendMessage` (текущие стр. 55-60) добавить строку:
+
+```python
+"disable_web_page_preview": True,
+```
+
+Итоговый payload:
+```python
+json={
+    "chat_id": s.telegram_chat_id,
+    "text": text,
+    "parse_mode": "HTML",
+    "disable_notification": disable_notification,
+    "disable_web_page_preview": True,
+},
+```
+
+### 2.2. `edit_telegram()` — добавить ключ в JSON-payload `httpx.post`
+
+В словаре `json={...}` вызова `editMessageText` (текущие стр. 168-173) добавить строку:
+
+```python
+"disable_web_page_preview": True,
+```
+
+Итоговый payload:
+```python
+json={
+    "chat_id": s.telegram_chat_id,
+    "message_id": message_id,
+    "text": text,
+    "parse_mode": "HTML",
+    "disable_web_page_preview": True,
+},
+```
+
+> Примечание: Telegram Bot API исторически принимает top-level `disable_web_page_preview`
+> для `sendMessage`/`editMessageText` (актуальная схема также поддерживает
+> `link_preview_options.is_disabled`, но top-level флаг остаётся валиден и совместим).
+> Используем top-level флаг — минимальная, обратносовместимая правка, как указано в задаче.
+
+## 3. Изменения API
+
+Нет изменений внутреннего HTTP API оркестратора. Меняется только тело исходящих запросов к
+Telegram Bot API (добавлен один булев ключ в payload двух методов).
+
+## 4. Изменения схемы БД
+
+Нет.
+
+## 5. Требования к новым QG checks
+
+Нет. Новые Quality Gate проверки не вводятся.
+
+## 6. Конфиг / флаги
+
+Нет. Поведение «без превью» — безусловное (kill-switch не требуется: превью трекера
+не нужно никому, риск регрессии нулевой; правка обратимая одной строкой).
+`parse_mode`, `disable_notification`, bump/edit-логика — без изменений.
+
+## 7. Артефакты, обновляемые по pipeline
+
+- `CHANGELOG.md` — запись в `## [Unreleased]` (тип `fix:` — косметика UX уведомлений).
+- Документация: правка `src/notifications.py` затрагивает поведение, описанное в
+  `CLAUDE.md` (раздел «Нотификации / Telegram live-tracker») и
+  `docs/architecture/README.md` (компонент Notifications). Достаточно короткой ремарки,
+  что карточка/уведомления шлются без web-page-preview (по желанию архитектора — определить
+  объём в ADR; ADR не обязателен для столь малой косметики, решение за архитектором).
+
+## 8. Контракты-инварианты (не нарушать)
+
+- **never-raise**: обе функции по-прежнему ловят все исключения (`try/except: pass`/`return`)
+  и не валят оркестратор.
+- Возвращаемые значения не меняются: `send_telegram` → `message_id|None`,
+  `edit_telegram` → `EDIT_*`.
+- `parse_mode: "HTML"` сохранён в обоих payload (иначе `<a href>` сломается).
+- `disable_notification` в `send_telegram` сохранён (карточка тихая).
+- Инвариант «одна карточка на задачу» (bump/edit) не затрагивается.
+
+## 9. Commit / ветка
+
+- Ветка: `feature/ORCH-080-orch-52g-telegram-link-preview` (существует).
+- Commit: `fix: disable Telegram link-preview in tracker notifications (ORCH-080)`.

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

@@ -0,0 +1,59 @@
+# 03-Acceptance Criteria — ORCH-080
+
+Work Item ID: ORCH-080
+
+Каждый критерий имеет явное условие PASS/FAIL.
+
+## AC-1 — `disable_web_page_preview` в payload `sendMessage`
+
+- **PASS:** JSON-payload вызова `httpx.post(.../sendMessage)` в `send_telegram()` содержит
+  ключ `"disable_web_page_preview"` со значением `True`.
+- **FAIL:** ключ отсутствует или `False`.
+- **Проверка:** unit-тест (мок `httpx`) инспектирует `httpx.post.call_args.kwargs["json"]`.
+
+## AC-2 — `disable_web_page_preview` в payload `editMessageText`
+
+- **PASS:** JSON-payload вызова `httpx.post(.../editMessageText)` в `edit_telegram()` содержит
+  ключ `"disable_web_page_preview"` со значением `True`.
+- **FAIL:** ключ отсутствует или `False`.
+- **Проверка:** unit-тест (мок `httpx`) инспектирует `httpx.post.call_args.kwargs["json"]`.
+
+## AC-3 — баннер link-preview Plane исчез в карточке трекера
+
+- **PASS:** в реальном чате Telegram карточка трекера задачи (режимы `bump` и `edit`)
+  больше не показывает баннер «Plane — Modern project management».
+- **FAIL:** баннер всё ещё разворачивается.
+- **Проверка:** ручная верификация на staging (8501) после деплоя — наблюдение карточки в
+  Telegram. Автоматически косвенно покрыто AC-1/AC-2 (payload содержит флаг).
+
+## AC-4 — ссылка на задачу остаётся кликабельной
+
+- **PASS:** в карточке/уведомлениях номер задачи `ORCH-NNN` остаётся кликабельной ссылкой
+  `<a href=...>` на issue в Plane; `parse_mode: "HTML"` сохранён в обоих payload.
+- **FAIL:** `parse_mode` изменён/удалён, либо ссылка перестала рендериться как `<a href>`.
+- **Проверка:** unit-тест проверяет, что `"parse_mode": "HTML"` присутствует в обоих payload;
+  существующие тесты ссылок (`test_notify_issue_links.py`) остаются зелёными.
+
+## AC-5 — сохранены существующие поля payload
+
+- **PASS:** `send_telegram` payload по-прежнему содержит `chat_id`, `text`, `parse_mode`,
+  `disable_notification`; `edit_telegram` payload — `chat_id`, `message_id`, `text`,
+  `parse_mode`. Возвращаемые значения функций не изменились
+  (`send_telegram → message_id|None`, `edit_telegram → EDIT_*`).
+- **FAIL:** любое из перечисленных полей удалено/переименовано, либо изменился контракт
+  возврата.
+- **Проверка:** unit-тесты payload + существующие тесты трекера/классификации исходов.
+
+## AC-6 — never-raise сохранён, pytest зелёный
+
+- **PASS:** при сетевой/HTTP-ошибке `send_telegram`/`edit_telegram` не бросают исключение
+  (возврат `None`/`EDIT_FAILED`); вся сюита `pytest tests/ -q` зелёная.
+- **FAIL:** любое исключение наружу или красный pytest.
+- **Проверка:** существующие тесты never-raise (`test_resilience.py`,
+  `test_telegram_tracker.py`) + полный прогон.
+
+## AC-7 — документация обновлена в том же PR
+
+- **PASS:** `CHANGELOG.md` содержит запись об ORCH-080; при необходимости — короткая ремарка
+  в `CLAUDE.md`/`docs/architecture/README.md` о подавлении link-preview.
+- **FAIL:** функционал изменён, документация не обновлена (Reviewer → REQUEST_CHANGES).

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

@@ -0,0 +1,76 @@
+work_item: ORCH-080
+description: >
+  Подавление Telegram link-preview (disable_web_page_preview: True) в payload
+  send_telegram (sendMessage) и edit_telegram (editMessageText). Сохранить
+  parse_mode HTML, disable_notification, never-raise и контракты возврата.
+
+tests:
+  - id: TC-01
+    type: unit
+    description: >
+      send_telegram() кладёт "disable_web_page_preview": True в JSON-payload
+      httpx.post(.../sendMessage). Проверка через мок httpx и инспекцию
+      httpx.post.call_args.kwargs["json"].
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      edit_telegram() кладёт "disable_web_page_preview": True в JSON-payload
+      httpx.post(.../editMessageText). Проверка через мок httpx и инспекцию
+      payload.
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      Регрессия parse_mode: оба payload (sendMessage и editMessageText)
+      по-прежнему содержат "parse_mode": "HTML" — ссылка <a href> остаётся
+      кликабельной (AC-4).
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      Регрессия полей send_telegram: payload содержит chat_id, text,
+      parse_mode, disable_notification; disable_notification прокидывается
+      из аргумента (True/False) без изменений (AC-5).
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      Контракты возврата не изменились: send_telegram возвращает message_id
+      при ok:true, None при отсутствии креденшелов/ошибке; edit_telegram
+      возвращает EDIT_OK при ok:true (AC-5, AC-6).
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      never-raise: при httpx.post бросающем исключение send_telegram->None и
+      edit_telegram->EDIT_FAILED, без проброса исключения (AC-6).
+    module: tests/test_link_preview_disabled.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: >
+      Полный прогон существующей сюиты трекера/уведомлений остаётся зелёным
+      (нет регрессий bump/edit-логики, классификации исходов, ссылок):
+      pytest tests/test_telegram_tracker.py tests/test_tracker_bump.py
+      tests/test_notify_issue_links.py tests/test_resilience.py.
+    module: tests/test_telegram_tracker.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: >
+      Вся сюита pytest tests/ -q зелёная (общая регрессия, AC-6).
+    module: tests/
+    expected: PASS

docs/work-items/ORCH-080/06-adr/ADR-001-disable-telegram-link-preview.md

@@ -0,0 +1,63 @@
+# ADR-001: Подавление Telegram link-preview в низкоуровневых примитивах нотификаций
+
+## Статус
+Accepted
+
+## Контекст
+С ORCH-067 карточка трекера и notify-сообщения несут кликабельный номер задачи
+`<a href="https://plane.mva154.duckdns.org/.../issues/<id>/">ORCH-NNN</a>`. Telegram
+Bot API по умолчанию (при отсутствии ключа `disable_web_page_preview`) разворачивает
+web-page-preview для первой ссылки в сообщении — под каждым сообщением трекера
+раскрывается баннер «Plane — Modern project management». В дефолтном режиме `bump`
+(ORCH-067) карточка пересоздаётся на каждом переходе, поэтому баннер дублируется на
+каждой задаче и каждом обновлении, засоряя ленту (жалоба Owner, 08.06).
+
+Код-аудит (`src/notifications.py`) подтвердил причину: JSON-payload обоих
+низкоуровневых примитивов — `send_telegram()` (`POST /sendMessage`, стр. 55-60) и
+`edit_telegram()` (`POST /editMessageText`, стр. 168-173) — **не содержит** ключ
+`disable_web_page_preview`. Все вышестоящие нотификации (`update_task_tracker` в обоих
+режимах, `notify_approve_requested`, `notify_error`, alert'ы стадий из
+`launcher`/`stage_engine`) проходят через эти два примитива.
+
+## Решение
+Добавить `"disable_web_page_preview": True` в JSON-payload `httpx.post` обоих примитивов:
+`send_telegram()` и `edit_telegram()`. Изменение — **на уровне низкоуровневого
+примитива**, а не на уровне каждого вызова, потому что:
+
+1. **Единая точка** — все исходящие сообщения трекера/нотификаций идут через эти две
+   функции; правка двух строк гасит баннер у ВСЕХ потребителей (карточка `bump`/`edit`,
+   notify-хелперы, alert'ы) без изменения их кода.
+2. **Безусловно, без флага** — превью Plane не нужно никому (это не данные, а навигация
+   по ссылке, которая остаётся кликабельной). Kill-switch не вводится: риск регрессии
+   нулевой, правка обратима одной строкой. Это согласуется с принципом «минимум
+   зависимостей/конфигурации».
+3. **Top-level флаг, а не `link_preview_options.is_disabled`** — top-level
+   `disable_web_page_preview` остаётся валиден и обратносовместим в Bot API; это
+   минимальная правка без введения вложенной структуры.
+
+`parse_mode: "HTML"` сохраняется в обоих payload (иначе `<a href>` перестанет
+рендериться — ссылка должна остаться кликабельной). `disable_notification`,
+bump/edit-логика, repoint `tracker_message_id`, delete-семантика, контракты возврата
+(`send_telegram → message_id|None`, `edit_telegram → EDIT_*`) — не затрагиваются.
+
+## Последствия
+**Плюсы:**
+- Баннер link-preview исчезает под карточкой трекера (оба режима) и под всеми
+  notify/alert-сообщениями — одна правда в двух примитивах.
+- Ссылка на задачу остаётся кликабельной (HTML сохранён).
+- Нулевой риск: ключ аддитивный, контракты примитивов и инвариант «одна карточка на
+  задачу» не меняются; `never-raise` (`try/except`) сохранён.
+
+**Минусы / ограничения:**
+- Поведение безусловное — нет конфигурации «вернуть превью». Сознательный выбор:
+  превью трекера не имеет ценности, флаг был бы лишней поверхностью.
+
+**Не затрагивается:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, схема БД, `parse_mode`,
+`disable_notification`, транспортные хелперы `delete_telegram`/repoint-логика. Глобальный
+ADR не требуется — решение локально для `src/notifications.py`, не сквозное.
+
+## Self-hosting
+Изменение не требует немедленного рестарта прод-контейнера и не меняет топологию.
+Деплой — штатный через staging (8501) → `Confirm Deploy` (ORCH-059). По ORCH-026
+(сериализация merge одного репо) задача мержится после освобождения конвейера
+`orchestrator` (координация с ORCH-074 — см. BRD §7).

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

@@ -0,0 +1,22 @@
+# 10-Tech Risks — ORCH-080
+
+Work Item ID: ORCH-080
+Зона: `src/notifications.py` (две строки в `send_telegram`/`edit_telegram`)
+
+Косметическая правка UX (LOW). Топология, схема БД, стадии, QG — не меняются.
+Риск регрессии оценён как **нулевой**; ниже — остаточные пункты для внимания.
+
+| # | Риск | Вероятность | Влияние | Митигация |
+|---|------|-------------|---------|-----------|
+| R-1 | Опечатка ключа/значения (`disable_web_page_preview`) — баннер не гаснет | Низкая | Низкое (косметика) | unit-тест AC-1/AC-2 инспектирует `httpx.post.call_args.kwargs["json"]`; ручная верификация на staging (AC-3) |
+| R-2 | Случайное удаление `parse_mode: "HTML"` → ссылка `<a href>` ломается | Очень низкая | Среднее (теряется кликабельность) | AC-4: unit-тест на наличие `parse_mode: "HTML"` в обоих payload; `test_notify_issue_links.py` остаётся зелёным |
+| R-3 | Merge-конфликт с ORCH-067/ORCH-074 в `src/notifications.py` | Низкая | Низкое | По ORCH-026 сериализация merge одного репо; запуск после доезда ORCH-74 в `main` (BRD §7); pre-merge rebase (ORCH-043) |
+| R-4 | Регрессия контракта возврата примитивов (`message_id|None` / `EDIT_*`) | Очень низкая | Среднее | Правка строго аддитивна (новый ключ в payload), возвраты не трогаются; AC-5 + существующие тесты трекера |
+| R-5 | Telegram депрекейтит top-level `disable_web_page_preview` в пользу `link_preview_options` | Очень низкая | Низкое (forward-compat) | Top-level флаг остаётся валиден и обратносовместим; миграция на `link_preview_options.is_disabled` — отдельная задача при необходимости |
+
+## Инварианты, которые НЕЛЬЗЯ нарушить
+- `never-raise` обоих примитивов (`try/except` сохранён).
+- `parse_mode: "HTML"` в обоих payload (иначе `<a href>` ломается).
+- `disable_notification` в `send_telegram` (карточка тихая).
+- Инвариант «одна карточка на задачу» (bump/edit) — не затрагивается.
+- Контракты возврата: `send_telegram → message_id|None`, `edit_telegram → EDIT_*`.

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

@@ -0,0 +1,72 @@
+---
+type: review
+work_item_id: ORCH-080
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-080
+
+## Summary
+Задача убирает баннер Telegram link-preview («Plane — Modern project management»),
+который разворачивался под кликабельной ссылкой `ORCH-NNN` в карточке трекера и
+во всех notify/alert-сообщениях. Решение точно соответствует TRZ и ADR-001:
+добавлен ключ `"disable_web_page_preview": True` в JSON-payload обоих
+низкоуровневых примитивов `send_telegram` (`POST /sendMessage`) и `edit_telegram`
+(`POST /editMessageText`) — единая точка для всех потребителей, без kill-switch,
+без изменения контрактов. Изменение минимально (2 строки + комментарии),
+аддитивно и обратимо.
+
+Проверены все четыре оси (ТЗ, ADR, качество кода, тесты) + документация. Findings
+уровней P0/P1/P2 — нет.
+
+## Findings
+
+### P0 — Blocker
+- нет
+
+### P1 — Must fix
+- нет
+
+### P2 — Should fix
+- нет
+
+## Соответствие ТЗ и AC
+- TRZ §2.1/§2.2 — ключ добавлен в оба payload в точности как предписано. ✅
+- AC-1 — `disable_web_page_preview: True` в `sendMessage` payload (TC-01). ✅
+- AC-2 — то же в `editMessageText` payload (TC-02). ✅
+- AC-3 — баннер исчезает (ручная верификация на staging; косвенно покрыто AC-1/AC-2). ✅
+- AC-4 — `parse_mode: "HTML"` сохранён в обоих payload, ссылка кликабельна (TC-03);
+  `tests/test_notify_issue_links.py` зелёный. ✅
+- AC-5 — поля `chat_id/text/parse_mode/disable_notification` (send) и
+  `chat_id/message_id/text/parse_mode` (edit) сохранены; контракты возврата
+  (`message_id|None`, `EDIT_*`) не изменились (TC-04/TC-05). ✅
+- AC-6 — never-raise сохранён (TC-06); полный прогон `pytest tests/ -q` — **1058 passed**. ✅
+- AC-7 — документация обновлена в том же PR (см. ниже). ✅
+
+## Соответствие ADR
+ADR-001 (Accepted): правка на уровне примитива (а не каждого вызова), безусловно
+без флага, top-level `disable_web_page_preview` вместо `link_preview_options`,
+`parse_mode: HTML` сохранён, контракты и инвариант «одна карточка на задачу» не
+тронуты. Реализация соответствует решению 1:1. Глобальные ADR не нарушены
+(`STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД — без изменений). ✅
+
+## Качество кода
+- Изменение минимальное, целевое; комментарии ссылаются на ORCH-080 и поясняют цель.
+- `try/except` never-raise в обеих функциях не затронут; пути без кредов и контракты
+  возврата сохранены.
+- Тесты содержательные: инспектируют реальный payload через мок `httpx`
+  (`call_args.kwargs["json"]`), покрывают флаг, регрессию `parse_mode`/полей,
+  контракты возврата и never-raise (TC-01..06). Нет тривиальных/пустых тестов.
+- Security: ключ булев, новых поверхностей/секретов нет.
+
+## Документация
+Изменён `src/` (поведение исходящих Telegram-запросов) → документация обновлена в
+том же PR, как требует CLAUDE.md §2/§6:
+- `CHANGELOG.md` — запись в `## [Unreleased]` (тип `fix:`). ✅
+- `CLAUDE.md` — раздел «Нотификации / Telegram live-tracker» дополнен пунктом
+  «Без link-preview (ORCH-080)». ✅
+- `docs/architecture/README.md` — компонент Notifications дополнен ремаркой ORCH-080. ✅
+- ADR `docs/work-items/ORCH-080/06-adr/ADR-001-disable-telegram-link-preview.md` заведён. ✅
+
+Документация соответствует коду; расхождений нет.

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

@@ -0,0 +1,66 @@
+---
+type: test-report
+work_item_id: ORCH-080
+result: PASS
+---
+
+# Test Report — ORCH-080
+
+Подавление Telegram link-preview (`disable_web_page_preview: True`) в `send_telegram`
+(`sendMessage`) и `edit_telegram` (`editMessageText`). Сохранены `parse_mode: HTML`,
+`disable_notification`, never-raise и контракты возврата.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Дата: 2026-06-09
+- Ветка: `feature/ORCH-080-orch-52g-telegram-link-preview`
+- Review verdict: APPROVED (`12-review.md`)
+
+## Smoke test API (prod 8500, read-only)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok","service":"orchestrator"}` — OK |
+| `GET /status` | OK (ORCH-080 = task #62, stage `testing`) |
+| `GET /queue` | OK (breaker `closed`, preflight_ok, reconcile/reaper enabled) |
+
+## Результаты тестов
+
+| TC ID | Описание | Тест(ы) | Результат |
+|-------|----------|---------|-----------|
+| TC-01 | `disable_web_page_preview: True` в payload `sendMessage` (AC-1) | `test_send_telegram_disables_link_preview` | PASS |
+| TC-02 | `disable_web_page_preview: True` в payload `editMessageText` (AC-2) | `test_edit_telegram_disables_link_preview` | PASS |
+| TC-03 | Регрессия `parse_mode: HTML` в обоих payload (AC-4) | `test_send_telegram_keeps_parse_mode_html`, `test_edit_telegram_keeps_parse_mode_html` | PASS |
+| TC-04 | Регрессия полей `send_telegram` + проброс `disable_notification` (AC-5) | `test_send_telegram_preserves_existing_fields`, `test_send_telegram_disable_notification_default_false`, `test_edit_telegram_preserves_existing_fields` | PASS |
+| TC-05 | Контракты возврата (`message_id`/`None`/`EDIT_OK`) (AC-5/AC-6) | `test_send_telegram_returns_message_id`, `test_send_telegram_returns_none_without_creds`, `test_edit_telegram_returns_edit_ok` | PASS |
+| TC-06 | never-raise → `None`/`EDIT_FAILED` без проброса (AC-6) | `test_send_telegram_never_raises`, `test_edit_telegram_never_raises` | PASS |
+| TC-07 | Регресс сюиты трекера/уведомлений (bump/edit, ссылки, resilience) | `test_telegram_tracker.py`, `test_tracker_bump.py`, `test_notify_issue_links.py`, `test_resilience.py` (+ `test_link_preview_disabled.py`) — 106 passed | PASS |
+| TC-08 | Полная регрессия `pytest tests/ -q` (AC-6) | вся сюита — 1058 passed | PASS |
+
+## Покрытие Acceptance Criteria
+- AC-1 — TC-01 ✅
+- AC-2 — TC-02 ✅
+- AC-3 (баннер исчез в чате) — ручная верификация на staging (8501) после деплоя; автоматически косвенно покрыто AC-1/AC-2 (payload несёт флаг). Не блокирует тест-гейт.
+- AC-4 — TC-03 + `test_notify_issue_links.py` зелёный ✅
+- AC-5 — TC-04/TC-05 ✅
+- AC-6 — TC-06 + полный прогон зелёный ✅
+- AC-7 — документация (CHANGELOG/CLAUDE.md/architecture/ADR) проверена на review-стадии ✅
+
+## Вывод pytest
+
+Полная сюита:
+```
+1058 passed, 1 warning in 26.61s
+```
+
+Целевые файлы ORCH-080 (TC-01..07):
+```
+106 passed, 1 warning in 3.24s
+```
+(`test_link_preview_disabled.py` — 12 passed.)
+
+Единственный warning — `PydanticDeprecatedSince20` в `src/config.py:5` (предсуществующий, не связан с ORCH-080).
+
+## Итог
+**PASS** — все автоматические тесты (TC-01..08) зелёные, smoke API OK, регрессий нет.
+Задача готова к переходу на стадию `deploy-staging`.

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

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

@@ -0,0 +1,26 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T22:31:47Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live `orchestrator-staging` instance (port 8501).
+Run canonically **inside** the container via the Docker exec API (REST equivalent of
+`docker exec orchestrator-staging python3 /repos/orchestrator/scripts/staging_check.py
+--base-url http://localhost:8501 --mode stub`), so B6 reads the staging instance's own
+process-env registry (ORCH-048, ADR-001).
+
+**Exit code: 0 → advance.** All REAL pipeline checks passed (8/10 PASS).
+
+- Block A (SMOKE): A1 /health, A2 /queue, A3 ORCH_STAGING=true — PASS
+- Block B (ACCESS): B4 Plane sandbox, B5 Gitea sandbox (push=true), B6 registry isolation
+  (sandbox present, prod ET/ORCH absent) — PASS
+- Block C (E2E): C7 create issue in SANDBOX, C8 trigger pipeline via /webhook/plane — PASS
+- C9a/C9b — FAILED but **waived** (known sandbox-infra checks; depend on SANDBOX bot
+  accounts being project members, not on the pipeline). 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

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-52h: эффорт агентов резолвится в пустую строку в проде (env перебивает config)
+
+Work Item ID: ORCH-081
+
+## Description
+
+TBD

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

@@ -0,0 +1,82 @@
+# 01 — BRD: ORCH-081 (ORCH-52h)
+
+**Work Item:** ORCH-081
+**Эпик:** ORCH-052 (продолжение ORCH-52a / ORCH-074)
+**Тип:** Багфикс (конфигурация эффорта агентов)
+**Приоритет:** HIGH
+**Repo:** orchestrator (self-hosting)
+
+## 1. Контекст и проблема
+
+При проверке ORCH-074 (08.06) обнаружено: `resolve_agent_effort()` для **всех 6 агентов
+в проде** возвращает пустую строку `''`, хотя в `src/config.py` заданы осмысленные
+дефолты (`agent_effort_default="high"`, per-agent `high`/`medium`). Итог: флаг
+`--effort` **не передаётся** в Claude CLI, и каждый агент бежит на встроенном
+CLI-дефолте эффорта, а **не** на заявленном `high`/`medium`.
+
+### Корень (диагностика)
+В проде env-переменные `ORCH_AGENT_EFFORT_DEFAULT` и
+`ORCH_AGENT_EFFORT_{ANALYST,ARCHITECT,DEVELOPER,REVIEWER,TESTER,DEPLOYER}` выставлены в
+**пустую строку** (`VAR=` без значения). Pydantic Settings трактует присутствующую
+env-переменную (даже пустую) как явное значение и **перебивает** дефолт класса:
+`agent_effort_* = ''`. В цепочке резолва (`launcher._resolve_agent_attr`):
+- per-agent `''` → falsy → пропуск (уровень 2);
+- default `''` → falsy → пропуск (уровень 3);
+- → возврат `''` (уровень 4, «без флага»).
+
+Поскольку **и default тоже пуст**, привычный откат «per-agent пуст → взять default»
+не спасает: откатываться не на что. Это ключевой нюанс — фикс обязан давать каждой
+роли непустой «пол» (floor) даже когда И per-agent, И default env пусты.
+
+## 2. Бизнес-ценность / зачем важно
+
+Для Opus 4.8 (канон Anthropic) уровень reasoning-эффорта влияет на качество вывода
+**сильнее**, чем у прежних моделей. Coding/agentic роли (особенно `developer`) должны
+идти минимум на `high`, а `developer` — кандидат на `xhigh`. Сейчас фактически работает
+неконтролируемый CLI-дефолт → прямой удар по стратегии надёжности и предсказуемости
+качества всего конвейера (включая enduro-trails из общего инстанса).
+
+## 3. Решение (бизнес-уровень)
+
+Принят **вариант (c)** (решение Славы, 08.06): пустая строка эффорта трактуется как
+«не задано» и откатывается на осмысленный per-role дефолт (а не на CLI-дефолт),
+**устойчиво** к пустым env. Дополнительно — зафиксировать целевые дефолты в `config.py`
+и `.env.example`.
+
+### Целевые значения эффорта (единственный апгрейд — `developer`)
+| Агент | Эффорт | Обоснование |
+|-------|--------|-------------|
+| analyst | high | intelligence-роль |
+| architect | high | intelligence-роль |
+| **developer** | **xhigh** | coding/agentic, канон Opus 4.8 → апгрейд с `high` |
+| reviewer | high | intelligence-роль |
+| tester | medium | механическая роль |
+| deployer | medium | механическая роль |
+
+`developer → xhigh` — единственное изменение относительно текущих config-дефолтов;
+остальные значения подтверждают текущий замысел и фиксируются устойчиво.
+
+## 4. Грабли / ограничения (из бизнес-запроса)
+
+- **Хост-репо / env-правки НЕ переживают деплой**, если положены в git-managed файл
+  (урок 08.06 про docker-compose + TZ). Источник правды для реальных значений —
+  `.env` на хосте (gitignored), канон-шаблон — `.env.example`. Фикс обязан быть
+  **code-side robust**: даже если прод-`.env` снова окажется с пустыми
+  `ORCH_AGENT_EFFORT_*`, эффорт всё равно резолвится в целевые значения.
+- **Self-hosting:** правка касается инструмента, который сейчас в проде обслуживает и
+  другие проекты. Прод-контейнер `orchestrator` не ронять в рамках задачи; деплой —
+  через штатный `deploy-staging` → `Confirm Deploy`.
+
+## 5. Не-цели
+
+- НЕ трогать model-резолв (`resolve_agent_model` — сделан в ORCH-074).
+- НЕ включать G3 model-routing — все 6 агентов остаются на `claude-opus-4-8`.
+- НЕ менять значения эффорта сверх согласованных (`high`/`medium`/`xhigh` для
+  developer). Иные значения — отдельное взвешенное решение.
+
+## 6. Затронутые стороны
+
+- Все агенты конвейера (analyst → deployer) во всех проектах общего инстанса.
+- Операторы (правка прод-`.env`), документация (README таблица, `.env.example`).
+</content>
+</invoke>

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

@@ -0,0 +1,110 @@
+# 02 — ТЗ: ORCH-081 (ORCH-52h)
+
+**Work Item:** ORCH-081 · **Тип:** багфикс конфигурации · **Repo:** orchestrator
+
+Документ описывает ТРЕБУЕМОЕ ПОВЕДЕНИЕ и затронутые модули. Конкретный механизм
+(field_validator vs изменение резолвера) — на усмотрение архитектора; ниже зафиксированы
+инварианты, которым любая реализация обязана удовлетворять.
+
+## 1. Задействованные модули
+
+| Модуль | Роль в задаче |
+|--------|----------------|
+| `src/config.py` (`Settings`) | дефолты эффорта; устойчивость к пустому env (ядро фикса) |
+| `src/agents/launcher.py` | `resolve_agent_effort` / `_resolve_agent_attr` (цепочка резолва), `VALID_EFFORTS`, сборка `--effort` в `_spawn` |
+| `.env.example` | канон-шаблон значений эффорта по ролям |
+| `docs/architecture/README.md` | таблица «Модель и эффорт по ролям» (строки ~47–54) |
+| `CHANGELOG.md` | запись о фиксе |
+| `tests/test_resolve_agent_effort.py` | расширить кейсами пустого env |
+
+## 2. Корень бага (точная механика)
+
+`launcher._resolve_agent_attr` (строки ~104–114):
+```
+per_agent = getattr(settings, f"agent_effort_{agent}", "")  # '' в проде -> falsy -> skip
+default   = getattr(settings, "agent_effort_default", "")    # '' в проде -> falsy -> skip
+return ""                                                     # уровень 4: без флага
+```
+Pydantic: `ORCH_AGENT_EFFORT_*=` (пустая строка в env) перебивает дефолт класса →
+поле `= ''`. Поскольку пустым оказывается **и** `agent_effort_default`, у резолва нет
+непустого «пола» для отката → `''` → `--effort` не передаётся.
+
+## 3. Требования к фиксу (вариант c)
+
+### FR-1. Непустой floor на каждую роль при пустом env
+При ЛЮБОЙ комбинации пустых `ORCH_AGENT_EFFORT_*` (включая `ORCH_AGENT_EFFORT_DEFAULT=`)
+`resolve_agent_effort(agent)` обязан вернуть целевое непустое значение для каждой из 6
+ролей:
+
+| agent | результат |
+|-------|-----------|
+| analyst | `high` |
+| architect | `high` |
+| developer | `xhigh` |
+| reviewer | `high` |
+| tester | `medium` |
+| deployer | `medium` |
+
+Замечание для реализации: floor должен быть **per-role**, а не единым на default —
+иначе пустой `ORCH_AGENT_EFFORT_TESTER=` снапнется на `high` вместо `medium`. Т.е.
+«пустая строка трактуется как не-задано» применяется так, чтобы каждая роль получала
+СВОЙ канонический дефолт, а не общий.
+
+### FR-2. Приоритет резолва сохраняется
+Порядок не меняется: project-override (`projects_json.agent_efforts`) > per-agent env >
+default > floor. Непустой явный env/override по-прежнему ПОБЕЖДАЕТ floor (оператор может
+осознанно задать, напр., `ORCH_AGENT_EFFORT_DEVELOPER=high`, и это применится).
+
+### FR-3. Валидация невалидного значения не регрессирует
+Значение вне `VALID_EFFORTS` (`low|medium|high|xhigh|max`) по-прежнему логируется
+(`logger.warning`) и **дропается** → `''` (без флага). Floor НЕ должен «спасать» явную
+опечатку (`turbo`/`ultra`) — поведение ORCH-41 сохраняется (never-break, мусор не
+уезжает в CLI).
+
+### FR-4. `developer → xhigh` зафиксирован явно
+`config.py`: `agent_effort_developer` со значением `xhigh` (сейчас `high`).
+`.env.example`: `ORCH_AGENT_EFFORT_DEVELOPER=xhigh` (сейчас `high`) + правка комментария
+про split (developer теперь xhigh, не в группе «thinking → high»).
+
+### FR-5. `xhigh` принимается CLI-слоем
+Подтвердить, что `xhigh` присутствует в `VALID_EFFORTS`
+(`src/agents/launcher.py:22` — уже `frozenset({"low","medium","high","xhigh","max"})`,
+**присутствует**; добавления не требуется, только верификация тестом). Эффорт реально
+собирается в команду: `_spawn` строит `effort_flag = f"--effort {effort} "` при непустом
+`effort` (строка ~434) — путь проброса не менять, только убедиться тестом сборки флага.
+
+## 4. Изменения API / схемы БД
+
+- **API endpoints:** нет.
+- **Схема БД:** нет.
+- **Конфиг (env-контракт):** значения `ORCH_AGENT_EFFORT_*` неизменны по ИМЕНАМ;
+  меняется лишь дефолт `developer` (high → xhigh) и устойчивость к пустым значениям.
+  Обратная совместимость: непустой явный env работает 1:1 как раньше.
+
+## 5. Требования к QG checks
+
+Новых QG checks не требуется. Гейты конвейера не затрагиваются.
+
+## 6. Артефакты pipeline (обновить в ТОМ ЖЕ PR)
+
+- `src/config.py` — дефолт developer + устойчивость к пустому env.
+- `src/agents/launcher.py` — если фикс кладётся в резолвер (на усмотрение архитектора).
+- `.env.example` — `ORCH_AGENT_EFFORT_DEVELOPER=xhigh` + правка комментария split.
+- `docs/architecture/README.md` — таблица эффорта: developer `high` → `xhigh`; при
+  необходимости — ремарка про floor/устойчивость к пустому env.
+- `CHANGELOG.md` — запись (`fix:`).
+- `tests/test_resolve_agent_effort.py` — новые кейсы (см. 04-test-plan.yaml).
+
+## 7. Операционная часть (вне PR-кода, для деплой-лога)
+
+- Реальные значения — в прод-`.env` на хосте (gitignored). Рекомендуется привести
+  прод-`.env` к каноне `.env.example` (developer=xhigh, остальные непустые), НО фикс
+  обязан работать и без этого (FR-1). Не коммитить секреты/хост-env в git.
+- Деплой — через `deploy-staging` (8501) → `Confirm Deploy`. Прод-контейнер не ронять
+  вне штатного хука.
+
+## 8. Definition of Done
+
+AC-1…AC-5 из `03-acceptance-criteria.md` выполнены; `pytest -q` зелёный; документация
+(README + `.env.example` + CHANGELOG) синхронизирована в том же PR; never-break соблюдён.
+</content>

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

@@ -0,0 +1,60 @@
+# 03 — Критерии приёмки: ORCH-081 (ORCH-52h)
+
+Каждый критерий — чёткое условие PASS/FAIL. Пустой env моделируется в unit-тестах
+(установка `agent_effort_* = ""`), проверка «в проде» — операционная (post-deploy).
+
+## AC-1 — осмысленный непустой эффорт для всех 6 агентов
+**PASS:** `resolve_agent_effort(agent)` возвращает целевое непустое значение для каждой
+роли при канонической конфигурации:
+
+| agent | ожидаемое |
+|-------|-----------|
+| analyst | `high` |
+| architect | `high` |
+| developer | `xhigh` |
+| reviewer | `high` |
+| tester | `medium` |
+| deployer | `medium` |
+
+**FAIL:** любой агент возвращает `''` или значение, отличное от таблицы.
+
+## AC-2 — пустой env НЕ приводит к пустому эффорту (вариант c)
+**PASS:** при `agent_effort_default = ""` И всех `agent_effort_<role> = ""`
+(моделирование прод-env, где `ORCH_AGENT_EFFORT_*=` пусты) `resolve_agent_effort` для
+каждой из 6 ролей возвращает значение по таблице AC-1 (floor per-role срабатывает:
+developer=`xhigh`, tester/deployer=`medium`, остальные=`high`), а **не** `''`.
+**FAIL:** хотя бы одна роль при полностью пустом env даёт `''`.
+
+## AC-3 — эффорт реально пробрасывается в запуск агента
+**PASS:** в `launcher._spawn` (или эквивалентной сборке) при непустом резолвнутом
+эффорте формируется `--effort <value> ` во флагах команды; при пустом — флаг
+отсутствует. Тест сборки флага подтверждает наличие `--effort xhigh ` для developer и
+`--effort medium ` для tester.
+**FAIL:** `--effort` отсутствует при непустом значении ИЛИ присутствует при пустом.
+
+## AC-4 — документация синхронизирована
+**PASS:** `.env.example` содержит `ORCH_AGENT_EFFORT_DEVELOPER=xhigh` и корректный
+комментарий про split; таблица «Модель и эффорт по ролям» в
+`docs/architecture/README.md` показывает developer = `xhigh` (остальные без изменений);
+`CHANGELOG.md` содержит запись о фиксе.
+**FAIL:** любой из трёх артефактов рассинхронизирован с фактическими дефолтами config.
+
+## AC-5 — never-break, тесты зелёные
+**PASS:**
+- `pytest -q` целиком зелёный (включая существующие
+  `tests/test_resolve_agent_effort.py` и новые кейсы).
+- Невалидное значение эффорта (`turbo`/`ultra`/`bogus`) по-прежнему логируется и
+  дропается в `''` (floor его НЕ маскирует) — регрессии валидации ORCH-41 нет.
+- Непустой явный per-agent env / project-override по-прежнему побеждает floor
+  (приоритет резолва сохранён).
+- `xhigh ∈ VALID_EFFORTS` (подтверждено тестом).
+
+**FAIL:** падение любого теста, регрессия валидации/приоритета, либо `xhigh`
+отвергается как невалидный.
+
+## AC-6 (операционный, для деплой-стадии) — проверка в проде
+**PASS:** после деплоя на проде `resolve_agent_effort` для 6 агентов даёт значения
+AC-1 (проверяется в рантайме прод-инстанса / по логам запуска агента — наличие
+`--effort` с верным уровнем). Фиксируется в `14-deploy-log.md`.
+**FAIL:** в проде хотя бы один агент бежит без `--effort` или с неверным уровнем.
+</content>

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

@@ -0,0 +1,86 @@
+work_item: ORCH-081
+description: >
+  Тест-план фикса ORCH-52h — устойчивость резолва эффорта к пустому env (вариант c) +
+  фиксация целевых дефолтов (developer -> xhigh). Расширяет существующий
+  tests/test_resolve_agent_effort.py. Пустой прод-env моделируется установкой
+  agent_effort_* = "" на settings (через monkeypatch), как уже делают текущие тесты.
+tests:
+  - id: TC-01
+    type: unit
+    description: >
+      Канонические дефолты: resolve_agent_effort для всех 6 ролей даёт
+      analyst/architect/reviewer=high, developer=xhigh, tester/deployer=medium.
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-1, FR-4]
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      Пустой env (вариант c): при agent_effort_default="" И всех
+      agent_effort_<role>="" каждая из 6 ролей возвращает целевое значение по AC-1
+      (НЕ ""). Ключевой кейс бага: developer -> xhigh, tester/deployer -> medium,
+      analyst/architect/reviewer -> high.
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-2]
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      Floor НЕ маскирует опечатку: невалидное значение (default/per-agent/override =
+      'turbo'/'ultra'/'bogus') по-прежнему логируется и дропается в "" (валидация
+      ORCH-41 не регрессирует). Проверить, что floor не подменяет невалидный явный ввод
+      на дефолт.
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-5, FR-3]
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: >
+      Приоритет сохранён: непустой per-agent env побеждает floor/ default
+      (ORCH_AGENT_EFFORT_DEVELOPER=high -> "high", не "xhigh"); project-override
+      побеждает per-agent (agent_efforts={"developer":"xhigh"}).
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-5, FR-2]
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: >
+      xhigh валиден: xhigh ∈ VALID_EFFORTS и resolve_agent_effort с developer-дефолтом
+      xhigh не дропается.
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-5, FR-5]
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Сборка флага: при resolve developer=xhigh во флагах присутствует "--effort xhigh ",
+      при tester=medium — "--effort medium "; при пустом эффорте "--effort" отсутствует
+      (mirror логики _spawn, как существующие test_flags_* кейсы).
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-3]
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: >
+      Документация синхронизирована: .env.example содержит
+      ORCH_AGENT_EFFORT_DEVELOPER=xhigh; README таблица эффорта показывает developer
+      xhigh. (Проверяется ревьюером/тестером по diff; опционально — текстовая ассерта.)
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-4]
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: >
+      Регрессия существующего набора: весь tests/test_resolve_agent_effort.py +
+      tests/test_resolve_agent_model.py остаются зелёными (never-break ORCH-41/074).
+    module: tests/test_resolve_agent_effort.py
+    covers: [AC-5]
+    expected: PASS
+</content>

docs/work-items/ORCH-081/06-adr/ADR-001-effort-resolution-floor.md

@@ -0,0 +1,129 @@
+# ADR-001: Per-role floor для резолва `--effort`, устойчивый к пустому env
+
+**Work Item:** ORCH-081 (ORCH-52h) · **Эпик:** ORCH-052 (после ORCH-074)
+**Связанные:** ORCH-41 (резолв model/effort), ORCH-074 (валидация модели, `is_valid_model`)
+
+## Статус
+Accepted
+
+## Контекст
+
+В проде `resolve_agent_effort()` возвращает `''` для всех 6 агентов, хотя в
+`src/config.py` заданы осмысленные дефолты (`high`/`medium`). Итог: флаг `--effort`
+не передаётся в Claude CLI, каждый агент бежит на встроенном CLI-дефолте, а не на
+заявленном уровне. Для Opus 4.8 reasoning-эффорт сильнее влияет на качество, чем у
+прежних моделей, → прямой удар по предсказуемости качества всего конвейера (включая
+enduro-trails из общего инстанса).
+
+### Корень (точная механика)
+Pydantic Settings трактует **присутствующую** env-переменную — даже пустую
+(`ORCH_AGENT_EFFORT_DEVELOPER=` без значения) — как явное значение и **перебивает**
+дефолт класса: поле `= ''`. В проде пусты И per-agent (`ORCH_AGENT_EFFORT_<ROLE>=`),
+И default (`ORCH_AGENT_EFFORT_DEFAULT=`). Цепочка резолва (`_resolve_agent_attr`):
+
+```
+project-override (agent_efforts) → пусто
+per-agent env ('') → falsy → skip
+default ('') → falsy → skip
+→ '' (уровень 4: без флага)
+```
+
+Привычный откат «per-agent пуст → взять default» не спасает: откатываться не на что —
+default тоже пуст. Нужен непустой **per-role** «пол» (floor) ниже default.
+
+### Дополнительное ограничение (урок 08.06)
+Хост-правки env, положенные в git-managed файл, **не переживают деплой**. Источник
+правды реальных значений — `.env` на хосте (gitignored). Значит, фикс обязан быть
+**code-side robust**: даже если прод-`.env` снова окажется с пустыми
+`ORCH_AGENT_EFFORT_*`, эффорт всё равно резолвится в целевые значения.
+
+## Рассмотренные варианты
+
+### Вариант A — `field_validator` в `config.py` (coerce пустой → дефолт на уровне поля)
+Валидатор каждого `agent_effort_*` конвертирует пустую строку в канонический дефолт
+поля.
+**Отклонён:** ломает приоритет FR-2. Если per-agent поле всегда непустое, оно ВСЕГДА
+бьёт `default` (уровень 3 становится мёртвым для роли с пустым env). Сценарий: оператор
+ставит `ORCH_AGENT_EFFORT_DEFAULT=max`, per-agent оставляет пустыми — намерение «все
+роли на max», но coercion на уровне поля даст каждой роли её per-role дефолт, а не
+`max`. Floor обязан стоять **строго ниже** default, а это видно только в резолвере,
+где доступна вся цепочка приоритетов.
+
+### Вариант B — explicit hardcoded map `{analyst: high, …}` в `launcher.py`
+Отдельная константа-карта per-role floor.
+**Отклонён как первичный:** вводит **второй источник правды** рядом с дефолтами
+`config.py`. Баг, который мы чиним, — это и есть дрейф/рассинхрон конфигурации;
+заводить новую поверхность дрейфа концептуально неверно (карту и config надо вручную
+держать в синхроне).
+
+### Вариант C — floor в резолвере, значение = class-default поля (ПРИНЯТО)
+Floor применяется как **последний** уровень в `resolve_agent_effort`, ниже `default`,
+а его значение берётся из **декларированного class-default** соответствующего поля
+`Settings` (через `model_fields`), который пустой env НЕ может перебить.
+
+## Решение
+
+Фикс кладётся в `resolve_agent_effort` (`src/agents/launcher.py`), `_resolve_agent_attr`
+остаётся общим с model-резолвом и **не трогается** (floor — effort-специфичен).
+
+### Цепочка резолва (новая, уровень 4 — floor)
+```
+1. project-override  (projects_json.agent_efforts[agent])   — непустой побеждает
+2. per-agent env     (settings.agent_effort_<agent>)        — непустой побеждает
+3. global default    (settings.agent_effort_default)        — непустой побеждает
+4. per-role FLOOR    (class-default поля agent_effort_<agent>) — НОВОЕ, непустой пол
+   ↓ (только если все 1–3 пусты)
+5. валидация VALID_EFFORTS → невалидное дропается в '' (ORCH-41, never-break)
+```
+
+### Ключевые инварианты реализации
+- **Floor = class-default поля, а не instance-значение.** `type(settings).model_fields[f"agent_effort_{agent}"].default` возвращает декларированный дефолт (`high`/`medium`/`xhigh`), который пустой env не клобберит. Это восстанавливает значение, которое pydantic дал бы, не будь спурьозного `VAR=`. **Единый источник правды — `config.py`**: developer-апгрейд на `xhigh` делается одной правкой поля, floor подтягивается автоматически.
+- **Floor применяется ДО валидации и ТОЛЬКО при пустом резолве.** Порядок критичен для FR-3: явная опечатка (`turbo`) — непустая, поэтому floor НЕ применяется, и значение штатно дропается валидацией в `''`. Floor не маскирует мусор.
+- **Floor — строго уровень 4 (ниже default).** Непустой явный env/override/`default` по-прежнему побеждает floor (FR-2). Floor срабатывает лишь когда сконфигурировать эффорт забыли/занулили на всех уровнях.
+- **Unknown-agent fallback:** если поля `agent_effort_<agent>` нет (имя не из 6 ролей), floor деградирует на class-default `agent_effort_default` (`high`) — непустой безопасный пол, never-break.
+
+### Сопутствующая правка config (FR-4)
+`config.py`: `agent_effort_developer` `high → xhigh` (канон Opus 4.8: coding/agentic роль).
+Это единственное изменение значений; остальные (`analyst/architect/reviewer=high`,
+`tester/deployer=medium`) подтверждаются и фиксируются устойчиво. Поскольку floor =
+class-default, апгрейд автоматически становится и новым floor для developer.
+
+### Целевые значения (floor при полностью пустом env)
+| agent | floor |
+|-------|-------|
+| analyst | high |
+| architect | high |
+| developer | **xhigh** |
+| reviewer | high |
+| tester | medium |
+| deployer | medium |
+
+## Последствия
+
+**Плюсы**
+- Code-side robust: пустой прод-`.env` больше не обнуляет эффорт; целевые уровни
+  гарантированы без зависимости от хост-правок, которые не переживают деплой.
+- Единый источник правды (`config.py`); нулевой риск дрейфа floor-карты.
+- Приоритет резолва и контракт ORCH-41 сохранены 1:1; непустой явный конфиг работает
+  как раньше (полная обратная совместимость).
+- Валидация ORCH-41 не регрессирует — опечатки по-прежнему дропаются, never-break.
+
+**Минусы / ограничения**
+- Лёгкая зависимость от pydantic-v2 API (`model_fields[...].default`) — публичный
+  стабильный атрибут, но это связь с внутренним устройством Settings. Замокать в тестах
+  тривиально.
+- «CLI-дефолт без флага» как исход для 6 штатных ролей становится недостижим — это
+  намеренно: для известных ролей всегда есть непустой пол. Unknown-agent сохраняет
+  безопасный непустой fallback.
+
+**Не затрагивается**
+- API endpoints — нет. Схема БД — нет. QG checks / гейты конвейера — нет.
+  Model-резолв (ORCH-074) — нет. Путь проброса `--effort` в `_spawn` (стр. ~434) — нет
+  (только верификация тестом, FR-3/FR-5).
+
+## Деплой (self-hosting)
+Правка касается инструмента, обслуживающего в проде и другие проекты. Прод-контейнер
+`orchestrator` не ронять в рамках задачи; деплой — штатно `deploy-staging` (8501) →
+`Confirm Deploy`. Рекомендуется привести прод-`.env` к каноне `.env.example`
+(developer=xhigh, остальные непустые), НО фикс обязан работать и без этого (FR-1).
+Проверка в проде (AC-6) фиксируется в `14-deploy-log.md`.

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

@@ -0,0 +1,17 @@
+# 10 — Технические риски: ORCH-081 (ORCH-52h)
+
+| ID | Риск | Вероятн. | Влияние | Митигация |
+|----|------|----------|---------|-----------|
+| R-1 | **Floor маскирует опечатку.** Если floor применить ПОСЛЕ/ВМЕСТО валидации, мусорное `turbo` подменится на floor вместо дропа → регрессия never-break ORCH-41. | низк. | средн. | Floor строго ДО валидации и ТОЛЬКО при пустом резолве (значение `turbo` непустое → floor не трогается → дроп). Покрыть тестом FR-3 (опечатка → `''`). |
+| R-2 | **Floor перебивает явный конфиг.** Ошибка порядка → floor встанет выше default/per-agent и `ORCH_AGENT_EFFORT_DEFAULT=max` перестанет применяться. | низк. | средн. | Floor — строго уровень 4 (ниже default). Тест FR-2: непустой default/per-agent/override побеждает floor. |
+| R-3 | **Зависимость от pydantic-internal** `model_fields[...].default`. Будущий мажор pydantic может сменить API → floor отвалится. | низк. | низк. | Публичный стабильный атрибут pydantic v2. Тест AC-1/AC-2 поймает регрессию сразу (floor вернёт не то/пусто). Фиксируется версией pydantic в зависимостях. |
+| R-4 | **Дрейф floor vs config** при выборе hardcoded-карты. | — | — | Снят архитектурно: floor = class-default поля, единый источник правды (см. ADR-001, вариант B отклонён). |
+| R-5 | **Self-hosting:** правка резолва эффорта затрагивает запуск ВСЕХ агентов всех проектов общего инстанса; ошибка ломает конвейер enduro-trails тоже. | низк. | высок. | Обязательный `deploy-staging` (8501) перед прод-деплоем; прод-контейнер не ронять вне штатного хука; `Confirm Deploy`-гейт. Post-deploy проверка AC-6 по логам запуска агента. |
+| R-6 | **Прод-`.env` снова с пустыми `ORCH_AGENT_EFFORT_*`** после деплоя (урок 08.06: git-managed env не переживает). | средн. | низк. | Именно это и закрывает фикс (FR-1, code-side robust): эффорт резолвится в floor независимо от состояния `.env`. Приведение `.env` к каноне — рекомендация, не зависимость. |
+| R-7 | **`xhigh` не принимается CLI-слоем.** developer-апгрейд бессмыслен, если `xhigh ∉ VALID_EFFORTS`. | очень низк. | средн. | `xhigh` уже в `VALID_EFFORTS` (`launcher.py:22`); добавления не требуется — только верификация тестом (FR-5). |
+
+## Сводный вывод
+Изменение локализовано в `resolve_agent_effort` + один дефолт `config.py`; не трогает
+API, схему БД, QG-гейты, model-резолв и путь проброса `--effort`. Главный остаточный
+риск — операционный (R-5, self-hosting), снимается штатным staging-гейтом. Контракт
+ORCH-41/ORCH-074 сохранён, обратная совместимость полная.

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

@@ -0,0 +1,57 @@
+---
+type: review
+work_item_id: ORCH-081
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-081 (ORCH-52h) — устойчивость резолва `--effort` к пустому env + developer→xhigh
+
+## Summary
+Фикс конфигурационного бага: в проде `resolve_agent_effort()` возвращал `''` для всех 6 агентов (пустые `ORCH_AGENT_EFFORT_*=` перебивают class-default pydantic), `--effort` не доходил до Claude CLI. Решение — вариант C по ADR-001: непустой **per-role floor** уровня 4 в `resolve_agent_effort`, значение = декларированный class-default поля `agent_effort_<agent>` через `model_fields[...].default`. `developer` поднят `high→xhigh` в `config.py` (единый источник правды, floor подтягивается автоматически).
+
+Реализация полностью соответствует ТЗ и ADR; вся документация синхронизирована в том же бранче; `pytest -q` — **1031 passed**.
+
+## Соответствие ТЗ (FR-1…FR-5)
+- **FR-1** per-role floor при пустом env → каждая роль получает свой канон (`_agent_effort_floor`, TC-02). ✓
+- **FR-2** приоритет резолва сохранён: явный env/override/default побеждают floor (TC-04: `test_explicit_env_beats_floor`, `test_default_beats_floor`, `test_project_override_beats_floor`). ✓
+- **FR-3** валидация не регрессирует: непустая опечатка (`turbo`) не доходит до floor → дропается в `''` (TC-03 `test_floor_does_not_mask_typo`). ✓
+- **FR-4** `agent_effort_developer = "xhigh"` в `config.py`; `ORCH_AGENT_EFFORT_DEVELOPER=xhigh` + правка комментария split в `.env.example`. ✓
+- **FR-5** `xhigh ∈ VALID_EFFORTS`; сборка флага `--effort xhigh `/`--effort medium ` подтверждена (TC-05/TC-06). ✓
+
+## Соответствие ADR-001
+- Floor как **строго уровень 4** ниже default, в резолвере — ✓ (вариант C, не field_validator/не hardcoded map).
+- Floor = **class-default поля** (`type(settings).model_fields[...].default`), который пустой env перебить не может — ✓.
+- `_resolve_agent_attr` (общий с model-резолвом) **не тронут** — ✓.
+- Floor применяется **ДО валидации и только при пустом резолве** — ✓.
+- Unknown-agent деградирует на class-default `agent_effort_default` (`high`) — ✓ (`test_empty_env_unknown_agent_floor_is_default`).
+- Никаких изменений API / схемы БД / QG / model-резолва / пути проброса в `_spawn` — ✓.
+
+## Качество кода и тестов
+- Чистый leaf-helper, подробные docstrings, контракт never-raise соблюдён.
+- Тесты содержательные, покрывают все AC/FR (канон-дефолты, floor per-role, не-маскирование опечатки, приоритет на 3 уровнях, `xhigh`-валидность, сборка флага + негативные кейсы).
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice-to-have
+- `tests/test_resolve_agent_effort.py:218-219` — продублирована строка `assert "--fallback-model" not in flags` в `test_flags_absent_when_model_empty`. Безвредно, можно убрать при случае.
+
+## Документация
+Изменён `src/` → документация обновлена в том же бранче (доку-гейт пройден):
+- `docs/architecture/README.md` — таблица «Модель и эффорт по ролям»: developer = `xhigh`; добавлена ремарка про per-role floor / устойчивость к пустому env (AC-4). ✓
+- `.env.example` — `ORCH_AGENT_EFFORT_DEVELOPER=xhigh` + комментарий split/floor (AC-4). ✓
+- `CHANGELOG.md` — запись `fix:` с разбором корня/фикса. ✓
+- `docs/work-items/ORCH-081/06-adr/ADR-001-effort-resolution-floor.md` — присутствует (Accepted). ✓
+
+## Примечание (вне scope ревью)
+- AC-6 — операционная проверка в проде после деплоя, фиксируется в `14-deploy-log.md` на стадии deploy. К коду PR не относится.
+- `git diff main...HEAD` показывает также код ORCH-074 (`is_valid_model`/`resolve_agent_model`) из-за устаревшего локального `main`; собственно изменения ORCH-081 — коммит `56bf303` (+ README обновлён в линии бранча). На ревью это не влияет: HEAD-состояние корректно по всем осям.

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

@@ -0,0 +1,61 @@
+---
+type: test-report
+work_item_id: ORCH-081
+result: PASS
+---
+
+# Test Report — ORCH-081 (ORCH-52h)
+
+Устойчивость резолва `--effort` к пустому env (вариант c) + фиксация целевых
+дефолтов (developer → xhigh).
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Repo/branch: orchestrator @ `feature/ORCH-081-orch-52h-env-config` (worktree)
+- prod `/health`: ok (8500) · staging `/health`: ok (8501) — не трогались
+- Дата: 2026-06-08
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+| TC ID | Описание | Покрытие | Результат |
+|-------|----------|----------|-----------|
+| TC-01 | Канонические дефолты: 6 ролей дают high/high/xhigh/high/medium/medium | AC-1, FR-4 | PASS |
+| TC-02 | Пустой env (вариант c): per-role floor, developer→xhigh, tester/deployer→medium, остальные→high (НЕ "") | AC-2 | PASS |
+| TC-03 | Floor НЕ маскирует опечатку: `turbo`/`ultra`/`bogus` логируется и дропается в "" | AC-5, FR-3 | PASS |
+| TC-04 | Приоритет сохранён: непустой per-agent env / project-override побеждают floor/default | AC-5, FR-2 | PASS |
+| TC-05 | `xhigh ∈ VALID_EFFORTS` и не дропается | AC-5, FR-5 | PASS |
+| TC-06 | Сборка флага: `--effort xhigh ` (developer), `--effort medium ` (tester); пустой → флаг отсутствует | AC-3 | PASS |
+| TC-07 | Документация синхронизирована: `.env.example` DEVELOPER=xhigh, README таблица developer=xhigh | AC-4 | PASS |
+| TC-08 | Регрессия: весь набор test_resolve_agent_effort.py + полный регресс зелёные | AC-5 | PASS |
+
+### Сопоставление с критериями приёмки
+- **AC-1** — `test_canonical_effort_all_roles[*]` (6 параметров) → PASS.
+- **AC-2** — `test_empty_env_falls_back_to_per_role_floor[*]` (6 параметров) + `test_empty_env_unknown_agent_floor_is_default` → PASS.
+- **AC-3** — `test_flags_present_when_configured`, `test_flags_effort_per_role`, `test_flags_absent_when_effort_empty` → PASS.
+- **AC-4** — verified по diff: `src/config.py:108` `agent_effort_developer = "xhigh"`; `.env.example:48` `ORCH_AGENT_EFFORT_DEVELOPER=xhigh`; `docs/architecture/README.md` таблица developer=`xhigh`; `CHANGELOG.md` содержит запись `fix:` → PASS.
+- **AC-5** — `test_floor_does_not_mask_typo`, `test_*_beats_floor`, `test_xhigh_is_valid`, `test_invalid_*_dropped` + полный регресс зелёный → PASS.
+- **AC-6** — операционный, вне scope стадии testing: проверяется в рантайме прода на стадии `deploy`, фиксируется в `14-deploy-log.md`.
+
+## Smoke test API (prod 8500)
+- `GET /health` → `{"status":"ok","service":"orchestrator"}`
+- `GET /status` → HTTP 200
+- `GET /queue` → HTTP 200
+
+## Вывод pytest
+
+Целевой файл задачи:
+```
+tests/test_resolve_agent_effort.py ... 29 passed, 1 warning in 0.36s
+```
+
+Полный регресс:
+```
+........................................................................ [ 97%]
+.......................                                                  [100%]
+1031 passed, 1 warning in 27.02s
+```
+(единственный warning — PydanticDeprecatedSince20 в `src/config.py:5`, не относится к задаче, предсуществующий.)
+
+## Итог
+**PASS** — все 8 TC пройдены, критерии AC-1…AC-5 выполнены (AC-6 операционный, для стадии deploy), полный регресс `1031 passed`, smoke API зелёный. Прод/staging-контейнеры не затрагивались.

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

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

@@ -0,0 +1,27 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T19:47:45+00:00
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed. Exit code 0 → advance.
+
+Canonical run inside the `orchestrator-staging` container (ORCH-048, ADR-001) via the
+Docker Engine API over the unix socket (docker CLI unavailable in the agent container):
+
+```
+python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub
+```
+
+Result: **8/10 checks PASS**, all REAL checks 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
+```
+
+The two waived checks (C9a/C9b) are the known sandbox-infra-only checks tolerated under
+ORCH-061 (SANDBOX bot accounts are not members of the sandbox Plane project — not a pipeline
+regression). All pipeline (REAL) checks A1–A3, B4–B6, C7–C8 passed.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-81: конвейер не создаёт PR для ветки → деплой стопорится на merge-verify (HOLD)
+
+Work Item ID: ORCH-082
+
+## Description
+
+TBD

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

@@ -0,0 +1,119 @@
+# 01 — BRD: ORCH-082 (ORCH-81)
+
+**Конвейер не создаёт PR для ветки → деплой стопорится на merge-verify (HOLD)**
+
+- Work Item: **ORCH-082** (Plane-заголовок «ORCH-81»)
+- Repo: `orchestrator` (self-hosting)
+- Тип: **Багфикс / надёжность конвейера**
+- Приоритет: **HIGH** — блокирует автономный деплой
+- Зона: создание PR (reviewer/developer/deployer пути), `src/merge_gate.py`, `src/stage_engine.py` (`_handle_merge_verify`), `src/agents/launcher.py` (`_ensure_pr`)
+
+---
+
+## 1. Контекст и проблема
+
+При деплое **ORCH-074** (08.06, статус «Confirm Deploy») детерминированный finalizer
+(`run_deploy_finalizer` → под-гейт `_handle_merge_verify`) вызвал
+`merge_gate.merge_pr(repo, branch)` и получил **`ok=False` («no open PR»)**: в Gitea для
+ветки `feature/ORCH-074-…` **не существовало открытого PR** с `head.ref==branch` и
+`base.ref=="main"`.
+
+Защита **ORCH-073** (fail-closed по «SHA-в-main») отработала **корректно**: задача удержана
+на стадии `deploy` (НЕ `done`), Plane → Blocked, Telegram-alert, ложно-зелёного `done` не
+произошло. Это **правильное** поведение для случая «merge реально невозможен».
+
+**Дефект не в защите, а в инварианте до неё:** автономный конвейер **не гарантировал**, что к
+моменту merge у ветки существует открытый PR. PR на сегодня создаётся ровно в одном месте —
+`launcher._ensure_pr`, вызываемом **только** на пути `agent == "developer"` и **только** когда
+в этом конкретном run был непустой git-diff, успешный commit и успешный push (см. root-cause
+ниже). Любой сценарий, где developer-run не произвёл свежий коммит, оставляет ветку **без PR**,
+и задача неминуемо застревает на merge-verify.
+
+### Workaround, применённый вручную (НЕ фикс)
+PR #79 создан вручную через Gitea API (`mergeable=True`) → штатно перезапущен
+`run_deploy_finalizer` → `merge_pr` честно влил код в `main` → задача `done`. Это разовое ручное
+вмешательство, **не** устранение причины.
+
+### Почему это системный пробел, а не разовый сбой
+Так как создание PR **не гарантировано конвейером**, любая следующая задача с тем же стечением
+обстоятельств (developer-run без нового коммита; тихо упавший вызов создания PR; ветка
+восстановлена/пересоздана вручную) застрянет на merge-verify тем же образом. Автономность
+деплоя (цель ORCH-54) этим заблокирована.
+
+---
+
+## 2. Root cause (предварительный аудит кода — подтвердить логами G1)
+
+PR создаётся **исключительно** функцией `AgentLauncher._ensure_pr` (`src/agents/launcher.py`),
+которая вызывается из `_monitor_agent` по цепочке условий:
+
+```
+exit_code == 0
+  → есть worktree-изменения (git status --porcelain непусто)
+    → git commit succeeded
+      → git push succeeded
+        → agent == "developer"   ←── ТОЛЬКО здесь вызывается self._ensure_pr(...)
+```
+
+Отсюда минимум три структурных способа остаться без PR:
+
+- **R-A (условное создание).** Если developer-run завершился без изменений (`git status`
+  пустой) — ветка уже была закоммичена/запушена в прошлый run, бойнс REQUEST_CHANGES без новых
+  правок, повторный прогон, или ручное восстановление ветки — `_ensure_pr` **не вызывается
+  вовсе**. PR не появится никогда. (Соответствует гипотезе ТЗ №2.)
+- **R-B (тихий сбой создания).** `_ensure_pr` ловит любое исключение
+  (`except Exception → logger.error → return None`): транзиентная ошибка Gitea на шаге
+  `POST …/pulls` теряется без ретрая и без эскалации. Конвейер «думает», что developer
+  отработал, и едет дальше. (Гипотеза ТЗ №1 — silent fail.)
+- **R-C (разъехавшееся состояние ветки/PR).** ORCH-074 — первая задача после серии ручных
+  восстановлений `main` 08.06. PR мог быть закрыт/пересоздан, либо у ветки остался только
+  авто-docs-PR (`base != main`), который `merge_pr`/`pr_already_merged` корректно НЕ считают
+  кодовым PR. (Гипотеза ТЗ №4.)
+
+Идемпотентность (гипотеза №3): сам `_ensure_pr` идемпотентен на чтении (сначала `GET …open&head`,
+создаёт только если пусто), но он не запускается вне «свежий developer-коммит», поэтому
+идемпотентность не достигает merge-стадии — никакой флаг «PR создан» в БД не хранится.
+
+**Вывод:** гарантия «к моменту merge у ветки есть открытый код-PR» в конвейере **отсутствует**.
+
+---
+
+## 3. Бизнес-цели
+
+| ID | Цель |
+|----|------|
+| **G1** | Установить и задокументировать точную причину отсутствия PR на ORCH-074 (код-аудит + логи run_id 396/398). |
+| **G2** | Гарантировать инвариант: к моменту merge-verify у ветки **есть** открытый код-PR; если его нет — finalizer/deployer создаёт его сам, **идемпотентно**, ПЕРЕД `merge_pr`, вместо HOLD на ручное вмешательство. |
+| **G3** | Явно логировать факт PR: **PR-created / PR-existed / PR-create-failed** (наблюдаемость). |
+
+## 4. Не-цели (явные границы)
+
+- НЕ ослаблять защиту ORCH-073: fail-closed по «SHA-в-main» остаётся. Реальная невозможность
+  merge → по-прежнему HOLD + alert.
+- НЕ авто-мержить без PR (PR — обязательный артефакт ревью/слияния).
+- НЕ создавать PR в неподходящий момент — только на ребре `deploy → done`, ПОСЛЕ прохождения
+  всех гейтов (security/merge-gate/staging/image-freshness уже пройдены).
+- НЕ менять `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, схему БД, контракты `check_deploy_status`,
+  exit-коды хука.
+
+## 5. Заинтересованные стороны
+- **Owner** (homenet542) — автономность деплоя орка.
+- Все проекты на инстансе (enduro-trails) — общий прод/очередь: ложный HOLD self-задачи не
+  должен требовать ручного вмешательства, а реальный дефект merge — обязан удерживаться.
+
+## 6. Бизнес-риски и допущения
+- **Грабли (из ORCH-073):** у ветки может быть несколько PR (код-PR + авто docs-PR). Создание/
+  выбор PR обязан фильтровать `head.ref==branch` И `base.ref=="main"`, иначе слияние/верификация
+  схватят не тот PR.
+- **Допущение:** merge-verify исполняется ПОСЛЕ всех гейтов, поэтому создание PR именно здесь не
+  обходит ревью и безопасно по времени.
+- **Контракт надёжности:** весь новый путь — **never-raise**; ошибка создания PR (Gitea
+  недоступна) → честный HOLD + alert, а не исключение в `advance_stage`.
+
+## 7. Definition of Done (бизнес-уровень)
+1. Root cause задокументирован (`06-adr/` архитектором, ссылка из ADR на этот BRD).
+2. После фикса задача с веткой без PR не зависает: конвейер создаёт PR идемпотентно и доводит до
+   `done` (при честном merge).
+3. Защита ORCH-073 цела (регресс-тест на «код не в main» → HOLD).
+4. Логи различают created/existed/failed.
+5. `pytest` зелёный; never-raise соблюдён.

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

@@ -0,0 +1,108 @@
+# 02 — ТЗ: ORCH-082 (ORCH-81)
+
+**Гарантированный идемпотентный код-PR перед merge-verify + наблюдаемость**
+
+> Машина стадий, реестр `QG_CHECKS`, схема БД, exit-коды хука, контракты
+> `check_deploy_status`/`_parse_deploy_status`, защита ORCH-073 (SHA-в-main) — **НЕ меняются**.
+> Изменение — точечная врезка «ensure PR» в под-гейт merge-verify + новый идемпотентный
+> PR-актор в `merge_gate` + структурное логирование.
+
+---
+
+## 1. Задействованные модули `src/`
+
+| Модуль | Роль в задаче | Характер изменения |
+|--------|---------------|--------------------|
+| `src/merge_gate.py` | leaf-логика merge-актора (`merge_pr`, `verify_merged_to_main`, `pr_already_merged`) | **+ новый идемпотентный актор** `ensure_open_pr(repo, branch) -> (status, detail)` (never-raise). |
+| `src/stage_engine.py` | под-гейт `_handle_merge_verify` на ребре `deploy → done` | **врезка:** вызвать `ensure_open_pr` ПЕРЕД `merge_pr`; на `failed` → честный HOLD+alert; логировать исход. |
+| `src/agents/launcher.py` | `_ensure_pr` (текущий единственный создатель PR) | **усилить наблюдаемость** (различать created/existed/failed) — опционально переиспользовать новый актор `merge_gate.ensure_open_pr`, чтобы создание PR было единым кодом. Поведение «создавать только у developer» НЕ ужесточать без необходимости. |
+| `src/config.py` | флаги | **+ kill-switch** `merge_verify_autocreate_pr_enabled` (дефолт `True`), область — та же `merge_verify_applies` (self-hosting / `merge_verify_repos`). |
+| `docs/architecture/README.md`, `CHANGELOG.md` | golden source | обновить (раздел ORCH-071/073 merge-verify — дописать про авто-создание PR). |
+
+> Точная сигнатура `ensure_open_pr`, имя/дефолт kill-switch и место врезки — за архитектором
+> (ADR). Ниже — функциональные требования к поведению, не финальный дизайн.
+
+## 2. Функциональные требования
+
+### FR-1 — Идемпотентный PR-актор `merge_gate.ensure_open_pr(repo, branch)`
+Возвращает структурированный исход (например `("existed"|"created"|"failed", detail)`):
+1. `GET …/pulls?state=open` → если есть PR с **`head.ref==branch` И `base.ref=="main"`** →
+   `("existed", <number>)`. **Фильтр идентичен `merge_pr`/ORCH-073 FR-3** — авто-docs-PR
+   (`base != main`) НЕ считается код-PR.
+2. Иначе `POST …/pulls` (`head=branch`, `base=main`, заголовок/тело — авто) → `201` →
+   `("created", <number>)`.
+3. Идемпотентность: если параллельно PR уже создан и Gitea вернёт ошибку «PR exists» —
+   повторный `GET` подтверждает существующий PR и возвращает `("existed", …)`, **дубль не
+   плодится** (AC-2).
+4. Любая иная ошибка HTTP/parse/сети → `("failed", <reason>)`. **Never-raise.**
+
+### FR-2 — Врезка в `_handle_merge_verify` (ребро `deploy → done`)
+Внутри существующего `_handle_merge_verify`, ПОСЛЕ `merge_verify_applies(repo)`-гейта и
+резолва `validated_revision`, но **ПЕРЕД** `merge_pr`:
+- если `merge_verify_autocreate_pr_enabled` → вызвать `ensure_open_pr(repo, branch)`;
+- `status == "created"|"existed"` → продолжить штатно к `merge_pr` → `verify_merged_to_main`;
+- `status == "failed"` → **честный HOLD + alert** (как сегодняшний not-merged путь:
+  `note_not_merged_alert` + `set_issue_blocked` + Plane-коммент + Telegram; задача остаётся на
+  `deploy`, НЕ `done`, БЕЗ отката на development) с сообщением, отражающим «PR создать не
+  удалось» (а не «PR не влит»).
+- kill-switch off → текущее поведение 1:1 (никакого создания PR).
+
+### FR-3 — Защита ORCH-073 цела (регресс-инвариант)
+Создание PR **не подменяет** проверку слияния. После `ensure_open_pr` + `merge_pr` верификация
+остаётся **только** `verify_merged_to_main` (SHA-в-main, ORCH-073 FR-1) + регресс-гард
+(`check_main_regression`). Если код реально не оказался в `main` — HOLD сохраняется. Создание PR
+лишь устраняет **ложный** HOLD «no open PR», который конвейер обязан был предотвратить.
+
+### FR-4 — Наблюдаемость (G3)
+В лог писать однозначный исход на каждом из мест работы с PR:
+- `merge-verify ensure_open_pr -> created PR #N` /
+- `… -> existed PR #N` /
+- `… -> failed: <reason>`.
+Сообщение HOLD при `failed` обязано отличаться текстом от HOLD «not merged» (оператор должен
+видеть, что причина — невозможность создать PR, а не невозможность слить уже созданный).
+Желательно — пометка исхода в `14-deploy-log.md` (best-effort, frontmatter `deploy_status:`
+нетронут).
+
+### FR-5 — Идемпотентность повторного прохода
+Повторный заход в merge-verify (reaper / reconciler / повторный approve) при уже существующем
+PR → `ensure_open_pr` возвращает `("existed", …)`, `merge_pr` → `already-merged`/штатно — **без
+дублей PR и без побочных эффектов** (INV-5/AC-9 ORCH-073 сохранены).
+
+## 3. Изменения API (HTTP / внутренние)
+- **Внешний HTTP API сервиса — без изменений** (новых endpoint нет).
+- **Исходящие вызовы Gitea:** новый `POST /api/v1/repos/{owner}/{repo}/pulls` из контекста
+  merge-verify (тот же вызов, что уже делает `_ensure_pr`); чтение — существующий
+  `GET …/pulls?state=open`.
+- **Внутренний контракт `merge_gate`:** новая публичная функция `ensure_open_pr` (leaf,
+  never-raise), вызывается из `stage_engine._handle_merge_verify` (и опционально из
+  `launcher._ensure_pr`).
+
+## 4. Изменения схемы БД
+**Нет.** Состояние идемпотентности выводится из самого Gitea (наличие открытого PR), миграции
+не требуются. (Согласуется с restart-safe-моделью merge-verify.)
+
+## 5. Требования к новым QG checks
+**Новых зарегистрированных QG-checks нет.** Это под-гейт-врезка в `advance_stage`
+(`_handle_merge_verify`), как и сам ORCH-071 merge-verify — не отдельный `QG_CHECKS`-элемент.
+Реестр `QG_CHECKS` не трогается.
+
+## 6. Конфигурация / kill-switch
+- `merge_verify_autocreate_pr_enabled: bool = True` (env `ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED`).
+  `False` → ровно прежнее поведение (нет авто-создания PR; «no open PR» → HOLD как раньше).
+- Область действия — `merge_gate.merge_verify_applies(repo)`: реально только для self-hosting /
+  `merge_verify_repos`; прочие репо — no-op.
+
+## 7. Артефакты pipeline (создать/обновить)
+- `docs/work-items/ORCH-082/06-adr/ADR-001-*.md` — архитектор (root cause G1 + дизайн ensure-PR).
+- `12-review.md`, `13-test-report.md`, `14/15/16-*` — последующие стадии.
+- Обновить `docs/architecture/README.md` (блок ORCH-071/073) и `CHANGELOG.md` — в ТОМ ЖЕ PR
+  (правило агентов №2/№6).
+
+## 8. Инварианты (не нарушать)
+- `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, `check_deploy_status`/`_parse_deploy_status`,
+  exit-коды хука, terminal-sync, merge-gate (ORCH-043), image-freshness (ORCH-058) — **без
+  изменений**.
+- Контракт **never-raise** на всём пути merge-verify (INV-1 ORCH-073).
+- Слияние только через PR (`POST /pulls/{index}/merge`); `main` никогда не push/force-push.
+- Защита ORCH-073 (SHA-в-main + регресс-гард) приоритетна: при конфликте «создать PR» проигрывает
+  «не дать ложно-зелёный done».

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

@@ -0,0 +1,69 @@
+# 03 — Критерии приёмки: ORCH-082 (ORCH-81)
+
+Каждый критерий — однозначное условие PASS/FAIL. Машинные вердикты гейтов — только из
+YAML-frontmatter.
+
+---
+
+### AC-1 — Root cause задокументирован
+- **PASS:** в `06-adr/ADR-001-*.md` зафиксировано, **почему** PR не создался на ORCH-074
+  (со ссылкой на код-путь `launcher._ensure_pr` и/или логи run_id 396/398), и какая из гипотез
+  R-A/R-B/R-C подтвердилась.
+- **FAIL:** причина не названа / только догадка без привязки к коду или логам.
+
+### AC-2 — Гарантированный идемпотентный код-PR к merge-verify
+- **PASS:** к моменту merge-verify у ветки гарантированно существует открытый PR с
+  `head.ref==branch` И `base.ref=="main"`; повторный вызов авто-создания при уже существующем PR
+  **не плодит дубль** (возвращает existed).
+- **FAIL:** при отсутствии PR задача сразу уходит в HOLD; ИЛИ повторный проход создаёт второй PR.
+
+### AC-3 — Авто-создание PR ПЕРЕД merge_pr (вместо немедленного HOLD)
+- **PASS:** при физическом отсутствии открытого код-PR `_handle_merge_verify` сначала создаёт PR
+  (`ensure_open_pr → created`), затем выполняет `merge_pr` → `verify_merged_to_main`; ложного
+  HOLD «no open PR» не возникает.
+- **FAIL:** «no open PR» по-прежнему приводит к HOLD без попытки создать PR (при включённом
+  kill-switch).
+
+### AC-4 — Защита ORCH-073 цела (регресс)
+- **PASS:** при реальном «код не в `main`» (`verify_merged_to_main → False`) — по-прежнему HOLD +
+  alert + `set_issue_blocked`, задача НЕ `done`, БЕЗ авто-отката на development. Регресс-гард
+  `check_main_regression` не ослаблен.
+- **FAIL:** создание PR маскирует невлитый код и пропускает задачу в `done`; ИЛИ ослаблен
+  SHA-в-main / регресс-гард.
+
+### AC-5 — Логи различают исход PR
+- **PASS:** в логах присутствует ровно один однозначный исход на проход: **PR-created** /
+  **PR-existed** / **PR-create-failed**; HOLD по «create-failed» текстуально отличим от HOLD
+  «not merged».
+- **FAIL:** исход не логируется или created/existed/failed неразличимы.
+
+### AC-6 — Грабли мультиPR: фильтр base==main
+- **PASS:** при наличии у ветки авто-docs-PR (`base != main`) актор НЕ принимает его за код-PR и
+  создаёт/выбирает именно PR на `main`.
+- **FAIL:** docs-PR трактуется как код-PR (слияние/верификация работают не с тем PR).
+
+### AC-7 — Never-raise + честный HOLD при недоступности Gitea
+- **PASS:** при ошибке создания PR (Gitea недоступна/HTTP-ошибка) `ensure_open_pr` возвращает
+  `failed`, путь merge-verify даёт честный HOLD+alert, исключение НЕ всплывает в `advance_stage`.
+- **FAIL:** исключение пробрасывается / процесс падает / задача молча уходит в `done`.
+
+### AC-8 — Kill-switch off → прежнее поведение 1:1
+- **PASS:** при `merge_verify_autocreate_pr_enabled=False` авто-создание не выполняется; «no open
+  PR» → HOLD как до фикса (поведение ORCH-074 воспроизводится).
+- **FAIL:** при выключенном флаге PR всё равно создаётся.
+
+### AC-9 — Условность (область self-hosting)
+- **PASS:** для не-self репозиториев (`merge_verify_applies → False`) врезка — no-op; создание PR
+  остаётся за прежним механизмом.
+- **FAIL:** авто-создание срабатывает для чужих репо.
+
+### AC-10 — Инварианты не нарушены
+- **PASS:** `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, `check_deploy_status`, exit-коды хука,
+  merge-gate/image-freshness — без изменений; `main` не push/force-push; документация
+  (`README.md`, `CHANGELOG.md`) обновлена в этом же PR.
+- **FAIL:** затронут любой из перечисленных инвариантов / документация не обновлена.
+
+### AC-11 — pytest зелёный
+- **PASS:** `pytest tests/ -q` зелёный, включая новые тесты из `04-test-plan.yaml` и
+  существующие `test_merge_verify*.py` / `test_orch073_*` / `test_merge_actor.py`.
+- **FAIL:** любой тест падает.

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

@@ -0,0 +1,90 @@
+work_item: ORCH-082
+title: "Гарантированный идемпотентный код-PR перед merge-verify (фикс ложного HOLD)"
+strategy: >
+  Юнит-тесты на новый идемпотентный актор merge_gate.ensure_open_pr (мок Gitea HTTP)
+  и интеграционные тесты на врезку в stage_engine._handle_merge_verify (мок merge_gate
+  + verify), включая регресс ORCH-073. Все пути — never-raise. Gitea и git мокаются,
+  сеть не дёргается.
+
+tests:
+  # ---- ensure_open_pr: идемпотентный PR-актор (FR-1) ----
+  - id: TC-01
+    type: unit
+    description: "ensure_open_pr: открытого код-PR нет -> POST создаёт PR -> ('created', N); фильтр base==main применён"
+    module: tests/test_orch082_ensure_pr.py
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: "ensure_open_pr: открытый PR head==branch И base==main уже есть -> ('existed', N), POST не вызывается (нет дубля)"
+    module: tests/test_orch082_ensure_pr.py
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: "Грабли мультиPR: у ветки только docs-PR (base!=main) -> он НЕ считается код-PR -> создаётся PR на main (AC-6)"
+    module: tests/test_orch082_ensure_pr.py
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "ensure_open_pr never-raise: Gitea POST/GET кидает HTTP/timeout -> ('failed', reason), исключение не всплывает (AC-7)"
+    module: tests/test_orch082_ensure_pr.py
+    expected: PASS
+
+  - id: TC-05
+    type: unit
+    description: "Идемпотентность гонки: POST вернул 'PR exists' -> повторный GET подтверждает существующий -> ('existed', N), дубль не создан"
+    module: tests/test_orch082_ensure_pr.py
+    expected: PASS
+
+  # ---- _handle_merge_verify: врезка ensure-PR (FR-2/FR-3) ----
+  - id: TC-06
+    type: integration
+    description: "merge-verify: PR отсутствовал -> ensure_open_pr создаёт -> merge_pr -> verify True -> deploy->done БЕЗ ложного HOLD (AC-3)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  - id: TC-07
+    type: integration
+    description: "Регресс ORCH-073: PR создан/влит, но verify_merged_to_main=False (код не в main) -> HOLD + set_issue_blocked, НЕ done, без отката (AC-4)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  - id: TC-08
+    type: integration
+    description: "ensure_open_pr -> 'failed' (Gitea down) -> честный HOLD+alert, текст отличается от 'not merged', advance_stage не падает (AC-7)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  - id: TC-09
+    type: integration
+    description: "Kill-switch merge_verify_autocreate_pr_enabled=False -> ensure_open_pr не вызывается, 'no open PR' -> прежний HOLD 1:1 (AC-8)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  - id: TC-10
+    type: integration
+    description: "Условность: non-self репо (merge_verify_applies=False) -> врезка no-op, авто-создание не выполняется (AC-9)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  - id: TC-11
+    type: integration
+    description: "Идемпотентный повторный проход (reaper/reconciler): PR уже existed, merge_pr=already-merged -> verify True -> done, без дублей PR (AC-2/FR-5)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  # ---- Наблюдаемость (G3 / AC-5) ----
+  - id: TC-12
+    type: unit
+    description: "Логи различают created/existed/failed; HOLD-сообщение create-failed != HOLD-сообщение not-merged (caplog, AC-5)"
+    module: tests/test_orch082_merge_verify_autocreate.py
+    expected: PASS
+
+  # ---- Регресс существующего merge-verify контракта ----
+  - id: TC-13
+    type: integration
+    description: "Happy-path ORCH-071/073 не изменён: merge_pr ok + verify True + регресс-гард ok -> done, merged_to_main: true во frontmatter"
+    module: tests/test_merge_verify.py
+    expected: PASS

docs/work-items/ORCH-082/06-adr/ADR-001-ensure-open-pr-before-merge-verify.md

@@ -0,0 +1,221 @@
+# ADR-001: Гарантированный идемпотентный код-PR перед merge-verify (ensure_open_pr)
+
+- Work Item: **ORCH-082** (Plane-заголовок «ORCH-81»)
+- Repo: `orchestrator` (self-hosting)
+- Связь: амендмент к merge-verify ([adr-0013](../../../architecture/adr/adr-0013-merge-verify-gate.md),
+  [adr-0014](../../../architecture/adr/adr-0014-merge-verify-sha-source-of-truth.md));
+  глобально зафиксировано в [adr-0016](../../../architecture/adr/adr-0016-ensure-open-pr-before-merge-verify.md)
+- BRD/ТЗ/AC: `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+
+## Статус
+Accepted
+
+## Контекст
+
+### Что случилось (инцидент ORCH-074, 08.06)
+Деплой ORCH-074 встал на под-гейте merge-verify (ребро `deploy → done`):
+`run_deploy_finalizer → _handle_merge_verify` вызвал `merge_gate.merge_pr(repo, branch)` и
+получил `ok=False, "no open PR"` — в Gitea для ветки `feature/ORCH-074-…` **не было открытого
+PR** с `head.ref==branch` И `base.ref=="main"`. Защита ORCH-073 (fail-closed по «SHA-в-main»)
+**отработала правильно**: задача удержана на `deploy` (НЕ `done`), Plane → Blocked, Telegram-alert,
+ложно-зелёного `done` не произошло. Разблокировано вручную — PR #79 создан через Gitea API,
+finalizer перезапущен, код честно влит, задача `done`. Это **workaround, не фикс**.
+
+### Root cause (G1, подтверждён код-аудитом)
+PR создаётся в конвейере **ровно в одном месте** — `AgentLauncher._ensure_pr`
+(`src/agents/launcher.py:1079`), и вызывается он из `_monitor_agent` **только** по цепочке
+условий (`src/agents/launcher.py:751–753`):
+
+```
+exit_code == 0
+  → git status --porcelain непусто (есть worktree-изменения)
+    → git commit succeeded
+      → git push succeeded
+        → agent == "developer"   ←── ТОЛЬКО здесь вызывается self._ensure_pr(...)
+```
+
+Отсюда класс «ветка без PR» структурно неизбежен. Подтверждённые код-аудитом ветви:
+
+- **R-A (условное создание) — структурный первопричинный дефект.** Если в конкретном
+  developer-run нет свежих изменений (`git status` пуст: ветка уже была закоммичена/запушена
+  ранее, бойнс REQUEST_CHANGES без новых правок, повторный прогон, **ручное восстановление
+  ветки**) — `_ensure_pr` **не вызывается вовсе**. PR не появится никогда. Никакого
+  персистентного флага «PR создан» в БД нет, поэтому идемпотентность чтения внутри `_ensure_pr`
+  до merge-стадии не доходит.
+- **R-C (разъехавшееся состояние ветки/PR) — проксимальный триггер ORCH-074.** ORCH-074 — первая
+  задача после серии **ручных восстановлений `main` 08.06**: открытый код-PR был закрыт/не
+  пересоздан, у ветки мог остаться лишь авто-docs-PR (`base != main`), который `merge_pr` (фильтр
+  `base=="main"`, ORCH-073 FR-3) корректно НЕ считает кодовым.
+- **R-B (тихий сбой создания) — потенциальная, не первопричина здесь.** `_ensure_pr` глотает любое
+  исключение (`except Exception → logger.error → return None`): транзиентная ошибка Gitea на
+  `POST …/pulls` теряется без ретрая и эскалации.
+
+**Вывод:** в конвейере **отсутствует инвариант** «к моменту merge-verify у ветки есть открытый
+код-PR». Защита ORCH-073 верно ловит следствие, но причина — выше по потоку. Любая следующая
+задача с тем же стечением обстоятельств застрянет тем же образом → автономный деплой (ORCH-54)
+заблокирован.
+
+### Ограничения, которые нельзя нарушать
+- Защита ORCH-073 (SHA-в-main + регресс-гард) — приоритетна. Создание PR **не должно** маскировать
+  реально невлитый код.
+- `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, схема БД, `check_deploy_status`/`_parse_deploy_status`,
+  exit-коды хука, merge-gate (ORCH-043), image-freshness (ORCH-058) — без изменений.
+- Весь путь merge-verify — **never-raise**.
+- Слияние только через PR; `main` никогда не push/force-push.
+
+## Решение
+
+Закрыть пробел инвариантом «обеспечить открытый код-PR» **внутри того же под-гейта merge-verify**,
+ПЕРЕД детерминированным `merge_pr`. Три точечные врезки, симметричные существующему дизайну
+ORCH-071/073 (leaf-актор в `merge_gate` + врезка в `_handle_merge_verify` + kill-switch). Машина
+стадий и реестры не трогаются.
+
+### Р-1. Новый идемпотентный leaf-актор `merge_gate.ensure_open_pr(repo, branch)`
+
+Сигнатура (решение архитектора по ТЗ §1):
+
+```python
+def ensure_open_pr(repo: str, branch: str) -> tuple[str, str]:
+    """Гарантировать открытый код-PR (head==branch, base==main). never-raise.
+    Возврат: ("existed", "<number>") | ("created", "<number>") | ("failed", "<reason>").
+    """
+```
+
+Алгоритм (FR-1):
+1. `GET …/pulls?state=open` → найти PR с **`head.ref==branch` И `base.ref=="main"`**. Фильтр
+   **идентичен** `merge_pr`/ORCH-073 FR-3 — авто-docs-PR (`base != main`) НЕ считается код-PR
+   (AC-6). Нашли → `("existed", <number>)`.
+2. Иначе `POST …/pulls` (`head=branch`, `base="main"`, авто-заголовок/тело) → `201` →
+   `("created", <number>)`.
+3. **Идемпотентность при гонке:** если на `POST` Gitea вернёт «PR exists»/`409`/`422` —
+   повторный `GET` (шаг 1) подтверждает существующий PR → `("existed", …)`. Дубль не плодится
+   (AC-2, FR-5).
+4. Любая иная HTTP/parse/сетевая ошибка → `("failed", <reason>)`. **Never-raise** (`except
+   Exception → ("failed", str(e))`).
+
+Актор — **leaf** (зависит только от `settings` + `httpx`, без импорта `stage_engine`), как
+`merge_pr`/`verify_merged_to_main`. Таймауты — переиспользовать `settings.merge_pr_timeout_s`
+(тот же класс Gitea-вызовов).
+
+> **Почему фильтр `base=="main"` критичен** (грабли ORCH-073): у ветки одновременно бывают код-PR
+> и авто-docs-PR. Без фильтра актор «увидит» docs-PR как existed и не создаст нужный код-PR, а
+> `merge_pr` потом не найдёт что мержить → петля. Один и тот же предикат `head==branch &&
+> base=="main"` гарантирует, что `ensure_open_pr` и `merge_pr` работают с одним и тем же PR.
+
+### Р-2. Врезка в `_handle_merge_verify` (ребро `deploy → done`)
+
+В существующем `_handle_merge_verify` (`src/stage_engine.py:1324`), **ПОСЛЕ**
+`merge_verify_applies(repo)`-гейта и резолва `sha = image_freshness.validated_revision(...)`,
+но **ПЕРЕД** `merge_pr`:
+
+```python
+sha = image_freshness.validated_revision(repo, branch)
+
+# ORCH-082: гарантировать открытый код-PR ДО детерминированного merge_pr.
+if settings.merge_verify_autocreate_pr_enabled:
+    pr_status, pr_detail = merge_gate.ensure_open_pr(repo, branch)
+    logger.info(
+        f"Task {task_id}: merge-verify ensure_open_pr -> {pr_status} ({pr_detail})"
+    )
+    if pr_status == "failed":
+        return _hold_pr_create_failed(
+            task_id, repo, work_item_id, branch, pr_detail, result
+        )
+    # "created" | "existed" -> штатно продолжаем к merge_pr.
+
+merged_ok, merge_msg = merge_gate.merge_pr(repo, branch)
+...
+```
+
+Семантика (FR-2):
+- `created | existed` → продолжаем штатно к `merge_pr` → `verify_merged_to_main` → регресс-гард.
+- `failed` → **честный HOLD + alert** через новый helper `_hold_pr_create_failed` (см. Р-3); задача
+  остаётся на `deploy` (НЕ `done`), БЕЗ отката на development — симметрично текущему not-merged/
+  regressed HOLD.
+- kill-switch off → блок пропускается целиком → поведение 1:1 как до фикса (AC-8).
+
+Место выбрано так, что **никакой существующий шаг не сдвигается**: `merge_pr` и
+`verify_merged_to_main` остаются на своих местах с теми же контрактами. Создание PR — это только
+страховка инварианта ДО них.
+
+### Р-3. Новый HOLD-helper `_hold_pr_create_failed` (распознаваемость причины, FR-4/AC-5)
+
+Зеркало существующего `_hold_main_regressed` (`src/stage_engine.py:1280`). Текст HOLD **обязан
+отличаться** от not-merged HOLD: оператор должен видеть, что причина — **невозможность создать
+PR** (Gitea недоступна), а не **невозможность слить уже созданный**:
+
+```python
+def _hold_pr_create_failed(task_id, repo, work_item_id, branch, reason, result) -> bool:
+    merge_gate.note_not_merged_alert(work_item_id)  # переиспользуем счётчик-нотификатор
+    msg = (f"PR создать не удалось: {reason} (repo={repo}, branch={branch}, "
+           f"wi={work_item_id}). Открытый код-PR отсутствует и не создан — задача "
+           f"удержана на `deploy` (НЕ done). Нужно проверить доступность Gitea / создать PR.")
+    # set_issue_blocked + plane_add_comment + send_telegram (каждый в try/except, never-break HOLD)
+    result.alerted = True
+    result.note = "pr-create-failed-hold"   # отличается от "merge-not-verified-hold"
+    result.advanced = False
+    return True
+```
+
+Это сохраняет инвариант «никогда не пробрасываем исключение в `advance_stage`»: `failed` —
+структурированный исход, а не throw.
+
+### Р-4. Единый источник кода создания PR (опционально, рекомендуется)
+
+`launcher._ensure_pr` рекомендуется **делегировать** в `merge_gate.ensure_open_pr`, чтобы создание
+PR жило в одном месте и одинаково логировало created/existed/failed (G3). **Поведенческий
+инвариант:** триггер «создавать PR только в developer-пути со свежим коммитом» **НЕ ужесточается**
+(BRD/ТЗ §1) — меняется лишь реализация под капотом, не условие вызова. Это снижает риск
+рассинхрона двух копий логики «выбрать/создать PR». Если делегирование увеличивает диффу/риск —
+допустимо оставить `_ensure_pr` как есть и лишь усилить его логирование (created/existed/failed);
+функциональная цель ORCH-082 достигается врезкой Р-2 независимо.
+
+### Р-5. Kill-switch и область действия
+
+- `merge_verify_autocreate_pr_enabled: bool = True`
+  (env `ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED`) в `src/config.py`, рядом с
+  `merge_verify_enabled`/`regression_guard_enabled`.
+- `False` → ровно прежнее поведение: авто-создания нет, «no open PR» → HOLD как в ORCH-074 (AC-8).
+- Область — `merge_gate.merge_verify_applies(repo)` (self-hosting / `merge_verify_repos`); прочие
+  репо — no-op, создание PR остаётся за прежним механизмом (AC-9). Отдельного `*_repos` для
+  авто-создания НЕ вводим: семантически оно неотделимо от merge-verify, у которого уже есть область.
+
+## Последствия
+
+### Плюсы
+- Закрыт структурный пробел: к merge-verify ветка гарантированно имеет открытый код-PR; ложный
+  HOLD «no open PR» больше не требует ручного вмешательства (AC-2/AC-3).
+- Защита ORCH-073 цела и приоритетна: верификация остаётся **только** `verify_merged_to_main`
+  (SHA-в-main) + `check_main_regression`. Реально невлитый код → HOLD как прежде (AC-4/FR-3).
+- Идемпотентность по факту Gitea (наличие открытого PR), без новой колонки/таблицы — согласуется с
+  restart-safe-моделью merge-verify; повторный заход (reaper/reconciler/re-approve) → `existed`,
+  дублей нет (FR-5/AC-2).
+- Распознаваемые исходы в логах и в HOLD-тексте: created / existed / failed (G3/AC-5).
+- Инварианты сохранены: `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД, `check_deploy_status`,
+  exit-коды хука, merge-gate, image-freshness — не тронуты (AC-10). `main` не push/force-push.
+
+### Минусы / ограничения
+- Auto-создание PR на ребре `deploy → done` означает, что код-PR может появиться **после** того,
+  как все гейты (security/merge-gate/staging/image-freshness) уже пройдены по ветке. Это безопасно
+  по времени (BRD §6 допущение): ревью/гейты валидируют **код ветки**, а PR — лишь механизм
+  слияния; merge-verify исполняется ПОСЛЕ всех гейтов. PR здесь не обходит ревью.
+- При недоступности Gitea задача попадёт в HOLD (как и сегодня) — но теперь с явным текстом
+  «PR создать не удалось» вместо «PR не влит». Это сознательный fail-closed (AC-7): never-raise,
+  честный HOLD, не ложно-зелёный `done`.
+- Небольшое дублирование Gitea-вызовов между `ensure_open_pr` и `merge_pr` (оба GET список PR). Это
+  приемлемо: два независимых leaf-актора с одинаковым фильтром важнее микро-оптимизации; объединять
+  в один вызов — увеличить связность без пользы.
+
+### Влияние на self-hosting
+Изменение строго аддитивно и под kill-switch (`True`). Прод-контейнер не рестартится этой задачей;
+выкат — через staging-гейт (8501) как любая ORCH-задача. На ребре `deploy → done` риск-профиль не
+растёт: при любом сбое — HOLD, не падение `advance_stage`, конвейер всех проектов не встаёт.
+
+## Связанные документы
+- BRD/ТЗ/AC: `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`
+- Тех-риски: `10-tech-risks.md`
+- Глобальный амендмент: [adr-0016](../../../architecture/adr/adr-0016-ensure-open-pr-before-merge-verify.md)
+- Контекст merge-verify: [adr-0013](../../../architecture/adr/adr-0013-merge-verify-gate.md),
+  [adr-0014](../../../architecture/adr/adr-0014-merge-verify-sha-source-of-truth.md)
+- Постмортем фантомного merge: `docs/history/LESSONS_2026-06-08_phantom-merge.md`,
+  runbook `docs/operations/PHANTOM_MERGE_RUNBOOK.md`

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

@@ -0,0 +1,27 @@
+# 10 — Технические риски: ORCH-082 (ORCH-81)
+
+Риски точечной врезки «ensure_open_pr перед merge-verify». Все — в зоне ребра `deploy → done`
+(self-hosting), под kill-switch `merge_verify_autocreate_pr_enabled`.
+
+| ID | Риск | Вероятн. | Влияние | Митигация |
+|----|------|----------|---------|-----------|
+| **R1** | `ensure_open_pr` выбирает/создаёт **не тот** PR (авто-docs-PR `base != main`) → `merge_pr` мержит/верифицирует не тот PR | Сред. | Высокое | Фильтр `head.ref==branch` И `base.ref=="main"`, **идентичный** `merge_pr` (ORCH-073 FR-3). Тест AC-6: ветка с docs-PR (`base!=main`) → актор его игнорирует и создаёт код-PR на `main`. |
+| **R2** | Создание PR **маскирует** реально невлитый код → ложно-зелёный `done` (регресс ORCH-073) | Низк. | Критич. | Верификация остаётся ТОЛЬКО `verify_merged_to_main` (SHA-в-main) + `check_main_regression`; `ensure_open_pr` НЕ влияет на вердикт merge. Регресс-тест AC-4: `verify_merged_to_main→False` ⇒ HOLD, не `done`. |
+| **R3** | Гонка: параллельно создаётся 2 PR → дубль | Низк. | Сред. | Идемпотентность FR-1.3: на ошибку «PR exists»/409/422 — повторный GET → `existed`; PR создаётся только если GET пуст. Тест AC-2. |
+| **R4** | Исключение из `ensure_open_pr` пробрасывается в `advance_stage` → падение перехода | Низк. | Высокое | Контракт never-raise (`except Exception → ("failed", reason)`); врезка обёрнута внешним try/except `_handle_merge_verify`. `failed` → структурированный HOLD, не throw. Тест AC-7. |
+| **R5** | Gitea недоступна на ребре `deploy → done` → задача в HOLD | Низк. | Сред. | Сознательный fail-closed: `failed` → честный HOLD+alert (`_hold_pr_create_failed`), НЕ ложный `done`. Текст HOLD отличим от not-merged (AC-5) — оператор видит причину. Reaper/reconciler/re-approve переиграют, когда Gitea вернётся (FR-5). |
+| **R6** | Оператор не различит HOLD «PR не создан» и HOLD «PR не влит» | Сред. | Низк. | Отдельный helper `_hold_pr_create_failed` с собственным текстом и `result.note="pr-create-failed-hold"` (≠ `merge-not-verified-hold`); лог-строка `ensure_open_pr -> failed: <reason>`. AC-5. |
+| **R7** | Расхождение логики выбора/создания PR между `launcher._ensure_pr` и `merge_gate.ensure_open_pr` | Сред. | Сред. | Рекомендованное делегирование `_ensure_pr → ensure_open_pr` (единый код). Если не делегируем — обе копии используют ОДИН фильтр `head==branch && base==main`; тест на согласованность. |
+| **R8** | Включение по умолчанию (`True`) меняет прод-поведение скрытно | Низк. | Сред. | Поведение строго аддитивно: при наличии PR → `existed`/no-op; меняется лишь ранее-падавший путь «no open PR». Kill-switch `False` → 1:1 ORCH-074 (AC-8). Выкат через staging-гейт (8501). |
+| **R9** | Регресс инвариантов (`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД/exit-коды) | Низк. | Высокое | Под-гейт-врезка в `advance_stage`, НЕ новый `QG_CHECKS`-элемент и НЕ новая стадия; БД не трогается (идемпотентность из Gitea). Тест AC-10 + полный `pytest`. |
+
+## Зоны без изменений (подтверждение границ)
+- **Инфраструктура/топология** — без изменений → `07-infra-requirements.md` не требуется.
+- **Схема БД** — без изменений (идемпотентность выводится из Gitea) → `08-data-requirements.md`
+  не требуется.
+- `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_deploy_status`/`_parse_deploy_status`, exit-коды хука,
+  merge-gate (ORCH-043), image-freshness (ORCH-058), terminal-sync — не тронуты.
+
+## Главный архитектурный приоритет
+При любом конфликте «создать PR» **проигрывает** «не дать ложно-зелёный `done`» (защита ORCH-073).
+Создание PR — страховка инварианта ДО merge_pr, никогда не подмена верификации merge.

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

@@ -0,0 +1,65 @@
+---
+type: review
+work_item_id: ORCH-082
+verdict: APPROVED
+version: 1
+---
+
+# Review ORCH-082 — Гарантированный идемпотентный код-PR перед merge-verify
+
+## Summary
+Изменение закрывает отсутствующий инвариант «к моменту merge-verify у ветки есть открытый
+код-PR» (root cause ложного HOLD «no open PR» на деплое ORCH-074). Реализовано строго аддитивно,
+по дизайну ADR-001: новый идемпотентный leaf-актор `merge_gate.ensure_open_pr`, точечная врезка в
+`stage_engine._handle_merge_verify` ПЕРЕД `merge_pr`, distinguishable HOLD-helper
+`_hold_pr_create_failed`, делегирование `launcher._ensure_pr` в единый актор, kill-switch
+`merge_verify_autocreate_pr_enabled`. Защита ORCH-073 (SHA-в-main + регресс-гард) не ослаблена и
+остаётся приоритетной. Машина стадий, `QG_CHECKS`, схема БД, контракты деплоя — не тронуты.
+
+Все 4 оси проверки пройдены:
+- **ТЗ (02-trz.md):** FR-1..FR-5 реализованы — идемпотентный актор с фильтром
+  `head==branch & base=="main"`, врезка после `validated_revision` и до `merge_pr`, честный HOLD
+  на `failed`, защита ORCH-073 цела, идемпотентность повторного прохода.
+- **AC (03-acceptance-criteria.md):** AC-1..AC-11 покрыты. Root cause задокументирован в ADR
+  (R-A структурный + R-C проксимальный для ORCH-074); идемпотентность/existed (TC-02, TC-05);
+  autocreate до merge_pr (TC-06); защита ORCH-073 (TC-07); логи различают исход (TC-12); фильтр
+  base==main (TC-03); never-raise (TC-04, TC-08); kill-switch off (TC-09); условность non-self
+  (TC-10); инварианты + документация; pytest зелёный.
+- **ADR:** реализация 1:1 соответствует Р-1..Р-5 ADR-001; не нарушает глобальные adr-0013/0014
+  (амендмент adr-0016 корректно зарегистрирован).
+- **Качество кода:** never-raise соблюдён (все внешние вызовы в try/except), docstrings на
+  публичных функциях, тесты содержательные (мок Gitea HTTP + интеграционные на под-гейт, не
+  тривиальные). Секреты не хардкодятся (token из settings). `main` не push/force-push.
+
+`pytest tests/ -q` → **1046 passed**. Целевые наборы (`test_orch082_ensure_pr.py`,
+`test_orch082_merge_verify_autocreate.py`, `test_merge_verify.py`) — зелёные.
+
+## Findings
+
+### P0 — Blocker
+- нет
+
+### P1 — Must fix
+- нет
+
+### P2 — Should fix
+- нет
+
+### P3 — Nice-to-have
+- [ ] Поведенческое уточнение `launcher._ensure_pr`: после делегирования в `ensure_open_pr`
+  developer-путь теперь требует `base=="main"` (раньше принимался любой открытый PR с
+  `head==branch`). Это корректное усиление (выравнивание с `merge_pr`) и для штатного потока
+  PR всегда создаётся на `main` — регресса нет; зафиксировано для истории, действий не требует.
+
+## Документация
+Документация обновлена в том же PR — соответствие правилу №2/№6 CLAUDE.md:
+- `docs/architecture/README.md` — добавлен раздел ORCH-082 в блок merge-verify (строки 209-240).
+- `CHANGELOG.md` — запись в `## [Unreleased]`.
+- `.env.example` — `ORCH_MERGE_VERIFY_AUTOCREATE_PR_ENABLED=true` + комментарий.
+- `docs/architecture/adr/adr-0016-ensure-open-pr-before-merge-verify.md` — сквозной ADR (амендмент
+  adr-0013/0014), зарегистрирован в `docs/architecture/adr/README.md` (макс. номер → 0016).
+- `docs/work-items/ORCH-082/06-adr/ADR-001-*.md` — детальный ADR (root cause + дизайн).
+- API сервиса не менялось (новых endpoint нет), конфиг-флаг отражён в `.env.example`. Все
+  изменения `src/` (merge_gate, stage_engine, launcher, config) задокументированы.
+
+**Вердикт: APPROVED** — P0/P1 отсутствуют, документация обновлена, тесты зелёные.

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

@@ -0,0 +1,81 @@
+---
+type: test-report
+work_item_id: ORCH-082
+result: PASS
+---
+
+# Test Report — ORCH-082
+
+Гарантированный идемпотентный код-PR перед merge-verify (фикс ложного HOLD «no open PR»).
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Ветка: feature/ORCH-082-orch-81-pr-merge-verify-hold
+- Дата: 2026-06-09
+- Review verdict: APPROVED (12-review.md, P0/P1 отсутствуют)
+
+## Проверка окружения
+- `GET /health` → `{"status":"ok","service":"orchestrator"}` — прод-контейнер 8500 жив.
+- Тесты прогнаны в worktree ветки (прод не затронут, деструктивных операций нет).
+
+## Smoke test API (prod 8500)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | `{"status":"ok"}` — OK |
+| `GET /status` | OK — ORCH-082 (id=61) виден на стадии `testing` |
+| `GET /queue` | OK — `running:1, queued:0`, breaker `closed`, reconcile/reaper/post_deploy активны |
+
+## Результаты (привязка к 04-test-plan.yaml)
+
+| TC ID | Тип | Описание | Тест | Результат |
+|-------|-----|----------|------|-----------|
+| TC-01 | unit | ensure_open_pr: PR нет → POST создаёт → ('created', N); фильтр base==main | test_tc01_creates_pr_when_absent | PASS |
+| TC-02 | unit | PR head==branch И base==main уже есть → ('existed', N), POST не вызывается | test_tc02_existed_no_duplicate | PASS |
+| TC-03 | unit | Мульти-PR: только docs-PR (base!=main) → создаётся PR на main (AC-6) | test_tc03_docs_pr_not_counted_creates_on_main | PASS |
+| TC-04 | unit | never-raise: GET/POST кидает ошибку → ('failed', reason), не всплывает (AC-7) | test_tc04_never_raise_on_get_error / _on_post_error / _failed_when_post_non_2xx | PASS (3) |
+| TC-05 | unit | Гонка: POST 'PR exists' (409/422) → повторный GET → ('existed', N), без дубля | test_tc05_race_post_conflict_confirms_existing[409,422] | PASS (2) |
+| TC-06 | integration | PR отсутствовал → ensure создаёт → merge_pr → verify True → done без HOLD (AC-3) | test_tc06_autocreate_then_merge_then_done | PASS |
+| TC-07 | integration | Регресс ORCH-073: verify=False → HOLD + set_issue_blocked, НЕ done, без отката (AC-4) | test_tc07_verify_false_still_holds | PASS |
+| TC-08 | integration | ensure → 'failed' (Gitea down) → честный HOLD+alert, текст ≠ 'not merged' (AC-7) | test_tc08_ensure_failed_holds_distinct | PASS |
+| TC-09 | integration | Kill-switch off → ensure не вызывается, 'no open PR' → прежний HOLD 1:1 (AC-8) | test_tc09_killswitch_off_no_autocreate | PASS |
+| TC-10 | integration | Условность: non-self репо (applies=False) → no-op, авто-создание не выполняется (AC-9) | test_tc10_non_self_repo_noop | PASS |
+| TC-11 | integration | Идемпотентный повторный проход: PR existed, already-merged → verify True → done (FR-5) | test_tc11_idempotent_redrive | PASS |
+| TC-12 | unit | Логи различают created/existed/failed; HOLD create-failed ≠ HOLD not-merged (AC-5) | test_tc12_logs_distinguish_outcomes | PASS |
+| TC-13 | integration | Happy-path ORCH-071/073 не изменён: verify True → done, merged_to_main: true | test_merge_verify.py (verify_true_when_sha_is_ancestor + 7 регресс-тестов) | PASS |
+
+Все 13 TC из тест-плана покрыты и зелёные.
+
+## Сопоставление с критериями приёмки (03-acceptance-criteria.md)
+- **AC-1** Root cause в ADR-001 (R-A структурный + R-C для ORCH-074) — подтверждено review.
+- **AC-2** Идемпотентный код-PR, без дублей — TC-02, TC-05, TC-11 — PASS.
+- **AC-3** Авто-создание PR ПЕРЕД merge_pr — TC-06 — PASS.
+- **AC-4** Защита ORCH-073 цела (verify=False → HOLD, не done) — TC-07 + test_merge_verify — PASS.
+- **AC-5** Логи различают исход PR — TC-12 — PASS.
+- **AC-6** Фильтр base==main (docs-PR не код-PR) — TC-03 — PASS.
+- **AC-7** Never-raise + честный HOLD при недоступности Gitea — TC-04, TC-08 — PASS.
+- **AC-8** Kill-switch off → поведение 1:1 — TC-09 — PASS.
+- **AC-9** Условность self-hosting — TC-10 — PASS.
+- **AC-10** Инварианты не нарушены, документация обновлена — подтверждено review (README/CHANGELOG/.env.example/ADR).
+- **AC-11** pytest зелёный — **1046 passed** — PASS.
+
+## Вывод pytest
+
+Полный прогон:
+```
+1046 passed, 1 warning in 25.57s
+```
+(единственный warning — PydanticDeprecatedSince20 в src/config.py:5, не относится к ORCH-082, предсуществующий.)
+
+Целевые наборы:
+```
+tests/test_orch082_ensure_pr.py ............ (8 passed)
+tests/test_orch082_merge_verify_autocreate.py ....... (7 passed)
+tests/test_merge_verify.py ........ (8 passed)
+======================== 23 passed, 1 warning in 0.42s =========================
+```
+
+## Итог
+**PASS** — все 1046 тестов зелёные, целевые наборы ORCH-082 + регресс merge-verify зелёные,
+smoke API (health/status/queue) OK, все 13 TC и AC-1..AC-11 покрыты. Задача готова к переходу
+на стадию `deploy-staging`.

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

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

@@ -0,0 +1,49 @@
+---
+staging_status: SUCCESS
+timestamp: 2026-06-08T21:55:49Z
+base_url: http://localhost:8501
+---
+
+# Staging Gate Log
+
+Staging test suite completed against the live staging environment (`orchestrator-staging`, port 8501),
+run inside the container per the canonical method (ORCH-048, ADR-001):
+
+```
+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 failed (waived per ORCH-061): C9a, C9b
+
+All REAL pipeline checks (Block A SMOKE, Block B ACCESS, C7/C8) passed. The only failures are the
+two infra-only sandbox checks (C9a branch-in-sandbox / C9b analyst-job-enqueued), which depend on
+SANDBOX bot accounts being members of the sandbox project — not on the pipeline. Tolerance is enabled
+(`staging_infra_tolerance_enabled=True`), so these are waived and the script exits 0 (fail-closed for
+any REAL failure remains intact).
+
+```
+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 …', 'C9b …'] are known sandbox-infra checks; all real checks green
+```
+
+### Block-by-block summary
+
+| Block | Check | Result |
+|-------|-------|--------|
+| A | A1 GET /health → 200 status=ok | ✓ PASS |
+| A | A2 GET /queue → 200 with counts/max_concurrency/resilience | ✓ PASS |
+| A | A3 ORCH_STAGING=true (not prod) | ✓ PASS |
+| B | B4 Plane: sandbox project accessible | ✓ PASS |
+| B | B5 Gitea: orchestrator-sandbox accessible, push=true | ✓ PASS |
+| B | B6 Registry: sandbox present, prod ET/ORCH absent | ✓ PASS |
+| C | C7 Create issue in Plane SANDBOX | ✓ PASS |
+| C | C8 Trigger pipeline via /webhook/plane | ✓ PASS |
+| C | C9a Branch appears in orchestrator-sandbox | ✗ FAIL (sandbox-infra, waived) |
+| C | C9b Analyst job enqueued in staging queue | ✗ FAIL (sandbox-infra, waived) |
+
+Cleanup completed: test Plane issue deleted (HTTP 204); no branch created to delete.

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

@@ -0,0 +1,7 @@
+# Business Request: ORCH-86: reconciler шлёт в Telegram «ET-002 done разблокирована (потерян webhook)» периодически
+
+Work Item ID: ORCH-086
+
+## Description
+
+TBD

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

@@ -0,0 +1,70 @@
+# 01-BRD — ORCH-086: reconciler шлёт ложное «ET-002 done разблокирована»
+
+Work Item: **ORCH-086**
+Тип: **Багфикс** (шум уведомлений / остаток livelock)
+Приоритет: **MEDIUM**
+Зона: `src/reconciler.py`
+Связано: продолжение **ORCH-068** (тот фикс задеплоен, но НЕ закрыл этот путь), наследует контракты **ORCH-053 / ORCH-060 / ORCH-066**.
+
+## 1. Контекст / проблема
+В Telegram периодически (а особенно сразу после рестарта оркестратора) прилетает уведомление:
+
+> 🔧 reconciler: ET-002 done разблокирована (потерян webhook)
+
+Это **ложный шум**: задача `ET-002` (проект enduro-trails) давно завершена, реально ничего не разблокируется. Уведомление вводит наблюдателя в заблуждение (создаёт впечатление, что конвейер чинит застрявшую задачу, хотя ничего не происходит).
+
+ORCH-068 уже починил аналогичный livelock на **F-2 (plane-side)**: добавил per-issue терминал-исключение (`_is_terminal_state`, группа Plane `completed`/`cancelled`) и in-memory dedup-guard по `issue_id→state_uuid`. Однако эти две защиты **не покрывают путь F-1 (gate-side)**.
+
+## 2. Диагностика (код-аудит, golden source — текущий `src/reconciler.py`)
+
+Уведомление отправляет `Reconciler._note_unblock()` (`reconciler.py` ~стр.444) через `send_telegram()` при `settings.reconcile_notify_unblock=True`.
+
+Два механизма ORCH-068, которые ДОЛЖНЫ были его подавить, на пути F-1 не работают:
+
+1. **Dedup-guard не срабатывает.** Guard ключуется по `state_uuid` и активен только когда `state_uuid is not None` (`_note_unblock`, стр.459–463). Но вызов в F-1 (`_reconcile_gate_task`, стр.228):
+   ```python
+   self._note_unblock(task.get("work_item_id") or str(task_id), stage)
+   ```
+   передаёт **только 2 аргумента, БЕЗ `state_uuid`** → ветка dedup пропускается → уведомление шлётся при каждом релевантном тике/старте. (В отличие от F-2, где все 4 вызова `_note_unblock` передают `state_uuid` — стр.394/400/407/416.)
+
+2. **Терминал-скип не ловит этот путь.** Терминал-исключение ORCH-068 (`_is_terminal_state`, стр.327–344) вызывается **только в F-2** (`_reconcile_plane_issue`, стр.362). В F-1 единственный «терминал-фильтр» — это `get_active_tasks_for_reconcile()` (`db.py` стр.193: `WHERE stage != 'done'`), который смотрит **только на стадию задачи в БД оркестратора** и НЕ знает о статусе задачи в Plane (группа `completed`/`cancelled`). Поэтому задача, которая в БД оркестратора стоит на НЕ-`done` стадии (дрейф), а в Plane уже `Done`, проходит фильтр.
+
+### Почему `advance_if_gate_passed` считает ET-002 «продвинувшейся» (G1 — гипотеза, требует подтверждения в development)
+Для enduro-trails (не self-hosting) условные гейты (`check_staging_status`, `check_deploy_status`, merge-gate, image-freshness, security-gate, merge-verify) — **no-op `(True, ...)`** (условность ORCH-35/43/58/71). Поэтому для enduro-задачи, чья стадия в БД оркестратора НЕ `done`, но застряла перед терминалом (например `deploy`), `advance_if_gate_passed` находит гейт зелёным (no-op) → вызывает `advance_stage(..., finished_agent=None)` → возвращает `result.advanced=True` (стр.227) → доходит до `_note_unblock`. Guard 2 (`_is_blocked_or_needs_input`, стр.230) задачу не спасает: его `skip_set` = `{blocked, needs_input, extra_waits}` и **НЕ содержит `done`/`cancelled`** → терминальная-в-Plane задача через него проходит. «Периодичность / при старте» объясняется отсутствием dedup (state_uuid не передан) + чистым in-memory состоянием нового процесса после рестарта (первый проход снова находит задачу).
+
+> **Открытый вопрос для G1 (подтвердить в development по prod-БД/логам):** точная стадия `ET-002` в БД оркестратора в момент срабатывания (в quoted-сообщении фигурирует слово «done», но `get_active_tasks_for_reconcile` исключает `stage='done'` — значит стадия в БД иная либо аномальная). Фикс обязан быть **робастным независимо** от точной стадии: терминальность определяется по группе статуса Plane (как `_is_terminal_state`), а не по строковому совпадению стадии.
+
+## 3. Бизнес-цели
+- **G1.** Установить и задокументировать, почему F-1 (`advance_if_gate_passed`) доводит терминальную в Plane задачу (ET-002) до `_note_unblock` на каждом релевантном тике/старте.
+- **G2.** Не слать unblock-уведомление для задач, УЖЕ терминальных (`done`/`cancelled`) в Plane (по группе статуса) и/или в оркестраторе — распространить терминал-скип ORCH-068 на путь F-1 (стр.228), а не только на F-2.
+- **G3.** Передавать `state_uuid` в `_note_unblock` на **всех** путях (включая F-1) → in-memory dedup-guard работает везде (страховка от повтора, даже если терминал-скип когда-то не сработает).
+
+## 4. Объём (Scope)
+**В объёме:**
+- Точечная правка `src/reconciler.py`: терминал-скип на пути F-1 + проброс `state_uuid` в `_note_unblock` из F-1.
+- Сохранение/корректное инкрементирование наблюдаемости ORCH-068 (`skipped_terminal_total`, `deduped_total`, `unblocked_total`).
+- Unit-тесты, покрывающие AC-1…AC-5.
+- Обновление документации (`docs/architecture/README.md` блок Reconciler, `CHANGELOG.md`).
+
+**Вне объёма (Не-цели):**
+- НЕ ломать легитимный replay реально застрявшей задачи (когда реконсиляция её ДЕЙСТВИТЕЛЬНО двигает — уведомление полезно).
+- НЕ трогать пайплайн / статусы enduro-trails.
+- НЕ отключать `reconcile_notify_unblock` глобально (потеряем полезные алерты) — подавление **точечное**, только для терминальных.
+- НЕ менять `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, схему БД, контракты `advance_stage` / `advance_if_gate_passed`.
+- НЕ менять поведение F-2 (там ORCH-068 уже корректен) сверх необходимого переиспользования хелперов.
+
+## 5. Заинтересованные лица
+- **Owner / Слава** — наблюдатель Telegram-карточек и алертов; страдающая сторона (шум).
+- **enduro-trails** — проект, чьи терминальные задачи генерируют ложные алерты; пайплайн не должен быть затронут.
+- **orchestrator (self-hosting)** — терминал-детект должен корректно работать и для self (разные наборы Plane-статусов).
+
+## 6. Риски и ограничения
+- **R1 (грабли мультипроектности).** enduro-trails и orchestrator — разные проекты с разными наборами Plane-статусов. Терминал-детект ОБЯЗАН работать для обоих: первичный дискриминатор — группа статуса Plane (`completed`/`cancelled`, project-independent), fallback — логические ключи `done`/`cancelled` (как в существующем `_is_terminal_state`, стр.338–344).
+- **R2 (наблюдаемость).** Нельзя сломать счётчики ORCH-068. При скипе терминальной задачи в F-1 — инкрементировать `skipped_terminal_total` (единая семантика с F-2). `deduped_total`/`unblocked_total` — без регрессии.
+- **R3 (never-raise).** Тик реконсилятора обязан оставаться never-raise (сеть Plane может быть недоступна). Сбой терминал-проверки → консервативное поведение (как Guard 2: при ошибке скорее НЕ слать, чем слать ложно; но НЕ ценой подавления легитимного unblock — см. AC-4).
+- **R4 (доп. сетевой вызов).** F-1 для проброса `state_uuid` и терминал-детекта должен знать текущий Plane-статус issue. Guard 2 (`_is_blocked_or_needs_input`) уже делает `fetch_issue_state`. Желательно переиспользовать один fetch, не удваивая обращения к Plane API на тик (производительность горячего цикла).
+- **R5 (ложно-отрицательный риск).** Слишком агрессивное подавление может задушить полезный алерт о реально застрявшей задаче → обязателен регресс-тест AC-4.
+
+## 7. Метрика успеха
+- В Telegram больше нет периодического «ET-002 done разблокирована»; `skipped_terminal_total` растёт (наблюдаемо в `GET /queue`).
+- `pytest tests/ -q` зелёный; новые тесты AC-1…AC-5 проходят.