# Критерии приёмки — ORCH-36: Исполняемый самодеплой (Вариант B)

Work Item: ORCH-036
Stage: analysis
Автор: analyst
Дата: 2026-06-06

Формат: каждый критерий — проверяемое условие PASS/FAIL. Отладка и проверки
выполняются на **staging-цели хука** (8501); реальный прод (8500) — только после approve.

---

## AC-1. Стадия deploy исполняет реальный деплой (не бумажный)
- **PASS:** на стадии `deploy` (после зелёного `deploy-staging`) вызывается хост-хук,
  который реально перетегирует образ, рестартит целевой сервис и выполняет health-check;
  `deploy_status` отражает РЕАЛЬНЫЙ исход хука.
- **FAIL:** `deploy_status: SUCCESS` пишется без фактического рестарта/health (бумажный лог).
- **Проверка:** прогон на staging-цели хука; в логе хука видны retag + `up -d` + health-loop;
  exit-code хука соответствует записанному `deploy_status`.

## AC-2. Self-репо: рестарт 8500 — внешним detached-процессом, агент себя не убивает
- **PASS:** для `orchestrator` рестарт 8500 выполняет процесс ВНЕ контейнера агента; deployer-агент
  завершается штатно (exit 0), его процесс не убит рестартом контейнера.
- **FAIL:** deployer синхронно делает `docker compose up -d orchestrator` из контейнера и/или
  агент падает/обрывается на середине из-за рестарта собственного контейнера.
- **Проверка:** симуляция на staging-цели; убедиться, что detached-процесс переживает выход агента.

## AC-3. deploy_status маппится из exit-code хука
- **PASS:** exit-code хука 0 → `deploy_status: SUCCESS`; exit-code ≠ 0 (1/2) → `deploy_status: FAILED`.
- **FAIL:** любой иной маппинг (например SUCCESS при exit 1).
- **Проверка:** unit-тест маппинга exit-code → вердикт; интеграционный прогон с искусственным
  кодом возврата хука.

## AC-4. Провал деплоя → откат на development
- **PASS:** при `deploy_status: FAILED` задача откатывается `deploy → development`
  (`set_issue_blocked`, Plane+Telegram), как в существующей ветке БАГ-8.
- **FAIL:** при FAILED задача уходит в `done` или зависает.
- **Проверка:** существующий контракт `stage_engine._handle_qg_failure_rollbacks` для
  `deployer`+`check_deploy_status` сохранён и срабатывает.

## AC-5. Ручной approve обязателен и реально тормозит прод
- **PASS:** при `DEPLOY_REQUIRE_MANUAL_APPROVE=true` прод-хук НЕ вызывается до явного «go»;
  после «go» — вызывается.
- **FAIL:** прод-хук дёргается без approve.
- **Проверка:** прогон без «go» — целевой сервис НЕ перезапущен (нет записи рестарта в логе хука,
  не сменился uptime/контейнер); прогон с «go» — рестарт состоялся.

## AC-6. Уведомления о каждом промоуте и откате
- **PASS:** на старт/успех прод-деплоя и на откат приходят и Plane-коммент в задачу, и Telegram.
- **FAIL:** хотя бы один промоут/откат прошёл «молчаливо».
- **Проверка:** в Plane-задаче и в Telegram-чате присутствуют сообщения для каждого исхода.

## AC-7. Build-once: в прод идёт образ, прошедший staging
- **PASS:** прод-деплой использует тот же образ, что прошёл staging-гейт (retag + `--no-build`),
  без пересборки.
- **FAIL:** прод-деплой пересобирает образ заново (артефакт может отличаться от протестированного).
- **Проверка:** sha/тег образа прод == образ, валидированный на staging; в логе нет `build`.

## AC-8. Staging-гейт остаётся обязательным предусловием
- **PASS:** прод-деплой недостижим без зелёного `check_staging_status` (`staging_status: SUCCESS`).
- **FAIL:** прод-хук можно вызвать при FAILED/отсутствующем staging-вердикте.
- **Проверка:** при `staging_status: FAILED` задача откатывается на development, до `deploy` не доходит.

## AC-9. Авто-rollback восстанавливает прод (симуляция битого деплоя)
- **PASS:** при симуляции битого деплоя на staging-цели health не проходит → хук авто-откатывает
  на предыдущий образ → сервис снова healthy; exit-code = 1 (rolled back); MTTR < 60с.
- **FAIL:** сервис остаётся нерабочим после провала деплоя.
- **Проверка:** искусственно сломать health, прогнать хук, убедиться в восстановлении и exit 1.

## AC-10. Существующие инварианты не сломаны
- **PASS:** не изменены контракты `check_deploy_status` / `_parse_deploy_status`,
  `STAGE_TRANSITIONS`, terminal-sync `deploy → done`, merge-gate (ORCH-43), rollback БАГ-8.
- **FAIL:** любой из перечисленных контрактов изменён/сломан.
- **Проверка:** существующие тесты deploy/staging/merge-gate зелёные; регресс-прогон `pytest tests/`.

## AC-11. Условность по репо (не-self не ломается)
- **PASS:** для не-self репо (enduro-trails) деплой идёт прежним ssh-путём; self-логика (detached,
  approve, 8500) применяется только для `orchestrator`.
- **FAIL:** не-self репо затронуты self-специфичной логикой и ломаются.
- **Проверка:** `is_self_hosting_repo` корректно разводит пути; тест на не-self репо.

## AC-12. Флаг полного авто НЕ выключен в этой задаче
- **PASS:** `DEPLOY_REQUIRE_MANUAL_APPROVE` остаётся `true`; переключение в `false` не делается.
- **FAIL:** флаг выставлен в `false` в рамках задачи.
- **Проверка:** дефолт конфигурации = `true`; в коде/`.env.example` нет принудительного `false`.

## AC-13. Документация обновлена (golden source)
- **PASS:** обновлены `deployer.md` (стадия deploy = вызов хука), `INFRA.md` (процедура),
  `CHANGELOG.md`; заведён ADR в `06-adr/`.
- **FAIL:** функционал изменён, документация — нет (Reviewer обязан вернуть REQUEST_CHANGES).
- **Проверка:** диффы документации присутствуют в том же PR.

---

## Definition of Done
Все AC-1…AC-13 в статусе PASS; `pytest tests/` зелёный; артефакты pipeline на месте;
прод (8500) во время разработки НЕ тронут (вся проверка — на staging-цели хука).