Comet Classic, OpenSpec + Superpowers

Classic 分为 Open → Design → Build → Verify → Archive 五个阶段。OpenSpec 管理需求规格与归档，Superpowers 提供设计方法，以及用户选定的规划、执行和审查方法。完整流程（full）必须经过 brainstorming 和设计确认；hotfix/tweak 使用各自的预设步骤。

1. 确定目标与工作区

开始新任务或更换宿主时，必须读取并执行宿主能力核对，在批准 Open 前确认当前流程所需的能力。执行配置改变后，只补核对新策略需要的能力。

开始或恢复前，按 comet-classic/reference/classic-layout.md 解析产物路径，并执行 comet-classic/reference/scripts.md 的“CLI 引导”。使用公开 Comet CLI 和 OpenSpec 适配器。所有参考按当前动作读取相关章节，复用上下文中仍有效的规则。

• 未明确调用 Classic、需要判定是否恢复已有工作时：读取 comet-classic/reference/context-recovery.md 的 Ambient Resume，按 comet resume-probe . --stdin --json 结果处理；只有 auto_resume 自动进入，ask_user 按 reason 使用 Ambient Resume 表格中的问题与选项提问，out_of_scope/none 不进入。
• 启动新需求或目标 change 尚不明确时：读取 comet-classic/reference/intent-frame.md 的最小示例与目标选择规则，获取未归档的 change 列表后填写 CometIntentFrame，运行 comet classic intent route --stdin。Agent 只负责按证据填写意图字段，路由由 Runtime 计算；以返回结果为准，不另写一套自然语言评分规则。
• 已明确目标 change 且已由 Runtime 初始化时：按下方绑定工作区；SDK 新 change 使用 comet-state.yaml，历史 .comet.yaml 原地读写，compat 初始化仍使用旧名，以 state next 返回的 Runtime 归属判断恢复路径，不能只看状态文件是否存在。有多个未归档的 change 且尚未选定时，不提前绑定。真正的新 change 直接交 /comet-open 或对应预设 Skill，它们会先准备工作区再初始化；workspace resolve 对未初始化的 change 会报 not found。

comet classic workspace resolve <change-name> --json
# 进入返回的 projectRoot 后选择 change
comet state select <change-name> --json

同一 change 同时存在 comet-state.yaml 和 .comet.yaml 时（包括其中一个是失效符号链接）必须停止，保留两个文件并核对来源；不得静默择一、覆盖或自动改名。

选择结果已包含当前 Runtime 归属、phase、revision 与 nextAction 时直接继续；只有缺少信息、外部状态变化或旧结果已过期时，才运行 comet state next <change-name> --json 补读。

跨设备同步应携带实际状态文件、change 文档、引用工件、代码和项目配置；检查点不包含独立子 worktree 和未提交代码。复制到新设备的 SDK change 若在实际状态文件中有 run_checkpoint，具名 state select 或 state next 会恢复原阶段、Action 和确认；继续外部工作前先确认原设备的执行进程已停止。结果未明的 Action 先核对，不重发。只有旧状态文件缺少检查点、常规入口明确报告 Run 记录丢失时，才核对正式文档，说明显式恢复会回到 Open、旧确认和检查需要重做，取得用户同意后运行 comet state restore <change-name> --confirmed。