seemseam /ccb:su-batch
1. 指令意图说明
/ccb:su-batch 用于让用户授权 AI 团队在明确范围内连续推进多个节点或多个子任务。它的核心不是“省人工点击”，而是定义自治范围、停止边界和升级条件。
2. 节点集声明
可覆盖完整 7 节点集，但每个节点仍按自己的 manifest 执行：
| 节点 | Manifest |
|---|---|
| 需求分析 | references/kernel/nodes/requirement_analysis.node.md |
| 技术设计 | references/kernel/nodes/technical_design.node.md |
| 任务拆分 | references/kernel/nodes/task_breakdown.node.md |
| 派工 | references/kernel/nodes/dispatch.node.md |
| 实施 | references/kernel/nodes/implementation.node.md |
| 审查 | references/kernel/nodes/review.node.md |
| 归档 | references/kernel/nodes/archive.node.md |
3. 触发约定
/ccb:su-batch scope=requirement requirement_id=<id>
/ccb:su-batch scope=subtasks requirement_id=<id> count=<n>
/ccb:su-batch 允许这个需求下的子任务连续推进
/ccb:su-batch --payload {"subject":"requirement","scope":"subtasks","requirement_id":"<id>","task_ids":["<subtaskId>"],"policy_profile":"autonomous-batch","stop_policy":{"on_subtask_failure":"stop_and_report"}}
用户必须知道授权范围和停止条件。AI 不得把一次 batch 授权解释成无限期全项目自治。
subtask set 轻量 coordinator 契约
当 payload scope="subtasks" 且包含 task_ids 时，本指令就是一次轻量批量推进：
- 先读取
requirement_id、task_ids对应的需求文档、dev_task 文档、拆分草案和 EventJournal，确认全部属于同一需求。 - 自行判断执行顺序；如果依赖关系或当前状态与 task set 冲突，停止并报告原因，不要跳过出错项继续推进。
- 对每个子任务派工给执行 agent 前，按 dev_task 的
code_workspace调用ensureRequirementWorktree({ projectRoot, requirementId, codeWorkspace })；同一 requirement 重复调用必须视为幂等 no-op，确保 ask 发出前 codeRoot 已存在。 - 对每个子任务逐个子任务走
implementation→review→archive。实施可调用执行 agent；review 轻重由当前上下文和风险自判，但归档前必须有 review 通过或明确风险授权。 - 每个子任务完成后让文件真相源落地，Console 通过现有 per-subtask 状态投影展示进度；本轻量契约不维护独立 batch 进度条。
- 失败即停：任一子任务 implementation/review/archive 失败时，停止后续子任务，报告已 done、未 done、失败子任务和原因。
stop_policy.on_subtask_failure="stop_and_report"是默认且唯一支持策略。 - 本档不做精细 cursor 断点续跑；恢复时必须重新读取 dev_task frontmatter 和 EventJournal，再向用户说明可安全继续的范围。
- 每个子任务 archive 只写该 dev_task 真相源终态，不调用 worktree merge/cleanup。当最后一个
scope 成员归档完成后，AI 执行 requirement 收尾判断：调用本技能内的
isRequirementFullyTerminal(requirementId)，扫描该需求下全部 dev_task，排除status: cancelled后确认每个剩余 dev_task 均为status: done + current_node: archive + review_status: passed，且无未物化的 approved follow-up draft。若为真，只执行mergeRequirementWorktree()，让该需求全部 implementation spaces 及其 associations 的 runtime 进入merged并停止；requirement md 必须保持非 delivered（通常为delivering），各 worktree+分支保留给用户预览。不得在 batch 尾部调用cleanupRequirementWorktree()或requirement.finalize。若为假，不合并，并说明仍未终态的 requirement 内子任务或 follow-up。 - 投影收敛（不依赖 watcher）：每个子任务归档后、以及 finalize 后，best-effort 主动触发一次 Console 投影刷新（本地 Console 在跑时
POST /api/projects/<projectId>/scan），并校验关键投影（子任务current_node/status、需求status）与 canonical 文件一致。WSL2 watcher 会漏文件事件，故不得只依赖它异步跟上；Console 不可达或投影与 canonical 不一致时，明确告知用户需手动 scan，不得在投影未确认收敛时声称"已交付且界面一致"。
使用 helper 时从 plugin lib 引入：
import {
ensureRequirementWorktree,
mergeRequirementWorktree
} from "../../lib/worktree/index.mjs";
4. Plugin 独立运行约定
batch 授权写入 EventJournal。members.task_key / execution_order 是批次执行和审计
scope 来源；需求自动收尾以 isRequirementFullyTerminal(requirementId) 的全需求扫描为准，但只做
merge-only 预览暂停。dev_task_requirement_terminal evidence 只在后续
/ccb:su-archive requirement_id=<id> 手动归档时用于 finalize。members.task_id 仅用于和
Console/DB 投影做一致性观察。后续节点推进仍由 plugin 文件真相源驱动，不调用 Console 业务写入接口。
5. 强协商与 sc 要求
建立 batch 前必须：
- 让 Codex 协商授权范围是否清楚。
- 扫描必问项，尤其是成本、隐私、合规和不可逆工程动作。
- 写 4 锚点反思。
- 记录停止条件：遇到用户必问项、协商无新增信息、验证失败、范围冲突或外部服务风险。
6. 用户可见输出
输出授权范围、预计会经过的节点、停止条件、用户仍需拍板的事项和 batch 记录路径。