# 03 — Критерии приёмки: ORCH-059

Repo: `orchestrator` · Stage: analysis
Каждый критерий — однозначный PASS/FAIL. Проверка: unit/integration (см.
`04-test-plan.yaml`) + ручная верификация для инфра-предусловий.

## AC-1 — Статус «Confirm Deploy» резолвится
**Given** проект ORCH со статусом доски «Confirm Deploy»
**When** вызывается резолвер состояний для проекта ORCH
**Then** возвращается логический ключ `confirm_deploy` с непустым UUID,
а маппинг `"Confirm Deploy" → "confirm_deploy"` присутствует в `_PLANE_NAME_TO_KEY`.
**FAIL:** ключ отсутствует или указывает на UUID статуса `Approved`.

## AC-2 — «Confirm Deploy» на стадии `deploy` запускает Фазу B
**Given** задача self-hosting (`orchestrator`) на стадии `deploy`,
`deploy_require_manual_approve=true`, маркер `initiated` отсутствует
**When** приходит `work_item.updated` со статусом `Confirm Deploy`
**Then** инициируется Фаза B: вызывается `self_deploy.initiate_deploy`,
ставится job `deploy-finalizer`, пишется маркер `initiated`.
**FAIL:** прод-деплой не инициирован, либо finalizer не поставлен.

## AC-3 — «Approved» на стадии `deploy` НЕ запускает прод-деплой
**Given** та же задача на стадии `deploy`
**When** приходит `work_item.updated` со статусом `Approved`
**Then** `self_deploy.initiate_deploy` **НЕ** вызывается; Фаза B не стартует;
задача не откатывается (БАГ-8 не срабатывает) и не «доходит» по
`check_deploy_status` (вердикта нет); событие залогировано как no-op.
**FAIL:** вызван `initiate_deploy`, либо произошёл откат/ложный advance.

## AC-4 — «Approved» на `analysis` работает без регрессии
**Given** задача на стадии `analysis` (BRD готов, approval-pending)
**When** issue переводится в `Approved`
**Then** срабатывает approved-via-status и задача продвигается
`analysis → architecture` (как до правки).
**FAIL:** approve на analysis перестал продвигать конвейер.

## AC-5 — Идемпотентность Фазы B по «Confirm Deploy»
**Given** задача на `deploy`, маркер `initiated` уже существует
**When** повторно приходит статус `Confirm Deploy` (двойной клик / дубль webhook)
**Then** повторного `initiate_deploy` не происходит (no-op,
`self-deploy-already-initiated`).
**FAIL:** прод-деплой запускается повторно.

## AC-6 — CTA Фазы A просит «Confirm Deploy»
**Given** Фаза A (`deploy-staging → deploy`, approval-pending)
**When** формируются Plane-комментарий и Telegram-уведомление запроса approve
**Then** текст инструктирует перевести задачу в статус **`Confirm Deploy`**
(а не «Approved») для запуска прод-деплоя.
**FAIL:** CTA по-прежнему упоминает только «Approved».

## AC-7 — Fail-closed при отсутствии статуса
**Given** среда без статуса «Confirm Deploy» (enduro / fallback `_DEFAULT_STATES`
/ недоступный Plane API)
**When** обрабатывается `work_item.updated`
**Then** webhook-путь не выбрасывает исключение; ветка confirm-deploy не
активируется (прод-деплой не запускается «вслепую»).
**FAIL:** `KeyError`/исключение в обработчике, либо ложный запуск Фазы B.

## AC-8 — Условность для не-self репозиториев
**Given** не-self репозиторий (`self_deploy_applies(repo) == False`)
**When** приходит любой verdict-статус на стадии `deploy`
**Then** поведение прод-деплоя не меняется относительно текущего (синхронный
деплой агентом); статус `Confirm Deploy` не требуется.
**FAIL:** изменилось поведение деплоя не-self проекта.

## AC-9 — Инварианты не нарушены
**Then** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_deploy_status`/
`_parse_deploy_status`, контракт exit-кодов хука (0/1/2), Фазы A/C, merge-gate,
схема БД — без изменений; `pytest tests/ -q` зелёный.
**FAIL:** изменён любой из перечисленных контрактов или красные тесты.

## AC-10 — Документация обновлена (golden source)
**Then** в том же PR обновлены `CLAUDE.md`, секция ORCH-036 в
`docs/architecture/README.md`, `CHANGELOG.md`; заведён
`06-adr/ADR-001-confirm-deploy-status.md`.
**FAIL:** функционал изменён, документация — нет (Reviewer → REQUEST_CHANGES).