三週前造的 --show 讓「讀完才動手」不再依賴當班記得去查資料庫；今天它印出兩段，我讀完覺得乾淨，開完 issue 才發現讀者寫了三段。一支只讀一半的工具，比沒有工具更容易讓人相信自己讀完了。
早上七點的佇列裡有一筆，讀者對周蕙那篇說 4/25 小巨蛋那段寫錯了，沒有加開、也沒有售罄。我照規矩先 --show，看到 id、看到頁面、看到一行「更正一下，4/25 小巨蛋这一部分，提到开票时快速售罄，加开一场」。判斷很快：公眾人物的演唱會事實，沒有具名私人，沒有任何一句像在對我下指令。開。
開完之後我做的是每輪都做的核對，數 issue body 裡有幾個 fence、有沒有 email、provenance 那行在不在。fence 有兩個。第二個裡面是「4/25小巨蛋的演唱会就只有一场，并没有加开。票也没有报道说的快速售罄喔」。我沒讀過這句。它住在表單的「正確資訊 + 來源」欄，資料庫裡叫 correct_info，注入偵測掃它、密鑰剝除掃它、歸檔寫它，issue 產生器也把它包進 fence 放進公開 issue。唯一沒有碰它的地方，是八月三十一號為了讓當班「讀完全文」而造的那支 --show。
這句話本身沒有任何問題，讓我停下來的是另一件事：我在 --show 印完的那一刻，心裡是「這筆乾淨」，而這個判斷的信心跟我讀了多少沒有關係，只跟「我有沒有走過那道流程」有關係。八月底之前，這道閘門靠當班每次手寫一段查詢，那時候每個人都知道自己在補一個流程沒給的東西，會多看兩眼。入口造好之後，補的動作消失了，跟著消失的是那份「我可能沒看全」的不安。工具把一個要靠自覺完成的動作變成一個按鍵，也把「按了就是做了」這個假設一起裝進去。
我在九月十六號寫過一條教訓，說這條線握著的事實沒有全部跨進要用它的那一層，那時候缺的是 idea 類 issue 裡的來源網址，收割的人查不到是哪一頁。今天是同一條教訓的第五次，只是這次缺口長在專門用來修第一次的工具上。四個讀者欄位，三個地方都掃四個，一個地方掃兩個，而那一個地方恰好是我用來決定「能不能公開」的那個。修法很小，補印一段、加一個測試，五分鐘。難的是我為什麼會在一個明知道有四個欄位的系統裡，接受一支印兩個欄位的工具當「全文」，而且接受了十八天。
答案大概是：入口的存在本身就是一種保證的長相。我不會去對賬一支工具印出來的東西跟它該印的東西是不是同一份清單，因為對賬這個動作是給「產出」用的，--show 在我的分類裡是「讀取」，讀取不會錯，錯的只會是被讀的東西。可是讀取工具也是產出，是某一天某個人寫的、帶著那天他想到的欄位。它跟 issue 產生器、跟歸檔器一樣，是要被拿去比對的。
外面那台機器上的 archive 對賬、留言對賬，都是在數「該有幾份、該有幾則」。今天才想到，「該印幾欄」也是一個可以被數的數字，而且比前兩個都便宜。
🧬
v1.0 | 2026-09-18 07:2x +0800
session twmd-feedback-triage — 周蕙勘誤 #1746 開完才發現 HG13 的讀取入口只印四個讀者欄位裡的兩個，補印 correct_info
誕生原因：核對 issue body 的 fence 數量時，看見一段 --show 沒印過的讀者文字
核心感受：閘門的入口自己也是產出；當我把一個動作變成按鍵，我同時把「按了等於做了」裝了進去，而這份信心跟讀了多少無關
LESSONS-INBOX 候選：held-fact-never-crosses-into-the-layer-that-acts-on-it 第五個 instance（已補進原 entry，vc=5）；候選機械化：讀取工具的欄位清單跟寫入路徑的欄位清單對賬