Day17 的 /new-adr 記錄一次決策，Day26 的 /new-postmortem 記錄一次事故，兩者都是「事件觸發」——有討論才有筆記。累積了兩週下來，obsidian-agent-brain 的 30_Resources 底下已經躺了十幾篇筆記，但沒有人會主動回頭把「這一週到底做了什麼」串起來看。想知道答案，唯一的辦法是自己去翻 git log。

obsidian-agent-brain 是一個真實有版本控制的專案，這件事在前 26 天一直沒被特別提起，但今天要用上：vault/ 底下的筆記異動、跟 brain-cli 程式碼與 .claude/commands/ 的異動，全部落在同一份 git 提交歷史裡。每次 /refine-inbox 落地一篇筆記，或每次幫 brain-cli 加一個子指令，理論上都會產生一次 commit。這代表「這一週知識庫發生了什麼」跟「這一週工具開發做了什麼」這兩個問題的答案，其實已經完整存在，不需要另外設計一套異動記錄機制——不用在 vault 裡維護一份手寫日誌，也不用在 brain-cli 裡新增一個記錄事件的子指令。今天的 /weekly-report 要做的事情很純粹：把 git log 查出來的東西，加上呼叫當下的 vault 健康度快照，組成一篇可以直接查閱的週報。

用檔案路徑分類，不要求 commit message 遵守新規則

git log 拿到一批提交之後，第一個問題是怎麼分成「知識庫異動」跟「工具開發異動」兩類。考慮過的做法是要求以後 commit message 都要加上 [vault]/[cli] 這種前綴，讓分類變成字串比對——但這個系列從 Day15 到 Day26 的所有 commit 都沒有這個慣例，回溯不到，而且這種規則本質上是「靠人記得遵守」，遲早會漏。

最後選了檔案路徑前綴：一次提交異動的檔案只要有任何一個落在 vault/ 底下，就算進「知識庫異動」；只要有任何一個不在 vault/ 底下，就算進「工具開發異動」。這個依據不需要開發者額外配合，git 已經記錄了每次提交異動哪些檔案。代價是一個提交可能同時觸及兩邊——比如同一次 commit 裡新增了 .claude/commands/new-postmortem.md，又順手補了幾篇示範筆記——這種情況不強制互斥，兩份清單都列出來，比起武斷歸到其中一類更準確地反映實際發生的事。

「完全沒異動」才中止，「某一類是空的」不中止

/new-postmortem 的中止邏輯判斷的是「對話脈絡夠不夠」，/weekly-report 面對的是不同的問題：「這段時間 repo 是否有任何活動」。兩種空的情況要分開處理：

• 區間內完全沒有任何 commit → 中止，回報「本週無異動，不產生週報」，不建立空殼筆記。
• 區間內有 commit，但只命中其中一類 → 不中止，該區塊標「本週無異動」，其餘照常產出。

只有程式碼異動、沒有筆記異動的一週很常見，反過來也是；如果因為某一類是空的就整篇中止，週報會變得幾乎每週都無法產生。只有在「這週 repo 完全沒有任何活動」的情況下，週報才真的沒有存在的意義。

status 固定 evergreen，跟 postmortem 的動態判斷不一樣

/new-postmortem 的 status 依排查完整度動態判斷，因為根本原因或修復方式當下可能還沒定案。/weekly-report 沒有這個中間態：它彙整的是「已經發生、已經是既定事實」的 git 歷史，跟「呼叫當下」的健康度快照，兩者在生成的那一刻就是完整、不會再變動的資料——不會有「這週的 commit 之後又多了幾個」這種情況需要回頭修改同一篇週報。因此比照 /new-adr 固定寫死 evergreen，不需要引入「待確認」這種中間態。

唯一例外是 ## 下週待辦 區塊，這是四個區塊裡唯一需要參考對話脈絡的部分——如果呼叫指令前剛好在討論下一步規劃，就填進去；沒討論過就標「待補充」，不虛構內容。但這個標註刻意不影響 status 判斷，理由跟 Day26 「預防與經驗」標「待補充」不影響事故收尾判斷一樣：其餘三個區塊的資料本來就客觀存在，足以構成一篇有價值的週報，不該因為下週規劃還沒聊到就整篇打回「未完成」。

建立位置：以「日期區間」而非「時間戳」判斷同名衝突

/new-adr、/new-postmortem 都是直接落地 vault/30_Resources/，週報也一樣，因為記錄的是「某個已結束區間」的總結，寫定之後主要用途是回頭查閱某一週做了什麼，符合 PARA 判斷問題 3（被動查閱的參考資料）。

但衝突判斷的依據不同。ADR、postmortem 用「使用者提供的標題」判斷同名衝突；週報沒有使用者輸入的標題，它的「標題」本質上就是日期區間本身（週報 <起始日期>~<結束日期>）。如果同一個區間已經產生過週報，代表使用者很可能是想更新既有週報，而不是自覺地建立第二篇重複記錄，所以中止並回報既有檔案路徑，不自動覆寫，交由使用者自行決定要編輯既有筆記還是換個區間重新呼叫。

實際跑四種情境

在 obsidian-agent-brain repo 上驗證：

1. 不帶參數（預設過去 7 天，2026-08-16~2026-08-22）：這段區間內有 19 次提交，5 次觸及 vault/，17 次觸及非 vault/ 路徑（含 3 次橫跨兩類）。週報正確列出兩份清單，## 知識庫健康度快照 記錄的孤立筆記數（9）、斷鏈數（0），跟呼叫當下 brain health --json 的結果一致。這次對話裡也討論過 Day27 之後要接 Day28 ci-cd-pipeline 的規劃，## 下週待辦 對應填入，不是「待補充」。
2. 明確指定區間（2026-08-18~2026-08-19）：只涵蓋這兩天的 8 次提交（2 次知識庫異動、8 次工具開發異動，其中 2 次橫跨兩類），確認週報不多不少只涵蓋區間內的提交。這次沒有討論下週規劃，## 下週待辦 正確標「待補充」，status 依然是 evergreen。
3. 只有工具開發異動的區間（2026-08-21~2026-08-21）：這天只有一次改 .claude/commands/ask-vault.md 的提交，## 本週知識庫異動 標「本週無異動」，週報照常產出，沒有被錯誤中止。
4. 確定沒有任何提交的區間（2020-01-01~2020-01-07，早於專案 git 歷史起點）：git log 回傳空結果，指令中止，回報本週無異動，沒有建立任何筆記。

三篇實際產出的週報都共享 weekly-report tag，沿用 Day16 的自動織入邏輯後互相在 ## Related 補上了 Wikilink；針對第一種情境的日期區間再呼叫一次，brain scan 偵測到 週報 2026-08-16~2026-08-22.md 已存在，中止建立，沒有覆寫既有內容。建立後的 brain health 顯示孤立筆記數維持在 9（三篇週報彼此連結，沒有變成孤立筆記），斷鏈數維持 0，沒有新增任何斷鏈。

銜接後續

/weekly-report 證明了「回顧」不一定要新建一套記錄機制——只要活動本身已經被版本控制記錄下來，缺的只是一個固定的彙整動作。Day27 目前還是手動呼叫，## 下週待辦 也還是依賴呼叫當下的對話脈絡才能填滿。Day28 進入 ci-cd-pipeline，會評估怎麼讓 /weekly-report 從「手動呼叫」進一步變成排程自動觸發——但排程觸發的下週待辦沒有對話脈絡可以參考，這正是留給下一天要解決的問題。