v3.4.0

v3.4.0

Released 2026-07-12.

A feature release built around one idea: the artefact an operator sees is
itself the verifiable receipt. Typed activity records, detached runs,
tournament selection, cost-aware dispatch, in-process gates, a spec-to-graph
pipeline, workload identity, an MCP Tasks surface, a receipt-backed update
path, and the run review board all land as signed, replayable records rather
than logs beside the work. Windows parity coverage and the MCP registry OCI
packaging fix round out the release.

A few extra-large items shipped a complete first phase with documented
follow-ups; each section below says what landed and what is deferred.

Typed activity data and ops modalities (#2311)

The typed activity boundary gains explicit data and ops modalities, so an
activity is recorded with its shape rather than as opaque text.

• Each activity result is projected into the HMAC audit chain as an
  activity.result receipt carrying the modality, the content hash, and the
  prior chain digest.
• A verifier can join a chain entry to the recorded activity and confirm the
  modality and payload hash without replaying the run.
• bernstein activity renders and checks the recorded modalities.

Detached run service (#2352)

A run is no longer tied to the process that started it. Operators submit a
goal, disconnect, and reattach later.

• bernstein run-service submits a goal, detaches to a supervisor, and
  reattaches to an existing run.
• A restart resumes from the durable run descriptor and ledger rather than
  starting over; the active chain is never rotated mid-run.
• Submit, detach, reattach, and completion are each run.lifecycle receipts
  in the audit chain, so the full life of a detached run is reconstructable.
• Run directories are realpath-contained under the service root, so a run id
  can never redirect state outside the runtime tree.

Follow-ups: broader supervisor back-pressure controls are tracked separately.

Tournament runs (#2353)

A hard task can fan out into parallel attempts and keep only the winner, with
the decision fully explained.

• A task declares attempts: N with scripted evaluators (test pass rate,
  lint status, coverage delta, mutation score, or an arbitrary command).
• The scheduler runs N sibling attempts in isolated worktrees with identical
  inputs; the winner is a pure function of the evaluator outputs with a
  stable attempt-hash tie-break, with no model call in the decision path.
• The result is a signed, spine-anchored TournamentReceipt naming every
  attempt hash, every evaluator output, the winner, and the lineage edges;
  the selection is mirrored as a tournament.selection audit event.
• bernstein tournament show and bernstein tournament verify render and
  recompute a selection offline, so a tampered score or a hand-picked winner
  diverges from the replay and fails.
• Fan-out is gated on the task's existing per-ticket budget ceiling and
  aborts before spawning when projected spend would breach the cap.

Cost-aware scheduling (#2354)

Dispatch decisions now respect USD budgets and route work to the cheapest
surface that can honour it.

• Each cost-aware dispatch is a cost.dispatch_receipt: a deterministic
  admit or halt under USD caps, pinned by a decision hash over the price
  table, spend ledger, and caps, so two operators replay the same verdict.
• Non-interactive work routes to a provider batch surface where the adapter
  declares one; a prompt-cache window schedules a warm-up fan-out where the
  adapter documents one. Both capabilities are declared per adapter and
  default to the conservative option, so work is never routed to a surface an
  adapter does not offer.
• Pool preflight projects per-pool spend before dispatch and refuses work
  that would exhaust a pool.

Follow-ups: additional provider batch endpoints are added as adapters declare
them.

In-process verification gate (#2360)

A gate-capable adapter can enforce the completion and path policy in-session,
the moment a worker believes it is done.

• bernstein hook-gate reads the worker's hook events, loads the task policy,
  refuses an out-of-scope write, and refuses to end a turn on a failed
  required check.
• A gate decision is sealed as an evidence bundle, so a verifier cannot tell
  from the schema whether the gate fired in-process or scheduler-side.
• An adapter with no blocking hook surface injects no gate hooks and degrades
  to the authoritative scheduler-side gate with no policy weakening.

Spec-to-task-graph pipeline (#2361)

Teams that write specs first get a supported path from a requirements
document to a gated task graph.

• bernstein plan compile holds at most one model call: draft extracts
  acceptance lines into a content-addressed requirement set, approve binds
  the requirement-set hash into the audit chain as a spec.requirement_set
  receipt, and compile turns the approved set into a task graph as a pure,
  model-free transformation.
• Each task node is content-addressed over the requirement lines it
  implements, so the same approved set always compiles to a byte-identical
  graph and editing one requirement re-plans only the affected node.
• A verifier can prove offline that a graph was compiled from the exact
  requirement set the operator approved; any post-approval edit breaks the
  chain.

SPIFFE-compatible workload identity (#2363)

Fleets standardizing on SPIFFE workload identity can map a bernstein fleet
onto deterministic SPIFFE IDs.

• The Ed25519 install identity and each agent card map onto a deterministic
  SPIFFE ID, so two operators derive the same id for the same install and
  agent and a verifier re-derives it later.
• With a SPIRE agent present (optional bernstein[spiffe] extra), the issued
  X.509-SVID is bound to a card by a spiffe.svid_binding receipt that
  re-derives the id, refuses any SVID whose id disagrees, and appends the
  binding hash to the audit chain.
• bernstein spiffe id derives the id offline and bernstein spiffe verify-binding re-derives it and proves the card-to-SVID binding against
  its chained receipt. Without the extra, the self-contained Ed25519 path
  stays the default and every existing flow is unchanged.

MCP Tasks extension (#2364)

Long-running runs are exposed through the MCP Tasks surface as verifiable run
handles.

• A run handle is emitted as an mcp.task_handle receipt, so a caller can
  reconnect to a long-running run and verify the handle against the chain.

Receipt-backed skill and plugin update path (#2369)

Installing and updating bernstein as a skill or plugin now produces
provenance rather than a silent overwrite.

• An update is a plugin.update_receipt: the manifest hash and spine anchor
  are recorded, and an update whose manifest hash does not match the receipt
  is refused.
• Aggregate install status reports the verified state across installs.

Run review board: diff viewer, evidence panel, attested actions (#2365)

The run review board gains a diff viewer and an evidence panel, and every
board action is attested.

• A reviewer sees the run diff and the sealed evidence behind each step in one
  view.
• Approvals and rejections are review_board.action receipts joined to the
  run journal, so a review can prove which action a principal took under which
  scope.

Windows process and worktree parity coverage (#2367)

Windows process and worktree branches gain mock coverage, and the lane
promotion path is documented, closing gaps ahead of first-class Windows
support.

MCP registry OCI packaging fix (#2424)

The MCP registry packaging path publishes a correct OCI artefact, fixing the
registry publish flow.

Upgrading

pipx upgrade bernstein     # or: uv tool upgrade bernstein

No configuration migration is required. The SPIFFE integration is opt-in via
the bernstein[spiffe] extra; every other capability is available by default
and leaves existing flows unchanged.