Day22 結尾老實承認了一件事：demo vault 當時的連通結構不是太密（4 篇 Cobra 筆記彼此兩兩相連的完全圖）就是太小（2 節點的小群組），找不到一個「移除後真的會讓知識網格斷成幾塊」的節點，只好改用一張額外繪製、明確標示「不是 demo vault 真實資料」的鏈狀示意圖示範斷點邏輯。今天是 Stage 4（Day20-25）收尾的最後一天，要用真實資料把這個缺口補上。

Day21 讓 brain-cli 產出全庫連結的 Graphify JSON，Day22 在其上定義了樞紐（hub）與斷點（breakpoint）的判讀方法，Day23-24 打造了 /ask-vault 混合檢索問答。這四天的驗證都各自針對「當下那一刻的靜態圖」，從未示範過「vault 內容成長之後，圖結構、樞紐排名、斷點判讀會怎麼變化」。今天不寫任何新的 brain-cli 程式碼、不改任何既有 slash command 的定義檔，全部透過既有工作流程做一次「成長前後對比」的整合示範。

成長前快照：跟 Day21-24 的結論一致

重新對 demo vault 執行 brain graph --json，拿到跟 Day21-24 完全一致的 14 個節點、14 條邊：Cobra 群組（Cobra CLI 框架、Cobra flag 綁定筆記、Cobra 子指令樹筆記、選用 Cobra 作為 CLI 框架）彼此兩兩相連，樞紐分數並列最高（6 分）；Graphify 群組（Graphify 匯出格式規劃、Graphify 資料模型與 brain-cli 索引對應關係）互相連結，樞紐分數 2 分；其餘 8 篇孤立筆記樞紐分數 0。依 Day22 的斷點判讀方法重新檢查一次：Cobra 群組是完全圖，移除任何一篇都不會分裂，沒有斷點；Graphify 群組只有 2 節點，規模太小不構成有代表性的斷點——跟 Day22 的結論完全一致，這座 demo vault 目前確實找不到真實斷點。

順手核對一下這次示範要用到的三個 tag 目前的分布範圍（直接讀每篇筆記的 Frontmatter）：golang、cli 只出現在 Cobra 群組的筆記裡，graphify 只出現在 Graphify 群組的筆記裡，沒有任何孤立筆記帶有這三個 tag 之一——這代表接下來新增一篇同時帶有這三個 tag 的筆記，只會精準連到這兩個群組，不會意外命中孤立筆記。

讓筆記成長：一篇語意上真實橋接兩個群組的筆記

要示範真實斷點，得先讓圖裡出現一個真正的斷點。放棄「隨便找兩個孤立節點手動加一條連結」的做法——那種連結內容上沒有意義，讀者會覺得是硬湊出來的。改成新增一篇內容上本來就該同時提到兩個群組的筆記：brain graph 這個子指令，本身就是 Cobra 子指令樹掛載方式與 Graphify 資料模型輸出格式的真實交集——它是用 rootCmd.AddCommand() 掛進 Cobra 命令樹的一員，輸出的又是 Graphify 資料模型定義的 JSON 結構。這件事實本身站得住腳，不是為了製造斷點而硬湊的連結。

把這篇筆記（brain graph 子指令與 Cobra、Graphify 的交集）放進 vault/00_Inbox/，tags 同時帶 golang、cli（Cobra 群組慣用）與 graphify（Graphify 群組慣用），然後透過 /refine-inbox 既有的工作流程處理——不是在草稿裡手動寫死 ## Related 要連去哪幾篇筆記，而是讓 Day16 就已經存在的「共享 tag 自動織入雙向連結」機制自然觸發連結。這樣一次示範疊加驗證了兩層既有行為：圖形結構本身，以及自動織入機制在「跨群組」這個新場景下是否依然正確運作。

/refine-inbox 依 PARA 判斷規則命中第 2 條（沒有明確截止日期，但屬於需要長期主動維護、持續更新的技術對應關係——之後新增更多橫跨 Cobra 掛載方式與 Graphify 輸出格式的子指令時，都要回頭更新這篇筆記），把它搬進 20_Areas/，type 從 inbox-draft 更新為 atomic-note、status 更新為 growing。自動織入的結果核對起來完全符合預期：新筆記跟 4 篇 Cobra 群組筆記、2 篇 Graphify 群組筆記各自互相補上了 ## Related Wikilink，沒有意外連到任何原本孤立的筆記。搬移後執行 brain health，孤立筆記數維持 8 篇不變（新筆記本來就不是要連去孤立筆記）、斷鏈數 0——沒有製造任何非預期的斷鏈。

成長後快照：樞紐排名怎麼變

再次執行 brain graph --json：

{
  "nodeCount": 15,
  "edgeCount": 26
}

節點數從 14 增加到 15（新增的橋接筆記），邊數從 14 增加到 26（新筆記跟 6 篇既有筆記各自形成一組雙向邊，6 × 2 = 12 條新的有向邊）。重新計算樞紐分數：

交叉核對：成長後所有節點樞紐分數加總 = 12 + 8×4 + 4×2 = 12 + 32 + 8 = 52，正好等於 edgeCount（26）的兩倍，算法沒有算錯。新筆記樞紐分數 12 分，直接取代 Cobra 群組成為全庫最高樞紐——這完全符合直覺：它是目前唯一同時連向兩個群組全部 6 篇筆記的節點，Day22 定義的樞紐計算方法完全不需要任何修改，直接套用在成長後的新資料上就能得出正確結果。

這次真的判讀出一個真實斷點

依 Day22 的斷點判讀方法（暫時忽略方向、逐一嘗試移除節點看是否讓圖分裂）檢查新筆記這個節點：把新筆記（連同它相連的所有邊）從圖裡移除，剩下的圖會拆成兩個彼此不再相連的子圖——Cobra 群組（4 節點，彼此仍然兩兩相連，因為 Cobra 群組原本的 12 條邊完全沒有動到）跟 Graphify 群組（2 節點，彼此仍然相連，因為兩者之間原有的那條邊也沒有動到），這兩個群組之間再也沒有任何路徑可達。這正是斷點的定義——新增的橋接筆記，被正確判讀為一個真實斷點，而且完全基於 demo vault 的真實 brain graph --json 輸出，不需要另外繪製任何示意圖。

這裡也順便印證了 Day22 結尾講的那句話：「斷點通常出現在連接兩個群組的唯一橋樑上，而不是出現在互相高度冗餘連結的密集群組裡」——新筆記樞紐分數最高（12 分），同時也是斷點，這兩件事並不矛盾，它剛好是「重要且脆弱」的典型例子：一旦這篇筆記被誤刪或搬移，Cobra 群組跟 Graphify 群組就會立刻失去唯一的連結。

整個過程中，成長前後兩次 brain graph --json 輸出的 JSON 欄位命名與結構完全相同（都是 {"nodes":[{"id","label"}],"edges":[{"source","target"}],"nodeCount","edgeCount"}），差異只在 nodes/edges/nodeCount/edgeCount 的實際內容與數量——brain-cli 沒有新增或修改任何指令、旗標或輸出欄位。

順手驗證 /ask-vault 也能自然反映新的圖資料

既然新筆記已經進了 vault，順手重跑一次 /ask-vault，問一個涉及新筆記內容的問題：「brain graph 子指令跟 Cobra、Graphify 有什麼關係？」

第一階段結構檢索：抽出關鍵字「brain graph」「Cobra」「Graphify」，比對全庫筆記標題與 tags，命中 7 篇候選（新筆記本身，加上 4 篇 Cobra 筆記、2 篇 Graphify 筆記）——超過 5 篇的合理範圍，依關鍵字命中次數排序限縮：新筆記標題同時命中三個關鍵字排第一，其餘筆記各命中一個關鍵字並列，取排序在前的 5 篇（新筆記、Cobra CLI 框架、選用 Cobra 作為 CLI 框架、Graphify 匯出格式規劃、Graphify 資料模型與 brain-cli 索引對應關係）進入第二階段，並記錄「本次已限縮候選範圍，限縮前候選共 7 篇」。

第二階段讀完這 5 篇候選筆記正文後的回答：

brain graph 這個子指令是用 Cobra 建立的子指令樹的一員，透過 rootCmd.AddCommand() 掛進既有的 Cobra 命令樹（依據：《brain graph 子指令與 Cobra、Graphify 的交集》）。Cobra 本身是 Go 生態中最廣泛採用的 CLI 框架，提供子指令樹、flag 解析與自動產生說明文件的能力，是 brain-cli 在骨架階段就決定採用的框架（依據：《Cobra CLI 框架》《選用 Cobra 作為 CLI 框架》）。而 brain graph --json 輸出的內容完全遵循 Graphify 的資料模型定義——節點與邊的欄位草案在規劃階段就已經定案（依據：《brain graph 子指令與 Cobra、Graphify 的交集》《Graphify 匯出格式規劃》），與 brain-cli 全庫索引邏輯的資料模型對應關係一致（依據：《Graphify 資料模型與 brain-cli 索引對應關係》）。候選筆記未提及 brain graph 子指令未來是否會新增更多旗標或輸出欄位，這部分無法回答。

這次沒有觸發圖鄰居擴散（標題直接命中關鍵字），檢索邏輯完全沿用 Day23-24 已經定案的行為，沒有修改 .claude/commands/ask-vault.md 任何一行——/ask-vault 的結構檢索、候選篩選自然就把新筆記納進來了，不需要任何額外調整。

落地一則新 Requirement

把這次示範驗證到的場景，落地成 graphify-integration capability 的一則新 Requirement：vault 成長（新增筆記與跨群組連結）後，既有的樞紐分數計算與斷點判讀方法 SHALL 能正確反映新的節點/邊資料，且完全不需要 brain-cli 新增或修改任何指令、旗標或輸出欄位。今天實際驗證到的三個 Scenario——樞紐分數正確反映新增邊、真實資料中判讀出此前不存在的斷點、成長前後 JSON 契約不變——都跟今天實際做出來的結果一致，沒有需要調整驗收標準的落差。

Stage 4 收尾

Stage 4（Day20-25）從 Day20 定義 Graphify 的資料模型開始，Day21 讓 brain-cli 真的把全庫連結匯出成 JSON，Day22 在這份 JSON 上定義了樞紐跟斷點的判讀方法，Day23-24 打造了 /ask-vault 混合檢索問答，今天把這幾天累積的能力串成一個連貫的「成長觀察」流程：vault 每長出一篇新筆記、多織入幾條連結，樞紐排名會怎麼變、會不會冒出新的斷點、/ask-vault 能不能自然接住這些變化——今天用真實 demo 資料，第一次完整地把這整條觀察鏈走了一遍，也順手補上了 Day22 當時只能靠示意圖說明的缺口。

👉 明天 Day26，系列要從「知識圖譜」轉向 Stage 5：工程實戰、CI/CD 與總結。第一站是把 Bug 排查日誌轉成個人資產——我們明天見！