# 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:** любой тест падает.
