orchestrator/docs/work-items/ORCH-118/01-brd.md

work_item, stage, author_agent, status, created_at, model_used

work_item	stage	author_agent	status	created_at	model_used
ORCH-118	analysis	analyst	ready-for-review	2026-06-15	claude-opus-4-8

01 — BRD (бизнес-требования): ORCH-118 — replace avoidable LLM control paths with deterministic implementations

Work Item: ORCH-118 · Repo: orchestrator · Стадия: analysis

⚠️ Inventory-first. Это зонтичная inventory/architecture-задача, а НЕ реализация детерминированных раннеров. Её результат — карта всех мест вызова LLM + классификация + упорядоченный roadmap + нормативная политика использования LLM, защищённая структурными тестами. Реализация конкретных замен — последующие задачи, запускаемые ПОСЛЕ утверждения карты. Их код в ORCH-118 не вносится (см. §2 «Вне объёма»).

📌 Follow-up'ы именуются по РОЛИ, без выдуманных Plane-ID. Roadmap рекомендует отдельные follow-up задачи по ролям-кандидатам (deployer-замена, tester-гибрид и т.д.). Конкретные Plane-ID этих задач в артефактах ORCH-118 НЕ фиксируются — они присваиваются при фактическом заведении задач в backlog. Аналитик не имеет доказательного источника на конкретные ID и не должен их выдумывать (см. NFR-6).

🔁 Revision R3 (2026-06-15). Из пакета удалена нормативная привязка follow-up'ов к конкретным ID ORCH-115/ORCH-116 (этих work item нет ни в репозитории, ни в подтверждённом backlog — claim «источник истины: live Plane backlog» был непроверяемым). Вместе с ней удалены навязывавший её структурный тест (бывш. TC-11) и отдельный критерий приёмки (бывш. AC-9). Follow-up'ы теперь описаны по роли, ID — TBD. Содержательная классификация ролей не менялась (deployer = кандидат на детерминированную замену, tester = кандидат на hybrid-fallback). (R1→R2 ранее «чинил» порядок этих ID; R3 убирает корень проблемы — фиксацию несуществующих ID.)

🔁 Revision R4 (2026-06-15). Закрыт блокер R3-ревью: инвариант «места вызова LLM» смешивал факт «существует процесс Claude CLI / спавнится subprocess» (транспорт/механизм) с фактом «потребляется суждение LLM» (LLM-консультация). R4 развёл транспорт (_spawn) и слот/ capability (D1/D2) от факта консультации во всех артефактах (см. §0). Содержательная классификация ролей и весь R3-материал (анти-фабрикация ID) — без изменений.

🔁 Revision R5 (2026-06-15) — единственный оставшийся блокер R4-ревью. Рецензент подтвердил R4 (консультация ≠ транспорт/слот; no-alternative-LLM-transport; follow-up'ы по роли/TBD; нет runtime-дифа) — менять их не нужно. Закрывается один блокер: артефакты разводили «консультация ≠ транспорт/слот», но не делали явной третью ось — самую важную для названия задачи «replace avoidable LLM control paths»: среди фактических консультаций не различались (i) control-path-консультации — где LLM-вердикт потребляется потоком управления (на нём ветвится check_*-гейт), и (ii) artifact-producer-консультации — где LLM лишь производит артефакт, а ветвление делает детерминированный гейт (наличие файлов / CI), и суждение LLM в control flow не входит. И главное — нигде явно не определена «avoidable LLM control path». R5 добавляет эту ось и определение во все артефакты (новый §0-bis, уточнённые BR-1/BR-2 + новые BR-8/BR-9, FR-1/FR-2 + новый FR-8, AC-1/AC-2 + новый AC-10, TC-13/TC-14). Содержательная классификация (analyst/architect/developer/reviewer → keep-LLM; deployer → replace-deterministic; tester → hybrid) не меняется — R5 даёт ей доказательный control-path вывод из кода (check_*/_parse_* в src/qg/checks.py).

---

0. Единица анализа: «LLM-консультация» ≠ «процесс Claude CLI» (R4)

Задача — про LLM control paths, поэтому единица инвентаря/классификации/инвариантов — это LLM-консультация (call-site), а НЕ «спавн процесса / существование Claude CLI». Три ортогональных факта фиксируются раздельно (их смешение и было блокером R3-ревью):

1. LLM-консультация (семантическая единица). Точка потока управления, где решение/артефакт конвейера потребляет суждение LLM (инференс модели). Именно её перечисляет и классифицирует карта. «Заменить avoidable LLM control path» = убрать консультацию там, где суждение не нужно, — независимо от того, каким транспортом она реализована.
2. Транспорт (механизм) ≠ консультация. Claude CLI-subprocess через launcher._spawn (src/agents/launcher.py, сборка CLAUDE_BIN --print … --system-prompt "$(cat …)" + Popen) — текущий единственный транспорт, которым реализуется LLM-консультация. Транспорт — это одна реализация понятия, а НЕ его определение. «Существует процесс Claude CLI» само по себе не равно «принято решение на основе суждения LLM».
3. Capability ≠ consultation (способность ≠ факт консультации). Спавн процесса делает site LLM-capable; происходит ли консультация фактически — гейтится потоком управления:
   • D1/D2 (deploy-finalizer/post-deploy-monitor) — job-роли, занимающие слот агента, но перехватываемые в launch_job до _spawn (src/agents/launcher.py:389,394, код прямо помечает «Not an LLM spawn») → консультации LLM нет, хотя «агент» как job существует;
   • timeout-kill (exit_code=-9) / salvage-guard (if exit_code==0) → спавненный процесс может не произвести потреблённого суждения. Поэтому «процесс спавнится» переоценивает «суждение потреблено».

Следствие для инварианта единственной точки (детализируется в BR-1/BR-6): он должен быть транспорт-агностичным и двусторонним — (i) единственный транспорт LLM-консультации в src/** — _spawn, И (ii) отсутствует любой иной транспорт (импорт anthropic/openai/LLM-SDK, прямой HTTP-эндпоинт Anthropic/Claude, второй model-invoking subprocess-сборщик --system-prompt/--model). Дискриминатор — «консультирует LLM», а не «спавнит subprocess»: десятки subprocess-вызовов в src/** (git/pytest/docker/ssh/сканеры/staging_check.py) не являются LLM-консультациями и не должны попадать под инвариант (см. FR-6 матчинг).

---

0-bis. Третья ось: control-path-консультация ≠ artifact-producer-консультация; что такое «avoidable» (R5)

§0 (R4) отделил факт консультации от транспорта и слота. Но название задачи — «replace avoidable LLM control paths» — требует ещё одного, решающего различия внутри множества фактических консультаций (A1…A6). Без него «control path» и «avoidable» остаются неопределёнными, и карта не отвечает на главный вопрос задачи: какие именно консультации — это avoidable LLM control paths. Это и есть оставшийся блокер R4-ревью.

Ось 3 — как именно LLM-вывод соотносится с потоком управления

Каждая фактическая консультация (роль-агент) относится ровно к одному из двух типов:

• (C) Control-path-консультация. LLM эмитит machine-verdict, который потребляется потоком управления конвейера: соответствующий check_*-гейт ветвится на этом вердикте (PASS→дальше / FAIL→откат). Суждение LLM входит в control flow — это и есть «LLM control path» в точном смысле названия задачи.
• (P) Artifact-producer-консультация. LLM производит артефакт (документы/код/PR), а решение о продвижении принимает детерминированный гейт, судящий артефакт независимо от самоотчёта LLM (наличие файлов, статус CI). Суждение LLM в control flow не входит → это не «LLM control path» (хотя консультация реальна и может требовать настоящего суждения).

Различие доказывается кодом — кто потребляет вывод роли (src/qg/checks.py, ground-truth на момент задачи):

Роль	Потребитель вывода (control-flow consumer)	Тип (C/P)	Control path?
analyst	check_analysis_complete (checks.py:33) — наличие файлов 01–04	P	нет
architect	check_architecture_done (checks.py:62) — наличие 06-adr/07	P	нет
developer	check_ci_green (checks.py:82) + check_branch_mergeable (657) — CI/merge	P	нет
reviewer	check_reviewer_verdict (checks.py:336) читает verdict: → REQUEST_CHANGES-откат	C	да
tester	check_tests_passed (checks.py:182) → _parse_tests_verdict (226) читает result:	C	да
deployer	check_staging_status (599)→_parse_staging_status (538) staging_status:; check_deploy_status (473)→_parse_deploy_status (413) deploy_status:	C	да

Для P-ролей гейт читает не самоотчёт LLM, а независимый детерминированный сигнал (файлы/CI) — поэтому подделать ветвление «самооценкой» нельзя; это структурно НЕ control path. Для C-ролей гейт читает именно machine-verdict, который написал LLM — суждение LLM и есть точка ветвления.

Определение «avoidable LLM control path» (нормативное, R5)

Call-site — avoidable LLM control path ⟺ выполнены оба условия:

1. (control path) это C-консультация — её LLM-вердикт потребляется потоком управления (check_* ветвится на нём); и
2. (deterministically derivable) этот вердикт по сути есть детерминированная функция от tool-сигналов (exit-code pytest/smoke, staging_check.py, exit-code деплоя), которые оркестратор уже вычисляет сам → суждение LLM не добавляет информации → консультацию можно снять без потери смысла.

Отсюда — точный целевой набор задачи (доказательно, не «на глаз»):

• avoidable LLM control paths = {tester, deployer} — C и вердикт деривируем из exit-кодов (_parse_tests_verdict судит то, что есть исход pytest; _parse_staging_status/ _parse_deploy_status судят то, что есть исход staging_check.py/деплоя; прод-деплой self-hosting уже идёт детерминированным путём Phase A/B/C, ORCH-036).
• control path, но НЕ avoidable = {reviewer} — C, но вердикт не деривируем: «приемлем ли код?» — настоящее суждение (keep-LLM). Это показывает, что «control path» сам по себе не равен «avoidable» — отсекает условие 2.
• НЕ control path (avoidable-вопрос неприменим) = {analyst, architect, developer} — P: детерминированный гейт судит артефакт, суждение LLM в control flow не входит; авторская работа требует настоящего суждения (keep-LLM). Это отсекает условие 1.
• уже детерминированы (вне консультаций) = {deploy-finalizer, post-deploy-monitor} — §0.3.

Эта ось выводит R3/R4-классификацию из кода, а не постулирует её: класс call-site'а есть функция его (C/P)-типа и деривируемости вердикта (см. BR-2). «Avoidable» больше не «удобство на глаз», а проверяемый двухбитный предикат над src/qg/checks.py.

---

1. Бизнес-контекст и проблема

Зонтичный follow-up по итогам RCA-цепочки ORCH-114/117 (и предшествующих ORCH-110/111/112/113): корневым классом инцидентов было то, что side-effectful и решающие control-path'ы не имели единого детерминированного владения — где-то решение принималось «потому что так удобно» через LLM-агента, хотя по сути это исполнение фиксированных команд и маппинг результата.

Установленный факт по текущему коду (инвентаризация — §1 TRZ, артефакт-карта):

• В оркестраторе единственный транспорт LLM-консультации — src/agents/launcher.py::_spawn (одна subprocess.Popen сборка Claude CLI: CLAUDE_BIN --print … --system-prompt "$(cat …)"), которым пользуются 6 ролей-агентов (analyst, architect, developer, reviewer, tester, deployer). Прямых вызовов Anthropic API / LLM-SDK / иных model-invoking транспортов в src/** нет (подтверждено инвентаризацией; впредь — держится тестом FR-6). ⚠️ Это утверждение про транспорт, а не про «единственный subprocess»: в src/** десятки прочих subprocess-вызовов (git/pytest/ docker/ssh/сканеры) — они не консультируют LLM (см. §0).
• Из 6 консультаций только 3 — это LLM control paths (вердикт потребляется потоком управления, §0-bis): reviewer / tester / deployer. Остальные 3 (analyst / architect / developer) — artifact-producer'ы: их выход судит детерминированный гейт (наличие файлов / CI), суждение LLM в control flow не входит. Среди 3 control path'ов avoidable — те, чей вердикт деривируем из exit-кодов: tester и deployer; reviewer — control path с настоящим суждением (keep).
• Все остальные control-path'ы уже детерминированы (без LLM): маршрутизация стадий (STAGE_TRANSITIONS/advance_stage), все Quality Gate'ы и под-гейты (check_*, security/merge/ coverage/image-freshness), парсеры вердиктов (_parse_* через frontmatter.py), классификатор ретраев (error_classifier.py), serial-gate/transition-lease/reconciler/reaper, а также две зарезервированные job-роли deploy-finalizer и post-deploy-monitor (перехватываются в launch_job до _spawn — это рабочий прецедент детерминированной замены агента).

Боль/риск, который закрывает задача: LLM на механических control path'ах — это (а) лишний источник недетерминизма и инцидентов (ложный вердикт/действие в точке ветвления), (б) задержка (запуск opus-агента вместо прямого вызова), (в) расход токенов/денег. При этом «вслепую» убирать LLM нельзя — часть путей несёт настоящее суждение (анализ, архитектура, написание кода, ревью), и автономность/гибкость должны сохраниться. Точный дискриминатор «убирать/оставить» — определение «avoidable LLM control path» (§0-bis).

ORCH-118 даёт доказательную карту «где LLM действительно нужен, а где это avoidable control path» и упорядоченный план безопасных замен — фундамент, на котором последующие срезы (по ролям-кандидатам) выполняются предсказуемо и без регресса.

2. Объём (scope)

В объёме

• BR-1 Полная инвентаризация всех мест вызова LLM и всех ролей-агентов (карта call-site'ов).
• BR-2 Классификация каждого call-site в один из 4 классов (keep / replace-now / replace-later / hybrid-fallback) с явным обоснованием, выведенным из control-path-оси (§0-bis): класс есть функция (C/P)-типа и деривируемости вердикта.
• BR-3 Доказательное подтверждение (с привязкой file:line), что не-агентские control-path'ы (маршрутизация / ретраи / QG / парсеры / finalizer'ы) уже детерминированы.
• BR-4 Упорядоченный roadmap замен: зависимости, оценка экономии токенов/времени, риски безопасности, потребность в hybrid-fallback, рекомендованный первый срез — кандидаты названы по роли (follow-up ID — TBD).
• BR-5 Нормативная политика использования LLM («LLM — только там, где нужно настоящее суждение») как durable-документ.
• BR-6 Структурные regression-тесты, прибивающие инварианты карты к коду (транспорт-агностичный двусторонний инвариант + control-path-ось) — анти-дрейф.
• BR-7 Явно позиционировать роль deployer и роль tester как кандидаты-follow-up для детерминированной замены — по роли, без привязки к конкретным Plane-ID (см. NFR-6).
• BR-8 (R5) Карта явно размечает каждую консультацию по оси (C) control-path / (P) artifact-producer с доказательством — кто потребляет вывод роли (check_*/_parse_* с file:line).
• BR-9 (R5) Карта/политика явно определяют термин «avoidable LLM control path» (двухбитный предикат §0-bis) и поимённо называют целевой набор {tester, deployer}, явно отделяя его от control-path-но-keep (reviewer) и от не-control-path (analyst/architect/developer).

Вне объёма

• ❌ Реализация детерминированных раннеров deployer / tester и любых других замен — это отдельные follow-up задачи ПОСЛЕ утверждения карты (явное требование заказчика в business request).
• ❌ Выдумывание/фиксация конкретных follow-up Plane-ID (напр. ORCH-115/ORCH-116) в любых артефактах ORCH-118 — ID присваиваются при заведении задач (NFR-6).
• ❌ Изменение STAGE_TRANSITIONS / реестра QG_CHECKS / семантики и имён check_* / machine-verdict-ключей (verdict:/result:/staging_status:/deploy_status:/security_status:/ coverage_status:) / схемы БД.
• ❌ Включение model-routing (G3 ORCH-41) или смена модели/эффорта ролей.
• ❌ Любая правка поведения src/** в рантайме (ORCH-118 — docs + tests only, по образцу ORCH-077/079/101/102/103/011).
• ❌ Снижение автономности или гибкости конвейера.

3. Заинтересованные стороны

• Заказчик / Owner — инициатор RCA-трека ORCH-114/117; принимает карту и roadmap (gate утверждения).
• Сопровождающие платформы (self-hosting) — выигрывают в стабильности, скорости, экономии токенов.
• Downstream-проекты (enduro-trails) — делят общий прод/очередь; для них требуется нулевая регрессия (NFR-1).
• Будущие исполнители follow-up'ов — потребители карты, roadmap и политики.

4. Бизнес-требования (BR)

• BR-1 — Инвентарь LLM-консультаций (call-site'ов). Выпустить durable-документ, перечисляющий каждое место, где control-path потребляет суждение LLM или может его потребить (единица — LLM-консультация, §0, а не «спавн процесса»): единственный транспорт _spawn, все 6 ролей-агентов и обе зарезервированные job-роли D1/D2 (включаются как доказательство «слот агента есть, но консультации LLM нет» — перехват до _spawn). Для каждого — file:line, триггер, стадия/владелец, выходной артефакт, machine-verdict-ключ (если есть), потребитель вывода (check_*/_parse_* с file:line), оценка токенов/времени, признак capability-vs-consultation (§0.3) и признак оси (C) control-path / (P) artifact-producer (§0-bis, BR-8). Проверяемо: каждый file:line резолвится в реальный код.
• BR-2 — Классификация. Каждому call-site присвоить ровно один класс из таксономии: keep-LLM (нужно настоящее суждение), replace-deterministic-now (безопасная замена сейчас), replace-later/risky (замена позже / рискованно), needs-hybrid-fallback (детерминированное ядро + LLM-фолбэк на суждение). Класс выводится из control-path-оси (§0-bis): P → keep-LLM (артефактная авторская работа); C + не-деривируемый вердикт → keep-LLM (reviewer); C + деривируемый вердикт → replace-* / needs-hybrid-fallback (tester/deployer = avoidable). Для keep-LLM — назвать конкретное суждение, ради которого LLM сохраняется (для C-keep — почему вердикт не деривируем).
• BR-3 — Подтверждение детерминизма не-агентских путей. Документально, с file:line-доказательством, зафиксировать, что маршрутизация стадий, ретраи, QG-проверки, парсеры вердиктов и finalizer'ы не консультируют LLM (не зависят от суждения LLM — ни через _spawn, ни через иной транспорт; их subprocess-вызовы git/pytest/docker/ssh/сканеров — детерминированные инструменты, не LLM, §0). Если инвентаризация найдёт неожиданную LLM-консультацию — она попадает в карту (BR-1) и классификацию (BR-2).
• BR-4 — Упорядоченный roadmap. Ранжированный план замен: для каждого кандидата (названного по роли) — зависимости, оценка экономии токенов/времени (из телеметрии agent_runs), риск безопасности, нужен ли hybrid-fallback, ожидание kill-switch/обратимости. Явно указать рекомендованный первый срез и обоснование выбора (опора на control-path-вывод: первым берётся самый «чисто деривируемый» control path). Привязка к follow-up задаче — по роли; конкретный Plane-ID НЕ фиксируется (заводится отдельно, NFR-6).
• BR-5 — Политика использования LLM. Нормативный durable-документ: «LLM — только там, где требуется настоящее суждение»; критерии решения keep vs replace, сформулированные через ось §0-bis (является ли путь control path; деривируем ли вердикт); требование к новым/изменённым control-path'ам обосновывать любое использование LLM против этой политики.
• BR-6 — Анти-дрейф структурными тестами. Тесты, привязывающие инварианты карты к коду: транспорт-агностичный двусторонний инвариант единственной точки (§0); перечисленные детерминированные модули/job-роли не несут LLM-консультации; карта перечисляет ровно те 6 промптов, что лежат в .openclaw/agents/; тотальность классификации; плюс control-path-ось (R5): карта размечает каждую роль (C/P) согласованно с фактическим потребителем в src/qg/checks.py, а avoidable-набор = {tester, deployer}. Тесты — offline. Тест на привязку к конкретным follow-up ID не вводится (анти-паттерн R3).
• BR-7 — Позиционирование follow-up'ов по роли. Карта/roadmap явно отмечают роль deployer и роль tester как кандидаты-замены, не реализуемые в ORCH-118; их старт гейтится утверждением карты. Привязка — по роли, без конкретных Plane-ID (NFR-6).
• BR-8 (R5) — Явная control-path-разметка. Карта несёт для каждой консультации поле оси (C) control-path / (P) artifact-producer + доказательство (потребитель вывода с file:line). Разметка проверяема структурным тестом против src/qg/checks.py (BR-6, TC-13).
• BR-9 (R5) — Явное определение «avoidable LLM control path» и поимённый целевой набор. Карта/ политика дают нормативное определение термина (двухбитный предикат §0-bis) и поимённо называют {tester, deployer} как avoidable, явно отделяя их от reviewer (control path, keep) и от analyst/architect/developer (не control path). Набор проверяем тестом (BR-6, TC-14).

5. Нефункциональные требования (NFR)

• NFR-1 — Сохранение поведения (нулевая регрессия). ORCH-118 — docs+tests only: STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict-ключи/схема БД — байт-в-байт; поведение конвейера 1:1; enduro-trails не затронут.
• NFR-2 — Сохранение автономности и гибкости. Ни инвентаризация, ни политика не должны предлагать решений, снижающих автономный/пакетный режим (ORCH-088/089) или гибкость; политика защищает автономность как инвариант любой будущей замены.
• NFR-3 — Self-hosting безопасность. Задача только читает код и пишет docs+tests — не деплоит, не рестартит прод-контейнер, не трогает main/force-push, не запускает процессов/сети.
• NFR-4 — Трассируемость и сопровождаемость. Карта привязана к коду маркерами/тестом и остаётся честной при эволюции кода; формат — по docs/_standards/PIPELINE_DOCS.md и TRACEABILITY.md.
• NFR-5 — Доказательность экономии. Цифры экономии берутся из реальной телеметрии agent_runs (модель/эффорт/токены/стоимость/время по ролям) и помечаются как оценки до фактического замера после реализации.
• NFR-6 — Только проверяемые ссылки (анти-фабрикация, R3). В артефактах фиксируются только ссылки, резолвящиеся в код/документы репозитория. Конкретные follow-up Plane-ID не выдумываются: кандидаты-замены именуются по роли; ID присваивается при заведении задачи. (Это закрывает корень отклонённой ревизии R2.)
• NFR-7 (R5) — Контроль-ориентированность определений. «LLM control path» и «avoidable» определяются через потребление вывода потоком управления (кто из check_* ветвится на выводе), а не через «есть ли вообще LLM-вызов на стадии». Любое утверждение «это avoidable LLM control path» обязано резолвиться в конкретный check_*/_parse_* + tool-сигнал, из которого вердикт деривируем.

6. Допущения и ограничения

• Единственный транспорт LLM сейчас — Claude CLI через launcher._spawn; прямых вызовов Anthropic API в src/** нет (подтверждается инвентаризацией).
• Model-routing не включён — все 6 ролей на claude-opus-4-8 (ORCH-41), что упрощает оценку экономии.
• Карта — снимок на момент задачи, защищённый структурными тестами от тихого расхождения с кодом.
• Прецедент детерминированной замены агента уже существует и работает (deploy-finalizer/ post-deploy-monitor в launch_job до _spawn) — это снижает архитектурный риск follow-up'ов.
• На момент анализа конкретные follow-up work item для замены ролей в backlog не подтверждены — поэтому ID не фиксируются (NFR-6).
• (R5) Control-path-разметка опирается на ground-truth src/qg/checks.py на момент задачи; при эволюции кода её честность держит структурный тест (TC-13/TC-14).

7. Критерии успеха

Карта LLM-консультаций полна и привязана к коду, и разводит три ортогональных факта: транспорт/слот («процесс Claude CLI существует», R4 §0), факт консультации, и — control-path-ось (R5 §0-bis): потребляется ли LLM-вывод потоком управления (check_* ветвится на нём) или его независимо судит детерминированный гейт. Термин «avoidable LLM control path» явно определён (двухбитный предикат) и целевой набор поимённо назван {tester, deployer} с доказательным отделением от reviewer (control path, keep) и от analyst/architect/developer (не control path). Каждый site классифицирован с обоснованием, выведенным из этой оси; детерминизм не-агентских путей доказан (отсутствием LLM-консультации, не отсутствием subprocess); есть упорядоченный roadmap с зависимостями/экономией/ рисками и рекомендованным первым срезом (кандидаты — по роли); есть нормативная политика; структурные тесты зелёные и осмысленные (инвариант единственной точки транспорт-агностичен и двусторонен; control-path -разметка сверена с src/qg/checks.py; avoidable-набор зафиксирован); ни один рантайм-инвариант не тронут; раннеры замен НЕ реализованы; ни один артефакт не фиксирует непроверяемых follow-up ID. Детальные PASS/FAIL — в 03-acceptance-criteria.md.

8. Риски

• Недо-/пере-классификация (LLM убран там, где нужно суждение, или сохранён там, где не нужен) → митигирует control-path-вывод (§0-bis: класс выводится из (C/P)-типа и деривируемости вердикта, а не «на глаз») + требование «назвать конкретное суждение» для keep-LLM + ревью карты.
• Конфляция «есть LLM на стадии» с «это control path» (рецидив корня R4-блокера) → митигирует явная разметка оси и тест TC-13 (сверка с фактическим потребителем check_*).
• Дрейф карты относительно кода со временем → митигируют структурные тесты (BR-6), включая control-path-инварианты (TC-13/TC-14).
• Преждевременная замена в погоне за экономией ценой автономности/гибкости → инвентаризация отделена от реализации; первый срез — самый низкорисковый «чисто деривируемый» control path.
• Фабрикация ссылок/ID (рецидив дефекта R2) → митигирует NFR-6 (только проверяемые ссылки; follow-up'ы — по роли) и ревью. Детали техн.рисков — 10-tech-risks.md (архитектор).