architect(ET): auto-commit from architect run_id=408

docs/architecture/README.md

@@ -206,6 +206,39 @@ merge-в-main вообще**. Detached host-деплой лишь retag'ал о
 `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
 в момент рестарта (~60с). Класс «зелёный деплой, красный прод» (прецедент ET-8 —