8 月 10 日下午 4 點 02 分，a2e51fc，48 行。

這是個很小的改動，但它代表了一件我在前三個版本完全不會做的事：收到需求之後，先確認「這是不是真的漏掉了」，然後用最少的改動解決。

需求：迷你窗上沒有「開始」

為了不要占太大的版面，所以我在 Pomofocus 新增了一個可以縮成小小的倒數視窗並浮在畫面的功能。
滑鼠移上去會浮現三顆按鈕：暫停、跳過、展開。

那天我回報：

迷你畫面在番茄還沒開始前，應該要有按鈕可以開始

查證：這是真的漏掉了

交接文件 12.28 記錄的查證結果是這樣：

迷你窗的 ui/window_mode 與 PomodoroEngine.state 是兩條獨立的軸，IDLE 停在迷你窗完全可能發生（開機還原 mini 形態、或一顆番茄結束回 IDLE 仍待在迷你窗），但 hover 浮現的三顆鈕在 IDLE 全都沒用——pause() 在 IDLE 直接 return，skip() 的 match 也沒有 IDLE 分支，只能按「展開」回主視窗才開得了番茄。

這段話解釋了「為什麼會漏」：
視窗形態（主視窗／迷你窗／系統匣）和番茄鐘狀態（閒置／工作／休息）是兩套獨立的狀態，兩兩組合起來有九種情形，而「迷你窗 + 閒置」這格當初 AI 漏掉了。

決議：不新增按鈕

接下來這句是重點：

訪談決議：沿用系統匣選單（tray.gd MenuAction.TOGGLE）的同一顆鈕多用途 pattern，不新增按鈕、不改 hover 時機。

系統匣的選單早就在做這件事——同一個選項，在不同狀態下做不同的事。迷你窗照做就好。

實作是：

• 主按鈕在閒置狀態下，文字改成「開始」，按下去開始一顆番茄；其他狀態維持「暫停／繼續」。
• 閒置狀態下把「跳過」按鈕變灰（沒有進行中的東西可以跳）。
• 場景檔完全沒動，維持 6 月 18 日定案的 190×76 尺寸和三顆按鈕的版面。

48 行，其中還包含測試。

為什麼特地提出來

如果是四月的我，遇到這個需求會直接說「幫我在迷你窗加一顆開始按鈕」。

然後就會發生：
視窗要變寬才塞得下第四顆按鈕 → 按鈕變小不好按 → 版面重排 → hover 的判定範圍要跟著改 → 三顆變四顆之後某個尺寸算式不成立。

這不是假設，Day 5 講過的標籤介面就是這樣一路改了五次形態。

而這次的決議是「不新增」，代價是使用者要知道同一顆按鈕會變身。
這是因為系統匣早就這樣運作了，整個程式的行為是一致的。

這篇的重點

vibe coding 最大的特色就是改動的成本變得太低，但也正因為如此，反而會讓人很難停下來想「這個真的要加嗎」，反正叫它做只要三十秒。

前三版就是這樣把東西越加越多，然後在功能的重量下停住。

第四版做對的一件事，是把「先查證、再訪談、然後用最小的方式做」變成預設流程。
慢個十分鐘，省下後面的五次來回。

帶走這個：需求進來之後的三步，慢十分鐘省五次來回

1. 查證：這是真的漏掉，還是我對它的期待本來就沒被設計進去？要求 AI 說明「為什麼會漏」，而不是直接補。我那次拿到的答案是「視窗形態和番茄鐘狀態是兩條獨立的軸，這個組合沒人想到」——這句話比修好本身更有價值，因為它指出還有其他組合可能同樣沒被想到。
2. 找既有 pattern：這個程式裡有沒有地方已經在解同類問題？我的系統匣選單早就在做「同一顆按鈕依狀態變身」，照抄就好，整個程式的行為也才一致。

明天講專案中抓到的一個 bug：休息視窗在作業系統層被藏起來了，但程式從頭到尾都以為它還在畫面上。