 jiantw83
|
5b0eb784b4
|
fix(doctor,setup): 兩支技能補上路徑守則，呼叫一律字面絕對路徑
這兩支技能的腳本呼叫原本全是裸相對路徑，整份文件沒有任何路徑守則。相對路徑會對著操作者當下的工作目錄解，而那裡從來不是外掛根目錄，所以每一個呼叫點都是模型就地猜前綴的地方。部署技能原本三處相對路徑被補成帶變數路徑，就是同一個機制。
實際掃到的處數比預估多：體檢 18 處、修復 20 處。多出來的是兩類原本沒想到的——裸檔名的 Gitea 呼叫，以及被當成參數傳的資料檔。後者同樣會解錯地方，而且解錯了不會報錯。
兩支各補路徑守則與前置步驟，解出兩條根目錄：跨外掛走 current 那一層（解到那一層就停，再往下解會落到帶版本號的快取路徑，那種路徑進不了允許清單），技能自己的腳本與範本走 CLI 載入技能時講明的外掛基底目錄。
兩支都不靠 current 底下那條 jsc-cli 連結，但理由各自不同，不是照抄部署那一支的。體檢不能靠，因為它正是機器可疑時才跑的技能——觸發時機本身就是連結可能出錯的那幾個時刻，而連結指著舊版時拿到的是舊的掃描腳本與舊的規格表，掃出來的每一列都像真的發現，不會有任何錯誤訊息。修復更不能靠，因為它寫檔，而且它要修的其中一列正是那個決定連結位置的變數：那種機器上根目錄根本解不出來，而修它要用的腳本掛在外掛基底目錄底下、不依賴那個變數，所以解不出來既不停這一輪也不擋那一項修復。何況拿舊的寫入腳本改設定檔，再用同一份舊腳本重驗，兩邊當然對得上，整輪會報成已修。
失敗分支也與部署不同。部署解不出根目錄就停手；這兩支都不停——體檢把它記成一項發現然後跑完不需要跨外掛的檢查，因為唯讀體檢中途停掉操作者什麼都拿不到；修復把它當成待修的那一項，修好再重解一次。
兩份範本與說明文件一併改。範本是這兩支技能在同一輪一起讀的，而且指示寫入，留著裸路徑等於留一個繞過新規則的入口。範本裡另外補掉兩個路徑洞：指向範本自己的佔位符原本沒有路徑，以及一個連目錄都沒有的裸檔名。
行為契約四列跟著改，並補上可稽核的跡象：回報裡的腳本路徑全是字面絕對路徑，跨外掛的路徑中間是 current 那一層而不是帶版本號的快取路徑。
|
2026-09-03 13:07:07 +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
|
2adf9a172e
|
feat(doctor): 新增執行環境體檢技能
What: 新增 jsc-cli:doctor，一次體檢技能版本、Hook 接線、全域設定與自我設定，只讀不改，結果寫進 wiki CHECK_{HASH}。
Why: 安裝或更新技能組之後，沒有任何工具說得出這台機器還缺什麼。設定散在環境變數、rc 檔與專案目錄，出錯時只能一個一個猜。
How: 版本比對複用 jsc-hooks 的 version-guard.sh report，接線狀態複用新加的 wire-cli.sh status（唯讀），設定則由 tools/scan-config.sh 比對 tools/config-spec.tsv 判定必要或選擇。規格表是必要性的唯一判準，掃描只負責抓出漏登錄的變數。
Who: 體檢與修復流程，搭配 jsc-cli:setup 收尾。
|
2026-08-26 10:43:37 +08:00 |
|