釋出：排程條目不再寫死工作階段代號，CLI 判定跟上共用函式 #25

2026-09-04T04:32:28Z

jiantw83 commented

2026-09-04 04:32:28 +00:00

摘要

需求描述：把 develop 累積的變更釋出到 master。deploy.sh clone 的是預設分支，沒進 master 的東西這台機器一輪都用不到。這一批修掉排程條目上的兩個坑，兩個都讓無人值守那一輪看起來正常卻不正常。
計畫名稱：無
計畫頁：無
分析頁：無

這一批的內容

一、條目不再寫死工作階段代號。 那一輪的兩半由不同的東西寫：start 由 hook 寫，它從 hook 的標準輸入 JSON 讀得到 CLI 真正的代號；end 由工具腳本寫，沒有那份 JSON，只能讀環境變數。條目寫死了那個變數，於是兩半落在不同的值上，而配對的判準正是那個代號加技能名——永遠配不起來。

二、CLI 判定跟上共用函式。 共用函式認三個環境標記，這一支自己抄了一份、只認第一個，而那一個在工具腳本被叫用時不會設。技能本文的啟動步驟叫的正是不帶 --cli 那一種，所以這台機器上每一次啟動都停在用法錯誤，訊息還看起來像「這台機器沒裝 CLI」。

版號 0.2.1 到 0.2.2。

第一個坑的實際規模

真機第一輪巡檢報出「有 91 支技能只有 start 沒有 end，那幾輪中止了」。逐個工作階段數下來：

start 數	end 數	有幾個工作階段
1	0	92
2	0	1
0	29	1

最後那一列就是寫死的代號——29 筆收尾全掛在一個從來沒開始過的工作階段底下。91 筆全是假的。

代價不只是數字難看。 那一節存在的理由正是「只有 start 沒有 end 是一支技能中止的唯一證據」，而這批假訊號只增不減，遲早把真的中止蓋掉。

第二個坑是漂移

同一個判斷寫兩份，共用函式後來補了兩個標記，這一份沒跟上。註解裡寫明了這件事，也寫明共用函式加新標記時這裡要一起加。

測試結果

拿掉寫死的代號之後真的配得起來：用隔離的根目錄各寫一筆收尾事件，帶那個變數記到的是寫死的字串，不帶就記到這個工作階段真正的代號。
不帶 --cli 的安裝乾跑回結束碼 0，判出來是 claude；改動前同樣的呼叫回 6。
乾跑印出來的條目裡，寫死的那個變數一處都不剩，其餘十個環境變數的快照原樣保留。
三支檢核腳本都回結束碼 0。
全程沒有動到正式的排程，用的是乾跑。

殘留不必手動清

那一支本來就會把開超過一天沒配對到的 start 丟掉，所以修好之後一天內自己收斂。

這兩個坑是怎麼被發現的

真機跑第一輪巡檢，它照設計把發現列進了待人處理。巡檢本身沒有壞——壞的是它讀的那批資料，而它老老實實把數字報出來，才讓人查得下去。

前置 Push Request

無

## 摘要 - 需求描述：把 develop 累積的變更釋出到 master。`deploy.sh` clone 的是預設分支，沒進 master 的東西這台機器一輪都用不到。這一批修掉排程條目上的兩個坑，兩個都讓無人值守那一輪看起來正常卻不正常。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 這一批的內容 **一、條目不再寫死工作階段代號。** 那一輪的兩半由不同的東西寫：`start` 由 hook 寫，它從 hook 的標準輸入 JSON 讀得到 CLI 真正的代號；`end` 由工具腳本寫，沒有那份 JSON，只能讀環境變數。條目寫死了那個變數，於是兩半落在不同的值上，而配對的判準正是那個代號加技能名——**永遠配不起來**。 **二、CLI 判定跟上共用函式。** 共用函式認三個環境標記，這一支自己抄了一份、只認第一個，而那一個在工具腳本被叫用時不會設。技能本文的啟動步驟叫的正是不帶 `--cli` 那一種，所以這台機器上每一次啟動都停在用法錯誤，訊息還看起來像「這台機器沒裝 CLI」。版號 0.2.1 到 0.2.2。 ## 第一個坑的實際規模真機第一輪巡檢報出「有 91 支技能只有 start 沒有 end，那幾輪中止了」。逐個工作階段數下來： | start 數 | end 數 | 有幾個工作階段 | | --- | --- | --- | | 1 | 0 | 92 | | 2 | 0 | 1 | | 0 | 29 | 1 | 最後那一列就是寫死的代號——29 筆收尾全掛在一個從來沒開始過的工作階段底下。91 筆全是假的。 **代價不只是數字難看。** 那一節存在的理由正是「只有 start 沒有 end 是一支技能中止的唯一證據」，而這批假訊號只增不減，遲早把真的中止蓋掉。 ## 第二個坑是漂移同一個判斷寫兩份，共用函式後來補了兩個標記，這一份沒跟上。註解裡寫明了這件事，也寫明共用函式加新標記時這裡要一起加。 ## 測試結果 - 拿掉寫死的代號之後真的配得起來：用隔離的根目錄各寫一筆收尾事件，帶那個變數記到的是寫死的字串，不帶就記到這個工作階段真正的代號。 - 不帶 `--cli` 的安裝乾跑回結束碼 0，判出來是 `claude`；改動前同樣的呼叫回 6。 - 乾跑印出來的條目裡，寫死的那個變數一處都不剩，其餘十個環境變數的快照原樣保留。 - 三支檢核腳本都回結束碼 0。 - 全程沒有動到正式的排程，用的是乾跑。 ## 殘留不必手動清那一支本來就會把開超過一天沒配對到的 `start` 丟掉，所以修好之後一天內自己收斂。 ## 這兩個坑是怎麼被發現的真機跑第一輪巡檢，它照設計把發現列進了待人處理。巡檢本身沒有壞——壞的是它讀的那批資料，而它老老實實把數字報出來，才讓人查得下去。 ## 前置 Push Request - 無

jiantw83 added 2 commits 2026-09-04 04:32:29 +00:00

fix(schedule): 排程條目不再寫死工作階段代號，CLI 判定跟上共用函式 c76e8489a6

兩個坑，都在同一支腳本，都讓無人值守那一輪看起來正常卻不正常。

一、條目寫死了工作階段代號。那一輪的兩半因此落在不同的值上：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>

Merge pull request '排程條目不再寫死工作階段代號，CLI 判定跟上共用函式' (#24 ) from fix/schedule-entry-drops-fixed-session-id into develop cd83b1b62a

Reviewed-on: #24

admin approved these changes 2026-09-04 04:35:10 +00:00

admin merged commit 2cccafd3a9 into master

2026-09-04 04:35:13 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: plugins/assist#25