154 lines
9.4 KiB
Markdown
154 lines
9.4 KiB
Markdown
# 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_complete` FAIL)
|
||
> авто-аппрув не срабатывает (нет 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).
|