claude.md 規則精修 捕捉

CLAUDE.md 規則精修捕捉檔

單篇任務型捕捉檔，綁定這次針對 CLAUDE.md 規則層的精修討論（角色過載、內部矛盾、可執行性等）。討論定案後併入 CLAUDE.md 本體與（若有決策價值）DragonsHoard建設歷程，整份刪除，不保留本體。

背景：CLAUDE.md 角色過載（2026-09-06）

• 觀察：CLAUDE.md 同時扮演系統憲法／檔案系統規格／Wiki schema／Ingest SOP／Query 演算法／Lint spec／Git 操作手冊／Chaos-Materials 手冊／決策紀錄入口，共九種角色。
• 判斷：角色多不是問題本身；問題在於 Ingest／Query／Lint 把完整演算法內嵌在 CLAUDE.md，違反寫作準則自訂的「只寫行為，不寫怎麼做」。
• 對照組：Git 操作手冊已經示範外部化模式——CLAUDE.md 只留觸發條件＋一句話指向 skill，實質規則放 hoard-commit／hoard-pull／hoard-status。

決定：Ingest／Query／Lint 卸載到 Skill（2026-09-06，已定案並執行）

• 既有相反決策：這個分工問題過去被討論過，且結論跟這次相反——
  • Query（觸發機制演變「三十」）最初決定 CLAUDE.md 保留完整定義、skill 當薄殼，理由是「避免兩邊各存一份程序」；「四十三」改寫時刻意反過來寫（維持 CLAUDE.md 為唯一權威版本），但明講是刻意擱置分工問題，因為當時 CLAUDE.md 精簡 Query 那段的過程本身可能是鐵人系列文章的素材，要先讓內容定案再回頭處理落地位置。
  • Lint 最近一次重寫（拿掉 checkpoint、改五項純結構驗證）才剛重新確認「CLAUDE.md 是唯一規格來源，skill 只是 pointer」。
  • Ingest 曾提案整個搬進新 skill，使用者當時否決——但否決理由是「當時只是要塞一句話大小的小規則，開新 skill 是殺雞用牛刀」，不是「Ingest 不該進 skill」的一般性判斷。
• 視野已變：使用者確認當時判斷視野太窄。現在有 chaos/第六七篇 CLAUDE.md 捕捉.md 整理出的五層機制模型篩選框架可用——CLAUDE.md 收錄門檻是「高頻＋不可推斷」兩個必要條件都要滿足；通過篩選後，「多步驟只在特定任務觸發的程序」屬於卸載給 Skill 的角色，不該留在 CLAUDE.md。Ingest／Query／Lint 完整演算法正是這種「程序型知識」，跟框架結論直接衝突，該篇捕捉檔「順便發現」段落已經點出這點（見該檔第 75 行）。
• 擱置理由已解除：查證 第九篇 - Ingest：把資料丟進知識庫.md（102 行）、第十六篇 - Query 的手段：優缺點與使用情境.md（141 行）都已是有實質內容的獨立草稿，不再需要靠 CLAUDE.md 正文本身當鐵人文章的孵化素材，「四十三」當時擱置分工問題的理由不再成立。
• 決定：Ingest／Query／Lint 三個工作流程的完整演算法搬到對應 skill（Lint→hoard-commit、Query→hoard-query、Ingest→新建 hoard-ingest），CLAUDE.md 只留觸發條件＋一句話指向，比照 Git 那組已經驗證過的模式。
• Ingest 觸發模式的額外決定：不比照 hoard-query（純手動 /hoard-query），而是比照 hoard-commit「AI 主動判斷情境呼叫」——但更精確地說是「使用者明確要求，或 AI 主動提議且經使用者同意」兩種路徑，觸發後直接執行不用再問一次，跟現有 commit 建議機制（Git 段落「可以主動建議建立 commit，但不得未經使用者要求自行 commit」）同一套邏輯，維持現有使用體驗不倒退。
• 已執行：
  • CLAUDE.md「工作流程」三節（Ingest／Query／Lint）收斂成各一句話觸發條件＋指向 skill，331 行縮到 248 行。
  • 新建 .claude/skills/hoard-ingest/SKILL.md，含完整 6 步驟與觸發模式說明。
  • hoard-query/SKILL.md 內容從薄殼改成收納完整 4 步驟演算法（限縮範圍／閱讀門檻／找到內容／無命中判定與回報），frontmatter description 不變。
  • hoard-commit/SKILL.md 步驟 3 改成收納完整五項 Lint 結構檢查，「相關規則」段落同步把方向反過來（skill 是唯一規格來源，CLAUDE.md 只留觸發條件）。
  • 確認過 CLAUDE.md 全文與 wiki 全庫都沒有用「步驟編號」引用這三段（歷史 decision log 裡的提及是敘述過去，不是活依賴），搬動不會弄斷任何交叉引用。
• 待辦：chaos/第六七篇 CLAUDE.md 捕捉.md 待辦清單「決定 Lint／Query 程序放置方式要不要跟著這次一起調整」已在此定案為「要」且執行完畢，該檔案之後潤稿到第七篇時可直接引用本節結論。

問題一：raw/ 不變性 invariant 自相矛盾（2026-09-06，已定案並執行）

• 現況：頂層寫「既有 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，內容不變）：raw/projects/active/{iThome鐵人賽2026, RambleWiki公開站, 某企業委外專案} 與 raw/projects/archive/iThome鐵人賽2026-舊方向 全部收斂進 raw/projects/<name>/，active/、archive/ 兩個空殼子目錄（含 .gitkeep）一併移除。
  • CLAUDE.md 五處同步修改：核心架構樹狀圖、raw/wiki 結構對稱說明（補例外）、raw/ 不變性宣告（改成只剩 raw/assets/ 一種例外）、常青與專案定義（project 的 active/archive 限定為 wiki/ 側）、專案歸檔步驟 1（只搬 wiki/）、Lint 規則一（簡化成只判斷 raw/assets/ 歸類搬出這一種白名單）。
  • wiki/ 裡 33 個檔案的「原始來源：raw/projects/active/…」這類當下路徑提及，機械式取代成新路徑（raw/projects/active/ 與 raw/projects/archive/ 都改成 raw/projects/）。
  • 刻意不動：wiki/log.md、wiki/log-archive.md（append-only 歷史敘述，不因 schema 改變回溯竄改，跟問題二同一原則）；第十一篇 - 直接把 CLAUDE.md 給你，附使用須知.md（正文教讀者舊版歸檔機制，使用者確認會自己重寫，這次不代勞）。
• 完整規劃見已執行的 plan（存於另一台機器的本機 plan 檔案）。

問題二：log.md append-only 與歸檔動作矛盾（2026-09-06，已定案並執行）

• 現況：頂層寫「新紀錄一律追加於檔案末尾，不修改或刪除既有紀錄」；但歸檔規則又寫「超過 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 完全重複（後者已經是唯一需要的完整規格：wc -c 判斷門檻、grep 找切割點、依行號搬移）。使用者選擇拿掉 CLAUDE.md 這段重複，只留不變性宣告，理由是精簡；不需要額外加「見 hoard-commit skill」的 pointer，因為 CLAUDE.md 的 Git 段落已經寫明「commit 用 hoard-commit skill」，archiving 只在 commit 時觸發，不必重複指路。
• 待討論項已定案：要不要幫 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 不需改動。

問題三：sources 欄位從未有操作型定義，且實際數字不可靠（2026-09-06，已定案並執行）

• 現況：schema 定義 sources: 3 這類欄位，Lint 也驗證「必須是非負整數」，但整份 CLAUDE.md 沒有定義「一個 source 算什麼」。
• 實測三個頁面對照 raw/ 實際檔案數，證實不是單純沒寫文件、是從沒被一致套用過：
  • 靶心人公式.md sources:1 ↔ raw/ 剛好 1 個檔案（巧合，頁面本身也明講逐字來源見該檔）。
  • 檢索典範與問題分類.md sources:3 ↔ raw/ 0 個檔案（raw/evergreen/topics/LLM Wiki/ 資料夾根本不存在；連帶抓到這頁的文獻整理當初 Ingest 沒有依步驟 3 存底原始來源，是另一個流程缺口，不在本次範圍內處理）。
  • 舊方向 iThome _index.md（歸檔）sources:12 ↔ raw/ 實際 29 個檔案，對不起來。
• 查證起源：git 初始 commit（fc1a8e7，2026-07-29 建骨架）就已經有這個欄位，commit message 沒說明設計初衷，找不到任何決策紀錄解釋過用途。
• 判斷：目前系統裡沒有任何程式邏輯（Ingest／Query／Lint）真的讀取這個欄位做決策，Lint 只做型別檢查、不驗證正確性。唯一價值是給人看的「證據厚度提示」——一眼判斷頁面是轉寫單一素材還是跨來源綜合過。這個用途邊緣但維護成本低，值得留。
• 決定：保留欄位，重新定義為「這個頁面目前內容所源自的、不重複 raw/ 路徑數量」；唯一合法寫入者是 Ingest（執行步驟 3／4 時本來就知道用了哪些 raw/ 路徑，可直接算出正確數字）；Lint 維持只做型別檢查，不做正確性稽核（wiki 是自由格式散文，逐篇核對成本不划算）。
• 不回溯：舊頁面現有數字不主動修正，放著不管；等該頁面下次真的被 Ingest 觸碰時，依當下實際 raw/ 路徑重新算過（不是在舊值上遞增），讓數字隨自然編輯逐步校正，不開一次性稽核專案。
• 已執行：CLAUDE.md「Frontmatter 慣例」補上 sources 定義句；Ingest 步驟 4（寫入 wiki）補一句依實際用到的 raw/ 路徑數更新 sources。沒有修改任何既有頁面的數字（符合不回溯）。

問題四：status 混了 track 與文件完成度兩條軸線（2026-09-06，已定案並執行）

• 現況：schema 定義 status 固定值為 draft | evergreen | active | archived | done，但只詳細解釋了 draft。
• 實測發現不是單純缺文件，是五個值混了兩條軸線：
  • Track 層級（evergreen／active／archived）：evergreen 100% 跟 wiki/evergreen/ 目錄一致；active／archived 大致跟 wiki/projects/active|archive/ 一致，但有反例——第三篇 - 取材分析.md、Karpathy LLM Wiki 中譯.md 人在已歸檔的專案目錄下，status 卻還是 active。查歸檔 SOP 步驟 3 只要求「更新受影響的 index.md、log.md 與相關頁面」，從未明講要同步子頁 status，這就是漏洞根源。
  • 文件完成度（draft／done）：只出現在專案文章頁面（iThome 鐵人賽系列），標記「這篇文章本身寫完了沒」，跟專案 track 完全獨立——已封存專案底下的文章有的是 done 有的是 draft，沒人管。
• 判斷：取材分析.md 這類「輔助研究素材、不是交付物也不是 track 頁面」的頁面，兩條軸線都套不上，才會卡在過時的 active 沒人動。
• 決定：status 收斂成純 track 層級，只留三個值：evergreen | active | archived，一個 frontmatter 只負責一種工作。文件完成度這條軸另外開欄位或乾脆不開——已知舊方向 _index.md 本來就用 ✅／🟡／🔴 進度表在追蹤文章完成度，不靠 frontmatter，判斷這條軸成本低、可以先不處理。
• 連帶要補的歸檔 SOP：專案歸檔時，該專案底下所有子頁面的 status 一併同步改為 archived（補上這條，取材分析.md 那類卡住的頁面之後歸檔就不會再漏）。
• 這次不能比照 sources「不回溯」：因為是縮小 Lint 允許值集合（拿掉 draft／done），新規則生效當下，舊頁面裡還在用 draft／done 的一律會被 Lint 判異常，remap 是規則生效的必要前置動作，不是額外回溯專案。好在是純機械式（照頁面當下所在 active/ 或 archive/ 目錄直接對應），約 19 篇文章頁面，不需要逐篇判斷內容：
  • wiki/projects/active/ 底下原本 draft／done 的頁面 → 全部改 active
  • wiki/projects/archive/ 底下原本 done／draft／active 的子頁面 → 全部改 archived
• 已執行：CLAUDE.md「Frontmatter 慣例」status 收斂成三值並補齊定義（拿掉 draft 的舊定義句）；同段補上 sources 定義（跟問題三合併處理）；專案歸檔 SOP 新增步驟 2「子頁面 status 一併同步改為 archived」。實際 remap：wiki/projects/active/ 底下 16 個原 draft／done 頁面 → active；wiki/projects/archive/ 底下 5 個原 draft／done／active 頁面（含當初卡住的 取材分析.md、Karpathy LLM Wiki 中譯.md）→ archived。純機械式，依 grep ^status: (draft|done)$／^status: (draft|done|active)$ 對照所在目錄批次執行，未逐篇判斷內容。

問題五：Promote 沒講「來源是 chaos/ 時怎麼保存」（2026-09-06，已定案並執行）

• 現況：混亂層 → Promote 規定「依 Ingest 流程決定歸屬、寫入 wiki…」，但 Ingest 步驟 3（保存來源）只講「對話文字另存、外部既有檔案複製進去」，沒有涵蓋「來源是 chaos/ 裡的既有檔案」這種情況——chaos/ 不算對話文字（不是這次對話當下講的話），也不算外部既有檔案（是 Hoard 內部、不是外部帶進來的），落在中間沒人管。
• 已發生的實例（不處理，過去的就過去）：log-archive.md 2026-08-08 那筆記錄，第二篇正文「逐字歸檔自 chaos/白板.md」，內嵌圖片有搬進 raw/，正文文字完全沒有存進 raw/，隨後 chaos/白板.md 該段落就被清掉——這段原始措辭現在只剩 wiki 版本，raw/ 沒有逐字備份，是真的發生過的資料流失，不是理論假設。
• 判斷：chaos 規則本身要求 Promote 完要清掉已收錄的內容（常駐型移除該段、任務型整份刪除），來源會主動消失，更需要在清掉前先落地備份到 raw/。
• 決定：hoard-ingest skill 步驟 3 補上第三種來源類型：「來源是 chaos/ 時，將本次實際 Promote 的原始內容複製一份保存至對應路徑」。Promote 段落本身不用改字，它已經寫「依 Ingest 流程」，會自動吃到這條。
• 不回溯：已經發生的第二篇正文遺失不處理，不去 chaos/白板.md 的 git 歷史挖回來補救。
• 已執行：hoard-ingest/SKILL.md 步驟 3與 frontmatter description 都補上「來源是 chaos/ 時將本次實際 Promote 的原始內容複製一份保存至對應路徑」。

問題六：hoard-status 把合法的 raw/assets/ 搬出誤報成異常（2026-09-06，已定案並執行）

• 現況：hoard-status/SKILL.md 步驟 4（含 frontmatter description）寫「raw/ 底下如果有任何 M／D／R…一律標異常」，完全沒有 raw/assets/ 歸類搬出（git mv）這個合法例外——這個例外從一開始就存在於 Promote 段落，hoard-status 從沒跟上，是獨立於這次 raw/ 精修的舊 bug，跟本次 Ingest/Query/Lint 卸載要解決的「規則各存一份、其中一份沒同步」同一種形狀。
• 決定：步驟 4 改成——raw/ 底下的「修改」（M）或「刪除」（D）一律標異常；「搬移／改名」（R）時，若舊路徑在 raw/assets/ 底下、新路徑不在 raw/ 樹內，屬於合法歸類搬出，不算異常，其餘搬移都標異常；只有「新增」正常。Frontmatter description 同步拿掉「一律」的暗示、補上例外。
• 已執行：hoard-status/SKILL.md 步驟 4 與 frontmatter description 都補上 raw/assets/ 歸類搬出的合法例外。

問題七：report-format.md 沒跟上 Query 演算法的精修（2026-09-06，已定案並執行）

• 現況：.claude/skills/hoard-query/report-format.md 有三處過時——
  1. 開頭「觸發時機」寫「CLAUDE.md「工作流程→Query」「2. 閱讀門檻」」，但 Query 完整演算法已搬進 hoard-query/SKILL.md 本身，指錯地方。
  2. 「排序規則」只講雙重命中／只 grep／只反向連結三層，完全沒有語意候選（A）的位置——現在正常情況下 A 很少落到「未精讀」，但問題八一旦定案，A 整批未精讀的情況會出現，需要補一層（且應排最優先，語意相關性比 grep／反向連結的間接證據更直接）。
  3. 「大小資訊」引用「步驟 2 或步驟 3 子步驟 2」，這是舊版結構的步驟編號，現在 hoard-query/SKILL.md 用「1～4」標題結構，沒有這種子步驟，是死的交叉引用。
• 已執行：跟問題八一起改。report-format.md 整份重寫：觸發時機改指向本 skill 自己；排序規則新增語意候選（A）最優先層；新增獨立的「範圍過廣格式」小節；大小資訊的死引用改成泛稱「2. 閱讀門檻」。

問題八：Query「2. 閱讀門檻」沒有處理語意候選（A）自己就超過 90KB 的情況（2026-09-06，已定案並執行）

• 現況：閱讀門檻只講了「候選總量 ≤90KB 全讀」跟「候選總量 >90KB 但 A 在預算內，優先讀 A、B/C 延後」兩種情況；「單篇 A 超過 15KB」有章節定位救濟，但「A 本身（多篇加總）就超過 90KB」完全沒有判準。
• 討論過兩個方向：(1) 在 A 內部排優先序（依 updated 日期或檔案大小）讀到預算用完，其餘列未精讀；(2) 不硬讀，直接判定「範圍過廣」，比照「4. 無命中判定與回報」的透明回報精神，列出候選清單，建議使用者縮小範圍或拆成幾個問題。
• 決定：選方向 (2)。理由：這是低機率情境（除非使用者故意問很廣泛的問題），方案 (1) 要多發明一條排序規則，方案 (2) 重用既有的「無命中」透明回報模式，成本更低，也更符合 Query「策展優先、不是硬要生出答案」的既有立場，呼應「先讓真實需求擠出來再長結構」原則。
• 已執行：hoard-query/SKILL.md「2. 閱讀門檻」改寫成一條決策路徑——先套用單篇 15KB 章節定位，再依序判斷「總量 ≤90KB 全讀」「總量 >90KB 但 A 在預算內」「A 本身 >90KB → 範圍過廣，不讀任何候選」三種情況，最後一種直接依 report-format.md 的範圍過廣格式回報 A／B／C 全部候選（A 排最前）。

問題九：「範圍判準優先於經濟判準」是沒有內文定義的術語（2026-09-06，已定案並執行）

• 現況：hoard-ingest 步驟 2 標題寫「決定歸屬，範圍判準優先於經濟判準」，但「範圍判準」「經濟判準」這兩個詞在操作規則本文裡從沒被定義過——只有在 觸發機制演變「十九」的決策歷程裡才找得到定義（範圍判準＝先判斷內容本質、對照 wiki/index.md 範圍宣告篩出合格候選；經濟判準＝划不划算、命名/維護成本，只能在範圍判準通過之後才生效）。
• 這牴觸 CLAUDE.md「CLAUDE.md 寫作準則」自己第 4 條：「簡稱只定義一次，例子只作補充，不取代正式判準」——這兩個詞從第一次在操作規則裡出現就沒被定義過，不是「定義過但後面沒再重複」，是從沒定義過。
• 使用者判斷：這不是功能缺口——步驟 2 底下三個 bullet（先判斷性質、對照範圍、篩合格候選才問沿用或新增）本身已經把完整流程講清楚了，就算不知道「範圍判準」「經濟判準」這兩個名詞在講什麼，照著 bullet 做也不會做錯。純粹是術語標籤缺定義，可改可不改。
• 討論過程：第一版草稿「經濟判準：沿用既有頁面還是開新頁面比較划算」被使用者指出太模糊，沒講「划算」在秤什麼；回頭核對「十九」的原始定義（划不划算——量小、命名/維護成本），改採直接沿用既有措辭，不重新發明新說法。
• 決定並已執行：不拿掉這兩個詞（已在決策歷程、鐵人賽第十一篇文章裡被使用，拿掉會讓那些引用變成無源之水），在 hoard-ingest 步驟 2 標題後補括號定義：「範圍判準：內容性質是否落在既有主題定義的範圍內；經濟判準：划不划算——內容量、命名與維護成本值不值得為此新增分類。範圍判準要先篩出合格候選，經濟判準才輪到在合格候選裡做選擇」。三個既有 bullet 不動。frontmatter description 不用同步展開，維持壓縮摘要。

問題十：專案歸檔卸載到 skill（2026-09-06，已定案並執行）

• 現況：CLAUDE.md「專案歸檔」段落把完整 5 步驟寫在正文，結尾註明「歸檔不另設 skill，依上述流程執行」。
• 這是明確討論過並否決過的：架構與流程「十六」（2026-08-12）用 AskUserQuestion 問過要不要獨立 skill，使用者當時選「不需要」，理由是頻率低、步驟不多、跟「不主動建議新 skill 除非有具體痛點」原則一致。
• 使用者重新提出：這個判斷是在五層機制模型出現前做的，框架本身判準不是頻率、是「是不是多步驟只在特定任務觸發的程序」——歸檔完全符合；且 hoard-pull／hoard-status 這兩個既有 skill 步驟量級跟歸檔差不多，歸檔卻沒有，不一致。判斷「這個動作實際非常少做，所以需要獨立出來」（跟 CLAUDE.md 本身「每次 session 都要用」的性質差太多）。
• 決定：獨立成 hoard-archive skill。
• 觸發模式的錯誤與修正：討論觸發方式時，AI 第一版誤引「十六」的舊觸發設計（使用者明確要求，或 AI 觀察到跡象主動提議），使用者當場同意；但查證後發現這個「AI 主動提議」分支已經在更晚的 規則品質與判準「二十五」（2026-08-23）被拿掉——使用者當時逐條檢查全文，確認這條路徑「從沒真的被使用過」，判定灰色地帶、不划算，簡化成只剩「使用者明確要求」一種觸發，CLAUDE.md 現有文字（「使用者要求歸檔專案時」）就是簡化後的版本。AI 主動發現這個引用錯誤並回頭修正，最終只保留「使用者明確要求歸檔」這一種觸發路徑，不恢復已經被否決的 AI 主動提議分支。
• 已執行：新建 .claude/skills/hoard-archive/SKILL.md，5 個步驟原封不動搬進去；CLAUDE.md「專案歸檔」段落收斂成一句話觸發條件＋指向 skill。
• 待處理（不在本次範圍）：第十一篇 - 直接把 CLAUDE.md 給你，附使用須知.md 也有一份完整的舊版歸檔流程說明（含問題一之前的 raw/ active/archive 搬移寫法），使用者將自行重寫這篇文章，不代為修改，跟問題一的處理方式一致。

待辦

• 確認「真正的 invariant」文字是否採用——已採用並執行（含拿掉 raw/ active/archive 分裂的加碼版本）
• 收集使用者觀察到的問題（第一輪）——四個問題（raw/ 不變性、log.md append-only、sources 定義、status 雙軸線）＋ Ingest/Query/Lit 卸載到 skill，皆已討論定案並逐項執行、commit 且 push（commit 4908956）
• 第二輪：問題五～九（Promote chaos 來源保存、hoard-status 誤報、report-format.md 過時、Query 範圍過廣判準、範圍/經濟判準定義）皆已討論定案並逐項執行，尚未 commit
• 依「Hoard 建設歷程」收錄門檻（改變 Hoard 結構／規則／schema／AI 行為邊界的重大決策才記錄），把這次所有決策整理進 wiki/evergreen/topics/DragonsHoard建設歷程/（架構與流程或觸發機制演變，視內容性質分派），完成後刪除本捕捉檔整份內容