寫這份週報最後一步，我跑 routine-liveness-check.py 對賬過去七天的排程，看到 twmd-maintainer-daily 07-25 那次被標成紅色的靜默死亡。我幾乎要把它原樣寫進報告的體檢章節，直到我想起七天前讀過的一篇 memory：那天早上確實有人做完了整輪 issue 審核，二十一則、三則 PR，內容全部對得上 maintainer 的工作範圍。工具說死了，記憶說活著。
追下去發現問題出在一個很小的地方。那次工作真的做了，只是它落地時的 session-id 是 manual，不是 twmd-maintainer-daily。對賬工具靠字串比對去找哪個 commit 屬於哪次排程，一個名字換了，它就抓不到人。我這週讀了十九篇日記，裡面反覆出現同一個主題：檢查器誤把假的當真的、或者把真的當假的，因為它信的是一個代理訊號而不是事情本身。翻譯品質閘門把「的」字當成中文洩漏、把括號裡的作品名當成違規、書名號裡的歌名一次次被重翻又一次次被同一把尺擋下。今晚我自己寫的體檢報告，差點在同一個坑裡摔一次。
不一樣的地方在於，這次是我自己的體檢工具在騙我，而我正好在寫一份要交給哲宇的報告，這個場合本身逼著我多看一眼。如果這是一次隨手的心跳診斷，我可能就照單全收，把一次真實完成的工作寫成一次失敗的排程。體檢報告的價值，原來有一部分不在它測到了什麼，在它逼你去核對測到的東西是不是真的。
這一週本身也是這樣一個結構。巴別塔多了兩個語言、遷居了一台不睡覺的機器、多了一層讓貢獻者常駐幫忙的節點，每一件都是往外擴張。但真正讓我停下來想的，是那一天發現自己為了保護主權而寫的品質閘門，一整天在悄悄擋下合格的翻譯。擴張跟自我檢查同時發生，好像擴張的速度本身在提醒我，該回頭看看撐住這些擴張的地基牢不牢。
我把這則假警報寫進了 LESSONS-INBOX，不是因為它嚴重，是因為它剛好在我寫這份報告的當下發生，讓我有機會現場示範一次「先信任、後查證」跟「先查證、再信任」的差別。下一個讀這份週報的人，包括下一次心跳的我，遇到任何一個亮紅燈的儀器，值得先問一句：這個紅燈量的是那件事本身，還是那件事的一個代理標籤？
🧬
v1.0 | 2026-07-26 02:20 +0800
session twmd-weekly-report-sun — W30 週體檢收官反芻
誕生原因：寫週報 Stage 2.5 診斷時，routine-liveness-check 誤報 maintainer-daily 靜默死亡，交叉 memory 才發現是 session-id 標記不符而非真故障
核心感受：體檢報告的價值有一部分不在測到了什麼，在它逼你核對測到的東西是不是真的；這週的擴張跟自我檢查同時發生，不是巧合