Brick breaker · laguna-s-2.1

Let me start by understanding the environment. I need to build a brick-breaker game using Phaser. Let me first check the current directory and verify the phaser.min.js file is present.

The phaser.min.js is present. Let me check the Phaser version to understand the API I'll be working with.

Phaser 3.80.1. Now let me build the brick-breaker game. I'll write a complete index.html with everything inlined.

Key requirements:
1. Paddle, ball, wall of breakable bricks. Move paddle with Left/Right or mouse, keeping it inside playfield.
2. Ball rests on paddle initially. Space or visible Launch control starts it. Bounce off paddle and playfield walls. Hitting a brick removes it and increases score once.
3. Three lives. Ball falling below paddle costs one life and returns to launch state if lives remain.
4. Clearing all bricks = win state. Losing all lives = Game Over. Restart restores all bricks, score, lives.
5. Show controls and generate all graphics using Phaser Graphics or generated textures. No image/audio assets.

Let me design this carefully.

Game constants:
- Playfield: 800x600 typical, let me use that.
- Paddle: width 100, height 20.
- Ball: radius 10.
- Bricks: rows of 5 colors, each row maybe 10 bricks wide.
- Lives: 3.

Game states / phases:
- LAUNCH: ball resting on paddle. Press Space or click Launch button to start.
- PLAYING: ball moving, physics active.
- BALL_LOST: ball fell below paddle. Decrement life. If lives remain, back to LAUNCH. Else Game Over.
- WIN: all bricks cleared.
- GAME_OVER: no lives.

Let me think about the physics. Phaser 3 arcade physics. I'll use ArcadePhysics.

Ball:
- setCollideWorldBounds(true) so it bounces off walls and top.
- Bounce 1,1.
- velocity initially 0.
- On launch: set velocity x,y.

Actually with ArcadePhysics, using a fixed velocity and bounce, the ball will reflect. Let me set velocity on launch with some angle.

Paddle:
- static or dynamic body? Let me use a dynamic body or a moving body with immovable.
- Actually for paddle, use a body that is immovable so it doesn't get pushed by the ball. Use setImmovable(true).
- Move paddle with cursor keys or mouse.

For mouse control, I'll track pointer position and move paddle to it (clamped to playfield). But the paddle body should be moved via position. Let me handle input each frame.

Let me think about the ball resting on the paddle. When in LAUNCH state, the ball is positioned on top of the paddle and follows the paddle's x position. Disable physics velocity / set body enabled false? Actually easier: keep ball as a physics body but set velocity to 0 and let it just sit on the paddle. But physics would still apply gravity. Let me disable gravity on the ball (no gravity in breakout anyway, arcade doesn't have gravity by default unless set). Actually ArcadePhysics world gravity defaults to 0. So no gravity. Good.

But if I keep the ball as a physics body with collide against paddle, when resting it might jiggle. Let me handle the LAUNCH state by making the ball a normal sprite that follows the paddle position, with physics body but velocity 0 and not colliding (or colliding but paddle immovable). Actually simpler: when in launch, set ball body checkCollision none, keep it positioned on paddle top, set velocity 0.

Let me design collision:
- Bricks: physics bodies, setDisable after hit. Collide ball with bricks -> on overlap, destroy brick, score++.
- Use collider for paddle/ball/walls, and overlap (or collider with callback) for bricks.

Actually for bricks, I want to remove on hit. Use overlap with ball and brick, callback removes brick and updates score.

For paddle-bounce: use a collider. When ball hits paddle, bounce. But we also want angle control based on where ball hits paddle (more realistic). Let me add a custom bounce: on overlap with paddle, adjust velocity based on hit position. Actually a simple approach: normal arcade bounce works fine. But to make it more playable, let me compute bounce based on distance from paddle center.

Let me keep it robust: 
- ball.setCollideWorldBounds(true), ball.setBounce(1).
- paddle as immovable body, collide ball<->paddle via physics collider with a callback that adjusts bounce direction based on relative hit position. This improves playability.

Let me write a paddleHit callback: 
```
function paddleHit(ball, paddle) {
  // adjust x velocity based on where ball hit paddle
  var relative = (ball.x - paddle.x) / (paddle.width/2);
  ball.setVelocityX(Phaser.Math.Clamp(relative * maxSpeed, -maxSpeed, maxSpeed));
  // ensure y velocity is upward-ish
  ball.setVelocityY(-Math.abs(ball.body.velocity.y) || -speed);
}
```

But using a collider callback means we can modify. Let me use `this.physics.add.collider(ball, paddle, paddleHit)`. Good.

Now world bounds: width 800, height 600. Ball bounces off top and sides. Bottom — ball falling below paddle loses a life; so we should NOT have collideWorldBounds on bottom, OR we detect when ball.y > paddle.y (below). Let me set world bounds to allow bottom to be a "death zone". 

Actually `setCollideWorldBounds(true)` makes it bounce off ALL bounds including bottom. I don't want bottom bounce. Instead I'll create a custom bottom sensor: a kill zone sprite at the bottom that triggers overlap with ball -> ball lost.

Approach:
- World size 800x600.
- Ball has collideWorldBounds for left/right/top only? Arcade's collideWorldBounds bounces on all walls. Hmm.

Alternative: Make the world 800x600 but disable bottom collision by using setCollideWorldBounds and then... not possible per-wall. 

Better: Use a static body "bottom" zone that overlaps (not collides) — actually I want ball to pass through bottom to trigger loss but bounce off left/right/top.

Simplest robust approach: Don't set collideWorldBounds on the ball. Instead create static walls (left, right, top) as separate static bodies for bouncing, and a bottom sensor zone for losing.

Let me do that:
- Create left, right, top walls as static bodies (Physics) placed at edges. Ball collides with them (bounce).
- Bottom zone: static or just an invisible sprite at y=590..600 height, as an overlap sensor with the ball. When overlapped, trigger ball loss.

But static body walls + collide will bounce ball with bounce set on ball. Actually for arcade, when a dynamic body collides with a static body, the bounce is determined by the dynamic body's bounce. So set ball.setBounce(1). Good.

Hmm, but static walls need to have setBounce? Static bodies have a bounce of 0 by default but... Actually when colliding, the resulting bounce uses both bodies' bounce. For a static body, if its bounce is 0, the collision may not bounce. Let me setBounce on the static walls too, or use velocity reflection. Actually in Arcade, the formula: the separation and the body's "bounce" combined. Let me just set world.setBounds and use setCollideWorldBounds but handle bottom separately.

Wait, let me reconsider. Using setCollideWorldBounds(true) reflects off all four walls. For bottom, I can check: in the ball's physics step / update, if ball.y > bottom threshold AND not in a special handling... but the bounce would reflect it back up. 

Actually, I think the cleanest: Use Arcade world with bounds 800x600. Ball: setCollideWorldBounds(true). Then the bottom acts as a wall that bounces. To detect "ball lost", I can't easily because it bounces. Unless I make the bottom wall not bounce.

Let me go with explicit walls - cleaner control:
- Left wall: x at 0, width 10, full height. static.
- Right wall: x at 790, width 10.
- Top wall: y 0, height 10.
- Bottom: NOT a wall. Instead a sensor zone y 570 height 30, overlap -> ball lost.

Set ball bounce 1. Ball collides with left/right/top walls. Ball overlaps bottom zone -> lost.

This is clean. Let me go with that.

Actually, simpler still and very standard: Use `this.physics.world.setBounds(0, 0, 800, 600)` and `ball.setCollideWorldBounds(true)`. Then to handle bottom, override by checking position each frame: if ball.y > gameHeight (i.e. went below) ... but collideWorldBounds prevents it going below. 

Hmm the issue is collideWorldBounds stops it. So I'll use explicit walls. Let me do explicit walls.

Let me also think: I want the ball to bounce, and when it hits the paddle, bounce differently. With a collider and callback, I handle paddle bounces. Walls are handled via collideWorldBounds-like static walls.

Let me also reconsider: maybe set world bounds but disable bottom using `ball.body.onWorldBounds = false`? Not possible per-wall.

OK explicit walls it is. Actually, I realize I can use setCollideWorldBounds(true) but only register worldbounds collision for walls I want, then for bottom detection use the fact that... no.

Decision: explicit static walls for left/right/top + bottom sensor for loss. Ball has setBounce(1), setCollideWorldBounds(false) (default). Actually with explicit walls I don't need collideWorldBounds.

Wait, but if I want the ball to also collide with paddle and bricks, I'll use colliders/overlap separately. Good.

Let me structure the code:

Setup:
```
const config = {
  type: Phaser.AUTO,
  width: 800,
  height: 600,
  parent: 'game',
  physics: { default: 'arcade', arcade: { debug: false, fps: 60 } },
  scene: { preload, create, update, ... }
};
```

Hmm, I'll use a Scene class or plain object. Let me use a class for organization, but simpler with plain functions sharing a state. I'll use a single Scene with create/update.

Variables: paddle, ball, cursors, bricks (group), score=0, lives=3, gameState.

Create walls:
```
const w = 800, h = 600;
const wallL = this.physics.add.existing(... static).
```
Let me use `this.add.rectangle` with physics:
```
const walls = this.physics.add.staticGroup();
walls.create(w/2, 0, null, null).setDisplaySize(w, 10)...
```
Hmm easier: create rectangle GameObjects and enable physics.

Let me do:
```
const bounds = this.physics.add.staticGroup();
const topWall = this.add.rectangle(w/2, 5, w, 10, 0x555555).setOrigin(0.5);
const leftWall = this.add.rectangle(5, h/2, 10, h, 0x555555).setOrigin(0.5);
const rightWall = this.add.rectangle(w-5, h/2, 10, h, 0x555555).setOrigin(0.5);
this.physics.add.existing(topWall, true); // true = static body
this.physics.add.existing(leftWall, true);
this.physics.add.existing(rightWall, true);
```
And the ball collides with these. Since they're static bodies with bounce 0, the ball (bounce 1) should still reflect. Actually let me verify: In Arcade, collision bounce = body1.bounce + body2.bounce? The reflection uses (1+restitution)... Let me just set the ball's bounce and also set walls bounce. For static bodies, setBounce works too.

Actually, I recall that for Arcade physics, `setBounce` on a static body does affect collision. But to be safe, let me make the walls also bouncy: `topWall.body.setBounce(1)` ... but static bodies' velocity is 0 so the bounce reflection should still occur via the dynamic body. 

Hmm, let me just rely on a simpler approach: use `this.physics.world.setBounds` AND handle bottom via overlap sensor, and for top/left/right set collideWorldBounds. But bottom bounce... 

OK you know what, I'll just use collideWorldBounds(true) for the ball and NOT use bottom as a bounce. Instead I'll set the world bounds to be taller than the visible area isn't needed... 

Let me reconsider cleanly. The simplest reliable approach that I KNOW works in Phaser:
```
ball.setCollideWorldBounds(true);
ball.setBounce(1, 1);
this.physics.world.setBounds(0, 0, 800, 600);
```
Now bottom bounce is active. To detect loss, I can use `ball.body.onWorldBounds` callback. Actually Phaser supports world bounds events: `this.physics.world.on('worldbounds', callback)`. The callback receives (gameObject, isFromLeft, isFromRight, isFromTop, isFromBottom). When the ball hits the bottom, isFromBottom = true! 

So I can:
- Set collideWorldBounds(true) for natural bouncing off walls.
- Use worldbounds event to detect bottom hits. When isFromBottom, treat as ball lost.

Wait but if it bounces off bottom, the event fires. I'd then manually handle: ball lost. But the bounce already happened (velocity reflected). I can in the callback zero out velocity and trigger loss. Let me think: When ball hits bottom wall, Arcade reflects it (velocity.y *= -bounce). The worldbounds event fires with isFromBottom=true. In my callback, I set ball body to be "lost": stop the ball (setVelocity(0)), trigger life loss, reposition to paddle. 

Actually there might be a subtlety: the worldbounds reflection happens and then the event. I can in the callback set ball velocity to 0 and mark it as lost, ignoring the bounce. That works.

But to be safe and clear, I prefer the explicit bottom sensor approach. Let me use a hybrid: explicit side/top walls as static bodies, bottom as overlap sensor. This avoids the bounce-on-bottom issue entirely and gives clear loss detection.

Let me write a helper to create a wall:
```
function makeWall(x, y, w, h) {
  const wall = scene.add.rectangle(x, y, w, h, 0x888888);
  scene.physics.add.existing(wall, true);
  return wall;
}
```
Then colliders: `this.physics.add.collider(ball, wallsGroup, null, null, this);` Actually collider between ball and a static group works. Let me create all walls in a static group and add one collider.

For bottom sensor: an invisible rectangle at bottom, set as overlap:
```
const bottomSensor = this.add.zone(400, 580, 800, 40).setOrigin(0.5);
this.physics.add.existing(bottomSensor, true); // static body
this.physics.add.overlap(ball, bottomSensor, ballLost, null, this);
```
Hmm but overlap with static body — the ball's body must be enabled. Overlap works.

Actually I realize there's a concern: the bottomSensor overlap might trigger while ball is resting on paddle if paddle is at bottom. Paddle is at bottom area (y ~ 550-560). The sensor at y 580 height 40 covers 560-600. The ball on paddle would be at y ~530 (radius 10 from paddle top). So ball center y ~540 when resting, which is above 560. Good, won't trigger. Let me set sensor at y 600-10 = 590 height 20 → covers 580-600. Ball lost when center y > 580. Paddle at 550, ball on top at 540. Fine. But when ball is moving fast it might skip — unlikely at 60fps. Acceptable.

Actually, let me reconsider: I want the ball to clearly pass below the paddle. Let me make sensor y=610 (just below visible) height=20, covering 600-620. Ball center > 600 triggers loss. Ball on paddle ~540. Good. Let me put y = 610.

Hmm but the bottom sensor is below the visible playfield (600). That's fine, invisible.

OK. Let me also double check collider between dynamic ball and static walls bounces. Yes, Arcade: when a dynamic body collides with a static body, the dynamic body bounces according to its own bounce and the static body's bounce (which defaults to 0). With dynamic bounce 1 and static bounce 0, the effective... Actually the standard result: a ball with bounce 1 hitting a static wall will reverse velocity (reflect). Let me confirm by recalling: `body1.bounce` and `body2.bounce`. The separation velocity = -(1+e)*v_rel where e... In Phaser Arcade, the bounce used is `Math.max(body1.bounce.x, body2.bounce.x)`? Not exactly.

Hmm, I'm not 100% sure static body bounce=0 would reflect a bounce=1 ball. Let me just SET the static walls' bounce to 1 too, to be safe. Static bodies do support setBounce. Let me setWall bounce 1.

Actually, I recall that Arcade Physics' collide does properly reflect a bouncy dynamic body off a static body regardless. But to be 100% safe I'll setBounce(1) on walls too. Let me also give walls `body.setAllowGravity(false)` (static bodies don't have gravity anyway).

Alright, let me also handle the paddle collision. I'll use a collider with processCallback to allow the collision (so it bounces) and a callback to customize bounce direction. Actually for paddle, I want custom bounce. Let me use an overlap? No, overlap doesn't separate. I want the ball to bounce. Let me use a collider with a custom callback that adjusts velocity. When the callback runs, the bounce physics already happened (velocity reflected). I then override the velocity with my custom values.

Actually, simpler and robust: make the paddle a static body? If paddle is static and immovable, the ball reflects off it. But paddle moves (player controls). Static bodies can be moved but it's not ideal for continuous movement (setVelocity on static body moves it kinematically but Arcade handles it via position). Hmm.

Let me make paddle a dynamic body, setImmovable(true), so it doesn't get pushed by the ball. Move via setting position or velocity. With immovable, when ball hits paddle, ball bounces off based on its own bounce and paddle's bounce. Good enough for reflection. Then add a callback to tilt the angle based on hit position for better playability.

So:
```
paddle.body.setAllowGravity(false);
paddle.setImmovable(true);
paddle.setBounce(1); // to ensure reflection
this.physics.add.collider(ball, paddle, paddleHit, null, this);
```
In paddleHit(ball, paddle): customize.

For brick collision: bricks are static or dynamic? Make them static (so they don't fall). Use overlap to remove:
```
this.physics.add.overlap(ball, bricks, brickHit, null, this);
```
In brickHit: get the brick, destroy it, increment score.

But if bricks are static bodies, overlap works. Good. Also I might want a collider for visual separation but overlap removal is enough.

Actually there's a subtlety: if ball overlaps brick and overlaps at same time as other things, Arcade processes all. Fine.

Let me make bricks static group.

Let me also add score/lives text and a Launch button and control instructions.

Controls display: show text "← → move paddle | SPACE or Launch button: launch ball | [R] restart" plus live buttons.

Visible Launch control: a button. On mobile/touch it helps too. Let me create a Phaser text button.

Restart: visible button too? The requirement says "Restart restores all bricks, score, and lives." I'll make a restart button appear in win/gameover states, and also support R key.

Let me design states:
- gameState = 'LAUNCH' (waiting to launch). Ball on paddle, velocity 0.
- 'PLAYING'
- 'WIN'
- 'GAME_OVER'

When LAUNCH: show launch button. On launch, set velocity, switch to PLAYING.
When ball falls: lives--. If lives>0, reset ball to paddle, LAUNCH. Else GAME_OVER (show restart).
When bricks cleared: WIN (show restart).
Restart: reset lives=3, score=0, rebuild bricks, LAUNCH.

Implementation of building bricks: 5 rows, each row 10 bricks (or 11). Colors: red, orange, yellow, green, blue. Each brick 70x25, gap. Let me compute: width 70, 11 bricks = 770 + gaps. With 800 width, 11 bricks + 12 gaps of ~3 → 770+36=806 too wide. Let me do 10 bricks: 700 + 11*3=33 → 733 + start offset ~34. Fine. Or brick width 64 * 11 = 704 + 12*3=36=740, offset 30. Let me use rows that have increasing health in some versions, but requirement says hit once removes + score once. So each brick is 1-hit.

Let me do 5 rows × 10 bricks. Offset so centered.

Bricks group: `bricks = this.physics.add.staticGroup()`. Create with `bricks.create(x,y,rect)...` Actually creating from a texture. Let me create a generated brick texture or just rectangle GameObjects added to static group.

`this.physics.add.staticGroup()` accepts children. But creating static bodies from rectangles: `bricks.create(x, y)` by default creates an image with 'ball' key... no. Let me use:
```
const brick = this.add.rectangle(x, y, BW, BH, color);
this.physics.add.existing(brick, true);
bricks.add(brick);
```
Then overlap ball with bricks.

Alternatively use `this.physics.add.staticGroup({ key, ... })`. But rectangles aren't keyed. I'll just create and physics-add manually, then group them so overlap uses group.

Actually overlap can be between ball and a group: `this.physics.add.overlap(ball, bricks, brickHit)`. The bricks is a Group of static bodies. Good.

Let me make bricks a Group (not staticGroup) and use `this.physics.add.existing(brick, true)` for each, adding to the group. That should work.

Let me store bricks also for clearing/rebuild. I'll just destroy all and recreate on restart.

For "clearing all bricks", check `bricks.getChildren().length === 0` after each hit. When 0, WIN.

Now ball rest on paddle: 
```
function resetBall() {
  ball.setVelocity(0);
  ball.body.checkCollision.none = true; // disable collision during launch rest
  ball.x = paddle.x;
  ball.y = paddle.y - paddle.height/2 - ballRadius;
  ball.body.allowGravity = false; // no gravity anyway
  ball.setCollideWorldBounds(...); // keep bouncing
}
```
Hmm, but checkCollision.none=true disables collisions entirely for the ball body. Then on launch I re-enable and set velocity. But the bottom sensor overlap uses the ball body's overlap — if checkCollision.none, overlap won't process. During LAUNCH the ball isn't falling anyway (velocity 0), so no bottom trigger. Fine. On launch: setVelocity, checkCollision.none=false.

Wait but during LAUNCH the ball sits on paddle moving with paddle (I position ball.x = paddle.x each frame). So ball follows paddle. Good.

Let me handle the ball following paddle when in LAUNCH: in update, if state==='LAUNCH', set ball.x = paddle.x (ball.y stays above paddle).

Launch control: space key or button. On launch: ball.setVelocity(...); enable collisions; state=PLAYING.

Ball velocity: let me give it a fixed speed, e.g. 300, angle depending on direction. Actually classic: velocity x random or based on paddle hit. On first launch, give a fixed upward velocity, e.g. setVelocity(-200, -300) or random left/right. Let me do setVelocity(200, -300) with bounce 1. Actually I'd like the angle to vary. Let me pick: vx = random between 150-250 * (random sign). Use Phaser.Math.Between or getRandomFloat.

Paddle movement: cursors left/right, set paddle velocity (with allowGravity false, immovable so it stays). Or set paddle.x directly. Let me set velocity clamped, and also clamp x within playfield (paddle.width/2 to 800-paddle.width/2). Using position clamp is more reliable. Let me move via velocity but clamp position each frame.

Mouse control: pointer.x — move paddle center to pointer.x (clamped). On desktop mouse, pointer.x is the mouse x. So in update, if pointer is down or just move paddle toward pointer.x. Requirement: "Move the paddle with Left/Right or the mouse". Let me move paddle to follow pointer.x when mouse is active. I'll just always set paddle to track pointer.x if within playfield (when pointer exists). Hmm but that conflicts with keyboard. Let me do: keyboard takes priority if a key is pressed; else mouse tracking. Simpler: if mouse moved significantly, move paddle to pointer.x; keyboard also works. They can coexist (last one wins). I'll implement both: keyboard velocity-based movement; if no key pressed, set paddle.x = pointer.x (clamped). Actually to avoid jitter, I'll do:

```
if (cursors.left.isDown) { paddle.setVelocityX(-paddleSpeed); }
else if (cursors.right.isDown) { paddle.setVelocityX(paddleSpeed); }
else { paddle.setVelocityX(0); /* mouse tracking */ paddle.x = Phaser.Math.Linear(paddle.x, pointer.x, 0.2); }
```
And clamp position: `paddle.x = Phaser.Math.Clamp(paddle.x, paddle.width/2, 800-paddle.width/2)`.

But pointer.x only valid when pointer exists. In Phaser, `this.input.activePointer` always exists (defaults to mouse). Fine.

Hmm, using Linear smoothing for mouse makes it responsive. But for keyboard, setVelocityX. Since paddle is immovable and no gravity, velocity moves it. Good.

Actually, careful: if paddle is immovable=true, the ball won't push it. But the paddle's own velocity moves it. setImmovable affects collision response (won't be moved by collisions), not own movement. Good.

Paddle bounce customization: I want the ball to bounce off paddle with a direction based on impact. With ball bounce 1 and paddle bounce 1, on collision the ball reflects. The reflection angle depends on relative velocity. To make it predictable and fun, I override in paddleHit callback:
```
function paddleHit(ball, paddle) {
  let diff = ball.x - paddle.x;
  let normalized = diff / (paddle.width/2);
  let angle = Phaser.Math.DegToRad(90 - normalized*60); // aim up
  let speed = ball.body.speed || 300; ... 
  ball.setVelocity(Math.cos... )
}
```
Hmm. Let me do simpler: keep horizontal reflection but scale vx by normalized impact, vy upward.
```
function paddleHit(ball, paddle) {
  let diff = ball.x - paddle.x;
  let norm = Phaser.Math.Clamp(diff/(paddle.width/2), -1, 1);
  let speed = Math.sqrt(ball.body.velocity.x**2 + ball.body.velocity.y**2) || 300;
  // reflect: new vy = upward; new vx based on norm
  let vx = norm * speed;
  let vy = -Math.abs(ball.body.velocity.y); // upward
  // ensure minimum upward
  if (vy === 0) vy = -speed;
  ball.setVelocity(vx, vy);
}
```
But the collider callback fires AFTER the physics solved the collision (which already reflected). Overwriting velocity should be fine; though there's a subtlety that the ball might be overlapping paddle. Arcade separates them. The callback runs after separation. Setting velocity overrides. Good.

Edge: if ball hits paddle near top edge going down, fine. If the ball is slow it might get stuck? No, vy upward set.

Let me make sure ball.y when resting is above paddle so it doesn't fall through. During LAUNCH, physics collisions are disabled (checkCollision.none) so ball just sits. Good.

Now, the bottom sensor overlap and the ball: while ball falls, overlaps bottomSensor → ballLost. Set ball velocity 0, disable, state handling.

But wait: the bottom sensor is below the world? It's at y=610. World bounds (if using setCollideWorldBounds) — but I'm using explicit walls (top/left/right) and NOT setCollideWorldBounds, so bottom is open. Good, ball can fall past 600 to 610 hitting sensor. 

Let me make walls: top wall at y=5 h=10; left x=5; right x=795. Ball radius 10, so ball center can go to 5 (left edge) — left wall at x=5 width10 covers 0-10, ball center at 10 would just touch. With bounce, ball reflects around center 10. Fine. Actually I want ball to not go off-screen. Let me set walls at x=5 (left edge at 0) covering 0-10, ball center reflects at 10. Good enough; ball radius 10 means visible edge at 0. Fine.

Hmm wait, let me set world to 800 wide, walls at x=5 (so left edge 0). Ball center reflects when ball.x - radius = 0 → x=10. With wall thickness 10 spanning 0..10, the collision happens around there. Fine.

Now let me think about whether to use setCollideWorldBounds or explicit walls. I'll use explicit walls for full control and to skip bottom. Let me also disable default world bounds collision by leaving ball's setCollideWorldBounds false (default). Good.

Let me now also reconsider: using `this.physics.add.collider(ball, wallsGroup)` — for a group of static bodies, collider works. Good.

Let me write the code now.

Also need to handle: when ball lost during PLAYING, after decrementing lives, reset ball to LAUNCH. The restart button and R key.

For the visible Launch button: I'll create a text or zone button. Let me use a styled text with set interactive, or a rectangle with text. I'll make a rectangle button at center-bottom or center.

Let me make a function createButton. Actually I'll make buttons as rectangles with text, setInteractive, on('pointerdown'). I'll manage visibility via setState.

Let me keep it simpler: Use DOM? No, must be in canvas/Phaser. Use Phaser text + rectangle.

Let me define:
```
launchBtn: the visible "Launch" button (shown in LAUNCH state).
restartBtn: shown in WIN/GAME_OVER.
```

Let me write the full HTML.

Let me think about timing for the launch: when player clicks Launch or presses Space in LAUNCH state, set velocity and switch to PLAYING.

For Space: `cursors.space` is `this.input.keyboard.addKey(Phaser.Input.Keyboard.KeyCodes.SPACE)`.

Now, I want the opening to be inspectable. Let me ensure the scene creates everything and the ball is visibly resting on the paddle, bricks laid out, paddle controllable, Launch button visible.

Let me also add a "Controls" text at top.

Let me now also consider the bottom sensor might interfere with paddle? No.

Let me also make sure ball doesn't get stuck inside bricks when overlapping multiple at once. Arcade overlap processes each. Destroy each. Fine.

One concern: ball overlap with bricks — if the ball is small and brick is wide, when the ball hits a brick corner it might both overlap detection. Removing it is fine.

Also when ball rests on paddle and we set checkCollision.none, but we still want overlap with bottom sensor? During LAUNCH the ball is at y ~540, sensor at 610, no overlap. Fine. But also ball overlap with bricks disabled — ball is near top, no bricks there during launch. Fine.

Edge: After launch, re-enable collisions. Set ball.body.checkCollision.none = false. Also ball.body.checkCollision.up/left/right/down = true (default).

Let me also ensure the ball's `body.onWorldBounds` not used.

Alright, also need to make sure that when I enable collisions after launch, the overlap and collider registrations are still active (they are registered once). Good.

Now let me consider the paddle-bounce callback signature. `this.physics.add.collider(ball, paddle, collideCallback, processCallback)`. In collideCallback, I set velocity. But the default collision would also have reflected. Setting velocity overrides. But there's risk the ball keeps overlapping paddle due to my changes. The collider's separation moves them apart; my velocity change makes it move up. Should be fine.

Actually, a cleaner approach: use a processCallback that returns true to allow collision, and use the default physics bounce (ball bounce 1 + paddle immovable). Then I don't even need to override velocity. But the angle based on paddle hit is nice. Let me keep the override but keep it minimal.

Hmm, let me reconsider: if I make paddle `setImmovable(true)` and give paddle bounce 0 and ball bounce 1, on collision ball reflects off (its own bounce). The reflection angle equals the incident angle relative to the normal. With paddle flat (horizontal top), normal is vertical → ball reflects symmetrically (vx unchanged, vy reversed). That's classic breakout. Good. The paddle-hit callback for custom angles is a bonus. Let me include a mild version but not essential.

Let me write the paddleHit to set vy based on impact and add spin. Keep simple.

Let me now also make the ball's max speed consistent: after many bounces the ball keeps speed (bounce 1 conserves energy). Good. But the paddle override might change speed — let me preserve speed magnitude. I'll compute speed from current velocity.

Let me write it.

Let me also add sound? No audio assets allowed (and no network). Skip audio. Could use WebAudio generated beeps, but requirement says no audio assets; generated audio might be allowed but to be safe skip. Actually "Do not load image or audio assets." Generated audio via WebAudio is not "loading assets", but it's extra. I'll skip audio to keep it simple and avoid issues.

Now let me write index.html.

Let me structure:

```html
<!DOCTYPE html>
<html>
<head>
<meta charset>utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Brick Breaker</title>
<style>
  html,body{margin:0;padding:0;height:100%;overflow:hidden;background:#111;color:#fff;font-family:sans-serif}
  #game{width:100%;height:100%;}
  .info{position:absolute;top:10px;left:10px;z-index:10;...} // maybe place via Phaser text instead
</style>
</head>
<body>
<script src="phaser.min.js"></script>
<script>
... game code ...
</script>
</body>
</html>
```

I'll put all info text inside the Phaser canvas as text objects to keep it self-contained (no DOM overlay needed). Actually a small DOM overlay for controls is fine and the task says inline CSS — DOM elements with CSS are okay (it's still one HTML file, no external resources). But to be safe and self-contained, I'll render controls as Phaser text and buttons. Let me render everything in Phaser.

Let me write the JS.

```js
const WIDTH=800, HEIGHT=600;
const PADDLE_W=120, PADDLE_H=20;
const BALL_R=10;
const BRICK_W=64, BRICK_H=24;
const ROWS=5, COLS=10;
const LIVES=3;

let config={
 type:Phaser.AUTO,
 width:WIDTH,
 height:HEIGHT,
 parent:'game',
 physics:{default:'arcade', arcade:{gravity:{y:0}, debug:false, fps:60}},
 scene:{init,preload,create,update}
};
new Phaser.Game(config);

function init(){...}
function preload(){...}
```

Hmm, using scene methods as separate functions — need `this` binding. When using the object form scene:{create, update}, Phaser binds them with scene as this. So `function create(){...}` called as this=scene. Good.

Let me use a scene class maybe cleaner. But functions are fine.

Let me write create:
```
function create(){
  const self=this;
  // world bounds via explicit walls
  const walls = self.physics.add.staticGroup();
  const t = walls.create(WIDTH/2, 5, makeRect(...));
  ...
}
```
Hmm staticGroup.create expects a texture key. For a rectangle without texture, I can pass a generated texture. Let me create a 1x1 white texture and use as fill, scaling.

Better: generate a 'pixel' texture in create:
```
const graphics = self.add.graphics().draw... 
```
Phaser's `this.add.rectangle` returns a Rectangle GameObject (a shape), not a texture-based sprite, so physics.add.existing works directly. Rectangle is an actual GameObject. So `const wall = this.add.rectangle(x,y,w,h,color)` then `this.physics.add.existing(wall, true)`. This works! No need for texture. Good. Rectangles are GameObjects.

For sprites needing texture, I'd generate. But bricks and paddle and ball I can make as rectangles too (no texture needed). The ball is a rectangle (looks like a square). To make a circle for the ball, I can use `this.add.circle`? Phaser 3.60+ supports `this.add.circle(x,y,radius,color)`. Yes. Let me use circle for ball, rectangles for paddle/bricks/walls.

Actually circle physics body — `this.physics.add.existing(circle, true/false)` — a Circle GameObject can have a physics body (it becomes a circle body? or rectangle body?). Arcade bodies for a circle GameObject: Arcade uses circle bodies if body is Circle. Phaser's Arcade GameObject body: for an `image`, body is Rectangle. For `this.add.circle`, does Arcade create a circle body? I think Arcade body shape is determined by the GameObject; circle GameObjects get ArcadeCircle? Let me check: Phaser Arcade body's `isCircle`... The physics body created via add.existing for a Circle might be a regular Body with a circular offset. Hmm. To avoid ambiguity, let me use a rectangle for the ball (it's a square ~20x20, looks fine) OR generate a circular ball texture.

Actually a 20x20 square as the "ball" is acceptable visually-ish but let me make it a circle for nicer look. Let me generate a circular ball texture using `this.add.graphics` and `generateTexture`:
```
const gfx = this.make.graphics();
gfx.fillStyle(0xffffff);
gfx.fillCircle(10,10,10);  // radius 10
gfx.generateTexture('ballTex',20,20);
gfx.destroy();
const ball = this.physics.add.existing(this.add.image(0,0,'ballTex'));
```
But image needs to be positioned. Hmm this adds complexity. Alternatively use `this.add.circle` and then `this.physics.add.existing(circle)`. Let me test whether Arcade supports circle bodies from add.circle.

Actually Phaser Arcade: when you do `this.physics.add.existing(gameObject)`, it creates a `Phaser.Physics.Arcade.Body` (or ArcadeStaticBody). For Arcade, the body shape is always a rectangle (body is a Rectangle). But there's `isCircle` property that makes it circular for collision. For a Circle GameObject, the body is created with isCircle=true? I believe `this.add.circle` results in a physics body that is circular IF Arcade supports it... Let me recall: Arcade supports circle bodies via `body.setCircle(radius)`. For an existing body you call `body.setCircle(radius, offsetX, offsetY)`. 

To keep it simple and avoid circle-body edge cases, I'll just make the ball a 20x20 rectangle with rounded... rectangles don't have border radius in Canvas easily in Phaser. So ball will be a square. That's acceptable. Or I generate a circle texture.

Let me generate a circle texture — clean and the ball looks round. It's not an "asset" (it's generated). Allowed.

Plan: create textures programmatically for ball and maybe paddle (paddle as rectangle fine). Use:
- ball: generate 'ball' texture (circle), add as physics image.
- paddle: add.rectangle.
- bricks: add.rectangle.
- walls: add.rectangle.

Let me write a helper to generate a circle texture:
```
function genCircle(key, r, color){
  const g=this.add.graphics();
  g.fillStyle(color,1);
  g.fillCircle(r,r,r);
  g.generateTexture(key, r*2, r*2);
  g.destroy();
}
```
Wait generateTexture on graphics: `graphics.generateTexture(key, width, height)` exists. Yes.

Then `const ball = this.physics.add.image(WIDTH/2,0,'ball'); ball.setCollideWorldBounds... `

Hmm, but physics.add.image with 'ball' texture — the body defaults to Rectangle sized to texture (20x20). I want a circular body. I can call `ball.body.setCircle(BALL_R)`. Let me do that.

Actually maybe overcomplicating. Let me just use `this.add.rectangle(BALL_R*2, BALL_R*2,...)`? Rectangle of 20x20 = square. For a "ball" in breakout, square is fine functionally. But circle looks better and bounce off rectangle corners weird. Let me do circle texture + setCircle body. I'll do it.

Let me just generate and setCircle.

Let me also handle paddle as rectangle: good.

Now the overlap/collider setup:

```
const walls = [topWall,leftWall,rightWall];
this.physics.add.collider(ball, walls, null, null, this);
this.physics.add.collider(ball, paddle, paddleHit, null, this);
this.physics.add.overlap(ball, bricks, brickHit, null, this);
this.physics.add.overlap(ball, bottomSensor, ballFell, null, this);
```

For `this.physics.add.collider(ball, walls)` where walls is an array — accepts array? I think collider accepts GameObject, Group, or array. Let me pass a group instead: put all walls in a static group `wallGroup`, add them, then collider(ball, wallGroup).

Let me restructure walls into a staticGroup.

```
const wallGroup = this.physics.add.staticGroup();
const topW = this.add.rectangle(WIDTH/2,5,WIDTH,10,0xaaaaaa);
this.physics.add.existing(topW,true); 
// set bounce on body: topW.body.setBounce(1); // static body bounce
wallGroup.add(topW);
```
Hmm, mixing add.rectangle and physics.add.existing then adding to staticGroup — but physics.add.existing with true makes it a static body; does wallGroup (staticGroup) properly adopt it? The body is already created. Adding to group should be fine. But staticGroup.create normally creates its own. Let me instead use staticGroup.create with a generated wall texture. Or simpler: just create individual static bodies and a single collider each:

```
function makeStaticRect(x,y,w,h,color){
  const r = this.add.rectangle(x,y,w,h,color);
  this.physics.add.existing(r,true);
  r.body.setBounce(1,1);
  return r;
}
```
Then:
```
const topW=makeStaticRect(WIDTH/2,5,WIDTH,10,0x666666);
const leftW=makeStaticRect(5,HEIGHT/2,10,HEIGHT,0x666666);
const rightW=makeStaticRect(WIDTH-5,HEIGHT/2,10,HEIGHT,0x666666);
this.physics.add.collider(ball,[topW,leftW,rightW]);
```
collider with array? Phaser accepts array of GameObjects? The docs: gameObject1 can be a single object, array, or Group. Yes arrays work. Good.

Actually I'm fairly sure Phaser's `collider` accepts arrays. Let me avoid risk and add them all to a physics group. Use a regular Group with `this.physics.add.group()`? But static bodies... Hmm.

Alternative: Make walls non-static but immovable and body.enable... Actually simplest robust: set world bounds and use collideWorldBounds for the ball for left/right/top, and a separate bottom sensor. Let me reconsider this approach because it's standard and reliable.

Standard approach:
```
this.physics.world.setBounds(0,0,WIDTH,HEIGHT);
ball.setCollideWorldBounds(true);
ball.setBounce(1,1);
ball.setVelocity(...);
```
This bounces ball off all 4 walls. For bottom, I detect via worldbounds event:
```
this.physics.world.on('worldbounds', (go, left, right, up, down)=>{
  if(down){ handle ball lost }
});
```
When ball hits bottom, it would reflect (bounce) — but in the event handler I can stop it: set velocity 0 and trigger loss. The reflection already applied; I override. The ball might briefly be at bottom edge then I reset it. Since I'm triggering life loss and reset, it's fine. But the bounce reflection in that frame makes the ball move up slightly then I reset. Acceptable—actually cleaner is to disable world bounds reflection for bottom only, which Arcade doesn't directly support.

Hmm, but the worldbounds event fires for the ball only when `ball.body.onWorldBounds = true` is set. Let me set that.

Wait, but there's a subtlety: with multiple objects, worldbounds events fire for all that have onWorldBounds. I'll set it only on ball.

But the bottom reflection: when the ball crosses the bottom bound, Arcade reflects velocity.y. The worldbounds callback fires. In callback, I set velocity 0 and call loseLife. The ball is now above bottom (reflected). Then loseLife resets ball to paddle. So the ball never visibly "falls below"; it pops back up to paddle. That breaks the visual of "ball falling below paddle costs a life". 

For better visuals, I want the ball to visibly fall below the paddle then get removed. So explicit bottom sensor below the paddle is better. Let me go with explicit walls (no world bounds on bottom) + bottom sensor.

OK decision made: explicit walls top/left/right (static, bouncy), bottom sensor zone below paddle for loss. No setCollideWorldBounds on ball (false).

Let me verify array collider works. Actually I just realized a cleaner method: create a single static group for walls.

`const wallGroup = this.physics.add.staticGroup();`
Then I need to add static bodies. `wallGroup.create(x,y,key)` needs a texture. I can generate a 1x1 white texture and scale.

Let me generate textures:
```
genRectTexture('px', 1,1, 0xffffff); // 1x1 white
```
Then:
```
function wall(x,y,w,h){
  const r = wallGroup.create(x,y,'px').setDisplaySize(w,h).setOrigin(0.5);
  return r;
}
```
staticGroup.create with texture 'px' creates a static Arcade body sized to the texture (1x1) then setDisplaySize scales the visual but does the body scale? setDisplaySize sets displayWidth/Height and updates body size? For Arcade, `setDisplaySize` does NOT update the physics body. There's `setSize`. Hmm. For static group members, the body size might stay 1x1.

This is getting fiddly. Let me just use individual rectangles with physics.add.existing(true) and add a collider for each, or collect in an array for one collider. I'm fairly confident `this.physics.add.collider(ball, arrayOfGameObjects)` works because the internal `overlap` uses `GetObjectToRenderList`/`collider` accepts arrays. Let me verify by checking Phaser source quickly via grep.

Let me grep the phaser min for how collider handles arrays. Actually, trust memory: Phaser's `collider` and `overlap` accept `gameObject2` as an object or array. I've used arrays before. I'm confident.

Actually, to be safe and simple, I'll create the three walls and call collider three times OR use an array. Let me just create them and add a single collider with array; if it didn't work I'd see. Given I can test in browser, I'll use array and verify in browser.

Alternatively, simplest bulletproof: enable world bounds for ball but set world height taller so bottom isn't bounced? No.

Let me reconsider using `collideWorldBounds` true for top/left/right and detect bottom via overlap sensor placed inside bounds. The issue: collideWorldBounds bounces at bottom too. If ball reaches bottom (y near 600), it reflects. The sensor at y ~ 585 (overlap) triggers before reflection? The order: Arcade moves body, then checks collisions/walls, reflects if collideWorldBounds, then my overlap sensor checks. So ball at y=585 overlapping sensor triggers loss. But ball might also reflect off bottom at y=610 if it went to 610 before sensor. If sensor at y=590-600 region and ball goes 580→600, overlap fires first (at 590 region) before reaching 600. Good. So sensor placed at top of "loss zone" around y=580, height 20. Ball entering y>580 triggers loss. Since ball is ~10 radius, when center hits 580 the ball bottom is at 590, paddle top ~540. The ball clearly below paddle. Good. And world bounds bottom reflection (at 600) never reached because we detect at 580 and remove ball.

But wait, if I both have collideWorldBounds bouncing at bottom AND a sensor at 580, the sensor fires at 580 (loss) before bottom reflection at 600. Good, so bottom reflection is irrelevant (never reached). So I can keep collideWorldBounds(true) for top/left/right bounce and add the bottom sensor below. Clean! No explicit walls needed. 

So:
```
this.physics.world.setBounds(0,0,WIDTH,HEIGHT);
ball.setCollideWorldBounds(true);
ball.setBounce(1,1);
ball.body.onWorldBounds = true;  // not needed if using sensor for bottom
```
Actually no worldbounds event needed; use sensor.

Bottom sensor:
```
const bottomSensor = this.add.zone(WIDTH/2, 600-5, WIDTH, 20).setOrigin(0.5); // at y=595, covers 585-605
this.physics.add.existing(bottomSensor, true); // static sensor
bottomSensor.body.setAllowCollision(true); // it's a sensor
this.physics.add.overlap(ball, bottomSensor, ()=>ballLost(), null, this);
```
Wait, for overlap to trigger with a static body, the static body must have `isCircle`? No. Overlap works; static body acts as solid but overlap triggers regardless of collision response (overlap isn't blocked by body being static? Actually overlap triggers when bodies intersect regardless of one being static, yes). But for a static body, by default it's not a sensor. Overlap in Arcade detects intersection irrespective of sensor/collision flags? Overlap is basically intersect detection; processCallback can return false to skip. Static bodies are checked in overlap? I believe overlap works with static bodies (that's how you overlap a ball with static walls sometimes). Hmm, but to be safe set the static body's `body.setCheckCollision` all true, `body.setAllowGravity(false)`; overlap should fire.

Actually, there's nuance: Arcade overlap between a dynamic and static — the static body won't move, overlap callback fires. Yes that's standard (e.g., overlap bullet with wall). Good.

Alternatively use a dynamic sensor (kinematic) set as non-colliding. But static is fine.

Hmm, one concern: static bodies in overlap — Phaser's overlap iterates "broadphase" bodies; static bodies ARE included in the bodies list. Good.

Actually, let me reconsider: I recall overlap does include static bodies. Yes.

But to be 100% safe with the bottom, maybe use a normal dynamic body zone set to `body.setAllowGravity(false)` and `body.setImmovable(true)` and thickness small, as an overlap sensor. Either works. I'll use static.

Hold on, simpler: skip the bottom sensor entirely and instead in `update()`, check `if (ball.y > HEIGHT + something) ballLost()`. Since collideWorldBounds reflects at bottom (y=600-10), the ball never exceeds ~600. So update check wouldn't fire. So I DO need either disabled bottom bounce or a sensor. Using the sensor approach with collideWorldBounds(true) — but bounce reflects at 600, sensor at 585 triggers first. Good, update check not needed.

Hmm wait, actually will the sensor overlap fire before the bottom wall reflection? Arcade step order: 1) integrate velocities (move bodies) 2) test collisions against world bounds / other bodies and resolve. The overlap is also processed in the collision phase. The order of world-bounds vs overlap callbacks... Both processed. The ball reflects off bottom at y≈610? No, world bounds bottom is y=600. collideWorldBounds reflects when ball touches 600. The sensor covers y 585-605 (center 595). As ball descends from 585 toward 600, when ball's body intersects the sensor rect (585-605), overlap fires → I remove ball. This happens before the ball reaches 600 (reflection). So ball is removed. 

So I'll keep collideWorldBounds(true) for edges, plus bottom sensor. Good. The bottom world-bounds bounce is effectively dead code. Fine.

But careful: with bounce(1,1) and collideWorldBounds, the ball reflects off bottom too—but since we remove it in sensor, fine.

Actually, even simpler: Don't set collideWorldBounds for bottom by using explicit walls. But I've already reasoned the sensor approach is fine. Let me just also set the ball so it doesn't reflect at bottom by... no, leaving it is fine.

Hmm, but there's a risk the ball, when resting on paddle during LAUNCH, with checkCollision disabled, sits fine. On launch we enable collisions. The ball then might immediately be overlapping paddle → paddle collider fires → fine, bounces.

Let me also consider: during LAUNCH, ball velocity 0 and checkCollision.none=true so it doesn't move/fall. We position ball.x = paddle.x each frame. Good.

Now, the paddleHit callback: I want to override velocity to aim based on impact. But default collideWorldBounds bounce already handled edges. Paddle collider reflects. Let me keep default reflection (ball bounces off immovable paddle with bounce 1) and add the angle tweak. Let me implement:

```
function paddleHit (ball, paddle){
  const diff = ball.x - paddle.x;
  const norm = Phaser.Math.Clamp(diff/(paddle.width/2), -1, 1);
  const speed = Math.max(200, Phaser.Math.Distance.Between(0,0,ball.body.velocity.x, ball.body.velocity.y));
  const angle = Phaser.Math.DegToRad(Phaser.Math.RadToDeg(Phaser.Math.Angle.Between(paddle.x,paddle.y,ball.x,ball.y)) ); // hmm
  ...
}
```
Let me keep it straightforward. After collision, the ball is moving up (reflected). I'll blend vx based on norm:
```
const speed = Math.hypot(vx,vy) || 300;
const newAngle = Phaser.Math.DegToRad(90 - norm*55); // aim up-left/up-right
ball.body.velocity.x = speed * Math.sin(newAngle)*sign... 
```
Hmm. When norm=0 (center), angle=90° → velocity straight up (vx=0, vy=-speed). When norm=1 (right edge), angle=35° → vx=+speed*cos(35), vy=-speed*sin(35). When norm=-1, vx negative. That's a nice aiming. Let me compute:
```
const speed = ...;
const deg = 90 - norm*55; // range 35..155? No, 90-55..90+55 = 35..145. But norm in [-1,1] → deg in [35,145]. At 145°, cos negative. Hmm I want at right edge (norm=1) vx positive. deg=35 → cos positive. At norm=-1, deg=145 → cos negative (vx negative). At center deg=90 cos0 vx 0. 
```
But deg=145 gives vy = -sin(145) = -0.574*speed (upward). Good. So deg range 35..145. Let me set deg = 90 - norm*55? At norm=1: 35. At norm=-1: 145. Yes.

```
const rad = Phaser.Math.DegToRad(90 - norm*55);
ball.setVelocity(speed*Math.cos(rad), -speed*Math.sin(rad));
```
cos(35)=0.819, sin(35)=0.574 → vx=0.819*speed, vy=-0.574*speed (up). cos(145)=-0.819, sin(145)=0.574 → vx=-0.819, vy=-0.574. Center cos90=0, sin90=1 → vx=0, vy=-speed (straight up). 

But wait I defined rad = degToRad, and vy uses -sin(rad)*speed. At center sin90=1 → vy=-speed (up). Good.

But the speed: I want the ball to keep moving up after hit. vy negative = up (in Phaser, y increases downward). Good.

Edge: ensure vy is upward (negative) always, which it is in this range. Good.

I think default reflection + this override is fine. But there's a problem: the collider will first reflect the ball, then my callback overrides velocity. The ball might be slightly overlapping paddle after. Arcade separation moves them apart along normal (vertical) so ball ends above paddle. Good. Then velocity up. Fine.

But if I set velocity with the same speed, and the ball was descending fast, the override changes it. Good.

Let me make sure not to infinite-loop or get stuck. Fine.

Now bricks. Let me lay them out centered:
```
const offsetX = (WIDTH - COLS*BRICK_W - (COLS-1)*gap)/2 + BRICK_W/2;
```
Let me compute gap. Let me choose gap=4, COLS=11, BRICK_W=64 → total = 11*64+10*4 = 704+40=744, offset=(800-744)/2=28. x_start = 28+32=60. Hmm. Let me just pick COLS=11, gap=3 → 11*64+10*3=704+30=734, offset=(800-734)/2=33, startX=33. Fine. Or simpler COLS=10, BRICK_W=70, gap=3 → 700+27=727 offset=36.5.

Let me use COLS=11, BRICK_W=62, gap=4 → 682+40=722 offset=39. Eh. Let me just pick: ROWS=5, COLS=11, BRICK_W=64, gap=3. startX = (WIDTH - (COLS*BRICK_W + (COLS-1)*gap))/2 = (800 - (704+30))/2 = (800-734)/2 = 33. Brick x = 33 + 32 = 65 start? Let me define: x = startX + i*(BRICK_W+gap) + BRICK_W/2. startX=33, so first brick center x = 33+32=65. Last = 33 + 10*67 = 33+670=703 +32 = 735. Good, within 800.

y rows: from top 60 down. y = 60 + row*(BRICK_H+gap). BRICK_H=24 gap=3 → 27. rows y: 60,87,114,141,168.

Colors per row from top: red, orange, yellow, green, blue. Use distinct colors:
0:#e74c3c red
1:#e67e22 orange
2:#f1c40f yellow
3:#2ecc71 green
4:#3498db blue

Bricks: static bodies? I'll make them static so they don't fall. Create rectangles with physics static. But for overlap removal I can destroy them; removing from group. If using staticGroup, destroy bricks. Let me store bricks in a group `bricks` (physics group). Create each as rectangle+physics add existing true (static). Then group.add. Overlap(ball, bricks). On hit, brick.disableBody(true,true) or destroy. Removing (destroy) reduces group.getChildren length → check zero.

Let me create bricks as static bodies via `this.physics.add.existing(rect, true)`. Then `bricks.add(rect)`. bricks = `this.physics.add.staticGroup()`? If I create bodies manually I should use a plain Group: `this.add.group()`? Actually need a physics group for overlap to check. Let me use `bricks = this.physics.add.group()`. Then add static bodies to it. Does overlap work for a physics group containing static bodies? The group's children have static bodies; overlap iterates group's physics children. Should work.

Hmm, but mixing static bodies in a dynamic physics group might be okay. Let me instead make bricks dynamic with `setImmovable(true)` and `setAllowGravity(false)`. Then they stay put and behave like static for overlap. Dynamic bodies are definitely handled by overlap. That avoids static-in-dynamic-group concerns. Let me do that: `this.physics.add.existing(rect, false)` (dynamic), `rect.body.setAllowGravity(false)`, `rect.body.setImmovable(true)`, `rect.body.setBounce(0)`. Then brickHit: `brick.disableBody(true,true)` or destroy.

For clearing check use group count. Dynamic group's getChildren returns sprites. disableBody keeps the body disabled but object remains (overlap won't fire for disabled). Let me just `brick.destroy()` and rely on `bricks.getChildren().length`. After destroying all, length 0 → win.

But careful: destroying a sprite also removes its body from physics. Overlap next frame won't include it. Good. And group.getChildren will reflect removal? getChildren returns active children list; destroyed children have `active=false`. Actually group counts active children. `getChildren()` includes non-active? The Group's `getChildren` returns `this.getChildren()`? It returns `this.total` based? Let me just track a brickCount manually decrementing, and also could use `bricks.getLength()`. I'll track count manually to be safe and clear win condition. Actually `getChildren().length` after destroy — destroyed objects are removed from group's `children`? Destroying a child calls `scene.children.remove` and group's `remove` (group.onChildDestroy removes). So getChildren length decreases. I'll use `bricks.getChildren().length`. Good.

Let me also handle multiple bricks at once (unlikely). Fine.

Now the ball: I'll use image with circle texture + setCircle body. Let me generate texture 'ball' as circle radius 12 → tex 24x24. Then image. Set body setCircle(12)? The body circle radius should be 12. Actually the texture is 24x24 circle; body setCircle(12) centered. Fine. Or simpler set body size to 24x24 and treat as "ball" visually circle but physics rectangle. For a small ball, rectangle vs circle rarely matters. But setCircle is nicer. Let me do setCircle(12).

Hmm, Arcade `body.setCircle(radius, offsetX, offsetY)`. Offset to center so circle centered in 24x24. Default offset (0,0) places circle at body.x.. I think setCircle auto-offsets. Let me not overthink; setCircle(12). Good.

Now paddle movement & clamping & mouse. Implement in update:

```
function update(){
  if (state===WIN||state===GAME_OVER) return;
  const speed = 520;
  if (cursors.left.isDown){ paddle.setVelocityX(-speed); }
  else if (cursors.right.isDown){ paddle.setVelocityX(speed); }
  else { paddle.setVelocityX(0); }
  // mouse tracking
  const ptr = this.input.activePointer;
  if (!cursors.left.isDown && !cursors.right.isDown){
    // ease toward pointer x
    const targetX = Phaser.Math.Clamp(ptr.x, paddle.width/2, WIDTH-paddle.width/2);
    paddle.x = Phaser.Math.Linear(paddle.x, targetX, 0.3);
  }
  const minX = paddle.width/2;
  const maxX = WIDTH - paddle.width/2;
  paddle.x = Phaser.Math.Clamp(paddle.x, minX, maxX);
  paddle.body.update();
  // LAUNCH follow
  if (state===LAUNCH){
    ball.x = paddle.x;
    ball.y = paddle.y - paddle.height/2 - BALL_R;
  }
}
```
Wait, moving paddle via Linear on x but also setVelocityX from keyboard — conflict. Let me separate: use velocity for keyboard, and for mouse add the linear tracking only when no keys. But paddle.position via velocity; if I also set paddle.x directly (Linear) that overrides velocity integration for that frame, fine since keyboard path sets velocity. Let me ensure when keys pressed, don't do linear. Code above does that.

But there's subtlety: paddle is dynamic body. Setting paddle.x directly moves it (Arcade supports direct position set; body updates velocity? Actually directly setting x may leave body.velocity stale, but it's fine for an immovable-moving paddle). Hmm but paddle body is dynamic and immovable=true. Setting position directly is okay; Arcade body will update its position. Collision still works. Fine.

But if I set paddle.x directly via Linear and also the physics step moves by velocity=0 (since no key), fine.

Alternative cleaner: Don't use physics body velocity for paddle; just set paddle.x directly and use paddle.body as a sensor (setImmovable true so ball bounces, but paddle position set manually). But then collisions: paddle body must be active; Arcade collides using body positions. Setting paddle.x moves body too (body.x = ...). Actually you must keep body in sync. When you set sprite.x, Phaser updates the transform; for Arcade body, you may need `paddle.body.update()` or set `paddle.body.x = paddle.x`. Hmm.

To avoid sync issues, the standard approach: move paddle with `paddle.setVelocityX(...)` and clamp the position. For clamping, after physics step, set `paddle.body.x = clamp(paddle.body.x)`. Or set `paddle.setX(clamped)`. Phaser's Arcade: after `update`, if you set sprite position, the body position follows on next body.update? There's a known gotcha: changing sprite.x doesn't move the physics body automatically; you should set the body position. Actually for non-physics-moving, setting `sprite.x` does update transform but body uses `body.x`/`body.update`. The body's position is updated from the GameObject at the start of physics step via `body.update` if `body.sync` ... For Arcade, bodies are NOT auto-synced from display object each frame unless you do it.

Hmm, I recall that for Arcade, when you move a GameObject via `sprite.x = ...` (direct assignment) while it has a body, the body does NOT automatically follow. You must set `sprite.body.x` or call `sprite.body.update()`. Wait, actually I think `sprite.x` setter does call a transform update but the Arcade body reads position from the GameObject at the *start* of the physics step via `SpriteState`? 

I'm overcomplicating. The SAFE approach: control paddle through the Arcade body velocity (kinematic-ish): set `paddle.body.setVelocityX(...)`. Arcade then moves the body and the GameObject follows automatically ( Arcade updates GameObject position from body each step when you set velocity, because the body.move... actually Arcade moves body by velocity and sets `gameObject.x = body.x` in the body's postUpdate). Yes! ArcadeBody.postUpdate sets the GameObject's position from the body. So using velocity (or setVelocityX + having the body enabled) the body moves and the sprite follows. For clamping, set `paddle.body.x = Math.clamp(paddle.body.x, min, max)` BEFORE the body moves? Or after? The order is tricky.

Simplest robust: use velocity for movement, and clamp via `paddle.body.x` in the same update (before body.step? update runs before physics step). In `update()` (Scene.update runs before physics step in Arcade? Actually Scene.update is called, then physics step). So setting paddle.body.velocity in update, then physics moves it. For clamping after movement, I'd clamp in the paddleHit/collision or use a processCallback. Hmm.

Alternatively, do clamping in `update` AFTER physics step — but update is before step. I can use a collider/physics callback, or poll in `update` again (two phases). 

Let me avoid all this: keep paddle as an Arcade Dynamic body, setVelocityX for movement, and clamp position using the body at end of update (update runs before physics step, so clamping there affects before the move). To clamp AFTER move, I can register a world step listener: `this.physics.world.on('postUpdate', clampPaddle)`? Or simpler, clamp using the display object position by also repositioning body manually in update AND accept that the next physics postUpdate overwrites sprite from body. 

Ugh. Let me step back.

Cleanest known-good pattern: Use a STATIC body for the paddle that you reposition manually, with `body.update()` sync. Static bodies can be moved via `body.x = v` or you set `sprite.x` and then call `body.update()` so the body follows, and collisions use the new position. But moving a static body each frame works in Arcade for things like moveable platforms. The ball collides with the static paddle (paddle doesn't move from impact). I control paddle via `body.x`.

So: paddle = `this.add.rectangle(...)`, `this.physics.add.existing(paddle, true)` (static body), `paddle.body.setAllowGravity(false)`, `paddle.body.setImmovable(true)` (redundant for static), `paddle.body.setBounce(0)`. Then in update: `paddle.body.x = clamp(targetX, min, max)` and `paddle.x = paddle.body.x`. Hmm but static body movement: set `paddle.body.x = v` then `paddle.body.update()`? Static bodies: setting `.x` on a static body marks it dirty and it will sync. Actually for static bodies you set `body.x`/`body.y`, and the GameObject position is updated automatically at the start of the physics step via `body.update`? For static bodies, `body.update()` (called from postUpdate of the body? no, static bodies update via `body.syncGameObject`...).

I'm going down a rabbit hole. Let me empirically test in the browser with a static moving paddle. Given I have browser tools, I can iterate. Let me just implement a clear approach and test:

Approach I'm confident works: Dynamic body paddle, immovable, move via `paddle.setVelocityX(speed)` and manually clamp the POSITION via `paddle.x` setter AND `paddle.body.x` to keep them in sync. Since Arcade postUpdate sets GameObject.x from body, to keep them consistent I'll set both `paddle.body.velocity.x` and in update after computing, set `paddle.body.x = clamp(paddle.body.x, ...)` won't work because step hasn't run.

Let me instead use a collider processCallback-free approach: move paddle with velocity, and use `paddle.setCollideWorldBounds(false)` ... no.

OK let me just TEST. I'll write the game, load in browser, and inspect. I'll use the dynamic-body-immovable approach with velocity and clamp the body position. If the paddle behaves oddly, I'll adjust.

Actually, I now recall clearly: For a Dynamic Arcade body, you CAN simply do `sprite.x = value` or `sprite.body.x = value`, and it works because the Arcade body's position IS the source of truth and on the next `body.update()` the GameObject transform is synced from `body.x`. The `Sprite.x` setter sets `this._x` (the transform) but NOT body.x. So setting `sprite.x` alone leaves body behind — the body stays and on next step re-syncs sprite to body, so your sprite.x change is reverted/ignored! This is the classic gotcha. Therefore you must set `body.x` (or velocity) to move an Arcade body.

So: set `paddle.body.setVelocityX(speed)` → Arcade moves body → sprite follows. For clamping, set `paddle.body.x = Math.clamp(paddle.body.x, minX, maxX)` in a post-physics context. 

Phaser provides `this.physics.world.on('worldbounce')`? Not. There's `this.physics.world.on('postUpdate', ...)`. Arcade world emits 'postUpdate' each step. I can clamp there. Simpler: in update(), set velocity; then ALSO clamp in update but that's pre-step. To clamp after step, use a small trick: clamp the body.x but the body hasn't moved yet this frame... 

Alternative robust clamp using velocity + a `collider`/ `overlap`? no.

Let me use: paddle velocity for movement, and clamp position by zeroing velocity at boundaries and also clamping body.x at end of physics via a custom approach. 

Hmm, simplest: instead of clamping with bounds, just stop the paddle from going past by checking the body.x in update (pre-step) and clamping its TARGET. I.e., set velocity, then clamp body.x in update (pre-step) won't prevent overshoot but if speed small relative to remaining distance it's fine. But a single fast step could overshoot.

Better: handle clamping via a static invisible wall? No.

Let me just clamp with `body.x` set in update, but apply a manual integration: Actually the most reliable: don't move the paddle via physics velocity; instead each frame set `paddle.body.x` directly to the clamped target (no velocity), and the sprite follows because Arcade syncs GameObject from body on postUpdate. To make collisions work, the static/dynamic body's position for collision is body.x which is current → collisions use new position. This is the moveable platform pattern: set `body.x = target`, set `body.enable = true`, collisions work. For dynamic body you'd also set velocity=0. This is reliable because you set the actual body position used in collision.

But does Arcade sync `body.x`? For dynamic body, `body.x` is the source of truth; setting it directly moves it. The GameObject position is updated from body in `Body.postUpdate()` (which sets `gameObject.x = body.x`). postUpdate runs each physics step. So setting body.x in Scene.update (pre step) → at step end, sprite syncs to body.x. 

So the moveable-platform pattern: `paddle.body.x = targetX; paddle.body.y = fixedY`. Set velocity 0. Collisions: paddle is dynamic immovable; ball collides and bounces off. 

I'll use that. For paddle movement:
```
const speed = 0;
paddle.body.setVelocity(0,0);
paddle.body.setAllowGravity(false);
paddle.setImmovable(true);
...
// keyboard
if (cursors.left.isDown) paddle.body.x -= speedScale; // direct position change
else if (cursors.right.isDown) paddle.body.x += speedScale;
else { // mouse
  paddle.body.x = ptr.x; 
}
// clamp
paddle.body.x = clamp(paddle.body.x, minX, maxX);
```
Direct position change per frame = effectively teleport each frame, fine at 60fps. Using `paddle.body.x += delta*speed` for smooth. Let me use a speed and time delta. But Scene.update(time,delta) gives delta. I'll use pointer.x directly for mouse (responsive enough). Keyboard: move by `Math.sign * speed * delta/1000`. Hmm.

Actually mixing direct position assignment is fine for a paddle. Let me do:
```
if (ptr.leftButtonDown || keys)... 
```
For mouse: if mouse moved, set paddle x = clamp(ptr.x). For keyboard: move by delta. 

But keyboard left/right and mouse both? If using keyboard, ignore mouse. Let me do: 
```
if (cursors.left.isDown) move left
else if (cursors.right.isDown) move right
else set paddle.x = clamp(ptr.x)  // mouse/trackpad follow
```
For keyboard move amount: `paddle.body.x += dir * 520 * dt` where dt = delta/1000.

Let me also ensure the ball on paddle moves with paddle: ball.x = paddle.x (and synced). Set ball.x = paddle.body.x each frame in LAUNCH. Since body.x is set directly for paddle, set ball.x = paddle.body.x. Good. Actually ball's body.x is what matters for physics; I'll set both ball.x and ball.body.x? For the ball during LAUNCH, I set ball.x = paddle.x and ball.body.x? The ball's body.x must equal. Since Arcade syncs GameObject→body? No, body→GameObject. So set ball.x doesn't move body. Set ball.body.x = paddle.body.x. And set ball.y / ball.body.y. Let me just set ball positions via `ball.body.x`/`ball.body.y`? But ball also has visual; Arcade syncs body→sprite each step, so setting body.x updates sprite. Good. So in LAUNCH: `ball.body.x = paddle.body.x; ball.body.y = paddle.body.y - PADDLE_H/2 - BALL_R;` and ensure velocity 0. Arcade postUpdate sets sprite.x from body. 

Now let me also make sure in LAUNCH I disable ball collisions: `ball.body.checkCollision.none = true` so it doesn't bump bricks while on paddle? During LAUNCH ball is on paddle near bottom, bricks at top — no overlap. But to be safe set checkCollision.none and also disable its overlap handlers? They won't fire if no overlap. Fine. On launch: set checkCollision.none=false, setVelocity. Also must re-enable so it collides. Good.

Let me ensure the ball's bottom-sensor overlap doesn't fire during LAUNCH: ball at y~545, sensor at ~595+. No. Good.

Now the bottom sensor: I worry overlap with static sensor vs dynamic ball — fine. But I set ball.checkCollision.none during LAUNCH; overlap requires body's checkCollision? Overlap checks `body1` and `body2` checkCollision flags? If ball's checkCollision.none, overlap won't detect. During LAUNCH ball not falling, fine.

Now let me also double check: when ball is launched and falls, it overlaps bottom sensor → ballLost. In ballLost: set velocity 0, checkCollision.none=true, state=LAUNCH? Actually ball lost happens during PLAYING. We decrement lives; if >0, resetBall to LAUNCH (ball on paddle). If 0, GAME_OVER.

But there's a subtlety: the overlap callback ballLost fires; I set velocity 0 and reposition ball to paddle and set state LAUNCH. But the overlap might keep firing while ball is near sensor? I set ball to LAUNCH position (y~545) so it's no longer overlapping sensor. And checkCollision.none=true so no more overlap. Good. Also need to disable the ball's body from moving further: setVelocity(0) and maybe `ball.body.setAllowGravity(false)` (already none). Good.

Now win: when bricks empty, state=WIN, show message + restart button. Stop ball: setVelocity 0.

Game over: show message + restart. Ball already stopped.

Restart: reset lives=3, score=0, rebuild bricks, resetBall, state=LAUNCH, reset texts.

Visible Launch button: only show when state===LAUNCH. On clicked → launchBall. Also Space key launches.

Let me make the Launch button a visible control. I'll create a rectangle with text "LAUNCH (SPACE)" and setInteractive. Similarly a "RESTART (R)" button shown in WIN/GAME_OVER.

Let me also add an info/controls panel as Phaser text at top covering: "←/→ move | mouse move | SPACE launch | [R] restart".

Now let me write the code carefully and then test in browser.

Let me write it. I'll define helper functions within an IIFE or rely on closures in create. Since scene functions share `this` and outer consts (WIDTH etc.), I'll define helper functions inside create via closure, or module-level functions that take `scene`. To keep state (score, lives, bricks, etc.) I'll store on `this` (scene) or use closure variables. Let me use closure variables in a boot function and pass scene. Actually simpler: attach everything to the scene object (this) in create, and functions as methods on a class. Let me use a class-based scene for clean state.

Let me write a class:
```
class GameScene extends Phaser.Scene {
  constructor(){ super('Game'); }
  create(){ ... this.fieldName ... }
  update(){ ... }
}
```
Class methods share `this` and state as instance fields. 

Let me define state fields in create: this.paddle, this.ball, this.bricks (group), this.score=0, this.lives=LIVES, this.state='LAUNCH', this.scoreText, this.livesText, this.msgText, this.launchBtn, this.restartBtn, this.cursors, this.pointer.

Let me write everything now.

For building bricks: 
```
buildBricks(){ this.bricks = this.physics.add.group(); const rows=5,cols=11,gap=3,BW=62,BH=22;
  const startX=(WIDTH-(cols*(BW+gap)-gap))/2; // center
  const colors=[0xe74c3c,0xe67e22,0xf1c40f,0x27ae60,0x3498db];
  for(let r=0;r<rows;r++){ for(let c=0;c<cols;c++){ const x=startX+c*(BW+gap)+BW/2; const y=55+r*(BH+gap)+BH/2; const b=this.add.rectangle(x,y,BW,BH,colors[r]); this.physics.add.existing(b,false); b.body.setAllowGravity(false); b.body.setImmovable(true); this.bricks.add(b); } }
}
```
Wait startX: total width = cols*BW + (cols-1)*gap. startX = (WIDTH - totalWidth)/2. With cols=11,BW=62,gap=3 → total=682+30=712; startX=(800-712)/2=44. First brick center x = 44+31=75; last = 44+10*65+31 = 44+650+31=725. Good within 800.

Bricks dynamic immovable, collideWorldBounds? They should bounce ball? No, bricks don't bounce the ball (ball destroys them). I set ball bounce and walls bounce. Ball hits brick → overlap destroys brick. But ball also collides with bricks? I only set overlap (not collider) for bricks. With overlap, the ball passes through? Overlap triggers callback but doesn't separate. If I don't collide, the ball would continue through the brick (and overlap fires) — but I destroy the brick so it doesn't matter. However, if overlap fires and I destroy, the ball keeps going with no bounce, potentially hitting the next brick behind. Hmm. In breakout, hitting a brick should also bounce the ball. Let me make bricks also a collider so the ball bounces, plus overlap callback to destroy.

But Arcade collider + overlap simultaneously on same pair? Typically you use one. If collider bounces ball and overlap destroys — order: collider resolves first (reflects ball), then overlap detects intersection and destroys brick. But after reflection the ball may no longer overlap (separated). Then brick not destroyed! Conflict.

Better: Use ONE mechanism. Use a collider with a callback that destroys the brick AND bounces. Actually collider's collideCallback fires after the physics resolves the collision (ball reflected, separated). In the callback, destroy the brick and score++. The reflection already happened. That gives bounce + removal. 

So use `this.physics.add.collider(ball, bricks, brickHit, separateCallback?, this)`. But destroy in brickHit — removing the brick. However, collider processes all colliding pairs in a step; destroying a body mid-resolve might be fine (Arcade handles destroyed). Let me use collider with brickHit that destroys and scores, and checks win.

But there's a concern: if multiple bricks overlap the ball simultaneously, the collider fires per pair. Destroying one removes it. Fine.

But also: bricks are immovable dynamic bodies. Ball collides → reflects. Then brickHit destroys brick. Good. Let me do that. The reflection off a brick (horizontal edge) will angle the ball. Good.

Wait, but I want the ball to destroy bricks on contact (1 hit). With collider, ball reflects normally AND brick destroyed. Good. Let me use collider for bricks. Remove the overlap for bricks.

But hold on: immovable + collider means ball reflects off brick face (like a wall). Good.

However, there's the issue of the ball getting caught if a brick is destroyed leaving a gap — standard, fine.

Let me also ensure bricks removed from group and win check: `this.bricks.getLength()` after destroy. After destroying, getLength updates (destroyed removed). 

Now paddle: collider(ball, paddle, paddleHit). Ball reflects + I override velocity.

Walls: collider(ball, [top,left,right]) or use collideWorldBounds. Let me use collideWorldBounds(true) for simplicity and a bottom sensor for loss. As discussed sensor fires before bottom bounce. Let me go with that to reduce wall-creation code. Actually I worried about array. collideWorldBounds is simplest and reliable. Let me use it. And bottom sensor for loss.

But bottom sensor using overlap with ball while ball has collideWorldBounds — ball reflects at bottom (y=600). Sensor covers 580-600 region (center y=590 height20). Overlap fires when ball center enters [580,600]. The reflection at 600 is below sensor top; sensor fires first. Good. So ball removed before reaching reflect. 

But hmm, if ball is small and moving fast and step overshoots from 575 to 605 in one frame (ball center crosses sensor fully to below), overlap still detects (body was inside sensor region this frame). So detected. Fine.

Let me set ball bounce 1, collideWorldBounds true. Good.

Now bottom sensor as zone static body. Let me create:
```
this.bottomSensor = this.add.zone(WIDTH/2, 595, WIDTH, 20).setOrigin(0.5);
this.physics.add.existing(this.bottomSensor, true);
this.bottomSensor.body.setAllowCollision(true);
```
For a zone, physics body size = zone size. set existing true → static body. Overlap ball vs bottomSensor. Good.

Now the win condition: when bricks empty. During play. Set state WIN, stop ball, show message.

Let me ensure brick collider's brickHit checks bricks.getLength()===0 → win.

Now let me also handle the ball getting its speed; with bounce 1 it maintains speed. The paddleHit override preserves speed. Good. But the paddleHit override sets speed = current speed (magnitude). After brick bounces, speed preserved. Good.

Potential infinite speed: none. Good.

Edge case: ball moving nearly horizontally hitting a brick row could bounce between bricks; fine.

Now let me also make sure the ball doesn't get stuck: if ball dy is 0 (horizontal) and hits a brick, reflect gives dy... it'd stay horizontal. The paddle override always gives upward dy (negative). Good.

Let me also handle the case where after launch, the ball might immediately hit bricks above paddle? Bricks at y≥55. Paddle at y=560. Ball above paddle (y~545). Launch upward. No immediate brick. Good.

Now let me write the full file.

Let me also add: when in LAUNCH and user clicks anywhere (not just button) maybe launch via Space only, but the visible Launch button is the control. Also tap/click anywhere to launch? Requirement: "Space or a visible Launch control starts it." So Space + Launch button. Let me also allow clicking the Launch button.

Let me make launchBtn visible in LAUNCH state, hidden otherwise.

Now restart: a Restart button visible in WIN/GAME_OVER. On click or R key → reset.

Let me write.

Let me also think about whether to show controls text persistently. I'll show a controls text at top center, always visible. And a state message text at center for WIN/GAME_OVER/LAUNCH hints.

Let me write the code.

One more: the paddle clamping minX = PADDLE_W/2, maxX = WIDTH - PADDLE_W/2. PADDLE_W=120 → min 60, max 740. Good.

Let me code the paddle movement to be smooth with keyboard:
```
update(){
  if(this.state===GameState.WIN || this.state===GameState.GAME_OVER) return;
  const dt = Math.min(this.game.loop.delta*0.001, 0.05);
  const speed = 600;
  let moved=false;
  if(this.cursors.left.isDown){ this.paddle.body.x -= speed*dt; moved=true; }
  else if(this.cursors.right.isDown){ this.paddle.body.x += speed*dt; moved=true; }
  else {
    // mouse follow
    const ptr=this.input.activePointer;
    this.paddle.body.x = Phaser.Math.Linear(this.paddle.body.x, ptr.x, 0.3);
    moved=true;
  }
  this.paddle.body.x = Phaser.Math.Clamp(this.paddle.body.x, PADDLE_W/2, WIDTH-PADDLE_W/2);
  // sprite will sync from body on physics postUpdate
  if(this.state===GameState.LAUNCH){
    this.ball.body.x = this.paddle.body.x;
    this.ball.body.y = this.paddle.body.y - PADDLE_H/2 - BALL_R + 1; // +1 slight overlap to stick
  }
}
```
Wait, when state is LAUNCH I set ball body.x/y directly. But ball also has velocity 0 and checkCollision none, so no movement; the body.x assignment is the source. But does Arcade sync the ball's sprite from body when velocity 0? postUpdate syncs if enabled. Should be fine. Actually I can also set ball.x for visual; but body.x is what matters. Let me set both for safety: `this.ball.body.x = ...; this.ball.x = this.ball.body.x;` Hmm setting ball.x directly may be overwritten by postUpdate to body.x (same value) so fine.

Actually there's a concern: setting `this.ball.body.x` directly each frame while ball has a body — does Arcade complain? It's normal (moveable platforms do this). Good.

For +1 overlap to "stick" ball to paddle so it doesn't separate visually. With checkCollision.none there's no collision so they can overlap. Just set ball.y = paddle.y - PADDLE_H/2 - BALL_R + 0 (no overlap). The ball radius 12 sits above paddle height 20; center at paddle.centerY - 10 - 12 = paddle.y - 22. Let me set ball.body.y = paddle.body.y - PADDLE_H/2 - BALL_R. Good.

Hmm, but ball.body.y for a circular body — the body.x/y is the center? Arcade body.x/y is the center of the body for circle? Actually Arcade body position is the center? No: Arcade Body position (body.x, body.y) is the center of the body (for circle, body.x/y is center; the rect body.x,y is center too in v3? I think body.x is the center). Let me not worry; set ball.body.x = paddle.body.x and ball.body.y = paddle.body.y - (PADDLE_H/2) - BALL_R. With paddle at y=560, ball center at 560-10-12=538. The ball visually (radius 12) spans 526-550, paddle top at 550. Ball bottom (550) touches paddle top (550). Good.

Wait paddle.height=20, half=10, paddle center y=560, top=550. Ball center y=560-10-12=538. Ball bottom = 538+12=550 = paddle top. 

For collision during play, ball hits paddle when ball.y+BALL_R ≈ paddle.y - PADDLE_H/2 → 550. Good.

Now let me write it all out and test.

Let me also reconsider the bottom sensor position: paddle at y=560, top 550. Ball lost when below paddle, i.e., ball.y > ~570 (ball center below paddle bottom which is 570). Sensor at y=595 height 20 covers 585-605. Ball center >585 triggers. Ball bottom at center+12. When center 585, bottom 597 (below paddle 570). Good, clearly lost. 

But should the ball be allowed to "try" to bounce off paddle and if it slips past the bottom edge of paddle count as loss? Yes. Good.

Let me also make the playfield visually bounded: draw a border via rectangle outlines or a background. Fine.

Let me write the file now. I'll keep code reasonably robust.

Let me also add score and lives text top-left and top-right.

Let me write.

Also, I realize for `this.physics.add.collider(ball, bricks, brickHit)` where bricks is a group — collider accepts group. Good. And brickHit(ball, brick). Good.

For paddle collider, brick collider, bottom overlap need to be created once in create. But bricks are recreated on restart (new group). The colliders reference the group/ball/paddle/bottom — ball, paddle, bottom are persistent; bricks group recreated means collider references old group. So on restart I must re-create the collider (or re-add). Let me create colliders that reference `this.bricks` and on restart rebuild bricks and reset the collider by removing and re-adding, OR store collider references and update. Simplest: a method `setupCollisions()` called after building bricks, that (re)creates the ball-brick collider. But re-creating duplicate colliders causes multiple callbacks. Let me store the collider objects and on restart destroy them then recreate.

Phaser: `const c = this.physics.add.collider(...); ... c.destroy();` to remove. Then re-create. Let me do that.

Let me store this.brickCollider and destroy/recreate. The paddle, wall (collideWorldBounds), bottom sensor are persistent.

Let me code.

For the launch button & restart button as interactive rectangles:
```
makeButton(x,y,text,w,h){
  const bg=this.add.rectangle(x,y,w,h,0x333333).setStrokeStyle(2,0xffffff);
  const label=this.add.text(x,y,text,{fontSize:'16px',fill:'#fff',align:'center'}).setOrigin(0.5);
  const hit=this.add.zone(x,y,w,h).setOrigin(0.5).setInteractive();
  // track hover
  ...
  return {bg,label,hit,hide};
}
```
Simpler: make a container or just a text with background. Let me make a rectangle + text, and make the rectangle interactive (setInteractive) since rectangle is a GameObject that supports input. Does `this.add.rectangle(...).setInteractive()` work? Yes, rectangle supports setInteractive (it's a Polygon/Shape which supports input). Then on('pointerup', handler). Let me do that. I'll also tint on hover.

Let me write a Button class-like helper inside create:
```
createButton(x,y,labelText,onClick){
  const w=140,h=44;
  const rect=this.add.rectangle(x,y,w,h,0x2c3e50).setStrokeStyle(2,0xffffff);
  const txt=this.add.text(x,y,labelText,{fontSize:'18px',fill:'#ecf0f1',fontFamily:'sans-serif'}).setOrigin(0.5);
  rect.setInteractive({pixelSized:false});
  rect.on('pointerover',()=>rect.setFillStyle(0x34495e));
  rect.on('pointerout',()=>rect.setFillStyle(0x2c3e50));
  const handler=()=>onClick();
  rect.on('pointerup',handler);
  txt.on('pointerup',handler); // so clicking text works
  return {rect,txt,setVisible(v){rect.setVisible(v);txt.setVisible(v);}};
}
```
Hmm, `setVisible` as method on returned object referencing rect/txt closures. Good.

Let me store this.launchBtn and this.restartBtn objects and toggle via a helper `setVisible(btn,v)`.

Let me finalize and write the file, then test.

Let me write code now.

Actually, let me reconsider: rectangle setInteractive — for input to work the scene input manager needs to be enabled (auto). Fine.

Let me also handle the Space key and R key globally.

Let me write.

Let me write the whole thing.

Good, the APIs exist. Let me write the full index.html now.

Let me think about the design once more and write clean code.

I'll use a class-based Scene. Let me write it.

Now let me run the game in the browser and inspect. Let me use the browser tool.

There's an error: `this.add.rectangle(...).setOrigin(...).setStroke is not a function`. The `setStroke` is not a method on a Rectangle GameObject directly. For shapes (Rectangle), the stroke style is set via `setStrokeStyle(width, color)` not `setStroke(color, width)`. Let me fix that.

Actually `setStroke(value, width)` is a method... wait, Rectangle shape has `setStrokeStyle(color, alpha, thick)`? Let me check. Phaser shapes: `setStrokeStyle(color, alpha, thickness)`. Actually the API: for a `Phaser.GameObjects.Rectangle`, methods include `setStrokeStyle(color, alpha, thickness)`. There is also `setStroke`? Let me just use `setStrokeStyle`. The error says setStroke is not a function, so use setStrokeStyle.

Let me fix the border rectangle.

Error: `this.paddle.body.setAllowGravity is not a function`. The paddle body is a Static body (since I created it with `this.physics.add.existing(rect, true)`). Static bodies don't have `setAllowGravity`? Actually they do have `setAllowGravity`. Hmm wait, the error says it's not a function. Let me check. For an ArcadeStaticBody, methods: setAllowGravity? ArcadeStaticBody extends Arcade.Body? Actually ArcadeStaticBody is a separate class. It may not have setAllowGravity. Static bodies don't fall due to gravity regardless (gravity doesn't apply to static bodies). So I can skip setAllowGravity on the paddle (static). Let me remove it.

Actually, the paddle static body doesn't need setAllowGravity. Let me just remove that line for paddle. And setImmovable? Static bodies are inherently immovable. setImmovable may also not exist on static. Let me remove setImmovable too. Static bodies don't move, so it's inherently immovable. The ball will bounce off a static paddle body (since static body is bouncy enough with ball bounce 1).

But wait — I want the ball to bounce off the paddle. For a static body with bounce 0, does the ball (bounce 1) reflect? In Arcade, when a dynamic body collides with a static body, the reflection uses... Let me check: the bounce applied = `Math.max(body1.bounce.x, body2.bounce.x)`? Or the formula uses `body1.bounce` for the separation? I recall that for a dynamic-static collision, the dynamic body's velocity is reflected based on the static body's bounce property too. Actually, the standard behavior: a static body with default bounce (0) and a dynamic body with bounce (1) — the dynamic body does NOT bounce (sticks)? No... In Arcade, when a Dynamic body collides with a Static body and neither has bounce, the dynamic body stops. With bounce on the dynamic body, it reflects. Hmm, I'm not certain.

Let me reconsider the whole paddle design. The cleanest known-good pattern for a breakout paddle: paddle is a dynamic body, immovable, allowGravity false, moved by setting body.x. The ball collides with it and bounces. Let me switch paddle to dynamic and remove setAllowGravity issue.

Actually, ArcadeStaticBody does have setAllowGravity? The error says it doesn't. Let me check whether static body has setImmovable. Let me just make paddle dynamic (not static) to use setAllowGravity and setImmovable reliably.

If paddle is dynamic:
- setAllowGravity(false) — exists on Body. Good.
- setImmovable(true) — exists. Good.
- Move by setting body.x directly. Dynamic body can be moved by setting position; Arcade will still test collisions against its body position. Moveable platform pattern works with dynamic bodies too (set position, set velocity 0).
- The ball collides with paddle (dynamic). With paddle immovable and bounce, ball reflects.

But moving a dynamic body by directly setting body.x each frame — does Arcade use that position for collision? Yes, the body position is body.x; setting it directly updates the position used in collision tests. Good. And since velocity is 0, it won't drift. The sprite syncs from body postUpdate. Good.

However, there's a subtlety: if paddle is dynamic and immovable=true, when the ball hits it, the paddle doesn't move (immovable) and the ball reflects. Good.

Let me change paddle to dynamic: `this.physics.add.existing(rect, false)`.

Then setAllowGravity(false), setImmovable(true) work.

Also the ball — its body is dynamic (false). setCircle, setCollideWorldBounds, etc. all fine (they worked except the paddle line).

Also for bricks I used dynamic (false) with setImmovable, setAllowGravity, setBounce — fine.

Let me also double check the bottomSensor: static zone. No methods called. Good.

Also `this.ball.body.setCollideWorldBounds(true)` is a Body method — exists on both. Good.

Let me also reconsider: the `onWorldBounds` handler signature — worldbounds event passes (gameObject, isFromLeft, isFromRight, isFromTop, isFromBottom). My handler ignores. But it fires for any body with onWorldBounds=true. I never set ball.body.onWorldBounds = true, so the worldbounds event won't fire. Actually I registered `this.physics.world.on('worldbounds', ...)` but it only fires if some body has onWorldBounds enabled. Since none do, it won't fire. That's fine (I removed my reliance on it). Actually I'm using bottomSensor overlap for loss, so global worldbounds event is not needed. Let me remove the world.on listener to avoid confusion, or leave it (harmless). I'll leave it but it's harmless. Actually let me remove it to keep clean. Eh, leave it; no harm.

Wait, actually there might be an issue: the ball uses `setCollideWorldBounds(true)` which makes it bounce off all 4 world bounds including the bottom (y=600). The bottomSensor at y=600 height 4... overlap with ball. But the ball bounces off bottom at 600, so it might never overlap the sensor placed at 600. Let me reconsider the sensor placement.

The sensor zone: `this.add.zone(WIDTH/2, HEIGHT, WIDTH, 4)` → center y=600, height=4 → covers y 598..602. But the world bound bottom is at y=600 (the world bounds height=600, so bounds y from 0 to 600). The ball's body center can go down to 600 (the bound). collideWorldBounds reflects when body touches the bound (ball center at 600 means ball bottom at 612, partially below). Actually collideWorldBounds reflects when the body reaches the edge. For a circular body radius 12, it reflects when ball center x reaches left+12 etc. At the bottom, it reflects when ball center y reaches HEIGHT - BALL_R = 588. So the ball center never goes below 588 due to bounce. That's above the sensor at 598. So the sensor (598-602) would never be reached by the ball center! The loss detection fails.

Hmm. So with collideWorldBounds bouncing at bottom, the ball won't fall below 588. I need the ball to be able to pass the paddle and fall off. 

So I should NOT use collideWorldBounds for the bottom. Options:
1. Disable world bounds bottom bounce: use explicit walls only for top/left/right (static, bouncy), and open bottom. Then ball falls below paddle, overlaps bottomSensor.
2. Keep collideWorldBounds but rely on worldbounds event to detect bottom and in the handler remove the ball.

Option 1 is cleaner for the "fall below" visual. Let me create explicit top/left/right walls as static bouncy rectangles, and not setCollideWorldBounds on the ball. Then ball falls freely past bottom into sensor.

Let me do that. Walls: top (y=5), left (x=5), right (x=WIDTH-5). Ball bounce 1. Ball collides with walls (collider). Ball does NOT collide with bottom (open). Bottom sensor below paddle.

Let me also make walls static bodies and bouncy. But static bodies' bounce for reflecting a dynamic ball — I need to confirm static body bounce reflects. Let me set both ball bounce(1) and wall bounce(1) to be safe. Actually, let me reconsider: In Arcade, a dynamic body colliding with a static body — does the dynamic body reflect? I believe YES: Arcade's collision response computes restitution. The effective restitution for separating velocity uses `body1.bounce` when body2 is static (mass infinite). Actually I've definitely seen balls bounce off static walls in Arcade with world bounds (which are static). collideWorldBounds uses static world bounds and the ball bounces. So static walls DO reflect a bouncy ball. Good. So explicit static walls with ball bounce 1 → reflection. 

Let me set walls as static bodies, ball bounce 1, collider(ball, walls).

But does the static wall need setBounce? The world-bounds bounce worked without explicitly setting wall bounce (world bounds have bounce 0 by default but the ball bounces). Hmm, actually worldBounds bounce: `this.physics.world.setBounds(..., { ... })` and there's `this.physics.world.setBoundsCollision`. The world bounds collision uses `body.bounce` of the colliding body? Let me just set wall.setBounce(1) and ball.setBounce(1) to be safe. I'll make walls static with bounce 1.

Wait, does ArcadeStaticBody have setBounce? It should (it's a body). Let me check; the earlier error was setAllowGravity not existing on static. setBounce likely exists on static bodies. If not, I'll handle differently. Let me just try and verify in browser.

Actually, to be robust, let me reconsider: use collideWorldBounds true for top/left/right AND disable bottom via `this.physics.world.setBoundsCollision(true, true, true, false)` — this disables collision with the bottom world bound! Then ball bounces off top/left/right but passes through bottom (falls). And detect loss via `worldbounds` event (only top/sides fire, not bottom) OR via bottom sensor. 

`PhysicsWorld.setBounds(x, y, width, height)` and `setBoundsCollision(up, down, left, right)` — note the order is (left, right, up, down)? Let me check Phaser docs: `setBoundsCollision(left=true, right=true, up=true, down=true)`. Hmm the signature order. Actually in Arcade.World: `setBounds(x,y,width,height)` then `setBoundsCollision(left, right, up, down)`? Let me verify. I think the actual signature is `setBoundsCollision(left=true, right=true, up=true, down=true)` — no wait.

Let me just check the phaser source for setBoundsCollision signature.

`setBoundsCollision(n,r,o,a)` — signature `setBoundsCollision(left, right, up, down)`? The params are (t,e,i,s) mapped. Actually the function is `setBoundsCollision(left, right, up, down)`. Let me check the body: 
```
setBoundsCollision:function(t,e,i,s)
```
with default assignments `t===void 0?...`. So it sets left, right, up, down. So `setBoundsCollision(true, true, true, false)` disables bottom. 

Actually the parameter names — let me check which is which by looking at the assignment.

So `setBoundsCollision(left, right, up, down)`. So `setBoundsCollision(true, true, true, false)` disables bottom world-bound collision while keeping top/left/right. Then the ball passes through bottom. I can detect loss via a bottom sensor overlap, OR via the worldbounds event (with `ball.body.onWorldBounds = true`). But since bottom collision is disabled, the worldbounds event won't fire for bottom. So I'll use a bottom sensor zone.

Actually, simpler: keep collideWorldBounds(true) for top/left/right, disable bottom via setBoundsCollision(true,true,true,false), and use a bottom sensor overlap zone. The sensor at y ~ 590-600.

But wait — with collideWorldBounds true and bottom disabled, the ball reflects off top/left/right but freely exits bottom. Good. Then bottom sensor overlap detects loss. 

But also need ball to collide walls/ball. collideWorldBounds handles edges. For paddle/bricks via colliders. Good. This avoids creating explicit wall objects.

Let me go with:
- `this.physics.world.setBounds(0,0,WIDTH,HEIGHT)`
- `this.physics.world.setBoundsCollision(true, true, true, false)` — disable bottom.
- `ball.setCollideWorldBounds(true); ball.setBounce(1,1);`
- bottom sensor zone overlap → ballLost.

This is clean. Let me also make paddle dynamic (so setAllowGravity/setImmovable work). Remove the static paddle approach.

Let me also reconsider: do I even need the worldbounds event listener? No (no onWorldBounds true). Remove it to avoid stale references (it would error if it fired? It won't fire, so harmless, but remove for cleanliness).

Let me fix the code:
1. Ball: remove collideWorldBounds? No, keep (handles top/left/right). Set bounce 1,1.
2. Paddle: dynamic body, setAllowGravity(false), setImmovable(true). Move via body.x.
3. Add `this.physics.world.setBoundsCollision(true,true,true,false)`.
4. Bottom sensor zone.
5. Remove world.on worldbounds listener (optional). I'll leave but harmless; actually I'll remove to be clean. Let me remove the `this.physics.world.on('worldbounds'...)` line and onWorldBounds method? Keep onWorldBounds unused might cause "unused" but fine. Let me just remove the listener registration; keep method no-op? I'll remove both to be clean. Actually removing is fine.

Let me also reconsider the bottom sensor with overlap. The sensor is a static zone. Overlap dynamic ball vs static sensor. Should fire. Good.

But there's a concern: When the ball rests on the paddle during LAUNCH, its checkCollision.none=true so overlap with sensor disabled (but no overlap anyway). On launch, enabled. Good.

Also the bottom sensor y: let me place it at y = HEIGHT - PADDLE area. Paddle at HEIGHT-50=550, top 539. Ball lost when below paddle (~ball.y > 560). Let me set sensor center y = 580, height 24 → covers 568..592. Ball center >568 → lost. Ball on paddle ~538. Good margin. But the world bottom is at 600; with bottom disabled ball falls below to sensor. Good. Actually the sensor at 568-592 is within bounds; ball will reach it falling. Good. Let me also expand to height 40 to be safe: center y=600? No 600 is at bound. Let me do center y=590 height 40 → 570..610. Ball center >570 lost. Good.

Wait but world bound bottom is at 600; ball can fall below 600 (sensor extends to 610). The sensor zone at y=590 height 40 → 570..610. Fine, overlap works for bodies partly below bound? The physics world bounds don't constrain overlap detection. Good.

Let me set sensor zone at y=590, height 40.

Actually, I realize overlap with a sensor: a static-zone body that overlaps — fine.

Hmm, but one concern: the bottom sensor as a static body; the ball's collideWorldBounds bottom is disabled, so ball falls through to sensor overlap. But does the ball fall through the bottom world bound region without any body below? Yes since bottom bound collision disabled. Good.

Let me also double check: with bottom bound collision disabled, does the ball still get reflected by top/left/right? Yes (those enabled). Good.

Now the paddle: dynamic body, immovable. I move paddle.body.x directly. Since velocity 0 and allowGravity false, it stays. The ball collides with paddle (collider). Paddle immovable → ball reflects. Good. Paddle doesn't bounce off world bounds (paddle is dynamic; world bounds collision — does paddle collide with world bounds? By default dynamic bodies collide with world bounds only if `body.setCollideWorldBounds(true)` set. I haven't set it on paddle. So paddle won't be constrained by world bounds. I clamp manually. Good. The paddle won't bounce off anything. Good.

Now bricks: dynamic, immovable, allowGravity false, bounce 1. Ball collides via collider → reflects and destroys. Good.

Let me also reconsider the paddleHit callback: I override velocity. But the collider already reflected (with paddle bounce). Paddle bounce — I set paddle.setBounce? For a dynamic immovable body, setBounce affects reflection. The paddle's bounce default 0. The ball's bounce 1. When dynamic ball (bounce1) collides dynamic paddle (bounce0, immovable), reflection uses... Let me set paddle bounce 0 (default) and ball bounce 1, and in paddleHit override velocity anyway. Actually the override sets velocity based on impact position with full speed upward. So regardless of default reflection, my override takes over. Good. But the default reflection might already move the ball up/down; my override replaces. Fine. Let me keep paddle bounce 0.

Wait, but if paddle bounce is 0 and immovable, on collision the ball (bounce 1) reflects? With immovable body, the response: the dynamic body's velocity is reflected using its own bounce. I think it works. And my override re-sets it anyway. So fine.

Let me also ensure brickHit destroys brick: `brick.disableBody(true,true)`. For a dynamic body, disableBody disables it (body removed from world, gameObject still present but disabled). Then overlap/collider won't fire for it. And brickCount--. Good. Alternatively `brick.destroy()`. destroy() removes from group → getLength updates. Let me use destroy for cleaner group length, but destroy also removes from physics world. Let me use `brick.destroy()` and check `this.brickCount` (manual) for win. Actually I'm tracking brickCount manually. Let me use disableBody to keep it simple and safe, or destroy. destroy is clean. Let me use destroy.

But wait: destroying a body mid-collide-callback (during the physics step) — Arcade handles destroyed bodies (they're removed). Should be fine. Let me use disableBody(true, true) to be safe against mid-step issues. With disableBody, the brick GameObject is deactivated but remains in the group (getChildren still includes it, but body disabled). For win check, I use manual brickCount. Good. disableBody is safer mid-step. Let me use disableBody(true,true).

Hmm, disableBody(true,true) hides and disables the body. The rectangle stays in display? `disableBody` with `disableGameObject=true` sets the GameObject.visible=false and active=false? Then getChildren length stays (object still in group but inactive). My manual count works. Good.

Let me keep disableBody(true,true).

Now, another concern: brick collider fires brickHit for each brick the ball hits. With multiple bricks in a row, fine. But after disableBody, the disabled body shouldn't re-trigger. Good.

Also, the ball could hit a brick and the collider reflect; then onBrickHit destroys. Good. The reflection direction from brick (dynamic immovable bounce0, ball bounce1) — reflects normally. Good.

Now let me also double-check the `this.ball.body.setCircle(BALL_R)` — Ball body created via `physics.add.existing(image,false)` → dynamic Body, rectangle sized to texture (24x24). Then setCircle(BALL_R=12) makes it circular radius 12. Good. But the image is 24x24; the circle fits. Good.

Now also, the paddle is a rectangle GameObject with static? No, dynamic. `this.physics.add.existing(rect, false)`. Good.

Let me also reconsider: I set `this.paddle.body.setImmovable(true)`. Immovable dynamic bodies don't get pushed. When ball hits, ball reflects, paddle stays. Good. But immovable bodies also might not separate properly? Standard. Good.

Also, moving an immovable dynamic body by setting body.x directly — collisions still tested against it. Good. And the sprite position syncs from body. Good.

Now, the `setOrigin(0.5)` for paddle rectangle is default. Good. For body.x setting, fine.

Now, the bottom sensor: `this.add.zone(...)`. zone is a GameObject; physics.add.existing(zone, true) → static body sized to zone (zone default size 0x0 unless set). I set zone size via `this.add.zone(x,y,w,h)`. zone with width/height. Good. Static body of size 800x40. Overlap ball vs sensor fires. Good.

But does overlap require the sensor body's checkCollision? Overlap uses checkCollision of both bodies. The ball's checkCollision is none during LAUNCH (false). During play true. The sensor static body checkCollision defaults all true. Good.

Now let me also verify: `this.physics.world.setBoundsCollision(true,true,true,false)` — this modifies the world bounds collision. The ball with setCollideWorldBounds(true) will bounce only top/left/right. Good.

Let me apply fixes:
- Paddle: dynamic body, remove setAllowGravity? No, setAllowGravity exists on dynamic Body. Keep. Remove the `true` static flag (change to false).
- Add setBoundsCollision disabling bottom.
- Remove/replace onWorldBounds handler (remove world.on listener).
- Adjust bottomSensor placement.

Let me also fix: `this.physics.world.on('worldbounds', this.onWorldBounds, this);` — remove.

Let me make these edits.

Actually, regarding `setBoundsCollision`: default world bounds collision is all true. Since I call setBoundsCollision(true,true,true,false) — bottom false. But note the order (left,right,up,down). Good.

Let me also double check: with collideWorldBounds true on the ball, does the ball still get bounced by top? Yes up=true. Left/right true. Down false → passes. Good.

Now let me edit the create method.

Current relevant lines:
```
    // --- world bounds (top/left/right bounce via CollideWorldBounds; bottom handled by sensor) ---
    this.physics.world.setBounds(0, 0, WIDTH, HEIGHT);
    // --- bottom "death" sensor ---
    this.bottomSensor = this.add.zone(WIDTH / 2, HEIGHT, WIDTH, 4).setOrigin(0.5);
    this.physics.add.existing(this.bottomSensor, true);
```
and paddle:
```
    this.paddle = this.physics.add.existing(this.add.rectangle(WIDTH / 2, HEIGHT - 50, PADDLE_W, PADDLE_H, 0xecf0f1), true); // static, moveable platform style
    this.paddle.body.setAllowGravity(false);
    this.paddle.body.setImmovable(true);
```
and collision setup:
```
    this.physics.world.on('worldbounds', this.onWorldBounds, this);
```
and onWorldBounds method.

Let me make edits.

Edit 1: paddle dynamic.
Edit 2: world bounds collision disable bottom; sensor placement.
Edit 3: remove world.on listener.

Let me do them.

No errors now. Let me take a screenshot to see the initial state.

Screenshots aren't supported in this environment ("model does not support images"). That's fine. Let me instead interact and inspect via console. Let me test launching the ball. I'll simulate: the Launch button is at center-bottom. But I can also press Space. Let me press the space key via the keyboard tool, then observe.

Actually the browser tool has `key` action. Let me send Space to launch. But the scene's keySpace — JustDown fires on key down. Let me press space.

But wait — `input.activePointer` for mouse follow: when no mouse interaction, activePointer is at (0,0)? In Phaser, the active pointer starts at (0,0) and updates on mouse move. So on a fresh load with no mouse move, ptr.x = 0, and my else-branch sets paddle.body.x = Linear(paddle.x, 0, 0.32) → pulls paddle to 0. That's a problem! The paddle would be dragged to x=0 (left) because the pointer is at 0 until the user moves the mouse.

I need to handle this: only follow the pointer when the pointer is "active" (mouse moved or a button down) or clamp the target to the pointer's last real position. Let me track pointer movement. Options:
- Only follow pointer if `ptr.isMouse` and the pointer has been moved (e.g., `ptr.primaryTouch` or some "just moved" flag). Phaser activePointer has `.x` updated on any move. There's no direct "has moved" flag reliably.

Better: track mouse position manually with `this.input.on('pointermove', ...)` to a stored lastMouseX, and only follow if a move happened recently. Or simpler: only follow pointer if the distance between ptr.x and paddle.x is reasonable, OR require a flag set on pointermove.

Let me add an event listener: `this.input.on('pointermove', (p)=>{ this.mouseX = p.x; this.mouseDirty = true; })`. In update, if mouseDirty and no keys, follow this.mouseX. But if never moved, mouseDirty stays false → no mouse follow → paddle stays centered. That's the desired behavior: paddle stays where it is until user moves mouse or presses keys. 

But the requirement: "Move the paddle with Left/Right or the mouse". Mouse move should move the paddle. With the dirty flag, after first mouse move it follows. Good. Let me also reset mouseDirty appropriately or keep it true forever once set (so it keeps following, which is fine — the pointer position is continuously updated once mouse moves). Actually once mouse moves, activePointer.x is always updated, so I can just follow activePointer.x as long as `this.mouseStarted` is true. Set mouseStarted=true on first pointermove. Good.

Alternatively, clamp the pointer target but also stop the paddle from snapping to 0 if pointer at 0. Hmm. Let me use the dirty flag approach — cleanest.

Let me also reconsider: when mouse follows to targetX, and there's no clamping causing the paddle to move under the mouse smoothly. Fine.

Let me also make sure keyboard takes precedence: if left/right isDown, use keyboard; else if mouseStarted, follow mouse; else stay. Good.

Also need to handle when ptr.x is valid (mouse). The activePointer.x when only keyboard is used (no mouse) stays at its last value or 0. Since I gate on mouseStarted, it won't yank.

Let me implement: add `this.mouseStarted=false;`, in create: `this.input.on('pointermove', ()=>{ this.mouseStarted=true; });`. Then in update else-branch: if mouseStarted, follow ptr.x; else nothing (paddle holds position, velocity 0).

Wait, but I removed paddle velocity approach and move by body.x directly (no velocity). For keyboard I do body.x += speed*dt. For mouse I do body.x = Linear. For none, body stays (no velocity). Good.

Actually there's a subtlety: when using body.x direct movement with a dynamic body, after I move it the body has velocity 0. The next physics step won't move it (velocity 0). Good. And the sprite syncs. Good.

Let me also double check that a dynamic body moved by setting body.x directly is properly tested for collisions in the same step. Arcade collision test uses body's current position (the position set this frame before the physics step? Actually physics step runs after Scene.update; in update we set body.x, then step collides). Yes collisions use updated position. Good.

Hmm wait — order: Scene.update() runs, THEN the physics world step() runs (Arcade steps at the world fps). So setting body.x in update affects the positions used in that step's collision? The step reads body.x (the position) at step time. Since we set it before step, yes. Good. And postUpdate syncs sprite from body. Good.

Let me also verify the paddle stays within bounds — I clamp body.x to [PADDLE_W/2, WIDTH-PADDLE_W/2]. Good.

Let me make the fix for mouse. Let me also reconsider: the activePointer.x might be the keyboard-less pointer; with mouseStarted gating it's fine.

Let me edit update.

Current update else-branch:
```
    } else {
      // mouse / pointer follow
      const target = Phaser.Math.Clamp(ptr.x, PADDLE_W / 2, WIDTH - PADDLE_W / 2);
      this.paddle.body.x = Phaser.Math.Linear(this.paddle.body.x, target, 0.32);
    }
```
Change to gate on mouseStarted.

Also need to init this.mouseStarted and add pointermove listener in create.

Let me edit.

Also, the hint text says mouse to move; good.

Let me also reconsider whether pressing Space when pointer at top-left 0 — JustDown(space) works regardless. Good.

Let me also double-check: the Launch button — it's a rectangle + text, setInteractive. On pointerup calls launchBall. Should work on click. Good.

Let me apply edits.

Let me add the mouseStarted flag init and pointermove listener. Let me add near the input section. And then modify the update else-branch.

Let me edit the input section.

No errors. The paddle should stay centered initially. Now let me test launching the ball using the Space key. The browser `key` action sends a key event. Let me try Space.

But wait — JustDown(space) fires on the key-down event. The browser key tool likely sends keydown. Let me try.

Actually, the ball launch via Space: state===LAUNCH, JustDown(space) → launchBall. Let me press space and then observe the physics over a few frames.

Let me press space, then wait and inspect. There's no way to "wait" except reload or action. Let me do key space then motion (animation) to capture frames.

I pressed space. Now let me capture motion to see the ball bouncing. The `motion` action records animation frames (up to 10 seconds or based on duration). Let me use motion with a default duration. The motion action may need a duration. Let me try motion with delta? The motion action records up to N seconds. Let me call motion with a timeout.

The motion action doesn't return image frames I can see (the harness says "model does not support images" for screenshots, but motion is for the agent to see frames). The result only shows console. Hmm. The motion recording probably generates frames but the tool result isn't showing them because images aren't supported by this model. 

So I can't visually inspect frames. I'll have to rely on console inspection and a debug overlay. Let me add physics debug or a console-based position logger to verify behavior. 

Actually, I can add a debug text to the scene that shows the ball position, and then use the `inspect` action to read the DOM/console? The inspect action returns DOM and console. Let me use a debug text that prints ball.x/y, score, lives, state. Then read it via inspect (DOM text? The inspect returns "dom" string). Let me add an always-visible debug text showing ball state, and also log to console via a periodic tick.

Better: let me add console.log in onBrickHit, onBallLost, launchBall, etc., so I can confirm hits. And add a debug text overlay visible in DOM that I can read via inspect.

Let me first inspect to see the DOM currently.

Actually, the inspect action returns the DOM as a string and console logs. Let me add a debug overlay text and re-run, then inspect and trigger brick hits, then inspect console.

But I can't see images, so visual verification is limited. I'll instrument with console logs and a debug text element that I can read.

Let me add:
- A debug text showing ball x,y, vx,vy, score, lives, state, brick count — updated each frame. Visible in canvas. I can read via console? No, it's on canvas. But I can also console.log each frame (every ~1s) via a timer.

Let me add a timer that logs state every 500ms, plus log events. Then I can use inspect to read console after interacting.

Actually, the inspect console only shows logs at the time of inspection. If I do a sequence of actions (key, motion), then inspect, I'll see logs emitted. But logs happen in real-time in the iframe; by the time I inspect, the console captures what's there. Let me add a debug text to the canvas that shows current values, and ALSO log periodically.

Hmm, reading a canvas text via DOM inspect won't reveal the text content (it's drawn on canvas, not DOM). So I must use console.log.

Plan: add a debug ticker that console.log every ~600ms: state, ball.x, ball.y, vx, vy, score, lives, brickCount, paddle.x. Then:
1. Reload (fresh start).
2. Inspect console to see initial debug (ball resting).
3. Press Space (launch).
4. Move paddle a bit (key left/right or mouse) — via drag or mouse. Actually to move paddle with mouse I'd need to move pointer; the `drag` action simulates mouse drag which moves pointer → mouseStarted → paddle follows. Or use keyboard arrow keys.
5. Wait a few seconds (motion).
6. Inspect console → read debug logs to confirm ball moves, bounces, hits bricks, score changes.

Also add console.log in launchBall, onBrickHit (with brick count/score), onBallLost (lives). That gives clear event confirmation.

Let me also make the debug ticker not spam too much (every 0.5s). And maybe log on brick hit.

Let me add these logs and a debug text. Let me also reduce ball speed a bit? 320 is fine.

Let me also reconsider: the paddle collision bounce override — when ball hits paddle, onPaddleHit overrides velocity to aim based on impact. Good. Let me also ensure when ball rests on paddle (LAUNCH) then launches, the ball doesn't immediately re-collide weirdly. On launch, ball velocity set upward, checkCollision re-enabled. The ball is positioned just above paddle. It moves up. No immediate collision. Good.

One concern: after launch, in the SAME frame update continues to LAUNCH-follow? No, state changed to PLAYING so the LAUNCH follow block doesn't run. Good.

Another concern: the ball's circle body radius 12; setCollideWorldBounds reflects at edges with bounce 1. Should bounce fine.

Let me also verify the brick collider: bricks are dynamic immovable with bounce 0. Ball bounce 1. On collide, ball reflects (since dynamic body with bounce collides immovable). The reflection off a brick: depends on impact angle. Should reflect. Good. And onBrickHit disables brick + scores.

Wait, there's a potential ordering issue: onBrickHit (collide callback) fires AFTER physics resolves the collision (ball reflected & separated). Then brick.disableBody. Next frames, disabled body not tested. Good. But within the same step, if the ball is touching multiple bricks, each pair's callback fires. Fine.

However, one concern: disableBody(true,true) on a dynamic body mid-step — disables the body so subsequent collision tests skip it. The manual brickCount-- tracks total hits. When brickCount<=0 → win. But note: brickCount starts at ROWS*COLS = 5*11=55. Good.

But careful: if a single ball overlaps multiple bricks in one step, each calls onBrickHit decrementing. Good. When count hits 0, win. But what if the ball hits the last brick and also still moving — fine.

Let me also ensure the win check sets state WIN and stops ball. Good.

Now, the bottom sensor overlap: when ball falls below paddle, overlaps sensor → onBallLost. But during the fall, the ball also might bounce off the paddle? No, it's past paddle. It falls into sensor (y 570-610). Detected. Good. But wait: the sensor is at y 570..610. The ball falling passes through. Overlap fires. Good. In onBallLost, I set velocity 0, checkCollision none, lives--, etc. Good.

But there's a subtle issue: the ball during PLAYING has collideWorldBounds true (top/left/right bounce, bottom disabled). As it falls below 600, it continues into sensor region (y up to 610). The sensor zone is at y=590 height 40 → 570..610. Good overlap. 

Now, also: could the ball fall and the bottom sensor overlap trigger while also the ball is moving fast and skip? Overlap detection is per-step (continuous? Arcade has no CCD by default). At 60fps and speed 320 (~5.3 px/frame), won't skip a 40px zone. Good.

Let me add the instrumentation and re-test via console logs.

Let me edit to add debug logging.

I'll add in create:
```
// debug ticker
this.debugText = this.add.text(10, HEIGHT-60, '', {fontSize:'12px',fill:'#ff6b6b'});
this.debugText.setOrigin(0,0);
this.debugTick = 0;
```
In update, increment debugTick by delta; if >600ms, log and update debugText, reset.

Actually debugText on canvas I can't read. But console.log I can read via inspect. Let me just console.log.

Let me add a timer event in create:
```
this.time.addEvent({delay:500,callback:()=>{ console.log('DBG', this.state, Math.round(this.ball.x), Math.round(this.ball.y), Math.round(this.ball.body.velocity.x), Math.round(this.ball.body.velocity.y), 'score',this.score,'lives',this.lives,'bricks',this.brickCount, 'px', Math.round(this.paddle.body.x)); }, loop:true});
```
And console.log in launchBall ("LAUNCHED", vx, vy), onBrickHit ("BRICK", score, brickCount), onBallLost ("LOST", lives), onPaddleHit ("PADDLE").

These help me confirm behavior via console inspect.

Let me add them.

Let me edit the file.

Oops, I removed the onBrickHit line by mistake. Let me re-read the file around there.

I see, the edit removed the `onBrickHit(ball, brick)` signature line but left the body as an orphaned block `{ ... }` after onPaddleHit. I need to restore the `onBrickHit(ball, brick)` method declaration. Let me fix by re-adding it.

Now let me reload and inspect to see the initial state debug log, then launch and observe. Let me reload first.

Initial load, no debug log yet (ticker first fires after 500ms). Let me wait a moment and inspect to capture the initial DBG log (ball resting on paddle). Let me use motion briefly then inspect. Actually motion takes time; let me just inspect after a short delay. The inspect action itself probably takes some real time? Not sure. Let me do a short motion (1s) to allow the 500ms ticker to fire, then inspect.

Actually let me do: motion for ~1.5s to capture the first debug tick while ball is resting, then inspect console.

The inspect console doesn't show my DBG logs. That's strange — the console shows the Phaser boot message and WebGL warnings but not my console.log from the ticker. 

Wait — the console output shown is the iframe's console. The "log: Phaser v3.80.1" is Phaser's own console message. But my console.log('DBG ...') from the ticker isn't appearing. Why?

Possibility: the console captured is from a specific time snapshot, and my logs appear but are filtered/truncated. Or the ticker didn't fire because... the scene's update might not be running? Or the `time.addEvent` is paused until the scene starts? The scene is running (Phaser boot message). The ticker delay 500ms loop should fire. During motion 2s, it should fire ~4 times.

But the inspect console shows the same list as before — maybe the console returned is a snapshot taken at a different time, or it only captured logs emitted during the action's duration. Hmm.

Actually maybe the issue: `console.log` calls from within the iframe are captured but the returned "console" array might be capped. The previous inspect showed only Phaser log + warnings. My DBG logs not present suggests the ticker didn't log, OR the console buffer only returns a subset.

Wait, maybe the issue is that the iframe console shown is the *outer* console captured before/after, and logs from inside the iframe appear under a different mechanism. But the Phaser "log" appears (the colored Phaser banner), so iframe logs DO appear. So my logs should too. They don't. So the ticker likely never fired → the scene update/ticker not running?

Let me reconsider. Maybe the scene didn't start because... Actually the Phaser banner appears, meaning `new Phaser.Game(config)` ran and it booted. The scene 'Game' should start automatically (the default/start). Hmm, but did the scene's create run? If create ran, the ticker would fire after 500ms. 

Maybe the motion/inspect tools capture console from a *fresh* evaluation, and the logs from the previous motion (2s) should still be in the console if the iframe persists. The console seems to only show boot messages. Possibly the logs are emitted but the tool's console array is the state at the moment of the action return, and since the iframe persists across actions, logs accumulate. But we only see boot messages — meaning no DBG logs were emitted.

Let me check: maybe the ticker callback runs but `console.log` inside `time.addEvent` — the scene might not be ticking because... Actually wait, maybe `this.time.addEvent` with `loop:true` and `delay:500` — the first fire is after 50ms? No, delay 500 → first fire at 500ms. During a 2-second motion, should fire 4 times.

Unless the scene isn't running because the browser paused the iframe? No.

Alternatively, maybe the console shown is stale (captured at iframe load) and doesn't update. The repeated WebGL warnings "this message will no longer repeat" suggests the console reflects accumulation (it deduplicated repeat warnings). So the console IS updating. But my DBG logs aren't there.

Hmm, could it be that console.log inside the iframe is being suppressed? Or maybe the scene's create threw after the ticker setup? No, no error.

Wait — maybe the issue is `this.time.addEvent` is called in `create`, but the scene's `create` runs once at start. Good. But maybe the scene didn't start because the default scene didn't auto-start? With `scene: SceneA` where SceneA is a class, Phaser auto-starts it. The boot banner shows. 

Let me add a console.log at the very start of create to confirm create runs, and log immediately (not via ticker), re-reload and inspect.

Actually, let me reconsider: the inspect action returns the console "at this moment". The previous motion(2s) should have allowed ticks. But the console returned by inspect (a separate action after) shows only boot messages. This strongly implies the DBG logs were never emitted → create's ticker never ran → maybe create didn't run, or errors silently.

But on the very first reload, there was NO error. So the scene created without error. So create ran, ticker set. Ticker should fire.

Unless... the `time.addEvent` callback references `this.ball` which is set. Should be fine.

Wait, maybe the console captured by the tool is the *parent* page console, and the iframe's console.log goes to the iframe's own console which the tool captures as a snapshot — but the snapshot timing: the tool's `inspect` might capture console right at the moment, but maybe logs emitted during motion are captured and shown during motion, and by the time inspect runs they've been... no, logs persist in console history.

Let me add an immediate console.log in create and a per-update log (every nth frame) to be sure. Also let me reduce reliance on ticker — log in update periodically. And log on create.

Actually, maybe simpler explanation: the browser tool's "console" field returns the console entries captured during that action's lifetime. The `motion` and `inspect` actions each have their own window; logs emitted during motion(2s) should show. But they didn't. The Phaser banner shows because it's logged at boot which is during the action. 

Wait, in the motion action just now, the console showed Phaser banner + warnings but the motion action's console should include the 500ms tick logs too if they fired. It didn't. So ticks didn't fire during motion(2s)? That means create's time.addEvent didn't run, OR the scene isn't ticking.

Let me test more directly: add console.log('CREATE DONE') at end of create, and a console.log in update() always (or every 60 frames). Reload and inspect immediately (without motion). The reload action returns console which should include 'CREATE DONE' and 'update' logs.

Actually, the `reload` action returned console with only boot messages (Phaser banner + warnings), no "CREATE DONE" if I had it. But I don't have it now. Let me add it and a frequent update log, reload, and inspect.

Let me also consider: maybe console output from the iframe is being captured but `console.log` with a long string is fine. 

Hold on — maybe the real issue: the iframe console shown is captured BEFORE my logs because the tool returns console at the *start*? No, boot banner is there.

Let me just add immediate logs and re-test. Let me add:
- In create, right after resetBall(): `console.log('CREATE DONE state='+this.state);`
- In update: `if(this._f==null)this._f=0; this._f++; if(this._f%30===0) console.log('UPD state='+this.state+' ball.y='+Math.round(this.ball.y)+' vxvy='+Math.round(this.ball.body.velocity.x)+','+Math.round(this.ball.body.velocity.y));`

Then reload, inspect (no motion). The inspect should show CREATE DONE and UPD logs.

Let me add these.

Actually, the update logs would be frequent (every 30 frames ~ every 0.5s). Good.

Let me add.

Now I see "CREATE DONE state=launch bricks=55". The create ran. But no UPD logs yet (need time for 30 frames). Let me do a short motion and then inspect to capture UPD logs and the resting ball.

Still no UPD logs. The scene create runs but update doesn't tick? That's odd. The `_f` counter increments in update; if update never runs, no UPD logs. Also the 500ms timer never logged. So the scene's update loop isn't running!

Why? Possibly because the scene is in a state where `this.scene` is paused, or the game loop is paused. Or maybe the iframe is "hidden" (not visible) so Phaser pauses the update loop? Phaser pauses the game loop when the tab/window is not visible? Actually Phaser doesn't auto-pause on blur by default, but the browser may throttle background tabs. But the iframe should be visible.

Wait — maybe the issue: I created the game with `new Phaser.Game(config)` but the scene's `update` runs only if the scene is started. The scene auto-starts. But maybe `update` only runs if there's a render loop and the scene is not paused. 

Hmm, but the ticker (time.addEvent) also didn't log. Both rely on the game loop. So the game loop (update + timers) is NOT running. That means the scene is paused or the loop isn't ticking.

Why would the loop not tick? Maybe because the canvas/iframe isn't rendering/ticking. The Phaser banner and WebGL warnings appear (from boot). But no frames.

Possible: Phaser's update loop is driven by requestAnimationFrame. In a hidden/backgrounded iframe, rAF may be throttled/paused. But the tool presumably shows a live iframe...

Wait, maybe the problem is that the tool's iframe is not "visible" to the browser so rAF doesn't fire, OR the tool only runs the game during a specific action and the motion action's frames... but the ticker should fire during motion(2s).

Actually, wait: maybe the motion action DOES run frames, and the UPD logs should appear during motion, but the console returned shows the same as before (CREATE DONE) — i.e., no UPD logs during the 2-second motion. So the game loop is genuinely not ticking.

Hmm, but the game DID boot. Why no update? 

Let me reconsider. Maybe `update` isn't being called because... In Phaser, `update` is called if defined on the scene. I defined `update()` method on the class. Should be called.

Maybe the scene is paused because of an error during create AFTER my console.log? If create threw after 'CREATE DONE', the scene would be in ERROR and update wouldn't run. But the console would show the error. No error shown.

Wait — 'CREATE DONE' is logged at the END of create now. So create completed successfully. So update should run.

Unless the game loop is paused. Let me reconsider: Could `this.game.loop.delta` or something cause a freeze? No, update just logs.

Let me reconsider the possibility that the iframe is backgrounded (the tool might show it as not actively visible). Many browser automation iframes are not visible = rAF throttled to ~1fps or paused. But 2 seconds should still give ~1-2 frames, and the 500ms timer (time.addEvent based on elapsed) — Phaser's timer uses its own clock? It uses the game loop's delta or real time? Phaser's Time module uses a real timer based on `Date.now()` and the game loop. If the loop is throttled, timers fire slowly but should still fire after 500ms of real time? Actually Phaser's timers are updated in the step using delta; if the loop is paused, timers don't update.

Hmm. So the whole loop is paused → update and timers both stop. That points to the game loop not running because the canvas isn't visible/active in the iframe.

But wait, the very first reload showed the Phaser banner and WebGL warnings — those are logged synchronously at boot, before any rAF. So they appear regardless of loop. No UPD/timer logs means loop not running.

Could it be that the game loop IS running but update throws silently? No, errors would show.

Let me reconsider: maybe `this._f % 30 === 0` — _f starts null→0 at first update, then `this._f++` makes it 1, check 1%30. Wait order: I set `if(this._f==null) this._f=0; this._f++; if(this._f%30===0)`. First update: _f becomes 1, 1%30≠0. So no log on first. After 30 updates (~0.5s at 60fps), _f=30 → log. During 2s motion, should log ~4 times. But timer (500ms) should also fire. Neither appears. So loop not running.

I think the game loop is being throttled because the iframe is not visibly rendered/active in the harness's browser. This is a known issue: headless/embedded iframes often don't fire rAF when "not visible".

But the task says "Run the application in the browser and inspect the initial output and console." and the motion action implies the browser renders frames. The WebGL warnings about ReadPixels "High: GPU stall" appearing suggests rendering IS happening (ReadPixels is called during render). So frames ARE rendering (rAF fires, rendering happens) — the WebGL warnings come from the render pipeline. So the loop IS running (rendering each frame). But update() not logging?!

If rendering happens (rAF fires, WebGL ReadPixels warnings), then update() should also fire each frame. Unless... update() IS running but throwing? But no error. Or my logging condition is wrong.

Wait, maybe the issue is that `this._f` accumulates across the motion but `_f % 30` logs at frames 30,60,90... during 2s at 60fps that's frames 120 → 4 logs. They should appear.

Unless update() is NOT being called. But rendering is. That's contradictory unless the scene is set to not call update? Or the Scene's update exists but... 

Hold on. Maybe the issue: I'm defining `update()` as a method, but Phaser only calls the scene's update if the scene is active and the method exists. It exists. 

Wait, could there be TWO scenes or the wrong scene active? Only one scene SceneA.

Let me reconsider the timer: time.addEvent first fires after 500ms. If loop runs, it fires. If no timer log, loop not running. But WebGL warnings say rendering happens.

Maybe the WebGL warnings are from a SINGLE render (at boot) and then the loop pauses? The "GL Driver Message ... ReadPixels" appears 3 times (then "no longer repeat"). ReadPixels is called each render frame normally. If loop paused after boot, only a few initial renders. Hmm.

Actually, I bet the harness runs the iframe and the motion action captures frames by rapidly stepping? Or the iframe rAF runs but update is throttled? 

Let me reconsider: maybe the game loop pause is because Phaser auto-pauses when the window loses focus or when the canvas isn't visible. The harness iframe might be considered "hidden". But rendering warnings suggest it renders. Confusing.

Let me try a different, more reliable signal: log from within `create` using a `this.time.delayedCall(300, ()=>console.log('TIMER FIRED'))`. If even that doesn't fire, loop is dead. And add a `requestAnimationFrame`? 

Actually, let me reconsider whether `update` is even being invoked. Let me add a log at the very TOP of update (no condition): `console.log('UPDATE')` — but that's 60 logs/sec, too noisy but the tool captures. Actually the console might cap. Let me log every 60 frames but ALSO log immediately: Actually let me just log once in create via delayedCall(200) and also confirm update by a single log on first update.

Hmm, let me reconsider the real possibility: The harness's browser tool may render the page and capture a few frames during `motion`, but the Phaser game loop relies on rAF which the harness's hidden iframe might not sustain. The fact that `CREATE DONE` appears (synchronous in boot) but no UPDATE/TIMER logs strongly suggests the tick loop isn't running in this harness context — OR there's an exception in update/timer before it logs.

Let me check for exceptions: maybe `this.game.loop.delta` is undefined or `this.ball.body.velocity` — no, those are fine. `this._f` first update: `if(this._f==null)` true → set 0; `this._f++` → 1; `1%30`. fine. `this.ball.body.velocity.x` — ball exists. `this.ball.x` fine. So no throw.

Wait, is `update` even defined as a method? In a class, yes `update(){...}`. Let me double check I didn't accidentally misplace it. Let me re-read the file around update.

Actually, wait — maybe the problem is that the scene's `update` is defined but Phaser's Scene.update is called only when `scene.settings.updateSort`? No. update is called if present. Hmm.

Alternatively, maybe the loop IS running but the console tool isn't capturing logs emitted during `motion`? The motion action returned console that includes 'CREATE DONE' (from boot, synchronous). But logs emitted during the 2-second motion (UPDATE) should be captured in the motion's returned console if the tool captures continuously. It showed only boot-level logs. 

Wait, actually look: the motion action's console returned includes 'CREATE DONE' — that's from boot (synchronous) which happened during the motion action's lifetime too (reload→motion). Actually between reload and motion, create ran (CREATE DONE). The motion action's console shows that line + the initial warnings. It does NOT show UPD logs from during the motion. So during the 2s of motion, no UPD logs were emitted → update didn't run during motion.

So either update isn't running, or timer/update not ticking. But rendering warnings suggest some frames.

Let me try: maybe the harness runs the iframe and `motion` captures frames via rAF, so rAF IS firing (that's why WebGL warnings appear — render happens). If rAF fires, Phaser's main loop (update+render) runs each frame. So update MUST run each frame. So UPD logs should appear. Unless my update has a bug causing it to skip logging.

Let me re-read my update carefully.

```
update() {
  // restart key
  if (Phaser.Input.Keyboard.JustDown(this.keyR)) {
    if (this.state === GameState.WIN || this.state === GameState.GAME_OVER) this.restart();
  }
  if (this.state === GameState.WIN || this.state === GameState.GAME_OVER) return;

  const dt = Math.min(this.game.loop.delta * 0.001, 0.06);
  const ptr = this.input.activePointer;

  if (this._f == null) this._f = 0;
  this._f++;
  if (this._f % 30 === 0) {
    ... console.log('UPD ...');
  }
  ...
}
```

At start state is LAUNCH, so it doesn't early-return. _f increments. After 30 frames logs.

Hmm, maybe `this.game.loop.delta` is 0 initially (loop.delta at first frame = 0 or NaN)? `this.game.loop.delta` — the loop object. Actually the property is `this.game.loop.delta`? Phaser.Game.loop has `elapsed` and `delta`? Let me check. `game.loop.delta` — I think `loop` has `elapsed` (ms) and `delta`? In Phaser 3, `this.game.loop` has properties `fps`, `delta`, `elapsed`, etc.? Actually `this.game.loop.delta` might be undefined → `undefined*0.001` = NaN → `Math.min(NaN,0.06)` = NaN. Then later `this.paddleSpeed * dt` = NaN → paddle.body.x = NaN. But that wouldn't stop the update log (which runs before that line). The log runs after `const dt=...` line? No — the `_f` log block is AFTER the dt/ptr lines. If `dt` is NaN, the code continues (NaN propagates but no throw). So UPD log should still fire at frame 30.

Wait, order in my edit: I put the `if(this._f...)` block AFTER `const dt` and `const ptr`. So dt computation (NaN) doesn't prevent the log. So log should still fire. Unless dt being NaN causes something... no, NaN just propagates to paddle math, no throw.

So UPD should fire at frame 30. Unless update never runs.

Let me verify update runs by adding a log at the very first line of update (unconditional first-3-frames):
Actually, let me just move the _f log to the very top of update and log unconditionally on first call. And add a delayedCall timer in create.

Actually, the 500ms time.addEvent also didn't fire. Two independent timers not firing = loop not running. So update not running AND timers not running → the game loop / tick isn't happening.

But rendering warnings (ReadPixels) → some rendering. Could be initial boot render only, then loop stops.

Hypothesis: The harness "motion" action steps the simulation a limited number of frames or renders some frames but doesn't run Phaser's update loop enough? That seems unlikely.

Alternative hypothesis: Maybe the scene is being PAUSED by Phaser because the canvas/context lost focus, and Phaser's `VisibilityHandler`/`focus` pauses the loop? Phaser auto-pauses the Scene when window blurs? No, Phaser pauses scenes on window blur only if configured (`this.game.loop.sleep`? no). Actually Phaser does NOT auto-pause on blur by default.

But the harness iframe might be hidden → the browser throttles rAF heavily (background tabs: rAF throttled to ~1fps or paused). The initial boot render + WebGL warnings (3, then no repeat) suggest only ~3 initial frames rendered, then throttled to pause. The "no longer repeat" warning means it stopped logging that warning → renders stopped. So after ~3 frames, rendering paused. So the game loop is effectively paused because the iframe is backgrounded/throttled.

So in this harness, the iframe runs briefly then throttles. That means I can't get many update ticks. Hmm.

But the task expects me to "Run the application in the browser and inspect the initial output and console" with "a brief pass." Maybe the harness renders a handful of frames. The initial output (ball resting, bricks, paddle, UI) is what matters most, plus launching once.

Given the throttling, let me get the initial state confirmed and do a launch then quickly inspect console within one motion action (where render might run). The motion action likely forces rendering during its capture. So let me: reload, then immediately (without separate motion) do a `motion` with launch input? The motion action probably renders frames; during those frames update runs and logs. Let me try: reload → key(space launch) → motion(2s) → inspect, and see if UPD/BRICK logs appear during motion.

Earlier after launch+space, I did motion(6s) but didn't inspect the combined. Let me redo carefully: reload (fresh), then key space (launch), then motion 3s, then inspect console. If the loop runs during motion, I'll see UPD logs and hopefully a BRICK HIT if the ball hit bricks.

Actually, in my earlier test (first space press + motion 6s), the console after didn't show UPD. But that was inspected separately. The motion action itself returns console captured during those 6s. That motion(6s) console only showed boot warnings, no UPD. So during that 6s motion, update did NOT log. But motion presumably rendered frames (ReadPixels warnings... actually those stopped repeating). Hmm, the motion console showed the warning 3x then "no longer repeat" — consistent with ~3 frames then stop. So during the 6s motion, only ~3 frames rendered. That means the motion action doesn't sustain 60fps; it renders a few frames.

This is a real constraint: the harness renders very few frames per action. So I can't rely on many ticks. But I can still verify the initial render (ball on paddle, bricks, UI) which is the key "opening" state. And verify launch by pressing space and capturing the immediate next frames.

Given the constraints, let me focus on verifying the most important things via the immediate console: create ran (done), and after space press, launchBall logs 'LAUNCHED' and the ball has velocity. The 'LAUNCHED' log is synchronous on keydown → should appear immediately in the next inspect.

Let me also reconsider: maybe the game loop isn't running at all because of an issue with the Scene config. Let me double-check: `scene: SceneA` where SceneA is a class. Phaser accepts a class or object. With a class, it instantiates and auto-starts. update method present. Should work.

But maybe the loop pause is the real issue. Let me test by making the game render-driven: Actually Phaser update IS render-loop driven. If rAF is throttled, few frames.

Let me try a different approach to verify physics: Instead of relying on ticks, I can simulate many update steps in my head / trust the code. But I want to actually verify the launch and bounce.

Let me try: reload, press space (launch), then do `motion` with a short delta (e.g., 4s) and capture console. If even a few frames of motion run after launch, the ball will have velocity and maybe bounce off top/walls and hit bricks. I might catch a BRICK HIT log. Let me try and inspect.

But there's risk the throttle means <1 frame runs after launch. Let me try increasing the chance: do `key space` then `motion` (which should render several frames), then immediately `inspect`.

Let me also reduce reliance: maybe the harness `motion` action DOES run at full 60fps for the duration internally (the tool said "motion frames"). The "ReadPixels" WebGL warnings appear a few times then dedup — that's just the warning dedup, not evidence of frame count. So motion may actually run 60fps for the duration. In that case UPD logs WOULD appear during motion. But they didn't in my last motion(2s)? Let me re-examine: the last motion(2s) console showed CREATE DONE + warnings but no UPD. If motion ran 120 frames, UPD (every 30) = 4 logs. They'd appear. They didn't. So motion did NOT run 120 frames of update. So either update didn't run or motion didn't render that much.

Wait, but maybe the console returned by motion is captured only at the START? It includes CREATE DONE which is from bootstrap during reload (before motion). Hmm, actually the sequence: reload (console has boot+CREATE DONE). Then motion(2s). The motion console returned shows boot+CREATE DONE+warnings. If motion rendered frames with UPD logs, they'd be appended. They're not. So no UPD during motion.

Therefore update() is NOT running during motion. But motion presumably renders something. Contradiction unless the scene is paused.

Let me reconsider: maybe the scene's `update` is not defined correctly due to a syntax issue, causing Phaser to not call it (and no error because missing method just means no update). Did I accidentally put update inside the class? Let me re-read the file fully to check structure.

The structure is correct; `update()` is defined in the class. So why isn't update running?

The likely cause: the harness's iframe is throttled/paused (background). The boot logs and a few initial renders happen, but the game loop (rAF-driven update) pauses after a short time.

Actually, wait. Let me reconsider. Maybe the game loop runs at 60fps but the console capture in the tool only retains a limited number of log entries and my logs are being truncated? The console shown includes boot (1 log) + CREATE DONE (1 log) + 3 warnings. If UPD logged 4 times, total would be ~9 entries. The tool might cap console at ~N entries but that should include them.

Hmm. Let me reconsider: maybe `this.game.loop` is not the right access and `this.game.loop.delta` throws? No, throws would show error.

Actually — maybe the game loop is paused because the harness runs the iframe in a "paused" state and only renders a few frames on certain actions. The `motion` action might be the one that actually drives the simulation. But motion's console didn't show UPD logs... 

Wait, actually, let me reconsider the order of my earlier actions. After adding the debug logs, I did: reload (saw CREATE DONE). Then motion(2s) (saw same console, no UPD). Then I'm now reading structure.

Let me try a more aggressive approach to confirm the loop runs: do `key(space)` to launch, then `motion` with a longer duration, and inspect the console returned by THAT motion action (which captures logs during the motion). Let me also temporarily make the UPD log fire every frame (every frame) for the first 60 frames so even few frames produce logs. Change `% 30` to `% 1` temporarily? That'd be 60 logs/sec but the console might show many. Let me log every frame to maximize chance of catching.

Actually, let me reconsider: maybe update IS running but my console.log calls are being suppressed because... no.

Let me reconsider `this.game.loop.delta`. In Phaser 3.80, is it `this.game.loop.delta` or `this.game.loop.delta`? The GameLoop class has `.delta` (current step delta) and `.elapsed`. Actually I think it's `this.game.loop.delta`. Let me verify. If undefined, NaN, but update still runs (no throw). So UPD still logs at frame 30.

Unless `this.game.loop` is undefined → `this.game.loop.delta` throws TypeError → update throws → scene might error and Phaser logs error. But no error shown. Hmm but if update throws every frame, Phaser would log the error repeatedly? Maybe suppressed. And timers would still run (timers are independent of update? No—Arcade world and Time module update each step; if the step throws, timers don't update). So a throw in update would also stop timers. That matches! Let me check if `this.game.loop.delta` is valid.

Let me grep phaser min for "loop.delta" or the GameLoop properties.

Actually, let me just simplify: remove the dependence on `this.game.loop.delta`. Use `this.game.loop.delta`? Let me verify the property name. Let me grep.

So `this.game.loop.delta` is a valid property (used internally as `this.game.loop.delta`). So accessing it shouldn't throw. Let me check the value type. `delta:o` means delta is an object? "delta:o" — in the minifier, `delta:o` could mean `delta: o` where o is a variable. Hmm. And `delta:e`. These are different occurrences. The GameLoop class likely has `delta` property = a number (frame delta in ms). Let me check more carefully.

Actually "this.game.loop.delta" is referenced internally so it exists. So not the issue.

Let me reconsider. Maybe the loop genuinely doesn't run in the harness iframe (throttled). Let me test the timer more directly with a delayedCall and also log every frame. Let me change the UPD to log every frame for first 200 frames but cap. Actually, let me just change to log every frame unconditionally but that's noisy. Let me log every frame for the first 120 frames then stop.

Actually, a cleaner diagnostic: replace the periodic _f log with a log that fires every frame but only during motion. The tool returns console captured during the action. Let me just log every frame (no modulo) and see if ANY "UPD" appears during a motion. If the loop runs even 1 frame during motion, I'll see one.

Let me also add a delayedCall(150) in create that logs "TICK".

Let me also consider: maybe the harness's `motion` action does NOT run the iframe's JS loop; it just captures existing canvas frames. And the iframe only runs JS at load (sync) then is inert. In that case, NOTHING after create-ticker will run. But the Phaser banner logged synchronously. And 'CREATE DONE' is in create (sync). So only sync logs appear. The loop never runs because the iframe isn't actively browsing.

But then the game wouldn't be "playable" in the harness. The task says "Run the application in the browser and inspect." Maybe the harness does run it but throttles.

Hmm, let me reconsider: When I pressed Space earlier (key action), did launchBall run? I can't tell because no LAUNCHED log appeared (I didn't inspect after). Let me test the key action produces a synchronous log: I added console.log('LAUNCHED ...') inside launchBall, which runs on JustDown(space) in update. If update never runs, LAUNCHED never logs.

So the critical question: does update run? Let me get a definitive answer by logging every frame.

Let me change the _f log to log every frame (with a guard to stop after 200 to avoid flooding):
```
if(this._f < 200){ console.log('UPD frame=' + this._f + ' state='+this.state+' ball.y='+Math.round(this.ball.y)+' vy='+Math.round(this.ball.body.velocity.y)+' bricks='+this.brickCount); this._f++; }
```
Put _f init before. Remove the modulo. Log first 200 frames.

Then reload + motion(2s) + inspect. If loop runs, I'll see UPD frame=0..N. If not, only CREATE DONE.

But 200 logs might flood; the tool might cap display. Let me log first 30 frames (enough). At 60fps 30 frames = 0.5s. Let me log first 60 frames (1s) — should capture during a 2s motion.

Let me also keep the 500ms timer log; if it fires I'll see 'DBG...'. Let me change timer delay to 200ms for quicker.

Actually, let me reconsider the whole diagnostic. Let me just make update log unconditionally every frame but only the first 60, and inspect.

Let me edit.

Time is running short. Let me reload and inspect to see if update runs. Let me do reload then inspect quickly.

Now the loop IS running during reload! The console shows UPD frame=0,1,2. And I see ball=(400,530) initially then frame=2 ball=(352,529) — the paddle moved to 352 (mouse follow kicked in because mouseStarted... wait mouseStarted should be false initially). Why did paddle move from 340→352? Hmm. Actually frame 0 paddle=340, frame2 paddle=340? It shows paddle=340 at frame 0 and 2? Let me re-read:

frame=0 ... paddle=340
frame=1 ... paddle=340
frame=2 ... paddle=340? The log: "UPD frame=2 state=launch ball=(352,529) v=(0,0) bricks=55 paddle=340". So ball moved to x=352 but paddle stays 340. Why did ball.x change to 352? The ball is resting on paddle; in LAUNCH I set ball.body.x = paddle.body.x. So ball.x should equal paddle.x=340. But it shows 352 at frame 2. 

Wait, maybe the reload action captured the iframe rendering over multiple frames and my mouse (the harness pointer) is at some x, and mouseStarted got set true via a pointermove from the harness moving the mouse to capture the frame? Possibly the harness moves the pointer during reload, setting mouseStarted=true, and then... but if mouseStarted true, paddle would follow pointer.x. But paddle stayed 340. Hmm. Actually ball.x=352 but paddle=340 — ball.x not equal paddle.x means the LAUNCH-follow line didn't run for that frame, OR paddle.body.x is 340 but ball.body.x is separate.

Wait, in update for LAUNCH: `this.ball.body.x = this.paddle.body.x;` sets ball to paddle (340). But ball shows 352. So maybe frame=2 was captured at a moment before the LAUNCH-follow line? No, the follow line always runs in LAUNCH. Unless state changed. But state=launch (LAUNCH) shown. So the follow line ran setting ball.x=340. But the log shows ball.x=352.

Hmm, contradiction. Unless the ball's body.x was changed by something else. OR the log at frame=2 reflects a state where... wait, maybe my read is off. Let me re-read the exact console:

"UPD frame=0 state=launch ball=(400,530) v=(0,0) bricks=55 paddle=340"
frame 1 not shown directly (between 0 and 2 there's the warning, then frame=1)... 
"UPD frame=1 state=launch ball=(400,530) v=(0,0) bricks=55 paddle=340"
"UPD frame=2 state=launch ball=(352,529) v=(0,0) bricks=55 paddle=340"

So at frame 2, ball.x=352 but paddle=340. That's inconsistent with my follow code (which sets ball.x=paddle.x=340). Unless... OH. The ball.x in the log is `this.ball.x` (the GameObject), but I set `this.ball.body.x`. Arcade: setting body.x directly — does the GameObject x get updated immediately? For a dynamic body, setting body.x does NOT immediately update the GameObject's transform; the GameObject is synced from the body at the END of the step (postUpdate). So during the same frame's update, setting body.x then reading ball.x (GameObject) returns the OLD sync value. So there's a one-frame desync: ball.x lags body.x by one frame.

At frame 0: paddle body.x set to 340 (initial). ball.body.x set to 340. ball.x (GameObject) still 400 (initial position) — wait frame 0 shows ball.x=400 (initial position, before any body→sprite sync). Actually at create, ball GameObject at 400. Frame 0 update sets body.x=340 (paddle). ball GameObject.x is still 400 (will sync to 340 at end of frame 0's physics postUpdate, so frame 1 sees 340). Frame 1: ball.x=400 still? It shows 400. Hmm, then frame 2: ball.x=352.

This is getting confusing due to the one-frame sync delay and the paddle possibly moving. The key takeaways:
- The loop runs (frames 0,1,2 logged). 
- The ball rests (v=(0,0)) during LAUNCH. 
- bricks=55. 
- paddle at 340 (initial center). 

Wait paddle=340 but paddle initial x = WIDTH/2 = 400. Why 340? The paddle body.x after one frame: in update frame 0, since no keys and mouseStarted false, the else-if chain does nothing → paddle.body.x unchanged = 400. But log shows 340. Hmm. So paddle moved to 340. That means mouseStarted became true and pointer.x was 340ish? The harness pointer might be at x~340 (left of center) when the iframe got focus, and a pointermove event set mouseStarted=true. Then paddle.body.x = Linear(400, 340, 0.32) → 400 - (60*0.32)=400-19=381, not 340. But log frame0 paddle=340. 

Hmm, maybe the harness mouse is at x=340 and mouseStarted true, and over frames Linear moves paddle toward 340: frame0 ~381, frame1 ~368, frame2 ~359... but logs show 340 each frame. That doesn't match Linear progression. 

Actually wait, maybe mouseStarted true and ptr.x=340, and `Phaser.Math.Linear(this.paddle.body.x, target, 0.32)`: with target=340 and current 400 → 381. Not 340. So not matching.

Unless the harness pointer is directly setting paddle via something. OR my reading: paddle=340 at frame0 means body.x already 340 at frame0 (before any update). Initial paddle body.x = 400 (create sets rectangle at WIDTH/2=400). So frame0 should be 400 unless update already ran once. The reload log might capture after one update already happened.

This is too deep. The important thing: **the loop runs** (frames logging), ball rests on paddle (v=0), bricks=55, paddle within bounds. The paddle at 340 is within [60,740]. Good.

Hmm, but paddle=340 while pointer... The mouse follow moving paddle to pointer.x. That's fine — mouse works. Good, that actually confirms mouse control works (paddle moved toward pointer). 

But there's a 1-frame desync between ball.body.x and ball GameObject.x. That's just a visual/log timing thing, not a bug affecting gameplay. Actually, it could matter: in LAUNCH I set ball.body.x = paddle.body.x every frame. The GameObject syncs after step. So the visible ball follows paddle with 1-frame lag — negligible.

Wait, but there's a concern: the ball's body.x is set to paddle.body.x, but the ball GameObject x (used for collisions and onPaddleHit diff) lags by 1 frame. For paddle collision that's fine.

Now, let me actually test the full flow: launch (space), see ball move (v nonzero), bounce off top/walls, hit bricks (score increments, bricks decrease), and fall/life lost. Let me press Space then motion then inspect.

But time is short (5 min left). Let me be efficient: 
1. Press Space to launch.
2. motion ~4s to let ball bounce and hit bricks.
3. inspect console to see LAUNCHED, BRICK HIT, possibly BALL LOST.

Then I'll remove debug logs and finalize.

Actually, since mouse control already moved the paddle (340), pressing Space in LAUNCH launches. Let me do key space then motion then inspect.

Let me be careful: the key action — does Space register to the iframe? The harness key action should send to the active iframe. Let me try.

Let me do: key(space), then motion(4), then inspect. But I can only do one action at a time and inspect returns console. Let me do key then motion then inspect.

Actually, to save time, let me do key(space) + motion(4) in sequence, then inspect.

Now I see:
- The key(space) action ran MANY frames (the harness ran the loop for ~57 frames during this key action, ~1 second). So the loop runs during actions and is throttled in real-time but the key action seems to have advanced ~1s of simulation (57 frames at 60fps ≈ 0.95s). Actually it seems the key action itself ran the simulation for ~1 second (57 frames). Interesting — so each "key" / action runs the game for a short real-time duration. 

- The Space launched at frame 56: "LAUNCHED vx=-126 vy=-320 speed=320". Good, launch works.
- At frame 57: ball=(352,529) v=(-126,-320) bricks=55 state=playing. 

So the ball was launched but only 1 frame after launch in this capture. I need more frames to see bounces and brick hits. Let me run a motion action to advance more time so the ball bounces off top, hits bricks, etc.

The key action advanced ~56 frames (~1s). A motion action probably advances more. Let me do motion(3s) then inspect to capture brick hits and bounces.

But wait, the ball at frame 57 is at y=529 moving vy=-320 (up). It will rise to top (y~12), bounce, come down, hit bricks at y~58+. With 55 bricks in 5 rows, the ball traveling from y=529 upward to y=12 then back down 600 pixels at 320px/s ≈ 1.9s round trip. Plus horizontal. In 3 seconds it should hit several bricks. Let me run motion(4) and inspect.

Actually the previous key action took ~1s of sim and we saw launch at the end. Let me now do motion(3) and inspect. That gives ~2-3s more sim after launch → ball should bounce off top and start hitting bricks, hopefully a few BRICK HIT logs.

Let me do motion(3) then inspect.

Actually, I realize the "key" action might run the sim only briefly and the motion action captures frames for `delta` seconds. Let me just call motion(3) and then inspect.

Let me do motion with delta 3.

Hmm, this motion(4) returned the SAME console as before (the same log history from the previous key action), not new logs from the 4-second motion. The console appears to be the SAME list (up to frame 59 DBG). So the motion action didn't append new logs? That's odd.

Wait, the motion console is identical to the previous key's console (ends at frame 59 DBG state=playing ball=(346,513)...). So the motion(4) didn't produce additional console output beyond what was already there. That suggests the console returned is a snapshot of the iframe's console history at the moment the action is invoked, OR the motion action's console capture didn't include new logs.

Actually, it seems the console returned by `motion` and `inspect` and `key` all return the SAME growing list (the full history). After the key action, the console ended at "frame 59 DBG state=playing ball=(346,513)". The motion(4) console is identical — ending at the same point. So no new logs were emitted during motion(4)?? That can't be if motion runs 4 seconds of sim.

Unless... the motion action returns the console captured at the START (before running) — i.e., it snapshots console then runs frames and returns the snapshot taken before. That would explain why all actions show the console up to the point of invocation.

Hypothesis: The browser tool's returned "console" is the console state at the moment the action *begins* (or a snapshot taken early), not after. So to see logs from a motion, I'd need to inspect AFTER motion completes, via a separate `inspect` call.

In the key action, the console showed logs up to frame 57 (LAUNCHED) — that's because the key action ran the sim, advanced frames, and the console snapshot included those. So the key action DID capture logs during and after. Then motion(4) returned the same ending at frame 59 — meaning motion didn't add logs visible, OR motion's snapshot was taken at its start (which was frame 59's state).

Hmm, inconsistent. Let me think: 
- Key action result: console ended at frame 57/59 DBG (LAUNCHED at frame 56, then frame 57-59 playing). So the key action ran ~57 frames and the console includes logs up to the end of those frames.
- Motion(4) result: console ended at frame 59 DBG (same). So motion(4) apparently did NOT advance the sim / produce new logs, OR its console snapshot was taken at start (=frame 59 state, before any new frames).

If motion(4) had run 4 seconds (240 frames) of sim, we'd see frames 60-299 with ball bouncing and brick hits. We see only up to 59. So motion(4) did NOT run sim frames, OR the console snapshot is taken at start.

Possibility: `motion` captures frames for the given duration but the `console` returned is a snapshot from before the motion started. So to capture new logs, I must run motion THEN inspect (separate action). The inspect would then show logs up to the inspect moment, which includes motion's frames.

But earlier: key action then motion(6s) then... I didn't inspect after motion. The motion(6) console was the same as before (no new). So motion indeed doesn't update the console in its return.

Wait, but the key action DID show advancing frames (0→57). So key advanced sim AND its console showed it. So key returns post-action console. But motion returns pre-action console? Inconsistent tool behavior, or maybe key and motion both run sim and return console captured after, but motion(4) ran but the sim didn't log because... 

Actually, maybe the motion action's `console` array is capped at a certain length and truncated, so the NEWER logs (after the cap) replace... no, it ended at frame 59 (same as key's end). If motion ran 240 frames, the console would end at frame ~300. It ends at 59. So motion did NOT run frames (or didn't log).

Hmm, possibly `motion` records visual frames (screenshots) but does NOT advance the game's simulation clock / rAF — it might just capture the existing canvas state over time without running JS? But earlier motion also didn't log UPD. And the key action DID advance (57 frames). 

Wait — maybe the key action advances the sim because pressing a key requires JS focus, and in doing so the harness runs the loop. While motion just captures frames without running JS (paused loop)? But the loop ran frames 0-59 during the key action. The key action = send a keydown and then... the harness might run the iframe loop for ~1s. The motion action = capture frames without running the loop fully.

This is confusing and eating my limited time. Let me reconsider the harness behavior.

Actually, I think the key action runs the game loop for a brief period (because it interacts). The motion action captures rendered frames (the harness might run rAF to capture, OR just snapshot). The console returned by each action reflects the iframe's console at the time the harness captures the response.

Observation: key action returned console ending at frame 59 (LAUNCHED + a few playing frames). So after the key action, the sim had advanced to frame 59. The motion(4) returned console STILL ending at frame 59 — meaning motion did not advance the sim further (or did but console snapshot is stale). 

Given the inconsistency, the most reliable approach: do an action that advances sim, then a separate `inspect` to read the latest console. Let me try: motion(3) then inspect. If inspect returns logs beyond frame 59 (e.g., frames 60+, brick hits), then the loop ran during motion. Let me test.

Actually wait, time is very limited (maybe ~3 min left). Let me be strategic. I've already confirmed:
- Scene creates, loop runs.
- Ball rests on paddle (v=0, LAUNCH). ✓
- 55 bricks. ✓
- Paddle visible, follows mouse (340). ✓ (mouse control works)
- Space launches ball with upward velocity. ✓ launchBall works, state→playing.
- Ball moves after launch (v=(-126,-320), position updates). ✓
- Brick collision: NOT yet confirmed (bricks still 55 at frame 59, ball heading up).

I need to confirm: ball bounces off top wall, hits a brick (score+1, bricks 54), bounces off paddle, and falls below paddle → ball lost (lives 2). And restart.

Let me run motion(5) then inspect to capture those logs. If the sim advances during motion, I'll see brick hits.

Let me do motion(5) then immediately inspect.

Actually, let me reconsider: maybe the harness `motion` action DOES run the sim and returns the console at the END, but it returned the same console because... no.

Let me just try: motion(3), then inspect. See if console advances beyond frame 59.

Given time pressure, let me do it.

Actually, wait — I realize the key action advanced from frame 0 to 59 in a SINGLE action (it ran ~59 frames, ~1 sec). That's a lot for a "key press". So the harness, on EACH action, seems to run the iframe for about 1 second of real time (advancing ~60 frames), and returns the console accumulated during that second. 

- Reload action: runs ~3 frames, console shows up to frame 2 (the reload action's duration shorter?).
- key action: runs ~59 frames (~1s), console shows up to 59.
- motion(4): runs 4 seconds? But console shows up to 59 only — so motion did NOT run sim, just captured frames (no JS loop) OR the console cap.

Hmm, if motion(4) ran 4s of sim at 60fps = 240 frames, console would show frames up to ~300. It shows up to 59. So motion does NOT advance the JS loop. So motion only captures visual frames (rAF snapshots?) without running the game logic? That contradicts "motion frames".

But the reload and key actions DID run the loop. So what's different? Maybe key/relaod actions cause the iframe to be focused and the browser runs rAF; motion just records without focus? Unclear.

Practical plan: Use `key` actions (which advance the sim ~1s) repeatedly to advance time, then `inspect` to capture logs. Each key action advances ~1s. Let me press an innocuous key (like a no-op) or Space repeatedly? Pressing Space again: in PLAYING state, JustDown(space) does nothing (launchBall guards state===LAUNCH). So pressing space repeatedly is safe and advances sim ~1s each. But will pressing the same key again register as new JustDown? Each `key` action is a fresh press. Let me press space a few times to advance sim, then inspect.

Actually, pressing Space in PLAYING is harmless. Let me press space ~3 times to advance ~3s of sim, then inspect console to capture brick hits.

But each key action returns console already. Let me just do key(space) and see how far it advances, then key again, etc. Actually to capture the FINAL state, I'll do a final `inspect` after advancing.

Let me do: key(space) [advance ~1s, ball bounces off top reaches bricks], then inspect.

Wait, ball launched at frame 56 going up at 320px/s. Top of screen y~12 (ball center). From y=529 going up at 320px/s → reaches y=12 in ~1.6s (~96 frames). That's beyond the ~60 frames per action. So after 1 action (frame ~120), ball near top. After 2 actions (frame ~180), ball bounced off top coming down, entering brick field (y 58-168). It'd hit bricks. Let me do 2-3 key actions then inspect.

Hmm, but actually the bounce off top reverses vy to +320, ball descends through bricks. At y around 80-170 it hits the top brick row. Hit → brick destroyed, score+1. 

Let me advance with 2 space presses then inspect.

Actually, let me reconsider time. ~3-4 min left. Let me do: key(space), key(space), inspect. Each key advances ~1s. After 2 keys, ~2s+ elapsed since launch, ball should be descending into bricks. Let me go.

Actually, to maximize progress in one step, let me do a `motion` then `inspect` (in case motion does advance). But motion returned stale console before. Let me instead rely on key actions.

Let me do key(space) and observe.

Now I see:
- The ball advanced: frame 59 ball=(348,518) v=(-126,-320). Then two DBG logs show the ball moving up-left: (346,513)→(283,353)→(220,193). So the ball is rising and moving left (vx=-126). 
- ERROR: `brick.disableBody is not a function`. 

So the brick collider fired (ball hit a brick), calling onBrickHit which calls `brick.disableBody(true,true)` — but `brick` is a rectangle GameObject; `disableBody` is a method on GameObjects that have a physics body? Actually `GameObject.disableBody` IS a method added by Arcade via `EnableArmature`? Wait. In Phaser, the method is `sprite.disableBody(?)` from `Arcade` — actually the method is on the Scene/Physics, or it's `body.disabled = true`. The GameObject's `disableBody` — Phaser adds `setVelocity` etc via... Hmm.

Actually, the Arcade body methods like `disableBody` are part of the GameObject? Let me recall: `Phaser.GameObjects.Components` ... No. The method to disable a body is `this.physics.world.disable(body)` or set `body.enabled = false`. There's also `GameObject.disableBody`? Let me check. Actually Arcade sprites (image) have `body` and you can do `sprite.body.setEnabled(false)` or `sprite.body.destroy()`. There's a method `sprite.disableBody()`? I think `disableBody` is NOT on the GameObject. The correct approach: `brick.body.enable = false; brick.disableBody`? 

Hmm. Let me reconsider. In Phaser Arcade, to remove a body you can do `this.physics.world.disable(brick.body)` or `brick.body.destroy()`. Or to keep the object but remove body, `brick.body.enable = false`. 

But I'm using overlap/collider callback receiving the GameObject `brick` (rectangle). To remove the brick, I should `brick.destroy()` (removes GameObject and body). Or `brick.body.enable=false` + hide.

Wait, the error happened at the moment a brick was hit. So the ball DID hit a brick (collision works!), but the destroy call failed. Let me use `brick.destroy()` instead. But destroy mid-collide-callback — Arcade can handle destroying the GameObject; the body is removed. But `this.brickCount--` and score++ should still run. Let me restructure onBrickHit: increment score, decrement count, then destroy the brick.

Actually, the issue: `brick.disableBody` is not a function. Let me check if it's `brick.disableBody` vs `brick.body.disableBody` vs `this.physics.world.disable(brick.body)`.

In Phaser 3, the GameObject has a `body` property, and Arcade adds methods to the body. The world has `disableBody(gameObject)`? Hmm.

Let me grep phaser min for disableBody.

`world.disableBody` exists, and `this.disableBody` (a `this` context method) exists on Body? `this.disableBody` is the Body's method. Let me find the Body.prototype.disableBody signature.

So `Body.prototype.disableBody(t)` exists (removes from tree, sets enable=false). So `brick.body.disableBody(true)` should work. But I called `brick.disableBody(...)` on the GameObject, not the body. The error "brick.disableBody is not a function" — because the GameObject (rectangle) doesn't have disableBody. I need `brick.body.disableBody(true)` or use `brick.destroy()`.

Actually the cleanest is `brick.destroy()` — removes the GameObject and its body from the world, and from the group. Let me use destroy. But destroy within a collide callback — Arcade should handle removal safely (bodies destroyed are removed). Let me use destroy.

But wait, there's a nuance: I'm using a collider (not overlap) for bricks. The collide callback fires after the physics resolved. Destroying the brick there is fine. Many examples use overlap with destroy. Let me switch to overlap instead of collider for bricks, OR keep collider + destroy in callback. Collider + destroy should be okay.

Actually, using a collider means the ball bounces off bricks (good). The callback destroys the brick. Let me keep collider and change `brick.disableBody(true,true)` to `brick.destroy()`.

But careful: when the brick is destroyed, the group `this.bricks.getChildren()` should reflect removal → getLength decreases. And I track brickCount manually too. Good.

Wait, but does destroying the body mid-collide-callback cause issues for the current step's iteration? Arcade iterates a list of colliding pairs; removing one body during iteration could skip or error. In practice, destroy marks the body removed; Arcade's broadphase handles it. It's a common pattern though usually with overlap. To be safe, let me switch brick interaction to `overlap` and in the overlap callback destroy the brick AND ensure the ball bounces. But overlap doesn't separate/bounce. With overlap, the ball might pass through. Hmm.

Option: Use collider for bounce + do NOT destroy in the collide callback; instead mark a flag and destroy after the step. But simpler: use overlap; in callback, destroy brick + reverse ball velocity appropriately (simulate bounce). That's more code.

Alternatively, keep collider + destroy in callback. I believe Phaser handles destroying the game object in a collision callback — it's commonly done. The earlier error was just the wrong method name (disableBody on GameObject vs body). Let me change to `brick.body.disableBody(true)` (Body method) which is the proper way and safer than destroy mid-step (disables body without removing GameObject from tree... actually disableBody removes from tree). Hmm disableBody also removes from tree (this.remove). 

Actually, the cleanest and safe: don't destroy/disable in the callback; instead set a flag and process removals after the physics step. But simpler approaches work in practice.

Let me think about what's truly robust. Many Phaser breakout tutorials use:
```
this.physics.add.collider(ball, bricks, hitBrick, null, this);
function hitBrick(ball, brick){ brick.disableBody(true,true); ... }
```
But that's on Arcade Sprite (image) which has `disableBody`? Sprites created from image DO have `disableBody`? Actually, Arcade GameObjects get `disableBody`/`enableBody`? Let me check: the GameObject body is created, but `disableBody` as a method on the GameObject — Phaser's Arcade `Image`/`Sprite` GameObject: does it have disableBody? 

The grep showed `this.disableBody` — where is it defined? It might be a mixin on Arcade-enabled GameObjects (Image/Sprite/etc). But my brick is a `this.add.rectangle` (Rectangle shape, not an Arcade Sprite). Rectangle shape might NOT get the Arcade object methods. So `brick.disableBody` not found, but `brick.body.disableBody` exists. 

To be safe regardless of object type, use `brick.body.enable = false; brick.setVisible(false); brick.body.checkCollision.none = true;` — disable without removing. This avoids destroying during step. Then brickCount tracks removal. Win when brickCount<=0. The disabled bricks just sit invisible; fine. And they won't collide again (checkCollision.none, enable false). 

Actually `brick.body.enable = false` — setting body.enable false removes it from collision? In Arcade, body.enable false means it's not processed. Good. And checkCollision.none true. Let me set both.

But disabled bodies remain in the group; getChildren still lists them (but body.enable false). For win I use brickCount (manual). Good. So I don't rely on getLength.

But wait, I also use `this.bricks` in collider and restart `this.bricks.clear(true,true)` removes children. Good.

Let me change onBrickHit to:
```
onBrickHit(ball, brick){
  brick.body.enable = false;
  brick.body.checkCollision.none = true;
  brick.setVisible(false);
  this.brickCount--;
  this.score++;
  ...
}
```

Hmm, but a disabled static-like dynamic body with checkCollision.none might still be in overlap/collider lists but won't register. Fine.

Actually, even simpler and definitely works: `brick.destroy()`. Destroying a GameObject removes it from the scene and its body from physics world. Doing this inside a collider callback is supported (Phaser's collide handles destroyed objects). Let me use destroy — clean. But destroy during the collide callback: the body is removed from the body tree. Arcade's `processCallback`/callback happens after separation; destroying should be okay. I'm fairly confident destroy works (it's the most common pattern in overlap-based breakers). 

But there's a known caveat: destroying bodies during the physics step can cause "Cannot read property of undefined" if Arcade iterates over the bodies array while it's mutated. Phaser guards this. Common examples destroy in overlap callbacks. Let me use destroy.

Actually, to be safe from mid-step mutation, let me use overlap (not collider) for bricks, and in the overlap callback destroy the brick + manually reflect the ball. But manual reflection is extra code.

Alternatively, use collider for the bounce, and in the callback use `brick.body.enable=false; brick.setVisible(false)` (no destroy), relying on brickCount. This is the safest (no removal from arrays mid-step). Let me go with that.

Let me rewrite onBrickHit:
```
onBrickHit(ball, brick){
  if(!brick.body||brick.body.enable===false) return; // already hit
  brick.body.enable=false;
  brick.body.checkCollision.none=true;
  brick.setVisible(false);
  this.brickCount--;
  this.score++;
  this.scoreText.setText('SCORE:'+this.score);
  console.log('BRICK HIT score='+this.score+' bricks='+this.brickCount);
  if(this.brickCount<=0){ win }
}
```
The guard prevents double-counting if multiple contact frames. Good.

Now, with brick.body.enable=false, will the ball still register overlap/collide? The collider won't fire for disabled body. Good. So one hit per brick.

But there's the concern: the collider's separation/reflection uses the brick body for the normal. If I disable mid-callback, the current resolution already done. Next frames brick ignored. Good.

Let me also reconsider the paddleHit override and brick reflection. Currently bricks are dynamic immovable bounce1, ball bounce1. When ball hits brick, collider reflects ball. onBrickHit disables brick. Good. The reflection direction: ball hitting a brick's top edge reflects down; hitting side reflects sideways. Standard. Good.

Let me update the code. Also I should reduce the debug log spam (frame 0-59 logs every frame is noisy but okay for debugging; I'll trim to less before finalizing, or keep a light version). Since final should be clean, let me reduce UPD logs to every 30 frames, and keep BRICK/LAUNCHED/LOST/WIN events. Let me change the _f log back to modulo 30 but it floods earlier. Actually for final I'll keep a minimal console? The task doesn't require console logs; they're just for my verification. Let me keep event logs (LAUNCHED, BRICK HIT, BALL LOST, WIN) — useful for debugging and harmless. And remove the per-frame UPD spam (it floods console). Let me revert UPD to every-30-frames logging to light.

Actually, the per-frame logs (frame 0-59) are noisy and might slow things / flood. Let me make UPD log every 30 frames only, and BRICK/LAUNCHED/LOST/WIN logs remain. Let me edit.

Given time, let me make focused edits:
1. Fix onBrickHit brick removal (use body.enable=false + setVisible).
2. Reduce UPD spam to every 30 frames.

Then re-test: reload, launch, advance, confirm BRICK HIT logs appear and bricks decrement, ball bounces.

Let me also keep an eye on the win/restart flow but time is short.

Let me make the edits.

Now reduce UPD spam to every 30 frames. Let me edit the _f log block.

Now let me reload and verify the full flow: launch, bounce off top, hit brick (BRICK HIT + score +1, bricks 54), etc. Let me reload, then press space (launch), then advance time with more space presses, then inspect.

Actually reload resets the game (fresh). Then space launches. Then I need to advance ~1.5s for ball to reach top, then more to descend into bricks. Each key action advances ~1s. So: reload → key(space) [launch + ~1s rising, ball reaches top area ~ frame 96] → key(space) [~2s, ball descending, hits bricks] → inspect.

But the console from the last key action should show the BRICK HIT logs. Let me do reload, then key twice, then inspect.

Wait — but the previous run ended in an ERROR (disableBody) which may have corrupted the scene? The error was thrown in onBrickHit; the scene continues (Phaser catches errors in callbacks? Actually an error in a callback would propagate and might break the physics step). After the error, frames continued logging (DBG showed ball continuing to (283,353) etc.) — wait no, after the error the logs showed DBG frames advancing with the ball moving, so the scene continued. But the brick wasn't removed (enable still true). And subsequent brick hits would re-error. The scene kept running though.

Anyway, fresh reload will reset. Let me reload and test cleanly.

Let me reload, then key(space), then key(space) again (advance), then inspect.

Actually, to maximize chance of catching a brick hit in one go, let me do reload then a single key(space) — but that gives ~1s, ball reaches top (~y=193 at frame from earlier log it was at 220,193 then would continue to top ~frame 110). Need ~2s to hit bricks. So two key actions. Let me do reload → key → key → inspect.

But each key action returns its own console. The final inspect will show cumulative. Let me just do key, key, then inspect. The inspect console should show everything including BRICK HIT.

Let me go.

Launch happened (vx=125 vy=-320). Now the ball is rising. Let me advance ~2 more seconds to let it bounce off the top and hit bricks. Each key advances ~1s. Let me press space again (PLAYING, harmless) twice then inspect.

Actually, let me just do two key actions, then inspect.

Hmm, this second key action returned the SAME console (ending at LAUNCHED) — no new UPD logs. So this key action did NOT advance the sim (no new frames). That's strange — the first key advanced ~56 frames and showed LAUNCHED at the end. The second key returned identical console.

Wait, maybe the harness `key` action runs the sim only when there's a NEW key press effect, and pressing Space again (already pressed) does nothing? Or maybe the second key action's sim advance produced logs but the console snapshot is taken at the start?

Actually, the first key action's console ended at "LAUNCHED" + then frame 57-59 playing logs appeared in the LATER (third) action. Wait, let me recount.

Sequence of actions and consoles:
1. reload → console ends at frame 2 (or 3).
2. key(space) → console ends with "LAUNCHED vx=125 vy=-320" (this action advanced ~56 frames, launch at frame ~56). Wait, this key action's console showed CREATE DONE, frames 0-3, then LAUNCHED. It did NOT show frames 4-56 nor the playing frames. Hmm. Actually the first space-press key action (the one that showed "LAUNCHED vx=125") — its console ended at LAUNCHED, but earlier actions had shown frames up to 59 with playing state. 

Wait, I'm confusing myself. Let me re-trace:

- First `key(space)` after reload: returned console ending at "LAUNCHED vx=125 vy=-320 speed=320". Before that line were frames 0-3 and CREATE DONE. So this first key advanced... it launched (LAUNCHED logged) but the frames 4-59 weren't shown? Actually the console shows frame 0,1,2,3 then DBG (0.5s), then frame 30,31,...59? No — this last key action's console shows up to frame 3 then LAUNCHED. It does NOT show frames 30-59 or the playing DBG. 

Hmm wait, the last action's console (second key) shows: frame0,1,2,3, (warning x3), LAUNCHED. That's it — only the initial frames 0-3 then LAUNCHED. The earlier "first key" action (before I reloaded) showed frames up to 59. 

This is inconsistent. The console snapshots seem unstable / partial. The harness console capture is unreliable (it seems to return a partial or stale snapshot).

Given the unreliability and time pressure (~3 min left), let me make a decisive test: reload, then do a `motion` (which the harness describes as frames), then `inspect`. But motion didn't advance before. 

Actually, let me reconsider: maybe the harness console returned by each action is the console snapshot captured at the moment the action STARTS, not after. Evidence: 
- First key action: snapshot at start = frames 0-3 + CREATE DONE + launch? No, launch happened during the action. Hmm.

Actually the first key action showed "LAUNCHED" which happened during that action. So snapshot is at END.

Let me look at the LAST action (second key) returned: it shows frame 0,1,2,3 then LAUNCHED — but NO frames 30-59, NO playing DBG, NO BRICK HIT. This is a subset. It seems the console is truncated to the most recent N entries? The last action's console has ~12 entries; it's missing the middle frames 4-59.

I suspect the harness console capture returns only a window of recent logs, or dedupes. The WebGL "no longer repeat" and frame logs suggest logs are captured but possibly capped.

This is too unreliable to fully verify every brick hit via console. But I have strong evidence the mechanics work:
- Ball rests on paddle (frames 0-3, v=0, on paddle).
- Launch gives velocity, state→playing, ball moves (earlier we saw (348,518)→...→(283,353)→(220,193), rising left).
- Ball collides with a brick (we got the disableBody error AT the brick hit moment → proves brick collision registered).
- The fix (body.enable=false) should now work.

The main remaining uncertainty: does the brick actually get removed now and score increment. The error happened exactly at onBrickHit, so the handler ran (collision detected). With the fix, it won't error. I'm fairly confident.

Given time constraints, let me do ONE more verification: reload, launch (key), advance (key), inspect — and look specifically for "BRICK HIT" in the captured console. If the console capture is unreliable, I might not see it, but let me try once more, and importantly, check via inspect after.

Actually, let me reconsider the harness console. The `inspect` action might return the FULL current console history (not a snapshot). The `motion`/`key` actions return a console that may be a snapshot at response time. Let me just: reload, key(space), key(space), then `inspect`. The inspect should return the full current console including all logs since boot (the iframe persists). Let me try that and grep for BRICK HIT.

Let me go: reload, key, key, inspect.

Actually each action is separate; let me do key, key first (to advance), then inspect.

Hmm, but the first key advanced ~56 frames in one action earlier. Let me do reload → key(launch) → key(advance) → key(advance) → inspect. 3 advance keys after launch.

Let me be efficient: do key ×3 then inspect.

Actually, I worry the per-action sim advance is ~1s (60 frames). After launch, need: rise to top (~1.6s = ~96 frames), bounce, descend into bricks, hit. So ~2-3s = 2-3 key actions. Let me do 3 keys after launch then inspect.

But the console returned by `inspect` — will it be the full history? Let me just try and look for BRICK HIT / BALL LOST.

Given only ~2-3 min left, let me act decisively: reload, then key, key, key (advance), then inspect.

Launch happened (vx=-145 vy=-320). Now advance to let ball rise to top and hit bricks. Let me do a `motion` to advance several seconds (even if console capture is partial, the sim advances), then `inspect`.

Actually the key action advanced ~56 frames? No — this key action only showed up to LAUNCHED (frame ~56? It didn't show frames 30-56). The console is capped/truncated to recent entries. So I can't see frame progression, but the sim DID advance (ball launched at frame ~56, and now we're past it). 

Let me do motion(3) to advance ~3s, then inspect to capture full console. The inspect returns the full current console history; let me look for BRICK HIT / BALL LOST / WIN.

Let me advance with motion then inspect.

The motion(3) console is the same stale snapshot (ending at LAUNCHED). The motion action apparently does NOT advance the JS sim and returns a stale snapshot. The `inspect` action should return the live console. Let me call inspect now — it should reflect the current state after motion advanced time (if motion advanced) or not.

Actually, given the harness behavior is murky, let me just inspect now to get the live console. If motion advanced the sim, inspect will show brick hits.

The inspect returns the same stale console ending at LAUNCHED. So the motion action did NOT advance the JS sim (no new frames, no brick hits). And inspect doesn't add anything.

Hmm. So only `reload` and `key` actions advance the sim by ~1s; `motion` and `inspect` don't advance.

Wait, but the first `key(space)` after the very first reload advanced ~56 frames and showed playing frames. Then the later key actions showed only up to LAUNCHED. The difference: the first reload's key advanced the sim because... Actually let me reconsider: maybe each `key` action advances the sim by ~1 second of real running, BUT the console returned is truncated to the LAST ~15 log entries (a rolling window). The first key's console showed frames 0-3 and LAUNCHED (truncated, missing 4-56). The earlier first reload+key (before fixes) showed up to frame 59 + DBG — that was a different scenario where more frames were captured because... hmm.

Actually, I bet the harness console returned is a capped rolling buffer (last N entries). When many UPD frames log (every frame), the buffer fills with UPD frames and the BRICK HIT / later events get pushed out or appear. But now UPD logs every 30 frames (less), so the buffer has room and shows LAUNCHED.

The key insight: I need to ADVANCE the sim enough for brick hits, and the console buffer (last N) would then show the latest logs (BRICK HIT, etc.) if they're recent. After launching, the ball needs ~2-3s to hit bricks. So I need 2-3 key actions to advance ~2-3s, and then the LAST key action's console (rolling buffer of recent logs) would show BRICK HIT.

But my last two key actions were after launch: I did key(space) [advance ~1s, launch], key(space) [advance ~1s? but console showed same LAUNCHED...]. Hmm, the second key after launch returned identical console (LAUNCHED only). Did it advance? If it advanced 1s, the ball would be at top (y~12) and the rolling buffer would show an UPD frame near the top, not LAUNCHED. But it showed LAUNCHED at the end. So either it didn't advance, or the rolling buffer kept LAUNCHED as the most recent (impossible if 60 new UPD logs came after).

Wait — the UPD log fires every 30 frames. In 1s (60 frames), UPD logs at frame 30 (and 0). That's 2 UPD logs per second now. So after 1s advance, console would show "UPD frame=30 state=playing..." as the latest, not LAUNCHED. But it showed LAUNCHED as latest. So the second key did NOT advance the sim.

So pressing space again does NOT advance the sim. Only the FIRST interaction (or the act of pressing a key that the harness treats as "focused") advances. Hmm. Or the sim only advances during `reload` and the first `key`, not subsequent identical keys.

This is really inconsistent. The harness's behavior is hard to control, and I'm burning time.

Let me step back and think about what I've verified:
✓ Scene creates and runs (loop ticks).
✓ Ball rests on paddle in LAUNCH state (v=0, position on paddle).
✓ 55 bricks laid out (5 rows × 11).
✓ Paddle present, mouse-follow moves it; keyboard would work.
✓ Space launches ball (sets upward velocity, state→playing).
✓ Ball moves after launch (position changes, velocity preserved).
✓ Ball collides with bricks — PROVEN by the earlier `brick.disableBody is not a function` error which was thrown inside onBrickHit, meaning the brick collider callback fired. So brick→ball collision and the hit handler execute.
✓ Bounce off walls: the ball rose upward and will bounce off top (collideWorldBounds). I saw it rising.
✓ Lives=3 initial.

What's NOT directly verified due to console capture issues:
- Score increments / brick visually removed (the disableBody error interrupted; with the fix it should work but I haven't captured a clean BRICK HIT log).
- Ball bouncing off paddle (onPaddleHit override).
- Ball falling below paddle → life lost.
- Win / Game Over / Restart.

Given time (~1-2 min left), let me do a focused verification of the brick hit fix: reload, launch, advance enough to hit a brick, and inspect for "BRICK HIT" (the new log). The trouble is advancing sim reliably.

Let me try: reload (advances ~3 frames), then key(space) — first key advanced a full ~56 frames and launched. Wait, in the latest reload→key sequence: reload showed frames 0-3, then key(space) showed LAUNCHED (so it advanced ~56 frames to launch). So the FIRST key after a reload advances ~1s and launches. Then to get brick hits I need ~2 more seconds AFTER launch. But the second key didn't advance.

Maybe the issue: after launch, the sim is "playing" and the harness only advances sim while the scene is "idle"? No.

Let me try a different advance mechanism: press an arrow key (keyboard) — maybe keyboard actions advance the sim. Or press space twice rapidly. Or use `drag` (mouse) which might advance sim while dragging.

Actually, the `drag` action moves the pointer → generates pointermove → mouseStarted=true → paddle follows. During drag, the harness presumably runs the sim. Let me try a drag to advance time and simultaneously move the paddle (testing mouse control + advancing physics). Then inspect.

Let me do: reload, key(space) to launch, then drag from paddle area horizontally (advances sim + moves paddle), then inspect for BRICK HIT and paddle movement.

But I only have ~1-2 min. Let me try one combined: reload, launch (key), drag (advance+paddle), inspect.

Actually, the earlier reload+key advanced ~56 frames and launched. If I then do a `drag` action, it likely advances the sim (drag runs over time). Let me do key(space) then drag then inspect.

Let me try.

Actually, let me reconsider time. The user said "At most 15 minutes. [now ~10 min elapsed, ~5 min remain]". Then "10 minutes have elapsed. At most 5 minutes remain." So I have ~5 min. Let me use it wisely.

Let me do: reload → key(space) [launch] → drag [advance ~1-2s + move paddle] → inspect.

The drag action: `drag` with x,y,toX,toY,delta. It simulates a pointer drag over delta time. This should advance the sim. Let me drag horizontally across the playfield for ~2 seconds.

Let me set toX across. e.g., from x=400 y=560 to x=700 y=560, delta... what's delta? The drag delta param — probably duration in ms or seconds. Let me use delta=2000 (ms) or just a number. Risky. Let me try delta=2 (seconds) like motion.

Actually, I'll just try drag and inspect.

Let me proceed: reload, key, drag, inspect.

Launch done. Now do a drag to advance the sim and move the paddle. Let me drag from near the paddle (x=340,y=550) to x=700, over a duration. The drag params: x,y (start), toX,toY (end), delta (duration?). Let me set start at x=340 y=550, end x=100 y=550 (move left), delta maybe 2000 (ms). Actually I'm not sure what delta unit is. Let me try delta=2 (seconds) consistent with motion. Actually motion delta seemed to be seconds but didn't advance sim. Drag might behave like key (advance sim). Let me try drag with toX varying to move paddle and advance.

Let me drag leftwards from 340 to 80 (delta 2). During drag, sim advances and paddle follows mouse. Then inspect for BRICK HIT and paddle movement.

Actually, to maximize chance of brick hits, the ball needs to travel up and back down. A 2-3s drag should suffice. Let me drag from (340,550) to (100,550) over delta 3.

Hmm, but I'm unsure delta unit. Let me try delta=3.

Let me do the drag then inspect.

Now the drag advanced the sim ~60 frames (~1s) and moved the paddle (paddle went from 340→159→60). So mouse control works (paddle follows pointer). 

The ball: frame 30 at (305,422) moving (-140,-320), frame 60 at (235,262) still moving (-140,-320) — so the ball has been going UP-LEFT and not yet hit any wall or brick (bricks=55 still, score=0). The ball is at y=262, still rising (vy=-320). Bricks start at y=58. So the ball is still above the bricks rising to the top. It hasn't reached the top yet (y going from 529→262 in ~1s; top is ~12; another ~0.8s to reach top). 

So I need more time. The drag advanced ~1s. Need ~1.5-2s more for ball to reach top, bounce, come down into bricks. Let me do another drag (or motion) to advance.

But motion didn't advance before; drag did. Let me do another drag. But dragging again — the pointer stays. Let me drag a bit more, e.g., from current paddle pos to right side, delta 2. Then inspect.

Actually, each drag seems to advance ~1s. Let me do 2 more drags then inspect.

Let me drag from (60,550) to (500,550) delta 2, then another, then inspect.

Actually, let me reconsider: maybe `inspect` doesn't advance but returns the current console. After a drag that advances sim and logs BRICK HIT, the rolling console buffer (last N) would show BRICK HIT if recent. The buffer seems to keep last ~12-14 entries. After more dragging with brick hits, the latest entries would be BRICK HIT / UPD near bricks. Let me do a few drags.

Let me do drag (right), then inspect.

Time check: must finalize soon. Let me do 2 more drags then inspect.

Now I see BRICK HIT logs:
- "BRICK HIT -> score=1 bricks=54"
- "BRICK HIT -> score=2 bricks=53"
- Then DBG: ball=(180,190) v=(0,0) score=2 — wait, the ball velocity became (0,0)?! After hitting 2 bricks, the ball velocity shows 0,0. That's a bug! The ball stopped moving after hitting bricks.

Why would the ball stop? The brick collider reflects the ball. But after the brick hits, v=(0,0). Hmm. 

Possible cause: The ball hit bricks but the reflection left velocity 0? Or collision resolution with multiple bricks caused the velocity to be zeroed.

Actually, look: at frame 90, ball=(180,190) v=(0,0). The ball traveled from (235,262) to (180,190) — diagonal up-left, then stopped at (180,190). It hit 2 bricks (score 2). After hitting them, velocity became 0. 

This suggests the brick collision reflected the ball, but then something zeroed the velocity. 

Possible: The onBrickHit disables the brick body (enable=false). But the ball's velocity zeroed too. Why?

Hmm. Actually maybe the ball hit TWO bricks in the same frame, and the multi-collision resolution with immovable dynamic bricks resulted in velocity cancellation. When a ball hits a corner shared by two bricks, Arcade resolves both collisions; with the reflection math, hitting two perpendicular walls could cancel velocity (e.g., vx and vy both reversed/nulled). 

Actually a known Arcade issue: when a body collides with multiple objects simultaneously, the velocity can be zeroed because each collision resolves based on the (possibly already-modified) velocity, and with immovable + bounce 1, hitting two bricks at a corner can result in v=(0,0) (the reflections cancel). This is the classic "ball gets stuck" problem.

Specifically: ball moving up-left hits a brick. Reflection reverses vy (up→down) and/or vx. If it hits two bricks (one on left, one above) in the same step, the resolver might reverse vx from one and vy from another... Actually with immovable bodies and bounce, Arcade's `separate` computes new velocity. For a dynamic body hitting immovable, the dynamic body gets reflected. If two immovable collisions happen in one step, the second operates on the post-first velocity. Depending on normals, the final velocity could be near zero.

Actually more likely: the ball hit a brick and the reflection was computed, but then the ball is also colliding with the paddle? No, paddle is at y=550.

Wait, the ball at (180,190) v=0 — it stopped in mid-air above the bricks. So the collisions zeroed it. This is a real bug to fix.

The root cause: when the ball hits a brick, Arcade uses the brick (immovable) to reflect. With bounce=1 on both and immovable, the reflection should reverse the normal component. But hitting the corner of two bricks simultaneously can zero the velocity.

Common fix: Instead of relying on Arcade's automatic reflection for bricks, use an `overlap` (not collider) for bricks, and manually reflect the ball's velocity based on the collision normal. This gives controlled reflection and avoids the cancelation.

Alternatively, reduce brick count or ensure bricks are spaced so the ball doesn't hit corners. But corners are common.

Better approach: Use overlap for bricks; in the callback, determine which side was hit (by comparing positions) and flip vx or vy accordingly, then destroy the brick. This is the standard breakout approach and avoids Arcade's multi-collision cancellation.

Let me rewrite brick interaction:
- `this.physics.add.overlap(this.ball, this.bricks, this.onBrickHit, null, this);`
- In onBrickHit(ball, brick): 
  - disable/destroy brick, score++.
  - Reflect ball: determine if hit was more vertical or horizontal based on ball center vs brick center, and flip the appropriate velocity component. 
  - Simple: compare ball.x vs brick.x; if horizontal distance > vertical distance, flip vx; else flip vy. 
  - Ensure vy stays (don't zero). Set a minimum speed.

But with overlap, the bricks must NOT be colliders (else double). I'll remove the brick collider. The ball won't auto-bounce off bricks; my overlap callback handles reflection. Good.

But there's a subtlety: overlap callbacks fire when bodies intersect. The ball overlaps a brick → callback. I reflect and remove brick. But the ball might be deep inside the brick; I should also separate slightly. Reflection alone may cause it to stay overlapping next frame? After removing the brick, no further overlap. Fine.

But if the ball overlaps a brick but I don't separate, the ball might tunnel. For a small ball and thin bricks, reflection + brick removal is enough.

Let me implement onBrickHit to:
```
onBrickHit(ball, brick){
  if(!brick.body||!brick.body.enable||brick.body.enable===false) return;
  brick.body.enable=false; brick.body.checkCollision.none=true; brick.setVisible(false);
  this.brickCount--; this.score++; this.scoreText.setText('SCORE: '+this.score);
  console.log('BRICK HIT...');
  // reflect based on impact side
  const dx = ball.x - brick.x;
  const dy = ball.y - brick.y;
  if (Math.abs(dx) > Math.abs(dy)) { ball.body.velocity.x = -ball.body.velocity.x; }
  else { ball.body.velocity.y = -ball.body.velocity.y; }
  // normalize speed
  const speed = Math.hypot(ball.body.velocity.x, ball.body.velocity.y) || this.ballSpeed;
  ... ensure non-zero
  if (this.brickCount<=0) win;
}
```

This avoids Arcade's multi-brick cancellation because I directly flip components. But if the ball overlaps MULTIPLE bricks in one physics step (two overlap callbacks), each flips a component — e.g., flip vx then flip vy → ball reverses fully (back the way it came). That could happen for corner hits. To mitigate, only reflect in the FIRST brick hit per frame: use a flag `this._ballReflectedThisFrame`. Set true after first reflection; reset at start of update or via a world step pre-event. 

Simpler: limit reflection per frame. Add `this._reflected=false` reset at the top of update? But overlap callbacks happen during the physics step which is after update. Hmm. Reset via `this.physics.world.on('preUpdate', ()=>{ this._reflected=false; })`. Actually world emits 'preUpdate' before step. Let me set a flag reset there. Or reset in update() (update runs before step): set this._reflected=false at top of update. Then overlap callback during step checks/sets. Good. But update runs once per frame before step; overlap callbacks in that step; flag reset next frame. Good.

Let me add `this._reflected=false;` at top of update (before the state checks? It should reset each frame regardless). Actually put it at the very top of update.

But careful: the bottom-sensor overlap and paddle collider also happen; _reflected only affects brick reflection. Fine.

Also, for bricks, I no longer want the automatic collider (which caused cancellation and double-handling). Switch brickCollider to overlap.

Also, the paddleHit currently runs as a collider callback and overrides velocity. With the paddle collider (collider ball-paddle), the ball reflects; then my onPaddleHit overrides with aim-based velocity. That should be fine. But does the paddle collider also suffer multi-collision cancellation? The paddle is a single body, so no corner double-hit. Fine. Keep paddle collider + onPaddleHit.

Actually, wait: the paddle collider with immovable paddle and ball bounce1 — the ball reflects. Then onPaddleHit overrides velocity (aim based). That's fine. But the reflection from Arcade for paddle might already be correct; my override is the aiming enhancement. Keep.

But there's a concern: the brick "v=0" bug. Let me also consider the ball hitting a brick and the paddle reflect — separate.

Let me also reconsider the ball hitting the TOP wall via collideWorldBounds — that reflects fine (single wall). Good. The v=0 issue was specifically multi-brick corner. The overlap+manual-flip+flag fix addresses it.

Let me also ensure speed isn't lost. After flipping a component, speed magnitude preserved (just flip sign of one component). Good. But the paddleHit override sets a new speed equal to max(ballSpeed, current). Good.

Hmm, also: after flipping via overlap, the ball might still be overlapping the brick (we disabled it, so no). Good.

One more: the overlap callback for bricks — overlap requires the bodies to actually intersect. Arcade overlap detects intersection and calls callback. Since bricks are dynamic immovable with checkCollision all true, overlap works. Good. But note: overlap also triggers separation? No, overlap doesn't separate; it just calls callback. Good, manual reflection handles direction.

But there's a catch: if the ball is moving fast and passes through a brick without overlap detection (tunneling) — at 320px/s and 60fps, 5.3px/frame, brick BH=22; won't tunnel. At higher speeds after paddle boost still fine.

Also, the ball might overlap a brick that's already disabled? I guard with `brick.body.enable===false` return. Good. But once disabled, does overlap still consider it? Disabled bodies are removed from broadphase? `body.enable=false` → Arcade skips disabled bodies in tests. So no. Good, but the guard is a safety.

Let me also reduce the chance of multi-brick hits by spacing, but the flag handles it.

Let me also reconsider: with overlap (not collider), when the ball approaches a brick, does it collide/separate before overlap? No — I removed the brick collider. Only paddle collider + world bounds bounce + brick overlap. The brick overlap callback flips velocity. But there's no collision separation, so if the ball is partially inside the brick at callback time, after flipping and the brick being removed, next frame the ball is outside. Fine. But what if two bricks overlap the ball and the flag prevents the second flip — the ball gets one flip, passes. Good. But the ball might be overlapping brick2 next frame and flip again. Fine.

Potential issue: the ball could get stuck bouncing between the top wall and a brick repeatedly, or oscillate. Unlikely with removal.

Let me implement the fix. Also reset _reflected each frame at top of update. But update returns early if WIN/GAME_OVER. That's fine (no bricks then). Actually if WIN, bricks all removed, no overlap. Fine. But to be safe set _reflected=false at very top of update before the early return. Let me add at top.

Hmm, but update early-returns for WIN/GAME_OVER. Setting _reflected false there is harmless. Let me put it first.

Let me now also reconsider whether the brick overlap + manual flip could leave the ball's velocity such that vy gets flipped to negative again incorrectly. The logic: if abs(dx)>abs(dy) flip vx else flip vy. For a ball coming down-right hitting a brick's top edge: dy (ball.y - brick.y) could be positive (ball below brick center) → abs(dy) larger? If ball hits top of brick, ball is below brick center → dy>0, and dy magnitude ~ brick height/2 = 11, dx small → abs(dy)>abs(dx) → flip vy (down→up). Correct! If ball hits brick's left/right side: dx large → flip vx. Correct. Good.

But what about the ball hitting a brick near its corner where both dx and dy are similar — picks one (the larger). Reasonable.

Edge: ball moving up-left hitting a brick's bottom edge (ball above brick center, dy negative): abs(dy) large → flip vy (up→down). Correct (ball was moving up into the brick's bottom). Good.

OK. Let me implement.

Also, I realize there might be ANOTHER cause of v=0: the brick collider's callback (onBrickHit) disabled the brick, but Arcade's separate step for that collider pair might have zeroed the ball's velocity when one body got disabled mid-step. Switching to overlap avoids the collider entirely. Good.

Let me make the edits:
1. In setupCollisions: replace brickCollider (collider) with overlap.
2. Rewrite onBrickHit to manual reflect + flag.
3. Add _reflected flag init and reset.

Let me edit.

Actually, the brickCollider variable is destroyed and recreated in setupCollisions (called on restart). Let me change the line to overlap and store as overlapRef (overlap returns a World? Actually add.overlap returns the Overlap callback? `this.physics.add.overlap` returns a `Overlap` object? In Phaser, add.overlap returns the Overlap object which has a `destroy` method. Let me store it. On restart, destroy and recreate.

Let me write the new setupCollisions and onBrickHit.

Also, I need to remove the now-unused `onBrickHit` reliance. Keep method name.

Let me also handle: when bricks are overlap (not collider), the ball passes through but I manually reflect. However, the ball also still collides with paddle (collider) and world bounds (bounce). Mixed: overlap for bricks, collider for paddle. That's fine.

Let me edit setupCollisions.

Now I need to reset `this._reflected = false` at the top of each frame's update (before the physics step). Update runs before the step. Let me add it at the top of update. But update early-returns for WIN/GAME_OVER; setting _reflected there is fine. Let me add at very top.

Also I should reset _reflected in resetBall / launchBall? It resets at top of update each frame anyway. Good.

Let me edit update top.

Now let me reload and test: launch, advance to hit bricks, confirm brick hit + reflection (velocity not zeroed). Let me reload, launch (key), then drag to advance and move paddle, inspect.

Let me reload first.

Launch (vx=166 vy=-320). Now advance with drags to let the ball rise, bounce off top, come down, hit bricks, and bounce off paddle. Let me do 2-3 drags of ~3s each. Then inspect. Let me do drag, drag, drag, then inspect.

Actually each drag advanced ~60 frames (~1s). I need the ball to: rise from y=530 to top (y~12) = 518px / 320px/s ≈ 1.6s. Then descend from top to bricks (y~58) = ~520px at 320 ≈ 1.6s. So ~3.2s to first brick hit. Then more for multiple. Let me do 3 drags (~3s) then inspect. Maybe 4 drags to be safe. Time is limited (~2 min). Let me do 3 drags then inspect; if no brick hit yet, one more.

Let me drag left-to-right across.