术语表
所有 OpenSpec 术语集中于此，以通俗易懂的语言定义。浏览一遍后，阅读其余文档会更快。
术语按主题分组，每组内按字母顺序排列。
核心名词
规范（Spec）。 描述系统某部分行为的文档。规范存放在 openspec/specs/ 目录下，按领域组织，由需求和场景组成。规范是对"这个软件做什么"这一问题的共识性回答。参见 概念。
事实来源（Source of truth）。 即整个 openspec/specs/ 目录。它保存了系统当前已达成共识的行为。变更（Change）提出对该目录的编辑建议；归档（Archive）则将这些编辑正式应用。
变更（Change）。 一个工作单元，打包为 openspec/changes/<name>/ 下的文件夹。变更包含与该工作相关的一切内容：提案、设计、任务，以及它引入的规范编辑。一个变更对应一个功能或修复。
工件（Artifact）。 变更内部的文档。标准工件包括提案、增量规范、设计和任务。它们按依赖顺序创建，并相互衔接。
增量规范（Delta spec）。 变更内部的规范，仅描述正在变更的内容，使用 ADDED、MODIFIED 和 REMOVED 部分，而非重新陈述整个规范。这正是 OpenSpec 能够干净地编辑现有系统的原因。参见 概念。
领域（Domain）。 规范的逻辑分组，例如 auth/、payments/ 或 ui/。你选择与自己对系统认知方式相匹配的领域。
规范内部
需求（Requirement）。 系统必须具备的单一行为，通常使用 RFC 2119 关键词书写："系统 SHALL 在 30 分钟后使会话过期。"需求描述的是做什么，而非怎么做。
场景（Scenario）。 需求的具体、可测试示例，通常采用 Given/When/Then 形式。场景使需求变得可验证：你可以据此编写自动化测试。
RFC 2119 关键词。 MUST、SHALL、SHOULD 和 MAY 这些词，它们带有标准化的含义，表示需求的严格程度。MUST 和 SHALL 表示绝对要求。SHOULD 表示推荐但允许例外。MAY 表示可选。该名称来源于定义它们的互联网标准文档。
工件
提案（proposal.md）。 变更的为什么和做什么：其意图、范围和高层方法。这是你创建的第一个工件。
设计（design.md）。 怎么做：技术方案、架构决策以及你预期修改的文件。对于简单变更，此项可选。
任务（tasks.md）。 带复选框的实现清单。AI 在 /opsx:apply 期间逐项处理，并随进度勾选完成项。
生命周期
归档（Archive）。 完成变更的操作。其增量规范合并到主规范中，变更文件夹移至 openspec/changes/archive/YYYY-MM-DD-<name>/。归档后，你的规范描述的是新的现实状态。参见 概念。
同步（Sync）。 将变更的增量规范合并到主规范中，但不归档该变更。通常自动执行（归档时会提示执行），但也可通过 /opsx:sync 单独使用，适用于长期变更。参见 命令。
工作流与命令
OPSX。 当前标准的 OpenSpec 工作流，围绕流畅的操作而非僵化的阶段构建。其斜杠命令均以 /opsx: 开头。参见 OPSX 工作流。
斜杠命令（Slash command）。 你在 AI 助手的聊天中输入的命令，例如 /opsx:propose。斜杠命令驱动工作流。它们不是终端命令。参见 命令如何工作。
探索（/opsx:explore）。 思考伙伴命令。它读取你的代码库，比较各种选项，将模糊的想法澄清为具体计划，不创建工件也不编写代码。当你遇到问题但尚无计划时，这是推荐的起点。参见 先探索。
CLI。 你在终端中运行的 openspec 程序。它用于设置项目、列出和验证变更、打开仪表板以及归档。这是 OpenSpec 的终端部分。参见 CLI。
技能（Skill）。 一个指令文件夹（.../skills/openspec-*/SKILL.md），你的 AI 助手会自动检测并遵循。技能是新兴的跨工具标准，用于向你的助手交付 OpenSpec 工作流。
命令文件（Command file）。 每个工具的斜杠命令文件（.../commands/opsx-*）。这是较早的交付机制，目前仍与技能并行支持。你很少直接操作这些文件。
配置集（Profile）。 项目中安装的斜杠命令集合。核心（Core）（默认）包括 propose、explore、apply、update、sync、archive。扩展（expanded） 集额外添加 new、continue、ff、verify、bulk-archive、onboard。使用 openspec config profile 进行更改。
交付方式（Delivery）。 OpenSpec 为你的工具安装技能、命令文件还是两者兼有。全局配置，通过 openspec update 应用。
自定义
模式（Schema）。 定义工作流包含哪些工件以及它们之间的依赖关系。内置默认值为 spec-driven（提案 → 规范 → 设计 → 任务）。你可以 fork 它或编写自己的模式。参见 自定义。
模板（Template）。 模式内部的 Markdown 文件，用于塑造 AI 为特定工件生成的内容。编辑模板会立即改变 AI 的输出，无需重新构建。
项目配置（openspec/config.yaml）。 每个项目的设置：默认模式、注入到每个规划请求中的 context:，以及每个工件的 rules:。这是让 OpenSpec 了解你的技术栈和约定最简单的方式。参见 自定义。
上下文注入（Context injection）。 将项目背景信息放入 config.yaml 的 context: 字段，使其自动添加到 AI 生成的每个工件中。这比指望 AI 去读取单独的文件更可靠。
依赖图（Dependency graph）。 由工件的 requires: 关系构成的有向图。它是一个 DAG（有向无环图：箭头只向前指向，绝不形成环路），OpenSpec 用它来判断你接下来可以创建什么。
赋能者，而非关卡（Enablers, not gates）。 这一原则表明，工件依赖关系展示的是接下来变得可能的事情，而非接下来必须做的事情。你可以在任何时间重新访问和编辑任何工件。参见 核心概念一览。
跨仓库协作（Beta）
这些术语仅适用于你的规划跨越多个仓库的情况。它们处于 Beta 阶段。大多数用户可以忽略它们。参见 Stores 用户指南。
存储库（Store）。 一个专门用于规划的独立仓库。它具有你已熟悉的 openspec/ 结构（规范和变更），外加一个小身份文件。你在机器上按名称注册一次，之后任何 OpenSpec 命令都可以从任何位置在其中工作。
引用（Reference）。 在代码仓库的 openspec/config.yaml 中声明的、该仓库所依赖的存储库。引用是只读的：仓库保留自己的根目录，openspec instructions 会获得所引用存储库规范的索引，每个规范附带获取它的精确命令。
工作上下文（Working context）。 openspec context 为当前仓库组装的内容：其 OpenSpec 根目录加上它引用的所有存储库，每个存储库附带获取方式。这是对"我在和什么一起工作？"的回答。
工作集（Workset）。 一组你一起打开的个人、机器本地文件夹（一个存储库与你正在工作的代码仓库并列）。通过 openspec workset create 显式创建；这些本地路径的任何信息都不会提交到共享的规划仓库中。