Magnet Caption

Build "Magnet Caption" — a polished mobile-first portrait web app for the Eazo community, built from a live TikTok trend, in the swipe-to-decide card family.

CONCEPT
A brushed steel fridge door with your own photo held up by two magnets, and sixty loose word magnets scattered across the metal. Drag magnets into a line under the photo and they snap to an invisible baseline, click against each other and shove their neighbours aside. The words you do not use drift to the edges. The caption you build is a physical object on a fridge, not a text field.

RULES & STATES
- The photo comes from the device picker only — the user chooses it from their own library, it never leaves the device, nothing is uploaded and no camera is ever opened. The app works completely offline.
- A drawn placeholder photo is already on the fridge at first paint, so the app is fully usable and fully shareable with no photo chosen; choosing one simply swaps it in.
- Magnets have real physics: mass, a click on contact, a snap to the caption baseline and genuine shoving of neighbours when a word is pushed into a full line.
- The word bank is fixed and embedded, grouped by tone (dry, warm, blunt, wistful), and the caption line caps at eight magnets so it stays a caption and not a paragraph.
- Result: the fridge door with the photo and the finished magnet caption, exported as one card. Replay scatters the magnets again. Ambient: the fridge hums and a slow highlight travels across the steel.

OPENING (cover mode)
Open with a full-bleed opening artwork unique to this app, drawn procedurally in code: A brushed steel fridge door photographed straight on with a single photo held by two magnets and sixty loose word magnets scattered across the surface, one line half assembled below the photo; the title is spelled out in oversized magnet letters along the top edge, slightly uneven. The title must be integrated into the artwork itself — never the generic "title + tagline + how-to card + Enter button" layout. Any text drawn on the canvas needs a contrasting stroke outline so it can never blend into the art beneath it, and the main title must sit at least 20 percent down from the top so it clears the language toggle. The artwork must fill the frame — no empty single-colour field with one line of text. Below the artwork show at most ONE short tutorial line, then exactly ONE text button that starts play. Nothing else on the opening screen.

GLOBAL REQUIREMENTS
- Language: ship a lightweight built-in i18n layer with exactly two locales, English (en) and Chinese (zh). The app ALWAYS opens in English — hardcode the default locale to en and never call navigator.language or otherwise detect the system or browser language. Provide one small, comfortably tappable EN / 中文 toggle placed top-right, about 56px down from the top edge, clear of the device status bar. Chinese appears only after the user actively switches. The cover, onboarding, defaults, generated content and all share output stay English regardless of locale. Never mix two languages on one screen. Declare one shared TypeScript interface whose fields are all string, annotate both dictionaries with it and look them up as Record<'en'|'zh', T> — never let the two dictionaries infer incompatible literal types, and run a production type check before you call it done.
- Fully self-contained: absolutely no external APIs of any kind — no AI calls, no third-party data, media or font services, no remote backend, no login. Embed every item of data, copy and content in the app code. Draw every other piece of artwork procedurally in code; ship no image assets.
- Local photo import (this app only): the user may bring in pictures through the device's own file picker (an <input type="file" accept="image/*"> with NO capture attribute, so it opens the photo library and never the camera). Read them with FileReader or createObjectURL, keep them entirely in memory, revoke the object URLs on unmount, and never upload, fetch, POST or transmit a photo anywhere. Ship a drawn placeholder set so the app is fully playable, fully complete and fully shareable before any photo is chosen, and handle a cancelled picker, an unsupported file and a very large file as real states rather than errors. Downscale anything imported to at most 1600px on the long edge before drawing it.
- Share: integrate a Share feature using the @eazo/sdk community share interface so the player can post the result directly to the Eazo Community. Follow the SDK's own current best practices for composing and attaching the result — do not invent custom share plumbing. The attachment must be something the community server can fetch over the network. Place Share on the result state, keep Replay available, no placeholder buttons, and never claim the post was shared when it was not (in a plain browser the share cannot actually publish, so the button must reflect the real return value).
- SSR determinism: the initial render must be deterministic. No Math.random(), no Date.now(), no locale-dependent number or date formatting during first paint — move all of it into a client effect or drive it from a fixed seed. Hydration must produce zero console errors.
- Mobile-first portrait, touch-only, no hover dependence. The app root must follow the host container height (position: fixed; inset: 0; height: 100%) — never 100dvh or 100svh. Size any canvas from its PARENT element using a ResizeObserver and run the fit once on mount; convert every touch event through getBoundingClientRect() read at event time — never cache the rect and never use window.innerWidth/innerHeight for canvas sizing. Clamp every derived geometry value to a legal range at the point it is computed, so no radius, size or index can ever go negative or non-finite.
- Safe areas: keep all top UI at least 56px from the top edge. Keep every core interactive control AND every self-drawn bottom UI element (HUD text, counters, legends, hints) fully above the bottom 88px of the viewport — the Eazo mobile app overlays a native toolbar there that your code cannot detect. Verify at 393x852 portrait.
- Fill the screen: the layout must stretch to the full host height. No dead colour band in the lower half — if the stage has a fixed aspect ratio, give the leftover vertical space a designed extension (gradient, ambient particles, scene ground), never a bare block.
- No background music and no autoplay audio.
- Complete real states: loading, empty, success and error where relevant. Every control must actually work — no alerts, console-log placeholders or fake results.
- Visual bar: exactly ONE core rule understood within 3 seconds, with rich generous visual response on every touch (motion, particles, deformation, colour, light). Canvas 2D preferred for effects; do not use the canvas roundRect API (older iOS Safari lacks it). Never hardcode light text colours onto possibly-light backgrounds — derive text colour from the theme. Keep some ambient motion at all times so no screen is ever a still image.