本卡從一次教材路由事故抽出。新寫的密碼學選型章節在 out-of-scope 列表寫「金鑰託管平台選型 → 05-deployment-platform」，把讀者送去部署平台模組。實際上該模組的 vendor 清單是 docker、kubernetes、nginx、envoy、traefik 這類部署工具，一個金鑰託管平台都沒有，也沒有相關章節；而該模組自己的 vendors/ 底下有一整組金鑰託管與機密管理服務頁（aws-kms、hashicorp-vault、google-cloud-kms、azure-key-vault 等）——它們全都在本章自己的模組底下。這條路由送出去的位置，離正確答案比原地還遠。

事故經過三輪、十個 reviewer 的多輪審查沒有被抓到，由使用者閱讀時提問「這篇文章不存在，還是列在 backlog」而浮現——問題的形態是第三種：路由指向了不承接該主題的模組，兩個直覺解釋都沒中。

限制：本卡談的是路由的目的地驗收，不是路由的條目寫法（條目自包含見 #204）、也不是引用錨點的穩定性（見 #155）。適用於任何「把讀者送去別處」的結構：章節的下一步路由、模組的交接欄位、卡片的鄰卡連結、文件的參見段。

核心原則

路由的驗收條件是「目的地實際承接這個主題」，不是「目的地存在」。 兩者的差距在於：存在性可以機械驗證（檔案在不在、連結能不能點），承接與否要語意判定（那個模組真的有這個主題的內容嗎）。多數檢查工具與審查習慣都停在前者，而讀者受傷的是後者——他點過去、翻完整個模組、發現沒有，然後不知道該回哪裡。

這裡有一個容易誤判的分岔。發現路由落空時，直覺的兩個解釋是「文章還沒寫」或「已經列在 backlog」，兩者都預設方向是對的、只是內容還沒到。但還有第三種：方向本身錯了，內容在別處、甚至就在讀者剛離開的那一頁底下。這一種最難察覺，因為路由條目本身讀起來完全合理——把金鑰託管歸給部署平台，在語感上並不突兀。

承接之上還有一道關卡：可達。目的地確實擁有這個主題，但它埋在某個小節的第三層時，讀者到站後的體驗與落空相同——他看到一整頁不相干的內容，判斷「應該是我找錯了」然後離開。驗收因此要走到落點的第一屏：從路由指過去之後不再往下捲、不再點第二次，看得到這個主題嗎。存在、承接、可達是三道遞進的關卡，機械檢查只驗第一道，語意審查通常停在第二道。

反模式：驗證停在存在性，於是沒有一層對它負責

失效鏈在來源端有三層，每一層各自都在正常運作，合起來卻沒有任何一層負責這件事。

工具層：連結檢查驗的是目標檔案存在。而模組級的路由常寫成 code 格式的模組名（`05-deployment-platform`）而非連結——它不是連結，所以連存在性檢查都不進。指涉一個不存在的模組都不會報錯，更不會有人問它承不承接該主題。

審查層：跨章一致性 frame 查的是「連結有沒有斷、錨點在不在」，outbound frame 查的是「既有內容該不該指向新內容」。兩個 frame 的方向都對，但都不問「這條既有的路由，目的地真的有這個主題嗎」。這是 #126 說的軸線缺口——這一軸沒有人在看，而非某一軸做得不夠深。

作者層：寫 out-of-scope 與交接路由時，分配依據是主題的語感歸屬（金鑰託管聽起來像基礎設施、基礎設施像部署平台），而不是去目的地確認過。寫作當下這個動作的成本很低——切過去看一眼就知道——但它不在任何檢查清單上，所以不會發生。

這三層都是來源端的視角。目的地端還有一層沒有人在看：被指向的那個模組的維護者，沒有機制讓他知道有哪些 inbound 路由指著自己。這一端的檢查成本其實最低——模組主人最清楚自己承不承接某個主題。

四層失明疊起來的結果是：路由錯誤可以存活過完整的審查流程，最後由讀者承擔。這與 #155 指出的「misdirected 比 dangling 更難偵測」是同一個機制在模組層的形態——成功解析到錯的地方，比解析失敗更難發現，因為前者沒有任何錯誤訊號。

修法：寫路由時反向確認，落空時分四種處置

寫的時候：每寫一條跨模組路由，去目的地找出承接該主題的具體檔案或段落。找得到就把路由指向它（能給連結就給連結，比指模組名精確）；找不到就進入下面的處置分流。這個動作要在寫路由的當下做，因為當下正在想這個主題，判斷成本最低。

給不出連結時，條目要寫出剛才驗到的落點名稱（哪個檔案、哪一節），讓下一個人能複驗。只留模組名等於沒有留下驗證痕跡——去看過與沒去看過的產物完全相同，整條規則因此不可證偽。

落空時分四種處置，判準是「這個主題該不該由那個模組承接」：

• 指錯了：主題有內容、只是在別處。改指正確落點。這是最容易被誤判成「還沒寫」的一種，所以發現路由落空時第一步是全站搜一次該主題，確認它確實不存在，而不是直接假設要新寫。
• 該有但沒寫：方向正確、內容確實缺。列進目的地模組的 backlog，並在路由條目標明狀態，別讓讀者點過去撲空。接著判斷要不要先建簡版——判準是讀者到達後能不能拿到最小可行答案：如果一段話加幾個連結就能讓他繼續往下走，先建簡版比留空好，之後再補完整內容；如果這個主題需要完整推導才有價值，簡版會給錯誤的完成感，那就只留 backlog、路由條目暫時拿掉。登記時在前置條件欄註明是哪一篇路由指過來的，否則目的地模組無從知道有 inbound 路由押在這一項上。建了簡版的話該項仍留在 backlog 並標明現況是簡版——簡版讓路由不再落空，不代表主題已被承接，而路由不落空之後就沒有任何訊號會催它補完。
• 根本不該路由：這個主題不屬於任何現有模組、或它其實在本文的範圍內。刪掉該條，或收回本文處理。刪的前提是確認過它不屬於任何地方——只是暫時找不到落點時走 #212 的處置，標出建議目的地並登記待辦。刪除是這四種處置裡最省力的一種，而省力正是它會被誤選的原因。
• 目的地在自己維護的範圍之外：主題該由外部規格、官方文件或別人的知識庫承接。這一種的驗收條件與前三種不同，因為那個目的地會改版、改路徑、甚至下架，而自己沒有辦法讓它保持承接。處置是連過去的同時在條目裡寫明「到那裡要拿到什麼」，讓連結日後失效時讀者至少還知道自己該找什麼。反過來用：寫不出「要拿到什麼」的外部路由，通常是在推卸而不是在導引。

審查時：把「路由目的地承接驗證」列為一個獨立的檢查維度，逐條路由問「去那裡真的找得到嗎」，找得到的再問一次「到站的第一屏看得到嗎」。這一維不能靠連結檢查代勞，因為 code 格式的模組指涉不進工具的視野，而可達性連指得進去的連結也驗不了。

這一維的產出是一張逐條表（路由條目 / 目的地 / 實際承接的檔案或段落 / 到站第一屏看不看得到）。沒有列出條目的「已檢查」不成立——抽查三條與逐條驗完，在不列條目的報告裡長得一模一樣，而逐條驗的成本正是抽查的誘因所在。

Sibling 維度：需求最強的來源有沒有指過來

本卡驗的是 outbound——本文指出去的那條路由成不成立。反向的那一維同樣會 silent 失效：新內容寫完之後，最需要它的那些既有頁面有沒有指過來。

實測形態：四篇文章的審查揭露它們共用某個未承接的缺口，於是補了三章專門承接。三章寫完各自有三個以上的 inbound、orphan 檢查通過——而那四篇裡有三篇完全沒指向它們。四篇正是需求最強的入口（三章就是為了補它們的缺口而寫的），缺口卻留在那裡，因為寫新章時只寫了它自己的「下一步路由」（往外指），忘了往內指的那一半。

orphan 檢查對這種情形放行是必然的：它問的是「有沒有人指」，而這一維要問的是「該指的人有沒有指」。前者是數量門檻，後者要先答出「誰最需要這篇」。可操作的做法是新內容交付時列出它的需求來源清單（哪幾篇的讀者會需要它、各自在哪一段會產生這個需求），逐條回去補——而那份清單多半就是當初決定要寫這篇的理由。

跟其他原則的關係

• #155 引用章節用語意標題、不用位置編號：同一個失效機制（misdirected 比 dangling 難偵測）的不同層。#155 處理章節內的引用錨點會 silent 漂移，本卡處理跨模組的路由目的地會 silent 落空。兩者都是「成功解析到錯內容」沒有錯誤訊號。
• #204 路由條目要自包含：處理路由條目本身的可讀性（跳轉單位不依賴鄰條上下文），本卡處理路由指向的另一端是否成立。兩張卡合起來才是一條路由的完整驗收：條目讀得懂、目的地接得住。
• #232 自審 sweep 的偵測方法要對齊規則類型：本卡是它的具體實例。用「連結有效性」這個偵測方法去查「路由是否成立」這類規則，方法與規則類型不匹配——前者是機械可驗的存在性、後者是語意判定的承接關係，所以查了也抓不到。
• #126 寫作 review 是多軸完整性、不是單軸深度：補救是加一軸：完整的多輪審查沒抓到，是沒有任何一軸負責這件事，而非既有的軸做得不夠細。
• #244 範例讓最後一類出口缺口現形：本卡驗既有路由指得對不對，#244 驗該有路由的地方有沒有路由。一篇文章可以每條路由都通過本卡的三道關卡，而仍然在段落層級處處落空——兩者是同一件事的品質面與覆蓋面。
• #147 規範化跟自審是兩種認知任務：本卡把檢查維度寫進規範之後，同一批稿件的其他路由仍需另外掃一次——立規範的當下不保護已寫好的內容。

判讀徵兆

• 路由條目用 code 格式寫模組名（`05-deployment-platform`）而非連結：這種形態逃過所有連結檢查。
• 寫路由時的依據是「這個主題聽起來屬於哪個模組」而不是「我去看過那個模組有這個內容」。
• 讀者回報「這篇文章不存在嗎」：這個提問的形態通常預設方向正確，實際要先驗證的是方向本身。
• 同一個主題的 vendor 頁或章節在 A 模組，而 A 模組自己的路由把該主題送去 B 模組——路由送出去的位置比原地還遠。
• 模組的 out-of-scope 列表比它的實際交接關係長：宣告了很多「這不歸我管」，但沒確認過歸誰管。
• 路由指向一個很大的目的地（整個模組、整篇長文），而該主題在那裡只佔一小節：連結有效、主題也在，讀者到站後仍然要自己找。
• 判讀表的 N 列裡只有 M 列有對應的深化段：欄位齊全會遮住這個不對稱，而缺的那幾列等於認出自己之後沒有地方可去。

本卡從一篇 API 認證信任邊界章節的檢討抽出（backend 07 資安模組的認證分層那一篇）。該章以機制陳述為主：「使用者層可以撤銷單一 session 而不影響他人」「系統層的憑證由所有呼叫共用，撤銷等於中斷整條整合」，以及一段關於層間不互相代理與委任型例外的說明。三處都正確、也都經過完整的多輪審查，但提需求的人讀完提出的問題是：什麼情況需要撤銷使用者層、什麼情況必須撤銷系統層、什麼樣的系統會需要委任型設計。

這些問題有經驗的人不會問——他讀到「撤銷粒度」時，腦中自動浮現員工離職、密鑰進了公開倉庫、廠商通報外洩這些場景。沒有這些經驗的讀者拿到的只是一組屬性，連不到任何他會遇到的事。

值得記下的是原文並非完全沒有情境：它在講混層後果時帶到過「該使用者離職或密碼重設就會中斷整條整合」。真正的缺口在覆蓋而非有無：情境零星出現、沒有為每個判讀項目系統覆蓋，讀者因此無法預期哪一節會給他情境、哪一節不會。

限制：本卡談判讀 / 選型 / 決策類內容（回答「該怎麼判斷」的那一層）。純參考類內容（規格表、API 文件）以查詢為目的，不適用。

核心原則

判讀層的機制屬性要配上「什麼系統會遇到」與「什麼事件會逼出這個動作」，才對沒有相關經驗的讀者構成判準。 只給屬性時，讀者必須自己補上情境才能使用它。而補情境需要的是該領域的事故經驗，那份經驗正好也是這個判斷的輸入之一——能補的人已經握有做判斷的材料，內容對他的增量因此有限。

經驗是梯度，而可用程度沿著這條梯度呈單峰。熟悉一般後端事故、不熟這個領域的讀者補得出「員工離職」、補不出「系統層撤銷要先跟廠商約維護窗口」，內容對他部分可用——他是補情境收益最大的一端。再往外到完全不熟這個領域的讀者，缺的已經換成術語入口：連「撤銷」與「session」各指什麼都要先查，情境補了也接不上。可用程度因此在中段最高，兩端各自因為不同的原因掉下來，資深端不需要、零經驗端接不住。

這個形狀決定修法要分岔。判定「這篇不缺情境」時真正該確認的是它落在哪一端：資深端是真的不必補，零經驗端該補的是術語的卡連結而不是情境。把兩端一起歸進「不需補」，零經驗端的缺口就永遠不會被登記。

判定落在資深端時要說出依據——模組宣告的讀者定位、或前置章節已經教過的主線術語。這一端是整條規則裡唯一沒有後續動作的結論，也因此是最省力的結論；沒有依據的「資深端」與沒有做過判定沒有差別。

這裡要區分兩個常被一起排除的東西：

判讀層宣告「不展開實作」是正確的分工，但情境不是實作。判讀的定義就是「遇到 X 時該怎麼選」，把 X 拿掉之後，剩下的是分類學而不是判準。

分界線畫在解析度而非內容類型。「webhook 訂閱、B2B API 整合、對外發佈的授權憑證」與「用哪個雜湊演算法、timestamp 要不要併進簽章範圍」講的是同一件事的兩種粒度。判讀層取到讓成本可感的粒度就停——讀者要能推出這件事對他要花多久、動到誰、動不了的話卡在哪；再往下的函式庫與參數屬於下游，它讓讀者能執行，對「該不該做」這個判斷沒有增量。

用解析度當判準比用內容類型可靠，因為後者會誤判形如操作步驟的句子。「撤銷系統層憑證要先找到對方窗口、約一個雙方都能配合的維護時間」讀起來像操作指引，實際上是判讀層必須交出的成本量級——拿掉它，「撤銷等於中斷整條整合」就退回成一句沒有份量的屬性。

情境對應讀者的兩個時刻

情境有兩種，服務的讀者時刻不同，缺任一個時刻都會讓對應的使用場景落空。

先劃一條邊界：情境回答的是進入條件（這件事什麼時候跟我有關），走到這裡之後會怎樣屬於後果、住在下方兩拍寫法的第二拍。兩者不同層，後面補的敘事化後果不是第三種情境。

系統形態服務設計階段——讀者在問「我做的是哪一種系統，所以該注意什麼」。它的寫法是描述會走到這個問題的形貌與成因：哪些選擇會導致它、通常在什麼條件下形成、識別特徵是什麼。

形態的軸取決於讀者做這個決定時什麼是變數：已經有系統、正在決定要不要改它時，軸是架構長相；選型當下系統還不存在時，軸是團隊狀態（「當團隊只知道系統好像怪怪的，優先補訊號」）；對外契約類的軸則是關係人的能力（消費者能不能被強制更新）。判定某篇缺形態之前要先問它用的是哪條軸——只找架構軸會把用其他軸寫成的形態誤判成缺。

觸發事件服務事故與維運階段——讀者在問「現在發生了這件事，該動哪一層」。它的寫法是列出會逼出這個動作的具體事件：帳號被盜、員工離職、密鑰外流、廠商通報、輪替到期。

判讀類內容常見的問題節點表通常有「判讀訊號」欄，但那一欄有時序陷阱：訊號要等設計已經落地才觀察得到，設計階段的讀者手上是空的。系統形態填的正是這個空缺。

反模式：把情境當成實作一起排除

失效鏈很短：定位為判讀層 → 宣告不展開實作 → 情境跟著被省掉 → 內容變成純屬性陳述 → 審查查不出問題（每句都正確、結構也完整）→ 能用的讀者收斂到已經握有那份經驗的一端。

審查查不出來的原因是所有既有的檢查維度都會通過：技術正確性通過（屬性描述沒錯）、寫作規範通過（核心原則先行、正向陳述都合格）、結構完整性通過（該有的段落都在）。缺的東西不在任何一欄裡。

有一個訊號能在事後辨識這種失效：同一篇裡通常會有一兩節「不小心寫對了」。該篇的「何時可以合併層級」一節就寫了「單一前端搭配單一後端、沒有第三方整合時」——這就是系統形態，讀者能直接對號入座。同一位作者在同一篇裡做得到，代表這不是能力問題，是沒有檢查點的問題。修法方向因此是加檢查維度，而不是加寫作指導。

修法：兩拍寫法，形態值得獨立成節

每個判讀項目寫成兩拍：先寫什麼系統會走到這裡（含成因與識別特徵），再寫走到這裡會失去什麼 / 該怎麼選。第一拍讓讀者認出自己，第二拍才是原本就有的後果分析。

形態的份量足夠時獨立成節，緊接在問題節點表（逐列列出風險節點與判讀訊號的那張表）之後作為延伸段。份量的判準是累計超不超過一段；判「不夠」而改行內補時，行內那一句的下限是讀者能從它認出自己的系統——只加一個規模形容詞（「大型系統會遇到」）不構成形態，它是把判定寫成了合規的形狀。獨立的理由是它服務的是設計階段的讀者，而後果分析服務的是已經落地之後的判斷，兩者的使用時機不同；混在一起會讓設計階段的讀者要在後果描述裡自己挑出形態。

修的時候有兩個固定副作用要一併處理：

其一，補情境會引入第二人稱。具象化的敘述天然帶出「你的產出物」「你得先找到窗口」這類寫法，因為講情境時會不自覺對著人講。中性陳述的教材規範在這一步最容易破功，補完要專門掃一次。

其二，原本的封閉計數會失準。缺情境常常伴隨缺段落——該篇修正前寫「三種混法」而問題節點表有四個節點，因為第四類從來沒有獨立段落。補上第四類之後，「三種」這個數字才浮現為錯誤。反過來說，封閉計數與表格列數對不上，本身就是缺段落的偵測訊號。

跟其他原則的關係

• #217 審查要有斷言支撐 frame：兩者都讓判準無法使用，但斷點不同。#217 的判準空殼是「停在維度清單、沒有條件到行動的映射」；本卡的判準有映射，缺的是讀者不知道什麼時候會踩到這個判斷。前者是判準本身沒寫完，後者是判準寫完了但沒有入口。
• 常識是相對於讀者背景的：同構問題的不同層。那張卡處理術語（作者的常識不是讀者的常識），本卡處理情境（作者的經驗不是讀者的經驗）。兩者的共同機制是作者把自己的背景投射成讀者的背景，而同源審查者有完全相同的投射。
• 多輪審查缺 outside-in 讀者 frame：本卡是它的一個新盲點實例。既有的 outside-in frame 問「讀者讀完要做什麼」與「他懂不懂這個術語」，還沒有人問「他想不想像得出來這些情況會發生」。
• #126 寫作 review 是多軸完整性、不是單軸深度：三輪審查通過而使用者一讀就發現，是缺一軸而非某軸不夠深。
• #244 範例讓最後一類出口缺口現形：同一個投射的兩種形態。本卡是作者假設讀者知道什麼時候會遇到，#244 是作者假設讀者知道遇到之後怎麼辦；兩者都因為作者自己兩件事都知道而不可見，補寫順序上也接在一起。
• #240 跨模組路由要驗證目的地承接該主題：同批事故的姊妹卡。#240 是路由指向錯地方，本卡是內容本身缺情境；兩者都由使用者閱讀時提問而浮現，都不在任何審查維度的視野內。

判讀徵兆

• 讀者的提問形態是「什麼情況會需要這個」「什麼樣的系統會這樣做」——這是缺情境的直接訊號，而不是讀者不夠用功。
• 判讀類內容以屬性陳述為主（X 具備 Y 特性、A 與 B 的差異在 C），情境零星出現而未覆蓋各判讀項目。
• 判定某篇缺形態時只找了架構長相這一種軸，沒問它是不是用團隊狀態或關係人能力當軸。
• 判定「不需補情境」時沒有分辨讀者落在哪一端：資深端確實不必補，零經驗端缺的是術語入口，兩者被歸成同一個結論時後者的缺口不會被登記。
• 判讀層被裁掉的內容裡有成本量級（要協調誰、要等多久），理由是「那屬於實作」——這是把解析度誤判成內容類型。
• 問題節點表的每一列都有判讀訊號，但那些訊號都要等設計落地才觀察得到。
• 同一篇裡有一兩節寫了具體系統形態、其餘沒有——代表能力在、檢查點不在。
• 封閉計數（「三種混法」）與表格列數對不上。
• 內容被有經驗的同事評為「寫得很清楚」，同時被新人評為「看不懂要幹嘛」。

本卡從一次教材補寫的中途檢討抽出。起點是使用者指出判讀類章節「只講理論、沒有範例，沒有經驗的人無法想像各種有風險的情境」。當時把這個需求轉化成「補系統形態與觸發事件」——形態回答「什麼樣的系統會遇到」、觸發事件回答「什麼事件會逼出這個動作」，並據此完成了數篇補寫。

補完之後使用者再次提問：有找到需要補案例的地方嗎，怎麼沒看到補案例的動作。這個提問揭露原始需求被轉化掉了一半：形態與觸發事件解決的是「我是不是這一類」，而「無法想像風險情境」問的是「出事會長什麼樣」。前者是分類，後者是敘事，補了前者不等於補了後者。

轉譯之所以沒被自審抓到，是因為補上的內容通過了所有既有檢查——技術正確、規範合格、結構完整，缺的東西不在任何一欄裡。止血的代價則隨時間線性成長：轉譯發生在最前面，修正要回頭動原則卡、操作規範、待辦描述，以及每一篇已經照舊定義補寫過的章節。

上面三段就是一則微案例，四拍齊全：當初為什麼那樣轉譯（分類語言可檢查可窮舉）、什麼時候發現（補完之後被再問一次）、為什麼自審抓不到（通過了所有既有檢查）、修正要付什麼（成本隨已完成篇數成長）。

限制：本卡談教學章節內的短敘事，不談案例庫的建立與引用（後者見 #224）。適用於判讀 / 選型 / 決策類內容，純參考與程序型不適用。

核心原則

形態讓讀者對號入座，微案例讓他想像後果，兩者服務不同的認知動作、缺一則判讀不完整。 兩者的分界在靜態與時序：形態與後果分析都交代得出後果是什麼（「撤銷等於中斷整條整合」就是後果），交代不出它怎麼發生、為什麼沒被擋下。微案例補的正是那條時間線。

沒有經驗的讀者卡在後者。他讀完形態知道自己中了，但不知道中了會怎樣——而「會怎樣」正是他需要用來說服自己或說服團隊的依據。有經驗的人能自己補上這一段，這也是為什麼純形態的內容對資深讀者看起來已經完整。

微案例指的是無身分的短敘事：三四句、不帶公司名、不帶年份、不帶數字帳目，只保留失敗的過程與它為什麼沒被及時發現。

跟真實 case 的分工

教學層引用真實 case 時要剝離身分與規模鋪陳（見 #224），因為那些帳目的住址在 case 記錄原文。這條原則擋住了「在章節裡展開某公司某年某事件」這個做法，於是很容易得出「章節不該有敘事」的結論。

#224 禁的是搬運帳目與身分，具體敘事不在它的範圍內。無身分的微案例同時滿足兩邊：它有敘事因此可想像，它沒有身分與帳目因此不侵占 case 記錄的責任。

分工是：微案例在章節內、承擔「讓形態變得可想像」；真實 case 在案例庫、承擔「這件事真的發生過、細節可查證」。章節的案例參考段連過去，兩者不互相取代。

反模式：把「補範例」轉譯成「補分類」

失效鏈是：讀者反映缺範例 → 執行者轉譯成可操作的工作項 → 轉譯時選了分類語言（形態、類型、判準）→ 補完之後每一項都正確，但原始需求只被滿足一半 → 因為補上的內容通過了所有檢查，沒有訊號提示還缺什麼。

這個轉譯有其道理——分類語言可檢查、可窮舉、可寫進規範，敘事不行。執行者傾向選可操作的那一種，而這個傾向本身不會被自審抓到，因為轉譯之後的工作項確實被完整執行了。

辨識訊號是提出需求的人再問一次。第一次提需求說「缺範例」，補完之後又問「怎麼沒看到補範例」，代表轉譯過程中丟掉了一半的需求。這時要回去對照原始用詞，而不是解釋自己補上的內容為什麼也算範例。

修法：四拍敘事，寫在形態之後

微案例緊接在形態之後，讀者剛對號入座、動機最強的位置。四拍結構：

1. 當初為什麼這樣做——寫出當時沒有人反對的理由（比較快、省一跳、兩邊都是自己人）。缺這一拍，讀者會覺得「這是別人才會犯的蠢錯」。
2. 什麼時候開始出問題——時間推進，而非同時發生。這類問題的特徵是決策與後果之間有一段時間差，長到當事人不會把兩件事連起來。
3. 為什麼沒有被及時發現——監控盲區、時間差、責任分散。這一拍最不可省略：第一、二、四拍讀者能從機制自行推得（動機、時間差、修復成本都是屬性的延伸），第三拍取決於該組織的監控與責任配置，是唯一推不出來的，也因此最常被省略。
4. 止血的代價——修復本身要付什麼。缺這一拍，讀者會低估這件事，以為出事再改就好。

長度控制在三四句。要更長就代表它該進案例庫，而不是留在章節裡。

四拍依情境取捨：第三拍最不可省，第一與第四拍在後果已經很直觀時可以壓成半句。判準是拿掉之後讀者會不會低估這件事——會，就補回來。這個判準要對著沒有經驗的讀者問，因為已經懂機制的作者自評時最省力的答案永遠是「不會」，於是第一、四拍長期被壓成半句、微案例退化成兩拍。壓縮後的第一拍仍要說出當時這個決定的合理性（「兩邊都是自己人」）；只寫「為了省事」會讓它退回成蠢錯。

微案例挑後果最不直觀的一兩個形態寫；直觀的（例如密鑰外洩會被冒用）補了是冗餘。「一兩個」是上限而非配額——下限由不直觀的形態有幾個決定：先把該篇的形態按後果直觀程度排序，最不直觀的必寫，有兩個以上而只寫一個時要說出漏掉的那個為什麼可以不寫。排序在動筆前做；照節次順序補到哪算哪，挑中的通常正好是後果最直觀的那幾類。

那個理由要落在後果直觀程度上，「在別處已經展開」不成立。 一個形態的後果可以既在別處寫過又完全不直觀，因為別處那段多半是分析——成本結構、修法、風險邊界——而微案例補的是敘事，正是本卡開篇分開的那兩件事。分析替代不了敘事；能替代的只有另一段敘事（同站的真實案例、或另一篇的微案例）。理由寫成「別處已展開」時，規則的外觀留下了、判準被換掉了，而換掉之後每一處看起來都像照規則寫的（見 #243）。寫不出直觀程度的理由、又找不到承接它的敘事時，正確的處置是把它登記成待寫的候選，而不是替它找一個理由。

而判定某個形態「後果直觀」之前，先查它有沒有已經被登記成待補的微案例。 這條規則可以被形式滿足而實質錯誤——理由的形狀對了（用的是直觀程度）、判定卻與自己的待辦清單相反，而兩處相反的時候，登記處那一份通常才是對的：它是在盤點的視角下判的，正文那一份是在「這一段要收尾了」的壓力下判的。兩處先收斂再寫。

四拍要有來源

四拍是敘事的骨架，不是可以填滿的欄位。每一拍要出自親歷的事件、案例庫已經記下的形態、或機制上必然如此（時間差、共用憑證隨產出物擴散的途徑，這一類推得出來）。

第三拍的風險最高，而且風險的來源正是它的價值：它是唯一推不出來的那一拍。推不出來意味著沒有這段經驗的作者只能發明它，而四拍結構本身沒有任何地方會擋下發明——編造的監控盲區讀起來與真實的一樣完整。這條口子在方法被交給缺乏該領域經驗的人或交給生成工具執行時最先破：他們拿到的是一個可以照填的模板，而模板的第三格恰好是他們手上沒有的東西。

寫不出真實來源時，第三拍留白比杜撰好。編造的後果不是讀者少學一件事，是他據此以為自己的監控只要補上那一項就夠了——一則具體而錯誤的盲區，比沒有微案例更難被後續的審查推翻，因為它讀起來已經很像經驗。四拍都找不到來源時，這一節留空並列進待辦，等素材出現再補。

留白要留下可追蹤的痕跡，否則它在事後與「沒想到要寫」無法區分。三件事一起做：不用概括句把第三拍補滿（概括句會讓後人以為這一拍已經寫過）；backlog 的前置條件寫出缺的是哪一類素材（「缺該形態的實際事故記錄」而非「缺素材」）；設一條 tripwire——該形態的案例庫新增任一則、或同類事故在自己的系統發生過一次，就回頭補這一拍。少了後兩項，「留白比杜撰好」會從暫緩退化成永久豁免：沒有觀察者會觸發回補，而「等素材出現」本身不是一個會被誰注意到的事件。tripwire 住在模組的 tripwire 段，該項仍留在 backlog——它已經決定要做、只是被素材阻塞，與「tripwire 不進 Backlog」不衝突。

這條要求連帶決定了補寫的排程：微案例不能靠一輪掃描補完全部章節。有素材的先補，其餘的登記缺口，等案例庫累積到能支撐。

跟其他原則的關係

• #241 判讀層只給機制屬性時，可用程度隨讀者既有經驗遞減：本卡是它的補完。#241 的情境有系統形態與觸發事件兩種，都是分類語言、回答讀者的進入條件；本卡補的微案例並非第三種情境，而是把 #241 兩拍寫法裡第二拍的後果分析從分析換成敘事。三者的認知動作分別是「我是哪一類」「什麼時候要動」「動作晚了會怎樣」。
• #224 教學層引用 case 要剝離身分與規模鋪陳：本卡處理它留下的空白。#224 說明了為什麼不能搬帳目，沒有說明「那要用什麼填」——無身分微案例就是答案。
• #115 案例引用深度跟著 case 類型走：來源紀律的同一條線延伸到另一種載體。#115 管的是引用他人 case 時把 skeleton 擴寫成 rich case（編造細節），本卡的「四拍要有來源」管的是不引用任何 case、作者自寫敘事時同一個編造壓力——載體從別人的紀錄換成自己的短敘事，而後者沒有原文可以對照，因此更難被抓到。
• #244 範例讓最後一類出口缺口現形：本卡的產物是它三種盤點單位裡的第三種。四拍的最後一拍（止血代價）把讀者推到「所以要怎麼止血」，而那個問題在分析段落裡不會被問到——微案例寫完之後要為這一類單位再跑一次出口盤點。
• #126 寫作 review 是多軸完整性、不是單軸深度：需求被轉譯掉一半而全程沒有訊號，是缺一軸的典型——所有既有檢查都在驗「補上的內容對不對」，沒有一項在驗「補上的內容是不是原本要的」。

判讀徵兆

• 提需求的人在補寫完成之後，用原本的詞再問一次（「怎麼沒看到補範例」）。
• 章節裡的形態是一串標籤或短句列舉，通篇沒有任何一段有時間推進。
• 內容能回答「我是不是這一類」，回答不了「所以會發生什麼」。
• 把需求轉譯成工作項時，選的詞跟提需求的人用的詞不同，而這個差異沒有被明說。
• 微案例的第三拍寫得比其他三拍概括（「監控沒有涵蓋到」而不是哪一段路徑沒有涵蓋）——概括通常是沒有來源時留下的痕跡。
• 一輪補寫就讓所有章節都有了微案例：素材不會剛好夠用，全數齊備代表其中有一部分是照模板填的。

本卡從兩篇資安選型章節補完範例之後的一輪盤點抽出。兩篇都經過完整的多輪審查、也都剛補過系統形態與微案例，技術正確、結構完整、路由段齊備。補完之後改用一個新問題掃全文：讀者現在知道這是問題了，他去哪解決。

盤點結果是七處缺出口。其中兩處的目的地其實存在且承接該主題，只是連結在一百行之後的文末路由段——讀者在問題發生的位置提出疑問，答案放在他讀完整篇之後才會遇到的地方。另外三處是主題根本沒有落點，而文中沒有任何一句說明它不存在；讀者找不到時的預設歸因是自己沒找到，於是把時間花在搜尋上。

這七處在那一輪之前都沒有被發現過，而那一輪同時改變了兩件事：補上了微案例，並且改用一個新問題掃全文。事後拆開來看，七處裡只有兩處依附於微案例（它們是微案例末端那句「補起來要……」帶出來的），其餘五處掛在問題節點表與風險邊界上——那兩種單位在任何微案例存在之前就已經存在。真正讓它們現形的是換視角，不是補範例。

限制：本卡談教學內容的出口完整性，適用於判讀 / 選型 / 決策類與操作類內容。純參考類（規格表、API 文件）以查詢為目的，讀者不帶問題來，不適用。

核心原則

出口盤點的視角是讀者的下一個動作，而單位是每一句「指名了問題卻沒有就地解決」的話——其中只有一類要等範例存在，因此盤點要跨兩個階段各跑一次。 判讀表的每一列、風險邊界的每一條、out-of-scope 的每一項宣告任何時候都掃得到；微案例末端那句「補起來要……」要等微案例寫出來才有。把整個盤點延到補完範例之後，前兩種單位的缺口會被拖著；只在補範例之前掃一次，第三種永遠掃不到。

真正讓缺口現形的是換視角。所有既有的檢查維度都在驗「已經寫的內容對不對」：技術正確、規範合格、結構完整、路由段存在。缺的是「這一段提出的問題有沒有被接住」，而那要用讀者的下一個動作當視角，不是用段落本身當視角。用段落當視角時「撤銷等於中斷整條整合」讀起來完整——句子把後果講清楚了、本身沒有缺口。

範例在這件事上的貢獻是多出一類單位，其餘各類與它無關。四拍的最後一拍是止血代價，它把讀者推到「所以要怎麼止血」，而那個問題在分析段落裡不會被問到——這一類缺口確實只有補完範例才掃得出來。

檢查單位是每個被提出的問題，不是每篇文章

文末的「下一步路由」段是文章層級的出口。它回答「讀完整篇之後往哪走」，回答不了「讀到第三節這一句時我該怎麼辦」。有路由段的文章仍然可以在段落層級處處落空。

盤點的單位因此是每一個被提出的問題，判準是「這一句指名了一個問題而沒有就地解決它」。這是規則而不是清單——本卡最初把它寫成三項封閉枚舉（判讀表的列、風險邊界的條、微案例末端的止血句），而下方判讀徵兆自己就列了第四類（out-of-scope 宣告到「不在本章範圍」為止），那一類在多數章節的密度還高於前三類。收斂動作段的每一步、跨章交叉引用段同樣會生出新問題。

命中率最高的仍然是那三類，掃描時先掃它們；而三類裡只有微案例末端要等第二階段才存在。

微案例末端的命中率最高，也是唯一要等範例存在的一種；其餘各類在文章寫完的當下就可以掃，不必等。

四種出口狀態與處置

出口存在且就在手邊——合格，不必動。

出口存在但在文末——目的地承接該主題、連結也有效，只是離問題發生的位置太遠。就地補一句連結，並在句子裡說明去那裡要拿到什麼。這是可達性問題在文章內部的形態，與 #240 的模組層可達是同一個機制。

出口不存在、而主題能用最小可行答案打發——當場補。判準是一段話加幾個連結能不能讓讀者繼續往下走；能的話寫進本文，主題份量夠獨立成篇的就寫簡版新章節，深度留待辦。簡版要在開頭明說自己是簡版與缺什麼，否則它會被當成完整內容而永遠不被補完。

出口不存在、而主題需要完整推導——明說它不存在，並給一條最小判準讓讀者當下不至於卡住。明說是這一格的重點：讀者找不到某個主題時的預設歸因是自己沒找到，沉默會讓他把時間花在搜尋上。給最小判準則讓「尚無專章」不等於「無從下手」。

而「已列入待辦」不要寫進正文。 這一格要交給讀者的是兩件事——它不存在、以及在那之前怎麼辦——待辦狀態是第三件，屬於維護者。差別在讀者拿它做不了任何事：他無法據此調整判斷，只會知道作者記得這件事。內部狀態的住址是那份待辦清單本身，而正文寫進去之後兩處會各自漂移，那時清單被清掉而正文還在說它排著。

反模式：刪範例時連帶刪掉唯一的止血知識

微案例的第四拍（止血代價）常常是全篇唯一寫出止血路徑的地方。依「挑後果最不直觀的一兩個形態寫」的規則替換微案例時，被換掉的那則裡的止血資訊會一起消失，而替換的理由（後果太直觀）只評估了前三拍。

實際發生過：一則微案例因為後果過於直觀被換掉，而它的第四拍是全篇唯一提到「換密鑰會讓所有還沒更新的使用者一起失效」的地方。替換當下沒有人注意到這一句沒有別的落點，直到出口盤點才補回來。

處置是替換微案例前先掃第四拍：那句止血描述在文章別處有沒有第二個出處。沒有的話先把它移進風險邊界或判讀段，再替換。

跟其他原則的關係

• #242 形態讓讀者對號入座，微案例才讓他想像得出後果：本卡承接它的產物。#242 說明微案例讓後果可想像，而可想像的後果會產生一個新問題（怎麼辦）——那是出口盤點三種單位裡的第三種。兩張卡的關係是交錯而非前後接續：出口盤點在形態階段跑一次（涵蓋節點表與風險邊界），微案例寫完再跑一次（涵蓋止血代價那一類）。
• #240 跨模組路由要驗證目的地承接該主題：#240 檢查已經寫下的路由指得對不對，本卡檢查該有路由的地方有沒有路由。前者驗既有連結的品質，後者驗連結的覆蓋；一篇文章可以每條路由都正確而仍然處處落空。
• #241 判讀層只給機制屬性時，可用程度隨讀者既有經驗遞減：同一個投射的兩種形態。#241 是作者假設讀者知道什麼時候會遇到，本卡是作者假設讀者知道遇到之後怎麼辦。兩者都因為作者自己兩件事都知道而不可見。
• #246 被多篇當成前提的判斷缺的是住址：本卡第四種狀態（出口不存在就明說並給最小判準）的反面。那一格處理的是單篇視角下的落空，而 #246 的缺口在單篇視角下不落空——每一篇都給了自己那一角、讀者當下走得下去，要看見它必須換成跨篇視角。
• #126 寫作 review 是多軸完整性、不是單軸深度：缺出口是又一條沒有人負責的軸——既有維度都在驗已寫內容的正確性，沒有一項在驗「提出的問題有沒有被接住」。

判讀徵兆

• 文章有完整的「下一步路由」段，而正文某一節的問題在那個段裡找不到對應項。
• 微案例的最後一拍寫了止血代價，而全文沒有任何一處說明止血要怎麼做。
• 某個主題在文中被提到「不在本章範圍」，句子到此為止而沒有給落點。
• 讀者問「這個情境有對應的解決方案章節嗎」——這個提問形態代表他已經認同問題、卡在下一步。
• 出口只盤點過一次：兩個階段各跑一次才涵蓋三種單位，一次掃描必然漏掉其中一類。
• 掃描報告說「路由段齊備、無缺口」：這是段落視角的結論，換成讀者的下一個動作當視角會得到另一份清單。

本卡從一個資安模組跑完四輪審查之後的盤點抽出。那個模組的待辦清單有十一項，其中五項是同一個形狀：資產盤點、機器憑證的配發流程、管理平面的隔離設定落點、委任型憑證的機制選型、授權模型選型。五項的共同點是它們在多篇章節裡被當成前提引用——某一篇說「這件事要靠 inventory 才做得到」、另一篇說「輪替覆蓋率要有分母」、第三篇說「暫時緩解要靠它選降級路徑」——而沒有任何一篇承接它。

更值得記的是這五項全部是審查時才被登記的，沒有一項在寫作當下浮現。寫每一篇的時候，那一角是本篇需要的、也寫得出來、寫完本篇就完整了。

觸發本卡的是第六個實例。一輪 steelman 指出某章「缺了先問要不要自己做這件事」，修法因此落進那一章的前置段。事後回看，那個前置段回答的問題與另外兩處碎片（一項待辦、一個全站零落點的主題）是同一條判斷軸的三個角，而那條軸在所有相關章節的上游。

限制：本卡談的是判斷型內容之間的共同前提。純術語的重複出現是另一回事，處置是建卡而非建章（分界見下方修法段）。

核心原則

一個判斷被多篇當成前提時，它缺的是住址而不是內容；而每一篇的檢查都看不到這件事，因為每一篇只需要它的一角，而那一角每篇都寫得出來。 缺口只在把幾篇並置之後才出現，而並置不是任何既有檢查會做的動作。

機制在於共同前提沒有歸屬。教學模組的章節多半由具體問題長出來——事故發生在機制上，於是章節對著機制寫。而「該不該做這件事」這一層是所有相關章節的共同前提，它不是任何一篇的缺口，因此沒有任何一篇的寫作動機會帶出它。

有一個形式讓這件事更難察覺：前置段。不屬於本篇的內容放進前置段之後，它有了一個看起來合法的容身處——因為前置段確實是本篇需要的，它是這一章的適用性閘門。所以它不觸發「不屬於這篇的內容要找出路」那條規則（見 #212），那條管的是不屬於，而前置段屬於。真正的問題不是它放錯地方，是整條軸只有一角被寫下來，而那一角是從下游那一篇看得到的那一角。

反模式：修法落點跟隨發現路徑

這一類缺口通常由審查發現，而審查是逐篇進行的。reviewer 從某一篇出發說「這篇缺了前置」，修法就落回那一篇。整個過程沒有任何一步是錯的，產出卻是把一條跨篇的軸壓成某一篇的一段。

發現路徑因此決定了修法形狀。同一件事若由「模組覆蓋」的視角提出，修法會是新開一篇；由「這一篇缺什麼」的視角提出，修法會是補一段。而審查框架整體偏向後者——各種 frame 問的都是「這篇有什麼問題」，連反向引用那一維也是問「既有內容該不該指向新內容」，方向仍然是單篇對單篇。

辨識訊號是修法之後那一段讀起來比它所在的章節更上游。前置段回答的問題比本章的主題更早發生、而且對別的章節同樣成立時，它就不只是前置段。

修法：先分缺卡還是缺章，再讓各篇保留自己那一角

分界在重複的是定義還是判斷的角。 同一個名詞在多篇各被解釋一次、每次解釋的內容相同——那是術語，處置是建卡，各篇連過去。同一條判斷軸在多篇各被交代一角、每篇寫的角度不同——那是缺章，因為取捨需要並置才成立，而並置只能發生在同一篇裡。

偵測方式是數：同一個概念被三篇以上當成前提，且各篇寫的不是同一句話時，觸發評估。三篇是門檻而非定則——兩篇時通常仍是其中一篇的延伸段，三篇之後「哪一篇是主場」這個問題就沒有答案了。

新開一篇之後，各篇的那一角要留著。 它是本篇的適用性閘門，讀者需要在這裡就知道自己該不該繼續讀下去；刪掉它會讓每個入口都少一道判斷。留著的形式是壓縮成一到兩句加一條路由——保留判準、把取捨的推導交給上游那一篇。

新篇要標明自己是誰的上游。 這一類文章的讀者路線與模組既有的路線不同：它在所有下游章節之前，而模組入口的路線敘述多半是照章節編號寫的。缺這一句時，新篇會變成又一篇沒有入口的內容。

跟其他原則的關係

• #212 不屬於這篇的內容要找出路、不是刪除：本卡是它的盲區。#212 處理的是明顯不屬於本篇的內容，判別靠「主題與篇標題不同」；而共同前提放在前置段時確實屬於本篇，主題也對得上，所以那條檢查不會觸發。兩者的差別在缺陷位置——#212 的內容放錯了地方，本卡的內容沒放錯，只是整條軸只寫了一角。
• #244 範例讓最後一類出口缺口現形：#244 的第四種狀態（出口不存在就明說並給最小判準）處理的是單篇視角下的落空，而本卡的缺口在單篇視角下不落空——每一篇都給了自己那一角、讀者當下走得下去。要看見它必須換成跨篇視角。
• #126 寫作 review 是多軸完整性、不是單軸深度：又一條沒有人負責的軸，而且它是跨篇的軸。既有的維度不論多細都是對單篇操作，把每一篇都做到滿分仍然不會發現這件事。
• #221 檢查規則的作用域要顯式列舉：同樣讓「每一篇都通過」失去意義。#221 是規則沒有涵蓋到那些檔案，本卡是檢查的單位（單篇）小於缺陷的單位（跨篇）。
• #247 多次局部正確的修法會合成缺陷：本卡的缺陷單位是跨篇、它的第二種形態的缺陷單位是共用產物（模組入口、待辦清單），兩者都因為既有檢查的單位小於缺陷的單位而漏掉。
• #263 同一個對象被兩篇各自分解一次時，不相容會長得像互補：同一條跨篇軸上的另一端。本卡的對象有零個住址（一個判斷被多篇當前提而沒有任何一篇承接），那張卡的對象有兩個住址（一個對象被兩篇各自分解），而兩者的偵測動作相同——把整批的前置段或表格並置，逐篇審查都不觸發。
• #245 原則層與操作層是兩份會漂移的副本：同一種「並排才看得見」的家族。#245 的並排對象是同一條原則的兩個副本，本卡的並排對象是同一條軸的幾個角；兩者都要靠一個沒有人會自然做的動作才現形。

判讀徵兆

• 模組的待辦清單裡有多項是「某某的完整處理 / 某某的選型」，而它們在正文都以「這要靠 X」的形式被引用過。
• 一項待辦全部由審查登記、沒有一項在寫作當下浮現。
• 某一章的前置段回答的問題比該章的主題更早發生，而且對別的章節同樣成立。
• 同一個名詞在三篇以上出現，每篇各交代一次，而三次交代的角度都不同。
• 讀者問「這個情境有對應的章節嗎」，翻查之後發現內容散在三處、每處都只有一角。
• 模組入口的讀者路線是照章節編號寫的，而路線的第一站不是讀者實際要做的第一個決定。

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 覆蓋的設計決策，這些內容繼續用各模組自己的語言寫，不受四欄約束。