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

package/bundled/locales/zh-TW/core/pipeline-integration-standards.md

@@ -0,0 +1,238 @@
+---
+source: ../../../core/pipeline-integration-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-18
+status: current
+---
+
+# Pipeline 整合標準
+
+> **語言**: [English](../../../core/pipeline-integration-standards.md) | 繁體中文
+
+**適用範圍**: 所有使用自動化開發 Pipeline 的軟體專案
+**Scope**: universal
+
+---
+
+## 概述
+
+Pipeline 整合標準定義自動化開發 Pipeline 應如何讀取專案設定、執行開發階段，以及根據專案情境調整行為。本標準為 AI 輔助及 CI/CD 驅動的開發工作流程提供一套與語言、框架無關的通用模型。
+
+## 參考資料
+
+| 標準／來源 | 內容 |
+|-----------|------|
+| ISO/IEC 12207 | 軟體生命週期流程 |
+| ISO/IEC 15504 (SPICE) | 流程評估 |
+| Continuous Delivery（Jez Humble） | Pipeline 設計原則 |
+| DORA Metrics | 部署頻率、前置時間、MTTR、變更失敗率 |
+
+---
+
+## 設定契約
+
+### UDS 設定區塊
+
+使用自動化 Pipeline 的專案必須在標準設定區塊中宣告其 Pipeline 偏好。設定區塊通常放置於專案的 manifest 檔案中（例如 `manifest.json`、`uds.config.json` 或等效檔案）。
+
+### 標準開關名稱
+
+| 開關 | 型別 | 預設值 | 描述 |
+|------|------|--------|------|
+| `autoSpecGeneration` | boolean | false | 自動從 PRD／使用者故事產生 SDD 規格 |
+| `autoDerive` | boolean | false | 規格核准後自動衍生 BDD／TDD／ATDD |
+| `autoTDD` | boolean | false | 衍生完成後自動進入 TDD RED 階段 |
+| `autoCheckin` | boolean | false | 所有品質關卡通過後自動提交 |
+| `autoBatch` | boolean | false | 自動批次累積待提交的變更 |
+
+### 開關語意
+
+每個開關控制特定的 Pipeline 行為：
+
+| 開關 | 開啟時 | 關閉時 |
+|------|--------|--------|
+| `autoSpecGeneration` | Pipeline 從輸入產生規格草稿並提交審查 | 需手動建立規格 |
+| `autoDerive` | 規格核准後 Pipeline 自動執行衍生（BDD／TDD／ATDD） | 透過指令手動衍生 |
+| `autoTDD` | 衍生完成後 Pipeline 設定 RED 狀態並建立測試骨架 | 開發者手動進入 TDD |
+| `autoCheckin` | 所有關卡通過（測試、lint、覆蓋率）後 Pipeline 自動提交 | 開發者手動提交 |
+| `autoBatch` | Pipeline 累積變更並在達到閾值時合併 | 每次變更個別提交 |
+
+### 設定範例
+
+```json
+{
+  "pipeline": {
+    "autoSpecGeneration": true,
+    "autoDerive": true,
+    "autoTDD": true,
+    "autoCheckin": false,
+    "autoBatch": false,
+    "context": "greenfield"
+  }
+}
+```
+
+### 設定讀取規則
+
+1. **安全預設值**：所有開關預設為 OFF（手動模式）
+2. **明確宣告**：Pipeline 必須在讀取設定後才能確定開關狀態，不得假設
+3. **執行期覆寫**：CLI flag 或環境變數可覆寫檔案式設定
+4. **驗證**：Pipeline 在執行前必須驗證設定值
+
+---
+
+## Pipeline 階段模型
+
+### 標準六階段 Pipeline
+
+```
+┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
+│  1.PLAN  │───▶│  2.SPEC  │───▶│ 3.DERIVE │───▶│ 4.BUILD  │───▶│ 5.REVIEW │───▶│6.CHECKIN │
+│ 需求分析  │    │ 規格撰寫  │    │ 測試衍生  │    │ 實作建置  │    │ 審查驗證  │    │ 提交簽入  │
+└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
+```
+
+### 階段定義
+
+| 階段 | 輸入 | 輸出 | 品質關卡 |
+|------|------|------|---------|
+| **Plan（規劃）** | PRD、使用者故事、需求 | 結構化需求文件 | 需求已審查 |
+| **Spec（規格）** | 需求 | 含驗收條件的 SDD 規格 | 規格已核准 |
+| **Derive（衍生）** | 已核准的規格 | BDD 情境、TDD 骨架、ATDD 表格 | 1:1 驗收條件對應已驗證 |
+| **Build（建置）** | 測試骨架 ＋ 規格 | 實作程式碼 | 測試通過（RED→GREEN） |
+| **Review（審查）** | 實作 ＋ 測試 | 審查意見 | 審查已核准 |
+| **Checkin（簽入）** | 已核准的變更 | 已提交的程式碼 | 所有品質關卡通過 |
+
+### 階段相依性
+
+- 每個階段的輸出為下一階段的輸入
+- 未經明確設定不得跳過任何階段
+- 品質關卡失敗必須阻擋進入下一階段
+
+---
+
+## 開發情境分類
+
+### 情境類型
+
+| 情境 | 描述 | 典型場景 |
+|------|------|---------|
+| **Greenfield** | 全新專案或功能，無既有程式碼 | 新增模組、新服務、新產品 |
+| **Brownfield** | 需修改的既有程式碼庫 | 為舊有程式碼新增功能、重構 |
+| **Adhoc** | 小型、獨立的變更 | Bug 修復、設定變更、Hotfix |
+
+### 情境策略矩陣
+
+| 階段 | Greenfield | Brownfield | Adhoc |
+|------|-----------|------------|-------|
+| **Plan** | 完整需求分析 | 優先進行影響分析 | 快速評估 |
+| **Spec** | 完整 SDD | Delta SDD（僅變更部分） | 可選（重大變更才需要） |
+| **Derive** | 完整衍生 | 針對性衍生 | 跳過（除非複雜） |
+| **Build** | 從零開始 TDD | 修改既有程式碼 ＋ 新測試 | 直接修復 |
+| **Review** | 完整審查 | 聚焦於變更的審查 | 快速審查 |
+| **Checkin** | 標準簽入 | 標準簽入 | 標準簽入 |
+
+### 情境自動偵測啟發式規則
+
+Pipeline 應使用下列訊號自動偵測情境：
+
+| 訊號 | Greenfield 指標 | Brownfield 指標 | Adhoc 指標 |
+|------|----------------|----------------|-----------|
+| 檔案數量 | 無檔案或極少檔案 | 已建立的程式碼庫 | 不適用 |
+| 變更範圍 | 新目錄／模組 | 修改既有檔案 | 變更 1–3 個檔案 |
+| 測試覆蓋率 | 無既有測試 | 既有測試套件 | 既有測試已涵蓋該區域 |
+| 規格是否存在 | 無規格 | 既有規格 | 可能有也可能沒有 |
+
+### 情境覆寫
+
+開發者可在設定中明確指定情境：
+
+```json
+{
+  "pipeline": {
+    "context": "brownfield"
+  }
+}
+```
+
+或透過 CLI flag 指定：
+```bash
+pipeline run --context=greenfield
+```
+
+---
+
+## 整合驗證
+
+### Pipeline 實作者檢查清單
+
+實作本標準的整合者必須驗證以下項目：
+
+| 檢查項目 | 要求 | 驗證方式 |
+|---------|------|---------|
+| 設定讀取 | Pipeline 從設定中讀取所有開關 | 單元測試：模擬設定 → 驗證行為 |
+| 預設值處理 | 未設定的開關預設為 OFF | 單元測試：空設定 → 手動模式 |
+| 階段執行 | 6 個階段依序執行 | 整合測試：完整 Pipeline 執行 |
+| 關卡強制執行 | 失敗的關卡阻擋下一階段 | 整合測試：注入失敗 → 驗證阻擋 |
+| 情境感知 | Pipeline 根據情境類型調整 | 整合測試：各情境 → 驗證階段 |
+| 覆寫支援 | CLI flag 覆寫檔案設定 | 單元測試：檔案 ＋ flag → flag 優先 |
+
+### 驗證規則
+
+1. **設定 Schema 驗證**：對照已知開關名稱進行驗證；對未知鍵值發出警告
+2. **開關型別安全**：所有開關必須為 boolean；拒絕非 boolean 值
+3. **情境列舉值**：情境必須為以下其中之一：`greenfield`、`brownfield`、`adhoc`
+4. **階段完整性**：Pipeline 必須回報哪些階段已執行、哪些已跳過
+
+---
+
+## 反模式
+
+| 反模式 | 影響 | 正確做法 |
+|--------|------|---------|
+| 硬編碼 Pipeline 行為 | 無法適應專案需求 | 在執行期讀取設定 |
+| 忽略情境類型 | 執行錯誤的階段 | 偵測或讀取情境設定 |
+| 跳過品質關卡 | 有問題的程式碼進入程式碼庫 | 在每個階段強制執行關卡 |
+| 全有或全無的自動化 | 使用者完全迴避 Pipeline | 允許逐開關的細粒度控制 |
+| 靜默跳過階段 | 失去可追蹤性 | 記錄並回報所有跳過決策 |
+
+---
+
+## 最佳實踐
+
+### 應做事項
+
+- ✅ 在執行任何階段前先讀取設定
+- ✅ 所有開關預設為 OFF（安全預設值）
+- ✅ 在 Pipeline 啟動時記錄哪些開關為啟用狀態
+- ✅ 回報階段執行狀態（已執行／已跳過／失敗）
+- ✅ 允許逐階段的細粒度開關控制
+- ✅ 在使用前驗證設定 Schema
+- ✅ 支援透過 CLI 覆寫設定
+
+### 不應做事項
+
+- ❌ 未讀取設定即假設開關狀態
+- ❌ 靜默跳過階段而不記錄
+- ❌ 忽略品質關卡失敗
+- ❌ 硬編碼 Pipeline 行為
+- ❌ 混用情境策略（例如：Greenfield 規格 ＋ Adhoc 建置）
+
+---
+
+## 相關標準
+
+- [規格驅動開發（Spec-Driven Development）](spec-driven-development.md) — Spec 階段工作流程
+- [正向衍生標準（Forward Derivation Standards）](forward-derivation-standards.md) — Derive 階段實作
+- [簽入標準（Check-in Standards）](checkin-standards.md) — Checkin 階段品質關卡
+- [變更批次標準（Change Batching Standards）](change-batching-standards.md) — 簽入前的批次合併
+- [驗收條件追蹤（Acceptance Criteria Traceability）](acceptance-criteria-traceability.md) — 跨階段驗收條件追蹤
+
+---
+
+## 版本歷程
+
+| 版本 | 日期 | 變更內容 |
+|------|------|---------|
+| 1.0.0 | 2026-03-18 | 初始版本 — 設定契約、六階段 Pipeline 模型、情境分類 |

package/bundled/locales/zh-TW/core/project-context-memory.md

@@ -0,0 +1,79 @@
+---
+source: ../../../core/project-context-memory.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 專案情境記憶標準
+
+> **語言**: [English](../../../core/project-context-memory.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-03-16
+**適用性**: 所有使用 AI 助手的軟體專案
+**範圍**: uds-specific
+
+---
+
+## 目的
+
+本標準定義一個結構化系統，用於擷取、檢索和強制執行**專案特定**的情境、架構決策和領域知識。不同於開發者記憶（通用且可轉移），專案情境記憶作為特定程式碼庫的「長期大腦」，確保 AI 助手遵守本地慣例和歷史決策。
+
+---
+
+## 快速參考
+
+### 記憶項目結構
+
+| 欄位 | 類型 | 說明 |
+|------|------|------|
+| `id` | string | 唯一識別碼（`PRJ-YYYY-NNNN`） |
+| `type` | enum | `decision` / `convention` / `structure` / `glossary` |
+| `summary` | string | 一句話摘要 |
+| `status` | enum | `active` / `proposed` / `deprecated` |
+| `scope` | list | 適用的檔案或目錄 |
+
+### 儲存位置
+
+項目以 **Markdown + YAML Frontmatter** 格式儲存，確保人類可讀（文件）和機器可解析。
+
+- **目錄**: `.project-context/`
+- **格式**: `.md` 檔案
+
+## 記憶類型
+
+| 類型 | 說明 | 範例 |
+|------|------|------|
+| `decision` | 架構或技術決策 | 「使用 PostgreSQL 而非 MongoDB」 |
+| `convention` | 程式碼慣例 | 「API 回應必須使用 camelCase」 |
+| `structure` | 專案結構規則 | 「測試檔案與原始碼平行放置」 |
+| `glossary` | 領域術語定義 | 「'tenant' 指多租戶的獨立實例」 |
+
+## 記憶生命週期
+
+```
+proposed → active → deprecated
+```
+
+| 狀態 | 說明 |
+|------|------|
+| `proposed` | 新提出但尚未團隊確認的項目 |
+| `active` | 已確認且必須遵守的項目 |
+| `deprecated` | 已過時但保留供歷史參考 |
+
+## AI 助手行為
+
+當 AI 助手在專案中工作時：
+
+1. **載入** — 在工作階段開始時讀取 `.project-context/` 中的所有 `active` 項目
+2. **遵守** — 所有建議和程式碼生成必須符合活躍的記憶項目
+3. **提議** — 發現新的隱含慣例時，建議建立新的記憶項目
+4. **衝突** — 如果使用者請求與活躍記憶衝突，必須提醒使用者
+
+## 相關標準
+
+- [情境感知載入](context-aware-loading.md)
+- [反幻覺標準](anti-hallucination.md)
+- [AI 協議標準](ai-agreement-standards.md)

package/bundled/locales/zh-TW/core/requirement-engineering.md

@@ -0,0 +1,79 @@
+---
+source: ../../../core/requirement-engineering.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 需求工程標準
+
+> **語言**: [English](../../../core/requirement-engineering.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-01-28
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
+**業界標準**: IEEE 830-1998、IEEE 29148-2018、SWEBOK v4.0
+**參考**: [computer.org](https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4)
+
+---
+
+## 摘要
+
+需求工程是在整個開發生命週期中系統性地引出、分析、規格化和驗證軟體需求的過程。它提供撰寫、管理和驗證需求的理論基礎，基於業界標準包括 IEEE 830-1998、IEEE 29148-2018、SWEBOK v4.0 和 ISO/IEC 25010。
+
+此過程涵蓋功能需求（系統應做什麼）、非功能需求（效能、安全、可用性等品質屬性）和約束條件。使用者故事（Agile 格式）搭配驗收條件（Given-When-Then）作為主要規格格式，透過 INVEST 準則驗證。
+
+---
+
+**完整指南：[需求工程指南](../../../methodologies/guides/requirement-engineering-guide.md)**
+
+---
+
+## 快速參考
+
+| 面向 | 說明 |
+|------|------|
+| **核心流程** | 引出 → 分析 → 規格化 → 驗證 |
+| **需求類型** | 功能需求 (FR)、非功能需求 (NFR)、約束條件 |
+| **優先級排序** | MoSCoW、P0-P3、Kano 模型 |
+| **品質模型** | ISO/IEC 25010（8 個特徵） |
+| **標準** | IEEE 830、IEEE 29148、SWEBOK v4.0 |
+
+## 使用者故事格式
+
+```
+作為 [角色]
+我希望 [功能]
+以便 [商業價值]
+```
+
+### INVEST 準則
+
+| 準則 | 說明 |
+|------|------|
+| **I**ndependent | 獨立 — 故事之間盡量獨立 |
+| **N**egotiable | 可協商 — 細節可以討論調整 |
+| **V**aluable | 有價值 — 對使用者或業務有價值 |
+| **E**stimable | 可估算 — 可以估算工作量 |
+| **S**mall | 小型 — 可在一個迭代內完成 |
+| **T**estable | 可測試 — 可以撰寫驗收條件 |
+
+## 需求優先級
+
+### MoSCoW 方法
+
+| 分類 | 說明 |
+|------|------|
+| **Must have** | 必要 — 沒有就無法發布 |
+| **Should have** | 應有 — 重要但可以延後 |
+| **Could have** | 可有 — 增值但非必要 |
+| **Won't have** | 不做 — 此版本明確排除 |
+
+## 相關標準
+
+- [規格驅動開發](spec-driven-development.md)
+- [正向推導標準](forward-derivation-standards.md)
+- [行為驅動開發](behavior-driven-development.md)
+- [測試標準](testing-standards.md)

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

@@ -0,0 +1,74 @@
+---
+source: ../../../core/security-standards.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 安全標準
+
+> **語言**: [English](../../../core/security-standards.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-01-29
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
+**業界標準**: OWASP Top 10 (2021)、OWASP ASVS v4.0、NIST SP 800-53
+**參考**: [owasp.org](https://owasp.org/Top10/)
+
+> **詳細說明與範例，請參閱 [安全指南](../../../core/guides/security-guide.md)**
+
+---
+
+## 目的
+
+本標準定義軟體開發的完整安全指南，涵蓋安全程式設計實踐、弱點預防、認證/授權和安全測試。
+
+**參考標準**：
+- [OWASP Top 10 (2021)](https://owasp.org/Top10/)
+- [OWASP ASVS v4.0](https://owasp.org/www-project-application-security-verification-standard/)
+- [NIST SP 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+
+---
+
+## 核心安全原則
+
+| 原則 | 實作 |
+|------|------|
+| **最小權限** | 基於角色的存取控制、限時 token |
+| **安全失敗** | 認證錯誤時拒絕存取、不暴露堆疊追蹤 |
+| **職責分離** | 開發/部署/管理使用不同角色 |
+| **縱深防禦** | 不依賴單一控制措施 |
+| **預設安全** | 安全預設值、明確選擇較不安全的選項 |
+| **零信任** | 驗證每個請求、假設已被入侵 |
+
+## OWASP Top 10 預防清單
+
+| # | 風險 | 預防措施 |
+|---|------|----------|
+| A01 | 權限控制失效 | RBAC、最小權限、伺服器端驗證 |
+| A02 | 加密失敗 | TLS 1.2+、AES-256、安全金鑰管理 |
+| A03 | 注入攻擊 | 參數化查詢、輸入驗證、ORM |
+| A04 | 不安全設計 | 威脅模型、安全設計審查 |
+| A05 | 安全設定錯誤 | 安全預設值、最小化安裝 |
+| A06 | 易受攻擊的元件 | 依賴掃描、定期更新 |
+| A07 | 認證失敗 | MFA、密碼策略、會話管理 |
+| A08 | 資料完整性失敗 | 數位簽章、CI/CD 管線安全 |
+| A09 | 記錄與監控不足 | 集中式日誌、告警、SIEM |
+| A10 | SSRF | 白名單、網路分區、輸入驗證 |
+
+## 安全測試
+
+| 測試類型 | 工具 | 頻率 |
+|----------|------|------|
+| SAST（靜態分析） | SonarQube、Semgrep | 每次提交 |
+| DAST（動態分析） | OWASP ZAP、Burp Suite | 每次發布 |
+| SCA（軟體組成分析） | Snyk、npm audit | 每日 |
+| 滲透測試 | 手動/自動化 | 每季 |
+
+## 相關標準
+
+- [部署標準](deployment-standards.md)
+- [效能標準](performance-standards.md)
+- [測試標準](testing-standards.md)

package/bundled/locales/zh-TW/core/systematic-debugging.md

@@ -0,0 +1,95 @@
+---
+source: ../../../core/systematic-debugging.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 系統化除錯工作流程
+
+> **語言**: [English](../../../core/systematic-debugging.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-20
+**適用性**: 所有使用 AI 輔助開發的軟體專案
+**範圍**: 通用 (Universal)
+**靈感來源**: [Superpowers](https://github.com/obra/superpowers) — systematic-debugging (MIT)
+
+---
+
+## 目的
+
+定義結構化的四階段除錯工作流，防止常見的「猜測修復」反模式。強制要求在嘗試修復前先進行根因分析，並包含 **3-Strike Rule** 以提早發現架構問題。
+
+---
+
+## 術語表
+
+| 術語 | 定義 |
+|------|------|
+| 根因 (Root Cause) | 缺陷存在的根本原因，而非僅僅是表徵 |
+| 3-Strike Rule | 連續 3 次修復嘗試失敗後，懷疑存在架構問題 |
+| 反向追蹤 (Backward Tracing) | 從錯誤表徵追溯到源頭 |
+| 元件邊界 (Component Boundary) | 兩個模組或子系統之間的介面 |
+
+---
+
+## 核心原則 — 鐵律
+
+> **禁止跳過根因分析直接修復。**
+
+如果你發現自己在說「快速修復」、「試試看」或「應該可以了」— **停下來**，回到第一階段。
+
+---
+
+## 四階段除錯工作流
+
+### 階段 1：觀察與重現
+
+| 步驟 | 說明 |
+|------|------|
+| 收集錯誤資訊 | 錯誤訊息、堆疊追蹤、日誌 |
+| 確定重現步驟 | 建立可靠的重現路徑 |
+| 記錄環境條件 | 作業系統、版本、設定 |
+
+### 階段 2：根因分析
+
+| 技術 | 適用場景 |
+|------|----------|
+| 反向追蹤 | 從錯誤點向後追溯資料流 |
+| 二分法 | 快速縮小問題範圍 |
+| 元件隔離 | 逐一排除元件 |
+| 日誌分析 | 檢查事件順序和狀態變化 |
+
+### 階段 3：修復
+
+| 規則 | 說明 |
+|------|------|
+| 先寫測試 | 寫一個重現 bug 的失敗測試 |
+| 最小化修改 | 只修改必要的程式碼 |
+| 驗證修復 | 確認測試從紅轉綠 |
+| 無副作用 | 確認沒有引入新的 bug |
+
+### 階段 4：驗證與預防
+
+| 步驟 | 說明 |
+|------|------|
+| 執行完整測試套件 | 確保沒有回歸 |
+| 更新文件 | 記錄根因和修復方案 |
+| 回顧 | 是否需要加強預防措施 |
+
+## 3-Strike Rule
+
+連續 3 次修復嘗試失敗時：
+
+1. **停止修復** — 不要再嘗試第 4 次
+2. **升級** — 通知架構師或資深開發人員
+3. **重新分析** — 從更高層次重新分析問題
+4. **考慮重構** — 問題可能在架構層面
+
+## 相關標準
+
+- [驗證證據](verification-evidence.md)
+- [測試標準](testing-standards.md)
+- [AI 模型選擇策略](model-selection.md)

package/bundled/locales/zh-TW/core/test-governance.md

@@ -0,0 +1,88 @@
+---
+source: ../../../core/test-governance.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 測試治理標準
+
+> **語言**: [English](../../../core/test-governance.md) | 繁體中文
+
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
+
+---
+
+## 概述
+
+測試治理標準定義測試活動的政策、完成準則和環境管理策略。本標準橋接 ISO/IEC/IEEE 29119 正式流程與 Agile/Scrum 實踐。
+
+## 參考
+
+| 標準/來源 | 內容 |
+|-----------|------|
+| ISO/IEC/IEEE 29119-2 | 測試流程 |
+| ISO/IEC/IEEE 29119-3 | 測試文件（測試計劃/測試案例） |
+| ISO/IEC/IEEE 12207 | 驗證流程 + 整合流程 |
+| Agile/Scrum 指南 | 完成定義 (DoD) |
+| ISTQB 基礎教學大綱 | 測試層級、測試類型 |
+| Mike Cohn 測試金字塔 | 金字塔經驗比例（建議預設值） |
+
+## 術語
+
+| 術語 | 標準來源 | 說明 |
+|------|----------|------|
+| 完成定義 (DoD) | Agile/Scrum | 任務/功能完成的檢查清單 |
+| 測試完成準則 | ISO 29119-2 | 測試活動的退出準則 |
+| 系統整合測試 | ISO 12207 | 非正式 ISO 術語，但為業界標準 |
+| 金字塔比例 70/20/7/3 | Mike Cohn（經驗值） | 建議預設值，非強制 |
+
+---
+
+## 測試政策
+
+### 品質目標
+
+| ID | 名稱 | 衡量指標 |
+|----|------|----------|
+| QO-1 | 缺陷密度 | < 1 缺陷/KLOC（正式發布） |
+| QO-2 | 測試覆蓋率 | 依測試金字塔比例 |
+| QO-3 | 回歸率 | < 5% 每次迭代 |
+
+### 測試金字塔
+
+| 層級 | 比例 | 執行時間 | 說明 |
+|------|------|----------|------|
+| 單元測試 (UT) | 70% | < 100ms/test | 測試個別函式/方法 |
+| 整合測試 (IT) | 20% | < 1s/test | 測試元件互動 |
+| 端對端測試 (E2E) | 7% | 數秒/test | 測試使用者工作流 |
+| 效能/安全測試 | 3% | 分鐘級 | 非功能測試 |
+
+### 完成定義 (DoD)
+
+每個功能完成前必須滿足：
+
+| 項目 | 說明 |
+|------|------|
+| 所有測試通過 | 100% 通過率 |
+| 覆蓋率達標 | 符合金字塔比例 |
+| 無已知缺陷 | P0/P1 缺陷為零 |
+| 程式碼審查完成 | 至少一位審查者核准 |
+| 文件更新 | API 文件和 CHANGELOG 已更新 |
+
+## 測試環境管理
+
+| 環境 | 用途 | 管理責任 |
+|------|------|----------|
+| 本地 (Local) | 開發者單元測試 | 開發者 |
+| CI | 自動化測試 | CI/CD 管線 |
+| Staging | 整合和 E2E 測試 | DevOps |
+| Production | 煙霧測試和監控 | SRE |
+
+## 相關標準
+
+- [測試標準](testing-standards.md)
+- [提交規範](checkin-standards.md)
+- [部署標準](deployment-standards.md)