回饋與 RFC 流程
兩個入口，同一套判準
| 誰 | 送到哪 | 格式 |
|---|---|---|
| 取用端的 agent（其他系統的 repo 裡、連得到維護方 PMIS） | PMIS 系統 DESIGN 的 task，標題以 [回饋] 開頭 | AGENTS.md「回饋到上游」——格式正本只有那一份 |
| 人，或沒有 PMIS 的外部讀者 | 下一節的 GitHub 表單與 PR | 表單欄位 |
取用端在用的當下就送，不必等自己湊滿三次——單一系統只看得到自己的用例，三次由守門人在上游跨系統數。 PMIS 是維護方的內部帳、這個 repo 是公開的，所以 GitHub 表單留著給人用；兩邊的判準（下面的五題、三次法則、守門人三問）相同。
GitHub：三種回饋，三條路
| 類型 | 路徑 | 入口 | 期望回應 |
|---|---|---|---|
| Bug | Issue，附最小重現 | Bug 回報表單 | 直接修 |
| 小調整（文案、對比、一個 prop） | PR 開到 dev，附截圖或說明 | 開 PR（模板自帶自查清單） | Review 後合併進 dev |
| 新元件 / 新 token / 改語意 | RFC | RFC 提案表單 | 討論後決定 |
另有一個低門檻入口：缺件認領表單—— 頁面章缺件表的項目，回報一個使用場景＝三次法則的一次證據， 證據齊了由守門人升級成 RFC 或直接動工。拿不準走哪條路，先開缺件認領，不會錯。
RFC 要回答的五題
## 問題
使用者遇到什麼？不解決會怎樣？
## 三次法則證據
這個東西在哪三個地方實際被需要過？（要有具體出處，不是「以後可能會用到」）
## 提案
API 長什麼樣？舉一個真實的使用情境。
## 替代方案
考慮過什麼？為什麼不採用？（沒有替代方案通常代表想得不夠）
## 影響
會不會改變既有行為？需要 major 嗎？現有使用者要做什麼？
正式提案直接用 RFC 表單， 欄位與這五題一對一、逐欄必填。符合性台帳的四題 （問題、建議、影響範圍、如果不改會怎樣）是它的下游速記版—— 在自己 repo 的台帳裡記錄用四題；取用端 agent 送 PMIS 的回饋，骨架後四段就是這四題，三次證據由守門人在上游串起來； 人送正式提案用表單五題。
三次法則
只收實際用過三次以上且穩定的東西。
同一個問題在三個不同地方各自解決過一次 → 現在可以抽象了， 而且你已經知道它的三種形狀。
不要在第一次遇到時就抽象。你只看過一種形狀， 抽出來的介面九成會在第二次使用時被推翻——然後就變成一個沒人敢改的舊介面。
三次法則的例外：已知的無障礙或安全問題。這種不必等三次。
三次由守門人在上游數，不是由單一取用端數。 每個宿主只看得到自己的用例—— 各自數到一就停下來的話，三個宿主的證據永遠不會相遇。所以取用端每遇到一次就送一則回饋，串連是守門人的事（見下方「取用端回饋：PMIS 的分流」）。
誰決定
必須有明確的守門人（一個人或一個小組）。
沒有守門人的設計系統，三個月後會有五種按鈕—— 每一種都是某次「這個 case 比較特殊」的產物，而且每一次都很合理。
守門人的工作不是說「不」，是問：
- 三次法則過了嗎？
- 拿掉領域脈絡還成立嗎？
- 現有元件真的做不到嗎？
本 repo 的守門人：@kielchang（.github/CODEOWNERS 宣告；
核准版的閘門——staging → main 的合併——由 ruleset 與 PR 上的核准清單強制，見版本策略「三段式發布」）。
token 與基礎章是全系統契約，與其他部分同一位守門人——分開設的前提是有第二位維護者。
提案的狀態機
RFC 的狀態用 label 表達，狀態轉移只有守門人動手：
| label | 誰掛 | 語意 |
|---|---|---|
rfc | 表單自動 | 類型標記，永不移除 |
rfc:討論中 | 表單自動 | 開立即此態，任何人可討論 |
rfc:已接受 | 守門人 | 三問通過；在 PMIS 開一個有到期日的計畫，見下節 |
rfc:已婉拒 | 守門人 | issue 留一句可被推翻的理由後關閉（「因 X 不收，待 Y 成立可重提」） |
rfc:已擱置 | 守門人 | 通常是三次證據未滿——用缺件認領湊證據，齊了改回討論中 |
可過濾就可治理：「所有擱置中的提案」是 一個網址， 不是一份要人記得維護的清單。
取用端回饋：PMIS 的分流
取用端 agent 照 AGENTS.md「回饋到上游」在 PMIS 系統 DESIGN 開 task——
格式正本只有那一份，tests/feedback-intake.test.ts 盯著它不分岔、不被別頁另抄一份。
一則＝一個場景＝一次證據，送件方記台帳的同一刻就送。
狀態用 task 的四態表達，轉移只有守門人動手（送件方送出後不改狀態）：
| task 狀態 | 對應 Issue label | 語意與守門人的動作 |
|---|---|---|
backlog | rfc:討論中／rfc:已擱置 | 新進，或證據未滿。在描述末尾記 同類：#a #b 把同對象的回饋串起來；連本則湊滿三則就往下走 |
todo | rfc:已接受 | 三問通過。小調整直接修；新元件／新 token／改語意在 PMIS 開計畫（feature），並在本則描述追加 → feature #N |
in_progress | — | 實作中 |
done | 關閉 issue | 描述末尾加 ## 守門人結論：「已處理於 vX.Y.Z」，或「已婉拒：因 X 不收，待 Y 成立可重提」 |
- 不符規範不等三次：確認是 bug 就直接進
todo。無障礙與安全問題標high，收到即處理。 - 計畫的連結寫在描述裡：task 建好之後掛不上 feature，所以用
→ feature #N一行表達。 - 改描述是整段取代：追加結論前先讀出原文，原文照留、結論接在後面。
- 婉拒不刪：下一則同類進來時，先重讀上一則的結論——理由寫成可被推翻的形式，就是為了這一刻。
節奏——人工：守門人，每次開 dev → staging 的 PR 之前，列出 DESIGN 的 backlog task，逐則處理標題以 [回饋] 開頭的。
這一條沒有守衛，漏了不會紅；試行期的成效指標也記在 PMIS 那一則計畫裡。
RFC → 計畫 → 決定：落點在 PMIS
Issue 與 PMIS 裡的回饋都是討論紀錄；計畫與決定記在維護方內部的 PMIS，本站不放——兩本帳分工，RFC 與回饋是它們之間的橋：
- 已接受（label
rfc:已接受，或回饋進todo）：在 PMIS 開一個計畫（問題與假設、時間上限、最小試驗、成功訊號與門檻、這次不做什麼、沒達標時的預設結局）。 實作 PR 合併時關閉 issue、回饋寫結論改done；結案時若成立了難以回頭的決定，才在 PMIS 記一則 ADR。 - 已婉拒：理由留在 issue 或回饋的「守門人結論」，不開計畫——沒發生的事不佔紀錄。
本站不設 docs/rfc/ 檔案庫，也沒有決策紀錄章：規則在守衛與各章那一句，理由跟著規則走；
來龍去脈是內部決策，留在 PMIS。第三本帳必與前兩本重疊，重疊的帳本一定漂移。
淘汰也要有流程
新增有流程，移除也要有：
- 標記棄用（
@deprecated，說明替代方案） - 保留至少一個 minor 版本
- 下一個 major 移除
沒有淘汰流程的設計系統只會越長越胖，最後沒有人知道哪些還能用。