plimsoll v0.23.0

Matching a code run to an outside observation log used to need another piece of paperwork. Plimsoll's run record now has a place for the sandbox's identity. Kubernetes fills it with the pod's unique ID, and every client checks it. The delivery slip finally has a serial number.

Upgrade the server and clients together. This release uses protocol 4 and run-record version 4. Earlier clients are refused before their code runs. Old evidence still checks: verifiers read every record version a release has written, so recordings from v0.10.0 to v0.22.0 verify with this release (bundles from before v0.18.0, which have no line links, verify one record at a time). The Python and TypeScript clients are both 0.23.0.

Also included:

• A receipt challenge with deliberately wrong evidence, plus a checker that ties test results to the code revision they tested.
• Coding-session labels on execution records, standard test-result and coverage formats, and a dependency-observation log reader with its coverage limits stated.
• A documented connection for Mirror, Reflection's coding agent, through MCP, the standard agent-to-tool interface. Build the MCP binary from this release's source; its npm launcher is not published yet.
• Fresh signed examples across nine sandbox configurations, including a batch of fixed, hand-authored controllers. These demonstrate execution and checking; no model was trained to make them.
• Repairs to signed JSON handling, coding-session hook failures, timestamp ordering, file-descriptor attribution and test-result consistency. Canonical builds use Go 1.26.10.
• A new project outcome, runner_failed: your steps began and then the runner failed (an artifact it could not read, say), so your code ran. setup_failed now always means no step began. A client older than 0.23.0 reads the new outcome as unspecified.
• A project's timeout covers the whole run. A step that hangs late no longer takes the earlier steps' output with it.
• Projects behave alike across providers now, checked by one shared test suite: artifacts come back after a timed-out step, a link inside the work directory is followed, each step keeps 1 MiB of each output stream and runs on past it with its own exit code (on docker it used to be killed), a flood past 32 MiB ends a step with exit 153, and a step killed by a signal reports 128 plus the signal. The two differences left are written down in docs/run-results.md. On E2B, a project sent with no files now runs; before, its steps could not start.
• A sandbox whose cleanup fails keeps holding its capacity until it is confirmed gone, so concurrency limits keep meaning something.
• Fewer misleading answers: an over-size request is reported as the caller's mistake, not "at capacity"; output cut off after a command exited is flagged as cut; a Docker Cloud timeout is measured inside the VM, not from a slow reply.
• The simulation image now carries the buck-converter and cart-pole swing-up graders at /oracle/graders/, and the C controller examples score with them in a run of their own.
• Sessions now work on E2B; they bill against the daily allowance and need an idle timeout. (Corrected 2026-10-27: this line also named Docker Cloud, which does not have sessions yet.)
• For OpenShell operators: unless your gateway is the v0.1.2 release itself (not a prerelease of it), set agent_policy_proposals_enabled to false explicitly. Only v0.1.2 has been measured to default it to off.
• Security fixes from a full review: a signed statement now has exactly one reading (field names must match exactly, so predicate and Predicate can no longer both appear); a client given its own HTTP client or fetch no longer reports "nothing ran" for a call a retry may have delivered; on docker, a run's API access ends before cleanup starts; the Google ADK adapter refuses compositional function calling wherever plimsoll runs code in the agent tree; an E2B session call's API access ends when its steps do, not after the artifacts are read; and the shipped graders no longer let a value that is not a number pass a limit.

A receipt protects recorded statements from unnoticed changes. It does not prove that code is correct or safe. Isolation tiers describe configuration and provider evidence plus startup checks, not hardware attestation.