A stacker. Offline-first. No email.

Naively, BackgroundSystem fires dozens of createLinearGradient calls per frame — on older Androids that murders the GC and FPS collapses.

Fix: a GradientCache keyed by colors + dimensions. Invalidated only on theme switch. Together with a ParticleSystem object pool (swap-and-pop instead of Array.splice: O(1) instead of O(n)), fever mode stays at a constant 60 FPS on low-end devices.

Score submissions are signed on the client — a 32-bit hash over (s, b, p, d, t) + VITE_SIGNATURE_SALT from env. The Supabase RPC submit_score stores the signature and runs its own plausibility checks: a score cap per block, a min time per block, perfects ≤ blocks, streak ≤ perfects, and a 5-submissions / 5-minute rate limit per nickname.

Not a perfect solution — the salt lives in the bundle, reverse engineering is possible. But: enough to keep fire-and-forget cheats off the public board without forcing game state onto a server. Pragmatically calibrated against the attackers who actually show up.

Themes live as pure data in src/data/themes/{standard,premium,seasonal}/ — one ESM module per theme with color phases, effect flags and counts. The SeasonalEventManager detects the date and activates themes + ThemeReactions automatically — flying bats at Halloween, snowflakes at Christmas.

New event = new theme file + a single entry in SeasonalEvents.js with a date window. No code change in the renderer, no deploy coordination. The boundary between content change and code change was drawn deliberately and preserved: what authors touch versus what developers touch has been separate since day one.

SyncService pulls the cloud state on login, merges it against LocalStorage, and writes the result back. Per-field strategy: bestScore and statistics counters via Math.max, inventory and achievements as a union, equipped and settings from the cloud on first sync, local-first after that. coins use Math.max on the restore sync but stay local during an active session — otherwise the cloud would replay coins the player has already spent.

Consequence: playing on three devices loses no progress — high-water marks stay consistent, purchases and unlocks accumulate, and the most recent active session decides the loadout state. Tight enough to keep the conflict cases visible in the code — no hidden last-write-wins magic for someone to accidentally "optimize" later.