Lint 重新思考（合理性／有效性出發，非現況描述）
任務型捕捉檔，預計最終會被記錄進 wiki（可能是獨立主題頁，或併入既有的 DragonsHoard 建設歷程／iThome 文章，視後續決定而定）。討論方法：不預設現行 hoard-commit 五項規格是對的答案，先從「什麼樣的 Lint 設計合理、有效」建立判準，再回頭檢驗現行設計、找漏洞。以下是討論收斂後的整體理解。
一、Lint 的本質定位
Lint 只處理「機械可判斷、不需要語意或脈絡理解」的結構檢查——這是它跟 Ingest／Query 的分工邊界，也是判斷任何一項該不該歸 Lint 管的第一道濾網。矛盾／過時說法討論後確認不符合這條線，見第四節。
二、觸發時機
判準：
- 要卡在「修正還便宜」跟「修正變貴」的分界點上——這是選任何觸發點的唯一正當理由。
- 觸發本身要可靠、不能靠自覺或記性——「定期」「有空就做」這類設計在這個 Hoard 已經被證明會退化成「可以不做」（校準機制、舊版 checkpoint 都是例子）。
- 不能太頻繁到打斷正常寫作／探索的節奏——中間狀態暫時違反不變條件是正常的，不該每次都被打斷。
- 不能太稀疏到讓違規累積到無法追溯。
結論：commit 這個時間點在「時機」上是對的，同時滿足準則 1、3、4，跟現行設計一致。
但「保證方式」有漏洞：現在完全靠「AI 答應每次都會呼叫 hoard-commit」，這是文字承諾不是機制保證，任何繞過 Claude Code 的 commit（終端機、GUI Git 工具、另一個 agent session）都不會觸發它。現行五項檢查全部是「純結構檢查，不需要 LLM」，理論上可以寫成確定性腳本、掛真正的 git pre-commit hook，讓觸發不依賴 AI 記性——這是套用 Hoard 自己已經驗證過的判準（host 層級機制優先於 agent 層級文字承諾，見「五十六」「五十七」）。這個漏洞的補償手段：使用者懷疑有 commit 繞過檢查時，可以主動要求一次全域稽核（跟第三節的全域稽核是同一件事的兩種用途）。
三、檢查對象
判準：
- 必須是純機械可判斷的，不需要語意或脈絡理解。
- 必須對應到某個明確被承諾過的保證，不是「感覺應該不錯」的內容品質期待。
- 必須是「單看一個頁面本身看不出來，需要跳出去看全局才會發現」的錯誤。
- 檢查成本要跟知識庫規模相稱（現在 93 份頁面，成本可忽略；規模變大時需要重新評估）。
現行五項（raw/ 不變性、孤兒頁面、死鏈、新增頁面最低連結、frontmatter schema）套用四條判準全部成立，予以保留。
效能設計修正（已定案）：孤兒頁面／死鏈不需要每次把全庫連結圖整個重建一次。一個頁面會變孤兒或連到死鏈，成因必定是這次 commit 裡「某頁面被編輯移除了連結」或「某頁面被刪除／改名」，兩者都會現形在 diff 裡。所以只需要：(1) 對這次被修改的頁面，比對修改前後找出「被拿掉的連結」；(2) 記下這次被刪除／改名頁面的舊路徑；(3) 針對這幾個目標做窄範圍反向搜尋（grep 這幾個字串），確認沒有其他頁面還連著。範圍窄、成本低，效果跟全域重掃等價，取代死鏈／孤兒頁面現行「全域重新解析」的做法。全域重掃保留給使用者主動要求的稽核用途，同時補償第二節「觸發保證」的漏洞。
新增候選（第六項，優先度低）：頁面短檔名唯一性。全庫實測撞名只有兩組共 9 個檔案：_index.md（6 份，跨 6 個不同專案／主題資料夾）、決策歷程.md（3 份，跨 3 個不同專案／主題資料夾），沒有其他撞名。這兩組是每個專案／主題都會有一份的通用樞紐檔名，撞名本身是結構上必然、會持續變多的，但實際會造成連結失效的觸發條件（寫一條依賴短檔名歧義解析的裸連結）到現在為止0 次真實故障——寫作習慣自然用相對路徑（自己專案內）或完整路徑（跨專案）避開了這個雷，不是靠任何機制擋下來的。真要做這項檢查，需要先把 _index、決策歷程 這類已知故意重複的通用檔名排除在外，否則每次新增專案都會發假警報；符合判準 1、2、3，但實際發生率是 0，優先度排在效能修正之後，列低優先。
未經檢驗的旁支觀察（不算討論結論，只是留痕）：raw/ 不變性檢查偶爾需要人工判斷「這次 diff 是不是只是 CRLF/LF 換行符正規化」——這是我單方面加進來的觀察，沒有跟使用者討論過，證據也只查到 2026-08-02 log-archive 一筆真的針對 raw/ 檔案的案例（另一筆 2026-08-11 是文章正文換行符問題，跟 raw/ 不變性檢查無關，不能算數）。是否要處理、值不值得處理，都還沒討論，不列入待決事項。
四、矛盾／過時說法——定案排除
結論：不歸 Lint 管，也不設計成任何形式的 AI 審查機制，責任交還使用者。
理由：這兩項本質上需要語意理解，不符合判準 1。勉強要做的話只有三種可能設計：全庫兩兩比對（成本高、雜訊高）、縮小到同主題比對（本質上就是在做 Query／Ingest 的工作，不是 Lint）、依賴 Ingest／Query 順手發現（本來就已經在做——Ingest 步驟 4 有限範圍的矛盾比對、Query 語意理解時的偶然副作用，2026-09-11 有真實案例）。不需要為此另立機制。
這個結論呼應「知識庫最高負責人始終是使用者」的立場：矛盾／過時與否本身就是需要人（或 AI 在場、被要求時）當下判斷的事，包裝成自動化保證，等於預設了一個不存在的「隨時可被機械驗證的正確答案」，這個預設本身就是錯的。
五、現況驗證（今天實測，作為佐證）
- 2026-09-07 有一次真實的全域掃描確實抓到過 2 個舊孤兒頁面（
舊方向/chaos/底下兩份任務型捕捉檔，只被純文字提及），證明機制設計本身有效，不是空想。 - 七項→五項改造拿掉 checkpoint／
lint類型 log 紀錄後，個別 commit 不再留下「有沒有真的做全域掃描」的痕跡——跟hoard-query在「四十四」附近踩過的「規則清楚但沒有可觀察中途產物」是同一種結構性風險，目前還沒被抓到過，但機制上存在。 - 今天現場重新寫腳本驗證：全庫 93 份頁面，目前 0 孤兒頁面——「現在」這個不變條件成立，但這是這次臨時驗證的結果，不是規律性被驗證出來的。
六、已定案 vs 待決事項
已定案：
- 死鏈／孤兒頁面檢查改成「窄範圍反向搜尋」（第三節），取代全域重新解析；死鏈掃描範圍的疑慮同時被這個結論解決，不再是獨立問題。
- 矛盾／過時說法不歸 Lint 管，責任交還使用者（第四節）。
不列入待決、只是未經檢驗的旁支觀察：
- raw/ 不變性檢查的 CRLF 正規化雜訊——這是我單方面加進來的，沒有討論過，證據也有誇大（見第三節旁支觀察）。
可執行待辦（含觸發保證、窄範圍反查、第六項）已搬到 chaos/Ingest／Query／Lint 重新審視 待辦.md 統一管理，這裡不重複列，避免兩份檔案內容互相漂移。這份檔案只保留推導過程與判準本身。