jiantw83andClaude Opus 5
f83e1c542f
第十支 hook 上線之後實測發現：claude 與 kiro 的盤點點名得出它，codex、 copilot、antigravity 三段的盤點卻各自只驗自己寫死的那兩支。那三支的接線 盤點看不出第十支在不在，而 smoke 那一行還自稱「十支 hook」——兩句話都是 真的，範圍不同，讀的人分不出來。 根因是「接線寫了哪幾支」與「盤點驗了哪幾支」本來是兩份手寫清單。加一支 hook 要記得回來改第二個地方，而漏改的那一天不會有任何東西叫。 改成從接線那一邊實際會寫出去的內容抽名字，兩邊只留一份清單： - codex 讀的是從 hooks/hooks.json 推導出來的複本，所以名單取自來源那一份， 十支全驗；推導漏掉一支時，盤點說得出漏了哪一支。 - copilot 與 antigravity 只接得上兩道閘門，名單取自各自的條目產生函式。 - copilot 原本一支 hook 都沒點名，只驗「hooks 鍵在」——鍵在而某一支條目掉了 照樣回 present，那正是這一整支腳本一直在防的形態。 codex 接線後的驗證也一起改：原本只確認那兩道閘門有接上，現在逐支對照來源。 推導是整份複製再改 matcher，漏掉任何一支都算推導壞了。 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.9",
|
||
"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"
|
||
}
|
||
}
|
||
}
|