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

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