universal-dev-standards 5.15.1 → 5.16.0

package/bundled/locales/zh-TW/core/browser-compatibility-standards.md

@@ -1,11 +1,228 @@
 ---
 source: ../../../core/browser-compatibility-standards.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: b806494266e8
 ---
 
-<!-- TODO: 待完整繁體中文翻譯 — Translation pending -->
-<!-- See source: core/browser-compatibility-standards.md -->
+# 瀏覽器相容性標準
 
-> 此標準尚未完整翻譯。請參閱英文原文：[English](../../../core/browser-compatibility-standards.md)
+> **語言**：[English](../../../core/browser-compatibility-standards.md) | 繁體中文
+
+**版本**：1.0.0
+**最後更新**：2026-05-05
+**適用範圍**：前端專案（網頁應用程式、漸進式網頁應用程式 PWA、Web Components）
+**範疇**：universal
+**業界標準**：Browserslist、W3C WebDriver、WebDriver BiDi
+**參考資料**：[caniuse.com](https://caniuse.com/)、[Playwright 瀏覽器支援矩陣](https://playwright.dev/docs/browsers)
+
+---
+
+## 目的
+
+本標準定義所支援的瀏覽器與裝置矩陣、測試自動化策略，以及瀏覽器相容性的發布閘門（即 `release-readiness-gate.md` 中的第 9 維度，Tier-3）。
+
+瀏覽器相容性問題屬於使用者最容易察覺的缺陷之一，卻因為團隊往往假設「在 Chrome 上能跑就好」而被系統性地測試不足。若缺少明確的支援矩陣與自動化驗證，回歸缺陷便會滲漏到正式環境，影響大量使用者族群。
+
+---
+
+## 支援層級定義
+
+| 層級 | 定義 | 發布閘門 |
+|------|-----------|--------------|
+| **Tier-1**（完整支援） | 功能完全對等 + 自動化測試覆蓋 | 100% 通過 —— 任一測試失敗即阻擋發布 |
+| **Tier-2**（部分支援） | 盡力支援；主要流程必須可運作 | ≥ 95% 通過 —— 低於則 WARN，< 90% 則 FAIL |
+| **Tier-3**（盡力而為） | 非正式支援；缺陷會記錄但不阻擋發布 | 僅作為建議參考 |
+
+---
+
+## 預設瀏覽器矩陣
+
+團隊**必須**明確宣告其支援矩陣。以下預設值涵蓋了大多數網頁流量（依 2025–2026 年資料）：
+
+### Tier-1（預設）
+
+| 瀏覽器 | 版本 | 平台 |
+|---------|----------|---------|
+| Chrome | latest、latest-1 | Windows、macOS、Linux、Android |
+| Safari | latest、latest-1 | macOS、iOS |
+| Firefox | latest | Windows、macOS、Linux |
+| Edge | latest | Windows、macOS |
+
+### Tier-2（預設）
+
+| 瀏覽器 | 版本 | 平台 |
+|---------|----------|---------|
+| Chrome | latest-2、latest-3 | 桌面 |
+| Safari | latest-2 | macOS、iOS |
+| Samsung Internet | latest | Android |
+| Opera | latest | 桌面 |
+
+### Tier-3（預設）
+
+| 瀏覽器 | 備註 |
+|---------|-------|
+| IE 11 | 已終止支援（EOL）；僅在合約要求時才支援 |
+| Chrome < latest-3 | 列為已知限制追蹤 |
+
+### 裝置 / 視窗（Viewport）矩陣
+
+| 類別 | 最小寬度 | 代表性裝置 |
+|----------|-----------|-----------------------|
+| 行動裝置（小） | 360px | Android（小尺寸） |
+| 行動裝置（標準） | 390px | iPhone 14 |
+| 平板（直向） | 768px | iPad |
+| 平板（橫向） | 1024px | iPad 橫向 |
+| 桌面（小） | 1280px | 13 吋筆電 |
+| 桌面（標準） | 1440px | 15 吋筆電 / 外接螢幕 |
+| 桌面（寬） | 1920px | Full HD 螢幕 |
+
+最低要求：在 **360px、768px、1280px**（行動 / 平板 / 桌面斷點）進行測試。
+
+---
+
+## 自動化測試
+
+### Playwright 矩陣設定
+
+```typescript
+// playwright.config.ts
+import { defineConfig, devices } from "@playwright/test";
+
+export default defineConfig({
+  projects: [
+    // Tier-1 browsers
+    { name: "chromium", use: { ...devices["Desktop Chrome"] } },
+    { name: "firefox", use: { ...devices["Desktop Firefox"] } },
+    { name: "webkit", use: { ...devices["Desktop Safari"] } },
+    { name: "edge", use: { ...devices["Desktop Edge"] } },
+    // Mobile Tier-1
+    { name: "mobile-chrome", use: { ...devices["Pixel 7"] } },
+    { name: "mobile-safari", use: { ...devices["iPhone 14"] } },
+    // Viewport coverage
+    { name: "tablet", use: { ...devices["iPad Pro 11"] } },
+  ],
+  // Tier-1 failure = build failure
+  reporter: [["html"], ["junit", { outputFile: "results/browser-compat.xml" }]],
+});
+```
+
+### CI 執行策略
+
+```bash
+# Run full Tier-1 matrix on release candidate
+npx playwright test --project=chromium,firefox,webkit,edge,mobile-chrome,mobile-safari,tablet
+
+# Run Tier-1 only on every PR (fast feedback)
+npx playwright test --project=chromium,firefox,webkit
+
+# Run Tier-2 on release candidate (results feed into sign-off as WARN/PASS)
+npx playwright test --project=samsung,opera
+```
+
+### 雲端瀏覽器測試
+
+針對 Tier-1 的跨作業系統測試（例如在 Windows 主機的 CI 上測試 Safari），請使用雲端服務：
+
+| 服務 | 使用情境 |
+|---------|---------|
+| BrowserStack Automate | 商業專案；提供最廣泛的 OS + 瀏覽器矩陣 |
+| Sauce Labs | 已有既有合約的企業 |
+| LambdaTest | 開源 / 對成本敏感的專案 |
+
+**最低雲端測試要求**：在真實 iOS 裝置上測試 Safari latest 與 latest-1（對於 WebKit 的缺陷，模擬器（Simulator）並不足夠）。
+
+---
+
+## 視覺回歸測試（選用但建議）
+
+像素差異（Pixel-diff）測試可偵測跨瀏覽器的版面回歸：
+
+```bash
+# Using Playwright visual comparisons
+npx playwright test --update-snapshots  # update baseline
+npx playwright test                     # compare against baseline; fail if diff > threshold
+```
+
+門檻建議值：版面元件 < 0.5% 像素差異；複雜的互動元件 < 2%。
+
+---
+
+## 發布閘門條件
+
+這是 `release-readiness-gate.md` 中的**第 9 維度**（Tier-3：前端 / 網頁專案必填；CLI / 純後端專案則標示為 `N/A`）。
+
+| 閘門 | Pass | Warn | Fail |
+|------|------|------|------|
+| Tier-1 瀏覽器矩陣 | 100% 測試通過 | — | 任一測試失敗 |
+| Tier-2 瀏覽器矩陣 | ≥ 95% 通過 | 90–95% | < 90% |
+| 視窗覆蓋（360/768/1280） | 任何 Tier-1 瀏覽器上版面皆無破版 | — | 任一關鍵流程無法使用 |
+
+### 簽核所需的證據
+
+```
+| 9 | Browser / Device Compat | PASS | Playwright: 6 browsers × 7 viewports, 100% Tier-1; Tier-2: 97%; [junit report link] | QA Lead |
+```
+
+### `N/A` 條件
+
+在以下情況標示為 `N/A`：
+- 專案為純 CLI、純後端 API，或行動原生（非網頁）
+- 記錄理由：`"N/A — backend API service, no browser UI"`
+
+---
+
+## Browserslist 設定
+
+在 repo 根目錄提交一份 `.browserslistrc`，以確保建置工具（Babel、PostCSS、Autoprefixer）針對相同的瀏覽器：
+
+```
+# .browserslistrc
+# Tier-1: production targets
+last 2 Chrome versions
+last 2 Firefox versions
+last 2 Safari versions
+last 2 Edge versions
+last 2 iOS versions
+last 2 ChromeAndroid versions
+
+# Tier-2: for reference (not in build targets by default)
+# last 4 Chrome versions
+# Samsung Internet >= 14
+```
+
+---
+
+## 反模式
+
+- **只測試 Chrome** —— Chrome 約佔桌面流量的 65%；剩下的 35% 是 Safari / Firefox / Edge 使用者，而你的 bug 會被他們發現
+- **使用瀏覽器模擬器測試 iOS Safari** —— 模擬器上的 WebKit 與真實裝置的 WebKit 有所分歧；對於 release candidate，務必在真實 iOS 上測試
+- **未指定矩陣** —— 隱含假設「支援所有瀏覽器」是不可能測試的；明確的 Tier-1 矩陣勝過毫無實質的隱含覆蓋
+- **將 Tier-3 瀏覽器失敗當作阻擋項** —— Tier-3 是盡力而為；記錄問題才是恰當做法，而非阻擋發布
+- **略過行動視窗測試** —— 行動優先（mobile-first）已是標準；缺少 360px 測試將為大多數行動使用者帶來破損的使用體驗
+
+---
+
+## 與其他標準的關係
+
+- **`accessibility-standards.md`** —— 鍵盤導覽與螢幕報讀器測試需跨所有 Tier-1 瀏覽器執行
+- **`e2e-testing.md`** —— Playwright 矩陣設定將 E2E 測試擴展為多瀏覽器
+- **`release-readiness-gate.md`** —— 第 9 維度（Tier-3）
+- **`performance-standards.md`** —— Core Web Vitals 目標適用於每個 Tier-1 瀏覽器
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更內容 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | 首次發布：Tier-1/2/3 矩陣、Playwright 設定、雲端測試、發布閘門條件 |
+
+---
+
+## 授權
+
+本標準依 [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/contract-testing-standards.md

@@ -1,11 +1,190 @@
 ---
 source: ../../../core/contract-testing-standards.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: 2afa2fe434a6
 ---
 
-<!-- TODO: 待完整繁體中文翻譯 — Translation pending -->
-<!-- See source: core/contract-testing-standards.md -->
+# 合約測試標準（Contract Testing Standards）
 
-> 此標準尚未完整翻譯。請參閱英文原文：[English](../../../core/contract-testing-standards.md)
+> **語言**：[English](../../../core/contract-testing-standards.md) | 繁體中文
+
+**版本**：1.0.0
+**最後更新**：2026-05-05
+**適用範圍**：具有 API 消費者（服務對服務、前端對後端、公開 API）的專案
+**範疇**：universal
+**業界標準**：消費者驅動合約測試（Consumer-Driven Contract Testing, CDCT）、Pact Specification v3
+**參考資料**：[pact.io](https://docs.pact.io/)、[Spring Cloud Contract](https://spring.io/projects/spring-cloud-contract)
+
+---
+
+## 目的
+
+合約測試（Contract testing）驗證 provider（API 伺服器）與其 consumer（用戶端）對於確切介面 —— 請求格式、回應 schema 與狀態碼 —— 達成共識，且無需雙方同時部署。
+
+若缺少合約測試：
+- Provider 的變更會在 production 中悄悄破壞 consumer
+- 服務之間的整合測試需要完整環境
+- API 版本決策在缺乏實際使用證據的情況下做出
+
+本標準將消費者驅動合約測試正式化為一道**發布閘門**（`release-readiness-gate.md` 中的 Dimension 4，Tier-3）。
+
+---
+
+## 消費者驅動合約流程
+
+```
+Consumer 撰寫互動預期
+        ↓
+Consumer 將合約發布至 Pact Broker
+        ↓
+Provider CI 取得 consumer 合約
+        ↓
+Provider 驗證自身能否滿足每一筆互動
+        ↓
+Pact Broker 記錄：can-i-deploy 結果
+        ↓
+發布閘門：provider 部署前所有 consumer 合約必須 GREEN
+```
+
+---
+
+## 合約涵蓋範圍
+
+一份合約涵蓋：
+
+| 元素 | 是否必須指定 | 備註 |
+|---------|-------------|-------|
+| 請求方法（Request method） | 是 | GET / POST / PUT / PATCH / DELETE |
+| 請求路徑（Request path） | 是 | 包含路徑參數（path params） |
+| 請求標頭（Request headers） | 僅必要者 | 不要過度指定可選標頭 |
+| 請求 body schema | 是（針對寫入操作） | schema 層級，而非字面值 |
+| 回應狀態（Response status） | 是 | 所有預期的狀態碼 |
+| 回應 body schema | 是 | schema 層級；使用 matcher 而非字面值 |
+| 回應標頭（Response headers） | 僅必要者 | 例如 `Content-Type` |
+
+**寧可不足指定，也不要過度指定。** 只斷言 consumer 實際使用到的部分。
+
+---
+
+## 向後相容視窗
+
+| 發布類型 | 相容性要求 |
+|-------------|--------------------------|
+| Patch | 100% 向後相容；不預期有合約變更 |
+| Minor | N-1 consumer 合約版本仍須通過 |
+| Major | 需要棄用期；通知 consumer；舊合約歸檔 |
+
+**破壞性變更政策**：若任何作用中的 consumer 合約呈紅色，provider 不得部署（MAY NOT deploy）。破壞性變更需要：
+1. 採用僅新增（additive-only）變更的新 provider 版本
+2. Consumer 遷移至新版本
+3. 舊合約明確標示棄用並歸檔
+
+---
+
+## 發布閘門準則
+
+| 準則 | 硬性下限 | 警告區間 |
+|-----------|-------------|-----------|
+| 所有作用中的 consumer 合約 | 100% 綠燈 | —（二元：全有或全無） |
+| N-1 向後相容 | 100% 綠燈 | — |
+| 棄用合約清理 | 舊合約於 30 天內歸檔 | > 30 天 = WARN |
+
+Pact Broker 中的 `can-i-deploy` 指令封裝了這道閘門：
+
+```bash
+pact-broker can-i-deploy \
+  --pacticipant <provider-service> \
+  --version <version> \
+  --to-environment production
+```
+
+結束碼（Exit code）0 = PASS；非零 = FAIL（阻擋發布）。
+
+---
+
+## 實作指引
+
+### Consumer 端
+
+```typescript
+// Pact consumer test (TypeScript example)
+const interaction = {
+  state: "user 42 exists",
+  uponReceiving: "a request for user 42",
+  withRequest: {
+    method: "GET",
+    path: "/users/42",
+    headers: { Accept: "application/json" },
+  },
+  willRespondWith: {
+    status: 200,
+    headers: { "Content-Type": "application/json" },
+    body: like({           // schema matcher, not literal
+      id: integer(),
+      name: string(),
+      email: email(),
+    }),
+  },
+};
+```
+
+### Provider 端
+
+```bash
+# Provider verification in CI
+PACT_BROKER_BASE_URL=https://pact-broker.internal \
+PACT_PROVIDER_VERSION=$GIT_SHA \
+npm run test:pact:provider
+```
+
+### Pact Broker 標籤
+
+| 標籤 | 意義 |
+|-----|---------|
+| `main` | main 分支的最新版本 |
+| `production` | 目前部署於 production 的版本 |
+| `<feature-branch>` | 功能分支合約（暫時性） |
+
+---
+
+## 反模式
+
+- **測試整個 API 表面** —— 只測試 consumer 實際使用的部分；過度指定會造成不必要的合約中斷
+- **字面值比對** —— 使用 schema matcher（`like()`、`eachLike()`、`integer()`）而非精確值；合約應能容忍實際資料的合理變化
+- **略過 provider 驗證** —— 發布 consumer 合約卻不進行 provider 驗證，代表該合約毫無強制效力
+- **未執行 `can-i-deploy`** —— 只檢查個別合約狀態並不足夠；`can-i-deploy` 會評估整個部署矩陣
+
+---
+
+## 與其他標準的關係
+
+- **`api-design-standards.md`** —— 合約測試強制執行 API 設計中所宣告的向後相容保證
+- **`release-readiness-gate.md`** —— Dimension 4（Tier-3：當存在 API consumer 時適用）
+- **`integration-testing.md`** —— 合約測試補足但不取代整合測試
+- **`versioning.md`** —— 語意化版本與上述向後相容視窗互相關聯
+
+---
+
+## 另見
+
+- [Pact 文件](https://docs.pact.io/)
+- [Can I Deploy](https://docs.pact.io/pact_broker/can_i_deploy)
+- [消費者驅動合約（Consumer-Driven Contracts）](https://martinfowler.com/articles/consumerDrivenContracts.html) —— Martin Fowler
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | 初版發布：消費者驅動合約流程、向後相容視窗、發布閘門準則 |
+
+---
+
+## 授權
+
+本標準依 [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/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

@@ -21,7 +21,7 @@ status: current
 
 本標準定義一套**關係 schema**，讓規格、決策與程式碼能以圖的方式遍歷——回答如*「我若修改 `execute()`，會影響哪些規格與決策？」*的問題。它與向量／語意記憶（找出*相似*的產物）互補，提供**結構遍歷**（找出*有關聯*的產物）。
 
-此 schema 與引擎無關：以純 Markdown front-matter 表達，AI 助手可直接讀取（降級模式），亦可由可選的圖引擎（如 [CodeSage](https://github.com/AsiaOstrich/CodeSage)）索引以進行多跳查詢（服務模式）。
+此 schema 與引擎無關：以純 Markdown front-matter 表達，AI 助手可直接讀取（降級模式），亦可由可選的圖引擎（如 [EngramGraph](https://github.com/AsiaOstrich/EngramGraph)）索引以進行多跳查詢（服務模式）。
 
 ---
 
@@ -68,7 +68,7 @@ related: [XSPEC-204]
 ```markdown
 ---
 id: DEC-069
-title: CodeSage Architecture
+title: EngramGraph Architecture
 date: 2026-05-27
 supersedes: [DEC-057]
 impacts: [XSPEC-237]