> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Native 工作流
> 面向 Fable 5、GPT-5.6 等强模型的自包含需求工作流：详细约束、轻量执行、可恢复证据。
Comet Native 是专门适配 Fable 5、GPT-5.6 这一档强编码模型的 Skill。它假设模型能够自主调查代码、形成实现方案并按风险选择测试，因此不再强制固定的设计、计划、TDD、调试或审查方法；同时仍用 Comet 自有 Runtime 管理需求、完整目标规格、阶段、证据、冲突与归档。
它的核心原则是：**需求与验收要具体，执行方法保持轻量。** 轻量指减少对强模型不必要的过程编排，不是减少需求质量或取消验证。
## Native 与 Classic 如何选择
| 维度 | Native | Classic Spec 模式 |
| ------- | ---------------------------------------- | ---------------------------------------- |
| 主要适用模型 | Fable 5、GPT-5.6 及同档强模型 | 低于 Fable 5、GPT-5.6 这一能力档、需要更细步骤指导的模型 |
| 工作流 | Shape → Build → Verify → Archive | open → design → build → verify → archive |
| 需求与状态 | Comet 自有 brief、完整目标规格、`comet-state.yaml` | OpenSpec change/delta spec、`.comet.yaml` |
| 实现过程 | 模型按仓库事实与风险自主选择 | 显式组织设计、计划、TDD、调试与审查协议 |
| 依赖 | Comet Native Skill 与 Runtime | Comet Classic、OpenSpec 与 Superpowers |
| 适合的约束强度 | 强结果约束，较少方法约束 | 更细阶段指导与过程约束 |
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 真实评估](/zh/eval/comet-native-vs-040-experiment)。
模型名称是便于选择的能力档参考，不是 Runtime 的硬编码检测条件。Comet
不读取模型名称自动切换工作流；最终选择由项目配置决定。
## 统一入口，独立生命周期
`/comet` 读取 `.comet/config.yaml`，再确定性转发到 `/comet-native` 或 `/comet-classic`。配置可以只启用一种工作流，也可以同时启用两种：
```yaml theme={null}
schema: comet.project.v1
default_workflow: native
workflows:
- native
- classic
ambient_resume: true
native:
artifact_root: docs
language: zh-CN
clarification_mode: sequential
classic:
language: zh-CN
context_compression: off
review_mode: standard
auto_transition: true
```
`default_workflow` 只决定 `/comet` 进入哪一侧；不会迁移、删除或合并 change。Native 与 Classic 保持各自的 phase、schema、change、规格和归档目录，即使同一项目同时启用也不会互相转换。
## 四阶段工作流
```mermaid theme={null}
flowchart LR
S["Shape"] --> B["Build"]
B --> V["Verify"]
V -->|pass| A["Archive"]
V -->|fail| B
```
### Shape：固定目标与用户决定
Shape 先调查仓库事实，再把 Outcome、Scope、Non-goals、Acceptance examples、Constraints and invariants、Decisions、Open questions 与 Verification expectations 写入 `brief.md`。
模型需要区分两类选择：
* 会改变用户可见结果、默认行为、兼容性、范围、风险或不可逆结果的，是用户决定；
* 只改变实现方式而不改变可观察结果的，是模型自主选择。
存在用户决定时，Sequential 模式每轮询问一个最上游问题；Batch 模式会一次提出本轮所有可回答问题，并在进入 Build 前要求用户确认最终的共享理解。两种模式都提供推荐和选项影响；`[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 存在并发冲突；
* 相同失败在没有进展的情况下重复出现。
因此，Native 的“自动”是有状态的连续推进，不是后台 daemon，也不是跳过用户决策或安全检查。
继续阅读：[Native 快速开始](/zh/native/quickstart)、[Native 配置](/zh/native/configuration)、[产物与状态](/zh/native/artifacts-and-state)、[安全与恢复](/zh/native/safety-and-recovery)。