design-review

# design-review ## Language Rule Follow an explicit artifact or audience language when provided. Otherwise, write critique, summaries, and the user-facing verdict in the conversation language according to `<agent-home>/roles/response-policy.md`. Preserve schema keys, check IDs, paths, scores, and status literals. ## Resolve and Check State Find the applicable `design_state.yaml` and require `phases.components: done`. Review the available source and rendered evidence, including `03_components/*.tsx`, validated screenshots, standalone previews, or an explicit user-provided mockup. ## Two-Gate Review Run two distinct gates: 1. **Verifier**: detect breakage, console errors, layout failures, and contract violations. 2. **Critic**: assess the visual and experiential quality of output that passed the hard gate. ### Step 1: Verifier Gate Dispatch the `design/verifier` unit as the `visual-verify` sibling review node, in an independent context. Preserve this two-layer result schema: - `verdict: done | needs_work` - `breakage: has_errors | none` - `vision_passrate: <float>` as passed `[vis]` checks divided by total `[vis]` checks - `status: verified | needs_review | needs_iteration | failed | unavailable` - `layer1_checks[]`: every `[det]` item as `{id, passed, reason}` - `layer2_checks[]`: every `[vis]` item as `{id, dimension, passed, reason}` - `gaps[]`: failed `{dimension, reason}` entries when `needs_work` - `round_cap_hit: true` when a retry ceiling is reached On PASS,...