四項待辦，一天清完
交接檔 Next Session Goals 有四條：content.js 逼近 800 行上限、e2e 座標寫死在 `1710,40`（換螢幕就壞）、非 16:9 影片從未實測、側欄並排拉寬疑似未修。 解法各自直白：把 `content.js` 的品質政策抽到 `src/quality-policy.js`、 視窗適配邏輯抽到 `src/window-fit.js`，662 → 581 行； e2e 改呼叫 `chrome.system.display` 在執行期查詢座標； 直式影片實測——然後踩坑；側欄則發現 v2.3.0 早已修掉，補上守門測試即可。
commits `8b85042` → `c08d5c8`，CI 全綠（單元 74 → 98、e2e 內建 40/40、4K 46/46）。 上架後 `2026-08-08` 確認線上版本 = 3.0.1、舊網址殘留 0 次，收尾 commit `8836039`。
兩條「長期綠燈、但什麼都沒守到」的測試
第一條：「彈出視窗開在來源螢幕」。Brave 的 `--window-position` 旗標會覆蓋 每一個 `chrome.windows.create` 的 `left` / `top` 座標，且不報任何錯。 舊 harness 把主視窗與彈出視窗都用同一個旗標座標啟動， 於是「彈出視窗開在來源螢幕」變成必然成立—— 因為驗的是命令列旗標，不是產品程式碼裡 `chrome.windows.create` 的邏輯。
第二條：「彈出視窗長寬比符合影片」。全新 profile 預設擋自動播放， 導致 `videoWidth = 0`；影片寬度為零時程式退回 16:9 基準， 於是「內容區符合影片長寬比」變成 16:9 比 16:9——永遠成立。
兩條都通過了好幾個版本。「測試綠」跟「測試有作用」是兩件事， 不會自己分開，必須主動設計對照情境才看得出來。
直式影片：我們讓它比不裝擴充功能還小
實測環境：1670×896 視窗、720×1280 影片、釘 720p。 YouTube 原生（不裝任何擴充）可見影像面積是 439×780； 裝了 Auto Resizer 之後是 405×720——面積少了 14.8%。
交接檔裡寫「直式影片出現黑邊，與 YouTube 原生行為相同」。那句是錯的： YouTube 原生對直式影片會給一個高容器，兩側是黑邊， 但內容本身維持影片長寬比的高度。Auto Resizer 錯在把容器高度當成影片高度， 壓出了更小的可見區域。
修法第一版只對了一半，而且我把錯誤的期望值也一起寫進了測試—— 讓「改正確」與「改期望值」變成同一步，失去了測試的對照功能。 最後另開一個獨立 commit，先把測試改正確（RED），再改產品邏輯（GREEN）。 16:9 輸出有專門測試守著，全程沒動。
Chrome Web Store：命中次數跌是假進度
v3.0.0 上架後，說明文案的 OPEN SOURCE 段落一直是舊網址—— 那是在送審之後才更新 `store-assets/store-listing.md` 的， Dashboard 沒回填，線上從未改過。 掃 repo 看到的是正確版本，線上是舊的，兩個副本從 v3.0.0 起就不一致。
查驗時用 grep 抓舊網址，命中數從 3 降到 2 看起來像「快好了」。 實際上那是 Support URL 欄位（已修）跟說明文案（尚未修）兩個不同欄位各自的狀態。 聚合數字把兩個獨立問題混成一個進度條。 要逐一看命中「位置」，不要只看命中「次數」。 最終隨 v3.0.1 一併修掉，兩個欄位同步更新。
關鍵教訓
測試綠 ≠ 測試有作用：Brave 旗標覆蓋座標、新 profile 擋自動播放——這兩個環境假設讓兩條測試從頭到尾都是 tautology。主動設計對照情境才能分辨。
文件說的不算，實測說的才算：交接檔寫「直式影片黑邊同 YouTube 原生」是錯的。現場量測才看出面積差了 14.8%。
錯誤的期望值也要分開 commit：先讓測試 RED（期望值改正確），再讓產品 GREEN（實作改正確）。兩步混在一起就沒有對照。
看命中位置，不要只看命中次數：3 → 2 看起來像進度，其實是兩個獨立欄位各自報狀態，聚合數字掩蓋了真相。
版控副本與線上副本可以長期不同步：repo 裡的 store-listing.md 是對的，但 Dashboard 從未更新——掃 repo 永遠查不出線上的問題。