前言

昨天把要做的系統講清楚了。今天在寫任何規格之前，得先處理一件事：這個專案是全新的，沒有既有程式碼可以讓 AI 先讀懂。

昨天說到

昨天介紹了要做的系統：一個會議紀錄的版本控管與簽核工具，核心是版本控管、簽核流、稽核軌跡。

但在把這些寫成規格之前，有一個前置問題。

AI-DLC 的流程裡，有一步是先讀懂既有的程式碼與慣例，再提案。這一步在成熟的專案上很合理，因為程式碼裡本來就藏著沒有被正式寫下來的約定：命名怎麼取、錯誤怎麼處理、目錄怎麼分。

這個專案目前只有在D04補的一個骨架，所以第一步要反過來做：不是先讀懂慣例，是先把慣例定下來。

補足先前那份 CLAUDE.md

Day 04 跑過 /init，產出了 77 行的 CLAUDE.md，裡面有技術棧、常用指令、目錄結構，以及一些從專案中看得出來的分層意圖。當時的結論是：/init 寫的是現況，真正的團隊規範要自己補。我補了以下三塊：

一、協作規則

這一塊比較偏向人與 AI 的合作方式，它不一定能被自動檢查，但至少要寫成可以在 review 時指認的句子。

## 怎麼跟我協作
- 改動超過三個檔案時，先講你要改什麼，我確認再動。
- 只改我指定的範圍。看到旁邊有問題就說出來，不要順手改掉。

第二條其實就是針對前面一直遇到的「改 A、結果壞 B」問題。

二、不可違反的業務規則

昨天定下來的三個核心，這次直接寫成程式碼必須遵守的規則：

## 不可違反的業務規則
- 記錄一旦送出就唯讀。要修改只能建立新版本，舊版本永遠保留。
- 全員確認才生效；任何一人退回，該版本回到草稿。
- 退回時清除該版本已有的確認。

這三條有一個共同點：都寫得出測試，所以它們之後會變成 Test，而不是停在文件裡。

三、什麼算做完

這一塊要寫成真的跑得動的指令，而不是「記得測試」：

## 什麼算做完
- `cd backend && uv run pytest` 全綠
- `cd frontend && npm run build` 通過（這就是 typecheck）

這塊還有一個附帶好處：它跟前幾天那支 Stop hook 是同一件事的兩種寫法

CLAUDE.md 寫的是期待，hook 寫的是門檻。

兩邊規則一致的時候，才會形成比較完整的約束，讀得到，也擋得住。

寫不成檢查的，我沒有寫進去

上面三塊裡，我刻意沒有放這類句子：

• 「保持程式碼簡潔」
• 「遵循最佳實踐」
• 「這是一個小型專案，不要過度設計」

它們看起來很正確，但沒有任何一句能在 review 時用來指認具體的某一行。

形容詞式的原則不會保護你，它只會讓你以為自己被保護著。

如果真的想約束「不要過度設計」，可行的寫法是把它變成可以數的東西，例如「新增第三方相依套件前要先問」。

小結

• 專案沒有慣例可以讀懂，所以 AI-DLC 的第一步要反過來做：先把慣例定下來。
• 這次補進 CLAUDE.md 的主要是三塊：協作規則、不可違反的業務規則、完成條件。
• 業務規則和完成條件，之後可以繼續落到 Test 與 Hook；協作規則雖然不一定能自動檢查，但至少讓 review 有明確依據。

明天：慣例定下來了，接下來要把「我想做什麼」變成一份 AI 能執行的規格。但我不打算自己寫——我想讓 claude 來訪問我。