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

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

@@ -0,0 +1,66 @@
+---
+source: ../../../core/deployment-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 部署標準
+
+> **語言**: [English](../../../core/deployment-standards.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-02-09
+**適用性**: 所有具有部署管線的軟體專案
+**範圍**: 通用 (Universal)
+**業界標準**: Twelve-Factor App、Google SRE — Release Engineering、DORA State of DevOps
+**參考**: [12factor.net](https://12factor.net/)、[sre.google](https://sre.google/books/)、[dora.dev](https://dora.dev/)
+
+---
+
+## 目的
+
+本標準定義安全部署軟體到正式環境的指南，涵蓋部署策略、Feature Flags、回滾程序、環境一致性和部署效能指標。
+
+**參考標準**：
+- [The Twelve-Factor App](https://12factor.net/) — Factor X：開發/正式一致性
+- [Google SRE Book — Release Engineering](https://sre.google/sre-book/release-engineering/)
+- [DORA State of DevOps Report](https://dora.dev/)
+
+---
+
+## 核心原則
+
+| 原則 | 說明 |
+|------|------|
+| **部署 ≠ 發布** | 部署程式碼到正式環境和將其暴露給使用者是分開的動作；使用 Feature Flags 控制曝光 |
+| **漸進式曝光** | 將變更推送給越來越大的受眾：內部 → 金絲雀 → 百分比 → 全面上線 |
+| **快速回滾** | 每次部署必須有經過測試的回滾路徑，在 5 分鐘內完成 |
+| **環境一致性** | 保持開發、暫存和正式環境盡可能相似（Twelve-Factor App Factor X） |
+| **自動化一切** | 手動部署步驟容易出錯；自動化建置、測試、部署和回滾 |
+| **監控一切** | 部署時必須具備可觀測性；無法測量就無法安全部署 |
+
+## 部署策略選擇
+
+| 策略 | 停機時間 | 風險 | 適用場景 |
+|------|----------|------|----------|
+| **滾動更新 (Rolling)** | 零 | 低 | 無狀態服務 |
+| **藍綠部署 (Blue-Green)** | 接近零 | 低 | 需要即時回滾 |
+| **金絲雀部署 (Canary)** | 零 | 極低 | 高流量服務 |
+| **重建 (Recreate)** | 有 | 中 | 資料庫遷移 |
+
+## DORA 指標
+
+| 指標 | 菁英水準 | 高水準 |
+|------|----------|--------|
+| 部署頻率 | 每天多次 | 每週至每月 |
+| 變更前置時間 | < 1 小時 | 1 天至 1 週 |
+| 故障率 | 0-15% | 16-30% |
+| 服務恢復時間 | < 1 小時 | < 1 天 |
+
+## 相關標準
+
+- [安全標準](security-standards.md)
+- [效能標準](performance-standards.md)
+- [測試標準](testing-standards.md)

package/bundled/locales/zh-TW/core/error-code-standards.md

@@ -1,14 +1,14 @@
 ---
 source: ../../../core/error-code-standards.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-01-05
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-03-18
 status: current
 ---
 
 # 錯誤碼標準
 
-> 版本: 1.1.0 | 最後更新: 2026-01-05
+> 版本: 1.2.0 | 最後更新: 2026-03-18
 
 ## 概述
 
@@ -284,6 +284,228 @@ function validateEmail(email: string) {
 }
 ```
 
+## API 錯誤序列化
+
+### RFC 7807 / RFC 9457 Problem Details
+
+HTTP API 應使用 [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) Problem Details 格式作為標準錯誤封裝：
+
+```json
+{
+  "type": "https://api.example.com/errors/auth-val-001",
+  "title": "Validation Error",
+  "status": 400,
+  "detail": "Email field is required for registration",
+  "instance": "/api/register",
+  "code": "AUTH_VAL_001",
+  "errors": [
+    {
+      "field": "email",
+      "message": "Email is required",
+      "code": "AUTH_VAL_001"
+    }
+  ],
+  "requestId": "req_abc123",
+  "timestamp": "2026-03-18T10:30:00Z"
+}
+```
+
+**必要欄位（RFC 7807）：**
+
+| 欄位 | 型別 | 描述 |
+|------|------|------|
+| `type` | URI | 錯誤文件參考連結 |
+| `title` | string | 簡短的人類可讀摘要 |
+| `status` | integer | HTTP 狀態碼 |
+| `detail` | string | 人類可讀的詳細說明 |
+| `instance` | string | 引發錯誤的請求 URI |
+
+**擴充欄位（建議）：**
+
+| 欄位 | 型別 | 描述 |
+|------|------|------|
+| `code` | string | 應用程式錯誤碼（PREFIX_CATEGORY_NUMBER） |
+| `errors` | array | 欄位層級的詳細錯誤 |
+| `requestId` | string | 用於追蹤的關聯 ID |
+| `timestamp` | string | ISO 8601 時間戳 |
+
+### REST JSON 錯誤回應
+
+結合內部錯誤碼與 RFC 7807 的標準 REST 錯誤回應：
+
+```json
+// 單一錯誤
+{
+  "type": "https://api.example.com/errors/validation",
+  "title": "Validation Error",
+  "status": 400,
+  "detail": "Request validation failed",
+  "errors": [
+    {
+      "code": "AUTH_VAL_001",
+      "field": "email",
+      "message": "Email is required",
+      "pointer": "/data/attributes/email"
+    }
+  ]
+}
+
+// 多重錯誤
+{
+  "type": "https://api.example.com/errors/validation",
+  "title": "Validation Error",
+  "status": 400,
+  "detail": "Multiple validation errors occurred",
+  "errors": [
+    {
+      "code": "AUTH_VAL_001",
+      "field": "email",
+      "message": "Email is required",
+      "pointer": "/data/attributes/email"
+    },
+    {
+      "code": "AUTH_VAL_201",
+      "field": "password",
+      "message": "Password must be at least 8 characters",
+      "pointer": "/data/attributes/password"
+    }
+  ]
+}
+```
+
+### GraphQL 錯誤處理
+
+GraphQL 使用不同的錯誤模型。將應用程式錯誤碼映射到 `extensions` 欄位：
+
+```json
+{
+  "data": null,
+  "errors": [
+    {
+      "message": "Email is required",
+      "locations": [{ "line": 2, "column": 3 }],
+      "path": ["createUser"],
+      "extensions": {
+        "code": "AUTH_VAL_001",
+        "category": "VALIDATION",
+        "field": "email",
+        "httpStatus": 400,
+        "timestamp": "2026-03-18T10:30:00Z"
+      }
+    }
+  ]
+}
+```
+
+**GraphQL 錯誤類別：**
+
+| 類別 | 對應 | 用途 |
+|------|------|------|
+| `VALIDATION` | VAL | 輸入驗證失敗 |
+| `BUSINESS_RULE` | BIZ | 業務邏輯違反 |
+| `AUTHENTICATION` | AUTH (001-099) | 身份驗證失敗 |
+| `AUTHORIZATION` | AUTH (100-199) | 權限失敗 |
+| `INTERNAL` | SYS | 伺服器端錯誤 |
+| `NETWORK` | NET | 上游服務失敗 |
+
+### gRPC 錯誤處理
+
+將應用程式錯誤碼映射到 gRPC 狀態碼，並透過 metadata 傳遞詳細資訊：
+
+```protobuf
+// 錯誤詳情訊息
+message ErrorDetail {
+  string code = 1;          // "AUTH_VAL_001"
+  string message = 2;       // 人類可讀訊息
+  string field = 3;         // 受影響的欄位
+  string documentation = 4; // 錯誤文件連結
+}
+```
+
+**gRPC 狀態碼對應：**
+
+| 類別 | gRPC 狀態 | 代碼 |
+|------|----------|------|
+| VAL | `INVALID_ARGUMENT` | 3 |
+| BIZ | `FAILED_PRECONDITION` | 9 |
+| AUTH (001-099) | `UNAUTHENTICATED` | 16 |
+| AUTH (100-199) | `PERMISSION_DENIED` | 7 |
+| SYS | `INTERNAL` | 13 |
+| NET | `UNAVAILABLE` | 14 |
+
+```go
+// Go 範例
+import "google.golang.org/grpc/status"
+import "google.golang.org/grpc/codes"
+
+st := status.New(codes.InvalidArgument, "Validation failed")
+st, _ = st.WithDetails(&errdetails.BadRequest{
+    FieldViolations: []*errdetails.BadRequest_FieldViolation{
+        {Field: "email", Description: "AUTH_VAL_001: Email is required"},
+    },
+})
+return st.Err()
+```
+
+## 重試與冪等性
+
+### 重試指導
+
+| 類別 | 可重試 | 策略 |
+|------|--------|------|
+| VAL | 否 | 修正輸入後重新提交 |
+| BIZ | 否 | 解決業務條件 |
+| AUTH (001-099) | 否 | 重新驗證身份 |
+| AUTH (200-299) | 是 | 重新整理令牌後重試 |
+| SYS | 視情況 | 指數退避重試 |
+| NET | 是 | 指數退避重試 |
+
+### 重試回應標頭
+
+```http
+HTTP/1.1 503 Service Unavailable
+Retry-After: 30
+X-RateLimit-Reset: 1679961600
+```
+
+在錯誤回應中包含重試指導：
+
+```json
+{
+  "type": "https://api.example.com/errors/rate-limit",
+  "title": "Rate Limit Exceeded",
+  "status": 429,
+  "detail": "Too many requests",
+  "code": "API_NET_429",
+  "retryable": true,
+  "retryAfter": 30
+}
+```
+
+### 冪等性金鑰
+
+對於非冪等操作（POST），要求 `Idempotency-Key` 標頭：
+
+```http
+POST /api/payments HTTP/1.1
+Idempotency-Key: key_abc123def456
+Content-Type: application/json
+
+{"amount": 100, "currency": "USD"}
+```
+
+**冪等性規則：**
+
+| 動詞 | 冪等 | 需要金鑰 |
+|------|------|---------|
+| GET | 是 | 否 |
+| PUT | 是 | 否 |
+| DELETE | 是 | 否 |
+| PATCH | 否 | 建議 |
+| POST | 否 | 關鍵操作必須 |
+
+---
+
 ## 文件需求
 
 ### 錯誤碼文件
@@ -365,6 +587,7 @@ AUTH_VAL_001
 
 | 版本 | 日期 | 變更 |
 |-----|------|------|
+| 1.2.0 | 2026-03-18 | 新增：API 錯誤序列化（RFC 7807 Problem Details、REST、GraphQL、gRPC）、重試與冪等性指導 |
 | 1.1.0 | 2026-01-05 | 新增：參考標準章節，包含 RFC 7807、RFC 9457、HTTP 狀態碼和 Microsoft REST API 指南 |
 | 1.0.0 | 2025-12-30 | 初始錯誤碼標準 |
 
@@ -376,6 +599,9 @@ AUTH_VAL_001
 - [RFC 9457 - HTTP API 問題詳情](https://datatracker.ietf.org/doc/html/rfc9457) - RFC 7807 更新版 (2023)
 - [HTTP 狀態碼 (MDN)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) - HTTP 狀態碼參考
 - [Microsoft REST API 指南 - 錯誤處理](https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#handling-errors) - 業界最佳實踐
+- [GraphQL 規範 - 錯誤](https://spec.graphql.org/October2021/#sec-Errors) - GraphQL 錯誤格式規範
+- [gRPC 狀態碼](https://grpc.github.io/grpc/core/md_doc_statuscodes.html) - gRPC 錯誤處理參考
+- [Google API 設計指南 - 錯誤](https://cloud.google.com/apis/design/errors) - Google API 錯誤設計模式
 
 ---
 

package/bundled/locales/zh-TW/core/forward-derivation-standards.md

@@ -1,7 +1,15 @@
+---
+source: ../../../core/forward-derivation-standards.md
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-03-18
+status: current
+---
+
 # 正向推演標準 | Forward Derivation Standards
 
-**版本**: 1.0.0
-**最後更新**: 2026-01-19
+**版本**: 1.2.0
+**最後更新**: 2026-03-18
 **適用範圍**: 所有使用規格驅動開發的專案
 
 > **語言**: [English](../../../core/forward-derivation-standards.md) | 繁體中文
@@ -363,6 +371,57 @@ spec-review → forward-derivation → discovery
 
 ---
 
+## Pipeline 整合
+
+### 自動 TDD 轉換
+
+當正向推演由自動化 Pipeline 觸發時（參見 [Pipeline 整合標準](pipeline-integration-standards.md)），以下規則適用於轉換至 TDD 循環：
+
+#### Auto-TDD 進入規則
+
+| 規則 | 說明 |
+|------|------|
+| **推演完整性** | 所有推演輸出（BDD、TDD、ATDD）必須在進入 TDD 前完成生成 |
+| **RED 狀態初始化** | Pipeline 在生成測試骨架後將 TDD 狀態設為 RED |
+| **測試骨架驗證** | 生成的測試檔案必須能編譯/解析無誤後才能進入 RED |
+| **AC 計數驗證** | 進入轉換前驗證輸出測試數量與 AC 數量匹配 |
+
+#### Pipeline Hooks
+
+推演步驟可透過 Pipeline 事件自動觸發：
+
+| Hook | 觸發條件 | 動作 |
+|------|---------|------|
+| `on-spec-approved` | Spec 狀態變更為「已批准」 | 啟動推演 Pipeline |
+| `on-derivation-complete` | 所有推演輸出已生成 | 轉換至 TDD RED 階段 |
+| `on-tdd-green` | 所有推演測試通過 | 觸發審查階段 |
+
+#### Auto-TDD 進入工作流程
+
+```
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│ Spec Approved│───▶│  Derive All  │───▶│ Verify Count │───▶│  TDD RED     │
+│ (hook)       │    │  BDD+TDD+ATDD│    │ AC = Tests   │    │  (auto-set)  │
+└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
+```
+
+1. **Spec 批准**：Pipeline 偵測到 Spec 批准（透過 hook 或輪詢）
+2. **完整推演**：Pipeline 以專案配置的語言/框架執行 `/derive-all`
+3. **計數驗證**：Pipeline 驗證輸出數量與 AC 數量匹配（反幻覺）
+4. **RED 狀態**：Pipeline 將 TDD 狀態設為 RED；測試骨架存在但 assertion 為 [TODO]
+
+#### 與 Pipeline 階段的整合
+
+正向推演對應 [Pipeline 整合標準](pipeline-integration-standards.md) 6 階段模型中的 **DERIVE** 階段：
+
+| Pipeline 階段 | 正向推演角色 |
+|--------------|------------|
+| SPEC | 輸入：已批准的規格 |
+| **DERIVE** | 執行：解析 AC → 生成 BDD/TDD/ATDD 輸出 |
+| BUILD | 輸出：測試骨架進入 TDD RED→GREEN 循環 |
+
+---
+
 ## 應避免的反模式
 
 ### 生成反模式
@@ -424,6 +483,7 @@ spec-review → forward-derivation → discovery
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| 1.2.0 | 2026-03-18 | 新增：Pipeline 整合章節 — auto-TDD 轉換、pipeline hooks、auto-TDD 進入工作流程 |
 | 1.0.0 | 2026-01-19 | 初始發布 |
 
 ---

package/bundled/locales/zh-TW/core/git-worktree.md

@@ -0,0 +1,104 @@
+---
+source: ../../../core/git-worktree.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# Git Worktree 隔離
+
+> **語言**: [English](../../../core/git-worktree.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-20
+**適用性**: 所有使用 Git 進行版本控制的專案
+**範圍**: 通用 (Universal)
+**靈感來源**: [Superpowers](https://github.com/obra/superpowers) — using-git-worktrees (MIT)
+
+---
+
+## 目的
+
+定義 Git Worktree 的完整生命週期管理標準，確保環境乾淨、安全合併與適當清理。Worktree 允許在多個分支上並行工作，無需 stash 或切換。
+
+---
+
+## 術語表
+
+| 術語 | 定義 |
+|------|------|
+| Worktree | Git 儲存庫在不同分支上的鏈接工作副本 |
+| 基準測試 (Baseline Test) | 在新建 worktree 上執行的測試，用於驗證環境是乾淨的 |
+| Worktree 目錄 | worktree 被建立的檔案系統路徑 |
+
+---
+
+## 核心原則 — 隔離與責任
+
+> **每個 worktree 必須以乾淨狀態開始（基準測試）、在隔離環境中工作、以合併或明確清理結束。**
+
+---
+
+## 生命週期階段
+
+### 階段 1：建立
+
+```bash
+# 建立新的 worktree
+git worktree add ../project-feature-name feature/feature-name
+```
+
+| 步驟 | 說明 |
+|------|------|
+| 1. 建立 worktree | 指定路徑和分支名稱 |
+| 2. 安裝依賴 | 在新 worktree 中執行 `npm install` 等 |
+| 3. 基準測試 | 執行測試確認環境乾淨 |
+
+### 階段 2：工作
+
+- 在 worktree 中正常開發
+- 各 worktree 之間完全隔離
+- 不影響主工作目錄
+
+### 階段 3：完成
+
+| 選項 | 指令 |
+|------|------|
+| 合併 | 在主目錄中執行 `git merge feature/name` |
+| 丟棄 | 執行清理流程 |
+
+### 階段 4：清理
+
+```bash
+# 移除 worktree
+git worktree remove ../project-feature-name
+
+# 列出所有 worktree
+git worktree list
+
+# 清理過時的 worktree 參考
+git worktree prune
+```
+
+## 命名慣例
+
+| 元素 | 格式 | 範例 |
+|------|------|------|
+| Worktree 目錄 | `../project-feature-name` | `../myapp-login-fix` |
+| 分支名稱 | `feature/name` 或 `fix/name` | `feature/user-auth` |
+
+## 最佳實踐
+
+| 實踐 | 原因 |
+|------|------|
+| 建立後立即執行基準測試 | 確認環境乾淨 |
+| 完成後立即清理 | 避免 worktree 累積 |
+| 不要在 worktree 之間共享未提交的變更 | 防止衝突 |
+| 定期執行 `git worktree prune` | 清理過時參考 |
+
+## 相關標準
+
+- [分支完成工作流程](branch-completion.md)
+- [代理派遣與並行協調](agent-dispatch.md)
+- [Git 工作流](git-workflow.md)

package/bundled/locales/zh-TW/core/model-selection.md

@@ -0,0 +1,83 @@
+---
+source: ../../../core/model-selection.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# AI 模型選擇策略
+
+> **語言**: [English](../../../core/model-selection.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-20
+**適用性**: 使用多模型分級的 AI 輔助開發
+**範圍**: 通用 (Universal)
+**靈感來源**: [Superpowers](https://github.com/obra/superpowers) — subagent-driven-development (MIT)
+
+---
+
+## 目的
+
+定義基於任務複雜度的 AI 模型分級選擇策略。使用能勝任的最便宜模型，僅在必要時升級。
+
+---
+
+## 術語表
+
+| 術語 | 定義 |
+|------|------|
+| 模型分級 (Model Tier) | 代表模型能力和成本的分類等級 |
+| 複雜度信號 (Complexity Signal) | 指示所需能力等級的任務可觀察特徵 |
+| 升級 (Escalation) | 低級模型失敗後升級到高級模型 |
+
+---
+
+## 核心原則 — 成本效益
+
+> **始終使用與任務複雜度匹配的最便宜模型。**
+
+---
+
+## 三級模型分類
+
+| 級別 | 適用場景 | 複雜度信號 |
+|------|----------|-----------|
+| **Tier 1（輕量級）** | 簡單、重複性任務 | 單一檔案、格式化、搜尋替換 |
+| **Tier 2（標準級）** | 中等複雜度任務 | 多檔案、邏輯修改、測試撰寫 |
+| **Tier 3（高級）** | 高複雜度任務 | 架構設計、跨系統整合、除錯 |
+
+## 複雜度信號判斷
+
+| 信號 | Tier 1 | Tier 2 | Tier 3 |
+|------|--------|--------|--------|
+| 涉及檔案數 | 1 | 2-5 | 6+ |
+| 需要推理深度 | 淺 | 中 | 深 |
+| 跨模組互動 | 無 | 有限 | 複雜 |
+| 需要創意/設計 | 無 | 部分 | 大量 |
+| 錯誤風險 | 低 | 中 | 高 |
+
+## 升級規則
+
+| 觸發條件 | 動作 |
+|----------|------|
+| 低級模型產生錯誤輸出 | 升級到下一級別 |
+| 任務超出預期複雜度 | 升級到下一級別 |
+| 多次重試仍失敗 | 升級到最高級別 |
+| 安全性或架構關鍵任務 | 直接使用最高級別 |
+
+## 成本最佳化策略
+
+| 策略 | 說明 |
+|------|------|
+| **批次處理** | 將多個簡單任務合併為一次呼叫 |
+| **快取** | 快取常見查詢結果避免重複呼叫 |
+| **預篩選** | 先用低成本模型判斷是否需要升級 |
+| **任務分解** | 將複雜任務拆分為多個簡單子任務 |
+
+## 相關標準
+
+- [代理派遣與並行協調](agent-dispatch.md)
+- [驗證證據](verification-evidence.md)
+- [系統化除錯](systematic-debugging.md)

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

@@ -0,0 +1,84 @@
+---
+source: ../../../core/performance-standards.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 效能標準
+
+> **語言**: [English](../../../core/performance-standards.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-01-29
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
+**業界標準**: ISO/IEC 25010 效能效率
+**參考**: [sre.google](https://sre.google/books/)
+
+> **詳細說明與最佳化技術，請參閱 [效能指南](../../../core/guides/performance-guide.md)**
+
+---
+
+## 目的
+
+本標準定義軟體效能工程的完整指南，涵蓋效能需求、測試方法論和監控實踐。
+
+**參考標準**：
+- [ISO/IEC 25010:2011](https://www.iso.org/standard/35733.html) - 效能效率
+- [Google SRE Book](https://sre.google/books/) - 網站可靠性工程
+
+---
+
+## 效能需求範本
+
+### NFR 格式
+
+```markdown
+### NFR-PERF-XXX: [標題]
+
+**分類**: 效能效率 > [時間行為/資源利用/容量]
+**優先級**: P1/P2/P3
+
+**需求**:
+| 百分位 | 目標 | 最大值 |
+|--------|------|--------|
+| p50 | Xms | Yms |
+| p95 | Xms | Yms |
+| p99 | Xms | Yms |
+```
+
+## 效能預算
+
+| 類別 | 預算 | 測量方式 |
+|------|------|----------|
+| 頁面載入時間 | < 3 秒 | Lighthouse |
+| API 回應時間 (p95) | < 500ms | APM 工具 |
+| 記憶體使用 | < 512MB | 執行時監控 |
+| CPU 使用率 | < 70% 平均 | 系統監控 |
+| 套件大小 | < 200KB (gzip) | 建置分析 |
+
+## 效能測試類型
+
+| 類型 | 目的 | 工具 |
+|------|------|------|
+| **負載測試** | 驗證正常負載下的效能 | k6、JMeter、Locust |
+| **壓力測試** | 找出系統極限 | k6、Gatling |
+| **浸泡測試** | 偵測記憶體洩漏 | k6（長時間執行） |
+| **尖峰測試** | 驗證突發流量處理 | k6、Artillery |
+
+## 監控與告警
+
+| 指標類型 | 範例 | 告警閾值 |
+|----------|------|----------|
+| 延遲 (Latency) | p95 回應時間 | > 目標的 2 倍 |
+| 流量 (Traffic) | 每秒請求數 | 異常波動 > 50% |
+| 錯誤率 (Errors) | HTTP 5xx 比例 | > 1% |
+| 飽和度 (Saturation) | CPU/記憶體使用 | > 80% |
+
+## 相關標準
+
+- [部署標準](deployment-standards.md)
+- [安全標準](security-standards.md)
+- [測試標準](testing-standards.md)