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

work_item, stage, author_agent, status, created_at, model_used

work_item	stage	author_agent	status	created_at	model_used
ORCH-094	architecture	architect	proposed	2026-06-09	claude-opus-4-8

10 — Технические риски: ORCH-094 — terminal-window-aware гард deploy-статусов

Work Item: ORCH-094 · Repo: orchestrator · Стадия: architecture

Формат: каждый риск — вероятность × влияние, причина, митигейшн, привязка к AC/ADR-решению.

---

R-1 — Гард подавляет ЛЕГИТИМНЫЙ Monitoring у реально деплоящейся задачи (регресс AC-4)

• Вероятность: средняя (без точного предиката — высокая) · Влияние: высокое.
• Причина: update_task_stage("done") (стр. 369) выполняется раньше set_issue_monitoring (стр. 404) ⇒ в момент легитимного Monitoring задача в БД уже done. Наивный гард «stage==done → Done» затёр бы легитимную индикацию.
• Митигейшн: предикат «терминал И НЕ активное окно» (D2 шаг 6) + перенос арм-блока перед terminal-sync (D3): window_active==True на стр. 404 ⇒ ALLOW. Анти-регресс — TC-11 (рабочий цикл Awaiting→Deploying→Monitoring→Done без подавления) + TC-03 (stage=deploy проходит).

R-2 — Фактический актор флаппа — внешняя Plane-automation (вне кода орка)

• Вероятность: низкая · Влияние: среднее (G1 закрыт не полностью).
• Причина: все 273 перехода — под бот-токеном орка; гипотеза H-внешнее не исключена до инструментальной локализации (FR-1).
• Митигейшн: гард — буфер на стороне орка (BR-2): если PATCH идёт через код орка — гасится; developer локализует актора (FR-1) и фиксирует в ADR/CHANGELOG (BR-7). Если актор реально внешний — это документируется как known-limitation, гард остаётся защитой от внутренних путей.

R-3 — Перенос арм-блока ломает инвариант ORCH-021/066

• Вероятность: низкая · Влияние: высокое (self-hosting прод).
• Причина: правка порядка внутри маркированного блока next_stage == "done".
• Митигейшн: arm_monitor не зависит от Plane-статуса/merge-lease (пишет sentinel + ставит отложенный job); merge-lease release остаётся после terminal-sync; идемпотентность арма по ARMED и инвариант ORCH-066 (deploy→done self ⇒ Monitoring) сохранены (D3). Прочитаны adr-0010 + 06-adr/ADR-001-plane-status-model. Тесты TC-06/TC-08 + TC-11.

R-4 — never-raise-деградация маскирует флапп (fail-safe = ALLOW)

• Вероятность: низкая · Влияние: низкое.
• Причина: при ошибке лукапа стадии / сетевой ошибке гард делает ALLOW (прежнее поведение), что в теории не гасит маятник.
• Митигейшн: БД-чтение — локальный SQLite (надёжно; ошибка редка); в штатном случае стадия читается ⇒ сходимость работает. Деградация логируется warning (D5) ⇒ видно в диагностике. NFR-1 приоритезирует «не падать/не блокировать конвейер всех проектов» над агрессивным подавлением. Тест TC-05.

R-5 — «Зомби»-тик пост-деплой-монитора после рестарта/стейл-job шлёт статус-PATCH

• Вероятность: низкая · Влияние: среднее.
• Причина: стейл-job post-deploy-monitor в очереди после закрытия окна/рестарта мог бы дёрнуть set_issue_monitoring.
• Митигейшн: идемпотентный страж has_marker(...DONE) (ранний return без PATCH/реэнкью, ~1729) + тик no-op при cancelled мид-окно (D4) + гард D2 (window_active==False ⇒ CONVERGE_DONE). restart-safe (sentinel'ы на диске). Тесты TC-06/TC-07.

R-6 — Стоимость лукапа tasks на каждый deploy-PATCH

• Вероятность: низкая · Влияние: пренебрежимое.
• Причина: новый SELECT на каждый вызов deploy-сеттера self-репо.
• Митигейшн: тот же ряд даёт repo для applies; SQLite-чтение ничтожно против сетевого PATCH; не-self/выключенный флаг → ранний ALLOW. Без кэша (корректность > микро-оптимизация).

R-7 — Регресс не-self репозиториев (enduro-trails)

• Вероятность: очень низкая · Влияние: среднее.
• Причина: общий инстанс/БД; правка общих сеттеров plane_sync.
• Митигейшн: applies(repo) (D2 шаг 3, deploy_status_guard_repos="" → self-hosting only); для не-self deploy-фазовые статусы и так не выставляются (terminal-sync сразу Done). Тест TC-12.

R-8 — Лукап по work_item_id не матчит (нет аксессора)

• Вероятность: низкая · Влияние: низкое (деградирует в ALLOW).
• Причина: get_task_by_plane_id матчит UUID-ключи, не человекочитаемый work_item_id.
• Митигейшн: developer добавляет read-only get_task_by_work_item_id (D8, без миграции); при промахе — ALLOW (never-raise). Тумбстоны ORCH-090 (#cancelled-<id>) не коллизируют с живым рядом.

---

Сводка по инвариантам (не нарушены)

Инвариант	Статус
STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict ключи	не тронуты (D7)
Схема БД	без миграции (read-only аксессор) (D7/D8)
main / force-push / прод-контейнер / detached-деплой	не тронуты (D7, NFR-2)
Рабочий self-deploy (Phase A→B→C, merge-gate, freeze ORCH-088)	1:1 (D7, AC-4)
Реконсилятор F-1/F-2	без изменений (гард субсумирует sync→Done) (D7)
Обратимость (kill-switch → 1:1)	ORCH_DEPLOY_STATUS_GUARD_ENABLED (D6)