# Project Instructions

This project is a reverse-engineered specification of a real mobile app, exported as structured documentation. Your task is to generate a high-fidelity, fully interactive prototype from these documents.

## Files in this folder

- `screens.md` — every screen, layout, and navigation flow
- `features.md` — feature behavior and business logic
- `CLAUDE.md` — this file, your operating instructions

The two markdown documents describe **structure and behavior** but intentionally omit pixel-level visuals, image sources, and fidelity preferences. Apply the rules below before generating anything. **Do not ask the user to clarify the items defined here — the defaults are intentional.**

## 1. Image sources — never use placeholder boxes

Every image region must point to a real, varied URL. Pick from this table by content type, and increment `{n}` so images don't repeat within a screen:

| Content type            | URL template                                              |
|-------------------------|-----------------------------------------------------------|
| User avatar             | `https://i.pravatar.cc/150?img={1-70}`                    |
| Generic photo / feed    | `https://picsum.photos/{w}/{h}?random={n}`                |
| Square thumbnail        | `https://picsum.photos/seed/{seed}/300`                   |
| Product image           | `https://picsum.photos/seed/product{n}/600/600`           |
| Food                    | `https://foodish-api.com/api/`                            |
| Video poster            | `https://picsum.photos/{w}/{h}?blur=1&random={n}` + play icon overlay |
| Map (static)            | `https://picsum.photos/seed/map{n}/600/400` desaturated   |
| Logo / app icon         | inline SVG you generate                                   |

Avatars must look like different people. Photos must look like different photos. Never reuse the same URL twice on one screen. **Empty gradient rectangles are not acceptable output.**

## 2. Design system — infer aggressively from the docs

Read the app name and screen content. Derive a coherent design system without asking:

- **Brand color**: pick the dominant accent implied by the app's category and any color cues in the docs. If unsure, pick one accent and stick to it.
- **Background / text**: choose light or dark base based on app category conventions.
- **Radius**: small (4px), medium (8–12px), large (16–24px), or pill (full). Pick one scale and use it consistently.
- **Spacing**: 4px or 8px base grid. Pick one.
- **Typography**: system sans-serif unless the app is clearly editorial / brand-heavy.

Always declare the system at the top of your output, then reuse those tokens across every screen.

## 3. Defaults (assume unless docs say otherwise)

- **fidelity**: hi-fi, production-looking
- **interactivity**: fully clickable — tabs switch, lists scroll, buttons trigger state, forms accept input, modals open/close
- **dark mode**: light only
- **device frame**: iPhone 15 Pro mockup with status bar (9:41) and dynamic island
- **copy**: realistic placeholder text — real-sounding usernames, captions, prices, dates. **No Lorem Ipsum.**
- **emojis**: use freely where natural (captions, reactions, button labels)
- **micro-interactions**: hover/press states, transitions between screens

## 4. Layout — canvas gallery mode (default)

Render the prototype as a **scrollable gallery of live phone frames**, not a single interactive device. Every screen in `screens.md` is rendered as its own independently-stateful phone, all visible on one canvas.

**Structure**

- Sticky top bar: `{appName} · Interactive prototype` + one-line tagline derived from `features.md`.
- Canvas background: light neutral (`#f5f5f3` light / `#0a0a0a` dark) with a subtle dotted grid (1px dots, ~24px spacing, ~5% opacity).
- Group screens into 3–5 **functional sections** inferred from `screens.md` flows (e.g. bottom-tab screens → one group, auth → one group, detail/sheet screens → one group). Number sections `01 / N`, `02 / N`, …
- Each section shows:
  - `h2` title (20px semibold)
  - one-line sub-copy describing what's interactive in that group
  - a row of 2–3 phone frames (`flex-wrap` or `grid`). Breakpoints: 3/row ≥1100px, 2/row ≥700px, 1/row <700px.
- Small caption above each phone naming the specific screen (e.g. `For You · live feed`).

**Phone wrapper (reusable component)**

- Logical viewport 390×844, rounded bezel (~48px), Dynamic Island notch, status bar (9:41 · signal · wifi · battery), home indicator.
- Scale the wrapper via `transform: scale(…)` — never resize inner content — so screen math stays correct.
- Each `<Phone initialScreen="…">` holds its own independent state. Tapping / scrolling / typing in one phone must not affect any other.

**Global Tweaks toolbar (replaces per-phone controls)**

- One React context + CSS variables on the canvas root; every toggle affects every phone at once.
- Minimum controls: **Theme** (light/dark), **Accent** (brand gradient ↔ flat brand color), **Density** (comfortable/compact).

**Acceptance checks before shipping**

- [ ] Every screen in `screens.md` appears somewhere in the gallery.
- [ ] Scrolling / tapping in one phone does not affect any other.
- [ ] Flipping Theme / Accent / Density changes every phone simultaneously.
- [ ] Nothing is a screenshot — everything is live DOM.
- [ ] On a 1440px viewport, at least one section shows 3 phones per row without overlap.

## 5. What NOT to do

- Do not ask clarifying questions about colors, images, fidelity, interactivity, or dark mode — apply defaults
- Do not generate gray / gradient / empty image placeholders
- Do not invent screens that aren't in the docs
- Do not skip the device frame
- Do not use Lorem Ipsum or `[image]` / `[avatar]` text labels
- Do not omit interactivity ("just static mockups" is wrong)
- Do not render a single phone with in-app tab routing as the whole output — use canvas gallery mode (§4)
- Do not use static screenshots inside phone frames — every frame is live DOM

## 6. Output order

1. Print the inferred design system (tokens table)
2. Print the navigation map
3. Generate the canvas gallery with every screen, grouped into 3–5 sections (§4)
4. Ship the prototype as a single standalone HTML file, offline-capable, no follow-up questions