概念位置

Fail-safe 預設與 UX Fallback 的分工：fallback 是給使用者的替代路徑（主路徑失敗後使用者往哪走）、fail-safe 是系統自己的預設方向（保護機制失效時系統做什麼）— 前者是使用者可見的路、後者是程式碼裡的 else 分支。安全領域的對應概念是 fail-open vs fail-closed：破壞性操作的確認機制要 fail-closed（故障即拒絕）。

可觀察訊號與例子

需要檢查 fail-safe 的訊號是「保護邏輯存在、但它的故障分支沒人設計過」。實戰正面案例：匯入覆蓋模式的確認 Modal 在 DOM 缺失時一律視為未確認、預設不清空書庫（U.C12）。反向的檢查問句：確認元件不存在時、你的程式碼走哪個分支？

設計責任

Fail-safe 的設計責任是為每個保護機制（確認對話框、權限檢查、二次驗證）顯式寫下故障分支的方向。程式碼層的掃描訊號：確認邏輯的 else / null / timeout 分支最終呼叫的是「執行」還是「中止」— 分支缺失或走向執行的，就是故障會靜默放行破壞的候選。

觀察

電子書庫總覽 Chrome 擴充功能（book_overview_v1）的匯入功能有覆蓋 / 合併兩種模式；覆蓋模式的語意是「以檔案內容取代現有書庫」— 該模式下匯入空檔等於清空全部資料。設計（src/overview/import-flow-controller.js，W1-049）：

1. 覆蓋模式下偵測到匯入內容為空時，彈出專屬確認 Modal 描述後果（現有書庫非空時文案帶具體數字「將清空現有 N 本書」）、使用者明確確認才執行；合併模式不觸發這道確認。
2. Modal 帶 aria-labelledby / aria-describedby，螢幕閱讀器使用者能取得完整的後果描述。
3. 關鍵設計：確認 Modal 的 DOM 元件缺失時，視為使用者未確認、預設不清空。確認機制故障不會讓破壞性操作靜默通過。

判讀

1. 破壞性操作 gate 是 gate 的一個獨立類型。認證 / 網路 / 權限 gate 攔「使用者能不能繼續」，破壞性操作 gate 攔「使用者是否理解後果」— 觸發條件不是身分或環境、是操作的破壞半徑（不可逆、影響既有資料、影響範圍大於使用者的直覺預期）。「匯入」聽起來是加法、覆蓋模式的實際語意是取代 — 語意與直覺預期的落差越大、越需要確認。

2. 確認機制本身有故障模式。元件沒渲染、事件沒綁上、動態載入失敗 — 確認 UI 故障時系統要選一個預設方向：執行（把故障當同意）或不執行（把故障當拒絕）。安全預設的原則是倒向不可逆性低的那邊：不清空可以重試匯入、清空無法還原。這與「fail-open vs fail-closed」的安全設計同構。

3. 確認對話框的可及性是 gate 有效性的一部分。看不到後果描述的確認（螢幕閱讀器讀不出 Modal 內容）等於沒有確認 — 使用者按了「確定」但不知道確定了什麼。

策略

1. 識別破壞性操作：列出所有會覆蓋 / 刪除 / 取代既有資料的操作，語意與直覺預期有落差的是高風險項（匯入的覆蓋模式 = 取代、同步 = 可能覆蓋、重設 = 清空）。

2. 確認 UI 描述後果、不只問「確定嗎」：帶上具體數字（「將清空現有 N 本書」）讓使用者對照自己的預期。

3. 為確認機制設計故障預設：確認元件不存在 / 事件未觸發 / 回應逾時，一律視為未確認。程式碼層的檢查訊號：確認邏輯的 else / null 分支走向哪邊。

下一步路由

• Gate 的必答問題與類型 → Gate 分類與三問設計法
• 確認機制故障的預設方向 → Fail-safe 預設
• 通知形式的干擾程度判準（Dialog 的阻斷性是設計需求）→ 通知模式選擇
• 對照案例（gate 缺 fallback）→ U.C2 biometricOnly 無 fallback