Native 与 Classic 如何选择
Classic 并不是旧版 Native，也不是失败后的降级路径。对于 Fable 5、GPT-5.6 以下的模型，更细的 Spec 与执行阶段可以减少遗漏和流程漂移；Comet 现有真实基线评估已经验证，Classic 的强约束能在这类任务中保持良好的任务覆盖与完成效果。Native 则面向已经具备更强自主推理能力的模型，减少重复阶段与依赖 Skill 带来的执行负担。
现有 Native 与 0.4.0 Classic 的对齐实验包含 16 个任务、每个任务 3 次运行；两种模式的任务级
pass@3 都是 100%。该实验支持“两种工作流都能覆盖任务、Native 在该实验中执行更轻”的结论，但不能单独证明所有模型、仓库和任务上的因果优势。详见 Native 与 Classic 真实评估。
模型名称是便于选择的能力档参考，不是 Runtime 的硬编码检测条件。Comet
不读取模型名称自动切换工作流；最终选择由项目配置决定。
统一入口，独立生命周期
/comet 读取 .comet/config.yaml，再确定性转发到 /comet-native 或 /comet-classic。配置可以只启用一种工作流，也可以同时启用两种：
default_workflow 只决定 /comet 进入哪一侧；不会迁移、删除或合并 change。Native 与 Classic 保持各自的 phase、schema、change、规格和归档目录，即使同一项目同时启用也不会互相转换。
四阶段工作流
Shape：固定目标与用户决定
Shape 先调查仓库事实，再把 Outcome、Scope、Non-goals、Acceptance examples、Constraints and invariants、Decisions、Open questions 与 Verification expectations 写入brief.md。
模型需要区分两类选择：
- 会改变用户可见结果、默认行为、兼容性、范围、风险或不可逆结果的，是用户决定；
- 只改变实现方式而不改变可观察结果的，是模型自主选择。
[blocking] 问题解决前不能进入 Build。改变长期行为时，Shape 还会为每个 capability 写完整目标规格，而不是只记录增量 patch。
Build：让强模型自主实现
Build 以 brief、完整目标规格和仓库规则为边界。模型自行决定是否需要落盘计划、采用何种测试粒度、如何调试与审查；Native 不要求为了流程制造额外文档，也不强制 TDD。 若实现中出现新的产品决定，工作流返回澄清。推进 Verify 前，Runtime 会把真实项目产物固化为 implementation scope；无法证明范围完整时会停下，只有用户明确接受与 scope hash 绑定的风险后才能按 partial scope 推进。Verify：把结论绑定到当前事实
Verify 对照 Acceptance examples、完整目标规格和实现风险运行实际检查。verification.md 记录命令、结果、跳过理由、已知限制和逐项 Acceptance evidence。
Runtime 将验证结论绑定到当前 brief、目标规格、implementation scope 和 revision。任一输入变化后，旧报告、旧 receipt 和旧 pass 都会变为 stale，不能用于归档。失败会返回 Build；相同 scope 下重复出现相同失败且没有真实进展时，Runtime 会从自主修复转为人工停止，避免无限循环。
Archive：两步预检后提交
Archive 先生成内容绑定的preflightHash，再在提交时重新检查证据、路径与 canonical spec hash。并行 change 已改变同一 capability 时，归档会停止而不是覆盖；模型需要读取最新 canonical spec，使用 spec rebase 刷新基线，再重新实现和验证。
归档成功后，完整目标规格成为 canonical spec，active change 移入带日期的 archive 目录。trajectory 只保存阶段摘要与证据引用，不记录隐藏推理过程。
自动推进的边界
阶段条件满足时，Runtime 返回结构化 continuation，让同一个/comet-native Skill 继续执行。以下情况会停下：
- 仍有未解决的用户决定；
- 配置、状态、锁或事务无法安全解释；
- 验证证据失效或实现范围不完整；
- canonical spec 存在并发冲突；
- 相同失败在没有进展的情况下重复出现。