universal-dev-standards 6.4.0 → 6.5.0

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

@@ -1,8 +1,9 @@
 ---
 source: ../../../core/model-selection.md
-source_version: 1.0.1
-translation_version: 1.0.1
-last_synced: 2026-06-10
+source_version: 2.1.0
+translation_version: 2.1.0
+last_synced: 2026-08-11
+source_hash: a843a9052a2d
 status: current
 ---
 
@@ -10,17 +11,21 @@ status: current
 
 > **語言**: [English](../../../core/model-selection.md) | 繁體中文
 
-**版本**: 1.0.1
-**最後更新**: 2026-06-10
+**版本**: 2.1.0
+**最後更新**: 2026-08-11
 **適用性**: 使用多模型分級的 AI 輔助開發
 **範圍**: 通用 (Universal)
 **靈感來源**: [Superpowers](https://github.com/obra/superpowers) — subagent-driven-development (MIT)
 
+> **翻譯範圍（XSPEC-355）**：本翻譯只涵蓋**規範性（normative）**內容。
+> 說明性（informative）段落——成本最佳化建議、示例清單、參考資料、設計理由的敘述——
+> 請參閱[英文原文](../../../core/model-selection.md)。
+
 ---
 
 ## 目的
 
-定義基於任務複雜度的 AI 模型分級選擇策略。使用能勝任的最便宜模型，僅在必要時升級。
+定義兩個獨立決策：**選哪個模型**與**要它想多深**。兩者不可壓成同一軸。使用能勝任的最便宜組合，失敗時沿**正確的軸**升級。
 
 ---
 
@@ -28,79 +33,412 @@ status: current
 
 | 術語 | 定義 |
 |------|------|
-| 模型分級 (Model Tier) | 代表模型能力和成本的分類等級 |
-| 複雜度信號 (Complexity Signal) | 指示所需能力等級的任務可觀察特徵 |
-| 升級 (Escalation) | 低級模型失敗後升級到高級模型 |
+| 模型分級 (Model Tier) | 代表模型**推理天花板**與成本的分類等級 |
+| 思考深度 (Effort Level) | **單次派工**所要求的推理深度；是請求參數，不是模型屬性 |
+| 推理天花板 (Reasoning Ceiling) | 超過此限度後，再多的思考時間也得不到更好的答案 |
+| 規格明確度 (Specification Definiteness) | 步驟是否已定義，或僅知目標與約束 |
+| 硬邊界 (Hard Boundary) | 模型**完全不具備**的能力（非「做得比較差」）——如 context 容量、是否支援 effort 參數 |
+| 拒絕標記 (Refusal Marker) | 在一則外觀正常的回應中，表示請求被拒絕的欄位 |
+| 升級 (Escalation) | 在 effort 軸用盡後，沿模型軸往上移動 |
 
 ---
 
-## 核心原則 — 成本效益
+## 版本欄語意
+
+> **本文件只有一個版本欄。** 檔頭的 `Version` 欄涵蓋全檔，包含所有章節。
+> **章節不得自帶版本標記**；章節的變更歷程一律記於[版本歷史](#版本歷史)表。
+>
+> `ai/standards/model-selection.ai.yaml` 的 `standard.meta.version` 對應**全檔版本**，
+> 絕不對應任何章節版本。
+
+---
+
+## 核心原則 — 兩個正交軸
+
+> **模型軸買的是「天花板與性格」，effort 軸買的是「這一次要它想多深」。在一軸上的選擇，不決定另一軸。**
+
+```
+                        effort →   低         中          高        極高        極限
+模型層級 ↓
+  fast                             ·          ·           ·         ?           ?
+  standard                         ·          ·           ·         ?           ?
+  capable                          ·          ·           ·         ?           ?
+```
 
-> **始終使用與任務複雜度匹配的最便宜模型。**
+每一格原則上都是合法派工：兩個軸各自獨立選擇。
+
+`?` 標示的格子，**本標準無法斷言其可用性**——某個模型接受哪些 effort 級距是**該模型的屬性**，而此處的層級名稱是與廠商無關的標籤，所以答案在各平台自己的「層級 → 模型」映射裡，不在這張表裡。不支援的級距是**硬邊界**，不是「較差的選擇」——見 [R3a](#r3a-硬邊界)。採用者**必須**逐模型登記它接受哪些級距。
 
 ---
 
-## 三級模型分類
+## 軸一 — 模型層級
+
+### 選擇判準
+
+兩個判準決定分層。**兩者都不是「改幾個檔案」**。
+
+#### 判準 1 — 推理天花板需求
+
+這個任務是否存在**單靠更多思考時間也解決不了**的成分？
+
+- **否** → 較低層即可勝任；用 effort 買深度，而非用錢買天花板。
+- **是** → 需要更高天花板；在較低層加多少 effort 都到不了。
+
+#### 判準 2 — 規格明確度
+
+**這是雙向判準，並非單調遞增。**
+
+| 規格狀態 | 偏好 | 反向使用時的失效模式 |
+|---|---|---|
+| 步驟已定義、路徑已知 | 字面遵循型（較低層） | 把已寫死的步驟餵給高天花板型會**降低**產出品質——它會重新詮釋已經決定過的事 |
+| 僅知目標與約束、路徑未知 | 模糊性導航型（較高層） | 把模糊任務給字面遵循型，會得到**「精確執行了錯誤的那句話」** |
+
+> **為何移除「修改檔案數」**：3 個檔案的模組邊界重新設計，比 8 個檔案的機械改名更難。
+> 檔案數會**以固定方向**誤判「深而窄」的工作——這是偏差，不是噪音。
+
+### 三個層級
+
+層級識別碼（`fast` / `standard` / `capable`）維持不變，只有判準改變。
+
+#### Tier 1: Fast（快速層）
+
+**用途**：無推理天花板需求、規格完全明確的工作。
+
+**信號**：
+- 不存在「想更久也想不出來」的成分
+- 步驟已寫出，無需尋路
+- 不需要設計判斷
+- 字面遵循正是想要的行為
+
+#### Tier 2: Standard（標準層）
+
+**用途**：需要一定推理天花板，規格大致明確但留有局部決策空間。
+
+**信號**：
+- 部分成分需要推理，但沒有一項是「想更久也想不出來」
+- 目標與多數步驟已定義，剩下有限的局部選擇
+- 需要理解模組間關係
+
+#### Tier 3: Capable（能力層）
+
+**用途**：需要高推理天花板，或規格僅有目標與約束、路徑未知。
+
+**信號**：
+- 存在單靠更多思考時間解決不了的成分
+- 路徑未知；答案要找出來，不是套用
+- 需要導航模糊性而非遵循文字
+
+> **關於「大型重構」**：目標結構**已定**的大型重構**不**自動屬於 Tier 3——
+> 依判準 2 它是明確規格，高天花板模型的產出可能比字面遵循型更差。
+> 使它升到 Tier 3 的是「目標結構**未定**」。
+
+### 選擇決策流程
+
+```
+這個任務是否存在單靠更多思考解決不了的成分？
+  ├── 是 → 需要高天花板 → Tier 3 (Capable)
+  └── 否 → 規格有多明確？
+            ├── 步驟完全定義、路徑已知   → Tier 1 (Fast)
+            ├── 目標＋多數步驟、局部選擇 → Tier 2 (Standard)
+            └── 僅有目標與約束           → Tier 3 (Capable)
+接著，獨立地：選擇 effort 級距（軸二）。
+```
+
+---
+
+## 軸二 — Effort（思考深度）
+
+Effort 是**單次派工的參數**，不是模型屬性。同一個模型在 `low` 與在 `max` 不是同一個工作者。
+
+### 與廠商無關的 effort 級距
+
+各平台自行將這些標籤映射至其參數。**標籤是契約，映射是在地的。**
+
+| 級距 | 語意 | 典型用途 |
+|---|---|---|
+| `low`（低） | 最少斟酌，主要依模式作答 | 機械性編輯、查詢、格式化 |
+| `medium`（中） | 一般斟酌；預設值 | 多數已定義的實作工作 |
+| `high`（高） | 延伸斟酌，作答前考慮替代方案 | 含局部決策的整合工作 |
+| `very-high`（極高） | 探索並淘汰候選方法 | 設計、審查、非顯而易見的除錯 |
+| `max`（極限） | 該模型可用的最大深度 | 升級模型軸前的最後一次嘗試 |
+
+**並非每一層都支援每一個級距。** 是否支援 effort 參數是**硬邊界**，不是品質梯度——見 [R3a](#r3a-硬邊界)。平台的「層級 → 模型」映射**必須**登記每個模型接受哪些級距。
+
+### 失敗診斷 — 深度不足或天花板不足？
+
+> **任務失敗時，先判斷是哪一軸不足。兩者的補救方式不可互換。**
+
+| 觀察到的現象 | 診斷 | 補救 | 用錯補救的代價 |
+|---|---|---|---|
+| 產出淺、略過考量、提早收手，但它做過的推理本身是對的 | **深度不足** | 在**同一個**模型上提高 effort | 升級層級＝為一個從來不是瓶頸的天花板多付錢 |
+| 產出在種類上就錯了——誤解問題、提出不可行的方法——**且在 `max` effort 下仍如此** | **天花板不足** | 升級**模型**層級 | 再提高 effort 買不到任何東西；級距已用盡 |
+
+**排序規則**：先調 effort，再升級層級。只有在當前層的**最高可用** effort 也失敗之後，才升級層級。未用盡 effort 就升級層級，是對「哪一軸不足」的未經驗證假設。
+
+**例外**：若[判準 1](#判準-1--推理天花板需求) 事前已識別出「想更久也想不出來」的成分，直接從較高層開始。排序規則是關於**診斷失敗**，不是關於忽略事前判準。
+
+---
+
+## 反向排除規則
+
+層級判準說的是什麼工作該**升到**某層。本節說的是什麼工作**不該送給**某層。這是兩個不同的問題，而第二個問題的答案無法從第一個推導出來。
+
+### R3a 硬邊界
+
+> **硬邊界是能力的「有無」，不是能力的「程度」。** 裝不下輸入的模型不是「把任務做得比較差」——它做不了這個任務。
+
+採用者**必須**在其「層級 → 模型」映射中登記硬邊界，且**與能力分數並列而分開記錄**：
+
+| 硬邊界 | 它回答的問題 | 違反時的後果 |
+|---|---|---|
+| **Context 容量** | 輸入裝得下嗎？ | 截斷或報錯——模型從未看過任務的一部分 |
+| **Effort 參數支援** | 這個模型接受 effort 級距嗎？ | 請求被拒，或靜默以模型固定深度執行 |
+| **Modality 支援** | 它接受這種輸入型別嗎（影像、語音）？ | 輸入被丟棄或拒絕 |
+
+**規則**：不滿足任一必要硬邊界的模型，須在**成本比較之前**排除，而非在比較中排名較低。事後才排除，會讓比較便宜但做不到的模型在價格上勝出。
+
+**登記格式**：硬邊界對應能力登記表的 `declared`——布林值，連線建立時即可取得，成本趨近零。分數 `1` **不是**硬邊界，它是量測到的低品質（見 [R7a 四態表](#routing_rules--四態路由)）。
+
+### R3b 反向風險
 
-| 級別 | 適用場景 | 複雜度信號 |
-|------|----------|-----------|
-| **Tier 1（輕量級）** | 簡單、重複性任務 | 單一檔案、格式化、搜尋替換 |
-| **Tier 2（標準級）** | 中等複雜度任務 | 多檔案、邏輯修改、測試撰寫 |
-| **Tier 3（高級）** | 高複雜度任務 | 架構設計、跨系統整合、除錯 |
+能力更高不是全面地更好。有兩類風險的方向與層級判準相反：
 
-## 複雜度信號判斷
+#### 1. 規格敏感類工作遭安全分類器拒絕
 
-| 信號 | Tier 1 | Tier 2 | Tier 3 |
-|------|--------|--------|--------|
-| 涉及檔案數 | 1 | 2-5 | 6+ |
-| 需要推理深度 | 淺 | 中 | 深 |
-| 跨模組互動 | 無 | 有限 | 複雜 |
-| 需要創意/設計 | 無 | 部分 | 大量 |
-| 錯誤風險 | 低 | 中 | 高 |
+高能力層可能帶有更嚴格的安全分類。合法但形似禁止類別的工作——資安加固、緩解措施實作、憑證處理程式碼、red-team 工具——可能被**拒絕**。
+
+> **拒絕不是錯誤。** 呼叫回傳的是**正常回應加上拒絕標記**。
+> 對只檢查 exit code、或只檢查有無擲出例外的呼叫端而言，**這是靜默失效**：
+> 管線記錄成功，而工作根本沒做。
+
+**要求**：
+
+1. 呼叫端**必須檢查回應中的拒絕標記**。沒有錯誤不等於完成的證據。（見 `verification-evidence` 標準：「檢查工具跑了但回傳了無意義的內容」與「檢查根本沒跑」是兩種不同的失效類型。）
+2. 規格敏感類工作在**批次派往**高能力層之前，**必須先驗證可行性**——用一則廉價的探測請求，而非整份任務。
+3. 遇到拒絕時，**改派至其他層級或其他 provider**；不要以更高 effort 重試同一請求。**effort 移動不了分類器的判定。**
+
+#### 2. 過度詳細的 prompt 會降低高天花板模型的品質
+
+把每一個步驟都寫出來，對字面遵循型是正確做法，對高天花板型則是**錯誤**做法：後者會重新詮釋已經決定過的事，產出反而變差。
+
+**規則**：prompt 顆粒度隨層級走。若唯一可用的 prompt 是完整寫出的步驟清單，[判準 2](#判準-2--規格明確度) 本來就要求把它送到較低層——送到高層是雙重錯誤：付更多錢，得到更差的產出。
+
+---
 
 ## 升級規則
 
-| 觸發條件 | 動作 |
-|----------|------|
-| 低級模型產生錯誤輸出 | 升級到下一級別 |
-| 任務超出預期複雜度 | 升級到下一級別 |
-| 多次重試仍失敗 | 升級到最高級別 |
-| 安全性或架構關鍵任務 | 直接使用最高級別 |
+升級現在有兩個軸；下表適用於**當前層級的 effort 已用盡之後**。
+
+| 當前層級 | 在最高可用 effort 下仍失敗 | 動作 |
+|-------------|-----------|--------|
+| Fast | → Standard | 以 Standard 層重新派工 |
+| Standard | → Capable | 以 Capable 層重新派工 |
+| Capable | → 人工 | 標記為需要人工介入 |
+
+### 升級不是重試
+
+升級意味著改用更有能力的模型，不是重複同一個動作。更高層級的模型會收到：
+- 原始任務
+- 低層級模型的產出與失敗原因
+- **已嘗試過的 effort 級距**
+- 其他可用的上下文
+
+---
+
+## 規則
+
+| ID | 觸發條件 | 動作 | 優先級 |
+|----|---------|--------|----------|
+| MS-001 | Fast 層 BLOCKED，effort 已用盡 | 升級至 Standard | High |
+| MS-002 | Standard 層 BLOCKED，effort 已用盡 | 升級至 Capable | High |
+| MS-003 | Capable 層 BLOCKED，effort 已用盡 | 標記為需要人工介入 | Critical |
+| MS-004 | 任務規格僅有目標與約束 | 從 Standard 或更高層級開始 | Medium |
+| MS-005 | 產出淺但推理健全，effort 尚未達 max | 在同一模型上提高 effort — **不要**升級層級 | High |
+| MS-006 | 產出在種類上就錯了，且 effort 已達 max | 升級模型層級 — 再提高 effort 買不到任何東西 | High |
+| MS-007 | 候選模型不滿足必要硬邊界（context、effort 支援、modality） | 在成本比較**之前**排除 | Critical |
+| MS-008 | 將規格敏感類工作派往高能力層 | 先探測可行性；每一則回應都要檢查拒絕標記 | Critical |
+| MS-009 | prompt 是完整寫出的步驟清單 | 偏好字面遵循型；不要升到高天花板層 | Medium |
+| MS-010 | `pin_date` 或 `measured.at` 距今超過 90 天 | 發出 WARN 並排入重測佇列（不阻擋發版） | Medium |
+
+---
+
+## LLM 能力管理（XSPEC-027）
+
+上述兩軸回答「選哪個模型、想多深」。本節回答第三個獨立問題：**這個模型究竟做不做得到這「種」事，以及做得多好**——用於多模型池環境。
+
+### capability_dimensions — 能力維度
+
+能力維度分為四大類，共 10 個子維度：
+
+| 大類 | 子維度 | 說明 | 基準測試 |
+|------|--------|------|---------|
+| modality | vision | 圖片/截圖理解（UI 分析、圖表解讀） | internal-vision-bench |
+| modality | audio | 語音理解能力 | future-audio-bench |
+| modality | image_generation | 圖片生成能力 | provider-specific |
+| reasoning | code_reasoning | 程式碼理解與生成品質 | humaneval-plus |
+| reasoning | math_reasoning | 數學推理準確率 | gsm8k |
+| reasoning | instruction_following | 複雜多步驟指令遵循率 | internal-instruction-bench |
+| reasoning | long_context_quality | 長文件中間段資訊存取 | needle-in-haystack |
+| output | structured_output | JSON/Schema 格式輸出成功率 | internal-json-bench |
+| output | tool_use | Function Calling 正確率 | internal-tool-bench |
+| language | multilingual_zh_tw | 繁體中文品質（本系統優先語言） | internal-zh-tw-bench |
+
+#### 每個子維度有「兩個」獨立欄位
+
+> **單一 1–5 分無法表達兩件不同的事。**「支不支援」是二元、廠商宣告、連線時即可取得；
+> 「有多好」是連續、需要跑 benchmark。把兩者編碼進同一個數字，
+> 會讓便宜的事實與昂貴的事實無從分辨——而昂貴的那個會靜默勝出。
+
+| 欄位 | 型別 | 來源 | 成本 | 意義 |
+|---|---|---|---|---|
+| `declared` | 布林 | provider 的模型描述端點或設定宣告 | 趨近零，連線時可得 | **做不做得到這件事** |
+| `measured` | `{ score: 1–5, at: 日期, version_identifier: 字串 }` | benchmark 執行 | 高，離線 | **做得多好** |
+
+**規範性規則**：
+
+1. **`declared: false` 是硬邊界。** 無論任何分數，該模型做不到這件事。它會被排除，且**不**排入校準佇列——量測它沒有意義。
+2. **`declared: true` 且 `measured` 缺失 = `UNKNOWN`。** 做得到，但不知道做得多好。這是**資訊缺口**，不是結論。
+3. **`supported` 不得由 `score` 推導。** 任何以 `supported = score > 0`（或類似）計算的實作，都已把兩個欄位合併回單軸，重新製造了本規則存在所要防止的缺陷。
+4. **量測失敗不得記為任何分數。** 必須記為缺失（`UNKNOWN`）。以預設值填補失敗的量測——包括 `0`，而 `0` 不在 1–5 量表內——會讓「我們量不到」與「我們量到了而且很差」無從分辨。
 
-## 成本最佳化策略
+**評分量表（1–5），僅適用於 `measured.score`**：
 
-| 策略 | 說明 |
+| 分數 | 意義 |
 |------|------|
-| **批次處理** | 將多個簡單任務合併為一次呼叫 |
-| **快取** | 快取常見查詢結果避免重複呼叫 |
-| **預篩選** | 先用低成本模型判斷是否需要升級 |
-| **任務分解** | 將複雜任務拆分為多個簡單子任務 |
+| 5 | 生產就緒 — 高準確率，可直接使用 |
+| 4 | 良好 — 偶有遺漏，可接受 |
+| 3 | 基本可用 — 需人工補充 |
+| 2 | 部分可用 — 僅供參考 |
+| 1 | 不可靠 — 不建議使用 |
+
+**沒有 0 分。** 量測缺失以「`measured` 物件不存在」表達，絕不以分數表達。
+
+### capability_registry — 模型能力登記表
+
+各專案依自己的實測，在自己的 `capability_registry` 中維護每個模型的分數。
+
+> **本標準依規則不登記任何具體廠商模型 ID。** 寫進標準的模型 ID 是一個
+> **有到期日、卻沒有時鐘**的引用端：它會過期，而過期的樣子與正常的樣子在頁面上無從分辨。
+> 以下範例一律使用佔位符。
+
+**格式**：
+```yaml
+- model_id: "<provider>/<model-name>"        # 佔位符 — 由採用者填入
+  version_pinned: "<version-identifier>"      # SHA、日期戳或 model_version
+  pin_date: "<YYYY-MM-DD>"
+  eol_date: "<YYYY-MM-DD>"                    # 可選
+  capabilities:
+    "modality.vision":
+      declared: true
+      measured:
+        score: 4
+        at: "<YYYY-MM-DD>"
+        version_identifier: "<量測時所用的版本識別>"
+    "modality.audio":
+      declared: false                          # 硬邊界 — 無 measured 欄位，也不需要
+    "output.tool_use":
+      declared: true                           # measured 缺失 → UNKNOWN → 排入校準佇列
+```
+
+**版本鎖定（DEC-031 D1）**：`version_pinned` 與 `pin_date` 為**必填**，以防模型靜默升級而能力在無人察覺下改變。
+
+**逾期檢查（WARN，非 BLOCK）**：`pin_date` 或 `measured.at` 距今超過 **90 天**時，**必須**發出 WARN，並指名受影響的 `model_id` 與子維度。它**不得**阻擋發版——純檔內不變量的誤報率過高，不適合作為閘門。
+
+### routing_rules — 四態路由
+
+> **「沒測過」與「測過且不可靠」不是同一個狀態。** 壓成同一態的後果是：
+> 新偵測到的模型在第一次評估時就被排除，而且再也回不到候選池——
+> **與「支援更多模型」的目標直接相反。**
+
+| 狀態 | 條件 | 動作 |
+|---|---|---|
+| `SUPPORTED` | 所需能力的 `measured.score` 皆 ≥ `min_score` | 正常執行 |
+| `DEGRADED` | `measured.score` 存在、≥ 2、但低於 `min_score` | 降級執行；產出標記 `[DEGRADED]` |
+| `UNSUPPORTED` | **`measured` 存在**且 `score` ≤ 1 | 排除；**不**排入校準佇列（已有結論） |
+| `UNKNOWN` | **`measured` 缺失**——未登記、量測失敗或資料逾期——而 `declared: true` | **排入校準佇列**；在校準完成前**不得**靜默排除 |
+
+**`declared: false`** 在本表之前處理：它是硬邊界（[R3a](#r3a-硬邊界)），排除且**不**排入校準佇列。
+
+**可觀測性要求**：`UNKNOWN` 與 `UNSUPPORTED` **必須在回傳結構上可分辨**，而不只是在 log 上可分辨。呼叫端必須能分辨「這個模型不行」與「我還不知道這個模型行不行」——兩者導向不同的下一步動作。回傳單一布林值、或只回傳三態的路由 API，表達不了這件事。
+
+**決策樹**：
+
+```
+任務需要 capability X
+  ├── declared == false                    → 硬邊界     — 排除，不校準
+  ├── measured 缺失／失敗／逾期            → UNKNOWN     — 排入校準佇列
+  ├── measured.score ≤ 1                   → UNSUPPORTED — 排除，不校準
+  ├── measured.score ≥ 2 且 < min_score    → DEGRADED    — 執行並標記 [DEGRADED]
+  └── measured.score ≥ min_score           → SUPPORTED   — 執行
+```
+
+### 重測觸發 — 三條獨立路徑
+
+> **版本變更是充分條件，不是必要條件。** 降智偵測（DEC-033）之所以存在，
+> 正是因為**模型 ID 與版本字串不變而行為改變**。
+> 僅由版本變更觸發的實作，會漏掉 DEC-033 整個要防的情境。
+
+| # | 觸發 | 效果 |
+|---|---|---|
+| 1 | `version_identifier` 與 `measured` 中記錄的不同 | 既有量測**立即失效** → 狀態變為 `UNKNOWN` |
+| 2 | `measured.at` 距今超過 90 天 | 排入重測；發出 WARN（見 MS-010） |
+| 3 | 降智偵測告警（DEC-033，CAP-004／CAP-005） | 排入重測——**即使版本字串未變** |
+
+這三條**彼此獨立**：各自單獨觸發，且沒有任何一條是另一條的前提。
+
+### 能力規則
+
+| ID | 條件 | 動作 | 優先級 |
+|------|------|------|------|
+| CAP-001 | 所需 capability 的 `measured.score` ≥ `min_score` | SUPPORTED — 正常執行 | High |
+| CAP-002 | `measured.score` ≥ 2 但低於 `min_score` | DEGRADED — 降級流程，產出標記 `[DEGRADED]` | Medium |
+| CAP-003 | **`measured` 存在**且 `score` ≤ 1 | UNSUPPORTED — 替代流程或提示用戶；不校準 | High |
+| CAP-004 | 降智偵測（DEC-033）觸發 moderate 信號 | 啟動金絲雀測試，記錄降智警告，**並將受影響能力排入重測** | High |
+| CAP-005 | 降智偵測觸發 critical 信號 | 切換備用模型，上報 P1 Issue，**並將受影響能力排入重測** | Critical |
+| CAP-006 | `declared: true` 且 `measured` 缺失、失敗或逾期 | UNKNOWN — 排入校準佇列；**不得**靜默排除 | High |
+| CAP-007 | 所需 capability 的 `declared: false` | 硬邊界 — 在成本比較之前排除；**不**排入校準佇列 | Critical |
+| CAP-008 | `version_identifier` 與 `measured.version_identifier` 不同 | 立即失效該量測 → `UNKNOWN` | High |
+
+**選擇策略**：`pareto_weighted` — 在**通過硬邊界排除的候選之中**，優先選擇所需維度得分最高、成本最低的模型。
+
+### 與兩個軸的關係
+
+- **模型軸** — 推理天花板與性格（選哪個模型）
+- **Effort 軸** — 這次派工的思考深度（想多深）
+- **能力維度** — 選中的模型究竟做不做得到這「種」事，以及做得多好
+
+套用順序：硬邊界排除 → 依兩個判準選層級 → 確認所需能力為 `SUPPORTED` 或可接受的 `DEGRADED` → 選擇 effort 級距。
+
+---
 
 ## 與下一步建議整合
 
-[ai-response-navigation](ai-response-navigation.md) 標準（規則 R6，選用）允許每個「建議下一步」選項攜帶等級標注。本標準的複雜度信號即為判斷依據。
+[ai-response-navigation](ai-response-navigation.md) 標準（規則 R6，選用）允許每個「建議下一步」選項攜帶等級標注。本標準的判準即為判斷依據。
 
-**與廠商無關原則**：等級名稱（Fast／Standard／Capable）是工具無關的泛稱。各平台自行將等級映射到可用模型。
+> **2.1.0 的變更**：先前的標注是依檔案數推導的。依舊判準做出的既有標注可能已不再準確。
+> 層級識別碼未變，因此**不需要資料遷移**；下次編輯周邊文字時順手重新評估標注即可。
 
-| 等級 | 典型能力定位 |
-|------|-------------|
-| Fast | 輕量級 / 指令遵循 |
-| Standard | 均衡推理 + 程式碼生成 |
-| Capable | 進階推理、架構分析 |
+**與廠商無關原則**：等級名稱（Fast／Standard／Capable）與 effort 標籤（`low` … `max`）都是工具無關的泛稱，不對應任何特定廠商的模型識別碼或參數名稱。各平台自行維護「等級 → 模型」映射、「effort 標籤 → 參數」映射，以及自己的硬邊界登記。
 
 ---
 
 ## 相關標準
 
-- [代理派遣與並行協調](agent-dispatch.md)
-- [驗證證據](verification-evidence.md)
-- [系統化除錯](systematic-debugging.md)
+- [代理派遣與並行協調](agent-dispatch.md) — **怎麼派**：並行安全、獨立域判準、狀態協定、prompt 設計。本標準管的是**派給誰、想多深**；兩者互補，且**不得互相重寫**——並行安全規則屬於該標準，不屬於這裡。
+- [驗證證據](verification-evidence.md) — 為何「沒有擲出錯誤」不是成功的證據；[R3b](#r3b-反向風險) 拒絕標記要求的依據
+- [系統化除錯](systematic-debugging.md) — 先診斷再修改，在此適用於「深度不足 vs 天花板不足」的判斷
 
 ---
 
 ## 版本歷史
 
+> **關於排序**：各列依**版本序**排列，非日期序。版本 `2.0.0`（2026-04-13）早於
+> `1.0.1`（2026-06-10），因為當時能力管理章節自帶一條獨立的版本序。
+> 2.1.0 移除了章節版本，見[版本欄語意](#版本欄語意)。
+
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| 2.1.0 | 2026-08-11 | **二軸重構（XSPEC-362）**。模型軸判準由檔案數改為「推理天花板需求 × 規格明確度」（R1）。新增正交的 effort 軸，含與廠商無關的級距與「深度不足 vs 天花板不足」失敗診斷（R2）。新增反向排除規則：硬邊界，以及安全分類器拒絕作為靜默失效（R3）。`capability_dimensions` 子維度拆為 `declared` / `measured`（R7b）；`routing_rules` 擴為四態，分離 `UNKNOWN` 與 `UNSUPPORTED`（R7a）；三條獨立重測觸發（R7c）。`capability_registry` examples 改為佔位符，新增 90 天逾期 WARN（R4）。移除章節版本；明訂 `.ai.yaml` 的 `meta.version` 對應全檔版本（R6a）。新增規則 MS-005–MS-010、CAP-006–CAP-008。 |
+| 2.0.0 | 2026-04-13 | 新增 LLM 能力管理章節（XSPEC-027 Phase 1）：`capability_dimensions`、`capability_registry`、`routing_rules`。*本列於 2.1.0 回溯補登——此變更當時從未進入版本歷史。* |
 | 1.0.1 | 2026-06-10 | 新增「與下一步建議整合」節（R6 交叉引用；與廠商無關原則） |
 | 1.0.0 | 2026-03-20 | 初始版本 |

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

@@ -1,9 +1,9 @@
 ---
 source: ../../../core/mutation-testing.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-06-10
-source_hash: 6a5286d76274
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-08-14
+source_hash: 8eeaea8d9cc3
 status: current
 ---
 
@@ -11,8 +11,8 @@ status: current
 
 > **Language**: [English](../../../core/mutation-testing.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-05-04
+**版本**: 1.1.0
+**最後更新**: 2026-08-14
 **適用範圍**: 所有具備單元/整合測試的軟體專案
 **Scope**: universal
 **產業標準**: ISTQB Foundation Syllabus（測試有效性指標）
@@ -39,6 +39,42 @@ Mutation Score = Killed Mutants / (Killed + Survived) × 100%
 
 ---
 
+## 歸因：kill 記給第一個失敗的測試
+
+「Killed」代表這一輪執行中**有某個**測試對該突變體斷言失敗——大多數工具不會記錄是**哪一個**測試殺死了它，更不會記錄是**哪一層**。因此 7/7 的 kill score 驗證的是**對該突變體執行過的整套測試**，不是任何單一測試，也不是任何單一測試層級（unit vs. integration vs. property）。
+
+**後果**：「property suite 驗證了 X」這句話，並不是一次聚合的 mutation run 所能支持的主張。要支持它，必須**只啟用 property suite** 重跑 mutation testing：
+
+```bash
+npx stryker run --mutate 'src/module/**' -- --project=property
+```
+
+若隔離執行殺死的突變體比聚合執行少，這個差距正是 unit/integration 測試原本悄悄替它涵蓋掉的部分。
+
+**規則**：高風險模組（與 80% 門檻適用的同一集合——auth/license/payment/security）在宣稱「已被 property 驗證」之前，必須先單獨對 property suite 重跑一次突變。
+
+---
+
+## 單邊不變式抓不到 fail-closed 缺陷
+
+像「輸出永不超過上限」這種性質是單邊的：它結構上抓不到讓程式碼**fail closed**（拒絕一切，包含合法輸入）的突變體——因為 fail-closed 的突變體永遠不會產生超過上限的輸出。Mutation score 看起來毫髮無傷，而一整類缺陷（阻斷服務、錯誤拒絕合法請求）對這套測試完全隱形。
+
+**修法**：每個單邊不變式都要配一個相反邊界的性質——「永不超過上限」需要一個搭檔性質，例如「上限以下的都會被接受」——讓過度寬鬆與過度嚴格的突變體都各自有一條被抓到的路徑。
+
+---
+
+## Equivalent mutant 不是要追殺的存活者
+
+一個存活的突變體不會自動等於測試缺口。有些突變體與原始程式碼**語意等價**——沒有任何輸入能區分兩者的行為——不管測試怎麼寫都殺不死它。用一個只為了推高分數而存在的斷言（例如對一個無關緊要的值加 `toBeDefined()`）硬殺，只會製造一個空心測試，沒有真的補上任何缺口。
+
+**每個被審查過的存活者都必須被分類**：
+- **真缺口** → 寫一個能觸發那個可區分行為的測試。
+- **`equivalent, because <理由>`** → 連同為了得出此結論而檢查過的輸入一併記錄。
+
+未分類的存活者，不等於已分類為 equivalent 的存活者。只有已分類為 equivalent 的突變體，才可以從分母中排除。
+
+---
+
 ## 工具
 
 | 語言 | 工具 | 指令 |
@@ -96,6 +132,9 @@ npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner
 - 在每個 PR 的 CI 中都加入突變測試（太慢）
 - 未經 mutation score 驗證就接受 AI 生成的測試
 - 靠加 `toBeDefined()` 斷言來殺死突變
+- 用一次聚合（非隔離）的 mutation run 就宣稱「property suite 驗證了 X」
+- 對有 fail-closed 失效模式的性質，只用單邊不變式
+- 對語意等價的突變體硬殺，而不是分類為「equivalent, because <理由>」
 
 ---
 

package/bundled/locales/zh-TW/core/test-governance.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/test-governance.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-04-20
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-08-14
 status: current
 ---
 
@@ -72,6 +72,23 @@ status: current
 | 程式碼審查完成 | 至少一位審查者核准 |
 | 文件更新 | API 文件和 CHANGELOG 已更新 |
 
+### 門檻閘門必須 Fail Closed
+
+一個印出百分比、卻無論有沒有達標都以 exit code `0` 結束的量測層，是一份報告，不是一道閘門。它會在自己印出的數字連續多次 commit 持續下滑時始終保持綠燈，而沒有東西擋下下一次合併。
+
+任何有通過/失敗門檻的檢查（coverage、lint、mutation score，或任何有界的量測指標）都必須把「未達門檻」轉譯成非 0 的 exit code——透過工具自己的強制旗標，而不是透過事後重新解析輸出的包裝腳本：
+
+| 工具 | Fail-closed 旗標 |
+|------|-------------------|
+| pytest-cov | `--cov-fail-under=<N>` |
+| coverage.py | `coverage report --fail-under=<N>` |
+| diff-cover | `diff-cover coverage.xml --fail-under=<N>` |
+| nyc / Istanbul | `--check-coverage --lines <N>` |
+| Stryker Mutator | `stryker.config.json` 中的 `thresholds.break` |
+| ESLint | `--max-warnings 0` |
+
+一個計算出數字、印出來、卻永遠 `exit 0` 的包裝腳本，既不滿足本條規則，也不滿足 `verification-evidence` 的證據有效性規則 1——工具的 exit code 不再帶有任何關於它量測對象的資訊。
+
 ## 測試環境管理
 
 | 環境 | 用途 | 管理責任 |
@@ -89,6 +106,7 @@ status: current
 | pyramid-compliance | 規劃測試策略時 | 以 70/20/7/3 金字塔比例為指引。可接受偏差，但需有文件記錄的正當理由 | 必須 |
 | sit-isolation | 執行系統測試時 | 系統測試應對外部相依性使用 Stub，但使用真實的內部服務。使用 SIT 環境進行系統層級的驗證 | 建議 |
 | test-execution-continuity | 新增或完成測試案例時 | 測試案例必須連接到自動化執行觸發器（CI gate、build hook 或排程執行）。存在但從未執行的測試提供假信心，比沒有測試更糟。在將測試覆蓋率標記為完成前，請確認執行歷程存在。| 必須 |
+| fail-closed-threshold-gate | 設定或審查任何 coverage/lint/mutation 或其他門檻檢查時 | 該檢查必須使用工具自己的 fail-under（或等價）強制旗標，使其在未達門檻時以非 0 退出。只印出數字、永遠 exit 0 的腳本是報告，不是閘門，不滿足本條 | 必須 |
 
 ---
 
@@ -97,3 +115,4 @@ status: current
 - [測試標準](testing-standards.md)
 - [提交規範](checkin-standards.md)
 - [部署標準](deployment-standards.md)
+- [驗證證據標準](verification-evidence.md) —— 證據有效性規範的是產出 exit code 之後如何**解讀**它；`fail-closed-threshold-gate` 規範的是閘門必須如何被**建造**，讓 exit code 一開始就帶有真實資訊

package/bundled/locales/zh-TW/core/translation-lifecycle-standards.md

@@ -3,7 +3,7 @@ source: ../../../core/translation-lifecycle-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
 last_synced: 2026-04-20
-status: current
+status: stale
 ---
 
 # 翻譯生命週期標準