9.4 KiB
03 — Критерии приёмки: Авто-режим по лейблам (ORCH-089)
Каждый критерий — чёткое условие PASS/FAIL. Маппинг на BR (01-brd.md) и AC
бизнес-запроса указан в скобках.
AC-1 — autoApprove проходит гейт BRD (BR-1 / BizAC-1)
Дано: задача с лейблом autoApprove, analyst успешно завершился (артефакты
BRD/TRZ/AC/test-plan на месте), auto_label_enabled=True, репо в scope.
Когда: срабатывает _handle_analysis_approved_flow (ветка files_ok).
Тогда:
- задача автоматически переходит
analysis → architectureбез человеческого Approved; - Plane-статус выставлен в
Approved(индикация); - клок
brd_review_ended_atзакрыт (mark_brd_review_ended); - авто-проход залогирован + Telegram/карточка/Plane-коммент уведомляют о факте.
PASS: стадия задачи стала architecture без внешнего webhook Approved; клок закрыт.
FAIL: задача осталась в In Review/analysis ИЛИ advance прошёл без индикации/лога.
AC-2 — autoDeploy триггерит прод-деплой (BR-2 / BizAC-2)
Дано: задача с лейблом autoDeploy дошла до ребра deploy-staging → deploy,
все тех-гейты (security, merge-gate, image-freshness, staging) зелёные, Phase A advance
на deploy выполнен, auto_label_enabled=True, репо в scope (self-hosting).
Когда: срабатывает _handle_self_deploy_phase_a.
Тогда:
- Phase B (
_handle_self_deploy_phase_b) инициируется автоматически, без ручногоConfirm Deploy; - маркер
INITIATEDвыставлен (идемпотентность), finalizer-job (Phase C) поставлен; - Plane-статус →
Deploying; авто-проход залогирован + Telegram/Plane-коммент.
PASS: прод-деплой инициирован без статуса Confirm Deploy от человека; Phase C армлен.
FAIL: задача застряла в Awaiting Deploy, ожидая ручного Confirm Deploy.
AC-3 — оба лейбла → полная автономность (BR-3 / BizAC-3)
Дано: задача с лейблами autoApprove И autoDeploy, все тех-гейты по пути зелёные.
Когда: задача проходит конвейер analysis → … → deploy.
Тогда: задача проходит от анализа до прод-деплоя без единого ручного клика
(ни Approved, ни Confirm Deploy).
PASS: ноль человеческих гейт-кликов; задача достигла deploy/done автономно.
FAIL: конвейер остановился хотя бы на одном из двух человеческих гейтов.
AC-4 — без лейблов поведение НЕ меняется (BR-4 / BizAC-4)
Дано: задача без лейблов autoApprove/autoDeploy.
Когда: проходит гейты BRD и деплоя.
Тогда: оба гейта остаются ручными — задача ждёт In Review → Approved (человек) и
Awaiting Deploy → Confirm Deploy (человек), ровно как до ORCH-089.
PASS: на гейте BRD задача в In Review ждёт человека; на гейте деплоя — в
Awaiting Deploy ждёт человека. Нулевая регрессия.
FAIL: задача без лейблов авто-прошла любой гейт.
AC-5 — красный тех-гейт блокирует авто-режим (BR-5 / BizAC-5)
Дано: задача с лейблом autoDeploy, но один из тех-гейтов на ребре
deploy-staging → deploy красный (например, staging unhealthy / merge-gate конфликт /
security FAIL / image-freshness mismatch).
Когда: конвейер достигает ребра деплоя.
Тогда: Phase A НЕ достигается (под-гейт завернул задачу) → autoDeploy НЕ
инициирует Phase B; задача откатывается/встаёт ровно как при ручном режиме.
PASS: при красном тех-гейте прод-деплой НЕ инициирован, несмотря на лейбл; поведение тождественно ручному режиму при том же провале. FAIL: autoDeploy инициировал прод-деплой при красном тех-гейте.
Аналогично для autoApprove: при отсутствии артефактов (
check_analysis_completeFAIL) авто-аппрув не срабатывает (нет advance), задача не уходит на architecture.
AC-6 — fail-safe к ручному гейту (BR-6 / BizAC-6)
Дано: одно из: лейбл не распознан; Plane API недоступен при чтении лейблов; неоднозначное сопоставление имени; исключение в логике авто-режима. Когда: гейт BRD или деплоя. Тогда: авто-режим НЕ срабатывает → откат к ручному гейту (задача ждёт человека); конвейер НЕ падает.
PASS: при ошибке/неоднозначности задача переходит в ручное ожидание (никогда не авто-проход по ошибке); ни одно исключение не всплывает наружу (never-raise). FAIL: ошибка чтения лейблов привела к авто-проходу ИЛИ к падению/застреванию конвейера.
AC-7 — прозрачность каждого авто-прохода (BR-7 / BizAC-7)
Дано: любой сработавший авто-проход (autoApprove или autoDeploy). Когда: гейт пройден автоматически. Тогда: факт виден в: (а) логе с причиной (label X → действие); (б) Telegram + live-карточке задачи; (в) Plane-комменте.
PASS: все три канала несут отметку об авто-проходе и о том, какой лейбл его разрешил. FAIL: авто-проход произошёл «молча» (нет отметки хотя бы в одном из обязательных каналов: лог + Telegram/карточка + Plane).
AC-8 — kill-switch и scope (BR-9 / BR-10)
Дано: auto_label_enabled=False (или репо вне auto_label_repos).
Когда: задача с лейблами проходит гейты.
Тогда: авто-режим полностью отключён — оба гейта ручные, никаких новых сетевых
вызовов на гейтах; поведение 1:1 как до ORCH-089 (включая нулевую регрессию для enduro).
PASS: при выключенном флаге лейблы игнорируются, поведение прежнее.
FAIL: при False авто-режим сработал ИЛИ появилась регрессия для не-scope репо.
AC-9 — независимость лейблов (BR-3)
Дано: задача только с autoApprove (без autoDeploy) — и симметрично наоборот.
Тогда:
- только
autoApprove: BRD авто-проходит, деплой ждёт ручного Confirm Deploy; - только
autoDeploy: BRD ждёт ручного Approved, деплой авто-проходит.
PASS: каждый лейбл влияет строго на свой гейт, второй гейт остаётся ручным. FAIL: один лейбл повлиял на оба гейта.
AC-10 — инварианты неизменны (TRZ §10)
Тогда: STAGE_TRANSITIONS, QG_CHECKS, check_analysis_approved,
check_deploy_status, check_staging_status, схема БД, все технические под-гейты,
sentinel-маркеры self-deploy, exit-коды deploy-хука — не изменены.
PASS: diff не затрагивает перечисленные контракты; существующие тесты этих компонентов зелёные. FAIL: любой из инвариантных контрактов изменён.
AC-11 — документация обновлена (CLAUDE.md §правила 2/6)
Тогда: в том же PR обновлены CLAUDE.md, docs/architecture/README.md,
заведён 06-adr/ADR-001-*, 07-infra-requirements.md (создание лейблов), CHANGELOG.md.
PASS: документация-golden-source синхронна с кодом. FAIL: функционал изменён, документация — нет (reviewer → REQUEST_CHANGES).