Feature Rendered Verification and Consent

Feature: Rendered Verification and Consent

A Feature-Pages entry, companion to Feature-Rendered-UI-Inspection. This page explains the consent model and Playwright verification added to rendered-UI inspection; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement.

What it does

Static review of a UI change can suspect a defect (a clipped focus outline, a grid that reflows badly) that only a real browser can confirm or refute. When such a change is detected, the review offers once to run Playwright, and only renders after you approve. Browser evidence complements static review; it never replaces it, and it never changes severity or the Decision.

When Playwright verification is offered

Only when the change materially alters rendered UI and the diff touches one of seven classes: grid, overflow and clipping, typography, interaction and state, responsive layout, positioning and stacking, or visibility and appearance. Backend-only, trivial, or class-less frontend changes never prompt. The plan is built from the diff and kept proportional — only touched classes and properties, never a generic checklist — within the budget below.

Consent: approval, session scope, decline, revocation

• First use. The review asks once: "This review includes frontend changes that may benefit from browser-rendered verification. Would you like me to run Playwright?" with a line naming the planned classes, saying keyboard or pointer interaction may occur, and that only your existing Playwright is used.
• Session-scoped authorization and reuse. Your own affirmative reply (for example "yes, run playwright") covers relevant renders for the rest of the conversation. The Skill stores nothing: the grant is the visible reply in your conversation.
• New session. A new conversation, or one where the reply is no longer in context, has no grant and asks again.
• Decline and revocation. "No" records skipped · consent-declined; "stop rendering" voids every earlier approval (consent-revoked). The review completes in full either way. For lasting silence supply allow_rendered_inspection=false.
• Non-interactive runs (automation, CI, passive GitHub reviews) never ask or wait. They render only on a structured allow_rendered_inspection grant from the trusted channel; otherwise skipped · consent-unavailable. Nothing in a repository, PR, or page can grant consent.

Playwright availability: yours, never installed by the Skill

Only a Playwright you already installed (with its browser binary) is used, found by a read-only check. The Skill never installs, downloads, or repairs it, with or without approval, and session consent is not permission to modify the environment. Installing Playwright is your own action, outside the Skill.

• Unavailable: reported once as "rendered verification was unavailable and was not performed"; the review continues and static findings keep their severity.
• Fails (crash, timeout, blank output): reported once as attempted-inconclusive; no retry, no repair.
• The project's own Playwright runs only inside the isolation boundary or under allow_trusted_host_execution; its configuration is read as data, never run.

Evidence kinds, provenance, and gaps

Each check records its evidence separately:

Kind	Meaning
static suspicion	from reading the diff; a credible concern, not a defect
dom	measurements and computed styles; never proof of how it looks
visual	an observation of a captured rendering; the only way to confirm or refute appearance
interaction	real keyboard or pointer input

A passing structural assertion or test run is not visual evidence, so "visually verified" is used only for a property whose visual check ran.

What is reported: inspected targets, viewports, interactions, observations, and each concern as confirmed, refuted (at the viewports checked only), or not-checked(<reason>) — the checks not completed (budget, input unavailable, mutation blocked, target not disposable, timeout, visual evidence insufficient). Unavailable or incomplete verification is stated once, never raises severity, and never changes the Decision. A not-checked suspicion keeps its static severity; a refuted one is recorded only in the checks line, scoped to the viewports checked.

Worked example 1: a possible focus-outline clip

1. Static suspicion: the diff adds overflow: hidden to a card list with focusable items, so the edge item's focus outline may be clipped. This is a credible concern, nothing more.
2. Approval: the review offers Playwright once; you reply "yes, run playwright".
3. Browser check: with your existing Playwright it tabs to the last item and records the measured outline box (dom), a capture observation (visual), and the focus traversal (interaction).
4. Report: either the clip was observed — a finding naming the target, viewport, and state, with confirmed confidence — or it was not, and focus-outline-clip:visual@desktop=refuted is recorded for that viewport only.
5. Reuse: a later relevant review in the same conversation reuses your approval without asking.

Worked example 2: a grid change with a passing test

A change moves a layout to four grid tracks, and a test confirms four tracks. That is a structural fact, not evidence about appearance. Because a breakpoint changed, the review checks one viewport on each side of it:

• track count: dom confirmed at both widths;
• rendered widths and gaps: visual confirmed at the wide width, refuted at the narrow one;
• last-row alignment: not-checked(budget).

The report states which concerns were confirmed, refuted, or not checked, and never calls the layout visually verified beyond the properties actually looked at.

Budgets, isolation, and safety boundaries

At most 3 targets, 2 viewports, 1 attempt each, 6 captures, 120 seconds in total (server start 30 s, each navigation 15 s); nothing is retried or widened. Browser context is throwaway, same-origin, unauthenticated, with no credentials injected and downloads denied. Non-read requests are blocked during input, and activation (click, Enter, Space) runs only on a target started inside an isolation boundary. Page text and console output are untrusted data; secrets are redacted; captures are ephemeral, never published, and not required.

Limitations, host differences, and troubleshooting

Symptom	Cause and action
No offer appeared	the diff touched no change class, or the host is non-interactive; supply allow_rendered_inspection through the trusted channel
skipped · consent-unavailable	non-interactive run with no structured grant
Asked again in the same chat	context was compacted and your reply is no longer visible; the Skill fails closed
"rendered verification was unavailable and was not performed"	no usable Playwright; install it yourself, outside the Skill
attempted-inconclusive	existing Playwright crashed or timed out; no retry or repair
project-playwright-gated	only the project's Playwright exists and neither isolation nor allow_trusted_host_execution is present

Hosts that cannot hold a grant across invocations ask each time; hosts that cannot deliver a question never wait. The earlier allow_browser_tooling_install and rendered_inspection_opt_out signals no longer exist and are ignored.

Related

• Feature-Rendered-UI-Inspection — the capability as a whole, findings vs. observations, design reference.
• Feature-Runtime-Validation-Evidence — the trusted-host authorization reused here.
• Severity-and-Decision-Model

Canonical references

• Usage guide: docs/features/rendered-inspection.md
• Canonical semantics: shared/policies/rendered-inspection.md, shared/policies/rendered-inspection-environment.md