universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/locales/zh-TW/core/reverse-engineering-standards.md

@@ -367,10 +367,10 @@ Feature: 購物車
 
 ### 技能參考
 
-- [反向工程技能](../../../skills/claude-code/reverse-engineer/SKILL.md) - 詳細工作流程實作
-- [規格驅動開發技能](../../../skills/claude-code/spec-driven-dev/SKILL.md) - SDD 整合
-- [BDD 助手技能](../../../skills/claude-code/bdd-assistant/SKILL.md) - Gherkin 撰寫
-- [TDD 助手技能](../../../skills/claude-code/tdd-assistant/SKILL.md) - 測試覆蓋分析
+- [反向工程技能](../../../skills/reverse-engineer/SKILL.md) - 詳細工作流程實作
+- [規格驅動開發技能](../../../skills/spec-driven-dev/SKILL.md) - SDD 整合
+- [BDD 助手技能](../../../skills/bdd-assistant/SKILL.md) - Gherkin 撰寫
+- [TDD 助手技能](../../../skills/tdd-assistant/SKILL.md) - 測試覆蓋分析
 
 ---
 
@@ -378,9 +378,9 @@ Feature: 購物車
 
 - [反幻覺指南](anti-hallucination.md) - 基於證據的分析要求
 - [規格驅動開發](spec-driven-development.md) - 規格工作流程
-- [行為驅動開發](behavior-driven-development.md) - Given-When-Then 情境
+- [行為驅動開發](../../../core/behavior-driven-development.md) - Given-When-Then 情境
 - [測試驅動開發](test-driven-development.md) - 紅-綠-重構循環
-- [驗收測試驅動開發](acceptance-test-driven-development.md) - 驗收條件
+- [驗收測試驅動開發](../../../core/acceptance-test-driven-development.md) - 驗收條件
 - [程式碼審查清單](code-review-checklist.md) - 審查指南
 
 ---

package/bundled/locales/zh-TW/core/spec-driven-development.md

@@ -1,288 +1,37 @@
----
-source: ../../../core/spec-driven-development.md
-source_version: 1.3.0
-translation_version: 1.3.0
-last_synced: 2026-01-19
-status: current
----
-
 # 規格驅動開發 (SDD) 標準
 
-**版本**: 1.3.0
-**最後更新**: 2026-01-19
-**適用範圍**: 所有採用規格驅動開發的專案
-
-> **語言**: [English](../../../core/spec-driven-development.md) | [繁體中文](../locales/zh-TW/core/spec-driven-development.md)
-
----
-
-## 目的
-
-本標準定義規格驅動開發 (SDD) 的原則與工作流程，確保變更在實作前已經過規劃、記錄並透過規格核准。
-
-**主要效益**:
-- 減少利害關係人與開發者之間的溝通誤解
-- 為所有變更提供清晰的審計軌跡
-- 新成員更容易上手
-
----
-
-## SDD 工作流程
-
-```
-┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│     提案     │───▶│     審查     │───▶│     實作     │
-└──────────────┘    └──────────────┘    └──────────────┘
-                                               │
-                                               ▼
-                    ┌──────────────┐    ┌──────────────┐
-                    │     歸檔     │◀───│     驗證     │
-                    └──────────────┘    └──────────────┘
-```
-
-### 工作流程階段
-
-| 階段 | 說明 | 產出物 |
-|------|------|--------|
-| **提案** | 定義變更內容與原因 | `proposal.md` |
-| **審查** | 利害關係人核准 | 審查意見、核准紀錄 |
-| **實作** | 執行已核准的規格 | 程式碼、測試、文件 |
-| **驗證** | 確認實作符合規格 | 測試結果、審查 |
-| **歸檔** | 關閉並歸檔規格 | 已歸檔的規格與 commits/PRs 連結 |
-
----
-
-## 核心原則
-
-### 1. SDD 工具命令優先
-
-**規則**: 當專案整合了 SDD 工具（如 OpenSpec, Spec Kit 等）且該工具提供特定命令（例如 `/openspec` 或 `/spec` 等斜線命令）時，AI 助手**必須優先使用這些命令**，而非直接手動編輯檔案。
-
-**理由**:
-- **一致性**: 工具確保規格結構遵循嚴格的架構。
-- **可追溯性**: 命令通常會自動處理日誌、ID 和連結。
-- **安全性**: 工具可能有內建驗證以防止無效狀態。
+> **語言**: [English](../../../core/spec-driven-development.md) | 繁體中文
 
-**範例**:
-- ✅ 使用 `/openspec proposal "新增登入"` 取代手動建立 `changes/add-login/proposal.md`。
+**版本**: 1.2.0
+**最後更新**: 2025-12-30
+**適用性**: 所有採用規格驅動開發的專案
+**範圍**: 通用 (Universal)
 
 ---
 
-### 2. 方法論優於工具
-
-**規則**: SDD 是一種方法論，不綁定於單一工具。雖然 OpenSpec 是常見的實作，但本標準適用於任何 SDD 工具（例如 Spec Kit）。
-
-**指引**:
-- **通用流程**: 提案 -> 審查 -> 實作 -> 驗證 -> 歸檔。
-- **工具適應**: 適應工作區中啟用之 SDD 工具的特定命令與模式。
-
----
-
-### 3. 先規格，後程式碼
-
-**規則**: 在沒有經核准的規格或變更提案的情況下，不得進行功能性的程式碼變更。
-
-**例外情況**:
-- 關鍵熱修復（立即恢復服務，隨後補文件）。
-- 瑣碎變更（錯字、註解、格式調整）。
-
----
-
-## 規格文件範本
-
-### 提案範本
-
-```markdown
-# [SPEC-ID] 功能標題
-
 ## 摘要
-簡述提議的變更。
-
-## 動機
-為何需要此變更？解決什麼問題？
-
-## 詳細設計
-技術方法、影響的元件、資料流程。
-
-## 驗收條件
-- [ ] 條件 1
-- [ ] 條件 2
-
-## 相依性
-列出對其他規格或外部系統的相依性。
-
-## 風險
-潛在風險及緩解策略。
-```
-
----
-
-## 與其他標準整合
 
-### 與 Commit 訊息指南整合
+規格驅動開發 (SDD) 是一種「文件優先」的開發方法論，強調在編寫任何程式碼之前，先定義清晰、結構化的規格（Specification）。這種方法特別適合 AI 輔助開發，因為高品質的規格能顯著降低 AI 的幻覺並提高程式碼生成的準確度。
 
-實作已核准的規格時，在 commit 訊息中引用規格 ID：
-
-```
-feat(auth): implement login feature
-
-Implements SPEC-001 login functionality with OAuth2 support.
-
-Refs: SPEC-001
-```
-
-### 與簽入標準整合
-
-在為規格簽入程式碼前：
-
-1. ✅ 規格已核准
-2. ✅ 實作符合規格
-3. ✅ 測試涵蓋驗收條件
-4. ✅ PR 中引用規格 ID
-
-### 與程式碼審查清單整合
-
-審查者應驗證：
-
-- [ ] 變更符合已核准的規格
-- [ ] 無超出規格範圍的變更
-- [ ] 規格驗收條件已達成
+SDD 的核心流程：**規格提案 → 規格審查 → 實作 → 驗證 → 歸檔**。
 
 ---
 
-## 常見 SDD 工具
-
-| 工具 | 說明 | 命令範例 |
-|------|------|----------|
-| **OpenSpec** | 規格管理 | `/openspec proposal`, `/openspec approve` |
-| **Spec Kit** | 輕量級規格追蹤 | `/spec create`, `/spec close` |
-| **手動** | 無工具，基於檔案 | 手動建立 `specs/SPEC-XXX.md` |
+**完整指南: [SDD 指南](../methodologies/guides/sdd-guide.md)**
 
 ---
 
-## 最佳實踐
-
-### 應該做的
-
-- ✅ 保持規格專注且原子化（每個規格一個變更）
-- ✅ 包含明確的驗收條件
-- ✅ 將規格連結到實作 PR
-- ✅ 完成後歸檔規格
-
-### 不應該做的
-
-- ❌ 在規格核准前開始編碼
-- ❌ 實作期間修改範圍而不更新規格
-- ❌ 讓規格處於懸而未決狀態（始終關閉或歸檔）
-- ❌ 跳過驗證步驟
-
----
-
-## 與反向工程整合
-
-### 概述
-
-對於沒有規格的現有程式碼庫，使用[反向工程標準](reverse-engineering-standards.md)來生成與 SDD 相容的提案草稿。
-
-### 反向工程 → SDD 流水線
-
-```
-┌─────────────────────────────────────────────────────────────────────────┐
-│                    反向工程 → SDD 流水線                                  │
-├─────────────────────────────────────────────────────────────────────────┤
-│                                                                         │
-│   現有程式碼                                                             │
-│        │                                                                │
-│        ▼                                                                │
-│   ┌────────────────────────────────────────────────────────────┐       │
-│   │ /reverse-spec                                               │       │
-│   │   • 程式碼掃描 → 技術清單 [已確認]                            │       │
-│   │   • 測試分析 → 驗收條件 [已確認/推論]                         │       │
-│   │   • 缺口識別 → [未知] 項目                                   │       │
-│   └────────────────────────────────────────────────────────────┘       │
-│        │                                                                │
-│        ▼                                                                │
-│   草擬規格（反向工程）                                                   │
-│        │                                                                │
-│        ▼                                                                │
-│   ┌────────────────────────────────────────────────────────────┐       │
-│   │ SDD 審查流程                                                 │       │
-│   │   • 人類填寫 [未知] 區塊（動機、風險）                         │       │
-│   │   • 利害關係人驗證 [推論] 項目                                │       │
-│   │   • 正式核准                                                 │       │
-│   └────────────────────────────────────────────────────────────┘       │
-│        │                                                                │
-│        ▼                                                                │
-│   已核准規格 → 繼續正常 SDD 工作流程                                     │
-│                                                                         │
-└─────────────────────────────────────────────────────────────────────────┘
-```
+## 快速參考
 
-### 反向工程規格的要求
-
-當規格透過反向工程生成時：
-
-1. **標記狀態**：在元資料中包含 `狀態: 草稿（反向工程）`
-2. **填寫未知**：所有 `[未知]` 區塊必須由人類在核准前填寫
-3. **驗證推論**：所有 `[推論]` 項目必須經過審查和確認
-4. **標準審查**：在實作前遵循正常 SDD 審查流程
-5. **來源引用**：維護 file:line 參考以確保可追溯性
-
-### 何時使用反向工程
-
-| 情境 | 做法 |
+| 面向 | 說明 |
 |------|------|
-| 舊系統現代化 | 從反向工程開始 |
-| 記錄未文件化的程式碼 | 從程式碼生成規格 |
-| 新成員入職 | 提取規格進行知識轉移 |
-| 重構前的文件化 | 在重大變更前建立規格 |
-
-### 相關命令
-
-| 命令 | 用途 |
-|------|------|
-| `/reverse-spec` | 從現有程式碼生成 SDD 規格 |
-| `/reverse-bdd` | 將驗收條件轉換為 Gherkin 情境 |
-| `/reverse-tdd` | 分析 BDD 情境的測試覆蓋 |
-
----
+| **核心原則** | 先規格，後實作 (Spec First) |
+| **主要產物** | Markdown 規格文件 (`docs/specs/`) |
+| **參與者** | 架構師、開發者、AI 助手 |
+| **驗證方式** | 規格審查、正向推演 (Forward Derivation) |
 
 ## 相關標準
 
-- [反向工程標準](reverse-engineering-standards.md) - 程式碼轉規格轉換
-- [測試驅動開發](test-driven-development.md) - TDD 工作流程與 SDD 整合
-- [行為驅動開發](behavior-driven-development.md) - BDD 工作流程與 Given-When-Then 情境
-- [驗收測試驅動開發](acceptance-test-driven-development.md) - ATDD 工作流程與商業驗收
-- [測試標準](testing-standards.md) - 測試框架與最佳實踐（或使用 `/testing-guide` 技能）
-- [測試完整性維度](test-completeness-dimensions.md) - 7 維度測試覆蓋
-- [Commit 訊息指南](../../../core/commit-message-guide.md) - Commit 訊息規範
-- [程式碼簽入標準](../../../core/checkin-standards.md) - 程式碼簽入標準
-- [程式碼審查清單](../../../core/code-review-checklist.md) - 程式碼審查清單
-- [文件結構標準](../../../core/documentation-structure.md) - 文件結構標準
-
----
-
-## 版本歷史
-
-| 版本 | 日期 | 變更內容 |
-|------|------|----------|
-| 1.3.0 | 2026-01-19 | 新增：與反向工程整合章節、相關命令 |
-| 1.2.0 | 2026-01-05 | 新增：IEEE 830-1998 和 SWEBOK v4.0 第 1 章（軟體需求）至參考資料 |
-| 1.1.0 | 2025-12-24 | 新增：工作流程圖、規格範本、整合指南、最佳實踐、相關標準、授權 |
-| 1.0.0 | 2025-12-23 | 初始 SDD 標準定義 |
-
----
-
-## 參考資料
-
-- [OpenSpec Documentation](https://github.com/openspec)
-- [Design Documents Best Practices](https://www.industrialempathy.com/posts/design-docs-at-google/)
-- [ADR (Architecture Decision Records)](https://adr.github.io/)
-- [IEEE 830-1998 - 軟體需求規格](https://standards.ieee.org/ieee/830/1222/) - 需求文件標準
-- [SWEBOK v4.0 - 第 1 章：軟體需求](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society
-
----
-
-## 授權
-
-本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
+- [測試驅動開發](test-driven-development.md)
+- [反向工程標準](reverse-engineering-standards.md)
+- [正向推演標準](forward-derivation-standards.md)

package/bundled/locales/zh-TW/core/test-completeness-dimensions.md

@@ -1,15 +1,15 @@
 ---
 source: ../../../core/test-completeness-dimensions.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2025-12-30
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-01-24
 status: current
 ---
 
 # 測試完整性維度
 
-**版本**: 1.0.0
-**最後更新**: 2025-12-24
+**版本**: 1.1.0
+**最後更新**: 2026-01-24
 **適用範圍**: 所有需要測試的軟體專案
 
 [English](../../../core/test-completeness-dimensions.md) | [繁體中文](.)
@@ -22,13 +22,13 @@ status: current
 
 ---
 
-## 七個維度
+## 八個維度
 
-完整的測試套件應為每個功能涵蓋以下 7 個維度：
+完整的測試套件應為每個功能涵蓋以下 8 個維度：
 
 ```
 ┌─────────────────────────────────────────────────────────────┐
-│                    測試完整性 = 7 個維度                      │
+│                    測試完整性 = 8 個維度                      │
 ├─────────────────────────────────────────────────────────────┤
 │  1. 正向路徑          正常預期行為                            │
 │  2. 邊界條件          最小/最大值、限制                       │
@@ -37,6 +37,7 @@ status: current
 │  5. 狀態轉換          前後驗證                                │
 │  6. 驗證邏輯          格式、業務規則                          │
 │  7. 整合驗證          實際查詢驗證                            │
+│  8. AI 生成品質       AI 生成測試品質（新增）                  │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -415,6 +416,94 @@ public async Task GetActiveUsers_RealDatabase_ReturnsOnlyActiveUsers()
 
 ---
 
+### 8. AI 測試生成品質
+
+評估 AI 生成測試的品質與有效性。
+
+**為何重要**:
+
+AI 程式碼助手可以快速生成測試，但數量 ≠ 品質。此維度確保 AI 生成的測試提供真正的價值。
+
+**品質評估標準**:
+
+| 標準 | 品質不佳 | 品質良好 |
+|------|---------|---------|
+| **測試目的** | 測試明顯的 getter/setter | 測試業務邏輯和邊界案例 |
+| **斷言深度** | 只有 `result != null` | 驗證具體的值和狀態 |
+| **獨立性** | 測試依賴執行順序 | 每個測試自成一體 |
+| **命名** | `test1`, `test2` | 描述性: `should_reject_invalid_email` |
+
+**AI 測試生成檢核清單**:
+
+```
+□ 測試目的驗證
+  □ 測試是否驗證有意義的行為？
+  □ bug 會導致測試失敗嗎？
+
+□ 斷言品質
+  □ 斷言是否具體（不只是「非空」）？
+  □ 斷言是否驗證預期的輸出值？
+
+□ 測試獨立性
+  □ 測試可以任意順序執行嗎？
+  □ 每個測試都設定自己的資料嗎？
+
+□ 變異分數
+  □ 程式碼中的變異會被捕捉嗎？
+  □ 邏輯變更時測試會失敗嗎？
+```
+
+---
+
+## 變異測試
+
+### 概述
+
+變異測試透過在程式碼中引入小變更（變異）來驗證測試有效性，並檢查測試是否能捕捉它們。
+
+```
+原始程式碼    變異        變異後程式碼
+──────────  ──────►    ──────────
+if (x > 0)             if (x >= 0)  ← 變異
+
+           執行測試
+           ──────────►
+
+測試失敗？ → 變異被殺死 ✅ (測試有效)
+測試通過？ → 變異存活 ❌ (測試薄弱)
+
+變異分數 = 被殺死的變異 / 總變異數
+```
+
+### 常見變異運算子
+
+| 運算子 | 原始 | 變異後 | 測試應捕捉 |
+|--------|------|--------|-----------|
+| 邊界 | `>` | `>=` | 差一錯誤 |
+| 否定 | `true` | `false` | 布林邏輯 |
+| 算術 | `+` | `-` | 數學運算 |
+| 回傳 | `return x` | `return null` | 回傳值使用 |
+
+### 變異測試工具
+
+| 語言 | 工具 | 連結 |
+|------|------|------|
+| Java | PIT | https://pitest.org/ |
+| JavaScript/TypeScript | Stryker | https://stryker-mutator.io/ |
+| C# | Stryker.NET | https://stryker-mutator.io/docs/stryker-net/ |
+| Python | mutmut | https://github.com/boxed/mutmut |
+
+### 解讀結果
+
+| 變異分數 | 解讀 | 行動 |
+|----------|------|------|
+| > 90% | 優秀 | 維持此水準 |
+| 80-90% | 良好 | 檢視存活的變異 |
+| 60-80% | 尚可 | 新增缺少的測試案例 |
+| < 60% | 不佳 | 有重大測試缺口 |
+
+---
+
 ## 測試案例設計清單
 
 使用此清單檢核每個功能的完整性：
@@ -462,6 +551,12 @@ public async Task GetActiveUsers_RealDatabase_ReturnsOnlyActiveUsers()
   □ 實體關聯已驗證
   □ 分頁已驗證
   □ 排序/篩選已驗證
+
+□ AI 生成品質（如果是 AI 生成）
+  □ 測試驗證有意義的行為
+  □ 斷言具體（不只是「非空」）
+  □ 變異分數 > 80%
+  □ 邊界案例已涵蓋
 ```
 
 ---
@@ -489,12 +584,14 @@ public async Task GetActiveUsers_RealDatabase_ReturnsOnlyActiveUsers()
 
 | 功能類型 | 必需維度 |
 |---------|---------|
-| CRUD API | 1, 2, 3, 4, 6, 7 |
-| 查詢/搜尋 | 1, 2, 3, 4, 7 |
-| 狀態機 | 1, 3, 4, 5, 6 |
-| 驗證 | 1, 2, 3, 6 |
-| 背景工作 | 1, 3, 5 |
-| 外部整合 | 1, 3, 7 |
+| CRUD API | 1, 2, 3, 4, 6, 7, 8* |
+| 查詢/搜尋 | 1, 2, 3, 4, 7, 8* |
+| 狀態機 | 1, 3, 4, 5, 6, 8* |
+| 驗證 | 1, 2, 3, 6, 8* |
+| 背景工作 | 1, 3, 5, 8* |
+| 外部整合 | 1, 3, 7, 8* |
+
+*維度 8（AI 生成品質）在測試為 AI 生成時適用
 
 ---
 
@@ -514,6 +611,12 @@ public async Task GetActiveUsers_RealDatabase_ReturnsOnlyActiveUsers()
 ❌ 測試資料的 ID 與業務識別碼使用相同值
 
 ❌ 測試實作細節而非行為
+
+❌ 未審查就接受 AI 生成的測試
+
+❌ 假設高行覆蓋率等於有效測試
+
+❌ 對關鍵程式碼跳過變異測試
 ```
 
 ---
@@ -527,10 +630,21 @@ public async Task GetActiveUsers_RealDatabase_ReturnsOnlyActiveUsers()
 
 ---
 
+## 參考資料
+
+- [ISTQB AI 測試大綱](https://www.istqb.org/certifications/ai-testing) - 基礎級 AI 測試認證
+- [Stryker 變異測試](https://stryker-mutator.io/) - 多語言變異測試框架
+- [PIT 變異測試](https://pitest.org/) - Java 變異測試
+- [Google 測試部落格 - 變異測試](https://testing.googleblog.com/2021/04/mutation-testing.html) - Google 對變異測試的觀點
+- [ISTQB 基礎級大綱](https://www.istqb.org/certifications/certified-tester-foundation-level) - 核心測試概念
+
+---
+
 ## 版本歷史
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| 1.1.0 | 2026-01-24 | 新增：第 8 維度（AI 測試生成品質）、變異測試章節 |
 | 1.0.0 | 2025-12-24 | 初始發布，包含 7 維度框架 |
 
 ---