DragonsHoard 建設歷程－規則品質與判準
範圍：抓出既有規則／skill 涵蓋不到的漏洞，並收斂成可重複套用的判準（例如規則有不有效、Lint 查不查得到）。不收：個別觸發機制本身的演變過程（見 觸發機制演變）、跟 AI 協作的溝通風格（見 協作與元規則）、CLAUDE.md 撰寫原則本身的通用理論（不限 DragonsHoard，見 CLAUDE.md 撰寫原則，這裡只收 DragonsHoard 實際套用時具體踩過的坑）。
二十、2026-08-15：定義「校準」——原本 Lint 查不到的失效類型
起點：使用者打算做一次定期的人工整理，計畫包含：過一遍 CLAUDE.md、粗看 wiki 文章是否符合各自分類、整理 chaos 層看有沒有已經處理過、不再需要的內容（歸檔或刪除）、評估 log.md 要不要歸檔。討論過程中，這件事跟既有「Lint」的關係變成焦點，逼出一輪對「Lint 能查什麼、查不到什麼」的重新檢視。
核心發現：既有 Lint（CLAUDE.md「Lint」一節）查的都是文本內部有訊號的失效——矛盾說法、被新來源推翻的舊主張，本質是「另一段文字跟這段文字對不上」，AI 靠比對語料庫本身就查得到。這次要處理的是另一種失效：文本內部完全沒有矛盾訊號，內容自己讀起來通順自洽，但因時間流逝或使用者想法／外部世界已經改變，不再服務使用者現狀——判斷依據不在語料庫裡，只存在使用者當下腦中或外部現實，AI 讀十遍語料庫也讀不出來，注定只有使用者自己能做。這個前提本身也預設「當初記的沒記錯」——不重新檢查記錄品質（那是 ingest 當下該顧好的事），純粹檢查「當初對、現在還對不對」的時間軸漂移。
四個具體案例收斂成兩個子類：討論中舉了四個實際素材當案例——(1) chaos/想法.md「匠人」條目，舊念頭還熱不熱；(2) 某主題頁內容跟使用者現在的認知有沒有脫節；(3) writing 主題的範圍宣告，邊界在使用者腦中有沒有漂移；(4) 「AI 教學者」標籤這類明講「留到之後再談」的延後判斷。收斂出兩個子類：
- 內容認同漂移：內容還真不真、使用者還認不認同，涵蓋案例 (1)(2)(4)
- 結構適配漂移：內容依然有效、使用者也還認同，但呈現／組織方式現在不再好用（例如已整理好的內容想換一種編排方式）
一度考慮的第三子類「優先順序漂移」（內容還真，但在使用者生活裡的份量變了）討論後判斷不需要獨立，併入上述兩類即可。兩個子類不排除以後還有更多，之後遇到不屬於這兩類的案例再擴充，不用現在窮舉。
明確排除的情況：chaos/白板.md 堆積同主題待整理筆記，不算這個新類別——那是還沒走過 Ingest 管線的原料，談不上「已記錄內容失效」，不需要「當初記的沒錯」這個前提，屬於既有 Ingest 工作流程的積壓，不是新概念。
命名：「校準」（calibration），跟 Lint 並列、互不隸屬。比喻上，wiki 是使用者心智與外部世界在某個時間點的快取（cache）；Lint 檢查快取內部一致性，校準檢查快取跟活的來源（使用者現況／外部世界）之間的落差——這個落差 AI 沒有獨立管道存取，只有快取的主人自己對照活的來源才校準得回來。這個概念本身具有通用性，不限 DragonsHoard，適用任何 AI 維護的個人 wiki，記到獨立頁 校準，跟這裡的 Hoard 具體實作分開、互相連結（2026-08-21 補寫，原本先只記在這裡、列為待辦）。
工作內容的討論與擱置：AI 一度提案讓 AI 用 proxy 訊號（自我標記不確定的條目、多久沒更新、範圍宣告是否該定期複查）篩出候選清單，使用者判斷這個提案有邏輯矛盾——校準這整個類別存在的前提就是「AI 沒有能力判斷什麼可能失效」，卻要 AI 先篩「哪些東西看起來可能失效」，篩選本身已經是那個 AI 做不到的判斷。使用者的結論：這項工作才剛被發現，不需要訂得太完美，先把最初規劃的幾項當作校準的具體工作內容——讀過 CLAUDE.md、檢查 wiki 文章是否符合各自分類（不深看）、整理 chaos 層找出已經處理過或不需要的內容決定歸檔或刪除、評估 log.md 是否需要歸檔——並註明也可以請 AI 掃過提供建議，AI 的角色是輔助（提供中性的結構性資訊、幫忙掃視），不是取代使用者的判斷。細節怎麼分工留待實際跑過幾次校準、有真實經驗後再收斂，這次不預先設計成熟流程。
頻率：無固定週期，使用者自行決定——完全看心情觸發，不比照 Lint 綁 commit 的雙觸發機制。
與 CLAUDE.md 正式化的關係：這次刻意不在 CLAUDE.md 新增獨立章節，只記在這裡跟 log.md——呼應「十七」節「先讓真實需求擠出來再長結構」的既有原則，校準這個概念才剛成形，還沒真的跑過一輪，等有實際執行經驗、知道哪些部分會重複套用之後，再決定要不要、怎麼寫進 CLAUDE.md。log.md 之後真的執行校準、要記錄結果時該用什麼紀錄類型（沿用 infra／lint，還是新開一種），同樣留待之後實際執行時再定。
二十四、2026-08-21：hoard-commit skill 遺漏 chaos/ 的 commit staging 範圍
最初目的：使用者發現前一天（2026-08-20）寫在 chaos/白板.md 的內容，呼叫 /hoard-commit 之後沒有出現在 GitHub 上，懷疑「commit 的時候 chaos 的內容沒有被推上去」。需要先查清楚是這台機器把內容弄丟了，還是內容根本沒被納入那次 commit。
怎麼做：先排查這台機器（git identity: Winson / winson.liu@cloudysys.com）目前的狀態——HEAD 跟 origin/master 完全同步、沒有任何未推送的 commit，chaos/白板.md 現在的內容跟 GitHub 上一字不差（最後真正改動它的 commit 是 8/19 的 ebf59b6）。確認這台機器上沒有遺失或卡住的內容之後，回頭讀 .claude/skills/hoard-commit/SKILL.md，發現步驟 2「掃描異動」與步驟 3「健檢」的範圍都明確寫死只涵蓋 wiki/ 跟 raw/，整份 skill 從頭到尾沒有任何一步提到 chaos/。CLAUDE.md「混亂層」規則講的是「chaos 不受 lint 內容健檢／交叉引用規則約束」，但 skill 撰寫時把這個「不用健檢」誤延伸成「commit 流程不用管」——如果 AI 照 skill 字面步驟只 staging 它掃描/健檢過的檔案，chaos 的異動就會被整個漏掉，不進 commit、推不上 GitHub。修正方式：在步驟 6（草擬 commit message）加一句，staging 前先跑 git status --porcelain 全盤確認，chaos/ 等其他有異動的路徑即使不受 lint 檢查也要一併納入這次 commit；並在「相關規則」補一段，把「需要健檢的範圍」跟「需要 commit 的範圍」兩件事明確拆開講，避免以後又被合併誤讀。
最後變成什麼樣：.claude/skills/hoard-commit/SKILL.md 步驟 6 與「相關規則」段落已更新。這台機器沒有可以立即復原的遺失內容——8/20 寫的東西找不找得回來，取決於使用者去另一台機器（毓文 / yeelm1487@gmail.com）確認 git status 是否還留著未 commit 的異動，找到的話補一次 commit/push 就能救回。這次修正屬於規則層級的變更（門檻 1）：更新了 commit 流程 skill 的固定步驟，以後每次 /hoard-commit 都會照新版執行，不是一次性補救。
二十五、2026-08-23：發現「定義了沒用的規則」，收斂出規則有效性判準
最初目的：iThome 鐵人賽第八篇要把 Ingest 從輕描淡寫的操作步驟提升為主角規格，逼出一輪理論化討論，過程中新建了 Ingest 頁面（三段結構：消化／結構化／觸發評估）。使用者接著追問 2026-08-12 寫進 CLAUDE.md 的「觸發評估」規則（Ingest 步驟 2）實際造成什麼影響，發現「講不出具體時機」那個分支就算被完美執行也不會產生任何可觀察的產出——tags、index.md、連結全部不受影響，跟完全沒問過這個問題結果一樣。需要先確認這個判斷、再收斂出一套通用判準，避免以後又寫出這種「定義了但沒用」的規則，並回頭拿去檢查 CLAUDE.md 既有規則。
怎麼做：先修正 Ingest 頁面本身的模型——消化→結構化才是 Ingest 的核心生產線，觸發評估的產出（如果有）落在生產線之外（另一份規則檔案），不修改被 ingest 頁面的 tags/index/連結；接著砍掉 CLAUDE.md 裡「講不出具體場景」那個 no-op 分支的落落長描述，以及一開始補記上去的「已知限制」註記——後者本身也違反「CLAUDE.md 不該內嵌演變歷史」（見「二十三」）。使用者提出假設「規則要被執行，必須講清楚具體產出」，AI 用 chaos/白板.md 待辦打勾規則當反例——那條規則產出極度具體（[ ]→[x]），但 CLAUDE.md 自己承認「不會自動發生」，證明「具體產出」是必要條件、不是充分條件，還缺「觸發時機」這個獨立維度。討論中一度擴大到「執行邏輯本身的完整性」（以 hoard-commit 漏 staging chaos/ 為例，見「二十四」）與「Lint 當第四層安全網」，被使用者判定是扯遠、混入不同問題，明確要求收回，只留兩條判準。最後一輪修辭precision：使用者指出「具體觸發時機」這個措辭本身還留有破綻——「具體」不能排除語意判斷偽裝成具體條件的情況（例如「使用者提到重要決策時就記錄」，聽起來具體，實際上跟 Query 觸發機制翻車（「十八」）是同一個病），改用「可機械判斷的事件」取代「具體」，明確排除依賴 AI 語意判斷的觸發。
最後變成什麼樣：兩條判準（觸發綁定可機械判斷的事件、執行後留下具體可驗證的產出）寫進 CLAUDE.md 新增小節「規則有效性判準」，緊接在「與 AI 協作的溝通風格」之後。過程中的一個副產品：確認了「舉反例」是比「延伸羅列更多維度」更有效的收斂方式（白板打勾規則反例一次講清楚「必要不充分」，執行邏輯完整性/Lint 那輪延伸反而讓使用者看不懂在討論什麼）。
後續：拿判準逐條檢查 CLAUDE.md 全文（同日）：掃過全部規則，分三類——(A) 明確違規、直接刪除：chaos/白板.md 待辦打勾同步規則（觸發是「AI 事後發現」，語意判斷、不可機械檢查）、「想法捕捉入口」的「AI 定期讀過 想法.md」（「定期」沒有綁定任何事件，且 Query 改成 /hoard-query 手動觸發後這句已經完全沒有任何東西在驅動它執行）；(B) 灰色地帶、判定不划算、一併刪除：歸檔流程「觸發」步驟原寫「AI 觀察到明顯完成跡象時可以主動提議」，使用者確認實際運作一直是使用者主動提出歸檔要求，這個 AI 主動提議的分支不是真正在用的路徑，簡化為「使用者提出要歸檔某個專案」；(C) 判定判準本身管不到、排除在外：「與 AI 協作的溝通風格」整節、「語言慣例」、建設歷程「值不值得記」門檻的即時判斷——這些是沒有離散觸發點、要求 AI 在任何對話中隨時保持警覺的行為風格規則，本質上無法綁在機械事件上，跟「該不該產出一份檔案」的工作流程規則不是同一種病，不套用這條判準。三處刪修已直接反映在 CLAUDE.md 對應段落。
二十九、2026-08-27：CLAUDE.md 精簡性複查，抓出六處多餘內容
最初目的：準備把 CLAUDE.md 整份公開貼進 iThome 鐵人賽第十篇（決策過程見 iThome 鐵人賽 2026 決策歷程「十九」）之前，使用者想再確認一次這份文件有沒有殘留多餘內容。這輪要抓的是「二十五」沒涵蓋到的失效模式——「二十五」查的是規則有沒有觸發、有沒有產出（有效性），這次查的是精簡性判準第 3 條「只寫做什麼、不寫為什麼」有沒有被確實遵守，兩者是不同的檢查維度。
怎麼做：逐節重讀，抓出六處具體問題並修正：(1) 混亂層節裡 白板.md／想法.md 兩個 bullet 幾乎逐字重複「差異不是主題是性質」這句，刪掉重複的一份，改成「見上」；(2) Git 節「兩個 skill 原名 dragonshoard-commit/pull，2026-08-02 改名縮短」是純歷史事實、不影響現在的行為，直接刪除；(3) 溝通風格「不主動建議新增 skill」條目裡「2026-08-14 從本節移出，原本的判準被誤用」這段沿革說明同樣刪除，只留判斷方式與決策 pointer；(4) 混亂層節開頭「原料跟成品中間需要一個位置——這就是混亂層」整段「為什麼」敘述，改成一句功能性描述並補上 pointer 到 架構與流程「八」「十」（已核對這兩節正好是混亂層概念與 chaos/ 資料夾定案）；(5) Query 節「這類判斷不穩定、容易漏接」補上 pointer 到 觸發機制演變「十八」（Query 觸發機制事故本來就記在那，原本沒連過去）；(6) 溝通風格「想法反覆跳動、不用每次確認」條目「使用者想法生成模式本來就是快速迭代」這句「為什麼」敘述，查核後發現建設歷程裡找不到這條規則的起源記錄——直接砍短，沒有補 pointer。
最後變成什麼樣：CLAUDE.md 六處修訂完成，檔案變短、pointer 覆蓋更完整。留下一個已知缺口：「想法反覆跳動」這條規則本身沒有對應的建設歷程記錄可以回連，之後若要補一筆完整決策歷程可以回頭處理，目前先維持精簡版文字。
三十四、2026-09-01：CLAUDE.md 新增第三類判準「嚴謹度」，逐條套用重寫既有規則
最初目的：完成 Query 段落整套重新設計（「三十三」）後，那段敘述風格反覆修了五輪才收斂，使用者認為最終版本清楚，要求以此為範本套用到 CLAUDE.md 其餘既有規則，用捕捉檔 chaos/CLAUDE.md規則重寫.md 記錄任務。既有兩類判準（有效性管「會不會被執行」、精簡性管「該不該長這麼肥」）都沒有管「規則讀起來是不是可逐項套用的判準、還是在解釋或說服讀者」這個維度，逼出第三類判準。
怎麼做：先從 Query 段落重寫過程萃取七個具體風格特徵（輸出定義先行、判準測試要能逐項套用不能是抽象性質描述、條件分支互斥不硬湊第三支、避免帶推論語氣的敘事連接詞、例子收進括號不編進敘事句、簡稱只在首次出現定義、口語化不能犧牲精確）。動手前先確認兩件事：逐條檢查順序（選擇照 CLAUDE.md 既有章節順序，不是使用者另外指定順序）、七個特徵要不要收斂成正式判準寫進 CLAUDE.md（選擇收斂為正式判準，不只是這次任務的參考筆記）。將七個特徵壓縮成「CLAUDE.md 寫作準則」節新增的第 4-6 條，跟既有「有效性」「精簡性」並列成「嚴謹度」類別；接著照章節順序逐條過 CLAUDE.md 全文，用新判準抓出違規段落並修正：刪掉「反面排除」「規模門檻搬移」「Ingest 步驟 3c」「hoard-commit 觸發」等處帶「——這是為什麼」尾巴的敘事性解釋（精簡性/嚴謹度雙重違規）；把「卡住時給最小啟動行為」條目從敘事句改寫成明確的判準→是／否分支結構（嚴謹度第 4-5 條）；把 Hoard 建設歷程門檻的「核心判斷句」從帶重述尾巴的敘事句改成單一判準問句。
最後變成什麼樣：CLAUDE.md「CLAUDE.md 寫作準則」節從兩類判準擴充為三類，文末 pointer 補上「三十三」標明本次判準風格的直接來源。全文另外修訂約六處既有規則的敘事性尾巴與條件結構。捕捉檔 chaos/CLAUDE.md規則重寫.md 內容併入後，依單篇任務型捕捉檔慣例整份刪除。同日使用者回頭複查「wiki 直接編輯」節，發現「創作本體 vs. 使用者報告的狀態」這條跟「Promote」步驟 1 的括號說明逐字重複，改成一句 pointer 指過去，只留原條目裡別處沒有的「文章正文協作先給草稿、不要直接寫進檔案」規則。同一輪再複查「混亂層」共通規則：刪掉跟節首「兩層規則都不適用」逐字重複的最後一條（僅存的新資訊「不用出現在 index.md 裡」併回節首那句）；「不整份畢業」條砍掉跟「單篇任務型捕捉檔」bullet 重複的內容，只留 pointer；「整理口述想法」條砍掉「那些是雜訊」填充語氣；「新增待辦」條把「讓它在實際動手時自然浮現」的敘事修辭拉直成「等實際動手時再決定」。使用者最後要求全文覆核一次，抓出三處：(1) 「wiki 直接編輯」節 log.md 節奏那條 bullet 跟「log.md 維護規則」節「可以比照 index.md，寬鬆／批次處理即可」逐字重複（此重複原本就存在，非本次新增），刪掉前者、併入 index.md 那條 bullet 的括號 pointer；(2) 「CLAUDE.md 寫作準則」節文末 pointer 漏掉本條「三十四」自身，補上；(3) 嚴謹度判準第 6 條「（例：…)」全形／半形括號不一致的筆誤，修正為全形。
三十七、2026-09-01：Ingest 步驟 3、4 之間的分支矛盾
最初目的：使用者請 ChatGPT review CLAUDE.md，抓出 Ingest 步驟 3c 明講決策可能是「沿用現有頁面／加個段落」，步驟 4 卻無條件寫「在決定的位置寫一頁來源摘要」——決策若是沿用既有頁面，步驟 4 字面上仍要求生出新頁面，兩步驟對不上。
怎麼做：核對步驟 3c 的兩種可能決定（沿用既有頁面、開新頁面），把步驟 4 從單一動作改寫成依決定分流的兩個互斥分支，符合「CLAUDE.md 寫作準則」嚴謹度判準第 5 條（條件分支互斥）。
最後變成什麼樣：步驟 4 改為「依步驟 3 的決定寫入內容：決定沿用既有頁面 → 在該頁補上對應段落；決定開新頁面（含步驟 3c 判定要開新主題資料夾的情況）→ 建立來源摘要頁」，兩分支對應步驟 3c 的兩種決定，不再預設一定產生新頁面。
四十六、2026-09-07：tag 名稱不合格重複發生，Frontmatter schema 補上標籤語法驗證
最初目的：使用者發現 CLAUDE.md 撰寫原則 頁的 tags 裡 CLAUDE.md 這個標籤在 Obsidian 顯示為無效——句點不是 Obsidian 標籤語法允許的字元。使用者接著指出這不是第一次：上一次是空格或特殊符號導致同樣的「標籤失效」，兩次根因不同、但都屬於同一類問題——tag 名稱不符合 Obsidian 語法。逐次個別修正治標不治本，需要收斂成 Lint 能攔住的一般判準。
怎麼做：核對既有 .claude/skills/hoard-commit/SKILL.md 步驟 3「Frontmatter schema」健檢五項，發現只檢查 tags 欄位存不存在，不檢查陣列裡每個標籤的內容格式是否合法——這正是兩次事故的共同根因：規則只驗證「有沒有」，沒驗證「合不合格式」。解法不是為句點、空格各寫一條特例，而是直接對齊 Obsidian 標籤語法本身：只允許字母、數字、底線 _、連字號 -、用於巢狀的斜線 /，不得含空白、句點等其他符號，也不得整個標籤只有數字——一條規則涵蓋所有非法字元的情況，不分是哪個符號。
最後變成什麼樣：.claude/skills/hoard-commit/SKILL.md 步驟 3「Frontmatter schema」新增第三項檢查（標籤語法），下次 commit 前的 Lint 會攔下任何不合法標籤。CLAUDE.md 撰寫原則 頁的 CLAUDE.md 標籤已改為 CLAUDE-md。全庫掃過一輪現有 tags，未發現其他違反新規則的既有標籤。
四十八、2026-09-06：真實案例——專案歸檔該不該抽成 Skill，AI 推理錯誤又被糾正
最初目的：CLAUDE.md 規則精修定案後複查新版 CLAUDE.md，發現「專案歸檔」是個 5 步驟完整 SOP，卻明講「歸檔不另設 skill，依上述流程執行」，跟 Ingest／Query／Lint／Git 全部抽成 Skill 的模式（見「四十九」）不一致。
怎麼做：AI 第一次查 wiki/index.md 發現這個 repo 只歸檔過一個專案，判斷「頻率太低，還沒到值得抽出去的門檻」，套用了「份量小的單行規則可以留著」的先例——這個類比套錯了，被使用者當場糾正：CLAUDE.md 常駐稅邏輯的必要條件本來就是「高頻」，低頻直接不合格，跟程序長短、抽出去的力氣無關；而且 Skill 平常只在清單裡佔一行 description，抽出去的成本很低，內嵌在 CLAUDE.md 卻是每個 session 都要付的稅，不管這次有沒有要歸檔。低頻不是「還沒資格抽」的理由，反而是「更該抽」的理由。錯誤在於把「這東西該不該存在於 CLAUDE.md」跟「現在動手抽值不值得」兩件事混在一起。
最後變成什麼樣：這是一次真實的「AI 推理錯了、被使用者當場抓到糾正」的過程，示範了常駐稅邏輯正確的套用方式——判準是頻率（高頻＋不可推斷），不是抽出去要花多少工程量。實際卸載成 skill 的完整決策過程與技術結果見「五十五」。
五十二、2026-09-06：sources／status 兩個 frontmatter 欄位補齊操作型定義
最初目的：發現 schema 定義 sources: 3 這類欄位、Lint 也驗證「必須是非負整數」，但整份 CLAUDE.md 沒有定義「一個 source 算什麼」；同時發現 status 固定值 draft | evergreen | active | archived | done 只詳細解釋了 draft。
怎麼做：sources——實測三個頁面對照 raw/ 實際檔案數，證實不是單純沒寫文件、是從沒被一致套用過：靶心人公式.md sources:1 ↔ raw/ 剛好 1 個檔案（巧合）；檢索典範與問題分類.md sources:3 ↔ raw/ 0 個檔案（資料夾根本不存在，連帶抓到這頁文獻整理當初 Ingest 沒依步驟 3 存底原始來源）；舊方向 iThome _index.md sources:12 ↔ raw/ 實際 29 個檔案。查證 git 初始 commit 就有這個欄位，找不到任何決策紀錄解釋用途；判斷目前系統裡沒有任何程式邏輯真的讀取這個欄位做決策，唯一價值是給人看的「證據厚度提示」。status——實測發現不是單純缺文件，是五個值混了 track 層級（evergreen／active／archived）與文件完成度（draft／done）兩條軸線，第三篇 - 取材分析.md、Karpathy LLM Wiki 中譯.md 人在已歸檔專案目錄下 status 卻還是 active，查歸檔 SOP 步驟 3 只要求「更新受影響的 index.md、log.md 與相關頁面」從未明講要同步子頁 status，是漏洞根源。
最後變成什麼樣：sources 保留欄位，重新定義為「這個頁面目前內容所源自的、不重複 raw/ 路徑數量」，唯一合法寫入者是 Ingest，Lint 維持只做型別檢查；舊頁面數字不回溯修正，等下次真的被 Ingest 觸碰時才依當下實際重算。status 收斂成純 track 層級三值 evergreen | active | archived，一個 frontmatter 只負責一種工作，文件完成度另外用進度表 ✅／🟡／🔴 追蹤、不靠 frontmatter；因為是縮小 Lint 允許值集合，這次不能比照 sources 不回溯，純機械式 remap（依頁面當下所在 active/ 或 archive/ 目錄直接對應）：wiki/projects/active/ 底下 16 個原 draft／done 頁面 → active；wiki/projects/archive/ 底下 5 個原 done／draft／active 子頁面（含 取材分析.md、Karpathy LLM Wiki 中譯.md）→ archived；連帶補歸檔 SOP 新增步驟 2「子頁面 status 一併同步改為 archived」。
五十四、2026-09-06：「範圍判準優先於經濟判準」補回操作型定義
最初目的：發現 hoard-ingest 步驟 2 標題寫「決定歸屬，範圍判準優先於經濟判準」，但這兩個詞在操作規則本文裡從沒被定義過，只有在觸發機制演變「十九」的決策歷程裡才找得到定義，牴觸 CLAUDE.md「CLAUDE.md 寫作準則」自己第 4 條「簡稱只定義一次，例子只作補充，不取代正式判準」。
怎麼做：使用者判斷這不是功能缺口——步驟 2 底下三個 bullet 本身已經把完整流程講清楚了，就算不知道這兩個名詞在講什麼，照著 bullet 做也不會做錯，純粹是術語標籤缺定義，可改可不改。第一版草稿「經濟判準：沿用既有頁面還是開新頁面比較划算」被指出太模糊，沒講「划算」在秤什麼，回頭核對「十九」原始定義（划不划算——量小、命名／維護成本），改採直接沿用既有措辭，不重新發明新說法。
最後變成什麼樣：不拿掉這兩個詞（已在決策歷程、鐵人賽第十一篇文章裡被使用，拿掉會讓那些引用變成無源之水），在 hoard-ingest 步驟 2 標題後補括號定義：「範圍判準：內容性質是否落在既有主題定義的範圍內；經濟判準：划不划算——內容量、命名與維護成本值不值得為此新增分類。範圍判準要先篩出合格候選，經濟判準才輪到在合格候選裡做選擇」。三個既有 bullet 不動。
五十八、2026-09-08：Query 簡化建立的判準回頭套用到其餘六個 skill，補齊兩處未被保障的「不自動觸發」
最初目的：hoard-query 簡化正式落地（「五十七」）後，使用者想確認這次改版逼出的判準是不是只對 Query 有效，其餘 hoard-archive／hoard-commit／hoard-ingest／hoard-materials-sync／hoard-pull／hoard-status 六個 skill 有沒有跟上同一套嚴謹度與有效性水準。
怎麼做：把「五十六」「五十七」逼出的兩條判準當檢查清單，逐一讀六個 skill 全文套用：（a）規則是不是真的被 host 層級機制保障（disable-model-invocation、allowed-tools 這類 frontmatter 欄位），還是只有純文字宣稱、跟改版前的 Query 一樣沒有真的被擋住；（b）規則管的是看得見的邊界／最終輸出，還是看不見的中間判斷過程、又沒有查核機制。逐項結果：hoard-status、hoard-materials-sync 的 description 都文字宣稱「手動 /xxx 叫用，不自動觸發」，但都沒有 disable-model-invocation: true 背書，判準（a）不合格，直接補上這個欄位；hoard-status 額外宣稱「只讀、不異動任何檔案」、hoard-materials-sync 宣稱「不做任何寫作」，同樣只是文字承諾，兩者都補上 allowed-tools: Bash Read Grep Glob（排除 Edit/Write，把「不寫入」做成工具層級擋掉）。hoard-commit 檢視後判定是六者中嚴謹度最高的一個，本來就是「三十四」「三十七」「四十六」三輪判準修過的產物，五項 Lint 全是可逐項套用的機械判準，沒有缺口。hoard-pull 就是「五十六」裡拿來對照、驗證過真的有效的範本，維持原狀。hoard-archive 步驟都落在可查核的 git 動作上，步驟 4「修正連結」雖沒像 hoard-commit 寫死 grep 指令，但漏改的舊路徑連結會在下一次 hoard-commit 死鏈檢查被攔下，等於有安全網，不算真缺口。hoard-ingest 步驟 2「決定歸屬」結構上跟 Query 原本出包的候選 A 同類——都是發生在其他動作之前、看不見的中間判斷，沒有機制驗證 AI 真的逐一比對過各主題範圍宣告、還是抓標題關鍵字比對就分類；但跟 Query 不同的是，分類錯位最終會留下可見產物（頁面位置、index.md），不是「查無結果」那種沉默失敗，且目前沒有觀察到真的發生過分類錯誤，依照「別為沒真的發生過的事加機制」的既有原則（見「五十六」），判定先不加報告機制，只記錄留意，不落地成規則變更。
最後變成什麼樣：hoard-status、hoard-materials-sync 兩個 skill 的 frontmatter 補上 disable-model-invocation: true 與 allowed-tools: Bash Read Grep Glob；hoard-commit、hoard-pull、hoard-archive 維持原狀，判定已達標；hoard-ingest 步驟 2 的潛在風險列為觀察項，未落地成規則變更。這是「五十六」「五十七」的判準第一次回頭套用到 Query 以外的 skill，確認判準不是只對單一 skill 有效，也示範了「結構相似不代表風險等級相同」——同樣是「看不見的中間判斷」，Query 是沉默失敗、Ingest 有安全網，處置因此不同。
七十九、2026-09-23：以通用模板為鏡做三軸盤點，確立「規則檔只寫行為、連結都不留」
最初目的：把 skill 從 DragonsHoard 搬到通用模板 itwilldo-wiki-demo 時，核心原則是「絕對不要照搬」——每份 spec 的每個欄位、每支 skill 的每個步驟都要依模板的實際結構重新判斷還成不成立。這個過程等於把 Hoard 自己的設計重看了一遍，順帶照出不少問題。使用者據此要求以 itwilldo 為參考做一次完整盤點，並自行定義了判準。
怎麼做：判準三軸——（一）內容歸屬位置：規格是不是寫在它所規範的資料檔裡、是不是被寫死在 skill 裡、同一條規則有沒有散在兩處；（二）規則合理性：前提還成不成立、會不會真的被執行、彼此有沒有衝突、觸發條件是不是全有全無；（三）規則的效益：拿 claude-authoring.md 自己的「只寫行為」原則回頭檢查 Hoard，設計理由、根因案例、事故經過、歷程補充都是常駐上下文成本卻不改變行為。軸三使用者追加了一條更嚴的標準：連指向脈絡的連結都不要留，因為連結本身也是成本，而且會誘導 AI 去讀。同時劃清界線：軸三只適用規則檔（CLAUDE.md、.claude/specs/、.claude/skills/），建設歷程與決策歷程那些歷史敘述本身就是內容，不在這條標準底下。排序原則是「CLAUDE.md 是唯一每個 session 常駐載入的檔案」——同樣刪一段廢話，刪在 CLAUDE.md 的效益遠高於刪在 spec 裡。
最後變成什麼樣：盤出 14 項，分四批處理完畢。CLAUDE.md 從 6,641 降到 5,618 bytes（−15.4%）。最能說明軸三必要性的是檔首那段重構公告：它指向的 chaos/CLAUDE.md 重構分析.md 早已不存在——查證發現那份捕捉檔是 2026-09-15 重構當下就被 Promote 並刪除的，也就是那個指標從寫下去的第一天就是死的，活了 8 天沒被發現。另外兩處刪除也是同類：一條「已確認廢除」的規則（規則檔在描述一條不存在的規則），以及 log-archive.md 指向 CLAUDE.md 早已移除的章節。
八十、2026-09-23：規格外包——規則不該寫在它所規範的資料檔裡
最初目的：軸一掃出同一個模式重複出現在四個地方：wiki/index.md、wiki/log.md、wiki/log-archive.md、raw/雜記寶庫/index.md 的檔首都自帶維護規格。代價是每次 Query、Ingest 讀那些資料檔，都要連規格一起吃進上下文。另外兩類同源問題：wiki_link_check.py 有三組常數（WIKI_ROOT_EXEMPT／DEADLINK_EXEMPT／CHAOS_WHITELIST）是只存在於 Python 裡的規則，任何 spec 都沒記載；CLAUDE.md 的核心架構樹有七行把規則混進了目錄說明。
怎麼做：新增 .claude/specs/wiki-index.md 與 wiki-log.md 兩份規格，四處檔首的規則全部抽走。雜記寶庫只有兩句規則，折進 raw-lifecycle.md 而不另開一份——多開一份 spec 的維護成本高過收益。建設歷程路由頁的「記錄格式」則維持原狀：那是單一 wiki 內容頁自己的書寫慣例，不是跨頁物件規格，抽出來會變成只有一個消費者、而且消費者是內容頁的 spec。腳本三組常數寫進對應 spec。架構樹清成純結構描述，但其中 chaos/ 的豁免規則（不受交叉引用與 index.md 約束）與「使用者可直接編輯 wiki 任何檔案」原本全 Hoard 只寫在那棵樹裡，直接砍會掉規則，先補進 chaos-capture.md 與 wiki-page.md 才動手。另外 log 的 類型 欄位過去從未列舉可用值，實際用過六個，收斂成現在真的會被寫入的三個（ingest／infra／archive）——允許值列著沒人寫的選項，下次 AI 可能會挑來用。
最後變成什麼樣：.claude/specs/ 從 11,597 增至 15,689 bytes，CLAUDE.md 同期再降。這批的本質是規則總量增加、常駐成本下降——規則沒有消失，只是從「每個 session 都載入」搬到「需要時才讀」，而且多出來的部分是原本只存在於 Python 常數、架構樹註解與檔首裡、從未寫成明文的東西。副產物是一條原本完全沒人記載的維護耦合被寫下來：新增常駐型捕捉檔時，必須同步更新 wiki_link_check.py 的白名單，否則指向它的連結會被判死鏈。
八十一、2026-09-23：連結檢查長期空轉與唯讀鐵律的範圍矛盾——兩個互相遮蔽的失效
最初目的：搬 wiki_link_check.py 到 itwilldo 時，在新環境的測試案例上發現腳本抓不到新增的頁面，追出根因——git diff --name-status 與 git ls-files 回傳的非 ASCII 路徑預設會被八進位跳脫並加引號，腳本直接拿這個字串當路徑，跟 rglob 掃出來的真實 UTF-8 檔名永遠比對不上。Hoard 的 wiki 頁面幾乎都是中文檔名，這表示五項檢查對絕大多數異動長期空轉，而且因為 exit code 是 0，看起來像「通過」。
怎麼做：run_git() 統一加上 -c core.quotepath=false。以 commit b2fd9d9 實測驗證：該次有 6 個 wiki 檔案異動，修正前腳本只認得出 1 個（唯一純 ASCII 路徑的 wiki/log.md）。修完先做一次全庫掃描確認累積損害——100 個頁面，0 個真正壞掉的連結，但掃出兩類誤判，都會在修正上線後開始擋 commit：指向 raw/ 的裸檔名連結（4 處，目標檔案真實存在、Obsidian 也正常解析，只是 is_valid_external() 只認明確的 raw/ 前綴），以及文章正文裡沒用反引號包起來的 wikilink 語法示範（1 處）。前者選擇放寬檢查器貼合實際書寫慣例，後者補上反引號。同時補一條規則：hoard-lint 的三項檢查必須各自回報實際執行狀態，不得只回報「通過」而不交代哪些真的跑過——這正是本次事故的形狀。
最後變成什麼樣：基準線全庫死鏈 0、歧義 0，檢查從此是真的在跑。更值得記的是後續：修完當天的第一個 commit，lint 就當場攔下一個 raw/ 唯讀鐵律異常——而追查後發現那不是單次手誤，Hoard 每次往雜記寶庫存東西都會追加該目錄的 index.md，日常操作長期違反唯讀鐵律的字面規定卻從未被抓到。根源是 raw-lifecycle.md 的 Object 寫「原始來源檔案」，唯讀鐵律的措辭卻涵蓋整個 raw/，沒區分「該凍結的來源」與「Hoard 自己維護的目錄索引」；已修正主詞並明文排除目錄索引。兩個失效互相遮蔽：檢查壞了所以抓不到矛盾，矛盾沒被抓到所以沒人發現檢查壞了。這也是機制修好之後第一次真的擋下東西，等於自證有效。
八十二、2026-09-23：lint 觸發判斷從 commit 歸位到 lint 自己
最初目的：「這次要不要跑 lint」的判斷寫在 hoard-commit 步驟 3（「wiki/、raw/ 都沒有異動就跳過」），等於 commit 必須知道 lint 內部長什麼樣。兩個後果：lint 日後增減檢查項目時 hoard-commit 也要跟著改、而且很容易漏改；使用者直接手動叫 hoard-lint 時不會有這層判斷。顆粒度也太粗——lint 裡是四項依賴不同目錄的檢查，觸發卻是全有全無，只搬一份來源進 raw/ 的 commit 照樣會去讀 wiki-page.md、跑連結腳本。
怎麼做：判斷整個搬進 hoard-lint 的第一步，掃一次 git status 後依受影響的頂層目錄決定跑哪幾項，hoard-commit 簡化成無條件呼叫。依賴關係重新推導過，沒有照抄 itwilldo 的分組（Hoard 的檢查項目不同，多了 log.md 歸檔、frontmatter 是六欄位、連結檢查含 orphan／minlink）：raw 不變性綁 raw/；連結檢查、frontmatter、index 跟上、log 歸檔四項綁 wiki/——其中 log 歸檔是 Hoard 獨有，綁 wiki/ 的理由是 log 只因追加紀錄而變大，而 wiki/log.md 就在 wiki/ 底下，所以推它過門檻的那次 commit 必然是 wiki 有異動的那次。
最後變成什麼樣：知識只留在一個地方，lint 增減檢查時不必再同步改 commit，手動叫用行為也一致。略過的檢查一律要明講原因，不靜默跳過——這條跟「八十一」補的執行狀態回報義務接在一起，構成「沒跑的檢查必須是可見的」這個完整要求。