jiantw83andClaude Opus 5
c76e8489a6
fix(schedule): 排程條目不再寫死工作階段代號，CLI 判定跟上共用函式
兩個坑，都在同一支腳本，都讓無人值守那一輪看起來正常卻不正常。
一、條目寫死了工作階段代號。那一輪的兩半因此落在不同的值上：start 由 hook
寫，它從 hook 的標準輸入 JSON 讀得到 CLI 真正的代號；end 由工具腳本寫，沒有
那份 JSON，只能讀環境變數，於是讀到寫死的那個字串。配對的判準是工作階段
代號加技能名，兩半的代號不同就永遠配不起來。
這台機器上實測累積了 91 筆假的「只有 start 沒有 end」，其中 90 筆是同一支
每輪都會被叫用的技能。逐個工作階段數下來：92 個是一個 start 零個 end，另有
一個工作階段收著 29 個 end 卻一個 start 都沒有——那一個就是寫死的代號。
代價不只是數字難看。那一節存在的理由正是「只有 start 沒有 end 是一支技能
中止的唯一證據」，而這批假訊號只增不減，遲早把真的中止蓋掉。不設這個變數，
兩半就都落在 CLI 自己給的代號上，實測驗過確實配得起來。
二、CLI 判定抄了一份較窄的。共用函式認三個環境標記，這一份只認第一個，而
工具腳本被叫用時那一個不會設。於是每一次不帶 --cli 的安裝都回用法錯誤——
技能本文的啟動步驟叫的正是不帶 --cli 那一種，這台機器上一定裝不起來。同一個
判斷寫兩份就是這樣漂走的：共用函式後來補了兩個標記，這一份沒跟上，而漂移
的代價是一個看起來像「這台機器沒裝 CLI」的錯誤。
殘留的那 91 筆不必手動清，那一支本來就會把開超過一天的丟掉，一天內收斂。
三份 manifest 版號 0.2.1 升到 0.2.2。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 12:29:20 +08:00
..
2026-09-03 16:37:44 +08:00
2026-09-03 16:37:44 +08:00
2026-09-04 12:29:20 +08:00
2026-09-04 10:16:13 +08:00
2026-09-03 19:05:07 +08:00