---
work_item: ORCH-123
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-16
model_used: claude-opus-4-8
---

# 10 — Технические риски: ORCH-123 — host-side исполнение staging-раннера

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

Формат: риск → вероятность/влияние → митигация (привязка к решению ADR-001 / AC).

---

## R-1 — Security: расширение поверхности атаки docker (NFR-3 / AC-9)
**Влияние:** критичное (root-эквивалент на общем хосте). **Вероятность (при выбранной стратегии):**
низкая.
Любой вариант с docker CLI/SDK **в контейнере** поверх смонтированного `docker.sock` (rw + group_add
999, ORCH-040) превращает дремлющую возможность в активный root-эквивалентный путь, доступный
worker-коду **и любому subprocess'у** (вкл. LLM-агентов).
**Митигация:** выбран **host-side ssh** (ADR-001 D1/D2) — docker-операции на хосте под существующим
доверенным key-gated каналом (ORCH-036/058), **без** docker CLI/SDK в контейнере и **без** расширения
использования сокета. ORCH-123 поверхность ORCH-040 не трогает. Любой будущий socket/CLI-в-контейнере
вариант — отдельный явный security-review.

## R-2 — Реконсилятор/reaper откатывает infra-held задачу как код-фейл (FR-2 / AC-3 / AC-11)
**Влияние:** высокое (реинтродукция дефекта ORCH-123). **Вероятность:** средняя (зависит от
поведения reconciler ORCH-053 на застрявшем `deploy-staging`).
`permanent-env` / исчерпавшая-DEFER задача держится на `deploy-staging` (ADR-001 D4). Если reconciler/
reaper трактует «застрял на deploy-staging без running-job» как повод откатить на `development` —
дефект вернётся.
**Митигация:** developer **обязан** верифицировать, что reconciler/reaper трактует infra-held
deploy-staging-задачу как **удержанную** (пере-выдать `deployer`-джоб для re-drive после починки
окружения), а **не** откатывает в `development`. Регресс-покрытие — поведенческий тест на «held не
становится rollback». Наблюдаемость (D8) делает held видимым (alert + `GET /queue` + лог).

## R-3 — Over-tolerance: реальный код-фейл сюиты замаскирован как «инфра» (BR-3 / AC-4)
**Влияние:** высокое (сломанный код проходит staging-гейт). **Вероятность:** низкая.
Трёхсторонняя классификация (D3) может ошибочно отнести реальный `exit≠0` сюиты к
`permanent-env`/`transient-infra` (→ нет отката) при коллизии exit-кодов
(`docker exec` No such container = 1, и `staging_check` fail = 1).
**Митигация (D3):** дизамбигуация по **скану stderr на env-маркеры**, не по голому exit-коду:
распознанный suite-exit **без** env-маркера всегда `suite-ran` (никогда не реклассифицируется в
инфру — зеркало ORCH-110 BR-6). Fail-safe default при неоднозначности → `transient-infra` (DEFER), не
тихий проход. Маркер-сет покрыт TC-06; reviewer проверяет анти-over-tolerance (≥P1, как ORCH-110).

## R-4 — Remote tree-kill: удалённое `docker exec`-дерево переживает таймаут (NFR-5)
**Влияние:** среднее (осиротевший pytest на хосте — класс ORCH-109/110). **Вероятность:** низкая.
`proc_group` tree-kill убивает **локальный** ssh-клиент при таймауте, но не гарантирует убийство
удалённого `docker exec`-дерева на хосте (процессы — дети docker-демона, не ssh-сессии).
**Митигация:** backstop — bounded таймаут внутри самой `staging_check.py`; это **то же** принятое
допущение, что у `image_freshness.rebuild_staging_image` (синхронный ssh без remote tree-kill).
Документируется как known-limitation (ADR-001 D-Последствия); не блокер.

## R-5 — Held-задача клинит serial-gate репо (NFR-5 / AC-11)
**Влияние:** среднее (более поздние задачи репо ждут). **Вероятность:** средняя (при реальном
environment-сбое).
infra-HOLD держит задачу на `deploy-staging` → ORCH-088 serial-gate блокирует **более поздние** задачи
того же репо до снятия.
**Митигация:** принятый tradeoff (зеркало ORCH-110 infra-HOLD): environment-проблема, требующая
оператора, **должна** остановить репо, а не молча ложно-откатывать (что было бы хуже — порча
done-критериев + расход developer-retry). Скоуп **self-hosting only** (enduro не затронут). Громкий
alert «инфра, НЕ дефект кода» (D8) → быстрая операторская реакция; `GET /queue` показывает held.

## R-6 — ssh-target не сконфигурирован / пустой `deploy_ssh_host` (FR-1 / D6)
**Влияние:** среднее. **Вероятность:** низкая (в проде `ORCH_DEPLOY_SSH_HOST=127.0.0.1` задан compose).
Config-дефолт `deploy_ssh_host=""`; на нестандартном хосте host-side стратегия без ssh-target
неработоспособна.
**Митигация:** пустой ssh-target → классификация `permanent-env` (D3) → infra-HOLD + alert (никогда
ложный откат); preflight на старте (D5) ловит это до реальной задачи. `applies(repo)` self-hosting-only
→ прочие репо не затронуты.

## R-7 — Кросс-каттинг: правка маркированных блоков (CLAUDE.md §9 / ORCH-078)
**Влияние:** среднее. **Вероятность:** низкая.
Затрагиваются блоки с маркерами ORCH-115 (staging_runner, прямой объект), ORCH-036 (`self_deploy`
ssh), ORCH-058 (`image_freshness` host-side docker), ORCH-110 (`proc_group`/infra-tolerance/classify),
ORCH-101 (host-параметризация), ORCH-040 (docker.sock mount), ORCH-114 (transition-lease граница).
**Митигация:** developer **перед** изменением сверяет инварианты с их `06-adr/` (CLAUDE.md §9). Блок с
≥3 маркерами агрегируется **сводным сквозным ADR** `adr-0049` (ADR-001 Сквозная регистрация). Не
ломать: один транспорт LLM `_spawn` (`llm-usage-policy.md` §5), `STAGE_TRANSITIONS`/`QG_CHECKS`/
machine-verdict (NFR-1), transition-lease берётся внутри `advance_stage` (граница O1), INV-4 (мерж
только через PR-merge, никогда push в `main`).

## R-8 — Регрессия конвейера / гейта (NFR-1 / AC-7)
**Влияние:** критичное. **Вероятность:** очень низкая.
Случайное изменение `check_staging_status`/`_parse_staging_status`/`staging_status:`/`STAGE_TRANSITIONS`/
схемы БД.
**Митигация:** фикс — замена **стратегии исполнения продюсера**, не гейта (зеркало ORCH-115 NFR-1).
Структурный анти-регресс-тест (TC-11) держит имена/семантику/ключи байт-в-байт; миграции БД нет
(restart-safe DEFER-счётчик — маркер в `task_content`, TRZ §5). Анти-дрейф ORCH-115 (TC-14) зелёный.