Space Invaders · laguna-s-2.1

Let me analyze this task. I need to build a Space Invaders-style game in a single self-contained `index.html` file with inline CSS and JS, no external resources. Let me plan the implementation.

Key requirements:
1. Canvas-based, procedural graphics (no images)
2. Controls: Left/Right arrows or A/D to move cannon, Space to fire upward
3. Aliens in a grid that move horizontally, reverse+descend at edges, fire toward player
4. Bunkers (destructible barriers) between cannon and aliens - pixel damage
5. Three lives, enemy shots cost a life with brief invincibility protection
6. Game Over (aliens reach player zone or zero lives), Win (clear all aliens)
7. Restart functionality
8. Score, projectile lifetime, fire rate limiting

Let me write the full implementation. I'll make it clean and complete.

Let me think about the structure:
- HTML: canvas element + controls instructions
- CSS: styling, centered layout
- JS: game loop, entities, physics, input handling

Let me write this carefully.

For the bunkers, I'll use a bitmap approach - a 2D array of pixels representing bunker material. When a shot hits, I'll damage (remove) the hit pixel. This makes it persistent and allows shots to pass through gaps.

Let me think about the rendering approach for bunkers. I'll create bunker objects with a pixel grid. Each bunker has a width and height in pixels, and I'll draw filled rectangles for intact pixels.

For alien bullets, typically in Space Invaders, the aliens have a separate "shooter" - the bottom-most alien in a column, or a random alien, fires. I'll pick a random alien (or bottom-most in a column) to fire occasionally.

Let me code this up.

Let me structure the code:

```javascript
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');

let gameState = {
  // game objects
};

// Input handling
let keys = {};
window.addEventListener('keydown', ...);
window.addEventListener('keyup', ...);

// Game entities
class Cannon {...}
class Alien {...}
class Bullet {...}
class Bunker {...}

// Game loop
function update() {...}
function draw() {...}
function gameLoop() {...}
```

Let me write it all out now. I'll be thorough.

For bunker pixel damage: when a bullet hits the bunker area, I need to find the specific pixel(s) that were hit and remove them. I'll iterate through the bunker's pixel grid, check if the bullet's position overlaps an intact pixel, and if so, mark it as destroyed and destroy the bullet.

Let me think about the bunker bitmap. I'll make a simple bunker shape - like the classic 4-block high barrier. Actually, I'll use a predefined pixel pattern.

Let me use a simple bunker shape like:
```
....####....
...######...
..########..
.##########.
############
############
############
```

Hmm, let me make a cleaner one. I'll define bunkers with a grid pattern.

Actually, let me think about pixel resolution. If I use small pixels (e.g., 4x4 pixel cells), the bunker will look good. Let me use a grid of, say, 11 wide × 6 tall, with each cell being 4×4 pixels. So bunker is 44×24 pixels.

Let me define the bunker shape as a 2D array.

Now let me think about the overall approach carefully and write it all.

Let me consider the alien grid: typical Space Invers has rows of different colored aliens. I'll make a grid, say 10 columns × 5 rows.

Alien movement: they move horizontally as a group. At edges, reverse direction and move down. The whole group shares a velocity.

When an alien is hit, remove it. The group continues.

For firing: I'll pick the bottom-most alien in each column and randomly choose one of them to fire periodically.

Let me code this.

I need to be careful about:
- Projectile lifetime (bullets should disappear after some time or distance)
- Fire rate limiting (player can't fire continuously)
- Brief protection after being hit (invincibility frames)

Let me write the complete game now.

```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Space Invaders</title>
<style>
  * { margin: 0; padding: 0; box-sizing: border-box; }
  body { background: #000; color: #fff; font-family: 'Courier New', monospace; display: flex; justify-content: center; align-items: flex-start; min-height: 100vh; padding-top: 20px; }
  #gameContainer { text-align: center; }
  h1 { font-size: 28px; margin-bottom: 5px; letter-spacing: 2px; }
  #hud { margin: 10px 0; font-size: 18px; }
  canvas { background: #000; display: block; margin: 0 auto; image-rendering: pixelated; }
  #controls { font-size: 14px; color: #aaa; margin-top: 10px; }
  button { margin-top: 10px; padding: 8px 20px; font-size: 16px; font-family: inherit; background: #222; color: #0f0; border: 1px solid #0f0; cursor: pointer; }
  button:hover { background: #0f0; color: #000; }
  #message { position: absolute; color: #ff0; font-size: 40px; text-align: center; width: 100%; top: 40%; }
</style>
</head>
<body>
<div id="gameContainer">
  <h1>SPACE INVADERS</h1>
  <div id="hud">SCORE: <span id="score">0</span> &nbsp; LIVES: <span id="lives">3</span></div>
  <canvas id="gameCanvas" width="600" height="700"></canvas>
  <div id="controls">← → or A/D to move &nbsp;|&nbsp; SPACE to fire</div>
  <button id="restartBtn" style="display:none;">RESTART</button>
  <div id="message"></div>
</div>
<script>
...
</script>
</body>
</html>
```

Wait, the message div positioned absolute needs the container to be position: relative. Let me handle that. Actually, let me put the message inside the container and make container position relative.

Let me now write the JavaScript game.

```javascript
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');
const scoreEl = document.getElementById('score');
const livesEl = document.getElementById('lives');
const messageEl = document.getElementById('message');
const restartBtn = document.getElementById('restartBtn');

const W = canvas.width;  // 600
const H = canvas.height; // 700

const keys = {};
window.addEventListener('keydown', (e) => {
  keys[e.code] = true;
  if (e.code === 'Space') e.preventDefault();
});
window.addEventListener('keyup', (e) => {
  keys[e.code = false;
});
window.addEventListener('blur', () => {
  for (let k in keys) keys[k] = false;
});

let state = 'playing'; // playing, gameover, win

// Cannon
let cannon = { x: W/2 - 25, y: H - 50, w: 50, h: 20, speed: 5, fireRate: 0 };

// Bullets
let bullets = []; // player bullets
let enemyBullets = [];

// Aliens
let aliens = [];
const alienCols = 11;
const alienRows = 5;
let alienDir = 1;
let alienVelocity = 0.5; // base, increases
let alienDropSpeed = 10;

// Bunkers
let bunkers = [];

// Lives
let lives = 3;
let score = 0;
let invincible = 0; // frames

function initAliens() {
  aliens = [];
  for (let r = 0; r < alienRows; r++) {
    for (let c = 0; c < alienCols; c++) {
      aliens.push({ x: 70 + c * 45, y: 60 + r * 45, w: 35, h: 30, row: r });
    }
  }
  alienDir = 1;
  alienVelocity = 0.4;
}

// Bunker pattern - bitmap
const bunkerPattern = [
  "00111111100",
  "01111111110",
  "11111111111",
  "11111111111",
  "11100110011",
  "11000110001",
];
```

Hmm wait, that bottom row with gaps - the bunker would fall apart. Let me look at classic Space Invaders bunkers - they have a triangular top and a rectangular base, with the bottom having some gaps? Actually the classic bunker looks like:

```
.XXXXXX.
XXXXXXXX
XX....XX
XX....XX
XXXXXXXX
XXXXXXXX
```

Something like that. Let me just make a solid-ish shape with the top being pointed.

Let me define:
```
const bunkerPattern = [
  "000111111100",
  "001111111110",
  "011111111111",
  "011111111111",
  "011111111111",
  "011000011000",
  "001100001100",
];
```

Hmm, let me keep it simpler and more like the actual game. I'll make each bunker cell 5x5 pixels.

```
const bunkerPattern = [
  "001111100",
  "011111110",
  "111111111",
  "111111111",
  "111000111",
  "110000011",
];
```

7 rows × 9 cols, each cell 5x5 = 45x35 pixel bunker.

Let me make the bunker a class/object with a pixel grid that gets modified.

```javascript
function initBunkers() {
  bunkers = [];
  const bunkerW = bunkerPattern[0].length * 5;
  const bunkerH = bunkerPattern.length * 5;
  const startX = (W - 4 * bunkerW) / 2 + 10; // wait, 4 bunkers
  // actually let me position bunkers
  const bunkerY = H - 180;
  const bunkerCount = 4;
  const spacing = (W - bunkerCount * bunkerW) / (bunkerCount + 1);
  for (let i = 0; i < bunkerCount; i++) {
    const bx = spacing * (i + 1) + i * bunkerW;
    bunkers.push(createBunker(bx, bunkerY));
  }
}

function createBunker(x, y) {
  const grid = [];
  const cellSize = 5;
  for (let r = 0; r < bunkerPattern.length; r++) {
    grid[r] = [];
    for (let c = 0; c < bunkerPattern[r].length; c++) {
      grid[r][c] = bunkerPattern[r][c] === '1';
    }
  }
  return { x, y, grid, cellSize, w: bunkerPattern[0].length * cellSize, h: bunkerPattern.length * cellSize };
}
```

Now for bunker collision: when a bullet enters bunker area, check which cells it overlaps and destroy them.

```javascript
function bunkerHit(bullet, bunker) {
  // bullet is a circle/rect
  const cell = bunker.cellSize;
  // check overlap
  const gx = Math.floor((bullet.x - bunker.x) / cell);
  const gy = Math.floor((bullet.y - bunker.y) / cell);
  if (gx >= 0 && gx < bunker.grid[0].length && gy >= 0 && gy < bunker.grid.length) {
    if (bunker.grid[gy][gx]) {
      // destroy a small area
      for (let dy = -1; dy <= 1; dy++) {
        for (let dx = -1; dx <= 1; dx++) {
          const cx = gx + dx, cy = gy + dy;
          if (cx >= 0 && cx < bunker.grid[0].length && cy >= 0 && cy < bunker.grid.length) {
            bunker.grid[cy][cx] = false;
          }
        }
      }
      return true;
    }
  }
  return false;
}
```

Actually for better damage visual, I'll just destroy the single cell that was hit (or a 3x3 area). Let me use a 3x3 cross-shaped damage.

Now let me think about the game loop and timing.

```javascript
let lastTime = 0;
function gameLoop(timestamp) {
  if (!lastTime) lastTime = timestamp;
  const dt = timestamp - lastTime;
  lastTime = timestamp;
  
  update(dt);
  draw();
  
  requestAnimationFrame(gameLoop);
}
requestAnimationFrame(gameLoop);
```

But for consistent movement, I'll use frame-based logic but scale by dt. Actually, Space Invaders is typically frame-based. Let me use a fixed timestep approach with requestAnimationFrame and accumulate.

Actually, let me keep it simpler - use requestAnimationFrame and work with a target of ~60fps. I'll compute dt for movement.

Let me think about what needs dt scaling:
- Cannon movement: speed * dt / 16.67 (so speed is per-frame at 60fps)
- Bullet speed: same
- Alien velocity

Or I could just use frame counts. Let me use dt for smoothness.

Actually, to keep the classic feel, let me use a fixed update with interpolation. But that's complex. Let me just use dt-based movement which is simpler and works fine.

Let me define everything in terms of pixels per second:

```javascript
const CANNON_SPEED = 200; // px/s
const BULLET_SPEED = 400; // px/s
const ALIEN_BASE_SPEED = 20; // px/s, increases
```

And dt in seconds = dt / 1000.

Hmm, but the alien movement in Space Invaders is the group moving together. Let me handle that.

Let me now write the full update function.

```javascript
function update(dt) {
  if (state !== 'playing') return;
  
  const secs = dt / 1000;
  const frames = dt / 16.67; // approx frame count
  
  // Cannon movement
  if (keys['ArrowLeft'] || keys['KeyA']) cannon.x -= CANNON_SPEED * secs;
  if (keys['ArrowRight'] || keys['KeyD']) cannon.x += CANNON_SPEED * secs;
  // clamp
  cannon.x = Math.max(0, Math.min(W - cannon.w, cannon.x));
  
  // Firing
  cannon.fireRate -= frames;
  if (keys['Space'] && cannon.fireRate <= 0) {
    bullets.push({ x: cannon.x + cannon.w/2 - 2, y: cannon.y, w: 4, h: 10, speed: BULLET_SPEED });
    cannon.fireRate = 15; // frames cooldown
  }
  
  // Update player bullets
  for (let i = bullets.length - 1; i >= 0; i--) {
    const b = bullets[i];
    b.y -= b.speed * secs;
    b.life = (b.life || 0) + frames;
    if (b.y < -20 || b.life > 90) { // lifetime ~1.5s
      bullets.splice(i, 1);
      continue;
    }
    // Check alien hit
    for (let j = aliens.length - 1; j >= 0; j--) {
      const a = aliens[j];
      if (rectOverlap(b, a)) {
        aliens.splice(j, 1);
        bullets.splice(i, 1);
        score += 10 * (a.row + 1);
        updateScore();
        break;
      }
    }
  }
  
  // ... enemy bullets, bunkers, etc
}
```

Let me handle the alien group movement with edge detection:

```javascript
function moveAliens(frames) {
  // find group bounds
  let minX = Infinity, maxX = -Infinity;
  for (const a of aliens) {
    minX = Math.min(minX, a.x);
    maxX = Math.max(maxX, a.x + a.w);
  }
  
  let dir = alienDir;
  if (dir > 0 && maxX + alienVelocity * frames > W - 20) {
    dir = -1;
    alienDir = -1;
    // drop down
    for (const a of aliens) a.y += alienDropSpeed;
  } else if (dir < 0 && minX + alienVelocity * frames * dir < 20) {
    dir = 1;
    alienDir = 1;
    for (const a of aliens) a.y += alienDropSpeed;
  }
  
  for (const a of aliens) {
    a.x += alienVelocity * frames * dir;
  }
  
  // check if aliens reached bottom
  for (const a of aliens) {
    if (a.y + a.h > cannon.y) { // reached player zone
      state = 'gameover';
      messageEl.textContent = 'GAME OVER';
      restartBtn.style.display = 'inline-block';
      return;
    }
  }
}
```

Hmm, I need to be careful - the alien velocity should increase as aliens are eliminated, which is the classic mechanic. Let me compute velocity based on remaining aliens.

```javascript
alienVelocity = ALIEN_BASE_SPEED + (alienCols * alienRows - aliens.length) * 0.15;
```

For alien firing: I'll pick a random alien from the bottom of columns and have them fire with some probability.

```javascript
function alienFire() {
  // find bottom-most alien in each column
  const bottomInCol = {};
  for (const a of aliens) {
    const col = Math.round((a.x - 70) / 45); // hmm, need consistent column calc
    if (!bottomInCol[col] || a.y > bottomInCol[col].y) {
      bottomInCol[col] = a;
    }
  }
  const candidates = Object.values(bottomInCol);
  if (candidates.length > 0 && Math.random() < 0.003) {
    const shooter = candidates[Math.floor(Math.random() * candidates.length)];
    enemyBullets.push({ x: shooter.x + shooter.w/2 - 2, y: shooter.y + shooter.h, w: 4, h: 10, speed: 200 });
  }
}
```

Actually, let me reconsider. Let me not compute column by position but track it. Hmm, but when aliens move as a group vertically (on drop), columns stay roughly the same x. Let me just track column index in each alien object. Actually the aliens move in x as a group but each alien's x is its own. Let me assign a column index to each alien initially and keep the bottom-most per column.

Let me store col property in alien creation:
```javascript
aliens.push({ x, y, w, h, row: r, col: c });
```

Then bottom in col is the one with the highest y (lowest on screen) for each col.

```javascript
function alienFire() {
  const bottomCandidates = {};
  for (const a of aliens) {
    if (!bottomCandidates[a.col] || a.y > bottomCandidates[a.col].y) {
      bottomCandidates[a.col] = a;
    }
  }
  const candidates = Object.values(bottomCandidates);
  if (candidates.length > 0 && Math.random() < 0.004) {
    const shooter = candidates[Math.floor(Math.random() * candidates.length)];
    enemyBullets.push({ x: shooter.x + shooter.w/2 - 3, y: shooter.y + shooter.h, w: 6, h: 12, speed: 180, life: 0 });
  }
}
```

Now enemy bullets:
```javascript
for (let i = enemyBullets.length - 1; i >= 0; i--) {
  const b = enemyBullets[i];
  b.y += b.speed * secs;
  b.life += frames;
  if (b.y > H + 20 || b.life > 120) {
    enemyBullets.splice(i, 1);
    continue;
  }
  // Hit cannon
  if (rectOverlap(b, cannon) && invincible <= 0) {
    enemyBullets.splice(i, 1);
    lives--;
    updateLives();
    invincible = 90; // frames of protection
    // flash effect
    if (lives <= 0) {
      state = 'gameover';
      messageEl.textContent = 'GAME OVER';
      restartBtn.style.display = 'inline-block';
    }
    continue;
  }
  // Hit bunker
  for (const bunker of bunkers) {
    if (bunkerHit(b, bunker)) {
      enemyBullets.splice(i, 1);
      break;
    }
  }
}
```

Wait, the invincible check: the requirement says "brief protection from repeated damage." So when hit, set invincible timer. While invincible > 0, don't take damage. But should the bullet be destroyed? I think yes - the bullet passes through during invincibility or gets destroyed. Let me destroy the bullet when it hits during invincibility to avoid continuous damage. Actually, "protection from repeated damage" means after taking a hit, you can't be hit again for a brief period. The bullet that hits you is consumed. So:

```javascript
if (rectOverlap(b, cannon)) {
  enemyBullets.splice(i, 1);
  if (invincible <= 0) {
    lives--;
    updateLives();
    invincible = 90;
    // check game over
  }
}
```

This way, any enemy bullet touching the cannon is destroyed, but only costs a life if not invincible. That seems right.

While invincible, the cannon should flash. Let me handle that in draw.

Now, player bullets hitting bunkers:
```javascript
for (let i = bullets.length - 1; i >= 0; i--) {
  for (const bunker of bunkers) {
    if (bunkerHit(bullets[i], bunker)) {
      bullets.splice(i, 1);
      break;
    }
  }
}
```

Let me also make the alien bullets able to destroy player bullets (collision). Optional but nice.

Now let me also think about: player bullets should be able to pass through gaps in bunkers. Since we destroy cells, and the bullet passes through empty cells, that naturally works.

Let me also handle: when bullet hits the top edge of a bunker cell, it destroys that cell. The bunkerHit function I wrote checks which cell the bullet is overlapping. Good.

Let me also make sure bullets that pass entirely through gaps (no cell overlap) continue. Since bunkerHit only returns true when hitting an intact cell, bullets pass through gaps.

Now let me write the draw function:

```javascript
function draw() {
  // Clear
  ctx.fillStyle = '#000';
  ctx.fillRect(0, 0, W, H);
  
  // Draw starfield background
  drawStars();
  
  // Draw aliens
  for (const a of aliens) {
    drawAlien(a);
  }
  
  // Draw bunkers
  for (const bunker of bunkers) {
    drawBunker(bunker);
  }
  
  // Draw player bullets
  ctx.fillStyle = '#0f0';
  for (const b of bullets) {
    ctx.fillRect(b.x, b.y, b.w, b.h);
  }
  
  // Draw enemy bullets
  ctx.fillStyle = '#f00';
  for (const b of enemyBullets) {
    ctx.fillRect(b.x, b.y, b.w, b.h);
  }
  
  // Draw cannon (flash if invincible)
  if (invincible <= 0 || Math.floor(invincible / 4) % 2 === 0) {
    drawCannon();
  }
  
  // Draw score/lives
  // already in HUD
}
```

Let me make procedural alien drawings. Each alien is a rectangle with some pattern. Different rows could have different patterns/colors.

Row 0 (top): lightest (cyan), Row 4 (bottom): darkest (red).

Let me draw aliens as detailed sprites using rectangles.

Actually "procedural graphics" - I should draw shapes with canvas, not use images. Let me make nice-looking aliens with canvas drawing.

For each alien, I'll draw based on row:
- Row 0: a "squid-like" or shield shape
- Row 1: two eyes
- etc.

Let me make a drawAlien function that draws a different pattern per row.

Let me think of simple alien designs using rectangles:

Alien type 1 (row 0) - "squid":
```
  #
 ###
# # #
 #####
# ###  
```
Hmm, that's complex. Let me keep it simpler - draw aliens as colored rectangles with a pattern.

Actually, let me draw each alien as a combination of primitive shapes:

```javascript
function drawAlien(a) {
  const colors = ['#4ffff4', '#4ff4ff', '#f4f44f', '#f48f4f', '#f44f4f'];
  ctx.fillStyle = colors[a.row] || '#f44f4f';
  
  // body
  ctx.fillRect(a.x, a.y, a.w, a.h);
  
  // draw details
  ctx.strokeStyle = '#fff';
  // ...
}
```

Let me make each alien type have a distinct sprite:

Type 0 (top row): "squid/eyeball" - draw two antennae and a body
Type 1: "crab" - two claws
Type 2: "octopus" 
etc.

I'll draw them with rectangles and lines. Let me write a reasonably detailed alien.

For row-based design:
```javascript
function drawAlien(a, row) {
  const colors = ['#00e5ff', '#ffff00', '#ff9100', '#ff3d00', '#ff1744'];
  ctx.fillStyle = colors[row];
  
  const cx = a.x + a.w / 2;
  
  switch(row) {
    case 0: // squid - two eyes, tentacles
      // body oval-ish
      ctx.fillRect(a.x, a.y, a.w, a.h);
      // eyes
      ctx.fillStyle = '#fff';
      ctx.fillRect(cx - 10, a.y + 8, 6, 6);
      ctx.fillRect(cx + 4, a.y + 8, 6, 6);
      ctx.fillStyle = '#00e5ff';
      // mouth
      ctx.fillRect(cx - 8, a.y + 20, 16, 3);
      break;
    ...
  }
}
```

This is getting complex. Let me simplify and just make each alien a colored rectangle with a pattern of smaller blocks, differentiated by row color. That satisfies "procedural graphics" on a canvas.

Actually, let me make them look decent. I'll draw aliens with a few rectangles forming a sprite. Let me predefine each type as an array of cells.

```javascript
// Alien sprite definitions: each is a grid of 0/1
const alienSprites = {
  0: [ // squid
    "011110",
    "111111",
    "101101",
    "111111",
    "010010",
  ],
  1: [ // crab
    "110011",
    "111111",
    "011110",
    "010010",
    "110011",
  ],
  2: [ // octopus
    "011110",
    "111111",
    "110011",
    "011110",
    "010010",
  ],
  3: [...],
  4: [...],
};
```

Hmm, this is getting big. Let me use a different approach: draw the alien as a colored block with eyes drawn using fillStyle. That's procedural and simple.

Actually, let me just go with colored rectangular sprites with simple details. Let me make each type draw a distinct shape using fillRect and moveTo/lineTo.

Let me simplify - I'll define each alien type as a list of "pixel" cells (grid-based sprite), then render each cell as a small rectangle. This is the most Space Invaders-faithful approach (the original used pixel sprites).

```javascript
const alienTypes = [
  // Type 0 - top row (Cyan)
  [
    "001111100",
    "011111110",
    "110111011",
    "111111111",
    "001010100",
  ],
  // Type 1
  [
    "11100111",
    "11111111",
    "01011010",
    "01111110",
    ...
  ],
];
```

Then:
```javascript
function drawAlien(a) {
  const type = a.row;
  const sprite = alienSprites[type];
  const color = alienColors[type];
  ctx.fillStyle = color;
  const cellSize = a.w / sprite[0].length;
  for (let r = 0; r < sprite.length; r++) {
    for (let c = 0; c < sprite[r].length; c++) {
      if (sprite[r][c] === '1') {
        ctx.fillRect(a.x + c * cellSize, a.y + r * cellSize, cellSize, cellSize);
      }
    }
  }
}
```

This is clean and procedural. Let me define sprites for 5 types. But honestly, with limited time, let me use a few distinct ones and reuse patterns. I'll make 5 alien types.

Let me define:

Type 0 (cyan): squid
```
"001111100"
"011111110"
"110111011"
"111111111"
"010101010"
```

Type 1 (yellow): 
```
"11100111"
"01111110"
"00111100"
"01111110"
"11000011"
```

Type 2 (orange):
```
"01111110"
"11111111"
"11011011"
"01111110"
"01000010"
```

Type 3 (red):
```
"11111111"
"11111111"
"11000011"
"10111101"
"11111111"
```

Type 4 (pink/red):
```
"11000011"
"01111110"
"10111101"
"11111111"
"01011010"
```

OK, this is reasonable. Let me proceed.

For the sprites, each is 9 cells wide (type 0) which might make cellSize = 35/9 = ~3.89, not integer. Let me make the alien width a multiple of the sprite width. Let me set alien w = 36, h = 28, and sprites are 9×5 cells, so cellSize = 4. That works: 9*4 = 36, 5*4 = 20. Hmm, 5*4 = 20 but I want h = 28. Let me set cell size to 4 and sprite 9×7, giving w=36, h=28. Let me redesign sprites to 9×7.

Actually, let me reconsider. Let me make cellSize = 4. Alien sprite is 9 wide × 7 tall → 36 × 28 px. 

Let me redesign the sprites at 9×7:

Type 0 (Cyan - Squid):
```
"001111100"  (r0)
"011111110"  (r1)
"111111111"  (r2)
"110010011"  (r3)
"100000001"  (r4)
"011111110"  (r5)
"001000100"  (r6)
```

Hmm, that's 7 rows. Let me just keep the 5-row ones and scale. Actually, let me just allow non-integer cellSize and use fillRect which handles it fine (sub-pixel). Or I'll round. Let me make sprites 8 wide × 6 tall so cellSize = 4 (32×24) — but then I need to fit in the alien grid spacing of 45. 32 < 45, fits fine. Let me also consider h: 6 × 4 = 24.

Actually, you know what, let me not overthink the sprites. Let me use simpler aliens. The point is a playable game. Let me use:

```javascript
const alienSprites = {
  0: ["011110","111111","111111","011110"],  // round
  1: ["110011","110011","111111","011110"],
  2: ["001100","111111","111111","110011"],
  3: ["101010","111111","011110","000000"],
  4: ["011110","101101","111111","001100"],
};
```

6×4 sprites, cellSize = 5 → 30×20. 

Let me just go with a 6-wide 5-tall sprite and cellSize = 5, giving 30×25. Fits in 45×40 grid.

Honestly the exact sprite doesn't matter too much. Let me write 5 reasonable sprites at 6 wide.

Let me just finalize the code. I think I'm overcomplicating. Let me write the whole thing now, testing as I go.

Let me reconsider the overall structure and write clean code. I'll write the file, then test in browser.

Let me think about timing constants:
- Cannon speed: 220 px/s
- Player bullet speed: 450 px/s
- Player bullet lifetime: 1.2s
- Player fire cooldown: ~12 frames (0.2s at 60fps) or use a timer
- Enemy bullet speed: 180 px/s
- Alien base speed: 30 px/s
- Alien speed increase: +2 per alien killed
- Alien drop speed: 12 px
- Alien fire probability: ~0.004 per frame

Let me reconsider fire rate limiting using a timer rather than frames, to be dt-independent:
```javascript
cannon.cooldown -= secs;
if (keys.Space && cannon.cooldown <= 0) { fire; cannon.cooldown = 0.25; }
```

Same for bullets using lifetime timers.

Let me use seconds-based timing throughout. Good.

For the alien movement, I'll use dt-based:
```javascript
alienVelocity = base + (total - remaining) * accel;
each alien: a.x += alienVelocity * secs * dir;
```

Let me now also handle the "move then check edge". The classic behavior: aliens move, and when the leading alien would go past edge, reverse and drop. I'll compute the group's velocity and apply.

One issue: if I check after moving, the aliens might clip past the edge. Let me check before moving: compute the new maxX = maxX + velocity*secs*dir; if it exceeds right bound, reverse dir, drop, and move. 

Let me handle it cleanly:
```javascript
function updateAliens(secs) {
  if (aliens.length === 0) {
    // win
    if (state === 'playing') {
      state = 'win';
      messageEl.textContent = 'LEVEL CLEARED!';
      restartBtn.style.display = 'inline-block';
    }
    return;
  }
  
  const speed = ALIEN_BASE_SPEED + (totalAliens - aliens.length) * ALIEN_ACCEL;
  let moveDir = alienDir;
  
  let minX = Infinity, maxX = -Infinity;
  for (const a of aliens) {
    minX = Math.min(minX, a.x);
    maxX = Math.max(maxX, a.x + a.w);
  }
  
  const nextMax = maxX + speed * secs * moveDir;
  const nextMin = minX + speed * secs * moveDir;
  
  if (moveDir > 0 && nextMax > W - 15) {
    alienDir = -1; moveDir = -1;
    for (const a of aliens) a.y += alienDrop;
  } else if (moveDir < 0 && nextMin < 15) {
    alienDir = 1; moveDir = 1;
    for (const a of aliens) a.y += alienDrop;
  }
  
  for (const a of aliens) {
    a.x += speed * secs * moveDir;
  }
  
  // alien firing
  ...
}
```

Hmm, the edge detection: in the classic game, the direction reverses when ANY alien reaches the edge. With group movement, checking maxX/minX against bounds is correct.

Now, for win/loss during alien movement:
```javascript
for (const a of aliens) {
  if (a.y + a.h > cannon.y) { gameOver }
}
```

Let me write it all out now. Let me also track totalAliens for speed calc.

Let me also add a descending condition: if aliens get too low. The classic: if any alien's bottom passes a threshold (player zone), game over.

Let me set player zone threshold = cannon.y (top of cannon). Actually if alien bottom >= cannon.y, that's game over (alien landed). Let me use that.

OK let me just write the code carefully now. Let me write the whole index.html.

I need to be careful about a few things in the edit. Let me write the complete file.

Let me also think about the invincibility flash - I'll make the cannon invisible or render it in an alternate color. I'll do: if invincible and frame even, don't draw cannon (or draw it dim).

Let me use a visual: when invincible, draw cannon with reduced alpha / different color.

Let me also count the invincibility in seconds:
```javascript
invincible -= secs;
if (invincible > 0 && Math.sin(invincible * 20) > 0) ... // flash
```

Let me write the complete game now. I'll be thorough but efficient.

Let me also reconsider: the task says "Start with three lives. Enemy shots cost a life with brief protection from repeated damage." So I'll start lives at 3 and display it.

Also "Increase score once" for each alien hit - so +1 per alien (or with value). I'll give each alien a point value (e.g., 10-40 based on row) but the key is score increases once per hit alien. I'll do that.

Let me write the file now.

For the HUD, I'll update score and lives elements.

Let me write everything.

Actually, let me reconsider the bunker damage and bullet-bunker interaction more carefully to ensure bullets pass through gaps. 

Bullet is a rectangle (x, y, w, h). When checking bunker collision, for each cell the bullet overlaps, if it's intact, destroy it and destroy bullet. If the bullet overlaps only destroyed cells (gaps), it passes through. This works naturally with my approach.

But there's subtlety: a player bullet goes upward. If it hits a bunker, it gets destroyed. But what if the bullet is small (4×10) and passes between cells? Since cells are 5px and bullet is 4 wide, the bullet might pass through a 5px gap. That's fine/expected.

Actually, for better bunker interaction, when a bullet hits, I should destroy it. Let me make the bullet destroy the bullet when ANY intact cell is hit. With my loop checking cells, I return true on first intact cell hit, destroying the bullet. Good.

Let me also handle the case where bullet partially overlaps - I check all cells the bullet's bounding box touches.

Let me write bunkerHit to take a bullet rect and bunker, and destroy overlapping intact cells with a 3x3 area, return whether a hit occurred.

```javascript
function bunkerHit(bullet, bunker) {
  const cell = bunker.cellSize;
  let hit = false;
  const gx1 = Math.floor((bullet.x) / cell - bunker.x / cell);
  // let me just use relative coords
  const relX = bullet.x - bunker.x;
  const relY = bullet.y - bunker.y;
  const cStart = Math.floor(relX / cell);
  const cEnd = Math.floor((relX + bullet.w) / cell);
  const rStart = Math.floor(relY / cell);
  const rEnd = Math.floor((relY + bullet.h) / cell);
  
  for (let r = rStart; r <= rEnd; r++) {
    for (let c = cStart; c <= cEnd; c++) {
      if (c >= 0 && c < bunker.cols && r >= 0 && r < bunker.rows) {
        if (bunker.grid[r][c]) {
          // destroy 3x3
          for (let dr = -1; dr <= 1; dr++) {
            for (let dc = -1; dc <= 1; dc++) {
              const nr = r + dr, nc = c + dc;
              if (nr >= 0 && nr < bunker.rows && nc >= 0 && nc < bunker.cols) {
                bunker.grid[nr][nc] = false;
              }
            }
          }
          hit = true;
        }
      }
    }
  }
  return hit;
}
```

Wait, this returns true if ANY intact cell is hit, and it destroys a 3x3 area around each hit. That's fine. But destroying cells while iterating might affect other checks - but since I mark them false and check `if grid[r][c]` before acting, subsequent iterations won't re-destroy. Good. But the 3x3 might destroy cells that were the "current iteration" target too - that's fine, just removes material.

Actually, there's a subtle issue: I check `if bunker.grid[r][c]` and if true, destroy 3x3 including itself. Then if another cell in the bullet's path was already destroyed by the 3x3, it won't re-trigger. Good.

But this means one hit can destroy a larger area. That's fine for visual effect. Maybe I'll make it just the single cell plus adjacent. Let me keep 3x3 it looks nice (circular-ish damage).

OK, I think I have enough. Let me write the complete code.

Let me also draw a starfield and ground line to make it look good.

Let me write the final file now. I'll be comprehensive.

Let me reconsider dimensions: 600×700 canvas. Playfield: alien area top ~60-400, bunkers at H-200, cannon at H-50.

Let me finalize alien grid: 11 cols × 5 rows, starting at x=80, y=70, spacing 45x45.

11 aliens × 45 = 495, + start 80 = 575 < 580. Fits.

Let me write it.

Actually, let me make alien grid 10 cols × 5 rows to be safe, spacing 50. 10×50 = 500, start 50 = 550, fits in 600 with margin.

Let me do 10 cols, 5 rows, spacing 50, start x=75, y=60. Each alien 40×40.

75 + 10*50 = 575, + 40 = 615 > 600. Hmm. Let me do 9 cols or spacing 45. Let me do 10 cols, spacing 45, start 60: 60 + 10*45 = 510, +40 = 550. Fits with margin on right. On left, 60 - margin. Good. Actually let me center: total width = 60 + 10*45 + 40 = 60 + 450 + 40 = 550 (if last alien at 60+9*45=465, +40=505). Hmm let me recompute: aliens at x = 60, 105, 160, ..., 60+9*45=465. Last alien right edge = 465+40=525. So right margin = 600-525=75. Left margin = 60. Slightly off-center but fine. Let me just use startX=60, spacing 46... eh, let me not overthink.

Let me do: alienCols = 11, alienRows = 5, spacing 42, startX = 55. 55 + 10*42 = 55+420 = 475, + alienW(34) = 509. Right margin 91. Let me center properly: alienW=34, cols=11, gap=42. Total span = 11*34 + 10*42 = 374+420 = 794. That's too wide! 

Let me recompute. Total span = cols*alienW + (cols-1)*gap. For cols=11, alienW=34: 11*34 = 374, + 10*gap. To fit in 600 with margins: 374 + 10*gap = 550 → gap = 17.6. That's too tight (aliens touching).

Let me reduce cols to 9: 9*34 = 306, + 8*gap = 550 → gap = 30.5. OK.

Or alienW = 28, cols = 11: 308 + 10*gap = 550 → gap = 24.2.

Let me do alienCols = 11, alienW = 28, alienH = 24, gap = 26, startX centered. Span = 11*28 + 10*26 = 308 + 260 = 568. Margins ~16. Hmm tight. Let me do 10 cols: 10*28 + 9*30 = 280+270 = 550. startX = 30. Good.

Let me use: alienCols=10, alienRows=5, alienW=28, alienH=24, gap=30, startX=35. 35 + 9*30 + 28 = 35+270+28 = 333... wait that's not right. The x positions: x[c] = startX + c * (alienW + gap)? No, let me just use a simple layout: x[c] = startX + c * spacing where spacing = 34. 35 + 9*34 + 28 = 35 + 306 + 28 = 369. Then I can center by computing startX.

Let me just compute startX = (W - ((alienCols-1)*spacing + alienW)) / 2. With cols=10, spacing=34, alienW=28: (600 - (9*34+28))/2 = (600 - 334)/2 = 133. Hmm that gives startX=133, too much margin.

OK I'm overcomplicating positioning. Let me just pick values that look good and not worry about perfect centering. Let me do:

- alienCols = 11, alienRows = 5
- alienW = 32, alienH = 28
- spacing = 40 (center-to-center)
- startX = 50

x positions: 50, 90, 130, ..., 50 + 10*40 = 450. Last right edge = 482. Good, fits in 600.

Actually that's fine! 50 + (c)*40 for c in 0..10. Right margin = 600 - 482 = 118. Not centered but fine. Let me center: startX = (600 - (10*40 + 32))/2... the last center is at 50 + 10*40 = 450, right edge 482. To center the whole thing: total width = 482 - 50 = ... the leftmost edge is 50, rightmost edge is 482. To center: I want (leftmost) = (600-432)/2 = 84. Let me set startX = 80. Then right edge = 80 + 10*40 + 32 = 512. Centered-ish (margin 88 on right, 80 on left). 

Eh, let me just set startX = 60. Good enough. The aliens will be within bounds and that's what matters.

Let me finalize: alienCols=11, alienRows=5, alienW=32, alienH=28, spacing=38, startX=55.

55 + 10*38 = 435, +32 = 467. OK centered within 600.

Let me go. Writing now.

Actually, let me make spacing such that movement reversal works well. Doesn't matter much.

Let me write the complete file. I'll set ALIEN_BASE_SPEED reasonably so the game feels good.

Let me also think: the classic game has aliens moving faster as they die. ALIEN_ACCEL ~ 0.8 (px/s per alien) with base 25. With 55 aliens, full speedup = 25 + 55*0.8 = 69 px/s. That feels a bit slow at start (25px/s) and fast at end (69). Maybe tune: base 30, accel 1.5: 30 to 112. That might be too fast at end. Let me do base 25, accel 1.2: 25 to 91. Reasonable.

Hmm, but the original speeds are quite fast. Let me go with base 28, accel 1.5, max ~110. Let me test and adjust.

Now let me write the code. I'll write the full HTML file.

Let me draft the complete file:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Space Invaders</title>
<style>
  *{margin:0;padding:0;box-sizing:border-box}
  html,body{height:100%}
  body{margin:0;background:#000;color:#fff;font-family:'Courier New',monospace;display:flex;justify-content:center;align-items:flex-start;min-height:100vh;padding-top:16px;overflow:hidden}
  #gameContainer{text-align:center}
  h1{font-size:26px;letter-spacing:3px;margin-bottom:4px;text-shadow:0 0 8px #0ff}
  #hud{font-size:18px;margin:8px 0}
  #hud span{color:#0f0;text-shadow:0 0 6px #0f0}
  canvas{background:#000;display:block;margin:0 auto;border:1px solid #333;box-shadow:0 0 20px #0ff2}
  #controls{font-size:13px;color:#8a8;margin-top:8px}
  button{margin-top:12px;padding:8px 18px;font-size:15px;font-family:inherit;background:#111;color:#0f0;border:1px solid #0f0;cursor:pointer;text-shadow:0 0 4px #0f0}
  button:hover{background:#0f0;color:#000}
</style>
</head>
<body>
<div id="gameContainer">
  <h1>SPACE INVADERS</h1>
  <div id="hud">SCORE: <span id="score">0</span> &nbsp; LIVES: <span id="lives">3</span></div>
  <canvas id="gameCanvas" width="600" height="700"></canvas>
  <div id="controls">← / → or A / D : MOVE &nbsp;|&nbsp; SPACE : FIRE</div>
  <button id="restartBtn" style="display:none">RESTART</button>
</div>
<script>
(() => {
  const canvas = document.getElementById('gameCanvas');
  const ctx = canvas.getContext('2d');
  const scoreEl = document.getElementById('score');
  const livesEl = document.getElementById('lives');
  const restartBtn = document.getElementById('restartBtn');
  
  const W = canvas.width, H = canvas.height;
  
  let keys = {};
  window.addEventListener('keydown', e => {
    if (e.code === 'Space') e.preventDefault();
    keys[e.code] = true;
  });
  window.addEventListener('keyup', e => { keys[e.code] = false; });
  window.addEventListener('blur', () => { keys = {}; });
  
  // Constants
  const CANNON_SPEED = 240;
  const BULLET_SPEED = 480;
  const BULLET_LIFETIME = 1.4;
  const FIRE_COOLDOWN = 0.22;
  const ENEMY_BULLET_SPEED = 200;
  const ALIEN_BASE_SPEED = 26;
  const ALIEN_ACCEL = 1.3;
  const ALIEN_DROP = 14;
  const ALIEN_FIRE_CHANCE = 0.005;
  
  const alienCols = 11, alienRows = 5;
  const alienW = 32, alienH = 28;
  const alienSpacing = 38;
  const alienStartX = 55;
  const alienStartY = 60;
  const totalAliens = alienCols * alienRows;
  
  let state = 'playing';
  let aliens = [];
  let alienDir = 1;
  let lives = 3;
  let score = 0;
  let invincible = 0;
  let cannonCooldown = 0;
  let bullets = [];
  let enemyBullets = [];
  let bunkers = [];
  
  const cannon = { x: W/2 - 25, y: H - 55, w: 50, h: 22, fireCd: 0 };
  
  // Alien sprites (6 cols, 5 rows)
  const alienSprites = [
    ["011110","111111","111111","011110","001100"],
    ["110011","111111","011110","001100","010010"],
    ["011110","111111","110011","011110","001100"],
    ["111111","101101","111111","010101","110011"],
    ["001100","111111","101101","011110","110011"],
  ];
  const alienColors = ['#00f0ff','#ffe138','#ff7538','#ff3c2c','#ff5ac8'];
  
  // Bunker
  const cellSize = 5;
  const bunkerPattern = [
    "000111111000",
    "001111111100",
    "011111111110",
    "111111111111",
    "111111111111",
    "111000110011",
  ];
  
  function initAliens() {
    aliens = [];
    for (let r = 0; r < alienRows; r++) {
      for (let c = 0; c < alienCols; c++) {
        aliens.push({
          x: alienStartX + c * alienSpacing,
          y: alienStartY + r * alienSpacing,
          w: alienW, h: alienH,
          row: r, col: c
        });
      }
    }
    alienDir = 1;
  }
  
  function createBunker(x, y) {
    const grid = [];
    for (let r = 0; r < bunkerPattern.length; r++) {
      grid.push([]);
      for (let c = 0; c < bunkerPattern[r].length; c++) {
        grid[r].push(bunkerPattern[r][c] === '1');
      }
    }
    return { x, y, grid, cellSize: cellSize,
      cols: bunkerPattern[0].length, rows: bunkerPattern.length,
      w: bunkerPattern[0].length * cellSize, h: bunkerPattern.length * cellSize };
  }
  
  function initBunkers() {
    bunkers = [];
    const bw = bunkerPattern[0].length * cellSize; // 60
    const bh = bunkerPattern.length * cellSize; // 30
    const count = 4;
    const spacing = (W - count * bw) / (count + 1);
    const by = H - 200;
    for (let i = 0; i < count; i++) {
      const bx = spacing * (i + 1) + i * bw;
      bunkers.push(createBunker(bx, by));
    }
  }
  
  function resetGame() {
    lives = 3; score = 0; state = 'playing'; invincible = 0; cannonCooldown = 0;
    bullets = []; enemyBullets = [];
    cannon.x = W/2 - 25; cannon.y = H - 55;
    initAliens();
    initBunkers();
    updateScore();
    updateLives();
    restartBtn.style.display = 'none';
    document.getElementById('message')... // no message
  }
  
  ...
})();
```

Hmm, I removed the message element. Let me add it back inline. Let me use a simple overlay via canvas or a div. Let me add a div#message in the HTML. Actually I'll add it via the container.

Let me keep message handling: I'll draw the message on the canvas itself for simplicity, OR use a div. A div overlay is cleaner. Let me add `<div id="message"></div>` and style it.

Let me restructure to include message div. Actually, I'll handle messages by drawing text on canvas (Game Over / Level Cleared) so everything's in canvas. That avoids overlay positioning issues. Let me do that.

```javascript
function drawMessage(text) {
  ctx.fillStyle = 'rgba(0,0,0,0.7)';
  ctx.fillRect(0,0,W,H);
  ctx.fillStyle = '#ff0';
  ctx.font = 'bold 40px "Courier New"';
  ctx.textAlign = 'center';
  ctx.fillText(text, W/2, H/2 - 30);
  ctx.font = '20px "Courier New"';
  ctx.fillText('Press RESTART or R to try again', W/2, H/2 + 10);
}
```

And use R key to restart too.

Now let me put together the entire game. Let me write it fully.

For the starfield, I'll generate random stars once.

Let me write the final complete code now.

Let me also handle input for restart via R key:

```javascript
if (state !== 'playing') {
  if (keys['KeyR'] || (restartBtn clicked)) resetGame();
}
```

Let me add a key listener for R.

Now, let me also double-check: bunkers should be between cannon and aliens. Bunkers at y = H-200 = 500. Cannon at y = H-55 = 645. Aliens from y=60 down to 60+4*38+28 = 60+152+28 = 240. So aliens top area, bunkers middle (500), cannon bottom (645). Good, bunkers between.

But wait - as aliens descend (drop) they get closer to bunkers. When they pass the bunkers... aliens move down 14px per drop. With 5 rows starting at y=60 and spacing 38, bottom row starts at 60+4*38 = 212, +28 = 240. They'd need many drops to reach 500. Fine.

Let me write the whole thing now. Let me make sure to handle all collision and game states.

I also want to ensure the alien bullets and player bullets can hit each other (optional). I'll add bullet-bullet collision for polish: a small chance they meet. Not required, but let me add it for completeness. Actually, let me keep it simpler and skip bullet-bullet collision unless easy. I'll add it: if a player bullet and enemy bullet overlap, destroy both. Simple.

Let me write the full code.

Let me also think about performance: small number of objects, fine.

Now, the update function structure:

```javascript
function update(secs) {
  if (state !== 'playing') return;
  
  // Input - cannon
  let dx = 0;
  if (keys['ArrowLeft'] || keys['KeyA']) dx -= 1;
  if (keys['ArrowRight'] || keys['KeyD']) dx += 1;
  cannon.x += dx * CANNON_SPEED * secs;
  cannon.x = Math.max(4, Math.min(W - cannon.w - 4, cannon.x));
  
  // Fire
  cannonCooldown -= secs;
  if ((keys['Space'] || keys['Space']) && cannonCooldown <= 0) {
    // need a flag to avoid continuous fire on hold? 
  }
}
```

Issue: if player holds Space, should they be able to fire repeatedly at cooldown rate? In the classic game, holding fire fires once per cooldown. With keydown events repeating (which happens for held keys in browsers), Space would repeat. But I want controlled fire rate. Let me handle: fire when Space is just pressed (transition) OR when cooldown is ready and key is held.

Actually, holding Space and firing at cooldown rate is acceptable (classic behavior: hold to auto-fire). Let me fire when cooldown <= 0 && keys.Space, then reset cooldown. This allows auto-fire at the cooldown rate. That's fine and matches "bound fire rate."

But key repeat: keys.Space stays true while held. So with cooldown gating, fire happens every FIRE_COOLDOWN. Good, that's the bound fire rate.

Let me check Space both via 'Space' code. e.preventDefault() on keydown for Space prevents page scroll. Good.

Now bullets update:
```javascript
for (let i = bullets.length-1; i>=0; i--) {
  const b = bullets[i];
  b.y -= BULLET_SPEED * secs;
  b.life += secs;
  // check bounds
  if (b.y > H || b.life > BULLET_LIFETIME) { bullets.splice(i,1); continue; }
  // check alien hit
  let hit = false;
  for (let j = aliens.length-1; j>=0; j--) {
    const a = aliens[j];
    if (rectOverlap(b, a)) {
      aliens.splice(j,1);
      score += 40 - a.row * 8; // top=40, bottom=... let me do 50,30,20,10? 
      score = Math.max(score, ... )
      updateScore();
      hit = true;
      score += 10 + a.row * 5;
      updateScore();
      break;
    }
  }
  if (hit) { bullets.splice(i,1); continue; }
  // check bunker hit
  for (const bunker of bunkers) {
    if (bunkerHit(b, bunker)) { bullets.splice(i,1); break; }
  }
}
```

Wait I have a duplicate score line. Let me fix: `score += 10 + a.row * 5;` (row 0 = 10, but let me do row-based values). Actually in Space Invaders scoring: top row 10? No. The classic: squid=30? Let me just give value = 10 + (alienRows - a.row) * 5 or simpler: row-based: top=40, next=30, next=20, next=10, bottom=5? Actually original scores: 10, 20, 30 (but that's by type not row). Let me just do: value based on row from top: row 0 = 40, row 1 = 30, row 2 = 20, row 3 = 10, row 4 = 5? That's 5 tiers but maybe weird.

Let me just keep it simple: each alien = 10 points, with bonus for higher rows. `score += 10; ` plus if row 0 (top, fastest to clear) maybe 40. Let me do: value = [40, 30, 20, 10, 10][row]. Eh, I'll just use `score += 10 + a.row * 3;` So row 0 = 10, row 4 = 22. Simple enough and score increases once per alien.

Actually, the requirement just says "increase score once" per hit alien. So any value is fine. Let me use `score += 10 + (4 - a.row) * 5;` (top row = 30, bottom = 10). That's a nice progression. Let me do that.

Now enemy bullets:
```javascript
for (let i = enemyBullets.length-1; i>=0; i--) {
  const b = enemyBullets[i];
  b.y += ENEMY_BULLET_SPEED * secs;
  b.life += secs;
  if (b.y > H+10 || b.life > 2.5) { enemyBullets.splice(i,1); continue; }
  // hit cannon
  if (rectOverlap(b, cannon)) {
    enemyBullets.splice(i,1);
    if (invincible <= 0) {
      lives--;
      updateLives();
      invincible = 2.0; // 2 seconds protection
      if (lives <= 0) {
        state = 'gameover';
      }
    }
    continue;
  }
  // hit bunker
  for (const bunker of bunkers) {
    if (bunkerHit(b, bunker)) { enemyBullets.splice(i,1); break; }
  }
}
```

Alien firing:
```javascript
function alienFire(secs) {
  if (aliens.length === 0) return;
  // bottom-most per column
  const bottom = {};
  for (const a of aliens) {
    if (!bottom[a.col] || a.y > bottom[a.col].y) bottom[a.col] = a;
  }
  const candidates = Object.values(bottom);
  if (Math.random() < ALIEN_FIRE_CHANCE) {
    const s = candidates[Math.floor(Math.random() * candidates.length)];
    enemyBullets.push({ x: s.x + s.w/2 - 3, y: s.y + s.h, w: 6, h: 12, life: 0 });
  }
}
```

Alien movement:
```javascript
function moveAliens(secs) {
  if (aliens.length === 0) {
    if (state === 'playing') {
      state = 'win';
    }
    return;
  }
  const speed = ALIEN_BASE_SPEED + (totalAliens - aliens.length) * ALIEN_ACCEL;
  let minX = Infinity, maxX = -Infinity;
  for (const a of aliens) {
    minX = Math.min(minX, a.x);
    maxX = Math.max(maxX, a.x + a.w);
  }
  let moveDir = alienDir;
  if (alienDir > 0 && maxX + speed*secs > W - 12) {
    alienDir = -1; moveDir = -1;
    for (const a of aliens) a.y += ALIEN_DROP;
  } else if (alienDir < 0 && minX + speed*secs*moveDir - ... ) {
  }
  // need careful
}
```

Let me be careful with the reverse logic. I'll compute the prospective position and check bounds:

```javascript
function moveAliens(secs) {
  if (aliens.length === 0) { if (state=='playing') state='win'; return; }
  const speed = ALIEN_BASE_SPEED + (totalAliens - aliens.length) * ALIEN_ACCEL;
  let moveDir = alienDir;
  let minX = Infinity, maxX = -Infinity;
  for (const a of aliens) { minX = Math.min(minX,a.x); maxX=Math.max(maxX,a.x+a.w); }
  
  const step = speed * secs * moveDir;
  if (moveDir > 0 && maxX + step > W - 12) {
    alienDir = -1; moveDir = -1;
    for (const a of aliens) a.y += ALIEN_DROP;
  } else if (moveDir < 0 && minX + step < 12) {
    alienDir = 1; moveDir = 1;
    for (const a of aliens) a.y += ALIEN_DROP;
  }
  
  for (const a of aliens) a.x += speed * secs * moveDir;
  
  // Check game over (aliens reached player zone)
  for (const a of aliens) {
    if (a.y + a.h >= cannon.y) {
      state = 'gameover';
      return;
    }
  }
}
```

Wait there's a bug: when reversing, I set moveDir so aliens move inward this frame (good, they won't go past edge). After drop, they move with the new direction. Good.

Now the draw function:

```javascript
function draw() {
  // clear
  ctx.fillStyle = '#000';
  ctx.fillRect(0,0,W,H);
  
  // stars
  drawStars();
  
  // ground
  ctx.fillStyle = '#444';
  ctx.fillRect(0, H-30, W, 2);
  
  // aliens
  for (const a of aliens) drawAlien(a);
  
  // bunkers
  for (const b of bunkers) drawBunker(b);
  
  // bullets
  ctx.fillStyle = '#0ff';
  for (const b of bullets) ctx.fillRect(b.x,b.y,b.w,b.h);
  
  // enemy bullets
  ctx.fillStyle = '#f55';
  for (const b of enemyBullets) ctx.fillRect(b.x,b.y,b.w,b.h);
  
  // cannon
  if (invincible <= 0 || (invincible*10 % 2 < 1)) {
    drawCannon();
  }
}

function drawCannon() {
  ctx.fillStyle = '#0f0';
  // main body (trapezoid-ish using rect)
  ctx.fillRect(cannon.x, cannon.y + 8, cannon.w, cannon.h - 8);
  // turret
  ctx.fillRect(cannon.x + cannon.w/2 - 8, cannon.y, 16, 8);
  // ... details
}
```

Let me make the cannon look like the classic: a triangular/curved top with a rectangular base and a gun. I'll draw:
- Base rectangle
- Two antennae or a trapezoid top

Let me draw:
```javascript
function drawCannon() {
  const c = cannon;
  ctx.fillStyle = '#0f0';
  // base
  ctx.fillRect(c.x, c.y + 10, c.w, c.h);
  // top trapezoid (pointed)
  ctx.beginPath();
  ctx.moveTo(c.x, c.y + 10);
  ctx.lineTo(c.x + c.w, c.y + 10);
  ctx.lineTo(c.x + c.w - 10, c.y);
  ctx.lineTo(c.x + 10, c.y);
  ctx.closePath();
  ctx.fill();
  // gun
  ctx.fillStyle = '#0ff';
  ctx.fillRect(c.x + c.w/2 - 4, c.y - 8, 8, 12);
  // details
}
```

For aliens, drawAlien with sprite:
```javascript
function drawAlien(a) {
  const sprite = alienSprites[a.row];
  const color = alienColors[a.row];
  ctx.fillStyle = color;
  const cols = sprite[0].length, rows = sprite.length;
  const cs = a.w / cols;
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      if (sprite[r][c] === '1') {
        ctx.fillRect(a.x + c*cs, a.y + r*cs, cs, cs);
      }
    }
  }
}
```

Hmm, a.w=32, sprite cols vary (6). cs = 32/6 = 5.33. Fine with fillRect.

For bunkers:
```javascript
function drawBunker(b) {
  ctx.fillStyle = '#58d';  // or '#0f8' 
  const cs = b.cellSize;
  for (let r = 0; r < b.rows; r++) {
    for (let c = 0; c < b.cols; c++) {
      if (b.grid[r][c]) ctx.fillRect(b.x + c*cs, b.y + r*cs, cs, cs);
    }
  }
}
```

Bunker color: let me use a yellowish-green '#fc3'. Or '#5a4' . Let me use '#8a3f0' ... let me use '#ca8' (brownish). The classic bunkers are green/yellow. Let me use '#8f5'.

OK, I think I have a complete mental model. Let me write the file.

One more: the win/gameover state display. After switching state, I'll draw a message overlay. Let me handle in the main render.

Also restart via R and button.

Let me write the complete file now.

I also want to track time since game end for the message. Let me just draw message when state != playing.

Let me write it all out:

```javascript
// starfield
let stars = [];
function initStars() {
  stars = [];
  for (let i=0;i<80;i++){
    stars.push({x:Math.random()*W, y:Math.random()*H, s:Math.random()*1.5+0.5});
  }
}
function drawStars() {
  ctx.fillStyle = '#fff';
  for (const st of stars) ctx.fillRect(st.x, st.y, st.s, st.s);
}
```

OK now let me assemble the entire file. Let me write it.

Let me reconsider ALIEN_FIRE_CHANCE = 0.005 per frame at 60fps = 0.3 per second. That might be too frequent. Let me make it a per-call check scaled by secs. I'll call alienFire each update with secs: `if (Math.random() < ALIEN_FIRE_CHANCE * secs * 60)` or just a timer-based approach. Let me use a simple timer: aliens accumulate a chance based on time. Actually simplest: per update, `Math.random() < ALIEN_FIRE_CHANCE` where chance is small, e.g., 0.002. At 60fps that's ~0.12/sec. With ~55 aliens, expected ~0.12 * ... hmm.

Let me think: I want roughly 1 enemy shot per ~0.5-1s early on. Let me set a timer that fires a shot every random interval between 0.5 and 1.2s, picking the bottom-most of a random column.

```javascript
let alienFireTimer = 0;
function alienShooting(secs) {
  alienFireTimer -= secs;
  if (alienFireTimer > 0) return;
  alienFireTimer = 0.6 + Math.random() * 0.6;
  // pick a random alive column's bottom alien
  const cols = {};
  for (const a of aliens) {
    if (!cols[a.col] || a.y > cols[a.col].y) cols[a.col] = a;
  }
  const candidates = Object.values(cols);
  if (candidates.length === 0) return;
  const s = candidates[Math.floor(Math.random()*candidates.length)];
  enemyBullets.push({x: s.x+s.w/2-3, y: s.y+s.h, w:6, h:12, life:0});
}
```

That gives a controlled rate. Good.

Now let me write the whole file. Final.

Let me also make sure the cannon doesn't fire while invincible? No, player can always fire during invincibility (that's fine - they just can't take damage).

Let me also reconsider: after game over/win, I should stop the game loop update but keep rendering. My update() returns early when state != 'playing', and draw always runs. But I want the game loop to keep running to show the message and allow restart. The loop continues via requestAnimationFrame regardless. Good.

Now restart: resetGame sets state='playing', recreates everything. Also clear keys to avoid firing immediately? Not necessary but let me clear relevant keys.

Let me write the file. Let me also add the R key handling.

Let me write it all now and then test.

Final code assembly. Let me be careful with the rectOverlap helper:

```javascript
function rectOverlap(r1, r2) {
  return r1.x < r2.x + r2.w && r1.x + r1.w > r2.x &&
         r1.y < r2.y + r2.h && r1.y + r1.h > r2.y;
}
```

Now let me also handle bullet-bullet collision (optional, quick):
```javascript
// between player and enemy bullets - optional
for (let i = bullets.length-1; i>=0;i--){
  for (let j = enemyBullets.length-1; j>=0;j--){
    if (rectOverlap(bullets[i], enemyBullets[j])){
      bullets.splice(i,1); enemyBullets.splice(j,1); break;
    }
  }
}
```

I'll include it for polish. Put it before bullet updates or as part of. Let me put a quick check.

Actually, to avoid bugs, let me keep bullet-bullet collision simple and add it. It's a nice touch.

OK writing the complete file now. Let me make it clean and correct.

Let me reconsider the alien drop behavior near the bottom combined with the win check. When aliens.length becomes 0 during bullet processing, the next frame moveAliens will detect empty and set win. Good. But I should also clear remaining bullets maybe. Not necessary.

Let me write the file now.

I realize I should double check: "Aliens reaching the player zone or zero lives causes Game Over; clearing the aliens shows a win state." My conditions: aliens.y + h >= cannon.y → gameover; aliens.length===0 → win. zero lives → gameover. 

Also "clearing the aliens shows a win state" - win when all aliens dead. Good.

Now let me write it.

Let me make the canvas have a nice border/glow. I'll use CSS box-shadow.

Let me finalize dimensions and write.

Let me write the complete index.html file now.

Also, I want to make sure the firing during invincibility and the protection works. Let me re-examine: when invincible > 0, enemies can still shoot, and if they hit the cannon, the bullet is destroyed but no life lost (during invincibility). After 2s, player can be hit again. Good. The cannon flashes during this.

Let me also add: while invincible, maybe player bullets still fire (yes, allowed). Good.

Let me write the code. Final version:

Actually, let me reconsider the invincibility flash condition. `invincible*10 % 2 < 1` - invincible is seconds. As it counts down, this flashes. Let me use a simpler approach with a frame counter. Let me track invincible as a time that decreases, and flash based on `Math.floor(invincible * 10) % 2 === 0`. 

Actually let me track a separate flash timer or use the invincible value: `if (Math.floor(invincible * 8) % 2 === 0)` draw cannon. When invincible=0, draw always (Math.floor(0*8)%2 = 0, true). Good. During invincibility it flashes. Good.

Let me write the full file.

I'm confident now. Let me write it.

One more consideration: I use `e.preventDefault()` for Space to prevent scrolling. But I also read keys['Space'] on keydown. If I preventDefault on Space keydown, the keydown event still fires and sets keys['Space']=true. Good. On keyup, keys['Space']=false. But if page scrolls... with preventDefault it won't. Good.

Also, I should make sure that holding Space doesn't cause issues with the cooldown reset. Already handled.

Let me write the file. I'll write it all in one go.

Let me reconsider the alien sprite arrays - make them consistent width so cs calculation is clean. Let me make all sprites 6 wide:

```javascript
const alienSprites = [
  ["011110","111111","111111","011110","001100"],  // 6 wide, 5 tall - cyan
  ["100001","111111","101101","111111","100001"],   // yellow
  ["011110","111111","111111","110011","011110"],   // orange
  ["111111","111111","110111","111111","111111"],   // red - fills? 
  ["111111","101101","111111","011110","110011"],   // pink
];
```

Hmm let me make them distinct and recognizable. Let me design 5:

Type 0 (cyan, "squid"):
```
011110
111111
111111
011110
001100
```

Type 1 (yellow, "crab"):
```
100001
111111
110011
111111
100001
```

Type 2 (orange, "spider"):
```
011110
110011
111111
111111
110011
```

Type 3 (red):
```
011110
111111
101101
111111
011110
```

Type 4 (pink):
```
111111
100001
111111
011110
110011
```

These are fine - distinct enough. Good.

Now let me write the complete file. I'll write it.

Let me also double-check the score update function:
```javascript
function updateScore() { scoreEl.textContent = score; }
function updateLives() { livesEl.textContent = lives; }
```

Good.

Now let me write the complete file. Final.

Actually, I realize for `cannonCooldown` I declared both a variable and a property. Let me just use `cannon.fireCd` property. Let me be consistent. I'll use local variables `let cannonCooldown` and track on cannon object. Let me simplify: use `cannon.cd`.

Let me restructure cleanly:

State variables:
- cannon = { x, y, w, h }
- let fireCd = 0
- let bullets[], enemyBullets[], aliens[], bunkers[]
- let alienDir, lives, score, invinc, state

Functions: initAliens, initBunkers, resetGame, update(secs), draw, moveAliens, updateBullets, updateEnemyBullets, alienShooting, bunkerHit, rectOverlap, drawStars, drawAlien, drawCannon, drawBunker, drawMessage, updateHUD

Game loop with requestAnimationFrame.

Let me write it all.

I'm going to write the file now via the write tool.

Let me carefully write it so it's correct on first try, then test.

Let me write it out fully.

Note: when state is gameover/win, I still want to render the message. Let me have draw always render, and if state != playing, render message overlay.

Let me also animate the message slightly or just static. Static is fine.

Let me write.

Also I should make restartBtn work: onclick = resetGame. And R key = resetGame when not playing.

Let me also reset alienFireTimer in resetGame.

Let me write the complete file now.

Let me consider: do I need `lastTime` for the game loop? Yes for dt. Let me use:
```javascript
let last = performance.now();
function loop(now) {
  const secs = (now - last) / 1000;
  last = now;
  const capped = Math.min(secs, 0.05); // avoid huge dt on tab switch
  update(capped);
  draw();
  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);
```

Good.

Now writing the file. Let me also ensure canvas doesn't have image-rendering issues - I'll leave default (or set to auto since not pixel art). Actually procedural vectors, so leave default.

Let me write the complete final index.html.

Let me make sure to test these behaviors per the task:
- Movement (A/D, arrows)
- Firing
- Alien motion + edge reversal + descent
- Shot hitting bunker → damage
- Shot hitting alien → removed + score
- Lives display
- Game over / win
- Restart
- Invincibility after hit
- Projectile lifetime / fire rate

I'll write, then run in browser and verify.

Let me write the file.

Now let me write the full content using the write tool again with the complete file. Let me compose it carefully.

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

The DOM renders. Let me inspect the canvas to make sure it draws. Let me take a screenshot to see the visual.

The screenshot tool doesn't show images. Let me try the inspect action to look at the canvas and console more deeply.

Interesting - the lives shows 2 now, which means an enemy bullet hit the cannon. There's something happening - the game is running and an enemy bullet already hit the cannon, reducing lives to 2. That suggests enemy bullets are being fired and hitting the cannon, which is correct behavior. But it happened immediately, which seems too fast. Let me think.

Wait, lives went from 3 to 2. This means during the inspection/reload, the game ran for some time and an enemy bullet hit the cannon. The alien fire timer starts at 0, so on the first update, alienFireTimer (0) <= 0 triggers, sets timer to 0.7-1.2s, and fires a bullet from a random bottom alien. The bullet travels down at 210px/s. If the cannon is directly below, it could hit. 

But that means within ~1 second an enemy bullet hit. That's actually plausible behavior. The game is running. Good - movement, firing, alien shooting all work.

But wait - this means the game continued running while I was inspecting. The enemy bullet hit the cannon. That's fine - it's expected behavior.

Let me now do a more controlled test. Let me interact with the game: test movement and firing. Let me click/tap to focus and use key inputs. Actually, the browser tool has a 'key' action. Let me test movement with key.

But first, let me reconsider: the game auto-runs on load and plays. By the time I inspect, some time has passed. That's OK.

Let me test specific behaviors:
1. Movement: send ArrowRight / KeyD keys
2. Firing: send Space
3. Restart: send KeyR

Let me also check the console for errors. The console only shows the sandbox warning (not a real error). No JS errors. Good - the script ran without errors.

Let me test movement and firing. Let me use the key action. But the key action might need focus. Since keys are on window, it should work.

Let me test:
1. Press Space to fire - should create a player bullet
2. Press ArrowRight to move
3. Fire and hit an alien

Actually, let me think about whether the enemy bullet hitting immediately is a problem. It reduced lives to 2. Let me restart (R) and observe the fresh state, then test movement/firing without enemy bullets interfering too much.

Let me first restart the game with R key, then observe fresh state.

Actually, let me test key interactions. Let me press R to restart, then move and fire.

Let me also consider: the enemy fire chance - alienFireTimer starts at 0, so the first shot fires almost immediately (within the first frame). That's a bit aggressive. Maybe I should start it with a small delay. But it's not wrong. Actually, it might be too harsh that enemies fire very quickly. Let me reconsider - actually alienFireTimer=0 at start means first update triggers a shot after 0-0.5s. That's fine-ish but maybe too early. The classic game has aliens fire after a moment. But it's acceptable. However, the issue is the cannon is centered and aliens fire at bottom-most per column. A straight-down shot from a column aligned with the cannon would hit. With 11 columns spread across 600px, and cannon at center (x~275), the alien above x=275 would be column... alienStartX=58, spacing 40, so column centers at 58+40c+16. For x=275: 58+40c+16=275 → 40c=201 → c=5.025. So column 5 center = 58+200+16 = 274. Close to cannon center 275. So the alien in column 5 (index 5, 6th from left) is roughly above the cannon. If that alien is the bottom one in its column and fires, the bullet goes straight down and hits the cannon. That's actually realistic.

But the issue: it happened "immediately" during my inspect, which means I didn't get to test the opening formation cleanly. Let me restart and test movement/firing quickly before enemy shots interfere. Enemy shots take ~0.7s+ to fire and ~1.5s+ to reach bottom (490px / 210 = 2.3s). So I have ~2s before first enemy shot reaches. That's plenty to test movement and firing.

Let me restart and test.

Let me press R to restart.

Hmm, the R key should restart and reset lives to 3, but it still shows LIVES: 2. Let me check - maybe the key event 'r' (lowercase) isn't matching 'KeyR'. The keydown event for 'r' would have e.code = 'KeyR' regardless of case. But the browser 'key' action sends text "r". How does the harness translate text to a keydown event? It might send e.code='KeyR' or e.key='r'. 

Actually, the issue might be that the harness sends a keydown event, but maybe my R-restart only fires on keydown when state !== 'playing'. After the enemy shot, state should still be 'playing' (lives=2, not 0). So state === 'playing', and my R handler checks `state !== 'playing'` - so R restart won't fire while playing! That's the bug in my logic: I only allow R restart when NOT playing. But the task says "Provide Restart" - and I also have the RESTART button which calls resetGame directly.

Wait, the requirement: "Provide Restart to restore aliens, bunkers, score, lives, and player position." The Restart should be available to restore the game. My restartBtn (showing only when not playing) calls resetGame. But R key only restarts when not playing.

But the user expects to be able to restart at any time? The task says "Restart to restore aliens, bunkers, score, lives, and player position." This implies restarting resets the whole game. Typically restart is available after game over/win, but could also be a fresh-start anytime.

Hmm, but during my test, I wanted to restart to get a clean state. The R key didn't work because state is 'playing'. 

Let me reconsider. The issue: I want R to restart anytime (or at least when not playing). But for testing, I'd like to restart anytime. Let me make R restart anytime - that's more user-friendly and matches "Provide Restart". But then during play, accidentally pressing R would restart. That's probably fine for this game.

Actually, let me reconsider the requirement. The typical Space Invaders "restart" is after game over. But the task's verification says "Use Restart and check the initial formation, bunkers, lives, and score." This implies using the Restart (button) to restore initial state. The Restart button appears after game over/win. So the flow is: play until game over, then press Restart.

But for my testing, I need a clean state. Let me make R work anytime so I can test. Actually, let me reconsider: maybe I should make the RESTART button always available, OR make R always restart. 

Let me think about what's best for the game. Having restart available anytime is fine and convenient. Let me make R restart anytime and keep the button visible always (or at least functional). Actually, having the button always visible is fine too.

But wait - there might be an issue. Let me re-examine: the R key handler:
```js
if (e.code === 'KeyR' && state !== 'playing') { resetGame(); }
```

Since state is 'playing', R does nothing. The button is hidden (style.display='none'). So neither R nor button restarts during play.

For the game, restart-after-gameover is the classic design. But let me make it more testable and user-friendly: allow R to restart anytime, and show the restart button always (or hide only conceptually). 

Hmm, but if I show the button always, it's always clickable to restart - that might be too easy to accidentally reset. Let me keep the button showing after game over/win (classic), but ALSO allow R to restart anytime for convenience. Actually, mixing might confuse. 

Let me reconsider the task verification: "Use Restart and check the initial formation, bunkers, lives, and score." This is testing that Restart restores the initial state. The cleanest test: let the game reach game over (or win), then use Restart, and verify initial state is restored.

But to get to game over quickly, I'd let aliens descend or lose all lives. That takes time. Alternatively, I make R restart anytime.

I think the best design: Restart (button + R) restores the initial game state. Make it available always (button always visible) so the player can restart at any time. This is actually a common, friendly design. Let me do that - button always visible, R always restarts.

Wait, but then "three lives" and "game over" states are less meaningful if you can always restart. But the game still shows game over/win messages. The restart is just a convenience. That's fine.

Actually, let me reconsider - maybe keep restart only after game over/win (classic), but for MY testing I'll trigger a game over. Hmm, that's tedious.

Let me just make R restart anytime and keep the button visible always. This satisfies "Provide Restart to restore..." unambiguously. Let me update:

1. Remove the `state !== 'playing'` guard on R (allow anytime).
2. Make restartBtn always visible.

But actually, having the button always visible during play looks odd. Let me keep the button shown always but maybe that's fine - it's a "RESTART" button always there. Many games have that.

Alternatively: keep button hidden during play, shown after game over/win; R works anytime. That way the button follows classic behavior and R is a shortcut. But then during play, only R restarts. That's fine for testing.

Hmm, but the task says "Provide Restart" - the button is the provided restart. Let me make the button always available. Let me reconsider.

Actually, you know what, let me keep it clean and classic: 
- RESTART button appears + is functional after game over/win.
- R key restarts anytime (convenience + testing).

This way:
- Normal play: press R anytime to reset (useful for testing).
- After game over: button appears, click or press R.

But wait, if R restarts anytime, then during play R resets the game. Is that bad? For a test harness it's great. For users, it might be slightly confusing but acceptable.

Hmm, let me reconsider. Actually a cleaner approach that satisfies everything: Make restart available anytime via both R and a always-visible button. Let me just do that. The button always shows. Simple and testable.

Wait, but if the button is always visible and I show it inline, the layout shifts. Let me keep it always visible (not display:none). Let me change the draw() logic to always show the button.

Actually, let me reconsider the cleanest design that's also good UX:
- Button always visible below controls.
- R key always restarts.
- After game over/win, a message overlay appears; clicking restart or pressing R resets.

Let me go with: button always visible, R always restart. Update the code.

Let me make these edits:
1. In keydown handler, change `state !== 'playing'` to always (remove guard).
2. In draw(), remove the display toggle, OR always show button. Let me set `restartBtn.style.display = 'inline-block'` always — but during play, do we want it shown? Yes, always available.

Hmm, actually showing RESTART button during active play is a bit unusual. Let me think about the verification step again: "Use Restart and check the initial formation, bunkers, lives, and score." 

I think the intended test is: start game → play → reach game over or just click restart → verify everything reset to initial (aliens grid, bunkers full, lives=3, score=0, cannon centered).

To test this cleanly, restart must restore initial state. The simplest: I let R restart anytime. Let me make R restart anytime and keep button shown after game over. But to test during play (fresh), R works.

Actually, the cleanest for testing: make R always restart. Let me just do that and keep the button shown always too. Let me update both.

Wait, but if button is always shown, the initial check shows button. That's fine.

Let me reconsider: maybe keep button hidden during play (clean look) but R always works. Then for my test, I use R. And after game over, button appears. This gives clean UX + testable. Let me do that.

So changes:
1. R key always restarts (remove `state !== 'playing'` guard).
2. Keep button showing only after game over/win (current draw logic).
3. restartBtn.onclick = resetGame (always, via the listener).

But during play, if I want to test restart via the button, the button isn't visible. So I'll use R for testing restart during play. That works.

Let me update the R handler to always restart. Let me also make sure resetGame works when called via R during play.

Let me edit.

Also, I realize there might be another subtle issue: when I pressed 'r' (lowercase text), did the harness generate a keydown with code KeyR? The console shows no error, and lives stayed 2 (no restart). If the handler fired but state was 'playing' (guard), it wouldn't restart. So the guard prevented it. Let me remove the guard.

Actually wait - maybe the harness 'key' action with text "r" sends e.key='r' but e.code might be undefined or 'KeyR'. If e.code is undefined, my check `e.code === 'KeyR'` fails. Let me handle both e.code and e.key. Let me check for `e.key === 'r' || e.key === 'R' || e.code === 'KeyR'`.

Hmm, the harness likely synthesizes a KeyboardEvent. Let me make the handler robust: check both e.code and e.key.

Let me update the keydown handler to handle R robustly and always restart.

Let me also reconsider: the 'Space' and movement keys - I tested via the harness? No, I only sent 'r'. Let me test movement and firing with key action too. But I'm not sure the harness key action properly simulates. Let me make the handlers robust and test.

Let me look at how the harness sends key events - it sent text "r". The resulting event: likely a keydown with key='r', code='KeyR' (most emulators set code based on the letter). Let me assume code='KeyR'. But to be safe, check e.key.

Let me update the handler:
```js
window.addEventListener('keydown', (e) => {
  if (e.code === 'Space') e.preventDefault();
  keys[e.code] = true;
  if ((e.code === 'KeyR' || e.key === 'r' || e.key === 'R') && !e.repeat) {
    e.preventDefault();
    resetGame();
  }
});
```

Wait, but if R always restarts during play, then while playing, holding R... e.repeat prevents repeated restarts when held. With `!e.repeat` it fires once on press. Good.

But there's an issue: if I remove `state !== 'playing'` guard, R restarts even during play. Good for testing. But the `!e.repeat` - when testing via harness, the key is pressed once (no repeat), so it fires. Good.

Let me also make sure keys[e.code]='r'... wait, I set keys[e.code]=true. For 'r', e.code='KeyR', so keys['KeyR']=true. That's harmless (I don't use KeyR for movement). Fine. But it stays true until keyup. The harness might not send keyup. That's fine since nothing checks KeyR during play.

Actually, for movement testing, I'll send 'ArrowRight' and 'Space' and 'KeyD' etc. Let me ensure those work. e.code for pressing → would be 'ArrowRight', 'KeyD', 'Space'. The harness text for these might be different. Let me check: the harness 'key' action takes text. For arrow keys, text might be 'ArrowRight'? Or a special? Hmm. The harness description: `key` with `text` parameter. It probably simulates typing that text. For 'r' it sent a keydown+keyup? Actually it might just send keydown. 

This is uncertain. Let me instead make the game also respond to the key being "pressed" via text. But I can't easily know the harness's mapping. 

Alternative: Let me reconsider testing. The key action may not reliably simulate game controls. But the task says "Run the application in the browser and inspect the initial output and console. Use the available browser tools for a brief pass through the representative checks."

Maybe the better approach: since I can't fully control timing with the harness, let me at least verify:
1. The game renders (canvas draws aliens, bunkers, cannon). ✓ (DOM shows, but I can't see image)
2. No JS errors. ✓
3. Movement/fire work via key presses.

Since the screenshot doesn't show images, I can't visually verify. But the DOM text shows LIVES: 2 (changed from 3), proving the game loop is running and enemy bullets hit the cannon. That confirms: aliens move, enemy shoots, bullets collide with cannon. 

Let me verify more behaviors by triggering events and observing DOM changes (HUD updates are text-rendered and visible in DOM).

Let me restart via R (after fixing the handler), then test:
- Fire (Space) → score should... well, firing alone doesn't change HUD unless I hit an alien. But I can't easily aim. 
- Move (ArrowRight) → cannon moves (no HUD change visible, but no error).
- Restart → HUD resets to SCORE 0 LIVES 3.

Since HUD is the visible text, I can track: score changes when alien hit, lives change when hit.

Let me make the fixes first, then test.

Let me also add: maybe make the cannon invincibility flash visible. Already done.

Let me also reconsider: maybe I should make a longer-lived testing by slowing enemy fire initially. But it's not necessary.

Let me apply the R-key fix and the robust key handling. Let me edit.

Actually, let me reconsider whether R should restart during play. The task: "Provide Restart to restore aliens, bunkers, score, lives, and player position." This strongly implies Restart = full reset to initial. It doesn't say "only after game over." So allowing R to restart anytime is fine and arguably expected (so you can restart the formation). 

But there's a subtlety: if R restarts anytime during play, the "Game Over" / "Win" states become skippable. That's OK.

Let me also consider: maybe keep the RESTART button always visible so "Provide Restart" is clearly satisfied (a visible button). Let me make the button always visible. That way the user sees a Restart button always. Combined with R key. This best satisfies "Provide Restart."

Decision:
- restartBtn always visible (inline-block).
- R key always restarts (no state guard), with !e.repeat.
- Button onclick = resetGame.

Let me update the code accordingly.

Let me make the edits.

The edit tool wants an array of edit objects. Let me redo the edit with the correct format (edits array). Let me also make the button always visible. Let me do both edits.

Actually, I'm running low on time (5 min left). Let me make the essential fixes quickly:
1. Fix R-key handler (always restart, robust).
2. Make button always visible.

Let me do these edits with proper array format.

Now let me also add the onclick handler for the restart button. Let me check if it's already there. In my code I had `restartBtn.addEventListener('click', resetGame);` — let me verify. Actually I wrote:
```js
restartBtn.addEventListener('click', resetGame);
```
Let me check the original file... Yes I included it in the "Start" section? Let me re-read. Actually I'm not sure I added the click listener. Let me check the file. In my written code, I had:

```js
/* ---------------- Start ---------------- */
  initStars();
  resetGame();
  updateHUD();
  requestAnimationFrame(loop);
})();
```

I did NOT add the restartBtn click listener! Let me check... Looking at my written code, I don't see `restartBtn.addEventListener('click', resetGame);`. Let me add it. But wait, the restartBtn is defined with `const restartBtn = document.getElementById('restartBtn');`. I need to wire its click.

Let me read the file to confirm and add the click listener.

Actually, given time constraints, let me just quickly add the click listener. Let me read the relevant part of the file first.

I see - the restart button click listener is missing. Let me add it. Let me read lines around 495-510 to add the click listener.

Now let me reload and test. Let me reload the browser and check that R restarts the game (lives should go back to 3).

Let me reload and inspect.

Now the game starts fresh: SCORE: 0, LIVES: 3, and the RESTART button is visible. Good.

Now let me test:
1. Movement - press ArrowRight or D, then maybe fire and check.
2. Restart - press R, verify LIVES back to 3 and SCORE 0.

Let me wait a bit to see if lives drop again (to confirm enemy shooting), then restart with R.

Let me test movement with key action. Send 'd' or ArrowRight. Let me try 'd' (KeyD) and then 'ArrowRight'. 

Actually, the key action takes text. Let me send text 'd' to move right, and 'a' to move left, and ' ' (space) to fire.

But I'm not sure the harness translates 'd' to KeyD. Let me try. Actually, let me also try ArrowRight - but the text for an arrow is unclear.

Let me test firing: send space. And movement: send 'd'.

Let me first test restart with R since that's the key verification. Let me send 'r' and check LIVES goes to 3.

Actually, the game is currently at LIVES 3 (fresh). Let me let it run a moment to drop a life, then restart. But I can't control timing easily. Let me just test R restart now (resets to 3 anyway) and verify the HUD shows 0/3.

Let me send 'r'.

Actually, let me test movement and firing first since those are core. Let me send 'd' then check nothing breaks, then send space to fire.

Let me test a sequence. First, let me try moving and firing. I'll send keys and then inspect the DOM to see if it still runs without errors.

Let me send 'd' (move right).

Hmm, but I'm worried the harness might only set the keydown and the cannon moves a tiny bit then... it doesn't matter visually since I can't see. Let me verify via logic: movement code reads keys['KeyD'] or keys['ArrowRight']. If harness sends keydown with code 'KeyD', movement works.

Let me try sending keys and watch for JS errors in console. If no errors, the code is sound.

Let me test: send 'd', 'a', space (fire). Let me do a couple and inspect.

Actually, given I have ~4 minutes left, let me be efficient. Let me:
1. Send R to restart (verify HUD 0/3 - already is).
2. Send Space to fire (verify no error + bullet created).
3. Send 'd'/'a' or arrows to move (verify no error).
4. Let it run to confirm alien motion/shooting (LIVES changes), then restart.

The most valuable verification given constraints: confirm (a) no JS errors, (b) restart restores state, (c) enemies shoot and lives decrement, (d) firing works.

Let me send a few keys and inspect console + DOM.

Let me fire a bunch and move. Actually, to verify a shot hits an alien and score increases, I'd need to aim. The cannon is centered under column 5. If I fire repeatedly, eventually a player bullet goes straight up and hits the alien in column 5 (bottom row is row 4, but aliens start at top). Actually straight up from center hits the middle alien column. With 11 columns, center is column 5 (0-indexed) at x = 58 + 5*40 = 258, center of alien = 258 + 16 = 274. Cannon center = 275+25 = 300... wait cannon.x = 275, w=50, center = 300. Bullet x = cannon.x + 25 - 2 = 278? Let me recompute: bullet x = cannon.x + cannon.w/2 - 2 = 275 + 25 - 2 = 298. Alien column 5 at x=258, alien spans 258 to 290. Bullet at x=298-302. Alien column 5 right edge = 290. So bullet (298-302) does NOT overlap alien column 5 (258-290)! 

Hmm, the cannon is centered (275-325), bullet at 298. Aliens start at x=58. The center alien column: with 11 columns spacing 40, the middle (column 5) alien is at 58+5*40 = 258, spans 258-290. The cannon center is 300. So the cannon is offset to the right of the center alien column by ~10px. So a straight-up shot from cannon (x~298) misses the center alien column's right edge (290)!

Wait, that means the player can't hit the center column aliens shooting straight up? That's a problem. Let me recompute the alien layout.

alienStartX = 58, alienSpacing = 40, alienW = 32.
Alien column c center = 58 + c*40 + 16 = 74 + 40c.
Column 5 center = 74 + 200 = 274.
For the bullet (x≈298) to hit column 5 (x span 258-290), it doesn't (298 > 290).

But column 6 center = 74 + 240 = 314, span 298-330. Bullet x=298 is at the left edge of column 6. So a straight-up shot barely hits column 6's left edge. Hmm, marginal.

So the cannon (center 300) aligns roughly with column 5.5 (between col 5 ending at 290 and col 6 starting at 298). So straight up hits the boundary between column 5 and 6. Marginal.

This means aiming straight up is unreliable. The player must move left/right to shoot specific aliens. That's actually classic Space Invaders feel (you move to aim). But it might be frustrating that the default center shot misses most aliens.

Let me reconsider the alignment. Maybe I should center the alien grid so the middle aligns with the cannon. With 11 columns, the middle column is 5 (0-indexed). Its center x = alienStartX + 5*40 + 16. For this to equal cannon center (300): alienStartX = 300 - 5*40 - 16 = 300 - 200 - 16 = 84. So if I set alienStartX = 84, the center column (5) aligns with cannon center (300). Then a straight-up shot (x≈298) hits column 5 (span 84+200 to 84+200+32 = 284 to 316). Bullet 298 is within 284-316. 

Wait let me recompute with alienStartX=84: column 5 x = 84 + 5*40 = 484? No. Column c x = alienStartX + c*40. Column 5 x = 84 + 200 = 284, span 284-316. Center = 300. Bullet at 298. Yes, hits column 5. 

And the rightmost: column 10 x = 84 + 400 = 484, span 484-516. Within 600. Good. Leftmost column 0 at x=84, span 84-116. Good margins.

So let me change alienStartX from 58 to 84 to center-align the grid with the cannon. This makes straight-up shots hit the center column, which is more playable and classic.

Actually, the original Space Invaders has the player able to shoot all aliens by moving. Centered alignment is fine. Let me update alienStartX = 84.

Also, the alien bullets: when an alien fires straight down from column 5 (x center 300), the bullet is at x = alien.x + 16 - 3 = 300-3=297, goes down to cannon at y~640. Cannon x span 275-325, bullet x 297-303. Hits cannon center. That's why the early shot hit the cannon! Column 5 bottom-right alien firing straight down hits the centered cannon. Makes sense.

So with centered aliens, straight-up player shots hit center aliens, and straight-down enemy shots hit the cannon. That's the classic dynamic. Good. Let me update alienStartX = 84.

This is an essential fix for playability. Let me make it.

Given time constraints (~3-4 min), let me make this one edit and re-test.

Let me edit alienStartX.

Now let me reload and test. Let me test:
1. Firing - send Space, then watch HUD. But firing straight up from center should hit center aliens. After a few shots, score should increase.
2. Restart with R.

Let me reload, then fire several times (the aliens are moving; a straight shot up should hit the center column aliens over time as they descend/move). Actually the aliens move horizontally as a group. A straight-up shot from x≈298: with alienStartX=82, center column 5 spans 82+200=282 to 314. Bullet at 298-302. So hits column 5. As the group moves, column 5 moves too. When the group is moving rightward, at some point bullet x=298 is between aliens. Hmm.

Actually the aliens move as a group (all shift x together). So at any moment, column 5's span is [82 + offset + 200, ...+232] where offset is the group's accumulated x shift. The bullet at 298 hits column 5 when 82+offset+200 < 298 < 82+offset+232, i.e., offset in [82+200-298+... let me: need 282+offset < 298 < 314+offset → offset < 16 and offset > -16. So when group offset is within ±16px of start, straight-up hits column 5. Since the group oscillates back and forth over a ~50px range, the bullet will hit column 5 roughly half the time. Good enough.

Let me test by firing many times rapidly. With fire cooldown 0.24s, I can fire ~4 bullets/sec. Each straight-up bullet travels 450px/sec and lifetime 1.4s, reaching top in ~1.5s... actually canvas height 700, bullet from y=636 going up to y=-20, distance ~656px at 500px/s = 1.3s. So bullets are in flight a while. With 0.24s cooldown, multiple bullets can be in flight simultaneously, stacked vertically. They'd all be at x≈298. So a vertical "spread" of bullets at x=298 traveling up. When the group is in position, multiple bullets might hit multiple aliens in column 5 (at different y). Or they'd be destroyed one by one hitting the same column. 

This could clear column 5 quickly. That's fine for a test.

Let me reload and fire a bunch, then check score increases.

Let me reload first.

Good, fresh start. Now let me fire - send space several times. Let me send space a few times and then inspect to see if score changed.

One shot fired. Let me wait and fire a few more. The bullets travel up at 500px/s, taking ~1.3s to reach top. Aliens are at y~64-250. The bullet reaches alien y (~64) after (636-64)/500 = 1.14s. So I need to wait ~1.2s after firing for the bullet to hit. But the bullet is at x≈298 and needs the group aligned.

Let me fire several shots in succession (each 0.24s apart due to cooldown). Let me fire 5-6 times with delays. But the harness key action is instantaneous. Let me fire a few and then wait by doing other operations, then inspect.

Actually, let me fire a burst of spaces. But the fire cooldown means only one bullet per 0.24s. The harness sends keydown; my code checks `keys['Space']` each frame. But the harness might only send keydown, not keyup, so keys['Space'] stays true until... I never get keyup (harness may not send). Actually I should handle: if keys['Space'] is true continuously, my code fires every 0.24s as long as Space is held. So sending keydown once = Space held = auto-fire every 0.24s. So one ' ' press = continuous firing. Good.

So a single space keydown starts auto-firing. After ~1.3s, bullets start hitting aliens and score increases. Let me wait a moment and inspect.

Let me do a couple more actions to let time pass, then inspect. Let me move right a bit and then inspect.

Actually, the game loop runs continuously regardless of my inputs (it's requestAnimationFrame). So time passes as I do nothing. Let me just inspect after a brief delay. But each browser action is a separate call. Let me send another key (like move) and then inspect to see accumulated score.

Let me fire and move, then inspect.

Actually, I already fired (space held = autofire). Let me just inspect now after some real time passed (the reload + key call took some time). Let me inspect.

Score is still 0. The autofire should have fired multiple bullets by now. Maybe keys['Space'] isn't being set because the harness ' ' (space) keydown might set e.code='Space' (which I handle) — that should work. But maybe the harness doesn't hold the key; maybe each key action is a one-shot press without sustained key state, OR the keydown isn't registering.

Wait — there's a concern: my keydown listener checks `if (e.code === 'Space') e.preventDefault()`. If the harness sends the event with a different code, keys['Space'] might not be set. Or maybe the event is being sent but the game's update reads keys correctly.

Actually, the DOM shows LIVES stayed 3 — meaning no enemy bullet hit the cannon. Earlier (before fixes), it dropped to 2, confirming enemy shooting works. But now it's 3 (fresh restart). So in this fresh game, no enemy shot has hit yet (~2s elapsed). 

And score is still 0 — meaning no alien was hit yet. That's suspicious if autofire happened. Either:
(a) The space keydown didn't register (no firing), or
(b) Bullets fired but didn't hit aliens (alignment issue), or
(c) Not enough time elapsed.

The reload just happened, and I did one key press (space) then 'd'. The total wall-clock time between reload and now is maybe ~2-4 seconds. A bullet fired at t=0 reaches aliens at t=~1.2s. If multiple bullets fired (autofire every 0.24s), by t=2s there'd be ~8 bullets in flight. Some should hit.

But score is 0. Possibilities:
- Space didn't register as a held key. Maybe the harness sends keydown+keyup quickly, so keys['Space'] is true for only one frame, firing one bullet. That one bullet travels up; at ~1.2s it could hit. But only ~2-3s elapsed since reload. The single bullet should have reached aliens by now (1.2s) if the group was aligned. But the group moves; the bullet at x≈298 needs the group within ±16px offset. The group moves at ~24px/s initially, so in 1.2s it moved ~29px, possibly out of alignment. Marginal.

- Maybe the bullet fired but missed because of alignment. Let me reconsider: with alienStartX=82, center column 5 spans 282-314. Bullet x = cannon.x + 25 - 2 = (300) + 25 - 2 = 323?? Wait, cannon.x after my move: cannon started at W/2 - 25 = 275. I pressed 'd' (move right). So cannon moved right a bit, say to ~285. Then bullet x = 285 + 25 - 2 = 308. Column 5 span 282-314. 308 is within. So should hit.

Hmm wait, but I moved right BEFORE firing? No — order was: reload (fresh), then space (fire), then 'd' (move right). So firing happened first while cannon was centered at 275. Bullet x = 275 + 25 - 2 = 298. Column 5 span 282-314 (if group at offset 0). 298 within → should hit.

But group might have moved. At t=0, group at offset 0, moving right at 24px/s. At t=1.2s, offset = ~29px. Column 5 span = 282+29 to 314+29 = 311-343. Bullet at 298. 298 < 311. Missed! The group moved right ~29px in 1.2s, so column 5 moved to 311-343, and the bullet (298) is now to the left of it. Miss.

So the bullet fired at t=0 arrives at y=64 at t=1.2s, but by then the group moved right 29px, so the aligned shot misses. The alignment was only good at the instant of firing.

This means a single straight-up shot is unlikely to hit unless fired exactly when the group is positioned. With auto-fire producing multiple bullets at x≈298 (all same x, stacked vertically), they all arrive at different times but same x=298. As the group oscillates (moves right then reverses at wall, moves left), at some point column 5's x passes through 298. When group offset is ~-16 to +16 relative, the bullet at 298 hits column 5.

The group moves back and forth between walls (x from ~82 to ~268 range for column 5 center, i.e., offset from -16 to ... wait the reversal happens at walls). Column 5 center ranges from 82+200=282 to ... when group reverses at right wall, column 5 is near 282-314? No. Let me think: the group moves right until maxX (rightmost alien, column 10) hits the wall at 600-12=588. Column 10 right edge = 82 + 10*40 + 32 + offset = 514 + offset. Wait column 10 x = 82 + 10*40 = 482, right edge = 514. For right edge + offset = 588 → offset = 74. So group moves right by up to 74px before reversing. So column 5 center ranges from 300 (offset 0) to 300+74 = 374 (offset 74) on the right, and down to 300-... on left. Actually the group oscillates between offset 0 and max right, then reverses and goes left. 

Hmm, actually the group starts at offset 0 moving right. It reverses at +74, then moves left, passes through 0, reaches the left wall where minX (column 0 left edge) = 82+offset hits 12 → offset = -70. So column 5 center ranges 300-70=230 to 300+74=374. The bullet at x=298 (cannon centered). Column 5 spans [282+offset, 314+offset] for offset in [-70, 74]. The bullet x=298 hits column 5 when 282+offset <= 298 <= 314+offset → offset in [298-314, 298-282] = [-16, 16]. So when the group offset is between -16 and +16, a bullet at x=298 hits column 5. The group spends a portion of its cycle in that range.

With auto-fire every 0.24s producing bullets at x=298, and the group moving at 24-110px/s... Initially 24px/s, the group takes a while to traverse. Over a few seconds, several bullets at x=298 are in flight. As the group's column 5 passes through x=298 range, bullets hit. 

But in the ~3s elapsed, did the group pass through offset 0 to ... it started at offset 0 going right. So at t=0, offset=0 → bullet at 298 is perfectly aligned (282-314 contains 298)! The FIRST bullet fired at t=0 should hit column 5 if it arrives while offset is still ~0. The bullet arrives at y=64 (top alien row) at t = (636-64)/500 = 1.14s. At t=1.14s, offset = 24*1.14 = 27px. Column 5 span = 282+27 to 314+27 = 309-341. Bullet x=298. 298 < 309. Missed by 11px. Argh, so close.

The top-row aliens are at y=64. The bullet reaches y=64 at t=1.14s, but by then the group moved 27px right, shifting column 5 to 309+. The bullet (298) misses.

But the bullet continues past y=64 upward and exits, missing. So the top alien is missed. What about lower rows? The bullet is at x=298 throughout. Column 5 aliens at y=64,104,144,...,244. All shifted right by 27px at t=1.14s, so all column 5 aliens are at 309+. Bullet at 298 misses all of column 5.

So the single center shot misses because the group moved. The bullet would need to hit a different column. At t=1.14s, bullet at x=298. Which column alien is at x=298? Column 5 span 309-341 (no). Column 4 x = 82+160=242, span 242+27=269 to 274+27=301. Wait column 4 span = [242+27, 274+27] = [269, 301]. Bullet 298 is within 269-301! So bullet at 298 hits column 4 at t=1.14s, IF column 4 alien is still at y where bullet is.

The bullet at t=1.14s is at y=64. Column 4 row 0 alien is at y=64. So the bullet hits column 4, row 0 at t=1.14s! Score should increase.

Hmm, so why is score still 0? Let me reconsider. Maybe the bullet didn't fire at all, or the timing/alignment is off, or there's a bug.

Wait, maybe the issue is the bullet's x. Let me recompute cannon.x at fire time. After reload, cannon.x = 275. Bullet x = cannon.x + cannon.w/2 - 2 = 275 + 25 - 2 = 298. Yes.

Maybe the space key didn't register. Let me reconsider: the harness 'key' action with text=' '. Does it produce a keyboard event with code 'Space'? Possibly. But maybe it produces key=' ' with code undefined, or it's a different event type. If e.code isn't 'Space', then `keys[e.code]=true` sets keys[undefined]=true, and `e.code==='Space'` is false so no preventDefault. But keys['Space'] never gets set → no firing. And the R restart I did earlier... wait, did R work? Earlier when I sent 'r', lives stayed 2 (didn't reset to 3), then after my fix I reloaded and it showed 3 (fresh reload, not from R). So I haven't actually confirmed R works either!

Hmm. So the key action may not be registering properly with my e.code-based handlers. 

Let me reconsider how the harness sends keys. The 'key' action takes a `text` parameter (the text to type). It likely fires keydown, keypress (deprecated), and keyup events with key/text properties. For 'r', e.key='r', e.code='KeyR' (browsers set code from key). For ' ', e.key=' ', e.code='Space'.

So e.code should be set. Then my handler sets keys['Space']=true. Firing should happen.

But maybe the harness sends keydown AND keyup in quick succession (a full keypress cycle), so keys['Space'] is true for only one animation frame. In that one frame, fireCd might be >0? No, initially fireCd=0. So on the first frame with keys['Space']=true, it fires, sets fireCd=0.22. Then keyup sets keys['Space']=false. So only ONE bullet fires. That bullet at x=298, fired at t=0. As computed, it might hit column 4 row 0 at t=1.14s (if aligned). 

But score is 0. So either the bullet didn't hit, or didn't fire, or my timing/alignment analysis is off.

Let me reconsider the timing. After reload, the game starts. The first update has secs = small. gameTime starts accumulating. The space key I sent — when did it fire relative to the reload? The reload starts the loop. Then I call key action ' '. There's some delay (network/harness) before the key event reaches the page, maybe ~0.5-1s after reload. So the bullet fires at t≈0.7-1.0s (game time), not t=0. By then the group has moved. And the bullet then takes 1.14s to reach top. Total t≈1.8-2.1s. The group at that time has moved further. Hard to predict hits.

This is getting too deep. The core issue: verifying a hit via console/DOM is timing-sensitive and the harness key events are unpredictable.

Let me step back and focus on what I can verify reliably and what's essential:

1. No JS errors — confirmed (only the sandbox warning).
2. Game renders — confirmed (canvas present, runs).
3. Restart works — not yet confirmed via R. Let me test R restart and verify HUD resets.
4. Enemy shooting reduces lives — confirmed earlier (LIVES went 3→2 on first reload before fixes).
5. Player can fire — hard to confirm score change via timing.

Let me prioritize confirming: (a) R restart resets to 0/3, (b) movement doesn't error, (c) the game reaches a win/gameover eventually and restart restores.

For (a), let me trigger a game over more reliably. Actually, I can verify restart by letting lives drop to 0 (game over) then pressing R → should reset to 3. But waiting for that is slow.

Alternatively, since I made R restart *anytime* (including during play), let me just press R now (lives is 3, score 0) and confirm it stays 0/3 (reset). That confirms R resets state. But it's already 0/3, so I can't distinguish "reset" from "no change."

Better: let some game state change (lives drop or score rise), then R, then check it returns to 0/3.

The cleanest: let the game run without input until an enemy bullet drops a life (we saw this happen: 3→2). Then press R and confirm lives→3, score→0.

But I can't control the timing. Let me just wait by doing redundant inspect calls, then when lives < 3, press R and verify it resets to 3.

Actually, let me reconsider the autofire. Let me check if Space registers by testing: the score is still 0 AND lives is 3 after my space+'d' inputs. If Space had fired bullets that hit aliens, score>0. If bullets hit column 4 etc., score>0. So possibly no bullets fired (Space didn't register) OR bullets fired but missed everything.

Let me try a different approach to verify firing: I'll rely on logic. Actually, let me just trust the code is correct (no errors, logic sound) and verify restart, which is the explicit task check.

Let me wait for a life to drop (enemy shot), then R to restart, verify 0/3.

Let me do an inspect now to see current state.

Actually, I've spent a lot of reasoning. Let me be pragmatic with remaining time (~3 min):

Plan:
1. Inspect now — see if lives/score changed (some time passed).
2. If lives dropped, press R, verify resets to 0/3. (confirms restart)
3. If score>0, confirms firing/hitting aliens works.
4. Also do a movement test: move left/right — but no visible HUD change, can only confirm no errors.

Let me inspect now.

Now LIVES: 0 — the game reached game over (zero lives). Enemy bullets hit the cannon 3 times (each costing a life with 2s invincibility between, but the invincibility prevents rapid repeated damage — however 3 hits over time). Wait, invincibility is 2s. For lives to reach 0, there must have been 3 separate hits spaced >2s apart. The game ran long enough (I've been doing multiple actions over a minute or so). So the game went: 3→2→1→0, with 2s protection between each. That took at least ~6s+ of game time plus bullet travel. 

Actually wait — the state should now be 'gameover' (lives <= 0). And the RESTART button — the draw function sets `restartBtn.style.display = 'inline-block'` always now. And the message overlay should show "GAME OVER". 

Now LIVES: 0, SCORE: 0. So no alien was hit (score 0), meaning my spacebar firing either didn't register or bullets missed. Hmm. But the gameover happened. 

Wait, but actually if the game is now in 'gameover' state, the message overlay "GAME OVER" should appear. The DOM text wouldn't show the canvas overlay text (it's canvas-drawn, not DOM text). So DOM only shows the HUD: SCORE 0, LIVES 0.

Now, the fact that score is 0 despite my firing attempts is concerning — it suggests Space didn't fire bullets, OR bullets fired but never hit aliens. Let me reconsider.

Actually, maybe Space DID fire but the bullets all went straight up at x≈298 and either missed or got destroyed by the bunkers. Remember the bunkers are at y=490, between cannon (640) and aliens (64-250). A straight-up bullet at x=298 passes through the bunker region at y~490. Bunkers are at x positions: 72, 204, 336, 468 (centers of bunker i). With bw=60: bunker 1 spans 72-132, bunker 2 spans 204-264, bunker 3 spans 336-396, bunker 4 spans 468-528. A bullet at x=298: bunker 2 ends at 264, bunker 3 starts at 336. 298 is in the gap (264-336). So bullet passes through the gap. Good. So bunkers don't block straight-up center shots. The bullet reaches aliens.

So if bullets fired, they should hit aliens (column 4/5) as computed. But score is 0. So bullets likely didn't fire = Space didn't register.

Why didn't Space register? Let me reconsider the harness. The 'key' action: maybe it only fires the event but my preventDefault or something interferes? No. 

Or maybe: the harness 'key' sends a keydown event, but after my reload, the page's JS might not have the listeners attached yet when the key event fires? No, I sent space AFTER reload+inspect cycles, so listeners are attached.

Hmm, wait. Actually, maybe the harness fires the key event on a different element or with a delay, and by the time it arrives, the game is in a state... no, it was 'playing' the whole time until lives hit 0.

Actually, maybe the issue: I sent ' ' (space) ONCE, the harness fired keydown+keyup (one press). My code: on the keydown frame, fireCd=0 so it fires ONE bullet. That bullet travels up. By the time it reaches aliens (~1.14s after firing), did the alignment allow a hit?

Let me recompute more carefully with realistic timing. Let me assume the space keydown arrived at gameTime t_f (unknown, maybe ~0.5-1.5s after reload). The bullet x = 298 (cannon centered, I hadn't moved yet when I fired space — the 'd' came after). 

The bullet travels up from y=636. It reaches the alien region. The aliens move. Let me compute where column c is horizontally as a function of gameTime.

This is too uncertain. Let me instead just directly test firing more aggressively and see if score changes. But actually, maybe the real issue is the alignment makes center shots largely miss, and the player needs to MOVE to aim. The task says "Check alien motion and inspect a shot hitting a bunker or alien for visible damage or score feedback." 

The verification expects me to confirm a shot hits an alien (score feedback) OR hits a bunker (visible damage). Given the difficulty of hitting a moving alien with a single center shot, hitting a bunker is more reliable. If I move the cannon to aim at a bunker and fire, the bullet should hit the bunker and damage it. But again, only works if Space registers.

The bigger concern: does Space register at all? Score=0 and lives=0 suggests no alien was ever hit by my shots. But enemy bullets DID hit (lives dropped), proving enemy bullets work. Player bullets might not have fired.

Let me test Space registration definitively. Let me restart (R) to get fresh 3/0, then fire a SINGLE space and immediately inspect a few times over ~2s to see if score ever increments. If it never does, Space isn't registering and I have a bug.

Actually, a cleaner test: I can make the game more lenient — but I shouldn't change game logic just for testing. 

Wait — maybe the problem is that `e.preventDefault()` on the Space keydown, combined with how the harness dispatches, prevents the keys['Space'] from being set? No, preventDefault is after I set keys. Order in my handler: `if (e.code==='Space') e.preventDefault(); keys[e.code]=true;`. So keys['Space'] is set BEFORE or regardless of preventDefault. preventDefault just stops the default scroll. keys['Space']=true happens. So on the update frame after, it should fire.

Unless... the harness dispatches the event and the event's e.code is NOT 'Space'. For a space character, the KeyboardEvent code is 'Space'. But if the harness synthesizes events with only `key` set and code derived differently... 

Let me make the handler more robust by also checking e.key === ' ' (space) and the character. Let me update the firing check and the key storage to handle both code and key.

Actually, the cleanest fix: store keys by BOTH code and a normalized key. But my update() checks `keys['Space']`, `keys['ArrowLeft']`, `keys['KeyA']` etc. (codes). If the harness sets keys[e.code] where e.code is undefined (only e.key set), then keys['Space'] is never true.

Let me make the keydown handler store both:
```js
keys[e.code] = true;
keys[e.key] = true;   // store by key too
```
And update checks could use either. But I'd need to also check ' ' (space char), 'ArrowLeft', etc. by key. Mixed.

Simplest robust approach: in update, check multiple representations. But that's messy.

Alternative: Let me check what the harness actually sends. Let me add a temporary console.log of e.code and e.key on keydown, then inspect the console. That will tell me exactly what event the harness produces.

Let me add a debug log temporarily. Actually, I have limited time. Let me just make the input handling robust by storing keys under both code and key, and checking both forms. 

Actually, the cleanest: store `keys[e.code] = true` AND `keys[e.key] = true`. Then in update, the existing checks (`keys['Space']`, `keys['ArrowLeft']`, `keys['KeyA']`, `keys['KeyD']`) work IF e.code is set. If only e.key is set (e.key=' ', e.code undefined), then `keys[e.key]` = keys[' ']=true, and `keys[e.code]`=keys['undefined']=true. My update checks `keys['Space']` — that won't match keys[' ']. 

So I should also handle e.key=' ' for space and e.key='ArrowLeft' etc. for arrows, and e.key='a'/'d'.

Hmm. Let me just normalize: store keys under e.code primarily. To be safe, also store under a lowercase key. Let me think about what's most likely.

Actually, the fact that LIVES dropped to 0 means enemy bullets hit the cannon — but that's the GAME shooting (alienFire uses Math.random, not input). So enemy shooting works independent of my key inputs. The player-firing (Space) is the only thing requiring input. And also movement (key inputs) — but I can't see movement effect in HUD.

So the untested-with-input behaviors are: player movement and player firing. Both depend on keys.

Given the harness DID deliver 'r' to trigger something? Wait, did R work? After my fix (R restarts anytime), I sent 'r' earlier? No — I reloaded (fresh) after the fix, then sent space, then 'd', then inspect. I did NOT test R after the fix. The lives went 3→0 via enemy bullets over the elapsed real time (~1+ minute of back-and-forth).

So I have NOT confirmed R restart works, nor Space fire, nor movement. The only confirmed input-independent behaviors: rendering, alien movement, enemy shooting, lives/score display.

This is a problem for verification. Let me add a robust key normalization and a temporary debug log to confirm what the harness sends, then re-test.

Let me modify the keydown handler to log e.code and e.key, and store keys under both. Then reload, send a key, and read the console log.

Let me do this. Time is ~2-3 min.

Let me edit the keydown handler:
```js
window.addEventListener('keydown', (e) => {
  console.log('key:', e.key, 'code:', e.code);
  if (e.code === 'Space' || e.key === ' ') e.preventDefault();
  keys[e.code] = true;
  keys[e.key] = true;
  if ((e.code === 'KeyR' || e.key === 'r' || e.key === 'R') && !e.repeat) {
    e.preventDefault();
    resetGame();
  }
});
window.addEventListener('keyup', (e) => { keys[e.code] = false; keys[e.key] = false; });
```

And update the firing/movement checks to also accept the key-based forms. Since I now store both, and update checks keys['Space'], if e.code='Space' then keys['Space']=true. If e.code is undefined but e.key=' ', then keys[' ']=true but not keys['Space']. So I need update to check `keys['Space'] || keys[' ']`.

This is getting messy. Let me normalize input into a clean set of boolean flags instead of a generic keys object. Let me define:
```js
const input = { left:false, right:false, fire:false, restart:false };
```
And in keydown, set these based on e.code OR e.key:
```js
function isLeft(e){ return e.code==='ArrowLeft'||e.code==='KeyA'||e.key==='ArrowLeft'||e.key==='a'||e.key==='A'; }
function isRight(e){ return e.code==='ArrowRight'||e.code==='KeyD'||e.key==='ArrowRight'||e.key==='d'||e.key==='D'; }
function isFire(e){ return e.code==='Space'||e.key===' '||e.key==='Space'; }
function isRestart(e){ return e.code==='KeyR'||e.key==='r'||e.key==='R'; }
```

Then keydown sets input flags, keyup clears. This is robust to whatever the harness sends.

Let me rewrite the input section with this approach. It's cleaner and more robust. Let me do it.

Then in update, check input.left, input.right, input.fire.

Let me rewrite. Given time, let me do a focused edit of the input block and the update input checks.

Let me view the current input + update input lines.

Actually, let me just rewrite the whole script portion via a careful edit. But that's risky with time. Let me do targeted edits:

Edit 1: Replace the input block (key listeners + input state).
Edit 2: Replace the cannon movement + firing input checks in update.

Let me read the current input block to get exact text.

Let me replace the input block with a robust input system. Let me write the new input block.

Now update the update() function to use the `input` object instead of `keys`. Let me find and replace the cannon movement and firing checks.

Now let me reload and test. First, let me reload to get fresh state and see the console log of what key events arrive. Then send space and check.

Let me reload and inspect console.

Actually, the game will be running again. Let me reload, then immediately send a space, then inspect to see the console.log of the keydown AND whether score increases.

But the game auto-runs and enemy bullets will eventually drop lives. Let me reload, then send space once, then inspect (to see console log of the keydown). Then I'll know how the harness dispatches keys.

Let me reload.

There's an error: "keys is not defined". I replaced `keys` with `input`, but somewhere I still reference `keys`. Let me find remaining references to `keys`.

In resetGame I have `for (const k in keys) keys[k] = false;`. That references `keys` which no longer exists. Let me fix that to use `input`.

Let me grep for `keys` references.

Typo - I accidentally put a `>` in the parameter name. Let me redo correctly.

Good - no errors now. Fresh game: SCORE 0, LIVES 3. Now let me fire (send space) and then inspect to see the console.log of the keydown event. This will tell me what e.key and e.code the harness sends.

The console log shows: KEYDOWN {"key":" ","code":"Space"}. So the harness DOES send e.code='Space' and e.key=' '. So Space registers. And the `isFire` function returns true for e.code==='Space'. So input.fire=true. The bullet should fire.

But wait — LIVES dropped to 2 after this single space press! That means... an enemy bullet hit the cannon. But I only pressed space (fire). The lives dropping means enemy bullets are hitting. 

But also SCORE is still 0. So the player bullet fired (Space registered, input.fire=true) but didn't hit an alien (score 0), while an enemy bullet hit the cannon (lives 3→2).

Wait, but the life drop to 2 — is that from THIS space press event, or accumulated over time? The reload happened, then immediately I sent space. The time between reload and the space key event is short (~1s). An enemy bullet takes 0.7-1.2s to fire (alienFireTimer) plus ~2.3s to travel to cannon. So an enemy bullet couldn't have reached the cannon in ~1s after reload. Unless the fire timer fired at t≈0 (immediate) and traveled 2.3s. So total ~2.3s minimum for a hit. 

Hmm, but lives is now 2, meaning a hit occurred. The real-world time between reload and this inspect might be more than I think (the harness calls have latency). Could be ~3-5s of game time elapsed. So an enemy bullet fired at t~0.5s arrived at ~2.8s, hitting the cannon. The invincibility (2s) then protected until ~4.8s. So only ONE hit by now (lives 2). That's consistent.

But wait — there's another possibility: did my space key press ALSO somehow register in a way that caused the life drop? No, space only fires player bullets (which go UP). Can't cause life loss. So the life drop is from an enemy bullet. Confirmed enemy bullets work.

Now, SCORE=0 after firing. The player bullet fired but didn't hit an alien. Why? As I analyzed, the single center shot largely misses due to group movement. With only ONE bullet fired (the harness sent one keydown, and `!e.repeat` means... wait, my handler sets input.fire=true on keydown. It doesn't auto-repeat because the harness sends a single keydown. But does the harness send a keyup? If not, input.fire stays true and the game auto-fires every 0.22s!

Let me check: the console only logged ONE KEYDOWN. If the harness sends keydown only (no keyup), input.fire would stay true (held), and the game would auto-fire every 0.22s. Over ~3-5s that's ~15 bullets. Those bullets at x=298 would likely hit SOMETHING. But score is 0. 

Hmm, unless the bullets all miss or get absorbed. Let me reconsider. If auto-firing ~15 bullets at x=298 over several seconds, as the group oscillates left-right, some bullets should hit column 4/5 aliens. Unless... the bullets are being destroyed by the bunkers. The bullet at x=298 in the bunker gap (bunker 2 ends 264, bunker 3 starts 336) — 298 is in the gap. So no bunker hit. Bullets reach aliens. 

Wait, unless the cannon moved. I haven't moved the cannon (no arrow/D press). So cannon stays centered, bullets at x=298. 

So 15 bullets at x=298 traveling up. As the group moves, column 4 (span [269+offset, 301+offset]) and column 5 (span [282+offset, 314+offset]) pass through x=298. At offset where column 5 is at 282-314, bullet 298 hits. The group oscillates offset from -70 to +74 (and back). So column 5 spans x from 212 to 388. x=298 is within column 5's span whenever offset ∈ [-16, +16] (i.e., span [282+offset,314+offset] contains 298). The group passes through this range. So bullets should hit.

But maybe the bullets fired BEFORE the group entered the aligned range, and the bullets travel up and miss, and the harness stopped sending (single keydown, no keyup) so... no wait, if input.fire stays true (no keyup), it auto-fires continuously. So bullets keep firing. As the group oscillates, eventually bullets hit. Over ~5s, definitely some hits. Score should be >0.

Unless input.fire is NOT staying true. Maybe the harness sends keyup shortly after keydown. Then only ONE bullet fires (on the keydown frame, since input.fire=true for one frame, then keyup sets false). One bullet, likely misses due to group movement. Score stays 0.

The console logged only the keydown (my log fires on `!e.repeat` keydown). If there were a keyup, it doesn't log. So I can't tell from logs whether keyup was sent.

Given score=0, it's plausible only one bullet fired and missed. OR multiple fired but all missed.

Either way, the player-firing MECHANISM works (Space registered, input.fire set). The issue is just that hitting a moving alien with a single center shot is unreliable. To reliably demonstrate a hit, I should MOVE the cannon to track/aim.

Let me test: move left/right to aim at aliens, fire, and check score. But movement requires the arrow keys or A/D to register. Let me test movement + firing together.

Actually, a more reliable way to hit an alien: the cannon is centered. The aliens move as a group oscillating. If I don't move, the bullets are at fixed x=298. Let me just fire MANY bullets (hold space / send many spaces) and wait for the group to oscillate into alignment. 

But each harness key call = one keydown. If I send space multiple times, I get multiple keydowns (each firing one bullet if fireCd ready). With 0.22s cooldown, sending space rapidly via multiple calls (each ~1s apart) gives ~1 bullet per 1s. Over 5s, ~5 bullets. Still may miss.

Alternatively, move the cannon to align with aliens. Let me move right (D) so cannon shifts right, bullet x increases to align with a column. 

Honestly, the cleanest verification of "shot hitting alien → score feedback": let the game run longer with continuous firing until score rises. But that requires input.fire to stay true (auto-fire) OR many key presses.

Let me try: send space, then send 'd' a few times (move right), space, 'a', etc. Actually, let me just send a burst and wait, then inspect score. If score eventually rises, firing+hit+sCore works.

Actually, here's a thought: the bullet-bullet collision and bunker interaction. Let me instead verify the BUNKER damage, which is easier: move the cannon to aim at a bunker and fire. A bunker is large (60px wide). If I move the cannon right so the shot goes through a bunker, it'll damage it. But bunker damage isn't reflected in HUD (no visible change in DOM). I can't see the canvas. So bunker damage isn't verifiable via DOM.

The only HUD-observable outcomes are score (increasing) and lives (decreasing). Lives already works (enemy hits). Score requires hitting aliens.

So to verify score feedback, I MUST get a player bullet to hit an alien. Let me try harder: send multiple space keydowns (each fires one bullet if cooldown elapsed) and move the cannon to track. 

Actually, the simplest reliable method: keep firing continuously. If the harness sends keyup quickly (input.fire false after one frame), I need repeated space presses. Let me send several space keydowns with time gaps (the harness call latency provides gaps ~1s each). Each fires one bullet (if cooldown 0.22s elapsed — yes since gaps are ~1s). So ~1 bullet per second, at x=298 (if not moving).

To hit, I should move the cannon so bullets aim at a specific alien column. Let me compute: to hit column 5 aliens (centered at x=300+offset), I want bullet x to match. Bullet x = cannon.x + 25 - 2 = cannon.x + 23. For bullet to hit column 5 (span 282+offset to 314+offset), set cannon.x+23 ∈ [282+offset, 314+offset]. 

This is dynamic. Hard to aim with discrete inputs.

Alternative: Let me just send a LOT of space presses and let random alignment happen. Or, better: let me reduce the fire cooldown issue by checking if input.fire stays held.

Actually, let me reconsider — maybe the harness keeps the key held (keydown, then keyup on next action or never). If keyup is never sent during my sequence, input.fire stays true = auto-fire. Then many bullets fire. Let me test this hypothesis: send ONE space (already did), and the console logged one KEYDOWN. If auto-fire were happening, the game would fire many bullets. Over the next ~5s (doing other actions), if auto-fire is on, score should rise. Currently after the space press + one inspect, score=0, lives=2. Let me do another action (wait) and inspect again — if auto-fire is on, score may rise.

But I already spent a key action. Let me just inspect again now (time passes) and see if score rose (indicating auto-fire works and bullets are hitting).

Let me inspect.

Actually wait, I want to be efficient. Let me do this: I'll verify by a more controlled approach. Let me check whether input.fire persists. Let me send space once, then WITHOUT sending keyup, wait ~4s (via another key action that takes time, or just inspect), then check score. If score rises, auto-fire confirmed and hits happen.

Hmm, but if the harness auto-sends keyup, only one bullet fires.

Let me just try: send space, then inspect after a delay (send an innocuous key or just inspect). Let me send 'd' (move) then inspect, checking score.

Actually, let me reconsider the whole testing strategy given time (~2 min left). 

The game is essentially working:
- Renders (canvas + HUD). ✓
- No JS errors. ✓
- Alien grid, bunkers, cannon all initialized. ✓
- Alien movement (group, reversal, descent) — verified indirectly (game runs, aliens exist). 
- Enemy shooting & hit detection & lives & invincibility — VERIFIED (lives 3→0 across hits, with protection).
- Player firing mechanism — Space registers (logged). 
- Score feedback on alien hit — NOT YET confirmed (score 0).
- Restart — NOT YET confirmed via R/button.
- Bunker damage — logic present, not visually verified.

Remaining essential verification: (1) a player shot hitting an alien → score, (2) Restart restoring state.

For (2): let me press R now (lives=2, score=0) and verify it resets to 3/0. That confirms restart (even though already going to reset lives up). Actually after R, lives should go 2→3, score 0→0. The lives change (2→3) confirms restart reset lives. Let me do that.

For (1): harder. Let me try to get a hit. Idea: send many space keydowns. Each fires a bullet if cooldown ready. Let me send space ~6 times (with the natural ~1s harness latency between calls), giving ~6 bullets over ~6s. With auto-fire possibly on (if no keyup), even more. Some should hit as the group oscillates.

Actually, even simpler and VERY reliable: the aliens in the center columns will be hit if I fire a burst while the group is near center. But I can't control timing precisely.

Let me try a different reliable hit: instead of relying on the oscillating group, let me confirm that bullets DO travel and DO collide. Since enemy bullets collide with the cannon (verified), the collision system works. The player bullet uses the same rectOverlap against aliens. The alien drawing and positions are correct. So a player bullet WILL hit an alien if it reaches one. The issue is just getting the shot to intersect a moving alien.

Let me just fire a sustained burst and check score. Let me send space multiple times, with inspects between to watch score.

Given ~2 min, let me:
1. Send R (restart) — verify lives 2→3 (reset). [confirms restart]
2. Send space a few times over waiting — watch score. [confirms firing + hit + score]

Let me do R first.

Wait, but if I press R, it resets to fresh (lives 3, aliens full). Then the group is at start, moving. If I then fire, I might hit. Let me do R then immediately fire a burst.

Let me send R now.

Actually, the current state is lives=2 (gameover not reached, since lives=2 >0, state still 'playing'). R should restart. Let me press R and verify lives→3, score→0, aliens full.

Let me send 'r'.

Restart works! After pressing 'r': SCORE 0, LIVES 3. The lives went from 2 to 3 (reset). And the console shows KEYDOWN {"key":"r","code":"KeyR"} → resetGame fired, restoring initial state (3 lives, 0 score, fresh alien grid, full bunkers, centered cannon).

So Restart is confirmed working — restores aliens, bunkers, score, lives, player position. ✓

Now I need to confirm a player shot hitting an alien → score feedback. Let me fire a burst. The group just restarted, moving right from center. A center shot at x=298 should hit column 5 when the group is near offset 0. Right after restart, offset=0, so column 5 spans 282-314, bullet at 298 hits. But the bullet takes 1.14s to reach the top, by which time offset≈27 (group moved right). As computed, bullet at 298 then hits column 4 (span 269-301 at offset 27). So the FIRST bullet after restart should hit column 4 row 0 at ~t=1.14s. 

So if I fire one space now and wait ~1.3s, score should become 10 (or 20 for row 0... row 0 = [30,20,20,10,10], row 0 = 30). Wait, my scoring: `const pts = [30, 20, 20, 10, 10][Math.min(a.row, 4)];`. So row 0 (top) = 30 points. Hitting a top alien = +30. Score 30.

Let me fire space and wait, then inspect for score change. But I need to make sure input.fire fires bullets. If the harness sends keyup quickly, only 1 bullet. Let me fire one, wait ~1.5s, inspect.

But the timing: after the R keyup, the harness latency. The R keydown arrived at gameTime ~t_R. The game continued. Now if I send space, it fires a bullet at x=298 (cannon centered, since restart centered it and I haven't moved). That bullet should hit column 4/5 within ~1.2s. 

But the group is also moving and might have reached a wall and reversed. Right after restart, group at offset 0 moving right at 24px/s (speed increases with kills, but few kills so ~24-40px/s). In 1.2s, offset ≈ 30-48px. At offset 48, column 5 span = 282+48=330 to 314+48=362. Bullet 298 < 330, misses column 5. Column 4 span = 269+48=317 to 301+48=349. Bullet 298 < 317, misses column 4. Column 3 span = 82+... column 3 x = 58+... wait alienStartX=82. Column 3 x = 82+3*40=202, span 202-234, +48 offset = 250-282. Bullet 298 > 282, misses. Hmm, so at offset 48, bullet 298 falls in the GAP between column 3 (ends 282) and column 4 (starts 317). Misses!

At offset 0: column 4 span 269-301, bullet 298 hits (within 269-301). 
At offset 27: column 4 span 296-328, bullet 298 hits (within 296-328). Wait 298 > 296 and < 328. Yes hits! 
At offset 48: column 4 span 317-349, bullet 298 misses (298<317).

So the bullet at x=298 hits column 4 (or column 5) when offset ∈ some range around 0-30. The bullet arrives at t=1.14s, offset at that time = 24*1.14 + accel contributions. If offset > 30 at arrival, misses.

The exact hit depends on timing alignment. It's marginal. To be safe, let me fire MULTIPLE bullets over a couple seconds so that as the group oscillates, one aligns.

Better idea: I should MOVE the cannon to aim. If I move the cannon right while firing, I can track a column. But that's finicky with discrete inputs.

Actually, the MOST reliable way to hit an alien with minimal fuss: the group oscillates between walls. Over a few seconds it passes through the aligned range multiple times. If I fire continuously (auto-fire on if key held), bullets at x=298 will hit whenever the group is aligned. So continuous firing + waiting ~3-4s should produce hits.

The question is whether the harness holds the key (input.fire stays true). Let me test by sending space and then waiting and inspecting — if score rises over time, auto-fire is working.

Let me send space, then do a couple of inspect calls (time passes ~2s each), watching score.

Let me send space now (fresh after R, cannon centered).

Hmm, lives dropped to 2 again (enemy bullet hit during the elapsed time). Score still 0. 

The space keydown was logged. But I can't tell if input.fire persisted (auto-fire) or was a single press. Score=0 suggests either single bullet that missed, or the bullets all missed.

Let me wait longer and inspect again to see if score rises (if auto-fire is on, more bullets fire and some hit as the group oscillates). Let me inspect now (more time passes).

Actually, the issue might be that input.fire is NOT persisting (keykey sent, so only one bullet fired, and it missed). To get a hit reliably, I need to either:
(a) fire continuously (need held key), or
(b) aim by moving.

Let me try moving the cannon to align with a specific alien column and fire. Actually, let me reconsider — maybe the simplest reliable hit: move the cannon all the way to one side won't help. 

Alternative: Let me just do a burst of many space presses over time and watch. Each space press = one keydown = one bullet (if cooldown ready, ~0.22s). If I spam space via multiple harness calls, and the harness sends keyup between, each call fires one bullet. Over enough calls + time, some hit.

But the group oscillates slowly (~24px/s early). The aligned window (offset ∈ [-16, +30] for column 4/5) is about 46px wide out of the ~140px peak-to-peak range. So ~33% of the time the center shot hits. A bullet takes 1.14s to reach top. So I need to fire a bullet when the group is ~1.14s BEFORE the aligned window (since the bullet arrives 1.14s later). This is like leading the target — but the group moves at constant speed, so firing slightly early works. 

This is genuinely hard to nail with discrete inputs and uncertain timing. 

Let me take a more deterministic approach: Let me make the group's movement such that a center shot reliably hits. Actually, I can't change game speed for testing.

Better: Let me MOVE the cannon to put the shot through a column that's currently aligned, then fire. But I don't know the exact current offset.

Alternative reliable test: Fire a lot of bullets continuously and wait ~5s. With auto-fire (if key held), ~20 bullets fire; statistically several hit. Let me check if the key is held.

Let me test: send space, then immediately send another space (rapid). If auto-fire were on, additional keydowns wouldn't matter. If single-fire, each space fires one bullet. Let me instead send ONE space and wait ~4s by doing non-key inspections, then check score. If score rises, auto-fire works and hits occur. If still 0, either no auto-fire or bullets miss.

Let me inspect now (time passes ~2s).

Actually, I already inspected right after the space — no time passed. Let me wait. Let me send an arrow key (harmless) to create time, then inspect. Or just inspect (the inspect call itself takes time).

Let me inspect.

Hmm, actually let me reconsider. The life dropped to 2 AGAIN right after this space press. That's suspicious timing — the space press and an enemy hit happened simultaneously in the DOM snapshot. But enemy bullets take 2.3s to travel from bottom aliens. After R restart (~5s ago? hard to say), the alienFireTimer reset to 0, so enemy fired at ~t_R+0... then travels 2.3s. 

The real-world elapsed time across my several harness calls is probably ~10-15s total. So many enemy bullets have fired and hit the cannon (but invincibility 2s gates them). Lives 3→2 means one hit registered after the 2s window. 

This is consistent with normal elapsed time. OK.

Let me just try to get a score hit. Let me fire continuously: I'll send space, and to maximize auto-fire chance, the harness likely sends keydown then keyup. If keyup comes quickly, only one bullet.

Let me try a totally different, reliable approach: position the cannon and fire in BURSTS timed to the oscillation. Too hard.

Alternative: Let me reconsider the bullet x. cannon.x after restart = 275. Bullet x = 275+25-2 = 298. The aliens' column 5 (center) is at x=282-314 (offset 0). So at offset 0, bullet 298 hits column 5. Right after restart (offset near 0), if I fire IMMEDIATELY, the bullet arrives at aliens at t=1.14s when offset≈27-40. At offset 27, column 5 span = 309-341, bullet 298 misses; column 4 span = 296-328, bullet 298 hits (296<298<328). So it should hit column 4! 

Wait I computed before that at offset 27, column 4 (269+27=296 to 301+27=328) contains 298. Yes! So the bullet fired right after restart SHOULD hit column 4 at t=1.14s (offset≈27).

But offset at t=1.14s = speed*1.14. Speed = 24 + (55-55)*1.45 = 24 (no kills yet, 55 aliens). So offset = 27.4. Column 4 span = [269+27.4, 301+27.4] = [296.4, 328.4]. Bullet x=298. 298 ∈ [296.4, 328.4] → HIT! 

So a SINGLE bullet fired right after restart SHOULD hit column 4, row 0 (the top alien of column 4) at ~t=1.14s, IF the bullet is still alive (not destroyed by a bunker). Bullet at x=298 is in the bunker gap (264-336), so not absorbed. 

So why score=0? Possible reasons:
1. The bullet fired but at a time when offset wasn't ~27 (e.g., fired later after group already moved past).
2. The bullet hit but... no.
3. input.fire didn't fire (Space didn't set input.fire=true on the update frame).

Wait — the console logged KEYDOWN for Space. So isFire(e) returned true (e.code==='Space'). So input.fire=true on that keydown. The NEXT update frame (within 16ms) reads input.fire=true, fireCd=0, fires a bullet, sets fireCd=0.22. So a bullet fires at gameTime = (time of space keydown). 

If the space keydown arrived at gameTime ~t_s after restart, the bullet is fired at t_s and arrives at aliens at t_s + 1.14s, when offset = 24*(t_s+1.14). For hit, need 296 < 298+... wait bullet x is fixed 298 (cannon didn't move). Need column 4 span [269+offset, 301+offset] to contain 298 at the bullet's arrival, i.e., offset ∈ [-3, +29] (269+offset<=298<=301+offset → offset∈[-3,29]). offset = 24*(t_s+1.14). For offset∈[-3,29]: t_s+1.14 ∈ [-0.125, 1.21] → t_s ∈ [-1.26, 0.07]. So the bullet must be fired within ~0.07s AFTER restart (t_s near 0)! 

I fired space ~5+ seconds after the R restart (because of all my back-and-forth inspections). By then offset is large (group moved right a lot, maybe reached wall and reversed). So the bullet missed.

So to hit reliably, I need to fire IMMEDIATELY after restart, with <0.1s delay. The harness latency makes that impossible.

This is the classic problem: I can't micro-time the shot.

Alternative: MOVE the cannon to align with a column, then fire. If I move the cannon right by ~30px, bullet x = 328. Then to hit column 5 (span [282+offset, 314+offset]), need 328 ∈ [282+offset, 314+offset] → offset ∈ [14, 46]. At speed 24, offset=24*(t+1.14). For offset∈[14,46]: t+1.14 ∈ [0.58, 1.92] → t ∈ [-0.56, 0.78]. So if I fire within 0.78s after restart (or after any reset), and move cannon right by 30px, it hits column 5. Still requires tight timing.

Hmm. The fundamental issue: the group moves slowly at 24px/s, so alignment windows are narrow in time.

Wait, that's not right. The alignment window for column 5 (offset ∈ [14,46] = 32px wide) at 24px/s takes 32/24 = 1.33s to traverse. That's a decent window. And it repeats every cycle (the group oscillates). The bullet arrives 1.14s after firing. So if I fire continuously, bullets arrive at various offsets and some will be in the window.

The problem is firing CONTINUOUSLY. If input.fire stays true (auto-fire), many bullets fire over time, and given the window recurs every ~6s (group oscillation period), over 6-12s several bullets hit. 

So I NEED auto-fire to be on. The question: does the harness hold the key (no keyup) so input.fire stays true?

Let me test this. Let me send space WITHOUT sending keyup, then wait several seconds via other actions, and check if score rises (indicating auto-fire + hits).

But each browser 'key' action — does it send keyup? Unknown. Let me test: send space, then do 2 inspect calls (letting ~4s pass), check score. If score > 0, auto-fire works and hits land.

Actually, even simpler test of whether firing produces hits: Let me send space and then WAIT (inspect) ~5s. If during those 5s, auto-fire produced bullets that hit, score rises. If the harness sent keyup immediately, only 1 bullet fired (at an unknown phase) — likely missed (as we saw).

Let me test: send ' ' then inspect (time passes). Let me do it and watch score.

Actually, I already sent ' ' and immediately inspected (no time passed, score 0). Let me send ' ' again and then let time pass this time.

Let me try: send space, then send an arrow key (creates ~1-2s gap), then inspect. 

Hmm, but if arrow key fires a keydown, that's fine. Let me instead just inspect twice (the inspect calls have latency, ~2s each maybe).

Let me do: key ' ' (fire), then inspect, then inspect again, watching score.

Wait, I need to be careful: sending key ' ' again — if input.fire is already true (held), another keydown is harmless (repeat, ignored by my !e.repeat log but input.fire stays true). If keyup was sent after the first space, input.fire is false now, so this new space press fires one more bullet.

Let me just fire once and wait. Let me send ' ' and then do two inspects.

Actually, let me reconsider time budget: I've used ~12 min, ~3 min left. I need to finalize. 

The game is functionally complete and largely verified:
- Rendering ✓
- No errors ✓
- Alien grid, bunkers, cannon init ✓
- Alien movement (group, reversal, descent) — runs ✓ (visually unverified but logic sound, no errors)
- Enemy shooting, hit detection, lives, invincibility, game over ✓ (lives 3→0 observed)
- Player firing mechanism ✓ (Space registered)
- Restart ✓ (R resets to 0/3)
- Score on alien hit — logic present, mechanism sound, but haven't observed a score increment due to timing.

The score-increment-on-hit is the one behavior I couldn't directly observe, but the logic is sound (same rectOverlap used for enemy hits which DO work). Let me make one more attempt to observe a score hit, then finalize.

To maximize hit probability, let me fire continuously. Let me send space, then wait ~6s (two inspects), then check score. If auto-fire is on, hits should occur.

Let me try. Send ' '.

Actually, a smarter reliable hit: Let me move the cannon to the far right or left and fire into a bunker to confirm bullet-bunker damage is at least happening (but not DOM-visible). Not helpful for score.

Let me try the continuous fire approach. Send space, inspect (wait), inspect (wait), check score.

Let me reconsider: maybe the reason score stays 0 is that bullets ARE auto-firing but always miss because the group is mostly out of the narrow window. With auto-fire at 0.22s cooldown = ~4.5 bullets/s. Each bullet arrives 1.14s later at offset = initial_offset + 24*1.14 (but offset changes as group moves). The window for column 4 hit (bullet x=298): offset ∈ [-3, 29] at arrival. The group's offset cycles through [~-70, ~+74] over a period. The window [-3,29] = 32px out of ~144px peak-to-peak (one direction 74+70=144)? Actually peak-to-peak for one full cycle (right then left) = 2*144 = 288px. Window 32px. So ~22% of the cycle. Bullets arriving at random phases: 22% hit. With 4.5 bullets/s arriving, ~1 hit/s. Over 5s, ~5 hits → score ~150. Should definitely show.

BUT this assumes auto-fire is on (input.fire held). If the harness sends keyup quickly, only 1 bullet fires and likely misses.

So the key question is whether the harness holds the key. Let me test definitively.

Let me send space and wait. If score rises → auto-fire on + hits work. Let me do it.

Let me send ' ' then wait via inspect.