釋出 jsc-meta 0.2.5：新增 frontmatter 檢查，改寫 hook 接線準則 #52
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: plugins/meta#52
Reference in New Issue
Block a user
摘要
變更內容
tools/lint-frontmatter.shreferences/guidelines.mdskills/skill-check/SKILL.mdlint-frontmatter.sh併進第一組稽核，明寫退出 3 不算通過references/behaviors.md、README這一批抓到的六個缺陷
六個全部不會報錯——設定寫得看起來正確，CLI 靜默不理，日誌、結束碼與
status都沒有痕跡。Skill，但 Codex 沒有Skill工具hooks鍵寫成內嵌物件，實際是路徑字串PreToolUse寫成 Flat，實際要 Groupedactions鍵都不生成JSC_CLI={代號}status全綠，閘門一次都不擋第 4 個最險：前三個修完之後一切看起來都對，閘門仍然完全不會作用。
設計重點
lint-frontmatter.sh的退出 3 明寫不算通過：那是「什麼都沒掃」，不是「掃過沒問題」。方法論
照文件寫不夠，要去問 CLI 自己讀到什麼。這次用到的唯讀管道：
agy -p "/hooks"（不吃 quota）、kiro-cli agent validate、codex 的[hooks.state]登記內容。copilot 沒有這種管道，所以它的形狀維持未證。測試結果
check-behaviors.sh、lint-frontmatter.sh、ste100-lint.sh對 10 個 domain 全部退出 0。lint-scripts.sh9 個退出 0，ask退出 3（沒有腳本可掃）。wire-cli.sh smoke codex退出 0，lines由腳本自印，接線形狀 26 條斷言、每條正向配一條反向。JSC_CLI、用改前版本重組假樹，每一種都抓得到並回非零。驗證等級
agentSpawn、userPromptSubmit實跑觸發kiro 的 verdict 是
degraded，理由是 CLI 限制不是接線問題：技能走ResolveSkill這個 agent 內部請求，preToolUse攔不到技能叫用，userPromptSubmit的非零結束碼也擋不下那一輪。尚未做的事
write-guard.sh三種模式與 SDLC 模型鎖在四支非 claude CLI 上尚未接線。那是還沒做，不是驗不過。resources兩層 glob 能不能修好技能可見性未驗證。kiro 目前預設資源 glob 只掃一層，34 支技能一支都載不到。前置 Push Request
What： - 新增 tools/lint-frontmatter.sh，掃一個 domain 每支 skills/*/SKILL.md 的 frontmatter，檢查分隔線成對、必要鍵齊全、未加引號的純量不含「冒號加空白」、起頭字元不是 YAML 特殊字元、加了引號的值收得起來，共五項。 - 改寫 skills/skill-check/SKILL.md 的第一組稽核，把這支腳本併進去成為第 2 步，原本的行為清單檢查、結束碼路由檢查、hook smoke 依序後移。 - 第二組留白的檢查清單項目由四項改成五項，第 3 步的合併說明、三組的完成條件、第 6 步的重驗完成條件同步改寫。 Why： - 抓到 6 支技能的 description 是未加引號的 YAML 純量、內容含「冒號加空白」。那在 YAML 是鍵的分隔符號，整份 frontmatter 當場語法錯誤。 - Antigravity 讀到語法錯誤就靜默丟棄整支技能。磁碟上 34 支，它只認 28 支。載入器不報、CLI 不報，技能清單只是少了幾列。 - 這種缺陷唯一的發現途徑是逐檔比對磁碟數量與載入數量。人工比對 10 個 domain 每次稽核都要重做一遍，還會漏。輸入輸出固定的判定就交給程式。 How： - 腳本用 awk 自己判定 YAML 1.2 的 plain scalar 規則，不相依 pyyaml。護欄不綁在一個不保證存在的相依上，才跑得到每一台機器。 - 單引號的跳脫是重複一次、雙引號的跳脫是反斜線，兩套規則不同，所以引號改用逐字掃描，不用正規表示式一次比對兩種。 - 結束碼分四種：0 是掃到 SKILL.md 且五項全過、1 是有不合格項目（清單走 stderr，格式 {檔案}:{鍵}:{說明}）、2 是用法錯誤、3 是什麼都沒掃。 - SKILL.md 明寫退出 3 不算通過，並把「每個 domain 的 lint-frontmatter.sh 退出 0」列進第 6 步的完成條件。 Who： 屬 CLI hook 接線修正（jsc-hooks 0.3.4）在 meta 這一側的稽核工具。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 這一側的規範文件。