 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 |
|
admin
|
07c1c44e5a
|
Merge pull request 'doctor 與 setup 補上路徑守則,腳本呼叫一律改成字面絕對路徑' (#63) from fix/literal-paths-for-doctor-and-setup into develop
Reviewed-on: #63
|
2026-09-03 05:35:25 +00:00 |
|
jiantw83
|
56dbffa25c
|
chore(plugin): 三份 manifest 升版至 0.3.4
兩支技能的路徑守則要靠版號才傳得到機器端。
三份 manifest 由 sync-skill-manifest.sh 同步,只動版本欄位。
|
2026-09-03 13:07:07 +08:00 |
|
jiantw83
|
5b0eb784b4
|
fix(doctor,setup): 兩支技能補上路徑守則,呼叫一律字面絕對路徑
這兩支技能的腳本呼叫原本全是裸相對路徑,整份文件沒有任何路徑守則。相對路徑會對著操作者當下的工作目錄解,而那裡從來不是外掛根目錄,所以每一個呼叫點都是模型就地猜前綴的地方。部署技能原本三處相對路徑被補成帶變數路徑,就是同一個機制。
實際掃到的處數比預估多:體檢 18 處、修復 20 處。多出來的是兩類原本沒想到的——裸檔名的 Gitea 呼叫,以及被當成參數傳的資料檔。後者同樣會解錯地方,而且解錯了不會報錯。
兩支各補路徑守則與前置步驟,解出兩條根目錄:跨外掛走 current 那一層(解到那一層就停,再往下解會落到帶版本號的快取路徑,那種路徑進不了允許清單),技能自己的腳本與範本走 CLI 載入技能時講明的外掛基底目錄。
兩支都不靠 current 底下那條 jsc-cli 連結,但理由各自不同,不是照抄部署那一支的。體檢不能靠,因為它正是機器可疑時才跑的技能——觸發時機本身就是連結可能出錯的那幾個時刻,而連結指著舊版時拿到的是舊的掃描腳本與舊的規格表,掃出來的每一列都像真的發現,不會有任何錯誤訊息。修復更不能靠,因為它寫檔,而且它要修的其中一列正是那個決定連結位置的變數:那種機器上根目錄根本解不出來,而修它要用的腳本掛在外掛基底目錄底下、不依賴那個變數,所以解不出來既不停這一輪也不擋那一項修復。何況拿舊的寫入腳本改設定檔,再用同一份舊腳本重驗,兩邊當然對得上,整輪會報成已修。
失敗分支也與部署不同。部署解不出根目錄就停手;這兩支都不停——體檢把它記成一項發現然後跑完不需要跨外掛的檢查,因為唯讀體檢中途停掉操作者什麼都拿不到;修復把它當成待修的那一項,修好再重解一次。
兩份範本與說明文件一併改。範本是這兩支技能在同一輪一起讀的,而且指示寫入,留著裸路徑等於留一個繞過新規則的入口。範本裡另外補掉兩個路徑洞:指向範本自己的佔位符原本沒有路徑,以及一個連目錄都沒有的裸檔名。
行為契約四列跟著改,並補上可稽核的跡象:回報裡的腳本路徑全是字面絕對路徑,跨外掛的路徑中間是 current 那一層而不是帶版本號的快取路徑。
|
2026-09-03 13:07:07 +08:00 |
|
admin
|
45187f5173
|
Merge pull request '部署收尾刷新 current 連結農場,讓升版後的技能路徑不再指著舊版' (#61) from feat/refresh-current-link-farm-on-deploy into develop
Reviewed-on: #61
|
2026-09-03 04:40:24 +00:00 |
|
jiantw83
|
47f248adec
|
chore(plugin): 三份 manifest 升版至 0.3.3
連結農場的刷新要靠版號才傳得到機器端。
三份 manifest 由 sync-skill-manifest.sh 同步,只動版本欄位。
|
2026-09-03 12:19:59 +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 |
|
admin
|
253443e94e
|
Merge pull request 'deploy 的腳本呼叫全改成字面絕對路徑,開頭解一次根目錄,無人看管的輪次不再停在第一支腳本' (#59) from fix/literal-absolute-paths-for-deploy into develop
Reviewed-on: #59
|
2026-09-03 02:52:09 +00:00 |
|
jiantw83
|
bd23690aa5
|
chore(plugin): 三份 manifest 升版至 0.3.2
三份外掛 manifest 的版本欄從 0.3.1 升到 0.3.2,內容由同步腳本產生,其餘欄位未動。
deploy 技能的路徑守則與 Step 0 已經改完,版號要跟著動,版本守衛才判定得出這台機器落後,更新輪次才會把新的技能內容拉下來。
交給 manifest 同步腳本一次寫三份,避免三份手改而版號不一致。
影響每一台裝了這組技能的機器:版本比對與部署更新都讀這個欄位。
|
2026-09-03 10:33:30 +08:00 |
|
jiantw83
|
b41ceb00d9
|
fix(deploy): 腳本呼叫改成字面絕對路徑,開頭先解一次根目錄
技能文件新增路徑守則一節,寫明這支技能的每一次腳本呼叫都要是字面絕對路徑,不留未展開的變數,也不留波浪號。
新增 Step 0:開頭跑一次 readlink -f "$JSC_HOME/current" 解出根目錄,整輪只解這一次,之後每一處都把代稱換成那個目錄。解出來的路徑要用 [ -d ] 查過存在才算數——JSC_HOME 沒設時那道指令會印出 /current、結束碼 0,非空又是絕對路徑,只看前三項會直接放行,而那個目錄並不存在。文件同時明講解到 current 這一層就停,不要再往下解一層,因為再解就落到帶版本號的快取路徑,而那種路徑放不進允許清單。
四處跨外掛呼叫改成字面路徑寫法。其中三處原本寫成相對路徑,那才是模型自己補成帶變數路徑的源頭。技能自己的四支腳本另外處理:jsc-cli 不在 current 底下,那裡只有另外三個外掛,所以改用 CLI 載入技能時講明的外掛基底目錄,原樣照抄、不跑指令。
無人看管的輪次在第一支腳本就被權限層擋下,整輪一個外掛都沒部署。2026-09-02 到 09-03 用非互動模式比照排程環境實測多種寫法:權限層拿未展開的字面字串做靜態比對,帶變數或波浪號的路徑對不上任何允許規則,只有允許清單上的完整字面指令跑得動,連 readlink、ls 這種讀取指令都要各自有規則。放寬允許清單解不掉,因為規則本身也是靜態比對,而且路徑中段的萬用字元不匹配。
deploy 是人在現場跑的技能,開頭那一次核准詢問有人可以按,所以保留自己解路徑的做法。守則另外寫下一句擋回頭路:為了看起來整齊而把字面路徑改回帶變數的寫法,等於再一次弄壞每一個無人看管的輪次。
行為說明表的 deploy 四列同步改寫,觸發時機沒動。
影響排程觸發的無人看管輪次,它們現在才跑得完第一支腳本。現場執行部署的操作者只多出開頭那一次核准詢問。
|
2026-09-03 10:33:30 +08:00 |
|
admin
|
9d0e1ea3dd
|
Merge pull request '體檢目錄頁改成大標題加條列,doctor 與 setup 的呼叫同步換鍵' (#58) from feat/contents-list/main into develop
Reviewed-on: #58
|
2026-09-02 10:00:37 +00:00 |
|
jiantw83
|
4479a090a6
|
chore(plugin 版本): 三份 manifest 升版至 0.3.1
What:`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 三份 manifest 的 `version` 從 `0.3.0` 升到 `0.3.1`,三份一起改、值保持一致,其餘欄位一個字都不動。
Why:版本號是 `jsc-hooks/hooks/version-guard.sh` 判斷機器上的 plugin 落後與否的唯一依據。目錄頁的版面與鍵已經換過,版本號不動的話 version-guard 會把機器上的舊版當成最新版,`jsc-cli:doctor` 不會把它列進待修項目,那台機器就繼續留著以裸 `HASH` 當鍵的舊敘述,寫出來的目錄頁跟新範本對不上。三份分別給不同 CLI 讀,只升其中一份會讓同一支 plugin 在不同 CLI 上報出不同版本,落後判斷跟著失準。
How:只改 `version` 這一個鍵,走修訂號一階。這一輪是既有頁面型別的呈現方式調整,沒有新增技能,也沒有改動任何腳本的呼叫介面,不到次版本號的幅度。三份的值刻意保持一致,version-guard 才比得出單一結論。
Who:屬於「wiki 目錄頁改條列式呈現」這個需求的發版收尾,與同一輪的敘述與範本改動配成一套。獨立成一個 commit 的理由是型別不同:這一組是 chore 而非 feat,改動的檔案與敘述那一組完全不重疊,版號要重切或回退時也不必動到行為契約。
|
2026-09-02 17:25:37 +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 |
|
admin
|
8444307534
|
Merge pull request '收尾寫一筆 skill-end 事件,執行狀態才回報得到助理' (#57) from feat/status-report into develop
Reviewed-on: #57
|
2026-09-02 08:04:20 +00:00 |
|
jiantw83
|
db2a2f8206
|
chore(plugin 版本): 三份 manifest 升版至 0.3.0
|
2026-09-02 16:01:14 +08:00 |
|
jiantw83
|
03e59c69bd
|
feat(狀態回報): 收尾寫一筆 skill-end 事件
現行紀錄只記「被叫用」,沒有成敗也沒有結束碼。跑完整輪的技能與開場就
中止的技能,在紀錄裡長得一模一樣。
start 由技能用量 hook 順手發,不必改技能文件。end 只能由技能自己在收尾
步驟寫——hook 接在技能工具呼叫上,而實際工作發生在之後的模型輪次,它在
原理上看不到成敗。有 start 沒有配對的 end,就是那一輪中止了。
status 五選一,每支技能各自寫明什麼情況選哪一個。找不到回報腳本就安靜
跳過,回報失敗一律不改變技能自己的結論。
|
2026-09-02 16:01:14 +08:00 |
|
admin
|
936fc5cdaa
|
Merge pull request '連結一律寫成 [文字](絕對網址),並在寫入前驗證連得到' (#56) from feat/link-verification/main into develop
Reviewed-on: #56
|
2026-09-02 06:46:45 +00:00 |
|
jiantw83
|
9f4ed977b2
|
chore(plugin 版本): 三份 manifest 升版至 0.2.9
|
2026-09-02 14:27:18 +08:00 |
|
jiantw83
|
c76daa61ca
|
feat(link): 連結一律寫成 [文字](絕對網址),寫入前先驗證連得到
取消 [[頁名]] 與 [[顯示文字|頁名]] 兩種同 wiki 寫法,不再分「同存取庫」與
「跨存取庫」兩條規則。那種寫法只在自己那個 wiki 內解析,寫錯不報錯,畫面上
看起來像普通文字或死連結,巡不到也修不了。
連結寫進頁面前先過 jsc-gitea 的 link-check.sh,結束碼 0 才寫。驗證一律走 API,
不看網頁狀態碼:私有存取庫的網頁網址對未登入請求一律回 404,拿狀態碼判會把
好連結判成壞的。認證失敗回 7,與死連結的 1 分開,免得金鑰一過期就把還在的頁
整批判死。
|
2026-09-02 14:27:18 +08:00 |
|
admin
|
86225f355f
|
Merge pull request 'feat(wiki): 體檢目錄頁改走專用存取庫,並補齊設定規格表' (#54) from feat/wiki-contents-repo/main into develop
Reviewed-on: #54
|
2026-09-02 03:27:54 +00: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 |
|
admin
|
225e33d2c8
|
Merge pull request '放行 jsc-assist 的 marketplace 條目到預設分支' (#52) from chore/marketplace-assist-registry/main into develop
Reviewed-on: #52
|
2026-09-01 04:55:09 +00:00 |
|
admin
|
214b8a22c5
|
Merge pull request 'chore/marketplace-assist-registry/sync-copies' (#51) from chore/marketplace-assist-registry/sync-copies into chore/marketplace-assist-registry/main
Reviewed-on: #51
|
2026-09-01 04:52:42 +00:00 |
|
jiantw83
|
e87d6b36fe
|
chore(marketplace): 把 jsc-assist 登錄進統一 marketplace
What:
- 兩份 marketplace 檔各加一個 jsc-assist 條目,來源網址指向 assist 存放庫。
Why:
- 準則要求每個 domain 存放庫都帶同一份 marketplace 檔,任何一個存放庫都能當註冊入口。副本之間只要有一份沒跟上,稽核就會報出不一致。
- 正本少了這個條目,各 CLI 的安裝指令就找不到 jsc-assist,這個 domain 等於發佈不出去。
How:
- 條目由 meta 的 sync-marketplace.sh 產生,同時寫進正本與每個 domain 存放庫的副本,寫完逐檔比對位元組。這一支存放庫的兩份副本就是那一輪的產物。
- 條目依名稱排序,縮排與非 ASCII 描述的處理都交給同一支腳本,不手改 JSON。
- 這一批是從最新的預設分支重新產生的。前一輪的分支基底早於監控頁型別那批改動,直接合併會把那些改動回退掉,所以整批重做而不是解衝突。
Who:
助理 domain 落地的註冊步驟在這個存放庫的同步。
|
2026-09-01 12:50:04 +08:00 |
|
jiantw83
|
36e1bebe1f
|
Merge pull request '收攏 models 技能的 frontmatter 語法修正' (#48) from feat/cli-hook-rewire/main into develop
|
2026-09-01 00:58:39 +00:00 |
|
jiantw83
|
749b1ad6d3
|
Merge pull request '修正 models 技能 SKILL.md frontmatter 的 YAML 純量語法' (#47) from feat/cli-hook-rewire/quote-description into feat/cli-hook-rewire/main
|
2026-09-01 00:56:08 +00:00 |
|
jiantw83
|
daa4bcf9e1
|
fix(frontmatter): 修正 models 技能 SKILL.md frontmatter 的 YAML 純量語法錯誤
What:
- 修正 skills/models/SKILL.md frontmatter 裡 description 欄位的 YAML 語法錯誤。
- 整串 description 加上單引號,內部撇號改寫成兩個單引號,內容文字一個字都沒變。
- 同步更新 plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三個 manifest 版本號,從 0.2.6 進到 0.2.7。
Why:
- description 內含「冒號加空白」,屬於未加引號的 YAML plain scalar,違反 YAML 語法規定。
- Antigravity 解析 frontmatter 時當場中斷,整支技能被靜默丟棄,沒有任何錯誤訊息;磁碟上 34 支技能,Antigravity 只認得 28 支。
- 準則要求 description 用英文撰寫,不能把「: 」改成全形冒號迴避語法問題,只能加引號修正。
How:
- 整串 description 值加上單引號,內部撇號寫成兩個單引號跳脫,其餘字元不動。
- 用 git show HEAD: 取出改前的原始值,把改後的單引號純量還原後做字串相等比對,確認逐字相同、字元數一致。
- 執行 ste100-lint.sh、check-behaviors.sh、lint-frontmatter.sh 三支檢查腳本,退出碼皆為 0;git diff --numstat 顯示只動了 frontmatter 那一行。
Who:
- 本次修到 cli 技能組的 models 技能,屬盤點各 CLI 可用模型與能力標籤的功能。
|
2026-08-31 19:02:43 +08:00 |
|
jiantw83
|
7d58afa2ee
|
Merge pull request '收攏技能行為清單與相依版本阻擋改動' (#45) from feat/skill-behaviors-and-version-block/main into develop
|
2026-08-31 08:10:33 +00:00 |
|
jiantw83
|
b5d72f5245
|
Merge pull request '相依版本不符改為照樣更新並提醒、新增技能行為清單' (#44) from feat/skill-behaviors-and-version-block/deploy-requires-warn into feat/skill-behaviors-and-version-block/main
|
2026-08-31 08:09:19 +00:00 |
|
jiantw83
|
99e0554995
|
chore(plugin): 版號升到 0.2.6
What:plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 的 version 從 0.2.5 改成 0.2.6。
Why:這一輪改了相依檢查的結束碼與部署時的處置,外部行為跟 0.2.5 不同。三份 manifest 是版本檢查與部署推薦的依據,版號不動,version-guard.sh 就看不出這台機器該更新。
How:三份檔案只改 version 一個欄位,其餘內容不動,三份保持同一個版號。
Who:版號發布。
|
2026-08-31 13:35:43 +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
|
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
|
4ed0bf11a2
|
fix(check-requires): 分開相依不符與判不出結論的結束碼
What:把原本的結束碼 1 拆成兩個。1 只代表相依版本不符或缺相依 plugin。新增 4 代表判不出結論,成因是 manifest 不存在、不是有效 JSON、或缺 python3。這三種成因的輸出從 status=blocked 改成 status=unknown。
Why:兩種成因共用同一個結束碼,呼叫端就只能用同一句話講兩件事。環境壞掉會被講成版本落後。操作者照著去補版本,補到最後也碰不到真正的問題點。
How:找不到 manifest、找不到 python3、JSON 解析失敗三處改回傳 4,狀態字串一併改成 unknown。檔頭的輸出格式表與結束碼表跟著改寫,並寫下 1 與 4 分開的理由。
Who:相依檢查結論分流。
|
2026-08-31 13:35:41 +08:00 |
|
jiantw83
|
76b3f2dcb6
|
docs(references): 新增五支技能的行為清單作為驗證基準
What:新增 references/behaviors.md。這一頁列出 delegate、deploy、doctor、models、setup 五支技能的行為。每支技能記錄觸發時機、關鍵步驟、外部呼叫、完成條件、可驗證跡象五個項目。
Why:技能驗證以前沒有共同基準。驗證的人只能自己讀 SKILL.md 反推該有哪些行為,兩個人推出來的結果不會一樣。有了這一頁,驗證就比對同一份基準。
How:一支技能一個章節,章節內用一張兩欄表格寫滿五個項目。外部呼叫欄位寫出腳本路徑與子命令,可驗證跡象欄位寫出實際會被改動的檔案或目錄。頁首寫明規則:技能異動時,要在同一個 PR 內一起更新這一頁。
Who:技能驗證基準。
|
2026-08-31 13:35:40 +08:00 |
|
admin
|
8d17f231cf
|
Merge pull request 'fix/skill-check-compliance-and-flow' (#42) from fix/skill-check-compliance-and-flow into develop
Reviewed-on: #42
|
2026-08-31 03:19:16 +00:00 |
|
jiantw83
|
f19b9494b4
|
chore(cli): 補上 jsc-ask 相依宣告並推進版本
delegate 與 setup 都靠決策樹問使用者,deploy 問部署模式也是。這份相依
過去沒有寫進 manifest,安裝順序沒排對,就會執行到一半才失敗。現在三份
manifest 都補上這一項,更新前的相依檢查才擋得住。同時做一次版本推進,
讓已發佈版本對得上這一輪的內容。
|
2026-08-31 11:09:59 +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
|
e30bbf5780
|
feat(cli): 待修項目合併收成共用腳本,檢查改為併行
「待修項目」表原本由 doctor 與 setup 各寫一次。同一套合併與排序規則寫在
兩個地方,遲早各自漂移:一邊改了排序,另一邊漏掉一整類項目,而且沒有
任何地方看得出來。現在規則只留一份,兩支技能都呼叫它。輸入與輸出都是
TSV,一項都沒有時照樣印一列,呼叫端永遠有東西可以呈現。
doctor 的四項檢查彼此不共用資料,排成一列跑只是把等待時間乘上四倍,
現在同時啟動。doctor 呼叫接線腳本一律帶唯讀旗標,把「打錯一個子命令就
改到或刪掉檔案」的風險移進程式層,不再只靠指令打對。
deploy 的 CLI 偵測、版本結論與 marketplace 清單同樣互不相干,改成併行
取得。版本結論改讀版本守門腳本的單行結論,不再自己從表格推導。setup 把
已經確認過的模式與版本報告直接交給 deploy,操作者不必再答一次同樣的問題。
deploy、doctor、models 都補上結束碼分流:腳本回什麼碼就走哪條路,不再從
輸出內容猜。體檢目錄頁改成先讀回再更新自己那一列,整頁覆蓋會把別台機器
的紀錄一次抹掉。設定規格表補上技能盤點頁要用的環境變數,盤點頁才有地方
可寫。
|
2026-08-31 11:09:59 +08:00 |
|
jiantw83
|
e8bf4ddaaf
|
fix(cli): 分開「模型不合格」與「腳本被叫錯」的結束碼
model-tags.sh 的 gate 原本用同一個結束碼表示兩件事:模型缺能力標籤,
以及這支腳本被叫錯。delegate 讀到用法錯誤時,會當成模型沒通過檢查,
默默把一個能用的模型丟掉。真正的錯在哪,永遠不會浮出來。現在用法錯誤
改走另一個碼,兩種「無法判定」也歸到同一個碼,呼叫端只要認碼就分得出
三種結果。model-config.sh 照同一套規則調整,兩支腳本的契約才一致。
check-requires.sh 在沒有 python3 的機器上,會直接讓 shell 回一個沒宣告過
的碼,呼叫端讀不到原因。現在先確認 python3 在不在,並印出擋下的理由,
manifest 相依檢查才是真的做得到的事。
delegate 的七個步驟原本沒有任何完成條件,引用了不存在的 plugin,也把
CLI 偵測與標籤篩選寫成文字敘述,可是這兩件事早就有腳本負責。挑模型那
一步需要模型 id,全篇卻沒有任何步驟產得出來。現在每一步都寫出完成條件,
資料一律取自腳本,模型夠不夠格由結束碼判定,不讓模型自評標籤。
setup 的環境變數重驗原本去讀目前這個 shell。可是寫進 rc 檔的值,要等新的
shell 起來才存在,所以重驗永遠回報「沒設到」,把修好的項目誤判成失敗。
現在只驗 rc 段落裡確實有那一行,環境層面交給下一次體檢。
|
2026-08-31 11:09:59 +08:00 |
|
admin
|
369e6e59f6
|
Merge pull request 'fix(codex-deploy): 保留 CLI 自身快取相容路徑' (#40) from fix/codex-cli-cache-compat into develop
Reviewed-on: #40
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
|
2026-08-28 10:32:38 +00:00 |
|
jiantw83
|
5e4c413dec
|
fix(codex-deploy): 保留 CLI 自身快取相容路徑
|
2026-08-28 18:31:04 +08:00 |
|
admin
|
ca58604afc
|
Merge pull request 'fix(codex-deploy): 保留舊 hooks 快取相容路徑' (#38) from fix/codex-cache-compat into develop
Reviewed-on: #38
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
|
2026-08-28 10:24:54 +00:00 |
|
jiantw83
|
90b89047e3
|
fix(codex-deploy): 保留舊 hooks 快取相容路徑
|
2026-08-28 18:18:28 +08:00 |
|
admin
|
fc446bfe55
|
Merge pull request 'feat/plugin-dependencies/main' (#35) from feat/plugin-dependencies/main into develop
Reviewed-on: #35
|
2026-08-28 04:04:53 +00:00 |
|
admin
|
3833055499
|
Merge pull request 'feat/plugin-dependencies/declare-requires' (#34) from feat/plugin-dependencies/declare-requires into feat/plugin-dependencies/main
Reviewed-on: #34
|
2026-08-28 04:02:56 +00:00 |
|
jiantw83
|
4aa691a9cb
|
feat(deploy): update 前檢查 jsc requires 相依版本
|
2026-08-28 11:59:16 +08:00 |
|
jiantw83
|
a89484c9fa
|
feat(manifest): 宣告部署工具相依版本
|
2026-08-28 11:59:16 +08:00 |
|
admin
|
c4e75f7f83
|
Merge pull request 'fix/deploy-hook-runtime-path' (#32) from fix/deploy-hook-runtime-path into develop
Reviewed-on: #32
|
2026-08-28 03:27:53 +00:00 |
|
jiantw83
|
382f946167
|
chore(release): 發布 jsc-cli 0.2.1
|
2026-08-28 11:22:13 +08:00 |
|
jiantw83
|
d918ccc6dc
|
fix(deploy): 優先從穩定路徑尋找重啟閘門
|
2026-08-28 11:22:08 +08:00 |
|