design-review

Topics in the source

• Design Review — Final Quality Gate
• When
• Input
• The two assessments — ISOLATED, never in the same head
• Part 1 — Deterministic Checks (mechanical, run first)
• Part 2 — Bounded Visual Review
• Findings — P0-P3, NO aggregate score, ever
• Challenger gate — mandatory, in-loop, not a trailing consultation

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. After design-motion (web/webapp) or directly after the mockup (design-ios/ design-android). The last step before reporting

This is an excerpt. Refer to the complete source and its current requirements.