orchestrator/docs/work-items/ORCH-110/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-110	architecture	architect	proposed	2026-06-15	claude-opus-4-8

10 — Технические риски: ORCH-110 — merge-gate re-test infra-tolerance + tree-kill

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

Информационный (гейтом не парсится). Риски реализации и их митигейшн.

Реестр рисков

ID	Риск	Вер.	Влия.	Митигейшн
TR-1	Над-толерантность маскирует реально зависший тест ветки как «инфра» (R-1 BRD): бесконечный/долгий тест ветки → таймаут → толерируется → задача не падает на дефекте	Низ.	Выс.	Строгая ограниченность D3 (merge_retest_infra_max_retries=2, суммарное время ≤ ~34 мин) → исчерпание = инфра-alert (не молчание); красно-откат-путь сохранён (BR-6); D4 не пропускает re-test когда HEAD реально сдвинут. Остаточно: «зависший тест ветки» эскалируется как инфра, а не код — приемлемо (оператор увидит alert и разберёт; тест-зависание чинит developer вручную)
TR-2	os.killpg/start_new_session платформенная зависимость (не-POSIX / урезанный контейнер)	Низ.	Сред.	Гард hasattr(os, "killpg") + kill-switch subprocess_tree_kill_enabled → fallback на прежний subprocess.run (never-break); бой — Linux
TR-3	Tree-kill убьёт не те процессы (неверный pgid → SIGKILL чужой группе)	Низ.	Выс.	pgid == proc.pid гарантирован start_new_session для нашего потомка; killpg только по os.getpgid(proc.pid) нашего Popen; ProcessLookupError толерируется; никогда не киляем pgid 0/own
TR-4	Рассинхрон сквозных таймаутов при бампе бюджета (R-3 BRD): re-test 900 + coverage 900 + агент → > reaper_max_running_s	Низ.	Сред.	Проверенная таблица worst-case (≈4460 < 5400, 07-infra I-5); reaper_max_running_s не меняется; валидация непозитивного бюджета → дефолт+WARNING; операторская заметка про ручной бамп
TR-5	Магическая строка классификации ("timeout" in reason) хрупка к смене текста reason	Низ.	Сред.	Единый предикат classify_retest_failure (одна тестируемая точка, TC-03) вместо россыпи; reason — стабильный контракт ORCH-043 (как "merge-lock busy")
TR-6	D4 пропустит re-test и пропустит семантический конфликт	Оч.низ.	Сред.	Пропуск ТОЛЬКО при доказанном no-op rebase (нет «уехавшего main» → нет нового класса конфликта); на неопределённости (pre/post пуст / git-ошибка) re-test бежит (fail-safe); HEAD уже прошёл CI+tester+staging транзитивно
TR-7	Дубль/конфликт с ORCH-111 (proc_blocking)	Оч.низ.	Низ.	Чёткое разделение слоёв (D6): ORCH-110 предотвращает/толерирует у источника, ORCH-111 наблюдает; ORCH-110 не вводит детектор процессов
TR-8	Регресс при выключенном флаге (нарушен байт-в-байт fallback)	Низ.	Выс.	TC-07 проверяет kill-switch off = прежнее поведение и enduro no-op; каждый из 4 флагов независим и off → старый путь
TR-9	Гонка leдза на инфра-ретрае (повторный acquire, держание дольше TTL)	Низ.	Сред.	Существующее свойство ORCH-043 (лиз держится дольше TTL; реклейм holder-aware + pid-aware, ORCH-065 не трогает живого держателя); таймаут уже освободил лиз перед ретраем — переacquire штатный

Сводный вывод

Доминирующий класс — над-толерантность vs анти-регресс защиты merge-gate (TR-1/TR-6): закрыт строгой ограниченностью + сохранением красно-откат-пути + пропуском re-test только на доказанном no-op. Остальные риски — стандартного класса (платформенная зависимость, сквозные таймауты, kill-switch регресс), митигированы существующими паттернами кодовой базы (never-raise, fail-safe, дефолт=бой, валидация). Изменение аддитивно и полностью обратимо флагами; новой стадии/QG/ схемы БД нет. Эскалация arch:major-change не требуется; возврат в анализ не требуется. Остаточный риск для прод-конвейера (self-hosting) — низкий: critical-path не трогает main/прод-рестарт/ detached-деплой, а наихудший новый сценарий (инфра-alert после ретраев) строго лучше текущего (ложный manual-gate).