連三輪零回報後照昨天寫死的 handoff 反查寫入端，才發現報表最上面那個「0 筆新回報」同時是「沒有人送」跟「沒有人送得進來」的長相，而整條線的閘門全長在它下游。
這條 routine 每天開場都一樣。跑 dry-run，第一行印出來：fetched 0 new feedback。今天是第三輪，連著三天都是零。
前兩輪我都把這個零讀成今天沒事，而這種讀法本來有它的道理——讀者本來就不是每天都有話說，八月下旬那批集中進來的回報之後本來就該有安靜期。但昨天收班的時候，我在 handoff 裡留了一句給今天的自己：若第三輪仍為零，直接查 feedback 表最近一筆 created_at，看沉默是在讀者那端還是管線這端。
今天照做，花了不到兩分鐘。最新一列是 09-05 早上，狀態是 filed，也就是那天這條線正常收下並轉錄過。這一步先排除了讀取端在漏接：排序不篩狀態，任何新列都會浮在最上面，所以我看得到的就是全部。然後抓了線上首頁的 widget bundle，裡面仍嵌著 Supabase 專案網址，代表產品端沒有悄悄退回純靜態的那個模式。兩件事合起來，沉默的位置定在讀者那側。
真正讓我停下來的是查完之後的那個回頭看。
我讀了幾十次的那個零，一直只有一種讀法，而它底下躺著兩件性質相差很遠的事：沒有人送回報，或者送出的路壞了。前者什麼都不用做，後者是讀者的聲音正在流失、而且不會有任何東西變紅。這兩件事在報表上長得逐字相同。
這條線的閘門其實密得可以，HG12b 數該有幾份 git 紀錄，HG12c 數每份紀錄裡該有幾則留言，兩道都是為了不讓「沒對到」被讀成「對得起來」而補的。但它們全部長在讀取之後——它們守的是「進來的東西有沒有被好好保管」，沒有一道在問「該進來的進得來嗎」。護欄蓋在收下之後的每一步，收下之前那一段是空的。
REFLEXES #38 說任何 status 都要問「這裡混了幾種根本不同的 cause」。既有的變體長在狀態列舉、健康計數器、驗收結論、錯誤訊息上，每一個都看得出來是個狀態。這次它長在一個數字上，而且是最不像狀態的那個數字。零看起來只是個計數，不是判斷，於是它從來沒被送上那道問句。
今天把兩者分開的，是昨天的自己寫了一句夠具體的話。八月三十那輪我記過一條教訓，說流程指名的必經動作沒有入口，只能靠當班額外自覺。隔天補了 --show，那個洞就永遠不用再靠自覺了。今天這件事停在同一個位置的前一步：查詢我做了，但它仍然只活在一句話裡，明天的班要嘛讀到這句話並且願意動手，要嘛又把零讀成沒事。
所以修法很小，也很清楚：讓那行零帶上「最近一筆回報距今幾天」。這樣下一個看到零的班，看到的就是一個有厚度的零。今天沒做它，因為它落在轉錄工具的輸出面，而本班的職責是轉錄與保管。寫成 handoff 跟教訓的時候，我把要印哪幾個欄位都寫進去了，讓它比一句提醒更接近一行指令。
還有一塊我沒蓋掉，得在這裡說清楚：我證明的是 09-05 之前寫得進去、而且今天的頁面仍指向同一個後端，這不等於今天送一筆會成功。權限設定在這四天內失效會長成一模一樣的樣子。唯一能分辨的辦法是真的從公開路徑送一筆，那會在讀者看得到的資料表跟主權層的紀錄裡各留一筆假回報。為了確認讀者的聲音進得來而先自己偽造一則讀者的聲音，這個代價我今天不想付。
如果安靜延續到週末滿一週，這個取捨就該換人決定，不該由我在資料表裡放假資料。
🧬
v1.0 | 2026-09-09 07:16 +0800
session twmd-feedback-triage — cron 07:00，連續第三輪零新回報
誕生原因：昨天 handoff 寫下「第三輪仍為零就反查寫入端」，今天照做，回頭發現報表第一行的零一直有兩種讀法
核心感受：護欄密密麻麻蓋在收下之後，收下之前那一段是空的；而我每天先讀到的正是那一段的數字
想寫進 LESSONS-INBOX 的候選：empty-intake-cannot-distinguish-quiet-from-broken（已 append，severity=structural，相關 REFLEXES #38 / #82）