Appearance
Claude Design Screen Reviews
The PDPR, Screen Coverage Mandate, and Foundational Screen Prompts are forward-looking: they tell Claude Designs how to design a screen correctly before it exists. This section is the retrospective half of that loop: for screens that already exist in the Claude Designs prototype project, did they actually come out compliant, and if not, what is the exact fix.
Why this exists
Without this, every review lives once in a chat transcript and is gone. This section makes findings permanent, gives every finding a ready-to-paste Claude Designs prompt, and tracks whether the fix actually landed.
The loop
How to use this in practice:
- Open the relevant page below for the feature you're about to look at in Claude Designs.
- If it says Not yet reviewed, ask Claude Code to review that screen first (it fetches the live file from the Claude Designs project via the design-sync tool, not from memory).
- For each finding marked design-fixable, copy the fenced prompt block as-is and paste it into Claude Designs.
- For each finding marked architecture-gated, do not paste anything into Claude Designs. It links to a
QRS-###in the tracker instead. That gap gets resolved during core architecture planning, and only after a decision is made does a new design-fixable prompt get written to reflect it. - Once you've applied a prompt and Claude Designs has regenerated the screen, tell Claude Code "revalidate
<screen name>". It re-fetches the live file, re-runs the same checks, and appends a dated Revalidation entry under the original finding rather than silently overwriting history.
Status legend
| Status | Meaning |
|---|---|
| ⚪ Not yet reviewed | Listed in the design project's SCREENS.md but no findings logged yet here |
| 🔴 Findings logged | Reviewed, findings written up, prompt(s) not yet sent |
| 🟡 Prompt sent | Prompt pasted into Claude Designs, revalidation not yet requested |
| 🟢 Resolved | Revalidated and the finding no longer reproduces |
| 🔵 Architecture-gated | Not a Claude Designs fix; tracked as a QRS-###, resolved during core architecture planning |
Foundational process gap (read first)
The prototype's actual file structure does not match the Design to Code Workflow mandate
Design to Code Workflow specifies tokens.json, a /components gallery (one file per component, every state), <screen>.mobile.dc.html / <screen>.desktop.dc.html pairs, a prototype-hub.dc.html, and a manifest.json mapping screen → route → component → status.
The live Claude Designs project instead has: CSS token files (not tokens.json), no standalone component gallery, device-split folders (prototype/mobile-console/ vs ui_kits/merchant-console-v2/) instead of .mobile.dc.html / .desktop.dc.html pairs of the same screen, SCREENS.md (a hand-written markdown table) instead of a machine-readable manifest.json with a status field, and no React Native artifacts anywhere (every mobile screen is an HTML phone-frame mockup, not a spec for Expo/RN).
This is logged as QRS-045 in the tracker because it's the reason the mobile and desktop merchant consoles diverged into two different information architectures instead of one responsive design, and because a hand-written markdown file can't drive automated revalidation the way a real manifest with a status field could. Resolving this is a prerequisite for this whole review process to scale past manual file-by-file checks.
Master status table
| Feature / area | Page | Status | Last reviewed |
|---|---|---|---|
| Templates (admin panel) | admin-panel/templates | 🟢 Finding 1 fully resolved (Findings 2-4 still open) | 2026-07-19 (revalidated twice) |
| Subscriptions (admin panel) | admin-panel/subscriptions | 🔴 Findings logged | 2026-07-19 |
| Ad Manager (admin panel) | admin-panel/index | 🔴 Findings logged | 2026-07-19 |
| Ad architecture (cross-cutting) | admin-panel/index | 🔴 Findings logged, corrected post-AdManager review | 2026-07-19 |
| Affiliate / Growth Rewards (admin + console, both tiers) | admin-panel/affiliates | 🟢 All findings resolved (revalidated; fix landed at the token layer) | 2026-07-19 (reviewed + revalidated) |
| Overview, Tenants, Plans, Moderation, RBAC, Billing (admin panel) | admin-panel/index | ⚪ Not yet reviewed | — |
| Public Service Card | service-card-and-flows | 🔴 Findings logged | 2026-07-19 |
| Customer flows (Book, Order, Pay, Review) | service-card-and-flows | ⚪ Not yet reviewed | — |
| Onboarding (first-run experience) | onboarding | 🟢 Validated · consolidation resolved (WelcomeStory → Onboarding, revalidated) | 2026-07-20 |
| Profile & Settings (user console) | profile-and-settings | 🟢 Validated — meets the field brief | 2026-07-19 |
| Merchant console — mobile Home | merchant-console | 🔴 Findings logged | 2026-07-19 |
| Merchant console — remaining mobile screens (Enquiries, Messages, Thread, More, Notifications, Profile, Analytics, Invoices, CardEditor, QRTools, Catalogue, Reviews, Offers, Announcements) | merchant-console | ⚪ Not yet reviewed | — |
Merchant console — desktop (ui_kits/merchant-console-v2) | merchant-console | 🔴 Findings logged (contracts/manifest only; page-level .jsx files not yet read) | 2026-07-19 |
Design system foundation (tokens, ds-base.js) | design-system-foundation | 🔴 Findings logged | 2026-07-19 |
| Prototype hub | not yet given its own page | ⚪ Not yet reviewed | — |
No screen is marked reviewed unless its actual file was fetched and read. Anything above marked Not yet reviewed should stay that way in this table until that happens, rather than being assumed clean.