feat(deploy): 部署收尾刷新 current 連結農場

$JSC_HOME/current 是一組不帶版本的符號連結，每個外掛一條，指向快取裡帶版本號的實體目錄。技能文件裡所有跨外掛的腳本呼叫都以這一層為根，因為它不帶版本號、寫得進權限允許清單。

問題是沒有任何東西會更新這些連結，只有 wire-cli.sh 會更新 jsc-hooks 那一條。其餘幾條是人手動建的，建好之後就停在當時的版本。實際後果是部署完四個 domain 之後，快取裡是新版，連結卻還指著舊版：助理巡檢照文件的字面路徑跑，跑到的是舊腳本，而其中一個舊版底下根本沒有它要呼叫的檔案。失敗無聲，只有心跳停止，沒人盯就不會有人發現。

部署改成收尾時刷新整組連結。挑部署來做，是因為它本來就知道裝了哪些 domain、裝到哪個版本，資訊最齊。

四個設計決定：

基準 CLI 取 claude、codex、copilot、kiro 之中第一支找得到的，整輪只有那一支寫連結。連結農場只有一組，不可能同時指向五個 CLI 的副本；而五支 CLI 是平行跑的，五支都寫會互相覆寫，最後指到哪一份是隨機的、出事重現不出來。antigravity 一律不當基準，它的來源是本地 clone，而那份 clone 明文允許是維護者的開發樹，把全機器路徑指到做到一半的樹正好是這次要修的那種毛病。

版本目錄取版本排序最大、且真的有 plugin.json、且本身不是符號連結的那一層。要求 plugin.json 是因為裝到一半的目錄沒有它，挑到會讓連結指向不完整的外掛而且照樣不報錯。

解除安裝的判準是「連結還在、指向卻沒了」，不是「這輪解除安裝過這個 domain」。只解除安裝其中一支 CLI 時，連結可能還指著另一支手上完好的副本，那一條必須留著。

連結建立失敗印一行繼續，不記進失敗清單。這一段跑在外掛都裝好之後，部署本身已經成功；記成失敗會連帶跳過重啟閘門，操作者拿到的是一台明明裝好卻被說成失敗的機器。缺陷仍然看得見，因為輸出多了一行。

目標存在但不是符號連結時一律不覆寫，印 skip 要人工處理。ln -sfn 對著實體目錄下手會把連結建進那個目錄裡，農場當場壞掉還不會報錯。

新增 link 行讓呼叫端讀得到每一條連結指到哪裡，狀態五選一。技能文件與行為契約跟著更新，另修正一句因這次改動而失效的敘述：原本寫 current 底下沒有 jsc-cli，刷新之後那條連結會存在，改成講清楚它仍然靠不住，因為第一次建起它的正是這一輪。

skills/deploy/SKILL.md

@@ -29,7 +29,7 @@ Empty output, a non-zero exit, or a path that is not an existing directory → s
 
 ### The second root — this skill's own `tools/`
 
-`jsc-cli` is **not** one of the links under `{JSC_ROOT}`; that directory carries `jsc-assist`, `jsc-gitea` and `jsc-hooks` and nothing else. So `tools/detect-clis.sh`, `tools/deploy.sh`, `tools/check-requires.sh` and `tools/write-guides.sh` cannot be reached through `{JSC_ROOT}`, and none of them may be written as a bare relative path either — the rule above wants a literal absolute path at every call site, and a call site with no way to build one is where a prefix gets guessed.
+**Do not reach this skill's own `tools/` through `{JSC_ROOT}`, even when a `jsc-cli` link is sitting there.** Step 4 refreshes the farm for every deployed domain, so after a round has run, `{JSC_ROOT}/jsc-cli` usually exists — but this skill cannot rely on it, because the round that first creates it is this very one. On a machine that has never deployed, and on any machine where the last round's link write came back `fail`, `{JSC_ROOT}/jsc-cli` is absent or stale, and `tools/detect-clis.sh`, `tools/deploy.sh`, `tools/check-requires.sh` and `tools/write-guides.sh` would resolve to nothing or to a superseded copy of themselves. None of the four may be written as a bare relative path either — the rule above wants a literal absolute path at every call site, and a call site with no way to build one is where a prefix gets guessed.
 
 They sit at `{plugin root}/tools/`, and the plugin root is the base directory the CLI states when it loads this skill. Take that literal path verbatim, call it `{CLI_ROOT}`, and write all four calls as `{CLI_ROOT}/tools/{script}` — `/root/.claude/plugins/cache/jsc/jsc-cli/0.3.2/tools/deploy.sh`, for example. No command runs for this one, and it is taken once, like `{JSC_ROOT}`.
 
@@ -84,7 +84,7 @@ Nothing passed in → run every step as written below.
 
 4. Run `{CLI_ROOT}/tools/deploy.sh {mode} {cli} {domain}...` once per detected CLI, passing the whole domain list in one call so the marketplace command runs only once. This step **MUST run as a sub agent**, one sub agent per CLI, and **all of them start together** — the CLIs write to separate plugin directories, so serialising them only adds up their install times.
 
-   The script prints `cmd` and `exit` lines for every command, one `requires` line before each domain update, optional `compat` lines for Codex cache links, and one `result` line at the end; `-n` prints the commands without running them.
+   The script prints `cmd` and `exit` lines for every command, one `requires` line before each domain update, optional `compat` lines for Codex cache links, `link` lines for the `current` link farm (see 4a), and one `result` line at the end; `-n` prints the commands without running them.
 
    | Exit | Action |
    | --- | --- |
@@ -95,7 +95,22 @@ Nothing passed in → run every step as written below.
 
    On update, `{CLI_ROOT}/tools/check-requires.sh {cli} {manifest}` checks each domain's `jsc.requires` before that domain is updated. Exit 0 updates the domain as usual. Exit 1 — a missing or too-old required jsc plugin — prints a `warn` line and the domain **is still updated**: skipping it would leave a behind domain permanently unable to reach the version its dependency needs. The block lives one layer up, at skill invocation time, where `jsc-hooks/hooks/version-guard.sh` stops that domain's skills. **That last mention is a description of where the block happens, not a call this skill makes** — nothing here runs `version-guard.sh` except step 1.2, which is written as `{JSC_ROOT}/jsc-hooks/hooks/version-guard.sh`, so do not read it as a call site that was left un-prefixed. Exit 4 — the manifest is unreadable, is not valid JSON, or python3 is missing — prints a `note` line and also still updates the domain: no verdict is not the same fact as behind, so it gets its own line rather than a `warn` that would send the operator hunting for a version problem that is not there. Exit 2 or any other code — a `check-requires.sh` usage error or a broken script — prints a `skip` line and leaves that domain untouched, because a checker that failed outright is not a pass. Codex update preserves old `jsc-cli` and `jsc-hooks` cache version paths as symlinks to the newest installed version, so a still-running Codex deploy can keep using its helper scripts and a still-running Codex session whose hook_run_id points at the old cache can finish without `No such file`. Antigravity cannot install from a Gitea URL, so the script clones each domain into the local plugin directory (`JSC_LOCAL_PLUGINS`, default `$JSC_HOME/plugins`) and installs from that path — keep that clone, because update pulls the same one. That default deliberately avoids a development checkout: when the directory holds uncommitted changes or unpushed commits, the script prints a `skip` line, leaves the tree untouched, and installs the on-disk content.
 
-   Done when every detected CLI has reported an exit code and a `result` line, every skipped domain has a checker-failure reason or a local-tree reason, and every `warn` domain is named with the version it still has to catch up to.
+   **The `link` lines say where `{JSC_ROOT}` now points, and they are the reason step 0's literal paths keep working.** `{JSC_ROOT}` is a farm of version-free symbolic links, one per plugin, each pointing at that plugin's versioned directory in a CLI's plugin cache. Every literal absolute path this skill builds rests on it, so a link left on an old version silently runs an old script — and a script that old version never shipped is simply absent, which stops a heartbeat without printing anything. `deploy.sh` refreshes the whole farm at the end of its run: install and update repoint every link at the version just installed, uninstall clears the ones whose target is gone.
+
+   Only one CLI's run touches the farm. The machine has one farm and five CLIs hold five copies, so the script picks the first of claude, codex, copilot, kiro that is installed and lets only that run write; every other CLI prints one `link<TAB>-<TAB>skip` line naming the base CLI, which is how a deliberate skip is told apart from a farm nobody refreshed. Read the base CLI's sub agent output for the real result. Each line is `link<TAB>{domain}<TAB>{status}<TAB>{link path}<TAB>{target or reason}`.
+
+   | `link` status | What it means and what to do |
+   | --- | --- |
+   | `ok` | The link now points at column 5, the version directory this round installed. Carry the target into step 7 for at least the plugins this skill itself reaches through `{JSC_ROOT}` |
+   | `removed` | Uninstall left the target gone, so the dangling link was cleared. Nothing to do |
+   | `skip` with a domain in column 2 | Something that is not a symbolic link already sits at that path, and the script deliberately refused to overwrite it. **Report it as an operator action** — until it is cleared by hand, that plugin's documented path keeps resolving to whatever is sitting there |
+   | `skip` with `-` in column 2 | This run is not the base CLI, or no base CLI is installed at all. The second case means no documented path got refreshed this round, so say so |
+   | `fail` | The version directory could not be found, or the link could not be written. The deploy still stands, but that plugin's documented path may still be on an old version. Name the plugin and the reason, and judge the round `degraded` |
+   | `dryrun` | `-n` only: column 5 is where the link would point. Nothing was written |
+
+   A failed link never fails the deploy. By the time the farm is refreshed the plugins are installed and working, and marking the round failed would skip the restart gate and the `result` line too, handing the operator a fully deployed machine described as a failure. The stale link is a real defect, but its remedy is a line the operator can see and act on.
+
+   Done when every detected CLI has reported an exit code and a `result` line, every skipped domain has a checker-failure reason or a local-tree reason, every `warn` domain is named with the version it still has to catch up to, and every `link` line has been read — with each `ok` target in hand for step 7 and each `fail` or domain-level `skip` named as an operator action.
 
 5. After install or update, call `jsc-hooks:hooks-install` and **hand it the CLI list from step 1.1**, so it does not probe the same five executables a second time. `hooks-install` still detects for itself when it receives no list — that fallback is what keeps it usable on its own.
 
@@ -114,11 +129,13 @@ Nothing passed in → run every step as written below.
 
    Done when both `wrote` lines are printed, or the failure is reported with the exit code and the paths involved.
 
-7. Report the run and close it, in one block. The result and any failure reason for every CLI × mode, plus every `skip` line, every `warn` line, every Codex `compat` line, and every CLI that could not be version-checked in step 2.
+7. Report the run and close it, in one block. The result and any failure reason for every CLI × mode, plus every `skip` line, every `warn` line, every Codex `compat` line, every `link` line that is not a plain base-CLI skip, and every CLI that could not be version-checked in step 2.
+
+   State the farm explicitly: name `{JSC_ROOT}` and, per plugin, the version directory its link now points at, taken from the `ok` targets. That one list is what lets the next round's operator check by eye that a documented path leads to the version just deployed, instead of finding out through a heartbeat that quietly stopped.
 
    For install or update, the same block ends with the restart instruction, in these words: 「請關閉目前的工作階段並重新啟動，新的技能內容才會載入」. `deploy.sh` recorded this round in `$JSC_HOME/restart-required.d/{cli}` — one file per CLI — and prints its path on a `restart` line; `jsc-hooks` reads only that CLI's own file and keeps reminding until that CLI restarts, with `JSC_RESTART_GATE=off` as the escape hatch. Restarting one CLI clears its own file and leaves the others' gates standing. Name the two guide paths from step 6 in that same closing block, so the operator knows where this machine's update and removal commands now live.
 
-   Done when every detected CLI appears in the report with its `result` status, and — for install or update — the restart instruction is printed with both guide paths named, or step 6's failure is repeated in their place.
+   Done when every detected CLI appears in the report with its `result` status, every plugin's refreshed link target is named, and — for install or update — the restart instruction is printed with both guide paths named, or step 6's failure is repeated in their place.
 
 8. **Record how the run ended.** This is the last thing this skill does, and it runs on every path out of the skill, the ones that stop at step 1 included. Call
 
@@ -130,10 +147,10 @@ Nothing passed in → run every step as written below.
 
    | status | When this skill uses it |
    | --- | --- |
-   | `ok` | Every detected CLI's `deploy.sh` exited 0, hooks-install returned a clean verdict for each of them with no `No such file` in any smoke result, and both guides printed their `wrote` line |
+   | `ok` | Every detected CLI's `deploy.sh` exited 0, hooks-install returned a clean verdict for each of them with no `No such file` in any smoke result, both guides printed their `wrote` line, and the base CLI's `link` lines are all `ok` or `removed` |
    | `blocked` | Nothing was deployed because there was nothing to deploy to: `detect-clis.sh` exited 0 with no row, so none of claude, codex, copilot, antigravity, kiro is installed and the run stops before any plugin command |
    | `failed` | The run broke: the marketplace read in step 1.3 exited non-zero or returned no plugin entry, or every detected CLI's `deploy.sh` came back non-zero. Also used when a smoke result carries `No such file`, which this skill judges as a failed update even when hooks-install did not |
-   | `degraded` | The deploy landed on part of the machine only: some CLIs exited 0 while others failed, a domain was left untouched by a `skip` line from `check-requires.sh`, or `write-guides.sh` exited 4 so the plugins are installed but this machine has no up-to-date update and remove guide |
+   | `degraded` | The deploy landed on part of the machine only: some CLIs exited 0 while others failed, a domain was left untouched by a `skip` line from `check-requires.sh`, `write-guides.sh` exited 4 so the plugins are installed but this machine has no up-to-date update and remove guide, or a `link` line came back `fail` or skipped a plugin whose link path is not a symbolic link — the plugins are installed, but a documented path may still lead to the old version |
    | `aborted` | The user chose none of `install`, `update` or `uninstall` at step 3, or stopped the run before step 4 launched the first CLI, so no plugin command ran |
 
    Done when exactly one `skill-end` line was recorded for this run, or the script was absent and the run finished without it.