jiantw83
8150ca8722
判準原本是「這個工作階段代號我沒見過＝行程是新起的」。那個等式不 成立：還沒重啟的工作階段自己生出來的子行程，拿到的也是沒見過的代 號，於是替人把閘門放下了，而人一次都沒重啟。 這台機器上真的發生過。部署掛上的閘門兩分鐘後就不見了，那段時間有 三個子工作階段冒出來，收尾那句「請重新啟動」於是只剩人自己記得。 排程那條路碰巧沒踩到，因為 cron 條目帶著 JSC_CLI=cron，清的是別 一份——巧合擋下來的，不是判準擋下來的。 反方向也會答錯：續接原代號的 resume，行程確實換過了，舊寫法卻連 問都不會問。 所以 require 一併記下掛上閘門時的工作階段代號與那一支 CLI 的行程 代號，清除只認行程存活：還活著就不清，走了就清。追不到行程代號時 退回結束記號，要求代號換了而且舊階段寫出過 .end。核對命令名不只 看行程還在，因為行程代號會被回收。 判定整段搬到 restart-gate.sh，session-timer.sh 只負責問。冒煙那 一組原本把舊語意寫成斷言，改成逐條驗三條清除路徑，並加一條驗 require 真的把欄位寫下來——少了那個欄位會無聲退回相容路徑，而每 一條行為斷言照樣全綠。
16 lines
478 B
JSON
16 lines
478 B
JSON
{
|
||
"name": "jsc-hooks",
|
||
"version": "0.5.1",
|
||
"description": "跨 CLI hooks：STE100 語言強制、工時計時、技能用量記錄、SDLC 模型鎖、版本前置檢查、註解範圍守門、繁中編碼守門、部署後強制重啟、寫入與提交閘門",
|
||
"skills": "./skills/",
|
||
"jsc": {
|
||
"requires": {
|
||
"jsc-cli": ">=0.2.1",
|
||
"jsc-gitea": ">=0.1.7",
|
||
"jsc-git": ">=0.1.1",
|
||
"jsc-meta": ">=0.2.3",
|
||
"jsc-review": ">=0.0.8"
|
||
}
|
||
}
|
||
}
|