子任务统一管理与交付
例如，一个权限管理目标可以拆成权限 API、权限配置页面和审计日志。三个结果可以独立实现和验证，但仍属于同一个产品目标，需要统一集成和最终验收。这类任务适合使用 Supervisor Change。
按照可交付结果拆分任务
Comet 会在最终 Shape 确认前检查是否值得拆分。只有同时满足以下条件，才会建议使用 Supervisor Change：- 至少有两个结果可以独立实现和验证；
- 整体目标中的每个验收项都能明确分配给某个子任务；
- 子任务之间的依赖可以明确表达；
- 并行执行或分阶段交付确实能降低整体等待时间。
children.yaml，RC1 使用 comet.native.children.v2 格式。文件中的 acceptance_index 保存从 brief.md 派生的整体目标验收项，包括每项的验收 ID、来源和完整文字；每个子任务只声明唯一名称、依赖项和自己覆盖的验收 ID。Runtime 会检查名称重复、未知依赖、依赖环和验收遗漏。
用户选择拆分方案与推进方式
确认前，Comet 会展示整体目标、子任务列表、依赖关系和验收映射。用户可以调整拆分、继续使用单个 Native Change，或者选择一种推进方式：
推进方式只决定子任务在哪里执行；拆分结果、依赖、验收标准和集成规则在两种方式下保持一致。确认 Supervisor 拆分时，Runtime 会把选择作为
coordination_mode 写入 comet-state.yaml。恢复流程或因需求变化重新进入 Shape 时会沿用这个选择，只有出现新的用户可见决定时，流程才会返回 Shape，请用户重新确认。
确认之前，Runtime 不会创建子任务、worktree 或外部会话。包含两个或更多子任务时，普通的“确认”也不能代替推进方式选择。
完整方案和两种方式一起展示后，你可以一次回复，例如“确认当前方案，采用 A 多会话协作”。仅回复“A”只表示选择推进方式，不代表确认完整方案；方案、验收或子任务调整后仍需重新确认。
每个子任务都有独立工作区
Shape 确认后，Runtime 会先为主任务创建专用的集成分支和集成 worktree，再以集成分支的当前提交为起点，为各个子任务准备独立 worktree 和任务包。 每份任务包包含：- 子任务的角色和验收范围；
- 唯一的工作目录；
- 当前集成基线提交；
- 用于绑定任务回报的
runId； - 依赖条件和停止条件。
readyChildren 告诉主会话哪些子任务现在可以开始。多会话模式默认最多同时启动两个互不依赖的子任务；单会话模式按顺序执行。需要临时改为串行时，由主会话在分发任务时指定：
在 Codex 中采用多会话并行推进
在 Codex 中选择多会话协作后，当前会话成为主会话。它负责分配任务、持续检查进度、处理阻塞、让 Runtime 集成已经验证的结果，并完成主任务的最终 Verify。主会话不直接进入子任务 worktree 修改代码。readyChildren 中的每个子任务都会交给一个用户可见的独立任务。独立任务沿用当前项目，并直接进入 Runtime 已经准备好的子任务目录，无需另外创建 worktree。独立任务报告完成后，结果还要经过子任务 Verify 和 Runtime 集成；主会话以集成后的状态为准，才继续下一步。
在 Claude Code 中采用 Agent Teams 并行推进
在 Claude Code 的交互式会话中，可以使用 Agent Teams 运行不同子任务。PowerShell 中可通过以下环境变量启用：readyChildren 中的每个子任务分配一个有明确名称的 teammate。teammate 只在 Runtime 指定的子任务 worktree 中工作，不能自行创建新的工作区、领取依赖尚未满足的子任务、集成主任务分支或创建嵌套团队。
Agent Teams 负责运行多个会话，Native Runtime 仍然负责工作区、任务状态、验证和集成：任务状态以 Runtime 记录为准，主任务的最终验收也由它执行，团队成员的消息只作为进度参考。
先验证，再集成
每个子任务都必须经过active → verified → integrated：
- Builder 在子任务 worktree 中完成候选实现，并提交绑定当前
runId的结果； - 独立 Verifier 检查候选提交和子任务验收范围；
- Runtime 只接受角色、
runId和当前任务状态都匹配的回报； - 验证通过后，Runtime 把已验证提交集成到 Supervisor 的集成 worktree，并运行必要的集成检查。
integrated，依赖它的后续子任务才会进入 readyChildren。
集成完成后统一验收
所有子任务进入integrated 后，Runtime 会立即推进主任务的最终 Verify。最终 Verify 在集成 worktree 中运行至少一项集成检查，并覆盖整体目标的完整验收范围。
最终 Verify 通过后，Supervisor Change 才能进入 Archive。用户按 Native 的归档交付选项决定保留工作区、本地合并、推送或创建 PR（选项语义见归档与交付），目标分支在最终交付前不会被提前修改。
如果最终 Verify 失败，Runtime 会保留集成现场，不会重新打开已经完成集成的子任务。流程会根据实际失败的验收项追加一个名称唯一的修复子任务，补充整体目标的验收映射，并返回 Shape 让用户确认新增修复范围。最后一个子任务集成后仍允许在父级直接提交小修复，最终 Verify 会记录实际核验的集成提交；恢复时中断的最终验证记录会自动补全或按需重跑。
可恢复的任务进度
子任务汇总、readyChildren、集成状态和下一步动作都记录在 Runtime 状态中，主会话在恢复或推进任务时会通过 comet native status <supervisor-change> --details --json 读取。你只需要让 Agent 继续当前任务，这些查询和衔接由主会话自动完成。
在恢复任务时，Comet 以 Runtime 持久化的 coordination_mode 为准，不重复创建已有子任务或 worktree。multi-session 继续使用多会话协作，single-session 继续由当前会话按顺序推进。
如果原来的 Codex 独立会话或 Claude Code Agent Team 已经不存在，Comet 会重新读取 Runtime，并在 multi-session 下自动改用 subagent。已经派发但丢失的任务会先通过 supervisor-cancel 使旧 runId 失效，再使用新的任务包和 runId 重新派发；旧执行的迟到结果会被拒绝。subagent 也不可用时，Comet 会报告真实阻塞，不会自动切换为单会话推进。
继续阅读 Native Loop，了解主任务和子任务共用的验收机制。阅读 多 Change 与规格冲突 和 恢复手册，了解并发冲突与中断恢复。