觀察

電子書庫總覽 Chrome 擴充功能（book_overview_v1）從 lazy-load 書庫頁提取書目。提取器的兩種載入策略（捲動容器 / 點擊「更多…」按鈕）設計成二擇一，實機上容器 selector 恆先命中，「更多…」按鈕分支永不執行；首批 96 本載入後 count 連續 3 輪不變，觸發 count_stable 條件判定完成 — 實際書庫有 928 本，提取器在 96 本就宣告成功結束（commit 9d0556e1b，W1-030 / W1-040）。

修復：每輪同時捲動＋點擊按鈕（不再二擇一），涵蓋率從 96/928 提升到 928/928 — 可見書目全數取得（全書庫 944 本、其餘為封存借出、不在可見清單）。

判讀

1. count 穩定是「沒有變化」、不是「沒有更多」。lazy-load 頁面的內容增長依賴特定觸發動作（捲動、點按鈕）— 觸發動作缺失時 count 永遠穩定，穩定訊號分不出「真的到底了」和「載入通道根本沒打開」。完成判定缺一個獨立的窮盡證據：頁面宣告的總數、終止標記（「沒有更多了」元素）、載入觸發器消失、或 API 側的窮盡宣告（分頁 cursor 耗盡、has_more=false）。

2. 誤報完成比報錯更難察覺。提取失敗使用者會重試；「成功提取 96 本」看起來一切正常，使用者帶著殘缺資料做下游決策（統計、匯出、比對），錯誤在離開這個畫面很久之後才浮現、且很難回溯到提取階段。

3. 有總數可對照時，缺口是可偵測的。頁面顯示 928 本、提取到 96 本 — 10 倍差距在有對照數字時一眼可見。判定邏輯沒有利用這個訊號，是證據源的遺漏、不是證據不存在。

策略

1. 完成判定列出證據清單：宣告完成前問「終止條件是『確認沒有更多』還是『暫時沒變化』」。只有停滯訊號時，完成宣告降級為「已取得 N 筆、可能還有更多」的誠實表達。降級的適用邊界：下游需要全量的操作（備份、匯出、合規留存）不適用部分結果 — 這類場景把不完整按失敗處理、阻止下游動作。

2. 利用對照數字做完整性檢查：來源有總數（頁面計數、API total）時，提取數與總數的比對是最便宜的誤報偵測 — 差距大時不宣告完成、改報部分結果與原因。

3. 多策略遍歷用並行不用二擇一：載入觸發方式不確定時每輪全部嘗試，單一策略的 selector 誤命中不會關閉其他通道。

下一步路由

• 進度指示與假進度反模式 → 時間感知與回應策略
• 結果通知的呈現（部分成功的摘要 + 明細）→ 互動回饋三層模型
• 類似案例（結果通知鏈路錯誤）→ U.C9 提取成功卻誤報失敗