Rule — 多 AI 派活（本项目主控规范）¶
触发场景：一轮活里出现「可分离、判据客观、体量够大」的子任务，或需要独立对抗审时。 借鉴自跨项目的多执行方编排实践，但本文只写本项目的判据；通用编排细则不在这里复述。
0. 唯一真相源（不在本文复述，别照抄任何复述）¶
| 要什么 | 去哪查 |
|---|---|
| 派给谁（执行方、家数、跨厂商要求） | ~/.claude/tools/dispatch-policy.tsv |
| 执行方能力画像 / 通道 / 隔离要求 | ~/.claude/tools/flow-agents.conf |
| 派活命令与收口协议 | source ~/.claude/tools/flow.sh |
🔴 本文写死任何执行方名字都会过期。看到本文档里出现具体模型名，那是举例，不是配置。
1. 本项目的先天优势：判据是机器给的¶
派活最难的一步是「怎么证明它真干了、干对了」。本项目已有的门禁把这一步变成了跑一条命令：
⇒ 本项目派活的收活判据 = pnpm verify 退出码 + diff 复核，不靠执行方自述。
这比「让它写一段总结」硬一个数量级。任务书必须把这条命令写进「自我验证」段。
2. 派活前：三道闸，缺一不派¶
| 闸 | 命令 / 判据 | 为什么 |
|---|---|---|
| ① 基线绿 | pnpm verify 退出 0 |
基线本来就红，执行方交回来的红分不清是谁的 |
| ② 工作区干净 | git status --porcelain 为空，或在制品已提交/已 stash |
🔴 本项目已栽过：58 个未提交文件时派活，执行方的改动与在制品混在一条 diff 里，无法归因 |
| ③ 执行方没在别处忙 | inflight who |
执行方是跨项目全局共享资源，别的会话可能正在用；抢占会让两边都拿到半截上下文 |
三闸任一不过 → 先把闸弄绿，别派。
3. 什么必须派 / 什么绝不派¶
必须派（三条同时成立）¶
- 体量 > 3000 token（更小的活，派活固定开销就吃掉收益）
- 上下文能写清（答案依赖没落到文件里的口径 ⇒ 别派，写不清就是自己做）
- 判据客观（能跑
pnpm verify/ 能 grep 出行号 / 能对 baseline）
永远派（与体量无关）¶
- 对抗审 / GO-NO-GO —— 不派 = 自己审自己，等于没审
- 同题跨厂商扫描 —— 两家发现不重合是本项目 scanner 沉淀的来源
永远自己做（主控不外包）¶
- 判执行方报告的真假、驳回
- 拍板取舍、合并决策、解冲突
- 浏览器里的真实 e2e 复现（扩展要装进 Chrome 才能验）
- 改
docs/rules/宪法级规则、改版本号、发版
3.5 标准推进流水线（Tony 2026-08-30 拍板）¶
一件事从「要不要做」到「做完可提交」，走这四步，不跳步。
flowchart TD
A[对抗定方案] --> B[sonnet5 实施]
B --> C[terra + dshf 跨厂商双审]
C -->|PASS| D[主控复核 file:line → 提交]
C -->|BLOCK| B
D --> E[推进下一项]| 步 | 谁 | 干什么 | 为什么是它 |
|---|---|---|---|
| ① 对抗定方案 | 多 lens 并行 + 交叉证伪 | 决策类问题给正反双方最强论证，实测数字说话 | 单方论证会自我确认 |
| ② 实施 | sonnet5（空白记忆） | 写代码、改文档、写测试 | 实测质量足够；空白会话不带 anchor bias |
| ③ 双审 | terra(openai) + dshf(deepseek) | 跨厂商对抗，读同一固定快照，独立 session | 防共同盲区 |
| ④ 复核 + 提交 | 主控自己 | 逐条验 file:line、跑闸、path-scoped 提交 | 派出去的是劳动不是责任 |
三条不能省¶
🔴 步骤 ② 一律用 sonnet5，不用 opus5。 实测（2026-08-30）：sonnet5 在第三层审查中推翻了 opus 主控 + terra + dshf 的三方共识，发现三方全漏的活云通道与 manifest 域名拼写错误。 它的失效模式不是能力不足，是容易把可查的数字外推成业务结论（如把「249 国中 53 个欧洲」 当成业务权重）—— 那正是步骤 ③ 要抓的。
🔴 步骤 ③ 必须跨厂商。 同厂商双审防不了共同盲区。但反过来也成立： 跨厂商双路曾漏掉 sonnet5 抓到的 ISSUE-0042 复发 —— lens 设计比模型厂商更决定发现什么， 两者不能互相替代。
🔴 步骤 ④ 不外包。 审查方的每条结论都要主控自己重跑。本轮实证：审查方给的行号错过
（decodeCfEmail 在 226 不是 216）、结论错过（enterpriseEmailOnly 的「恒 false」指的是
前置条件不是调用点）、也提过不该采纳的建议。
什么时候可以跳过 ①¶
方案已经对抗定完、只是分阶段实施时，直接从 ② 开始。 但任何新的产品取舍或架构选择都要回到 ①。
4. 任务书四要素（缺一条下游必然跑偏）¶
执行方每次都是全新会话、不能追问。任务书必须自包含：
- 目标：一句话说清「做完长什么样」，不是「看看有没有问题」
- 绝对路径：工作目录、要改的文件、要读的规则文档，全写绝对路径
- 约束：本项目的硬约束必须抄进去 ——
- 🔴 不许阉割式修复（
disabled/sortable:false/ 隐藏列），见docs/rules/no-mutilation-fix.md - 🔴 改
src/**或wxt.config.ts的提交必须带Docs-Impacttrailer，见docs/rules/docs-impact.md - 🔴 storage 字段只加不删，废弃加
// deprecated - 🔴 settings / 调度字段望文生义必死，先读源码顶部注释
- 自我验证 + 期望产出：明确要求跑
pnpm verify并贴原始输出；产出格式钉死（改哪些文件 /file:line/ 闸输出）
报告格式（写进任务书，否则它会写几千字）¶
≤ 800 字结构化状态卡：结论 +
file:line+ 闸的原始输出 + 它没做什么 不要：把读过的代码贴回来、把步骤复述一遍
5. 收活：只信客观证据¶
tail -1 "$out" | grep -qE '^__FLOW_EXIT__=[0-9]+$' # ✅ 末行整行匹配
grep -q '__FLOW_EXIT__' "$out" # 🔴 会被输出回显骗
拿到产出后，主控必须自己再做三件事（派出去的是劳动，不是责任）：
git diff逐行看它改了什么 —— 别只看它说改了什么- 复跑
pnpm verify，退出码为准 - 抽查它报的每个
file:line是否对得上（历史命中率约 70-80%，会误判、会 hallucinate）
🔴 执行方报的「还剩 N 处未处理」必须当场落档到 docs/_todo.md 的来源（raw/inbox/ 或 issue），
不落 = 下一轮当它不存在，见 docs/rules/todo-registration.md。
6. 对抗审：跨厂商，作者不自审¶
本项目原有的 independent-agent-review.md 解决的是 anchor bias（换视角）；
本条追加解决 共同盲区（换模型族）：
| 要求 | 判据 |
|---|---|
| 审的人 ≠ 写的人 | 自审必过，等于没审 |
| 跨供应商（不是跨工具、不是跨档位） | 同一家的两个档位 = 同一个模型的两次采样 = 回声 |
| 修这刀的 ≠ 扫出这刀的那一家 | 否则它会顺着自己的误判改 |
⚠️ 「同模型不同 harness」不是两家。判独立性看模型族，不看调用通道。
必须跑对抗审的场景（在 independent-agent-review.md 的清单之上）：
- 改了任何 scripts/scan-*.py 或 baseline —— 闸自己坏了不会报错，只会静默变绿
- 改了 scripts/hooks/ —— 同上，且它拦的是所有后续提交
- 发版前的最终审
7. 反模式（本项目已经栽过的）¶
| ❌ | 为什么坏 | 正解 |
|---|---|---|
| 工作区一堆在制品时派活 | 归因不了，且执行方可能把你的在制品当成 bug 改掉 | 先提交或 stash |
让执行方直接 pnpm build / 改 package.json 版本号 |
发版顺序是铁律，见 version-release-flow.md |
构建与发版主控自己做 |
| 信执行方「已验证 / 已通过」 | 声称即实存是本仓硬教训 | 自己复跑闸 |
| 用它的报告直接改代码不复核 | 70-80% 命中率 | trust but verify |
| 改 scanner 让它变绿来「修 bug」 | 闸假绿比 bug 更贵 | 先造受控破坏，确认闸能红 |
| 同厂商两个档位当「双审」 | 回声 | 查 flow-agents.conf 的 model_group |
8. 并行安全（本机同时跑多个会话时）¶
- 执行方进程是全局的：
inflight who先看，别抢别人正在用的 - 清进程绝不
pkill -f/killall—— 会误杀其它会话的活 - 共享文件（
docs/_todo.md/ 各INDEX.md/development-log.md）改完立刻 path-scoped 提交， 别git add -A，别隔夜
9. 流程图¶
flowchart TD
A[有一轮活] --> B{可分离·判据客观·>3000token?}
B -- 否 --> C[主控自己做]
B -- 是 --> D{三道闸: verify绿·工作区净·执行方闲}
D -- 任一不过 --> E[先弄绿闸]
E --> D
D -- 全过 --> F[写自包含任务书·四要素]
F --> G[查 dispatch-policy.tsv 派给谁]
G --> H[flow_go 派出]
H --> I{末行 __FLOW_EXIT__ 收口?}
I -- 否 --> J[等/查 inflight]
I -- 是 --> K[主控: 看diff + 复跑verify + 抽查 file:line]
K --> L{改了 scanner/hook/核心?}
L -- 是 --> M[跨厂商对抗审·作者不自审]
L -- 否 --> N[落档: issue/spec/todo]
M --> N10. 元教训¶
派出去的是劳动，不是责任。
本项目值得派活的真正理由不是省 token，而是：它已经有一套机器判据（pnpm verify 19 项），
所以执行方的产出能被客观验收。没有这套闸的项目，派活等于把不确定性外包给一个不能追问的对象。