Files
meta/references
jiantw83 beede79d3a docs(guidelines): 改寫 hook 準則裡五支 CLI 的接線事實
What:
- 改寫「Hook 規則」第 3 條,寫明五支 CLI 的 hook 負載形態各不相同,沒有哪一支是基準格式。
- 新增「技能名解析與阻擋輸出的共用腳本」節,列出 skill-name.sh 與 deny.sh 的用法、各 CLI 的技能名取值來源、抽成共用腳本的理由。
- 改寫「版本前置檢查」,補上五支 CLI 的接線位置表、逐支陷阱表、未實測部分的標明規則。
- 改寫「部署後重啟閘門」,指名 restart-gate.sh,並寫明接線位置與版本前置檢查完全相同。
- 審核檢查清單新增一項:該 domain 的 lint-frontmatter.sh 要退出 0,退出 3 不算通過。

Why:
- 這一節以前寫著「只有 claude 接得上,其餘四支沒有 pre-tool hook」。那是錯的。四支全都有能阻擋的 pre-tool 事件,是我們接錯位置。
- 四個無聲失效逐一坐實了這件事:codex 的 matcher 用 Skill,但 Codex 沒有 Skill 工具,技能是模型用 Bash 讀 SKILL.md;codex 的 hooks 鍵寫成內嵌物件,實際規格是路徑字串;antigravity 的 PreToolUse 寫成 Flat,實際要 matcher 加 hooks 包一層的 Grouped;三支新接的命令沒帶 JSC_CLI={代號},閘門認不出自己跑在哪支 CLI 上,一次都擋不下來。
- 錯誤的結論被寫進準則之後就沒有人再去查。版本前置檢查與部署後重啟閘門因此在四支 CLI 上長期失效,而且失效是安靜的:hook 沒被觸發不會報錯,看起來就跟「沒有東西該擋」一樣。

How:
- 接線位置表每一列都經過執行檔抽出或本機實測,事件名、matcher、寫入檔案、阻擋方式逐欄寫死。
- verdict 據實分級:claude、codex、copilot、antigravity 寫 wired;kiro 的技能叫用走 ResolveSkill 內部請求、不走工具管線,攔不到,寫 degraded,不寫 failed。
- antigravity 與 kiro 的觸發沒有實跑驗證,另段標明,回報時不得混進已驗證的結論。
- 兩道閘門共用同一套接線,就共用同一份事實表。重啟閘門那節只指回接線位置表,不另寫一份能力描述,避免改一份、漏一份。

Who:
屬 CLI hook 接線修正(jsc-hooks 0.3.4)在 meta 這一側的規範文件。
2026-08-31 19:13:03 +08:00
..