5.4 KiB
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).