詞彙表
所有 OpenSpec 術語都集中在一處，以平實的語言定義。快速瀏覽一次，其餘文件就能讀得更快。
術語按主題分組，並在每組內按字母順序排列。
核心名詞
規格（Spec）。 描述系統部分行為的文件。規格存放於 openspec/specs/，依領域組織，由需求與場景組成。規格是「這個軟體做什麼？」的共識答案。參見概念。
真相來源（Source of truth）。 整體的 openspec/specs/ 目錄，保存系統目前公認的行為。變更提案對其提出編輯；歸檔則套用這些編輯。
變更（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）。 專案中安裝的斜線指令集合。核心（預設）為 propose、explore、apply、update、sync、archive。擴充集合加入 new、continue、ff、verify、bulk-archive、onboard。使用 openspec config profile 變更。
交付方式（Delivery）。 OpenSpec 是否為你的工具安裝技能、指令檔案或兩者。全域設定，使用 openspec update 套用。
自訂
結構（Schema）。 定義工作流程有哪些工件以及它們彼此依賴的方式。內建預設為 spec-driven（提案 → 規格 → 設計 → 任務）。你可以分岔或自行撰寫。參見自訂。
範本（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）。 此原則表示工件依賴顯示的是接下來可能成為什麼，而非必須成為什麼。你可以隨時重新檢視和編輯任何工件。參見核心概念一覽。
跨倉庫協調（測試版）
這些術語僅適用於你的規劃跨越多個倉庫的情況。它們處於測試階段。多數使用者可忽略。參見倉庫使用者指南。
倉庫（Store）。 一個獨立倉庫，其全部工作就是規劃。它擁有你熟悉的相同 openspec/ 結構（規格和變更），外加一個小型身分檔案。你在機器上以名稱註冊一次，之後任何 OpenSpec 指令都可以從任何地方對其操作。
參考（Reference）。 在程式碼倉庫的 openspec/config.yaml 中，對某個倉庫的宣告，該倉庫可從中引用。參考是唯讀的：倉庫保留自己的根目錄，openspec instructions 會增加被參考倉庫規格的索引，每個規格附有確切的取得指令。
工作上下文（Working context）。 openspec context 為目前倉庫組合的內容：其 OpenSpec 根目錄加上它所參考的每個倉庫，各自附有如何取得的方式。這是「我目前正在與什麼一起工作？」的答案。
工作集（Workset）。 你共同開啟的個人、僅限本機的資料夾集合（一個倉庫，以及你處理的程式碼倉庫）。使用 openspec workset create 明確建立；這些本機路徑不會提交到共享的規劃倉庫。