CB-622: rename bridge_* tools to fleet_* in scripts, e2e tests and config; mount name bridged -> fleetd

2026-08-22 21:49:15 +02:00
36 changed files with 202 additions and 205 deletions
@@ -13,7 +13,7 @@ A design task is worked by two architects. Design alone first, then exchange and
 say plainly where you disagree. Do not concede just to agree.

 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `fleet_ask{question}` only when a decision belongs to
+investigate it further. Use `bridge_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.

@@ -10,7 +10,7 @@ git worktree and branch. Never check out, rebase onto, or push to `main`. Confir
 the worktree root and branch before you edit. Use only paths under that root.

 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `fleet_ask{question}` only when a decision belongs to
+investigate it further. Use `bridge_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.

@@ -12,7 +12,7 @@ Read the whole assigned scope before judging it. Review only that scope. If you
 something outside it, note it in one line and do not investigate it further. Do not
 run the build. The owner makes changes and runs checks.

-Use `fleet_ask{question}` only when a decision belongs to the lead, such as an
+Use `bridge_ask{question}` only when a decision belongs to the lead, such as an
 unclear requirement or two defensible fixes. Do not ask about something you can
 decide by reading more code.

@@ -5,7 +5,7 @@ description: Implementer-role procedure for a bridged worker — verify your wor

 # Implementer worker — procedure

-The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
+The turn contract (one `bridge_reply`, `bridge_ask` for the lead's decisions, honest reporting,
 never merge, never commit `.mcp.json` or `wiki/`) is in **`CLAUDE.md` → Bridge communication →
 Worker** and already applies. This skill is only the *implement-and-hand-off procedure*.

@@ -103,7 +103,7 @@ fix it if the cause is yours (e.g. branch not pushed yet), and report the failur
 inventing a URL. If `GITEA_TOKEN` is unset your profile was not granted PR-create: push the branch
 and report its name so the lead opens the PR.

-## 6. Hand off — what goes in `fleet_reply`
+## 6. Hand off — what goes in `bridge_reply`

 The reply is the entire handoff; the lead cannot see your terminal.

@@ -130,7 +130,7 @@ sequenceDiagram
    I->>G: git push -u origin HEAD
    I->>G: POST /pulls (GITEA_TOKEN) — open PR to main
    G-->>I: html_url
-    I->>L: fleet_reply(PR url, branch, files, tests)
+    I->>L: bridge_reply(PR url, branch, files, tests)
    Note over L,G: the lead reviews the PR and merges on green — you never merge
 ```

@@ -53,7 +53,7 @@ Map each entry from `.mcp.json`:
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["CLAUDE.md"],
  "mcp": {
-    "bridged":  { "type": "remote", "url": "http://127.0.0.1:8765/mcp", "enabled": true },
+    "fleetd":  { "type": "remote", "url": "http://127.0.0.1:8765/mcp", "enabled": true },
    "context7": { "type": "remote", "url": "https://example.dev/mcp", "enabled": true,
                  "headers": { "Authorization": "Bearer {env:CONTEXT7_TOKEN}" } },
    "gitea":    { "type": "local", "command": ["gitea-mcp", "-t", "stdio"], "enabled": true,
@@ -5,7 +5,7 @@ description: Reviewer-role procedure for a bridged worker — how to work a revi

 # Reviewer worker — procedure

-The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
+The turn contract (one `bridge_reply`, `bridge_ask` for the lead's decisions, honest reporting,
 never merge) is in **`CLAUDE.md` → Bridge communication → Worker** and already applies. This
 skill is only the *review procedure*: how to work the scope, and the exact shape of what you
 send back.
@@ -24,13 +24,13 @@ wrong.
  covers what it was given.
 - Do **not** edit files or run the build. You review; the owner acts.

-## 3. Reach for `fleet_ask` only for a genuine fork
+## 3. Reach for `bridge_ask` only for a genuine fork

 Ambiguous requirement, a missing acceptance criterion, "intended or a bug?", or two defensible
 fixes with different consequences — those are the lead's call, and guessing produces a
 confident-but-wrong finding. Anything you could settle by reading more code is yours to settle.

-## 4. The finding — what goes in `fleet_reply`
+## 4. The finding — what goes in `bridge_reply`

 Report the **single most important** real issue in the scope, in these four lines, under
 ~90 words:
@@ -13,7 +13,7 @@ A design task is worked by two architects. Design alone first, then exchange and
 say plainly where you disagree. Do not concede just to agree.

 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `fleet_ask{question}` only when a decision belongs to
+investigate it further. Use `bridge_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.

@@ -10,7 +10,7 @@ git worktree and branch. Never check out, rebase onto, or push to `main`. Confir
 the worktree root and branch before you edit. Use only paths under that root.

 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `fleet_ask{question}` only when a decision belongs to
+investigate it further. Use `bridge_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.

@@ -12,7 +12,7 @@ Read the whole assigned scope before judging it. Review only that scope. If you
 something outside it, note it in one line and do not investigate it further. Do not
 run the build. The owner makes changes and runs checks.

-Use `fleet_ask{question}` only when a decision belongs to the lead, such as an
+Use `bridge_ask{question}` only when a decision belongs to the lead, such as an
 unclear requirement or two defensible fixes. Do not ask about something you can
 decide by reading more code.

@@ -34,8 +34,8 @@ flowchart LR
    W["worker claude pane<br/>ANTHROPIC_BASE_URL set<br/>MCP client"]
    M["llm.ltms.dev<br/>(the one gateway)"]

-    OPUS -->|"MCP fleet_send (blocks)"| SRV
-    W -.->|"MCP fleet_reply"| SRV
+    OPUS -->|"MCP bridge_send (blocks)"| SRV
+    W -.->|"MCP bridge_reply"| SRV
    CLI -->|"Unix socket<br/>send_text · events.subscribe"| HERDR
    HERDR -->|"drives PTY"| W
    W -->|"inference"| M
@@ -51,16 +51,13 @@ flowchart LR
  plain daemon (no Anthropic quota), so it may poll/subscribe freely.
 - **One gateway (unified MCP setup):** `bridged` is the **sole communication path** for every
  Claude session. Primary and workers each mount it as an MCP server (one `claude mcp add`
-   line, same on both) and talk over MCP tools — `fleet_send` / `fleet_reply` /
-   `fleet_status` (with `fleet_ask` planned for the blocked-worker path). **No Claude session
-   ever addresses a broker, a peer, or the network
-   directly**; any queue is `bridged`-internal. MCP tool I/O never sets `ANTHROPIC_BASE_URL`, so
-   mounting the bridge is subscription-safe by construction.
-   **Tool naming:** the tools were renamed from `bridge_*` to `fleet_*` (CB-622). The daemon
-   still answers the old `bridge_*` names for one release, but they are deprecated — use the
-   `fleet_*` names.
- **How the primary consumes a reply:** a single **blocking MCP call** (`fleet_send`);
-  `bridged` holds it open until the worker calls `fleet_reply` or its turn hits
+  line, same on both) and talk over MCP tools — `bridge_send` / `bridge_reply` /
+  `bridge_status` (with `bridge_ask` planned for the blocked-worker path). **No Claude session
+  ever addresses a broker, a peer, or the network
+  directly**; any queue is `bridged`-internal. MCP tool I/O never sets `ANTHROPIC_BASE_URL`, so
+  mounting the bridge is subscription-safe by construction.
+- **How the primary consumes a reply:** a single **blocking MCP call** (`bridge_send`);
+  `bridged` holds it open until the worker calls `bridge_reply` or its turn hits
  `agent_status=done`, then returns the reply as the tool result. No cross-turn busy-poll, so
  no quota burn. SSE is an optional side-channel for humans/dashboards watching status.
 - **Worker → primary** rides `bridged`'s **MCP rendezvous** — the reply resolves the primary's
@@ -101,9 +98,9 @@ tests run separately via `mvn test -Pcontract`):

 - **Core gateway** — herdr socket client (contract-tested vs live 0.7.0); guard-checked worker
  spawn with `ANTHROPIC_BASE_URL` injected only into the worker's env; status-gated injector;
-  blocking `fleet_send` with reply rendezvous; MCP server as a thin adapter over the REST core.
- **MCP tools** — `fleet_send` / `fleet_reply` / `fleet_status` (messaging) and `fleet_spawn`
-  / `fleet_list` / `fleet_stop` / `fleet_profiles` / `fleet_poll` (fleet). Caller identity is
+  blocking `bridge_send` with reply rendezvous; MCP server as a thin adapter over the REST core.
+- **MCP tools** — `bridge_send` / `bridge_reply` / `bridge_status` (messaging) and `bridge_spawn`
+  / `bridge_list` / `bridge_stop` / `bridge_profiles` / `bridge_poll` (fleet). Caller identity is
  connection-based (loopback peer PID → herdr pane), so the same mount serves primary and workers.
 - **Delivery reliability** — completion fallback (a confirmed `working→idle` turn resolves a
  send); async fire-and-poll (beats the caller's MCP call timeout for long tasks); and failure
@@ -111,7 +108,7 @@ tests run separately via `mvn test -Pcontract`):
 - **Fleet** — multiple worker profiles, each with an independent base_url guard check; workers
  inherit the primary's working directory (never `$HOME`); a readiness gate holds delivery until
  a worker's Claude has connected the bridge MCP (no paste lost into its boot window).
- **Blocked-worker path** — `fleet_ask` reverse rendezvous: a worker pauses its delegated turn to
+- **Blocked-worker path** — `bridge_ask` reverse rendezvous: a worker pauses its delegated turn to
  ask the primary and resumes the *same* turn with the answer (CB-205).
 - **Session lifecycle** — session manager with spawn/reuse/recycle, `idle_ttl` reaper, `context_cap`,
  and graceful drain on shutdown (CB-301/CB-303); per-worker git worktrees on their own branch with
@@ -35,7 +35,7 @@ bind:
 # a caller whose connection maps to this pane resolves as the primary (no credential needed —
 # the pane mapping is as unforgeable as a worker's), and reply nudges are pushed to it.
 # REQUIRED when the primary runs inside a herdr pane — without it the pane match reads the
-# primary as a worker and refuses spawn/send/stop. Get the id from bridge_whoami; re-pin if
+# primary as a worker and refuses spawn/send/stop. Get the id from fleet_whoami; re-pin if
 # the primary moves panes.
 # primary:
 #   terminal: term_0123456789abcd
@@ -49,12 +49,12 @@ bind:
 #
 #   tab → the ONLY field identity depends on (CB-579); the exact label of the tab hosting the lead.
 #         Label the tab yourself, or let bridged label one it launches — see `fleet.leaders:` below.
-#   kind/model → descriptive; they document what runs in the pane and are echoed by bridge_whoami
+#   kind/model → descriptive; they document what runs in the pane and are echoed by fleet_whoami
 #
 # A lead's tab must already carry its label (or be launched by bridged, which labels it) — there is
 # no terminal id to paste in and nothing to re-pin when the session restarts: the tab survives, so
 # the same label resolves the same lead again on the next scan.
-# `bridge_whoami` reports `{"role":"primary","leader":"<name>"}`; role stays "primary" because a lead
+# `fleet_whoami` reports `{"role":"primary","leader":"<name>"}`; role stays "primary" because a lead
 # IS a primary for authorization, so nothing that keys on the role breaks.
 #
 # KEEP `primary:` when adding leads: it still addresses the CB-307 push loop, which needs a single
@@ -69,7 +69,7 @@ bind:
 # never a capability: what a pane may do is decided by the role the daemon resolves for it.

 # CB-551: IDLE-LEAD HEARTBEAT — nudge the single lead back to work when it has been continuously
-# idle (no open bridge_send driving it) past the quiet period. The fleet is one lead + architects +
+# idle (no open fleet_send driving it) past the quiet period. The fleet is one lead + architects +
 # workers, so a lead that stalls is a single point of failure; the ReplyPushLoop only nudges when a
 # reply lands, and this timer catches the gap where nothing lands and the lead just sits idle.
 #
@@ -99,7 +99,7 @@ bind:
 #                      them changes nothing right now, and no minimum is enforced on either, because
 #                      nothing reads them to enforce one. They exist so a later build can start
 #                      honouring them without another config-shape change.
-#   notifications.mode → "webhook" flips what bridge_list REPORTS (healthCoverage: "full" instead
+#   notifications.mode → "webhook" flips what fleet_list REPORTS (healthCoverage: "full" instead
 #                      of "detection-only") — it does NOT make bridged send any webhook call; no
 #                      delivery mechanism is implemented yet. Any other value, or omitting the
 #                      block, reports "detection-only".
@@ -152,7 +152,7 @@ herdrSocket: ~/.config/herdr/herdr.sock
 #   gitHostEnv       → host env var holding the forge host (default GITEA_HOST). Injected as
 #                      GITEA_HOST *only* alongside a resolved gitTokenEnv.
 #   exhaustedPattern → regex matched against a completion-fallback scrape (CB-578 stage A) to
-#                      classify a turn that ended with no bridge_reply as the backend having
+#                      classify a turn that ended with no fleet_reply as the backend having
 #                      refused on a subscription usage limit, rather than a real answer. Opt-in —
 #                      omit and this profile's completion fallback behaves exactly as before.
 #                      Every backend words its refusal differently, so this is config, never a
@@ -200,12 +200,12 @@ profiles:
    # weight: relative selection weight for automatic placement (weighted, round-robin, and
    # fixed's fallback walk). Absent defaults to 1.0. An explicit 0 or negative value means
    # "never auto-select this profile" (CB-554) — it stays reachable via an explicit
-    # `bridge_spawn{profile:"gx10"}`, which bypasses placement entirely; only automatic
+    # `fleet_spawn{profile:"gx10"}`, which bypasses placement entirely; only automatic
    # selection skips it.
    weight: 0.5
    # maxLoad: max live workers on this profile. Omit for unlimited. An explicit 0 (CB-585) caps
    # the profile at zero live members — it is excluded from automatic placement and an explicit
-    # `bridge_spawn{profile:"gx10"}` against it is refused too; a cap holds even when the profile
+    # `fleet_spawn{profile:"gx10"}` against it is refused too; a cap holds even when the profile
    # is named directly. Negative is refused at config load — there is no sane meaning for it.
    maxLoad: 2
    # subscription: true
@@ -259,8 +259,8 @@ profiles:
  # The bridge MCP + reply charter mount via a generated OPENCODE_CONFIG file, and the model is a
  # `provider/model` selector. Placement, tabs, cwd, and the readiness gate are shared with Claude.
  #
-  # Dogfood-verified 2026-07-29 against opencode 1.18.5 (spawn → readiness gate → bridge_send →
-  # structured bridge_reply → teardown). The `opencode/*-free` models run on opencode's own gateway
+  # Dogfood-verified 2026-07-29 against opencode 1.18.5 (spawn → readiness gate → fleet_send →
+  # structured fleet_reply → teardown). The `opencode/*-free` models run on opencode's own gateway
  # and need NO credentials — check `opencode models` for the current free list, since the names
  # change. That also makes the worker off-subscription by construction.
  #   opencode-free:
@@ -447,7 +447,7 @@ fleet:
  #                                  # MUST NOT be a member workspace — those are excluded from the
  #                                  # scan, so a lead placed in one is never found again.
  #     cwd: /path/to/repo           # the launched lead's working directory (default: bridged's own)
-  #     kind: claude                 # descriptive; reported by bridge_whoami
+  #     kind: claude                 # descriptive; reported by fleet_whoami
  #   gpt-sol-5.6:
  #     tab: "lead: gpt-sol-5.6"
  #     kind: opencode
@@ -600,7 +600,7 @@ guard:
 #   uri: amqp://guest:guest@127.0.0.1:5672
 #   prefetch: 32

-# Active push-to-primary (CB-307 Stage 3). When a worker reply lands with no open bridge_send,
+# Active push-to-primary (CB-307 Stage 3). When a worker reply lands with no open fleet_send,
 # the ReplyPushLoop injects a *drain nudge* (never the payload) into the primary's own herdr
 # pane — status-gated (only when injectable, never mid-turn) and bounded. Ack = drain: the loop
 # stops as soon as the primary's inbox is empty.
@@ -615,7 +615,7 @@ guard:
 #                    classified as a WORKER and refused SPAWN/SEND/STOP. That failure is
 #                    self-locking: the learned terminal is populated by the very orchestration
 #                    calls being refused, so only this pinned value can break the cycle. Read the
-#                    id off bridge_whoami (it reports the current terminal even while
+#                    id off fleet_whoami (it reports the current terminal even while
 #                    misclassified) and re-pin whenever the primary moves panes.
 #   pushReminders  → max nudges before giving up (default 5)
 #   pushBackoffMs  → delay between nudges in ms (default 15000)
@@ -5,10 +5,10 @@

 ## Why this exists

-Stage 2 gave a worker→primary reply a **durable place to wait** when no `fleet_send` is
+Stage 2 gave a worker→primary reply a **durable place to wait** when no `bridge_send` is
 open: it lands in `agent.<target>.inbox` on the broker and survives a daemon bounce. But
 delivery is still **pull** — the primary only sees the reply if it happens to call
-`fleet_poll(target)` / `GET /sessions/{id}/replies`. A reply can sit indefinitely while
+`bridge_poll(target)` / `GET /sessions/{id}/replies`. A reply can sit indefinitely while
 the primary works on something else.

 This layer makes delivery **active**: the bridge *pushes* a nudge to the primary the moment
@@ -26,11 +26,11 @@ pointed at the primary's pane instead.

 ```mermaid
 flowchart LR
-    W["worker"] -->|"fleet_reply (no open send)"| MS["MessageService.reply"]
+    W["worker"] -->|"bridge_reply (no open send)"| MS["MessageService.reply"]
    MS -->|"inbox.publish"| INBOX[("agent.&lt;target&gt;.inbox<br/>(durable, LavinMQ)")]
    MS -->|"notify"| LOOP["ReplyPushLoop"]
    LOOP -->|"status-gated inject"| PANE["primary's herdr pane"]
-    PANE -->|"primary drains"| DRAIN["fleet_poll(target)<br/>= peek + ack"]
+    PANE -->|"primary drains"| DRAIN["bridge_poll(target)<br/>= peek + ack"]
    DRAIN -->|"inbox now empty"| LOOP
    LOOP -.->|"still non-empty →<br/>re-inject on backoff"| PANE
    classDef store fill:#2c5282,stroke:#1a365d,color:#ffffff;
@@ -51,11 +51,11 @@ the caller runs in a herdr pane on this host. Today it's discarded for the prima
 (`presence.markPresent` is a no-op on it).

 **Plan:** a single-slot `PrimaryRegistry` (thread-safe) holding the primary's `terminal_id`.
-Populate it from the **orchestration-side** MCP tools — `fleet_send`, `fleet_spawn`,
-`fleet_poll`, `fleet_list`, `fleet_status`, `fleet_profiles` — capturing
+Populate it from the **orchestration-side** MCP tools — `bridge_send`, `bridge_spawn`,
+`bridge_poll`, `bridge_list`, `bridge_status`, `bridge_profiles` — capturing
 `callerTerminal(exchange)` when it is (a) non-null and (b) **not** a registered worker
 session in `SessionManager`. That caller is, by construction, the primary. Worker-side tools
-(`fleet_reply`, `fleet_ask`) never set it.
+(`bridge_reply`, `bridge_ask`) never set it.

 - **Config override / pin:** a `primary: { terminal: "<id>" }` block in `BridgedConfig`
  (nested record, same shape as `Broker`). Lets an operator pin it, or supply it when
@@ -71,13 +71,13 @@ A `ReplyPushLoop` component, notified at the single no-waiter call site
 (`MessageService.reply` → the `inbox.publish` branch, `MessageService.java:192`).

 - **Inject a nudge, not the payload.** The injected turn tells the primary *to drain*
-  (e.g. "Worker `<target>` returned a reply — run `fleet_poll(target=<target>)` to collect
+  (e.g. "Worker `<target>` returned a reply — run `bridge_poll(target=<target>)` to collect
  it"), it does **not** carry the reply text. Rationale: replies can be large/multiline and
  terminal injection would mangle them; the drain response is the clean transport. Keeps the
  push idempotent — re-nudging is harmless.
 - **Ack = drain.** The primary draining (`drainReplies` = peek + ack) is the acknowledgement.
  The loop's **stop condition is `inbox.peek(target).isEmpty()`** — the reply is gone from the
-  inbox because it was acked. No new `fleet_ack` tool needed for v1 (see Increment 3).
+  inbox because it was acked. No new `bridge_ack` tool needed for v1 (see Increment 3).
 - **Status-gated injection (mechanism (b), chosen).** A dedicated lightweight scheduled loop,
  **not** the worker `Injector`. It injects via `AgentControl.send(primaryTerminal, nudge)`
  (the same herdr `agent.send` = `pane send-text` + submit that delivers to workers) only when
@@ -93,10 +93,10 @@ A `ReplyPushLoop` component, notified at the single no-waiter call site
  the reply remains in the durable inbox and the next natural poll (or a later worker reply's
  nudge) still surfaces it. Bounded so the bridge never spams the primary.

-### Increment 3 — optional per-`msgId` `fleet_ack` tool (deferred)
+### Increment 3 — optional per-`msgId` `bridge_ack` tool (deferred)

 Drain-as-ack is coarse: it clears *all* pending replies for a target at once. If finer
-control is ever needed (ack one reply, leave others held), add a `fleet_ack(msgId)` tool
+control is ever needed (ack one reply, leave others held), add a `bridge_ack(msgId)` tool
 mapping to `inbox.ack(target, msgId)` — the port already supports per-`msgId` ack. Not built
 in v1; the stop-on-empty loop is sufficient.

@@ -132,7 +132,7 @@ boundary**. The bridge is signalling the primary that it has mail — not drivin
  non-null terminal AND not a registered session" predicate; the loop's stop-on-empty and
  bounded-reminder logic with an injected clock + a fake injector (no real herdr).
 - **Live dogfood (primary-side):** with the daemon on the broker jar + a real worker,
-  delegate a task, let the worker reply after the `fleet_send` window closes, and observe the
+  delegate a task, let the worker reply after the `bridge_send` window closes, and observe the
  bridge inject a drain nudge into *this* primary pane; confirm draining stops the reminders;
  confirm an unreachable primary (registry empty) degrades to pull with no loss.

@@ -15,7 +15,7 @@ Consequences today:
  since when?" without shelling to herdr for a raw agent list (no state, no ownership, no age).
 - Cleanup of a worker that outlived its owning process depends entirely on the boot-time
  name-nonce **reaper** (CB-117) — there is no live, authoritative roster during a run.
- `fleet_list` (CB-304) can only surface herdr's view, not a bridge-owned roster.
+- `bridge_list` (CB-304) can only surface herdr's view, not a bridge-owned roster.
 - There is no seam for per-session policy (checkpoint on teardown → CB-302; idle_ttl /
  context_cap / drain → CB-303).

@@ -100,9 +100,9 @@ final class SessionManager {
  `TurnListener` alongside `CompletionResolver` so it sees turn boundaries, and give it the
  `WorkerPresence` signal for `READY`.
 - **`BridgeMcp.spawn` / `BridgedApp.spawnWorker`** — route spawn through `SessionManager.acquire`
-  (carry `callerTerminal` as `ownerTerminal`). **`fleet_stop` / `DELETE /workers/{paneId}`** →
+  (carry `callerTerminal` as `ownerTerminal`). **`bridge_stop` / `DELETE /workers/{paneId}`** →
  `SessionManager.release`.
- **`fleet_list` / `GET /sessions` (CB-304 later)** — read `SessionManager.roster()`.
+- **`bridge_list` / `GET /sessions` (CB-304 later)** — read `SessionManager.roster()`.
 - **`MessageService`** — no change required for one-shot; a later CB-303 auto-release hook can call
  `release` from `onTurnComplete` under policy.

@@ -121,4 +121,4 @@ final class SessionManager {
 - **CB-302** — attach a checkpoint step (`STATE.md` + commit) to the `release` path.
 - **CB-303** — a policy loop over `roster()` using `spawnedAtNanos`/state to auto-`release` on
  `idle_ttl`, or drain on `context_cap`.
- **CB-304** — `fleet_list` reads `roster()` for a bridge-owned roster + live join.
+- **CB-304** — `bridge_list` reads `roster()` for a bridge-owned roster + live join.
@@ -3,7 +3,7 @@
 **Status:** ✅ shipped — implemented at commit `97ecc71` (per-worker git worktree + config-parity
 overlay). As-built: `session/GitWorktrees.java` behind the `Worktrees` port, wired in
 `Bridged.main` and configurable via `worktreeRoot` / per-profile `parityOverlay`
-(see `bridged.example.yaml`). Branch/worktree surface in `fleet_list` landed with CB-304
+(see `bridged.example.yaml`). Branch/worktree surface in `bridge_list` landed with CB-304
 (`9fe04bf`); the worker-opened-PR checkpoint landed as CB-302 (`64e70ef`).
 **Extends:** [CB-301 Session Manager](CB-301-Session-Manager.md) (shipped, commit `54d907c`).
 **Realizes:** the config-parity requirement in [Worker Git Workflow](Worker-Git-Workflow.md).
@@ -122,7 +122,7 @@ public void release(String paneId) {

 ### Surface: MCP + REST

- `fleet_spawn` gains an optional `worktree` arg: `true`, or a ticket slug string. Truthy ⇒ build a
+- `bridge_spawn` gains an optional `worktree` arg: `true`, or a ticket slug string. Truthy ⇒ build a
  `WorktreeRequest(slug, null)` and call the 5-arg `acquire`.
 - `POST /workers` gains `worktree` (+ optional `ticket`) in the body/query, same mapping.
 - `workerView`/`view(WorkerSession)` include `worktree` and `branch` **when non-null** (omit for
@@ -6,11 +6,11 @@

 ## 1. Problem

-`fleet_spawn` today returns a session the instant the herdr pane is started. The pane is not
+`bridge_spawn` today returns a session the instant the herdr pane is started. The pane is not
 yet a usable Claude REPL — it may still be sitting at the folder-trust prompt, or the CLI may
 never come up at all. Nothing blocks or times out on that. Consequences:

- A `fleet_send` to a not-yet-ready worker surfaces as a **~60 s MCP-client timeout** (the send
+- A `bridge_send` to a not-yet-ready worker surfaces as a **~60 s MCP-client timeout** (the send
  blocks waiting for a turn that can't start) instead of a fast, explicit spawn failure.
 - A worker stuck at the folder-trust prompt lingers in `SPAWNING` forever; nothing fails it.

@@ -99,11 +99,11 @@ Jackson ignores unknown keys, so omitting them in existing YAML is safe; pick sa
  `spawn` throws — verify the new exception flows through it (worktree removed, nothing registered).
 - The **non-worktree** path registers the session only *after* `spawn` returns, so a throw means no
  half-live `SPAWNING` session is ever registered — confirm this and add a test.
- `fleet_spawn` (MCP verb) must return an **error result** carrying the exception message, not a
+- `bridge_spawn` (MCP verb) must return an **error result** carrying the exception message, not a
  success with a dead session. Trace `BridgeMcp`/`BridgedApp` spawn handlers and make sure the
  exception becomes a clean tool error, not an uncaught 500 with a stack trace.

-**Out of scope (do NOT do here):** gating `fleet_send` on session `READY` (existing status-gate +
+**Out of scope (do NOT do here):** gating `bridge_send` on session `READY` (existing status-gate +
 this spawn gate already close the window), MCP-handshake-as-readiness signal, the CB-307 broker,
 any config `kind:` discriminator, any second adapter.

@@ -13,7 +13,7 @@ Stage 2 (the AMQP/LavinMQ adapter behind the same port) is explicitly **out of s
 ## 1. The bug this fixes (grounded in current code)

 The reverse (worker→primary) path is `Rendezvous` — a `ConcurrentHashMap<session, CompletableFuture<Resolution>>`
-of **live blocking waiters only**. No queue, no store. When a worker calls `fleet_reply` and **no send
+of **live blocking waiters only**. No queue, no store. When a worker calls `bridge_reply` and **no send
 is currently open** for that worker:

 - `Rendezvous.resolve(session, content)` → `complete(...)` → `waiters.get(session) == null` →
@@ -22,7 +22,7 @@ is currently open** for that worker:
  `BridgeMcp.reply` returns `error("no send is awaiting a reply for this worker")` (`mcp/BridgeMcp.java:270-272`);
  REST returns `409 no_pending_send` (`rest/BridgedApp.java:339-345`).

-This is the observed "communication break": a worker that finishes just after its `fleet_send` timed
+This is the observed "communication break": a worker that finishes just after its `bridge_send` timed
 out (the ~60s sync window) replies into the void. There is **no message-id, dedup, or ack** anywhere in
 the message path today.

@@ -79,7 +79,7 @@ in `MessageService`, which already owns the `Rendezvous` and will own the `Reply

 - Add `MessageService.reply(String session, String content)`:
  ```java
-  /** Route a worker's explicit fleet_reply: resolve an open send, or queue it in the inbox if none. */
+  /** Route a worker's explicit bridge_reply: resolve an open send, or queue it in the inbox if none. */
  public boolean reply(String session, String content) {
      if (rendezvous.resolve(session, content)) {
          return true;                       // a live send took it — unchanged fast path
@@ -94,7 +94,7 @@ in `MessageService`, which already owns the `Rendezvous` and will own the `Reply
  - `BridgedApp.replyMessage` (`rest/BridgedApp.java:330-346`) — return `200` (queued) instead of
    `409 no_pending_send`.

-**DO NOT touch the QUESTION path.** `fleet_ask` / `rendezvous.resolveQuestion` must keep today's
+**DO NOT touch the QUESTION path.** `bridge_ask` / `rendezvous.resolveQuestion` must keep today's
 `NO_WAITER` behaviour — a mid-turn question is **interactive** (the worker blocks synchronously and cannot
 consume a late answer), so it must **never** be queued. Only terminal `REPLY`s go to the inbox.

@@ -110,11 +110,11 @@ The primary re-checks a worker it delegated to. Expose a drain keyed by **worker
 - Add `MessageService.drainReplies(String target)`: `peek` the inbox, `ack` each returned `msgId`, hand
  back the `List<InboxMessage>` (or just the contents). At-least-once: peek→deliver→ack (ack only after
  the caller has them, so an in-flight failure re-surfaces them).
- **DECISION (required default): expose via the existing poll verb, keyed by target.** Extend `fleet_poll`
+- **DECISION (required default): expose via the existing poll verb, keyed by target.** Extend `bridge_poll`
  to accept an optional `target` (worker session) and, when present, return that worker's drained replies —
  alongside a matching REST route `GET /sessions/{id}/replies`. Do **not** change `send`/`answer` semantics
  (do not drain inside `send` — that conflates "deliver to worker" with "collect its mail"). Keep the
-  existing ticket-based `fleet_poll(ticket)` path working unchanged. If you see a cleaner surface, still
+  existing ticket-based `bridge_poll(ticket)` path working unchanged. If you see a cleaner surface, still
  ship this default and note the alternative for review.

 ## 3. Config
@@ -126,11 +126,11 @@ Stage-2 AMQP adapter: absent → in-memory, present → AMQP).
 ## 4. Acceptance criteria (what the primary will verify)

 1. New `ReplyInbox` + `InboxMessage` + `InMemoryReplyInbox` in `dev.ltms.bridged.msg`.
-2. `fleet_reply` with **no open send** now **succeeds and queues** (no more `error` / `409`); the reply is
+2. `bridge_reply` with **no open send** now **succeeds and queues** (no more `error` / `409`); the reply is
   later retrievable and identical.
 3. The queued reply is drainable by the primary keyed by target; draining **acks** it (a second drain
   returns nothing); dedup by `msgId` (re-publishing the same id does not double-queue).
-4. **QUESTION path unchanged** — `fleet_ask` with no open send still returns `NO_WAITER` (add/keep a test
+4. **QUESTION path unchanged** — `bridge_ask` with no open send still returns `NO_WAITER` (add/keep a test
   proving a question is never queued).
 5. Completion/failure fallbacks unchanged.
 6. Unit tests covering: `InMemoryReplyInbox` publish/peek/ack/dedup/FIFO/concurrency; `MessageService.reply`
@@ -111,7 +111,7 @@ host's terminals.*

 ```mermaid
 flowchart LR
-    send["fleet_send(globalId, msg)"] --> lookup{"directory:<br/>is globalId local?"}
+    send["bridge_send(globalId, msg)"] --> lookup{"directory:<br/>is globalId local?"}
    lookup -->|"yes"| local["inject via local herdr<br/>(today's Injector path)"]
    lookup -->|"no"| pub["publish agent.&lt;id&gt;.inbox<br/>(broker routes to owning gateway)"]
    pub --> consume["owning gateway consumes<br/>→ injects into its local herdr"]
@@ -158,17 +158,17 @@ sequenceDiagram
    participant BR as broker
    participant GA as gateway A
    participant P as primary (host A, MCP client)
-    W->>GB: fleet_reply
+    W->>GB: bridge_reply
    GB->>BR: publish primary-bound (durable, msg id)
    BR->>GA: route to A's primary inbox
    Note over GA: held durably until the primary pulls
-    P->>GA: blocking fleet_send resolves / fleet_poll
+    P->>GA: blocking bridge_send resolves / bridge_poll
    GA-->>P: reply (then ACK to broker)
 ```

 *Figure 4 — the broker makes the middle hop lossless, ordered, and idempotent; the **final** hop
 into the primary is still a **pull** (gateway A holds the message until the primary's blocking
-`fleet_send` or `fleet_poll`). Cross-host neither improves nor worsens this — it just spans hosts.
+`bridge_send` or `bridge_poll`). Cross-host neither improves nor worsens this — it just spans hosts.
 This is precisely the gap CB-307 closes on one host and CB-308 stretches across hosts.*

 ## 6. Staging & dependencies
@@ -207,7 +207,7 @@ they overlap (notably: the envelope is no longer optional, and dedup is split by
   gateway's host. This extends the single-host invariant — *identity comes from the connection,
   never an argument* — across the broker: cross-host, identity comes from the key. Complements
   (not replaces) per-gateway broker logins over TLS.
-2. **Profiles are owned by the worker's host.** `fleet_spawn(profile, host)` resolves the name in
+2. **Profiles are owned by the worker's host.** `bridge_spawn(profile, host)` resolves the name in
   the *target* gateway's `bridged.yaml`. Gateways advertise their profile names in presence
   heartbeats, so a leader sees what each host offers before spawning; an unknown name is a clear
   error from the target. Secrets (base URLs, tokens) never leave the host that uses them.
@@ -259,7 +259,7 @@ they overlap (notably: the envelope is no longer optional, and dedup is split by
   serialize acks fleet-wide. Ordering caveat: a *return* (unroutable) arrives **before** the
   confirm, so "confirmed" ≠ "routed"; the sender checks the returned-set at confirm time.
   `mandatory` is false only for `BROADCAST`, where an empty group is legal silence.
-10. **Queue lifecycle is session lifecycle.** `fleet_stop`/reap deletes the worker's inbox queue
+10. **Queue lifecycle is session lifecycle.** `bridge_stop`/reap deletes the worker's inbox queue
    (its `broadcast.*` bindings die with it — no broadcasts to the dead); `x-expires` collects
    queues orphaned by a crashed gateway (long for main/orchestrator inboxes, short for workers).
    Queue names carry a version suffix (`.v2`): AMQP refuses to redeclare an existing durable
@@ -7,7 +7,7 @@ the core learning any one peer's environment.
 ## 1. Why

 `claude-bridge` is a **communication bus between heterogeneous AI agents** — its stable surface is
-the protocol (`fleet_spawn / send / poll / reply / ask / list / stop / status`), and that surface
+the protocol (`bridge_spawn / send / poll / reply / ask / list / stop / status`), and that surface
 should stay provider-neutral. Today the daemon can only materialize one kind of peer: an
 off-subscription Claude Code CLI over herdr. Everything specific to *how that peer is set up*
 (`ANTHROPIC_BASE_URL`, the subscription guard, `--mcp-config`/system-prompt flags, `claude-*`
@@ -126,7 +126,7 @@ existing configs. (Jackson already ignores unknown keys, so adding `kind` is bac

 ```mermaid
 sequenceDiagram
-    participant MCP as fleet_spawn (MCP/REST)
+    participant MCP as bridge_spawn (MCP/REST)
    participant SM as SessionManager
    participant L as PeerLauncher (by profile.kind)
    participant T as transport (herdr)
@@ -150,7 +150,7 @@ degrades gracefully when a launcher lacks one:

 | Capability | Meaning | Claude Code | Codex (likely) | Human |
 |---|---|---|---|---|
-| `MID_TURN_ASK` | supports `fleet_ask` rendezvous | ✓ | ? | ✗ |
+| `MID_TURN_ASK` | supports `bridge_ask` rendezvous | ✓ | ? | ✗ |
 | `SELF_PR` | can open its own PR at checkpoint (CB-302) | ✓ (opt-in token) | ? | ✗ |
 | `WORKTREE` | can run in a provisioned git worktree | ✓ | ✓ | ✗ |
 | `ORPHAN_REAP` | spawner can reconcile orphaned peers on boot | ✓ | ? | ✗ |
@@ -184,7 +184,7 @@ sequenceDiagram
    participant O as OpenCodeLauncher
    participant B as HerdrPeerLauncher (base)
    participant H as herdr
-    P->>M: fleet_spawn(profile="oc-impl")
+    P->>M: bridge_spawn(profile="oc-impl")
    M->>C: spawn(SpawnRequest)
    C->>C: kind(profile)=="opencode"
    C->>O: spawn(req)
@@ -226,11 +226,11 @@ until it is "major" (Stage-B whole), per the CB-401 bar.
 - **opencode TUI ⇄ herdr injection.** herdr drives a pane by typing into a TUI. Must confirm
  opencode's TUI accepts injected keystrokes/submit the way `claude` does, and reaches an
  `injectable` status the CB-306 gate recognizes. *Validation:* spawn one opencode worker,
-  watch the readiness gate pass, `fleet_send` a trivial task.
+  watch the readiness gate pass, `bridge_send` a trivial task.
 - **Bridge MCP visibility in opencode.** Confirm `OPENCODE_CONFIG` (or `opencode mcp add`)
-   actually surfaces the `fleet_*` tools inside the opencode session, and that `fleet_reply`
+  actually surfaces the `bridge_*` tools inside the opencode session, and that `bridge_reply`
  is callable — the reply-charter is worthless if the tool isn't mounted. *Validation:* the
-  worker completes a task by calling `fleet_reply`; the reply lands via the CB-307 path.
+  worker completes a task by calling `bridge_reply`; the reply lands via the CB-307 path.
 - **opencode MCP/config schema drift.** opencode is fast-moving (1.1.31 today). Pin the config
  schema we generate against the installed version; treat the exact keys (`type: "remote"` vs
  `"http"`, `instructions` shape) as a dogfood-verified fact, not an assumption.
@@ -281,7 +281,7 @@ as a dogfood-verified fact for 1.18.5.
 | §5 risk | Result |
 |---|---|
 | opencode TUI ⇄ herdr injection; CB-306 gate | ✅ `peer pane=wD:p3 reached injectable state` ~0.6s after `agent.start` |
-| Bridge MCP visible + `fleet_reply` callable | ✅ MCP `initialize` from `Implementation[name=opencode, version=1.18.5]`; worker replied through the tool |
+| Bridge MCP visible + `bridge_reply` callable | ✅ MCP `initialize` from `Implementation[name=opencode, version=1.18.5]`; worker replied through the tool |
 | Config schema drift (1.1.31 → 1.18.5) | ✅ unchanged, see above |
 | Provider credentials | ✅ free tier, zero credentials |

@@ -291,7 +291,7 @@ Full lifecycle exercised through the REST surface:
   to `OpenCodeLauncher` (`spawning opencode profile=opencode-free`), pane `wD:p3`.
 2. Readiness: `{"ready":true,"status":"idle"}`, roster state `ready`.
 3. `POST /sessions/{id}/message` → **`{"replySource":"reply","reply":"391"}`** — a *structured*
-   `fleet_reply`, not the CB-115 completion-fallback transcript scrape. The clean path.
+   `bridge_reply`, not the CB-115 completion-fallback transcript scrape. The clean path.
 4. `DELETE /workers/wD:p3` → `204`, roster empty, tolerant teardown (`tab_not_found` ignored —
   opencode had already closed its own tab).

@@ -45,7 +45,7 @@ flowchart TB
    w1["worker pane (gx00 vLLM)"]
    w2["worker pane (ollama)"]
    human --> primary
-    primary -->|"fleet_send / spawn / ask"| daemon
+    primary -->|"bridge_send / spawn / ask"| daemon
    daemon --> comp
    comp --> cc
    comp --> oc
@@ -150,7 +150,7 @@ sequenceDiagram
    participant SL as SandboxLauncher
    participant SB as sandbox (peer-owned)
    participant A as agent in sandbox
-    M->>D: fleet_spawn(profile=backend, role=backend)
+    M->>D: bridge_spawn(profile=backend, role=backend)
    D->>SL: spawn(SpawnRequest)
    SL->>SB: start entrypoint (image = backend role)
    Note over SL,SB: bridge injects guarded ANTHROPIC_BASE_URL,<br/>mounts bridge MCP url + reply charter
@@ -213,12 +213,12 @@ sequenceDiagram
    participant MA as main A (Opus)
    participant BR as bridged / broker
    participant MB as main B (cloud)
-    MA->>BR: fleet_send(to = main B, msg)
+    MA->>BR: bridge_send(to = main B, msg)
    BR->>BR: publish agent.B.inbox (durable, msg id)
    Note over BR: held until B pulls (B is a client too)
-    MB->>BR: blocking fleet_send / poll resolves
+    MB->>BR: blocking bridge_send / poll resolves
    BR-->>MB: msg (then ACK)
-    MB->>BR: fleet_reply(to = main A)
+    MB->>BR: bridge_reply(to = main A)
    BR->>BR: publish agent.A.inbox
    MA->>BR: poll resolves
    BR-->>MA: reply
@@ -287,7 +287,7 @@ sequenceDiagram
    H->>O: high-level goal (large context)
    O->>O: name/resume main A session
    O->>MA: task + SCOPED context slice (not the whole history)
-    MA->>W: fleet_send(delegation, carrying only the relevant slice)
+    MA->>W: bridge_send(delegation, carrying only the relevant slice)
    W-->>MA: result
    MA-->>O: rollup
    O->>O: fold into orchestrator context, pick next main/turn
@@ -440,13 +440,13 @@ sequenceDiagram
    participant BR as broker
    participant GB as gateway B
    participant SB as sandbox agent (host B, container)
-    MA->>GA: fleet_send(globalId on B, msg)
+    MA->>GA: bridge_send(globalId on B, msg)
    GA->>GA: directory lookup - is globalId local? NO
    GA->>BR: publish agent.ID.inbox (durable)
    BR->>GB: route to the owning gateway
    GB->>SB: inject via B's LOCAL herdr (keystrokes)
    Note over GB,SB: SandboxLauncher already spawned the container -<br/>its PTY is in B's herdr, CB-306 readiness passed
-    SB-->>GB: fleet_reply (to B's LOCAL MCP endpoint)
+    SB-->>GB: bridge_reply (to B's LOCAL MCP endpoint)
    GB->>BR: publish primary-bound (durable, msg id)
    BR->>GA: route back to A
    Note over GA: held until the main pulls (the main is a client)
@@ -196,7 +196,7 @@ every member spawn. The wiki keeps the direct route open precisely because "if t
 nothing that matters is blocked."

 So keep it. Add a second profile `local-direct` pointing at `http://gx00.gw:8000` with **`weight: 0`**
-— never auto-selected, still spawnable with an explicit `fleet_spawn{profile: "local-direct"}`.
+— never auto-selected, still spawnable with an explicit `bridge_spawn{profile: "local-direct"}`.
 That is exactly what CB-554 made `weight: 0` mean, and it turns the escape hatch into something the
 lead can actually reach during an incident.

@@ -266,7 +266,7 @@ Each of these cost someone real debugging time upstream. They apply to us.
 1. **Rotating a token restarts the auth proxy, which drops in-flight streaming responses.** For us
   that means rotating `AI_GATEWAY_TOKEN` kills every live member mid-turn, and an async ticket's
   report goes with it. This is the same rule as a daemon redeploy: **drain the fleet first**
-   (`fleet_list` → `fleet_poll` anything wanted → `fleet_stop`), then rotate.
+   (`bridge_list` → `bridge_poll` anything wanted → `bridge_stop`), then rotate.
 2. **The gateway's own `SecurityPolicy` fails open.** Standalone `aigw run` accepts it and silently
   ignores it — an unauthenticated request returned **200**. Auth is the Caddy proxy in front, and
   nothing else. Never reason as if the gateway authenticates.
@@ -283,10 +283,10 @@ Each of these cost someone real debugging time upstream. They apply to us.

 Merging config is not proving it. The checks, in order:

-1. `fleet_spawn{profile: "gx"}` succeeds and the member completes a real turn ending in
-   `fleet_reply`. This is the first proof of the token, the URL and the model name, and it risks
+1. `bridge_spawn{profile: "gx"}` succeeds and the member completes a real turn ending in
+   `bridge_reply`. This is the first proof of the token, the URL and the model name, and it risks
   nothing the fleet depends on.
-2. `fleet_spawn{profile: "local"}` succeeds. If the guard allowlist was missed, this **throws** — a
+2. `bridge_spawn{profile: "local"}` succeeds. If the guard allowlist was missed, this **throws** — a
   loud, self-correcting failure, which is the good kind. If the restart was missed, it also throws,
   for the same reason.
 3. A `local` member completes a turn. That exercises streaming through two TLS edges, the auth proxy
@@ -297,9 +297,9 @@ Merging config is not proving it. The checks, in order:
   deltas. For `gx` on `/v1`, this answers the open question in §3 rather than assuming it.
 5. The cockpit at `auth.ltms.dev` shows requests counted against the `claude-bridge` consumer, not
   `legacy`. That is the whole point of taking our own token.
-6. `fleet_spawn{profile: "local-direct"}` still works, so the escape hatch is real rather than
+6. `bridge_spawn{profile: "local-direct"}` still works, so the escape hatch is real rather than
   theoretical.
-7. `fleet_list` shows `gx` carrying no `credentialId`, so a `sol`/`terra` exhaustion cannot
+7. `bridge_list` shows `gx` carrying no `credentialId`, so a `sol`/`terra` exhaustion cannot
   quarantine it. This is the single-point-of-failure claim in §3b, checked rather than asserted.

 ---
@@ -172,7 +172,7 @@ The current split is the mirror image of what you'd expect:
 | REST routes | ❌ **none at all** — the session id is taken from the URL path and trusted | ❌ none |

 So REST is the *more* exposed surface: `POST /sessions/{id}/reply` accepts any `{id}` from the
-path, whereas the MCP `fleet_reply` derives the worker from the connection and refuses to read it
+path, whereas the MCP `bridge_reply` derives the worker from the connection and refuses to read it
 from an argument. Loopback-only bind is what makes this safe today.

 **Therefore CB-505 must enforce on both paths against one shared resolver** — not at a single
@@ -1,7 +1,7 @@
 # M4 - Fleet health, recovery, routing, and capacity

 **Status:** Design accepted on 2026-08-15. CB-573 part 1 has shipped the classification model and
-the `fleet_list` capacity view; the remaining M4 units are not yet shipped. See
+the `bridge_list` capacity view; the remaining M4 units are not yet shipped. See
 [Unit 2 — what has landed so far](#unit-2---what-has-landed-so-far) before planning Unit 2 work:
 some of its criteria were met by separate CB tickets, and one of them contradicts the unit text.
 **Scope:** Fleet evidence, safe mechanical repair, lead routing, capacity reporting, and optional
@@ -145,7 +145,7 @@ Idle may drive configured resource cleanup. It never opens an incident and never
 | `TURN_BOUNDARY_LOST` | Same session turn stays `BUSY`; same accepted task stays open; two raw snapshots show `IDLE` or `DONE` | Strong disagreement. Strict reconciliation may repair it. |
 | `ERROR_ON_SCREEN` | Suspicious non-working state survives grace; `detection` matches a tested adapter-specific fatal signature | Certain only for the matched signature. A bare word such as `Exception` is not enough. |
 | `STALL_SUSPECTED` | Open turn is older than the configured threshold; two normalised `recent_unwrapped` digests are unchanged; no boundary or reply occurs | Not certain. A long valid API call can look the same. Lead decides. |
-| `MUTE` | Turn resolves through completion fallback instead of `fleet_reply` | Certain that no structured reply won. It does not prove an MCP failure. A single event is a metric, not an incident. |
+| `MUTE` | Turn resolves through completion fallback instead of `bridge_reply` | Certain that no structured reply won. It does not prove an MCP failure. A single event is a metric, not an incident. |
 | `REPLY_STRANDED` | Typed reply or health message remains after owning-lead push reaches its cap | Collection failed. This does not explain whether the lead is busy, dead, or ignoring the nudge. |
 | `DELEGATION_ORPHANED` | Target is gone, failed, or released, but one or more tasks remain `PENDING` after reconciliation grace | Certain bridge invariant failure. This is not an inbox-drain fault. |
 | `WORK_PRODUCT_AT_RISK` | Provisioned branch has commits after its recorded base; member is `DONE`, `FAILED`, or preserved after release; no turn or inbox item remains; long-idle threshold passed | A warning, not proof of loss. Work may already have an open pull request or a squash merge. |
@@ -230,8 +230,8 @@ Only the lead may:
 - choose how to use partial work in a worktree;
 - restart herdr or change network, model, credentials, backend, or configuration.

-Reports include literal safe tool calls such as `fleet_status(sessionId="...")`,
-`fleet_poll(ticket="...")`, `fleet_list()`, and optional `fleet_stop(paneId="...")`. A judgement
+Reports include literal safe tool calls such as `bridge_status(sessionId="...")`,
+`bridge_poll(ticket="...")`, `bridge_list()`, and optional `bridge_stop(paneId="...")`. A judgement
 state never presents stop as the only action.

 ### 5.3 Release causes and worktree safety
@@ -251,7 +251,7 @@ preserving cause.

 Before abnormal release removes the live session, M4 writes an atomic manifest under the worktree
 root. It records session identity, owner, role, profile, repository, path, branch, base commit,
-release cause, release time, state, and pending task ids. `fleet_list.preservedWorktrees` loads these
+release cause, release time, state, and pending task ids. `bridge_list.preservedWorktrees` loads these
 manifests after restart. Stop output and WARN logs also name the path and cause. M4 never
 auto-deletes a preserved worktree.

@@ -348,7 +348,7 @@ Invalid known-format data is copied byte-for-byte to durable queue
 before the original is acknowledged. A failed quarantine handoff leaves the original unacknowledged.
 The raw body never enters logs.

-Decode failure creates a redacted WARN, metric, `fleet_list` summary, and routed health incident.
+Decode failure creates a redacted WARN, metric, `bridge_list` summary, and routed health incident.
 One bad entry never escapes the consumer callback and never stops later valid messages.

 Safe downgrade is not supported. The previous build ignores `content_type` and would show typed JSON
@@ -399,13 +399,13 @@ Choose the candidate with the fewest assigned foreign incidents. Break ties by s
 then terminal id. Pin the recipient. Reassign only if that peer becomes unhealthy or retires. A
 routing generation marks a reassignment, and old pending assignments become superseded.

-`fleet_list` lead rows show health, health age, assigned foreign incident count, and a bounded list
+`bridge_list` lead rows show health, health age, assigned foreign incident count, and a bounded list
 of incident id, subject, state, severity, age, and routing generation. The top-level view also shows
 owner, recipient, and routing reason.

 A peer incident is published under the recipient lead's inbox key, not the failed subject's key. Its
 status-gated nudge names the failed lead and gives the exact
-`fleet_poll(target="<recipient-terminal>")` call.
+`bridge_poll(target="<recipient-terminal>")` call.

 ### 7.5 Lead inbox ownership

@@ -427,7 +427,7 @@ An idle, reachable lead may receive the existing bounded nudge. An unreachable o
 has no safe in-loop recovery. The bridge must not restart or replace it. A new lead would not have the
 failed lead's plan or context, and an uncertain relaunch could create two orchestrators.

-With no webhook, only `fleet_list`, `/healthz`, metrics, WARN logs, and the incident journal remain.
+With no webhook, only `bridge_list`, `/healthz`, metrics, WARN logs, and the incident journal remain.
 These are passive surfaces. They are not a human notification.

 ## 8. Lost-boundary reconciliation
@@ -521,7 +521,7 @@ task poll source, and metrics. The lead sees:

 ```text
 [repaired completion - bridged detected a lost turn boundary. The member did not call
-fleet_reply; pane-derived text follows and may be partial]
+bridge_reply; pane-derived text follows and may be partial]
 ```

 Clipped text also keeps the existing clipped-tail marker.
@@ -551,7 +551,7 @@ failure operation once. It never recreates the task.

 Capacity is a view, not a health state.

-`fleet_list` adds one block per profile:
+`bridge_list` adds one block per profile:

 ```text
 profile, maxLoad, live, free, reclaimable
@@ -612,7 +612,7 @@ incident feeds lead-health evidence. If the lead then becomes unhealthy, peer or
 Webhook mode requires a resolved environment variable. Turning notification off stops outbound
 attempts but keeps incidents. Turning it back on resumes still-open human incidents.

-Without a sink, `fleet_list.healthCoverage` states that human escalation is unavailable. `/healthz`
+Without a sink, `bridge_list.healthCoverage` states that human escalation is unavailable. `/healthz`
 keeps its existing HTTP liveness result and adds a nested `fleetHealth.status=partial` component.
 Metrics and one startup or reload WARN expose the same limit.

@@ -792,7 +792,7 @@ Acceptance criteria:
    them.
 16. Explicit stop is state-aware. Any pending task or non-terminal state preserves the worktree.
 17. Atomic preserved-worktree manifests reload after restart and appear in lead-only
-    `fleet_list.preservedWorktrees`.
+    `bridge_list.preservedWorktrees`.
 18. Manifest failure preserves the worktree and opens an operator-visible health failure.
 19. Provision records the base commit. Terminal, long-idle worktrees report
    `WORK_PRODUCT_AT_RISK` only under the evidence in Section 4.2 and never auto-delete work.
@@ -820,7 +820,7 @@ met, and I did not run one.
 | 14 | `DELEGATION_ORPHANED` | 3 files | **Partial.** The health state exists. The teardown-invariant check that creates it, and the retry rule, do not. |
 | 15 | `SPAWN_ROLLBACK` | 0 files | **Contradicted — see below.** |
 | 16 | — | — | Partial at best. CB-576 made release preserve a dirty worktree; whether explicit stop is state-aware is not checked. |
-| 17, 18 | `preservedWorktrees` | 0 files | Not started. No manifest, and no lead-only `fleet_list` field. |
+| 17, 18 | `preservedWorktrees` | 0 files | Not started. No manifest, and no lead-only `bridge_list` field. |
 | 19 | `WORK_PRODUCT_AT_RISK` | 0 files | Not started. |

 **Criterion 15 no longer matches the code, and the code is right.** It says "normal `COMPLETED`
@@ -837,7 +837,7 @@ preserve it. `SPAWN_ROLLBACK` itself does not exist yet.
 ### Unit 3 - Typed inbox and member routing

 Scope: semantic record, AMQP migration, both adapters, member routing, polling, and member health in
-`fleet_list`.
+`bridge_list`.

 Acceptance criteria:

@@ -852,7 +852,7 @@ Acceptance criteria:
 6. Invalid known data never escapes the callback, appears as a reply, or blocks later valid messages.
 7. Invalid data reaches durable per-target quarantine before original ack. Failed handoff leaves the
   original unacked.
-8. Decode failures create redacted WARN, metric, `fleet_list` summary, and routed incident without
+8. Decode failures create redacted WARN, metric, `bridge_list` summary, and routed incident without
   raw content.
 9. Both adapters pass one semantic contract for fields, FIFO, dedup, ownership, ack, and release.
 10. Lead keys require explicit ownership. Publication never claims a queue.
@@ -865,7 +865,7 @@ Acceptance criteria:
 15. RabbitMQ contract tests pass with `mvn test -Pcontract`. The same cases run once on production
    LavinMQ, or the release states that LavinMQ was not checked.
 16. Member incidents route to the exact delegating lead and never resolve a task rendezvous.
-17. `fleet_list` shows compact member health and capacity without pane content. Member
+17. `bridge_list` shows compact member health and capacity without pane content. Member
    `idleForSeconds` is present only when no accepted turn or inbox item exists.

 ### Unit 4 - Lead health and peer routing
@@ -887,7 +887,7 @@ Acceptance criteria:
 8. A selected working peer is not interrupted. Its push waits for an injectable window.
 9. Recipient assignment stays pinned. Reassignment increments generation and supersedes old pending
   assignment.
-10. `fleet_list` shows bounded foreign assignments, recipient, reason, and generation without pane
+10. `bridge_list` shows bounded foreign assignments, recipient, reason, and generation without pane
    content.
 11. `LeadInboxRegistry` owns configured and discovered lead keys before publication.
 12. Missing leads keep ownership. Retirement needs an empty queue and handled incidents.
@@ -911,7 +911,7 @@ Acceptance criteria:
 3. Webhook mode requires a resolved environment value. Bad notification config does not disable an
   already valid detector.
 4. Mode changes keep open incidents. Re-enable resumes eligible incidents.
-5. `fleet_list`, `/healthz`, metrics, and one WARN show partial coverage without a sink. HTTP
+5. `bridge_list`, `/healthz`, metrics, and one WARN show partial coverage without a sink. HTTP
   liveness behavior stays unchanged.
 6. One-lead, no-sink coverage states that lead failure has no active notification or recovery.
 7. Incident and outbound dedupe use the stable keys in Section 10.3.
@@ -220,17 +220,17 @@ sequenceDiagram
    participant H as herdr
    participant W as Worker (Claude)

-    P->>B: fleet_send("do X", target=w) — blocks
+    P->>B: bridge_send("do X", target=w) — blocks
    B->>B: register waiter(w)
    B->>H: agent.send(w, "do X")  (idle window)
    H-->>W: prompt injected
    W->>W: works the turn
-    W->>B: fleet_reply("result")
+    W->>B: bridge_reply("result")
    B->>B: resolve waiter(w)
    B-->>P: { outcome:"reply", text:"result" }
 ```

-### 6.2 Clarification — reverse rendezvous (`fleet_ask`)
+### 6.2 Clarification — reverse rendezvous (`bridge_ask`)

 The worker pauses mid-turn to ask; the primary answers; the worker resumes in the same turn.

@@ -240,14 +240,14 @@ sequenceDiagram
    participant B as bridged
    participant W as Worker

-    P->>B: fleet_send("do X", target=w) — blocks
+    P->>B: bridge_send("do X", target=w) — blocks
    B-->>W: "do X" (injected)
-    W->>B: fleet_ask("which config?") — worker blocks
+    W->>B: bridge_ask("which config?") — worker blocks
    B-->>P: { outcome:"question", text:"which config?", turn_id }
-    P->>B: fleet_send("config.yaml", target=w, turn_id) — blocks again
-    B-->>W: resolve fleet_ask → { answer:"config.yaml" }
+    P->>B: bridge_send("config.yaml", target=w, turn_id) — blocks again
+    B-->>W: resolve bridge_ask → { answer:"config.yaml" }
    W->>W: resumes same turn
-    W->>B: fleet_reply("done")
+    W->>B: bridge_reply("done")
    B-->>P: { outcome:"reply", text:"done" }
 ```

@@ -261,10 +261,10 @@ sequenceDiagram
    participant B as bridged
    participant W as Worker

-    P->>B: fleet_send("do X", target=w, block=false)
+    P->>B: bridge_send("do X", target=w, block=false)
    B-->>P: { outcome:"dispatched", dispatch_id }
    P->>P: continues its own work
-    W->>B: fleet_reply("result")
+    W->>B: bridge_reply("result")
    Note over B: no waiter → detached path
    B->>B: Injector.enqueue(primary_pane, "result")
    B-->>P: injected into idle pane (status-gated)
@@ -272,7 +272,7 @@ sequenceDiagram

 ### 6.4 Uncooperative worker — turn-done fallback

-A worker that never calls `fleet_reply` still returns a result: `bridged` reads its terminal
+A worker that never calls `bridge_reply` still returns a result: `bridged` reads its terminal
 tail when the turn completes.

 ```mermaid
@@ -281,9 +281,9 @@ sequenceDiagram
    participant B as bridged
    participant W as Worker

-    P->>B: fleet_send("do X", target=w) — blocks
+    P->>B: bridge_send("do X", target=w) — blocks
    B-->>W: "do X" (injected)
-    W->>W: works, never calls fleet_reply
+    W->>W: works, never calls bridge_reply
    B->>B: StatusPoller sees agent_status → idle/done
    B->>B: AgentControl.read(w, "recent")
    B-->>P: { outcome:"turn_done", text:<terminal tail> }
@@ -19,12 +19,12 @@ of this one.
 ## One gateway for all messages

 - **Everyone talks through the same door.** The leader and every worker connect to the same
-  MCP server and use only its tools: `fleet_whoami` · `fleet_profiles` · `fleet_spawn` ·
-  `fleet_list` · `fleet_status` · `fleet_send` · `fleet_reply` · `fleet_ask` ·
-  `fleet_poll` · `fleet_ack` · `fleet_stop`.
+  MCP server and use only its tools: `bridge_whoami` · `bridge_profiles` · `bridge_spawn` ·
+  `bridge_list` · `bridge_status` · `bridge_send` · `bridge_reply` · `bridge_ask` ·
+  `bridge_poll` · `bridge_ack` · `bridge_stop`.
 - **You are who your connection says you are.** The bridge finds out who is calling from the
  connection itself, never from a name the caller sends. So a worker cannot pretend to be
-  someone else, and `fleet_whoami` tells each agent its own role — no guessing.
+  someone else, and `bridge_whoami` tells each agent its own role — no guessing.
 - **The subscription line cannot be crossed.** Only a spawned worker gets
  `ANTHROPIC_BASE_URL`; the leader never does. Each worker profile has a list of allowed
  model hosts, checked before anything starts.
@@ -59,7 +59,7 @@ had to ask for its replies. That gap is now closed on a single machine:
 - **The leader gets a tap on the shoulder.** When a reply lands, the bridge nudges the
  leader's own pane — only when the leader is free, and only a few times. If the leader is on
  another machine, this quietly falls back to pick-up mode; the reply still waits.
- **Workers can ask questions.** With `fleet_ask`, a worker can pause mid-task, ask the
+- **Workers can ask questions.** With `bridge_ask`, a worker can pause mid-task, ask the
  leader something, and continue the *same* task with the answer.

 ## More than one kind of worker
@@ -20,7 +20,7 @@ requirement, not a nice-to-have.**
 - **Worktree provisioned by the daemon** — `SessionManager` creates a dedicated git worktree +
  branch per session, **hydrates it to full config parity** (below), and tears it down on release.
 - **Worker opens its own PR** — the worker commits, pushes its branch, and opens the PR/MR itself,
-  returning the PR URL in its `fleet_reply`.
+  returning the PR URL in its `bridge_reply`.

 ## Why worktrees (the hazard being fixed)

@@ -103,7 +103,7 @@ sequenceDiagram
    Note over W: implement in the isolated worktree
    W->>G: git commit + git push (SSH, same user)
    W->>G: open PR (branch to main)
-    W-->>P: fleet_reply (prUrl, branch, summary, tests)
+    W-->>P: bridge_reply (prUrl, branch, summary, tests)
    P->>SM: release(paneId)
    SM->>G: git worktree remove wt
    Note over G: branch + PR persist for review/merge
@@ -170,7 +170,7 @@ A worker-facing playbook (sibling to the existing `reviewer` skill):
 3. **Push** your branch (`git push -u origin HEAD`).
 4. **Open a PR** to `main` (option A `curl`, or the decided mechanism) with a title/body describing
   the change and referencing the ticket.
-5. **Reply** via `fleet_reply` with the **PR URL**, branch name, files changed, and test names —
+5. **Reply** via `bridge_reply` with the **PR URL**, branch name, files changed, and test names —
   that reply is the whole handoff.
 6. Do **not** merge; do **not** touch `.mcp.json` or `wiki/`.

@@ -14,7 +14,7 @@ rule that **a worker inherits the primary's directory** (never `$HOME`), and how

 ```mermaid
 flowchart TD
-    A["fleet_spawn / POST /workers"] --> B{"explicit cwd?<br/>(profile cwd or spawn arg)"}
+    A["bridge_spawn / POST /workers"] --> B{"explicit cwd?<br/>(profile cwd or spawn arg)"}
    B -->|"yes — told otherwise"| C["use that cwd"]
    B -->|"no"| D{"caller PID resolvable?<br/>(MCP peer PID)"}
    D -->|"yes"| E["cwd = the primary's cwd<br/>lsof -a -p PID -d cwd"]
@@ -51,7 +51,7 @@ only affect the seed shell, which the bridge closes).
 | # | Source | When |
 |---|--------|------|
 | 1 | Explicit `cwd` — a per-profile `cwd:` in config, or a spawn argument | "told otherwise" — pin a fixed workdir |
-| 2 | The **primary's cwd**, auto-detected from the `fleet_spawn` caller | normal MCP spawn from the primary |
+| 2 | The **primary's cwd**, auto-detected from the `bridge_spawn` caller | normal MCP spawn from the primary |
 | 3 | The `bridged` daemon's own cwd | REST spawn / off-host caller — **never `$HOME`** |

 The primary's cwd (source 2) is discoverable with no new plumbing: `bridged` already resolves the MCP
@@ -65,7 +65,7 @@ sequenceDiagram
    participant B as "bridged"
    participant O as "OS (lsof)"
    participant H as "herdr"
-    P->>B: "fleet_spawn {profile} (no cwd)"
+    P->>B: "bridge_spawn {profile} (no cwd)"
    B->>O: "peer PID for this connection's port"
    O-->>B: "pid"
    B->>O: "cwd of pid (lsof -d cwd)"
@@ -79,7 +79,7 @@ sequenceDiagram

 > **Status:** implemented (CB-112). `bridged` threads the resolved `cwd` onto **`agent.start {cwd}`**
 > (verified: the worker process is rooted there), keeping the single shared worker space. On an MCP
-> `fleet_spawn` the primary's cwd is auto-detected from the caller's PID; over REST (no MCP caller)
+> `bridge_spawn` the primary's cwd is auto-detected from the caller's PID; over REST (no MCP caller)
 > it is the explicit `cwd` param else the daemon's cwd. Both placements (`tab` and legacy `pane`)
 > carry it, since it rides `agent.start`.

@@ -133,5 +133,5 @@ unattended.

 ## See also

- `docs/MCP-Contract.md` — the tool surface (`fleet_spawn`, `fleet_profiles`, …).
+- `docs/MCP-Contract.md` — the tool surface (`bridge_spawn`, `bridge_profiles`, …).
 - `wiki/2-Message-Server.md` — the herdr `agent.*` / `workspace.*` schema (`workspace.create {cwd}`).
@@ -6,7 +6,7 @@ running `bridged` daemon**, captures the full transcript, and grades the channel

 This is the committed form of the ad-hoc channel test that discovered the CB-115 gaps
 (herdr `unknown` misclassification wedging delivery, dirty completion scrapes, and workers
-never calling `fleet_reply` in conversation). Run it after any change to the injector,
+never calling `bridge_reply` in conversation). Run it after any change to the injector,
 status handling, completion/failure paths, or the worker reply charter.

 ## What it exercises
@@ -28,7 +28,7 @@ sequenceDiagram
        T->>B: POST /sessions/{id}/message {wait:false}
        B-->>T: ticket
        B->>W: inject prompt (status-gated)
-        W-->>B: fleet_reply
+        W-->>B: bridge_reply
        T->>B: GET /tasks/{ticket}  (poll)
        B-->>T: done + reply
    end
@@ -68,7 +68,7 @@ Per-turn grade:

 | Grade      | Meaning                                                              |
 |------------|---------------------------------------------------------------------|
-| `OK`       | delivered and resolved by an explicit `fleet_reply` (`source=reply`) |
+| `OK`       | delivered and resolved by an explicit `bridge_reply` (`source=reply`) |
 | `DEGRADED` | delivered and answered, but resolved via completion-scrape fallback |
 | `EMPTY`    | turn completed but the reply was empty                              |
 | `FAILED`   | the worker's turn ended in failure (`phase=failed`)                 |
@@ -1,16 +1,16 @@
 #!/usr/bin/env python3
-"""Live bridge_ask test — the REVERSE rendezvous (CB-205), watched end to end.
+"""Live fleet_ask test — the REVERSE rendezvous (CB-205), watched end to end.

-Every other harness drives the forward path: primary `bridge_send` → worker `bridge_reply`.
+Every other harness drives the forward path: primary `fleet_send` → worker `fleet_reply`.
 This drives the one that runs the other way. A worker is told to pause its delegated turn,
-ask the primary a question via `bridge_ask`, and only finish once it has the answer — so the
+ask the primary a question via `fleet_ask`, and only finish once it has the answer — so the
 turn round-trips primary→worker→primary→worker inside a SINGLE delegation.

 The mechanics that only this path exercises:

  • a worker's mid-turn question surfacing on the primary's *own* blocked send (Outcome.QUESTION),
  • the `turnId` correlation that lets the primary answer the exact paused turn,
-  • the answer resuming that same turn and the worker's final `bridge_reply` landing on the
+  • the answer resuming that same turn and the worker's final `fleet_reply` landing on the
    re-opened forward waiter (never a stale or cross-wired one).

 It is two blocking REST calls, no polling:
@@ -57,14 +57,14 @@ ANSWER_COLOR = "blue"

 # A task that CANNOT be completed without asking: the worker is not told which color to choose,
 # only that the primary will name one when asked. So a correct final reply is only reachable by
-# actually calling bridge_ask and using the answer.
+# actually calling fleet_ask and using the answer.
 TASK_PROMPT = (
    "You are a bridge worker in a quick coordination game. You do NOT know which color to pick — "
    "only the primary does. Do exactly this, in order:\n"
-    "1. Call the `bridge_ask` tool with EXACTLY this question: \"PICK A COLOR: red or blue?\"\n"
+    "1. Call the `fleet_ask` tool with EXACTLY this question: \"PICK A COLOR: red or blue?\"\n"
    "2. The primary will answer with one color word. Take that color and uppercase it.\n"
-    "3. Call `bridge_reply` with EXACTLY one line: CHOSEN=<COLOR>  (e.g. CHOSEN=GREEN if told green).\n"
-    "Do not guess a color. Do not call bridge_reply before bridge_ask has returned an answer. "
+    "3. Call `fleet_reply` with EXACTLY one line: CHOSEN=<COLOR>  (e.g. CHOSEN=GREEN if told green).\n"
+    "Do not guess a color. Do not call fleet_reply before fleet_ask has returned an answer. "
    "Do nothing else — no file reads, no other tools."
 )

@@ -134,7 +134,7 @@ def run(base, profile, repo, send_timeout, answer_timeout):
    rec.update(tid=tid, pane=pane, spawned=True)
    await_ready(base, tid)

-    # 1) Delegate the ask-forcing task. This blocks until the worker calls bridge_ask, at which
+    # 1) Delegate the ask-forcing task. This blocks until the worker calls fleet_ask, at which
    #    point our own send unblocks carrying the question and the turnId to answer on.
    print(f"[{now()}] delegating task (blocks until the worker asks; up to {send_timeout}s)…")
    t0 = time.time()
@@ -159,7 +159,7 @@ def run(base, profile, repo, send_timeout, answer_timeout):
        rec.update(phase="no_turnid", detail="question surfaced without a turnId to answer on")
        return rec

-    # 2) Answer on that exact turn. This blocks again until the resumed worker calls bridge_reply.
+    # 2) Answer on that exact turn. This blocks again until the resumed worker calls fleet_reply.
    print(f"[{now()}] answering '{ANSWER_COLOR}' on turn {rec['turnId']} (blocks until reply; up to {answer_timeout}s)…")
    t1 = time.time()
    rec["phase"] = "awaiting_reply"
@@ -188,7 +188,7 @@ def run(base, profile, repo, send_timeout, answer_timeout):
 def grade(rec):
    """PASS only if the worker asked, the turn resumed, and the reply reflects the answer."""
    if rec["phase"] == "no_question":
-        return "NO_ASK", "the worker finished/stalled without ever calling bridge_ask"
+        return "NO_ASK", "the worker finished/stalled without ever calling fleet_ask"
    if rec["phase"] in ("send_error", "answer_error", "spawn"):
        return "ERROR", rec.get("detail") or "transport error before the round-trip completed"
    if rec["phase"] == "no_turnid":
@@ -203,7 +203,7 @@ def grade(rec):
            return "OK", "asked, resumed the same turn, and the reply reflected the primary's answer"
        if reflected:
            return "DEGRADED", f"reply reflected the answer but resolved via {rec['replySource']} " \
-                               "(worker did not call bridge_reply cleanly)"
+                               "(worker did not call fleet_reply cleanly)"
        return "WRONG_ANSWER", f"the worker replied but did not reflect '{ANSWER_COLOR}' — " \
                               f"the answer may not have reached the resumed turn: {rec['reply']!r}"
    return "WEDGE", f"unexpected terminal phase {rec['phase']}: {rec.get('detail')}"
@@ -213,16 +213,16 @@ def write_transcript(out_dir, rec, meta):
    path = out_dir / "bridge_ask_transcript.md"
    g, note = grade(rec)
    with path.open("w") as f:
-        f.write(f"# Live bridge_ask — reverse rendezvous — {datetime.now():%Y-%m-%d %H:%M}\n\n")
+        f.write(f"# Live fleet_ask — reverse rendezvous — {datetime.now():%Y-%m-%d %H:%M}\n\n")
        f.write(f"One worker paused its delegated turn to ask the primary, then resumed with the "
                f"answer (profile `{meta['profile']}`). Result: **`{g}`**.\n\n")
        f.write("## Round-trip\n\n")
        f.write(f"1. **primary → worker** (delegation): the ask-forcing task.\n")
-        f.write(f"2. **worker → primary** (`bridge_ask`, {rec.get('ask_latency')}s): "
+        f.write(f"2. **worker → primary** (`fleet_ask`, {rec.get('ask_latency')}s): "
                f"{rec.get('question')!r} — surfaced on the primary's blocked send as a "
                f"`question` with `turnId={rec.get('turnId')}`.\n")
        f.write(f"3. **primary → worker** (answer on that turn): `{ANSWER_COLOR}`.\n")
-        f.write(f"4. **worker → primary** (`bridge_reply`, {rec.get('answer_latency')}s, "
+        f.write(f"4. **worker → primary** (`fleet_reply`, {rec.get('answer_latency')}s, "
                f"source={rec.get('replySource')}): {rec.get('reply')!r}\n\n")
        f.write(f"> **{g}:** {note}\n")
        if rec.get("detail"):
@@ -231,7 +231,7 @@ def write_transcript(out_dir, rec, meta):


 def main():
-    ap = argparse.ArgumentParser(description="Live bridge_ask reverse-rendezvous test (CB-205)")
+    ap = argparse.ArgumentParser(description="Live fleet_ask reverse-rendezvous test (CB-205)")
    ap.add_argument("--base", default="http://127.0.0.1:8765")
    ap.add_argument("--profile", default=None)
    ap.add_argument("--repo", default=str(REPO_ROOT))
@@ -241,7 +241,7 @@ def main():
    ap.add_argument("--keep-worker", action="store_true")
    args = ap.parse_args()

-    print(f"[{now()}] live bridge_ask: 1 primary, 1 worker "
+    print(f"[{now()}] live fleet_ask: 1 primary, 1 worker "
          f"(profile={args.profile or 'default'}, repo={args.repo})\n")

    rec = {"spawned": False, "pane": None}
@@ -262,7 +262,7 @@ def main():

    print()
    print("=" * 72)
-    print("LIVE bridge_ask SUMMARY — reverse rendezvous (CB-205)")
+    print("LIVE fleet_ask SUMMARY — reverse rendezvous (CB-205)")
    print(f"  asked:    {rec.get('question')!r}  (turnId={rec.get('turnId')}, {rec.get('ask_latency')}s)")
    print(f"  answered: {ANSWER_COLOR!r}")
    print(f"  replied:  {rec.get('reply')!r}  (source={rec.get('replySource')}, {rec.get('answer_latency')}s)")
@@ -24,7 +24,7 @@ Usage:
    --turn-timeout  per-turn max wait, seconds    (default 150)
    --keep-worker   do not stop the worker at the end

-Exit code: 0 if every turn in the window resolved via a clean bridge_reply with no channel
+Exit code: 0 if every turn in the window resolved via a clean fleet_reply with no channel
 break; 1 otherwise. A live per-turn log streams to stdout so the run can be watched.
 """
 import argparse
@@ -47,12 +47,12 @@ STEPS = [7, 3, 11, 5, 9, 4, 13, 6, 8, 2]
 RULES = (
    "Let's play a running-total game across several messages. The total starts at 0. "
    "In each message I'll tell you to add a number; keep the running total yourself and "
-    "reply via bridge_reply with ONLY the current total as a plain integer — no words, no "
+    "reply via fleet_reply with ONLY the current total as a plain integer — no words, no "
    "punctuation, just the number. Do not restate the arithmetic. First move: add {step}."
 )
-NEXT = ("Add {step}. Reply via bridge_reply with only the new running total.")
+NEXT = ("Add {step}. Reply via fleet_reply with only the new running total.")
 REANCHOR = ("Let's re-sync — the running total is {total}. Now add {step}. Reply via "
-            "bridge_reply with only the new running total.")
+            "fleet_reply with only the new running total.")


 def parse_int(reply):
@@ -142,15 +142,15 @@ def main():
    print("=" * 72)
    print(f"SUSTAINED CONVERSATION SUMMARY — 1 primary <-> 1 worker over {dur}s (~{dur/60:.1f} min)")
    print(f"  turns:            {turns}")
-    print(f"  clean bridge_reply exchanges: {oks + drifts}/{turns}   (channel breaks: {breaks})")
+    print(f"  clean fleet_reply exchanges: {oks + drifts}/{turns}   (channel breaks: {breaks})")
    print(f"  arithmetic correct (continuity held): {oks}/{turns}   (drifts: {drifts})")
    print(f"  latency:          avg {avg}s over {turns} turns")
    ok = breaks == 0 and turns >= 2
    if ok and drifts == 0:
-        print("  RESULT: PASS — every turn resolved via bridge_reply and the worker held the "
+        print("  RESULT: PASS — every turn resolved via fleet_reply and the worker held the "
              "running total across the whole window.")
    elif ok:
-        print(f"  RESULT: PASS (channel) — every turn resolved via bridge_reply for the full "
+        print(f"  RESULT: PASS (channel) — every turn resolved via fleet_reply for the full "
              f"window; {drifts} arithmetic drift(s) (worker recovered after re-anchor).")
    else:
        print("  RESULT: FAIL — the channel broke on at least one turn (see CHANNEL BREAK above).")
@@ -4,7 +4,7 @@ the running `bridged` daemon, fully captured, with automatic gap analysis.

 This is the repeatable form of the ad-hoc channel test that surfaced the CB-115 gaps
 (herdr `unknown` misclassification, dirty completion scrape, workers not calling
-bridge_reply). It drives a real off-subscription worker over the live gateway exactly
+fleet_reply). It drives a real off-subscription worker over the live gateway exactly
 as a primary Opus session would (async fire-and-poll), records every turn, and grades
 the channel.

@@ -130,9 +130,9 @@ def grade(rec):
    phase, source, reply = rec["phase"], rec["source"], rec["reply"]
    has_reply = bool(reply and reply.strip())
    if phase == "done" and source == "reply" and has_reply:
-        return "OK", "clean explicit bridge_reply"
+        return "OK", "clean explicit fleet_reply"
    if phase == "done" and has_reply:
-        return "DEGRADED", f"resolved via {source} (worker did not call bridge_reply)"
+        return "DEGRADED", f"resolved via {source} (worker did not call fleet_reply)"
    if phase == "done" and not has_reply:
        return "EMPTY", "turn completed but reply was empty"
    if phase == "failed":
@@ -206,7 +206,7 @@ def main():
    ok = all(g in ("OK", "DEGRADED") for g in grades)
    reply_clean = all(g == "OK" for g in grades)
    if reply_clean:
-        print("  RESULT: PASS — every turn delivered and got a clean bridge_reply.")
+        print("  RESULT: PASS — every turn delivered and got a clean fleet_reply.")
    elif ok:
        print("  RESULT: PASS (with notes) — every turn delivered & replied, but some via fallback.")
    else:
@@ -12,7 +12,7 @@ and collects every reply concurrently. That stresses what a single worker never
  • reply routing under concurrency (worker A's answer must never resolve worker B's send),

 and, as the payload, whether a fleet of off-subscription workers can actually surface
-real issues in the repo and report them back structurally via bridge_reply.
+real issues in the repo and report them back structurally via fleet_reply.

 It talks ONLY to the bridge's REST face on loopback — it never sets ANTHROPIC_BASE_URL
 and never touches herdr directly, so it is subscription-safe by construction.
@@ -64,7 +64,7 @@ PROMPT_TMPL = (
    "You are one of several issue-hunting workers in the claude-bridge repo (it is your "
    "current working directory). Your assignment: inspect the file `{target}` and find the "
    "SINGLE most important real bug, correctness gap, or risk in it. Read the file before "
-    "answering. Reply via bridge_reply with EXACTLY these four lines:\n"
+    "answering. Reply via fleet_reply with EXACTLY these four lines:\n"
    "1. {target}:<line>\n"
    "2. issue: <one sentence>\n"
    "3. fix: <one line>\n"
@@ -147,9 +147,9 @@ def grade(rec):
    phase, source, reply = rec["phase"], rec["source"], rec["reply"]
    has_reply = bool(reply and reply.strip())
    if phase == "done" and source == "reply" and has_reply:
-        return "OK", "clean explicit bridge_reply"
+        return "OK", "clean explicit fleet_reply"
    if phase == "done" and has_reply:
-        return "DEGRADED", f"resolved via {source} (worker did not call bridge_reply)"
+        return "DEGRADED", f"resolved via {source} (worker did not call fleet_reply)"
    if phase == "done" and not has_reply:
        return "EMPTY", "turn completed but reply was empty"
    if phase == "failed":
@@ -1,6 +1,6 @@
 {
  "mcpServers": {
-    "bridged": {
+    "fleetd": {
      "type": "http",
      "url": "http://127.0.0.1:8765/mcp"
    }
@@ -1,6 +1,6 @@
 ---
 name: setup
-description: Make the current project bridge-ready — check the prerequisites, mount the bridged MCP gateway into the project's .mcp.json, apply standard Claude Code settings, and verify this session resolves as the primary. Writes no credentials. Load this when asked to set up, install, configure, or onboard a project onto claude-bridge, or when bridge_* tools are expected but absent.
+description: Make the current project bridge-ready — check the prerequisites, mount the bridged MCP gateway into the project's .mcp.json, apply standard Claude Code settings, and verify this session resolves as the primary. Writes no credentials. Load this when asked to set up, install, configure, or onboard a project onto claude-bridge, or when fleet_* tools are expected but absent.
 ---

 # Bridge setup — make this project bridge-ready
@@ -70,7 +70,7 @@ The entry to add, exactly:
 ```json
 {
  "mcpServers": {
-    "bridged": {
+    "fleetd": {
      "type": "http",
      "url": "http://127.0.0.1:8765/mcp"
    }
@@ -78,12 +78,12 @@ The entry to add, exactly:
 }
 ```

-If `.mcp.json` already exists, add only the `bridged` key and leave every other server untouched.
-If a `bridged` entry is already there with a different URL, **ask** rather than assuming yours is
+If `.mcp.json` already exists, add only the `fleetd` key and leave every other server untouched.
+If a `fleetd` entry is already there with a different URL, **ask** rather than assuming yours is
 right — a non-default port usually means a deliberate second daemon.

 > **If this plugin is installed, you can skip this step entirely.** The plugin ships its own
-> `.mcp.json`, so `bridged` is already mounted for any session with the plugin enabled. Write the
+> `.mcp.json`, so `fleetd` is already mounted for any session with the plugin enabled. Write the
 > project-level file only when the user wants the mount to work *without* the plugin — for
 > teammates who have not installed it, or for CI.

@@ -111,18 +111,18 @@ project already set.
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
-      "mcp__bridged__bridge_whoami",
-      "mcp__bridged__bridge_list",
-      "mcp__bridged__bridge_status",
-      "mcp__bridged__bridge_profiles",
-      "mcp__bridged__bridge_poll"
+      "mcp__fleetd__fleet_whoami",
+      "mcp__fleetd__fleet_list",
+      "mcp__fleetd__fleet_status",
+      "mcp__fleetd__fleet_profiles",
+      "mcp__fleetd__fleet_poll"
    ]
  }
 }
 ```

-Only the **read-only** bridge verbs are pre-allowed. `bridge_spawn`, `bridge_send`, and
-`bridge_stop` start processes, deliver work, and tear down terminals — those stay behind a prompt
+Only the **read-only** bridge verbs are pre-allowed. `fleet_spawn`, `fleet_send`, and
+`fleet_stop` start processes, deliver work, and tear down terminals — those stay behind a prompt
 on purpose. Do not "helpfully" add them.

 Never write `settings.local.json` on the user's behalf; that file is personal and usually
@@ -157,7 +157,7 @@ Write none of these into any file. Show the user the `export` lines to run thems
 Reconnect MCP if needed (`/mcp`), then confirm the tools are live and this session is the primary:

 ```
-bridge_whoami
+fleet_whoami
 ```

 - `{"role":"primary"}` — correct, you are done with this step.
@@ -169,7 +169,7 @@ bridge_whoami

  ```yaml
  primary:
-    terminal: term_xxxxxxxxxxxx     # the terminalId bridge_whoami just reported
+    terminal: term_xxxxxxxxxxxx     # the terminalId fleet_whoami just reported
  ```

  The daemon reads this **at boot**, so it needs a restart. Re-pin whenever the primary moves
@@ -178,9 +178,9 @@ bridge_whoami
 Then prove the fleet actually works, with a real spawn:

 ```
-bridge_profiles                       → the configured backends
-bridge_spawn{profile: "<one of them>"} → must reach state "ready"
-bridge_stop{paneId: "<from spawn>"}
+fleet_profiles                       → the configured backends
+fleet_spawn{profile: "<one of them>"} → must reach state "ready"
+fleet_stop{paneId: "<from spawn>"}
 ```

 **`/healthz` reporting `ok` is not evidence that spawning works.** It reports that the daemon can
@@ -216,7 +216,7 @@ State plainly:
 ```
 prereqs:   herdr <version> · bridged <protocol> · ccs <version> · codex <version|absent>
 written:   <files created or merged, or "none">
-role:      <bridge_whoami result — and the pin, if one was needed>
+role:      <fleet_whoami result — and the pin, if one was needed>
 spawn:     <real spawn result: profile, state reached, torn down>
 env:       <variables the USER still needs to export — names only, never values>
 skipped:   <anything not done, and why>
@@ -212,7 +212,7 @@ if [ -n "$OLD_PID" ] && [ "$ASSUME_YES" = 0 ]; then
  echo "   A restart drops every in-flight ticket and rendezvous. A member's report"
  echo "   is NOT recoverable once its ticket is gone."
  echo
-  echo "   Confirm with bridge_list that no members are live, and bridge_poll anything"
+  echo "   Confirm with fleet_list that no members are live, and fleet_poll anything"
  echo "   you still want, BEFORE continuing."
  echo
  read -r -p "   Fleet drained? type yes to restart: " reply
@@ -356,6 +356,6 @@ else
  ok "no ERROR lines since restart"
 fi
 echo
-echo "   Next: call bridge_whoami and confirm it still answers 'primary'. A lead whose tab label"
+echo "   Next: call fleet_whoami and confirm it still answers 'primary'. A lead whose tab label"
 echo "   no longer matches fleet.leaders.*.tab is demoted to worker and refuses orchestration."
 echo