4.9 KiB
4.9 KiB
10 — Технические риски: ORCH-082 (ORCH-81)
Риски точечной врезки «ensure_open_pr перед merge-verify». Все — в зоне ребра deploy → done
(self-hosting), под kill-switch merge_verify_autocreate_pr_enabled.
| ID | Риск | Вероятн. | Влияние | Митигация |
|---|---|---|---|---|
| R1 | ensure_open_pr выбирает/создаёт не тот PR (авто-docs-PR base != main) → merge_pr мержит/верифицирует не тот PR |
Сред. | Высокое | Фильтр head.ref==branch И base.ref=="main", идентичный merge_pr (ORCH-073 FR-3). Тест AC-6: ветка с docs-PR (base!=main) → актор его игнорирует и создаёт код-PR на main. |
| R2 | Создание PR маскирует реально невлитый код → ложно-зелёный done (регресс ORCH-073) |
Низк. | Критич. | Верификация остаётся ТОЛЬКО verify_merged_to_main (SHA-в-main) + check_main_regression; ensure_open_pr НЕ влияет на вердикт merge. Регресс-тест AC-4: verify_merged_to_main→False ⇒ HOLD, не done. |
| R3 | Гонка: параллельно создаётся 2 PR → дубль | Низк. | Сред. | Идемпотентность FR-1.3: на ошибку «PR exists»/409/422 — повторный GET → existed; PR создаётся только если GET пуст. Тест AC-2. |
| R4 | Исключение из ensure_open_pr пробрасывается в advance_stage → падение перехода |
Низк. | Высокое | Контракт never-raise (except Exception → ("failed", reason)); врезка обёрнута внешним try/except _handle_merge_verify. failed → структурированный HOLD, не throw. Тест AC-7. |
| R5 | Gitea недоступна на ребре deploy → done → задача в HOLD |
Низк. | Сред. | Сознательный fail-closed: failed → честный HOLD+alert (_hold_pr_create_failed), НЕ ложный done. Текст HOLD отличим от not-merged (AC-5) — оператор видит причину. Reaper/reconciler/re-approve переиграют, когда Gitea вернётся (FR-5). |
| R6 | Оператор не различит HOLD «PR не создан» и HOLD «PR не влит» | Сред. | Низк. | Отдельный helper _hold_pr_create_failed с собственным текстом и result.note="pr-create-failed-hold" (≠ merge-not-verified-hold); лог-строка ensure_open_pr -> failed: <reason>. AC-5. |
| R7 | Расхождение логики выбора/создания PR между launcher._ensure_pr и merge_gate.ensure_open_pr |
Сред. | Сред. | Рекомендованное делегирование _ensure_pr → ensure_open_pr (единый код). Если не делегируем — обе копии используют ОДИН фильтр head==branch && base==main; тест на согласованность. |
| R8 | Включение по умолчанию (True) меняет прод-поведение скрытно |
Низк. | Сред. | Поведение строго аддитивно: при наличии PR → existed/no-op; меняется лишь ранее-падавший путь «no open PR». Kill-switch False → 1:1 ORCH-074 (AC-8). Выкат через staging-гейт (8501). |
| R9 | Регресс инвариантов (STAGE_TRANSITIONS/QG_CHECKS/схема БД/exit-коды) |
Низк. | Высокое | Под-гейт-врезка в advance_stage, НЕ новый QG_CHECKS-элемент и НЕ новая стадия; БД не трогается (идемпотентность из Gitea). Тест AC-10 + полный pytest. |
Зоны без изменений (подтверждение границ)
- Инфраструктура/топология — без изменений →
07-infra-requirements.mdне требуется. - Схема БД — без изменений (идемпотентность выводится из Gitea) →
08-data-requirements.mdне требуется. STAGE_TRANSITIONS,QG_CHECKS,check_deploy_status/_parse_deploy_status, exit-коды хука, merge-gate (ORCH-043), image-freshness (ORCH-058), terminal-sync — не тронуты.
Главный архитектурный приоритет
При любом конфликте «создать PR» проигрывает «не дать ложно-зелёный done» (защита ORCH-073).
Создание PR — страховка инварианта ДО merge_pr, никогда не подмена верификации merge.