Files
orchestrator/docs/work-items/ORCH-089/10-tech-risks.md

5.5 KiB
Raw Blame History

10 — Технические риски: ORCH-089 (авто-режим по лейблам)

# Риск Вероятность / Impact Митигация
R-1 Ложный авто-проход гейта при ошибке чтения лейблов (Plane вернул мусор/частичный ответ) → задача авто-проходит, хотя лейбла нет. Низк. / Критич. (групповой self-hosting риск). has_label обёрнут в единый try/except → False; fetch_issue_labels различает None (ошибка) и [] (нет лейблов); неоднозначность имени → False. Любая неопределённость → ручной гейт (BR-6/AC-6). Дополнительно: тех-гейты страхуют от деплоя сломанного даже при ложном autoDeploy.
R-2 Двойной advance / гонка автоApprove с реальным Approved-вебхуком или reconciler F-2. Сред. / Низк. Advance применяется один раз: после авто-advance стадия = architecture; поздний Approved/F-2 видят architecture и не повторяют analysis-переход (как человеческий double-click сегодня).
R-3 Двойной прод-деплой при autoDeploy (повторный заход Phase A / дубль staging-deployer-finished). Низк. / Высок. Идемпотентность Phase B по маркеру INITIATED. Phase A после первого прохода advance'ит стадию на deploy → guard current_stage=="deploy-staging" больше не матчится, повторный Phase A не запускается. clear_state в Phase A wipe'ит маркеры только при входе в свежий проход.
R-4 Re-entrancy вложенного advance_stage из _handle_analysis_approved_flow → рекурсия. Низк. / Сред. Вложенный вызов идёт с finished_agent=None и попадает в ветку approved-via-status, НЕ в _handle_analysis_approved_flow (та требует agent=='analyst'). Рекурсии нет.
R-5 Регрессия для enduro / при выключенном флаге (лишние сетевые вызовы, изменение поведения). Низк. / Высок. applies(repo) (локальный, без сети) проверяется ПЕРВЫМ; has_label (сеть) — только при applies==True. auto_label_enabled=False или репо вне scope → applies==False → нулевой сетевой оверхед, поведение 1:1 (AC-8).
R-6 Лейбл не создан в Plane-проекте → фича «молча не работает». Сред. / Низк. has_label==False → ручной гейт (fail-safe, не ошибка). Инфра-предусловие задокументировано (07-infra-requirements.md I-1). Прозрачность: отсутствие авто-прохода видно по тому, что задача встала на ручном гейте.
R-7 Транзиентность Approved-статуса (перекрывается Architecture сразу после advance) → оператор не увидит, что прошёл именно авто-аппрув. Сред. / Низк. Durable-прозрачность — лог + Telegram + Plane-коммент («auto-approved via label autoApprove») + live-карточка (AC-7). Plane-статус Approved — лишь мгновенная индикация.
R-8 Stale-кэш карты лейблов (get_project_labels) → недавно созданный/снятый лейбл не виден. Низк. / Низк. TTL auto_label_states_ttl_s (300с) — самозалечивание без рестарта (образец plane_states_ttl_s/ORCH-068). Окно ≤ TTL.
R-9 Plane API недоступен на гейте → задержка/блок конвейера. Низк. / Сред. Таймаут 10с (как соседи), never-raise → «нет авто» → ручной гейт. Конвейер не блокируется; задача просто ждёт человека (прежнее поведение).
R-10 Доверие выражено лейблом ошибочно (autoDeploy навешан не на ту задачу). Сред. / Сред. Тех-гейты блокируют поломку (не «не ту фичу»). Лейбл обратим (снять → ручной режим). Зона ответственности оператора; прозрачность авто-прохода (AC-7) даёт раннее обнаружение.

Вывод

Доминирующий риск — R-1 (ложный авто-проход); закрывается строгим never-raise / fail-safe контрактом leaf-модуля и тем, что тех-гейты остаются последней линией защиты. Все риски укладываются в установленные проектом паттерны (условный под-гейт + kill-switch + scope + fail-safe), новых классов риска фича не вводит.