universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-TW/core/secret-management-standards.md

@@ -0,0 +1,101 @@
+---
+source: ../../../core/secret-management-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: 1bb70238135b
+status: current
+---
+
+# 機密管理與憑證衛生標準
+
+> **Language**: [English](../../../core/secret-management-standards.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/secret-management-standards.ai.yaml`
+> **規格**: XSPEC-065（cross-project/specs/XSPEC-065-uds-infrastructure-pack.md）
+
+## 概觀
+
+本標準定義團隊如何在開發與生產環境中儲存、注入、輪替與稽核機密（secret）與憑證。
+涵蓋三個核准的機密來源層級（Vault 動態機密、Cloud KMS、SOPS+Git）、依憑證類型的
+輪替政策、透過 pre-commit 與 CI 掃描自動防止硬編碼機密，以及安全的機密注入模式。
+設計目標為消除原始碼與 CI 日誌中的憑證，同時在各種團隊規模下維持營運實務性。
+
+本標準屬於 **IaC 標準包**（XSPEC-065），並作為機密處理的橫切*主要負責者*：被容器
+映像建構（`container-image-standards`）、合規稽核（`audit-trail`）以及存放憑證的
+SRE runbook 多處引用。
+
+> **範圍**：本標準定義機密的*核准來源*、*輪替頻率*、*防護層*與*注入模式*。在
+> Vault／Cloud KMS／SOPS 之間的選擇以及特定掃描工具屬採用者的選擇。
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | 機密來源三選項（Vault／Cloud KMS／SOPS+Git） | MUST |
+| REQ-002 | 依類型的輪替政策 | MUST |
+| REQ-003 | 硬編碼機密防護（pre-commit + CI 掃描） | MUST |
+| REQ-004 | 機密注入（僅限環境變數或掛載檔案） | MUST |
+
+### REQ-001 — 機密來源三選項
+
+團隊 MUST 依營運情境使用三個核准的機密來源層級之一：(1) **HashiCorp Vault 動態
+機密**（生產與多團隊環境首選）——機密以短 TTL 隨需生成，任何地方皆不儲存靜態憑證；
+(2) **Cloud KMS 搭配原生 secret manager**（AWS Secrets Manager／GCP Secret
+Manager／Azure Key Vault）——適合雲原生部署，機密於執行期透過受 IAM 控制的 API
+呼叫取得；(3) **SOPS + Git 加密**——適合小團隊與 GitOps 流程，機密以 `age` 或 KMS
+金鑰加密後再 commit，僅於受信任的執行環境解密。在任何其他位置（env 檔、wiki、聊天）
+儲存未加密機密為 **PROHIBITED**。
+
+### REQ-002 — 依類型的輪替政策
+
+所有機密 MUST 具備由自動化工具或行事曆提醒強制執行的輪替政策。各類型最低輪替
+頻率：**資料庫憑證**——每 90 天；**API 金鑰**（第三方服務）——每 180 天；**簽章
+金鑰**（JWT、程式碼簽章）——每 365 天；**一次性 token 與 session 憑證**——使用後
+立即撤銷，MUST NOT 重用；**TLS 憑證**——至少於到期前 30 天輪替，盡可能以
+ACME／Let's Encrypt 或 cert-manager 自動化。輪替事件 MUST 記錄於稽核軌跡。
+
+### REQ-003 — 硬編碼機密防護
+
+團隊 MUST 實作自動掃描，以在硬編碼機密進入儲存庫前偵測並封鎖。REQUIRED 兩層：
+(1) **Pre-commit hook** 使用 `detect-secrets`、`gitleaks` 或 `truffleHog`——掃描
+staged 檔案，偵測到 pattern 即封鎖 commit；(2) **CI 管線掃描**——於每個 PR 重掃所有
+變更檔案，若發現機密則封鎖合併。最低偵測 pattern：AWS access key 格式
+（`AKIA[0-9A-Z]{16}`）、PEM 私鑰標頭（`-----BEGIN .* PRIVATE KEY`）、通用 API token
+pattern（`api[_-]?key\s*[:=]\s*\S{16,}`），以及含密碼的連線字串。
+
+### REQ-004 — 機密注入
+
+機密 MUST 僅透過環境變數或掛載檔案注入應用程式程序。透過命令列參數傳遞機密為
+**PROHIBITED**（於程序清單可見）。透過 URL 查詢參數傳遞機密為 **PROHIBITED**（被
+proxy 與伺服器記錄）。環境變數注入應使用平台原生機密注入（Kubernetes Secrets、ECS
+task definition secrets、GitHub Actions secrets）。檔案式注入則將機密掛載為唯讀
+volume，並使用限制性檔案權限（0400 或 0600）。
+
+## 反模式
+
+- 將憑證直接硬編碼於原始碼或設定檔。
+- 未加密即將機密存於 CI/CD 環境變數（UI 中明文）。
+- 跨多環境共用憑證（dev／staging／prod 使用相同機密）。
+- 長期靜態憑證且無輪替排程。
+- 將含真實機密的 `.env` 檔提交至版本控制。
+
+## 與既有標準的整合
+
+- **`iac-design-principles`**——機密後端（Vault／KMS 狀態）本身即是版本化、受存取
+  控制的基礎設施。
+- **`audit-trail`**——輪替、存取與注入事件為可稽核操作（REQ-002 要求記錄輪替事件）。
+- **`pii-classification`**——守護 TIER-1 PII 的憑證承襲最嚴格的處理控制。
+- **`security-standards`**——本標準是更廣安全基線的憑證衛生面向。
+
+## 相關規格
+
+- XSPEC-065 — UDS 基礎設施（IaC）標準包（本標準來源）
+- DEC-043 — UDS 覆蓋完整性路線圖（Wave 4 範圍；D1 橫切負責者）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~004：機密來源選項、輪替政策、硬編碼機密防護、機密注入（XSPEC-065） |

package/bundled/locales/zh-TW/core/secure-op.md

@@ -0,0 +1,328 @@
+---
+source: ../../../core/secure-op.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 7ef0c2e3a2c2
+status: current
+---
+
+# Secure-Op：AI Agent 安全操作標準
+
+> **Language**: [原文（繁體中文）](../../../core/secure-op.md) | 繁體中文 | [简体中文](../../zh-CN/core/secure-op.md)
+
+**版本**：1.0.0
+**最後更新**：2026-05-04
+**適用範圍**：所有部署 AI Agent 的系統
+**範疇**：AI Agent 安全操作
+**產業標準**：ISO/IEC 27001:2022、NIST SP 800-207、OWASP LLM Top 10 2025
+
+---
+
+## 標準概述
+
+**Secure-Op** 是針對 AI Agent 系統的安全操作方法論，定義 AI Agent 在執行高風險操作時必須遵循的六大安全支柱。
+
+本標準源自 External Guardian OPA Sidecar reference implementation (XSPEC-146 from an external project)的實作經驗，並沉澱為通用 UDS 標準，供任何採用 UDS 的 AI Agent 系統套用。
+
+### 核心理念
+
+傳統軟體安全假設操作主體是人類使用者。AI Agent 系統帶來新的威脅模型：
+- **Agent 可能被提示注入（Prompt Injection）操控**，偽裝成合法操作
+- **LLM 推論不確定性**，相同輸入可能產生不同決策
+- **操作範圍不可預測**，一個指令可能觸發連鎖副作用
+
+Secure-Op 的回應是：**確定性系統守護邊界，機率性系統只做輔助**。
+
+---
+
+## 六大支柱
+
+### 支柱一：Veto-Based Decision（否決式決策）
+
+決策邏輯必須以「否決權」為基礎，不得使用投票制。
+
+#### 核心原則
+
+| 原則 | 說明 |
+|------|------|
+| Deterministic > Probabilistic | 確定性系統（Policy Engine、Rule Engine）的決策優先於 LLM 推論 |
+| Policy-as-Code | 所有安全規則必須版本控制，可回歸測試 |
+| 否決即終止 | 任一層 DENY 即立刻終止管線，不繼續下一層 |
+
+#### 決策管線（Decision Pipeline）
+
+```
+輸入操作請求
+     │
+     ▼
+[M1] Prompt Injection 偵測
+     │ DENY → 終止
+     ▼
+[M2] Policy Engine（OPA / Rule Engine）
+     │ DENY → 終止
+     ▼
+[M3] SOBR 風險評分
+     │ ≥76 → DENY；51-75 → HITL；≤50 → 繼續
+     ▼
+[M4] Semantic Review（選配，LLM）
+     │ DENY → 終止
+     ▼
+執行操作 + 記錄 Audit
+```
+
+**參考實作**：OPA（Open Policy Agent）或等效 Policy Engine
+
+---
+
+### 支柱二：SOBR Risk Scoring（四維風險評分）
+
+量化風險分數，提供一致且可解釋的決策依據。
+
+#### 公式
+
+```
+RiskScore = S×0.30 + O×0.25 + B×0.25 + R×0.20
+```
+
+#### 四個維度
+
+| 維度 | 權重 | 說明 | 範例高分 | 範例低分 |
+|------|------|------|---------|---------|
+| **S** Sensitivity | 0.30 | 目標資源敏感度 | 使用者憑證（100）| 公開文件（5）|
+| **O** OperationType | 0.25 | 操作危險程度 | 執行任意程式碼（100）| 讀取公開資料（10）|
+| **B** BlastRadius | 0.25 | 操作影響範圍 | 影響所有正式環境（100）| 隔離開發沙箱（10）|
+| **R** Reversibility | 0.20 | 不可逆程度（越不可逆分數越高）| 永久刪除無備份（100）| 唯讀操作（0）|
+
+#### 決策閾值
+
+| 分數範圍 | 決策 | 行動 |
+|---------|------|------|
+| 0–25 | **ALLOW** | 正常執行，記錄 Audit |
+| 26–50 | **ALLOW_WITH_MONITORING** | 執行並加強監控，標記人工事後審查 |
+| 51–75 | **REQUIRE_HITL** | 觸發人工審核升級（Human-in-the-Loop）|
+| 76–100 | **DENY** | 拒絕，記錄決策路徑與違規項目 |
+
+---
+
+### 支柱三：Fail-Closed（故障關閉原則）
+
+任何安全組件故障時，**預設行為必須是 DENY**，禁止 fail-open。
+
+#### 故障情境對應
+
+| 故障情境 | 必要回應 | 例外 |
+|---------|---------|------|
+| Policy Engine 不可達 | DENY ALL | 唯讀操作可由操作者明確設定例外 |
+| SOBR 評分計算失敗 | REQUIRE_HITL（保守升級）| 無 |
+| Signature 驗證失敗 | DENY ALL | 無 |
+| 任何未知錯誤 | DENY | 無 |
+
+#### 禁止的反模式
+
+- **Fail-Open**：錯誤時預設 ALLOW（嚴重度：CRITICAL）
+- **部分驗證繼續執行**：某層驗證失敗但仍繼續（嚴重度：HIGH）
+- **靜默吞噬錯誤**：catch 錯誤但不改變決策（嚴重度：HIGH）
+
+---
+
+### 支柱四：Audit Chain（不可竄改審計軌跡）
+
+所有安全決策必須記錄在**可驗證的不可竄改審計軌跡**中。
+
+#### 每筆 Audit 紀錄必要欄位
+
+| 欄位 | 型別 | 說明 |
+|------|------|------|
+| `request_id` | UUID v4 | 每次決策的唯一識別碼 |
+| `decision` | enum | ALLOW / ALLOW_WITH_MONITORING / REQUIRE_HITL / DENY |
+| `risk_score` | number (0-100) | SOBR 計算結果 |
+| `timestamp` | ISO 8601 UTC | 毫秒精度時間戳 |
+| `violations` | string[] | 違規政策列表（ALLOW 時為空陣列）|
+| `signature` | base64 Ed25519 | 對核心欄位的非對稱簽章 |
+| `prev_hash` | SHA-256 hex | 前一筆紀錄的 hash（構成 hash chain）|
+
+#### Hash Chain 設計
+
+```
+Record[0]: prev_hash = "0000...0000" (genesis)
+Record[1]: prev_hash = SHA-256(Record[0])
+Record[2]: prev_hash = SHA-256(Record[1])
+...
+```
+
+必須提供 `verify_chain()` 函式，可偵測任何中間紀錄的竄改。
+
+#### 簽章規格
+
+- **演算法**：Ed25519（非對稱加密）
+- **簽署內容**：`{request_id}:{decision}:{risk_score}:{timestamp}`
+- **禁止**：使用 HMAC（對稱）作為審計簽章
+
+#### 儲存等級
+
+| 等級 | 儲存媒介 | 適用環境 |
+|------|---------|---------|
+| Level 0（最低）| 本地 append-only file | 開發/測試 |
+| Level 1（推薦）| WORM 儲存（S3 Object Lock / Azure Immutable Blob）| 正式環境 |
+| Level 2（最高）| 不可變雲端 + Remote Attestation | 法規要求環境（SOC2, ISO 27001 認證）|
+
+---
+
+### 支柱五：HITL Escalation（人工審核升級）
+
+Risk Score 落在 51–75（REQUIRE_HITL 區間）時，必須有明確的人工審核升級機制。
+
+#### 兩種 HITL 模式
+
+| 模式 | 行為 | 適用情境 |
+|------|------|---------|
+| **Non-Blocking** | 發送通知，執行繼續（加強監控）| 分數 51–62，低敏感操作 |
+| **Blocking** | 暫停執行，等待人工確認 | 分數 63–75，高敏感環境 |
+
+#### 必要要求
+
+- **TTL**：HITL 審核請求必須有過期時間（建議 **1800 秒**）
+- **過期行為**：TTL 到期未審核 → 自動升級為 DENY
+- **Audit**：HITL 觸發事件與審核結果必須記入 Audit Chain
+- **通知介面**：Webhook 為標準介面；Adapter 模式支援 Slack / Teams / PagerDuty
+
+#### 通知 Payload 必要欄位
+
+```json
+{
+  "request_id": "...",
+  "risk_score": 67,
+  "operation_summary": "...",
+  "policy_violations": [...],
+  "expires_at": "2026-05-04T12:30:00Z"
+}
+```
+
+---
+
+### 支柱六：Prompt Injection Defense（提示注入防護）
+
+AI Agent 系統必須防護 Prompt Injection 攻擊，防止惡意輸入繞過安全控制。
+
+#### 偵測模式類型
+
+| 類型 | 範例模式 |
+|------|---------|
+| 覆蓋指令 | "ignore previous instructions", "disregard your programming" |
+| 角色扮演操控 | "you are now", "act as", "DAN", "jailbreak" |
+| 系統 Token 注入 | `[SYSTEM]`, `[INST]`, `<\|system\|>`, `<<SYS>>` |
+| 指令前綴 | "New instruction:", "OVERRIDE:", "Updated system prompt:" |
+
+#### 防護措施
+
+1. **攔截位置**：M1 Intake 層（管線最前端），在任何語意評估前攔截
+2. **回應**：觸發 DENY + 記錄 `PROMPT_INJECTION_DETECTED` violation
+3. **日誌安全**：**禁止**將原始惡意輸入存入日誌；只記錄偵測到的模式類型與輸入的 Hash
+4. **模式維護**：每月更新偵測模式；訂閱 OWASP LLM Working Group 更新
+
+---
+
+## 實作參考
+
+### External Guardian (reference implementation)（TypeScript 參考實作）
+
+External Guardian OPA Sidecar reference implementation (XSPEC-146 from an external project)是 Secure-Op 的完整 TypeScript 參考實作，包含：
+
+- **GuardianService**：主要 Veto-based 決策管線
+- **SobrScorer**：SOBR 四維風險評分
+- **AuditChain**：SHA-256 Hash Chain + Ed25519 簽章
+- **HitlNotifier**：Webhook Adapter（支援 Slack/Teams）
+- **PromptInjectionDetector**：正則表達式 + 模式比對
+
+> 路徑：external Guardian implementation (separately licensed)
+
+### 最小實作清單
+
+建立 Secure-Op 合規系統的最小步驟：
+
+```
+□ Step 1：建立 Policy Engine（OPA 或等效工具）並連接至 Agent 管線
+□ Step 2：實作 SOBR 評分計算（4 維度 + 權重公式）
+□ Step 3：設定決策閾值路由（ALLOW / MONITORING / HITL / DENY）
+□ Step 4：建立 Audit Chain（append-only + hash + signature）
+□ Step 5：實作 HITL 通知 + TTL 機制
+□ Step 6：加入 Prompt Injection 偵測（M1 位置）
+□ Step 7：在所有錯誤路徑確認 Fail-Closed 行為
+```
+
+---
+
+## ISO / NIST / OWASP 對映
+
+| 支柱 | 標準對映 |
+|------|---------|
+| Veto-Based Decision | ISO/IEC 27001:2022 A.8.24 |
+| SOBR Risk Scoring | ISO/IEC 27001:2022 Annex A.8.24；ISO/IEC 27005 |
+| Fail-Closed | NIST SP 800-207 Zero Trust Architecture（2.1節）；ISO/IEC 27001:2022 A.8.22 |
+| Audit Chain | ISO/IEC 27001:2022 A.8.15（Logging）；ISO/IEC 27001:2022 A.5.33（Protection of records）|
+| HITL Escalation | ISO/IEC 27001:2022 A.8.2；NIST SP 800-53 AC-2 |
+| Prompt Injection Defense | OWASP LLM Top 10 2025 LLM01；ISO/IEC 27001:2022 A.8.24 |
+
+---
+
+## 等級分類
+
+Secure-Op 標準分為三個實作等級（Priority Levels）：
+
+### P0a：審查層（必須）
+
+最低基準要求，所有 AI Agent 系統必須實作：
+
+- Policy Engine 連接並設定 Fail-Closed
+- SOBR 風險評分（任何操作請求觸發）
+- Prompt Injection 偵測（M1 位置）
+
+### P0b：執行驗證層（必須）
+
+在 P0a 基礎上，強化執行時的決策保障：
+
+- 完整決策路由（ALLOW / MONITORING / HITL / DENY）
+- HITL 升級機制（含 TTL）
+- 所有決策記入 Audit Log
+
+### P0c：強化層（高安全需求環境）
+
+在 P0b 基礎上，達到法規合規等級：
+
+- Hash Chain + Ed25519 簽章的 Audit Chain
+- WORM 儲存（Level 1 或 Level 2）
+- Remote Attestation 支援
+- 定期 Audit Chain 完整性驗證
+
+---
+
+## 快速開始建議
+
+### 對於小型 AI Agent 系統（MVP / Prototype）
+
+從 SOBR 評分 + 基本 DENY 閾值開始：
+
+1. 為每個操作類型定義 S / O / B / R 值
+2. 計算 RiskScore；≥76 直接拒絕
+3. 記錄決策到 append-only log
+
+### 對於生產環境 AI Agent 系統
+
+完整實作六大支柱，使用 External Guardian (reference implementation) 作為參考或直接引用。
+
+### 對於法規要求環境（金融、醫療、政府）
+
+P0c 等級 + 外部稽核師可存取的 Audit Chain 匯出功能。
+
+---
+
+## 相關標準
+
+- `security-standards`：架構層安全設計（輸入驗證、認證設計）
+- `security-testing`：安全測試方法論（SAST、DAST、依賴審計）
+- `audit-trail`：一般 Audit Trail 標準
+- `mock-boundary`：測試中禁止 mock 安全控制
+
+
+**Scope**: universal

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

@@ -0,0 +1,113 @@
+---
+source: ../../../core/security-testing.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-08
+source_hash: 242e9016416c
+status: current
+---
+
+# 資安測試標準
+
+> **Language**: [English](../../../core/security-testing.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-06-19
+**適用範圍**: 所有軟體專案
+**Scope**: universal
+**產業標準**: OWASP Testing Guide v4, NIST SP 800-115, ISO/IEC 27001
+**參考資料**: OWASP Top 10, CWE/SANS Top 25
+
+---
+
+## 目的
+
+本文件定義軟體專案的資安測試方法論。它與 `security-standards.md`（架構層級的資安設計）互補，提供執行層級的指引：該執行哪些工具、何時執行、以及如何回應發現的問題。
+
+---
+
+## 四個資安測試層
+
+### 1. SAST — 靜態分析
+
+在不執行程式碼的情況下分析原始碼。於 pre-commit 與 CI 中執行。
+
+| 語言 | 工具 | 偵測項目 |
+|----------|------|---------|
+| TypeScript/JS | eslint-plugin-security | eval 注入、regex DoS、路徑遍歷 |
+| Python | bandit | SQL 注入、硬編碼憑證 |
+| Java | SpotBugs + FindSecBugs | SQL 注入、XSS |
+
+**閘門**: High/Critical → 阻擋 merge
+
+### 2. 相依套件稽核
+
+掃描第三方套件的已知 CVE。於 pre-push 與每週執行。
+
+| 生態系 | 工具 | 指令 |
+|-----------|------|---------|
+| Node.js | npm audit | `npm audit --audit-level=high` |
+| Python | pip-audit | `pip-audit` |
+
+**閘門**: High/Critical CVE → 阻擋發布（例外須記錄並附到期日）
+
+### 3. 機密掃描
+
+偵測不慎提交的機密資訊。於每次 commit 時執行。
+
+工具: gitleaks、truffleHog
+
+**閘門**: 偵測到任何機密 → 立即阻擋 commit
+
+### 4. DAST — 動態分析
+
+透過 HTTP 測試運行中的應用程式。於 staging 部署後執行。
+
+工具: OWASP ZAP、Nuclei
+
+**閘門**: High/Critical 發現 → 阻擋晉升至 production
+
+---
+
+## CVE 回應政策
+
+| 嚴重度 | 回應 |
+|----------|----------|
+| Critical | 24 小時內修補；阻擋所有部署 |
+| High | 下次發布前解決 |
+| Moderate | 14 天內解決 |
+| Low | 追蹤；於維護時段解決 |
+
+---
+
+## 發現事項修復生命週期
+
+上述各層負責偵測發現，CVE 政策則設定解決時限（SLA），但一個發現事項還需要一個**有負責人的生命週期**——否則「阻擋 merge」就是唯一定義好的動作，偵測之後的一切都沒有定義。每個資安發現（SAST / DAST / 機密 / 相依套件 CVE）都遵循以下狀態機。
+
+| 狀態 | 意義 | 負責人 | 結束條件 |
+|-------|---------|-------|----------------|
+| **Detected（已偵測）** | 由某一層（SAST/DAST/機密/稽核）提出 | 掃描閘門（CI） | 已指派嚴重度 |
+| **Triaged（已分診）** | 已確認嚴重度與有效性（真實 vs 誤判） | 資安審查者 | 真實 → 轉為 In-Progress；誤判 → 標記為 `suppressed` 並記錄理由 |
+| **In-Progress（處理中）** | 修復正在實作 | 受影響元件的程式碼負責人 | 修復已提交 |
+| **Resolved（已解決）** | 修復已合併 | 程式碼負責人 | 原掃描重新執行後乾淨無發現 |
+| **Verified（已驗證）** | 重新掃描確認發現已消失 | 掃描閘門（CI） | 發現事項關閉 |
+
+- **閘門**：任何 Critical/High 發現若狀態非 `Verified`（或 `Triaged → suppressed` 且附有理由），皆**阻擋發布**，與上述 CVE 回應政策的 SLA 一致。
+- **不得靜默關閉**：發現事項只能透過 `Verified`（重新掃描乾淨）或資安審查者明確記錄的 `suppressed` 決定離開此生命週期——絕不可透過刪除，也不可由修復作者自行核准關閉。
+
+---
+
+## 反模式
+
+- 將所有 CVE 視為同等緊急
+- 對 production 執行 DAST（應使用 staging）
+- 無限期忽略 `npm audit`
+- 在測試中 mock 身分驗證 middleware（見 mock-boundary.md）
+
+---
+
+## 與其他標準的關係
+
+- `security-standards`: 架構層級的控制措施（輸入驗證、身分驗證設計）
+- `mock-boundary`: 測試中絕不 mock 資安控制
+- `deployment-standards`: DAST 作為部署管線的一部分執行

package/bundled/locales/zh-TW/core/self-review-protocol.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/self-review-protocol.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-05-28
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-09
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/self-review-protocol.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-05-26
+**版本**: 1.1.0
+**最後更新**: 2026-07-09
 **適用範圍**: 所有軟體專案（新建、重構、遷移、維護）
 **範圍**: partial
 **業界標準**: ISO/IEC 25010（文件可維護性）、IEEE 1063-2001（軟體使用者文件）
@@ -24,7 +24,7 @@ status: current
 本標準規範大型 markdown 編輯**commit 前**必跑 **self-review**，捕捉內部 cross-reference 不一致 — 這類問題慣性被內部推理忽略，但完整 re-read 一次即可 surface。
 
 **與其他標準的關係**：
-- 與 [code-review.md](code-review.md) 互補（後者涵蓋程式碼變更）
+- 與 [code-review.md](code-review-checklist.md) 互補（後者涵蓋程式碼變更）
 - 與 [documentation-writing-standards.md](documentation-writing-standards.md) 互補（後者涵蓋內容創作）
 - 本標準專注於**大型 markdown 文件**（DEC、ADR、XSPEC、SKILL.md、規格文件、runbook 等）的**編輯後驗證**
 
@@ -34,7 +34,7 @@ status: current
 
 多次 Claude 輔助編輯 session（如 `dev-platform/.claude/skills/eval-source/SKILL.md` v1.1.0 → v1.1.1、v1.2.0 → v1.2.1）觀察到一致模式：**每次大型 markdown 編輯都引入 3-6 處小型內部不一致**，內部推理看不出來，但完整 re-read 立刻 surface。
 
-這些不一致歸納為 **6 大類**，且固定觸發後續 patch commit。在 commit 前加入強制 re-read 步驟後，此模式消失（eval-source v1.3.0 為首次無 patch follow-up 的 SKILL.md 變更）。
+這些不一致歸納為 **6 大類**，且固定觸發後續 patch commit。在 commit 前加入強制 re-read 步驟後，此模式消失（eval-source v1.3.0 為首次無 patch follow-up 的 SKILL.md 變更）。第 7 大類（語言與術語一致性）為後續因不同動機（跨對話 AI 輸出漂移，非原始 patch 週期模式）新增，詳見下方。
 
 ---
 
@@ -56,7 +56,7 @@ status: current
 
 ---
 
-## 6 類常見內部不一致
+## 7 類常見內部不一致
 
 ### 1. Diagram / Flow 與 step list 不同步
 **範例**：工作流程圖 7 格但文件實際定義 8 步驟
@@ -82,12 +82,16 @@ status: current
 **範例**：example 寫「D1/D2/D3」但 rule 明說 D3 不強制，且當前案例正好把 D3 降為後續追蹤
 **檢查**：example 中每個具體值是否與當前 rule 一致；example 不應與最新案例經驗矛盾
 
+### 7. 語言與術語一致性
+**範例**：雙語文件某段落中英文夾雜，或日文假名/韓文諺文混入繁體中文段落；或同一份文件內「XSPEC」「gate」「pipeline」等專案慣用術語寫法不一致
+**檢查**：掃描非目標語言文字是否出現在非預期段落（如日文假名 U+3040–U+30FF、韓文諺文 U+AC00–U+D7A3 混入 zh-TW 段落）、同段落語言混雜、以及同一檔案內既有慣用術語拼法是否一致
+
 ---
 
 ## 流程
 
 1. **edit 完成後、commit 前**，用 file-reading 工具重新讀過**完整檔案**（不只 diff）
-2. 依上方 6 類逐項對照
+2. 依上方 7 類逐項對照
 3. **發現問題** → 直接 Edit 修補後再 commit（同一 commit 包含修正，不要分開 ship）
 4. **若已 commit 才發現** → 新增 patch commit（如 v1.2.1 對 v1.2.0）
 
@@ -104,19 +108,19 @@ status: current
 ### ADR / DEC
 在 `## 後續追蹤` 表格新增一行：
 ```
-| Self-review pass | 本 DEC | ✅ YYYY-MM-DD (6 類無 issue) |
+| Self-review pass | 本 DEC | ✅ YYYY-MM-DD (7 類無 issue) |
 ```
 
 ### XSPEC SDD Delta
 在「不改動清單」section（如 §N.6）後追加：
 ```
-> Self-review pass: YYYY-MM-DD (6 類無 issue)
+> Self-review pass: YYYY-MM-DD (7 類無 issue)
 ```
 
 ### Commit message body
 最後一行附：
 ```
-Self-review (protocol v1.0.0): N issues found, M applied in same commit / 0 found.
+Self-review (protocol v1.1.0): N issues found, M applied in same commit / 0 found.
 ```
 
 ---
@@ -125,7 +129,7 @@ Self-review (protocol v1.0.0): N issues found, M applied in same commit / 0 foun
 
 | 實踐 | 涵蓋面向 | 觸發時機 |
 |---|---|---|
-| **Code Review**（[code-review.md](code-review.md)）| 程式碼正確性、設計、安全 | code PR merge 前 |
+| **Code Review**（[code-review.md](code-review-checklist.md)）| 程式碼正確性、設計、安全 | code PR merge 前 |
 | **內容自我審計**（如 eval-source skill 7 題）| 內容完整性（是否包含所有必要 section）| 每次文件產出 |
 | **Self-Review Protocol**（本標準）| 內部 cross-reference 一致性（形式，非內容）| 大型 markdown 編輯後、commit 前 |
 | **同儕審查** | 獨立視角、blast radius 評估 | 重要變更 |
@@ -164,3 +168,4 @@ Self-review (protocol v1.0.0): N issues found, M applied in same commit / 0 foun
 ## Self-Review Pass
 
 > Self-review pass: 2026-05-26 (6 類無 issue；本標準首稿同步 self-review)
+> Self-review pass: 2026-07-09（7 類無 issue —— 依 XSPEC-324 新增第 7 類「語言與術語一致性」）