它解决什么问题
design 阶段结束时，需要把 OpenSpec 的需求规格（proposal、design、tasks、delta spec）交给 build 阶段作为实现依据。默认模式下这些内容完整传入，token 开销大。上下文压缩通过 hash 引用和结构化投影减少冗余传输。两种模式
off 保留完整摘要，beta 保留 delta spec 并用 hash 引用 supporting 文件
off 模式
生成完整但可追溯的摘要：design-context.json— 机器索引（change、phase、canonical spec、源文件路径、per-file sha256、context_hash）design-context.md— Superpowers 可读上下文，每文件带源路径、行范围、sha256 和确定性摘要。超过 80 行的文件截断，带[TRUNCATED]标记和Full source:指针。
--full 标志可以输出 verbatim 完整内容而不是截断。
beta 模式
生成结构化 spec 投影：spec-context.json— 机器索引，每文件标role: spec（delta spec）或role: supporting（proposal/design/tasks）spec-context.md— 紧凑上下文：delta spec 文件 verbatim 投影（完整保留验收场景），proposal/design/tasks 只存 hash 引用
beta 模式下
—full 被忽略（会输出 warning）。beta 只对 delta spec 做 verbatim 投影，其他文件靠 hash 引用，所以节省来自不重复传输 proposal/design/tasks 的全文。为什么 delta spec 要完整保留
OpenSpec 的 delta spec（specs/<capability>/spec.md）包含验收场景，是实现正确性的关键依据。beta 模式完整保留 delta spec 内容（verbatim 投影），只对 proposal/design/tasks 用 hash 引用。这保证：
- 验收场景零漂移——不管 spec 是中文还是英文，投影都完整保留。
- proposal/design/tasks 的完整性靠 sha256 验证——需要时按 hash 回查原文件，而不是靠 Agent 摘要。
何时触发
上下文压缩在 design→build 交接时触发，由comet-handoff.mjs <change> design --write 生成。
design 守卫会检查交接包的存在和有效性：handoff_context/handoff_hash 必须写入 .comet.yaml，markdown 包必须带 Generated-by: 标记和可追溯的源/hash 引用。beta 模式下 spec-context.json 还必须结构有效并引用当前源文件。
主动式压缩
design 阶段在写完brainstorm-summary.md 后、创建 Design Doc 之前，会触发平台原生的 compact/compaction 机制（如果平台支持），或暂停让你手动执行。压缩后重新加载交接文件。这是独立于 context_compression 的运行时优化。
性能数据
来自 Comet 的 benchmark 测试：
beta 模式在保持 100% 测试通过率的同时节省约 25–30% token，代价是 spec 覆盖率从 100% 降到 95%（因为部分 supporting 文件靠 hash 引用而非全文）。
怎么启用 beta
项目级（推荐）
编辑.comet/config.yaml：
.comet.yaml。
单个 change
通过comet-state 命令：
环境变量临时覆盖
怎么选
下一步
- Classic 配置 — context_compression 字段和配置优先级
- 代码审查机制 — 另一个项目配置项
- 工作流概念 — design→build 交接在五阶段中的位置
- comet-handoff — 交接包生成的脚本细节