release: v0.1.9 develop 到 master #29
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: plugins/cli#29
Reference in New Issue
Block a user
摘要
develop放行到master，共 8 個 commit。內容是使用者 15 條工作規則的第三群「技能組治理」在本存取庫的落地：新增tools/write-guides.sh，部署收尾在$JSC_HOME產生update-guide.md與remove-guide.md；deploy.sh轉呼叫restart-gate.sh require掛上部署後重啟閘門；config-spec.tsv補九列設定規格。變更內容
tools/write-guides.sh$JSC_HOME寫下update-guide.md與remove-guide.md，內容是五支 CLI 各自的實際指令，不是通用說明。tools/deploy.shrestart-gate.sh require，把重啟狀態檔寫成雙方講好的 key=value 格式。skills/deploy/SKILL.mdtools/config-spec.tsvscan-config.sh掃得到、不再有無主設定。README.mdplugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json設計重點
develop併了不等於生效：marketplace 與jsc-hooks/hooks/version-guard.sh讀的都是存取庫的預設分支master。version-guard.sh取 rawplugin.json時刻意不指定 ref，Gitea 就回預設分支那一份，所以只有這個 PR 合進master，五支 CLI 才看得到 0.1.9。deploy.sh轉呼叫restart-gate.sh require寫，不自己拼格式。寫的人與讀的人共用同一支程式，格式就不會漂。$JSC_HOME，重啟後還在。部署當下的終端輸出會被捲掉，檔案不會。config-spec.tsv補齊九列是為了讓scan-config.sh orphans能回零。設定沒登記在規格表裡，等於沒人知道它存在。升級後使用者會立刻感受到的差異
$JSC_HOME：update-guide.md與remove-guide.md。deploy.sh會寫下重啟狀態檔，接著在 claude 上，非豁免技能會被 jsc-hooks 的restart-gate.sh擋下（exit 2），逃生門是JSC_RESTART_GATE=off。測試結果
ste100-lint.sh掃本存取庫全綠。write-guides.sh產出兩份指引，且內容含五支 CLI 的實際指令。config-spec.tsv欄位數一致為 8。scan-config.sh orphans零回報。deploy.sh update經restart-gate.sh require寫出 key=value 格式的狀態檔，jsc-hooks 的restart-gate.sh讀得懂並正確擋下。develop內容推到預設分支。前置 Push Request
What：新增 `tools/write-guides.sh`（`write-guides.sh [-n] {install|update} {domain}...`），產生 `$JSC_HOME/update-guide.md` 與 `$JSC_HOME/remove-guide.md` 兩份指引，兩份都整份覆寫。輸出 TSV 四種行別：`cli`（偵測到的 CLI）、`plan`（dry-run 時會寫入的檔案）、`wrote`（實際寫入的檔案）、`note`（非致命說明）；結束碼 0 寫成、2 參數錯誤、4 目錄或檔案寫不進去。 Why：更新與移除這兩件事原本只存在於技能內文裡。CLI 壞掉、沒有工作階段、或是換人接手的時候，機器上找不到任何一份寫著「這台機器要怎麼更新、怎麼移除」的東西，只能回頭讀技能。指引落成本機檔案，不開工作階段也照著走得完。 How：內容一律依實際偵測結果生成，不寫死。CLI 清單來自 `detect-clis.sh`；每支 CLI 的指令字面直接取自 `deploy.sh -n` 的輸出，所以指引寫的就是 `deploy.sh` 真正會跑的指令——各 CLI 的差異只有 `deploy.sh` 一個真實來源，這裡再抄一份就會有兩套指令，改了一邊忘了另一邊，指引就開始騙人。kiro 走不走本地複製退路，也是讀 `deploy.sh` 的 `note` 行判斷，不自己再探測一次。獨立成一支腳本、不併進 `deploy.sh`：`deploy.sh` 的職責是「對單一 CLI 部署」，一輪部署會逐個 CLI 呼叫它，而指引寫的是整台機器的樣貌，只該產生一次；併進去還會與 `deploy.sh -n` 形成雙向遞迴。寫檔走暫存檔再 `mv`，寫一半不會留下半份指引。移除指引另外列出 plugin 指令管不到的殘留物（`$JSC_HOME`、本地 clone、kiro 技能目錄、rc 檔的 `# jsc-config` 段落）與各自清掉的影響。 Who：`/jsc-cli:deploy` 的 install 與 update 收尾，以及日後要手動更新或整組移除的操作者。What：`tools/deploy.sh` 新增 `restart_gate_sh()` 與 `mark_restart()` 兩個函式，並在全部指令成功、印出 `result` 之前呼叫 `mark_restart`。`install` 與 `update` 會轉呼叫 `jsc-hooks` 的 `hooks/restart-gate.sh require {模式} {domain}...` 掛上重啟閘門，成功就多印一行 `restart<TAB>{狀態檔路徑}`；`uninstall` 與 dry-run 不寫。輸出行別表與檔頭的環境變數說明同步補上。 Why：部署換掉的是磁碟上的技能檔，目前工作階段載入的還是舊版。這段落差期間跑技能，改動看起來沒生效，人會以為部署失敗又重跑一次。要有一個「這台機器有一輪部署還沒重啟」的證據留在檔案上，判定那一端才擋得下來。 How：狀態檔的路徑、格式與判讀全留在 `jsc-hooks` 的 `restart-gate.sh`，這裡只轉呼叫它的 `require` 子命令，比照 `jsc-sdlc` 轉呼叫 `sdlc-gate.sh wp-lock` 的慣例。兩邊各拼一份格式就會對不上：這裡一開始自己寫四欄 TSV，而 hooks 那端讀的是 `key=value`，狀態檔存在卻解不出欄位，改成轉呼叫才修好，格式只能有一個真實來源。找腳本的順序比照 `jsc-sdlc` 的 `wp-gate.sh`：環境變數 `JSC_HOOKS_DIR` 優先，再找並排的工作樹，最後找 plugin 快取；找不到就印 `note` 行據實說「這次沒有掛上重啟閘門」，不自己補寫一份——閘門本來就由 `jsc-hooks` 判讀，它不在就沒有判定點，寫下去只是留一個沒人讀的檔案，還會讓下一輪誤以為閘門掛上了。`require` 一律接 `</dev/null`：它不讀標準輸入，但這裡的標準輸入是宿主餵進來的管線，不關掉會卡住。 Who：`/jsc-cli:deploy` 的 install 與 update 收尾，與 `jsc-hooks` 的部署後重啟閘門對接。What：`skills/deploy/SKILL.md` 新增兩個步驟並改寫 `description`。新的第 7 步：install 或 update 在所有 CLI 跑完之後，整台機器跑一次 `tools/write-guides.sh {mode} {domain}...`，完成條件是兩份指引都印出 `wrote` 行；原本的回報順延為第 8 步；新的第 9 步：收尾一律印出重啟指示「請關閉目前的工作階段並重新啟動，新的技能內容才會載入」，並把兩份指引的路徑講出來。 Why：兩份指引與重啟提示都是部署收尾的一部分，腳本做得到、技能流程沒寫，就等於沒人會跑。重啟這件事尤其要在收尾講清楚：`deploy.sh` 已經把這一輪記進 `$JSC_HOME/restart-required`，使用者不知道要重啟就會繼續用舊版技能，然後以為部署沒生效。 How：指引那一步明寫「整台機器跑一次」，排在每個 CLI 都跑完之後——第 5 步是一個 CLI 一個子代理，指引寫的卻是整台機器的樣貌，跟著 CLI 跑就會被覆寫成最後一支的內容。`uninstall` 跳過這一步：指引描述的是裝好的技能組。重啟指示用固定字句，不讓每次回報各講一套；`JSC_RESTART_GATE=off` 作為逃生門一併寫出，判讀在 `jsc-hooks`。 Who：`/jsc-cli:deploy` 技能的執行流程與收尾回報。