 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 |
|