superpowers SDD 任务级评审调度设计：让每个任务的代码评审变便宜而不失守

本文基于 superpowers 仓库的设计文档 2026-06-09-sdd-task-scoped-review-dispatch-design.md，完整拆解 subagent-driven-development（SDD）技能"任务级评审调度"的改造设计：问题诊断、目标与非目标、三轮成本迭代的完整数据，以及四处 prompt 文件的具体改动。读完后你将掌握一套可迁移到任何多 Agent 开发流水线的成本控制方法——用 diff 优先阅读、命名风险门控、测试预算和证据规则，把每个任务上的评审开销压低 30% 以上，同时保持发现缺陷的能力不变。

背景与问题：为什么 per-task 评审这么贵

SDD 的核心循环是：每个任务派发一个全新的 implementer 子代理，任务完成后派发评审子代理，所有任务完成后再做一次宽口径的整分支评审。设计文档基于两个真实本地 SDD 会话（sen-core-v2 和 serf，会话记录位于 ~/.claude/projects/）给出了成本证据：

• 在 sen-core-v2 会话中，8 个质量评审者里有 7 个做了仓库范围的 grep，最贵的一次跑了 50+ 条 Bash 命令、耗时约 200 秒；两个会话中质量评审的成本是同任务上规格评审（spec reviewer）的 4～8 倍；
• 而规格评审者的 prompt 里有一句 "Only read files in this diff. Do not crawl the broader codebase"，它们保持了收敛：6～16 次工具调用，14～65 秒；
• 没有任何评审者自主跑过重型测试——所有观察到的整包测试或重复测试，都是 controller 在 prompt 里显式要求的（"check all uses"、"run tests if useful, especially race-focused ones"、"does anything else read Meta()?"）。

文档按影响力排序给出了四个根因：

1. per-task 质量 prompt 继承了"合并就绪"评审框架。当时的 code-quality-reviewer-prompt.md 委托给 code-reviewer.md，后者询问架构、可扩展性、安全、生产就绪度，并以 "Ready to merge?" 收尾——这个框架授权了一个单任务 diff 去做分支级宽度的评审。规格 prompt 的 diff 范围护栏从未被移植过来。
2. controller 没有编写评审 prompt 的指引，于是它自己发明开放式指令（"check all uses"），评审者又逐字照做。
3. 流水线上的重复劳动：质量模板的 "Plan alignment" 维度重新检查了规格评审刚验证过的东西；评审者在相同代码上重跑 implementer 已经跑过（并带着 TDD 证据报告过）的测试套件。
4. per-task 评审与最终评审共用一个模板，"任务级窄、最终级宽"这一区分在系统里没有任何表示。

设计文档还如实记录了一个修正：一份 field report 最先发现了这个问题，其引用的会话与数字无法核实，但定性诊断被两个真实会话确认；其中一条错误被纠正——跨切面审计（锁顺序、变更的契约）有时恰恰是正确的方法，所以修复必须"把广度放在一个被明确陈述的具体风险后面做门控"，而不是一刀切禁止。

设计目标与非目标（明确保留的行为）

目标：

• per-task 评审限定在任务范围内：diff 优先阅读、有据可依地扩展、不重复跑测试；
• 最终整分支评审保持现有宽度；
• 评审能抓住的东西不减少。

非目标 / 明确保留——这部分值得逐条读，因为它划定了改造的边界：

• 完整的 re-review 保留：评审者在修复后复审时，仍按完整阅读广度复审整个任务（但不重跑 implementer 刚修完代码的测试）。这一条故意拒绝了 field report 的 "re-review budget" 方案——最坏样例（re-review 跑 -race 和 -count=100 循环）的成本由下面的测试预算来抑制，而不是靠收窄 re-review 的阅读范围。
• 两个评审阶段保持分离（已被后续成本迭代取代）：原文档此处被划掉了——线上评测经济学显示"每次派发的开销"主导了总成本，维护者决定把所有东西摆上桌面重新权衡。per-task 阶段最终合并为一个 task reviewer 出两个裁决（spec compliance + code quality）；独立的宽口径最终评审保留。
• coordinator 保留模型判断：不给评审强制模型档位，双向都不强制。
• requesting-code-review/ 原封不动：它仍是最终分支评审和临时评审的宽模板。
• 裁决顺序（spec compliance 先于 quality 报告）、修复-复审循环、Critical/Important 必须修复的要求，全部不变。

成本迭代：从首发到冻结配置的完整演进

这是设计文档信息密度最高的部分，记录了一次次"上线 → 评测 → 归因 → 再改"的真实循环。以下数字均来自文档中列出的 live before/after 评测。

共享原则：不要重跑没改过代码的测试

所有迭代的地基是一条共享原则：implementer 的报告里已经包含针对"正是这段被审代码"的测试结果和 TDD RED/GREEN 证据，评审者通过阅读来验证。只有当阅读提出了一个现有测试无法回答的具体怀疑时，才跑一个聚焦测试，而不是套件。在评审子代理只读的 harness 上（例如 Antigravity 把评审模板映射到没有命令权限的 research 类型），评审者在报告里写明它想跑哪个测试。

这条原则的成立有一个前提：implementer 修复后必须重跑覆盖被改代码的测试。设计文档指出当时没有任何东西强制这一点，因此同步修改了 implementer prompt——"修复评审发现后，重跑覆盖被改代码的测试，并把结果写进修复报告"。在当前仓库中，这条规则确实落在 implementer-prompt.md 的 "After Review Findings" 小节："Reviewers will not re-run tests for you — your report is the test evidence." 迭代 2 之后还补了一条：implementer 在迭代过程中跑聚焦测试，提交前完整套件只跑一次（见 implementer-prompt.md）。

成本回归与归因

质量硬化文案（证据规则、约束传递、pristine 输出）落地后，live 对比暴露出成本回归：go-fractals 场景从任务级评审首版的 42.8 分钟 / 14.5M tokens 涨到硬化版的 69.9 分钟 / 32.2M，而质量达到基线同等水平（盲评 8.5 对 8.5）。按子代理轮次剖析，成本归因依次是：

1. 便宜模型在多步工作上花的轮次是 2～3 倍（1197 个 subagent 轮次里 678 个是 haiku）；
2. 每次派发的固定开销（每任务 3 次子代理启动，每次都要重新推导 diff；controller 协调占了总开销的一半）；
3. 证据规则的叙述（narration）。

迭代 1：轮次比单价重要

• 模型指引改为 "turn-count-beats-token-price"（多步工作以 mid-tier 为下限）；
• diff 可以内联粘贴进 prompt（可选）；
• 证据规则改为 "cite-don't-narrate"（引用行号，不叙述过程）；
• Important 重新定义为 "cannot-trust-until-fixed"；修复派发只针对 Critical/Important。

结果：68.2 分钟 / 22.9M——token 降 29%，墙钟持平。一个有意思的细节：内联 diff 的措辞是"可选"的，结果 22 次评审派发中只有 2 次的 controller 真的把 diff 粘了进去——可选指令基本没人执行。

迭代 2：两个评审阶段合并为一个 task reviewer

per-task 的规格评审与质量评审合并进一个 task-reviewer-prompt.md：一个评审者、一次 diff 阅读、两个裁决；一次修复派发同时处理两类发现。结果（go-fractals）：47.5 分钟 / 15.7M / $13.55——在所有维度上击败基线，盲评 9/10 对基线 7/10。这正是当前仓库的形态：task-reviewer-prompt.md 的 prompt 结构就是 "Part 1: Spec Compliance" + "Part 2: Code Quality"，输出两个裁决（Spec Compliance 的 ✅/❌/⚠️ 与 Task quality: Approved | Needs fixes）。

迭代 3：校准、怀疑、把 diff 当文件

• Calibration 明确点名合并阻塞性的可维护性损伤——逐字复制的逻辑块、被吞掉的错误、无断言的测试——归入 Important；Minor 发现必须粘贴进最终评审供分诊。当前 task-reviewer-prompt.md 的 Calibration 节正是这样写的："Important means this task cannot be trusted until it is fixed … verbatim duplication of a logic block, swallowed errors, tests that assert nothing."
• 评审者的怀疑延伸到 implementer 的设计理由："left it per YAGNI" 是一个声明，不是一个裁决。当前模板的 Do Not Trust the Report 节 保留了这个立场："a stated rationale never downgrades a finding's severity."
• 把 diff 作为文件交给评审者：git diff > /tmp/sdd-task-N.diff，用重定向保证 diff 永不进入 controller 的上下文，评审者一次 Read 调用读完。这是"可选粘贴"指引被证实无人采用（11～17 次派发里 0～6 次，出于局部理性的上下文经济学）之后的对策——从"建议"变成机制。
• 证据规则的由来（文档在迭代 1 之前补充说明）：live 评测中评审者对 prompt 明确指向的缺陷给出了无支持的 "yes"——一次 accessible-name 检查、一次临时目录清理检查，缺陷就躺在被审 diff 里。此后评审者必须对每个 What-to-Check 项给出 file:line 证据，而非裸 yes/no。

冻结配置（commit e355795），五个场景全部通过：go-fractals 44.4 分钟 / 13.4M / $11.67（相对基线 -32% 时间、-37% token、-27% 美元）；svelte-todo 62.8 / 19.7M / $15.76（-21% / -28% / -25%）；rejects-extra-features $1.31（对 $1.88）；spec-reviewer-flaws 持平；植入缺陷场景（v3：对判断类问题设置 open-flag 透明标准、对"名字承诺验证但从不验证的测试"设置 must-fix 标准）通过，缺陷被抓住并修复。

迭代 4-5（2026-06-10）：方差诚实、结构性修复、正向配方

同一配置重跑暴露了运行间方差（相同 prompt 下 44.4 → 57.1 分钟；评审者的"逃生门"胃口在 1.0 → 6.3 次工具调用/评审之间摆动），所以此后的所有结论都改用区间表述。五个并行的 go-fractals 实验变体加上对真实本地会话的 transcript 挖掘（含负结果的完整日志在 evals 子模块的 evals/docs/experiments/2026-06-10-sdd-cost-experiments.md）产出了最终配置。

采用的措施（每一条都对应当前仓库里可验证的机制）：

措施	解决的问题	当前仓库中的落点
final-review package（最终评审者 33 → 6 个轮次，且按 controller 模型计价）	最终评审重复推导分支 diff	SKILL.md Final Review：scripts/review-package PLAN_FILE MERGE_BASE HEAD
两个模板中的 REQUIRED model: 行	纯文字指引会中途衰减——曾有一次 session 内衰减导致 17 次派发继承 opus，+$5	task-reviewer-prompt.md、implementer-prompt.md 的 model: [MODEL — REQUIRED …]
task-brief + report 文件	需求文本不再穿过 controller 上下文	scripts/task-brief（awk 提取单个 Task 全文，打印路径）
进度账本 progress.md	真实会话在 compaction 后重新派发了整个已完成任务序列（约 22 个任务 269 次派发）	SKILL.md Setup 的账本规则；工作目录由 scripts/sdd-workspace 解析
omnibus final fixer（一个 fix 子代理处理全部最终发现）	某真实会话"每个发现一个 fixer"的修复波比全部任务加起来还贵	SKILL.md："dispatch ONE fix subagent with the complete findings list — not one fixer per finding"
scoped fix tests	一行修复不需要全套件	re-review-prompt.md 的 Tests 节
唯一 SHA 区间命名的伴随文件	worktree/submodule 安全	scripts/review-package：默认输出 review-<base7>..<head7>.diff
派发组合配方 + 评审者"命名风险预算"	禁止式指令会反噬	微测：正向配方 3.0（誊写的具体值）vs 禁止式 4.4 vs 对照组 3.6——"prohibitions can backfire"，另见 2026-06-10-positive-instruction-redesign-design.md

测试过但被否决：

• controller 轮次批处理与并行调用流水线——controller 每条消息恰好只发一个工具调用（每次运行里 0 条多工具消息），且它 46% 的轮次是思考/叙述，这是 prompt 无法消除的地板；
• 后台派发流水线——机制被 7/28 的运行采用，但收益低于这些场景 ±6 分钟的噪声地板。

最终验证配置（b81f35b 家族），所有门槛通过：

• go-fractals：54.1–54.7 分钟 / 14.4–16.6M / $12.81–14.31（基线 64.9 / 21.2M / $16.07）；
• svelte-todo：55.0 分钟 / 19.3M / $14.99（基线 79.7 / 27.3M / $20.98）；
• planted-defect 通过 / $2.77；
• 全部 8 次同设计 fractals 运行：44.4–57.1 分钟 / 13.4–20.0M / $11.67–14.84——最差的一次抽取也在所有维度上击败基线，典型中位节省约 20–25%。

设计细节：四处 prompt 文件的改动

文档的 Design 节按文件给出改动清单。下面先按原文继承，再对照当前仓库的实际形态。

1. 质量评审 prompt 自包含化

停止委托给 requesting-code-review/code-reviewer.md，per-task 质量评审获得自己的作用域受限模板：

• 框架："You are reviewing one task's implementation for code quality."——是一个任务级门，不是合并评审；
• Spec compliance 已定案：规格评审已通过，不再重审需求或计划对齐；
• 保留的评审维度：代码质量（清晰度、重复、错误处理）、测试质量（验证真实行为而非 mock）、可维护性，以及 SDD 特有检查（单一职责、可独立测试、遵循计划的文件结构、本变更贡献的文件增长）。删除：plan alignment、安全/可扩展性/生产就绪维度、merge 裁决；
• 范围预算（scope budget）：从 git diff BASE..HEAD 出发；先读被改文件；只有为了评估一个你能为它命名的具体风险才检查 diff 之外的代码。跨切面变更——锁顺序、函数/API 契约、共享可变状态——是合法的命名风险，足以支持检查调用点。不要默认爬代码库。
• 测试预算：即上面的共享原则，外加：除非你先点名了一个具体怀疑的 flake 或 race，否则不跑整包套件、race detector 或重复/高次数循环；否则在报告里建议重型验证而不是执行。implementer 报告的测试输出里有警告或噪声就是发现——输出应当 pristine（implementer 的 self-review 也检查这一点）。
• 证据规则：对每个 What-to-Check 项用 file:line 证据作答，不是裸 yes/no（动机见迭代 3）。
• 只读规则保留精简版：不改工作树、index、HEAD、分支状态；但当前模板里那句 git worktree add 操作指引不带入——diff 作用域的评审永远不需要检出另一个修订版。
• 裁决：Strengths / Issues（Critical/Important/Minor）/ "Task quality: Approved | Needs fixes."

当前仓库的形态：如上所述，迭代 2 之后这一独立模板与规格评审模板合并为 task-reviewer-prompt.md。从文件内容看，上述所有要素都在合并模板里完整保留：范围预算（L45-L50 的 "Do not crawl the broader codebase … Cross-cutting changes are legitimate named risks"）、测试预算（L64-L76）、pristine 输出、证据要求（L113-L116）、只读规则（L52-L53）与 "Task quality" 裁决（L163）。

2. 规格评审 prompt 的清理

• 删掉 git worktree add 操作指引。只读规则保留；diff 作用域的规格评审不需要检出其他修订版。
• 化解 diff-only 护栏与 "verify everything independently" 的张力：spec compliance 通过"读 diff 对照需求"来判定；implementer 的 TDD 证据覆盖"它能跑"——套用共享测试原则。当前模板对应 L89-L91："If a requirement cannot be verified from this diff alone … report it as a ⚠️ item instead of broadening your search."
• 新增第三裁决通道：无法从 diff 验证的需求（存在于未变更代码、跨任务）报告为显式的 "⚠️ Cannot verify from diff — controller should check X" 条目，而不是去爬代码库或者静默放行。流程图上的二值 pass/fail 菱形无法路由它，所以由第 3 节的 controller 指引定义处理：⚠️ 条目不阻塞质量评审的派发，但 controller 必须在标记任务完成前自行解决每一条（它持有计划和跨任务上下文）；controller 确认是真实缺口的条目按"规格评审失败"处理，退回 implementer。
• 用有根据的怀疑替换虚构前提：把 "The implementer finished suspiciously quickly" 换成 "Treat the implementer's report as unverified claims about the code"——同样的不信任，不发明事实。当前模板 L55-L62 正是这个版本，且比原设计更进一步（迭代 3 的设计理由怀疑）。

3. SKILL.md 的 controller 改动

设计文档列出的六处改动，与当前 SKILL.md 的对照：

• Model Selection：把 "Architecture, design, and review tasks: use the most capable available model" 拆成两句——架构/设计任务仍用最强的模型；评审任务按与 implementer 相同的判断选择，按 diff 的大小、复杂度和风险缩放。当前 L165-L172 保留了这一分法，并明确"最终整分支评审属于架构/设计档"。
• Reviewer prompt construction（新增指引）：派发评审者时，不写没有具体任务理由的开放式指令（"check all uses"、"run race tests if useful"）；不要求评审者重跑 implementer 已跑过的测试；不替评审者预判发现——绝不指示评审者忽略或不标记某个具体问题，疑似假阳性在评审循环里裁决。这条规则的由来是一次 live 评测中 controller 捏造了 "the plan forbids a shared helper" 的说法、并指示质量评审者不要标记一个植入的 DRY 违规。当前 L283-L292 甚至给出了可机械检查的停止规则：如果你要写的 prompt 里出现 "do not flag"、"don't treat X as a defect"、"at most Minor" 或 "the plan chose"——停：你在预判。 另外两条硬要求也来自 live 教训：controller 必须把 spec/design 的全局约束（版本下限、命名/文案规则、平台要求）逐字贴进派发的需求里——一次 live 运行因为没有任何评审者看到约束，交付了一个对着 "Go 1.21+" 设计的 go 1.26.1 模块下限；以及每次派发必须显式指定模型——省略模型会继承会话（通常最贵的）模型，静默击穿模型选择。
• 处理规格评审的 ⚠️ 条目（新增小节，与 Handling Implementer Status 并列）：当前 L293-L298 与原文一致。
• 最终评审显式保持宽口径：最终整分支评审派发节点加上指向 ../requesting-code-review/code-reviewer.md 的显式指针——因为一旦删除 per-task 质量 prompt 的委托，那个模板将无人引用而成为孤儿。当前流程图中三个节点标签 Dispatch final code reviewer (../requesting-code-review/code-reviewer.md) 字节级一致（Graphviz 按标签文本匹配节点，三处不一致会长出幽灵节点）。
• 示例工作流：质量评审者行更新为新裁决词汇（"Task quality: Approved"，见 SKILL.md L464），最终评审者的 "ready to merge" 行保留。
• 流程拓扑不变；⚠️ 通道由 controller 指引处理，不新增图分支。

当前仓库中的执行机制：三个脚本与一个工作区

设计文档的验证节和迭代 4-5 的措施，最终都落到了 skills/subagent-driven-development/scripts/ 下的三个 bash 脚本上。它们值得单独看一下，因为成本控制里相当一部分收益来自"文件代替粘贴"这一机械改动：

• task-brief：task-brief PLAN_FILE N 用一段 awk 脚本（跳过代码围栏、匹配 # Task <N> 标题）把计划里单个任务的全文提取到 task-<N>-brief.md，打印路径。任务文本从此以文件形式存在，不再穿过 controller 的上下文——这也是迭代 4-5 "fidelity anchor" 的载体：评审者和 implementer 读同一个 brief 文件，需求以文件为准。
• review-package：review-package PLAN_FILE BASE HEAD [OUTFILE] 把 git log --oneline、git diff --stat 和 git diff -U10（L42，十行上下文）写入一个文件，打印路径与大小。输出从不进入 controller 上下文，评审者一次 Read 调用读完提交列表、stat 和完整 diff。脚本头注释点明关键设计：必须用派发 implementer 前记录的 BASE，而绝不是 HEAD~1——后者会静默丢弃多提交任务的所有提交。默认文件名 review-<base7>..<head7>.diff 按区间唯一命名，修复后的复审自动得到一份不同的新文件，worktree/submodule 场景也不会互相覆盖。
• sdd-workspace：解析并创建 <repo-root>/.superpowers/sdd/<plan-basename>/ 作为单个计划的全部短命工件目录（briefs、reports、review packages、progress 账本），并写入自忽略的 .gitignore。脚本头注释解释了为什么放在工作树而不是 .git/ 下（Claude Code 把 .git/ 当受保护路径，会拒绝子代理写入 report 文件）。值得注意的是，账本位置已从设计文档迭代 4-5 阶段的 <git-dir>/sdd/progress.md 演进为按计划文件作用域的目录——另一个计划的目录永远不该被读取或写入，陈旧账本被误读为当前进度会让 controller 跳过整个任务序列，计划级作用域从结构上消除了这个故障。

配套地，SKILL.md 的任务循环把"派发纪律"写死：派发 prompt 只描述一个任务而非会话历史（真实教训：某次派发 42k 字符，99% 是粘贴的历史）；实现子代理永不并行派发（会冲突）。

修复循环与最终评审：窄与宽的分工如何闭合

设计文档的"任务级窄、最终级宽"主张，在当前仓库的执行流程里是完整可验证的（SKILL.md 的流程图中）：

1. per-task 任务评审（task-reviewer-prompt.md）：一次 diff 阅读、两个裁决；
2. 修复循环（最多 5 轮）：1–3 轮 resume 原 implementer，4–5 轮换更强模型的全新 implementer；每轮 = 一次修复派发 + 一次作用域受限的复审（re-review-prompt.md 只裁决发现清单 + 检查修复 diff 里新引入的破坏，diff 之外的观察进入账本、不延长循环）；
3. 熔断：第 5 轮仍有未决发现时停止派发，controller 逐条裁决——评审者错了或可争议的 parking（记账并附裁决理由）、真实但下游不依赖的 parking、真实且承重的 STOP 并报告给人类；
4. 最终整分支评审：用 code-reviewer.md 的宽模板、最强模型、MERGE_BASE..HEAD 的 review package，并指向账本里的 deferred-minor 与 parked 行做合并前分诊；有发现则一次 omnibus 修复派发 + 一次作用域复审，无第二波。

这条链正好回应了设计文档的核心目标"评审能抓住的东西不减少"：窄的是每任务门的阅读范围与测试预算，宽的是最终评审的完整宽度，两者通过账本（Minor 发现、parked 裁决）显式传递，没有静默丢弃。

设计文档承认的未修复项（known, deferred）

设计文档专设一节承认一个架构性盲区：规格评审者对照的是 controller 粘贴的任务文本；它抓不住 controller 从计划中提取需求时丢掉的需求。这是"controller 提供全文"这一架构的属性，不是 prompt 问题，不在本设计范围内。读设计文档时保留这一边界很重要：它意味着任务级评审的质量上限部分取决于 controller 提取的忠实度，这也是为什么 task-brief 文件（单一需求来源）比"controller 粘贴"更进一步。

验证方式：如何确认这类改动没有回退

设计文档的 Verification 节给出三层验证，对任何"改 prompt 文件"的工程都有参考价值（prompt 文件没有单元测试，静态验证 + 行为评测缺一不可）：

1. 插件基础设施测试（tests/ 目录）仍须全部通过；
2. SDD 技能行为评测：改动前后各跑一遍（git submodule update --init evals 后按 evals 子模块的 README），具体场景：sdd-go-fractals、sdd-svelte-todo、sdd-rejects-extra-features（含规格评审 YAGNI 门的端到端 SDD）、spec-reviewer-catches-planted-flaws；
3. 已知评测缺口（文档主动暴露）：没有现成场景在一个 SDD 任务内植入代码质量缺陷并断言 per-task 评审能抓住它，也没有场景度量单次评审的探索成本（工具调用/grep 计数）。补一个植入单任务质量缺陷的场景（评审必须在最终评审之前标记它）；探索成本则人工对比改动前后评测 transcript 里评审子代理的工具调用计数。

配套的实施计划为每个 prose 编辑给出了精确的 grep 落点检查，例如：

• grep -c "requesting-code-review" skills/subagent-driven-development/code-quality-reviewer-prompt.md 期望 ABSENT（委托已移除）；
• grep -n "suspiciously\|worktree add" skills/subagent-driven-development/spec-reviewer-prompt.md 期望 CLEAN；
• grep -n "After Review Findings" skills/subagent-driven-development/implementer-prompt.md 期望一处、且位于 ## Report Format 之前——当前仓库中该小节位于 implementer-prompt.md L107，与检查预期一致；
• grep -rn "Ready to merge" skills/subagent-driven-development/ 期望 CLEAN（任务级模板不再以合并裁决收尾）。

总结

这篇设计文档的价值不仅在于结果（go-fractals 场景 -32% 时间 / -37% token / -27% 美元，且最差抽取仍全面击败基线），更在于它完整公开了一次"评测驱动 prompt 工程"的方法论循环：

1. 用真实会话 transcript 定位成本根因，而不是猜——质量评审 4～8 倍成本来自 prompt 框架继承，而非模型本身；
2. 把广度放在"命名风险"后面做门控，而不是一刀切禁止——跨切面审计有时是正确方法，"one focused check per named risk" 是当前模板的最终措辞；
3. 可选指令会被忽略（内联 diff 2/22 次采用率），约束要落进 REQUIRED 字段或机械脚本（review-package、task-brief、sdd-workspace）；
4. 禁止式指令可能反噬（微测 4.4 vs 3.0），正向配方 + 誊写具体值更有效；
5. 承认运行间方差，结论一律区间化；公开负结果（被否决的批处理/流水线实验同样写入文档）。

这些机制——diff 优先阅读、测试预算、证据规则、⚠️ 第三裁决通道、账本、作用域复审、omnibus 修复、任务级窄/最终级宽的分工——对任何需要给 LLM 子代理流水线控制成本的工程都是可直接借鉴的模式。