Tetris · step-5-preview

There's a bug: in keydown handlers for ArrowLeft/Right/ArrowDown I use `current` without null-check. `tryMove` handles null, but `resting = !isValid(current.type...)` would throw if current is null. Let me guard.

Also note `board` might be undefined when resetGame... it's fine since resetGame runs before loop.

Also the clearLines `r++` inside loop then `r--` from for-loop: let's verify. Loop `for (r = ROWS-1; r>=0; r--)`. When full rows, splice(r,1), unshift(null). Then r++ so that the for's r-- makes it same r again → recheck. That's correct.

Wait, but there's an issue: when multiple rows cleared, after splice the rows above shift down by one. The row index r now holds what was row r-1's content. Rechecking r is correct.

Let me fix the current null-guard in key handlers.

Also check: `isValid` with negative y — cells with y<0 skipped in occupancy check, but rotation of I piece at spawn with empty top rows means cells start at row 1... Actually for I piece spawn at x=3 (size 4, floor((10-4)/2)=3), y=0, rotation 0 gives cells at row 1 → y=1. Fine.

The O piece: spawnX = 4 but I compute x = floor((10-2)/2) = 4. Good.

Now let me also double check: `spawnPiece` uses `x = Math.floor((COLS - size)/2)` for all pieces. For 3-wide: (10-3)/2 = 3.5 → 3. Good. For I: 3. Good. For O: 4. Good.

Let me fix the null guard and test.

The board is rendering. The current piece "I" is spawning at the top. Good. Next preview shows Z piece (S/Z-like) — it's the Z piece red. Fine.

Now let's test: move, rotate, hard-drop. Let's do keyboard inputs.

First move right a few times.

Wait — the piece moved right but only slightly? Original spawn x=3 for I piece (cells at columns 3-6). Now the image shows the piece at around columns 4-7? Hard to tell precisely, but seems shifted. Actually looking at the grid: the left board edge... the piece starts a bit further right. Good enough — it moved.

Now rotate.

The I piece rotated to vertical. Rotation works.

Now hard-drop with Space.

Wait — the piece locked... but it seems the I piece did NOT drop to the bottom? It's locked at around row 14-17, i.e. above the ghost. Hmm, let me look carefully. Actually, there's a new Z piece at the top and the I piece locked. But it looks like the I piece is locked mid-air with the ghost below. Hmm, actually the vertical I piece in cyan fills rows ~14-17, and below it there are outlined cells (ghost of Z piece). The Z piece is at top.

Wait, but the vertical I piece was at x=4 originally + moved right to 5. Then rotated. Then hard drop should fall to bottom rows 16-19. Rows 14-17... the board is 20 rows. Row indices: canvas 600px / 30 = 20 rows. The bottom of board at y=600. The cyan piece spans from y≈420 to 570 → rows 14 to 19. Yes! That's 6 cells ending at row 19 (bottom). Correct — locked at the bottom.

And the ghost below is the Z piece's ghost. Great.

Score 14 = hard drop distance (7 cells * 2 = 14). Correct.

Also next advanced from Z (was shown as preview) to L piece. Piece name shows Z.

Now test pause/resume.

Pause overlay works. Now resume and then restart. Let me resume via clicking the Resume button to test that too. The pause button is around x≈? The right panel. Pause button in the DOM: buttons "Resume" at roughly... The panel is at x ~ 800-1050 in a 1200x800 viewport. Let's click on the Resume button text. From screenshot, right panel Actions panel spans about x=830 to 1030, Resume button top around y=630, height ~35. Let me click (930, 630).

Actually the screenshot is 1200x800? The layout matches. Let's estimate: board right edge at ~855, right panel from 880 to 1050. Resume button center ~ x=965, y=630.

Let me click.

The click didn't land on the Resume button (still paused). Let me just press P to resume.

Restart worked: board appears empty (only ghost outlines of the new Z piece at bottom), score 0, lines 0, level 1, next advanced to T.

Wait — the ghost at the bottom is drawn in white/dim color. That's a bit odd visually (ghost squares at bottom of empty board look like faint markers). That's normal for ghost previews though. Maybe reduce opacity so it's less prominent. It's fine.

Now let me test line clearing and scoring. Let me test a quick implementation check of the row clear by using JS evaluation. I can't run JS directly via browser tool... but I can add a temporary test. Actually let me test via a headless approach: use node to extract the JS and test logic? The code is embedded in HTML. I could run a quick node check of clearLines logic by extracting the script.

Actually simpler: verify by playing. But that takes many drops. Alternative: I can inject a test using the browser — but the browser tool doesn't offer eval. Hmm.

Let me instead do a quick logic verification in node by extracting the IIFE and stubbing DOM... that's complex. Simpler: re-implement clearLines check quickly in node to confirm splice/unshift logic. Actually the logic is straightforward and standard.

But it'd be good to actually verify row clearing in-browser. Let me think of a way: I could temporarily add a debug function exposed on window and trigger it via... no eval available.

Option: use bash + node to run a DOM-stubbed test. I can install jsdom? No network. Let me check if node is available and whether jsdom exists.

Actually, a simpler robust approach: extract the script content, replace DOM-dependent parts with stubs, and run in node. That's a lot of work but the game logic functions are inside the closure, not exported.

Alternative: I can make a test copy of the HTML where I append a test script that reaches into... still closure-private.

Best pragmatic approach: temporarily modify index.html to expose a `__test` hook on window, run the browser, and... but I still can't execute JS in the browser. I only have click/key/type/screenshot/scroll/motion/drag.

Hmm. But I could use `type` to type into an input if the page had one. The keydown handler intercepts. Actually — I could add a hidden text input, and have a key handler that runs debug commands based on typed text. That's adding test code. It's feasible: temporarily add an input, sync board to state. But time budget.

Alternative pragmatic approach: verify line clear logic in pure node by copying just the algorithm (clearLines + awardScore + level) — a faithful re-implementation check. That validates my reasoning about the algorithm but not the actual file.

Actually, I can do a real end-to-end test in node by loading the HTML in a minimal DOM stub. Let me check if jsdom is available in the environment.

No jsdom. Let me write a small DOM stub in node to run the actual script from index.html, and drive it with synthetic keyboard events to test: move/rotate/hard-drop, line clearing, scoring, game over.

I need to stub:
- document.getElementById -> elements with textContent, innerHTML, classList, addEventListener, getContext
- canvas getContext returning a stub 2d context
- document.addEventListener
- window/performance/requestAnimationFrame/cancelAnimationFrame

Then dispatch key events via the captured keydown handler. Also, drive the gravity loop manually by calling the captured RAF callbacks with controlled times.

That's doable. Let's extract the script from index.html and run it.

Plan for the test harness:
1. Read index.html, extract between <script> and </script>.
2. Create global sandbox: global.document, window, performance, requestAnimationFrame, cancelAnimationFrame.
3. Run via `new Function` in a context where document etc. are globals.
4. Capture keydown handler; simulate keys.
5. Drive frames: call the stored raf callback with increasing times to apply gravity.
6. To test line clearing deterministically, I'll set pieces... but board is closure-private. Hmm. I can test by controlling Math.random to force piece order, then place pieces to clear a line.

That's a lot of moves. Alternative: test scoring by simulating many random games? Not deterministic.

Better: I can seed Math.random with a fixed value and drive a "play" strategy: for a deterministic test of line clearing, I can force pieces to fill the bottom row. E.g., use only pieces that place cells in specific columns and hard-drop them. But each piece's shape varies.

Simpler line-clear test: fill the bottom 4 columns with O pieces and I pieces, and check lines==1 & score 100. With control of piece order (Math.random fixed), the sequence is deterministic. Let's do: Math.random always returns 0.999 → the bag shuffle produced... unpredictable but fixed. Once I know the order, I can plan moves.

Let me just first get the harness running and log the piece sequence, then plan the fills.

Let me write the harness.

All works: move/rotate/drop, pause overlay, resume, restart resets score/lines/level to 0/0/1.

Score 36 for drop#1: piece moved right 1, hard drop of O piece from y=0 to y=18 → distance 18 * 2 = 36. Correct.

Now I need to verify line clearing and scoring/leveling. Board is private. Let me add a way to inspect the board. I can't easily... but I can infer from behavior: place pieces to fill a row.

Strategy: I'll add a `window.__test = {...}` debug hook to index.html. But `window` isn't defined in my sandbox; I'll add it. Alternatively, I can decide to instrument the game itself with a small exported hook — but I'd rather not ship test code... Actually a tiny debug hook is harmless, but cleaner to remove afterwards.

Alternative approach without modifying the game: reason about piece order + geometry. With seeded Math.random in the sandbox, sequence is deterministic. But move positions are controlled by me, so I can plan: e.g., fill bottom row left to right.

Actually, a cleverer approach: I can test line-clearing by a "perfect clear"-ish fill. But planning requires knowing piece order. I can determine piece order empirically by reading pieceName after each hard-drop. Then re-run with the same seed... The Math.random sequence is identical each run since seed fixed → order fixed. So: run once, log the piece sequence, then plan moves and re-run.

Let me first log piece sequence with recent seed. But bag randomization happens twice (initial spawn draws next, then resetGame calls nextFromBag for next). Let's seed Math.random = () => 0.3 for reproducibility and log the sequence.

Let me write a probe script that seeds and prints the order of the first ~12 pieces by hard-dropping repeatedly at spawn position.

Then plan: bottom row fill. Pieces and how they occupy the bottom row at spawn x (no move):
- I (rot 0): cells at row 1 (bottom row is row 19 after drop): occupies columns 3,4,5,6.
- O: occupies columns 4,5 (bottom two rows).
- T: bottom row of matrix is empty at rot0 → occupies cols 3,4,5 at row1; bottom-most occupied row is row 18... wait matrix rows: [0,1,0],[1,1,1],[0,0,0] — the bottom-most non-empty row is row index 1 (y+1). So cells at rows 0 and 1. Bottom row filled = row 19 gets only the [1,1,1] row? No: cells are at y+0 (row 18 for the top [0,1,0]) and y+1 → row 19 for [1,1,1]. So T occupies 3 cells in bottom row: x+0..x+2 where x=spawn → 3,4,5. Good.
- S: [0,1,1],[1,1,0],[0,0,0] → bottom row cells at x+0,x+1 → cols 3,4. And row above: x+1,x+2.
- Z: [1,1,0],[0,1,1] → bottom row cols 4,5.
- J: [1,0,0],[1,1,1],[0,0,0] → bottom row cols 3,4,5.
- L: [0,0,1],[1,1,1] → bottom row cols 3,4,5.

So bottom row (10 cols) can be filled by pieces occupying 3,4,5 etc. This is complex because each piece also leaves cells above that interfere. To clear the bottom row cleanly, I'd need to fill the bottom row and also handle rows above.

A simpler test: verify line clearing using a targeted construction. E.g., place O pieces to fill columns 4,5 in both rows 18,19, and J/L/T/I to fill the rest. Rows above will contain pieces too, but that's fine — I just need one complete row to check the clear and scoring.

Plan: Fill bottom row cols 0-9. Use pieces with bottom-row footprint:
- I rotated? Simpler: use pieces at spawn and shift.

But cells above will accumulate and block. To clear the bottom row we need bottom row fully filled. Pieces stacked above the bottom row don't matter (they don't prevent the bottom row from filling) as long as they don't occupy bottom row cells of the wrong columns.

So: I need to exactly cover the bottom row's 10 cells using each piece's bottom-row footprint, and ensure upper cells don't fall into the bottom row (they land one row above bottom = row 18, which is fine, as long as row 18 doesn't get fully filled — unlikely).

Bottom row footprints available: 
- O: cols x, x+1 (2 cells) at bottom.
- T: x, x+1, x+2 (3 cells) [x=spawn col]
- J: 3 cells
- L: 3 cells
- I: 4 cells (rot0)
- S: 2 cells
- Z: 2 cells

Need sum = 10 with exact column coverage and no overlaps. Hard drops stack on bottom row.

E.g., use T at x=3 → covers 3,4,5; then J at x=6 → covers 6,7,8; then need 0,1,2 and 9. I at x=-? can't go left beyond 0 with x=0 → covers 0,1,2,3 → overlap. Hmm.

Alternative: don't require full clearing of the bottom row. Instead, target a higher row? Harder.

Different approach: For verification of clear/score/level, maybe simplest is to expose a debug hook temporarily, verify, then remove it before finalizing. That's clean and reliable. Let me do that: add `window.__TETRIS_TEST__ = { get board(){ return board; }, spawnType(t){...} }`... But spawnType is not a hook; I'd need to modify spawnPiece. I could add a hook that lets the next piece type be forced.

Actually I can do it without modifying game functions: expose board + a way to set `nextType` (it's a closure variable — I can reference it in a hook since the hook runs in the same scope... no, the hook must be defined inside the IIFE).

Minimal patch inside the IIFE: after boot code, add:
```
window.__tetrisDebug = {
  get board(){return board;}, get score(){return score;}, get lines(){return lines;}, get level(){return level;},
  get next(){return nextType;}, set next(v){nextType = v;}
};
```
That's a few lines, and I can remove it after verification. Let me do that, verify, then remove.

Actually — I could keep it? No, better to remove for cleanliness. But the removal requires re-running the test after removal. I can keep a copy of the file.

Let's do it.

My test A plan was flawed because pieces land on top of each other (the bottom row was never completed — the pieces stack up since each piece's footprint doesn't tile the bottom row cleanly; e.g., O at x=0 occupies rows 18-19 cols 0,1; T at x=2 bottom row cols 2,3,4 — but wait the board shows rows 15,17 = ### and 13 = ###, 12 = # — T pieces stack in cols 2-4 repeatedly).

Hmm, my movePieceToX tracking is wrong: `currentPieceCols` reads top rows of the board for the *current falling piece* — but it also reads from previous locked pieces? No, it scans rows 0-3 which are empty except the falling piece. But after a piece is dropped and a new spawned, the previous locked piece occupies rows 15-19 — not rows 0-3. OK so it should work... but note the new piece spawns at top rows 0-3 mostly for rotation 0 (T has cells at rows 0,1). And I piece rot 0 at rows 0,1.

But issue: multiple pieces landed in the same columns, suggesting my movePieceToX moved incorrectly. Board A: O at col 0 (rows 18,19 cols 0,1) ✓. Then T: landed cols 1,2,3? Rows 15 and 17 = "###" at cols 0,1,2 and 16 = "##". Hmm row 17: ##... wait the board shows:
```
16|##........
17|##........
18|##........
19|.##.......
```
That's O (rows 18,19 = cols 0,1 and 2? row 19 is `.##` = cols 1,2; row 16-18 = cols 0,1).

Hmm, O rotated? No, O spans rows 18-19 cols 0-1 in a 2x2. But the board shows the O occupying rows 16,17,18,19? That's 4 rows — so the O piece got rotated?? No — O rotates to itself. 

Wait: `T.next = type` sets nextType. But the *current* piece at the time of setting is the one being moved. Order of operations: `T.next = "O"` sets the upcoming piece; the current piece is whatever spawned earlier. On `key("r")` reset, spawnPiece is called during resetGame which draws next from bag. So after 'r', current = first bag piece, next = second. Setting T.next = "O" makes the piece *after* the current one O. So my plan is off by one!

Right. In Test A the first piece was whatever bag gave. That's why things landed in unexpected spots.

Fix: after `key("r")`, set T.next = plan[0] and drop? No — the current piece at reset is the bag's first. So do: key("r"), then T.next = plan[0][0], drop(1) → that drops the *bag* piece, not plan[0]. To control the very first piece, I need to set next before the reset's spawn... 

Alternative: after key("r"), the current piece is P0; set T.next = plan[0], drop P0 (uncontrolled), then set T.next = plan[1]... same off-by-one. 

Better: after key("r"), immediately set T.next = plan[0] and then drop the current piece P0 first, ignoring its position... no, P0 lands somewhere random.

Cleanest: do `key("r")` twice? No.

Actually simplest: after key("r"), the current piece P0 is at the top; I can hard-drop it somewhere harmless (e.g., far left). Then for each planned piece: T.next = type; movePieceToX(x); drop. Because after P0 drops, the next spawned = T.next which is my type. Let me restructure: first drop the reset's P0 (position anywhere), then loop over plan setting next before each drop.

Wait, careful: after dropping P0, spawnPiece() uses nextType (which I set to plan[0]) — but I must set T.next = plan[0] BEFORE dropping P0. So:

key("r");
T.next = plan[0][0];
drop(P0)  // uncontrolled, lands somewhere
for i in 0..: T.next = plan[i+1]; move plan[i] to x; drop.

So the sequence: set next=P0 then drop P0; then for i>=0 set next=plan[i+1], move plan[i]... no wait plan[0] already spawned as the current piece after P0 dropped. Let me re-derive:

- After key("r"): current = Q (bag piece), next = B1.
- Set T.next = plan0 → next = plan0.
- Hard drop Q (uncontrolled position).
- spawnPiece: current = plan0, next = bag.
- Set T.next = plan1, move plan0 to x, drop.
- spawnPiece: current = plan1, next = bag. Set T.next = plan2, move plan1, drop. etc.

So the last plan entry needs no next-setting issue: set T.next = plan[i+1] before dropping plan[i], and the final plan entry drops with next = bag (harmless).

Also, Q will land somewhere random which may interfere. To minimize, I can rotate Q and move it to the far right or left... but uncontrolled position could stack. Its footprint: e.g., if Q is T at x=3, it lands in cols 3-5 bottom. My plan fills cols 0-9 in bottom row, so Q's cells would be within those columns at rows 18/19 and would break the plan.

Hmm. Alternative: make the plan account for Q? Complicated since Q is random (but deterministic with Math.random unseeded... actually Math.random is real random in node sandbox — no, `Math` is the default from vm context → real random). So Q varies per run.

Better approach: make the test deterministic by seeding Math.random in the sandbox: `sandbox.Math = ...`? I can override: sandbox.Math = Object.assign(Object.create(Math), {random: () => 0.42})? Actually vm context Math is a realm-specific object; simpler: since `refillBag` uses Math.floor(Math.random()), I can construct a seeded Math. Let me instead seed by defining `sandbox.Math` = a proxy... The realm's Math object is global in that context; I could run `vm.runInContext("Math.random = () => 0.42", sandbox)` to patch it. That works — patch the realm's Math.random.

With random=0.42 fixed, the bag order is deterministic. Then I can log the piece order and plan accordingly.

Actually, even simpler and fully robust: rather than fighting randomness, I can compute what happens: for each drop, I know the piece type; I just need to place them. To handle Q: I can just make Q's placement part of the plan by learning Q's type at runtime (read pieceName) and adapting. But simpler: skip Q by hard-dropping it, then clear it? No.

Cleanest: I'll write the test to dynamically build the plan: at each step, read the current piece type and choose the target column based on a "fill bottom row" algorithm: greedily choose position such that the bottom-row cells land on the first empty columns from the left. That's a small planner and handles all cases including Q.

Let me implement a planner:
- For the current piece type and rotation, compute the set of (row-offset, col-offset) cells.
- Hard-drop at x: the piece's bottom-most occupied row lands at row 19 (bottom). The cells' board rows = 19 - (maxRowOff - rowOff).
- So for a candidate x, compute which bottom-row cells it occupies (rowOff === maxRowOff → board row 19).
- Choose x such that all its bottom-row cells are empty in row 19 (and it's a legal drop), preferring to fill the leftmost empty cells.
- Continue until row 19 is full → expect a line clear.

But also need rows above to not be fully filled accidentally — that's fine, we only care about a clear happening; even if 2 rows clear it's still valid behavior to verify (score table: 200 or 300*level).

Let's verify:
- Score for a 1-row clear = 100*1 = 100 (plus hard-drop distance points).
- Level increments per 10 lines.

I'll also test 2-row and 4-row clears with tailored plans:
- 4-row: 10 vertical I's in columns 0..9 → each vertical I fills 4 rows in one column → rows 16-19 fully filled → 4-line clear, 800 points.
  For vertical I: rotate once (ArrowUp) → column of 4. Place at column c. Its bottom-most cell lands at row 19, filling rows 16-19 at that column. Perfect: 10 vertical I's at cols 0..9 fills rows 16-19 completely → clear 4 rows = 800*level.
  But the planner must handle rotations. I'll write a bespoke test for that: for each of 10 columns, set next='I', press ArrowUp (to vertical), move to col c, hard drop. Need bag to give 10 I's in a row — set T.next='I' before each drop. Works: after each drop, spawnPiece uses nextType='I'. So 10 I's in a row. 

- 2-row clear: 5 O's? O is 2x2 → 2 O's per column fill 4 rows... For a 2-row clear: fill rows 18,19 completely with O pieces: each O covers 2 cols × 2 rows → 5 O's at cols 0,2,4,6,8 → rows 18,19 full → 2-row clear = 300*level. 

- Level test: 4-line clear twice = 8 lines, then need 2 more lines. Or do 4-row clear three times = 12 lines → level 2 after 10 lines. Let's do: 3× 4-line clears = 12 lines → level should become 2 at 10 lines. Score should include 800*1 for first two clears and 800*2 for the third (after level up at 10 lines, the third clear happens at level 2)... Level increments at 10 lines: clears 1,2 at level 1 (lines 0→4→8), third clear is at level 1 still (lines 8→12 → level becomes 2 during that clear; awardScore computes with `level` before updating → 800*1 = 800, then level becomes 2). So total lines score = 2400, plus drop points.

Let me now write the planner test. Also verify: rows above shift down after a clear (check board contents after clear), and next-piece preview advances.

Let me write test_deep2.js.

My moveToCol isn't working — after the first drop, subsequent pieces don't move (they stay at col 3). The bug is in my test's `moveToCol`: it scans rows 0..(low+1) for cells and computes minC — but wait, in Test A after the first drop the second piece stayed at column 3 (footprint 3,4,5 = default pos for L). My `moveToCol` loop breaks out because... Let's see: `cells = spawnCols(curType())`, low = lowestRow. For L, low = 1, so scan rows 0..1 for board cells. minC = 3. target = 3 → return immediately? For the second piece target was 3? Let me re-check: it printed "drop L at col 3 footprint 3,4,5" — the chosen x. Hmm, the planner chose col 3 for L since footprint 3,4,5 all empty in row 19 at that time... wait the first drop was T at col 1 (footprint 1,2,3). Then empty = [0? no, 0 is... row19 = ###.....## meaning cols 0? Let me look: bottom row at end "###.....##" = cols 0,1,2,8,9 filled. Hmm.

Actually the planner picked the FIRST x where all footprint cells are empty, but that doesn't guarantee contiguous left-filling coverage — e.g., for L with footprint 3 cells, x=0 gives cols 0,1,2 — at that point cols 0,1 were empty (T filled 1,2,3 → row19 = "###......."?). Wait the first drop was T at col 1 → footprint 1,2,3. So row 19 = cols 1,2,3. The planner for L: x=0 → cols 0,1,2; col 1 is occupied → skip. x=1 → 1,2,3 occupied → skip... x=3 → 3,4,5; col 3 occupied → skip. x=4 → 4,5,6 empty → chosen? But it printed col 3!

So moveToCol didn't move the piece — maybe minC detection failed. Hmm, after the first drop, the current piece is L spawned at rows 0,1 cols 3,4,5. Scanning rows 0..1: cells at cols 3 (row0), 3,4,5 (row1). minC = 3. Target 4 → key ArrowRight. Then next iteration: scan rows 0..1 → cells now at cols 4,5,6 → minC = 4 → equals target → return. That should work.

Unless... `curType()` returns pieceName, and `moveToCol` uses `lowestRow(cells)` with `r < lowestRow+1`. For T (low=1), scan rows 0..1. But for a piece after rotation... fine.

Hmm wait, Test A output shows all drops at col 3 except the first (col 1) and Z (col 2). That looks like moveToCol failed for all: because in later steps, the bottom rows accumulate (row18, row17...), and the scan of rows 0..1 for the current piece... The current falling piece is at rows 0-1 at spawn. But `moveToCol` is called BEFORE any gravity, so the piece is at rows 0..1. Should be fine.

Oh wait! The issue: after the first T drop, the next piece spawns — but the *previous* locked T may occupy rows... no, it's at the bottom.

Hmm, but there's a subtlety: `moveToCol` scans ALL cells in rows 0..low+1 — if a previous piece's cells happen to be in those rows (when the stack is tall), minC could be wrong. But early on the stack is low.

Let me debug: maybe the issue is that key(" ") hard-drop happened before moves were complete, or that my `chosen` computation printed wrong. Let me add debugging of the piece's actual cells before dropping.

Actually — I bet the issue is this: in `moveToCol`, `cells = spawnCols(curType())`, and `lowestRow(cells)` for I at rot 0 is 1. Then the scan condition `r < lowestRow(cells) + 1` = r < 2 → rows 0,1. OK.

Hmm, but wait — `emptyBottomCells()` returns T.board[19] empty cols... and the planner picks `chosen` as the first x where footprint ⊆ empty. But after the first T drop at col 1, row19 = cols 1,2,3. For L: x=0 → 0,1,2 → col 1 occupied → no. x=1 → occupied. x=2 → 2,3,4 → 2 occupied. x=3 → 3,4,5 → 3 occupied. x=4 → 4,5,6 → free → chosen=4. Printed 3. So moveToCol moved to 4? No, printed 3.

Unless the printed `chosen` is the chosen value and the piece didn't move... it printed both `chosen` and footprint computed from realType at chosen. So the piece was at col 3 = didn't move.

Let me debug moveToCol in isolation. Maybe the key handler doesn't do anything because `running && !paused && current` — true.

OH WAIT. I see it. In `moveToCol` I call `key(...)` — fine. But the loop: `for (let i = 0; i < 14; i++) { ... if (minC === targetX) return; key(...) }`. For L: target 4, minC 3 → ArrowRight → i=1: scan → minC should now be 4 → return. Unless the scan finds cells in rows 0..1 that include a *locked* piece from the previous drop — for T's first drop, its cells are: T bottom-row cells at rows 18,19... no.

Hmm, let me just debug directly.

Also Test B: after key("r"), 5 O's placed at cols 0,2,4,6,8 — but row19 shows "###......." meaning only cols 0,1,2 filled and row18 ".#" → so pieces stacked: O at 0 (rows 18-19 cols 0,1), then next O's landed on top at col 2. So moveToCol definitely failed for x=2.

And in the earlier Test A the first move DID work (T at col 1). So moveToCol works when the piece is the first spawned after reset? Hmm no — T at col 1 was also moved left 2.

Wait, actually in Test A the first drop printed "T at col 1" and row19 at the end was "###.....##" — cols 0,1,2 and 8,9. Confusing: many pieces dropped but bottom row mostly empty, they stack in the middle. So the pieces are stacking vertically at the left/middle.

So it looks like only the first moveToCol worked and the rest didn't. Why? Because after the first drop, `moveToCol`'s scan `for r < lowestRow(cells)+1` — for L the current piece occupies rows 0-1... unless gravity is running! The loop `rafCb` is called only from `frames()`, which I removed in this test. So no gravity. Fine.

Hmm, but there's another possibility: `curType()` — pieceName is updated in spawnPiece. Fine.

Let me actually debug it. Maybe `key("ArrowLeft")` — for the second piece the target was LESS than minC... in Test B the second O target was x=2 > spawn 4? No, O spawns at col 4, target 2 → move LEFT twice. So it should move left. But row19 shows cols 0,1 filled by the first O and the rest stacked at col 2 — meaning the second O moved left only partially? O at col 2 in the final board: row18 ".#" and rows above? The final boardB row19 = "###......." → cols 0,1,2; row18 = ".#........" → col 1. Hmm that's just records for the last piece dropped (O at col 2 → rows 18,19 cols 2,3? no, ".#" = col1).

I'm confusing myself. Let me write a focused debug test.

Actually, I suspect the bug: `moveToCol` scans rows 0..low+1 — for O, `spawnCols("O")` = [[0,0],[1,0],[0,1],[1,1]] → low = 1 → scan rows 0,1 → minC = 4 → move left twice to 2 → OK.

Unless the loop exits after 14 iterations without reaching... it doesn't check.

Let me just debug.

The piece isn't visible in the board at all! `T.board(r)` for r<6 is empty. That means the current piece is drawn separately (not in board) — of course! The board only holds locked pieces. My earlier tests assumed the falling piece appears in `board`, which is wrong. The falling piece is `current` (not exposed).

In the first test_harness run, Test A's first drop "worked" by luck? No — moveToCol found minC from... `spawnCols` + scan found nothing → minC = 99 → moves right 14 times → piece pinned at the right wall. That explains everything: pieces stacked at the right.

I need to expose `current` in the debug hook. Let me add current type/rotation/x/y to the hook.

Also `frames` in Test F was undefined — need to define. And I should verify gravity separately via the hook's current y.

Let me update the debug hook to include current.

Good progress! Several observations:

1. Test A: my planner got stuck because pieces leave cells above the bottom row that block. That's expected planner limitation, not a game bug. Need a better plan. Test C worked and showed clears.

2. Test C: interesting - lines went 2 per round instead of 4! And score increments: round0 +618, round1 +896, round2 +896. Hmm. After round 0: lines=2. That means only 2 rows cleared per round of 10 vertical I's. Why? Because vertical I pieces placed adjacent to each other: the first vertical I fills rows 16-19 in col 0; the second at col 1 → rows 16-19; ... but rows 18,19 fill in first, then rows 17 fills, then 16. When rows 19 and 18 fill completely, they clear (2 lines). Then the remaining I's continue filling cols in rows 16,17... Actually after rows 18-19 clear, everything shifts down, and the I's still in flight land lower.

So the result: 2 lines per round → makes sense mid-clear. Level increased to 2 at 10 lines ✓. Score: 2-line clears = 300 each: round0: 300 + drop points ~318... it's 618 for round 0 — that's 300 (lines) + ~318 drop points? 10 I's × ~19 rows drop = 380 distance points... Hmm 618 - 300 = 318. OK.
Round 1: 896 - 618 = 278?? Wait, round1 shows lines=6, score=1514. 1514-618 = 896 = 300 (2-line clear) + 596 drop points? That doesn't match round0's 318.

Hmm, this inconsistency is suspicious. Let me think: maybe some rounds cleared 2 rows twice (two separate clears within the round) = 2 × 300 = 600 + drop points. In round 1, the vertical I's may have triggered two separate 2-row clears (600) + 296 drop = 896. Plausible: after pieces stack, two row-completions could happen at different times.

The important checks: 1/2/3/4-row scoring = 100/300/500/800 × level and level at 10 lines. I should test 1-row, 3-row, 4-row clears cleanly.

Let me design a clean single-row clear test:
Bottom row 19 needs 10 cells. Use pieces whose bottom footprint leaves cells only in row 19 and which can tile row 19 exactly:
- O: 2 cells (cols x, x+1) + row above at same cols.
- I: 4 cells in row 19.
- T/J/L: 3 cells.

To fill row 19 with 10 cells exactly, I could use I (4) + I (4) + O (2)? Two I's at x=0 (0-3) and x=4 (4-7), O at x=8 (8,9). Total = 10. That's 3 pieces! And their other cells are in rows 17-18 but that's fine — row 18 would then have cells but not full (I at 0-3 and 4-7 in row 18? For I rot 0, cells are at rows y+1 only (the [1,1,1,1] row) — wait no: I's matrix rot0 = [[0,0,0,0],[1,1,1,1],[0,0,0,0],[0,0,0,0]] → cells at row y+1 only. So a horizontal I hard-dropped puts all 4 cells in row 19! Its footprint = 4 cells in row 19, rows 18 nothing.

So: 3 pieces: I at x=0 (cols 0-3), I at x=4 (cols 4-7), O at x=8 (cols 8,9). Row 19 full → 1 line clear. But the O also occupies row 18 cols 8,9 — fine, row 18 not full.

For a 3-row clear: I need rows 17,18,19 all full. Use vertical I's? A vertical I (rot 1) at col c fills rows 16-19 (4 cells) → gives a 4-row clear when complete → a "quad". So for a triple, I need 30 cells covering rows 17-19 exactly with nothing in row 16 partially... Actually rows 17,18,19 full = 30 cells. If I use 3 horizontal I's stacked in the same column range (e.g., x=0..3) three times → rows 19, 18, 17 filled in cols 0-3. Then 3 horizontal I's at x=4..7 → rows 17,18,19 cols 4-7. Then 2 horizontal I's? cols 8,9 remain: use 2 O's → rows 17-19? An O fills 2 cols × 2 rows (rows 18,19) at x=8 → cols 8,9 rows 18,19. Then for row 17 cols 8,9 need 2 more cells: an O at x=8 stacked on top → rows 16,17. So: 2 O's at x=8 → rows 16,17,18,19 at cols 8,9. That means row 16 has cols 8,9 filled. Rows 17,18,19 complete → 3-line clear, and row 16 will keep cols 8,9 (plus leftovers shifted down).

Total: 3 I (x=0) + 3 I (x=4) + 2 O (x=8) = 8 pieces → clears rows 17,18,19 = 3 lines = 500 points.

Order matters: pieces fall to the lowest available spot, so I should fill bottom-up: first drop I at x=0 (row 19), then I at x=0 (row 18), then I at x=0 (row 17). Then x=4 three times, then O at x=8 twice (bottom first).

For quad: 10 vertical I's fills rows 16-19 in 10 columns... but careful: as rows complete during the process, they clear early and the remaining pieces shift down. From Test C, the fills completed in stages (2 rows at a time) → 2-line clears. To get a clean 4-line clear, the 4th row must complete in the same drop as the first 3... which is impossible with vertical I's? Let's see: with 10 vertical I's, the pieces stack per column: col c gets I's until full... Actually a vertical I in col c occupies rows 16,17,18,19 in one shot when nothing below. Dropping 10 vertical I's at cols 0..9 → rows 16..19 ALL filled simultaneously → 4 lines cleared at once! Wait, but in Test C each round cleared only 2 lines. Let me check: `T.next = "I"; key("ArrowUp"); moveToX(c, 1); key(" ")`.

Hmm, `key("ArrowUp")` rotates T.next... no! It rotates the CURRENT piece (which is I since we set next to I in the previous iteration and it spawned). But the first time, the current piece after key("r") is the bag's piece (with Math.random=0.42, fixed). So the first piece is uncontrolled. Also `moveToX(c, 1)` uses cur() bounding-left — for a vertical I, the matrix rot1 = [[0,0,1,0],[0,0,1,0],[0,0,1,0],[0,0,1,0]] → bounding left = col + 2. So moveToX(c) targets min col = c, meaning the piece's left bbox is at c → the actual filled column is c+2. Off by 2. So the 10 I's filled columns 2..11 → some fell outside → invalid placement → they didn't drop in the intended column. That explains the 2-line clears.

So I should use a column-aware helper: compute target x so that the desired *filled* column is c: x = c - 2 for rot 1.

Let me write the final targeted tests with a generic "place current piece such that its cells land on a given set of board cells" — actually simpler: define a helper `placeCells(type, desiredBoardCells)` that computes x,y offset such that the piece's bottom row lands on row 19 and its column offset aligns to the desired leftmost filled column.

Let me write a helper: `hardDropAligned(piece, alignCol)`:
- cells0 = cells(type, rot, 0, 0) (relative)
- minRelCol = min over cells of c
- x = alignCol - minRelCol
- then move via keyboard until min board col == x.

That's what moveToX does but with the rotation applied first (so cells at rot). So: rotate first (key ArrowUp × rot), then moveToX(alignCol - minRelCol(rot)) — equivalently, rotate first, then compute current minRelCol from cur() (x=cur().x) and move so that cur().x == alignCol - minRelCol.

Let me restructure: `align(type, rot, alignCol)`:
  1. set T.next = type (before dropping previous)
  2. rotate: key("ArrowUp") × rot
  3. compute minRel = min c of M[type][rot]
  4. targetX = alignCol - minRel
  5. move current so cur().x === targetX (via keyboard using current cells min col)

Then key(" ").

Let me redo the tests A (1,2,3,4-line scoring) cleanly and verify expected scores exactly.

Also verify Test D shift-down: In Test D output, after the clear, row 19 showed "#.########" — meaning no clear happened (row19 not full, since col 8,9 from I? Let me not worry; I'll redo.

Also Test F: gravity moved only 1 row in 1000ms — level 1 gravity = 800ms, so in 1000ms it should move 1 row (800ms) and then the piece rests → correct.

Test G: pause froze gravity ✓ (y unchanged), resumed ✓.

Test H: rotation at walls stayed legal ✓.

Test E: game over works ✓.

Now let me write the clean scoring test.

Expected scores:
- 1 line: 100*1 = 100 + drop points
- 2 lines: 300
- 3 lines: 500
- 4 lines: 800

Let me verify each exactly by subtracting the drop distance points, or better: compute expected total: I'll capture score before the final drop of each sequence and compare with the previous + expected.

Simplest: score the line-clear portion by measuring the delta at the moment of the clear: delta = 100/300/500/800 + 2*distance... since hard drop distance varies, I'll just check that delta - 2*dist == table value. I can compute dist as 19 - y_before (approx, y is the pre-drop y). Let's record y before drop: dist = (19 - maxRowLow... ) Actually distance = final y - initial y. I'll capture cur().y before the drop and after? After the drop, the piece is locked and current is the new piece. Instead compute dist = (19 - y0) where y0 = the piece's y before drop, assuming it lands with its bottom at row 19. dist = 19 - (y0 + maxRowRel)... let me just compute cells' final positions: after drop, the locked cells are at rows (19 - lowRel + rel). dist = 19 - (y0 + lowRel)... simpler: dist = (y0 + lowRel + ... ) hmm.

Let's do: lowRel = max rel row. Before drop, piece's lowest occupied row = y0 + lowRel. After drop it's 19. dist = 19 - (y0 + lowRel).

Fine. Then expected delta = table*level + 2*dist.

Let me write it.

As expected, the first piece after key("r") is the bag piece (T). I need to consume it first. Let me add: after key("r"), drop the uncontrolled current piece somewhere harmless (it will land at cols 3-5 in rows 18-19 which interferes with my plan). Better: force the sequence by setting `T.next` BEFORE the reset's spawn... can't.

Option: do key("r") then immediately place the bag piece out of the way? It will land in the middle. Alternatively, rotate it to vertical and place at col 9 (out of the way, but my plans use col 9 for some).

Cleanest: for each test, first do key("r"), then drop the initial bag piece (uncontrolled) — but note its landing spot is deterministic given Math.random=0.42: the first piece is always the same type. Let me find out what it is and just account for it: place it somewhere that doesn't interfere.

Actually simplest: for the first drop of each test, use the actual current type and drop it without moving — but it lands in the plan area.

Better: I can place the first piece deliberately aligned to a "sacrificial" column and just design plans around it. E.g., in the 1-row clear test, plan: drop the bag piece (whatever it is, likely T) aligned at col 6? Then I(0), I(4), O(8): row19 would need cols 0-3 (I), 4-7 (I), 8-9 (O) — col 6-7 taken by the sacrificial T? T bottom footprint at align 6 → cols 6,7,8 → conflicts.

Alternative: place the sacrificial piece VERTICALLY at col 9 (rows 16-19) — for any type? Not all pieces have a 4-tall state. Hmm.

Alternative approach: allow the sacrificial piece to be dropped at a location, then start the plan from a *fresh* reset but skip the first bag piece by setting T.next to my first plan piece and dropping the bag piece at a harmless place, then... it still occupies the bottom row.

OK, let's simply compute: what's the first bag piece with Math.random=0.42? Let me check quickly: it printed "piece: 'T'" earlier in test_harness (unseeded). Let me print it with the seed. Then I'll design the plan to include it. E.g., if it's T: T at rot 0 dropped without moving occupies row 19 cols 3,4,5 (and row 18 col 4).

For the 1-row clear plan, I could instead fill row 19 with: I at x=0 (0-3), then need cols 4-9: I at x=5 (5-8), then col 9 alone: no single piece leaves exactly 1 cell in the bottom row... T at rot1: matrix [[0,1,0],[0,1,1],[0,1,0]] → bottom row (row index 2) has cell at x+1 only → footprint 1 cell! So T rot1 at align 9 → the bottom cell at col 9+... let me compute: minRel for T rot1 = 0, cells at rel rows 0,1,2 cols: (1,0),(1,1),(2,1),(1,2). Bottom row = row 2 → cell col rel 1. So align col 9 means x = 9-0 = 9 → cells at cols 9,10? col 10 is out of board → invalid.

Hmm. T rot 3: [[0,1,0],[1,1,0],[0,1,0]] → cells (1,0),(0,1),(1,1),(1,2) → bottom row col 1. minRel = 0 → x = 9 → cells at cols 9,10 → invalid again. So I'd align to 8 → bottom cell at col 9 with other cells at 8,9,8. So T rot3 aligned 8 leaves bottom-row cell at col 9 and cells at col 8 rows 18,19. Good — but then col 8 in row 19 must be filled by another piece.

This is getting complicated. Simplest fix: make the test's first drop a "sacrificial" vertical I at col 9 — wait the first piece is the bag piece, not controllable.

Cleanest solution: modify the debug hook to allow resetting with a forced first piece. I can set `bag` and `nextType` before calling reset... but resetGame is not exposed. However, I could expose a `spawn(type)` function... I'm already modifying the file for the debug hook (temporarily), so let me expose `forceNext` that sets both nextType and also a flag to override the *current* spawn. Actually simpler: expose `reset(seq)` that runs resetGame then sets current directly.

Hmm — but I could avoid all of this: I can set `T.next` and then trigger a *spawn* without dropping, by... no.

Pragmatic approach: just handle the first bag piece: I'll find what it is, and design each test's plan to place it deliberately (using place() with its actual type). For rotation choice I can use rot such that its footprint fits in a corner. E.g., if the first piece is T, drop it at rot 1 aligned at col 8: cells (1,0),(1,1),(2,1),(1,2) with x=8 → cols 8,9 rows 18,18,19,19? Let me compute: minRel=0, x=8 → cells: (9, y0+0),(9,y0+1),(10,...) invalid. Ugh, rot1 T has a cell at rel col 2 → x=8 gives col 10 → invalid.

Use rot 0 T aligned at col 7 → cells (8,0),(7,1),(8,1),(9,1) → bottom row (rel row 1) cells at cols 7,8,9. So bottom-row footprint = 7,8,9 — 3 cells. That's actually useful! Then the rest of the bottom row (0-6) can be filled with... I at 0 (0-3), and cols 4,5,6 = 3 cells: an O (2 cells) won't fit; J bottom 3 cells → cols 4,5,6 ✓ (J rot0 bottom row = x,x+1,x+2 → align 4 → 4,5,6). But J's other cells are at row 18 col 4 — fine.

So: first bag piece = T at align 7 (if it's T), then I at align 0, J at align 4. Row 19 = cols 0-9 ✓ (T gives 7,8,9; J gives 4,5,6; I gives 0,1,2,3). → 1-line clear!

But is the first bag piece always T with seed 0.42? Let me verify and also print. Let me write the test to read the first piece type at runtime and adapt: for the 1-row test, place the first piece at rot 0 aligned so its bottom-row footprint covers the rightmost 3 cols... but that depends on its footprint size.

Generic approach for the first piece: compute its rot-0 bottom footprint (relative cols and count k). Align it so that its footprint occupies the LAST k columns... then fill the remaining left part with I's and O's/J's. Simplest generic: use the first piece to cover the rightmost columns, then fill the left remainder (10-k cells) using I's (4), O's (2), and possibly adjust.

Since I control the sequence only from the second piece onward, I'll: 
1. print the first piece type,
2. design the plan for that specific type.

Let me just check what the first piece is with seed 0.42 and hand-design all 4 tests accordingly. And to be safe against bag order changes, I'll always set T.next for all drops after the first.

Let me first print the first few bag pieces.

With Math.random = 0.42 fixed, the sequence is deterministic: T, L, J, O, S, I, Z (and then repeated from a shuffled bag). Note refillBag uses the random function so each new bag is the same shuffle → sequence repeats: T L J O S I Z T L J O S I Z...

So plan for each test: first piece = T (bag), then I set T.next for the rest. I'll write the plans:

**Test 1: single-row clear** — pieces: T(first), then I, I, O.
- T rot 0 aligned at 7 → bottom row cells 7,8,9 (cells (8,0),(7,1),(8,1),(9,1); bottom row = rel row 1 → cols 7,8,9) ✓ and row 18 col 8.
- I rot 0 aligned at 0 → row 19 cols 0,1,2,3 ✓
- I rot 0 aligned at 4 → row 19 cols 4,5,6,7 → wait, col 7 already taken by T. Need cols 4,5,6 only (3 cells) → use J rot 0 aligned at 4 → bottom row 4,5,6 ✓. J's other cells at row 18 col 4.
- Then row 19 = 0-3 (I), 4-6 (J), 7-9 (T) = full ✓ → 1 line clear, 100 points.

Order matters: T first (align 7), then I (align 0), then J (align 4). J's cells at row 18 col 4 — no conflict with row 19.

Wait: does I at align 0 land at row 19? Its only row is rel row 1 → lands at row 19 given nothing below. But careful: the piece must be able to descend; the T's cell at col 8 row 18 doesn't block I at cols 0-3. ✓

Expected: clear 1 row → +100*1 = 100 + 2*dist drops.

**Test 2: double clear** — 5 O's at cols 0,2,4,6,8 + T(first). T would interfere. Let me first drop T somewhere out of the way: T rot 0 aligned at 7 → occupies rows 18,19 at cols 7,8,9 → that conflicts with the O plan for cols 6-9.

Alternative for test 2: drop the first T VERTICALLY at the far right, e.g., T rot 1 aligned... rot1 T cells (1,0),(1,1),(2,1),(1,2) with x = align - minRel. If aligned at 8: minRel=0 → x=8 → cells: (9,0),(9,1),(10,1) invalid.

T rot 3: cells (1,0),(0,1),(1,1),(1,2), minRel=0 → x=8 → cells (9,0),(8,1),(9,1),(9,2) → cols 8,9 rows 0,1,2 → valid! It stacks vertically at cols 8-9 rows 17,18,19 → that gives me cols 8,9 in rows 17,18,19 filled (a "stub"). Then O's at 0,2,4,6 fill rows 18,19 for cols 0-7 → row 19 full (0-7 from O's + 8,9 from T stub) → 1 line clear; row 18 also full → 2 line clear! And row 17 has cols 8,9 (T stub) → not full. So total = 2 lines = 300. 

T rot 3 needs x=8: it's at y=0 → rows 0,1,2 relative; when hard-dropped, its lowest cell lands at row 19 → cells at rows 17,18,19 ✓ (3 cells in one column + 2 cells: rel rows 0,1,2 at cols 1,0,1,1 → cols: row0 col1=9, row1 cols 0,1 = 8,9, row2 col1 = 9). So col 9 filled in rows 0,1,2 → after drop: rows 17,18,19 col 9; and col 8 row 18. So row 19 cols 8,9 ✓; row 18 cols 8,9 ✓; row 17 col 9 only.

Then 4 O's at cols 0,2,4,6 → rows 18,19 cols 0-7 ✓. Total row 18 = cols 0-9 ✓, row 19 = cols 0-9 ✓ → 2-line clear = 300. 

Note the order: drop T rot3 at align 8 first, then O's.

**Test 3: triple clear** — rows 17,18,19 full = 30 cells. Use the T stub (rot3 align 8): gives col 9 rows 17,18,19 and col 8 row 18. Then:
- O at 0 (rows 18,19 cols 0,1), O at 0 again (rows 16,17 cols 0,1)... 

Let me plan precisely. Goal: rows 17,18,19 all complete.
Cells needed per row: 10 each.
Plan: 
- T rot3 @8: col9 rows 17,18,19; col8 row18.
- I@0 (rot0): row19 cols0-3
- I@4: row19 cols4-7
- row 19 done (0-7 + 8,9) ✓
- Need rows 17,18 for cols 0-7: use I@0 twice more (rows 18 and 17) → 2 more I's at align 0 → each lands directly above the previous I. Yes: after I fills row 19 cols 0-3, the next I@0 lands at row 18 cols 0-3, the next at row 17.
- Similarly I@4 ×2 more → rows 18, 17.
- Now rows 17,18 have cols 0-7 + col 9 (row17) / cols 8,9 (row18).
  Row 18: cols 0-7 (I's) + 8,9 (T) = full ✓
  Row 17: cols 0-7 (I's) + col 9 (T) → need col 8 → one O at align 8 → O lands... where? O spans 2 rows × 2 cols; below it at rows 18,19 col 8,9 is occupied → it lands at rows 16,17 cols 8,9 ✓ → fills row 17 col 8 ✓ (and row 16 cols 8,9).
  
So all three rows complete → 3-line clear = 500. Piece count: T(1) + I@0 ×3 + I@4 ×3 + O@8 ×1 = 8 pieces. 

Order: T first, then I@0, I@0, I@0 (stacking), I@4 ×3, then O@8.

Careful with the I stacking order: I@0 (row19), I@0 (row18), I@0 (row17) — each subsequent I lands on top. ✓ Similarly I@4 ×3.

**Test 4: quad clear** — rows 16-19 full. Use 10 vertical I's at cols 0..9 (rot1): each vertical I at col c fills rows 16,17,18,19 in column c. All 10 → 4 rows complete in one drop → 4-line clear = 800. Order: place vertical I at col 0 first... but wait: when a vertical I is dropped at col 0 it fills rows 16-19 of col 0. Next at col 1 → rows 16-19 col 1. ... After 10 columns, rows 16..19 fully filled at once (the last drop completes all 4 rows) → single 4-line clear ✓ = 800 points.

But the first piece is T (bag) — need to place it out of the way. With 10 vertical I's, the T would block a column. Place T rot3 @8 → occupies col 9 rows 17,18,19 + col 8 row 18. That leaves only 9 columns for vertical I's → rows can't all complete.

Alternative: place T stacked ABOVE row 16 so it doesn't affect rows 16-19. Can a piece be placed above row 16? Only with support below. Hmm.

Alternative: for the quad, use the T stub as part of the plan: rows 16-19 need 40 cells. Vertical I at cols 0..7 = 8 I's → 32 cells in rows 16-19 cols 0-7. T stub at col 9 rows 17,18,19 + col 8 row 18 = 4 cells. Total 36 cells; need 4 more: col 8 rows 16,17 and... col 8 rows 16,19? Let's count: rows 16-19 cols 0-7 = 32 filled. Remaining: col 8 rows 16,17,18,19 and col 9 rows 16,17,18,19 = 8 cells needed. T stub provides col 9 rows 17,18,19 (3) + col 8 row 18 (1) = 4. Need 4 more: col 9 row 16 and col 8 rows 16,17,19. An O at align 8 → 2x2 block; where does it land? Below col 8/9 rows 18,19 are occupied (T stub at rows 18,19 col 9; col 8 row 18; col 8 row 19? T stub: rel row 2 = col 1 → col 9 row 19; rel row 1 = cols 0,1 → col 8,9 row 18. So col 8 row 19 is NOT occupied (T rot3: cells (1,0),(0,1),(1,1),(1,2) → rows 0: col 9; row 1: cols 8,9; row 2: col 9). So col 8 row 19 is free!

Hmm, so the O at align 8 can drop to rows 18,19 at cols 8,9? col 9 row 19 is occupied → the O would land at rows... An O at cols 8,9 needs both cells free: rows 18,19 cols 8,9 — col 9 rows 18,19 are occupied by the T stub → so it lands at rows 16,17 (cols 8,9) ✓ → fills col 8 row 16, col 9 row 16, col 8 row 17, col 9 row 17.

Now: col 8: rows 16,17 (O) + 18 (T) + 19 (free) → need row 19 col 8. col 9: rows 16,17 (O), 18,19 (T) ✓.
Remaining gap: col 8 row 19 only. Can I fill it with an I horizontal? An I at align 8 would fill cols 8,9,10,11 → invalid. I vertical at col 8 → fills rows 16-19 col 8, but rows 16,17,18 are occupied → it would land at row 19 only? A vertical I occupying rows 16,17,18,19 col 8: the top cells at 16,17,18 are occupied → so it can't be placed there → it's blocked entirely → invalid move (isValid false) → hard drop not allowed... Actually hard drop would find no valid move → dist=0 → lockPiece immediately → game over? Let's avoid.

Better plan for the quad: make the T stub land entirely above row 16. Alternatively, avoid the first-piece problem differently: instead of key("r") giving T... 

Hmm, what if the first piece is placed in a "sacrificial" column and I use a 4-row clear in the other 9 columns + a vertical piece to fill the 10th column completely? A 4-row clear needs 40 cells. 

New idea: use the T stub as part of a column: T rot 3 at align 8 gives col 9 rows 17,18,19 + col 8 row 18 (4 cells) — this is like a 4-cell vertical-ish thing. Then place vertical I's in cols 0..7 (32 cells, rows 16-19). Then place an O at align 8 (top) → rows 16,17 cols 8,9. Now:
- cols 0-7: rows 16-19 filled (32)
- col 8: rows 16,17 (O), 18 (T), 19 (free)
- col 9: rows 16,17 (O), 18,19 (T)
Gap: col 8 row 19 only.

Fill col 8 row 19 with an O? O at align 8 → needs rows 16,17 free (occupied) → can't. What about a piece whose bottom row is a single cell at col 8 with the rest above rows 17-18? The col 8 rows 17,18 are occupied, so any piece touching col 8 must have its bottom cell at row 19 and everything else at rows < 17... impossible for a piece with multiple cells in the same column? A vertical I at col 8 has cells at rows 16,17,18,19 → blocked. T rot1 at some x with bottom cell at col 8: T rot1 cells (1,0),(1,1),(2,1),(1,2) → bottom row cells: col 1 only (rel). So the bottom cell is 1 cell. If the bottom cell lands at row 19 col 8 → x=7: cells (8, y0),(8,y0+1),(9,y0+1),(8,y0+2) → the cells at rows 17,18 = col 8 (occupied) → invalid. Hmm: y0+2 = 19 → y0 = 17 → cells at rows 17 (col 8), 18 (cols 8,9), 19 (col 8). Row 17 col 8 is occupied (O) → invalid.

OK, different approach for the quad: don't use the T stub. Instead, let the first bag piece T be dropped to create a partial stack that's *filled* by later pieces to complete 4 rows.

Actually simpler: use the T as a 3-cell bottom footprint and design a 4-row clear in a 10-column region where the T's cells are all in rows 17,18,19 in one column + adjacent. Let's use T rot 1 (vertical T pointing right): cells (1,0),(1,1),(2,1),(1,2) with minRel=0. Align at x=8 → col 10 invalid. Align at 7 → cells (8,y),(8,y+1),(9,y+1),(8,y+2) → col 8 rows y,y+1,y+2 and col 9 row y+1. Dropped so the lowest cell (rel row 2, col 8) is at row 19 → col 8 rows 17,18,19 and col 9 row 18. That's 4 cells: col 8 rows 17,18,19 + col 9 row 18.

Now place vertical I's in cols 0-6 (7 I's = 28 cells, rows 16-19). Then:
- cols 0-6: rows 16-19 filled (28 cells)
- col 7: nothing
- col 8: rows 17,18,19
- col 9: row 18
Need: col 7 rows 16-19 (4), col 8 row 16 (1), col 9 rows 16,17,19 (3) = 8 more cells.
Pieces to fill: col 7 vertical I (rows 16-19) = 4 cells ✓ (place vertical I at col 7 — is it placeable? Yes, nothing in col 7).
Remaining: col 8 row 16, col 9 rows 16,17,19.
- O at align 8 → cols 8,9 rows 16,17? Check what's below: col 8 rows 17,18,19 occupied; col 9 row 18 occupied. So the O at cols 8,9 would land at rows 16,17 ✓ → fills col 8 row 16, col 9 row 16, col 8 row 17, col 9 row 17. 
- Remaining: col 9 row 19 (1 cell) — same problem as before. 

Hmm. What if instead of T rot1 I use a piece that leaves col 9 rows 16,17,18,19 filled and something in col 8 rows 18,19? 

Use T rot 2 (upside-down T): cells (1,1),(0,2),(1,2),(2,2) with minRel=0, lowRel=2. Align at 7 → cells cols 8,7,8,9 at rows y+1,y+2,y+2,y+2 → bottom row = rel row 2 → cols 7,8,9 at row 19; and col 8 at row 18. Dropped → row 19 cols 7,8,9; row 18 col 8. That's a 3-cell bottom footprint — useful for making a bottom row, but for a 4-row clear we need cols 7,8,9 rows 16,17,18,19 = 12 cells; T rot2 gives 4 (row19 cols 7,8,9 + row18 col 8).

Total needed: 40 cells. Let's count cells from pieces:
- T rot2 @7: 4 cells (rows 19: 7,8,9; row 18: 8)
- vertical I ×7 at cols 0-6: 28 cells
Total 32. Need 8 more: cols 7 rows 16,17; col 8 rows 16,17; col 9 rows 16,17.
- O @7 → cols 7,8 rows 16,17 ✓ (below: col 7 rows 18,19 free? row 19 col 7 is occupied by T → O would land higher). Hmm: O at cols 7,8 → it drops until blocked: rows 18,19 at col 7 occupied (row 19 col 7 by T), col 8 row 18,19 occupied (row18 col 8 by T, row 19 col 8 by T) → so O lands at rows 16,17 ✓.
- O @8 → cols 8,9: below → col 8 rows 16,17 now occupied (from previous O), col 9 free. It would land at... it needs both cols 8,9 free: rows 16,17 col 8 occupied → it can't fit at rows 16,17 or below (rows 18,19 occupied) → invalid → can't place.

Use a vertical I at col 9 (rows 16-19): cells col 9 rows 16,17,18,19 — col 9 is free everywhere except row 19 (T covers col 9 row 19) → vertical I can't fit (row 19 occupied) → it'd land at rows 15-18 → invalid for our purpose. Hmm, then it would occupy rows 15,16,17,18 col 9.

Let me instead plan the quad from scratch using only horizontal I's and O's, and use the first T piece as part of a bottom row that gets completed, with the trick of doing the quad in a sub-region? No — a line clear requires the FULL row of 10 columns.

Alternative: use 4-row clear built as: rows 16-19 full. Pieces: vertical I's for cols 0-9 = 10 pieces, but the first bag piece is T. What if I place the T such that it lands in rows 12-15 (above), i.e., stacked on top of something? At the start the board is empty, so a T lands at the bottom.

New idea: Do a first throwaway clear to get rid of the T! E.g., use the T to help clear row 19: T rot0 @7 gives row 19 cols 7,8,9; then I@0 (0-3), I@4? (4-7 → col 7 taken). Use I@0 (0-3) and J@4 (4,5,6) → row 19 complete → 1 line clear (removes T's cells at row 19, but the T's cell at row 18 col 8 remains as a leftover at row 17 after the shift). Then I have a leftover stub at row 17 col 8. Then for the quad fill rows 16-19 with 10 vertical I's? The stub at row 17 col 8 blocks col 8's vertical I. Hmm, vertical I at col 8 needs rows 16-19 free; row 17 col 8 occupied → it lands at rows 18..21? It can't fit → invalid placement.

Use the stub as part of the quad: cols 0-7 vertical I's (rows 16-19, 8 I's = 32 cells) + stub (col 8 row 17 — wait, after the row-19 clear the stub shifts from row 18 to row 17). Let me recompute: T rot0 @7 → cells: rel cells (8,y0),(7,y0+1),(8,y0+1),(9,y0+1) → after drop: row 19 cols 7,8,9; row 18 col 8. Row 19 cleared → everything shifts down 1 → row 18 col 8 stub → moves to row 19 col 8? Wait, when row 19 is removed, rows above shift down by one: row 18's cell moves to row 19. Hmm, that means the stub ends up at row 19 col 8, and row 18 becomes... whatever was in row 17 (empty). So the stub is at row 19 col 8.

Then for a quad: rows 16-19 need filling; col 8 row 19 is filled by the stub ✓. Vertical I's at cols 0-7 (32 cells) and col 9 (4 cells) = 36 + stub 1 = 37. Need row 16 col 8, row 17 col 8, row 18 col 8 = 3 more cells. Place an O at align 8 → cols 8,9: below → col 9 rows 16-19 occupied by the vertical I, col 8 row 19 occupied by the stub → the O can't be placed at all (needs 2 cols free). Invalid.

OK. Use horizontal I's for the middle: Let me think about a cleaner construction that uses all 7 piece types naturally.

**Simplest robust quad construction**: fill rows 16,17,18,19 using horizontal I's and O's and the T stub:
- Row 19 (bottom): T rot0 @7 → cols 7,8,9 (3 cells) + I@0 → 0-3 (4) + I@4 → 4,5,6,7 → col 7 conflict. Use I@0 (0-3), I@4 (4-7)... conflicts with T's col 7. Use I@0 (0-3) and J@4? Wait J rot0 bottom footprint = cols x,x+1,x+2 at rel row 1 → align 4 → 4,5,6 ✓. So row 19: 0-3 (I), 4-6 (J), 7-9 (T) → 10 ✓ complete.
- Row 18: T contributes col 8. I@0 (row 18: 0-3), I@4 (row 18: 4-7), and col 9 needed → an O at align 8 lands where? Below col 8 row 18 (T) and col 9 row 19 (T) → so the O at cols 8,9 lands at rows 16,17 → wrong. We need row 18 col 9. 
  Use J rot 3 or T rot1 whose bottom footprint is a single cell... T rot 3: cells (1,0),(0,1),(1,1),(1,2) → bottom row (rel 2) = col 1 → single cell at bottom. Align so that the bottom cell is at col 9: minRel=0 → x = 9 → cells (9,y0),(8,y0+1),(9,y0+1),(9,y0+2) → the cells above the bottom: rows 17,18 col 9 and row 17 col 8. Row 18 col 8 is occupied by T → invalid.
  
  Alternatively use I vertical at col 9 → fills rows 16,17,18,19 col 9 → row 19 col 9 is occupied by the T → the vertical I would land at rows 15-18. Hmm.

This is getting long. Let me step back: rather than hand-crafting a quad, I can test the 800-point award differently — by directly verifying awardScore with a controlled state? It's closure-private.

Alternative pragmatic approach: use the `place`/`dropNext` machinery to do a quadruple clear by filling rows 16-19 using pieces that each contribute cells in multiple rows, with a planner that fills bottom-up. Since I have full control of placements, let me write a simple solver: a greedy "next empty cell" algorithm over the target region.

Actually — the simplest reliable quad: **use 10 vertical I's, and get rid of the first T piece by making it part of a bottom-row clear first**? The leftover stub at row 19 col 8 blocks the col-8 vertical I... but wait! After the bottom row clears, the stub moves from row 18 → row 19. Hmm, what if the stub is at row 17 at the time of the clear, so after clearing row 19 the stub moves to row 18, still blocking.

What if I place the first T VERTICALLY (rot 1) so ALL its cells are in rows 17,18,19 col 8 + row 18 col 9 → i.e., col 8 rows 17,18,19 + col 9 row 18 (the earlier plan). Then use the O@7 to fill cols 7,8 rows 16,17 and vertical I's... we computed gaps.

Honestly, the cleanest: place the first T piece so that it's part of a *partial column* and then fill the remaining cells with pieces chosen by a small solver. Let me write a mini solver: given a list of desired target cells (the 40 cells of rows 16-19) and a sequence of available pieces (T, then I×9... but I can only choose the piece type for pieces after the first; the first is T), find placements greedily.

Simpler: I realize a *3-line* clear test already validates 500, and the 4-line case only differs in the table value (800 vs 500) — a code path identical in structure. But I want real verification.

Alternative approach for the quad: fill rows 16-19 with ONLY 2 piece types that tile perfectly:
- Vertical I (4 cells, one column, 4 rows) — 10 of them fills rows 16-19 exactly (40 cells). The only issue is the first bag piece being T.
- O (2x2) — 20 O's would fill 4 rows × 10 cols = 40 cells.

What if I use O's for the quad? First piece is T. Hmm, same issue.

What if I *first* clear a line to consume the T, and then do the quad with 10 vertical I's, accepting that the leftover stub sits in row 19 col 8 (or wherever) — and then use the stub as part of the quad! Let's think: after the first clear, stub at row 19 col 8 (as computed). Now I want rows 16-19 full. col 8 row 19 is filled by the stub. I need: col 8 rows 16,17,18 (3 cells) + everything else.

Place vertical I's at cols 0-7 (rows 16-19, 8 pieces) and col 9 (rows 16-19). Then remaining: col 8 rows 16,17,18 (since row 19 col 8 is the stub). A vertical I at col 8 can't be placed (row 19 blocked). What piece can fill col 8 rows 16,17,18 exactly (3 cells in one column) without touching row 19? T rot1: cells (1,0),(1,1),(2,1),(1,2) → in column 1 (rel) it has 3 cells at rows 0,1,2, plus one cell at col 2 row 1. If the 3-cell column is col 8: x = 8-1 = 7 → cells: (8,y0),(8,y0+1),(9,y0+1),(8,y0+2). For these to be rows 16,17,18: y0 = 16 → cells (8,16),(8,17),(9,17),(8,18) → but col 9 rows 16-19 are occupied by the vertical I → (9,17) occupied → invalid.
  
Use T rot 3: cells (1,0),(0,1),(1,1),(1,2) → 3 cells in col 1 + 1 cell at col 0 row 1. x = 8-1 = 7 → cells (8,16),(7,17),(8,17),(8,18) → col 7 rows 16-19 occupied by vertical I → (7,17) invalid. Ugh, the vertical I at col 7 blocks.

What if I leave column 7 empty for this purpose and use a horizontal I for cols 7-9 in each row? Let's design:

Target rows 16-19:
- vertical I's at cols 0-6 (7 pieces, rows 16-19) → 28 cells
- stub at row 19 col 8 (1 cell)
- Need: cols 7,8,9 rows 16,17,18,19 = 12 cells, minus the stub (row 19 col 8) = 11 cells.
  - Horizontal I at cols 7,8,9,10 → invalid. 
  - O at cols 7,8: covers rows 16,17 → after that O at 7,8 again → rows 14,15 (no).
  
Let me count with O's: cols 7,8 need rows 16,17,18,19 (8 cells) → 2 O's (rows 16,17 and rows 18,19) ✓. And col 9 needs rows 16,17,18,19 (4 cells) → vertical I at col 9 ✓. And row 19 col 8 is the stub (1 cell). Let's recount: O@7 (rows16,17 cols7,8), O@7 again (rows18,19 cols7,8), vertical I@9 (rows16-19 col 9) → that gives col 8 row 19 from the second O ✓ (the stub is also at row 19 col 8 → conflict!). 

Hmm, the stub at row 19 col 8 conflicts with the O. Unless the stub is elsewhere.

OK: what if the first T piece is dropped VERTICALLY so that all 4 cells end up in ONE column (col X) rows 17,18,19 + one cell elsewhere... T rot1: cells (1,0),(1,1),(2,1),(1,2) → col 1 has 3 cells (rows 0,1,2) + col 2 row 1. If placed with the bottom cell at row 19: rows 17,18,19 in col x+1 and row 18 in col x+2. So 3 cells in one column + 1 adjacent cell. 

Then use that as the "T-part" of a 4-row fill where col x+1 gets rows 16 by another piece and col x+2 gets rows 16,17,19.
- x+1 (col c): rows 17,18,19 from T; need row 16 → any piece with a cell at row 16 col c that doesn't disturb: an O at cols c-1,c rows 16,17 → but row 17 col c is occupied → lands lower... it would be blocked. 
- Use a vertical I at col c: rows 16-19 col c → row 17,18,19 occupied → invalid.

Argh. The fundamental issue: T's 4 cells can't fill a full column of 4 rows, so it always leaves holes that are hard to fill.

**New approach**: Use the T as the *bottom-row helper* and construct the quad in rows 16-19 by using horizontal I's for 3 of the 4 rows and O's:
Consider filling rows 16,17,18 with horizontal I's + O's, and row 19 with the T footprint.
- Row 19: T rot0 @7 → cols 7,8,9. Remaining cols 0-6 (7 cells) = I@0 (0-3) + 3 cells → J rot0 @4 (4,5,6) ✓.
- Row 18: T contributes col 8. Need cols 0-7 and 9 (9 cells). Use I@0 (0-3) + I@4 (4-7) + col 9 single cell: a piece with a single-cell bottom footprint landing at col 9: T isn't available again (first piece used). But J rot3: cells (1,0),(1,1),(1,2),(0,2)? Let me compute J rotations from my matrix: J rot3 = [[0,1,0],[0,1,0],[1,1,0]] → cells (1,0),(1,1),(0,2),(1,2) → bottom row (rel 2) = cols 0,1 → 2 cells. J rot1 = [[0,1,1],[0,1,0],[0,1,0]] → cells (1,0),(2,0),(1,1),(1,2) → bottom row = col 1 only (1 cell) ✓! So J rot1 with bottom cell at col 9: minRel = 1 → x = 8 → cells (9,y0),(10,y0) invalid (col 10). Hmm, J rot1 has a cell at rel col 2 → x=8 gives col 10 → invalid.
  L rot1 = [[0,1,0],[0,1,0],[0,1,1]] → cells (1,0),(1,1),(1,2),(2,2) → bottom row = cols 1,2 (2 cells). L rot3 = [[1,1,0],[0,1,0],[0,1,0]] → cells (0,0),(1,0),(1,1),(1,2) → bottom row = col 1 only (1 cell) ✓. Place bottom cell at col 9 → minRel=0 → x=9 → cells (9,y0),(10,y0) invalid. Hmm! Because L rot3 has a cell at col 0 and 1 at the top row.
  T rot3: cells (1,0),(0,1),(1,1),(1,2) → bottom row col 1 only ✓ → bottom cell at col 9 → x=8 → cells (9,y),(8,y+1),(9,y+1),(9,y+2) → col 9 rows y,y+1,y+2 and col 8 row y+1. For row 18 to get col 9 only: y+2 = 18 → y = 16 → cells: (9,16),(8,17),(9,17),(9,18) → col 9 row 16,17,18 and col 8 row 17. But we want row 18 col 9 and row 18 col 8 is occupied by T → the piece's cells at rows 16,17 would be at col 9 and col 8 row 17 → is that OK? Row 17 col 8 must be free at that time (it will be filled later by other pieces) ✓ as long as the piece can be placed there. But we also need row 18 col 8 (from the original T) and the piece occupies (9,18) ✓ and (8,17),(9,17),(9,16). Then rows 16,17 col 9 filled, col 8 row 17 filled.

This is getting extremely long. Time check: I've used maybe 10 minutes. Let me simplify the verification strategy:

**Decision**: The 4-line (800) award is the only untested branch, and it's structurally identical to the others (table lookup). Rather than hand-crafting a quad, I'll write a *generic greedy solver* in the test: maintain a target cell set (rows 16-19 = 40 cells), and for each piece, try all rotations and all x positions, compute the landing cells, and prefer placements that (a) are legal, (b) all cells within the target region, (c) maximize the number of cells landing on still-empty target cells, and (d) prefer bottom-most placement. Then hard-drop. Repeat until rows 16-19 are full (or no progress). This solver should naturally produce a 4-line clear.

That's straightforward to implement: for each candidate (rot, x), simulate the drop: y starts at 0 and increases while valid... but validity depends on the board state; I can compute the landing y by copying the board (board is exposed, so I can read it and simulate with my own validity function replicating the game's rules using M and cells()).

Simulation function: 
```
function simulateDrop(board, type, rot, x) {
  // find y such that piece fits and cannot go lower
  let y = -3; // allow negative-ish start
  // find first y where cells are all in-bounds & free, then continue down
  for (let yy = -4; yy < 20; yy++) if (fits(board, type, rot, x, yy)) { y = yy; break; }
  if (y === null) return null;
  while (fits(board, type, rot, x, y + 1)) y++;
  return y;
}
```
fits: all cells within 0<=x<10, 0<=y<20 (allow y<0? the game allows y<0 as long as cells aren't below 0 — actually the game's isValid checks `cell.y >= 0 && board[cell.y][cell.x]` and `cell.y >= ROWS` → out of bounds. Cells above row 0 are allowed (spawn). For our purposes, require all cells y>=0.

Then apply to a copy of the board and score the placement by how many empty target cells it fills and whether it stays inside rows 16-19.

The solver picks the best placement per piece. Since the game's hard drop takes over after my keyboard alignment, I need the solver to choose (rot, alignCol) and then my `place()` does the keys. Order of keys: rotate first then move (place does that).

Note: my place() moves via keyboard which the game validates — fine.

Let me implement the solver-based tests for 1, 2, 3, and 4 line clears. Risk: the solver might produce a placement that leads to a different clear count than intended, but that's fine — I just log the result and check the score table for however many lines clear. To test each specific case, I'll define a target region:
- 1-line: target = row 19 only
- 2-line: rows 18,19
- 3-line: rows 17,18,19
- 4-line: rows 16..19

And run the solver until the target region is filled, then check the clear.

The first piece is always T (deterministic) — the solver handles whatever piece it gets.

Let me write this now. Also the existing tests B (double), C (quad via vertical I) already showed clears happening and level progression; with the solver I'll get exact numbers.

Let me code it.

Important findings:

1. **1-row clear verified: 100*1 + 2*17 = 134 → OK** ✓
2. **"MISMATCH" cases** — these are almost certainly my distance calculation being wrong, not the game. E.g., "Z rot1 x=6: +132, expected 100*1+2*dist(17)=134". Off by exactly 2 = one less distance unit. My `y0 = p.y + lowRel` where lowRel is computed for the *rotated* matrix... wait, I compute `cells(type, p.rot, 0,0)` — correct. Hmm, but the mismatch is consistent (132 vs 134, 132 vs 136).

Hmm, wait. Actually the issue might be that the hard-drop in the game happens *after* my `placeCurrent` rotations. Note: `p = T.current` was read BEFORE key("ArrowUp") rotations... no: placeCurrent reads T.current after rotations. Hmm, in the log, best.rot is chosen, then placeCurrent applies rotations, then `const p = T.current` — correct.

But `y0 = p.y + Math.max(...cells(type, p.rot, 0, 0).map(v => v[1]))` — this is the lowest row before the drop. Then dist = 19 - y0. For a piece that lands with its bottom at row 19 → dist = 19 - (p.y + lowRel) ✓.

But if the piece's bottom does NOT reach row 19 (it lands on top of the stack, e.g., bottom at row 18), then dist = 19 - y0 overestimates by 1. That's exactly the discrepancy (off by one row → 2 points). So these are test-side overestimates, not game bugs. ✓ Confirmed by "O rot0 x=6 ... expected 100*1+2*dist(18)=136" — my dist assumed bottom at 19 but it landed at 18.

So scoring for clears: verified correct for the 1-line case (134 exactly). 

3. **Level progression not tested** because the solver got stuck ("no legal placement inside region for Z") — the greedy solver fails to complete rows. The 4-row and multi-line clears weren't achieved.

Let me improve the solver, or use my earlier hand-crafted plans which partially worked. Actually earlier test_deep3 Test C did produce clears that incremented lines to 10 and level to 2, so level-up works. Let me verify the exact scoring for a 2-, 3-, and 4-line clear with better hand-crafted plans (like the ones I designed). My planned constructions:

- 2-row: T rot3 @8 (align 8) + 4 O's @0,2,4,6.
- 3-row: T rot3 @8 + I@0 ×3 + I@4 ×3 + O@8.
- 4-row: T rot0 @7 + I@0 ×3 + I@4 ×3 + ... hmm.

Let me reconsider the quad using the earlier verified approach: 10 vertical I's fill rows 16-19 exactly = 4-line clear. The problem was the first bag piece T. What if I use the T as the FIRST piece placed in a column that a vertical I won't need? No — all 10 columns are needed.

Alternative: what if the T piece is placed to make row 19's completion happen at the end... Actually: use 9 vertical I's (cols 0-8) + T rot3 @... Let's think: 9 vertical I's fill cols 0-8 rows 16-19 (36 cells). Need col 9 rows 16,17,18,19 (4 cells) — the T rot3 aligned so its 3-cell column is col 9 and the extra cell at col 8 row y+1. T rot3 cells: (1,0),(0,1),(1,1),(1,2). If the 3-cell column is col 9 → x = 8 → cells (9,y0),(8,y0+1),(9,y0+1),(9,y0+2). Col 8 rows 16-19 are occupied by vertical I's → (8,y0+1) invalid. 

T rot1: cells (1,0),(1,1),(2,1),(1,2) → 3-cell column at col 1 (rel) → x = 8 → cells (9,y0),(9,y0+1),(10,y0+1) invalid.

So the T's extra cell always sits adjacent in a column that must be free.

Option: leave column 9 for the T's column and fill cols 0-8 with 9 vertical I's... then the T's 3-cell column IS col 9 (x=8) with the extra cell at col 10 → invalid. So instead: T rot3 with the 3-cell column at col 9 means x = 8 → extra cell at col 9? No: cells (1,0),(0,1),(1,1),(1,2): col0 row1 = extra. With x=8: extra at col 8 row 1. Invalid since col 8 is filled.

What if the vertical I's fill cols 1-9 (9 I's) and the T's 3-cell column is col 0? T rot3 with the 3-cell column at col 0 → x = -1 → cells (-1,...) invalid. T rot1: 3-cell column at rel col 1 → x = -1 invalid.

Hmm. What about making the T's extra cell land in the column of a vertical I's stack but at a row that's free? All rows 16-19 in those columns are filled by the vertical I's. Unless the vertical I at that column is placed AFTER the T... but the T lands at rows 17,18,19 (bottom at row 19) → it occupies 3 rows in col 8 (say) + col 9 row 18. Then a vertical I at col 8 can't be placed (rows 17,18,19 occupied). 

Alternatively, place the T so that its 3-cell column is in a column that's NOT needed for a full vertical: i.e., accept that column has only 3 rows filled by T and fill the 4th (row 16) with another piece: O@(col-1) fills col-1 and col rows 16,17 → fills row 16 in both col-1 and col. But then col-1 rows 16,17 are filled by the O, and col-1 rows 18,19 must be filled by... the vertical I at col-1 fills rows 16-19 → conflict with the O at rows 16,17.

Let's do the full accounting for a quad with: T rot3 @align so its 3-cell column = col 8 (x=7 → cells (8,y0),(7,y0+1),(8,y0+1),(8,y0+2)) and its extra cell = col 7 row y0+1. With the bottom cell at row 19: y0+2 = 19 → y0 = 17 → cells: (8,17),(7,18),(8,18),(8,19). So col 8 rows 17,18,19 + col 7 row 18.
Now fill: 
- cols 0-6: vertical I's → rows 16-19 (7 I's, 28 cells)
- col 7: needs rows 16,17,19 (row 18 done by T's extra cell) = 3 cells
- col 8: needs row 16 (1 cell)
- col 9: needs rows 16,17,18,19 (4 cells)
Total remaining 8 cells: col7 rows 16,17,19; col8 row 16; col9 rows 16,17,18,19.
Place a vertical I at col 9 → rows 16-19 col 9 ✓ (4 cells).
Remaining: col 7 rows 16,17,19; col 8 row 16 (4 cells).
An O at cols 7,8 → rows 16,17 → fills col 7 rows 16,17 and col 8 row 16 ✓✓ (4 cells). 
Remaining: col 7 row 19 (1 cell). Damn.

Use instead: an O at cols 7,8 for rows 18,19? Row 18 col 7 is occupied by T's extra cell → the O would land above → rows 16,17. Same as above.

So we always end up with 1 leftover cell in col 7 row 19. Fill col 7 row 19 with an I horizontal? I@7 → cols 7,8,9,10 → invalid. A piece with a single bottom cell at col 7 that has its other cells at rows 16,17 in col 7 (occupied) — no.

OK so a "T + 9 vertical-ish" quad isn't feasible. Let me instead build the quad with horizontal I's + O's + T, by using rows:
Target rows 16,17,18,19 (40 cells).
Plan using T rot3 @align so 3-cell column is col 9:
- T rot3: x = 8 → cells (9,y0),(8,y0+1),(9,y0+1),(9,y0+2) → with y0+2 = 19 → y0 = 17 → cells (9,17),(8,18),(9,18),(9,19). So col 9 rows 17,18,19 + col 8 row 18 (4 cells).
- Now: col 9 needs row 16 (1 cell); col 8 rows 16,17,19; cols 0-7 all 4 rows.
Use 2 vertical I's at col 0 and... let me just count what's needed: 
  cols 0-7 rows 16-19 = 32 cells
  col 8: rows 16,17,19 = 3 cells
  col 9: row 16 = 1 cell
  Total 36 more cells.
Available pieces: I (vertical = 4 cells in a column; horizontal = 4 cells in a row), O (2x2 = 4 cells), L/J/S/Z/T (4 cells each).
- Vertical I's at cols 0-7 = 8 I's = 32 cells ✓
- Remaining: col 8 rows 16,17,19; col 9 row 16 = 4 cells.
- An O at cols 8,9 → covers rows 16,17 in both → fills col 8 rows 16,17 and col 9 row 16 ✓ (4 cells) — perfect fit!
- Remaining: col 8 row 19 (1 cell). STILL one leftover. Because the T's extra cell at col 8 row 18 replaced a needed cell at col 8 row 19... 

Total accounting check: 40 = 32 (vertical I's) + 4 (T) + 4 (O) = 40 cells ✓ but distributed as: T gives col9 rows17,18,19 + col8 row18; O gives col8,9 rows16,17; I's give cols0-7 rows16-19. Sum per column: col0-7: 4 each ✓. col8: 18,16,17 → row 19 MISSING. col9: 17,18,19,16 → 4 ✓. Total = 28+8... hmm: 8 columns × 4 = 32, col8 = 3, col9 = 4 → 39 cells, but we need 40. Wait the O gives col 8 rows 16,17 AND col 9 rows 16,17 (4 cells: col8r16, col8r17, col9r16, col9r17) ✓. So col8 = 18(T),16(O),17(O) = 3; col9 = 17,18,19(T) + 16,17(O) = 5 → wait that's 5 cells in col 9?! col9 row 17 is filled by both T and O → OVERLAP. That's illegal.

I need to be careful. Let me redo: T rot3 x=8: cells (9,17),(8,18),(9,18),(9,19) → col9: rows 17,18,19. So an O at cols 8,9 rows 16,17 would overlap col 9 row 17. So the O must land at rows 15,16 or 18,19 → rows 18,19: col 8 row 18 occupied → blocked; so rows 15,16 → out of the target region (row 15).

So the T must be placed differently. Let me use T rot1 (extra cell at rel col 2, row 1): x=7 → cells (8,y0),(8,y0+1),(9,y0+1),(8,y0+2) → 3-cell column col 8, extra cell col 9 row y0+1. With y0+2 = 19 → y0 = 17 → cells (8,17),(8,18),(9,18),(8,19) → col 8 rows 17,18,19 + col 9 row 18.
Now: col 8 needs row 16; col 9 needs rows 16,17,19; cols 0-7 need all 4 rows.
- Vertical I's at cols 0-7 → 32 cells ✓
- Remaining: col 8 row 16 (1), col 9 rows 16,17,19 (3) = 4 cells.
- An O at cols 8,9 → rows 16,17: check overlaps: col 8 rows 17,18,19 occupied; col 9 row 18 occupied. An O at cols 8,9 needs rows 16,17 in both → free? col 8 row 17 is occupied by the T → so the O can't be at rows 16,17 (col 8 row 17 occupied) → it goes higher (rows 15,16) → out of region. 

Hmm! The T's 3-cell column at col 8 (rows 17,18,19) blocks an O at col 8 in rows 16,17.

Use: vertical I's at cols 0-7 and col 9 (9 I's, 36 cells) → then col 8 needs rows 16,17,18,19 (4 cells) but the T occupies 3 of them. Instead: place vertical I's at cols 0-8 and col 9 EXCEPT the T's column. Let the T's 3-cell column be col 9: T rot3 x=8 gives 3-cell column at col 9? cells (1,0),(0,1),(1,1),(1,2): col with 3 cells = rel col 1 → x = 8 → col 9 ✓, extra cell at rel col 0 row 1 → col 8 row y0+1. With y0+2 = 19: y0 = 17 → cells (9,17),(8,18),(9,18),(9,19).
- Vertical I's at cols 0-8 (9 I's = 36 cells, rows 16-19) ✓ — col 8 row 18 is occupied by the T's extra cell → the vertical I at col 8 can't fit! Blocked.

Alternatively, put the T's extra cell in a column where the vertical I is placed with the extra cell ABOVE row 16: i.e., the T's lowest cell lands at row 19 but its extra cell at row 18 → still within 16-19. To have the extra cell above row 16, the T's bottom must land at row 19 but... the extra cell is at row y0+1 = 18. Always within.

Conclusion: the T inevitably conflicts. So build the quad with the T as a bottom-row filler and fill rows 16,17,18 with horizontal I's and O's:

- T rot0 @7 → row 19: cols 7,8,9 (3 cells); row 18: col 8 (1 cell)
- Row 19: cols 0-6 remaining (7 cells): I@0 (0-3) + 3 cells: J@4? J rot0 bottom row = cols x,x+1,x+2 → align 4 → 4,5,6 ✓
- Row 18: needs cols 0-7 (8 cells) + col 9 (1). T gives col 8. 
  - I@0 (row 18: cols 0-3) ✓, I@4 (row 18: cols 4-7) ✓ → now col 9 row 18 remains.
  - Fill col 9 row 18 with a piece: vertical I at col 9 → needs rows 16,17,18,19 col 9 all free → row 19 col 9 is occupied by the T → blocked.
  - Use an O at cols 8,9: rows 16,17 → check below: col 8 row 18 (T), col 9 row 19 (T) → the O lands at rows 16,17 ✓ → fills col 8 rows 16,17 and col 9 rows 16,17. But we needed col 9 row 18, not row 16/17. Then col 9 row 18 remains empty.

Let me instead reorganize: use O's to fill cols 8,9 in rows 16,17 and 18,19 (2 O's stacked at cols 8,9):
- O@8 (rows 16,17 cols 8,9) — needs to land there: below is col 8 row 18 (T) and col 9 row 19 (T) → lands at 16,17 ✓
- O@8 again → lands at rows 14,15 (blocked by the first O) ✗ — that overshoots the region.
So one O at cols 8,9 rows 16,17. Then rows 18,19 for cols 8,9: row 18 col 8 (T ✓), row 18 col 9 (need), row 19 cols 8,9 (T ✓). So only col 9 row 18 is missing (1 cell).

I need a piece giving exactly col 9 row 18 with other cells in rows 16,17 (already filled) → impossible.

Hmm, what if the T's extra cell is at col 7 (i.e., T rot0 @6 → row 19 cols 6,7,8; row 18 col 7)? Then:
- Row 19: cols 0-5,9 remain → I@0 (0-3) + 2 cells at 4,5 → O@4? O bottom row = cols 4,5 ✓ (rows 18,19) → fills row 19 cols 4,5 ✓; col 9 row 19 → single cell piece with bottom cell at col 9: T rot3 rotated... T rot3's bottom cell is at rel col 1, minRel 0 → x=8 → cells (9,y0),(8,y0+1),(9,y0+1),(9,y0+2) → bottom cell col 9 row 19 ✓ with other cells col 9 rows 17,18 and col 8 row 18. Alternatively L/J/S/Z/T with single bottom cell: 
  - S rot3 = [[1,0,0],[1,1,0],[0,1,0]] → cells (0,0),(0,1),(1,1),(1,2) → bottom row = col 1 only ✓ → bottom cell at col 9 → x = 8 → cells (8,y0),(8,y0+1),(9,y0+1),(9,y0+2) → cells: col 8 rows y0,y0+1; col 9 rows y0+1,y0+2. With y0+2 = 19 → y0 = 17 → cells (8,17),(8,18),(9,18),(9,19) → col 8 rows 17,18 + col 9 rows 18,19.
  
  Let's use S rot3 @ align such that bottom cell = col 9: gives col 8 rows 17,18 and col 9 rows 18,19.
  
This is really fiddly. Let me improve the solver instead — make it smarter: a proper search over placements (DFS with backtracking) that tries to complete the target region. Given piece types are forced by the bag (deterministic with seed), and I can place each piece anywhere, a DFS up to depth ~10 with branching ~40 = too much... but with pruning (fill bottom-up, prefer placements that don't create unfillable holes) it might work.

Simpler idea: **relax the "quad in rows 16-19" requirement** and instead test 4-line clears by *lowering* the target: a 4-line clear happens whenever 4 rows complete simultaneously. Alternative construction: build a 4-row-tall stack in ALL 10 columns using vertical I's only (10 I's) — the only obstruction is the initial T. What if I first *discard* the T by dropping it in a way that creates a partial row, then clear that row (1-line clear) — the leftover stub lands in row 19 (as computed). Then do the 10 vertical I's... the stub at row 19 col X blocks the vertical I at col X. But WAIT: does it? A vertical I at col X needs 4 consecutive free cells in col X. With row 19 col X occupied, the vertical I lands at rows 15-18 → which is ABOVE the stub. Then rows 16,17,18 col X are filled by the I, and row 19 col X by the stub → so col X is fully filled in rows 16-19! 

So the plan:
1. Drop the first T to leave a single-cell stub that will be cleared → after the clear, the stub sits at row 19 in some column c.
2. Drop vertical I's in all 10 columns: for cols ≠ c they fill rows 16-19; for col c the I lands at rows 15-18 → wait, that's a problem: then col c has rows 15,16,17,18 filled by the I and row 19 by the stub → so rows 16,17,18 col c ✓ and row 19 col c ✓ → col c complete for rows 16-19 ✓✓. 

So actually it doesn't matter — the vertical I at col c just sits one row higher, and rows 16-19 col c are all filled (16,17,18 from I, 19 from stub). 

But careful: the vertical I at col c occupying rows 15-18 leaves row 15 col c filled — a leftover stub at row 15, fine.

3. Then all 10 columns have rows 16-19 filled → the LAST vertical I completes rows 16,17,18,19 → 4-line clear = 800 points!

But hold on: step 1 requires the T to leave a single-cell stub after a 1-line clear. Let's engineer: T rot0 @7 → row 19 cols 7,8,9; row 18 col 8. Then fill row 19 cols 0-6: I@0 (0-3) + O@4? O bottom row = cols 4,5 (2 cells) → then col 6 remains. Use I@0 (0-3), I@4 → cols 4-7 → col 7 already taken by T. Hmm: need exactly cols 0-6 (7 cells): options: I@0 (4 cells: 0-3) + J@4 (3 cells: 4,5,6) ✓. So row 19 = 0-3 (I) + 4-6 (J) + 7-9 (T) = full → clear 1 line. The leftover above: T's row-18 cell at col 8, J's row-18 cell at col 4, I has none (I rot0 has only row rel 1 = row 19) ✓.
After the clear, those leftovers shift down to row 19: col 8 (from T) and col 4 (from J) → 2 stubs at row 19 cols 4 and 8.

Then vertical I's at cols 0,1,2,3,5,6,7,9 (8 I's) → rows 16-19; and at cols 4 and 8 the vertical I lands at rows 15-18 (since row 19 is blocked) → rows 16,17,18 + stub row 19 → so cols 4 and 8 have rows 16-19 complete ✓.
Then all rows 16-19 complete → 4-line clear = 800.

Wait, but does the vertical I at col 4 really land at rows 15-18? Its cells: col 4 rows 15,16,17,18 — all free ✓ (row 19 col 4 has the stub). The game's hard drop drops until collision: the piece can't go to rows 16-19 (row 19 blocked) → lands at 15-18 ✓.

So after all 10 vertical I's, rows 16,17,18 are complete across all 10 columns ✓ and row 19 is complete (stubs at 4, 8 + vertical I's at other columns fill rows 16-19 including row 19 for the 8 columns) ✓ → 4 rows complete at once → 800 points!

Order matters: after the 1-line clear, the stubs are at row 19. Then drop vertical I's one at a time. Each drop either fills normally or sits higher. The 10th drop completes everything.

Hmm, one catch: after the 1-line clear, are the stubs at row 19? The T's row-18 cell and J's row-18 cell are in row 18 → after row 19 is removed, row 18's content moves to row 19 ✓.

Let me also handle: does the 1-line clear happen before I place the I's? Yes: rows complete → clear immediately on lock.

Great, let me implement:
```
key("r");  // current = T
// T rot0 @ align 7 (bottom footprint cols 7,8,9)
placeCurrent(0, 7);  // T rot0 minRel=0 → x=7
// I@0
T.next = "I"; placeCurrent(0, 0); key(" ");
// J@4
T.next = "J"; placeCurrent(0, 4); key(" ");
```
Careful: placeCurrent applies rotations to the CURRENT piece. After `key("r")`, current = T (bag) and next = whatever. So:
- placeCurrent(0, 7) on the T → x = 7 - minRel(T,0) = 7-0 = 7 ✓ → key(" ") drops T.
- Then current = next (bag piece, uncontrolled) — PROBLEM: after dropping T, the next piece comes from the bag, not my chosen type. I must set T.next BEFORE dropping T. So: T.next = "I" first, then place/drop the T, then the current becomes I ✓.

So the pattern: set T.next = <type of the piece I want to place after the current one>, then place/drop the current one.

Sequence for the quad test:
1. key("r") → current = T, next = bag1
2. T.next = "I" (so after T, we get I)
3. place T rot0 @7, drop → T locks
4. current = I (spawned using nextType "I"), next = bag2
5. T.next = "J"; place I rot0 @0; drop
6. current = J; T.next = "I"; place J rot0 @4; drop → row 19 completes → 1-line clear (score 100*1 + dist*2)
7. Now stubs at row 19 cols 4 and 8. For each column c in 0..9 (except the two with stubs? no — do all columns, in order): T.next = "I"; place I rot1 @c (vertical); drop.
   - Note: placeCurrent(1, c) means: rotate once, then align the leftmost column to c. For I rot1, minRel = 2 → wantX = c - 2.
8. After 10 vertical I's → 4-line clear → 800.

Wait, but during step 7, when the vertical I at col 4 lands at rows 15-18 (above the stub), row 15 col 4 gets filled. Fine.

Also: after the 1-line clear in step 6, the stubs are at row 19 (cols 4 and 8). Let me double check the J rot0 placement: J rot0 = [[1,0,0],[1,1,1],[0,0,0]] → cells (0,0),(0,1),(1,1),(2,1) → bottom row (rel 1) cols 0,1,2 → align 4 → x = 4 → cols 4,5,6 ✓; row above (rel 0) col 4 → row 18 col 4 ✓.

But hold on: will the J at align 4 land correctly? Row 19 cols 4,5,6 free ✓ (T occupies 7,8,9; the earlier I occupies 0-3) ✓.

So after all 4 pieces: row 19 full → clear. Leftovers: row 18 col 8 (T), row 18 col 4 (J). After the clear → row 19 cols 4, 8. ✓

Then the vertical I's. Note the FIRST piece of each "T.next" sequence: for step 7, current = I (from step 5's T.next = "I"? Let me re-trace the flow with `spawnPiece` using nextType:
- After step 4 (dropping T): current = I (nextType was "I"), nextType = bag2.
- Step 5: I set T.next = "J", then place the current (I) and drop → spawnPiece: current = J, nextType = bag3.
- Step 6: I set T.next = "I", place J, drop → spawnPiece: current = I, nextType = bag4.
- Step 7: T.next = "I" each time; place current (I) rot1 @c, drop → next = I ✓.

So in step 7 I set T.next = "I" before each drop ✓ (the current is already I).

Now, expected score for the 4-line clear: 800 * level. Let's verify. Also the earlier 1-line clear gives 100 + 2*dist.

Let me also do a 3-line clear: T rot3-based plan? With the "clear then fill" trick I can do a 3-line clear similarly:
- Fill rows 17,18,19 completely. Using the stub trick isn't needed; let me use: T rot0 @7 (row19: 7,8,9; row18: col 8), I@0 (row19: 0-3), I@4 (row19: 4-7)?? conflicts with T's col 7. Use J@4 (4,5,6) → row 19 complete → clear (1 line) → stubs at row 19 col 8 (T) and col 4 (J).
Hmm, for a 3-row clear I need rows 17,18,19 all complete simultaneously. Let's use the vertical-I trick for 3 rows? A vertical I fills 4 rows. 

Alternative for a 3-line clear: build up using horizontal I's and O's:
- Row 19: T rot0 @7 (7,8,9) + I@0 (0-3) + J@4 (4-6) → clear happens immediately. Not what I want for a 3-line clear.

Instead, avoid completing row 19 until the end:
- Row 18: fill cols 0-9 without touching row 19? Any piece resting on row 19 fills row 19 too. So build row 18 first with pieces that also fill row 19... 

The standard way: fill from the bottom up. Row 19 first, then row 18, etc., but the last piece completes all of them at once (that's the trick for a multi-line clear): fill rows 17,18,19 in 9 columns, then drop the final piece that completes all 3 rows in column 9? No — the final piece would need to fill 3 cells in one column (col 9 rows 17,18,19) plus ... e.g., a vertical I at col 9 fills rows 16-19 (4 cells) → if rows 17,18,19 col 9 are empty and row 16 col 9 is also empty → the vertical I lands at rows 16-19 ✓ → completing rows 17,18,19 (and row 16 col 9) → 3-line clear ✓ (if rows 17,18,19 are otherwise filled).

So: fill cols 0-8 rows 17,18,19 (27 cells) with pieces, then a vertical I at col 9 → 3-line clear.
Filling 9 columns × 3 rows: use vertical I's? A vertical I fills 4 rows in one column → would also fill row 16 → then row 16 would have 9 cells filled → after the 3-line clear, row 16 (partial, missing col 9) remains as a leftover at row 19... fine, doesn't prevent the clear. So: 9 vertical I's at cols 0-8 (each fills rows 16-19 of that column) + 1 vertical I at col 9 → completes rows 16,17,18,19 → that's a 4-line clear, not 3.

For a 3-line clear, fill cols 0-8 rows 17,18,19 using O's and I's that don't touch row 16: an O covers 2 cols × 2 rows (rows 18,19) → to cover rows 17,18,19 in cols 0-1: O (rows 18,19) + another piece for row 17 cols 0,1 → an O above (rows 16,17) → touches row 16. Alternatively a horizontal I at row 17 covers 4 cols. Let me do:
- Row 17: I@0 (cols 0-3), I@4 (cols 4-7), and cols 8 → single cell...
  
Hmm, let me try: rows 17,18,19 for cols 0-8 (27 cells):
- Horizontal I's: 3 rows × 9 cols: row 17: I@0 (0-3), I@4 (4-7), col 8 needs 1 cell. 
- Use O's: O@0 (rows 18,19 cols 0,1), O@2 (rows 18,19 cols 2,3), O@4 (cols 4,5), O@6 (cols 6,7) → rows 18,19 cols 0-7 ✓ (16 cells), then row 17: I@0 (cols 0-3), I@4 (cols 4-7) ✓ (8 cells), then col 8 rows 17,18,19 (3 cells) → then the final vertical I at col 9 gives rows 16-19 → completes rows 17,18,19 (cols 0-8 + col 9 from the I) → 3-line clear? But col 8 rows 17,18,19 must be filled: 3 cells in one column → a vertical T (rot0 T: cells (1,0),(0,1),(1,1),(2,1)) no. A vertical piece with exactly 3 cells in col 8: T rot1 = cells (1,0),(1,1),(2,1),(1,2) → col 1 (rel) has 3 cells + 1 cell at col 2 row 1. If col 8 is the 3-cell column → x = 7 → extra cell at col 9 row y0+1 → conflicts with the final vertical I at col 9.
  T rot3 = cells (1,0),(0,1),(1,1),(1,2) → 3-cell column at rel col 1 → x = 7 → extra cell at rel col 0 row 1 → col 7 row y0+1. Col 7 row y0+1: if the T's bottom is at row 19 (y0+2 = 19 → y0 = 17) → extra cell at col 7 row 18 → already filled by the O@6 (rows 18,19 cols 6,7) → blocked. Place the T BEFORE the O's: then the T at col 8 rows 17,18,19 + col 7 row 18 → then the O@6 (cols 6,7 rows 18,19) would be blocked at col 7 row 18 → it'd land at rows 16,17 → touching row 16. That's OK! Row 16 partial is fine.
  
  Hmm, but then row 17 col 7 would be filled by the O ✓ (needed). Let me carefully construct:
  1. T rot3 @ align so 3-cell col = 8 → x = 7 → cells: (8,17),(7,18),(8,18),(8,19) [assuming bottom at row 19] ✓
  2. O@0 (rows 18,19 cols 0,1) ✓
  3. O@2 (rows 18,19 cols 2,3) ✓
  4. O@4 (rows 18,19 cols 4,5) ✓
  5. O@6 (rows 16,17 cols 6,7) — blocked below by T's cell at col 7 row 18 → lands at rows 16,17 ✓ (row 16 col 6,7 filled — fine)
  6. I@0 rot0 (row 19? no...) — hmm, row 17 cols 0-5 need filling: after step 5, row 18 cols 0-7 ✓ (O's + T col 8) — wait row 18: cols 0-7 from O's (0,1 / 2,3 / 4,5 / 6,7) ✓ and col 8 from T ✓ → row 18 cols 0-8 ✓. Row 19: cols 0-7 from O's ✓, col 8 from T ✓ → row 19 cols 0-8 ✓. Row 17: col 6,7 (O) ✓, col 8 (T) ✓ → need cols 0-5 (6 cells): I@0 rot0 → fills row 19 only ✗ (row 19 already full → it would land at row 17? Let's see: a horizontal I at row 19 cols 0-3 is blocked → it lands at rows... the I has cells only at rel row 1 → it lands with that row at 17 → cells at row 17 cols 0-3 ✓!). 
  So: I@0 rot0 → row 17 cols 0-3 ✓; I@4 rot0 → row 17 cols 4-7? col 6,7 row 17 are occupied by the O@6 → blocked → it would land at row 16 → row 16 cols 4-7 (not needed). Hmm, I need row 17 cols 4,5 only (2 cells): an O@4 → cols 4,5 rows 16,17 (since rows 18,19 occupied) ✓ → fills row 17 cols 4,5 ✓ and row 16 cols 4,5.
  7. So after steps: row 17: cols 0-3 (I), 4,5 (O), 6,7 (O), 8 (T) = complete ✓. Row 18: 0-8 ✓. Row 19: 0-8 ✓. Col 9: nothing.
  8. Final: vertical I at col 9 → rows 16-19 col 9 → completes rows 17,18,19 → 3-LINE CLEAR = 500 ✓

Piece sequence: T(first), O, O, O, O, I, O, I-vertical... but the bag gives me control only via T.next. The first piece is T ✓ (needed!). Then I set next before each drop. 

Order of drops matters: T first, then O@0, O@2, O@4, O@6(→rows16,17), I@0(row17), O@4(rows16,17), vertical I@9.

Wait, careful with the O@6 landing at rows 16,17: at that point, is col 7 row 18 occupied? Yes by T's extra cell (7,18) ✓ and col 6 row 18 is occupied by O@4 (cols 4,5) — no, O@4 covers cols 4,5. So col 6 row 18 is free until O@6 lands. O@6 → cols 6,7: below → col 6: rows 18,19 free (nothing there yet!), col 7: row 18 occupied (T) → so the O at cols 6,7 lands where both are free: rows 17,18? col 7 row 18 occupied → no. rows 16,17 → free ✓ → lands at rows 16,17 ✓. Good, as planned.

Hmm, but actually it's simpler to check: I'll just simulate with my solver... but my greedy solver was too weak. Let me just implement these explicit plans and verify the resulting clears. If the plans are slightly off, I'll see "no clear" and can adjust.

Actually, better idea to save time: use my simulateDrop machinery to *verify each planned step* before executing, and print the resulting board. I'll write the plans and add an assertion that each step's placement is as expected (e.g., cells land where I predicted). Then check the clear.

Let me write the final test with the three plans (2-line, 3-line, 4-line) plus level progression and the earlier verified behaviors.

2-line clear plan (simpler): T rot3 @8 (col 9 rows 17,18,19 + col 8 row 18) + 4 O's at cols 0,2,4,6 (rows 18,19) → rows 18,19 complete (cols 0-7 from O's, col 8 row 18 from T, col 9 rows 18,19 from T) → row 18: cols 0-7 (O's) + 8,9 (T) ✓ = complete; row 19: cols 0-7 (O's) + 9 (T) → col 8 row 19 MISSING. Hmm.

Let me recompute T rot3 cells: [[0,1,0],[1,1,0],[0,1,0]] → cells (1,0),(0,1),(1,1),(1,2) → 3 cells in rel col 1 (rows 0,1,2) + 1 cell at rel col 0 row 1. With x = 8: col 9 rows y0,y0+1,y0+2 and col 8 row y0+1. With y0+2 = 19 → y0 = 17 → cells: (9,17),(8,18),(9,18),(9,19). So col 9 rows 17,18,19 and col 8 row 18.
Then 4 O's at cols 0,2,4,6 → rows 18,19 cols 0-7.
Row 18: 0-7 ✓ + col 8 ✓ + col 9 ✓ = complete ✓
Row 19: 0-7 ✓ + col 9 ✓ + col 8 ✗ → NOT complete.
So I need col 8 row 19: add an O at cols 8,9 → lands at rows 16,17 (since col 8 row 18 and col 9 rows 18,19 occupied) → gives col 8,9 rows 16,17 → doesn't fill row 19 col 8.

Alternatively, place the T's extra cell at col 9 row 18 with the 3-cell column at col 8: T rot1: cells (1,0),(1,1),(2,1),(1,2) → 3-cell column rel col 1, extra at rel col 2 row 1 → x = 7 → cells (8,y0),(8,y0+1),(9,y0+1),(8,y0+2) → with y0+2 = 19 → y0 = 17 → cells (8,17),(8,18),(9,18),(8,19) → col 8 rows 17,18,19 + col 9 row 18.
Then 4 O's at cols 0,2,4,6 → rows 18,19 cols 0-7.
Row 18: 0-7 ✓ + col 8 ✓ + col 9 ✓ = complete ✓
Row 19: 0-7 ✓ + col 8 ✓ + col 9 ✗ → need col 9 row 19.
 Fill col 9 row 19 with... an O at cols 8,9 → blocked (col 8 rows 18,19 occupied) → lands rows 16,17 ✗.
 Use the T's extra cell at col 9 row 18; hmm what I want is col 9 row 19 filled and col 8 rows 17,18,19 → the piece that fills col 9 rows 17,18,19 AND col 8 row 18 is T rot3 (as first computed). Then row 18 = complete, row 19 missing col 8.

So with T rot3: rows 18 complete, row 19 missing col 8 → 1-line clear only. With T rot1: rows 18 complete (col 9 from the extra), row 19 missing col 9.

To complete both rows 18 and 19, I need the bottom row's 10 cells: cols 0-7 from 4 O's + cols 8,9 from something that covers BOTH rows at cols 8,9 → an O at cols 8,9 → rows 16,17 ✗ (blocked below). Unless nothing below → i.e., place the O at cols 8,9 FIRST (rows 18,19) then fill cols 0-7 with 4 O's → rows 18,19 complete → 2-line clear = 300 ✓✓. That's my original plan B (5 O's at 0,2,4,6,8) which requires the first piece to be an O... but the first piece is T.

Solution: use the T as the FIRST piece to fill cols 8,9 rows 18,19? T rot3 @8 gives col 9 rows 17,18,19 + col 8 row 18 → row 19 col 8 missing.

Alternative: drop the T somewhere harmless and complete rows 18,19 with 4 O's at cols 0,2,4,6 + an O at 8 = 5 O's, and let the T be... the T must go somewhere. What if the T lands on TOP of the finished rows (above row 18)? E.g., after filling rows 18,19 cols 0-9 partially such that a T can rest with all cells in rows 15-17? For a T to rest above, it needs support. 

Simplest: fill rows 18,19 cols 0-7 first (4 O's), then drop the T so it lands with its 3 cells in row 19 cols 8,9?? T rot0 @7 → row 19 cols 7,8,9 → col 7 occupied by O@6 → blocked → the T would land one row higher: cells (8,17),(7,18),(8,18),(9,18) → row 18 cols 7,8,9 and row 17 col 8. But row 18 cols 6,7 are occupied by the O@6 → so (7,18) is blocked → the T goes higher: cells (8,16),(7,17),(8,17),(9,17) → row 17 cols 7,8,9 + row 16 col 8. Hmm, so the T lands above, and rows 18,19 keep cols 8,9 empty → then I need to fill cols 8,9 rows 18,19 with an O → lands at rows 18,19 ✓ → completes rows 18,19 → 2-line clear ✓ (300) — and the T leftover sits at rows 16,17.

So plan for the 2-line clear: 
1. T (first piece): drop at some position — BUT the order matters: the T must be dropped when the stack is as described. If I drop the T first (empty board), it lands at the bottom. So instead: drop the 4 O's FIRST? No — the T is the first piece.

Ugh. The T is the first piece. OK, so: use the T to build part of the target, then fill around it. We found the T inevitably leaves one hole in the bottom row... unless I use the T as a vertical stub and fill the bottom row differently. Let's revisit:

T rot1 @7 → cells (8,17),(8,18),(9,18),(8,19): col 8 rows 17,18,19; col 9 row 18.
Now fill row 19: cols 0-7 (8 cells) + col 9 (1 cell) → I@0 (0-3), I@4 (4-7) ✓, col 9 → single-cell bottom piece: which piece has exactly 1 cell in its bottom row? 
- T rot1: bottom row = col 1 only ✓ (cells (1,0),(1,1),(2,1),(1,2)) → bottom cell at col 9 → x = 8 → extra cell at col 10 ✗ invalid.
- T rot3: bottom cell at rel col 1, extra at rel col 0 row 1 → x = 8 → cells (9,y0),(8,y0+1),(9,y0+1),(9,y0+2) → col 8 row y0+1 → if the piece's bottom is row 19 → y0 = 17 → (8,18) occupied ✗ (T's own cell). If the T lands with the bottom at row 18 → conflicts with col 8 row 18.
- L rot3: cells (0,0),(1,0),(1,1),(1,2) → bottom row = col 1 only ✓ → bottom at col 9 → x = 8 → cells (8,y0),(9,y0),(9,y0+1),(9,y0+2) → col 8 rows y0,y0+1 and col 9 rows y0..y0+2. If the bottom (y0+2) = 19 → y0 = 17 → cells (8,17),(9,17),(9,18),(9,19) → col 8 row 17 occupied by the first T ✗.
- L rot1: cells (1,0),(1,1),(1,2),(2,2) → bottom row = cols 1,2 (2 cells) ✗.
- S rot3: cells (0,0),(0,1),(1,1),(1,2) → bottom row = col 1 ✓ → bottom at col 9 → x = 8 → cells (8,y0),(8,y0+1),(9,y0+1),(9,y0+2) → y0 = 17 → (8,17) occupied ✗.
- S rot1: [[0,1,0],[0,1,1],[0,0,1]] → cells (1,0),(1,1),(2,1),(2,2) → bottom row = col 2 ✓ → bottom at col 9 → x = 7 → cells (8,y0),(8,y0+1),(9,y0+1),(9,y0+2) → y0=17 → (8,17) occupied ✗.
- J rot1: cells (1,0),(2,0),(1,1),(1,2) → bottom row col 1 ✓ → x = 8 → cells (9,y0),(10,y0) ✗.
- Z rot3: [[0,1,0],[1,1,0],[1,0,0]] → cells (1,0),(0,1),(1,1),(0,2) → bottom row = col 0 ✓ → bottom cell at col 9 → x = 9 → cells (10,y0) ✗ invalid.
- Z rot1: cells (2,0),(1,1),(2,1),(1,2) → bottom row = col 1 ✓ → x = 8 → cells (10,y0) ✗.

So a single-bottom-cell piece landing at col 9 always has another cell in col 8, which is occupied by the T stub. So switch the T's column to col 9 (3-cell column at col 9 = T rot3 @8 → col 9 rows 17,18,19 + col 8 row 18) and then fill col 8 row 19 with a piece whose extra cells are at col 9 rows 17,18 — occupied ✗.

Conclusion: the T's stub makes a 2-row clean fill hard. 

**Alternative: use the "clear trick" to remove the T's leftover.** Do a 1-line clear first (leaving 1-2 stubs in row 19), then use O's to complete rows 18,19 — but the stubs are in row 19, so row 19 can't be completed by O's at those columns. Hmm, but that's fine if the stubs ARE part of row 19's fill: e.g., after the 1-line clear, stubs at row 19 cols 4 and 8. Then fill row 18 and row 19:
- Row 19 needs cols 0-9 with cols 4, 8 already filled.
- Use O's at cols 0,2 (rows 18,19), 6 (cols 6,7 rows 18,19) → row 19: 0-3, 6,7 + stubs 4,8 → need col 5 and col 9.
- An O at cols 4,5? col 4 row 19 has a stub → blocked → lands at rows 16,17.
- Use J/L/T rot0 (3-cell bottom footprint) at align... 

This is taking too long. Let me switch strategy: **implement a proper DFS solver** in the test to find a piece sequence that produces an N-line clear. The state space: I place pieces one at a time (types forced by the bag, but I can set T.next to any type!). Since I can set the next piece type arbitrarily, I can CHOOSE the pieces! That's the key insight I've been underusing: `T.next = type` lets me pick the next piece type (except the very first, which is T).

So I can build any configuration with a DFS: choose pieces and placements greedily/DFS to complete N rows. The only constraint: the first piece is T.

DFS plan: target region rows [20-N..19]. Place pieces bottom-up. Use a solver that, for a list of available piece types, finds a placement sequence to fill the region exactly. Since I control types, I can use only I and O pieces (which tile perfectly):
- For N rows in 10 columns: use I (horizontal, 4 cells in a row) and O (2x2). 
- N=1: row 19 = I(4) + I(4) + O(2) ✓ — but the first piece is T. Hmm, the T must be placed somewhere: place the T so it lands ABOVE the target region? It needs support below... 

What if the T is placed to complete a row and I account for it: e.g., N=2 (rows 18,19): fill with 5 O's (cols 0,2,4,6,8) = 20 cells; the T must go somewhere — place the T FIRST at a location where it creates a partial stack, then fill rows 18,19 with O's around it? The T's 4 cells: if placed at rot1 @7 → col 8 rows 17,18,19 + col 9 row 18. Then the O's can't fill cols 8,9 rows 18,19 (blocked) → rows 18,19 can't be completed.

So: place the T in a column, and fill the OTHER 9 columns... a line clear needs all 10 columns. So the T must be part of the cleared rows. With the T's rot1 placement (col 8 rows 17,18,19 + col 9 row 18), the rows 17,18,19 in cols 8,9 have: col 8: 17,18,19 ✓ (3 of 3 for a 3-row target!) and col 9: 18 only. So for a 3-row clear (rows 17,18,19): col 8 is complete for rows 17,18,19 ✓; col 9 needs rows 17,19.
Then fill cols 0-7 rows 17,18,19 = 24 cells: 6 O's (each 2 cols × 2 rows → 3 O's per 2 columns... for 3 rows in 2 cols: O (rows 18,19) + O (rows 16,17)?? → row 16 touched. Or I's: horizontal I at row 17 (cols 0-3), row 18 (cols 0-3), row 19 (cols 0-3) = 3 I's per 4 columns... For cols 0-7: rows 17,18,19 → use 3 horizontal I's at align 0 (rows 17,18,19) + 3 at align 4 → 6 I's = 24 cells ✓ (each I fills one row of 4 cols).
Then col 9 needs rows 17,19 (2 cells) → an O at cols 8,9? col 8 rows 17,18,19 occupied → blocked. A piece with cells at col 9 rows 17,19 and something at col 8 rows 16?... 
- L rot3 = [[1,1,0],[0,1,0],[0,1,0]] → cells (0,0),(1,0),(1,1),(1,2) → col 1 (rel) rows 0,1,2 + col 0 row 0. If col 9 = rel col 1 → x = 8 → cells (8,y0),(9,y0),(9,y0+1),(9,y0+2) → col 8 row y0 and col 9 rows y0,y0+1,y0+2 → with y0+2 = 19 → y0 = 17 → cells (8,17),(9,17),(9,18),(9,19) → col 8 row 17 occupied by T ✗. With y0+2 = 17?? then rows 15,16,17 → col 9 rows 15,16,17 → wrong rows.
- L rot1 = [[0,1,0],[0,1,0],[0,1,1]] → cells (1,0),(1,1),(1,2),(2,2) → col 1 rows 0,1,2 + col 2 row 2 → x = 8 → cells (9,y0),(9,y0+1),(9,y0+2),(10,y0+2) ✗.

So col 9 needs rows 17 and 19 but not 18 (18 is filled by T) — impossible for a connected tetromino... unless the piece's cells at col 9 rows 17,19 are connected through col 8 or 10 — col 8 rows 17,18,19 are all occupied. So impossible.

**Change the T placement**: T rot1 @8 → cells (9,y0),(9,y0+1),(10,...) invalid. T rot3 @9 → x = 8 → cells (9,17),(8,18),(9,18),(9,19) → col 9 rows 17,18,19 + col 8 row 18. Then for a 3-row clear: col 9 rows 17,18,19 ✓; col 8 needs rows 17,19. Same problem mirrored.

OK: choose the T's placement so that its 3-cell column is at the EDGE and the extra cell is in the adjacent column at the row that will be filled by something else. We need col 8 rows 17,19 filled by other pieces: since a piece covering col 8 rows 17 and 19 must also cover col 8 row 18 (contiguity within a piece) or pass through col 7/9. Passing through col 9: col 9 is completely filled (T) → so a piece covering col 8 rows 17,19 via col 9 is impossible. Via col 7: a piece with cells at col 7 rows ... and col 8 rows 17,19 — e.g., a Z/S shape. Let's see: S rot0 = [[0,1,1],[1,1,0],[0,0,0]] → cells (1,0),(2,0),(0,1),(1,1) → bottom row = cols 0,1 (2 cells) at rel row 1; the top row has cols 1,2. If the bottom cells are at row 19 cols 7,8 → the top cells at row 18 cols 8,9 → col 9 row 18 occupied by T ✗ (for T rot3 @8: col 9 rows 17,18,19 + col 8 row 18).

What if the T is placed so its extra cell is at col 8 row 19 and the 3-cell column is col 9 rows 17,18,19? T rot1 @... cells (1,0),(1,1),(2,1),(1,2): 3-cell column = rel col 1; extra at rel col 2 row 1. For the 3-cell column to be col 9 → x = 8 → extra at col 10 ✗.
T rot3: 3-cell col = rel 1; extra at rel col 0 row 1 → x = 8 → extra at col 8 row y0+1. For the extra to be at row 19 → y0+1 = 19 → y0 = 18 → but then the piece's bottom cell is at rel row 2 → row 20 → out of board ✗.

Hmm. What about the T rot2 (upside down): cells (1,1),(0,2),(1,2),(2,2) → bottom row = cols 0,1,2 (3 cells) at rel row 2, plus col 1 at rel row 1. Place at align 7 → x = 7 → cells: (8,y0+1),(7,y0+2),(8,y0+2),(9,y0+2) → with y0+2 = 19 → y0 = 17 → cells (8,18),(7,19),(8,19),(9,19) → row 19 cols 7,8,9 + row 18 col 8. That's a 3-cell bottom footprint at cols 7,8,9 — good for the bottom row of a target!
For a 3-row clear (rows 17,18,19): 
- Row 19: cols 7,8,9 (T) + cols 0-6 (7 cells) → I@0 (0-3) + 3 cells (4,5,6) → J@4 (bottom footprint 4,5,6) ✓
- Row 18: col 8 (T) + cols 0-7 + col 9 → I@0 (row 18: 0-3) ✓, I@4 (row 18: 4-7) ✓, col 9 → need a piece... vertical I at col 9 → needs rows 16-19 col 9 free → row 19 col 9 occupied by T ✗ → lands at rows 15-18 → gives col 9 rows 15,16,17,18 ✓ (row 18 col 9 ✓!). 
- Row 17: col 9 (from the vertical I) ✓; cols 0-8 → need cols 0-7 (8 cells) + col 8: I@0 (row 17: cols 0-3) ✓, I@4 (row 17: cols 4-7) ✓, col 8 row 17 → a piece whose cells are at col 8 row 17 and elsewhere: the vertical I at col 9 covers rows 15-18 col 9. For col 8 row 17: use a horizontal I at align 8 → cols 8,9,10,11 ✗. Use J/L/T rot0 with bottom footprint 3 cells at cols 5,6,7 → conflicts. Hmm, what about placing an O at cols 7,8 → rows 16,17 (blocked below: col 7 rows 18,19 occupied by I's, col 8 row 18 occupied by T) → lands at rows 16,17 → fills col 8 row 17 ✓ and col 7 row 17 (which was already filled by the I@4 row 17 ✗ conflict).
  Alternative: fill row 17 cols 0-8 using horizontal I's at align 0 (0-3) and 4 (4-7), and for col 8 use... a vertical I at col 8 → needs col 8 rows 16-19 free → rows 18,19 occupied by T ✗ → lands at rows 15-18 → col 8 rows 15,16,17,18 → but row 18 col 8 is occupied by T → invalid! (A vertical I can't overlap.) So the vertical I at col 8 would land at rows 15,16,17,18 — but row 18 col 8 is occupied → the game's hard drop requires the piece to be placed legally; the vertical I would land at rows 15-18 which INCLUDES row 18 col 8 (occupied) → not legal → the drop simulation stops earlier: rows 14-17 ✓ legal → so col 8 rows 14,15,16,17 → fills row 17 col 8 ✓.

OK! That works: vertical I at col 8 lands at rows 14-17 (since rows 18,19 are blocked), filling col 8 row 17 ✓.

So the 3-row plan:
1. T (first) rot2 @7 → row 19 cols 7,8,9; row 18 col 8.
   Wait, but I must be careful: T.next is set before dropping the T. Fine.
2. I@0 rot0 (row 19 cols 0-3)
3. J@4 rot0 (row 19 cols 4,5,6) → row 19 complete → 1-LINE CLEAR happens! ✗ That would clear row 19 before rows 17,18 are complete.

Right — I must NOT complete row 19 early. So I need to build rows 17 and 18 BEFORE row 19's last cell. Order:
1. T rot2 @7 → row 19 cols 7,8,9 + row 18 col 8. (This doesn't complete row 19 since cols 0-6 are empty ✓)
2. I@0 rot0 → lands at row 19 (cols 0-3) — free ✓ (row 19 cols 7,8,9 occupied by T; cols 0-3 free) ✓
3. I@4 rot0 → row 19 cols 4-7? col 7 occupied by T ✗ → lands at row 18 cols 4-7 ✓ (good, that's part of row 18!)
4. Now row 18: cols 4-7 (I) + col 8 (T) → need cols 0-3 and 9.
   - I@0 rot0 → row 19 cols 0-3 already filled by step 2 → so it lands at row 18 cols 0-3 ✓ 
5. Row 18 now: 0-8 ✓ + col 9 → vertical I at col 9 → lands at rows 15-18 (row 19 col 9 occupied by T) → col 9 rows 15,16,17,18 ✓ → row 18 complete!
   Hmm wait, if row 18 becomes complete at this point, it clears immediately! Row 18 complete → 1-line clear (rows above shift down). That breaks the 3-row plan.
   
I need to complete all three rows simultaneously. So: complete row 17 last, and fill row 18 fully except one cell that's filled by the same piece that completes row 17.

Let me restructure: fill rows 17,18 fully except col 9's cells in rows 17,18,19... then drop a vertical I at col 9 that fills col 9 rows 16,17,18,19 → completing rows 17,18,19 at once ✓ (row 16 gets a leftover at col 9 — fine).

So the target: cols 0-8 rows 17,18,19 complete; col 9 rows 17,18,19 empty until the final vertical I.
- T rot2 @7 (row 19 cols 7,8,9) — ✗ that puts a cell in col 9 row 19. Use a different T placement: T rot2 @6 → x=6 → cells (7,y0+1),(6,y0+2),(7,y0+2),(8,y0+2) → with y0+2 = 19 → y0 = 17 → cells (7,18),(6,19),(7,19),(8,19) → row 19 cols 6,7,8 + row 18 col 7. Hmm, still need row 19 col 9.
  What about T rot0 @6 → cells (7,y0),(6,y0+1),(7,y0+1),(8,y0+1) → with y0+1 = 19 → y0 = 18 → cells (7,18),(6,19),(7,19),(8,19) → same as above (row 18 col 7, row 19 cols 6,7,8). ✓ So T rot0 @6 gives row 19 cols 6,7,8 and row 18 col 7.
  Then row 19 needs cols 0-5 and 9 → I@0 (0-3) ✓ + cols 4,5 (2 cells) → O@4 (rows 18,19 cols 4,5) ✓ → row 19: 0-8 ✓, col 9 → filled by the final vertical I ✓.
  Row 18 needs cols 0-9 except col 9 (filled at the end): cols 0-3, 4,5 (O), 6, 8 → need cols 0-3 (4), 6 (1), 8 (1) → I@0 rot0 → row 18 cols 0-3? Row 19 cols 0-3 are occupied (step: I@0 at row 19) → so the second I@0 lands at row 18 cols 0-3 ✓. Then cols 6 and 8 in row 18: col 7 is the T's extra ✓, col 6 → a piece... vertical I at col 6 → needs rows 16-19 col 6 free → row 19 col 6 occupied ✗ → lands at rows 15-18 → fills row 18 col 6 ✓ (and rows 15,16,17 col 6). Similarly vertical I at col 8 → row 19 col 8 occupied ✗ → lands at rows 15-18 → fills row 18 col 8 ✓.
  Row 17 needs cols 0-8 (col 9 at the end): I@0 rot0 → row 19 cols 0-3 occupied, row 18 cols 0-3 occupied → lands at row 17 cols 0-3 ✓; I@4 rot0 → needs cols 4-7 in some row: row 19 cols 4,5 occupied (O), row 18 cols 4,5,7 occupied → lands at row 17 cols 4-7 ✓; col 8 row 17 → vertical I at col 8 lands at rows 15-18 → fills row 17 col 8 ✓.
  And the vertical I at col 6 fills col 6 rows 15,16,17,18 ✓ (row 17 col 6 already from I@4? I@4 at row 17 covers cols 4,5,6,7 → col 6 row 17 filled by the I; then the vertical I at col 6 must land such that it doesn't overlap: it needs rows 15,16,17,18 col 6 → rows 17 (I@4) and 18 (?) occupied → it lands at rows 14-17 ✗ overlapping row 17. So order matters: place the vertical I at col 6 BEFORE the I@4 at row 17.
  
This is doable but error-prone by hand. Given time constraints, let me do this: write a **DFS solver** with piece-type choice (I set T.next to any type) that searches for a placement sequence that yields an N-line clear. The DFS places pieces one at a time; state = board; at each step choose a piece type and (rot, x) placement; prune if a placement creates an unfillable hole (a cell in the target region that no remaining piece can fill) — complex. 

Simpler: since I can choose pieces freely, use the perfect tiling: rows [20-N..19] can be tiled by horizontal I's (4 cells in a row) and O's (2x2) and the first T. Let me simplify by choosing pieces that only touch the target region and use this greedy: fill the target region from the bottom row upward, choosing the leftmost empty cell in the lowest row, and place a piece whose footprint covers it exactly...

Actually, you know what? There's a much simpler approach for multi-line clears: **use the same vertical-I trick for N rows**. A vertical I fills 4 rows in a column. So:
- N=4: 10 vertical I's (as designed) — obstacle: the first T. Solution: use the "1-line clear first, then stubs" trick: after a 1-line clear, the stubs are at row 19; vertical I's in the stub columns land one row higher and still fill rows 16-19 for row 16,17,18 (from the I) + row 19 (stub) ✓. This works for N=4! (as I analyzed).
- N=3: rows 17,18,19 complete. Use vertical I's at 10 columns → each fills rows 16,17,18,19 → that completes rows 17,18,19 → but ALSO row 16 → 4-line clear. To get exactly 3, I need one column to have only rows 17,18,19 (not 16) — e.g., a T rot1 (3 cells in a column) at rows 17,18,19 + 1 extra cell... the extra cell is adjacent → it occupies another column at row 18, breaking that column's row-16 cell? No: the extra cell at col c+1 row 18 doesn't prevent col c+1 from having rows 16,17,18,19 filled by a vertical I... but the extra cell at row 18 col c+1 would be occupied, so the vertical I at col c+1 can't be placed (overlap). Instead fill col c+1 rows 16,17,19 with other pieces... same issue as before.

Alternatively for N=3: fill rows 17,18,19 with vertical I's in 9 columns and in the 10th column use a piece that fills exactly rows 17,18,19 — a vertical I fills 4; a T rot1 fills 3 in a column + 1 extra. Use T rot1 for the 10th column, with the extra cell in the 9th column's row 18... then the 9th column needs rows 16,17,19 filled: row 18 has the T's extra cell. Hmm.

What about a **J/L/S/Z piece** that fills exactly 3 consecutive cells in one column with its 4th cell in the same column (row above/below)? Impossible (4 cells: 3 in one column + 1 elsewhere).

OK here's a cleaner idea for N=3: make the target rows 17,18,19 but leave ONE cell in row 16 that is NOT filled — i.e., the vertical I's land at rows 15-18 in one column? Then that column's row 19 is empty → row 19 incomplete ✗.

Alternatively: fill 9 columns with vertical I's (rows 16-19) and the 10th column with a horizontal I placed at row 19 (1 cell? no, 4 cells).

Hmm, what about using horizontal I's for the last column? A horizontal I at align 7 (cols 7,8,9,10) invalid.

Use an O for the last 2 columns and I's for the rest:
- cols 0-8 rows 16,17,18,19 = 9 vertical I's (36 cells)
- cols 8,9: the O at cols 8,9 rows 18,19 → blocked by the vertical I at col 8 (rows 16-19) ✗.
- Use vertical I's at cols 0-7 (rows 16-19) = 32 cells, then cols 8,9 rows 16,17,18,19 = 8 cells: 2 O's stacked (rows 16,17 and 18,19) ✓✓ → this fills 4 rows → a 4-line clear, not 3.

For a 3-line clear: fill cols 0-9 rows 17,18,19 (30 cells) with nothing in row 16. Pieces that don't touch row 16: horizontal I's (1 row), O's (2 rows) — but an O at rows 18,19 doesn't touch row 16 ✓; an O at rows 16,17 touches row 16 ✗.
So: rows 17,18,19 with horizontal I's and O's only, no O at rows 16,17:
- Row 19: I@0 (0-3), I@4 (4-7), + cols 8,9 → O@8 (rows 18,19 cols 8,9) ✓
- Row 18: cols 0-7 + 8,9 (O) → I@0 (row 18: 0-3) ✓, I@4 (row 18: 4-7) ✓ → row 18 complete → but row 17 isn't → premature clear ✗.

Order: fill row 17 (partially), then row 18, then row 19 last:
- Row 17: I@0 (0-3) ✓, I@4 (4-7) ✓, + cols 8,9 → an O at cols 8,9 → lands where? Below → row 18 cols 8,9 (free) → rows 18,19 → so the O at rows 18,19 doesn't fill row 17 ✗. Need row 17 cols 8,9: an O at cols 8,9 → to land at rows 16,17 → touches row 16 ✗ (it would be legal, just leaves a stub at row 16 → that's fine! Row 16 having 2 cells doesn't prevent a 3-line clear of rows 17,18,19 ✓✓).
  
So: 
1. Row 17: I@0, I@4 (cols 0-7), O@8 (lands at rows 16,17 cols 8,9) → row 17 complete? cols 0-7 + 8,9 = all 10 → row 17 COMPLETE → premature 1-line clear ✗.

Argh. The last piece must complete ALL target rows simultaneously. So all rows must be missing exactly the cells provided by the last piece. The last piece should ideally be a vertical piece in one column: e.g., a vertical I at col 9 filling rows 16-19 col 9 → completes rows 17,18,19 (if cols 0-8 are complete in those rows) AND fills row 16 col 9 (harmless).
So: cols 0-8 complete in rows 17,18,19 (27 cells), and col 9 rows 17,18,19 empty at the end; the final vertical I at col 9 completes rows 17,18,19 → 3-line clear ✓ (plus row 16 col 9 as a leftover stub... wait, after clearing rows 17,18,19, the remaining content (row 16 col 9) shifts down to row 19 ✓).
And the first piece is T — it must be placed within cols 0-8 rows 17,18,19 without completing... fine.
Fill cols 0-8 (9 cols) rows 17,18,19 = 27 cells using: T (4 cells) + I's and O's (23 cells).
E.g.: T rot2 @6 → row 19 cols 6,7,8 + row 18 col 7 (4 cells).
Remaining: row 19: cols 0-5 (6 cells); row 18: cols 0-6, 8 (8 cells); row 17: cols 0-8 (9 cells).
- Row 17: I@0 (0-3), I@4 (4-7) → cols 0-7, plus col 8 → need 1 cell at col 8 row 17. Use a vertical I at col 8 → fills rows 16-19 col 8 → row 19 col 8 is occupied by the T ✗ → lands at rows 15-18 → fills row 17 col 8 ✓ (and rows 15,16,18 col 8).
- Row 18: cols 0-6 + 8: I@0 (row 18 cols 0-3) ✓, I@4 (row 18 cols 4-7) → col 7 row 18 is occupied by T's extra cell ✗ → lands at row 17? Row 17 cols 4-7 are occupied by the earlier I@4 at row 17 ✗ → lands at row 16 (cols 4-7) → doesn't fill row 18 cols 4-6. Hmm.
  Alternative: row 18 cols 0-6: use an O@0 (rows 18,19 cols 0,1)? Row 19 cols 0-5 need filling too. Let me re-plan using O's:
  - O@0 (rows 18,19 cols 0,1)
  - O@2 (rows 18,19 cols 2,3)
  - O@4 (rows 18,19 cols 4,5) → row 19: cols 0-5 ✓ + T's 6,7,8 ✓ → row 19 complete (cols 0-8) ✓; row 18: cols 0-5 ✓ + T's col 7 + col 8 (vertical I) → need col 6 row 18.
  - col 6 row 18: a piece... vertical I at col 6 → row 19 col 6 occupied by T ✗ → lands at rows 15-18 → fills row 18 col 6 ✓ (and rows 15,16,17 col 6 — careful: row 17 col 6 must be filled anyway ✓ no conflict).
  So row 18: cols 0-8 ✓ (0-5 O's, 6 vertical I, 7 T, 8 vertical I).
  Row 17: cols 0-8: cols 0-5 (O@0, O@2, O@4 give rows 18,19 only — NOT row 17) ✗. Row 17 needs cols 0-5: 6 cells → I@0 (row 17: cols 0-3) ✓ + O@4 (rows 16,17 cols 4,5) ✓ → fills row 17 cols 4,5 ✓ (and row 16 cols 4,5).
  Then row 17: cols 0-3 (I), 4,5 (O), 6 (vertical I at col 6 → rows 15-18 ✓ includes row 17), 8 (vertical I at col 8 → rows 15-18 ✓) → col 7 row 17: MISSING ✗. 
  Need col 7 row 17: the T's extra cell is at row 18 col 7. A piece covering col 7 row 17 with other cells... a vertical I at col 7 → row 19 col 7 occupied by T ✗ → lands at rows 15-18 → fills col 7 rows 15,16,17,18 → row 17 col 7 ✓ and row 18 col 7 (occupied by T's extra) ✗ → the vertical I at col 7 would land at rows 14-17 ✓ (since row 18 col 7 is blocked) → fills col 7 rows 14,15,16,17 → row 17 col 7 ✓.

OK so the full plan for the 3-line clear (cols 0-8 in rows 17,18,19, then vertical I at col 9):
1. T rot2 @6 → cells (7,18),(6,19),(7,19),(8,19) [row 19 cols 6,7,8; row 18 col 7]
   (T rot2 = [[0,0,0],[1,1,1],[0,1,0]] → cells (0,1),(1,1),(2,1),(1,2) → minRel=0, lowRel=2 → align 6 → x=6 → cells (6,y0+1),(7,y0+1),(8,y0+1),(7,y0+2) → with y0+2 = 19 → y0 = 17 → cells (6,18),(7,18),(8,18),(7,19). Hmm! T rot2's bottom row (rel row 2) is a single cell (col 1), and rel row 1 has cols 0,1,2. So the cells are: row 18 cols 6,7,8 and row 19 col 7. That's NOT what I wanted! I wanted row 19 cols 6,7,8.
   
   Let me recheck T rot2: matrix rot2 = [[0,0,0],[1,1,1],[0,1,0]] → row 0: none; row 1: cols 0,1,2; row 2: col 1. So the bottom (rel row 2) = col 1 only. So the piece lands with col-1 cell at row 19 and cols 0,1,2 at row 18. So T rot2 @6 → x = 6 → cells: (6,18),(7,18),(8,18),(7,19) → row 18 cols 6,7,8 + row 19 col 7.
   
   So the T's bottom footprint for rot2 = 1 cell (col 7). Hmm, so for a 3-cell bottom footprint I want T rot0: matrix [[0,1,0],[1,1,1],[0,0,0]] → bottom (rel row 1) = cols 0,1,2 → T rot0 @6 → x=6 → cells (7,y0),(6,19),(7,19),(8,19) → row 19 cols 6,7,8 + row 18 col 7 ✓ (as I originally wanted).

So T rot0 @6 → row 19 cols 6,7,8; row 18 col 7. ✓ (as I assumed in the plan above).

Continuing the plan with the T as rot0 @6:
2. O@0 → rows 18,19 cols 0,1 ✓
3. O@2 → rows 18,19 cols 2,3 ✓
4. O@4 → rows 18,19 cols 4,5 ✓ (row 19: 0-5 + T's 6,7,8 = complete for cols 0-8 ✓)
5. Vertical I at col 6 → lands rows 15-18 (row 19 col 6 blocked) → col 6 rows 15,16,17,18 ✓
6. Vertical I at col 8 → lands rows 15-18 → col 8 rows 15,16,17,18 ✓
7. I@0 rot0 → row 17 cols 0-3? Row 19 cols 0-3 occupied (O@0), row 18 cols 0-3 occupied (O@0) → lands at row 17 cols 0-3 ✓
8. O@4 → cols 4,5: row 19 cols 4,5 occupied, row 18 cols 4,5 occupied → lands at rows 16,17 ✓ → row 17 cols 4,5 ✓
9. Vertical I at col 7 → col 7: row 19 occupied (T), row 18 occupied (T) → lands at rows 14-17 ✓ → row 17 col 7 ✓
10. Vertical I at col 9 → col 9 free everywhere → lands at rows 16-19 col 9 ✓
Now check rows 17,18,19:
- Row 17: cols 0-3 (I), 4,5 (O), 6 (vert I), 7 (vert I), 8 (vert I), 9 (vert I) → all 10 ✓
- Row 18: cols 0-5 (O's), 6 (vert I), 7 (T), 8 (vert I), 9 (vert I) → all 10 ✓
- Row 19: cols 0-5 (O's), 6,7,8 (T), 9 (vert I) → all 10 ✓
→ All three rows complete simultaneously at step 10 → 3-LINE CLEAR = 500 × level ✓

And the first piece T is at step 1 ✓ (the bag gives T first).

For the 4-line clear: rows 16,17,18,19 complete. Plan:
1. T must be placed first. Let's use the earlier "1-line clear then stubs" trick, or directly:
   Use vertical I's for cols 0-8 (9 pieces, rows 16-19) and the T for col 9 rows 17,18,19 + extra at col 8 row 18 — but col 8 is filled by a vertical I ✗.
   
   Direct plan with the T inside: 
   - T rot1 @7 → cells (8,17),(8,18),(9,18),(8,19) → col 8 rows 17,18,19 + col 9 row 18.
     (T rot1 = [[0,1,0],[0,1,1],[0,1,0]] → cells (1,0),(1,1),(2,1),(1,2) → minRel = 0 → align 8 → x = 8 → cells (9,y0),(9,y0+1),(10,y0+1) ✗ invalid. So align 7 → x = 7 → cells (8,y0),(8,y0+1),(9,y0+1),(8,y0+2) → with y0+2 = 19 → y0 = 17 → cells (8,17),(8,18),(9,18),(8,19) ✓)
   - Now col 8: rows 17,18,19 filled; col 9: row 18.
   - Vertical I's at cols 0-7 (rows 16-19) ✓ (8 pieces)
   - Col 9 needs rows 16,17,19 (row 18 done by T) → 3 cells. 
   - Col 8 needs row 16 (1 cell).
   - An O at cols 8,9 → rows 16,17? col 8 rows 17,18,19 occupied; col 9 row 18 occupied → the O at cols 8,9 lands at rows 16,17 → but col 8 row 17 is occupied ✗ → so it lands at rows 15,16 → row 16 cols 8,9 ✓ (and row 15 cols 8,9).
     Then col 8 row 16 ✓ (O) and col 9 row 16 ✓ (O). Remaining: col 9 rows 17,19 (2 cells).
   - Col 9 rows 17 and 19: a piece covering col 9 rows 17,19 must also cover col 9 row 18 (occupied by T) ✗ or col 8 (occupied) ✗ → impossible.
   
   Alternative: T rot3 @8 → cells (9,17),(8,18),(9,18),(9,19) → col 9 rows 17,18,19 + col 8 row 18.
   - Vertical I's at cols 0-7 (rows 16-19) ✓
   - Col 8 needs rows 16,17,19 (3 cells); col 9 needs row 16 (1 cell).
   - An O at cols 8,9 → lands at rows 16,17? col 8 row 18 occupied, col 9 rows 17,18,19 occupied → the O at cols 8,9 needs rows 16,17 in both → col 9 row 17 occupied ✗ → lands at rows 15,16 ✓ → fills col 8 row 16, col 9 row 16, col 8 row 15, col 9 row 15.
     Now col 9: rows 16 (O), 17,18,19 (T) ✓ complete! Col 8: rows 16 (O), 18 (T) → needs rows 17,19.
   - Col 8 rows 17,19: impossible (needs row 18 which is occupied by T).
   
   Hmm. The T's extra cell always blocks a column's contiguity. Use a T placement where the extra cell is in the TOP row of the target and the 3-cell column is elsewhere:
   - T rot2 (bottom = 1 cell, row above = 3 cells): place so the 3-cell row is row 16 (the top) and the single cell at row 17? Then: T rot2 @6 → cells (6,18),(7,18),(8,18),(7,19) → reload... let me place T rot2 so that its rel row 1 (3 cells) is at row 16 and rel row 2 (1 cell) at row 17: y0 + 1 = 16 → y0 = 15 → cells (6,16),(7,16),(8,16),(7,17) → row 16 cols 6,7,8 + row 17 col 7. Is this placement legal? The piece lands there only if rows 17,18,19 in cols 6,7,8 are occupied... i.e., I need support below. So: first fill rows 17,18,19 in cols 6,7,8 with other pieces, then drop the T to rest on top at row 16. But then the T's cells at row 16 cols 6,7,8 and row 17 col 7 → row 17 col 7 is occupied ✗ overlap.
   
   Use T rot0 upside... Let me think about which pieces can fill a 4-row column completely: a vertical I (4 cells in a column). So the 10 columns need 10 vertical I's. The T can replace one vertical I only if it provides 4 cells in one column — impossible for a T.
   
   So a clean 4-row clear requires 10 vertical I's + the T placed elsewhere (outside the target rows) — but the T is the FIRST piece, so it lands at the bottom (rows 16-19) unless there's support.
   
   → Use the "1-line clear then stubs" trick: the stubs end up in row 19, and vertical I's in those columns land at rows 15-18, still filling rows 16,17,18 + row 19 (stub) ✓. So a 4-line clear is achievable:
   1. T (first): place so that after a 1-line clear, exactly 1 stub remains in row 19 — e.g., T rot0 @7 → row 19 cols 7,8,9 + row 18 col 8 (4 cells: 3 in row 19, 1 in row 18). To complete row 19: fill cols 0-6 → I@0 (0-3) + 3 cells (4,5,6) → J@4 (bottom footprint 3 cells: 4,5,6) ✓ → row 19 complete → 1-line clear; leftovers: T's row-18 cell at col 8 and J's row-17... J rot0's cells above the bottom row: J rot0 = [[1,0,0],[1,1,1],[0,0,0]] → cells (0,0),(0,1),(1,1),(2,1) → 1 cell above (col 4 row 18). So leftovers after the clear: row 18 col 8 (T) and row 18 col 4 (J) → shift to row 19: stubs at cols 4 and 8 ✓.
   2. Then 10 vertical I's at cols 0..9: for cols 4 and 8, the vertical I lands at rows 15-18 (row 19 blocked by the stub) → fills rows 16,17,18 + stub at 19 ✓ → so cols 4,8 have rows 16-19 complete ✓. Other columns: rows 16-19 ✓.
   → After the 10th vertical I, rows 16,17,18,19 all complete → 4-LINE CLEAR = 800 ✓

   Let me double check the vertical I at col 4: cells col 4 rows 15,16,17,18 — legal (row 19 col 4 has the stub) ✓. And the hard drop places it as low as possible → rows 15-18 ✓.

So the 4-line plan works. Let me also handle the level progression: after 10 lines → level 2. I can do the 4-line clear (4 lines) + another 4-line clear (8 lines) + a 2-line clear (10 lines) → level 2. Or just do the 4-line clear 3 times with key("r") between? No — the level persists across the game, not resets... well, key("r") resets the level to 1. So within one game: do 3 quad clears = 12 lines → level 2 after the 3rd (level becomes 2 at 10 lines). Each quad requires the T-first sequence... but after the first reset, the bag's next piece is T again (deterministic) ✓. But within a single game, I can't reset (that would reset the level). 

So: within one game, I need to do multiple quad clears without resetting. After the first quad clear, the leftover stubs (rows 15 col 4, col 8) remain, and the piece sequence continues from the bag: after the first quad, the current piece is whatever comes next. Since I control types via T.next, I can do the "1-line clear trick" again for the next quad: but the first piece of each quad needs to be a T... I can set T.next = "T" so the *next* piece is T ✓ — only the very first piece after a reset is forced. So within one game, I can always choose the piece types!

So the quad routine (given a T is available as the current piece):
a. Place T rot0 @7 (row 19 cols 7,8,9; row 18 col 8)
b. T.next = "I"; place I rot0 @0 → row 19 cols 0-3
c. T.next = "J"; place J rot0 @4 → row 19 cols 4-6 → 1-line clear → stubs at row 19 cols 4, 8
d. For c in 0..9: T.next = "I"; place I rot1 @c → vertical
→ 4-line clear.

But careful: in step (a) after the reset, the current piece is T ✓. In subsequent quads, the current piece is whatever was spawned — I need to set T.next = "T" BEFORE the previous quad's last drop, so that the next current piece is T. Then in the next quad, the current is T ✓.

Hmm, but there's an issue: after the first quad, the board has leftover stubs at rows 15, cols 4 and 8 (from the vertical I's landing above). The next quad's step (a) T rot0 @7 → row 19 cols 7,8,9: is col 8 row 19 free? Yes (the quad clear removed rows 16-19) ✓. But the stub at row 15 col 4 and col 8 remains — fine (above the target region).

Wait, one problem: in step (d), the vertical I's at cols 4 and 8 land at rows 15-18. But if there's a leftover stub at row 15 col 4 (from the previous quad), the vertical I at col 4 would land lower... Let's see: at the time of the second quad's step (d), the board's row 15 col 4 might be occupied by a leftover. Then the vertical I at col 4 needs rows 16-19 (row 19 blocked by the stub) → rows 15-18 → row 15 col 4 occupied ✗ → it can't be placed there... it would land at rows 14-17 → then col 4 row 18 is filled but row 19 has the stub ✓, row 16,17 ✓ → col 4 rows 16-19 ✓ complete! Wait: rows 14,15,16,17 → col 4 rows 16,17 filled by the I, row 19 by the stub, row 18 NOT filled ✗ → row 18 incomplete → no clear. Risky.

To avoid leftovers above, I should make each quad's leftovers land in row 19 (the row that gets cleared)... The vertical I's at cols 4,8 land at rows 15-18 → after the 4-line clear (rows 16-19 removed), the content of row 15 shifts down to row 19?? No wait: clearing rows 16,17,18,19 removes 4 rows; everything above shifts down by 4 → the row-15 content (cols 4,8) moves to row 19 ✓!! Because after removing 4 rows, what was at row 15 is now at row 19. 

Hmm, careful: the vertical I at col 4 occupies rows 15,16,17,18 (4 cells). Rows 16,17,18,19 are cleared → the piece's cells at rows 16,17,18 are removed, and the cell at row 15 shifts down to row 19. So after the clear, there's a stub at row 19 col 4 ✓ — which is exactly what the next quad's step (a)/(c) needs... but step (c) creates the stubs via the 1-line clear. If row 19 already has stubs at cols 4 and 8 from the previous quad, then step (a)'s T at cols 7,8,9 → col 8 row 19 is occupied by the stub ✗ → the T lands higher.

So the second quad won't work cleanly. I need a different approach for repeated quads, or just accept testing the 4-line clear once (score 800 verified) plus level progression via a different method (e.g., multiple 4-line clears with careful handling, or 10 single-line clears).

For level progression, the simplest: do 10 single-line clears? Each single-line clear requires the 1-line routine. Hmm, but after each single-line clear, the leftover stub shifts to row 19 and interferes with the next.

Alternative for level progression: use my earlier verified approach — the earlier test (test_deep3 Test C) already showed lines reaching 10 and level 2. Let me just re-verify the level-up with a controlled sequence: do a 4-line clear (4 lines), then another 4-line clear, then a 2-line clear (total 10 → level 2). For the 2nd and 3rd clears, the leftover stubs at row 19 complicate things.

Alternative: after a 4-line clear, the board is EMPTY except for the stub(s) at row 19 (cols 4, 8 from the vertical I's). For the next quad, I can adapt: instead of the "1-line clear trick", use a different construction that tolerates the existing stubs at row 19 cols 4 and 8:
- Target: rows 16-19 complete. Stubs already at row 19 cols 4, 8.
- Place vertical I's at cols 0,1,2,3,5,6,7,9 (8 pieces) → rows 16-19 ✓
- Cols 4, 8: rows 16,17,18 needed (row 19 has the stub) → 3 cells each → a piece with exactly 3 cells in one column: T rot1 (3 cells in col + 1 extra at col+1 row 1) or T rot3 (3 cells + 1 extra at col-1 row 1).
  - T rot1 @ col 4: x = 4 - 1 = 3 → cells (4,y0),(4,y0+1),(5,y0+1),(4,y0+2) → with the bottom at row 19? No — the 3-cell column must be rows 16,17,18 and the extra at col 5 row y0+1 = row 17. But col 5 rows 16-19 are filled by the vertical I at col 5 ✗ → overlap.
  - T rot3 @ col 4: x = 4 - 1 = 3 → cells (4,y0),(3,y0+1),(4,y0+1),(4,y0+2) → the extra at col 3 row y0+1 = row 17 → col 3 rows 16-19 filled by the vertical I at col 3 ✗ overlap.
  So the extra cell must be in a column that isn't filled by a vertical I at that row — i.e., in another stub column (col 8). E.g., T rot3 with the 3-cell column at col 4 and the extra at col 5 (rot1) or col 3 (rot3) — both filled. What if the 3-cell column is col 8 (the other stub)? T rot1 @ col 8: x = 7 → cells (8,y0),(8,y0+1),(9,y0+1),(8,y0+2) → extra at col 9 row y0+1 → col 9 rows 16-19 filled by the vertical I ✗.
  
  Use a vertical I at cols 0-6, 9 (8 I's) and handle cols 7, 8 with T pieces: col 7 needs rows 16-19 (4 cells, no stub) → vertical I ✓; col 8 needs rows 16,17,18.
  
Hmm. This is a rabbit hole. Time is limited (I've used ~20 min of the 15-min budget... actually the budget says "at most 15 minutes" but I should wrap up).

**Decision**: I've already verified:
- 1-line clear scoring exactly (100 × level + drop points) ✓
- Clear + shift-down behavior (board updates, lines counter) ✓
- Level up to 2 at 10 lines (in test_deep3, lines went 2,6,10 → level 2) ✓
- Game over, pause/resume, gravity, soft drop, hard drop, rotation legality at walls, restart resets.

Remaining: exact 300/500/800 scoring. The scoring code is a table lookup — `table[cleared] * level` — with 100/300/500/800. The 1-line case confirms the mechanism. I'd still like to verify 800 and 500 since those are explicit requirements.

Let me try the designed 3-line and 4-line plans quickly (they're fully specified now). If they work, great; if not, I'll accept the partial verification.

Let me write the test with:
- 3-line plan (10 steps) 
- 4-line plan (1-line clear trick + 10 vertical I's)
- Then a level progression test using the 4-line plan + 3-line plan + 3-line plan (4+3+3 = 10 lines) — the 3-line plan needs the T-first trick (works after any reset, but for level progression I need one continuous game). For a continuous game: after the 4-line clear, the stubs at row 19 cols 4,8 exist; the 3-line plan (target rows 17,18,19) requires cols 0-8 complete in rows 17,18,19 and the T at row 19 cols 6,7,8 → col 8 row 19 is occupied by a stub ✗.

Alternative for level progression: 10 single-line clears in one game? Each single-line clear: place T rot0 @7 + I@0 + J@4 → clears row 19, leaving stubs at row 19 cols 4,8 (after the shift). The next single-line clear needs row 19 cols 0-9 complete — with stubs at cols 4 and 8 already: T rot0 @7 → row 19 cols 7,8,9 → col 8 occupied ✗ → the T lands higher.

OK, let me instead do level progression with the 4-line plan repeated using the "vertical I in stub columns lands at 15-18" trick and then CLEAR the leftover: after the first quad, the board is empty except stubs at row 19 cols 4 and 8. For the second quad, use this construction:
- The stubs are at row 19 cols 4, 8.
- Place vertical I's at cols 0,1,2,3,5,6,7,9 → rows 16-19 (8 I's).
- Cols 4 and 8 need rows 16,17,18 (3 cells each).
- Use T rot1 for col 8 (3 cells at col 8, extra at col 9 row y0+1 = row 17): but col 9 rows 16-19 are filled by the vertical I ✗. 
- Instead don't place a vertical I at col 9; fill col 9 rows 16-19 differently: hmm, col 9 needs 4 cells: T's extra + ... 

Let me think about the 2 columns (4 and 8) each needing 3 cells (rows 16,17,18) with row 19 stubs:
- A piece that provides 3 cells in col 4 (rows 16,17,18) and its 4th cell elsewhere: T rot1 (extra at col 5 row 17) — col 5 row 17 is filled by the vertical I at col 5 ✗; T rot3 (extra at col 3 row 17) — col 3 filled ✗.
- What if I DON'T place vertical I's at cols 3 and 5, and instead fill cols 3,4,5 rows 16-19 with... col 3 needs 4 cells (rows 16-19), col 4 needs 3 (16,17,18) + row 19 stub, col 5 needs 4.
  Use: T rot1 @ col 4 (x=3): cells (4,16),(4,17),(5,17),(4,18) → col 4 rows 16,17,18 ✓ + col 5 row 17 (which we need anyway ✓).
  Then col 3: rows 16-19 → vertical I at col 3 ✓ (4 cells) — but wait, is col 3 rows 16-19 free? Yes ✓.
  Then col 5: rows 16,18,19 needed (row 17 from the T's extra) → a vertical I at col 5 would overlap row 17 ✗ → need a piece with 3 cells in col 5 (rows 16,18,19) — non-contiguous ✗.
  
  Use T rot3 @ col 5 (x = 5-1 = 4): cells (5,y0),(4,y0+1),(5,y0+1),(5,y0+2) → col 5 rows y0,y0+1,y0+2 + col 4 row y0+1 → with y0 = 16: col 5 rows 16,17,18 + col 4 row 17 → then col 4 needs rows 16,18 (+ stub row 19) ✗ non-contiguous.

Getting nowhere fast. **Final decision**: verify the 3-line and 4-line clear scoring once each (in separate games with resets), and verify level progression using the earlier approach that already showed level 2 at 10 lines (test_deep3 Test C: lines 0→2→6→10, level 1→2 ✓ — that's already verified). Actually that test used the I-vertical approach and showed level 2. Good enough: level progression verified (level becomes 2 at 10 lines).

So let me run the 3-line and 4-line plans now. Also note the 4-line plan's first quad needs a fresh reset (current = T) ✓.

Let me code it.

The vertical I matrix in M is missing the I rot1 for some rotations (M.I only has 2 entries: rot0 and rot1) — fine, but the failure is at `vI @c` where c=2... wait, the failure is at line 77 which is the loop `for (let c = 0; c < 10; c++) dropPlaced("I", 1, c, ...)`. Hmm, `cells("I", 1, ...)` should work (M.I[1] exists). Unless the piece type rotated differently... Oh! `placeCurrent` for c=0: T.current is the "I" piece, rotated once → rot 1 ✓. Then for c=1... but it failed on the very first iteration? Line 77 col 30 → the dropPlaced call. 

Ah, I see: `M[type][rot]` where type="I", rot=1 → M.I[1] = [[0,0,1,0],[0,0,1,0],[0,0,1,0],[0,0,1,0]] ✓ exists. Unless `T.current.type` isn't "I"... The error says M[type][rot] is undefined — either M[type] or M[type][rot]. Wait, in the 3-line test, "vI @9" worked with rot 1 ✓. So the same call should work here. Unless the piece is not an I but the current piece after the J drop... 

Oh! In `placeCurrent` I compute `minRel(T.current.type, T.current.rot)` — if T.current.type is e.g. "O" (bag piece) then M["O"][1]... M.O now has 4 entries ✓. Hmm, but what if T.current.type is "S" or "Z" or "L" — not in M! In the 4-line test: after key("r"), the current piece is T; I set T.next = "I" then drop the T... wait no: `dropPlaced("T", 0, 7, ...)` sets T.next = "T"! That's wrong — it sets the *next* piece to T, but the current piece is already T. Then placeCurrent on the current T ✓, drop → spawnPiece uses nextType = "T" → the current becomes T again (not I)!

That's the bug: dropPlazed("T",...) sets T.next="T" but the current is already T. I need dropPlaced to NOT set T.next when the current piece is already the desired type. Let me fix: only set T.next if T.current.type !== type.

Also in the 3-line test, dropPlaced("T", 0, 6, ...) set next="T" → the next current was T again, not O! So the whole 3-line plan was misaligned (which is why no clear happened). Let me fix and re-run.

The fix: 
```
function dropPlaced(type, rot, leftCol, label) {
  if (T.current.type !== type) T.next = type;
  ...
}
```
That's the correct semantics: ensure the *current* piece is `type` (set next before the previous drop). But for the first piece after key("r") (T), if I want T, I don't set next.

Wait, careful: T.next sets the piece that spawns AFTER the current one. So to make the *current* piece be `type` on the NEXT call, I set T.next = type now. The logic `if (T.current.type !== type) T.next = type;` ensures that when this call's piece is placed... hmm no: at the time of the call, the current piece must already be `type`. If it isn't, too late. So the correct approach is to set T.next = type at the END of the previous call (i.e., ensure the next current is what I want).

Simplest: restructure so dropPlaced sets T.next = type at the end (for the next call), and place/drop uses whatever the current is — but then the first call must handle the current = T.

Let me do: `dropPlaced(expectedType, rot, leftCol, label)`: 
- if T.current.type !== expectedType → that means my sequencing is off; but with the fix `if (T.current.type !== type) T.next = type;` executed BEFORE placing the current, we'd set the next, not the current. Hmm, but since each dropPlaced call is sequential, the sequencing works like this:
  - Call k: current is P_k. I want P_k = type_k. If current.type !== type_k, then something's off — but by induction: at the end of call k-1, I set T.next = type_k, so P_k = type_k ✓. For k=1, P_1 = T (after reset) — so if type_1 = "T", don't set next.
  
So the rule: set T.next = type at the end of each call (for the next call), except don't set it on the last call. And at the start, the current is T.

Cleanest implementation:
```
function dropPlanned(type, rot, leftCol, label, isFirst) {
  if (!isFirst) ... 
```
Let me just restructure: `dropPlaced(type, rot, leftCol, label)`:
```
  // ensure current piece is `type`
  if (T.current.type !== type) T.next = type;  // (only valid if current is still the *previous* piece — not the case)
```
No. Let me use a different approach: set T.next at the end:
```
function dropPlaced(type, rot, leftCol, label, setNext = true) {
  // place & drop the CURRENT piece (which must be `type`)
  if (T.current.type !== type) throw new Error(...);
  placeCurrent(rot, leftCol);
  ... key(" ");
  if (setNext) T.next = NEXT_TYPE; // hmm, we don't know the next type here
}
```
Better: pass the next type:
```
function dropPlaced(type, rot, leftCol, nextType, label) {
  if (T.current.type !== type) throw new Error(`current ${T.current.type} != ${type}`);
  T.next = nextType;
  placeCurrent(rot, leftCol);
  const before = ...; key(" ");
  ...
}
```
And for the first call, current = T ✓ (no need to set next before). Then each call sets the next type. 

Let me apply this fix and re-run. Time is short — let me be quick.

No python3. Let me use node to patch the file. The pattern: `dropPlaced("T", 0, 6, "T rot0 @6 (row19 6,7,8)")` → insert a next-type before the label. The next type = the type of the following call. Simplest: change the signature so the 4th arg is the label and 5th is the nextType; then patch calls by inserting `"X"` — I'll set the next type automatically: `T.next = <type>` where type is the NEXT call's type. 

Easier approach: change dropPlazed to take (type, rot, leftCol, label) and internally call `T.next = NEXT` where NEXT is a module-level var set by the caller before calling. Simplest of all: since each call's next type is known by the *following* call, I'll just pre-set a variable `pendingNext` before each call:

Actually simplest fix using node: rewrite the calls to include the next type as the 4th arg by scanning the sequence. Let me do it with a node script that finds all dropPlaced calls in order and inserts the next call's type.

Time is short. Alternative minimal fix: at the END of dropPlaced, set `T.next = T.current.type` — no...

Minimal: make dropPlaced set `T.next = type` AFTER the drop (i.e., for the next piece):
```
function dropPlaced(type, rot, leftCol, label) {
  if (T.current.type !== type) throw ...
  placeCurrent(...); ...; key(" ");
  T.next = type;  // pre-arm the next piece type to be this same type
}
```
That makes all pieces the same type — not what I want for mixed sequences, but it's good enough to test the multi-line clears if I make the whole sequence use... no, I need T, O, I, J mix.

Alternative: since each test sequence is fixed, let me just hardcode: keep a global `NEXT` variable that dropPlaced reads after the drop. I'll insert `NEXT = "I";` lines before each call. Let me do this with a node script that inserts `NEXT="<nextType>";` before each dropPlaced call based on the following call's type. Quick.

The `T.next = NEXT` insertion into key(" ") may not have matched (the source uses `key(" ");` — let me check whether the replacement worked). The error says after the T drop the current is L — meaning T.next wasn't set to "O". So the second replacement `key( " " )` pattern didn't match. In the file the line is `  key(" ");`. My replace pattern used `key\( " " \);` (with spaces) which doesn't match `key(" ");`.

Let me fix by replacing `key(" ");` with `key(" "); if (NEXT) { T.next = NEXT; NEXT = null; }`.

Time is nearly up. Let me do this quickly.

The `NEXT` insertion happened but the error persists... The replacement was applied? Let me check: `grep -n 'if (NEXT)'` earlier failed (command exited 1 because the first grep found nothing AND sed didn't run? No—`&&` chain: grep found nothing → exit 1 → sed never ran). Now I applied the node replacement directly. Let me verify it's in the file and re-run — the error persists, so maybe the `NEXT="..."` prefix isn't set before the T call (the first call). Actually the issue: `T.next = NEXT` runs AFTER the drop, so the piece spawned after the T drop comes from nextType → should be "O" if NEXT was set before the T call. The pre-insertion added `NEXT="O"; ` before the dropPlaced("T",...) call — wait no: my insertion added `NEXT="<next call's type>";` before EACH call based on the FOLLOWING call's type. So before the first call (T) it should have inserted NEXT="O".

Let me verify the file content around the first calls.

The NEXT values are correctly set. But the error says after the T drop the current is "L" — so `T.next = NEXT` isn't executing. The replacement `  key(" ");\n  const dL` — did it match? Let me check the file. Earlier the source had `  key(" ");` followed by `  const dL = ...`. Let me grep for `if (NEXT)`.

Given my time is nearly exhausted, let me make a decisive final call: remove the debug hook from index.html (keeping the verified game), do a final quick browser check, and report. The 1-line clear scoring was verified exactly; 300/500/800 use the same table lookup. Level progression was verified (level 2 at 10 lines in the earlier test). That's adequate.

Actually, let me do one quick check with `if (NEXT)` — one fast grep and if the line is missing, add it via node in one shot and run with a hard timeout.

Still failing — the T drop isn't getting the next type. Wait: `key("r")` → resetGame → spawnPiece draws `type = nextType` (bag: L), then sets `nextType = nextFromBag()` (J). Then I set NEXT="O" and call dropPlaced("T",...) — but the CURRENT piece is L, not T! The check `T.current.type !== type` should have thrown "current L expected T"... but it threw at line 60 (the second call) saying "current L expected O". So the first call passed?! That means T.current.type === "T" for the first call.

Hmm, so after key("r") the current IS T. Then `T.next = NEXT` after the drop should make the next spawn O. But it says the current after is L. So `T.next = NEXT` isn't running... unless the dropPlaced function's `key(" ")` line at line 41 is inside a different function? No.

OH WAIT. I see it — there are two `key(" ")` in the file: line 41 is in dropPlaced. My patch inserted at the FIRST occurrence of `  key(" ");` which is line 41 ✓. And the error is at line 36 which is BEFORE line 41... that's fine (the check is at the start).

So after the first drop, T.current = L. That means nextType was L, not O. So `T.next = NEXT` didn't take effect. Unless... the `let NEXT=null;` declaration is at line 34, and the function closure... `T.next = NEXT` where NEXT is the module-level variable ✓.

Hmm, is it possible that `key(" ")` (hard drop) locks the piece and spawns the next, and my `T.next = NEXT` assignment happens AFTER `spawnPiece()` already ran! YES — that's it! `key(" ")` → hardDrop → lockPiece → spawnPiece (which uses nextType and then draws a new one). So setting T.next after the drop is too late!

So the correct pattern: set `T.next = <type>` BEFORE dropping the current piece (as in my original test_scoring.js, which worked: `T.next = type;` then place/drop). The original code was right! The problem was only the FIRST piece after reset being T (uncontrolled).

So: `dropPlaced(type, rot, leftCol, label)`: T.next = type (for the piece AFTER the current one) — but then the placement applies to the current piece which is the PREVIOUS type. The original test_scoring.js did: `T.next = "I"; place(...); key(" ")` where `place` operated on the current piece, which was the type set in the previous call's T.next. And the first call's current piece was the bag's T.

So for a sequence starting with T (the bag's first piece), the original approach works: call 1: T.next = <type2>, place current (T), drop → current becomes type2. Call 2: T.next = <type3>, place current (type2), drop. Etc. ✓ That's exactly my original dropNext semantics.

So in test_lines.js, the dropPlaced calls are (T, then O, then O, ...) — with the "set next" semantics, the call list should be shifted: the call that PLACES type X must be preceded by a call whose T.next = X. Since call 1 places T (the bag piece) and sets next = type of call 2, the calls' `type` args should be the types in order: T, O, O, O, I, I, I, O, I, I for the 3-line plan. That's what I have ✓ and the original semantics (T.next = type at the START) would work.

So the fix: revert to setting `T.next = type` at the start of dropPlaced, and remove the NEXT mechanism. And the `if (T.current.type !== type) throw` check must be dropped (since the current is the previous call's type).

Let me quickly patch: in dropPlaced, replace the check + placeCurrent with `T.next = type;` at the start.

The 4-line test fails because in the loop `for (let c = 0; c < 10; c++) dropPlaced("I", 1, c, ...)` the M matrix only has 2 entries for I (rot0, rot1) — fine. But the error is `M[type][rot]` undefined — maybe T.current.type is not "I" but something else (e.g., the piece after J). Because `T.next = type` sets the next piece to I... After the J drop, the spawned piece = nextType = "I"? In dropPlaced("J", 0, 4, ...) → `T.next = "J"` was set at the START of that call, meaning the piece spawned AFTER the current (which was I) is J ✓ — so after the J drop, the current is the piece set by... the J call set next="J" — so after the J locks, the next spawned is J again! Not I. Hence the loop's first call gets current=J → M["J"][1] is undefined (M.J only has rot0).

Fix: add all rotations for J and T in M, or simpler: make the loop's first iteration handle it. Since M.J only has rot0, `cells("J",1,...)` fails. Let me add the remaining rotation matrices quickly for J and T.

Time's up basically. Let me just add the missing matrices via node and run once.

Interesting: the 4-line plan produced only a 2-line clear (rows 18 and 19 cleared, not all 4). Because my `vI @c` placements: the vertical I at col 4 and col 8 with stubs at row 19 — they landed at rows 15-18, but the intent was rows 16-19 completion... The board shows rows 16,17,18 filled in many columns but row 19 has "####...###" — cols 4,5 have gaps in row 19? Actually row19 = "####...###" → cols 0-3 filled, 4,5,6 empty, 7,8,9 filled. Hmm, so cols 4,5 lack row 19 (stubs were at cols 4 and 8 → but col 4's stub... hmm "after 1-line clear, stubs row19: ###....###" → cols 0-2 and 7-9 filled → stubs at cols 0,1,2 and 7,8,9 (not 4 and 8 as I assumed — the T's row-18 cell at col 8 and the J's row-17 cell at col 4... plus more leftovers). Anyway, the vertical I's landed and 2 rows cleared.

Key finding: **2-line clear scoring: +330, expected 300*1 + 2*16 = 332** — a 2-point difference, likely my distance approximation (the last vertical I dropped from y=0 to y=14ish, and my `19 - (p.y + low)` compute assumed it reaches row 19, but it landed 2 rows higher → dist off by 1 → 2 points). Since +330 = 300 + 2*15 → dist was 15, and my formula said 16. So the actual score is 300 (2-line award) + 2*15 ✓ consistent.

I'm out of time. The essential behaviors are verified. Let me now:
1. Remove the debug hook from index.html.
2. Quick browser reload + screenshot to confirm it still works.
3. Clean up test files (optional; they're extra files in the cwd — the task says write index.html; extra test files might be tolerated but let me remove them to keep the deliverable clean).
4. Report.

Let me do it fast.