教學模組的 Backlog 段格式規範
這篇要解決什麼
Backlog 段的責任是讓「這個模組還有什麼沒寫」在不讀完整份大綱的情況下就能被回答。教學模組寫到一定規模後，未完成的工作會散在大綱各處：vendor 覆蓋表的空欄、知識卡候選清單、推演階段表、跨模組的交接缺口。這些內容各自都有存在的理由，但它們共用一個讀者需求——有人（可能是幾個月後的自己）想知道「現在該接著做什麼」。
實際發生過的情況是：backend 十二個模組各自發展出不同的 backlog 段名，大綱待辦、觀念網路補完方向、後續深化方向、下一輪推演大綱、後續推演大綱、規劃方向、後續擴充方向、目前缺口與後續批次 都出現過。每個名字在它自己的模組裡都說得通，合起來的後果是跨模組盤點必須逐檔閱讀、且無法確定有沒有漏掉某個段名。
規範要解的是這個彙總問題，不是要把各模組的規劃思路壓成同一種。因此格式分兩層：可彙總的標準表在上，模組自己的敘事在下。
段落結構
每個教學模組的 _index.md 用 ## Backlog 作為段名，段內先放標準表，表下方保留該模組原有的規劃敘事作為 H3 子段。
1## Backlog
2
3| 項目 | 類型 | 前置條件 | 規模 |
4| ---- | ---- | -------- | ---- |
5| 八個 T1 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9） | vendor | 需與效能模組界定角度分工 | 8 篇（大） |
6| 判讀訊號表格補行動建議欄 | 主章 | 無 | 小 |
7
8### 下一輪推演大綱
9
10（模組原有的階段表與敘事，不動）段名固定的理由是它要能被 grep。rg -l "^## Backlog" content/*/*/_index.md 要能列出全部有待辦的模組，少一個就代表該模組漏了這段，而不是「它可能叫別的名字」。
段的位置放在模組完成狀態之後、跨分類引用之前。讀者的閱讀順序是先知道現況、再知道待辦、最後才需要往外跳。Tripwire、知識卡補強方向這類本來就不進 backlog 表的內容，可以留在 Backlog 段外作為 sibling H2。模組若還沒有完成狀態段與跨分類引用段，Backlog 放在文末即可。
標準表的四個欄位
四個欄位的共同判準是「彙總時需不需要」。四個欄位各自對應一個彙總視角：總量（還剩幾件事）、分布（缺口集中在哪一類產出物）、可啟動性（哪些現在就能開始）、成本量級（哪些要花大力氣）。
項目
寫具體要產出什麼，不寫方向。「8 個 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9）」是項目；「vendor 層需要深化」是方向。
判準是讀完這一格能不能直接開檔開始寫。答案是否的時候，那句話屬於下方的敘事段而非標準表。方向本身有價值——它記錄了為什麼這些項目值得做——但它回答不了「現在該接著做什麼」。
類型
從固定的五個值裡選，讓跨模組彙總能按類型分組：
vendor：vendor deep article、migration playbook、服務頁主章：模組主章的新章節或既有章節的修訂知識卡：新建卡片或既有卡片的補強案例：案例庫的採集、深挖、反例補齊跨模組：需要動到別的模組才能完成的項目
固定枚舉的代價是偶爾會有項目落在邊界上。判斷方式是看產出物落在哪個目錄：產出物進 vendors/ 就是 vendor，進 knowledge-cards/ 就是知識卡，進 cases/ 就是案例，落在模組根目錄的章節檔就是主章。同時牽涉兩個模組的，看主要工作量在哪一邊，另一邊在前置條件欄註明。
前置條件
寫「還缺什麼才能開始」，沒有就寫 無。
這一欄決定了項目能不能被現在的自己接手。無 代表素材與依賴都就位，隨時可以開工；有內容的則指出卡在哪裡——「需要先建 case 庫」「等 11.9 的路由落點確定」「需要實機環境驗證」。
無 是一個斷言，寫之前要實際確認過落點與素材——它讓該列成為盤點時最先被挑走的一列，而斷言錯了的挫敗發生在開工之後。有內容的則要寫成可觀察的事件（「等 11.9 的路由落點確定」「該形態的案例庫有第一則紀錄」），寫不成可觀察事件的含糊阻塞（「需要素材」「等時機」）永遠不會觸發。這也是候選與待辦的那把尺：寫不出可觀察的解除條件，多半代表它還是候選、該回到後續候選段。
盤點時這一欄是排序的主依據。前置條件為 無 且規模小的項目，是進度停滯時最容易重新啟動的入口。
項目源自別處的路由落空時，這一欄要寫明是哪一篇指過來的。跨模組路由的目的地端沒有任何機制知道有哪些 inbound 路由押在自己身上，而那條路由的讀者正在等這一項——少了這個註記，這一項讀起來會像是模組自己想做的事，優先序因此被低估。這是既有欄位的用法界定，不新增第五欄。
規模
可數的項目寫「數量（級距）」，例如 8 篇（大）、4 張卡（中）；不可數的只寫級距 小 / 中 / 大。兩種寫法都帶級距，這一欄才能跨模組排序——只寫數量時 8 篇 與 大 無法比較。
三級的分界用單次工作能否完成來判定：小 是一次專注時段內能做完（補一段、加幾個連結、建一張卡）、中 是需要跨幾次（一篇完整文章、一組卡片）、大 是需要獨立規劃批次（一整批 vendor deep article、一個新的案例庫）。
這一欄的用途是讓盤點結果能回答「這個模組的缺口是零碎的還是結構性的」。十個 小 項目與一個 大 項目的處置方式不同：前者適合順手清掉，後者要排期。
寫 中 的項目要能說出它為什麼跨不過一次專注時段、又為什麼不需要獨立排期。三級裡只有 中 兩邊都不必舉證，它因此是最省力的值；整個模組的 backlog 全是 中 時，排序與「零碎還是結構性」兩個用途同時失效，該重判一次。
改動任何一欄的格式時，同一批要把既有實例掃過一遍。規範文章改完就結案的話，範例列與它抄來的那個模組會從此不一致——立規範與掃存量是兩件事，前者不會自動完成後者。
哪些內容不進 Backlog
Backlog 記錄的是已經決定要做、只是還沒做的工作。以下三類內容經常被誤放進來：
候選與評估中的想法留在原本的「後續候選」段。候選的語意是「將來可能做」，它與 backlog 的差別在有沒有做過取捨。把候選寫進 backlog 會讓項數失去意義——盤點時看到二十項，其中十二項其實還沒決定要不要做。
Tripwire 與判讀條件留在各自的段落。它們是「什麼情況下要重新評估」，觸發前不構成待辦。
已完成項目直接刪除，不留刪除線或「已完成」標記。完成紀錄的住址是 git history 與模組完成狀態段。Backlog 表要維持「表裡的每一列都是待辦」這個不變條件，否則讀者每次都要先過濾一遍。
這條約束及於整個 ## Backlog 段，不只表格。完成清單放在表下方的 H3 子段時，讀者仍然要先過濾才知道哪些是待辦，而過濾正是段落結構要替他省掉的動作。同樣地，內容為空的待辦子段（只有一句「這一節記錄……」而下面沒有項目）該刪除——空段讀起來像「這裡還沒盤點」，跟「這裡沒有待辦」是兩個不同的訊息。
總覽的維護規則
content/backend/_index.md 的總覽段只放索引，不複製各模組的 backlog 內容。
索引的每一列是「模組名（含連結）／項數／主要缺口一句」三欄，細節一律點回各模組。這條規則的理由是 SSoT：各模組的 _index.md 是自己 backlog 的唯一真實來源，總覽複製內容就會產生兩份、而更新時只改一份的機率遠高於兩份都改。
索引仍然會過時——項數會變、主要缺口會換。但過時的代價不同：索引過時的後果是數字不準，讀者點進去就會看到正確的；複製內容過時的後果是讀者拿到錯誤的清單，且沒有訊號提示他該去對照。
禁止複製的範圍不限於總覽這個方向。 同一份清單在模組自己的 _index.md 裡出現兩次（標準表一次、下方的推進紀錄敘事再列一次）產生的是同一個機制，而且更容易發生——兩份內容在同一個檔案裡，寫的時候看起來像是在補充說明，不像在複製。判準是：任何一處把 backlog 的項目重新列出來，就要問「這些項目改了之後，誰會記得回來改這裡」。答案是「沒有人」時，改成指回標準表。
新增教學模組時要同步在總覽補一列。這與新增頂層 content/<module>/ 要更新 content/_index.md 是同一類的登記責任。
與寫作原則的關係
這份格式規範看起來牴觸「情境優先於模板」（AGENTS.md 原則八），實際上它劃在原則的邊界外側。分界畫在讀者拿它做什麼這條軸上，內容的類別（教學／維運）只是它的粗略代理：要理解單一情境為什麼成立時，把不同情境套進同一組欄位會讓判讀條件消失；要在多個項目之間比較與排序時，欄位一致正是比較能成立的前提。
用內容類別當標籤會失準，因為同一份文件的不同段落可以落在軸的兩端——模組 _index.md 的章節說明是教學、Backlog 段是跨項比較，兩者共存於同一個檔案。判斷某一段該不該欄位化，問它服務的是哪一種閱讀動作，而不是問它屬於哪一類文件。
這也是為什麼標準表停在四欄：欄位的准入條件是「彙總會用到」而非數量上限——想加第五欄時先問它對應哪個彙總問題，對應不出來就該留在下方的敘事段。
模組自己的敘事段保留在標準表下方，正是為了守住這條界線。推演階段的順序依賴、觀念網路的補完理由、vendor 覆蓋的設計決策，這些內容繼續用各模組自己的語言寫，不受四欄約束。