前言：把第三部的發現串起來看一次全貌

第三部花了 7 天挖這個套件的跨版本相容性跟靜態品質工具現況。今天把它們串起來看一次全貌。

今日目標

• 回顧第三部 7 天各自發現了什麼
• 看清楚這些發現之間的共同結構：承諾寫在哪裡、由誰檢查、什麼時候才會被發現出問題
• 回收「相容性防線目前完全靠跑測試」這句話,講清楚它精確的意思
• 為第四部（實際動手補救）先列出候選清單

7 天發現的清單

共同結構：三個問題,同一個答案

把這 7 天的發現放在一起看，會發現它們其實在回答同一組問題：

「這個承諾／規則寫在哪裡？」 答案幾乎都是「只寫在 CI 矩陣設定裡，沒有寫進 composer.json、README、或任何給人類/AI 讀的專案指引」。

「誰會檢查？」 答案是「除了 CI 跑測試那一刻，沒有別的機制在檢查」——PHPStan 沒裝、phpcs 沒接進去、composer audit 從沒被想到要跑。

「什麼時候才會被發現？」 答案是「等到某天有人（或 AI）不小心踩到，或是某個依賴版本的已知漏洞被公開很久之後才偶然被注意到」。

「相容性防線完全靠跑測試」這句話的精確意思

不是說「跑測試沒有用」——CI 矩陣涵蓋 7.1 到 8.3，確實會在每次 push 時攔下明顯的語法不相容問題，這是真實有效的防線。這句話的意思是：目前這個套件除了『跑一次測試』之外,沒有任何第二層防線——沒有靜態分析在寫程式碼的當下就攔截型別問題，沒有 composer audit 在依賴版本累積風險時發出警訊，沒有版本約束在安裝階段就擋下不相容的環境。單一防線的問題不是它不管用，是它只在「剛好跑到那條路徑」的時候才生效——沒被測試覆蓋到的分支、沒被特別注意到的依賴版本，防線就完全不存在。

這也剛好呼應這個系列從第一天就立下的主題句：AI 能幫你補程式碼，但補不出你自己都沒發現的測試缺口——換到這裡的脈絡，可以延伸成：工具能幫你多開幾道防線，但補不出你自己都沒想到要去檢查的那個面向。 PHPStan、composer audit、phpcs 都不是新奇的工具，它們沒被用起來的原因,通常不是技術障礙，是根本沒有人在某個時間點停下來想「我們現在還缺什麼」。

第四部的候選清單

接下來 8 天要動手做的候選項目，都是這一部發現的直接延伸：

• 補一份有意義的覆蓋率門檻（呼應 Day 07、18）
• 把 check-style 接進 CI,並處理既有的 8 個違規（呼應 Day 20）
• 幫 RefundRequest/VoidRequest 補上例外情境測試（呼應 Day 05、10）
• 寫一份 prompt 模板，讓 AI 補功能時連帶檢查測試缺口（呼應 Day 13、21）
• 討論 README 漂移能不能用 CI 自動偵測（呼應 Day 04、17）
• 回頭看 PHPStan 常態化跑起來後,會持續冒出什麼類型的新警告（呼應 Day 19）

今日思考題

看完這 7 天的發現，如果要你只選一件事優先做，你會先補哪一個？是最容易做的（例如加一行 composer audit），還是影響最大的（例如處理 phpcs 既有違規讓 check-style 能真正接進 CI）？

今日重點回顧

• 第三部的 7 個發現,共同結構都是「承諾只寫在 CI 矩陣裡、沒有第二層檢查機制、只在剛好踩到時才會被發現」
• 「相容性防線完全靠跑測試」不是說測試沒用，是說目前只有這一層防線，沒有覆蓋的角落就完全空白
• 全系列主題句延伸：工具能幫你多開防線，但補不出你自己都沒想到要檢查的面向

明日預告

明天正式進入第四部——不再只是診斷,而是實際在一份暫存複本上動手做出幾個補救示範，第一個是幫覆蓋率補一份有意義的門檻。