feat(狀態回報): 收尾寫一筆 skill-end 事件

現行紀錄只記「被叫用」，沒有成敗也沒有結束碼。跑完整輪的技能與開場就
中止的技能，在紀錄裡長得一模一樣。

start 由技能用量 hook 順手發，不必改技能文件。end 只能由技能自己在收尾
步驟寫——hook 接在技能工具呼叫上，而實際工作發生在之後的模型輪次，它在
原理上看不到成敗。有 start 沒有配對的 end，就是那一輪中止了。

status 五選一，每支技能各自寫明什麼情況選哪一個。找不到回報腳本就安靜
跳過，回報失敗一律不改變技能自己的結論。

skills/delegate/SKILL.md

@@ -97,6 +97,22 @@ Detection and tag filtering are decided in code, not in prose: `jsc-cli/tools/de
 
    Done when the CLI, the model, the requirement and the per-criterion verdicts are all in the report, and every failure recorded in step 6 appears in the failure section.
 
+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 or step 3 included. Call
+
+   `jsc-hooks/tools/report-status.sh skill-end jsc-cli:delegate {status} {exit code} [detail]`
+
+   `{exit code}` is the exit code of whatever decided the outcome — the subagent's own status, or the `detect-clis.sh` or `model-tags.sh` call that ruled the run — and `0` when nothing failed. `{detail}` is one short line, no more than 200 characters: the target CLI and the model id fit there, the subagent's output does not. **If the script is not on this machine, skip this step in silence and finish the run as it stood** — missing infrastructure is not a failure, and a reporting call may never change what this skill returns or reports.
+
+   | status | When this skill uses it |
+   | --- | --- |
+   | `ok` | The subagent exited 0, its output held one `result` and one `summary` line, every acceptance criterion came back `pass`, and every `wrote` path sat inside the write scope |
+   | `blocked` | The capability gate stopped the delegation before it started, so no subagent ran: every candidate model returned `FAIL` or `UNKNOWN-MODEL` from `model-tags.sh gate`, `detect-clis.sh` exited 0 with no row, the CLI the user named is not on this machine, or the target CLI has no model row and no forced model |
+   | `failed` | The delegation ran and broke: the subagent exited non-zero, its exit status could not be obtained at all, its output was missing the `result` or `summary` line, a criterion came back `fail`, or a `wrote` path landed outside the write scope. `detect-clis.sh` or `list-models.sh` exiting non-zero sits here too |
+   | `degraded` | The subagent returned `result needs-input`: part of the goal is done and the rest waits on the user, so the report has a 需要使用者補充 section that is not empty. The delegation happened, the goal did not close |
+   | `aborted` | The premise did not hold, so the skill stopped on its own: step 1 could give the goal no pass-or-fail acceptance criterion, or the request carried two or more independent goals and has to be split. Also used when the user stops the run before step 5 spawns the subagent |
+
+   Done when exactly one `skill-end` line was recorded for this run, or the script was absent and the run finished without it.
+
 ## Do not use this skill
 
 - Do not use it for model inventory. That is `/jsc-cli:models`.

skills/deploy/SKILL.md

@@ -87,3 +87,21 @@ Nothing passed in → run every step as written below.
    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.
+
+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
+
+   `jsc-hooks/tools/report-status.sh skill-end jsc-cli:deploy {status} {exit code} [detail]`
+
+   `{exit code}` is the exit code of whatever decided the outcome — the worst `deploy.sh` exit of the run, or the collector that stopped step 1 — and `0` when nothing failed. `{detail}` is one short line, no more than 200 characters: the mode and the per-CLI counts fit there, the `cmd` and `exit` lines do not. **If the script is not on this machine, skip this step in silence and finish the run as it stood** — missing infrastructure is not a failure, and a reporting call may never change what this skill returns or reports.
+
+   Record it after step 7's block, never instead of it. The event stream carries one status; the operator still needs the per-CLI report on screen.
+
+   | 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 |
+   | `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 |
+   | `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.

skills/doctor/SKILL.md

@@ -162,3 +162,24 @@ Exits 7 and 8 never mean the page is missing. Writing a fresh template over a di
 State the four counts from 2.2's `summary` line: required items missing, settings invalid, CLIs unwired, domains behind. Recommend `/jsc-cli:setup` when any of those is above zero. Never fix anything here.
 
 Done when every link written into either page passed `link-check.sh` first — or the `DEAD` list is on screen and that write was skipped — each of the two pages is reported with its URL, or its skipped write is reported together with its reason, **and** the four counts are stated with the recommendation given or explicitly withheld.
+
+### 3.3 Record how the run ended
+
+This is the last thing this skill does, and it runs on every path out of the skill. Call
+
+`jsc-hooks/tools/report-status.sh skill-end jsc-cli:doctor {status} {exit code} [detail]`
+
+`{exit code}` is the exit code of whatever decided the outcome, and `0` when nothing failed. `{detail}` is one short line, no more than 200 characters: the four counts fit there, the five blocks do not. **If the script is not on this machine, skip this step in silence and finish the run as it stood** — missing infrastructure is not a failure, and a reporting call may never change what this skill returns or reports.
+
+This one call writes, and it is the only write this skill makes. It records what the run found; it changes no setting, no wiring and no version, so the read-only contract of the opening paragraph still holds.
+
+| status | When this skill uses it |
+| --- | --- |
+| `ok` | All four checks reached a conclusion, the five blocks and the 待修項目 table are on screen, and both pages were written |
+| `degraded` | The checkup ran but part of it has no conclusion, and this is the common outcome for a read-only skill that cannot reach a source. Any check reported as 無法驗證 lands here — `version-guard.sh report` exiting non-zero, `scan-config.sh` exiting 3 on a missing spec table, `wire-cli.sh status` returning an unexpected code, a Gitea-dependent row coming back `skipped` in offline mode — and so does a `wiki-repo` exit 3 that skipped a page write, which this skill treats as a finding rather than a fault |
+| `failed` | Reading the machine worked, then recording it broke on an error: `link-check.sh`, `gitea.sh` or `wiki-contents.sh` returned 7 on an invalid key, or 8 on any other API failure. Both are errors, never an absent page, and neither leaves a usable record |
+| `aborted` | The user stopped the run before the record was written, for example by declining to supply `GITEA_HOST` and asking to end the checkup there |
+
+`blocked` has no place in this skill. Nothing gates a read-only checkup: a machine with no CLI installed, no plugin registry and no wiki repo still produces four findings, and reporting that as `blocked` would hide a run that did its whole job.
+
+Done when exactly one `skill-end` line was recorded for this run, or the script was absent and the run finished without it.

skills/models/SKILL.md

@@ -38,3 +38,19 @@ description: 'List every model usable by each installed AI CLI (claude, codex, c
    2. A 「階段偏好模型」 table right after it, built from collector 1.3's rows, with three columns: stage, chain, source (`project` / `global`). State below the table that the chain does **not** grant passage: it only names the model to suggest switching to when the gate blocks, and expresses preference among models that already satisfy the required tags.
 
    Done when the requirement table shows all four stages with their required tags, and the 階段偏好模型 table shows the same four stages with `-` for unconfigured ones.
+
+7. **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
+
+   `jsc-hooks/tools/report-status.sh skill-end jsc-cli:models {status} {exit code} [detail]`
+
+   `{exit code}` is the exit code of whatever decided the outcome — usually `model-tags.sh sync` — and `0` when nothing failed. `{detail}` is one short line, no more than 200 characters: the CLI and model counts fit there, the four-column table does not. **If the script is not on this machine, skip this step in silence and finish the run as it stood** — missing infrastructure is not a failure, and a reporting call may never change what this skill returns or reports.
+
+   | status | When this skill uses it |
+   | --- | --- |
+   | `ok` | Every detected CLI has a model list, every model carries a tag, `sync` exited 0 and printed the path, and both stage tables are on screen |
+   | `blocked` | Nothing could be inventoried because nothing is installed: `detect-clis.sh` exited 0 with no row, so steps 2 to 4 have no CLI to work on. The tag table and the stage requirements are still printed, so say in `{detail}` that the inventory half of the run never started |
+   | `failed` | `model-tags.sh sync` returned 1, 2 or any other non-zero code, so `$JSC_HOME/model-tags.tsv` was not written and the SDLC gate stays broken until it is. `detect-clis.sh` exiting non-zero sits here too |
+   | `degraded` | The tag table was written but the picture is incomplete: `list-models.sh` stayed silent for a CLI so step 2 fell back to 「預設推定」 defaults, a model is missing from `references/model-tags.md` and was queued as a `jsc-ask:ask` question instead of tagged, or `model-config.sh list` failed so the 階段偏好模型 table shows 未取得 |
+   | `aborted` | The user stopped the run before `sync` wrote the file, so the gate reads whatever the previous run left behind |
+
+   Done when exactly one `skill-end` line was recorded for this run, or the script was absent and the run finished without it.

skills/setup/SKILL.md

@@ -146,3 +146,21 @@ No wiki repo configured, or any non-zero exit from `wiki-repo`, `hash-id`, `wiki
 Then state the counts: fixed, skipped, delegated, and 未修好. Recommend `/jsc-cli:doctor` for a clean re-check when anything was delegated.
 
 Done when every link written into either page passed `link-check.sh` first — or the `DEAD` list is on screen and that write was skipped — each of the two pages is written or its skip is reported, and the four counts are stated.
+
+## 6. 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
+
+`jsc-hooks/tools/report-status.sh skill-end jsc-cli:setup {status} {exit code} [detail]`
+
+`{exit code}` is the exit code of whatever decided the outcome — usually the `apply-config.sh` call that ruled the run — and `0` when nothing failed. `{detail}` is one short line, no more than 200 characters: the four counts fit there, the item table does not, and no value the user typed goes in it. **If the script is not on this machine, skip this step in silence and finish the run as it stood** — missing infrastructure is not a failure, and a reporting call may never change what this skill returns or reports.
+
+| status | When this skill uses it |
+| --- | --- |
+| `ok` | Every item on the list was confirmed and applied, each one re-verified by the checker its own row names, nothing was skipped, and both pages were written |
+| `blocked` | The environment refused every write, so nothing on the machine changed: `apply-config.sh` returned 4 on each item because the backup or the write failed. A run that could not touch a single rc file did no work, so it is never reported as `failed` half-done |
+| `failed` | Writes landed but the run broke: an applied item still fails its re-verification in step 4, `apply-config.sh` returned 2 on a malformed call this skill made, or `link-check.sh`, `gitea.sh` or `wiki-contents.sh` returned 7 or 8 and the record could not be rewritten |
+| `degraded` | The run finished with part of the list untouched. The usual case is the user turning an item down at step 2 — a skip is recorded as skipped and never as fixed — and a delegated repair that its owner skill did not close counts the same way. The machine is better than it was, and the 未修好 and 略過 counts are above zero |
+| `aborted` | The user stopped the sequential confirmation partway and asked to end the run, so the remaining items were never put to them |
+
+Done when exactly one `skill-end` line was recorded for this run, or the script was absent and the run finished without it.