fix(mcp): name the unfinished-run tick fuse as loop_fuse

AGENTS.md

@@ -405,9 +405,14 @@ boot 自动 ack 本 agent 的 `swarm.hello`。安装或拉代码后须重启 MCP
 Parent。此时 `boot_once` 为空。忽略 `next_action` 再调 `swarm_tick` 时默认不启新周期。
 第一次 `ok=true`、`severity=soft`、`cycle_started=false`、`progress=false`、
 `redirect_count=1`，`next_action` 仍是 `swarm_solidify`，不改 `last_run`。
-同一条 run 再 tick 返回 `ok=false`、`loop_fuse=pending_redirect_loop`（`severity=soft`，
-`retryable=false`，没有 `error` 字段），仍不启周期；这不是门禁失败，也不是放弃，
-软缺口留在 `warning`。两次返回都带 `preserve_pending=true`、`abandon_run=false`、
+同一条 run 再 tick 返回 `ok=false`、`loop_fuse=pending_redirect_loop`、
+`redirect_reason=pending_redirect_loop`（`severity=soft`，`retryable=false`，
+没有 `error` 字段），仍不启周期；这不是门禁失败，也不是放弃，也不是另一个
+`next_action`。`next_action` 仍是 `swarm_solidify`。`dispatch_reason` 仍是
+`pending_solidify`。第一次重定向的 `redirect_reason` 仍是 `pending_solidify`，
+没有 `loop_fuse`。常驻 instructions 写 `loop_fuse=pending_redirect_loop`，
+不把裸码当成 `next_action`。软缺口留在 `warning`。两次返回都带
+`preserve_pending=true`、`abandon_run=false`、
 `action_required=swarm_solidify`（boot/status 在仍要固化时同样带上）。有软缺口时，
 第一次 tick 与保险丝都不带 `gate_soft_continue`（缺席不是 false；`ok` 第一次仍为 true，
 没有 `error`；`tick_again=false` 表示不要再 tick）。两次 tick 都带

CHANGELOG.md

@@ -12,6 +12,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **README 对齐软默认与 MCP 口味（英/中）**：soft-accept 为 MCP 默认路径（经验写入 `~/.evolver/workspaces/<id>/`，不自动 git commit，不写 Parent baseline；`no_baseline` / `pack_absent` / `unmeasured` / `drop` / `flat` / `regression` 为警告）。硬阻断仍为密钥、`~/.evolver/`、`val_seal`。补开箱 `setup` / `doctor`、soft T0、前 5 tick 核心循环、`pending_solidify`、安装后重启 MCP，以及本 fork 的 clone URL（`linkerlin/evolver.py`）。顺手修正仍写「缺基线即停 / 过门即 commit / drop 仍硬拒绝」的 quickstart、AGENTS.md 与教程句子。
 
 ### Added
+- **MCP 宿主可用性：保险丝码写在 `loop_fuse` 与 `redirect_reason` 上**：常驻 instructions 把裸 `pending_redirect_loop` 改成 `loop_fuse=pending_redirect_loop`，不再把它写成 `next_action` 的并列值，长度仍小于 1200。同一条未完成 run 再 tick 时 `redirect_reason=pending_redirect_loop`（无软缺口与有软缺口两条路径都写），`dispatch_reason` 仍是 `pending_solidify`，`next_action` 仍是 `swarm_solidify`，`ok=false`，没有 `error` 字段。第一次重定向的 `redirect_reason` 仍是 `pending_solidify`，没有 `loop_fuse`。只匹配 `error == pending_redirect_loop` 的宿主仍会错过；读 `loop_fuse` 或保险丝 `redirect_reason` 的宿主会去固化。不写 Parent baseline，不放宽固化门。DEBUG #61 的目录缓存没有做假修复。
 - **MCP 宿主可用性：未完成 run 的 tick 重定向不再用失败字段表示停 tick**：软缺口上的两次默认 `swarm_tick` 不再写 `gate_soft_continue=false`，这个键缺席。缺席不是 true（只在 true 时再 tick 的宿主会停），也不是 false（只把严格 false 当成整段会话失败、且不读 `session_not_failed` 的宿主不会结束会话）。`tick_again=false` 仍表示不要再 tick。同一条 run 再 tick 时 `ok=false`，保险丝码改在 `loop_fuse=pending_redirect_loop`，`error` 字段不出现。只看 `ok` 的宿主会停；把任意 `error` 当放弃的宿主不会丢掉这条 run。`session_not_failed` 与 preserve 三元组仍在。boot / status 的 `gate_soft_continue` 仍为 true。不写 Parent baseline，不放宽固化门。
 - **MCP 宿主可用性：未完成 run 的 tick 重定向标明会话没有失败**：两次默认 `swarm_tick`（第一次软重定向，以及 `error=pending_redirect_loop`）都带 `session_not_failed=true`。先读这个字段，再读 `gate_soft_continue` 和 `error`。true 表示会话没有失败：`gate_soft_continue=false` 只停 tick；保险丝上的 `pending_redirect_loop` 不放弃未完成 run，preserve 三元组仍指向 `swarm_solidify`。`ok` / `error` / `gate_soft_continue` 的原值不动。boot / status 不带这个字段。不写 Parent baseline，不放宽固化门。
 - **MCP 宿主可用性：软缺口的第一次 tick 重定向不再邀请再 tick**：未完成 run 上带软缺口的 `swarm_tick`，第一次就把 `gate_soft_continue` 写成 false。`ok` 仍为 true，没有 `error`，`severity` 仍为 soft，`next_action` 仍是 `swarm_solidify`。false 只表示不要再 tick，会话没有失败，软缺口留在 `warning`。`next_steps` 第一条改为现在调用 `swarm_solidify`，不再写「再 swarm_tick」。boot / status 的 `gate_soft_continue` 仍为 true。只看 `ok` 的宿主再 tick 仍会碰到 `pending_redirect_loop`。不写 Parent baseline，不放宽固化门。

DEBUG.md

@@ -1185,3 +1185,14 @@
 - **根因**：`gate_soft_continue=true` 的原义是「软缺口，会话继续」；`error` 是硬停字段（`apply_soft_gap` 写明软缺口不得进 `error`）。#17–#19 把「不要再 tick」写进这两个失败形字段，再请宿主先读新旗标。不读新旗标的宿主按原义处理。
 - **修复**：未完成 run 的 tick 重定向（第一次和保险丝）在软缺口上删掉 `gate_soft_continue`，不写成 false，也不留 true。缺键不是 true，只按 true 循环的宿主不再 tick；缺键不是 false，只把严格 false 当会话失败的宿主不会结束会话，哪怕它不读 `session_not_failed`。`tick_again=false` 仍表示不要再 tick。保险丝码从 `error` 挪到 `loop_fuse=pending_redirect_loop`，`error` 字段不出现，`ok` 仍为 false。只看 `ok` 的宿主会停；只因 `error` 放弃的宿主不会丢掉 run。`session_not_failed` 与 preserve 三元组仍在。boot / status 的 `gate_soft_continue` 仍为 true，且不带 `session_not_failed`。不写 Parent baseline，不放宽固化门。目录缓存（DEBUG #61）未做假修复。
 - **经验**：**停 tick 不能借用失败字段。** `false` 写在名字像「继续」的旗标上，不读旁注的宿主会把 false 读成整段停。`error` 是硬停槽，保险丝码放进去就会被当成放弃。缺键同时躲开「只在 true 时 tick」和「只在 false 时判死」。仍把缺键当成「继续 tick」的宿主，以及把 `ok=false` 本身当成整段失败的宿主，这次覆盖不到。
+
+### 68. 常驻说明把裸码当成 `next_action`，保险丝的 `redirect_reason` 仍写「待固化」（MCP 易用性，已修）
+
+- **症状**：#67 之后，保险丝码在 `loop_fuse=pending_redirect_loop`，`error` 字段不出现，`next_action` 仍是 `swarm_solidify`。连上时的常驻 instructions 仍写 `next_action=swarm_solidify or pending_redirect_loop`。只匹配 `error == pending_redirect_loop` 的宿主不再看见这个码，会跳过 `swarm_solidify`。把裸 `pending_redirect_loop` 当成 `next_action` 并列值的宿主也对不上 #20 的信封。保险丝返回的 `redirect_reason` 仍是 `pending_solidify`，机器读者没有一个非 `error` 的原因字段与保险丝码对齐。
+- **根因**：#20 把码从 `error` 挪到 `loop_fuse`，常驻那一句和 `redirect_reason` 留在旧形状上。裸码没有字段名，读起来像另一个 `next_action`。
+- **修复**：常驻 instructions 改成 `loop_fuse=pending_redirect_loop`，不写 `error=pending_redirect_loop`，也不把裸码当成 `next_action`，长度仍小于 1200。保险丝（无软缺口的早返回，以及有软缺口的返回）把 `redirect_reason` 写成 `pending_redirect_loop`。`dispatch_reason` 仍是 `pending_solidify`。`loop_fuse`、`ok=false`、`error` 缺席、`session_not_failed=true`、preserve 三元组、`tick_again=false` 不动。有软缺口时仍不写 `gate_soft_continue`。第一次重定向的 `redirect_reason` 仍是 `pending_solidify`，没有 `loop_fuse`。`next_action` 仍是 `swarm_solidify`。不写 Parent baseline，不放宽固化门。目录缓存（DEBUG #61）未做假修复。
+- **经验**：**字段名要和码一起出现。** 裸码会被读成 `next_action`。`error` 不能再写回这个码，否则「任意 error 即放弃」的宿主又会丢掉 run。非失败的原因字段是保险丝上的 `redirect_reason`。
+- **仍在的宿主摩擦**（#20 的 1、2、4，这次没有关）：
+  1. 把缺席的 `gate_soft_continue` 当成「继续 tick」（只在严格 false 时才停），并且不看 `tick_again` / `next_action` / `ok` 的宿主，仍可能再 tick。保险丝上 `ok=false` 仍能停住只看 `ok` 的宿主。
+  2. 把 `ok=false` 本身当成整段会话失败、且不读 `session_not_failed` 与 `loop_fuse` 的宿主，仍会在第二次 tick 上停掉会话。`ok=false` 留着，是因为只看 `ok` 的宿主靠它停止空转。
+  4. 宿主 `tools/list` 缓存滞后（DEBUG #61）没有做假修复。安全信号在返回体上。

README.md

@@ -239,7 +239,7 @@ After `uv sync`, a pull, or any install, **restart the MCP server**. A long-live
 
 Live `tools/list` already publishes `swarm_tick` parameters `prompt_mode` (`full` or `short`) and `checklist_only`, with descriptions on those fields, and read-only `swarm_doctor`. A host catalog that still lists only `agent_name` and `include_prompt`, or that cannot find `swarm_doctor`, is a stale client session. Restarting the server reloads the code; start a new host session so the client reads `tools/list` again.
 
-If a previous run is unfinished, `swarm_boot` keeps `next_action=swarm_solidify`, sets top-level `pending_solidify`, and adds `readonly_smoke` (`tools`: `swarm_doctor` and `swarm_status`, `settles_run`: false). `hint` says to solidify first. A soft gap (`no_baseline` / `pack_absent` / `unmeasured`) still attaches `warning` and `next_steps`, and it does not replace that hint or weaken the gate. A read-only smoke can call `swarm_doctor` or `swarm_status`; neither settles the run nor invents a Parent baseline. A `swarm_tick` in that state does not start a cycle. The first call stays soft (`ok` true, `severity` soft, `cycle_started` false, `progress` false, `redirect_count` 1, `next_action` still `swarm_solidify`, `last_run` unchanged). The same call again on that run returns `ok` false, `loop_fuse=pending_redirect_loop`, `severity` soft, `retryable` false, and no `error` field. It still does not start a cycle. `loop_fuse` is the tick-loop fuse, not a gate failure and not an abandon signal; a soft gap stays on `warning` and `next_steps`. Both returns set `preserve_pending` true, `abandon_run` false, and `action_required` to `swarm_solidify` (boot and status do too while solidify is still next). Do not drop the unfinished run. When a soft gap is present, `gate_soft_continue` is omitted on the first redirect and on the fuse (`tick_again` is false). Omitted is not false: the first redirect keeps `ok` true and sets no `error`, so a host that treats only a strict false as session death stays in the session and does not tick again. Both tick returns set `session_not_failed` true. Read that field before other flags: true means the session is not failed, and `loop_fuse` does not abandon the run when the preserve flags say to call `swarm_solidify`. `next_steps` starts with `swarm_solidify`. Boot and status keep `gate_soft_continue` true while a run is still unfinished, and they do not set `session_not_failed`. Pass `supersede_pending=true` to replace that run. Pause and the compaction checkpoint still refuse the cycle.
+If a previous run is unfinished, `swarm_boot` keeps `next_action=swarm_solidify`, sets top-level `pending_solidify`, and adds `readonly_smoke` (`tools`: `swarm_doctor` and `swarm_status`, `settles_run`: false). `hint` says to solidify first. A soft gap (`no_baseline` / `pack_absent` / `unmeasured`) still attaches `warning` and `next_steps`, and it does not replace that hint or weaken the gate. A read-only smoke can call `swarm_doctor` or `swarm_status`; neither settles the run nor invents a Parent baseline. A `swarm_tick` in that state does not start a cycle. The first call stays soft (`ok` true, `severity` soft, `cycle_started` false, `progress` false, `redirect_count` 1, `next_action` still `swarm_solidify`, `last_run` unchanged). The same call again on that run returns `ok` false, `loop_fuse=pending_redirect_loop`, `redirect_reason=pending_redirect_loop`, `severity` soft, `retryable` false, and no `error` field. It still does not start a cycle. `loop_fuse` and that `redirect_reason` are the tick-loop fuse. The code is not an `error` and not a `next_action`. `next_action` stays `swarm_solidify`. `dispatch_reason` stays `pending_solidify`. The first redirect keeps `redirect_reason=pending_solidify` and does not set `loop_fuse`. Connect-time instructions name `loop_fuse=pending_redirect_loop` the same way. The fuse is not a gate failure and not an abandon signal; a soft gap stays on `warning` and `next_steps`. Both returns set `preserve_pending` true, `abandon_run` false, and `action_required` to `swarm_solidify` (boot and status do too while solidify is still next). Do not drop the unfinished run. When a soft gap is present, `gate_soft_continue` is omitted on the first redirect and on the fuse (`tick_again` is false). Omitted is not false: the first redirect keeps `ok` true and sets no `error`, so a host that treats only a strict false as session death stays in the session and does not tick again. Both tick returns set `session_not_failed` true. Read that field before other flags: true means the session is not failed, and `loop_fuse` does not abandon the run when the preserve flags say to call `swarm_solidify`. `next_steps` starts with `swarm_solidify`. Boot and status keep `gate_soft_continue` true while a run is still unfinished, and they do not set `session_not_failed`. Pass `supersede_pending=true` to replace that run. Pause and the compaction checkpoint still refuse the cycle.
 
 A cold `swarm_status` (this process has not called `swarm_boot`) returns `next_action=swarm_boot` and a short hint. After boot, status keeps `agent_name`, `source_revision`, and any soft `gap` / warnings. `tool_asset_search`, `tool_mailbox_poll`, `tool_cycle_timeline`, and `swarm_approvals` always return `{ok, items, hint}` — an empty match is not a blank body. `swarm_approvals` also keeps `pending` (the same rows as `items`) and `recent`. Read-only `swarm_doctor` mirrors `evolver doctor` without `--fix` (`ok`, soft warnings, command hints in `fixes`). `no_baseline` / `pack_absent` / `unmeasured` stay soft-continue.
 

README.zh.md

@@ -277,7 +277,7 @@ uv run evolver migrate-state
 
 soft-accept 选用 minimal T0 探针（`determine_t0_mode` 返回 `minimal`；`skip` 也已实现）。验收钩子（`solidify_hook`）在本轮已标 `soft_accept` 时按这个深度跑。硬接受仍跑完整 T0。若结算裁决带了 skip 或 minimal 探针，warnings 里会有 `t0_skipped_soft` 或 `t0_probe=minimal`。
 
-`pending_solidify` 仅在 `last_run.run_id` 与 `last_solidify.run_id` 不同时为真。成功的 solidify（含 soft-accept）会写下 `last_solidify`，下一次 status 或 boot 报告 `pending_solidify: false`，开局动作回到 `swarm_tick`。仍有待固化 run 时，`boot_once` 为空，宿主先固化。此时再调 `swarm_tick` 默认不启新周期。第一次仍是软返回（`ok` 为 true，`severity=soft`，`cycle_started=false`，`progress=false`，`redirect_count=1`，`next_action` 仍是 `swarm_solidify`，不改 `last_run`）。同一条 run 再 tick 返回 `ok=false`、`loop_fuse=pending_redirect_loop`、`severity=soft`、`retryable=false`，并且没有 `error` 字段，仍然不启周期。`loop_fuse` 是 tick 空转保险丝，不是门禁失败，也不是放弃；软缺口留在 `warning` 与 `next_steps`。两次返回都带 `preserve_pending=true`、`abandon_run=false`、`action_required=swarm_solidify`（boot 与 status 在仍要固化时同样带上）。不要丢掉这条未完成 run。有软缺口时，第一次 tick 与保险丝都不带 `gate_soft_continue`（缺席不是 false；`ok` 第一次仍为 true，没有 `error`；`tick_again=false` 表示不要再 tick）。只把严格 false 当成整段会话失败的宿主因此不会停掉会话。两次 tick 都带 `session_not_failed=true`：先读这个字段，会话没有失败；`loop_fuse` 不在 `error` 里，preserve 三元组仍指向 `swarm_solidify`。`next_steps` 第一条是调用 `swarm_solidify`。boot 与 status 的 `gate_soft_continue` 仍为 true，且不带 `session_not_failed`。要替换这条 run 才传 `supersede_pending=true`。暂停与压缩检查点仍优先于这个参数。
+`pending_solidify` 仅在 `last_run.run_id` 与 `last_solidify.run_id` 不同时为真。成功的 solidify（含 soft-accept）会写下 `last_solidify`，下一次 status 或 boot 报告 `pending_solidify: false`，开局动作回到 `swarm_tick`。仍有待固化 run 时，`boot_once` 为空，宿主先固化。此时再调 `swarm_tick` 默认不启新周期。第一次仍是软返回（`ok` 为 true，`severity=soft`，`cycle_started=false`，`progress=false`，`redirect_count=1`，`next_action` 仍是 `swarm_solidify`，不改 `last_run`）。同一条 run 再 tick 返回 `ok=false`、`loop_fuse=pending_redirect_loop`、`redirect_reason=pending_redirect_loop`、`severity=soft`、`retryable=false`，并且没有 `error` 字段，仍然不启周期。`loop_fuse` 与这个 `redirect_reason` 是 tick 空转保险丝，不是 `error`，也不是 `next_action`。`next_action` 仍是 `swarm_solidify`。`dispatch_reason` 仍是 `pending_solidify`。第一次重定向的 `redirect_reason` 仍是 `pending_solidify`，没有 `loop_fuse`。常驻 instructions 写 `loop_fuse=pending_redirect_loop`。这不是门禁失败，也不是放弃；软缺口留在 `warning` 与 `next_steps`。两次返回都带 `preserve_pending=true`、`abandon_run=false`、`action_required=swarm_solidify`（boot 与 status 在仍要固化时同样带上）。不要丢掉这条未完成 run。有软缺口时，第一次 tick 与保险丝都不带 `gate_soft_continue`（缺席不是 false；`ok` 第一次仍为 true，没有 `error`；`tick_again=false` 表示不要再 tick）。只把严格 false 当成整段会话失败的宿主因此不会停掉会话。两次 tick 都带 `session_not_failed=true`：先读这个字段，会话没有失败；`loop_fuse` 不在 `error` 里，preserve 三元组仍指向 `swarm_solidify`。`next_steps` 第一条是调用 `swarm_solidify`。boot 与 status 的 `gate_soft_continue` 仍为 true，且不带 `session_not_failed`。要替换这条 run 才传 `supersede_pending=true`。暂停与压缩检查点仍优先于这个参数。
 
 下列情况仍硬停（不要重试同一次失败）：diff 里的密钥或凭据、改写 `~/.evolver/` 下的引擎状态、`val_seal` 泄露。损坏的 bench 门（`gate_error`）以及验证面改动的 anchor 失败也会拒绝。没有假说时本轮仍被拒（`hypothesis_missing`），直到 `swarm_hypothesis` 成功。