jiantw83andClaude Opus 5
e53bb23f8e
新增 tools/scan-repos.sh：掃出工作目錄底下的存取庫，交出 {repo} 要代的
那份清單，順便對出每一個存取庫的 REPO_{HASH} 盤點頁頁名（雜湊規則與
盤點頁那一支相同，實測值一致）。
掃描起點刻意沒有預設值。給一個預設就等於猜，而猜錯的後果不是掃不到，
是在猜錯的那些目錄底下跑指令——往上一層是家目錄、再往上是整台機器，
而那一輪沒有人看得到它跑到哪裡去了。沒設就回 3 並說要設哪一個變數。
深度預設一層、上限三層；點開頭的目錄、符號連結、路徑帶空白或殼層特殊
字元的三種一律不交出去，但逐個印出來——那是真的存在卻沒被盤點到的
存取庫，只印一個總數會讀成整批都掃過了。
run-due.sh 改成兩個代入點都代：{cli} 取偵測到的 CLI 代號、{repo} 取
掃到的存取庫，兩個都帶的那一筆目標數是乘積。待辦簿那一筆的 repo 欄
有值時只代那一個，值可以是路徑也可以是 {owner}/{repo}；對不出來就
印 held=，不退回全部存取庫——那一筆指名了一個目標。代入之後再驗一次
禁止字元，因為代進去的值是這一輪現場算出來的。
schedule.sh 把 JSC_ASSIST_SCAN_ROOT 與 JSC_ASSIST_SCAN_EXCLUDE 快照進
排程條目。少了掃描起點，帶 {repo} 的內建項每一輪都代不出目標，而那一輪
只印一行 held=，看起來像這一批還沒接上、不像一個變數沒進條目。
同時補兩個只有真的執行才發現得了的缺陷：
一、cron 一行的長度上限只在寫入那一刻由 crontab 自己擋，--dry-run 那一路
根本不碰它，所以預演每一次都過。實測踩過一次：整條 PATH 快照進條目那一批
預演全綠、安裝回結束碼 4。改成建好條目就量，兩個模式都印 entry_len= 與
上限，達到上限當場拒絕並指出長度是從哪幾個快照變數來的。
二、run-due.sh 截錯誤訊息用的 cut -c 數的是位元組不是字元，中文字剛好被
截在中間就在報告上留下一個替代字元。改成截完再過一次 iconv -c 丟掉那個
不完整的序列。這一種不會有人來報：亂碼不影響結束碼。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
355 B
JSON
16 lines
355 B
JSON
{
|
|
"name": "jsc-assist",
|
|
"version": "0.3.2",
|
|
"description": "助理：事件收攏、健康巡檢與待辦簿（MONITOR_{HASH} wiki 頁）",
|
|
"skills": "./skills",
|
|
"jsc": {
|
|
"requires": {
|
|
"jsc-cli": ">=0.2.7",
|
|
"jsc-gitea": ">=0.2.0",
|
|
"jsc-hooks": ">=0.3.7",
|
|
"jsc-log": ">=0.1.4",
|
|
"jsc-meta": ">=0.3.3"
|
|
}
|
|
}
|
|
}
|