design-reviewlisted

# /design-review — 3-Lens Design-Fidelity Gate > **Announce on start:** open your reply with "Using /design-review to run the 3-lens fidelity gate." Compare the **implemented UI** against its intended design (the design spec section + the project's established UI conventions). Produce a scorecard, prioritized findings, auto-logged backlog items, and a **PASS / CONDITIONAL / FIX-NOW** verdict. ## Why this gate exists (the lesson, baked in) A redesign can pass thousands of unit tests + type-check + lint + a structural "phase gate" and still ship a wrong UI: token leakage flips a dark app to light, density is off, status labels are raw English instead of localized. **Root cause:** the review verified STRUCTURE + FUNCTION (DOM tree, unit tests, build) but never VISUAL FIDELITY (real screenshots, token coverage, theme/i18n correctness). **Green unit / type / lint ≠ correct UI.** This gate forces a real-browser capture + mechanical checks that a structural snapshot is blind to. ## When to run - After **every frontend sprint / feature**, BEFORE bumping the meta submodule pointer / promoting — a gate, not a courtesy. - Ad-hoc on one route: `/design-review /<route>`. - Input parsing: - `/design-review` → auto-detect changed routes (`git diff --stat <base>...HEAD -- 'src/app/**' 'src/features/**' 'src/widgets/**'` or the equivalent for your project's structure) - `/design-review sprint-S<N>` → review the named sprint's changed routes - `/design-review <route>` → one route