prototype-to-paritylisted

# Prototype → parity An approved prototype is a **spec, not aspiration**. The default is a 1:1 match — full visual language AND full content/behavior — unless the user explicitly scopes it down. The single biggest failure mode is silently shipping a "phase-1 subset" (or reusing the existing app's look) when a richer prototype was approved; that gets noticed and redone. ## The Iron Rule > Build to the prototype 1:1 the first time. If the prototype implies pulling later-phase > work forward (new content, a whole visual system), do that — or, before deviating, > name the gap and ask. A self-authored phase plan never overrides what the user approved. ## The arc (one phase, your loop between each) ### 1. Extract a faithful parity spec (fan out) Run a small **design-extraction workflow** — parallel facet-extractors, one per concern, each reading the prototype + the current implementation + the real API/data contracts, each returning a structured spec (exact tokens/copy/structure, the current-vs-target delta, and **the real endpoint that backs each UI element**). Typical facets: - **Tokens / visual language** — exact colors (give concrete values, e.g. oklch matching the prototype hex), fonts (which headings use the display face), radii, shadows, spacing; map to the app's existing token system. Flag a11y contrast risks up front. - **Each major surface** — structure, every user-facing string, every interactive affordance. - **Data wiring** — map each card/list/control to a re