UI review

The render is the evidence. A description, DOM text or source code only supports it. Severity, the 13 criteria and the edge cases are in references/criteria.md. An installed design system's own rules come first and count as agreed criteria.

Steps

1. Scope. What the caller names, else the branch's changed screens, else the five top routes.
2. Lint. Run the project's own lint on the scoped files. Record the command and exit code.
3. Capture each screen at each width (the app's narrowest and widest, 390 and 1280 by default) in the states that matter, one fresh navigation per width. With build-design-system installed, build-design-system/scripts/capture.mjs does this behind a guard that blocks every write and saves each capture's accessibility tree. It needs --writes <file> listing the app's writes, or --no-backend, and writes only to its --out folder (keep that under .ui-review/). Otherwise use the host's browser tool and save the tree yourself. Run the project's accessibility scanner too when it has one.
4. Fix the purpose of each screen in one line. Mark it assumed when the caller did not give it.
5. Probe the traps each screen has, on a local build only: keyboard path, focus after close, loading and error states, a throttled tab, reduced motion, and a touch width. Each probe gets a measured result or a reason it did not run. Measure press feedback with the Event Timing API (a PerformanceObserver on event entries, each duration under 100 ms). Do not click anything that writes to shared data.
6. Walk the criteria at each width. Cite each finding by number and name, or by the installed rule's ID.
7. Sort. With more than one reviewer available (a panel), give each the same prompt and no persona, read only. The coordinator then sorts every finding into blocking, should-fix, note or dismissed, naming who raised it and giving one line of reason. A finding raised by two reviewers on their own is the strongest signal. Dismiss nitpicks, hypotheticals nobody traced to a real call site, and "I would have done it differently". Within a bucket, put surfaces that write data first, then order by places hit. Without a panel, do the same alone.
8. Walk the edge cases and mark each shown or not shown.
9. Write the verdict last.

Rules