universal-dev-standards 5.0.0-rc.8 → 5.0.0

package/bundled/locales/zh-TW/core/testing-standards.md

@@ -1,17 +1,19 @@
 # 測試標準
 
-> **語言**: [English](../../../core/testing-standards.md) | 繁體中文
+> **Language**: [English](../../../core/testing-standards.md) | 繁體中文
 
-**版本**: 3.0.0
-**最後更新**: 2026-02-10
-**適用性**: 所有軟體專案
-**範圍**: 通用 (Universal)
+**版本**: 3.1.0
+**最後更新**: 2026-03-25
+**適用範圍**: 所有軟體專案
+**Scope**: universal
+**產業標準**: ISTQB CTFL v4.0, ISO/IEC/IEEE 29119
+**參考資料**: [istqb.org](https://istqb.org/)
 
 ---
 
 ## 目的
 
-本標準為 AI 代理和開發人員定義可執行的測試規則和慣例。關於理論基礎、教育內容和詳細範例，請參閱 **[測試理論知識庫](guides/testing-guide.md)**。
+本標準定義可操作的測試規則與慣例，供 AI 代理與開發人員使用。如需理論基礎、教育內容與詳細範例，請參閱 [測試理論知識庫](../../../skills/testing-guide/testing-theory.md)。
 
 **參考標準**:
 - [ISTQB CTFL v4.0](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
@@ -22,47 +24,84 @@
 
 ## 術語表
 
-| 縮寫 | 全稱 | 說明 |
+| 縮寫 | 全名 | 說明 |
 |------|------|------|
-| **UT** | 單元測試 (Unit Testing) | 隔離測試個別函式/方法 |
-| **IT** | 整合測試 (Integration Testing) | 測試元件之間的互動 |
-| **ST** | 系統測試 (System Testing) | 測試完整整合的系統 |
-| **AT** | 驗收測試 (Acceptance Testing) | 針對業務驗收標準進行測試 |
-| **E2E** | 端對端測試 (End-to-End Testing) | 測試完整的使用者工作流程 |
-| **UAT** | 使用者驗收測試 (User Acceptance Testing) | 由最終使用者執行的驗收測試 |
-| **SIT** | 系統整合測試 (System Integration Testing) | 測試多個系統的整合 |
+| **UT** | Unit Testing | 獨立測試個別函式/方法 |
+| **IT** | Integration Testing | 測試元件之間的互動 |
+| **ST** | System Testing | 測試完整的整合系統 |
+| **AT** | Acceptance Testing | 依據業務驗收標準進行測試 |
+| **E2E** | End-to-End Testing | 測試完整的使用者工作流程 |
+| **UAT** | User Acceptance Testing | 由終端使用者執行的驗收測試 |
+| **SIT** | System Integration Testing | 測試多個系統的整合 |
 
-> **注意**：本文件中的「IT」一律指「整合測試 (Integration Testing)」，而非「資訊科技 (Information Technology)」。
+> **注意**: 本文件中的 "IT" 一律指 "Integration Testing"（整合測試），而非 "Information Technology"（資訊科技）。
 
 ---
 
-## 測試金字塔 (預設比例)
+## 覆蓋率目標（主要指標）
 
-```
-              ┌─────────┐
-              │   E2E   │  ← 10% (較少，較慢，成本較高)
-             ─┴─────────┴─
-            ┌─────────────┐
-            │    IT/SIT   │  ← 20% (整合測試)
-           ─┴─────────────┴─
-          ┌─────────────────┐
-          │       UT        │  ← 70% (單元測試 - 基礎)
-          └─────────────────┘
-```
+> **Coverage is the primary metric for test quality.** Higher coverage means more code is protected by tests.
+> **覆蓋率是測試品質的主要指標。** 更高的覆蓋率代表更多程式碼受到測試保護。
+
+| 指標 | 最低要求 | 標準 | 理想 |
+|------|---------|------|------|
+| **行覆蓋率 (Line Coverage)** | 80% | 90% | 95%+ |
+| **分支覆蓋率 (Branch Coverage)** | 70% | 85% | 90%+ |
+| **函式覆蓋率 (Function Coverage)** | 85% | 95% | 100% |
+| **突變分數 (Mutation Score)** | — | 80% | 90%+（關鍵程式碼） |
+
+**層級定義：**
+- **最低要求**: 所有專案的基準線 — 低於此值即為品質風險
+- **標準**: 大多數專案的目標 — 透過紀律化的測試即可達成
+- **理想**: 關鍵系統與核心業務邏輯的目標 — 在可行的情況下追求 100%
+
+> **實務指引**: 100% 覆蓋率是理想目標。實務上，行覆蓋率達到 95% 以上時會出現邊際效益遞減。最後的 5% 應集中在關鍵路徑（認證、支付、資料完整性），而非自動產生的程式碼或簡單的 getter/setter。
+
+---
+
+## 覆蓋率與佔比 — 關鍵區別
+
+> **AI 代理與開發人員：請勿混淆這兩個概念。**
+
+| 概念 | 意義 | 重要性 |
+|------|------|--------|
+| **覆蓋率（Coverage）** | 測試所執行的程式碼百分比 | **主要指標** — 衡量保護程度 |
+| **佔比（Ratio）** | 各層級測試數量的分布 | 僅供參考 — 影響執行時間 |
+
+**覆蓋率**回答的問題是：「我的程式碼有多少被測試了？」
+**佔比**回答的問題是：「我的測試中，單元測試、整合測試、E2E 測試各佔多少比例？」
 
-| 層級 | 比例 | 執行時間目標 |
-|------|------|--------------|
-| 單元測試 (UT) | 70% | 總計 < 10 分鐘 |
-| 整合測試 (IT) | 20% | 總計 < 30 分鐘 |
-| E2E 測試 | 10% | 總計 < 2 小時 |
+---
+
+## 測試框架選擇
+
+| 框架 | 層級 | 最適用於 |
+|------|------|---------|
+| **ISTQB** | UT → IT/SIT → ST → AT/UAT | 企業級、法規遵循、正式 QA |
+| **業界金字塔** | UT → IT → ST → E2E | 敏捷、DevOps、CI/CD |
 
 ---
 
-## 測試層級需求
+## 測試金字塔（測試數量佔比 — 僅供參考）
+
+> **注意**: 以下為測試**數量**佔比（各層級有多少測試），而非覆蓋率目標。覆蓋率要求請參閱上方的[覆蓋率目標](#覆蓋率目標主要指標)。
+
+| 層級 | 測試數量佔比 | 執行時間目標 |
+|------|-------------|-------------|
+| 單元測試 (UT) | 約 70% 的測試 | < 10 分鐘 |
+| 整合測試 (IT) | 約 20% 的測試 | < 30 分鐘 |
+| 系統測試 (ST) | 約 7% 的測試 | < 1 小時 |
+| E2E 測試 | 約 3% 的測試 | < 2 小時 |
+
+> 70/20/7/3 的比例為經驗法則建議（Mike Cohn）。其目的在於最佳化回饋速度 — 大部分測試快速執行（UT），較少測試緩慢執行（E2E）。
+
+---
+
+## 測試層級要求
 
 ### 單元測試 (UT)
 
-**特性**: 隔離、快速 (< 100ms/個)、確定性
+**特性**: 隔離、快速（每個 < 100ms）、確定性
 
 #### 範圍
 
@@ -83,39 +122,35 @@
 [class_name]_test.[ext]     # Python, Go
 ```
 
-**方法命名** (每個專案擇一):
+**方法命名**（每個專案選擇一種）:
 
-| 風格 | 最適合 | 範例 |
-|------|--------|------|
+| 風格 | 最適用於 | 範例 |
+|------|---------|------|
 | `[Method]_[Scenario]_[Result]` | C#, Java | `CalculateTotal_NegativePrice_ThrowsException()` |
 | `should_[behavior]_when_[condition]` | JavaScript/TypeScript | `should_reject_login_when_account_locked()` |
 | `test_[method]_[scenario]_[expected]` | Python (pytest) | `test_validate_email_invalid_format_returns_false()` |
 
-#### 覆蓋率閾值
+#### 覆蓋率門檻
 
-| 指標 | 最低 | 推薦 |
-|------|------|------|
-| 行覆蓋率 (Line) | 70% | 85% |
-| 分支覆蓋率 (Branch) | 60% | 80% |
-| 函式覆蓋率 (Function) | 80% | 90% |
+> 請參閱本文件頂部的[覆蓋率目標](#覆蓋率目標主要指標)以取得權威的覆蓋率要求。
 
 ---
 
 ### 整合測試 (IT)
 
-**特性**: 元件整合、真實相依性 (通常容器化)、1-10 秒/個
+**特性**: 元件整合、真實相依性（通常容器化）、每個 1-10 秒
 
-#### 何時必須有整合測試
+#### 何時需要
 
-**決策規則**: 如果你的單元測試對查詢/過濾參數使用萬用匹配器 (`any()`, `It.IsAny<>`, `Arg.Any<>`)，該功能必須有整合測試。
+**決策規則**: 若您的單元測試使用萬用匹配器（`any()`、`It.IsAny<>`、`Arg.Any<>`）來處理查詢/過濾參數，該功能**必須**有整合測試。
 
 | 情境 | 原因 |
 |------|------|
 | 查詢述詞 | Mock 無法驗證過濾表達式 |
-| 實體關聯 | 驗證外鍵正確性 |
-| 複合主鍵 | 記憶體資料庫可能與真實 DB 不同 |
+| 實體關係 | 驗證外鍵正確性 |
+| 複合鍵 | 記憶體資料庫可能與真實資料庫不同 |
 | 欄位對應 | DTO ↔ Entity 轉換 |
-| 分頁 | 資料排序和計數 |
+| 分頁 | 列排序與計數 |
 | 交易 | 回滾行為 |
 
 #### 範圍
@@ -123,9 +158,11 @@
 | 包含 | 排除 |
 |------|------|
 | 資料庫 CRUD 操作 | 完整使用者工作流程 |
-| Repository + Database | 跨服務通訊 |
+| Repository + 資料庫 | 跨服務通訊 |
 | Service + Repository | UI 互動 |
 | API 端點 + Service 層 | |
+| 訊息佇列生產者/消費者 | |
+| 快取讀寫操作 | |
 
 #### 命名慣例
 
@@ -137,17 +174,54 @@
 
 ---
 
+### 系統測試 (ST)
+
+**特性**: 完整系統、類生產環境、基於需求
+
+#### 範圍
+
+| 包含 | 排除 |
+|------|------|
+| 完整 API 工作流程 | UI 視覺測試 |
+| 跨服務交易 | 使用者旅程模擬 |
+| 資料流經整個系統 | A/B 測試情境 |
+| 安全需求 | |
+| 負載下的效能 | |
+| 錯誤處理與復原 | |
+
+#### 類型
+
+| 類型 | 說明 |
+|------|------|
+| 功能性 | 驗證功能按規格運作 |
+| 效能 | 負載、壓力、可擴展性測試 |
+| 安全性 | 滲透測試、弱點掃描 |
+| 可靠性 | 故障轉移、復原、穩定性 |
+| 相容性 | 跨平台、瀏覽器相容性 |
+
+#### 命名慣例
+
+```
+[Feature]SystemTests.[ext]
+[Feature].system.test.[ext]
+[Feature]_st.[ext]
+```
+
+---
+
 ### 端對端測試 (E2E)
 
-**特性**: 使用者視角、全端 (UI → API → Database)、最慢 (30s+/個)
+**特性**: 使用者視角、全端（UI → API → 資料庫）、最慢（每個 30 秒以上）
 
 #### 範圍
 
 | 包含 | 排除 |
 |------|------|
-| 關鍵使用者旅程 | 每個可能的使用者路徑 |
-| 登入/驗證流程 | 邊緣案例 (使用 UT/IT) |
+| 關鍵使用者旅程 | 所有可能的使用者路徑 |
+| 登入/認證流程 | 邊界案例（使用 UT/IT） |
 | 核心業務交易 | 效能基準測試 |
+| 跨瀏覽器功能 | |
+| 部署的冒煙測試 | |
 
 #### 命名慣例
 
@@ -159,67 +233,108 @@ e2e/[feature]/[scenario].[ext]
 
 ---
 
-## 測試替身 (Test Doubles)
+## 測試替身
 
-| 類型 | 目的 | 何時使用 |
-|------|------|----------|
-| **Stub** | 回傳預定義值 | 固定的 API 回應 |
-| **Mock** | 驗證互動 | 驗證方法被呼叫 |
-| **Fake** | 簡化的實作 | 記憶體資料庫 |
-| **Spy** | 記錄呼叫 | 部分 Mock |
-| **Dummy** | 佔位符 | 填補必要參數 |
+| 類型 | 用途 | 使用時機 |
+|------|------|---------|
+| **Stub** | 回傳預定義的值 | 固定的 API 回應 |
+| **Mock** | 驗證互動行為 | 驗證方法是否被呼叫 |
+| **Fake** | 簡化實作 | 記憶體資料庫 |
+| **Spy** | 記錄呼叫，委派給真實物件 | 部分模擬 |
+| **Dummy** | 佔位符，不會被使用 | 填充必要參數 |
 
-### 依測試層級使用
+### 各測試層級的使用指引
 
 | 層級 | 指引 |
 |------|------|
-| **UT** | 對所有外部依賴使用 Mocks/Stubs |
-| **IT** | 資料庫使用 Fakes，外部 API 使用 Stubs |
-| **E2E** | 全部使用真實元件；僅外部支付/郵件使用 Stub |
+| **UT** | 對所有外部相依性使用 Mock/Stub |
+| **IT** | 資料庫使用 Fake，外部 API 使用 Stub |
+| **ST** | 使用真實元件，僅對外部第三方使用 Fake |
+| **E2E** | 使用全部真實元件；僅對外部支付/郵件使用 Stub |
 
 ---
 
-## Mock 限制
+## Mock 的限制
 
-**問題**: 萬用匹配器 (`any()`, `It.IsAny<>`) 會忽略實際查詢邏輯，允許錯誤的查詢通過。
+**問題**: 萬用匹配器（`any()`、`It.IsAny<>`）會忽略實際查詢邏輯，使不正確的查詢通過測試。
 
-**規則**: 如果 Mock 一個接受查詢/過濾/述詞參數的方法，你**必須**有對應的整合測試來驗證查詢邏輯。
+**規則**: 若模擬一個接受查詢/過濾/述詞參數的方法，你**必須**有對應的整合測試來驗證查詢邏輯。
 
 ```python
 # 範例 - Python
 # ❌ 此測試無法驗證查詢正確性
 mock_repo.find.return_value = users
 
-# ✓ 新增整合測試來驗證實際查詢
+# ✓ 新增整合測試以驗證實際查詢
 ```
 
 ---
 
-## 測試資料需求
+## 測試資料要求
 
-### 區分識別碼規則
+### 原則
 
-當實體同時具有代理鍵 (自動產生 ID) 和業務識別碼時，測試資料**必須**為兩者使用不同的值。
+1. **隔離**: 每個測試管理自己的資料
+2. **清理**: 測試結束後自行清理
+3. **確定性**: 測試不依賴共享狀態
+4. **可讀性**: 測試資料清楚表達意圖
+
+### 區別識別碼規則
+
+當實體同時擁有代理鍵（自動產生的 ID）和業務識別碼時，測試資料**必須**使用不同的值。
 
 ```python
-# ❌ 錯誤: id 等於 business_code - 對應錯誤無法偵測
+# ❌ 錯誤: id 等於 business_code - 映射錯誤無法被偵測
 dept = Department(id=1, business_code=1)
 
-# ✓ 正確: 區分值可捕捉對應錯誤
+# ✓ 正確: 不同的值可捕捉映射錯誤
 dept = Department(id=1, business_code=1001)
 ```
 
+### 複合鍵規則
+
+對於擁有複合主鍵的實體，確保每筆記錄有唯一的鍵組合。
+
+```python
+# ❌ 鍵衝突
+batch1 = BatchRecord(id=0, send_time=now)
+batch2 = BatchRecord(id=0, send_time=now)  # 衝突！
+
+# ✓ 唯一組合
+batch1 = BatchRecord(id=0, send_time=now + timedelta(seconds=1))
+batch2 = BatchRecord(id=0, send_time=now + timedelta(seconds=2))
+```
+
 ---
 
 ## 測試環境
 
-### 依測試層級的容器使用
+### 各語言工具
+
+| 語言 | 版本管理工具 | 鎖定檔案 |
+|------|-------------|---------|
+| Python | venv, virtualenv, poetry | requirements.txt, poetry.lock |
+| Node.js | nvm, fnm | package-lock.json, yarn.lock |
+| Ruby | rbenv, rvm | Gemfile.lock |
+| Java | SDKMAN, jenv | pom.xml, build.gradle.lock |
+| .NET | dotnet SDK | packages.lock.json |
+| Go | go mod | go.sum |
+| Rust | rustup, cargo | Cargo.lock |
+
+### 最佳實踐
+
+1. **始終使用虛擬環境**進行開發與測試
+2. **提交鎖定檔案**至版本控制
+3. **在 CI/CD 管線中固定版本**
+4. **在 README 或 .tool-versions 中記錄所需的執行環境版本**
+
+### 各測試層級的容器使用
 
 | 層級 | 容器使用 |
-|------|----------|
-| UT | 不需要 - 使用 mocks |
-| IT | Testcontainers 用於資料庫、快取 |
-| ST | Docker Compose 用於完整環境 |
+|------|---------|
+| UT | 不需要 - 使用 mock |
+| IT | 使用 Testcontainers 處理資料庫、快取 |
+| ST | 使用 Docker Compose 建立完整環境 |
 | E2E | 完整容器化堆疊 |
 
 ---
@@ -233,18 +348,116 @@ dept = Department(id=1, business_code=1001)
 | 單元測試 | 每次提交 | 10 分鐘 |
 | 整合測試 | 每次提交 | 30 分鐘 |
 | 系統測試 | PR 合併至 main | 2 小時 |
-| E2E 測試 | 發布候選版 | 4 小時 |
+| E2E 測試 | 發布候選版本 | 4 小時 |
+
+### 必要指標
+
+| 指標 | UT | IT | ST | E2E |
+|------|----|----|----|----|
+| 通過/失敗數 | 必要 | 必要 | 必要 | 必要 |
+| 執行時間 | 必要 | 必要 | 必要 | 必要 |
+| 覆蓋率 % | 必要 | 必要 | 選用 | 不需要 |
+| 不穩定測試率 | 必要 | 必要 | 必要 | 必要 |
+| 截圖/影片 | 不需要 | 不需要 | 選用 | 必要 |
+
+---
+
+## 最佳實踐
+
+### AAA 模式
+
+```
+// Arrange - 設置測試資料與環境
+// Act - 執行待測行為
+// Assert - 驗證結果
+```
+
+### FIRST 原則
+
+| 原則 | 說明 |
+|------|------|
+| **F**ast（快速） | 測試快速執行 |
+| **I**ndependent（獨立） | 測試之間互不影響 |
+| **R**epeatable（可重複） | 每次結果相同 |
+| **S**elf-validating（自我驗證） | 明確的通過/失敗 |
+| **T**imely（及時） | 與生產程式碼同時撰寫 |
+
+### 應避免的反模式
+
+- 測試相依性（測試必須按特定順序執行）
+- 不穩定測試（時而通過、時而失敗）
+- 測試實作細節（重構時測試就壞了）
+- 過度 Mock（沒有真正測試到任何東西）
+- 缺少斷言（測試沒有驗證有意義的內容）
+- 魔術數字/字串（無法解釋的值）
+- 相同的測試 ID（代理鍵與業務鍵使用相同值）
+
+---
+
+## 測試文件結構
+
+### tests/README.md 必要章節
+
+每個 `tests/` 目錄**應該**包含一個 README.md，內含：
+
+#### 1. 測試概覽表
+
+| 測試類型 | 數量 | 框架 | 環境 |
+|---------|------|------|------|
+| 單元測試 | 150 | Jest | Node.js |
+| 整合測試 | 45 | Jest | Node.js + TestContainers |
+| E2E 測試 | 12 | Playwright | Browser |
+
+#### 2. 目前狀態章節
+
+| 指標 | 值 | 目標 | 狀態 |
+|------|-----|------|------|
+| 通過率 | 98.5% | >= 95% | 通過 |
+| 行覆蓋率 | 82% | >= 80% | 通過 |
+| 分支覆蓋率 | 75% | >= 70% | 通過 |
+
+#### 3. 報告連結章節
+
+| 報告類型 | 位置 | 說明 |
+|---------|------|------|
+| 測試結果 | `results/` | 時間戳記的執行報告 |
+| 覆蓋率 | `coverage/` | 程式碼覆蓋率報告 |
+| 差距分析 | `docs/gap-analysis.md` | 缺失覆蓋率分析 |
+
+### 測試報告命名慣例
+
+| 項目 | 慣例 | 範例 |
+|------|------|------|
+| 報告檔名 | `test-report-YYYYMMDD-HHMMSS.md` | `test-report-20260129-143000.md` |
+| 報告目錄 | `tests/results/` | |
+| 覆蓋率目錄 | `tests/coverage/` | |
+
+### 目錄結構
+
+```
+tests/
+├── README.md                    # 測試概覽與狀態
+├── results/                     # 測試執行報告
+├── coverage/                    # 覆蓋率報告
+├── docs/                        # 測試文件
+├── unit/                        # 單元測試
+├── integration/                 # 整合測試
+└── e2e/                         # 端對端測試
+```
+
+---
 
 ---
 
 ## 相關標準
 
-- [測試理論知識庫](guides/testing-guide.md) - 教育內容、範例、技巧
+- [測試理論知識庫](../../../skills/testing-guide/testing-theory.md) - 教育內容、範例、技術
 - [測試驅動開發](test-driven-development.md) - TDD/BDD/ATDD 方法論
 - [測試完整性維度](test-completeness-dimensions.md) - 8 維度測試覆蓋
 - [規格驅動開發](spec-driven-development.md) - SDD 工作流程整合
 - [程式碼簽入標準](checkin-standards.md)
-- [程式碼審查清單](code-review-checklist.md)
+- [程式碼審查檢查清單](code-review-checklist.md)
+- [部署標準](deployment-standards.md) - 部署準備的測試要求
 
 ---
 
@@ -252,13 +465,23 @@ dept = Department(id=1, business_code=1001)
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
-| 3.0.0 | 2026-01-29 | **重大重構**：拆分為規則（本文件）和理論（testing-guide.md）。優化 AI 閱讀效率。 |
+| 3.1.0 | 2026-03-24 | **覆蓋率優先重構**: 將覆蓋率目標提升至首要位置，提高門檻（行 80/90/95+、分支 70/85/90+、函式 85/95/100），新增覆蓋率與佔比的區別，將測試金字塔降為僅供參考 |
+| 3.0.0 | 2026-01-29 | **重大重構**: 拆分為規則（本檔案）與理論（testing-theory.md）。從 141KB/3185 行縮減至約 12KB/350 行。所有教育內容移至 skills/testing-guide/testing-theory.md。純規則格式，針對 AI 代理消費最佳化。 |
 | 2.2.0 | 2026-01-20 | 新增測試文件結構章節 |
-| 2.1.0 | 2026-01-05 | 新增 SWEBOK v4.0 參考 |
-| 2.0.0 | 2026-01-05 | 根據 ISTQB CTFL v4.0 和 ISO/IEC/IEEE 29119 進行重大更新 |
+| 2.1.0 | 2026-01-05 | 新增 SWEBOK v4.0 參考、測試基礎知識、測試相關量測 |
+| 2.0.0 | 2026-01-05 | 重大更新，對齊 ISTQB CTFL v4.0 與 ISO/IEC/IEEE 29119 |
+| 1.3.0 | 2025-12-29 | 新增測試框架選擇、IT/SIT 縮寫說明 |
+| 1.2.0 | 2025-12-19 | 新增 Mock 限制、整合測試要求、測試資料模式 |
+| 1.1.1 | 2025-12-11 | 改善系統測試範例，使用通用領域概念 |
+| 1.1.0 | 2025-12-05 | 新增測試環境隔離章節 |
+| 1.0.0 | 2025-12-05 | 初始測試標準，包含 UT/IT/ST/E2E 覆蓋 |
 
 ---
 
 ## 授權
 
-本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 釋出。
+
+---
+
+**維護者**: 開發團隊

package/bundled/locales/zh-TW/core/verification-evidence.md

@@ -0,0 +1,94 @@
+---
+source: ../../../core/verification-evidence.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 驗證證據標準
+
+> **語言**: [English](../../../core/verification-evidence.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-20
+**適用性**: 所有 AI 輔助開發工作流
+**範圍**: 通用 (Universal)
+**靈感來源**: [Superpowers](https://github.com/obra/superpowers) — verification-before-completion (MIT)
+
+---
+
+## 目的
+
+建立「鐵律」：無驗證證據不可聲稱完成。防止 AI 代理虛構成功結果，確保每個完成聲明都有可執行的證據支持。
+
+---
+
+## 術語表
+
+| 術語 | 定義 |
+|------|------|
+| 驗證證據 (Verification Evidence) | 驗證指令執行及其結果的結構化記錄 |
+| 鐵律 (Iron Law) | 絕對規則：無證據 = 不可聲稱完成 |
+| RED-GREEN 循環 | 透過展示修復前測試失敗、修復後測試通過來證明 bug 修復 |
+| Exit Code | 指令的數值回傳值（0 = 成功、非零 = 失敗） |
+
+---
+
+## 鐵律
+
+> **無驗證證據 = 不可聲稱完成。**
+
+代理聲稱「已完成」不是證據。驗證必須是可獨立執行且產生可觀察輸出的。
+
+---
+
+## 證據格式
+
+每個完成聲明必須包含以下結構化證據：
+
+```markdown
+## 驗證證據
+
+**指令**: `npm test`
+**Exit Code**: 0
+**摘要**: 全部 42 個測試通過
+**時間戳**: 2026-03-24T10:30:00Z
+```
+
+## 證據類型
+
+| 類型 | 適用場景 | 範例 |
+|------|----------|------|
+| **測試結果** | 功能開發、bug 修復 | `npm test` 輸出 |
+| **建置成功** | 編譯、打包 | `npm run build` 的 exit code 0 |
+| **Lint 通過** | 程式碼品質 | `npm run lint` 無錯誤 |
+| **RED-GREEN** | bug 修復 | 修復前失敗 → 修復後通過 |
+| **手動驗證** | UI 變更、視覺效果 | 截圖或螢幕錄影 |
+
+## RED-GREEN 循環
+
+修復 bug 時的驗證流程：
+
+1. **RED** — 展示修復前測試失敗
+2. **修復** — 套用修復
+3. **GREEN** — 展示修復後測試通過
+4. **全套** — 執行完整測試套件確認無回歸
+
+## 禁止的完成聲明
+
+以下聲明**不構成**驗證證據：
+
+| 聲明 | 原因 |
+|------|------|
+| 「已完成」 | 無可觀察的輸出 |
+| 「應該可以了」 | 未執行驗證 |
+| 「我改了程式碼」 | 修改 ≠ 驗證 |
+| 「測試應該會通過」 | 預測 ≠ 事實 |
+
+## 相關標準
+
+- [系統化除錯](systematic-debugging.md)
+- [反幻覺標準](anti-hallucination.md)
+- [提交規範](checkin-standards.md)
+- [代理派遣與並行協調](agent-dispatch.md)