2 Commits

Include renames

Author	SHA1	Message	Date
jiantw83	7343def16e	feat(schedule): 助理的系統排程接線 ... What： - 新增 tools/schedule.sh，三個子命令：install 安裝、remove 移除、status 查現況。兩筆工作分別是每分鐘的心跳與每十五分鐘的巡檢。 - 助理主體的 start 接上安裝、stop 接上移除，行為清單與 README 跟著更新。 Why： - 心跳要有人定時寫，不然啟動之後過幾分鐘就自己過期，助理看起來像沒在跑。 - 排程這件事有標準的輸入與輸出，準則要求下放腳本，技能只描述何時呼叫。 How： - 條目行尾帶固定標記，安裝先濾掉自己的舊條目再追加。絕不覆寫整份排程，別人的條目一行都不碰；寫完回讀驗證，出現兩筆或別人的行數對不上就報錯。 - 裝完檢查排程服務在不在跑。這台機器是 WSL，預設不啟動 cron，裝了條目卻一次都不會執行——不檢查就會宣稱一件沒發生的事。 - 條目一律帶 </dev/null。排程是非互動環境，任何等輸入的東西都會把整筆卡死。 - 輸出寫到 JSC_HOME 底下，不寫進任何專案目錄，免得多出未追蹤檔污染別人的變更盤點。 - 巡檢那一筆預設不裝，要明著指定才會裝。巡檢本體還沒實作，裝了只會每十五分鐘失敗一次；巡檢指令也不猜 CLI，判不出來就停下，猜錯的代價是每十五分鐘跑一支不存在的執行檔。 - stop 先移除排程再清心跳，順序不能反。反過來的話清完下一分鐘排程就補寫一次，stop 等於騙人。 Who： 助理落地的第三塊。這裡留下一個要在巡檢那一輪解掉的問題：心跳目前由排程直接寫，所以心跳新鮮只證明排程活著，不證明助理做了事。往後應該改由巡檢跑完那一輪去寫，心跳才等於工作訊號。限制已寫進技能內文與說明文件。	2026-09-01 14:34:12 +08:00
jiantw83	fbf3e5a605	feat(assistant): 助理主體收攏 start、status、stop 三個操作 ... What： - 新增 assistant 技能，提供啟動、查現況、停止三個操作。 - 刪掉原本獨立的 status 技能，行為清單與 README 的技能目錄一起改。 - 三份 manifest 的版本一起提升，對 jsc-hooks 的下限提到含心跳腳本的那一版。 Why： - 助理的生命週期是一件事，拆在兩支技能裡，靠描述自動觸發的 CLI 等於擲骰子挑一支。準則也明寫技能目標不得重複。 - 刪除的代價這時候最低：這個 domain 才剛落地，status 是它唯一一支技能，除了自己的文件沒有別的東西指向它。晚一步等各處都引用了再收攏，成本差很多。 How： - 心跳的判定一律交給 jsc-hooks 的心跳腳本，三個操作都讀它的回報，不自己解析心跳檔。判定有兩份就會漂移，狀態與訊息就會對不上。 - 那支腳本的每一個結束碼都在技能裡有明確處置，包含「腳本自己沒跑起來」那一種——那時候既不能說助理在跑，也不能說助理停了。 - 時間戳壞掉一律當成不新鮮，絕不退回判成新鮮。 - 異常結束不需要額外的清理機制：心跳是時間戳，過了門檻自動失效。反過來說，stop 以外的任何路徑都不該寫心跳，否則就是留一個假心跳。 - stop 清心跳是它的職責，不算助理界線裡「不刪狀態檔」那一條。技能內文把這個例外寫明白，免得日後照界線把 stop 砍掉。 - stop 的收尾同時講兩件事：心跳清掉之後閘門會擋下技能呼叫，以及閘門目前還沒接線所以這一刻擋不到誰。前者是設計後果，停助理的人一定要知道；後者不講就是說一件還沒成真的事。 - 排程這一輪不做，start 只寫第一次心跳，並講明心跳不會自動更新。 Who： 助理落地的第二塊：心跳有了，接著要有人寫它、讀它、清它。	2026-09-01 14:19:24 +08:00