DragonsHoard 建設歷程－協作與元規則
範圍：跟 AI 協作的溝通風格與慣例、這份建設歷程記錄本身該怎麼寫／怎麼分類。不收：資料夾/schema 層面的定案（見 架構與流程）、規則觸發機制與品質判準（見 觸發機制演變、規則品質與判準）。
六、這份記錄本身的產生過程
架構變更執行完後，使用者主動問「要不要把這整串對話記錄下來」。討論後確認：
- 這段對話的內容不屬於第四篇（
決策歷程.md明確排除 ingest/query/lint、規則演化留給後續文章），而是屬於後面某篇談「規則隨真實使用而演化」的素材，先存起來 - 歸屬：iThome 專案（而非另開 DragonsHoard 自己的架構分類）——注意：此決定 2026-07-30 被推翻，見下方「七」
- 使用者要求能透過 tag 搜到「DragonsHoard 自己的架構史」——因為 tag 是掛在整個檔案上，不能只讓
決策歷程.md裡的某一段落單獨帶 tag，所以另開這份獨立衛星檔案（比照文章/第三篇 - 取材分析.md的既有模式），跟逐字稿一起打上DragonsHoard架構史這個 tag - 逐字稿範圍：整段 session 全部，從最一開始「幫我把 GitHub 串起來」到這段記錄本身被建立為止
十三、2026-07-31：CLAUDE.md 新增「與 AI 協作的溝通風格」規則
起點：使用者提到自己常說「有建議或問題可以直接提出」，但這次懶得再打一次這句話，想確認 CLAUDE.md 有沒有把這條收成規則。查過後確認沒有——既有的「主動建議」都綁定特定情境（commit、wiki 頁面、跳題捕捉），沒有一條通用的「AI 不用等邀請就能主動開口」規則。
討論：先草擬一版「AI 主動提出建議與疑問」的規則，使用者看過後補了一份完整得多的「溝通風格」筆記，涵蓋五個主題：給判斷不要列選項（外觀/風格類問題可以直接批評）、不要把簡單的事情變複雜（待辦只寫一句話、口述筆記要貼近原話不加分析）、例行操作要主動回報、寫作類協作要先給草稿不直接寫檔案、結構/系統擴充要節制（不主動建議新 skill）。討論該把哪些內容放進 CLAUDE.md、哪些留在 AI 的跨對話記憶時，一開始的判斷是「先建立問題模型再收斂方案」「講解從具體差異切入」這兩條比較像通用溝通習慣、非 DragonsHoard 專屬，適合放跨對話記憶；但使用者反問「不寫進 CLAUDE.md 能確保遠端相同 repo 的電腦同步嗎」，點出關鍵事實：AI 的跨對話記憶是綁在「這台機器 + 這個專案路徑」的本機狀態，不屬於 git repo 的一部分，不會透過 git pull 帶到使用者的其他電腦——這個 repo 本來就會在多台機器上開（launch-dragonshoard.ps1 的 $PSScriptRoot 修改就是實例，見第十二節提及的多機器操作背景），只有寫進 CLAUDE.md 才能保證每台機器讀到同一份規則。
最終定案：原本規劃拆到跨對話記憶的兩條也一併收進 CLAUDE.md，不使用跨對話記憶存放任何一部分。CLAUDE.md 新增「與 AI 協作的溝通風格」獨立小節（六條：主動提出建議/疑問、給判斷不列選項、問題模型先於方案、具體差異切入、動作完成主動回報、結構擴充節制），並擴充「wiki 直接編輯」（文章正文先給草稿、不直接寫進檔案）與「混亂層」共通規則（口述筆記貼近原話不加分析、待辦只寫一句話不預拆步驟）兩處既有段落。
十四、2026-08-02：白板 checklist 打勾要主動同步，且再次確認「不用跨對話記憶」的原則
起點：AI 幫使用者確認白板 [ ] 待辦裡兩項其實已經完成，順手在對話裡記到 AI 的跨對話記憶系統（記憶檔案存在使用者本機、綁定這台電腦跟這個專案路徑），沒有寫進 CLAUDE.md。使用者馬上糾正：要記到 CLAUDE.md，不是只存 memory。
討論：這正好重複第十三節已經確認過的結論——AI 的跨對話記憶不屬於 git repo 一部分，不會透過 git pull 帶到使用者的其他電腦，只有寫進 CLAUDE.md 才能保證每台機器讀到同一份規則。這次踩進同一個坑，是因為判斷「這條規則感覺很小、很局部（只跟白板 checklist 有關）」，誤以為可以用記憶處理，沒意識到「規則多小」跟「要不要進 CLAUDE.md」是兩回事——只要是會被引用套用的規則，就該進 CLAUDE.md，跟規則本身大小無關。
最終定案：撤掉已經寫進跨對話記憶的那筆，改寫進 CLAUDE.md「混亂層」共通規則：白板待辦的 [ ] → [x] 不會自動發生，AI 完成對應工作、或事後發現某項其實已經做過，都要主動回頭核對並打勾，不要假設使用者會自己記得回頭勾。同時重申：這個 repo 的所有操作性規則（不管多小、多局部）一律進 CLAUDE.md，不使用跨對話記憶。
十五、2026-08-11：卡住/決策過多時給最小啟動行為，不回拋高難度問題
起點：規劃第四篇文章時，使用者面對「合併 4+5 與否、順序怎麼排」等結構性懸念說「卡住了，不明確、需要決策的地方太多，給我一個最小啟動行為」。AI 給出「想一個具體場景寫一行到白板」，繞開結構性猶豫，使用者事後追問這個建議的依據，展開討論。
討論：釐清卡住有兩種型態——「排列型」（選項清楚，但缺一個可以依附判斷的具體錨點）跟「二選一型」（沒有小動作能兩邊通吃）。這次是前者。有效的「最小啟動行為」要滿足一個條件：不管後面選項怎麼收斂都用得上，即所有分支的最小共同交集，不是隨便找件事做。使用者進一步要求：往後遇到「卡住/決策太多」的狀態，AI 要直接給這個最小啟動行為，不要回拋一個本身也有決策難度的問題——不是禁止提問，是問題本身的決策負擔不能讓使用者更混亂。
該不該另開「框架」區域的討論：使用者聯想到舊 Vault（Treasury-Vault）的 03-Vault/Frameworks/ 資料夾，問要不要仿照開一個專門放這類「框架」的地方，並自陳舊 Vault 裡的「唯一主線法則」這類框架幾乎沒觸發過。AI 判斷不需要，理由跟第九、十二節是同一個模式：CLAUDE.md 每個 turn 自動載入，獨立框架頁需要「被想起才會去讀」——「唯一主線法則」幾乎沒觸發過，正是因為它放在不會自動生效的地方，跟 Lint 曾經沒被觸發過（第九節）、raw 唯讀屬性擋不住 rm（第十二節）是同一種 Policy vs Enforcement 失效模式，把新規則移去獨立框架頁等於重蹈覆轍。同時把「框架」拆成兩種：(a) 管 AI 怎麼協作的規則——必須留 CLAUDE.md；(b) 使用者自己的決策框架（如唯一主線法則）——性質上更接近一般 wiki 主題頁，不需要進 CLAUDE.md。這次的規則屬於 (a)，(b) 類是否要開新地方放，留待使用者之後有具體項目時再議，不跟這次綁在一起決定。
最終定案：CLAUDE.md「與 AI 協作的溝通風格」新增一條規則，不開獨立框架區域。
後續：如何確保未來真的會被想起（同日續）：使用者追問，鐵人賽期間類似情境出現時，AI 會不會主動想到查這次討論。AI 一開始只提議在 CLAUDE.md 那條規則後面加一句 inline pointer（仿照 raw 唯讀規則「決策過程見『十二』」的既有寫法），使用者認為範圍太窄——不該只靠「規則旁邊剛好有沒有寫 pointer」，而是任何跟 Hoard 本身架構、規則、工作模式相關的問題，都該主動讀這份建設歷程頁，不限於已經連結的特定條目。這其實是既有 Query 工作流程（先讀 index.md 找相關頁面）套用到「問題主題是 Hoard 自己」這種情境的具體化，兩者不衝突、互補（pointer 給精確定位，廣覆蓋規則給不依賴 pointer 也能觸發的保底）。
最終定案（續）：CLAUDE.md「與 AI 協作的溝通風格」新增的規則後面補一句 inline pointer 指回本節；「Hoard 建設歷程」節新增「查詢觸發」規則，任何跟 Hoard 本身相關的問題都主動讀這份建設歷程頁，不限於使用者明講或規則旁邊有沒有寫 pointer。
二十一、2026-08-19：定義建設歷程條目本身該記錄什麼內容——收斂成「目的／做法／結果」三段
最初目的——為什麼要動：起因是討論 git log -p 能不能拼湊出建設歷程，比較後發現 commit message 只留得住「結果快照」，留不住「為什麼」「中間否決過什麼」「轉折怎麼發生的」——這些正是這頁存在的差異化價值，但 CLAUDE.md「Hoard 建設歷程」一節當時只定義了「值不值得記」的門檻（結構規則變動／可重複套用的工作模式），完全沒規定「記的時候要包含什麼內容」，等於每次執筆全憑手感，沒有規則保證新條目撐得住上面那個比較結論。
怎麼做——為了達成目的採取了什麼做法：來回收斂多輪，中間出現並否決了幾個版本：
- AI 最初提「最終決定/否決方案/轉折觸發點/核心分歧」四項，使用者另外獨立想出「做了什麼／為什麼／實際做成什麼樣／限制風險／未來可能性」五項，兩邊合併討論。
- 第一輪合併發現「做了什麼」跟「實際做成什麼樣」定義太近、容易混淆，用 raw 唯讀技術性強制那筆真實案例（見「十二」）當測試案例，確立操作型判準：前者決策當下就能寫完、後者要等真的用過才寫得出來。
- 使用者提出房子裝修比喻（「為什麼要動房子／採取了哪些改動／房子現在什麼狀態」），把「為什麼」從「做了什麼」裡完全拆開獨立成「最初目的」，讓被否決的替代方案自然併入「怎麼做」段落，不用單獨立項。
- 第四項「替未來留下哪些可能性」被使用者質疑不知道要寫什麼；用「一、待辦功能」「二、02-Areas」兩筆單純否決型決定測試，證實這項不是每筆決定都天生有內容，會逼出空洞填空句，違反「結構擴充節制」原則，因此否決，改成有懸念時直接併入「最後變成什麼樣」當附註，不獨立成項。
最後變成什麼樣——實際結果是什麼：收斂成三段固定框架——最初目的／怎麼做（含被否決方案）／最後變成什麼樣（含副作用與懸念），寫進 CLAUDE.md「Hoard 建設歷程」節「記錄內容要求」小節，並註明三段非強制模板、適用時才寫。本條目本身就是用這套新框架寫的第一筆，屬於自我指涉的示範案例（呼應知識庫建設哲學「四、系統本身也是知識的一部分」）。這次討論同時也是 iThome 鐵人賽第七篇（建構歷程＋Git）素材的延伸——chaos/第七篇規劃.md 已有 pointer 記錄 git vs 決策紀錄的核心對比，完整的三段式框架定案記在這裡，第七篇若要引用，指過來即可，不重複維護兩份。
二十三、2026-08-20：CLAUDE.md 不該內嵌演變歷史 + 移除已內化的「跳題處理」實驗段落
起點：使用者要求用同一套標準檢視 DragonsHoard 自己的 CLAUDE.md。AI 抓出兩個問題：
CLAUDE.md「Hoard 建設歷程」節裡「想法捕捉入口」一句的標題括號塞了三次搬遷歷史（2026-07-30 定案，2026-07-30 續：從 raw 搬到根目錄混亂層，2026-07-30 再續：混亂層收整成 chaos/ 資料夾），讀者要先解析完歷史才看到現行規則——這段歷史本身其實已經完整記在本頁第八、十節。- 「跳題處理」整節仍標著「實驗中，2026-07-30 開始」，三週過去沒人回頭確認狀態。
使用者定案：
- 「跳題處理」——使用者確認這個習慣已經內化成常態,不再需要 AI 主動提醒/提議,整節從 CLAUDE.md 刪除(不是轉正成正式規則,是這條規則本身已經不需要存在)。
- 「想法捕捉入口」——使用者給出判斷原則：CLAUDE.md 本來就不該放演變歷史。判斷方式很簡單——先查建設歷程頁有沒有記過這段歷史：有記過就直接把 CLAUDE.md 裡的歷史敘述刪掉、只留現行規則 + 單一定案日期；沒記過，代表當初漏記，算 AI 的失誤，要先補進建設歷程再刪。這次查證後兩處搬遷（raw→根目錄混亂層、混亂層→
chaos/資料夾）都已經在本頁記過，所以直接刪减,不需要先補記。 - 使用者同時指出 CLAUDE.md「Hoard 建設歷程」節本來就已經寫了「查詢觸發」規則（任何跟 Hoard 架構/規則相關的問題都主動讀這份建設歷程頁，不限於規則旁邊有沒有寫 pointer）——這代表 CLAUDE.md 完全不需要在規則本文裡重複維護歷史，演變過程一律只在這頁查，CLAUDE.md 只需要陳述「現在有效的規則是什麼」。
這件事夠格記進本頁的理由：這不是單次修一句話，而是確立了一條以後每次 CLAUDE.md 規則修訂都會重複套用的撰寫原則——「規則變了幾次不重要，CLAUDE.md 永遠只寫現在生效的版本，演變過程一律留給建設歷程頁」，符合門檻 (2)。跟 知識庫建設哲學 已經整理的信念一致，也呼應 iThome 鐵人賽第五篇文章裡「CLAUDE.md 撰寫四原則」的「儘量不要太長」一條——這次順帶把 CLAUDE.md 從 222 行降到 216 行。
待確認：AI 順帶指出 CLAUDE.md「raw 唯讀是文件約定」一段（見本頁「十二」）也有類似但較輕微的情況——內文除了 pointer 到建設歷程「十二」，還額外重述了一段「為什麼從技術強制改回文件約定」的推理過程，跟這次刪除的兩個案例是同一種模式的邊界情況。這次沒有一併處理，留給使用者之後自行判斷要不要比照精簡。
後續（2026-08-21）：使用者主動追問「有必要特別列出 raw 要唯讀這件事嗎」，順勢確認這段還是該留——真正發生過的意外（見「十二」）是使用者自己校稿手滑編輯到 raw，不是刻意動的，而且這條規則主要是講給 AI 聽：ingest 時只讀不改的邊界如果沒明講，AI 可能「順手」改動來源檔，hoard-commit skill 裡的 git diff 檢查也會失去對應的「為什麼要查」。確認留著之後，比照本節同一原則精簡：刪掉重述的推理過程，只留現行規則 + pointer，段落從原本的完整推理縮成一句「AI 處理 ingest 時只讀不改；Lint 機制詳見 hoard-commit skill。原因與演變見「十二」」。至此「二十三」定案的原則已套用到 CLAUDE.md 全部相關段落。
二十八、2026-08-26：建設歷程本身依主題拆成四檔 + 路由頁定案
最初目的：處理完 log.md 歸檔（見「二十七」）後，使用者接著發現 DragonsHoard建設歷程.md 自己也過度肥大——27 個章節、72KB。需要一套分檔方式。
怎麼做：一開始想比照 log.md 用「留最近、封存舊的」時間切法，但發現關鍵差異：本頁章節被 [[DragonsHoard建設歷程]]「N」 這種編號引用了近 35 次、散布在 15 個檔案，其中 CLAUDE.md 自己就引用了 8 個不同章節（八、十二、十五、十六、十九、二十一、二十五、二十七），從最早到最新都有——時間切法會迫使 CLAUDE.md 同時指向多個歸檔檔案，且砍斷它自己最依賴的規則說明，因此改用主題分類。先分三桶（架構與流程／規則治理／協作與元規則），使用者追問「要不要因為檔案會持續長大而分更細」，回頭看最近 11 個章節（十七～二十七）的分布，發現規則治理桶佔了 7 個、明顯比另外兩桶快——這是用實際成長動能而非猜測作判斷，於是把規則治理桶進一步拆成「觸發機制演變」（Lint/Ingest/Query 各自何時觸發）跟「規則品質與判準」（抓漏洞、收斂判準），另外兩桶維持不動（近期成長已明顯趨緩，不用為了假設的成長預先拆）。章節編號維持全域唯一、不重新編號，只有連結要指到的檔名改變，最大程度降低要修的引用數量。
最後變成什麼樣：DragonsHoard建設歷程.md 改當純路由頁（簡介 + 章節號對照表），正文拆進四個新檔——架構與流程.md（一～五、七、八、十、十一、十二、十六、二十二、二十七，~27KB）、觸發機制演變.md（九、十七、十八、十九、二十六，~19KB）、規則品質與判準.md（二十、二十四、二十五，~12KB）、協作與元規則.md（六、十三、十四、十五、二十一、二十三、本節，~15KB）。每個新檔開頭加一句範圍宣告，比照 wiki/index.md 常青主題的既有慣例，供以後新章節判斷該歸進哪一檔。約 24 處活的 「N」 引用（CLAUDE.md、hoard-commit skill、7 篇 wiki 頁面）需要逐一改指到正確檔名；wiki/log-archive.md 裡 ~11 處舊引用比照專案封存的既有先例不回頭修，連結對象變得不確定但不影響稽核判讀。