orchestrator/docs/work-items/ORCH-118/03-acceptance-criteria.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

03 — Критерии приёмки (Acceptance Criteria): ORCH-118 — replace avoidable LLM control paths with deterministic implementations

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

Формат: каждый критерий имеет PASS (что должно быть истинно для приёмки) и FAIL (что считается провалом). Reviewer/тестер проверяет их буквально по файлам репозитория. Напоминание: ORCH-118 — inventory-first, docs+tests only; реализация раннеров приёмкой запрещена в этой задаче (AC-7); фиксация конкретных follow-up Plane-ID запрещена (AC-9, R3).

🔁 R5. Добавлены/уточнены критерии под control-path-ось (BRD §0-bis): среди реальных консультаций различаются (C) control-path (LLM-вердикт потребляется потоком управления) и (P) artifact-producer (детерминированный гейт судит артефакт); термин «avoidable LLM control path» явно определён, целевой набор {tester, deployer} поимённо назван. Затронуты AC-1, AC-2 и новый AC-10; добавлены тесты TC-13/TC-14.

---

AC-1 — Полнота и привязка инвентаря LLM-консультаций (+ control-path-разметка)

Условие: Документ-карта перечисляет каждый call-site, где control-path потребляет (или способен потребить) суждение LLM — единица = LLM-консультация, не «спавн процесса» (R4) — с обязательными полями, привязанными к коду, включая ось (C/P) и потребителя вывода (R5).

• PASS: Карта содержит S0 (launcher._spawn — единственный транспорт LLM-консультации), все 6 ролей (analyst/architect/developer/reviewer/tester/deployer, консультируют через S0) и обе job-роли (deploy-finalizer/post-deploy-monitor, помеченные «занимают слот агента, но LLM не консультируют» — перехват до _spawn); у каждой записи заполнены location (file:line) / trigger / stage/owner / output / machine-verdict key (если есть) / output consumer (check_*/_parse_* с file:line) / est. tokens-runtime / consults-LLM / axis (C control-path / P artifact-producer) / classification / rationale; каждый file:line резолвится в реальный код. Карта явно разводит «транспорт/слот существует» и «LLM фактически консультируется» (§0) и «consultation входит в поток управления (C)» vs «детерминированный гейт судит артефакт (P)» (§0-bis).
• FAIL: Пропущен любой call-site; отсутствует любое обязательное поле (включая output consumer или axis); file:line не резолвится; карта смешивает «процесс Claude CLI существует» с «LLM-консультация происходит» (напр. помечает D1/D2 консультирующими LLM); или не размечает ось C/P (напр. называет analyst «control path», или не доказывает потребителем check_*); заявлен второй транспорт LLM, не подтверждённый кодом.

---

AC-2 — Классификация по таксономии (4 класса, тотально и однозначно, выведена из control-path-оси)

Условие: Каждый перечисленный call-site отнесён ровно к одному классу с обоснованием, выведенным из оси §0-bis.

• PASS: Таксономия определена явно (keep-LLM / replace-deterministic-now / replace-later/risky / needs-hybrid-fallback); каждому site присвоен ровно один класс; класс согласован с осью: P → keep-LLM (analyst/architect/developer), C + не-деривируемый вердикт → keep-LLM (reviewer, с названным конкретным суждением, не сводимым к exit-коду), C + деривируемый вердикт → replace-*/hybrid (tester/deployer); у keep-LLM-записей назван конкретный вид суждения, ради которого LLM сохраняется.
• FAIL: Site не классифицирован / классифицирован дважды; класс вне таксономии; keep-LLM без названного суждения; класс противоречит оси (напр. control-path-deployer помечен keep-LLM без доказательства не-деривируемости вердикта, или artifact-producer-analyst помечен replace-*).

---

AC-3 — Доказанный детерминизм не-агентских путей

Условие: Карта отдельно фиксирует, что control-path'ы вне 6 агентов не консультируют LLM, с доказательством.

• PASS: Перечислены маршрутизация (advance_stage/STAGE_TRANSITIONS), все QG_CHECKS/check_*, парсеры _parse_*, error_classifier, под-гейты (security/merge/coverage/image-freshness), self_deploy Phase A/B/C, reconciler/reaper/serial-gate/transition-lease — каждый с file:line, подтверждающим отсутствие LLM-консультации (ни _spawn-транспорта, ни альтернативного). Их subprocess-вызовы инструментов (git/pytest/docker/ssh/сканеры) явно квалифицированы как не-LLM (детерминизм доказывается отсутствием LLM-транспорта, а не отсутствием subprocess).
• FAIL: Утверждение о детерминизме без file:line-доказательства; путь, заявленный детерминированным, фактически консультирует LLM (и это не отражено в инвентаре/классификации); либо детерминизм «доказан» простым отсутствием subprocess (подмена дискриминатора, §0).

---

AC-4 — Упорядоченный roadmap с обязательными атрибутами и первым срезом

Условие: Есть ранжированный roadmap детерминированных замен.

• PASS: Roadmap упорядочен; для каждого кандидата (названного по роли) указаны зависимости, оценка экономии токенов/времени (со ссылкой на источник — agent_runs/usage), риск безопасности, потребность в hybrid-fallback, ожидание kill-switch/обратимости и тип follow-up задачи по роли (без конкретного Plane-ID); явно назван рекомендованный первый срез с обоснованием (самый низкорисковый «чисто деривируемый» control path).
• FAIL: Roadmap не упорядочен; у кандидата отсутствует любой обязательный атрибут; оценка экономии не привязана к источнику; нет рекомендованного первого среза; кандидат привязан к выдуманному Plane-ID (→ см. AC-9).

---

AC-5 — Нормативная политика использования LLM

Условие: Существует durable-документ политики.

• PASS: Политика формулирует принцип «LLM — только где нужно настоящее суждение», даёт критерии решения keep vs replace через ось §0-bis (control path ли это; деривируем ли вердикт) и требование обосновывать любое новое использование LLM против политики; документ нормативный (durable, в docs/), а не разовая заметка.
• FAIL: Политика отсутствует; не нормативна; не опирается на control-path-критерий; противоречит сохранению автономности (NFR-2).

---

AC-6 — Структурные анти-дрейф тесты: зелёные и осмысленные

Условие: Новый offline-тест-файл прибивает инварианты карты к коду; инвариант сформулирован вокруг LLM-консультации/транспорта (R4) и control-path-оси (R5), а не «существования процесса Claude CLI».

• PASS: Тесты проверяют: (a) единственный транспорт LLM-консультации в src/** (= launcher._spawn); (f) отсутствие любого иного LLM-транспорта (нет импорта anthropic/openai/LLM-SDK, нет прямого HTTP-эндпоинта Anthropic/Claude, нет второго model-invoking subprocess-сборщика); (b) отсутствие LLM-консультации в перечисленных детерминированных модулях и в обработчиках deploy-finalizer/ post-deploy-monitor; (c) двустороннюю сверку списка промптов карты с .openclaw/agents/; (d) тотальность классификации; (e) перехват D1/D2 в launch_job до _spawn; (g) корректность control-path-разметки (TC-13) — axis каждой роли согласован с фактическим потребителем в src/qg/checks.py (P-роли → check_analysis_complete/check_architecture_done/check_ci_green; C-роли → check_reviewer_verdict/_parse_tests_verdict/_parse_staging_status/_parse_deploy_status); (h) фиксацию avoidable-набора (TC-14) — множество avoidable LLM control paths = {tester, deployer}, reviewer = control-path-keep, analyst/architect/developer = не control path. Дискриминатор тестов — «консультирует LLM», а не «спавнит subprocess». Тесты не используют сеть/LLM/subprocess-к-модели. Полный pytest tests/ -q — зелёный.
• FAIL: Тестов нет; тест тривиально проходит (не привязан к коду); инвариант проверяет лишь «один Popen Claude CLI» без (f); отсутствует control-path-инвариант (g/h) — карта могла бы помечать analyst «control path» или забыть deployer в avoidable-наборе, и тест бы это пропустил (корень R4-блокера); тест выродился в «подсчёт всех subprocess»; любой тест красный; полный прогон tests/ падает; введён тест, прибивающий карту к конкретным follow-up Plane-ID (анти-паттерн R3).

---

AC-7 — Скоуп и сохранение поведения

Условие: ORCH-118 не меняет рантайм и не реализует раннеры.

• PASS: Диф не меняет STAGE_TRANSITIONS / реестр и имена QG_CHECKS/check_* / machine-verdict-ключи / схему БД; в src/** нет нового детерминированного раннера tester/deployer (раннеры замен не реализованы); изменения ограничены docs + новый(е) тест-файл(ы).
• FAIL: Изменён любой из перечисленных рантайм-контрактов; реализован детерминированный раннер замены; правки src/**-поведения вне инвентаря/тестов.

---

AC-8 — Синхронизация golden-source документации

Условие: Обзорные/архитектурные доки и CHANGELOG отражают новые артефакты.

• PASS: docs/architecture/README.md и витрина docs/overview/* ссылаются на карту call-site'ов и политику использования LLM; CHANGELOG.md обновлён в том же PR.
• FAIL: Карта/политика введены, но golden-source доки/витрина/CHANGELOG не обновлены (ось ORCH-079/ ORCH-011 → finding ≥P1).

---

AC-9 — Только проверяемые ссылки; follow-up'ы — по роли, без выдуманных ID (анти-фабрикация, R3)

Условие: Ни один артефакт не фиксирует непроверяемых follow-up Plane-ID; кандидаты-замены именуются по роли.

• PASS: Везде, где карта/BRD/TRZ/roadmap/ADR упоминают кандидата-замену, он назван по роли (deployer-замена, tester-гибрид); конкретные follow-up Plane-ID не указаны; все file:line/ ссылки на документы резолвятся в репозиторий. Тип follow-up'а описан по роли, ID — «TBD / при заведении задачи».
• FAIL: Любой артефакт фиксирует конкретный follow-up Plane-ID (напр. ORCH-115/ORCH-116) как нормативную привязку роли; присутствует ссылка/маркер, не резолвящийся в код/документ репозитория; введён структурный тест, прибивающий карту к конкретному follow-up ID.

Контекст: AC-9 заменяет ранее ошибочный «канонический-маппинг» критерий ревизии R2. Корень отклонения R2 — фиксация несуществующих ID (ORCH-115/ORCH-116) как нормативного инварианта с непроверяемым источником («live Plane backlog»). R3 запрещает фабрикацию ID и переводит follow-up'ы на именование по роли.

---

AC-10 (R5) — Явная control-path-ось и определение «avoidable LLM control path»

Условие: Артефакты явно различают control-path-консультации и artifact-producer-консультации и явно определяют целевой термин — это закрывает единственный оставшийся блокер R4-ревью (название задачи — «replace avoidable LLM control paths»).

• PASS:
  1. Ось определена и применена. Карта/политика явно вводят ось (C) control-path (LLM-вердикт потребляется потоком управления — check_* ветвится на нём) vs (P) artifact-producer (детерминированный гейт судит артефакт; суждение LLM в control flow не входит), и присваивают ровно один тип каждой из 6 ролей с доказательством-потребителем (check_*/_parse_*, file:line): P = analyst/architect/developer; C = reviewer/tester/deployer.
  2. Термин определён. Дано нормативное определение «avoidable LLM control path» = двухбитный предикат: (i) C-консультация И (ii) вердикт деривируем из tool-сигналов (exit-code pytest/ smoke/staging_check.py/деплоя).
  3. Целевой набор поимённо назван. Артефакты явно называют avoidable LLM control paths = {tester, deployer}, и явно отделяют: reviewer — control path, но keep (вердикт не деривируем, настоящее суждение); analyst/architect/developer — не control path (artifact-producer). Это согласовано с классификацией (AC-2) и закреплено тестами TC-13/TC-14.
• FAIL: Артефакты упоминают «LLM control paths» без явного определения; не размечают ось C/P по ролям или размечают её без доказательства-потребителя; не определяют «avoidable» как проверяемый предикат; не называют поимённо целевой набор {tester, deployer} или не отделяют его от reviewer (control-path-keep) и от analyst/architect/developer (не control path); разметка не согласована с src/qg/checks.py / не закреплена TC-13/TC-14.

---

Сводная матрица AC ↔ FR/BR

AC	Покрывает
AC-1	BR-1 / FR-1 / BR-8 / FR-8
AC-2	BR-2 / FR-2 (выведена из §0-bis)
AC-3	BR-3 / FR-3
AC-4	BR-4 / FR-4
AC-5	BR-5 / FR-5
AC-6	BR-6 / FR-6 (вкл. TC-13/TC-14)
AC-7	BR-7 / FR-7 / NFR-1 / NFR-3
AC-8	NFR-4 / правила агентов §2,§6 (golden-source)
AC-9	NFR-6 / BR-7 / FR-7 (только проверяемые ссылки; follow-up'ы по роли, без выдуманных ID)
AC-10	BR-8 / BR-9 / FR-8 / NFR-7 (R5 — control-path-ось + определение «avoidable»)