universal-dev-standards 5.17.0 → 6.1.0

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

@@ -0,0 +1,120 @@
+---
+source: ../../../core/rollback-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: c3ace87126ca
+status: current
+---
+
+# Rollback Standards（回滾標準）
+
+> **語言**: [English](../../../core/rollback-standards.md) | 繁體中文
+
+---
+
+## 概述
+
+本標準定義回滾觸發條件矩陣、自動 vs 手動回滾決策流程，以及與錯誤預算的整合方式。確保每一次部署都有明確、可量化的回滾策略，而非依賴主觀判斷。
+
+---
+
+## 核心原則
+
+- **可量化觸發條件**：回滾觸發必須有明確的數值門檻，絕不使用「看起來有問題」等主觀描述
+- **三層決策模型**：自動回滾（Auto）→ 輔助回滾（Assisted）→ 手動回滾（Manual）
+- **錯誤預算整合**：當錯誤預算低於 10% 時，自動將輔助回滾升級為自動回滾
+- **強制事件記錄**：每次回滾都必須寫入部署日誌並觸發事故回應流程
+
+---
+
+## 觸發條件矩陣
+
+### 自動回滾（Auto-Rollback）
+
+系統自動執行，無需人工干預：
+
+| 指標 | 觸發門檻 |
+|------|---------|
+| 錯誤率 | > 2× 基線，持續 5 分鐘 |
+| 健康檢查失敗 | 連續 3 次 |
+| P99 延遲 | > 5× 基線，持續 3 分鐘 |
+
+### 輔助回滾（Assisted-Rollback）
+
+系統發出警報，由值班工程師確認後執行：
+
+| 條件 | 說明 |
+|------|------|
+| SLO 違反 | 非關鍵路徑的 SLO 違反 |
+| 錯誤預算剩餘 | < 10%（此時升級為自動回滾） |
+
+### 手動回滾（Manual-Rollback）
+
+由開發者評估後決定是否執行：
+
+| 條件 | 說明 |
+|------|------|
+| 延遲惡化 | 仍在 SLO 範圍內的效能下降 |
+| 外觀問題 | 使用者可見但不影響功能的問題 |
+
+---
+
+## 嚴重性矩陣
+
+| 等級 | 觸發方式 | 處理時限 | 通知對象 |
+|------|---------|---------|---------|
+| P0 | 自動 | < 2 分鐘 | 全體相關人員 |
+| P1 | 自動 | < 5 分鐘 | 值班工程師 |
+| P2 | 輔助 | < 15 分鐘 | 團隊主管 |
+| P3 | 手動 | < 1 小時 | 開發者 |
+
+---
+
+## 錯誤預算整合
+
+當錯誤預算剩餘 < 10% 時：
+
+1. 輔助回滾自動升級為自動回滾
+2. 觸發事故事件記錄
+3. 暫停後續部署，直到預算恢復
+
+---
+
+## 回滾方法比較
+
+| 方法 | 執行時間 | 風險 | 前置條件 |
+|------|---------|------|---------|
+| Blue-Green 切換 | < 30 秒 | 低 | 雙環境基礎設施 |
+| Feature Flag 關閉 | < 5 秒 | 極低 | Feature Flag 系統 |
+| DNS 切換 | 60-120 秒 | 中 | 多區域設定 |
+| 程式碼 Revert | 數分鐘 | 中 | 乾淨的 git 歷史 |
+| 資料庫還原 | 數小時 | 高 | 已驗證的備份 |
+
+---
+
+## 回滾前後檢查清單
+
+### 回滾前（Pre-Rollback）
+
+- [ ] 確認回滾目標版本是健康的
+- [ ] 確認資料庫遷移向後相容
+- [ ] 通知相關利害關係人
+
+### 回滾後（Post-Rollback）
+
+- [ ] 確認健康檢查在目標版本通過
+- [ ] 將回滾事件寫入部署日誌
+- [ ] 開立事故單進行根因分析
+- [ ] 更新錯誤預算追蹤
+
+---
+
+## 相關標準
+
+- [deployment-standards.md](../../../core/deployment-standards.md) — 部署基礎策略
+- [cd-deployment-strategies.md](../../../core/cd-deployment-strategies.md) — 部署策略選用矩陣
+- AI 格式：[../ai/standards/rollback-standards.ai.yaml](../../../ai/standards/rollback-standards.ai.yaml)
+
+
+**Scope**: universal

package/bundled/locales/zh-TW/core/runbook.md

@@ -0,0 +1,110 @@
+---
+source: ../../../core/runbook.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: 443fb8c4e692
+status: current
+---
+
+# Runbook 撰寫標準
+
+> **Language**: [English](../../../core/runbook.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/runbook.ai.yaml`
+> **規格**: XSPEC-063（cross-project/specs/XSPEC-063-uds-sre-standards-pack.md）
+
+## 概觀
+
+本標準定義運維 **runbook** 如何撰寫、組織、維護與測試。涵蓋必備章節、撰寫原則
+（可重現、無歧義的步驟）、目錄結構、檢視節奏，以及演練頻率。撰寫良好的 runbook
+能讓任何 on-call 工程師無需 tribal knowledge 即可執行復原步驟，藉此降低 Mean Time
+To Repair（MTTR）。
+
+本標準屬於 **SRE／運維標準包**（XSPEC-063），是與 `incident-response`（runbook 於
+mitigate 階段執行）與 `slo-sli`（error budget 政策由 runbook 連結）並列的可執行
+復原成員。它補充既有的 `runbook-standards` Skill 錨點；UDS 的獨特貢獻在於可由
+VibeOps Governance Agent（DEC-042）直接執行的 AI 可執行 runbook schema。
+
+> **範圍**：本標準定義「runbook 必須包含什麼，以及如何組織、檢視與演練」。runbook
+> 託管工具（wiki、Git repo、PagerDuty）與自動化引擎屬採用者的選擇，不在本標準
+> 範圍內。
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | 必備 runbook 章節（overview → post-actions） | MUST |
+| REQ-002 | 可重現且無歧義的步驟（可複製貼上 + 驗證） | MUST |
+| REQ-003 | Runbook 命名與目錄組織（typed dir、kebab-case） | MUST |
+| REQ-004 | 檢視與演練節奏（依類型） | MUST |
+| REQ-005 | Rollback 與 fallback 步驟（標示清楚、置於升級前） | MUST |
+| REQ-006 | 告警整合 metadata（alert 名稱、dashboard、query） | SHOULD |
+
+### REQ-001 — 必備 Runbook 章節
+
+每個 runbook MUST 依序包含下列章節：(1) **Overview**——alert 名稱、severity、
+受影響服務、owner、最後更新、最後演練日期；(2) **Symptoms**——可觀察的指標；
+(3) **Impact Assessment**——面向使用者的影響與 blast radius；(4) **Diagnostic
+Steps**——附可複製貼上指令的有序步驟；(5) **Fix Steps**——每步皆附驗證的有序
+修復；(6) **Escalation**——附角色與可用時段的具體聯絡人；(7) **Post-Actions**——
+後續任務、ticket、postmortem 觸發。
+
+### REQ-002 — 可重現且無歧義的步驟
+
+runbook 中的每個步驟 MUST 可重現且無歧義。步驟 MUST 使用可複製貼上的指令，且不
+留下任何未定義的 placeholder。決策點 MUST 包含明確的分支條件（if X then Y, else
+Z）。每個 fix 步驟 MUST 包含一個驗證指令，確認修復生效後才繼續，且 MUST 顯示預期
+輸出。
+
+### REQ-003 — Runbook 命名與目錄組織
+
+Runbook MUST 使用描述「問題」而非「解法」的 kebab-case 名稱。檔案 MUST 組織進
+typed 目錄：`alerts/` 放 alert-response runbook、`operations/` 放標準運維、
+`emergency/` 放重大事件程序、`troubleshooting/` 放一般調查指南。每個 runbook 檔
+MUST 在 front matter 宣告其類型。
+
+### REQ-004 — 檢視與演練節奏
+
+Runbook MUST 依類型按排程檢視：alert-response runbook 每季、emergency 程序每月、
+標準運維與 troubleshooting 指南每半年、change 程序在每次使用後。Runbook MUST 演練：
+P1 runbook 每月、P2 每季、emergency 程序每季。演練紀錄 MUST 附加於 runbook 或由其
+連結。
+
+### REQ-005 — Rollback 與 Fallback 步驟
+
+任何描述變更或修復的 runbook MUST 包含一個標示清楚的 rollback 章節，說明若修復失敗
+或造成額外問題時如何復原變更。Rollback 章節 MUST 出現在 escalation 章節之前，並
+包含其自身的驗證步驟。
+
+### REQ-006 — 告警整合 Metadata
+
+Alert-response runbook SHOULD 包含一個 metadata 區塊，將 runbook 連結至特定 alert
+規則。這讓告警工具（PagerDuty、Alertmanager）能自動連結 runbook。Metadata MUST
+包含 alert 名稱、dashboard URL，以及用於調查的 Prometheus／logging query。
+
+## 與既有標準的整合
+
+- **`runbook-standards`**——既有的 Skill 錨點標準；`runbook` 提供其背後的 AI 可
+  執行 schema 與章節／演練要求。
+- **`incident-response`**——runbook 於事件 mitigate 階段執行；SEV runbook 依此處
+  節奏演練。
+- **`slo-sli`**——error budget 政策 MUST 由服務 runbook 連結。
+- **`rollback-standards`**——REQ-005 rollback 步驟與 rollback 標準的復原程序對齊。
+- **`alerting-standards`**——REQ-006 metadata 將 alert 規則連結至其 runbook。
+- **`execution-history`**——當 runbook 標記 `automation_level: automated` 時，
+  Governance Agent 的執行結果記錄為 execution history。
+
+## 相關規格
+
+- XSPEC-063 — UDS SRE／運維標準包（本標準來源）
+- XSPEC-251 — Operator 主動可靠性（runbook 責任）
+- DEC-042 — Guardian / Governance Agent 模式（agent 執行 `automated` runbook）
+- DEC-041 — EU AI Act 2026 合規（可稽核的復原程序）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~006：必備章節、可重現步驟、命名/組織、檢視/演練節奏、rollback/fallback、告警整合 metadata（XSPEC-063） |

package/bundled/locales/zh-TW/core/sast-advanced.md

@@ -0,0 +1,309 @@
+---
+source: ../../../core/sast-advanced.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: aa3d9f9ad760
+status: current
+---
+
+# 進階 SAST 標準
+
+> **語言**: [English](../../../core/sast-advanced.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-05-05
+**適用範圍**: TypeScript / JavaScript 專案
+**Scope**: universal
+**參考資料**: [CodeQL 文件](https://codeql.github.com/)、[gitleaks](https://github.com/gitleaks/gitleaks)、[Biome linter](https://biomejs.dev/)
+
+---
+
+## 目的
+
+本標準定義進階靜態應用程式安全測試（SAST）實踐，作為依賴項稽核（`npm audit`）的補充。涵蓋三個獨立但互補的層次：
+
+1. **CodeQL 語意分析** — 找出第一方程式碼中的注入漏洞
+2. **Secret 掃描** — 防止提交 API 金鑰與憑證
+3. **Biome 安全 lint 規則** — 在編輯器和 CI 層面強制執行安全的程式碼模式
+
+---
+
+## 為什麼 npm audit 不夠用
+
+`npm audit` 會對照 NPM 諮詢資料庫掃描你的 `package-lock.json`，它只能找出**第三方依賴中已知的 CVE**。
+
+它**無法**找出：
+
+| 漏洞類型 | 範例 | 偵測方法 |
+|---|---|---|
+| **命令注入** | `exec(\`git log ${userInput}\`)` | CodeQL 資料流分析 |
+| **路徑穿越** | `fs.readFile(path.join(base, req.params.file))` | CodeQL 資料流分析 |
+| **原型污染** | `target[req.body.key] = req.body.value` | CodeQL 污點分析 |
+| **XSS（透過 DOM sink）** | `element.innerHTML = userContent` | CodeQL 資料流分析 |
+| **SQL 注入** | `db.query("SELECT * FROM users WHERE id = " + id)` | CodeQL 資料流分析 |
+| **硬編碼 secret** | `const apiKey = "sk-live-abc123..."` | gitleaks 模式比對 |
+
+---
+
+## 第一層：CodeQL 語意分析
+
+### CodeQL 的作用
+
+CodeQL 會建構你的 TypeScript 程式碼的語意模型，然後執行查詢，追蹤從**來源**（使用者輸入、請求參數、環境變數）到**接收點**（命令執行、檔案系統存取、DOM 操作）的資料流。
+
+### GitHub Actions 工作流程
+
+建立 `.github/workflows/codeql.yml`：
+
+```yaml
+# SPDX-License-Identifier: MIT
+name: CodeQL Analysis
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+  schedule:
+    - cron: '0 2 * * 1'   # 每週一 02:00 UTC
+
+jobs:
+  analyze:
+    name: Analyze TypeScript
+    runs-on: ubuntu-latest
+    permissions:
+      actions: read
+      contents: read
+      security-events: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v3
+        with:
+          languages: javascript-typescript
+          queries: security-extended
+          query-filters: |
+            - include:
+                tags contain: security
+
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v3
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v3
+        with:
+          category: "/language:javascript-typescript"
+```
+
+### 關鍵設定選項
+
+| 選項 | 值 | 原因 |
+|---|---|---|
+| `languages` | `javascript-typescript` | 涵蓋 `.ts` 與 `.js` 檔案 |
+| `queries` | `security-extended` | 包含預設集中未涵蓋的注入/XSS/路徑穿越查詢 |
+| `schedule` | `0 2 * * 1` | 每週抓取 GitHub 發布的新查詢包 |
+| `security-events: write` | 必填 | 將 SARIF 結果上傳至 GitHub Security 分頁 |
+
+### 分支保護設定
+
+新增工作流程後，設定分支保護規則：
+
+1. Settings → Branches → Branch protection rules → Edit main
+2. 啟用「Require status checks to pass before merging」
+3. 將 `CodeQL` 與 `sast` 加入必要檢查項目
+
+---
+
+## 第二層：使用 gitleaks 掃描 Secret
+
+### gitleaks 能偵測什麼
+
+gitleaks 使用模式比對與熵分析來偵測：
+- AWS 存取金鑰（`AKIA[0-9A-Z]{16}`）
+- GitHub token（`ghp_`、`gho_`、`ghs_`、`ghr_`）
+- 私鑰 PEM 區塊（`-----BEGIN RSA PRIVATE KEY-----`）
+- 符合憑證模式的高熵字串
+- 定義於 `.gitleaks.toml` 的自訂模式
+
+### CI 整合
+
+在你的 CI 工作流程中加入 `sast` 工作：
+
+```yaml
+sast:
+  name: Secret Scanning
+  runs-on: ubuntu-latest
+  steps:
+    - uses: actions/checkout@v4
+      with:
+        fetch-depth: 0   # 完整歷史以確保準確掃描
+    - name: Run gitleaks
+      uses: gitleaks/gitleaks-action@v2
+      env:
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+### `.gitleaks.toml` 設定範例
+
+```toml
+title = "Gitleaks Configuration (example)"
+version = "8"
+
+[extend]
+# 從 gitleaks 基礎設定繼承預設規則
+useDefault = true
+
+[[rules]]
+id = "app-license-key"
+description = "App license key"
+regex = '''app[_\-]?license[_\-]?key\s*[:=]\s*["']?([A-Za-z0-9\-]{32,})["']?'''
+severity = "CRITICAL"
+tags = ["license", "app"]
+
+[[allowlist.commits]]
+# 範例：允許已修復的特定 commit hash
+# commits = ["abc1234"]
+
+[[allowlist.regexes]]
+# 將測試 fixture 值加入白名單
+description = "Test fixture placeholder keys"
+regex = '''PLACEHOLDER_KEY_FOR_TESTING'''
+```
+
+### 處理誤報（False Positives）
+
+當 gitleaks 標記誤報時：
+
+1. 找出觸發比對的確切模式
+2. 在 `.gitleaks.toml` 中加入有針對性的 `allowlist.regexes` 條目，並附上說明
+3. 在被標記的值旁邊加上程式碼註解，記錄允許原因
+4. 每季審查所有白名單條目
+
+---
+
+## 第三層：Biome 安全規則
+
+### 為什麼選擇 Biome 而不是 ESLint
+
+採用 Biome 作為 linter 的專案，無需額外安裝 ESLint 套件，即可獲得內建的安全相關規則。Biome 中的關鍵安全規則：
+
+| 規則 | 類別 | 防止的問題 |
+|---|---|---|
+| `suspicious/noGlobalEval` | suspicious | 透過 `eval()` 動態執行程式碼 |
+| `suspicious/noWith` | suspicious | 透過 `with` 陳述式污染作用域 |
+| `suspicious/noConsoleLog` | suspicious | 透過 `console.log` 意外記錄 secret |
+| `correctness/noUnusedVariables` | correctness | 可能包含敏感邏輯的廢棄程式碼 |
+| `security/noBlankTarget` | security | 未加 `rel="noopener"` 的 `target="_blank"` 分頁劫持 |
+
+### `biome.json` 設定
+
+```json
+{
+  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
+  "linter": {
+    "enabled": true,
+    "rules": {
+      "recommended": true,
+      "suspicious": {
+        "noGlobalEval": "error",
+        "noWith": "error"
+      },
+      "security": {
+        "noBlankTarget": "error"
+      }
+    }
+  }
+}
+```
+
+### CI 整合
+
+```yaml
+- name: Lint (Biome)
+  run: npm run lint   # 對應：biome check .
+```
+
+`biome check .` 指令會同時執行格式檢查與 linter 規則。安全規則失敗會產生非零退出碼，阻擋 CI 流程。
+
+---
+
+## 品質閘門門檻
+
+| 嚴重性 | 合併政策 | 修復 SLA |
+|---|---|---|
+| **CRITICAL** | 阻擋合併，無例外 | 立即處理 |
+| **HIGH** | 阻擋合併，main 分支 HIGH 為零 | 立即處理 |
+| **MEDIUM** | 不阻擋；建立追蹤 issue | 30 天 |
+| **LOW** | 不阻擋；記錄以供查閱 | 選擇性 |
+
+### 設定 GitHub Code Scanning 阻擋政策
+
+在儲存庫安全性設定中：
+1. Security → Code scanning → Protection rules
+2. 將「Security severity level」設定為「High or higher」
+3. 這會在 CodeQL 回報任何 HIGH 或 CRITICAL 問題時阻擋 PR 合併
+
+---
+
+## npm test 整合
+
+在 `package.json` 中加入 `test:sast` 腳本作為開發者入口：
+
+```json
+{
+  "scripts": {
+    "test:sast": "npm audit --audit-level=high"
+  }
+}
+```
+
+這允許透過 `npm run test:sast` 執行本地推送前檢查。注意：此指令只涵蓋依賴項漏洞；完整的 SAST 管線在 CI 中執行。
+
+---
+
+## 總結：縱深防禦安全掃描
+
+```
+Commit → pre-push hook (npm audit)
+  │
+  └─→ CI: sast job (gitleaks secret scan)
+  │
+  └─→ CI: check job (biome lint — security rules)
+  │
+  └─→ CI: codeql.yml (semantic analysis — injection/XSS/traversal)
+  │
+  └─→ GitHub Code Scanning (SARIF results — blocks PR on HIGH+)
+```
+
+沒有任何單一掃描器能抓到所有問題。這種分層方式提供：
+- **依賴項漏洞**：npm audit（快速，每次推送）
+- **提交的 secret**：gitleaks（每次推送，完整歷史）
+- **程式碼品質/安全**：Biome 規則（每次提交，編輯器即時回饋）
+- **第一方漏洞**：CodeQL（深度分析，PR 及每週）
+
+---
+
+## 相關標準
+
+- [安全標準](../../../core/security-standards.md)
+- [Secret 管理標準](../../../core/secret-management-standards.md)
+- [Check-in 標準](../../../core/checkin-standards.md)
+- [容器安全](../../../core/container-security.md)
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更內容 |
+|---|---|---|
+| 1.0.0 | 2026-05-05 | 初始發布（XSPEC-161） |
+
+---
+
+## 授權
+
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權釋出。

package/bundled/locales/zh-TW/core/schema-evolution.md

@@ -0,0 +1,98 @@
+---
+source: ../../../core/schema-evolution.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: 0e8f6242bf38
+status: current
+---
+
+# Schema 演進標準
+
+> **Language**: [English](../../../core/schema-evolution.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/schema-evolution.ai.yaml`
+> **規格**: XSPEC-068（cross-project/specs/XSPEC-068-uds-data-engineering-pack.md）
+
+## 概觀
+
+本標準定義資料庫與資料儲存的 schema 如何**安全演進**而不破壞既有消費者。涵蓋向後
+相容變更樣態、禁止的破壞性變更、expand-contract 遷移策略、schema 版本化與 registry、
+CI 中的自動相容性檢查，以及回滾程序。適用於關聯式資料庫、文件儲存、事件 schema
+（Avro/Protobuf）與 API request/response schema。
+
+本標準屬於**資料工程標準包**（XSPEC-068），以安全演進規則延伸 `database-standards`
+的靜態 schema 定義。
+
+> **範圍**：本標準定義*相容性分類*、*expand-contract* 部署紀律與 CI 閘控。具體遷移
+> 工具（Flyway/Liquibase）與 schema registry（Confluent）屬採用者的選擇。
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | 向後相容變更樣態 | MUST |
+| REQ-002 | 無遷移計劃禁止破壞性變更 | MUST |
+| REQ-003 | Expand-contract 遷移策略 | MUST |
+| REQ-004 | Schema 版本化與 registry | MUST |
+| REQ-005 | CI 中的自動 schema 相容性檢查 | MUST |
+| REQ-006 | Schema 變更回滾程序 | MUST |
+
+### REQ-001 — 向後相容變更樣態
+
+所有 schema 變更 MUST 向後相容，除非遵循正式的破壞性變更流程。向後相容變更包含：
+新增帶預設值的可空欄位、新增表／collection、新增可選訊息欄位、新增 enum 值（含
+未知處理）、放寬資料型別（INT → BIGINT），以及新增索引。這些變更 MUST 可在不協調
+消費者更新的情況下部署。
+
+### REQ-002 — 無遷移計劃禁止破壞性變更
+
+下列分類為 **BREAKING**，未經正式 expand-contract 遷移計劃與消費者協調 MUST NOT
+部署：重新命名或刪除欄位、不相容地變更資料型別、對既有欄位加上無預設值的 NOT
+NULL、變更主鍵／外鍵定義、移除 enum 值，以及變更欄位語意（將欄位挪作他用）。
+
+### REQ-003 — Expand-Contract 遷移策略
+
+破壞性變更 MUST 使用 **expand-contract**（平行變更）樣態：**Phase 1（Expand）**在舊
+結構旁新增新結構；**Phase 2（Migrate）**將舊資料回填至新結構並更新所有 writer；
+**Phase 3（Contract）**將所有 reader 更新至新結構；**Phase 4（Cleanup）**在所有
+消費者更新後移除舊結構。每階段 MUST 為獨立且經驗證的部署。階段間最短等待：一個
+完整部署週期。
+
+### REQ-004 — Schema 版本化與 Registry
+
+事件驅動與 API schema（Avro、Protobuf、JSON Schema）MUST 以明確版號註冊於 schema
+registry，並遵循語意版本：PATCH 用於向後相容新增、MINOR 用於新可選欄位、MAJOR 用於
+破壞性變更。每次 schema 變更 MUST 在註冊前審查核准。消費者 MUST 指定其消費的 schema
+版本。
+
+### REQ-005 — CI 中的自動 Schema 相容性檢查
+
+每個修改 schema 定義的 PR MUST 在 CI 觸發自動相容性檢查。對關聯式 schema，遷移腳本
+MUST 在 CI 對 production-snapshot 資料庫執行以在合併前偵測錯誤。對事件 schema，
+MUST 針對所有已註冊消費者版本檢查相容性。相容性失敗 MUST 阻擋 PR 合併。
+
+### REQ-006 — Schema 變更回滾程序
+
+每個遷移腳本 MUST 具備對應的回滾（down）腳本。回滾腳本 MUST 在 CI 與正向遷移一同
+測試。對破壞性變更（drop、型別變更），MUST 在執行前進行並驗證資料備份。回滾計劃
+MUST 記載於遷移 PR 並在部署 runbook 中引用。
+
+## 與既有標準的整合
+
+- **`database-standards`**——本標準在靜態 schema 定義之上加入*演進*紀律。
+- **`data-contract`**——MAJOR schema 版本對映 contract 破壞性變更治理與消費者簽核。
+- **`data-pipeline`**——管線須依 REQ-001 容忍來源的向後相容變更。
+- **`deployment-standards`**——expand-contract 各階段為獨立部署；回滾計劃置於部署
+  runbook。
+
+## 相關規格
+
+- XSPEC-068 — UDS 資料工程標準包（本標準來源）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~006：向後相容樣態、禁止破壞性變更、expand-contract、版本化／registry、CI 相容性檢查、回滾（XSPEC-068） |