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>