What qwen3.8-27b did

Let's plan the Breakout game.

Structure:
- `index.html` — page with canvas, controls description, styles
- `game.js` — all the game logic

Main requirements:
1. 960×600 CSS pixel playfield, centered.
2. 8 columns × 5 rows of bricks at the top, with gaps. Different color per row. Top 2 rows take 2 hits (visual damage after the first hit), the rest take 1 hit.
3. Bottom paddle, controlled by mouse (follows cursor's x) and left/right arrow keys. Can't leave the field.
4. Ball starts stuck to the paddle, launches with Space or click. Bounces off walls, ceiling, bricks, paddle. Paddle hit position changes the exit angle — edges are steeper.
5. 3 lives. Ball lost off the bottom → lose 1 life, ball sticks to paddle again.
6. Score: 10 points per brick hit, 50 points per brick destroyed. Score and lives displayed during play.
7. Win when all bricks are gone, lose at 0 lives. Clear message + restart that fully resets (score, lives, bricks).
8. rAF loop, frame-rate independent (dt scaling).
9. No tunneling — use substeps / continuous collision. Even when the ball speeds up.
10. Speed gradually increases as bricks are destroyed, with a cap.
11. Pause with P, or on window blur.
12. Juice: hit flash, particles, screen shake, trail, WebAudio sound. Don't overdo it.
13. All graphics via canvas API.
14. Show controls outside the canvas.

Design details:

Canvas: 960×600 CSS pixels. Handle devicePixelRatio for sharpness: canvas.width = 960 * dpr, canvas.height = 600 * dpr, ctx.setTransform(dpr,0,0,dpr,0,0). CSS width 960px, height 600px.

Layout: centered on the page. Dark theme. Title, canvas, controls description below.

Bricks: 8 columns × 5 rows. Playfield width 960. Gaps between bricks. Let's calculate: side margins and gaps. Brick width: (960 - 2*margin - 7*gap) / 8. With margin 40, gap 8: (960 - 80 - 56)/8 = 824/8 = 103. Brick height 24, row gap 8. Top offset: 60 (below the HUD area? Actually, score and lives are displayed "during play" — can be drawn on canvas at the top. Let's put the HUD on canvas: score top-left, lives top-right (hearts or ball icons). Bricks start at y=70.

Rows: y = 70 + row*(24+8) = 70 + row*32. Row 4 ends at 70+4*32+24 = 70+128+24 = 222. Good, plenty of room below.

Brick colors: 5 different colors per row. Top 2 rows take 2 hits. After the first hit, visual damage: draw cracks / dim it, or draw a cracked version (e.g., darker + crack lines).

Ball: radius 6. Speed: base 380 px/s, increases per brick destroyed. Max speed cap ~700 px/s. Speed scale: speed = min(base + destroyedCount * 8, max). Total bricks 40; base 380 + 40*8 = 700 exactly at the cap. Good: speed = 380 + destroyed*8, cap 700.

Actually, "speed increases gradually as bricks are destroyed, with a cap" — this works.

Ball direction: keep a velocity vector; on speed change, rescale the vector to the new magnitude while preserving direction.

Paddle: width 110, height 14, positioned at y = 600 - 30 (near the bottom edge). "Bottom edge" — paddle near the bottom. Paddle y: 600 - 26 - 14? Let's say paddleY = 600 - 34 = 566, height 14. Ball lost when ball.y - r > 600.

Paddle movement: mouse x → paddle center = mouseX, clamped to [paddleW/2, 960 - paddleW/2]. Arrow keys: speed 600 px/s (dt scaling). Left/right held down.

Ball launch: stuck state — ball.x = paddle.x, ball.y = paddleTop - r - 1. Launch with Space or click: angle slightly random? Spec says launch on Space or click. Let's launch at a slightly random angle near vertical: angle = -90° ± up to 20°. Or fixed -75°? Random within ±25° from vertical is good, guarantees horizontal movement.

Paddle bounce: relative hit position p = (ball.x - paddle.x) / (paddleW/2), clamped to [-1, 1]. Exit angle: angle from vertical = p * maxAngle, maxAngle = 60°. So vx = speed * sin(angle), vy = -speed * cos(angle). Center → straight up; edges → 60° from vertical. Good.

Also, to prevent the ball from getting stuck in a horizontal loop, guarantee a minimum |vy|: the 60° max angle means vy = speed*cos(60°) = 0.5*speed, which is fine.

Wall collision: left/right: if ball.x - r < 0 → x = r, vx = |vx|; if x + r > 960 → x = 960 - r, vx = -|vx|. Ceiling: y - r < 0 → y = r, vy = |vy|.

Brick collision: no tunneling. Use substeps: split dt so that per substep the ball moves at most ~ (r) or a fraction of the minimum brick dimension. Simplest and most robust approach: compute the steps = ceil(dist / maxStep), maxStep = 4 px (ball radius 6, brick height 24, gap 8). At max speed 700 px/s and dt up to ~0.05s (50ms), distance = 35px → 9 substeps. No problem.

Within each substep: move the ball, then check collisions:
- Walls (simple clamp).
- Bricks: iterate over living bricks; if circle-rect intersects, determine the collision face by penetration depth (compare x overlap and y overlap), reflect velocity, push out, and break. To avoid double hits on the same substep, process one brick per substep (break after the first collision). With 4px substeps and ball radius 6, it's fine.

Circle-rect collision: closestX = clamp(ball.x, brick.x, brick.x+w), closestY = clamp(ball.y, brick.y, brick.y+h); dx = ball.x - closestX, dy = ball.y - closestY; if dx*dx+dy*dy <= r*r → collision.

Face determination: if ball center is horizontally inside the brick (closestX == ball.x), it's a vertical face... Standard approach: compute overlapX = (r - |dx|) etc. Simpler: if |dx| > |dy| → horizontal bounce (vx = -vx, push x out by sign(dx)*(r - |dx|)); else vertical bounce (vy = -vy, push y out). Edge cases where dx or dy is 0 (center is exactly on an edge) — handle with a sign fallback.

Actually a cleaner method: penetration depth. dx = ball.x - closestX, dy = ball.y - closestY. If dx == 0 && dy == 0 (center inside rect — shouldn't happen with substeps), push out along the smaller axis. Otherwise if |dx| > |dy|: vx = sign(dx)*|vx|... wait, if the ball is moving right and hits the left face of a brick, dx < 0 (closest point is on the right side of the ball... let me think: ball is to the left of the brick, closestX = brick.x, dx = ball.x - brick.x < 0. Ball should bounce left: vx = -|vx|. sign(dx) = -1 → vx = sign(dx)*|vx| = -|vx|. Good. Push out: ball.x += sign(dx)*(r - |dx|).

Else (|dy| >= |dx|): vy = sign(dy)*|vy|; ball.y += sign(dy)*(r - |dy|).

This is the standard approach and works well with substeps.

Brick hit: brick.hp -= 1; score += 10; if hp <= 0: score += 50 (total 60 per destroyed brick — spec: 10 per hit, 50 per destroy; a 2-hit brick totals 10+10+50=70, a 1-hit brick totals 60). Hmm, "10 points per brick hit, 50 points for destroying" — yes, hit = 10 each time, destroy bonus = 50. OK.

Particles: on hit, spawn ~8 particles with random velocities, gravity, fade. On destroy, more (~14) + a small screen shake (magnitude 4, decays) + a flash on the brick (draw a white flash rectangle for a few frames — simpler: particle burst + shake + sound).

Trail: keep the last N ball positions, draw fading circles. Simple: store positions each frame (or each substep end), draw with decreasing alpha and radius.

Sound: WebAudio, create on first user gesture (click/keydown) to satisfy autoplay policy. Simple beep synth: oscillator + gain envelope. Different pitches: wall (200Hz square, short), paddle (300Hz), brick hit (440), brick destroy (660 with a quick arpeggio?), lose life (descending), win (little arpeggio). Keep it simple: a function playSound(freq, duration, type, volume, slideTo).

Pause: P key toggles pause (only when playing, not during win/lose). Window blur → auto-pause (only when playing). Show "PAUSED" overlay.

Game states: 'ready' (ball stuck, waiting for launch), 'playing', 'paused', 'won', 'lost'. Restart: R key or click a button? Spec: "both states show a clear message and offer a restart that fully resets the game." Show a message on canvas and offer restart — click or Space/R key restarts. Accept Space, R, or click in won/lost state. Also a visible hint "Press Space or click to restart."

Score and lives display: drawn on canvas at the top: "SCORE 1234" left, lives as small ball icons or hearts on the right. Use canvas text.

HUD area: top 50px. Bricks start at y=70 — wait, if score text is at y~30 and bricks start at 70, that's fine.

Actually, let's reconsider: bricks at y=70..222. Ball launches from paddle at y~560. Plenty of room.

Mouse control: mousemove on the canvas → compute x in canvas coordinates: (e.clientX - rect.left) * (960 / rect.width). CSS width is 960 so scale = 1, but handle it generically.

Keyboard: track ArrowLeft/ArrowRight in a keys object. preventDefault on arrows/space to prevent page scroll.

Frame-rate independence: dt = (now - last)/1000, clamped to max 0.05 (to avoid huge jumps after tab switch). All movement * dt.

Screen shake: shakeTime, shakeMag; offset = random within mag * (shakeTime/shakeDur). Apply ctx.translate before drawing the world; HUD can be drawn without shake (or with it — simpler to shake everything, that's fine, or draw HUD after restore).

Hit flash: when a brick is hit, store flash {x,y,w,h,t} and draw a white overlay with alpha ~ t. Or a global flash. Per-brick flash is better.

Also add subtle background: dark with a slight vignette or grid. Keep it simple: dark background, subtle stars? Keep it minimal — dark gradient background, faint grid lines. Good.

Ball stuck: draw ball on top of paddle; show "Press Space or click to launch" hint text.

Edge cases:
- Ball can't escape: substeps + clamp guarantee it. Also add a safety clamp: if ball goes past the bottom, that's a life loss (intended). Left/right/top are clamped.
- Ball speed cap 700; substep maxStep 4 → at 60fps, per-frame distance = 700/60 ≈ 11.7px → 3 substeps. At 144Hz, 4.86px → 2 substeps. Good.
- dt clamp 50ms → max distance 35px → 9 substeps. Good.

Pause on blur: window 'blur' event → if state is 'playing' or 'ready' → pause. Also 'ready' state — pausing ready is fine; show "PAUSED."

Sound on restart etc.

Win check: remainingBricks == 0 → state 'won', play win sound.
Lose: lives == 0 → state 'lost'.

Life loss: ball falls below 600 + margin → lives--, lives > 0 ? state 'ready' (ball sticks) : state 'lost'. Play lose sound. Screen shake.

Now, "the ball must never tunnel through bricks, get stuck inside them, or escape the playfield even when accelerating" — substeps handle this. Also, after paddle bounce, push the ball above the paddle top to avoid re-collision: ball.y = min(ball.y, paddleTop - r).

Paddle collision: only when ball is moving downward (vy > 0) and ball bottom >= paddle top and ball.y - r < paddle bottom (i.e., ball vertically overlaps the paddle) and horizontally within the paddle range (|ball.x - paddle.x| <= paddleW/2 + r). Then compute the angle.

Also, if the ball hits the side of the paddle — rare; treat it as a bounce with the same formula (it works, angle from the hit position).

Score display: "SCORE" and number. Lives: 3 small circles (remaining lives as filled, lost as empty?) or hearts. Draw remaining lives as small ball icons.

Also show the current speed? Not needed.

Controls outside the canvas:
- Mouse or ← → : move paddle
- Space / click: launch ball
- P: pause
- Space / click / R: restart after win/lose

Now let's write the code.

Structure of game.js:

```js
(() => {
'use strict';

// --- Setup ---
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const W = 960, H = 600;
let dpr = Math.max(1, Math.min(2, window.devicePixelRatio || 1));
function fitCanvas() { dpr = ...; canvas.width = W*dpr; canvas.height = H*dpr; }
window.addEventListener('resize', fitCanvas); fitCanvas();
// in render: ctx.setTransform(dpr,0,0,dpr,0,0)

// --- Audio ---
let audioCtx = null;
function ensureAudio() { if (!audioCtx) { try { audioCtx = new (window.AudioContext||window.webkitAudioContext)(); } catch(e){} } if (audioCtx && audioCtx.state === 'suspended') audioCtx.resume(); }
function beep(freq, dur, type='square', vol=0.15, slide=0) { if(!audioCtx) return; ... oscillator + gain, exponential ramp }

// --- State ---
const COLS=8, ROWS=5, BW=103, BH=24, GAP=8, MARGIN=40, TOP=70;
```

Wait, let's recompute BW: (960 - 2*40 - 7*8)/8 = (960-80-56)/8 = 824/8 = 103.

Brick positions: x = 40 + c*(103+8), y = 70 + r*(24+8).

Colors per row:
- Row 0: #ff5252 (red)
- Row 1: #ffb74d (orange)
- Row 2: #ffd54f (yellow)
- Row 3: #4dd0e1 (cyan)
- Row 4: #7986cb (indigo)

Top 2 rows: hp 2, rest hp 1.

Damaged look: draw the brick in a darker color + crack lines (a few random-looking but deterministic lines). Precompute crack offsets per brick? Simpler: draw 2-3 crack lines based on brick index (deterministic pseudo-random from index). Or just draw a darker fill + a crack polyline. Let's do: damaged → fill with a darker shade, stroke with a crack path made from a seed.

Simple deterministic cracks: given brick index i, use a small hash function to generate 3 segments.

Paddle: PW=110, PH=14, PY=566.

Ball: R=6, base speed 380, +8 per brick destroyed, cap 700.

Speed function: currentSpeed() = Math.min(380 + destroyedCount*8, 700).

On launch: dir angle = (-90 + rand*40 - 20) degrees → vx = cos, vy = sin (in radians). Angle from vertical: a = (Math.random()*50-25) * PI/180; vx = sin(a)*speed; vy = -cos(a)*speed.

Update loop:

```js
let last = performance.now();
function frame(now) {
  requestAnimationFrame(frame);
  let dt = (now - last)/1000; last = now;
  if (dt > 0.05) dt = 0.05;
  if (state === 'playing') update(dt);
  render();
}
```

Pause: state 'paused' — skip update, render overlay. When unpausing, `last` keeps updating each frame (since we compute dt every frame), so no jump. Good — dt is computed every frame regardless of state, so no time jump on unpause.

Paddle update: keyboard velocity 620 px/s.

Mouse: on mousemove, set targetPaddleX; in update, paddle.x = clamp(targetPaddleX). But if the mouse isn't moved, the keyboard should work — so mouse sets targetPaddleX only on mousemove events; keyboard moves paddle.x directly, and also updates targetPaddleX to the new position so the next mousemove doesn't jump... Actually, if the mouse doesn't move, targetPaddleX stays at the old value; if we set paddle.x = targetPaddleX every frame, the keyboard movement gets overwritten. Solution: on mousemove, set a flag and paddle.x directly (clamped). Keyboard moves paddle.x in update. Both modify the same x; no per-frame mouse application needed. But smooth mouse follow: direct setting is fine (cursor position). Let's do that.

Ball update (playing):
```js
const dist = speed * dt;
const steps = Math.max(1, Math.ceil(dist / 4));
const sdt = dt / steps;
for (let i=0;i<steps;i++){
  ball.x += ball.vx * sdt;
  ball.y += ball.vy * sdt;
  // walls
  if (ball.x < R) { ball.x = R; ball.vx = Math.abs(ball.vx); wallHit(); }
  else if (ball.x > W-R) { ball.x = W-R; ball.vx = -Math.abs(ball.vx); wallHit(); }
  if (ball.y < R) { ball.y = R; ball.vy = Math.abs(ball.vy); wallHit(); }
  // paddle (only when moving down)
  if (ball.vy > 0 && ball.y + R >= PY && ball.y - R <= PY+PH && Math.abs(ball.x - paddle.x) <= PW/2 + R) {
     const p = Math.max(-1, Math.min(1, (ball.x - paddle.x) / (PW/2)));
     const a = p * (60 * Math.PI/180);
     ball.vx = Math.sin(a) * speed;
     ball.vy = -Math.cos(a) * speed;
     ball.y = PY - R;
     paddleHit sound;
  }
  // bricks
  for (const b of bricks) {
    if (b.hp <= 0) continue;
    const cx = clamp(ball.x, b.x, b.x+b.w);
    const cy = clamp(ball.y, b.y, b.y+b.h);
    const dx = ball.x - cx, dy = ball.y - cy;
    if (dx*dx + dy*dy <= R*R) {
      // resolve
      if (Math.abs(dx) > Math.abs(dy)) { ball.vx = Math.sign(dx||1)*Math.abs(ball.vx); ball.x += Math.sign(dx||1)*(R - Math.abs(dx)); }
      else { ball.vy = Math.sign(dy||1)*Math.abs(ball.vy); ball.y += Math.sign(dy||1)*(R - Math.abs(dy)); }
      hitBrick(b);
      break;
    }
  }
  // bottom
  if (ball.y - R > H) { loseLife(); break; }
}
```

Wait — sign issue: if dx>0 (ball to the right of the contact point, i.e., hit the right face of the brick... no wait. Let me redo: cx = clamp(ball.x, brick). If ball is to the left of the brick, cx = brick.x > ball.x, dx = ball.x - cx < 0. The ball is moving right and hits the left face of the brick → should bounce left → vx negative. sign(dx) = -1 → vx = -|vx|. Correct.

Push out: ball.x += sign(dx) * (R - |dx|) → moves further left. Correct.

If ball center is exactly at brick.x (dx=0) and |dy| smaller... use fallback sign 1. Fine.

Edge: ball hits the corner → |dx| vs |dy| decides. OK.

hitBrick(b): b.hp--; score += 10; spawn particles at contact point; flash; sound; if hp<=0: score += 50; destroyed++; bigger particles; shake(3, 0.15); check win.

Note: speed increase should apply to the current ball velocity: rescale the vector to the new speed while preserving direction. Since we set velocity from the speed variable on each bounce, we can just store `speed` and rescale: const m = Math.hypot(vx,vy); if m>0: vx = vx/m*newSpeed, vy = vy/m*newSpeed. Do this in hitBrick after destroyed++.

Trail: array of {x,y}; push {x,y} each frame (in render or update); cap length 12; draw with alpha i/len * 0.25.

Particles: {x,y,vx,vy,life,maxLife,color,size}; update with gravity 500 px/s², life -= dt; draw with alpha life/maxLife.

Shake: shakeT (remaining), shakeDur, shakeMag. In render: if shakeT>0: shakeT -= dt (in update; but render doesn't know dt... update shake in update and also during ready? Simpler: update shake in frame() with dt regardless of state, but only when not paused. Actually, let's update shake in frame(): if (state!=='paused') updateShake(dt).

Flash: array of {x,y,w,h,t,dur}; update t; draw with white alpha t/dur * 0.8.

Render order:
1. ctx.setTransform(dpr...); clear; background.
2. save; apply shake translate.
3. Draw bricks, paddle, trail, ball, particles, flashes.
4. restore.
5. HUD (score, lives) — drawn without shake for readability.
6. State overlays: ready hint, paused, won, lost.

HUD: "SCORE 0000" top-left at (20, 30) with monospace font; lives top-right: draw 3 small circles at W-20 - i*20.

Also a small "LEVEL SPEED" indicator? Skip.

Ready state: ball follows the paddle. Draw a hint text in the center: "Press SPACE or click to launch".

Won: overlay with dark translucent rectangle, "YOU WIN!" + final score + "Press SPACE or click to play again".
Lost: "GAME OVER" + score + same hint.

Pause: "PAUSED — press P to resume".

Input handlers:
- keydown: Space → if ready: launch; if won/lost: restart; preventDefault. P/Escape? Spec says P. p/P toggles pause when playing/ready (and unpauses from paused). R → restart anytime? Let's allow R to restart from won/lost (and anytime? Keep it to won/lost + playing? Simpler: R restarts from any state — full reset. Hmm, accidentally pressing R during play would be annoying. Let's make R work only in won/lost states, plus Space/click.)
- Arrow keys: keys.left/right = true; preventDefault.
- keyup: clear.
- mousedown on canvas: ensureAudio; if ready → launch; if won/lost → restart; if paused → resume? Click to resume? Let's keep click to resume too (convenient). Actually, spec: pause with P or on window blur. Resume with P. Also allow click/Space to resume — harmless.
- mousemove: update paddle target (only meaningful in ready/playing).
- window blur: if state is playing or ready → state = 'paused'.

Also, ensureAudio on first keydown/mousedown.

Restart: reset score, lives, bricks (rebuild), paddle center, ball stuck, particles/trail/flash cleared, speed, state='ready'.

Win check in hitBrick: if destroyed === total (40) → state='won', play win jingle.

Lives display: max 3.

Now, "the ball must never tunnel through bricks, get stuck inside them, or escape the playfield even when accelerating" — substeps handle it. Also, after paddle bounce, push the ball above the paddle top to avoid re-collision: ball.y = min(ball.y, paddleTop - r).

Paddle collision: only when the ball is moving downward (vy > 0) and ball bottom >= paddle top and ball.y - r < paddle bottom (i.e., ball vertically overlaps the paddle) and horizontally within the paddle range (|ball.x - paddle.x| <= paddleW/2 + r). Then compute the angle.

Also, if the ball hits the side of the paddle — rare; treat it as a bounce with the same formula (it works, angle from the hit position).

Score display: "SCORE" and number. Lives: 3 small circles (remaining lives as filled, lost as empty?) or hearts. Draw remaining lives as small ball icons.

Also show the current speed? Not needed.

Controls outside the canvas:
- Mouse or ← → : move paddle
- Space / click: launch ball
- P: pause
- Space / click / R: restart after win/lose

Now let's write the code.

Structure of game.js:

```js
(() => {
'use strict';

// --- Setup ---
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const W = 960, H = 600;
let dpr = Math.max(1, Math.min(2, window.devicePixelRatio || 1));
function fitCanvas() { dpr = ...; canvas.width = W*dpr; canvas.height = H*dpr; }
window.addEventListener('resize', fitCanvas); fitCanvas();
// in render: ctx.setTransform(dpr,0,0,dpr,0,0)

// --- Audio ---
let audioCtx = null;
function ensureAudio() { if (!audioCtx) { try { audioCtx = new (window.AudioContext||window.webkitAudioContext)(); } catch(e){} } if (audioCtx && audioCtx.state === 'suspended') audioCtx.resume(); }
function beep(freq, dur, type='square', vol=0.15, slide=0) { if(!audioCtx) return; ... oscillator + gain, exponential ramp }

// --- State ---
const COLS=8, ROWS=5, BW=103, BH=24, GAP=8, MARGIN=40, TOP=70;
```

Wait, let's recompute BW: (960 - 2*40 - 7*8)/8 = (960-80-56)/8 = 824/8 = 103.

Brick positions: x = 40 + c*(103+8), y = 70 + r*(24+8).

Colors per row:
- Row 0: #ff5252 (red)
- Row 1: #ffb74d (orange)
- Row 2: #ffd54f (yellow)
- Row 3: #4dd0e1 (cyan)
- Row 4: #7986cb (indigo)

Top 2 rows: hp 2, rest hp 1.

Damaged look: draw the brick in a darker color + crack lines (a few random-looking but deterministic lines). Precompute crack offsets per brick? Simpler: draw 2-3 crack lines based on brick index (deterministic pseudo-random from index). Or just draw a darker fill + a crack polyline. Let's do: damaged → fill with a darker shade, stroke with a crack path made from a seed.

Simple deterministic cracks: given brick index i, use a small hash function to generate 3 segments.

Paddle: PW=110, PH=14, PY=566.

Ball: R=6, base speed 380, +8 per brick destroyed, cap 700.

Speed function: currentSpeed() = Math.min(380 + destroyedCount*8, 700).

On launch: dir angle = (-90 + rand*40 - 20) degrees → vx = cos, vy = sin (in radians). Angle from vertical: a = (Math.random()*50-25) * PI/180; vx = sin(a)*speed; vy = -cos(a)*speed.

Update loop:

```js
let last = performance.now();
function frame(now) {
  requestAnimationFrame(frame);
  let dt = (now - last)/1000; last = now;
  if (dt > 0.05) dt = 0.05;
  if (state === 'playing') update(dt);
  render();
}
```

Pause: state 'paused' — skip update, render overlay. When unpausing, `last` keeps updating each frame (since we compute dt every frame), so no jump. Good — dt is computed every frame regardless of state, so no time jump on unpause.

Paddle update: keyboard velocity 620 px/s.

Mouse: on mousemove, set targetPaddleX; in update, paddle.x = clamp(targetPaddleX). But if the mouse isn't moved, the keyboard should work — so mouse sets targetPaddleX only on mousemove events; keyboard moves paddle.x directly, and also updates targetPaddleX to the new position so the next mousemove doesn't jump... Actually, if the mouse doesn't move, targetPaddleX stays at the old value; if we set paddle.x = targetPaddleX every frame, the keyboard movement gets overwritten. Solution: on mousemove, set a flag and paddle.x directly (clamped). Keyboard moves paddle.x in update. Both modify the same x; no per-frame mouse application needed. But smooth mouse follow: direct setting is fine (cursor position). Let's do that.

Ball update (playing):
```js
const dist = speed * dt;
const steps = Math.max(1, Math.ceil(dist / 4));
const sdt = dt / steps;
for (let i=0;i<steps;i++){
  ball.x += ball.vx * sdt;
  ball.y += ball.vy * sdt;
  // walls
  if (ball.x < R) { ball.x = R; ball.vx = Math.abs(ball.vx); wallHit(); }
  else if (ball.x > W-R) { ball.x = W-R; ball.vx = -Math.abs(ball.vx); wallHit(); }
  if (ball.y < R) { ball.y = R; ball.vy = Math.abs(ball.vy); wallHit(); }
  // paddle (only when moving down)
  if (ball.vy > 0 && ball.y + R >= PY && ball.y - R <= PY+PH && Math.abs(ball.x - paddle.x) <= PW/2 + R) {
     const p = Math.max(-1, Math.min(1, (ball.x - paddle.x) / (PW/2)));
     const a = p * (60 * Math.PI/180);
     ball.vx = Math.sin(a) * speed;
     ball.vy = -Math.cos(a) * speed;
     ball.y = PY - R;
     paddleHit sound;
  }
  // bricks
  for (const b of bricks) {
    if (b.hp <= 0) continue;
    const cx = clamp(ball.x, b.x, b.x+b.w);
    const cy = clamp(ball.y, b.y, b.y+b.h);
    const dx = ball.x - cx, dy = ball.y - cy;
    if (dx*dx + dy*dy <= R*R) {
      // resolve
      if (Math.abs(dx) > Math.abs(dy)) { ball.vx = Math.sign(dx||1)*Math.abs(ball.vx); ball.x += Math.sign(dx||1)*(R - Math.abs(dx)); }
      else { ball.vy = Math.sign(dy||1)*Math.abs(ball.vy); ball.y += Math.sign(dy||1)*(R - Math.abs(dy)); }
      hitBrick(b);
      break;
    }
  }
  // bottom
  if (ball.y - R > H) { loseLife(); break; }
}
```

Wait — sign issue: if dx>0 (ball to the right of the contact point, i.e., hit the right face of the brick... no wait. Let me redo: cx = clamp(ball.x, brick). If ball is to the left of the brick, cx = brick.x > ball.x, dx = ball.x - cx < 0. The ball is moving right and hits the left face of the brick → should bounce left → vx negative. sign(dx) = -1 → vx = -|vx|. Correct.

Push out: ball.x += sign(dx) * (R - |dx|) → moves further left. Correct.

If ball center is exactly at brick.x (dx=0) and |dy| smaller... use fallback sign 1. Fine.

Edge: ball hits the corner → |dx| vs |dy| decides. OK.

hitBrick(b): b.hp--; score += 10; spawn particles at contact point; flash; sound; if hp<=0: score += 50; destroyed++; bigger particles; shake(

It's an empty directory. I'll create index.html and game.js.

Alright, game.js — the complete logic. I'll write it carefully in one go (about 450 lines, should be fine, but to be safe I'll split it into two chunks: write the first half, then append the second half with edit). Actually, a single write of about 15KB should be okay (the truncation risk is for very large writes). To be safe, I'll split it into two chunks.

Wait — there's one bug I should check: `update(dt)` is being called every frame regardless of state. Inside `update`, when state is 'paused', it calls updateJuice(dt) — meaning particles/shake keep animating even while paused. That's a minor issue, but it's probably fine (or rather, it's arguably better that way). But wait: in the 'paused' state, `movePaddle(dt)` runs before the state check! Let me re-read:

```js
function update(dt) {
  movePaddle(dt);

  if (state === 'ready') { ... }
  if (state !== 'playing') { updateJuice(dt); return; }
  ...
}
```

So even in the paused state, movePaddle runs — but the keys get cleared on blur, and the user can't hold a key while paused... actually, they could press P to pause while holding an arrow key, and the paddle would keep moving while paused. Minor, but let's fix it: only move the paddle when state is 'ready' or 'playing'.

Also, updateJuice running during pause: particles keep falling during pause. Aesthetically that's fine, but a true pause should freeze everything. Let's freeze juice during pause too.

Another issue: in 'ready' state, update() calls movePaddle and then stickBall — good. But updateJuice(dt) is called in the ready branch — good.

Also, `update` for 'won'/'lost' states: movePaddle runs (keys might still be held down) — harmless, but let's gate it.

Let me restructure:

```js
function update(dt) {
  if (state === 'paused') return;
  if (state === 'ready' || state === 'playing') movePaddle(dt);
  ...
}
```

And updateJuice only in ready/playing (and also in won/lost so the confetti-like particles from the last hit settle down — that's nice; let's keep juice updating in all states except paused).

Another check: the `frame` loop calls update(dt) every frame — in 'won'/'lost' states, update executes: state !== playing → updateJuice, return. Good.

Another check: `hitBrick` sets state='won' mid-substep; the substep loop breaks on the next iteration due to `if (state !== 'playing') break;`. Good. But note: after the substep loop, the trail push and updateJuice still execute — no problem.

loseLife: sets state='ready' or 'lost'; the loop breaks. Good.

Potential issue: ball is in 'ready' state and the window blurs → state='paused'. Then on resume (P), state='playing'?? No — the blur handler sets 'paused' from 'ready'; on resume, P sets state='playing' — but the ball was stuck! That's a bug: pressing P while paused (originating from ready) should return to 'ready', not 'playing'.

Fix: remember the state before pausing. Add `pausedFrom` variable: on pause, save `pausedFrom = state`; on resume, `state = pausedFrom`.

Similarly, onPrimaryAction from paused → should restore to pausedFrom, not unconditionally 'playing'.

Let me fix both:

```js
let pausedFrom = 'playing';
function pauseGame() { if (state==='playing'||state==='ready') { pausedFrom = state; state='paused'; } }
function resumeGame() { if (state==='paused') state = pausedFrom; }
```

Use in the P handler, blur, and onPrimaryAction.

Another subtle issue: mousemove sets paddle.x directly. In 'ready' state, stickBall keeps the ball on the paddle — good.

Another check: `drawBall` is skipped in 'lost' state (the ball is off-screen anyway). In 'won' state, the ball is still drawn — no problem, it's on the field.

One more: in 'ready' state, the ball is drawn at the paddle position — good.

Trail during 'ready': stickBall clears the trail; update in ready doesn't push to the trail. Good.

Now, the paddle's keyboard movement uses `keys` which is cleared on blur. Good.

Also, `e.repeat` guard: Space with repeat held down → only the first press is processed. Good, prevents relaunching... well, relaunching only matters in ready state; a repeat Space during 'playing' does nothing anyway.

Edge case: keydown Space in 'won' → onPrimaryAction → resetGame → state 'ready'. Good.

Now, let me re-verify the substep collision resolution when the ball is moving fast downward and hits the bottom edge of a brick: dy > 0 (ball center below the contact point... wait: ball is below the brick, moving up? No — the ball is moving up (vy<0) and hits the bottom face of the brick: cy = b.y + b.h, dy = ball.y - cy > 0 (ball center is below the bottom edge of the brick). |dy| > |dx| → s = 1 → vy = +|vy| (downward). Correct: the ball bounces back down. Push out: ball.y += (R - |dy|) → moves further down. Correct.

Ball moving down hits the top face of a brick: dy = ball.y - b.y < 0 → s=-1 → vy = -|vy| (upward). Correct.

Now, a potential subtle issue: after a horizontal bounce with `ball.x += s * (R - Math.abs(dx))`, in the case where dx is exactly 0 (ball center is exactly at the brick's x edge) and |dx| > |dy| is false → falls into the vertical branch. No problem.

Tunneling: max substep 4px < R=6. Walls are clamped. Good.

Another one: ball speed — after paddle bounce, speed is exactly `speed`. After wall/brick bounce, magnitude is preserved (sign flip of one component). setSpeed rescales. So |v| ≈ speed always holds. Good.

Score display: 5-digit padding. Max score = 40 bricks: rows 0-1 (16 bricks × (10+10+50)=70) = 1120; rows 2-4 (24 × 60) = 1440; total 2560. 4 digits is enough, but 5 digits is fine.

Lives HUD: 'LIVES' text at W-96 (right-aligned), circles at W-78, W-54, W-30. W-30+7 = 937 < 960. Good.

Now, let me also re-verify the flash drawing: roundRect is defined before use. Yes.

`drawOverlay` uses textAlign center and then resets to left. Good.

Audio: `tone` with delay parameter — win uses delay. OK.

One concern: `ctx.font` uses 'ui-monospace' — no problem, falls back to monospace.

Canvas CSS: width 960px, max-width 100% — on small screens it scales down; mouse coordinate mapping uses rect.width scaling. Good.

Now, the 'paused' overlay: drawOverlay('PAUSED', ..., 'Press P to resume') — but the overlay also shows "Press SPACE, R or click to play again" — that's misleading for pause. Let me make drawOverlay accept a third-line parameter, or handle pause separately. I'll add an optional `hint` parameter that defaults to the restart hint.

Let me apply these fixes with edit calls:

1. Add pausedFrom + pauseGame/resumeGame; update keydown P, blur, and onPrimaryAction.
2. Gate movePaddle inside update; freeze juice during pause.
3. drawOverlay hint parameter for pause.

Also, a minor point: in the blur handler, call pauseGame() instead of setting directly.

Let me write the edits.

Next, I'll read back the entire file to verify completeness and consistency, and if node is available I'll run a syntax check.

The syntax is OK. Next, I'll write a headless logic test in node, stubbing out the DOM/canvas, and verify the following:
1. That the ball doesn't tunnel through bricks even at high speeds.
2. That the ball stays within the field boundaries.
3. That the win/loss/restart cycle works.
4. That the score calculation is correct.

The game is an IIFE that uses `document.getElementById('game')`, `window.addEventListener`, `canvas.addEventListener`, `performance.now`, `requestAnimationFrame`, and `window.devicePixelRatio`. I can stub these out in node, capture the rAF callback, and manually step through frames.

Let me write a test harness:

```js
// test.js
const listeners = {};
const canvasListeners = {};
const ctxStub = new Proxy({}, { get: (t, p) => {
  if (p === 'createLinearGradient' || p === 'createRadialGradient') return () => ({ addColorStop(){} });
  if (p === 'measureText') return () => ({ width: 0 });
  return typeof p === 'string' ? (canvasStubProps[p] ?? (() => {})) : undefined;
}, set: () => true });
```

Hmm, a Proxy that returns a no-op function for any get works for most canvas methods, but properties like fillStyle get set — the set trap returns true. `ctx.canvas`? Not used. OK.

But note: the code uses `ctx.setTransform`, `fillRect`, etc. — all no-ops. No problem.

Stub:

```js
global.window = {
  devicePixelRatio: 1,
  addEventListener: (t, f) => { (listeners[t] ||= []).push(f); },
  AudioContext: undefined,
};
global.document = { getElementById: (id) => canvasStub };
global.performance = { now: () => nowMs };
let rafCb = null;
global.requestAnimationFrame = (cb) => { rafCb = cb; return 1; };
```

The canvas stub needs: getContext: () => ctxStub, addEventListener: (t,f)=>{...}, getBoundingClientRect: () => ({left:0, top:0, width:960, height:600}), and settable width/height properties.

Then, to drive it: call rafCb(t) in a loop — but the IIFE calls `requestAnimationFrame(frame)` at the end, and frame re-registers on each call. So:

```js
function step(ms) { nowMs += ms; const cb = rafCb; rafCb = null; cb(nowMs); }
```

frame calls requestAnimationFrame(frame) first, so rafCb is re-set. Good.

To test game internals (ball position, bricks, state, score), I need access. The IIFE keeps everything private. For testing, I can extract state via a different approach: modify the IIFE to expose a debug handle only when `window.__BREAKOUT_DEBUG__` is set? That pollutes the production code a bit, but it's harmless and a common technique. Alternatively, test behavior purely through observable means: rendering is a no-op, so it's not easy to observe.

Better approach: temporarily expose a debug object. Add the following at the end of the IIFE:

```js
if (typeof window !== 'undefined' && window.__breakoutDebug) {
  window.__breakoutDebug.api = { get state(){return state}, ... };
}
```

Hmm, that's an extra element. Or, in the test, read the source and eval it with the IIFE modified? Simpler: add a small debug export guarded by a flag — it's clean and doesn't affect normal operation.

Actually, the simplest and most robust approach for testing: copy game.js to a temporary file, replace the trailing `})();` with `window.__dbg = { get state(){return state}, get score(){return score}, get lives(){return lives}, get ball(){return ball}, get bricks(){return bricks}, get speed(){return speed}, resetGame, launchBall, step: (dt)=>update(dt) }; })();` and eval it in node with the stubs. This way I don't have to touch the shipping file.

Let's do that with a small node script.

Test scenarios:
1. After load, state === 'ready', 40 bricks, score 0, lives 3.
2. Call launchBall (via dbg) or simulate a Space keydown. Then step frames at 60Hz for, say, 60 seconds of simulated time, verifying each frame: ball.x is within [R-ε, W-R+ε]… actually, the ball can legitimately be below H (falling). Check: ball.x is within [0, W], ball.y < H + 50, and the ball doesn't overlap a living brick (circle-rectangle distance) — this verifies there's no sticking. Also, the ball never ends up entirely inside a brick.
3. Force high speed: set speed directly? dbg exposes the getter for speed, but I want to test tunneling at MAX_SPEED. I can expose a setter or a `setSpeedTo(v)` helper. Let me expose `setSpeedTo` in the dbg replacement: a function that sets `speed = v` and rescales the ball's velocity. Actually, setSpeed() only raises it up to the target… it rescales to the target. I can expose `forceSpeed(v)`: speed = v; const m = hypot; if m>0 scale.

Then run with speed 700, dt 1/60, and verify no tunneling: after each substep… I can't see substeps, but I can verify that at the end of each frame the ball doesn't overlap a brick (except in the instant of a hit — after resolution it shouldn't overlap). Hmm, but is it possible for the ball to overlap a brick at a frame boundary after resolution? The resolution pushes it out, so no. But it's possible for the ball to be inside a brick at a frame boundary if it collided in a later substep… no — each substep resolves immediately, so after the last substep there's no overlap. Wait, actually there's a subtle case: the ball resolves against brick A (pushed out), then continues in the same substep… no, the movement happens before the collision check within a substep; after resolution, the next substep moves again and rechecks. If the push-out + next movement pushes it into an adjacent brick, that's handled by the next substep's check. At frame end, the last substep has completed resolution. But is it possible for the ball to end a substep overlapping a brick it didn't check? The loop checks all bricks and breaks on the first hit; other bricks are unchecked in that substep, but movement ≤ 4px and the push-out is small, so the overlap with other bricks is at most a few px… theoretically, could it end a frame overlapping a second brick by up to ~4px? Possible in a corner case, but the next frame's first substep resolves it. My test assertion "no overlap at frame boundary" might rarely fail. To be safe, assert no overlap with penetration deeper than 0.5px, and separately assert the ball never fully enters a brick (center inside rectangle) — the real "stuck" failure.

Actually, a simpler and stronger assertion: the ball center never ends up strictly inside a brick's rectangle, and the ball stays within [R, W-R] horizontally, and y < H+R (bottom exit only). Also, the ball's y never jumps from above a brick's top to below the brick's bottom in one frame (tunneling) — that's implicitly covered by "center never inside a brick" + no overlap.

Hmm, but a tunneling brick: the ball passes completely through the brick in one frame — at the frame boundary it's below the brick, no overlap, center not inside. To detect this, I need to track per-frame whether the ball crossed a brick's band. Alternative: verify that the ball's y movement per frame ≤ speed*dt + ε (no teleporting) — that's trivially true.

Better tunneling check: at each frame, before the step, record the ball position; after the step, compute the line segment of the path; for each living brick, check whether the segment (with radius) intersected the brick's rectangle expanded by R… that's essentially re-implementing the collision.

Practical approach: run a long simulation (e.g., 120 seconds at 60Hz = 7200 frames) with random paddle motion and forced max speed, and assert:
- The ball center is never strictly inside a brick.
- The ball's horizontal position is within [R-0.01, W-R+0.01] (walls clamp).
- The ball's y is never < R-0.01 (ceiling clamps).
- Whenever the ball is below the paddle region and falling, a life is eventually lost (game progresses).
- The game reaches a terminal state (win or loss) or keeps playing with lives ≥ 0.
- Score consistency: score === 10*(total hits) + 50*destroyed — I can track hits via the sum of (initialHp - hp) across bricks: totalHits = Σ max(0, initialHp(b) - b.hp). destroyed = Σ (b.hp <= 0). Then score should equal 10*totalHits + 50*destroyed. This is a strong invariant!

Also, test the win: force a win by… letting the simulation run is slow. Instead, expose a dbg helper `destroyBrickAt(i)`? I can add to the dbg replacement: `killAllButOne` or directly: set all bricks' hp to 0 except one, set destroyed = 39, then hit the last one. Simpler: expose `hitBrick` and `bricks` — call hitBrick(bricks[0]) 40 times? hitBrick decrements hp; a 1hp brick dies on the first call. For 2hp bricks, call twice. So: for each brick b: while (b.hp > 0) hitBrick(b). Then state should be 'won', score = 10*ΣinitialHp + 50*40 = 10*(16*2 + 24*1) + 2000 = 10*56 + 2000 = 2560.

Then resetGame() → state 'ready', score 0, lives 3, all bricks' hp restored (16 at 2hp, 24 at 1hp), destroyed 0, speed back to 380.

Loss test: set lives=1… expose a `setLives(n)` helper? Or simulate: put the ball below the bottom: ball.y = H + 100, state 'playing', step → loseLife → lives 2, state 'ready'. Repeat 3 times → state 'lost'.

Pause test: state 'playing' → dispatch blur listener → state 'paused'; step frames → ball doesn't move; P keydown → back to 'playing'.

Also, test that pausing from 'ready' returns to 'ready'.

Input test: keydown Space in 'ready' → 'playing'. mousedown in 'won' → 'ready'.

Let me write the harness. Steps:

```js
const fs = require('fs');
let src = fs.readFileSync('game.js', 'utf8');
const tail = `
window.__dbg = {
  get state(){return state}, get score(){return score}, get lives(){return lives},
  get destroyed(){return destroyed}, get speed(){return speed},
  get ball(){return ball}, get bricks(){return bricks}, get paddle(){return paddle},
  resetGame, launchBall, hitBrick, pauseGame, resumeGame,
  forceSpeed(v){ speed = v; const m = Math.hypot(ball.vx, ball.vy); if (m>0){ ball.vx = ball.vx/m*v; ball.vy = ball.vy/m*v; } },
  setLives(n){ lives = n; },
  setBall(x,y,vx,vy){ ball.x=x; ball.y=y; ball.vx=vx; ball.vy=vy; },
};
})();`;
src = src.replace(/\}\)\(\);\s*$/, tail);
eval(src);
```

Wait, game.js ends with `})();`. The replace regex `/\}\)\(\);\s*$/` matches the trailing `})();`. The IIFE body contains many `})();`-like things? No — only the final line is `})();` (other functions end with `}`). The regex is anchored to end-of-string, so it's safe.

But `eval` in non-strict module scope… game.js starts with `(() => { 'use strict'; ...`. Eval in function scope: `window`, `document`, `performance`, `requestAnimationFrame` need to be globals. In node, define them as globals before the eval: `global.window = ...` etc. The code references bare `window`, `document`, `performance`, `requestAnimationFrame` — all resolved via global. Good.

The ctx stub: needs to handle any method call and property set. Use a Proxy:

```js
function makeCtx() {
  const target = {};
  return new Proxy(target, {
    get(t, p) {
      if (p === 'createLinearGradient' || p === 'createRadialGradient') return () => ({ addColorStop() {} });
      if (p in t) return t[p];
      return (...args) => {};
    },
    set(t, p, v) { t[p] = v; return true; }
  });
}
```

Note: `ctx.canvas` isn't used. OK.

Canvas element stub:

```js
const canvasEl = {
  width: 960, height: 600,
  getContext: () => ctxStub,
  addEventListener: (t, f) => { (canvasEvents[t] ||= []).push(f); },
  getBoundingClientRect: () => ({ left: 0, top: 0, width: 960, height: 600 }),
};
```

window stub:

```js
const winEvents = {};
global.window = {
  devicePixelRatio: 1,
  addEventListener: (t, f) => { (winEvents[t] ||= []).push(f); },
  AudioContext: undefined, // audio disabled in tests
};
global.document = { getElementById: () => canvasEl };
let nowMs = 0;
global.performance = { now: () => nowMs };
let rafCb = null;
global.requestAnimationFrame = (cb) => { rafCb = cb; };
```

Note: `window.AudioContext || window.webkitAudioContext` → undefined → audio stays null → sfx is a no-op.

Driving:

```js
function frame(ms) { nowMs += ms; const cb = rafCb; rafCb = null; cb(nowMs); }
function fireWin(type, ev) { (winEvents[type]||[]).forEach(f => f(ev)); }
function fireCanvas(type, ev) { (canvasEvents[type]||[]).forEach(f => f(ev)); }
```

The keydown event needs `code`, `preventDefault(){}`, and `repeat:false`.

The mousedown event needs `preventDefault(){}` and clientX/clientY.

Now the simulation:

```js
const D = window.__dbg;
// initial state
assert(D.state === 'ready');
assert(D.bricks.length === 40);
assert(D.score === 0 && D.lives === 3);

// launch
fireWin('keydown', { code:'Space', preventDefault(){}, repeat:false });
assert(D.state === 'playing');

// long simulation at 60Hz, paddle auto-follows the ball (to keep the ball alive longer)
let maxPen = 0;
for (let i = 0; i < 60 * 180 && (D.state === 'playing' || D.state === 'ready'); i++) {
  // move paddle toward the ball with the mouse
  fireCanvas('mousemove', { clientX: D.ball.x, clientY: 0 });
  frame(1000/60);
  const b = D.ball;
  // invariants
  if (b.x < 5.99 || b.x > 954.01) throw new Error('ball escaped horizontally: ' + b.x);
  if (b.y < 5.99) throw new Error('ball escaped ceiling: ' + b.y);
  if (b.y > 600 + 20) throw new Error('ball too far below: ' + b.y);
  // brick overlap
  for (const br of D.bricks) {
    if (br.hp <= 0) continue;
    const cx = Math.max(br.x, Math.min(b.x, br.x + br.w));
    const cy = Math.max(br.y, Math.min(b.y, br.y + br.h));
    const dx = b.x - cx, dy = b.y - cy;
    const d2 = dx*dx + dy*dy;
    if (d2 < 0.25) throw new Error('ball stuck inside brick: ' + JSON.stringify({b, br}));
    // penetration depth
    if (d2 < 36) { const pen = 6 - Math.sqrt(d2); if (pen > maxPen) maxPen = pen; }
  }
  // score invariant
  let hits = 0, dest = 0;
  for (const br of D.bricks) { const ih = br.row < 2 ? 2 : 1; hits += Math.max(0, ih - br.hp); if (br.hp <= 0) dest++; }
  if (D.score !== 10*hits + 50*dest) throw new Error('score mismatch: ' + D.score + ' vs ' + (10*hits+50*dest));
}
```

Hmm, wait — the score invariant: the score is also… only from bricks. Yes, score = 10*hits + 50*destroyed.

Note: the `b.x < 5.99` check — the ball is clamped to exactly R=6 at the wall, so b.x >= 6 always holds. Good.

One caveat: in 'ready' state, the ball is at PY - R - 0.5 = 559.5 — no problem.

Paddle auto-follow via mousemove keeps the ball alive; the ball might still be lost occasionally (deflection angles). Lives 3 → the game might end in 'lost' before 180 seconds. That's fine — the loop condition stops. But to test more, I can restart: if state is 'lost', fire mousedown (restart), continue. Let me add: if the state is 'won' or 'lost', restart via mousedown and continue the simulation. That way I can test the restart cycle too.

Also, test forced max speed: after launch, D.forceSpeed(700), run 60 seconds, same invariants.

Also, explicitly test pause:
```js
// pause on blur
fireWin('blur', {});
assert(D.state === 'paused');
const bx = D.ball.x, by = D.ball.y;
frame(1000/60); frame(1000/60);
assert(D.ball.x === bx && D.ball.y === by); // frozen
// resume with P
fireWin('keydown', { code:'KeyP', preventDefault(){}, repeat:false });
assert(D.state === 'playing');
```

But note: pausing in 'ready' → resume returns to 'ready'. Test that separately.

Win test:
```js
D.resetGame();
for (const br of D.bricks) { while (br.hp > 0) D.hitBrick(br); }
assert(D.state === 'won');
assert(D.score === 2560);
// restart via Space
fireWin('keydown', { code:'Space', preventDefault(){}, repeat:false });
assert(D.state === 'ready' && D.score === 0 && D.lives === 3);
assert(D.bricks.every(br => br.hp === (br.row < 2 ? 2 : 1)));
assert(D.speed === 380);
```

Wait — hitBrick checks `destroyed >= 40` → won. But hitBrick also calls sfx (no-op), spawnParticles (fine), setSpeed (fine).

Also, the win state: after resetGame, the state is 'ready'.

Loss test:
```js
D.resetGame();
D.launchBall(); // state playing
D.setBall(480, 700, 0, 100); // below the bottom
frame(1000/60);
assert(D.state === 'ready' && D.lives === 2);
D.launchBall(); D.setBall(480, 700, 0, 100); frame(1000/60);
assert(D.lives === 1 && D.state === 'ready');
D.launchBall(); D.setBall(480, 700, 0, 100); frame(1000/60);
assert(D.lives === 0 && D.state === 'lost');
// restart via R
fireWin('keydown', { code:'KeyR', preventDefault(){}, repeat:false });
assert(D.state === 'ready' && D.score === 0 && D.lives === 3);
```

Wait: setBall(480, 700, ...) — in the next frame's update: substeps: dist = speed*dt ≈ 380*0.0166 ≈ 6.4 → 2 substeps. Ball y 700 → moves further down. Bottom check: ball.y - R > 600 → 700-6=694 > 600 → loseLife. Good.

But note: after setBall with vy=100 downward, the paddle check: ball.vy > 0, ball.y + R >= PY (706 >= 566 yes), ball.y - R <= PY + PH? 694 <= 580? No. So no paddle bounce. Good.

Also, test that the ball is stuck to the paddle in 'ready': after resetGame, ball.x === paddle.x and ball.y === 559.5.

Also, test that the keyboard paddle stays within the field: hold ArrowRight for 5 seconds: paddle.x === 960 - 55 = 905.

Let me also verify the launch angle: after launch, |v| === 380 and vy < 0.

Another potential bug to double-check in the code: in `update`, when state === 'ready', it calls movePaddle and then stickBall — but the mousemove handler sets paddle.x directly even in 'paused' state — then on resume, the paddle is at the mouse position. Fine.

Another: `frame` clamps dt to 0.05 — in the test, frame(1000/60) → dt = 0.0166. Good.

Another check — the `hitBrick` win check: `destroyed >= COLS * ROWS`. destroyed is incremented only when hp reaches 0. Good.

Now, about the maxPen assertion: I only track maxPen and print it at the end; I don't hard-fail on small penetrations (≤ 0.5px is fine… actually, I hard-fail on d2 < 0.25, i.e., penetration > 5.75px — that's the "stuck inside" case).

Hmm, wait, there's actually a subtle scenario where the ball could end a frame overlapping a brick by a few px: the ball hits brick A in substep k, is pushed out, and in substep k+1 moves 4px into brick B (adjacent, no gap? there's an 8px gap; a 4px movement can't cross an 8px gap unless it's already close). With 4px substeps and 8px gaps, the ball can't be inside two bricks at once. Overlap with a second brick at frame end is at most ~4px penetration… but the next frame resolves it. My d2 < 0.25 threshold (penetration > 5.75) shouldn't trigger. Let me set the hard-fail threshold to penetration > 3px (d2 < (6-3)² = 9), and report the maxPen observed.

Actually, wait, there's a real edge case: the ball hits the corner of a brick diagonally; resolution picks one axis (|dx| > |dy| → x-axis). If the true geometry required a y push-out, the x push-out could leave a residual overlap… but the next substep rechecks and resolves along the other axis. Penetration is bounded by the substep distance (4px) + resolution error. A hard-fail at 3px might be too strict… let me think: worst case, the ball is pushed out along the x-axis, but the y-overlap remains (the ball's center is still within the y-range of the brick and x is just outside the edge by R - |dx|). After the push, distance to the closest point: x is exactly R away horizontally, dy is small → d² = R² + dy² > R² → no overlap! Because the push-out places the ball center exactly R away along the resolved axis from the closest point… wait, the closest point is recomputed after the push. If I push x so that |dx'| = R exactly (dx' = ball.x - cx, cx = brick edge), then d² = R² + dy'² ≥ R² → no overlap. Unless the push is insufficient: the push amount is R - |dx|, so |dx'| = R exactly. Then d² = R² + dy'². If dy' ≠ 0, d > R → no overlap. If dy' = 0, d = R → tangent, no overlap (d2 <= R² is the collision test: d2 = R² → collision true! `dx*dx + dy*dy <= R*R` — tangent counts as a collision, but that's fine, it just re-resolves with zero push).

So after resolution, the ball is never overlapping that brick. Other bricks: the ball moved at most 4px this substep before the check; it can't reach another brick (8px gap + geometry). At frame end (after the last substep's resolution), no overlap with any brick… except: the last substep's movement could push the ball into a brick, but the check runs after the movement in the same substep — yes, the check runs after the movement in the same substep. So at frame end, no overlap at all.

But wait — the order within a substep: move → wall → paddle → brick → bottom. After the brick resolution, the bottom check. Then the next substep. So at frame end, the last substep's brick check has run. No overlap. Except the paddle: after the paddle bounce, the ball is placed at PY - R — no overlap. Walls are clamped. So I can hard-fail on any overlap (d2 < R² - 0.001). Let me use d2 < 35.9 (penetration > 0.01px). Hmm, floating point: the push-out is exact in arithmetic: ball.x += s*(R - |dx|) → new dx' = dx + s*(R-|dx|) = s*|dx| + s*(R - |dx|) = s*R. Exact in real arithmetic; in floating point, ~1e-13 error. d2 = R² + dy'² vs the R² comparison — with dy'=0, d2 might be R² ± 1e-12. The collision test `<= R*R` is only used inside the game loop (re-resolving with a zero push is harmless). In the test, use a threshold: fail if d2 < R² - 0.5 (i.e., penetration > ~0.04px). That's safe.

Also, the "center strictly inside a brick" check: cx === b.x && cy === b.y (clamp returns the ball position) → dx=dy=0 → d2=0 → caught by the same check.

Next, the tunneling check: the ball's y per frame: |Δy| ≤ speed*dt + 1. And the ball's x is within [6, 954] each frame. The ceiling y ≥ 6. These + no overlap = no escape.

Also, I want to verify the ball actually hits bricks during the simulation (the sim isn't degenerate): at the end, assert destroyed > 0 or hits > 0. With the paddle auto-following, the ball bounces around; it should hit bricks. Track totalHits across the whole run.

Edge: the ball's vy could become very small (nearly horizontal) → the ball loops horizontally between walls forever, hitting the top row? A nearly-horizontal ball at some y bounces off the left/right walls forever without hitting bricks (if y is below the bricks). The launch angle is at most 25° from vertical, so |vx| ≤ 0.42*speed initially. Paddle deflection is at most 60° from vertical → |vx| ≤ 0.866*speed, vy ≥ 0.5*speed. So the ball always has a decent vertical component → it eventually reaches the brick zone. It won't get stuck in a horizontal loop. Good.

But could the ball get stuck bouncing between the paddle and the ceiling in a 2-cycle without hitting bricks? Possible in principle, but with angle changes on each paddle hit (position-dependent), it escapes. In the test, the paddle follows the ball's x → the hit position is near the center → a nearly vertical bounce → the ball goes straight up and down, hitting the top row of bricks (the ball's x is roughly constant; the top row spans the full width) → it hits a brick. Good, actually deterministic: the paddle perfectly follows → the ball bounces vertically at a fixed x → hits a brick in the top row.

Hmm, wait, one more: mousemove sets paddle.x = clamp(ball.x) — the ball is above the paddle, moving up; the paddle follows the ball's x; the ball comes down at the same x → the hit position is centered → a vertical bounce. The ball cycles vertically at x, hitting bricks in the column above x. Each hit destroys/damages a brick; the ball bounces back down, up again… it destroys the whole column, then… the ball keeps bouncing at the same x, hitting the next row in that column. Eventually all 5 bricks in that column are destroyed; the ball passes through the gap, bounces off the ceiling, comes back, hits bricks in the same column of the next row… wait, the column is fully cleared → the ball passes through, bounces off the ceiling, comes back, no bricks in that column → the ball falls, the paddle catches it, vertical bounce again, same column — forever, with no more bricks there! The sim could stall with bricks remaining elsewhere.

To avoid a degenerate sim, add a small random offset to the paddle target: clientX = ball.x + sin(i)*40. Then the hit position varies → deflection angles vary → the ball roams the field. Let me use a noisy target: `fireCanvas('mousemove', { clientX: D.ball.x + Math.sin(i * 0.7) * 60, ... })`.

This gives varied deflections. The ball should roam and destroy bricks. If the game is lost (3 lives), restart and continue.

Let me also add a stall detector: if no brick is destroyed for 30 seconds (1800 frames) and the state is playing, log a warning and… just log it; the test asserts totalHits > 0 overall. Actually, let me assert that the sim destroys at least, say, 10 bricks in total across the restarts. With the noisy paddle, that should be easy.

Now, let me also double-check the `update` function when state === 'won'/'lost': it calls updateJuice and returns — the ball isn't updated, fine.

And `frame` always calls update(dt) — in 'paused' it returns immediately. Good.

Another possible issue: `movePaddle` is called in both 'ready' and 'playing' — after the fix, yes.

Also, the initial `last = performance.now()` → nowMs=0 → the first frame's dt = 0 → no problem.

Also, check the HTML: the script tag `game.js` is at the end of body — the canvas exists before the script runs. Good.

Alright, let me write the test file and run it.