A /tmp leak at render thirteen: shipping meshcheck's deterministic renderer

What shipped

Rendering went from spec to product surface. The renderer/ package carries the deterministic harness built in P2M2 — the studio rig, one whole-scene camera fit shared across all angles, Draco/meshopt/KTX2 decoders, and a RenderBackend seam — and now also the deployed form: api/render-internal, a Vercel Large Function running @sparticuz/chromium under playwright-core, gated by its own header secret and invoked intra-deployment by the API.

meshcheck-core owns the judgment. RND-001/002/003 are registry checks fed by injected integer evidence; validate_with_render and render_report are new wasm exports; screenshots ride Report::assemble’s existing slot. On top of that: /v1/validate full mode (Blob staging, six angles, signed /s/ screenshot URLs bound to report expiry, 2 credits), /v1/render returning the Rust-assembled RenderReport, async turntable GIFs, a RENDER_FAILED error that is reachable only where the render is the product, and an invisible corpus mutation only RND-002 can catch.

Decisions

The frontmatter carries all nine. The chain that matters most runs through the phase: the P2M1 spike earned the exact-hash gate with 496/496 deployed samples, P2M2 froze the integer-evidence contract that makes TS incapable of influencing verdicts, and P2M5 stress-tested the whole stack — including a CPU-tier migration mid-gate that moved zero hash bytes. The one revised number of the phase is the latency target, and the revision is a decision with named rejected alternatives, not a quiet edit.

What broke

The centerpiece: the deployed renderer poisoned its instance after ~12 renders. The P2M4 plan said “clean the per-launch /tmp profile dir”; the implementation closed the browser but never removed profiles. Hermetic tests and short smokes could not see it. The phase gate’s sustained runs hit it in minutes — renders 1-12 byte-correct, render 13 onward failing in ~1.2s with render function 500, instance-local, no self-heal, sometimes preceded by blank frames hashing 30e14955…. Diagnosis was initially blinded because the API discarded renderer 5xx bodies. The fix (9c5dbab) is a per-request mkdtemp profile via launchPersistentContext removed in the same finally, an age-gated stale sweep, surfaced 5xx bodies, and — same commit — async render jobs learned to unzip bundles, which the gate also exposed.

The latency gate then failed honestly three times: 13.8s, 8.9s after the Performance-tier flip, 9.2s with packing disabled (reverted — worse p50, no p95 gain). We revised the threshold rather than disguise queueing as latency.

Smaller breaks: the /s/ routes 404’d on first deploy (vercel.json rewrite missing — app mounting and platform routing are separate truths); KTX2Loader’s multiline ktx-parse import slipped past the vendor sweep; sparticuz v149 required dynamic-import over require (ERR_REQUIRE_ESM); gifenc has no ESM named exports; review upgraded the internal-key check to a constant-time compare.

Numbers

Gate evidence lives in bench_results/phase2-determinism.json: 36 (asset, angle) cells, one hash each, across three runs on three separate deployments, equal to the local table — FlightHelmet traveling as a 47MB zip through the async path. Latency was measured as the /v1/validate POST span (staging PUTs excluded, disclosed), 60 requests at concurrency 4 plus a 10-request sequential sample; the config comparison in the frontmatter is what justified the standing tier. The checks_only load row was re-run mid-experiment and came back better than its Phase 1 value (p95 245ms vs 297ms).

Next

Phase 3 is distribution: the meshcheck-mcp npm package, the Astro site with the drag-and-drop demo on a browser key, and cookbook drafts. Its gate wants a recorded agent transcript naming a real defect, a sub-10s browser demo, and Lighthouse ≥ 90 on the landing page.