What qwen3.8-flash-next did

I'll start by exploring the working directory and setting up the project structure.

Empty directory. Let me plan the game.

Design:
- `index.html`, `style.css`, `game.js`.
- Canvas 128x128 logical, scaled up (e.g., 4x = 512x512) with crisp pixels (image-rendering: pixelated).
- Tile = 8 logical px. Viewport 16x16 tiles.
- Levels: each 16 tiles tall, width several screens, say 96 tiles (6 screens) for L1, wider for later.

Let me carefully design physics.

Constants (tiles, seconds):
- GRAVITY = 22
- MAX_FALL = 14
- GROUND_ACC = 18
- MAX_ROLL = 6
- FRICTION = 12
- AIR_CONTROL = 0.4 * 18 = 7.2
- RESTITUTION = 0.35
- BOUNCE_H = 3.0 tiles => v = sqrt(2*g*h) = sqrt(2*22*3) = sqrt(132) = 11.489 t/s
- PAD_H = 6.0 => v = sqrt(2*22*6) = sqrt(264) = 22.978 t/s

Fixed timestep: 1/120 s. Accumulator.

Ball radius = 0.5 tile (4 logical px).

Collision: circle vs solid tiles, resolved axis by axis. Since ball is exactly 1 tile diameter, treating AABB of 1x1 tile is close enough but "circle" — for collision I'll use AABB of the ball's bounding box (which for a 1-tile circle is the standard approach) but spec says circle-vs-solid-tile. I'll implement a proper circle-AABB sweep-lite: move X, then check overlapping tiles in the ball's bounding box, resolve by pushing out. For simplicity and reliability, using the bounding-box (square of side 1 tile) is safe: it's slightly wider than the circle at corners but never snags... Actually a bounding box of exactly 1 tile width means the ball fits exactly through a 1-tile gap. With a true circle it also fits through 1 tile gap (diameter = 1 tile). Using AABB makes corners land flush on edges which is good for platforming. Hmm, but the requirement says circle-vs-solid. I'll implement circle-based resolution: compute closest point on tile rect to circle center, if dist < r, push out along axis. For axis-separated resolution this works fine.

Let me think carefully. Simplification that's robust: treat ball as an AABB with width=height=1 tile minus tiny epsilon? That's the classic. But let's do circle: 

Horizontal pass: newX. Compute tile range overlapping. For each solid tile, check if circle (center (newX, y), r) intersects tile rect. Since we resolved vertically last frame, vertical overlap is well-defined. If intersecting, resolve: if moving right, newX = tileLeft - r; else newX = tileRight + r. But with a circle, the check "intersects" using the closest-point distance test could report a hit when only the corner region grazes — that's fine for horizontal resolution but could cause the ball to be stopped by a corner it merely grazes while falling past a wall edge. To avoid that, restrict the check to tiles whose vertical span overlaps the circle's vertical extent by more than a small amount... Hmm.

Simplest robust approach used widely: use AABB for collision (with the ball's box being [cx-r, cx+r] x [cy-r, cy+r]) but round tile lookups. Corner snagging is avoided since we do axis separation and, when moving up, we only push if overlapping. With AABB, a ball rising next to a wall and then falling: fine.

Given a 1-tile-diameter circle in an 8px tile grid, I'll use a slightly smaller collision box than the visual (e.g., collision size 0.98 tile ≈ 7.8px, use logical pixel integers? Actually let's use floats in tiles and convert to pixels for rendering).

I'll do: collision box half-extent h = 0.47 tiles (slightly smaller than the 0.5 visual radius). This gives some forgiveness: fits easily through 1-tile gaps, doesn't catch on tile edges, and the lethal spike hitbox is separately smaller. This behaves as a "circle vs solid tile" pragmatically. Hmm, the spec explicitly says circle-vs-solid-tile collisions. I'll implement a circle-vs-tile function but with the axis-split: during horizontal move, check intersection with circle radius r (0.47) using the closest-point test but with the tile expanded only... 

Let me just do AABB-with-radius using the axis split. In each axis pass, I compute the ball's AABB from center ± r. Overlap test against tile rects. Resolve along that axis only. This is literally circle-vs-tile resolution under axis-split with the circle approximated by its bounding box during each pass; it's the standard and it's defensible. But I can do better for the vertical pass: when landing on top, use the true circle's lowest point = center + r, same as box. When hitting a wall side, circle's leftmost point = center - r, same as box. Difference only at corners, which axis splitting handles. So AABB-of-circle == circle for the extremes. So the AABB approach IS circle collision for axis-aligned moves at extremes. Good — no snagging because I only resolve if there's genuine overlap in the axis direction: i.e., for horizontal, the tile must overlap the ball's vertical range strictly (with epsilon) — using the box. Fine. I'll note in comments it's circle collision resolved axis by axis using the circle's extreme points.

Actually to be safest against "sinking into corners", I'll shrink r for collision to 0.47 (7.52 px at 8px tile... 0.47*8 = 3.76 px half → 7.52px box, ball visual radius 4px). That means when the ball rests on the ground, its visual bottom extends 0.24 px below? No: collision bottom = cy + 3.76, resting on tile top at integer y. Visual bottom = cy+4 → 0.24 px below tile top. Slight visual overlap; negligible. Better: use r_col = 0.5 and just be careful, and use epsilon of 0.001. Hmm, with r=0.5 exactly, ball in a 1-tile-wide corridor: fits exactly (1.0 = 1.0). Might jitter if pushed. Use r_col = 0.48 to give margin. Visual overlap of 0.16 px — invisible. Good.

Now the bounce mechanic: "Bounce is applied only when the ball lands." So on landing (vertical collision from above with vy > 0), if bounce key is held, set vy = -bounceV. Otherwise vy = -vy * 0.35 (restitution), and if |vy| small, settle to 0.

Also to keep continuous bouncing at full height while holding: since each landing sets vy = -bounceV regardless of incoming speed, holding bounce gives constant height. Good. Need bounce to be held "at the moment of landing" — use keydown-held state. Fine.

Restitution 0.35 with repeated small bounces: falling from bounce height 11.49 t/s, on landing without hold → vy = -4.02 → height = 4.02²/(2*22) = 0.367 tiles. Then next landing vy=4.02 → -1.4 → 0.045 tiles... settle threshold: if |vy| < 1.2 t/s after restitution, set vy=0. So it settles quickly. Good.

Bounce pad: on landing on pad surface, vy = -padV regardless of hold. Also pad detection: pad is a solid tile of type PAD. When vertical resolution lands on a PAD tile, launch.

Crumbling block: solid. When ball lands on it (vertical landing on CRUMBLE tile), start timer (0.5s). After timer → collapse (not solid) with visible tell (shake before collapse: jitter offset for last 0.15s). Respawn after ~3s. Need to ensure the ball resting on it when it collapses just falls — that's fine, levels designed so falling there is safe (place crumble over safe ground, or crossing over spikes: hmm — "Collapsing must never make a level unwinnable or strand the ball." For a crossing over spikes, when the block collapses, if the ball is on it, it falls into spikes and dies. That's the classic risk; but must not strand. Crossing: the ball must run/jump across; if it lingers it dies. That's acceptable as long as it's not unwinnable (respawn before it, block regenerates). Fine.

Important: respawn places ball at checkpoint. Crumble block states reset on respawn (safer). Yes, reset crumble timers on respawn.

Now the level data. Tile chars:
- '.' empty
- '#' solid
- '^' spike
- 'o' hoop
- 'c' checkpoint
- '*' crystal
- 'P' bounce pad (solid surface, launches)
- 'C' crumbling block
- 'E' exit door (2 tiles tall) — I'll mark with 'E' at bottom and 'e' at top? Simpler: place 'E' at bottom tile and the tile above must be empty; I'll detect door as bottom char 'E' occupying tiles (x,y) and (x,y-1). Should the door be solid when closed? Spec: "It is closed, visibly closed and impassable while any hoop remains." So closed door = solid. Implement: door occupies 2 tiles; when closed, both are solid; when open, not solid, and touching either tile clears the level.

So I'll encode door as 'E' in the bottom row of the door and the top tile also 'E' (two consecutive 'E's vertically). Then the door tiles list = those. I'll require map authors to place two E vertically.

- '@' ball spawn (level start)
- 'X' ... no, use E for exit.

Also background variety: maybe 'B' for background decorative block (non-solid, purely visual)? That could help levels read differently. Let's add '~' = solid "block variant" (a distinct-looking solid, e.g., a pillar/column) — but spec says every level is built from those objects; extra decorative non-solid is fine visually. I'll allow '%' as non-solid decoration? Keep it minimal: I'll add a background layer generated procedurally per level (dots/stars) rather than map chars. Keep the map chars to the defined set only.

Level dimensions: height 16 tiles exactly, width: L1 = 80 tiles (5 screens), L2 = 88, L3 = 96, L4 = 104. Camera viewport 16x16. Camera scrolls horizontally only, camera x = clamp(ball.x - 8, 0, W-16), smoothed (lerp). Actually smooth follow could jitter; use exponential smoothing with dt-based lerp in fixed step — deterministic. Good: camera update in fixed step so frame-rate independent.

Wait: if camera follows smoothly and levels are 16 tall, ball near horizontal center. Also clamp to bounds; never reveal outside map. Since levels are exactly 16 tall, camera y = 0 always. 

Let me now design the four levels carefully. Ground at bottom rows. Let's define rows 0 (top) .. 15 (bottom).

I need to be careful about jump reachability. Bounce height 3 tiles: from standing on ground at y_ground (top surface at tile row R, meaning ball center at R - 0.5 in tile units... let's think in "tiles above ground"): a full bounce raises the ball 3 tiles. So the ball's center goes up 3 tiles; the ball can land on a platform whose top surface is up to ~2.9 tiles above current surface? Ball rests with center at surface - 0.5 (half tile above the top of the ground tile). To land on a ledge of height h tiles (top surface h tiles above current top surface), the ball's center must reach at least (ledge top surface) - 0.5 = current center - h + 0.5... i.e. it needs to rise h - ... let me compute: current center y_c = T0 - 0.5 where T0 is the ground surface level (in tile units measured upward). Ledge surface T1 = T0 + h. To rest on the ledge, center = T1 - 0.5 = T0 + h - 0.5 = y_c + h - 0.5... hmm wait sign: in screen coords y down. Let me just use "rise = 3 tiles" for center. To land on a ledge of height h, the center must reach the ledge top minus 0.5, i.e. rise needed = (h) + ... 

Let y be down. Ball center on floor at y0. Floor top surface at y0 + 0.5. Ledge top surface at (y0+0.5) - h. Ball resting on ledge has center at ledge top + 0.5 = y0 + 0.5 - h + 0.5 = y0 - h + 1. So the center rises by h - 1. Hmm that means with a 3-tile rise, max h = 4? That doesn't seem right. Let's recheck: floor tile occupies rows [F, F+1) i.e. top edge at y=F (screen y downward). Ball resting on floor: center y = F - 0.5. Ledge: its top edge at y = F - h. Ball resting on ledge: center = F - h - 0.5. Rise = (F-0.5) - (F-h-0.5) = h. So rise = h. OK, my earlier algebra was wrong. Rise = h. Great: max climbable ledge = 3 tiles exactly (touch apex exactly). For safety, design ledges at ≤2 tiles steps for comfortable play, 3 tiles max with a margin. Hmm but the apex must be reached with vy≈0 exactly at h=3 which needs the peak; and horizontal motion means it passes the ledge top at some point with residual... To land ON the ledge top at height 3, the ball must reach apex ≥ 3 tiles while its x is over the ledge. With apex exactly 3.0, at apex vy=0 and the ball's bottom = center+0.5; it needs center ≤ ledgeTop - 0.5... wait resting center is F-h-0.5 = F-3.5, apex center = F-0.5-3 = F-3.5 exactly. So apex exactly equals the required center. That's frame-perfect-ish. So ledges should be at most 2 tiles above the current surface for comfortable play. Actually more precisely: a bounce from ground can reach a ledge 2 tiles high easily (and 3 tiles with the peak exactly — too tight). Also horizontal speed doesn't affect height so it can make it at speed. I'll cap step heights at 2 tiles, with 3-tile steps only from a bounce pad (6 tiles) or when there's a mid step.

Hmm, but wait. The ball also has to clear a wall of height 3 while moving horizontally: to pass over a 3-tall wall, its center must be above wallTop - 0.5 = apex needed = 3 tiles... same tight issue. Use walls of ≤2 height for critical path, plus bounce pads for higher things.

Actually let me reconsider: the bounce height is measured from the point of launch, i.e., the ball leaves ground with v=bounceV, rises 3 tiles. If the ball is at the apex and moving horizontally, it needs the ledge top at exactly 3? Being conservative: max ledge = 2 tiles. That's my design rule. And bounce pad (6 tiles) → max ledge 5 tiles, use ≤4.

Also, horizontal distance per hop: with bounce vy=11.49, time up+down = 2*v/g = 2*11.49/22 = 1.045 s. At max roll 6 t/s, that's 6.27 tiles horizontal per hop. At half speed ~3.1 tiles. So gaps: safe gap = 4 tiles at moderate speed. To be generous, gaps ≤ 3 tiles for critical path, and landing zones ≥3 tiles wide, spikes spaced generously.

Falling: the ball can fall down any amount safely (no fall damage) as long as it lands on solid ground, not spikes. Good — drops are always safe.

Now let's design levels. I'll write them as string arrays in game.js, 16 rows each.

Let me define a helper for level building: I'll write rows explicitly. Being careful with widths.

I'll write them in chunks with a script to validate counts. Let me plan each level as segments of 16 wide (screens), so the camera reveals new screens.

Level 1: "Green Fields" — width 80 (5 screens). Theme: green/teal, flat ground with gentle learning.

Screen A (x 0-15): flat ground rows 14-15 solid, spawn at x=2 on ground, no hazards. Hoop at x=6 (row 12, floating 1.5 above ground, so at y=12? Ball resting center = 13.5; hoop at row 12 center y=12.5 — reachable by rolling? The ball's top = 13. So hoop at row 12 (center 12.5) overlaps ball top region... Overlap test: hoop as a small circle radius 0.3 at tile center; ball radius 0.5; ball top at 13.0 when grounded; hoop center at 12.5, distance 0.5 < 0.8 → collected while rolling. Good, so hoops at row 12 are collected by rolling; hoops at row 11 require a bounce.

Let me put hoops at heights requiring bounces sometimes: hoop at row 11 center y=11.5, distance from ball center at 13.5 = 2.0; ball at apex center 10.5 → distance 1.0 from hoop center (12.5? no 11.5): at apex center y=10.5, distance to (x,11.5) = 1.0 > 0.8. Hmm need to be careful with the collection radius. Let me define hoop collection radius = 0.45 tile around tile center, plus ball radius 0.5 → collect when distance < 0.95. At apex center y = 10.5 with hoop at row 11 (center 11.5): distance = 1.0 → not collected. Tight. Let me use hoop collect radius generous: dist < 1.05. Then apex at 1.0 distance collects. Better: I'll place hoops where the ball passes through, i.e. row 12 (rolling) or row 11 (bounce, and the ball passes through rows 11 and 12 during the bounce anyway, since a 3-tile bounce sweeps the center from 13.5 up to 10.5 — it always passes center y=11.5!). So hoop at row 11 is collected by any bounce over it. Hoops at row 10 (center 10.5): apex center exactly 10.5 → collected at apex only if x aligned exactly at apex → too tight. So: place hoops at most 2 tiles above the surface the ball is bouncing from (row ≤ 11 for surface row 13 top... let me recompute properly).

General: ball resting on surface with top edge at tile row T (i.e., occupies row T..? ) Let's say ground solid rows 14,15. Ball center = 13.5 when grounded (resting on row 14 top edge y=14). Bounce apex center = 10.5. So the ball's center covers y ∈ [10.5, 13.5]. A hoop at row 12 center 12.5 ✓, row 11 center 11.5 ✓, row 10 center 10.5 — only at apex, marginal, but if the ball is bouncing across that x-range over a wide range the apex occurs at exactly one x. With collect radius 0.95 and horizontal tolerance: at distance from apex, the center y rises... the ball's y as function of x near apex is flat, so a hoop at row 10 would be collected if |Δy| + ... dist = sqrt(dx² + dy²) < 0.95; near apex dy = 10.5 - 10.5 = 0 at exact apex, dy grows as (1/2)g t² = 11t², dx = 6t; need dy ≤ 0.95 → t ≤ 0.293 → dx ≤ 1.76 tiles. So a hoop at the apex row is collectible over a 3.5-tile-wide window. That's fine actually, not frame-perfect. But if the ball is moving slower, dx window smaller but still ~ 1 tile at speed 3. OK, tolerable. I'll still mostly put hoops at 1-2 tiles above the surface or in the natural arc.

Let me now design levels concretely, and then I'll write a validation script that:
1. parses maps, counts hoops/checkpoints/crystal/exit/pads/crumbles,
2. checks each level is 16 rows tall, all rows equal width,
3. checks spawn not in solid,
4. checks every floor gap is spiked (i.e., check bottom row is all solid? I'll design bottom row fully solid or spiked-filled).

And a reachability/simulation test: I could write a headless physics test in node that plays the level with a scripted input policy... That's ambitious. A simpler verification: run a "BFS/grid search" over a coarse simulation with input options to see if the exit is reachable. That could be a good check but complicated. Alternative: write a node script that simulates the ball with an autopilot heuristic... risky.

Better: write a node script that does a coarse search (like a "jump-and-run" search) using the actual physics module. If I structure game.js so the physics + level parsing can be required in node (guard the browser parts with `typeof document !== 'undefined'`), I can export via `module.exports` for testing. That's doable: at the end of game.js, `if (typeof module !== 'undefined') module.exports = {...}`.

Then a search: state = (x,y,vx,vy) discretized; actions: hold-left/hold-right/none + bounce held/not, applied per fixed step; search for a sequence reaching exit. That's a big search space but with pruning (coarse grid on x,y and vx,vy buckets, BFS with visited set, limited depth ~ 3000 steps) it may find a path. Given momentum physics, a BFS with hashing rounded states (x rounded to 0.5 tiles, y 0.5, vx 0.5, vy 0.5) and up to maybe 200k states could find paths. But hoops required to open the exit makes full-run search harder (need to visit all 6 hoops). I could search for reachability of each hoop/checkpoint/exit individually from spawn (ignoring the door-closed requirement by searching exit as "reach door tile"), which validates completability piecewise. And hoops are on the ground path mostly.

I think a targeted reachability test per key point is a strong verification. Let me plan to do that: for each level, run a BFS from spawn with action per-step ∈ {(-1,0),(0,0),(1,0)} × bounce held {0,1} = 6 actions, fixed dt = 1/120, and check reachability of: each hoop tile, each checkpoint, crystal, exit-door tile. Use discretization bucket size 0.25 tile for positions, and 0.5 for velocities, with a visited set; cap states. If BFS can't reach, I'll examine and adjust the level. This is a nice verification approach. Risk: BFS may be too slow / fail to find feasible paths due to discretization (momentum). Let me try it; if too slow, fall back to a coarse "can the ball traverse at all" simulation using a handcrafted autopilot per level (scripted inputs by x position) — also a decent check.

Given time constraints, let me first write the game well, then do verification. Keep levels forgiving by design (max step 2 tiles, gaps ≤3 tiles with spikes beneath and generous landings).

Let me write the code.

Structure of game.js:
- CONFIG constants
- LEVELS: array of {name, palette, rows:[...]}
- parseLevel(def) → {W,H,solid:Uint8Array (0 empty,1 solid,2 pad), spikes:Uint8Array (bitmask per tile of edges? simpler: spikes tile flag + hitbox rect inside tile), entities: hoops[], checkpoints[], crystal, exit tiles[], spawn}
  - Spikes: I'll support spike direction? Just floor spikes (pointing up) for simplicity. Lethal hitbox = inner region: for a floor spike tile, hitbox = rect from (x+0.15, y+0.35) to (x+0.85, y+1.0). Keep as tiles with hitbox defined relative. Maybe also allow ceiling spikes? Not needed. Keep floor spikes only.
- Ball state
- Input handling
- Physics step (fixed dt), collision
- Death/respawn
- Camera
- Rendering: canvas 2D, integer camera for crispness? Camera at fractional position; render at device pixels scaled — with crisp scaling: canvas is 128x128 logical, scaled via CSS transform with image-rendering pixelated. Drawing at fractional logical coordinates produces subpixel edges within the 128x128 buffer, which appears as shimmer when scaled up. To avoid jitter, round camera to logical pixel (integer px) each frame: camPx = Math.round(camTiles * 8). Since ball moves sub-pixel, rounding camera to whole px makes world move in 1px steps — no jitter, no shimmer. That's standard pixel-art camera. Good.
- HUD: DOM elements below canvas, or drawn on a separate canvas region below. Requirement: "single HUD bar fixed below the 128×128 world viewport so it never hides a map row". I'll draw HUD in a separate canvas (128x24 logical) below the world canvas in the same scaled container. Or DOM with pixel-styled text. DOM is easier for score text but fonts... "no external fonts" — use system monospace. A DOM HUD with monospace is fine and crisp. But pixel-crisp look: I'd rather draw HUD on a second canvas of 128x20 logical with a tiny bitmap font I define? That's extra work but nicer. Let's do a second canvas 128x24 logical scaled with the same CSS factor, and draw a small built-in 3x5 or 5x7 pixel font for digits. Digits only need 0-9 and level number, and "SCORE"/"HOOPS" labels? Spec: HUD contains only life ball icons, level number, hoops remaining, 8-digit score. I can use icons: ball icons (lives), "LV 1", hoop ring icon + number, and the score digits. To avoid ambiguity I'll include a tiny pixel font (5x5 digits + a few letters). Let me implement a compact 3x5 font for digits and a 5x7-ish for letters? Simpler: implement a 3x5 digit font (10 digits) and draw letters as small pixel glyphs via a 3x5 font for A-Z too? A 3x5 uppercase font is doable but fiddly.

Alternative: DOM HUD using monospace text with letter-spacing; it's crisp (text rendered at device scale) and easy. Requirement is only that it's fixed below the viewport with those items, aligned right score. I'll go DOM HUD: `<div id="hud">` with life icons as small canvases? Use CSS circles for ball icons (red dots). Level: "LEVEL 1". Hoops: ring icon (CSS circle with border) + "×3". Score: 8-digit monospace.

Let's do DOM HUD. It also avoids the font work. Good. But mixing DOM HUD with a scaled canvas: keep the container width = 512px (4×128). HUD bar 512 wide, ~48px tall, dark background, monospace.

Screens: title, level complete, game over, game complete as DOM overlays on top of the canvas area. That's fine ("title screen contains only...").

Scale: 128*4 = 512. Maybe 4.5? Use 4x = 512, and on smaller screens scale via CSS. Use CSS `--scale: 4` and width: calc(128px * 4). Add a resize handler computing scale from window size (integer scale preferred, min 2, max 5). Simple: compute scale = clamp(floor(min(vw, vh-80)/128), 2, 6)? Keep it simple with JS on resize.

Now let's write the physics carefully.

```js
const TILE = 8;
const FIXED_DT = 1/120;
const G = 22, MAX_FALL = 14, ACC = 18, MAX_ROLL = 6, FRICTION = 12, AIR = 0.4;
const REST = 0.35, BOUNCE_H = 3.0, PAD_H = 6.0;
const BOUNCE_V = Math.sqrt(2*G*BOUNCE_H); // 11.489
const PAD_V = Math.sqrt(2*G*PAD_H);
```

Ball: {x, y (center, in tiles), vx, vy, r=0.5, grounded}

step(dt):
1. read input: dir = -1/0/1, bounceHeld.
2. if grounded: if dir != 0: vx += dir*ACC*dt (clamp to ±MAX_ROLL); else: apply friction: vx -= sign(vx)*FRICTION*dt, clamp to 0 if sign flip.
   else (airborne): if dir != 0: vx += dir*ACC*AIR*dt, clamp to ±MAX_ROLL (clamp only when exceeding? if vx exceeds max from a pad... clamp anyway) . In air with no dir input: no friction (preserve momentum).
3. vy += G*dt; clamp to MAX_FALL.
4. Move X: x += vx*dt; resolve horizontal collisions.
   - After resolution, if collided while moving, vx = 0.
5. Move Y: y += vy*dt; resolve vertical collisions; detect landing (vy>0 and pushed up). On landing: check tile type: pad → vy = -PAD_V, squash; else if bounceHeld → vy = -BOUNCE_V; else vy = -vy*REST, if |vy| < 1.0 → vy = 0.
   - Also set grounded = true when vy resolved upward and no bounce? For the friction rule, treat grounded when resting (vy==0 and a tile below within epsilon). Let's compute `grounded` after vertical resolution: check if there's solid within 0.06 below ball bottom and vy >= 0.
   
   Ordering issue: friction applied at start of step based on grounded from last step — fine.
6. Crumble triggers on landing on crumble tile.
7. Spike check (circle vs spike hitboxes) → death.
8. Pickup checks: hoops, checkpoints, crystal, exit.
9. Clamp inside world bounds: if x < r → x = r, vx = 0 (shouldn't happen; edges are solid walls in maps anyway). If y > H + 2 → death? Every floor gap is spiked, and bottom row is solid, so no falling out. But as a safety: if y > H + 3, kill.

Vertical resolution with vy*dt at MAX_FALL=14 t/s and dt=1/120 → 0.116 tiles per step, less than a tile, so no tunnelling with a 1-tile ball. Good. Also cap dt steps to avoid spiral (max 8 steps per frame).

Collision resolution details:

```js
function tilesSolidRect(...) 
```
Implement:
```js
function collideX(b){
  const r = CR; // 0.48
  let x0 = b.x - r, x1 = b.x + r, y0 = b.y - r, y1 = b.y + r;
  const tx0 = Math.floor(x0), tx1 = Math.floor(x1 - 1e-9);
  const ty0 = Math.floor(y0 + 1e-9), ty1 = Math.floor(y1 - 1e-9);
  for (let ty=ty0; ty<=ty1; ty++){
    for (let tx=tx0; tx<=tx1; tx++){
      if (!isSolid(tx,ty)) continue;
      if (b.vx > 0){ b.x = tx - r - 1e-6; } else if (b.vx < 0){ b.x = tx+1 + r + 1e-6; }
      b.vx = 0;
      // recompute x range
    }
  }
}
```
Iterating with recomputation: better to loop until no overlap (max 3 iterations). Simplify: gather min push. I'll do: compute overlaps and take the closest resolution. Since ball ≤ ~1 tile, at most 2x2 tiles overlap. Implementation:

```js
function moveX(b, dx){
  b.x += dx;
  for (let iter=0; iter<3; iter++){
    let hit = false;
    const [tx0,tx1,ty0,ty1] = box(b);
    for (let ty=ty0; ty<=ty1 && !hit; ty++){
      for (let tx=tx0; tx<=tx1; tx++){
        if (!isSolid(tx,ty)) continue;
        hit = true;
        if (dx > 0) b.x = Math.min(b.x, tx - CR - EPS);
        else b.x = Math.max(b.x, tx+1 + CR + EPS);
        break; // take first solid in direction
      }
    }
    if (!hit) break;
    b.vx = 0;
  }
}
```
Hmm with dx>0 and multiple solid tiles, we want the minimum tx among overlapping ones. Let's compute properly:

```js
if (dx>0){ let best=Infinity; for each solid tile overlapping: best=Math.min(best,tx); if finite {b.x=best-CR-EPS; b.vx=0;} }
else { let best=-Infinity; ... b.x=best+1+CR+EPS }
```
And for y similar with landing detection. Also careful: EPS pushing may push the ball into another tile in tight spots but with CR=0.48 and 1-tile corridors there's slack.

Vertical:
```js
function moveY(b, dy){
  b.y += dy;
  if (dy>0){ // falling
     find solid tiles overlapping with ty = max row
     if found: b.y = tyMin - CR - EPS; landing...
  } else { ... }
}
```
Wait for falling, we want the topmost solid row among overlapping: b.y = ty - CR - EPS with ty = min row of solids overlapped. Yes.

Node available. Let me write the files.

Start with game.js core.

That core draft was messy (leftover `hitTx` scratch, OVERLAY placeholder, `held` with auto hook, missing rendering). I'm going to rewrite game.js cleanly and completely, with all 4 levels, rendering, HUD and flow. Let me first finalize level data, then write the whole file in 3 chunks.

Let me finalize the level grids (with the fixes I worked out). I'll write them as data in a separate `levels.js`? Spec allows splitting CSS/JS; extra file is fine but let me keep all in game.js to be safe... Actually "You may split CSS and JavaScript into style.css and game.js" — implies just those two. Keep everything in game.js.

Level grids (final, per my design):

L1 MEADOW (80 wide), screen 0 rows top→bottom (y0..y15):
```
0:  ................
1:  ................
2:  ................
3:  ........o.......
4:  ................
5:  ................
6:  .....##.....###.
7:  .....##o....###.
8:  ................
9:  ...........o....
10: ................
11: ..@....o...##.c.
12: .o............##
13: ............E###
14: ###############.
15: ###############.
```
screen 1:
```
0:  ................
1:  ................
2:  ................
3:  ................
4:  ................
5:  ................
6:  ....##..........
7:  ....##...o......
8:  ..........###...
9:  ................
10: ................
11: .o..........c.##
12: ####...o.......#
13: ####E..##.....##
14: #####^^######^^#
15: ################
```
Wait — I need to double check row 12: `####...o.......#` — that's 18 chars. Let me count: "####" 4 + "..." 3 =7 + "o" 1=8 + "......." 7 = 15 + "#" 1 = 16 ✓. OK good (I mis-counted).

And row 13 `####E..##.....##` = 4+1+2+2+5+2 = 16 ✓.
Row 11 `.o..........c.##` = 1+1+10+1+1+2 = 16 ✓.
Row 14 `#####^^######^^#` = 5+2+6+2+1 = 16 ✓.
Row 6 `....##..........` = 4+2+10 = 16 ✓.
Row 7 `....##...o......` = 4+2+3+1+6 = 16 ✓.
Row 8 `..........###...` = 10+3+3 = 16 ✓.

Hmm, one issue in screen 1: the step at row13 x8-9 and the block at row12 x15: to climb the x15 block (h=2 from row-14 surface) the player bounces. Fine.

But wait, in screen 1 row 12 x15 = '#' and row 13 x15='#'? I had plan: x15 columns solid at rows 12 and 13, resting on row 14. Row 13 = `####E..##.....##` → x13,14,15 = '#','','#'? positions: index 0-3 = '#', 4='E', 5,6='.', 7,8='#', 9-13='.....' , 14,15='##'. Yes x14,x15 are '#' at row 13. And row 12 x15='#'. Hmm but row 13 x14 is also solid → a 2-wide column top at row 12? No: row 12 x14 is '.' (row 12 is `####...o.......#`: index 0-3 '#', 4-6 '...', 7 'o', 8-14 '.......', 15 '#'). So the column is x15 only, top at row 12 (2 tiles: rows 12,13) ✓. But row 13 has x14 solid which is a lower step (top row 13, h=1). Fine.

Level 1 screen 2:
```
0:  ................
1:  ................
2:  ................
3:  ................
4:  ................
5:  ................
6:  ...........###..
7:  ..........o.....
8:  ...o............
9:  ................
10: ...........##...
11: ..............c.
12: ...###...o....##
13: #.........#####.
14: #^^####...######
15: ################
```
Check widths: row 6 `...........###..` = 11+3+2=16 ✓. Row 7 `..........o.....` = 10+1+5=16 ✓. Row 8 `...o............` = 3+1+12=16 ✓. Row 10 `...........##...` = 11+2+3=16 ✓. Row 11 `..............c.` = 14+1+1=16 ✓. Row 12 `...###...o....##` = 3+3+3+1+4+2=16 ✓. Row 13 `#.........#####.` = 1+9+5+1=16 ✓. Row 14 `#^^####...######` = 1+2+4+3+6=16 ✓. Row 15 16 ✓.

L1 screen 3:
```
0:  ................
1:  ................
2:  ................
3:  ................
4:  ................
5:  ..........###...
6:  ..........###...
7:  ...........o....
8:  ................
9:  .....##.........
10: .....##....o....
11: ..........###...
12: ...o..##......##
13: ..###.###..E####
14: #####^^^########
15: ################
```
Widths: row5 `..........###...` = 10+3+3=16 ✓. row7 `...........o....` = 11+1+4=16 ✓. row9 `.....##.........` = 5+2+9=16 ✓. row10 `.....##....o....` = 5+2+4+1+4=16 ✓. row11 `..........###...` = 16 ✓. row12 `...o..##......##` = 3+1+2+2+6+2=16 ✓. row13 `..###.###..E####` = 2+3+1+3+2+1+4=16 ✓. row14 `#####^^^########` = 5+3+8=16 ✓.

L2 FOUNDRY (80 wide):
screen 0:
```
0:  ................
1:  ................
2:  ................
3:  ................
4:  ................
5:  ................
6:  ................
7:  ................
8:  ................
9:  ................
10: ....o...........
11: ....##......o...
12: ..@.##..o...####
13: ......###...E###
14: ###############.
15: ###############.
```
widths: row10 `....o...........` = 4+1+11=16 ✓. row11 `....##......o...` = 4+2+6+1+3=16 ✓. row12 `..@.##..o...####` = 2+1+1+2+2+1+3+4=16 ✓. row13 `......###...E###` = 6+3+3+1+3=16 ✓.

Hmm — wait. The x12-15 block at rows 12-13 (top row 12, h=2) with the door at x12 rows 12-13 → the door sits ON TOP of that block, and the block's left face is climbable in 2 steps. But the player must climb h=2 to reach the top of x12-15... they need to get to the ledge. Let me re-plan: the pit is x11. The player bounces across and lands on x12-13 top (row 12, h=2). Wait, the block spans x12,13,14,15 at rows 12 AND 13. So climbing from row 14 (y=13.5 center) to row 12 top → h=2. Doable via a bounce. Or via a step up on x10-... The pit at x11: falling in it → row 14 spike? Row 14 is `###############.` all solid → safe 1-deep pit. Good, forgiving.

L2 screen 1:
```
0:  ................
1:  ................
2:  ................
3:  ................
4:  ................
5:  ............####
6:  ............####
7:  ............####
8:  ............####
9:  ..........==####
10: ............####
11: ....o.....====..
12: ............####
13: ...####.....####
14: ..######...#####
15: ..######...#####
```
Hmm wait, I need the pad top surface at row 12 for the critical route (plan: "pad x10-11 top surface row 12"). Let me re-derive screen 1 geometry from my plan:
- pit at x8, x9 (deep: floor at rows 14-15 → row 14 solid at x8,x9? My plan says "x8, x9 are pit (depth 2)" — the pit floor is row 14 top (i.e. rows 14,15 solid, no spikes).
- The main floor: x0-7 solid rows 13,14,15 → walking surface row 13 (y=12.5). And x10-15 solid rows 13,14,15 → surface row 13 (12.5).
- Pad column: x10,11 with pad tiles at row 12 → pad top surface row 12, i.e. y=11.5, h=1 above the x10-11 surface at 12.5.
- The big block: x12-15 solid rows 4..13 → top surface row 4, h=8.
- Route A (critical, 3 hoops here): from the pad (standing at 11.5), bounce to 8.5 apex; the ball's bottom at apex = 8.0 → can it land on a block with top surface at row 8 (bottom at y=8)? It needs center ≤ 7.5 (resting center = 8-0.5 = 7.5). Apex center = 8.5. NO! I conflated h=6 with reaching. From standing center y=11.5, apex center = 11.5 - 6 = 5.5, resting on surface row S needs center = S - 0.5, so S - 0.5 ≥ 5.5 → S ≤ 6. So from the pad at row-12 surface, reachable ledges have top row ≤ 6, i.e. height difference ≤ 6 tiles ✓ (surface 12.5 → 6.5, that's 6 tiles up; resting center 5.5 = apex exactly — too tight!). So max comfortable climb from a pad = 5 tiles.

OK so let me re-derive the "reachable ledge" rule properly in row terms: standing on surface with top row S (resting center = S - 0.5). After a bounce, apex center = S - 0.5 - 3. A ledge with top row L requires resting center L - 0.5 ≤ apex center → L ≤ S - 3 (exactly at apex → tight). Comfortable: L ≤ S - 2.

For pads: L ≤ S - 5 (comfortable), L = S-6 impossible-ish.

So my earlier "max ledge = 2 tiles above" == L ≤ S-2 ✓ consistent.

Now for level 2, the big block: I want the pad route to land ON the big block top. So pad top row S_pad = 12 (center 11.5) and big-block top row L must satisfy L ≤ 12-5 = 7. Let's set the big block top row = 7 (h from 12 → 5 ✓ comfortable). And from the ground surface (row 13, center 12.5), the big block top row 7 → h = 6 → unreachable from standing (need L ≥ 11) ✓ so the pad IS required. 

And the ledge route: from the main floor row 13 (12.5), a hop to ledge top row 11 (center 10.5, h=2 ✓), then the big block's left face at x12 from row 11 down; standing on row 11 surface (center 10.5), the big block top row 7 requires L ≤ 11-3 = 8 → 7 is exactly at the apex → too tight! Hmm. So the "ledges" route needs two steps: row 11 ledge → then another ledge row 9 → then the block top row 7. But from row 9 surface, L ≤ 9-3 = 6 < 7 ✓ so a 2-tall... wait L ≤ S-3 means "tight", L ≤ S-2 comfortable: from S=9, L=7 is exactly at the limit → tight/frame-perfect. So the big block top must be ≤ row 9-2 = 7 from a step at row 9. Hmm, so with two 2-tile steps the block top could be row 7 from S=9. So: ledge row 11 → ledge row 9 → block top row 7 would require each step ≤ 2 tiles ✓ (row 13 → 11 → 9 → 7). That's a staircase, which makes the pad route pointless — but that's fine, as long as the pad route exists and is the direct/intended one? No! The requirement: "Level 2 introduces bounce pads, with at least one on the critical path." If there's a staircase around it, the pad is not on the critical path.

So I need the big block to be climbable ONLY via the pad: block top row 7, and the wall from the ground (row 13) is 6 tiles → from standing max is 2. So no ledges at rows 11 and 9 near the block. Instead: the ledge route is at a different x and leads somewhere else.

Let me redesign Level 2 screen 1 with clean intent:
- Ground surface row 13 (x0-7 and x10-15 solid rows 13-15).
- Big block at x12..15, solid rows 6..13 → top surface row 6. From the pad surface row 12: L ≤ 12-5 = 7 → row 6 needs center 5.5 vs apex center 11.5-6 = 5.5 → exactly equal → too tight. Let's use pad top row 11 instead: standing center = 10.5, apex center = 4.5, so block top row L with L - 0.5 ≥ 4.5 → L ≥ 5, comfortable L ≥ 6. So pad surface row 11 (h=2 from the main floor row 13) — hmm, can the player get onto a pad whose top is at row 11 (2 tiles above the ground)? Yes: bounce from the ground, and land on the pad top (h=2 ✓ comfortable). Then a landing on the pad launches 6 tiles → apex center 10.5-6 = 4.5 → block top row 6 comfortable ✓ (block top surface row 6 = 5 tiles above pad surface). 

But careful: the ball approaching the pad's left face (pad occupies rows 11,12,13 = 3 tiles tall) — while bouncing along the ground the ball hits the pad's wall; it needs to climb onto it: bounce from ground (apex center 9.5, bottom 9.0) while adjacent to the pad column; the pad's top row is 11 → to land on top the ball's bottom must clear y=11 → center ≤ 10.5 ✓ apex center 9.5 clears. It needs horizontal movement into the top: after clearing the top edge, move right. Fine, standard.

Simplify the pad into the ground: put the pad as a 2-wide tile embedded in a 1-tall pedestal. Let me define concretely.

Screen 1 (x offset 16) FINAL:
- rows 13,14,15 solid at x0-7 (ground surface row 13); x8,x9 pit (rows 14,15 solid, so depth 1... let me make the pit floor row 14 → the ball falls to y=13.5; from the pit floor, a bounce reaches apex center 10.5, and climbing out to surface row 13 (L=13 ≤ S-2 where S=14 → L ≤12 → NO! from floor row 14 (S=14, center 13.5), a bounce apex center 10.5 → resting center needed for surface row 13 = 12.5 ≤ 10.5? Wait resting center for top row L is L-0.5; need L-0.5 ≥ apex center = 10.5 → L ≥ 11. So surface row 13 IS reachable (13 ≥ 11) with lots of margin. Hmm wait, that contradicts my earlier rule L ≤ S-2. Let me redo: standing on top row S (center S-0.5); apex center = S-0.5-3 = S-3.5. Landing on top row L: need resting center L-0.5 to be ≥ apex center? No! The ball can land on ledge L if its center reaches L-0.5 at some point: i.e. min center y over the flight = apex center = S - 3.5. It can reach y values ≥ apex center (y increases downward). It needs center ≤ ... ugh, signs. Ledge L is higher than S when L < S. The ball reaches its minimum y (highest point) = S-3.5. To be on ledge L, its center must equal L-0.5 at some moment → need L-0.5 ≥ S-3.5, i.e. L ≥ S-3. So a ledge 3 tiles higher (L = S-3) is exactly reachable at apex → tight; comfortable L = S-2. Consistent with before ✓.

For the pit floor at row 14 (S=14): out to surface L=13 → 13 ≥ 14-3 = 11 ✓ easily reachable (margin 2 tiles). Good. So any 1-tile-high ledge is easily climbed, and 3-tile-high is the tight max.

Hmm! Wait, that changes my earlier conclusion. Earlier I said max ledge = 2 tiles. And L ≥ S-3 means the ledge can be at most 3 tiles higher ✓ same thing. And "comfortable ≤ 2 tiles higher" ✓. Good, consistent.

So the pad (surface row 11, i.e. 2 tiles above ground row 13) → 6-tile launch: apex center = 10.5 - 6 = 4.5 → ledges with L ≥ 4.5+0.5 = 5 → so ledges at top row ≥ 5 reachable, comfortable at L ≥ 6. Big block top row 6 = 7 tiles above the pad? No: pad surface row 11, block top row 6 → 5 tiles higher ✓ comfortable.

FINAL screen 1 for L2:
```
row0:  ................
row1:  ................
row2:  ................
row3:  ................
row4:  ...............o     -- no, must be 16 wide, and be careful
```
Let me write the whole grid at once, 16 wide:

```
r0:  '................'
r1:  '................'
r2:  '................'
r3:  '.........o......'   hoop G at x9 row9? -> below
r4:  '.......######...'   big block top? 
```
Hmm, I keep flip-flopping. Let me carefully lay out screen 1 on paper.

Design intent for L2 screen 1 (x = 16..31):
- Ground surface: row 13 for x16..x23 (left part) and x26..x31 (right part). Pit at x24,x25 (floor row 14, safe).
- Big block: x28..x31 solid rows 6..13 → top surface row 6. Left face at x28.
- Pad pedestal: x24,x25? No, that's the pit. Put the pad column at x23? Hmm. Let me place the pad on the left ground so the launch takes the ball over the pit onto the big block:
  - pad top surface row 11 at x22,x23: pad tiles at rows 11 and 12 (2 tall) on top of ground rows 13-15 → the ball steps up? The pad's top is 2 above the ground (h=2 → reachable by a normal bounce ✓).
  - From standing on the pad (center 10.5), launch 6 → apex center 4.5; the big block top row 6 → resting center 5.5 ≥ 4.5 ✓, margin 1 tile. Horizontal: during the flight the ball must travel from x≈23 to x≥28-... it has to cross from the pad (x22-23) to the block top x28..31, i.e. ≥ 5 tiles. Air time for a full pad bounce = 2*22.978/22 = 2.089 s; at roll speed 6 → 12.5 tiles. At speed 3 → 6.3 tiles ✓. But there's a catch: the ball's trajectory rises 6 tiles; on the way up it must clear the block's left face? No — the ball goes up from the pad and comes down onto the block top. It must clear the block's left wall at x28 before its bottom goes below y=6 (the block top). The bottom at center y is y+0.5; the ball crosses x28 at center y; if at that moment its bottom is below 6 → collides with the wall at x28. So the ball must cross x28 (its right edge at x28 → center = 27.5) while center ≤ 5.5. And its resting center on top is 5.5. So the crossing happens right at the apex edge — meaning the ball must be near its apex when it crosses x27.5, i.e. its horizontal speed must be right. That's a speed-specific jump → forbidden ("no obstacle that has to be taken at exactly one speed").

Fix: move the pad closer to the block, or lower the block, or make the pad's launch arc comfortably clear the wall. Let's set the pad at x25,x26 (right edge of the pit? no...). Let me place the pad on the right side of the pit adjacent to the block: pad column at x26,x27 (2 wide), pad tiles rows 11,12, standing center 10.5. The block left face at x28. The ball must cross center x = 27.5 (right edge of ball at x28) with center ≤ 5.5, which happens from the apex... but the ball is standing at center x≈26.5 on the pad, and it needs to move right just 1 tile to reach x=27.5, at which point its center y must be ≤5.5 — at apex, yes (4.5). Time from launch to apex = v/g = 1.044 s. In 1.044 s at speed s, it travels 1.044s. To be at x ≥ 27.5 by apex → 1.044s ≥ 1 → s ≥ 0.96 t/s (i.e. barely moving). And it must not hit the wall... there's no wall to the right beyond x28 — the ball at center x=27.5 moving right rises; at x=28+ it's above the block? Its center y must be ≤ 5.5 for the bottom to clear the block top (y=6). If the ball has center y < 5.5 while at x ∈ [28, 31] it's above the block; then it descends onto the top ✓. If it moves fast (s=6) it travels 6*1.044 = 6.3 tiles by apex → x ≈ 32.8, past the block (which ends at x31) → it flies over the whole block and lands... where? Beyond x32 at a lower place. That could be off the level end or into a pit. So the block must be wide enough (or the pad placed so a fast ball lands on it). Let's make the block wide: x28..x35 top row 6 — hmm, screen 1 is only 16 wide.

Alternative cleaner approach: put the pad launch as a vertical boost along a wall with a wide landing plateau. i.e., the block is the whole right half of the screen: x24..x31 solid rows 6..13 (top row 6) — but then the pad at x22-23 top row 11 needs to launch the ball to a landing on top of x24: crossing x=24 (ball center 23.5) — the ball standing on the pad at center x=22.5..23 — right at the edge — needs center ≤ 5.5 which happens near apex. Time to apex 1.044s, needs to travel from x≈22 to 23.5 → 1.5 tiles → s ≥ 1.44 t/s. And the ball must not overshoot the plateau — it's 8 tiles wide, and at max speed 6 it travels 6.3 tiles by apex, landing further along the plateau; the plateau extends x24..31 (8 tiles) so it lands within it or possibly beyond at the far right end. Landing at apex + descent: it will land on top of the plateau somewhere between x=24 and x=24+12.5 = 36.5 (if full speed) — but the plateau ends at 31, so at full speed it flies off the right end of the plateau. Then it continues to screen 2 at a high altitude. That's fine if screen 2 continues at a similar altitude — actually that's the *point*: the level rises in altitude as it progresses (like level 3's design). Let's do that: screen 1's plateau top row 6 continues into screen 2 at the same altitude. Then speed doesn't matter: a slow ball lands on the plateau; a fast ball lands further along the plateau or continues onto screen 2's high road.

This is much more robust. So: the design principle → make high routes wide/continuous, and where the ball must arrive at a specific spot, provide generous width.

OK, let me now design all levels with this principle: continuous plateaus at altitudes, generous widths, hazards spaced out, and short ledges only over safe floors.

Let me redo Level 2 fully as one 80-wide grid, thinking about it as a continuous side view. Altitudes (top row numbers) per x.

I'll define columns:
x: 0-3 ground row 13 (spawn x2)
x 4-7 ground row 13
x 8-9: pit (floor row 14), a small dip with hoop; easy out
x 10-12: ground row 13, hoop 'o' row 12, checkpoint 'c' row 12 at x11? Let's keep flat & gentle for the first screen (teaching pads? no, pads are on the critical path at screen 1 per "introduces bounce pads" — put a *free* pad early on the ground (non-critical) to teach, then the critical pad).

Let me write out L2 grid screen by screen, top→bottom, being explicit about surfaces.

SCREEN 0 (x0-15): ground row 13, flat; a teaching pad embedded in the ground (top row 13, i.e., pad tile at row 13 x6,x7) — stepping onto it launches 6 tiles, landing back on the ground (safe, wide open). Hoops: 'o' row 12 at x3, 'o' row 11 at x10 (bounce). Crystal: 'o' at x13 row 10 on a small pedestal (row 10,11 block x13-14 → top row 10, h=3 hmm 3 is tight; use a 2-high pedestal → top row 11, and the crystal at row 10 above it → collected during a bounce ✓). Checkpoint 'c' at x14 row 12. Door at x14? Let's keep the door at x14 rows 12-13 (on the ground level). Wait, ground surface is row 13 → the door must sit ON the ground: door tiles rows 11-12? No — if the walking surface is row 13 (tiles at rows 13,14,15 solid), a door standing on it occupies rows 12 and 11? The bottom tile of the door = row 12 (resting on row 13) and top = row 11. Hmm! I previously used row-14 ground with the door marker at row 13 (bottom) and row 12 (top) ✓ = the two tiles immediately above the ground surface. So rule: door marker 'E' at the tile just above the surface, plus the tile above that (must be clear). So with surface row 13, the marker goes at row 12 and the tile above (row 11) must be empty.

OK. In L1 all surfaces were row 14 (solid rows 14,15) so doors were at row 13 ✓.

Let me now write L2.

SCREEN 0 (x 0-15), ground rows 13,14,15 solid:
```
r0:  ................
r1:  ................
r2:  ................
r3:  ................
r4:  ................
r5:  ................
r6:  ................
r7:  ................
r8:  ................
r9:  ...........o....   (hoop C at x11 r9 — reachable? standing 12.5, apex 9.5 → needs center ≤ 9.5; hoop center 9.5 → only at apex. Let's move to r10 → center 10.5 ✓ comfortable)
r10: ...........o....
r11: ....==.......c..   teaching pad? no wait pad tiles need to be solid with top surface; pad at rows 11,12 x4,x5 → surface row 11
r12: ..@.o....o...###   hmm door
r13: ################
r14: ################  -- too many rows
```
I keep messing up. Let me be systematic. Ground = rows 13,14,15 solid (surface row 13). Objects placed at rows ≤ 12.

r0..r8 mostly empty.

Screen 0 plan:
- spawn '@' at x2 r12 (the ball rests on row 13 ✓ since '@' at r12 means center 12.5 ✓).
- pad teaching: '=' tiles at x6,x7 in r13 (embedded in the ground surface, so their top surface is row 13 = the ground surface). Walking/rolling along the ground onto the pad → each landing launches 6 tiles ✓ teaching, harmless (landings are flat ground).
- 'o' x4 r12 (roll), 'o' x10 r11 (bounce), 'o' x13 r11? Need 3 here.
- 'c' x14 r12 → but the door needs x14 r11+r12... conflict. Put the door at x14 r12(marker)+r11, and the checkpoint 'c' at x12 r12.

Screen 0 rows (16 wide), with ground rows 13,14,15 = '#', pad '=' at r13 x6,x7:

r0:  '................'
r1:  '................'
r2:  '................'
r3:  '................'
r4:  '................'
r5:  '................'
r6:  '................'
r7:  '................'
r8:  '............##..'   (small pedestal x12,x13 rows 8-9? no — leave empty)
r9:  '................'
r10: '....o.......o...'
r11: '....##.......###'   -- hmm the '###' at r11 x13-15 would be a wall blocking the door.

Simplify! The door at x14 with r11,r12 clear. So screen 0 right side must be clear of solids at x13-15 rows 11,12. Let's put nothing there.

r12: '..@.o...o.....E###'  → door marker 'E' at x14 r12; then '#' at x15 r12? That would be adjacent to the door — the door's top tile is x14 r11; a solid at x15 r12 doesn't block the door. But the walking surface is row 13, so a solid at x15 r12 = a 1-tall step. Hmm, fine, but let's keep it clean: r12 = '..@.o...o.....E...' and r13 = '#####==#########'? Then the level continues to screen 1 at the same altitude.

Wait, but the ground at r13 x15 = '#' and screen 1 r13 x15 = '#' continues ✓.

Screen 0 (FINAL):
```
r0:

Rather than this limited validator, the real verification is a search-based solver using the actual physics. Let me restructure: put the level data and physics in game.js with a node-export hook, then write a solver in tools/solve.js that imports game.js.

So: first, let me write game.js properly with all 4 levels. To do that I need the level maps finalized... but I can iterate: write the maps, run the solver, adjust.

Let me write the full game.js now with the L1 maps and draft L2-L4 maps (from my paper design), then iterate with the solver.

Let me write the level maps into game.js as data arrays. I'll now carefully write out L2, L3, L4 grids.

=== LEVEL 2 : FOUNDRY (80 wide) ===
Screen 0 (x0-15): flat ground rows 13,14,15; pad tiles at row 13 x6,x7 (teaching pad, embedded).
r0-r9 empty.
r10: '....o...........'  hoop x4
r11: '..........o.....'  hoop x10
r12: '..@.......o...E.'  spawn x2, hoop x10? conflict with r11 hoop at x10 - fine, different rows. Let's do: spawn x2, hoop x12 r12, door x14 r12.
r13: '######==########'  (ground with pads at x6,x7)
r14: '################'
r15: '################'

Hmm, but there are 3 hoops here and it's totally flat & trivial. Let me add a couple of blocks for shape: a block at rows 11-12 x9? Then the hoop at r11 x10 conflicts. Let me place: a 2-tall block at rows 11,12 x3 (so the player must bounce over/onto) hmm spawn x2 is right next to it. Let's do: spawn x2; block x5,x6 rows 12 (1-tall step) — hmm, the pad is at r13 x6,x7.

Let me restructure screen 0: 
- ground rows 13-15 solid everywhere.
- pads '=' at r13 x5,x6 (embedded in ground: tiles at r13 are part of the ground; their top surface = row 13, same as the ground). ✓
- Step block: x9,x10 rows 11,12,13? If it's at rows 11-12 sitting on the ground, its top surface = row 11 (2 tiles above ground) → climbable ✓; the ball must climb it or... it's a wall otherwise: from the ground, its left face is 2 tiles tall → the player bounces (apex 9.5) and lands on top (resting 10.5) ✓.
- Hoop above the step block top: 'o' at r10 x9 → resting on the block top = center 10.5; hoop center 10.5 ✓ collected when standing on the block.
- Hoop 'o' r12 x2 (roll).
- Hoop 'o' r11 x13 (bounce).
- Checkpoint 'c' r12 x12.
- Door 'E' r12 x14.
- Spikes: none in screen 0? Level 2 should have some spikes. Put a 1-tile spike pit: hmm, with the ground at r13, a spike pit = spikes at r13 with the floor at r14: i.e. r13 x11 = '^' (a single spike in the ground surface) — the ball must step over it: 1 tile wide, easy to hop. Hmm, but the ground surface tiles at r13 x11 = '^' means r13 is not solid there → the ball falls to r14 (1-deep). Let's make spikes at r12 above solid r13? No, spikes sit on the surface: a spike tile at r13 with solid r14,r15 below → wait, if r13 x11 is a spike (not solid), the ball rolls along the surface r13 (resting on r14 top) ... hmm no: ground solid rows 13,14,15 means the walking surface is at the top of row 13 (y=13). If x11's r13 tile becomes a spike, the ball at x11 walks on... nothing; it falls to the r14 surface? The tiles at r14 x11 are solid → surface = top of row 14 (y=14) → a 1-deep pit containing a spike at r13? No: the spike tile at r13 is now the pit's wall space. Confusing.

Cleaner: the walking floor = rows 14,15 solid (surface y=14, resting center 13.5) — like level 1 — and spikes replace tiles in row 13 sitting ON the floor (the spike's own tile is r13, resting on r14) ✓. That's exactly how L1 works: '^' at row 14 in L1... wait, in L1 I put spikes at row 14, which is within the solid rows. Let me re-check L1 screen 0 r14: `###############.` and r13: `............E###`. The spikes in L1 screen 1 are at row 14: `#####^^######^^#` — the spikes REPLACE solid tiles at row 14. So the walking surface at those columns is the top of row 14 (y=14) — the ball's center is 13.5, bottom 13.0, spike hitbox top = 14 + 0.40 = 14.4. Wait that means a ball rolling along at center 13.5 has its bottom at 13.0, and the spike hitbox spans y 14.4..15.0 — the ball never touches it! Because the ball's bottom is at 13.0 and the spike hitbox starts at y=14.4. Hmm! That's wrong: the spike tile at row 14 sits BELOW the surface.

I need to fix my L1 maps: spikes must be in the row just ABOVE the walking surface. In L1 the walking surface (top of solid rows 14,15) is y=14, resting center 13.5, bottom 13.0. A spike sitting on the floor occupies row 13 (the tile above the floor). So spike tiles should be at row 13, not row 14!

Hmm, wait. If a spike occupies row 13 and the ball rolls along row-14-floor... it can't, the spike blocks it: the spike tile is not solid, so the ball rolls INTO the spike tile → its bottom at 13.0 and the spike hitbox from y = 13+0.40 = 13.4 to 14.0. Ball bottom 13.0 vs hitbox top 13.4 → no contact?! The spike hitbox is at the BOTTOM of the tile: y from tile+0.40 to tile+1.0 → for tile row 13: 13.4..14.0. The ball rolling on the floor at center 13.5 → its center is at 13.5, which is INSIDE the hitbox y-range 13.4..14.0 → collision ✓ (nearest point distance small). Good.

So a spike at tile row T with a floor whose top surface is at y = T+1 (i.e. solid rows T+1...): the ball rolling on that floor has center y = T+0.5, and the spike hitbox spans y ∈ [T+0.4, T+1.0] → the ball's center is inside → lethal ✓. And a ball landing/standing next to it is safe.

So: with my SPIKE_BOX y offset 0.40 and height 0.60, the spike's lethal region is the lower part of its tile — that's for spikes sitting ON a floor. Good, and the x inset 0.14 gives 1.1 px at each side.

So in L1 I must place spikes in row 13 (above the floor rows 14,15) — but that's where I put the door markers and hoops, fine, different columns.

Wait, but I also designed pits with floors. Let me re-express: "spike pit" = the ground row (the solid surface row) is replaced by spikes? No: a spike pit = a hole in the floor rows with a spike on the pit floor. E.g. floor rows 14,15 solid; at pit columns x, rows 14 is a spike sitting on row-15 solid → the pit floor top = y=15, the spike tile at row 14, its hitbox y ∈ [14.4, 15.0], ball falling in has center passing through → lethal ✓. That's what I originally drew in L1 (`#####^^######^^#` at row 14 with row 15 solid) ✓ — the spike is at the pit floor level, lethal to anything falling in.

But then a ball that lands on the pit floor next to the spike (a 1-wide spike in a 3-wide pit) — hmm, if the spike occupies the whole pit floor width, falling in = death.

Now, my "spike pit 3 wide, pit floor row 15" phrasing: floor rows 14,15 solid normally; for the pit, remove row 14 solid and place spikes at row 14 (resting on row 15). So in the map: row 14 = '^' at those columns, row 15 = '#'. ✓ That's what I drew in L1.

And the ball rolling along the normal surface (y=14, center 13.5) approaching a spike at row 14 (not solid): it falls into the pit and dies. ✓ Fine.

Now, the "leave room" requirement: a spike in a pit 3 wide is a hazard over 3 tiles — the player must bounce over it. Time to react: the ball falls at up to 14 t/s but starting at 0 → falls 1 tile in ~0.3 s. Hmm, the pit depth: the surface at y=14, the pit floor at y=15 (1 tile deep). Falling into a 3-wide pit at speed 6 takes 0.5 s to cross; the ball drops 0.5*22*0.25 = 2.75 tiles in that time, way more than 1 → death. So the player must bounce BEFORE the pit. They see the pit; must launch before the edge. Landing must be on the far side. With a full bounce at speed 6: 6.27 tiles. ✓ Comfortable at speed ≤ 3.

So the constraint is that spikes are only ever encountered as pit floors (death if you fall in) or as surface spikes on ledges. That's fine, and the level design must make them easy to clear.

But "several clear tiles between spikes and after every landing" — I'll space spike pits with ≥3 clear tiles of normal floor between them ✓ as designed.

Hmm, wait: one problem in L1 screen 1, the door at x16 r13 and spikes at r14 x6,7 — the door is at surface level ✓ (door bottom tile at r13, resting on the r14 floor) ✓.

OK. Another check: in L1 screen 1, I had plan rows:
```
r12: ####...o.......#
r13: ####E..##.....##
r14: #####^^######^^#
r15: ################
```
The door 'E' at x4 r13 sits on the r14 floor ✓, top tile x4 r12 = '#'?? r12 = `####...o.......#` → x0-3 = '#', x4 = '.', good (x4 is clear at r12) ✓. Wait: x0,1,2,3 = '#' then x4='.'? "####" occupies x0-x3 ✓, then x4,x5,x6 = '...', x7='o' ✓. 

Hmm, but this is screen 1 so x offset 16: door at x=20, r13. And the r12 x0-3 = '#' = a solid block at x16-19 rows 12 sitting... on what? r13 x0-3 = '####' solid, so rows 12,13,14,15 solid at x16-19 → that's a raised area with surface row 12, and the door at x20 r13 is on the lower floor (surface row 14). Hmm, that means the raised area at x16-19 has surface y=12 while the door at x20 is on surface y=14. And the door faces left, blocked? No, the door's front is open at x20. But the player arriving from x16-19 (high) would drop to the door area. That's backwards from what I planned (I planned the door at the end of a climb in the previous screen). Actually the door is on the LEFT edge of screen 1 at x20, and the previous screen's exit was x14? Hmm — the L1 screen 0 door was at x=14 r13 with the surface at row 14; the player walks right to x=15 (r13 x15 = '.' in screen 0 → the ground at x15 r14 = '.'! Screen 0 r14 = `###############.` → x15 is empty → the surface at x15 is row 15. And screen 1 x16 r14 = '#' (r14 = `#####^^######^^#` → x0='#') ✓. So x15 has floor at row 15 (surface y=15) — the ball descends 1 tile from x14 to x15 and then... x16 r14 solid → the surface rises to y=14 → a 1-tile step up ✓ fine.

But the door at x20 (screen1 x4) r13: the player must arrive at ground level (surface y=14) at x20 from the left (x19 = solid rows 12-15, surface y=12) — so they'd have to climb DOWN into the door. The door is at the bottom of a step. Fine — but wait, that means the player can reach the door EARLY by just walking right from screen 0! Because x15-x20 at surface level is accessible at the start.

Oh no — the door in screen 1 x4 is right at the start of screen 1, which is reachable at level start. That's fine actually (the door is closed until all 6 hoops are collected; the player must return/roam). Hmm, but is it fine? The exit is at x20 but the remaining 5 hoops are at x>20? Let's check the hoop list for the updated L1: screen 0 hoops (1,12),(6,7),(9,9),(11,3),(13,7) = 5; screen 1 hoops: (23,12)?? Let me recount from my map rows: screen 1 r7 'o' at x8+16=24, r12 'o' at x7+16=23 → 2 hoops in screen 1; screen 2: r8 'o' x3+32=35, r12 'o' x9+32=41 → 2; screen 3: r7 x11+48=59, r10 x9+48=57 → 2. Total = 5+2+2+2 = 11. So my "5 in screen 0" is wrong — it's 5,2,2,2. Ugh, and I wanted 3,3,4,6... whatever. The distribution doesn't matter much; what matters: the exit must be reachable only after collecting hoops that require going right past it? No — the exit can be anywhere; the player collects all 6 hoops then enters the door. If the door is at x20 and hoops are at x23,24,35,41,57,59, they must pass through the door area (x20) while it's closed — the door is only 2 tiles tall and occupies x20; is it impassable? Yes, when closed the door tiles are SOLID, so the player must climb over the raised block at x16-19? Hmm, the door at x20 r13,r12 is a 2-tall solid wall blocking the corridor at ground level. To pass, they'd climb it (the door's top at y=12, standing on surface y=14 → 2 tiles above → climbable by bouncing on top of the closed door ✓ nice — that works, the player can bounce on top of the closed door and continue right).

That's acceptable but let me redesign L1's geography to be cleaner: the exit door should be at the far right of the level (x78-ish) so the level reads left→right, with all 6 hoops before it. That's much better design. Let me redo L1: put the door at the end (x78) and let the player traverse the whole level.

Hmm, but my earlier L1 draft had a door at the end of each screen, which was a mistake (only one door per level!). Let me restructure all four levels as left→right runs ending with the exit door at the far right.

Let me now redo all four level maps properly with a single door at the end.

=== LEVEL 1 : MEADOW (80 wide) ===
Theme: rolling green. Gentle. Altitude mostly row-14 floor (surface y=14) with mild variation.

I'll write screens as before but keep the corridor flowing.

Screen 0 (x0-15):
```
r0:  ................
r1:  ................
r2:  ................
r3:  ........o.......     hoop B (x8,y3)
r4:  ................
r5:  ................
r6:  .....##.....###.     pillar x5-6 (rows 6-7); block x12-14 rows 6-7
r7:  .....##o....###.     hoop C (x8,y7)
r8:  ................
r9:  ................
r10: ................
r11: ...........o....     hoop E (x11,y11)
r12: ..@....o...##.c.     spawn x2; hoop A (x7,y12); step x12-13 rows 12-13; checkpoint (x14,y12)
r13: .o............##     hoop D (x1,y13)... 
```
Hmm wait, a hoop at (1,13) — the ball starts at x2 on surface y=14 → center 13.5; the hoop at (1,13) center 13.5 ✓ collected rolling left.

r13 x1 = 'o' and x14,x15 = '##'. And the checkpoint at (14,12) sits on the step (x12-13 rows 12-13) — no, if x12,x13 are solid at rows 12,13 then their top surface is y=12; the checkpoint at x14 r12 needs a floor at (14,13) → r13 x14,x15 = '#' ✓ so x14 also has solid at r13 → top surface y=13, and the checkpoint center (14.5,12.5) is 1 above that surface ✓.

r14: `###############.` (x0-14 solid; x15 hole)
r15: `################`

Hmm at x15, r14 empty, r15 solid → surface y=15 there; and screen 1 x16 r14 solid → 1-tile step. OK.

Let me simplify and make row 14 fully solid in screen 0 and put the transition elsewhere. Actually a 1-tile step down/up between screens is invisible to gameplay. Let me keep r14 fully solid at x0..15 in screen 0 to avoid weirdness:
r14: `################`
r15: `################`
and screen 1 also starts with the same.

Now the whole level 1 has surface y=14 in screen 0.

Screen 1 (x16-31): hazards begin.
```
r0-r5: empty
r6:  ................
r7:  ................
r8:  ..........###...      block x26-28 rows 8-9? (surface y=8)
r9:  ..........###...
r10: ................
r11: .o..........c...      hoop (x17,y11)
r12: ................
r13: .......o........      hoop (x23,y13)? center 13.5 → rolling ✓
r14: #####^^#####^^##      spike pits x5-6 (rel. 5,6 → abs 21,22) and x12-13 (abs 28,29)
r15: ################
```
Hmm, wait: spikes at r14 (replacing floor) → the pit floor is row 15 (surface y=15) with spikes at r14 whose hitbox is y ∈ [14.4,15.0]. A ball rolling along surface y=14 (center 13.5) into x21: nothing solid → falls; at center 14.0 the ball's bottom is 14.5 → hmm, the spike test: ball center (21.5, 14.2) vs hitbox (x 21.14..21.86... wait the spike at tile (21,14): hitbox x ∈ [21.14, 21.86], y ∈ [14.4, 15.0]. Ball center passing at (21.5, 14.2): nearest point (21.5, 14.4) → distance 0.2 < CR ✓ lethal.

OK. But hold on: if the spike tile at (21,14) is not solid, and (21,15) is solid, then the ball could land on the floor at (21,15) surface y=15 → resting center 14.5 → that's inside the spike hitbox (y 14.4..15.0) → dead. Yes, falling in = death ✓ intended.

Let me make spike pits wider = the hazard: 2-3 tiles wide. And the ball must clear them. To clear a 2-wide pit with a full bounce is easy.

For level 1's gentleness, let me use 2-wide pits with 4+ tiles of clear floor on each side.

Screen 1 layout (16 wide), surface row 14:
- r14: x0..4 '#', x5,6 '^', x7..11 '#', x12,13 '^', x14,15 '#' → `#####^^#####^^##` = 5+2+5+2+2 = 16 ✓
- A block at x10,x11 rows 11,12? Hmm, I want a mid-level ledge with a hoop. Let me add: block x8,x9 rows 10,11,12,13 → surface y=10, reachable? From surface y=14 → 4 tiles up → too high for one bounce (max 3, comfortable 2). Hmm! Careful: ledge heights must be ≤ 2 above the immediate launch surface, or reachable via a 2-tile staircase.

Given L1 has no pads, all climbs must be staircase steps ≤ 2. Let me design L1's vertical bits as staircases: e.g. a step at y=12 (h=2) then a ledge at y=10 (h=2 from the step) ✓.

Screen 1 features:
- spike pit A: r14 x5,6 (abs 21,22) with clear floor x0-4 and x7-11 ✓ (4 clear tiles each side).
- staircase: block at x9,x10 rows 12,13 (surface y=12, h=2 from y=14) ✓; then block x11? To reach a ledge at y=10 we need a step at y=12 near it.
- Let me place: block x9-10 rows 12,13 (surface 12); block x12-14 rows 10,11,12,13 (surface 10) — from the x9-10 surface (y=12) to x12-14 surface (y=10) is a 2-tile step ✓, but there's a gap at x11 (surface y=14 there) — the ball jumps from the step (x10, standing center 11.5) right onto the y=10 ledge (resting center 9.5): needs rise 2 and horizontal 1.5 tiles. During a full bounce, at 0.38 s it has risen 1.98 and travelled ≥ 0.57 tiles (if it accelerates from 0, more realistically 1-2 tiles) ✓. Feasible. But risky if the ball is moving fast → it sails over the ledge (fine, it lands further right).
- Then spike pit B at r14 x... hmm the block at x12-14 occupies r14? Let me define the pit at r14 x12,13 with the block above? No, a solid column must be continuous.

I'll write the level as a height-map mental model. Let me be very concrete and simple for L1: a mostly-flat level with 2-tile steps, 2 spike pits of 2 tiles each, 3 spike pits of 3 tiles in screen 3, and small ledges reachable by staircases. All objects at rows 12-13 (reachable by rolling/short bounce) plus ledges at y=10 and y=8 reached via steps.

I'm going to simplify my approach: define each level's ground as rows 14,15 = solid except at spike pits, and add structures. I'll write the grids now in the final form and validate with the solver.

=== L1 MEADOW (80 wide, 5 screens) ===
Screen 0 — learning, no hazard:
```
0:  ................
1:  ................
2:  ................
3:  ........o.......
4:  ................
5:  ................
6:  ................
7:  ................
8:  .....##.........
9:  .....##.........
10: ................
11: ...........o....
12: ..@....o...##.c.
13: .o............##
14: ################
15: ################
```
Hmm, the pillar x5-6 rows 8-9: its surface y=8; reachable? From y=10? nothing at y=10. It's decorative (unreachable) — but a hoop at (3,12)? Let me instead: the hoop at (8,3) requires climbing the pillar x5-6 (rows 6,7) then a bounce. With nothing else, the pillar x5-6 rows 6,7 = surface y=6 → unreachable (would need steps). So make the pillar taller and reachable by staircase: 
- step1: block x4-5 rows 12,13 (surface y=12)
- step2: block x6-7 rows 10,11,12,13 (surface y=10)
- step3: block x8-9 rows 8,9,10,11,12,13 (surface y=8)
- hoop at (10,7)? From step3 surface y=8 (center 7.5): bounce apex center 4.5 → the ball can land on ledges with surface ≥ 6. Hoop at (10,6) center 6.5: needs center ≤ 6.5, reachable ✓.
Hmm, but the staircase is a big climb for L1 screen 0. Actually a staircase is a nice gentle teaching structure: each step is 2 tiles → bounce, bounce, bounce. And the hoop at the top rewards.

But wait: at x8-9 top surface y=8 and x10 empty down to y=14 — the ball bounces from the top of x8-9 (center 7.5) and can reach a ledge surface ≥ 6 (resting center ≥ 5.5)... For the hoop at (10,6) center 6.5: the ball's center passes through 6.5 during a bounce ✓ (from 7.5 to 4.5). Distance |dy| = 0 at that moment, dx small ✓ collected.

Then the player continues right and drops to the ground.

Screen 0 (final):
```
r0:  ................
r1:  ................
r2:  ................
r3:  ................
r4:  ................
r5:  ................
r6:  ..........o.....     hoop (x10,y6) — requires the staircase
r7:  ................
r8:  ........###...      block x8-10 rows 8-13 (surface y=8)
r9:  ........###
r10: ......###...        block x6-8? conflict...
```
Careful: staircase blocks must be non-overlapping columns. Let me use columns:
- x4,x5: solid rows 12,13,14,15 → surface y=12
- x6,x7: solid rows 10,11,12,13,14,15 → surface y=10
- x8,x9: solid rows 8..15 → surface y=8
- x10..15: rows 14,15 → surface y=14
So:
r8:  `........##......`  (x8,9)
r9:  `........##......`
r10: `......##....o...`  (x6,7) + hoop at x12,y10 (needs a bounce from ground: center 10.5 vs standing 13.5 ✓ apex 10.5, only at apex. Move to r11.)
r11: `......##......o.`? Let's place the checkpoint.

Let me write it out completely:

L1 screen 0 rows (y=0..15):
```
y0 : ................
y1 : ................
y2 : ................
y3 : ..........o.....      hoop (10,3)?? 
```
Ugh, the hoop at y=6 above the x8-9 block (surface y=8): center (10.5,6.5) — but wait the block x8-9's top surface is y=8 and the ball standing on it has center (x, 7.5). The hoop at tile (10,6) center (10.5, 6.5): the ball standing on the block at x=9.5 has center (9.5,7.5); distance to (10.5,6.5) = sqrt(2) = 1.41 > 1.02 → not collected while standing. Bouncing from the block: apex center y = 4.5, so its center passes 6.5 at t where 7.5 - 11t + 11t² = 6.5 → 11t²-11t+1 = 0 → t=0.112 or 0.888 s; x at t=0.112 with v=1 → 10.6 (hoop x 10.5) ✓ collected. 

I'd rather place the reward hoop right above the block top so it's collectible from a bounce off the block: hoop at (8,6) center (8.5, 6.5): the ball standing at center (8.5,7.5) — bouncing up passes 6.5 immediately ✓ collected nearly in place. Good: hoop at (8,6) or (9,6).

OK, writing final L1 screen 0:
```
y0 : ................
y1 : ................
y2 : ................
y3 : ................
y4 : ................
y5 : ................
y6 : ........o.......      hoop (8,6)
y7 : ................
y8 : ........##......      x8,9 solid
y9 : ........##......
y10: ......##........      x6,7 solid
y11: ......##....o...      hoop (12,11)
y12: ..@.##......c...      spawn (2,12); x4,5 solid; checkpoint (12,12)
y13: .o..##....##...       hmm x12,13 solid rows 13?
```
The checkpoint at (12,12) needs a floor at (12,13) → put x12,13 solid at row 13 → surface y=13 (1 above the ground y=14) ✓.
```
y13: .o..##....##...#      -- getting messy
```
Let me simplify by dropping the x12-13 step: put the checkpoint at (13,13) directly on the ground (floor at (13,14) ✓ solid) with center (13.5,13.5): the ball rolling at center 13.5 → distance 0 ✓ collected while rolling ✓ perfect for L1's first checkpoint.

FINAL L1 screen 0:
```
y0 : '................'
y1 : '................'
y2 : '................'
y3 : '................'
y4 : '................'
y5 : '................'
y6 : '........o.......'
y7 : '................'
y8 : '........##......'
y9 : '........##......'
y10: '......##........'
y11: '......##....o...'
y12: '..@.##..........'
y13: '.o..............'
y14: '################'
y15: '################'
```
Objects: spawn (2,12); hoop A (1,13); hoop B (8,6); hoop C (12,11); checkpoint CP1 (13,13)? 

Hmm, I need CP1 to be "in front of" the level's hardest stretch (which

Now I need to fill in levels 2, 3, 4 maps. Let me write them as arrays via a helper script so I can compose rows. But actually let me hand-write them into game.js.

L2 FOUNDRY (80 wide, 5 screens). Let me lay out per screen with the design I made.

Screen 0 (x0-15): ground rows 14,15 solid → surface y=14. Teaching pad embedded at row 13 x5,x6 (the pad tile's top surface is y=13?? No: a pad tile at row 13 means the pad occupies the tile row 13 and its top surface is y=13; but the ground surface is y=14, so the pad tile sticks up 1 tile above the ground — a 1-tall pedestal. The ball rolling on the ground (center 13.5, bottom 13.0) hits the pad tile's left face (spanning y 13..14): overlap → stops. Then bouncing (apex center 10.5) → then descends onto the pad top (center 12.5) ✓ then launches 6 tiles → apex center 6.5 ✓ lands on the ground. Teaching ✓. Good: '=' at r13 x5,x6.

Screen 0 objects: spawn (2,13); hoops: (4,13) rolling, (9,12) bounce [center 12.5, reachable: standing center 13.5 → apex 10.5 ✓], (13,11)? center 11.5 needs center ≤ 11.5 (standing 13.5, apex 10.5) ✓.
Checkpoint: CP1 at (14,13)? Then r14,r15 solid ✓ center (14.5,13.5) ✓ rolling.
Spikes: none in screen 0 (safe opening).

Screen 0 rows:
```
y0:  ................
y1:  ................
y2:  ................
y3:  ................
y4:  ................
y5:  ................
y6:  ................
y7:  ................
y8:  ................
y9:  ................
y10: ............o...      hoop (12,10)
y11: ................
y12: ....o.......o...      hoops (4,12),(12,12)
y13: ..@...==........      spawn (2,13), pads (5,13),(6,13)
y14: ################
y15: ################
```
Hmm, but the pad at r13 x5,x6 — the ball spawning at (2,13) rolls right into the pedestal; the pedestal is 1 tall and 2 wide; the ball could also just... it must bounce over it. OK. But the teaching pad launches 6 tiles — dramatic and safe.

Let me put the crystal in screen 0? "crystal takes a deliberate detour" — in L2, put the crystal in screen 0 up high: needs a pad launch. From the pad top (surface y=13, center 12.5), pad launch apex center = 6.5 → the crystal at (5,7)? center 7.5, reachable ✓. Hmm, it would be collected during the teaching pad launch, so not a detour. Put the crystal in screen 2 on a high side ledge.

Let me design L2 screens 1-4 with the structure I planned (high route row 12, plateau top row 6, etc.) but with a single door at the end.

L2 plan (surface altitudes): screen 0: y=14 flat. Screen 1: y=14 flat with spike pits, then a pad launch to a plateau at row 6 spanning into screen 2. Screen 2: plateau row 6 (high route) + a low route at row 14 with a crystal; screen 3: descent + pad + crumbles? No, crumbles are L3. Screen 3-4: pads and spikes, ending with the door on a plateau.

Let me be concrete.

=== L2 screen 1 (x16-31) ===
- ground rows 14,15 solid at rel x0-15 except spike pits.
- spike pits at rel x3,4 and rel x8,9,10 (2- and 3-wide), separated by clear floor.
- a pad pedestal at rel x13 (pad tile r13, top surface y=13) launching to the plateau in screen 2.
- hoops: 2 here.
Rows (rel x 0-15):
```
y0:  ................
y1:  ................
y2:  ................
y3:  ................
y4:  ................
y5:  ................
y6:  ................
y7:  ................
y8:  ................
y9:  ................
y10: ................
y11: ........o.......     hoop (rel 8, y11) — hmm above a spike pit; collected mid-flight over the pit? The ball crossing at speed... Let's put it elsewhere.
y12: ..o.............     hoop (rel 2, y12) center 12.5 = rolling ✓
y13: ......^^^...=...     spike pit rel 6,7,8 (floor = row 14 solid? no!) 
```
Careful: spike pits — I replace the floor row 14 tile with '^' and keep row 15 solid, so the pit floor is at y=15 and the spike occupies row 14. Hmm, earlier I decided the spike tile at row 14 with row 15 solid → hitbox y ∈ [14.42, 15.0] → a ball falling in dies ✓. And the ball rolling on the surface y=14 (center 13.5, bottom 13.0) at x just before the pit: the spike at tile (19,14) has hitbox x ∈ [19.12, 19.88]; the ball rolling at center (18.5,13.5): nearest point (19.12, 14.4) → dx=0.62, dy=0.9 → dist 1.09 > 0.48 ✓ safe. As it rolls to (19.0,13.5): nearest (19.12,14.4) → dx 0.12, dy 0.9 → dist 0.91 > 0.48 ✓ safe (because the hitbox's top is at 14.42 and the ball's center is at 13.5 — the ball is above the hitbox's top, so only its center-to-box distance matters). Hmm, so the ball rolling at surface y=14 over a spike at row 14 would NOT be killed?! Because the ball's center is 0.9 above the hitbox top. But the ball has no floor there (the spike tile is not solid), so it falls into the pit and then dies. Right, but if the pit were only 1 tile deep with a spike at its floor... yes, it falls and dies ✓. But the "safe roll over" case matters if the spike is solid — it's not.

Alternatively, place spikes ON the surface: the spike tile at row 13 above a solid floor at row 14 → the spike occupies the tile the ball rolls through (surface y=14, center 13.5): spike hitbox for tile (x,13) is y ∈ [13.42, 14.0], x ∈ [x+0.12, x+0.88] → the ball at center (x+0.5, 13.5) → the nearest point is (x+0.5, 13.5) itself (inside the box) → dist 0 → dead ✓. So spikes on the surface are lethal to a rolling ball ✓ and that's the classic "spikes on the floor" hazard. 

Which do I want? Both work. Surface spikes (spike at row = surface-1) are a wall-to-run-through hazard: the player must bounce over them. Their tile is not solid, so the ball can also fall? No — with a solid floor at row 14, the spike at row 13 sits on the floor; the ball rolling along surface y=14 hits the spike tile region and dies.

Hmm, but the spec says "Every gap in a floor is floored with spikes rather than bottomless." So gaps (holes in the floor) have spikes at the bottom of the gap. That means: the floor rows 14,15 with a gap → remove the row-14 solid at the gap columns and put spikes at... the gap's bottom. If the gap removes row 14 only, the bottom of the gap is row 15's top (y=15), so a spike sitting on it occupies row 14 ✓ → spike tile at row 14, row 15 solid.

So the "pit spike" version: '^' at row 14, solid at row 15. That's a "gap floored with spikes" ✓. It kills by falling in.

For a surface spike hazard (lethal to rolling), place '^' at row 13 with solid row 14 below — that's a spike ON the floor, not in a gap. The spec says spikes may fill their tile visually but the lethal hitbox is smaller so "a clean bounce over a floor spike is never frame-perfect". This implies floor spikes that you bounce over ✓. Good, both are fine.

But careful: with the surface spike version, a spike at row 13 (hitbox y 13.42..14.0) — a ball bouncing over it: at the crossing its center must be above... The ball's center at 13.0 gives nearest point (x,13.42) → dy 0.42, and dx=0 if aligned → dist 0.42 < 0.48 → dead! So the ball must be higher: center ≤ 13.0 - ... need dist > 0.48 when dx=0 → 13.42 - cy > 0.48 → cy < 12.94. So the ball's center must be above 12.94 while crossing the spike's x-range [x+0.12, x+0.88]. The ball rolls at center 13.5 (dead) so it must jump. A full bounce from the floor: from center 13.5, it reaches 10.5. The ball needs cy < 12.94 → that happens from t where 13.5 - 11.489t + 11t² < 12.94 → 11t² - 11.489t + 0.56 < 0 → t ∈ [0.0526, 0.993] → a 0.94 s window ✓ generous. And landing: after the spike, must land on the floor beyond x+0.88. If the ball is at speed 6, in 0.94 s it travels 5.6 tiles. Fine.

So: place surface spikes as hazards on ledges AND pit spikes in gaps. Both are lethal. Good.

Important: a ball that lands right next to a surface spike (1 tile away) is safe ✓.

Now, one important safety check: the respawn/landing spots must be ≥ ~0.5 tiles from spikes. Since the ball is 1 tile wide and the spike hitbox is inset 0.12, a ball landing adjacent (its edge touching the spike tile's edge) has center at the tile boundary; e.g., spike tile at x=20 row 13, ball landing with center x=19.48 (its right edge at 19.96): nearest spike point (20.12, 13.42)... dx = 0.64 → dist ≥ 0.64 > 0.48 ✓ safe.

OK. Now let me write L2 concretely. I'll aim for a coherent 5-screen side view. Let me use the pit-spike style (spikes at floor level in gaps) for most, and a few surface spikes on ledges.

L2 screen 0 (x0-15) — safe opening, teaching pad:
```
y0-9:  empty (except decorations)
y10: '................'
y11: '...........o....'    hoop (11,11) center 11.5 ✓ bounce
y12: '....o...........'    hoop (4,12) center 12.5 = rolling ✓
y13: '..@...==....c...'    spawn(2,13); pad(5,13),(6,13); checkpoint (12,13)
y14: '################'
y15: '################'
```
Wait: is the checkpoint at (12,13) OK? center (12.5,13.5) ✓ rolling.
Hoops so far: (4,12), (11,11) = 2.
Crystal for L2: high ledge in screen 1 or 2.

L2 screen 1 (x16-31): first spike pits + the critical pad.
```
y0:  '................'
y1:  '................'
y2:  '................'
y3:  '................'
y4:  '................'
y5:  '................'
y6:  '................'
y7:  '................'
y8:  '.......o........'    hoop (rel7,y8) — hmm reachable? The ball on the ground center 13.5, apex 10.5. Hoop center 8.5 → unreachable. NO.
```
Keep L2 objects at rows ≥ 11 unless on a high route.
```
y10: '................'
y11: '.....o..........'    hoop (rel5,y11) center 11.5: reachable by a bounce from the ground (apex 10.5) ✓
y12: '................'
y13: '..===.....^^^...'    pad pedestal rel 2,3,4 (row 13, top y=13); spike pit rel 10,11,12 (row 13 → surface spikes!) 
y14: '################'
y15: '################'
```
Hmm: if the spike is at row 13 with row 14 solid → it's a surface spike ON the floor (lethal to rolling) — that's a "spike wall" hazard 3 wide, must bounce over. That works too, and it's more visible/readable than pit spikes I think. But the requirement "every gap in a floor is floored with spikes" — I have no gaps then. Let me include both: gaps with spikes at the bottom (in screens 2-4) and surface spikes.

For a 3-wide surface spike patch at rel 10,11,12 with solid floor row 14: the ball must bounce over 3 tiles + its own width = from the last safe spot at rel 9 (center x 10.48 max) to landing at rel 13 (center x ≥ 13.5). Distance ≈ 3 tiles at the crossing... The ball's center must be above 12.94 from x=10.12 to x=12.88 (the spike hitbox span) and it starts at center 10.5. Takeoff at x=10.5, needs cy<12.94 from then until x=12.88+0.48=13.36 → 2.86 tiles ✓ easy at any speed (at speed 1, 2.86 tiles takes 2.86 s > the 0.94 s window!). Hmm: the window is when the ball is airborne with cy < 12.94 → from t=0.0526 to 0.993 s. If the ball moves at speed 1, in 0.993 s it travels 0.99 tiles → it would land at x=11.5 which is above the spikes → lands ON the spike tile? Landing on a spike tile: the spike tile isn't solid so it falls through it and dies. So at speed 1 you die; at speed ≥ 3 you clear 2.9 tiles within ~0.9 s ✓. So the player needs speed ≥ ~3.3 t/s. That's fine for a competent player (they hold the direction) — but the requirement "no obstacle that has to be taken at exactly one speed" — this is a *minimum* speed, not exact. With max speed 6 the ball travels 6*0.94 = 5.6 tiles, landing wherever. It must not land on a spike: if the spike patch is 3 wide with ≥3 clear tiles after, landing anywhere from 3 to 5.6 tiles ahead lands on clear floor ✓ as long as there are ≥ 3 clear tiles after the spikes (the ball's landing could be 5.6 tiles from takeoff = 2.7 tiles past the spikes). Fine.

To be extra safe for a slow/starting player, I'll place spikes only where the player has a running start, and make sure there's a visible cue.

Let me now just write out L2 with care, then let the solver verify.

L2 (FOUNDRY) 5 screens:

Screen 0 (x0-15):
```
y0:  '................'
y1:  '................'
y2:  '................'
y3:  '................'
y4:  '................'
y5:  '................'
y6:  '................'
y7:  '................'
y8:  '................'
y9:  '................'
y10: '................'
y11: '...........o....'
y12: '....o...........'
y13: '..@...==....c...'
y14: '################'
y15: '################'
```

Screen 1 (x16-31):
```
y0:  '................'
y1:  '................'
y2:  '................'
y3:  '................'
y4:  '................'
y5:  '................'
y6:  '................'
y7:  '................'
y8:  '................'
y9:  '................'
y10: '................'
y11: '.....o..........'
y12: '................'
y13: '.==....^^^...o..'
y14: '#####^^^########'   -- hmm mixing. Let me not have both a pit and surface spikes in the same screen confusingly.
```
Let me settle on: pit spikes = '^' at row 14 with row 15 solid (a gap in the floor). Surface spikes = '^' at row 13 with row 14 solid. Both read as a spiky floor to the player. I'll use pit spikes mostly (they read as holes with spikes at the bottom = clearer "don't fall in").

Actually for gameplay clarity, pit spikes are BETTER: the hole is visible, and the ball falls in and dies (the player must jump over the hole). Surface spikes require the ball to jump over a 1-tall spike, which is fine too. Let me use both but mostly pits.

With pit spikes: a 3-wide pit at rel x, r14='^^^', r15 solid. The ball rolling at surface y=14 must clear: from the last solid tile before the pit, its center can be at most (pitStart - 0.48); it falls if it goes past the edge. Actually the ball rolls off the edge and falls. Takeoff: the ball must have jumped before the edge — a full bounce from the ground at speed s: the horizontal distance until it returns to y=13.5 is 6.27*t/1... = 6.27 tiles at s=6 (full round trip). But it doesn't need to return to 13.5; it needs to land on the far edge, i.e. reach x_far + 0.48 with cy ≤ 13.5. So it needs to travel 6.27 tiles at speed 6 to be back at 13.5, or 3 tiles at speed 6 in 0.5s when it's at apex. So a 3-wide pit + 2*0.48 margin = ~4 tiles: at speed 6, it takes 0.67 s, and the height at 0.67 s: cy = 13.5 - 11.489*0.67 + 11*0.449 = 13.5 - 7.7 + 4.94 = 10.74 ✓ well above. So it clears easily. Landing beyond the pit at 4+ tiles ✓.

So a pit of 3 wide is easy at speed 6. Pits of 5-6 wide require full speed. Level 4 could use 5-wide pits with pads.

OK writing L2 for real now:

Screen 1: two pits + a pad pedestal that launches to a high plateau in screen 2.
```
y0-9:  empty
y10: '................'
y11: '.....o..........'      hoop (21,11)
y12: '................'
y13: '..==............'      pad pedestal rel 2,3 → abs 18,19 (top surface y=13)
y14: '####^^^####^^^##'      pit rel 4-6 (abs 20-22) and rel 11-13 (abs 27-29)
y15: '################'
```
Wait — the pad pedestal at rel 2,3 row 13 is at abs x18,19 and the pit is at abs 20-22 → the pad is right before the pit; landing on the pad and bouncing 6 tiles takes the ball over the pit ✓. Hmm, but the pad's left face is 1 tile above the ground: the ball rolling into it stops, then bounces onto it. OK.

Actually, better: the pad launches the ball over the spikes. But the ball could just bounce over the spikes from the ground without the pad (3-wide pit is clearable at speed 6) — fine, the pad makes it easy.

Screen 2 (x32-47): the high plateau + crystal + the descent.
I want a plateau whose top is at row 6, reachable by a pad launch from screen 1... but the pad at abs 18-19 (surface y=13): pad apex center = 12.5-6 = 6.5 → reachable ledges surface ≥ 7.5 → row 8 comfortably. Hmm, so from a pad at surface y=13, the reachable plateau top is row 8 (comfortable). Let's set the plateau top row 8.

Screen 2 layout:
- Left part (rel 0-7): low ground rows 14,15 (surface y=14).
- A big plateau block from rel 4 to rel 15 (abs 36-47) solid rows 8..15 → its top surface y=8, and it's 12 tiles wide (a generous high road).
- The ball arrives on top from the screen-1 pad (needs to reach x≥36 at altitude ≤ 8.5): from the pad at abs 18.5, pad launch: apex center 6.5, so at x=35.5 (17 tiles away) it would have landed long before. Hmm — the ball can't travel 17 tiles at the needed altitude. Its flight: apex at 1.044 s; at speed 6 it travels 6.27 tiles in the full round trip (2.089 s). So from x=18.5, the full pad-bounce arc goes to x≈24.8 landing at surface y=13 (the pad level) or the ground level y=14 (further). Hmm, the pad bounce from surface 13: total airtime 2.089 s, at speed 6 = 12.5 tiles, landing at surface y=13 level; if it descends to the ground surface y=14 it travels a bit further (~13 tiles). So the pad can throw the ball 12-13 tiles! That's a lot. So the ball launched from the pad at abs 18.5 at speed 6 flies to abs ~31 and lands at... whatever surface is there around y=13-14. Then it would crash into a wall if the plateau starts at abs 36. Hmm.

So for the pad → plateau route, the plateau must be within ~10 tiles horizontally, OR the ball bounces multiple times (holding bounce on the pad keeps it at 6-tile height each landing... but it only lands on the pad once; in the air it travels).

Let me restructure: place the pad pedestal close to the plateau: pad at abs 30-31 (screen 1 rel 14,15), plateau starting at abs 34. From the pad at center 31.5, apex center 6.5 at t=1.044s; the ball needs cy ≤ 7.5 to land on the plateau top (row 8 → resting center 7.5). At speed 3: at t=1.044 it has moved 3.1 tiles → x=34.6 ✓ which is ≥ 34 (plateau start) ✓ and near apex ✓ lands on top. At speed 6: at t=0.5 it has moved 3 tiles → x=34.5, cy = 12.5-5.74+2.75 = 9.5 → that's below 7.5 → it hits the plateau's left wall at abs 34 → blocked, slides down. Hmm! At high speed it fails. Then it lands on the ground before the wall, and needs a slow-speed launch. That's "an obstacle that has to be taken at a specific speed" (max speed) — a competent player can just go slowly (tap the direction). Hmm, the spec says "no obstacle that has to be taken at exactly one speed". Taking it at ≤ some speed isn't "exactly one speed", but I'd rather avoid needing care.

Fix: make the plateau's left face a staircase from the ground up (rel steps) so any speed works? Then the pad wouldn't be needed...

Alternative: put the pad at the BOTTOM of a shaft and the plateau at the top of the shaft with a wide landing area to the right. Classic: the ball is in a pit (a 2-deep trench), a pad at the trench floor launches it up a shaft; the wall on the right is far enough that the ball can then land on a wide high plateau. The trick: the pad's launch must be able to reach the plateau top with plenty of horizontal room: if the high plateau's left edge is a wall going up to row 8, and the pad is at the bottom (surface y=14) at abs x=P, then the ball launched from center y=13.5 reaches apex 7.5. To land on a plateau with top row 8 (resting center 7.5) it must have cy ≤ 7.5 → only at the very apex → too tight. So the plateau top must be at row 10 (resting center 9.5): reachable from a ground-level pad (apex 7.5) with 2 tiles margin ✓. And 10 - 14 = 4 tiles up from the ground... but then the ball could also climb it via 2 bounces on intermediate ledges? Only if there are ledges. A sheer wall from y=14 to y=10 (4 tiles) is not climbable without the pad ✓ (max 3, tight). Hmm, 4 tiles needs care; with the pad's help, the ball at apex 7.5 must land on the wall top at 9.5 — that's 2 tiles of margin ✓.

But wait: to land ON the plateau (top row 10), the ball must be to the right of the plateau's left edge while above y=9.5. The pad is at the trench floor; where's the plateau's left edge relative to the pad? If the pad is directly below/adjacent, the ball rises straight up next to the wall, and needs horizontal movement of ~1-1.5 tiles to get over the plateau. With the pad's 2.09 s airtime, tiny horizontal speeds suffice; at speed 6 the ball travels 12.5 tiles and would sail past the plateau if the plateau is narrow. So make the plateau wide (12+ tiles) → at speed 6 it lands somewhere on the plateau ✓; at speed 1 it lands at ~2 tiles ✓ on the plateau. Both fine as long as the plateau is ≥ 12 tiles wide starting right next to the shaft. 

So the rule for pad routes: a wide (≥ 12 tile) landing plateau whose top is 4 tiles above the pad surface (2 tiles of margin). 

And to prevent a 2-bounce climb onto the plateau without the pad: a 4-tile sheer face is not climbable in one bounce (max 3, tight) — but wait, could the ball bounce twice to gain 4 tiles? No — every bounce is the same height; there's no accumulation. From the ground, apex center 10.5; to land on a 4-tall ledge (resting center 9.5) is impossible. Could the ball land on the ledge if it starts ON something 1 tile high? Yes (from a 1-tall step, apex 9.5 → exactly the ledge, tight). So I should avoid 1-tall steps right in front of the plateau. Fine.

Great, that's the L2 pad design. Let me define L2 with altitude changes:
- Screen 0: surface y=14, flat, teaching pad (embedded 1-tall pedestal).
- Screen 1: spike pits, flat ground y=14, ending with a shaft: at abs x=28-31 the ground drops to row 15 (i.e., a 1-tile depression?) Hmm.

Let me simplify the pad-on-critical-path in L2 as: a wide 5-tile spike pit that's clearable ONLY with a pad (because at max speed a full bounce is 6.27 tiles, hmm that clears 5). Let's compute the maximum jump distance: full bounce from surface y=14 at speed 6 → 6.27 tiles (returning to y=13.5 center). If the pit is 5 wide plus the ball's need to land past the far edge... takeoff from the last safe tile: the ball's center at pitStart-0.48; it must land with center ≥ pitEnd+0.48 (so its bottom is on solid ground: center x ≥ (pitEndTile) + ... let me define: pit spans tiles [a, b] (not solid at row 14); the ball lands at x where row 14 is solid → x ≥ b+1 - ... center x ≥ b+1 - 0.48+ hmm: for the ball to land on the tile b+1, its center must be ≥ (b+1) - ... no: the tile b+1 spans x from b+1 to b+2; the ball lands if its center is within that tile's x-range ± overlap. Actually the ball lands on tile b+1 if its bottom edge overlaps the tile: center x ∈ [b+1-CR, b+2+CR] roughly (also overlapping neighbors). So minimum landing center x = b+1-0.48 = b+0.52. Takeoff center max = a-0.52. Distance = b+0.52-(a-0.52) = (b-a) + 1.04. For a 5-wide pit (b-a=4): 5.04 tiles ✓ within 6.27 at full speed. For a 6-wide pit: 6.04 — just at the limit. So max pit width ≈ 5.

So a pit of width 6-7 is impassable without a pad ✓. The pad's flight at speed 6 = 12.5 tiles → clears a 6-7 wide pit easily, but the landing must be generous: after the pad launch, if the ball still holds speed 6, it lands 12.5 tiles away; so the landing area beyond the pit must be wide (≥ 10 tiles) or the pit must be positioned so overshoot is safe. Let me design L2's critical pad crossing as: pad pedestal at abs x, then a 6-wide spike pit, then a long plateau (12 tiles). Overshoot lands on the plateau ✓ or flies into the next screen ✓ (also safe). 

Hmm, careful: the pad launches 6 tiles up; on the way up the ball may hit a ceiling. Fine, no ceilings.

OK let me write L2 now with this. And I'll place the checkpoint before the hard bit.

=== L2 FINAL MAP ===
Screen 0 (x0-15): as above: spawn 2,13; pad pedestal (5,13),(6,13); hoops (4,12),(11,11); CP1 (12,13).
Wait: the pad pedestal at (5,13),(6,13) is 1 tall. The checkpoint at (12,13) → center 13.5, rolling ✓.

Screen 1 (x16-31):
```
y11: '.....o..........'   hoop (21,11)
y12: '................'
y13: '................'
y14: '####^^^####^^^##'   pits abs 20-22 and abs 27-29
y15: '################'
```
Hmm: two 3-wide pits 4 tiles apart, the player needs speed for both. At speed 6, from a takeoff at x=19.52 they land at x=20.52+ ... the pit 20-22: land at x≥19.52... let me not over-think: pits 3 wide are easy.

Wait, but the second pit at 27-29: after landing at ~23.5 (abs) from the first pit, the ball needs speed again for the second. Landing at 23.5 with 3.5 tiles before the pit edge 27 → accelerate from 0: reaching 27 needs... v = sqrt(2*18*3.5)= sqrt(126) = 11.2 > max 6, so it reaches max speed within 1 tile (6²/(2*18) = 1.0 tile) ✓ so it hits the pit edge at speed 

Now write a checker that validates: row widths, entity counts, spawn validity, door placement, and a quick reachability heuristic (surface analysis). Let me write tools/check.js.

Also I should write a physics-based solver. Let me first do the structural checks, then the solver.

The user hasn't asked anything substantive yet — the last message was just system instructions saying I'm an expert software engineer helping the user solve problems. There's no actual task. I should acknowledge briefly and wait. My response was minimal acknowledgment.

The parent package.json has "type": "module". So use ESM in tools (import/export) or use .cjs. Let me rename tools to .cjs... but the parent package.json affects the directory. Since the game.js is browser-global (uses `typeof window`), loading it in node: with ESM, I can import it — but game.js is an IIFE assigning to globalThis, so `import '../game.js'` works (it has no exports, just side effects) as long as it doesn't use `document`. Careful: game.js at top-level calls `if (typeof document !== 'undefined') boot();` → in node, document is undefined → skipped ✓. But `global.BOUNCE` where global is `typeof window !== 'undefined' ? window : globalThis` → globalThis ✓ works in ESM import? An imported ESM module has its own scope; assigning to globalThis.BOUNCE works ✓.

Wait, game.js currently contains `LEVEL_SHAPES` referencing the maps inline. I plan to keep maps in game.js for the final. For tooling, I'll keep maps in tools/maps.js and have a build step that inlines them into game.js? Simpler: keep game.js with the maps inline (final requirement: levels defined as data in the source), and tools import game.js and read `globalThis.BOUNCE.LEVEL_SHAPES`.

So: use ESM in tools. Rename tools to .mjs? With the parent package.json type=module, .js files are ESM ✓. So just use `import`.

But my `tools/maps.js` uses `module.exports` → change to `export default`.

Let me restructure: 
- game.js contains everything including LEVEL_SHAPES inline (final state).
- tools/check.mjs: `import '../game.js'` then `const {LEVEL_SHAPES} = globalThis.BOUNCE;`.

For iteration, I'll keep the maps in tools/maps.mjs and port into game.js once validated. Actually simplest: write the maps directly in game.js, and tools import game.js. Iterating on maps = editing game.js. That's fine, edit tool works well.

Let me set that up: first put level 1's map into game.js (replace LEVEL_SHAPES[0]), then run the checker.

Note game.js currently has an invalid palette string: `pad: '#ffcf2 0'.replace(' ', '')` — I later set PALETTES[1].pad = '#ffb300' so it's valid but ugly. Let me clean it.

Also game.js references `sim.idx2` and `isSolidL` defined after boot — fine since they're used at runtime. And `drawDoor` uses `L0doorBottom(sim)` — fine.

Also in `drawScreen`, `p.doorOpen` doesn't exist; I set ctx.fillStyle twice then '#000000'. OK but let me clean later.

Let me first fix game.js palette + insert level 1 map, then check.

Playwright is available — I could screenshot the game in a real browser to verify rendering. Good for final verification.

Let me set up: maps live in game.js. tools/check.mjs imports ../game.js.

Let me update game.js's LEVEL_SHAPES with level 1 (from tools/maps.js content) and remove the placeholder palette hack.

Now insert the level 1 map into LEVEL_SHAPES[0] (replacing the existing draft) and keep 2-4 empty for now. Let me view the current LEVEL_SHAPES section.

I'll replace the entire LEVEL_SHAPES array (lines 94-188) with the level-1 map only (plus placeholders). Best: use a Python script to splice, or use edit with oldText being the whole block — too long. Let me instead write the maps to tools/maps.mjs and have a tiny build script that regenerates the LEVEL_SHAPES block inside game.js from tools/maps.mjs. That gives me easy iteration while keeping the final game.js self-contained.

Plan: `tools/maps.mjs` exports an array of 4 row arrays. `tools/port.mjs` reads maps.mjs, generates the text `const LEVEL_SHAPES = [...];` and splices it into game.js between markers `/*__MAPS_START__*/` and `/*__MAPS_END__*/`.

Let me add the markers to game.js by replacing lines 94..188. I'll do it with python for precision.

Wait, I need to check that line 188 (1-indexed) was indeed the closing `];` of LEVEL_SHAPES and that I didn't cut into other content. Let me verify around the marker.

Good. Now write tools/maps.mjs with level 1 filled in, and tools/port.mjs to splice into game.js. Then iterate on maps with the checker + solver.

Level 1 (MEADOW, 4 screens, 64 wide) final as designed:

Now a solver. It loads the maps with its own copy of the physics constants and simulates the ball with discretized actions. Let me write it.

Solver details:
- Load physics constants from game.js exports (import '../game.js' → globalThis.BOUNCE.C).
- Map → solid/pad/crumble/spike/hoop/check/crystal/door arrays (crumbles treated as permanently solid to be conservative; the closed door also treated as solid, so the solver must approach the door tile but the exit test = the ball overlapping the door tile; if the door is solid, the ball can't overlap... it can touch it though. So for the door reachability test, treat the door tiles as non-solid (as they will be when open) — I'll do the exit test with door non-solid.)
- Actions: 6 combos of (dir -1/0/1) × (bounce 0/1). Hmm, also for fine maneuvering include both left&right? Not needed.
- Step: replicate game physics.
- State hash: x,y to 1/8 tile; vx,vy to 1 t/s... Let me use q = v => Math.round(v*4)/4 for x,y and Math.round(v*2)/2 for vx,vy. vy is huge in magnitude (up to 14) and continuous; quantizing to 2 t/s may merge states wrongly (losing precision for landing timing), but for reachability exploration it's fine — it's heuristic. The risk is missing solutions. Let me use finer vy quantization (0.5) but include vy only when airborne... Let's try q(v)=round(v*4)/4 for velocities too → vy ∈ [-23,14] → 148 values; that's a lot but BFS is bounded by transitions anyway.

Actually a better search: since the search space is dominated by continuous variables, a randomized/monte-carlo search may be more effective: sample random action sequences (piecewise-constant actions with random durations), keep track of the best progress, and evolve (like a genetic search). Hmm.

Let me first try BFS with quantization and see how it does on level 1. I'll cap states and measure which entities get reached.

Key detail: for the BFS to work, I need states near the entity, and I should test entity collection during the simulation (using the same rules as the game). Then "reached hoops" = the set collected along some path (but each path collects its own set...). I'll track a global "ever touched" set for each entity type per level — approximate but useful. For the door, I'll test "did any trajectory ever overlap the door region".

Actually a cleaner approach to test completability: a goal-directed search — for a sequence of goals (each hoop, the crystal, the exit), simulate from the current state with a greedy/heuristic policy? Too fragile.

Let me go with BFS "ever touched" + additionally report the deepest x reached. That validates the corridors and most pickups. If BFS touches everything (all 6 hoops, 2 checkpoints, crystal, door) in each level, that's strong evidence of completability. The one thing it doesn't prove is that they're all collectible in a single run — but since a respawn preserves pickups and the state is deterministic from the spawn, if the BFS from spawn touches hoop A and (via another path) hoop B, then the player can get hoop A, die... no. Hmm. Actually if the BFS touches A and B from spawn (in separate branches), the player can traverse branch A, then return? Not necessarily.

Mitigation: run the BFS with the state including a bitmask of collected items? 2^9 = 512 × states. Might be too slow but let's try: visited key = hash + bitmask. Hmm, that explodes. Alternative practical approach: a real "player bot" with a heuristic policy: always move toward the nearest uncollected target, bounce when an obstacle or a hazard is ahead, etc. — that's a lot of tuning.

Middle ground: multi-goal BFS where I check "can I reach all items" by doing a sequence of single-goal searches: start at spawn with a state; BFS to the nearest goal, extract the path, follow it in the real sim (updating pickups), then BFS from that state to the next goal, etc. That's a greedy solver but uses real search per goal — pretty convincing and implementable. The risk: BFS to a goal might fail even if reachable from a different state; and after getting hoop A, the ball is at hoop A's location (momentum state) which is fine as a start state.

Also the door: after all 6 hoops, BFS to the door (door non-solid) → level complete.

Crumble blocks: treat as solid (conservative) but if a BFS fails, try treating them as solid and also try a variant where crumbles are gone (impassable). Simpler: treat crumbles as solid always — if a route needs the ball to *wait* on them, no. It's conservative: the solver will think the ball can stand on them forever, which is fine for crossing (a player crosses quickly).

Let me write the solver now. It needs the physics replicated faithfully (that's the risk of divergence, but it's a small core; I'll keep it tight and derive from the same constants).

Actually — better idea to avoid divergence: make the solver use the REAL Sim from game.js by driving `sim.input` with functions! The Sim class is DOM-free and `sim.step(dt)` is public. I can construct a Sim, set `sim.input = {left:()=>..., right:()=>..., bounce:()=>...}`, and call `sim.step(FIXED_DT)` directly. And I can snapshot/restore state by cloning {x,y,vx,vy,grounded} plus crumble map (leave crumbles unrestored — approximate; the state copy is approximate for crumbles but exact for the ball).

That's much better: no duplicated physics. The BFS snapshots ball state (x,y,vx,vy,grounded) and restores it. The level's pickups change monotonically (collected stays collected) which only makes later collection easier... but it distorts the "hoopsLeft" for the door. For the door test I'll set sim.hoopsLeft = 0 manually at the start (so the door is open during the search).

Hmm, but pickups collected during BFS change the sim state permanently (hoopDone). For the search, that's mostly harmless (I record collections as "touched" and accept that a hoop can only be "touched" once). To be careful, I'll snapshot the level's hoopDone/checkTaken/crystalTaken arrays too, along with the ball state and hoopsLeft — the whole relevant state. Cheap-ish: arrays of length 6/2/1.

Let me write it: snapshot() returns an object with ball {x,y,vx,vy,grounded,dead}, respawnAt, level hoopDone/checkTaken/checkActive/crystalTaken/crumble(serialized), hoopsLeft, lives, score, mode, camX. Restore assigns them.

For speed, the BFS will store compressed state keys and snapshots as plain objects. Number of states maybe 100k+ → memory heavy but OK for offline testing.

Let me write the solver with a max of ~60k states, depth limit ~4000 steps (33 s of game time)... BFS over steps: each state expands to 6 children; with visited dedup, ~60k states × 6 = 360k steps ✓ fast enough.

Plan per goal-search: 
```
function searchTo(sim, pred, maxStates=80000, maxDepth=3000) → {path, state} or null
```
BFS: queue of nodes {snap, actions:[], depth}. Expand: for each of 6 actions: restore snap, apply action for 1 step... but per-step action switching is expensive; that's the honest model though. Let me do per-step actions with the visited-state hash. Store the node's snapshot per queue entry (a snapshot object). Memory: 60k × (a small object) → fine.

Note: with per-step actions, the search has to hold keys for many steps to build speed. BFS explores uniformly, so momentum builds fine.

Additionally, to help reach distant goals, I'll bias: sort the action expansions... BFS is uniform cost. Since all steps cost 1, BFS is fine.

Also, I need the ball's y-quantization to keep the state space manageable. Let me use: q = Math.round(v*8)/8 for x,y (so 0.125 tile), and velocities rounded to 0.25. Also include `grounded` in the key. Also include crumble phase? Ignore (assume crumbles never collapse during the search — I'll additionally run each search with crumbles treated as already-gone, to prove routes don't depend on them).

Hmm, careful: if crumbles are gone (non-solid), routes over them become impossible; if solid, always possible. The truth is in between: the crossing must be made within ~0.5 s of first landing. So the honest check is with crumbles solid (the solver stands there indefinitely, which a player can't) — that's optimistic. So I'll manually verify the crumble crossings are crossable in < 0.5 s (short gaps). I'll note the crumble tile positions and check the distance from the previous platform is short.

Also there's a subtlety: my BFS treats the ball as unable to "die" (spikes kill it). Deaths in BFS = state where ball.dead → discard branch (that's realistic-ish).

Let me write the solver now and test on level 1.

Now I need a port script to put maps.mjs into game.js, then run check + solve for level 1.

Note: `Sim` constructor calls loadLevel(0) — for a level with an empty map (levels 2-4 currently), spawn defaults to (1.5,1.5) and everything works but the ball falls? With W=16 (rows=[] → W=0!). parseLevel with rows=[] gives W=0 → arrays of size 0, and tileAt returns out of bounds... The solve loop only runs on level 0 for now if I specify. Let me make port.mjs write empty levels as 16 blank rows? No: the game would break. I'll just fill all levels eventually. For now test level 0 only.

Let me write port.mjs and run.

Now the level 2, 3, 4 maps. Let me design them properly this time, using the pad/ledge rules:
- normal bounce: rise 3 tiles; comfortable climb = 2 tiles.
- pad: rise 6 tiles; comfortable climb = 5 tiles, must start from a standing position on the pad.

L2 FOUNDRY (80 tiles, 5 screens). Ground surface y=14 (rows 14,15 solid).

Screen 0 (x0-15): safe start, 2 hoops, CP1.
- spawn (2,13)
- Hoop A (1,13) center 13.5 rolling ✓
- Hoop B (8,12) center 12.5: from ground center 13.5 → apex 10.5 ✓
- CP1 (14,13) center 13.5 rolling ✓
- ground rows 14,15 solid.

Screen 1 (x16-31): introduce pads off critical path + Hoop C + spikes.
- Hoop C (19,12) rolling/bounce ✓
- pad pedestal: '=' at (22,13),(23,13) → top surface y=13 (1 tile above ground) ✓ reachable by bouncing from the ground (need cy ≤ 12.5 → rise 1 ✓).
  Landing on the pad launches 6 tiles: apex center = 12.5-6 = 6.5.
- spike pit: rows 14 at rel 12,13 (abs 28,29) 2 wide ✓, floor row 15 solid.
- The ball bounces over the 2-wide pit easily from the ground.
Rows for screen 1: rel x0-15; abs = 16+rel.
rel y12: hoop at rel 3 (abs 19) → '...o............'
rel y13: pads at rel 6,7 (abs 22,23) → '......==........'
rel y14: spikes at rel 12,13 → '############^^##'
rel y15: all solid.

Screen 2 (x32-47): CP2 + Hoop D + crystal + a pad that starts the high route.
Plan: 
- ground rows 14,15 solid from rel 0..15 (surface y=14) — but with a structure: a 2-tall step at rel 8,9 (solid rows 12,13,14,15) → top surface y=12 (2 up) ✓.
- Hoop D (rel 4 = abs 36, y12) center 12.5 ✓ bounce from ground.
- CP2 at rel 2 (abs 34, y13) center 13.5 rolling ✓ (banks progress before the second hard stretch: the ascent + the spike gauntlet).
- The crystal on a high ledge: reachable only via a pad. Place a pad '=' at rel 14,15 (abs 46,47) row 13 (top surface y=13) — that's the pad which starts the high route into screen 3.
- The crystal is in screen 3, at (51,7) (rel 3): the ball standing on a pad at (46,13)+(47,13)... the crystal at (51,7) center 7.5. Standing center 12.5 → apex center 6.5 ✓. Horizontal: from the pad center 47.5 → 51 = 3.5 tiles, needs cy ≤ 7.5 → from t=0.612 to t=1.476 → at speed 2.4 (t=1.476 for 3.5 tiles) ✓ fine at speeds ~2.4-5.7 t/s. At speed 6, at t=0.583, x=51, cy=8.74. So the player must not be at full speed... At full speed it sails past, lands somewhere in screen 3 (safe ground) and can retry. Fine (retryable). Let me put the crystal a bit closer: (50,7): dx from 47.5 = 2.5 → window t ∈ [0.612,1.476] → speeds 1.69..4.08 t/s. At full speed 6 it misses. That's fine but let me place it exactly at the apex for widest tolerance: apex x = 47.5 + 6*1.044 = 53.8 at speed 6. Hmm, depends on the player's speed. Alternative: make the crystal reachable at low speed, which is easy to control (tap the direction). Keep (50,7).

Hmm, actually, the crystal should be reachable via a deliberate detour and be reasonably forgiving. Since a pad launch from standing (vx=0) rises straight up, the ball would rise from center (47.5,12.5) to (47.5,6.5) — the crystal at (47,7) center 7.5 would be caught on the way up (|dy|=1 at the moment when... the ball's center passes 7.5 at t=0.612 → if vx=0 then x=47.5, |dx|=0.5 <1.02 ✓ caught). So with vx=0, a crystal at (47,7) or (46,7) or (47,6)... Let me put the crystal at (48,7) → center 48.5: |dx| = 1.0 < 1.02 — marginal at vx=0. If the player drifts right slightly, it's caught. Hmm. The player wants to reach the high route in screen 3 anyway. Let me make the crystal directly above the pad: (46,7) center (46.5,7.5) — standing on the pad x46-47 (center 46.5 to 47.5) → with a small rightward drift, both x and y windows are satisfied easily ✓. So crystal = (46,7).

But wait, is a crystal at 5.5 tiles above the pad surface reachable? Standing center 12.5, crystal center 7.5, needs center ≤ 7.5+ (|dy|<1.02 → center ≥ 7.5-1.02 = 6.48) → apex center 6.5 ≤ 6.48? Apex is 6.5, so the ball needs center ≤ 7.5+1.02=8.52 (i.e., be within 1.02 above/below) — the ball reaches center 8.52 at some time ✓ well before apex. Fine, generous.

OK so: pad at abs (46,47) row 13, crystal at abs (46,7)?? Hmm, the crystal is 6 tiles above the pad's surface = at the very top of the pad's launch arc. That's a nice "high ledge" detour. But is the crystal reachable *without* the pad? No (it's 6 tiles above the ground) ✓ deliberate.

Screen 3 (x48-63): the high route: reachable only from the pad. A ledge at row 8 spanning rel 0..7 (abs 48-55) solid rows 8..15 → surface y=8. From the pad standing center (46.5..47.5, 12.5), a pad launch (apex center 6.5) → landing on surface y=8 needs cy ≤ 7.5, with dx ≥ 0.5... For the ball to land on the ledge at abs 48+ (its left edge is at x=48), the ball must cross x=48.48 (center) with cy ≤ 7.5. The window cy ≤ 7.5 is t ∈ [0.612, 1.476]. So dx from 47.5 → needs x ≥ 48.48 → dx ≥ 0.98 → t ≥ 0.98/speed... For any speed s: the ball reaches x=48.48 at t = 0.98/s. If s is large (6), t = 0.163 → at that time cy = 12.5-1.76 = 10.9 (still below the ledge top 8) → the ball slams into the ledge's left wall (rel 0, rows 8-15 = a tall wall) and falls back. Then the player retries with less speed. At s=1.5: t = 0.65 ✓ cy = 12.5-7.47+4.65 = 9.7? Let me compute: cy = 12.5 - 22.978t + 11t²; at t=0.65: 12.5-14.94+4.65 = 2.2?? That's above the level top... Hmm, 12.5 - 14.94 = -2.44 + 4.65 = 2.21 → that means the ball's center is at y=2.21 which is above the ledge surface (8) ✓ so it clears the ledge height. Wait but that's wrong: at t=0.65, is that right? v0=22.978, so y(t) = 12.5 - 22.978t + 11t². At t=0.65: 12.5 - 14.94 + 4.65 = 2.21. Hmm, that seems too high — apex is at t = 22.978/22 = 1.044 with y = 12.5 - 22.978(1.044) + 11(1.09) = 12.5 - 23.99 + 11.99 = 0.5. Yes apex center y = 0.5?? But I said apex = standing center - 6 = 12.5-6 = 6.5. Let me recompute: h = v²/(2g) = 22.978²/(2*22) = 528/44 = 12.0. That's wrong! PAD_V = sqrt(2*G*PAD_H) = sqrt(2*22*6) = sqrt(264) = 16.25, not 22.978. I mis-computed earlier (sqrt(2*22*6) = sqrt(264) = 16.248). Yes! PAD_V = 16.25 t/s. And BOUNCE_V = sqrt(2*22*3) = sqrt(132) = 11.489 ✓. I earlier wrote PAD_V = 22.978 (that was sqrt(528) — wrong).

So PAD_V = 16.25. Airtime = 2*16.25/22 = 1.477 s. At max roll 6 t/s → 8.86 tiles per pad bounce.

Let me redo the pad calcs: standing center 12.5 → apex center 6.5 ✓ (rise 6). cy ≤ 7.5 window: y(t) = 12.5 - 16.248t + 11t² ≤ 7.5 → 11t² - 16.248t + 5 = 0 → disc = 264 - 220 = 44 → sqrt=6.63 → t = (16.248±6.63)/22 → t ∈ [0.437, 1.040] ✓ duration 0.6 s. So dx = s*t ∈ [0.437s, 1.04s]; for landing on a ledge ≥ 0.98 tiles away: s ≥ 0.94 and s ≤ 2.25 (so dx ≤ 2.2 for the ledge's... no upper limit unless there's a wall on the far side). So a speed range of ~1-2 t/s → wide ✓. At s=6, dx at t=0.437 = 2.6 tiles; at that x the ball's cy = 7.5 and it keeps descending — if the ledge is present at x=48..55, the ball's center passes below 7.5 at x > 50.1 and lands on the ledge top around x ≈ 52-53 (where cy = 7.5 again at t=1.04 → x = 47.5+6.24 = 53.7 ✓ on the ledge). Wait, I need to be careful: the ledge's left wall is at x=48 (solid rows 8-15). The ball at t=0.437 is at x=50.1 with cy=7.5 (just at the ledge's top surface level). Between t=0.437 and t=1.04 it's above the surface (cy < 7.5) ✓ so it passes over the ledge region and then descends onto it at x ≈ 53.7 ✓ lands. So at s=6 it lands at x≈53.7, which is on the ledge (48-55) ✓. At s=1.5 it lands at... the ball's cy = 7.5 at t=0.437 → x = 47.5+0.66 = 48.2 → but the ledge's left wall is at x=48; the ball's center at 48.2 means its left edge is at 47.72, overlapping the wall at x=48? Its center y = 7.5 (bottom = 8.0 = exactly the ledge top). So it just grazes the corner. Hmm — the collision might resolve horizontally (pushing it left) instead of landing it on top. Risky. To fix, the pad should be positioned so that the ball, at low speed, rises beside the wall and clears it before descending: the ball's center at the moment it crosses x=48.48 (so its left edge is at 48.0, just past the wall's face) must be ≤ 7.5. Crossing x=48.48 happens at t = 0.98/s. For s=1.5 → t=0.653 → cy = 12.5-10.6+4.69 = 6.59 ✓ ≤ 7.5 ✓ so it clears the wall! (At t=0.437 it's at x=48.15... let me redo: at s=1.5, x(t) = 47.5+1.5t. At t=0.437, x=48.16 — the ball's left edge = 47.68 → overlapping the wall at x=48 with cy=7.5, bottom = 8.0. The wall tile is at column 48, rows 8..15 → its top-left corner is (48,8). The ball's center (48.16, 7.5), r=0.48: the closest point of the wall tile (48..49, 8..15) is (48.16, 8.0) → distance 0.5 > 0.48 ✓ no overlap. Phew, it fits.) 

But in the game, the horizontal collision check uses AABB-style box overlap (my implementation checks tile box overlap in the axis pass). Let me re-examine my moveX: it checks whether the ball's box [x-CR, x+CR] × [y-CR, y+CR] overlaps the tile rect [tx, tx+1] × [ty, ty+1]. With center (48.16,7.5): box = [47.68,48.64]×[7.02,7.98]; the tile (48,8) spans [48,49]×[8,9] → no y-overlap (7.98 < 8) ✓ no collision. Good — but that's marginal (0.02). Such marginal cases are the "frame-perfect" risk. My box-based check is slightly *more* conservative than a true circle check (the box corners stick out), which means it may block where a circle would fit. For safety, I should use a true circle-vs-tile check in the axis passes: overlap test = closest point distance < r. Let me improve moveX/moveY to use the true circle test:

For moveX: after moving x, for each nearby tile, compute the closest point on the tile to the center; if dist² < r² → collision. For horizontal resolution, I additionally want to only resolve when the contact normal is horizontal. Since we resolve axis-by-axis and y was already resolved last step, using the pure distance test is standard. But the risk: the ball resting exactly on the floor (bottom at y = tile top) with center y = ty - 0.5... then during moveX, the tile at (tx, ty) below the ball's feet: the closest point to the center is (clamp(x), ty) → distance = 0.5 in y... equals r=0.48? No: center y = ty - 0.48 - EPS (resting), so the vertical distance to ty = 0.4813 < 0.48? It's 0.48+EPS = 0.4815 > 0.48 ✓ no overlap. Hmm, marginal! Because the ball rests exactly at distance r from the floor tile. With EPS=0.0015 the gap is tiny; floating point could make it collide → then moveX would push the ball horizontally out of the floor tile → wrong (it'd push it back, making rolling impossible). That's why my current box test is actually safer for the floor case? No—the box test has the same issue: the ball box bottom = center y + 0.48 = ty - 0.0015 < ty ✓ no overlap. Same margin. Hmm, but for the tile the ball is standing ON: the ball's box is [x-0.48,x+0.48] × [ty-0.96-e, ty-0.0015] and the tile below spans [tx,tx+1]×[ty,ty+1] → no overlap ✓ (since bottom < ty). OK both work.

The real fix for robustness: use a smaller collision radius for X than for Y? Common technique. Or: in moveX, only consider tiles that vertically *straddle* the ball's center (overlap the center row band), not tiles the ball merely touches at its bottom edge. I.e., require the vertical overlap of the ball's box with the tile to exceed a margin (say 0.1 tile). That prevents both the "standing on a floor blocks horizontal movement" issue and the corner-graze blocking. Similarly, in moveY, require horizontal overlap > margin.

Let me implement:
- moveX: tile overlaps in the y-direction with |overlap| > STEP (0.12 tile) — i.e. ballTop < tileBottom - STEP && ballBottom > tileTop + STEP.
- moveY: ballLeft < tileRight - STEP && ballRight > tileLeft + STEP.
Hmm, but requiring overlap > STEP in moveY means a ball landing on a tile only by its very edge (a corner landing) doesn't land — that's the standard "corner tolerance" and is fine (it makes edge landings slightly forgiving).

Hmm, but careful: if the ball lands with only 0.05 overlap on a ledge, it doesn't land → it slides past the ledge and falls. With STEP=0.12 that could feel wrong. Let me use STEP = 0.06 for moveY and 0.06 for moveX, plus EPS. Actually the marginal grazing case above (bottom exactly at the ledge top corner) — with STEP=0.06 the ball must overlap the tile by ≥ 0.06 vertically to be blocked horizontally ✓ nice.

Let me now use: in moveX, a tile counts if `oy = min(ballBottom, tileBottom) - max(ballTop, tileTop) > 0.08`. In moveY, a tile counts if `ox = min(ballRight, tileRight) - max(ballLeft, tileLeft) > 0.08`.

Hmm, for landing detection, the ball moving down: I want a hit if ox > 0.08. The ball is 0.96 wide and the tile is 1 wide, so ox = 0.96 when aligned; if the ball is at the ledge's edge, ox smaller. So requiring ox > 0.08 means the ball needs at least 0.08 of overlap to land ✓ fine.

OK, I'll implement that. It makes the physics "corner-tolerant" = fewer snag/frame-perfect issues.

Now, back to level design; my earlier pad calc assumed PAD_V=22.978 in a couple of places. Let me redo the key pad numbers with PAD_V=16.25, PAD rise = 6 tiles ✓ (that's what matters: rise 6 tiles, airtime 1.477 s, max horizontal 8.86 tiles).

For L2's high route: pad surface y=13 (standing center 12.5) → apex center 6.5 → can land on ledges with surface ≥ 7.5 → i.e. surface rows 8+ ✓ (8 ≥ 7.5). Margin 0.5 tile. Comfortable? A ledge at surface y=9 (resting center 8.5) has 1.5 tiles of margin ✓ better. Let me set the L2 high ledge top at row 9 instead of 8. Then:
- L2 screen 3: ledge abs 48-55, solid rows 9..15 → surface y=9.
- Then Hoop F at (53,8) center 8.5 → the ball standing on the ledge at center 8.5 ✓ collected by rolling ✓ nice.
- Crystal: from the pad standing center 12.5, apex 6.5. Crystal at (46,7)? center 7.5 — the ball passes through center 7.5 going up ✓ (7.5 ≥ 6.5) ✓ reachable. But careful: the crystal at (46,7) is directly above the pad — while standing on the pad at center (46.5 or 47.5, 12.5) and pressing bounce, the ball rises straight up through (46.5, 7.5) → the crystal center (46.5, 7.5) ✓ collected at the top of the arc.

Hmm, but the crystal would then be on the critical path (collected automatically). Requirement: "the crystal ball takes a deliberate detour — a high ledge or a side alcove — and is never required". If it's auto-collected on the way up the pad, it's not really a detour. Let me put the crystal elsewhere: on a small side ledge in screen 2 at row 11 reachable by a normal bounce but off the main path (e.g., above a wall the player must deliberately climb). Let me put the crystal in screen 1 in a side alcove: e.g., a pocket at rows 11-12 above the pad pedestal... 

Simpler: crystal in screen 2 on a high ledge that requires 2 bounces up a staircase going *up* from the main floor (the main path stays low). E.g., a ledge at abs (36-39, row 10): reachable only by bouncing onto a step at row 12 first, then to row 10. The main path continues at the ground level → the crystal is a deliberate detour ✓. Let me place:
- screen 2: a raised structure: columns x38,39 solid rows 10..15 (surface y=10); step: columns x36,37 solid rows 12..15 (surface y=12). From ground (center 13.5) → bounce onto x36-37 top (resting center 11.5, rise 2 ✓). From there → bounce onto x38-39 top (resting center 9.5, rise 2 ✓). Crystal at (38,9)? center (38.5,9.5) → collected when standing on x38-39 top ✓. But it should be a "high ledge" ✓ it is.

Hmm, but is the crystal reachable directly from the ground by a single bounce? Standing center 13.5, apex center 10.5; crystal center 9.5 → needs center ≤ 9.5+1.02... the ball's center must come within 1.02 of (38.5,9.5): its minimum center y is 10.5 → distance 1.0 < 1.02 → hmm, barely reachable from the ground with a bounce right next to it. Let me raise it: crystal at (38,8) center 8.5 → from the ground's apex 10.5, distance 2 → not reachable ✓. From the x38-39 ledge (standing center 9.5): |dy| = 1.0 < 1.02 ✓ collected while standing?? The ball standing on the ledge has center 9.5, the crystal center 8.5 → dy = 1.0, dx = 0 → dist 1.0 < 1.02 ✓ collected. OK but that's marginal-looking; better: put the crystal one tile higher, at (38,7) center 7.5: standing center 9.5 → dy=2 ✗; bouncing from the ledge: apex center 6.5 → passes 7.5 ✓ collected mid-bounce ✓. Nice: the crystal requires climbing the staircase and bouncing at the top — a genuine detour ✓.

But careful: the crystal at (38,7) — is the space above the x38-39 ledge free (rows ≤ 8 empty)? Yes, if no other structure. The ball bounces from the ledge top (y=10) up to center 6.5 → its top edge is 6 → must have clearance at rows 6-8 above the ledge ✓ ensure the map is empty there.

OK. Now let me also fix L1's numbers — all L1 hoops were at rows ≥ 8 with the ground at 14 (max rise from ground = apex center 10.5, reach |dy| ≤ 1.02 → hoop center ≥ 9.48 → hoop rows ≥ 9 (center 9.5) ✓; hoops at row 8 (center 8.5) require a launch from a surface y=12 or lower... 

L1 checks (ground surface y=14, standing center 13.5, apex center 10.5):
- Hoop A (1,13): center 13.5 rolling ✓
- Hoop B (8,6): center 6.5 — from the x8-9 ledge (surface y=8, standing center 7.5, apex 4.5): passes 6.5 ✓
- Hoop C (14,12): center 12.5 ✓ bounce from ground
- Hoop D (17,13): center 13.5 rolling ✓
- Hoop E (25,11): center 11.5 ✓ from ground (apex 10.5 ≤ ... need |dy| ≤ 1.02 → yes passes 11.5 ✓)
- Hoop F (34,13) rolling ✓, Hoop G (41,13) rolling ✓ — wait that's 7. Let me re-list L1's final hoops: (1,13), (8,6), (14,12), (17,13), (25,11), (34,13), (41,13), (46,7), (53,11), (58,13) = 10. Too many! I need exactly 6.

Let me recount from the maps.mjs level-1 draft:
Screen 0: 'o' at (8,6) [row6: '........o.......' → x8 y6], 'o' at (12,12) [row12: '..@.##....o..c..' → x2='@', x4,5='#', x10='o', x13='c'], 'o' at (1,13) [row13: '.o..............'] → 3 hoops ✓ CP1 at (13,12)?? row12 index 13 = 'c' → center (13.5,12.5). Hmm, I wrote row 12 as '..@.##....o..c..' → positions: 0='.',1='.',2='@',3='.',4='#',5='#',6='.',7='.',8='.',9='.',10='o',11='.',12='.',13='c',14='.',15='.'. So hoop (10,12) center (10.5,12.5): from ground center 13.5 → passes 12.5 ✓. And CP1 (13,12) center 12.5 — but the surface below is y=14 (rows 14,15 solid) → the ball rolling at center 13.5: |dy| = 1.0 < 1.1 → collected while rolling ✓ (my checkpoint test is |dy| < 1.1). OK.
Screen 1: row7 '.........o......' → hoop (16+9=25, 7)! center 7.5 — too high from the ground (apex 10.5, need ≤ 8.52). Not reachable from the ground; the block at rel 8,9 rows 8-9 (abs 24,25) has surface y=8, standing center 7.5, apex 4.5 → passes 7.5 ✓ (it's right above the block at (25,7)... the block spans abs x24,25 at rows 8,9 → standing on it at center (24.5 or 25.5, 7.5). The hoop at (25,7) center (25.5,7.5) → collected while STANDING on the block ✓ (dist 0). ✓ good.
row11 '.......o........' → hoop (16+7=23, 11) center 11.5 ✓ from ground (apex 10.5 passes 11.5 ✓).
So screen 1 has 2 hoops: (25,7), (23,11).
Screen 2: row7 '.............o.*' → hoop (32+13=45,7) and crystal (47,7). Row 7 hoop at (45,7) center 8.5 — above what? The block at rel 4,5,6 rows 9,10 (abs 36,37,38) surface y=9. Hoop at (45,7) is at the crystal ledge area (the ledge at abs 46-47 rows 7-9 in my design)... but in maps.mjs screen 2 I didn't include the ledge! Let me re-read my maps.mjs level 1 screen 2:
```
row7:  '.............o.*'      hoop (45,7), crystal (47,7)
row9:  '....###.........'      block abs 36-38
row10: '....###.........'
row12: '..o......o......'      hoops (34,12), (41,12)
row14: '###^^^####^^####'
```
So there's no ledge under the crystal — the crystal at (47,7) center 8.5 requires center ≤ 8.52 from... the ground apex is 10.5 ✗; from the block at abs 36-38 (surface y=9, standing center 8.5, apex 5.5) → but that's 8 tiles horizontally away; the ball bounces from the block: at the apex, x = 38.5 + s*1.044; at speed 1 → 39.5, at speed 2 → 40.6. To reach x=47.5 at a center y ≤ 8.52 the ball needs t ∈ [0.612, 1.476] and dx = 9 → s ∈ [6.1, 14.7] → s max is 6 → at s=6, t=1.5 → just outside the window (cy=10.5 > 8.52). ✗ Not reachable.

So I need to fix: either add the crystal ledge (columns 46-47 rows 7-9... wait, in my design the crystal ledge was at surface row 10 with the crystal at row 9). Let me put the crystal ledge in screen 2: columns abs 46,47 (rel 14,15) solid rows 10..15 → surface y=10, and the crystal at (47,9) center 9.5 — hmm, from the ground (apex 10.5, need ≤ 10.52 → the ball's center reaches 10.5, distance 1.0 ✓ < 1.02) — reachable from the ground by a lucky bounce next to the ledge! Marginal. Let me raise the ledge: solid rows 9..15 at rel 14,15 → surface y=9 (5 above the ground) — not climbable from the ground (max 3) ✓; crystal at (47,8) center 8.5: from the ground apex 10.5 → distance 2.0 ✗ not reachable ✓. Is the ledge itself reachable? Its surface y=9 needs center ≤ 8.5; from the block abs 36-38 (surface 9, standing center 8.5): bounce apex center 5.5, window center ≤ 8.5 is t ∈ [0.357, 1.687] → dx = 46.48-38.5 = 7.98 → s ∈ [4.73, 22] → at s ≈ 5-6 ✓ possible. Hmm, that's a long jump requiring near-max speed — for level 1, too demanding. Let me instead design level 1's crystal detour as the simple staircase I

Good: full bounce airtime 1.044 s → 6.27 tiles at max speed. Pad: 1.477 s → 8.86 tiles.

Now write tools/maps.mjs with all four levels.

Wait, several problems:
1. Level 2 screens have wrong row counts? Screen 1 of L2: I listed 17 rows? Let me count: 
```
'................', x? 
```
L2 screen 1: I wrote rows: 11 dots rows then '.....o..........' then '.' then '############^^##' then '################' then '################' → let me count the lines: 
1 '................',
2 '................',
3 '................',
4 '................',
5 '................',
6 '................',
7 '................',
8 '................',
9 '................',
10 '................',
11 '................',
12 '.....o..........',
13 '................',
14 '############^^##',
15 '################',
16 '################',
That's 16 ✓ but the spike is on the 14th line = y13, not y14! Because the 16 lines are y0..y15 and I placed '############^^##' as line 14 = y13. Let me recount: line 1 = y0 ... line 16 = y15. My spike row was intended as y14 → line 15. In the text above, after '.....o..........' (y11) and '................' (y12), comes '############^^##' (y13), then '################' (y14), '################' (y15) → that's 3 more lines after y11: y12, y13, y14, y15 = 4 lines. So total = 12 + 4 = 16 ✓ and the spikes land on y13 = surface spikes with solid y14 below ✓ Actually that's the "surface spike" variant, which is fine (lethal to rolling). Hmm, but it's ambiguous. Let me make sure the checker verifies bottom-row solidity.

The checker will tell me about row-length problems. Let me also verify the L4 count (7 screens = 112 rows).

Rather than eyeballing, run the checker. Let me update check.mjs to import from maps.mjs (not game.js) for now.

The import is at line 82 which is fine (imports are hoisted). Let me move it to the top for clarity and run.

Bug in check.mjs: my `parse` indexes `g[X*H + y]` but reads rows with `rows.forEach((row,k) => { s = floor(k/H), y = k%H })` — that's right, but the entity collection uses `ents[ch]` where ch is the char, and I index `X = s*S + x`. The width is computed as `rows.length * S` = 64*16 = 1024 — wrong: rows.length is the number of ROW lines (64 for level 1), so W should be (rows.length/16)*16 = 64. Let me fix: W = Math.ceil(rows.length/H)*S.

Also spawn/hoop coordinates printed are wrong (hoop at 8,6 listed... the print shows hoops "8,6 1,13 20,12 30,12 26,13 42,10 34,12 41,12" — hmm 20,12 and 30,12 don't match my map. Because with W wrong, X = s*S+x is fine... let me recompute: level 1 screen 0 row12 '..@.##....o..c..' hmm wait, in my current maps.mjs level 1 screen 0 row 12 is '..@.##..........'? Let me look: 

L1 screen 0:
row12 = '..@.##..........'? No — I wrote:
```
'......##........',   y10
'......##........',   y11
'..@.##..........',   y12
'.o..........c...',   y13
```
Hmm, so CP1 is at (12,13) ✓ and the hoop at (1,13) ✓, spawn (2,12) ✓. But the printed hoops for level 1 include (20,12),(30,12),(26,13),(42,10) — those come from the checker indexing: it says spawn 0 and crystal 0 too — the '@' wasn't found?! and it lists 8 hoops. The problem: `ents[ch]` — for '@' the key exists (at). Hmm "spawn (empty)" means '@' wasn't found... and the hoops listed are 8 rather than 6.

Ah, I see the bug: `rows.forEach((row,k) => {...})` — I compute `s = Math.floor(k / H)` and `y = k % H`, then `const X = s * S + x;` — with S=16, H=16, X = 16*floor(k/16)+x ✓ correct. And the printed values... 8 hoops: (8,6) ✓, (1,13) ✓, (20,12)? screen1 (k=28 → s=1,y=12) row '....o.........o.' → x4='o' → X=16+4=20 ✓ that's the hoop I intended at (20,12) ✓ (I mis-remembered; in the new maps.mjs I put '....o.........o.' at y12 of screen 1 → hoops (20,12) and (30,12)), then (26,13)? screen1 y13 = '..........o.....' → x10 → X=26 ✓. So screen 1 has FOUR hoops: (20,12),(30,12),(26,13) and (25,7)? no — screen 1's y8,y9 rows are '........###.....' (no hoop). So screen 0: 2 hoops ((8,6),(1,13)); screen 1: 4 hoops; screen 2: (42,10),(34,12),(41,12) = 3; screen 3: 0. Total 8 and no crystal/spawn.

I wrote these maps hastily. Let me rewrite them carefully, and better: build them programmatically in the tool so structure (floors) is guaranteed, then place entities by explicit coordinates. That is much less error-prone than hand-drawing 64-row strings.

New plan: tools/build.mjs constructs each level from a small DSL:
- start with a blank 16-tall grid of '.'
- for each level: define ground segments as {x0,x1,top} where top = surface row (e.g. 14 means rows 14,15 solid); fill rows top..15 with '#'.
- define raised blocks as rectangles {x0,x1,y0} → fill y0..15 with '#'? A raised block from surface y0 down to 15.
- spikes: fill spikes over gap columns at the gap floor row.
- entities placed by (x,y).
- then dump to strings, run the checker, and print the ASCII art for review.

This guarantees the width, no bottomless columns, and I can assert counts. Then port the generated strings into game.js.

Let me write build.mjs with the four levels' geometry, print the maps, and validate. I'll iterate on the numbers until the solver passes.

Let me define helper API:
```js
function mk(width) -> grid
function fillRect(g,x0,x1,y0,y1,ch)
function ground(g,x0,x1,top)   // fillRect(x0,x1,top,15,'#')
function gapSpike(g,x0,x1,floorTop) // spikes at row floorTop, solid below floorTop+1..15
```
Level 1 (64 wide):
ground(0,63,14) — full floor.
Then gaps: for each pit, set rows 14 at those columns to '^' (keeping row 15 solid).
Pits: L1: [5,6], [20,21], [28,29], [35,37], [43,44], [52,53], [61,62].
Raised blocks (surfaces):
- staircase screen 0: ground(4,5,12) → i.e. fillRect(4,5,12,13,'#') so surface y=12 and rows 14,15 already solid. Then ground(6,7,10), ground(8,9,8).
- screen1: block(24,25,8); block(36,38,9)
- screen2: block(45,47,10) [crystal ledge]; block(48,49,12)?
- screen3: block(54,55,10); block(58,60,4)
Wait, but blocks are in specific screens. Let me recompute with x coordinates directly (0-63):
- S0 (0-15): staircase at (4,5,12), (6,7,10), (8,9,8). Spawn (2,12)→'@' at (2,13) (the tile above the floor y=14 surface → the '@' tile is y=13, giving center 13.5 ✓ resting on the floor). Hmm, careful: in my parse, '@' at (x,y) → spawn center = (x+0.5, y+0.5). For the ball to rest on the surface y=14 (center 13.5), '@' must be at y=13 ✓.
- hoops: (1,13) rolling; (8,6) [above the x8-9 block whose surface is y=8, standing center 7.5 → the hoop center (8.5,6.5) is 1 above → collected while standing? dist 1.0 <1.02 ✓ collected when standing at x=8.5; also collected mid-bounce]. Let me instead put it at (8,5) → center 5.5: from standing center 7.5 → dist 2.0 ✗; requires a bounce from the block (apex center 4.5 → passes 5.5 ✓). Good, more interesting: hoop at (8,5). Hmm, but must ensure it's reachable: the ball standing on the block (center 7.5) bounces → its center passes 5.5 ✓ yes.
  Hmm, careful: the ball must not hit the block's edge... it's standing on the block ✓ fine.
- (10,12) → center 12.5 ✓ bounce from ground. Wait the block at (8,9,8) has rows 8..13 solid → so at x=8,9,10..15 the floor is at y=14. A hoop at (10,12) is above the ground at surface 14 ✓ bounce ✓.
- CP1 at (12,13) center 13.5 ✓ rolling.
- S1 (16-31): block(24,25,8) → fillRect(24,25,8,13). Hoop (25,7) center (25.5,7.5): standing on the block (surface 8) center 7.5 → dist 0 ✓ collected standing. Hmm, that's trivially collected when landing on the block — fine and clear.
  Actually, better: hoop at (25,6) center 6.5 → from standing center 7.5: dist 1.0 ✓ collected standing (marginal). Let me keep (25,7) → collected on arrival ✓ satisfying.
- Hoop (23,11) center 11.5 ✓ bounce from ground (surface 14).
- S2 (32-47): block(36,38,9) → surface y=9 (5 above ground: NOT climbable directly ✓), reachable via 2 hops from the block (24,25,8)? The block (24,25) has surface 8 and standing center 7.5; the block (36,38) surface 9 → resting center 8.5, which is 1 BELOW 7.5 → the ball can jump from the higher block to the lower one, gap from x=25.5 to x=35.5 = 10 tiles. Full bounce airtime 1.044 s → needs speed 9.6 ✗ impossible. 
  So (36,38,9) is unreachable. Fix: make it lower or add a step. Let me design the crystal detour instead:
  - step at (34,35,12) → surface y=12 (2 above ground ✓ climbable)
  - block at (37,38,10) → surface y=10 (2 above the step ✓ reachable: from the step's standing center 11.5 → apex 8.5 → needs ≤ 9.52 ✓ with dx = 37.5-35.5 = 2 tiles: window center ≤ 9.52 is t ∈ [0.357,1.687]; at speed 1.19..5.6 ✓ generous).
  - crystal at (38,8) center 8.5: from the block (37,38) standing center 9.5 → dist 1.0 ✓ collected standing... let me put the crystal at (38,7) → center 7.5: standing center 9.5 → dist 2 ✗; requires a bounce from the block (apex center 6.5 → passes 7.5 ✓) ✓ nice: "high ledge + bounce".
    Clearance above (37,38) rows 5..9 must be empty ✓.
- Hoops in screen 2: (34,12) center 12.5 ✓ bounce; (41,12) center 12.5 ✓ bounce.
- S3 (48-63): block(54,55,10) surface 10; reachable? from ground center 13.5, need ≤ 9.52 ✗. Add a step: block(51,52,12) → surface 12 ✓ then (54,55,10) reachable from the step ✓ (dx from 52.5 to 53.5 → 1 tile; window generous ✓).
  Hmm, the gap between the step at 51-52 and the block at 54-55: at x=53 the floor is at y=14 (ground) → so the ball can hop from the step to the ground at 53 and then to the block (54,55) from the ground? From the ground (center 13.5) it can't reach the block's surface 10 (needs ≤ 9.52). So it must go from the step (51,52) directly to the block (54,55): dx = 53.5 - 52.5 = 1 (landing at x ≥ 54-0.48+... its center must be ≥ 53.52 to be over the block's first tile? For the ball to land on the tile x=54 with surface y=10, its center must be within [54-0.48, 55+0.48] roughly and cy ≤ 9.52 ✓. From the step standing at center 52.5, a bounce: at t=0.357 (window start) x = 52.5+s*0.357; at speed 3 → 53.6 ✓ lands ✓ fine.
- Hoop (58,13)? The exit is at x57. Let me finalize screen 3:
  - CP2 at (50,13) → center 13.5 rolling ✓ (before the climb + exit run)
  - hoop: the 6th hoop. Let me recount hoops: (1,13), (8,5), (10,12), (25,7), (23,11), (34,12) = 6 already, plus (41,12) = 7. I need exactly 6 total. Let me choose:
    H1 (1,13) — rolling, tutorial
    H2 (8,5) — requires the staircase (detour-ish but on the path? The staircase isn't required... Hmm! All 6 hoops must be on the critical path = must be reachable without optional detours... "the six hoops sit on the critical path" means they're along the way, not hidden in optional spots (in contrast to the crystal). A hoop above a staircase that the player need not climb is technically a detour. But that's fine and typical; the strict reading: the 6 hoops must be collectible in the course of completing the level; the crystal is the only one that requires a deliberate detour. To be safe, make hoops all reachable along the main corridor (some require a bounce in place).
    So: put hoops at heights ≤ 3 above the main walking surface, except where the main route itself goes up (e.g., over a block).
    Final L1 hoops:
    H1 (1,13) rolling ✓
    H2 (10,12) bounce ✓
    H3 (23,11) bounce ✓  (over the ground)
    H4 (25,7) — above the block (24,25,8) → requires climbing the block; the block is 2 wide; is it on the critical path? The player can just bounce over it. Hmm, "critical path" — let me interpret loosely: hoops are placed in the level's main play area (not requiring an optional detour structure). A hoop on top of a raised block in the middle of the corridor is fine (the corridor passes by it).
    Actually simplest defensible design: put hoops in a line along the route, at heights requiring rolls and bounces, plus 1-2 on raised blocks the route passes.
    H5 (41,12) bounce ✓
    H6 (58,13)? — hmm, near the exit; the exit is at (57,13). Let me put H6 at (54,9) → on the block (54,55,10) surface → standing center 9.5, hoop center 9.5 ✓ collected on the block. And the block (54,55) is climbed via the step (51,52) — a short climb near the exit.
    So 6 hoops: (1,13), (10,12), (23,11), (25,7), (41,12), (54,9).
    Hmm, is (10,12) needed vs (8,5)? Fine.
  - Wait, I removed the staircase (4,5,12),(6,7,10),(8,9,8) → then nothing uses it. Let me keep a light staircase in screen 0 for the "climb for a hoop" feel? With only 6 hoops I'd rather keep the structure but no hoop on it. Hmm. Let me put H2 on the staircase: H2 = (8,6) center 6.5: standing on the block (8,9,8) center 7.5 → dist 1.0 ✓ collected standing on the staircase top. The staircase (4,5,12),(6,7,10),(8,9,8) is a detour though...
    Decision: I'll make the staircase part of the route to H2 and keep it: the level is gentle, and having to climb for a hoop is a puzzle-platformer staple. But the requirement says hoops are on the critical path and the crystal is the detour. A staircase is not really a "detour" if the hoop is up there — the hoop defines the path. Fine.
    So L1 hoops: H1 (1,13), H2 (8,6), H3 (23,11), H4 (25,7)?? — hmm (8,6) and (25,7) both above blocks. Let me finalize:
    H1 (1,13)   roll
    H2 (8,6)    staircase (bounce from the top block)
    H3 (13,11)  bounce from ground (screen 0)
    H4 (25,7)   on the block (24,25,8)
    H5 (41,12)  bounce from ground
    H6 (54,9)   on the block (54,55,10), reached via the step (51,52,12)
    And the crystal (38,7) on the block (37,38,10) reached via the step (34,35,12) ✓ a deliberate detour ✓.
    And CP1 (12,13), CP2 (50,13), door (57,13).
  Level 1 geometry:
   - ground surface 14 for x0..63, with spike pits at [5,6],[20,21],[28,29],[35,37],[43,44],[52,53],[61,62]... but wait: the step (51,52,12) overlaps the pit at [52,53]! Conflict. Let me put the pits at: [5,6], [20,21], [28,29], [35,37], [43,44], [61,62]. And near the exit: [56,57]? No, the door is at 57. Pits: [5,6],[20,21],[28,29],[35,37],[43,44],[47,48],[61,62].
   Careful: the pit at [35,37] is right where the step (34,35,12) is → conflict. Let me re-place structures & pits to avoid overlap:
   
   x ranges: 0-15 screen0, 16-31 screen1, 32-47 screen2, 48-63 screen3.
   Structures:
     S0: staircase at x4-5 (top 12), x6-7 (top 10), x8-9 (top 8)
     S1: block x24-25 (top 8)
     S2: step x34-35 (top 12), block x37-38 (top 10)
     S3: step x51-52 (top 12), block x54-55 (top 10), door pillar x60-63 (top 12) [door at x62]
   Pits (2-3 wide, in the y=14 floor):
     [2,3]? no — the spawn is at x2. Pits: [6,7]? conflicts with the staircase. 
     Let me use: [11,12], [19,20], [28,29], [41,42], [45,46], [57,58].
     Spacing: 11-12 then 19-20 → 6 clear tiles ✓; 20→28 = 7 clear ✓; 29→41 = 11 clear ✓; 42→45 = 2 clear tiles (hmm, tight: after crossing the pit at 41-42 the player lands ~43-44 then immediately must jump 45-46. 2 tiles is a bit tight but the ball at speed lands past the pit and can jump again... Let me space: [41,42] and [47,48] → 4 clear ✓. But x47-48 must be clear of structures ✓.
     So pits: [11,12], [19,20], [28,29], [41,42], [47,48], [57,58].
     Note x57-58 is right before the door pillar at x60 → 1 tile gap at x59 between the pit (ends 58) and the pillar (starts 60). Landing after the pit at x59.5 (center) with the pillar wall at x60 → the ball's right edge 59.98 → just fits. Hmm, risky. Move the pit to [56,57] and the pillar starts at x60 → 2 clear tiles (58,59) ✓. And the door at x62 on top of the pillar (surface 12) → the door tiles (62,11),(62,12) ✓ (base at y=12).
     Hmm, the door base at y=12 means the marker is at (62,12) with the floor at (62,13) ✓.
     Let me double check the pillar: ground(60,63,12) → fillRect(60,63,12,13) → surface y=12 ✓. The door 'E' at (62,12)? The door's bottom tile must be the tile just above the floor: the floor surface is y=12 (top of rows 12..15 solid) → the door occupies (62,11) and (62,10)? Careful: for a surface at row S (rows S..15 solid), the ball rests with center S-0.5 and the tile directly above the surface is row S-1. So the door's bottom tile = row S-1 = 11, and the top tile = 10. So the 'E' marker goes at (62,11) = S-1. My checker requires the 'E' tile's floor below to be solid ✓ (62,12) is solid ✓ and (62,10) must be clear ✓.
     
     Hmm, wait: in the earlier maps the door was at y=13 with floor rows 14,15 → marker at 14-1 = 13 ✓ consistent.

Let me now also reconsider: do I want the exit on a raised pillar for L1? It adds a climb with 3-tile walls. Simpler for the gentlest level: the exit on the flat ground at x=62 (surface 14, marker at (62,13)) with spikes just before it ([57,58] pit) ✓ done. Then no pillar needed for L1.

Level 1 final structures: staircase x4-9; block x24-25 (top 8); step x34-35 (top 12) + block x37-38 (top 10); step x51-52 (top 12) + block x54-55 (top 10). Door (62,13). Pits [11,12],[19,20],[28,29],[41,42],[47,48],[57,58].
Hoop H6 at (54,9): standing on the block (54,55) surface 10 → center 9.5 ✓ dist 0.
Crystal (38,7): block (37,38) top 10 → standing center 9.5 → needs a bounce (apex 6.5) → passes 7.5 ✓.
CP1 (12,13) — hmm, x12 is inside the pit [11,12]! Move CP1 to (14,13). And CP2 to (49,13)? x49 is after the pit [47,48] ✓. Let me place CP1 (15,13) and CP2 (50,13).

Also H3 (13,11) — near CP1 at (15,13) ✓ fine. But x13 is between the pit [11,12] and CP1: the hoop at (13,11) requires a bounce from the ground; the ground at x=13 is solid (surface 14) with 1 clear tile after the pit (x13 is right after the pit ends at 12) → the ball landing after the pit lands at ~13.5 and can bounce ✓ OK but tight-ish. Let me move H3 to (16,12).

I'll stop hand-wiggling and let the solver verify. Writing build.mjs now.

Level 2 (80 wide, 5 screens) — geometry:
- ground surface 14 all x0-79 as the base, with a raised high road.
- Screen 0: spawn (2,13); pads '=' at (5,13),(6,13) (1-tall pedestals: the pad tile at row 13 = 1 tile above the floor surface 14 ✓ so the pad's top surface is y=13); hoops (1,13) roll, (9,12) bounce; CP1 (13,13).
- Screen 1: pits [19,20,21] (3 wide) and [27,28,29] (3 wide); hoops (17,13) roll?? hmm x17 is right after the spawn screen. Let me put hoop (23,12) (bounce, on the clear floor between the pits? x22 is the only clear tile between the pits (21 ends, 27 starts) → no. Space the pits: [19,20,21] and [28,29,30]; clear floor x22-27 ✓ 5 tiles.
  Hoop (24,11) → bounce from the ground x24 ✓.
  Also a teaching-free area ✓.
- Screen 2 (x32-47): CP2 at (33,13); the critical pad pedestal at (43,13),(44,13),(45,13) → surface y=13; the high road from screen 3: block x48-... Let me put the high road in screens 3-4: block x48-59 with surface y=9 (fill rows 9..13) → the wall face at x=48 is 5 tiles above the ground surface 14 → not climbable from the ground ✓ pad required.
  From the pad standing center (43.5..45.5, 12.5): pad rise 6 → apex center 6.5; the landing on the high road needs center ≤ 8.5 (surface 9) → window t ∈ [0.31, 1.17]; dx = 48.48-45.5 = 3 → at speed 2.56..9.6 ✓ generous at typical speeds. ✓
- Screen 3 (x48-63): the high road x48-59 (surface 9); then x60-63: what? Let me put a descent: x60-63 ground surface 14 (so the high road ends and drops 5 tiles to the ground — safe ✓).
  Hoops on the high road: (51,8) → center 8.5 = standing center on the high road ✓ collected rolling ✓. 
  Then the pad at x=57,58 on the high road? For level 2, we need the second pad maybe optional. Let me include one pad on the high road at (56,9) (a 1-tall pad tile on the high road surface) — optional fun (launches to apex center 2.5 → could reach a ledge at y=5 in screen 4 for... nothing. Skip; keep just one pad in L2 (the critical one) — spec requires "at least one on the critical path" ✓.
  Hmm, but level 2 should feel like "the pad level". I'll add a second pad in screen 4 that's needed to reach the exit area? Let me design screen 4:
- Screen 4 (x64-79): ground surface 14; pit [66,67,68,69] (4 wide) — hmm, the ball arrives on the high road (x48-59) and drops to the ground at x60. Then the pit at 66-69 (4 wide): max normal jump = 6.27 tiles ✓ clearable at speed 6 (4-wide needs 5.04 tiles ✓) so it's fine without a pad, and forgiving-ish. Then a pad pedestal at (72,13),(73,13) launching onto the exit platform: block x74-79 surface y=9 (5 above ground) — the exit door on top at (77,8)? Then the player must use the pad to get to the exit platform ✓ second pad, and it's on the critical path ✓ nice. And a hoop at (76,8) on the exit platform ✓ and the crystal... 

Where's the crystal for L2? "off the critical path, a high ledge or side alcove". In screen 1, put a small alcove above the ground: e.g., a ledge at (24,10) → hmm. Let me place the crystal in screen 3 above the high road on a pillar: block x54-55 surface y=5 (fill rows 5..8 above the high road? The high road is solid rows 9..13, so a pillar x54-55 rows 5..8 sits on it → surface y=5. Reachable from the high road (standing center 8.5): rise needed = surface 9 → 5 = 4 tiles ✗ not climbable (max 3, tight). Make it surface y=6 (3 above the high road): standing center 8.5 → apex 5.5; landing on surface 6 needs center ≤ 6.5 → ✓ possible (window t ∈ [0.612,1.476]? no that's for a 6-tile rise. For a 3-tile rise: center ≤ 6.5 → from 8.5: 8.5-11.489t+11t² ≤ 6.5 → 11t²-11.489t+2 ≤ 0 → disc = 132-88 = 44 → t ∈ [0.221,0.823] → at speed 3-6 the dx = 0.66-4.9 tiles ✓ reachable ✓. So a pillar with surface y=6 is a 3-tile climb — allowed but tight (2 is comfortable). It's a crystal detour so tight-but-not-frame-perfect is OK. Let me use surface y=7 (2 above the high road ✓ comfortable) and put the crystal at (54,6) → center 6.5: standing on the pillar (surface 7) center 6.5 → dist 0 ✓ collected standing. ✓ 
  Hmm, but then the pillar is just a small step up; the "deliberate detour" is mild. It's fine — it requires leaving the high road, climbing, and returning.
  Wait, but there's an issue: the pillar at x54-55 rows 7-8 (surface 7) on top of the high road (surface 9) — the ball rolling on the high road at center 8.5 hits the pillar's wall (rows 7,8 = 2 tall) → must bounce onto it ✓ fine.

Level 2 final-ish:
- ground surface 14 x0-79.
- pads: (5,13),(6,13) [screen 0 teaching]; (43,13),(44,13),(45,13) [critical].
- pits (spikes at row 14): [19,20,21], [28,29,30], [66,67,68,69]? Let me check the pit at 66-69 (4 wide) with the drop from the high road at x60 — plenty of run-up ✓. Also [74,75]? no.
- blocks: high road x48-59 surface 9; exit platform x74-79 surface 9; pillar x54-55 surface 7 (on the high road).
- hoops: (1,13), (9,12), (24,11), (51,8), (58,8), (76,8) → let me check (58,8): standing on the high road (surface 9, center 8.5) → the hoop center (58.5,8.5) ✓ rolling. And (76,8): standing on the exit platform (surface 9, center 8.5) ✓.
  Hmm, two hoops that are free rolls and one at (24,11) bounce, (9,12

I left mistakes in level3/level4 (stray '@' markers, duplicate crumble/gap calls). Let me clean those two functions up now.

L3 fixes: remove the stray '@' at (67,13) lines; the door: m.block(72,79,9) then ent(m,74,8,'E') — but the door base must be at surface-1 = row 8 ✓ since the terrace surface is 9 → the door's bottom tile is (74,8) ✓. Remove the duplicate.

L4 fixes: remove the stray '@' at (72,13); the `m.gap(53,55,15,2); m.rect(53,55,14,14,'C')` duplicates — I called gap then rect twice. Order matters: `gap(x0,x1,floorTop,depth)` clears rows floorTop..floorTop+depth-1 then sets spikes at floorTop. Wait: `this.rect(x0,x1,floorTop, floorTop+depth-1, '.')` then `this.rect(x0,x1,floorTop, floorTop,'^')` → so the spike is at floorTop and the rows below are cleared. Hmm, that's wrong for a floor with surface at row `top`: for a floor whose surface is row 14 (solid rows 14,15), a gap of depth 1 means: remove the row-14 solid, put a spike at row 14 resting on row 15 ✓ → gap(51,58,14,1): clears row 14 (already solid) then puts '^' at row 14 ✓ leaves row 15 solid ✓. For depth 2 (a deeper pit): remove rows 14 and 15, and put the spike... at row 14? No — the spike should sit on the pit's floor which is now below the map. So depth 2 pits need the spike at row 15 and rows 14 cleared: gap(x0,x1, 14, 2) should clear rows 14..15 and put spikes at row 15 (the pit floor). Hmm, but then row 16 doesn't exist → the spike at row 15 has nothing solid beneath → the ball falls through the spike tile onto... the spike at row 15 (hitbox y 15.42..16.0) → the ball's center would need to reach ~15.9 to touch it; the ball would fall to y > H+4 → kill() ✓ still lethal but via the out-of-bounds kill. That's fine (the ball dies), but the spec says gaps must be floored with spikes rather than bottomless. So better: depth-2 pits keep row 15 solid and have spikes at row 14 (same as depth 1, just visually deeper? no...). 

Simplest and unambiguous: all spike gaps are depth 1: the floor rows 14,15 solid → remove row 14, place '^' at row 14 (resting on row 15). The gap is 1 tile deep with spikes filling it. ✓ Fully floored with spikes, no bottomless columns. Do that everywhere.

So `gap(x0,x1)` = clear row 14? But some gaps might be in a raised surface (e.g., a gap in a terrace at surface row 9). Let me generalize: gap(x0, x1, surfaceRow) → clears the tile at surfaceRow-1? Hmm.

Let me define semantics clearly: `floor(x0,x1,top)` fills rows top..15 with solid. A "gap" in that floor with spikes at the bottom of the gap: clear rows top..(top+depth-1)? For a floor of surface `top`, digging a hole of depth d means removing rows top..top+d-1 and the hole's floor is at row top+d (which must be solid — it is, since the floor extends to row 15, as long as top+d ≤ 15). Spikes then sit at row top+d-1 (the tile just above the hole's floor) ✓.
- For a surface at 14 with d=1: clear row 14, spikes at row 13?? No: d=1 → clear rows 14..14, hole floor = row 15 solid, spikes at row top+d-1 = 14 ✓. Yes! spikes at row 14, hole floor row 15 ✓. Correct.
- For a surface at 14 with d=2: clear rows 14,15 → hole floor = row 16 (doesn't exist) ✗. So restrict d=1 for row-14 floors. ✓

So `gap(x0,x1,top=14,depth=1)`: clear rows top..top+depth-1, spike at row top+depth-1.

Now L3's crumble crossing: I want spikes BELOW the crumble tiles so falling = death. The crumble tiles replace the floor at surface row 14 (so they're 1-tall floor tiles). To have spikes below them, the crumbles must be above the spike tiles. So the pit is deeper: the floor is solid rows 14,15 normally; at the crossing, clear rows 14 (and 15? can't) → so we can't have spikes below a 14-surface crumble.

Alternative: make the crossing floor higher: the crossing is at surface row 13 (i.e., there's a solid base rows 13,14,15 normally at those columns). Then a gap = clear rows 13,14 with spikes at row 14 (resting on row 15) ✓ and the crumble tiles at row 13 (the surface) ✓ spanning the spike tops. So the ball walks at surface y=13 there; falling through a crumble drops it into the spike at row 14 ✓ (lethal). 

Hmm, but then the crossing surface (13) differs from the surrounding floor (14). Simple fix: build the whole L3 crossing region (and the platforms leading to it) at surface 13. Or: for the crossing region, raise the ground by 1 tile: ground(x0,x1,13) for the crossing stretch, with the transitions being 1-tile steps ✓ natural.

Let me restructure L3's crossing: a raised stretch x49..60 with surface 13 (rows 13,14,15 solid). Within it, a pit x52..57: clear rows 13,14, spikes at row 14 (on solid row 15), and crumble tiles at row 13 covering x52..57? If the crumbles span the whole pit, the ball must cross 6 tiles — too long. Let me make the pit x52..55 (4 wide, spikes at row 14) with crumble tiles at row 13 at x52,x53 and x54,x55, and a solid (non-crumble) platform at x54? Hmm.

Simpler: pit x51..56 (6 columns) with crumbles at x51,52 and x55,56 and SOLID tiles at x53,54 at row 13? Then the crossing = crumble, solid, crumble. Hmm.

Cleanest: 3 crumbles with a solid step:
- raised stretch x48..62 surface 13.
- pit: x52..57, spikes at row 14, no solid at row 13 EXCEPT crumbles at x52, x54, x56 (3 crumbles, with gaps of 1 between: x53, x55 are open spikes).
  The ball must bounce from the platform edge (x51 → center 51.5) onto the crumble at x52 (center 52.5) → 1 tile hop ✓; then x52 → x54 (2 tiles) ✓; then x54 → x56 ✓; then x56 → the platform at x57+ ✓. Each hop is small (2 tiles) so it's doable at low speed ✓ and the crumbles expire 0.5 s after landing — each hop at low speed takes ~0.4-0.5 s ✓ doable but the player must keep moving ✓ exciting.
  Is it fair? The first hop from x51 to x52 (1 tile) then the crumble starts crumbling on landing; the player has 0.5 s to hop to x54 (2 tiles): a bounce's up-phase is ~0.5 s and at speed 4-6 they cover 2.5-3.5 tiles in 0.5 s ✓. So the player should hold right and bounce immediately. Good, and there's a 1-tile-wide spike gap between (x53) so a failed hop = death.
  Hmm, "Nothing frame-perfect" — 0.5 s reaction isn't frame-perfect but it IS timing-critical. To be safer, make the crumbles not instantly start their countdown? The spec says ~0.5 s after the ball first lands. Alternatively widen the crumble tiles: crumbles 2 wide at x52-53, then a solid platform at x54-55 (surface 13), then crumbles at x56-57, over spikes. So the sequence: platform x48-51 → hop 2 tiles onto crumble x52-53 (2 wide, so a generous landing) → hop from x53.5 to the solid x54-55 (just 1 tile!) ✓ very easy → then hop onto crumble x56-57 → then hop to the platform x58+. Each crumble landing gives 0.5 s, and the next hop is 1-2 tiles = ~0.2-0.3 s at low speed ✓ plenty of margin. 
  That's a proper critical-path crumble crossing that's forgiving. Let me use that.
  Also "Collapsing must never make a level unwinnable": the crumbles regenerate in 3 s ✓ and the intermediate solid platform at x54-55 means the ball is never stranded ✓.

L4's crumble crossings: same pattern (2-wide crumble + solid island + 2-wide crumble) over spike pits, with the pit at the right depth.

So general pattern: for a crossing at surface row T with spikes below: build a raised strip with surface T (rows T..15 solid), then dig the pit: clear rows T..14? Let's define: pit from x0..x1 with spikes at row 14: clear rows T..13 (the solid above the spike row), spikes at row 14, row 15 solid ✓. Then crumble tiles at row T (surface) over the pit, plus a solid island column at row T.

Let me define a builder helper: `crossing(x0, x1, T, crumbleCols, solidCols)`:
 - ground(x0, x1, 15) → i.e. only row 15 solid (so row 14 is empty above it? no...). Hmm.

Let me be concrete: I'll build the level with ground surface 14 everywhere (rows 14,15 solid), and make crossings by raising a strip to surface 13.

Helper: `crumbleCross(x0, x1, spec)` where the strip x0..x1 has surface 13 and within it a spike pit at [px0..px1] (clear rows 13, spikes at 14) plus crumble tiles at row 13 at the given columns and solid tiles at row 13 at the island columns.

Implementation:
```
strip(x0,x1,13)          // rows 13,14,15 solid
pit(px0,px1)             // clear row 13 over px0..px1, spike at row 14
then set row 13 tiles: 'C' at crumble cols, '#' at island cols
```
✓ 

Now transitions from surface 14 to surface 13 = a 1-tile step up ✓ trivial.

Let me rewrite levels 3 and 4 with these helpers. Also note the crumble tiles at row 13 with spikes at row 14: when the crumble collapses, the ball standing at center 12.5 falls; the spike at row 14 has hitbox y 14.42..15.0 → the ball falls through and dies when its center reaches ~13.94 (dist to 14.42 < 0.48) ✓ lethal.

Also when the crumble regenerates (row 13 solid again) while the ball is standing in the pit... it would be embedded in the crumble tile → my isSolid would push it? My collision code only resolves on movement; if the ball is in the pit (it's dead by then) fine. Edge case: the ball could be in the pit region below a regenerating crumble only if it's alive, which can't happen (falling = death). OK.

Let me rewrite build.mjs levels 3 & 4, and fix `gap`.

L4 layout (96 wide, 6 screens). Let me design it as a coherent side view:

Base ground surface 14 across x0..95.

Screen 0 (x0-15): safe-ish start.
- spawn (2,13); hoop (1,13); pad pedestal (6,13),(7,13) [teaching]; hoop (10,12); terrace block x12..15 surface 11 (3 above ground: hmm 3 is tight). Use surface 12 (2 above) ✓ climbable from the ground; hoop (14,11) center 11.5 = standing on the terrace (center 11.5) ✓ collected on arrival.
  Hmm, is a surface-12 terrace climbable in one bounce from the ground? Yes (2 tiles) ✓.
- CP1 at (16? ) let me put CP1 at (15,11) on the terrace? Then CP1 is early. Fine: CP1 (15,11).
  Wait, the terrace x12-15 surface 12 → the tile above the surface is row 11 → CP at (15,11) center (15.5,11.5) ✓.

Screen 1 (x16-31): spike beds, hoops.
- pits: [19,20,21] (3 wide), [27,28,29] (3 wide).
- hoops: (23,11) bounce, (31,13)? 
- CP2 at (30,13)?? Hmm CP2 should be in front of the level's second hard stretch (the crumble gauntlet). Let me put CP2 at (31,13).

Screen 2 (x32-47): pad launch + crystal detour.
- pad pedestal (35,13),(36,13),(37,13) [surface 13]
- big pit x39..44 with spikes (surface-14 gap of 6 wide) → the pad launch carries the ball over: from standing center 13.5 (on the pad surface 13? no: the pad surface is row 13 → standing center 12.5) → pad apex center 6.5; landing beyond the pit at surface 14 (center 13.5): the ball descends to center 13.5 at t: 12.5-16.248t+11t² = 13.5 → 11t² - 16.248t - 1 = 0 → t = (16.248 + sqrt(264+44))/22 = (16.248+17.55)/22 = 1.536 s → at speed 6 dx = 9.2 → lands at x = 36.5+9.2 = 45.7 ✓ beyond the pit (ends x44) ✓. At speed 4: dx = 6.1 → x = 42.6 → lands in the pit ✗ dies. So the pad crossing needs speed ≥ ~5.2. Hmm, that's a "must be at speed" constraint. Fix: make the pad pedestal closer to the pit or make the pit narrower (4 wide): pad at 35-37 (center up to 37.5), pit x39-42: the ball must land at x ≥ 42.52 with cy ≤ 13.5: dx from 37.5 = 5 tiles → t = 5/s; need t ≤ 1.536 → s ≥ 3.25 ✓ and no upper bound issue (the far side is wide) ✓. So a 4-wide pit from a 3-wide pad. Also the ball can approach the pad at speed and land on the pad while bouncing (rolling onto the pad top requires stopping or bouncing). Hmm, if the ball is moving fast it may overshoot the pad (8.86 tiles per pad bounce!). Wait, it lands on the pad first (the pad's top surface is at 13, and the ball approaching at surface 14 bounces up 3 and comes down onto the pad top (1 tile up) → it lands on the pad which launches 6 ✓ regardless. If the ball rolls onto the pad without bouncing (its center 13.5 hits the pad's left wall at rows 13) → blocked, stops ✓ then bounce.
- After the big pit: ground surface 14, spike pit, hoop (46,12)?
- Crystal: a detour. Place it high: the ball standing on the pad at (36,13) center 12.5 → apex 6.5 → a crystal at (36,7) center 7.5 ✓ caught straight up. But that's on the critical path (auto-caught on the pad launch). Put it elsewhere: screen 2 side alcove: a raised pocket: block x45-46 surface 10 (4 above ground ✗ not climbable) — the crystal should be reachable but optional: block x45-46 surface 12 (2 above) then block x48-49 surface 10 (2 above that) → crystal at (49,7) center 7.5: standing at center 9.5 (surface 10) → bounce apex 6.5 → passes 7.5 ✓. So the crystal needs 2 climbs + a bounce ✓ a deliberate detour ✓.

Screen 3 (x48-63): hmm, x48-49 now used by the crystal block. Let me reorganize the x budget: 96 tiles = 6 screens. Let me plan the sequence:
 0-15: safe start + terrace + CP1
 16-31: spike beds + CP2 (at x31)
 32-47: pad launch over a 4-wide pit; crystal detour (steps at x41-42 surface 12, x44-45 surface 10, crystal (45,7)); hoop (43,12) hmm.
 48-63: crumble crossing #1 (critical): strip x50-63 surface 13; pit x53..58 with crumbles x53-54, island x55-56 (solid at row 13), crumbles x57-58; spike at row 14 under the pit. Hoop on the island.
 64-79: crumble crossing #2 + spikes; hoop (70,12); pit [66,67]? Let me define: strip x64-79 surface 13 continuing? Simpler: keep the strip x50-71 surface 13 (one raised region) with two crossings.
 80-95: final: pad launch onto the exit terrace + a crumble crossing.

Let me write it concretely with numbers in the builder and then let the solver validate. I'll iterate.

L4 concrete:
- ground surface 14 x0..95.
- S0: spawn (2,13); 'o' (1,13); pads (6,13),(7,13); 'o' (10,12); terrace x12-15 surface 12; 'o' (14,11); 'c' (15,11)?? Hmm the terrace is 4 wide (x12-15) so both fit.
- S1: pits [19,20,21], [27,28,29]; 'o' (23,11); 'c' (31,13) = CP2? Wait CP2 should be in front of the second hard stretch = the crumble gauntlet (x50+). ✓ CP2 at (31,13).
- S2: pads (35,13),(36,13),(37,13); pit x39-42 (4 wide); 'o' (40,11)?? — a hoop above the pit at (40,11) center 11.5: the ball crossing the pit on the pad arc passes 11.5 ✓ collected in flight. Hmm, hoops above pits are exciting but must be collectible without risk ✓ they are (the arc passes through). Let me place it at (41,10) → center 10.5: the pad arc's apex is 6.5; it passes 10.5 ✓. Fine.
  Hmm, risky for the solver to find? It'll be fine.
  Let me put 'o' at (44,12) (after the pit, bounce) instead — safer. And the crystal detour: steps x45-46 surface 12, x47-48 surface 10, crystal (48,7).
  Hmm, x47-48 is in screen 2/3 boundary. Fine.
- S3 (48-63): the raised strip x50-71 surface 13 — wait, the crystal block at x47-48 has surface 10; adjacent to the strip's surface 13 → fine.
  Let me set: strip x50..71 surface 13 (solid rows 13,14,15).
  Crossing A: pit x54..59: clear row 13 at x54-59, spikes at row 14 x54-59; crumbles at row 13: x54,x55 and x58,x59; island solid at row 13: x56,x57.
  'o' at (56,12) on the island (center 12.5; standing on the island surface 13 → center 12.5 ✓ collected standing).
- S4 (64-79): Crossing B: pit x66..71: crumbles x66,x67; island x68,x69 (row 13 solid); crumbles x70,x71. 'o' at (68,12)? Two hoops on islands might be too easy; fine.
  Then the strip ends at x71 → after x71 the ground drops to surface 14 at x72-79 (1-tile drop ✓).
  Hmm, I need a hoop count: (1,13), (10,12), (14,11), (23,11), (44,12), (56,12) = 6 ✓ and 'o' at (68,12) would be a 7th. So skip that one. Let me instead place the 6 hoops as: (1,13), (10,12), (14,11), (23,11), (44,12), (56,12). Then the last stretch (x72-95) has no hoop ✓ fine (the exit is there).
  Hmm, but "In each level the six hoops sit on the critical path" ✓ they do.
- S5 (80-95): the finale: 
  - the ground surface 14 from x72..79; a spike pit [75,76,77]; then the pad at (81,13),(82,13),(83,13) launching onto the exit terrace x86..95 surface 9 (5 above ground; needs the pad ✓ 6-tile launch) — the pad standing center (82.5,12.5) → apex center 6.5; landing on surface 9 needs center ≤ 8.5 ✓ window t ∈ [0.31,1.17]; dx from 83.5 to 85.52 = 2 tiles → speeds 1.7-6.4 ✓ generous ✓.
  - and a crumble crossing on the terrace before the door: strip x86-95 surface 9 (rows 9..15 solid); pit x89..92: clear rows 9..13?? that's deep; spikes must be at the pit floor. For a surface-9 strip, a pit = clear rows 9..13 with spikes at row 14 (resting on row 15 solid, which exists) ✓ wait rows 10-13 cleared, spikes at row 14, row 15 solid ✓ so the pit is 5 deep with spikes at the bottom ✓ nice and scary. Crumble tiles at row 9 (surface) with an island: crumbles x89,x90; island x91,x92 solid at row 9? Hmm, an island at row 9 requires the solid to span rows 9..? Let me build it as: the strip solid rows 9..15 across x86-95, then carve the pit: clear rows 9..13 at x89..92 and set spikes at row 14 there; then re-add crumble tiles at row 9 at x89,90 and 92,93? and leave island at x91? Hmm, the island needs to be reachable.
  
  Let me simplify the finale to reduce risk: the exit terrace x86-95 surface 9 reached by the pad; the door at (93,8); one crumble crossing on the terrace: pit x89..91 (3 wide): clear rows 9..13, spikes at row 14; crumble tiles at row 9 x89,90 and solid at row 9 x91? A solid tile at row 9 with nothing below (rows 10-13 clear) is a floating solid ✓ fine.
  So: crumbles at (89,9),(90,9) then land on the solid (91,9), then continue to the door ✓. Only one 2-wide crumble step + hop. The hop from the terrace edge x88 (center 88.5) onto the crumbles x89-90 (center ~89.5-90.5) = 1-2 tiles ✓ easy; then from x90.5 to the solid x91 (center 91.5) = 1 tile ✓ easy. So the crossing is easy going, but if you dawdle the crumbles collapse and then you must get from x88 across a 3-wide pit... hmm, after the crumbles are gone (they return after 3 s), the player standing at x88 must jump a 3-wide pit (x89-91 open above deep spikes... wait x91 is solid at row 9 so the pit is only x89,x90 = 2 wide from the terrace edge x88: the ball at center 88.52 jumping to land at center ≥ 90.52 (over the solid x91) = 2 tiles ✓ doable ✓ not stranded. 
  And if the player is ON the crumbles when they collapse → death (that's the challenge), or if they're on x91 island → safe, and from x91 they can continue right ✓ (the door is at x93) ✓ no stranding.
  
  Good. Let me also add a spike pit on the terrace approach: [85,86]? Careful. Let me keep the finale: ground surface 14 x72..85, pit [76,77,78], pad (81,13),(82,13),(83,13), terrace x86-95 surface 9, crumble crossing x89-91, door (93,8).
  Wait: the pad pedestal (81-83, row 13) sits on the ground surface 14 ✓.

Now L3 (80 wide, 5 screens):
- ground surface 14 x0..79.
- S0: spawn (2,13); 'o' (1,13); 'o' (6,12); pit [9,10,11]; 'c' (14,13) CP1.
- S1 (16-31): forgiving crumble: strip x18..24 surface 13; pit x20..23: clear row 13, spikes at row 14; crumbles at (20,13),(21,13),(22,13)? For the forgiving intro, make it 1 crumble: crumble at (21,13) 1 wide, and solid at row 13 x22,x23 → hop from x19.5 onto the crumble (center 21.5) = 2 tiles ✓ then hop to x22 (center 22.5) = 1 tile ✓ easy. 
  Hmm, the crumble at (21,13) alone with open spikes at x20 and x22? Let me define: strip x18-24 surface 13; carve pit x20-22 (clear row 13, spikes row 14); crumble at (21,13) only; then the pit is open at x20 and x22 with the crumble bridging the middle. Hmm, that's meaner (the ball must land ON the 1-wide crumble). Let me instead: crumbles at (20,13),(21,13) (2 wide) and solid row 13 at x22 → the hop from x19 (strip, center 19.5) onto the crumbles (center 20.5-21.5) = 1 tile ✓, then to x22 ✓. So crossing = 2 tiny hops. Forgiving ✓.
- S2 (32-47): 'o' (35,11); blocks/steps for the crystal: step x37-38 surface 12, block x40-41 surface 10, crystal (41,7); 'c' (46,13) CP2.
- S3 (48-63): the critical crumble crossing: strip x49..66 surface 13; pit x52..57 (clear row 13, spikes row 14); crumbles at (52,13),(53,13) then island solid row 13 at (54,13),(55,13) then crumbles at (56,13),(57,13). 'o' at (54,12) on the island ✓.
- S4 (64-79): the exit climb: 'o' (68,12)? Hmm count: (1,13), (6,12), (35,11), (54,12) = 4; need 2 more: (66,12)? Let me place 'o' (43,13)?? Let me distribute: (1,13) roll, (6,12) bounce, (25,11) bounce (screen 1, after the crumble), (35,11) bounce, (54,12) island, (70,12) bounce → 6 ✓.
- Exit: the door on a raised terrace: block x74-79 surface 11 (hmm from surface 14 → 3 tiles = tight). Use surface 12 (2 up ✓) with the door at (77,11). Then the strip x64-73 surface 14, terrace x74-79 surface 12 → 2-tile climb ✓ and the door marker at (77,11) ✓ (base (77,12) solid ✓).
  Hmm, for L3 let me make the exit require a pad? No, pads debut in L2 and L3 has crumbles. Fine: the exit on a terrace reachable by a 2-tile hop.

Also I should double check "each level opens with a safe stretch": L3's screen 0 has a pit at [9,10,11] — the first 8 tiles are safe ✓. L4's screen 0 has no pit ✓. 

OK now, importantly: does L3's screen 0 have the "first crumble introduced somewhere forgiving before it matters"? The first crumble is in screen 1 ✓ forgiving ✓.

Let me now rewrite build.mjs. I'll write the whole file again with the helper-based approach.

The user hasn't actually asked a question yet — the message is just system instructions plus context. There's no task to do. I should acknowledge briefly and wait for the actual request. Keep it very short.

Small conflicts:
- L1: checkpoint (50,13) is adjacent to the block at (51,52,12) — the block's solid at (51,13) is to the right of the checkpoint. That's "jammed" per my check (which is conservative: the checkpoint at (50,13) center (50.5,13.5) with a wall at x51 → the ball rolling right at center 13.5 hits the wall at 51 (its right edge at 51-0.48 = 50.52) → so the ball reaches center 50.52 and the checkpoint center is 50.5 → dist 0.02 → collected ✓ fine. But the jam check is conservative. Let me just move CP2 to (49,13).
- L3: hoop (35,11) adjacent to the block (36,37,10)? (36,11) is solid → the hoop at (35,11) center (35.5,11.5): the ball at center 35.52 → dist 0.02 → collected ✓. Move it to (35,12)? Hmm, but let me just relocate to avoid ambiguity: put the hoop at (32,12) hmm x31 is CP2. Let me reorganize L3's counts: 7 hoops because I have (1,13),(6,12),(25,11),(35,11),(54,12),(70,12) = 6... plus? Oh, (54,12) is the island and... let me recount: 1,6,25,35,54,70 = 6. The audit says 7. Hmm, maybe m.e(46,12,'o') too — yes! I have (46,12) as well → 7. Let me drop (35,11).
- L4: hoop (44,12) adjacent to the block (45,46,12) → (45,12) solid. Move the hoop to (43,12)? Then (44,12)... the block starts at 45 → the hoop at (43,12) is 2 away ✓.

Let me fix these three spots and re-run.

Wait, in L4 I moved the hoop to (43,12) but x43 is between the pad (35-37) and the pit (39-42) — x43 is after the pit ✓ solid ground ✓ and the ball landing after the pit lands around x43.5 ✓. Hmm, the hoop at (43,12) requires a bounce right after landing. OK.

But careful: the audit checks 'jammed' for adjacency to solids at (x±1,y) and (x,y-1). (43,12): (42,12) is empty (the pit is at row 14) ✓, (44,12) empty ✓ (the block starts at 45 row 12 → (45,12) not adjacent to (43,12)) ✓, (43,13) empty ✓.

Also the L3 hoop moved to (32,12): (31,12)? CP2 at (31,13). (33,12) — the block (33,34,12) means (33,12) is solid → adjacent to (32,12) → jammed again! Ugh. Let me place the L3 hoop at (30,12)? (29,12) is part of the block (28,29,12) → solid → jammed. Hmm. Let me put it at (44,12) instead (after the spike pit at 41-43) — and move the (46,12) hoop to (30,11)? Hmm.

Let me lay out L3 screens 2-3 more carefully:
L3 objects: spawn (2,13), hoops (1,13), (6,12); CP1 (14,13); crumble crossing x18-24; then ground surface 14 at x25-32; block (28,29) surface 12; CP2 (31,13); crystal detour steps (33,34) surface 12 + (36,37) surface 10, crystal (37,7); pit (41,42,43); hoop; strip x49-66 surface 13 with the crossing; island hoop (54,12); hoop (70,12)? but x70 is on the strip (surface 13) → a hoop at (70,12) center 12.5 = standing on the strip surface 13 ✓ rolling ✓ (not jammed: (69,12) is solid? The strip is solid rows 13,14,15 → (69,12) is empty ✓ (70,11) empty ✓ (71,12) empty ✓ OK).
So hoops: (1,13), (6,12), (25,11), (46,12), (54,12), (70,12) = 6 ✓. I dropped the (35,11)/(32,12) hoop entirely. 

Let me check (25,11): (24,11)? The strip x18-24 surface 13 → (24,13) solid, (24,12),(24,11) empty ✓; (26,11) empty ✓; (25,10) empty ✓ → not jammed ✓.

Let me apply: replace `m.e(32, 12, 'o');` with nothing (keep (46,12)).

But now L3 has 6 hoops: (1,13), (6,12), (25,11), (46,12), (54,12), (70,12) ✓.

Run the build + audit + print, and inspect the maps visually.

Looks reasonable. Note L1's spike gaps are at x=11,12 ✓ etc. Also note L1 screen 2 row 14 shows '#########^^####^' → the spike at x15 is part of the gap (47,48) which spans screens ✓.

Let me see the rest of the output for levels 2-4.

Level 3 screen 1: the crumble crossing shows `..##CC..#...##.c` at row 13 — wait, the floor(18,24,13) fills x18-24 rows 13-15 solid, then hole(20,23,13) clears row 13 at x20-23 and spikes at row 14 x20-23, then crumble(20,21,13) → crumbles at x20,21 at row 13. The printed row 13 shows at rel 2,3 = '##' (x18,19) ✓ then 'CC' (x20,21) ✓ then '..' (x22,23 open spikes) then '#' (x24) ✓. 

Hmm! The crumbles at x20,21 and then OPEN spikes at x22,23 with a solid at x24. So the crossing is: from x19 (surface 13) hop onto the crumbles (x20-21), then hop over the open spike gap x22-23 to land at x24 (surface 13). The gap x22-23 is 2 wide → the hop from x21.5 to x23.52 = 2 tiles ✓ fine. OK, but is that "forgiving"? The second hop is over a 2-wide open spike gap ✓ normal. Fine.

Also level 3 screen 3 (the critical crossing): row 13 = `.###CC..CC######` (rel 1-3 = x49,50,51 solid; CC at x52,53; '..' open spikes x54,55; 'CC' x56,57; then x58+ solid). So the crossing = platform x49-51 → crumbles x52-53 → open spikes x54,55 → crumbles x56,57 → platform x58+. 

I intended an island at x54,55 but hole(52,57,13) cleared row 13 at x52-57 then I set crumbles at 52-53 and 56-57, leaving x54,55 open. So the crossing has TWO open spike gaps: x54-55 (2 wide) between the crumble platforms. So the sequence: from x51.5 → land on the crumble x52-53 (center 52.5-53.5) → hop over the open gap x54,55 → land on the crumble x56-57 → hop to x58. Each hop is 2-3 tiles ✓ but the landing spots are crumbles with a 0.5 s fuse, so the player must bounce promptly. This is a proper critical crumble crossing ✓ (and each hop is ~2 tiles = ~0.35 s at low speed, well inside the 0.5 s fuse ✓... hmm, actually if the fuse starts on landing and the player bounces immediately, they're airborne so no problem).

Wait — one problem: if the ball lands ON a crumble tile and the crumble collapses while the ball is standing on it, the ball falls into the spikes → death. The fuse is 0.5 s. The player lands, then must bounce within 0.5 s. That's a reaction window of 0.5 s ✓ human-possible (and the player can also just hold bounce before landing → then the landing auto-bounces them off immediately ✓ since the bounce is applied on landing). That's a nice mechanic: hold bounce through the crossing. 

But careful: "Collapsing must never make a level unwinnable or strand the ball." If the ball is on the crumble at x52-53 when it collapses → death (respawn at CP2 x31, and crumbles reset on respawn ✓). If the ball is on the platform x51 or beyond, safe ✓. The crumbles regenerate after 3 s ✓. So not unwinnable ✓.

Level 3 screen 4: the exit terrace x74-79 surface 12 with the door at (77,11) ✓. And hoop (70,12) ✓ on the strip x49-66? Wait, the strip is x49-66 surface 13; x70 is beyond it → the ground surface 14 at x70 → a hoop at (70,12) center 12.5 → needs a bounce from surface 14 (standing center 13.5 → apex 10.5) ✓ fine. And there's a 1-tile step from the strip (surface 13, ends at x66) down to the ground (surface 14) at x67 ✓.

Level 4 screen 2: pad (35,36,37) at row 13, spike pit x39-42 ✓; hoop (43,12) ✓; blocks (45,46) surface 12 and (48,49) surface 10 ✓ with the crystal at (49,7).
Level 4 screen 3: crumble crossing A: row 13 = `.###CC..CC####` — hmm: floor(51,71,13) then hole(54,59,13) → clears row 13 at x54-59, spikes at row 14 x54-59; crumbles at 54,55 and 58,59 → open spikes at x56,57 (which should have been my island!). Hmm, I intended the island solid at x56,57 but `hole` cleared them. So the layout: platform x51-53 → crumbles x54,55 → OPEN spikes x56,57 → crumbles x58,59 → platform x60+. And the hoop at (56,12) center 12.5 is above the open spikes — collected mid-hop ✓ (risky but the arc passes through). Hmm, that hoop is above a spike gap; if the player is on the crumble and bounces, they pass through the hoop ✓. Fine — exciting but the ball must not need precision. Let me check: the hop from the crumble (center 55.5) to the crumble (center 58.5) = 3 tiles. Hmm, that's a longer hop (3 tiles over a 2-wide spike gap). At low speed: 3 tiles takes 3/s seconds; the ball must clear the gap: the ball's center must be above the spike hitbox top... the spikes are at row 14 (hitbox y 14.42-15.0) — but the ball is walking on surface 13 (center 12.5). Falling into the gap: the ball's center needs to reach 13.94 to touch the spike box. So the ball has a free fall of 1.44 tiles from center 12.5 = 0.36 s. So a 3-tile hop at speed ≥ 3 takes 1.0 s > 0.36 s → the ball would fall into the spikes! Hmm, no: the ball's arc during a bounce: from center 12.5, it rises to 9.5 and comes back to 12.5 at t=1.044. So the ball's center stays ABOVE 12.5 for the whole arc ✓ (it never goes below its launch height). So the ball lands back at its launch height; when it crosses the gap, if the far platform's surface is at the same height (13) ✓ it lands on it. The concern is only whether it reaches the far platform before the arc brings it below surface 13 — i.e., past center 13.5 it's below the platform surface. So: the ball leaves x=55.5 (center) at 12.5 and its center returns to 12.5 at t = 1.044 s. Beyond that it descends below the platform level. In 1.044 s at speed s, dx = 1.044s. Needs dx ≥ 3.02 to reach x=58.52 (the far crumble's left edge - 0.48 + ... let me compute: the far crumble spans x58,59 → for the ball to land on it its center must be ≥ 58 - 0.48 = 57.52... but actually it must not be over the open gap x56,57. If its center is over x57 at a height below surface 13, it's fine as long as... no: the ball's bottom must be above the platform surface while over the gap; landing happens when its bottom reaches y=13 (the platform top). If at that moment the ball is over x57 (open), it continues falling → into the spikes. So the landing x must be ≥ 57.52+ (i.e. overlapping the crumble tile 58 by at least ~0.5 for my collision margin). So dx needed = 58 - 55.5 = 2.5+ → at speed ≥ 2.5 (t=1.0 s) ✓ generous. At speed 6: dx = 6.3 → lands at x=61.8 → past the crumbles x58,59 → onto the platform x60+ ✓ fine (x60+ is solid at surface 13 ✓).

So the crossing works at any speed ≥ ~2.5 ✓.

Hmm, but wait: the ball must land ON the crumble x58-59 OR continue to the platform. At speed 6 it lands on the platform ✓ good. At speed 2.5-4 it lands on the crumble (and then must continue within 0.5 s ✓ or bounce immediately).

Hmm, but one risk: if the ball lands on the crumble at x58-59 and the crumble has already collapsed (from an earlier visit), then the ball falls into the spikes → death. It regenerates after 3 s. That's a "timing" element but not unwinnable ✓.

Now, is there any risk that the first hop (from x53 onto the crumble x54-55) fails? From the platform x51-53 (surface 13), standing at x53.5 → the crumble x54,55: dx = 0.5 → the ball barely needs to move ✓.

OK. Let me now check L4 crossing B: hole(65,70,13) → clears row 13 at x65-70; crumbles at 65,66 and 69,70 → open spikes x67,68. Sequence: platform x60-64 (wait, is x60-64 solid at surface 13? The strip is floor(51,71,13) → x51-71 solid rows 13-15 ✓, minus the holes) → from x64 → crumbles x65,66 → hop over open x67,68 → crumbles x69,70 → platform x71.
Then the strip ends at x71 → the ground at x72+ is surface 14 (1-tile drop ✓).

L4 finale: spikeGap(76,77,78 at row 14) → wait I wrote m.spikeGap(76, 78, 14) → clears row 14 at x76,77,78 and puts spikes at row 14 (resting on row 15) ✓ 3-wide pit. Then pad(81,82,83,13) then floor(86,95,9) terrace, hole(89,90,9)... I wrote m.hole(89, 91, 9) → clears row 9 at x89-91 and puts spikes at row 10! Careful: hole(x0,x1,top) clears row `top` and puts spikes at row top+1. For the terrace (surface 9, rows 9-15 solid), hole(89,91,9) clears row 9 and puts spikes at row 10 → so the pit is 1 deep with spikes at row 10, resting on solid rows 11-15 ✓ that's consistent ✓. But then the crumble at row 9 (crumble(89,90,9)) is above the spikes ✓ and x91 is open spikes (1 wide) ✓.
So: terrace x86-95 surface 9; pit at x89-91 (spikes at row 10); crumbles at x89,90; x91 open; the ball hops from x88 → crumbles x89-90 → then to x92 (solid terrace) — a 1-tile hop from x90.5 to x92 ✓ fine.
Hmm, careful: is x92 solid at row 9? Yes (the terrace minus the hole x89-91) ✓.
Then the door at (93,8) ✓ (base (93,9) solid ✓).

Now, the pad launch onto the terrace: pad at x81-83 (surface 13, standing center 12.5); the terrace surface is 9 → landing needs center ≤ 8.5 → window t ∈ [0.31, 1.17]; the terrace's left edge x=86 → the ball's center must be ≥ 85.52 while cy ≤ 8.5. dx from 83.5 = 2 tiles → speed ≥ 1.71 and ≤ 6.4 ✓ generous ✓. But also the ball must not hit the terrace's left wall (rows 9-15 solid at x86) — when the ball's center crosses x=85.52, its cy must be ≤ 8.5 (above the terrace surface)... For speed 6: t at dx=2 → 0.33 s → cy = 12.5-16.25*0.33+11*0.109 = 12.5-5.36+1.2 = 8.34 ✓ ≤ 8.5 clears ✓ (marginal!). Hmm, marginal at full speed. At speed 6 the ball would graze the terrace's left wall corner. Let me check more precisely: the ball's box/circle at cy=8.34: the terrace tile (86,9) spans y 9..10 → the ball's bottom = 8.34+0.48 = 8.82 < 9 ✓ clears (with 0.18 margin). Then it continues: at t=0.5 cy = 12.5-8.12+2.75 = 7.13; at t=0.6: 12.5-9.75+3.96 = 6.7; apex at t=0.738 → cy = 6.5. Then it descends and lands on the terrace at cy=8.5 → t=1.17 → x = 83.5+6*1.17 = 90.5 → that's over the crumble/pit region (x89-91)! At t=1.17 it's at x=90.5 descending onto the pit → death. Hmm! So arriving at full speed lands you in the pit. That's harsh. Let me move the pit further right: hole(90,92,9) and crumbles (90,91); then the ball at full speed lands at x=90.5 which is now over the crumble x90-91 ✓ (crumbles are solid). Hmm, but the door is at x93 and the terrace ends at x95. Let me shift: terrace x86-95; pit x91-93 (spikes at row 10); crumbles x91,92; solid at x93? The door base is at (93,9)... conflict with the pit. Let me restructure the finale:

- terrace x84-95, surface 9.
- pad x80,81,82 (surface 13) → landing on the terrace's left part x84+ ✓ (dx from 82.5 → 83.52 = 1 tile → speed range 1.0-6.4 ✓; check the full-speed landing: t=1.17 → x = 82.5+7 = 89.5 → lands on the terrace at x89.5 ✓ solid (if the pit starts at x90) ✓).
- pit x90-92 (spikes at row 10, crumbles at x90,91, solid x92) → the ball lands at 89.5 (just before the pit) ✓ then hops the crumbles.
- door at (94,8)? The audit requires the door's neighbours (x±1 at y and y-1) to be non-solid: (93,8),(93,7) empty ✓, (95,8),(95,7) empty ✓ (x95 is the last column: (95,9..15) solid; (95,8) empty ✓).
  Let me put the door at (94,8) and the terrace x84-95 surface 9 ✓.
  Hmm, but then the crumble hop: from the crumble x91 (center 91.5) to the solid x92 (center 92.5) = 1 tile ✓ then the door at x94: the ball rolls right into the door region ✓ (the door tiles are (94,8) and (94,7)).

So L4 finale: pad(80,82,13); floor(84,95,9); hole(90,92,9); crumble(90,91,9); door (94,8).
Also the spikeGap before the pad: m.spikeGap(76,78,14) ✓ 3-wide pit on the ground before the pad ✓.

And I need CP2 (31,13) — that's far from the final stretch. Requirement: "the two checkpoints bank progress in front of that level's two hardest stretches". L4's two hardest stretches: the crumble gauntlet (x51-71) and the finale (x72-95). CP1 is at (15,11) and CP2 at (31,13) — hmm, neither is in front of the finale. Let me move CP1 to (50,12)?? Hmm, x50 is at surface... let me check the L4 map: x45-46 floor surface 12, x48-49 floor surface 10, x51-71 strip surface 13. So near x50: the ground surface 14 at x50. Let me place CP1 in front of crossing A at (50,13) → center 13.5, on the ground at surface 14 ✓ (and the strip at x51 has surface 13 → a 1-tile step up at x51 ✓; the checkpoint at (50,13) with a solid at (51,13) → jammed per my audit (right neighbor solid at the same row). Hmm, the audit's jam check is about (x±1, y) being '#' — (51,13) is '#' (the strip's surface row is 13 → rows 13,14,15 solid) → jammed. But is it really? The checkpoint tile (50,13) center (50.5,13.5); the ball rolling on the ground surface 14 has center 13.5 → dist 0 ✓ collected before hitting the wall at x51 ✓ it's fine, but let me place it at (49,13)? Then (49,13)'s right neighbor (50,13) is empty ✓ and below (49,14) solid ✓. But x48-49 is the crystal block (floor(48,49,10) → (48,10),(49,10) and rows 10-15 solid) → so (49,13) is solid ✗. 

Let me restructure L4's geometry a bit: the crystal detour at x45-46 (surface 12) + x48-49 (surface 10) occupies x48-49 down to the bottom. So x50 is free ground. The strip starts at x51.

Place CP_A at (50,13)? Its right neighbour is (51,13) = solid → jam. Instead let me move the strip to start at x52 and put CP at (50,13): then (51,13) is empty ✓ and (49,13) is solid (part of the x48-49 block) → jam on the left! Ugh.

Alternative: raise the checkpoint onto the strip: CP at (51,12) (on the strip, surface 13) → the tile above the surface is row 12 ✓; (50,12) empty ✓ (52,12) empty ✓ (51,11) empty ✓ no jam ✓. And the ball walking on the strip at center 12.5 → the checkpoint center (51.5,12.5) → dist 0 ✓ collected on entering the strip ✓ 

So CP1 = (51,12) [in front of crossing A] and CP2 = ? in front of the finale, e.g. on the ground at (79,13)? The finale starts at the pad x80-82. (79,13): left (78,13) empty ✓ right (80,13) = pad '=' → my audit only flags '#' as jam; a pad is '=' → not flagged, but physically the pad tile at (80,13) is solid → the ball rolling right at center 13.5 is blocked at x=79.52 → dist to (79.5,13.5) = 0.02 ✓ collected ✓ fine.
Hmm, but CP2 in front of the finale means a respawn there — right before the pad and the 3-wide spike pit at x76-78 ✓ OK (the spike pit is behind it).

And I should keep a checkpoint count of 2 ✓: CP1 (51,12), CP2 (79,13). But then the early part of L4 (the pads and spike beds x16-44) has no checkpoint... "the two checkpoints bank progress in front of that level's two hardest stretches" ✓ exactly two, in front of the two hardest ✓ correct per spec.

Hmm, but for L1, L2, L3 I placed CP1 early and CP2 mid. That satisfies "in front of the level's two hardest stretches" loosely. Let me re-verify each:
- L1: CP1 (15,13) before the spike beds (x19+) and CP2 (49,13) before the final climb (x51-55) ✓ good.
- L2: CP1 (13,13) before the spike beds x19-30; CP2 (33,13) before the pad climb + the descent ✓ good.
- L3: CP1 (14,13) before the first crumble (x18-24) ✓; CP2 (31,13) before the critical crumble crossing (x49-66) ✓ good.
- L4: fix as above ✓.

Now let me also double check L2's screen 3 (the high road): rows 9-14 at x48-59 solid, and the pillar x54,55 rows 7,8,9 → printed '......##........' at row 7 with '*' at (54,6) ✓ and hoops at (51,8) and (58,8) ✓.

Wait, from the printed L2 screen 3 row 8: `...o..##..o.....` → hoops at rel 3 (x51) and rel 10 (x58) ✓ and the pillar at rel 6,7 (x54,55) ✓.

But hold on: the hoop at (51,8) center (51.5,8.5) = the ball's center standing on the high road (surface 9) ✓ collected by rolling. But the ball ARRIVES on the high road via a pad launch — it might land past x51 if fast. Then it can roll back left onto... the high road ✓ fine.

Now, one issue in L2: after the high road (x48-59), the ball must descend to the ground at x60+ (surface 14). The high road's right edge is at x59 → dropping 5 tiles to the ground ✓ safe (no fall damage). ✓ And the spike bed at x66-69 ✓ is after the landing zone x60-65 (6 clear tiles) ✓.

Then the pad at x72,73 → terrace x74-79 surface 9, door at (77,8) ✓. Hmm: the pad is at x72-73 (surface 13) and the terrace starts at x74 with its surface at 9 → the terrace's left wall spans rows 9-13 at x74. The ball on the pad must cross x=73.52 (its center) with cy ≤ 8.5. dx from 73.5 (standing at the pad's right edge) = 0.02 → basically immediately: the ball standing at the pad's right edge (center 73.5, but the terrace wall at x74 means the ball's center can be at most 74-0.48 = 73.52) → so standing at 73.5, bouncing 6 tiles up: at t=0.1, cy = 12.5-1.6+0.11 = 11.0; hmm, it needs to rise above cy=8.5 which takes t=0.31 s → dx = 0.31*s. At speed 1, dx = 0.31 → x = 73.81 → and at that time cy = 8.5; the ball's right edge = 74.29 > 74 → it collides with the terrace wall at x74 (rows 9-13): the wall tile (74,9) spans y 9..10 — the ball's center at 8.5, bottom 8.98 < 9 → hmm, the ball's box [73.33,74.29]×[8.02,8.98] and the tile (74,9) spans [74,75]×[9,10] → no overlap (8.98 < 9) ✓. So the ball just rises past the wall corner. Then it must get over the terrace top: at t=0.31 it's at x=73.81 with cy=8.5 (exactly the surface level) — it continues rising; at the apex (t=0.738) cy=6.5, x = 73.5+0.738s. Then it descends to cy=8.5 at t=1.17 → x = 73.5+1.17s. For s=1: x=83.5?? no: 73.5+1.17 = 74.67 ✓ lands on the terrace ✓. For s=6: x = 73.5+7.02 = 80.5 → beyond the terrace (which ends at x79) → the ball flies past the terrace and lands on the ground at x>79... the level ends at x79! So at high speed the ball sails off the level end. My boundary clamp: `if (b.x > LL.W - CR) { b.x = LL.W - CR; ... }` → x clamps to 79.52 and the ball falls... the world's right edge is solid (my isSolid returns true for out-of-bounds) ✓ so the ball lands on the ground at x=79.52 hmm, out-of-bounds tiles are solid, meaning the column x=80 is solid → the ball at x ≤ 79.52 rests on the ground surface 14 (rows 14,15 solid at x79) ✓ fine, then it can roll back left and retry ✓. Not ideal but not broken. Let me extend the terrace to x79 and add... it already is x74-79 with the surface at 9; so at high speed the ball overshoots the terrace and falls at x=79.5 into... x79 is solid rows 9-15 → so the ball at x=79.5 lands on the terrace top ✓ (the terrace extends to x79 = the last column) ✓. Wait, at speed 6, x = 80.5 would be beyond the level → clamped to 79.52 → lands on the terrace (x79, surface 9)? The ball's center 79.52 at cy=8.5 → it rests on the tile x79? The tile (79,9) is solid → hmm, the ball's center 79.52 means it's over column 79 (spans 79-80) ✓ resting on surface 9 ✓ OK, and then it can't go right (the world's edge) ✓ fine.

So the ball lands on the terrace ✓. But careful: the clamp happens mid-air — my code clamps x and zeroes vx but the ball keeps falling ✓ lands ✓ fine.

Good. Now L4's final: door at (94,8) with the terrace x84-95 → the door's base (94,9) is solid ✓, above (94,7) must be clear ✓ (the terrace surface is 9, so rows 0-8 at x94 are empty ✓).

Let me now update L4 in the builder: change CP1 to (51,12), CP2 to (79,13), pad(80,82,13), floor(84,95,9), hole(90,92,9), crumble(90,91,9), door (94,8). Remove floor(12,15,12)'s hoop/CP at (14,11),(15,11)? I had CP1 at (15,11) on the terrace x12-15; now CP1 moves to (51,12). Hmm, but then the terrace x12-15 holds a hoop only ✓ fine.

Wait, but I want 2 checkpoints in front of the two hardest stretches: crossing A (x51-59) and the finale (x72-95). CP1 (51,12) and CP2 (79,13) ✓.

Hmm, is (79,13) OK given the pad at x80-82? The pad tile at (80,13),(81,13),(82,13) is 1 tall on the ground (surface 14). The checkpoint at (79,13) center (79.5,13.5): the ball rolling right at center 13.5 is blocked by the pad's left face at x80 → its center stops at 79.52 → dist 0.02 ✓ collected. Fine but tight; let me move CP2 to (78,13)? Then the audit: (77,13) empty ✓ (79,13) empty ✓ (78,14) = '^'? The spikeGap is at x76-78 row 14 → (78,14) is a spike → the checkpoint at (78,13) would be directly above a spike → bad (respawn?). My audit checks "door/spawn floor" but not spikes below checkpoints. Let me place CP2 at (74,13): (73,13),(75,13) empty ✓ (74,14) solid ✓ (spike pit starts at 76) ✓ → CP2 (74,13), 2 tiles before the pit ✓ and the ball respawns there safely ✓.

Hmm, but then after respawning at CP2 the player must redo the pit+pad+terrace ✓ correct behavior.

Let me apply the L4 edits. Also add a hoop count check: L4 hoops (1,13),(10,12),(14,11),(23,11),(43,12),(56,12) = 6 ✓.

Also for L4 crossing B (x65-70), maybe put a hoop? No, 6 already.

Let me edit build.mjs for L4.

Also the audit should check that checkpoints/crystals are not sitting directly on spikes (nothing lethal below the tile they rest on... the entity tile itself shouldn't be a spike and the tile below shouldn't be a spike for respawn safety — actually checkpoints in mid-air are fine; respawn places the ball at the checkpoint center, and if a spike is right below it might die instantly. Let me add an audit: for checkpoints, the tile below must not be a spike and the tile itself must not be a spike.

Let me add that check, and also verify the spawn/respawn is not inside a spike.

Then run build+check.

Also I realize the audit doesn't check that entity tiles below are 'o' support; whatever.

Now, let me add a `respawnSafe` audit for checkpoints, then run the solver.

Let me check the state of things quickly. Files: index.html (need to check it exists — I never wrote it!), style.css (never wrote it!), game.js (wrote it, but level maps empty and referencing missing things).

Critical: index.html and style.css don't exist yet. game.js has empty maps for levels 2-4 and level 1 maps in maps.mjs not yet spliced... Actually I did run `--write` which wrote maps.mjs, but game.js's LEVEL_SHAPES is `[[],[],[],[]]` placeholder (splicing was scripted via port.mjs which I never ran).

Priorities:
1. Run build (audit), run port.mjs to splice maps into game.js.
2. Write index.html + style.css.
3. Sanity check game.js for syntax errors / missing functions (node parse + maybe jsdom-less smoke test).

Let me go fast.

All four maps spliced into game.js and syntax is OK. Now I need index.html and style.css (they don't exist!). That's the critical missing piece.

Let me quickly check game.js's boot() for the DOM ids it needs: #stage, #world, #lives, #lv, #hoops, #score, #overlay. And CSS classes: .ball, .card, .press, .hint, .sub, .score, .on, --s, --hud.

Let me write index.html and style.css now. Also verify there are no undefined function calls in game.js (e.g., `sim.idx2`, `isSolidL` are defined ✓; `drawDoor` uses `L.doorOpen || '#000'` fine; `drawScreen` uses `sim.fx` ✓; `Sim.prototype` defined after boot but assigned before requestAnimationFrame starts? boot() is called at module top-level (line ~636 region: `if (typeof document !== 'undefined') boot();`) BEFORE the `Sim.prototype.idx2` assignments at the end of the file! boot() calls requestAnimationFrame(frame) which is async, so by the time frame runs, the prototype methods exist ✓. But boot() also... it constructs Sim, which doesn't call idx2 ✓. Fine.

Wait — is `boot()` invoked before `Sim.prototype.idx2` is defined? Yes but only rAF matters. Also `LEVELS_PARSED` is defined before boot ✓.

Another check: `this.fx` is initialized in Sim constructor before loadLevel? `this.fx = []` then loadLevel → placeAtRespawn... loadLevel sets `this.fx = []` too ✓.

Also `Game` class no longer exists — I removed it in the rewrite? Let me check that nothing references Game. And `KEY_ANY`, `PALETTES` name field etc. Let me grep for obvious issues and run a headless smoke test: simulate the Sim stepping through level 1 to make sure no exceptions.

Let me write index.html + style.css first, then a quick node smoke test of Sim, then optionally a Playwright screenshot to confirm the page loads without errors.

Careful: the HUD in game.js sets `elLevel.textContent`, `elHoops`, `elScore`, `lifeIcons.innerHTML`. If the elements are wrapped, my ids are on the right elements ✓ (I put ids on inner spans/b). In game.js: `elLevel.textContent = ...` where elLevel = document.getElementById('lv') → `<b id="lv">` ✓. elHoops = `<b id="hoops">` ✓. elScore = `<span id="score">` ✓ — but note it's inside `<span class="grp scr" id="score">` ✓ id on the span ✓ fine.

Now style.css: scale via --s, crisp pixels, HUD bar below the 128x128 viewport, overlay screens.

Now smoke-test: run game.js in node (it has no DOM path executed) and drive the Sim headlessly for level 1 to catch runtime errors, and verify entity counts. Then optionally a Playwright page load to confirm no console errors.

game.js uses `import`? No, it's a browser IIFE; node --check passed. To import it in node ESM: `import '../game.js'`... from a script in the same dir. Let me write a quick inline node test.

The smoke test lives in /tmp so the relative import fails, and it also needs the parent package.json type... /tmp has no package.json, so .mjs is ESM ✓. Let me put the smoke test in the project dir (tools/smoke.mjs) with the correct relative path.

Two red flags:

1. W = 1024 for level 1 — the parse computed W = rows.length * VIEW_TILES where rows.length = 64 (rows, not screens!). Bug in parseLevel: it treats each row entry as a screen. LEVEL_SHAPES from port.mjs has 64 rows for level 1, so rows.length=64 → W = 1024, and rows are indexed as `rows[s*H+y]` where s goes 0..rows.length/H... Let me re-read parseLevel:

```js
const H = VIEW_TILES, W = rows.length * VIEW_TILES;
for (let s = 0; s < rows.length; s++)   // s = screen index; but rows.length is the total number of rows!
```
So it iterates s over rows.length (=64) screens instead of 4 → W=1024, and most rows are undefined → filled with '.'. So the parsed maps ARE still correct in terms of tile placement for the first 4 screens (since rows[s*H+y] with s<4 works), but W is wrong (1024 instead of 64), meaning:
- The level's right side is empty space up to x=1023 with no floor → the ball could run off into the void!
- Camera clamp W-16 → the camera would show empty space.
This is a real, must-fix bug.

Fix: `const screens = Math.ceil(rows.length / H); W = screens * VIEW_TILES;` and loop s < screens.

2. Bounce height at speed = 4.95 tiles vs standing 2.93 — that violates "every bounce is the same height". Why? Because at speed the ball lands on something different, or... the measurement: `runSteps=120` (1 s of rolling right) then hold bounce. Hmm, peak = y0 - peakY where y0 is the ball's y at the moment of the last measured step. Ah wait — my measurement is flawed: I set `s.input.bounce = () => true` and then the ball bounces when it lands. But at speed the ball is running right and may still be airborne at that instant... Also the ball accelerates right and at 120 steps it's at max speed 6 t/s → it travels ~4 tiles in 0.75 s. But then the peak measured is 4.95 — bigger than 3! That suggests the ball launched from a bounce pad? Level 1 has no pads. OR the ball ran into a wall/pit and fell, so peak measures the fall (y0 - peakY where peakY is the minimum y = the highest point; falling increases y so peakY would be y0...). Falling gives y0 - peakY = 0 unless the ball went UP.

Hmm, actually the ball's y0 was measured mid-run; then in the loop it holds bounce. If the ball goes down a spike gap... it dies (break). Wait: peakY = min over steps. If the ball goes up 3 tiles, peak = 3. To get 4.95 the ball must have gone up 4.95 tiles. Unless... y0 was captured while the ball was airborne above the ground? No: at 120 steps of rolling right from spawn on flat ground, the ball is grounded (in L1 screen 0 there's the staircase at x4-9 — the ball running right hits the wall at x4! It stops against the wall (vx=0). Then holding bounce → it bounces up 3 tiles, but while pressed against the wall it keeps holding right and bounce... The measured "peak" of 4.95 could be because after bouncing up 3 tiles above the surface at y=14 (center 13.5 → apex 10.5), hmm 4.95 above y0? If y0 = 13.5, peak y = 8.55 → 4.95 tiles up. How? A bounce from the ground at apex center 10.5, but with the staircase: the ball is against the wall at x4 (rows 12-13 solid) — while holding right+bounce, on each landing it gets 3 tiles → and it may land on top of the step at y=12 (center 11.5), then bounce again → apex 8.5 → y0-peakY = 5. Yes! That's it: the ball climbed the staircase. So my measurement is confounded, not a physics bug. Standing bounce = 2.93 ✓ ≈ 3.

Let me verify the "same height" claim more cleanly: measure on flat ground with no obstacle — use level 2 screen 0? Also confounded. Let me instead measure the launch velocity magnitude on landing: it must be BOUNCE_V regardless. Simpler test: place the ball in mid-air? Let me do a quick test: from spawn in L1, roll LEFT (away from the staircase) to build speed, then... it hits the level's left wall. Hmm. Use level 4 spawn? Also flat to the right for many tiles (L4 has the pad at x6 — confounded).

Test differently: instrument by measuring the maximum height above the local surface... Simplest: run a check where the ball rolls right in L2 (spawn x2, flat to x4 where the pad is at x5-6) — confounded.

Alternative: temporarily test in a synthetic flat map. Let me build a synthetic level (all floor 14, 40 wide) and measure bounce height from standing and at full speed. That's the real physics test. Do it inside the smoke script by parsing a synthetic map through BOUNCE.parseLevel.

Also, importantly: L1's spawn at x2 with the staircase wall at x4 means a beginner rolling right immediately hits a wall — that's fine (it's the tutorial staircase).

Let me fix parseLevel's W bug now — that's critical — and then rerun the smoke test + synthetic bounce test.

Also check: `if (b.x > LL.W - CR)` clamp uses W ✓ after the fix it'll clamp at the true level end.

Let me fix in both game.js and tools/maps (no, maps are data).

Wait: in the parse loop, the row is `rows[s * H + y]` — with s = screen index ✓ correct now.

But the maps.mjs written by build.mjs: rows() returns screens*16 rows in order screen0 y0..y15, screen1 y0..y15, ... ✓ matches rows[s*H+y] ✓.

Also the `at`/index uses `s * VIEW_TILES + x` ✓.

Now also add a synthetic bounce-height test. Let me append to tools/smoke.mjs and rerun.

Widths fixed (64/80/80/96) and entity counts are exactly 6/2/1/1 for all four levels. Bounce height is constant 2.95 tiles from standing and at full speed ✓ and no-hold settles immediately ✓.

Now verify the page actually loads in a browser without errors using Playwright (available in the parent project). Quick check: load file:// index.html, wait, capture console errors and a screenshot.

Time is short — let's do it.

The page loads, no console errors, the game starts on Space, the ball rolls and collected a hoop (score 00000100, hoops 5) ✓. Camera, HUD and flow work.

Let me look at the screenshots quickly to confirm the world renders (not a black screen) and that the ball is visible.

Time is tight; let me check the play screenshot visually.

I can't view images. Instead, verify programmatically: sample canvas pixel data in the browser to confirm non-black content, the red ball exists, and the HUD bar is below. Let me do a quick canvas pixel analysis in Playwright.

The canvas is 128×128 logical, rendered at 640 CSS px (scale 5), the world is fully drawn (16384 non-black pixels = full viewport has content), the red ball is present (25 red pixels ≈ a 1-tile-diameter ball at 8px ≈ π*4² ≈ 50... 25 counted with the strict threshold, fine), and the HUD strip sits 34px below the world canvas ✓ (never hides a map row).

Everything core works: index.html + style.css + game.js load, no errors, flow starts, pickups score, HUD correct.

One last cheap consistency check: the overlay screens (level clear / game over / complete) reference sim.mode; game over needs lives to hit 0. Already logic-checked. And the leftover `drawDoor` uses `p.doorOpen || '#000'` — harmless.

Also: no background processes running (I started none). Let me delete nothing... Actually shot-title.png/shot-play.png are extra artifacts in the deliverable directory. They're harmless but let me remove them to keep the published dir clean (small, cheap).

Then finish with a summary.