Let me build a complete Asteroids game in a single self-contained index.html file. Let me write it.

I'll create a full playable game with:
- Canvas rendering
- Vector ship with thrust and rotation
- Shooting
- Screen wrapping
- Asteroids splitting into smaller pieces
- Score and lives
- Procedural vector graphics

Let me write the file.

Let me verify the file works by checking for obvious JS errors. Let me do a quick syntax check using node.

Let me find the error. Let me check around the splitRock function where I have `const pieces = r.size === 3 ? 2 : 2;`. That is fine. Let me check for stray parens.

Let me extract the script and check line by line.

Line 14 - this is within the mulberry32 function definition but reported at the top? The incremental parse may be inaccurate because partial code isn't valid until complete. Let me instead just look for the actual error. Let me write the script to a file and use node to check with better reporting.

The error stack doesn't give the line. Let me use a different approach - write the JS to a file and run node check.

The problem: `keys[' ']` — using a space string literal inside single quotes is fine, but the issue is `keys[' ')` — the string is `' '` which in the file... wait let me look. The token is `keys[' ')` — that means the string literal `' '` then `)` but there's an extra `)`. Actually looking at the source: `if ((keys[' ') || keys['space'])` — this has `(keys[' ')` which is `(` + `keys[` + `' '` + `)` + `. Wait: `keys[' ')` = `keys[` `' '` `)` — that closes with `)` but `['` needs `]`. So `keys[' ')` is wrong — it should be `keys[' ')` 

Wait, the correct syntax is `keys[' ']` or `keys[' ')`. Let me look: `keys[' ')` is `keys[` + `' '` + `)` — missing the `]`. The string is `' '` and then `)` closes the array access with the wrong bracket. Actually in my source I wrote `(keys[' ')` which is `( ` + `keys[` + `' '` + `)`. The `[` is never closed with `]`. So `keys[' ')` — the `)` after `' '` closes... hmm.

Actually the issue is I wrote `keys[' ')` instead of `keys[' ']`. Let me look at exact text. In the file: `if ((keys[' ') || keys['space']) &&` — so `keys[' ')` — the character after `' '` is `)`. It should be `]`. 

Wait, that's a parse error but let me just check what I actually wrote. Let me grep.

Line 765: `keys[' ')` should be `keys[' ']`. And line 767: `keys[' ']` is correct but there might be an issue — line 767 `keys[' '] = false;` is fine.

So line 765 has `keys[' ')`. Fix to `keys[' ']`.

Good, syntax ok. Let me do a quick sanity test of the core logic by running a headless simulation. But the code uses DOM and requestAnimationFrame. Let me at least test the pure math functions and logic in isolation. Actually, let me just verify there are no obvious runtime issues. Let me simulate the update/render logic with a mock canvas.

Actually it's probably fine. Let me quickly review the game logic once more for correctness.

One concern: in splitRock, `addScore(20)` for size>1 and `addScore(100)` for tiny. In classic asteroids it's 20 for small, 50 for medium, 100 for large. But since hitting a rock always splits (including size 3 -> gives 20). Fine.

The `wrapSegment` function is defined but not really used in rendering. I use wrapEdge instead. That's dead code, but harmless. Actually let me check — in drawRock I use wrapEdge, not wrapSegment. wrapSegment and drawSeg are dead. Harmless but let me leave.

Let me verify there's no committed leftover issue with `const pieces = r.size === 3 ? 2 : 2;` — always 2, fine.

Let me do a quick headless test to ensure the game loop runs without errors using a mock DOM. That's complex. Instead, let me just re-read key parts to verify correctness.

Let me verify canvas fills and everything. I think it's good. Let me test by running it in a browser-like environment — can't easily. Let me at least write a small node test that stubs document, canvas, etc. and runs a few frames.

That's a test stub issue (appendChild not defined in my mock), not a real bug. Let me add appendChild to the mock.

The game runs 400 frames without throwing. The stubs don't simulate gameplay state transitions (keys not set), but the render/update loops for the title screen run.

Let me also simulate an actual game by setting keys and triggering startGame. Actually the loop calls startGame on enter key. But keys aren't exposed globally. Let me trace — keys is a closure variable. I can't access it from outside easily.

Let me simulate gameplay by patching to inject some movement. Actually, let me just trust it. But I'd like to test the play state more thoroughly including splitting. Let me do a more comprehensive test that pokes into the closure by exposing internals.

Actually, a simpler approach: I'll add a test hook by appending `window.__test = {startGame, update, render, rocks, ship};` via patching, then drive it.

The object literal shorthand with computed property `get rocks(){return rocks;}` — the `get rocks()` inside an object in an `eval` context. Actually the error is that `startGame` is not defined because these are inside an IIFE (the whole script is wrapped in `(function(){...})()`). So my appended code is inside the IIFE too... actually I appended it after the IIFE closes? No — the code that gets placed is `code += ...` after the whole IIFE. So window.__t is defined outside the IIFE, where startGame etc. are not in scope.

I need to inject INSIDE the IIFE. Let me insert before the final `})();`.

`scorePop` is defined with `const scorePops` but referenced as `scorePop` (singular) in the object. The object literal is evaluated immediately, so referencing `scorePops` would be fine (it's defined before by const hoisting? No, const is TDZ). Actually my hook references scorePop which doesn't exist. Let me just remove scorePop from the hook.

The tests mostly pass:
- Gameplay runs 5s with 4 rocks
- Split test: 1 tiny rock + bullet → after 10 updates, rocks = 5?? Wait, before 1, after 5. The tiny rock (size 1) hit should be removed (splitRock: size>1? no, size===1 → addScore(100), no pieces). So after should be 0. But it's 5. 

Hmm, that's because the bullet spawns at ship position with vx/vy=0 and the tiny rock also at ship position. But wait, splitting happened and gave score 150 (100 for tiny + 50 level clear bonus because rocks became 0 → nextLevel() spawned new rocks, count = 3+level). level was 2 (startGame → level 0, then first rocks cleared? No).

Actually let's trace: startGame sets level=0, calls nextLevel → level=1, spawns 4 rocks. Then I set rocks=[] and add 1 tiny rock. Update 600 times first though... during those 600 updates (5s), the ship might hit rocks and things happen. rocks0 read after = 4, meaning during 5s sim with no input, the 4 rocks stayed (ship invuln 2.5s then... ship could get hit). Anyway.

Then split test: 1 tiny rock + bullet at same pos. splitRock removes it, addScore(100). rocks.length becomes 0 → triggers level clear: addScore(50*level) + nextLevel(). level is 1, so +50, new rocks = 3+1=4? Then spawnRocks(6) in... no nextLevel → spawnRocks(count=Math.min(3+level,10)). level incremented to 2, count=Math.min(5,10)=5 rocks. So after=5. Score = 100+50=150. Wait but also gameplay over 5s might have added score. Actually 150 matches exactly 100+50. 

So the split logic works correctly. The render error is just because my stub `ctx` proxy returns `0` for `ship.shape`? No, drawShip accesses `s.shape` which is a real array. The error: "Cannot read properties of undefined (reading 'length')" at drawShip line 578 — `const pts = s.shape;` and `pts.length`. So s.shape is undefined. Why? Because during render, ship may be undefined? No—render checks `if (ship && ...)`. ship is defined. 

Wait, s.shape — in startGame, ship = newShip() which has no `shape` property! shipShape is a separate const. newShip doesn't assign shape. drawShip uses `s.shape` which is undefined! That's a real bug.

I need to assign shape in newShip. Let me fix: create ship shape per ship, or reference the global shipShape. Let me set `shape: shipShape` in newShip. But if I want per-ship variation, I could generate fresh shape. Let me just use the shared shipShape.

Also note startGame sets ship.shape. Let me fix newShip to include shape: shipShape.

Let me fix.

That error is just my mock stub missing fillText. Let me add it. The real code is fine. Let me add fillText and fillRect already there.

My sed replaced the closing `}` with `.` too. Let me just rewrite the ctx line properly with fillText(){},.

All tests pass. The game logic works correctly:
- Ship splits work
- Splitting a tiny rock clears level (rocks → next level 5 rocks) and +100 + bonus
- Rendering runs without errors

Let me also verify respawn/loseLife works, and the gameover state. Let me quickly test a loseLife scenario. Actually the previous test covered it implicitly through the 5s sim. Let me just verify loseLife doesn't throw by adding a quick test. But I think it's fine.

Let me also double check the drawShip invulnerability flicker logic - when invuln>0 and flicker frame, it skips drawing ship. That means on flicker-off frames the ship is invisible — good flicker effect.

One thing: in render, the check `if (state === 'play' && ship.invuln > 0 && Math.floor(time * 12) % 2 === 0)` skip. But time is seconds passed since page load from performance.now via rAF. That's fine.

Let me verify the final file one more time for the HTML openness and that index.html is present. Also check there are no leftover comments issues. The file is complete.

Let me also confirm the title screen shows a sample of rocks drifting. On load, spawnRocks(6) is called and ship created, state='title'. In render, ship is drawn only if state !== 'title', so ship hidden on title — good, and rocks move? In loop, update only runs when state==='play'. So on title screen rocks don't move. That's fine, they're static background. Actually they won't drift. Minor, acceptable. But the sfx of rocks floating is nice-to-have. Could add title update. Let me leave as static; it's fine.

Actually, let me make the title screen slightly nicer by letting rocks drift. But keeping minimal. It's fine.

Let me do a final review of the full file quickly to make sure everything is coherent.

Let me remove the dead code: wrapSegment and drawSeg which aren't used. drawSeg and wrapSegment are dead since drawRock uses wrapEdge. Let me check if they're truly unused. grep.

grep -c returned 0 matches → exit code 1, but that's fine (means no matches). JS syntax OK. Let me re-run tester with the new file to confirm still passes.

Let me also run the first broader test (400 frames) to confirm.