Snake · mimo-v2.6-pro

Let me build the game. Single index.html file.

Key details:
- 20x20 grid canvas
- Arrow keys, ignore reversals including rapid inputs before next step (buffer input, but only accept if not opposite of current direction — and also not opposite of pending queued direction for multi-buffer? Requirement says "including rapid inputs before the next movement step" — simplest robust approach: only accept one direction change per step, or keep a small queue where each queued direction is validated against the previous accepted direction. I'll use a queue of max 2 with validation against last accepted direction).
- Food in unoccupied cell, eating grows by one, score++, spawn new food.
- Wall/body collision ends game. Tail cell vacating on non-growing step allowed.
- Start, Pause/Resume, Restart. Win when board full.
- Display controls and score. preventDefault on arrow keys.

Let me write it, then test with browser tools.

Implementation:

```js
const COLS=20, ROWS=20, CELL=24;
canvas width = 480.
```

Game state: state = 'idle' | 'running' | 'paused' | 'over' | 'won'.

Snake: array of {x,y}, head at index 0. direction {x,y}. pendingDirections queue.

Step logic:
- take next direction from queue if valid (not opposite of current dir, and not zero length)
- newHead = head + dir
- check wall collision -> game over
- compute growing = (newHead equals food)
- body check: snake cells excluding tail if not growing (tail vacates). Actually exclude last element if !growing. If growing, tail stays so all cells are solid.
- if collision -> game over
- unshift newHead; if !growing pop tail.
- if growing: score++, spawn food; if no free cells -> win.

Food spawn: collect free cells, pick random.

Timing: use requestAnimationFrame with accumulator, step interval 120ms (adjustable maybe not needed).

Rendering: draw grid, snake (rounded rects), food, score display in DOM.

Buttons: Start, Pause/Resume, Restart. Pause button label toggles Pause/Resume.

Keyboard: ArrowUp/W etc. Space could toggle pause — optional but fine. preventDefault on arrows.

Rapid inputs: queue max 2 entries; validate each against last accepted direction (track lastQueuedDir). E.g., moving right, press Up then Left quickly: Up accepted (lastQueued=Up), Left is opposite of Up -> ignored. Good.

Let me write the file.

Also mobile? Not required. Keep it clean.

Now write index.html.

Let me write full HTML with style.

I'll write the code carefully.

Then test in browser: load, check console errors, click Start, send arrow keys, check snake moves, pause/resume, restart checks.

For browser testing, I can use `browser` tool with actions. To check game state I can inspect DOM (score text) and maybe expose window.__game for testing. I'll add a small debug handle `window.__snake` exposing state for verification — harmless.

Let me write it.

Now run it in the browser and verify.

The layout renders. Note the canvas appears to not fill the shell width — the canvas is 520px wide, and shell centers it. Actually there's an offset: the canvas appears narrower than the panel and offset... it looks fine actually (canvas centered inside shell, with slight borders). Actually the canvas seems shifted left relative to the panel? The panel is 290-910 (620 wide), the canvas 335-860 (525). That's centered-ish (335-290=45, 910-860=50). Fine.

Now test gameplay. Click Start, then press arrow keys and check state. Let me use the browser click on Start button (coordinates ~343, 209), then key presses, then inspect.

I'll also use __snake handle via inspect? The browser tool has "inspect" action which probably shows DOM/console. I can't easily run JS eval... Let me check what inspect returns. Actually maybe I can type into something. Let me just use key presses and inspect DOM (score/length/status text).

Plan:
1. Click Start (343, 209).
2. Press ArrowDown a few times — snake moves down; inspect DOM to see status "Running".
3. Check movement grid alignment via __snake? inspect might give DOM only. Let me try inspect after actions.

Actually a better verification: use the console through the browser tool? Not available. But I could add a temporary debug readout... Alternatively I can verify by rendering: the snake head position visually.

Hmm, I can verify game logic with node by extracting the script? That's heavier. Simpler: use keyboard + screenshots to visually verify, and use DOM values for score/length/status.

But food placement in a free cell and restart resets — DOM shows length 3 and score 0 after restart; food in free cell requires visual or JS. I could expose __snake and read it via... maybe the "inspect" action prints DOM. Let me try using the browser "type" action into a text field? No.

Alternative: run a headless check with node? No DOM. Could do quick logic test by copying the JS logic into a node script — but that tests a copy.

Better: I could temporarily make the page display debug info in a DOM element... Actually I can just add a hidden but queryable element? Simpler: add a small element that shows "food: x,y" in the footer? That's odd.

Alternative: the inspect action might return console logs. I could add a console.log of state on each step temporarily... but console output is captured in the tool output ("console": [...]). Yes! The reload output includes console messages. So I can temporarily add console.log in step() to verify movement, food, etc. Or permanently add a lightweight debug log? Better to temporarily instrument, verify, then remove.

Actually simpler: use inspect action — maybe it can run JS? Unknown. Let me just do temporary instrumentation: add console.log in step() and spawnFood(). Actually I can add a permanent `console.debug`-free approach... temporary is fine.

Let me do: click Start, press keys, screenshot, and check DOM status/score/length. Plus temporary console logging for food cell occupancy check.

Let me add temporary logging first.

Wait — step() logs before unshift so "len" is pre-move. Fine.

Now reload and start the game. Click Start at approximately (343, 209).

Food spawned at (12,16) in a free cell (free=397 = 400-3 snake cells). Good.

Now click Start, then press arrow keys and inspect console logs.

Game running, snake of length 3 at middle, food above the snake. Status "Running". Interesting: the frame shown is at 0ms but the game is running — the screenshot shows the snake at its start position.

Note: Start button still shows "Start" but is disabled (grey). Fine.

Now press ArrowDown, ArrowLeft rapid, and see console logs. Let me do key presses: ArrowDown (turn down), then quickly ArrowRight + ArrowDown to test queue rejection... Let's test:
1. Press ArrowDown — snake turns down.
2. Rapid: ArrowUp (should be ignored as reversal), then inspect.

The browser key action presses one key at a time; frames advance between presses maybe. Let me just do sequences and look at the DBG step logs to see dir changes.

First press ArrowDown.

Interesting — a lot of time passed between the click and the key press (the game ran to the wall before my key press was processed). The head moved one cell at a time (x 10→19), grid-aligned, and wall collision ends the game. Good — that verified movement and wall death, though the ArrowDown press came after game over (ignored, which is correct since state != running).

Note: the tool's frames advance time rapidly between my calls. So I need to be quick: after starting, immediately press keys. But each tool call seems to advance many frames. Hmm — during this key call, the game advanced 10 steps before processing? Actually the log accumulated steps from the moment of start until now. So there's significant time between tool calls (~1.2s+).

To test turning reliably, I could pause the game first, or slow it down. Better approach: use the exposed __snake API? But I can't eval JS via browser tool... Actually maybe I can — the `type` action types text into a focused element. Not eval.

Alternative strategy: press keys rapidly in succession — each key action is a separate call with time between. But time between calls only matters if the game is running; the game advances 1 cell per 125ms. Between tool calls, maybe 1-2s passes → 8-16 cells. With 20 cells width, we can survive a couple of calls.

Better: make the game turn-testable by pressing keys in sequence quickly. Or: pause the game (which stops movement) — but then arrow keys are ignored since state !== running. Hmm, I could allow queued input while paused? No, that's odd.

Another option: temporarily slow STEP_MS to e.g. 2000ms for testing, verify turns/pause/restart, then revert. That's pragmatic. Let's do that: set STEP_MS = 1500 temporarily.

Actually better idea: use key action with multiple keys? The `text` param may accept multiple keys? Unknown — likely one key. Let me just temporarily raise STEP_MS to 1200 for testing.

Also test pause/resume: pause prevents steps. Restart resets.

Also test reversal rejection: while moving right, press ArrowLeft → should be ignored (game continues moving right). With slow step this is testable.

And rapid inputs: press ArrowDown then ArrowUp quickly → the ArrowUp should be rejected (reversal against queued Down). With slow step, both presses happen within one step interval. Then step log shows dir=0,1 (down) and queue=1... wait after consuming Down, queue becomes 0. The log prints queue length before shift? In step(), the queue shift happens at the beginning, then log prints inputQueue.length after shift. Let me trace: pressing Down then Up quickly → queue=[down]; Up rejected since opposite of down. Step: shift down → dir=down, queue now 0, log queue=0. Fine — I'll observe dir in logs.

Then eat food: hard to steer to food precisely with tool calls, but growth could be tested via... Actually I can verify growth by steering toward the food if I know its coordinates (logged). With slow steps (1.2s) and tool calls, I can navigate a Manhattan path. That may take many calls but each call = 1 step. Let's set STEP_MS=1200 and try. Actually maybe 1000ms and navigate.

Alternatively I can test growth deterministically by temporarily making food spawn directly in front of the snake... simpler: temporarily add a debug that places food at head+2? Hmm, modifying spawn logic for test then reverting is error-prone.

Pragmatic approach: with slow steps, navigate to food using logged coordinates. Food coordinates are logged at reset. Path: from start head (10,10) going right... I'll compute as I go.

Actually — there's a much easier trick: temporarily set STEP_MS very large (e.g. 60000) and use the Enter/arrow keys... no, movement then never happens.

Wait — I could temporarily expose a "manual step" and drive via keyboard? The window.__snake.step exists but I can't call it without eval.

Hmm, can I trigger JS through the page? The `type` action types into focused element — if I create a text input that evals its value on Enter... That's a test harness inside the page. Too hacky but effective and easy: temporarily add an input whose keydown Enter does eval(value). Then I can call __snake APIs, verify growth, tail-vacate rule, win state, etc. quickly. Then remove the harness before finalizing.

But careful: keep final file clean. I'll add the harness temporarily and remove at the end.

Actually maybe the browser tool's `inspect` action accepts x/y and returns element info; maybe not eval. Let me just do the input-harness approach — it's reliable.

Plan:
1. Temporarily add hidden input#eval with Enter → try { console.log("EVAL", JSON.stringify(eval(value))) } catch.
2. Focus it via click, type commands like `__snake.queue({x:0,y:1}); "ok"` etc.
3. Verify: 
   - grid movement (already verified one cell at a time)
   - reversal ignored
   - rapid input handling
   - eating food → growth, score, respawn in free cell
   - tail vacate allowed
   - restart resets
   - win state
4. Remove harness and debug logs, restore STEP_MS (keep 125), final reload check.

Also should test pause/resume through buttons/keys with normal flow — doable regardless of step speed.

Let me implement the harness. I'll place the input in the page temporarily.

Also for deterministic tests I can pause the game and use __snake.step() manually. 

Let me write the harness: input id="evalbox", keydown Enter → evaluate. Also make it visible at the bottom temporarily so I can click it.

Eval returns value; log it as JSON.

Let me do it.

Also slow the game down temporarily so it doesn't run wild between calls: set STEP_MS = 100000 effectively paused? Better: set STEP_MS = 5000 temporarily so manual control works; I'll use __snake.step() for deterministic steps. Actually with eval harness I can just pause the game immediately after start and drive step() manually. But pause isn't needed — let me set STEP_MS to 60000 temporarily so real-time stepping barely happens; then all stepping is manual. But then keyboard arrow handling: queueDirection only works when state === 'running', which is fine since state is running.

But grid movement "advance one cell at a time" was already verified with real timing. For turn-response tests I'll use manual steps and real keyboard arrows.

Let me set STEP_MS temporarily to 60000... Actually keep it at 125 but pause the game right after starting? While paused, arrow keys are ignored (by design). Hmm, for the direction tests I want real arrow key events with running state. So slow the clock: STEP_MS = 30000 (30s per step) — plenty of slack between tool calls, and I can use manual __snake.step() to advance. Then final restore to 125.

Let me edit STEP_MS temporarily.

Now reload, click Start, then click the eval box and type commands.

Sequence of tests:
A. Start game (click Start).
B. ArrowDown key → queue down; eval __snake.step() then read dir → should be (0,1). Test grid alignment: head moves exactly 1 cell.
C. Reversal: while moving down, press ArrowUp → should be ignored; step(); dir should still be (0,1) and head y+1.
D. Rapid inputs: press ArrowLeft then ArrowRight quickly (both before step) → Left accepted, Right rejected (opposite of queued Left). step() → dir=(-1,0), queue empty... wait after step, queue empty. Then eval shows dir (-1,0).
   Also rapid: moving left, press Up then Down quickly → Down rejected (opposite of queued Up).
E. Eating: place food in front? I can't set food directly (no setter). But I can navigate: eval __snake.food to get coords, then queue steps to reach it. With manual steps I can compute a path. Simpler: use eval to manipulate internals? __snake exposes getters only for snake/food. But eval runs in page scope... the IIFE is closed, so I can't reach internals. But I can navigate the snake with manual steps using arrow keys + step(). Feasible: read food coords, then steer: e.g. move vertically then horizontally. Each step needs a key press + step call... that's many tool calls.

Better: extend harness eval to accept a sequence. Since eval is arbitrary JS, I can write code that dispatches KeyboardEvents and calls __snake.step() repeatedly in a loop within one eval! e.g.:

`(function(){ var s=window.__snake; var f=s.food; ... })()`

I can dispatch keydown events on window via `window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowUp'}))` — my handler listens on window and checks e.key. That works in-page. And call s.step() to advance. So I can script full scenarios in one eval string. 

Let me write test scripts:

Test 1: movement & turns
```
(function(){
 var s=window.__snake; var out=[];
 s.restart();
 out.push('start '+JSON.stringify(s.snake)+' dir'+JSON.stringify(s.dir));
 window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowDown'}));
 s.step();
 out.push('afterDown head'+JSON.stringify(s.snake[0])+' dir'+JSON.stringify(s.dir));
 window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowUp'})); // should be ignored
 s.step();
 out.push('afterUpAttempt head'+JSON.stringify(s.snake[0])+' dir'+JSON.stringify(s.dir));
 window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowLeft'}));
 window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowRight'})); // rapid reverse, must be ignored
 s.step();
 out.push('afterRapid head'+JSON.stringify(s.snake[0])+' dir'+JSON.stringify(s.dir));
 return out.join(' | ');
})()
```

Test 2: eating & growth & respawn free cell
```
(function(){
 var s=window.__snake; s.restart();
 var out=[]; var guard=0;
 while(s.state==='running' && guard++<2000){
   var h=s.snake[0], f=s.food;
   if(!f) break;
   if(h.x!==f.x){ window.dispatchEvent(new KeyboardEvent('keydown',{key: h.x<f.x?'ArrowLeft':'ArrowRight'})); }
   else if(h.y!==f.y){ window.dispatchEvent(new KeyboardEvent('keydown',{key: h.y<f.y?'ArrowUp':'ArrowDown'})); }
   s.step();
 }
 out.push('state='+s.state+' score='+s.score+' len='+s.length+' food='+JSON.stringify(s.food)+' guard='+guard);
 // verify food not on snake
 var occ=s.snake.some(function(p){return s.food && p.x===s.food.x && p.y===s.food.y;});
 out.push('foodFree='+(s.food? !occ : 'none'));
 return out.join(' | ');
})()
```
Careful: navigating directly to food may crash into body (snake length 3, straight chase usually fine, but turns could reverse). Since path is Manhattan with only one turn, and snake is short, it's OK — but the naive controller might attempt a 180 when food is exactly behind. Guard against: choose direction not reversing current. Actually if food is behind the head, going straight at it would require reversal — instead first move perpendicular. My controller: if h.x!==f.x move horizontally; that could be a reversal. Add check: compute desired dx,dy; if desired is reverse of s.dir, pick a perpendicular move first. Fine, I'll add.

Also verify growth: score and length both increase.

Test 3: tail-vacate allowed. Hard to construct naturally... I can craft: grow the snake a bit, then steer in a tight loop? Complicated. Alternative: use eval to verify the logic indirectly — hmm, internals inaccessible.

Alternative approach for tail test: build a scenario where the snake chases its own tail: drive the snake in a circle. With length 4+, moving in a circle each step the head moves into the cell the tail just vacated... Actually in a circle chase, head moves into the cell occupied by the segment ahead of tail? For a snake of length L in a square loop path, head entering the previous tail cell happens when the head catches up to the tail exactly. If the snake is exactly filling a loop, the head moves into the tail cell each step. That's a natural construction: snake length 3 though. Hmm.

Easier: since a 3-length snake can't hit its own tail anyway (moving into tail cell = moving into neck = reversal, which is blocked). So the tail-vacate rule only matters for length ≥ 4 with the head landing exactly on the current tail cell. Construct: snake of length 4 in a 2x2 square? A snake can't occupy a 2x2 square... actually it can: (0,0)head,(1,0),(1,1),(0,1) — yes, a 2x2 loop. Then moving up/right/down/left rotates. Head at (0,0) moving... head into the tail cell (0,1) means moving down — allowed if dir isn't up. Let's see: snake [head (0,0), (1,0), (1,1), tail (0,1)] with dir... head came from where? It can be constructed by steering.

Constructing this via the controller is doable but fiddly. Alternative: verify logically via a standalone JS test in node replicating the step function? That tests a copy.

Alternative simpler construction: grow snake to length ≥4 by eating, then drive it in a "square spiral" so the head follows exactly one cell behind the tail... For the head to land on the tail cell, distance along body must equal length-1 in path cells... i.e. head is directly behind tail, and moves into tail's cell while tail moves away. That happens whenever the snake is "coiled" so head is adjacent to tail and the tail moves away from head in the same step. With a circle of length L in cells of a loop, head adjacent to tail. For L=4: 2x2 square works.

Practical approach: after growing to length 4+, drive it in tight circles of 2-cell... Let me instead do this: grow to length 4, then navigate to form the 2x2 square near a corner and check that the game doesn't end.

Actually here's a much simpler deterministic trick: the controller could drive the snake along a Hamiltonian-ish "ring" path: turn right every 2 steps creates a zigzag... Hmm.

Alternative: verify tail rule with a targeted unit test of the actual code: I can extract the step logic... no.

Alternative pragmatic: modify the harness to expose a test setter temporarily: add to __snake a `debugSet(snakeArr, dirVec, foodPos)` method temporarily. Then I can set up the exact 2x2 square scenario and call step(), verifying no game over and head occupies the vacated tail cell. That's clean and I remove the setter with the harness. Let me add that temporarily.

Let me add to __snake (temporary): `__dbg: function(sn, d, fd){ snake = sn.map(...); dir = d; food = fd; inputQueue=[]; state='running'; }`. I'll add it via the harness script? It's inside the IIFE scope... I'd need to edit the __snake object definition. Fine — add `dbg` temporarily there and remove later. Or simpler: attach it inside the IIFE as a temporary line. Let me edit the __snake object to include a dbg function temporarily.

Actually, I can implement the whole verification differently: instead of a setter, note that __snake.step exists and I can call it after steering. The 2x2 square construction via steering: snake length 4, wrap it into a square. Let's think: with manual steps and the steering controller, I can write a scripted sequence of key+step in one eval — I can literally program the exact sequence of turns: e.g. go right 1, down 1, left 1, up 1 repeatedly. Starting from a straight length-4 snake moving right, do: down, (step), left, (step), up, (step) → now it forms... let's trace.

Start: head (10,10) dir right, body [(10,10),(9,10),(8,10),(7,10)].
- key Down, step: head (10,11). body [(10,11),(10,10),(9,10),(8,10)].
- key Left, step: head (9,11). body [(9,11),(10,11),(10,10),(9,10)].
- key Up... that's reversal? current dir is left; up is fine. step: head (9,10) — but (9,10) is occupied by tail! Tail vacates this step (non-growing) → allowed. body becomes [(9,10),(9,11),(10,11),(10,10)] — the 2x2 square, and the game must NOT be over. 

That's exactly the tail-vacate test, achievable with keys + step() in one eval. And continuing: key Right, step: head (10,10) which is the new tail → vacates → allowed. Rotating square forever. If the rule were wrong, the game would end at step 3. Excellent — no debug setter needed.

Test 4: pause/resume via buttons/keyboard. eval can call __snake.pause() but better to test the real button: click Pause button, then check status DOM, then step... Actually pause behavior: while paused, no stepping. Test via eval: `window.__snake.start(); ...` Hmm, simpler: click the Pause button via browser tool and inspect DOM (status = Paused), click Resume → Running. That tests the buttons. Also keyboard P/Space.

But careful: STEP_MS is 30000 now so nothing moves anyway; pausing effect on stepping can be verified via eval: while paused, call nothing... The frame loop only steps when running. To verify pause halts movement, I can rely on real timing test at the end with normal STEP_MS: start, note head position via eval... but eval calls are separate tool calls with the harness. Hmm — after restoring STEP_MS=125, I can: start game, eval read head, wait (tool call for screenshot), eval read head → moved. Then pause, eval head, screenshot (time passes), eval head → unchanged. That works with the harness before removal. Good.

Test 5: Restart resets: grow the snake a bit (score>0, length>3), then click Restart button, eval: score 0, length 3, food free cell, state running. Also restart from game-over state resets.

Test 6: win state — filling the board. Hard to actually play 400 cells. I can verify via a scripted Hamiltonian cycle filling the whole board! With the eval harness I can program a snake-following path... Actually simpler: temporarily (in harness eval) I can't set the snake. Hmm.

Alternative for win: use the tail-following trick — a snake that follows its own tail along a Hamiltonian cycle will eventually fill the board. I can program a boustrophedon path: the snake of length L follows the serpentine path; the head just keeps going along the serpentine route and eats food each time... but food spawns randomly, not in front. To fill the board I need to eat food whenever the head reaches it — with the serpentine path the snake covers all cells eventually if it eats food placed anywhere... complicated.

Simpler approach: temporarily add a debug setter to fill the board to 399 cells with food at the last free cell and check that the win state triggers without errors. That requires the setter. Alternatively, temporarily patch spawnFood... 

Alternative: verify the win branch by code review — it's a small, clear branch. Given time budget (15 min), I could do a targeted test: temporarily add a `dbgFill()` to __snake that sets snake to all cells except one and food there, then step() → should set state 'won'. Then remove with harness. Let me add a temporary dbg setter in the harness-adjacent edit — but it must be inside the IIFE. I'll add it to the __snake object as `dbgSetup` temporarily, and remove in the same edit pass at cleanup.

Given time, let's do it: add to __snake:
```
dbgSetup: function (sn, d, fd) { snake = sn.map(function(p){return {x:p.x,y:p.y};}); dir = d; food = fd; inputQueue = []; state = "running"; updateHud(); },
```

Then eval can build the win scenario: snake = all cells except (19,19)... actually to test win: snake occupies all 400 cells except head's next cell... Let's construct: snake occupies every cell except (0,0) and (1,0); head at (1,0) dir left; food at (0,0). Step: head moves to (0,0), grows, spawnFood finds 0 free cells → win. snake array must have head first. Build programmatically in eval.

Also with dbgSetup I can also directly test the tail-vacate rule and reversal more crisply. But the key-driven square test is more end-to-end; I'll do both quickly.

OK, let me add dbgSetup temporarily.

Now reload and run test scenarios through the eval box. Steps:
1. reload
2. click eval box (10,10 area... input at left:10 top:10 width 300 → click at (150,20))
3. type the eval script + Enter? The `type` action types text; does it press Enter? I can type text then use `key` action with "Enter". The key action might send to the page/keyboard — presumably focused element. Let me type then key Enter.

Careful: typing a long JS string with quotes — the type action sends text. Should be fine.

Test 1 script (movement, turns, reversal, rapid input):

(function(){var s=window.__snake,o=[];s.restart();o.push('init '+JSON.stringify(s.snake)+' d'+JSON.stringify(s.dir)+' food'+JSON.stringify(s.food));window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowDown'}));s.step();o.push('down1 '+JSON.stringify(s.snake[0])+' d'+JSON.stringify(s.dir));window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowUp'}));s.step();o.push('revIgnored '+JSON.stringify(s.snake[0])+' d'+JSON.stringify(s.dir)+' st='+s.state);window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowLeft'}));window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowRight'}));s.step();o.push('rapid '+JSON.stringify(s.snake[0])+' d'+JSON.stringify(s.dir));window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowUp'}));window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowDown'}));s.step();o.push('rapid2 '+JSON.stringify(s.snake[0])+' d'+JSON.stringify(s.dir)+' st='+s.state);return o.join(' | ')})()

Expected: init head (10,10) d (1,0). down1 head (10,11) d(0,1). revIgnored head (10,12) d(0,1) running (ArrowUp ignored). rapid: Left accepted (from down → left ok), Right rejected (opposite of queued left) → head (9,12) d(-1,0). rapid2: Up accepted (from left), Down rejected → head (9,11) d(0,-1).

Note: after restart, dir is right and head (10,10). But wait — restart() sets state='running' and resets. Good.

Careful: KeyboardEvent dispatch — my handler calls e.preventDefault(); synthetic events support that. Fine.

Also note the game with STEP_MS=30000 will accumulate accumulator over time... after 30s a step occurs. My tool calls might exceed 30s total? Possibly! accumulator += delta with delta capped at 250ms per frame. Real time accumulates. If 30s pass, one step occurs spontaneously — could disturb tests. Let me lower risk: set STEP_MS to 300000 (5 min). Actually the accumulator resets on startGame/restart. Tests take maybe 2-4 min... Let me change to 600000 to be safe. Actually simpler: I'll keep 30000 but each test calls s.restart() first which resets accumulator... but restart resets snake too, fine. Within a single eval, steps are instantaneous so no drift. Between evals, a stray step might occur but each test restarts first. OK, but for the pause test I need real timing — I'll do that at the end after restoring STEP_MS=125.

Hmm, one problem: after restart() the accumulator isn't reset (only startGame/restartGame set accumulator=0). __snake.restart → restartGame() sets accumulator = 0. Good.

Let me run test 1.

Eval box is visible. Now click it and type test 1.

Now type the test script into the focused input, then press Enter.

The text was typed into the input. Now press Enter to evaluate.

Two issues:
1. `eval` is blocked by CSP ('unsafe-eval' not allowed). So my harness can't eval strings. But interestingly, the Enter key in the input... my keydown handler on window fired Enter → startGame()! That's why status became "Running" and food respawned at (10,19). Note the input's keydown handler also ran but eval failed.

So I need a different approach: instead of eval, use a fixed dispatcher that parses commands differently. Options:
- Use `new Function(...)` — also blocked by CSP (unsafe-eval).
- Use `setTimeout(string)` — blocked too.
- Instead of eval of typed code, make the harness input dispatch to pre-registered named test functions! I can define `window.__tests = { t1: function(){...}, t2: ... }` in the harness script (compiled inline, allowed by 'unsafe-inline'), and the input just picks a test by name and logs the result. That works fine — no eval needed.

So: rewrite the harness to have a `runTest(name)` which calls window.__tests[name]() and console.logs the result. And typing "t1" + Enter runs it.

Also I must stop Enter in the input from bubbling to my game handler — or rather it doesn't matter much, but the game's Enter handler starting games interferes. I'll stopPropagation in the input's handler.

Also note CSP blocks eval — good to know for the final app (it doesn't use eval; fine).

Let me define tests:
- t1: movement/turn/reversal/rapid (as above)
- t2: eat food → growth, score, respawn free
- t3: tail-vacate square
- t4: win state via dbgSetup
- t5: restart reset after growth (uses DBG)

For t2 I need to navigate to food with a controller using dispatched key events and s.step().

Let me write the harness replacement now.

Test t2 code:
```
t2: function(){
  var s = window.__snake, out = [], guard = 0;
  s.restart();
  var startLen = s.length, startScore = s.score;
  while (s.state === 'running' && guard++ < 3000) {
    var h = s.snake[0], f = s.food;
    if (!f) break;
    var key = null;
    if (h.x !== f.x) key = (h.x < f.x) ? 'ArrowRight' : 'ArrowLeft';
    else if (h.y !== f.y) key = (h.y < f.y) ? 'ArrowDown' : 'ArrowUp';
    if (key) {
      // avoid 180 reversals
      var d = s.dir, nd = {ArrowRight:{x:1,y:0},ArrowLeft:{x:-1,y:0},ArrowUp:{x:0,y:-1},ArrowDown:{x:0,y:1}}[key];
      if (nd.x === -d.x && nd.y === -d.y) {
        key = (d.x !== 0) ? 'ArrowDown' : 'ArrowRight';
        nd = {ArrowRight:{x:1,y:0},ArrowDown:{x:0,y:1}}[key];
      }
      window.dispatchEvent(new KeyboardEvent('keydown', {key: key}));
    }
    s.step();
  }
  var occ = s.food ? s.snake.some(function(p){return p.x===s.food.x && p.y===s.food.y;}) : 'nofud';
  out.push('startLen='+startLen+' endLen='+s.length+' score='+s.score+' state='+s.state+' guard='+guard);
  out.push('foodFree='+(s.food ? !occ : 'none')+' food='+JSON.stringify(s.food));
  return out.join(' | ');
}
```
This eats the first food then stops? No — it loops until state != running or 3000 steps; it will keep eating food repeatedly (growing a lot). Actually that's fine and even better: verify multiple eat/respawn cycles. But it will eventually crash into its own body (naive controller). Then state='over' and I can report score/len. Hmm, I want to verify growth at least. Let me break out after first successful growth: check s.score > 0 → break after verifying food free. Let me just run a loop up to 20 foods or until death, then report. Actually the naive controller avoids body? Not necessarily. Let me limit to: run until score >= 3 or guard limit, then report. That verifies growth and respawn multiple times.

For the controller, avoid reversal properly.

t3 tail-vacate:
```
t3: function(){
  var s = window.__snake, out = [];
  s.dbgSetup([{x:10,y:10},{x:9,y:10},{x:8,y:10},{x:7,y:10}], {x:1,y:0}, {x:0,y:0});
  window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowDown'})); s.step();
  out.push('a '+JSON.stringify(s.snake)+' st='+s.state);
  window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowLeft'})); s.step();
  out.push('b '+JSON.stringify(s.snake)+' st='+s.state);
  window.dispatchEvent(new KeyboardEvent('keydown',{key:'ArrowUp'})); s.step();
  out.push('c '+JSON.stringify(s.snake)+' st='+s.state); // head enters vacating tail cell (9,10)
  out.push('len='+s.length);
  return out.join(' | ');
}
```
Food at (0,0) so no accidental eating during the test.

Expected after c: snake [(9,10),(9,11),(10,11),(10,10)] and state 'running'.

t4 win:
```
t4: function(){
  var s = window.__snake, out = [], sn = [];
  // build: fill all cells except (0,0) and (1,0); head at (1,0) moving left toward food (0,0)
  for (var y = 0; y < 20; y++) for (var x = 0; x < 20; x++) {
    if ((x===0&&y===0) || (x===1&&y===0)) continue;
    sn.push({x:x,y:y});
  }
  sn.unshift({x:1,y:0}); // head
  // wait: (1,0) excluded from the loop, so unshift is correct
  s.dbgSetup(sn, {x:-1,y:0}, {x:0,y:0});
  out.push('lenBefore='+s.length);
  s.step();
  out.push('state='+s.state+' score='+s.score+' len='+s.length);
  return out.join(' | ');
}
```
Careful: body collision check — snake body includes all cells except (0,0),(1,0) plus head (1,0). Length = 399. Moving to (0,0) with food → willGrow → limit = snake.length = 399, check all body cells for (0,0): none → ok. Then unshift, score 1, spawnFood → free cells: none (400 occupied) → returns false → state 'won'. 

t5 restart: use dbgSetup to set a grown snake and score? score is internal; but I can drive actual gameplay: after t2 the score is >0; then click Restart... but the test framework only logs. I'll do t5 as: run eat loop to score>=1, then call s.restart() and report score/len/food/state. And also test the real Restart button via browser click separately (with eval-readout via a getter test "tstate").

Let me add a `tstate` test that just reports the current state snapshot (state, score, len, head, food, dir) so I can read values after clicking real buttons.

Also t6: pause test via real button + time. With STEP_MS=30000, movement doesn't happen; I'll restore STEP_MS=125 at the end and do a real-time pause check by clicking Pause and calling tstate twice (time passes between tool calls → if paused, head unchanged).

Hmm, but with STEP_MS=30000 the accumulated delta also matters. Let me restructure final verification:
1. Remove debug logs + harness? No — keep harness (minus eval) until after real-time tests, then remove. But removing harness requires a final reload to confirm nothing broke — fine.

Actually simpler ordering:
- Now: run t1..t5 with manual steps (STEP_MS still huge, harmless).
- Then: restore STEP_MS=125, remove DBG logs (keep harness), reload, do real-time checks: start via Start button, tstate; wait; tstate (head moved by 1 cell per step, grid aligned); press ArrowDown + ArrowLeft, tstate; click Pause, tstate twice (no movement while paused), click Resume, tstate twice (moves); play until eat? maybe not needed; click Restart button, tstate (score 0, len 3, food free).
- Then remove harness and dbgSetup, restore STEP_MS comment, reload, final screenshot + console check.

Good. Let me write the harness replacement now.

Time is tight. I need to finalize: remove the test harness and dbgSetup, restore STEP_MS=125, remove DBG logs, save index.html, then do a quick final browser check.

But I haven't verified behavior yet with the harness. The harness tests would take several tool calls. Let me be pragmatic: I'll do ONE quick verification pass before cleanup — actually cleanup is essential. Let me prioritize:

1. Restore production code (remove harness, dbgSetup, DBG logs, STEP_MS=125) — must do.
2. Reload and check no console errors, screenshot.
3. One quick interactive check: click Start, press arrow keys quickly, pause/resume, restart — but each call takes time.

Actually I could run the tests in one shot first since the harness is in place: reload, click input, type "t1", Enter — that's 3 calls per test. Too slow for 5 tests. Alternative: chain all tests into one function? I could run one combined test by typing "t1"... but I want at least some verification.

Better: run the combined verification quickly: modify harness so a single test "all" runs t1..t5 and returns combined. But that's another edit + reload + type + Enter = 4 calls, then cleanup edits + reload = 3 more. That's ~7 calls. Tight but the checks are valuable.

Actually simpler: I can make the input default run ALL tests when empty/Enter with "all"... Let me instead just type "t3" style. Hmm.

Compromise: add `all` to tests via a tiny edit that also does the cleanup? No.

Let me do this efficiently:
Step A (1 edit): remove DBG logs + restore STEP_MS + remove dbgSetup? No — keep dbgSetup/harness for one test run.

Time check: 5 minutes. Each browser call ~ maybe 20-30s of budget? Unknown. Let me limit to: 1 edit (add "all" test), 1 reload, 1 click, 1 type, 1 key → get results of all logic tests. Then 1 edit (cleanup), 1 reload + final screenshot. That's 7 calls. Risky but let's move fast.

Actually I can avoid the click: typing might work on the already-focused input after reload? Focus is lost after reload. The `type` action may need focus. Perhaps `type` types into the page with focus on body — then my input wouldn't receive it. I need the click.

Alternatively, make the harness auto-run all tests on load and console.log results! Then just reload → console shows results. That's 1 edit + 1 reload. 

Let me do that: edit harness to run t1..t5 immediately on load and log. Then reload and read console. Then cleanup + final reload.

Let me make that edit now — I'll modify the harness's end: after defining __tests, call each and log. And in the same edit... no, cleanup must be a separate edit after.

Go.

Note t2 calls s.restart() which sets state running and then... after the tests, the game will be running with STEP_MS=30000 — fine.

Reload now.

Excellent results:
- t1: movement one cell at a time, turns work, ArrowUp reversal ignored (continued down), rapid Left+Right → only Left applied, rapid Up+Down → only Up applied. ✅
- t2: ate 3 foods, grew 3→6, score 0→3, food respawned in free cell (foodFree=true), restart → score 0 len 3 head reset. ✅
- t3: tail-vacate — head moved into vacating tail cell (9,10) and game stayed running, len 4. ✅
- t4: filling board → state 'won', len 400, food null. ✅
- t5: wallHit st=running — hmm, expected 'over'! Let me check t5: snake [(5,5)head,(5,6),(6,6)], dir up, step → newHead (5,4), which is NOT a wall. Oops — my test was wrong: head at y=5 moving up needs 5 steps to hit wall, but I only stepped once. The test scenario was flawed, not the game. Wall death was already verified earlier in real play (the DBG gameover at x=19 wall hit). Self-hit also not reached. So the earlier real-time run confirmed wall death.

Also note the screenshot shows "You Win!" overlay while status shows "Running" — this is because t5's dbgSetup reset state to 'running' after t4 set 'won', leaving the overlay stale. Test artifact only.

Note the HUD shows score 1/len 4 which is t5's state — fine.

One issue: t4's win happened; good. But "score=1" in win message because the whole board was pre-filled — expected.

Now cleanup: remove DBG logs, remove harness script, remove dbgSetup, restore STEP_MS = 125. Then final reload + quick real interaction check (start, arrow, pause, restart) — time is short; I'll do one reload + one quick interaction sequence if possible.

Also fix: in step() the log line removal. And the win overlay: fine.

Let me do the cleanup edit now.

Now reload for a final check: no console errors, no harness, and one quick real interaction: click Start, arrow key, then Pause, then Restart. Let me do reload first (also verifies clean console).

Clean: no console errors, harness gone, Ready state, food on board. One last quick real interaction: click Start and immediately click Pause to confirm the buttons work in the final build, then screenshot. Time budget is nearly done — do one combined check: click Start (343,209). Then click Pause (428,209) — verify status Paused. That's 2 calls. Then maybe one more: Resume + Restart. Let me do Start then Pause in two calls quickly.

Final build runs, Status = Running, snake 3 segments, food on board. Now click Pause (428, 209) and confirm Paused state + Resume label. Then I'm done — time budget nearly exhausted.

The snake hit the right wall before my Pause click landed (time passes between tool calls), so the game was already over — Pause is disabled and correctly ignored (status "Game Over", overlay shown with correct death message). That's expected behavior given unattended real-time running; the Pause button itself was verified disabled in game-over state. Earlier logic tests (via the harness) verified pause/resume state transitions indirectly? Not exactly, but pause/resume code paths are simple and the button label/enable logic was exercised across states (Ready→Running→Game Over).

Hmm, the required verification mentions Pause/Resume and Restart checks. I verified Restart resets (t2: afterRestart score=0 len=3 head reset, food in free cell) and the Restart/Start buttons work. Pause/resume buttons: Pause disabled in game-over — correct. The pause/resume toggle itself wasn't directly observed. Given the time budget (I'm at the limit), let me do ONE final quick click: click "Play Again"/Start then Pause immediately in one call? Each call is one action. Time's nearly up.

Actually I can do 2 quick clicks: Start (362,209) then Pause (466,209). But between calls the snake moves right from center and dies after ~10 steps = 1.25s. Tool calls seem to take longer than that (previous evidence). So the Pause click will again land after game over.

Alternative: click Start and then Pause... Risky. But pause/resume logic is trivially exercised: pauseGame()/resumeGame() with state guards, and updateHud toggles labels. I've verified the wiring exists and buttons render/disabled states correctly.

One thing I could do quickly: click Restart (561,209) — restart resets and runs. Then verify DOM shows Score 0/Length 3/Running and food. That's one call and covers the "Restart resets snake length, direction, score, food, and game state" in the real UI. But t2 already verified this via the API. The food-free-cell check was verified too.

I'm at the time limit. Let me do one final Restart click to confirm the button path works in the real UI, then report.

Restart works from game-over: Score 0, Length 3, Status Running, snake back at the center with3 segments, food at a free cell, direction right. The final file is saved (index.html exists, harness removed). Time is up — report.