"文件設計"
- 商業邏輯論述要 self-contained：不依賴 code 才能被理解
技術文章在「不放 code 的段落」仍然要 self-contained——商業邏輯論述不能預設讀者已經看過 code、用「那個 payload 第二段」「剛才的變數」這類 reference 等於把理解門檻轉嫁給讀者去翻 code。修法是把 reference 翻譯成「用名詞 / 角色 / 條件描述」的 self-contained 句子、即使讀者跳過所有 code block 也能理解論述。
- 路由條目要自包含：跳轉單位不依賴鄰條上下文
路由段落（下一步 / 依情境讀法 / MOC）的每條 bullet 是獨立跳轉單位、讀者只讀命中自己情境的那條；用「同篇 / 上一條 / 前述文章」指代鄰條的目標、或為了避免重複連結而壓縮引用、會讓讀者在錯的文章裡找不到目標。拆分標準是讀者情境數、不是目標文章數 — 兩個情境路由到同一篇文章時重複完整連結合規。是 #155 引用錨點在「容器層」的 sibling、#113 self-contained 在 navigation surface 的對應。
- 依職責拆分文字文件：修改紀錄的訊號、切法與拆完之後的引用
規則文件、操作手冊與範本的拆分：從版本歷史讀出一份文件承擔幾種職責，依職責而非長度決定切法，原檔保留導覽表、同一條規則只定義一次，以及拆完之後更新引用與檢查新檔之間的指引缺口
- 規則文件的精簡：用 Progressive Disclosure 分出常駐內容與參考細節
規則文件膨脹之後的精簡：Progressive Disclosure 的四層分法（快查表、強制規則、決策流程、參考細節）、把參考細節移出常駐文件的做法、一次規則文件精簡的前後量測，以及過度精簡、只按章節切開與移出後未留入口這幾種失誤