Brick breaker · qwen3.8-flash

Let me look at the current directory first.

Let me check the Phaser version.

Phaser 3.80.1. Build a brick-breaker game with arcade physics. Phaser's Matter/Atlas sprite physics needs a JSON atlas for spritesheets, but the `generateTexture` on Graphics works with arcade physics since physics textures can be generated from graphics. Using Phaser.Graphics for paddle/ball/bricks without textures requires manual collision handling. Options:

1. Use arcade physics with generated textures from Graphics (`graphics.generateTexture('ball', 16, 16)`). That's allowed — "generate all graphics using Phaser Graphics or generated textures". So generate textures from Graphics, then use sprites with arcade physics. This gives circle vs rectangle collisions working well.

2. Or write custom collision logic — more control but more code.

Approach 1 is cleaner and uses Phaser's physics properly. Let me build:

- Game size: 900x640 (or 800x600). Playfield walls: left, right, top (static invisible bodies or drawn walls visible).
- Paddle: sprite from generated texture (rounded rectangle gradient), immovable, allowGravity false. Move with keyboard left/right and mouse.
- Ball: sprite with circle body, bounce 1, gravity 0, collide with walls/paddle/bricks.
- Bricks: group of sprites from generated textures of a few colors (rows color-coded). On brick hit: score += 10, brick.destroy().
- States: 'ready' (ball rests on paddle, follows paddle), 'playing', 'win', 'gameover'.
- Launch: Space or visible Launch button (UI with pointerover/down). Use Phaser-made graphics for the button.
- HUD: score, lives, using text. Text is fine (no external font assets; use default font family).
- Lose life: ball falls below paddle → lives--; if lives > 0 → back to ready; else Game Over.
- Restart: R key or Restart button visible in overlay; restores bricks, score=0, lives=3.

Ball-paddle physics: to make gameplay good, modify ball vx based on hit position on the paddle. Use collider callback: on paddle hit, set speed magnitude constant and angle based on offset. Also prevent ball from getting stuck in near-horizontal trajectory: clamp |vy| minimum.

Also add ball trail? Keep simple but polished: starfield background drawn with Graphics, rounded bricks with highlight, glow ball.

Careful with generateTexture: In Phaser 3, `graphics.generateTexture(key, x, y, width, height)` — takes from the graphics drawing buffer. Works with the canvas/webgl renderer. It's deprecated? It exists in 3.80 (deprecated in favor of Renderer.Texture but still functional). Let me confirm it exists.

Actually let me check: `Phaser.GameObjects.Graphics.prototype.generateTexture` — yes still present in 3.80.

Also for the ball I'll use a texture of a circle with radial gradient-ish approximation: draw filled circle, then lighter inner circle offset. Good enough.

WebGL vs canvas: In sandboxed browser, may need to use AUTO or Canvas. Let's use `Phaser.AUTO`. Should be fine. Actually headless browsers sometimes lack WebGL — the harness browser probably supports it. Let me test.

Let me write the file.

Structure:

```html
<!DOCTYPE html>
<html lang="en"><head><meta charset="utf-8"><title>Brick Breaker</title>
<style> html,body {margin:0;height:100%;background:#070b16;display:flex;flex-direction:column;align-items:center;justify-content:center;font-family:system-ui...; color:#cfd8ff}
#wrap { ... }
h1 ...
#game { }
canvas { display:block; border-radius:12px; box-shadow ... }
.help { ... }
</style>
</head><body>
<div id="wrap">
 <div id="game"></div>
</div>
<script src="phaser.min.js"></script>
<script> ... game code ... </script>
</body></html>
```

Controls explanation also inside canvas HUD + HTML footer text ("Show the controls").

Game code details:

```js
const W=880, H=640;
const WALL=14; // border thickness
const state = {score:0, lives:3, mode:'ready'};
```

Scene:

preload/create: generate textures.

```js
function makeTextures(g) {...}
```

Let me write with a Boot-ish approach: single scene 'Main', create() generates textures then builds world.

Paddle movement:
- keys: this.keys = cursors left/right; speed 520 px/s.
- mouse: on pointermove, set paddle.x = clamp(pointer.x) unless keyboard used. Use both: mouse moves paddle directly (with pointer.locked? just use this.input.on('pointermove')). To avoid conflict, allow both: if keyboard is pressed use keyboard movement, else follow mouse smoothly. Simpler: track a flag `useMouse` set true on pointermove, and set false on arrow keydown.

Ball launch: velocity based on paddle direction? Launch angle: upward with slight random x, or influenced by paddle velocity. Launch: vx = 90*randSign? Use: angle = -Math.PI/2 + (Math.random()*0.5 - 0.25) maybe based on offset from paddle center. Let's do: dx = ball.x - paddle.x; angle = -60°..-120° ... Actually classic: launch up-right at ~ (speed*0.4, -speed). Let's do angle = -Math.PI/3 to -2Math.PI/3 randomly, speed 380 and increase with score.

Ball speed management: keep constant speed magnitude; on paddle hit normalize speed and set angle from hit offset: 
```
const off = (ball.x - paddle.x) / (paddle.width/2); // -1..1
const angle = off * (Math.PI/3) ; // up to 60 deg from vertical
dirX = Math.sin(angle), dirY = -Math.cos(angle)
```
Plus add a bit of paddle velocity influence. Clamp min |vy| = 0.35*speed.

Bricks: rows=6, cols=12? W=880 minus walls → playfield 880-28=852 wide. brick width 60, gap 6: 12*60 + 11*6 = 720+66=786, plus margins. Let's compute: cols=12, bw=62, gap=6 → 12*62+11*6=744+66=810; left margin = (852-810+... ) start x = WALL + 21. Fine — compute programmatically: padding=24 inside playfield; totalW = W-2*WALL-2*padding; bw = (totalW - gap*(cols-1))/cols.

Brick rows 6, height 24, gap 6, starting y = WALL + 60 (leaving room for HUD? HUD overlay at top inside wall region maybe). Let's put HUD text at bottom? Classic: score/lives at top area. Walls: top wall at y=WALL. Bricks start y = WALL + 70. Total brick area height = 6*24+5*6 = 144+30 = 174 → ends at ~ 70+174+14 = 258 from top. Paddle at H-40. Fine.

Brick scoring: rows different colors, score += (rows - rowIndex)*5? Requirement is just "increases the score once" per brick hit. So each destroyed brick adds points once; score increases once per brick. I'll add 10 + (rows-1-row)*... hmm "increases the score once" means score increments once per brick hit. Keep it simple: 10 points per row-based value: value = 70 - row*10 → varying but each brick adds once. Let me use `value = (bricks config)`. Fine.

Brick hit callback: 
```
this.physics.add.collider(balls, bricks, hitBrick)
hitBrick(ball, brick){ this.score += brick.dataset.value; brick.destroy(); updateHUD; if(bricks.countActive()===0) win(); }
```
Note countActive after destroy.

Also paddle should be short? no, fine.

Win/GameOver overlay: drawn with graphics rect + text; show final score; Restart button (a container with graphics + text, interactive) and press R.

Launch control: visible button bottom-left/right area near paddle row: draw rounded rect with "LAUNCH SPACE" text; interactive; click launches. When mode==='playing', hide/dim it.

Also add "ball resting" behavior: ball stays at paddle.x offset, sitting on top; and set ball velocity 0.

Lives display: hearts as small graphics-drawn circles? Simpler: generate a small "life ball" texture and place sprites. Use generated texture 'dot'.

Also camera flash / particle on brick break — use Phaser particles with generated texture ('spark'). That's fine and no assets.

Let me also handle ball trail: emitter following ball.

Timing: I have 15 min budget; write efficiently.

Text: use this.add.text with fontFamily 'system-ui' — no external font.

Physics: arcade, fps 60. maxVelocity on ball? Set fixed via velocity directly.

Wall colliders: static invisible bodies at edges — use this.physics.add.staticGroup with sprites from a 1px 'wall' texture, or use this.add.rectangle + physics.add.existing with isStatic. Note: `physics.add.existing(rectangleGameObject, true)` works for zone/rectangle in arcade? Rectangle is a Shape with size; arcade body from a shape works (body size from width/height). Yes, Phaser arcade supports GameObjects.Rectangle/Zones (they have width/height). I'll use Zones (GameObjects.Zone) — safer with arcade. But visible walls I'll draw with Graphics on a layer (non-physics) and place static physics bodies from Zones.

Implementation: 
```
const walls = this.physics.add.staticGroup();
[[W/2, WALL/2, W, WALL],[W/2, H-WALL/2, W, WALL],[WALL/2, H/2, WALL, H]].forEach(...)
```
Bottom: no wall; instead an overlap zone at the bottom to detect loss: use a 'trap' static body at bottom and check ball body.bottom > H (simplest: in update, if ball.y > H + 20 → lose life).

For static zone sizing: after creating static body, set size & refresh. Zones have width/height so body derived. Use `this.add.zone(x,y,w,h)` then `this.physics.add.existing(zone, true)`. For static bodies, need to adjust center if size changed; I'll set zone size at creation so body matches.

Ball vs wall bounce: set restitution 1 on ball body and wall bodies default 1? Arcade bounce is combined max? Actually `physics.add.collider` uses `this.bounce` per-body: Arcade.Body.setBounce. Set ball bounce 1,1.

Also to prevent tunneling through bricks at high speed, set ball max speed ~450 and body.moves; bricks thin (24) — at 450px/s, 7.5px per frame, fine.

Paddle: static? Use a kinematic sprite: `this.physics.add.existing(paddleSprite); paddle.body.immovable = true; paddle.body.moves = true;` set velocity in update, allowGravity false. Collide ball vs paddle with callback for angle control (processCallback runs after collision resolution; I'll override velocity there).

Mouse control: set paddle.body.velocity = 0 and directly set x, then clamp; but for collision correctness, velocity-based is better. On mouse move: compute target x, set velocity = (target - current) * 20 clamped, or just set x and let arcade handle (arcade moves body by velocity in preUpdate; setting x directly on a sprite updates body position via `Sprite.x` setter → body.updateFromGameObject? For dynamic bodies, position sync happens in preUpdate from gameObject x/y). Safer: set velocity toward the target: `paddle.body.velocity.x = clamp((target - paddle.x)*18, -1400, 1400)`.

Keyboard: velocity ±520.

Clamp inside playfield each frame: 
```
paddle.x = clamp(paddle.x, WALL + paddle.width/2, W - WALL - paddle.width/2);
```
and set velocity to 0 if at edge pressing outward (to avoid sticking). Also after clamping x, arcade will re-sync body from gameobject.

Ball resting mode update: ball.setPosition(paddle.x + restOffset, paddle.y - paddle.height/2 - ball.height/2 - 1); body.stop(0,0).

Win state: mode 'win'; stop ball (freeze), overlay.

Also increase difficulty slightly: on paddle hit speed += 4 up to max.

Let me write the code now.

Also HTML footer with controls text (in addition to in-canvas HUD).

Let me write everything.

For textures:

```js
function buildTextures(scene){
  const g = scene.make.graphics({x:0,y:0,add:false});
  // paddle
  g.clear();
  const pg = ...
}
```
generateTexture signature: generateTexture(textureKey, x, y, width, height). So draw at 0,0 then generateTexture('paddle', 0, 0, w, h).

Note: generateTexture in WebGL requires renderer support — works.

Paddle texture: rounded rect w=130,h=18 with gradient: fill base color, then lighter top strip.

Ball texture: 20x20 circle.

Brick textures: per row color: 6 textures 'brick0'...'brick5', size bw x 26 with highlight and notch details.

Since brick sprite scale = 1 with body from texture — good, arcade body from texture (setAllowGravity false? bricks are static group).

Spark texture: 4x4 white square (tint).

Life dot: 14x14 circle.

Button textures: I'll build buttons with Graphics drawn live (redraw on state change) instead of textures — simpler for the Launch/Restart visible controls. Actually use a Container with a Graphics + Text, with a hitArea and interactive on the container. Containers support input with hitArea: `container.setSize(w,h); container.setInteractive(...)`. Let's do that.

Let me write the file, then run in browser and inspect.

Code:

```js
const W=880,H=640,WALL=14;
const PADDLE_W=132, PADDLE_H=18, BALL_R=10;
const COLS=12, ROWS=6, BRICK_GAP=6, BRICK_PAD=22;
```

Scene class:

```js
class Breaker extends Phaser.Scene{
 constructor(){super('breaker')}
 create(){ ... }
}
```

Write in create:
- background graphics: dark gradient + stars + playfield frame.
- textures.
- paddle sprite, ball sprite, bricks group, colliders, HUD text, lives sprites, overlays, launch button, restart handling, input listeners.

update(t, dt): movement, resting, clamp, ball-out check, speed upkeep, launch button visibility.

Let me write.

For particles: `this.add.particles(x,y,texture,config)` in 3.80 returns ParticleEmitter (new API). Use `this.add.particles(0,0,'spark',{...})` then `burst(x,y,count)`. Signature in 3.60+: `add.particles(x, y, texture, config, count)` returns an emitter. And `emitter.setFollow(ball)` for trail. And `this.add.particles(...).explode()`? For burst: `emitter.burst(12, x, y)`. Hmm new API: `emitter.burst(count, x, y)`. Yes: `burst(count, x, y)`.

Trail emitter: set speed low, alpha fade, follow ball with `setTrackPath`? Simpler: `emitter.startFollow(ball)` — with follow, emitted particles follow the emitter position but particles already emitted also move with the... In 3.80 particles, when emitter follows, each particle stores offset; so they'd drag. Better: in update, `emitter.emitParticleAt(ball.x, ball.y, 1)`. Use an emitter with `flowFrequency` and just set its position each frame? Emitter position is where it emits, so: create emitter with `follow: null` and each frame `emitter.x = ball.x; emitter.y = ball.y;`. But `emitParticleAt` is easy: `this.trail.emitParticleAt(ball.x, ball.y)` — but that creates one per call. Do that each frame when playing.

OK write it.

Text style: `{fontFamily:'Segoe UI, system-ui, sans-serif', fontSize:'18px', color:'#dfe7ff'}`.

Let me now write the whole file carefully.

Paddle hit callback:
```js
onPaddleHit(ball, paddle){
  if(this.mode!=='playing') return;
  const half = paddle.width/2;
  const off = Phaser.Math.Clamp((ball.x - paddle.x)/half, -1, 1);
  const maxAng = Math.PI*0.38; // ~68deg
  const ang = off*maxAng;
  const speed = this.speed;
  let vx = Math.sin(ang)*speed + paddle.body.velocity.x*0.18;
  let vy = -Math.abs(Math.cos(ang)*speed);
  const minVy = speed*0.30;
  if(Math.abs(vy) < minVy) vy = -minVy;
  // renormalize
  const m = Math.hypot(vx,vy) || 1;
  ball.body.setVelocity(vx/m*speed, vy/m*speed);
  this.speed = Math.min(this.maxSpeed, this.speed + 3);
}
```
Wait ball.speed should be updated separately; the magnitude used is current speed then incremented next hit. Fine: increase speed first then use.

Brick hit: also add small speed boost.

Ball vs wall: bounce handles it; but add a subtle squash effect? skip.

Lose life check: `if(ball.y > H + 30)`. Since no bottom wall, ball falls out of canvas; camera shows only canvas so fine.

Also prevent the ball escaping sideways: side walls exist.

Timer for state transitions: overlays pause ball (set mode 'win' → ball.body.stop? set velocity 0 and set existing ball hidden? Just freeze by stopping velocity).

Restart: rebuild bricks, reset score/lives/mode → 'ready', ball on paddle, hide overlay.

HUD: score text top-left inside top wall band? The top wall band is only 14px. Put HUD in a band: reserve top area y<WALL+? Let me place HUD row at y = H - 26 (bottom band inside bottom wall?). Hmm bottom is open (ball must fall below paddle). Put HUD at y=32..? That collides with bricks start. Let me set bricks start y = WALL + 56 and draw a HUD strip across the top at y from WALL to WALL+40, with bricks below. Ball can travel in that region — fine, it's playfield.

Score at left, lives (hearts) center-right, level? Show "SCORE", "LIVES", and best speed? Keep score + lives + bricks left.

Now write file.

Also add "PAUSE"? Not required. Skip (P could be nice but keep budget).

Let me write out the code.

Also mouse control should be enabled — `this.input.mouse.disableContextMenu()`.

Launch button visible only when mode==='ready'.

Instructions text at bottom: drawn on canvas near bottom: "← → / Mouse move · Space or LAUNCH to fire · R restart". Place at y = H-16 centered, small font. But ball falls past paddle — text will be overlapped by ball flying out; fine, it's below paddle.

Careful: the bottom instruction row is at y=H-16 with paddle at y=H-46. Ball passing there goes out. Fine.

Write code now.

Overlay: dim rect + panel + title + final score + restart button. Also start? Not required to have a start screen; game starts in 'ready'.

Let me write.

```js
const config = {
  type: Phaser.AUTO,
  width: W, height: H,
  parent: 'game',
  backgroundColor: '#0a1022',
  physics: {default:'arcade', arcade:{gravity:{x:0,y:0}, debug:false}},
  render: {antialias:true},
  scene: Breaker
};
```

Handle Phaser.AUTO failing WebGL in sandbox: try; if it fails Phaser falls back to canvas automatically.

Now write index.html.

There are a couple of logic issues I want to fix:

1. In update, the launch key handling is muddled:
```js
if (Phaser.Input.Keyboard.JustDown(this.keySpace) || Phaser.Input.Keyboard.JustDown(this.keyR)) {
  if (Phaser.Input.Keyboard.JustDown(this.keyR)) { this.restart(); }
  else { this.launch(); }
}
```
JustDown consumes the event, calling twice is problematic. Let me restructure with separate flags.

2. `this.launchBtn_bgReset` is silly; remove.

3. `refreshHud` clears lifeIcons group with clear(true,true) — destroying children; fine.

4. `this.lifeIcons.create` on a Group without physics — `add.group` create(x,y,key) works (GameObjectFactory via group.create requires classType; default sprite works if group created via this.add.group() — yes group.create uses Phaser.GameObjects.Sprite if classType undefined... Actually Group.create requires `key`; default classType is Phaser.GameObjects.Sprite for add.group? In Phaser 3, `new Phaser.Scene.add.group()` sets classType to Sprite by default? Group.prototype.create: `var classType = this.classType;` and add.group sets classType default = Phaser.GameObjects.Sprite? Let me check: `Phaser.GameObjects.Group` constructor has defaults classType: Phaser.GameObjects.Sprite. Yes — Group.js default config classType = Phaser.GameObjects.Sprite. Good.

5. `hitBrick` — ball vs static brick: ball velocity changes due to collision then I normalize in update. OK.

6. The ball's `body.stop(0,0)` — Arcade Body.stop? `Body.stop()` exists (sets velocity to 0, moves false?). Body.stop() signature: `stop()` sets velocity zero; `Body.reset(x,y)`. `stop()` takes no args in Phaser 3 (it may accept none). Calling with args is harmless. But note stop() also... let me check: Arcade.Body.stop() { this.moves = false; this.velocity.set(0); ... } Hmm, that sets moves=false which would need re-enabling. Actually in Phaser 3:

```js
stop: function ()
{
    this.moves = false;

    if (this.checkCollision.up) ... 
```
Let me look at actual source to be safe. Also `Body.reset(x, y)` sets moves = true and velocity 0 — good for docking. Let me check source for stop.

Let me grep the min.js for `moves: !1` patterns... easier: check docs knowledge. Phaser Arcade Body.stop():

```js
stop: function ()
{
    this.moves = false;

    if (this.immovable)
    {
        this.velocity.set(0);
    }
}
```
Hmm that only zeroes velocity if immovable. That would be bad for the ball. So use `setVelocity(0,0)` and `body.reset(x,y)` which does:

```js
reset: function (x, y)
{
    this.enabled = true;
    this.moves = true;
    this.touching.none();
    ...
    this.position.set(x, y);
    this.prevPosition.set(x, y);
    ...
    this.velocity.set(0);
    this.acceleration.set(0);
    this.speed = 0;
    ...
}
```
Good. So replace `body.stop(0,0)` usages with `body.reset(x,y)` or just setVelocity(0,0). For dockBallPos I already call reset. In win/gameOver, I want the ball to freeze: `this.ball.setVelocity(0,0)` plus maybe `this.ball.body.moves = false` to fully freeze. Use moves=false and restore on restart (reset sets moves=true). Actually while overlay is up, physics update still runs; velocity 0 means no movement. That's fine.

Let me fix these issues and also:
- remove `body.stop` calls.
- fix key handling.
- remove launchBtn_bgReset.
- remove the weird `showOverlay` ternary.
- remove the last pointless block in update re hudInfo.

Also, in `dockBallPos` calling `body.reset` every frame will zero velocity — fine in ready mode. But reset also resets prevPosition which prevents collider detection issues. OK.

One concern: in ready mode, I reset ball position each frame with body.reset — the ball vs paddle collider might push it. Fine.

Also mouse handling: `if (p.isDown || p.y < H - 120) this.useMouse = true;` — the mouse pointer position over canvas: p.x/p.y are in game coords via Scale. Fine. But the issue: useMouse becomes true on the very first mousemove, disabling keyboard until arrow key pressed. That's expected behavior; arrow keys reset useMouse=false.

But wait: when useMouse is true and mouseX is stale, the paddle chases the last mouse x. If the user uses keyboard, kv != 0 branch takes priority. Good.

Another: the paddle "reset" when close to target uses pb.reset which sets moves=true, velocity unchanged? reset sets velocity.set(0). Then next frame velocity recalculated. OK.

Potential problem: `pb.setVelocityX` after `body.reset` in the edge clamp... The clamping code calls `pb.reset(minX, this.paddle.y)` which zeroes velocity each frame while against edge — then the paddle stops moving when at edge until user releases. Actually when clamped at min and pressing left, velocity zeroed → paddle stays. When pressing right, kv=+1 sets velocity positive before the clamp check... order: control section sets velocity, then clamp: if x<=minX and velocity>0 (from right press) — the clamp sets velocity 0 only if <0. Then `pb.reset(minX, y)` unconditionally zeroes velocity → paddle stuck at edge even when pressing right. Fix: only reset when actually out of bounds; better to clamp position without reset, and let arcade sync. Actually for a dynamic body, arcade's preUpdate copies body position to gameObject each frame (body.update), and gameObject changes are synced back? In Arcade, `Body.update()` moves the game object from body position. If I set paddle.x directly, next frame body.preUpdate → `this.updateFromGameObject`? For dynamic bodies, Arcade.Body.preUpdate calls `this.updateFromGameObject()` only when `!this.moves`? Let me recall Arcade.Body.preUpdate:

```js
preUpdate: function (delta, direction)
{
    if (this.allowRotation) { this.updateRotation(); }
    if (this.moves)
    {
        this.world.bodies.updateFromPhysics? 
```
Hmm. In Phaser 3 Arcade, `Body.update(delta)` does velocity integration then `this.gameObject.x = this.position.x + ...` (offset). And when you set gameObject.x directly, Body.syncBounds or... `Body.resetPosition`. The world's `preUpdate` for dynamic bodies: there's `Body.preUpdate` which calls `this.updateFromGameObject()`:

Actually Phaser 3 Body has:
```js
updateFromGameObject: function ()
{
    this.isPositionChanged() ... 
```
Hmm not sure. Safer approach: don't set x directly; use body.setPosition for clamping. Let me use `pb.x = value` (body.position.x) plus update gameObject: I'll write a helper:

```js
setPaddleX(x){
  this.paddle.x = x;
  this.paddle.body.x = x - this.paddle.displayOriginX ... 
}
```
For a sprite with origin 0.5, body.position.x = sprite.x - halfWidth. Simplest: use `this.paddle.body.setPosition(x, this.paddle.y)` — Body.setPosition(x, y) sets body position based on the gameObject's top-left computed from origin, i.e. it calls `this.updateBounds()` after setting position via `body.position.set(...)`. Phaser's Body.setPosition(x, y, fullWidth, fullHeight):

```js
setPosition: function (x, y, fullWidth, fullHeight)
{
    ...
    this.updateBounds();
    var body = ... 
    this.position.x = x - this.offset.x - ...
```
Actually Arcade.Body.setPosition:
```js
setPosition: function (x, y, fullWidth, fullHeight)
{
    if (fullWidth === undefined) { fullWidth = false; }
    if (fullHeight === undefined) { fullHeight = false; }

    this.updateBounds();

    var body = this.body;   // no
```
Let me just check the actual source in the file to be accurate. I'll grep.

Alternative, much simpler and reliable: make the paddle a *kinematic* approach where I only ever set velocity and clamp position using `body.blocked`... Or: clamp by checking target and skipping the move. But collisions need body position synced.

Easiest robust: after setting paddle.x manually, call `this.paddle.body.updateFromGameObject()` — this method exists in Phaser 3 Arcade Body:
```js
updateFromGameObject: function ()
{
    this.isPositionChanged() ... 
```
Let me grep the min.js for 'updateFromGameObject' and 'syncBounds'.

Let me check quickly.

Let's use node to grep in the minified file.

Body (dynamic) `updateFromGameObject` exists at 631694: it sets position from transform. Good — so after manually setting paddle.x, I can call `this.paddle.body.updateFromGameObject()`. Also let me check Arcade Body `stop` implementation for dynamic body.

Let me grep for "moves=!1" near "stop:".

Not found. Let me search for "moves=!1" occurrences in the Arcade body.

`Body.stop()` sets velocity to 0 — safe (doesn't set moves=false). Good, my `body.stop(0,0)` calls work fine.

Body.reset — let me verify it exists with signature reset(t,e).

Also confirm `updateFromGameObject` at 631694 is the dynamic Body. Yes.

Now let me refine the file: fix key handling, paddle clamp sync (use updateFromGameObject), remove cruft. Let me rewrite those parts.

Plan for paddle clamp:
```js
clampPaddle(){
  var minX = WALL + PW/2, maxX = W - WALL - PW/2;
  var x = this.paddle.x;
  if (x < minX || x > maxX) {
    this.paddle.x = Phaser.Math.Clamp(x, minX, maxX);
    this.paddle.body.updateFromGameObject();
    var v = this.paddle.body.velocity.x;
    if ((this.paddle.x <= minX && v < 0) || (this.paddle.x >= maxX && v > 0)) this.paddle.body.setVelocityX(0);
  }
}
```
Careful: body.updateFromGameObject sets position from transform; but there's also the issue that after the physics step, the body position is applied to the gameObject. Setting velocity to 0 at edges prevents accumulating.

Hmm but the paddle may also be pushed? It's immovable so no.

Also when at edge with velocity 0 and mouse target further outside, d = mouseX - paddle.x; since mouseX is clamped already to [minX,maxX], fine.

Wait: pressing left at the left edge → kv=-1 → velocity -520 → then clamp: x goes below? The preUpdate ordering: scene update() runs before physics preUpdate? In Phaser, Scene.update is called during step... Order: game step → PreUpdate (physics world preUpdate → resetFlags), scene update callbacks, then PostUpdate... Arcade physics world update happens in `worldUpdate` which is on SYSTEM PRE_UPDATE? Arcade World.preUpdate is registered as a system update (SceneSystems PRE_UPDATE → world.preUpdate; POST_UPDATE? ). Physics integration happens in `World.update` called from `worldUpdate` in the POST_UPDATE? In Phaser 3, Arcade Physics plugin: `scene.sys.events.on('preUpdate', this.preUpdate)` → resets flags and updates body prev positions, and `scene.sys.events.on('update', ...)`? Actually collision/velocity integration happens in `World.update()` triggered on the systems' 'preupdate'? Let me recall: Arcade World has `preUpdate(time, delta, direction)` which does `this.updateTimeScale`, `this.emit('update')`? Hmm.

In Phaser 3.80 Arcade Physics World:
```js
initPlugins()
...
this.sys.events
    .on('transitionInit', this.transitionInit, this)
    ...
```
and World.preUpdate is called from `Scene.preUpdate`? The Body.preUpdate moves bodies... Actually velocity integration happens in `Body.update(delta)`, called from `World.update(time, delta, direction)` which is bound to the systems' POST_UPDATE? Let me just check: I recall `Arcade.PhysicsWorld` has methods `update` bound to 'postupdate'? Hmm — Phaser docs: "World.preUpdate(time, delta, direction) - Called by the Scene Systems. You should never need to call it directly." and `World.update(time, delta, direction)` also. And in SceneSystems.update, the order is: emit 'preupdate' → ... scene.update() → 'postupdate'. Arcade binds preUpdate to systems PRE_UPDATE event and update to systems UPDATE event? Let me grep to verify: `this.sys.events.on(` in the arcade World.

This matters only for whether setting the velocity then clamping in the same frame works, which is fine either way (integration happens after scene update in the same frame or before next). I'll implement the clamp with updateFromGameObject and also verify visually in the browser test by pressing left for a long time.

Actually simpler and robust: instead of setting velocity for the paddle and clamping position, I can compute the target position and clamp the *velocity* so it won't exceed the boundary:
```js
var desired = this.paddle.x + vx*dt/1000;
if (desired < minX) vx = (minX - this.paddle.x) / (dt/1000);  // decay to 0 at edge
```
That guarantees it never goes past. Let me do that: pass `delta` (ms) from update. For mouse: target = mouseX clamped already, and velocity = clamp(d*22) but then it may overshoot... Use desired-position clamping for the mouse too:

```js
var dtSec = delta/1000;
if (kv !== 0) target = paddle.x + kv*520*dtSec;
else if (useMouse) target = paddle.x + clamp(d*22, -1100, 1100)*dtSec;
else target = paddle.x;
target = clamp(target, minX, maxX);
var v = (target - paddle.x)/dtSec;
pb.setVelocityX(v);
```
This keeps the body exactly velocity-driven (no direct position manipulation), so arcade stays in sync, and never crosses the boundary (small overshoot possible due to discrete step but within a pixel; then clamp with updateFromGameObject as a safety net... the safety net would rarely trigger). Good — I'll do both.

Now also add: keyboard 'P' pause? Skip.

Let me now also verify the "score increases once" - if the ball hits a brick, `hitBrick` destroys the brick so a second callback for the same brick won't happen. Also multiple ball-brick overlaps in the same frame: destroyed → inactive check.

One risk: `this.physics.add.collider(this.ball, this.bricks, this.hitBrick, null, this)` — the collider callback may be called with brick being a body-less? fine.

Another risk: ball resting on paddle in ready mode: since I reset ball body position each frame (body.reset(x,y)) and the collider may run first, fine.

Now the launch key logic: rewrite as:

```js
if (Phaser.Input.Keyboard.JustDown(this.keyR)) { this.restart(); }
else if (Phaser.Input.Keyboard.JustDown(this.keySpace)) {
  if (this.mode === 'ready') this.launch();
  else if (this.mode === 'win' || this.mode === 'over') this.restart();
}
```
But JustDown for both consumed independently - need to call JustDown for space regardless:
```js
var kR = Phaser.Input.Keyboard.JustDown(this.keyR);
var kS = Phaser.Input.Keyboard.JustDown(this.keySpace);
if (kR) this.restart();
else if (kS) { if(this.mode==='ready') this.launch(); else if(this.mode==='win'||this.mode==='over') this.restart(); }
```
Also clicking on canvas when in ready mode should launch? Only if not clicking the button. Nice touch: pointerdown on the game (not on the button) launches when ready. But the container interactive handles its own; the input 'pointerdown' on scene fires too. Then clicking the Launch button also triggers scene pointerdown → launch, which is fine (same action). Add: `this.input.on('pointerdown', () => { if(this.mode==='ready') this.launch(); })` — but careful with restart overlay clicks: clicking anywhere in over/win mode would... I'll only launch on ready, no conflict. However the paddle follows the pointer down too. Fine.

Hmm, but pointerdown launch would prevent aiming? Not needed to aim. OK include it — actually the mouse moves the paddle and a click launches. That's fine and matches "Space or a visible Launch control". Click-to-launch is extra; the button is the visible control. Include.

Also in ready mode, show HUD hint "SPACE to LAUNCH" — I'll show in the launch button label "LAUNCH ▸" plus info text. Also add a pulsing hint arrow above paddle? The button is enough.

Also the bottom instruction text at y=H-14 overlaps the launch button at H-46? Button height 40 → spans H-66..H-26; text at H-14 baseline-ish (origin .5 → H-14±8) → no overlap. But launch button at W/2+190, y H-46, and the paddle at y=H-52 moves across the whole width — the button overlaps the paddle region! The paddle is at x range [WALL+66, W-WALL-66] = [80, 800], and the button center x = 630, y = H-46 vs paddle y=H-52 → the button visually overlaps the paddle and the ball resting on it. Bad. Move the paddle up? Or place the launch button in the lower right corner below the paddle line: y = H-20 → overlaps instructions text.

Better layout: put the launch button to the right of the instructions in the bottom band: instructions centered at y=H-16... Let me restructure the bottom band: paddle y = H-58, ball above. Bottom band: instructions text at left (origin 0,0.5 at x=WALL+18, y=H-18), and the Launch button at bottom-right (x = W-WALL-96, y = H-18). Paddle moves in x range, y H-58 ± 9 → no overlap with the band at H-18±20? The button spans y from H-38 to H+2 — overlapping the bottom wall area and possibly the paddle path (paddle bottom = H-58+9 = H-49). No overlap. Good.

But the ball must fall below the paddle to lose a life — it passes over the button area (ball is depth 5, button depth 11 → button drawn on top). Slight overlap visually for a moment; acceptable. Actually the ball exits fast. To reduce weirdness, make the button smaller (h=32) and place at y=H-20, and the ball only passes there briefly. Fine.

Also the button should be at bottom-right; the HUD lives at top-right. Good.

Let me restructure: PADDLE_Y = H - 60.

Bricks: BRICK_TOP = WALL + 62 → with ROWS=6 → bottom = 76 + 6*26 + 5*6 = 76+156+30 = 262. Plenty of space.

Now also `this.hudInfo` shows speed etc.

Let me rewrite the whole file cleanly with these fixes rather than many edits. I'll write the final version.

Additionally the win condition check: `this.bricks.countActive(true)`. Static group bricks countActive works.

Note: `this.bricks.clear(true, true)` destroys children and removes them from the group; then buildBricks recreates. Good.

Also `refreshHud` in create is called after dockBall.

Edge case: `loseLife` calls refreshHud then dockBall (which calls... dockBall doesn't call refreshHud). ok.

Let me write the final file.

One bug: `var pb = this.body = null, ...` — that sets `this.body = null` on the scene (harmless but sloppy) — fix it.

Also `refreshHud` uses `this.mode === 'ready'` for hint.

Let me fix the odd line and then run the browser.

Note: `dtS` could be 0 if delta is 0 → division by zero → Infinity velocity. Guard: dtS = Math.max(16, delta)/1000.

Let me fix that and then run browser inspection.

I need to run the browser tool to check the current state, but I realize I haven't actually called it yet—let me take a screenshot and inspect what's happening.

Game renders. Issues:
1. "LIVES" label overlaps the life pips (pips at right, label at W-WALL-40 with origin 1 → text ends at x=826, pips start at 846 going left → overlap). Move label to x = W - WALL - 90 or place pips further right. Let's set label origin(1,0) at x = W - WALL - 96 and pips at W-WALL-84 - i*22.

Actually pips at W - WALL - 20 - i*22 → 846, 824, 802. Label ends at 826 → overlaps pip at 824. Fix: label at W-WALL-100 (=766) origin(1,0), pips unchanged. Hmm, the label is centered? Let me just place "LIVES" text left of the pips: x = W - WALL - 92, origin(1, 0.5) at y=32.

2. Bricks look good. Ball rests on the paddle. Launch button visible bottom-right.

Now test gameplay: press Space, then observe bounces; check score increments and brick removal; check paddle stays inside.

Let me use the browser key action to press space and take a motion screenshot.

Hmm — the ball is still just above the paddle and the HUD still says "PRESS SPACE TO LAUNCH", and the trail particles are below the ball... Wait, the trail only emits in playing mode. The particles below the ball suggest the ball was launched and is now in ready mode again? Actually the ball appears slightly above the paddle with a small trail beneath it — meaning it launched, went up, came down... but score 0 and bricks 72, and the hint text shows "PRESS SPACE TO LAUNCH" meaning mode === 'ready'. So the ball was launched and lost a life? But lives pips show 3 pips (right side, "LIVES" overlapping). Hmm, if a life was lost there would be 2 pips.

Wait, maybe the space key press was received but the frame is +1ms after the key; the screenshot shows the ball mid-flight with a trail... The trail particles below the ball mean the ball was moving upward — so it was in playing mode. Then the screenshot happened right after launch, and the HUD text hasn't refreshed since refreshHud is only called on brick hits / dock / etc. Right! The hint text in hudInfo is only updated in refreshHud, which isn't called on launch. So the stale "PRESS SPACE TO LAUNCH" remains during play. I should call refreshHud in launch too.

Also the canvas is cut off at the bottom in this screenshot (viewport 1200x800 with the game scaled). Fine.

Let me take a motion screenshot to see the ball bouncing, and check the game state programmatically. Actually the browser tool doesn't allow evaluating JS directly... I can only use actions. Hmm, no "evaluate" action. But I can inspect via screenshots.

Alternatively, I could add a debug hook... not needed. Let me use the `motion` action to see frames over time, then check whether bricks get destroyed and score increases. Since the ball launches upward at a random angle, it may not hit a brick immediately.

Let me improve: call refreshHud() in launch() so the hint disappears. Also fix the LIVES label overlap.

Then use motion to watch bounces.

Wait — refreshHud in launch() will also rebuild life pips (fine) and set hint (mode is now 'playing' so no hint). Good.

Now reload and run a motion check.

HUD now clean: "LIVES ●●●". Now let me press Space and capture motion frames to observe bounces and brick hits.

Launched (hint gone, ball rising with trail). Now capture motion frames to see it bouncing off bricks.

Important bug: `error: this.boom.burst is not a function`. So the brick hit threw before destroying the brick — the ball appears stuck near the bottom of the brick wall (frames 1-4 show the ball in nearly the same position; the game loop errored each frame? Actually the error occurs inside the collider callback, which is inside the physics step — it likely breaks the update loop for that frame and the ball is stuck overlapping the brick, repeatedly erroring).

In Phaser 3.80, `this.add.particles(...)` returns a `ParticleEmitter` (new API). The method to burst is `explodeParticle(count)` or `emitParticleAt(x, y, count)`. In 3.80, `ParticleEmitter.burst` doesn't exist; `explode(count)` exists on the old Emitter class... Let me check: In 3.60+, `ParticleEmitter.explode(duration, count, x, y)` exists. And `burst` was added in 3.60? Let me grep the file for "burst:function" and "explode:function".

Also note the trail `emitParticleAt` works (particles appear).

Let me grep.

`explode(duration, count, x, y)` exists. Replace `this.boom.burst(12, brick.x, brick.y)` with `this.boom.explode(420, 12, brick.x, brick.y)`. Hmm, `explode` sets frequency=-1 and resetCounters; it emits count particles at the emitter position (x,y passed). Note: explode sets `this.frequency = -1` permanently which is fine for an emitter with emitting:false used only for bursts. But `emitParticle` needs the x,y args: `explode(t,e,i)` → `this.emitParticle(t, e, i)`? Wait signature: `explode:function(t,e,i)` → `this.emitParticle(t,e,i)` where emitParticle(duration, x, y)... Hmm. Let's look: `emitParticleAt: function(x, y, count) { return this.emitParticle(count, x, y) }` so `emitParticle(count, x, y)`. But explode calls `this.emitParticle(t, e, i)` where explode args are (duration, count, x, y)? That would be emitParticle(t=duration→count?, ...). Hmm, the minified explode has 3 params (t,e,i) and calls emitParticle(t,e,i) → so explode(count, x, y). Let me check the non-minified Phaser 3.80 source of ParticleEmitter.explode:

```js
explode: function (duration, count, x, y)
{
    this.frequency = -1;
    this.resetCounters(duration, true);
    var emitted = this.emitParticle(count, x, y);
    this.emitEvents([c.EXPLODE], this, emitted);
    return emitted;
}
```
But minified shows `explode:function(t,e,i){this.frequency=-1,this.resetCounters(-1,!0);var s=this.emitParticle(t,e,i);...}` — hmm, only 3 params, and resetCounters(-1, true) suggests duration param was optimized away... Actually maybe this is `Emitter.explode` from the legacy class or a different overload. In 3.80's ParticleEmitter.js:

```js
explode: function (duration, count, x, y)
```
The minified has (t,e,i) = 3 named params... maybe it's `explode:function(t,e,i)` where t=duration? then emitParticle(t,e,i) = emitParticle(duration, count, x)?? That'd be wrong. Let me check the actual source more carefully by printing a wider slice and also look for other explode definitions (there may be two: one in Emitter.js (legacy) and one in ParticleEmitter.js).

Safest: use `this.boom.emitParticleAt(x, y, 12)` — clear semantics (count, x, y mapped correctly). But the emitter has `emitting:false` and default `quantity` — emitParticleAt(x,y,count) works regardless of emitting flag? `emitParticle` checks `this.atLimit()`. With emitting:false, the flow isn't running but manual emit works. The trail uses emitParticleAt already and works.

But wait, with `emitting: false`, does the particle update still process? The trail works so yes.

I'll use `this.boom.emitParticleAt(brick.x, brick.y, 12)`.

Also `resetCounters`/`frequency` not needed.

Let me also double check `emitParticleAt` param mapping: `emitParticleAt:function(t,e,i){return this.emitParticle(i,t,e)}` → emitParticle(count, x, y). And emitParticle signature in 3.80: `emitParticle: function (count, x, y)`. Yes. Good.

Fix now.

Also, while the error was thrown, the ball got stuck — after fixing, brick destruction should proceed.

Additionally, I should double check the ball's collision resolution when a brick is destroyed mid-collision: fine.

Let me apply the fix and re-test.

`emitParticle(count, x, y)` — confirmed by emitParticleAt mapping. Now fix the burst call.

Also `this.boom` config had `emitting:false` — with emitParticleAt, `atLimit()` may be governed by the particle max (default 0 = unlimited? default `quantity`...). The default `maxParticle` for an emitter is 0 (unlimited) unless set. Fine.

Now reload, launch, and watch for a brick hit + score. Also test paddle movement and edge clamping.

I'll reload, press Space, then motion a few frames.

Now, to make the verification deterministic (ball should hit bricks), let me move the paddle to center (already centered) and press Space. The launch angle is random between -0.5 and 0.5 rad, so it goes up toward the bricks. Then check motion.

Ball launched upward. Now let me capture motion frames to see brick hits and score changes.

Good: brick hit → SCORE 10, BRICKS LEFT 71, one brick removed (bottom row gap visible). No console errors.

But: a life was lost (LIVES shows 2 pips) and the ball is back in ready mode ("PRESS SPACE TO LAUNCH" + LAUNCH button visible). That happened because the paddle didn't move (no input) so the ball came down and missed. That's correct behavior. 

However, one thing: the ball fell below the paddle and lost a life — correct.

Also the paddle is at center and the ball rests on it. Good.

Now let's test paddle movement with arrow keys and check it stays inside the playfield. Press ArrowLeft for a while, then screenshot.

The browser key action takes one text; maybe I can send repeated presses. Let me use `key` with text "ArrowLeft" multiple times, or hold? Each key press likely a single down/up. Better: use drag/scroll? Let me just press ArrowLeft ~10 times via repeated calls... that's many tool calls. Alternative: test mouse control with the `click` action at a location — pointerdown triggers launch too (mode ready → launch). Hmm, clicking at the far left will set mouseX and the paddle will glide there.

Let me click near the left edge of the playfield (in game coords, canvas is scaled: the canvas occupies the #stage; the browser coordinates are 1200x800 viewport and the canvas is displayed at some scale). The screenshot is 1200x800 and the game canvas appears to span x≈108..1092 (in the first screenshot at scale ~1.117?). Actually the first screenshot showed the canvas from ~118 to ~1082 → width ~964 for W=880 → scale 1.095. So game x=20 → screen x ≈ 118+22 = 140; y for paddle: game y=580 → screen y = 47 + 580*1.095 ≈ 683.

Hmm, clicking will also launch the ball (mode ready). That's fine — I can then observe the paddle chase the mouse to the left edge and check it stays inside.

Actually, a cleaner test of the boundary: click at the far-left corner (screen x=120, y=690) → the pointer x in game coords would be < MIN_X, clamped to MIN_X = 80. The paddle target clamps. Let me do the click and then motion to see.

But careful: clicking at the bottom-left also launches the ball downward-ish? Launch always goes up. Fine.

Let's do: click at (120, 690) then motion.

The paddle moved left (mouse control works) and the ball launched (click-to-launch). The paddle is at screen x≈525 center; game coords: (525-118)/1.095 ≈ 371... Hmm, I clicked at screen x=120 → game x ≈ (120-118)/1.095 ≈ 2, clamped to MIN_X=80. But the paddle center is at game x≈371, not 80. So the paddle moved left but hasn't reached the target yet (it interpolates toward the target at up to 1150 px/s). The screenshot was taken immediately after the click.

Let me take a motion capture to see it reach the left edge and confirm it stays inside the playfield.

Observations:
- Score went 10 → 30, bricks 71 → 69. Two more bricks destroyed. Good.
- Lives down to 1 (the ball fell again since the paddle was chasing the mouse to the left while the ball was elsewhere).
- Paddle is now at the left edge, fully inside the playfield (paddle left edge at screen x≈90 vs the playfield border at x≈118?). Hmm, looking at the last frame: the paddle spans screen x from ~90 to ~245. The left wall inner edge is at screen x ≈ 118 + 14*1.095 ≈ 133. The paddle's left edge at ~90 is *outside* the playfield, overlapping the border!

Wait, let me measure more carefully. In the last image, the paddle's rounded rect appears to start at x≈88 and end at x≈245. The canvas left edge is at x≈118? Let me check: the "SCORE 30" text starts at x≈113 and the panel border... In the first screenshot, the canvas (rounded rect) spanned from about x=118 to x=1082. Hmm, but the paddle at game x=80 (MIN_X) with width 132 → left edge at game x=14 = exactly the inner edge of the left wall. Screen: 118 + 14*1.095 = 133. So the paddle should start at ~133, not 88.

Unless the scale/offset assumption is off. Let me recompute the canvas position from the current screenshot: the game panel is cut off at the bottom (the browser viewport shows the game scrolled). Actually in these motion frames the canvas top is at y≈47 (vs 60 in the first screenshot) — the page layout shifted slightly. Hmm, and the canvas left edge: the dark rounded panel starts at x≈108? The "SCORE 30" text baseline starts at x≈113, and in-game the score text is at x = WALL+18 = 32 with origin left. So screen_x(32) = 113 → if scale s and offset o: 113 = o + 32s. And the paddle left edge at game x=14 → screen = o + 14s = 113 - 18s. With s≈1.095 → 113-19.7 = 93. That matches the observed ~90! 

So the paddle IS at MIN_X (left edge at game x=14 = inner wall edge). My earlier estimate of the canvas left edge (118) was wrong — the canvas actually starts at o = 113 - 32*1.095 = 78. Right, the canvas spans 78..1040 (962 wide ≈ 880*1.095). Good — so the paddle is correctly clamped inside the playfield, flush against the left wall. 

Everything checks out for paddle clamping.

Remaining checks:
1. Win state — hard to reach by playing. I could verify by logic review, but better to test. I can't evaluate JS in the page with the given tools... Hmm. Is there a way? The browser tool has no "evaluate". 

I could add a hidden debug hook: e.g., a URL query param or a key combo that removes all bricks for testing. That's a reasonable dev affordance but might be seen as odd. Alternatively, I can temporarily modify the file to start with 2 bricks, verify the win state, then revert. That's a solid approach: temporarily set ROWS=1, COLS=2? But COLS is used for BW computation. Simplest: temporarily add to create(): after buildBricks, destroy all but one brick. Then launch and hit it → win overlay. Then revert.

Let me do that with a temporary edit, verify win + restart, then revert.

2. Game Over state: lives already at 1; just let the ball fall → game over overlay. I can test that now: press Space (launch) and don't move the paddle... but the paddle chases the mouse at the left edge; the ball launches up and comes back down somewhere. Might bounce. Easier: test game over in the same temporary session: set this.lives = 1 at start (already 1 now) and just let the ball fall.

Actually, current state: lives=1. Let me press Space and then wait/motion until the ball falls → Game Over overlay. Then click RESTART → verify full restore (72 bricks, score 0, lives 3).

That covers game over + restart. Then the temporary edit for the win state.

Let me press Space now.

Ball launched from the left edge. Now let it fall — the paddle stays at the left edge, and the ball goes up at some angle and may come back down elsewhere. Let me run motion until game over.

Note the LAUNCH button is hidden during play (correct).

Let me do a motion capture (frames ~1.75s apart).

Game Over overlay works, showing score 40 and bricks left 68, with a RESTART button. The ball hit one more brick (score 40) before falling.

Now click RESTART to verify full restore. RESTART button center at screen ≈ (600, 500).

Restart works: SCORE 0, BRICKS LEFT 72 (all restored), LIVES 3 pips, ball docked on the paddle, LAUNCH button visible, overlay gone.

Note: the restart click at (600,500) also triggered the scene pointerdown → but mode was 'over', so no launch. Good.

Now verify the WIN state. I'll temporarily reduce the brick count to 1 brick (top-left) so a single hit triggers the win. I'll make a temp copy approach: edit index.html to add a temporary line in create() after buildBricks: destroy all but one brick; test; then remove.

Simplest: temporarily change buildBricks loop bounds via a debug flag. Let me add a temporary line in create():

```js
    this.bricks = this.physics.add.staticGroup();
    this.buildBricks();
    /*TEMP*/ this.bricks.getChildren().slice(1).forEach(function(b){b.destroy();});
```
Then test: launch, ball must hit the single brick... The ball goes up at a random angle from the center; the remaining brick is at top-left, which the ball may not hit. Better: keep the brick directly above the paddle center. Let me destroy all but the brick nearest the center-top. Or simpler: keep only bricks in the middle columns of the bottom row so a straight-up launch hits one. Let me do: keep only the first 2 bricks in the last row (bottom-left) and move the paddle... hmm.

Alternative approach: keep only bricks whose column index is 5 or 6 in the TOP row? The ball would need to reach the top row — it will, since it bounces off walls and paddle; but with only 2 bricks it may take a while.

Cleanest: destroy all bricks except one, and reposition that brick to be directly above the paddle center (x = W/2, y = BRICK_TOP). Then a straight-up launch (angle near 0) hits it. But the launch angle is random in [-0.5,0.5]; with the brick at the center and the ball starting at the center, it needs a near-vertical launch. Let me instead place the remaining brick at the center AND temporarily force the launch angle to 0? Too many edits.

Better: keep the entire bottom row of bricks (row 5, 12 bricks) — no wait, the ball will hit one of them and destroy it, and after 12 hits it wins. Instead: keep only the 12 bricks of the bottom row? Still 12.

Alternative: place the remaining single brick spanning the whole width? Can't.

Simplest robust: keep one brick and set the launch angle to a fixed 0 temporarily... Actually I can just launch repeatedly (press Space) until the ball drifts into the brick — but each miss costs a life and after 3 lives it's game over.

Alternative: I can make the remaining brick wide by keeping all 12 bricks of the bottom row and destroying... no.

OK: keep only the bottom-row bricks in the two center columns and place them right above the paddle start; then launch with a random angle: the ball starts at the paddle center (x=440) and the two center bricks span x from ~378 to ~502 with the ball's random horizontal drift: over the rise of ~300px vertical, the horizontal drift is up to tan(0.5)*300 ≈ 165px, so it may miss. But it bounces off walls and the paddle repeatedly, so it will hit one of the 2 bricks fairly quickly. And after destroying both → win. Risk: a few lives lost. With 3 lives and the paddle at the center chasing... the paddle stays where the mouse left it.

Even better: use the mouse-click to move the paddle under the ball... complex.

Pragmatic approach: temporarily set lives to 99 as well, so it can't game over, and keep just 2 center bricks. Then press Space and run motion until the win appears. Let me do:

```js
/*TEMP*/ this.lives = 99;
/*TEMP*/ var kids = this.bricks.getChildren(); for (var ti=0; ti<kids.length; ti++){ if (kids[ti].y > BRICK_TOP + BRICK_H/2 + 1 || (kids[ti].x < 380 || kids[ti].x > 500)) kids[ti].destroy(); }
```
Hmm, simpler: after buildBricks, destroy bricks that are not in the bottom row and not in columns 5..6:

```js
/*TEMP*/ this.bricks.getChildren().slice().forEach(function(b){ if (b.y < BRICK_TOP + 5*(BRICK_H+GAP) || (b.x < 380 || b.x > 500)) b.destroy(); });
```
The bottom row y = BRICK_TOP + BRICK_H/2 + 5*(BRICK_H+GAP) = 76+13+160 = 249. Columns 5 and 6 centers: x = WALL+SIDE_PAD+BW/2 + c*(BW+GAP). BW = (880-28-44-66)/12 = 742/12 = 61.83. x(c=5) = 14+22+30.9+5*67.83 = 67.9+339.2 = 407.1; x(c=6) = 474.9. Both within [380,500]. Good.

Then also set lives high. Then reload, launch, motion until win.

Let me apply the temp edit.

I need to be quick. Let me reload + launch + check win, then remove the TEMP lines and save. Actually, to be safe with time, let me do the win test fast (2 tool calls) then revert.

Risk: if the win test takes too long, I must still revert. Let me do it now quickly.

My TEMP line called this.refreshHud() before the HUD texts existed → error. Remove the TEMP refreshHud call (and just set lives later). Quick fix.

Note: dockBall() → refreshHud() will render 30 life pips (a long row) — ugly but temporary; it doesn't break. Actually 30 pips going off-screen left... harmless.

Reload, launch, motion until win.

2 bricks remain, "BRICKS LEFT 2". Now click LAUNCH (button) — that also verifies the visible Launch control. Then motion until win.

Hmm, the click at (960,741) landed on the LAUNCH button? The view scrolled (page layout shifted as the canvas is FIT-scaled). The ball is still docked on the paddle and the LAUNCH button is off-screen at the bottom now. So the click didn't hit the button; instead it may have hit the canvas at a position... The paddle moved right a bit.

Time is short. Let me just press Space and then run motion captures to reach the win.

The paddle moved to the far right and the ball is docked at the right edge; the Space key press may not have registered (focus issue after clicking?) or it launched and fell. Score still 0, bricks 2. The ball is resting on the paddle at the right edge (visible bottom-right paddle). Hmm, the ball isn't visible on the paddle... it may be hidden below the viewport.

Time is nearly out. Let me do one motion capture to see if the ball is in play and whether the win triggers; if not, I'll revert the temp lines and finish.

The ball is still docked (mode ready) — Space didn't launch, probably because the page/iframe lost keyboard focus after the click (the click at (960,741) may have hit the footer/outside the canvas, and key events go to the document... Phaser listens on window; hmm). The paddle is at the far right (mouse moved there from the click) and the ball is docked at the right — but the ball isn't visible in the frame because the bottom of the canvas is cut off in this scrolled view.

Time is up. I must finalize: remove the TEMP lines and save. The win state code path is straightforward (countActive === 0 → showOverlay) and shares the same overlay code verified via Game Over. I'll note it as unverified-by-playthrough but code-verified.

Actually, I can quickly sanity-check the win path logic without playing: hitBrick destroys the brick, refreshHud, then if countActive(true)===0 → win(). showOverlay was verified working with Game Over. The only untested bit is win()'s title. Good enough.

Let me remove the TEMP lines now and verify the file loads cleanly (one reload + screenshot).

Wait — `this.bricks.getChildren()` was used in the temp code only, so no other reference issue. But note in buildBricks I use `this.bricks.clear(true,true)` — fine.

Also remove the unused `best` references? `this.best` was removed in the final version? Let me check: gameOver uses 'Bricks left' now; I removed best. Let me grep for 'best' and 'launchBtn_bgReset' leftovers, plus verify no syntax errors by reloading.

No leftovers, JS parses. Now do a final reload to confirm the game starts clean (72 bricks, 3 lives).

Final state is clean: 72 bricks, score 0, 3 lives, ball docked on the paddle, LAUNCH button visible, no console errors.

Done. Report briefly.