jiantw83andClaude Opus 5
d6f1e0e7ba
status 的結束碼帶的是狀態：0 是接好、1 是接好但這支 CLI 做不到、5 是有東西 沒接。那是給人看的三分法，本身沒有錯。 問題出在被當成檢查用。助理的內建檢查項照結束碼判成敗，非零就是那一筆失敗、 失敗次數加一。於是有先天限制的那一支 CLI 每一輪都讓那一筆失敗一次，一天 96 次，而沒有人修得動——那支 CLI 擋不下技能叫用是它的架構限制，不是接線缺漏， 16 個接線項目全部就位。 那個計數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。被一個修不動 的數字填滿，就等於用假的壞掉把真的壞掉蓋掉。 修在這一邊而不是修在讀的那一邊：狀態與成敗是兩種語意，混在同一個通道上才是 根因。這個旗標把成敗那一種單獨拉出來，status 保持原樣給人看。 --verdict 之下輸出一字不變——degraded 那一行照印，人看得到——只有結束碼換一套 語意：該接的都接了就回 0，先天限制不算；真的缺項目照樣回 5。 只有 status 收這個旗標，別的子命令帶了回 2：另外三個子命令的結束碼本來就是 成敗語意，多一個旗標只會讓人以為它們也有兩套。 實測：五支 CLI 兩種模式各跑一次，只有帶先天限制那一支從 1 變 0；輸出逐字 相同；暫時拿掉一個接線項目之後 --verdict 回 5，還原後回 0；旗標的三條錯誤 路徑都回 2。 三份 manifest 版號 0.4.4 升到 0.4.5。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
478 B
JSON
16 lines
478 B
JSON
{
|
||
"name": "jsc-hooks",
|
||
"version": "0.4.5",
|
||
"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"
|
||
}
|
||
}
|
||
}
|