6.4 KiB
6.4 KiB
10 — Технические риски
Work Item: ORCH-066 Автор: Architect Дата: 2026-06-07
Риски слоя B (Plane-индикация). Слой A (STAGE_TRANSITIONS/гейты) не затрагивается, поэтому
класс «сломали конвейер» структурно исключён — худший исход любого риска ниже = неверная
индикация, не остановка конвейера.
| ID | Риск | Вероятность | Влияние | Митигация |
|---|---|---|---|---|
| R1 | Частичная конфигурация: оператор создал не все 6 статусов в ORCH → отсутствующий ключ деградирует. Наивный статический enduro-UUID дал бы невалидный state (PATCH 422) на orchestrator-issue. |
Средняя | Средн. | Project-relative alias-fallback (ADR §2.2): отсутствующий ключ → собственный базовый UUID проекта → PATCH валиден, индикация откатывается к текущему статусу. Покрыть тестом partial-config. |
| R2 | Enduro-регресс через Guard 2: новые ключи алиасятся на in_progress/in_review/done; наивное добавление в skip-set заставит F-1 пропускать enduro In Progress/Done → сломанная реконсиляция (ORCH-053/060). |
Средняя | Высок. | Subtraction базовых рабочих статусов (ADR §2.6): extra_waits -= base_working. На enduro (алиасы схлопнуты) extra_waits == {} → нулевой регресс. Тест: enduro-алиас не добавляет skip, orchestrator-distinct добавляет. |
| R3 | Двойной триггер старта: F-2 reconciler и webhook оба маршрутизируют to_analyse; при алиасе to_analyse == in_progress возможен повтор. |
Низкая | Низк. | list_issues_by_state дедуплицирует UUID через set; active-job guard + atomic create-claim в handle_status_start (get_task_by_plane_id + has_active_job_for_task) — без двойного старта (AC-4). Сохранить fork как есть. |
| R4 | Кэш статусов: после создания статусов _STATES_CACHE отдаёт старый резолв до сброса → доска не обновляется. |
Средняя | Низк. | reload_project_states() / рестарт staging. Документировано в 07-infra-requirements.md §3. Прод-рестарт ради кэша — запрещён (self-hosting). |
| R5 | Опечатка в имени статуса оператором (Code Review без дефиса и т.п.) → ключ не резолвится. |
Средняя | Низк. | Резолв по точному name; при промахе — alias-fallback (деградация, не падение). Точные имена и проверка в 07-infra-requirements.md §1–2. |
| R6 | Terminal-sync split: ошибка ветвления post_deploy_applies → enduro получает Monitoring after Deploy вместо Done (регресс AC-9) или self уходит в Done минуя окно (AC-8). |
Низкая | Средн. | Единый источник условности — post_deploy.post_deploy_applies(repo) (та же функция, что армит монитор). Тесты AC-8 (self→monitoring) и AC-9 (не-self→done). |
| R7 | Phase B: set_issue_deploying поставлен до фактического старта детача → ложная индикация при провале initiate_deploy. |
Низкая | Низк. | Ставить set_issue_deploying после успешного initiate_deploy и записи INITIATED marker (ADR §2.5); провал initiate_deploy оставляет Awaiting Deploy + просьбу повторить approve. |
| R8 | Post-deploy DEGRADED → set_issue_blocked ошибочно трактуется как «действие над продом». |
Низкая | Высок.(если) | set_issue_blocked — только Plane-PATCH. Тик остаётся ALERT_ONLY, НИКОГДА не рестартит/откатывает прод-контейнер (AC-12, ORCH-021 BR-5). Явный тест: self DEGRADED не трогает контейнер. |
| R9 | Plane API недоступен в момент простановки статуса → PATCH падает. | Низкая | Низк. | Все set_issue_*/_set_issue_state_direct — never-raise (логируют, не пробрасывают). Индикация пропускается, слой A не затронут. |
| R10 | Регресс на тестах, читающих STAGE_TO_STATE/PLANE_STATES конкретные UUID. |
Низкая | Низк. | Новые ключи в _DEFAULT_STATES = алиасы на те же in_progress/review/done UUID → значения байт-в-байт; STAGE_TO_STATE analysis/review остаются прежними UUID (ADR §2.3). |
| R11 | Self-hosting: выкладка орка минуя staging. | Низкая | Высок. | Обязательный deploy-staging гейт (8501); прод не рестартить вне штатного self-deploy. Раскат обратим (не создавать статусы = старое поведение). |
Сводный вывод
Все риски снижаемы в рамках принятой архитектуры; ни один не способен остановить конвейер
(слой A инвариантен). Два ключевых требуют аккуратной реализации и обязательных тестов:
R1 (project-relative alias-fallback) и R2 (Guard-2 anti-regress subtraction) —
оба зафиксированы в ADR §2.2 и §2.6 как явные контракты. Эскалации arch:major-change не
требуется: изменение локализовано в слое B, без новых компонентов/стадий/QG/миграций.