管理判斷先講：與其再開新主題，今天整隊只做一件事——清倉。17 筆候選，4 篇走完雙審上線，13 筆把狀態修正到與現實一致，收工時 PREPARED 與 BRIEF_READY 全部歸零。開新案永遠比較迷人，清倉永遠比較無聊，但佇列失真一天，所有優先級判斷就錯一天。
為什麼在意這件事
一個停滯的候選清單有兩種敗法：已上線的東西顯示成待辦，團隊會重複花力氣；待辦的東西顯示成就緒，老闆會以為產能比實際大。兩種都直接污染決策。今天看到的 13 筆狀態修正，等於 13 個曾經錯誤的儀表板讀數，這種東西放著不管，代價比少發四篇文章高得多。所以我寧可讓今天的主題停在後台，也要把佇列先清到能信任的狀態，再談接下來要寫什麼。
今天看到的進步
- 四篇上線全部走完整流程，雙審、部署、線上 sha256 核實一關不缺，REJECT 就真的打回重修再上。
- 替換連結踩坑一次之後，規則定清楚了——改源頭、不碰產物，今天 build 腳本與內容源檔都按這條走。
今天看到的問題
- deploy 自動回寫候選狀態的補丁，四次部署完全沒生效，最後靠人工補標。自動化斷一節，流程就退回手工，而且沒有任何警報。
- 根因：判斷條件依賴一個根本不存在的回傳鍵。測試全綠，因為測試 mock 的是我們想像中的介面。
今天教 AI 的事
兩條。第一條：替換任何連結或內容，先找到真正的源頭再動手；改產物的修法會被下一次 build 覆寫，還會讓品質檢查與產物對不上。第二條：對外部函數的回傳值，永遠寫契約層的驗證，別拿想像中的欄位寫判斷。一個不存在的鍵可以讓整段自動化安靜失效四次，這是最貴的安靜。這兩條聽起來都小，但它們剛好各踩在今天最痛的兩個坑上。
明天還要看的
三件事：修正後的補丁在真實 deploy 中是否自動生效；人工補標過的候選有沒有遺漏的邊角；subagent 完成事件傳遞失效是否連續第三天出現。清倉清的是存量，這三項是流量端的風險，盯到收斂為止。