 jiantw83
|
c397994ce8
|
feat(deploy): 部署收尾轉呼叫 restart-gate.sh require 掛上重啟閘門
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` 的部署後重啟閘門對接。
|
2026-08-27 16:34:16 +08:00 |
|
|
jiantw83
|
e01ec1b3f5
|
fix(deploy): kiro 本地複製補上 tools、references、templates、hooks 與 plugin.json
What：
改寫 `tools/deploy.sh` 的 `kiro_copy()`。原本只複製 `skills/.` 一個目錄，現在同時複製 `tools`、`references`、`templates`、`hooks` 四個子目錄與 `plugin.json`。四個子目錄逐一判斷來源是否存在，存在才複製；`plugin.json` 缺了不算錯誤，函式一律回傳 0。`deploy_kiro()` 印給使用者看的 `note` 訊息也一併改寫，說清楚退路實際複製了哪些內容。
Why：
`kiro-cli 2.18.1` 已經沒有 `plugin` 子指令，kiro 只能走本地複製這條退路。過去只複製 `skills/` 還能動，是因為舊版 SKILL.md 沒叫 kiro 跑同伴目錄裡的腳本。2026-08-27 放行的這批技能（cli 0.1.7、sdlc 0.1.9、git 0.0.8、gitea 0.1.5 等）把 `jsc-sdlc/tools/wp-gate.sh owns`、`jsc-gitea/tools/pr-watch.sh`、`jsc-git/tools/base-branch.sh --derive` 寫成 SKILL.md 的完成條件，kiro 於是拿到一份「指令要求跑腳本、腳本卻不在機器上」的技能，`jsc-sdlc:implement` 與 `jsc-git:pr` 會直接卡住，比不更新更糟。缺 `references/` 也讓 `consensus.md`、`branch.md`、`guidelines.md` 在 kiro 上讀不到。
How：
目標路徑維持 `$KIRO_SKILLS/jsc-{domain}/`，跨 plugin 的引用（例如 `jsc-gitea/tools/…`）以 `$KIRO_SKILLS` 為根就解析得到，不必改動任何 SKILL.md。每個子目錄都用「先 `mkdir -p` 目標，再複製 `src/.` 到 `dst/`」的寫法：目標目錄已經存在時，`cp -R src dst/` 會把來源塞進 `dst/{名稱}/{名稱}`，第二次更新就多疊一層。`plugin.json` 以單檔複製處理，讓 `version-guard.sh` 之類的呼叫端查得到本機版本。函式尾端明確 `return 0`，避免 `plugin.json` 不存在時的測試結果變成函式結束碼。
Who：
jsc-cli:deploy 技能的 kiro 部署退路。
|
2026-08-27 12:37:04 +08:00 |
|
|
jiantw83
|
63d4185a40
|
fix(deploy): codex 更新補上逐網域 plugin add
What：deploy_codex 的 update 分支在 marketplace upgrade 之後，補上逐網域的
plugin add，與 install 分支一致。
Why：codex 沒有 plugin update 子指令，只有 add、list、marketplace、remove。
marketplace upgrade 只重抓 marketplace 快照，而 jsc 的 marketplace.json 只列各
網域的 git URL、不含版本，內容不會變，codex 一律回「already up to date」並結束碼 0。
已安裝外掛的版本在 plugin add 當下決定，快取不會被連帶重抓。結果是十個網域裡八個
版本完全沒動，指令卻全部成功——只看結束碼會判定成功，是最難察覺的那種失敗。
實機驗證過：更新前 review 是 0.0.2，跑完 marketplace upgrade 仍是 0.0.2。
How：update 分支照 install 的寫法逐網域跑 plugin add。實測 codex 的 add 會就地
升級到快照裡的最新版（review 0.0.2 升到 0.0.5），不需要先 remove。同時在函式上方
寫明這個限制與理由，避免後人再把那一行當成多餘的重複而刪掉。
Who：跨 CLI 技能組批次部署。
|
2026-08-27 10:28:10 +08:00 |
|
|
jiantw83
|
49cd4d3ee4
|
fix(deploy): 修正 domain 前綴歧義與 kiro-cli 探測
What: deploy.sh 收到帶 jsc- 前綴的 domain 名時自動去掉前綴再組 jsc-{domain}@jsc；deploy_kiro 先探測這個版本的 kiro-cli 認不認得 plugin 子指令，不認得就整批直接走本地複製退路。
Why: marketplace.json 的 plugins[].name 本身就帶 jsc- 前綴，SKILL.md 只寫「domain 名單來自 marketplace」沒講清楚要不要去前綴，實際執行時餵進去兜成 jsc-jsc-ask@jsc 雙重前綴，claude、copilot、antigravity、kiro 四支 CLI 的更新全部第一輪失敗。另外 kiro-cli 2.18.1 這個版本已經完全沒有 plugin 子指令，逐一嘗試再退回複製會先洗出一長串看似失敗、實則設計內的錯誤訊息。
How: 腳本層正規化 domain 參數（去前綴），比只改文件更可靠——不管呼叫端傳哪種格式都對。kiro 的探測用 kiro-cli --help-all 抓子指令清單，一次性判斷，不逐一撞錯誤才退回；探測本身不算部署動作，不印 cmd／exit。SKILL.md 同步補上前綴說明。
Who: jsc-cli:deploy 的執行正確性與輸出可讀性。
|
2026-08-26 11:30:18 +08:00 |
|
 jiantw83andClaude Opus 5
|
26ffaa8a07
|
fix(cli): 補齊稽核缺失並修掉護欄失效
What：依 jsc-meta:skill-check 的稽核結果修正技能與工具——補上每個步驟的可檢核完成條件、
把留在內文的標準輸入輸出流程下放 tools/、修正查表與退碼路由造成的誤判。
Why：稽核發現這些缺失會讓技能在實際執行時走錯分支或靜默通過。
完成條件缺漏是最常被違反的一項；退碼誤判與查表錯誤則會讓良性狀況被當成失敗。
How：逐項對照 references/guidelines.md 的審核檢查清單修正，新增的工具都有
documented exit codes，並以真實執行驗證每條路徑。
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 |
|