chore(runtime): delete steering-drivers — subsumed by registry directives; driverAgent/supervisorAgent stay (they are the engine)

[drewstone]

Stacked on #713. The measured outcome of the legacy-deletion pass, including the finding that corrects the original kill-list:

• Deleted: src/runtime/steering-drivers.ts (+ its test file) — per-round steering expressed as code, genuinely subsumed by registry directives on graph edges. Net −570 LOC. The one live consumer (define-leaderboard) migrated to a behavior-identical naiveRetryDriver (plan order, decide logic, rationale string all diffed equal against the deleted source); 5 of 8 deleted tests ported with strengthened assertions, 3 obsolete with proof (zero dumbDriver consumers repo-wide).
• Kept, with the reason on record: driverAgent and supervisorAgent are NOT parallel legacy surfaces — they are the execution engine runGraph runs through (runGraph → supervise() → supervisorAgent → driverAgent; the external-harness driver arm exists only there). The kill-list's "~6 consumers each" were mostly doc-comment mentions. Deleting them would be re-implementing ~1,545 LOC inside supervise.ts — a move, not a deletion.

Adversarially audited SHIP (5/5 probes held: behavior-diff, kill-test successors, zero dangling references, gates, kept-surface verification). Review LOWs fixed: stale "steering directive" wording, historical commentary replaced with current-contract wording.

0.125.0. Suite 2352; all gates + version bump green.

[tangletools]

✅ Auto-approved drewstone PR — ab3f91b9

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-03T07:27:01Z}

[tangletools]

✅ Auto-approved drewstone PR — ab3f91b9

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-03T07:27:03Z}

The base branch was changed.

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	169.9s (2 bridge agents)
Total	169.9s

💰 Value — sound

删除了一个现在多余的循环内核控制模块，并为图分析边增加了一种连贯的新形式（配备工具的代理节点），两者都符合代码库的风格。

• What it does: 同一 PR 中包含两个截然不同的变更，跨越四个提交和两个次要版本（0.124.0 特性，0.125.0 删除）：

1. 删除：移除了 src/runtime/steering-drivers.ts（泄漏无信号控制驱动程序——naive/dumb——及其共享解释器 steeringDriver）。策略文本已作为注册表数据（delegates/naive-continuation，delegates/dumb-continuation-pass/-fail）存在，图边将其作为带版本的指令附加；最后一个使用者 (defineLeaderboard) 获得了一个内联的 naiveRetryDriver，其 plan/decide/rationale 与被删除的代码字节等价（已验证：plan 返回 [task] 在 shot 0，shot>0 时返回 []/

• Goals it achieves: 1. 移除现在多余的抽象层。Steering-driver 解释器曾是注册表指令数据与循环内核 Driver 接口之间最后的纯代码桥梁；策略已经是可优化的注册表行，且每个调用点的控制逻辑微不足道，足以作为裸 Driver 字面量存在（leaderboard 的 15 行内联代码）。

2. 将分析器从纯函数泛化为“纯函数或配备工具的代理”，填补了矩阵中唯一一个连贯的空白单元：在变更之前，分析器要么是环境提供的 lens（纯函数，无工具），要么是驱动程序生成的“审查者”（oracle-doctrine 违规——驱动程序控制任务，可以扭曲分析）。新形式是图声明的（拓扑数据，而非驱动程序生成）且配备工具的（可以使用其配置文件授予的任何工具进行调查）。

3. 关闭缺失的透传缺口：supervise() 已经接受了 watchWorkers，但 RunGraphOptions

• Assessment: 这两个变更都是连贯的，符合 runGraph 层既定的设计规则（节点固定、可观察边、作为数据的指令、oracle 主义）。

删除：真实且完整。全局搜索对 steeringDriver|naiveDriver|dumbDriver|SteeringDirectiveData|SteeringDecision|ApplyContinuation|NaiveDriverOptions|DumbDriverOptions 返回零命中 (rg --type ts)。defineLeaderboard 迁移在行为上是相同的，并且移植的测试 (src/runtime/define-leaderboard.test.ts:326-361) 维护了泄漏无防火墙探测（驱动程序读取 verdict.notes/verdict.scores 时抛出异常）。将 `driverAgent

• Better / existing approach: none — this is the right approach. 已寻找现有的等效项和更简单的设计，均未发现：

• 现有的 run_analyst MCP 工具 (src/mcp/tools/coordination.ts:2163) 是按需的纯 LENS 路径——它调用 opts.analysts.run(kind, store)，一个同步的纯函数。不存在现有的代理分析器形式；这是新功能，不是重复实现。

• 替代方案“扩展 AnalystRegistry 以支持代理支持的 lens”（一个 runAgent 方法）会将生成机制（Scope.spawn、预算、makeWorkerAgent）泄漏到纯函数注册表中——这是一种分层违规。所选择的拆分（lens = 注册表中的纯函数；代理 = 协调层中生成的工作进程）保持了每一层的整洁。

• 替代方案“让驱动程序

• Model: opencode/zai-coding-plan/glm-5.2

• Bridge attempts: 2

• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

A coherent two-part change: deletes a genuinely-subsumed 570-LOC steering-drivers layer via a behavior-preserving migration to a 25-LOC naiveRetryDriver, and lands an in-grain generalization (analyst-as-graph-NODE + watchWorkers passthrough) reachable through the kernel's runGraph entry.

• Integration: Fully reachable. naiveRetryDriver is consumed NOW at src/runtime/define-leaderboard.ts:562 (the one migrated call site). The analyst-as-NODE form is reached via runGraph → validateGraph → AnalyzeOnSettleRoute.agent → spawnAnalystRun (src/mcp/tools/coordination.ts:955, invoked at :1171), exercised by examples/graphs/analyst-agent-review.ts and the inspector tests in tests/kernel/graph.test.ts. The
• Fit with existing patterns: Fits the established patterns rather than competing with them. (1) It generalizes the analyzes edge's analyst reference from 'registry lens only' to 'lens OR node' while preserving the oracle doctrine structurally — validateGraph refuses a delegates-target/root/ambiguous/analyzed analyst (src/runtime/supervise/graph.ts:352-410), so an analyst node can never receive driver work. (2) watchWorkers cl
• Real-world viability: Holds on realistic paths. Refusal and failure are observable, not silent: spawnAnalystRun publishes {analystSpawnRefused} / {analystRunFailed} as finding events (src/mcp/tools/coordination.ts:996, 947). The analyst spawn rides the SAME scope.spawn + makeWorkerAgent machinery as a driver spawn, so spend conservation, journaling, and tracing are inherited. The post-loop drain correctly converts an i
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260803T073241Z}