"Strategy"
- 三層定義與職責表
Unit Test / Protocol Integration Test / Screen State Test 各層職責、驗證目標與盲區的完整論述
- 判斷原則：什麼時候需要 protocol integration test
從服務架構特徵判斷是否需要 protocol integration test 的決策流程 — 協議複雜度、mock 寬鬆度、失敗靜默度三個維度
- 反模式：用 mock 數量彌補 mock 盲區
為什麼增加 mock test 數量無法跨越 mock 的結構性盲區 — 從 192 個 test 全過的案例拆解數量與覆蓋率的真正關係
- 主策略 + 補強策略：選擇不必互斥
多策略並非「五選一」、可分層疊加：root-cause fix（解結構問題） + UX 補強（解使用者感知）通常雙打比單選更穩。判準三條：解不同層 / 沒副作用衝突 / 增量成本可接受。把「策略選擇」預設成單選、會放掉互補可能、產生「結構修了但使用者體驗仍差」或「UX 蓋過去但結構還壞」。
- Capability gap 的對策三層階梯：expectation → augment → rebuild
系統有 capability gap（功能不滿足使用者預期）時、對策有三層階梯：L1 expectation alignment（UX hint、訊息精準）、L2 augmenting computation（補一層計算 close gap）、L3 structural rebuild（換 index / engine / 演算法）。三層成本、覆蓋率、脆弱度遞增、不必每次跳到 L3。本卡是 #75 主+補強策略的「不疊加、選層級」變種、跟 #59 五策略矩陣可疊加使用。
- L1 + L2 疊加時的訊號一致性：UX hint 跟自動 fallback 講的話要對齊
把 expectation alignment（L1）跟 augmenting computation（L2）疊加時、兩個 layer 給使用者的訊號可能矛盾：L1 說「請改打字」、L2 卻自動找到了；L1 說「資料可能延遲」、L2 卻 stale-while-revalidate 自動 refresh。沒對齊時使用者困惑。本卡定設計 protocol：兩個 layer 講同一個 capability gap、訊號要 layered consistent、不是 redundant 也不是 conflicting。本卡是 #75 + #86 + #79 在「使用者訊號層」的整合。