概念

本指南說明 OpenSpec 的核心理念及其相互關聯。如需實際應用，請參閱快速入門與工作流程。

設計哲學

OpenSpec 圍繞四大原則構建：

流動而非僵化         — 無階段閘門，專注於當下合理的工作
迭代而非瀑布式       — 邊建構邊學習，持續調整優化
簡易而非複雜         — 輕量設定，最少儀式感
既有系統優先         — 適用於現有程式碼庫，而非僅限全新開發

為何這些原則重要

流動而非僵化。 傳統規格將你鎖定在固定階段：先規劃，再實作，然後完成。OpenSpec 更具彈性——你可以按照對工作最合理的順序建立產出物。

迭代而非瀑布式。 需求會改變，理解會深化。起初看似良好的方案，在檢視程式碼庫後可能不再適用。OpenSpec 接納這一事實。

簡易而非複雜。 某些規格框架需要繁複設定、僵化格式或重量級流程。OpenSpec 不會阻礙你的工作。數秒內即可初始化，立即開始作業，僅在需要時才進行自訂。

既有系統優先。 多數軟體工作並非從零開始——而是修改現有系統。OpenSpec 的差異化方法能輕鬆規範對現有行為的變更，而非僅描述新系統。

整體概覽

OpenSpec 將您的工作組織成兩個主要領域：

┌────────────────────────────────────────────────────────────────────┐
│                        openspec/                                   │
│                                                                    │
│   ┌─────────────────────┐      ┌───────────────────────────────┐   │
│   │       specs/        │      │         changes/              │   │
│   │                     │      │                               │   │
│   │  事實來源            │◄─────│  提議的修改                   │   │
│   │  您的系統目前如何運作 │ 合併 │  每個變更 = 一個資料夾        │   │
│   │                     │      │  包含產出差異                 │   │
│   │                     │      │                               │   │
│   └─────────────────────┘      └───────────────────────────────┘   │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

規格 是事實來源 — 它們描述您的系統目前的行為方式。

變更 是提議的修改 — 它們存放在獨立的資料夾中，直到您準備好合併它們。

這種分離是關鍵。您可以並行處理多個變更而不會產生衝突。您可以在變更影響主要規格之前對其進行審查。當您歸檔一個變更時，其差異會乾淨地合併到事實來源中。

協調工作區

工作區支援正在積極開發中，目前尚未準備就緒供使用。請勿基於工作區行為構建外部自動化、整合或長期運行的工作流程；命令、狀態檔案和 JSON 輸出隨時可能變更。

以下命令提供了跨連結儲存庫或資料夾進行規劃的初始設定流程。

當單一儲存庫擁有規劃、實施和歸檔流程時，儲存庫本地的 OpenSpec 專案是合適的預設選擇。有些工作跨越多個儲存庫或資料夾。對於這種情況，OpenSpec 協調工作區是持久的規劃中心。

工作區的心智模型是：

workspace = 相關跨儲存庫變更所在的位置
link      = 工作區可以規劃的儲存庫或資料夾的穩定名稱
change    = 一個功能、修復、專案或其他計劃中的工作單元

工作區的結構與儲存庫本地專案不同：

workspace-folder/
├── changes/                       # 工作區層級的規劃
└── .openspec-workspace/
    ├── workspace.yaml             # 共享的工作區識別碼和連結名稱
    └── local.yaml                 # 此機器的本地路徑

儲存庫本地的 OpenSpec 狀態保持現有結構：

repo-root/
└── openspec/
    ├── specs/
    └── changes/

這個區別很重要。工作區資料夾是跨連結儲存庫或資料夾進行規劃的協調介面。每個儲存庫的 openspec/ 目錄仍然是儲存庫擁有的規格、儲存庫本地變更和實施規劃的主場所。使用者不需要在工作區資料夾內執行儲存庫本地的 openspec init。

穩定的連結名稱是工作區規劃引用儲存庫和資料夾的方式。共享的工作區狀態保存諸如 api、web 或 checkout 之類的名稱；每台機器在 .openspec-workspace/local.yaml 中將這些名稱映射到自己的本地路徑。

# .openspec-workspace/workspace.yaml
version: 1
name: platform
links:
  api: {}
  web: {}

# .openspec-workspace/local.yaml
version: 1
paths:
  api: /repos/api
  web: /repos/web

預設情況下，OpenSpec 建立的工作區將 .openspec-workspace/local.yaml 排除在可攜式協作狀態之外。.openspec-workspace/workspace.yaml 保持可攜式，因為它儲存的是工作區名稱和穩定的連結名稱，而不是某個使用者的絕對檢出路徑。

連結的路徑可以是完整的儲存庫、大型單一儲存庫內的資料夾，或其他現有資料夾。它們不需要先有儲存庫本地的 openspec/ 狀態才能參與工作區規劃。後續的實施、驗證或歸檔工作流程可能需要更多儲存庫準備，但規劃的可見性始於連結。

多儲存庫：
  api      -> /repos/api
  web      -> /repos/web

大型單一儲存庫：
  billing  -> /repos/platform/services/billing
  checkout -> /repos/platform/apps/checkout

受管理的工作區位於標準的 OpenSpec 資料目錄下：

getGlobalDataDir()/workspaces

這意味著當設定了 XDG_DATA_HOME 時為 $XDG_DATA_HOME/openspec/workspaces，在 Unix 風格的回退路徑下為 ~/.local/share/openspec/workspaces，在原生 Windows 回退路徑下為 %LOCALAPPDATA%\openspec\workspaces。原生 Windows Shell、PowerShell 和 WSL2 各自為運行 OpenSpec 的運行時保留路徑字串。此基礎不會在 D:\repo、/mnt/d/repo 和 UNC WSL 路徑之間進行轉換。

OpenSpec 還在以下位置維護一個機器本地的登錄檔：

getGlobalDataDir()/workspaces/registry.yaml

該登錄檔將工作區名稱映射到工作區位置，以便後續的全域命令可以從任何地方列出或選擇已知的工作區。它只是一個索引。每個工作區資料夾對其自己的 .openspec-workspace/workspace.yaml 和 .openspec-workspace/local.yaml 保持權威性，因此過時的登錄檔記錄可以被報告和修復，而無需重新定義工作區本身。

工作區的可見性不等於變更的承諾。當 OpenSpec 需要知道哪些儲存庫或資料夾相關時，設定一個工作區；當您準備好規劃一個功能、修復、專案或其他工作單元時，再建立一個變更。

有用的命令：

# 引導式設定
openspec workspace setup

# 適合自動化的設定
openspec workspace setup --no-interactive --name platform --link /repos/api --link web=/repos/web
openspec workspace setup --no-interactive --name platform --link /repos/api --opener codex

# 從本地登錄檔查看已知的工作區
openspec workspace list
openspec workspace ls

# 為選定的工作區新增或修復連結
openspec workspace link /repos/api
openspec workspace link api-service /repos/api
openspec workspace relink api-service /new/path/to/api

# 檢查此機器可以解析什麼
openspec workspace doctor
openspec workspace doctor --workspace platform

# 開啟連結的工作集
openspec workspace open
openspec workspace open platform --agent github-copilot
openspec workspace open --editor

workspace setup 總是在標準工作區位置建立工作區，將其記錄在本地登錄檔中，顯示工作區位置，並且至少需要一個連結的儲存庫或資料夾。互動式設定會詢問偏好的開啟器。非互動式設定僅在提供 --opener codex、--opener claude、--opener github-copilot 或 --opener editor 時才儲存一個。

OpenSpec 還維護根工作區開啟檔案：AGENTS.md 中由 OpenSpec 管理的引導區塊、用於 VS Code 和 GitHub Copilot-in-VS-Code 開啟的機器本地 <workspace-name>.code-workspace 檔案，以及針對該受維護的 .code-workspace 檔案的特定忽略條目。使用者編寫的 *.code-workspace 檔案仍然可追蹤，因為忽略規則僅針對受維護的檔案。

受維護的 VS Code 工作區將協調根目錄作為 .，並將有效的連結儲存庫或資料夾作為額外的根目錄。VS Code 將這些條目顯示為多根工作區。

workspace open 使用儲存的偏好的開啟器開啟連結的工作集，除非為該次會話傳遞了 --agent <tool> 或 --editor。同時傳遞兩個開啟器覆蓋項會導致錯誤。根工作區開啟使連結的儲存庫和資料夾對探索和規劃可見；實施在使用者明確要求實施工作後開始。

workspace link 和 workspace relink 僅記錄現有資料夾；它們不會建立、複製、移動、初始化或編輯連結的儲存庫或資料夾。成功連結或重新連結後，OpenSpec 會重新整理受管理的引導、VS Code 工作區檔案和忽略規則。

需要一個工作區的工作區命令可以從任何地方使用 --workspace <name> 運行。如果您在工作區資料夾或子目錄內運行它們，OpenSpec 會使用當前工作區。如果有多個已知工作區可用且您未傳遞 --workspace <name>，人類命令會顯示一個選擇器；--json 和 --no-interactive 會失敗並返回結構化的狀態錯誤，而不是提示。

直接的工作區命令支援用於腳本的 JSON 輸出。JSON 回應將主要資料保存在 workspace、workspaces 或 link 物件中，並在 status 陣列中報告警告或錯誤。正常的物件使用 status: []。

規格

規格使用結構化的需求和情境來描述您系統的行為。

結構

openspec/specs/
├── auth/
│   └── spec.md           # 認證行為
├── payments/
│   └── spec.md           # 支付處理
├── notifications/
│   └── spec.md           # 通知系統
└── ui/
    └── spec.md           # UI 行為和主題

按領域組織規格 — 對您的系統有意義的邏輯分組。常見模式：

• 按功能區域：auth/、payments/、search/
• 按元件：api/、frontend/、workers/
• 按限界上下文：ordering/、fulfillment/、inventory/

規格格式

一個規格包含需求，每個需求都有情境：

# 認證規格

目的

應用程式的驗證與工作階段管理。

需求

需求：使用者驗證

系統 SHALL 在成功登入後簽發一個 JWT 權杖。

情境：有效憑證

• 假設一個擁有有效憑證的使用者
• 當該使用者提交登入表單
• 那麼將返回一個 JWT 權杖
• 且使用者將被重新導向至儀表板

情境：無效憑證

• 假設無效的憑證
• 當使用者提交登入表單
• 那麼將顯示一條錯誤訊息
• 且不會簽發任何權杖

需求：工作階段過期

系統 MUST 在 30 分鐘無活動後使工作階段過期。

情境：閒置逾時

• 假設一個已驗證的工作階段
• 當 30 分鐘過去且無任何活動
• 那麼該工作階段將被無效化
• 且使用者必須重新驗證

**關鍵元素：**

| 元素 | 目的 |
|---------|---------|
| `## Purpose` | 此規格領域的高層次描述 |
| `### Requirement:` | 系統必須具備的特定行為 |
| `#### Scenario:` | 需求在實際應用中的具體範例 |
| SHALL/MUST/SHOULD | 表示需求強度的 RFC 2119 關鍵字 |

### 為何要以這種結構撰寫規格

**需求是「做什麼」** — 它們陳述系統應該做什麼，而不指定實作方式。

**情境是「何時做」** — 它們提供可以驗證的具體範例。好的情境：
- 是可測試的（你可以為其編寫自動化測試）
- 涵蓋正常路徑和邊界情況
- 使用 Given/When/Then 或類似的結構化格式

**RFC 2119 關鍵字**（SHALL、MUST、SHOULD、MAY）傳達意圖：
- **MUST/SHALL** — 絕對需求
- **SHOULD** — 建議，但存在例外
- **MAY** — 可選

### 規格是什麼（以及不是什麼）

規格是一份**行為契約**，而非實作計畫。

好的規格內容：
- 使用者或下游系統所依賴的可觀察行為
- 輸入、輸出和錯誤條件
- 外部約束（安全性、隱私、可靠性、相容性）
- 可以測試或明確驗證的情境

在規格中應避免：
- 內部類別/函式名稱
- 程式庫或框架選擇
- 逐步實作細節
- 詳細的執行計畫（這些應屬於 `design.md` 或 `tasks.md`）

快速檢驗：
- 如果實作可以在不改變外部可見行為的情況下變更，那麼它很可能不屬於規格。

### 保持輕量：漸進式嚴謹

OpenSpec 旨在避免官僚主義。使用足以使變更可驗證的最輕量級別。

**輕量規格（預設）：**
- 簡短、以行為為優先的需求
- 清晰的範圍和非目標
- 幾個具體的驗收檢查

**完整規格（用於較高風險）：**
- 跨團隊或跨儲存庫的變更
- API/契約變更、遷移、安全性/隱私疑慮
- 歧義可能導致昂貴重工的變更

大多數變更應保持在輕量模式。

### 人類 + 代理協作

在許多團隊中，人類進行探索，而代理起草文件。預期的循環是：

1. 人類提供意圖、上下文和約束。
2. 代理將其轉換為以行為為優先的需求和情境。
3. 代理將實作細節保留在 `design.md` 和 `tasks.md` 中，而非 `spec.md`。
4. 驗證確認結構和清晰度後才進行實作。

這使得規格對人類可讀，對代理保持一致性。

## 變更

變更是對您系統的建議修改，以資料夾形式封裝，包含理解與實作所需的一切。

### 變更結構

openspec/changes/add-dark-mode/ ├── proposal.md # 為何與什麼 ├── design.md # 如何（技術方案） ├── tasks.md # 實作檢查清單 ├── .openspec.yaml # 變更中繼資料（可選） └── specs/ # 增量規格 └── ui/ └── spec.md # ui/spec.md 中正在變更的內容

每個變更都是自包含的。它包含：
- **工件** — 記錄意圖、設計與任務的文件
- **增量規格** — 關於新增、修改或移除內容的規格說明
- **中繼資料** — 此特定變更的可選配置

### 為何變更是資料夾

將變更封裝為資料夾有幾個好處：

1. **所有內容集中。** 提案、設計、任務與規格都位於同一處。無需在不同位置搜尋。

2. **並行作業。** 多個變更可以同時存在而不衝突。可以在進行 `fix-auth-bug` 的同時處理 `add-dark-mode`。

3. **清晰的歷史記錄。** 歸檔時，變更會連同其完整上下文移至 `changes/archive/`。您可以回顧並理解不僅是變更了什麼，還有為何變更。

4. **易於審查。** 變更資料夾易於審查 — 打開它，閱讀提案，檢查設計，查看規格差異。

## 工件

工件是指引工作的變更內部文件。

### 工件流程

proposal ──────► specs ──────► design ──────► tasks ──────► implement │ │ │ │ why what how steps

• scope changes approach to take

工件相互構建。每個工件為下一個提供上下文。

### 工件類型

#### 提案 (`proposal.md`)

提案在較高層級捕捉**意圖**、**範圍**與**方法**。

```markdown
# 提案：新增深色模式

## 意圖
使用者要求新增深色模式選項，以減少夜間使用時的眼睛疲勞，
並符合系統偏好設定。

## 範圍
包含範圍：
- 設定中的主題切換
- 系統偏好偵測
- 在 localStorage 中儲存偏好

不包含範圍：
- 自訂顏色主題（未來工作）
- 逐頁主題覆寫

## 方法
使用 CSS 自訂屬性進行主題設定，並透過 React Context 進行狀態管理。
首次載入時偵測系統偏好，允許手動覆寫。

何時更新提案：

• 範圍變更（縮小或擴大）
• 意圖明確化（對問題有更好的理解）
• 方法根本性轉變

規格（specs/ 中的增量規格）

增量規格描述相對於當前規格的變更內容。請參閱下方的增量規格。

設計 (design.md)

設計捕捉技術方案與架構決策。

# 設計：新增深色模式

## 技術方案
透過 React Context 管理主題狀態，以避免 prop drilling。
CSS 自訂屬性實現運行時切換，無需切換類別。

## 架構決策

### 決策：使用 Context 而非 Redux
使用 React Context 管理主題狀態，因為：
- 狀態簡單（亮/暗）
- 無複雜狀態轉換
- 避免新增 Redux 依賴

### 決策：使用 CSS 自訂屬性
使用 CSS 變數而非 CSS-in-JS，因為：
- 與現有樣式表相容
- 無運行時開銷
- 瀏覽器原生解決方案

## 資料流
```
ThemeProvider (context)
       │
       ▼
ThemeToggle ◄──► localStorage
       │
       ▼
CSS Variables (applied to :root)
```

## 檔案變更
- `src/contexts/ThemeContext.tsx` (新增)
- `src/components/ThemeToggle.tsx` (新增)
- `src/styles/globals.css` (修改)

何時更新設計：

• 實作顯示方案不可行
• 發現更好的解決方案
• 依賴或約束條件變更

任務 (tasks.md)

任務是實作檢查清單 — 帶有核取方塊的具體步驟。

# 任務

## 1. 主題基礎設施
- [ ] 1.1 建立具有亮/暗狀態的 ThemeContext
- [ ] 1.2 為顏色新增 CSS 自訂屬性
- [ ] 1.3 實作 localStorage 持久化
- [ ] 1.4 新增系統偏好偵測

## 2. UI 元件
- [ ] 2.1 建立 ThemeToggle 元件
- [ ] 2.2 在設定頁面新增切換開關
- [ ] 2.3 更新標頭以包含快速切換

## 3. 樣式
- [ ] 3.1 定義深色主題調色盤
- [ ] 3.2 更新元件以使用 CSS 變數
- [ ] 3.3 測試對比度以確保無障礙性

任務最佳實踐：

• 將相關任務分組在標題下
• 使用層級編號（1.1、1.2 等）
• 保持任務小到可在一個工作階段內完成
• 完成任務時勾選它們

增量規格

增量規格是使 OpenSpec 適用於既有系統開發的關鍵概念。它們描述變更內容，而非重述整個規格。

格式

# 認證的增量規格

## 新增需求

### 需求：雙因素認證
系統必須支援基於 TOTP 的雙因素認證。

#### 情境：2FA 登記
- 假設一個未啟用 2FA 的使用者
- 當使用者在設定中啟用 2FA
- 則顯示 QR 碼供驗證器應用程式設定
- 且使用者必須在啟用前使用驗證碼驗證

#### 情境：2FA 登入
- 假設一個已啟用 2FA 的使用者
- 當使用者提交有效憑證
- 則呈現 OTP 挑戰
- 且僅在有效 OTP 後完成登入

## 修改需求

### 需求：工作階段過期
系統必須在 15 分鐘不活動後使工作階段過期。
（先前：30 分鐘）

#### 情境：閒置逾時
- 假設一個已驗證的工作階段
- 當 15 分鐘過去而無活動
- 則工作階段被無效化

## 移除需求

### 需求：記住我
（已棄用，改用 2FA。使用者應在每個工作階段重新驗證。）

增量章節

章節	含義	歸檔時發生什麼
## 新增需求	新行為	附加到主規格
## 修改需求	變更行為	替換現有需求
## 移除需求	棄用行為	從主規格中刪除

為何使用增量而非完整規格

清晰性。 增量精確顯示變更內容。閱讀完整規格時，您需要在心中與當前版本進行差異比較。

避免衝突。 兩個變更可以觸及同一規格檔案而不衝突，只要它們修改不同的需求。

審查效率。 審查者看到的是變更，而非未變更的上下文。專注於重要的事情。

適合既有系統。 大多數工作修改現有行為。增量使修改成為一等公民，而非事後考慮。

架構

架構定義了工作流程中的製品類型及其相依性。

架構運作方式

# openspec/schemas/spec-driven/schema.yaml
name: spec-driven
artifacts:
  - id: proposal
    generates: proposal.md
    requires: []              # 無相依性，可優先建立

  - id: specs
    generates: specs/**/*.md
    requires: [proposal]      # 需要提案後才能建立

  - id: design
    generates: design.md
    requires: [proposal]      # 可與規格並行建立

  - id: tasks
    generates: tasks.md
    requires: [specs, design] # 需要規格與設計皆完成

製品構成一個相依關係圖：

                    提案
                   (根節點)
                       │
         ┌─────────────┴─────────────┐
         │                           │
         ▼                           ▼
      規格                         設計
   (相依於:                     (相依於:
    提案)                       提案)
         │                           │
         └─────────────┬─────────────┘
                       │
                       ▼
                    任務
                (相依於:
                規格, 設計)

相依性是促成條件，而非關卡。 它們顯示了可以建立什麼，而非接下來必須建立什麼。如果不需要設計，可以跳過它。您可以在設計之前或之後建立規格——兩者都只相依於提案。

內建架構

spec-driven（預設）

規格驅動開發的標準工作流程：

提案 → 規格 → 設計 → 任務 → 實作

適用於：大多數希望在實作前就規格達成共識的功能開發。

自訂架構

為您的團隊工作流程建立自訂架構：

# 從頭建立
openspec schema init research-first

# 或複製現有架構
openspec schema fork spec-driven research-first

自訂架構範例：

# openspec/schemas/research-first/schema.yaml
name: research-first
artifacts:
  - id: research
    generates: research.md
    requires: []           # 先進行研究

  - id: proposal
    generates: proposal.md
    requires: [research]   # 提案基於研究結果

  - id: tasks
    generates: tasks.md
    requires: [proposal]   # 跳過規格/設計，直接進入任務

建立與使用自訂架構的完整細節，請參閱自訂。

歸檔

歸檔透過將變更的差異規格合併至主規格中，並為歷史記錄保留該變更，從而完成一次變更。

歸檔時發生什麼

歸檔前：

openspec/
├── specs/
│   └── auth/
│       └── spec.md ◄────────────────┐
└── changes/                         │
    └── add-2fa/                     │
        ├── proposal.md              │
        ├── design.md                │ 合併
        ├── tasks.md                 │
        └── specs/                   │
            └── auth/                │
                └── spec.md ─────────┘


歸檔後：

openspec/
├── specs/
│   └── auth/
│       └── spec.md        # 現已包含 2FA 需求
└── changes/
    └── archive/
        └── 2025-01-24-add-2fa/    # 為歷史記錄保留
            ├── proposal.md
            ├── design.md
            ├── tasks.md
            └── specs/
                └── auth/
                    └── spec.md

歸檔流程

1. 合併差異。 每個差異規格區段（新增/修改/移除）都會套用到對應的主規格。
2. 移至歸檔。 變更資料夾移至 changes/archive/，並加上日期前綴以便按時間排序。
3. 保留上下文。 所有製品在歸檔中保持完整。您隨時可以回顧以了解變更的原因。

歸檔為何重要

乾淨的狀態。 進行中的變更 (changes/) 僅顯示進行中的工作。已完成的工作會移出視線。

稽核軌跡。 歸檔保留了每個變更的完整上下文——不僅是變更了什麼，還有解釋原因的提案、解釋方法的設計，以及顯示已完成工作的任務。

規格演進。 隨著變更被歸檔，規格會有機地成長。每次歸檔都會合併其差異，隨著時間建立起全面的規格。

整體如何運作

┌──────────────────────────────────────────────────────────────────────────────┐
│                              OPENSPEC 流程                                   │
│                                                                              │
│   ┌────────────────┐                                                         │
│   │  1. 開始       │  /opsx:propose (核心) 或 /opsx:new (擴展)               │
│   │     變更       │                                                         │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  2. 建立       │  /opsx:ff 或 /opsx:continue (擴展工作流程)              │
│   │     製品       │  建立提案 → 規格 → 設計 → 任務                           │
│   │                │  (基於架構相依性)                                        │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  3. 實作       │  /opsx:apply                                            │
│   │     任務       │  依序完成任務，並勾選完成                                │
│   │                │◄──── 隨著學習更新製品                                    │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  4. 驗證       │  /opsx:verify (可選)                                    │
│   │     工作       │  檢查實作是否符合規格                                    │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐     ┌──────────────────────────────────────────────┐    │
│   │  5. 歸檔       │────►│  差異規格合併至主規格                         │    │
│   │     變更       │     │  變更資料夾移至歸檔/                          │    │
│   └────────────────┘     │  規格現為更新後的事實來源                     │    │
│                          └──────────────────────────────────────────────┘    │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

良性循環：

1. 規格描述當前行為
2. 變更提出修改（作為差異）
3. 實作使變更成真
4. 歸檔將差異合併至規格
5. 規格現在描述新的行為
6. 下次變更基於更新後的規格

術語表

術語	定義
製品	變更中的一份文件（提案、設計、任務或差異規格）
歸檔	完成變更並將其差異合併至主規格的過程
變更	對系統提出的一項修改，打包為一個包含製品的資料夾
差異規格	描述相對於當前規格的變更（新增/修改/移除）的規格
領域	規格的邏輯分組（例如 auth/、payments/）
需求	系統必須具備的特定行為
情境	需求的具體範例，通常採用 Given/When/Then 格式
架構	製品類型及其相依性的定義
規格	描述系統行為的規範，包含需求和情境
事實來源	openspec/specs/ 目錄，包含當前已達成共識的行為

下一步

• 入門指南 - 實用的第一步
• 工作流程 - 常見模式及適用時機
• 指令 - 完整指令參考
• 自訂 - 建立自訂架構並配置您的專案