用途：为一次变更建立从提案到归档的完整流程，通过四个文档依次回答为什么、做什么、怎么做、如何拆分执行，再进入执行与收尾阶段。
主要能力：按序产出 proposal.md（含 status 前置字段）、每个能力一份 specs/<capability>/spec.md 增量规格、按端（backend/frontend）拆分且始终带后缀的 design.<side>.md 与 tasks.<side>.md。proposal 与 specs 不按端拆分，属于产品事实；design 与 tasks 属各仓库的执行事实。生命周期状态为 draft→in-progress→in-review→archived，缺省视为 in-progress，仅归档阶段可置 archived。
使用方式：树根由环境变量 SPEC_VAULT_PATH 决定，未设置时回落为宿主仓库的 ./openspec，可指向共享 Markdown 库以便多个宿主仓库读写同一事实；访问方式为本地文件系统。已上线规格位于 <root>/specs/<capability>/spec.md，API 契约以 OpenAPI YAML 放在 <root>/contracts/，归档时投影到 Postman，该文件为主、Postman 不直接编辑。每个产物有 templates/ 模板，正式编写前先读对应 references 文档；遵守 requires 依赖顺序，不提前产出下游产物，缺前置时先提示补齐。
适用场景：需要跨前后端协同、要求规格成为权威并跟踪任务清单的变更流程。
限制：具体命令、安装方式与收费信息暂未提供；编写前需遵循各 references 的格式规则。