The maxB Flash

Two fixes, one cause, one doctrine honored.

Symptom

S&P and Crude Oil lanes on claudeberg.com/atomic would paint for a single frame, then fade to dark. The other three lanes (H100, Gold, BTC) rendered fine. The user's words: "looks ok for a frame, then fades."

False start (H1)

Codex was dispatched to audit atomic.html statically, ranking flash hypotheses. Top candidate: the resize guard used raw-floating-point DPR equality:

if (w === _lastW && h === _lastH && dpr === _lastDpr) return;

On iOS, devicePixelRatio can jitter between 2.0 and 2.00001. Strict equality misses that, so canvas.width = w runs every frame — which clears the bitmap. Plausible. We patched it to compare effective integer backing-store dimensions, deployed, purged cache. The live HTML had the fix.

It didn't stop the flash.

This is where the closed-loop debugging doctrine showed up for the collar. "A visual bug is closed-loop only when you see the pixels after your fix." Text-grep verification of the deployed file is not seeing the pixels.

The actual bug

Opened the page in headless Chrome via mcp__chrome-devtools__*. Listed console messages. The DOM had only just hydrated and already:

renderLane xyz:SP500 ReferenceError: maxB is not defined
renderLane xyz:CL    ReferenceError: maxB is not defined

3,363 errors in six seconds. Every render frame. Only for lanes that had accumulated bloom events (SP500 and CL). The other three lanes rendered clean because their blooms arrays were empty, so the offending code path was never hit.

The bug:

// atomic.html:1427
const vx = liveX;
if (vx > chartLeft && vx < forecastRight) {
  // ...
  const maxB = Math.round(W * 0.025);   // ← declared INSIDE the if block
  // ...violin + heat + wall labels use maxB here...
}

// ...180 lines later, OUTSIDE the if block...

// atomic.html:1625 — the blooms loop
for (let i = inst.blooms.length - 1; i >= 0; i--) {
  // ...
  const x0 = isBid ? vx - maxB - 2 : vx + maxB + 2;  // ← ReferenceError
}

const is block-scoped. maxB lived and died inside the if (vx in viewport) block. The blooms loop reached for it two hundred lines down and found a ghost. The per-lane try/catch we'd added the day before swallowed the exception into console.error. Swallowed means silent: no red banner, no broken page, just lanes that never got drawn. And because the page was in persistence-mode (each frame fades the previous one by α=0.25 before drawing), the stale silhouettes washed out over about four frames. That's the "looks ok for a frame, then fades."

The fix

Hoist the declaration above the if:

const vx = liveX;
const maxB = Math.round(W * 0.025); // hoisted for blooms loop below
if (vx > chartLeft && vx < forecastRight) {
  // ...
}

Two lines. Deployed, purged, hard-reloaded. Console went from 3,363 errors to 2 (both unrelated 401s on a gated resource). Two screenshots three seconds apart: all five lanes painting, only live price ticks differ between frames. Closed loop.

What we learned (the durable part)

1. A silenced exception is worse than a loud one. The per-lane try/catch we added the previous day to isolate render failures was technically correct — it prevented one bad lane from breaking the whole frame. But when the catch path is just console.error, a bug that throws on every frame looks visually identical to a data-starvation bug, a GPU reset, or a compositor flash. The symptom points everywhere. Log plus a visible placeholder is better than log plus silence.
2. Text-grep verification of the deploy is necessary but not sufficient. We verified yesterday's fix was live by curl + grep and claimed "deployed." It was deployed. It didn't fix the actual bug. Only seeing the pixels post-fix closes the loop.
3. Scoping errors hide behind "which lanes have data." SP500 and CL were the two lanes receiving trade events at this time of day. The other three were not, so their blooms arrays stayed empty and the offending line at 1625 never executed. A JavaScript bug that depends on whether a loop body runs can look like a data-specific rendering bug. It isn't. It's a lexical bug pretending to be a data bug.
4. The rubric is generative, not exhaustive. The H1 hypothesis list from the static audit was excellent analysis. It just didn't include the bug. The lesson isn't "rubrics are bad," it's "a ranked hypothesis list is a starting point, not a proof. Close the loop with the eyes before you claim a fix."

The stack that got us here

• Codex (gpt-5.4, xhigh, workspace-write sandbox) — ran the static audit that produced the H1/H2/H3 ranking. One of the agents got blocked on sandbox scope and returned its report inline in the stdout stream instead of writing the artifact. Both outcomes are fine; the content is what matters.
• chrome-devtools MCP — once we cleared a stale profile lock, this was the fastest path to "see the actual pixels." new_page + take_screenshot + list_console_messages is a three-step closed-loop primitive.
• Wrangler + Cloudflare API — deploy plus zone-level cache purge in one shell pipeline, gated through gatekeep.sh so the CF token never touches the transcript.
• flashscope — a small Rust tool we built this session (tools/flashscope) to capture headless-chrome screenshots at intervals and detect flash patterns via pixel diff. We didn't need it to find this bug — the console errors were the tell — but it stays as a standing red-team instrument for future visual-glitch hunts.

Doctrine

mindpalace/DOCTRINE/CLOSED-LOOP-DEBUGGING-DOCTRINE.md

• R1. Second "still broken" = screenshot before more code.
• R3. Per-item try/catch in render loops isolates failures — but log + visible placeholder, not log + silence.
• R5. Deploy verification: cf-cache-status: MISS + grep the body.
• R6. Two screenshots > one. Flash is a delta between frames.
• R9. A ranked hypothesis list is generative, not complete. Close the loop.

Session stack: Claude Opus 4.6 (1M context) + Codex gpt-5.4-xhigh + chrome-devtools MCP + wrangler 4.78.0 + gatekeep 1Password bridge. Live version: 89fc0e7a-d778-4da4-8930-ab931cf57d43.