Tetris · qwen3.8-flash

Let me build the Tetris game.

Plan: single index.html file, canvas-based board 10x20, controls, score, lines, level, next preview, hold optional (I'll add hold + ghost since easy), pause/resume, restart, game over.

Let me write the code carefully.

Key details:
- SRS-ish spawn positions: pieces spawn at top rows, columns 3-6 for most. I spawn at row 0 (or row -1 hidden?). Requirement: "legal spawn positions" and "visible board 10 columns, 20 rows". I'll spawn pieces entirely within visible board at top: for standard, I spawn pieces in the top-out visible region: row 0 for I? I'll use shapes with defined offsets and place them so their bounding box top-left is at column 3, row 0 for most, and for I at column 3, row 0.

Let me define shapes as matrices:
I: 4x4 with row1 = [1,1,1,1] → spawn at x=3, y=0 occupies row 1 (0-indexed) visible rows. Fine.
O: 2x2 [[1,1],[1,1]] spawn x=4, y=0.
Others: 3x3, spawn x=3, y=0. Rotation via matrix transpose + reverse rows (clockwise).

Wall kicks: I'll implement simple attempt with kicks (left/right/up) — optional. Let's do basic: try rotated; if blocked, try offsets [(-1,0),(1,0),(-2,0),(2,0),(0,-1)] — simple kicks. That's fine and legal (moves into non-overlapping positions). Actually simpler and safe: reject blocked rotation. But kicks are nicer. I'll implement basic kicks but ensure they respect bounds/occupied cells.

Scoring: 100/300/500/800 * level. Soft drop maybe +1 per cell, hard drop +2 per cell. Fine (extra). Level = floor(lines/10)+1. Gravity interval decreases with level.

Game over: if spawn overlaps → state 'gameover', overlay.

Pause: toggle with button and 'P'. Show overlay.

Restart resets board, score, level, lines, piece sequence (reset 7-bag randomizer), next queue, hold, timer.

7-bag randomizer for piece sequence state.

Display controls on screen.

Keyboard: Left/Right/Down/Space — prevent default for arrows/space. Also need to handle lock delay: piece lands when it can't move down. Simple: gravity tick moves down; if blocked, lock. Also hard-drop locks immediately.

Let me also implement DAS-ish repeat using browser key repeat — fine.

Ghost piece: show projection.

Rendering: canvas 300x600 (30px cells) plus next canvas 120x120ish, hold canvas.

I'll draw grid, cells with slight bevel.

Let me write the file.

Also test with the browser tool. Let me write code.

Structure:

```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Tetris</title>
<style>...</style>
</head>
<body>
<div class="wrap">
 <header>...</header>
 <main>
  <aside class="panel left">hold canvas, stats</aside>
  <div class="board-area"><canvas id="board" width="320" height="640"></canvas> overlay</div>
  <aside class="panel right">next canvas, controls</aside>
 </main>
</body>
```

Simplify: left panel: Hold + stats (Score, Lines, Level); board with overlay div; right: Next, buttons, controls list.

Cell size 30, board 300x600. Use device pixel ratio scaling maybe — keep simple with fixed size but set canvas width/height to CSS size * dpr for crispness. I'll do a setupCanvas helper with dpr.

JS:

```js
const COLS=10, ROWS=20, CELL=30;
const SHAPES = {
 I:{c:'#35c5e6', m:[[0,0,0,0],[1,1,1,1],[0,0,0,0],[0,0,0,0]], spawn:{x:3,y:0}},
 J:{c:'#4a5fd8', m:[[1,0,0],[1,1,1],[0,0,0]], spawn:{x:3,y:0}},
 L:{c:'#e0883a', m:[[0,0,1],[1,1,1],[0,0,0]], spawn:{x:3,y:0}},
 O:{c:'#e6d23c', m:[[1,1],[1,1]], spawn:{x:4,y:0}},
 S:{c:'#4ec85f', m:[[0,1,1],[1,1,0],[0,0,0]], spawn:{x:3,y:0}},
 T:{c:'#a94fd8', m:[[0,1,0],[1,1,1],[0,0,0]], spawn:{x:3,y:0}},
 Z:{c:'#e04a4a', m:[[1,1,0],[0,1,1],[0,0,0]], spawn:{x:3,y:0}},
};
```

Note for J/L/S/T/Z with 3x3 matrices spawn y=0: the third row is empty so occupied cells at rows 0-1 → visible at top. Good.

I piece: 4x4 with row index 1 occupied → occupies visible row 1. Spawn y=0 means bounding box top at row 0, occupied row 1. Actually typical spawn: I at row -1... fine, visible is okay. Hmm, but that leaves row 0 empty above — fine, legal.

Actually to make pieces spawn at very top visually maybe use y=-1 for I so blocks at row 0. But negative y requires collision handling for hidden rows. Keep y=0 for simplicity; occupied rows 1 for I, 0-1 for others. Slight inconsistency but fine. Actually let me trim the I matrix to a 4x1... no, rotation of I needs the 4x4 form. Alternative: I matrix rows: [[1,1,1,1],[0,0,0,0],[0,0,0,0],[0,0,0,0]] with spawn y=1 → occupies row1. Rotation clockwise of that matrix gives column 0 filled → x offsets change. Standard SRS rotation states for I: rotating 4x4 clockwise: transpose then reverse each row. Row0 = [1,1,1,1] → after clockwise, column index 3 becomes [1,1,1,1] vertically → occupied at rows 0..3, x=3+3=6 within bounds (cols 3..6). Vertical I occupies rows y..y+3 = 1..4, x=6. That's fine and legal.

Let me use matrix form:
I: [[0,0,0,0],[1,1,1,1],[0,0,0,0],[0,0,0,0]] spawn x=3,y=0: horizontal occupies row 1, cols 3-6. Rotate clockwise: transpose → row i = col i; then reverse each row. Let me compute: m[r][c]. Transposed t[c][r]=m[r][c]. Row0 of m: all zeros → col0 all zeros. Row1 of m: all ones → col1 all ones. So t[r][c] = 1 when c==1 for all r? t[r][c]=m[c][r], t[r][c]=1 iff m[c][r]=1 iff c==1... wait m[c][r]=1 iff c==1 (row index of m is c). So t has column... t[r][c]=1 iff c==1. Then clockwise = reverse each row of t: row r reversed → position c becomes t[r][3-c]... new[r][c] = t[r][3-c] → 1 iff 3-c==1 iff c==2. So vertical I at x=3+2=5, rows y..y+3 = 0..3. Occupies rows 0-3 col 5. Fine.

Collision: check each filled cell within 0..ROWS-1, 0..COLS-1 and board empty. Cells with y<0 allowed? For rotation kicks maybe. I'll allow y<0 cells to be non-colliding (treated as outside above, ignored) but on spawn require all filled cells >= 0 and free. Simpler: reject any cell with y<0? That could block legitimate rotations near top. Let me allow y<0 as "above board" free cells, and game over check at spawn: any filled cell overlapping occupied or y<0 → hmm. Standard: spawn at top; if overlap → game over. I'll treat y<0 as free but if the piece cannot be fully placed at y>=0... Let me just require spawn y=0 and reject if overlap; and if a filled cell has y<0 at spawn → not possible since matrices at y=0 have min row 0.

For rotations I'll allow cells at y<0 (free), that's standard-ish. Fine.

Gravity: interval = Math.max(60, 1000 - (level-1)*85) ms or use classic table. level 1 = 1000ms? That's slow-ish; use ~800ms base. Let's do speeds array: [1000,843,686,571,470,383,311,250,197,156,120,90,65,45,30,20].

Lock: when gravity can't move down → lock immediately (with small lock delay? keep simple: lock immediately). Add a small lockDelay of 0 for simplicity — requirement says "Lock landed pieces". Immediate lock on failed gravity drop is fine, and hard drop locks.

Next queue: bag-based, keep 1 next (display) plus maybe 3. Show one next piece as required; I'll show next 3 in preview column? "next-piece preview" — I'll show the next piece prominently plus 2 smaller. Keep simple: show 3 in a vertical column canvas.

Hmm, preview: show the next piece large plus queue of 2 more. I'll do: canvas 4x3 cells for next piece large; below two small canvases? Overkill. Use a single canvas 5x12 cells displaying next 3 pieces with labels. Simpler: single canvas showing next 3 pieces stacked, each in a 4-wide slot. Good.

Bag implementation:

```js
let bag=[];
function nextFromBag(){ if(bag.length<2){ const b=Object.keys(SHAPES).slice(); shuffle(b); bag.push(...b);} return bag.shift(); }
```

Careful: bag should refill in whole sets. Use: if(bag.length===0){bag = shuffled keys} return bag.shift(). And queue: while(queue.length<4) queue.push(nextFromBag()).

Hold: swap, canHold flag reset on lock.

Line clear: find full rows, splice out, unshift empty rows, count.

Score: base [0,100,300,500,800][n] * level. Lines += n; level = floor(lines/10)+1.

Rendering loop with requestAnimationFrame; accumulate dt.

Input handling: keydown with repeat guard for rotate/harddrop (use e.repeat check).

Pause overlay & game over overlay & message. Buttons: Start/Restart, Pause/Resume. Also a "Hold" button and "Rotate" maybe not needed. Buttons: Pause/Resume, Restart, Hold.

Also on game over, keys should do nothing except restart. Also add "Start" — game begins immediately (state 'playing'). Maybe require pressing a key? I'll start immediately on load and after restart.

Now write it.

CSS: dark theme, grid layout, monospace-ish font, neon accents.

Let me write the full file.

Also add flash animation on line clear? Keep it simple but nice: brief white flash row highlight via a clearing state timer. I'll implement a small clear animation: set `clearing = {rows:[], t:0}` for 180ms during which rows drawn white and gravity paused, then actually remove. Nice touch, low risk. But need to be careful with spawn order: lock piece → mark rows → after animation → clear & spawn next. I'll implement it: state machine `phase`. Let me implement:

lockPiece(): merge to board, compute full rows, if any: set clearingRows, clearingTimer=160, score/lines update immediately, then on timer expiry remove rows and spawn. During clearing, no input movement for piece (piece is null). If no rows: spawn immediately.

Spawn happens after clearing → check game over then.

Also need `piece = null` while clearing.

Input functions check `if(!piece || state!=='playing') return;` and gravity check `if(piece)`.

Let me write.

Drawing functions:

drawCell(ctx,x,y,color,size) with bevel: fill rect, lighter top-left, darker bottom-right, plus inner highlight.

Board render: background grid lines, locked cells, ghost, piece, clearing flash.

DPR setup:

```js
function fit(canvas, w, h){ const dpr=window.devicePixelRatio||1; canvas.width=w*dpr; canvas.height=h*dpr; canvas.style.width=w+'px'; canvas.style.height=h+'px'; const ctx=canvas.getContext('2d'); ctx.setTransform(dpr,0,0,dpr,0,0); return ctx; }
```

Board canvas 300x600 CSS; on small screens maybe scale via CSS max-width... Keep width fixed but wrap in overflow. I'll add a media query to shrink? Canvas fixed size; use CSS transform scale for narrow. Skip; just make page scrollable.

Next canvas: width 100 (4 cols of 22) x height 260 for 3 pieces.

Let me now write the file content.

For rotation kicks, implement simple kick tests:

```js
function tryRotate(dir){
  const rotated = rotateMatrix(piece.m, dir);
  const kicks = [[0,0],[-1,0],[1,0],[0,-1],[-2,0],[2,0]];
  for(const [dx,dy] of kicks){
    if(!collides(rotated, piece.x+dx, piece.y+dy)){ piece.m=rotated; piece.x+=dx; piece.y+=dy; return true;}
  }
  return false; // rejected, piece unchanged
}
```

Note collides ignores y<0 cells. But if piece moves up (dy=-1) partially above board, that's ok.

Fine. Now write.

Also mobile: add touch buttons? Not required. I'll add keyboard focus note. Provide buttons for arrows maybe not needed.

Let me write the file now.

Also add SFX? No external assets. Could use WebAudio beeps — no network. Optional; adds risk of autoplay policy errors. I'll add a tiny WebAudio blip created lazily on first key press (user gesture) with try/catch, plus a mute toggle. Keep minimal risk: wrap everything in try/catch. Actually let's include it but guarded.

I'll skip audio to reduce risk? It's a nice touch and guarded in try/catch. I'll include a small sound function created on first user gesture.

Let me write code.

Stat display: score, lines, level in left panel.

Game over overlay text: "GAME OVER" + final score + "Press Restart".

Let me write final code carefully.

```js
const keys = Object.keys(SHAPES);
function shuffle(a){for(let i=a.length-1;i>0;i--){const j=Math.floor(Math.random()*(i+1));[a[i],a[j]]=[a[j],a[i]];}return a;}
```

State object:

```js
let board, piece, holdType, canHold, queue, bag, score, lines, level, state, clearing, dropTimer, lastTime, flash;
function reset(){ board=Array.from({length:ROWS},()=>Array(COLS).fill(null)); piece=null; holdType=null; canHold=true; bag=[]; queue=[]; score=0; lines=0; level=1; state='playing'; clearing=null; dropTimer=0; refillQueue(); spawn(true); }
```

refillQueue: while(queue.length<3) queue.push(pull());

spawn(first): type = queue.shift(); refillQueue(); build piece {type, m: clone(SHAPES[type].m), x: spawn.x, y: spawn.y, color}; if collides at spawn → state='gameover', piece=null? Keep piece drawn but blocked. I'll set piece=null and state='gameover' and show overlay.

Hmm for verification: "a new piece spawns, and the next-piece preview advances" — the preview should show the new head of queue. Good.

collides(m,x,y): for each cell r,c where m[r][c]: const by=y+r, bx=x+c; if(bx<0||bx>=COLS||by>=ROWS) return true; if(by<0) continue; if(board[by][bx]) return true.

Also check cells m beyond matrix size fine.

rotateCW(m): n=m.length; res[r][c]=m[n-1-c][r]? Let me get correct: clockwise: new[c][n-1-r] = m[r][c], i.e., new[i][j] = m[n-1-j][i]. Check with J: m=[[1,0,0],[1,1,1],[0,0,0]]. new[0][0]=m[2][0]=0; new[0][1]=m[1][0]=1; new[0][2]=m[0][0]=1 → row0=[0,1,1]; new[1][0]=m[2][1]=0; new[1][1]=m[1][1]=1; new[1][2]=m[0][1]=0 → [0,1,0]; new[2][0]=m[2][2]=0; new[2][1]=m[1][2]=1; new[2][2]=m[0][2]=0 → [0,1,0]. So shape:
```
.##
.#.
.#.
```
J rotated clockwise should be:
```
.##  -> hmm standard J spawn:
J..
JJJ
...
```
Rotated CW gives:
```
J..
JJ.  wait
```
Let me think: J spawn cells (0,0),(1,0),(1,1),(1,2). Rotate CW around center of 3x3: (r,c) -> (c, 2-r). (0,0)->(0,2); (1,0)->(0,1); (1,1)->(1,1); (1,2)->(2,1). Result cells: (0,1),(0,2),(1,1),(2,1):
```
.##  hmm row0: . J J
.#.
.#.
```
Yes matches the computed new matrix. Good, that's correct J rotation state (R).

rotateCCW: (r,c) -> (n-1-c, r).

Now gravity tick: if(!moveY(1)) lockPiece().

Soft drop: move down by 1 if possible, score+1, reset dropTimer.

Hard drop: while(moveY(1)) cells++; score += 2*cells; lockPiece().

Line clear and scoring:
```js
function lockPiece(){ merge; const full = rows fully filled; if(full.length){ clearing={rows:full,t:180}; lines+=full.length; score+= [0,100,300,500,800][full.length]*level; level=...; sfx } else { piece=null; spawn(); } }
```
Wait need piece=null in both branches. And in update loop: if(clearing){clearing.t-=dt; if(<=0){ removeRows(clearing.rows); clearing=null; spawn(); }}

Level recompute: level = Math.floor(lines/10)+1; gravity interval table lookup.

Also "increase gravity speed every ten cleared lines" ✓.

Buttons: Pause toggles state playing<->paused; label updates. Restart resets. Hold: swap.

Keyboard mapping: ArrowLeft/ArrowRight/ArrowUp/ArrowDown/Space/p/P/r/R/h/H/c/C.

Also render loop always draws.

Preview drawing: for each of queue's first 3 (or next + 2 small), draw shape centered in slot.

Let me code:

```js
function drawPreview(){ const ctx=nctx; ctx.clearRect(0,0,NW,NH); ... queue.slice(0,3).forEach((t,i)=>{ drawShapeAt(ctx,t, offsetX, i*slot + pad, cell) })}
```

NW=110, cell sizes: first piece cell 24, others 18? Simpler: three slots each height 76, cell = 16, center by computing bounding box.

I'll compute shape bounds:

```js
function shapeBounds(m){ let minR=9,maxR=-1,minC=9,maxC=-1; ... }
```

Then center within slot width.

Hold canvas: 80x80, cell 16.

Also "Show the controls" — list in right panel.

Let's write everything now.

CSS design: dark navy bg, subtle radial gradient, panels with borders, glow on board. Use system fonts.

Now the code.

One more: overlay for paused/gameover positioned absolutely over board canvas.

Write file.

I noticed a CSS bug I typed: `footer{margin-top:14px; font-size:11px; color:#5f7characters}` — invalid, must fix. Let me fix and run browser.

Also fix the odd hold hint text ("no network, all local") — fine but weird. Let me change to something sensible.

Now run in browser and inspect.

Now let's run the app in the browser.

The board renders. The active piece is O (yellow) at top, ghost at bottom. Wait — the active piece appears at top rows 0-1 and ghost at bottom rows 18-19. Looks right.

Hmm, but the board canvas is 300x600 and appears ~310 wide in the screenshot; the visible board is 10 cols x 20 rows. Good.

One issue: the O piece spawns at x=4, occupying cols 4-5 — standard SRS O spawns at cols 4-5? Standard is cols 3-4 in some, 4-5 in others. Fine.

Now let me test interactions. First, note the current piece is O. Let me test moves/rotations with keyboard. The browser tool sends keys to the page. Let's do: press ArrowLeft twice, ArrowUp (rotate — O rotation should be no-op but with kicks it stays), then Space hard drop.

Better: I should verify programmatically too. But the sandbox may not let me evaluate JS directly... The browser tool only has click/drag/key/type/scroll/screenshot/inspect/motion. No evaluate. So I'll verify via screenshots and DOM text (score/lines/level).

Let me press keys. First check the piece: O. Rotation of O: rotate matrix 2x2 gives same shape, so no visible change. Let me instead restart to get a fresh piece? Restart gives random piece. I'll just test with O: move left, hard drop, check that a new piece spawns and preview advances.

Actually to verify "move and rotate the first piece" more visibly, I could use hold to swap pieces. Simpler: just do the sequence and screenshot.

Let me press ArrowLeft twice and screenshot.

The piece moved left (now at cols 2-3) and fell due to gravity (now at rows ~11-12). Ghost follows at bottom. Movement works.

Now rotate (O rotation is invisible). Let me press ArrowUp anyway, then hard drop with Space, and check the piece locks and a new piece spawns + preview advances (next should become I).

Interesting — the piece is now at the bottom (rows 18-19) and the ghost is not visible separately (it coincides with the piece). Gravity elapsed more. Rotation of O is a no-op visually (correct).

Now hard drop with Space. The piece is already at the bottom, so hard drop locks it. Then a new piece spawns (S, green) and preview should advance to I, T, plus a new third from the bag.

Hmm. Something is off. The locked yellow O piece is at the bottom (rows 18-19, cols 2-3) ✓. But the active piece appears to be a green S at rows ~15-16 and there's a cyan I at the top of the board (row 1) — that's odd. Wait: the cyan I at the top row 1... and the green S near bottom overlapping the ghost?

Let me re-read the image: Top: cyan I piece horizontal at row 1, cols 3-6. Middle-bottom: ghost outline (4 cells) at row 15 cols 2-5, and green S cells at rows 16-17, and yellow O at rows 18-19.

So there appear to be TWO active pieces drawn? No — the cyan at top must be... hmm, the queue was [O(spawned), S, I, T]. After hard drop, spawn takes S from queue → queue becomes [I, T, +new pull]. The preview shows T, L(orange), Z(red). So queue after spawn = [T, L, Z]. That means spawn pulled... wait: initial queue was [O,S,I,T] displayed? No — the initial preview showed S (green), I (cyan), T (purple) = queue[0..2] = S, I, T, with piece O. After locking, spawn shifts S out and pulls a new one from bag → queue = [I, T, Z?]... but preview shows T, L, Z. Hmm, that means two pieces were consumed? Preview shows queue[0]=T, queue[1]=L, queue[2]=Z.

Wait, before the space press, the preview showed S, I, T. Now it shows T, L, Z. So queue advanced by 2 (S and I consumed). And the drawn active piece is green S near the bottom?! And cyan I at top.

Oh! I see the bug: the S piece shown near the bottom is actually... let me think again. Actually the green cells at rows 16-17: pattern is row16: cols 3,4; row17: cols 2,3 — that's an S shape. And the cyan I at the top row 1 cols 3-6 is the I piece.

So both S and I appear on the board. That means... the S was locked into the board? No, the S is at rows 16-17 above the yellow O. Hmm, but wait — the yellow O is at rows 18-19. So the S looks like it landed on top of the O! And the ghost outline (4 cells wide) at row 15 belongs to the current active piece which is the cyan I at top.

So: the S piece got LOCKED onto the board on top of the O, and the current piece is I (cyan) with its ghost at row 15 (4 cells wide, cols 2-5). Yes! That's consistent: the ghost is 4 cells wide = I piece. So active piece = I at top, and S was locked.

Why did S lock immediately after spawn? Because of double-lock: hardDrop → lockPiece → spawnPiece (S spawns at rows 0-1). Then... the update loop: G.dropTimer was reset in spawnPiece. Hmm.

Ah wait — I see. In hardDrop, I do `while(!collides(...)) d++;` then lockPiece. lockPiece → spawnPiece → new piece S. Then syncHud. That's fine.

But the S piece landed on top of the O piece at rows 16-17... The O was at rows 18-19, cols 2-3. S resting on top: rows 16-17 with cells at (16,3),(16,4),(17,2),(17,3) — that's exactly resting on the O. So S fell from spawn to landing... that took 16 rows of gravity, which at 1000ms/level would take 16 seconds. The screenshots between actions take real time? Possibly a lot of time elapsed between the reload and now (each browser call could be seconds apart, plus the piece fell during the ArrowLeft→ArrowUp gap ~ we saw O fall from top to bottom in that gap, so time passes quickly — maybe the harness advances frames with a big dt, or real time between calls is many seconds).

Actually yes: between the ArrowLeft screenshot (piece at rows 11-12) and the ArrowUp screenshot (piece at rows 18-19), several seconds passed. So after the hard drop, the S piece fell and locked on top of the O stack. That's normal game behavior — just real time passing between my tool calls. Fine.

So the state is consistent: hard drop locked O, S spawned, preview advanced (S→ now T at front), then S fell and locked naturally, and I spawned. 

Score 22 = 2*11 cells hard dropped (piece was at rows 18-19 already? Hmm, d should be 0 since it was resting at bottom... Actually at the ArrowUp screenshot the O was at rows 18-19 = bottom, so d=0 and score would be 0. But score shows 22. Let me check: maybe the O was at rows 17-18 in that screenshot (the last visible row of the board is cut off in the screenshot? The board bottom edge is at y≈690 in the image, and the piece bottom at ~685). Hmm, the canvas is 600 tall displayed from y=65 to 665... Actually in the screenshot the board spans y≈70..690 and the yellow piece bottom is at ~685, so it's at the bottom rows 18-19. Then d=0 → score 0. But score = 22.

Hmm, 22 could come from... wait, maybe the piece was at rows 17-18 (d=1 → 2 points) and then 20 more? No.

Let me reconsider: maybe score came from a line clear? No, lines=0.

Alternatively: the O piece in the ArrowUp screenshot was at rows 17-18, and hard drop moved it 1 row (+2). Then 22-2 = 20 = 10 rows × 2 for the S piece? No, S locked by gravity, no score.

Hmm, what about softDrop scoring? Not used.

Wait — maybe the score is from the I piece? No.

Let me recompute: could the O have been at rows 8-9 in the ArrowUp frame and the screenshot... no, it was clearly near the bottom.

Hmm, 22 = 2*11. If the O was at rows 7-8 at the time of the key press and fell 11 rows to rows 18-19. But the screenshot showed it at the bottom... Screenshots are taken at a moment; the key press may have happened at a later time (after more falling). Actually the key action likely happens then screenshot taken right after — the piece shown in the ArrowUp screenshot is post-keypress. Hmm, but the screenshot after ArrowLeft showed the piece at rows 11-12, and after ArrowUp at rows 18-19. So at Space press time it may have already been at the bottom → d=0.

Unless... the space press happened at a time when the piece was at rows 7-8? No, time only moves forward.

Alternatively the 22 points came from something else. Let me check the code: hardDrop adds 2*d. softDrop adds 1 per cell. Hmm, in the update loop, gravity movement doesn't add score. So 22 must be 2*d with d=11.

Oh wait! I bet the sequence is: the Space key press happened, piece fell 11 rows (it was at rows 7-8 in real time when the event fired?) — no...

Hmm, actually maybe the screenshot for ArrowUp was taken BEFORE the render of a later state, or the screenshots are taken at fixed intervals... Whatever. Another possibility: the harness's "key" action takes time (e.g., it may wait a bit before screenshotting). Not important — but let me double check there's no double-counting bug. Actually there's a real possibility: `blip()` and the keydown handler... no score there.

Wait, there's another possibility: the browser tool's key event may have been delivered as a keydown with `repeat`? For Space I guard `if(!ev.repeat)`. If the tool sends keydown+keyup quickly, fine.

Hmm, what if the tool's "key" text "Space" maps to key " " — yes handled.

Let me consider: maybe between the ArrowUp screenshot and Space, the game... the O piece can't fall past the bottom. So d=0.

Unless the piece in the ArrowUp screenshot was at rows 17-18 (bottom row of the canvas is at y=690 in the image; the yellow block bottom edge at ~685 → row 19 ends at 690 → so it's rows 18-19). Hmm, in the latest screenshot, the yellow O bottom is at ~685 too. So O is at rows 18-19. OK.

So where does 22 come from? 11 rows × 2. Maybe the O was at rows 7-8 when Space was pressed and the screenshot after ArrowUp was stale/taken before the fall? No — the ArrowUp screenshot showed it at the bottom, which is later than 7-8.

Unless the harness re-rendered... Let me just verify the scoring directly with a controlled test: restart, then immediately hard drop and check score = 2*d where d is the drop distance. Since gravity is 1000ms and the piece spawns at row 0, hard drop from spawn should give d = 18 for O (rows 0-1 → 18-19) = 36 points. For I (row 1 → row 19): d=18 → 36.

Rather than guessing, let me do a controlled test: click Restart (score resets to 0), then immediately press Space and read score from DOM. Then I can compute expected.

Actually, there's a subtle possible bug: in `hardDrop` I call `lockPiece()` then `syncHud()`. In lockPiece I also call syncHud. Fine.

Another: `G.score += 2*d` — d is rows dropped. And softDrop +1 each. Fine.

Hmm! I found it: the ArrowLeft screenshot showed the piece at rows 11-12. Then ArrowUp: rows 18-19 — meaning ~7 seconds passed (7 gravity steps at 1s). Then Space: 22 points = 11 rows. That doesn't fit either.

Unless... the O piece was NOT at the bottom in the ArrowUp frame but at rows 17-18, and the ghost/piece... 

OK let me stop speculating and test in a controlled way. Also, an important consideration: maybe the harness's screenshots are taken at a moment that doesn't correspond to the keypress time (e.g., keypress happens, then it waits for animation frames). Let me test: Restart → screenshot (score 0) → Space → screenshot (score should be 2*d).

Let me also verify line clearing works. To clear lines quickly I'd need to fill a row — hard with random pieces and real time passing. Alternative: I can verify line-clear logic by filling a row via many hard drops... that's a lot of tool calls.

Better idea: expose a small test hook? I shouldn't add test-only code to the deliverable... Actually it's acceptable to verify logic by reasoning + a targeted manual run. Hmm.

Alternative approach: use the browser tool but drive the game through many key presses in one call? The tool only takes one action per call. I could use `type` with a long string of characters — but `type` types text characters, which would trigger arrow keys? No, type sends character keys. If I type "cccc"? no.

Hmm — but I could exploit `type` to enter spaces: typing "      " sends 6 space keydowns → 6 hard drops. That's useful! But arrow keys aren't typable.

Another approach: add a hidden debug API to the game? Many would consider that fine but it adds code. Actually, a cleaner verification path: I can copy index.html to a test file and use node to simulate the pure game logic? The logic is embedded in the HTML but I could extract the script and run it in node with a stub DOM. That's a solid way to verify line clears, scoring, level, game over, restart.

Let me do that: extract the <script> content, create a jsdom-free harness with stubs for document/window/canvas. That's a bit of work but doable: I need document.getElementById returning stub objects with getContext returning a proxy that ignores calls, addEventListener stubs, style, classList, textContent.

Let me write a node harness:

```js
const fs=require('fs');
const html=fs.readFileSync('index.html','utf8');
const script=html.match(/<script>([\s\S]*)<\/script>/)[1];
// stubs
function ctxStub(){ return new Proxy({}, {get:(t,p)=> { if(p==='canvas')return {}; return (...a)=>({measureText:()=>({width:10})}); }, set:()=>true}); }
```
Careful: code uses ctx.setTransform, fillRect, etc. and sets properties. Proxy with get returning function for everything and set allowed works. Also `ctx.globalAlpha = 1` set → fine.

document stub: getElementById returns element stub with getContext, style, classList{add,remove}, textContent, innerHTML, addEventListener, width/height.

window stub: addEventListener capturing keydown handler, devicePixelRatio, AudioContext undefined.

performance.now, requestAnimationFrame: stub to no-op (so the loop doesn't run) — but then update() never runs; I'll call functions manually. But the script's functions are in module scope of the eval — I need access. I can append to the script a line exporting globals: e.g., run with `new Function(script + "; return {G, resetGame, hardDrop, move, rotatePiece, softDrop, holdPiece, update, spawnPiece, collides, lockPiece, finishClear, togglePause, el};")`. Since the script uses "use strict" and const/let at top level of the function body, that works — those declarations become local to the function, and the return statement can access them. 

Then simulate: place pieces to fill a row. E.g., set G.board manually to near-full row and drop a piece to complete it, then run update(dt) to advance the clear animation and check score/lines.

That's a good verification. Let's do it.

Also verify: reject moves off-board (move left 5 times → x stays at min), rotation rejection when blocked, game over when stack reaches spawn, restart resets everything, 7-bag produces all 7 in each 7 spawns.

Let me write the harness.

Also note: `blip` uses window.AudioContext — undefined → returns early. Good. `performance.now` needed. `requestAnimationFrame` — I'll stub as no-op to avoid recursion.

Let's write it.

Good, node 24. Let me write the harness in /tmp (not in cwd, to keep index.html the only deliverable... actually keeping test files out of cwd is cleaner; but /tmp/job-Lkjv9U is cwd. I'll write test file to /tmp/tetris_test.js).

I left some garbage in section 2 (broken loops). Let me clean those up before running — the `for` loops with weird IIFEs might throw. Let me remove that junk.

Also the "left move rejected at left wall" test uses `api.bounds ? 1 : 1` weirdness in test 4 - fine. And test 3's right wall check: `maxX + 1 > 0 && collides(...)` ok.

Also I removed `const first8` but the earlier lines reference `seq` still fine.

Let me run.

The 4 failures are all single-line-clear tests using an O piece. Interesting: the tetris/double/triple tests (vertical I) passed. Why does the O single-line test fail?

In my test: board rows: bottom row filled cols 0-8 (hole at col 9). Marker at (ROWS-2, 0). O piece placed at x=8, y=ROWS-3 → cells (ROWS-2,8),(ROWS-2,9),(ROWS-1,8),(ROWS-1,9). But (ROWS-1,8) is already filled by "#777"! So the O collides at its initial position, and hardDrop with d=0 locks it overlapping... then bottom row was already full? Let's see: bottom row cols 0-8 filled, col 9 filled by O → row full → should clear!

Wait but rowsAfter shows ["0000000011","1000000011","1111111110"] — so the bottom row is "1111111110" = col 9 empty! And rows above have O at cols 8,9. That means the O landed one row higher than expected: O occupies rows ROWS-3 and ROWS-2 at cols 8,9. So the O's bottom is at ROWS-2, and (ROWS-1,9) stays empty.

Why? Because the O piece's matrix is 2x2 and y=ROWS-3 → cells rows ROWS-3, ROWS-2 (i.e., 17,18), not 18,19. I mis-indexed: O at y=ROWS-3 occupies rows ROWS-3 and ROWS-2, so bottom row ROWS-1 untouched. My test expectation was wrong, not the game. The O rests on top of the filled bottom row cells at col 8: hardDrop → while not collides at y+1: at y=ROWS-2, cells rows ROWS-2,ROWS-1 → (ROWS-1,8) filled → collide. So it stays at ROWS-3/ROWS-2. Right — my test setup was wrong: I need the hole at col 8 or 9 and place the O so it fills the hole.

Let me fix the test: fill bottom row cols 0..7 (hole at cols 8,9), place O at x=8, y=ROWS-2 → occupies rows ROWS-2,ROWS-1 cols 8,9 → completes bottom row. And marker at (ROWS-2,0) to check shift-down.

Wait, but O at y=ROWS-2 occupies rows ROWS-2 and ROWS-1 → bottom row gets cols 8,9 filled → row full → clears 1 line. Good.

Similarly for the level-multiplier test and the 10th-line test: same fix.

So the game logic is likely fine; my test setup was off. Let me fix the three tests.

Also check the tetris tests: they used rows ROWS-n..ROWS-1 filled except col 9, and a vertical I at x=9, y=ROWS-4 with m=[[1],[1],[1],[1]] → occupies rows ROWS-4..ROWS-1 col 9 → fills the holes in the bottom 4 rows. Passed. Good.

Let me fix and rerun.

No python3. Use node to patch the file.

All 32 logic checks pass. Now back to the browser for the visual/interactive verification pass required by the task: restart, move, rotate (visible piece), hard drop, check lock + spawn + preview advance, pause/resume, restart.

Let me also check the earlier score anomaly (22 points). With the harness, hard drop scoring works as 2*d. In the browser, the O piece fell from spawn to bottom over time and then hard drop... Actually the score of 22: hmm, wait. Let me reconsider: maybe the browser tool's `key` action for "ArrowUp" happened while the piece was mid-fall, and then the screenshot was taken later. Then Space pressed while the piece was at rows 18-19 → d=0 → 0 points. But 22 appeared. Unless the screenshot after ArrowUp was taken at the moment of key press... then the piece was at rows 18-19 (bottom) → d=0.

Hmm, could the piece have been repositioned? Actually! Look at the ArrowUp screenshot: the ghost outline is NOT visible separately, which means the piece was at its landing position. So d=0.

So where did 22 come from? Let me look for a possible double-scoring: In hardDrop I add 2*d, then lockPiece → syncHud. Hmm.

Oh wait! I see it. In the browser, the piece shown at rows 18-19 in the ArrowUp screenshot... then between ArrowUp and Space, the O piece stays. But actually, maybe the harness's key events are queued and the screenshot for ArrowUp was taken after gravity moved it. Whatever — the possibility of a real bug: `softDrop` is not involved.

Alternatively, maybe the Space key press happened BEFORE the ArrowUp screenshot? No, order is sequential.

Hmm, another candidate: the browser tool may send key events with `repeat` semantics... no.

Let me just test cleanly in the browser: click Restart (score → 0), then immediately press Space and read the score. Expected: for the spawned piece, d = distance to floor. For O: spawn y=0, lands at y=18 → d=18 → 36. For I: occupies row 1, lands at row 19 → d=18 → 36. For J/L/S/T/Z: occupy rows 0-1, land at rows 18-19 → d=18 → 36. Hmm, all 36 if pressed immediately. But gravity may have moved it down by the time Space registers, reducing d. Total should be exactly 36 regardless (since 2 per row, and total distance from spawn to floor is 18 for all pieces... wait for I: spawn occupied row 1, floor row 19 → 18 rows. Yes 36 for all). Unless gravity already moved it some rows (those rows give no points, so total < 36).

So the earlier 22 is inconsistent with a total drop of 18 rows (should be ≤36 and even). 22 = 2*11 → the piece dropped 11 rows via hard drop, meaning at press time it was at rows 7-8. That contradicts the screenshot showing rows 18-19... unless the screenshot was taken at a *later* time than the keypress. That's plausible if the harness presses the key, then waits for a frame/render... hmm, that would be later, showing the bottom position.

Wait no. If the key press occurred when the piece was at rows 7-8, the screenshot taken after would show the piece at 18-19 (locked? no, locked pieces stay). Hmm, the ArrowUp screenshot showed the O at rows 18-19 as an *active* piece (bright, with ghost overlapping). If it had locked, it would still be drawn at 18-19 identically, and a new piece would spawn at the top. In the ArrowUp screenshot, there was NO piece at the top of the board. So the O was still active at rows 18-19 at screenshot time... 

Unless the screenshot in the ArrowUp call was taken right after the keypress but before the next rAF paint... The screenshots come from the harness; can't be sure about timing.

Actually here's a cleaner explanation: the harness's screenshot might be captured at a moment slightly *before* the key is dispatched?? Unlikely.

Let me instead consider: 22 points could come from a *sequence*: hard drop d=0 gives 0... hmm, what if the ArrowUp rotation moved the piece up (kick [0,-1])? For O at the bottom: rotate CW of 2x2 identity matrix → same matrix, kick [0,0] succeeds → no move. So no.

OK: another possibility — the space keydown fired twice (keydown + key repeat with ev.repeat false), causing two hard drops: first locks O (d=0, 0 pts) and spawns S; second hard drop drops S from row 0-1 to bottom of stack... S lands on top of the O stack: O at rows 18-19 cols 2-3; S spawn x=3, cells (0,1),(0,2),(1,0),(1,1) → cols 3,4 / 3,4... wait x=3: cells (row0: c=1,2 → cols 4,5; row1: c=0,1 → cols 3,4). Falling: bottom-most cells are row1 at cols 3,4. Col 3 has O at rows 18-19 → S's row1 can't go below row 17 → y=16 → dropped 16 rows → 32 points. Hmm, 32 ≠ 22.

But wait, in the final screenshot the S appears at rows 16-17 exactly resting on the O! And the score is 22. If S had been hard-dropped, score would be 32. If S fell by gravity and locked, score += 0.

Hmm, 22 = 2*11. What if the O was at rows 7-8 when Space fired? Then hard drop d=11 → 22 points, O locks at rows 18-19 ✓, S spawns ✓, and by the time of the screenshot (which is after) S had fallen to rest on the O ✓ (that takes 16 seconds of gravity... plausible if the harness waits). And the ArrowUp screenshot showing O at rows 18-19 would be... inconsistent, unless the ArrowUp screenshot was taken after the Space press was processed? No, the Space press came after.

Hmm, unless the ArrowUp screenshot was taken at a *later* real time than the Space press?? The screenshots are attached to each call's result; the harness may capture a screenshot after some delay. If the ArrowUp call returned a screenshot taken after a long delay... but the Space call's screenshot shows more progress (S locked, I spawned). So the ArrowUp screenshot is earlier in game time than the Space screenshot. And it shows the O at the bottom as active. Then Space's hard drop should give d=0.

Contradiction. Unless the piece visible at rows 18-19 in the ArrowUp screenshot was already LOCKED and the current active piece was the newly spawned S at the top — but the top rows in the ArrowUp screenshot were empty... Let me look again at the ArrowUp screenshot description: yellow block at bottom rows ~18-19, nothing at top. Score 0 at that time.

Hmm wait, maybe it's the O locked at 18-19 and the active S is at rows 0-1 but rendered... no, the top was empty.

Alternatively, maybe the browser tab was throttled (rAF paused) between calls, so the game state froze at "O active at bottom" and time only advanced when the harness ran frames. Then upon Space press: d=0 → 0 points. Still not 22.

I can't explain 22 from reasoning. Let me look for a scoring bug in the code once more:

```js
function softDrop(){ ... if(!collides(...)){ y+=1; score+=1; ...} lockPiece(); }
```
Not called by Space.

keydown handler: `case " ": case "Spacebar": if(!ev.repeat) hardDrop(); break;`
Then at the end: `if(k !== "ArrowDown") blip(...)`. No score.

hardDrop: 
```js
let d=0; while(!collides(m,x,y+d+1)) d++; piece.y+=d; score+=2*d;
```
Correct.

Hmm — unless the harness's "key" action for Space is implemented as typing a space into the page... it dispatches a keydown with key " ". OK.

What about `HANDLED.indexOf(k)` — irrelevant.

So 22 implies d=11 at press time. The only way: the piece was at rows 7-8. So the screenshot I interpreted as "rows 18-19" must have been the O at rows 17-18 or the image timing differed. Actually! Look at the ArrowUp screenshot again: the yellow block's bottom is at y≈685 while the board's bottom border is at y≈690. In the Space screenshot, the yellow block's bottom is at y≈685 too. Both at rows 18-19. Hmm, in the ArrowLeft screenshot, the piece was at y≈440-490 (rows 12-13) and ghost at 620-680.

OK here's another thought: maybe the harness's screenshots are rendered from a *paused/throttled* state and the piece positions I see are stale relative to the actual game state. E.g., in the ArrowUp screenshot the game had already advanced (O locked at 18-19, S spawned at top) but... no, then S would be visible at top.

I'll do a clean controlled browser test now: Restart → screenshot → Space → screenshot, and check score is ≤36 and even, and consistent. Let me also verify the "hard drop from spawn = 36" expectation.

Actually, maybe I misread and the score 22 came after the piece had already been partially dropped... Let's just test cleanly.

Note: gravity at level 1 is 1000ms, and real time passes between my calls (several seconds), so pieces fall. To get a clean measurement I should click Restart and immediately press Space in the same... can't combine. I'll do Restart then Space quickly in two calls and read the score; expect 36 minus 2*(rows already fallen).

Let me do it.

Restart worked: board cleared, score 0, level 1, fresh J piece at top-left (cols 2-4, rows 0-1), preview shows O, S, Z, hold empty.

Now: move right twice, rotate CW (J → visible change), then hard drop.

Moved right by 1 (now cols 3-6... actually the J now at cols 3-5). Piece still at rows 0-1 (gravity hasn't advanced much, or the screenshot is immediate).

Now rotate CW.

Rotation CW worked: J is now in the vertical orientation (cells: row0: cols 5,6; row1: col5; row2: col5 → wait the image shows top row two cells at cols 5,6 and then a column at col 5 going down 3). That's the J "R" state... Let me verify: J spawn (0,0),(1,0),(1,1),(1,2). CW → (0,1),(0,2),(1,1),(2,1) which is:
```
.##
.#.
.#.
```
Yes matches the screenshot. ✓ And the ghost follows correctly at the bottom.

Also the piece fell a bit (now at rows 6-8). Good.

Now hard drop with Space, and check score = 2*d.

Hmm, wait. The screenshot shows:
- Blue J locked at the bottom (rows 17-19, col 5 + row17 cols 5,6) ✓ locked into board.
- A YELLOW O piece at rows 15-16, cols 4-5 — locked? It appears solid (not ghost). 
- A green S piece at the top (rows 0-1) — active, with ghost at rows 13-14.

So the O got locked too?! That means two pieces were locked between my Space press and the screenshot. Ah — I understand now: the queue was [O, S, Z]. After J hard-dropped, O spawned. Then real time passed during the tool call, O fell and locked (gravity), then S spawned at top. That explains the earlier 22-point anomaly too? No... the earlier score of 22 came from a single hard drop.

Hmm, but wait: the score is 24 now. J's hard drop: J was at rows 6-8 (bottom cell row 8) and landed at rows 17-19 → d = 9 → 18 points. Hmm, 24 = 2*12. The J's lowest cell was at row 8 in the screenshot; landing row 19 → for the J in vertical state, cells rows 0..2 relative; bottom cell at y+2. In the screenshot, the J occupied screen rows ~6,7,8 → y=6, bottom cell row 8. After drop, bottom cell at row 19 → d = 11 → 22 points. Hmm, 24 = 2*12.

The screenshots may lag the actual state by a frame or two of gravity. Fine — the numbers are consistent with hard-drop scoring (2/cell) with the exact fall distance unknown due to timing. Also possible: after O locked by gravity (no points), S spawned... no points.

Actually 24 could be 22 (J) + 2 from something? Or the J fell 12 rows. Either way, hard-drop scoring works.

So no bug — the earlier "22" was just the actual fall distance at press time (screenshots lag real game time because the harness's screenshots are taken at a different moment than the key dispatch).

Now: the preview advanced correctly. Before: O, S, Z. Now active = S?? Wait, the active piece is green S at top, and the preview shows Z (red), T (purple), L (orange). So queue advanced: [O,S,Z] → O spawned (consumed), queue [S,Z] + pull → [S,Z,T?]. Then O locked by gravity, S spawned, queue [Z,T,L]. Preview shows Z, T, L ✓. Consistent.

Board: J locked ✓, O locked ✓, S active at top ✓, ghost shown ✓.

Now test pause: press "p" and check overlay + button label "Resume". Then resume. Then restart.

Note: while paused, gravity freezes (verified in harness).

Let me press p.

Pause overlay shows "PAUSED", button label changed to "RESUME", board dimmed. Note the game continued to progress a bit before pausing (S locked, Z active at top, preview now T, L, I).

Now click Resume button and verify overlay disappears.

Resumed: overlay gone, button says PAUSE, Z active at top, stack below. 

Now let me verify a line clear visually... that would take many moves. The harness already verified clearing logic. But it would be nice to see the flash + score in the browser. I could try: use the HOLD button and arrow keys to build up... too many calls. 

Instead, let me do a quick visual check of a line clear by stacking pieces in one column region? Not needed — logic verified headlessly.

Let me now test Restart and check the board/score/level reset. Also test game over visually? Hard. Skip.

Click Restart.

Restart worked: board cleared, score 0, lines 0, level 1, fresh J piece, new queue (I, S, O), hold empty.

Interesting: the J spawned again at the same position — new bag.

Now let me verify a line clear visually in the browser. I have time budget (~5 min used of 15). A quick way: repeatedly hard-drop pieces into the left columns to fill a row? Each row needs 10 cells; with 4 pieces (16 cells) I could fill cols 0-3 fully (4 wide × 20 rows = 80 cells = 20 pieces) — too many. 

Alternative: fill a single row by dropping pieces to the far left and far right alternately — still needs 10 cells in one row, which happens naturally if I stack pieces at the bottom alternating left/right. With random pieces, roughly 3 pieces placed at the bottom row could cover ~10 cells if I position them precisely. Let's try: drop pieces at the left edge (all the way left) and right edge alternately. Hmm, but pieces stack vertically, so bottom row cells: col 0-2 from J at left... 

Let me try a simpler approach: use soft-drop/hard-drop with alternating left and right wall positions. Each hard drop takes one tool call, plus arrow presses. That's ~2-3 calls per piece → ~10 calls for 4 pieces. Each call takes ~5-15s. Might be feasible but risky with gravity (pieces fall while I press keys, but hard drop overrides position anyway — the column matters, not the row).

Plan: press ArrowLeft ×10 (to slam to the left wall) then Space; then ArrowRight ×10 then Space; repeat. 4 pieces = 8 calls + key presses... Each call is one key. That's a lot of calls (10 left presses per piece!).

Better: hold key repeat? The `type` action types a string of characters — could I type "cccc"? Not arrows.

Alternative: use the browser `drag` action? No.

Hmm — what about the DAS? There's no auto-repeat handling beyond OS repeat; `move` on repeated keydown events works since I don't guard repeats for arrows. If I could send many ArrowLeft events in one call... `type` with text "←"? Not a real key event.

OK, alternative approach to visually verify a line clear: I already verified it headlessly with the real code path (hardDrop → lockPiece → clearing → finishClear → score/lines/level). That's solid. The visual flash is a nice-to-have.

But one thing worth verifying in the browser: the line-clear flash animation and that the game continues after a clear (no crash in the render path when G.piece is null during clearing). Let me check the render path when clearing: drawBoard iterates rows, uses G.clearing.rows — fine. G.piece null → skips ghost. OK.

Actually, there IS a potential runtime error worth checking: in `drawBoard`, `block()` with color "#ffffff" → shade works. Fine.

Another risk: `finishClear` splices rows — verified headlessly.

Let me try to trigger a line clear in the browser with a cheap trick: use Hold to cycle? No.

Alternative: I can trigger a clear quickly by stacking in a narrow well. Let me think about the minimum number of tool calls: I could press ArrowLeft 10 times... Actually, I can send a key press and the harness might support holding? No.

Hmm, what about this: the piece falls due to gravity while I press arrow keys, and each key call takes real time. If I press ArrowLeft once per call, that's 10 calls. Too many.

Alternative approach: fill the well differently — drop pieces near the middle where fewer moves are needed. To complete a row I need 10 cells in the same row. If I place pieces at the left wall (x=0) and right wall (x=6 or 7), the bottom row gets filled: e.g., J at left wall covers cols 0-2 in its bottom row; L at right wall covers cols 7-9. Then T in the middle covers 3-5. That's 3 pieces → bottom row full → clear! Requires moving to the walls: ~10 arrow presses each.

Unless... I use gravity time to my advantage: no.

I could add key-holding support? Not needed.

Alternative: verify the clear animation by temporarily... no, I shouldn't modify the game for testing.

I think a reasonable compromise: verify line clearing visually using a small number of calls by exploiting the fact that pieces spawn at columns 3-6 and drift. Honestly, the headless test covers correctness of the code path executed in the browser (same script). The remaining browser-only risk is rendering during the clearing window, which I can check with the `motion` action while a clear happens... but I need a clear to happen.

Let me try a different cheap trick to force a near-clear: play several hard drops alternating left/right using the on-screen... there are no on-screen left/right buttons. Hmm, only Hold/Pause/Restart/Sound buttons.

OK — decision: I'll add nothing; instead, let me do a quick sanity render check by using `motion` to observe the game running (gravity + locking) for a couple seconds, and confirm no console errors. Then accept the headless verification for line clears.

Actually wait — there's a smarter way to get a line clear in few calls: the board is 10 wide; if I let pieces fall naturally (gravity) without moving them, they stack in the middle columns 3-6. Never clears.

Alternatively: I can press ArrowLeft once and then Space repeatedly? Each Space is one call. Pieces would stack in one column region.

Hmm, what about typing spaces via `type` with a string of many spaces? `type` sends key events for each character — with text "          " (10 spaces) that's 10 hard drops in ONE call! And each hard drop needs positioning... but if I don't position, pieces stack where they spawn (cols 3-6).

Combined idea: use `type` with a string that includes characters that move pieces? `type` types characters like "c" (hold) — hold cycles pieces but doesn't move horizontally.

What about the fact that `type` may send keydown with key="ArrowLeft"? No, type sends literal characters.

So: I can't move horizontally in bulk. But here's a thought: I can send `key` "ArrowLeft" and the harness may dispatch with repeat? No.

Final answer: skip the visual line-clear; it's verified through the identical code path in the harness. Let me do a final `motion` check to make sure the running game renders smoothly and no console errors accumulate, then check the file is valid and finish.

Actually, one more consideration for a real bug hunt: what happens when the game is over and the user clicks Pause/Resume or Hold? togglePause only acts when playing/paused → in gameover state, pressing P does nothing ✓ (state stays gameover). Hold button in gameover: holdPiece checks state !== "playing" → returns false ✓. Good.

What about clicking Restart while paused → resetGame sets state playing ✓.

Also: game over while `G.clearing` active? Not possible since clearing → spawn → gameover.

One more: `finishClear` calls `spawnPiece()` which may set gameover ✓.

Another potential issue: after game over, the overlay covers the board; the last piece (which couldn't spawn) is drawn? In spawnPiece on collision I set G.piece = p and state gameover; drawBoard skips ghost when gameover but draws the piece at spawn overlapping the stack. Minor visual, acceptable.

Let me also double check the `keydown` handler's preventDefault condition: `if(HANDLED.indexOf(k) !== -1 || k === " " && ev.code === "Space")`. Fine. But when the user has focus on a button and presses Space, the button click fires AND hardDrop... e.g., after clicking Restart, focus is on the Restart button; pressing Space would trigger a click → restart the game! That's a real annoyance: user clicks Pause with mouse, then presses Space to hard-drop → the button re-activates (pause toggles) AND the piece hard-drops.

Fix: call `ev.currentTarget.blur()` in button handlers, or preventDefault for Space when the target is a button. Simplest: in each button click handler, blur the button. Let me add a helper: after handling, `e.currentTarget.blur()`. Or globally: on keydown, if document.activeElement is a button and key is " ", blur it. I'll add blur in the click handlers.

Also `preventDefault` on Space keydown at window level happens before the button's click activation? preventDefault on keydown for Space does prevent the click activation on buttons in most browsers (space activates on keyup for buttons; preventing keydown default prevents scrolling and the activation). Not fully reliable — blur is the robust fix.

Let me implement blur on all four buttons.

Also, arrow keys with a focused button: ArrowLeft/Right don't activate buttons, fine.

Let me make the edit and re-verify quickly.

Now let me try to see a line clear in the browser after all, using a trick: `type` a bunch of spaces to hard-drop pieces without moving them → they stack in cols 3-6 → no clear. 

Hmm, alternative: what if I use the Hold button repeatedly? No.

Let me try one thing: use `type` with text containing many "d"? Not mapped.

OK here's another idea that's cheap: I can fill a row by stacking against the left wall using gravity + the fact that pieces spawn at x=3. If I press ArrowLeft once per... 

Actually! Insight: `key` action might accept a key name; but what if I use `type` with text of repeated characters mapped to movement? My keydown handler supports "z"/"Z" (CCW rotate), "c" (hold), "p" (pause), "r" (restart). No horizontal movement via letters. I could ADD WASD support (a/d/w/s) which would let me use `type` to send many characters in one call — that's a legitimate feature improvement (keyboard controls) and enables a bulk test: type "aaaa...a" (10 a's) then spaces.

That's a nice addition: support A/D/W/S as alternates. Then `type` "aaaaaaaaaa" moves the piece 10 cells left (clamped at the wall), and `type` "          " (spaces) hard-drops. Hmm, does `type` send keydown with key=" " for spaces? Presumably it types characters, so key=" " → hardDrop. 

Let me add WASD support to the controls list and handler. Then attempt a visual line clear:
1. Reload (fresh game).
2. type "aaaaaaaaaa" (piece to left wall) — but between characters gravity is irrelevant since we then hard drop.
3. type " " → hard drop at left wall.
4. type "dddddddddd" → right wall; type " " → hard drop.
5. Repeat with different pieces; hopefully 3-4 pieces fill the bottom row.

Problem: pieces at the left wall have varied footprints; a clear isn't guaranteed. But worth a try with ~4-6 calls.

Actually the pieces at the left wall: J at x=0 in spawn orientation covers bottom row cols 0,1,2 (row1: 0,1,2) and top col 0. L at x=0 covers cols 0,1,2. I at x=0 covers cols 0-3. O at x=0 covers cols 0,1. S at x=0 covers cols 0,1 bottom / 1,2 top. T covers 0,1,2. Z covers 0,1 bottom... So left-wall drops fill cols 0-2ish, right-wall fills 7-9ish. Middle 3-6 needs 4 cells — pieces spawn there and if I just hard-drop without moving, they land in the middle columns 3-6.

So plan: left-wall drop, right-wall drop, then two no-move drops (they fall in cols 3-6 area) → bottom row might complete. The stack heights differ though: bottom row cells fill first for each piece since they all fall to the floor... yes, all pieces land on the floor initially, so their lowest cells occupy the bottom row (unless the bottom row already has cells there). So after ~4 pieces: left piece covers bottom cols 0-2, right covers 7-9, middle pieces cover 3-6. That should clear the bottom row!

Risk: rotation state varies, and the middle pieces (spawn x=3) cover cols 3-6 partially: J spawn covers row1 cols 3,4,5 → bottom cols 3-5; then another middle piece covers col 6 (L spawn: row1 cols 3,4,5 with the bump at col 5 top → hmm L covers bottom cols 3,4,5 too; I covers 3-6 → 4 cells!). 

So: left drop (cols 0-2), right drop (cols 7-9), and one I piece hard-dropped in the middle (cols 3-6) = full row! But I can't control which piece spawns. With 4-5 attempts, likely to work.

Let me implement WASD first, then try. Time check: I've used ~6 min. Fine.

Also add WASD to the controls list.

Wait: "s" for soft drop conflicts with nothing, but "S" also... fine. However note the keydown handler's `default: return;` — the blip line runs only for handled keys. OK.

Careful: 'r' restart, 'p' pause, 'c' hold, 's' soft drop, 'a'/'d' move, 'w' rotate, 'z' CCW. No conflicts.

Now reload and try the line-clear experiment:
1. reload → fresh game
2. type "aaaaaaaaaa" → piece to left wall
3. type " " → hard drop
4. type "dddddddddd" → next piece to right wall... but wait, the piece spawns at x=3, so 10 d's clamps at the right wall ✓
5. type " " → hard drop
6. type " " → hard drop the middle piece (no movement)
7. type " " → hard drop again
8. screenshot

Note: `type` might not send keydown for space characters properly. Let's test step by step. Also each hard drop in a single `type` with multiple spaces would drop successive pieces quickly — good.

Let me reload first.

Fresh game: J active, queue L, O, S. Controls list updated with WASD ✓.

Now: type "aaaaaaaaaa" (10 a's) then a space → left wall + hard drop. Let me combine into one type string: "aaaaaaaaaa " (10 a's + space). Then "dddddddddd " for the right wall, then "  " for two middle drops.

Careful: the first piece is J: at the left wall, spawn orientation cells: row0 col0, row1 cols 0,1,2 → bottom row cols 0,1,2 ✓.
Second piece L: right wall → L spawn: row0: col2; row1: cols 0,1,2 → at right wall x=7: bottom row cols 7,8,9 ✓.
Third: middle (spawn x=3): O at x=4 → cols 4,5 bottom; S at x=3 → bottom cols 3,4. 
So after J(0-2), L(7-9), O(4,5), S(3,4) → missing cols 6. Need a piece covering col 6: I at spawn x=3 covers 3-6 ✓ (but bottom would be row 1 of matrix... I covers cols 3-6 in one row ✓).

The queue is L, O, S + bag. Let me just drop 5-6 pieces alternating left/right/middle and see if a line clears. Strategy per piece: alternate left wall, right wall, and no-move (middle). Since pieces land on the floor only if the column is empty; as the stack builds, subsequent pieces land higher, and the "bottom row" completion needs exactly cols 0-9 filled at row 19.

Left-wall drops fill cols 0-2 (row 19), right-wall fills 7-9, middle fills 3-6. So sequence: left, right, middle(1 or 2 pieces). Let me do: "aaaaaaaaaa " then "dddddddddd " then " " then " " then screenshot.

But note: gravity is 1000ms and pieces spawn at the top; between my type calls, pieces may fall partway — that doesn't matter for hard drops (they slam to the floor).

One concern: while typing 10 a's, if the piece locks due to gravity before the space arrives... unlikely within ~100ms of typing. But the tool may type slowly. Risk accepted.

Also: if a piece lands on the stack and locks before the space, the next piece's index shifts. Fine.

Let's go.

Hmm! The piece moved LEFT but only to x=2 (cols 2,3,4) — not to the left wall (x=0). And the space hard-drop didn't happen (piece still active at rows 12-13, score 0).

Wait, the piece is at cols 2-4, rows 12-13. It moved left by 1 from spawn (x=3 → x=2). So only ONE 'a' keydown was registered? Or the `type` action typed into... Hmm, "aaaaaaaaaa " — maybe the type action sends characters via a single input event or types them but my handler... Let me think: `type` probably sends key events per character. Only one move registered and no hard drop.

Hmm, maybe the type action sends `insertText` (CDP) which produces keydown with key="a" but... it produced only one? And the space didn't register at all (no hard drop, score 0).

Wait, actually maybe the space DID register as a hard-drop but the piece was mid-air... no, score 0 and the piece is still active at rows 12-13 with a ghost at the bottom.

So: `type` delivered 1 keydown for 'a' and none for space? Odd. Possibly the tool types text into a focused element (document.activeElement) and only one event got through, or it dispatches with `key` values that differ.

Alternatively: my handler ran for the first 'a' (move left ✓), then... subsequent 'a's also moved left but hit the wall? No — the piece is at cols 2-4, not at the left wall (cols 0-2). Unless... hmm, wait: J spawn is x=3 → cols 3,4,5. Now it's at cols 2,3,4 → moved left exactly 1.

So only one 'a' keydown registered. Maybe the harness's `type` sends the text as a single "insertText" event, and my handler sees key="a"?? Unclear. Or maybe the harness has a per-call event budget.

Also possible: the harness's type sends keydown/keyup pairs per char but with a delay; the screenshot was taken mid-typing (after 1 char). And the space char may be swallowed by the browser (space → but preventDefault...). Hmm, the screenshot is taken at +0ms per the output, so typing may still be in progress?? The output says "Frame 1, +0ms" — maybe it captured immediately.

Let me try again with a different approach: send `key` calls individually (works reliably, as shown earlier). But 10 calls per piece is too many.

Alternative approach for the visual line clear: use `type` with a longer string and then take a `screenshot` in a separate call to see the final state after typing completes. Let me test: type "dddddddddddddddd" and then screenshot in the next call. If the piece ends at the right wall, typing works but the screenshot is just taken early.

Let's do that: type "dddddddddddddddddddd" then screenshot.

Interesting: the J piece LOCKED at the bottom-left (rows 18-19, cols 2-4) — it fell by gravity and locked (not a hard drop, score still 0 ✓ consistent with gravity lock). Now L is active at rows 8-9, cols 4-6, and the preview advanced to S, I. So the 'd' keys didn't move the L piece at all — because it spawned after the typing? Hmm, the typing happened while J was active (moving it right? no...).

Wait: the J is at cols 2-4 which is where it was after the single 'a' move (cols 2-4). So the 20 'd' presses did nothing to J... unless they moved it right and then... no, J is at cols 2-4 = same as before.

Hmm, so the `type` action's characters aren't producing keydown events that my handler processes (except the one 'a' earlier?). Odd. Maybe the earlier 'a' came from... hmm.

Actually maybe `type` sends events to the focused element only — after my earlier click on the RESTART button, focus was on the button, but I call blur() now... The reload happened after; no clicks since. So document.body has focus and window keydown should fire.

Maybe the harness's `type` uses `page.keyboard.type()` in Playwright which does dispatch keydown/keyup per character. Then 20 'd' keydowns should have moved L to the right wall. The active L is at cols 4-6 (spawn position x=3? L spawn x=3 → cols 3-5; the image shows cols 4-6 → moved right 1). So exactly ONE 'd' registered again!

So `type` seems to register only the first character (or the tool's screenshot is taken after 1 char and the rest arrive later?). The "Frame 1, +0ms" suggests it captured the first frame. Maybe the type is async and the rest of the characters land after the screenshot. If so, the state I see is mid-typing.

Let me take a plain screenshot now to see the settled state.

So only 1 'd' registered: the L piece locked at cols 2-4 (row 17) — wait, the L is now locked at rows 16-17 (col 4 top, cols 2-4 bottom), and O is active at the top. Preview: S, I, T.

So each `type` call registered only ONE keydown (the first character). The rest were dropped. So bulk typing isn't available.

Conclusion: I can't cheaply fill a row in the browser. The line-clear logic is verified headlessly via the exact same script (hardDrop → lockPiece → clearing → finishClear → score/lines/level), so I'm satisfied.

Current state: O active at top, stack of J+L at bottom-left. I could try to complete a row... The bottom row has cols 2,3,4 filled (J) — need 0,1,5,6,7,8,9 = 7 more cells. Each piece needs precise positioning which requires multiple key calls (each call = 1 keypress). Not feasible in the remaining time budget (I've used ~9 min).

Let me instead do one more valuable browser check: the line-clear *rendering* path (G.clearing non-null) — I can't trigger it. Alternatively, verify no console errors after all this play (console is clean: only the sandbox iframe warning). ✓

One more important check: game over overlay in the browser. I can trigger it by letting pieces stack up... that takes ~20 pieces. Alternatively, I verified headlessly.

Let me do a final static check of the file: validate HTML/JS syntax (node --check on the extracted script), confirm no external resources (no http/https URLs), and confirm the file is self-contained.

Also let me double check one edge case in the code I noticed: in `holdPiece`, when `prev` exists and the swapped-in piece collides, I set gameover — fine.

Another: `spawnPiece` sets `G.canHold = true` — but holdPiece calls spawnPiece when the hold was empty, which resets canHold to true, breaking the "one hold per piece" rule! Let's trace: holdPiece with empty hold: G.holdType = cur; prev = null → spawnPiece() → sets G.canHold = true. Then after the if/else, G.canHold = false is set (since it comes after). Order in code:

```js
if(prev){...} else spawnPiece();
G.canHold = false;
```
Good — canHold=false is applied after spawnPiece. ✓ (My headless test "second hold without lock is rejected" passed.)

But there's a subtle issue: after holding with an empty hold, the next lock → spawnPiece → canHold=true ✓ correct.

Another check: `G.dropTimer` reset on spawn ✓.

Potential issue: in `update`, `while(G.dropTimer >= step)` with step possibly small at high level; dt capped at 60ms → at step=20ms, 3 iterations max. Fine.

Let me run a syntax check and grep for external URLs.

Finalizing now. index.html is saved and valid (JS syntax OK, no external refs, 32/32 headless logic checks pass, browser-verified interactions).

Let me do a final reload sanity check quickly to confirm the file after the WASD edits still runs clean.

Final state is clean: fresh game, empty board, score/lines/level reset, next preview, controls shown, no console errors (only the harness's own sandbox iframe warning).

Done. Report.