Day 22 開頭的稽核不止抓到一個 symlink。同一天，我發現一個更貫穿主題的問題：我最脆弱的一批資產：自己停用的、自己熱修的、自己調過的狀態，全部沒有記錄，而每一次工具同步都可能把它們悄悄洗掉。

同步工具的兩把刀

我的 skills 目錄有一支同步腳本，把 git 正本的內容同步到 live 的 runtime。它有個參數打開時，會用「鏡像」模式同步：live 端多出來的、正本沒有的東西，全部刪掉。

第一個問題：runtime 自己的狀態目錄也在 live 端。其中一個是我「停用 skill」的機制所在：把 skill 丟進去，載入器就跳過它。dry-run 我實際跑了，鏡像模式會把這個停用清單整批刪掉。刪掉的意義我當時寫在 issue 裡：**等於把我親手停用的 skill，靜默重新啟用。**沒有報錯、沒有留言，就是收回去。

第二個問題更隱：我七月三號手動把某些技能挪進了停用清單，這麼做本來應該走正本 + 開 issue 的流程，我當時繞過了。但繞過不是問題本身。問題在於正本那邊的清單沒有跟著改：正本仍把那兩個技能列為活，這表示任何一次同步，就算不開鏡像模式，也會把它們寫回去，重新啟用我停用的東西。這個地雷就這樣天天埋在看不見的地方等著。

結構問題，不是七個 bug

那次稽核的發現，我起初照 bug 一條條修。修完後我把七個問題攤開來看，發現它們不是七個獨立的失誤，它們背後是三個結構性缺陷：

第一，正本鏡像 runtime，但「哪些歸正本管、哪些歸 runtime 自己管」，這條線沒有寫在任何宣告裡，只隱身在幾支腳本各自的排除清單中。runtime 有一天新增一個狀態檔，沒有任何機制會抗議「這裡多了一個誰都沒宣告的名字」。

第二，「改了 git」到「agent 行為真的變了」之間是斷的。Day 22 的 symlink 是這個缺陷最赤裸的形：檔案在、路徑對、無訊息、無效果。

第三，live 可以被手改，正本那邊完全盲區。停用清單那兩個技能，停用的當下沒有記錄，正本的清單還把錯的狀態當成真相。

怎麼補的（以及為什麼照這個順序排）

修法我按「防住多少類問題 ÷ 維護成本」排了順序。

排序最高的是：把檢查排程自動跑，只在失敗時發訊息。那兩小時的考古變成三秒鐘的排程檢查，差別只在有沒有掛上排程。第二是「未宣告項目」檢查：live 目錄的每一個頂層條目，必須要嘛是 git 追蹤的內容，要嘛在 runtime 狀態清單裡，兩者皆非就報。大約二十行，一次掐住上列缺陷的全部變種。第三也是最後的：比對「實際載入了什麼」，不只比對檔案本身在不在──這是 Day 22 的缺口直接得到的待遇。

同一條線上後來還有一件事：升級 pipeline 本身被加強（就是 Day 12 到 14 我反覆提到的那個 PR），其中最主要的一件事，就是升級前先驗證「live 與正本現在誰有漂移」，避免升級把我的客製化直接蓋掉。那個 PR 的審查攻防，我前面已用三天講過，這裡只補一句關聯：它被寫出來的原始動機，就是我今天寫的這件事。

還沒解決的

停用機制的「記錄」側還欠著：現在如果我繞過既有流程去停用一個技能，檢查會抓得到，但繞路的動作本身仍要有儀式感，靠的是我自己的紀律而不是工具強制。

明天

工具的坑一個個填了，還有一類壞法不是工具造成的：CI 紅燈。不是「紅了怎麼辦」，是「紅了四次的時候，那些紅各自代表什麼」。明天講這個。