Screen Coverage Mandate

A governance rule and a copy-paste prompt for Claude Designs. It exists because early design output was leaning on generic screens and placeholder data. Every screen must be driven by the actual product requirements, not by assumptions.

How to use

Paste the block below into Claude Designs alongside the PDPR Design Prompt. When designing a specific screen, also paste that screen's brief from Foundational Screen Prompts.

The rule

Every feature in QRSETU must have a dedicated, approved design screen. These approved screens are the single source of truth for the product. All future implementation is driven directly from them. No assumptions based on generic screens, placeholder flows, or standard feature sets may be made unless they are explicitly documented.

# QRSETU SCREEN COVERAGE MANDATE (READ BEFORE DESIGNING ANY SCREEN)

1. Every QRSETU feature must have its own dedicated, approved design screen. The approved screens are
   the single source of truth. All engineering implementation is built directly from them.

2. Do not invent screens, flows, fields, or feature sets. Design only what the provided requirements
   document. Do not fall back on generic app patterns, placeholder flows, or a standard SaaS feature
   set. QRSETU is a specific product with specific behavior.

3. Do not use placeholder or lorem data. Use the real field names, real labels, real steps, real
   states, and real copy from the requirements. If a value is unknown, use a realistic QRSETU example
   and mark it clearly as an example, do not fabricate a feature around it.

4. If a requirement is missing or ambiguous, stop and flag it as an open question. Do not assume a
   behavior to fill the gap. A missing requirement is a question to ask, not a blank to guess.

5. Every screen must map to a real feature and a real route in the product, and must name that route
   and its target component (see the handoff structure in the PDPR).

6. Design the complete screen, not just the happy path: include empty, loading, success, error,
   permission, and edge-case states as defined for that screen.

7. Respect all global rules from the PDPR: no hardcoded colors (tokens only), the 3XL rounded corner
   signature, Apple Human Interface influence, native mobile via Expo and an installed-app desktop
   experience, mandatory light and dark, and no em dashes anywhere.

8. Priority order: design the core foundation first (landing, onboarding, authentication, default
   dashboard, profile, settings, and the app shell), then move to individual feature screens. Do not
   design a feature screen before its requirements are documented and approved.

If you would otherwise assume something, ask instead.

Coverage expectation

A feature is not considered design-complete until it has an approved screen (or set of screens) for every state and every platform (mobile and desktop). Implementation must be replicable from those screens with pixel-perfect accuracy and no feature drift. See Design to Code Workflow for how screens map to code, and Foundational Screen Prompts for the first set of briefs.

Priority foundation

Design these first, in this order, using the grounded briefs on the next page:

1. Landing page
2. Sign up
3. Login and password reset
4. Admin login
5. Onboarding flow
6. Default dashboard
7. Profile
8. Settings
9. The authenticated app shell (navigation for mobile and desktop)

Any other foundational platform screen that already exists or is planned must also get a brief before its feature work begins.