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

10 — Технические риски: ORCH-076 (ORCH-52c)

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

Информационный документ (гейтом не парсится). Источник истины по решениям — 06-adr/ADR-001.

ID	Риск	Вероятн.	Влияние	Митигация	Остаточно
R-1	Регресс чтения вердикта на гейте (review/testing/staging/deploy/security) при переводе на единый parse_frontmatter → ложный откат/застревание → остановка конвейера ВСЕХ проектов (главный self-hosting риск).	средняя	критическое	Унифицируется только парс YAML, НЕ семантика (ADR D2); сигнатуры/tuple[bool,str]/токены/upper-case/fallback worktree→origin/main 1:1; reason-строки переносятся дословно через FrontmatterParse-состояния; анти-регресс-тест на каждый из 5 гейтов (старый док → тот же вердикт) + полный pytest tests/ зелёный до мержа (AC-4/AC-6).	низкое
R-2	Самоблокировка валидатором на собственном деплое: доки ORCH-52c (и соседей) ещё без полной 6-польной схемы → strict-валидатор завалил бы гейт.	высокая (если включить strict)	высокое	frontmatter_validation_strict дефолт False; валидатор в default-режиме вне вердикт-пути гейтов (warning-only, чистый no-op для boolean); strict тестируется, но НЕ включается до ORCH-52d; false в .env/.env.staging (NFR-3, ADR D3).	очень низкое
R-3	Первый боевой autoDeploy (ORCH-089): орк сам подтверждает прод-рестарт после staging → если регресс R-1 проскользнул мимо тестов, автодеплой выкатит его без человеческой паузы.	низкая	высокое	autoDeploy достигает Фазы B только после зелёных под-гейтов ребра deploy-staging→deploy (security→merge-gate→image-freshness→staging) — не деплоит сломанное (BR-5 ORCH-089); обязательная страховка staging (8501); пост-деплой мониторинг ORCH-021 (ALERT_ONLY для self) ловит «зелёный деплой, красный прод» с откатом durable-freeze (ORCH-088); ручной BRD-гейт сохранён. Наблюдать стадию deploy вживую (Telegram-карточка).	низкое
R-4	Дрейф reason-строк / сообщений гейтов при рефакторе → тесты, ассертящие текст, краснеют; логи/Plane-комменты меняют формулировку.	средняя	низкое	Маппинг FrontmatterParse → прежняя reason-строка зафиксирован в ADR D2; переносить дословно; ассерты в анти-регресс-тестах фиксируют текущий текст.	низкое
R-5	Расхождение спеки handoff с фактом кода → «лживый» стандарт.	средняя	среднее	HANDOFF_PROTOCOL.md согласован 1:1 с PIPELINE_DOCS.md §2–§3 (тот же набор документов/ключей/гейтов); явная пометка «источник истины — код» (правило ORCH-075); reviewer сверяет (CLAUDE.md №2/№6).	низкое
R-6	Скрытое исключение из writer/валидатора прорывается в конвейер (нарушение never-raise) на битом вводе.	низкая	высокое	Контракт всего модуля never-raise (как действующий reader): любая ошибка → лог + безопасное значение; тест на битом вводе (невалидный YAML, не-mapping, I/O-ошибка) подтверждает отсутствие проброса (AC-5/NFR-2).	очень низкое
R-7	Циклический импорт при использовании frontmatter из qg/checks.py/security_gate.py/post_deploy.py/review_parse.py.	низкая	среднее	frontmatter.py — leaf без проектных зависимостей (только logging + ленивый yaml); импортируется, не импортирует проектные модули — циклов нет.	очень низкое
R-8	Частичная унификация (token-логика осталась в каждом гейте) воспринимается reviewer'ом как недовыполнение AC-3.	низкая	низкое	AC-3 требует «парсить YAML через единый API, а не дублированной логикой» — выполнено (D2); неунификация семантики — осознанный выбор безопасности, зафиксирован в ADR (альтернатива A1 отклонена).	очень низкое

Сводные митигации (обязательные перед мержем)

1. Анти-регресс-тест на каждый из 5 вердикт-гейтов (старый док без схемы → прежний вердикт).
2. tests/test_frontmatter.py: reader (контракт неизменен) / writer (round-trip) / валидатор (полный/неполный, strict on/off) / битый ввод → never-raise.
3. Полный pytest tests/ -q зелёный.
4. frontmatter_validation_strict=False в прод/staging env.
5. Живое наблюдение стадии deploy (первый autoDeploy); готовность к orchestrator-deploy-hook.sh --rollback штатным путём (не ручной рестарт).