符合性台帳
問題
導入之後的第二個月，會開始出現這種對話：
「我們的表格算是照設計書做的嗎？」 「應該算吧，欄位設定那些都有。」 「那分頁預設值不一樣是怎麼回事？」 「那個是因為……我忘了，那時候好像有原因。」
問題不在於「不一樣」——不一樣通常是對的，宿主專案有它的理由。 問題在於沒有人知道哪些不一樣是刻意的、哪些是抄漏的。
一年之後這兩者已經無法分辨，於是升級上游變成一件沒人敢做的事： 你不知道跟進會踩爛什麼，也不知道不跟進會錯過什麼。
做法：一份台帳，三種狀態
每一個本地元件在台帳上有一列，狀態只有三種：
| 狀態 | 意思 | 後續動作 |
|---|---|---|
| 遵循 | 對齊上游同名項目的規範與行為 | 上游 bump 時評估跟進 |
| 自製 | 上游沒有，本專案自行設計 | 具通用性 → 依三次法則寫提案 |
| 刻意偏離 | 上游有，但本專案做法不同 | 必須寫原因 |
台帳的價值全部集中在第三種狀態的那句話上：
核心規則
刻意偏離必須寫原因。沒寫原因的偏離不是偏離，是待修項目。
這條規則之所以有效，是因為它把成本放在正確的地方： 偏離當下寫一句原因只要 30 秒，事後考古要一整個下午，而且經常考古不出來。
原因要寫成可以被推翻的形式：「上游只收 A，本地因為 B 而保留 C， 待 D 完成後移除」。
不要寫「配合現有架構」。這句話沒有內容，它唯一的作用是讓這一列看起來 已經被檢討過。
不屬於設計系統範圍的東西不要進台帳。 綁定業務領域、依賴狀態管理或路由的元件， 本來就不該對齊上游，把它們列進去只會讓台帳長到沒人讀。 在台帳最後開一節列出來、註明「不需要對齊」即可——明說不管，也是一種管。
唯讀鐵律：下游不寫上游
上游與下游是兩個獨立的 repo，關係是單向的：
上游 ──讀──→ 下游 （隨時，拉下來自己評估）
上游 ←─提案─ 下游 （走 PR，不是直接寫）
沒有 submodule、沒有共用工作區、沒有自動同步。理由不是潔癖，是兩邊的節奏不同： 下游要趕的是這個月上線，上游要顧的是所有宿主。 任何自動同步機制都會讓其中一邊的急事變成另一邊的意外。
實務上建議把唯讀做成環境事實而不只是規範——下游的環境對上游沒有寫入權限。 規範靠人記得，權限不用。
提案 → PR → 合併 → 才實作
發現上游規範有問題（缺一種狀態、規則不合用、有更好的做法）時：
在下游發現問題
→ 寫提案（問題、建議、影響範圍、如果不改會怎樣）
→ 帶去上游開 PR
→ 上游確認並合併
→ 才回頭更新台帳與本地實作
括號裡的四題是 RFC 五題的速記版，用在自己 repo 的台帳與內部討論； 正式送上游用 RFC 表單 （五題逐欄）或直接開 PR——入口都列在回饋與 RFC 流程。
最後一步的順序是重點：未合併的提案不得在下游先行實作。
先實作的誘惑很大——反正提案一定會過、反正我這邊很急。 但只要上游在審查時改了任何一個決定（換個 prop 名、多一種狀態、換個預設值）， 下游就得二次修改；而在二次修改完成之前，台帳上那一列既不是遵循也不是偏離， 它處在一個沒有名字的狀態，而這個狀態會存活得比預期久很多。
急著上線就先記成「自製」或「刻意偏離」並寫明原因， 同時把提案送出去。合併之後再改成「遵循」。
不要一邊等 PR 一邊把上游還沒同意的做法寫進本地元件。 兩邊各走各的路，只需要一次就夠。
兩本帳，分工不重疊
宿主專案需要兩份紀錄，它們回答的是不同的問題：
| 帳本 | 回答 | 讀者 |
|---|---|---|
| CHANGELOG | 我的元件庫這次改了什麼 | 用這個元件庫的人（含未來的自己） |
| 符合性台帳 | 我跟上游的關係是什麼 | 要決定「上游 bump 了，我跟不跟」的人 |
分開的理由：CHANGELOG 是時間序（一直長），台帳是現況快照（維持同樣長度）。 混在一起的話，「現在的狀態是什麼」要靠讀完整部歷史才拼得出來。
一次變更常常兩本都要動：改了元件 → CHANGELOG 加一則； 如果這次改動讓某個元件從「刻意偏離」變回「遵循」→ 台帳那一列也要改。
上游更新不自動套用
怎麼知道上游 bump 了：Watch 上游 repo 的 Releases（每次進版自動發， notes 就是 CHANGELOG 那一則；完整訊號表見跟上新版）。 訊號送上門之後，動作是：
拉取 → 對台帳逐列評估 → 決定跟不跟 → 更新台帳的上游版本欄
不是 npm update 然後看 CI 綠不綠。
升級是一個決定，不是一件意外。 設計系統的變更會改動已上線畫面的外觀與行為—— 即使是修對比、調間距這種「小事」，對已經對齊過版面的宿主都是可見的變化。 逐列評估讓這些變化在被使用者看到之前，先被人看到。
台帳在這一步的作用很具體：標「遵循」的列才需要評估。 標「自製」的不受影響，標「刻意偏離」的只需要重讀一次原因—— 「當初偏離的理由還成立嗎？」有時候上游這次的改動正好解掉了偏離的原因， 那一列就可以收回來。
離線摘要：帶著關鍵規範走
宿主專案在自己的 repo 裡留一份離線摘要：色彩語意的四組 token、 模式的一句話版本與反例、無障礙的門檻值。不是完整複製，是最常用的判斷依據。
理由很實際：需要做判斷的時刻，往往是最沒空去讀完整文件的時刻。 如果查一條規則要先開瀏覽器、找到站台、翻到那一章，那麼在趕時間的時候， 它就會被跳過——這正是漂移防護講的同一件事。
摘要要明講它是摘要，並附上「完整內容請讀上游」與取得方式。 它的定位是加快判斷，不是取代來源。
不要把摘要寫成第二份規範。一旦它開始出現上游沒有的規則， 它就變成一個沒有人維護的分支——而且因為它比較近、比較好查，大家會讀它不讀上游。
順帶把取用方式的環境限制也寫進摘要：哪條路通、哪條路不通 （文件站被公司 proxy 擋、API token 的授權範圍只涵蓋自己的 repo…）。 沒寫下來的話，每個新加入的人都會自己重新撞一次同樣的牆。
取捨
代價：多一份要維護的檔案。
減災的方式是讓台帳短。它不是文件，是一張表：一列一個元件， 狀態一個詞，備註一句話。長到需要目錄的台帳，就是已經沒有人在讀的台帳。
這份成本要不要付，取決於一件事：你打算跟上游維持關係多久。 如果只是抄一次就分家，不需要台帳——但那樣的話也不需要上游， 把程式碼複製走並刪掉出處即可，至少誠實。 台帳存在的前提，是你還打算再升級一次。