Pomofocus 有 10 個測試腳本，休息視窗那支後來長到 70 項。全部都是用無畫面模式（headless）跑的。

這些測試很有用，但它們有一個根本的限制：看不到畫面。

交接文件裡有一句話把這件事講得很清楚：

注意 headless 的 screen_count = 0，遮罩相關斷言在 headless 下是空集合比較

我的休息視窗要蓋住所有螢幕。
在無畫面模式下，螢幕數量是 0，所以「每個螢幕都有遮罩」這個斷言會通過——因為零個螢幕都有遮罩，邏輯上成立。

測試綠燈，功能沒驗到。

8/10 那次量測

8 月 10 日我問了一個問題：自動開始下一段休息的時候，我手已經離開鍵盤滑鼠了，那個全螢幕的休息畫面真的會蓋在其他程式上面嗎？還是會被壓在後面、倒數自己跑完？

這個問題自動測試答不了。所以那天的做法是：

把專案複製一份到暫存目錄（不動 repo）、加一次性探針旗標 --autostart-probe（設 auto_start_break = true、工作 12 秒，並印出休息視窗的原生 HWND），搭配 --fast-timer 避免污染 stats；全程讓真實的前景程式壓著 Godot（app 不是前景 = 自動開始的真實情境），以 Win32 z-order 列舉 + per-monitor DPI aware 截圖量測三輪（游標在主螢幕 / 游標在副螢幕 / forced 強度）。

量測結果有三條：

一、有蓋住，原本的擔心不成立。

三輪的 z-order 第 0 名都是休息視窗（WS_EX_TOPMOST，rect 精確等於目標螢幕），第 1 名是另一面螢幕的遮罩，第 2 名才是當時的前景程式。背景程序拿不到前景，但拿得到 topmost band。

**二、全螢幕會開在游標所在的那一面螢幕。**自動開始的時候我的手已經離開滑鼠，游標在哪面是隨機的，所以主螢幕常常只拿到遮罩，真正的倒數和步驟在另一面。這個當下決議維持現狀不改。

**三、鍵盤焦點完全沒轉移。**這條最嚴重：

三輪 GetForegroundWindow 在休息前後都是同一個程式，含 forced 那輪⋯連帶：forced 的長按 ESC 靠 Input.is_key_pressed，收不到按鍵就不累計；focus_exited 拉回也因為從未取得焦點而不觸發 → 逃生口等於失效。

強制鎖定模式的唯一逃生方式，是長按 ESC 三秒。而在自動開始的情境下，那個視窗根本收不到鍵盤——逃生口是壞的，但所有自動測試都顯示它能用，因為測試是直接呼叫按鍵事件，不經過作業系統的焦點機制。

修法：不依賴鍵盤的逃生路徑

決議是不去搶前景（怕影響到原本電腦執行的其他程式），改成補一條不需要鍵盤的路：畫面上直接加一顆「長按 3 秒結束休息」的按鈕，跟 ESC 共用同一個計時器和進度條。

然後補了 5 項測試：顯示逃生鈕、按不滿放開不逃生且進度歸零、長按 3 秒逃生、視窗隱藏、計為未達成。

這件事的重點

自動測試能測的是「程式的內部狀態對不對」。它測不到：

• 畫面實際長什麼樣
• 視窗在作業系統的層級關係
• 鍵盤焦點在誰身上
• 顏色、透明度、疊字
• 手感

而這些恰好是桌面應用最容易出錯的地方。

vibe coding 的節奏下，AI 會很肯定的告訴我們「70 項測試全部 PASS」，但它代表的成功比以為的窄很多。

帶走這個：在測試檔旁邊放一份「測不到清單」

自動測試會給我們一種安全感，而那種安全感的邊界通常說不出來。所以我們可以準備另外一份清單，格式是：測不到什麼、為什麼、那要怎麼驗。

寫這份清單有兩個好處。
第一，不會再把「70 項測試全過」誤讀成「這個功能沒問題」。
第二，最後一欄常常只需要「肉眼看一眼」

要求 AI 列這份清單很有效，它很清楚自己跑了什麼、沒跑什麼。

明天講一個問題：那些文件裡明明白白寫著「未實機驗證」的功能，兩個月後在真實生活裡的下場。