cargo-hauler 0.7.3 → 0.8.0

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # Changelog
 
+## 0.8.0
+
+### Minor Changes
+
+- 970dbde: New `hauler_dashboard` MCP tool carries the dashboard App
+  (`ui://cargo-hauler/dashboard.html`): hosts that render MCP Apps open the
+  dashboard beside its result, populated from the same status payload the App
+  then polls through `hauler_status`. Its text result is one summary line plus
+  where the App and the text form are, so opening the dashboard never pastes the
+  status document into the model's context. `hauler_status` no longer advertises
+  the App and returns the queue, lanes, and tickets as text for the model, as
+  before. `hauler web` opens the App through `hauler_dashboard`. The
+  `hauler-dashboard` skill and the status document's dashboard line name the new
+  tool.
+
+## 0.7.4
+
+### Patch Changes
+
+- 4267d0c: Keep read-only commands and MCP tools on a protocol-compatible running daemon, and defer automatic replacement for submissions until the older daemon is idle (#209).
+  
+  Initialize the dashboard on every MCP Apps host — Codex, Claude, ChatGPT, VS Code/Cursor, and Goose — without host-specific origin exceptions (#212).
+
 ## 0.7.3
 
 ### Patch Changes

package/README.md

@@ -59,10 +59,11 @@ hauler install-shim                                # optional: cargo from script
 ```
 
 Restart the host (or reload the window) so new sessions load the hooks. The
-daemon starts on demand with the first brokered request; `hauler status` shows
-what is running, and the `hauler_status` tool opens the dashboard in hosts that
-render MCP Apps. Prefer the hosts' own plugin commands, or building from a
-checkout? See [Install](#install).
+daemon starts on demand with the first brokered request; `hauler status` and
+the `hauler_status` tool show what is running as text, and the
+`hauler_dashboard` tool opens the dashboard in hosts that render MCP Apps.
+Prefer the hosts' own plugin commands, or building from a checkout? See
+[Install](#install).
 
 The CLI is `hauler` on PATH from `npm i -g cargo-hauler`. Never run
 `scripts/hauler.mjs` or any path under `.claude/plugins/cache`,
@@ -85,13 +86,16 @@ The CLI is `hauler` on PATH from `npm i -g cargo-hauler`. Never run
 | `hauler result <ticket> [--full]` | A stored ticket in full: the settled 16 KiB output tail, or the whole live in-memory tail while it runs (not the status preview). The document names the full on-disk output log (`Full output: <path> (size)`) and `--json` carries it as `request.outputPath`; `--full` prints that whole log instead of the tail (the last ~768 KiB when it does not fit, with the path for the rest). |
 | `hauler kill <ticket>` | Stop a ticket: drop it from the queue or SIGTERM (then SIGKILL) its cargo process group, freeing the lane. Riders return to their lane or fail with it. |
 | `hauler request [--session ID] [--host HOST] [--cwd DIR] [--after TICKET …] -- <cargo …>` | Submit a background request and return its ticket, with where it landed in its lane (`queued behind cc-3281 (~13m)`, `waiting for cc-3281`, or `attached to cc-3281`). `--cwd` overrides the current CLI workspace; `--after` works as for `exec`. |
-| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `stop` records its typed `shutdown` outcome in JSON and exits `0` only after a `shutting-down` acknowledgement followed by the original pid's exit, or when the daemon was already absent. Refusal, timeout, protocol error, disconnect before acknowledgement, and an acknowledged daemon still alive after 5 s exit `1`; `running` remains `true` when the original pid is alive and `null` when liveness could not be established. `restart` is the manual replacement: it sends the graceful stop, waits up to 5 s for the old pid to exit, then starts a daemon from this install and prints both (`restarted: pid 741314 (0.6.0) → pid 742001 (0.6.1)`); a daemon that has not exited by then is reported, not killed, and nothing is started (exit `1`). Tickets in flight are not handed over: the old daemon settles them itself as it shuts down — `killed`, error `daemon shutdown` — and callers resubmit (only rows a daemon that died without shutting down never marked are stamped `orphaned by daemon restart` by the next daemon's first ledger pass). After upgrading the package, every client entry — reads (`status`, `daemon status`, `log`, `last`, `await`, `result`, the dashboard and MCP tools), writes, and hooks — checks the daemon version before requesting a versioned payload and replaces a daemon from the previous install automatically. When the old daemon has not exited within the grace, the command fails with `` cargo-hauler daemon pid N (X.Y.Z) is still running 5s after the shutdown request; not restarted — retry once it has exited, or stop it with `hauler daemon stop` `` instead of parsing its payload or starting a second daemon. |
+| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `stop` records its typed `shutdown` outcome in JSON and exits `0` only after a `shutting-down` acknowledgement followed by the original pid's exit, or when the daemon was already absent. Refusal, timeout, protocol error, disconnect before acknowledgement, and an acknowledged daemon still alive after 5 s exit `1`; `running` remains `true` when the original pid is alive and `null` when liveness could not be established. `restart` is the explicit replacement path: it sends the graceful stop, waits up to 5 s for the old pid to exit, then starts a daemon from this install and prints both (`restarted: pid 741314 (0.6.0) → pid 742001 (0.6.1)`). Tickets in flight are not handed over: the old daemon settles them itself as it shuts down — `killed`, error `daemon shutdown` — and callers resubmit. Automatic upgrades are gentler: read-only commands and MCP/dashboard reads never retire a daemon; a protocol-compatible older daemon serves them directly. Submission commands replace an older daemon only after an idle status check; daemons from 0.7.4 onward hold admission closed while confirming that state, while 0.7.1–0.7.3 receive a client preflight. A busy or slow-to-retire daemon keeps serving the submission and emits one line such as `daemon 0.7.1 will be replaced by 0.7.3 when idle`. A truly incompatible daemon is reported with its pid and version instead of having its payload parsed. |
 | `hauler install-shim [--dir DIR] [--real-cargo PATH] [--force]` | Install the optional PATH shim. |
-| `hauler web [--port N] [--no-open]` | Open the dashboard from the checkout, npm package, or installed plugin. Agent Bundle's generated web command serves the built App against the plugin's own `hauler` server, opens it populated by `hauler_status`, and stays in the foreground until Ctrl-C. In an MCP host, call `hauler_status` instead. |
+| `hauler web [--port N] [--no-open]` | Open the dashboard from the checkout, npm package, or installed plugin. Agent Bundle's generated web command serves the built App against the plugin's own `hauler` server, opens it populated by `hauler_dashboard`, and stays in the foreground until Ctrl-C. In an MCP host, call `hauler_dashboard` instead. |
 
 The `hauler` MCP server projects the same operations as `hauler_status`,
 `hauler_log`, `hauler_last`, `hauler_await`, `hauler_result`, `hauler_kill`,
-and `hauler_request`, with the same filters as the CLI. `hauler_status` and
+and `hauler_request`, with the same filters as the CLI, plus
+`hauler_dashboard`, which carries the MCP App (below) and answers with one
+summary line so opening the dashboard never pastes the status text into the
+model's context. `hauler_status` and
 `hauler_log` rows are the same bounded summaries (`outputPreview`, never a
 tail); `hauler_result`, `hauler_await`, and `hauler_last` carry the whole
 tail. `hauler_request.cwd` is an optional override: Agent Bundle's authoritative
@@ -102,7 +106,8 @@ workspace.
 ## Dashboard
 
 The dashboard is an MCP App (`ui://cargo-hauler/dashboard.html`) attached to
-`hauler_status`. It shows contention and admission, in-flight and queued work
+`hauler_dashboard`; `hauler_status` is the same data as text for the model and
+never opens it. It shows contention and admission, in-flight and queued work
 — each running row with the last line of its output preview, each ticket's
 drawer with the whole tail fetched through `hauler_result` — metrics over
 one-hour, 24-hour, and all-time windows, per-command timings, optional kache
@@ -448,9 +453,13 @@ ever flagged.
 Tickets do not survive a daemon stop; runs are never handed over to the next
 daemon. How a ticket ends depends on how the daemon went. A graceful stop —
 `hauler daemon restart`, `hauler daemon stop`, or the automatic replacement of
-a daemon from another install by the next `hauler exec`, `hauler request`,
-hook call, or `hauler daemon start` — is the shutdown request, and the old
-daemon settles every queued, running, and attached ticket itself as it exits:
+an idle older daemon by the next `hauler exec`, `hauler request`, hook
+submission, or `hauler daemon start` — is the shutdown request. Automatic
+replacement checks for queued, running, executing, or attached work first;
+0.7.4 and later daemons hold admission closed through that decision, while
+0.7.1–0.7.3 receive the compatible client's status preflight. When a stop does
+proceed, the old daemon settles every queued, running, and attached ticket
+itself as it exits:
 its cargo processes are terminated (SIGTERM, then SIGKILL after
 `CARGO_HAULER_KILL_GRACE_MS`) and each row is marked `killed` with the error
 `daemon shutdown`, so `hauler result cc-N` shows the ticket `killed` with
@@ -708,9 +717,9 @@ it from the umask:
   under `XDG_RUNTIME_DIR`, `TMPDIR`, or the system temporary directory —
   never directly into a shared temporary root. Two accounts sharing one
   temporary root get separate directories. A daemon from an earlier install
-  still listening at the previous relocated path is retired by the next
-  client under the usual one-version rule, and `hauler daemon stop` asks it
-  too before reporting nothing running, so upgrading needs no manual cleanup.
+  still listening at the previous relocated path is considered only by a
+  daemon-starting submission, never by a read; `hauler daemon stop` asks it
+  too before reporting nothing running.
 
 Windows has neither POSIX modes nor uids, and its control endpoint is a
 named pipe rather than a filesystem entry, so none of the above applies
@@ -728,14 +737,11 @@ there; state files keep the permissions the filesystem gives them.
   `hauler_await` fail loudly when the daemon is unreachable instead of
   reporting a ticket as not found; `hauler_status`, `hauler_log`, and
   `hauler_last` read the ledger with the daemon marked `stopped` or
-  `unresponsive`. Before any live daemon reply is parsed, these reads apply
-  the one-version rule and replace a daemon left running by a previous
-  install. Replacement is directional: only a newer install replaces a
-  daemon. A client older than the daemon it finds — a session still on a
-  previous plugin — never shuts it down (the daemon refuses a shutdown from
-  an older or unversioned client), reports the daemon as newer, and runs
-  cargo directly. If replacement fails, the reads report that failure
-  instead of reading the stale payload.
+  `unresponsive`. Reads never request daemon shutdown. They use an older
+  daemon when its wire-protocol identity is compatible; a truly incompatible
+  daemon is reported with its pid and version. A client older than the daemon
+  it finds — a session still on a previous plugin — keeps the directional
+  `DaemonNewer` behavior and never shuts it down.
 - The state directory is not migrated between installs. Every rendered
   document names the one in use (`state dir …` in the header; `stateRoot` in
   `--json`), so a `CARGO_HAULER_STATE_DIR` change is visible on the next
@@ -782,7 +788,7 @@ src/
   layout.tsx                    the hauler shell around every rendered route
   providers/hauler-daemon.ts    request-scoped daemon configuration
   components/                   typed components over pure view-models
-  mcp/hauler/tools/*.tsx        hauler_status, _log, _last, _await, _result, _request, _kill
+  mcp/hauler/tools/*.tsx        hauler_status, _dashboard, _log, _last, _await, _result, _request, _kill
   mcp/hauler/tools/*.cli.ts     each tool's `hauler <command>` projection (flags, positionals)
   mcp/hauler/apps/dashboard.tsx the MCP App (ui://cargo-hauler/dashboard.html)
   cli/daemon.ts                 the one plain CLI command
@@ -897,7 +903,8 @@ the same filter as its `session` field). Results carry
 
 | Route | Surface | Document |
 | --- | --- | --- |
-| `tool:hauler/hauler_status` (`hauler status`) | queue, lanes, admission, kache, filters; bounded summary rows (`StatusRow`): `outputPreview` on running rows, never a tail | `StatusDocument`; the tool advertises the dashboard App |
+| `tool:hauler/hauler_status` (`hauler status`) | queue, lanes, admission, kache, filters; bounded summary rows (`StatusRow`): `outputPreview` on running rows, never a tail | `StatusDocument`, text for the model |
+| `tool:hauler/hauler_dashboard` (`hauler web`) | the same `StatusResult`, `limit` only; the tool advertises the dashboard App (`_meta.ui.resourceUri`) so hosts open it beside the result | `DashboardDocument`: one summary line plus where the App and the text form are |
 | `tool:hauler/hauler_log` (`hauler log`) | recent requests, as summary rows | `LogStream` → `LogDocument` |
 | `tool:hauler/hauler_last` (`hauler last`) | most recent request, as a detail record with its tail | `LastDocument` |
 | `tool:hauler/hauler_await` (`hauler await`) | long-poll a ticket (≤ 2 h) | `AwaitStream` → `AwaitDocument` |
@@ -921,8 +928,10 @@ resource URI it describes, so the document cannot drift from the surface.
 #### Dashboard
 
 `src/mcp/hauler/apps/dashboard.tsx` is the MCP App at
-`ui://cargo-hauler/dashboard.html`, attached to `hauler_status` on hosts that
-render MCP Apps. It shows contention and admission, in-flight and queued
+`ui://cargo-hauler/dashboard.html`, attached to `hauler_dashboard` on hosts
+that render MCP Apps; the opening result is that tool's status payload, and
+`hauler_status` carries no App so its text reaches the model alone. It shows
+contention and admission, in-flight and queued
 work, metrics windows, optional kache data, lanes, and history, with a live
 output drawer per ticket. The App polls `hauler_status` every 5 s; its rows
 are summaries, so a running row's `outputPreview` shows as one line under the
@@ -978,7 +987,7 @@ pnpm run check     # the gate
 To see the dashboard outside an MCP host, run `node artifact/bin/cargo-hauler.mjs
 web` after a build: the framework's `web` command (configured under `web` in
 `agent-bundle.config.ts`) launches the artifact's own `hauler` server, calls
-`hauler_status` once so the App opens populated, approves `call-tool` so its
+`hauler_dashboard` once so the App opens populated, approves `call-tool` so its
 panels may poll, and serves `ui://cargo-hauler/dashboard.html` on a loopback
 origin until Ctrl-C — so the data is the daemon's own. `pnpm run dev` and the
 Workbench's MCP page preview the same App with live rebuilds. The repository
@@ -986,9 +995,10 @@ ships no preview harness of its own.
 
 agent-bundle does not yet have an npm release; this repository pins the
 [pkg.pr.new](https://pkg.pr.new) preview of Agent Bundle main commit
-[`b807ca0`](https://github.com/ScriptedAlchemy/agent-bundle/commit/b807ca0eea5c0d5744350e1fa8829e3d59c3c0b8),
-merged by [Agent Bundle PR #772](https://github.com/ScriptedAlchemy/agent-bundle/pull/772),
-for both `agent-bundle` and `@agent-bundle/runtime`. `inspect` reports the
+[`e040c32`](https://github.com/ScriptedAlchemy/agent-bundle/commit/e040c32591d586eba72da6fa5c1bc1c881993000),
+built from [Agent Bundle PR #779](https://github.com/ScriptedAlchemy/agent-bundle/pull/779),
+for `agent-bundle`, `@agent-bundle/runtime`, and their paired
+`rsc-markdown-stream` preview. `inspect` reports the
 `agent` component kind as unavailable on every host (agent-bundle G5
 deferral); this plugin defines no agents.
 

package/dist/.claude-plugin/marketplace.json

@@ -1 +1 @@
-{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","name":"cargo-hauler-marketplace","owner":{"name":"cargo-hauler"},"plugins":[{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","source":"./","version":"0.7.3"}]}
+{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","name":"cargo-hauler-marketplace","owner":{"name":"cargo-hauler"},"plugins":[{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","source":"./","version":"0.8.0"}]}

package/dist/.claude-plugin/plugin.json

@@ -1 +1 @@
-{"author":{"name":"cargo-hauler"},"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","name":"cargo-hauler","version":"0.7.3"}
+{"author":{"name":"cargo-hauler"},"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","name":"cargo-hauler","version":"0.8.0"}

package/dist/.codex-plugin/plugin.json

@@ -1 +1 @@
-{"author":{"name":"cargo-hauler"},"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","hooks":"./.codex-plugin/hooks.json","interface":{"capabilities":["mcp","hooks","skills"],"category":"Productivity","defaultPrompt":["Help me use cargo-hauler."],"developerName":"cargo-hauler","displayName":"cargo-hauler","longDescription":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","shortDescription":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks."},"keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","mcpServers":"./.codex-plugin/mcp.json","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","skills":"./skills/","version":"0.7.3"}
+{"author":{"name":"cargo-hauler"},"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","hooks":"./.codex-plugin/hooks.json","interface":{"capabilities":["mcp","hooks","skills"],"category":"Productivity","defaultPrompt":["Help me use cargo-hauler."],"developerName":"cargo-hauler","displayName":"cargo-hauler","longDescription":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","shortDescription":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks."},"keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","mcpServers":"./.codex-plugin/mcp.json","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","skills":"./skills/","version":"0.8.0"}

package/dist/.cursor-plugin/plugin.json

@@ -1 +1 @@
-{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","displayName":"cargo-hauler","hooks":"./.cursor-plugin/hooks.json","keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","mcpServers":"./.cursor-plugin/mcp.json","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","skills":"./skills/","version":"0.7.3"}
+{"description":"Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.","displayName":"cargo-hauler","hooks":"./.cursor-plugin/hooks.json","keywords":["cargo","rust","agent","mcp","claude-code","codex","cursor","build-orchestration"],"license":"MIT","mcpServers":"./.cursor-plugin/mcp.json","name":"cargo-hauler","repository":"https://github.com/ScriptedAlchemy/cargo-hauler","skills":"./skills/","version":"0.8.0"}

package/dist/INSTALL.md

@@ -2,7 +2,7 @@
 
 Coalesce, schedule, and stream cargo so concurrent agent sessions share compiles instead of fighting locks.
 
-Version: `0.7.3`
+Version: `0.8.0`
 
 Run these commands from this bundle directory. The bundle is self-contained: every command below is
 a host command or the bundled installer, and nothing requires the `agent-bundle` CLI. Where that CLI is

package/dist/README.md

@@ -59,10 +59,11 @@ hauler install-shim                                # optional: cargo from script
 ```
 
 Restart the host (or reload the window) so new sessions load the hooks. The
-daemon starts on demand with the first brokered request; `hauler status` shows
-what is running, and the `hauler_status` tool opens the dashboard in hosts that
-render MCP Apps. Prefer the hosts' own plugin commands, or building from a
-checkout? See [Install](#install).
+daemon starts on demand with the first brokered request; `hauler status` and
+the `hauler_status` tool show what is running as text, and the
+`hauler_dashboard` tool opens the dashboard in hosts that render MCP Apps.
+Prefer the hosts' own plugin commands, or building from a checkout? See
+[Install](#install).
 
 The CLI is `hauler` on PATH from `npm i -g cargo-hauler`. Never run
 `scripts/hauler.mjs` or any path under `.claude/plugins/cache`,
@@ -85,13 +86,16 @@ The CLI is `hauler` on PATH from `npm i -g cargo-hauler`. Never run
 | `hauler result <ticket> [--full]` | A stored ticket in full: the settled 16 KiB output tail, or the whole live in-memory tail while it runs (not the status preview). The document names the full on-disk output log (`Full output: <path> (size)`) and `--json` carries it as `request.outputPath`; `--full` prints that whole log instead of the tail (the last ~768 KiB when it does not fit, with the path for the rest). |
 | `hauler kill <ticket>` | Stop a ticket: drop it from the queue or SIGTERM (then SIGKILL) its cargo process group, freeing the lane. Riders return to their lane or fail with it. |
 | `hauler request [--session ID] [--host HOST] [--cwd DIR] [--after TICKET …] -- <cargo …>` | Submit a background request and return its ticket, with where it landed in its lane (`queued behind cc-3281 (~13m)`, `waiting for cc-3281`, or `attached to cc-3281`). `--cwd` overrides the current CLI workspace; `--after` works as for `exec`. |
-| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `stop` records its typed `shutdown` outcome in JSON and exits `0` only after a `shutting-down` acknowledgement followed by the original pid's exit, or when the daemon was already absent. Refusal, timeout, protocol error, disconnect before acknowledgement, and an acknowledged daemon still alive after 5 s exit `1`; `running` remains `true` when the original pid is alive and `null` when liveness could not be established. `restart` is the manual replacement: it sends the graceful stop, waits up to 5 s for the old pid to exit, then starts a daemon from this install and prints both (`restarted: pid 741314 (0.6.0) → pid 742001 (0.6.1)`); a daemon that has not exited by then is reported, not killed, and nothing is started (exit `1`). Tickets in flight are not handed over: the old daemon settles them itself as it shuts down — `killed`, error `daemon shutdown` — and callers resubmit (only rows a daemon that died without shutting down never marked are stamped `orphaned by daemon restart` by the next daemon's first ledger pass). After upgrading the package, every client entry — reads (`status`, `daemon status`, `log`, `last`, `await`, `result`, the dashboard and MCP tools), writes, and hooks — checks the daemon version before requesting a versioned payload and replaces a daemon from the previous install automatically. When the old daemon has not exited within the grace, the command fails with `` cargo-hauler daemon pid N (X.Y.Z) is still running 5s after the shutdown request; not restarted — retry once it has exited, or stop it with `hauler daemon stop` `` instead of parsing its payload or starting a second daemon. |
+| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `stop` records its typed `shutdown` outcome in JSON and exits `0` only after a `shutting-down` acknowledgement followed by the original pid's exit, or when the daemon was already absent. Refusal, timeout, protocol error, disconnect before acknowledgement, and an acknowledged daemon still alive after 5 s exit `1`; `running` remains `true` when the original pid is alive and `null` when liveness could not be established. `restart` is the explicit replacement path: it sends the graceful stop, waits up to 5 s for the old pid to exit, then starts a daemon from this install and prints both (`restarted: pid 741314 (0.6.0) → pid 742001 (0.6.1)`). Tickets in flight are not handed over: the old daemon settles them itself as it shuts down — `killed`, error `daemon shutdown` — and callers resubmit. Automatic upgrades are gentler: read-only commands and MCP/dashboard reads never retire a daemon; a protocol-compatible older daemon serves them directly. Submission commands replace an older daemon only after an idle status check; daemons from 0.7.4 onward hold admission closed while confirming that state, while 0.7.1–0.7.3 receive a client preflight. A busy or slow-to-retire daemon keeps serving the submission and emits one line such as `daemon 0.7.1 will be replaced by 0.7.3 when idle`. A truly incompatible daemon is reported with its pid and version instead of having its payload parsed. |
 | `hauler install-shim [--dir DIR] [--real-cargo PATH] [--force]` | Install the optional PATH shim. |
-| `hauler web [--port N] [--no-open]` | Open the dashboard from the checkout, npm package, or installed plugin. Agent Bundle's generated web command serves the built App against the plugin's own `hauler` server, opens it populated by `hauler_status`, and stays in the foreground until Ctrl-C. In an MCP host, call `hauler_status` instead. |
+| `hauler web [--port N] [--no-open]` | Open the dashboard from the checkout, npm package, or installed plugin. Agent Bundle's generated web command serves the built App against the plugin's own `hauler` server, opens it populated by `hauler_dashboard`, and stays in the foreground until Ctrl-C. In an MCP host, call `hauler_dashboard` instead. |
 
 The `hauler` MCP server projects the same operations as `hauler_status`,
 `hauler_log`, `hauler_last`, `hauler_await`, `hauler_result`, `hauler_kill`,
-and `hauler_request`, with the same filters as the CLI. `hauler_status` and
+and `hauler_request`, with the same filters as the CLI, plus
+`hauler_dashboard`, which carries the MCP App (below) and answers with one
+summary line so opening the dashboard never pastes the status text into the
+model's context. `hauler_status` and
 `hauler_log` rows are the same bounded summaries (`outputPreview`, never a
 tail); `hauler_result`, `hauler_await`, and `hauler_last` carry the whole
 tail. `hauler_request.cwd` is an optional override: Agent Bundle's authoritative
@@ -102,7 +106,8 @@ workspace.
 ## Dashboard
 
 The dashboard is an MCP App (`ui://cargo-hauler/dashboard.html`) attached to
-`hauler_status`. It shows contention and admission, in-flight and queued work
+`hauler_dashboard`; `hauler_status` is the same data as text for the model and
+never opens it. It shows contention and admission, in-flight and queued work
 — each running row with the last line of its output preview, each ticket's
 drawer with the whole tail fetched through `hauler_result` — metrics over
 one-hour, 24-hour, and all-time windows, per-command timings, optional kache
@@ -448,9 +453,13 @@ ever flagged.
 Tickets do not survive a daemon stop; runs are never handed over to the next
 daemon. How a ticket ends depends on how the daemon went. A graceful stop —
 `hauler daemon restart`, `hauler daemon stop`, or the automatic replacement of
-a daemon from another install by the next `hauler exec`, `hauler request`,
-hook call, or `hauler daemon start` — is the shutdown request, and the old
-daemon settles every queued, running, and attached ticket itself as it exits:
+an idle older daemon by the next `hauler exec`, `hauler request`, hook
+submission, or `hauler daemon start` — is the shutdown request. Automatic
+replacement checks for queued, running, executing, or attached work first;
+0.7.4 and later daemons hold admission closed through that decision, while
+0.7.1–0.7.3 receive the compatible client's status preflight. When a stop does
+proceed, the old daemon settles every queued, running, and attached ticket
+itself as it exits:
 its cargo processes are terminated (SIGTERM, then SIGKILL after
 `CARGO_HAULER_KILL_GRACE_MS`) and each row is marked `killed` with the error
 `daemon shutdown`, so `hauler result cc-N` shows the ticket `killed` with
@@ -708,9 +717,9 @@ it from the umask:
   under `XDG_RUNTIME_DIR`, `TMPDIR`, or the system temporary directory —
   never directly into a shared temporary root. Two accounts sharing one
   temporary root get separate directories. A daemon from an earlier install
-  still listening at the previous relocated path is retired by the next
-  client under the usual one-version rule, and `hauler daemon stop` asks it
-  too before reporting nothing running, so upgrading needs no manual cleanup.
+  still listening at the previous relocated path is considered only by a
+  daemon-starting submission, never by a read; `hauler daemon stop` asks it
+  too before reporting nothing running.
 
 Windows has neither POSIX modes nor uids, and its control endpoint is a
 named pipe rather than a filesystem entry, so none of the above applies
@@ -728,14 +737,11 @@ there; state files keep the permissions the filesystem gives them.
   `hauler_await` fail loudly when the daemon is unreachable instead of
   reporting a ticket as not found; `hauler_status`, `hauler_log`, and
   `hauler_last` read the ledger with the daemon marked `stopped` or
-  `unresponsive`. Before any live daemon reply is parsed, these reads apply
-  the one-version rule and replace a daemon left running by a previous
-  install. Replacement is directional: only a newer install replaces a
-  daemon. A client older than the daemon it finds — a session still on a
-  previous plugin — never shuts it down (the daemon refuses a shutdown from
-  an older or unversioned client), reports the daemon as newer, and runs
-  cargo directly. If replacement fails, the reads report that failure
-  instead of reading the stale payload.
+  `unresponsive`. Reads never request daemon shutdown. They use an older
+  daemon when its wire-protocol identity is compatible; a truly incompatible
+  daemon is reported with its pid and version. A client older than the daemon
+  it finds — a session still on a previous plugin — keeps the directional
+  `DaemonNewer` behavior and never shuts it down.
 - The state directory is not migrated between installs. Every rendered
   document names the one in use (`state dir …` in the header; `stateRoot` in
   `--json`), so a `CARGO_HAULER_STATE_DIR` change is visible on the next
@@ -782,7 +788,7 @@ src/
   layout.tsx                    the hauler shell around every rendered route
   providers/hauler-daemon.ts    request-scoped daemon configuration
   components/                   typed components over pure view-models
-  mcp/hauler/tools/*.tsx        hauler_status, _log, _last, _await, _result, _request, _kill
+  mcp/hauler/tools/*.tsx        hauler_status, _dashboard, _log, _last, _await, _result, _request, _kill
   mcp/hauler/tools/*.cli.ts     each tool's `hauler <command>` projection (flags, positionals)
   mcp/hauler/apps/dashboard.tsx the MCP App (ui://cargo-hauler/dashboard.html)
   cli/daemon.ts                 the one plain CLI command
@@ -897,7 +903,8 @@ the same filter as its `session` field). Results carry
 
 | Route | Surface | Document |
 | --- | --- | --- |
-| `tool:hauler/hauler_status` (`hauler status`) | queue, lanes, admission, kache, filters; bounded summary rows (`StatusRow`): `outputPreview` on running rows, never a tail | `StatusDocument`; the tool advertises the dashboard App |
+| `tool:hauler/hauler_status` (`hauler status`) | queue, lanes, admission, kache, filters; bounded summary rows (`StatusRow`): `outputPreview` on running rows, never a tail | `StatusDocument`, text for the model |
+| `tool:hauler/hauler_dashboard` (`hauler web`) | the same `StatusResult`, `limit` only; the tool advertises the dashboard App (`_meta.ui.resourceUri`) so hosts open it beside the result | `DashboardDocument`: one summary line plus where the App and the text form are |
 | `tool:hauler/hauler_log` (`hauler log`) | recent requests, as summary rows | `LogStream` → `LogDocument` |
 | `tool:hauler/hauler_last` (`hauler last`) | most recent request, as a detail record with its tail | `LastDocument` |
 | `tool:hauler/hauler_await` (`hauler await`) | long-poll a ticket (≤ 2 h) | `AwaitStream` → `AwaitDocument` |
@@ -921,8 +928,10 @@ resource URI it describes, so the document cannot drift from the surface.
 #### Dashboard
 
 `src/mcp/hauler/apps/dashboard.tsx` is the MCP App at
-`ui://cargo-hauler/dashboard.html`, attached to `hauler_status` on hosts that
-render MCP Apps. It shows contention and admission, in-flight and queued
+`ui://cargo-hauler/dashboard.html`, attached to `hauler_dashboard` on hosts
+that render MCP Apps; the opening result is that tool's status payload, and
+`hauler_status` carries no App so its text reaches the model alone. It shows
+contention and admission, in-flight and queued
 work, metrics windows, optional kache data, lanes, and history, with a live
 output drawer per ticket. The App polls `hauler_status` every 5 s; its rows
 are summaries, so a running row's `outputPreview` shows as one line under the
@@ -978,7 +987,7 @@ pnpm run check     # the gate
 To see the dashboard outside an MCP host, run `node artifact/bin/cargo-hauler.mjs
 web` after a build: the framework's `web` command (configured under `web` in
 `agent-bundle.config.ts`) launches the artifact's own `hauler` server, calls
-`hauler_status` once so the App opens populated, approves `call-tool` so its
+`hauler_dashboard` once so the App opens populated, approves `call-tool` so its
 panels may poll, and serves `ui://cargo-hauler/dashboard.html` on a loopback
 origin until Ctrl-C — so the data is the daemon's own. `pnpm run dev` and the
 Workbench's MCP page preview the same App with live rebuilds. The repository
@@ -986,9 +995,10 @@ ships no preview harness of its own.
 
 agent-bundle does not yet have an npm release; this repository pins the
 [pkg.pr.new](https://pkg.pr.new) preview of Agent Bundle main commit
-[`b807ca0`](https://github.com/ScriptedAlchemy/agent-bundle/commit/b807ca0eea5c0d5744350e1fa8829e3d59c3c0b8),
-merged by [Agent Bundle PR #772](https://github.com/ScriptedAlchemy/agent-bundle/pull/772),
-for both `agent-bundle` and `@agent-bundle/runtime`. `inspect` reports the
+[`e040c32`](https://github.com/ScriptedAlchemy/agent-bundle/commit/e040c32591d586eba72da6fa5c1bc1c881993000),
+built from [Agent Bundle PR #779](https://github.com/ScriptedAlchemy/agent-bundle/pull/779),
+for `agent-bundle`, `@agent-bundle/runtime`, and their paired
+`rsc-markdown-stream` preview. `inspect` reports the
 `agent` component kind as unavailable on every host (agent-bundle G5
 deferral); this plugin defines no agents.