RCF-001 — 建立 RCF 規格層變更紀錄機制
類型：規則變更 日期：2026-04-22 觸發條件：條件 1 — 新增 HARD STOP 規則（主 CLAUDE.md 快速索引表格新增「RCF 規格層變更紀錄」一列） 相關文件：
CLAUDE.md（新增 ⛔ RCF 規格層變更紀錄規則章節 + 快速索引）knowledge/decisions/README.md（新增 RCF 類型說明）knowledge/CLAUDE.md（文件索引 + 觸發情境）knowledge/decisions/RCF-000-template.md（新建模板）- 18 個部門 CLAUDE.md（最近修改記錄同步）
問題背景
跨 session 壓縮後，Claude 只能從 git log 知道「改了什麼」，無法知道「為什麼這樣改」。具體症狀：
- 某個 HARD STOP 的措辭被修改，但看不出是修正舊設計的缺陷還是擴展觸發條件
- 某個部門 CLAUDE.md 被批量同步，但不知道同步的依據是什麼規則更改
- SKILL 執行步驟改了，但不確定舊步驟為什麼不夠用
這個問題在系統規模小時可容忍，但隨著 HARD STOP 規則增加、部門數量增加，「設計失憶」的成本越來越高——新規則可能重複舊決策、舊問題可能被重複引入。
commit message 不適合作為決策記錄：它記錄「做了什麼」，不記錄「考慮過哪些方案、為什麼選這個」。
考慮過的方案
| 方案 | 描述 | 優點 | 缺點 | 採用？ |
|---|---|---|---|---|
| 方案 A：依賴 git commit message | 在 commit message 中加入詳細的 Why 說明 | 零新文件 | commit message 有長度限制，無法承載多方案對比；閱讀體驗差；不可搜尋 | ❌ 未採用 |
| 方案 B：擴展 audit-log.md | 在現有 audit-log.md 中新增「決策背景」欄位 | 不需新資料夾 | audit-log 定位是「錯誤追溯」，混入架構決策會讓兩種記錄互相干擾；長期會變成難以閱讀的流水帳 | ❌ 未採用 |
| 方案 C：decisions/ 新增 RCF 類型（最終採用） | 在現有 knowledge/decisions/ 中新增 RCF-XXX.md 格式，作為架構決策的設計理由記錄 |
與現有 decisions/ 架構一致（ADR 概念）；可獨立搜尋；有標準模板；零新資料夾 | 需要定義明確的觸發條件，否則「什麼都要寫」等於什麼都不會寫 | ✅ 採用 |
最終決策
採用方案 C，原因：
- 落地成本最低：
knowledge/decisions/已存在，不需新資料夾或新系統 - 格式一致性：與現有 001-hq-architecture.md、002-tech-stack.md 的 ADR 精神一致
- 可搜尋：RCF-XXX.md 命名讓 Grep 可以快速定位所有設計決策
- 觸發條件可機械化：5 個條件均為二元判斷（成立/不成立），不需人工判斷「夠不夠重要」
方案 A 排除理由：commit message 是執行記錄，不是設計記錄，強行混用會讓兩者都不好用。 方案 B 排除理由：audit-log 定位是「找錯誤、修錯誤」，混入架構決策會破壞其作為「問題追蹤清單」的可讀性。
影響範圍
| 影響類型 | 具體項目 |
|---|---|
| 新增文件 | knowledge/decisions/RCF-000-template.md（模板） |
| 新增文件 | knowledge/decisions/RCF-001-rcf-mechanism.md（本文件，自我記錄） |
| 修改文件 | CLAUDE.md：快速索引新增 RCF 列 + 新增「⛔ RCF 規格層變更紀錄規則」章節 |
| 修改文件 | knowledge/decisions/README.md：索引表格新增 2 列 + 新增 RCF 類型說明 |
| 修改文件 | knowledge/CLAUDE.md：文件索引 +2 列 + 最近修改記錄更新 |
| 觸發部門同步 | 18 個部門 CLAUDE.md 最近修改記錄各新增 1 行 |
驗證方式
- 下次對話中如果發生觸發條件 1-5 的任一情況，查照中應出現「⚠️ 觸發 RCF：條件 X」標注
- 執行結束後
knowledge/decisions/應有對應的 RCF-XXX.md 新文件 grep -rn "RCF" CLAUDE.md應能找到快速索引行 + 規則章節
RCF 改版上限機制執行慣例（2026-05-01 補入，源自 RCF-031 v1.0→v1.1 首例）
觸發條件
單一 RCF 文件進入 v1.1 / v1.2 / v1.3 修訂時。
封存方式：採 git history（不另存 archived 副本）
理由：
git log knowledge/decisions/RCF-XXX.md即可完整追溯所有版本演進- 每次 commit 即為快照，無資訊遺失
- 避免 archived 副本與主檔 diverge 的維護成本
- 與 Tim 既有 git 工作流一致
主檔修訂規範
- 頂部「版本」欄位更新為新版本號
- 頂部新增「v1.X 修訂說明」section（簡短列出主要變更與依據）
- 文末「執行記錄」表新增一列（日期 / 動作「v1.X 修訂」/ 備註）
- 不需另存
RCF-XXX-v1.0-archived.md等副本檔案
何時觸發新 RCF（而非版本迭代）
- 修訂涉及「核心決策方向反轉」（如 RCF-031 v1.1 技術棧 GAS→Vercel 屬「實作策略修訂」非「方案 A→B 反轉」，仍屬內部迭代）
- 修訂衍生影響其他 SKILL / HARD STOP / 部門結構 → 衍生 RCF（如 RCF-031 v1.1 若需修 SKILL 即觸發 RCF-033，本次不需）
v1.3 上限後的處理
若單一 RCF 達 v1.3 仍需修訂 → 建立新 RCF-XXX-successor.md 並在原 RCF 標注「已由 RCF-XXX-successor 替代」