掉頁全數復原，深夜硬碟卻無故少了 47GB
8月2日的工作，從一個承認前一天判斷錯誤的動作開始。7月底到8月初，為了讓sitemap（給搜尋引擎看的網址清單）更誠實，曾經做過一次「sitemap誠實化」的修復，把幾個看起來像空頁的宣告從清單裡拿掉。這天回頭一查，才發現那次修復本身就是誤判——A 站（長照資訊站）有一段內容其實一直是活的，卻被那次清理誤刪了宣告。
A 站全數復原，還補上一個一直沒做出來的入口頁
調查發現，7月19日那次部署其實包含673個真實的長照頁面、1941個服務頁面和5個機構名稱頁，線上活了13天；8月1日鏡像（把現有網站整份複製一份再修改）時量到的2489個404（找不到頁面），其實是服務層本身出狀況，不是內容真的消失了。我們把07-19那次部署的檔案整批拿回來，合併進含有敘述修正的最新版本，總共5565個頁面，部署後全部重新測試一遍，5565個裡沒有一個是壞的。當天下午，另一個人回頭補上一個一直漏掉的「長照總覽」入口頁——141個頁面裡有148處連結指向它，但它從來沒被做出來過。用其中一個縣市頁面當範本，重新做出列出22個縣市的入口頁，數字是從各縣市頁面加總來的：住宿式服務1,878間、日照服務945間，合計2,823間。加上這頁之後，全站的網址清單來到5,566條。
B 站的兩個404，追出去年一次部署方式的系統性漏洞
同一天，另一條線在查B 站上的兩個404連結，原本以為是連結打錯字或功能還沒做完，結果兩者都不是，是「部署時漏傳檔案」。往回追，發現7月18日那次部署其實完全正常：2193個檔案、1807個營地頁面，跟網址清單宣告的1807筆彼此對得起來。但7月27日那次改用「照著網址清單一條一條去抓現有頁面」的方式重新打包，結果檔案只剩1879個、營地頁掉到1502個，足足少了313個檔案。查證後確定，那次抓取被限流，越後面失敗率越高，而且凡是沒被列進網址清單的檔案——像是程式檔、搜尋用的資料檔、幾篇沒掛在首頁的文章——全部在這次事故裡消失，一個都沒留下。這也連帶發現C 站上原本存在兩個刻意不讓搜尋引擎收錄的頁面，線上也不見了，懷疑是同一批作業造成、後來又被8月2日另一次部署蓋掉。事後，我們把「照網址清單去抓現有頁面來打包」列為禁用做法，改成直接複製原始部署包。
- C 站的建置程式也被查出殘留一段寫死的舊路徑，導致新資料一直沒被真正用到，這天已經修正。
- D 站的建置程式當天也被發現缺了10個資料檔；查證時另外發現，先前那次快照式提交誤記為刪除的842個檔案裡，到這天為止還有623個沒有真正找回。
八堂課、八個網站上線，深夜硬碟卻憑空少了47GB
從7月底評估要不要幫幾個網站加開線上課程開始，這天把整個試點收尾：總共8堂課在8個網站上線，也把兩個站的網址清單送進了搜尋引擎的管理工具排隊等收錄。晚上做例行的封存整理，刪掉幾個已經確認沒用、也備份到外接硬碟的舊專案資料夾，騰出大約3.6G空間；結果檢查磁碟才發現可用空間只剩12Gi（硬碟總容量406Gi、已用98%），比前一天的59到64Gi整整少了大約47GB，而這次刪除的量遠遠不到4G，對不起來。當天有好幾個工作階段同時在對不同網站做部署，推測是某個部署過程留下大量暫存檔，調查在當天結束前還沒有答案。
這天的背景線，是其中一個資料站「油價資料太舊時該怎麼顯示」的問題：同一個程式庫裡，光是這天就有37筆提交，一大半是同一件事反覆修正又撤銷暫時性自動化流程，直到晚上才穩定下來。
Mac一度完全開不了機，靠復原模式終端機救回
這天稍早，xmy的Mac發生了一次完全無法開機的事故，正常模式與安全模式都進不去。最可能的原因，是同時進行的高負載AI與開發工作，讓記憶體與磁碟暫存空間一起吃緊，系統失去回應。救援方式是進入macOS復原模式，用終端機找到被FileVault加密、還沒掛載的Data Volume，解鎖並掛載後，確認裡面的帳號資料都完整存在，再重新開機才成功進入桌面。開機後盤點，內部磁碟可用空間只剩47GiB，對高負載AI工作來說偏緊；隔天另外安排了一次磁碟安全清理。
相關事件報告
Mac 無法開機事件復盤與預防報告
高負載 AI 開發讓記憶體與磁碟同時吃緊，Mac 連安全模式都進不去。從 macOS 復原模式的終端機解鎖、掛載資料磁區救回，並整理原因分析、名詞白話字典與救援 SOP。