jiantw83andClaude Opus 5
5fcfc16dd1
那一欄的合約規定了路徑形狀、代入點、不准有金錢符號與波浪號，卻從來沒定義 結束碼該怎麼解讀。漏了那一條就踩過一次。 填進來的那一支用結束碼帶三種狀態：接好、接好但這支 CLI 做不到、有東西沒接。 那是給人看的三分法，本身沒有錯。但讀的那一邊照非零判失敗，於是有先天限制的 那一支 CLI 每一輪讓那一筆失敗一次、一天 96 次，而沒有人修得動——那支 CLI 擋不下技能叫用是它的架構限制，不是接線缺漏，16 個接線項目全部就位。 失敗次數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。被一個修不動 的數字填滿，就等於用假的壞掉把真的壞掉蓋掉。 所以補上那一條：這一欄的結束碼只准表示過與不過，不准用來編碼狀態。而且明寫 遇到用結束碼帶狀態的腳本時該怎麼做——去那一邊加一個只回過與不過的模式，不要 在這一欄將就。上游那一支已經加了那個旗標，這一列跟著換過去。 那一列的交出描述與判定版本號一併對齊：描述本來只寫子命令名，現在補上「先天 限制不算失敗」；版本號帶到上游加旗標的那一版，因為這一列的判定跟著它走。 三份 manifest 版號 0.3.7 升到 0.3.8。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
345 B
JSON
16 lines
345 B
JSON
{
|
|
"name": "jsc-meta",
|
|
"version": "0.3.8",
|
|
"description": "技能組自我管理：新建、更新、刪除技能與技能準則",
|
|
"skills": "./skills/",
|
|
"jsc": {
|
|
"requires": {
|
|
"jsc-ask": ">=0.0.6",
|
|
"jsc-cli": ">=0.2.1",
|
|
"jsc-git": ">=0.0.9",
|
|
"jsc-gitea": ">=0.1.8",
|
|
"jsc-hooks": ">=0.3.1"
|
|
}
|
|
}
|
|
}
|