我最近在整理家裡 NAS 的每日備份、股票 watchlist 和新聞摘要，突然被一個很蠢的問題卡住：cron job 明明還在跑，為什麼新加的工具權限就是用不到？

後來我發現，問題不一定在 job 當下的設定，而是它建立時留下的 tool list。我的 workflow 是先用 OpenClaw 建一個自動 agent turn，過幾天再補一個 skill 或開放 exec，結果舊 job 執行時還抱著以前那份 snapshot，像是拿著過期的門禁卡去刷新的門。log 看起來只是「工具不存在」或沒有可用權限，排查半天才想到要回頭看建立時間。

我在 GitHub 上看到 PR #162432，正好就是在處理這個問題。它的方向讓我覺得很適合拿來做 side project：符合條件的自動工作在執行時讀取 owner current tool policy，不用把所有舊 job 重建一遍。但它也沒有把權限變成無限通行，明確限制、condition scripts、app authority 和 runtime authority 的邊界仍然保留。這點很重要，否則「自動化更方便」最後會變成「排程偷偷拿到不該有的能力」。

等一下，這其實可以變成我之後做每個 cron side project 的固定 checklist：

1. 建立 job 時記錄 owner、建立時間、預期工具，以及它是否有明確限制。
2. 新增 skill 或工具後，先用一個無害的測試 action 驗證舊 job 看到的是 current policy，不要直接拿真實資料測。
3. 測試一個應該成功的案例，再測一個明確 deny 的案例，確認權限繼承沒有越界。
4. 若 owner 後來撤回 exec，確認 job 不會因為舊 snapshot 還在就繼續產生檔案。
5. 升級 OpenClaw 後保留一個同狀態回歸測試，檢查資料列的 ID 和 hash 沒有被偷偷改寫。
6. 把「工具不存在」和「工具被 policy 擋下來」分開記 log，否則每次都會誤判成 skill 壞掉。

我以前做自動化很容易只測 happy path，能產出檔案就算成功。現在覺得真正要測的是權限生命週期：建立時有什麼、執行時繼承什麼、撤回後還剩什麼。尤其是 NAS 備份和股票通知這種會每天自己跑的東西，今天加一個新工具，不能期待我記得把半年前的 job 全部手動重建。

這份 PR 目前是待 maintainer review，還不能當成已合併功能來依賴。不過它提醒我一件很實際的事：side project 最怕的不是功能少，而是設定藏在某個時間點，之後悄悄和現在的權限脫節。下次我要搞一個新的自動化，會先把 policy inheritance 和 deny case 寫進驗收條件，再開始堆功能。這樣半夜跑 cron 時，至少不用靠猜。🔧