yibie Capture
把已确认的共识写成一个活的设计契约。
前置条件
plan已结束并得到approve、compatible revise、breaking，或明确的plan-only执行授权。breaking时，SPEC 必须包含迁移方案；ADR 不在这里写， 由learn收尾时写。- 设计需要跨多个上下文，或必须交给之后的 agent 继续。
docs/spec-agents/WORKFLOW.md、CONTEXT.md、项目KERNEL.md（若存在）、 相关 ADR、Protocol、Runbook 和 Lesson 已被读取；冲突回到plan。
写入位置
创建或更新：
.specs/<feature>/SPEC.md
不要在根目录再创建第二份 SPEC。目录不存在时按需创建；不要预建未来 feature 的文件。
SPEC 最小结构
# <feature>
status: draft | confirmed | in-progress | revised | superseded
revision: <number>
context_refs:
## Problem and goal
## Unchanged contracts
## Decision and boundaries
## Model delta
## Action Contracts
## Seams and verification
## Compatibility and migration
## Out of scope
## Issue map
## Revision notes
记录“已经决定的 what/why/where”，不要把新的取舍藏进 SPEC。实现细节只写到能让后续切片保持一致的程度。
当 SPEC 是 Kernel Bootstrap 时，记录 K1 已确认的概念、关系、动作契约和
不变量，以及待确认的扩展；不要把 K1 复制成第二份长期真相。验证通过后由
learn 更新项目 KERNEL.md。
修订
- 文字澄清、链接和验证补充可以直接修订。
- 改变目标、边界、身份、关系、不变量、接口或验收标准，必须重新经过
plan。 - 修订时保留 revision、原因、受影响的 CONTEXT/Protocol、兼容性、迁移和验证。
- 受影响的 Slice 标为
stale；不要让旧 Slice 继续执行。
完成条件
SPEC 状态、未改变的契约、边界、Action Contracts、验证入口和 out-of-scope 齐全，并能让一个新上下文不依赖本次对话继续工作。