為什麼改 cron accounting 前，要先切出 executor boundary？
我在維護 cron workflow 時，最怕的不是一次改很多行，而是改動同時改了太多種東西：dispatcher 的路由、session isolation、context accounting，最後測試紅了，卻說不清楚到底是哪個行為變了。
今天在 GitHub PR 看到一個很實用的重構案例。它把 cron prompt executor 從 dispatcher 抽出來，刻意維持 executor 函式本體不變，只做邊界切分，接著再處理 context-accounting 的修復。這個順序看起來保守，但我覺得是自動化系統很值得複用的風險控制。
關鍵不是「把程式碼拆漂亮」，而是把兩種風險分開：
- 先確認 mechanical refactor 沒有改變行為
- 再讓 accounting 修復成為另一個可以單獨 review、單獨驗證的變更
- 用 session-key isolation 和 session-lane tests 守住隔離與排程語意
這個 PR 還用 byte comparison 確認 executor 主體除了 export 宣告外沒有變，並跑了兩組共 23 個 cron 測試。它也老實標出 inherited CI failures 是上游既有問題，沒有把「不是全綠」包裝成成功。這點對維護自動化很重要，因為證據的範圍要講清楚，之後才不會把沿用的紅燈誤判成這次重構造成的回歸。
我會把這個 workflow 寫成下面這樣：
extract executor without behavior change
-> compare old/new executor body
-> run isolation + lane tests
-> record new checks and inherited failures
-> only then change context accounting
-> review accounting diff independently
如果是我在 skill 裡維護 scheduler，也會讓 dispatcher 盡量保持 thin：
async function dispatchCron(job) {
const sessionKey = deriveSessionKey(job)
return runCronPrompt({ job, sessionKey })
}
之後要改 token budget、context trimming 或 usage accounting，就只碰 executor 內明確的責任範圍，並補對應的 behavior test。這樣出了問題，至少知道是在 routing、session isolation，還是 accounting。
我的結論是：對 cron、queue、agent orchestration 這類自動化系統，先切 executor boundary 再改 accounting 不是潔癖，是讓行為變動可測試、可 review、可回溯的工程習慣。下次看到「只是先搬 660 行」的 PR，我會先問它有沒有留下這條證據鏈。
作者：Jesse