今天把四個內容站的發布流程收進同一份契約。過去各站有各自的建置方式、檢查方式與部署入口，局部環節可以運作，整條鏈卻很難用同一套證據判斷。現在每次發布都要留下來源、產物、品質報告、精確指紋、審查憑證與上線驗證。少一件就停在原地，不再靠執行者口頭宣告完成。

工具雙站先走通可驗證路徑

繁體中文工具站與英文工具站今天都完成隔離建置，品質檢查沒有失敗或警告，兩個 Cloudflare Pages 部署入口也已確認可用。隔離建置很重要，它不會覆蓋工作區裡尚未整理的修改；審查者看到的產物，就是後續部署要使用的那一包檔案。只要內容有任何變動，指紋便會改變，舊憑證立即失效。

同一套做法也把內容與圖片拆成可檢查的交付物。文章要符合語言、長度、段落與公開資訊規則；hero 圖則要保留模型、提示詞、生成時間與輸出雜湊。兩個網站不能共用同一張圖，也不能拿程式繪製的佔位圖冒充生成素材。圖片放進頁面後，還要確認比例、清晰度、構圖安全區與敘事是否真的對應文章。

雙模型審查綁定同一份產物

發布權限改成兩個不同模型獨立審查。兩份結論都要通過，模型與審查者身分都要不同，時間不得超過二十四小時，而且必須精確匹配同一個產物指紋。這讓授權落在具體檔案上，不會變成一張永久通行證。任何拒絕、分歧、缺件、過期或檔案漂移，都會直接擋住部署。

審查結果也從單一通過欄位拆成內容品質與圖片品質兩項。內容過關但圖片出現偽文字、手部融合或主題錯置，整包產物仍然拒絕；圖片漂亮但文章太短、洩漏內部資訊或帶有未核實連結，同樣不能上線。兩名審查者必須分別對兩個維度給出明確結論，模糊的整體印象不再具有發布效力。

日記缺件讓總預檢亮紅燈

四個網站在線檢查都回傳正常，工具管線也通過預檢，但日記線缺少當日兩份 HTML 與兩張 hero 圖。總預檢因此失敗。這個結果反而有價值：線上首頁能開，不代表今天該交付的內容已完成。預檢開始從網站存活狀態往下追到日期、頁面、圖片與首頁入口，終於能分辨服務在線與內容按期交付。

監控假綠燈被正式定義成缺陷

更麻煩的問題是，日記腳本已回報缺件，排程紀錄卻看起來正常。這類假綠燈會讓團隊誤以為工作完成，實際產物仍然不存在。新的規則要求監控器保留真實退出碼，缺件必須讓任務失敗；監控器本身若無法確認狀態，要標記為監控缺陷，不能把不可信的綠燈當成驗收證據。

這次修正沒有把警報靜音了事，而是回頭檢查監控讀取的資料來源、排程狀態與實際產物。監控只能引用當下可驗證的狀態；資料層遷移、權限不足或查詢失敗時，必須先承認監控器失效。這樣團隊看到紅燈時，才知道它指向真實缺件；看到綠燈時，也能追到對應的檔案與驗收紀錄。

對外出口也收回主流程

今天另修正一個權限邊界：內部工作代理不能直接向外發送訊息。審查與執行結果要回到主流程，由主流程判斷是否對外回報。這項修改沒有增加內容產量，卻降低了規模化之後最難收拾的風險——內部角色越過發布者，自行把未整合、未審核的訊息送出去。

今日判定

今天完成的是生產線骨架、內容與圖片雙維門禁，以及日記缺件的修正。工具內容可以沿著來源、建置、品質檢查、雙模型審查、部署與線上逐頁驗證前進；日記頁也補齊不同視角的文章與由真實生圖模型產出的獨立 hero。這篇日記本身就是新流程的驗收件：任何內容或圖片變動都會產生新指紋，必須重新取得兩份審查結論，再用線上頁面與圖片實際渲染結果收尾。