觀察

驗收回報「右下按鈕按了沒反應」；管理模式批次操作 UI 的盤點結果：

對照規格（SPEC-006 FR-9 / FR-10）：批次操作的 domain 層已完整實作 — LibraryManagementService.performBatchOperation（刪除 / 改來源 / 改重要度 / 增刪標籤）與 Command 模式的編輯服務（undo / redo）都在 — 是 UI 到 service 的最後一段接線沒做。團隊已有「佔位實作」的追蹤票（佔位掃描盲區改善），本案是同類技術債在管理模式的集中呈現。

附帶：底部欄只在「已選取至少一本」時才出現 — 驗收者若沒先勾書、連佔位的編輯 / 分享 / 刪除鍵都看不到。

判讀

1. 可點的假按鈕是負資產。按鈕存在 = 系統承諾功能存在，點了沒反應被讀成「壞掉」（體感同 U.C5 零回饋）— 對產品信任的傷害大於「功能還沒有」。未完成的功能在 UI 上的正確形態是隱藏、或 disabled + 說明（「即將推出」），不是可點的佔位。

2. dev toast 佔位掩蓋未接線。接了 toast 的按鈕在開發自測時「有反應」— 開發回饋（toast 彈了）與使用者回饋（操作確實執行）被混為一談，佔位從此不在任何人的視野裡，直到驗收。log-only 佔位更隱形：畫面上完全無反應。

3. domain 完成 + UI 佔位 = 完成度斷層。規格對照表寫「批次管理操作：已實作」指的是 service 層 — 進度報告以 domain 層為準時，UI 未接線的斷層不會出現在任何狀態欄位上，驗收是唯一暴露點。完成度要分層記帳（domain / UI 接線 / 驗收通過）。

策略

1. 佔位 handler 用統一可掃描的標記（固定的 dev-placeholder helper、或 // PLACEHOLDER: 類統一註解），release 前用 grep 掃描（本案的現成過渡掃法：rg "尚未實作|DevToast"）清零或轉成 disabled + 說明。

2. 未接線功能的 UI 三選一：隱藏（功能不該被發現）、disabled + 原因（讓使用者知道存在但未開放）、接線（完成它）— 可點無反應不在選項裡。

3. 完成度分層記帳：domain 完成、UI 接線、驗收通過是三個獨立狀態 — 「已實作」要標明層級，避免 UI 斷層藏在 domain 的完成宣告後面。

下一步路由

• 零回饋按鈕的原型案例 → U.C5 匯出按鈕零回饋
• 回饋鏈路的其他斷點 → U.C9 提取成功卻誤報失敗、U.C19 計數被版面擠壓
• 三層回饋的完整要求 → 互動回饋三層模型