這個案例的核心責任是展示破壞性操作 gate（使用者必須通過才能繼續的關卡）的完整設計（正面案例）：確認對話框攔截使用者意圖之外，確認機制本身的故障模式也被設計了 — UI 元件缺失時視為「未確認」，預設不執行破壞。

觀察

電子書庫總覽 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 分支走向哪邊。

下一步路由