RambleWiki

架構與流程

Properties1
tagsdragonshoard架構史, 工作模式

閱讀時間約 102 分鐘

DragonsHoard 建設歷程－架構與流程

← 建設歷程總覽

範圍：資料夾／schema 配置、raw 唯讀機制的演變、混亂層誕生、專案歸檔流程、獨立子系統的落地定案（例如 log.md 歸檔）。不收：規則觸發機制對錯的檢討（見 觸發機制演變）、規則品質判準（見 規則品質與判準）、跟 AI 協作的溝通風格（見 協作與元規則）。

零、2026-07-29：起點——把 DragonsHoard 推上 GitHub

最初目的：DragonsHoard 建立之初的第一個基礎設施動作，先於本頁「一」開始記錄的所有架構決策——這份建設歷程本身能被完整追溯，前提就是這裡的 git repo 先存在。原本以獨立頁面 wiki/projects/active/github-repo-setup.md 記錄，2026-09-01 併入本頁當始祖記錄。

怎麼做：可見性選 private（raw/evergreen/self 有個人成長／健康／心理素材，不適合公開）；建立方式先裝 GitHub CLI（gh），全程在終端機用指令建立 repo、設 remote、push，不透過網頁介面手動操作。

最後變成什麼樣：安裝 gh CLI（2.96.0，winget）→ gh auth login（帳號 troublord，HTTPS，web browser 驗證）→ gh repo create DragonsHoard --private --source=. --remote=origin → push 現有 commit（master → origin/master）。Repo 建立於 https://github.com/troublord/DragonsHoard（private），確認畫面：

一、起點：待辦功能該不該放進 DragonsHoard

使用者提出想比照 Treasury-Vault 的 00-Capture 弄一個待辦功能。討論後否決：

  • 待辦的本質是「當下有效、做完即棄」，跟 DragonsHoard 整套設計「內容隨時間累積、越舊越有價值」的時間性正好相反
  • 使用者真正在意的是「一打開電腦不知道要幹嘛」——這是跨全生活領域的狀態快照需求，DragonsHoard 範圍鎖定知識/創作，天生不是能承接「生活全局」的容器
  • 結論：待辦留在 Treasury-Vault，但建議把 00-Capture「什麼都要先分類」的外殼拿掉，只留待辦這條路徑，其餘想法改丟根目錄的 白板.md

二、Treasury-Vault 02-Areas 是否適合搬進來

讀過 Treasury-Vault 的 生活｜個人定位.md 後否決，但理由跟待辦不同：

  • 待辦是「時效性不合」；02-Areas 是「編輯權/作者身份不合」——這類文件是使用者自己第一人稱持續原地改寫的人生敘事，不是外部素材、也不是等著被消化的原始資料
  • 當時的 DragonsHoard 三分法（raw 唯讀 / wiki AI 全權維護 / workspace 會畢業變唯讀）找不到「使用者永久持有編輯權、不追求畢業」這第三種狀態的位置

三、轉折點：使用者指出 AI 一路把自己的創作當例外

使用者直接反饋：「這個 DragonsHoard 自從建立起，AI 好像一直往『非創作、外部素材為主』的方向在跟我討論」——指出 CLAUDE.md 原文的 raw/evergreen/topics/（興趣主題深挖）從未限定只能是外部文章，咖啡、健身、攝影、音樂、旅遊、閱讀、遊戲、穿搭、髮型、籃球、寫作等任何興趣主題，使用者自己的理解與創作本來就該跟外部素材平起平坐，是 AI 自己讀太窄、不是規則本來就這樣寫。

共識：raw 的「原始素材」不分來源，使用者自己的創作/理解跟外部來源地位相同，都走同一條 ingest 管線。

四、重新協商 raw / wiki / workspace 的過程

raw 唯讀定義的重新檢視

  • raw 的唯讀從一開始就不是「只服務外部素材」——raw/projects/<project-name>/ 原本就註明「含 workspace 畢業前的存查版」，唯讀真正保護的是「不可竄改的歷史記錄」，不是「只能放外人寫的東西」
  • 使用者一度提出「不管來源是誰，都先進 raw」，AI 反駁：Query 流程本身就是繞過 raw 直接寫 wiki 的現成反例，統一規則的話要一併處理 Query（這點討論中明確擱置，留到後面）

方案比較：重新定義 raw vs. 另開「輸入層」

比較兩個方向：(A) raw 擴大定義，AI 全權執筆，使用者只負責回報；(B) 另開一層跟 raw 同等地位、使用者親自持續動手寫的空間。核心分歧是「誰執筆」。使用者選 B，並澄清方案 B 的真正用途：不是要保留像個人定位那種永久親手打磨的敘事文件，而是「我是很愛整理、很愛理解的人，想讓自己整理進來的資訊有更多被找到、被引用、被利用的機會，這套 wiki 裡有別人的也有我的創作與理解」。

「輸入層」的提出與拿掉

  • 一度定案：新增跟 raw 同等地位的「輸入層」，使用者持續編輯，不直接觸發 ingest，達到某個時間點時拍快照存進 raw（帶日期，可多次），才觸發 ingest——維持 ingest 單一觸發點在 raw，避免兩套觸發規則
  • 後續發現：使用者提出「一旦歸檔該文件就該從輸入層消失」，跟「唯一使用者，沒有需要保護的對象」「git 已提供版本歷史」兩個論點疊加後，發現直接編輯 wiki 本身已經沒有實質風險
  • 最終拿掉輸入層：直接編輯 wiki + frontmatter 標記 status: draft + Lint 事後校對，已經完整取代輸入層原本要解決的問題，回到 raw+wiki 兩層

驗證案例：文章/第三篇 - 標題未定.md 當時已經在 wiki/ 裡卻明顯還沒定案（標題都還沒定，index.md 卻寫「定稿待校稿」），直接證明舊規則（wiki 使用者不可手改）跟真實使用情境已經脫節。

交叉引用 vs. index/log 的區分

  • 交叉引用：wiki 之所以是 wiki 的成立前提，缺了就只是分類整齊的檔案庫，硬性要求
  • index.md：速度層面的軟性要求，沒跟上是「找得到但找得慢」，不是壞掉
  • log.md：稽核追溯的核心功能已被 git commit history 取代，不再要求嚴格即時更新

Lint 雙觸發機制

  • 保留「使用者不定期要求」路徑
  • 新增「每次開始處理 DragonsHoard 相關工作時，自動用 git diff <上次檢查點 commit> HEAD -- wiki/ 掃描異動」，檢查點 commit SHA 記錄在 log.md 的 lint 紀錄裡
  • 否決「背景默默定期跑」（需要額外排程基礎設施，對個人 wiki 沒必要——沒人使用時 drift 不影響任何事）

五、最終定案與執行結果

拿掉 workspace/，回到 raw + wiki 兩層：

  • raw 明確涵蓋使用者自己的創作/理解，跟外部來源同等地位
  • wiki 開放使用者直接編輯；交叉引用完整性硬性要求，index.md/log.md 軟性要求
  • 保留「創作本體逐字保留 vs. 狀態類內容可整理」的區分，只是觸發點從「畢業」改成日常 ingest/直接編輯
  • Frontmatter status 新增 draft
  • 白板從 workspace/evergreen/白板.md 搬到 DragonsHoard 根目錄 白板.md，定位為不屬於 raw 或 wiki 的常駐例外——使用者與 AI 之間的對話／發想橋梁，這是使用者在計畫審核階段主動修正的一點（原提案是搬進 wiki/evergreen/，被退回）
  • wiki/log.md 新增 infra 類型紀錄架構本身的變更

實際改動的檔案：CLAUDE.md 全面改寫、白板.md 搬到根目錄、workspace/ 資料夾整個刪除、wiki/log.md 追加 infra 紀錄。

七、2026-07-30：獨立成常青主題 + 白板工作模式定案

背景：使用者對第三篇文章是否要重寫感到猶豫（懷疑是衝動），要求先把白板待辦整理成 checklist 再一起討論優先順序。討論中使用者提出：鐵人賽期間跟 Hoard 有關的操作都值得記錄，但這份記錄「不限於鐵人賽，它屬於 Hoard 建設」——點出上面「六」的歸屬決定其實不成立。

推翻的決定：上方「六」記錄的「歸屬：iThome 專案」被推翻。理由：Hoard 自身的架構/工作模式演變，不該因為 iThome 專案未來歸檔而被連帶歸檔或視為只服務該系列——這份記錄的價值獨立於任何專案存在。

新決定：

  1. 本檔案從 wiki/projects/active/iThome鐵人賽2026/ 搬到 wiki/evergreen/topics/DragonsHoard建設歷程/，逐字稿一併搬到 raw/evergreen/topics/DragonsHoard建設歷程/，脫離 iThome 專案生命週期
  2. 定義「值不值得記」的門檻（避免這個常青主題被日常瑣事灌水）：(a) 改變 Hoard 結構/規則本身、(b) 確立或修改以後會重複套用的工作模式、(c) 反之單次操作/單篇進度/常規維護不記——核心判準是「以後會不會被引用套用，還是做完就沒了」。細節寫入 CLAUDE.md「Hoard 建設歷程」一節
  3. 白板處理流程定案：使用者要求處理白板時，AI 先整理成 - [ ] checklist，再一起討論優先順序，不跳過討論直接執行——使用者確認喜歡這個協作模式，寫入 CLAUDE.md「白板」一節，成為持續適用的規則（不只是這次的個案）

與第三篇重寫的關係：討論到最後，第三篇「要不要重寫」的疑慮被拆解為一個具體、可驗證的問題——Lint 段落清單漏了兩條（見決策歷程「五、第三篇」），判斷是小修不是重寫，不需要整篇動工。

八、2026-07-30：raw 唯讀技術性強制 + 混亂層概念定案

起點：毓文校稿第三篇時，因為 raw/ 跟 wiki/ 資料夾結構刻意對稱，順手改錯層——直接編輯了 raw/ 那份（應唯讀），而不是 wiki/ 那份。改動被 git status 抓到才發現，已同步進 wiki、raw 用 git checkout 復原，過程無實質損失，但暴露出「raw 唯讀」目前只是 CLAUDE.md 裡的一句約定，沒有任何技術強制力——跟這系列一直在講的「Policy vs Enforcement」是同一個問題，這次在自己系統上真實發生。

討論的方案分級：(1) 純靠人記得——當場被否決，因為這次的規則本來就寫在 CLAUDE.md 裡、使用者也知道，還是改錯，證明記憶不可靠；(2) 檔案系統唯讀屬性（Windows attrib/IsReadOnly）——選定方案，成本低、能真的擋下寫入（含 AI 透過工具寫入），代價是新 ingest 的檔案不會自動繼承，需要另外設定；(3) git pre-commit hook 擋 raw/ 路徑——更硬，但設定複雜，本次沒做，留作未來可能的加強。

執行：raw/ 底下現有檔案全部設為唯讀（Windows 檔案屬性），實測確認寫入會被系統擋下（Permission denied），git 操作（checkout 等）不受影響。

衍生問題與「混亂層」概念的誕生：設唯讀時發現 raw/evergreen/topics/DragonsHoard建設歷程/想法.md（append-only 的想法捕捉檔）沒辦法唯讀，因為它本質上是持續被寫入、還沒定案的內容，跟 raw 的「凍結歷史記錄」性質衝突。討論過三個安置方案：(a) 留在 raw 裡單獨排除唯讀——技術上可行但概念擰巴，一個「這裡全部凍結」的資料夾裡留一個「這份永遠不凍結」的例外；(b) 搬進 wiki——被否決，因為 wiki 的定位是「已整理、可信任的最終內容」，塞一份格式不拘、多數內容還沒過篩選門檻的隨手記，會混淆 wiki 的定位；(c) 認知到 raw（原料，唯讀凍結）跟 wiki（成品，定案內容）中間，其實一直存在一個「混亂層」——常駐、持續寫入、不用先篩選、不受兩層任一邊規則約束——白板.md 早就是這層的第一個成員，只是沒被正式命名。

最終定案：把 想法.md 從 raw/evergreen/topics/DragonsHoard建設歷程/ 搬到 DragonsHoard 根目錄，跟 白板.md 並列成為「混亂層」正式概念下的兩個成員——白板通用、想法.md 範圍限定在 Hoard 建構本身，各自在檔案開頭標示清楚範圍。raw/ 從此不需要留任何唯讀例外。細節寫入 CLAUDE.md「混亂層（根目錄例外）」一節，取代原本的「白板（根目錄例外）」節。

十、2026-07-30：混亂層收整成 chaos/ 資料夾 + 新增「單篇任務型捕捉檔」規則

起點：規劃第四篇文章要寫什麼的過程中，討論拉得很長、還沒定案，需要一個地方記錄「這篇文章打算寫什麼」的中間過程。舊模式是把這類「寫前筆記」寫在 raw/ 對應文章檔案裡（例如第三篇之前都是這樣），但第八節記錄的 raw/ 技術性唯讀化之後，這條路已經走不通——連使用者自己都無法再寫入 raw/ 底下的檔案。

討論：這個缺口本質上跟第八節「想法.md 需要一個不受 raw/wiki 規則約束的家」是同一個模式，混亂層本來就是為了裝這種「持續被寫、還沒定案」的內容而存在。順勢決定：

  1. 把混亂層從根目錄兩個散落檔案（白板.md、想法.md）收整成一個資料夾 chaos/——英文命名，使用者在 想法.md 自己的隨手記裡其實已經提過「raw, chaos」這個構想，這次正式採用
  2. 新增第三種混亂層檔案類型「單篇任務型捕捉檔」，跟白板／想法這種永續收集區的差異：綁定單一篇文章或任務，不是常駐；內容整理進對應 wiki 頁面（例如 決策歷程.md）之後，直接刪除整份檔案，不像白板/想法那樣保留本體——因為這類文件的任務有明確終點，wiki 端已經有永久的家之後，混亂層那份只是重複的草稿
  3. 第一個實例：chaos/第四篇戰略規劃.md，記錄第四篇「要寫什麼」的完整定案清單

判斷這件事夠格記進本頁的理由：改變了 Hoard 本身的資料夾結構（新增 chaos/ 資料夾）與規則（單篇任務型捕捉檔的歸檔方式），且是一種以後每篇文章規劃階段都會重複套用的模式，符合門檻 (1)(2)。

最終定案：白板.md、想法.md 用 git mv 搬進 chaos/；CLAUDE.md 核心架構樹狀圖、「混亂層」節、「Hoard 建設歷程」節的路徑描述同步更新；wiki/log.md 追加一筆 infra 紀錄。

十一、2026-07-31：修正「想法.md」範圍定義——從 Hoard 限定改成跨領域

起點：上一節（十）剛把混亂層收整成 chaos/ 資料夾定案，使用者隨即指出 想法.md 的範圍描述「只收 Hoard 建構本身相關的想法」跟他原本的想像不符——他心裡想的其實是舊 vault（Treasury-Vault）03-Vault/Ideas/想法.md 那套模式：一個跨領域的想法擱置區，收集「覺得以後會用到，但現在不知道有什麼用」的念頭（伴侶關係反思、俄國詩人的感受、技術構想都混在一起），分類軸線是成熟度（還不到能用的階段），不是主題（限定某個領域）。

討論：檢視 Treasury-Vault 實際的 Ideas/ 資料夾（17 篇跨領域紀錄，索引檔＋獨立衛星檔兩層結構）後，發現它會亂的原因：每則想法不分大小都自動開一個獨立檔案，連一行就講完的念頭也生一個檔案，資料夾難以掃視，且沒有清楚的畢業去向。確認方向：兩層結構之後有需要再說，這次先只做「單一檔案、預設一行摘要、不自動開檔案」。同時釐清 白板.md 跟 想法.md 的分界，不該是「主題範圍」（通用 vs Hoard 限定，這是上一輪寫錯的方向），該是「性質」：白板是正在進行的對話／發想，想法是先擱置、之後才可能用到的種子——兩者現在都不限主題。

最終定案：chaos/想法.md 開頭範圍宣告改寫為跨領域擱置區，既有 Hoard 相關筆記本體不動（標題順帶從「想法（Hoard 建設過程隨手記）」簡化為「想法」，去除跟新範圍矛盾的字樣）；CLAUDE.md「混亂層」節（想法.md／白板.md 兩條 bullet、核心架構樹狀圖裡的 想法.md 註解）與「Hoard 建設歷程」節「想法捕捉入口」段落同步改寫，分界描述統一成「性質不是主題」。

十二、2026-07-31：raw 唯讀從檔案系統技術強制改回文件約定 + git diff 事後偵測

起點：討論 raw/assets/ 的定位（附件該不該先落在這個暫存資料夾，還是直接存進最終的主題/專案資料夾）時，連帶重新檢視第八節建立的 raw 唯讀技術強制機制。使用者質疑：既然新 ingest 進來的檔案本來就不會自動繼承唯讀屬性（第八節已記錄這個代價），這個屬性的保護力打從一開始就不完整，那設定唯讀這件事是不是已經沒有意義。

討論：

  1. 實測發現保護力比預期更破：Windows 唯讀屬性能穩定擋下編輯（PowerShell Set-Content、Bash 直接覆寫都被拒絕），但擋不住刪除——PowerShell Remove-Item 不加 -Force 會被擋，但 Git Bash 的 rm（AI 預設使用的殼層）不需要任何強制旗標就能直接刪掉唯讀檔案。也就是說現有機制對「編輯」有效、對「刪除」形同虛設，且哪個工具能繞過完全不直觀
  2. 使用者一度提議乾脆完全拿掉唯讀、只靠「AI 與使用者留意」這種純文件約定守住 raw 不可編輯——這個方向被指出風險：第八節那次唯一真實發生過的意外，正是使用者自己校稿時手滑編輯到 raw（因為 raw/wiki 結構刻意對稱、路徑容易看錯），不是 AI 犯的錯；純文件約定對「人手滑」完全沒有攔阻力，等於重新踩進第八節已經驗證過會失敗的模式
  3. 轉向討論另一種技術性把關：既然 Lint 已經對 wiki/ 做 git diff <checkpoint> HEAD 掃描異動，同樣的手法可以套用在 raw/——git 用內容雜湊判斷檔案有沒有變動，不受任何檔案系統屬性或使用哪個殼層影響，比屬性可靠。用 git diff --name-status 分辨 M（既有內容被改動，異常）、A（新增，正常）、R（純搬移不動內容，正常，涵蓋 raw/assets/ 歸位到主題/專案資料夾這類操作）

最終定案：raw/ 底下所有檔案的 Windows 唯讀屬性全部解除，回到純文件約定「唯讀、不修改」；防護機制改成 .claude/skills/dragonshoard-commit/SKILL.md 在既有 wiki/ 掃描之外，新增 git diff --name-status <checkpoint> HEAD -- raw/ 檢查，抓到 M 就停下來跟使用者確認如何處理（例如 git checkout 復原），不自作主張改掉。這是事後偵測不是事前阻擋，但比會被 Bash rm 繞過的檔案屬性更可靠，且 git history 本來就能救回被誤改的內容——跟第五節「wiki 開放直接編輯，靠 git + Lint 把關」用的是同一套邏輯，只是這次套用到 raw。細節寫入 CLAUDE.md 核心架構樹狀圖、新增的 raw/assets/ 說明段落、「Lint」健檢項目清單。

十六、2026-08-12：專案歸檔流程細節定案

起點：使用者請 AI 綜合 CLAUDE.md、架構、對話記憶，整理出「知識庫建設哲學」獨立成頁（見知識庫建設哲學）後，接著要求針對「歸檔」這個既有規則做需求擷取——原本 CLAUDE.md「常青 vs 專案」節對歸檔只寫了「完成後把 raw／wiki 對應資料夾搬到 archive 下，更新 index/log，除非明講不重啟」三句話，實際操作會踩到的細節（誰觸發、連結怎麼處理、封存原因要不要分類、要不要另開 skill）都還沒定案。

討論：AI 用 AskUserQuestion 針對四個具體分歧點做需求擷取，而非自行假設：

  1. 觸發者：使用者選「AI 觀察到跡象可以主動提議」（不是只能使用者明講才動手，也不是 AI 自行判斷完成就執行）——跟系統本身「歸檔屬於有點不可逆的資料夾搬移動作，AI 可以主動提議但需使用者確認」的一貫謹慎原則一致。
  2. 連結修正：使用者選「要，歸檔時一併地毯式修正」——理由是先例已經證明這是真實需求：iThome鐵人賽2026-舊方向 封存時（見上方「五十／四十八」附近 log.md 對應紀錄），就發生過帶完整路徑的反向連結（wiki/index.md、建設歷程.md 等處）需要手動改指向新 archive 路徑的情況，這次正式把它寫成流程裡的必要步驟，不再是事後才發現要補的漏洞。
  3. 封存用語：使用者選「要區分用語」——「完成封存」跟「取代封存」語意不同，iThome鐵人賽2026-舊方向 屬於後者，之後回顧掃描 log.md 時能一眼分辨這批專案是做完的還是半路被換掉的。
  4. 獨立 skill：使用者選「不需要」——跟 CLAUDE.md「結構/系統擴充要節制、不主動建議新 skill 除非有具體痛點」的既有原則一致，歸檔頻率低、步驟不算多，用文件裡寫清楚的步驟手動走一次即可。

最終定案：CLAUDE.md「常青 vs 專案」節的歸檔敘述從三句話擴充成六步驟清單（觸發／搬移／連結修正／用語區分／更新 index-log／不重啟），並註明不設獨立 skill。細節寫入 CLAUDE.md 對應段落。

二十二、2026-08-20：（此則內容涉及未公開資訊，公開版隱藏）

二十七、2026-08-26：log.md 大小／時間雙門檻歸檔機制

最初目的：使用者發現 wiki/log.md 才 28 天就長到 110KB／122 筆，明顯過度肥大——單次 Read 這份檔案已經會撞到 token 上限（前 65 行就吃掉近 5 萬 token）。需要一套會持續生效的歸檔規則，而不是只做一次性清理。

怎麼做：討論中先排除「前三十天」這個字面切法——log.md 全部歷史都還在 28 天內，字面上等於整份都要搬走。改成設計一套持續運作的機制：大小門檻（30KB，讓單次 Read 舒服讀完）與時間門檻（45 天，防止活動量低時大小遲遲不觸發，純粹當保底）雙軌並行，任一超過即觸發，保留最近 10 筆、其餘搬進新檔 wiki/log-archive.md。規則放在哪一層：使用者一開始問能不能把門檻寫進 log.md 本體，判定不行——log.md 是純資料層，CLAUDE.md 才是每個 session 都會載入的規則層，寫進 log.md 不會被穩定執行，違反「規則有效性判準」（見「二十五」）的第一條；機械觸發點掛在 hoard-commit skill（跟既有 Lint 同一個攔截點），門檻數字寫進 CLAUDE.md「log.md 維護規則」。檢查與執行方式：使用者追問「檢查方式是全部讀過一遍還是只看大小」，確認整套機制刻意設計成不需要讀懂內容——觸發判斷只用 wc -c 比大小、grep -m1 抓最舊日期；真的觸發時也只用 grep -n 抓行號做機械切割，不會把 log.md 全文讀進對話 context，檢查成本不隨檔案變大而變貴。被掃到機率的確認：log-archive.md 沿用 log.md 現有的豁免待遇（不受交叉引用／index.md／孤兒頁面規則約束）——Lint 只 diff 增量、Query 本來就不讀 log.md，歸檔動作只在搬移當下的 commit 被 diff 到一次，之後不會被重複掃描。

最後變成什麼樣：CLAUDE.md 新增歸檔規則段落與架構樹狀圖條目，hoard-commit skill 新增步驟 5（檢查／歸檔）並重新編號後續步驟。同步執行首次歸檔：122 筆中較舊的 112 筆（2026-07-29～2026-08-24 大部分）搬進新建的 wiki/log-archive.md，log.md 只留最近 10 筆＋這次變更本身的紀錄。

二十九、2026-08-28：Hoard 開一個公開網站分支（RambleWiki）

最初目的：使用者想把 Hoard 的部分內容變成一個公開網站，記在 materials/ 時就標註「重要」——這是具體需求，不是隨手冒出的點子。限制條件：免費、DragonsHoard 這個 repo 本身要維持 private，且不想公開的內容（chaos/materials/raw、wiki 裡的個人心得等）不能外流。

怎麼做：先討論技術選型——GitHub Pages 免費方案要求整個 repo 公開（連原始檔案都曝光），否決；Cloudflare Pages + Access 可以做到資料夾層級權限（免費層 50 人），但使用者決定不做資料夾層級權限，改用「篩選子集」的路線，所以這塊先不用。最終選 Quartz（v5，obsidian template，吃 wikilink，免費）當產生器，Netlify 免費層當部署平台（可接私有 GitHub repo，只公開 build 出的靜態網頁，原始檔案不外流），並用 GitHub 的獨立分支 public-site 隔離要公開的內容——分支雖然共用 git history，但因為 GitHub repo 本身是 private，這不構成外流風險；之後要真正加入篩選過的 wiki 內容時，同步方式訂為 git checkout <path> 複製或 cherry-pick 特定 commit，不對這個分支做整支 git merge，避免私人資料夾被一併拉進去。Netlify 帳號用使用者的第二個帳號，跟既有的其他個人網站分開算免費額度。過程中撞到一個技術債：Quartz 5.0.0 upstream 的 @quartz-community/latex plugin 對 @myriaddreamin/rehype-typst 版本號釘死了不相容的 peer dependency，導致乾淨的 npm install／npm ci 直接失敗；解法是在 netlify.toml 設 NPM_FLAGS=--legacy-peer-deps（Netlify 官方支援、會傳給它內部自動執行的 npm install 步驟），本地端一併用 npm ci --legacy-peer-deps 驗證過全流程可過。

最後變成什麼樣：2026-08-28 完成第一階段——public-site 分支推上 GitHub，Netlify 站點命名 RambleWiki（ramblewiki.netlify.app），quartz.config.yaml 對應設定 baseUrl／pageTitle／locale（zh-TW）。實測通路成功：GitHub repo 確認仍是 private，Netlify production deploy 成功，網站可正常瀏覽（目前只是一頁測試佔位內容）。副作用：public-site 分支的 repo 根目錄多了一批 Quartz 專案檔案（package.json、quartz/、quartz.config.yaml、netlify.toml、content/），這些檔案只存在這個分支，不影響 master；public-site 目前仍完整包含 wiki/raw/chaos/materials 全部檔案（只是沒被 Quartz 的 content/ 資料夾處理，不會被公開），真正的內容篩選（要公開哪些常青主題）還沒做，留給後續維護追蹤。

三十、2026-08-27～29：素材庫（materials/）設計定案與 Telegram 同步實測

最初目的：起因是一段 ChatGPT 對話延伸出的觀察——chaos/ 已經有了，但「素材」（有火花但還沒變成決定、也還沒長成 wiki 頁面的碎片：自己冒出的念頭、有情緒重量的個人經歷片段、外部素材激起的反應）沒有專屬的收集方式，會持續積灰塵。核心需求是寫作時能「拉」出舊素材找靈感，不是 AI「推」提醒——AI 主動提醒被明確否決，理由是會打斷創作。

怎麼做：

  • 定位：不併入既有 raw/wiki/chaos 三層，獨立成第四層資料夾 materials/，正常進 git，但套用完全相反的治理原則——high recall, low precision：捕捉不篩選、允許矛盾共存、不去重、量大是目標不是問題、精準工作（搜尋/篩選/找關聯）留到「使用時」才做。素材可以不正確、不完整、不成熟，且不用被解決，不需要「清掉太舊素材」的機制。
  • 結構：一則素材一個檔案，檔名即內容濃縮版，資料夾列表本身就是掃描用的 index——不用 frontmatter、不用 tags、不用 index.md。捕捉完全不經過 AI，使用者直接寫檔案；AI 預設不主動讀、不主動整理，使用者主動問時才查。
  • 生命週期：被「拿起來做」時搬進 chaos/（沿用單篇任務型捕捉檔模式）；半途而廢搬回 materials/，不刪除，呼應「素材不用證明自己有用」。
  • 手機同步方案選型：目標是手機端零成本、不湊 Notes 替代品。依序排除 Obsidian Sync（付費）、iCloud Drive（同步範圍鎖定固定根目錄，materials/ 要嘛整個 Hoard 搬進 iCloud 冒 .git 損毀風險、要嘛用 symlink 多一層複雜度）、Google Drive for Desktop（2026-06-15 起關閉新增備份資料夾功能）、Syncthing（要求手機、PC 兩端同時在線才能互傳，使用者確認兩端都不會常駐執行）。最終選 Telegram Saved Messages（手機原生輸入，送出即存檔，不用另外申請 bot／裝其他 App）＋使用者帳號 API（Telethon，非 Bot API）在 PC 端讀取。捨棄 Bot API 的關鍵理由：getUpdates 是消費式佇列，一旦某台機器抓過並確認，其他機器永遠拿不到，且佇列有 24 小時保存期限；使用者帳號 API 讀的是聊天紀錄本體，唯讀不消費、無過期，多台機器可以各自安全地重複讀取、各自維護自己的 min_id checkpoint。代價是設定較重——需在 my.telegram.org 申請 api_id/api_hash，每台機器各自用手機驗證碼登入一次、各自存一份 session 檔案（等同帳號完整存取權，.gitignore 排除不進 git）。
  • 實測與修正（2026-08-29，桌機 KHUser）：申請好 api_id/api_hash 並完成登入後，實測發現並修正腳本 xcripts/telegram_materials_sync.py 兩個原始設計沒考慮到的問題：
    1. async with TelegramClient(...) as client: 語法本身在進入區塊時就會呼叫 client.start()（不帶參數），比後面手動呼叫的 client.start(phone=...) 更早觸發，導致登入永遠吃不到設定檔裡的手機號碼，卡在預設的互動輸入提示、在非互動式的執行管道（例如 Claude Code 的 ! 前綴指令）直接 EOF 失敗。改成手動 client = TelegramClient(...) 建立、await client.start(phone=...) 才連線、finally 手動 disconnect()。
    2. Telegram 相簿（一則文字＋多張圖片）在底層會拆成多則獨立訊息，共用同一個 grouped_id，說明文字只掛在其中一則、其餘訊息文字是空的。原始腳本只處理「一則訊息一個檔案」，導致一次分享被拆成好幾個各自獨立、其中沒標題的圖片只能用時間戳記命名的檔案，不符合「一次分享是一則素材」的預期。修正做法：依 grouped_id 緩衝分組，同一組只產生一則 .md 筆記（檔名沿用說明文字，跟純文字素材同一套取名邏輯）＋對應圖片檔案（<標題>-1.jpg、-2.jpg…），筆記內容是說明文字後接 Obsidian embed 語法（![[<標題>-1.jpg]]）連結圖片；單張圖片（無相簿）也統一走這套「一則 .md ＋一個圖片檔」模式，取代原本「圖片檔案本身用說明文字當檔名」的特例。
    • 同一次討論也確認：手機端離線輸入的訊息會排入本機佇列，恢復連線（Wi-Fi 或行動網路皆可）後自動送出，不需要額外機制；另一支沒有電信門號的手機只要用 QR code 登入同一個 Telegram 帳號，靠 Wi-Fi 就能當捕捉裝置，跟門號/SIM 卡無關。

最後變成什麼樣：桌機（KHUser）完整跑過純文字、單張圖片＋文字、多張圖片相簿＋文字三種情境，全部正確落地成預期的檔案結構；白板既有 14 則想法也已依素材定義搬進 materials/，資料夾現在有真實內容，不是空殼。同一次順手解決「要不要包成類似 hoard-pull 的呼叫方式」這個原本待辦：發現腳本只有第一次登入需要互動輸入手機驗證碼，session 檔案存好之後之後每次執行完全不需要互動，因此直接包成新 skill .claude/skills/hoard-materials-sync/SKILL.md（/hoard-materials-sync），取代手動開終端機打指令的流程；順便修正腳本中文輸出在非標準主控台編碼下的亂碼問題（sys.stdout.reconfigure(encoding="utf-8")）。尚未完成：筆電端各自登入與 session、回頭驗證 ChatGPT「創作動作清單」剩餘幾條情境（找相關素材、找關聯、找案例等提用行為）——這些留在待辦，不影響「素材庫核心捕捉路徑已跑通」的結論。設計討論全文原記在 chaos/素材庫設計.md，內容已被本節與 CLAUDE.md「素材庫」章節取代，該任務型捕捉檔已刪除。

三十一、2026-08-31：checkpoint 從各機獨立改為 git 共用，補上「刪除」被 per-machine 設計漏掉的洞

最初目的：第十三篇動筆過程中，順手把筆電端的 Telegram 同步登入也設定完成（第一次動手見本文「三十」尚未完成事項）。筆電第一次執行同步，卻把桌機在「三十」測試階段就已經手動刪除的 5 個測試檔案重新抓了回來，暴露 per-machine checkpoint 設計沒考慮「刪除」這個動作——checkpoint 只決定「這台機器接下來從哪裡開始讀」，不代表內容還在不在；本地刪除檔案不會傳播到其他機器，只要 Telegram 訊息本身還在，任何 checkpoint 落後的機器都會重新讀到。

怎麼做：一開始考慮的修法是直接去 Telegram 刪掉訊息源頭，這樣能解決眼前這批測試訊息，但下次換一個新機器或某台機器 checkpoint 重置，同樣情境還是會重演，屬於治標不治本。使用者反問「多台電腦維護同一個 checkpoint 不就能解決」，重新檢視後確認這才是根治方法：checkpoint 若透過 git 共用，任何機器都不會再讀到「已經被共用 checkpoint 涵蓋」範圍內的訊息，不管本地內容有沒有被刪除，也就不需要動 Telegram 上的訊息。但共用 checkpoint 有一個必須守住的前提：checkpoint 的 commit 必須跟它涵蓋範圍內新增的 materials/ 檔案綁在同一個 commit，不能分開——只 commit checkpoint 不 commit 對應內容，會讓那些訊息之後在任何機器上都撈不回來，是比原本「重複同步」更嚴重的資料永久遺失。共用基準直接採用筆電當下的 min_id=17（比桌機上次記錄的 14 大，往這個方向推進不會漏內容），使用者確認不需要先查證桌機實際數字再對齊。

最後變成什麼樣：.gitignore 把 xcripts/telegram_checkpoint.json 移出忽略清單、改為追蹤檔案，並在旁邊註記共用規則；hoard-materials-sync skill 邊界一節新增提醒，checkpoint 要跟涵蓋範圍內的 materials/ 新增檔案同一個 commit 一起進去。筆電 materials/ 資料夾清掉 12 個測試垃圾檔案（123/Test/This is a test/And image test 系列/She don't like the plan 系列/測試同步），保留兩則真實內容（夜晚高雄速拍、圖片-20260831-064508，剛好也是第十三篇「示範」一節截圖的來源）。原本考慮的「刪 Telegram 訊息源頭」方案不再需要執行。桌機端下次 hoard-pull 拿到共用 checkpoint 後即完成兩機對齊，尚未實際驗證（留待桌機下次操作時確認）。

三十九、2026-09-02：新增梗圖庫（memes/）

最初目的：使用者感覺需要一個可重複使用的梗圖存放區，供文章配圖挑選。既有三層都不合——raw/assets/ 是單次暫存區（進 ingest 後搬走清空）、materials/ 是待撿去加工的想法碎片、wiki/ 要求交叉引用完整，梗圖是「用過還留著、不會被消化掉」的 stock asset，性質都不同。

怎麼做：確認範圍是通用、不限單一專案後，開新頂層資料夾 memes/，跟 chaos/、materials/、raw/、wiki/ 平行；結構比照 materials/——扁平資料夾、檔名即索引，不用 frontmatter／tags／index.md。使用者明確表示這次不需要定義捕捉流程（Telegram 同步、PC 端手動拖檔都可以，自己處理），也不需要自動化，AI 只要讓資料夾存在即可。

最後變成什麼樣：建立 memes/.gitkeep 占位；CLAUDE.md 新增「梗圖庫」一節與目錄樹條目；hoard-commit skill 兩處提及 chaos/、materials/ 的地方（commit staging 範圍、lint 排除說明）併入 memes/。捕捉機制留給使用者自行處理，尚無實際內容驗證。

四十二、2026-09-04：CRLF/LF 假性 M 反覆復發，拔掉根源（core.autocrlf vs .gitattributes 衝突）

最初目的：08-30 已經診斷過一次「wiki/raw 檔案顯示 M 但 git diff 是空的」問題（git hash-object 比對確認內容逐位元組相同，是 index stat 快取過期），當時修法是 git add --renormalize . 清一次快取＋新增 .gitattributes（* text=auto eol=lf）釘死換行政策。09-04 hoard-pull 前，同一個症狀又在三個完全不同的檔案上重演，代表 08-30 只解決了當下那批檔案，沒有拔掉會持續產生新一批假 M 的根源，這次要挖到底、避免變成每次 pull 前都要人工重新診斷一次的例行公事。

怎麼做：查證發現 core.autocrlf=true 是 system 層級設定（Git for Windows 安裝程式的預設值，不是使用者自己設的，git config --local／--global 都查無此設定），跟 .gitattributes 的 eol=lf 同時對「工作目錄該用什麼換行符」各自有主張——這正是 Git 官方文件記載的已知衝突模式：eol 屬性理論上會覆蓋 core.autocrlf 的 checkout 行為，但兩者疊在一起容易讓 index 的 stat 快取在每次 checkout/pull 後跟實際內容對不上，08-30 那次的 --renormalize 只是清掉當時已經跑掉的快取，沒有移除「兩層規則同時生效」這個持續存在的觸發源，所以之後任何一次 checkout 都有機會重新產生新的假 M。改用 repo-local git config 直接關掉 autocrlf（git config core.autocrlf false，只影響這個 repo，不動 system/global 設定），讓 .gitattributes 的 eol=lf 單獨作主，不再有兩套判斷互相打架。

最後變成什麼樣：毓文 PC 這台已設定 local core.autocrlf=false，並重新 git add --renormalize . 確認 git status 乾淨。KHUser 那台尚未設定——這是 per-repo 的 local git config，不會隨 git push／git pull 同步過去，需要使用者自己在那台電腦上手動跑同一行指令。截至本次記錄，兩機是否徹底不再復發尚未驗證，留待下次兩機互動（KHUser 端設定完、下次跨機 pull）時確認。

四十七、2026-09-06：五層機制模型精修、CLAUDE.md 收錄門檻正式化、八類協作內容分層判斷

最初目的：潤稿現有 CLAUDE.md 四原則文章時發現，四原則講的是「怎麼寫得好」，不是「知識庫的 CLAUDE.md 該有什麼」這個內容規格層，兩者性質不同。查證外部共識（Anthropic 官方＋社群）發現只到軟體專案語境的類別清單層級，沒有知識庫場景對應版本，判定值得補一篇。討論到一半發現問題本身問錯了：原本問「CLAUDE.md 該有什麼內容」是單一容器的篩選問題，正確問法是「知識庫的協作內容，該怎麼分配到 CLAUDE.md／Rules／Skills／Subagents／Hooks 五層機制？」。

怎麼做：先確認是五層機制、不是三層——前段共識研究只涵蓋到 Skill，沒提到 Subagent／Hook。Hook：DragonsHoard 有兩次真實評估紀錄（Lint 觸發機制、白板提醒機制），都判定不需要，理由具體且一致——Hook 的強項是「機械、不需語意判斷的保證觸發」，但知識庫規則大多需要 AI 自己判斷情境，跟 Hook 的強項不對盤；raw/ 唯讀保護是例外，該用檔案系統權限做，Hook 留作未來可能加強（見「十六」）。Subagent：完全沒有評估紀錄，跟 Hook 不同——不是巧合沒遇到，是整個 wiki 架構（90KB 閱讀預算、index.md 摘要導航、策展優先於檢索）刻意設計成不需要大量委派讀取，Subagent 原本該解決的問題被架構本身消滅了；唯一保留的邊際情境是一次性超大量遷移。收斂出 CLAUDE.md 收錄門檻：高頻＋不可推斷兩個必要條件（缺一不可，核心比喻是「常駐稅」——不管這次任務用不用得到，內容都要被讀一次）。以 DragonsHoard 現有 CLAUDE.md 為實證基礎，盤點出八類知識庫 AI 協作內容（資料結構定義／分類判準／核心工作流程／內容模型 schema／維護規則／邊界禁止事項／協作風格／元規則），逐一套用判斷樹（每次都需要→CLAUDE.md／特定路徑才需要→Rules／特定任務才需要→Skill）分層。

最後變成什麼樣：結論落在 DragonsHoard 現況只用得到 CLAUDE.md 與 Skills 兩層——Rules 推薦條件收斂成三條同時成立才划算（真的有異質分區＋每個分區規則量本身不小＋實際工作很少同時橫跨多分區），DragonsHoard 三條全不成立（只有一個人、資料夾間高度互相依賴、每個分區規則本來就短）。.claude/ 現況（只有 skills/，沒有 rules/、agents/，也沒有 hook 設定）與這輪推導結論一致，驗證推導方向正確，不是巧合。整套框架成為 iThome 鐵人賽新第六篇《知識庫的 AI 協作內容該有什麼》的理論基礎，已發布。

五十、2026-09-06：raw/ 不變性 invariant 自相矛盾

最初目的：發現 CLAUDE.md 頂層寫「既有 raw/ 內容不得修改或搬移，只能新增」，但專案歸檔規定 active/→archive/ 整個搬遷、Promote 規定 raw/assets/ 圖片 git mv 出去，Lint 又寫「修改、刪除或搬移→異常」，三處互相打架。

怎麼做：初版提案（後來被推翻）想幫兩個例外搬移各自寫白名單，讓 Lint 分辨「合法搬移」跟「真異常」。使用者反問後推翻初版——專案歸檔根本不該動到 raw/：raw/ 保存的是來源本身，來源的性質不會因為使用它的專案是否封存而改變，把 wiki/ 層的 active/archive 生命週期複製一份套在 raw/ 上是不必要的耦合。

最後變成什麼樣：拿掉 raw/projects/ 底下的 active/archive 分裂，專案來源固定放在 raw/projects/<project-name>/，不因專案封存而搬家；歸檔動作只搬 wiki/，raw/ 完全不受影響；raw/ 唯一剩下的搬移例外是 raw/assets/ 歸類搬出（Promote 流程既有機制）。執行內容：資料夾搬移（git mv，皆偵測為 rename，內容不變）；CLAUDE.md 五處同步修改（核心架構樹狀圖、raw/wiki 結構對稱說明、raw/ 不變性宣告、常青與專案定義、專案歸檔步驟 1、Lint 規則一）；wiki/ 裡 33 個檔案的「原始來源：raw/projects/active/…」路徑提及機械式取代成新路徑。刻意不動：wiki/log.md、wiki/log-archive.md（append-only 歷史敘述不因 schema 改變回溯竄改，跟「五十一」同一原則）；第十一篇「直接把 CLAUDE.md 給你」正文教讀者舊版歸檔機制，使用者確認會自己重寫，這次不代勞。

五十一、2026-09-06：log.md append-only 與歸檔動作矛盾

最初目的：發現 CLAUDE.md 頂層寫「新紀錄一律追加於檔案末尾，不修改或刪除既有紀錄」，但歸檔規則又寫「超過 30KB，保留最近 10 筆，其餘搬到 log-archive.md」，字面上就是從 log.md 刪除既有紀錄，跟「五十」的 raw/ 問題同形狀。

怎麼做：判斷不變性的作用範圍應該是「log.md ∪ log-archive.md」整體集合，不是單一檔案；歸檔搬遷（依原順序、逐字不變搬到同樣 append-only 的 log-archive.md）是唯一允許移出 log.md 的例外操作。連帶發現 CLAUDE.md 裡「超過 30KB…保留最近 10 筆…搬至 log-archive.md」這段機械程序，跟 hoard-commit skill 步驟 5 完全重複，選擇拿掉 CLAUDE.md 這段重複、只留不變性宣告，理由是精簡。討論要不要幫 Lint 加一條規則對稱於 raw/ 規則一（擋 log.md 被竄改或非歸檔搬移）——不加，維持 Lint 五項不變，理由跟精簡一致：log.md 本來就標榜靠 Git 稽核、不阻塞主流程。

最後變成什麼樣：CLAUDE.md「log.md 維護規則」改成：「新紀錄一律追加於檔案末尾。既有紀錄不得竄改；唯一允許將既有紀錄移出本檔的操作是歸檔——依原順序逐字搬至同樣 append-only 的 wiki/log-archive.md。除歸檔外，不得修改、刪除既有紀錄。」拿掉 30KB／保留 10 筆的具體數字與切割程序（留在 hoard-commit skill 步驟 5），log-archive.md 的豁免說明單獨留一句、跟歸檔動作脫鉤。hoard-commit skill 不需改動。

五十五、2026-09-06：專案歸檔重新評估後卸載到 hoard-archive skill，翻案「十六」的舊決定

最初目的：承接「四十八」的 AI 推理錯誤糾正後，重新確認 CLAUDE.md「專案歸檔」段落該不該抽成獨立 skill——這是明確討論過並否決過的：「十六」（2026-08-12）用 AskUserQuestion 問過要不要獨立 skill，使用者當時選「不需要」，理由是頻率低、步驟不多，跟「不主動建議新 skill 除非有具體痛點」原則一致。

怎麼做：使用者重新提出：那個判斷是在五層機制模型（見「四十七」）出現前做的，框架本身的判準不是頻率、是「是不是多步驟只在特定任務觸發的程序」——歸檔完全符合；而且 hoard-pull／hoard-status 這兩個既有 skill 步驟量級跟歸檔差不多，歸檔卻沒有，不一致。討論觸發方式時，AI 第一版誤引「十六」的舊觸發設計（使用者明確要求，或 AI 觀察到跡象主動提議），使用者當場同意；但查證後發現這個「AI 主動提議」分支已經在更晚的規則品質與判準「二十五」被拿掉——使用者當時逐條檢查全文，確認這條路徑從沒真的被使用過，判定灰色地帶、不划算，簡化成只剩「使用者明確要求」一種觸發。AI 主動發現這個引用錯誤並回頭修正。

最後變成什麼樣：新建 .claude/skills/hoard-archive/SKILL.md，5 個步驟原封不動搬進去；CLAUDE.md「專案歸檔」段落收斂成一句話觸發條件＋指向 skill，只保留「使用者明確要求歸檔」這一種觸發路徑，不恢復已經被否決的 AI 主動提議分支。待處理：第十一篇「直接把 CLAUDE.md 給你」也有一份完整的舊版歸檔流程說明，使用者將自行重寫這篇文章，這次不代為修改，跟「五十」問題一的處理方式一致。

六十、2026-09-10：telegram_materials_sync.py 從純手動改為 launch script 前景執行一次

最初目的：使用者查到外部 Obsidian 外掛「Vault Telegram Bridge」，功能上跟既有 telegram_materials_sync.py（見「三十」「三十一」）重疊，比較後反問能不能比照 xcripts/photo_watcher.py（launch-dragonshoard.ps1 啟動時背景常駐輪詢 photos/／memes/ 自動轉檔）讓素材同步也自動化。

怎麼做：先評估「比照 photo_watcher 常駐輪詢」的成本——判定明顯偏高，因為兩者碰的資源性質不同：photo_watcher 只碰本地檔案，免費輪詢、失敗了下一輪重試就好；telegram sync 碰 Telegram API，常駐輪詢需要重構成持續連線（現有腳本是「連線→抓一批→斷線」一次性流程）、要處理 flood control 限流、且 session 過期時要求輸入手機驗證碼的互動提示會發生在無人看見的背景行程裡，等同靜默卡死，风险等级跟本地檔案處理不同。因此改採折衷：不做常駐輪詢，改成「開 session 時前景同步跑一次」——原腳本形狀已經符合「跑一次就結束」，不需要重構。刻意選擇前景而非比照 photo_watcher 用 -WindowStyle Hidden 背景隱藏：launch-dragonshoard.ps1 是使用者自己在真實終端機視窗手動執行、有 stdin，前景執行能讓 session 過期時的登入提示正常運作，順便解決了 hoard-materials-sync skill 文件裡「Claude Code 的 ! 前綴非互動管道無法完成登入」這個既有限制。

最後變成什麼樣：xcripts/launch-dragonshoard.ps1 在啟動 photo_watcher.py 背景行程之前，新增一行前景同步執行 python "$PSScriptRoot\telegram_materials_sync.py"；輸出（「抓到 N 則新素材」或登入提示）直接印在使用者自己的終端機視窗，不經過 AI 轉述。hoard-materials-sync skill 與 /hoard-materials-sync 手動觸發保留不變，用於 session 中途需要補抓最新素材時使用；skill 的 disable-model-invocation: true（AI 不自動觸發）語意不受影響，這次新增的自動化發生在 launch script 層級，不是 AI 決策層級。

六十二、2026-09-11：launch-dragonshoard.ps1 的 Telegram 素材同步從自動前景執行改成先詢問是否同步

最初目的：「六十」把 Telegram 素材同步改成開 session 時自動前景跑一次，但使用者後來覺得每次開 session 都固定執行、沒有選擇空間，想改成先問要不要同步。

怎麼做：在 Set-Location $vaultPath 之後、原本直接呼叫 telegram_materials_sync.py 的地方，改成先 Read-Host 詢問「同步 Telegram 素材？(Y/n)」，空白輸入或 Y／y 才執行同步，其餘（含 N／n）跳過；photo_watcher.py 背景常駐不受影響，仍自動啟動。同步更新 hoard-materials-sync skill 文件裡「launch script 已經前景同步跑過一次」的敘述，改成「先詢問是否同步，選擇同步才會前景跑過一次」。

最後變成什麼樣：開 session 從「固定跑一次同步」變成「每次自問一次」，使用者可以視當下要不要花時間等同步自行決定；/hoard-materials-sync 手動觸發不受影響，仍可在跳過或需要補抓時使用。這個時間點的問句本身，「七十三」發現跟任何一次 git pull 都無關，之後又被拿掉改綁 pull。

六十三、2026-09-11：新增頂層目錄 Clippings/（Obsidian Web Clipper 自動擷取落地區）

最初目的：iThome 第十九篇試裝 Obsidian Web Clipper 並實際擷取網頁時，發現它會在 vault 根目錄自動建立 Clippings/ 資料夾存放擷取的筆記，跟 chaos/materials/raw/wiki 等既有頂層目錄平行，完全不受 Hoard 既有結構管轄——這個資料夾是工具行為決定的，使用者無法透過 Hoard 這邊的規則直接控制它的存在。文章草稿一度只當作待解決的懸念收尾，之後使用者確認想法：這個資料夾可以留下來，只是需要在 CLAUDE.md／建設歷程補上正式定位。

怎麼做：比對 Clippings/ 的實際性質——內容是工具自動寫入、尚未歸類、不算正式 wiki 內容——跟 raw/assets/（尚未歸類或來源附帶的附件，只能新增、git mv 歸類搬出）幾乎一致，只是前者裝完整擷取筆記、後者裝附件。判定不需要為它另外設計一套治理規則，直接套用 raw/assets/ 現有的生命週期邏輯：先落地，決定收錄時 git mv 到 raw/ 對應路徑走正常 Ingest 流程，搬出前不受交叉引用／孤兒頁面規則約束。這個套用不影響 raw/ 不變性判準——Clippings/ 本身不屬於 raw/ 樹，移動它的檔案不受「raw/ 不變性」既有 Lint 規則檢查；檔案一旦搬進 raw/ 才開始受唯讀約束。

最後變成什麼樣：CLAUDE.md「核心架構」資料夾樹新增 Clippings/ 一行，並補一段說明其性質同 raw/assets/；wiki/index.md 不用動，因為 Clippings/ 不是 wiki 內容。第十九篇文章裡「還沒想清楚要不要讓它進 materials/」的懸念收斂成實際定案，文章本文是否要回頭反映這個結論，留給使用者之後自行決定。

六十四、2026-09-11：CLAUDE.md「核心架構」瘦身，拆出獨立的「原始來源（raw/）」「Clippings/」section

最初目的：使用者重看 CLAUDE.md，主觀感覺「太肥」——不是效能問題，是直覺上覺得常駐 context 裡有些內容不是每個 session 都用得到。想討論具體的「按需檢索」抽取方法能不能套用到 CLAUDE.md 自己身上（呼應 CLAUDE.md 撰寫原則原則二「只放值得當常駐 context 的內容」，跟 Ingest／Query／Lint 演算法卸載到 skill 是同一個判準的延伸）。

怎麼做：先釐清「抽成 skill」跟「結構整理」是兩件不同的事——前者真的會減少常駐 token，但引入「AI 可能忘記主動查」的新風險，只適合套在風險等級低（頂多整理不好，不是資料損毀）的規則上；後者不減少常駐量，只解決可讀性與待遇一致性。逐段檢視「核心架構」底下四段散文，發現：(1) raw/wiki 結構對稱敘述其實跟樹狀圖既有的 ← 不分 active/archive 註解重複；(2) 其餘三段（raw/ 來源範圍與唯讀邊界、raw/assets/、Clippings/）都是 raw/ 相關規則，卻被夾在「地圖」段落裡，跟 materials/／chaos/／memes/／photos/ 各自有獨立 H2 section 的既有模式不一致。原本提案把 Clippings/ 併入新的 raw/ section 當附屬段落（因為規則內容跟 raw/assets/ 幾乎一樣、篇幅很短），使用者指出這樣會模糊一個結構事實：Clippings/ 在目錄樹上是跟 raw/ 平行的頂層目錄，不是 raw/ 的子集，該有自己的獨立位置——篇幅短不等於不該獨立，兩個問題要分開處理。

最後變成什麼樣：砍掉重複的 raw/wiki 結構對稱段落；新增 ## 原始來源（raw/） section 收納 raw/ 專屬的來源範圍與唯讀邊界規則、外加 raw/assets/ 說明；新增獨立的 ## Clippings/ section，內容壓縮成一句話（指向 raw/assets/ 同性質，不重複整套機制）。raw/ 唯讀這條規則本身判定不適合抽成 skill——它是目前唯一一條「拿掉常駐會有不可逆風險」的規則（違反＝來源被竄改或遺失），跟混亂層／素材庫「頂多整理不好」的風險等級不同，因此維持常駐，這次只做結構搬移不減少 token。混亂層要不要抽成 skill 當 pilot，留待下一輪決定。

六十五、2026-09-11：混亂層「共通規則」精簡

最初目的：延續「六十四」的瘦身討論，逐句檢視混亂層段落是否有重複或無意義的資訊。先確認開頭定義句（「chaos/ 是 Wiki 外的暫存與發想空間，不受 raw/ 唯讀、wiki 交叉引用與 index.md 規則約束」）不是廢話——它是真正的範圍豁免宣告，觸發前提明確（AI 已經在處理 chaos/ 路徑），沒有「不知不覺」違反的空間，風險模型跟其餘混亂層規則一致，理由連結正確遵守「只描述要做什麼、原因放連結」的既有寫作準則。接著檢視「檔案類型」與「共通規則」五條，抓到兩處問題。

怎麼做：第一處——「AI 預設不主動整理，除非使用者明確要求」與「使用者要求處理 chaos 內容時，先整理成 checklist……」是同一個開關的兩面，被拆成兩條分開讀，合併成一條更清楚呈現邏輯關係。第二處——「新增待辦時先記錄一句話意圖，不預先展開完整步驟」被判定可能是「chaos/ 可直接收錄想法、片段與未整理內容，不要求先分類或寫成完整文章」的特例重複；依「從 failure 長出規則」原則詢問使用者這條背後是否有具體事故，使用者沒有補充相反資訊，判定為無記錄的特例，直接砍除。

最後變成什麼樣：「共通規則」從五條收斂成三條：不要求先分類／整理口述時保留原意／預設不整理＋要求時的處理流程合併成一條。「檔案類型」與開頭定義句維持不動。混亂層抽成 skill 當 pilot 的討論尚未開始，這次都還是結構精簡層次。

六十六、2026-09-11：Promote（chaos → wiki）卸載到 hoard-promote skill

最初目的：延續「六十四」「六十五」的 CLAUDE.md 瘦身討論，使用者提出：混亂層裡真正該抽成 skill 的其實是「Promote」這個動作，不是開頭定義句、檔案類型、共通規則那些被動規則。

怎麼做：比對 Promote 的形狀——有明確觸發點（使用者確定某段 chaos 內容要收進 wiki）、多步驟程序（走 Ingest＋用詞處理＋圖片搬移＋決策記錄＋收尾清理）——跟已經抽出去的 Ingest／Query／Lint／歸檔／Pull／Status 六個 skill 是同一種形狀，風險模型也一樣（觸發前提明確，不像「raw/ 唯讀」或混亂層被動規則那樣有「AI 沒意識到就手滑」的風險）。這個判斷修正了 AI 先前「混亂層」籠統指涉的範圍——被動規則（定義句／檔案類型／共通規則）風險等級不同，仍然擱置，不在這次動作範圍內。

最後變成什麼樣：新建 .claude/skills/hoard-promote/SKILL.md，6 個步驟（觸發、走 Ingest、用詞處理、圖片、決策記錄、收尾清理）搬進去，## 相關規則 指回 CLAUDE.md「混亂層」與 hoard-ingest，不重複內容。CLAUDE.md「Promote」小節收斂成一句話觸發條件＋指向 skill，跟「專案歸檔」段落的既有模式一致。混亂層剩下的被動規則（開頭定義句、檔案類型、共通規則）要不要抽成 skill、怎麼驗證 AI 會主動查，留待之後再討論。

六十七、2026-09-11：raw/assets/ 併入原始來源段落，wiki 直接編輯 改名「正式知識（wiki/）」搬到 raw/ 旁邊

最初目的：使用者問「原始來源（raw/）」段落（34-38 行）能不能刪掉、能不能移植，並提出 wiki 層也該有專屬說明，跟 raw/ 待遇對稱。

怎麼做：raw/ 來源範圍＋唯讀邊界那段判定不能刪（前面「六十四」已經定案，這是唯一一條拿掉常駐會有不可逆風險的規則）；但 raw/assets/ 定義句本身內容跟前一句已經提到「路徑搬移僅限於 raw/assets/ 歸類搬出」重疊，判定可以直接併進同一段，不用單獨一句，等於再壓縮一次而不是搬去別處。「wiki 層要有專屬說明」則發現 CLAUDE.md 裡早就有一個候選——## wiki 直接編輯 段落本身已經是「定義＋核心規則」的形狀（使用者可直接編輯／交叉引用是硬性要求），只差標題跟位置沒有跟 raw/ 對稱，判定不需要打散重組 Frontmatter／連結／index／log 這些既有子規則，只要改名搬位置。

最後變成什麼樣：raw/assets/ 的定義併入「原始來源（raw/）」段落尾端，不再單獨成句；## wiki 直接編輯 改名為 ## 正式知識（wiki/），搬到 ## Clippings/ 之後、## 常青與專案 之前，跟 ## 原始來源（raw/） 前後呼應。過程中發現並修正一個死鏈：文中「見「Promote」步驟 1」的引用在「六十六」把 Promote 抽成 skill 後步驟重編號、變成步驟 3，一併修正指向 hoard-promote 步驟 3。

六十八、2026-09-11：「專案歸檔」CLAUDE.md 觸發指標整個刪除

最初目的：使用者確認 專案歸檔 已經卸載到 hoard-archive skill 後，直接提出：既然是 skill，CLAUDE.md 裡那句「使用者明確要求歸檔專案時，呼叫 hoard-archive」的觸發指標本身也該刪掉——使用者預期這個 skill 能直接透過語意觸發，不需要 CLAUDE.md 再重複講一次觸發條件。

怎麼做：比對 CLAUDE.md 的觸發句跟 hoard-archive skill 自己的 description 欄位，發現兩者高度重複——skill 的 description 本身已經完整寫了「任何要把 DragonsHoard 專案標記封存的情境都該呼叫這個 skill，不要自行即興處理」，而這份 description 本來就會透過 skill 清單常駐在每個 session 的 context 裡（不需要 CLAUDE.md 額外提醒），符合「單一 Source of Truth」判準（CLAUDE.md 撰寫原則原則二）。直接刪除 CLAUDE.md 裡的「專案歸檔」小節，不留指標。

最後變成什麼樣：CLAUDE.md「常青與專案」底下不再有「專案歸檔」小節。這個判斷理論上同樣適用於 Ingest／Query／Lint／Pull／Status 五個既有 skill 的 CLAUDE.md 觸發指標——但這次只處理「專案歸檔」這一個，其餘五個是否要跟進，以及「刪掉指標後 skill 語意觸發是否真的可靠」這件事本身，都還沒驗證，屬於待觀察的懸念，不是已經定案的結論。

六十九、2026-09-11：「正式知識（wiki/）」補回角色定義與內部三大類說明

最初目的：「六十七」把 wiki 直接編輯 改名搬位置之後，使用者重新檢視發現這段對 wiki/ 本身的描述變得很薄弱——只剩「使用者可直接編輯」加三條規則，完全沒講 wiki/ 是什麼、跟 raw/ 的關係，而這是整個知識庫最重要的資料夾。這是這一輪瘦身過程中第一次往回修正「砍過頭」的地方。

怎麼做：檢查發現 wiki/ 內部的三個分類（evergreen/topics、evergreen/self、entities/）在 CLAUDE.md 全文裡從來沒被完整說明過——self/ 只在樹狀圖出現過，從沒展開；entities/ 同樣只在樹狀圖與 frontmatter type 列舉裡出現，實際定義（人物／組織／概念）只存在於 wiki/index.md 自己的分區標題，沒有回寫進 CLAUDE.md。避免無中生有，entities/ 的定義直接採用 wiki/index.md 現有的「Entities（人物／組織／概念）」分區標題原文，self/ 的內容範圍依現有頁面（自我檔案、健康與訓練紀錄、寫作與身分認同等）歸納。跟 raw/ 的關係（wiki/ 內容從 raw/ 經 Ingest 而來）補一句，但不重複第 3 行已經講過的「AI 是 Wiki 維護者」定位，避免重新引入前面幾輪一直在清除的重複資訊。

最後變成什麼樣：「正式知識（wiki/）」新增兩段——角色定義（跟 raw/ 的關係、使用者查詢閱讀的主要介面）與內部三大類說明（evergreen 再分 topics／self、entities、projects），既有三條規則（交叉引用／index-log／文章正文先給草稿）維持不動接在後面。這是本輪 CLAUDE.md 瘦身系列（六十四～六十八）裡唯一一次「加字」，提醒瘦身不是單向只砍不加，該有的角色說明砍過頭要補回來。

七十、2026-09-11：entities/ 分類首次落地，定案資料夾＋樞紐頁結構

最初目的：使用者用 Obsidian Web Clipper 收了七份 Obsidian 官方說明文件節錄到 Clippings/，討論後確認要收進 entities/——這是 entities 這個分類從「六十九」補回定義以來第一次真正被使用，先前全庫零頁面（wiki/index.md 一直寫著「尚無頁面」），沒有任何既有頁面可以參照怎麼寫。過程中使用者也反映 entities 這個字看到不會聯想到「外部事物或資源」，一度討論改名（考慮過 entries／resources／subjects／references，entries 最貼近「維基百科條目」語感），最後使用者改變主意維持原名，不執行改名。

怎麼做：使用者說明會收的頁面量大，判定不適合單檔，確認比照 evergreen/topics/<topic-name>/ 既有模式，改成資料夾＋_index.md 樞紐頁：wiki/entities/Obsidian/ 底下一份樞紐頁＋依實際功能（而非來源檔案）拆分的子頁，索引方式沿用「DragonsHoard建設歷程」等既有路由頁在 wiki/index.md 只留一個 bullet 連到樞紐頁的慣例，不需要為 entities 另訂新規則。raw/ 那邊同步發現樹狀圖裡從來沒有 entities 這一支（只有 evergreen/、projects/、assets/），比照 wiki 端補上 raw/entities/<entity-name>/。

最後變成什麼樣：新增 Obsidian 樞紐頁，底下跨裝置同步方式／從外部工具匯入／核心外掛與格式轉換 三個子頁，對應 raw/entities/Obsidian/（七份原始 clippings）；CLAUDE.md 核心架構樹狀圖 entities/ 補上 <entity-name>/ 子資料夾記號（wiki、raw 兩處），跟 topics/<topic-name>/、projects/<project-name>/ 記法對齊。以後其他 entity（人物、工具等）有前例可循：資料夾＋樞紐頁、頂層 index.md 一個 bullet 連進去，不用每次重新設計。（連結路徑於「七十一」entities/ 分類廢除後機械更新為現址，raw/entities/Obsidian/ 保持不動；本段敘述維持原樣不回溯改寫。）

七十一、2026-09-11：entities/ 分類廢除，唯一案例併回 evergreen/topics/

最初目的：「七十」建好 entities/Obsidian/ 當天，使用者重新檢視突然質疑這個分類有沒有必要——邊界模糊、目的不清楚。

怎麼做：重新檢視 entities/Obsidian/跨裝置同步方式 實際寫出來的內容，發現它做的是「官方做法 vs. 使用者實際做法」的比較與收斂判斷，形狀跟 topics/ 既有頁面（例如 AI輔助開發驗證流程：外部素材整理＋精簡收斂）幾乎一樣，不是單純的「這是什麼，記錄事實」型資源卡。加上更硬的訊號：entities/ 從 7/29 建庫到「七十」落地共 44 天全庫零頁面，這次是第一次真實使用，卻卡得很勉強——呼應 知識庫建設哲學「七」的原則「先讓真實使用壓力把需求擠出來，再長結構，不要預先設計好分類再塞內容」，entities/ 當初是預先設計出來、沒被真實需求驗證過的分類，這次測試結果反而是負面訊號。討論收斂：entities/ 唯一講得通的情境是「純粹的人物／組織檔案卡」（無使用者自己的框架/方法論，純粹是誰是誰的事實卡），但目前沒有任何真實案例，不需要為假設中的未來需求保留空分類，真的遇到再開。

最後變成什麼樣：wiki/entities/Obsidian/（git mv）整個搬到 wiki/evergreen/topics/Obsidian/，三個子頁 frontmatter type: entity 改回 type: topic；wiki/index.md 移除 Entities 分區，Obsidian 改列在常青主題區、補上範圍宣告。raw/entities/Obsidian/ 不隨 wiki 端搬動，維持原路徑不變——這不是疏漏，是延續「raw/ 路徑一旦落地就不再跟著 wiki 端分類調整」的既有原則（同「六十七」拿掉 raw/projects/active|archive 分裂時「歸檔動作只搬 wiki/，raw/ 完全不受影響」的邏輯）；連帶更新「七十」段落裡指向 entities/Obsidian/... 的連結為現址（機械修正路徑，不改敘述本身）。CLAUDE.md 核心架構樹狀圖（wiki、raw 兩處）、「正式知識（wiki/）」三大類說明改回兩大類、Frontmatter type 列舉、index.md 維護規則裡的「entities 分區」提及，全部移除 entities／entity 字樣。從建立到廢除只隔幾分鐘，是目前建設歷程裡最短命的結構決定，但過程本身驗證了「知識庫建設哲學」的判準確實能在真實情境裡快速抓出過度設計。

七十二、2026-09-11：任務型捕捉檔草稿完成後改歸檔至 raw/，不再一律整份刪除

最初目的：使用者盤點 chaos/ 白板時發現三份任務型捕捉檔（第十九篇捕捉.md、第十八篇 Query 捕捉.md、第十六至十八篇 Query 捕捉.md）綁定的文章草稿都已經寫完，覺得繼續留在 chaos/ 不合適，想直接刪除；AI 盤點內容後指出：完全刪除會讓其中兩份裡還沒被其他地方追蹤到的開放項目（第十六至十八篇 待辦清單「三篇銜接處確認」未打勾；第十八篇 Query 捕捉 裡「校準機制沒跑過」「tags 中英混用」兩條技術債）連被記得的地方都沒有。

怎麼做：使用者對兩個開放項目分別裁定：「銜接處確認」判定不需要單獨追蹤（潤稿時自然會處理），兩條技術債接受被埋進 raw/（不特別搬去 chaos/想法.md）。裁定後，比照既有「第三篇 - 取材分析」「Karpathy LLM Wiki 中譯」的衛星檔案先例（原始素材進 raw/，用 wikilink 或純文字路徑從 wiki 頁面連過去，不強制每份都包一層 wiki 頁面），把三份檔案 git mv 到 raw/projects/iThome鐵人賽2026/（保留歷史、內容不變），再把 wiki/（觸發機制演變.md、決策歷程.md、第十六～十八篇文章正文）與 chaos/白板.md、chaos/Web Clipper.md 裡指向舊 chaos/ 路徑的引用改成新 raw/ 路徑；wiki/log.md 與 raw/ 內部既有檔案（草稿.md 系列、被搬移的捕捉檔本身）裡的舊路徑文字維持原樣不動，前者因為 append-only 歷史準確性、後者因為 raw/ 內容一旦落地不得修改。

最後變成什麼樣：一般化出新的任務型捕捉檔收尾規則，補在「Promote 原有規則」之外——文章草稿寫完、捕捉檔本身任務完成後，若還有值得保留但沒被其他地方涵蓋的素材／未決事項，先由使用者逐項裁定去留，裁定完成後 git mv 整份歸檔進對應 raw/projects/<project-name>/，不再只有「整份刪除」一種收尾方式；chaos/ 因此不會一直堆積已完成任務的舊檔案，同時素材也不會真的消失。

七十三、2026-09-14：Telegram 素材同步的觸發時機改綁 hoard-pull，拿掉開 session 詢問

最初目的：這次 /hoard-pull 執行時撞到 materials/樂戶飯店.md 同名衝突——stash 起來的本地未 commit 版本，跟 pull 下來的遠端版本內容不同（用詞有出入，判斷是兩則相近但不完全一樣的 Telegram 訊息，不是同一則被重複處理）。順著這個衝突回頭檢視同步觸發設計，發現「六十二」訂下的詢問時間點（開 session 時）跟任何一次 git pull 完全無關：同步永遠可能發生在本地 xcripts/telegram_checkpoint.json 還沒被 pull 更新之前，讓「三十一」當初要解決的多機 checkpoint race 有機會重新發生——另一台機器已經同步並推上 GitHub 之後，這台機器若在還沒 pull 前就先答應同步，會拿本地過期的 min_id 重新處理其實已經被別台機器抓過的訊息，產生同名檔案衝突。

怎麼做：討論確認「checkpoint 新不新鮮」跟「有沒有新內容值得抓」是兩個獨立問題，各自需要不同的檢查手段：

  • 新鮮度：只要同步永遠緊接在一次成功的 hoard-pull 之後執行，本地 checkpoint 就保證等於 origin 上的最新版本——git pull 這個動作本身就是在把本地檔案內容更新成最新，不需要額外寫一段 git fetch 加比對 HEAD 落後與否的檢查，順序保證本身就足夠，比另外設計一層檢查更省事也更難出錯。
  • 有沒有新內容：checkpoint 新鮮與否管不到這件事，需要另外跟 Telegram 要一次最新訊息 ID（client.get_messages('me', limit=1)）跟本地 min_id 比大小，前者小於等於後者就代表沒有新素材，直接跳過，不動用完整抓取邏輯也不寫任何檔案。

兩層檢查合起來就能把「要不要同步」完全交給機器判斷，不需要使用者回答任何問題。討論中也確認一條路徑不受「同步緊接在 pull 後」這個順序保護：/hoard-materials-sync 手動中途觸發沒有規定使用前一定要先 pull，理論上仍可能用到過期 checkpoint。使用者評估這條路徑觸發機率低（要自己主動叫用）、就算撞到後果也只是重演一次可人工排解的 stash 衝突，不是資料遺失，決定不額外加防呆，接受這個殘餘風險，不做成第三層檢查。

最後變成什麼樣：xcripts/launch-dragonshoard.ps1 拿掉整段 Read-Host 詢問與呼叫 telegram_materials_sync.py 的邏輯，只保留啟動 photo_watcher.py 跟 claude；telegram_materials_sync.py 的 main() 在建立連線後、真正逐則抓取前，先做一次 peek 檢查，沒有新內容就印出「目前已是最新（checkpoint=X），沒有新素材」並提前結束；hoard-pull skill 新增步驟 7，在 pull 完成（含衝突／stash 皆已處理）後自動呼叫 telegram_materials_sync.py，不再詢問。hoard-materials-sync skill 說明文字同步更新，拿掉「launch script 會先詢問」的過時敘述，改成指向新的自動觸發點，保留手動中途補跑的既有用途。

七十四、2026-09-14：公開站排除範圍寫成 CLAUDE.md 執行規則，新增 hoard-public-site-sync skill

最初目的：討論怎麼把一則具體歷程紀錄分享給讀者時，發現「二十九」當時只留下一次性的篩選結果（哪四個主題公開、排除哪些其他類別），沒有沉澱成可重複套用的判準——CLAUDE.md 完全沒提過 public-site，之後要新增頁面到公開站時，排不排除全靠臨場判斷。

怎麼做：先確認現有安全網（同步方式限定 git checkout <path> 逐頁複製、絕不整支 git merge）本身已經是 whitelist-by-default，但沒解決「內容層級」的判斷缺口——資料夾層級能排除的（self/、projects/）好處理，難的是同一主題頁裡混雜可公開與不可公開內容的情況，需要文字判準而非路徑判準。接著發現一個容易忽略的反效果：CLAUDE.md 全文會逐字鏡像到 content/claude.md 公開（見「二十九」2026-08-31 那筆），排除規則如果直接點名真實的敏感類別，等於規則本身把要隱藏的事實寫在公開頁上。確認後決定排除範圍一律用抽象詞彙描述（例如「未公開的職涯現況／個人計畫」而非具體事項），這樣規則本身跟著 CLAUDE.md 一起鏡像公開也不會反洩漏。同步觸發時機維持使用者明確提出才做，不排程、不自動 push——push 是對外可見、影響公開網站內容的動作，跟既有「Git 操作經 skill、push 前一定確認」的原則一致。

最後變成什麼樣：CLAUDE.md 新增「公開站（public-site 分支）」一節，抽象詞彙寫排除範圍（evergreen/self/ 全部、涉及未公開職涯現況／個人計畫／可識別第三方身分的內容、wiki/projects/ 全部，以及其他特定主題身分相關段落），同步流程指到新的 .claude/skills/hoard-public-site-sync/SKILL.md；skill 內容層級判斷（步驟 4）明確要求拿不準就停下來問，不能只靠路徑比對放行。這是本節第一次把公開站的篩選判準沉澱成規則，之前完全沒有書面依據。

七十六、2026-09-15：新增 raw/雜記寶庫/，收「已影響完、不預期再用」的原始來源

最初目的：使用者把西風一篇談「向上交換」的 Facebook 貼文貼進 chaos/白板.md，要求完整收進 vault 並加註解。討論一路想在 wiki/evergreen/topics/ 或 wiki/evergreen/self/ 找歸屬：先糾結主題名稱該具體（「向上交換」）還是可以泛稱（使用者提「成功」），釐清「頁面名稱要具體」跟「主題名稱」是兩條不同規則，泛稱本身不違規；接著轉向 self/，使用者又點出既有 self/ 頁面「像一團沙」，沒有共同分類邏輯。最後使用者自己拆穿前提：這篇文章已經完成它的作用（意識到「聊天」是重要的信息交換動作），不預期未來會再查閱或引用，本質是「證明、存寶物」，不是要用的知識——這跟 wiki/「會被查詢引用」的定位不合，一開始也不完全等於 raw/ 慣常的「Ingest 上游」定位。

怎麼做：確認不建立任何 wiki/ 頁面，直接留在 raw/。命名討論過「存底」（庫裡已有先例用語，如「Karpathy gist 英文原文存底」）、「存證」「藏」「拾遺」，最後使用者選「雜記寶庫」。放置位置上，使用者否決掛在 raw/evergreen/topics/<topic-name>/ 底下——因為那個路徑格式本身暗示「對應 wiki/evergreen/topics/ 有同名頁面」，混進去會造成誤認；改成 raw/ 頂層新資料夾，跟 evergreen/、projects/、assets/ 平級。過程中也發現既有 raw/ 完全沒有自己的可發現性，只能靠 wiki 頁面的反向連結找到來源（例如 raw/entities/Obsidian/ 靠 wiki/evergreen/topics/Obsidian/ 的「原始來源」欄位才找得到）；雜記寶庫/ 沒有 wiki 頁面可以反向連結，因此另外維護自己的 index.md（append-only：日期＋檔名＋一句話留下原因），避免內容存進去卻再也找不到。

最後變成什麼樣：CLAUDE.md 核心架構樹狀圖與「原始來源（raw/）」段落補上 雜記寶庫/ 說明；新增 raw/雜記寶庫/index.md；西風〈向上交換〉原文（hashtag 連結原樣保留，未附原始貼文網址）連同使用者的一段留存原因註記，存入 raw/雜記寶庫/向上交換（西風）.md 作為第一筆案例。

七十七、2026-09-15：CLAUDE.md 依 Global／Routing／Workflow／Object spec 四層重構，新增 .claude/specs/

最初目的：使用者從 Harness Engineering 角度重新檢視 CLAUDE.md，核心假設是它不該是完整規格書，只該留「任何任務都需要知道的全域資訊」跟「把任務導向正確 context 的 routing」。起點是一個真實踩雷案例：AI 曾把管「頁面命名」的規則跨層級套用去否決「主題命名」提案，暴露出 CLAUDE.md 混雜多層級規則、沒有標示適用對象的結構性問題。

怎麼做：先做 context audit，把 CLAUDE.md 逐段分類；使用者提出四層架構（Global／Routing／Workflow context／Object spec），並定義單向依賴（Global → Routing → Workflow →〔需要時〕Object spec，Routing 也可以直接指到 Object spec）。過程中發現第一輪把 Object spec 內容直接複製進五支 skill 是錯誤示範——同一份規格被複製進兩支以上 workflow，違反「兩個以上消費者就該獨立」的判準。引入 schema 骨架（Object／適用範圍／消費者／規格本體／驗證方式）統一 Object spec 寫法，「適用範圍」欄位直接對應最初的根因案例。執行順序：CLAUDE.md 先瘦身到只剩 Global＋Routing（移出內容先進 chaos/CLAUDE.md 重構分析.md 暫存，不直接刪除）；audit 所有 skill description（常駐成本高但多數在複述 body 步驟）；audit skill 本體找出反向依賴與內嵌 spec；最後把 Object spec 分兩種方式定位——有天然單一檔案的用自我描述（log.md、index.md、建設歷程路由頁檔首），跨檔案多消費者的新建 .claude/specs/（wiki-page.md／raw-lifecycle.md／chaos-capture.md／claude-authoring.md／materials.md）。過程中查證發現 log.md 格式的 CLAUDE.md 舊規格（兩欄）跟 log.md 檔首本身（三欄）從建庫第一筆起就不一致，且從未被真正遵守過，判定 CLAUDE.md 舊版是錯的一方，非 log.md 漂移。另外確認並廢除一條從未被真正執行過的規則：「chaos 內容整理需先 checklist 再討論」，保留更簡單的「AI 預設不主動整理」；連帶更正並改寫了 memory feedback_whiteboard_checklist_discuss.md。

最後變成什麼樣：CLAUDE.md 從 15156 字元降到約 4000（含小幅補強：目錄樹補上 .claude/skills/、xcripts/），只剩角色定義、行為邊界、語言慣例、一張完整的 skill routing 表（新增先前遺漏的 archive／status／pull／polish／title／materials-sync）。五支 skill（hoard-commit／hoard-ingest／hoard-promote／hoard-status／hoard-public-site-sync）的內嵌 Object spec 內容改成指向 .claude/specs/ 的指標（hoard-public-site-sync 例外，唯一消費者維持內嵌）；11 支 skill description 常駐字數從約 3300 降到約 1362。過程稽核紀錄與逐段分類對照表已 Promote 進 raw/evergreen/topics/LLM Wiki/；可脫離 DragonsHoard 單獨成立的通用方法論（四層分層判準、Object spec 消費者判準、schema 骨架）併入 CLAUDE.md 撰寫原則 第 2 條，這裡只留 DragonsHoard 自己的套用紀錄。

七十八、2026-09-16：回溯「七十七」這波重構真正的驅動，浮現「引導 vs. 指令堆疊」判準

最初目的：使用者事後被 AI 問到「為什麼這兩天做出這麼大的改動」，回頭拆解才發現「七十七」記的「一個真實踩雷案例」（頁面命名規則誤套到主題命名）其實只是表面症狀。真正驅動是一段時間累積的操作面痛點：某個 skill 沒有照著流程跑完、執行過程中 AI 對任務的理解開始被新進的 context 污染、執行方向跟使用者要的完全不一樣。這些反覆出現的小問題逼他去審視整個 harness，過程中才接觸到 Harness Engineering 概念（他的理解：「管理 Agent 讀取的上下文」），一路查下去才確認 CLAUDE.md 與 skills 本身有很多結構性問題，「七十七」的重構與 09-16 後續（Lint 從理論重新推導、hoard-lint 拆成獨立 skill、全面 skill 簡化）都是這次審視的產物，不是單一 bug 觸發的過度反應。

怎麼做：這則本身不是技術決策，是回顧既有決策鏈時浮現的判準，沒有另外的取捨過程。回顧中提煉出一句具體結論：skill／CLAUDE.md 這類檔案裡「有效」的內容，不是丟一大堆 instructions 期待 AI 會 follow——這類檔案本質上做不到這件事；比較有效的做法是把可以外部化的東西盡量抽成 scripts（機械化、保證執行）與 specs（單一事實來源、跨消費者共用）這種「extracted jobs／contents」去引導 AI，而非純文字規則堆疊。

最後變成什麼樣：這個判準不改變任何現行結構，是「七十七」與其後續一直在用、但先前沒有明講的設計哲學，這次補上文字說明，供之後設計或檢討 skill 內容時直接引用；同步記入 memory（user_ai_literacy_via_hoard.md）。09-16 後續（hoard-lint 拆成獨立 skill、全面 skill 簡化）完成後精確重測：12 支 skill description 總字數（含新增的 hoard-lint）從「七十七」當時的 1362 字元再降到 562 字元；CLAUDE.md 維持 6617 字元（68 行）。

反向連結