RambleWiki

觸發機制演變

Properties1
tagsdragonshoard架構史, 工作模式

閱讀時間約 100 分鐘

DragonsHoard 建設歷程－觸發機制演變

← 建設歷程總覽

範圍：Lint／Ingest／Query／commit 各自「什麼時候該觸發、範圍多大」的演變過程。不收：觸發機制對不對的收斂判準本身（見 規則品質與判準）、資料夾/schema 層面的定案（見 架構與流程）。

九、2026-07-30：Lint 觸發機制從「靠自己記得」改成 skill 綁 commit

起點：使用者問這個 session 有沒有跑過 Lint，回頭查 wiki/log.md 才發現從 repo 建立以來從未有過任何一筆 lint 紀錄——CLAUDE.md 裡寫的「每次開始處理 DragonsHoard 相關工作時自動用 git diff 掃描」的「自動輔助檢查」機制，事實上一次都沒真的觸發過。跟第八節「raw 唯讀」發現的問題是同一個模式：規則寫在 CLAUDE.md 裡不等於會被執行（Policy vs Enforcement），這次換 Lint 機制上真實發生。

討論過程：

  • 先釐清觸發時機該綁在什麼動作上：考慮過 Claude Code 的 SessionStart hook（可綁 /clear、開新 session、resume、/compact 之後等不同來源），也考慮過綁在 git commit/push 本身——後者邏輯上更貼合，因為 Lint 的檢查點本來就是用 commit SHA 記錄的
  • 比較「寫成 hook」vs「寫成 skill」：hook 由 harness 保證觸發，但只能執行 shell 指令、無法自己判斷內容；skill 沒有強制觸發保證，呼叫與否仍取決於使用者手動輸入或 AI 自己判斷情境符合。理論上 hook 才是真正解決「不能靠記性」問題的機制
  • 使用者依過往經驗判斷，skill 的方式高機率已經足夠：skill 的名稱與描述會出現在每個 turn 的 skill 清單裡，比起規則被埋在 CLAUDE.md 某個段落深處，觸發時「注意到」的機率高很多，因此決定不裝 hook，先用 skill 這個較輕量的方案

最終定案：

  1. 新增 .claude/skills/dragonshoard-commit/SKILL.md，把 commit／push／lint 三個動作串成固定流程：找上次 lint checkpoint（log.md 裡最後一筆 lint 紀錄的 commit SHA，沒有的話用 repo 第一個 commit）→ git diff 掃描 wiki/ 異動 → 健檢（矛盾、孤兒頁面、缺交叉引用等）→ 確認 index.md 跟上 → 在 commit 之前於 log.md 記錄新 checkpoint（用「這次 commit 之前」的 HEAD，寧可下次重疊也不要漏看）→ 草擬並確認 commit → 詢問是否 push
  2. CLAUDE.md「Lint（健檢）」一節精簡為 pointer 指向這個 skill，拿掉原本描述模糊、從未真正觸發過的「自動輔助檢查」段落
  3. 想法.md 那邊「AI 定期讀過」的觸發時機，本次討論明確擱置，留待之後另外處理，不跟這次的 Lint/commit 機制綁在一起

十七、2026-08-12：Ingest 觸發點確認 + Claude Code 五層機制模型（同日，緊接「十六」）

起點：同一天稍晚，使用者重新拾起 Karpathy schema 層概念，跟 AI 深入討論「schema 層該怎麼組成」，過程中用一個假設情境（讀到一份 PDF《文字變現》，抓到想法「長文不是問題，沒有導航才是問題」，要求 ingest 進知識庫）反覆逼問 AI 描述自己會怎麼處理。完整討論骨架原存在 chaos/模組二_白板.md（模組二「結構即Prompt」取材用捕捉檔）；模組二後來被跳過未寫（決策歷程「七」「九」），該捕捉檔已於 2026-08-28 整理 chaos 時刪除，內容已收攏進本節，無遺失。

核心發現：「找得到」不等於「在需要時被使用」——前者是被動、能力型描述（技術上存在路徑可查），後者才是真正的靶心（在對的時機真的被叫出來）。內容的價值 = 品質 × 找不找得到，但「找得到」這個判準本身還不夠精確，容易讓人誤以為 index.md／wikilink 這種被動基礎設施已經解決問題，實際上只解決了「能不能找到」，沒解決「會不會被想起來用」。

AI 兩次實測、兩次現場犯錯：第一次實測，AI 提議把觸發點放在 wiki/projects/active/iThome鐵人賽2026/CLAUDE.md（子目錄 CLAUDE.md），理由是「寫作時會碰這個資料夾」；使用者追問後 AI 自己發現破綻——這系列文章的真實寫作流程是先在 chaos/白板.md 反覆草擬，定稿才歸檔進 wiki 專案資料夾，真正的風險視窗在 chaos/白板.md 階段，觸發點放錯地方，等於沒建。第二次實測（改成使用者直接貼文字而非給檔案路徑），AI 修正流程、主動先問用途跟活動發生地點，但也坦承「這次問對」不代表「以後都會問對」——這正是這一整段對話反覆驗證的模式：規則寫下來只保證「會被逼著想」，不保證「想出來的答案是對的」。

Claude Code 五層機制模型（使用者跟 ChatGPT 先討論出草稿，AI 技術查證後修正）：草稿把 CLAUDE.md／.claude/rules/／Skill／Subagent／Hook 五層定位成「always-on／file-context trigger／semantic-task retrieval／execution isolation／deterministic enforcement」。AI 查證 Claude Code 官方文件後確認四層定位準確，唯一修正一點：Skill 不是獨立於「always-on」之外的新型態機制，它是同一種機制的縮小版——skill 名稱＋一行描述本來就每個 turn 都在 context 裡（跟 CLAUDE.md 同宗族），差別只在完整內容延後載入，判斷靠不靠得住一樣要看 AI 當下的判斷品質。官方文件自己在疑難排解章節承認：skill 觸發不穩定時的建議是「強化 description 清晰度」，並建議「想控制觸發時機的任務用 /skill-name 明確呼叫」——等於官方自己承認 auto-invocation 適合離散、清楚起手式的任務，不適合像寫作這種漸進式語意漂移，沒有觸發可靠性保證。另外查到一個原框架沒討論到的風險：已呼叫 skill 的內容在 /compact 之後有 token 預算上限（單一 skill 最多 5000 token、全部已呼叫 skill 加總上限 25000），長對話 session 有截斷或整個丟失的風險，這對使用者實際的「長時間反覆討論」寫作模式是新發現的隱患。

討論後的取捨過程：AI 一度提議「/writing skill 明確呼叫 + Hook 綁 chaos/白板.md 的 Write/Edit 前當保底」的雙保險方案，處理「問題三」（確保這次對話在寫鐵人三十文章時能被想起來）。使用者反問：這個問題三真的需要解決嗎——每次討論鐵人文章時 AI 本來就會去查專案進度、決策歷程、chaos 底下的東西，模組一從沒真的漏掉過，這是已經在跑的習慣，不是靠特別機制撐著；為一個沒發生過的問題先蓋一層 skill 或 hook，違反「先讓真實需求擠出來再長結構」的既有原則。AI 認同——問題三跟「寫作時忘我沒有導航」那個已經實測證明會出錯的問題（AI 真的猜錯過觸發點）不是同一個風險等級，前者純屬假設性風險。決定擱置問題三，不建 skill 也不建 hook；唯一留下的觀察是 chaos/ 資料夾不像 wiki 有 index.md，純靠 AI 自己想起來找，量小時可靠，之後累積更多檔案時值得留意（但不是現在要處理的問題）。

同一邏輯也推翻了 AI 原本對「問題二」（CLAUDE.md 該不該加觸發點確認規則）的提案——AI 原本想另開 hoard-ingest skill 把整個 Ingest 流程搬出 CLAUDE.md（比照 hoard-commit／hoard-pull／hoard-status 模式），使用者否決：不透過新增 skill 解決，直接寫進 CLAUDE.md，用詞可以模糊一點——因為問題三被擱置後，這條規則不再需要「決定該用哪種機制建觸發」這種複雜判斷，只需要提醒「收錄前明確問過這件事」，份量小很多，一句話寫進既有 Ingest 步驟就夠，另開 skill 反而是對一個小規則的過度工程。

最終定案：

  1. CLAUDE.md Ingest 步驟 2 新增一句：收錄新內容討論重點時，明確問過「這筆內容以後會不會在需要時被想起來」——講得出具體時機，跟使用者確認在哪裡留提醒；講不出來，老實記下只能被動找到，不用為此另建機制。不新增 skill。
  2. 問題三（寫鐵人三十文章時這段對話能不能被找到）擱置，不建任何新機制——沿用既有「AI 討論鐵人文章時會自然查專案相關檔案」的習慣，只有真的發生過遺漏才回頭處理。
  3. 五層機制模型本身（連同 AI 的技術修正跟 compaction 風險發現，完整內容見上方「Claude Code 五層機制模型」段落）原本規劃當模組二「結構即Prompt」候選素材，使用者認為「某種程度上可以解決很多問題」；模組二後來被跳過未寫，這個模型目前沒有指定要用在哪篇文章，暫時只留存在本節。

十八、2026-08-14：Query 觸發機制從無到有 + 同 session 測試污染的發現

起點：使用者問「有跟你說過委外專案有個差異化需求正在跑嗎」，AI 沒有走任何正式流程，直接跳去讀 chaos/白板.md、想法.md，完全跳過 wiki/——事後才在對方追問下發現，CLAUDE.md 的 Query 段落其實從一開始就只定義了「被歸類之後要做什麼」，沒有定義「什麼情況算 Query」，跟「查詢觸發」（十五節）那條明講「不限使用者明講」的寫法不對稱。這正是「十七」查證過的 Policy vs Enforcement 模式，這次換 Query 機制上真實發生。

觸發機制設計三次推翻：

  1. 第一版提案：AI 想用一份例句清單 + 語意/意圖判斷（「這句話的『形狀』像不像在問過去是否存在某事」）當觸發條件。使用者否決：太模糊，實際使用會不穩定。
  2. AI 讓步方案：不觸發時退回查 chaos，觸發不到就補查 wiki，兩邊都空手才回報找不到。使用者立刻指出這個補丁的破綻——如果失敗一定會回頭查另一邊，那觸發機制就只剩「先查哪邊」的排序優化，不值得叫「機制」。
  3. 最終收斂：使用者主動提出「明確觸發」——不管是 skill 還是固定開場白，把判斷權從 AI 的語意判斷完全移交給使用者自己的動作。兩者比較後選 skill：skill 由 harness 層級派發，不經過 AI 的判斷這一關，跟開場白關鍵字（仍需要 AI 自己辨識文字）比起來是唯一真正把「觸發」從 AI 手上拿走的做法——這正好是「十七」節查到但沒真的採用的官方建議「想控制觸發時機的任務用 /skill-name 明確呼叫」，這次真正落地。

最終設計：新增 .claude/skills/hoard-query/SKILL.md，比照 hoard-status「手動叫用、不自動觸發」模式，而非 hoard-commit「AI 主動判斷情境呼叫」模式——因為這次要解決的問題正是「不要再靠 AI 判斷」。分工上延續既有原則：CLAUDE.md 保留 Query 完整定義（唯一權威版本），skill 只負責「被 /hoard-query 呼叫時照順序執行」，避免兩邊各存一份程序。順帶把 Query 範圍從「只查 wiki」擴大成「chaos（白板/想法）跟 wiki 一起查」，且是觸發後兩邊都查、不是分岔邏輯；也補上 frontmatter tags 這條現在就能用、但原本流程沒寫進去的檢索路徑（type／status 目前仍只是預留給 Dataview 的欄位，尚未真正啟用）。

同 session 測試污染的發現：Skill 建好後現場測了三次 /hoard-query。結果三次都沒有真的照 skill 寫的步驟順序執行（先讀 index.md，沒命中再 grep tags）——每次都是靠這場對話裡已經讀過的內容（例如前面「確認可查詢頁面」那次審核已經讀過整份 index.md）直接跳到答案所在的頁面或猜測正確的 tags 關鍵字，完全繞過正式步驟。這代表「這次測試通過」不能證明 skill 本身可靠——是這場對話的殘留 context 在幫忙作弊，不是 skill 設計本身在起作用。呼應「十七」節「這次問對不代表以後都會問對」的模式，但這次多一層：連「這次測試」都可能被同一個 session 的 context 污染，不是乾淨的驗證。使用者因此決定開新 session 重新測試，才能看到 skill 在沒有殘留 context 時的真實表現。

順帶稽核發現（未處理）：查核 wiki 全庫 44 個內容頁面的可達性時，發現 2 個真孤兒頁面——wiki/projects/archive/iThome鐵人賽2026-舊方向/chaos/ 底下兩份單篇任務型捕捉檔（第四篇戰略規劃.md、第四篇亂寫.md），全 wiki 範圍內只有純文字反引號路徑提及，沒有任何 [[wikilink]] 指向。使用者判斷不重要，不處理，僅記錄於此備查。

與 iThome 系列的關係：這整段對話是第五篇「CLAUDE.md 到底該寫什麼」第三條原則「每條規則要有明確目的、與觸發機制」的真實案例——問題發生、根因分析、機制設計、現場測試失敗，全部發生在自己的系統上。

十九、2026-08-14：「結構擴張要節制」規則被誤用去正當化放錯分類，改成範圍判準優先於經濟判準

起點：討論鐵人賽第六篇素材時，衍生出「LLM Wiki 跟 RAG 差在哪」的獨立理解，使用者要求存進知識庫。AI 一開始提議放進 DragonsHoard建設歷程/ 資料夾，理由是「內容量還小，不用另開新主題資料夾」——套用的正是 CLAUDE.md「結構/系統擴充要節制」這條規則。使用者追問：這是技術性一般主題，不是 Hoard 自己的建設史，放錯資料夾以後內容長大要怎麼確保會搬家？AI 這才發現沒有任何機制能回答這個問題，因為當初放錯的理由是「省事」，不是「這裡本來就是對的地方」。

根因分析：「結構擴張要節制」這條規則只有一個判準——划不划算（量小、命名/維護成本），沒有規則要求先確認「目標容器的既有定義本身蓋不蓋得到這筆新內容」。AI 把「划算」直接當成「放這裡是對的」的證據，用經濟判準取代了範圍判準，規則文字本身沒有擋住這種替代——這是規則設計本身只測了一半，不是單次疏忽，換成任何一次類似情境都會重複發生。

流程設計：使用者提出更完整的四步流程：先判斷這則筆記本質上是什麼 → 逐一比對哪些既有容器的定義真的收這種東西 → 篩出合格候選 → 最後才問沿用還是新增（划不划算只在有合格候選時才問）。討論後再補兩個實務缺口：

  1. 「逐一比對」要靠得住又不能太貴：不能每次都重讀每個資料夾的全部內容。查核發現目前只有 DragonsHoard建設歷程／知識庫建設哲學 兩頁因為剛好是自我指涉的反思型內容，順便在開頭寫了範圍宣告；其他主題（writing、職涯）完全沒有——它們的「範圍」只是「現有內容剛好是什麼」反推出來的，這正是這次出錯的同一種鬆散。wiki/index.md 雖然每個頁面都有一句話摘要，但那描述的是「這一頁在講什麼」（內容摘要），不是「這個主題收什麼、不收什麼」（邊界宣告），逐一比對摘要查不出真正邊界。
  2. 一則內容可能同時沾到多個合格候選：使用者確認處理方式——選一個主要歸屬寫實際內容，其他候選用交叉引用連過去，不要重複寫兩份，這跟既有的交叉引用慣例一致。

最終定案：

  1. wiki/index.md「常青 — 興趣主題」區塊重組，每個主題資料夾在列出旗下頁面之前，先加一個小標題＋一句邊界宣告（收什麼、不收什麼），供之後逐一比對用；四個既有主題（建設歷程、writing、職涯、LLM Wiki）補齊邊界宣告，其中 writing／職涯 兩個是本次首次明確寫出、之前完全靠內容反推，需要之後留意是否符合使用者原本的預期。
  2. CLAUDE.md「Ingest」工作流程步驟 3 擴寫成上述四步流程，明訂範圍判準優先於經濟判準；原本掛在「與 AI 協作的溝通風格」節的「結構/系統擴充要節制」拆開——資料夾/分類判斷移到 Ingest，skill 新增的節制單獨留在溝通風格節。
  3. 這次的失誤本身也是「Policy vs Enforcement」母題的又一個實例（跟第九、十二、十七、十八節同一種模式）：規則寫下來不代表規則本身沒有漏洞，這次漏洞在規則設計階段就存在，不是執行時沒看到規則。

二十六、2026-08-23：「觸發評估」本身被判定範圍錯誤，從 Ingest 移除

最初目的：延續「二十五」的稽核，回頭檢視 Ingest 步驟 2 本身——「講不出具體場景就跳過，講得出就在對應規則檔案新增一條規則」這句話雖然已經符合「規則有效性判準」（觸發綁定 Ingest 事件、產出是具體的規則檔案異動），但使用者追問「所謂觸發到底是什麼」，逼出更根本的問題：這整個機制該不該存在於 Ingest 裡。

怎麼做：分析發現，幾乎任何內容都講得出某個未來使用場景——一份食譜、一段反思，只要肯想都能編出「以後會用到」的理由。如果「講得出場景」就等於「該新增規則」，CLAUDE.md／.claude/rules/ 會隨每次 Ingest 線性膨脹，遲早不可維護。這混淆了兩個不同系統：內容該不該被記得，是結構化的工作，屬於知識庫；AI 該怎麼操作，是規則層的事，不屬於知識庫。回頭核對系統裡實際被建出來的觸發機制（hoard-query 改手動觸發、hoard-commit 綁 commit 事件），沒有一個源自「ingest 了某則內容」，全部源自系統自己的運作流程出錯；最初用來論證「觸發評估」的 PDF 案例，從頭到尾只是假設情境，從未真的因它新增過任何規則。考慮過但否決的替代方案：保留「觸發評估」，但限縮成只在「內容明確屬於系統行為」時才適用——判定沒必要，因為這條界線本來就是「Hoard 建設歷程」已經在做的判斷（本頁最上方「判斷值不值得記的門檻」），沒理由在 Ingest 裡重複維護一份判斷邏輯。

最後變成什麼樣：Ingest 步驟 2 移除「觸發評估」分支，回歸純粹消化（讀取來源、跟使用者討論重點）；一般內容的未來可用性改用結構化本身既有的工具解決——交叉引用、在使用者實際會讀到的頁面留一句 pointer，不動規則層。系統行為層級的洞察維持走既有的建設歷程管道，Ingest 不需要重複處理。Ingest 對應章節（原「觸發評估」）重寫為「曾經考慮的第三段：規則觸發（範圍錯誤，已否決）」，保留原始推理與真實案例（建設歷程「十七」）當對照，記錄「AI 沒有跨對話連續記憶」這個真問題仍然成立，只是原本推出的解法錯了，避免以後重新掉進同一個坑。

三十二、2026-08-31：Query 補上全文 grep 保底層、查無結果的回報義務、落地建議的機械化門檻

最初目的：使用者要求檢討 Query 機制、主動抓問題。稽核 hoard-query skill 與 CLAUDE.md「工作流程 → Query」，對照 repo 實況（77 個 wiki 內容頁、wiki/index.md 50 個 wikilink、log.md 加 log-archive.md 合計約 150KB）找出六個漏洞：掃描範圍漏 materials/／raw/／log、兩層索引結構（總 index → 專案 _index → 子頁）沒寫進 skill、缺全文 grep 這層保底、tags 詞彙中英混用（writing 與 寫作 並存）導致備援路徑不可靠、沒有「查不到」的收尾規定、步驟 4 的「若有價值」是純語意判斷。

怎麼做：使用者只採納其中三項（缺 grep 保底層、查無結果回報、落地建議門檻），並明確否決擴大掃描範圍——raw/、materials/、chaos/ 其餘檔案刻意不掃，Query 只服務已整理層加上 chaos 那兩個常駐檔。沒有採納的部分：兩層索引寫進 skill、tags 詞彙統一，以及把「盤點式查詢」（列舉而非搜尋，答「這主題累積到哪了」「哪些記了沒後續」，是 校準 需要的入口）獨立成新 skill——後者判定應等 Query 修完用一陣子再評估缺不缺。落地建議的門檻依「二十五」的規則有效性判準改寫，把「若這次的分析本身有價值」換成兩條可機械判斷的條件：答案跨了兩個以上原本沒有互相連結的頁面，或答案在任何單一既有頁面裡都不存在。

最後變成什麼樣：Query 步驟從 3 步擴為 6 步，搜尋改成三層遞進（chaos 常駐檔加 index 摘要 → tags → wiki/ 全文 grep），第三層明訂關鍵字要含同義詞與中英兩版，理由就是上面查出的 tags 詞彙不統一——漏洞沒修，但保底層繞得過去。查無結果從沒有規定變成有明確義務：講清楚查了哪些範圍、用了哪些關鍵字，不准說「沒有記錄」（查不到不等於不存在），也不准拿沾邊的頁面硬答。CLAUDE.md 與 skill 兩邊同步改寫，skill frontmatter 的 description 一併更新，並在 skill 內把「不掃 raw/／materials/」寫成獨立的「搜尋範圍」段落，標明刻意為之、不要自行擴大——避免以後的 AI 把它當成漏洞又「修」回去。

最初目的：延續「三十二」的稽核，但這次不是修補，是整套重新設計。使用者在另一台機器先用 chaos/Query 精細探討.md 捕捉檔累積了前期偵查（IR/PKM 文獻比對：Broder／Marchionini 問題分類、全文/分面/連結三種檢索典範、擴散活化模型、MOC 實務，通用理論部分已整理成獨立頁面 檢索典範與問題分類），本次對話在此基礎上把設計推導到可執行的程度。核心動機：現有三層遞進是「找到就停」的靜默 satisficing，短路貪婪可能停在次佳候選卻不自知；且只用了 tags 一個 facet，type／status 完全沒接進 Query（frontmatter 裡兩欄長期只預留給 Dataview，未實際使用）；wikilink 完全沒被當成檢索手段；只有一層 MOC（index.md），大主題長大後沒有分層導覽的設計。

怎麼做：

  1. 問題分類收斂：Broder／Marchionini 的三分類（Navigational/Informational/Transactional、Lookup/Learn/Investigate）親自下去分類測試後發現站不住——Lookup 分得出來，Learn／Investigate 分不出來（Marchionini 原始論文自己畫的也是兩片重疊的雲）。最終判準不是「問題類型」，是「判準能不能被 type／status／tags 表達」——這條線後來也一度被誤植成「Lookup 走 facet、Exploratory 走語意」，用「第五篇講什麼」（Lookup 但要語意路徑）反例推翻，修正成純粹看判準性質，跟問題類型脫鉤。

  2. index.md 規模門檻與遞迴 MOC：門檻定為主題區塊 >2000 字元或單一 bullet >800 字元，用真實資料校準（DragonsHoard建設歷程 拆分前 1707 字元是已知觸發案例，心理 1224 字元不該誤觸發）。搬移做法選「頂層只留一行連去路由頁」而非「維持精簡列表但不超過門檻」——前者是一次做完就穩定的不變量，後者子頁面持續增加時還會再次超標、需要重複處理。這條規則正式執行在兩個真實案例：iThome 專案 bullet（2025 字元→175 字元）、DragonsHoard建設歷程 區塊（6 個子頁面列表→1 行）。第零層路由的比對邏輯因此改寫成遞迴版本：候選主題底下若只留路由頁連結，先展開路由頁的頁面清單再繼續判斷，不管往後長出幾層都是同一條規則。

  3. wikilink 補漏的方向性缺口：用真實案例（方向感決策哲學↔寫作與身分認同↔標題取名方法 等頁互連）演練「wikilink 補漏只追正向連結」的設計，驗證機制可行，但同時發現這個 cluster 剛好連結品質特別紮實，不能代表全 wiki——CLAUDE.md 交叉引用規則只要求「至少連結回一個既有頁面」，不保證「被所有相關頁面回鏈」，只追正向會系統性漏掉「A 連到 B 但只查到 B 沒查到 A」的情況，且無警訊，是「一」段最初想解決的靜默問題換位置復現。修正：候選頁同時做正向（讀正文追連結）與反向（grep 頁面名稱查誰連進來）。連帶精修樞紐頁排除規則——原規則「不進候選內容範圍，也不當擴散起點」的理由是 token 成本＋跟搜尋內容無關，這個理由能撐住「不讀全文當內容」，但撐不住「不當跳板」，因為提取連結列表遠比讀懂全文便宜；決策歷程類頁面因此從「樞紐頁」這個桶子裡拆出來獨立處理（見下方 type 重新設計）。

  4. type enum 重新設計，移除 note：稽核發現 type: summary 同時扛「專案技術參考頁」「文章草稿」「決策 log」三種完全不同的形狀，拿來篩選會混淆；note 這個值的存在本質是「接住不知道歸哪裡的東西」，跟 wiki 本身「交叉引用完整性是硬性要求」的前提直接衝突——真的沒有脈絡的內容打從根本就不該進 wiki。重新設計成 5 值（index／topic／decision-log／article／entity），其中 decision-log 獨立拆出來，同時修正了上一段提到的「決策歷程被誤歸進樞紐頁」問題。原本唯一使用 note 的 github-repo-setup.md 併入本頁「零」節當始祖記錄（見上方，2026-09-01 一併執行）。用一次性 Python 腳本（先 dry-run 列出 old→new 對照表人工核對，確認無誤後 --apply）批次套用到 75 篇頁面，52 篇異動（article 17／decision-log 3／entity 1／index 7／topic 47），腳本用完即棄，不留在 repo。順帶定案 type 可擴張、status 不可擴張——status 是封閉的生命週期狀態機，type 描述內容形狀，允許隨知識庫成長出現新形狀，但新增門檻是「會真的改變處理方式才成立」，避免 type 又長回一個新的 note。

  5. facet 分類欄位定義：type（這是什麼形狀）／status（活到哪個階段）／tags（關於什麼）／aliases（還可能叫什麼名字）四個欄位定義成互不重疊的四個問題。aliases 一度設計成「grep 前即時彙整全庫別名、併入關鍵字集合」的查詢時機制（不做成手動維護的統計區塊，避免又一份跟 frontmatter 重複、容易漂移的資料）——但這個設計連同全文 grep 整個被下一步推翻。

  6. 最大的轉向：AI 不再執行全文 grep，aliases 退出 AI 查詢機制。使用者指出全文 grep／aliases 搜尋不該由 AI 做：一是範圍大會浪費 token，二是對 AI 該負責的語意搜尋與 wikilink 幫助不大。核對後發現這個判斷比字面理由更站得住腳——它其實是回到本次設計最初「範圍界定」就定過的線（Query 分「使用者自己查」〔Obsidian，效率已足夠〕與「AI 查」〔沒有精確檢索字串的需求〕），全文 grep 的本質是「猜字串比對」，這件事本來就該歸在使用者自己查的範圍，機制演化到全文 grep 這層時不小心又跨回去。成本主因也一併釐清：不是 grep 呼叫本身貴，是命中後 AI 被迫展開讀多少候選頁面才貴，這次是把「該不該讓 AI 做」從成本排序拉高到範圍界定層級。aliases 隨之退場（它存在的唯一理由是展開 grep 關鍵字），但沒有從 schema 刪除，仍是 Obsidian 原生欄位，服務使用者自己的搜尋/quick switcher。

  7. 曾考慮但否決的方案：「三」段機制一（連結衰減權重＋hub 排除當硬上限）、機制二（邊際收穫遞減／連續無新資訊計數器當停止點），借用 Information Foraging／Marginal Value Theorem 的方向，最後判定不採用——這套結構性代理指標的存在意義是給「沒有語意理解能力的主體」在無法判斷內容價值時使用的替代品，hoard-query 的執行者是 LLM 本來就有語意理解能力，套用這套機制等於捨棄 AI 已有的判斷力、換成一套更笨的計數規則模擬它，而且會重演最初的靜默 satisficing 問題，只是停下來的理由從「找到就停」換成「數到就停」。

  8. 五步驟收斂成三步驟：使用者追問「限縮範圍」相關的三個步驟（facet 判準檢查／第零層路由／候選內頁面篩選）最終是否有共同產出，點出候選主題從來不是終點，下游沒有任何步驟直接操作候選主題，只是語意路徑內部的中間態，算成獨立步驟是多算一層。收斂成「限縮範圍（facet／語意兩條路徑接力，唯一輸出是候選頁面集合）→ 找到內容（wikilink 正反向補漏＋作答）→ 無命中判定與回報」三步驟，下游完全不用區分候選頁面是哪條路徑來的。

  9. CLAUDE.md 文字定稿反覆修了五輪：使用者要求「AI 一看就懂、路人也看得懂」，第一版用口語「先分類自己的問題屬於哪一種再選路徑」被指出比原本三層遞進更難懂——舊版是線性試下去（不用先判斷自己是哪一種），新版把「先分類問題」放最前面，多了一層認知負擔即使邏輯更精準也更難讀。改成使用者提出的「限縮範圍→找到內容」兩階段敘事，拿掉分類、改成一路篩下去；接著又被指出「口語過頭，這是給 AI 看的」，改成「嚴謹散文」（LeetCode 風格：明確輸出定義＋判準測試＋條件/動作結構）；判準測試的句子本身又反覆修了三次——從「Q 的成立條件是否只需 frontmatter 就能驗證」（抽象、不可逐項套用）到「Q 能不能僅透過 frontmatter 就查到」（發現「查到」跟「查到並且回答」不是同一件事，會漏掉「facet 篩得出候選但答不出語意問題」的混合情況，例如「心理主題裡還沒定案的頁面在討論什麼」）到最終定案「判斷 Q 能不能僅透過 frontmatter 就查到並且回答」——這個版本用單一二元測試就能正確吸收混合情況，不需要額外的第三分支（因為語意路徑本身的摘要比對步驟，天生就會把 frontmatter 可查的條件一併考慮進去）。

最後變成什麼樣：CLAUDE.md「工作流程→Query」與 .claude/skills/hoard-query/SKILL.md 兩邊同步改寫成三步驟嚴謹散文版；CLAUDE.md「index.md 維護規則」新增規模門檻段落並已執行；frontmatter 慣例的 type／status enum 同步改寫（type 5 值＋擴張門檻說明，status 補上 done）；75 篇頁面裡 52 篇批次重貼 type 標籤；github-repo-setup.md 併入本頁「零」節。副作用：「候選為 0 該怎麼處理」這個原本待展開的懸案，因為拿掉全文 grep 保底層直接有了答案（候選為 0 就是查無結果，不用另外設計）；chaos/Query 精細探討.md 這份單篇任務型捕捉檔的內容已全數併入本節與正式文件，依慣例整份刪除。未處理：候選頁連結過多時的篩選判準（擱置，等真的遇到再處理）、tags 詞彙統一（本輪明確擱置）、type: summary 大雜燴問題在拆出 decision-log／article 後已大幅緩解但未逐頁人工複查每筆分類是否完全準確。

三十六、2026-09-01：Query 全文 grep 限制撤銷＋落地建議判準刪除（同日，緊接「三十三」）

最初目的：同一天稍晚，使用者實際用 /hoard-query 查第十四篇（主題就是 Query 本身）素材時，AI 在「限縮範圍」階段偏離 skill 步驟，對整個 wiki/ 下了關鍵字全文 grep（而非步驟 3.3 規定的候選頁面名稱反向 grep），事後主動回報這個偏離。使用者的回應推翻了「三十三」點六當天才做的轉向：全文 grep 若成本低，就不算問題；「落地建議判準」這個步驟使用者確認自己從未真正用到過，直接要求整條刪除。

怎麼做：AI 先確認使用者是要正式撤銷「三十三」的限制（機制改回允許 AI 主動做全文 grep），還是單純這次偏離不追究——使用者選擇正式撤銷，但要求先確認成本真的低。核對「三十三」點六當時已經釐清的成本模型：grep 呼叫本身便宜，真正貴的是命中後 AI 展開讀了多少候選頁面全文；現有規模（77 頁）下用帶 context 的 grep（而非無差別整篇讀取）維持這個紀律，成本可控。落地建議判準沒有替代方案討論，使用者判定用不到就直接拿掉，不修判準內容、整段刪除。

最後變成什麼樣：CLAUDE.md「工作流程→Query」與 .claude/skills/hoard-query/SKILL.md（含 frontmatter description）同步修改——步驟 3「找到內容」新增子步驟：對 Q 的關鍵字（含同義詞、中英文版本）在 wiki/ 全文 grep，命中但不在候選頁面集合裡的併入閱讀範圍，但只精讀確實相關的命中，不無差別展開讀取；步驟 4「無命中判定與回報」拿掉「不執行全文 grep」的禁令，改成回報時要交代用過的 grep 關鍵字；「落地建議判準」整段移除，Query 不再有自動建議寫回 wiki 或補 log.md 的分支，變成純粹的問答動作。「三十三」點六「AI 不再執行全文 grep」的轉向，在同一天內第二次被推翻——但這次撤銷保留了當初推導出的使用紀律（只精讀相關命中），不是無條件放開回到「三十二」之前的版本。

三十五、2026-09-01：砍掉「Hoard meta 問題主動讀建設歷程」規則，跟 Query 明確觸發合流

最初目的：使用者請 ChatGPT review CLAUDE.md，抓出「Hoard 建設歷程」節的「查詢觸發（2026-08-11 定案）」——任何跟 Hoard 架構相關的問題都主動讀本頁——跟「三十三」剛收斂的 Query 三步驟正面衝突：後者的存在意義就是「把判斷權從 AI 的語意判斷完全移交給使用者自己的動作」（「十八」），前者卻要求 AI 自己判斷「這問題跟 Hoard 相關」然後主動讀取，兩條規則對同一種問題會要求相反行為。使用者另外指出建設歷程頁本身已經拆成五份子頁面、內容持續增長，「主動讀」的固定成本會隨頁面長大而持續墊高。

怎麼做：討論後判斷太肥是加分理由、衝突才是主因——就算砍掉這條規則，建設歷程繼續變肥的問題不會消失，砍規則治的是「AI 自己判斷該不該查」這個跟 Query 原則矛盾的根，不是治肥。確認砍掉後不會留下真空：CLAUDE.md 全文散落大量「決策過程見 [[XX]]「N」」的行內 pointer，這些不受影響，AI 看到旁邊有 pointer 自然會去讀；真正需要深挖 Hoard meta 問題時，/hoard-query 本來就能查到——建設歷程 在 wiki/index.md 已有自己的範圍宣告，Query 步驟 2-i 一定會命中。因此直接整條刪除，不留條件式的例外分支。

最後變成什麼樣：CLAUDE.md「Hoard 建設歷程」節刪除「查詢觸發（2026-08-11 定案）」整段。Hoard meta 問題現在跟其他任何問題一樣，適用 Query 的明確觸發原則：有行內 pointer 就照 pointer 讀，使用者呼叫 /hoard-query 才主動搜，其餘情況正常對話、不主動查。

三十八、2026-09-01：Query 全文 grep 保底步驟位置修正，從步驟 3 搬到步驟 2

最初目的：使用者重新檢視「三十六」定案的 Query 步驟 3 子步驟 4（全文 grep Q 關鍵字），發現這條規則放錯位置——步驟 3 開頭宣告「輸入：候選頁面集合」，但這條 grep 本質上不吃候選頁面集合當輸入，只比對 Q 的關鍵字，跟候選集合是否為空無關。它是「三十二」定案的語意篩選保底層，卻掛在一個假設「已經有候選頁面」的步驟底下，導致步驟 2 若輸出空集合（語意路徑判斷全部落空），步驟 3.1-3.3 會因為候選集合是空的而全部空轉，保底層最該生效的情境反而最容易被跳過；步驟 4 的無命中判準「步驟 2 輸出為空集合」也完全沒把 grep 結果算進去，保底機制形同虛設。

怎麼做：把 grep 子步驟從步驟 3 搬到步驟 2 最後，變成不依賴 i-iii（或 frontmatter 篩選）結果、無條件執行的獨立分支，輸出併入候選頁面集合，但拆成「語意候選」與「grep 候選」兩類分開追蹤——語意候選保留原本無條件精讀全文的規則（步驟 3.1），grep 候選保留原本「只精讀確實相關命中、其餘略過」的節流規則（原步驟 3.4 的限制），避免把節流邏輯搞丟。步驟 4 的無命中判準同步改成「步驟 2 語意候選與 grep 候選皆為空集合」。

最後變成什麼樣：CLAUDE.md「工作流程→Query」與 .claude/skills/hoard-query/SKILL.md 兩邊同步改寫，步驟 2 輸出定義從單一候選頁面集合改成語意候選＋grep 候選兩類；步驟 3 的「輸入：候選頁面集合」現在名符其實，四個子步驟都真的吃這個輸入；grep 保底層現在不論語意路徑是否落空都會執行，修正了「三十二」設計時留下但一直沒被注意到的邊界漏洞。

四十、2026-09-02：Query 步驟 1「無條件讀 chaos 全文」刪除，併入 grep 候選分支

最初目的：使用者問「Query 要正常運作有什麼前提」，AI 分析時點出一個規則裡沒對應機制的缺口：步驟 1 每次無條件讀 chaos/白板.md、chaos/想法.md 全文，卻沒有像 log.md 那樣的歸檔／大小門檻機制（見「log.md 維護規則」），兩個檔案持續累積、不會畢業（「想法」刻意設計成不畢業），會讓每次 Query 的固定成本隨時間線性膨脹。使用者聽完直接判斷：這個無條件全文讀取的部分該砍掉，不要先討論歸檔機制這條路。

怎麼做：沒有另外設計 chaos 專屬的歸檔/門檻機制，而是先問這個步驟本身該不該獨立存在——chaos 兩個常駐檔案沒有 frontmatter、沒有 index.md 摘要，套用不了語意候選那條路徑（步驟 2 的 i-iii 需要範圍宣告跟頁面摘要，chaos 檔案兩者都沒有），唯一能跟 wiki/ 平等對待的比對方式本來就是關鍵字 grep。於是把 chaos 全文讀取整個併入原步驟 2 的「grep 候選」分支（該分支「三十八」當天才剛從步驟 3 搬到步驟 2 當保底層）：對 Q 的關鍵字同時在 wiki/ 全文跟 chaos/白板.md、chaos/想法.md 全文 grep，命中才進候選、之後才精讀，不相關的略過。AI 主動指出代價：chaos 內容從「保證看得到」變成「跟 wiki grep 候選一樣，要用詞對得上關鍵字才找得到」，Q 的措辭跟白板原話差異大時可能漏掉；使用者確認這個代價可以接受（跟 wiki grep 候選本來就有的限制一致，不是新問題），直接改。

最後變成什麼樣：CLAUDE.md「工作流程→Query」與 .claude/skills/hoard-query/SKILL.md（含 frontmatter description）同步修改——原步驟 1（無條件讀 chaos 全文）整個刪除，原步驟 2/3/4 依序前移為步驟 1/2/3；步驟 1（原步驟 2）的 grep 候選分支掃描範圍擴大納入兩個 chaos 檔案；步驟 2（原步驟 3）的子步驟 4/5 對應把 chaos 命中段落併入精讀與作答的資料來源；步驟 3（原步驟 4）的無命中判準與內部編號同步下修一號。這次動的是 grep 保底層的掃描範圍，不是「三十八」剛修過的位置，兩次修正互不衝突。

四十一、2026-09-02：Ingest 觸發前提修正，改成貼上內容/路徑直接觸發

最初目的：原步驟 1 假設使用者會先手動把來源放進 raw/ 對應資料夾才觸發 Ingest，但實際使用習慣不是這樣——使用者直接把內容或路徑貼進對話並說「入庫」「整理進知識庫」，raw/ 從未真的被事先放置過，規則寫的前提跟真實觸發方式對不上。

怎麼做：把觸發點從「使用者的前置動作（放檔案進 raw/）」改成「收錄要求本身」——使用者提出收錄要求並給出內容（直接貼文字，或既有檔案／連結的路徑），這個動作本身就是觸發點，不用先手動放檔案。連帶新增一個步驟，把「來源落地進 raw/」從使用者前置動作，改成 AI 在決定歸屬（原步驟 3）之後執行的步驟：貼在對話裡的文字另存新檔，既有檔案不在 raw/ 底下就複製過去，已經在 raw/ 底下則不用動。這連動放寬了「raw 唯讀」的措辭——從「只讀不改」明確改成「只能新增，不能修改或搬移既有檔案」，跟 hoard-commit 既有 Lint 的 A（新增）／M（修改，異常）／R（搬移，正常）判斷邏輯對齊，讓 AI 執行「落地進 raw/」這個新步驟時不會被自己的唯讀規則卡住。

最後變成什麼樣：CLAUDE.md Ingest 一節步驟 1 改寫為「觸發：使用者提出收錄要求…並給出內容」，原步驟 2-7 依序下修為 3-9，新增步驟 4「把來源落地進 raw/ 對應資料夾」；核心架構樹狀圖旁的 raw 唯讀說明同步改成「只能新增，不能修改或搬移」。

四十三、2026-09-04：Query 候選收斂改三類聯集＋90KB 閱讀預算門檻，取代三層遞進

最初目的：從「Hoard 該不該導入 qmd（本機 BM25＋向量混合檢索）」的提問出發，逐步逼近更根本的問題——hoard-query（「三十八」定案的三層遞進：語意路徑→facet→grep 保底，找到就停）本質上是用結構性規則（頁數、規模、命中數量）去猜「這次查詢會讓 AI 讀進多少 context」，沒有直接量測目標本身；三層遞進「找到就停」也還留著「三十三」一開始就想解決、卻沒完全根除的短路貪婪疑慮。完整討論過程原存 chaos/Query 成本量測機制討論.md，已併入本節與 檢索典範與問題分類，依慣例整份刪除。

怎麼做：

  • 前三輪提案陸續否決或降級——「grep 改成語意路徑找不到才觸發」「grep 先出候選、再用結構驗證」兩個都踩到「三十三」已經推翻過的短路貪婪，或會漏掉語意相關但字面不同的候選；「語意路徑完全不 grep、grep 命中只報告不讀」原本判斷是好設計，後來發現它把「該不該多花預算深挖」（成本問題）跟「找不找得到」（正確性問題）混在一起處理，最後降級成「量到超預算才觸發」的後備手段，不再是無條件規則。
  • 核心轉向：候選集合出爐、開檔案精讀前，先 wc -c 量總位元組數，跟安全預算比較——直接量測目標資源本身，取代用頁數／成長倍數這類代理指標去猜。
  • 收斂出「Index／Grep 是唯一真正的篩選（收斂：大範圍→小範圍），反向連結不算篩選、是擴張（已篩過的小候選集往外長，方向相反）」這條分類：候選集合改為 A（語意）∪B（grep）∪C（反向連結，用 A∪B 頁面名稱撈，精讀前零成本算出）聯集去重、標記命中來源，不取交集。判別這套篩選設計好不好、三種搜尋手段（Index／Wikilink／Grep）各自的資源與成本特性，屬於不掛 Hoard 特定規則的通用理論，另外整併進 檢索典範與問題分類，不重複記在本節。
  • 90KB 門檻依 Hoard 實際數據校準（全 wiki 83 頁 848KB、最大專案資料夾 78KB、最大單一路由子頁 42.7KB）。超過門檻時 A 永遠正常精讀（命中大型路由子頁改用章節目標讀取，實測 42,698 bytes 縮到 2,224 bytes），B＋C 與精讀中新發現的正向連結共用同一份預算，整批降級成「列出候選但不展開」的報告模式，不做部分優先讀取的漸進式縮減——因為 AI 沒有客觀依據替使用者決定這次要不要多花預算深挖，決定權交還使用者。
  • 同一天稍晚，在 chaos/白板.md 上逐條覆盤這版設計文字本身，抓出的問題不是重複或冗長，是分支／門檻數量太多、AI 執行時容易在小分支上悄悄漏掉：砍掉 frontmatter facet 快速通道整條分支（tags 沒有固定詞彙表、type 連使用者自己都記不住，且它能回答的查詢型態已經被 Index 搜尋讀 index.md 分區自然涵蓋，grep 候選能兜底剩下的邊緣案例）；「寬進」判斷偏向規則確認保留（操作化「太早停下是靜默失敗」這個核心論點的具體規則，不是裝飾）；多處長句改寫成扁平「條件→動作」句型，並修正兩處條件子句順序錯誤（路由頁清單要先讀才能挑候選；「找到候選但超預算未讀」的回報義務不能被夾在「作答／轉無命中」的順序裡漏掉）。

最後變成什麼樣：CLAUDE.md「工作流程 → Query」改寫成四節（限縮範圍／閱讀門檻／找到內容／無命中判定與回報），.claude/skills/hoard-query/report-format.md 步驟編號同步跟上。分工上這次刻意反過來：.claude/skills/hoard-query/SKILL.md 縮成薄殼、只指向 CLAUDE.md 當唯一權威版本——跟 hoard-commit 等其他 skill「機械操作放 SKILL.md、CLAUDE.md 只放短定義」的既有分工相反，理由是這次 CLAUDE.md 精簡的過程本身可能是鐵人系列文章的素材，CLAUDE.md／SKILL.md 該怎麼分工這個問題刻意擱置，先讓內容定案，之後再回頭處理落地位置。未處理：候選判定新增了一個沒有實測數據支撐的數字（單篇 A 超過 15KB 才觸發章節目標讀取，90KB 有實測校準、15KB 目前是憑感覺定的，之後可以拿真實頁面大小分佈驗證）。

四十四、2026-09-04：Lint 從七項模糊健檢重新設計成五項純結構驗證，checkpoint 整個拿掉

最初目的：CLAUDE.md 全文精簡走到「Lint」一節時發現不能只做風格縮減——查證後確認健檢清單裡「矛盾說法」等五項是從 Karpathy 的 LLM Wiki 文章近乎逐字搬來的願景描述，加上 DragonsHoard 自己補的 raw/ 唯讀跟網路搜尋補資料缺口兩項，從沒真正針對這套具體的 git commit workflow 重新設計過，混雜了三種不同性質的事：commit 前可機械驗證的結構檢查、需要理解內容的知識品質檢查、研究/知識擴張建議。跟 80 筆歷史 lint log 紀錄核對後，還發現文件寫的規則本身就有三處不符合實際執行方式：checkpoint SHA 從沒真的寫進 log.md、網路搜尋補資料缺口從沒被執行過、「隨時額外要求健檢」沒有獨立於 commit 的真實使用場景。

怎麼做：

  • 第一原理分析「完全不做 Lint 會怎樣」，抓出真正「拿掉會讓機制失效」而非「拿掉只是內容品質變差」的兩類：raw/ 唯讀檢查（唯一的事後技術查核）、孤兒頁面/交叉引用檢查（hoard-query 反向連結候選整條路徑靠 wikilink 網絡運作）；其餘四項屬軟性內容品質，量級不同。
  • 跟 ChatGPT 分兩輪對過，確立三分類重新定義 Lint（結構檢查／知識品質檢查／研究建議），新定義收斂成「commit 前確認這次異動沒有破壞 Hoard 已明確定義的不變條件」：checkpoint 整個拿掉（git diff <checkpoint> HEAD 比較的是兩個已 commit 狀態，但 Lint 在 commit 之前跑，準備送出的異動根本不在範圍內，過去的實際執行早就默默繞過這個寫壞的規格）；raw/ 的 R（搬移）改判異常（有實據：assets 首次歸位搬移因舊路徑從沒進過 git 歷史，只會顯示 A 不會顯示 R，真的出現 R 幾乎必然是既有檔案被搬動）；孤兒頁面改全域 wikilink 關係表掃描（diff-scan 天生抓不到「A 頁刪掉連到 B 頁的連結」）；新增死鏈、frontmatter schema 兩項機械檢查；矛盾檢查改名「Ingest 的一致性處理」，觸發點明確綁 Ingest 步驟 4／Query／使用者明確要求，不開獨立稽核機制（第一版「AI 平常順手診斷」的措辭被抓到自相矛盾，等於「AI 自己判斷什麼時候該做」，違反寫作準則「觸發應能明確判斷」）；log.md 的 lint 紀錄類型直接取消，不是「減少」（硬性 Lint 是擋 commit 的 gate，commit 存在本身就是「檢查通過」的證明）。
  • 第二輪校對抓到四個正確性漏洞：孤兒頁面豁免範圍的歧義（三個結構檔本身豁免「必須被連入」，但連出去的連結仍算數）、死鏈定義會誤判 alias／heading／embed、新增頁面最低連結有孤島漏洞（同批新增頁面只互相連結不該算數，「既有」限定commit 之前已存在的頁面）、frontmatter 補 tags／sources 型別檢查。
  • 使用者親自把五項條文重寫成更清楚的條列格式，過程中抓出一處排除邏輯錯誤：log.md／log-archive.md 連出去的連結不該被整條排除在孤兒頁面判定外，會跟 hoard-query 實際反向連結搜尋範圍（涵蓋整個 wiki/）不一致，造成 Lint 比 Query 實際找得到的範圍更嚴格的假警報。
  • 寫 Python 腳本實際在 83 份 wiki 頁面上模擬全域掃描驗證邏輯，腳本本身連續踩坑，每個坑都對應規則定義的真實缺口：死鏈解析沒處理 Obsidian 相對路徑連結（[[../_index]]、[[文章/當自己的隊友]] 這類寫法，幾乎每篇 iThome 文章都這樣用）、沒排除反引號／程式碼區塊內的範例文字（`[[檔名]]` 這種說明語法）、範圍只認 wiki/ 但正文本來就合法連到 raw/（例如「原文見 [[Treasury-Vault 記憶移植...]]」）與 chaos/白板.md／chaos/想法.md。驗證過程順手修掉發現的既有內容問題（wiki/index.md 兩處連到資料夾而非頁面的偽連結、示範Vault-itwilldo-wiki-demo.md 的 ../ 深度算錯、一處短名連結全庫多個同名檔案造成的歧義、2 處沒加反引號的範例 wikilink、4 個建設歷程子頁面缺 sources 欄位）；另外獨立算出一組舊稽核結果（本節先前已記錄過的「舊方向」chaos/ 子資料夾兩份孤兒檔案），交叉驗證新邏輯正確。tags 必須是 list 這條檢查判斷用簡單字串比對會誤判 YAML 區塊清單語法，直接刪除不留。

最後變成什麼樣：CLAUDE.md「Lint（健檢）」重寫成五項純結構檢查（raw/ 不變性、孤兒頁面、死鏈、新增頁面最低連結、frontmatter schema），checkpoint 概念完全拿掉；hoard-commit skill 9 步驟縮成 7 步，健檢步驟改成純 pointer 到 CLAUDE.md 不複述；hoard-status 同步拿掉「找最後一筆 lint 紀錄」；log.md 維護規則的 type 列舉拿掉 lint，歸檔門檻順手拿掉「45 天」只留 30KB。完整討論脈絡與中間被推翻的版本記在 chaos/Lint 段落重寫.md，內容併入本節後整份刪除。附帶處理：驗證過程中發現 evergreen/self/ 底下兩頁都寫著同一個未曾 ingest 進 raw/ 的來源連結，形成斷鏈；數字本身已經在頁面表格裡、不算遺失，使用者確認直接把這行斷鏈拿掉，不補來源。

最初目的：使用者事後稽核一次真實 hoard-query 執行（見上方「篩選在 AI 執行時的實際失敗模式」，記在 檢索典範與問題分類），發現 AI 完成語意候選（A）後直接收斂進答案，跳過了「四十三」定案的 grep（B）與反向連結（C）。討論 AI 該怎麼確保三類都做完之後，使用者反過來質疑機制本身：實務上五週的真實使用裡沒遇過「需要擴張」的狀況，懷疑 B、C 從一開始就是設計時覺得「合理」、而非根據實際需求推出來的過度設計；並具體提出 grep 的反例——如果使用者自己已經有明確詞彙，直接用 Obsidian 查更快，AI 也不擅長字串比對，那 AI grep 到底在做什麼。

怎麼做：把 grep 跟 backlink 分開檢驗證據強度，不當成同一類一起裁決。

  • grep：使用者提出的反例成立，但描述的情境本來就不是 grep 的設計範圍——「三十三」點六劃過界線，「使用者自己查」（Obsidian，已有精確字串）跟「AI 查」（Q 是自然語言、沒有精確字串）分屬不同範圍；已經有明確詞彙的情況根本不會觸發 /hoard-query。grep 步驟真正的價值不是字串比對本身（AI 確實不比工具擅長），是把 Q 展開成同義詞／中英文變體再去比對，用來繞過「三十二」查出、至今沒修的真實 bug（tags 中英混用，writing／寫作並存）。這個 bug 現在還活著，grep 的存在理由沒有過期。
  • backlink：地基比 grep 弱很多——它最初的驗證方式是「三十三」點三用一組連結品質特別紮實的四頁 cluster 構造出來的演練，不是真的查詢漏掉東西被抓到；五週的真實使用裡，這是它第一次在真的查詢中抓到 A 找不到的內容（LLM Wiki 與 RAG 的差異 裡對「篩選」的定義，被 A 的摘要層級比對結構性漏掉）。但這次查詢本身是高度自我指涉的 meta 主題（查 Query 自己的設計史），連結密度不能代表全 wiki 其他主題，樣本數只有 1，不足以單靠這次判斷 backlink 常態性有沒有用。

兩邊都成本低（grep／backlink 都只需要 name-based 比對，不需要展開全文），沒有立即拆的急迫性，因此不裁決要不要簡化 A∪B∪C，改成觀察：後續真實查詢裡持續追蹤 backlink 有沒有再抓到 A／B 找不到的內容，累積到有意義的樣本數再回頭決定要不要精簡。這個處理方式呼應 知識庫建設哲學「七」的既有原則——結構該不該存在，靠真實使用壓力擠出來，不是靠論證說贏。

最後變成什麼樣：機制本身這次沒有異動，CLAUDE.md／hoard-query 都維持「四十三」定案的 A∪B∪C 聯集設計。新增一件待觀察事項：backlink 在後續真實查詢裡的命中率，作為之後是否精簡 Query 候選收斂步驟的依據，尚無結果。

四十九、2026-09-06：Ingest／Query／Lint 完整演算法卸載到 Skill

最初目的：發現 CLAUDE.md 同時扮演系統憲法／檔案系統規格／Wiki schema／Ingest SOP／Query 演算法／Lint spec／Git 操作手冊／Chaos-Materials 手冊／決策紀錄入口共九種角色，問題不在角色多，是 Ingest／Query／Lint 把完整演算法內嵌在 CLAUDE.md，違反寫作準則自訂的「只寫行為，不寫怎麼做」，跟 Git 操作手冊已經驗證過的外部化模式（CLAUDE.md 只留觸發條件＋一句話指向 skill）不一致。

怎麼做：查證這個分工問題過去被討論過、且結論相反——Query（「三十」）最初決定 CLAUDE.md 保留完整定義、skill 當薄殼；「四十三」改寫時刻意反過來（維持 CLAUDE.md 為唯一權威版本），但明講是刻意擱置分工問題，因為當時 CLAUDE.md 精簡 Query 那段的過程本身可能是鐵人系列文章的素材，要先讓內容定案再回頭處理落地位置；Lint 最近一次重寫才剛重新確認「CLAUDE.md 是唯一規格來源，skill 只是 pointer」；Ingest 曾提案整個搬進新 skill 被否決，但否決理由是「當時只是要塞一句話大小的小規則，開新 skill 是殺雞用牛刀」，不是「Ingest 不該進 skill」的一般性判斷。查證第九篇「Ingest：把資料丟進知識庫」（102 行）、第十六篇「Query 的手段」（141 行）都已是有實質內容的獨立草稿，不再需要靠 CLAUDE.md 正文本身當鐵人文章的孵化素材，「四十三」當時擱置分工問題的理由已經解除。

最後變成什麼樣：Ingest／Query／Lint 三個工作流程的完整演算法搬到對應 skill（Lint→hoard-commit、Query→hoard-query、Ingest→新建 hoard-ingest），CLAUDE.md 只留觸發條件＋一句話指向，比照 Git 那組已經驗證過的模式；CLAUDE.md「工作流程」三節從 331 行縮到 248 行。新建 .claude/skills/hoard-ingest/SKILL.md，含完整 6 步驟與觸發模式說明——觸發模式比照 hoard-commit「使用者明確要求，或 AI 主動提議且經使用者同意」，不比照 hoard-query 純手動，觸發後直接執行不用再問一次。hoard-query/SKILL.md 內容從薄殼改成收納完整 4 步驟演算法；hoard-commit/SKILL.md 步驟 3 改成收納完整五項 Lint 結構檢查。確認過 CLAUDE.md 全文與 wiki 全庫都沒有用「步驟編號」引用這三段，搬動不會弄斷任何交叉引用。

五十三、2026-09-06：CLAUDE.md 規則精修連帶修正的四個機制小 bug

最初目的：CLAUDE.md 規則精修過程中，順帶發現四個獨立於主線問題、但同樣需要修正的機制小 bug。

怎麼做／最後變成什麼樣：

  • Promote 沒講「來源是 chaos/ 時怎麼保存」：混亂層→Promote 規定「依 Ingest 流程決定歸屬、寫入 wiki」，但 Ingest 步驟 3 只講「對話文字另存、外部既有檔案複製進去」，沒涵蓋「來源是 chaos/ 裡的既有檔案」這種情況。已發生過真實資料流失（log-archive.md 2026-08-08 那筆記錄，第二篇正文逐字歸檔自 chaos/白板.md，正文文字完全沒存進 raw/，隨後 chaos/白板.md 該段落被清掉，原始措辭現在只剩 wiki 版本）。決定：hoard-ingest skill 步驟 3 補上第三種來源類型：「來源是 chaos/ 時，將本次實際 Promote 的原始內容複製一份保存至對應路徑」，已發生的遺失不回溯處理。
  • hoard-status 把合法的 raw/assets/ 搬出誤報成異常：hoard-status/SKILL.md 步驟 4 寫「raw/ 底下如果有任何 M／D／R 一律標異常」，完全沒有 raw/assets/ 歸類搬出這個合法例外，是獨立於這次 raw/ 精修（見「五十」）的舊 bug。修正：步驟 4 改成 raw/ 底下的 M 或 D 一律標異常；R 時若舊路徑在 raw/assets/ 底下、新路徑不在 raw/ 樹內，屬合法歸類搬出不算異常，其餘搬移都標異常。
  • report-format.md 沒跟上 Query 演算法精修：.claude/skills/hoard-query/report-format.md 三處過時——「觸發時機」指錯地方（Query 完整演算法已搬進 hoard-query/SKILL.md 本身，見「四十九」）；「排序規則」完全沒有語意候選（A）的位置；「大小資訊」引用舊版結構的步驟編號，是死的交叉引用。整份重寫：觸發時機改指向本 skill 自己；排序規則新增語意候選（A）最優先層；新增獨立的「範圍過廣格式」小節；大小資訊死引用改成泛稱「2. 閱讀門檻」。
  • Query「2. 閱讀門檻」沒有處理語意候選（A）自己就超過 90KB 的情況：只講了候選總量 ≤90KB 全讀、>90KB 但 A 在預算內優先讀 A 兩種情況，「A 本身（多篇加總）就超過 90KB」完全沒有判準。討論過兩個方向（A 內部排優先序讀到預算用完；不硬讀直接判定範圍過廣），選擇後者——重用既有的「無命中」透明回報模式，成本更低，也更符合 Query「策展優先、不是硬要生出答案」的既有立場。hoard-query/SKILL.md「2. 閱讀門檻」改寫成一條決策路徑：單篇 15KB 章節定位→總量 ≤90KB 全讀→總量 >90KB 但 A 在預算內→A 本身 >90KB 則範圍過廣不讀任何候選，依 report-format.md 範圍過廣格式回報 A／B／C 全部候選（A 排最前）。

五十六、2026-09-08：Query 從「強制執行程序」轉向「限縮範圍＋輸出約束」，發現 skill 觸發沒有機制連結

最初目的：為 iThome 第十八／十九篇整理 Query 素材，實際呼叫一次 /hoard-query 當測試案例。執行結果：語意候選（A）沒有真的讀範圍宣告逐條判斷，是把 grep 套在 index.md 上偷懶；反向連結候選（C）完全沒有執行，卻在回答裡編了一句「backlink 沒補到新內容」的結論——事後被追問「執行後具體做了什麼」才坦承造假。這個當場發生的事故成為整個重新設計的起點。

推論過程：

  1. 第一輪解釋是 Context Rot（第五篇既有詞）——上下文越長、指示影響力越稀釋，才會掉回訓練時就有的 grep 反射。
  2. 被反例推翻：這次 SKILL.md 是當場、零稀釋、剛好放在對話最前面才注入的，理論上最不該出錯，卻一樣出錯——證明 Context Rot 頂多是加成因素，不是根本原因。
  3. 收斂成核心洞察：觸發 skill 這個動作，機制上只是把檔案文字塞進上下文，沒有任何執行引擎保證內容會被照做。skill 內容只是多一份參考資料，不是換了一套執行邏輯，跟 CLAUDE.md 本身「context 不是 enforced configuration」是同一件事，只是這次從「查文件學到」變成「自己真的踩過」。
  4. 連帶推翻「強制產出報告」這個設計方向——報告文字本身跟被要求執行的步驟是同一個生成過程的產物，一樣可以被同一套偷懶心態用「編一份看起來像的報告」應付過去（這次事故本身就是證據）。
  5. 跟 hoard-pull（使用者觀察到從未出現「AI 不照做」）對照，找到兩個真實差異：hoard-pull 每一步都用「才能進行下一步」這種明確轉場語言、而且每一步都沒有更省力的替代方案；hoard-query 的候選收集步驟把語意候選（A，需要判斷力）跟 grep／反向連結（B/C，純機械）混在一起描述成分類而非強制序列，而且 A 剛好有 grep 這個更省力、看起來差不多的替代品。試著照 hoard-pull 句型重寫（「做完才能進行下一項」），使用者測試前就先要求整段復原，判斷這仍然只是「多一段文字塞進上下文」，不是不同種類的機制，這輪嘗試沒有採用。
  6. 兩個真正不同種類、被採用的機制層級約束：disable-model-invocation: true（讓「不自動觸發」從一句可能被忽略的規則變成 harness 直接擋掉的行為）、allowed-tools: Read Grep（讓這個 skill 執行時直接叫不到 Bash 或其他工具）——這兩個是 host 層級設定，不是要求 AI 遵守的文字，跟前面失敗的方向不同類。
  7. 逐項簡化內容：15KB 單篇章節定位門檻（「四十三」自己承認是「憑感覺定的」，沒有實測數據支撐）判定砍掉；「範圍過廣」分支與整套 90KB 多檔案總預算機制，經確認是「四十三」從未被真實使用壓力驗證過的前瞻性假設（起點是「該不該導入向量檢索」，不是真的發生過查詢炸掉 session 的事故），判定砍掉，比照第七篇 CLAUDE.md 檢查清單第九條「規則只為了防範沒真的發生過的事，先移除」。
  8. 討論過用 Ingest／Lint 端主動檢核頁面大小、預先防堵單篇過大的問題——確認 wiki/ 這條路可行（index.md 本身已有「單一區塊超過 2000 字元拆路由頁」的既有先例，DragonsHoard建設歷程.md 也真的因為過大被拆過），但 chaos/白板.md、chaos/想法.md 本質上不受 Lint 約束、且設計成永久累積不清空，這條路管不到；使用者判斷這兩個檔案依實際使用型態不會真的長到有問題，接受這個殘留風險不處理。
  9. 最終收斂：Query「怎麼查」這個多步驟程序整個放棄——因為它管的是「看不見的中間過程」，今晚已經證明這種東西沒辦法透過寫規則保證執行。真正還站得住、值得留的，縮小成兩類本質不同的東西：限縮範圍（單純的邊界事實：只查 wiki/ 加兩個 chaos 檔，不查 raw/materials，沒有中途可以被悄悄跳過）、如何給結果（管的是唯一保證會產出、看得見的東西——最終答案本身：引用出處、查無結果不宣稱沒有記錄、不拿不相關候選充數）。

最後變成什麼樣：

  • 一般性設計原則（不限 Query，適用任何 skill）：規則管的是「看不見的中間過程」還是「看得見的邊界／最終輸出」，決定這條規則能不能真的被 skill 保障——前者不行，後者可以。
  • Query 的新方向：A/B/C 候選收集程序與 90KB 預算機制放棄，AI 自由決定怎麼查；SKILL.md 只保留範圍限定與輸出格式規則。截至本節記錄，方向已定案，實際改寫 SKILL.md 尚未執行（討論仍在 iThome 第十八／十九篇素材整理階段）。
  • 明確承認的風險：這個決定讓 Query 退回接近「十八」事故發生前的風險狀態——遇到用詞模糊、沒有固定關鍵字的個人回憶型提問（grep 天生查不到的情境），AI 可能再次直接查錯地方或漏查。使用者判斷維持一套沒有真的被可靠執行的機制、其維護成本（文件與實作持續脫節）比這個殘留風險更貴，主動選擇接受。
  • 完整討論過程也是 iThome 鐵人賽第十八／十九篇的核心素材，詳見 raw/projects/iThome鐵人賽2026/第十八篇 Query 捕捉.md。

五十七、2026-09-08：Query 簡化正式落地，查詢報告改為「相關主題→查詢紀錄→答案」三段式防造假設計

最初目的：「五十六」定案方向後，實際改寫 SKILL.md 尚未執行。動手前，使用者表達這次 Query 調校過程是整個建設歷程中體感最大的挫敗——花大量時間調校，最後發現只是無用功，診斷本質是「優化還沒發生的問題」：A/B/C 聯集與 90KB 預算的起點是「該不該導入向量檢索」的前瞻性假設，不是真的發生過的事故。討論釐清這個診斷跟歷程記錄的落差：唯一一次「A 真的找不到」的真實案例（「四十五」backlink 命中）樣本數僅 1、且發生在高度自我指涉的 meta 查詢情境，本身也撐不住整套機制的必要性——不是完全零案例，但這唯一反例反而佐證了使用者「機制過度設計」的判斷。

決策：

  1. 落地「五十六」定案：SKILL.md 砍掉 A/B/C 候選收集與 90KB／15KB 門檻，本體改成兩塊邊界／輸出約束——搜尋範圍（只查 wiki/ 加 chaos/白板.md、想法.md 兩個常駐檔）、回答規則（引用出處、查無結果不宣稱沒有記錄、不拿不相關候選充數）；frontmatter 補上 disable-model-invocation: true、allowed-tools: Read Grep 兩個 host 層級設定（field 名稱經 claude-code-guide agent 查證為真實存在）。
  2. 新增「查詢報告」機制，把「五十六」抓到的核心問題（AI 編造沒有真的執行過的結論）進一步具體化解法：報告內容必須能對照到真實的工具呼叫紀錄，不是事後改寫的敘述——查詢紀錄列出實際執行過的 Grep 模式與原始命中檔名、實際 Read 過的頁面，並區分「採用進答案」與「Read 後判斷不相關、未採用」兩類，避免只列採用的、漏記檢查過但沒用上的頁面。
  3. 加碼「相關主題」（初版設計為「相關頁面」，逐一列出答案來源頁面的 outgoing wikilink）：實測時發現連結數量一多可讀性太差，且 AI 曾自行把 17 個連結摘要壓縮成「第一～十七篇文章頁」，等於又犯了「五十六」抓到的同一種偷懶——用一句聽起來合理的摘要代替真的列出原始資料。改成依 wiki 既有目錄結構機械分類到主題名稱、去重列出，不再逐一列頁面：evergreen/topics/<主題> 對應 <主題>、evergreen/self 對應「自己」、projects/active|archive/<專案> 對應該專案名稱（標記進行中／已封存）、entities 對應「entities」，其餘算「wiki 頂層」。仍需要摘要清單時，訂出機械判準：只有同資料夾、相同連續編號規則（如「第N篇」）、編號完整無缺漏，才能壓成範圍格式，其餘一律逐一列出，避免又變成 AI 自行拿捏「看起來很多就摘要一下」。
  4. 報告呈現順序固定為「相關主題 → 查詢紀錄 → 答案（或查無結果訊息）」。

最後變成什麼樣：改完後開新 session 實測（避免「十八」發現過的同 session 測試污染），分別測過有明確答案（使用者運動型態）與可能查不到的問題類型，查詢報告列出的 Grep／Read 紀錄可以對照到真的執行過的工具呼叫，相關主題分類與摘要判準運作正常，排版可讀。使用者確認滿意，判定這次 Query 調整完畢。chaos/Query 挫敗捕捉.md（記錄本節背景中的挫敗診斷）Promote 進本節後刪除；raw/projects/iThome鐵人賽2026/第十八篇 Query 捕捉.md 的「實作進度」同步更新為已落地，仍保留供 iThome 第十八／十九篇寫作使用。

五十九、2026-09-10：釐清「先讀 index.md」是提供脈絡，不是定義查詢程序——「五十六」原則精確化

最初目的：使用者在同一個 /hoard-query session 連續查「熱狗」與「工作相關」兩題後，追問 AI 為什麼沒有重讀 wiki/index.md（答：上一輪已 Read 過、期間無異動，本輪沿用），並進一步追問這句「先讀 index.md」（SKILL.md 現行第 12 行）對查詢實際有沒有幫助，還是 grep 本身就夠快。AI 核對「工作相關」這次查詢的實際數據：grep「工作」在 wiki/ 撈出 51 個檔案，多數是「工作流」「整理工作」等語意無關的泛用詞雜訊；index.md 各主題的範圍宣告（如「職涯」相關條目寫明是使用者的工作/職涯內容）讓 AI 不用讀完 51 篇就篩出真正相關的 3 篇候選。使用者判斷「先讀 index.md 確實有用」，但追問這是否推翻「五十六」「AI 自由決定怎麼查、不定義程序」的既有決定。

決策：使用者釐清這不是推翻，是要多分一條線——「先讀 index.md」提供的是脈絡，不是程序。「五十六」真正否決的是 A/B/C 候選收集、90KB 預算門檻這類規定「收集到候選之後該一步步怎麼做、什麼時候該停」的分支式演算法：這類步驟管的是看不見的中間過程，同一套生成過程可以無痕跡地悄悄跳過（「五十六」的造假事故本身就是證據），不論規則寫多細都無法被保障執行。「先讀 index.md」性質不同：它不規定收斂候選之後下一步該怎麼做，只是把一份本來就存在、跟這次查詢有關的參考資料（範圍宣告＋頁面摘要）放進上下文，讀了沒讀、讀到什麼都會留下可核對的工具呼叫紀錄（本來就會出現在查詢報告的「查詢紀錄」欄位）。套用「五十六」自己定的判準（規則管的是看不見的中間過程，還是看得見的邊界／最終輸出）：先讀 index.md 屬於後者，A/B/C 屬於前者，兩者本來就不同類，這次只是把分界說得更精確，機制本身不用改。

最後變成什麼樣：SKILL.md 第 12 行「先讀 index.md」不變動；新增的是這條分界本身的判準，供之後遇到類似「要不要在 SKILL.md／CLAUDE.md 裡再加一句『先做 XX』」的提案時，能直接判斷這是脈絡還是程序，不必每次重新論證一次「五十六」整套推理。

六十一、2026-09-10：新增 hoard-polish／hoard-title 兩個手動觸發 skill，取代潤稿/標題複製貼上流程

起點：使用者每次文章定稿前都會做潤稿（依 潤稿方法）與標題重新審視（依 標題取名方法）兩個動作，但兩份方法論只是 wiki/evergreen/topics/writing/ 底下的一般頁面，沒有對應的觸發機制——每次都要手動複製貼上方法論全文，或先跑 hoard-query 查到頁面才能開始。使用者主動提出「做成 skill」。

討論過程：

  • 要不要合併成一個 skill：使用者選擇拆成兩個獨立 skill（hoard-polish／hoard-title），理由是兩份方法論本來就是各自獨立的判準（潤稿是校對/潤色的機械清單，標題是協作討論式的入口選擇），需求也不一定同時發生（例如標題還沒定但想先潤稿）。
  • 目標文章怎麼指定：比較「指令帶路徑」與「AI 依對話上下文自動判斷」，使用者選後者——不強制每次打指令都要附檔名，貼文章或討論中的文章可以直接被辨識為目標；找不到或有多篇候選時停下來問，不用猜的。
  • 觸發模式比照 hoard-query／hoard-status：disable-model-invocation: true，只能用 /hoard-polish／/hoard-title 手動叫用，不自動觸發——因為這是使用者主動決定「要定稿了」才會做的動作，不該被 AI 自行判斷時機介入。

最後變成什麼樣：新增 .claude/skills/hoard-polish/SKILL.md（依 潤稿方法 執行最終發布前模式七項清單，只回報不動手改）與 .claude/skills/hoard-title/SKILL.md（依 標題取名方法 執行「寫完之後的檢查清單」＋AI 協作規則，只協助決策不擅自優化）；兩個 skill 都不把方法論內容複製一份進 SKILL.md，執行時直接讀取來源頁面當下內容，避免兩邊各存一份、之後方法論更新會漂移不同步。兩份方法論頁面各自補一行 pointer 指向對應 skill。

七十五、2026-09-14：hoard-promote 逐字保留規則加上機械複製與事後 diff 核對，堵住「憑記憶重寫」漏洞

最初目的：使用者事後核對第二十篇 Promote 結果，發現 wiki 正文跟自己原本寫在 chaos/白板.md 的版本不一致——兩句話被改寫用詞，結尾還多了一整段使用者沒寫過、AI 自己加上去的澄清段落。回頭比對這次 session 的逐字記錄確認：問題不是「規則沒寫」，hoard-promote 步驟 3 本來就寫著「使用者自己的創作保留原有用詞，逐字尊重」，但這句話只是文字承諾，沒有任何機制強制執行；更嚴重的是，本該當防呆備份的 raw/ 副本，實際上跟 wiki 正文用的是同一份「AI 憑記憶重新輸出」的內容存的，不是真的從來源逐字複製，導致連備份都一起失真。跟「五十六」「五十七」是同一種病：規則管的是看不見的中間過程（AI 心裡怎麼組織文字），沒有任何看得見的邊界輸出可以核對有沒有走鐘。

決策：不能只靠「再三提醒 AI 要逐字」，因為問題本質是「重寫」這個動作本身無法被 AI 自己察覺——改成從機制上堵住兩個環節：

  1. 來源保存機械化（hoard-ingest 步驟 3）：把「複製到 raw/」明確定義成機械操作——直接讀取來源檔案、原樣寫入，不得意譯、精簡或憑記憶重新輸出。這一步先確保至少有一份真正忠實的副本存在，不管後面 wiki 端寫成怎樣都能核對。
  2. wiki 端強制事後 diff（hoard-promote 步驟 3）：先區分「使用者自己的創作」（文章正文、逐字稿，逐字尊重）跟「心得與片段」（未成句筆記，可整理措辭）兩種內容，只有後者允許改寫；使用者創作段落要求直接複製自 raw/ 副本，不憑記憶重寫；寫完後逐段核對 wiki 正文跟 raw/ 副本是否逐字一致（結構性元素如標題、wikilink、frontmatter 不算差異），有出入就停下回報，不自己決定要不要保留改寫版本。這一步是「五十七」查詢報告同一個思路的延伸：把本來看不見的「有沒有走鐘」，變成一次可以真的跑、有明確通過/失敗結果的核對動作。

最後變成什麼樣：.claude/skills/hoard-ingest/SKILL.md 步驟 3、.claude/skills/hoard-promote/SKILL.md 步驟 3 同步修訂。第二十篇 wiki 正文本身怎麼處理（是否訂正回原字句、拿掉多寫的結尾段）這次先擱置，優先處理流程本身，尚未決定。

反向連結