plugins/cli
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
122 Commits 10 Branches 0 Tags
62ea8022e09538d33e6912c1a28105b19fedcce5
Commit Graph
24 Commits
Author SHA1 Message Date
jiantw83 5b0eb784b4 fix(doctor,setup): 兩支技能補上路徑守則，呼叫一律字面絕對路徑 
這兩支技能的腳本呼叫原本全是裸相對路徑，整份文件沒有任何路徑守則。相對路徑會對著操作者當下的工作目錄解，而那裡從來不是外掛根目錄，所以每一個呼叫點都是模型就地猜前綴的地方。部署技能原本三處相對路徑被補成帶變數路徑，就是同一個機制。

實際掃到的處數比預估多：體檢 18 處、修復 20 處。多出來的是兩類原本沒想到的——裸檔名的 Gitea 呼叫，以及被當成參數傳的資料檔。後者同樣會解錯地方，而且解錯了不會報錯。

兩支各補路徑守則與前置步驟，解出兩條根目錄：跨外掛走 current 那一層（解到那一層就停，再往下解會落到帶版本號的快取路徑，那種路徑進不了允許清單），技能自己的腳本與範本走 CLI 載入技能時講明的外掛基底目錄。

兩支都不靠 current 底下那條 jsc-cli 連結，但理由各自不同，不是照抄部署那一支的。體檢不能靠，因為它正是機器可疑時才跑的技能——觸發時機本身就是連結可能出錯的那幾個時刻，而連結指著舊版時拿到的是舊的掃描腳本與舊的規格表，掃出來的每一列都像真的發現，不會有任何錯誤訊息。修復更不能靠，因為它寫檔，而且它要修的其中一列正是那個決定連結位置的變數：那種機器上根目錄根本解不出來，而修它要用的腳本掛在外掛基底目錄底下、不依賴那個變數，所以解不出來既不停這一輪也不擋那一項修復。何況拿舊的寫入腳本改設定檔，再用同一份舊腳本重驗，兩邊當然對得上，整輪會報成已修。

失敗分支也與部署不同。部署解不出根目錄就停手；這兩支都不停——體檢把它記成一項發現然後跑完不需要跨外掛的檢查，因為唯讀體檢中途停掉操作者什麼都拿不到；修復把它當成待修的那一項，修好再重解一次。

兩份範本與說明文件一併改。範本是這兩支技能在同一輪一起讀的，而且指示寫入，留著裸路徑等於留一個繞過新規則的入口。範本裡另外補掉兩個路徑洞：指向範本自己的佔位符原本沒有路徑，以及一個連目錄都沒有的裸檔名。

行為契約四列跟著改，並補上可稽核的跡象：回報裡的腳本路徑全是字面絕對路徑，跨外掛的路徑中間是 current 那一層而不是帶版本號的快取路徑。
 2026-09-03 13:07:07 +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 d5bc40be13 feat(wiki): 體檢目錄頁改條列式版面，鍵改用體檢頁頁名 
What：`templates/check-contents.md` 從 markdown 表格改成一台執行環境一個 H2 區塊，H2 標題就是那一台的體檢頁頁名 `CHECK_{HASH}`，原本的七個欄位改成標題底下一層 `- {欄位名}：{值}` 的條列，頁上不留任何表格。`skills/doctor/SKILL.md` 與 `skills/setup/SKILL.md` 對目錄頁的呼叫從 `wiki-contents.sh upsert CHECK 4 "{HASH}"` 改成 `upsert CHECK 1 "CHECK_{HASH}"`，`references/behaviors.md` 的關鍵步驟、完成條件與可驗證跡象，以及 `README.md` 的兩段技能敘述都跟著對齊。

Why：一列七格的表格，欄位一多就要橫向捲動，讀的人得先數欄位再對照表頭才知道哪一格是什麼；一筆一個 H2 區塊、每一條自己帶欄位名，掃過去就讀得懂。版面換成區塊之後鍵也得跟著換：表格時代的鍵是第 4 欄的裸 `HASH`，區塊沒有欄位可指，唯一能當鍵的是 H2 標題。key-col 與 key 沿用舊值會讓腳本比對不中，同一台機器每體檢一次就在頁尾多附一個區塊，舊區塊從此再也更新不到，而頁面看起來完全正常，錯得無聲無息。頁名只由 `{短主機名}/{登入帳號}` 決定，`GITEA_HOST` 換掉、`JSC_WIKI_REPO_CHECK` 搬到別的存取庫、Gitea 對頁名的編碼有差都動不到它，拿它當鍵比拿任何含網址的值都穩。

How：範本頁首的寫入語意從「一列」改寫成「一個區塊」，並補上四個參數的說明。第三個參數 `<key>` 收 H2 標題文字，也就是 `CHECK_{HASH}`；第四個參數收的是區塊檔而不是列檔，內容為 `## CHECK_{HASH}` 那一行、一個空行，再照範本的欄位順序每欄一條條列，`HASH` 那一欄照樣要寫，標題是鍵不代表欄位可以省，否則下一個讀的人讀不到。第二個參數 `1` 定位成 `<key-col>`，只在頁面還留著舊表格、需要自動轉檔時才用得到，指舊表格裡持有 `[CHECK_{HASH}](網址)` 的第 1 欄，轉檔時取那一格的文字當 H2 標題，頁面已經是條列格式就忽略它。「體檢頁」那一條維持 `[{文字}]({絕對網址})` 的人用連結寫法，H2 標題本身不放連結也不放網址。兩支技能的結束碼分流一併校正：`wiki-contents.sh` 的結束碼 1 從「寫入失敗」改寫成「組不出頁面內容或寫入失敗」，頁上找不到本機那一個區塊不算這一碼，腳本會改成附加。實際的轉檔與 upsert 邏輯都在 `jsc-gitea/tools/wiki-contents.sh`，這個存取庫只改敘述與範本。

Who：屬於「wiki 目錄頁改條列式呈現」這個需求落在 jsc-cli 的部分，也就是 `CHECK_CONTENTS` 這一型目錄頁的去表格化。內容頁維持圖表優先，不在這一輪範圍。
 2026-09-02 17:25:37 +08:00
jiantw83 fb80559159 feat(wiki): 體檢目錄頁改走專用存取庫，並補齊設定規格表 
What：CHECK_CONTENTS 改由 wiki-repo CONTENTS 解析並透過 wiki-contents.sh upsert
寫入，CHECK_{HASH} 仍走 wiki-repo CHECK。目錄頁新增一欄裸 HASH 當比對鍵。主機名
改由程式取短名，不再交給模型自由填。

Why：比對鍵原本是含網址的儲存格，換主機或換存取庫就比對不到，每跑一次體檢就替同一台
機器多附一列，畫面上還看不出來。主機名短名與 FQDN 不一致時，同一台機器會分裂成兩張頁，
而助理巡檢那邊是用程式取值的，兩邊對不起來。

How：設定規格表同一輪補齊三處既有缺漏——補上漏掉的 JSC_WIKI_REPO_MONITOR，體檢本來
看不到它而孤兒掃描還會誤報；刪掉指向不存在頁面的 MAINTAIN 內容頁字樣；MAINTAIN 那一列
改成不需要使用者處理，免得體檢叫人去設一支管不到任何頁的變數。整列保留，刪掉會讓孤兒
掃描開始誤報那個變數。

Who：jsc-cli
 2026-09-02 11:03:07 +08:00
jiantw83 5f1c4cc6d7 docs(deploy): 同步相依檢查改為照樣更新的行為 
What：SKILL.md 第 4 步改寫成四種結束碼的處置，第 7 步的回報清單補上 warn 行。README 的 check-requires.sh 表格列與 deploy 技能段落改寫成同一套說法。

Why：文件還寫著版本不符就跳過該 domain。操作者依文件預期那個 domain 不會動，實際上它已經更新，回報也對不上腳本印出來的行。

How：SKILL.md 逐一寫出 0、1、4、2 或其他四種結束碼各自的處置與理由，完成條件改成 skip 要有檢查腳本出錯或本地樹的原因、warn 要指名還缺哪一版。README 兩處改寫成同樣的四種分流，並寫明真正的阻擋在 version-guard.sh。

Who：相依版本不符的處置。
 2026-08-31 13:35:42 +08:00
jiantw83 8112905364 docs(cli): 把結束碼約定寫進腳本檔頭，README 跟著對齊 
detect-clis.sh 與 list-models.sh 一律回零：找不到執行檔，或讀不到設定檔，
都只是少掉那一列，不算失敗。這個約定過去只存在讀過腳本的人腦袋裡。
呼叫端很容易拿結束碼去判斷「這台機器有沒有裝 CLI」，然後永遠判斷錯。
現在把它寫在檔頭，兩支腳本的行為都不動。

README 的腳本表與技能說明同步更新，讀 README 的人看到的流程，才跟技能
裡實際寫的一致。
 2026-08-31 11:09:59 +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 284292ffcb docs(deploy): 部署說明同步一支 CLI 一份的重啟狀態檔 
What：`README.md`「部署留在機器上的檔案」那張表，`$JSC_HOME/restart-required` 那一列改成 `$JSC_HOME/restart-required.d/{cli}`，寫明一支 CLI 一份、內容是四行 key=value，以及路徑與格式的唯一來源在 `jsc-hooks/hooks/restart-gate.sh`。`skills/deploy/SKILL.md` 第 9 步的路徑說明同步改寫，補上「每支 CLI 只讀自己那一份」與「重啟一支只清自己那份、別支的閘門還立著」，全篇維持英文。

Why：這兩份說的是同一件事在不同讀者面前的樣貌——README 給看存取庫的人，技能文件給執行部署的模型。收尾提示裡的路徑是操作者唯一會拿到的線索，寫成舊的單一檔案就對不上機器上的實況，也會讓人以為重啟一支就把全部閘門解除了，那正是這一輪要修掉的錯誤認知。

How：只改說明，第 9 步的完成判準與那句固定的重啟指示都不動。舊表格那一列原本寫「一行一次成功部署」，其實是四行 key=value 的狀態檔，這次一併訂正。路徑與格式指回 `restart-gate.sh`，兩個存取庫不各自維護一份格式說明。

Who：`jsc-cli` 的存取庫說明與 `jsc-cli:deploy` 技能文件，對齊 `jsc-hooks` 的重啟狀態檔設計。
 2026-08-27 18:49:58 +08:00
jiantw83 afc4c5b50a docs(cli): README 補上兩份指引、重啟狀態檔與新增環境變數 
What：`README.md` 四處增修。工具表新增 `tools/write-guides.sh` 一列，`tools/deploy.sh` 那一列補上收尾寫重啟狀態檔與 `restart` 行；環境變數表新增 `JSC_HOME` 與 `JSC_RESTART_GATE` 兩列；新增「部署留在機器上的檔案」一節，用表列出三個檔案的產生時機與用途，並寫明兩份指引一律整份覆寫、`uninstall` 兩者都不產生。

Why：部署會在機器上留下三個檔案，這件事原本 README 一個字都沒寫。操作者不知道更新與移除的依據就在 `$JSC_HOME` 底下，也不知道 `restart-required` 存在代表什麼，只能去讀腳本註解。

How：三個檔案併成一張表，欄位是「何時產生」與「用途」，讓人一眼分得出哪些是可以放心刪的（指引重跑就有）、哪些有判定意義（重啟狀態檔）。閘門的判讀與逃生門明寫在 `jsc-hooks` 那一邊，`jsc-cli` 只負責寫狀態檔，避免兩份文件各寫一套判定規則。

Who：讀 `jsc-cli` 說明的操作者，以及要手動更新或移除技能組的人。
 2026-08-27 16:34:16 +08:00
jiantw83 e655f9a963 feat(setup): 新增引導與自動設定技能 
What: 新增 jsc-cli:setup，讀 doctor 的待修清單逐項確認後修復，並新增 tools/apply-config.sh 負責實際寫入。
Why: 體檢找得出問題，修還是得靠人一個一個查文件。修法又分三種：算得出來的、要人給值的、只能手動的，混在一起講不清楚。
How: 依規格表的 fix 欄分流，auto 直接寫、ask 先用決策樹問到值、manual 印步驟。複合修復交回原主（deploy、hooks-install、models）。apply-config.sh 只動 rc 檔的 # jsc-config 標記段落，寫前備份到 $JSC_HOME/backup/config/，寫後重讀驗證，fish 自動改用 set -gx 語法。
Who: 體檢與修復流程，接在 jsc-cli:doctor 之後。
 2026-08-26 10:43:50 +08:00
jiantw83 17329a94d3 feat(cli): 新增 delegate 子代理技能 2026-08-25 16:56:22 +08:00
jiantw83andClaude Opus 5 a739ae20f8 docs(cli): 同步文件與參考資料 
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 de1b9ad8a8 docs(README): 同步 deploy 的版本比對與推薦邏輯 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 13:03:17 +08:00
jiantw83andClaude Opus 5 8adff2535f refactor(marketplace 正本): deploy 的 domain 清單改讀 plugins/meta 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 18:00:35 +08:00
jiantw83andClaude Opus 5 c30dd61984 docs(README): 補上 model-tags.sh 與能力標籤閘門的說明 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 16:05:06 +08:00
jiantw83 f2029d4cd0 feat(cli): 新增 model-config.sh 的 resolve 子指令 
What:
在 `tools/model-config.sh` 新增 `resolve {stage}` 子指令。這個指令會取出某個 SDLC 階段的模型鏈（跟 `get {stage}` 用同樣的解析規則：先讀專案的 `.jsc/models`，找不到再讀 `$JSC_HOME/models.conf`），然後印出鏈中第一個模型名稱，當作目前這個 CLI 可用的模型。同時新增 `current_cli()` 這個輔助函式，透過各家 CLI 的環境變數，判斷目前是在 claude、codex、copilot、antigravity、還是 kiro 底下執行。這個版本先把 `current_cli()` 的結果記錄下來，還沒有拿它去過濾模型鏈中不可用的模型，這件事留到之後再做，因為要判斷某個模型是否可用，需要 LLM 層級的判斷，不是單純的 shell script 能做到的。之後的計畫是拿 `current_cli()` 的結果，對照 `references/model-tags.md` 和 `detect-clis.sh`，跳過模型鏈裡不可用的模型。另外，把 README.md 裡 `tools/model-config.sh` 的工具說明表格，加上新的 `resolve {stage}` 子指令說明。版本號也從 0.0.2 升到 0.0.3，同步改了 `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 這三份清單檔，這是這個 repo 的慣例：新增功能時要一併升版號。

Why:
jsc-meta:skill-check 這次稽核發現，jsc-sdlc 底下 plan、analyze、implement、maintain 這四個階段的技能，各自都要幫自己的階段挑一個模型，來做 gate check。如果沒有 `resolve` 這個子指令，這四個技能就要各自在技能說明裡，重複寫一次「讀模型鏈、選一個候補模型」的邏輯。這樣容易寫錯，也難維護。

How:
在既有的 `get`/`list` 邏輯基礎上，加一個 `resolve` 子指令，直接回傳模型鏈的第一個模型。同時加上 `current_cli()`，先把偵測 CLI 的能力做出來，但先不接上過濾邏輯，用註解說明後續要怎麼接。文件和版本號一併更新。

Who:
這個功能是給 jsc-sdlc 的四個階段技能（plan、analyze、implement、maintain）用的。它們可以直接呼叫 `resolve {stage}`，取得一個可用的模型名稱，不用各自重複寫模型鏈的判斷邏輯。
 2026-08-24 14:49:28 +08:00
jiantw83andClaude Fable 5 072e01821b docs(models): 補上角色式模型路由文件與階段指定模型輸出表 
What：references/model-tags.md 新增「階段指定模型（角色式路由）」章節，說明設定格式、檔案優先序與遞補鏈語意；skills/models/SKILL.md 的 description 與步驟加入 model-config.sh list 的「階段指定模型」輸出表（stage、指定鏈、source 三欄）；README.md 補上 tools/model-config.sh 工具列與 models 技能說明。
Why：角色式模型路由需要文件明確定義設定格式與判定順序，jsc-sdlc 閘門與使用者才知道指定模型優先、標籤比對為備援。
How：設定格式 stage=model[,fallback...]；優先序為專案 .jsc/models 覆寫 $JSC_HOME/models.conf；解析一律透過 jsc-cli/tools/model-config.sh，不自行讀檔；models 技能輸出表未設定的階段以「-」表示。
Who：models 技能的使用者與依賴模型閘門的 jsc-sdlc 各階段技能。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-24 11:36:45 +08:00
jiantw83andClaude Fable 5 fa95753afa style(cli): 中文並列改頓號 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:29:45 +08:00
jiantw83andClaude Fable 5 0e51ce8d1a docs(cli): README 安裝/更新/移除改為每指令一行（五個 CLI）並為相關 domain 加上 repo 連結 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:03:33 +08:00
jiantw83andClaude Fable 5 3f03cb14e1 docs(cli): 以統一格式改寫繁體中文 README 與 AGENTS 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 13:08:43 +08:00
jiantw83 2c2efb72ae Initial commit 2026-08-21 04:42:50 +00:00