01 — BRD: Авто-режим по лейблам (autoApprove + autoDeploy)

Work Item: ORCH-089 Repo: orchestrator (self-hosting) Стадия: analysis Приоритет: Бэклог (запуск по решению Славы, serial e2e после ORCH-88)

⚠️ Прошлый подход (09.06) ОТМЕНЁН: «Стрим ревьюит и апрувит BRD» — НЕ реализовывать. Актуальная модель: автономность управляется лейблами Plane на задаче, без участия людей.

1. Проблема / зачем

В конвейере два человеческих гейта — точки, где конвейер останавливается и ждёт ручного клика человека (Слава/Стрим):

Гейт BRD (стадия analysis): после завершения analyst задача переводится в In Review и ждёт, пока человек вручную выставит Plane-статус Approved, чтобы уйти на architecture.
Гейт деплоя (стадия deploy): после зелёного staging задача переводится в Awaiting Deploy (Phase A, ORCH-036/059) и ждёт, пока человек вручную выставит статус Confirm Deploy, чтобы запустить прод-деплой (Phase B).

Для задач, которым доверяем, оба ручных решения избыточны и тормозят пакетный автономный прогон («10–20 задач за ночь», эпик ORCH-088). Нужно снять эти два человеческих решения выборочно и декларативно — через лейблы на конкретной задаче.

2. Бизнес-цель

Дать оператору возможность пометить задачу лейблом и тем самым разрешить орку самому пройти соответствующий человеческий гейт, не трогая ни одну техническую проверку. Доверие выражается лейблом — на уровне отдельной задачи, обратимо, прозрачно.

3. Модель (решение Славы, 09.06)

Лейбл на задаче	Эффект
`autoApprove`	Орк САМ подтверждает BRD (гейт 1: `In Review → Approved`), без человека. Конвейер идёт на `architecture`.
`autoDeploy`	Орк САМ подтверждает прод-деплой (гейт 2: `Confirm Deploy`) и деплоит в прод после зелёного staging + всех тех-гейтов, без человека.

Лейблы независимы:

только autoApprove → BRD авто, деплой вручную;
только autoDeploy → BRD вручную, деплой авто;
оба → полная автономность (анализ → деплой без единого ручного клика);
без лейблов → текущее поведение (оба гейта ручные, нулевая регрессия).

4. Критический инвариант — авто-режим снимает ТОЛЬКО человеческое решение

Авто-режим не отключает и не ослабляет ни одну техническую проверку. Все тех-гейты остаются на месте и блокируют при провале ровно как сейчас:

check_ci_green (CI зелёный);
check_staging_status (staging healthy, ORCH-035);
security-гейт (gitleaks + pip-audit, ORCH-022);
merge-gate / re-test / merge-lease (ORCH-043);
image-freshness / provenance guard (ORCH-058);
merge-verify + regression-guard (ORCH-071/073);
post-deploy monitor (ORCH-021).

autoDeploy никогда не деплоит сломанное — он лишь заменяет ручной клик «Confirm Deploy» на авто-проход, и только когда все тех-гейты на ребре deploy-staging → deploy уже зелёные. autoApprove заменяет ручной клик «Approved», но артефакты анализа (BRD/TRZ/AC/test-plan) должны существовать (check_analysis_complete).

5. Fail-safe (безопасность по умолчанию)

При любой неоднозначности — откат к ручному гейту (never auto):

лейбл не распознан / Plane API недоступен / ошибка чтения лейблов;
неоднозначность сопоставления имени лейбла;
любое исключение в логике определения авто-режима.

Лучше подождать человека, чем авто-пропустить гейт по ошибке. Это согласуется с fail-closed-практикой проекта (ORCH-059 «нет статуса → нет деплоя»).

6. Прозрачность (обязательно)

Каждый авто-проход гейта логируется и виден оператору:

запись в лог (кто/почему: label autoApprove → auto-approved BRD / label autoDeploy → auto-confirmed prod deploy);
Telegram-уведомление + строка/обновление в live-карточке задачи (ORCH-042/087);
Plane-коммент в задаче (как при ручном проходе гейта).

Слава должен по карточке/Telegram видеть, что задача прошла гейт автоматически (а не руками), и какой именно лейбл это разрешил.

7. Бизнес-требования (BR)

BR-1. Лейбл autoApprove на задаче → BRD подтверждается автоматически (In Review → Approved) сразу после успешного analyst (артефакты готовы), конвейер идёт на architecture. Закрывается клок brd_review_ended_at.
BR-2. Лейбл autoDeploy на задаче → после зелёного staging и всех тех-гейтов прод-деплой (Phase B) триггерится автоматически, без ручного Confirm Deploy.
BR-3. Лейблы независимы; комбинация обоих даёт полную автономность анализ→деплой.
BR-4. Без лейблов поведение конвейера не меняется (оба гейта ручные).
BR-5. Тех-гейт красный → авто-режим НЕ проходит гейт; задача встаёт/заворачивается ровно как сейчас (авто-режим не маскирует провал тех-проверки).
BR-6. Нераспознанный/спорный лейбл / ошибка чтения → fail-safe к ручному гейту.
BR-7. Каждый авто-проход гейта логируется и виден в карточке/Telegram + Plane.
BR-8. Лейблы autoApprove и autoDeploy должны существовать в Plane-проекте ORCH (сейчас их нет — создать через labels API; инфра-предусловие).
BR-9. Раскат под kill-switch (как ORCH-035/043/059/088); выключенный флаг → строго прежнее поведение (нулевая регрессия для enduro-trails и для самого ORCH).
BR-10. Авто-проходы — только для self-hosting/applicable репо по тому же условному принципу, что и self-deploy (Phase A/B существуют только для self-hosting). Гейт BRD логически применим к любому репо, но раскат гейтится флагом/scope.

8. Вне scope (НЕ делаем в этой задаче)

Любая логика «Стрим/человек ревьюит BRD» (отменённый подход).
Управление лейблами из UI оркестратора.
Авто-режим для REQUEST_CHANGES / откатов reviewer/tester (это не человеческие гейты — это технические вердикты, они и так автоматические).
Снятие/ослабление любого технического гейта.
Авто-снятие per-repo freeze (ORCH-088) — freeze остаётся ручным.

9. Допущения и зависимости

Plane labels API v1 работает (POST /labels/ подтверждён в бизнес-запросе; GET лейблов проекта и поле labels issue — проверить на этапе архитектуры/разработки).
Идёт поверх ORCH-088 (serial gate) — авто-режим совместим с serial e2e: serial-gate сериализует задачи, авто-режим убирает человеческие паузы внутри прохода одной задачи.
Self-deploy Phase A/B/C (ORCH-036/059/071) — точки врезки авто-деплоя.

9.6 KiB Raw Permalink Blame History Unescape Escape