Feature

设计由你负责。你来规划、评审、验证。 实现委派出去。主导权留在你手里。

对受影响的子系统跑 how。
用 architect 并行探索设计。
把吞吐检查点写成四个 todo 项。某个维度确实不适用时（只改一个文件，没有扇出），这一项也保留，写成 n/a: <reason>，不要删掉：
- 必须先做的阻塞步骤。 门禁要在扇出之前跑完。
- 互相独立的工作线。 互不重叠的文件、服务或层，并行做。写同一处的，串行做。
- 共享的可变状态。 默认把目标拆开（separate-before-serializing-shared-state 原则 skill）。只有真正的不变量要守时，才串行。
- 最小的安全拆分。 如果交给一个执行者最好，说明原因。
把写代码委派给子代理，用你配置的 feature 模型（默认 grok-4.7-xhigh-fast），范围要具体。范围里写明文件路径和成功标准，还要点名数据形状和它的组织结构。组织结构按 principle-model-the-domain 在子代理写逻辑之前选好，例如用状态机代替散落的布尔值，用表或注册表代替一堆分支，用带类型的模型代替到处重复的形状假设。如果实现有几种都说得通的写法（错误处理、抽象层、测试结构），改用 arena skill 委派。这样各个 runner（并行出方案的子代理）会把备选方案摆出来，交叉评审替你把住最终的选择。这一条是强制的。不能写个跳过理由就绕开，Laziness Protocol 也推翻不了它（好处是写和审分开，不是省下几行代码）。不允许再派子代理的子代理，自己直接负责这份 diff，写和审照样分开，就算满足这一条。不要回一句「待命中」就去等嵌套的 agent。注释按 Comments 一节的规则写。改动要精准，只动必要的地方。文件如果是从别处的源文件派生出来的，要回到源文件重新核对。共享基础组件的改进，要移植到所有使用方，并逐个验证。勤提交。
在对应的界面上验证。结果「无法判定」，或者验证用错了界面，都不算通过。要明确标出来。
rebase 成小而有序的 commit。后续改动往上叠。按 sequence-verifiable-units 原则 skill 来做：每个小单元都先构建、验证、提交，再做下一个。
设计有争议时，交付前先跑 interrogate。
执行 Opening a PR。

代码上互相耦合的工作（一个功能，或一次迁移），交给单独一个负责人，检查点直接写进交给它的任务里。阻塞阶段过后，由这个负责人在内部扇出。父代理这一层的扇出，用于各自产出独立成果的切片（审计、跨子系统的调查、互相竞争的实验）。每到阶段边界，重写一次检查点。宁可开一个新的负责人，也不要连环打断原来那个。