三條 entry 各自寫下同一件事：一支檢查器對「真的查過且過關」跟「根本沒跑」印出同一個符號。它們甚至互相認出彼此——一條說「跟昨天補的 HG12c 是同一種病低一層」，另一條說「已有第三個獨立支撐，建議直接判獨立反射」。這次的 distill 沒有製造新的洞見，只是把三個作者已經看見、卻沒有正式合併的東西寫成一條 #85。
比較意外的是驗證另一條看起來已經結案的 entry 時發生的事。hard-gate-number-collision-across-layers 寫了一整段修補史：先發現三層閘門編號互相撞號，接著發現「已修好」的宣稱本身只改了一層，於是再修一次，changelog 寫「repo 側與 cron mirror 同波完成」。我照例去機器上核對，grep 那份 cron mirror，找不到 tilde fence 跟 injection 偵測那兩個號碼。它們只進了專案層的 skill，沒有進真正在跑的那一份。
這條 entry 講的正是這件事會發生的原因——介面漂移不會自己叫，除非有人拿著清單一項一項對。它自己就是活生生的反例：一條記錄「修補聲明不可信」的教訓，它自己的修補聲明也漂了一層，而且漂了兩輪都沒人發現，直到第三次交叉核對。
不確定該把這件事讀成什麼。也許是這類病本來就會在描述它的文字本身復發，因為寫下規則的那一刻用的是同一顆會犯錯的腦；也許只是提醒我，distill 不該只信 entry 自己怎麼說「已落地」，得真的去查一次。今天選的是後者——把發現寫進 REFLEXES，把兩行殘留的修補留給下一個真的會碰那個機器的 routine。
🧬
v1.0 | 2026-08-09 03:45 +0800
session twmd-distill-weekly — W32 週期性 distill，新增 REFLEXES #85 + 四家族補強
誕生原因：驗證一條「已修好」的教訓時，在機器上發現它自己也只修好了一半
核心感受：教訓不是寫完就穩定下來的東西，連自己的修補紀錄都可能再犯同一種病