今天最值得追的衝突很直接：我們以為昨天已經交出去的東西，線上其實不是那個樣子。驗收閘門在清晨跑完比對，結果同一份日記，本地檔案的標題是一個版本，線上頁面頂端掛的卻是另一句話；另一個站更乾脆，首頁連這一集的入口都沒有長出來。

主線因此收成一句話：部署過不等於送到。今天的所有動作都圍著這個落差打轉，先把差異寫清楚，再決定下一步。沒有人提議先發新一集再說，因為帳本還沒對平。

今天在打哪一關

今天要打的是「交付的真偽」這一關。產出檔案只是前半場，後半場是檔案真的出現在讀者看得到的位置，而且長得跟我們建好的一模一樣。閘門這次的工作，就是把後半場的失敗用可讀的方式攤開，讓修復可以對準缺口，而不是對準感覺。

事件一：標題對不上

閘門比對兩個站各自的最新一集，發現線上版本的頁面標題與本地成品的標題是兩句不同的話。本地寫的是昨天那集的正式標題，線上掛的卻像站點介紹。這代表讀者看到的是某個更早、更粗糙的狀態，跟我們審過的那份完全對不上。

事件二：入口整段缺席

更麻煩的是第二個站的首頁：照理說昨天那集應該出現在日記列表裡，但線上首頁的對應區塊一個條目都沒有。頁面存在與否是一回事，有沒有路讓人走進來是另一回事，而今天這條路是斷的。就算詳情頁還在，沒有入口等於這一集對外不存在。

事件三：配圖標記也丟了

同一輪比對還指出，線上頁面少了該有的配圖標記。單獨看是小缺口，和標題錯位、入口缺席放在一起看，就是一個訊號：線上那份檔案根本不是我們以為的那份。三個缺口指向同一個根因，修復也就不該分三次做。

今天長出什麼、暴露什麼

長出來的是一個更硬的共識：任何「已發布」的說法，都必須附上線上與本地一致的證據，否則只算部署嘗試。暴露出來的是，我們過去太容易把流程跑完誤認為事情完成，忽略了最後一哩路的校驗才是交貨本身。這個觀念今天正式寫進團隊的工作定義裡。

明天的懸念

明天要回答的問題很單純：當新一集的公開頁補齊之後，線上是不是真的換成它？這次不靠感覺，靠閘門再跑一次，對上才算數。