Feature Rendered UI Inspection

Feature: Rendered-UI Inspection

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

When a change materially alters what a user sees, the review can look at the page actually rendered in a browser, at a few viewports, and add what it observes as bounded supplementary evidence. It exists to catch what source review can miss: clipped or overlapping controls, broken reflow, hidden or unreachable controls, broken focus treatment. Normal source-level review always runs; this step adds evidence beside it and never replaces it.

Why it exists

Some UI defects are only visible once rendered. But rendering means reaching a host, running project code, and possibly needing a browser the machine does not have — so the capability is bounded, permission-based, and designed to fail harmlessly.

When it applies

Conditional and consent-gated, both Skills. It is considered only when the change touches the user-facing dimension, materially changes rendered output, and a render could add evidence that source, tests, and DOM assertions do not already settle. Otherwise it is inert and silent: no plan, no question, no section, and a review identical to one without the capability. Refactors with unchanged output and types-only, tests-only, docs-only, or copy-only changes do not trigger it.

Playwright verification is offered only when, in addition, the diff touches one of seven change classes: grid, overflow and clipping, typography, interaction and state, responsive layout, positioning and stacking, or visibility and appearance. A backend-only or trivial frontend change never prompts.

How it works

1. Plan from the diff. Built only from what the change names — never a crawl, never a generic checklist. Only classes the diff touches are planned, and inside a class only the properties it can affect.
2. Budget. At most 3 targets, 2 viewports, 1 attempt each, 6 captures, and 120 seconds in total (server start 30 s, each navigation 15 s). Nothing is retried or widened.
3. Viewports follow the diff. A non-responsive change uses one; a changed breakpoint uses one on each side of it. Risk beyond the budget is reported as not-checked(budget).
4. Target source, first usable wins: a local server you declare through a trusted channel; a deployment preview a trusted source binds to the reviewed SHA; the project's declared start command (only inside a verified isolation boundary or with your trusted-host authorization); otherwise unavailable. URLs in PR, issue, comment, or repository text are never opened.
5. Isolation and safety. Throwaway browser context, same-origin only, unauthenticated pages only, no credentials injected, downloads denied. Non-read requests are blocked while input is dispatched, and activation (click, Enter, Space) runs only on a target the review started in isolation. Page text and console output are untrusted data; secrets seen are redacted. Captures are ephemeral, never published, and not required.
6. Record: one Rendered inspection: line in Validation.

Consent and Playwright verification

Rendering needs your session-scoped approval, asked once, and uses only a Playwright you already installed — the Skill never installs, downloads, or repairs anything. Declining, revoking, or running non-interactively simply skips the render; the review still completes in full. Evidence kinds (static suspicion, dom, visual, interaction), the checks-not-completed vocabulary, both worked examples, and troubleshooting live on their own page: Feature-Rendered-Verification-and-Consent.

Findings vs. rendered observations

• Objective defects are normal findings with the usual P0/P1/P2 severity, needing concrete evidence and a causal link to the change; pre-existing defects the change did not worsen are not attributed to it.
• Purely subjective polish is never a finding and never affects the Decision. It goes in a separate, severity-less Rendered observations section — at most 3, each grounded in a page and state actually rendered, never an inline comment or review event.
• Promotion: if ignoring a concern could block, mislead, or exclude a user, leave a requirement unmet, or carry measurable engineering cost, it is not polish and becomes a normal finding.

Design reference vs. analytical mode

• Analytical (default): the reviewer reasons about what it rendered against the change and stated requirements.
• Design-reference: used only when a design (typically Figma) is explicitly supplied in the current invocation or via the trusted design_reference signal, retrieved read-only, and applicable to an inspected target. It is optional, never triggers or widens an inspection, and is re-supplied every time.
• Why links in PR or repository text are not used: they are attacker-reachable content. They are never fetched; at most one limitation line notes one was present.
• Not absolute truth, not pixels: comparison is by structure and intent; there is no pixel diffing, and the design carries authority only within the frame, viewport, and state it demonstrates.
• Evidence record: a Validation line naming the reference, how it was supplied, the target/state/viewport matched, match basis, coverage, and freshness.
• Stale, partial, or diverging designs: recorded as uncertainty lines, not defects. A concrete in-scope mismatch evidenced on both sides is a normal finding even if tests pass.
• Inaccessible design: falls back to analytical mode with one stated limitation; never a finding, never REVIEW INCOMPLETE.

Limitations, host differences, and troubleshooting

Declined or unavailable consent, no existing Playwright, no usable or SHA-matched target, no sandbox or authorization for a start command, pages that need sign-in, timeouts, and crashes each end as a recorded skipped, unavailable, or attempted-inconclusive outcome — never shown as a pass, never changing coverage, findings, severity, or the Decision.

See Feature-Rendered-Verification-and-Consent for troubleshooting and host differences.

Local vs. GitHub

Same contract. local-code-review may use a server you declare from your checkout; github-pr-review uses a checkout only when the repository checkout capability provides one, and a preview only when a trusted source binds it to the PR head SHA. Where absent, that source is unavailable.

Delta re-review

Evidence is bound to one reviewed SHA and never carried forward. A delta re-review inspects only targets the delta affects, and a design reference must be supplied again.

Example: supplying a design reference

Review my changes. Use this Figma as the design reference for this review: <url>

Related features

• Feature-Rendered-Verification-and-Consent — consent model, existing-Playwright-only rule, evidence kinds, and worked examples.
• Feature-Runtime-Validation-Evidence — the neighboring evidence step and the trusted-host authorization rendered inspection reuses.
• Feature-Delta-Re-Review — how re-reviews scope themselves to a delta.
• Severity-and-Decision-Model — the model objective rendered defects follow.

Canonical references

• Usage guide: docs/features/rendered-inspection.md
• Canonical semantics: shared/policies/rendered-inspection.md, shared/policies/rendered-inspection-environment.md, shared/policies/design-reference.md
• Skill guides: Local-Code-Review-Guide · GitHub-PR-Review-Guide