論述基礎與限制

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