v3.4.2
v3.4.2
Released 2026-07-12.
A patch release on top of v3.4.1. It wires the cost-aware batch and cache
policies into the live run loop, runs the adapter conformance suite on a real
Windows CI runner, and makes the packaged distribution image verifiable. There
are no breaking changes and no configuration migration is required.
Cost-aware scheduling now live in the run loop
- Batch routing is enforced during dispatch. Before a single-task batch is
spawned, the run resolves the adapter that would run the task and takes the
capability-gated routing decision: a batch-eligible task reaches a provider
batch endpoint only on an adapter that has one, a task that is not
batch-eligible never routes to batch, and a batch-eligible task on an adapter
with no batch surface runs interactively rather than being faked onto a batch
path that does not exist. Each routing decision is recorded as a verifiable
cost.batch_routeaudit-chain entry. - Cache-window fan-out is wired into the tournament fan-out. When the resolved
adapter supports a prompt-cache window and the operator has opted in, one
warm-up call primes the shared prompt prefix before the sibling attempts
spawn, so each attempt hits the warm cache instead of racing to write it. The
feature stays off by default.
Windows conformance on a real Windows runner
- The adapter conformance suite for the claude, codex, and gemini adapters now
runs on awindows-latestCI runner and exercises the real spawn, stop, and
restart contract against a cross-platform fake-CLI harness, alongside the
Windows worktree-isolation contract. This replaces the previous mock-only
Windows coverage for those paths. - The fake-CLI test harness is cross-platform: it installs a batch shim on
Windows and a shell wrapper on Unix, and the fake reads its own configuration
so the same integration tests drive a real subprocess on every runner. - The count of platform-reason test skips is reduced, with the file-mode and
permission cases and the canary worktree round-trip now running on every
platform.
Packaging
- Signed-image provenance verification. The MCP registry listing and the Docker
catalog entry are checked, offline, to resolve to the same signed container
image pinned to the release version. A newbernstein skills package image-verifycommand surfaces the verdict, and the release manifest check
fails a release that would publish a listing pointing at a different or
unsigned image. The registry and plugin manifests are version-synced with the
release.
Upgrading
pipx upgrade bernstein # or: uv tool upgrade bernsteinNo configuration migration is required. Every capability available in v3.4.1
is unchanged.