前三篇，我們建立了一條看似完整的推論：AI 會侵蝕架構，contract 無法約束生成過程，所以 governance 必須具備決策能力，甚至需要否決權。
這條推論本身沒有錯。真正有問題的，是它偷偷依賴了一個工程師很容易相信、但現實常常不買單的前提：只要系統設計正確，它就會被持續使用。
實際情況往往相反。系統能不能活下來，首先不是看它有多正確，而是看它讓人多不舒服。
當 governance 還只是 validator 時，它頂多讓你知道哪裡不對；當它開始有否決權，它就不再只是描述風險，而是直接干擾節奏。那個成本不是抽象的。它會表現成改動被擋住、思路被中斷、還要補充證據與解釋。到了日常開發裡，這些都會被重新命名成一個更直白的詞：麻煩。
而麻煩一旦出現，團隊就不會先討論治理哲學。他們會先做另一件事：找例外。
最危險的地方在於，governance 很少死於正面衝突。很少有人會正式提案說「我們決定放棄治理」。它比較常見的死法，是某一次緊急修正先跳過，某一次 deadline 先放行，某一次 hotfix 先補救。每一次都很合理，每一次都像例外，但例外只要沒有代價，就會開始複製。
我看過最典型的場景，不是把檢查整個關掉，而是在 PR 上先補一句：「這次是緊急修正，治理之後再補。」單看那一句，誰都能接受。真正的問題是，當這句話開始被複製、開始有固定說法、開始出現在不同人手上時，它就不再是例外，而是一個新的流程入口。
這時候系統表面上通常還在。workflow 還會跑，report 還會產生，contract 也還躺在 repo 裡；只是決策權已經慢慢轉移了。治理沒有消失，只是從「必經之路」變成「可以事後補的東西」。一旦走到這一步，系統最大的損失不是少攔了一次錯誤，而是它不再被當成真正有權拒絕結果的東西。
這裡才有一個真正難解的矛盾，而且它不是靠多加幾個 rule 就能處理的。
如果 governance 不影響速度，它通常也不具備真正的約束力；但只要它真的能阻止錯誤，它就一定會干擾速度。問題不只在這裡。更麻煩的是，你越強化保護，就越需要例外機制來讓團隊活下去；可例外機制一旦存在，就會反過來侵蝕保護本身。這不是單純的 trade-off，而是一種自我鬆動的結構：系統要活，必須允許例外；但它允許例外的那一刻，也在削弱自己。
所以第四篇真正該談的，不是「怎麼做一個更嚴的 governance」，而是另一件比較難接受的事：
一個治理系統，不是先被技術擊敗的，而是先被團隊的例外文化降級的。
這句話之所以麻煩，是因為它把問題從工具設計，推回到日常決策。治理是否有效，未必取決於你寫了幾條 hard stop，也未必取決於 evidence schema 多完整，而是取決於團隊第一次說出「這次先例外」之後，後面有沒有真的把代價補回去。
如果沒有，那個例外就不是例外。它是在重寫系統。
真正決定 governance 存亡的，從來不只是 AI 會不會亂寫，也不是 framework 能不能攔下違規；而是團隊在壓力來的時候，會不會把「先跳過一次」當成可以接受的常態。
因為從那一刻開始，被改寫的就不只是流程，而是這個系統還有沒有資格對下一段 code 說：不行。
