2048 · grok-4.7

I will build a single self-contained HTML file for the 2048 game.

I am designing the core mechanics. The board will use a 4x4 grid with arrow-key sliding and merging. Tiles spawn after each move at a 90/10 ratio of 2s to 4s. I will prevent rapid input from corrupting state and block page scrolling. Score, win, and game-over logic are also planned.

I will lock input during animations to prevent state corruption. Tiles will be absolutely positioned elements with unique IDs and CSS transforms for movement and merging.

I am now drafting the exact HTML structure. The layout will use a header with score and New Game button, a board wrapper containing a grid background, an absolutely positioned tile layer, and an overlay for win or game-over messages. I have also begun writing the JavaScript constants.

I am now writing the JavaScript game state. The board will be a 4x4 array of tile objects or null. I am also drafting the slide function and planning how to record tile positions before each move to animate transitions correctly.

I am refining the animation sequence. Tiles will slide from their old positions to new ones. Merged tiles will both animate to the destination cell, then be replaced by a single tile with a pop effect. A new tile will fade in after the move completes.

To prevent state corruption, input will be locked at the start of each move and ignored until the CSS transitions finish.

I am also drafting the merge algorithm. It will process lines left-to-right and reverse them for rightward moves.

I have completed the merge algorithm. It processes adjacent equal tiles, doubles their value into a new tile with a unique ID and mergedFrom tracking, accumulates the score increase, and advances two positions when merging occurs.

I verified the merge algorithm against several test cases. I also mapped the four movement directions to the core left-to-right processing logic. Tiles will keep their stable IDs when they slide without merging, and receive new IDs only when they combine.

I am now drafting the `move` function. It will snapshot tile positions before processing, skip invalid moves, and only spawn a new tile when the board actually changes.

I am finalizing the move completion logic. After rendering, a timeout will unlock input and check for win or game-over states.

Win triggers when any tile reaches 2048. Game over occurs when no empty cells remain and no adjacent equal tiles can merge.

I am also writing the CSS. Tiles animate via transforms with a 120ms ease-in-out transition. New tiles use a pop animation, and merged tiles use a merge-pop animation at z-index 2.

I am refining the animation technique. Tiles will render at their old positions first, then requestAnimationFrame will set new positions so CSS transitions can run cleanly without state corruption. Ghost tiles will represent merging sources during the transition, and only the merged tile will remain afterward.

I will maintain a `tiles` Map keyed by tile ID to track each tile's current and previous row and column. During rendering, new tiles are created in the DOM and existing ones slide from their old coordinates to new ones via CSS transforms. When two tiles merge, both animate into the same cell; once they arrive, the source tiles are removed and replaced by a single merged tile with a scale animation.

I refined the merge animation to prevent a visual flash. Only the sliding source tiles will be visible during the transition. The merged tile and new tile will appear only after the sources arrive.

I will update the score immediately when a move is committed so the increase is visible right away. I am also adding a keydown listener that calls preventDefault on arrow keys to stop the page from scrolling during gameplay.

I will skip touch swipe support to focus on the required features. The New Game button will reset the board, score, and any win or game-over overlay. After a win, a "Keep going" option will let the player continue playing; reaching game over afterward will still display the game-over message. The win message will appear only once.

I will initialize the board with two random tiles, mostly 2s and rarely 4s. I am skipping localStorage to keep the implementation simple. The visual style will use a warm beige background with colored tiles.

I finalized the tile color palette from 2 through 2048 and above. I will use system fonts only and avoid external assets. I plan to test the game by playing arrow-key moves in the browser, and I may expose a debug function on the window object so I can inspect board state via the console.

I will add data-value attributes to tiles so the board state is visible in the DOM inspector. I am also adding a lock flag to prevent rapid input from corrupting the game state.

I am now writing the `move` function. It will collect tile movements and merge data into separate arrays before rendering the board.

I am restructuring the `move` function to use cleaner arrays. Sliding tiles will be tracked in a `slides` array, and merged tiles that appear afterward will be tracked in a `births` array. This avoids messy merge tracking and makes the animation logic easier to follow.

I am now implementing the core merge loop inside `move`. It processes each line with two pointers: one for the destination cell and one for the source tile. When adjacent tiles have equal values, they combine into a new tile with a doubled value and a unique ID.

I realized the board must not update before the animation begins. The DOM will be rebuilt from the board state only after the slide transitions finish, while sliding tiles are manually positioned during the transition.

The animation function clears the tile layer and creates temporary elements at each tile's starting position. A forced reflow ensures the browser registers the initial coordinates before CSS transforms move them to the destination cells. After a 160 millisecond delay, the board rebuilds from its final state, the score updates, the game status is checked, and input is unlocked.

I am defining CSS variables for the 4×4 grid: 90-pixel cells, 12-pixel gaps, and a 408-pixel board width. Tiles will be absolutely positioned using transforms calculated from row and column indices. The initial two tiles will animate in without locking input. I am also beginning to draft the `hasMoves` function that checks whether any valid move remains.

I finished the `hasMoves` function. It scans every cell and checks its right and bottom neighbors for equal values.

The win condition is any tile reaching 2048 or higher that has not yet triggered a win message.

I am designing the overlay dialogs. The win screen will show "You win!" with a Keep going option and a New Game button. The game-over screen will show "Game Over" with a New Game button.

If a player continues past a win and the board becomes stuck, the game-over state takes precedence.

The win overlay will show a "Continue" button when moves remain, and a game-over subtitle when the board is stuck. New Game will always appear in the header. I am adding accessibility features like button focus and ARIA labels.

I am adding keyboard focus so the page captures arrow keys. Large numbers will use smaller fonts, and tile text will be dark for 2 and 4, white otherwise. The board will use responsive sizing with a viewport-relative cell width, a subtle shadow, and centered layout for the 1200×800 viewport. I will now write the file and test it.

I confirmed that new tiles spawn only after sliding animations finish, and that no animation runs when a move changes nothing. I will use a 90 percent chance for 2s and a 10 percent chance for 4s when placing tiles on empty cells. I plan to test the core merge logic in Node.js before writing the HTML file.

I will add a hidden `window.__debugSetBoard` hook so I can inspect board state in the console during verification. I am also testing an edge case: a line like [2,0,2,0] sliding left should merge into [4,0,0,0] and increase the score by four.

I verified the merge logic against several edge cases. Tiles separated by empty cells merge after compaction. In a line like [2,2,2,0], only the first pair combines into 4. A line like [4,4,2,2] becomes [8,4,0,0]. Rightward moves also behave correctly: [0,0,2,2] becomes [0,0,0,4], and [2,2,2,2] becomes [0,0,4,4].

I am weighing a 160 millisecond timeout against transitionend events to trigger the final board rebuild. The timeout is simpler, but transitionend would be more reliable since multiple tiles fire at once.

I will use a setTimeout to trigger the final board rebuild instead of transitionend events, since tiles that do not move never fire transitionend. Tiles that stay in place will still render correctly. Moving tiles will be layered above static ones so overlapping same-value tiles during a merge remain visible. New tiles will animate in with a scale effect, and merged tiles will pop into view.

I realized that animating both `left`/`top` and `transform` on the same tile would conflict. I will use CSS transitions for position and reserve `transform` only for the scale animations.

I am writing a `place` helper to set tile positions via CSS variables. During animation, tiles will be forced to their starting coordinates with transitions disabled, then reflowed, and finally moved to the destination with transitions enabled. I will wrap this in a requestAnimationFrame to ensure the browser registers the initial paint before sliding begins. The score display will also animate with a bump effect when it increases.

The win overlay will block arrow-key input until the player presses Continue, while New Game remains accessible. The game-over overlay will also freeze input until New Game is clicked. I am deciding whether to keep a persistent win badge visible when the player continues past 2048.

A persistent win banner will remain visible after the player continues past 2048. Touch support will be added as well. The implementation will be contained entirely in index.html.

I will log the board state after each move so I can verify merge scores in the console. A win is checked only after the full move completes, and it triggers once even if multiple tiles merge into 2048. The score increases by the total value of every tile that merges during a single move.

A session-best score is unnecessary. I am adding an `epoch` counter to prevent a stale animation timeout from overwriting the board when New Game is pressed mid-transition.

The epoch counter is now wired into the animation and New Game functions to prevent stale timeouts from overwriting board state. I will also add a footer hint for arrow-key controls and extend tile color rules to values above 2048.

The board will use `touch-action: none` to block touch scrolling, and keydown listeners will be non-passive so arrow keys cannot scroll the page. Grid cells will be static HTML elements with IDs `#board` and `#score` for easy inspection.

I will use `aria-live` regions for the score and game messages. Tiles will be HTML elements with `data-value`, `data-r`, and `data-c` attributes. I am now writing the file.

I will rebuild the tile layer in place after each move instead of destroying and recreating elements. This avoids a visual flash by removing only tiles that merged or left the board, adding new tiles, and keeping the rest already at their final positions.

Score will update immediately when a move commits, so the user sees it during the animation rather than waiting for the transition to finish.

I will layer tiles with higher z-index so those sliding farther travel over others. A score pop animation will play when the score increases. The game-over check runs after a new tile spawns, so a move that fills the board but leaves a possible merge does not end the game. If no tiles move and nothing merges, the board stays unchanged and no new tile appears.

I will add a meta viewport tag to the HTML. The Continue button will hide the win overlay and set `keepPlaying` to true while preserving the `won` flag so the win message does not reappear. I am now writing the code.

I noticed a bug where reaching 2048 and having no valid moves would only show Game Over, missing the win message. I am now handling that overlap so the win banner still appears when both conditions are true.

WASD keyboard support is being skipped to avoid confusion. I will add a console log and data attributes to expose board state for manual verification.

I will keep any debug hooks out of the final file. The board state can be inspected via `window.__2048` without affecting gameplay.

I will keep the code clean by removing any debug hooks and rely on DOM inspection for verification. I decided against adding an on-screen move log to avoid cluttering the interface. The board will use 96-pixel cells with a 10-pixel gap, giving a 434-pixel board that fits comfortably within an 800-pixel viewport.

The New Game button will use the classic 2048 brown styling. The score box will display a "SCORE" label and the game will use the original color scheme. Merged tiles will animate with a 180 millisecond scale pulse, while new tiles will fade in with a 160 millisecond scale transition.

Tile text will scale down for larger values, and each tile gets a CSS class for its numeric value. Box-shadow will be added to tiles, and text selection on the board will be disabled.

Arrow keys will not dismiss overlays. The New Game button will have id `new-game`. The board starts with two tiles. A 90 percent chance of a 2 and 10 percent chance of a 4 determines new tile values. Empty cells are found by scanning the board.

The tile animation sequence is being refined. Tiles will first have their transitions disabled and forced to starting coordinates, then a reflow occurs, and finally the transition is restored before moving to the destination. This two-step approach prevents browsers from skipping the initial paint and ensures the slide animation starts reliably.

The tile animation sequence is being refined. Tiles will first have their transitions disabled and forced to starting coordinates, then a reflow occurs, and finally the transition is restored before moving to the destination. This two-step approach prevents browsers from skipping the initial paint and ensures the slide animation starts reliably.

A pending-move queue will buffer the next arrow-key input while a slide animation is running. This keeps the game responsive without corrupting board state.

I will write a complete, polished 2048 game.

I am refining the animation approach. CSS transforms will replace calc() transitions for smoother tile movement. I am also planning internal logic tests and careful HTML construction.

The animation structure is now concrete. Outer tiles will use transform for position, while inner elements animate scale for pop effects. Movement transitions will apply to the outer wrapper.

I am finalizing the CSS grid layout. The tile layer will be inset by a gap variable, and each tile will use a translate function to position itself at (cell + gap) * column and row.

The board structure now has three layers: a grid for background cells, a tile layer for game pieces, and an overlay for win or game-over messages. The CSS sets the board dimensions to four cells plus five gaps, with rounded corners and padding.

I am adding a floating +score animation near the score box to provide visual feedback for each merge. The overlay will cover the entire board. I am now ready to write the complete implementation.

I will attach the keyboard listener to the window so arrow keys work even when the page lacks focus. Initial tiles will carry a `.new` class for their entrance animation. I am skipping a separate Node unit test and relying on careful inline logic instead.

I am designing a full synchronous render function to guarantee the DOM matches the board state after each move. I will also remove temporary animation classes once they finish so tiles do not re-trigger effects.

I decided against a full DOM rebuild after each move to avoid flicker. Incremental updates are safer. After animations finish, kept tiles will have their data attributes updated and merged sources removed. New tiles will carry both the `merged` and `new` classes. Merged tiles will sit above others via z-index.

I will add the merged tile before removing its source tiles so the pop animation plays cleanly without a visible gap. The new tile spawns in the same empty cell at the same time.

The score will update immediately before the slide animation so it is visible during movement. I will include a win message and style win and game-over states with distinct colors. The continue button will appear only after a win when valid moves remain. Touch swipes are a bonus feature, but arrow keys remain the primary input.

I am adding touch swipe detection. The code records the initial touch point and compares horizontal and vertical movement to determine the slide direction. A 24-pixel threshold prevents accidental taps from triggering moves.

I will embed a self-checking test suite that runs when the URL hash is `#test`. It will verify the core move logic directly in the browser without external dependencies.

I will run the self-tests automatically on page load and log PASS or FAIL to the console. The tests will operate on a fake board copy so they never alter the visible game state. I am also refactoring the core move logic into pure functions so it can be exercised without touching the live DOM.

I am now writing the core `slideLine` function. It filters out empty cells, merges adjacent equal tiles once per pair, accumulates the score gain, and pads the result back to four positions.

I am now writing the `moveBoard` function. It clones the board and applies `slideLine` to each row or column depending on the direction. I verified that the change detection correctly flags moves like [2,2,2,2] → [4,4,0,0] while leaving unchanged states such as [2,4,0,0] untouched.

I found a bug in `moveBoard`. For right and down moves, the code reverses each line before passing it to `slideLine`, then reverses the result back. The `changed` flag is computed against the reversed input, so it can be wrong for moves like `[2,2,0,0]` right. I need to fix this comparison.

The suspected bug in `moveBoard` was a false alarm. Reversing the input line before `slideLine` and reversing the output back preserves the correct `changed` flag. The comparison against the reversed input is valid.

I will compare the final board against the original to verify changes, rather than relying solely on the reversed-line check. I also need to track tile identities beyond their numeric values.

I am designing a `slideTiles` function that operates on tile objects rather than plain numbers. It will track slide destinations, new tile spawns, and merged tile identities separately from the numeric board state.

The `slideTiles` function now returns slide destinations, new tile spawns, and score gains. Tile IDs will use a global counter so tests can reuse the same logic. Even when no tiles merge, position changes still trigger movement animations.

I am now writing the complete HTML markup. The overlay will show a win message with a continue button, and the game-over state will hide that button. A New Game button will sit in the header.

Inspecting the body's innerText, console logs, and a screenshot.

Considering data attributes and a visually hidden live region to expose tile values for testing. Noting that innerText may include offscreen text.

Playwright innerText captures visible text, so tile numbers will appear in the inspection. The board renders row-major to preserve visual order after animation settles. A JSON console log of score and board state will be emitted after each move for verification.

Confirmed Playwright keyboard presses will fire keydown events correctly. Verified that preventDefault on keydown does not block the game from receiving input. Now planning the animation lock and pending move implementation details.

The animation lock will render the final board state before unlocking. Pending moves then read from logical state rather than DOM positions, preventing animations from starting mid-slide.

The animation function rebuilds tiles from logical positions derived from the pre-move board state, not from the current DOM. This means even if the DOM is mid-animation, the tile layer will still be correct. The animation lock primarily prevents interleaved DOM writes and duplicate tile spawns rather than preserving visual accuracy.

An epoch counter will prevent stale animation timeouts from overwriting the board after a later move. The CSS transition duration is 150 ms and the timeout is 170 ms. A New Game press during an active animation increments the epoch so the old timeout exits early.

Adding `button type="button"` to prevent form submission. A startup self-test will verify the merge logic against several tile sequences and expected scores.

The self-test now covers edge cases like no-merge rows and full-board merges. Horizontal, vertical, and game-over detection will be verified offline. The visual design uses a classic 2048 palette with beige backgrounds, dark gray tiles, and contrasting text.

The header will show the title, score, and New Game button. A status bar beneath the board will display arrow-key instructions and win messages. A game-over overlay will cover the board when no moves remain. Tiles will use a flat design with no shadow, plus a slight scale effect on merge. Large numbers will fit within 96-pixel cells at 28 pixels. The board will carry `role="grid"` for accessibility.

Arrow keys will move the game even when focus is on a button, and preventDefault stops buttons from activating. The continue button overlay ignores arrow input. Space on New Game works natively. Escape was considered for continuing but skipped. A subtle bug in slideLine changed detection was fixed by comparing tile values instead of objects. The file is ready to write.

The tile builder now uses CSS custom properties for cell size and gap. Each tile receives a class based on its value, plus data attributes for row, column, and value.

The tile builder now appends an inner div for the number text. A `renderStatic` helper clears and rebuilds the tile layer from the logical board state, marking new tiles with a `new` class. The `animate` function begins by clearing the layer and mapping slide data to DOM nodes.

The animation helper creates temporary tiles at their starting positions and forces a layout reflow so CSS transitions can begin. It then applies the transform to the target position and clears the tile layer after the animation completes.

The animation helper now marks merged tiles with a `merged` class and the newly spawned tile with a `new` class when rebuilding the final board. A visual gap may appear because the tile layer is cleared and rebuilt after each move.

The tile layer rebuild is kept for correctness rather than removing and adding tiles individually to avoid a flash. The newGame function resets the board, score, and game state, spawns two initial tiles, and clears the overlay.

The win check scans every tile for a 2048 value. The move check returns true if any cell is empty or adjacent tiles match. The initial two tiles are rendered immediately after the board reset.

The status refresh logic now handles win and game-over states. It checks for valid moves first, then displays the appropriate overlay: a win message when 2048 is reached, or a game-over message if no moves remain. If the player continues after winning, the overlay updates to show game over once the board becomes full.

The win overlay will pause the game and require a Keep going button to continue. Pressing Enter or clicking the overlay may also dismiss it.

The continueGame function hides the overlay and preserves the win message in the status line. New Game resets the status. The overlay CSS uses an absolute full-size layer with a semi-transparent background.

The overlay will use a flexbox centering layout with an 8-pixel border radius and a z-index of 10. It will toggle visibility via a `.show` class instead of the `hidden` attribute.

A score box containing a label, total score, and an animated gain indicator was added. The gain span floats upward from the right side of the score for 600 milliseconds using a CSS keyframe animation.

The score gain animation fades and shifts tiles upward by 24 pixels over 600 milliseconds. The gain indicator restarts by cloning its element whenever the score changes. A "2048" heading and viewport meta tags will be added to the HTML. Arrow key presses are intercepted with preventDefault to stop browser scrolling.

A brief self-test will run on page load to verify the slide logic. Only a single "self-test ok" log line will remain in the delivered file.

A visually hidden element will expose the board state for automated testing. Playwright reads innerText from the entire document body, so visible UI text like the score and buttons would interfere with tile value extraction.

The developer is checking whether Playwright's innerText captures off-screen text from an `sr-only` element, since the tool may include clipped content that is still accessible.

Playwright's innerText may include off-screen text, so the developer will verify this empirically. Console logs will be used for reliable state checks during testing and removed afterward. Tile CSS classes are being organized into value-specific rules and a super class for tiles above 2048.

The tile background and text color are now defined on `.tile-inner` so the scale animation transforms the colored box directly. Merged tiles receive a higher z-index and play a 160-millisecond pop animation.

A 140-millisecond appear animation will play for newly spawned tiles. Font sizes scale down by value tier: 34 pixels for 128, 256, and 512; 28 pixels for 1024 and 2048; 22 pixels for any tile above 2048. A `tileClass` helper assigns the correct CSS class based on the tile value. The page background will remain clean without extra patterns.

The board will use a 92-pixel cell size with a 12-pixel gap, fitting within the 428-pixel total width. A subtitle and focus-visible styles for buttons are also being added.

The developer is writing a standalone `testSlide` function that exercises the slide logic without touching live game state or `nextId`. They verified the downward merge order by hand: in a column of four 2s, the bottom two merge first into row 3, then the next two merge into row 2.

The developer will wrap the self-test in try/catch to prevent it from crashing the game if the slide logic diverges from computeMove. They plan to save and restore board state around the test so live game data is not corrupted.

The 90% spawn probability is confirmed correct. Unchanged moves will not spawn new tiles. Text selection will be disabled for a cleaner feel. A footer hint will be added. The game over overlay will include a New Game button alongside the header one.

The header will use a flex layout with the score and New Game button on one side and the title on the other. The score number will scale slightly when it updates. Arrow key repeat events will be handled so rapid presses do not corrupt board state.

The developer settled on a pending-direction strategy for arrow-key repeats. While the board animation is active, repeated key presses overwrite the pending move direction, so holding an arrow key chains one extra slide after each animation completes. This creates a slow, continuous movement effect without corrupting state. They also confirmed that calling preventDefault on every keydown will block the browser from scrolling while keys are held. The implementation is now ready to be written to the file.

The board does not need a tabindex because the window listener handles keyboard input regardless of focus. Playwright can press keys on the page without focusing the board first. The New Game button will be placed at a predictable position so its coordinates can be captured after the first screenshot.

The New Game button will receive an id for reliable targeting. A console-only board readout will expose tile values for automated verification. The slide animation will be slowed to 200 milliseconds so the motion tool can capture it across its four-frame intervals without sacrificing responsiveness.

The developer decided against slowing the animation for the motion tool. They will use a 120–150 millisecond slide duration instead of the original 100 milliseconds. A `will-change: transform` property will be added to improve smoothness. They also spotted a potential bug in the interaction between `requestAnimationFrame` and CSS transitions.

The developer is analyzing the exact frame sequence for tile animations. They are checking whether `requestAnimationFrame` can safely set the transition and end transform before the browser paints, so the slide animation interpolates correctly from the starting position.

The developer identified a risk that the browser may not record the starting transform as the before state if it never paints that frame. To guarantee reliable interpolation, they will use a double requestAnimationFrame pattern: first append the tile with its start transform and no transition, then force the start transform again in the next frame, and finally apply the transition and end transform in the following frame.

The developer abandoned the double requestAnimationFrame pattern. A synchronous reflow via `offsetHeight` is sufficient to record the starting transform as the computed before state. Setting the transition and end transform immediately after that reflow triggers the animation correctly without waiting for a paint cycle.

Tiles that move will receive a higher z-index so they pass over stationary ones. Tiles that remain in place keep the lower layer. The developer is now ready to write the file and will also add a test mode.

A floating +gain counter will appear above the score for each move. The New Game button will dismiss any active overlay. Grid cells will be generated by JavaScript to keep the HTML minimal and ensure the board renders even if scripting fails. The script tag will sit at the end of the body to prevent a flash of incorrect content.

The developer added `aria-live="polite"` to the score and status elements for accessibility. They will keep code comments minimal. They verified that unchanged moves skip spawning, new games start with two tiles, and valid moves spawn exactly one new tile.

The developer confirmed that the win overlay hides the continue button and blocks further moves until the player explicitly clicks it. They also verified that Game Over only appears when no valid move remains, even if the board is full but merges are still possible.

The developer decided against using Enter, Space, or arrow keys to dismiss the win overlay. They will keep the continue button as the only way to resume playing after a 2048 victory.

The developer decided to replace the win overlay with a non-blocking banner. Arrow keys will remain active after reaching 2048 so players can continue moving tiles. The banner will persist until dismissed or a new game starts.

A persistent message element will sit in the document flow to expose win and game-over text for automated verification. Game over will appear in both the overlay and this element, while the win banner remains non-blocking.

The developer will use a semi-transparent gold banner under the header to show the win message. It will sit above the board with `pointer-events: none` so arrow keys keep working and clicks pass through. Only the dismiss button on that banner will capture pointer events.

The developer abandoned the banner idea. A persistent status element above the board will display win and game-over messages instead. It will use exact text strings for automated verification.

The win message will read "You win!" and the New Game button will say "New Game". A small "Keep going" button will sit above the board to dismiss the win highlight. Arrow keys will remain active even if the player never clicks it, satisfying the requirement to allow continuing after a win.

The score will be a bare span so automated tests can read the number directly. The page will use flexbox to center the game vertically and horizontally for a clean 1200×800 screenshot.

The body will use `overflow: hidden` to prevent scrolling. The estimated layout height of roughly 650 pixels fits comfortably within the 800-pixel viewport. A self-test will log any failures after writing the file. The 2048 text in the title header may visually resemble a tile value, but this is acceptable.

Console output will be limited to errors. A JSON state dump after each move will expose score, game-over status, and win state for debugging.

The developer will strip the debug state logs from the final file so the console stays clean for automated verification. They also noted a minor gain-animation bug and are ready to write the complete implementation.

Touch support will be added for mobile play. The developer skipped `prefers-reduced-motion` to keep the animation logic simple. They verified that merging from right to left processes tiles in the correct order, so adjacent equal tiles combine properly.

The developer verified the merge logic against concrete examples. A rightward slide of [2, 2, 4, 0] correctly yields [0, 0, 4, 4], and a leftward slide of [2, 0, 0, 2] merges to [4, 0, 0, 0] with the score updated. They will also add an internal unit test for computeMove.

The developer is drafting a `selfTest` function that duplicates the merge algorithm inside the same scope. It will snapshot the board and tile IDs, then run concrete test cases—such as a leftward slide of `[2,2,2,2]` expecting `[4,4,0,0]` with a score gain of 8—by temporarily replacing the global board state and calling `computeMove`.

The developer finalized the `selfTest` logic. It snapshots the board and tile ID counter before each test case, runs `computeMove`, and restores the original state afterward. The function validates that the resulting board matches the expected layout and that the score gain is correct. Because `computeMove` returns a new board without mutating the global one, restoring the snapshot is straightforward.

The developer decided against adding a highest-tile display. Tile text will use dark color for 2 and 4, and light color for all other values. The board will receive a subtle box-shadow for depth. The score container will be positioned relatively to anchor the floating gain counter, and the New Game button will include padding for easy clicking.