Cron 的可觀測性：排程不該是黑箱

排程任務最陰險的故障模式是安靜地不跑。cron 表達式打錯、程序重啟後沒掛回去、上一輪卡死——沒有人會收到通知，直到某天發現三週的清理任務一次都沒執行。所以平台把「排程」與「可觀測」設計成一體。

慣例：@Cron 只准當扳機

@Cron 裝飾器一律放在 presentation 層的 scheduler 檔案裡，而且薄到只做三件事：觸發、try/catch 記錄成敗（帶耗時）、登記手動觸發入口。真正的工作在 application service——scheduler 是 HTTP controller 的孿生兄弟，只是觸發源從請求換成時鐘。

這個分離的直接紅利：每個排程都能從後台手動觸發。「等到凌晨三點看它跑不跑」是很糟的除錯迴圈，一顆按鈕現在就跑一次，才是。

觀測資料放哪裡：一個聰明的偷懶

每輪的執行結果（最後執行時間、耗時、錯誤）寫進平台的快取抽象。這個選擇的妙處：快取的一致性語意跟著 CACHE_DRIVER 走——單機開發時是記憶體、多 pod 部署換 redis，排程觀測的跨實例一致性自動跟上，一行都不用另外寫。

下一次執行時間、cron 來源、runtime 動態改排程，則直接問 scheduler registry——框架已經持有的狀態不要自己再存一份。後台一頁把「註冊了什麼、上次跑得如何、下次何時跑」合併展示，排程從黑箱變成儀表板。

執行結果也是稽核的一部分

失敗的那輪會記進失敗歷史；重要排程失敗可以接事件出口寄信告警。「排程有跑、跑成功了」這件事有據可查之後，那種「好像有東西沒在動？」的不安感就消失了——可觀測性買的其實是心理健康。