QRSETU Dev Portal

Appearance

Design to Code Workflow ​

How QRSETU turns Claude Designs prototypes into production React and React Native code with pixel-perfect fidelity, maximum reuse, and minimal interpretation. This is the companion to the PDPR Design Prompt: the PDPR generates the artifacts, this page defines how they are structured and consumed.

The fidelity principle ​

Pixel-perfect is not achieved by porting HTML into React by eye. It is achieved when the prototype and the code consume the same design tokens and the same component contracts. Two artifacts carry that fidelity:

  1. A machine-readable token file (colors, type, spacing, radius, shadow, motion).
  2. A component gallery where every component shows every state.

The React web app and the React Native (Expo) app mirror those one to one. Screen files then compose from the gallery and reference the same tokens, so they become reference and QA artifacts rather than something a developer hand-translates. This is also what enforces the no-hardcoded-colors rule across both design and code.

React Native is not HTML

Mobile is Expo and React Native: no DOM, no cascade, flex-only layout, different primitives. A .dc.html file cannot be literally ported into a native view. The desktop target is a web PWA, so HTML maps closely there, but mobile does not. Tokens plus component specs bridge the gap, which is why screens are generated per platform (mobile and desktop separately) from shared tokens and components.

Artifact structure ​

/design
  tokens.json                       the fidelity contract (drives src/index.css + the RN theme)
  /components                       component gallery: every variant, every state
    button.dc.html  input.dc.html  card.dc.html  ...
  /screens
    /mobile   dashboard.mobile.dc.html   digital-menu-items.mobile.dc.html  ...
    /desktop  dashboard.desktop.dc.html  ...
  prototype-hub.dc.html             links every screen into a navigable flow with user journeys
  manifest.json                     screen -> route -> React component -> status

Rules per artifact ​

tokens.json (the contract) ​

  • Platform-neutral. Maps cleanly to CSS custom properties for web (src/index.css) and to a shared theme object for React Native, so both platforms resolve identical semantics.
  • Layered: primitive, semantic, component (see the PDPR token strategy).
  • Light and dark values for every semantic role. This file, not any component, is what changes when the theme changes.
  • One file per component, showing all variants, sizes, and states (default, hover, focus, active, selected, disabled, loading, error, read-only).
  • Every value comes from a token. No hardcoded colors, radii, or spacing.
  • Component names equal the intended React component names (naming parity, below).

Screen files (/screens/{mobile,desktop}/*.dc.html) ​

  • One file per screen per platform. Compose only named gallery components, no bespoke one-off styling.
  • Reference tokens via CSS variables, so a screen inherits the theme automatically.
  • Include the screen's states (empty, loading, success, error) as toggles or sibling files, so developers never guess a state.
  • Embed a spec block: intended route, target React component name, platform, tokens used, breakpoint.

Prototype Hub (prototype-hub.dc.html) ​

  • Links every screen into a fully navigable prototype, grouped by user journey and flow.
  • Lets you review the complete application flow and overall feel before development starts.
  • Shows both platform variants for each screen.

Manifest (manifest.json) ​

  • Maps each screen to its route, its target React component, its platform, and its status (designed, locked, implemented, verified).
  • Implementation becomes a lookup, not an interpretation exercise.

The three things that kill interpretation ​

  1. Naming parity. Component and screen names in Claude Designs equal the React component and route names. The cheapest possible defense against drift.
  2. Traceability manifest. Every screen resolves to a route and a component with a status.
  3. Component parity list. Every gallery component has a one to one coded counterpart in src/components/ui (global primitives) plus per-tier overrides. This is the UI Hybrid System: build the library once, then assemble screens.

Implementation loop ​

  1. Design the tokens, then the gallery, then screens, then the Hub (in that order).
  2. Review the full flow in the Prototype Hub.
  3. Lock the tokens and gallery before building screens downstream.
  4. Build the component library first: map the gallery to src/components/ui and per-tier overrides.
  5. Assemble screens from the coded components, following the manifest.
  6. Verify:
    • Web PWA: screenshot-diff the built screen against its .dc.html.
    • React Native: validate against the spec block and shared tokens, since the renderer differs and a raw pixel diff does not apply.

Governance ​

  • The token file is the only place style values live. New color or style means a new or adjusted token, never an inline value.
  • Update tokens and the gallery first, then regenerate screens. Never edit a screen in isolation in a way that diverges from the gallery.
  • Keep design names and code names in lockstep. A rename happens in both places in the same change.

See also: PDPR Design Prompt · Frontend / UI Hybrid System · Coding Standards.