Snake · particle-1

There's a typo in CSS: `background: #1b2k3a;` invalid but followed by valid. Fine, but let me remove it.

Also the snake head eyes orientation - okay.

Let me test in browser.

The board looks very dark — snake isn't visible in the ready state? Actually the snake should be at row 10 with x=7..9. Hmm, the canvas appears empty except food. Wait, the grid lines are barely visible and snake is not visible. Let me check — maybe draw() is being covered by overlay with backdrop-filter blur. Overlay is on top with rgba(6,12,20,0.78) so snake is dimmed heavily. That's OK but I'd like the overlay less opaque, or it's fine. Let's reduce opacity to 0.62 maybe. Also let's start and test.

Actually wait—the whole board looks black; the checkerboard too. 0.022 rgba is very subtle. Fine.

Let me test gameplay by clicking Start and using JS to inspect.

Game runs. Snake visible, food visible. Grid cells look correct (20x20). Now let's test direction input & reverse-ignore logic. I'll use JS evaluate? I only have browser actions, no evaluate. Can I use key presses and inspect via DOM? __snake object isn't exposed in DOM output. Hmm, the inspect output shows DOM text only. I can read state via screenshot.

Alternative: use the bash tool with a headless check? Simpler: temporarily render state into DOM title/data attributes so inspect shows them. Could add a debug line in the DOM (hidden?) Actually I can add data attributes to body updated each draw — inspect dom text wouldn't include attributes though. But I could add the state into a visually hidden element's text. Let's add a small debug element `#dbg` with display:none? display:none text may not appear in DOM extraction. Use position absolute, opacity 0, height 0 overflow hidden — text might still be extracted. Let's try adding a hidden debug readout that is safe to keep (or remove at end).

Actually simpler: I can test via keyboard and screenshots, watching the snake move. Fast ticks (120ms), and screenshots take time, so snake may move. To verify reverse-ignore, pressing Up then Left rapidly then screenshot direction change... tricky.

Better: add a temp debug element, verify, then remove. Let me insert a debug span updated in draw.

Also note board top: snake head rendered with shadow. Ok.

Let me add debug.

Also draw() is only called on steps and the pulse interval, so dbg updates regularly. Note in "running" state, draw only on steps, fine.

Reload and inspect.

Food=19,15 at edge - it's rendered at edge, fine.

Now test: start with arrow key, then rapid inputs: press ArrowUp then ArrowLeft quickly (within same tick). Expect: queued from dir (1,0): Up accepted, then ref=Up so Left accepted → queue [Up, Left]. So snake turns up then left. Reverse test: press ArrowLeft while going right → ignored.

Sequence: start with ArrowUp (from ready → starts, dir queued [up]). Then quickly press ArrowLeft then ArrowRight? Let's do a controlled approach: start game with Space? No—Space starts. Then dir stays right. Let's press Space to start, then immediately press ArrowLeft (reverse → ignored), then check dir=1,0. Then press ArrowUp and ArrowLeft rapidly → both queue.

Use browser key actions which have latency though. Let's do that.

Now test reverse ignore: press ArrowLeft twice quickly, then inspect. But speed of tool is slow (multiple ticks pass). Head at 10,10 moving right. Wall at x=19. It may die soon. Let's press ArrowLeft now (should be ignored) then check dir.

Game over because it hit the wall while my tool call was slow (multiple seconds per call). dir remains 1,0 - reverse fine, but not a definitive test. The interval of tool calls is too slow for real-time testing of rapid input.

Better: write a Node-based test harness? No browser automation library available. Instead I can inject a test script via a query param? Or use the browser by adding a self-test mode triggered via location.hash that runs logic synchronously and writes results to DOM. That's a solid approach: add a hidden test harness triggered by `#test` which simulates rapid inputs by calling the internal functions with fake stepping.

To do that, I need to expose step and queue functions in window.__snake. I already expose state. Let me extend __snake with internal controls: queueDirection, step, resetGame, and expose setState. Then navigate to #test... but I can't navigate URL with the browser tool except reload. Hmm. Alternatively run tests automatically on load if location.hash === "#test" — but the browser reloads the same URL (probably retains path). The page URL is index.html; would it have hash? Unknown.

Alternative: I can add a temporary auto-test that runs on load and prints results to debug element, then check and remove. Since the file is mine to finalize, add temporary self-test that runs on load only when a flag is set in localStorage? No way to set localStorage without evaluate.

Simplest: temporarily make the self-test run always on load, inspect results, then remove the harness. Add code at end: run tests using a separate isolated engine copy... The internal closure functions can be used: I'll extend __snake with step/queue/reset. Then add a snippet in a temp copy (index_test.html) that imports? Functions are in closure — a separate file can't reach. So do: temp file test.html = index.html + appended script that runs after the IIFE, using window.__snake exposed step/queue. I'll expose step, queueDirection, resetGame, startGame in __snake temporarily in index.html, create test.html via copying and appending script, run tests, then remove the exposure of internals (keep getState maybe harmless, but final should be clean-ish; I'll keep only getState).

Let's do it.

No python. Use node?

Now load test.html in browser. The browser tool loads index.html presumably; maybe can navigate via URL? Only reload/inspect. Hmm. It says "Run index.html". Probably fixed to index.html. Then I could temporarily swap: copy index.html to index_real.html and test.html to index.html, reload, inspect, then restore. Do that.

The test script apparently didn't run to completion—the game is running with the interval active and dbg shows normal state, title unknown. The test snippet is appended after </body>? I inserted before </body> so it runs — but it starts a game via S.start() which starts the timer, and tests run synchronously; at the end, set dbg text, but then the timer keeps running and overwrites dbg (draw() called by step and by the 250ms pulse interval). So my results got overwritten.

I need to stop the timer at end and print results. Let me modify the test: stop by S.pause()? pause also sets state. Just call S.restart() then... restart calls stopTimer, good, then set dbg text. But draw from pulse interval will overwrite (only draws if not running). So after restart, the pulse redraw will overwrite dbg every 250ms. Need results output elsewhere, e.g. set document.title and also write into a separate element that draw doesn't touch. Use a new element appended, not #dbg. Also title extraction isn't available in inspect dom. Let me append results into a div appended to body with unique id, and also set document.title. Inspect DOM includes body text so it'll show.

Also in the last loop for '4-cell loop' test — check.

Regenerate the test with results element.

All pass except "self collision": my test path is wrong. Let's compute: snake [(9,10),(8,10),(7,10)] dir right.
Step 1: queue up -> head (9,9); body after move: (9,9),(9,10),(8,10).
Step 2: queue left -> head (8,9); body: (8,9),(9,9),(9,10).
Step 3: queue down -> head (8,10). Is (8,10) occupied? Body currently (8,9),(9,9),(9,10) — no. So no collision. Need 4 steps: then right into (9,10) which is tail and vacates -> allowed. To create actual self collision need len>=5 or tighter loop with len 4.

Better test: queue up, left, down, right? with len 3, sequence: after step3 head (8,10), body (8,10),(8,9),(9,9). Step4 right -> (9,10): occupied? body has (8,10),(8,9),(9,9) -> no. So the 2x2 loop with len3 requires 4 steps but never collides. With len 4: after eating length 4, do square loop: head goes around and hits the 4th segment.

Simulate a length-4 snake geometry: after growing, I can't set snake. Use natural growth then loop. Alternative approach: length 4 straight line e.g. body (9,10),(8,10),(7,10),(6,10). Turn: up (9,9), left (8,9), down (8,10) — (8,10) is now the 3rd segment head? After step up: body (9,9),(9,10),(8,10),(7,10). After left: (8,9),(9,9),(9,10),(8,10). After down -> (8,10): occupied by segment index 3 (tail) → it's tail which vacates? Len 4, tail is (8,10) and moves away since not eating → allowed. Hmm len 4 also allowed.

Len 5: body 5. up,left,down: after 3 moves body: (8,10),(8,9),(9,9),(9,10),(8,10)? Can't duplicate. Let's do: start head (9,10) len 5 body (9,10),(8,10),(7,10),(6,10),(5,10). Up->(9,9) body [(9,9),(9,10),(8,10),(7,10),(6,10)]. Left->(8,9) body [(8,9),(9,9),(9,10),(8,10),(7,10)]. Down->(8,10): occupied by index 3 which is not tail (tail is (7,10)) → collision. Good.

So write self-collision test with length 4→5. Getting length 5 requires eating twice. Simplest: use the food-chasing loop until score 2, then do the loop. But direction after eating may vary; hard to control.

Alternative: expose a debug setter temporarily (test build only). Since this is a test harness, I'll add a test-only function in the test script that manipulates internal state... not possible via closure.

Simplest: temporarily add `setSnake` to __snake in index.html (test copy only). But the check must validate actual game logic — occupied() logic; fine to set state directly.

Actually easier: prove self-collision using a growing snake naturally: chase food until score 3 (len 6), then attempt a spiral? Complex.

Alternative deterministic approach: I can make food predictable by overriding pickFood? No.

I'll add a test-only `setSnake` hook in index.html temporarily. But the final deliverable shouldn't expose it. I'll add it in index.html, test, then remove and restore final file. Actually I have index_real.html which is the pre-test version (before swapping; but it was saved before I swapped, containing step/queue exposure). I'll edit index.html (current test copy) to add setSnake to __snake in the inlined real code; test; then produce the final file from the code portion.

Simpler plan: modify index.html's __snake in the real part to add `setSnake: function(pts, d){ snake = pts.map(...); dir=d; ... }`. Then update test to use it. Then, after verifying, remove setSnake/pause/step exposures from the final file (keep only getState? I'd rather remove entire __snake... but the test relies on it; remove after final verification, then do one last visual smoke test — that's fine).

Let's do it.

The self-collision patch didn't apply? Results still show the old test name "self collision ends game" and running. The replace of the setSnake insertion worked? Let me check the file.

Hmm my replacement of the ok line targeted "ok('self collision ends game',S.getState().state==='over',S.getState().state);" — output still shows "self collision ends game", so the replacement failed. And the reset/start sequence replacement failed too (needs exact match including indentation). Let me check the file content around.

There are two copies of the test script in the file: one at line ~563 is the real code; and there appear to be TWO test blocks? Line 647 is inside one block and line 717 another. Because mk2.js read index.html (which already contained a test block from mk.js) and appended another. Right! mk2 read index.html which had test appended. So duplicated tests, first being the updated one.

So the first block (with setSnake) runs first and changes state; then second (older) block runs and overwrites results. Let me clean: rebuild index.html from a clean source. I'll strip all appended test scripts: take content up to the first `</body>`? The original test was inserted before `</body>` so structure is: real code ... first test script ... `</body>`? Actually mk inserted `test + '\n</body>'` replacing `</body>`; so first test is before </body>. mk2 then read that file which contains test1; replaced '</body>' with test2 + '</body>' → test1, test2, </body>. Wait but the first test block ends and then `</body>` replaced... Hmm, test1 was placed before </body>, then test2 replaces </body>, giving test1, test2, </body>.

So remove from the first `<script>\n(function(){\n  var out=[];` occurrence to just before final </body>. Let's rebuild from index_real.html (clean, has step/queue exposure), then regenerate the test with the corrected self-collision test, in one pass.

index_real.html is clean (has step/queue/start/pause/resume/restart exposure, but not setSnake). Rebuild test from it in one pass with setSnake insertion + fixed collision test.

All 27 tests pass. Now build the final index.html: clean version with overlay opacity maybe slightly higher visibility of board under overlay (fine as is), remove dbg element and dbgLine, remove internal hooks except a minimal getState? I'll remove the __snake exposure entirely for cleanliness... but keeping getState is harmless and useful. However the dbgLine/`#dbg` should be removed. I'll keep the game rendering updater for food pulse.

Also test the win state logic: when snake.length === 400 -> won. Hard to fully verify; simulate: setSnake with 399-cell body is unrealistic but the code path food===null -> won in reset? Actually in resetGame, pickFood could return null only if board full — snake len 3 so no. The win branch is straightforward. Could test win by setSnake with a snake filling board... 400 segments not constructible. Skip; reason about code.

Let me build clean final file: strip appended test script from index_real.html, and remove dbg + internal hooks.

Plan: from index.html, cut from the first `<script>\n(function(){\n  var out=[];` up to the closing of the appended block (end before '</body>'). Easier: use index_real.html (clean game, with step/queue/start/pause/resume/restart exposure and dbg div). Then edit: remove dbg div, dbgLine function and call, and trim __snake to getState only.

But then final verification of UI via keyboard/pause/restart clicks: doable with screenshots (visible overlay/score). Also verify arrow keys don't scroll — body overflow hidden, so can't scroll anyway; preventDefault present.

Let's write the final steps.

The overlay hides the snake (backdrop blur + 0.78). In ready state the snake should be somewhat visible. Reduce overlay opacity to 0.55 and remove blur maybe. Also there's a dark band behind the buttons? That looks like the overlay's box-shadow... Actually there's a greyish rectangle behind the buttons — that's the .stage box-shadow? No, it spans below the stage. Hmm, it looks like an artifact: `box-shadow: 0 0 30px rgba(20,120,200,.18), inset ...` — the outside shadow is bluish. The rectangle behind buttons is darker slightly. Probably the `.overlay` with backdrop-filter blur extends? No, inset:0 in stage.

Actually the darker rectangle region below stage from y≈595 to 660 — maybe the canvas's border-radius shadow? Could be the page background gradient banding. It's subtle; fine but let's reduce overlay opacity and see gameplay screenshot.

Now test interactions: Start button at (510,626), Pause at (600,626), Restart (680,626).

Board checkerboard now visible, snake visible faintly at center-right. Good.

Now click Start and verify playing; then key turns; pause; restart.

Snake visible, grid aligned, food present. Start disabled (greyed). Now press ArrowDown then ArrowLeft and screenshot to see direction change. Because each tool call takes ~1s+, snake moves ~8 cells per call and might hit a wall. It's at x=13 heading right; wall at 19 → 6 steps = 720ms. Risk of game over between calls. Arrow keys typed during "over" do nothing (state over, ignored), which is correct behavior.

Let's press ArrowUp quickly right after starting? Can't beat timing. Instead restart and immediately press up-left sequence; then screenshot may show over. It's fine; the deterministic tests already validated direction logic. I'll do one visual check with pause immediately to freeze.

Press ArrowUp now and check whether state continues or over. Then Pause and screenshot.

Game over from wall — the snake reached right edge (head at x=19). But the overlay text/overlay covers snake. It's fine; overlay opacity 0.6 makes them dim.

Now restart by clicking Restart, verify score 0, len 3, ready. Then start, press Space to pause quickly (may be over already). Better: restart, then press ArrowUp (starts moving up), then press space immediately in same call? Can't. Inter-call delay ~1s means snake moves a lot, up from (9,10) → reaches y=0 in 10 steps (1.2s). Risky.

Alternative: use Pause quickly by clicking Pause—click calls also slow. Let's just do restart, then click Pause after start via key Space and screenshot. Even if game over, I can verify Restart. The deterministic harness already proved pause/resume and restart logic. Also I can increase TICK_MS temporarily? No need.

Actually to visually verify pause works, set TICK to slow? Instead, I can verify pause/resume in browser by pausing when game is over? No. Let's try: restart, then press ArrowDown (starts, dir down from y=10, 10 steps to bottom), then immediately press Space (pause) in the next call ~1s later — likely already over. Hmm.

Quick approach: start from ready with Space then Pause button click might take 1s. Alternatively, after Restart, press ArrowLeft? reverse ignored, state ready. Press ArrowUp to start heading up: head (9,10) → 10 cells to wall = 1.2s. So after 1s call delay, still might be alive if timing is lucky, but the next call adds latency.

Alternative: make the game start paused? Not needed—behavior verified headlessly. I'll do restart verification visually and try pause.

Restart works: READY, score 0, snake back at center, food at a free cell (1,3 area). Now verify pause visually. To do it with the slow tool, I'll press ArrowDown (starts heading down; 10 cells to bottom ≈ 1.2s) then click Pause. Risky. Alternatively press ArrowUp then immediately send Space in the same batch? Tool calls in one block run maybe sequentially but faster? I can issue key + click in the same block? Tools execute in parallel per the instructions for independent calls — for browser actions, probably sequential. Let's try sending key ArrowUp and click Pause simultaneously in one block.

Pause works: state PAUSED, snake frozen, Pause button becomes Resume. Note the snake head is one cell above body (turned up) — grid aligned. Good.

Interesting: in the paused screenshot the snake looks like 2 segments visible (head plus 1) — maybe the third is behind the overlay text. Fine.

Now verify resume: click Resume button (Start disabled). Then check score grows after eating? The food is far. Let me at least resume and observe. Then restart check done.

Also verify arrow scrolling prevented: body overflow hidden.

Let's click Resume.

Resume works, snake moving up, grid-aligned. Score 0.

Now I'd like a visual for score increase. Food at ~(1,6). Snake heading up at x=9. Hard to steer within tool latency. The deterministic harness verified score/growth.

One more concern: "Start" button after game over — startBtn disabled in over state; clicking Space or Start can't restart (Start disabled). Requirement says provide Restart which exists. Fine.

Also I should double-check the win state doesn't break drawing (food null handled). Code handles food null. Good.

Also check console has no errors: inspect showed console empty.

Final cleanup: verify the file has no leftover debug references and view the final file head to ensure CSS is valid. Also, edge case: if the user presses direction key during "ready", we queue and start; if queued dir is reverse (left), ignored, so it starts moving right. Good.

Another consideration: `queuedDirs.length >= 2` returns early — caps buffer. Fine.

One bug possibility: in `step()`, when a queued direction would reverse relative to the committed dir due to queue cap interplay? queueDirection validates against last queued or committed, so safe.

Check `occupied(nx,ny,tailMovesAway)` with ignoreTail=true excludes the last segment. Correct: moving into a tail that vacates is allowed.

But subtle: if eating food and snake length grows, tail doesn't vacate — handled since eating → tailMovesAway false. Good.

Also when the new head lands on the tail cell on a non-growing step and the food is elsewhere — allowed. Correct.

Let me clean up temp files (index_real.html, test.html) so only index.html remains, and do a final reload/console check.

Initial state clean, no console errors. Done.

Summary of checks: game logic harness (27 assertions), visual start/pause/resume/restart, wall death. Unverified: win state path (only reachable at 400 segments), self-collision visual (verified headlessly), eating/score visual (verified headlessly).