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

2026-09-04T04:29:56Z

jiantw83 commented

2026-09-04 04:29:56 +00:00

摘要

需求描述：真機第一輪巡檢報出「有 91 支技能只有 start 沒有 end，那幾輪中止了」。查下去那 91 筆全是假的，根因是排程條目寫死了工作階段代號。同一支腳本上還有第二個坑：CLI 判定抄了一份較窄的，導致技能本文的啟動步驟在這台機器上一定裝不起來。
計畫名稱：無
計畫頁：無
分析頁：無

變更內容

檔案	為什麼改
`tools/schedule.sh`	三處拿掉寫死的工作階段代號；CLI 判定補上共用函式的另外兩個環境標記；兩處都補上為什麼的註解
`references/behaviors.md`	條目那一段記下「刻意不寫死工作階段代號」與理由
三份 manifest	版號 0.2.1 升到 0.2.2

一、91 筆假中止

配對的判準是工作階段代號加技能名。那一輪的兩半由不同的東西寫：

哪一半	誰寫的	代號從哪來
`start`	hook	hook 的標準輸入 JSON，是 CLI 真正的代號
`end`	工具腳本	沒有那份 JSON，只讀得到環境變數

條目裡寫死了那個環境變數，所以每一輪的 end 都掛在同一個固定字串底下，而 start 掛在每輪不同的 UUID 底下。兩半永遠配不起來。

逐個工作階段數下來，證據很直接：

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

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

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

二、不帶 --cli 一定裝不起來

共用函式認三個環境標記才判定是哪一支 CLI，這一支自己抄了一份、只認第一個。而那一個標記在工具腳本被叫用時不會設。

技能本文的啟動步驟叫的正是不帶 --cli 那一種，所以這台機器上每一次啟動都停在用法錯誤。錯誤訊息還很誤導——它說「判不出要用哪一支 CLI」，看起來像這台機器沒裝 CLI。

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

測試結果

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

殘留的那 91 筆不必手動清

那一支本來就會把開超過一天的 start 丟掉，理由寫在它自己的註解裡：留著只會讓那個檔案無止境長大，而那麼久沒收尾的早就報過了。所以修好之後一天內自己收斂。

這兩個坑是怎麼被發現的

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

前置 Push Request

無

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

jiantw83 added 1 commit 2026-09-04 04:29:57 +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>

admin merged commit cd83b1b62a into develop

2026-09-04 04:31:40 +00:00

admin deleted branch fix/schedule-entry-drops-fixed-session-id

2026-09-04 04:31:40 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: plugins/assist#24