Brick breaker · step-5-preview

Phaser 3.x presumably. Let me write the game.

I'll build a self-contained index.html with Phaser 3, using Graphics-generated textures for brick, paddle, ball.

Plan: Phaser game in ARCADE physics. Playfield 800x600, with an HUD area. Let's do width 800, height 640. UI overlay in Phaser (text showing score, lives, controls) plus a Launch button.

Let me write it.

Phaser 3.80.1. Good.

Now write the game.

Design:
- Canvas 480x680? Let's do 520 wide, 640 tall playfield? Actually let's make it nice: game width 480, height 720? Standard brick-breaker: 480x640 with HUD overlay drawn in Phaser.

I'll structure:
- W = 480, H = 640
- HUD in Phaser text at top (y=8..40), bricks start at y=80.
- Playfield walls: ball collision with world bounds set to playfield area? World bounds is whole canvas. I'll set ball.collideWorldBounds = true with bounce 1 and set world bounds to the playfield region excluding HUD: physics.world.setBounds(0, 50, 480, 590). Ball falls below → collider callback with world bounds bottom event... Simpler: manually check if ball.y > H then lose life. With collideWorldBounds = true the ball can't go below. So set collideWorldBounds true, set bounds top=50 so HUD isn't hit, and listen for worldbounds event on bottom? No — need the ball to pass below. Alternative: set bounds (0,50,480,590) with collideWorldBounds on ball for left/right/top, but check bottom manually and deactivate bottom bound. Easiest: set collideWorldBounds = false and handle wall collisions manually in update (clamp x, flip velocity, clamp y top flip velocity, bottom = lose life). That gives full control and guarantees paddle/ball containment.

Manual physics approach:
- ball.setVelocity continues, update() checks bounds.
- Arcade physics body still used for velocity & bricks collider (worldboundary not needed).

Bricks: static group of rectangles with arcade overlap. Use physics overlap between ball and bricks, on hit determine bounce axis by comparing previous position / distances.

For brick bounce: use ball.prev position or check penetration on x vs y. Standard: compute overlapX = ball.width/2 + brick.width/2 - |dx|; same for y; if overlapX < overlapY → flip vx else flip vy. Then set ball position to just outside brick.

Also brick colors per row.

Mouse control: paddle.x follows pointer.x, clamped. Keyboard: cursors + A/D.

Ball resting on paddle: ball attached, moves with paddle; on launch, set velocity up with slight angle.

Launch button: draw an HTML button overlay below the canvas? Or a Phaser interactive zone. Simpler: an HTML button positioned under the canvas, styled. The task says "Space or a visible Launch control". I'll do an HTML button below the canvas, visible only when in launch state. Let's just always show it (disabled when not needed).

Score, lives displayed in Phaser text + maybe HTML. Keep everything in Phaser for consistency, plus HTML wrapper with title and instructions.

Let's also add game over / win overlay text with restart button (HTML) and R key.

Generate textures with Graphics:
- 'brick' per row color: create via graphics generateTexture.
- 'paddle': rounded rect 84x16, blue.
- 'ball': circle radius 8, white.

Let me write the code.

Details:
```
const W=480, H=640;
const PLAY_TOP = 56;
```

Paddle y = H - 40.

Ball radius 7.

Lives 3, score 0.

Win when bricks count = 0 (active). Restart.

Also add particles/trail? Keep simple but nice: add a subtle trail using a small graphics? Skip; add ball glow via a larger soft circle texture. I'll add a 'glow' texture with radial fade using canvas texture... Use graphics with alpha circles multiple times to generate texture — can do: draw several circles with decreasing alpha, then generateTexture. Graphics alpha works, generateTexture captures it. Good.

Let me write.

Structure of scene:
- preload: generate textures (no loading).
- create: HUD text, bricks, paddle, ball, input, restart overlay.
- update(time, delta): move paddle, ball launch state follow, move ball, wall collisions.

Manual ball movement: velocity in px/sec, arcade body velocity; update handles bounds.

For dt handling: use delta/1000 clamp.

Ball speed: 260 px/s, increase slightly on paddle hits up to max 420.

Paddle bounce: on overlap, set vy negative and vx based on offset from paddle center: angle = offset/(paddleWidth/2) * 60deg. Set velocity magnitude to current speed.

Lives lost: reset ball to launch state.

Win: stop ball, show overlay "YOU WIN", restart available.

Overlay: I'll do an HTML overlay div for win/gameover with restart button — but easier to keep within Phaser: draw a semi-transparent rect + text + make it interactive? Keyboard R restarts, and the HTML Launch/Restart button below canvas handles restart. I'll implement HTML control bar with "#launchBtn" that changes label to "Launch" / "Restart" depending on state, plus always also accepts R and Space.

Simplest: single button: id="actionBtn". Text: "Launch" when ball ready; "Restart" when gameOver/win; hidden otherwise? Keep it always functional.

I'll expose scene methods to window for the HTML button: window.__game state.

Let me code carefully.

Text HUD: score top-left, lives top-right, plus "BRICK BREAKER" title center? Put title small at top center.

Controls text at bottom under canvas in HTML (visible). Also mention Space/Launch.

Write index.html now.

Code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Brick Breaker</title>
<style>...</style>
</head>
<body>
<div id="wrap">
  <h1>Brick BREAKER</h1>
  <div id="game"></div>
  <div id="bar">
    <button id="actionBtn">Launch</button>
    <div id="hint">← / → or Mouse to move · Space to launch · R to restart</div>
  </div>
</div>
<script src="phaser.min.js"></script>
<script>...</script>
</body>
</html>
```

Phaser text-based HUD inside canvas: score, lives.

Now JS scene:

```js
const GAME_W=480, GAME_H=620, PLAY_TOP=58;
const PADDLE_W=84, PADDLE_H=14, BALL_R=7;
const BRICK_ROWS=6, BRICK_COLS=10, BRICK_W=40, BRICK_H=18, BRICK_GAP=4;
const BRICK_TOP=100, BRICK_LEFT=(GAME_W-(BRICK_COLS*(BRICK_W+BRICK_GAP)-BRICK_GAP))/2;
```
480 - (10*44 - 4)=480-436=44 → left = 22. Good.

Colors rows: ['#ff5b6e','#ff9f43','#ffd93d','#4ade80','#38bdf8','#a78bfa'].

Texture generation:
```js
function makeRect(key,w,h,color,radius){g=this.add.graphics(); g.fillStyle(color,1); if(radius){g.fillRoundedRect(0,0,w,h,radius)} else g.fillRect(0,0,w,h); g.generateTexture(key,w,h); g.destroy();}
```
Ball: white circle with glow texture 'ballGlow' radius 14 alpha 0.25.

Use images for paddle/bricks/ball with origin 0.5.

Physics: arcade, ball body circle set: ball.body.setCircle(BALL_R) — for image with width 16 need setSize/setCircle then offset. Easier: use this.add.circle(x,y,BALL_R,0xffffff) (a Shape GameObject with Arcade physics support) — setCircle body works: gameObject.body.setCircle(BALL_R). With setCircle(r), Phaser sets body size 2r x 2r and offset to center if the object is this size. Fine.

I'll use an Arc render circle for ball (fillColor white) — but "generate all graphics using Phaser Graphics or generated textures". Using this.add.circle is a Phaser Graphics-ish shape; still generated programmatically, no assets. To be safe, generate textures via Graphics for everything including the ball, and add as image. Then set body circle: ball.body.setCircle(BALL_R, 0, 0)? For an image of size 2R, body default setSize(2R,2R) so it's square-ish. A circle body gives better corner behavior. I'll do ball.body.setCircle(BALL_R).

Actually to avoid offset issues: after setCircle, set body.setOffset((frame.width-2*R)/2 ...) — frame width = 2R so offset 0. Fine since texture is exactly 2R x 2R circle.

Wall collision handling in update:
```
if(ball.x - BALL_R < 0){ball.x=BALL_R; ball.body.velocity.x*=-1;}
if(ball.x + BALL_R > GAME_W){...}
if(ball.y - BALL_R < PLAY_TOP){ball.y=PLAY_TOP+BALL_R; vy*=-1;}
if(ball.y > GAME_H + 20){loseLife()}
```
Also keep ball within left/right.

Brick collision: use physics.overlap(ball, bricks, hitBrick, null, this). Good — but with body-based overlap and manual velocity, works.

hitBrick(ball, brick): brick.destroy(); score += 10; play flash effect; determine axis:
```
const dx = ball.x - brick.x, dy = ball.y - brick.y;
const ox = (brick.displayWidth/2 + BALL_R) - Math.abs(dx);
const oy = (brick.displayHeight/2 + BALL_R) - Math.abs(dy);
if(ox < oy){ reflect x; push out } else { reflect y }
```
Careful: bricks are static? Use staticGroup for bricks: this.physics.add.staticGroup(). Overlap works with static bodies. Yes.

But overlapping with static bodies: the body won't move ball, and body.blocked not set. Use overlap callback + manual handling: reflect velocity and reposition ball outside brick. Since we destroy the brick, repositioning is fine.

Edge: multiple bricks hit same frame → using overlap callback for each; second brick destroyed too. Acceptable.

Also handle the wall-hit flash: this.tweens.add scale? Brick is destroyed... Add particle-ish: a small expanding fading rect. I'll do a quick tween of a 'spark' image.

Paddle collision: physics overlap or manual distance check. Manual is safer for precise control:
```
if(ball.body.velocity.y > 0 && ball.y + BALL_R >= paddle.y - PADDLE_H/2 && ball.y - BALL_R <= paddle.y + PADDLE_H/2 && Math.abs(ball.x - paddle.x) <= PADDLE_W/2 + BALL_R)
```
then bounce.

Launch state: `ballOnPaddle` true; ball.x = paddle.x; ball.y = paddle.y - PADDLE_H/2 - BALL_R - 1; velocity 0.

Space key or action button → launch: set velocity with angle upward: speed 280, angle = -90 + (rand-ish based on paddle motion). Use fixed -65°..? Let's use angle = Phaser.Math.Between(-60, 60) relative to up: vx = speed*sin(a), vy = -speed*cos(a).

Paddle movement: keyboard left/right sets paddle velocity via direct position change: paddle.x += dir * 0.42 * delta. Mouse: if pointer active within canvas, paddle.x = clamp(pointer.x). I'll support mouse move always (pointer.x updates on move). Use this.input.on('pointermove') to set targetX = pointer.x, and if pointer not over canvas ignore. Simply clamp pointer.x. But if pointer hasn't moved, pointer.x = 0 default. Use flag: on pointermove set mouseActive=true. Keyboard sets mouseActive=false.

Clamp paddle.x between PADDLE_W/2 and GAME_W - PADDLE_W/2.

Speed increase: on paddle hits, speed = min(speed*1.03, 460) and renormalize velocity.

HUD text update: score, lives. Also state text centered (e.g., "SPACE TO LAUNCH").

Win overlay: draw rect + text; button becomes Restart. implement restart() resetting.

Let's write it. Also handle keyboard R restart, Space to restart from game over.

I'll include a small "launch indicator" arrow? Keep simple.

Time to write file.

For the HUD in Phaser: fonts with monospace. Add background panel graphics.

Also add subtle grid/background using Graphics lines? Add a starry background with generated dots texture — nice but optional. I'll add a dark gradient-ish background via a generated texture with vertical gradient using canvas texture (Phaser CanvasTexture). That's programmatic, allowed. Simple: create canvas 1x620 gradient, use as texture stretched? Might complicate. I'll just use scene bg color and a few decorative graphics lines.

Let me write it now.

Action button label logic: function updateActionLabel(): if(ballOnPaddle && !gameOver && !won) "Launch"; else if gameOver/won "Restart"; else disabled "Launch".

Clicking action button: if win/gameOver → restart; else if ballOnPaddle → launch.

Write.

Concern: `game.events.once("ready", ...)` — textures must be generated in preload, not after. Safer: create textures in the scene's `preload` (or in `init`). Let me change: add preload: makeTextures(this) in the scene. Also `game.scene.getScene("main")` before start may fail. Let me restructure.

Also note that Phaser's "ready" event fires on the game after boot but scene preload happens during boot too. Better to use preload.

Also potential issue: `this.input.activePointer.isOver` when using FIT scaling — Phaser handles input scaling correctly.

Also canvas focus: keyboard input requires canvas focus — Phaser keyboard listens on window by default, so it's fine.

Another issue: physics body for ball — I manually move ball.x/y, and arcade updates the body position from the game object? Actually arcade syncs body from gameObject at preUpdate each frame, then applies velocity. Since I set velocity and then manually move, body will sync from the sprite position next frame. Velocity is integrated by the body during its update — but body.velocity update happens in the arcade world update which occurs before scene.update? Order: scene.update() runs after scene's updateList which includes... Actually Phaser's Scene update order: `sys.update` → preUpdate (scene), then `scene.update()` called, then physics world update happens in the scene's update? Let's recall: Arcade physics world is bound to the Scene's 'update' event? In Phaser 3, `ArcadePhysics` plugin: `world.update(time, delta)` is called from the scene's update event via `this.systems.events.on(SceneEvents.UPDATE, this.world.update, this.world)`. Scene's UPDATE event is emitted BEFORE scene.update() (the user callback) in SceneManager.update: `this.events.emit(Events.PRE_UPDATE...)`, then `scene.sys.events.emit(SceneEvents.UPDATE, time, delta)`, then `scene.update()`. Hmm, actually order in SceneManager.update:
1. processing = scene.sys.step(time, delta)
2. scene.sys.events.emit(PRE_UPDATE...)
Let me recall sys.step: emits PRE_UPDATE, UPDATE, then calls scene.update() — in Phaser 3, `Systems.step` does:
```
this.events.emit(SceneEvents.PRE_UPDATE, time, delta);
this.events.emit(SceneEvents.UPDATE, time, delta);
this.scene.update.call(this.scene, time, delta);
this.events.emit(SceneEvents.POST_UPDATE, ...);
```
So physics world.update happens BEFORE scene.update. That means the body integrates velocity and moves the body, then in scene.update I ALSO move ball.x manually using the velocity. Both are based on the same velocity, so double movement... Let's think: at physics update, body moves by v*dt and syncs sprite position (body.position → gameObject via body.updateFromGameObject? Actually the body moves the gameObject: `this.position.x + ...; this.gameObject.x = ...`). Then in my scene.update I compute ball.x += v.x*step, adding a second increment. That's double speed. And my wall clamps use velocity, then resetting position, but body position set.

Simplest fix: set body velocity to 0 and do all movement manually? Then arcade still works for overlap detection since overlap uses body positions synced with gameObject each physics step. If velocity is zero, the body won't move but position syncs from gameObject? In Arcade, `Body.update` → if velocity zero, it does `this.position.set(gameObject.x...)`? Actually Body.preUpdate syncs from the gameObject using `this.updateBounds()`/`this.resetFlags()`. In Body.preUpdate: it copies position from gameObject if `this.syncBounds`... Let me recall Body.preUpdate code:

```js
preUpdate(willStep, delta) {
  if (this.disable) return;
  ...
  if (this.transform.x !== this.gameObject.x ...) { this.transform.copyPosition... }
  this.position.x = this.transform.x - this.transform.scaleX * this.offset.x ...
```
Yes, Body.preUpdate does `this.transform.copyPosition(this.gameObject)` etc, so position derives from gameObject. So if I keep velocity to 0 and manually set positions, the body follows and overlaps work. Velocity direction is tracked though—overlap check doesn't care about velocity. But I use v.x sign to decide... no, I use position-based logic. I only use velocity for direction/speed, which I manage.

Hmm, but "double movement" concern: I could instead rely entirely on arcade physics: keep velocity, don't manually move, and handle walls via triggers. That's more idiomatic but requires world bounds handling with the HUD band. I could set physics.world.setBounds(0, PLAY_TOP, GAME_W, GAME_H-PLAY_TOP) and set ball.collideWorldBounds = true, body.onWorldBounds = true, and listen for 'worldbounds' event to detect bottom hit → lose life. But bottom bound would be the playfield bottom (GAME_H), so the ball would bounce, not fall. I could instead set world bounds bottom to GAME_H + something and detect ball.y manually.

Given the double-integration risk, the cleanest: keep velocity vector in my own variables (this.vx, this.vy), set ball.body.velocity to (0,0), and manually integrate. Overlap detection still works via positions. That's deterministic and simple.

Wait — does Arcade overlap require body.enable and movement? `physics.add.overlap` checks bounding box intersection between bodies each world update, using body positions which are synced from gameObjects. Should work regardless of velocity.

Actually, one subtlety: Body.preUpdate only syncs from gameObject if `this.dirty`? Let's check Phaser 3.80 Body.preUpdate:

```js
preUpdate: function (willStep, delta) {
    if (this.disable) { return; }
    if (this.willStep) ... 
    this.resetFlags();
    var sprite = this.transform;
    ...
    var dx = sprite.x - sprite.prevPosition.x ...  // no
```
Hmm, actually I recall:
```js
preUpdate: function (willStep, delta)
{
    ...
    this.updateBounds();   // no
```
Let me just check the source in phaser.min.js for the body preUpdate to be sure. Easier: just test empirically in the browser with console logs.

Alternative safest approach: do movement via velocity (arcade integrated) and don't manually move the sprite. Handle walls manually by reading ball position and flipping velocity — that works exactly like the double-movement case minus duplication. Specifically:

update():
- paddle move (manual position change, body.reset)
- read ball.body.velocity, check bounds and flip; paddle bounce check; bottom check.
- no manual ball movement.

That relies on arcade integrating velocity, which is standard and correct. Overlap with bricks handled by arcade too. This is the most idiomatic and avoids the sync question entirely. The only concern is that body integrates with `useDelta` — arcade world by default uses delta (fixed? `fps: 60`, `timeScale`, and world.update uses delta). With variable delta the body moves velocity*delta/1000, matching my expectations.

Let me switch to that approach: remove manual integration, keep velocity-based. But wall bounce on left/right: flipping velocity.x works. On top: flip velocity.y.

One issue: ball speed increases over time (this.speed *= 1.035) but velocity magnitude is set at bounce events — fine.

Let me rewrite the update function accordingly, and change ball setCollideWorldBounds(false) (already).

Also there's a risk that after flipping velocity, the ball still overlaps the wall and gets stuck outside the world bounds — but collideWorldBounds=false means no clamping, so my manual clamp position is needed. With arcade integration, ball.x could go slightly beyond wall between flips? No—I check after integration each frame and reposition ball.x = BALL_R which is fine; body position derives from gameObject next preUpdate (Phaser Body does sync position from the gameObject: in Body.update, `this.position.x = ...` then at end it does `this.gameObject.x = this.position.x + ...`? Hmm, actually Arcade Body.update ends with:

```js
if (this.moves) { ... this.gameObject.x += ... }
```
Let me just look at the actual code to be sure about the direction of sync.

Minified names differ. Let's search for something like "syncBounds" or "position.copyPosition". Search for `updateFromGameObject` maybe named "updateFromGameObject".

Continue reading preUpdate to see the sync logic.

Confirmed: Body.preUpdate calls updateFromGameObject() each step (position derived from gameObject), then update integrates velocity into body position, and postUpdate applies the delta to the gameObject. So if I manually move the gameObject AND keep velocity, movement gets double-counted.

Decision: keep velocity as the source of truth and let arcade integrate; handle walls/paddle manually by reading position and modifying velocity + slightly correcting position (setting ball.x works because next preUpdate re-derives from gameObject). Setting ball.x directly after integration is fine — body will re-derive position from gameObject next step.

Note: `_dx` deltaMax could clamp... deltaMax is Infinity by default (set to Number.MAX_VALUE when size changes). Fine.

So remove manual integration and step. Also glide: glow position updates each frame in update() — fine.

Another concern: physics world's `fixedStep` default true with `fps: 60`? In Phaser 3.80, arcade world default: `fps: 60`, `fixedStep: true`, `timeScale`? With fixedStep true, it accumulates and steps in 1/60 increments, catching up. That means scene update may run multiple times per frame or physics may run in a loop. Doesn't matter since my checks happen per frame in scene.update, but with fixedStep the ball can move up to multiple steps between frames without my wall checks — with speed 285 px/s and 60fps, ~4.75 px per step, no tunneling through bricks (18px tall). Fine.

Actually careful: with fixedStep, the world update may run 0 or multiple times per rendered frame, meaning the ball could move more than expected between my checks, potentially tunneling the paddle (paddle height 14, ball 14 diameter, movement ~5px). Fine.

Now let me also verify: in movePaddle I call this.paddle.body.reset(x, PADDLE_Y) each frame — body.reset sets position and velocity zero, and stops. That's fine but resets body.prev; with immovable and staticGroup? Paddle is dynamic image with immovable. body.reset teleports; ok.

Actually simpler: just set paddle.x and let preUpdate sync. But body.position derived from gameObject in preUpdate anyway (updateFromGameObject), so setting paddle.x is sufficient. Keep body.reset for safety? body.reset sets gameObject.x/y too, which would override the clamp... I clamp before. Fine. Actually body.reset also sets velocity 0 and `this.position.set`. Keep it.

Hmm but one issue: body.reset moves the gameObject to paddle.x — same value. Fine.

Now also `this.input.activePointer.isOver` — after pointer leaves canvas isOver false, so paddle stays. Good. But with FIT scale, pointer.x is in game coords. Good.

Now the texture generation: I must move it into preload. Let me restructure the scene with a `preload` that generates textures. `scene.make.graphics({add:false})` works in preload.

Let's edit the file.

Also paddle tween scaling: paddle is scaled via tween — with body reset each frame, body position clamps. Fine. But the scale tween changes paddle's visual scale; body size updates via updateBounds on scale change (since _sx !== scaleX triggers width update). However PADDLE_W/2 constant used for collision math vs displayed width changes — during the 110ms flash, the collision box changes slightly. Minor. Actually ball bounce check uses PADDLE_W/2 while body may be 1.1× — harmless since it's overlap-based on the visual.

Hmm, one issue: paddle body — since I set body.reset each frame with a scaled gameObject, the body width recomputes. Fine.

Also brick hit: the ball may hit the brick side and bounce incorrectly with double-bricks; acceptable.

Now also: since I keep velocity and the ball's velocity magnitude stays as set, and physics has gravity 0 (set). Good.

Another issue: the ball body is a circle of radius BALL_R — setCircle(BALL_R) sets body width/height 2*BALL_R and offset... In Body.setCircle(radius, offsetX, offsetY) with no offsets: offset.x = (sourceWidth - 2*radius)/2 = 0 since texture is 14px. Good.

Now let's test in the browser. Let me check the browser tool availability.

Two issues:
1. `b.body.setAllowGravity is not a function` — for static bodies. Use `b.body.allowGravity = false` instead.
2. Canvas appears blank/black — probably because the error occurred during create after bricks were created... Actually the error is in buildBricks for the first brick → exception aborts create → nothing renders. Fix.

Also the game canvas seems to be a large square (aspect?). The scale mode FIT will fit within parent. It's showing 480x620 in a square-ish region... it's approximately square; whatever, it's the fit scaling within the div. Fine.

Fix setAllowGravity.

Looks great. The canvas is letterboxed inside a square due to FIT scaling within the div — the canvas width 480 height 620 should fit; the container is 480-ish wide? The div `#game` is inline-block, so it should shrink to canvas size. But the screenshot shows the game area square (about 560x560?). Actually Phaser FIT scales to fit the parent while preserving aspect ratio; the canvas element's CSS size gets set by FIT to fit the parent. The parent `#game` inline-block sizes to the canvas's original attribute size (480x620)... but the canvas CSS size is set by FIT which reads parent size. Chicken-and-egg — Phaser measures parent then sets canvas display size. The result here: the canvas rendered square-ish 560x560? The screenshot shows roughly 530x540 area including border. Hmm.

Actually Phaser's ScaleManager with FIT sets canvas.style.width/height based on parent bounds; since the parent inline-block wraps the canvas, its width depends on the canvas → circular. Phaser handles it, but the visual shows the playfield as square-ish, i.e., the aspect isn't 480:620 = 0.774. In the image, the bordered box looks ~530 wide × ~530 tall → aspect 1.0, meaning the canvas is square and the game content is centered with black bars top/bottom? Looking at the screenshot, the HUD is at the top of the black region and the paddle at the bottom — content fills the whole square. Hmm, but the visible game content looks vertically stretched: paddle near the bottom of a square area.

Wait, maybe the container gets its width from the page (max-width 520px of #wrap?). #wrap is a block with max-width 520 and padding 12 → content width ~496. #game is inline-block → shrink-to-fit... For a replaced element like canvas with intrinsic size, inline-block shrink-to-fit uses the canvas's used width. Phaser FIT might set style width to e.g. 100% of parent... 

Let me measure actual canvas CSS size via JS in the browser. I can use the browser's inspect action? Let me use `browser` inspect to evaluate? The inspect action shows DOM. Hmm, no JS eval tool apparently. I can use "type" in a JS console? Not available.

Alternative: use a screenshot measurement — hard.

Simplest fix: give #game an explicit width (e.g., 480px via style) or set scale mode to NONE and add a CSS max-width for responsiveness. Let me set explicit `#game { width: 480px; height: 620px; }`? But Phaser sets canvas style width/height in FIT mode which would override. Use Phaser.Scale.NONE and let CSS handle: `#game canvas { display:block; max-width:100%; height:auto; }`.

Actually the risk: with NONE, canvas is 480x620 with parentSize, mouse coordinates still map correctly (input uses canvas scale via... Phaser computes input scale from canvas bounds each frame, so CSS scaling is handled). Yes, Phaser handles CSS-scaled canvases for input via `ScaleManager.updateBounds`/`getCanvasPosition`. With NONE mode, `displaySize` is 1 but input coordinates use the canvas's bounding rect transform — I believe Phaser's InputManager uses `scaleMode` and `displayScale`. For NONE, displayScale = {x:1,y:1} computed from the parent size... Hmm, there's `ScaleManager.updateScale` that computes displayScale from the canvas bounds: in NONE mode, `getParentBounds` isn't used and `displayScale` set to 1? Let me look: In `updateScale`, for mode NONE, it sets `this.displaySize.setSize(width, height)` and canvas style width/height = gameSize * zoom... Then `displayScale.set(...)` = (canvasBounds.width / gameSize.width). Let me check the source for displayScale computation to be safe.

Simpler and safest: keep FIT but give #game a fixed pixel width matching aspect ratio, e.g. width:480px; height:620px? FIT will then scale the canvas to 480x620 = 1:1 (nothing to do). Actually Phaser FIT: parentSize = parent bounds (480x620 minus padding), canvas style size = fit within → exactly 480x620 if parent is exactly that. But if the parent is smaller (mobile), it scales down while preserving aspect. That's clean. So set #game { width: 480px; height: 620px; max-width: 100%; }? max-width could make the parent narrower than canvas and cause circularity again. Keep simple: fixed 480x620, and rely on the page scroll on small screens.

Hmm, but does FIT setting canvas style size conflict with parent shrink-to-fit? If parent is fixed 480x620, no circularity. Good.

Wait, but is the current rendering actually wrong? Let's verify by computing what's displayed: the outer bordered box in the screenshot is about 530px wide (based on layout width ~ 496 available?). Hard to tell precisely. The game canvas in the image: I see the playfield from HUD to paddle. If aspect ratio were distorted (stretched), we'd see stretched bricks. Bricks look reasonably proportioned... Actually with FIT + circular sizing, Phaser typically ends up with the canvas matching the parent width and height determined by the parent's own shrink-wrap: canvas sets style to width 100%? Hmm.

Let me just measure: use browser inspect to get the canvas element's computed size.

`displayScale` is computed from actual canvas bounds / baseSize, so input coordinates stay correct even with CSS scaling. 

Now let me measure the current rendered canvas size. I'll use a quick approach: use the browser's `inspect` action which gives DOM. Let's see if it reports sizes.

The DOM inspect doesn't give me element sizes. I can't run JS eval directly... but I can use the browser "type" action? That types into a focused element. Hmm. 

An alternative: the rendering looks proportionally fine — bricks look uniform, paddle looks right-sized relative to width. The vertical extent: from HUD to paddle. It looks plausible for 480x620 (aspect 0.77) — the playfield image area in the screenshot seems roughly 530 wide by 540 tall (square). Given the #wrap max-width 520 with padding, width ~496 → canvas should be ~496 wide × 640 tall, which would overflow the 800px viewport height and require scrolling... but the screenshot shows the whole thing including the button at the bottom, so it fits — meaning the canvas is NOT 496x640. The whole page content (title + game + button) fits in 800px height, so the game canvas is roughly 520 tall → width ≈ 400. Actually the box looks similar in width and height, ~530x530 in a 1200x800 viewport. Hmm, hard.

Anyway, the aspect ratio appears preserved (FIT) and undistorted. Since the playfield interior shows no distortion and the whole game is visible, that's acceptable. Let's just fix the sizing explicitly for a cleaner layout: set #game width/height explicitly to 480x620? That would make the page taller than 800 viewport (620 + title ~40 + button ~60 = 720 + margins → might fit). Fine either way.

Actually let's set a fixed-size container to avoid the circular shrink-wrap: `#game{width:480px;height:620px;}` and let Phaser FIT scale within. On the 1200x800 viewport this should render at 1:1. Let's do that and verify the game region is ~480x620.

Hmm, careful: if the container is fixed 480x620 and Phaser FIT's parent measurement returns 480x620, canvas style size = exactly 480x620 (no CSS scaling). 

Let me make that change, then test interactions: launch via keyboard Space, check physics, brick hits, score, paddle bounds.

To test keyboard, I can use browser key action — presumably it dispatches key events to the page. Let's try.

Now the game is 480x620 and the whole page still fits. Good.

Now test gameplay. Key presses: browser `key` action with text. Let's press Space. First I need canvas focus — the key action presumably sends to the page. Note the action button may have focus after clicking; I handle blur. Let's press space.

Nothing happened — the ball hasn't launched. Possibly the screenshot was taken at the same moment (frame +0ms) and the game didn't progress? The screenshots all say "Frame 1, +0ms" and show identical state. Maybe the game is paused? Perhaps motion happens but screenshots are captured immediately. Or the key event didn't reach the page.

Note: the ball on the paddle — it's not visible? The ball should be a white circle above the paddle. I see a small light-blue circle above the paddle in the image. Yes, it's there.

Let me try clicking the Launch button with the browser click action at its coordinates. The button is below the canvas, roughly at x=600, y=760? In the 1200x800 viewport: title ~y=30, game 620 tall from y≈65 to 685, button at y≈715. Center x=600.

But the action result shows only frame 1 and +0ms, suggesting no time advanced between reload and screenshot. Maybe the game loop isn't running in this environment because of the sandbox (requestAnimationFrame throttled?) but Phaser logged WebGL init so it's running.

Let's try click on the Launch button and then take a screenshot with motion.

The click registered (button appears pressed/darker) but the game state didn't change — the "PRESS SPACE OR CLICK LAUNCH" text is still shown, so launch didn't happen? The ball is still on the paddle.

Hmm. The click may have hit the button but `handleAction` → launchBall. Did launch fail? Possible issue: `actionBtn.disabled` was false, so click should fire. Unless... the game loop is not advancing at all (frames not running), and Phaser's scene update never runs so `sceneRef.handleAction()`... no, handleAction is called directly on click, synchronous. It should have launched.

Wait — maybe the click coordinates didn't hit the button; the button appears slightly darker which might just be the rendered :active state... Actually the button looks gray/darker in this screenshot, suggesting it was clicked (or hover/focus styling). Hmm, my CSS has button:disabled with grayscale(0.7) brightness(0.7) — the button appears gray in this screenshot while in the previous one it was cyan! So the button was DISABLED at the time of the click. That means `updateActionLabel` set disabled = true, which happens when not ballOnPaddle, not gameOver, not won... i.e., the ball was already launched?! But the ball is resting on the paddle visually.

Wait, or: the ball launched by the earlier Space keypress, the ball moved and fell (losing lives?) — no, LIVES still 3. Hmm.

Alternatively, `ballOnPaddle` false but ball didn't move? Let's think: after launching via Space, if the physics world isn't stepping (e.g., requestAnimationFrame throttled in this sandbox), the ball would stay at its position but ballOnPaddle=false → button disabled. And the ball's position: after launch, ball stays where it was (on the paddle) since nothing advances. That fits perfectly! The Space launch worked, but the render loop is frozen (frames not advancing — "+0ms" each time, identical screenshots).

But then, why is the game not stepping? Phaser's game loop uses requestAnimationFrame. In headless/screenshot environments rAF might not fire... but the earlier "motion" tool exists to sample frames. The console shows WebGL init though, which happens in boot (not loop dependent).

Let me check: take a "motion" reading to see if frames advance.

Actually let me first verify by pressing R (restart) — if the game loop is dead, the restart wouldn't reset the display (button would stay disabled). Actually resetGame → updateActionLabel sets button enabled, synchronous DOM change. So I can test loop liveness: press R; if the button turns cyan again → click handler/DOM works and the loop is dead.

Excellent! The game IS running (frames advance ~650ms each). The Space launch worked: score 10, one brick destroyed (bottom row, center: the brick in the left-ish middle of the bottom cyan row is gone), lives 2 (lost one life when the ball fell).

Interesting: only 2 frames rendered for ~2s. The game loop appears to run at ~1.5 fps in this environment (slow headless GL). That's an environment artifact (GPU stall ReadPixels). At 1.5 fps, delta is ~650ms, meaning physics steps with huge delta — with fixedStep the world catches up? With fps 60 fixedStep, world.update with 650ms delta would run ~39 steps in a loop, but `maxDeltaTime`/clamping... Actually Arcade World clamps delta to `deltaMax`? In 3.80: `world.update(time, delta)` — if `delta > maxDeltaTime` it uses... let me recall: 
```js
update: function (time, delta) {
  ...
  if (delta > this.maxDeltaTime) { delta = this.maxDeltaTime; }  // hmm was this removed in 3.60?
```
In Phaser 3.60+, `World.update` uses `this._elapsed` accumulation for fixedStep. There's a clamp: `this._elapsed += delta; if (this._elapsed > this._frameMaxMS) ...`. Something like that; regardless, the game works visibly.

Also important: my wall logic uses `Math.min(delta,32)`? No, I removed that. The movePaddle uses 0.42*delta which at 650ms = 273px per frame — too fast for keyboard movement, but in a real 60fps environment delta is 16ms → 6.7px/frame = ~400px/s. Reasonable. Maybe reduce paddle speed to ~420px/s equivalent... 0.42*16=6.7px/frame → 419 px/s. Good for 480 wide.

The concerning issue: at low fps, movement per frame is huge (ball jumps 285*0.65 = 185px per frame) → tunneling through bricks and possibly through the paddle. In a real browser at 60fps this is fine (~5px/frame). But to be safe against slow frames, I should clamp the delta for physics... but the physics is arcade-driven. I can set `physics.arcade.fps: 60, fixedStep: true` (default) which makes the world step in fixed increments — this prevents tunneling. Actually with fixedStep true, the world accumulates time and runs fixed 1/60 steps (multiple per frame if needed), so each step is only 1/60s of movement. That already protects against tunneling — as long as the accumulated delta isn't clamped to fewer steps. In Phaser 3.80 World.update:

```js
update (time, delta) {
    if (this.fixedStep) { this._elapsed += delta; ... while(this._elapsed >= this._frameTime) { ... this.step(this._frameTimeMS?) } }
```
Hmm. Let me check the actual code to be safe.

Also I noticed the ball is back on the paddle and state text shows again — expected after losing a life.

Also there's an issue: the paddle bounce check `ball.y + BALL_R >= top` etc. worked (lives lost as designed).

Also note the brick destroyed was the one at position (BRICK_LEFT + 5*(44) + 20, ...) — center bottom row, while the ball launched straight up (angle 0 → straight up). Yes: the missing brick is the 6th in the bottom row, exactly the center. 

Now, let me verify these behaviors in the actual environment more thoroughly since the effective fps is low:
1. Bricks get removed and score increases — verified (SCORE 10).
2. Ball bouncing off walls — need to observe.
3. Paddle staying inside playfield with keyboard/mouse.
4. Win/Game over overlay & restart.

Given the low fps, verifying the win state requires clearing 60 bricks, which takes many frames. Instead, I can test game-over by letting lives run out (3 balls falling = a few frames) — feasible.

But first, let me check the World.update fixedStep code to ensure robustness at low fps.

That was noisy. Let me instead search the Arcade World's update function by looking for `this.fixedStep` and `_frameTime`.

Good — with fixedStep (default true), when the delta is large, the world runs multiple fixed `step(1/60)` calls in a while loop. So even at ~650ms frames, the ball moves in 1/60 increments → no tunneling.

However, note: with a fixed-step loop, my scene `update()` wall checks only happen once per rendered frame (after all these substeps), so the ball could touch a wall during a substep and pass through — the wall checks happen only after. That could allow slight overshoot but the ball is bounded by the left/right/top checks after; a ball moving right at 285px/s moves 4.75px per substep, and with ~39 substeps per frame it could travel 185px before my check. If the ball is heading toward the right wall, it would be clamped back to the right edge with velocity flipped — visually the ball would "teleport" back from 185px beyond... i.e., it would appear to bounce off the wall but the wall bounce happens at most a frame late, so the ball can appear outside the wall for one frame (up to 185px outside). Hmm, that's the observed artifact? In the last screenshot the ball was on the paddle.

Also overlap collision with bricks: since I destroy bricks when overlapping and reposition the ball, multiple substeps are fine.

But the low-fps environment is a testing artifact only; on a real 60fps browser it's fine. Still, to make it robust, I could implement a substepped manual collision by doing wall checks per physics step. A cleaner approach: register my wall/bounds logic in a `world.on('worldstep')`-like hook: `this.physics.world.on(Phaser.Physics.Arcade.Events.WORLD_STEP, ...)`. Actually simpler: `this.physics.world.on('worldstep', ...)` — the event is emitted per step with delta. But the Arcade 'worldstep' event: `this.emit(d.WORLD_STEP, n)` — yes, per step (including substeps in the for loop? Let's check: in `update`, the fixed-step `a` branch emits WORLD_STEP once, and then `step()` calls also emit WORLD_STEP. Looking at `step`, it emits WORLD_STEP at the end. So per substep, WORLD_STEP is emitted. But careful: the ball body's own update happens in step() and then colliders update... Order inside step: bodies update (integrate), then colliders update (overlap/collide callbacks → my onBrickHit), then emit WORLD_STEP. So handling wall logic in the WORLD_STEP handler would happen right after integration & brick collisions. But brick collisions would then use the previous frame's wall state. Fine.

That's an improvement but adds complexity/risk. Given the environment is throttled to ~1.5fps mostly due to screenshot ReadPixels stalls (in a real browser it's 60fps), I'll keep it simple but add a modest safeguard: clamp the effective delta so the physics world doesn't run crazy many substeps? I can't control Phaser's delta.

Actually, a simpler and effective robustness improvement: handle wall collisions per WORLD_STEP event instead of per-frame. Let me implement it:

In create: `this.physics.world.on('worldstep', this.onPhysicsStep, this);` Hmm, Phaser.Physics.Arcade.Events.WORLD_STEP = 'worldstep'. The handler receives (delta) — actually emitted with (n) only.

In onPhysicsStep: do the wall bounce logic and the paddle bounce and the fall check. But careful: the paddle position is updated in scene.update() which runs once per frame — that's fine.

Risk: the fall check (losing a life) inside the step handler; and resetBall/setPosition inside the step loop → the loop continues stepping with the new (zero) velocity. Fine since velocity is 0 after reset.

Another risk: calling loseLife() → showOverlay → tween creation etc mid-step. Acceptable.

But also: stateText visibility etc. Fine.

Also: the ball position after walls is set (ball.x = ...). Then postUpdate applies delta to the gameObject based on body position changes. Hmm — postUpdate: `s.x += e` where e = position.x - prevFrame.x. Since I set ball.x directly (gameObject) after the body updated, the body position is NOT updated from the gameObject until the next preUpdate. Then postUpdate adds the body's delta to the gameObject position — the gameObject keeps its corrected position plus the small delta. That's OK.

Hmm wait, there's a subtlety: postUpdate adds `e` (the body's movement delta) to the game object position. But preUpdate already derived the body from the gameObject, so the total is consistent — this is the normal flow. When I override ball.x mid-frame, the next preUpdate picks up my corrected value. Fine.

But careful: I set `v.x = Math.abs(v.x)` where v = ball.body.velocity — modifying velocity during a step is fine.

One more consideration: doing this in 'worldstep' means the wall logic runs before the paddle/logic in scene.update — I'd move all ball logic into the step handler. Paddle movement stays in scene.update (once per frame). The ball bounce off the paddle then uses the paddle position from the previous frame — negligible.

Actually, there's a subtle problem: during the fixed-step `update()`, `preUpdate(a, n)` is called for all bodies BEFORE the steps, and `_elapsed` leftover handling... My clamp of ball.x in a step handler will be respected by the next step's preUpdate → updateFromGameObject. Good.

Let me restructure: move the wall/paddle/fall logic into `onPhysicsStep(delta)`. Keep scene.update for paddle movement and glow position.

Also I should double-check: does `this.physics.world.on('worldstep')` exist in 3.80? The Arcade Physics World extends EventEmitter and emits WORLD_STEP. Let me grep the Events constant for 'worldstep'.

Actually, WORLD_STEP is defined in the physics events as 'worldstep'. Let me verify.

Another consideration: `worldstep` is emitted even in non-fixedStep mode. Fine.

Let me check the event name.

'worldstep' confirmed. Let me restructure the ball logic to run per physics step. I'll refactor.

New structure:

```js
create: ...
  this.physics.world.on(Phaser.Physics.Arcade.Events.WORLD_STEP, this.onPhysicsStep, this);

onPhysicsStep: function () {
  if (!this.ball || this.ballOnPaddle || this.gameOver || this.won) return;
  var ball = this.ball, v = ball.body.velocity;
  ... walls, paddle bounce, fall check
}

update: function () {
  this.movePaddle(delta);
  if (this.ballOnPaddle) { stick ball to paddle; glow }
  this.glow.setPosition(this.ball.x, this.ball.y);
}
```

Note: when ballOnPaddle we must also zero velocity. Also when the ball is resting on the paddle, brick overlap isn't possible.

Fall check: `if (ball.y - BALL_R > GAME_H) { this.loseLife(); return; }`

Also careful: when loseLife resets the ball mid-step, the remaining substeps will move the ball with zero velocity — fine, but ballOnPaddle=true and the code returns early on subsequent steps this frame; then scene.update repositions it on the paddle. Good.

Let me implement.

Wait: `loseLife` sets the ball position via resetBall which calls `this.ball.body.setVelocity(0, 0)`. But we're inside the physics step loop; zero velocity means the remaining substeps don't move it. Good.

Also, `resetBall` sets `this.speed = Math.max(START_SPEED, this.speed * 0.9)` — resets speed each life. Fine.

Also `checkWin` — triggered from onBrickHit which runs during collider update inside step. Fine.

Now also the paddle scale tween: paddle.setScale during physics step; body updateBounds occurs on scale change — fine.

Potential issue: paddle.body.reset() in movePaddle happens once per frame; between substeps the paddle doesn't move. Fine.

Now, one more important issue: the ball's `body.setCircle(BALL_R)` means the body is 14x14 positioned at ball position with offset 0. Since ball.x is the center, body position = ball.x + offset - origin... For a body, position.x = gameObject.x + scaleX*(offset.x - displayOriginX). displayOrigin defaults to 0.5*width = 7. So position.x = ball.x - 7 = left edge of the circle body. Correct. And `ball.x - BALL_R < 0` → body left edge < 0. Correct. 

Wait, but displayOriginX — for `this.physics.add.image`, displayOrigin defaults to 0.5,0.5 → 7,7. So the body's top-left = (x-7, y-7). Good, my math is consistent.

Also brick bodies: staticGroup create at (x,y) with the image's center at x,y; static body position is computed with its own displayOrigin (7,9). Good — brick center matches.

Now, the paddle: `this.physics.add.image(..., 'paddle')` with displayOrigin 0.5 → body left edge at paddle.x - 42. My collision math uses PADDLE_W/2 from the center — consistent.

Now reload and test again. Let's reload and press Space, then take motion frames.

Good. Now launch with the Launch button click (button is enabled, so a click should work). Earlier the disabled button blocked it. Let me click Launch at approximately (600, 720).

Actually, since the button is now enabled, click it.

The click launched the ball (button now disabled, ball is above the paddle slightly). Now let me watch the motion frames to see bouncing behavior.

Excellent — bouncing works, bricks are destroyed (rows cleared in a diagonal-ish pattern), score increases 10 per brick. The ball also bounced off the right wall (frame 4 shows the ball on the right side moving left). 

Interesting: a brown/orange blob appears in frames 3 and 4 near the ball — that's the spark particle (tinted white circle scaling up and fading: at frame 3 it's dark orange/brown — the spark is tinted with the brick color). Wait, it looks brown (#ff9f43-ish) large — that's the spark tween scaling up. Fine.

Hmm, but the spark seems quite big (radius large) and brown-ish. The spark texture is a 20px white circle, tween scale to 2.6 → 52px. In frame 4 it appears huge (~60px) and dark. It's tinted with #ff9f43 = orange. Looks acceptable — like an explosion.

Also note the brick row heights: the ball cleared out the top rows and left a staircase shape — that's real gameplay over ~4 frames of slow-motion.

Now remaining checks:
1. Paddle stays inside the playfield — test by moving the mouse/pressing keys to the extreme.
2. Win state, Game Over, restart.

Also let me verify the "score" text isn't clipped by the tween scale (scoreText scale 1.18 - fine).

Also I noticed the ball in frame 2 is above the top wall row—fine.

Let me test the paddle: press ArrowRight for a while and check that the paddle doesn't exceed the right edge. In the current screenshot the paddle is at the center-bottom. Let me hold the right arrow. The `key` action with text "ArrowRight" probably dispatches a single keydown. If the game is at ~1.5fps, one frame with a 630ms delta moves the paddle 265px → it would hit the clamp. Let's do it and screenshot.

The paddle is at the bottom, flush against the left edge (x clamped at PADDLE_W/2 = 42). Wait — it moved left? I pressed ArrowRight but the paddle is at the far left... Let me look: the paddle appears at the bottom-left, and the ball is at mid-right. Hmm, that means the paddle moved left. Pressing "ArrowRight" should move right.

Hmm, maybe the key action typed text "ArrowRight" instead of dispatching a key event, so no key was registered, and the paddle moved left because of the mouse? The mouse hasn't moved... but pointermove may have been triggered by the earlier click at (600,720) — that's the Launch button, outside the canvas, so `pointermove` on canvas wouldn't fire.

Wait — the paddle could have moved left via the mouse due to the previous `click` action on the canvas? No clicks on the canvas happened.

Hmm, actually the ball is at mid-right, and the paddle at far-left — maybe the paddle got pushed left by a "pointer" event: when the browser tool clicks, the page might have received a pointermove at (600,720) which is outside the canvas → no canvas pointermove.

Let me reconsider: maybe the ArrowRight key DID register and the paddle moved right, but the... no, the paddle is clearly at the left.

Alternatively the paddle is at the left because the pointer's last position inside the canvas was x≈? The paddle is at x≈42 (left edge). If the pointer were at x≈42 in game coords... The click at (600,714) is on the button. Hmm, in canvas coordinates that would be y = 714 - canvasTop. If canvasTop ≈ 105, y = 609 (inside the canvas y range), x = 600 - canvasLeft. If canvasLeft ≈ 360 → 240 → center. Not left.

Wait — maybe the paddle moved left because of the mouse over the canvas... Actually I wonder: does Phaser's `input.activePointer` default position to (0,0) and my `mouseActive` flag false initially, so no movement? Then the paddle stays center until keys. But it's at the left...

Unless: `this.input.on("pointermove", ...)` — with a single keydown of ArrowRight and a huge delta (630ms), the paddle would jump right by 265px → clamped to 438 (right edge). The screenshot shows the paddle at the left. So the key moved it LEFT?! 

Hmm, could the key text "ArrowRight" have been typed as characters into the page, triggering... no.

Let me check the left part of the image: the paddle appears at around x=42 within the canvas (the canvas spans roughly x=360..840 in the screenshot). The paddle looks like it starts right at the inner border. So it's clamped at the LEFT.

What if the ArrowRight keypress was interpreted as 'keydown-ArrowRight'... and the keyboard plugin's `isDown` for cursors.right is true only during the frame; then in movePaddle: dir = +1 → paddle.x += ... → it should go right.

Unless `this.cursors.right.isDown` is false and `this.keyD.isDown`... no.

Wait! Maybe the mouse IS controlling: after the ArrowRight keypress, a `pointermove` event? No.

Hmm, what about `this.input.activePointer.isOver` — I check `this.mouseActive && this.input.activePointer.isOver`. mouseActive is set only by pointermove. Initially undefined → falsy. So no mouse control.

So how did the paddle end at the left? Unless... the left clamp: `Phaser.Math.Clamp(this.paddle.x, half, GAME_W - half)` — half = 42, GAME_W - half = 438. Fine.

OH WAIT. I see it: in `movePaddle` I call `this.paddle.body.reset(this.paddle.x, PADDLE_Y)`. But `body.reset` for a dynamic body... `Body.reset(x, y)` sets the body's position AND the gameObject position. That's fine.

Hmm, but what if the tween on the paddle `scale` was running... no, only on paddle hits.

Let me think about the ball position instead: the ball is at mid-right, and score jumped from 230 to 430 (20 bricks). The paddle at the left while the ball is on the right. 

Hypothesis: The browser `key` action sends a keydown for "ArrowRight"... but maybe it sends the literal string "ArrowRight" as separate keystrokes? If it sends keys "A", "r", "r", "o", "w"... then "a" would register on keyA → paddle left! And 'd'? no. Actually typing "ArrowRight" char by char: 'A','r','r','o','w','R','i','g','h','t'. The 'A' key → keyA isDown → move left. Also SPACE-like? no. And since delta is 630ms, moving left 265px → clamped to 42 = left edge! That explains the left paddle.

So the key action types characters rather than key events. That means Space earlier... hmm, earlier the Space keypress launched the ball (score went 0→10 and a life was lost) — if it typed the characters 'S','p','a','c','e', would that launch? No! But earlier the ball DID launch... Actually wait, in the very first test I pressed Space (text "Space") and nothing appeared to change in the screenshot, but then the click on the disabled button did nothing... Then the motion frames showed score 10, lives 2 — that happened between the click and the motion call, so either the Space keypress OR a "typed characters" event launched it.

Hmm, if "Space" is typed as characters, no launch. But we did observe a launch. Possibly the browser key action does support key names like "Space" and "ArrowRight". Then why did the paddle move left?

Let me test directly: press ArrowLeft and see if the paddle goes further left (it's already at the left edge, so no visible change). Better: check the paddle by pressing 'a' vs 'ArrowLeft'... 

Alternative test: mouse move. Let me try moving the mouse over the canvas to the left/right extremes and screenshot to confirm containment. Use the browser drag or click? There's no explicit mouse-move action. `click` with x,y presumably does pointerdown/up at that coordinate — does it also move the pointer? Probably yes (it moved/clicked). Let me click at the far right inside the canvas (e.g., x=830, y=400) and screenshot to see the paddle position. If the paddle goes to the right edge, mouse control works and containment is verified. Then click at the far left (x=375, y=400) to check the left clamp.

That would also interrupt gameplay (the click is inside the canvas — no button). Phaser handles pointerdown; my code only uses pointermove. A click also generates pointermove before pointerdown typically. Let's try.

Let me first screenshot the current state to get the paddle's x... Actually let's just do the clicks and observe.

The canvas: the game div is 480 wide + borders, centered in #wrap (max-width 520, page 1200 → centered at x=600). So the canvas spans roughly x=360..840 (including 2px borders), y from ~65 to ~685 (the title h1 above). In the screenshot, the game border box appears to start around x=355 and end around x=845. So the right interior ≈ 838, left interior ≈ 362.

Click at (838, 400) → paddle should clamp at right edge (game x=478 → screen ≈ 360+478 = 838). Let's do it.

Interesting: the click at (836,400) — inside the canvas — did NOT move the paddle (it stayed at the left edge), so a click doesn't produce a pointermove, or the pointer position only updates on move. Also a life was lost (LIVES 2, and the ball fell and the state text is back).

Hmm, the paddle stayed at the left. So the "a" hypothesis for ArrowRight seems wrong too... unless the click's pointermove isn't dispatched.

Wait, the paddle is at the far left and the ball fell below — the paddle didn't follow. So the paddle is stuck at the left. How did it get to the left in the first place?

Possibility: the first `key` action with text "ArrowRight" DID move it right... then a subsequent event moved it left? The only events were: reload, click (Launch button at 600,714 — outside canvas), motion, key ArrowRight, then this click (836,400 — inside canvas).

Hmm, what if pointermove events ARE dispatched with the click, and the pointer position in game coords at (836,400) is x = 836 - 360 = 476 → the paddle should be at the right edge. But it's at the left.

Alternatively, `this.input.activePointer.isOver` might be false, so the mouse ignore happens, and the paddle's position at the left came from... hmm.

Let me think about the earlier state: Before the ArrowRight keypress, the paddle was at the center (the motion frames showed a centered paddle at the bottom). After ArrowRight: left. So ArrowRight moved it LEFT by ~265px+ (clamped at the left edge, since the center is 240 and 240-265 = -25 → clamp 42). Yes! That's consistent with "a" being typed (or ArrowLeft somehow).

Wait — maybe the browser key action interprets "ArrowRight" by dispatching keydown with key "ArrowRight"... but ALSO the harness might send the string as text into the document body (focused element). If focus is on the document body and the harness "types" the string, the characters 'A','r','r','o','w','R','i','g','h','t' would be typed... 'a' → keyA.isDown... but my movePaddle reads isDown per frame; with a 630ms frame, only one frame processes it.

Actually more likely: the harness `key` action sends a proper key event for known names like "Space" and "ArrowRight". Then why did the paddle move left?

OH! I see it now. In `movePaddle`, `this.cursors.right.isDown` — the cursor keys are created via `this.input.keyboard.createCursorKeys()`. But I also registered `keydown-SR`? No... Hmm.

Wait, maybe the issue is different: `this.keySpace = this.input.keyboard.addKey(KeyCodes.SPACE)` and `this.input.keyboard.on("keydown-SPACE", this.handleAction, this)`. Fine.

Hmm, what about `this.input.keyboard.addKey(Phaser.Input.Keyboard.KeyCodes.R)` — pressing 'R' triggers keydown-R → handleAction → restart. Not related.

Let me consider that the ArrowRight keypress set `cursors.right.isDown` true, and in that same frame... dir=1, paddle.x += 265 → 505 → clamp to 438 (right edge). Then the screenshot should show the paddle at the RIGHT. But it shows it at the LEFT.

Unless the screenshot is from BEFORE the keypress took effect? No — the score changed from 230 to 430 (20 bricks destroyed) between the motion call and this screenshot, so frames advanced.

Hmm, is the paddle actually at the left? Let me look again at the image: the paddle (blue rounded bar) is at the bottom, spanning from about x=420 to x=480 in the screenshot... The visible border box spans about 356..844. The paddle looks like it starts at the left edge of the inner area (there's a gap for the wall graphic at x≈358). Yes it's at the far left.

So the paddle moved left. Could the paddle have been at the left BEFORE the ArrowRight press? Let's re-examine the motion frames: in all 4 frames, the blue paddle bar is at the bottom center-ish: In frame 1, the paddle spans roughly x=425..505 of the 480-wide playfield... Actually in frame 1 the paddle looks centered (the image shows it starting around x=425 and ending at 500 of the 1200 viewport, i.e., game x ≈ 65..140?? that doesn't look centered).

Hmm, I need to be careful about the mapping. Let me measure the canvas position. The game div: #wrap is max-width 520 centered in 1200 → 340..860. #game is inline-block 480 wide inside a text-centered parent → its box spans 340+20=... Actually #wrap has padding 18px 12px → content box from x=352 to x=848, centered → #game centered at x=600: spans 360..840. So game x=0 ↔ screen 360(+2 border), game x=480 ↔ 838.

In the last screenshot, the paddle spans from about x=360 to x=405 (screen) → game x 0..45 → left edge. Confirmed.

In the motion frames, the paddle looked like it spanned about x=425..500 screen? Let me look at frame 1's description again: the paddle bar appears to start around x=425 and end around 500 — hmm that would be game x 65..140, i.e., left-of-center. That's odd.

Hmm wait, I think the paddle in those frames was around x=420-500 screen, i.e., game x 60..140. Interesting: not centered either!

Actually hold on. Maybe the paddle IS centered and my scale estimate is off. The canvas is 480 wide but maybe it's being scaled by FIT: the parent #game is 480x620 but Phaser's FIT may compute the parent bounds as (480-4 border?) ... Actually if the parent's computed width were less than 480, the canvas would be scaled down. Let's check: the earlier concern about circular sizing. #game is inline-block with width:480 → shrink-to-fit irrelevant, width=480. The canvas inside is display block? Phaser adds the canvas with style. The parent's content box = 480 - 0 padding - 0 border... but I set `border: 2px solid` and `overflow:hidden` on #game. The content box = 480 - 4 = 476 wide, 616 high. So FIT would scale 480x620 → fit in 476x616 → scale = min(0.9917, 0.9935) = 0.9917 → canvas CSS size 476x614. So game x=0 ↔ screen ~362, game x=480 ↔ ~838. Fine, my mapping was roughly right.

So in the motion frames the paddle seemed to be left of center... Let me measure more carefully using a distinctive feature: the bricks. In frame 4, the ball is at game x≈460 (near the right wall) and the paddle at the left.

Hmm, in motion frame 1 the ball is at the top (x ≈ 240ish?) and the paddle at the bottom.

I can't reliably measure. Let me instead add a debug readout: temporarily display the paddle's x in the HUD. That's a quick way to verify containment precisely. I'll add `paddleX` to the stateText or HUD temporarily (and keep it out of the final version... or actually keep a small debug line? Better to remove after).

Even better: I can drive mouse movement via the `drag` action? A drag action might move the pointer from (x,y) to (toX,toY) and dispatch mousemove events along the way. Let me try a drag from the canvas center to the far right, and then screenshot to see if the paddle follows. If the pointermove events fire, the paddle follows the pointer.

Also for keyboard: maybe I should check whether the harness `key` action supports key names. The 'Space' press clearly launched the ball earlier (score 10, lives 2) — wait, did it? Let me re-check the timeline: 
1. reload
2. key Space → screenshot: no visible change (score 0, lives 3, ball on paddle)
3. click Launch button → screenshot: still score 0, lives 3, but the button appeared disabled/gray → so the ball HAD launched at that point (button disabled = not ballOnPaddle). So the Space keypress worked! Because the click on a disabled button wouldn't have changed the button's state... but hold on: at the time of the click, the button was already disabled because the Space launch happened in step 2. Yes! Space worked.
4. motion frames: score 10, lives 2 — the ball was launched and fell (losing a life) after hitting one brick. 

So `key` with text "Space" works properly. Then "ArrowRight" should work as a cursor key...

Hmm, unless the ball launched from the Space key but then... Let's recheck the later sequence: after the click on Launch (step 3) the ball launched again (it was on the paddle after losing a life). Then the motion frames showed active play with the paddle... 

Wait, at the time of the click in step 3, was the ball on the paddle? Lives were 2 with the ball on the paddle (state text visible) → clicking launched it → motion frames show the ball in play. In the motion frames, the paddle is a small blue bar. Look at motion frame 4: the paddle is at the bottom, roughly centered? The image shows the paddle near the bottom center-left...

I'm going in circles. Let me add a temporary debug text showing the paddle x and the ball x to the canvas HUD, then re-test. That gives precise data.

Actually, better: I'll add a permanent, small "debug-free" approach — write the paddle/ball positions into the `title` attribute of the DOM? Simpler: draw text in the HUD: `PADDLE 240`. I'll add it temporarily and remove it later. Let me add it as stateText content? The stateText is used for the prompt; I could add a second small text object at the bottom-right.

Let me just add a temporary `this.debugText = this.add.text(...)` showing "PX:.. BX:.. BY:.." updated in update(). Then screenshot after moving the mouse to the far right and after pressing ArrowRight/ArrowLeft.

Actually, the paddle IS following something to the left... Let me hypothesize: `this.input.on("pointermove", ...)` sets `mouseActive = true` and pointerX. But `this.mouseActive` persists forever after the first pointermove. Then the paddle follows `this.input.activePointer.x` every frame — and `activePointer.x` is in game coords. If the pointer never moved over the canvas... mouseActive stays false. So a click at (836,400) → the browser tool's click may dispatch mousemove first → pointermove fires with p.x = 474 → mouseActive = true → the paddle jumps to 474 (right edge) in the next frame. But the screenshot shows the paddle at the LEFT. So pointermove probably did NOT fire from the click, and mouseActive is false, and the paddle's position came from keyboard movement only.

Then the ArrowRight press must have moved it left... which is bizarre. UNLESS the harness's `key` action dispatches a keydown AND keyup for "ArrowRight" plus types the text? Or maybe the harness's key names are different (e.g., "Right" or "ArrowRight" unsupported) and it typed the literal string into the page. Typing "ArrowRight" characters: the first char 'A' (shift+a) → keyA.isDown → left movement. If keyA's isDown applies for one frame with delta 630ms → 265px left → clamped at 42. That fits perfectly!

But then how did "Space" work? Typing the literal string "Space": chars 'S','p','a','c','e'. No space char is typed! So the launch must have come from a real key event "Space". Contradiction... unless the harness supports named keys for letters like "Space" but not arrows? Possible: the harness might map "Space" to the space key but "ArrowRight" might be unrecognized and fall back to typing.

So the harness likely supports "Space", "Enter", "Tab", letters/digits, but maybe arrows are named differently (e.g., "ArrowRight" vs "Right"). Let me test with "Right" or "ArrowLeft" — hmm.

Better: verify with letters 'a' and 'd' which my game also supports! Press "d" → the paddle moves right. Then press "a" → left. That tests both keyboard movement and clamping.

Note: typing a single letter 'd' — if it's a real key event, keyD.isDown → moves right by 265px in one frame (given the slow fps) → clamped at 438 (right edge). 

Let's try "d".

The paddle is still at the far left after pressing 'd'. So keyboard isn't moving the paddle — meaning the key events aren't reaching Phaser at all, and the paddle's left position came from the mouse!

Wait: if the pointer moved over the canvas at game x ≈ 40... Hmm, the paddle is at the left. Maybe a pointermove DID occur when the tool clicked the Launch button (600,714): the browser tool might first move the mouse to the button, generating pointermove events. If the pointer passes over the canvas (from the previous position to (600,714)), a pointermove fires while over the canvas → mouseActive = true, pointer.x = some value → the paddle jumps to that x. Then `isOver` is false when the pointer is over the button, so the paddle freezes at whatever value. But the value would be near where it crossed the canvas, e.g., x≈240 (center) or x≈476.

Hmm, the paddle at the far left is consistent with the pointer entering the canvas at the left edge? The tool probably moves the mouse directly (no intermediate moves).

I need real data. Let me add a temporary debug text displaying the paddle x. That's the reliable way. Let me add a debug line to the HUD (temporary, removed after).

Also, keyboard: Phaser's keyboard listens on window by default (`input.keyboard.target = window`). The harness's key events might be dispatched on document.body or the focused element — they should bubble to window. Pressing Space worked, so keys DO reach Phaser. Then 'd' should also work... unless the "key" action's text 'd' was typed as text into a focused element (the Launch button after clicking?) — no, 'd' typed into a button doesn't matter.

Hmm! Wait. After clicking the Launch button, focus is on the BUTTON. When the harness types 'd', the keydown goes to the focused button and bubbles to window → Phaser's keyboard plugin receives it. Phaser's KeyboardPlugin adds listeners on `window` (for keydown/keyup) — should catch it.

But hold on: `keydown-R` etc. Hmm, 'd' — is keyD properly created? `this.keyD = this.input.keyboard.addKey(Phaser.Input.Keyboard.KeyCodes.D)`. Yes.

Hmm, but wait: maybe the key events ARE reaching Phaser, but the paddle didn't move because the move happened while `delta` was tiny? No, the delta is ~630ms, so it should move a lot.

Unless... `movePaddle` is called from update() and the paddle position is then overridden? Let's re-read my update():

```js
update: function (time, delta) {
  if (!this.paddle) return;
  this.movePaddle(delta);
  var ball = this.ball;
  if (this.ballOnPaddle) { ... }
  if (ball) this.glow.setPosition(ball.x, ball.y);
}
```
and movePaddle:
```js
var step = 0.42 * delta;
if (dir !== 0) { this.mouseActive = false; this.paddle.x += dir*step; }
else if (this.mouseActive && this.input.activePointer.isOver) { this.paddle.x = this.input.activePointer.x; }
var half = PADDLE_W/2;
this.paddle.x = Clamp(this.paddle.x, half, GAME_W - half);
this.paddle.body.reset(this.paddle.x, PADDLE_Y);
```

**`this.paddle.body.reset()`** — Body.reset(x, y) sets `this.stop()`, sets position, and updates the gameObject position. Hmm, but does `body.reset` also reset `body.enable`? Let's look at the source... Actually there might be an issue: Body.reset sets `this.position.set(x, y)` and `this.gameObject.setPosition(x, y)`. Fine.

So why doesn't the paddle move right?

**AH WAIT.** I bet the problem is the scale! The paddle has `setScale` from the tween when the ball bounced off it. The body `updateBounds` recomputes width based on scale. But more importantly, `body.reset(x, y)` uses the body's halfWidth to position the gameObject: `this.gameObject.setPosition(x + offset...)`? Let's look at Body.reset:

```js
reset: function (x, y) {
    this.stop();
    var sprite = this.gameObject;
    sprite.setPosition(x, y);
    ...
    this.updateBounds();  // ?
    ...
}
```
Hmm, if Body.reset sets the gameObject's position to (x, y) directly ignoring the body's offset, then since the body's position is derived from the gameObject via `updateFromGameObject` (position.x = x - displayOriginX... wait for a body, position.x = transform.x + scaleX*(offset.x - displayOriginX) = x + (0 - 42) = x-42, so position is the body's top-left.

And Body.reset(x, y) — in Phaser's Body.reset:
```js
reset: function (x, y) {
    this.stop();
    var sprite = this.gameObject;
    sprite.setPosition(x, y);
    ...
```
So passing the paddle's CENTER x is correct — the gameObject is positioned at its center (origin 0.5). OK.

So the paddle should move. Unless `movePaddle`'s `dir` is 0 and `mouseActive` is true with a stale pointer.x = ~40 → the paddle stays at 40 every frame, overriding the keyboard movement! That's exactly the symptom: the paddle is stuck at the far left, unaffected by the keyboard.

So `mouseActive = true` and `activePointer.x` ≈ 40 (game coords) — the pointer must have moved over the left part of the canvas. But then in the earlier motion frames the paddle was in the middle...

And the requirement "isOver" — for a pointer that's over the button (not the canvas), isOver should be false, so the paddle wouldn't follow the pointer at all. But `activePointer.isOver` might be stale/true... Actually Phaser sets `pointer.isOver`... hmm, `InputManager.onPointerMove` sets `pointer.isDown` etc. Where is isOver set? In `Pointer.move`/`InputManager.updateInputPlugins`: it sets `pointer.isOver`? Hmm, `this.isOver = this.camera`... Actually `isOver` is not a standard Phaser pointer property... Let me check: In Phaser 3, `Pointer` doesn't have `isOver`; hmm, but I recall `pointer.isOver` doesn't exist and there's `this.input.activePointer.isOver`... Let me grep.

Actually in Phaser 3 there IS `pointer.isOver`? Hmm... Let me check the source.

`isOver` is on the InputManager (scene.input.isOver → manager.isOver), which starts as true and is updated only on touch and mouse over/out events. So `this.input.activePointer.isOver` is `undefined` (the Pointer object has no isOver) — I wrote `this.input.activePointer.isOver` which is always undefined → falsy! That means the mouse control branch NEVER runs, so the paddle only moves via keyboard.

Wait, but then how did the paddle get to the left? Only the 'a' from typing "ArrowRight" (the harness typing characters) could have done that. And then 'd' should have moved it right...

Unless the harness's `key` action with text 'd' also typed... hmm, 'd' would move right by 265px → clamped at 438 (right edge). But the screenshot shows the paddle at the LEFT. So 'd' did nothing at all?! But Space worked...

Hmm, wait. Maybe the harness `key` action dispatches the event to the focused element. After I clicked the Launch button, focus is on the button. When I press 'd' with the button focused, the keydown bubbles to window... Phaser's KeyboardPlugin listens on `window` by default? Let me check: `KeyboardPlugin` constructor: `this.target = ...` — it uses `config.inputKeyboard.eventTarget || window`? Actually in Phaser 3, KeyboardPlugin listens on `window` (for keydown/keyup) unless `config.inputKeyboard.target` is set. Hmm, in newer versions it's `this.target = GetValue(config, 'inputKeyboard.target', window)`? Let me check quickly.

Also note: I have a document-level keydown handler that calls preventDefault for Space/Enter, not for letters.

Another thought: maybe my own `document.addEventListener("keydown", ...)` handler intercepting Space/Enter isn't relevant.

Let me check whether the keydown listener is on window and whether Phaser's keyboard plugin might be disabled because the canvas doesn't have focus... `KeyboardPlugin` in Phaser 3.60+: `this.enabled = ...; this.target = target || window`. Let me grep for `addEventListener("keydown"` in the phaser source.

Actually, simpler explanation: the harness `key` action with text 'd' might send the key to the page only if... Hmm.

Let me check what `Phaser.Input.Keyboard.KeyCodes.D` is: D = 68. Fine.

Hmm, but wait — maybe the issue is that after clicking the Launch button, the button has focus, and pressing 'd' triggers Phaser's keydown... Let me look at the KeyboardPlugin's wiring: in 3.80, KeyboardPlugin has `startListeners()` which is called on the scene's START event; it adds listeners to `window` for keydown/keyup. And it checks `if (!this.enabled) return`... `enabled` requires `this.manager.enabled`. Fine.

But — CRITICAL — Phaser's KeyboardPlugin also has `this.paused`/`this.target` and in `onKeyDown` it checks `if (event.defaultPrevented || !this.enabled || !this.manager.isOver) return;` !!! I recall something like:

```js
onKeyDown: function (event) {
    if (event.defaultPrevented || !this.enabled || !this.manager.isOver) { return; }
```
Hmm! That's in the KeyboardPlugin? Let me grep for "defaultPrevented" near keydown handling.

That would mean keyboard input only works when the mouse is over the canvas! That explains:
- Space worked: at that time the mouse pointer was over the canvas? Possibly the harness moves the mouse to the center of the page or the click position was within the canvas... The first Space press — the mouse might have been at (0,0) initially or over the canvas. Hmm, but then later key presses stopped working...

Actually, in the very first Space test, the mouse had never moved (initial position 0,0 → top-left corner). manager.isOver starts as `true` (this.isOver = !0) and only changes via setCanvasOver/setCanvasOut on mouseover/mouseout events. So initially isOver = true, and keys work. When the harness clicked the Launch button (y=714, outside the canvas), a mouseout/mouseover on the canvas may have fired → setCanvasOut → isOver = false → keyboard input stops working from then on!

That explains: the first Space worked (isOver still true), then after the button click, isOver=false → all subsequent keys ignored ('d' did nothing, 'a' from "ArrowRight" did nothing... but then how did the paddle get to the left?!).

Hmm, the paddle got to the left AFTER the button click, so keyboard movement was already disabled. So something else moved the paddle left. What else? The mouse branch (dead due to `activePointer.isOver` undefined)... 

Hmm, wait. What about `Phaser.Input.Keyboard.KeyCodes.R` → 'r' typed in "ArrowRight" → restart! And 'a'... Let's reconsider: maybe the "ArrowRight" keypress was a REAL key event for ArrowRight (the harness supports arrows), and after the click on the Launch button, the ball was launched... no.

Ugh. Let me just gather data. I'll add a debug text object showing paddle.x, ball.x/y, lives, mouseActive, isOver, so I can see exactly what's happening. Let me do that — modify the file temporarily.

Actually, better idea: instead of debugging blindly, make the implementation robust and remove the ambiguity:

1. Fix mouse control: use `this.input.isOver`? No — `scene.input.isOver` (manager) reflects whether the canvas is hovered. But the paddle should follow the mouse when the pointer is over the canvas. Cleanest approach: use the scene's pointermove handler to set the paddle directly (as I do with pointerX/mouseActive) — but only when the pointer is actually over the canvas. In the pointermove handler, check `p.event.target === game.canvas`? Or simply set `this.mouseActive = true` and in movePaddle use `this.pointerX` (from the last pointermove) — the problem: after the pointer leaves the canvas, the paddle keeps following. That's actually acceptable/typical? Many implementations freeze the paddle when the mouse leaves.

Better: use Phaser's `pointer.x` in the pointermove handler, and in the handler check whether the event target is the canvas:
```js
this.input.on('pointermove', function (p) {
  if (p.event && p.event.target !== this.game.canvas) { this.mouseActive = false; return; }
  this.pointerX = p.x; this.mouseActive = true;
}, this);
```
Hmm, `p.event` is the original DOM event. For a pointermove over the canvas, target = canvas. 

Simpler and robust: listen to the game canvas 'mousemove' DOM event and 'mouseleave' to disable:
```js
var canvas = this.game.canvas;
canvas.addEventListener('mousemove', function(e){ ... compute game coords via pointer.x ... });
```
But computing game coords requires the scale transform; Phaser's pointer object already does that. I can use `this.input.activePointer.x` inside the DOM mousemove handler since Phaser updates the pointer before emitting the scene event? Actually the scene's pointermove event fires from `updateInputPlugins` after Phaser updated the pointer position, so `p.x` is already in game coords. In the DOM handler, `this.input.activePointer.x` may lag by one frame. Use the scene input event but check the event target.

Actually the simplest robust approach: in the scene's pointermove handler, use `p.x` (game coords, already transformed) and require `p.event.target === this.game.canvas`. Let me do that. And also handle `pointerout`/`gameout` to stop following the mouse: `this.input.on('gameout', function(){ this.mouseActive = false; }, this)`.

2. Keyboard: isOver (manager.isOver) may block keys when the mouse leaves the canvas — if Phaser's KeyboardPlugin checks manager.isOver, I should ensure the keyboard works regardless. Let me grep to confirm.

Let me check the KeyboardPlugin's onKeyDown.

KeyboardPlugin listens on `this.target` which is `config.inputKeyboardEventTarget` — if undefined, defaults to `window`. So keydown on window works regardless of isOver. So keys should still work.

Hmm, but there's `this.enabled` — enabled is true by default.

Wait... `this.target = t.inputKeyboardEventTarget` — note in my game config I didn't set inputKeyboard, so it's fine (target = window).

So why didn't 'd' move the paddle? Let me look at the key handling: keys are queued and processed in `postUpdate` (POST_STEP). The queue is processed... `KeyboardPlugin.postUpdate` processes the queue → sets key states. Then scene update reads `isDown`. Since POST_STEP fires before the scene update? Order: the game step emits POST_UPDATE/POST_STEP after scene updates. Hmm, if keydown events are processed in POST_STEP (after the scene's update), then `isDown` becomes true only for the NEXT frame. That's a one-frame lag — not a problem at 60fps, and at 1.5fps there's still a next frame (630ms later).

Hmm, but with `isDown` — the Key object's `isDown` is set in `Key.onDown` (via the plugin's update). But there's also the `_justDown`/`_justUp`. When the key is released (keyup), isDown = false. Since the harness likely sends keydown+keyup quickly (within the same frame), by the next frame isDown is false again → the paddle never moves! That's exactly the problem: at 1.5fps, a quick keydown/keyup pair is missed entirely unless it happens to be processed.

Hmm, but then how did Space work (launch)? Because the launch is handled by the `keydown-SPACE` event listener (not isDown polling) — and Phaser's KeyboardPlugin emits 'keydown-SPACE' during processing... which happens in postUpdate (after the scene update). So the launch works because it's event-driven.

So: at the harness's ~1.5fps, a keydown+keyup pair is processed together and `isDown` never observed as true in update(). That's why 'd' did nothing. This is a testing-environment artifact (mouse/touch drag or holding keys would work).

To be robust, I should handle keys via events (keydown) rather than isDown polling for the paddle, or rely on `Phaser.Input.Keyboard.JustDown`. Simplest robust fix: handle paddle movement with keydown events: `this.input.keyboard.on('keydown-LEFT', ...)` moving by a fixed amount? Better: implement continuous movement using the key states but ALSO handle held keys... 

Actually the cleanest: keep isDown polling (correct for real gameplay at 60fps) — it works fine in real usage. The harness's low fps is the artifact. But I want to verify paddle containment in this environment. Alternative verification: use the mouse. The mouse branch is currently broken (`activePointer.isOver` undefined) — and I noticed the paddle ended up at the left, which suggests... hmm, what moved it left?

Let me think again about how the paddle got to the far left. Consider the harness `click` on the Launch button at (600,714): the harness moves the mouse to (600,714). Moving the mouse triggers mousemove on the button (outside the canvas) → Phaser's `onMouseMove`... Let me check Phaser's `onMouseMove`: it uses `this.isOver = this.manager`... Actually `onMouseMove` in InputManager:
```js
onMouseMove: function (event) {
    var isOver = this.manager.isOver;
    if (!isOver) { ... this.setCanvasOver(event) }  // maybe
    this.mousePointer.move(event, ...);
```
Hmm, Phaser's InputManager.onMouseMove doesn't check the target element — it processes the move regardless (only touch checks elementFromPoint). So a mousemove over the BUTTON (outside the canvas) would still update the mouse pointer's position, and the scene's pointermove event would fire with p.x = game coords of the client position! So the pointer.x could be off-canvas (e.g., negative x or > 480).

So the harness's mouse move to the Launch button (x=600 → game x=240) would fire a pointermove with p.x = 240 → mouseActive = true. So the paddle should be at 240 (center), not the left. Unless the mouse was moved to a position left of the canvas at some point (e.g., the harness moves the mouse from the previous position 0,0 to the target, generating intermediate moves? Unlikely).

Hmm, but at some point I pressed ArrowRight (which under the "typing" theory typed 'a' → keyA → left). With the 630ms frame, one keydown 'a' → in the next frame's postUpdate, the key state is applied... but the keyup also applies in the same postUpdate batch → isDown ends false. Hmm, unless the keyup was processed in a different frame.

OK — enough theorizing. Let me add temporary debug output showing paddle.x, mouseActive, pointer.x so I can see the actual state. I'll add it to the HUD as a small text line (temporary).

Actually — a better use of my remaining time: make the code correct/robust for real usage, and verify what I can:
- Fix mouse control to properly use scene pointermove with the canvas target check (so it works when the mouse is over the canvas).
- Keep keyboard (isDown polling) — standard and works in real browsers.
- Additionally, handle keydown events for left/right as an immediate impulse? That would double-move in real usage (frame-based + event-based). Instead, use `JustDown` events to set a small impulse... complicated.

Better approach for verification: I can drive the paddle by dispatching synthetic events via the browser tool? No JS eval available.

Hmm — what about using `drag`? The drag action probably does mousedown at (x,y), moves to (toX,toY), then mouseup. Mouse moves over the canvas will fire pointermove → with my fixed mouse control, the paddle would follow. Let me fix the mouse control first and test with a drag from the center to the right edge, then screenshot.

Let me now implement the fixes:
1. Mouse: `this.input.on('pointermove', ...)` with a canvas target check, plus `gameout` to stop.
2. Also make the paddle follow the pointer on pointerdown (for touch).

Then test via drag.

Also, to be safe for keyboard at low fps, I could use both isDown polling AND `keydown` events to set a per-frame movement flag. Actually a neat approach: on keydown-LEFT/RIGHT (event), set `this.keyDir` to ±1 with a timestamp; in movePaddle, if keyDir is set and the key is still down (isDown), move continuously; if the event fired but the key state is already false (quick tap), still apply movement for that frame. Implementation:

```js
this.input.keyboard.on('keydown-LEFT', () => { this.tapDir = -1; }, this);
this.input.keyboard.on('keydown-RIGHT', () => { this.tapDir = 1; }, this);
```
In movePaddle: 
```js
var dir = 0;
if (left.isDown || keyA.isDown) dir -= 1;
if (right.isDown || keyD.isDown) dir += 1;
if (dir === 0 && this.tapDir !== 0) { dir = this.tapDir; }  // applies for one frame
this.tapDir = 0 (reset after use, before or after movement)
```
But note keydown events are processed in postUpdate (after scene update) — so the tapDir set in postUpdate would be consumed in the NEXT frame's update. Good: at low fps the tap still produces one frame of movement (with a large delta → clamp). 

Careful: `keydown-LEFT` event names: Phaser's KeyboardPlugin emits 'keydown-LEFT'? The key names for cursor keys: 'LEFT', 'RIGHT', 'UP', 'DOWN' (KeyCodes). And 'keydown-A', 'keydown-D'. Let me use both LEFT/RIGHT and A/D.

This makes keyboard robust in both real and throttled environments. And the fixed-speed movement per frame uses delta, so a real 60fps game feels right.

Hmm, but one risk: if the user holds the right key, isDown is true → continuous movement; the tapDir would also add an extra frame of movement on the first frame → negligible.

Also, potential double-counting: when a key is held, every frame has isDown true → normal. When tapped, one frame with tapDir → fine.

Let me implement both fixes and test with the drag (mouse) and key presses.

Also fix: `stateText` says "PRESS SPACE OR CLICK LAUNCH" — fine.

Let me write the edits.

Wait, there's an ordering problem: `resetGame()` is called at the end of create() and it references `this.mouseActive` etc. — `this.mouseActive = false` is set before resetGame. Fine.

But `movePaddle` is called from update() which happens after create. OK.

However `this.tapDir = 0` initialization happens before resetGame. Good.

Now, an issue: the mouse branch `this.paddle.x = this.pointerX` — the pointerX is in game coords. Also the mouse should not fight with the ball resting on the paddle. Fine.

Another consideration: `p.event.target !== this.game.canvas` — for pointer events from the browser tool (mousemove), p.event is the DOM event with target = the element under the cursor. When over the canvas, target = canvas. Good. But careful: Phaser may use pointer events or mouse events; in either case target should be the canvas.

Hmm, one risk: `p.event` could be undefined for some synthetic events; then `p.event && ...` is falsy → returns early → mouse wouldn't work. Safer: `if (p.event && p.event.target !== this.game.canvas) return;` — if p.event is undefined we skip the return and use p.x. Wait no: if p.event is undefined the condition is false → we don't return → we use it. Good, that's what I wrote.

Now let's also double check the `gameout` event exists: Phaser.Scale? The InputManager emits GAME_OUT = 'gameout' on setCanvasOut, which is triggered by... the INPUT_OUT event from the ScaleManager? In Phaser 3, the ScaleManager emits OUT when the pointer leaves the canvas (it listens for mouseout/mouseleave on the canvas and dispatches 'out' to the game events, and the InputManager listens to GAME_OUT). Yes, `this.input.on('gameout')` should work — but the event is emitted on `game.events` and re-emitted by the InputManager? Looking at the source: `setCanvasOut: function (t) { this.isOut = !1, this.events.emit(o.GAME_OUT, t) }` — the InputManager emits GAME_OUT on ITS OWN events (this.events = input manager events), which is what `this.input` (the scene input plugin) proxies? Hmm, the scene input plugin's `on` method delegates to `this.manager.events`? Let me check: InputPlugin's `on: function (event, fn, context)` — it proxies to `this.manager.events` (for manager-level events) — actually InputPlugin has both scene-level and manager-level. In Phaser 3, `InputPlugin.on` is overridden:

```js
on: function (event, fn, context) {
    if (this.manager) { this.manager.events.on(event, fn, context) } ...
```
Hmm, actually I recall InputPlugin has a special `on` that routes 'gameout'/'gameover' to manager.events. Yes — InputPlugin defines:
```js
on: function (event, fn, context) {
    if (IsFunction(this.manager[event])) ...
```
Let me just grep quickly for GAME_OUT handling. Alternatively, safer: attach a DOM listener directly on the canvas for 'mouseleave'/'mouseout':

```js
var canvas = this.game.canvas;
canvas.addEventListener('mouseleave', function(){ scene.mouseActive = false; });
```
That's guaranteed. Let me replace the `gameout` listener with a DOM listener to avoid uncertainty.

Fresh state. Now let me drag the mouse across the canvas to move the paddle to the far right. A drag from (600, 500) to (830, 500). Then screenshot to verify the paddle is at the right edge and inside the playfield.

Actually, a `click` might also fire pointermove now (with my pointerdown handler making it active). Let me click at the far right inside the canvas: (835, 300) — but that's above the HUD. Fine. Then the paddle follows the pointerdown → pointerX = 473 → clamp 438 → the right edge.

Then screenshot. Then click at the far left (366, 300) → the paddle should clamp at 42.

Let's do the right one first.

Now the paddle is at the far right edge, flush with the right wall, and it stayed inside the playfield. Mouse control works now.

Next: click at the far left to verify the left clamp.

Hmm — now the paddle appears to be at the far LEFT but it looks like it's OUTSIDE the playfield slightly? Look: the paddle's left end appears to be at the inner wall's left edge... Actually the paddle looks like it starts right at the left wall (with a tiny gap). Let's compare with the earlier screenshot where the paddle was at the left: in that one the paddle appeared to touch the left wall too.

Wait, but in this screenshot, the paddle appears to be positioned slightly higher (y) and its left edge seems to align with the left border. It's at game x≈42 (clamped). The body is 84 wide → spans 0..84 in game coords. The left wall graphic is 6px wide. So the paddle covers the wall graphic region but stays within the playfield's horizontal extent. Good — inside.

Hmm, but is the paddle's left edge at x=0 exactly (touching the wall)? Looks like there's a small gap. Good.

Now let me verify keyboard movement works with the tap impulse. Press ArrowRight now: since the mouse pointer is over the canvas (mouseActive true) — hmm! `mouseActive` is true, so the paddle follows the pointer at (365,300) → game x ≈ 5 → clamped 42. Keyboard: dir=-1/1 → keyboard takes priority (dir !== 0 branch). So pressing ArrowRight: if the keydown event is processed, tapDir = 1 → paddle moves right by step (0.42*630 = 264) → clamp 438 (right edge). But if the harness's ArrowRight press doesn't reach Phaser, nothing happens and the mouse branch keeps it at 42.

Note the mouse is currently at game x≈5, so if the mouse branch wins, the paddle stays at the left. Good for detecting whether keyboard input works.

Let's press ArrowRight.

The ArrowRight keypress had no effect — the paddle is still at the left. So the harness's "ArrowRight" key event isn't reaching Phaser (or isn't recognized). The 'd'/'a' letter test also failed earlier (before the fix, though — the isDown polling wouldn't have caught a tap; now with the tap impulse, letters should work).

Let me test with 'd' now (should move right with the tap impulse).

Wait — but if the mouse branch is active (mouseActive=true and the pointer at x≈5), the keyboard branch takes priority in movePaddle, so 'd' → tapDir → right. Let's test.

'd' also had no effect. So keyboard events are not reaching Phaser at all now. Why? Because `this.manager.isOver`? No — the KeyboardPlugin's onKeyDown only checks `defaultPrevented` and `enabled`.

Wait: my own document keydown handler calls `e.preventDefault()` only for Space/Enter. For 'd' I don't preventDefault.

Hmm, but maybe the harness's `key` action dispatches a keydown on a specific element and Phaser's listener on `window` should still catch it (bubbling)... unless the harness dispatches the event directly on the element without bubbling (e.g., `new KeyboardEvent('keydown', {bubbles: false})` or via CDP `Input.dispatchKeyEvent` on the focused element — CDP does dispatch to the focused element with bubbling, so window should receive it).

Wait — maybe the earlier Space keypress DID launch the ball because of... hmm, that WAS a key event. So keys worked then.

Unless! Focus. After clicking the Launch button (in the earlier session), the button had focus. My document keydown handler for Space/Enter ALSO calls `actionBtn.blur()`. In the current session, I clicked inside the CANVAS (835,300) and (365,300) — the canvas isn't focusable, so the active element is body. Then keys go to body → window → Phaser.

Hmm, but Space worked in the FIRST session before any button click. So keys worked with body focus. Now with body focus it doesn't work?!

Hmm, wait. Maybe the difference: in the first session the key events went to... Let me test pressing Space now — if Space launches the ball, then keys DO work and only letters/arrows are broken (weird).

Let's try Space.

I have limited time. Space with a single space char did nothing either (the launch didn't happen). So keyboard events from the harness aren't reaching Phaser at all in this session. Perhaps the harness requires the page to be focused, or it uses a different mechanism.

Wait — earlier, after reload, the first Space press DID launch the ball (in the very first session). Hmm, actually no: in session 1, after pressing Space, the screenshot showed no change, and after clicking the disabled-looking button, the motion frames showed score 10/lives 2. So maybe the launch happened from the click... but the button appeared disabled which happens when ballOnPaddle=false. Hmm, the button's disabled styling appeared right after the click — consistent with the click launching it (the click happened at (600,720) which is the button). But the button appeared gray in that screenshot, i.e., disabled — which happens after launching. So the click on the button DID launch the ball in session 1! That means Space never worked. OK.

So: keyboard events never reach Phaser in this harness environment (perhaps the harness sends key events only to a focused element, or the game's iframe isn't focused). The mouse/click path works.

Given my time budget (5 minutes), the game itself works: mouse control (verified at both edges), launch via the Launch button (verified), brick destruction + score (verified), wall bounces (verified), losing lives on a miss (verified, lives 3→2 and life-loss overlay logic paths verified).

Remaining unverified: keyboard controls, win state, game over, restart. These are straightforward in code. Let me do a final sanity check of the code for the win path and the restart, and make sure the Launch button label updates.

One concern: `checkWin` uses `this.bricks.children.each(...)`. For a staticGroup, `children` is a Phaser.Structs.Set — `.each(callback)` exists on Set. Each callback receives (child, index?) — Set.each(callback, callbackScope) — yes.

Another: when `won`, the overlay shows and `handleAction` → resetGame. resetGame rebuilds? No — resetGame only resets score/lives/ball and hides the overlay. But the bricks are NOT recreated! Requirement: "Restart restores all bricks, score, and lives." So I must rebuild bricks in resetGame. Currently `buildBricks()` is only called in create. BUG — must fix: destroy all bricks and recreate them in resetGame.

Let me fix that now (essential). In resetGame:

```js
this.bricks.clear(true, true);  // destroy children
this.buildBricks();
```
`Group.clear(removeFromScene, destroyChild)` — yes, Phaser Group.clear(removeFromScene, destroyChild).

Note buildBricks regenerates textures (fine, cached).

Let me apply this fix now, then do a final quick check: use the mouse to move the paddle, click Launch, wait for the frames, and confirm a life loss/restart path via clicking the button after game over? That would take too long (3 lives). I'll instead verify the restart via the 'R'... no keyboard. Hmm. I can verify game over by letting the ball drop 3 times — each drop requires ~1 frame; it's fast actually. Then the button becomes "Restart" and clicking it should restore all 60 bricks, score 0, lives 3. That's a valuable verification of the win/over/restart logic. Let's do that after the fix.

Also for the win state: I can't easily clear all 60 bricks manually. I'll trust the code (checkWin on each brick hit) — but I could simulate by... no time. I'll note it as unverified.

Let me apply the fix.

Good. `buildBricks` is called in create AND in resetGame — and it regenerates the textures each time (harmless, just slow-ish). Let me split texture generation from brick creation to avoid regenerating textures 60 times... it's fine, they're already cached (generateTexture overwrites). OK.

Now let's verify: reload, launch, let lives run out (ball drops 3 times), then click Restart and confirm all bricks/score/lives are restored. Note: each drop takes one frame; but the ball must be re-launched each time! After a life loss, the ball returns to the launch state and the button becomes "Launch" again. So I need to click Launch 3 times. Each click → launch → next frame (630ms) → ball falls (the launch sends it up, so it may hit bricks; it takes several frames to come back down). Each frame is 630ms and the ball travels ~185px/frame. From the paddle to the bottom is ~570px → ~3 frames after reaching the top. So per life: ~4-5 frames ≈ 3 seconds. The motion action takes 4 frames (~2.6s) — that's about one life per motion call.

Total time budget ~3 minutes left. Plan:
1. reload
2. click Launch (button at ~600,714)
3. motion (x2) → should lose 1-2 lives
4. click Launch again, motion, repeat until game over
5. click Restart → screenshot → verify 60 bricks restored, score 0, lives 3.

Let me be efficient: do reload, click Launch, then a few motion calls with clicks in between. I'll batch independent calls where possible (reload then click must be sequential).

Let's go.

Ball launched. Now run motion to let lives drain (ball will fall after a few frames), then click Launch again for each life. Let me do motion once.

One life lost (3→2), score 10, one brick removed, ball back on the paddle with the launch prompt. Life-loss and return-to-launch-state verified.

Now to reach Game Over I need 2 more life losses: click Launch, motion, click Launch, motion. Then click Restart and verify the full reset. Let me be quick.

Lives = 1. One more life loss → Game Over. Click Launch, motion, then check for the "GAME OVER" overlay and the Restart button, then click Restart and verify the brick wall is fully restored.

Game Over works: "GAME OVER / Score: 380 / PRESS SPACE / R OR CLICK RESTART", LIVES 0, and the button says RESTART.

Now click Restart and verify all 60 bricks are restored, score 0, lives 3.

Restart works perfectly: all 60 bricks restored (6 rows × 10), score 0, lives 3, ball on the paddle with the launch prompt, and the button reads "Launch".

The file is saved. Let me do a final quick sanity check on the file (e.g., confirm it's a single self-contained file, no external requests) and confirm the file exists.

Also, the win state wasn't verified. The code path (`checkWin` → overlay "YOU WIN!" with restart) is the same as game over's path (verified via game over), so it's reasonable, but I'll note it as unverified.

One last consideration: the `gameout` event handler I added may be a no-op if the event name differs — harmless.

Also, the keydown handlers for Space/Enter preventDefault; the Space key is also captured by Phaser (`addCapture`)? Not set; fine.

Let me do a final check that index.html has no external resource references.