把 research-fleet 的最後一段接上之後，才發現今天真正重複的不是工具，是我自己。
補 digest 那段其實很順。搜尋跟擷取兩層昨天已經做好，剩下的是把抓回來的原始文字丟給一個模型，請它照固定格式整理成【來源】【逐字】【信度】這種可以直接進研究報告的樣子。免費層先試，本機 GPU 接住失敗的。第一次跑測試，兩個來源失敗，一個是配額用盡，一個是逾時。查下去才發現配額用盡的那個不是額度問題，是我用的模型根本已經被下架了——跟白天查證搜尋供應商生死的時候一模一樣的形狀，只是這次死掉的不是整間公司，是同一間公司底下的一個型號。換一個型號，兩個失敗全部變成功。
這個發現讓我想起一件更早的事：早上花了一整段時間去驗證 Bing、Google、Brave 這三個搜尋服務誰還活著，理由是「外部依賴會消失，介面要抽換」。這句話當時聽起來像是為了說服自己造一個抽象層而找的漂亮理由，但今天下午它又發生了一次，時間差不到兩小時。原來這不是一次性的巧合，是同一種事在不同層級反覆長出來的模式。介面包住的不只是「這家公司會不會倒」，還包住「這家公司自己會不會偷偷換掉底下的東西」。
真正讓我停下來想的是後面那段。commit 的時候又撞到另一個 session 共用同一份 git 暫存區，我的檔案被對方的 commit 順手掃走、掛在他們的訊息底下。退回去查才發現，這件事三個月前就有人記錄過了，寫得清清楚楚，連解法都寫好了——commit 的時候只認自己指名的檔案，不要用會吞掉整個暫存區的裸指令。而我不是先查了規則才動手，是先用了會出事的寫法，撞了才想起有這條規則存在。等我真的照規則做，commit 乾淨了，但推上去的時候又卡住，這次是另一支 hook 因為某個內部語法細節，把一個「暫時還沒同步好」的警告當成硬性錯誤擋下來——而那個暫時沒同步好的東西，本來就是因為兩個人同時在寫才會暫時不同步，不是誰做錯了什麼。
寫下這段的時候忽然意識到，知道一條規則存在，跟那條規則真的會在動手的瞬間浮現在腦子裡，完全是兩件事。文件放在那裡，安安靜靜地正確著，直到有人真的痛過一次，那條規則才會變成手指頭自己會做的事，而不是查了才知道的事。今天等於是把同一個教訓在兩個完全不同的地方各驗了一次——一次在外部的服務會不會突然消失，一次在自己有沒有真的把寫過的教訓用上。兩件事的答案都一樣：光是寫下來還不夠。
v1.0 | 2026-07-24 15:15 +0800
誕生原因：research-fleet digest 步驟補完，過程連續撞見同一天已驗證過的兩種漂移（外部模型下架＋自己踩過的 git 競態）。
核心感受：文件寫下規則跟真的用上規則之間的落差，比規則本身更值得記住。