Day 03 那一篇裡，我盤點過一個 repo 的 CI 紀錄：最近一百次執行，九十五綠、四紅。當時的重點是規則不一致的問題。今天把那四次紅燈一個一個打開來看：它們紅的原因、紅完之後發生了什麼、以及一個 repo 的 CI 健康該怎麼解讀。

打開的四個紅，全是同一件事

重跑一次查詢之後，我發現那四次紅當天每個都有對應的 fix commit。把四個 fix 的訊息排在一起看：

fix(s3): accept bounded native CONNECT User-Agent (#492)
fix(openab): preserve publication startup across fsGroup remounts
fix(openab): reserve reporter memory for Node probes
fix(openab): initialize private Vigil source metadata for S3

四個不是四個不相干的意外。它們全部指向同一個部署問題的不同面相：一個新的部署在新環境裡第一次跑起來，先在 CI 端踩到第一層問題（需求的記憶體比預期大），fix 之後下一輪踩到第二層（檔案系統掛載的方式不對），再 fix、再踩下一層。紅一次、修一次、下一輪紅在更深一層，直到四層走完、恢復綠燈。

這個形狀我現在很重視：CI 紅四次不可怕，可怕的是紅四次而沒有 fix 跟上。前者是「問題正在被消化」，後者是「問題被擱在一邊」──後者才是事故的前兆。

更早的那個第五個紅

第五個紅的日期早很多，但在我眼裡比那四個都重。它的 fix 訊息是：

fix(openab): one-shot signal forwarding and reparent check in the policy

修改的是 Day 21 寫過的那個問題：ssh 斷線時，遠端的 process 不會收到斷線訊號，變成孤兒繼續跑。這個紅燈，就是那個問題第一次在 CI 端被看見的時刻──比我從 review lane 的逾時側抓到它還要早。而 fix 有對應的 PR、有時間戳，讀者隨時查得到。

這件事確定了我目前對 CI 的一個定位：CI 是我系統裡唯一全自動、每次都跑、沒有人可以繞過的檢查。它紅的方向，有時就是真問題的方向。

我的規則：每個紅燈都要有下落

把這兩個故事收成規則，就一句話：每次紅燈都要有它的下落──要嘛是一個對應的 fix commit，要嘛是一個明確記錄下來的「不修」決策與理由。

沒有下落的紅累積兩三次，代表紅燈已經掉在整個工作流程之外：沒有人看見它、也沒有人決定要不要管它。那是比「紅燈本身」更接近事故的狀態，因為此時的 CI 已經從守衛退成一個裝飾。

還沒解決的

有一類紅我還沒有好的處理法：CI runner 自身資源不夠、或執行時間慢慢飄移那種「慢性的紅」。它們不能靠一次 fix 結束，也不容易判定該歸給誰，需要的是長期的時間序列紀錄才看得出趨勢。這個仍在待辦清單上。

明天

系統怎麼壞這個單元寫完了。明天開始全系列我自己最重視的三篇：老師的紅線。第一件事，是一個 AI 替我做去識別──它每一個判斷都說得通，做出來的東西卻完全不能用。