seemseam /ccb:su-dispatch
1. 指令意图说明
/ccb:su-dispatch 用于把一个已明确的 DeliveryUnit / 子任务派给 Codex、Claude 或其他执行 agent。它解决的业务问题是：执行者要清楚知道做什么、不做什么、怎么验证、如何回执。
2. 节点集声明
主要进入：
| 节点 | Manifest |
|---|---|
| 派工 | references/kernel/nodes/dispatch.node.md |
必要时可回退：
| 场景 | 回退节点 |
|---|---|
| 子任务边界不清 | references/kernel/nodes/task_breakdown.node.md |
| 技术方案缺失 | references/kernel/nodes/technical_design.node.md |
| 用户原意不清 | references/kernel/nodes/requirement_analysis.node.md |
3. 触发约定
/ccb:su-dispatch --payload {"subject":"subtask","task_id":"<subtaskId>","owner":"ccb_codex"}
/ccb:su-dispatch --payload {"subject":"subtask","task_id":"<subtaskId>","target_agent":"slot1_codex","cross_group_reason":"指定跨组复核"}
/ccb:su-dispatch 按当前子任务派给 codex
Console UI 可以投递同等 --payload JSON 命令到 anchor。payload 只用于定位主体和执行者，不授权跳过 dispatch manifest。
ask target 路由契约
派工提交前必须先解析实际 ccb ask 目标：
import {
buildCcbAskInvocation,
resolveAskRouting
} from "../../lib/ask-routing/index.mjs";
规则：
target_agent或用户自然语言里明确的 agent 名才算显式 target；owner=ccb_codex/owner=claude只是 dev_task 执行角色，不得直接当 ask target。- 未显式 target 时调用
resolveAskRouting({ projectRoot })，用当前 actor 所在 window 的唯一互补 provider 成员作为默认目标。 - helper 返回
status="needs_explicit_target"时，派工必须 deferred 并要求用户或上游流程给出实际 agent，不能 fallback 到main_codex或其它项目级默认。 - 显式 target 保持不变；若 helper 返回
routing.warnings或routing.crossGroup.requiresReason=true，派工 brief / 用户输出必须写明跨组 warning 或cross_group_reason，但不硬拦合法跨组。 - 生成命令时使用
buildCcbAskInvocation({ target: routing.target, taskId })；消息正文仍按 dispatch brief 合同单独构造，不拼进 target。
breakdown-draft read 契约
如果派工 brief 需要引用原 Requirement 的拆分草案，只能通过 lib 读取：
import { readBreakdownDraft } from "../../lib/breakdown-draft/index.mjs";
const { draft, hash } = await readBreakdownDraft({ projectRoot, requirementId });
dispatch 只读取 draft 来确认 include、依赖、owner 和验收，不在本指令里修改 draft。ValidationError 说明草案不可作为派工依据；LockTimeoutError 说明另一个 anchor 正在写，需稍后重试。严禁用 fs.writeFile 直接改 docs/.ccb/drafts/breakdown/*.json。
requirement worktree ensure 契约
对带 code_workspace 的 dev_task，派工在 ccb ask 前必须先调用 plugin worktree helper：
import { ensureRequirementWorktree } from "../../lib/worktree/index.mjs";
await ensureRequirementWorktree({
projectRoot,
requirementId,
codeWorkspace: devTask.code_workspace
});
ensureRequirementWorktree 是幂等前置动作：首次按项目拓扑展开该需求名下全部实施空间，零拓扑声明时退化为单 root 空间 ../SU-CCB-req-<reqId>；重复派工 no-op。helper 会把每个空间的 target_branch / base_sha 写入 canonicalRoot 的 docs/.ccb/worktrees/<reqId>.json，只有 aggregate_status=ready 才能提交 ccb ask；不要让 Codex 自建 worktree。
派工 brief 必须从 docs/.ccb/worktrees/<reqId>.json 附运行态空间表，至少包含 space_id、repo、path、branch、target_branch。单空间时也按同一表述给出 root 空间，避免执行者依赖旧的隐含单 worktree 规则。
4. Plugin 独立运行约定
本 skill 直接读取：
启动/定位上下文时先读 docs/00_项目总览.md、docs/00_文档地图.md 和 docs/.ccb/docs-structure-contract.yaml。业务文档落点必须经 docs-structure resolver / 目录契约定位。
- dev_task 文档（经 resolver 定位；当前契约落点为
docs/03_开发计划/） docs/.ccb/drafts/breakdown/*.jsondocs/.ccb/events/journal.jsonl
派工 brief 和任务流转写入对应 dev_task frontmatter / 正文中的受治理区域，并通过 ccbd/ask 通信路径交给目标 agent；审计事件写 EventJournal。不得调用 Console 业务写入接口写业务状态。
5. 强协商与 sc 要求
派工前必须：
- 使用 dispatch 节点推荐 sc 指令，或说明替代方式。
- 让 Codex 从执行者视角审查 brief。
- 写 4 锚点反思。
- 记录派工结果和可追踪 id。
6. 用户可见输出
输出 brief 摘要、目标 agent、禁止范围、验证要求、回执要求、派工状态和下一步等待项。