Rendered UI Finish Gate

Coding agents can produce frontend code that compiles and passes unit tests while still shipping generic, incomplete, or misleading interfaces. Common failures include missing loading and error states, controls that look interactive but do nothing, token drift, inaccessible focus behavior, and responsive layouts that were never rendered at their target widths. A source-only review cannot reliably detect all of these problems.

Add a bounded finish gate after implementation and before merge. The gate compares the rendered interface with a small design contract and checks both behavior and visual evidence:

1. Contract check -- identify the intended hierarchy, content model, tokens, responsive rules, and platform-specific constraints.
2. State check -- enumerate and exercise loading, empty, error, disabled, focus, success, and permission states that the feature can reach.
3. Interaction check -- verify that visible controls have real handlers, keyboard paths, labels, focus treatment, and correct navigation or submission behavior.
4. Render check -- inspect the page at representative viewport sizes and compare the result with the contract, not with a generic template.
5. Finish verdict -- report concrete findings with evidence, severity, and the smallest change needed to resolve each blocking issue.

contract = read_design_contract(change)
states = enumerate_required_states(change)
implementation = inspect_source(change)
rendered = render_at_viewports(change, contract.viewports)

findings = []
findings += check_tokens_and_hierarchy(implementation, contract)
findings += check_state_coverage(implementation, states)
findings += check_interactions(rendered, contract)
findings += check_responsive_rendered_output(rendered, contract)

return verdict(findings, evidence=findings.evidence)

The gate is deliberately separate from product-specific visual taste. It blocks missing behavior and unsupported claims first, then records visual quality findings that a human can review.

• Evidence Grade: medium
• Most Valuable Findings: Source checks catch inert controls and missing branches; rendered checks expose layout and state failures that source checks miss; a written contract makes review criteria repeatable.
• Unverified / Unclear: The best viewport set, severity thresholds, and amount of human review vary by product and platform.

• Require the gate for pull requests that change user-facing web or native UI.
• Ask the implementing agent to write or update the design contract before coding when hierarchy, states, or responsive behavior are unclear.
• Keep the first pass deterministic: inspect changed files, enumerate reachable states, render representative paths, and attach findings to the change.
• Treat missing states, inert controls, broken keyboard paths, and token violations as merge blockers. Treat subjective polish as a review item unless the contract makes it explicit.
• Store the rendered evidence and verdict with the pull request when the project needs an audit trail.

Known implementations

• UIZZE anti-ui-slop Skill -- an implementation that applies contract, state, interaction, and rendered-output checks to coding-agent UI changes.

• Pros: Finds failures that compile-time checks and source-only review miss; makes UI review repeatable; keeps required states and interaction semantics visible; produces actionable evidence rather than a vague quality score.
• Cons: Adds render and review time; requires representative test data and viewport choices; visual comparison can still encode reviewer bias; not every issue can be reduced to a deterministic rule.

• UIZZE anti-ui-slop Skill -- disclosed primary implementation.
• UIZZE public design contract -- example contract covering tokens, typography, states, responsive behavior, and finish criteria.
• Web Content Accessibility Guidelines (WCAG) -- neutral reference for interaction and accessibility requirements.