universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-TW/core/mock-boundary.md

@@ -0,0 +1,161 @@
+---
+source: ../../../core/mock-boundary.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-01
+source_hash: fe4715991a4c
+status: current
+---
+
+# Mock 邊界標準
+
+> **Language**: [English](../../../core/mock-boundary.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-07-01
+**適用範圍**: 所有具備單元測試與整合測試的軟體專案
+**Scope**: universal
+**產業標準**: ISTQB Foundation（Test Doubles）, xUnit Patterns（Gerard Meszaros）
+**參考資料**: "Working Effectively with Legacy Code"（Feathers）, "Growing Object-Oriented Software"（Freeman & Pryce）
+
+---
+
+## 目的
+
+本文件定義測試中哪些東西可以 mock、哪些不可以。其目標是防止**空心測試（hollow tests）**——永遠通過卻無法偵測真實 bug 的測試，因為它們用 stub 取代了系統的邏輯。
+
+---
+
+## 空心測試問題
+
+空心測試 mock 掉系統的大部分內容，使測試變成 mock 接線的規格說明，而非系統行為的規格說明。經典症狀：你可以刪掉實作檔案，測試仍然通過。
+
+**真實案例（Multi-agent pipeline SPEC-002.test.ts）**:
+
+```typescript
+vi.mock('../../src/runner/agent-runner.js')      // Core logic replaced
+vi.mock('../../src/runner/guardian-hooks.js')     // Core logic replaced
+vi.mock('../../src/runner/prototyper.js')         // Core logic replaced
+vi.mock('../../src/runner/iteration-report.js')   // Core logic replaced
+vi.mock('../../src/memory/memory-store.js')       // Core logic replaced
+vi.mock('node:fs/promises', ...)                  // I/O replaced
+
+// All assertions verify mock call counts — not actual outputs.
+// runPipeline() touches zero real code.
+```
+
+---
+
+## 可以 Mock 的項目
+
+| 類別 | 範例 | 理由 |
+|------|------|------|
+| 外部 HTTP 服務 | LLM API、金流閘道、email 服務 | 防止不穩定（flaky）測試；可控制回應情境 |
+| 時間函式 | `Date.now()`、`new Date()`、`setTimeout` | 使測試具確定性 |
+| 環境變數 | `process.env.NODE_ENV`、`process.env.LICENSE_KEY` | 支援組態變化 |
+| 檔案系統（僅限單元測試） | `fs.readFile`、`fs.writeFile` | 讓快速單元測試避免 I/O |
+| 跨模組邊界（須有對應 IT） | 其他模組的 public API | 隔離受測單元 |
+| 行程內背景執行（透過可注入 runner） | `Task.Run`、unawaited promise、`setTimeout`、goroutine、thread-pool dispatch | 注入 runner seam 讓測試能 await 到確定完成，消除 race |
+
+---
+
+## 不可 Mock 的項目
+
+| 類別 | 違規範例 | 禁止原因 |
+|------|---------|---------|
+| 自身模組的核心邏輯 | 在 pipeline-runner 測試中 `vi.mock('./pipeline-runner.js')` | 使測試形同虛設 |
+| IT/flow/E2E 測試中的資料庫 | 在整合測試中 `vi.mock('./db/client.js')` | 隱藏查詢 bug、schema 問題 |
+| HTTP 框架內部 | `vi.mock('express')` | 真實路由可能已壞 |
+| 安全控制 | 永遠通過的 auth middleware stub | 安全性回歸不可見 |
+
+---
+
+## 可注入的背景執行（Injectable Background Execution）
+
+fire-and-forget 的背景工作（`Task.Run`、unawaited promise、`setTimeout`、goroutine、`java.util.concurrent` executor 提交，或 `asyncio.create_task`）是一個 **seam**，就跟系統時鐘一樣。正如你注入 clock 而非讀取 wall-clock 時間，你也應注入背景 dispatcher，而非直接生出背景工作。這讓測試能把工作驅動到**確定、可被 await 的完成**，並斷言其結果（成功、例外或 retry）——不用 poll、不用 sleep、沒有 race。
+
+把 dispatch 抽象成一個小介面（例如 `IBackgroundTaskRunner` / `BackgroundDispatcher`），再提供兩種實作：
+
+- **Production**：保留真正的 fire-and-forget 語意——dispatch 立即回傳，工作以 detached 方式執行。
+- **Test**：以 **inline** 方式執行工作並**追蹤底層 Task/promise**，對外暴露一個 handle 讓測試能 `await`，使完成（與任何失敗）可被觀察。
+
+語言中立示意（TypeScript pseudo-code）：
+
+```typescript
+// Seam — 於任何 dispatch 背景工作處注入
+interface BackgroundDispatcher {
+  dispatch(work: () => Promise<void>): void
+}
+
+// Production：真正的 fire-and-forget——立即回傳，工作以 detached 執行
+class FireAndForgetDispatcher implements BackgroundDispatcher {
+  dispatch(work: () => Promise<void>): void {
+    void work() // 刻意不 await
+  }
+}
+
+// Test：inline 執行 + 追蹤 task，讓測試能 await 到完成
+class DeterministicDispatcher implements BackgroundDispatcher {
+  private readonly tasks: Promise<void>[] = []
+  dispatch(work: () => Promise<void>): void {
+    this.tasks.push(work()) // inline 啟動並保留 handle
+  }
+  async settle(): Promise<void> {
+    await Promise.all(this.tasks) // 測試 await 到確定完成
+  }
+}
+```
+
+測試注入 `DeterministicDispatcher`，執行受測程式碼，再於斷言結果前 `await dispatcher.settle()`——背景副作用此時已完全可觀察且具確定性。
+
+---
+
+## 空心測試偵測
+
+提交測試檔之前，請檢查：
+
+1. **Mock 數量 ≥ import 數量** → 審查：至少要有一個斷言驗證實際輸出
+2. **所有斷言都是 `.toHaveBeenCalled()` 系列** → 加入輸出值斷言
+3. **Mock 路徑與受測對象目錄相同** → 自我引用 mock；移除之
+4. **Mock 設定行數多於斷言行數** → 很可能是空心測試
+
+---
+
+## 反模式
+
+- **Total Mock Isolation**：所有 import 都被 mock；只斷言 mock 互動
+- **Mock the World**：外部 + 內部 + DB + FS 在同一個測試中全部 mock
+- **Orphan Mock**：跨模組 mock 卻沒有對應的整合測試
+- **Security Bypass Mock**：auth/權限邏輯被換成直接放行的 stub
+- **Database Mock Cascade**：DB 回傳寫死的資料，隱藏真實查詢錯誤
+- **Poll/Sleep for Background Result**：用 sleep 或 poll 等待 fire-and-forget 背景工作完成。race 依然存在——timeout 只是多數時候把它遮住，同時拖慢整套測試；在共用 runner 上更會把 flakiness 洩漏進其他 MR 的 CI。改注入 deterministic runner 並 await 被追蹤的 task。
+
+---
+
+## 規則摘要
+
+| 規則 | 觸發條件 | 動作 |
+|------|---------|------|
+| 禁止 self-mock | 測試檔 mock 自己的模組 | 移除 mock；讓真實程式碼執行 |
+| IT/flow 用真實 DB | 撰寫 IT 或 flow 測試 | 使用 in-memory SQLite 或測試 schema |
+| IT 對應測試 | mock 跨模組邊界 | 確保有對應的 IT 存在 |
+| 禁止 mock 安全機制 | 測試涉及 auth/權限 | 使用真實測試使用者 + 真實 token |
+| 空心審查 | Mock 數量 ≥ import 數量 | 加入輸出值斷言 |
+| 背景工作禁止 poll/sleep | 測試斷言某個 fire-and-forget 副作用 | 注入 deterministic runner；await 被追蹤的 task |
+
+---
+
+## 與其他標準的關係
+
+- **testing**：Mock 邊界規則適用於測試金字塔的所有測試層級
+- **test-completeness-dimensions**：維度 8（AI 測試品質）引用了這些規則
+- **flow-based-testing**：Flow 測試必須遵循 mock 邊界規則
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.0.0 | 2026-05-04 | 初始標準：空心測試問題、可／不可 Mock 表格、偵測、反模式、規則摘要 |
+| 1.1.0 | 2026-07-01 | 新增可注入的背景執行作為 seam（平行於 clock injection）：可 Mock 表列、`可注入的背景執行` 章節、`Poll/Sleep for Background Result` 反模式，以及背景工作禁止 poll/sleep 規則（issue #143） |

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

@@ -0,0 +1,173 @@
+---
+source: ../../../core/model-provenance.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: 62e6b25a38dd
+status: current
+---
+
+# 模型來源政策標準
+
+> **Language**: [English](../../../core/model-provenance.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/model-provenance.ai.yaml`
+> **規格**: XSPEC-255 (cross-project/specs/XSPEC-255-model-provenance-policy.md)
+
+## 概述
+
+模型選擇不只是「成本 × 品質」——還有 **第三軸：模型的*來源*是否被客戶接受**（地緣政治 /
+資料主權 / 法規）。受監管或地緣敏感的買家（如台灣金融/政府客戶）可能無法使用某司法管轄區的
+模型；最嚴格者連 **本地跑的開源權重** 都拒用。本標準把 **模型的來源（provenance）升為一級、
+可強制、可稽核的屬性**：宣告可接受來源政策、對不合規的模型選擇 **fail-closed block**、並產出
+可稽核證據（「本交付未使用任何被禁來源的模型」）。
+
+它是治理閘門家族中的 **來源（provenance）** 成員——與 `license-compliance`（XSPEC-193，
+*授權*）、`verification-oracle`（XSPEC-256，*正確性*）並列——三者共用同一形狀：
+**登錄/檢查 → fail-closed 閘門 → 稽核證據 → 升級給人的天花板**。三者是同一機制在三條軸上的
+profile：**授權 / 來源 / 正確性**。
+
+> **範圍**：本標準定義 *來源機制*（來源登錄、政策 schema、在每個模型選擇點的 fail-closed
+> 強制、稽核證據、天花板）。**政策內容（具體的 allow/deny 清單）歸客戶或合規 pack**——那是他
+> 的業務決策（DEC-075 中立機制 / DEC-063 合規姿態歸客戶）。執行引擎接線（如 VibeOps provider
+> 抽象層 / 路由閘門）屬下游採用議題，不在本標準範圍。
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | Model Origin Registry 為一級工件（模型 → 廠商 → 司法管轄/來源類別） | MUST |
+| REQ-002 | Provenance Policy schema（allow/deny 來源、本地權重區分、mode、unknown-origin） | MUST |
+| REQ-003 | 在每個模型選擇點 fail-closed 強制 | MUST |
+| REQ-004 | 可稽核的來源證據（每次生成記錄模型 + 來源；合規報告） | MUST |
+| REQ-005 | 示範機制的參考政策 pack（內容歸客戶/pack） | SHOULD |
+| REQ-006 | 未知來源模型 → fail-closed block/升級（不靜默放行） | MUST |
+| REQ-007 | 來源政策內容主權——機制中立、政策歸客戶 | SHOULD |
+
+### REQ-001 — Model Origin Registry
+
+每個已知模型 MUST 依 **廠商 → 司法管轄 → 來源類別** 分類。如同 `license-compliance` 的授權 DB，
+此 registry 可維護、可由生態/客戶擴充。來源類別至少要能區分 western-frontier、western-open
+與其他來源，政策才能針對它們表達。例：
+
+| 模型 | 廠商 | 司法管轄 | 來源類別 |
+|------|------|----------|----------|
+| Claude | Anthropic | US | western-frontier |
+| GPT / o-series | OpenAI | US | western-frontier |
+| Gemini | Google | US | western-frontier |
+| Llama | Meta | US | western-open |
+| Mistral | Mistral | EU | western-open |
+| Gemma | Google | US | western-open |
+| DeepSeek | DeepSeek | CN | china-origin |
+| MiniMax | MiniMax | CN | china-origin |
+| Qwen | Alibaba | CN | china-origin |
+
+### REQ-002 — Provenance Policy Schema
+
+per-project/per-customer 政策 MUST 至少能表達：`allow_origins` / `deny_origins`（依來源類別）、
+一個 **本地權重區分**（透過外國 API 存取的模型——資料外送——vs 同一模型的開源權重本地跑——資料
+留本地但權重是外國的）、強制 `mode`（`block` / `warn` / `require_human`），以及預設 **fail-closed**
+的 `unknown_origin` 行為。
+
+```jsonc
+{
+  "allow_origins": ["western-frontier", "western-open"],
+  "deny_origins": ["china-origin"],
+  "china_local_weights": "deny",   // deny | allow_local_only —— 嚴格者連本地外國權重都 deny
+  "mode": "block",                 // block | warn | require_human
+  "unknown_origin": "block"        // fail-closed
+}
+```
+
+### REQ-003 — Fail-Closed 強制
+
+在 **每個模型選擇點**（per-agent config / 路由決策 / BYOK），所選模型的來源 MUST 對照啟用中的
+政策。違規 MUST **fail-closed block（或升級）**——絕不靜默放行（比照 `license-compliance`
+blocklist 與 `verification-oracle` 未複現 block）。強制在路由 *之前* 接線，使不被允許的來源被
+換成可接受的模型，而非被使用。
+
+### REQ-004 — 稽核證據
+
+每次生成 MUST 記錄 **使用的模型 + 其來源類別**，使其可產出合規報告，如：*「本交付未使用任何
+被禁來源的模型」*。證據接稽核 logger / hash chain、`verification-oracle` 正確性證據（XSPEC-256）
+與 telemetry 白名單（DEC-066）。**此報告＝來源/治理護城河的對外證物**，也是客戶的合規證物。
+
+### REQ-005 — 參考政策 pack
+
+機制 SHOULD ship 少量 **參考政策 pack** 來示範它（例如一個 deny 某來源含本地權重的 pack）。
+機制領域中立；**具體政策內容由客戶或合規夥伴擁有**（比照合規 domain pack 的參考 pack 定位）。
+
+### REQ-006 — 未知來源 fail-closed
+
+來源 **不在 registry**（未知來源）的模型 MUST NOT 被靜默允許。系統 MUST 把未知來源當成
+**fail-closed block 或升級**（REQ-002 `unknown_origin`），與治理閘門「不靜默放行」規則一致。
+
+### REQ-007 — 來源政策內容主權
+
+來源 *機制* 領域中立（DEC-075）；*政策內容*（哪些來源可接受）歸客戶（DEC-063）。採用者
+SHOULD 讓政策維持客戶範圍且隔離（參見 `license-compliance` / `verification-oracle` 的逐客戶
+模式，DEC-064）。
+
+## 原則
+
+| ID | 原則 |
+|----|------|
+| P-1 | 來源是第三軸——模型選擇＝成本 × 品質 × *可接受來源* |
+| P-2 | Registry First——每個模型先帶廠商/司法管轄/來源類別，政策才能作用 |
+| P-3 | Fail-Closed——被禁或未知來源則 block 或升級；絕不靜默放行 |
+| P-4 | 證據導向——每次生成記錄模型 + 來源；可產合規報告 |
+| P-5 | 人的天花板——模糊/`require_human` 來源升級給人（DEC-076） |
+| P-6 | 內容主權——機制中立，可接受來源政策歸客戶 |
+
+## 閘門時機
+
+```
+模型選擇點（per-agent config / 路由 / BYOK）
+        │
+        ├─→ [來源政策檢查]  ← REQ-003 fail-closed、路由前
+        │         │
+        │   被禁 / 未知 ──→ block 或升級給人  ← REQ-006 / P-5 天花板
+        │         │
+        │   允許 ──→ 繼續；記錄模型 + 來源  ← REQ-004
+        ↓
+   來源稽核 / 合規報告  ← REQ-004（對外護城河證物）
+```
+
+## 與治理閘門家族的關係
+
+| Profile | 標準 | 軸 | 登錄/檢查 | block 觸發 |
+|---------|------|----|-----------|------------|
+| 授權 | `license-compliance`（XSPEC-193） | legal | blocklist/allowlist/greylist | 禁用授權 |
+| **來源** | **`model-provenance`（XSPEC-255）** | **source** | **模型來源 registry + 政策** | **被禁 / 未知來源** |
+| 正確性 | `verification-oracle`（XSPEC-256） | correct | ground-truth registry | 未複現 / drift |
+
+三者皆：fail-closed + 稽核證據 + 客戶覆寫上報 telemetry + 升級給人的天花板。
+
+## 與既有標準的整合
+
+- **`license-compliance`** — 姊妹 profile；共用 allowlist/denylist + fail-closed + 稽核 +
+  覆寫骨架（評估兩者是否為同一治理子系統）。
+- **`verification-oracle`** — 姊妹 profile；來源稽核證據與正確性證據並列於同一稽核/報告工件。
+- **`model-selection`** — 來源是套在 `model-selection` 成本/品質 right-sizing *之前* 的約束；
+  不可接受的來源先從候選集移除。
+- **`security-standards`** — 資料外送顧慮（外國 API 存取）對齊資料處理/安全；本地權重區分
+  （REQ-002）是資料主權控制。
+- **`verification-evidence`** — 來源報告是一種驗證證據（模型 + 來源 + 無被禁來源軌跡）。
+
+## 相關規格
+
+- XSPEC-255 — Model Provenance Policy 完整規格（本標準來源）
+- XSPEC-193 / XSPEC-256 — 姊妹治理閘門 profile（授權 / 正確性）
+- DEC-075 — VibeOps 領域中立定位（中立機制 / 政策歸生態）
+- DEC-063 — 法律與合規策略（受監管 / 主權敏感客戶）
+- DEC-064 — 客戶 IP 隔離策略（逐客戶政策範圍）
+- DEC-066 — Telemetry 驅動產品演進（稽核/telemetry 白名單）
+- DEC-076 — 自助北極星（來源＝自助天花板）
+- XSPEC-254 — 定位 pre-mortem（§7 #5 成本結構 / token 經濟——來源軸）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~007：模型來源 registry、來源政策 schema、在每個模型選擇點 fail-closed 強制、稽核證據、參考政策 pack、未知來源 fail-closed、政策內容主權（XSPEC-255） |

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

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/model-selection.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-03-24
+source_version: 1.0.1
+translation_version: 1.0.1
+last_synced: 2026-06-10
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/model-selection.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-03-20
+**版本**: 1.0.1
+**最後更新**: 2026-06-10
 **適用性**: 使用多模型分級的 AI 輔助開發
 **範圍**: 通用 (Universal)
 **靈感來源**: [Superpowers](https://github.com/obra/superpowers) — subagent-driven-development (MIT)
@@ -76,8 +76,31 @@ status: current
 | **預篩選** | 先用低成本模型判斷是否需要升級 |
 | **任務分解** | 將複雜任務拆分為多個簡單子任務 |
 
+## 與下一步建議整合
+
+[ai-response-navigation](ai-response-navigation.md) 標準（規則 R6，選用）允許每個「建議下一步」選項攜帶等級標注。本標準的複雜度信號即為判斷依據。
+
+**與廠商無關原則**：等級名稱（Fast／Standard／Capable）是工具無關的泛稱。各平台自行將等級映射到可用模型。
+
+| 等級 | 典型能力定位 |
+|------|-------------|
+| Fast | 輕量級 / 指令遵循 |
+| Standard | 均衡推理 + 程式碼生成 |
+| Capable | 進階推理、架構分析 |
+
+---
+
 ## 相關標準
 
 - [代理派遣與並行協調](agent-dispatch.md)
 - [驗證證據](verification-evidence.md)
 - [系統化除錯](systematic-debugging.md)
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.0.1 | 2026-06-10 | 新增「與下一步建議整合」節（R6 交叉引用；與廠商無關原則） |
+| 1.0.0 | 2026-03-20 | 初始版本 |

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

@@ -0,0 +1,106 @@
+---
+source: ../../../core/mutation-testing.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 6a5286d76274
+status: current
+---
+
+# 突變測試標準
+
+> **Language**: [English](../../../core/mutation-testing.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-05-04
+**適用範圍**: 所有具備單元/整合測試的軟體專案
+**Scope**: universal
+**產業標準**: ISTQB Foundation Syllabus（測試有效性指標）
+**參考資料**: "Introduction to Software Testing"（Ammann & Offutt）, Stryker Mutator 文件
+
+---
+
+## 目的
+
+突變測試（mutation testing）藉由注入人工 bug 並檢查測試是否能偵測它們，來評估測試套件的有效性。它回答了行覆蓋率無法回答的問題：**「我的測試真的有驗證正確行為嗎？」**
+
+---
+
+## 核心概念：Mutation Score
+
+```
+Mutation Score = Killed Mutants / (Killed + Survived) × 100%
+```
+
+- **Killed**：測試套件偵測到人工 bug（測試失敗）✅
+- **Survived**：測試套件漏掉了 bug（測試仍通過）❌
+
+一個只有 `expect(x).toBeDefined()` 的測試可以達到 100% 行覆蓋率，卻會讓許多突變存活（因為 `x` 是 `null`、`0` 或 `"wrong"` 都滿足 `.toBeDefined()`）。
+
+---
+
+## 工具
+
+| 語言 | 工具 | 指令 |
+|------|------|------|
+| TypeScript/JS | Stryker Mutator | `npx stryker run` |
+| Python | mutmut | `mutmut run` |
+| Java | PIT (Pitest) | `mvn pitest:mutationCoverage` |
+
+---
+
+## 閾值
+
+| 模組類型 | 最低分數 | 強制程度 |
+|---------|---------|---------|
+| Auth/License/Payment/Security | 80% | 封鎖 release |
+| 標準業務邏輯 | 70% | 警告；下次 release 前解決 |
+| AI 生成的測試 | 50% | 必要；低於即拒絕 |
+| 整體專案 | 60% | 追蹤趨勢；回歸時告警 |
+
+---
+
+## 何時執行
+
+| 觸發條件 | 指令 | 強制程度 |
+|---------|------|---------|
+| Pre-release 閘門 | `npm run test:mutation` | 整體 ≥ 60% |
+| 關鍵模組變更 | `npx stryker run --mutate 'src/auth/**'` | ≥ 80% |
+| AI 生成測試審查 | `npx stryker run` | ≥ 50% |
+
+**絕不**把突變測試加入 commit hook——它太慢了（10-60 分鐘）。
+
+---
+
+## Stryker 快速上手（TypeScript + Vitest）
+
+```bash
+npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner
+```
+
+```json
+// stryker.config.json
+{
+  "testRunner": "vitest",
+  "coverageAnalysis": "perTest",
+  "mutate": ["src/license/**/*.ts", "!src/**/*.test.ts"],
+  "thresholds": { "high": 80, "low": 60, "break": 50 }
+}
+```
+
+---
+
+## 反模式
+
+- 把行覆蓋率當作測試有效性的替代指標
+- 在每個 PR 的 CI 中都加入突變測試（太慢）
+- 未經 mutation score 驗證就接受 AI 生成的測試
+- 靠加 `toBeDefined()` 斷言來殺死突變
+
+---
+
+## 與其他標準的關係
+
+- `test-completeness-dimensions`：維度 8（AI 測試品質）引用 mutation score
+- `mock-boundary`：空心測試會讓許多突變存活；mock 邊界規則防止空心測試
+- `testing`：突變測試是測試金字塔頂端的品質閘門