---
work_item: ORCH-092
stage: architecture
author_agent: architect
status: accepted
created_at: 2026-06-09
model_used: claude-opus-4-8
---

# 10 — Технические риски: ORCH-092 — Промпт-аудит 6 агентов

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

> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
> Решения, порождающие/снижающие часть рисков, зафиксированы в
> `06-adr/ADR-001-developer-rebase-and-deployer-language.md`.

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

| ID | Риск | Вер. | Влия. | Митигейшн |
|----|------|------|-------|-----------|
| TR-1 | Массовая текстовая правка 6 промптов случайно ломает machine-verdict ключ (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`) по имени/регистру/значению | Сред. | Выс. | NFR-1 анти-регресс: `tests/test_agent_prompts_canon.py` (`test_machine_verdict_keys_preserved_exact_case`) + `test_agent_frontmatter_no_model.py` зелёные; правка точечная, не переписывание |
| TR-2 | Плейсхолдеры `<YYYY-MM-DD>` / `<resolve ORCH-41>` сами скопированы моделью буквально (тот же класс бага, что хардкод) | Сред. | Низ. | Явная инструкция «подставь фактическое (`date +%F` / резолв конфига), НЕ копируй из примера»; плейсхолдер визуально не похож на валидное значение |
| TR-3 | Удаление шага `git rebase origin/main` (D1) оставляет ветку на устаревшем `main` в длинной/повторной (rework) стадии development | Низ. | Сред. | Авторитетный `auto_rebase_onto_main` под merge-lease перед слиянием (ORCH-026/043) детерминированно догоняет `main`; serial-gate (ORCH-088) ограничивает расхождение `main` за время одной задачи; срез ветки — от свежего `origin/main` |
| TR-4 | Решение «deployer = EN» (D2) воспринято будущим агентом как дрейф и «починено» переводом → регресс NFR-1 на самом опасном промпте | Низ. | Выс. | Нормативная фиксация исключения: запись в `CLAUDE.md`/README §«Слой промптов» + ожидание EN-deployer в каноне-тесте (FR-11); ADR-001 D2 как ссылка-обоснование |
| TR-5 | Добавление секции `<escalation>` (developer/reviewer/tester) нарушает нормативный порядок 5 обязательных XML-секций канона 52d | Низ. | Сред. | `<escalation>` ставится ПОСЛЕ `</success_criteria>` (как у `architect.md` — эталон); гаранты `test_five_xml_sections_present` / `test_six_schema_field_names_present` |
| TR-6 | Поднятие критичной рамки в `deployer.md` (FR-6) задевает анти-регресс-маркер (`docker exec orchestrator-staging`, `pr_already_merged`, `8500`, `INFRA-WAIVED`) | Низ. | Выс. | Рамка добавляется/поднимается аддитивно (blockquote в начале `<context>`), маркеры не трогаются; каноне-тест проверяет их наличие |
| TR-7 | Сверка имён гейтов (FR-3) «исправляет» верное имя вслепую (напр. `check_tests_passed`) | Низ. | Сред. | BR-3/A-1: несовпадений на момент анализа НЕТ → правка только реально отсутствующих в `QG_CHECKS`; TC-03 сверяет имена против реального реестра `src/qg/checks.py` |

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

Доминирующий класс рисков — **случайный слом машинного контракта/канона при текстовой правке**
(TR-1/TR-5/TR-6/TR-7), полностью покрываемый структурными анти-регресс-тестами
`tests/test_agent_prompts_canon.py` + `test_agent_frontmatter_no_model.py` (NFR-1). Архитектурные
решения D1/D2 снижают, а не повышают системный риск: D1 устраняет конфликт инструкции с запретом
force-push и отдаёт догон `main` единственному авторитетному владельцу (движок); D2 минимизирует
регресс-поверхность на самом safety-critical промпте.

Изменение **docs/prompts-only**: `src/**`, `STAGE_TRANSITIONS`, `QG_CHECKS`, схема БД — не тронуты;
прод-контейнер 8500 не перезапускается (NFR-2); всё ревертируемо одним PR (NFR-3). Эскалация
`arch:major-change` **не требуется**; возврат в анализ **не требуется** (ТЗ реализуемо без нарушения
принципов). Остаточный риск для прод-конвейера (self-hosting) — **низкий**.