context 的 token 預算應是 per-model 參數而非全域寫死 200：7 個 engine 只有 2 個吃 prompt，其餘照樣截斷且照印 injected(N)

[kiki830621]

Problem

Original text（使用者原話，2026-08-07）：
「應該要分開，當作重要的模型參數來考慮」

PromptRenderer.defaultTokenBudget = 200 是全域寫死的單一常數，套用到所有 backend。但 prompt 能力是逐模型的性質，差異極大：多數 backend 根本不吃 prompt，而吃的那些上限也不同。目前的設計把「Whisper 的限制」當成「所有引擎的限制」。

Type

feature

Priority

P1。這不只是設計潔癖 —— 它讓 context biasing 在預設路由下靜默失效，而 CLI 還印出成功訊息（見下方 Impact）。

Actual（現況，逐項在原始碼查證）

一、預算是單一全域常數，無任何 per-model 概念

// Sources/BestASRKit/Context/PromptRenderer.swift
public static let defaultTokenBudget = 200

public static func render(_ context: LoadedContext,
                          tokenBudget: Int = defaultTokenBudget) -> Rendered

參數位存在，但全 codebase 無任何呼叫點傳非預設值 —— 只有一個 call site：

Sources/BestASRKit/CommandCore.swift:103
    return ContextBundle(loaded: loaded, rendered: PromptRenderer.render(loaded))

二、7 個引擎中只有 2 個會消費 prompt

引擎	原始碼中 prompt 出現次數
WhisperKitEngine	12
WhisperCppEngine	5
ParakeetEngine	0
AppleSpeechEngine	0
ChineseFamilyEngine（paraformer／sensevoice）	0
ExternalProcessEngine	0
Engine（protocol）	0

對那 5 個引擎，整套 render 照跑、截斷照發生、injected (N) 照印 —— 然後產物被丟棄。

三、連「吃 prompt 的那兩個」限制也不同，且無一由 renderer 感知

• WhisperKitEngine.clampedPromptTokens(_:limit:224) —— tokenizer 實測的 224，取 suffix(224)
• WhisperCppEngine —— 無自訂 clamp，直接 --prompt <字串> 交給 whisper-cli，理論上可超過 200

註解本身寫明 200 是為 Whisper 調的：

/// ~200-token budget, below Whisper's ~224 practical prompt limit; the
/// WhisperKit engine additionally clamps encoded tokens as a safety net.

設計本身很嚴謹 —— 問題是它被無條件套用到不是 Whisper 的東西。

四、suffix(224) 的方向與 renderer 的優先序相反

PromptRenderer 依 names → terms → phrases 排序，最重要的排最前。clampedPromptTokens 溢出時取 suffix(224)，砍掉的正是最前面的人名。目前 200 < 224 撞不到，但兩個機制的優先方向不一致，是潛在的坑。

Impact

這不是理論問題 —— 實測已經咬到。 2026-08-07 轉錄 IMPS 2026 會議錄音（10 檔約 7.3 小時）時：

recommend 在 high profile 選出 fluid-parakeet 0.6b-v3（「ranked #1 of 20 benchmarked candidates」，WER 6.1%）—— 也就是唯一完全不吃 prompt 的那一類。CLI 照樣印：

Context: <…>/.bestasr/context
  injected (49): Che Cheng, Che, Hau-Hung Yang, …, Joint Thurstonian, …
  truncated (53): criterion-related validity, …, Q-matrix, …

看起來 context biasing 生效了。實際上完全沒有：

目標詞	無 context 探針	parakeet ＋ context	whisper 無 context	whisper ＋ context
Joint Thurstonian	「during the thumbia」	「during Sonya」	「joint adornment models」	「Joint Thornia Models」
Likert	「the request scale」	「the scale or L F」	—	—

Joint Thurstonian 與 Likert scale 都在已注入的 49 個裡，parakeet 命中數 0。同一段音訊換 whisper.cpp large-v3-turbo，context 讓輸出從「joint adornment」修到「Joint Thornia」並辨識為專有名詞 —— 證明 context 本身有效，失效的是 backend。

三個後果：

1. 使用者被誤導。injected (N) 讀起來是「已生效」，實際上對 5/7 引擎是 no-op。使用者會據此去精簡詞表 —— 白工。
2. benchmark 路由與 context 目標衝突。routing 只看 WER，於是在有 context_dir 的情況下仍可能選中不吃 prompt 的引擎。而該 benchmark 語料顯然不像會議廳＋專業術語音訊 —— 排名第一的模型在這批素材上可讀性最差。
3. 截斷是真的發生的。實測 102 個項目只注入 49、截斷 53：42 個人名吃掉 171 tokens（85.5%），52 個術語只擠進 7 個，8 個 phrases 因 exhausted flag 被整類丟棄。對 parakeet 而言這整段計算與取捨都毫無意義。

Expected

把 prompt 預算視為引擎能力宣告，而非全域常數：

• Engine protocol 增加 prompt 能力宣告，兩態即可：不支援 / 支援且上限 N（兩個 whisper backend 實測上限皆為 224；若日後接入上限未知的後端再擴為三態）
• PromptRenderer.render 由所選引擎取得 budget，而非 defaultTokenBudget
• 引擎不支援 prompt 時整段跳過 render，並明確告知使用者「此後端不支援 context biasing」——不要印 injected (N)
• WhisperCppEngine 的上限明確設為 224（whisper-cli 文件的 n_text_ctx/2；並非「無上限」——先前以為它沒有 clamp 所以可高於 200，實測其說明明文標示上限，與 WhisperKit 一致）
• 檢視 clampedPromptTokens 的 suffix 方向是否應改為 prefix，以與 renderer 的優先序一致
• recommend / routing 在偵測到 context 存在時，把「是否支援 prompt」納入選型考量；至少在選中不支援的引擎時發出警告

Residue

「哪個模型在會議廳音訊上最好」不是本 issue 能解的。本 issue 只處理能力宣告的正確性 —— 讓系統不再宣稱做了它沒做的事。benchmark 語料是否該擴充到會議／演講類音訊，是另一條線（現行語料顯然讓 parakeet 在此類素材上被高估）。

相關

• #163 —— 同批診斷發現的安裝問題（release 不含 resource bundle）。兩者獨立：transcribe 在乾淨安裝上必 crash：release 未含 resource bundle、fallback 路徑寫死、sidecar 版本說謊導致 wrapper 永不自癒 #163 是裝不起來，本 issue 是裝起來了但 context 悄悄失效。
• 觸發脈絡：kiki830621/chchen-lab#12（IMPS 2026 會議錄音轉錄，private repo）。

Clarity Surface（idd-clarify run 2026-08-06T18:55:06Z）

Type	Source	Suggested canonical	Status
ambiguity	「應該要分開，當作重要的模型參數來考慮」	「分開」有兩種讀法：(a) budget 數值依模型不同（本 issue 採此解）；(b) 連 render 是否執行、能力宣告本身都依模型分流（Expected 第 3 點涵蓋）。兩者相容但工作量差一級，實作前宜確認範圍	resolved @ 2026-08-06T20:04Z（reason: scope = (a)+(b) 兩者皆含。依據為本 issue Expected 自身已同時列出兩層 —— 第 2 項「render 由所選引擎取得 budget」屬 (a)，第 1 項「Engine protocol 增加 prompt 能力宣告」與第 3 項「不支援時整段跳過 render」屬 (b)。Complexity 即按此範圍評定。⚠ 此為 diagnose 階段的明示假設：若原意僅為 (a)，請據此收窄 Expected 並重評 —— 範圍收窄會使 #129 硬閘的觸發理由改變）
missing-context	「支援但上限未知（交由後端自行截斷）」	已解：whisper-cli --help 明文 --prompt PROMPT initial prompt (max n_text_ctx/2 tokens)；Whisper 模型 n_text_ctx = 448 → 224，與 WhisperKitEngine.clampedPromptTokens 的 224 相同。兩個 whisper backend 上限一致，第三態（上限未知）可能不需要	resolved @ 2026-08-06T19:00Z（reason: whisper-cli 說明文件實測確認上限為 n_text_ctx/2 = 224）
terminology	「prompt」	本 issue 全文指 ASR decoder 的 conditioning text（Whisper 的 initial_prompt / promptTokens），非 LLM 意義的 prompt。混淆會誤導實作者往錯的抽象層找	dismissed @ 2026-08-06T20:04Z（reason: 該列本身即為正確的 canonical 定義，且本 issue 全文用法與之一致（WhisperKitEngine.clampedPromptTokens / whisper-cli --prompt 皆為 decoder conditioning text）。無待決事項，保留作為術語註記）

---

Current Status

Phase: proposed（Spectra tier）

欄位	值
Diagnosis	#164 comment（2026-08-07）
Conflict Class	C_shared_module_coord — Engines/Engine.swift public protocol ＋ 6 conformer
Complexity	Spectra（Layer 2 ＋ Layer 3 皆命中：public protocol ＋4th requirement × 6 conformer；跨 ≥4 子系統且設計空間互斥）
排序	必須排在 #165 之後（先收斂 spawn seam，再擴 protocol）
明示假設	scope = (a)+(b)（依 Expected 自身涵蓋範圍）。若原意僅 (a)，Layer 2 不命中、複雜度降為 Plan／Simple —— 收窄 Expected 後重跑即可
設計建議	能力宣告採二態（第三態目前無 instance）；不給預設實作（給預設等於允許沉默，與本 issue 初衷相反）
提案	✅ per-engine-prompt-capability 已建立、validated、parked（摘要）
⚠️ 存放位置	parked change 在 .git/spectra-app/changes/，不受 git 追蹤、不會 push —— 關鍵決策已鏡射於上述 comment
下一步	/spectra-apply per-engine-prompt-capability（自動 unpark 並開始實作）

[kiki830621]

Diagnosis

Type

feature

Root Cause / Analysis（需求分析）

Issue 的問題陳述在原始碼上完全成立，本節補上routing 需要的結構事實。

現況：預算是全域常數，只有一個 call site

// Sources/BestASRKit/Context/PromptRenderer.swift
public static let defaultTokenBudget = 200
public static func render(_ context: LoadedContext, tokenBudget: Int = defaultTokenBudget) -> Rendered

全 codebase 對 PromptRenderer.render 只有一處呼叫：

Sources/BestASRKit/CommandCore.swift:103
    return ContextBundle(loaded: loaded, rendered: PromptRenderer.render(loaded))

含意：把 budget 改成「由所選引擎提供」的管線改動本身很小（一個 call site）。真正的成本不在這裡。

成本在這裡：Engine 是 public protocol，有 6 個 conformer

// Sources/BestASRKit/Engines/Engine.swift:61
public protocol Engine: Sendable {
    var id: BackendID { get }
    func isAvailable() async -> Bool
    func transcribeRaw(audioPath:options:) async throws -> RawTranscription
}

目前 3 個 requirement。本 issue 的 Expected 第 1 項要加第 4 個。in-repo conformer 有 6 個：

WhisperKitEngine / WhisperCppEngine / ParakeetEngine / AppleSpeechEngine / ChineseFamilyEngine / ExternalProcessEngine

public 意味著契約也對未來的、以及 repo 外的引擎作者生效。這不是內部重構，是改公開契約。

需求拆解（範圍：(a)+(b)，見 Clarity Surface 的 resolved 註記）

#	需求	觸及
R1	Engine 宣告 prompt 能力	Engine.swift ＋ 6 conformer
R2	render 的 budget 來自所選引擎	PromptRenderer ＋ CommandCore:103
R3	不支援時整段跳過 render，且不印 injected (N)	CommandCore ＋ CLI 輸出
R4	WhisperCppEngine 上限獨立設定	WhisperCppEngine
R5	clampedPromptTokens 的 suffix 方向檢討	WhisperKitEngine
R6	recommend / routing 納入 prompt 支援度	routing / benchmark 選型

R1 與 R6 是設計決策，不是實作細節 —— 它們的形狀決定了往後所有引擎的樣子。這是 routing 判定的關鍵（見 Complexity）。

一個已可收斂的事實（縮小設計空間）

Clarity Surface 的 missing-context 列已解：whisper-cli --help 明文 --prompt PROMPT (max n_text_ctx/2 tokens)，Whisper n_text_ctx = 448 → 224，與 WhisperKitEngine.clampedPromptTokens(limit: 224) 相同。

兩個 whisper backend 上限一致 → 原 Expected 的第三態「支援但上限未知」目前沒有任何 instance。 這直接影響 R1 的 enum 形狀（見 Strategy）。

Impact

影響的檔案

檔案	改動
Sources/BestASRKit/Engines/Engine.swift:61	public protocol ＋1 requirement
Engines/{WhisperKit,WhisperCpp,Parakeet,AppleSpeech,ChineseFamily,ExternalProcess}Engine.swift	6 個 conformer 各自宣告
Context/PromptRenderer.swift:12	defaultTokenBudget 去全域化
CommandCore.swift:103	唯一 call site，改為傳入引擎 budget ＋ 不支援時跳過
routing / recommend	選型納入 prompt 支援度

影響的使用者流程（已實測，非理論）

recommend 在 high profile 選出 fluid-parakeet 0.6b-v3（「ranked #1 of 20 benchmarked candidates」，WER 6.1%）—— 正是完全不吃 prompt 的那一類。CLI 仍照印 injected (49) / truncated (53)。

目標詞	parakeet ＋ context	whisper ＋ context
Joint Thurstonian	「during Sonya」	「Joint Thornia Models」
Likert	「the scale or L F」	—

injected (N) 對 5/7 引擎是 no-op，但讀起來像「已生效」。 使用者會據此精簡詞表 —— 白工。且截斷是真的發生的：102 項只注入 49、截斷 53（42 個人名吃掉 171 tokens，8 個 phrase 因 exhausted 整類丟棄），對 parakeet 而言整段取捨毫無意義。

Strategy

設計決策一：能力宣告的形狀（建議二態 ＋ 明確擴充路徑）

選項	形狀	評估
三態	不支援 / 上限 N / 上限未知	原 Expected 提案。但第三態目前沒有 instance（兩個 whisper 皆 224）。加一個沒人用的 case，等於要求 6 個 conformer 與所有未來作者處理一個不存在的情況
二態（建議）	case unsupported / case supported(maxTokens: Int)	涵蓋全部現況。日後真出現「上限未知」的後端，再加 case —— 屆時有真實的 instance 可以驗證語意，而不是現在憑想像定義

設計決策二：protocol requirement 要不要給預設實作

選項	效果
必須實作（無預設）	6 個 conformer 全部要改；未來新引擎作者被迫思考這件事
給預設 .unsupported	改動小、非破壞性；但新引擎預設靜默不支援 context —— 正是本 issue 要消滅的失敗模式（宣稱做了沒做的事）的變體

建議：不給預設。 本 issue 的核心命題就是「能力必須被明確宣告」；給預設等於允許沉默，與初衷相反。6 個 conformer 一次改完是有界成本。

實作項

• R1 Engine 加 prompt 能力宣告（二態，無預設實作）
• R1' 6 個 conformer 各自宣告：WhisperKit .supported(224)、WhisperCpp .supported(224)、其餘 4 個 .unsupported
• R2 render 由所選引擎取 budget，移除 defaultTokenBudget 的全域角色
• R3 .unsupported 時整段跳過 render，改印「此後端不支援 context biasing」——不印 injected (N)
• R5 clampedPromptTokens 改 suffix → prefix，與 renderer 的 names → terms → phrases 優先序一致（目前 200 < 224 撞不到，但方向相反是既存的坑）
• R6 routing 在偵測到 context_dir 存在時納入 prompt 支援度；至少選中 .unsupported 引擎時警告
• 測試：.unsupported 引擎 ＋ 有 context → 斷言不印 injected、不執行 render

Conflict Class

C_shared_module_coord

共享資源具名：Sources/BestASRKit/Engines/Engine.swift 的 public Engine protocol 及其 6 個 conformer，加上 Context/PromptRenderer.swift 與唯一 call site CommandCore.swift:103。

與 #165 的排序（硬性）：#165 要在 同一個 Engines 層抽出共用 spawn helper 並做 family-wide sweep。兩者不可並行，且 #165 必須先做 —— 先把 spawn seam 收斂，再擴 protocol；反序會讓本 issue 的 protocol 擴充建在待重構的結構上，兩邊都要重做。

與 #163 無衝突（packaging 子系統，正交）。

Complexity

Spectra

7-step routing 逐項：

Step	判定
1. type=meeting	否（feature）
2. Layer 1 disqualifier	未命中
3. Layer V	未觸發（V1=2, V4=2；見下方 audit）
4. Spectra（Layer 2 ＋ Layer 3）	兩者皆命中 → Spectra（在 #129 硬閘之前即分流）
5–7	不需評

Layer 2（published API 給 future callers）—— 命中：Engine 是 public protocol，目前 3 個 requirement、6 個 in-repo conformer。本 issue 加第 4 個 requirement。public 使契約同時對 repo 外與未來的引擎作者生效。enum 形狀一旦定案，改動成本乘以所有 conformer —— 這正是需要先寫 spec 的情況。

Layer 3（跨子系統 ＋ 真實設計空間）—— 命中：

• 跨子系統：Engines（6 檔＋protocol）／Context/PromptRenderer／CommandCore／routing・recommend／CLI 輸出語意，≥4 個。
• 設計空間是真的、且選項互斥：二態 vs 三態（且已知第三態無 instance）；有無預設實作（非破壞性 vs 強制明確宣告）；suffix vs prefix（與既有優先序衝突）；routing 是警告 / 重排 / 硬性過濾。

這些不是實作細節 —— 每一個都改變往後所有引擎的樣子。

Layer V audit：V1 = 2、V4 = 2，未觸發。但 V1 是在 Clarity Surface 的 ambiguity 列被 resolve 之後才降到 2 —— resolve 前該列指出「(a) 僅 budget 數值 vs (b) 含能力宣告與 render 分流，工作量差一級」。本次以 scope =(a)+(b) 進行評估，依據是 issue Expected 自身已同時列出兩層。

⚠ 明示假設：若原意僅為 (a)（單純讓 budget 依模型不同），則 R1／R3／R6 應退出範圍，Layer 2 不再命中，複雜度會降到 Plan 甚至 Simple。此假設可逆 —— 收窄 Expected 後重跑 diagnose 即可。

Risks

• 改 public protocol 是廣播式改動。6 個 conformer 全部要動；若日後有 repo 外的引擎實作，加 requirement 是 source-breaking。不給預設實作（建議做法）會放大這點 —— 這是刻意的取捨，但必須是明知的取捨。
• suffix → prefix 是行為改動而非純修正。目前 200 < 224 撞不到，改了在現況下無可觀測差異；但一旦 budget 依引擎提高到 224，兩種方向會產出不同的 prompt。需要在 budget 提高之前改，否則會混入其他變因。
• R6 改 routing 會改變預設選出的模型，直接影響使用者拿到的逐字稿品質基線。有 context_dir 時偏好支援 prompt 的引擎，可能選到 WER 較高的後端 —— 「WER 較低」與「能吃 context」何者較優並未量測（見 Residue）。
• 與 #166 交互：#166 顯示 whisper ＋ 長 prompt 會誘發重複迴圈。若 R6 讓 routing 更常選中 whisper 以支援 context，可能提高踩到 #166 的機率。兩者應一併考慮，否則本 issue 的「修好」會把使用者推進另一個坑。

Residue

「哪個引擎在會議廳音訊上最好」不是本 issue 能解的。 本 issue 只處理能力宣告的正確性 —— 讓系統不再宣稱做了它沒做的事。

但由此暴露一個更大的、本 issue 無法承擔的問題：benchmark 語料顯然不像會議廳＋專業術語音訊。排名第一（WER 6.1%）的 parakeet 在這批素材上可讀性最差。R6 讓 routing「納入 prompt 支援度」只是在一個可能本身就失準的排序上加一個修正項 —— 語料是否該擴充到會議／演講類音訊，是獨立的一條線。

第二層殘留：「支援但上限未知」的第三態被建議延後，理由是目前無 instance。這是基於現況的判斷，不是對未來的保證 —— 若日後接入的後端確實無法宣告上限，屆時需要重開這個設計決策，而那時已有 6+ 個 conformer 綁在二態上。此處記錄該取捨，使日後回看時知道它是被明知地推遲，而非漏想。

---

Sister Concerns Filed

（IC_R011 audit trail — Step 3.6 sister sweep）

來源	處置
「benchmark 語料不像會議廳＋專業術語音訊，排名第一的模型可讀性最差」（Residue 第一段）	已開 #167 — 含實測對照與「排名帶著量測數字反而更誤導」的論證。#164 的 R6 依賴 #167 才有意義
「第三態（上限未知）被延後」（Residue 第二段）	未另開 — 是本 issue 的明知取捨、已記錄於 Residue，非獨立缺陷
「R6 可能提高踩到 #166 的機率」（Risks 末項）	未另開 — 交互風險，已在本 issue Risks 交叉引用 #166

本輪 batch 的 sister sweep 共開出 #166（--prompt 重複迴圈，自 #165）與 #167（語料代表性，自本 issue）。

[kiki830621]

Spectra 提案已建立並 parked

Complexity 判定為 Spectra，故不走 /idd-implement。已完成 /spectra-propose，產出並通過驗證：

per-engine-prompt-capability — valid
  proposal.md
  design.md
  tasks.md                      [0/14]
  specs/asr-engine/spec.md
  specs/context-calibration/spec.md
  specs/asr-routing/spec.md

下一步：/spectra-apply per-engine-prompt-capability（會自動 unpark 並開始實作）。

⚠️ parked change 存放於 .git/spectra-app/changes/，不受 git 追蹤、不會 push。 本 comment 因此完整記錄關鍵決策，使其不依賴單一機器存活。

---

受影響的既有 capability（三個，皆為 MODIFIED／ADDED delta）

Spec	變更
asr-engine	MODIFIED Common engine interface —— 介面增加 promptCapability，且明訂不得提供預設實作
context-calibration	MODIFIED Render context into a natural-language prompt with priority and budget（預算改由引擎提供）＋ MODIFIED Explain discloses context usage（不支援時不得宣稱注入）
asr-routing	ADDED Selection accounts for prompt support when context is present

五個設計決策（含否決理由）

D1：能力宣告採二態，而非三態。 否決原 issue 的第三態「支援但上限未知」—— 目前沒有任何 instance（兩個 whisper backend 上限同為 224）。為不存在的情況新增 case，等於要求 6 個 conformer 與所有未來作者處理一個無法驗證語意的分支。代價是日後若真需要第三態，會是第二次 source-breaking；接受。

D2：protocol requirement 不給預設實作。 給 .unsupported 預設會讓新引擎預設靜默不支援 context —— 正是本變更要消滅的「宣稱與實際不符」的變體。代價是 6 個 conformer 一次全改、且對 repo 外實作 source-breaking。這是明知的取捨：一次有界成本，換往後每個新引擎都被迫回答這個問題。

D3：不支援時跳過整段 render，而非渲染後丟棄。 截斷計算與 exhausted 判定對該引擎無意義，跑了只產生誤導性統計；且 explain 措辭需在同一判斷點決定。

D4：截斷方向必須與優先序一致，且要先做。 渲染優先序是 names → terms → phrases，但 WhisperKit 的 clamp 取後綴，砍掉的正是最前面的人名。目前 200 < 224 撞不到故無可觀測差異 —— 正因如此容易被當成無效改動而省略。必須在提高預算之前落地並附測試，否則兩個變因混在一起無法歸因。

D5：routing 納入支援度但不硬性過濾。 「WER 較低」與「能吃 context」孰重並未量測，硬排可能擋掉明顯較準的引擎。發警告把判斷交還使用者，不假裝系統知道它其實不知道的事。

兩項對使用者可見的變化（tasks 6.3 要求寫進 CHANGELOG）

1. Engine protocol 增加 requirement —— breaking change。
2. 同一份 context 在 Whisper 後端的注入量會增加（預算 200 → 224）。屬預期改善，但需標明，避免被誤認為模型行為漂移。

分析器殘留（2 項，未阻擋）

spectra analyze 由 9 項 Critical/Warning 降至 2 項，皆為 matcher 層面而非覆蓋缺口：COV-1 指稱 Render context… 無對應 task、CON-1 指稱 D5 未被 tasks 引用 —— 但兩者分別出現在 §1／§4 的段落標題與 task 5.2 內文。研判 matcher 只掃 task bullet 行、不掃段落標題。依 skill 的 2 輪上限規定不再續修，如實記錄。

明示假設（沿用 diagnose 階段）

scope 取 (a)+(b)（預算數值 ＋ 能力宣告與 render 分流），依據為本 issue Expected 自身已同時列出兩層。若原意僅為 (a)，則 D1／D2／D5 與 asr-engine、asr-routing 兩個 delta spec 應退出範圍，複雜度亦會降回 Plan —— 屆時整個 change 重提即可。

[kiki830621]

Spectra apply 完成 — 14/14，PR #173

per-engine-prompt-capability 全部落地（TDD 全程，.spectra.yaml 的 tdd／audit 紀律皆套用）。三個 commit：338c677（任務 1–6）、58c4abc（7–10）、3b3158d（11–14）。462 tests / 91 suites 全綠。

兩件事讓「完整性」不靠我的記性

protocol requirement 不給預設實作（D2）→ 建置失敗並逐一列出所有未宣告的 conformer。這份編譯器產生的清單成為宣告工作的依據 —— 然後它抓到我漏掉的第 7 個：測試側的 MockEngine。我在 diagnose 階段說「6 個 conformer」，編譯器證明是 7 個。

ContextBundle.rendered 改為 optional → 編譯器同樣列出每一個必須決定「哪一種情況」的消費點，包括 explain 與 benchmark 兩處我原本沒想到的。

兩個 collateral 失敗，形狀相同且值得記錄

兩個 mock engine 宣稱自己是 .whisperKit（會吃 prompt 的後端）卻繼承了 .unsupported 預設，於是 context 被正確跳過、關於注入計數的斷言就掛了。

這正是本變更要消滅的「宣告與行為不符」，出現在測試替身裡。 MockEngine.fixed 現在要求明確傳入 capability —— 替身必須說清楚它替的是什麼。

測試自身的誠實性

• 預算測試附反空過保護：先斷言 fixture 真的能分辨 200 與 224，否則後面的斷言不論接線對錯都會過。
• 5.2 的測試寫到一半發現我的前提是錯的：只註冊一個 parakeet mock 並不會讓 router 選 parakeet —— 它依 cold-start prior 選了 whisper.cpp（該測試裡沒有註冊對應 engine），斷言等於在測 routing 而非 capability。改為顯式 pin backend。

設計取捨（review 時值得看）

二態而非三態：被否決的第三態「支援但上限未知」全樹沒有任何 instance，兩個 whisper backend 上限都是 224。為不存在的情況加 case，等於要求每個 conformer 處理一個無法對照現實驗證的分支。

零預算規則放進型別：.supported(maxTokens: 0) 在 PromptCapability 內部就收斂為「不支援」，任何呼叫端都無法忘記或實作得不一樣。

選型只警告、不重排（D5）：「較低 WER」與「能吃 context」孰重並未量測，安靜地降級某後端，跟安靜地宣稱注入發生了，是同一種越權。

對使用者可見的兩項變化（已寫進 CHANGELOG）

1. Engine protocol 新增 requirement —— breaking。
2. Whisper 後端預算由 200 提高到實測上限 224 → 同一份 context 會有更多內容進到模型，該處逐字稿會有差異。屬預期改善，非模型行為漂移 —— 措辭已明確標示，避免被誤判。

順序

從 main 開 branch，與 #165／#163 相互獨立。與 #165 動到同一批檔案但屬不同區域，merge 順序不具約束力 —— 我先前提的順序顧慮，實際做完後確認是 merge 成本而非正確性問題。

下一步：/idd-verify #164 --pr 173。

[kiki830621]

Verify round 1 — FINDINGS

完整報告在 PR #173：#173 (comment)

摘要：

• Blocking：benchmark 的第三個 loadContext call site 沒帶 capability，BenchmarkRunner 的 candidate loop 無條件把 rendered prompt 餵給每個 candidate（含宣告 .unsupported 的 parakeet / chinese-family / apple-speech，這些都在預設 grid 內）。直接違反本次新寫的 asr-engine spec「an engine that declares no support never receives a rendered prompt」，並產出一個沒有意義的 %(CTX) delta——在 benchmark 出口重現了 context 的 token 預算應是 per-model 參數而非全域寫死 200：7 個 engine 只有 2 個吃 prompt，其餘照樣截斷且照印 injected(N) #164 要消滅的那類錯誤陳述。4 個 lens 各自獨立命中，逐行覆核成立。
• 次要：D5 warning 只接在 recommend，transcribe 沒接（spec 字面不合規，補一行即可；reviewer 說「零揭露」的因果指錯了——transcribe 沒有 --explain 時本來就不印任何 warning，屬既有行為，另開 issue）。
• D4 clamp 方向（我自己標記要 reviewer 獨立判斷的那題）：四條腿沒有任何一條主張 revert。三條獨立導出同一個持久解——重排 PromptRenderer 優先序讓高價值項落在尾端，而不是再翻 clamp。D4 維持現狀、task 1.1 不重做，renderer 重排另開 issue。
• Process gap：DA 與 Codex 兩條腿各重試 5 次全部 stalled 未完成。Codex leg 已是連續第 4 輪失敗，完整 6/6 一次都沒達成，屬結構性問題。

未上 idd-164-verified tag。