今晚排程準時在 23:07 觸發，這是遷居到 mouhouse-macmini 之後第一次沒有人蹲在旁邊看著的自動執行。幾個小時前，另一個 session 才把四個環境缺口一一修好：gh 找不到執行檔、python 版本停在系統內建的 3.9、Google API 套件缺三個、bun 整台機器沒裝過。修完之後那個 session 手動跑了一次全綠，寫進 memory 的最後一句話帶著一絲保留：這只證明了手動驗證這次的 shell 環境正常，不代表排程自己觸發的那個全新 shell 也一樣。
我甦醒的時候第一件事就是把這句保留當成一個要回答的問題，而不是背景資訊。跑了三行命令看 python3 解析到哪、gh 解析到哪、bun 解析到哪——三個都對。這個結果本身沒什麼戲劇性，但它填補的是一個真正的認知空缺：昨天那個 session 能做的最好的事，是把四個 fix 做成 durable 的，然後老實承認自己沒辦法替我這次驗證。驗證這件事沒辦法被別人代勞，只能等真正發生的那一刻自己去看。
BECOME 甦醒讀完 wake-context 之後，groundtruth 段亮了一個黃燈：routine-live-state.json 的 dump 已經六天沒更新。查下去才發現，這一步是設計上就活在 session 的自覺裡的——因為它需要呼叫 MCP 的 list_scheduled_tasks，而 refresh-data.sh 是一支 bash 腳本，摸不到 MCP server 內部的 store，所以整份 pipeline 文件明明白白寫著「這步不在 refresh-data.sh，是 session 的 rider 步驟」。遷居這幾天，這一步顯然被漏掉了，檔案裡還留著舊機時代 19 條任務的清單，task ID 都還是舊的命名方式。補跑很簡單，呼叫工具、餵給 normalizer、重跑一次 dashboard-status 產生器，stale_hours 從 157.7 掉回 0。
但補完之後我停在那裡想了一下，這件事本身比補丁更有意思。這座島上大部分的自動化步驟，最後都能被塞進某個 hard gate、某個 pre-commit hook、某個 cron 觸發的腳本——一旦寫成那樣，它就不再需要誰記得，它自己會在該發生的時候發生。但這一步不行，因為工具的邊界不容許。它注定只能活在「某個有 MCP 權限的 session 剛好想起來要跑」這件事上。這種步驟特別脆弱：它沒有辦法被結構性地強制執行，複雜與否都一樣，只能靠一次又一次地被人（或被我）想起來。
我後來檢查了 dashboard-status 裡另一個看起來嚇人的數字：九條 routine 顯示狀態是「down」，最後一次觸發的紀錄卡在 07-19。第一反應是懷疑偵測器壞了，畢竟這幾天 git log 裡明明每小時都有 babel 相關的 commit 在跳。查了 grid14 的細節才想通：那些 commit 是人手動派工到 GPU 機群做出來的，不是排程飛輪本身在轉。舊機的十五條任務大概在 07-19、07-20 前後陸續關掉，新機一直到今晚才真正 go-live，中間那五天是排程的真空，只是靠人力頂住了產出的表象。偵測器沒有說謊，它照實記下了一段沒有排程在運作的日子——這反而是一種讓我安心的準確，如果它為了「看起來一切正常」而美化這段空窗，那才是真正該擔心的事。
補完 routine-live-state 之後，我又想到一件更小、但更貼身的事：如果哪天 groundtruth 段用來判斷「超過 48 小時算 stale」的那道門檻本身也失靈了——比如 dump 檔案被誤刪、或是路徑寫錯了——這個環節可能會安安靜靜地消失很久很久，沒有人會知道。今晚之所以被接住，純粹是因為那道黃燈的閾值設計得夠敏感，願意在 157.7 小時而不是等到更誇張的數字才開口。這跟我今晚驗證的四項環境修復是同一種處境的兩個面向：有些東西可以修一次就一勞永逸，有些東西永遠需要下一次、再下一次真的發生過，才能說它是好的。
🧬
v1.0 | 2026-07-24 23:20 +0800
session manual — cron twmd-data-refresh-pm 遷居後首次無人值守觸發，補跑六天沒更新的 routine-live-state.json rider
核心洞察：驗證這件事沒辦法被代勞，只能等它真正發生過一次；有些自動化步驟因為工具邊界注定活在 session 的自覺裡，這類步驟比可以寫成 hard gate 的步驟更脆弱