cargo-hauler 0.6.3 → 0.6.4

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 0.6.4
+
+### Patch Changes
+
+- 1baf004: Model `env NAME=value … cargo …` and `bash -c '… cargo …'` requests as the cargo they run (#126). A leading `env` (assignments, `-u NAME`) is folded into the request environment and intent key, so such requests get the right subcommand, packages, estimate, identity/coverage attachment, batching, demux, and execution-phase hand-back instead of being recorded as subcommand `env` with a default estimate. A `bash -c` / `sh -c` / `zsh -c` script with exactly one cargo statement is scheduled, estimated, and phase-tracked as that cargo tail, but never attaches, leads, or folds (the script may do more than its cargo), and is never demuxed. `env -i` stays opaque; other `env` options are refused as non-cargo programs.
+- 1baf004: Serialize `hook-state.json` read-modify-write cycles across concurrent sessions' hook processes with a lock beside the file (#110), so one session's completion cursor or stop-denial counter is no longer lost when another session's hook saves at the same moment. Waiting is bounded (2 s) and a lock that cannot be taken degrades to the previous unlocked update rather than failing the host's tool call; a lock older than 5 s is treated as abandoned.
+- cc3e6bc: State precisely when `hauler install-shim` embeds the running npm entry instead of the PATH `hauler` (only when no `hauler` on PATH resolves to a `.js` script; version-manager shims do not count), in the README and in the command's own message, which no longer calls a self-embedded checkout entry "global" (#124)
+- 1baf004: `hauler status`, `hauler daemon status`, `hauler log`, `hauler_status`, and the dashboard no longer die with a `ZodError` when the daemon that answers is from a previous install (#123). The read-only surfaces check the daemon's reported version before parsing its rows; a mismatch reads the ledger, marks the daemon `unresponsive`, and says which version is running and that the next cargo command or `hauler daemon restart` replaces it.
+- e0ef261: Replace a daemon from a previous install before `hauler status`, `hauler daemon status`, ticket reads, MCP tools, or hooks parse its reply; report a clear failure when replacement cannot finish (#127)
+
 ## 0.6.3
 
 ### Patch Changes

package/README.md

@@ -85,7 +85,7 @@ 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`). `--after` works as for `exec`. |
-| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `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, the next `hauler exec`, `hauler request`, hook rewrite, or `hauler daemon start` replaces a daemon from the previous install automatically the same way; when the old daemon has not exited within the grace, that call 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 starting a second daemon. |
+| `hauler daemon <run\|start\|stop\|status\|restart>` | Manage the daemon lifecycle. `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 install-shim [--dir DIR] [--real-cargo PATH] [--force]` | Install the optional PATH shim. |
 | `hauler dashboard [--target claude\|codex\|cursor\|portable] [--port N] [--no-open]` | Open the dashboard in a plain browser tab: serve the MCP App standalone against the plugin's own `hauler` server on `127.0.0.1` (`spawnServeApp` from `agent-bundle/serve-app-command`, which runs `agent-bundle serve-app` as a child process and prints its URL), call `hauler_status` once so it opens populated, and stay in the foreground until Ctrl-C. A checkout command: it needs the built `artifact/` beside the CLI and `agent-bundle` under `node_modules` (`pnpm install && pnpm build`); the npm package ships no runtime dependencies and an installed host pack has no artifact, so both report what is missing. In an MCP host, call `hauler_status` instead. |
 
@@ -187,6 +187,13 @@ Within a lane, the daemon can reduce work in three ways:
 3. **Batch folding:** compatible queued compile or test requests are combined
    into one invocation.
 
+A leading `env NAME=value … cargo …` is folded into the request environment,
+so the cargo behind it is scheduled, estimated, attached, and phase-tracked
+as that cargo command (the assignments are part of its identity). A
+`bash -c` / `sh -c` script whose single cargo statement can be read is
+scheduled and estimated as that cargo command too, but never shared or
+folded: the rest of the script is opaque.
+
 A request that could not attach is logged at debug level with the gate that
 refused it (`subcommand`, `opaque-arguments`, `passthrough`,
 `compile-surface`, `packages`, `targets`, `channels`,
@@ -429,9 +436,12 @@ When the daemon starts Cargo it sets `CARGO_HAULER_INSIDE=1`, and the shim then
 invokes the embedded Cargo directly, so the daemon's own Cargo never returns
 through the broker. The shim is POSIX-only; its directory must appear before
 rustup's Cargo directory on `PATH`; replacing an existing destination requires
-`--force`. `hauler install-shim` resolves the global `hauler` on PATH and
-embeds its realpath (an npm `dist/bin/hauler.js` entry embeds itself only when
-PATH has no `hauler`); it refuses to run from a plugin-local `scripts/hauler.mjs`.
+`--force`. `hauler install-shim` walks PATH for a `hauler` whose realpath is a
+regular `.js`, `.mjs`, or `.cjs` file outside any plugin copy and embeds that
+realpath (a version-manager shim such as `mise/shims/hauler`, which resolves to
+a native binary, does not count); an npm `dist/bin/hauler.js` entry embeds
+itself only when that walk finds nothing. It refuses to run from a plugin-local
+`scripts/hauler.mjs`.
 If a Node upgrade moves that global file, the shim runs Cargo directly until
 you re-run `hauler install-shim --force`.
 
@@ -619,9 +629,10 @@ unset, the daemon reads kache's configured local store from
   `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`. None of these documents replaces a daemon left running by
-  a previous install: they read the daemon that is there, and the next
-  `hauler exec`, `hauler request`, or hook call replaces it.
+  `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. If replacement fails, they report that failure instead of reading
+  the stale payload.
 - 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