揭露句消失與發布日期造假的一天
8月24日是這段時間裡工作量特別密集的一天，喵宇宙同時在跑好幾個站台的重新出貨，也因此在同一天連續發現了兩起會影響大量頁面的問題。
文章揭露句被悄悄抹掉
喵宇宙的文章頁一直有一句話，告訴訪客這篇內容是由AI工具協助整理與撰稿、沒有逐篇經過人工覆核。這天發現，只要一個站台用「重新產生整個網站」的標準流程出貨（不是延用舊版本微調），這句話就會被整句拿掉——因為它從一開始就只是幾個星期前直接貼在正式站上的補丁，從來沒有真正寫進產生網站用的程式裡，一旦重新產生，補丁自然消失。
全站群盤點後確認，曾經出現過這句話的43個站裡，有24個站的文章頁（合計2,834篇）已經看不到這句話。修法是把揭露句正式寫進共用的頁面產生程式，品牌名稱從設定讀取，文字語意不變；原本就沒有這句話的站維持沒有。當天第一波把11個站、1,790篇文章頁的揭露句補回上線。第二波原本要處理9個站，結果只有2個站出貨（其中一站的3篇文章因為「內容本來就經人工審閱後定稿」屬實，保留了原本措辭），其餘7個站全部被系統擋下——因為那些站有部分文章其實只存在於正式站、從未進到版本控制，強行出貨等於用不完整的內容覆蓋現有頁面，系統選擇不出貨。A 站、另一個站這兩站原本的揭露句比其他站多一段「請以主管機關最新公告為準」的提醒，如果照統一版本蓋掉，這段提醒會不見，我們選擇保留這兩站原本較完整的版本。收尾時還發現A 站、還有一個站的正式站頁面仍顯示更早期的舊品牌名稱，代表品牌名稱更新並沒有真正推廣到全部站台。
這個問題背後有個共同原因：這天另外還發生了好幾次「文章已經直接貼上正式站，卻從未回到程式碼版本控制裡存檔」的狀況，好幾個站都有文章屬於這種情形，發現後陸續補進版本控制再重新出貨。這種情形當天一共出現5次，我們因此新增了一道自動檢查：出貨前系統會先抓正式站現有的完整網址清單，確認新版本涵蓋所有現有網址，少了任何一個就直接擋下，沒有繞過的開關。
發布日期其實天天造假
另一起事故是網站的發布日期失真。喵宇宙的建置系統裡有一個共用的「今天日期」設定，同時被拿去當作文章的發布日、更新日，以及網站地圖（sitemap，給搜尋引擎看的網址清單）裡每個網址的最後修改時間——換句話說，只要重新產生網站，不管內容有沒有真的改，所有頁面看起來都像今天剛更新過。這可能被搜尋引擎當成操縱日期的訊號，影響網站在搜尋結果的信任度。
這天完成了一次全站群稽核，把51個含這個欄位的程式檔案逐一追查來源，確認61個共用同一套建置邏輯的站台都受影響，只有一個站台的建置程式明確不套用這個預設。現網實測也發現，其中一個內容站一篇衛教常青文章的正文其實已經寫明「這類文章不需要顯示更新日期」的原則，但同一篇提供給搜尋引擎讀取的結構化資料卻沒有遵守這個原則，一樣天天標成今天，估計影響這個站約359篇文章。這次稽核到當天為止只做完盤點與分類，沒有改動任何檔案，修復計畫分成四個階段，其中兩個階段不用動到文章內容可以先做，另外要回填19個站台真正的發布日期，則要等xmy裁決之後才會動手。
這天其他出錯的地方
- 整個站群共用的自動檢查機制這天紅燈了兩次：一次是有新文章併入卻沒有同步更新對應的紀錄，另一次是共用建置程式改了卻沒有同步一組校驗值，兩次都在當天查出原因並修好。
- 其中一個站原本要重新出貨，卡在部署平台的專案設定還停留在舊的多站合一模式，需要人工到後台調整，正式站沒有受影響。
- 回填孤兒文章時，一則法規來源名稱被不小心從完整的正式名稱退回成較舊、較短的名稱，發現後隔天才改回並重新上線。
- 另一個站因為從來沒有建立過與現網比對的基準，一度被系統誤判成全新站台而跳過安全檢查，我們改用人工比對現網內容後才出貨，沒有造成任何頁面遺失。
- 還有一個站有一種特殊網址編碼格式在轉址後仍顯示找不到網頁，已記錄下來留待之後處理，不影響其他頁面正常瀏覽。
這天的其他進展
這天也把一個橫跨好幾天的舊網址轉址修復專案收尾：24個站台的網域轉址失敗問題全數判定完畢，15站已修完出貨，10站因為各自不同原因延後處理，沒有站台修復失敗。
系統維護部分，這天分兩階段清理磁碟空間：先自動刪除227個閒置超過24小時的暫存項目，可用空間從60GB回升到70GB；再經人工核准刪除51個確認重複的資料夾路徑（估計約10.2GB），實測卻只回升到72GB，推測是不少檔案原本就共用著底層儲存空間、不是單純的重複計算。另外設定了一個每天自動列出候選清單、但不會自動刪除的排程，方便之後人工複核。
另外，會員系統要不要共用一套的問題也重新盤點了一次：發現原本以為完全沒有的共用機制，其實已經在7個站台的正式站上運作；這個新事實推翻了原本要從零打造的假設，我們決定持續投資這一套現有系統，而不是另一個功能更完整、但還沒有任何一個站台真正上線用過的競爭方案。