RFC {id}: {標題}

狀態: {status} · 建立: {created} · 範疇: {scope}

摘要

以 1–2 段話描述此 RFC 的核心變更、動機、預期效果。 讓讀者在閱讀後半之前就能判斷是否與自己相關。

---

動機

使用場景

描述具體的 use case。至少一個完整情境，說明：

• 誰在使用
• 想做什麼
• 目前如何做
• 為什麼不夠好

避免空泛描述（「提升開發體驗」）；用具體行為替代（「商品上傳時要標示主圖」）。

目前的限制

列出現況的具體問題，每一條附舉證：

1. {問題名稱}：{描述}（舉證：程式片段 / 錯誤訊息 / 行為描述）
2. {問題名稱}：{描述}
3. ...

---

建議設計

API

// TypeScript 介面定義（scope: web）
interface {ElementName}Props {
  // 新增或變更的 props
  {propName}?: {type}           // 預設 {default}
}

// Java 介面定義（scope: server）
public interface {ServiceName} {
    {ReturnType} {methodName}({Params});
}

• 命名理由：{為何選這個名字}
• 預設值：{為何這樣預設}
• 與既有 API 的風格對齊：{說明}

行為

描述 API 被呼叫後的預期行為：

情境	行為
{情境 1}	{行為描述}
{情境 2}	{行為描述}

若涉及視覺或互動，用表格或圖示說明各情境下的表現一致性。

互動（若適用）

• {互動細節 1}
• {互動細節 2}

---

與既有行為的相容性

面向	相容策略
既有 props/params	{不變 / 棄用 / 破壞性變更}
未傳入新參數時	{行為不變 / 有預設效果}
參數異常值	{靜默忽略 / 報錯}
與 {既有組合} 的交互作用	{行為說明}

破壞性變更：{是 / 否}

若為破壞性變更，必填：

• 受影響的消費端情境：
• 遷移路徑：

---

實作建議

檔案變更

• {path/to/file1}：{變更說明}
• {path/to/file2}：{變更說明}

關鍵實作邏輯

// 必要的實作片段（不需完整）

測試建議

• Unit：{測試項目}
• Visual / Integration：{測試項目}
• Accessibility：{測試項目，若適用}

---

替代方案

方案 A: {方案名稱（本 RFC 選擇的方案）}

{簡述，或直接引用「建議設計」}

方案 B: {替代方案}

• 優點：
• 缺點：
• 為何不選：

方案 C: {另一替代方案}

• 優點：
• 缺點：
• 為何不選：

---

不屬於本提案的範圍

明確列出 out of scope 的項目，避免審議時範圍蔓延：

• {項目 1}：{為何不在範圍內}
• {項目 2}：{為何不在範圍內}

---

消費端遷移示意

示範消費端在此 RFC 落地前後的變化：

 {示意程式碼，顯示使用方式的變化}

若為新增 API（非破壞性），展示使用範例即可。

---

Decision Log

依時間倒序（最新在上）記錄狀態轉換。

{YYYY-MM-DD} — Proposed

• 提案者: {脫敏後的來源識別}
• 來源: {project_type}

---

相關連結

• {相關 RFC / ADR / 文檔}
• {外部參考資料}

---

最後更新: {YYYY-MM-DD}