Skip to main content
一个 Native 项目可以同时保留多个 active change。.comet/current-change.json 只记录下一次写入归属于哪一个 workflow 和 change，不是并发数量限制。这个单一选择让 Hook Router 能把一次原子写入交给唯一 Guard，避免两个 change 同时声称拥有同一批修改。

​
查看并选择 change

先用只读命令查看候选：
确认目标后显式选择：
new 和 select 会更新共享 selection；list、show 和 status 不会靠副作用切换当前 change。多个 active change 存在且 selection 缺失、失效或指向另一套 workflow 时，写入会停止并要求明确选择。
Native 没有单独的 resume 命令。恢复由只读状态检查、目标确认和 select 组成；在 Agent 中仍从 /comet 或 /comet-native 进入。

​
哪些工作可以并行

不同 capability、不同项目产物且没有共享行为约束的 change 可以并行推进。并行前建议确认：
  • 完整目标规格是否修改同一个 capability；
  • 两个 change 是否声明相同项目产物；
  • 一个 change 的验收是否依赖另一个尚未归档的行为；
  • 当前工作区是否包含另一个 change 未归属的修改。
Runtime 会在当前 Native root 内报告可证明的 capability 冲突和可能重叠，但它不是跨机器或跨远端分支的分布式锁。未集成 worktree、其他设备和未获取的远端提交仍需要团队自行协调。

​
canonical spec 为什么会冲突

Shape 会为每个目标 capability 冻结当前 canonical spec 的 base_hash。Archive 前，Runtime 再读取当前 canonical spec：
  • hash 未变化：可以继续两步 Archive；
  • hash 已变化：说明另一个 change 已先更新同一 capability，当前 change 不能直接覆盖；
  • 当前 root 中存在可证明的范围冲突：归档预检会停止并返回 finding。
冲突不会通过“后归档者覆盖先归档者”自动解决，因为旧目标规格可能已经不再代表最新产品行为。

​
使用 spec rebase

处理顺序如下：
  1. 阅读最新 canonical spec、当前 brief 和拟议完整目标规格；
  2. 按最新基线重写完整目标规格，必要时解决新出现的用户决定；
  3. 运行 rebase：
  1. 重新进入 Build，更新实现并形成新的 implementation scope；
  2. 重新 Verify，再执行两步 Archive。
spec rebase 会刷新 operation 和 base hash，并使旧验证结论失效。不要手工修改 comet-state.yaml 中的 hash，也不要复用冲突前的 pass。

小鱼对照带蓝色书签的最新规格书重写自己的页面，再准备重新验证，表示并发 change 需要安全 rebase

​
规划归档顺序

当多个 change 修改同一 capability 时，先归档基础行为，再让后续 change rebase 到新 canonical spec，通常比同时推进到 Archive 更容易审查。完全独立的 capability 可以分别验证和归档，但每次归档仍会重新检查当前 root、证据和 selection。 若需要跨设备协作，应同时同步正式 Native 产物和项目代码，并确保每台设备的 .comet/config.yaml 指向同一个 artifact root。仅复制 changes/ 目录而保留不同的本地根目录配置，会让恢复探针看不到已有 change。 继续阅读：Native 产物与状态、验证证据与自主修复 和 恢复与故障处理。
最后修改于 2026年7月22日