  jiantw83andClaude Opus 5
|
cd832460ee
|
fix(deploy): 本機複本一個 domain 一把鎖，重啟閘門不等整輪判定
實測踩到兩件事，同一輪、同一個根因。
那一份本機複本一台機器只有一份，而技能規定五支 CLI 平行部署——平行是對的，
它們寫的是不同的外掛目錄。但複本不是：五支都會來 pull 同一個目錄，連只需要
讀 manifest 的那幾支也會（相依檢查從那裡讀）。git 對同一個存取庫的併發寫入
沒有保護，於是同一輪裡兩支撞在一起，一支拿不到 ORIG_HEAD.lock、一支的遠端
refs 換不上去。
後果是最難查的那一種：兩支的整輪判定都變成 fail，而外掛其實全部裝好了——
報告說失敗、實際成功，而真正的原因跟部署無關。
改成一個 domain 一把 mkdir 鎖：那是檔案系統這一層唯一原子的建立動作。等不到
就印一行 warn 改用磁碟上的內容，別人正在拉同一份，硬等下去只是排隊。上一輪
中途死掉留下的鎖用年紀判，門檻放寬到等待秒數的四倍。
複本已經在磁碟上而 pull 拉不動的那一種，也改成只印 warn、不判整輪失敗：
內容在，只是可能比遠端舊。但一定要印出來——安靜地裝一份舊內容，是這一組
工具最怕的那種失效。clone 不存在那一種照舊算失敗，磁碟上根本沒東西可裝。
第二件事更嚴重。原本的寫法是「整輪判定成功才掛重啟閘門」，於是那一輪的
fail 把閘門一起跳過了：外掛換了一半，而唯一沒有被告知要重啟的，剛好就是
正在跑那份剛被換掉的程式碼的那一支 CLI。一道只在成功時才生效的提醒，在最
需要它的那一次不會出現。改成 install 與 update 一律先掛，再判 result。
順帶補一支安全截斷：訊息截長度用的是 cut -c，那數的是位元組，多位元組字
剛好被切成兩半會留一個替代字元，而亂碼不影響結束碼、沒有人會來報。
乾跑那一路一步都不動，連鎖都不取——取鎖是建目錄，那已經是寫入。原本改完
之後乾跑會真的去 pull，這一版修回來了。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-07 12:35:27 +08:00 |
|
|
jiantw83
|
a439636c4a
|
feat(deploy): 部署收尾刷新 current 連結農場
$JSC_HOME/current 是一組不帶版本的符號連結，每個外掛一條，指向快取裡帶版本號的實體目錄。技能文件裡所有跨外掛的腳本呼叫都以這一層為根，因為它不帶版本號、寫得進權限允許清單。
問題是沒有任何東西會更新這些連結，只有 wire-cli.sh 會更新 jsc-hooks 那一條。其餘幾條是人手動建的，建好之後就停在當時的版本。實際後果是部署完四個 domain 之後，快取裡是新版，連結卻還指著舊版：助理巡檢照文件的字面路徑跑，跑到的是舊腳本，而其中一個舊版底下根本沒有它要呼叫的檔案。失敗無聲，只有心跳停止，沒人盯就不會有人發現。
部署改成收尾時刷新整組連結。挑部署來做，是因為它本來就知道裝了哪些 domain、裝到哪個版本，資訊最齊。
四個設計決定：
基準 CLI 取 claude、codex、copilot、kiro 之中第一支找得到的，整輪只有那一支寫連結。連結農場只有一組，不可能同時指向五個 CLI 的副本；而五支 CLI 是平行跑的，五支都寫會互相覆寫，最後指到哪一份是隨機的、出事重現不出來。antigravity 一律不當基準，它的來源是本地 clone，而那份 clone 明文允許是維護者的開發樹，把全機器路徑指到做到一半的樹正好是這次要修的那種毛病。
版本目錄取版本排序最大、且真的有 plugin.json、且本身不是符號連結的那一層。要求 plugin.json 是因為裝到一半的目錄沒有它，挑到會讓連結指向不完整的外掛而且照樣不報錯。
解除安裝的判準是「連結還在、指向卻沒了」，不是「這輪解除安裝過這個 domain」。只解除安裝其中一支 CLI 時，連結可能還指著另一支手上完好的副本，那一條必須留著。
連結建立失敗印一行繼續，不記進失敗清單。這一段跑在外掛都裝好之後，部署本身已經成功；記成失敗會連帶跳過重啟閘門，操作者拿到的是一台明明裝好卻被說成失敗的機器。缺陷仍然看得見，因為輸出多了一行。
目標存在但不是符號連結時一律不覆寫，印 skip 要人工處理。ln -sfn 對著實體目錄下手會把連結建進那個目錄裡，農場當場壞掉還不會報錯。
新增 link 行讓呼叫端讀得到每一條連結指到哪裡，狀態五選一。技能文件與行為契約跟著更新，另修正一句因這次改動而失效的敘述：原本寫 current 底下沒有 jsc-cli，刷新之後那條連結會存在，改成講清楚它仍然靠不住，因為第一次建起它的正是這一輪。
|
2026-09-03 12:19:59 +08:00 |
|
|
jiantw83
|
ed4092bb3d
|
fix(deploy): 相依版本不符改成照樣更新並提醒
What：check_requires() 對 check-requires.sh 的四種結束碼重新分流。0 照常更新。1 改印一行 warn，該 domain 照樣更新，訊息寫出還缺哪一版。4 印一行 note，也照樣更新。2 或其他代碼維持印 skip、跳過該 domain，並記成失敗。
Why：跳過會讓落後的 domain 永遠等不到它要的相依版本，也就永遠更新不到，兩個 domain 互相等就形成死鎖。阻擋移到技能叫用那一層，由 jsc-hooks 的 version-guard.sh 執行，更新照跑不會壞事。判不出結論跟版本落後要講不同的話，混成一句會把環境問題誤導成版本問題。檢查腳本自己出錯是另一回事，讀不到結論就不能當成通過。
How：結束碼 1 的分支從印 skip、回傳 1 改成印 warn、回傳 0，結束碼 4 新增一個印 note、回傳 0 的分支，其餘代碼維持原本的 skip 與 FAILED。函式上方與檔頭補上這四條分流的理由。檔頭的輸出格式表補進 warn 與 compat 兩欄，結束碼說明也把 warn 列為不算失敗但要據實回報。
Who：相依版本不符的處置。
|
2026-08-31 13:35:41 +08:00 |
|
|
jiantw83
|
5e4c413dec
|
fix(codex-deploy): 保留 CLI 自身快取相容路徑
|
2026-08-28 18:31:04 +08:00 |
|
|
jiantw83
|
90b89047e3
|
fix(codex-deploy): 保留舊 hooks 快取相容路徑
|
2026-08-28 18:18:28 +08:00 |
|
|
jiantw83
|
4aa691a9cb
|
feat(deploy): update 前檢查 jsc requires 相依版本
|
2026-08-28 11:59:16 +08:00 |
|
|
jiantw83
|
d918ccc6dc
|
fix(deploy): 優先從穩定路徑尋找重啟閘門
|
2026-08-28 11:22:08 +08:00 |
|
|
jiantw83
|
98781a331f
|
fix(deploy): 部署工具的重啟狀態檔路徑改為一支 CLI 一份
What：`tools/deploy.sh` 的 `restart` 那一行改印 `$JSC_HOME/restart-required.d/{CLI 代號}`，檔頭註解一併改寫成「轉呼叫 `restart-gate.sh require` 掛上這支 CLI 的閘門」。`tools/write-guides.sh` 產生的更新指引，狀態檔說明改成一支 CLI 一份、重啟只清自己那份、別支的閘門不受影響。`tools/config-spec.tsv` 的 `$JSC_HOME/restart-required` 那一列改成 `$JSC_HOME/restart-required.d` 目錄，說明改為「該 CLI 那份不存在代表這支沒有待重啟的部署」。
Why：`jsc-hooks` 這一輪把狀態檔改成一支 CLI 一份，路徑從單一檔案變成狀態目錄底下的一份。`deploy.sh` 印的是操作者接下來要看的檔案路徑，印錯就指向一個不存在的檔案；`write-guides.sh` 寫出的更新指引是下一輪部署的依據，留著舊路徑會讓人以為刪掉那個檔案就能解除閘門；`config-spec.tsv` 是 `/jsc-cli:doctor` 比對設定落點的依據，路徑對不上就查不到這份執行期暫態。
How：三處都只跟著改路徑與說明，掛閘門的動作本來就是轉呼叫 `jsc-hooks` 的 `restart-gate.sh require`，這裡不重寫一份判定，也不自己組狀態檔內容——路徑與格式的唯一來源留在 `restart-gate.sh`。`config-spec.tsv` 那一列的型別仍是 `global` 的執行期暫態、備份與還原都維持 `none`，欄位數不變。
Who：`jsc-cli:deploy` 的部署收尾與更新指引，對齊 `jsc-hooks` 一支 CLI 一份的重啟狀態檔。
|
2026-08-27 18:49:58 +08:00 |
|
|
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 |
|