What qwen3.8-27b did

Let me think about the design.

Task: Snake game, 24×24 grid, canvas is about 720×720 CSS pixels. Vanilla HTML/CSS/JS. One original mechanic.

Let me design the twist. Ideas:

1. **Ghost trail**: Snake leaves a trail that decays; stepping on your own trail is... no, that's just a variant of the death rule.
2. **Wormhole**: Two portals swap positions. Somewhat generic.
3. **Momentum/braking**: Can brake to slow down, but food decays. Trade-off.
4. **Hunger**: Food has a timer; if you don't eat within N ticks, you lose a segment (or the food disappears and you lose a life). Trade-off: chase the food or play safe.
5. **Phase shift**: Press a key to make the snake temporarily pass through walls (phase) — but that's a power-up.
6. **Gravity/tilt**: The board tilts and the snake slides.
7. **Echo**: Your snake echoes — after eating, the snake becomes "echo" for a few seconds, and the old path becomes deadly... hmm.
8. **Symbiote**: A second snake (AI) chases you; if you eat, the symbiote gets stronger.
9. **Molting**: Every N food, the snake can shed its tail — pressing Space makes the tail segment drop, shrinking the snake and opening up space. Trade-off: shed to escape a trap but lose length/score? This is interesting: "Molting" — press Space to shed your tail (shrink by 2), which can save you from self-collision, but the shed segment becomes a hazard or disappears. Real trade-off: length = progress; shedding loses length.

Actually, a clean, well-known-feeling but original idea: **"Shedding"**: Press Space to shed the last 2 tail segments. They turn into... nothing (they just vanish). This gives an escape hatch when trapped. Trade-off: you lose growth. But is this "one sentence"? "Press Space to shed your tail and shrink by 2, escaping tight spots at the cost of growth." Not bad.

Another idea: **"Comet tail"**: Food leaves a trail... no.

Another idea: **"Gravity Well"**: The food you're about to eat is... no.

Another idea: **"Tether"**: A tether connects the head to the first food; if the snake gets too far away, the tether snaps and you die? Too punishing.

Another idea: **"Famine"**: Every food appears with a shrinking ring (timer, e.g. 8 seconds). If it expires, you lose 1 segment (minimum length 1... or minimum 3) and a new food appears. Trade-off: you must chase expiring food, but the food may spawn far away or in dangerous spots; if you're in a tight spot, you might choose not to chase it and risk losing a segment. This creates a real decision: chase the food at risk of crashing, or play safe and lose length. It interacts with growth (eating grows you, expiration shrinks you), death (if expiration shrinks you to minimum, no problem), and restart (timer resets).

Hmm, but "lose a segment on expiration" — is that a real decision? Yes: the food is somewhere, the timer is ticking. You can go for it (risk) or ignore it (lose 1 length). And the expiration timer can be tuned so that it's usually reachable but sometimes risky. I like this. Name: "Famine" or "Hunger". One sentence: "Each apple rots after about 10 seconds — chase it to grow, or let it rot and lose a segment."

Wait, there's a subtle point: if the snake is long and the food is far, losing a segment on expiration is a mild punishment. The decision: risk a crash to eat, or safely shrink. Good. And it interacts with the speed-up mechanic (as the snake grows, ticks get faster, so the timer in tick units stays consistent).

Alternative: **"Scurry"** — a sprint key: hold Shift to move 2× faster, but while sprinting you can't turn? No, that's a control change.

Let me think of something more distinctive: **"Phase"**: Press Space to phase through walls for 1 second (wrap around), but while phased you can't eat? Hmm, that's a power-up with a cost.

I think "Famine" (food decay) is the strongest: simple, one sentence, real trade-off, interacts with growth (net length fluctuates), death (none), restart (reset). Let me refine:

- Food has a lifetime of about 9 seconds (measured in ticks so it scales with speed... actually, in real time is better? If measured in ticks, it shortens in real time as the snake speeds up, making late-game more frantic. That's good: "the faster you go, the less time you have per apple"). Let me measure in ticks: food lifetime = 90 ticks? At 8 ticks/sec that's 11.25 seconds. As speed increases, real time shrinks. Hmm, but in late game ticks are about 15/sec, 90 ticks = 6 seconds. That's reasonably consistent.

Actually, real time might be simpler and fairer: 10 seconds always. But tick-based ties into the speed mechanic nicely and is easy to implement (decrement a counter each tick). Let's go tick-based: lifetime = 96 ticks (12 seconds at start). Display a shrinking ring around the food.

- On expiration: food disappears, snake loses 1 segment (minimum length 3? Let's say minimum 4 to keep it playable; if it's already at minimum, it just disappears). New food spawns.
- If the snake eats: +1 segment, +1 score, new food with a fresh timer.
- Score: +1 per food. Should expiration reduce score? No — score is "apples eaten". Keep score = apples eaten. Length changes independently. High score persists.

Wait — but if expiration shrinks the snake, the speed (which depends on length) also decreases. That's fine, it's consistent.

Trade-off clarity: food spawns at a random empty cell. Player decides: go for it (risk of wall/self) or ignore (lose 1 length). When the snake is long, ignoring is cheap (lose 1, speed slightly decreases). When short, losing length is more painful. Also, if you ignore, new food spawns elsewhere with a fresh timer — so you can keep ignoring and stay at minimum length forever, but then you never score. Nice: the score is the objective, and the risk of chasing food is the price.

Edge cases:
- Expiration shrinks the snake: remove the tail segment. But careful: if the tail cell is where the head is about to move? The head moves first, then the tail is removed. Standard order: compute the new head; check collision with the body (excluding the tail cell if the tail is moving — classic snake nuance: the tail cell is vacated on the same tick, unless growing). To keep it simple and safe: on each tick, move the head, and if growing (ate) keep the tail, otherwise remove the tail. Collision check: new head vs walls, vs body segments excluding the last tail cell (since it moves away). Actually, the common simple approach: check collision against all segments including the tail — slightly stricter but fine and predictable. Hmm, strictness: moving into the cell currently occupied by the tail is actually safe in classic snake (the tail moves). Many implementations allow it. To be lenient and feel good, exclude the tail from the collision check when not growing. Let me implement: body = array of cells, head at index 0. New head = head + dir. If new head is out of bounds → dead. If new head is in body[0..len-2] (excluding the tail when not growing) → dead. Then unshift the new head; if not eating, pop the tail.

Wait, but the "Famine" expiration also removes the tail — same operation.

- Pause: P or Escape toggles pause. Show a "Paused" overlay. Keys during pause: don't queue direction changes? Or allow them? Simpler: ignore direction input while paused (or queue the next direction). Ignoring is fine; on resume, the snake continues in the same direction. Actually, better: allow direction changes during pause? No — keep it simple: ignore.

- Game over: show score + high score, "Press any key to restart". Fully reset: snake, food, timer, score, speed.

- Input: prevent reversing into yourself: if new direction is the exact opposite of the current direction, ignore. Also, queue up to 2 direction inputs for responsiveness (input buffer). This makes it "responsive". Let me implement a small queue (max 2–3) that shifts each tick.

- Tick loop without drift: use a requestAnimationFrame accumulator: accumulate elapsed time; while (acc >= tickMs) { step(); acc -= tickMs; } with a cap on acc to avoid a spiral of death (e.g., clamp frame dt to 100ms). tickMs varies with length: start 125ms (8/sec), decrease by 2ms per apple eaten? Floor 60ms. Let me define: tickMs = max(60, 125 - 1.5 * (len - 3))? Let me calculate: start length 3. After 10 apples, len 13 → 125-15=110ms (9.1/sec). After 30 apples, len 33 → 125-45=80ms (12.5/sec). After 43 apples, floor 60ms (16.7/sec). Hmm, "slowly speeds up with a floor" — good. Maybe 1.2 per segment: after 30 apples → 89ms. Either way. Let's do tickMs = max(65, 125 - 1.5*(len-3)).

- Food lifetime in ticks: 96 ticks. At 125ms that's 12 seconds; at 65ms that's 6.2 seconds. Display a shrinking arc ring around the food. As it approaches expiration, the ring turns red / the food pulses.

- High score: localStorage key 'snakeFamineHigh' etc. Wrap in try/catch (in some contexts localStorage can throw).

- Grid: 24×24, canvas is 720 CSS pixels → 30px per cell. Use devicePixelRatio scaling for sharpness: canvas.width = 720 * dpr, ctx.setTransform(dpr,0,0,dpr,0,0). Actually, simpler: set canvas width/height to 720*dpr and scale. Also handle dpr changes? Keep it simple: set once on load, and on resize if needed. Let me set it once with a resize handler.

- Keys: arrow keys, WASD, P, Escape, Space (Space is... not used for the twist — the twist is automatic). Enter/Space to restart on game over? "Restart on key press" — any key. But careful: the key that killed you... whatever, any key restarts. But avoid instant restart from a held key? Require keydown (not repeat) — use e.repeat check. Also, on game over, require a key press; guard with a small delay (e.g., 400ms) so the player doesn't skip the game-over screen with a mashed direction key. Let me add a 500ms lockout after death before accepting a restart.

- preventDefault on arrow keys, space, WASD? WASD doesn't scroll, but arrows do. preventDefault on handled keys: ArrowUp/Down/Left/Right, Space, P, Escape (Escape doesn't scroll). Also, 'p' keydown is fine.

- Display: score, high score, and also "length" and "time to rot" maybe. Show the name and one-sentence explanation below the board. Show controls: arrows/WASD to move, P/Esc to pause.

- Feedback on eating: flash effect — a ring that expands from the eaten cell, a brief screen pulse, score pop-up "+1". Also a subtle grid. Keep it tasteful. Let me implement a particle burst (small squares) at the food position + a short "eat flash" on the score display. Also, the snake's head can pulse.

- Visual design: dark background, board with a subtle checkerboard (two very close dark shades), snake a gradient from head (bright green) to tail (darker), food a red apple with a leaf? Draw a circle + a small leaf. Expiring food: a shrinking ring (arc) around it, color shifting from amber to red. Snake: rounded rectangle segments, or a connected path. Rounded rectangles with slight gaps look good. Draw each segment as a rounded rectangle with a small inset; head with eyes.

- Pause overlay: dim the board, "PAUSED — press P to resume".

- Game over overlay: "GAME OVER", score, high score ("New high score!" if applicable), "Press any key".

- Start state: show a "Press any key / arrow to start" overlay? The task says a game-over state restarts on key press; starting: it's nice to have an initial "ready" state so the player can read the rules before the snake moves. Let me add a "ready" state: snake is idle, board is drawn, "Press an arrow key to start". First direction key starts the game. This makes the rules readable before starting. The snake starts length 3 in the center, facing right.

Also, "the snake moves at a fixed tick (starting around 8 steps per second)" — 125ms = 8/sec. Good.

Now, the twist name: "Famine"? "Rot"? "Spoilage"? Let's call it **"Famine"**: "Each apple rots after about 12 seconds — chase it to grow, or let it rot and lose a segment of your tail." Hmm, the tick-based lifetime changes with speed; say "12 seconds" but it varies... Let me say "Each apple rots (about 12 seconds, faster as you speed up) — eat it to grow, or let it rot and lose a segment." One sentence: "Apples rot: if you don't eat the apple before its ring runs out, it vanishes and you lose a segment — so decide every time whether the apple is worth the risk."

Name candidates: "Famine", "Rot & Ruin", "Spoilage", "The Rot". Let's go with **"Famine"** — evocative. Actually "Rot" is punchier and matches the visual. Let me name it **"Rot"**: "Each apple has a shrinking ring; if it empties before you eat it, the apple rots and you lose one segment of tail — chase it to grow, or play it safe and shrink."

Let me also confirm the interaction with death: if the snake is at minimum length (let's say 3) and food rots, it just vanishes (no shrink below 3). New food spawns.

Another consideration: should rotting reduce score? No. Score = apples eaten. But then a player could "safe-play" forever at length 3 with score 0 — that's fine, the score is the objective.

Hmm wait, another consideration: the trade-off should be a *real* decision. If the penalty is only -1 segment, is ignoring food always safe? If the food is far, yes. The tension: to score, you must eat; each apple forces a risk assessment. And late-game, the ring drains faster (ticks get shorter) so decisions get more frantic. I think this works. Also, when the snake is long and coiled, the food may be inside your own loop — unreachable without dying; then the choice is clear (let it rot). Good.

Alternatively, make the penalty -2? -1 is enough; the compounding effect of missing multiple apples matters.

Implementation plan (single index.html, embedded CSS + JS, or separate files? "Everything in the current directory. index.html is the entry point." A single file is safest for a static host. Let me make a single index.html with <style> and <script>. It'll be long (about 700–900 lines). The instructions say to write in chunks if it gets long — write the first part, then append with edit. Let me be careful: a single large write may be truncated. Write index.html in about 3 chunks: first write (head + CSS + HTML body), then append the JS part 1, then JS part 2 via edit. Actually, edit requires matching oldText; for appending, match the closing tag `</body></html>` and replace with new content + closing tag. That works.

Let me draft the code.

Structure:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Snake — Rot</title>
<style> ... </style>
</head>
<body>
  <main class="wrap">
    <header>
      <h1>SNAKE <span class="accent">· ROT</span></h1>
      <div class="hud">
        <div class="stat"><span class="label">Score</span><span id="score" class="value">0</span></div>
        <div class="stat"><span class="label">Best</span><span id="best" class="value">0</span></div>
        <div class="stat"><span class="label">Length</span><span id="len" class="value">3</span></div>
      </div>
    </header>
    <div class="board-wrap">
      <canvas id="board" width="720" height="720"></canvas>
      <div id="overlay" class="overlay"> ... </div>
    </div>
    <section class="twist">
      <h2>Rot</h2>
      <p>Each apple carries a shrinking ring of time — if it runs out before you eat it, the apple rots and you lose a segment of tail, so every apple is a choice: risk the chase to grow, or let it rot and shrink.</p>
    </section>
    <section class="controls">
      <p>Move: <kbd>↑↓←→</kbd> or <kbd>WASD</kbd> · Pause: <kbd>P</kbd>/<kbd>Esc</kbd> · Restart: any key</p>
    </section>
  </main>
<script> ... </script>
</body>
</html>
```

The overlay is an HTML div positioned over the canvas — that's fine (CSS, no images). Or draw the overlay on the canvas. HTML overlay is easier for text layout. Let me use an HTML overlay with a state class.

JS design:

```js
(() => {
'use strict';
const COLS = 24, ROWS = 24, CSS = 720, CELL = CSS / COLS; // 30
const canvas = document.getElementById('board');
const ctx = canvas.getContext('2d');

// dpr setup
function fitCanvas() {
  const dpr = Math.max(1, Math.min(2.5, window.devicePixelRatio || 1));
  canvas.width = CSS * dpr; canvas.height = CSS * dpr;
  canvas.style.width = CSS + 'px'; canvas.style.height = CSS + 'px';
  ctx.setTransform(dpr, 0, 0, dpr, 0, 0);
}
fitCanvas();
window.addEventListener('resize', fitCanvas);

// state
const S = { READY: 0, RUN: 1, PAUSE: 2, OVER: 3 };
let state = S.READY;
let snake, dir, queue, score, best, food, foodLife, foodLifeMax, grow, particles, eatFlash, deadAt, acc, lastT, tickMs;

best = loadBest();

const LIFE_TICKS = 96; // apple lifetime in ticks
const MIN_LEN = 3;

function reset() {
  const cx = Math.floor(COLS/2), cy = Math.floor(ROWS/2);
  snake = [{x:cx-1,y:cy},{x:cx-2,y:cy},{x:cx-3,y:cy}]; // head first, facing right
  dir = {x:1,y:0};
  queue = [];
  score = 0;
  grow = 0;
  food = null; foodLife = 0;
  spawnFood();
  particles = [];
  eatFlash = 0;
  acc = 0;
  tickMs = currentTickMs();
  updateHud();
}
```

Wait: the snake is length 3, head at cx-1? Let me set head (12,12), body (11,12), (10,12). Facing right. cx=12 (0-indexed, 24 columns → 0..23, center is 11.5). Head (12,12), body (11,12), (10,12). Good.

currentTickMs: `Math.max(65, 125 - 1.5 * (snake.length - 3))`.

spawnFood: pick a random empty cell (not on the snake). If the snake fills the board (24*24=576 cells) → win? Unlikely, but handle: if there are no empty cells → win state = game over with "You filled the board". Handle it: if no empty cells, food = null; the game effectively ends (win). Let me include a simple check.

step():
```js
function step() {
  // apply queued direction
  while (queue.length) {
    const d = queue.shift();
    if (d.x !== -dir.x || d.y !== -dir.y) { dir = d; break; }
    // if the queued direction is the reverse of the current direction, skip it?
  }
```

Hmm, careful: the queue may contain a reverse relative to the *current* dir; skip invalid ones and try the next. Standard: pop from the front until a valid (not reverse) one is found; if none, keep dir.

Actually, the classic approach: on keydown, if the key's direction is not the reverse of the *last queued or current* direction, push to the queue (capped at 3). Then on tick, shift one. Let me do validation on keydown: compare against the last element of the queue (or dir if the queue is empty). This prevents double-turn reversals (e.g., moving right, quickly press up then left: the queue is [up, left] — both are valid relative to their predecessor). Good.

```js
  // move head
  const head = { x: snake[0].x + dir.x, y: snake[0].y + dir.y };
  // wall
  if (head.x < 0 || head.y < 0 || head.x >= COLS || head.y >= ROWS) return die();
  // self: exclude the tail cell if not growing this tick
  const eating = food && head.x === food.x && head.y === food.y;
  const bodyLen = snake.length - (eating ? 0 : 1); // tail is vacated unless we grow
  for (let i = 0; i < bodyLen; i++) {
    if (snake[i].x === head.x && snake[i].y === head.y) return die();
  }
  snake.unshift(head);
  if (eating) {
    score++;
    eatFlash = 1; // decays
    burst(food.x, food.y);
    if (score > best) { best = score; saveBest(); }
    spawnFood(); // new food with fresh lifetime
  } else {
    snake.pop();
  }
  // food lifetime
  foodLife--;
  if (foodLife <= 0) rot();
  tickMs = currentTickMs();
  updateHud();
}
```

Wait, order: should the food lifetime decrement also happen on the tick you ate? If you ate on this tick, spawnFood sets foodLife = LIFE_TICKS, and then foodLife-- makes it LIFE_TICKS-1. Trivial, fine. Actually cleaner: decrement first, then check for eating? Let me do this: after movement/eating, `if (food) { foodLife--; if (foodLife <= 0) rot(); }`. If we just ate, the new food's lifetime is decremented by 1 on the same tick — negligible.

rot():
```js
function rot() {
  // visual: gray puff at food position
  rotPuff(food.x, food.y);
  if (snake.length > MIN_LEN) snake.pop(); // lose a segment
  spawnFood();
  updateHud();
}
```

die():
```js
function die() {
  state = S.OVER;
  deadAt = performance.now();
  if (score > best) { best = score; saveBest(); }
  showOverlay('over');
  updateHud();
}
```

Note: on death, the snake doesn't move (the head doesn't enter the wall). Draw the snake as-is, maybe flash red.

Main loop:
```js
let last = performance.now();
function frame(t) {
  requestAnimationFrame(frame);
  let dt = t - last; last = t;
  if (dt > 100) dt = 100; // clamp
  if (state === S.RUN) {
    acc += dt;
    while (acc >= tickMs) {
      acc -= tickMs;
      step();
      if (state !== S.RUN) { acc = 0; break; }
    }
  }
  render(t);
}
```

This is drift-free (accumulator). On faster displays (144Hz), dt is small and the accumulator handles it. Good.

render(t): draw the board background (checkerboard), grid lines (subtle), food with ring, snake, particles, eat flash. The overlay is handled by HTML.

Food ring: fraction = foodLife / LIFE_TICKS. Draw an arc around the food cell: from -90° to fraction*360°. Color: hue from 45 (amber) to 0 (red) as fraction→0. Also, when fraction < 0.25, the food pulses (radius oscillates with t).

Snake drawing: for each segment, a rounded rectangle inset by 2px. Color: gradient by index: head #7CFC00-ish... let me pick a palette:

- Background page: #0b0e14 (very dark blue-black)
- Board: two checker shades #10151f / #0d1219, border #1e2633
- Snake: head #a3e635 (lime-300), body gradient to #16a34a? Use HSL: hue 140 (green), lightness from 65% at head to 35% at tail. `hsl(140, 70%, L%)`, L = 62 - 30 * i/(len-1).
- Food: #ef4444 red circle, leaf #22c55e, ring amber→red.
- Eat flash: an expanding ring at the eaten cell (particle system: 10–14 small squares flying out, fading).
- Score pop: an HTML element "+1" that floats up? Can also be done with a canvas text particle. Let me do a canvas text particle "+1" that rises and fades.

Snake head eyes: two small dark dots based on dir.

Particles:
```js
function burst(cx, cy) { // cell coordinates
  for (let i=0;i<14;i++){
    const a = Math.random()*Math.PI*2, sp = 40+Math.random()*120;
    particles.push({x:(cx+0.5)*CELL, y:(cy+0.5)*CELL, vx:Math.cos(a)*sp, vy:Math.sin(a)*sp, life:1, size:2+Math.random()*3, hue: 40+Math.random()*20});
  }
  particles.push({text:'+1', x:(cx+0.5)*CELL, y:(cy+0.5)*CELL, vx:0, vy:-40, life:1, size:16});
}
```
Update in render with dt (render receives t; compute frame dt there). Let me update particles in the frame loop with the clamped dt (works in all states, so the death puff also animates).

Eat flash: `eatFlash` 0..1 decays; draw a subtle radial glow at the food's eaten position? Simpler: a whole-board vignette pulse: alpha = eatFlash*0.15 lime. Plus the score element in the HUD scales (CSS class 'bump' with transition, retrigger). Let me do a HUD bump via CSS animation retrigger: remove/add class with a void offsetWidth reflow.

Pause: toggle between RUN and PAUSE with P/Escape (only in RUN/PAUSE states). Overlay text "PAUSED".

Ready state: overlay "SNAKE · ROT — press an arrow key to start". On an arrow/WASD keydown in READY: set the direction (if not reverse of the initial dir? The initial dir is right; pressing left would be a reverse — ignore? Or start moving right anyway? Better: on start, set dir to the pressed direction if it's not the reverse of right... if the player presses left (reverse), start moving right? Hmm, that's confusing. Options: start the snake facing right; on start, if the pressed key is left, ignore the direction (start moving right) — but the player expects to move left. Alternative: make the initial dir "none" and require a non-reverse press... the simplest and most robust: on start, if the pressed direction is not the reverse of the current dir (right), apply it; if it's left, start moving right (the snake can't reverse). Actually, the player pressing left at start: the snake is at the center facing right, body on the left. Moving left = immediately die (reverse into self). So ignoring left and moving right is correct and safe. Good: treat it like normal input: push the direction to the queue if valid (not the reverse of the last queued/current).

But note: in READY state, the snake isn't moving; when the first valid direction arrives, state=RUN. If the player only presses left, nothing happens (the snake stays ready). That's acceptable — left is a reverse at start.

Also, restart on game over: any key (except modifier keys) after a 500ms lockout → reset() and state = READY? Or straight to RUN? "Restart on key press, fully reset everything." Let me restart to the READY state (show "press an arrow to start") — hmm, that adds one extra key press. Alternatively, restart directly to RUN with the initial dir (right). The spec: "the game-over state shows the score and restarts on key press, fully resetting everything." Let me restart to READY with a "Press an arrow key to start" overlay — consistent and gives the player a beat. Hmm, but "restart on key press" suggests the key press restarts the game. Restarting to a ready state where one more key starts it is also a restart (the game state is fully reset). I think that's fine and better UX. Actually, let me reconsider: the simplest interpretation — the key press restarts the game (the snake starts moving). But if the snake starts moving immediately on the same key press: if that key is a direction, use it (if valid). That's snappy: die → press up → the game restarts and moves up. I like that: on OVER, any key → reset(); if the key is a direction and valid, queue it and state=RUN, otherwise state=READY. Hmm, but "any key" includes P (pause) — pressing P to restart is weird, but acceptable. Let me exclude P/Escape from the restart keys... The spec says restart on key press. Let me accept any key except Shift/Control/Alt/Meta/Tab. And P/Esc... well, let me accept them too (they're keys). Actually, if the player is mashing P to pause and dies, they'd accidentally restart — the 500ms lockout mostly handles that. Let me keep it simple: any keydown (not repeat, not a modifier) restarts after the lockout.

Wait, there's also the READY state: "press an arrow key to start" — but any key? Let me keep it: in READY, direction keys start the game; other keys do nothing (or any key starts moving right? No — require a direction key so the player has control of the first move). Show "press an arrow key or WASD to start".

Pause key handling: P or Escape toggles pause only in RUN or PAUSE. In READY/OVER, ignore.

Prevent scrolling: e.preventDefault() on handled keys: arrows, space, WASD, P, Escape. Space: not used for the game... but the user might expect space to pause? Not required. Let me not bind space (avoid preventDefault on space? If space isn't handled, the page might scroll — the page is probably short and won't scroll; but for safety, preventDefault on space too? If we don't use space, preventDefault on it to avoid scroll/jump — hmm, but that blocks accessibility... the page is a game; let me preventDefault on arrows + space + WASD + P + Escape. Actually, preventDefault on WASD is harmless.

Hmm wait — should Space do something? The twist is automatic (rot), so no extra key needed. Good, one mechanic, no extra keys.

HUD: score, best, length. Also show a "rot" indicator? The ring on the food is the indicator. Maybe show a small "next rot" bar? The ring is enough.

localStorage: key 'snake-rot-best'. try/catch.

Overlay HTML:
```html
<div class="overlay" id="overlay">
  <div class="overlay-card">
    <div class="overlay-title" id="ovTitle">SNAKE · ROT</div>
    <div class="overlay-sub" id="ovSub">Press an arrow key to start</div>
  </div>
</div>
```
States: ready (title "SNAKE · ROT", sub "Press an arrow key or WASD to start"), paused ("PAUSED", "Press P or Esc to resume"), over ("GAME OVER", "Score 12 · Best 34 — press any key to restart"). Manage via a function setOverlay(kind).

The overlay is shown/hidden via a class. The overlay must not block... it's a visual thing; pointer-events none.

CSS: center the layout, dark theme, monospace-ish font (system font: ui-monospace, SFMono, Menlo, Consolas, monospace) — arcade feel. Title with letter-spacing. kbd styling.

Board wrap: position relative; canvas display block; overlay absolute inset 0, display flex center, background rgba(5,8,12,0.72), maybe backdrop-filter blur(2px) (fine offline).

Score bump animation:
```css
@keyframes bump { 0%{transform:scale(1)} 40%{transform:scale(1.35)} 100%{transform:scale(1)} }
.value.bump { animation: bump .25s ease; }
```
Retrigger: el.classList.remove('bump'); void el.offsetWidth; el.classList.add('bump');

Now, drawing details:

Checkerboard: for each cell, fill with color A/B. 576 fills per frame is fine. Or pre-render the board background to an offscreen canvas once (and on resize) —

Empty directory. Building the game. My twist: **"Rot"** — each apple has a shrinking time ring (measured in ticks, so it drains faster as the snake speeds up). If the ring empties before you eat it, the apple rots and disappears, and you lose one tail segment. Trade-off: chase the apple to grow and score, or play safe and shrink.

Write index.html in chunks: first write (head + CSS + HTML), then append the JS in 2 edits.

Next, I'll add JS Part 1: constants, state, canvas setup, background pre-rendering, reset, food, step, rot, die.

Next, Part 2: rendering (board, food with ring, snake with head/eyes, particles, flash), input handling, main loop, initialization.

Alright, let me read the file back and verify its completeness and consistency.

The file is complete. Let me review potential issues:

1. **`lastBump` variable** — declared but unused. Harmless, but I'll remove it for cleanliness.

2. **`e.repeat` check before `preventDefault`**: on repeat of arrow keys, since it early-returns, the page will scroll on held-down arrow keys. Hmm — "the keys the game uses must not scroll the page." If the user holds down ArrowUp, after the first keydown, repeats will scroll the page. The page is 720px + header + twist + controls — on a typical laptop with ~800px viewport height, the page might be scrollable. To be safe, I should `preventDefault` even on repeats of game keys. Move `preventDefault` before the `e.repeat` check.

3. **Restart key handling**: in the OVER state, any non-modifier key triggers a restart. This includes `KeyP`/`Escape` (no problem) and `Space` (no problem). But wait — what about keys like `F5`? e.code is "F5", not in HANDLED, not a modifier → restart. Well, that's acceptable ("restart with any key"). But F5 is browser refresh — actually, F5's keydown can't be prevented, and the browser will refresh anyway. Not a problem.

   One subtle point: in the OVER state, if the user presses `KeyW` (a direction key), reset → READY → then `enqueue(d)` and state=RUN. Good.

   But there's a bug: after `reset()`, `dir = {x:1,y:0}` and the queue is empty. If the pressed key is `KeyA`/`ArrowLeft` (reverse direction), `enqueue` ignores it, and state stays RUN with dir=right. The snake starts moving right. Good, safe.

4. **Pause during OVER?** P/Esc in the OVER state: the OVER branch handles all keys first (returns), so P restarts. No problem.

5. **Direction keys during pause are ignored** — as designed.

6. **`step()` when the queue contains a reverse of the current dir**: the while loop skips invalid ones and tries the next. Good.

7. **Self-collision check**: `solid = snake.length - (eating ? 0 : 1)`. When eating, the tail stays (grows), so all cells are solid. Correct.

8. **`rot()` after eating on the same tick**: after eating, spawnFood sets foodLife=96, then `foodLife--` → 95. No problem.

9. **`die()` inside the while loop in `frame()`**: after step() returns (die sets state to OVER), the loop checks `state !== ST.RUN` → break, acc=0. Good.

10. **`render(t)` when state is READY**: draws the board + food + snake. Food is drawn with a ring at full. Good.

11. **`drawFood` when `food` is null (board full)**: early return. In that case, the snake can't eat; the game continues until it dies. Acceptable as an edge case (576 apples — practically unreachable).

12. **`ctx.lineCap = "round"`** persists across frames — harmless.

13. **`ctx.textAlign = "center"`** persists — only used in floaters; harmless.

14. **`backdrop-filter`** — fine offline.

15. **`aria-live="polite"` on the hud** — updates every tick via updateHud? updateHud sets textContent every tick (8 times/sec) — aria-live announcing every tick is noisy for screen readers. Minor; should I remove aria-live or set it only on score? Simpler: remove the aria-live attribute. Actually, keeping it minimal: remove it.

16. **Canvas CSS `width:100%; height:auto`** — the canvas element's width/height attributes are set to 720*dpr by fitCanvas; CSS width 100% (720px within .wrap) and height auto → aspect ratio preserved. Good. On smaller screens it scales down; drawing coordinates remain in 720 CSS px space. Good.

17. **`e.preventDefault()` on Space**: Space is in HANDLED → preventDefault. The game doesn't use Space, but this prevents page scroll / button re-triggering. OK.

18. **Restart lockout is 450ms** — good.

19. **`diedAt` initial value 0** — no problem.

20. **`bump(elBest)` when best is updated** — good.

21. **`updateHud` inside `rot()`** — updates the length display. Good.

22. **Score display on the "over" overlay**: `score >= best` — since die() updates best to score if score>best, when a new record is set, score==best → the flash is displayed. If score is 0, no flash (score > 0 check). Good.

23. **First frame**: `lastT = performance.now()` at script evaluation; the first rAF's t is slightly after. dt is small. Good.

24. **Potential issue: `fitCanvas` on resize re-bakes the background — no problem.**

25. **`HANDLED` includes "Space"** — but Space's keydown in the OVER state triggers a restart (any key). No problem.

26. **Modifier key check after preventDefault**: Ctrl+arrow keys → preventDefault is called (arrows don't scroll anyway), then return. OK.

27. Another one: **`e.repeat` early return** — after moving preventDefault before the repeat check, held-down arrow keys won't scroll.

28. **`queue` on pause**: direction keys during pause are ignored, so the queue doesn't grow. Good.

29. **`enqueue` in READY state when the player presses the same direction as dir (right)**: `d.x === last.x && d.y === last.y` → ignored, but state=RUN still executes. The snake starts moving right. Good.

30. **`elOvLines.innerHTML` with escaped quotes** — in the written file it's `\"big\"` and it renders correctly as `class="big"`. Confirmed in the read output: `<span class=\"big\">` — wait, the read output shows `elOvLines.innerHTML = "<span class=\"big\">Eat the apples...` — hmm, in the actual file it's `\"` inside a JS string delimited by double quotes. That's valid JS. Good.

31. **`−1` floater** uses U+2212 minus — no problem, UTF-8.

32. **`★` character** — no problem.

33. **Tick speed and rot**: LIFE_TICKS=96 ticks. At start: 96 × 125ms = 12 seconds. At max speed (65ms): 6.24 seconds. The description says "a shrinking ring of time" without a fixed number of seconds — good, I avoided hard-coding a wrong number of seconds.

34. **`updateHud` is called every tick** — setting textContent of 3 elements 8–15 times/sec is cheap.

35. **`stepParticles` runs in all states** — particles decay during pause too. Minor: particles freeze? No, they keep animating during pause (dt keeps flowing). That's fine / actually looks good (the eat burst finishes during pause).

36. **`eatFlash` decays even during pause** — no problem.

37. **Guard `guard++ < 8`** — prevents spiral of death; with dt clamped to 100ms and tickMs ≥ 65, max steps per frame = 100/65 ≈ 1.54 → 2. The guard of 8 is plenty.

38. **`ctx.drawImage(bg, 0, 0, CSS_SIZE, CSS_SIZE)`** — the bg canvas is 720*dpr px; drawn scaled to 720 CSS units under the dpr transform → correct 1:1 device pixels. Good.

39. **`roundRect` custom function** — avoids relying on the newer `ctx.roundRect` API. Good for compatibility.

40. **`ctx.ellipse`** — widely supported. No problem.

Fixes to apply:
- Move `preventDefault` before the `e.repeat` check.
- Remove the unused `lastBump`.
- Remove `aria-live="polite"` (noisy per tick) — or keep it? Screen readers would read out "0" 8 times per second. Remove it.

Also, a small improvement for "responsive input": the queue cap of 3 is good.

Another consideration: in the OVER branch, `reset()` is called and then `setOverlay("ready")` — but if the key is a direction key, it's immediately overwritten with `setOverlay(null)`. A slight flicker of the ready overlay for one frame? Both happen synchronously before the next paint, so no visible flicker. No problem.

Edge case: in OVER, `e.code` could be something like "ShiftLeft" → not a modifier key (metaKey/ctrlKey/altKey are false) → restart. Shift is arguably a modifier key; should I also check `e.shiftKey`? The spec says "restart with any key" — Shift counts as a key too. Leave it as is.

Edge case: `KeyP` while paused → resume. `Escape` while paused → resume. Good.

Let me also double-check the "no reverse" logic in enqueue: moving right (dir=1,0), press up → queue=[up]. Press left → last=up, left is not a reverse of up → queue=[up,left]. Next tick: dir=up. Tick after: dir=left. Correct — a 180° turn across two quick key presses is legal (a U-turn), which is the expected behavior.

Press up, then down quickly: last=up, down is a reverse of up → ignored. Good.

Now, the `while (queue.length)` loop in step(): suppose the queue is [up, down] — can't happen because enqueue prevents a reverse against the last queued item. But the queue can contain an item that becomes a reverse of dir due to other shifts... e.g., dir=right, queue=[up, left]: tick 1 → dir=up (shift up). Tick 2: shift left; is left a reverse of up? No (reverse of up is down). dir=left. No problem. Can the queue contain a reverse of the current dir? dir=right, press up (queue=[up]), press left (queue=[up,left]), tick: dir=up. Queue=[left]. Tick: left is not a reverse of up. OK. Suppose dir=up, queue=[left, down]? enqueue: last=left, down is not a reverse of left → allowed. Tick: dir=left. Next tick: shift down; is down a reverse of left? No. dir=down. No problem — the while loop is just a safety net.

Alright, let me apply the three small fixes.

Next, I'll verify the JS syntax with node (extract the script and run a syntax check). Also, I'll check whether there are any external references (no http://, no src=, no @import).

The JS syntax is valid, and there are no external references. Next, I'll do a headless logic test of the game mechanics — I can stub out the DOM/canvas in Node and simulate the game loop to verify the following:

1. That the snake moves, eats, and grows.
2. That food does not spawn on top of the snake.
3. That rot (decay) shrinks the snake (with a minimum length).
4. That it dies on walls and on self-collision.
5. That it doesn't reverse.
6. That the tick speed has a lower bound.

I'll write a harness that stubs `document`, `window`, `localStorage`, `performance`, and `requestAnimationFrame`, load the script, and then drive the internal functions. Problem: the script is an IIFE? No — it's a plain script using top-level `const`/`let` and function declarations. If I load it via `vm` or eval in Node, the functions will be in scope and I can access them. I'll use `vm.runInThisContext`, or just eval it in a context where the stubs are defined.

Plan: create a test file that defines the stubs, then `require`/eval the game JS, and then call the functions. Since the game JS uses `document.getElementById`, `canvas.getContext`, `window.addEventListener`, `performance.now`, `requestAnimationFrame`, and `localStorage`, I'll stub all of them.

The canvas context stub needs: setTransform, fillRect, beginPath, moveTo, lineTo, stroke, fill, arc, ellipse, closePath, arcTo, drawImage, save, restore, fillText, and properties (fillStyle, etc.) — a Proxy that returns no-op functions for any property access will work.

After that, I can call `reset()`, `step()`, etc. But these are top-level `function` declarations in the eval'd script — if I eval in the same scope (indirect eval = global), the function declarations become global. I'll use `vm.runInThisContext(code)`, which makes top-level function declarations… In Node's vm, `runInThisContext` executes in the global context; function declarations become properties of the global object. `const`/`let` don't become global properties, but they're accessible from subsequent runInThisContext calls (they live in the global lexical environment). So I can run the test code in the same context.

Let me write the harness:

```js
// stubs
const noop = () => {};
const ctxStub = new Proxy({}, { get: (t, p) => {
  if (p === 'canvas') return canvasStub;
  return noop;
}, set: () => true });
```

Hmm, Proxy get returns noop for everything — but some properties get set (fillStyle) — the set trap returns true. `createRadialGradient` needs to return an object with addColorStop — the noop function returns undefined → `g.addColorStop` throws. Special-case it: if the property is 'createRadialGradient' or 'createLinearGradient', return () => ({ addColorStop: noop }).

document stub:
```js
const elements = {};
function makeEl(id){ return {
  id, textContent:'', innerHTML:'', className:'',
  classList: { add:noop, remove:noop, contains:()=>false },
  style:{}, offsetWidth:0,
  width:0, height:0,
  getContext: () => ctxStub,
  addEventListener: noop,
};}
global.document = {
  getElementById: (id) => elements[id] || (elements[id] = makeEl(id)),
  createElement: (tag) => makeEl('canvas'),
};
global.window = { addEventListener: noop, devicePixelRatio: 1 };
global.localStorage = { getItem: () => null, setItem: noop };
global.performance = { now: () => Date.now() };
global.requestAnimationFrame = noop;
```

Wait — the game calls `window.addEventListener("keydown", ...)` and `window.addEventListener("resize", ...)`. I want to capture the keydown handler so I can simulate keys. Let me capture it in a list.

After that, run the game code with vm.runInThisContext. Then run the tests:

```js
// access: reset, step, snake, dir, ... — const/let live in the global lexical scope;
// accessible from subsequent runInThisContext snippets.
```

Test scenarios:
1. After reset: snake length is 3, food exists and is not on the snake.
2. Force food in front of the snake: set food = {x: snake[0].x+1, y: snake[0].y}; step(); → length 4, score 1, new food not on the snake.
3. Reversal: set dir to right; call the keydown handler with ArrowLeft → dir unchanged / not enqueued.
4. Wall death: place the snake's head at x=23 facing right, step → state is OVER.
5. Self-collision: build a snake of length 5 in a coil; force the head to move into its own body → OVER.
6. Rot: set foodLife=1, place food far away, step → snake shrinks by 1 (if >3), new food spawns, foodLife=96.
7. Minimum length: length 3, foodLife=1, food far away, step → length stays 3.
8. tickMs lower bound: set snake length to 100 → currentTickMs() === 65.
9. Keydown in OVER state: after die, wait (diedAt uses performance.now — my stub uses Date.now; the lockout is 450ms — I can stub performance.now to be controllable). Simpler: make performance.now a mutable variable.

I'll make performance.now controllable: let nowMs = 0; global.performance = { now: () => nowMs }.

I'll write this test file to /tmp and run it with node.

Wait — the test file references `snake`, `dir`, `state`, `reset`, `step`, `food`, `foodLife`, `tickMs`, `currentTickMs`, `els`, etc. The game code is executed via `vm.runInThisContext` — top-level `function` declarations become properties of the global object (accessible). Top-level `let`/`const` go into the global lexical environment, and are accessible from subsequent `runInThisContext` scripts, but the test file itself is a regular Node module — it can't directly reference those lexical bindings!

`vm.runInThisContext` in Node: does code share the global lexical environment with…? No. Each `runInThisContext` call has its own… Actually, in Node, `vm.runInThisContext` compiles the code in the current global context. Top-level `let`/`const`/`class` create bindings in that context's "global lexical environment," and this persists across subsequent `runInThisContext` calls within the same realm (this is how the REPL works). But a regular module's scope is not part of that — module code can't directly reference those bindings.

So in the test file, I can't directly reference `snake`, `dir`, etc. I need to either run the test assertions via `vm.runInThisContext` as well, or have the game code expose a test hook.

The simplest approach: wrap the entire test body (after loading the game) in a string and run it with `vm.runInThisContext`. But the test uses `require`, `fs`, `process`, `console` — those are accessible from the global context too (console, process are globals; require is not). I can avoid require in the test body.

Alternative: add a small test hook to the game… but I don't want to pollute the shipping file. Better approach: in the test file, after loading the game, run the test code with `vm.runInThisContext(testBody)`, and pass in the helpers via globals (check, key, onSnake, els, listeners, nowMs setter, etc.).

Let me restructure:

- In the Node module: set up stubs, define `global.__check`, `global.__key`, `global.__setNow`, `global.__els`, etc.
- Load the game with `vm.runInThisContext(js)`.
- Build a string of the test body that references the game's globals (`snake`, `dir`, `state`, `reset`, …) and my own helper globals.
- Run it with `vm.runInThisContext(testBody)`.
- Collect results in `global.__results`, and in the module print them and set the exit code.

One caveat: `state` is a `let` binding — accessible from subsequent runInThisContext scripts. Yes, same realm.

Also, the game code references `document`, `window`, `localStorage`, `performance`, `requestAnimationFrame` — all defined as globals. Good.

Note: the game's `reset()` calls `updateHud()`, which uses `document.getElementById(...)` — stubbed. `setOverlay` uses els — no problem. `bump` uses classList — no problem.

The game's `fitCanvas()` runs at load time: it sets canvas.width (stub el), ctx.setTransform (noop), bakeBackground → bg canvas = document.createElement → makeEl → getContext → proxy. `b.createRadialGradient` → returns {addColorStop}. Good.

`requestAnimationFrame(frame)` → noop, so the loop never runs — I'll drive `step()` manually. Good.

One issue: the game's keydown handler is registered on `window` — captured in `listeners.keydown`. Good.

In test 10 (restart): after `die()`, `diedAt = performance.now()` = nowMs (0 at that point… note that nowMs has been accumulating). I'll manage nowMs carefully: it starts at 0. During the test, die happens at some nowMs value. Then `nowMs += 100` → within the lockout → key is ignored. Then `nowMs += 500` → key works.

But wait: in test 10, after the restart via `key("ArrowUp")`: the handler does `reset(); state=READY; setOverlay("ready"); d=DIRS["ArrowUp"]; enqueue(d); state=RUN;`. `enqueue`: queue is empty, last=dir={1,0}; up is not the same/reverse → gets enqueued. state=RUN. But `dir` is still {1,0} until the next `step()` consumes the queue! My check `dir.x === 0 && dir.y === -1` will fail, because dir only updates on step.

Fix: call `step()` after the restart key and then check dir. But step also moves the snake: head (12,12) + up → (12,11). Then check that the snake moved up. Let me adjust: after key("ArrowUp"), call step(), and check dir === up and snake[0].y === 11.

Note though: food might be at (12,11) → eating. That's fine, the check still holds (dir is up, head is 12,11).

Also test 3: after `reset()`, `key("ArrowUp")` — state is READY → enqueue + state=RUN. dir is still {1,0} until step. So the "reversal blocked" test needs a step() in between to actually set dir. Let me redo test 3:

```
reset();
key("ArrowUp");   // READY -> RUN, queue=[up]
step();           // dir=up, snake moves up
key("ArrowDown"); // reverse of up -> ignored
check(dir still up)
key("ArrowLeft"); // valid, queued
step();           // dir=left
key("ArrowRight");// reverse of left -> ignored
check(dir is left)
```

Also in test 3, the original check "same direction is ignored" — enqueue ignores the same direction; but the dir check after key() without step is meaningless. I'll remove that.

Test 4 (wall): snake's head at x=23 facing right, step → die. But food might be somewhere; no problem. Note: after `reset()`, I overwrite snake/dir/queue directly — those are `let` bindings in the global lexical environment; can I reassign them from a subsequent runInThisContext script? Yes — same realm, same bindings.

Wait, actually — one subtle point: `vm.runInThisContext` — do top-level `let` bindings of a previous runInThisContext script really persist and are they accessible from later scripts? Yes. This is the REPL behavior: Node's REPL wraps each line in a context where previous let/const are visible. Internally the REPL uses `vm` with a shared context… hmm, let me think. Node's REPL: each input is compiled and run in the same context; top-level `let`/`const` are accessible from subsequent inputs. The REPL uses `vm.Script` with a context… Actually, I recall that the REPL historically wrapped input in a function to avoid leaking let/const, and there were issues with let/const across REPL lines…

Let me not rely on uncertain behavior. Safer approach: wrap the game code so it exposes what I need. I can transform the loaded JS: append an export line at the end:

```js
globalThis.__G = { get snake(){return snake}, set snake(v){snake=v}, ... };
```

But I can't easily create getters for `let` bindings… actually I can: `get snake(){ return snake; }` — the getter's closure captures the lexical binding. And a setter `set snake(v){ snake = v; }` also works with let. So:

```js
const hook = `
globalThis.__G = {
  get snake(){ return snake; }, set snake(v){ snake = v; },
  get dir(){ return dir; }, set dir(v){ dir = v; },
  get queue(){ return queue; }, set queue(v){ queue = v; },
  get state(){ return state; }, set state(v){ state = v; },
  get food(){ return food; }, set food(v){ food = v; },
  get foodLife(){ return foodLife; }, set foodLife(v){ foodLife = v; },
  get score(){ return score; }, set score(v){ score = v; },
  get best(){ return best; }, set best(v){ best = v; },
  get tickMs(){ return tickMs; },
  reset, step, die, rot, enqueue, currentTickMs,
};
`;
vm.runInThisContext(js + hook);
```

And in the test module, I use `const G = globalThis.__G` and access `G.snake`, etc. Function declarations are accessible either way, but the hook makes everything explicit and robust regardless of vm's lexical scoping semantics.

This is solid. Let me rewrite the test file accordingly.

Also for the "best" test: `els.best.textContent` — the stub element's textContent is set by updateHud. Good.

Test 12: after reset, place food in front, step → score 1, best 1, localStorage "1". But note: `loadBest()` at load time reads localStorage._v = null → 0. Good.

Also note: in the eating test, `step()` also decrements the new food's foodLife (96 → 95). My check "new food ring is full" expects 96 — it will fail! Let me re-check the order in step():

```
if (eating){ ... spawnFood(); }  // foodLife = 96
...
if (food){ foodLife--; if (foodLife <= 0) rot(); }  // 96 -> 95
```

So after an eating step, foodLife = 95. Hmm. This is a 1-tick (about 125ms) offset — functionally fine, but my test expects 96. Which behavior do I want? Cleaner would be: decrement the old food's lifetime before the eating check? Or skip the decrement if we just spawned? The simplest and most correct semantics: the lifetime should count ticks since spawn. If I decrement after spawn, the new food's first tick is consumed immediately. To make the ring start exactly full and drain once per tick after spawn, I should only decrement the lifetime of food that existed before this tick's movement. Let me restructure step():

```
// ROT: drain the current apple (the one that was on the board during this tick)
if (food){
  foodLife--;
  if (foodLife <= 0) rot();   // rot() spawns a new food with a full ring
}
```

Place this before the movement? No wait — the order matters for whether you can eat food on the same tick it rots. If I drain first: foodLife 1 → 0 → rot() → new food spawns elsewhere. The old food is gone; you can't eat it on that tick. If I drain after: on the tick when foodLife reaches 0, you can still eat it (eat first, then the new food's life is decremented to 95).

Which is better for gameplay? "If the ring runs out before you eat it" — on the tick the ring hits 0, the apple rots. If the head reaches the apple on exactly that tick, is that "before it rots"? A race condition. Draining before movement is cleaner: the ring you see is exactly the number of ticks you have left to eat it. When the ring hits 0, the apple is gone before the snake moves. This is predictable and matches the visual (ring empty = apple gone).

But note: rot() spawns new food before the snake moves this tick — the snake could theoretically eat the new food on the same tick (if it spawns exactly in front of the head). That's fine/fun.

So restructure step():

```
function step(){
  // consume turn
  ...
  // ROT: the apple's lifetime drains one tick at a time
  if (food){
    foodLife--;
    if (foodLife <= 0) rot();
  }
  const head = ...
  ...
  if (eating){ ... spawnFood(); } else { snake.pop(); }
  tickMs = currentTickMs();
  updateHud();
}
```

Now, after an eating step, the new food's foodLife = exactly 96. And the ring displays the exact number of ticks remaining.

Edge case: rot() on the same tick the snake eats… can't happen — if the food rotted, a new food spawned; `eating` is computed against the new food. No problem.

Let me apply this reordering to index.html and update the tests accordingly (after an eating step, foodLife === 96; after a rot step, the new food's foodLife === 96).

Also re-check test 7 (rot): foodLife=1, food at (0,0), head at (12,12) moving right → drain: 1→0 → rot: length 4→3, new food. Then head moves to (13,12). Check length 3 ✓, new food off snake ✓, foodLife 96 ✓ (rot's spawnFood sets 96, and since the drain happens before the movement, there's no further decrement this tick).

Wait — but in the new order, the drain happens before the movement. In test 7, rot happens, then the snake moves. Good.

Test 8: length 3, foodLife=1 → rot, length stays 3 ✓.

Now, one more consideration about the reordering: `rot()` calls `updateHud()`, and then step calls `updateHud()` again — harmless.

Also the "eat" check: `eating` is computed after the drain — correct.

Let me apply the edit to index.html: move the ROT block before the head computation.

Current code:

```js
function step(){
  // consume the first valid queued turn (no direct reversals)
  while (queue.length){
    const d = queue.shift();
    if (d.x !== -dir.x || d.y !== -dir.y){ dir = d; break; }
  }

  const head = { x: snake[0].x + dir.x, y: snake[0].y + dir.y };

  // wall
  if (head.x < 0 || head.y < 0 || head.x >= COLS || head.y >= ROWS) return die();

  const eating = food && head.x === food.x && head.y === food.y;

  // self — the tail cell vacates this tick unless we grow, so it is safe
  const solid = snake.length - (eating ? 0 : 1);
  for (let i = 0; i < solid; i++){
    if (snake[i].x === head.x && snake[i].y === head.y) return die();
  }

  snake.unshift(head);

  if (eating){
    score++;
    ...
    spawnFood();
  } else {
    snake.pop();
  }

  // ROT: the apple's lifetime drains one tick at a time
  if (food){
    foodLife--;
    if (foodLife <= 0) rot();
  }

  tickMs = currentTickMs();
  updateHud();
}
```

New order: drain first.

Then rewrite the test file with the __G hook approach.

Next, rewrite the test harness using the `__G` hook approach (robust against vm's lexical scoping semantics), and fix the expected values for tests 3 and 10.