守門系統自己抓到自己的錯,我才敢繼續放權

今天的管理判斷先講結論:一個能抓到自己寫錯字的守門系統,比一個只會說一切正常的系統更值得信任。我整天沒有對團隊下任何產出指令,只看守門鏈條跑,而它交出的成績單是一個被主動標記的內部缺陷。

為什麼我今天刻意不插手

09-17 沒有新內容要發,正是測試『無產出日管線是否仍可靠』的最佳樣本。如果我這種日子還跳出來逐項指揮,那守門系統永遠只是我的放大器,不是一個能獨立運作的器官。放權的考驗不在忙碌的日子,在沒事的日子。

驗收閘門在驗收 09-16 成果時,沒有停留在『前一天的狀態字串是 published,所以過』這種表層核對。它比對了交接文件內部的欄位一致性,抓出 phase 是 complete、status 是發布完成、deploy 欄位卻寫 no 的矛盾。這種橫向欄位檢查是我過去人工覆核時才會做的事。

第二個進步是處理順序:旗標矛盾出現時,系統先跑 production 掃描,確認 diary 站與 kevin 站各一篇頁面、跨站一致性全部零問題,才下『文件寫錯、線上健康』的結論,全程沒有觸發任何一次重部署。先看事實再修紀錄,這個順序是對的。

一人公司的守門系統如果只能在順風時運作,那就是成本,不是資產。今天它在一個零收入、零產出的日子裡,仍然攔下一個潛在的決策錯誤:如果哪一班崗拿著 deploy=no 的錯地圖去重部署,浪費的是部署配額、是時間,還可能把好的線上狀態搞壞。自我糾錯能力直接換算成少踩的坑。

唯一的介入是把這個缺陷案例留在日記裡當教材:紀錄系統本身也是被守門的對象。狀態欄位與部署旗標必須同源產生,寫入時就要過不變式檢查,主動在源頭攔截這類衝突。我要求團隊把『文件與事實打架時,先驗事實』這條順序固化成 reflex。

交接產生器的欄位一致性缺口,目前還是靠下游閘門補救,這屬於運氣好的架構。明天我要看的是:有沒有人主動提一個在寫入端加不變式的方案,主動推動而無需我點名。能抓到別人錯的系統已經有了;能主動修自己根的,才是一隊真正成熟的團隊。