design-review

<objective> The final quality gate before any design deliverable is reported done. Runs two assessments that must stay ISOLATED from each other — deterministic detection (grep/count/compute checks) is never performed in the same head as the subjective/visual read, because collapsing them into one pass is exactly how prior AI-slop clusters shipped through this audit undetected. Findings are tagged P0-P3 (Blocking / Major / Minor / Polish) and reported individually — there is NO aggregate score, health score, or letter grade, ever; an aggregated number invites self-grading theater. The visual review is a bounded loop, maximum 2 fix cycles: the loop exits PASS only once the register-applicable positive floors are actually met, and a plateau (cycle 2 repeating cycle 1's finding) stops immediately even at cycle 1 of 2. Before any "done" claim, a mandatory in-loop challenger gate judges the deliverable blind — fresh-context, off a rendered PNG only, never fed this procedure's own reasoning. A Block from the challenger must be resolved or owner-accepted before "done" is reported. </objective> ## Design Review — Final Quality Gate ### When After `design-motion` (web/webapp) or directly after the mockup (`design-ios`/ `design-android`). The last step before reporting any design deliverable done — never skipped, never reported as passed if it wasn't actually run (`references/review-procedure.md` Failure Handling). ### Input - The complete rendered artifact: components/mockup with...