karvey-mockuplisted

# Karvey Mockup — Navigable HTML Prototype ## Purpose Generate a navigable HTML file with **3–4 levels of depth** before defining the graphic design. The engineer navigates the mockup in the browser, gives feedback, and it's iterated until approval. Crucially, the mockup is then **validated against the requirements** (Step 5B) to surface spec-gaps while they are still cheap to fix — before design, architecture and impl. Only afterward does it advance to graphic design and architecture. > **Why deeper (3–4 levels):** the goal of the mockup is to make the product *real enough* that spec mistakes become visible now, not during testing. A shallow mockup (just shells and lists) hides the decisions that actually break specs — wizards, confirmations, error/empty states, edge flows. Go to a 4th level whenever a flow has a multi-step action, a destructive confirmation, or a non-trivial state machine. ## Target agnosticism The mockup **adapts to the target declared** in `docs/spec/project.json` (the `targets` field) — see `karvey/rules/targets.md`. **Don't assume web by default:** - **web** → navigable HTML (App Shell + views + overlays, as described below) - **mobile (ios/android)** → screen flow (a sequence of screens with transitions, not a desktop sidebar) - **cli** → command transcript (example terminal input/output) - **api/backend** → request/response examples (sample payloads per endpoint) The levels, rules, and HTML structure in the following sections apply to the **web