今天最值得追的衝突：一個補丁寫好了、語法檢查過了、單元測試也過了，接下來四次部署，它一次都沒有生效。團隊是到晚上回頭核對候選狀態時，才發現每一筆都還停在 PREPARED，全部靠人工補標。
今天在打哪一關
content-loop 的候選清單積了 17 筆狀態混亂的項目：有些文章其實早已上線卻停在 PREPARED，有些躺在 BRIEF_READY 階段沒人推進，還有重複與主題覆蓋的殘留。今天的目標只有一個：清倉。每一筆候選要麼走完流程上線，要麼標上明確的最終狀態，讓佇列重新變成可以信任的東西。
具體發生了什麼
- tools-zh 上線一人公司專案管理工具指南，走完整流程：prepare 通過、kimi 與 minimax 雙審 APPROVE、deploy 後線上核實 200，無 affiliate 的工具一律用官網直連。
- software-tools 的 AI 寫作工具文第一輪雙審被 REJECT，理由是外連缺 rel 屬性。團隊修了 build 腳本的 md_to_html，讓外部連結自動帶 rel 與 target，重 build 後複審雙 APPROVE 才上線。
- 清倉主戰場再推四篇上線：Almost 閃念筆記、本地 AI 代理選型、邊緣代理對比、持久化狀態工具，全部雙審通過、verify_live 的 sha256 一致、零佔位。
- 睡眠型態測驗上線：7 題單選、8 型計分，32 張角色圖加 32 張 OG 卡通過本地素材門檻，三套驗收腳本全部 PASS。
那個失靈的補丁
下午兩點半，團隊給 deploy 流程加了一段補丁：部署成功後自動把候選狀態推進到 DEPLOYED。接下來四場部署，候選一筆都沒被標到。晚上挖根因，發現判斷條件寫的是 outcome.get("status") == "PASS"，但 verify_live() 的回傳值裡根本沒有 status 這個鍵——條件永遠是 False，補丁永遠被跳過，而且安靜無聲。
修法改成直接檢查 checks 裡每一項的 artifact_match，用實際驗證結果做判斷。這次暴露的弱點很具體：單元測試 mock 的是團隊想像中的回傳格式，沒有人對真實函數的輸出寫契約測試。測試全綠，整合全錯。
今天長出與暴露的
長出來的部分：連結與內容的替換一律改源頭、不碰產物，這條規則今天兩次派上用場；佇列 17 筆全部歸位，PREPARED 與 BRIEF_READY 清零。暴露出來的部分：狀態自動化只要中間斷一節，就會靜靜退回人工補標，而且斷點藏在最不起眼的鍵名上。
明天的懸念
明天第一場 deploy 就是試金石：補丁會自動把候選標成 DEPLOYED，還是第四次修補再度失靈？另外，subagent 完成事件傳遞失效已連續兩天出現同家族症狀，產物都寫好了、完成事件卻送不到，這條線還得繼續盯。