PDPR Design Prompt

PDPR = Product Design Prompt and Requirements. This is a single, exhaustive design brief you can copy and paste directly into Claude Designs to generate the complete QRSETU design system as one source of truth. It carries the full product context, brand, principles, token strategy, component architecture, platform targets, and quality bar.

How to use

Copy everything inside the block below (use the copy button in the top-right of the block) and paste it into Claude Designs as the initial brief. Keep this page as the canonical version. When the vision or brand evolves, update this page first, then regenerate. The output structure this prompt requests (tokens file, component gallery, per-platform screens, Prototype Hub, manifest) is defined in Design to Code Workflow.

Ground-truth values baked in

Primary brand color is the real token from the codebase: --primary: 43 100% 68% (approximately #FFD15C, a warm golden saffron). Secondary/accent coral is 11 100% 65% (approximately #FF6D4D). Ink/foreground navy is 210 48% 24% (approximately #213A57). These are seed values to expand into a full scale, not the finished palette.

# QRSETU DESIGN SYSTEM: MASTER GENERATION BRIEF (PDPR)

You are a Principal Product Designer and Design Systems Architect. Your task is to design and
document the COMPLETE, production-ready design system for QRSETU. This design system is the single
source of truth that governs every UI component, every screen, every workflow, and every future
feature across mobile and desktop. Treat this as a foundational, long-lived system, not a one-off
screen mockup.

Deliver work that is exceptionally premium, refined, and timeless. It must feel thoughtfully crafted
by a senior team, with careful attention to spacing, hierarchy, typography, interaction design, and
visual balance. It must never look like a generic template or an AI-generated application.

=====================================================================
SECTION 0: NON-NEGOTIABLE GLOBAL RULES (READ FIRST, NEVER VIOLATE)
=====================================================================

1. DO NOT use em dashes anywhere in any generated copy, documentation, labels, or examples. Use
   commas, colons, parentheses, or short sentences instead. This applies to every word you produce.

2. NEVER hardcode colors. No hex, rgb, hsl, or named colors may appear inside any component. Every
   color is consumed through a global design token, resolved through the tiered component layer.
   The entire application must be re-themeable centrally by editing tokens alone, with zero component
   edits. The only permitted exception is chart stroke and fill values, and even those should prefer
   tokens.

3. APPLE HUMAN INTERFACE DESIGN is the guiding influence. Follow the spirit of clarity, deference,
   and depth. Content is primary, chrome is quiet, motion communicates meaning.

4. THE 3XL HALF-ROUNDED CORNER SYSTEM is a foundational, non-negotiable brand signature. Outer shells
   and primary surfaces use a large, soft 3XL radius. Inner panels and nested surfaces use a slightly
   smaller but still generous radius. This soft, half-rounded language must be consistent across every
   component on every screen and platform. Never ship sharp or square primary surfaces.

5. MOBILE is built with React Native and Expo to deliver a genuinely native experience. The primary
   audience is mobile-first. Design mobile as a native app, not a shrunken website. Use native
   patterns: safe areas, native tab bars, native navigation transitions, native gestures, haptics.

6. WEB (desktop) must present as a premium, installed desktop application with an app-shell
   experience. It is a Progressive Web App that feels immersive and application-like, not a
   traditional responsive marketing website. Think polished desktop software: a persistent app shell,
   a refined sidebar, calm density, keyboard support, and a command surface.

7. LIGHT AND DARK themes are both mandatory and first-class. Theming is driven centrally through
   tokens. There is never any per-screen or per-page theme branching.

8. Design for BOTH mobile and desktop in every deliverable. Consistency across platforms is required,
   with platform-appropriate adaptation rather than identical layouts.

9. STRUCTURE THE OUTPUT FOR IMPLEMENTATION HANDOFF exactly as defined in Section 18. Every screen is a
   separate file per platform, composed from a shared component gallery that consumes shared tokens,
   linked by a Prototype Hub, and traced by a manifest. These prototypes are the reference for building
   the real React and React Native application, so fidelity, naming parity, and reuse are mandatory.

10. DESIGN ONLY FROM DOCUMENTED REQUIREMENTS. Every QRSETU feature has its own dedicated, approved
    screen that is the single source of truth. Do not invent screens, flows, fields, or feature sets,
    and do not use generic patterns or placeholder data. If a requirement is missing or ambiguous, flag
    it as an open question rather than assuming. Design the foundation first. See the Screen Coverage
    Mandate and the grounded Foundational Screen Prompts in the portal.

=====================================================================
SECTION 1: PRODUCT VISION AND CONTEXT
=====================================================================

QRSETU is one unified platform, not a collection of separate tools. It empowers two overlapping
audiences on shared infrastructure:

A. BUSINESS USERS (primary): small businesses and entrepreneurs, India-first, mobile-first. They use
   three product pillars:
   - QRSetu (Interaction): QR-native service digitization. Digital menu, feedback and reviews, polls,
     lead and inquiry forms, QR codes.
   - Studio, also called My Setu (Presence): a no-code, block-based website builder.
   - BioLink (Aggregation): a link-in-bio hub for social and marketing traffic.

B. INDIVIDUALS (generic): students, researchers, freelancers, job seekers, creators, and anyone with
   everyday personal-productivity needs. They use business-independent generic utilities with no
   business profile required: QR code generator, BioLink, digital card (vCard), forms and polls, and
   reminders. Roadmap generic utilities include invoicing, document and file sharing, and QR-based
   file sharing.

Core principle: a user gets a complete digital operating system where every component shares one
identity, one dataset, and one analytics surface. Value must be instant, with minimal admin overhead.

The design system must serve both audiences and both modes (business and generic) gracefully, with a
calm, welcoming, confidence-inspiring feel for non-technical users.

=====================================================================
SECTION 2: BRAND IDENTITY, PERSONALITY, AND VISUAL LANGUAGE
=====================================================================

Brand personality: warm, trustworthy, modern, effortless, and premium. Approachable for
non-technical small-business owners and individuals, yet refined enough to feel like top-tier
software. Confident but never loud. Helpful but never cluttered.

Visual language:
- Soft, generous rounded geometry (the 3XL corner signature).
- Warm, optimistic accent color with a calm, grounded neutral base.
- Airy spacing, clear hierarchy, and restrained use of color for emphasis.
- Depth through soft, layered elevation rather than heavy borders or hard shadows.
- Content-forward layouts where the interface recedes and the user's data leads.

Seed brand colors (expand into a full accessible scale, do not use these as the only values):
- Primary brand color: HSL 43 100% 68%, approximately #FFD15C, a warm golden saffron. This is the
  current primary used by the platform.
- Secondary accent: HSL 11 100% 65%, approximately #FF6D4D, a warm coral.
- Ink and foreground: HSL 210 48% 24%, approximately #213A57, a deep navy.
- Base background: near white in light mode, with a rich, non-pure-black surface in dark mode.

Deliver logo usage guidance, clear space, minimum sizes, and do and do-not examples as placeholders,
to be finalized with the brand team.

=====================================================================
SECTION 3: DESIGN PRINCIPLES (KEEP CONSISTENT PLATFORM-WIDE)
=====================================================================

1. Clarity first. Every screen has one obvious primary action and a clear hierarchy.
2. Calm and deferential. The interface is quiet so the user's content and tasks lead.
3. Consistency over novelty. Reuse patterns. A control behaves the same everywhere.
4. Soft and premium. The 3XL rounded language, layered elevation, and refined type feel crafted.
5. Instant and forgiving. Fast perceived performance, safe defaults, easy undo, gentle recovery.
6. Accessible by default. Contrast, target size, focus, and motion preferences are built in, not
   bolted on.
7. Trustworthy. Security and privacy states are legible. The user always knows what is happening
   with their data.
8. One system, two platforms. Native on mobile, app-like on desktop, unmistakably the same product.

=====================================================================
SECTION 4: DESIGN TOKEN STRATEGY (THE ONLY SOURCE OF STYLE)
=====================================================================

Produce a complete, layered token architecture. Tokens are the single source of truth. Components
never contain raw style values. Structure tokens in three layers:

- Layer 1, primitive tokens: the raw scales (a color ramp, a type scale, a space scale). Not used
  directly by components.
- Layer 2, semantic tokens: role-based aliases that components consume (surface, surface-muted,
  content-primary, content-secondary, border-subtle, accent, accent-contrast, success, warning,
  danger, info, focus-ring, overlay). Semantic tokens have distinct light and dark values.
- Layer 3, component tokens: optional per-component aliases for the tiered component layer to override
  without touching global semantics.

Token families to define in full, each with light and dark values where relevant:

1. COLOR
   - Full primary ramp derived from the golden saffron seed, plus coral secondary ramp and navy
     neutral ramp, each in steps suitable for backgrounds, borders, text, and states.
   - Semantic roles listed above, mapped for light and dark.
   - State colors: success, warning, danger, info, plus their soft container variants.
   - Contrast pairs guaranteed to meet WCAG AA for text and interactive elements.

2. TYPOGRAPHY
   - A refined, modern, highly legible type system. Recommend a primary UI typeface with strong
     multi-language support suitable for India-first usage, plus a fallback stack.
   - A modular type scale (for example a 1.2 to 1.25 ratio) with named roles: display, title-large,
     title, heading, body-large, body, label, caption, overline.
   - Line height, letter spacing, and weight guidance per role. Support platform dynamic type on
     mobile and comfortable reading measures on desktop.

3. SPACING
   - A consistent 4 and 8 point base scale (for example 2, 4, 8, 12, 16, 20, 24, 32, 40, 48, 64).
   - Guidance on component padding, stack spacing, and section rhythm for both platforms.

4. SIZING
   - Control heights, icon sizes, avatar sizes, minimum touch target of at least 44 by 44 points on
     mobile, and comfortable click targets on desktop. Container max widths for desktop app content.

5. BORDER RADIUS
   - A radius scale that centers the 3XL signature. Define named steps, for example: radius-sm,
     radius-md, radius-lg, radius-xl, radius-2xl, radius-3xl. Outer shells and primary cards use
     radius-3xl. Inner panels use radius-2xl. Small controls use a proportionally reduced radius so
     the soft language stays consistent. State the exact intended values in rem and in points.

6. ELEVATION AND SHADOWS
   - A soft, layered elevation scale (for example level 0 to level 4) using diffuse, low-opacity
     shadows in light mode and subtle luminance or border-based separation in dark mode. Avoid harsh
     or high-contrast drop shadows. Provide the exact shadow token values per level.

7. MOTION
   - Duration tokens (for example 120ms, 180ms, 240ms, 320ms) and easing tokens (a standard ease, an
     entrance ease, an exit ease, and a spring for native interactions). Define which durations map
     to which interaction classes.

8. Z-INDEX AND LAYERING
   - A named z-index scale for base, sticky, dropdown, overlay, modal, toast, and tooltip.

9. BREAKPOINTS AND DENSITY
   - Adaptive breakpoints for the desktop app shell. Define compact, comfortable, and spacious
     density where relevant.

10. ICONOGRAPHY
    - A single, consistent icon family with a defined stroke weight, corner treatment that matches the
      soft brand language, and standard sizes. Provide usage rules, keyline grid, and do and do-not
      guidance. Icons inherit color from tokens, never hardcoded.

Deliver tokens in a platform-neutral format (for example a structured JSON or a documented table)
that maps cleanly to both CSS custom properties for web and a shared theme object for React Native,
so mobile and desktop consume identical semantics.

=====================================================================
SECTION 5: THEMING ARCHITECTURE (CENTRAL, TIERED, PORTABLE)
=====================================================================

- Global primitives and semantic tokens live in a portable, platform-agnostic core with no DOM
  dependencies, so web and the React Native app both consume them.
- A UI Hybrid System: global primitive components define base behavior and consume semantic tokens.
  Tiered wrapper components may override component-level tokens for context, but never introduce raw
  values and never change the core consistency invariants (radius language, type scale, spacing,
  focus, motion, elevation).
- Theme switching (light and dark, and any future brand theming) happens by swapping token values at
  the root, with zero component changes. Document exactly how a component resolves a color from token
  to rendered value on each platform.
- Provide a clear rule: if a designer or developer needs a new color or style, they add or adjust a
  token, they do not inline a value.

=====================================================================
SECTION 6: COMPONENT ARCHITECTURE (ATOMIC, FOUNDATIONAL, COMPOSITE)
=====================================================================

Define the component library in three tiers. For every component, specify anatomy, variants, sizes,
all interaction states, tokens consumed, accessibility notes, and mobile plus desktop behavior.

ATOMIC (primitives): typography, icon, color swatch, button (primary, secondary, tertiary, ghost,
destructive), icon button, input, textarea, select, checkbox, radio, switch, slider, badge, tag,
chip, avatar, tooltip, spinner, skeleton, divider, progress.

FOUNDATIONAL (composed patterns): form field (label, control, helper, error), card, list item, menu,
dropdown, tabs, accordion, dialog and modal, sheet and bottom sheet, popover, toast and snackbar,
banner, segmented control, stepper, pagination, table and data grid, empty state, search field,
date and time pickers, file upload and image uploader, QR display and QR generator surface.

COMPOSITE (product-level): app shell (desktop sidebar plus top bar plus content, mobile tab bar plus
stack), dashboard summary cards, analytics panels, onboarding flow, menu builder surfaces, form
builder surfaces, BioLink editor, settings surfaces, command palette (desktop).

Required states for every interactive component: default, hover (desktop), focus and focus-visible,
active and pressed, selected, disabled, loading, error, and read-only where relevant.

=====================================================================
SECTION 7: LAYOUT SYSTEMS (MOBILE AND DESKTOP)
=====================================================================

MOBILE (React Native, Expo, native feel):
- Respect safe areas and notches. Use a native bottom tab bar for primary navigation and native stack
  transitions for depth.
- One primary action per screen, reachable in the thumb zone. Large, soft, tappable surfaces.
- Use bottom sheets for contextual actions, native pull to refresh, and native gestures.
- Support haptics on key confirmations and errors.

DESKTOP (PWA, installed app shell):
- A persistent app shell: a refined left sidebar for navigation, a quiet top bar for context and
  account, and a spacious content area with a comfortable max width.
- Multi-column layouts, master and detail patterns, and a command palette for power users.
- Keyboard-first support: full tab order, shortcuts, and focus management. It should feel like premium
  desktop software, not a stretched mobile view.
- Windowed, immersive feel appropriate to an installed PWA. Avoid marketing-site tropes.

Provide a responsive and adaptive strategy that adapts layout, density, and navigation per platform
and viewport, rather than simply reflowing a single web layout. Define the app-shell behavior at each
desktop breakpoint (sidebar expanded, collapsed to icons, and any compact state).

=====================================================================
SECTION 8: INTERACTION, MOTION, AND MICRO-INTERACTIONS
=====================================================================

- Motion communicates meaning: entrances build context, exits release it, and transitions preserve
  spatial continuity. Use the motion tokens consistently.
- Micro-interactions on key moments: button press feedback, toggle transitions, successful save,
  validation resolve, item added or removed, tab change, and pull to refresh.
- Prefer spring-based, natural motion on native. Keep desktop motion crisp and quick.
- Always honor reduced-motion preferences by replacing movement with gentle fades or instant states.
- Never animate for decoration alone. Motion must serve clarity.

=====================================================================
SECTION 9: STATE DESIGN (EVERY STATE, EVERY EDGE CASE)
=====================================================================

For every meaningful surface, design all of these states:
- Empty state: first-run, zero data, and cleared or filtered-to-empty. Include a friendly explanation
  and a clear primary action. Empty states must feel intentional and encouraging, never broken.
- Loading state: prefer skeletons that match final layout for content, spinners only for short
  indeterminate waits. Define when to use skeleton versus spinner versus progress. Avoid layout shift.
- Success state: clear, calm confirmation. Inline where possible, toast for background actions.
- Error state: safe, human, actionable messages. Never expose stack traces, table names, or internal
  details. Offer a retry or a next step.
- Partial and mixed state: some items loaded, some failed. Some permissions granted, some not.
- Offline and reconnecting state: clear indication, queued actions where applicable, graceful
  recovery when back online.
- Permission and auth states: signed out, session expired, insufficient role, and onboarding not
  complete.
- Edge cases: very long text and truncation rules, very large lists and virtualization, tiny and
  huge data, slow networks, and future right-to-left support.

=====================================================================
SECTION 10: FORM STANDARDS
=====================================================================

- Clear labels above controls, helper text where useful, and inline errors adjacent to the field.
- Validation timing: validate on blur and on submit, resolve errors as the user corrects them. Do not
  punish the user mid-typing. Align validation semantics with schema-based validation on the backend.
- Show required and optional clearly. Group related fields. Support multi-step forms with a visible
  stepper and safe navigation between steps.
- On mobile, use correct native keyboards per input type, support autofill, and keep the primary
  action visible above the keyboard.
- Disable or show progress on submit to prevent double submission. Preserve user input on error.
- Provide accessible error summaries and focus the first invalid field.

=====================================================================
SECTION 11: NAVIGATION PATTERNS
=====================================================================

- Mobile: native bottom tabs for top-level areas, stack navigation for depth, bottom sheets for
  contextual actions, and a clear back affordance.
- Desktop: persistent sidebar for primary areas, breadcrumbs for depth, and a command palette for
  fast navigation. Preserve scroll and selection where sensible.
- Consistent information architecture across platforms. Support deep linking and predictable back
  behavior. Make the current location always obvious.

=====================================================================
SECTION 12: FEEDBACK MECHANISMS AND UX CONSISTENCY
=====================================================================

- Use toasts for background or non-blocking results, inline feedback for in-context actions, and
  dialogs only for decisions that require attention.
- Destructive actions require a clear, well-labeled confirmation with the consequence stated plainly.
  The destructive action uses the danger token and is never the accidental default.
- Keep language consistent: the same action uses the same verb everywhere. Provide a concise voice and
  tone guide for microcopy that is warm, plain, and reassuring.

=====================================================================
SECTION 13: ACCESSIBILITY AND USABILITY
=====================================================================

- Meet WCAG 2.1 AA at minimum. Guarantee text and interactive contrast through token pairs.
- Minimum touch target of 44 by 44 points on mobile. Visible, high-contrast focus indicators on
  desktop. Full keyboard operability for all interactive elements.
- Support screen readers with proper roles, labels, and reading order on both platforms. Support
  dynamic type and large text without breaking layout.
- Honor reduced motion, reduced transparency, and high-contrast preferences. Never rely on color
  alone to convey meaning. Provide clear, forgiving interactions for non-technical users.

=====================================================================
SECTION 14: SECURITY AND PRIVACY IN UI AND UX
=====================================================================

- Error messages are safe and generic to the user, with no leakage of internal structure, secrets, or
  data belonging to others.
- Make auth and session states legible: signed in identity, session expiry, and re-authentication
  when needed. Handle role-based access gracefully with clear, non-punitive messaging.
- Treat personal data with care: mask sensitive inputs, confirm before sharing or making content
  public, and make public versus private state unmistakable.
- Provide clear account and data controls, including data export and account and data deletion flows,
  in line with privacy expectations. Use trust signals thoughtfully, without dark patterns.
- Never use manipulative or deceptive patterns. Consent and destructive actions are always explicit.

=====================================================================
SECTION 15: BACKEND INTEGRATION CONSIDERATIONS THAT SHAPE UI BEHAVIOR
=====================================================================

The frontend reads through query-cached calls and writes through server functions. Design the UI to
match this reality:
- Loading: show skeletons for initial reads, keep interfaces responsive during background refetches.
- Optimistic updates where safe, with clear rollback and a gentle error if the write fails.
- After a successful write, reflect fresh data by treating the relevant queries as invalidated.
- Error handling maps to typed backend errors: validation, unauthorized, forbidden, not found,
  conflict, and a safe generic server error. Each maps to a specific, human UI treatment.
- Respect rate limits and retries with sensible backoff messaging. Communicate idempotent actions so a
  user is not afraid to retry.
- Define latency budgets and the threshold at which a spinner or skeleton appears, to avoid flicker on
  fast responses. Handle slow and offline networks with queued actions and clear status.

=====================================================================
SECTION 16: FRONTEND IMPLEMENTATION GUIDELINES AND BEST PRACTICES
=====================================================================

- Components consume semantic tokens only. No inline colors, no per-screen theme branching. Theme is
  resolved centrally with a shared helper and a light or dark signal.
- Maintain parity between the React Native app and the web app shell by sharing tokens, semantics, and
  component contracts. Only presentation adapts per platform.
- Keep the domain and design logic platform-agnostic so the shared core can be reused. Document
  component APIs, prop conventions, and naming.
- Provide do and do-not examples for each major component and pattern, including radius, spacing,
  color usage, and motion.

=====================================================================
SECTION 17: DELIVERABLES (WHAT TO PRODUCE)
=====================================================================

Produce a comprehensive, organized design system that includes:
1. A design principles and brand overview.
2. The complete token set in a platform-neutral, documented format, with light and dark values.
3. A full component library with anatomy, variants, states, tokens, and accessibility notes, for both
   mobile and desktop.
4. Layout and app-shell specifications for mobile (native) and desktop (installed PWA).
5. Interaction, motion, and micro-interaction specifications tied to motion tokens.
6. A full catalog of states: empty, loading, success, error, partial, offline, permission, and edge
   cases.
7. Form, navigation, and feedback standards with microcopy guidance.
8. Accessibility, security, and privacy guidelines that shape UI decisions.
9. Representative screen templates for both platforms that demonstrate the system end to end, for
   business mode and generic individual mode.
10. A concise usage and governance guide explaining how to extend the system through tokens and tiered
    components, never through hardcoded values.

=====================================================================
SECTION 18: IMPLEMENTATION HANDOFF ARTIFACT STRUCTURE (MANDATORY)
=====================================================================

These prototypes will be handed to engineers as the reference for building the real application. The
primary objective is that every designed screen can be replicated in the React and React Native
codebase with pixel-perfect accuracy and maximum component reuse, with minimal interpretation. Produce
the output in this exact structure.

FIDELITY PRINCIPLE: pixel-perfect is achieved through shared tokens and shared component contracts, not
by hand-porting HTML. Both the prototype and the code consume the same tokens and the same named
components. React Native is not HTML (no DOM, no cascade, flex-only), so screens are generated per
platform from shared tokens and components, and tokens carry fidelity across the gap.

Directory and file structure to emit:

  /design
    tokens.json                       single source of truth, maps to CSS variables and an RN theme
    /components                        component gallery, one file per component, every state
      button.dc.html  input.dc.html  card.dc.html  ...
    /screens
      /mobile   <screen>.mobile.dc.html
      /desktop  <screen>.desktop.dc.html
    prototype-hub.dc.html             links every screen into a navigable flow, grouped by journey
    manifest.json                     screen to route to React component to platform to status

Rules for each artifact:

1. tokens.json: platform-neutral, layered (primitive, semantic, component), with light and dark values.
   It is the only place style values live. It must map cleanly to web CSS custom properties and to a
   shared React Native theme object so both platforms resolve identical semantics.

2. Component gallery: one file per component, showing all variants, sizes, and states (default, hover,
   focus and focus-visible, active, selected, disabled, loading, error, read-only). Every value comes
   from a token. No hardcoded colors, radii, or spacing.

3. Screen files: one file per screen PER PLATFORM (mobile and desktop separately). Compose only named
   gallery components, never bespoke one-off styling. Reference tokens via variables so each screen
   inherits the theme. Include the screen states (empty, loading, success, error) as toggles or sibling
   files. Embed a spec block in each screen: intended route, target React component name, platform,
   tokens used, and breakpoint.

4. Prototype Hub: a single navigable file linking every screen, grouped by user journey and flow,
   showing both platform variants, so the full application flow and feel can be reviewed before
   development.

5. manifest.json: maps every screen to its route, its target React component, its platform, and its
   status (designed, locked, implemented, verified).

NAMING PARITY (critical): component and screen names in the design must equal the intended React
component and route names. Every gallery component must have a one to one coded counterpart concept in
a global primitives layer plus per-tier overrides (a UI Hybrid System). Build the library once, then
assemble screens from it. This is what removes interpretation during development.

=====================================================================
SECTION 19: QUALITY BAR AND ANTI-PATTERNS
=====================================================================

Achieve a premium, refined, timeless result. Avoid the following:
- Generic template aesthetics or an obviously AI-generated look.
- Hardcoded colors or values anywhere.
- Sharp or square primary surfaces that break the 3XL rounded signature.
- A stretched mobile layout masquerading as a desktop app, or a responsive marketing site feel.
- Heavy shadows, cluttered density, inconsistent spacing, or arbitrary one-off styles.
- Manipulative patterns, unsafe error messages, or inaccessible contrast and targets.
- Em dashes in any generated text.

Every component must feel intentional, balanced, and part of one coherent, high-craft system that can
scale to every future QRSETU screen and feature on both mobile and desktop.

Maintenance

Keep this the canonical copy of the brief. When any of these change, update this page first, then regenerate: the Product Vision, the brand color tokens (see Frontend and the src/index.css token block), or the platform targets (Expo native mobile, installed-PWA desktop). The no-hardcoded-colors rule and the 3XL corner signature are enforced design invariants shared with Coding Standards and CLAUDE.md.