jiantw83 8150ca8722 fix(restart-gate): 閘門改問行程還在不在，不問代號見過沒有 ...

判準原本是「這個工作階段代號我沒見過＝行程是新起的」。那個等式不
成立：還沒重啟的工作階段自己生出來的子行程，拿到的也是沒見過的代
號，於是替人把閘門放下了，而人一次都沒重啟。

這台機器上真的發生過。部署掛上的閘門兩分鐘後就不見了，那段時間有
三個子工作階段冒出來，收尾那句「請重新啟動」於是只剩人自己記得。
排程那條路碰巧沒踩到，因為 cron 條目帶著 JSC_CLI=cron，清的是別
一份——巧合擋下來的，不是判準擋下來的。

反方向也會答錯：續接原代號的 resume，行程確實換過了，舊寫法卻連
問都不會問。

所以 require 一併記下掛上閘門時的工作階段代號與那一支 CLI 的行程
代號，清除只認行程存活：還活著就不清，走了就清。追不到行程代號時
退回結束記號，要求代號換了而且舊階段寫出過 .end。核對命令名不只
看行程還在，因為行程代號會被回收。

判定整段搬到 restart-gate.sh，session-timer.sh 只負責問。冒煙那
一組原本把舊語意寫成斷言，改成逐條驗三條清除路徑，並加一條驗
require 真的把欄位寫下來——少了那個欄位會無聲退回相容路徑，而每
一條行為斷言照樣全綠。

2026-09-07 14:25:08 +08:00

..

jsc-wrap.sh

feat(wire-cli): 把 lang-guard.sh 接到五個 CLI 的既有時機

2026-08-27 09:50:03 +08:00

report-error.sh

feat(異常目錄頁): 索引改成 H2 區塊條列並委派共用工具

2026-09-02 18:01:33 +08:00

report-status.sh

feat(狀態回報): 技能與 hook 的執行結果寫進本機事件流

2026-09-02 15:40:17 +08:00

scan-hook-errors.sh

feat(hooks): 工作階段開始時把助理的未讀提醒帶到前景

2026-09-07 11:14:41 +08:00

scan-logs.sh

docs(hooks): 每支腳本檔頭補上結束碼宣告，文件對齊九支 hook 的現況

2026-08-31 11:17:28 +08:00

wire-cli.sh

fix(restart-gate): 閘門改問行程還在不在，不問代號見過沒有

2026-09-07 14:25:08 +08:00