universal-dev-standards 5.14.0 → 5.16.0

package/bundled/locales/zh-TW/core/cross-flow-regression.md

@@ -1,11 +1,198 @@
 ---
 source: ../../../core/cross-flow-regression.md
 source_version: 1.0.0
-translation_version: 0.0.0
-last_synced: 2026-05-05
+translation_version: 1.0.0
+last_synced: 2026-06-02
+source_hash: 2f7bdbe6dc36
 ---
 
-<!-- TODO: 待完整繁體中文翻譯 — Translation pending -->
-<!-- See source: core/cross-flow-regression.md -->
+# 跨流程回歸（Cross-Flow Regression）
 
-> 此標準尚未完整翻譯。請參閱英文原文：[English](../../../core/cross-flow-regression.md)
+> **語言**：[English](../../../core/cross-flow-regression.md) | 繁體中文
+
+**版本**：1.0.0
+**最後更新**：2026-05-05
+**適用範圍**：所有具有多個 user flow 或業務流程的軟體專案
+**Scope**：universal
+**業界標準**：ISTQB Advanced Test Analyst（Regression Test Strategy）
+**參考資料**：`core/flow-based-testing.md`、`core/testing-standards.md`
+
+---
+
+## 目的
+
+本標準定義跨流程回歸測試（cross-flow regression testing）——驗證對某一個 flow 的修改不會破壞其他 flow，並確保**多個 flow 的組合**在依序執行時行為正確。
+
+### 與 `flow-based-testing.md` 的界線
+
+| 標準 | 範圍 | 它能捕捉的問題 |
+|----------|-------|----------------|
+| `flow-based-testing.md`（Multi-Gate Model） | 單一 flow：Decision Points、Terminal States、Decision Table | flow 內部的分支覆蓋缺口 |
+| **本標準** | 多個 flow：互動、共享狀態、依序組合 | flow 之間的污染、累積狀態 bug、跨 flow 的回歸 |
+
+這兩者是互補而非重疊的關係。一個專案兩者都需要。
+
+---
+
+## 為何跨流程 bug 與眾不同
+
+flow 內部測試（Multi-Gate）能證明「Login」處理了全部 7 種 terminal state。但它無法偵測：
+
+- **狀態污染（State contamination）**：在一次失敗的「Create Order」（FAIL_QUOTA_EXCEEDED）之後，quota 計數器遭到破壞 → 即使 quota 已重置，下一次「Create Order」嘗試仍然失敗
+- **共享資源衝突（Shared resource conflicts）**：「Report Generation」與「Data Export」同時執行時，破壞了共用的暫存目錄
+- **依序相依（Sequential dependency）**：「Cancel Subscription」成功，但後續的「Reactivate」flow 假設訂閱仍然存在 → NullPointerException
+
+---
+
+## 跨流程 Test Suite 定義
+
+### Tier-1：Critical User Journeys（CUJ，關鍵使用者旅程）
+
+Critical User Journeys 是橫跨 ≥ 2 個 flow 的端到端序列，代表核心業務價值路徑。每一次 release 都必須包含一套 CUJ regression suite。
+
+**CUJ 識別**：
+1. 列出所有 flow（來自 requirement-template §2.4）
+2. 找出共享狀態或常被依序執行的 pair／triple（成對／三組組合）
+3. 標記業務關鍵的組合（purchase、onboarding、authentication + 下游流程）
+
+**CUJ 覆蓋率要求**：
+
+| 指標 | Tier-2 門檻（預設） | Tier-1 關鍵路徑 |
+|--------|--------------------------|---------------------|
+| CUJ 通過率 | ≥ 95% | 100% |
+| 業務關鍵 flow 組合 | 100% | 100% |
+
+### Tier-2：flow 變更時的回歸
+
+當任何 flow 的 §2.4（Decision Points、Terminal States）被修改時，整套 CUJ suite 必須重新執行——而不只是執行被修改 flow 的測試。觸發邏輯：
+
+```bash
+# In CI: detect flow spec changes
+changed_flows=$(git diff origin/main... --name-only | grep -E "requirement-template|SPEC.*\.md")
+if [ -n "$changed_flows" ]; then
+  npm run test:cross-flow-regression
+fi
+```
+
+### Tier-3：並行與共享資源測試
+
+針對具有並行使用者操作的專案：
+- 兩位使用者同時執行相同的 flow
+- Flow A 與 Flow B 共用一個寫入資源
+- 長時間執行的 flow（非同步）與短 flow 的結果互動
+
+---
+
+## 測試結構
+
+跨流程回歸測試採用跨 flow 的**依序狀態穿引（sequential state threading）**（延伸自 `flow-based-testing.md` 的 `ctx` 模式）：
+
+```typescript
+describe("CUJ: Register → Verify Email → Create First Order", () => {
+  const ctx: {
+    userId?: string
+    token?: string
+    orderId?: string
+  } = {}
+
+  // Flow 1: Register
+  it("Flow-1 Step 1: Register new user", async () => {
+    ctx.userId = await registerUser({ email: testEmail, plan: "trial" })
+    expect(ctx.userId).toBeDefined()
+  })
+
+  // Flow 2: Email Verification (depends on Flow 1 output)
+  it("Flow-2 Step 1: Verify email token", async () => {
+    const token = await getEmailToken(ctx.userId!)
+    ctx.token = await verifyEmail(token)
+    expect(ctx.token).toBeDefined()
+  })
+
+  // Flow 3: Create Order (depends on Flow 2 auth token)
+  it("Flow-3 Step 1: Create first order", async () => {
+    ctx.orderId = await createOrder(ctx.token!, orderPayload)
+    expect(ctx.orderId).toMatch(/^ord-/)
+  })
+
+  // Cross-flow verification: order state reflects trial plan limits
+  it("Cross-flow: Trial plan quota enforced on first order", async () => {
+    const order = await getOrder(ctx.token!, ctx.orderId!)
+    expect(order.quota_applied).toBe("trial")
+  })
+})
+```
+
+### 跨流程失敗隔離
+
+當一個跨流程測試失敗時，失敗訊息必須指出是**哪一個 flow** 引入了狀態破壞：
+
+```typescript
+// BAD: generic assertion
+expect(result).toBe("success")
+
+// GOOD: includes flow context
+expect(result).toBe("success")  // Flow-3 depends on Flow-2 token being valid
+                                 // If this fails, check Flow-2 email verification output
+```
+
+---
+
+## 與 Release Gate 的整合
+
+跨流程回歸是 `release-readiness-gate.md` 中的 **Dimension 6**（Tier-2）。
+
+### 觸發條件
+
+| 觸發時機 | 範圍 |
+|---------|-------|
+| 每一個 release candidate | 整套 CUJ suite |
+| 修改任何 flow §2.4 的 PR | 整套 CUJ suite（merge 前） |
+| 部署至 staging 後 | CUJ 的 smoke 子集 |
+| 部署至 production 後 | 僅關鍵路徑 CUJ（canary） |
+
+### Sign-off 的證據
+
+```
+| 6 | Cross-flow Regression | PASS | CUJ suite: 47/47 passed; 0 flow-interaction failures | QA Lead |
+```
+
+### WARN 門檻
+
+- CUJ 通過率 ≥ 95% 但 < 100% → WARN，並需記錄具體失敗的 CUJ 並完成 root-cause（根因分析）
+- CUJ 通過率 < 95% → FAIL（release 被封鎖）
+- 業務關鍵組合失敗 → FAIL，無論整體通過率如何
+
+---
+
+## 反模式（Anti-Patterns）
+
+- **只在 CI 緩慢時才跑跨流程測試**——依定義，它們必須在每一個 release candidate 上執行
+- **孤立地測試每個 flow 卻稱之為「regression」**——flow 的孤立測試已由 Multi-Gate 涵蓋；跨流程測試必須具備 flow 之間的狀態相依關係
+- **在不相關的 `describe` 區塊間重複使用同一個 `ctx` 物件**——每個 CUJ 都需要乾淨、隔離的 `ctx`；CUJ 之間的污染會掩蓋 bug
+- **失敗訊息中缺乏 flow 歸屬（attribution）**——跨流程失敗難以除錯；務必指出是哪個上游 flow 產生了被破壞的狀態
+- **把 CUJ 失敗當成 flaky（不穩定）**——跨流程狀態 bug 是確定性的；「flaky」的跨流程測試幾乎都是共享狀態破壞的徵兆
+
+---
+
+## 與其他標準的關係
+
+- **`flow-based-testing.md`** —— flow 內部的 gate（跨流程的前置條件）
+- **`testing-standards.md`** —— testing pyramid 中的 regression 層
+- **`release-readiness-gate.md`** —— Dimension 6（Tier-2）
+- **`e2e-testing.md`** —— CUJ 測試通常在 E2E 或 System Test 層級執行
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | 初版發布：CUJ 定義、依序狀態穿引、release gate 標準、Tier-1/2/3 分類 |
+
+---
+
+## 授權
+
+本標準依 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
+
+**來源**：[universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)

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

@@ -333,6 +333,25 @@ spec-review → forward-derivation → discovery
 
 ---
 
+## 終端投影：使用者指南
+
+推演鏈不止於測試。**使用者指南是同一條鏈的終端投影**——E2E／旅程測試以機器驗證的那條作業流程，其供人閱讀的視圖。「使用者讀到的操作步驟」與「E2E 實際驗證的行為」因此成為一個被維持的不變量。
+
+- **單一真實來源**：SPEC 的驗收條件（AC）。所有下游產物——BDD 場景、TDD／IT／E2E 骨架、ATDD 表格、契約，**以及使用者指南**——都是同一條 AC 主幹的投影。使用者指南不是另一個要互相對照的來源，而是又一個投影。
+- **僅限 user-facing AC**：唯有**終端使用者可直接觀察或操作**的 AC（UI 流程、CLI 指令、對外 API 的使用者語意）才需要使用者指南步驟。純內部 AC（重構、內部模組契約、效能門檻、安全內控）無使用者指南義務。**判不準時一律歸 user-facing**——保守預設；必須明確標記才能排除。
+- **共用編號（`T-NNN`）**：每個使用者指南步驟標 `T-NNN`，且該 `T-NNN` 必須是某個真實 journey／E2E 測試的 id。使用者指南與 E2E 套件是同一作業流程的兩個投影、共用一把尺。模稜兩可或未標記一律報為**未覆蓋**（寧可冗餘不要遺漏）。
+  - ✅ 使用者指南步驟 `T-012「建立專案」` ↔ journey spec 中的 E2E 測試 `T-012`。
+  - ❌ 使用者指南自造 `UG-3` 卻無對應測試 → drift，報為未覆蓋。
+- **Drift 反例**：使用者指南寫「2-click checkout」、E2E 卻仍驗「3-step payment」——沒有共用編號就無人察覺。共用 `T-NNN` 把這種 drift 變成被報出的覆蓋缺口。
+
+### 單一主幹原則（非平行對照）
+
+測試與文件來源是**同一條 AC 主幹的多層投影**，不是互相對照的獨立真實來源。TDD／IT／E2E 是同一主幹的金字塔**層級**（依 AC 性質分層），非彼此競爭的來源。兩兩對照 N 個來源（N×N）會滋生 drift；把每個產物投影回單一 AC 主幹（N×1）則消除它。
+
+> **規則**：每個測試或文件產物都必須回溯到某個 AC。另立**平行編號體系**——一條脫離 AC 主幹的第二套 `T-NNN` 系列——即為違規。只有一把尺：AC 主幹，且 `T-NNN` 由 journey／E2E 測試與使用者指南共用。
+
+---
+
 ## 命令
 
 ### 命令參考

package/bundled/locales/zh-TW/core/knowledge-graph-memory.md

@@ -0,0 +1,127 @@
+---
+source: ../../../core/knowledge-graph-memory.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-05-30
+status: current
+---
+
+# Knowledge Graph Memory Standards（知識圖記憶標準）
+
+> **語言**: [English](../../../core/knowledge-graph-memory.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-05-30
+**適用範圍**: 在「程式碼 + 規格／決策」語料上使用 AI 助手的專案
+**Scope**: uds-specific
+
+---
+
+## 目的
+
+本標準定義一套**關係 schema**，讓規格、決策與程式碼能以圖的方式遍歷——回答如*「我若修改 `execute()`，會影響哪些規格與決策？」*的問題。它與向量／語意記憶（找出*相似*的產物）互補，提供**結構遍歷**（找出*有關聯*的產物）。
+
+此 schema 與引擎無關：以純 Markdown front-matter 表達，AI 助手可直接讀取（降級模式），亦可由可選的圖引擎（如 [EngramGraph](https://github.com/AsiaOstrich/EngramGraph)）索引以進行多跳查詢（服務模式）。
+
+---
+
+## 快速參考
+
+### 關係 Front-Matter Schema
+
+在規格／決策文件的 YAML front-matter 中加入以下可選欄位：
+
+| 欄位 | 型別 | 方向 | 意義 |
+|------|------|------|------|
+| `related` | id 列表 | 無向 | 鬆散關聯的產物 |
+| `impacts` | spec id 列表 | this → spec | 此決策改動那些規格 |
+| `impacted_by` | decision id 列表 | decision → this | 那些決策改動此規格 |
+| `supersedes` | decision id 列表 | this → decision | 此決策取代那些決策 |
+| `implements` | spec id 列表 | code/spec → spec | 此產物實作那些規格 |
+
+id 為產物識別碼（如 `XSPEC-205`、`DEC-062`、`ADR-001`）。內文的 `[[XSPEC-NNN]]` wiki 連結是等效但較低保真度的訊號。
+
+### 節點種類
+
+| 前綴 | 節點種類 |
+|------|---------|
+| `XSPEC-*` / `SPEC-*` | Spec |
+| `DEC-*` / `ADR-*` | Decision |
+| 函式／類別／模組（來自程式碼）| Code 節點 |
+
+---
+
+## 1. Schema
+
+### 1.1 Front-Matter 範例
+
+```markdown
+---
+id: XSPEC-205
+title: Agent/Role Spec SDD Variant
+status: Implemented
+impacted_by: [DEC-062]
+related: [XSPEC-204]
+---
+```
+
+```markdown
+---
+id: DEC-069
+title: EngramGraph Architecture
+date: 2026-05-27
+supersedes: [DEC-057]
+impacts: [XSPEC-237]
+---
+```
+
+### 1.2 邊的推導
+
+| 文件上的 front-matter | 推導出的邊 |
+|----------------------|-----------|
+| Decision `impacts: [SPEC]` | `IMPACTS`（Decision → Spec）|
+| Spec `impacted_by: [DEC]` | `IMPACTS`（Decision → Spec）|
+| Decision `supersedes: [DEC]` | `SUPERSEDES`（Decision → Decision）|
+| Decision 內文 `[[XSPEC-NNN]]` 連結 | `IMPACTS`（Decision → Spec）|
+
+邊是**冪等**的：同一關係從兩端宣告（決策的 `impacts` 與規格的 `impacted_by`）只產生一條邊，不會重複。
+
+---
+
+## 2. 兩種運作模式
+
+本標準的消費者**必須**同時支援兩種模式：
+
+### 2.1 降級模式（無引擎）
+
+AI 助手讀取目標文件，沿其 front-matter／`[[ref]]` 連結讀取被連結檔案，手動組出影響鏈。隨時可用；受限於助手能讀取的檔案數。
+
+### 2.2 服務模式（有圖引擎）
+
+語料被索引進圖引擎；助手送出單一多跳查詢（如 `impact-analysis { nodeId, maxHops }`）取得完整鏈——包含降級模式會漏掉的跨域連結（code → spec → decision）。
+
+> 正確實作在兩種模式下產生**相同形狀的答案**；服務模式只是更快更完整，並非本質不同。
+
+---
+
+## 3. Confidence（可選）
+
+節點**可**帶 `confidence`，範圍 `[0.1, 1.0]`。回饋訊號（測試通過／失敗、人工修正、狀態變更）演化 confidence，讓讀取時優先浮現最被強化的產物。confidence 有下限（永不歸零），使連續失敗無法抹除重要節點。此為自我演化圖記憶（SAGE）的基礎。
+
+---
+
+## 4. 規則
+
+1. 關係欄位**可選**且**附加**——缺少永不破壞工具。
+2. 允許參照尚不存在的 id；它們成為 stub 節點，待目標文件出現時解析。
+3. 從*擁有*該關係的一端宣告（決策擁有 `impacts`/`supersedes`；規格擁有 `impacted_by`），但兩端皆接受。
+4. 圖引擎為 **opt-in**。未設定引擎時工具**必須**優雅降級為 Markdown 讀取。
+5. 向量／語意記憶為**互補**而非取代——結構用圖遍歷，相似用向量。
+
+---
+
+## 相關標準
+
+- [Project Context Memory](project-context-memory.md) — 每專案長期事實
+- [Developer Memory](developer-memory.md) — 通用、可攜偏好
+- [ADR Standards](adr-standards.md) — 餵入 Decision 節點的決策紀錄格式

package/bundled/locales/zh-TW/core/release-readiness-gate.md

@@ -1,11 +1,192 @@
 ---
 source: ../../../core/release-readiness-gate.md
 source_version: 1.0.0
-translation_version: 0.0.0
-last_synced: 2026-05-05
+translation_version: 1.0.0
+last_synced: 2026-06-02
+source_hash: 3d156e19680e
 ---
 
-<!-- TODO: 待完整繁體中文翻譯 — Translation pending -->
-<!-- See source: core/release-readiness-gate.md -->
+# 發布就緒閘門（Release Readiness Gate）
 
-> 此標準尚未完整翻譯。請參閱英文原文：[English](../../../core/release-readiness-gate.md)
+> **語言**：[English](../../../core/release-readiness-gate.md) | 繁體中文
+
+**版本**：1.0.0
+**最後更新**：2026-05-05
+**適用範圍**：所有準備進行生產環境發布的軟體專案
+**Scope**：universal
+**業界標準**：ISO/IEC 25010（產品品質）、ISTQB Advanced Test Manager
+**參考文件**：`core/release-quality-manifest.md`、`core/flow-based-testing.md`
+
+---
+
+## 目的
+
+本標準定義一個**單一、彙整式的發布就緒閘門（Release Readiness Gate）**，將所有品質維度統一成生產部署前一個明確的 go/no-go 決策。
+
+若沒有這個閘門，品質證據會散落在 16 個以上的獨立標準中。團隊雖然通過了個別檢查，卻在未驗證某些維度的情況下出貨，因為沒有任何一份文件明說「你必須在發布前通過*所有這些項目*」。
+
+發布就緒閘門：
+- **彙整（Aggregates）** 16 個品質維度成為一份分級 checklist
+- **連結（Connects）** 人工 sign-off（本文件）與機器可讀的證據（`release-quality-manifest.md`）
+- **區分（Distinguishes）** 阻擋性條件與建議性警告
+- **可伸縮（Scales）** 透過 Tier-1 / Tier-2 / Tier-3 分級，以適應不同類型與風險等級的專案
+
+---
+
+## 與發布品質清單（Release Quality Manifest, RQM）的關係
+
+| 產物 | 格式 | 對象 | 目的 |
+|----------|--------|----------|---------|
+| **發布就緒 Sign-off**（本文件的範本） | Markdown checklist | 人類（PM、QA、Eng Lead、Business） | Go/no-go 決策、責任歸屬、稽核軌跡 |
+| **發布品質清單**（`release-quality-manifest.md`） | YAML/JSON | CI、工具、客戶 | 機器可讀的彙整、自動化閘門強制執行 |
+
+這兩份產物在每次發布時**並行（in parallel）**產生。Sign-off 涵蓋人工驗證的維度；RQM 涵蓋自動化的維度。兩者在生產部署前都必須為 `PASS` / `WARN`（絕不可為 `FAIL`）。
+
+---
+
+## Tier 分級
+
+| Tier | 要求 | 未達標 = ？ | 適用對象 |
+|------|-------------|---------|-------------|
+| **Tier-1** | 必須通過；若 `FAIL` 則阻擋發布 | 硬性阻擋（Hard block） | 所有專案 |
+| **Tier-2** | 應通過；`WARN` 須記錄理由；不阻擋 | 記錄在案的 WARN | 所有專案 |
+| **Tier-3** | 當功能集或領域需要時才適用；`N/A` 為有效狀態 | 接受 N/A | 取決於專案類型 |
+
+---
+
+## 16 維度發布就緒矩陣
+
+| # | 維度 | Tier | 閘門類型 | 阻擋條件 | 證據 | 標準 | 負責人 |
+|---|-----------|------|-----------|-------------------|----------|---------|-------------|
+| 1 | **效能 / 負載（Performance / Load）** | 2 | 自動化 | p95 latency 退化 > 10%；headroom < 20% | 負載測試報告 | `performance-standards.md` | Eng Lead + SRE |
+| 2 | **安全性（Security）**（SAST/DAST/SCA/secrets） | 1 | 自動化 | 任何 Critical/High CVE、SAST High 未修、diff 中含 secret | SARIF、Trivy、SBOM | `pipeline-security-gates.md` | SecEng / Eng Lead |
+| 3 | **無障礙（Accessibility, a11y）** | 2 | 自動化 + 人工 | axe-core critical > 0；鍵盤導覽路徑中斷 | axe 報告、screen reader 紀錄 | `accessibility-standards.md` §Release-Blocking Threshold | QA + UX |
+| 4 | **API / 合約測試（Contract Testing）** | 3 | 自動化 | 上游 consumer contract 為紅；N-1 相容性中斷 | Pact broker 報告 | `contract-testing-standards.md` | API owner |
+| 5 | **資料庫遷移（Database Migration）** | 1 | 自動化 | up/rollback/idempotency 測試失敗；資料保存測試失敗 | `data-migration-testing.md` 閘門結果 | `data-migration-testing.md` | DB Lead |
+| 6 | **跨流程回歸（Cross-flow Regression）** | 2 | 自動化 | 關鍵 user journey 通過率 < 95%；business-critical flow 組合失敗 | 跨流程回歸報告 | `cross-flow-regression.md` | QA Lead |
+| 7 | **營運就緒（Operational Readiness）** | 1 | 人工 | 缺少 Runbook；alerting 未設定；無 rollback 程序 | Runbook 連結、alert rule 審查 | `runbook-standards.md`、`alerting-standards.md` | SRE / Ops |
+| 8 | **在地化 / i18n（Localization）** | 2 | 自動化 | 發布中有 MISSING 或 MAJOR i18n 落差（semver 落差） | `check-translation-sync.sh` 輸出 | `translation-lifecycle-standards.md` | i18n Lead |
+| 9 | **瀏覽器 / 裝置相容性（Browser / Device Compatibility）** | 3 | 自動化 | Tier-1 瀏覽器/裝置通過率 < 100% | Playwright matrix 報告 | `browser-compatibility-standards.md` | Frontend QA |
+| 10 | **容量 Sign-off（Capacity Sign-off）** | 3 | 人工 | 預估尖峰時 headroom < 30%；無 Eng+SRE sign-off | 容量預測 + sign-off | `performance-standards.md` §Per-Release Capacity Sign-off | SRE + Eng Lead |
+| 11 | **合規 / 隱私（Compliance / Privacy）** | 3 | 人工 | GDPR/CCPA 違規；缺少 audit log；保存政策中斷 | 隱私審查 checklist | `privacy-standards.md` | DPO / Legal |
+| 12 | **文件完整性（Documentation Completeness）** | 2 | 人工 | 此次發布缺少 CHANGELOG；面向客戶的文件未更新 | CHANGELOG diff、文件審查 | `changelog-standards.md`、`documentation-lifecycle.md` | Tech Writer / PM |
+| 13 | **回滾 / 災難復原（Rollback / Disaster Recovery）** | 1 | 人工 | 此次發布無經測試的 rollback 程序；RTO > 門檻 | DR 演練紀錄；rollback script | `rollback-standards.md`、`disaster-recovery-drill.md` | SRE |
+| 14 | **生產 Smoke / Canary（Production Smoke / Canary）** | 1 | 自動化 | 部署後 smoke 失敗；canary error rate > SLO | Smoke 測試結果；canary 儀表板 | `smoke-test.md`、`cd-deployment-strategies.md` | SRE / DevOps |
+| 15 | **Feature Flag 治理（Feature Flag Governance）** | 2 | 人工 | 預設狀態未審查；kill-switch 未測試 | Flag 稽核 checklist | `feature-flag-standards.md` | PM + Eng Lead |
+| 16 | **多閘門流程驗證（Multi-Gate Flow Verification）** | 2 | 自動化 + 人工 | 任何 ≥ 3 步驟的流程缺少 Gate 0；Gate 3 CI 失敗；缺少 Gate 4 UAT sign-off | `flow_gate_report.json`；UAT sign-off 表 | `flow-based-testing.md` §Multi-Gate | QA Lead + Business |
+
+> **關於 Tier-3 的說明**：不適用時標記為 `N/A`（例如：CLI 工具的瀏覽器 matrix；無 API consumer 的獨立服務的合約測試）。`N/A` 在 sign-off 中需附上理由註解。
+
+---
+
+## 發布就緒 Sign-off 範本
+
+> 每次發布時複製此範本。在 repo 根目錄存為 `.release-readiness/<version>.md`，或附加於發布產物上。
+
+```markdown
+# Release Readiness Sign-off
+
+**Release**: [tag/version]
+**Date**: [YYYY-MM-DD]
+**Environment**: Pre-Production → Production
+**RQM Artifact**: [link or commit SHA]
+
+## Tier-1 Gates (ALL must be PASS)
+
+| # | Dimension | Status | Evidence | Sign-off |
+|---|-----------|--------|----------|---------|
+| 2 | Security (SAST/DAST/SCA) | PASS / FAIL | [link] | [name] |
+| 5 | Database Migration | PASS / FAIL | [link] | [name] |
+| 7 | Operational Readiness | PASS / FAIL | [link] | [name] |
+| 13 | Rollback / DR | PASS / FAIL | [link] | [name] |
+| 14 | Production Smoke/Canary | PASS / FAIL | [link] | [name] |
+
+## Tier-2 Gates (WARN must have rationale)
+
+| # | Dimension | Status | Evidence | Rationale (if WARN) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 1 | Performance / Load | PASS / WARN / FAIL | [link] | | [name] |
+| 3 | Accessibility | PASS / WARN / FAIL | [link] | | [name] |
+| 6 | Cross-flow Regression | PASS / WARN / FAIL | [link] | | [name] |
+| 8 | Localization / i18n | PASS / WARN / FAIL | [link] | | [name] |
+| 12 | Documentation | PASS / WARN / FAIL | [link] | | [name] |
+| 15 | Feature Flag Governance | PASS / WARN / FAIL | [link] | | [name] |
+| 16 | Multi-Gate Flow Verification | PASS / WARN / FAIL | [link] | | [name] |
+
+## Tier-3 Gates (N/A with rationale allowed)
+
+| # | Dimension | Status | Evidence | Rationale (if N/A) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 4 | API / Contract Testing | PASS / WARN / N/A | [link] | | [name] |
+| 9 | Browser / Device Compat | PASS / WARN / N/A | [link] | | [name] |
+| 10 | Capacity Sign-off | PASS / WARN / N/A | [link] | | [name] |
+| 11 | Compliance / Privacy | PASS / WARN / N/A | [link] | | [name] |
+
+## Overall Decision
+
+- [ ] **GO** — All Tier-1 PASS; all WARN documented; all N/A have rationale
+- [ ] **NO-GO** — One or more Tier-1 FAIL, or undocumented WARN
+
+**Decision made by**: [name, role]
+**Date**: [YYYY-MM-DD]
+```
+
+---
+
+## 狀態語意（Status Semantics）
+
+| 狀態 | 意義 | 對發布的影響 |
+|--------|---------|----------------|
+| `PASS` | 符合或超越所有條件 | 無 |
+| `WARN` | 低於目標但高於硬性最低標；已記錄理由 | 允許；記錄在案 |
+| `FAIL` | 低於硬性最低標；尚未解決 | **阻擋發布** |
+| `N/A` | 此維度不適用於本專案/本次發布；已記錄理由 | 允許 |
+
+---
+
+## 何時建立 Sign-off
+
+| 里程碑 | 動作 |
+|-----------|--------|
+| Release candidate 已 tag | 依範本建立 `.release-readiness/<version>.md`；填入證據連結 |
+| Pre-UAT 部署 | 填入 Gate 3 CI 結果；驗證 Tier-1 自動化閘門 |
+| UAT sign-off（Gate 4） | 完成 Tier-3 人工閘門；定案 Multi-Gate Flow 列 |
+| 生產部署決策 | 由 release owner 簽署整體 GO/NO-GO 決策 |
+
+Sign-off **不是**事後補做的——Gate 0（PRD 完整性）與 Gate 1（PR 層級測試）必須在 sign-off 文件建立之前很久就已滿足。Sign-off 彙整的是整個發布週期中持續蒐集的證據。
+
+---
+
+## 反模式（Anti-Patterns）
+
+- **在部署當天才建立 sign-off** — 證據應在整個發布週期中漸進蒐集
+- **未附理由就標記 WARN** — 沒有記錄理由的 WARN，在功能上等同於無視該閘門
+- **完全略過 Tier-3 而未附 N/A 理由** — 若 web app 省略瀏覽器測試，必須明確說明理由
+- **把 Sign-off 當成橡皮圖章** — 每一列都需要一位具名的 sign-off 負責人；匿名的集體所有權代表沒有真正的責任歸屬
+- **多個發布共用一份 sign-off** — 每個發布 tag 一份 sign-off；不可跨版本重複使用
+
+---
+
+## 另請參閱（See Also）
+
+- `release-quality-manifest.md` — 機器可讀的 RQM（本 sign-off 的自動化對應物）
+- `flow-based-testing.md` — Multi-Gate Flow Model（維度 16）
+- `branch-completion.md` — 分支層級閘門（前置條件；不等同於發布就緒）
+- `verification-evidence.md` — 證據標準（所有證據連結都必須符合此標準）
+- `deployment-standards.md` — 部署後閘門整合
+
+---
+
+## 版本歷史（Version History）
+
+| 版本 | 日期 | 變更 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | 首次發布：16 維度矩陣、分級 sign-off 範本、RQM 整合 |
+
+---
+
+## 授權（License）
+
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
+
+**來源（Source）**：[universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)

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

@@ -1,6 +1,14 @@
+---
+source: ../../../core/self-review-protocol.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-05-28
+status: current
+---
+
 # Self-Review Protocol（自我審查協議）
 
-> [English](../../../core/self-review-protocol.md) | **繁體中文**
+> **語言**: [English](../../../core/self-review-protocol.md) | 繁體中文
 
 **版本**: 1.0.0
 **最後更新**: 2026-05-26