feat(meta): 新增 SKILLSET 頁型與稽核流程檢查，四支異動技能收尾寫異動報告 #25
No Assignees
Notifications
Due Date
No due date set.
Depends on
#25 feat(gitea): 支援 SKILLSET 頁面類型
plugins/gitea
Reference: plugins/meta#25
Reference in New Issue
Block a user
feat(meta): 新增 SKILLSET 頁型與稽核流程檢查，四支異動技能收尾寫異動報告
摘要
jsc-meta的落地，共四條。R13 新增SKILLSET頁型（SKILLSET_CONTENTS、SKILLSET_{HASH}，雜湊來源{owner}/{repo}，頁內累積歷次異動），並要求skill-new、skill-update、skill-delete、skillset-update四支收尾強制套用到工作階段、驗證、寫報告；R14 稽核清單新增流程檢查四項（指標指得到、每步有完成條件、退路與失敗分流、閘門不自鎖）；R12sync-marketplace.sh列為skill-check的必經步驟；R15 部署後強制重啟閘門的規則正文、九支豁免清單與JSC_RESTART_GATE。決策紀錄在 wikiknowledges/QUESTION的QUESTION_FB8DF0B5。變更內容
references/guidelines.mdJSC_WIKI_REPO_SKILLSET、JSC_RESTART_GATE兩個環境變數列、wiki 頁命名總表的SKILLSET一列與雜湊來源說明、「部署後重啟閘門」一節（含九支豁免表與「清單認技能名不認呼叫鏈」），以及審核檢查清單的流程檢查四項skills/skill-check/SKILL.mdsync-marketplace.sh原本不在任何流程裡，跑不跑全憑人記得，改列為必經的第 5 步並逐一分流四個結束碼；第 2 步的稽核範圍明寫要涵蓋流程檢查四項，準則加了項目稽核才查得到skills/skill-new/SKILL.mdSKILLSET_{HASH}skills/skill-update/SKILL.mdlist-skills.sh的description與被動到的工具skills/skill-delete/SKILL.mdskills/skillset-update/SKILL.mdplugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json設計重點
deploy。 marketplace 與version-guard.sh都讀存取庫的預設分支（master），PR 停在develop時jsc-cli:deploy一定看不到這次的改動，「plugin list印出新版號」這個完成條件永遠達不到，流程會卡死。所以已合併到master走deploy，還沒到master就改用工作樹驗證，報告標「工作樹驗證、尚未部署」並點名還沒合併的發佈 PR。SKILLSET_{HASH}的雜湊來源是被改動的 domain 存取庫{owner}/{repo}，一個存取庫一頁；每次異動附加一節，要看一支技能改過幾次就在同一頁上翻。寫不進去時把頁名與未寫入的內容交回使用者，這一步留著不結案，不讓「報告沒寫成」被當成完成。jsc-ask:ask、jsc-git:pr、jsc-git:commit）自己不是收尾規則的主體，是為了讓前六支走得完才補進來的，準則裡單獨寫一段提醒日後增豁免時要一併想它會呼叫誰。references/後指標指向空處、工作包閘門若擋掉implement就結不了 PR），抽象敘述判不出來的，看實例就判得出來。測試結果
tools/ste100-lint.sh對本存取庫全綠。ste100-lint.sh全綠，三份 manifest 版本各自一致。restart-gate.sh的九支豁免與逃生門、gitea.sh wiki-repo SKILLSET的三項判定，都與準則寫的一致。前置 Push Request
What：`references/guidelines.md` 四處增修。環境變數表新增 `JSC_WIKI_REPO_SKILLSET` 與 `JSC_RESTART_GATE` 兩列；wiki 頁命名總表新增 `SKILLSET` 一列，並補上雜湊來源為被改動的 domain 存取庫 `{owner}/{repo}`、頁內累積歷次異動兩段說明；新增「部署後重啟閘門」一節，用表寫下狀態檔、清除時機、判定位置與逃生門，另附九支豁免技能的表與「清單認的是技能名，不是呼叫鏈」一段；審核檢查清單末尾新增流程檢查四項。 Why：這批規則要落到四個 domain 的腳本與技能裡，準則是它們的唯一真實來源。規則只留在各自的實作裡，改一邊忘一邊，稽核就沒有對照標準。三件事各有各的理由：`SKILLSET` 頁型讓技能組每次異動留下查得到的驗證紀錄；重啟閘門補上「部署換掉的是磁碟上的技能檔，工作階段載入的還是舊版」這段落差；流程檢查四項把過去踩過的坑寫成逐項確認得出來的項目。 How：閘門那一節刻意把每一支的「為什麼不能擋」逐支寫出來，不只列技能名——豁免清單日後要增刪，理由沒寫下來就得重新想一次。九支的理由收斂成同一件事：部署後還要寫得完技能組異動報告與工作日誌，整批擋下去「先重啟」與「先寫完報告」會互相打死，通則另外寫進流程檢查第 4 項「閘門不自鎖」。「清單認技能名不認呼叫鏈」單獨寫一段，因為後三支（`jsc-ask:ask`、`jsc-git:pr`、`jsc-git:commit`）自己不是收尾規則的主體，是為了讓前六支走得完才補進來的，日後增豁免時要一併想它會呼叫誰。流程檢查其中兩項附上踩過的實例，抽象敘述判不出來的，看實例就判得出來。 Who：`jsc-meta` 的技能準則，以及依準則稽核的 `skill-check` 與四支技能組異動技能。What：`skill-new`、`skill-update`、`skill-delete`、`skillset-update` 四支各新增一個收尾步驟，內含三個子步驟：把改動套用到目前工作階段、逐項驗證功能真的動得起來、把驗證結果附加到 wiki 的 `SKILLSET_{HASH}`。四支的 `description` 同步補上這段收尾。 Why：原本四支都以「開了 PR」作為收尾。PR 開完技能還沒進到任何 CLI，改動到底動不動得起來沒人驗過，壞了要等下一次有人踩到才知道。技能組的異動紀錄也一樣沒有落腳處：同一支技能改過幾次、每次改了什麼，只能翻 git 紀錄。 How：套用那一步分兩條路徑，依改動走到哪裡決定。PR 已經合併到 `master` 才走 `jsc-cli:deploy` 更新模式，並依提示重新啟動；PR 還停在 `develop` 或還在等審核，就改用工作樹驗證，報告標成「工作樹驗證、尚未部署」，並點名還沒合併的發佈 PR。分兩條路徑的理由是完成條件達不到：marketplace 與 `version-guard.sh` 都讀存取庫的預設分支，停在 `develop` 的改動 `deploy` 一定看不到，硬跑就卡在永遠達不到的完成條件上。驗證那一步要求逐項比對結束碼與實際輸出，不接受「跑完沒報錯」；對不上就回到套用那一步重跑，不往下走。報告一律附加一節、不覆蓋舊節，要看一支技能改過幾次就在同一頁上翻；寫不進去就把頁名與未寫入的內容交回使用者，這一步留著不結案。 Who：`jsc-meta` 的四支技能組異動技能，以及日後查技能組異動紀錄的人。