plugins/meta
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
122 Commits 9 Branches 0 Tags
651ddb3a6f8f1cc2046a5ee772fb0430b9ec3ad9
Commit Graph
29 Commits
Author SHA1 Message Date
jiantw83 651ddb3a6f feat(link): 連結一律寫成 [文字](絕對網址)，寫入前先驗證連得到 
取消 [[頁名]] 與 [[顯示文字|頁名]] 兩種同 wiki 寫法，不再分「同存取庫」與
「跨存取庫」兩條規則。那種寫法只在自己那個 wiki 內解析，寫錯不報錯，畫面上
看起來像普通文字或死連結，巡不到也修不了。

連結寫進頁面前先過 jsc-gitea 的 link-check.sh，結束碼 0 才寫。驗證一律走 API，
不看網頁狀態碼：私有存取庫的網頁網址對未登入請求一律回 404，拿狀態碼判會把
好連結判成壞的。認證失敗回 7，與死連結的 1 分開，免得金鑰一過期就把還在的頁
整批判死。
 2026-09-02 14:27:18 +08:00
jiantw83 f13724cb79 feat(wiki): 目錄頁專用存取庫入準則，skill-check 加入優化建議流程 
What：準則的環境變數表與命名總表加入 JSC_WIKI_REPO_CONTENTS 與目錄頁專用存取庫
一節，HASH 規則改為完整 40 碼。skill-check 的 Group 3 先讀上一輪決議，建議表加上
決議與決議日期兩欄，新增步驟 8 把稽核結果寫進 SKILLSET 頁。新增 check-page-name.sh
與兩份 SKILLSET 範本。

Why：優化建議原本每輪產出後就散掉，決議為延後的項目下一輪會重新掃、重新問一次，
正是 skill-check 自己第三個面向點名的毛病。SKILLSET_CONTENTS 是 14 個目錄頁裡
唯一沒有範本的，四支技能都被要求寫它，卻沒有欄位定義可套。

How：Group 1 補進三支現成但沒人呼叫的檢查腳本——ste100-lint.sh、check-wiki-rules.sh
與新增的 check-page-name.sh。讀不到上一輪決議時只停掉 Group 3，不再中止整輪：那兩組
完全不碰 wiki，金鑰失效就會鎖死整組技能唯一的稽核路徑。另外四支 meta 技能原本把目錄頁
寫進 SKILLSET 存取庫，一併改走 CONTENTS。
 2026-09-02 11:02:48 +08:00
jiantw83 7b6b9076ea docs(guidelines): 補上助理運行閘門與 fail-closed 閘門的專屬規則 
What：
- 新增「助理運行閘門」一節：規格表、心跳判定的六碼處置、豁免清單十一支。
- 節內另立「fail-closed 閘門的專屬規則」四條，那是準則現在完全沒有的東西。
- 環境變數表補上閘門開關與心跳門檻兩列。
- 三份 manifest 的版本一起提升。

Why：
- 整組 hook 的通則是資料不足就放行，這一道相反。例外不點名，後來的人會以為可以隨便再開一道 fail-closed 的閘門，而那種閘門開錯就是整組技能鎖死。
- 豁免清單與腳本檔頭是同一件事實。準則沒有那張表，兩邊就會各走各的，改一支忘了另一支。

How：
- 四條專屬規則裡有兩條是這一輪實作時才想清楚的。逃生門的判斷要擺在載入共用函式庫之前——函式庫讀不到時 sh 會就地結束並回擋人的那個碼，逃生門也跟著跑不到，人就繞不過去；這一條只對 fail-closed 成立。豁免清單只收解鎖路徑，方向與重啟閘門相反，那一道解鎖靠閘門外的動作，這一道解鎖靠跑一支技能。
- 「清單認技能名不認呼叫鏈」那一條補了一個更狠的實例：巡檢要先把結果寫上監控頁才寫心跳，只豁免助理自己會做出自咬環。所以新增豁免技能時不只要想它會呼叫誰，還要想那條呼叫鏈上有沒有一步是解鎖條件本身的前置。
- 心跳判定回「檔案系統問不出來」時放行不擋，理由與代價都寫進去了。那一碼與「時間戳壞掉」的差別在有沒有出路。

Who：
助理閘門實作完之後，把當中的判斷收進準則，讓下一道同類閘門有依據。
 2026-09-01 15:27:06 +08:00
jiantw83 970b7a4f71 docs(guidelines): 命名總表加入 MONITOR 頁型別 
What：
- Wiki 頁命名總表新增 MONITOR 一列，擁有者是技能助理。
- 表下補三段說明：雜湊來源、為什麼不帶工具名稱、寫入語意。
- CHECK 那一段拿掉「是唯一例外」的斷言，改成指向新的機器層規則。
- 三份 manifest 的版本一起提升。

Why：
- 總表是所有 wiki 頁命名的唯一來源。新型別沒登錄進來，各技能就沒有依據，只能各自猜。
- CHECK 原本寫著「是唯一例外」，指的是雜湊來源取主機名與帳號而不是存放庫。加了第二個同樣取法的型別之後，這句話就不成立了，留著會讓讀的人以為只有一個。

How：
- MONITOR 的雜湊來源比照 CHECK，取主機名與登入帳號。助理巡檢的是一台機器，不是一個存放庫。
- 刻意不帶工具名稱，這一點與 TOOLING 相反。TOOLING 一支 CLI 一頁，因為每支 CLI 各有自己的已安裝 plugin 與 hook 接線；助理看的是整台機器一份心跳、一本待辦簿，不分 CLI。
- 監控頁一律附加，不覆寫。助理的寫入是背景行為，覆寫錯了沒人在現場。TOOLING 內容頁是每次盤點覆寫整頁，兩者語意相反，所以各自寫明白。
- 只動總表那一節，其餘章節不碰。

Who：
技能助理落地帶出來的頁型別需求，四個存放庫同一批改。
 2026-09-01 12:10:55 +08:00
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
jiantw83 651dc19be9 docs(guidelines): 改寫相依版本準則並補上技能行為清單合約 
What：「Manifest 相依版本」第 5 條改成部署端照樣更新，只在回報裡寫明缺哪一版。「版本前置檢查」補上相依版本檢查三列。新增「技能行為清單」一節，訂出位置、標題、節、表格、欄位與更新時機。審核檢查清單加上行為清單這一項。README 補上 behaviors.md 與 check-behaviors.sh 兩列，並把 skill-check 段落改成三組腳本。

Why：跳過更新會讓落後的 domain 永遠更新不到。它落後所以被跳過，被跳過所以永遠落後。相依版本不符要擋的是拿舊版去跑，不是把舊版換成新版。阻擋改到技能被呼叫的當下，才擋得住真正會出事的動作。行為清單要有一份格式合約，check-behaviors.sh 才有判定依據。

How：阻擋交給 jsc-hooks/hooks/version-guard.sh。版本比對由它自己實作，不呼叫 jsc-cli/tools/check-requires.sh。hook 專屬存放於 jsc-hooks，而且 jsc-cli 已宣告相依 jsc-hooks，反向呼叫會做出循環相依。兩道檢查共用同一份豁免清單。行為清單一個 domain 一份，放進該 domain 的 references/behaviors.md，技能改動與清單改動才進得了同一個 PR。

Who：涵蓋這次兩件需求的準則與說明文件，一件是相依版本不符改為阻擋執行，一件是技能行為清單。
 2026-08-31 13:37:22 +08:00
jiantw83 6d28e207c7 docs(guidelines): 修正版本閘門、重啟閘門與維護頁的準則記載 
版本前置檢查的豁免表只列了四項，重啟閘門的豁免表少了 hook 修復技能。
照著這兩張表設定，hook 壞掉時唯一的修復路徑會被自己擋住，修不好也繞不過。
兩張表逐項對齊三方實作與腳本現況，補成七項與十項，
並寫明各自的唯一真實來源是哪一支 hook 腳本，兩邊以後要一起改。

Wiki 頁命名總表原本替維護類型列了內容頁。
技能與樣板都沒有產生那一頁的步驟，照著總表找，只會找到一個不存在的頁。
改成只列目錄頁，並寫清楚維護登記全寫在目錄頁的表格裡；
要補內容頁就先補技能步驟與樣板，不能只在總表上寫著。

另外登記技能盤點頁的類型、環境變數與雜湊來源，說明為什麼雜湊要帶工具名稱，
補上唯讀稽核要帶唯讀旗標、行數一律讀腳本自己印的那一行兩項檢查，
並把新增的共用說明、兩份樣板與三支工具寫進 README 的檔案一覽。
 2026-08-31 11:11:12 +08:00
jiantw83 0cf2392ae7 fix(skill-check): 納入腳本與 hook 驗證 2026-08-28 16:55:48 +08:00
jiantw83 771d71c28e docs(guidelines): 定義 jsc requires 相依宣告規則 2026-08-28 11:59:16 +08:00
jiantw83 b0ea356ff5 feat(meta): 建立 PR 收尾回報單一規範 2026-08-28 09:30:23 +08:00
jiantw83 baa1f1118f docs(guidelines): 重啟閘門狀態檔規則改為一支 CLI 一份 
What：`references/guidelines.md`「部署後重啟閘門」的規則表改四列——狀態檔路徑改成 `$JSC_HOME/restart-required.d/{cli}` 並標明一支 CLI 一份、清除時機標明只清自己那一份、原本的「狀態檔存在時」與「狀態檔不存在時」兩列改寫成「該 CLI 那份存在時」與「該 CLI 那份不存在時」，並寫明別支 CLI 的狀態檔不影響這一支。另外新增一段「狀態檔為什麼一支 CLI 一份」，記下 2026-08-27 部署時實測出的兩個缺陷，並把它寫成通則。

Why：準則是技能組的規則正本，`jsc-hooks` 的實作與 `jsc-cli` 的說明都對著它看。實作改成一支 CLI 一份而準則還停在單一檔案，下一次 skill-check 會判成實作違規，也可能有人照準則把實作改回去。這兩個缺陷是實測抓到的、不是推測，理由留在準則裡才擋得住下一次的簡化。

How：規則表只改該改的四列，判定位置與逃生門兩列不動。新增那段把缺陷寫清楚——並行部署互相覆蓋只留最後一支，以及任一支重啟就解除全部五支的閘門——再收成通則：跨 CLI 或跨工作階段的狀態檔，設計時先問清楚那個事實屬於誰，並指出工作包歸屬狀態檔踩過同一類錯誤。豁免清單那九支與「清單認技能名不認呼叫鏈」不動，這一輪沒有動到豁免範圍。

Who：`jsc-meta` 的技能準則，部署後重啟閘門這條規則的正本。
 2026-08-27 18:49:59 +08:00
jiantw83 6447416c7b docs(guidelines): 準則新增 SKILLSET 頁型、部署後重啟閘門與流程檢查四項 
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` 與四支技能組異動技能。
 2026-08-27 16:34:16 +08:00
jiantw83 769d8f3f33 docs(guidelines): 準則新增 PR 分支階梯與盯場輪詢間隔 
What：`references/guidelines.md` 新增「PR 分支階梯」一節，列出兩種型別的階梯、多層子功能的組法、base 一律由 `jsc-git/tools/base-branch.sh --derive` 推導、功能主幹自動建立，以及最後一級不能省；環境變數表補上 `JSC_PR_WATCH_INTERVAL`；稽核檢查清單新增一項「PR 的 base 符合 PR 分支階梯，沒有越級」。

Why：階梯要對所有存取庫成立，就必須有一份正本。放在技能準則裡，各 domain 的 README 與參考文件才能只寫摘要並指回來，不會養出好幾份互相打架的規則；稽核清單少了這一項，越級開的 PR 也沒有任何一關會發現。

How：階梯只寫表與六條說明，不寫實作細節，推導行為的正本仍在 `jsc-git/tools/base-branch.sh`。特別寫明第 4 條「推不出唯一合法基底就中止並詢問使用者，不猜，也不退回 `develop`」與第 6 條「`develop` 併進 `master` 才會生效」——marketplace 與 `version-guard.sh` 讀的都是存取庫的預設分支，階梯最後一級省掉就等於沒有發布。

Who：所有 jsc domain 存取庫的 PR，以及跑 `jsc-meta:skill-check` 稽核的人。
 2026-08-27 11:20:30 +08:00
jiantw83 19303ca555 feat(ste100): 語言規則納入適用範圍與編碼要求 
What
- `references/ste100.md` 新增「適用範圍」與「編碼」兩節，並以表格列出各類輸出是否適用。
- 「機檢」一節補上新的類別清單與文件檔、程式碼檔的分流說明。
- `references/guidelines.md`「語言」第 1 條改寫成「所有非程式碼輸出一律繁體中文、UTF-8、
  無亂碼、無簡體字」，並以一行指引指回 `references/ste100.md`。
- 「審核檢查清單」新增一個可勾選項目，涵蓋非程式碼輸出的語言與編碼，且要求機檢全綠。

Why
- 舊條文只講「交談與輸出內容」用 STE100 繁中，沒有把程式碼註解、commit 訊息、PR 描述、
  wiki 頁這些實際會產出的東西點名，執行時容易各自解讀。
- 編碼要求原本只有基礎紀律裡的一句「UTF-8，無亂碼」，沒有說明什麼算亂碼，也沒有寫明
  不得出現簡體字，機檢與人工判讀對不上。

How
- 適用範圍用表格逐項標「是」或「否」，並明講程式碼識別字、關鍵字、API 名稱不受限，
  SKILL.md 維持整份英文。
- 編碼用表格寫要求、內容與常見違規，違規範例直接對應機檢的「亂碼」類別。
- 細節只寫在 `references/ste100.md` 一處，guidelines.md 只留摘要與指引，維持單一真實來源。

Who
- 影響所有 jsc 技能的輸出與審核；撰寫技能與跑 `jsc-meta:skill-check` 的人要照新清單檢查。
 2026-08-27 09:43:20 +08:00
jiantw83 d9d1dafe6e docs(guidelines): 準則新增 CHECK 與 REPORT 兩種 wiki 頁類型 
What: wiki 頁命名總表加入 CHECK（擁有者 jsc-cli）與 REPORT（擁有者 jsc-log），環境變數表加入 JSC_WIKI_REPO_CHECK 與 JSC_WIKI_REPO_REPORT，並補上兩者的雜湊來源規則。
Why: 準則是這兩張總表的唯一真實來源。新頁類型只加進程式的白名單而沒寫進準則，下一次審核就會把它們當成漏網項目。
How: CHECK 記的是一台執行環境而不是存取庫，雜湊來源改用 {主機名}/{登入帳號}，是總表的唯一例外，明文寫清楚為什麼。REPORT 用既有的「加上主題字串」規則，雜湊來源為 {owner}/{repo}/{期間}，年月週日各一頁。
Who: wiki 頁面命名與 wiki 存取庫解析。
 2026-08-26 10:46:11 +08:00
jiantw83 fbb7004e70 fix(meta): 放寬 major 版本限制 2026-08-25 16:41:57 +08:00
jiantw83 acbbd30a0f fix(meta): 版本號改為單位數進位 2026-08-25 16:40:01 +08:00
jiantw83andClaude Opus 5 073c51e145 docs(meta): 同步文件與參考資料 
What：更新 README、AGENTS.md、templates 與 references，讓文件敘述與實際行為一致。

Why：稽核發現多處文件與程式行為分歧，違反「每個意義只有單一真實來源」。

How：以實際程式行為為準改寫敘述，重複的規則收成單一來源並以一行指引指過去。

Who：jsc-meta:skill-check 例行稽核（2026-08-25）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 14:58:54 +08:00
jiantw83andClaude Opus 5 7eb179f3a1 docs(guidelines): 新增版本前置檢查規範與豁免清單 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 11:52:38 +08:00
jiantw83andClaude Opus 5 98bc02578d refactor(marketplace 正本): 正本與權威來源改為 plugins/meta，移除對 plugins/jsc 的相依 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 18:00:35 +08:00
jiantw83andClaude Opus 5 a87946784b docs(guidelines): 新增 DELIVER 頁型與 JSC_WIKI_REPO_DELIVER 環境變數 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 17:24:45 +08:00
jiantw83andClaude Fable 5 85cfa77ed1 docs(guidelines): 新增 LEARN 頁型與 JSC_WIKI_REPO_LEARN 環境變數 
What：在 references/guidelines.md 的 wiki 頁命名總表新增 LEARN 頁型（LEARN_CONTENTS 教訓目錄、LEARN_{HASH} 技能教訓頁），並在環境變數表新增 JSC_WIKI_REPO_LEARN，未設定時退回 JSC_WIKI_REPO。

Why：jsc-log 新增 learn 技能，需要在準則中收錄對應的 wiki 頁型與環境變數，讓各技能對頁面命名與 wiki 存取庫解析有一致依據。

How：比照既有 LOG／ERROR 頁型格式，於環境變數表與頁命名總表各補一列，維持表格欄位與退回規則一致。

Who：jsc-log（learn 技能）為此頁型的擁有者。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-24 11:36:48 +08:00
jiantw83 3c63989f80 fix(skill-check): 補強工具化與環境優先審核 2026-08-21 16:53:17 +00:00
jiantw83andClaude Fable 5 dd04781058 docs(guidelines): 補記 gitea.sh 的 tea 登入金鑰備援機制 
What（改了什麼）：
- 「技能設計」第 2 條補充：gitea.sh 在 token 未設定或收到 401／403 時，會自動改用 tea 的登入金鑰重試一次。
- 環境變數表 GITEA_TOKEN 的「未設定時」欄位由「詢問使用者」改為「改用 tea 登入金鑰（tea login list）；tea 也沒有才詢問使用者」。

Why（為什麼改）：
- gitea.sh 已實作 tea token 備援，但準則文件未記載；技能作者與審核者依文件行事，文件落後會導致誤判認證失敗的處理方式。

How（怎麼改）：
- 僅更新 references/guidelines.md 兩處文字，與 jsc-gitea/tools/gitea.sh 的實際行為對齊，不動任何流程或工具。

Who（影響哪個功能／使用者）：
- 所有依 guidelines.md 撰寫或審核 jsc 技能的維護者；使用 gitea.sh 的技能在 token 失效時的預期行為自此有文件依據。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 08:23:53 +00:00
jiantw83andClaude Fable 5 a2057ad3e4 feat(meta): 準則改為每個存取庫都帶統一 marketplace 副本並同步 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:37:49 +08:00
jiantw83andClaude Fable 5 e2248493bb feat(meta): 準則改為技能文件整份英文，並明定中文並列用頓號 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:25:24 +08:00
jiantw83andClaude Fable 5 93b7f52ca9 feat(meta): STE100 擬人台灣感規則——新增 references/ste100.md（改寫自 speak-human-tw，MIT）並更新準則語言節 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:13:27 +08:00
jiantw83andClaude Fable 5 5695e3fe06 feat(meta): 準則改為統一 marketplace jsc 與版本 0.0.1 起算 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:03:37 +08:00
jiantw83andClaude Fable 5 6be3e7fc77 feat(meta): 匯入 jsc-meta 技能組 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 13:08:43 +08:00