What Went Wrong
The game builds: Brick Break, Maze Muncher, Star Swarm — the failures behind the guides
Three games built with agent teams, three tutorials that read smoothly — and, underneath, a set of failures worth more than the wins. This page collects them from the records kept at the time (build status reports and the platform's chronicle), the same honesty rule as the Potluck post-mortem: nothing reconstructed from memory, root causes named, and each incident tagged with the failure family it belongs to.
The white box: three bugs in a trench coat
What happened. Brick Break went live embedded on the framelogic.ai homepage; Tommy opened it on his iPhone and saw a white box. One report, one symptom — and underneath it, three stacked problems, each one masking the next:
- The game really was broken on older iPhones. It called
ctx.roundRect(), which shipped in iOS Safari 16.4 — anything older threw on frame one and painted nothing. Fixed with feature detection and anarcTofallback, then verified honestly: delete the API from the prototype and watch it still render. - It had no touch input at all — mouse events only. A phone could see it but never play it. Input moved to Pointer Events (touch + mouse unified).
- And the white box itself was us. The platform's own anti-framing armor —
frame-ancestors 'self'+X-Frame-Options: SAMEORIGIN— refused the cross-origin embed on every device, for every visitor. The same day's morning bug had been the same wall in the other direction (frame-srcblocking us from framing others). Neither threat model had included ourselves as the adversary.
The root cause that matters isn't any single bug — it's why three fix rounds passed while the user kept seeing white: every probe tested the direct URL, which loads, renders, and tracks touch perfectly, while Tommy was looking at the embed, where anti-framing headers fire. "The page works" and "works where the user is looking" are different claims. The hunt collapsed when Tommy himself asked: "are you testing the game url and I'm testing the home page?" Yes. The standing rule minted that night: reproduce the user's viewing context, not the resource. (Potluck family: root cause 6, trusting the instrument — here the instrument was the wrong vantage point.)
The fix stayed scoped, not surrendered: only /games/* — the namespace whose entire purpose is being embedded — became frameable; everything holding a session kept the armor.
A narrated action is not an action
What happened. Mid-build, with the white-box report coming in and priorities pivoting, the tutorials implementer agent was announced as launched but never actually spawned. The narration said the work was running; the tool call had never gone out. It was caught only when Tommy asked for a progress update on an agent that didn't exist. Respawned immediately — no work lost, but time was, and the claim was false while it stood.
The rule, recorded plainly in the chronicle because it should sting: verify a spawn like any other side effect before reporting it. This is the agent-team version of "exit code zero isn't correctness" (Potluck root cause 4) — except the tool reporting false success was the orchestrator's own narration.
The eyes that never went home
What happened. Maze Muncher's playtest round found eaten wisps whose eyes bounced forever on one corridor instead of returning to the den. Root cause, from the build log: the wisps' one-step greedy turn rule — pick the neighboring tile that minimizes straight-line distance — cannot route around a wall block. It was good enough for chase-and-scatter (where wrong turns self-correct), and structurally wrong for go-to-exact-tile. The fix gave eyes a memoized BFS distance map home; the regression test then failed on every one of the 21 mazes — including the original — proving the bug had been there since the first level and only geometry had hidden it.
The lesson: a heuristic that looks correct is a bug whose trigger hasn't shipped yet. Twenty new mazes didn't create the defect; they created the coverage. (Potluck family: root cause 3 — the assumption "greedy is fine here" was never verified, and the seams — pure logic, testable per-tile — made the fix and its proof cheap.)
The same playtest report carries a quieter multi-agent confession: the fixes touched files outside the maze-pack lane's ownership map, done at the user's direct request, with an explicit note to the sibling agent — "please integrate rather than re-implement." That's the one-writer rule bending under real-world pressure and being handled by disclosure instead of silence. It's the honest version of a merge conflict.
The one-frame-per-second phantom
What happened. During animation work verified through an automated browser, everything stuttered — because a minimized Chrome window throttles requestAnimationFrame to about one frame per second. The "janky animation" being debugged was the window manager's power saving. Standing rule since: probe the rAF gap first, raise the window before trusting any motion measurement. Same family as Potluck's headless-Chrome viewport floor (root cause 6): measure the instrument before the code.
The fix that hid behind its own cache
What happened. Re-vendored game fixes could sit invisible behind a visitor's cached copy of the old files — a shipped fix that a phone refuses to see is indistinguishable from an unshipped one, and during the white-box night that ambiguity cost real diagnostic time. The vendoring script now stamps asset references with the source commit (?v=<sha>) on every re-vendor, so a fix and its delivery can't diverge. (Family: root cause 5 — two versions of the code, one shared state; here the shared state was the browser cache.)
What the record shows overall
Read against the Potluck post-mortem, the striking thing is that the game builds and the app build failed in the same shapes at different scales: assumptions unverified until real contact (greedy routing, "our headers won't bite us"), success signals that weren't correctness (a narrated spawn, a passing direct-URL probe), version-vs-state skew (browser caches instead of queue workers), and instruments trusted before they were measured. The families repeat because they're properties of building with tools that report their own status — which is why each guide in this series now ships with its failures attached. The wins teach the pattern; the failures teach the judgment.