plugins/meta
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

release: v0.1.5 develop 到 master #29

Merged
admin merged 3 commits from develop into master 2026-08-27 10:58:17 +00:00
Conversation 1 Commits 3 Files Changed 4
+9 -7
jiantw83 commented 2026-08-27 10:56:28 +00:00
Member
Copy Link
Copy Source

PR 描述

摘要

  • 需求描述：把 develop 上的 v0.1.5 放行到預設分支 master，共 3 個 commit。內容是準則裡「部署後重啟閘門」的狀態檔規則改成一支 CLI 一份，並補上一段設計理由與抽出來的通則。這一段是必要的：marketplace 與 jsc-hooks/hooks/version-guard.sh 都讀存取庫的預設分支 master（version-guard.sh 取 raw plugin.json 時刻意不指定 ref，Gitea 就回預設分支那一份），而本存取庫又是 marketplace 的正本，develop 併了不等於生效，要放行到 master，已安裝的五支 CLI 才抓得到這次修正。原本的缺陷是 2026-08-27 這道閘門上線當日部署時實測抓到的：全機器單一狀態檔導致並行部署互相覆蓋（實測 kiro 寫入 9 秒後被 codex 蓋掉），而且任一支 CLI 重啟就解除全部五支的閘門，其餘四支沒重啟卻不再被擋。
  • 計畫名稱：無
  • 計畫頁：無
  • 分析頁：無

變更內容

檔案 為什麼改
references/guidelines.md 「部署後重啟閘門」那張規則表的四列改成一支 CLI 一份：狀態檔路徑改 $JSC_HOME/restart-required.d/{cli}、清除時機改成只清自己那一份、擋人與放行兩列的主詞從「狀態檔」換成「該 CLI 那份」，並明講別支 CLI 的狀態檔不影響這一支。判定位置與逃生門兩列不動。另新增一段「狀態檔為什麼一支 CLI 一份」，寫下兩個實測後果與改法，收尾抽成通則：跨 CLI 或跨工作階段的狀態檔，設計時先問清楚那個事實屬於誰，並指向工作包歸屬狀態檔踩過的同一類錯誤。
plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 版本升到 0.1.5。

設計重點

  • 準則要跟得上實作，否則稽核會照舊版判：jsc-meta 的準則是每一輪技能稽核的判準來源。jsc-hooks 與 jsc-cli 改成一支 CLI 一份之後，準則若還寫全機器單一檔案，下一次稽核會把正確的實作判成不合規。這三個存取庫的放行要一起做，就是這個原因。
  • 通則比個案重要：這次真正要留下來的不是路徑改了什麼，而是那個判斷方法——跨 CLI 或跨工作階段的狀態檔，設計時先問清楚那個事實屬於誰。重啟閘門管的是「這支 CLI 的行程還在跑舊版」，那是每支 CLI 各自的事實，所以狀態檔就該一支一份；同一類錯誤在工作包歸屬狀態檔上也踩過，所以新增那段有指回去。
  • 記的是實測，不是推論：新增那段寫明兩個後果都是 2026-08-27 部署當日實測抓到的，並點出哪一個更嚴重（清除是全域的，任一支重啟就解除全部五支，閘門在多 CLI 環境等於半失效）。準則裡留下事實與日期，下次有人想改回單一檔案才有得對照。
  • 豁免清單與閘門不自鎖那兩段不動：這次只改狀態檔規則，九支豁免技能的清單、清單認技能名不認呼叫鏈、以及閘門不自鎖的通則都維持原樣。
  • 附帶加固與行為差異（實作在 jsc-hooks 側，準則對齊的是同一套行為）：CLI 代號直接當檔名，所以含 /、以 . 開頭、或帶 [A-Za-z0-9._-] 以外字元的值一律當成取不到（實測 JSC_CLI=../evil、a/b、.、.. 都回 exit 2，狀態目錄外沒有多出檔案）；舊格式單一檔案存在時一律擋、訊息標明是舊格式紀錄，clear 會一併刪掉，屬過渡相容。升級後重啟一支 CLI 只解除那一支的閘門，其餘的照樣被擋、要各自重啟；restart-gate.sh report 現在看得出哪幾支還沒重啟。仍然只有 claude 擋得住——codex、copilot、antigravity、kiro 沒有 pre-tool hook，狀態檔照樣寫、照樣清，但中間沒有判定點。

測試結果

  • tools/ste100-lint.sh 掃本存取庫全綠。
  • 三份 manifest（plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json）版本一致為 0.1.5。
  • 本存取庫這一輪沒有腳本變更，sh -n 沒有對象可跑；另兩個存取庫改動過的腳本 sh -n 全部通過。
  • 核心隔離實測（在 jsc-hooks 側跑，驗的是準則寫的這套行為）：kiro 與 codex 各跑一次 require，產生兩份獨立狀態檔、不互相覆蓋；三支 CLI 各只看得到自己那一份；kiro clear 之後只剩 codex 那一份；重啟後 kiro 放行而 codex 仍被擋。最後這一列正是舊版壞掉的行為，主 agent 另外獨立複驗過一次，結果一致。
  • 舊檔相容實測：只有舊檔時三支 CLI 全擋、訊息標明是舊格式紀錄；clear 之後舊檔被刪；再判定一次放行。
  • 放行路徑實測：九支豁免技能全放行、逃生門 JSC_RESTART_GATE=off 放行、取不到技能名放行、取不到 CLI 代號放行。
  • 髒值防護實測：JSC_CLI=../evil、a/b、.、.. 四種全部 exit 2，狀態目錄外沒有多出檔案。
  • 所有子命令在 </dev/null 加 timeout 之下都不卡住。
  • jsc-hooks/tools/wire-cli.sh smoke claude 回 status=ok，重啟閘門 16 條專屬情境加通用執行共 17 行全部與預期相同。
  • 沒跑的據實說明：非 claude 四支 CLI 上這道閘門無法測試——它們沒有 pre-tool hook，沒有判定點可測，不是還沒測。
  • 這批放行本身沒有重跑腳本測試。上面這些是在 fix PR 階段跑的（meta#28，隔離與相容部分在 hooks#37），本 PR 只是把已驗過的 develop 內容搬到 master，沒有新的程式碼變更。

前置 Push Request

  • 無。三支 fix PR（hooks#37、cli#30、meta#28）都已合併進各自的 develop。
# PR 描述 ## 摘要 - 需求描述：把 `develop` 上的 v0.1.5 放行到預設分支 `master`，共 3 個 commit。內容是準則裡「部署後重啟閘門」的狀態檔規則改成一支 CLI 一份，並補上一段設計理由與抽出來的通則。這一段是必要的：marketplace 與 `jsc-hooks/hooks/version-guard.sh` 都讀存取庫的預設分支 `master`（`version-guard.sh` 取 raw `plugin.json` 時刻意不指定 ref，Gitea 就回預設分支那一份），而本存取庫又是 marketplace 的正本，`develop` 併了不等於生效，要放行到 `master`，已安裝的五支 CLI 才抓得到這次修正。原本的缺陷是 2026-08-27 這道閘門上線當日部署時實測抓到的：全機器單一狀態檔導致並行部署互相覆蓋（實測 kiro 寫入 9 秒後被 codex 蓋掉），而且任一支 CLI 重啟就解除全部五支的閘門，其餘四支沒重啟卻不再被擋。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `references/guidelines.md` | 「部署後重啟閘門」那張規則表的四列改成一支 CLI 一份：狀態檔路徑改 `$JSC_HOME/restart-required.d/{cli}`、清除時機改成只清自己那一份、擋人與放行兩列的主詞從「狀態檔」換成「該 CLI 那份」，並明講別支 CLI 的狀態檔不影響這一支。判定位置與逃生門兩列不動。另新增一段「狀態檔為什麼一支 CLI 一份」，寫下兩個實測後果與改法，收尾抽成通則：跨 CLI 或跨工作階段的狀態檔，設計時先問清楚那個事實屬於誰，並指向工作包歸屬狀態檔踩過的同一類錯誤。 | | `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` | 三份 manifest 版本升到 0.1.5。 | ## 設計重點 - **準則要跟得上實作，否則稽核會照舊版判**：`jsc-meta` 的準則是每一輪技能稽核的判準來源。`jsc-hooks` 與 `jsc-cli` 改成一支 CLI 一份之後，準則若還寫全機器單一檔案，下一次稽核會把正確的實作判成不合規。這三個存取庫的放行要一起做，就是這個原因。 - **通則比個案重要**：這次真正要留下來的不是路徑改了什麼，而是那個判斷方法——跨 CLI 或跨工作階段的狀態檔，設計時先問清楚那個事實屬於誰。重啟閘門管的是「這支 CLI 的行程還在跑舊版」，那是每支 CLI 各自的事實，所以狀態檔就該一支一份；同一類錯誤在工作包歸屬狀態檔上也踩過，所以新增那段有指回去。 - **記的是實測，不是推論**：新增那段寫明兩個後果都是 2026-08-27 部署當日實測抓到的，並點出哪一個更嚴重（清除是全域的，任一支重啟就解除全部五支，閘門在多 CLI 環境等於半失效）。準則裡留下事實與日期，下次有人想改回單一檔案才有得對照。 - **豁免清單與閘門不自鎖那兩段不動**：這次只改狀態檔規則，九支豁免技能的清單、清單認技能名不認呼叫鏈、以及閘門不自鎖的通則都維持原樣。 - **附帶加固與行為差異（實作在 `jsc-hooks` 側，準則對齊的是同一套行為）**：CLI 代號直接當檔名，所以含 `/`、以 `.` 開頭、或帶 `[A-Za-z0-9._-]` 以外字元的值一律當成取不到（實測 `JSC_CLI=../evil`、`a/b`、`.`、`..` 都回 exit 2，狀態目錄外沒有多出檔案）；舊格式單一檔案存在時一律擋、訊息標明是舊格式紀錄，`clear` 會一併刪掉，屬過渡相容。升級後重啟一支 CLI 只解除那一支的閘門，其餘的照樣被擋、要各自重啟；`restart-gate.sh report` 現在看得出哪幾支還沒重啟。仍然只有 claude 擋得住——codex、copilot、antigravity、kiro 沒有 pre-tool hook，狀態檔照樣寫、照樣清，但中間沒有判定點。 ## 測試結果 - `tools/ste100-lint.sh` 掃本存取庫全綠。 - 三份 manifest（`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json`）版本一致為 0.1.5。 - 本存取庫這一輪沒有腳本變更，`sh -n` 沒有對象可跑；另兩個存取庫改動過的腳本 `sh -n` 全部通過。 - 核心隔離實測（在 `jsc-hooks` 側跑，驗的是準則寫的這套行為）：kiro 與 codex 各跑一次 `require`，產生兩份獨立狀態檔、不互相覆蓋；三支 CLI 各只看得到自己那一份；kiro `clear` 之後只剩 codex 那一份；重啟後 kiro 放行而 **codex 仍被擋**。最後這一列正是舊版壞掉的行為，主 agent 另外獨立複驗過一次，結果一致。 - 舊檔相容實測：只有舊檔時三支 CLI 全擋、訊息標明是舊格式紀錄；`clear` 之後舊檔被刪；再判定一次放行。 - 放行路徑實測：九支豁免技能全放行、逃生門 `JSC_RESTART_GATE=off` 放行、取不到技能名放行、取不到 CLI 代號放行。 - 髒值防護實測：`JSC_CLI=../evil`、`a/b`、`.`、`..` 四種全部 exit 2，狀態目錄外沒有多出檔案。 - 所有子命令在 `</dev/null` 加 `timeout` 之下都不卡住。 - `jsc-hooks/tools/wire-cli.sh smoke claude` 回 `status=ok`，重啟閘門 16 條專屬情境加通用執行共 17 行全部與預期相同。 - 沒跑的據實說明：非 claude 四支 CLI 上這道閘門無法測試——它們沒有 pre-tool hook，沒有判定點可測，不是還沒測。 - 這批放行本身沒有重跑腳本測試。上面這些是在 fix PR 階段跑的（meta#28，隔離與相容部分在 hooks#37），本 PR 只是把已驗過的 `develop` 內容搬到 `master`，沒有新的程式碼變更。 ## 前置 Push Request - 無。三支 fix PR（hooks#37、cli#30、meta#28）都已合併進各自的 `develop`。
jiantw83 added 3 commits 2026-08-27 10:56:28 +00:00
docs(guidelines): 重啟閘門狀態檔規則改為一支 CLI 一份 baa1f1118f 
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` 的技能準則，部署後重啟閘門這條規則的正本。
chore(meta): 三份 manifest 版本升到 0.1.5 29080ca6e8 
What：`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 的 `version` 從 0.1.4 升到 0.1.5，三份同步，description 不動。

Why：準則改了就要讓機器上的 `jsc-meta` 換到新版，四支異動技能與 skill-check 讀的才是這一版的規則。版本不升，`version-guard.sh` 的版本前置檢查與 `jsc-cli:deploy` 的落後判定都看不出本機還是舊版，機器上就不會被提示更新。

How：只改版號一個欄位。三份必須一致：`plugin.json` 給 marketplace、`.claude-plugin` 給 claude、`.codex-plugin` 給 codex，任一份落後都會讓那一路的版本比對抓錯。這一輪只改準則正文、沒有新增或移除技能，所以走修訂號。

Who：`jsc-meta` 的三份 plugin manifest，配合這一輪準則修正發佈。
Merge pull request 'docs(meta): 準則的重啟閘門狀態檔規則改為一支 CLI 一份' (#28) from fix/restart-gate-per-cli-state into develop ccae8bfd7a 
Reviewed-on: #28
admin approved these changes 2026-08-27 10:58:15 +00:00
admin merged commit 2b81e67817 into master 2026-08-27 10:58:17 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
admin
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin (系統管理員) jiantw83 (Jeffery)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/meta#29