結論

「Stage B 以 Stage A 的清單為輸入」— 這句話讀起來像契約、實際上常常只是相鄰。它成立的條件在欄位層：下游輸入的每一欄、要能對到上游產出的某個欄、或一條明文的推導規則 — B 需要的每欄、A 的表裡有、或文件寫明「B 的欄 y 由 A 的欄 x 依規則 R 推導」。多階段流程（訪談協議、ETL、表單審批、CI pipeline）的每個交接處都適用這條檢查。

缺口的形態很安靜：A 的表七欄、B 要求的第八種資訊不在七欄裡、也沒有任何地方說明從哪來 — 執行者到了 B 才發現缺、回頭從 A 的欄位自行腦補。可推導時每個執行者推得不一樣、不可推導時就空著或亂填；而缺的欄位往往正是流程分支的開關（「失敗語意 = 不可丟」觸發整個 durable 機制）、開關欄自由心證等於分支隨機。

能推導、跟有規則、是兩回事

「語意上推得出來」會讓設計者誤以為不用寫：失敗語意「顯然」能從失敗情境跟風險欄看出來。沒有明文規則時、三個執行者會用三種標準推、而且都覺得自己推得有道理。

缺口在設計期隱形的原因是接縫沒有 owner：A 的表為 A 的目的設計（盤點操作）、B 的輸入為 B 的目的宣告（標 event 語意）、每一份單獨 review 都通過 — A 的作者覺得交付了、B 的作者覺得宣告了、欄位對不對得上沒有掛在任何人名下。浮現的唯一方法是把 B 的輸入逐欄對 A 的產出走一遍。

反模式與修法

逐欄走查的操作：列出下游輸入格式的欄位清單、每欄標注來源 —「上游欄位直給」「明文推導規則」「缺」三種狀態、「缺」逐個補。同一條契約在機器管線同樣成立：CI 的 deploy stage 宣稱以 build artifact 為輸入、需要的 version tag 卻沒有任何 stage 產 — 差別只在機器管線會當場報錯、文件協議的缺口靜默到執行者卡住那天。

跟其他抽象層原則的關係

• #153 Review 漏抓先分 design gap 與 execution gap：#153 立卡情境是 review 流程的漏抓、這裡把它的診斷分流借到流程設計：執行者標不出失敗語意、不是不認真、是設計沒給推導規則 — design gap、修法在文件、不在叮嚀執行者。
• #68 驗收的時間軸：四個 checkpoint：階段交接處是天然的驗收 checkpoint — 逐欄走查就是交接處的驗收動作、在「寫之前」的 checkpoint 跑一次、比執行者在第三階段卡住才回頭便宜。
• #44 Single Source of Truth：推導規則本身要有單一明文位置 — 沒有明文規則時、規則存在於每個執行者腦中、是 N 份互不一致的隱性源；寫下來不只是溝通、是把規則收斂成單源。
• #158 決策表兩列同時命中且結論相反：同一族的「組合失效」— #158 是規則之間的矛盾、本卡是階段之間的缺口、偵測都要跨單元走查（#158 靠真實案例 dry-run、本卡靠逐欄對照）而不是單元內檢查；兩者常在同一次旅程模擬中被一起抓到。

觸發 case

一個訪談協議的操作盤點階段產出七欄表（操作 / 角色 / 主情境 / 失敗情境 / 風險類型 / 前端引導 / 後端防護）、domain / event 切分階段的 event catalog 要求每個 event 標「失敗語意（可丟 / 不可丟）」— 且這一欄是 async-queue 維度升級為必展開的開關。讀者旅程 reviewer dry-run 時發現：七欄裡沒有失敗語意、兩份 reference 也都沒說明從哪推導、「runtime 要從失敗情境自行推導、可推但容易漏標」。修復落在 event catalog 的產出格式旁、把推導規則寫成明文 —「操作牽涉金流、合約或通知義務 → 它的 event 不可丟；event 只驅動可重算的衍生結果 → 可丟」— 上游的表一欄都沒加。

判讀徵兆