分析完成。以下是逐段的 context audit，沒有動任何檔案。
先講三個結構性發現
這三點是逐段分類的前提，比單段歸類更重要。
- 依賴方向是反的。 五支 skill 在自己的「相關規則」段落把規格指回 CLAUDE.md：hoard-ingest 說「歸屬判準、frontmatter、raw 不變性、index/log 規則見 CLAUDE.md」，hoard-commit 的 frontmatter 允許值、hoard-promote 的 chaos 檔案類型、hoard-public-site-sync 的排除範圍、hoard-archive 的 raw 不變性，都是同樣寫法。skill 是按需載入的，它的規格卻被迫常駐在 global 檔裡，這是 CLAUDE.md 膨脹的主因。只要把「skill 專用的規格」搬進 skill，CLAUDE.md 至少有四成內容可以只留 routing。
- 同一個物件的規則散在四個地方。 「wiki 頁面」的規格分別在「正式知識」、「Frontmatter 慣例」、「連結慣例」、以及 hoard-commit 步驟 3 的 Lint 規格；「raw/assets 生命週期」在目錄樹、raw 段、Clippings 段各說一次；「evergreen／project」分類在目錄樹、wiki 段、常青與專案段說三次。規則沒有標示適用對象，chaos 捕捉檔記錄的「頁面命名規則被拿去否決主題命名」就是這個結構的直接症狀，不是單次失誤。
- always-loaded 的預算不只 CLAUDE.md。 11 支 skill 的 description 在每個 session 開頭都會進 context，我這次確認全部看得到。它們總共約 3300 字，接近 CLAUDE.md 本文的一半，而且大多在複述步驟而非只寫觸發條件。CLAUDE.md 的「工作流程」「Git」「Promote」「同步」四段又把同樣的 routing 再寫一次。routing 目前是雙層重複的。
另外兩個小發現：log.md 檔首寫的格式是「類型｜範圍｜說明」三欄，CLAUDE.md 寫的是「type｜摘要」兩欄，兩份規格已經漂移，aw/projects/iThome鐵人賽2026-舊方向/CLAUDE.md 是一份舊規則快照，Claude Code 會在讀取子目錄檔案時按需載入該目錄的 CLAUDE.md，Ingest 舊方向素材時有可能被注入過期規則。raw/ 不可改名，這點值得實測確認再決定怎麼處理。
逐段分類
段落: 開頭角色定義
分類: 保留 global
為什麼需要／不需要常駐: 每個任務的行為框架，
去向: 原地
────────────────────────────────────────
段落: 核心架構目錄樹
分類: 保留 global
為什麼需要／不需要常駐: 這就是 routing map 本體。但缺 xcripts/、.claude/skills/，wiki/entities/
存在卻是空目錄且未記載。
去向: 原地，補齊或清掉缺漏
────────────────────────────────────────
段落: raw/ 只新增不修改
分類: 保留 global
為什麼需要／不需要常駐: 硬性不變條件，任何任務都可能碰到 raw 檔案，違反代價高。
去向: 留一句
────────────────────────────────────────
段落: raw/assets 歸類搬出例外的細節
分類: 移到既有 skill
為什麼需要／不需要常駐: 只在 promote／commit 3.1 與 hoard-status 4
已用可機械判定的形式各寫一份。
去向: hoard-commit 為單一來源
────────────────────────────────────────
段落: 「使用者創作也可作原始來源、走 Ingest」
分類: 移到既有 skill
為什麼需要／不需要常駐: 只有 Ingest 決定歸屬時用到。
去向: hoard-ingest
────────────────────────────────────────
段落: raw/雜記寶庫 段（本次新增、未 commit）
分類: 移到按需文件
為什麼需要／不需要常駐: 目錄本地規則，它自己 位與 append-only 說明，兩邊會再漂移。global
只需要「不經 Ingest」這一個 routing 事實。
去向: 目錄樹一行 + 該 index.md 檔首
────────────────────────────────────────
段落: Clippings/
分類: 改成 routing
為什麼需要／不需要常駐: 內容就是「性質同 raw/assets」，目錄樹註解已經說了。
去向: 併入目錄樹
────────────────────────────────────────
段落: wiki/ 定位、使用者可直接編輯
分類: 保留 global
為什麼需要／不需要常駐: 前者是 routing，後者告訴 AI
檔案可能被人改過、不能憑記憶。與「常青與專案
去向: 合併
────────────────────────────────────────
段落: 交叉引用硬性要求
分類: 目前無法判斷
為什麼需要／不需要常駐: 是 wiki 頁面物件規格是「直接編輯 wiki 頁面」不一定經過
bal，要嘛跟 frontmatter／連結慣例一起搬成「wiki 頁面規格」單一文件並在 global 留 routing。
去向: 見下方
────────────────────────────────────────
段落: 索引與 log 可延後同步
分類: 移到既有 skill
為什麼需要／不需要常駐: 只有 ingest／commit 關心；hoard-commit 步驟 4 已是「補上 index」的機制。
去向: hoard-commit
────────────────────────────────────────
段落: 文章正文先給草稿
分類: 目前無法判斷
為什麼需要／不需要常駐: 行為邊界而非規格，違反代價高（改掉使用者創作），而且沒有對應 skill。但只在共筆文章時適用。
去向: 見下方
────────────────────────────────────────
段落: 常青與專案
分類: 保留 global
為什麼需要／不需要常駐: status 欄位與 index 歸檔那句已由 hoard-archive 承接。
去向: 與 wiki 段合併
────────────────────────────────────────
段落: 建設歷程 收錄門檻
分類: 改成 routing
為什麼需要／不需要常駐: 觸發條件必須 global，否則 AI
不會提議記錄。但「什麼算重大」本身是語意判斷，這段無法變成機械判準，只能保持短。
去向: 留門檻兩條
────────────────────────────────────────
段落: 建設歷程 記錄內容（背景／決策／結果）
分類: 移到按需文件
為什麼需要／不需要常駐: 只有實際寫決策紀錄時需要格式。hoard-promote 步驟 5 已指向「對應決策歷程頁」。
去向: 建設歷程路由頁檔首
────────────────────────────────────────
段落: chaos/ 定位與豁免
分類: 保留 global
為什麼需要／不需要常駐: 任何任務都可能寫入 chaos，必須知道它不受 raw／lint 約束。
去向: 留一句
────────────────────────────────────────
段落: chaos 檔案類型（常駐型／任務型）
分類: 移到既有 skill
為什麼需要／不需要常駐: 唯一消費者是 hoard-promote 的收尾步驟，而該 skill 現在反過來指回 CLAUDE.md。
去向: hoard-promote
────────────────────────────────────────
段落: chaos 共通規則（整理口述以原意為主、不主動整理、先 checklist 再討論）
分類: 目前無法判斷
為什麼需要／不需要常駐: 前兩條是每次「記到白板」都會用到的行為邊界，第三條是工作流程。沒有捕捉用的 skill 可以承接。
去向: 見下方
────────────────────────────────────────
段落: Promote 段
分類: 保留 global
為什麼需要／不需要常駐: 已是正確的 routing 形式：觸發條件 + 去向。
去向: 範本
────────────────────────────────────────
段落: 素材庫 materials/
分類: 改成 routing
為什麼需要／不需要常駐: global 只需要「AI 預設不讀、不整理」。捕捉原則、結構、生命週期都是目錄本地規則。困難在
materials/ 規定不放 index 與 README，所以按需文件沒有自然落點。
去向: 留一句，其餘搬到 hoard-materials-sync 或架構與流程頁
────────────────────────────────────────
段落: 圖片資產 memes/photos
分類: 改成 routing
為什麼需要／不需要常駐: 由使用者自行加入，AI 幾乎不碰；唯一 AI 相關的「仍納入 commit」已在 hoard-commit 步驟 6。
去向: 目錄樹兩行
────────────────────────────────────────
段落: 公開站 排除範圍
分類: 移到既有 skill
為什麼需要／不需要常駐: 只在同步時套用，而 hoard-public-site-sync 宣告 CLAUDE.md
是它的「唯一規格來源」，這是反向依賴的最清楚措辭」的要求，因為 skill 也會鏡像公開。
c
────────────────────────────────────────
段落: 公開站 存在事實與同步觸發
分類: 改成 routing
為什麼需要／不需要常駐: AI 需要知道有公開站、不得自動 push。
去向: 留兩句
────────────────────────────────────────
段落: 與 AI 協作的溝通風格
分類: 保留 global
為什麼需要／不需要常駐: 純行為規則，每次對話都適用，這段是 global 的正確樣子。
去向: 原地
────────────────────────────────────────
段落: CLAUDE.md 寫作準則
分類: 移到按需文件
為什麼需要／不需要常駐: 只在修改 CLAUDE.md 這種任務。而且它目前只管 CLAUDE.md，skill
沒有同等的寫作標準。
去向: 獨立文件 + 一行 routing
────────────────────────────────────────
段落: Frontmatter 慣例
分類: 移到按需文件
為什麼需要／不需要常駐: wiki 頁面物件規格，Lint 消費。status 一整段軸線說明與 sources
的驗證備注是理由不是行為，違反本檔自己的準則第二條。
去向: wiki 頁面規格文件或 hoard-commit
────────────────────────────────────────
段落: 連結慣例
分類: 移到按需文件
為什麼需要／不需要常駐: 同上。並且要明確標示適用對象是「頁面」，主題與專案名稱不在此規則內。
去向: 同上
────────────────────────────────────────
段落: index.md 定位
分類: 保留 global
為什麼需要／不需要常駐: Ingest 與 Query 的第
去向: 留一句
────────────────────────────────────────
段落: index.md 更新時機、範圍宣告、路由頁門
分類: 移到按需文件
為什麼需要／不需要常駐: 範圍宣告由 hoard-ingest 步驟 2 消費；2000／800 字元門檻純機械，可以直接寫在 index.md
檔首，Ingest 與 Query 開頭本來就會讀這個檔。
去向: index.md 檔首 + hoard-ingest
────────────────────────────────────────
段落: log.md 維護規則
分類: 移到按需文件
為什麼需要／不需要常駐: log.md 檔首已有格式與 append-only 說明，且兩邊格式已漂移；歸檔機制在 hoard-commit 步驟 5。
去向: log.md 檔首為單一來源
────────────────────────────────────────
段落: 工作流程 + Git
分類: 改成 routing
為什麼需要／不需要常駐: 應合併成一張「觸發條件 → skill」對照表；目前 Lint 與 commit 是同一件事卻寫兩次，而
archive、status、pull、polish、title、materials-sync 沒有被列入。
去向: 單一 routing 表
────────────────────────────────────────
段落: 語言慣例
分類: 保留 global
為什麼需要／不需要常駐: 每次輸出都用到，一行。
去向: 原地
無法判斷的三項，各附我的傾向
- wiki 頁面規格要不要留一份 global 摘要。 傾向不留。理由是它已經由 Lint 在 commit 時機械驗證，這正是 harness 的作法。代價是 AI 寫頁面時可能先寫錯再被 Lint 打回，但修正成本低。
- 「文章正文先給草稿」與 chaos 共通規則。 傾向留 global，因為兩者都是「不要碰使用者創作內容」這類行為邊界，違反代價高，篇幅小。若之後 Claude Code 版本支援依路徑套用的 rules 檔案，再考慮搬到路徑範圍。
- CLAUDE.md 是否繼續同時服務公開站讀者與鐵人賽教材。 這個決定會改變整份文件的性質。目前有七處「理由見」「決策脈絡見」的 wikilink 指標，對模型是死重量，因為 CLAUDE.md 裡的 wikilink 沒有路徑、任務中也不該去追。這些只對人類讀者有用。如果要保留讀者用途，建議把 rationale 指標集中到文件尾端或另立說明頁，不要混在規
- 先定義新的 Context 架構 ：
Global
「任何情境開始前都必須知道什麼？」
Routing
「現在這個情境，接下來去哪裡取得 context？」
Workflow context
「這個動作要怎麼完成？」
Object / Domain spec
「被操作的東西本身有什麼規則？」
然後它們之間的依賴方向應該是：
Global
↓
Routing
↓
Workflow
↓
需要時引用 Object spec
例如：
CLAUDE.md
「要求收錄來源 → hoard-ingest」
hoard-ingest
「步驟 1 → 2 → 3
在判斷 wiki 頁面時讀 wiki-page spec」
wiki-page spec
「frontmatter 合法值
wikilink 規則
page naming
cross-reference 要求」
- Audit CLAUDE.md，但只做「分類」，不改寫
Schema 層（回答：要不要引入）
要，但不是載入鏈外新增第五層，是 Object spec 內部該統一的書寫格式。現在 Object spec 都是自由 prose，這正是根因案例（「成功」被誤套用頁面命名規則到主題命名）的成因：規則沒有標明適用範圍，AI 只能自己猜規則管到哪。
每份 Object spec 建議統一套這個骨架：
Object: <物件名稱>
適用範圍: <明確排除鄰近但不適用的情境，例如「僅限個別頁面命名，不含 topic/project 目錄名稱」>
規格本體: <欄位、允許值、格式>
消費者: <哪些 workflow／情境會讀它——同時是判斷「該不該獨立成 spec」的依據：2 個以上消費者就該獨立>
驗證方式: 機械（Lint 可直接查）/ 語意（需要 AI 當下判斷，不能自動化）
「消費者」欄位順便解決識別問題：兩個以上消費者，代表複製風險已經存在。「驗證方式」欄位是第 8 步（Hook 化）要用的分類，先在這裡標好，不用等到那一步重新盤點。這個骨架只在寫 Object spec 檔案本身時套用，Global／Routing 層的常駐成本不受影響。
CLAUDE.md 逐段重新分類（依六類架構，不標去向）
上一輪報告的「目前無法判斷」三項，這次歸類都已解決：交叉引用硬性要求→Object spec；文章正文先給草稿→Global；chaos 共通規則三條→Global。
| 段落 | 類別 | 備註 |
|---|---|---|
| 開頭角色定義 | Global | |
| 核心架構目錄樹 | Global | |
| raw/ 只新增不修改（鐵律本身） | Global | 違反代價高，不限特定 skill |
| raw/ 合法來源範疇（使用者創作也算、走 Ingest） | Object spec | raw/ 物件的範疇定義，不是程序 |
| raw/assets 歸類搬出例外（git mv、100% 相似度判準） | Object spec | 消費者：Ingest／Promote／Commit(Lint)／Status，4 個以上 |
| raw/雜記寶庫 存在事實＋不經 Ingest | Routing | 只需要「這裡不用 Ingest」這個事實 |
| raw/雜記寶庫 index.md 格式細節 | Remove/duplicate | 該檔自己的檔首已是規格本體，CLAUDE.md 重複寫一次 |
| Clippings/ | Routing | 短指標：同 raw/assets |
| wiki/ 定位 | Global | |
| 使用者可直接編輯 wiki | Global | |
| 交叉引用硬性要求 | Object spec | 消費者：Ingest／Commit(Lint)／使用者手動編輯 |
| 索引與 log 可延後同步 | Workflow | 屬於 hoard-commit「什麼時候該擋」的判斷，非物件規格 |
| 文章正文先給草稿 | Global | 行為邊界，違反代價高，不限特定 skill |
| 常青與專案（evergreen/project 定義＋目錄對應） | Global | 跟目錄樹綁在一起的基礎知識；status 欄位細部語意屬於 Frontmatter 這份 Object spec |
| 建設歷程 收錄門檻 | Routing | 語意判斷但功能是觸發＋去向 |
| 建設歷程 記錄內容格式（背景/決策/結果） | Object spec | 候選：可比照 log.md 模式自我描述在建設歷程路由頁檔首 |
| chaos/ 定位與豁免 | Global | |
| chaos 檔案類型（常駐型/任務型） | Object spec | 消費者：Promote 收尾＋任何直接寫入白板/想法的情境，2 個以上 |
| chaos 共通規則三條 | Global | 三條都是行為預設，違反代價高，不是物件規格 |
| Promote 觸發段 | Routing | |
| 素材庫 不主動讀取整理 | Global | |
| 素材庫 捕捉原則/結構/生命週期 | Object spec | |
| 圖片資產 基本事實（扁平結構、不受交叉引用約束） | Global | 短事實 |
| 圖片資產「仍要納入 commit」這句 | Remove/duplicate | hoard-commit 自己的「相關規則」段已經寫過同一句 |
| 公開站 排除範圍四條 | Object spec | 目前唯一消費者 hoard-public-site-sync，邊界案例 |
| 公開站 存在事實與同步觸發 | Routing | |
| 與 AI 協作的溝通風格 | Global | |
| CLAUDE.md／skill 寫作準則 | Object spec | 物件是「CLAUDE.md／skill 檔案本身」，不是特定 workflow 的步驟 |
| Frontmatter 慣例 | Object spec | 消費者：Ingest／Commit(Lint)／使用者手動編輯 |
| 連結慣例 | Object spec | 適用範圍要明講「僅頁面命名」，這正是根因案例要補的欄位 |
| index.md 定位 | Global | |
| index.md 更新時機/範圍宣告/路由頁門檻 | Object spec | 候選：比照 log.md 自我描述在 index.md 檔首 |
| log.md 維護規則 | Object spec | 格式部分已跟 log.md 檔首本身漂移，見下一列 |
| log.md 格式：CLAUDE.md 兩欄 vs log.md 檔首三欄 | Remove/duplicate | 兩份互相矛盾，需先裁定哪份對，不能直接當成「已有 canonical」搬走 |
| 工作流程＋Git 觸發條件段 | Routing | 但跟 skill description 重複，見下一列 |
| 工作流程＋Git 段跟 skill description 重複的部分 | Remove/duplicate | skill description 已常駐且更詳細，這段等於雙重 Routing |
| 語言慣例 | Global | |
| 七處「決策過程見／決策脈絡見」wikilink | Human-facing rationale | 對模型是死重量，只對人類讀者有用 |
上一輪誤塞進 skill 的內容，這次標記為 Remove/duplicate
上一輪直接編輯了五支 skill，把 Object spec 內容複製進去，正好是「消費者 ≥ 2」判準要抓的錯誤示範：
| 位置 | 內容 | 對應哪個 Object spec |
|---|---|---|
| hoard-commit | type/status 允許值字面值 | wiki 頁面 frontmatter |
| hoard-ingest | frontmatter 六欄位清單＋列舉值 | wiki 頁面 frontmatter |
| hoard-ingest | 常青主題範圍宣告規則 | index.md spec |
| hoard-ingest | 路由頁 2000/800 門檻 | index.md spec |
| hoard-ingest | log.md 條目格式 | log.md spec，且用的是已跟 log.md 檔首漂移的兩欄格式，等於複製了一份已經錯的版本 |
| hoard-promote | 常駐型/任務型定義 | chaos 捕捉檔 spec |
| hoard-public-site-sync | 排除範圍四條 | 公開站排除範圍 spec，目前逐字一致，但物理上是第二份副本 |
這七處之後要收斂成：skill 只留步驟本身＋「需要時讀 XX spec」的指標，不留規格內容。hoard-archive 上一輪只是拿掉指標、沒有複製內容，不在此列。
「消費者」欄位這次不保證窮盡——真正列全每個 Object spec 的消費者，要等第 5 步逐支重讀 skill 本體時才能確認，這裡先給第一輪判斷依據。
- 先處理 CLAUDE.md 的 Global + Routing
這是第一個真正修改檔案的階段。
目標不是「變短」，而是讓它只剩：
角色
全域行為
高風險 invariant
repo map
routing table
少量永遠適用的 boundary
先把 CLAUDE.md 從「規格書」變回「入口」。
- Audit 所有 Skill 的 description
這一步要放在 Skill 內容之前。
因為 description 本身 always-loaded。
只問：
這段 description 是否只足以讓 Claude 判斷「什麼時候該載入這支 Skill」？
凡是流程、細節、規則，都往 Skill 內部搬。
這一步可能很便宜，context 收益卻很大。
- 再 Audit Skill 本體
這時才逐支看：
hoard-ingesthoard-queryhoard-commithoard-promote- …
每支只問三件事：
它需要什麼 context？
它目前是不是反向依賴 CLAUDE.md？
它有沒有承載其實不屬於 workflow 的 domain spec？
- 把 Object / Domain spec 獨立出來
這是我認為報告裡還沒完全解決的一層。
例如：
wiki page spec
topic spec
raw/assets lifecycle
index.md spec
log.md spec
這些不應硬塞進某一支 Skill。
做到：
Skill
→ 需要時讀 canonical spec
而不是：
Skill A
Skill B
Skill C
→ 各自複製同一條規則
- 處理重複與 spec drift
這時才修：
log.mdvs CLAUDE.md 格式不同- raw 規則多份
- evergreen/project 定義多份
- public-site 規格重複
原則就是：
一條規則只能有一個 canonical source。
- 最後才處理 Hooks / 機械化
不要太早碰 Hooks。
等 context 結構穩定後再問：
哪些事情根本不該讓 LLM 判斷？
例如：
Lint
raw immutability
frontmatter schema
Git commit gate
這時才搬成 Hook / script / validation。
- 用真實 failure 做 regression test
最後不要只看「架構變漂亮」。
拿過去出錯的案例測：
「成功」當 topic 名稱
→ 是否還會誤引用 page naming rule？
Query candidate skip
→ 是否仍可觀察？
public-site sync
→ 是否只載入同步規則？
一般聊天
→ 是否完全看不到 public-site / lint 等無關細節？
如果壓成一句話，就是：
先決定 context 分層 → 清 CLAUDE.md → 清 Skill descriptions → 清 Skill 本體 → 建單一規格來源 → 去重 → 最後才用 Hooks 機械化。
尚待定位的內容（第 3 步搬移，2026-09-15）
第 6 步執行狀態（2026-09-15 更新）
以下每一節現在都已經有永久位置，逐項對照：
| 節 | 永久位置 |
|---|---|
| raw/ 合法來源範疇＋assets 搬出例外 | .claude/specs/raw-lifecycle.md |
| wiki 頁面：交叉引用硬性要求 | .claude/specs/wiki-page.md |
| 建設歷程 記錄內容格式 | wiki/evergreen/topics/DragonsHoard建設歷程/DragonsHoard建設歷程.md 檔首自我描述 |
| chaos 捕捉檔 spec | .claude/specs/chaos-capture.md |
| 素材庫 materials/ 捕捉原則 | .claude/specs/materials.md |
| CLAUDE.md／skill 寫作準則 | .claude/specs/claude-authoring.md |
| Frontmatter 慣例 | .claude/specs/wiki-page.md |
| 連結慣例（含根因案例的適用範圍修正） | .claude/specs/wiki-page.md，已補上「僅限頁面命名，不含主題/專案目錄名稱」 |
| index.md 更新時機／範圍宣告／路由頁門檻 | wiki/index.md 檔首自我描述 |
| log.md 維護規則 | 不用搬——查證後 wiki/log.md 檔首從建庫第一筆起就是正確的三欄格式，drift 其實是 CLAUDE.md 舊版寫錯（漏寫「範圍」欄），從未被實際遵守過。hoard-ingest 步驟 5、hoard-commit 等處已改成「讀 log.md 檔首當下格式」而不是硬寫死格式 |
| 公開站 排除範圍四條 | 維持原判斷，不獨立——只有 hoard-public-site-sync 一個消費者，canonical 版本留在該 skill 步驟 4，這份 CLAUDE.md 舊版拷貝作廢 |
| 索引與 log 可延後同步 | 不需要獨立處理，hoard-commit 步驟 4／5 的設計（批次檢查、有門檻才觸發歸檔）已經體現這個政策，不用另外寫一條 |
hoard-commit／hoard-ingest／hoard-promote／hoard-status 四支 skill 的內嵌內容已改成指向對應 spec 的指標；hoard-public-site-sync 依上表維持內嵌（唯一消費者）。
「chaos 內容整理流程：先 checklist 再討論」（2026-09-15 使用者確認廢除）：使用者指出這條規則實際上沒有被真正遵守過，而且判定不需要這個流程——不是漏做了值得補的 Workflow，是這條規則本身不該存在。不建 skill、不保留、不再視為待解決事項，跟「先 checklist 再討論」相關的舊 memory（feedback_whiteboard_checklist_discuss.md）也需要一併更新，見下方原文段落的更新註記。
以下維持原文，作為稽核紀錄與上表核對用，不刪除。
CLAUDE.md 這次已經瘦身成只剩 Global＋Routing（見該檔案現在的內容）。以下是從舊版逐字搬出來的段落，依上一節的分類標記，還沒有決定永久位置——不是獨立 spec 文件就是某個物件檔案自我描述（像 log.md／index.md 檔首），要等步驟 6、7 才定案。這裡先保留原文，避免刪除後要嘛你自己回憶重建、要嘛我從備份重讀重建。
raw/ 合法來源範疇＋assets 搬出例外〔Object spec〕
來源不限外部資料；使用者自己的創作、理解、心得與反思也可作為原始來源，走相同的 Ingest 流程。
路徑搬移僅限於
raw/assets/（尚未歸類或來源附帶的圖片等附件，不視為正式 wiki 內容）歸類搬出這個生命週期操作，且須以git mv保留歷史、確保內容不變。
消費者：Ingest／Promote／Commit(Lint)／Status，4 個以上。hoard-status 步驟 4 目前引用「見 CLAUDE.md「raw/」相關規則」，已經改成指向這裡（暫時性指標，步驟 6 定案後要再改一次指向正式 spec 路徑）。
wiki 頁面：交叉引用硬性要求〔Object spec〕
交叉引用是硬性要求：不論內容如何加入，最終都必須補齊相關交叉引用；缺漏可由 Lint 與後續維護補正。
消費者：Ingest（建立）／Commit(Lint 驗證)／使用者手動編輯。
索引與 log 可延後同步〔Workflow〕
索引與 log 可延後同步：
wiki/index.md與wiki/log.md不要求每次編輯立即更新，可批次處理。
屬於 hoard-commit「什麼時候該擋」的判斷，步驟 5 audit skill 本體時處理，看是否已經被步驟 4／5 的機械描述涵蓋。
建設歷程 記錄內容格式（背景/決策/結果）〔Object spec〕
每筆紀錄應盡量交代：
- 背景：為什麼需要改，當時要解決什麼問題或限制。
- 決策：最後採取什麼做法；若有重要替代方案，可一併記錄取捨理由。
- 結果：最後實際變成什麼樣，以及產生的影響或副作用。
只有「沒有值得記的替代方案」或「太新還沒有結果」這兩種情況可省略對應部分，其餘情況盡量寫齊。決策過程見 協作與元規則「二十一」。
候選位置：比照 log.md 模式，自我描述在 wiki/evergreen/topics/DragonsHoard建設歷程/DragonsHoard建設歷程.md 路由頁檔首。
chaos 捕捉檔 spec：可放什麼＋常駐型／任務型〔Object spec〕
chaos/可直接收錄想法、片段與未整理內容，不要求先分類或寫成完整文章。
- 常駐型：如
白板.md（通用發想，不限主題）、想法.md（跨領域想法暫存）。持續收集內容，不整份清空或畢業；新增其他常駐捕捉檔時，需在檔案開頭說明收錄範圍。- 任務型：綁定單一文章或任務的暫存檔。內容整理完成後刪除整份檔案。
消費者：Promote 收尾步驟＋任何直接寫入白板/想法的情境，2 個以上。
（2026-09-15 更新：原本跟這條混在 CLAUDE.md「chaos 共通規則」同一段的另外兩塊——「整理使用者口述時尊重原意」已提升為 Global，直接寫進新版 CLAUDE.md 行為邊界；「使用者明確要求整理時先 checklist 再討論」拆到下面新增的 Workflow 條目，三層混在一起這個結構問題本身也是使用者指出的。）
chaos 內容整理流程：先 checklist 再討論〔已廢除，2026-09-15〕
AI 預設不主動整理 chaos 內容；使用者明確要求處理時，先整理成- [ ]checklist，再與使用者討論優先順序與做法，不跳過討論直接執行。
使用者確認：這條規則實際上沒有被真正遵守過，而且不需要這個流程。這裡做一個未經使用者逐句確認的判斷：「AI 預設不主動整理 chaos 內容」跟「先 checklist 再討論」是兩件事——後者（程序）確定廢除；前者（不主動介入的預設）判斷應該保留，理由是它跟 materials/「AI 預設不主動讀取或整理」是同一種模式，拿掉會讓 AI 有理由主動去動使用者的草稿本。已補進 CLAUDE.md 行為邊界；如果使用者的意思其實是連這句也一併廢除，之後要再拿掉。不建 skill、不搬進任何 spec。
素材庫 materials/ 捕捉原則／結構／生命週期〔Object spec〕
- 收錄內容：自己的念頭、個人經歷片段，以及外部素材引發的反應；外部素材原文或原檔本身仍歸
raw/。- 捕捉原則：不去重、不分類、不標矛盾，也不因時間久而清理；允許大量累積。
- 結構：一則素材一個檔案，檔名即內容摘要；不用 frontmatter、tags 或
index.md。- 生命週期：開始實際處理時移入
chaos/，比照任務型捕捉檔；若停止處理則移回materials/，不刪除。定位與手機同步方案見 架構與流程「三十」「三十一」。
「不受 wiki 交叉引用／矛盾比對／孤兒頁面規則約束」與「AI 預設不主動整理」這兩條屬於 Global（跟 chaos/ 的豁免宣告同一類），已經留在新版 CLAUDE.md 目錄樹註解裡，不在此重複搬移。
公開站 排除範圍四條〔Object spec，邊界案例〕
（這裡原本逐字引用了 public-site-eligibility.md 的排除規則原文；公開版不重複列出具體排除類別，避免規則本身反洩漏排除了什麼——完整原文只留在私有的 master 分支。）
目前唯一消費者是 hoard-public-site-sync，該 skill 步驟 4 已經逐字內嵌同一份文字——物理上是兩份拷貝，步驟 6/7 要收斂成一份，這裡先保留 CLAUDE.md 原版供比對。
CLAUDE.md／skill 寫作準則〔Object spec：物件是 CLAUDE.md／skill 檔案本身〕
新增或修改規則時，遵守以下原則：
- 可執行：觸發條件應能明確判斷，不依賴 AI 自行猜測是否適用；執行結果應可驗證。
- 只寫行為：CLAUDE.md 只描述「要做什麼」；設計理由、事故經過與理論說明放在對應文件，必要時僅保留連結。
- 判準明確：多步驟或條件式規則應明確定義條件與動作；分支盡量互斥且完整，避免抽象或需要額外推論的描述。
- 保持扁平：優先使用直接的「條件 → 動作」敘述；簡稱只定義一次，例子只作補充，不取代正式判準。
這份準則自己也該套用 schema 骨架重寫——目前第 2 條本身就違反「只寫行為」（混了理由），是個現成的示範案例。
Frontmatter 慣例（wiki 頁面 spec 的一部分）〔Object spec〕
每個 wiki 頁面使用 YAML frontmatter：
--- type: index | topic | decision-log | article status: evergreen | active | archived tags: [tag1, tag2] created: 2026-07-29 updated: 2026-07-29 sources: 3 ---
type描述頁面的內容形態，可擴充；只有當新類型需要不同的實際處理方式時才新增。
index：路由／樞紐頁topic：主題參考或框架頁decision-log：依時間或編號累積的決策紀錄article：對外發表的創作正文
status只表示頁面所屬的 track 層級，值固定為evergreen、active、archived，不得自行擴充，語意對應「常青與專案」一節定義的 evergreen／wiki 專案 active／archived 三種軌道；文件本身寫完了沒屬於另一條獨立軸線，不由這個欄位承擔，需要追蹤時另用專案路由頁的進度表。
sources表示這個頁面目前內容所源自的、不重複raw/路徑數量，由 Ingest 於寫入或更新頁面時依實際用到的來源計算並維護；Lint 只驗證型別（非負整數），不驗證正確性。
消費者：Ingest（建立）／Commit(Lint 驗證，目前 hoard-commit 已內嵌一份 type/status 列舉值副本，屬於待清理的 Remove/duplicate）／使用者手動編輯。
連結慣例（wiki 頁面 spec 的一部分，⚠️根因案例相關）〔Object spec〕
交叉引用使用 Obsidian Wikilink
[[頁面名稱]]，不用相對路徑 Markdown link。
新頁面至少要有一個既有頁面連入，並至少連向一個既有頁面，避免成為孤立節點。
頁面名稱應盡量唯一且具體，避免使用[[研究]]這類泛稱。
步驟 6 重寫時務必加上「適用範圍」欄位：最後一句「頁面名稱應盡量唯一且具體」只管個別 wiki 頁面命名，不含 topic/project 目錄名稱——這正是根因案例（「成功」被誤套用成否決主題命名的理由）缺的那個欄位，套用 schema 骨架時不能省略。
index.md 更新時機／範圍宣告／路由頁門檻〔Object spec〕
頁面新增、歸屬改變，或摘要／路由資訊受影響時，更新
wiki/index.md。每個常青主題都必須有一句範圍宣告，說明該主題「收什麼、不收什麼」。範圍宣告定義的是主題本身的邊界，不得依目前已有頁面反推；Ingest 判斷新內容歸屬時，以此為主要依據。
index.md應維持頂層目錄的簡潔。單一主題或專案區塊超過 2000 字元，或其中單一 bullet 超過 800 字元，任一觸發即將該區塊子頁清單搬至獨立路由頁。搬移後，頂層index.md只保留主題／專案名稱、範圍宣告，以及指向路由頁的連結；路由頁負責維護各子頁的「連結＋一句話摘要」。
候選位置：比照 log.md 模式，自我描述在 wiki/index.md 檔首。消費者：Ingest 寫入後判斷／Commit 檢查是否跟上。
log.md 維護規則〔Object spec，⚠️含 drift〕
wiki/log.md是 append-only 的操作時間軸，每筆紀錄使用：## [YYYY-MM-DD] <type> | <摘要>
type可為ingest、query、archive、infra；需要時可在摘要前加入相關路徑或專案名稱。新紀錄一律追加於檔案末尾。既有紀錄不得竄改；唯一允許將既有紀錄移出本檔的操作是歸檔——依原順序逐字搬至同樣 append-only 的
wiki/log-archive.md。除歸檔外，不得修改、刪除既有紀錄。完整稽核追溯以 Git 為主，因此log.md可寬鬆、批次更新，不應阻塞主要流程。
Drift 警告：wiki/log.md 檔首目前實際寫的格式是「類型｜範圍｜說明」三欄（## [YYYY-MM-DD] 類型 | 範圍 | 說明），跟上面這份兩欄格式（type | 摘要）不一致。步驟 7 處理 drift 時要先問使用者哪份才是對的（log.md 檔首是使用者可直接編輯的內容，有可能是使用者自己改過但沒同步回 CLAUDE.md），不能未經確認就直接當其中一份是 canonical 搬走。hoard-ingest 上一輪已經內嵌了一份兩欄格式（等於複製了可能已經錯的版本），這處也要一併修。