回饋與 RFC 流程
三種回饋，三條路
| 類型 | 路徑 | 入口 | 期望回應 |
|---|---|---|---|
| Bug | Issue，附最小重現 | Bug 回報表單 | 直接修 |
| 小調整（文案、對比、一個 prop） | PR，附截圖或說明 | 開 PR（模板自帶自查清單） | Review 後合併 |
| 新元件 / 新 token / 改語意 | RFC | RFC 提案表單 | 討論後決定 |
另有一個低門檻入口：缺件認領表單—— 頁面章缺件表的項目，回報一個使用場景＝三次法則的一次證據， 證據齊了由守門人升級成 RFC 或直接動工。拿不準走哪條路，先開缺件認領，不會錯。
RFC 要回答的五題
## 問題
使用者遇到什麼？不解決會怎樣？
## 三次法則證據
這個東西在哪三個地方實際被需要過？（要有具體出處，不是「以後可能會用到」）
## 提案
API 長什麼樣？舉一個真實的使用情境。
## 替代方案
考慮過什麼？為什麼不採用？（沒有替代方案通常代表想得不夠）
## 影響
會不會改變既有行為？需要 major 嗎？現有使用者要做什麼？
正式提案直接用 RFC 表單， 欄位與這五題一對一、逐欄必填。符合性台帳的四題 （問題、建議、影響範圍、如果不改會怎樣）是它的下游速記版—— 在自己 repo 的台帳裡記錄用四題，送到上游用表單五題。
三次法則
只收實際用過三次以上且穩定的東西。
同一個問題在三個不同地方各自解決過一次 → 現在可以抽象了， 而且你已經知道它的三種形狀。
不要在第一次遇到時就抽象。你只看過一種形狀， 抽出來的介面九成會在第二次使用時被推翻——然後就變成一個沒人敢改的舊介面。
三次法則的例外：已知的無障礙或安全問題。這種不必等三次。
誰決定
必須有明確的守門人（一個人或一個小組）。
沒有守門人的設計系統，三個月後會有五種按鈕—— 每一種都是某次「這個 case 比較特殊」的產物，而且每一次都很合理。
守門人的工作不是說「不」，是問：
- 三次法則過了嗎？
- 拿掉領域脈絡還成立嗎？
- 現有元件真的做不到嗎？
本 repo 的守門人：@kielchang（.github/CODEOWNERS 落地）。
token 與基礎章是全系統契約，與其他部分同一位守門人——分開設的前提是有第二位維護者。
提案的狀態機
RFC 的狀態用 label 表達，狀態轉移只有守門人動手：
| label | 誰掛 | 語意 |
|---|---|---|
rfc | 表單自動 | 類型標記，永不移除 |
rfc:討論中 | 表單自動 | 開立即此態，任何人可討論 |
rfc:已接受 | 守門人 | 三問通過；同時開一則 ADR（提議中），見下節 |
rfc:已婉拒 | 守門人 | issue 留一句可被推翻的理由後關閉（「因 X 不收，待 Y 成立可重提」） |
rfc:已擱置 | 守門人 | 通常是三次證據未滿——用缺件認領湊證據，齊了改回討論中 |
可過濾就可治理：「所有擱置中的提案」是 一個網址， 不是一份要人記得維護的清單。
RFC → ADR：決策的落點
Issue 是討論紀錄，ADR 是決策紀錄——兩本帳分工，RFC 是它們之間的橋：
- 已接受：守門人開一則 ADR（狀態「提議中」，背景段連回 issue） → 實作 PR 合併時，ADR 改「已採用」、issue 關閉。
- 已婉拒：理由留在 issue，不寫 ADR——沒發生的事不佔決策紀錄。
為什麼不設 docs/rfc/ 檔案庫（Rust／React 模式），
見 ADR-0009：第三本帳必與前兩本重疊，重疊的帳本一定漂移。
淘汰也要有流程
新增有流程，移除也要有：
- 標記棄用（
@deprecated，說明替代方案） - 保留至少一個 minor 版本
- 下一個 major 移除
沒有淘汰流程的設計系統只會越長越胖，最後沒有人知道哪些還能用。