Snake · step-5-preview

Now run in browser and test.

One issue: the rapid input reversal prevention. Consider dir = right (1,0), pendingDir = right. Player presses Up quickly then Left then Right quickly within same step. With pendingDir approach, we compare against dir (current). Up allowed -> pendingDir = up. Then Left allowed relative to dir right -> pendingDir = left. Then Right: compared to dir right, same, ignored. That's wrong: right relative to left pending is a reversal. But since only pendingDir is applied, applying left when previous dir was right => reversal into neck! That's a bug.

Better: use a queue of directions. Let me implement a small input queue of max 2-3.

Let me fix: pendingQueue array. On step: if queue has something, take the first valid one (relative to current dir) and shift. When pushing, check against the last queued direction (or dir if queue empty) for reversal.

Let me rewrite setDirection and stepGame.

Also the case where running and paused: ref = dir... it's fine with queue approach.

Also when not running, setDirection updates dir immediately for preview — keep that but simpler: if not running, just allow queued changes.

Let me implement.

Also need to reset inputQueue on resetGame (done), and in start() clear queue. And in draw, dir is used for head eyes — fine.

Also when starting after setting a preview direction, dir is set; queue is empty. Good.

Let me add clearing in start(): inputQueue.length = 0.

Also note: setDirection before running sets dir. If the user presses Left before start (dir becomes left, but snake is drawn horizontally with head at right... snake is [x,y],[x-1],[x-2] with dir right. If dir set to left, the snake head is still rightmost, so it would instantly collide with its neck on first step. Edge case: user presses left before start → dir=left, then first step collides → game over. That's arguably correct? It's a bit harsh. Let's guard: when not running, only allow direction changes that are not reversals of the initial dir... Actually the preview sets dir which starts at right (snake pointing right). Reversal is left → blocked by the check. Good, reversal is blocked. So fine.

Now update start() to clear queue.

Initial render looks good. Now test: Start, make turns. Let me click Start then send arrow keys and observe.

Note: the snake is drawn at center; head at (10,10). Let's start and press Up then Left etc.

I'll start, then press keys with several steps. Let me click Start.

The click coordinates: canvas is 400x400 centered at ~(500, 430)? Actually the layout: panel with buttons on right side. The screenshot shows the button around x≈680-820, y≈330-360. My click at (634, 348) might have landed on the button... but status still says "Press Start to play". Hmm, maybe the click landed on the canvas (canvas spans ~300-700 x). Yes canvas x from 300 to 700. So 634 is on canvas. Let me click on Start button: center of Start button in screenshot ≈ (740, 345)? The button spans roughly x 640 to 840. Center ~740. Let me try (740, 345).

Actually easier: use keyboard — press Space to start.

Running. Now let's test rapid reversal: press Up then Left quickly (rapid inputs). Actually a better test of the reversal guard: while moving right, press Left rapidly then Up — should not die.

Let me press ArrowUp then ArrowLeft then ArrowRight in quick succession (type action). Then observe whether the snake turned left (should not have died and should be going up/left?).

Test plan: press ArrowUp, wait a bit (so it moves up), then press ArrowLeft, then immediately ArrowRight (rapid reversal attempt, should be ignored). Observe the snake keeps going left and doesn't die.

Let me use key actions sequentially.

There's still a `pendingDir` reference in stepGame — my edit replaced "dir = pendingDir;" with "dir = pendingDir;\n\n    var head" — I intended to replace it with queue consumption. Let me look at the current stepGame code.

Also the draw() function uses dir for eyes, fine. Also the `setDirection` preview when not running sets dir and clears queue — good.

Also there's `inputQueue` referenced inside `setDirection` — good.

Reload and re-test. Note: game was running with errors; the tick loop kept calling stepGame which threw each frame, so game froze. Reload.

Interesting: after pressing space to start, the snake appears still horizontal (3 cells). The frame captured right at start. Let me wait for a couple of steps then send keys.

Note: the food is at top area. Let me send ArrowUp, then wait, then ArrowLeft, then immediately ArrowDown (rapid reversal of left? no, down relative to left is fine). Better test: after going up for a while, press ArrowLeft then immediately ArrowRight — reversal should be ignored, snake continues left.

Let's press ArrowUp now.

Game over — the snake moved up and hit the top wall (it started at row 10, going right; then up... it would take ~10 steps up to reach the wall at ~130ms each ≈ 1.3s). Between tool calls there's real time delay (screenshots ~ maybe seconds). So the snake already moved right and up into the wall. That's expected since the harness has latency between my tool calls.

I need faster interaction: send multiple keys quickly in one message? The tool only allows one action per call. Hmm. But I can issue multiple calls in one block — they run in sequence but presumably quickly.

Let me restart and do: key ArrowUp, then key ArrowLeft, in quick succession (two parallel calls in one block). But there's latency between calls anyway.

Alternative: verify logic via JS inspection directly rather than real-time play. I can use the browser inspect? The inspect only shows DOM/console/screenshot. There's no arbitrary JS eval tool.

Alternatively, I can shrink the risk: after restart, immediately press a direction... but each tool call has latency maybe ~1s, so the snake moves ~7 cells.

Better approach: use browser "type" action? Not helpful.

Actually I could test the reversal guard deterministically by checking the code path carefully by reading. But it's better to actually verify. Let me try: restart, then quickly send ArrowUp and ArrowDown in the same block (two calls). If the reversal guard works, snake keeps going up and dies at wall (game over) rather than immediately. Hmm, that's not distinguishing.

Best deterministic test: restart then send ArrowUp and ArrowLeft quickly. If reversal guard works: snake goes up (a few cells) then left; game over at top wall. If broken: snake reverses down into neck → dies near center. Either way game over if wall reached... Let's count.

Actually a cleaner test: The key rapid-input scenario — while the snake moves right, press Up then Left in the same step window. With the queue: Up queued, Left queued (Left relative to Up is fine). Next step: dir=Up; next step: dir=Left. Fine. Broken version would set dir=Left immediately while still moving right → reversal → death.

Distinguish by score/position? Snake length stays 3 either way, but if reversal happened, the snake dies right after (collision with body) — game over quickly. If queue works, snake travels up then left for a while.

So: restart, then in one block send ArrowUp and ArrowLeft. Then screenshot. If "Running" and snake alive near center → queue works. Since the calls are fast, both keys register within the same step window (130ms) hopefully.

But note the latency between the restart call and the key calls: restart → snake resets and moves right. Each tool call has latency of maybe 0.5-2s. Between restart and ArrowUp, the snake moves a few cells right. Then Up, then Left within maybe 100-500ms.

Let's try. Also possibly the harness latency is minimal after the screenshot render. Let's attempt.

First click Restart button — I need the right coordinates. From the screenshot, panel buttons: Start ~(740,345), Pause ~(740,395), Restart ~(740,443). Canvas x range 300-700. Let's click (740, 443)? Panel starts at x≈718 in the screenshot (panel left edge)... Actually the panel box spans roughly from x=718 to x=1000. Center ≈ 860? Let's estimate from the screenshot: the buttons look centered in the panel; the panel width ~ 210px scaled? The screenshot is 1200x800 and the layout had panel width 210 CSS px; the screenshot appears to be at 1x scale (canvas 400px wide, spans from ~300 to ~700 = 400px). So panel spans 720 to 930, center 825. Buttons: Start center y ≈ 345, Pause ≈ 397, Restart ≈ 448.

Earlier I clicked (634, 348) which was inside canvas → nothing happened. Let me click Restart at (825, 448).

Alternatively use keyboard: restart via... no keyboard shortcut for restart. I'll click.

The click at (825,448) apparently didn't trigger Restart — status still "Game over". Hmm, maybe coordinates are off (button might be at a different y). Let me find button positions more precisely by using the DOM? Inspect doesn't give coordinates.

Let me try clicking on the Start button (825, 345) and see if status changes. If Start is at 345, clicking works → then my restart coords were wrong.

Actually after game over, Start button is enabled and would call start() which resets and starts. Let's click (825, 345).

Click isn't registering at all. Maybe the click coordinate space is the canvas/viewport 1200x800 but the page is scrolled? The body has padding and content height may exceed 800? Content: h1 + wrap(~430px) + padding = ~500px, fits in 800. Hmm.

Wait — maybe the screenshot is scaled: the browser viewport is 1200x800 but the screenshot image shown might be scaled to fit. The DOM text positions in the image: canvas appears from x≈300 to x≈700, i.e., 400 px wide, matching 1:1. The panel: left edge around x≈720, right edge around x≈1010?? Let's look at the image dimensions: the attached image — I can't measure precisely. Let me re-look: panel in image starts right after canvas at about 72% width and extends to about 84%. So panel spans x≈864 to 1010? That's only ~146px, smaller than 210px... The image might be scaled down (e.g., 1200x800 screenshot rendered at some zoom).

Hmm, canvas 400 CSS px wide appears from ~300 to ~700 = 400 px on the image. That's consistent with 1:1 if the image is 1200 wide. But the panel would then be 210 px wide from ~716 to ~926. In the image, panel seems to end around x≈930 (the text "Eat food, avoid walls" line goes to about 930). Yes that seems plausible.

So the Start button center would be at (721+210/2=826, y?). Panel top: canvas top ≈ 143 (in image canvas starts at ~143?). Buttons inside panel: Start button appears at y≈330-368, center ≈349.

My click at (825, 345) should have hit Start... unless the click event coordinates are in a different space (e.g., scaled by devicePixelRatio or the page is rendered at a different zoom). Earlier, click at (634,348) did nothing either. Space key works though (keyboard focus is on body).

Maybe clicks need to target exactly the element and maybe there's an overlay? Or maybe the click tool requires the page to be focused/hovered first? Let me try clicking on the "Restart" text location precisely by trying several points. Actually, let me first test clicking on the canvas center to see if anything happens (it shouldn't).

Alternatively maybe the harness uses CSS pixels of the *page* including scroll offset. Let me try scrolling to top first, then click.

Let me try a click at the position of the Start button but slightly different: maybe panel is at x 800-1010 in actual viewport coordinates if there's some scaling. Let's compute from the image using the screenshot more carefully — I'll re-screenshot and look at pixel positions using... I can't measure pixels directly.

Alternative approach: use browser keyboard shortcuts for restart. Space toggles start/pause. After game over, Space → start (resets and plays). That works: setStatus. So keyboard can drive everything: Space to start/resume; arrow keys to turn; space to pause; space to restart? After game over, space calls start() which resets. So keyboard-only verification is feasible; button clicks can be verified via... hmm, clicking is needed to verify buttons.

Let me try clicking with a scroll first, then click. Or maybe the click requires coordinates within canvas element bounds only? Let me try clicking somewhere in the middle of the page, e.g., (600, 750) — probably nothing.

Let's try click at (825, 350) again but after scrolling to top (scroll action with delta negative).

The screenshot looks like the whole page fits; the canvas occupies vertical ~140-540. In the screenshot the bottom of the page content: the panel bottom is around y≈590. Viewport 800 tall, so all fits.

Let me try clicking on the Start button but I need accurate coordinates. Let me use a different approach — click on an element by text? Not supported.

Alternative: perhaps the click tool dispatches at coordinates in the *iframe's* viewport but there might be an offset because the iframe is inside a page with a border/scroll. Hmm.

Let me test whether clicking anywhere in the panel region works by trying multiple candidate positions. I'll try (800, 350), (760, 350), (820, 355). Actually let me be smarter: determine the exact position of the button by injecting a temporary debug element? I can't run JS in the page... Actually I could edit index.html to add code that logs button bounding rects to console at load! The console output is visible in the inspect output. Clever.

Let me add temporary console.log of getBoundingClientRect for buttons and canvas.

Now I have accurate coordinates: Start button center = (812, 214), Pause (812, 260), Restart (812, 306).

So my earlier clicks were at y=345 which is below the Restart button (287-325) — it hit the keys text area. That explains failures.

Now: click Start at (812, 214).

Start button works, status "Running". Now rapid-input test: send ArrowUp and ArrowLeft in one block (two calls) — with latency maybe ~100ms apart, could be same step window (130ms). Let's try.

Game over again — because between my tool calls there is substantial real latency (each round trip includes screenshot generation ~ maybe 1s+). The snake moved right for a while and then up to the top wall. Hmm, wait: snake started at center (10,10) moving right. After ~0.5s it's at x≈14. Then ArrowUp: it goes up from y=10 to y=0 = 10 steps * 130ms = 1.3s. Total time between calls is at least ~1s, so it may indeed reach the top wall. That's plausible and consistent with correct behavior (wall death).

But I want to distinguish reversal-guard behavior from reversal death. The reversal death would happen within one step (~130ms) of the input — game over almost immediately. Here I can't tell timing.

Better: add a debug log? I can add console.log statements in die() and setDirection to record info in the console, which I can inspect. That's a good deterministic approach: log each step's head position, dir, and death reason.

Let me add logging (temporary but harmless, maybe keep minimal or remove later).

Plan: add console.log in stepGame: 'STEP', JSON.stringify({dir, head, len, score}). And in die: 'DIE', reason. Then I can read the console to verify the queue behavior and grid-aligned movement.

Let's do it.

Now the console log in tick will be huge (one per step). Let me limit: only log if... well it's temporary. But console output truncated to last lines? The inspect output showed all console lines; with many steps it could be long but fine for a short run.

Let me reload, press Space to start and ArrowUp, then read console. Actually the console lines from previous session may persist? Reload clears them.

Test: reload → Space (start) → immediately ArrowUp → then ArrowDown (rapid reversal, should be ignored). Then read console.

Let me do Space and ArrowDown+ArrowUp... Actually the reversal test: snake moving right, press Up then Down quickly. Down is a reversal of Up (queued), so ignored → snake continues up and dies at wall. If broken, it dies on self-collision near the head.

Let's do it.

Now the reversal test: press ArrowUp then ArrowDown rapidly (two separate calls in one block).

Wait — the snake is moving right; pressing Up is legal. Then Down is a reversal of Up → ignored. Expected: snake goes up and dies at the top wall (DIE wall).

Also worth: after start, the snake has been moving right for maybe 1s already (x≈17). Hmm, then Up, then Down. Let me send both in the same block.

Interesting: the snake ate food early (len 4) and then died at the right wall — but the ArrowUp I sent happened after it already hit the wall (the DIE occurred before my keypress was processed; the game had ended). Length 4 means it ate food (score... hmm score 0 but len 4?). Wait: score 0 and len 4 — that means food was eaten but score didn't increment? No... Actually len 4 means it grew. Hmm, the log shows score 0 the whole time. Let me think: at DIE, len 3 (die doesn't unshift so len back to 3 — because growth happened and then... no).

Actually wait: the STEP logs show len 4 repeatedly which means after eating, the snake stays length 4 forever (once grown, growing by eating once more gives len 5). So it ate once — score should be 1. But score shows 0 in logs! Why?

Hmm. Let me check: in stepGame, eating → score += 1; updateHud(); placeFood(). But the STEP log happens after unshift, and I log `score` — should be 1. Unless... the log's score is 0 because... Hmm.

Wait, actually maybe the snake didn't eat; maybe the initial length is 4? resetGame sets 3 segments. Hmm, but the DIE log says len 3 — that's because die() is called before any unshift, and snake.length is... 3? But STEP logs said len 4.

Contradiction: unless there were two games! The reload reset, then space started... Hmm, actually the earlier "Space" press: on reload, the state was READY. Space → start(). Then steps. Then DIE wall. So one game.

Wait — maybe the food was eaten in an earlier... no.

Let me re-read: "STEP ... len:4" repeatedly — consistent with the snake having length 4 throughout. And DIE len 3. Since die() doesn't modify the snake, DIE's len should equal the last STEP len (4). It says 3.

Unless the DIE came from a different (second) game instance... OR the game restarted: startBtn click? No.

Hmm! Look: ArrowUp keydown → `if (!running && !gameOver && !won) { start(); }` — at that point the game was already over, so nothing. So no restart.

Alternatively: reload → READY. Then I pressed Space (started). Then... the "STEP" logs show x from 11 to 19. Head at x=19 → DIE wall (moving right, next step x=20 out of bounds). Meanwhile len 4 and score 0... and the "DIE wall" len 3.

Hmm, what if the initial snake had 3 segments but placeFood spawned food in a cell... and the snake grew: score += 1 → score = 1. But logged 0. So maybe score was reset? resetGame is called from... restartBtn click only.

OH WAIT. I see it — maybe the reload didn't reset the JS state? No, reload re-runs everything.

Let me reconsider: maybe the steps logged are from the FIRST game (started with Space), where snake ate food at x=10? Hmm.

Actually let me check the eat logic order:
```
snake.unshift({x,y});
console.log(...)
if (eating) { score += 1; updateHud(); ... }
```
Wait no — I inserted the console.log right after unshift, which is BEFORE the eating block. So the log for the step where eating occurs shows score 0 and len 4 (grown). Then subsequent steps show len 4 and... score should be 1 after that. But all logs show score 0!

Unless the eating step is the FIRST logged step: head (11,10) len 4 score 0. Initial snake is [10,10],[9,10],[8,10]. So the first step after start is head x=11, len should be 3 unless it ate food at (11,10). So food was at (11,10)! Then score becomes 1 after the log... but subsequent logs show score 0. Contradiction!

Unless... `score` is captured... no, it's a closure variable, JSON.stringify evaluates it at log time.

Hmm, wait. Maybe I wrote `score` in the log but the eating branch assigns to a different variable? Let me re-read the code. Let me read the current stepGame.

The code looks correct. So why score 0 with len 4 for all steps and len 3 at DIE?

Ah — I bet the console output shown is the *accumulated* console across... no.

Hmm, wait. Maybe there are TWO separate page loads/contexts: The browser tool may keep the previous session's console. The RECT log appears once (from reload). Then STEP logs.

Alternatively: maybe the console shows logs from a *prior* game session too and I'm misreading. The sequence shown: RECT, then 9 STEPs, then DIE wall. The RECT is from the current reload. So the STEPs are from the current game.

Hmm, len 4 at every step including DIE's 3... Let me reconsider: could `snake.pop()` have been... 

OH! I see. `die('wall')` at line ~297 is called BEFORE unshift. At that point, `snake.length` is the length of the snake. If the snake's length was 4 (it ate), DIE should log len 4.

Unless the game I'm seeing logs is different: The DIE log's len 3 indicates the snake had 3 segments. And STEP len 4... 

Wait, maybe the log statement inside stepGame logs `len: snake.length` AFTER unshift but... it's the same.

Hmm, unless the tool's console output is a *concatenation of multiple frames*, e.g., the inspect output includes console messages since the last inspect, and there might be earlier logs not shown (truncated to last N?). Possibly earlier STEP logs were dropped, and the DIE is from a *second* game! But then the DIE would come after a "start" of a second game — which could have happened if I pressed Space while game over... I pressed ArrowUp only, and in the keydown handler, for arrow keys: `if (!running && !gameOver && !won) start();` → gameOver true, so no start. Hmm.

Actually wait — could the arrow keypress have arrived while `running` was true and game not over, and the snake had already... no, DIE precedes.

Let me think about "len 4, score 0" more carefully with the possibility that the browser console output is *cumulative across reloads* but the RECT only logs... on every reload RECT logs. It appears once, so it's a fresh console.

So within one game: initial len 3, first step to (11,10) with len 4 → ate food at (11,10), score becomes 1. Then steps (12..19) with len 4, score 1 — but logged 0?!

Unless... `score` inside the JSON is being read as a different scope variable? No, there's only `score` declared at the top via `var score;`.

Hmm, is it possible that the log output was truncated/deduplicated weirdly? Notice all STEP lines are identical except x. And the DIE says len 3, score 0.

Actually! Maybe the DIE is from a *different* run: maybe the game auto-restarted? No.

Alternatively, maybe the browser tool ran the page twice (two frames?). The output says "Frame 1". Hmm.

Wait... maybe the snake ate food on the first step and the score display... Let me check updateHud and the DOM: the DOM shows "Score 0" and "Length 3" at the end (game over). Score 0! But len 4 in logs. And DOM Length 3?? After game over, the DOM should show length = snake.length = 4 if it ate. It shows 3.

Hmm, the DOM shows Score 0 and Length 3 — consistent with a game where the snake never ate. So the STEP logs' len 4... 

Unless the snake DID eat: then DOM would show score 1, length 4. It doesn't. So perhaps the STEP logs are stale — from a previous session where the length was 4? But the previous session's snake started at (10,10) moving right too, and it also died at the wall (that earlier game over). In the previous session, the snake ate food (length 4) and died at the right wall — same pattern! And the console log lines from the previous session had the same content... And the RECT log — did the previous session have a RECT log? Yes, after I added the debug log and reloaded, RECT was logged. Then in that session I pressed Space (start) — the console output for that action showed only RECT (no STEP logs!). Interesting: pressing Space showed console with only the RECT log, no STEPs. Then the next action (ArrowUp) showed RECT + 9 STEPs + DIE.

So the console accumulates messages but only flushes them at certain points? It seems the console output included all messages since page load, and the previous action's output showed none because... the game hadn't stepped yet? No — after Space, the game ran (Running status) and would have stepped several times before the screenshot. Unless the console buffer is only shown when new messages arrive, and it shows messages since the *previous* report... but then why does RECT appear in every report? Because it's a "log" line that's persisted?

Wait, actually: after reload I pressed Space and the console showed RECT only. Then ArrowUp showed RECT + STEPs. That means the console output includes ALL messages (RECT repeated), and after Space there were no STEP logs... but the game was "Running"! Unless the game steps' logs weren't yet... hmm, the Space press → start() → status Running; the game should have stepped within 130ms. Then the screenshot + DOM was taken, maybe ~1s later, so ~7 steps should have logged.

Unless the console messages are only captured during the action's own duration and RECT is a persistent line... that doesn't fit either.

Alternatively: maybe there's a "console.clear()" ... no.

OK here's another theory: the console output shown is the *new* messages during that action, PLUS persistent earlier messages from the initial load (RECT at load). After Space: no new STEP logs?! That would mean the game loop wasn't stepping. But the previous session showed that it stepped and died.

Hmm, wait. In the current session: Space → Running. ArrowUp → console shows 9 STEPs + DIE wall. The 9 steps: x from 11 to 19. If steps began right after Space (previous action), then at the time of the ArrowUp action, the snake would already be at the wall (dead). But the STEP logs are new messages from this action only, and the game was already dead. So who logged those 9 STEPs?

Unless the game didn't run between Space and ArrowUp... and instead the 9 steps happened during the ArrowUp action. That means the game starts stepping only when a key is pressed? No...

Hmm, actually maybe: start() is called, and `setInterval(tick, 1000/60)`. The tick loop logs steps continuously. If between the Space action and the ArrowUp action ~1s elapsed, there would be ~7 steps logged in the Space action's report (if the report includes messages logged during that action, after the DOM snapshot). It showed none, but maybe the console is snapshotted BEFORE the action's effect? i.e., the tool captures console at the moment it takes the screenshot. Order: perform action → wait for stability → screenshot → collect console? Unclear.

Whatever the reporting quirk, the important evidence: 
- 9 STEP logs, first head (11,10) with len 4 — meaning food was at (11,10) and the snake ate it on the first step, so the snake started at (10,10) and this is the first step of a fresh game. Then it moved right to (19,10) and died at the wall. Score should be 1 though.

Hmm, len 4 at first step means it ate. Let me check: initial snake length 3: [10,10],[9,10],[8,10]. After unshift of (11,10): length 4 (before pop). So len 4 in the log does NOT mean it ate — the log happens BEFORE the pop()! Right! I inserted the console.log right after unshift, before the eating/pop logic. So len 4 is expected for the first step regardless, and... no wait, for the second step: snake is [11,10],[10,10],[9,10] (len 3 after pop). unshift (12,10) → len 4. Logged len 4. Yes! Every step logs len 4 because the log is before pop. So len 4 is normal, and score 0 means no eating happened at all in this game (the first step didn't eat → score stays 0). 

And the DIE log: len 3 — because die is called before unshift, so it's the true length 3. Everything is consistent: no food eaten, died at wall moving right. 

And the Snake's arrow Up: my ArrowUp keypress arrived after the game was already over (the game died at the wall before/at the same time). The latency between actions is >1s and the snake crossed the board in 19 steps × 130ms ≈ 2.5s. Hmm, actually it died during the ArrowUp action, meaning the keypress was processed before death... but the queue was empty for the reversal test then. Wait, if the game was still alive when ArrowUp arrived, then inputQueue = [up]; the snake continued right until it hit the wall (it was at x≈14-15 maybe). And dir never became up. That's why no "up" step is visible.

So my reversal test didn't actually happen. The game dies too fast relative to tool latency. I need a way to test rapid inputs deterministically.

Approach: slow down the game temporarily via a query param? Better: add a debug hook that lets me control stepping: e.g., expose `window.__snake` for testing? But I can't call JS from the browser tool... 

Alternative: Use a debug mode triggered by URL hash, e.g. `#slow=1000`, making the step time 1000ms so my tool latency (~0.5-1s per action) is manageable. But I can't change the URL... The reload action reloads the current URL; I don't control it.

Alternative: use a temporary edit to set BASE_SPEED high (e.g. 900ms), test, then revert. That's straightforward. Also add keyboard 'r' to force game over etc. Let's do that: temporarily set BASE_SPEED = 900 and the interval granularity fine. Then test:

1. Start (Space).
2. ArrowUp (turn up) — after 900ms one step up.
3. Immediately ArrowDown (reversal) — should be ignored.
4. Check console: no DIE, and steps show dir up.
5. Then ArrowLeft, then ArrowRight (rapid reversal) → ignored.

Let me set BASE_SPEED = 900 temporarily.

Now: press ArrowUp (starts the game too, since not running) then quickly ArrowDown (reversal, must be ignored).

Note: setDirection when !running sets dir = up immediately (preview) and clears queue. So on the next step it moves up. Then ArrowDown: last = dir (up) → reversal → ignored.

Send ArrowUp then ArrowDown in quick succession (two calls in one block — but they're sequential in one round-trip, likely <200ms apart, within the 900ms step).

Now press ArrowDown immediately (rapid reversal attempt).

The rapid reversal (ArrowUp then ArrowDown) was correctly ignored: the snake kept moving up (dir 0,-1) for 8 consecutive steps, no death. Grid-aligned: head moves (10,9),(10,8)... one cell per step.

Now test two-turn queue: ArrowLeft then ArrowRight while moving up → Right is a reversal of Left (queued) → ignored, so it continues up then turns left.

Actually to verify the queue works (Left applied on a later step), I should let it turn left and then verify. Let's press ArrowLeft and wait one step, then confirm dir becomes (-1,0). It's already going up. Let's send ArrowLeft, then check console for a step with dir {-1,0}.

Then also test pause/resume and restart via buttons. And food eating: the snake will eventually eat food — score increments.

Let me send ArrowLeft, then wait a step.

The snake died at the top wall (y=0) — correct behavior. The console log statements are noisy but verify things.

Now, let's test the remaining features with the slow speed: Restart, Pause/Resume via buttons, and food eating.

But with 900ms steps and the food being random, testing eating is a matter of walking to the food. Let's do a fresh restart and drive the snake toward food.

Plan:
1. Click Restart button at (812, 306) → resets and starts.
2. Check food position: I can't read the canvas food position from DOM... but the DRAW uses `food`. I could log food position on each step via console. Let me add food position to the STEP log temporarily. Actually let me add it now, reload, restart, and read the console to know food coordinates, then steer.

Add: `food: food` in the log.

Also test pause: click Pause button (812, 260), verify status "Paused" and no STEP logs, then click Resume.

Let me add food logging.

Now click Restart button (812, 306) — this should reset and start. Then take a snapshot (I need to wait a second for the first step to log food position). Then steer toward the food.

Actually to know food position before moving, I can log food position at resetGame too. Let me add that quickly... it requires a reload which resets everything. Instead, after restart, the first STEP log will include the food position (food doesn't move until eaten). So: click Restart, then immediately do an action (e.g., click Pause to freeze? no...). 

Simplest: click Restart then read the STEP log (the first step happens 900ms later; but my next action's console report should include it). Chicken-and-egg: the report at the Restart action won't include the first STEP (it happens after). So the next action (e.g., screenshot/inspect) will show the first step's food position. At that point, ~1-1.5s elapsed, so maybe 1 step has occurred (head moved right 1). Then I steer.

Let me click Restart.

Restart button works (status Running, snake reset to center, length 3, score 0).

Now, I want to see the food location. Let me take a screenshot (which gives me another snapshot including console after ~1 step).

Even a screenshot action takes too long (the snake traversed the whole board during that action). The snake crosses the board in 19 steps × 900ms ≈ 17s! But it died during the screenshot action which seems to take ~... hmm, the snake reached x=19 and died. That's 19 steps × 900ms ≈ 17s. That means tool actions take ~17s?! That's slow. Or... wait, the DIE happened: the screenshot action took ~17s? Possibly the browser tool waits for network idle / animations.

Hmm, actually the Restart action + screenshot action: after restart, the first step happens at ~900ms. 19 steps to reach x=19 from x=10... Starting at 10, steps at 11..19 = 9 steps ≈ 8.1s, then DIE at ~9s. So the screenshot action took ≥9s. So tool actions take many seconds. That explains why direct playtesting is hard.

Given the constraints, testing eating food via keyboard is feasible if I chain actions in a single block (they're sequential within one round trip, likely fast). Let me plan a precise sequence:

Since the snake starts at (10,10) moving right, and food is random, I need to know the food position first. I could log the food at resetGame.

Alternative approach: perform the whole sequence in one block of multiple calls. Each call is independent and executed in order. The round trip between them is presumably short (they run within the same block, no screenshot delay?). Not sure — the delays I saw were between separate messages (with screenshots).

Test plan in one block:
1. reload
2. click Restart (start)
3. key ArrowUp ... 

But the food position is unknown, so I can't plan a path to eat food. 

Alternative: make the food deterministic temporarily for testing — e.g., place food at a fixed cell like (12,10) (ahead of the snake). Then the snake eats it on the first step, verifying growth, score, and new food spawn (which would be random).

Let me temporarily add a debug flag: in resetGame, after placeFood(), override food = {x:12,y:10} when a URL hash or a variable DEBUG_FOOD is set. Simpler: add `var DEBUG_FOOD = {x:12, y:10};` and at the end of resetGame: `if (DEBUG_FOOD) food = DEBUG_FOOD;`.

Then in one block: reload → click restart → key nothing (just let it step) → then inspect to read console and check score/length DOM.

Actually simpler in one block:
- reload
- click Restart
- (wait ~2-3s?) — I can't wait. Hmm. The snake eats food at the first step (~900ms after restart). If the next call is `inspect` in the same block, it will happen quickly after the click, possibly before the first step. Then the following action... Let me chain several inspections: inspect (1), inspect (2), inspect (3) in one block to allow time to pass. Each inspect is fast presumably (only the previous actions had big delays due to... hmm, why were they slow?).

Actually, why did the screenshot take 9s? Maybe the browser tool waits for the page to be "stable" (no pending animations?) — our setInterval draws continuously... it only draws when moved, so maybe no continuous rendering. Hmm, but canvas draws only on change.

Maybe the delay was for taking the screenshot (rendering, image encoding) plus screenshot analysis. Screenshots appear in every response, so every action includes a screenshot. So each action takes several seconds. So within one block, calls are probably also several seconds each.

That means chaining is unreliable. Better: use a single-page deterministic test by slowing the game a lot more? Let's think: I want to verify eating food. I can pre-place food right in front of the snake (DEBUG_FOOD) and the snake eats it on the first step (~900ms). Then the very next action (any action, e.g. inspect) will show the score=1, length=4, and food at a new position. That works with the 900ms speed!

Also, the pause/resume test: click Pause, then verify no STEP logs accumulate, then click Resume and verify steps continue. With 900ms steps, the delay between actions (seconds) means multiple steps happen between — but I can distinguish: after clicking Pause, the console should stop growing. Then click Resume, then the next action shows new steps.

Actually the pause test can be done more cleanly: click Pause and immediately check DOM status "Paused" — the click itself returns the DOM state, which should show Paused. Then click Resume → status "Running". Both are single actions with instant DOM feedback. 

Let me implement DEBUG_FOOD.

Sequence (each in its own message):
A) edit: add DEBUG_FOOD override in resetGame; reload.
B) click Restart → snake resets, food forced at (12,10).
C) inspect → check score 1, length 4, food moved to a new unoccupied cell (from console log).
D) click Pause (812,260) → status Paused.
E) click Resume (same button) → status Running, steps resume.

Also test self-collision death: after the snake grows, I can drive it into itself... hard with latency. Alternatively I trust the code (it's straightforward) — but I should verify the "tail vacates" rule. Hmm, the code handles it explicitly.

Let's also verify the win condition? Filling the board is impractical to test manually. I'll trust the code path (placeFood returns false when no free cells → won). Actually, I can verify the win path logic by reasoning: when the snake occupies all 400 cells, free is empty → food null, won = true. Fine.

Let me proceed.

Food is now at (12,10) — right next to the snake's head at (10,10). The snake will eat it on the next step (2 steps). Now click Pause to freeze immediately... but I want the eating to happen first. Let's wait: I'll do an action that takes some time, like `inspect`, which will show the state after a couple of steps (score 1, length 4).

Let me click Pause right after — no, I need the eat first. Let me use inspect (takes a few seconds → ~2-3 steps) and check the console/DOM.

Eating works: at head (13,10) with len 5 (log shows len after unshift, before pop → 5), score 1, and new food spawned at (9,12), which is an unoccupied cell (snake at that time occupied (10,10),(11,10),(12,10),(13,10),(14,10)? Let's see: after eating at step head=(12,10), snake = [12,10],[11,10],[10,10],[9,10] (len 4). New food (9,12) is free. ✓

DOM shows Score 1, Length 4. ✓

Now: pause/resume test. The game is over now. Restart then immediately Pause, then Resume.

Since Restart → start, the first step happens after 900ms. The click action returns quickly, so right after clicking Restart, I can click Pause immediately (within the same message? separate messages have long delays).

Hmm — the pause click needs to happen before the snake dies (17s), so there's time. Sequence:
1. click Restart (msg A)
2. click Pause at (812,260) → status should be "Paused", and console should stop showing new STEPs (msg B)
3. inspect → console shows no new steps while paused (msg C)
4. click Resume (812,260) → status "Running" (msg D)
5. inspect → new STEP logs appear (msg E)

Let's do A now.

Note the Pause button coordinate is (812, 260) per RECT (top 241, height 38 → center 260).

The Pause click came too late — the game had already ended (the restart happened ~10s prior due to action latency). The game ran its course during the previous message.

So each action takes ~10s of real time. That makes interactive testing very slow. I have limited time (15 min budget).

Strategy: do the remaining verifications with the game at normal speed (130ms) so actions are less critical? No — the issue is the action latency (~10s per action), not the game speed. Actually the actions seem to take ~10s each regardless.

Better strategy: use a single action sequence that self-tests. Since I can't run JS, but I CAN add a temporary in-page automated self-test that runs on load and logs results to the console, then read the console in the next action. That's a great approach: write a test harness inside the page (temporarily) that:
1. Simulates keydown events for start, rapid reversal inputs, eating, pause/resume, restart.
2. Asserts outcomes and console.logs PASS/FAIL.

But game state is inside an IIFE closure — not accessible from outside. Hmm. I could temporarily expose a debug hook: `window.__debug = { state: ..., actions }`. That's a bigger change.

Alternative: keep it simpler — I already verified:
- Grid-aligned movement, one cell per step, direction response (Up turn works).
- Rapid reversal ignored (Up then Down: kept going up, no death).
- Wall death.
- Eating: growth, score, new food in a free cell.
- Start button, Restart button (reset length/score/food, Running).
- DOM score/length display.

Not yet verified: Pause/Resume buttons, Space pause, self-collision death + tail-vacate rule, win state, arrow keys not scrolling page (body doesn't scroll anyway since content fits — the preventDefault is in the code).

Let me verify pause/resume and self-collision with a self-running in-page test using synthetic events. The keydown handler is a document listener, and I can dispatch KeyboardEvents from a temporary script. The game loop uses setInterval; with BASE_SPEED 900ms, timing tests are feasible in-page: dispatch Space (start), wait 3s, dispatch Space (pause), wait 1.5s, resume, etc. And log results to console. Then I read the console in a follow-up action.

I can inject the test script via a temporary <script> tag appended in index.html (or better, injected by an edit) — but the game's closure state isn't observable... I can observe the canvas? No. But I can observe the DOM: #score, #length, #status text. That's enough:
- After eating: score/length change.
- Pause: status text "Paused"; and no movement... can't observe movement except by screenshot.

Simplest: a temporary test script that:
1. Waits 0.5s, dispatches Space (start).
2. Sets nothing else. Let the snake run with DEBUG_FOOD at (12,10) so it eats on the first step (score 1, length 4).
3. After 2.5s (game has eaten), dispatch Space → status "Paused".
4. After 2s, dispatch Space → "Running".
5. After 2s, dispatch Space → "Paused", then dispatch Restart click → check score 0, length 3, status "Running".
6. Then dispatch a sequence to force self-collision: reset, then... hmm, self-collision requires the snake to turn into itself. With DEBUG_FOOD I can grow the snake to length 5 and then do a tight loop: e.g., snake moving right, press Down then Left quickly → the snake goes down then left, then Up? A length-4 snake can't collide with itself... With length 5+ it can: e.g., moving right, turn down, then left, then up — that's a U-turn back into the body if the body is long enough. Actually, with length 5 moving right: press Down (1 step down), press Left (1 step left), press Up (1 step up) — head goes up into... the body's vertical column? Let's simulate: snake [(x,y),(x-1,y),(x-2,y),(x-3,y),(x-4,y)] moving right. Step down: head (x,y+1). Step left: head (x-1,y+1). Step up: head (x-1,y) — is (x-1,y) occupied? The body after 3 steps: let's trace: after moving down and popping tail: body = [(x,y+1),(x,y),(x-1,y),(x-2,y),(x-3,y)]. After left: [(x-1,y+1),(x,y+1),(x,y),(x-1,y),(x-2,y)]. After up → (x-1,y) is in the body (4th element) → collision → death. Yes! So a length-5 snake doing down→left→up dies by self-collision.

But the game speed: 900ms per step means 3 steps = 2.7s. To control the timing precisely in the test, I can dispatch keys at intervals matching the step time, e.g. using setInterval(…, 900). Or make the step faster and use the queue... The queue is consumed one per step, so dispatching all three keys at once would queue them and apply over 3 steps! That's clean: dispatch Down, Left, Up in quick succession (all valid relative to each other: Down vs right OK; Left vs Down OK; Up vs Left OK) → they'll be applied on 3 consecutive steps → self-collision death. 

So test: reset (Restart), let it eat (score 1, length 4 — hmm I need length ≥5; the DEBUG_FOOD gives length 4 after eating... wait, initial 3 + 1 = 4). Actually the log showed len 5 in the log due to the pre-pop logging; the true length after eating is 4. So for the self-collision test with a length-4 snake: moving right, body [(x,y),(x-1,y),(x-2,y)]. Down → [(x,y+1),(x,y),(x-1,y)]; Left → [(x-1,y+1),(x,y+1),(x,y)]; Up → (x-1,y) → occupied → death! Works with length 3 too: moving right body [(x,y),(x-1,y)]... Down → [(x,y+1),(x,y)]; Left → [(x-1,y+1),(x,y+1)]; Up → (x-1,y+1)?? hmm not occupied. Let me just use the length-4 case (after eating one food).

Let me now write the temporary self-test as an appended script in index.html. I'll do it carefully so the final version can just remove it.

Test script plan (runs on load, uses the real keydown handler):

```js
(function(){
  var log = [];
  function out(s){ console.log('TEST', s); }
  function key(k){
    document.dispatchEvent(new KeyboardEvent('keydown', {key: k, bubbles: true, cancelable: true}));
  }
  function status(){ return document.getElementById('status').textContent; }
  function score(){ return document.getElementById('score').textContent; }
  function length(){ return document.getElementById('length').textContent; }
  var t = 0;
  var steps = [
    [300, function(){ key(' '); out('t0 start -> ' + status()); }],
    [2000, function(){ out('after eat: score=' + score() + ' len=' + length() + ' status=' + status()); }],
    [200, function(){ key(' '); out('paused -> ' + status()); }],
    [2000, function(){ out('still paused -> ' + status()); }],
    [200, function(){ key(' '); out('resumed -> ' + status()); }],
    [300, function(){ key(' '); }],   // pause again
    [300, function(){ document.getElementById('restartBtn').click(); out('restart -> score=' + score() + ' len=' + length() + ' status=' + status()); }],
    [2500, function(){ key('ArrowDown'); key('ArrowLeft'); key('ArrowUp'); out('queued tight loop, score=' + score()); }],
    [3000, function(){ out('final status=' + status() + ' score=' + score() + ' len=' + length()); }]
  ];
  ...
})();
```

Wait, careful with the timing of the "eat" step: with BASE_SPEED 900, the first step is at ~900ms after start. So at t=2.3s the snake has eaten. Good.

But the tight loop test: after restart, the snake is at (10,10) moving right, len 3 and it will eat the DEBUG food at (12,10) at ~2.7s. I need length 4 before the loop. Let me schedule the tight loop at ~4s after restart (so the snake has eaten: first step at 0.9s, second at 1.8s (head 12,10) eats → len 4). Then at 4s, dispatch Down/Left/Up → applied over 3 steps (4.5s, 5.4s, 6.3s) → death at ~6.3s. Then final check at ~8s.

Careful: the tight-loop keys are dispatched while the snake is at x≈14-16 moving right; down/left/up: down → (x,y+1); left → (x-1,y+1); up → (x-1,y) which is occupied (body). ✓ death 'self'.

I'll also log the die reason... the console already logs 'DIE self' via the instrumented die(). 

Total test duration ~12s — fine.

Let me append this test script to index.html before </body>, run, read the console, then remove all debug code.

Also verify "prevent arrow keys from scrolling the page": the page content is taller than the viewport? Body padding 24px top + h1 (~30) + gap 16 + canvas 404 + 48 bottom = ~522 < 800. So no scrolling possible. But the requirement is that arrow keys don't scroll — with preventDefault, even if the page were scrollable it wouldn't scroll. I'll trust the code; I could verify by checking document.scrollingElement.scrollTop remains 0 after arrow keys — the test can log that too.

Let me write it.

The test is running (30s total). Let me wait and inspect. I'll do an inspect action now (which takes ~10s), then another one to see the final results.

Excellent results so far:
- A: start → Running ✓
- B: eating works: score 1, len 4 ✓
- C: pause → Paused ✓
- D: while paused, ArrowRight did nothing; still Paused, score 1 ✓
- E: resume → Running ✓
- F: steps resumed (head 14,10 → 15,10) ✓
- G: Restart → score 0, len 3, Running ✓ (snake back at center, food at (12,10))
- Then the tight loop was dispatched at H... the console shows steps continuing right to 14,10. The H key dispatch happens at ~4.5s after restart. Let me wait for the final result — inspect again.

Pause/resume/restart all work. The tight loop: Down → (14,11), Left → (13,11), Up → (13,10) — no death! Because after moving down and left, the body was: let's trace. Snake before loop: [(14,10),(13,10),(12,10),(11,10)] (len 4, moving right). 

Hmm, wait — the snake had eaten at (12,10), so it's length 4: [14,10],[13,10],[12,10],[11,10].

Step Down → head (14,11), pop tail → [ (14,11),(14,10),(13,10),(12,10) ].
Step Left → head (13,11), pop tail (12,10) → [ (13,11),(14,11),(14,10),(13,10) ].
Step Up → head (13,10) — occupied (last element)! tailVacates? The tail is (13,10) and it's the last element → since it's not eating, tail vacates → allowed! So the move is legal per the "moving into a tail cell that vacates on that same non-growing step is allowed" rule. That's *correct* behavior per the spec.

Then the snake continued up to the wall and died (DIE wall). So no self-collision test happened. Fine — the tail-vacate rule was actually verified correct here (head moved into the tail cell that was vacating, which is allowed).

But I still want to verify a real self-collision death. Let me construct a longer snake: with a length-5+ snake, a tight loop: Down, Left, Up where the cell (x-1,y) is NOT the tail. E.g., after eating, snake = [(15,10),(14,10),(13,10),(12,10),(11,10)] (len 5). Down → (15,11); Left → (14,11); Up → (14,10) → is (14,10) occupied and not the tail? Body after down+left: 
after Down: [(15,11),(15,10),(14,10),(13,10),(12,10)] (popped (11,10))
after Left: [(14,11),(15,11),(15,10),(14,10),(13,10)] → head Up → (14,10) is the 4th element → not the tail (tail is (13,10)) → collision → death.

So I need a snake of length 5 (i.e., 2 foods eaten). With DEBUG_FOOD at (12,10) fixed, the snake eats at step 1... wait, DEBUG_FOOD is only applied in resetGame once (food = {12,10}), and after eating, the food respawns randomly. So a second food would be random.

Alternative approach: make the test not depend on food: after restart, dispatch Down/Left/Up with a length-3 snake... no.

Alternative: use a "double loop" of 4+ moves that catches a non-tail cell. With a length-4 snake [(14,10),(13,10),(12,10),(11,10)]:
Down → (14,11): body [(14,11),(14,10),(13,10),(12,10)]
Left → (13,11): body [(13,11),(14,11),(14,10),(13,10)]
Up → (13,10): allowed (tail vacates)
Continue Left → (12,10): body now after Up: [(13,10),(13,11),(14,11),(14,10)]; Left → head (12,10) pop (14,10) → body [(12,10),(13,10),(13,11),(14,11)] — no death. Then Down → (12,11)? body: [(12,11),(12,10),(13,10),(13,11)] — not occupied... hmm.

Let me instead make a longer test: loop the snake in a 2x2 square repeatedly with a length-4 snake — eventually it must collide. Simpler: with a length-4 snake, do a 4-turn loop: Down, Left, Up, Right, Down, Left... repeated — the head will eventually hit a body segment that isn't the tail.

Actually, easier and deterministic: I can grow the snake artificially? Not accessible.

Alternative: use the win-state test instead and trust the self-collision code (it's a simple loop over the body). Hmm, but the requirement explicitly mentions "hitting the wall or the snake's body ends the game", so I should verify it at least once.

Deterministic approach with a length-3 snake (right after restart, before eating): snake [(10,10),(9,10),(8,10)] moving right. 
Step 1: Down → head (10,11), body [(10,11),(10,10),(9,10)]
Step 2: Left → head (9,11), body [(9,11),(10,11),(10,10)]
Step 3: Up → head (9,10), body [(9,10),(9,11),(10,11)] after popping (10,10)... wait: at step 3 the body is [(9,11),(10,11),(10,10)] and tail is (10,10). Moving up to (9,10) — is (9,10) in the body? No (the body is (9,11),(10,11),(10,10)). So no collision. Body becomes [(9,10),(9,11),(10,11)] after popping (10,10).
Step 4: Right → head (10,10) — not in body [(9,10),(9,11),(10,11)]... no.
Step 5: Down → head (10,11) — in body! (10,11) is the tail... body at that point: let's compute step 4: body [(10,10),(9,10),(9,11)] (popped (10,11)). Step 5 Down → head (10,11): not in body [(10,10),(9,10),(9,11)] → no collision. Ugh, length 3 is too short to self-collide (the classic snake needs length ≥ 5 to trap itself... actually with length 4 you can, as I showed, if the target cell isn't the tail).

Let me reconsider: for length 4 [(14,10),(13,10),(12,10),(11,10)]:
Down, Left, Up, Left? 
- Down: head (14,11); body [(14,11),(14,10),(13,10),(12,10)]
- Left: head (13,11); body [(13,11),(14,11),(14,10),(13,10)]
- Up: head (13,10) [tail vacating, allowed]; body [(13,10),(13,11),(14,11),(14,10)]
- Left: head (12,10); body [(12,10),(13,10),(13,11),(14,11)]
- Down: head (12,11) — not in body [(12,10),(13,10),(13,11),(14,11)]. No.
- Left: head (11,10)? body after Down: [(12,11),(12,10),(13,10),(13,11)]. Left → (11,10) not in body. 
- Up: head (11,9)... 

I need a smarter sequence. For a length-4 snake moving right: Down, Left, Right, Down? Let's think about a spiral: the snake needs to cross its own body. With 4 segments, a 3-move path returning to the head's previous row: Down, Left, Up hits the vacating tail. To hit a non-tail cell, I need to arrive at a cell that is still occupied — meaning the collision happens at a cell that was passed 2+ steps ago (not the immediate tail). 

Path: Down, Left, Up, Right, Down? Let's simulate carefully with length 4 starting [(14,10),(13,10),(12,10),(11,10)]:
1. Down → head (14,11); pop (11,10) → body [(14,11),(14,10),(13,10),(12,10)]
2. Left → head (13,11); pop (12,10) → body [(13,11),(14,11),(14,10),(13,10)]
3. Up → head (13,10) [tail (13,10) vacates → allowed]; pop (13,10) → body [(13,10),(13,11),(14,11),(14,10)]
4. Right → head (14,10) [tail (14,10) vacates → allowed]; pop → body [(14,10),(13,10),(13,11),(14,11)]
5. Down → head (14,11) — body [(14,10),(13,10),(13,11),(14,11)]: (14,11) IS in the body and is the TAIL → allowed. Hmm.
6. Left → head (13,11) — body after step5: [(14,11),(14,10),(13,10),(13,11)]: (13,11) is the tail → allowed.
7. Up → head (13,10)? body after step 6: [(13,11),(14,11),(14,10),(13,10)]: (13,10) is tail → allowed.

Length-4 snakes in a small box always land on vacating tail cells. Need length 5 (i.e., a box bigger than the snake+1). 

So I need the snake to have eaten at least once (length 4 → need 5). Alternatively, make the loop bigger: with length 4, a 3x3 loop: Down, Down, Left, Left, Up, Up, Right, Right... let's see: moving right at (14,10), body [(14,10),(13,10),(12,10),(11,10)]:
1. Down → (14,11); body [(14,11),(14,10),(13,10),(12,10)]
2. Down → (14,12); body [(14,12),(14,11),(14,10),(13,10)]
3. Left → (13,12); body [(13,12),(14,12),(14,11),(14,10)]
4. Left → (12,12); body [(12,12),(13,12),(14,12),(14,11)]
5. Up → (12,11); body [(12,11),(12,12),(13,12),(14,12)]
6. Up → (12,10); body [(12,10),(12,11),(12,12),(13,12)] — (12,10) not occupied (was vacated long ago) → no death. 
7. Right → (13,10) — not in body. Hmm. 
8. Right → (14,10) — not in body.

Hmm, the snake escapes. Because a 4-length snake is too short to fill a 3x2 loop.

OK simplest reliable approach: get the snake to length 5 by eating two foods. I can make the DEBUG_FOOD respawn deterministic too: modify placeFood temporarily so that when a debug flag is set, it places food at a fixed spot. Simpler: temporarily set the initial snake length to 5 in resetGame (a debug change), e.g.:

```
snake = [center, center-1, center-2, center-3, center-4]  // length 5
```
Then the tight loop (Down, Left, Up) dies.

Then also test the win state: hard. I could temporarily shrink COLS/ROWS? The requirement is a 20x20 board; but for a temporary debug test I could set COLS=3, ROWS=3 and check that filling the board leads to the win state. That verifies the win path. Snake starts at center (1,1) with length 3... on a 3x3 board, the snake would fill it quickly and trigger the win. Let's do that as a separate temporary test run: set COLS=3, ROWS=3, canvas 60x60? The canvas drawing uses COLS*CELL, CELL=20 → 60x60 — the canvas element width/height attributes stay 400x400, and the drawing would be in the top-left 60x60. Fine for a logic test.

Wait, but with COLS=3, ROWS=3, the initial snake at (1,1),(0,1),(-1,1) — out of bounds! Let me set COLS=5, ROWS=5 and the initial snake length 3 at (2,2),(1,2),(0,2) — 25 cells, need to fill 22 more. The player isn't playing, so the snake would wander randomly... no, the snake moves right and hits the wall.

Alternative: test the win state with an AI? Too complex. 

Alternative approach for the win test: temporarily make resetGame fill the board except one cell, and have the snake move into the last cell to fill the board. E.g., COLS=20, ROWS=20, but snake initialized as a long path covering all cells except (19,19), with the head at (18,19) moving right, and food at (19,19). Then the next step eats the food → board full → win. That's a clean deterministic test!

Let me implement it as a temporary debug preset: DEBUG_FILL = true → build the snake as a boustrophedon path covering all cells except the last one, with the head adjacent to the last cell.

Order: head at (19,18) moving right → next (19,19)? Let me construct: snake segments = path from head to tail: head (19,18), then (19,17), (18,17), (18,18), ... hmm, easier: fill all cells except (19,19) using a snake-like path where consecutive cells are adjacent.

Simplest: build the snake as a "reading order" path: row 0 left→right, row 1 right→left, etc. The head should be at the end of the path adjacent to (19,19). If the path covers all cells except (19,19) and ends at (19,18), then the head at (19,18) moving right (or down from (18,19))... Let me construct the path in reverse: snake array = [head, ..., tail]. 

Path (boustrophedon over rows 0..18 for x=0..19, then row 19 from x=0 to 18):
Actually the board is 20x20 = 400 cells; omit (19,19) → 399 segments. That's fine.

Let me define the path as a list of cells in boustrophedon order:
for y in 0..19: if y even: x from 0..19, else x from 19..0. But skip (19,19) (the last in y=19 even row order... y=19 is odd → x from 19..0, so (19,19) would be first). Hmm, I want the omitted cell to be adjacent to the path end.

Let's make the omitted cell (19,19) and the path end at (19,18) with the head there, and dir = right (so the next step goes to (19,19)).

Construct path order: traverse rows y=0..18 fully (that's 19 rows × 20 = 380 cells), then row 19: x=0..18 (19 cells) → total 399 cells. The last cell is (18,19) and the head should be adjacent to (19,19) — (18,19) is adjacent (right neighbor). 

So: snake array = [head=(18,19), then the rest in reverse path order]: [(18,19), (17,19), ..., (0,19), (19,18), (18,18), ...] — consecutive cells must be adjacent, which holds for the reverse of the path order.

Then food at (19,19) and dir = right. The next step: head moves to (19,19), eats the food (which is in the last free cell) → placeFood returns false → won = true → "You win! Board full".

I'll write a debug builder that generates this. Let me write it as a temporary block in index.html, activated by DEBUG_FILL.

Also self-collision: DEBUG_LONG = 5 → initial length 5.

Given time constraints (I've used maybe 8 minutes), let me be efficient: implement both debug presets and a second self-test script, then run it once, then clean up.

Actually, I can do both tests in one page load? No — DEBUG_FILL changes the initial state. I'll run the self-collision test first (DEBUG_LONG), then switch to DEBUG_FILL and rerun. Each requires a reload + an inspect. That's 2 rounds. Fine.

Let me write the code.

I need to hurry. Let me run the self-collision test, and in parallel prepare the cleanup. Actually, let me do one reload+inspect round for the self-collision test, then clean up all debug code, restore BASE_SPEED=130, remove debug food/long/fill and the test script and console.logs, and do a final quick verification.

Actually time is short. The critical thing is a correct final file. Let me run the test quickly (reload + inspect), then clean up.

Let me first do the reload and inspect.

The snake had length 5 (log) after the first step, so the tight loop (Down, Left, Up) at head (11,10): Down → (11,11); Left → (10,11); Up → (10,10) — the body at that point: [(10,10)? no: body was [(11,10),(10,10),(9,10),(8,10),(7,10)]. After Down: [(11,11),(11,10),(10,10),(9,10),(8,10)]. After Left: [(10,11),(11,11),(11,10),(10,10),(9,10)]. After Up → (10,10): in body at index 3, not the tail (tail (9,10)) → should be a self collision!

But the log shows STEP up to head (10,10) with no DIE. Hmm! That means the collision check passed. Why?

Because of `tailVacates`: I set `var tailVacates = !eating && tail.x === nx && tail.y === ny;` — tail is (9,10), nx,ny = (10,10) → not equal, so tailVacates = false. So the loop should find (10,10) at index 3 → die('self').

Wait, unless the body I traced is wrong. Let's recheck: the log shows the STEP for Up: head (10,10), len 5 (pre-pop). So the move was allowed. Body at that moment: [(10,11),(11,11),(11,10),(10,10),(9,10)]... hmm wait — after step Down and pop: the snake had len 5 → [(11,11),(11,10),(10,10),(9,10),(8,10)]. After step Left and pop: [(10,11),(11,11),(11,10),(10,10),(9,10)]. Yes (10,10) is at index 3.

So the self-collision check should have triggered die('self'). But it didn't! Let me look at the collision loop code again:

```
    var tail = snake[snake.length - 1];
    var tailVacates = !eating && tail.x === nx && tail.y === ny;

    for (var i = 0; i < snake.length; i++) {
      var s = snake[i];
      var isTail = (i === snake.length - 1);
      if (isTail && tailVacates) continue;
      if (s.x === nx && s.y === ny) {
        return die('self');
      }
    }
```
That looks correct... unless the direction queue wasn't applied as I assumed. The steps show dir transitions: (1,0) → (0,1) → (-1,0) → (0,-1). Head: (11,10) → (11,11) → (10,11) → (10,10). Hmm, head (10,10): moving up from (10,11) → (10,10). Yes.

So why no die? Let me check the actual body coordinates. Maybe DEBUG_LONG added segments at startX-2-d for d=1 → (7,10). Initial snake: [(10,10),(9,10),(8,10),(7,10)] (len 4). First step: head (11,10), pop (7,10) → [(11,10),(10,10),(9,10),(8,10)] (len 4).

Wait — but the debug food at (12,10) — did the snake eat? The log shows score 0 and food still (12,10), so no eating at (11,10). Good. So after the first step, len = 4 (log shows 5 pre-pop).

Then step Down: head (11,11) → body [(11,11),(11,10),(10,10),(9,10)] (len 4).
Step Left: head (10,11) → body [(10,11),(11,11),(11,10),(10,10)] (len 4).
Step Up: head (10,10) → body contains (10,10) at index 3 = the TAIL → tailVacates = true → allowed!

Right — I mis-added a segment earlier. The snake is length 4, not 5. So the Up move lands exactly on the vacating tail → allowed. Correct behavior, but again not a self-collision test.

So the tail-vacate rule is verified as working (twice), but self-collision death isn't yet verified. The collision check code is simple and reads correctly. Given the time budget (about 4 minutes left), I should now finalize: clean up all debug code, restore BASE_SPEED=130, and do a final quick sanity check (load + a few key presses at normal speed might not be feasible... but I can do a fast final check with a small in-page test? No time for another round).

Decision: clean up now, then do a final reload + inspect to confirm no console errors and the initial READY state renders correctly. Also do one quick in-page check? I'll skip further tests.

Actually, I could do one quick self-collision verification by setting DEBUG_LONG=2 (length 5) — but that requires another reload+inspect round (~2 min). Let me instead do the cleanup and, if time permits, verify self-collision via a quick test with DEBUG_LONG=2 in a single reload+inspect.

Hmm, time is very tight. Priority: clean file. Let me do the cleanup edits now.

Clean — no debug remnants. Now final verification: reload and check the initial state, and do a quick play test with normal speed (130ms). Given action latency (~10s), the snake will die quickly. Let me at least verify: load (no console errors), READY state, then press Space and an arrow to confirm it runs and turns — I can do that in one round (reload, then Space + ArrowUp in one block? Actions are separate calls; I can issue two calls in one block).

Let me do: reload (with a screenshot), then in the next block: key Space + key ArrowUp. Then inspect to see the console/state. That's 2 rounds. Time: I have maybe 3 minutes. Let's be quick.

Actually, I already verified all these mechanics earlier (with only BASE_SPEED and the debug food differing). The cleanup only removed instrumentation. A final sanity check: reload and confirm the initial render with no console errors. Let's do that single round.

Clean: no console errors, READY state, snake centered (3 cells), score 0, food placed in a random free cell.

Quick final play check at normal speed: press Space and ArrowUp in one block, then inspect. Time is short — let me do it in one block with two key calls and then one inspect? I can include all three calls in one block: key Space, key ArrowUp, inspect. They run sequentially. The snake will move right ~10s then die at the wall; the arrow Up may or may not register. Given the earlier verification of the same code path, this is just a sanity check that the game runs at normal speed without errors.

Let me do it.

Everything works: game runs at normal speed, game over at wall, restart available. (The snake hit the right wall before the up-turn could take effect, because of the ~10s delay between tool calls — expected with the slow tool round-trips.)

Final check of the file integrity (syntax valid JS). Let me do a quick node syntax check by extracting the script... node is available (I used it earlier). Quick check.