Fix stale tile colors on theme toggle and double-counted stats on repeat Enter

[dotcomstar]

Two bugs found while reviewing #212 before deploying it to production. Neither is in production yet; both are on main.

1. Scored tiles froze in the previous theme's colors

Switching dark/light mode (or High Contrast) after scoring a guess left the tiles in the old palette while everything else, including the keyboard keys directly below them, switched.

Before (unfixed main): dark mode, guess CHAIR scored, then switched to light. The tiles keep the dark palette (near-black R, dark green/yellow); the keys show the light one.

Computed colors at that moment:

element	color
C tile	rgb(83, 141, 78) (dark success)
C key	rgb(106, 170, 100) (light success)
R tile	rgb(58, 58, 60) (dark error)
R key	rgb(120, 124, 126) (light error)

After: same steps on this branch. Tiles and keys change together and report identical colors.

Cause. Cell cached the PaletteColor object it was scored with in displayStatus and only refreshed it at the flip midpoint. ThemedLayout rebuilds the theme in place (useMemo, no remount), so the effect saw a new object as a changed status prop but early-returned because the tile was already revealed. Before #212 the tile read status.main directly, so it always tracked the theme.

Fix. A letter's status is now a palette key end to end (LetterStatus = "success" | "warning" | "error" | "primary", exported from Cell.tsx). GameGrid computes keys, GameRow compares keys and uses sx theme paths for the connector color, and Cell resolves theme.palette[displayStatus] on every render. SampleGame and LandingLogo pass keys too, and both drop their useTheme calls. This was chosen over syncing the cached object on change because it removes the class of bug rather than patching one path, and it matches how Keyboard already types key statuses.

The effect also now mirrors the prop whenever the tile is already revealed. That closes a latent hole where any dependency change mid-flip cancelled the pending reveal timer and left the tile uncolored for good.

2. A repeat Enter during the game-end delay double-counted stats

#212 holds the stats dialog back ~2.5 s behind the flip, wave, and confetti on a game-ending win. During that window the on-screen ENTER key is still clickable, and a second tap (a mobile double-tap, say) re-ran the whole game-end block. logGame is additive, so the day's stats were counted twice. Previously the dialog's backdrop appeared synchronously and blocked this. The same double-count already happened on any Enter after dismissing the dialog, or after reloading a finished game.

Fix. The game-end block only ends the game and logs when this render's gameState is still "inProgress". Any later press just reopens the stats dialog.

Tests

• Cell: renders inside a ThemeProvider, swaps in a theme with a different success.main, asserts the background follows.
• Cell: a status change on an already-revealed tile updates color and aria text with no flip.
• HomePage: a repeat Enter after a game-ending win reopens the dialog without changing numQuestionsAttempted, questionsGuessedIn, or the category stats, both inside the delay window and after dismissing the dialog.

npm run lint, npx vitest run (204 passing), npm run build all pass locally. The review doc Claude-notes/code-review-2026-09-02.md has both findings with the screenshots.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JpS4A5zjVECoAQjVfMFazi

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
triviale	Ready	Preview	Sep 2, 2026 6:46pm UTC