跟 Claude Code 討論完一個技術選型，聊完了，視窗一關，剛才「為什麼選這個方案」的推理過程就只留在聊天記錄裡——半年後想確認當時的取捨，只能往上翻對話，或者，翻不到。

note-metadata-schema（Day04）的 type 受控詞彙早就把 adr 列進去了，跟 inbox-draft、atomic-note、hub-note 並列。但這幾天 demo repo 裡跑過的所有流程——brain capture 捕捉草稿、/refine-inbox 分類搬移、Day16 自動織入雙向連結——沒有一個會產生 type: adr 的筆記。這格早就留好了，卻一直是空的。原因不是忘記做，而是 ADR 這種筆記的「原料」跟其他筆記不一樣：/refine-inbox 處理的前提是 00_Inbox 裡已經有一篇使用者手寫的草稿；但技術決策通常不是先寫成草稿，而是先在跟 Claude Code 的對話裡把問題、方案、取捨都討論過一輪，才想到「這個決策應該留一份紀錄」。起點是對話，不是檔案。今天要補的 /new-adr，就是把這段落差接起來。

為什麼不是「先進 00_Inbox，再走一次 /refine-inbox」

第一個很自然會冒出來的做法：把整理好的決策內容當成一篇草稿，用 brain capture 丟進 00_Inbox，再跑 /refine-inbox 走一次既有的分類搬移流程，這樣還能直接沿用 Day15/16 已經寫好的所有邏輯，不用新增指令。

但這個做法在概念上是繞路的。/refine-inbox 的分類判斷（CLAUDE.md 的 4 條 PARA 判斷問題）解決的問題是「這篇筆記的內容，看起來該歸到哪裡」——這是在內容不確定歸屬時才需要的推理。ADR 不是這種情況：一篇決策紀錄一旦寫定，語意上就是「被動查閱、不需要主動維護」的參考資料，命中 CLAUDE.md 判斷問題 3，目的資料夾對所有 ADR 都是固定的 30_Resources，不會因為內容不同而變成 10_Projects 或 20_Areas。硬是先繞進 00_Inbox 再讓 /refine-inbox 判斷一次，只是在重新確認一個早就已知的答案。所以 /new-adr 直接跳過 00_Inbox，一步寫入 vault/30_Resources/。

status 為什麼固定是 evergreen，不是動態判斷

status 受控詞彙（seed/growing/evergreen）原本描述的是內容成熟度：草稿類筆記從 seed 起步，內容補齊、觀點成形之後才慢慢長成 evergreen，/refine-inbox 因此需要依內容判斷該給哪個值。但 ADR 記錄的是「某個時間點已經拍板的決策」——它在被建立的那一刻，內容就是完整、成熟的最終狀態，不會有「這個決策還在生長」的中間態；即使決策後來被推翻，正確的做法也是新建一篇 ADR 取代它（這是這次明訂的 Non-Goal，留給後續 Day 處理狀態轉換），而不是把舊的那篇改回 growing。所以 /new-adr 產生的筆記，status 一律固定寫 evergreen，不留給 Agent 判斷。

缺資訊時標「待補充」，不是想辦法補完

/new-adr 產生的正文固定三個 H2 區塊：## 背景、## 決策、## 後果。但這三段內容的原料是對話上下文，不是使用者額外填的結構化表單，一定會遇到「後果聊得不夠、只討論到方案本身」這種情況。這裡刻意訂了一條硬規則：資訊不足的區塊標註「待補充」，不可以用聽起來合理但沒有根據的內容去填滿它。

理由很直接：ADR 的價值就在於忠實記錄「當時到底是怎麼想的」，如果 Agent 為了讓文件看起來完整就自己編一段沒討論過的「後果」，未來的人看到這篇筆記會誤以為那是真的討論過、判斷過的結論，反而比留白更危險。更極端的情況——完全沒有任何決策脈絡可用——/new-adr 直接中止，回報需要使用者先說明決策內容，不產生一篇看起來像正式紀錄、實際上是空殼的 ADR。

自動織入雙向連結：沿用，不重新設計

/new-adr 產生的筆記一樣有 tags 欄位，一樣可能跟既有筆記共享 tag，沒有理由讓它繞過 Day16 已經驗證過的自動織入邏輯。所以這一步是原封不動地引用 /refine-inbox 步驟 6 的規則：依共享 tag 找候選相關筆記、雙向補正文 ## Related 區塊的 Wikilink、idempotent、不覆寫既有內容。這個邏輯的「定義」仍然歸屬 refine-inbox-workflow capability，/new-adr 只是在自己的步驟裡執行同一套規則——不修改 refine-inbox-workflow 的 spec，也不透過呼叫 /refine-inbox 來間接完成，因為 /new-adr 建立的筆記從一開始就不經過 00_Inbox，不符合 /refine-inbox 的前提。

實際跑一次：選用 Cobra 作為 CLI 框架

demo repo 裡已經有三篇跟 Cobra 相關的筆記：20_Areas/Cobra CLI 框架.md（tags: ["golang", "cli"]）、30_Resources/Cobra flag 綁定筆記...md（tags: ["golang", "cli"]）、30_Resources/Cobra 子指令樹筆記...md（tags: ["cli"]）。在對話裡討論完「brain-cli 要不要用 Cobra」這個決策——背景是子指令數量會持續增加、手刻 flag 套件遲早要重構；決策是採用 spf13/cobra；後果是子指令擴充成本穩定但多一個外部依賴——呼叫 /new-adr 選用 Cobra 作為 CLI 框架：

1. 整理三段式正文：背景／決策／後果都對應到剛才對話中實際討論過的內容，沒有一段是編出來的。
2. Frontmatter：type: adr、status: evergreen、tags: ["golang", "cli"]、related/aliases 皆為空陣列。
3. brain scan 檢查衝突：vault/30_Resources/ 下沒有同名檔案，可以建立。
4. 寫入：直接建立於 vault/30_Resources/選用 Cobra 作為 CLI 框架.md，沒有經過 00_Inbox。
5. 自動織入雙向連結：跟三篇既有 Cobra 筆記都共享至少一個 tag（golang 或 cli），於是四篇筆記的 ## Related 區塊互相補上了 Wikilink。
6. brain health：執行前後都是「0 筆斷鏈」，新筆記與三篇既有筆記都不再孤立。

再驗證兩個邊界情況：只討論背景與決策、刻意不聊後果，呼叫 /new-adr 後，## 後果 區塊確實標註「待補充」，而不是生出一段沒討論過的內容；對一個完全沒在對話中出現過的決策標題呼叫 /new-adr，指令直接中止，沒有任何筆記被建立。另外針對已經存在的 選用 Cobra 作為 CLI 框架.md 再呼叫一次 /new-adr，brain scan 偵測到同名衝突，中止建立，檔案內容（checksum）維持不變，沒有被覆寫。

銜接後續

Day17 補上的是 type: adr 這格從 Day04 就留好、卻一直沒人填的空位，而且刻意讓它跟 /refine-inbox 保持兩條獨立但共用底層邏輯的路徑：一個從「既有草稿」出發做分類搬移，一個從「剛討論完的對話」出發直接生成結構化紀錄，兩者在自動織入雙向連結、brain scan/brain health 前後驗證這些既有把關機制上完全一致。Day18 會把 Agent 呼叫 brain-cli 這件事本身（agent-tool-bridge）講清楚，Day19 則會把 Stage 3 累積下來的這些指令——/refine-inbox、/new-adr——串成一次完整的整合 demo。