Space Invaders · hy4

Let me plan the implementation carefully, then write index.html, run browser checks.

We need a playable Space Invaders game on canvas with procedural graphics, single file. Need robust mechanics and test interactions via browser tool. Let me think about design.

Viewport maybe 900x640 canvas with responsive scaling via CSS width min(100%, 900px), internal 900x640. HUD in DOM or drawn canvas? Could use DOM HUD for score/lives/status and controls overlay for easy inspection. Canvas draws aliens, bunkers, cannon, projectiles. For browser inspect, maybe add DOM debug hooks: window.game state object exposing counts, etc. That helps verification. Also can expose test helper functions? Don't overdo; can check state via window.__game. But adding data attributes to HUD helps.

Mechanics:
- Playfield bounds maybe left=30, right=870, top=70, bottom=600.
- Player x at center, width 44, y=560, speed 320 px/s, clamp.
- Shots: player shot array, velocity -520 px/s, fire cooldown 0.28s, max active maybe 3; Space keydown triggers via held logic; prevent default. Enemy shots downward 220-300 px/s, random alien firing, rate ~0.75-1.4s, max maybe 6; life limited by bounds and TTL ~4s.
- Alien formation: 5 rows x 10 cols maybe 50 aliens. spacing 62 x 44, width 36, height 24. Formation bounds computed from leftmost/rightmost alive alien positions; move horizontally speed ~55 px/s increasing as aliens die; reverse and descend 18 when edge reached (classic). We can implement formation offset dx, dy; each alien has col,row base position; position = originX + col*stepX + offsetX, originY + row*stepY + offsetY. For collision with edges use alive alien min/max x. When moving right and maxX + width >= right: reverse direction, offsetY += descent, then clamp x to keep from going over? Need avoid repeated reverse: after descending, if direction flips and edge check with new direction, won't trigger again. Actually classic: if moving right and hit right edge, at next frame direction left, no right-edge check. Good. But offsetX might exceed boundary; can clamp by shifting offsetX to keep maxX within boundary when reversing. And check with left edge similarly. Use function.

Aliens reaching player zone: if any alive alien bottom >= player.y - 8 (e.g. 545) -> game over. Might also check descending. Need also clear aliens win.

Bunkers: 4 at x around 110, 300, 500, 690, y=460. Each bunker composed of destructible small blocks (e.g., 12 cols x 6 rows, cell 6 px = 72x36) with arched shape. Need persistent material and gaps that shots pass through. Represent bunker as grid of booleans; collision with projectile: determine if point crosses cells, find nearest solid cell in path; remove a small cluster/radius around impact (e.g., cells within radius 7-10 px) randomized edges for visual erosion. Need both player shots (moving up) and alien shots (moving down) damage. Use projectile segment from previous pos to new pos to avoid tunneling. For each bunker, iterate cells; find first intersection along direction (top or bottom) with a solid cell; simpler: sample along projectile path at 2px increments, check cell at that coordinate, remove cells within radius and return hit. To let shots pass through gaps, only remove when collision found; if no cell solid, shot passes. For player shots moving up, need check bottommost first; sampling from prev->new naturally does that. For alien shots moving down, samples from prev->new naturally top-down. Good.

Also player shot vs alien collision; enemy shot vs player collision; maybe alien shot vs player shot collision optional. Enemy shot vs bunkers, player shot vs bunkers. Order: check bunker first then aliens? Since alien formation above bunkers, player shot moving upward should hit bunker first; segment sampling order handles both if we do bunker first along entire segment, then alien collision after; risk: shot passes through bunker gap and hits alien in same frame, fine. But if bunker hit found, remove shot. Need compute precise positions. We can use segment iterative collision in unified update for each projectile:
  - prevY = y, nextY = y + vy*dt.
  - Determine earliest t for collision with bunkers, aliens (player shots), player (enemy shots), maybe invader shots? 
Simpler: sample steps along path from prev to next (2-3 px) and at each sample check bunker cells and alien rectangles / player. That handles order by earliest sample. Then remove shot at first hit. Need avoid duplicate destruction: remove projectile immediately (break). Good. dt is capped (<= 0.033 maybe) so steps small; speed ~600*0.033=20 px, 2px steps fine.

Aliens firing: choose alive alien preferably bottom-most in a random column, spawn at alien center bottom. Need ensure shots spawn below formation. Rate scales with remaining aliens? base interval 0.85s, min 0.35s. Max active enemy shots 5. Can have random jitter. Invulnerability 1.4 sec after hit; flash cannon and maybe shield ring. On hit, lives--, remove enemy shot, clear enemy shots maybe? Brief protection from repeated damage; implement invuln=1.5s and e.g. enemy bullets that hit during invuln still pass? Could ignore or remove? To prevent repeated damage, during invuln shots don't cost life; maybe allow them to pass (or remove on contact to avoid visual stacking). Better remove them on contact while invulnerable but no life loss. Also clear enemy shots on life loss to avoid repeated damage. This is fine.

Game states: 'playing', 'gameover', 'win'. Overlay with title, message, button. Restart button always in HUD and overlay button. On restart reset all state incl arrays, formation offset, direction, score, lives, player pos, cooldowns, invuln, overlays. Need pause when not playing (but render still).

Controls display: visible instructions in DOM "← / → or A / D — Move • Space — Fire • R — Restart". Also arrow key prevent scroll. Add touch controls? Not required but nice: buttons for mobile? Could add on-screen buttons with pointer events to move/fire; but user asked Left/Right/A/D and Space. Could include simple touch controls for completeness; careful not clutter. Maybe add controls bar with "◀ ▶ FIRE" buttons for touch, but firing on key required. We'll include touch-friendly buttons below maybe not needed. Since browser tool can dispatch key events or use click.

Need draw procedural graphics:
- Background dark navy with stars generated deterministically (procedural seeded), subtle grid/ground.
- Aliens: pixel art drawn with rects based on row type, two animation frames (legs/eyes), cyan/magenta/violet colors. Could draw using small pixel grids from string patterns. Use canvas fillRect with unit scale. Need no external assets.
- Cannon: triangular/ship shape with barrel, thruster flicker, maybe glow.
- Bunkers: green blocks with slight shading, missing cells show dark.
- Bullets: player bright cyan beam, enemy amber zigzag / pellets.
- HUD: DOM score lives and status. Maybe also draw on canvas for authenticity; but DOM easier for inspect. Could do both. Keep DOM HUD above canvas: score, lives hearts, aliens count, status. Controls displayed under HUD. Overlay on canvas wrapper with semi-transparent panel, restart button. Maybe side panel? Single page layout center.

Need robust keyboard handling: keydown with e.code ('ArrowLeft','ArrowRight','KeyA','KeyD','Space','KeyR'). Set keys set. Ignore repeats for firing? We want fire rate, hold space to auto-fire with cooldown (common). Implement firing in update if keys.has('Space') && cooldown<=0. This gives continuous shots every 0.28s. Also maybe keydown immediate. Browser key tool may send keydown/keyup? Need know browser tool semantics. It has action "key", text likely key name maybe "ArrowRight", " " etc. Could use browser click on canvas then key. Might be easier to dispatch via JS? Browser tool action "key" with text maybe "ArrowRight". Need inspect tool output. We'll find.

We should also add accessibility / focus: window keydown works. ensure canvas focus not required. Also `tabindex=0` maybe.

Need debug hooks for verification:
`window.__game = { get state(){...}, ... }` maybe return snapshot function to inspect. Could expose `window.gameDebug = () => ({...})`. Use browser inspect? Browser action inspect gives DOM/console maybe not arbitrary JS evaluation. There's no explicit evaluate tool listed; browser inspect may return DOM snapshot and console. Could add on-page debug readout in DOM with data attributes showing state counts, and update DOM each frame. E.g. `<div id="debug" class="sr-only"> ... </div>` with `data-player-x`, `data-shots`, `data-aliens`, `data-bunker-cells`, `data-score`, etc. But that's artificial. Maybe use visual HUD for score/lives/aliens and debug line hidden? To verify via screenshot and inspect DOM, we can add `data-*` attributes to HUD or a `<output id="diagnostics">` that shows small telemetry "player x 450 · shots 1 · bunkers 264 blocks" as part of visible UI (looks like instrumentation but okay). Could help verify. Maybe better to include a "status" HUD with aliens remaining and shots; not too odd. The task says display controls, score, lives. We can show aliens remaining too. Need easier to inspect shot hitting bunker/alien for visible damage or score feedback. We can use browser screenshots to see score/damage, and debug display with `data-*`. Also can simulate rapid gameplay via browser key interactions and time; but might be hard to align shot with alien. Could add keyboard shortcuts for test? Not appropriate. Could expose deterministic seed and methods to facilitate? Maybe window.__si = { state, fire(), update? } for debugging. We can use browser action "inspect" maybe includes ability to execute JS? Let's check docs? browser tool description: "Run index.html, inspect DOM/console, interact, and see screenshots or motion frames. Reload after editing." actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No evaluate. But `key` may allow typing text into focused field; `type` maybe. Maybe `inspect` returns DOM plus console; could use console.log from game to reveal state. We can add console logs on key events and collisions to inspect. That could be a bit noisy but helpful. E.g., `console.log('[space-invaders]', 'state', snapshot)` on hits, restart, state changes. Then browser inspect likely shows console logs. Need see tool output format.

We can also use bash to run static checks (perhaps node with jsdom? no third-party libraries? But node may have no jsdom). Could use browser tool itself. We can leverage `browser` screenshot/motion, maybe use `key` to hold? Need figure out.

Let's write code with robust logic. Need careful with layout sizes and scaling for screenshot coordinates. Canvas 900x620 CSS width 100%, max-width 900px; tool viewport 1200x800. Wrapper centered, HUD above, controls below; canvas maybe 900x600 scaled to 900x600; top offset maybe ~120. Need browser click coordinates to focus maybe not necessary. Overlay buttons at center.

Let's decide exact dimensions:
canvas W=900 H=620.
Bounds: left=24, right=876, top=52 (formation start y=92), playerY=548 (cannon height 26; zone y=530). Bunkers y=448, cell=6, cols=13 rows=7 => width 78, height 42. Four bunker x positions: [110, 290, 470, 650]? plus maybe need centered four: available 852 / 4 = 213; width 78; positions 80+? Let's choose [95, 295, 495, 695] each width 78, centers 134,334,534,734; leaves ~100 right. Maybe better [104, 292, 480, 668] with 4 bunkers ending 746, leaves 130. Actually align around center: total 4*78 + 3*? Let gap=110 -> total 642, start=(900-642)/2=129; positions [129,317,505,693]. Nice. End 771. Use xPos=[120,310,500,690]? total 648; start=126; positions [126,316,506,696], end774. Good. Let's pick [120, 310, 500, 690] for simplicity? centers 159,349,539,729. Asymmetric? right end 768, left start 120; margins 120 & 132, close. Fine.

Bunker shape: 13 cols x 7 rows. Solid if:
- for row r 0..6:
  - if r===0: c>=3 && c<=9 && c not? arch top maybe c in [4..8] narrow; classic inverted U.
  - r===1: c>=2 && c<=10
  - r===2: c>=1 && c<=11
  - r>=3: c>=0 && c<=12, but carve central notch from bottom: if r>=5 && c>=5 && c<=7 -> false. Maybe r===6 && c===6 false. Need nice bunker shape. Let's define:
```
if (r===0) solid = c>=4 && c<=8;
else if (r===1) solid = c>=2 && c<=10;
else if (r===2) solid = c>=1 && c<=11;
else solid = true;
if (r>=5 && c>=5 && c<=7) solid=false; // doorway
if (r===6 && (c===4||c===8)) maybe edge erosion? no.
```
Total cells ~5+9+11+13+13+10+10=71 each, 284 total. Good.

Destroy cells: impact at (x,y) determine c=floor((x-bx)/cell), r=floor((y-by)/cell). Remove cells within radius in cell units maybe 1.6 cells (10 px). e.g.
```
for r from rr-1 to rr+2, c from cc-1 to cc+2:
 d=hypot((c+0.5)-(localX/cell), (r+0.5)-(localY/cell))
 if d<1.25 + Math.random()*0.35 and within grid -> false
```
This removes ~6-10 cells, making gaps. Need both sides. For player shots hitting from below, ideally bottom rows; sample path detects first solid cell from bottom. For enemy shots from above, top rows. Good.

Bullet width: player 3 px, enemy 4 px; collision with bunker cell should consider projectile width; sample along center x maybe enough; to make gaps meaningful, need check width around center. We can use a helper `bunkerCellAt(x,y)` with x ± bullet halfWidth maybe. If center passes through narrow gap but width overlaps solid, should still hit. Implement collision sample offsets maybe -2,0,2. For each sample y, iterate offsets and find solid cell; if any, pick first cell and damage. This is fine.

Collision detection with alien:
```
function eachAlien() ...
const ax = originX + col*stepX + offX, ay=originY+row*stepY+offY;
if (x+2 > ax && x-2 < ax+aw && y-6 < ay+ah && y+6 > ay) hit
```
Since shots sample y, use bullet center and height. Could use bullet rect vs alien rect. Need remove one alien per hit and score once: set alive=false, score += rowValue (10/20/30) and feedback particle + score popup maybe. `score` increments once because projectile removed. Need visual damage feedback: alien explosion particles + flash; score HUD update; floating score text. Good.

Enemy shots damage bunkers; player shots damage bunkers too. Need ensure player shots can pass through gaps: if cell solid, shot removed; else continues. Good.

Alien motion: `formation = {x:0,y:0,dir:1,speed:48, stepDown:18, frame:0, frameTimer:0.35}`. Each frame:
- compute alive min/max x; desired dx = dir*speed*dt; if max + w + dx > right or min + dx < left: reverse, y += 18, maybe x adjusted so formation stays in bounds; play tone? no audio maybe use WebAudio? external no; procedural audio optional but could cause autoplay issues. Could add simple beep via WebAudio on user gesture. Not required; skip to keep simple.
- else x += dx.
- speed = 38 + (1 - alive/total)*70; maybe plus time.
- animate frame every 0.45s (toggle 0/1).
- alien fire timer -= dt; when <=0, spawn from bottom-most alive alien in random col, reset timer to `0.55 + Math.random()*0.9` scaled by alive ratio; cap 0.35 min; also max enemy shots 5.
- check if any alien bottom >= playerY-18 -> game over (message "The invaders breached the line").
- if aliveCount===0 -> win.

Need ensure alien formation starts above bunkers and descends gradually. Start y=92; rows 5*44=220 => bottom row at 92+4*44+26=294; bunkers y=448. There's 154 px gap. Descent 18 per edge; formation width 10*62=~594; start originX = (900 - (9*62+36))/2 = (900-594)/2=153. left=153 right=747? Actually width = 9*62 + 36 = 594; start=153; right=747. Bounds 24..876; ~129 px travel each side, at speed 50 takes 2.6s; descends 18 each ~5.2s. game over after ~12 descents -> ~60s. Fine.

Alien firing: enemy shots start at y ~ alien bottom + 8, x center. Need random bottom-most per chosen col; if no alien in col, pick another. Could build list of bottom-most alive per column. Spawn shot with vy=210+random*90 maybe; TTL=5.0; max 6. They may hit bunkers; need visible damage. Fine.

Player lives: 3, display hearts or ship icons. Use DOM `lifePips` with 3 span; add class lost. HUD score padded maybe `0000`. `aliens` count. Status "WAVE 1 • IN PROGRESS" etc. Button "Restart" in header; overlay also has "Play again". R key restart. Need restart restore all state. Use `resetGame()` called at init and on button.

Input:
```
const keys = new Set();
window.addEventListener('keydown', e=>{
  if (['ArrowLeft','ArrowRight','ArrowUp','ArrowDown','Space','KeyA','KeyD','KeyR'].includes(e.code)) e.preventDefault();
  if (e.code==='KeyR'){ resetGame(); return;}
  if (e.code==='Space' && !keys.has('Space')) maybe fire immediately? 
  keys.add(e.code);
  if (e.code==='Space') tryFire(); // immediate on keydown with cooldown
});
window.addEventListener('keyup', e=> keys.delete(e.code));
window.addEventListener('blur', ()=> keys.clear());
```
Need fire rate: `fireCooldown` set to 0.26 on fire; update decrements. If holding space, update calls `tryFire()` every cooldown. This also handles immediate. If keydown repeats, `e.repeat` true; we can ignore but update still fires. Good. Bound projectile lifetime: `life` for each shot, e.g., player 2.2s, enemy 5s, and max active shots. Also remove out of bounds. Need fire rate for enemy too. "Bound projectile lifetime and fire rate" likely refers both player and aliens. We'll implement constants PLAYER_FIRE_COOLDOWN=0.28, PLAYER_MAX_SHOTS=3, PLAYER_SHOT_TTL=2.2; ENEMY_FIRE_INTERVAL range, ENEMY_MAX_SHOTS=6, ENEMY_SHOT_TTL=5.5. HUD maybe display "Rate limited". Good.

Need game loop:
```
let last = performance.now();
function loop(now){
 const dt = Math.min(0.033, (now-last)/1000 || 0);
 last=now;
 if(state==='playing') update(dt); else updateVisuals(dt); // particles maybe
 draw(now/1000);
 requestAnimationFrame(loop);
}
```
Particles should update even in gameover? optional. HUD update every frame or on change; DOM text updates from `syncHud()` whenever changed. Could set `hud.dataset` attributes each frame for tests. Add `document.body.dataset.state = state`, and `hud` data-* attributes. Good.

Potential browser tool inspect might return DOM text but not dataset. Could add hidden `<pre id="telemetry">` with JSON snapshot updated every ~250ms; style `position:absolute; ...` maybe visible small debug panel? To avoid clutter, make it visually hidden but DOM text accessible to inspect. But maybe inspect outputs innerText of body, hidden text? Hmm. Could make a small visible "diagnostics" line in footer: `DEBUG x:450 · shots p0/e0 · bunkers 284`—this is okay as game telemetry. Could help verify. But user didn't ask; we can include as "telemetry" in a subtle monospace line under controls. It can be visible and small. Maybe add `id=diag` with text like `CANNON 450 | SHOTS 0/0 | BLOCKS 284 | ALIENS 50`. That yields easy inspect of state. Not too jarring; fits retro aesthetic. Good.

Need test with browser tool:
1. reload, inspect initial output/console. Need check console for errors.
2. screenshot initial.
3. movement: key ArrowRight or KeyD. Tool `key` maybe supports "ArrowRight" with text. Need see. We may have to click canvas first. Actually key events on window should work regardless focus, but browser tool may require page focus. We'll try.
4. Firing: key "Space" maybe text " " or "Space". Need figure. Tool action key has `text` parameter. Could be like "Space" or "ArrowRight". Try "ArrowRight". Need maybe hold via motion? Tool has motion frames. Could use `key` action with text "ArrowRight" and check diag x changes. Since keydown+keyup in same action might not allow time to move. Could use `drag`? Could add on-screen buttons to move: clicking and holding could move via pointerdown/up. But browser `click` is momentary; movement depends on update while key held. If key action does keydown and keyup immediately, player may move only a tiny amount (dt ~0.016 => 5px). Could still see x change. But perhaps tool's key holds key for some duration. Need discover. To ensure testable movement, we can implement a small discrete nudge on keydown in addition to continuous movement: e.g., on keydown of Left/Right/A/D, move player by e.g. 18px immediately (if state playing), then continuous movement while held. But that might make gameplay feel odd; not too bad? Could instead implement movement based on key press count: on keydown, set velocity; no discrete. We can add small `nudge` for accessibility? Hmm. Better: implement `keydown` for arrow/A/D to move by 12 px immediately plus continuous; this ensures visible movement even if key event is instantaneous. But could make rapid key repeats move faster; fine. However legitimate gameplay might have a little jump on each key press, acceptable. Actually a 10px nudge feels fine. Let's do `movePlayer(10 * dir)` on first keydown (not repeat), then velocity continuous. This will make browser `key` test show x +10. Need avoid interfering with proper continuous: fine.

Alternatively use touch buttons that move by e.g. 24 px per click (discrete), plus hold support. Could include on-screen controls below canvas with buttons "◀", "▶", "FIRE", and on click move a fixed step or fire. This would make verification via browser click straightforward, and also mobile friendly. But requirement specifically Left/Right/A/D and Space; adding buttons okay. Let's implement on-screen buttons with pointer events:
- `<button id=leftBtn aria-label="Move left">◀</button>`, right, fire.
- `pointerdown` sets keys with virtual codes and also immediate nudge/fire; `pointerup` clears.
- `click` also perhaps triggers fire? Need avoid double fire; pointerdown handles. For browser click tool, pointerdown likely fires. Could use `onclick` to move by 24 and fire once; but pointerdown+click would double. We can handle only `click` for discrete step and `pointerdown` for held movement? Simpler: use buttons with `pointerdown` and `pointerup`; on `click`, if not handled, do discrete. But browser click dispatch triggers pointerdown/up/click; need avoid duplicate. Could just use `click` handlers that perform one discrete action (move by 22 or fire once) and `pointerdown` for continuous hold via setInterval? That's more complexity. Maybe not needed.

Given need focused checks, maybe use `key` tool. We can also add a hidden test button? Not appropriate. Let's see browser tool behavior first after writing. We can adapt.

For firing, `keydown Space` calls `tryFire()` immediately, so even if key action keydown+keyup instant, a shot spawns. Good. Need hold auto-fire via update; `keys` set. Fine.

For movement, add keydown nudge. Good.

For alien motion check, we can use screenshot after waiting via `motion` action (captures frames over time) or repeated `screenshot` with delays. Tool actions may have inherent time between calls. Could use `browser` action "motion" to see frames; likely returns sequence. Need check. Could also add diag showing formation x offset and direction; after a second, inspect diag. Good.

For shot hitting bunker/alien: We can't easily aim; player center x=450 initially. Bunkers at x=310..388 and 500..578; center x=450 falls between bunkers 2 and 3 (gap 388..500), so a center shot will not hit bunker, likely hit an alien column. Need map columns: startX=153, stepX=62. Column centers = 153+18 + c*62 = 171+62c: c0=171,c1=233,c2=295,c3=357,c4=419,c5=481,c6=543,c7=605,c8=667,c9=729. Center 450 is between c4(419) and c5(481), so can hit alien only if formation moved such that an alien overlaps x=450. Initial shot from center might pass between columns; alien width 36 -> c4 spans 401-437, c5 spans 463-499, gap 26 px. Shot width 4 won't hit. That's bad for verification "inspect a shot hitting a bunker or alien for visible damage or score feedback." Need make initial center shot align with a bunker or alien. We can set player start x to align with a bunker (e.g., x=349, center of second bunker) or with an alien column (e.g., x=419). But requiring "player position" reset; center typical. Could adjust formation/bunker positions to align center with alien and bunker? Let's design so center x=450 is aligned with a bunker center and an alien column. Then initial shot will hit bunker first, making visible damage; to score on alien, need shoot through gaps or move. But simple initial shots hit bunker. Task says "Check alien motion and inspect a shot hitting a bunker or alien for visible damage or score feedback." So either bunker or alien. Bunker damage visible. But also need verify player shots remove hit aliens and increase score once. We should test that too. Could align center with alien column but not bunker; then shot hits alien and score. Need also test bunker damage via enemy shot or move player to bunker.

Maybe best: place 4 bunkers centered such that central gap includes x=450 (so center shot can hit alien), and add on-screen buttons to move cannon to bunker x easily. Or choose bunker positions with one centered at 450? Then center shot hits bunker; to hit alien need move. We can verify both by moving and firing.

Let's optimize for testability:
- Aliens: 10 columns with step 60, width 38, startX=165? Need column center at 450. Suppose 10 cols, step=60, width=38, col center = startX+19+60c. Want c=5 center=450 => startX=450-19-300=131. Then formation width=9*60+38=578; start=131, right=709; asymmetric but can choose 11 columns: step=58, width=36, 11 cols => width=10*58+36=616, start=(900-616)/2=142, center of c5 =142+18+290=450. Nice! 11 columns, 5 rows =55 aliens. Center column c5 aligns with 450 exactly. Formation left=142, right=758; symmetric. Great. Use 11 cols, stepX=58, alien width=36, height=24, stepY=44, originY=94. Bunkers: 4 bunkers width=78 (13*6), choose centers such that center x=450 is a gap between bunkers 2 and 3. E.g., bunkers at x=[120,300,522,702]? width 78: 120-198, 300-378, 522-600, 702-780. Center gap 378-522 includes 450. Player initial x=450 can shoot through gap and hit center alien column c5. Other positions can hit bunkers: bunker 3 at 522-600 (center 561), bunker 2 at 300-378 (center 339). Need move ~90-110 px to align. With player speed 320 px/s, ~0.3s. Browser key nudge 10px each press; could need 9-11 presses. On-screen button click discrete 24px, ~4 clicks. We can add diagnostic or test helper? Could also make bunker centers at 450? Maybe 3 bunkers? Classic 4. Could place bunkers at x=[96,276,456,636] -> bunker3 spans456-534, center x=450 just 6px left of bunker3. Player shot width 4 at x=450 won't hit; but close. Move right nudge 10 -> x=460, hits bunker. Nice! Need symmetric layout: 4 bunkers width78, gap maybe 102, total width=4*78+3*102=618, start=(900-618)/2=141 -> x=[141,321,501,681]. Center 450 is in gap 399..501, 51 px from bunker3. With 5 nudges (10 each) x=500, could hit edge; with continuous key hold ~0.16s. Hmm.

Alternative place bunkers at x=[96,282,468,654] (gap 108 between starts), total 636, start 132? Let's compute: width=78, gap=108 -> step=186, total=4*78+3*108=636, start=(900-636)/2=132 -> x=[132,318,504,690]. Center 450 in gap 396..504, 54 left. Similar.

What if we use 5 bunkers with one centered at 450: width78, step=160, total=5*78+4*82? Actually step 160, total=78+4*160=718, start=91 -> centers [130,290,450,610,770]; last ends809. That's symmetric and nice. Classic 4 bunkers, but 5 is fine. Center shot from x=450 hits center bunker; need move to x=390 or 510 to hit alien through gap. But alien columns at 450 (c5) is behind center bunker; c4 center=392, c6=508; gaps between bunkers: bunker centers 130,290,450,610,770; spans 91-169,251-329,411-489,571-649,731-809. Gaps 169-251 (center 210), 329-411 (370), 489-571 (530), 649-731 (690). Alien column centers: 160,218,276,334,392,450,508,566,624,682,740 (if start=142, step58, width36: centers160+58c). Gaps centers 370/530 align near c4=392 / c6=508; shots through gap at x=392 (between bunkers 2 and3) can hit c4; x=508 (between bunkers3 and4) can hit c6. Need move ~58 px. Center shot hits bunker, visible damage. Score requires moving ~58px and firing through gap. Could be doable with key holds. But if center shot always blocked by bunker, game is harder: center bunker absorbs shots until destroyed. That's classic. Need test score maybe via moving to gap.

Maybe simpler: 4 bunkers with central gap at 450. Let's choose bunker x positions [110, 290, 532, 712] (width 78): spans 110-188,290-368,532-610,712-790; central gap 368-532, width164, includes 450. This is symmetric around 450? centers 149,329,571,751; mirror pairs sum 900 (149+751=900,329+571=900). Nice! Total span 110..790, margins 110 each. Great. So center x=450 is in central gap; initial shot can hit center alien column c5 (since 11 cols center at450). Bunkers at x=329 center and 571 center; need move ±121 px to hit bunker center. But can instead shoot at bunker edge with less movement? central gap from 368 to532; x=450; move right 82 -> x=532 hits bunker3 edge; move left 82 -> x=368 hits bunker2 edge. With speed 320, 0.26s. On-screen step 24 per click ~4 clicks. Key nudge 10 per press ~9 presses. Could use browser key hold maybe works. Could also make bunker width larger e.g., 90 and central gap smaller: bunkers at [120,300,510,690] width90 -> spans 120-210,300-390,510-600,690-780; central gap 390-510, center450; move60 to edge. Centers 165,345,555,735 (mirror around450? 165+735=900,345+555=900 yes). Nice! width90 (15 cols*6), gap120 between starts. Need shape 15 cols x 7 rows. Center gap 390-510 width120; from center 60 to edge. That's manageable. Great. Let's use bunker cols=15, cell=6, width=90, rows=7, height42, x positions [120,300,510,690]. symmetrical: spans 120-210,300-390,510-600,690-780; margins 120 each. Center gap 390-510, 120 wide. Alien c5 center=450. Bunker edges at390 and510; alien c4=392, c6=508, so shots at those x might clip bunker edge if width; but center shot clear.

For bunker damage test, move player right 60+ px to x=515 and fire. With on-screen right button discrete 26px, 3 clicks =78 -> x=528, hits bunker3. Good. Or key hold. We'll add clickable buttons with discrete moves.

Let's design on-screen control buttons:
```
<div class="touch-controls">
  <button id="btnLeft" class="ctrl">◀ <span>Left</span></button>
  <button id="btnFire" class="ctrl fire">FIRE <span>Space</span></button>
  <button id="btnRight" class="ctrl">▶ <span>Right</span></button>
</div>
```
On `click`: if state not playing, maybe call reset? no. left/right move 26 px; fire `tryFire()`; also button `pointerdown` could set a hold flag to move continuously; `pointerup/leave` clear. Need prevent double movement: on pointerdown set a `hold` flag and start continuous; on click, if hold was just a short press, also move 26? Could cause double. We can instead treat click only as discrete; no hold support, but touch users can tap repeatedly. Could use `setInterval` on pointerdown for continuous movement and clear on pointerup; then on click, if pointer duration < 200ms, apply discrete nudge. Complexity okay:
```
function bindHold(btn, code) {
 let downAt=0;
 btn.addEventListener('pointerdown', e=>{ e.preventDefault(); downAt=performance.now(); keys.add(code); });
 ['pointerup','pointercancel','pointerleave'].forEach(... keys.delete(code));
 btn.addEventListener('click', e=>{ if(performance.now()-downAt<250) nudge... });
}
```
But browser click tool may dispatch pointerdown then pointerup then click; downAt set; click within <250 => discrete move. Good. For fire, pointerdown call `tryFire()` (immediate), click no additional. Also add keys code 'Space' while held so auto-fire works; on pointerup remove. Need avoid duplicate if click triggers fire; we won't add click handler for fire. For keyboard, keydown nudge 10 px; for buttons, discrete 26 px. Good.

Need careful: `keys` uses code strings like 'ArrowLeft','ArrowRight','Space'. Buttons add these same codes. For Fire button pointerdown: `keys.add('Space')`; `tryFire()`; pointerup remove. For left/right pointerdown add code but also no immediate nudge until click. Continuous movement will happen while hold. Fine.

Need reset also clear keys? If restarting while holding, maybe keep; but okay. Reset should restore player position; if keys held, next frame moves. For test, no keys held. Could clear keys on reset to ensure position stable. Do that.

Need draw and DOM:
HTML structure:
```
<!doctype html>
<html lang="en">
<head> meta ... title ...
<style> ... </style>
</head>
<body>
<main class="shell">
  <header class="topbar">
    <div class="brand"><span class=mark>▰</span><div><h1>NEON INVADERS</h1><p>PROCEDURAL DEFENSE GRID</p></div></div>
    <div class="hud" id="hud" data-state="playing" data-score="0" ...>
      <div class="stat"><span>SCORE</span><strong id="score">0000</strong></div>
      ... lives pips ...
      <div class="stat"><span>ALIENS</span><strong id="aliens">55</strong></div>
      <button id="restart" class="restart">↻ Restart</button>
    </div>
  </header>
  <div class="stage">
    <canvas id="game" width="900" height="620" aria-label=...></canvas>
    <div id="overlay" class="overlay hidden" role="dialog">
      <div class=panel>
        <p class=eyebrow id=overlayEyebrow>...</p>
        <h2 id=overlayTitle>...</h2>
        <p id=overlayText>...</p>
        <button id=overlayRestart>Launch again</button>
      </div>
    </div>
  </div>
  <section class="instructions">
    <div class="keys">...</div> ...
  </section>
  <div class="telemetry" id="diag">...</div>
  <div class="touch-controls">...</div>
</main>
<script> ... </script>
</body>
</html>
```
Need ensure overlay hidden class display:none; when gameover/win show. Canvas still visible behind overlay with dim background.

CSS: dark background radial gradients, neon colors, monospace font stack (system fonts no external). Use `font-family: 'Courier New', ui-monospace, monospace`. Responsive: canvas width:100%; height:auto; display:block; aspect ratio 900/620; max-width:900px. Stage position relative; border, shadow. Body min-height 100vh; padding 16px; overflow-x hidden. Topbar max-width 900px; flex. On small screens wrap. Overlay absolute inset0; background rgba; panel center. Buttons styled.

Canvas drawing:
- `ctx.fillStyle='#050814'; fillRect(0,0,W,H);`
- stars from seeded array 90 stars with x,y,r,twinkle; draw small squares. Need deterministic seed function:
```
let seed=123456;
function rand(){ seed = (seed*1664525+1013904223)>>>0; return seed/2**32; }
```
Generate stars at reset? Could be static.
- ground line at y=590, gradient.
- playfield boundary maybe subtle vertical lines at x=24 and876.
- draw bunkers: for each solid cell, fillRect with color based on row and col plus damage edge; maybe use cell shade: top lighter, bottom darker; add highlight on top-left. To show gaps, draw only solid cells. Use slight glow via shadowBlur maybe expensive but okay (4*105 cells ~420 fillRects per frame) fine.
- draw aliens: pixel pattern. Need define patterns as strings 11x8 maybe. Use two frames:
```
const alienPatterns = [
[
"00100000100",
"00010001000",
"00111111100",
"01101110110",
"11111111111",
"10111111101",
"10100000101",
"00011011000"
], ...
]
```
Need consistent width maybe 11 cols, 8 rows; alien width 36, height24 => pixel size 3? 11*3=33, 8*3=24. Good. Use px=3; x offset (aw - 11*3)/2 =1.5; y0. Draw rects for '1'. Two frames differ legs/eyes. Maybe 3 row types with different patterns and colors. Could define pattern set per row (0..4), each with two frames; simpler use base pattern and alternate legs by frame:
```
const SPRITES = [
[ "00000100000", ... ]
]
```
Let's design pixel art carefully.

Classic squid/ crab:
Frame 0 11x8:
```
"00011011000"? hmm.
```
Let's use 11-wide, 8-tall patterns:
Type 0 (top row, squid):
f0:
"00011111000"
"00111111100"
"01111111110"
"01101110110"
"11111111111"
"10111111101"
"00100100100"
"01000000010"
f1:
"00011111000"
"00111111100"
"01111111110"
"01101110110"
"11111111111"
"11111111111"
"01001001000"
"00100000001"
Maybe too complex; either fine. Type1 crab, Type2 octopus. Could just use same pattern with color changes and small variations; procedural graphics requirement satisfied.

Better define function `drawAlien(x,y,row,frame,color)` with patterns array indexed row%3:
```
const SPRITES = [
[
 [
"00011111000",
"00111111100",
"01111111110",
"11011111011",
"11111111111",
"00111111100",
"00100100100",
"01000000010"
 ],
 [
"00011111000",
"00111111100",
"01111111110",
"11011111011",
"11111111111",
"01111111110",
"01001001000",
"00100000001"
 ]
],
...
]
```
Need eyes cut out: draw dark eye rects maybe; but patterns with 0s can indicate holes. Fine. Colors by row: ['#ff5fa2','#ff9d5c','#ffe66d','#7bf1a8','#69d2ff'] or top pink then violet etc. Add glow shadow maybe.

Aliens can be drawn with `ctx.fillStyle = color`, `shadowColor=color`, `shadowBlur=8`; then fillRect each pixel; reset shadowBlur=0 after. 55 aliens * ~60 rects =3300 rects per frame; with shadowBlur each might be heavy. Better avoid per-rect shadow; set shadow once and draw all rects; still maybe okay. Or no shadow, use bright colors and highlight. We can add a low-alpha aura behind alien with `fillRect` once. Fine.

Cannon: draw at x,y; shape with polygons: base trapezoid, barrel, cockpit. Procedural:
```
ctx.save(); translate(x, playerY);
if invuln and Math.floor(t*12)%2 skip or alpha .35;
draw glow ellipse; draw body path:
moveTo(-22, 14), lineTo(-16, 0), lineTo(-6,-4), lineTo(-4,-16), lineTo(4,-16), lineTo(6,-4), lineTo(16,0), lineTo(22,14), close
fill cyan/teal; stroke; draw barrel rect at (-3,-24,6,12); cockpit arc.
thruster flame flicker with random-ish sin.
```
Need player y maybe baseline; define `player.y = 552` as center? Let's set `PLAYER_Y=552` as top of cannon? Use draw relative to center y=552; body extends -24..+16 -> top528 bottom568. Ground line at590. Player zone y=522 (if alien bottom >= PLAYER_Y-28=524 game over). Need alien hitting player: enemy shot collision rect around x±18, y-18..y+14. Good.

Bunkers y=440 maybe; height42 -> bottom482, gap to cannon top528 =46. Alien shot from formation bottom~300 needs 1s to bunkers, then 0.2s to player. Player shot from y=528 to alien bottom~300 takes 0.4s at 560 px/s. Good.

Let's set PLAYER_Y = 552 (cannon center), cannon top 528. `PLAYER_ZONE_Y = 520`. Bunker top=438, bottom=480. Alien formation bottom initial: originY=92 + 4*44 +24=292. Good.

Enemy shots spawn from bottom-most alien y+24+6. Need maybe pass through other aliens? Not necessary; alien shots don't collide with aliens (classic they can pass through). Fine.

Player shot spawn y=PLAYER_Y-26 =526, x=player.x. Bullet width 3, height 12, vy=-620, TTL=1.8 (distance 1116, enough). Enemy shot vy=230-300, TTL=4.5.

Collision with player: enemy shot sample y; use `Math.abs(sampleX - player.x) < 20 && sampleY > PLAYER_Y-22 && sampleY < PLAYER_Y+14`; if invuln>0, remove shot and spawn small shield spark (no life); else lose life. Need brief protection; after hit `invuln=1.6`, clear enemyShots, add particles. `lives--`; if lives<=0 endGame(false,'Hull breached'). Also maybe `state='playing'` until next frame if lives>0. HUD sync.

Particles: array {x,y,vx,vy,life,maxLife,color,size}. On alien death spawn 12 particles; on bunker hit spawn 5; on player hit spawn 20. Update every frame regardless of state. Draw small squares/circles with alpha. Also floating texts {x,y,text,life,color} draw with font. Score popup shows "+30" at alien position; helps score feedback. Need ensure score HUD updates. Maybe add a brief score flash class on HUD using setTimeout? Could avoid timers; use `scorePulse=0.5` and CSS maybe not necessary. Draw `+30` floating text on canvas; visible.

Bunker hit should have visible damage: removal of cells and particles. Good.

Alien motion reverse and descend: need handle edge at each frame. Let's detail:
```
function updateFormation(dt){
  const alive = getAliveAliens();
  if (!alive.length) { endGame(true,...); return; }
  const minX = Math.min(...alive.map(ax)), maxX = Math.max(...alive.map(ax+AW));
  const speed = 42 + (1 - alive.length/TOTAL)*95 + Math.min(30, elapsed*0.2);
  let dx = formation.dir*speed*dt;
  let hitEdge = false;
  if (formation.dir>0 && maxX+dx > RIGHT-8) { dx = (RIGHT-8)-maxX; hitEdge=true; }
  else if (formation.dir<0 && minX+dx < LEFT+8) { dx = (LEFT+8)-minX; hitEdge=true; }
  formation.x += dx;
  formation.anim -= dt; if <=0 toggle frame.
  if (hitEdge) { formation.dir *= -1; formation.y += 18; }
  ...
}
```
Need if dx clamped to 0 when maxX already at boundary; after reverse direction, next frame moves left, no repeated descent. Good.
Aliens reaching player zone check after y increment: compute max bottom. If >= PLAYER_ZONE_Y endGame. Since formation y increments 18 per edge, max bottom starts 292, needs 13 descents -> 234 =>526. Game over after ~13*~4s=52s. Fine.

Alien firing interval:
```
enemyFireTimer -= dt;
if (<=0) {
 const ratio=aliveCount/TOTAL;
 enemyFireTimer = Math.max(0.32, (0.55+Math.random()*0.85)*(0.55+0.45*ratio));
 fireEnemyShot(aliveAliens);
}
```
At start ~0.8-1.4s. Max shots 6. Add `lastFireCol` to avoid same spot? not needed. Use `Math.random` (non-deterministic). For verification maybe deterministic random seed better. Use seeded `rnd()` for all game randomness to be reproducible. But reset should restore initial formation etc; random sequence could change but not critical. Let's implement seed reset in `resetGame()` to 0xC0FFEE so particles/stars/enemy fire deterministic. But stars can be generated once with separate seeded function. Use `rnd()` global seeded by reset; fine. Need avoid stars shifting on restart? generate stars once with local seeded PRNG. Good.

Enemy shot spawn: choose bottom-most alive alien in random column. Since 11 cols, pick from `columns` array of alive aliens per col; if empty retry up to 8 times; else pick any alive. `x = alienX(col)+AW/2`, `y = alienY(row)+AH+6`. Add shot with `vy=210 + rnd()*70 + (1-ratio)*40`, `ttl=4.5`, wave phase for drawing. Need max active shots.

Projectile update robust:
```
function updateShots(dt){
 for (let i=playerShots.length-1;i>=0;i--){
   const s=playerShots[i]; s.ttl-=dt; if(ttl<=0... remove)
   const y0=s.y, y1=s.y+s.vy*dt;
   const hit=traceShot(s, y0, y1, 'player');
   if(hit){ playerShots.splice(i,1); continue; }
   s.y=y1; if(s.y < TOP-20) remove;
 }
 ...
}
```
`traceShot` samples from t=0..1 with step every 2 px:
```
function traceShot(s, y0, y1, kind){
 const dist = Math.abs(y1-y0);
 const steps = Math.max(1, Math.ceil(dist/2));
 for(let i=1;i<=steps;i++){
   const t=i/steps;
   const y=y0+(y1-y0)*t;
   const x=s.x + (kind==='enemy'? Math.sin((s.age+t*dt)*??)*?? :0) maybe no horizontal movement. 
   if (bunkerCollision(x,y,kind,s)) return true;
   if(kind==='player' && alienCollision(x,y,s)) return true;
   if(kind==='enemy' && playerCollision(x,y,s)) return true;
   if(kind==='player' && enemyShotCollision? optional) ...
 }
 return false;
}
```
Need `s.age` maybe update before trace for enemy zigzag drawing only, not collision. Keep x constant. For each sample, if y out of bounds? fine.

Bunker collision:
```
function hitBunkerAt(x,y,s){
 const half = s.w/2;
 const offsets=[-half,0,half];
 for (const b of bunkers){
   for (const off of offsets){
     const px=x+off;
     if(px<b.x||px>=b.x+b.w||y<b.y||y>=b.y+b.h) continue;
     const c=Math.floor((px-b.x)/CELL), r=Math.floor((y-b.y)/CELL);
     if(b.cells[r] && b.cells[r][c]){
        damageBunker(b, px, y, s.vy>0?1:-1);
        spawnParticles(...);
        return true;
     }
   }
 }
 return false;
}
```
Need ensure player shot from below hitting bottom face: samples y decreasing; first solid cell encountered. Enemy shot from above: samples y increasing; first solid. Great. But if width offset overlaps cell in a bunker that center x is outside, still works. Need sample points maybe 3 offsets. fine.

Damage function:
```
function damageBunker(b,x,y,dir){
 const lx=(x-b.x)/CELL, ly=(y-b.y)/CELL;
 let removed=0;
 for(let r=0;r<ROWS;r++) for(let c=0;c<COLS;c++){
   if(!b.cells[r][c]) continue;
   const dx=(c+0.5)-lx, dy=(r+0.5)-ly;
   const rad = dir>0?1.35:1.55; // shots from above smaller?
   if(dx*dx+dy*dy < rad*rad + rnd()*0.25){ b.cells[r][c]=false; removed++;}
 }
 b.hits++;
 b.flash=0.18;
 ...
}
```
Need shape of destruction: player shots from below should carve upward; enemy from above carve downward. Could bias dy:
```
const biasedDy = dy + (dir>0 ? -0.25 : 0.25)? 
```
Maybe not necessary. But for visual, can add crater around impact. Need ensure holes persist; yes.

Could also degrade with multiple shots. Good.

`bunkerCellCount()` sum solids; used for diagnostics and maybe win? no.

Alien collision:
```
function hitAlienAt(x,y,s){
 for(let r=ROWS-1;r>=0;r--) for(let c=0;c<COLS;c++){
   if(!aliens[r][c].alive) continue;
   const ax=alienX(c), ay=alienY(r);
   if(x+s.w/2>ax && x-s.w/2<ax+AW && y-6<ay+AH && y+6>ay){
      killAlien(r,c,ax+AW/2,ay+AH/2); return true;
   }
 }
 return false;
}
```
Since player shot height ~12, sample y; using y±6. With step 2 no miss. Need avoid hitting alien behind bunker if bunker hit; trace order handles.

Score values by row: top 40, next 30, etc. e.g. `SCORE_VALUES=[40,30,20,20,10]`. On kill: `score += value; aliensAlive--; spawn particles; floatText '+40'; if aliensAlive===0 endGame(true)`. Need `score` increase once; okay.

Player shot TTL updates; if shot hits top boundary remove. Enemy shot TTL and out-of-bottom remove. Need max active shots enforced in `tryFire` and `fireEnemyShot`.

Game over/win:
```
function endGame(won, msg){
 state = won?'win':'gameover';
 keys.clear();
 overlay.classList.remove('hidden');
 overlay.dataset.state=...
 title...
 button...
 syncHud();
 console.log('[game]', state, snapshot());
}
```
Need overlay hidden on reset. `resetGame()` should set state='playing', score=0, lives=3, player.x=W/2, formation reset, bunkers reset, arrays empty, timers, invuln=0, elapsed=0, particles empty, floaters empty, overlay hidden, keys.clear(), syncHud(), log. Need also maybe `last=performance.now()` to avoid dt spike after restart. Set `lastTime = performance.now()`; but loop uses global. Good.

HUD sync:
```
scoreEl.textContent = String(score).padStart(4,'0');
livesEl.innerHTML = ...? use pips classes; avoid innerHTML each frame maybe create once.
aliensEl.textContent = String(aliensAlive).padStart(2,'0');
hud.dataset.score=score; etc.
diag.textContent = `CANNON ${Math.round(player.x)} ...`;
diag.dataset... 
```
Need check initial formation, bunkers, lives, score via DOM: `data-aliens="55"`, `data-bunker-cells="..."`, `data-lives="3"`, `data-score="0"`, `data-player-x="450"`, `data-state="playing"`, `data-formation-x="0"`, etc. Set on `hud` or `body`. For inspect, dataset may not be visible; diag text will show. Add visible diag: "TELEMETRY // x450 · formation +0.0 → · aliens 55 · bunker 380 · shots P0/E0". Need on restart check initial formation etc. Good.

Need maybe draw bunkers on canvas initial; screenshot can show. Need overlay hidden initial. Need no external requests: no fonts, no images. Fine.

Need maybe avoid `innerHTML` with user data (none). Fine.

Need self-contained file. We'll write with write tool.

Let's carefully craft JS code. Need ensure no syntax errors. Could run `node --check` on extracted script? We can use `bash` with `node` maybe available. We can extract script via python/regex and `node --check`. Good. But browser tool can also catch console errors. We'll do both.

Let's write full HTML now.

Detailed CSS:
```
:root { --bg:#050713; --panel:#0b1022; --cyan:#54f2ff; --pink:#ff5ca8; --lime:#a6ff6c; --amber:#ffcb6b; --muted:#7c89aa; }
* {box-sizing:border-box}
html,body{margin:0;min-height:100%}
body{background: radial-gradient(circle at 50% -10%, #17204a 0%, #070a18 45%, #03040c 100%); color:#e8f2ff; font-family: ...; padding:18px 14px 28px; display:flex; justify-content:center;}
body::before { content:""; position:fixed; inset:0; pointer-events:none; background: repeating-linear-gradient(...); opacity:.15; }
.shell{width:min(100%, 940px); position:relative;}
.topbar {display:flex; gap:16px; align-items:center; justify-content:space-between; margin-bottom:12px; flex-wrap:wrap;}
.brand ... 
.hud {display:flex; gap:10px; align-items:stretch; flex-wrap:wrap;}
.stat {min-width:92px; background:...; border...; padding:8px 12px; border-radius:10px; box-shadow...}
.stat span {font-size:10px; letter-spacing:.18em;color:var(--muted)}
.stat strong {display:block; font-size:22px; ...}
.life-pips {display:flex; gap:6px; margin-top:4px}
.pip {width:16px;height:14px; background:linear-gradient...; clip-path: polygon(...); box-shadow...}
.pip.lost {opacity:.18; filter:grayscale(1)}
.restart { ... }
.stage {position:relative; border:1px solid #2b3d70; border-radius:14px; overflow:hidden; background:#050814; box-shadow:...}
canvas{width:100%;height:auto;display:block;image-rendering:pixelated;}
.overlay{position:absolute;inset:0;display:grid;place-items:center;background:rgba(3,6,18,.74);backdrop-filter:blur(2px);}
.overlay.hidden{display:none}
.panel{...}
...
.instructions {display:flex; flex-wrap:wrap; gap:10px 18px; align-items:center; justify-content:space-between; margin-top:12px; font-size:12px;color:#aebcdf;}
kbd {...}
.telemetry {...}
.touch-controls {display:flex;gap:10px;justify-content:center;margin-top:12px}
.ctrl { ...}
.ctrl.fire { ...}
@media (max-width:700px) { ... }
```
Need `backdrop-filter` may be fine. No external.

Canvas visual: draw HUD-ish top line maybe "SECTOR 01" at top-left and boundaries. Need avoid clutter. Let's implement `drawBackground(t)`:
- fill with vertical gradient from #070c22 to #03050f.
- stars: for each star {x,y,s,phase}, alpha=0.35+0.45*sin(t*1.5+phase); fillStyle `rgba(160,210,255,${alpha})`; fillRect(x,y,s,s). Maybe some larger cross stars.
- horizontal scanlines: for y=0;y<H;y+=4 fillRect with rgba(255,255,255,0.012). Could be 155 rects, okay.
- boundary lines: left/right dashed with setLineDash([4,8]); strokeStyle rgba(84,242,255,.14).
- ground: gradient at y=584..620; line at y=586; glow.
- top label: small text "DEFENSE LINE // 01" at x=32,y=30; right "SCORE..."? HUD is DOM; maybe draw "▲" etc. Fine.
- maybe draw player zone line at y=520 with dashed red low alpha and label "BREACH LINE" right side. This helps visualize game over condition. Good.

Draw bunkers:
```
function drawBunkers(){
 for(const b of bunkers){
  ctx.save();
  ctx.shadowColor = '#63ff9b'; ctx.shadowBlur=6;
  for(r...) for(c...) if(solid){
    const px=b.x+c*CELL, py=b.y+r*CELL;
    const shade = ...
    ctx.fillStyle = shade;
    ctx.fillRect(px,py,CELL-0.6,CELL-0.6);
    if((r+c)%? ) small highlight...
  }
  ctx.restore();
  if(b.flash>0){ draw outline? }
 }
}
```
Per-cell shadowBlur might be expensive; set shadowBlur=0 and draw a glow rectangle behind bunker once:
```
ctx.fillStyle='rgba(90,255,140,.05)'; ctx.fillRect(b.x-4,b.y-4,b.w+8,b.h+8);
```
Then cells with colors. Good.
Color by row: `const colors=['#b6ff8a','#8cf07a','#63df73','#44c86a','#32ad60','#278e55','#1e7449']`; maybe top lighter. Add small lighter top edge if cell above missing: `if(r===0||!cells[r-1][c]) fillRect(px,py,CELL-1,1)` in #d8ffbb. This highlights erosion. Good. Persistent gaps visible.

Draw aliens:
```
function drawAliens(){
 const colors = [...];
 for r,c if alive:
   const x=..., y=...
   const frame=formation.frame;
   const sprite = SPRITES[r%3][frame];
   ctx.save();
   ctx.fillStyle='rgba(...)'; maybe aura: ctx.globalAlpha=.12; ctx.fillRect(x-3,y-3,AW+6,AH+6); globalAlpha=1;
   ctx.fillStyle=colors[r];
   const px=3, ox=x+(AW-11*3)/2, oy=y;
   for(let sy=0;sy<8;sy++) for sx...
   // eyes dark:
   ctx.fillStyle='#081124'; ctx.fillRect(x+? ...);
   ctx.restore();
}
```
Need sprites ensure eye holes. Let's define three sprite types with 11 chars each, 8 rows. Need verify strings length. Let's craft:

Type 0 (squid):
frame0:
```
"00011111000"  (11)
"00111111100"
"01111111110"
"11011011011"
"11111111111"
"00111111100"
"00100100100"
"01000000010"
```
frame1:
```
"00011111000"
"00111111100"
"01111111110"
"11011011011"
"11111111111"
"01111111110"
"01001001000"
"00100000001"
```
Type1 (crab):
frame0:
```
"00100000100"
"00010001000"
"00111111100"
"01101110110"
"11111111111"
"10111111101"
"10100000101"
"00011011000"
```
frame1:
```
"00100000100"
"00010001000"
"00111111100"
"01101110110"
"11111111111"
"11111111111"
"01010001010"
"00100000100"
```
Type2 (octopus):
frame0:
```
"00011111000"
"01111111110"
"11111111111"
"11001110011"
"11111111111"
"00111111100"
"00110001100"
"01000000010"
```
frame1:
```
"00011111000"
"01111111110"
"11111111111"
"11001110011"
"11111111111"
"01111111110"
"01100000110"
"00100000100"
```
Need check lengths: "00100000100" = 11? 3+1+5+1+? Let's count: 0 0 1 0 0 0 0 0 1 0 0 =11 yes. "00010001000" = 11. "00111111100" = 11. "01101110110" = 11. "11111111111"=11. "10111111101"=11. "10100000101"=11. "00011011000"=11. Good.
Eyes are zeros in rows 3/4 etc; background shows through. Could add dark eye pixels explicitly for each alien, but zeros enough.

Need draw animation frame toggle. `formation.frame` 0/1.

Draw shots:
- Player shot: vertical cyan capsule with glow: `ctx.fillStyle='rgba(84,242,255,.18)'; fillRect(x-5,y-10,10,20); fillStyle='#d7ffff'; fillRect(x-1.5,y-9,3,14); fillStyle=cyan; fillRect(x-3,y-2,6,4);`
- Enemy shot: amber zigzag: use sine wave based on `s.phase + s.y*0.12`; draw 3 small rects at x offsets; maybe simplest: `ctx.fillStyle='#ff9e6d'; ctx.fillRect(x-2,y-6,4,12); ctx.fillStyle='#ffe3a6'; ctx.fillRect(x-1,y-4,2,8);` plus glow. Need procedural graphics, okay.

Draw player: as above. Invulnerability: flicker via skipping draw on alternating intervals; shield ring:
```
if(invuln>0){ ctx.strokeStyle='rgba(84,242,255,.5)'; ctx.beginPath(); ctx.ellipse(x,y,30,22,0,0,TAU); ctx.stroke(); }
```
Need not hide player entirely maybe alpha=.5.

Draw particles and floaters:
```
for p: alpha=p.life/p.max; ctx.globalAlpha=alpha; fillRect...
for f: ctx.globalAlpha=...; ctx.font='bold 14px Courier New'; ctx.fillText(f.text,f.x,f.y);
```
Need `ctx.textAlign='center'`.

HUD sync maybe called on score/life changes and reset; diagnostics every 100ms in loop to avoid DOM thrash. But we can call each frame; fine. Use `diagTimer` accumulate and update at 0.08s. Need dataset always current on hits maybe call `syncHud()` on score/life; diagnostics update in loop. For inspect, a delay okay. Let's call `syncHud()` whenever score/lives/state changes and also in loop every 0.1s for diag; easier:
```
function syncHud(){
 scoreEl.textContent=...
 ...
 hud.dataset.score=score; ...
 diag.textContent=...
 diag.dataset.playerX=...
}
```
Call every frame? 60fps DOM text updates might be okay but unnecessary. Use `hudTick += dt; if(hudTick>0.1){syncHud(); hudTick=0}`. Also call immediately after events. Good.

Need console logging for verification:
- On init: `console.log('[invaders] ready', snapshot())`.
- On reset: `console.log('[invaders] restart', snapshot())`.
- On firing: maybe `console.log('[invaders] player shot', {x, count})` can be noisy but useful.
- On bunker hit: `console.log('[invaders] bunker damaged', {by, x, cells:...})`.
- On alien killed: `console.log('[invaders] alien destroyed', {score, remaining})`.
- On life lost: `console.log('[invaders] life lost', {lives})`.
- On game end: log.
Could be noisy with many events but fine. Maybe add `const DEBUG = true;` and a `log` helper. Browser inspect console may show last logs; if too noisy, not a problem. Need avoid logs every frame. Good.

Potential issue: browser tool `inspect` may not show console logs accumulated after actions? likely does. We'll see.

Need also window debug API for programmatic verification if tool supports key typing into address? no. But we can expose:
```
window.invaders = {
  snapshot,
  restart: resetGame,
  fire: tryFire,
  move: (dx)=> setPlayerX(player.x+dx),
  damageBunkerAt: ...
};
```
Could be useful if browser tool has hidden evaluate via `key`? No. But no harm. Actually we can use `browser` action "type" with text maybe into a field? not relevant. We could add a hidden input with oninput eval? That would be silly and insecure. Not needed.

Need verify using browser tool: perhaps `browser` action "key" can press and hold? Let's find by trying. If not, on-screen buttons can be clicked. Need coordinate mapping from screenshot. We'll get screenshot and inspect. If canvas responsive width maybe 900; stage max 940? shell width min(100%,940px), topbar etc. Canvas CSS width 100% of stage, stage width shell 940? Wait shell 940; canvas internal 900 but CSS width 100% -> 940, height 647. Browser viewport 1200x800, shell centered with width 940. Stage top maybe 90, bottom 737; controls below viewport maybe need scroll. Browser tool coordinates 1200x800; need click on buttons maybe below y=800 if controls below stage. Let's calculate: body padding top18; topbar height maybe 64 + margin12 =76; stage height 940*620/900=647 => bottom 18+76+647=741; instructions margin12 height~30 =>783; telemetry another~24 =>807; touch controls below ~50 =>857. So controls buttons likely below viewport. Need browser scroll for on-screen buttons, but keyboard works without focus. For verification via clicks, can scroll. Better make shell max-width 900px to match canvas, reducing stage height to620. Topbar height ~70 => body top18+70+12=100; stage bottom720; instructions margin12 height~30=>762; telemetry ~20=>782; controls below 800 maybe partly. Could place touch controls inside instructions row to fit. Or make canvas max-width 860? We can set shell width min(100%,900px); stage height620 exactly. Topbar maybe 70; total from top 18+70+10=98; stage bottom718; instructions at 730-760; telemetry at 766-786; controls at 790-830 (partly off). Could use `browser scroll` to reach. But keyboard tests don't need visible buttons. For screenshot, initial canvas fits nice. Need controls display visible in viewport maybe instructions at bottom; touch controls can be in instructions row to fit. Let's put touch controls in the same row as instructions at y~730, no separate below. Telemetry maybe small line below, at y~770. That fits. Actually body can scroll; tool can scroll. Fine.

Maybe make stage height 580 by using canvas internal H=600? Need ensure enough vertical room. Could use W=900,H=600. PlayerY=532, bunkerY=420, formation bottom~292, zone=500, ground=570. Still fine. Stage CSS height600, top 100 -> bottom700; instructions+controls+telemetry fit within800. Let's reduce H to600. Need adjust constants:
W=900,H=600; LEFT=24,RIGHT=876,TOP=52; PLAYER_Y=532; PLAYER_ZONE_Y=500; BUNKER_Y=420; groundY=566; alien originY=88, stepY=42, AH=24 => bottom=88+168+24=280; zone distance220; needs 13 descents (18*13=234) ->514 >500, game over after ~12 descents. Fine. Bunker bottom=462, player top ~508, gap46. Good.
Player shot spawn y=506; enemy shot to player y=532; fine.
Alien formation startX=142, stepX=58, AW=36, 11 cols => width=10*58+36=616, left142 right758; travel to right edge 876-8=868 =>110px, left edge32 =>110px; speed~45 =>2.4s each side; descent every4.8s; game over ~58s. Good.

Let's set H=600. Stage CSS width100% height auto 600/900 => if shell900, height600. Great.

Need tool viewport 1200x800; topbar maybe 70, stage top~98, bottom698; instructions at 710-740; telemetry at 745-765; controls maybe included in instructions at 710-750; all visible. Good.

Let's structure bottom row:
```
<section class="bottom">
 <div class="controls-copy">
  <span class="label">CONTROLS</span>
  <kbd>←</kbd><kbd>→</kbd> / <kbd>A</kbd><kbd>D</kbd> move · <kbd>Space</kbd> fire · <kbd>R</kbd> restart
 </div>
 <div class="touch-controls"> buttons </div>
</section>
<div class="telemetry" id=diag>...</div>
```
Bottom row height ~44, telemetry ~22. Fits.

Need restart button in topbar; overlay button too.

Need responsive: on narrow width, bottom row wraps; stage scales. Fine.

Let's now write code. Need be meticulous with JS syntax. I'll draft here mentally then use write.

JS skeleton:

```
(() => {
'use strict';
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const W=canvas.width,H=canvas.height;
const LEFT=24, RIGHT=W-24, TOP=48, GROUND=566;
const PLAYER_Y=532, ZONE_Y=500;
const PLAYER_SPEED=320, PLAYER_HALF=22;
const PLAYER_FIRE_CD=0.28, PLAYER_MAX_SHOTS=3, PLAYER_SHOT_TTL=2.0;
const ENEMY_MAX_SHOTS=6, ENEMY_SHOT_TTL=5.0;
const A_COLS=11,A_ROWS=5,A_W=36,A_H=24,A_DX=58,A_DY=42,A_X=142,A_Y=88;
const TOTAL_ALIENS=A_COLS*A_ROWS;
const B_X=[120,300,510,690], B_Y=420, CELL=6, B_COLS=15,B_ROWS=7;
...
const scoreEl=..., etc.
let seed=...;
function srand(s){ seed=s>>>0; }
function rnd(){ seed=(Math.imul(seed,1664525)+1013904223)>>>0; return seed/4294967296; }
const stars = (()=>{ const old=seed; srand(0x5EED); const arr=[]; ...; seed=old; return arr;})();
```
Need careful `srand` and `seed` restoration: `const old=seed; ... seed=old;`. Fine.

Sprites arrays need define maybe with helper to ensure lengths. We'll define `const SPRITES = [[[...],[...]], ...]`.

State variables:
```
let state, score, lives, player, formation, aliens, bunkers, playerShots, enemyShots, particles, floaters, keys, fireCooldown, enemyFireTimer, invuln, elapsed, lastTime, hudTick, gameMessage;
```
`player={x:W/2}`.
`formation={x:0,y:0,dir:1,frame:0,anim:0.42}`.
`aliens` 2D array of `{alive:true}`.
`bunkers` array with cells.

Helper:
```
function makeBunkers(){ return B_X.map((x,i)=>({x,y:B_Y,w:B_COLS*CELL,h:B_ROWS*CELL,cells:...,hits:0,flash:0,id:i}));}
function bunkerShape(r,c){
 let solid;
 if(r===0) solid=c>=5&&c<=9;
 else if(r===1) solid=c>=3&&c<=11;
 else if(r===2) solid=c>=1&&c<=13;
 else solid=true;
 if(r>=5 && c>=6 && c<=8) solid=false;
 return solid;
}
```
For 15 cols indices0..14. Top arch r0 c5..9 (5), r1 c3..11 (9), r2 c1..13 (13), r3/r4 15 each, r5/r6 12 each (remove c6-8) =>5+9+13+15+15+12+12=81 cells each, total324. Good. Need maybe center notch 3 cells wide from bottom; nice.

`countBunkerCells()` sum.

`alienX(c)=A_X+c*A_DX+formation.x`; `alienY(r)=A_Y+r*A_DY+formation.y`.

`aliveAliens()` loops and returns objects with r,c,x,y maybe allocate each frame; fine small. Could avoid allocation but okay.

`bottomAlienPerColumn()` maybe:
```
function pickEnemyShooter(){
 const perCol=Array(A_COLS).fill(null);
 for(r=0;r<A_ROWS;r++) for(c=0;c<A_COLS;c++) if(aliens[r][c].alive) perCol[c]={r,c,x:...,y:...};
 const candidates=perCol.filter(Boolean);
 if(!candidates.length)return null;
 return candidates[Math.floor(rnd()*candidates.length)];
}
```
This picks bottom-most per column because iterating r ascending and overwrite. Good.

`tryFire()`:
```
function tryFire(){
 if(state!=='playing'||fireCooldown>0||playerShots.length>=PLAYER_MAX_SHOTS) return false;
 playerShots.push({x:player.x,y:PLAYER_Y-26,vy:-620,w:4,h:12,ttl:PLAYER_SHOT_TTL});
 fireCooldown=PLAYER_FIRE_CD;
 spawnMuzzle...
 log('player shot', {x:Math.round(player.x), active:playerShots.length});
 return true;
}
```
Need `spawnParticles` maybe defined later as function declaration (hoisted), fine.
`fireEnemyShot()` similar.

`resetGame()`:
```
function resetGame(){
 srand(0xC0FFEE);
 state='playing'; score=0; lives=3; player={x:W/2}; formation={...}; aliens=...; bunkers=makeBunkers(); playerShots=[]; enemyShots=[]; particles=[]; floaters=[]; keys.clear(); fireCooldown=0; enemyFireTimer=0.9; invuln=0; elapsed=0; hudTick=0; overlay.classList.add('hidden'); overlay.dataset.state=''; lastTime=performance.now(); syncHud(); log('restart', snapshot());
}
```
But `keys` must be initialized before reset; define `const keys=new Set();` before.
Need overlay hidden class and `aria-hidden`.
`syncHud()` needs state variable. `snapshot()` needs all state. Fine.

Input handlers after function declarations maybe before reset:
```
window.addEventListener('keydown', e=>{
 const code=e.code;
 if([...].includes(code)) e.preventDefault();
 if(code==='KeyR'&&!e.repeat){ resetGame(); return; }
 if(state!=='playing') { if(code==='Space'&&!e.repeat) resetGame()? no, overlay button; maybe space restarts? Not required. We can allow Space to restart? Could, but not needed. }
 if(!keys.has(code)){
   if(code==='ArrowLeft'||code==='KeyA') movePlayer(-10);
   ...
   if(code==='Space') tryFire();
 }
 keys.add(code);
});
window.addEventListener('keyup', e=>keys.delete(e.code));
window.addEventListener('blur', ()=>keys.clear());
```
Need if gameover and arrow keys pressed, `movePlayer` should not move; check inside movePlayer. Good. Add `e.repeat` check for nudge? `!keys.has(code)` prevents repeats while held; if keyup happens between repeats, fine. For browser key action keydown+keyup, nudge occurs.
`movePlayer(dx)`: clamp.
`setPlayerX(x)` maybe debug.

Buttons:
```
function bindMoveButton(id, code, dir){
 const el=...
 let downAt=0;
 el.addEventListener('pointerdown', e=>{e.preventDefault(); downAt=performance.now(); keys.add(code);});
 const release=()=>keys.delete(code);
 ['pointerup','pointercancel','pointerleave'].forEach(ev=>el.addEventListener(ev, release));
 el.addEventListener('click', e=>{ if(performance.now()-downAt<260) movePlayer(dir*26); });
}
```
Potential: pointerdown + pointerup + click, continuous movement during 50ms -> ~16px; click adds 26 -> total42. Fine. For browser tool click maybe pointerdown/up happen same instant; continuous 0; adds26. Good. Need `downAt` default0, if click without pointerdown (keyboard activation) `performance.now()-0 >260`, no move. Better handle keyboard activation (Enter/Space) by also move; but browser tool click via pointer. Could set default `downAt=performance.now()` at bind? Then keyboard click later >260 no move. We can add `el.addEventListener('click', e=>{ if(e.detail===0) movePlayer(dir*26); else if(...) ...})`; `e.detail===0` for keyboard-generated click. Fine.
Fire button:
```
fireBtn.addEventListener('pointerdown', e=>{e.preventDefault(); if(state==='playing'){ keys.add('Space'); tryFire(); }});
...
fireBtn.addEventListener('click', e=>{ if(e.detail===0) tryFire();});
```
Need pointerdown call tryFire; if browser click, pointerdown fires shot. Good.
Potential issue: adding 'Space' to keys on pointerdown and not removed if pointerup outside button; pointerleave handles. Fine.

Restart buttons:
`restartBtn.addEventListener('click', resetGame); overlayRestart.addEventListener('click', resetGame);`

`endGame(won, reason)`:
```
if(state!=='playing') return;
state=won?'win':'gameover';
keys.clear();
overlayTitle.textContent=won?'SECTOR CLEARED':'GAME OVER';
overlayEyebrow.textContent=...
overlayText.textContent=... score...
overlayRestart.textContent=won?'Play again':'Try again';
overlay.classList.remove('hidden');
overlay.setAttribute('aria-hidden','false');
syncHud(); log('end', snapshot());
```
Need overlay panel maybe score display. Good.

`update(dt)`:
```
elapsed+=dt;
fireCooldown=Math.max(0,fireCooldown-dt);
invuln=Math.max(0,invuln-dt);
for b flash...
let dir=(keys.has('ArrowRight')||keys.has('KeyD')?1:0)-(keys.has('ArrowLeft')||keys.has('KeyA')?1:0);
if(dir) movePlayer(dir*PLAYER_SPEED*dt);
if(keys.has('Space')) tryFire();
updateFormation(dt);
if(state!=='playing') { updateEffects(dt); return; } // if formation ended game
updateProjectiles(dt);
if(state!=='playing') ...;
updateEffects(dt);
hudTick+=dt; if(hudTick>=0.1){syncHud();hudTick=0;}
```
Need `updateFormation` may call endGame; if so avoid firing etc. Good.
`updateEffects` also decrement b.flash, particles, floaters. Could do in update regardless.

`updateFormation(dt)`:
```
formation.anim-=dt; if<=0 { formation.frame^=1; formation.anim=0.38; }
const remaining=countAlive();
if(remaining===0){ endGame(true,'All alien...'); return; }
const speed=42+(1-remaining/TOTAL_ALIENS)*110+Math.min(25,elapsed*0.25);
let minX=Infinity,maxX=-Infinity,maxBottom=-Infinity;
for r,c alive... minX=Math.min(...), maxX=Math.max(...+A_W), maxBottom=Math.max(...+A_H);
let dx=formation.dir*speed*dt;
let edge=false;
if(formation.dir>0 && maxX+dx>RIGHT-6){ dx=RIGHT-6-maxX; edge=true;}
if(formation.dir<0 && minX+dx<LEFT+6){ dx=LEFT+6-minX; edge=true;}
formation.x += Math.max? dx could be negative if maxX already beyond boundary; but after reversal maybe? Need clamp dx to avoid moving backwards unexpectedly. If `RIGHT-6-maxX` negative, maxX over boundary; maybe due to dt or previous formation. Could happen if formation.x + max base > boundary after descent? Descent is y only, x unchanged. Should be okay. But to be safe: `if (edge) dx = Math.max(0, target-maxX)` for right; for left `dx = Math.min(0, target-minX)`? Let's derive:
right: proposed x too far; we want move to boundary: dx = max(0, RIGHT-6-maxX) (could be 0 if already at boundary). left: dx = min(0, LEFT+6-minX) (negative or 0). Good.
Then if edge: `formation.x += dx; formation.dir*=-1; formation.y+=18; log('formation reverse', {...})`. But if dx=0 and repeated edge check after reversal, next frame moving opposite so no edge. Fine.
else formation.x += dx.
After descent, check new maxBottom+18 >= ZONE_Y -> game over. Use maxBottom computed before + (edge?18:0). If >= ZONE_Y, endGame(false,'The invaders crossed the defense line.'). Need also maybe check without edge: if maxBottom>=ZONE_Y. Use `maxBottom + (edge?18:0) >= ZONE_Y`.
Then alien fire timer:
```
enemyFireTimer-=dt;
if(enemyFireTimer<=0){ fireEnemyShot(remaining); const ratio=remaining/TOTAL; enemyFireTimer=Math.max(0.34,(0.5+rnd()*0.85)*(0.55+0.45*ratio)); }
```
Need if game ended due to breach, don't fire. Put fire before breach check maybe not important. Better after check with return.
Need `countAlive()` could maintain `aliensAlive` variable to avoid loops. Use variable updated on kills. Let's define `let aliensAlive;` set 55 on reset. On kill decrement. Use for HUD and speed. `aliveAliens` function still loops for edge/fire. Good.

`updateProjectiles(dt)`:
```
for(let i=playerShots.length-1;i>=0;i--){
 const s=playerShots[i]; s.ttl-=dt; if(s.ttl<=0){splice;continue;}
 const y0=s.y,y1=s.y+s.vy*dt;
 if(traceProjectile(s,y0,y1,'player')){splice;continue;}
 s.y=y1;
 if(s.y<TOP-10) splice;
}
for enemy ... similar:
 if(traceProjectile(...)) ...
 s.y=y1; s.phase+=dt*12;
 if(s.y>H+20) splice;
```
Need `s.phase` update for drawing; fine.
`traceProjectile`:
```
const steps=Math.max(1,Math.ceil(Math.abs(y1-y0)/2));
for(let i=1;i<=steps;i++){
 const y=y0+(y1-y0)*i/steps;
 if(hitBunker(s.x,y,s,kind)) return true;
 if(kind==='player' && hitAlien(s.x,y,s)) return true;
 if(kind==='enemy' && hitPlayer(s.x,y,s)) return true;
}
return false;
```
Potential problem: player shot hits bunker cells via sample offsets; if a cell is found and removed, we immediately return true. Good.
Potential problem: player shot could hit alien first before bunker if y0 starts above bunker? No, player shots spawn below bunkers and move up; y0<y1? y1<y0; sampling from y0 downward in y (i.e., decreasing), so bunker encountered before alien. Good.
Enemy shots spawn above bunkers and move down; bunker before player. Good.

`hitBunker(x,y,s,kind)` needs check y within bunker bounds for each offset. If x+off inside and y inside and cell solid, call damage. But if projectile center is in gap and offsets overlap adjacent bunker, shot hits. Fine. Need avoid hitting a bunker cell that is behind another bunker? bunkers don't overlap. Good.
```
function hitBunker(x,y,s,kind){
 const offsets=[-s.w/2,0,s.w/2];
 for(const b of bunkers) {
   if(y<b.y||y>=b.y+b.h) continue;
   for(const off of offsets){
      const px=x+off;
      if(px<b.x||px>=b.x+b.w) continue;
      const c=Math.floor((px-b.x)/CELL), r=Math.floor((y-b.y)/CELL);
      if(b.cells[r][c]){
         damageBunker(b,px,y,kind);
         return true;
      }
   }
 }
 return false;
}
```
Need if y exactly b.y+b.h maybe skip; okay. `cells[r]` always defined if y within. Good.
`damageBunker`:
```
function damageBunker(b,x,y,kind){
 const lx=(x-b.x)/CELL, ly=(y-b.y)/CELL;
 const radius=kind==='player'?1.45:1.3;
 let removed=0;
 for r,c if solid:
   const dx=(c+0.5)-lx, dy=(r+0.5)-ly;
   const bias = kind==='player' ? Math.max(0, dy)*? ... 
```
Need perhaps directional bias: player shot from below should remove cells above impact more than below? Actually impact at first solid cell from bottom; the cells below are already likely gaps; crater around impact okay. Enemy shot from above first solid; crater around impact okay.
Use `dist2 = dx*dx + dy*dy; if(dist2 < radius*radius + rnd()*0.4)`. This may remove cells not adjacent to path, creating gaps. Need ensure shots can eventually pass through. After one hit, cells around impact removed; next shot from same x may pass if center cell removed and no adjacent cell within offsets. But with width offsets, if side cells remain, shot still hits. Need ensure center column removed sufficiently. `radius=1.7` maybe removes 2-3 cells around center, including center. With random edge, gap emerges after 1-2 shots. Good. Let's use radius `1.6` and deterministic condition with slight random; maybe remove ~8 cells. Need ensure `dx=dy=0` center removed always since dist2 of cell center to impact can be up to .5^2+.5^2=.5 < radius^2. So center cell removed. Side cells at c±1 have dx~1, dist2~1.25 <2.56, removed. So a 3-wide gap created. Great. Repeated shots will widen. Good.
```
b.hits++; b.flash=.2;
spawnParticles(x,y,kind==='player'?'#9dffb1':'#ffb26b',7,70);
log('bunker damaged', {by:kind, x:Math.round(x), y:Math.round(y), cells:countBunkerCells()});
```
Need log maybe noisy; okay.

`hitAlien(x,y,s)`:
```
for(let r=A_ROWS-1;r>=0;r--){
 const ay=alienY(r);
 if(y+s.h/2<ay||y-s.h/2>ay+A_H) continue;
 for c...
   if(alive && x+s.w/2>ax && x-s.w/2<ax+A_W){ killAlien(r,c,...); return true;}
}
return false;
```
Need y±h/2: player shot h=12; with sample step2, fine.
`killAlien`:
```
aliens[r][c].alive=false; aliensAlive--; const val=[40,30,20,20,10][r]; score+=val; floaters.push(...); spawnParticles(...,14,120); syncHud(); log(...); if(aliensAlive===0) endGame(true,...);
```
Need `endGame` uses score. Good.
`hitPlayer(x,y,s)`:
```
if(Math.abs(x-player.x)>PLAYER_HALF+s.w/2) return false;
if(y < PLAYER_Y-22 || y > PLAYER_Y+16) return false;
if(invuln>0){ spawnParticles(...,'#54f2ff',5,60); log('shield deflect'); return true; }
lives--; invuln=1.6; enemyShots.length=0; spawnParticles(...); floaters.push({text:'-1 LIFE',...}); syncHud(); log('life lost',{lives}); if(lives<=0) endGame(false,'...'); return true;
```
Need careful: we're iterating `enemyShots` backwards and inside `hitPlayer` we set `enemyShots.length=0`; then outer loop after `traceProjectile` returns true does `enemyShots.splice(i,1)` on empty array, harmless. But loop index continues with i-- from original length, splices on empty harmless. Could be okay but maybe weird. Better avoid clearing array inside hitPlayer; instead set `clearEnemyShots=true` and handle after loop, or simply don't clear, rely on invuln. But "brief protection from repeated damage" means invuln enough. Could still have multiple enemy shots on screen; when invuln, they get removed on contact. That's okay. To avoid repeated damage, no need clear. But classic clear on hit helps. Could set a flag `let enemyShotsCleared=false;` and after update loop if flag, enemyShots=[]; But outer loop uses variable reference; if we reassign, need handle. Simpler: don't clear; just invuln. However multiple shots may hit during invuln and be removed one by one, no life lost. Good. Maybe spawn shield particles. Let's not clear to avoid loop issues. But after respawn, enemy shots that were near player may still be above and come down; invuln covers 1.6s. Fine.
Need if `lives<=0`, `endGame` sets state and keys.clear; outer loop still processes remaining shots but hitPlayer checks state? Could add `if(state!=='playing') return false;` at top of trace/hitPlayer. Then no further life loss. Good.

`endGame` can be called from killAlien during player shot loop; then remaining player shots update might still call hitAlien and kill more aliens? Need guard `if(state!=='playing') break;` in loops or `traceProjectile` returns false if state not playing. Add at start of `updateProjectiles` loops:
```
if(state!=='playing') break;
```
and in `hitAlien` check state. Good. But state can only win when last alien killed; no more aliens anyway. Fine.

`updateEffects(dt)`:
```
for b flash=Math.max(0,...)
for particles: life-=dt; x+=vx*dt; y+=vy*dt; vy+=80*dt; filter via backwards
for floaters: life-=dt; y-=24*dt; filter
```
Need particles array splice. Fine.

`draw(t)`:
```
ctx.clearRect...
drawBackground(t);
drawBunkers();
drawAliens();
drawShots();
drawCannon(t);
drawEffects();
if(state!=='playing') maybe draw dim? overlay covers.
```
Need draw order: background, bunkers, aliens, shots, cannon, particles. Alien shots should appear over bunkers, player shots too. Fine.
Maybe draw formation direction arrow on top? not necessary.

`drawBackground(t)`:
```
const g=ctx.createLinearGradient(0,0,0,H); g.addColorStop...
ctx.fillStyle=g; fillRect...
stars...
ctx.fillStyle='rgba(84,242,255,.08)'; for y... optional
ctx.setLineDash([3,9]); ctx.strokeStyle='rgba(...)'; lines at LEFT,RIGHT from TOP to GROUND...
ctx.setLineDash([2,10]); ctx.strokeStyle='rgba(255,92,168,.18)'; line at ZONE_Y; ctx.fillText('BREACH LINE', RIGHT-?, ZONE_Y-6);
ground gradient...
```
Need avoid expensive createLinearGradient every frame? okay. Could precompute but fine.
Stars use `ctx.globalAlpha`; reset to1. Use fillRect. Fine.
Scanlines with globalAlpha maybe: `ctx.fillStyle='rgba(255,255,255,0.012)'; for(let y=0;y<H;y+=4) ctx.fillRect(0,y,W,1);`
Top text: `ctx.font='10px "Courier New", monospace'; ctx.fillStyle='rgba(...)'; ctx.fillText('SECTOR 01 // DEFENSE GRID', LEFT, 28); ctx.textAlign='right'; ctx.fillText('▲ ALIEN VECTOR', RIGHT, 28); ctx.textAlign='left';`
Need `ctx.save/restore` around text align maybe.

`drawBunkers` details as above.
`drawAliens`: use `SPRITES[r%3][formation.frame]`; need sprite strings length. Use `const px=3; const ox=x+(A_W-11*px)/2; const oy=y+(A_H-8*px)/2;` A_H=24, 8*3=24 -> oy=y. A_W=36, 11*3=33 -> ox=x+1.5. Use fillRect with fractional x okay. Could use `Math.round`. Better set px=3, ox=x+1.5; fine. Draw aura: `ctx.fillStyle=color; ctx.globalAlpha=.10; ctx.fillRect(x-2,y-2,A_W+4,A_H+4); ctx.globalAlpha=1;` Then fillRect for pixels. Then eyes? Zeros in pattern show background, okay. Add small highlight row: maybe not.
Need use `ctx.fillStyle=color` once per alien. Could set `ctx.shadowColor=color; ctx.shadowBlur=6;` then draw all rects, then reset. With 55 aliens, setting shadow per alien might be a bit heavy but okay at 900x600. Maybe skip shadow; use aura. Fine.

`drawShots`:
```
for s of playerShots: ...
for s of enemyShots: ...
```
Need enemy shot phase animation:
```
const wiggle=Math.sin(s.phase)*2;
ctx.fillRect(s.x+wiggle-2, s.y-7,4,14)...
```
But collision x constant; drawing wiggle ±2 okay. Need not affect gameplay.
Player shot glow: use `ctx.fillStyle='rgba(84,242,255,.18)'; fillRect(s.x-5,s.y-12,10,22)`. fine.

`drawCannon(t)`:
```
ctx.save();
ctx.translate(player.x, PLAYER_Y);
if(invuln>0){ ctx.globalAlpha = Math.floor(t*14)%2 ? .45 :1; draw shield ellipse}
// glow
ctx.fillStyle='rgba(84,242,255,.08)'; ctx.beginPath(); ctx.ellipse(0,4,30,18,...); fill();
// flame
const flame=8+Math.sin(t*25)*3;
ctx.fillStyle='#ff9d5c'; ctx.beginPath(); moveTo(-7,14); lineTo(0,14+flame); lineTo(7,14); close; fill();
ctx.fillStyle='#ffe6a6'; smaller...
// body path
ctx.beginPath(); moveTo(-24,14); lineTo(-18,2); lineTo(-8,-3); lineTo(-5,-16); lineTo(-3,-24); lineTo(3,-24); lineTo(5,-16); lineTo(8,-3); lineTo(18,2); lineTo(24,14); close();
ctx.fillStyle='#55e8ff'; fill(); ctx.strokeStyle='#d7ffff'; lineWidth=1.5; stroke();
// dark base / accents
ctx.fillStyle='#0b2e4a'; fillRect(-16,8,32,5);
ctx.fillStyle='#e9ffff'; fillRect(-2,-20,4,12);
ctx.fillStyle='#ff5ca8'; fillRect(-3,2,6,4);
ctx.restore();
```
Need body top barrel: player shot spawn y=506 = PLAYER_Y-26, just above barrel top (508). Good.
`invuln` shield ring drawn before body with globalAlpha flicker; okay.

`drawEffects`: particles with globalAlpha; floaters with text. Need reset `ctx.globalAlpha=1`.

`draw` when state gameover/win could still draw; overlay dims. Fine.

`snapshot()`:
```
return {
 state, score, lives, playerX:Math.round(player.x*10)/10,
 aliens: aliensAlive,
 bunkerCells: countBunkerCells(),
 formationX: Math.round(formation.x*10)/10,
 formationY: formation.y,
 formationDir: formation.dir>0?'right':'left',
 playerShots: playerShots.length, enemyShots: enemyShots.length,
 invuln: Math.round(invuln*100)/100
};
```
Need `countBunkerCells` maybe loop 4*105=420 each call; fine.
`log(label, data)`:
```
console.log('[invaders] '+label, data);
```
Need avoid logging snapshot with object that changes? We create new object; fine.

`syncHud()`:
```
scoreEl.textContent=String(score).padStart(4,'0');
aliensEl.textContent=String(aliensAlive).padStart(2,'0');
for(let i=0;i<3;i++) pips[i].classList.toggle('lost', i>=lives);
stateEl.textContent = state==='playing' ? 'ONLINE' : state==='win'?'VICTORY':'OFFLINE';
hud.dataset.state=state; ... 
diag.textContent = `TELEMETRY // cannon ${Math.round(player.x)} · formation ${formation.x>=0?'+':''}${formation.x.toFixed(1)} ${formation.dir>0?'→':'←'} · aliens ${aliensAlive} · bunker ${countBunkerCells()} · shots P${playerShots.length}/E${enemyShots.length} · lives ${lives} · score ${score}`;
diag.dataset.playerX=... etc
```
Need `hud.dataset.bunkerCells` maybe. Add `document.body.dataset.gameState=state`.
Need pips created in HTML as 3 spans; query all.
`stateEl` maybe in HUD as status stat. Let's include `<div class="stat status"><span>STATUS</span><strong id="status">ONLINE</strong></div>` maybe topbar crowded. Could omit; diag shows state. But nice. Need restart button. HUD width: brand ~220, stats 4*~100=400 + button100 =500, total720 fits900. Fine.

HTML topbar:
```
<div class="hud" id="hud">
 <div class="stat"><span>SCORE</span><strong id="score">0000</strong></div>
 <div class="stat"><span>LIVES</span><div class="life-pips" id="lives">...</div></div>
 <div class="stat"><span>ALIENS</span><strong id="aliens">55</strong></div>
 <button id="restart" class="restart">↻ RESTART</button>
</div>
```
Maybe status in diag. Good.

Overlay:
```
<div id="overlay" class="overlay hidden" aria-hidden="true">
 <div class="panel">
  <p class="eyebrow" id="overlayEyebrow">MISSION REPORT</p>
  <h2 id="overlayTitle">GAME OVER</h2>
  <p id="overlayText"></p>
  <div class="final-score">FINAL SCORE <b id=finalScore>0000</b></div>
  <button id="overlayRestart">RESTART MISSION</button>
  <p class="hint">or press <kbd>R</kbd></p>
 </div>
</div>
```
Need reset hide and set aria-hidden.

Need keyboard R works even when overlay shown. Good.
Maybe Space on gameover could restart? Not required; but could add: if state!=='playing' and code==='Space' && !e.repeat then resetGame(); return; This might help. But user expects restart button; no harm. However if gameover and user presses Space to fire, restarts unexpectedly; overlay says R. We'll not.

Need `endGame` overlay final score. Good.

Potential issue: `resetGame()` calls `log('restart', snapshot())` at init too; maybe label 'ready/restart'. Fine.

Need initial `formation.x=0`, `formation.y=0`, `formation.dir=1`. Aliens center col c5 at x=142+5*58=432, width36 => center450. Great.

Need bunker positions x=120,300,510,690; width90. Center gap 390..510. Player x=450; shot half width2 + offsets±2 => x offsets448,450,452, all in gap. Good. Center shot clears bunkers and hits alien c5 (span432..468). Great. So opening formation firing from center yields score after ~0.35s. Need test with browser: press Space, wait maybe 0.5s, inspect diag score. Need tool may not wait; use `motion` or repeated screenshot. Could also use `browser` action "screenshot" after a short delay? Each tool call takes some time, likely enough. Could use `motion` action to capture frames over e.g. 1s. We'll see.

Need alien motion check: diag formation x changes over time; after 1s, +~45. Need use `motion` maybe. If not, repeated `inspect` after a second maybe. Could use `browser` action "motion" likely captures frames and maybe returns motion frames; need see. Also could add a visible formation offset in telemetry; inspect after some time. Need time pass between tool calls. likely yes.

Need bunker damage check: player shot from center won't hit bunker. We can move cannon to x=530 via on-screen right button clicks (26 each: 450->476->502->528) then fire; shot from x=528 hits bunker3 (510..600). Need 3 clicks on right button. Need button coordinate. We can get screenshot and DOM inspect maybe. Or use keyboard ArrowRight with key hold perhaps. Let's make on-screen right button discrete 30px so 2 clicks ->510 exact edge; 3 ->540. Use 30. Need x=450+3*30=540, within bunker3. Good. But if browser click tool coordinates maybe need scroll? We'll position bottom row visible. Could also use keyboard nudge 10px and press ArrowRight 9 times; tool call count maybe okay but 9 calls. On-screen button 3 calls better. Maybe add shift? Not needed.

Need button click also `pointerdown` adds key and continuous movement for duration. If browser click is fast, discrete 30. Good. Need right button located maybe at x~? We'll use screenshot to find. Could use DOM inspect with selector? Browser inspect may output element positions? likely not, but screenshot can show. Need maybe tool `click` with x,y. We'll get screenshot and estimate. Alternatively add `id` and use keyboard? No selector support. Could use `browser` action "key" with text "ArrowRight" maybe simpler. But need multiple presses; maybe key action supports repeat count via text? likely not. Maybe `type` with text "dddd" could send keydown for each char? Could move 4*10=40. Hmm.

Could add a dedicated "aim at bunker" button? Not appropriate. Could place bunker such that center shot hits bunker and alien shots from center clear? But then score test harder.

Maybe implement a special test helper via URL hash? e.g., `?test=...` no network; can use initial hash to set player x. But browser tool cannot navigate with hash? maybe reload with index.html? no. Could add keyboard shortcut "B" to move cannon to bunker? Not in requirements and artificial. On-screen buttons are natural.

Maybe we can use browser `drag` action to move cannon by dragging on canvas? Could implement pointer drag on canvas to move cannon to pointer x. That is natural and useful: clicking/dragging canvas moves cannon. Then browser `click` at x=540 on canvas would set player x? Hmm. We can implement pointer events on canvas:
```
canvas.addEventListener('pointerdown', e=>{ setPlayerX(scaleX(e)); keys.add('PointerMove'); });
canvas.addEventListener('pointermove', e=>{ if(pointerActive) setPlayerX(scaleX(e)); });
```
This enables mouse/touch aiming, and browser click at any canvas x directly moves cannon. Also could fire on click? Maybe pointerdown moves, pointerup fires? That would be intuitive on mobile: tap to move + fire. But requirement says Space to fire; adding click-to-fire is okay. We can make canvas pointerdown set cannon x and `tryFire()`; that would make verification trivial: click at x=540, fires at bunker; click at center, fires at alien. But is that undesirable? It adds alternate control, not conflicting. Need display maybe "Tap/click field to aim + fire". Could be nice. But careful: browser clicking on canvas to focus might inadvertently fire; fine. Could double-fire if pointerdown + key? no.

Let's implement canvas pointer interaction:
```
let pointerAiming=false;
function canvasX(e){ const rect=canvas.getBoundingClientRect(); return (e.clientX-rect.left)*(W/rect.width); }
canvas.addEventListener('pointerdown', e=>{
 e.preventDefault();
 if(state!=='playing') return;
 setPlayerX(canvasX(e));
 pointerAiming=true;
 canvas.setPointerCapture?.(e.pointerId);
 tryFire();
});
canvas.addEventListener('pointermove', e=>{ if(pointerAiming && state==='playing') setPlayerX(canvasX(e)); });
['pointerup','pointercancel'].forEach(... pointerAiming=false; release capture)
```
But if browser click at x=540 on canvas, player moves to540 and fires immediately. Great for bunker test. Need ensure stage overlay hidden; click on canvas coordinates within stage. Need coordinate mapping: canvas displayed width maybe 900 (shell900) and height600; stage left=(1200-900)/2=150, top maybe 100. So click at browser x=150+540=690, y=100+450=550. Need screenshot to confirm. Could use `browser` action "drag" from x to x? Maybe click at x=690,y=500. Since y only used for x mapping, any y within canvas works. Good. This avoids needing on-screen button positions. Need display controls mention "Click/tap the field to aim + fire" maybe. Good.

But pointerdown on canvas also fires; if user clicks to focus then a shot occurs. Fine. Need prevent default to avoid text selection. Good.

Need `setPlayerX` clamps within playfield: `PLAYER_HALF+LEFT`? Keep cannon within playfield: clamp x to [LEFT+PLAYER_HALF, RIGHT-PLAYER_HALF] = [46,854]. Good. The bunker at x=690..780, reachable. Player position reset to W/2=450. Good.

Need maybe on-screen buttons still provide movement/fire; fine.

Need maybe `pointerAiming` with pointer capture; release on pointerup. If pointer leaves canvas while captured, pointermove still works; fine.

Need no external network. Good.

Now, test plan via browser:
- reload: inspect console/DOM, screenshot.
- maybe use `browser` action "key" with text "ArrowRight" to check movement; then inspect diag x. Need be careful if key action text uses "ArrowRight" or "d". Could just use `click` on canvas at known x to move; that's movement via pointer, not keyboard. But requirement says keyboard movement; need test keyboard too. Use browser key action. Need know syntax. We can try both. Since key events are on window, browser key tool should dispatch to page. We'll use `action:"key", text:"ArrowRight"` maybe. If tool expects a single key like "d", use `text:"d"`. We'll try and inspect diag. If no movement, try "d" or on-screen button.
- firing via Space: `action:"key", text:"Space"` or `" "` maybe. We can also use fire button click. Need verify keyboard specifically. We'll try. Add `keydown` console log to see event code maybe:
```
window.addEventListener('keydown', e=> log('key down',{code:e.code,key:e.key}) );
```
This might be noisy but helps know. Could remove after. We'll keep maybe only for arrow/space? Fine. Actually log every key could reveal tool behavior. Good.
- alien motion: wait with `motion` or repeated inspect.
- shot hitting alien: click canvas at center x=450 (browser x=600, y=400) to move+fire; wait; inspect diag score and log.
- shot hitting bunker: click canvas at x=540 (browser x=690) to move+fire; wait; inspect diag bunker cells and log. Need click after score test; note player x becomes540, then need reset to initial for restart test.
- enemy shots maybe hit bunkers too; we can inspect logs after a few seconds. Fine.
- Restart: click restart button (need coordinate from screenshot) or press R key; inspect diag initial values. Need verify initial formation, bunkers, lives, score. Could use `key` "r" if R key handled (e.code KeyR). Tool `key` text "r" should dispatch code KeyR. Or click button. We'll do both maybe. Need ensure restart button is accessible and overlay hidden. Use screenshot to locate; likely at top right x~1050,y~50. Use browser click with coordinates. If fails, use key R.
- Game over/win states: hard to fully verify (would require waiting ~60s or clearing 55 aliens). We can at least verify logic via code and maybe simulate by exposing debug hook? Could add `window.invaders.debug` with methods to force game over/win? Might be useful to test overlay/restart. But requirement doesn't explicitly ask to verify game over/win; verify list focuses movement/firing, alien motion, shot hitting bunker/alien, restart. We can note game over/win not fully verified. But perhaps we should test overlay via debug function if available. Since we can't evaluate JS, no. Could add hidden keyboard shortcut? Not needed.

Need maybe check aliens reaching player zone game over: not verified. Note in final.

Need maybe check lives loss: enemy shots may hit player; could wait and inspect. But not explicitly in verify list; we should note unverified if not. Could try to let game run ~10s and see lives. But browser tool interactions take time; maybe `motion` action can capture frames over duration. We'll see.

Need maybe test invulnerability: not in verify list. note unverified.

Need maybe check projectile lifetime/fire rate: code-enforced; can inspect multiple shots via holding Space? Could note code review only.

Let's write file now. Need ensure all strings valid. Let's produce carefully.

One more thought: `window.addEventListener('keydown')` with `e.preventDefault()` for Space etc. Browser tool might use `key` action with text "Space" and dispatch keydown+keyup; our `tryFire()` on keydown works. Good.

Need `keydown` log might produce many logs with `code` from tool; okay.

Need `pointerdown` on canvas and buttons might conflict: on-screen buttons are outside canvas, fine.

Need `canvas.setPointerCapture` may throw if pointerId invalid in synthetic browser click? Use optional try/catch. `if (canvas.setPointerCapture) { try{canvas.setPointerCapture(e.pointerId)}catch{} }`. Fine.

Need `pointerup` listener on window to clear pointerAiming; with capture, canvas gets pointerup. Add window listener too. Fine.

Need overlay is above canvas; clicks on overlay don't reach canvas. Good.

Need `overlay` hidden with `display:none`; `aria-hidden` toggled. Fine.

Need CSS for `.hidden` maybe generic. Good.

Need `finalScore` element.

Need `lives` pips classes. Good.

Need responsive canvas coordinate mapping: `canvas.getBoundingClientRect()` works.

Need `ctx.imageSmoothingEnabled=false` maybe set.

Need ensure `formation.x` toFixed in diag when formation defined. Fine.

Need `hud.dataset.bunkerCells` set to count. Fine.

Need `document.body.dataset.gameState` maybe.

Need maybe score HUD pulse on kill: add class 'bump' and remove via CSS animation? Could use `scoreEl.classList.remove('bump'); void scoreEl.offsetWidth; scoreEl.classList.add('bump');` on kill. CSS `@keyframes bump`. Nice visual score feedback. Also float text. Good. Need `void scoreEl.offsetWidth` to restart animation; okay. Add in `killAlien`. Need CSS `.stat strong.bump{animation:bump .28s ease-out}` and keyframes. Fine.

Need damage feedback for bunker: cells removed, particles, maybe b.flash draws outline. Good.

Need `b.flash` decrement in updateEffects. Draw bunker outline when flash>0:
```
if(b.flash>0){ ctx.strokeStyle=`rgba(200,255,180,${b.flash*2})`; ctx.strokeRect(...); }
```
Good.

Need `drawAliens` perhaps draw a subtle formation trail? not needed.

Need enemy shots from aliens potentially spawn at x center and y; need no collision with own formation. fine.

Need `fireEnemyShot` uses `rnd` and `enemyShots.length<ENEMY_MAX_SHOTS`. Need pick shooter. Use `aliensAlive` maybe. Good.
```
function fireEnemyShot(){
 if(enemyShots.length>=ENEMY_MAX_SHOTS) return false;
 const shooter=pickEnemyShooter(); if(!shooter)return false;
 const x=shooter.x+A_W/2, y=shooter.y+A_H+5;
 enemyShots.push({x,y,vy:210+rnd()*70+(1-aliensAlive/TOTAL_ALIENS)*50,w:5,h:12,ttl:ENEMY_SHOT_TTL,phase:rnd()*Math.PI*2});
 log('alien shot',{x:Math.round(x),active:enemyShots.length});
 return true;
}
```
Need `pickEnemyShooter` returns `{r,c,x,y}`. Good.

Need `enemyFireTimer` reset in updateFormation even if shot not fired due max shots? maybe set short timer anyway; fine.

Need `updateFormation` log on reverse could be noisy but okay. Maybe log only first few? fine.

Need if `edge` and `dx` clamped to0, then `formation.x += 0`, reverse, descend. Good. Need `maxBottom` computed before x move; descending by18. Check `maxBottom + (edge?18:0) >= ZONE_Y`. Good. If game over, `endGame` and return. Need not fire. Good.

Need `state` change while `update()` continues; update checks state after formation. In `updateProjectiles` loops, check state each iteration. Good.

Need `updateEffects` called even if state not playing. In `loop`, call `update(dt)` only if playing; else `updateEffects(dt)` and draw. But `update()` itself handles formation end and effects; if state changes mid-update, call effects at end anyway. Need structure:
```
function loop(now){
 const dt=...
 if(state==='playing') update(dt); else updateEffects(dt);
 draw(now/1000);
 requestAnimationFrame(loop);
}
```
Within update, if state becomes non-playing, still call updateEffects at end. But then next frame state non-playing calls updateEffects. Fine. Need avoid double effects in same frame if endGame called then update returns early? We'll design `update` with `try`? Simpler:
```
function update(dt){
 elapsed+=dt;
 ...
 if(state!=='playing'){ updateEffects(dt); return; }
 ...
 updateEffects(dt);
 hudTick...
}
```
Good.

Need `lastTime` reset on reset; loop uses `let lastTime=performance.now()`; reset sets it. Good.

Need `requestAnimationFrame(loop)` start after reset. fine.

Need maybe `document.addEventListener('visibilitychange')` to clear keys; optional.

Need `console.log` snapshot on reset; fine.

Let's write.

Need run static check. Use node --check on extracted script. Also verify sprite string lengths maybe via node script. Let's do bash with python extraction and node check.

No python3. Use node to extract and check via writing temp file. Need use bash with node -e. Let's do.

Now browser reload and inspect. Need use browser tool. Let's call reload then inspect maybe in parallel? Need reload first then inspect. Could call reload and screenshot in parallel? Better sequential.

Interesting reload output shows console truncated object (only first fields) and telemetry formation +10.4 in inspect but screenshot shows -5.6 maybe because different times / direction reversed? Wait screenshot shows formation -5.6 ← while inspect DOM says formation +10.4 →. Maybe reload happened, then screenshot taken later after enough time to reverse? Actually formation start x=0, moving right ~42 px/s. To reach right edge from maxX=758 to RIGHT-6=870 requires 112 px /42=2.67s; then reverse, descend, move left. Screenshot telemetry -5.6 ← indicates about 2.8s elapsed. Inspect DOM says +10.4 → maybe earlier at 0.25s. Tool output "Frame 1, +1ms" maybe screenshot from after some time? Hmm. It seems `reload` returns DOM and image captured at different times maybe. Fine. But object console truncated; inspect might show more later. Need perhaps change log to JSON string to see full snapshot. Could do `console.log('[invaders] '+label, JSON.stringify(data))` to avoid truncation. Might be useful. We can change log to output JSON string. Need check if browser tool truncates object representation; yes it shows `{state: playing, score: 0, lives: 3, playerX: 450, aliens: 55}` and cuts rest. JSON string would show all. Let's edit log to stringify. Also maybe add initial explicit snapshot string. Good.

Need screenshot initial looks good. Need note visual: formation appears at x maybe -5.6; aliens centered. Bunkers 4. Cannon center. Controls displayed. Great.

Need test keyboard movement and firing. Need browser key tool semantics. Let's try `action:"key", text:"ArrowRight"` and inspect. Need maybe use `inspect` after. Could call key and inspect in parallel? No, need sequential. Let's try key then inspect.

Key action works; cannon moved from450 to471 (nudge10 + continuous ~11). Good. Alien motion verified: formation reversals logged, y=36, dir changes. Bunker damage from enemy shots visible (bunker 2 top-left chipped, count306). Great. Need test firing via Space and score. Need aim center maybe cannon currently471; player shot from471 could hit alien column c5? Alien formation x currently maybe -88.4? Wait screenshot telemetry formation -88.4 → (DOM says -52.5 →, screenshot later). Need compute alien positions with offset -88: c5 center450-88=362, c6=420, c7=478. Cannon471 may hit c7 if offset ~-88, or c6 if offset -52. Need find a sure way to hit alien: click canvas at center x=600 (browser) which sets player x=450 and fires, but formation offset moving means center column may not align. Need maybe use `window.invaders.setPlayerX` not accessible. Could use canvas click at x corresponding to current alien center. We can read telemetry formation x and compute. But by the time we click, formation moves. Maybe easier: use `key` Space while holding cannon at some x and multiple shots; likely eventually hit an alien as formation passes. But need sure score feedback. Could also target bunker via canvas click, easier. For alien hit, we can use a deterministic approach: fire a spread of shots by holding Space (auto-fire) at center; formation moves horizontally, aliens will cross x=450. Since 11 columns spaced58, width36, gaps22; at any x, an alien occupies 36/58=62% of horizontal positions, so over time formation sweeps, shots at x=450 will eventually hit. If we hold Space for ~2s, likely score. But key action may be instantaneous; we can use fire button pointerdown? Browser `click` on FIRE button triggers pointerdown + pointerup quickly, one shot. Could click repeatedly. Or use `key` action with text "Space" maybe tool holds key for some duration? It seems `key` ArrowRight moved player 21px: nudge10 + continuous ~11px, meaning key was held ~34ms. Actually tool key action likely keydown then keyup after ~30ms. So Space keydown triggers one shot; no hold. Could use repeated key actions and time passes between calls. Need maybe 8-10 calls. Alternatively use `drag` from fire button to itself? pointerdown then pointerup maybe one shot. Could use `motion` action with key held? Not sure.

Maybe we can add a small debug helper accessible via keyboard: e.g., key "F" fires a volley of 3 shots? Not required. But we can use on-screen FIRE button repeatedly; 3 clicks. Need center shot align with alien eventually. Could use canvas click at varying x positions to target an alien column based on current formation. Need determine current formation x from telemetry and map to screen coordinates. Let's do a more controlled test:
- Press `R` to restart, giving formation x=0, y=0, dir=right, player x=450. Then immediately press Space or click center canvas to fire. Shot travel time from y=506 to bottom alien y~256? Actually bottom row y=88+4*42=256, height24 => bottom280. Distance226 /620=0.365s. Formation moves ~15px during flight. Center column c5 spans x=432..468 initially, moving right to447..483 at impact; shot x=450 overlaps. Great! So after restart, immediate center shot should hit bottom row alien c5 and score10. Need browser actions time may be ~1s between calls; formation x may have moved ~42px, so center column spans474..510; shot at450 misses, but c4 spans374..410 plus42=416..452 -> shot450 overlaps c4! Actually with formation x=42, c4 initial x=374..410 moves to416..452, so shot450 hits c4. Nice. With formation x=0..~36, c5 spans432..468 and shot450 hits. With formation x=36..58, c4 moved410..446? Let's compute c4 x=142+4*58=374, span374..410; +36=410..446, shot450 misses; c5 span432..468+36=468..504, shot450 misses. There's a gap when formation x~22? Need calculate coverage: at fixed x=450, alien columns spans [142+58c+fx, 178+58c+fx]. Need some c with lower<450<upper. Intervals for fx: c5 [432+fx,468+fx] contains450 if fx∈(-18,18). c4 [374+fx,410+fx] contains450 if fx∈(40,76). c6 [490+fx,526+fx] contains450 if fx∈(-76,-40). So gaps fx∈(18,40) and (-40,-18). At speed42, gaps last0.5s each. If actions take ~1s, could land in gap. We can press space multiple times at different times; eventually hit. Also player shot width4. Good.

Alternative target via canvas click at x matching current formation: use telemetry to compute best x. Need mapping of canvas x to browser x: stage left ~150, canvas width~900? Screenshot shows stage left=150, right=1050, width900. So browser x =150 + canvasX. Click at canvas x=450 -> browser x=600. Need y within canvas e.g., 400. Good. If formation x known, choose canvas x = center of an alien column around450 plus fx. Could click at x=450+fx maybe, but player x will be set to that; shot x same. Need target column c5 center =450+fx. If fx between -112 and112, x ranges338..562. All within playfield, but may pass through bunkers if x between390..510? Wait bunkers at 120-210,300-390,510-600,690-780. If x=450+fx:
- fx=0 ->450 central gap, good.
- fx=40 ->490 central gap, good (510 bunker starts at510).
- fx=80 ->530 hits bunker3, bad.
- fx=-40 ->410 central gap, good.
- fx=-80 ->370 hits bunker2 (300-390), bad.
So central gap allows x 390..510; thus fx between -60 and60. Formation x oscillates -112..112; if fx outside ±60, targeting center column may be blocked by bunker. Could target a different column that falls in central gap: choose c4 center=392+fx, c5=450+fx, c6=508+fx. Need one in [392,508] maybe; with fx±112, choose c6 for negative, c4 for positive. But can just restart and act quickly.

Maybe simpler: add a keyboard shortcut "Space" held? The browser key action might support text with repeated characters? `type` action may type text into focused element, generating keydown per char. Could use `action:"type", text:"          "` on body? Not sure. But we can use multiple `key` calls in parallel? Tool wrapper allows multiple developer tools in parallel if independent; but browser actions on same page not independent, could conflict. Could call `multi_tool_use.parallel` with several `browser` key actions, but they might run concurrently and all keydowns before keyups, causing keys set to hold; could fire multiple shots over a short time? Not reliable. Could use sequential calls.

Let's first edit log to JSON string for full snapshots. Also maybe want to reduce console log key downs? They are fine. Need maybe add a log on player shot with JSON. We'll change log function to:
```
function log(label, data){ console.log('[invaders] '+label+' '+JSON.stringify(data)); }
```
This will show complete data. Need reload after edit. Let's do edit now, then reload. Also maybe initial console object truncated but telemetry enough. Changing log makes verification easier. Need ensure no issues with circular objects (none). Good.

Also potential issue: `drawCannon` uses `rnd()` every frame for flame flicker; this consumes the deterministic random stream and makes enemy fire randomness depend on frame rate. Not a problem functionally, but for deterministic reset, maybe not ideal. Could use `Math.sin` only no rnd. Not necessary, but we can remove rnd from draw to keep RNG purely gameplay. Let's do that too: `const flame = 9 + Math.sin(t*27)*3 + Math.sin(t*41)*1.5;` Good. This avoids frame-rate-dependent random. Nice.

Need perhaps `window.invaders` debug API not used; okay.

Need maybe pointer click on canvas calls tryFire with current `fireCooldown`; if we click rapidly, some clicks won't fire due cooldown. For tests, need wait >0.27s between clicks. Fine.

Let's edit log and flame.

Need reload to apply. Then restart via R key maybe to reset after current state. Reload itself resets. Need test firing quickly after reload. Could perhaps use browser tool action to combine key press and inspect? Each call gives console/dom, so reload output includes initial state but not after key. We can reload then immediately key "Space". Need maybe time between tool calls ~? We can call reload then key; formation may have moved based on elapsed wall time. We can also press R and then Space in quick succession; tool calls sequential with some latency maybe ~0.1s? Actually browser tool outputs "Frame 1, +0ms" and captures console; real time between calls could be ~0.5-1s. We'll try. Use `key` "r" to restart then `key` "Space" then inspect. But each call output includes DOM telemetry, so can check score after. Let's do sequence:
- reload
- key "r" maybe not needed because reload resets; skip.
- key "Space" and inspect output. Need ensure formation x at that moment. Key output includes console logs and DOM telemetry. Let's call `key` with text "Space".

Again screenshot taken later than DOM, showing formation -4.8 left; maybe tool runs page for ~3s while capturing screenshot. Interesting: reload DOM at +9.7 right, screenshot at -4.8 left after reversal at ~2.7s. So time passes significantly (maybe 3s) between DOM capture and screenshot. Need account. For firing test, we need aim based on formation at time of key call; but the screenshot capture may take 3s, so if we press Space at call time, shot resolves during that 3s and we can see result in console/dom output perhaps after. Let's call key Space now; note current state after reload screenshot maybe ~3s elapsed, formation x ~0 (left). Actually screenshot telemetry -4.8 ←, so formation x≈-4.8, dir left. If we press Space now (next tool call ~? maybe another 3s), formation may have moved to -112 and reversed etc. Hard.

Better approach: use canvas pointer click to move and fire at a target computed from formation at the moment of click? We don't get pre-state; but we can use telemetry in prior output. Since tool call may start after several seconds, formation state changes unpredictably. Could use multiple shots at different x and rely on enough attempts. Or use `window.invaders` debug functions through a `key` action? Could maybe use `type` into canvas? Hmm.

Alternative: Add a special test-only control that freezes formation or sets it to zero on key press? We can use R to restart and maybe also fire a shot automatically after reset? Could add `R` restart then immediate `tryFire()`? But requirement says restart restores player position etc; firing on restart would be odd. Could add a debug key (e.g., "P") that pauses formation? Not in requirements but could be a "practice mode"? Hmm. Better avoid.

Maybe we can use browser `motion` action to hold key for duration? Need understand tool. Let's try `browser` action "motion" maybe captures motion frames over a period and can include key? It has no text parameter? Actually motion action may capture frames; maybe with text? Need use tool with action "motion" perhaps and maybe specify x,y? Let's see. Could produce frames over ~1s. But no key holding. Maybe action "drag" with toX,toY can hold pointer over fire button for ~some duration. For example `drag` from fire button to same point with small move might hold pointerdown for some time, adding 'Space' to keys and triggering continuous auto-fire while held. Browser `drag` likely dispatches pointerdown, moves, pointerup over a duration; maybe enough to fire multiple shots. Could use `drag` on canvas from center to center slightly; pointerdown fires once and pointermove sets x; pointerup; no continuous fire because canvas pointerdown only calls tryFire once, doesn't add 'Space'. Need fire button pointerdown adds 'Space', update auto-fires while held. A drag from fire button to fire button (or slight move) might hold 'Space' for maybe ~0.5s, producing 2 shots. Could then score. But need know drag duration. Let's explore.

Maybe easiest: create a hidden debug endpoint via URL query parameters that pre-aims and auto-fires? But browser tool reload always same URL maybe can pass text? action reload has no URL. Could use `browser` action "type" into address bar? no.

Could add a visible "AUTO FIRE" toggle button that holds fire continuously; user can click it to start auto-fire. Not required but could be a legitimate "autofire" control? Might be seen as extra. We can add a "HOLD FIRE" button with `pointerdown` adding 'Space' and pointerup removing; existing FIRE button already does that. Browser `click` may not hold long, but maybe `drag` can. Let's test drag on FIRE button. Need coordinates from screenshot: FIRE button around x=953,y=706, width76, height32. Use drag from (953,706) to (955,707) perhaps. Need maybe tool drag uses start and end coordinates and takes some time. Let's try after reload and see console logs for multiple player shots. But we also need score; if auto-fire at center while formation sweeps, likely hit. Let's try.

First, maybe test Space key: call key "Space" now.

Space fired a shot visible in screenshot (cyan beam at y~520). Need inspect after shot travels: next tool call will show result. Need call inspect now.

The player shot at x=450 didn't hit an alien (score0, shots P0). It probably passed through gap because formation at impact had fx~? We saw at key time formation -19.2 left; shot flight ~0.36s moves formation left ~15px to -34; gap between columns c5 and c6 at x450 when fx in (-40,-18) indeed. So missed. Need try again at better moment / x.

Need robust way to test alien hit. We can use canvas click to aim at an alien column center computed from current formation. Need get current formation x from telemetry before clicking; but tool latency means formation changes. However we can use `inspect` output and click target based on predicted x at click time maybe not exact. Better perhaps freeze formation state via restart + immediate click at center in same tool call? Could use `browser` action "drag" from Restart button to canvas center? That would click restart (on pointerup maybe) then move to canvas? no.

Maybe we can add a debug hook via keyboard: pressing "P" toggles pause? Not required. But we can use `window.invaders` only if browser tool can evaluate JS. Maybe browser action "inspect" supports some special text? It doesn't. But perhaps `browser` action "type" with text into a contenteditable element could trigger our own console? no.

Could incorporate a tiny in-page "TEST" control panel hidden behind a key sequence? Hmm. But simpler: use multiple shots from different x positions by clicking canvas at various x. Need ensure at least one hits an alien. Since formation moves and bunkers may block, choose x positions in central gap [392,508] or outer gaps that align with alien columns. We can click at several x over multiple calls; each click fires one shot (if cooldown expired). With 5-6 shots at x=400,430,460,490,520? Need avoid bunker blocking at x>510 or x<390. Let's choose x=400,420,440,460,480,500 within central gap. At any formation fx, there will be some alien column overlapping one of these x? Need check. Alien column spans (with fx):
c? centers at 160+58c+fx. For fx within [-112,112], columns cover x roughly 48+fx..? Let's list bottom row spans for c0..10: [142+fx,178+fx], [200+fx,236+fx], ..., [722+fx,758+fx]. For central gap x∈[390,510], which columns can overlap? c4 [374+fx,410+fx], c5 [432+fx,468+fx], c6 [490+fx,526+fx], c7 [548+fx,584+fx]. For a given fx, at least one of c4,c5,c6 overlaps [390,510] maybe. But our shot x chosen from discrete set. Need ensure one of those x is inside an alien span at impact. If we fire a volley at x=400,430,460,490, maybe at any fx one of these lies inside a span? Let's analyze.

For fx∈[-112,112], spans:
c4: [374+fx,410+fx] ranges [262,522]
c5: [432+fx,468+fx] ranges [320,580]
c6: [490+fx,526+fx] ranges [378,638]
c7: [548+fx,584+fx] ranges [436,696]
At fixed shot x values 400,430,460,490, we need find if union of spans covers at least one of those points for all fx. Let's compute condition for a shot x to be inside c4 span: fx∈(x-410, x-374). c5: fx∈(x-468,x-432). c6: fx∈(x-526,x-490). c7: fx∈(x-584,x-548). Union for x=400,430,460,490. Could brute force mentally or use node quickly. But note shot flight adds ~0.36s formation movement ~15px; need account. Could use broad x set with 10px spacing from390 to510 (13 shots) to guarantee. But each click needs cooldown0.27s; tool calls naturally >0.27s. Could use auto-fire via drag on FIRE button at a fixed x while formation sweeps; likely hit within 2-3 sec. Need maybe easier.

Another approach: use `drag` on canvas from x=400 to x=500 with pointer held. Our canvas pointermove sets player x continuously while dragging, but pointerdown fires only once. If we add auto-fire while pointer aiming (keys.add('Space') on canvas pointerdown) then dragging would produce multiple shots at different x, increasing hit chance. That's a legitimate control improvement: holding/tapping canvas could auto-fire like Space. Could modify canvas pointerdown to add 'Space' to keys and pointerup remove; then a drag across central gap would fire multiple shots following pointer (subject to cooldown). This is natural. Need ensure pointerdown still calls tryFire; adding 'Space' allows auto-fire while held. Then `drag` action from x=400 to x=500 might last enough to fire several shots. If drag duration ~0.5s, maybe 2-3 shots. Could still miss. Could drag back and forth (one action with toX/toY only linear). Hmm.

Maybe better: add a "rapid fire" burst on click? But fire rate bound required; cannot exceed cooldown. Could set fireCooldown lower? 0.27 reasonable. Multiple calls over several seconds fine.

Let's use brute force to find a set of x values and times that almost guarantees a hit given formation motion. But we can just fire many shots sequentially via `key` Space at center over time; formation sweeps across center, so eventually one shot will hit. Each tool call takes ~3s? Actually between key and inspect there were many logs with ~6 formation reversals, meaning ~20s of game time passed! Wait console from reload to key Space included 4 reversals (y=72), which at ~2.7s per edge = ~10.8s. Then inspect added another reversal y=72 -> maybe ~2s. So tool calls are separated by many seconds of game time? The browser tool may run page continuously at high speed? Actually "Frame 1, +0ms" but console logs accumulated from page running between tool calls in real time, maybe 10s because our reasoning took time. Indeed I spent time thinking between calls. So formation could be anywhere. Firing repeatedly at center over many calls should eventually hit, but game may end from aliens descending after ~60s. We need restart periodically.

Maybe use browser `motion` to capture frames while holding key? Let's explore tool capabilities. Could call `motion` and see output; perhaps it captures frames over ~1s and maybe allows interactions. Need not waste too much time. Let's call `motion` now.

Motion frames show alien formation moving left and descending; lives2 after enemy hit (good). Bunkers heavily damaged by enemy shots; visible material removal. Need still verify player shot hitting alien and score. Need maybe use a more deterministic approach using a test helper exposed on window but browser tool cannot call JS directly. Could use a DOM button that triggers a "demo shot" aimed at an alien? Maybe we can add a hidden but accessible key "T" that fires a guaranteed hit for debugging? That would be artificial and could confuse but not harmful if undocumented. But maybe acceptable under "unspecified implementation details are your choice". Still, better to test genuine gameplay.

We can exploit the canvas click to aim at exact alien position shown in screenshot. Need map screenshot coordinates to canvas coordinates. Stage left=150, top=80 (from screenshot: canvas top y=80, bottom y=640; width900, height560? Wait internal H=600 but screenshot stage from y=80 to640 =560? Let's inspect: screenshot shows stage top at y=80, bottom at y=638 maybe 558. Hmm CSS aspect-ratio 3/2 with width900 gives height600. But screenshot stage top maybe80, bottom640 =>560? Let's look more carefully: screenshot dimensions 1200x800, canvas top ~80, bottom~638, ground line at y~635. That's 558. Maybe browser screenshot scaled to 1200x800 from a larger page? Actually screenshot attached appears 1200x800; stage x from150 to1050 =900; y from80 to638=558. If aspect ratio 3/2, height should600. Maybe top is80 and bottom680? In image, controls at y~705, telemetry y~735. Stage bottom might be680? Let's examine attached: top of stage around80; bottom of stage around638? Hmm ground line near y636; controls around706; that's 70px gap. If stage bottom680, controls at706 would be 26px gap. Hard to tell. Let's use DOM/canvas bounding rect via console? We can add a one-time log of canvas rect on pointerdown; then click and see. But we can infer from CSS: shell width900, stage top roughly after topbar. Body padding16, topbar height maybe46? brand mark34, margin-bottom10 => total ~60. So stage top=16+? topbar maybe46? Let's compute from screenshot: header text at y~38, HUD boxes from y~20 to65, stage top around80. So top=80. Stage height=600 => bottom680. Controls row from y~692 to724, telemetry y~738. That matches image: controls around705, telemetry735. Ground line at y? PLAYER_ZONE_Y=500 maps to top80+500=580 (breach line label seen around568? Could be). Ground=566 maps646, so ground line around646. Cannon PLAYER_Y=532 maps612, seen cannon around605. Yes stage bottom680. So canvas display height600. Good. Browser x =150+canvasX; browser y=80+canvasY. We can click at y=400 (within canvas). Good.

Need target an alien column. From motion frame4 telemetry formation -74.2 left, screenshot shows bottom row aliens at x positions maybe ~215,273,... Need map: formation x=-74.2: c0 x=142-74=68 (canvas), center86; c1 center144; c2 center202; c3 center260; c4 center318; c5 center376; c6 center434; c7 center492; c8 center550; c9 center608; c10 center666. In screenshot frame4 bottom row aliens at approximate browser x 215,275,330,390,450,510,... Wait stage left150, so canvas x for first visible alien maybe65 -> browser215. Yes matches. Good. So at formation -74, c6 center434 (browser584) is in central gap390..510? Actually canvas434 -> browser584; yes central gap. To hit alien, click at browser x=150+434=584, y=400. But formation continues moving left while shot travels; from -74 left at ~? speed maybe42? Actually at y162, speed ~42+(0)+25=67 px/s; moving left. During 0.36s flight, formation x decreases ~24 to -98, so c6 center becomes410 (canvas), not434. Need aim at pre-adjusted x: target center at impact = c6 center initial 508? Wait c6 center = A_X + 6*58 +18 + fx =142+348+18+fx=508+fx. At fx=-74, center434. If moving left at ~67px/s, after0.36s fx=-98, center410. So need shoot at x=410. That's still central gap. More generally need know formation direction and speed, and aim ~20px ahead.

Could instead click at a bunker gap where an alien column will pass during shot flight. Need maybe use multiple clicks at x positions 400, 420, 440, 460, 480, 500 over successive calls. With formation moving, likely one hits. But game is at y162, nearing breach (zone500, bottom row y=88+168+24+162=442; needs 58 more =4 descents ~20s). Need act quickly or restart. Let's restart first to reset to clean state. Then use a sequence of clicks at chosen x positions shortly after restart, maybe with a helper that fires a spread of 3 shots simultaneously? We could add a "shot spread" on canvas click? Not required and fire rate bound. But maybe we can leverage `tryFire()` from window via a custom URI? No.

Could use `browser` action "drag" on FIRE button to hold auto-fire for ~2s. That's probably best. Need drag coordinates from screenshot: FIRE button around x=953,y=705 (center). Use `drag` with x=953,y=705,toX=955,y=705. Tool may hold pointer for ~? Let's try after restart. Need first restart via key "r" maybe. Then drag fire button. Need calculate if fire button pointerdown adds 'Space'; while drag held, update will call tryFire every 0.27s. If drag duration ~0.5-1s, 2-4 shots. Formation moves; center x=450; at restart, fx=0 and moving right. Over first 1s, fx goes0→42; center shot hits c5 for fx∈(-18,18) (first0.4s) then gap fx18-40 (0.3s), then c4 for fx40-76 (after1s). Shots launched at t=0,0.27,0.54,0.81,1.08; impact at +0.36s: fx at impact ~15,26,38,49,60. c5 hit for15 (first), gap26/38 (2nd/3rd), c4 hit49/60 (4th/5th). So at least first and 4th/5th score. Great! So holding fire for ~1s after restart should get score. Need drag duration likely ~0.5-2s. Let's try. Need restart via key "r" first, then drag. But tool call latency between restart and drag may be several seconds, so formation not at fx0. Could include restart via clicking restart button then drag in same tool? Not possible. Could perhaps use key "r" then immediately call drag; real time between calls may be ~1s (if we minimize thinking). The tool call itself outputs frame at +0ms, but page keeps running while we reason. We can make calls back-to-back in one assistant turn using multi_tool_use.parallel? But parallel tool calls would execute simultaneously, not sequential. However we can call `browser` action "key" and then `browser` action "drag" in same assistant message? Tools in same message via multi_tool_use.parallel execute concurrently; not sequential. Could call `browser` action "drag" with start on restart button and end on fire button: drag from restart button (pointerdown) to fire button (pointerup). The click event for restart may fire on pointerup? HTML button click event fires on pointerup at target where pointerdown started? In browsers, click fires on common ancestor if pointerdown/up differ, likely not on restart button, so restart might not trigger. Could instead start drag on fire button, move to restart button, back? only one toX/toY. Not reliable.

Could use key "r" and then key "Space" in consecutive tool calls quickly; formation at restart may be fx~0-? We can reduce thinking by sending two tool calls sequentially but as separate assistant messages with minimal delay. Our reasoning time dominates; but tool calls execute when we send them. We can send `key r`, then immediately `key Space` in next message (with no analysis). The page game time between calls may be small (~0.1s). Let's try that. But key "r" resets and key "Space" fires one shot; if timing ~0.1s, fx~4, shot impact fx~19; borderline gap. Need maybe key "r" then key "Space" repeated multiple times at 0.3s intervals? Tool call latency could be ~0.1-0.5s. We can send 5 `key` calls in sequence quickly. But each call output includes console; we can inspect final. Need no analysis between them. Could use multi_tool_use.parallel with sequential? no. But I can send multiple assistant messages? As ChatGPT, one turn can include multiple tool calls sequentially but the system executes each tool call and returns results, then I can issue next. That's okay; I'll just do it with minimal commentary.

Alternatively add a `setTimeout` in page to auto-fire after reset? Could implement a "demo burst" triggered by key R? E.g., R restarts and schedules 5 shots at 0.3s intervals. That would be artificial and might affect user experience (restart would auto-fire). Not good.

Maybe use `window.invaders.fire()` via `browser` action "key" with text? no.

What about using `browser` action "type" with text "r      " into body? It may dispatch keydown for each character including spaces. If we type a string with spaces, each space keydown could fire. But `type` likely targets focused input; no input. It may dispatch keyboard events to page. Could test. But key action already works. Repeated key calls fine.

Need maybe use `browser` action "drag" on FIRE button without restart; even if formation not at fx0, a 2s hold at center will have formation sweep through ~130px, giving several chances. Since formation oscillates, center x=450 gets alien coverage ~62% of time; 5-7 shots over2s likely at least one hit. Let's try drag on FIRE button now (without restart) but game near breach y162; still ~20s left. Need maybe drag duration from motion tool ~2s? `drag` likely has some steps over ~0.5s. Let's test. Use coordinates from screenshot: FIRE button center around (953,705). Need exact maybe from screenshot: button spans x~914..991, y~690..722. Center (953,706). Let's call drag from (953,706) to (954,706).

Drag didn't hit fire button? No player shot logs from drag, and game over due breach. Maybe coordinates wrong or drag didn't trigger pointerdown because gameover overlay already shown? Actually overlay appears in screenshot from drag call; perhaps game ended before drag due time. The drag start at y706 might be on FIRE button, but no player shot logs. Could be because state was already gameover at drag time (overlay visible), so pointerdown on fire button would still call tryFire but state not playing -> no log. So too late. Need restart and act quickly. Need avoid long reasoning between calls. Let's do a sequence of quick tool calls with minimal analysis: key "r" to restart, then key "Space" multiple times maybe 4 calls, then inspect. But game time between calls could still be seconds if tool process. However if we send them in one assistant turn with multiple tool calls sequentially, the tool results come back one by one; we can issue next without lengthy reasoning. Let's try to send `key r` then `key Space` etc. But I need to wait for each result; I can keep analysis minimal. Could also use `multi_tool_use.parallel` with several key actions? They may execute concurrently and all key events at nearly same time; fire cooldown would block all but one. Not useful.

Maybe use `browser` action `drag` on fire button immediately after restart key with minimal delay. Need know drag actually holds pointer and auto-fires. Let's test on a fresh restart. Need maybe drag duration. We'll do:
1. key "r" -> restart.
2. immediately drag on fire button (953,706)->(953,706) maybe tool drag with zero delta could be ignored; use 2px delta.
Need call after result. Let's do quickly.

Restart works: DOM telemetry formation +0.0, lives3, bunker324, score0, player450. Screenshot later formation -0.0 left? Actually screenshot telemetry -0.0 ← maybe after reversal? Wait DOM +0.0 → initial; screenshot -0.0 ← maybe a lot later after reverse and descent? But screenshot shows formation at initial y (top row around160 screenshot y, which corresponds canvas80? Actually top row y=88+80=168; yes initial y). Telemetry -0.0 ← could be after two reversals returning x=0 but y? screenshot top row at168, so y=0. Hmm maybe formation dir left at x=-0.0 from floating point after clamp? Could be screenshot from a different reload? Wait screenshot shows aliens centered same as initial. If dir left and y=0, impossible after reversal (y would18). Maybe DOM and screenshot from different times due page continuing; but screenshot telemetry -0.0 ← maybe formation x nearly0, dir left after edge and descent y? Yet top row would be +18 lower (screenshot y186), but appears y168. Hard to tell. Maybe screenshot attached from earlier reload frame? The tool says "Earlier screenshot omitted: only latest 4 images stay in context" but one attached. It could be a cached earlier image? Hmm.

Anyway, need quickly drag fire button now. Do it with no analysis.

Great! Score10, aliens54, visible missing alien in bottom row and +10 floater, explosion particles. That verifies player shot hitting alien and score once. Also screenshot shows bunker damage (bunkers chipped) from enemy/player shots. Need verify player shot hitting bunker specifically maybe. We saw enemy shots damage bunkers and player shot in screenshot at x~600? Actually player shot at x=600 browser? There is cyan shot at x~600 browser (canvas450) passing through central gap, not hitting bunker. Need specifically test player shot hitting bunker. We can use canvas click at x=540 (browser690) to aim and fire. Need ensure shot hits bunker3. Could use click action at browser x=690, y=500 maybe. Need note stage left150, canvas x540 -> browser690. y=500 is within canvas (top80..680). Clicking at y=500 maps to canvas y420? Actually y browser500 -> canvas y420, which is bunker top; pointerdown still sets player x and fires from cannon; y irrelevant. Good. Need ensure fireCooldown expired (last shot maybe from drag at t? Could be >0.27s by now). Need maybe click once and inspect logs for `by:"player"` bunker damage. Let's do. Need avoid long reasoning. Call click at x=690,y=500.

Great! Click at x690 moved cannon to540 and fired; screenshot shows bunker3 with obvious hole / outline flash; telemetry bunker274 from300 (screenshot) or270 DOM. Need check console logs for player bunker damage. The console output from click call includes only logs up to previous gameover? Wait it's the same long log from prior session, not including new `player shot` or `bunker damaged by player`? Actually after restart via key "r", console should have a new `ready / restart` log but output shows old logs only from initial session and no new restart log? Hmm strange: the key "r" output console didn't show a new `ready / restart` log at end, though DOM showed reset state. Wait resetGame logs, but console list output appears to be truncated to first ~100 logs, maybe tool only shows first 100, so later logs are omitted. That explains missing new logs. Need use `inspect` maybe still shows first 100 logs, not latest. Could use `console.clear()` in resetGame to keep logs manageable. That would help verification. We should add `console.clear()` in resetGame? But clearing console on restart may be okay; initial console log after clear shows ready. Could improve. But browser tool console output currently huge because old logs persist across reset. Need fix to make console manageable for final verification. Add `console.clear()` at start of resetGame, then log ready/restart. This is fine. Need also perhaps reduce logging of every enemy shot? Could keep but maybe limit. We can reduce `alien shot` logs? Not needed for verification but console could still get large over long play. Could remove logs for `alien shot` and `key down` maybe. But they help debugging. We can keep with console.clear on reset. Also maybe cap logs? no.

Need verify player bunker damage explicitly in logs. Could use screenshot visual (obvious hole in bunker3, bunker cell count drop from300 to274). That's sufficient. But task says "inspect a shot hitting a bunker or alien for visible damage or score feedback." We have both: alien hit score +10 and missing alien; bunker hole visible. Good.

Need verify restart restores initial formation, bunkers, lives, score, player position. We saw telemetry after key "r": cannon450, formation+0.0, aliens55, bunker324, lives3, score0. Need maybe click Restart button rather than R key. Requirement says "Provide Restart" — we have topbar and overlay button. We should test button click. Need maybe after current state (score10, player540, bunker274, lives3) click topbar restart at browser x~996,y~42 (from screenshot button spans944..1048, y20..64; center996,42). Then inspect DOM initial values. Need check overlay hidden. Let's do after adding console.clear maybe reload first. Need finish code edits, reload, then final checks. Also maybe need ensure game over state was observed (it was: overlay "GAME OVER", reason breach line, lives1). Win state not verified. Need maybe test win state via debug helper? Could add a hidden debug function? We have `window.invaders` snapshot etc but no way to call. Could add a keyboard shortcut to force win? Not appropriate. Could note unverified.

Need maybe test three lives and invulnerability: we observed life lost logs (lives2, lives1) and game over on breach. Brief protection not directly verified; we can note. Could maybe verify by looking at logs: after life lost, invuln1.6, and no immediate second life loss despite enemy shot at x471? In console, after first life lost at y126, next life lost at y162 ~? many seconds later; likely protection worked. But not explicitly. Fine.

Need check player movement with A/D too? We tested ArrowRight. Could test D quickly maybe. Requirement says Left/Right or A/D; "or" means either set okay. We support both. We could test `d` key to confirm. Maybe do quick final pass. Also check left boundary clamp via holding left? Could use on-screen left button clicks to move to edge? Need at least keep cannon within playfield; code clamps. We can test moving right repeatedly maybe. Not necessary but quick. Need maybe test keyboard A/D. We'll do after reload.

Need maybe check fire rate bound: we can inspect logs from drag: multiple player shots? Console output after drag showed score10 and P1 maybe. Need get logs after console.clear to see. Could use `motion` with fire button drag? Not necessary; code enforces. Could note unverified by direct test maybe. But requirement asks bound projectile lifetime and fire rate; we can mention implemented and maybe checked via telemetry shot count with held fire. Might need actually verify. We can use `drag` on fire button for ~? Need after console.clear to see logs. Could hold FIRE button via `drag` from center to center over 2px; if tool drag duration maybe ~0? It produced at least one shot and score. Need maybe check multiple shots with cooldown. Could use `browser` action "key" with text "Space" repeatedly and see logs with timestamps? no. Could add a log on shot with `fireCooldown` maybe. But code obvious.

Maybe we should reduce enemy shot rate? Current game seems very fast: enemy shots destroyed bunkers heavily and game over after ~60s, fine. But initial opening formation had grid moving and firing; good.

Potential issue: `console.clear()` in resetGame will clear browser console every restart; fine. Need add. Also maybe reduce `log('key down')` for every key; keep. Need maybe remove `window.invaders` debug API? It's harmless. Could keep.

Potential issue: `drawCannon` uses `rnd()` in `spawnParticles` called from `tryFire`, and enemy fire randomness; deterministic enough. fine.

Potential issue: `updateEffects` called twice? In `update`, if `endGame` triggered, updateEffects at end; loop next frame calls updateEffects because state not playing. fine.

Potential issue: `endGame` sets `keys.clear()` but pointerAiming remains true; canvas pointermove won't move because state not playing; pointerup clears. fine.

Potential issue: On restart, overlay hidden but focus may remain on overlay button; keyboard events on window still work. fine.

Potential issue: `canvas` pointerdown while overlay hidden but topbar restart button click may also trigger canvas? no.

Potential issue: `click` on canvas at browser y500 maps to canvas y420 (bunker top); pointerdown sets player x based on e.clientX only. fine.

Potential issue: `drag` on fire button at y706 actually worked? It seems score10 after drag, but maybe score came from earlier Space shot that finally hit? Wait screenshot after drag showed missing alien and +10. Could be from the earlier Space shot fired at x=450 before gameover? No, game was restarted via key "r", which cleared playerShots; then drag on fire button fired? The console output didn't show new logs due 100 log cap, but DOM score10 indicates a player shot hit an alien after restart. Drag likely held Space and fired at least one shot. Good. Need maybe drag duration enough for one shot. Fine.

Need maybe add console.clear and reload, then final verification with manageable logs. Let's edit. Also maybe add log of restart with snapshot; done. Need perhaps `console.clear()` at start of resetGame but initial page load console clear is fine. Need maybe log key down for R then clear then ready; tool output would show key down before reset then ready. Good.

Let's edit.

Need reload and final checks. But before that, maybe consider game over overlay reason: "The invaders crossed the breach line." lives were1 when gameover by breach, so requirement says aliens reaching player zone or zero lives causes Game Over; both implemented. We observed breach gameover. Zero lives not observed but code fine. Need maybe test zero lives gameover via debug? Could add a test helper triggered by a key sequence? Not needed. Could note unverified.

Need maybe verify win state: not observed. Could perhaps add a debug function to `window.invaders` like `clearAliens()` that marks all aliens dead and ends game, but browser tool cannot call JS. Could add a hidden keyboard shortcut "W" to force win? That would be artificial and maybe considered cheating. Not needed; note unverified.

Need maybe verify shots can pass through resulting bunker gaps. We have code; but not directly observed. Could perhaps inspect screenshot: bunker3 has a hole; after subsequent shot from same x, maybe passes through gap. We can test with clicking at same x=690 again and see if player shot travels beyond bunker (cyan shot above bunker) and maybe hits alien. Need more direct. Could test by clicking at x=690 twice with enough delay; after first shot damages bunker, second shot may pass through resulting gap. Need capture screenshot after second shot with cyan shot above bunker. But timing tricky. Could use `motion` frames after a click at same x. Might be doable. But requirement asks shots can subsequently pass through resulting gaps; we should at least trust code. Could maybe add console log when player shot passes through bunker gap? Hard to detect; but we can instrument: in `hitBunker`, if y crosses bunker top boundary with no solid cell, log "shot passed through gap"? That would be noisy. Could add a counter `gapPasses` and telemetry when a player shot crosses from below to above a bunker without collision. Need maybe implement to verify. Is it worth? The requirement explicitly says "shots can subsequently pass through the resulting gaps." We should ensure logic is correct and maybe test. Let's reason carefully about collision detection: `hitBunker` checks cells at sample y for x offsets. If a shot passes through a gap where all cells along x offsets are empty at each sampled y, it will not hit and continue upward. `damageBunker` removes cells around impact with radius sqrt(2.65)=1.63 cells, including the center cell and adjacent cells. But because shot has 3 offsets (-2,0,2), it may still hit side cells if the gap is not wide enough. After 1-2 shots, a 3-cell-wide gap should allow pass. Need ensure sample y covers entire bunker height: shot steps2px, bunker42px -> ~21 samples, so if any solid cell remains at any row within the 3 x offsets, it hits. Since damage removes cells in a circular radius around impact at first solid cell from bottom, it may not remove cells higher up (top rows) at same x. For player shot from below, first solid cell likely at bottom row r6 (or r5 due notch). Damage radius1.63 cells removes cells in rows5-6 and maybe4 but not rows0-3. So shot will still hit top rows on subsequent shots until enough shots carve through all7 rows. That's classic destructible bunkers: shots gradually tunnel through. Requirement says "Hits from either side remove bunker material persistently; shots can subsequently pass through the resulting gaps." This could mean after enough hits, gaps form; not necessarily one hit. Our implementation allows tunneling after several hits. But maybe need ensure enemy shots from above and player shots from below can carve through and eventually pass. With radius1.63 and impact at first solid cell, each shot removes ~6 cells around that row; after ~4 shots from same side, a vertical tunnel can form. Good.

Could add a diagnostic counter for "bunker pass-through" to help verify. But not necessary if we can visually see a shot above bunker after several shots. Might be nice to test. Need manage time. We have maybe ~? 15 min budget, but tool calls and reasoning long. Let's check time? No explicit clock. Need prioritize.

Need maybe refine gameplay: enemy shots damage bunkers very quickly (bunker cells from324 to200 in ~40s), leaving little cover. That's okay. Player shots also damage. Need maybe make enemy shots less frequent? Game over by breach after ~60s, fine.

Need maybe test with Restart button. Let's reload to apply console.clear, then do a compact final pass:
1. reload -> inspect initial DOM/console/screenshot.
2. key "d" -> inspect movement (x>450).
3. key "Space" -> inspect shot fired. Maybe screenshot shows shot.
4. click restart button -> inspect initial values (score0, lives3, aliens55, bunker324, cannon450, formation0).
5. maybe click canvas at x690 to hit bunker and inspect visible damage. But we already did prior to edit; reload won't change logic except console.clear. Need maybe re-verify affected behavior? We changed only console.clear and log format earlier; no gameplay changes. Could still do a brief recheck.
6. maybe check alien hit score again with drag fire button after restart. Need maybe use quick sequence. But we already have screenshot evidence from prior version; code same except console.clear. Could mention checked. Since addendum says "Fix clear problems you discover and recheck affected behavior." We found no clear problems except console log truncation; console.clear fixes. Need recheck initial output/console. We'll do.

Need maybe ensure no console errors after reload. Browser inspect console shows only logs, no errors. Good.

Let's reload.

Console clean now. Need final checks quickly. Let's test D key and Space maybe in one call? `key` action with text "d" then `key` "Space". Need minimal analysis. Call key d.

D key moved player450→465, good. Alien motion already verified via formation reversal logs and screenshots. Need test Space firing after reload with clean console; call key Space.

Space fired visible cyan shot; good. Need maybe check shot hitting bunker from player and score with clean logs. We already saw prior version, but final file same logic. Need maybe do one more quick sequence: click restart button, then click canvas at x690 to hit bunker, inspect console for `by:"player"` damage; then maybe drag fire button to get score. But time maybe okay. Need prioritize Restart verification via button. Let's click restart button at x996,y42.

Great. Restart button works: console shows clear + ready snapshot with initial values; DOM telemetry formation +4.2, cannon450, score0, lives3, aliens55, bunker324. Screenshot shows initial formation, intact bunkers, cannon center, 3 life pips. Need maybe verify player shot hitting bunker with clean console: click at x690,y500, then inspect. Let's do.

Excellent. Console shows player shot x540, bunker damaged by player, removed5, cells300. Screenshot shows bunker3 with hole and flash outline. Need maybe verify shot can pass through resulting gap after a few more clicks at same x. Could do multiple clicks with same x maybe 3-4 times and see console logs: if eventually `alien destroyed` or player shot travels above bunker. Need maybe capture screenshot with cyan shot above bunker. Let's attempt: click at x690,y500 again, eventually repeated damage. Need fireCooldown maybe expired by now (time between calls likely >0.27s). Let's do 3 more clicks, minimal analysis. Could call `click` three times sequentially. Need maybe tool call output each time; lengthy. Perhaps use `drag` on canvas from (690,500) to (690,500) with pointer held, but canvas pointerdown doesn't add Space, so only one shot. Could add auto-fire on canvas pointerdown for hold; maybe worth implementing to make click-and-hold fire. Currently canvas pointerdown calls `tryFire()` but doesn't add Space; we can add `keys.add('Space')` and remove on pointerup. That would make drag action on canvas hold fire for multiple shots and also move x. This is a nice improvement and helps test tunneling. Need edit to add keys.add/remove. But changing code requires reload, losing current state. Could still do; but maybe not necessary. We can just click multiple times. Let's do 3 clicks quickly. Need maybe each call has time >0.27s. We'll call click x690 y500 three times with minimal analysis.

Second player shot hit bunker at y449 (higher than first y461), showing persistent tunneling from below. Great. Need maybe one more click to see shot pass through gap above bunker. The screenshot shows cyan shot just below bunker at y? Actually cyan shot at browser x? There is a cyan beam inside bunker hole around y~550; could be player shot passing through? It seems at bunker center. Need not.

Need maybe test restart again after bunker damage to verify bunkers restore (we already did from button restart before damage; but after damage, restart should restore bunkers too). Our earlier restart from game state with score10/bunker damaged? The button restart call was after Space shot and score10, bunker maybe276. It did restore to324. Good. Need maybe explicitly note that.

Need maybe check score once: We saw `alien destroyed` once with score10 and remaining54. Need ensure score increments once per hit (killAlien called once; projectile removed). Could maybe fire at same x and score again? Not needed. We can note code.

Need maybe check win state: not verified. We can maybe simulate win by using debug API via `window.invaders` but browser tool no eval. Could add a keyboard shortcut to clear aliens? Not needed. But maybe we can add a "demo" mode hidden behind a query string and reload with hash? Browser reload action maybe supports text parameter? The tool schema for reload has no text but maybe `text` can pass URL? Could try `browser` action "reload" with text "#win"? Probably ignored. Not worth.

Need maybe check enemy shot life loss and invulnerability: we observed life lost logs and game over by breach; no zero lives gameover. Need maybe note unverified. But requirement says "Start with three lives. Enemy shots cost a life with brief protection from repeated damage. Aliens reaching player zone or zero lives causes Game Over; clearing aliens shows a win state." We should ensure zero lives code works. Let's inspect logic: `hitPlayer` decrements lives, invuln=1.6, if lives<=0 endGame(false,...). Good. But note `updateProjectiles` loop has `if (state !== 'playing') break;` at start of each iteration, so after endGame, remaining shots don't process. Fine. Need overlay shows. Good.

Win state: `killAlien` if aliensAlive===0 endGame(true,...). `updateFormation` also checks aliensAlive<=0. Good.

Potential issue: `endGame` sets `keys.clear()` but `keys` is const Set; fine.

Potential issue: `resetGame` calls `console.clear()` which may be considered a network request? no.

Potential issue: `window.invaders` exposes `setPlayerX` that could be used to move player outside clamp? It clamps. fine.

Potential issue: `pointerdown` on canvas adds no Space; holding doesn't auto-fire, but click/tap field to aim+fire works. Fine.

Potential issue: `fireBtn` pointerdown adds Space and tryFire; pointerup removes. If user holds, update auto-fires. Good. Bound fire rate. Need maybe check `key` Space held auto-fire: keydown adds Space, update calls tryFire every cooldown. Good.

Potential issue: projectile lifetime: player TTL2s, enemy TTL5s; also removed out of bounds. Good.

Potential issue: cannon within playfield: setPlayerX clamps to [48,852]. left/right buttons and pointer click clamp. Good. Need maybe test clamping? Could click at browser x=100 (canvas x=-50) and see player x=48. Not necessary but could quickly verify. Maybe do one quick click at x=100,y500 and inspect telemetry. Need then restart to final clean state. Might be useful. Let's do a quick boundary check and final restart. Need maybe not too many calls. We'll call click at x=100,y500; then inspect telemetry; then restart via R to leave clean. But tool calls have output; okay.

Actually, more important: final file should be saved. It is. Need maybe run node --check again after edits. Do that. Then maybe final browser reload and screenshot to ensure no errors after final edits. We already reloaded after console.clear; no errors. Could do final static check. Need maybe final report concise, mention what checked and unverified.

Let's do boundary test quickly maybe.

We need finalize quickly. Need note boundary click at x100 didn't move cannon? DOM telemetry cannon540, not clamped to48. Why? Browser x100 is outside canvas (canvas left150), so pointerdown on canvas didn't fire; no player shot log. That's fine; not a bug. Need maybe no essential issues.

Need final static syntax check after edits. Also maybe need ensure index.html present. Need maybe final reload? We already reloaded after final edit. Need maybe no further changes. Need maybe final restart to leave clean initial state? Not necessary; artifact state dynamic when loaded fresh. But final browser state currently playing with damaged bunkers; file itself resets on load. Fine.

Need maybe run node --check again. Then final report concise. Need mention what checked and unverified. Need maybe save file already saved. Could call bash to check file existence and syntax. Do that quickly.

Need final answer concise with what actually checked and unverified. Mention index.html saved, self-contained. Need note tested:
- initial load screenshot/DOM/console clean, 55 aliens, 4 intact bunkers, 3 lives, score0, cannon450.
- ArrowRight and D movement, Space firing and visible shot; cannon clamp code (not direct boundary test maybe mention implemented, not fully tested). Actually we clicked outside canvas; not a test. Could say keyboard movement checked for ArrowRight and D; clamping implemented but boundary extremes not directly exercised.
- Alien motion: formation reversal/descent logs and motion frames, screenshots show shifted grid.
- Alien hit: console log `alien destroyed`, score10, aliens54, missing alien and +10 popup.
- Bunker damage: enemy shots chipped bunkers; player shot at x540 logged `bunker damaged by player`, persistent hole, second hit at higher y showing tunneling. Need mention gaps pass-through maybe observed partially (second shot reaching higher into tunnel); full pass-through not directly captured.
- Restart: topbar button and R key restored score0, lives3, aliens55, bunker324, cannon450, formation0, overlay hidden.
- Game over by breach line observed overlay; life loss logs observed (lives2,1), brief invulnerability set but not exhaustively timed. Win state and zero-lives game over not directly triggered. Fire rate/TTL enforced in code but not stress-tested. Need mention unverified.
- No console errors, no external refs, JS syntax check.

Need maybe mention on-screen controls and click-to-aim as extra. Good.

Need not overlong. Let's final.