comet resume-probe 用来处理长任务里的“恢复识别”问题。
典型场景是：你想继续已有 Comet change，但会话、上下文窗口或设备已经变化，Agent 看不到连续对话，也没有新的 /comet 显式触发。
恢复探测会只读比对当前请求与 active changes，判断是否应回到 Native 或 Classic 流程，避免把“继续刚才的登录重构”误当成一条全新普通任务。
它会先读取项目 .comet/config.yaml，确认当前采用 Native 还是 Classic；再只读取该工作流下的 active changes、当前阶段与用户请求。旧 Classic 项目在没有有效 workflow 配置时走 legacy fallback；如果配置损坏，则直接停止并要求修复，不会跨工作流盲扫目录。
恢复探测只返回识别和路由结论。它不会修改 change、推进阶段、替用户在多个 change 里做决定，也不会自动执行下一条命令。Agent 应根据 nextCommand 调用 /comet-native 或 /comet-classic 完成恢复。
为什么需要恢复探测
长程任务不一定始终处于同一个完整上下文中。以下情况都可能让 Agent 忘记当前工作原本由 Comet 管理：- 对话经过上下文压缩、切换窗口或开启新会话；
- 用户换设备继续同一个仓库和 change；
- 新 Agent 只能看到磁盘状态和一句“继续之前的工作”；
- 用户自然地要求继续任务，但没有再次输入
/comet。
恢复探测不是要求用户记住一个额外命令。它主要供 Agent 和项目恢复说明调用，用来补上”用自然语言继续任务”和显式
/comet 入口之间的缺口。自动探测如何发生
用户不需要输入comet resume-probe。正常交互仍然是直接告诉 Agent：
继续刚才的登录重构。
comet init 和 comet update 会把恢复说明写入项目的 Agent 指令文件。当 ambient_resume 开启时，Agent 在处理可能属于长程任务的自然语言请求前，会自动运行只读恢复探测：
- 读取项目配置，确定应检查 Native 还是 Classic；
- 比较用户请求、active changes、当前阶段和 selection；
- 目标唯一时按
nextCommand重新进入对应的/comet-native或/comet-classic； - 目标有歧义时只问用户一个问题；请求无关时正常处理，不进入 Comet。
/comet 时会直接按项目配置进入工作流，不依赖自动探测。通过平台显式调用的非 Comet Skill 或斜杠命令同样不触发恢复探测——任务意图已经由该调用明确，直接执行该 Skill 即可。项目若设置 ambient_resume: false，普通自然语言请求不会触发自动恢复探测，但 /comet 仍然可用。
对用户而言，恢复探测是自动的。下面的 CLI 参数用于 Agent、Hook、项目指令和自动化集成，不是恢复任务前必须手工执行的步骤。
Agent 与自动化集成参考
Agent 或集成可以直接传入请求：如何理解结果
JSON 使用
comet.resume_probe.v2，包含 workflow、skill、entrySource、reasonCode、candidates、changeName、phase、nextCommand 和判断证据。Native 任一阶段都通过 /comet-native 恢复；comet native next 是状态推进命令，不是恢复入口。Classic 自带 runtime 的内部 v1 检查保持兼容，但顶层 CLI 返回 v2。
哪些情况一定会暂停
- 多个 active change，但用户请求没有点名目标。
- 多个 active change 且没有有效 selection 或用户点名。
- active change 缺少有效状态或项目配置损坏。
- 当前处于 plan-ready、验证失败、归档确认等用户决策点。
- 请求与已有 change 无关或只是信息查询时不会恢复，而是返回
out_of_scope。
/comet-native 检查现场；Classic 继续保留工作树归属确认规则。
与其他命令的区别
下一步
- 恢复中断的工作 — 自然语言恢复与显式
/comet的使用方式 - 状态损坏与恢复 — 恢复探测提示状态异常时如何排查
- comet status — 查看全部 active change 的详细状态