2048 · deepseek-v4-flash-0731

Let me create the 2048 game in index.html.

Let me think about the logic carefully. I'll write a robust implementation.

Key points:
- 4x4 board
- Arrow keys slide toward edge
- Merge once per tile per move
- Score increases by merged value
- Start with two tiles
- After a move that changes board, spawn one tile (90% 2, 10% 4)
- Don't spawn after unchanged move
- Animate movement and merging
- Prevent rapid input corrupting state (lock during animation)
- Prevent arrow keys scrolling page (preventDefault)
- Show score, win message on 2048, Game Over when no valid move
- New Game button, allow continue after win

Let me build this. I'll use a tile-based animation approach: track tiles as objects with row, col and value, and animate via CSS transforms.

Let me write a clean implementation. I'll represent tiles as an array of objects. Slide logic.

Let me write the code.

For animation: each tile element position can change. I'll assign tiles to cells. When sliding, compute target positions. Use CSS transitions on the tile's transform to animate movement. For merging, the merged tile slides to target position and then value updates.

Approach: Maintain a grid of tiles. On move, compute resulting moved tiles. For animation, I'll animate each existing tile to its new position, then after transition, apply merge (combine values into tiles). 

Simpler robust approach: use a grid of tile IDs in cells. On each move:
1. Compute next grid (values) from current.
2. For each tile currently present, determine its new cell. Animate transform.
3. For merged tiles, animate the surviving tile to the merged cell.

Let me implement with tiles that carry id. I'll store `board` as 4x4 of values (0 for empty), and `tiles` array of {id, value, r, c} for rendering.

Actually let me do the animation with a tile element per cell that exists. Let me structure:

- `grid`: 2D array of values.
- `tiles`: map tileId -> {id, value, r, c, el}
- `tileIdCounter`

On render: For each cell with value>0, ensure there's a tile. But for merging animation I need tile objects to move.

Let me implement move:

```
function move(dir) {
  const rBefore = grid.flatMap(r=>r); 
  // compute new grid
  const moved = computeMove(grid, dir, tiles);
  // returns {newGrid, moveLog}
}
```

This is getting complex. Let me simplify with a tile-based animation that's still correct.

I'll keep grid as source of truth, and tiles purely derived for display with animation. 

Animation approach:
- On each move, I compute the resulting grid.
- I compare to determine which tiles moved where, using a "shrink to left/right" algorithm.

Let me decompose: For each row (for horizontal move) or column (vertical), I process the line of cells.

I'll represent lines as arrays of tile objects (or nulls). 

Algorithm to animate a move along one direction across a line:

Let me define move processing on a line of 4 cells in the direction the tiles should slide (compress toward start index 0 = the edge we're moving toward).

Given current values line (with tile info), produce new values line. Also produce mapping: for each original tile, where it ends up.

Let me define direction:
- left: operate on rows, compress left.
- right: operate on rows, compress right (reverse line).
- up: columns, compress up.
- down: columns, compress down (reverse).

For each line, take the nonzero tiles in order. Then do the merge logic:
```
function processLine(tiles) {
  // tiles: array of tile objects (non-null), already in slide order
  result = new grid row of length 4, filled with 0
  out = []  // array of {value, mergedFrom:[ids]}
  let i = 0
  while (i < tiles.length) {
    if (i+1 < tiles.length && tiles[i].value === tiles[i+1].value) {
      // merge
      out.push({value: tiles[i].value*2, merged:[...]})
      i += 2
    } else {
      out.push({value: tiles[i].value})
      i += 1
    }
  }
}
```

Now for placement in output grid, first N out entries go to first N cells (in slide order direction).

For animation: 
- Each original tile that survives unmerged moves to its target cell.
- Each merged pair: both tiles animate to the target cell; then collapse into one tile showing doubled value.

Let me handle this with the tile object approach during the move:

I'll build the animation plan:
- For each line, compute `out` (list of target entries). Each entry has a target index (cell position in line order).
- Map original tiles to their target cell.
- For merged pairs, keep one tile (say the one further in slide order, or create a new tile at that cell after animation) — I'll animate both tiles to the target, then after transition, remove one and double the other's value.

Let me implement using actual DOM elements per tile.

Actually, let me use a cleaner strategy that avoids double-booking: I'll animate tiles by computing their destination cell from grid diff.

Let me do this concretely:

State:
- `board`: 4x4 values
- `tileObjs`: array of {id, value, r, c, el} — one per currently rendered tile element.

Rendering function `syncPositions()`: positions each tile element at its (r,c) cell using transform.

On move:
1. Lock input (isMoving = true).
2. Compute the move from current board. During computation, I'll also update tileObjs to reflect movement/merging, and record which tileEls are removed.
3. Set `transition` property on each tile element to enable animation.
4. Update board values immediately.
5. `requestAnimationFrame` twice (or use setTimeout) to allow style flush, then syncPositions to move tiles.
6. After transition duration (~150ms), remove merged-away tiles, update surviving tile values, spawn new tile (insert new tile at destination with pop-in animation), update score, check game over/win, unlock.

Let me be careful about the transition timing. The new tile spawn should happen after movement completes.

Let me code the move computation producing a plan.

I'll write a function `slide(board)` core and produce movement info.

Let me represent the plan per direction. For lines (rows or columns), I'll extract the tile objects.

Let me maintain tileObjs as a 4x4 grid? Actually easier: maintain `tileGrid` = 4x4 of tile ids (null if empty). And a dict id->tileObj. This maps directly.

So state:
- board values: 4x4
- tileGrid: 4x4 of tileId (or null)
- tilesById: map id -> tile object

On render sync positions from tileGrid.

Move algorithm on a line (array of 4 tileIds, as well as corresponding board values):

```
function processLine(ids, values) {
  // ids: 4 tileIds (null allowed) in slide order
  // returns {newIds, merges: [{fromId, toId, value}], moves:[{id, fromIdx, toIdx}]}
  const outIds = [null,null,null,null];
  const nonNull = []  // {id, value, fromIdx}
  for (let i=0;i<4;i++) if (ids[i]!=null) nonNull.push({id:ids[i], value:values[i], fromIdx:i});
  let outIdx = 0;
  let i = 0;
  while(i<nonNull.length){
    if (i+1<nonNull.length && nonNull[i].value===nonNull[i+1].value){
      outIds[outIdx]=nonNull[i].id; // survivor id from first
      moves.push({id:nonNull[i].id,to:outIdx});
      moves.push({id:nonNull[i+1].id,to:outIdx});
      merges.push({fromId:nonNull[i+1].id, toId:nonNull[i].id, value:nonNull[i].value*2, atIdx:outIdx});
      i+=2; outIdx++;
    } else {
      outIds[outIdx]=nonNull[i].id;
      moves.push({id:nonNull[i].id,to:outIdx});
      i++; outIdx++;
    }
  }
  return ...
}
```

Moves include all tiles that are placed (including ones not moving, but animation to same cell is harmless). I could filter to only moving ones, but no need.

After moving, the survivor tile of a merge needs to update its value and the merged tile removed. So:
- moves: each id moves to `to` position.
- merges: fromId disappears, toId value doubles.

Board values after move: outIds index -> value. For merged cell the value is doubled. For non-merged, original value.

Let me set: compute new board from newIds and merges.

Let me code it fully now. I'll write the complete index.html.

For the win: when a tile value reaches 2048, show win message once; but allow continuing. Keep a `won` flag so message shows once (or persistent banner with continue).

Game over: no empty cell and no adjacent equal values => game over. Check after each move (after spawning).

Let me consider: after win, game continues; if game over happens later it should show game over. Show win banner that remains (with continue). Actually simplest: show a message overlay "You win!" with Continue button. If they continue and eventually game over, show game over overlay. But if they've won, game over should maybe show "Game Over" too. I'll show overlay based on state: if gameOver show game over message; else if won show win message. On continue, hide overlay.

Let me write it.

Timer for animation: use transition duration 130ms. After syncing positions, setTimeout(140) to finalize.

Let me handle the double requestAnimationFrame for transition. Set transform after toggling transition class. I'll set all tile elements' transition in CSS by default (transform transition). Then on move, first sync to "from" positions while a `moving` class disables... hmm.

Simplest: tiles always have transition on transform. On move I:
1. update tileGrid (new positions) and merge info, but DON'T remove merged tiles yet or update values yet.
2. board values updated immediately for logic but tile values not yet changed for merged survivors.
3. Force reflow not needed since positions unchanged until I set new transform; transition animates automatically from old to new.
4. Set transforms to new positions. Tiles animate.
5. After timer, finalize: update survivor values, remove merged tiles and their elements, spawn new tile (with spawn animation), update score, check over.

This works because transition on transform animates any transform change automatically.

New tile: add a tile element at empty cell, give it spawn pop animation (scale from 0 with transition on transform via CSS keyframe).

Let me set row/col indices. Rows top=0..3, cols left=0..3. For direction up/down/left/right mapping to slide order.

Direction handling: I'll normalize by extracting lines and reversing for right/down.

Let me define:
- LEFT: lines = rows, order 0..3 (slide toward col 0)
- RIGHT: lines = rows, order 3..0 (slide toward col 3)
- UP: lines = columns, order 0..3 (slide toward row 0)
- DOWN: lines = columns, order 3..0 (slide toward row 3)

For processing, I extract the 4 tileIds and 4 values in slide order, call processLine, then write back into the appropriate line positions.

For reversed directions, I'll extract reversed then write back reversed. Let me just handle via helper that maps (lineIndex, cellInLine) to (r,c).

Let me write extraction and writeback generically based on direction:
- lineCount = 4
- For each line l (0..3):
  - getCell(l, pos, dir) returns {r,c}
  - pos 0..3 in slide order.
  - For LEFT: r=l, c=pos; RIGHT: r=l,c=3-pos; UP: r=pos,c=l; DOWN: r=3-pos,c=l.

Great.

Now for moves & merges, the `to` index is in slide order; convert to cell.

Let me code everything.

Let me now write the file.

I'll compute board existence check: if after move board unchanged (same array), don't spawn and unlock (no animation needed but could still just return). I'll detect change by comparing values before/after.

Let me track `moved` boolean: compare original board values to new board values.

Edge: a move that results in all tiles staying put (no merges) = unchanged => no spawn.

Now score: add merged values.

Let me write.

For rapid input protection: isMoving flag, also keydown ignored while isMoving.

For preventing scroll: preventDefault on arrow keys.

Now let me write the whole HTML.

I need to make sure game over and win checks.

Let me write the code now.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>2048</title>
<style>
*{box-sizing:border-box}
body{margin:0;font-family:...;background:...;display:flex;justify-content:center;}
...
</style>
</head>
<body>
...
<script>
...
</script>
</body>
</html>
```

Let me design layout: a container with header (title, score, best, new game button), board.

Board: I'll create a 4x4 background grid with cell placeholders, and overlay tile layer absolutely positioned.

Let me structure:
```
<div class="game">
  <header>
    <h1>2048</h1>
    <div class="scores">
      <div>SCORE <div id="score">0</div></div>
      <div>BEST <div id="best">0</div></div>
    </div>
    <button id="newGame">New Game</button>
  </header>
  <div class="board" id="board">
    <!-- 16 background cells -->
    <div class="tilelayer" id="tileLayer"></div>
  </div>
  <div class="overlay" id="overlay" hidden>...</div>
</div>
```

Tile positioning: board width e.g. 400px, padding 10, gap 10, cell size = (400-20-30)/4 = 87.5. Let me use CSS var for cell size. I'll compute positions via JS using board metrics (getBoundingClientRect) or fixed CSS. Let me use fixed sizes: cell size 100, gap 12, padding 10, board = 4*100+3*12+20 = 456. I'll position tiles at padding + col*(size+gap).

Tile element: width=size, height=size, positioned absolute, left/top absolute, and I'll use transform left/top plus a scale for spawn. Actually to animate transform I can set transform translate. Let me use `transform: translate(x,y)` for movement and add scale via keyframe for spawn on a child.

Let me set tile element with `transition: transform 130ms ease-in-out`. Position tiles via transform: translate(px,py). Set via JS `el.style.transform = 'translate('+x+'px,'+y+'px)'`.

For spawn animation, I need a separate scale transition. I'll add a keyframe animation on a wrapper or just set the tile's initial transform to translate + scale(0) then after reflow set to scale(1) with transition. Simpler: use CSS @keyframes pop {from{transform:scale(0)}to{transform:scale(1)}} applied to an inner span. Let me structure tile as:
```
<div class="tile" data-v>
  <span class="tile-inner"></span>
</div>
```
The outer positions via translate. The inner gets pop animation on creation.

Actually the outer transform is translate. Adding scale keyframe on same element conflicts with transform transition. So use inner element for scale animation.

Let me implement:
```
.tile{position:absolute; ... transition: transform .13s ease-in-out;}
.tile-inner{width:100%;height:100%;border-radius:...;display:flex;align-items:center;justify-content:center;font-size:...;font-weight:bold;color:#776e65;}
.tile.spawn .tile-inner{animation:pop .15s ease;}
@keyframes pop{0%{transform:scale(0);opacity:0}100%{transform:scale(1);opacity:1}}
```

Values and colors: standard 2048 tile colors.

Now let me write the JS.

```js
const SIZE=4;
let board, tileGrid, tileById, nextId, score, best, isMoving, won, gameOver;
const boardEl=..., layerEl=...; 

function init(){
  board=Array.from({length:SIZE},()=>Array(SIZE).fill(0));
  tileGrid=Array.from({length:SIZE},()=>Array(SIZE).fill(null));
  tileById={};
  score=0; won=false; gameOver=false; nextId=1;
  layerEl.innerHTML='';
  updateScore();
  spawnTile();spawnTile();
  updateOverlay();
}
```

spawnTile:
```
function spawnTile(){
  const empties=[];
  for r,c if board[r][c]===0 push [r,c];
  if(!empties.length) return;
  const [r,c]=empties[Math.floor(Math.random()*empties.length)];
  board[r][c]= Math.random()<0.9?2:4;
  const id=nextId++;
  tileGrid[r][c]=id;
  createTileEl(id, r,c, board[r][c], true);
  syncTile(id,r,c);
}
```

createTileEl:
```
function createTileEl(id,r,c,val,animate){
  let el=document.createElement('div');
  el.className='tile'+(animate?' spawn':'');
  el.innerHTML='<span class="tile-inner"></span>';
  el.dataset.id=id;
  layerEl.appendChild(el);
  tileById[id]={id,r,c,val,el};
  updateTileVisual(id);
  // set initial transform
  el.style.transform='translate('+x(r,c)+'px,'+y(r,c)+'px)';
}
```

Hmm need x,y functions from (r,c):
```
function cellPos(r,c){ // returns {x,y}
  x = PAD + c*(CELL+GAP);
  y = PAD + r*(CELL+GAP);
}
```

syncTile positions el.

updateTileVisual sets tile-inner text and background color:
```
function tileVisual(el,val){
  const inner=el.querySelector('.tile-inner');
  inner.textContent=val;
  el.className = 'tile' + (wasSpawn?' spawn':''); // keep spawn class
  set background via data-v
}
```
For colors, use classes or inline style based on value. Let me use inline background.

Let me handle spawn class: when creating with animate, keep class 'tile spawn'. The pop animation runs once. If I set className each update it may restart. Let me not reset className during normal updates. I'll give element background via style based on value and a text color computed.

Let me store on element: `el.style.background = colorFor(val)`, `inner.style.color = textColorFor(val)`, `inner.style.fontSize` for large numbers.

Simplify colors: function returns CSS color string.

Now move handling keydown:
```
document.addEventListener('keydown',e=>{
  const dirs={ArrowLeft:'left',ArrowRight:'right',ArrowUp:'up',ArrowDown:'down'};
  if(e.key in dirs){
    e.preventDefault();
    if(!isMoving && !gameOver) moveDirs[e.key];
  }
});
```
Allow continue after win: not blocked (only gameOver blocks, and after win continue allowed). Good.

move(dir):
```
function move(dir){
  isMoving=true;
  const before = board.map(r=>r.slice());
  const merges=[];
  let moved=false;
  // new tileGrid for placement
  forEach line...
  // compute new board
  ...
  // if no change -> unlock, return
  ...
}
```

Let me write the line processing to fill newBoard and newTileGrid, plus collect merges and moved tiles.

I'll create newBoard and newTileGrid (grid of ids).

```
function move(dir){
  isMoving=true;
  const before=board.map(r=>r.slice());
  const newBoard=Array.from({length:SIZE},()=>Array(SIZE).fill(0));
  const newTileGrid=Array.from({length:SIZE},()=>Array(SIZE).fill(null));
  const merges=[]; // {fromId,toId,value,cell}
  const slideOrder = [0,1,2,3];
  let anyMerge=false;
  for(let l=0;l<SIZE;l++){
    // extract line in slide order
    const ids=[],vals=[];
    for(let pos=0;pos<SIZE;pos++){
      const {r,c}=cellFromLine(dir,l,pos);
      ids.push(tileGrid[r][c]); vals.push(board[r][c]);
    }
    // process
    const res = processLine(ids,vals);
    if(res.changed) anyMerge? // processLine sets changed if merged
    // write back
    for(let pos=0;pos<SIZE;pos++){
      const {r,c}=cellFromLine(dir,l,pos);
      newTileGrid[r][c]=res.ids[pos];
      newBoard[r][c]=res.vals[pos];
    }
    // collect merges with cell positions
    for(const m of res.merges){
      const {r,c}=cellFromLine(dir,l,m.atIdx);
      merges.push({fromId:m.fromId,toId:m.toId,value:m.value,r,c});
    }
  }
  // detect changed
  let changed=false;
  for r,c if(before[r][c]!==newBoard[r][c]){changed=true;break;}
  if(!changed){ isMoving=false; return; }
  // animate
  // set tileGrid to newTileGrid
  tileGrid=newTileGrid;
  board=newBoard;
  // sync positions of all tiles
  for id in tileById: reposition to tileGrid position (find where id is)
  // merged: mark from tiles to be removed
  for m of merges: m.toId survivor value becomes m.value
  // after timer: remove from tiles, update values, spawn, score
  setTimeout(()=>{
    for(const m of merges){
      removeTile(m.fromId);
      setTileValue(m.toId,m.value);
      score+=m.value;
    }
    updateScore();
    spawnTile();
    if(inDeadlock()) {gameOver=true; updateOverlay();}
    else if(score... ) // win check
    isMoving=false;
  }, 150);
}
```

But there's an issue: syncPositions needs to know each tile's new cell. Since tileGrid is updated, I can loop over tileGrid and for each non-null id set its position. That covers all tiles. Let me do that.

Also need to ensure transition animates: the tile elements already have transition:transform. When I update transform after board changed, it animates. But for tiles that don't move, transform stays same (no change) fine.

But wait, timing: I update tileGrid then immediately set transforms in same synchronous block. Transitions will animate from previous transform to new. Good. The browser will start transition. Then setTimeout(150) > 130 transition, finalize.

But careful: if I set transform in same tick the transition works because style changed between paint frames; the browser batches. Since previous frame had old transform, next with transition animates. Works.

Let me reposition each id:
```
function repositionAll(){
  for r,c id=tileGrid[r][c]; if(id!=null){ const o=tileById[id]; const {x,y}=cellPos(r,c); o.el.style.transform='translate('+x+'px,'+y+'px)';}
}
```

removeTile(fromId): remove el, delete from tileById. Must not be in tileGrid anymore (it isn't after newTileGrid). Good.

setTileValue(id,val): tileById[id].val=val; update visual.

Win check: after spawning, if any tile value===2048 and !won -> won=true, show overlay win. But overlay show needs updateOverlay.

processLine:
```
function processLine(ids,vals){
  const res={ids:[null,null,null,null],vals:[0,0,0,0],merges:[]};
  const items=[];
  for(let i=0;i<SIZE;i++) if(ids[i]!=null) items.push({id:ids[i],val:vals[i]});
  let outIdx=0,i=0;
  while(i<items.length){
    if(i+1<items.length && items[i].val===items[i+1].val){
      res.ids[outIdx]=items[i].id;
      res.vals[outIdx]=items[i].val*2;
      res.merges.push({fromId:items[i+1].id, toId:items[i].id, value:items[i].val*2, atIdx:outIdx});
      i+=2; outIdx++;
    } else {
      res.ids[outIdx]=items[i].id;
      res.vals[outIdx]=items[i].val;
      i++; outIdx++;
    }
  }
  return res;
}
```

This assigns merges at outIdx which is the merge target cell index in slide order. Good. The survivor tile id is items[i].id (the first of pair). It stays and its value doubles. Good.

Now note: when merging, both tiles still animate to the target position? The survivor (first) and the second both should animate to outIdx. In repositionAll, I position by tileGrid which has survivor at outIdx (from line, id=items[i].id placed at outIdx). The second from tile (fromId) is not in newTileGrid, so it's removed but not repositioned — it stays at its old position, then disappears at finalize. Visually the second tile should slide onto the survivor. I need to animate the second tile to the target too.

So I should reposition the fromId tile to the merge target position before removal, so it slides there. Let me, in repositionAll, also handle merges: for each merge, reposition fromId tile to survivor's cell.

Let me modify: after setting tileGrid & board, do repositionAll which places survivor by its tileGrid cell, and also for each merge place fromId at survivor cell. Since fromId is still in tileById (valid until finalize), I can transform it.

```
function repositionAll(){
  for r,c id=tileGrid[r][c]; if(id!=null){transform to cell}
  for m of mergesMergeInfo // store those in a var accessible
}
```

Merge info used both for reposition and finalize. Store in a module var `pendingMerges`.

Let me restructure move to store pendingMerges.

Game over detection `inDeadlock()`:
```
function inDeadlock(){
  for r,c if(board[r][c]===0) return false;
  for r,c{ v=board[r][c]; if(c+1<4&&board[r][c+1]===v)return false; if(r+1<4&&board[r+1][c]===v)return false;}
  return true;
}
```

New Game button: init() and update overlay.

Overlay: shows message and a continue/new game button.

Let me handle overlay: 
```
function updateOverlay(){
  const t=document.getElementById('msg');
  const cont=document.getElementById('continueBtn');
  if(gameOver){ overlay hidden=false; t.textContent='Game Over!'; cont.textContent='New Game'; cont.style.display='';
  } else if(won){ t.textContent='You win!'; cont.textContent='Continue'; }
  else overlay.hidden=true;
}
```
Continue button click: if gameOver -> new game; else hide overlay & continue.

Continue: `overlay.hidden=true;`. 

Let me include BEST score: best=Math.max(best,score) in updateScore, persists in localStorage? No external; could use localStorage but sandbox fine. Optional. I'll keep best in memory, maybe localStorage is fine (not network). I'll add localStorage for best.

Now let me write everything and then test in browser.

Let me write the file.

Cell metrics: I'll compute from CSS. Let me fix constants in JS matching CSS. board padding 8, gap 12, cell 100. Actually let me use a board of 500px. Let me set:
```
.board{width:500px;height:500px;padding:8px;...}
```
cell size = (500 - 16 - 36)/4 = 448/4 = 112. gap = 12. Let me define JS constants CELL=112, GAP=12, PAD=8. And board width=500.

Let me just compute via JS reading computed style? Safer to hardcode in CSS too but better compute. I'll compute CELL, GAP, PAD in JS matching CSS. Use fixed constants.

Actually I'll set board via CSS with variables and read them in JS via getComputedStyle. More robust. Let me do:
```
:root{--cell-size:112px; --gap:12px; --pad:8px;}
.board{width:calc(var(--cell-size)*4 + var(--gap)*3 + var(--pad)*2); height:same}
```
In JS read parseFloat each, or just hardcode 112/12/8. I'll read from CSS to be safe.

Let me write cellPos using computed values.

I'll finalize now.

Let me also handle width of tile text, font sizes based on digits.

Colors:
- 2:#eee4da, text #776e65
- 4:#ede0c8
- 8:#f2b179 text white
- 16:#f59563
- 32:#f67c5f
- 64:#f65e3b
- 128:#edcf72
- 256:#edcc61
- 512:#edc850
- 1024:#edc53f
- 2048:#edc22e
- >2048: #3c3a32

Let me write.

Now let me also ensure first spawn after init is two tiles with different cells (spawnTile picks random empty). Good.

Let me write the file now.

There's a small placeholder bug in the merge animation. Let me fix that: I stored m.r, m.c for merges which are the survivor target cell. Let me use those.

In the move function, I have merges entries with r,c. Let me fix the placeholder line.

Start with two tiles. Let me inspect the DOM to see tile positions and values, then play moves.

Let me use a script via key events. I'll send arrow keys and check. But I need to know tile positions to verify merges. Let me take a screenshot? Model doesn't support images. Let me inspect DOM.

Let me add a debug approach: I'll use browser key action to press arrow keys. Then inspect DOM tile values.

Let me first check initial board tile values and positions.

The inspect only shows text. Let me use the console via a bash approach? I don't have a JS eval tool directly. Let me use the browser key action to send arrow keys and inspect.

Actually I need a way to check board state. The inspect returns DOM text but tiles' values are drawn. Let me check the tile elements with their transform positions. The inspect text gives "2 2" meaning two tiles with value 2.

Let me send arrow keys sequentially and check the result. I'll press ArrowLeft, wait, inspect.

Let me use the key action.

The DOM still shows 2 2, score 0. The move may not have registered? Or the inspect happened during the transition (before finalize). The finalize happens after 170ms. The key action returns quickly. Let me wait and inspect again.

Actually the initial two tiles could already be in the leftmost cells if they were spawned there, then no change. But random. Let me inspect positions. The inspect text doesn't give positions. Let me add a way to inspect positions - I can read the DOM via inspect but it only returns text content.

Let me wait and re-inspect after delay. Actually maybe move performed but input didn't fire because focus. Hmm, keydown listener is on document so should fire regardless. But the browser key action might send to document. Let me wait a moment and inspect.

Let me do a few arrow presses with a sleep. The browser tool key doesn't have delay param. Let me just send multiple keys and inspect after.

Actually, I realize I should verify tile positions. Let me temporarily expose board state for verification. Better: I can evaluate JS? There's no eval tool. But maybe the inspect shows only text content, not styles.

Let me think: I can add a hidden debug output to the page that shows board values after each move. Let me add that temporarily for verification, then remove. Actually I'll add tiny code writing board to the title or a data attribute on body. Let me just have it set document.title or a debug element.

Let me add a debug div showing the grid array as text. That way inspect reveals it.

Actually, simpler: I can use bash to inject? No, the page runs in the browser harness. Let me just add debug logging to console via console.log, and the browser tool reports console messages! Great. I'll add console.log statements in move() and newGame.

Let me add `console.log('board', JSON.stringify(board), 'score', score)` after finalize and in newGame.

Let me edit.

Oops I added a stray `updateArr = updateScores;` line - that's junk. Let me remove it. Actually it references undefined variable, harmless? `updateArr = updateScores` assigns the function to an undeclared variable (global). Fine but messy. Let me remove it.

Initial board [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,4,2]]. Two tiles: 4 at (3,2), 2 at (3,3).

Let me send ArrowLeft. Move left will slide row 3: [0,0,4,2] but wait cells (3,2)=4,(3,3)=2. For left, line row 3 slide order cols 0,1,2,3: values 0,0,4,2. Process: items 4,2 -> [4,2,0,0]. Changed. spawn tile.

Let me press ArrowLeft and check after delay.

The console shows the NEWGAME log (cached from reload) but not the after-move log yet (170ms). The inspect happened before the setTimeout fired. Let me send the key and wait more time before inspecting. Maybe the key was sent too fast. Let me press again and inspect. But pressed tiles already at left, a second left press would be no-change (no spawn). But raw output shows tiles still 4 2 at ... hmm the DOM shows 4 2 but not moved maybe during transition.

The problem: I send key then immediately inspect in the same message, before the 170ms finalize. I need to delay. Let me press ArrowLeft then do separate inspect after a pause. The browser tool doesn't have explicit sleep, but each tool call has some latency. Let me just press and then in the next call inspect, allowing natural delay.

Actually the before output also didn't show move because finalize not done. Let me press ArrowRight to move them and wait.

Let me send ArrowRight now (tiles at bottom row cols 0,1 after left) and then inspect in a follow-up.

Wait, the left press did happen? The last inspect DOM still showed 4 2 at positions we can't see. But no AFTER-MOVE log appeared, meaning within the returned console (which includes ipc timing) the setTimeout hadn't fired even 170ms? The tool returns quickly (~<170ms). So the log just isn't captured at that moment because setTimeout is in page's timer.

Hmm, but the console array should include async logs only up to when snapshot was taken. So I need consecutive interaction to accumulate logs. Let me press ArrowRight then inspect; by then the left move should have finalized (timer elapsed during tool roundtrip) and appear in the accumulating console.

Let me press ArrowRight.

Actually let me press ArrowRight twice to be safe and gather logs. But sequential: press right -> logs move; then inspect.

Let me do key ArrowRight.

Now after-move logged. First left move: board [[0,2,0,0],[0,0,0,0],[0,0,0,0],[4,2,0,0]], score 0. The bottom row became [4,2,0,0] (the 4 and 2 slid left, no merge). Spawned a 2 in empty cell at top row (0,1). Good - exactly one tile spawned.

Now let me test a merge. I want to align two equal tiles. Let me send more moves. I need an arrangement to merge. This is somewhat random. But the logic is unit-testable via the algorithm. Let me instead do a more controlled test.

Actually, let me trust the algorithm and verify page scroll prevention and game over / win overlay later. But the task explicitly wants verifying merges update score by merged value.

Let me drive the board toward a merge. Current board:
[0,2,0,0]
[0,0,0,0]
[0,0,0,0]
[4,2,0,0]

Let me think about moves to create equal neighbors. Hard to guarantee. 

Alternative: I'll temporarily test by setting board via a debug hook. But API is isolated in IIFE; no global access. 

Let me just play moves and observe merges. Let me press up, then inspect, continuing. I'll press a series and check for a merge (score > 0) or check that merges are correct when they occur.

Let me do ArrowUp. Current slide: column 0 values [0,0,0,4] -> up -> [4,0,0,0], deadlock false, changed. spawn.
column 1: [2,0,0,2] -> up -> [2,2,0,0] merge! 2+2=4. Score +=4.

Let me press up and check.

Column 0 up: [0,0,0,4] -> [4,0,0,0]. Column 1 up: [2,0,0,2] -> [2,0,0,2]? Wait the spawned tile from left was at (0,1)=2, and bottom (3,1)=2. Column 1 = [2,0,0,2]. Up -> slide toward row0: [2,2,0,0] -> merge 2+2=4 at row0 col1. Score +=4.

But the log shows board [[2,0,0,0],[0,0,0,0],[0,0,2,0],[4,2,0,0]] score=0. That's different! Column1 became [0,...] and there's a 2 at (2,2). Hmm.

Wait let me recompute. Before up move, board was:
[0,2,0,0]
[0,0,0,0]
[0,0,0,0]
[4,2,0,0]

Columns:
col0: [0,0,0,4] up->[4,0,0,0]
col1: [2,0,0,2] up-> processLine ids/vals [2,0,0,2] -> items [2,2] -> merge -> [4,0,0,0], merge fromId..., score+=4.
col2: [0,0,0,0]->0
col3: [0,0,0,0]->0

So expected after up: 
[4,4,0,0]
[0,0,0,0]
[0,0,0,0]
[0,0,0,0]
score=4, then spawn one tile.

But log shows [[2,0,0,0],[0,0,0,0],[0,0,2,0],[4,2,0,0]] score=0. That's not matching. What happened?

Hmm wait, the moves fired: I pressed ArrowLeft then ArrowLeft then ArrowUp. Let me reconsider. First left produced [[0,2,0,0],[0,0,0,0],[0,0,0,0],[4,2,0,0]]. Second left: is it a no-op? Slide each row left:
row0 [0,2,0,0]->[2,0,0,0] changed! yes.
row3 [4,2,0,0]->[4,2,0,0] no change.
So second left: row0 2 slides to col0. spawn.
But the second AFTER-MOVE log I saw was from ArrowUp (I pressed Left, then Left, then Up in three calls). Wait I pressed: ArrowLeft (call1), ArrowLeft (call2), ArrowUp (call3). The logs shown: NEWGAME, AFTER-MOVE(left1), AFTER-MOVE(which?). 

Between call2 (second left) and call3(up), did the second-left AFTER-MOVE log get shown? The last log shown at call3 was the third AFTER-MOVE. Let me recount: 

Actually when I pressed ArrowLeft in call2, the response logged only NEWGAME (the up... no). Wait call2 response: logs NEWGAME and AFTER-MOVE board=[[0,2,0,0],...,[4,2,0,0]] score=0. That was the FIRST left move's after-move log (from call1), captured late in call2. So call1's left hadn't finalized when call1 inspected, but finalized by call2's snapshot. Good.

Then in call2, the second ArrowLeft was sent. Its after-move would log ~170ms later.

Now call3 (up) response shows a third AFTER-MOVE board=[[2,0,0,0],[0,0,0,0],[0,0,2,0],[4,2,0,0]] score=0. This is the SECOND LEFT move result! Let me verify: second left on board [[0,2,0,0],[0,0,0,0],[0,0,0,0],[4,2,0,0]]:
row0 [0,2,0,0]->[2,0,0,0]
row3 [4,2,0,0]->[4,2,0,0]
others 0.
Result:
[2,0,0,0]
[0,0,0,0]
[0,0,0,0]
[4,2,0,0]
= exactly [[2,0,0,0],[0,0,0,0],[0,0,0,0],[4,2,0,0]], then spawn 2 at (2,2). So board after = [[2,0,0,0],[0,0,0,0],[0,0,2,0],[4,2,0,0]]. Yes! That's the second-left result, captured in call3.

So the ArrowUp in call3 hasn't finalized yet. Good, consistent. Now I need to inspect later to see the up move result with the merge. Let me press a no-op? If I press something it'll move further. Let me just inspect again (no key) — but inspect doesn't wait for pending timers beyond snapshot time. The previous call3 already waited enough (round trip) that up finalized by now. Let me do inspect to get the latest console.

Actually the console in a response only includes logs up to the snapshot. Each tool call re-snapshots and accumulates all logs since page load. So calling inspect now will include the up-move after-move log.

The latest after-move log is board=[[2,2,2,0],[4,0,0,0],[0,0,0,2],[0,0,0,0]] score=0. Wait, that's the up move? Let me recompute the up move from second-left board:
[[2,0,0,0],[0,0,0,0],[0,2,0,0],[4,2,0,0]] 

Wait the second-left board BEFORE spawn was [[2,0,0,0],[0,0,0,0],[0,0,0,0],[4,2,0,0]] then spawned 2 at (2,2) giving [[2,0,0,0],[0,0,0,0],[0,0,2,0],[4,2,0,0]].

Now up move on this:
col0: [2,0,0,4] up -> [2,4,0,0] (4 up). items 2,4 -> no merge -> [2,4,0,0].
col1: [0,0,0,2] up -> [2,0,0,0].
col2: [0,0,2,0] up -> [2,0,0,0].
col3: [0,0,0,0] -> 0.
Result:
row0: col0=2,col1=2,col2=2,col3=0 -> [2,2,2,0]
row1: col0=4, rest0 -> [4,0,0,0]
row2: all0
row3: all0
= [[2,2,2,0],[4,0,0,0],[0,0,0,0],[0,0,0,0]], then spawn 2 at (2,3): [[2,2,2,0],[4,0,0,0],[0,0,0,2],[0,0,0,0]].

Yes! That's exactly the log. score=0, correct (no merge this move). Good. The up move worked correctly (tiles slid up, 4 moved up in col0, spawned one tile).

So merges never happened yet because I haven't created equal adjacent tiles. The up move put three 2s in row0 but no adjacent equal (they're 2,2,2 all equal adjacent!). [2,2,2,0] has adjacent equal 2s at col0,col1,col2. But that's current state AFTER the up move finalized. No merge happened during that move.

Now to test merge: press ArrowLeft on board [[2,2,2,0],[4,0,0,0],[0,0,0,2],[0,0,0,0]]. Row0 = [2,2,2,0] left -> items [2,2,2] -> merge first two -> [4,2,0,0]. Score +=4. Also row2 [0,0,0,2]->[2,0,0,0] slides (changed). 

Expected result: 
row0 [4,2,0,0]
row1 [4,0,0,0]
row2 [2,0,0,0]
row3 0s
then spawn.
score=4.

Let me press ArrowLeft and then inspect (wait for finalize).

Still only up to previous log. The current ArrowLeft finalize not yet captured. Let me inspect again to get it.

The merge test passed. ArrowLeft on [[2,2,2,0],[4,0,0,0],[0,0,0,2],[0,0,0,0]]:
- row0 [2,2,2,0] -> [4,2,0,0], score +4.
- row1 [4,0,0,0]->[4,0,0,0]
- row2 [0,0,0,2]->[2,0,0,0]
Result before spawn:
[4,2,0,0]
[4,0,0,0]
[2,0,0,0]
[0,0,0,0]
then spawn 2 at (1,3): [[4,2,0,0],[4,0,0,2],[2,0,0,0],[0,0,0,0]]
= exactly AFTER-MOVE log, score=4. 

Score increased by exactly 4 (the merged value). BEST also updated to 4. Correct!

Now let me test:
1. [2,2,4,0] left -> [4,4,0,0]: this is a specific required example. Let me set up a board to test the merge-once logic. I can't directly set state, but I can reason through the processLine algorithm which I already trust. But let me test it via the game to be thorough.

Actually let me create that board by moves. Hard to control. The algorithm processLine handles it: items [2,2,4] -> first pair merge -> [4,4,0,0]. It's correct by code. I'm confident.

2. [2,2,2,2] left -> [4,4,0,0]: items [2,2,2,2] -> merge pair1 -> 4, then merge pair2 -> 4 -> [4,4,0,0]. Correct (i increments by 2, outIdx increments).

Let me verify the score after continuing and test New Game, and test game over and no-spawn-on-unchanged-move.

Let me test: press a move that's unchanged. Hard to get a no-move board. But the code returns early if unchanged. 

Let me now test New Game button resets to two tiles score 0. I'll click New Game button. The button is at header. Let me find its coordinates or use click on element. The browser inj click needs x,y coordinates. Let me get button position via inspect? The DOM doesn't give coordinates. 

Hmm, browser click action takes x,y. I need to compute. The layout: header at top. h1 flex:1 on left. New Game button on right side of header. The game width ~ 4*112+3*12+16 = 448+36+16=500px, centered. Viewport 1200 wide, so game left edge = (1200-500)/2 = 350. Button at right ~ x=350+500-... roughly x=780. y ~ header center ~ 50-ish. 

Actually board is 500 tall, header ~70 tall, body centered vertically. Total ~600. Viewport 800. Top offset ~ (800-600)/2=100. Header center ~ 135. Button x: header has h1(flex1) then two score boxes then button. Button near right: right edge of game = 350+500=850 minus padding ~ button center ~ 800. 

Rather than guess, let me use a more reliable approach: use keyboard by focusing? The New Game button I can trigger via its click through the overaly? No.

Let me instead trigger via JS? No eval tool. 

Alternatively, I can add a keyboard shortcut for new game, but better to test the button properly. Let me use scroll/click coordinates. Let me screenshot? model doesn't support images.

Let me just click at approximate coords and verify via console NEWGAME log appears. Each newGame logs 'NEWGAME board=...'. So I can detect success.

Let me try click at (800,135). Actually let me reconsider layout: body align-items:center vertically for full height, justify-content center horizontally. The .game is the only element. height = header (~70) + board(500) + foot(~30) + margins. Total ~610. Vertically centered in 800 -> top ~95.

Header inside .game flex row. Items: h1 (flex:1, grows), score-box, score-box, button. The button is at bottom-right of header. Header height ~ h1 font 46 -> ~60px tall. Header top ~95, so button center y ~ 95+30=125. Button x: right side. game right = 350+500=850. Button width ~... score boxes ~76 each + gaps. Button x center ~ 850-40 = 810.

Let me click (805,125).

New Game button works: clicked, logged NEWGAME board=[[0,0,0,0],[2,0,0,0],[0,0,0,2],[0,0,0,0]] with two tiles, score reset to 0 (dom shows SCORE 0), BEST retained 4. 

Now let me test the no-spawn on unchanged move and game over, plus the specific merge examples [2,2,4,0]->[4,4,0,0]. These are more about algorithm correctness. Let me construct a board to test [2,2,4,0]->[4,4,0,0].

Actually I want to directly verify the processLine merge-once semantics with these exact examples. I can't set board directly without a hook. Let me add a temporary test hook that sets the board and calls a move, logging. But that's invasive. 

Alternatively, I can reason and also verify via a second, cleaner approach: temporarily define a test that uses the internal functions. But they're in IIFE scope.

Let me add a global debug test function inside the IIFE that constructs a board and runs a move, for verification. I'll add `window.__test2048`. This isn't part of final behavior but harmless (or I remove after).

Actually, I can drive the real game to reach [2,2,4,0] pattern? That's hard.

Let me add a test harness temporarily. I'll add at end of IIFE a function that sets board/tileGrid to a given grid of values and calls move, logging result. I'll create tiles accordingly.

Let me write:
```
window.__test = function(arr, dir){
  // arr: 4x4 values
  board = arr.map(function(r){return r.slice();});
  tileGrid = Array.from(...null);
  tileById = {};
  nextId=1;
  score=0;
  for r,c if value>0 create tile (id=nextId++)
  move(dir);
};
```
move uses setTimeout for finalize. score update happens in timer. I'd need to read after timer. Hard to synchronize from outside. 

Better: refactor move to have a synchronous core then async finalize, but returning promises is annoying.

Alternative: I'll verify the merge-once semantics directly with a small standalone JS test run in node/bash (since the processLine logic is pure JS). I can extract and run it. But it's embedded in HTML.

Actually the addendum says run in browser and inspect. I've verified real merges. The specific examples [2,2,2,2] and [2,2,4,0] are covered by the processLine algorithm which I can verify logically. But let me at least do a quick standalone node test of the algorithm to be safe (bash with node). Let me copy processLine logic to a node one-liner... but that's duplicating. 

Let me instead add the __test hook and run it via browser, then read a result stored in a global that I inspect. But inspect only shows DOM text/console. I can have the test write result into document.title or a data attribute, then inspect. Hmm inspect returns DOM text content; title may appear? The inspect returned page text content (headings etc.) not title. 

Let me have __test log to console after finalize via setTimeout, and I call it then inspect later to get the log. Since console accumulates, I can call __test then in a subsequent inspect get the log.

Let me add __test that sets state and calls move, and also I make move optionally synchronous via a flag? Simpler: make __test await finalization by reading score/board after a delay stored. Actually the after-move log already prints board & score. So I just call __test([...], 'left') and then inspect after delay; the AFTER-MOVE log appears.

Let me add it.

Test case A: [2,2,4,0] left in a single row. Expected [4,4,0,0] then spawn. score=4. Board after = [4,4,0,0] plus spawn in some empty cell.
Test case B: [2,2,2,2] all row. left -> [4,4,0,0], score 8.

Let me add __test that puts the row and zeros elsewhere.

Let me edit.

Now I need to call __test. But browser tool has no eval. I need to invoke it. I could trigger it via keyboard? No, __test isn't bound.

Hmm. I can't execute arbitrary JS through the browser tool. I only have key/click/type/inspect/motion/scroll/drag.

Alternative: I could bind __test to a keyboard event or auto-run on load in a debug block. But I want targeted cases.

Let me instead have the harness auto-run test cases on load and log results, isolated to a temporary debug section that I remove afterward. But that pollutes and changes the game's initial state.

Better approach: add a debug function that runs the pure core logic synchronously WITHOUT DOM, logging results. Let me add a synchronous pure function `computeLinePure(vals)` that returns output values, and self-test on load (console) comparing examples. That doesn't touch the game state.

Let me add at end of IIFE a self-check that logs expected vs actual for processLine on pure value lines. But processLine takes ids/vals; I can call it with dummy ids. It returns res.vals. Let me add:

```
var testLines = [
  {in:[2,2,2,2], exp:[4,4,0,0]},
  {in:[2,2,4,0], exp:[4,4,0,0]},
  {in:[0,2,2,2], exp:[4,2,0,0]},
  {in:[2,0,2,4], exp:[4,4,0,0]}
];
testLines.forEach(function(t,i){
  var ids = t.in.map(function(v,j){ return v>0? 100+j : null; });
  var res = processLine(ids, t.in);
  console.log('PURE-TEST'+i, JSON.stringify(t.in), '->', JSON.stringify(res.vals), '(expected '+JSON.stringify(t.exp)+')');
});
```

processLine is defined in IIFE scope, accessible. This runs on load and logs. Let me add it and remove the __test DOM version (since I can't invoke it). Actually keep __test? It's harmless but unused. Let me remove __test to keep clean and rely on pure test + already-verified real merges.

Actually, let me replace __test with the pure self-test. Remove __test block.

Let me edit.

All pure tests pass. This directly verifies:
- [2,2,2,2] -> [4,4,0,0] (merge once per tile)
- [2,2,4,0] -> [4,4,0,0]
- [0,2,2,2] -> [4,2,0,0]
- [2,0,2,4] -> [4,4,0,0]

Now I need to verify:
1. No spawn after unchanged move.
2. Game over detection.
3. Win overlay on 2048.
4. Arrow keys don't scroll page.

Let me test no-spawn on unchanged move. Initial board after reload: [[0,0,0,0],[0,0,0,2],[0,0,0,2],[0,0,0,0]]. Since tiles are both in col3, pressing ArrowRight is already at right edge = unchanged move (no slide, no merge). Let me press ArrowRight and verify no AFTER-MOVE log (move returns early, no spawning, no log). And total tiles count stays 2.

Let me press ArrowRight then inspect. Since move returns early (no finalize log), if unchanged the log won't appear. I'll check DOM tile count stays 2 and no new spawn.

Let me press ArrowRight.

No AFTER-MOVE log appeared after ArrowRight, and DOM still shows exactly 2 tiles (2, 2), score 0. So an unchanged move did NOT spawn a tile and did NOT log (returned early). Correct behavior.

Note: the initial board here had two 2s in col3 rows 1,2. ArrowRight keeps them (unchanged). Correct no-op.

Now let me test win overlay and game over. These are hard to trigger in live play. Let me trust the code logic, but let me at least verify game-over detection path and win overlay via a DOM injection test... I can't eval. 

Let me reason:
- updateOverlay: checks gameOver (sets "Game Over"), else if has tile>=2048 and !won sets "You Win" and won=true. Good.
- inDeadlock logic correct.
- Game over only triggers after a move that fills board with no merges possible. It's set in move() finalize via updateOverlay when inDeadlock(). Good.

Win: continues play; won flag prevents re-overlay. Continue button hides overlay. Good.

I've verified the core required behaviors: slide, merge-once, score increment by merged value, spawn exactly one tile on valid move, no spawn on unchanged, New Game reset, arrow keys. 

Regarding arrow key scroll prevention: e.preventDefault() is called for mapped arrow keys, preventing page scroll. With a non-scrolling page it's fine. Let me verify preventDefault is active — the page isn't scrollable anyway, but logic is there.

One concern: page might scroll if content taller than viewport. The body uses display:flex align-items:center which could overflow if content > viewport, but content is ~610px < 800. Fine. And preventDefault prevents scroll regardless.

Let me also verify the win overlay triggers — I could scale a test by pushing a board with a 2048. But I can't set state. Let me reason the code is sound. Actually I can verify updateOverlay logic by examining it visually - already did.

Let me now verify rapid input lock and that animations complete correctly by pressing a quick succession of keys and checking final board integrity (no corruption). Let me press several moves quickly and verify the board is consistent (sum of all tile values = total of merged... well can't easily). Let me just do a few quick lefts and verify board values are powers of 2 and moves applied sequentially.

Actually, the lock prevents concurrent moves. Let me do a quick stress: press ArrowLeft, ArrowUp, ArrowRight, ArrowDown rapidly and inspect final board; ensure no error and board is valid (all values powers of 2, board changed appropriately). 

But with isMoving lock, rapid presses within 170ms are ignored, which is the intended anti-corruption. Good.

Let me do a quick final check: press ArrowLeft a couple times and confirm board stays valid (no negative/odd, correct count). 

Let me also remove the temporary self-test code before finalizing, since I added it as TEMPORARY and it logs on load (harmless but I said I'd clean up). I'll remove it to keep the file clean.

Let me remove the pure-test block.

Clean reload, two tiles (2,4). Let me do a quick stress sequence verifying board integrity and that a merge updates score. Let me press a series and check final.

Let me press ArrowLeft a few times and then inspect.

Wait, the DOM shows only 3 tiles (2,4,2)? The board log AFTER-MOVE shows 4 tiles: row0 all 0, row1 col3=2, row2 col0=2(original 2 from (2,2)), row3 col0=4. That's board cells: (1,3)=2, (2,0)=2, (3,0)=4. That's 3 tiles + one spawned 2 at (1,3). Wait the AFTER-MOVE log shows [[0,0,0,0],[0,0,0,2],[2,0,0,0],[4,0,0,0]]. That's 4 nonzero: (1,3)=2, (2,0)=2, (3,0)=4 = three tiles? Plus... row2 col0=2, row1 col3=2, row3 col0=4. That's 3 tiles. But spawn adds one => 4 total. Which is the pre-spawn board? The AFTER-MOVE log is printed after spawnTile(). Hmm the log shows the post-spawn board. Let me count: values are 2,4,2,2? row1col3=2, row2col0=2, row3col0=4 = {2,2,4}. That's only 3 values. So where's the 4th?

Wait original board: [[0,0,0,0],[0,0,0,0],[0,0,2,0],[0,0,0,4]]. Tiles: 2 at (2,2), 4 at (3,3). ArrowLeft:
row2 [0,0,2,0]->[2,0,0,0] (2 slides to col0). 
row3 [0,0,0,4]->[4,0,0,0] (4 slides to col0).
Then spawn one tile: at (1,3)=2. So post-spawn board:
row0 [0,0,0,0]
row1 [0,0,0,2]
row2 [2,0,0,0]
row3 [4,0,0,0]
= 4 tiles: 2,4,2,2. That's what the log shows! I miscounted. It shows row1col3=2, row2col0=2, row3col0=4 — plus row1... wait the log array is [[0,0,0,0],[0,0,0,2],[2,0,0,0],[4,0,0,0]]. Nonzero cells: [1][3]=2, [2][0]=2, [3][0]=4. That is ONLY THREE nonzero cells. Let me recount the array:

row0: [0,0,0,0]
row1: [0,0,0,2]  -> one 2
row2: [2,0,0,0]  -> one 2
row3: [4,0,0,0]  -> one 4

Total = 3 tiles. But a valid move should spawn one giving total 4 (2 original + 4... wait original had 2 tiles, move doesn't change tile count except merges, then spawn 1 => 3+1? No).

Original 2 tiles. The move slides (no merge), still 2 tiles. Spawn 1 => 3 tiles total. YES! 2 original + 1 spawned = 3. I incorrectly said 4. The log board has 3 tiles: the two originals (2,4) repositioned plus one spawned 2. That's correct! Total tiles = 2 + 1 = 3. 

The DOM shows "2 4 2" = 3 tiles. Correct.

So everything is consistent. Total tiles increased by exactly 1 after a valid move. 

I'm confident the game works:
✓ Start with 2 tiles
✓ Arrow keys slide
✓ Merge once per tile per move
✓ Score increases by merged value (verified: +4)
✓ Exactly one tile spawns on valid move (verified)
✓ No spawn on unchanged move (verified)
✓ Animations + input lock
✓ preventDefault on arrows
✓ New Game resets to 2 tiles, score 0 (verified)
✓ Win/game-over overlay logic (code-verified, not live-triggered)

The file is saved. I've removed the temp test code. Let me do a final read of the file to confirm no leftover debug and everything is intact.

Let me verify the file is complete and clean with a quick grep.

There are two remaining console.log debug statements (NEWGAME and AFTER-MOVE). Let me remove them since they're debug logging, keeping the file clean. Actual 2048 games shouldn't spam console on every move. Let me remove both.

Clean. Final reload shows two tiles, no console spam. File is complete and saved. Let me do a final report.

Verification summary. And note what wasn't live-triggered: win overlay at 2048 and game-over overlay (logic code-verified, not reached in randomized play), best persistence across reloads (localStorage), and rapid-input stress beyond a few quick keys.

Let me report.