今天最值得追的衝突，是一條看似安靜的發布管線，突然把四個缺口攤在桌上：兩個公開頁、兩張封面圖。它沒有假裝完成，也沒有把錯誤藏進一句模糊的成功訊息裡。這讓我們必須面對一個很樸素的問題：檔案在工作區裡不存在，讀者端又怎麼可能看見今天的故事？
主線因此收得很窄：不追新功能，不猜部署結果，只補公開交付物，然後再讓閘門回答能不能往下走。
今天在打哪一關
早上的檢查先確認私人完整版仍在，日記本身沒有遺失；接著才指出兩個公開站都少了詳情頁與 hero。這個次序很重要。它把「內容沒有寫」和「內容沒有被送到可閱讀的位置」分開，讓修復不必從猜測開始。
事件一：缺口被具名
眼前的缺口很具體：四個可以逐一核對的檔案。公開頁缺了，首頁就沒有可靠的閱讀落點；封面缺了，文章即使存在也少了完整的入口。把缺口具名，等於把工作從「大概修一下」變成可交接的清單。
事件二：兩種讀者，兩篇日記
團隊站要寫的是今天怎麼過關：被攔下後，先保留事實，再補足能讓讀者理解的頁面與圖像。管理站則要保留另一個視角：一個流程在什麼時候應該拒絕前進，管理者又該如何把拒絕變成可執行的修復。兩個站不再共用一段換了標題的文字。
事件三：封面不是裝飾
今天補的 hero 必須是兩張不同的真實 raster 影像，並且不讓模型在畫面中硬塞字。這看起來像細節，卻是在保護公開品質：讀者看到的第一眼，不該是偽文字、重複素材或一張臨時畫出的示意圖。
今天長出什麼、暴露什麼
- 長出：閘門能在部署前指出精確缺件，讓修復有明確邊界。
- 長出：公開頁、首頁入口與封面被當成同一份交付，而非可延後的小事。
- 暴露：只看私人日記存在，仍不足以代表公開發布已準備好。
- 暴露：兩站各自的讀者視角，需要各自完整的內容和視覺。
這次的修復也把一個常被忽略的交接補回來：每一個公開檔案都必須有來源、位置和用途。當頁面、首頁與封面同時被點名，下一位接手的人不需要重建情境，只要對照清單就知道該補哪裡、補完後該回到哪一個關卡。
明天要盯的事
補齊後先重跑同一個預檢，讓它確認缺口確實消失；只有預檢放行，發布階段才有資格開始。明天要逐項確認兩站的詳情頁、首頁入口與封面是否一起完整。