本篇是故事三的「理解」篇。

本篇要回答：逗號只是直接原因——是哪些條件讓一個字元的失誤，取得了橫穿整套系統的通行證？

當時發生了什麼

回看這場事故，我先後拿到過三張「沒問題」的證明：直譯器說語法合法、執行期說程式沒炸、測試說案例通過。三張證明疊在一起，看起來像系統正確；實際上它們證明的是三件不同的事，而「資料符合契約」不在其中任何一張裡。

我原本怎麼判斷

我曾把三張證明當成同一張的三種說法。拆開看才發現層級：語法正確只代表 Python 讀得懂；程式可跑只代表沒有路徑當場拋例外；資料契約正確才代表每個邊界收到的，是它答應接收的東西。前兩張證明極便宜，第三張最貴——而系統的正確性恰好只建立在第三張上。

我怎麼查證或重現

分兩本帳。

直接原因只有一行：行尾逗號把單一值變成了單元素 tuple。

促成因素才是通行證的來源：

• 關鍵函式缺型別註記，錯的型別連被標紅的機會都沒有。
• 重要邊界沒有輸入驗證，來什麼收什麼。
• 函式普遍接受寬鬆的 iterable——正當的彈性，順便掩護了變形的資料。
• Log 只輸出值，不輸出型別與結構（Day 12 的教訓）。
• 測試只驗證「沒有拋出例外」，而這場事故的特徵正是不拋例外。
• 靜態分析沒有涵蓋該路徑，或設定太鬆。
• 變數命名沒有區分單值與集合——result 裝什麼都不奇怪，item_count 裝 tuple 就刺眼了。

系統性缺口再上一層：整個團隊（包括當時的我）預設「過了 lint 與測試就是對的」，卻沒有任何一道檢查真正回答「資料跨越邊界後還符合契約嗎」。這不是誰的失誤，是驗證體系裡缺了一整個類別的檢查。

區分證據等級。已確認事實：直接原因的機制（已驗證）。合理推論：促成因素清單來自對當時開發習慣的複盤。示意內容：命名對比的舉例。

今天留下什麼方法

本篇結論：

局部語法成立，不代表資料跨越下一個邊界後仍符合契約。

下一篇（Day 15）收束故事三：不要為每個逗號立法，替重要的資料邊界建立契約。