cargo-hauler 0.6.4 → 0.6.6

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## 0.6.6
+
+### Patch Changes
+
+- 60fd579: Spawn the daemon from an absolute entry path. The daemon runs with the state dir as its cwd, so a relative entry (a host running the plugin script from its own directory, or a relative plugin root) resolved to `<state dir>/scripts/hauler.mjs` and every start died with `MODULE_NOT_FOUND`; with version gating that repeated on each hook call after an upgrade. The entry is now resolved against the client's cwd and checked for existence, falling back to the package entry beside the bundled module and only then to the running script.
+
+## 0.6.5
+
+### Patch Changes
+
+- 4686a3b: Lane scheduling prefers the compile surface the lane just built. A queued request whose profile, features, target, toolchain, or compile-relevant environment differ from the last leader's is scored as 1.5× its estimate, so consecutive requests that share a surface run back to back instead of alternating `cargo test` (test profile) with `cargo check`/`build` (dev profile) or flipping a feature set on every ticket. The ledger showed 47% of consecutive same-lane runs switching surface and those runs taking 1.6–2.5× as long as same-surface runs. Shortest-job-first, fan-out, edit fail-fast, and age escape still apply: a switch that is clearly cheaper still runs first, and a switching request cannot be starved.
+
 ## 0.6.4
 
 ### Patch Changes

package/README.md

@@ -252,8 +252,11 @@ compile phase and an execution phase once the ledger has seen
 `buildFinishedAtMs` on that intent. It can also use
 per-crate timing data from kache. Lower-cost work, requests with more attached
 callers, dependency-unblocking work, and recently edited packages receive a
-lower scheduling score. Waiting time lowers the score further so broad work
-eventually runs.
+lower scheduling score. A request whose compile surface (profile, features,
+target, toolchain, compile-relevant environment) differs from the one the lane
+just built is scored as 1.5× its estimate, so like work runs back to back
+instead of alternating test and dev profiles or flipping feature sets on every
+ticket. Waiting time lowers the score further so broad work eventually runs.
 
 Admission within a lane is therefore cost-ordered, not first-in-first-out: a
 queued `cargo test -p foo` (a cheap estimate) normally starts before a queued