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