45 lines
6.5 KiB
Markdown
45 lines
6.5 KiB
Markdown
---
|
||
work_item: ORCH-115
|
||
stage: architecture
|
||
author_agent: architect
|
||
status: proposed
|
||
created_at: 2026-06-16
|
||
model_used: claude-opus-4-8
|
||
---
|
||
|
||
# 10 — Технические риски: ORCH-115 — детерминированный staging-раннер
|
||
|
||
Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: architecture
|
||
|
||
> Информационный (гейтом не парсится). Риски реализации + их митигейшн; нумерация
|
||
> наследует R-1…R-5 из BRD §8 и добавляет производные.
|
||
|
||
## Реестр рисков
|
||
|
||
| ID | Риск | Вер. | Влия. | Митигейшн |
|
||
|----|------|------|-------|-----------|
|
||
| TR-1 (R-1) | Перехват «до `_spawn`» перехватит **не тот** джоб (прод-deployer вместо staging) | Низ. | Выс. | Дискриминатор = **стадия задачи** (`tasks.stage=="deploy-staging"`) **И** `applies(repo)`, не только имя роли (ADR D1). Для self-hosting прод-ребро `deployer` не спавнит; для не-self `applies==False`. Покрытие TC-05/TC-06. `should_intercept` never-raise → `False` → штатный `_spawn`. |
|
||
| TR-2 (R-2) | После вердикта не инициирован `advance_stage` → задача зависает на `deploy-staging` (нет «финиша агента») | Низ. | Выс. | Раннер сам вызывает `advance_stage(current_stage="deploy-staging", finished_agent="deployer")` (зеркало `run_deploy_finalizer`, ADR D7). На исключении джоб → `mark_job(failed)` → reaper/worker по существующим контрактам; никогда тихий advance. Покрытие TC-07. |
|
||
| TR-3 (R-3) | Таймаут/изоляция docker-subprocess; утечка процессов (инцидент ORCH-110) | Сред. | Сред. | `proc_group.run_in_process_group` (tree-kill SIGTERM→grace→SIGKILL всего дерева), `staging_runner_timeout_s`; малформ/непозитив → дефолт + WARNING. Покрытие TC-11; запрет сирот согласован с ORCH-110. |
|
||
| TR-4 (R-4) | Конфликт с transition-lease (ORCH-114) / serial-gate (ORCH-088) на side-effectful ребре | Низ. | Выс. | Граница O1: lease берётся **внутри** `advance_stage` — раннер его не трогает (ADR D7). serial-gate гейтит analyst-job claim, не deployer-job. Код ORCH-112/114 не модифицируется. |
|
||
| TR-5 (R-5) | Откат FAILED (developer-retry cap) расходится с LLM-путём | Низ. | Сред. | Реальный `≠0` exit → тот же `advance_stage`-откат (`stage_engine.py:932`, тот же cap `MAX_DEVELOPER_RETRIES`), что у FAILED-вердикта LLM. Покрытие TC-07. |
|
||
| TR-6 | **Инфра-сбой как код-фейл** (docker down / staging недоступен / таймаут → откат + расход developer-retry → петля) — анти-паттерн ORCH-110 | Сред. | Выс. | **Двухуровневый исход D5:** сюита исполнилась → verdict; tool-error/таймаут → bounded defer (`staging_runner_infra_max_retries`) → fail-closed `FAILED` + alert на исчерпании. Не жжёт developer-retry на инфре. Покрытие TC-10. |
|
||
| TR-7 | Скоуп-дрейф: случайная правка `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-key/схемы БД | Низ. | Выс. | NFR-1 — замена только *продюсера*. Анти-дрейф структурный тест TC-09; reviewer ловит ≥P1. Раннер пишет тот же `staging_status:` key, читается неизменённым `_parse_staging_status`. |
|
||
| TR-8 | Сквозной бюджет времени (`reaper_max_running_s`) превышен суммой работ на ребре | Низ. | Сред. | Таймаут 600s ≤ прежнего LLM-окна (3–15 мин) → Σ(работ на ребре) не растёт → инвариант ORCH-065/109/110 сохранён **без** правки `reaper_max_running_s` (ADR D9). |
|
||
| TR-9 | Рассинхрон карты LLM (`llm-call-sites.md`/roadmap/policy) с реализацией → красные анти-дрейф-тесты | Сред. | Сред. | Норматив сопровождения NFR-6 (ADR D11): точная спека правок + `test_llm_call_site_inventory.py`/`test_llm_determinization_docs.py` обновляются **атомарно с кодом** в development. Инвариант «ровно один `first_slice`» держать корректным. Покрытие TC-14. |
|
||
| TR-10 | Self-hosting safety: раннер случайно рестартит 8500 / force-push в `main` / правит инфру | Низ. | Выс. | BR-7/AC-8: argv не содержит запрещённых литералов (TC-12); лог пишется в worktree + push в **фичеветку** (не main PR-merge, ADR D6); только чтение + staging-сюита (8501). |
|
||
|
||
## Сводный вывод
|
||
|
||
Доминирующий класс — **корректность диспетчеризации и обработки инфра-сбоев** (TR-1/TR-2/TR-6)
|
||
на side-effectful ребре общего прод-инстанса (self-hosting). Все сняты опорой на **доказанные
|
||
прецеденты** (D1/D2 перехват, `run_deploy_finalizer`, `proc_group`, transition-lease внутри
|
||
`advance_stage`) и **двухуровневым исходом D5**, явно адресующим RCA-класс ORCH-110.
|
||
Изменение **аддитивное, never-raise, под kill-switch с байт-в-байт откатом**; гейт/ребро/
|
||
схема БД неизменны. Остаточный риск для прод-конвейера — **низкий**.
|
||
|
||
Эскалация **не требуется**: это не новая стадия/QG/смена БД (лейбл `arch:major-change` не
|
||
ставится), ТЗ удовлетворяется без нарушения принципов (возврат в анализ не нужен). Единственное
|
||
**инфра-предусловие** для включения в проде — доступность `docker exec` в `orchestrator-staging`
|
||
(уже выполнено LLM-путём); до включения флага поведение байт-в-байт прежнее.
|