dispatch

Dispatch（路由器）

通过受限的子进程 worker 推动一个 slice 的各阶段完成—— 你负责协调并且是唯一写入者，worker 负责执行。

开始时宣布：“正在使用 dispatch 技能，通过受限 worker 推动各阶段完成。”

外层循环

1. dispatch setup --slice <N> --dir <path> — 创建／恢复协调工作树。 在 Claude harness 下，--dir 必须解析到项目根目录内（约定为 .dispatch/SL-<n>）；根目录外的目录会被安全拒绝。其他 harness 保持其强制执行的根目录外隔离。
2. 使用 dispatch commit --slice N -m <msg> -- <path>… 提交协调者自己编写的内容（slice 状态、记忆、审计） （必须指定 pathspec）， 绝不直接运行 git commit。
3. dispatch plan-next --slice <N> — 找出下一个可执行阶段；文件互不冲突时，规划并行批次
4. 通过 /dispatch-spawn 启动 worker — 每个 harness 都使用 一条受限子进程路径（在接入 preferred-subprocess-harness 选择机制之前， 默认使用 pi harness）。
5. 自行落地每个阶段 — 导入、提交、记录边界、验证、将阶段切换为 completed，并回收分支（见下文）
6. 收尾：slice verify-vt <id>（VT 门禁，协调树）→ 通过后 执行 dispatch sync --prepare-review → 移除协调工作树 → 审计

每个批次

基础干净状态前置条件（启动前，非变更操作）。 在捕获 B／ 启动任何 worker 之前，以及在 main 上创建协调分支之前， 确认基础状态已通过干净性检查：

doctrine check prove     # fmt-check + lint; asserts, never fixes

基础状态为 RED 属于基础缺陷，与任何 worker 的发现截然不同：这意味着 你即将从中分支的树已经存在未格式化或 lint 报错。由操作人员侧修复—— 由你负责格式化并提交（或使用隔离的准备工作树）——绝不将其并入 worker 的差异， 也绝不自动修复。从脏基础状态启动的 worker 要么继承 RED（并在导入时因其 未造成的缺陷而被拦下），要么将其掩盖。每个批次仅在此热路径上运行一次（另一次 prove 是下方的导入后门禁——不要重复运行）。

启动 worker 前捕获 B = git rev-parse HEAD，然后在 B 处的协调树上捕获回归 基线：

doctrine check regression capture --base "$B"     # suite @ B; no-op on cache hit

在此次捕获和验证差异之前，都要规范化筛选器状态： 确认你自己的环境中未设置 DOCTRINE_WORKER，并强制进行真实 重建，以确保捕获和差异检查运行相同的套件调用及测试选择。 仅树相同还不够——泄漏的 DOCTRINE_WORKER 会改变运行的测试，并破坏取消属性（此时指纹不匹配会导致缓存未命中 → 诚实地重新捕获，绝不会污染基线）。

Worker 的自我报告仅供参考；只相信你自己的验证步骤。

落地阶段：由你按以下顺序推进

Worker 会交回一棵未提交的工作树（它无法提交——真实 git 目录在其隔离环境中为只读）。你负责落地：worktree import --from-worktree → 一次协调提交 → slice record-delta --commit <S> → 运行该阶段的验证 → slice phase --status completed → 回收分支。 /dispatch-spawn 说明每个步骤的操作方法和拒绝语义； 下方各步骤属于整个批次，而非单个阶段。

funnel 判定器——仅适用于绑定的 fork

参见 lib:reference/dispatch-mechanics.md § The funnel record，以及它作为驱动程序时的说明。

该机制保留原样，未作更改；当某一行确实存在时，它规定的操作如下：

kind	规定的操作
spawn	还没有 funnel 行——移交给 /dispatch-spawn（这是脚本调用，因此 next 不会输出字面内容）
await-worker	fork 已启动；等待 worker 返回
import	落地 worker 增量（dispatch_import，仅限 MCP）
verify	运行阶段套件并落地证据（doctrine dispatch verify，CLI）
reverify-stale	通过证据已无法反映当前 tip——重新运行套件
triage-verify-failure	RED 证据——判断节点，无命令；先进行分类处理，再做其他任何事
conclude	落地阶段边界（dispatch_conclude_phase）
reap	移除已完成的 fork（dispatch_reap）
all-reaped	阶段 funnel 已完成——移交给 doctrine dispatch status --slice <N>

并行且文件互不重叠的阶段仍采用单一指令：任何地方出现红色证据都要先分类处理（套件作用于整个 coord-tree），等待中的阶段绝不会阻止可运行阶段，其他正在执行的阶段会在每个级别的 detail 中列出。

参见 lib:reference/dispatch-mechanics.md §§“Two altitudes”和“A refusal is the recovery procedure”。

批次级节点

• Verify 的回归部分。 在 verify 节点，还要运行 doctrine check regression diff --base "$B"（套件在 S 上运行，使用与捕获时相同的规范化筛选器状态）。若出现 new ∪ changed（无论在哪个测试二进制文件／环境下显现，都属于切片回归），或无法完成运行（编译错误／panic／格式变更都必须硬性停止，绝不能静默返回绿色 ∅），则以非零状态码退出。persistent（在 B 和 S 处具有相同键和相同签名）是可容忍的环境产物；非空基线会作为 trunk 警告显示，需要修复，不能洗白成“环境问题”。停止时，列出的 new／changed 键就是问题所在；无需再进一步隔离。（将当前集的绿色结果沿用为 baseline-<B'> 是延后的成本优化；稳定状态下仍会重新捕获。）
• Import 的证明门。 worktree import --from-worktree 不会提交，并会在进程内运行拒绝并停止式证明门（在导入后的树上运行 doctrine check prove）：未格式化或 lint 呈红色的增量都会按 lib:reference/dispatch-mechanics.md 的规定使导入停止（落地或拒绝，绝不重写）。这里出现的红色属于 WORKER 增量缺陷，与上方 spawn 前的 BASE 缺陷不同。
• 注册表写入。 代码提交后，doctrine slice record-delta <SL> PHASE-NN --commit <S> 会将按提交限定的 [S^,S] 行写入主树一致性注册表（对称账本推导延后处理——机制见 /dispatch-spawn）。这不是“记得也要记录”的手动步骤：如果已落地的阶段缺少该行，Conclude 节点的完整性门会停止流程（见下文）。
• 每阶段审查。 在 import 和 conclude 之间，根据代码审查技能的 ## Cadence，权衡是否审查已落地的增量：低于遵循度门槛时默认审查；出现任何触发条件时必须审查（删除测试、Deviations: NONE、被豁免／无法检查的 VT、越界修改）。
• Knowledge 始终晚于已确认的提交，绝不先于它。

发生冲突、HEAD 移动或已修改树被触碰时，报告并停止——绝不自动解决。

交接节奏

在已提交的边界进行交接：达到 handover_after 批次（默认值为 5）或 handover_delta 累计已审查增量行数（默认值为 2000）时，以先到者为准。

基础新鲜度（驱动过程中）

长时间驱动会让 trunk 在协调分支下继续前进；这种偏移会一直不可见，直到 dispatch sync/candidate-create 因合并基点分歧而发生冲突——这是发现偏移最具破坏性的时机。dispatch status 会显示这一情况（trunk: moved (N commit(s) ahead of fork-point)）。当状态显示有变动时，运行 dispatch refresh-base --slice <N>——它会在实时协调工作树中将当前 trunk 合并到 dispatch/<N>，尽早并在上下文中推进基线，这样每次冲突都只涉及一个阶段的增量。此处发生冲突时会报告并停止，需在协调树中手动解决——绝不会自动合并。

收尾

所有阶段完成后，在协调树中、移除它之前，按以下节奏执行收尾：slice verify-vt <id> → 通过后运行 dispatch sync --prepare-review → 移除协调工作树目录（保留 refs）→ slice status <id> audit → 从父级/根目录运行 /audit。第 2 阶段集成是 /close 的工作，在审计后进行——审计前绝不落地代码。

slice verify-vt <id> 是 VT 存在性/形态检查关卡：它会读取协调树的 plan.toml，并检查每项 VT 模式标准所要求的 test_file + keywords。Fail 会以非零状态退出并 停止交接——不要越过它去准备审查；运行 /consult → 修改或豁免已编写的计划（绝不可自行放宽强制要求），然后重新运行。Uncheckable / Waived 会显示出来，但不会阻止流程。此处使用文件系统读取器即可，因为编排器（唯一写入者）已将驱动过程中途豁免提交到 dispatch/<slice>，因此协调工作树 == prepare-review 投影的已提交图。

在交接时嵌入： 将 verify-vt VT 摘要块 以及 一行回归状态（取自 verify 阶段的 check regression diff）纳入收尾输出和 /handover 数据包——这样缺口（包括 UNCHECKABLE / WAIVED，并以不同形式呈现）会在交接时显现，而不是等到审计时才发现。

prepare-review 是 强制执行 的一致性检查阶段：投影 refs 之前，它会提交边界台账，根据该已提交台账生成注册表条目（台账中的每一行都会写入主注册表——与 arm 无关），然后运行完整性 关卡；若任何已完成阶段缺少条目，就会 bail!。因此，到审计时注册表必定完整；此处发现缺口会导致流程停止（不会创建 refs），操作员需提交台账 / 通过 record-delta 记录缺口，然后重新运行。

危险信号

重要：请仔细阅读

绝不要： 不经路由就生成工作进程；让工作进程写入 .doctrine//.claude/；指望工作进程提交（它的 .git 是只读的——你要导入它的工作树）；重放分叉历史；自动合并冲突；自动调整计划/ 设计（/consult 会分叉）；在会话 main 上驱动；在收尾时集成；删除交付 refs；退回到内联执行；手动通过 Git 处理落地状态——上述顺序就是正确顺序；遇到拒绝时临时拼凑修复方法（拒绝文本本身就是流程）；“修复”缺失的 funnel 条目（未绑定的分叉永远不会落地）。 ! 绝不要退回到内联执行——如果你正准备运行 /execute，立即停止。 ! 绝不要像拿着电锯的醉汉一样使用 Git——如果你正准备进行任何可能有风险的操作，立即停止。 务必： 无论使用何种 harness，都通过 /dispatch-spawn 生成工作进程；保持上下文精简（限制报告长度，优先查看 diff 统计）；按文档规定的顺序落地每个阶段，并在开始下一阶段前完成当前阶段；提前提炼出独立完整的工作进程提示词；在提交确认后追记知识。