feat(plan): 接通 plan-critic 真实 subagent runner

[1-ztc]

做了什么

把 plan-critic 的 makeSubagentRunner 从 throwing placeholder 换成真实 ctx.spawnSubagent 调用——critic 终于能真跑(default 仍 off)。这是把"规划质量校验"从空壳框架变成可执行实验的临门一脚。

背景

critic 之前(feature/plan-completion-gate 上的 3859849)是 default-off + fail-open 的框架,但 runner 是 throw 空壳——当时判断"createSubAgentRunner 是 host-deps 工厂,没法从工具调"。探查后发现这判断不成立:moss 已有 ctx.spawnSubagent(ToolContext,create_subagent 工具在用),critic 该走同一条路。唯一缺口:spawnSubagent 签名没有 systemPrompt 参数,critic 要传自己的 critique prompt。

改动(沿 spawnSubagent → createSubAgentRunner 链路加 systemPromptOverride)

1. tool-types.ts — spawnSubagent 签名加 systemPromptOverride?: string
2. subagent-orchestrator.ts — SubAgentConfig 加 systemPromptOverride?: string
3. moss-agent.ts — spawnSubagent 闭包透传 params.systemPromptOverride 进 runner config
4. subagent-runner.ts — createSubAgentRunner 用 config.systemPromptOverride 覆盖子 agent systemPrompt(override 时 childSystemPromptParts 设 undefined,不破坏 prefix-cache 切分)
5. plan-tools.ts — makeSubagentRunner 接真实 ctx.spawnSubagent:scope: "plan"(read-only)、maxTurns: 2(critic 一轮出 JSON,2 轮覆盖偶发截断,不让它漂移成执行)、systemPromptOverride: critic prompt

cherry-pick 自 3859849:plan-critic.ts/plan-critic-prompt.ts/19-plan-mode.md/plan-critic.spec.mjs(无冲突,从 main 干净开)。

设计决定

• maxTurns=2:critic 是一轮评审(读 plan+任务→吐 issues JSON),不是多步探索。给 2 是覆盖偶发截断的安全垫;多了会让 critic 漂移成执行、且 approve 同步阻塞成本上涨。不是越多越好。
• scope=plan:read-only,critic 只评审不写代码。
• default off 仍保持:接通 ≠ 启用。MOSS_PLAN_VALIDATE 默认关,主线零影响;fail-open 保证任何 critic 故障不阻塞 approve。

测试

9 个 spec 全过(含关键回归:subagent-completion-gate 真起 createSubAgentRunner,改签名后没坏)。build + typecheck 干净。端到端:MOSS_PLAN_VALIDATE=on + 真实 provider(DeepSeek)跑 6 步 plan 任务,is_error:false 不崩不挂。

已知限制

• critic 真实收益未验证:接通只是前提。真 A/B 要控变量 eval fixture + N≥3,另说。
• 同主模型:未接 criticModel 字段,首轮同模型测"critic 这层本身有没有用";换更强模型留后续。
• plan-critic-integ.spec.mjs 是接线 smoke(off baseline + on 不崩),issues 阻止 approve 路径靠 mock provider 测不出(单元 runPlanCritique 已覆盖)。

🤖 Generated with Claude Code