UI Regression

Verify that the requested UI works from entry to outcome. Cover the changed surface and its dependencies, without expanding a small edit into an unrelated product audit.

Use the browser tools available and permitted in the current environment. When using the agent-browser CLI, read its skill first. This workflow does not require a particular browser driver or local source access.

Scope and evidence

• Identify the target URL or extension build, environment, affected screens, actions, roles, locales, and dimensions. Inspect source and API contracts when available. For deployed-only QA, derive coverage from visible navigation and the requested workflows.
• Keep a compact coverage ledger in working notes or an existing artifact: screen/action, locale/account state, expected outcome, observed result, evidence, and pass/fail/blocked/not-applicable. Inventory before testing, then update as results arrive. A screenshot does not cover its buttons.
• Record the tested revision or deployed version when observable, browser, viewport, data source, and build mode. Mark unknown revisions explicitly. Compare visuals with matching content, state, and dimensions when a baseline exists.
• When asked to test every function, account for every inventoried action. Do not silently omit blocked checks or impose an arbitrary bug-count stopping point.

Real behavior and safe boundaries

• Exercise the actual UI, API, and persistence together against an authorized environment. A mocked UI test plus a direct endpoint test does not prove their integration.
• Use fixtures or an isolated test environment to reproduce loading, empty, failure, and recovery states. Do not inject failures into production. Keep fixture results separate from live integration and packaged-extension results. Never present simulated playback as real third-party playback.
• Use dedicated test accounts and test-mode resources for side effects. Existing task authorization still applies. QA alone does not authorize payments, emails, production mutations, or broader access. Prefer read-only deployed checks unless the requested workflow authorizes more.
• If credentials, browser capabilities, source access, or external dependencies block a check, record the exact boundary. Continue independent checks. Never bypass browser protections or substitute a mock to claim a pass.

Actions and recovery

• Within the authorized side-effect boundaries, click each affected button, link, menu item, toggle, and submit control. Verify its destination or persisted result. For new-tab links, inspect the new tab and redirects rather than judging the unchanged opener.
• Exercise applicable loading, empty, success, failure, and retry states. Check that busy controls prevent duplicate submissions, retries recover, and success follows confirmation. Deliberately failing a request should not leave the page stuck loading.
• For forms/preferences, test validation, save failure/retry, cancel and Escape, reopening, reload persistence, and preservation of unrelated values. Cover defaults and deselect-all where supported.
• For auth changes, cover signed-out, signed-in, expired-session, sign-out failure/retry, and account switching. Verify protected actions enforce access and account changes do not reuse another user's data.
• For changed credit, quota, or request behavior, verify ownership, fresh versus repeated actions, exhaustion, unlimited access, and duplicate submissions. Use an isolated test backend for failure injection and access-control probes. Do not enumerate or alter real users' records.
• Check relevant direct entry, refresh, back/forward navigation, interruption, and repeated actions. Stop retrying once the failure is understood, especially when requests can create side effects.

Language, layout, and feedback

• Test every in-scope screen in each supported locale, including transient labels and errors. Check language detection/fallback, localized destinations, natural copy, and mixed-language strings.
• Choose narrow, medium, and wide dimensions appropriate to the surface, including actual popup dimensions for extensions. Inspect wrapping, overflow, scroll access, and long labels.
• Compare screenshots for layout, spacing, typography, colors, brand assets, and media. Check media loading, status/type, dimensions, aspect ratio, and playback when affected.
• Exercise keyboard order, focus visibility, accessible names, dialog focus containment/restoration, Escape, and an automated accessibility scan when supported. Check pressed/loading/success/error feedback and reduced motion. Report scan limitations separately from manual checks.
• Inspect console and network errors, failed assets, redirects, and unexpected 4xx/5xx responses. Distinguish intentional failures from regressions. Verify the browser has loaded the current candidate before attributing stale UI to a code defect.

Browser extensions

Apply these checks only to affected extension behavior.

• Load the production build in a supported browser. Exercise the popup, background/service worker, content script, messaging, storage, and host permissions involved. A localhost component preview does not validate extension APIs or browser permissions.
• Check popup close/reopen, extension reload, service-worker restart, and account-change messages where relevant. Verify listeners, timers, and injected UI do not duplicate.
• For player UI, test in-site title navigation, video-element replacement, fullscreen entry/exit, dismissal and intended reopening, dialog pause/resume, and saved filters across titles/accounts. Verify playback effects in the actual player when accessible.
• Inspect the release archive for the intended version, localized metadata, root manifest, referenced assets, and production origins. Exclude QA fixtures, credentials, nested archives, development loaders, and localhost references.

Finish against the tested candidate

• For local changes with source access, run the repository's clean install, applicable tests/lint/type checks, and production build. Test production output when bundling, dependencies, environment, or rendering changed. Deployed-only QA does not require a local checkout or rebuild.
• After a fix, rerun the failed case and affected neighboring flows against the final candidate. Tie evidence to that version. Do not reuse earlier screenshots as proof of later changes.
• Fix within the authorized scope, otherwise report reproducible findings with expected/actual behavior and evidence. A request to inspect a deployed UI does not itself authorize edits or deployment.
• If deployment is requested, resolve release-blocking failures first, then verify the deployed revision, relevant routes, and service health. Check persistent storage/domain bindings when the change or hosting upgrade affects them. A push or healthy root page alone is not deployment proof.
• Report coverage counts with blocked checks kept separate, critical findings, commands run, versions, locales/viewports, evidence links, and remaining risk. Unknown real workflows are not passes, and a successful build is not full QA.
• Keep evidence outside release assets. Exclude task-created QA fixtures from shipping output without deleting existing source fixtures and reset only browser overrides/sessions created for this work. Preserve user tabs and unrelated work.