claude-bot
9710d5f80d
ORCH-118 (inventory-first, docs+tests only): publish an evidence-based map of
every place the orchestrator's control flow consumes (or can consume) an LLM
judgment, mark the control-path axis (C control-path vs P artifact-producer),
define "avoidable LLM control path" as a checkable two-bit predicate, classify
each call-site, and order the deterministic-replacement roadmap. Pin the map to
code with offline structural anti-drift tests.
- docs/architecture/llm-call-sites.md — map + machine-readable inventory block
+ control-path axis + classification + keep-LLM justifications + deterministic
non-agent paths (FR-1/FR-2/FR-3/FR-8).
- docs/architecture/llm-determinization-roadmap.md — ordered candidates BY ROLE,
savings sourced from agent_runs, recommended first slice = deployer staging
(FR-4). No fabricated follow-up Plane-IDs (R3/NFR-6).
- docs/architecture/llm-usage-policy.md — normative principle, keep/replace
criteria via the axis, definition of "avoidable LLM control path" (FR-5/FR-8).
- tests/test_llm_call_site_inventory.py — TC-01/02/03/04/05/06/09/12/13/14.
- tests/test_llm_determinization_docs.py — TC-07/08/11.
- CHANGELOG.md + docs/overview/tech-quality-security.md — golden-source sync (AC-8).
Avoidable LLM control paths = {tester, deployer}; control-path-keep = {reviewer};
not-control-path (P) = {analyst, architect, developer}. Single LLM transport =
launcher._spawn (S0); no alternative transport (TC-12). Runtime untouched:
STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict keys / DB schema are
byte-for-byte; no replacement runners implemented (FR-7). Full suite: 2081 passed.
Refs: ORCH-118
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5.7 KiB
LLM determinization roadmap (ORCH-118)
Что это. Упорядоченный план детерминированных замен avoidable LLM control paths (
{tester, deployer}— см.llm-call-sites.md). Это транзиентный план: он обновляется по мере закрытия follow-up'ов. ORCH-118 раннеры не реализует (FR-7); старт каждого кандидата гейтится утверждением карты.Кандидаты названы ПО РОЛИ. Конкретные follow-up Plane-ID не фиксируются ни в одном артефакте (R3 / NFR-6): этих work item нет в подтверждённом backlog; ID присваивается при заведении задачи. Анти-фабрикация прибита тестом
TC-11(tests/test_llm_determinization_docs.py).Оценки экономии — «оценка до фактического замера» (NFR-5). Источник — существующие колонки
agent_runs(model/effort/токены/стоимость/время); точные числа снимаются при заведении follow-up'а черезGET /metrics/ запрос кagent_runs. Здесь — порядок величины, а не контракт.
1. Рекомендованный первый срез — deployer (staging-status)
Обоснование (самый низкорисковый «чисто деривируемый» control path):
- Деривируемость максимальна. Вердикт
staging_status:— чистый маппинг exit-кодаscripts/staging_check.py; готовый leafsrc/staging_verdict.py::compute_staging_verdict(ORCH-061) уже считает этот вердикт детерминированно. - Прод уже детерминирован. Ребро
deploy(deploy_status:) для self-hostingorchestratorпроизводит детерминированный finalizer (Phase A/B/C, ORCH-036) — LLM в критическом self-restart-пути нет. Срез не трогает критический путь → минимальная поверхность риска. - Опирается на прецедент
D1/D2(launch_job-перехват до_spawn) — архитектурный риск замены агента уже снят рабочим паттерном. replace-deterministic-now, без hybrid-fallback (в отличие от tester).
2. Второй кандидат — tester (гибрид)
Детерминированное ядро (pytest + smoke даёт PASS/FAIL по exit-коду) покрывает основной вердикт;
LLM-фолбэк сохраняется только на суждение, не сводимое к exit-коду: триаж падений и маппинг
TC ↔ критерии приёмки. Поэтому needs-hybrid-fallback, а не replace-deterministic-now: поверхность
суждения шире и объём работы больше.
3. Общие требования к каждому follow-up'у
Каждый кандидат при заведении задачи несёт: kill-switch + обратимость (паттерн
ORCH-022/027/043/089/090 — флаг *_enabled, пустой CSV *_repos → self-hosting only), скоуп-гард
(не трогать STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/схему БД), а замена-агента —
перехват в launch_job до _spawn (как D1/D2). Свежесть прецедента — инцидент-трек
ORCH-110/111/112/113/114/117 (единое детерминированное владение side-effectful путями).
4. Машинно-читаемый блок roadmap
Заголовок (
rank | role | dependencies | savings_estimate_source | security_risk | hybrid_needed | followup_type | first_slice) парситсяtests/test_llm_determinization_docs.py::test_tc07_*.followup_type— по роли, без Plane-ID. Ровно одинfirst_slice = yes.
| rank | role | dependencies | savings_estimate_source | security_risk | hybrid_needed | followup_type | first_slice |
|---|---|---|---|---|---|---|---|
| 1 | deployer | staging_verdict.compute_staging_verdict (ORCH-061) + launch_job pre-spawn precedent (D1/D2) | agent_runs (deployer rows; estimate pending GET /metrics) | low (prod already deterministic via Phase A/B/C ORCH-036) | no | deployer-replacement (staging-status mapping) | yes |
| 2 | tester | deterministic pytest+smoke core; LLM fallback for failure triage / TC-to-criteria mapping | agent_runs (tester rows; estimate pending GET /metrics) | medium (failure-triage judgment must stay correct) | yes | tester-hybrid (deterministic core + LLM fallback) | no |
5. Вне scope
reviewer— C, но keep (вердикт «приемлемость кода/решения» не деривируем): не в roadmap'е.analyst/architect/developer— P (artifact-producer, не control path): не в roadmap'е.- Реализация раннеров — отдельные follow-up задачи (по роли), стартуют после утверждения карты.
Связанные документы: llm-call-sites.md, llm-usage-policy.md.