它解决什么问题
什么时候触发拆分
PRD 拆分预检在/comet-open 的 Step 1a 触发，条件是输入属于以下任一情况：
- 大型 PRD、路线图、完整产品方案
- 澄清摘要包含多个独立能力、模块、用户路径或里程碑
拆分流程
大型 PRD 先拆成独立 change，范围、依赖和验收都写清楚后再逐个推进
候选拆分清单
推荐拆分时，Comet 会为每个候选项列出：- 建议 change 名称
- 目标与范围边界
- 明确非目标
- 依赖关系或推荐执行顺序
- 对应的核心验收场景
用户的三选一（阻塞点）
在创建任何 proposal/design/tasks 之前，Comet 必须暂停让你选择：- 创建多个 OpenSpec changes — 按候选拆分逐个创建独立 change。
- 保持为一个 change — 继续单 change 流程，并在 proposal/design/tasks 里记录不拆分的原因。
- 调整拆分方案 — 说明调整方向后，重新输出候选拆分清单并再次确认。
每个 change 如何创建
选择拆分后，每个被接受的拆分项都通过独立的/comet-open 创建，而不是 /opsx:new。原因：
/comet-open同时创建 OpenSpec artifacts 和.comet.yaml，确保每个 change 都进入 Comet 状态机。/opsx:new只创建 OpenSpec artifacts，change 会落在状态机之外，无法用/comet恢复和守卫。
- 进入每个拆分项时标注”已确认拆分项”，携带该拆分项的目标、范围、非目标和验收场景。
- 已确认拆分项默认跳过 PRD 拆分预检（除非该拆分项本身仍明显包含多个独立 capability）。
- 单个拆分项完成 open 阶段后不会自动流转到
/comet-design。拆分完毕后暂停，让你选择开始哪一个 change。
拆分后怎么推进
拆分产生多个 active change。推进方式：- 每个 change 独立走 design → build → verify → archive。
- 一个 change 归档后，用
/comet选择下一个 active change 继续。 - 各 change 之间可以有依赖顺序（候选拆分清单里会标注），但 Comet 不强制串行——你可以并行推进独立的部分。
中断了怎么恢复
批量拆分不新增专用状态文件，靠现有 active changes 做最小断点恢复：- 拆分过程中断后，恢复时先检查已创建的 active changes。
- 已存在且包含
.comet.yaml的拆分项不会重复创建。 - 未创建的拆分项按你已确认的拆分清单继续通过
/comet-open创建。 - 如果对话里已确认的拆分清单不可恢复，Comet 会重新向你确认拆分清单再继续。
真实场景示例
场景一：用户系统重构
输入一份 PRD，包含”用户注册登录、个人资料、权限管理、操作审计”四个模块。
你选择”创建多个 changes”。Comet 逐个创建
user-auth、user-profile、user-rbac、user-audit，每个都是独立 active change。
推进时先从 user-auth（无依赖）开始：
user-auth，走完 design → build → verify → archive。然后继续 user-profile。
场景二：平台迁移
输入一份迁移方案，包含”替换数据库、重写数据访问层、迁移 API、更新前端适配”。
这里依赖是强串行的，候选拆分清单标注了推荐执行顺序。你按 1→2→3→4 依次推进。