The Gallery Shipped — Every Post Now Moves

📊 Build Receipt

The numbers behind the ship. Treat it as a receipt, not a brag.

💥 What Was Broken

Every post had the same recycled animation library at the top. One canvas, the same shapes, the same loop — copy-pasted across the whole catalogue.

It worked the first time you saw it. By the third post it was furniture. The animations didn’t teach the post’s claims. They were decoration.

🎯 The Plan: Four Animations Per Post, Five Paradigms

Each post would get 4 unique animations, picked specifically to teach that post’s claims. No animation would appear twice across the catalogue.

Five rendering paradigms in the mix, so the gallery as a whole would feel varied:

Hard rules per post: single-file edit, namespaced CSS prefix, lazy-init via IntersectionObserver so animations don’t fire off-screen, a shared window.__rm__ reduced-motion helper that paints a static end-state for users who’ve disabled motion, and 375px-safe rendering for mobile.

🌊 The Wave Strategy

One worker per post. 48 posts. The orchestrator caps concurrent workers at 12 to keep terminal windows manageable.

Five posts shipped first as a pilot to lock the rules. Then the remaining 43 went out in 4 waves of 10–12 workers running in parallel:

Each builder gets a fresh ~1M context window. The orchestrator stays lean — it never builds, never researches, never scores. It writes briefs, watches results, and decides next steps.

🔍 The Audit That Caught The Bug

When a worker’s terminal closes before it can write its result file, the orchestrator can synthesize one from on-disk evidence: source code modified, screenshots captured, animation infrastructure present, signoff in the chat log.

Sixteen of the 43 builders ended that way. Their work was on disk, the screenshots looked right, and the orchestrator wrote “synthesized” result files for each. The first auditor scored from that evidence and called it shipped.

A second auditor — Auditor-Synth — was spawned for exactly this reason. Its job was to open each of the 10 unverified synthesized posts in fresh Chromium with page.on('pageerror') wired up.

Nine passed cleanly. One didn’t. Builder-Gallery10’s incremental-shutter animation threw TypeError: Cannot read properties of undefined (reading 'x') on both desktop and mobile. The screenshots had looked fine.

🐛 The Bug, The Real Root Cause

The respawned builder reproduced it on the first frame. Then it found the cause — and it was not what the brief had suspected.

The brief blamed an async race: cellsLayout getting accessed before its grid coordinates were populated. That guess was wrong. cellsLayout always had its 10 entries.

The real cause was Chrome’s clock. The animation set last = performance.now() just before calling requestAnimationFrame, then computed dt = (now - last)/1000 inside the callback. Those two clocks — performance.now() outside, the rAF DOMHighResTimeStamp inside — can disagree by a few microseconds because of timer coarsening.

That made dt briefly negative on the very first frame — about −22 microseconds. Negative dt made the time accumulator go negative. Math.floor on a small negative number returns −1. The clamp Math.min(NUM-1, -1) kept −1 because −1 is less than NUM-1. The lookup cellsLayout[-1] returned undefined. Reading .x on undefined threw.

// before
var dt = (now - last) / 1000;
var idx = Math.min(NUM - 1, Math.floor((cycleT / SWEEP) * NUM));
ctx.fillRect(cellsLayout[idx].x, ...);  // throws on frame 1

// after
var dt = Math.max(0, Math.min(0.05, (now - last) / 1000));
var cycleT = ((shutterT % SWEEP) + SWEEP) % SWEEP;
var idx = Math.max(0, Math.min(NUM - 1, Math.floor((cycleT / SWEEP) * NUM)));

Three fixes, defense-in-depth: clamp dt non-negative, wrap cycleT non-negative, clamp idx non-negative.

🔧 Preventive Sweep

One bug like that means there might be others. The pattern to grep for: Math.min(N-1, Math.floor(...)) with no Math.max(0, ...) guard, where the inner expression could go negative.

Sixteen hits across the catalogue. Each one inspected by hand. Two were already guarded. The other fourteen were safe by construction — either the input was a scroll progress clamped 0–1 by the framework, or the result was used as display text rather than an array index, or a loop bound made the negative value harmless.

No other post was actually vulnerable. Two artifacts left in the workspace so the next builder doesn’t reintroduce the pattern:

• work/check-pageerrors.mjs — a reusable Playwright probe that listens for pageerror, console.error, and failed requests. Exits non-zero on any real error. Builders run it pre-signoff.
• work/research-brief.md §4b — a new rule for rAF first-frame patterns: initialize last to null, set it inside the rAF callback, clamp dt non-negative, clamp any time-derived array index on both ends.

💡 What I’d Do Differently

The lesson isn’t “synthesized result files are bad.” They’re a reasonable fallback when a worker terminal closes mid-run. The lesson is “synthesized is not verified, and you can’t paper over that with screenshots.”

Next time, every builder runs the check-pageerrors.mjs probe before signoff. If the probe is non-zero, the result file gets stamped fail regardless of how good the screenshots look. The fresh-Chrome listener becomes part of the build, not an audit afterthought.