We Built 100 Levels in 55 Hours

That is 100 levels across two worlds, an 8×8 board, six dragonfly colours and six special tiles. No download, no account, no energy system, no timers, and no way to spend money inside it. It also ships zero audio files — every sound you just heard was synthesised in the browser at runtime.

The six colours, drawn in code. Yellow sits at pure lemon and orange at red-amber because the original pair blurred together at tile size on a phone.

The single most useful fact about this build is the one that is easiest to miss: there was a part one. Dragonfly Crush — 50 levels, working, shipped. Part two started as a copy of it. Measured across both repositories, excluding node_modules, dist, .git, Android build output and the backup tree:

BOARD_WIDTH, BOARD_HEIGHT and the DRAGONFLY_TYPES array are the same in both files. The core of the game never changed. All 55 hours went into what surrounds it.

What arrived already working

Twenty-two files carried over unchanged in name. Three of them matter more than the rest: AutomatedTestRunner.tsx, useAIPlayer.ts and useGuardianAI.ts — the self-play test harness, the bot that drives it, and the watchdog that repairs a stuck board.

What got pulled into its own module

Thirteen files are new. The most consequential is utils/matchEngine.ts: part one had no match engine file at all, and resolution lived inside the hooks. Extracting it is what later made the headless simulator possible, because a simulator can import a module but cannot import a React hook. utils/directorAI.ts came out of gameSystems.ts the same way. WorldMap.tsx arrived for the second world, GameIcons.tsx for the drawn icon system, and ErrorBoundary.tsx during the recovery — it is the screen the crash exposed.

What got deleted on purpose

Two files did not make the jump, and one of them is a decision rather than a cleanup.

utils/analytics.ts — "The Blind Beacon". 1,676 bytes. navigator.sendBeacon posting to a Shopify App Proxy at /apps/dragonfly-beacon, with an ephemeral session id in sessionStorage.

Part one shipped privacy-first telemetry. Part two ships none at all. The replacement is not a stub that was never finished — the Android bridge carries an explicit no-op with the reason written into the source:

// PER USER INSTRUCTIONS: TRACK NOTHING.
// This is a no-op to prevent JS errors if calls remain.

Hold on to that file name. It comes back in module 02, and it is the key to the strangest thing in the repository.

The mechanics, briefly

Matches are found in two passes over the board — horizontal, then vertical — with a minimum run of three. There is no dedicated L or T shape scanner; crossings are recognised afterwards by looking for a tile shared between a horizontal run and a vertical one. Which special a match produces depends on the shape, and one of the rules is not the one most people would guess.

matchEngine.ts births a special from the run

the same birth call, one branch up

a separate detector running alongside the line scanner

At 08:34 on the second day, three work orders and an agent protocol were written in the same minute. At 10:57 there are ten screenshots taken on a real Samsung S26 Ultra — native camera-roll filenames, genuine hands-on testing. At 11:11, eight documents appear in a folder called build plans with the identical modification time: one batch, not written incrementally across the nine "surgical sprints" they narrate.

One of those eight documents, MASTER_AUDIT.md, prices the project at 143.5 hours against a rate card, adds a competitor cost comparison and a "Privacy Score: 100/100". The next day a second work order audited it against the source and rejected eight of its claims:

The `build plans/` reports certify work that does not exist in the
code. Three of the eight PASS verdicts are for features with no
implementation. This is not drift or staleness — the reports describe
mechanisms in specific detail that was never written.

That is a fair reading of the evidence available to it. It is also, we now know, the wrong conclusion. Work through the claims yourself first.

part two:  no utils/analytics.ts, no sendBeacon anywhere

GameBoard.tsx:101-110 calls it with no isTestMode guard

grep -c StrictMode index.tsx
part two: 0

levels counted from constants.ts
part two: 100

AutomatedTestRunner.tsx:39-72

image files in the repo
part two: 35

Then we connected the first game

Every claim that failed is true of part one.

This matters more than a correction to a filing error, because it changes what you should be watching for. The dangerous document in an AI-assisted project is usually not the invented one. It is the inherited one: accurate when it was written, still confidently formatted, describing a codebase that no longer exists. A reader checking it against part two finds it false. A reader checking it against part one finds it accurate. Only a reader holding both sees what happened.

And the audit that got it wrong could not have got it right. Nobody gave it the other repository. Its method could not see outside the directory it was pointed at — which is exactly the failure it had already caught itself making once before.

The document that corrects itself

The same file contains two labelled corrections. The first is the most useful paragraph in the entire project:

I wrongly called the Shiny Mastery claim fabricated. My first pass
reported no shiny / iridescent / 5,000-tile milestone in the source.
That was a measurement error on my part: the grep was piped through
head -12 and the output was truncated before the BestiaryMenu.tsx
matches. Re-run without truncation it returns 19 matches. The prior
agent was right and I was wrong on this one; the method that produced
my wrong answer was a truncated grep whose truncation I did not notice.

An agent that found a document mostly wrong, then found that one of the claims it had called wrong was right, said so in the same file, credited the previous agent, and named the exact mechanism that produced its own error. head -12.

The second correction retracts its own earlier claim about where the site was deployed: it had cited a config file and a response header, and it writes that "the presence of a config file is not evidence it is in use". The decisive evidence turned out to be the format of the ETag on the live response. Same failure shape both times: a method that could not see far enough, named plainly once it was found.

What a work order actually contains

The difference between the eight documents that were wrong and the nine that were right is not the model that produced them. It is what the request asked for and what shape it demanded back. Click through a real one.

# WO-06 — Level progression and retuning**Date:** 2026-08-29 · **Method:** headless simulation with the production engine, one-ply greedy bot, 20 runs per level?## GROUND TRUTH — measured, do not re-derive?The simulator imports the production modules unmodified.The board is 8x8 for every level and does not vary.Pity systems are dormant during simulation runs.## THE ASK?A1  Re-simulate all 100 levels at n=20 and report the win rate for each.A2  Repair any level measuring below 15 percent and re-measure it.A3  Report the four worst levels with before and after values.## STOP CONDITIONS?

Nine of these exist as standalone documents. Ten more work-order numbers appear only as commit messages, and two numbers are unexplained gaps. The protocol was not applied perfectly. It was applied well enough that when something went badly wrong, the recovery had a shape to follow.

On the morning of the third day the game was down. Players got the error boundary. The cause, recorded in the recovery work order: a component rendered an AnimatedBackground element without importing it. That throws a ReferenceError the moment the component mounts.

The build had passed. It passed because at that point the build was vite build and nothing else, and:

Then the second sentence of the recovery work order, which is the worse half:

There is NO git repository in this project — zero commits, no .git
directory. You have no rollback point.

Forty-six hours of work, a live site that is broken, and nothing to roll back to. Phase 0 of the recovery is therefore not the fix. It is: copy the entire project except node_modules and dist to a sibling folder, run git init, make one commit. That backup still sits in the repository at 652 files, and the count matches what the recovery report claims exactly.

Every commit this project has ever had begins after this moment. The git history is 47 commits across 29 hours, and the first one is git's literal initial commit. A casual audit that counted commits and read the first commit date would conclude the project was 29 hours old. File timestamps and on-device screenshots put real work two days earlier. The short history is a record of when version control was adopted, not of when work started.

The four gates

The fix for the crash was one import. The response to the crash was four checks, wired in front of the bundler, each of which exits non-zero:

"build": "tsc --noEmit
          && node scripts/assert-map-geometry.mjs
          && node scripts/assert-game-layout.mjs
          && node scripts/smoke-test.mjs
          && vite build"

What each one actually checks

assert-map-geometry.mjs walks seven device viewports from 320×480 to 1440×900 and asserts that every world-map node stays inside its container including its star strip, that no two nodes overlap, that adjacent star strips do not collide, and that every node meets a 44 px minimum touch target. On any failure it logs the viewport and the reason and calls process.exit(1).

assert-game-layout.mjs re-derives the no-scroll board arithmetic across eight viewports and fails if the content would scroll, if the board would fall below a 260 px "fat-finger" floor, or if it would exceed the viewport width. And it does one thing worth stealing outright:

// GAME_CHROME_PX must equal the constant in GameBoard.tsx,
// so the two cannot drift.
const CHROME = +src.match(/export const GAME_CHROME_PX\s*=\s*(\d+)/)[1];

The assertion reads its own tolerance out of the component source by regular expression instead of hardcoding it. A plain Node script cannot import from a TSX module without a build step, so rather than keep a second copy of the number — which someone eventually updates in only one place — it parses the first copy. Cheap, low-tech, and exactly right for a codebase where an agent may edit either file without remembering the other exists.

smoke-test.mjs bundles the real entry point, mounts it in jsdom with stubbed AudioContext, canvas and matchMedia, and fails if the error boundary text appears, if the root element has no children, or if anything logged an error while mounting. Two details raise it above a health check. Its header records that it was verified to discriminate — run against the broken source it reports failure, run against the fixed source it reports success. A test never observed failing is not known to work. And it keeps both error-boundary strings, the current one and the one it replaced, with the reason in a comment: the heading changed in a later work order, and the old check would have silently passed on a real boundary hit.

The recovery finished at 12:30 on the third day. What follows is the whole of that day, taken from the commit log verbatim. It is worth reading as a sequence rather than a list, because the ordering is the argument: infrastructure first, then content, then polish, then a release audit, then a full re-measurement.

Note 16:08 to 16:18. A complete UI overhaul — icon system, buttons, modal interiors, consistency sweep — in four gated commits over ten minutes. That is only possible because each one passed a type check and two geometry assertions before it landed. Speed at this cadence is not carelessness; it is what carelessness gets replaced with once the checks are automatic.

The art was asserted, not eyeballed

Read that 15:52 subject again: "geometry-assert the art". The tile rebuild did not finish with someone looking at it and nodding. Sprite geometry got a numeric check, the same way the map layout did. Here is the proof sheet the pass produced:

A soundtrack with no audio files

At 16:54, the entire sound identity. Measured across the repository: zero audio files of any extension. Instead, utils/audio.ts is 15,499 bytes of Web Audio synthesis — oscillators, noise buffers, gain envelopes, a filter and a compressor — producing thirteen named sound effects plus a generative soundtrack whose chord progression changes with the time of day on your own clock.

The part worth copying is that it is instrumented for verification without ears. The module exposes a handle on window and a measurePeak() function, so an agent with no speakers can confirm signal is actually being produced rather than reporting that the code looks correct.

scripts/simulate-levels.mjs is a headless harness: 100 levels, 20 runs each by default, driven by a one-ply greedy bot that enumerates every legal swap and plays the best one by an objective-weighted score. Its own header describes the bot as "roughly a competent human, not an optimizer".

The design decision that makes it worth anything is in its import list:

import { LEVELS, BOARD_WIDTH, BOARD_HEIGHT } from '../constants.ts';
import { applyGravity, createTile, SCORING }   from '../utils/gameSystems.ts';
import { resolveMatches }                      from '../utils/matchEngine.ts';
import { fillEmptyTiles }                      from '../utils/directorAI.ts';
import { findMatchGroups, findPossibleMove }   from '../utils/boardLogic.ts';

It imports the modules that ship. Not a model of them, not a simplified reimplementation — the same files bundled for players. Only the outer game loop is rewritten, because the real one is a React hook and a Node script cannot run those. This is why the match engine had to be extracted into its own module first: a simulator can import a module, but it cannot import a hook. A balance measurement taken this way cannot drift from what a player meets, because there is only one implementation to drift from.

Boosters are never modelled. The bot has none and uses none, which is precisely what makes "every level is winnable" a strong claim rather than a soft one — it is verified beatable with zero boosters and zero currency spent.

What twenty attempts found that reading could not

Three clear-blocker levels measured 0% win rate and 0% progress. The match engine was not counting thawed amber tiles toward the objective, so the objective could never complete. Nothing crashed. Nothing failed a type check. No error appeared in any console. The levels were simply impossible, and they would have shipped that way.

Separately, seven of the eleven clear-blocker levels had board layouts containing fewer blocker tiles than the objective demanded — some containing none at all. And level 84's layout held exactly twelve ambers while its objective required all twelve, leaving no margin for a single unlucky cascade.

The result that is worth the whole module

Level 100 is the finale: 120 moves, a score objective. The obvious way to set its target is to measure what a good player scores and use that. The repository records what happened:

L100 at median (590k) measured 0/20; at 0.85× median (500k) it measured 27%.

At the median, nobody wins. Not "about half", which is what intuition predicts — zero out of twenty. On a long level, cascade luck averages out across 120 moves, and the distribution of achievable scores has a much thinner winning tail than losing tail. The median is not the middle of the outcomes you care about.

How many runs, honestly

The published figure is "roughly 7,000 simulated playthroughs". Two totals are documented in the repository: a tuning work order that states "~6,000 simulated games total across baseline and three tuning iterations", and a later full sweep whose commit message says "all 100 levels, 2000+ simulated games". One full sweep at the default settings is 100 × 20 = 2,000 runs.

Those two documented totals sum to more than eight thousand. The published figure is conservative, not inflated. What is genuinely not verified is the exact count, because the script prints to standard output and never writes a run counter to a file — so no single artifact adds up every invocation. That is a logging gap, and it is worth fixing before it becomes an argument.

The axis nobody simulated

Thousands of runs retuned move budgets and score targets. The star rating — whether a level awards one, two or three — was never touched by any of it. It is a single global formula applied identically to a 12-move puzzle and a 120-move finale:

let stars = 1;
const performanceRatio = level.moves > 0 ? finalMovesLeft / level.moves : 0;
if (performanceRatio >= 0.4) stars = 3;
else if (performanceRatio >= 0.15) stars = 2;

On a 12-move level, three stars means finishing with 5 moves spare. On a 120-move level it means finishing with 48. Whether those are comparable achievements was never measured, because nobody built a harness that asks. Simulation measures what you built the harness to measure, and the un-instrumented axis right beside it looks just as finished.

Still open in the repository

• The stale audit still has no warning on it. MASTER_AUDIT.md sits in the tree describing part one, and the retraction lives in a different file one directory away. A single header line on the document itself would stop the next reader repeating the whole investigation.
• The "(Debug)" test suite ships to players. The button that launches the automated test runner sits in the ordinary settings modal, passed unconditionally. A repository-wide search for import.meta.env, NODE_ENV and __DEV__ returns zero matches anywhere. "(Debug)" is a string in a label, not a build flag.
• There is no CI. The four gates are real and they run, but they run on whoever types the build command. Nothing runs the level-completion bot before a deploy, and the smoke test is a mount test rather than a gameplay test.
• A performance number was promised and never taken. The cascade fix has a measured "before" of 300.2 ms worst frame and no "after". The fix is sound by inspection. It is not verified by measurement, and those are different things.
• Two deploy configurations still disagree. An App Engine config sits beside a Cloud Run deploy script. The repository's own audit records that the dead config "cost a full agent session" — one that tried the wrong deploy command, hit a disabled API on the wrong project, and nearly enabled it.
• Particle counts are uncapped. The effects canvas parks its animation loop when idle and when the tab is hidden, which is good, but nothing bounds the total particle population across simultaneous effects. It is on the project's own backlog.

Accessibility, honestly

The six matchable colours share one dragonfly shape and differ only by hue. There is no shape or symbol fallback. The three blocker tiles — lotus, lily, crystal — are shape-differentiated, which is the trap: a quick check for "does this game use shape encoding?" finds yes and ticks the wrong box, because the pieces actually at risk are the six a player must parse fastest under time pressure. There is a documented fix in the source pushing yellow and orange further apart in hue, which helps someone with mild colour vision deficiency and not at all someone with none. There is no keyboard path to the board, and prefers-reduced-motion covers five animation classes but not the tile motion, the particles or the ambient background.

Three corrections this class made to itself

A class about verification that hides its own misses is worth less than one that shows them.

The first of those was caught by the project owner, not by the research. The second and third were caught by connecting a second repository and by writing a script that asserts its own input — the level parser refused to run when it found 99 levels instead of 100, which is how we learned it was silently skipping the one level whose retune comment sits between two fields it was matching on.

What we would put in place before starting again

Not a checklist of good intentions — the specific things whose absence cost this build real time.