---
name: frontend-acceptance-harness
description: Prove that a frontend feature, fix, workflow, redesign, or responsive state works in the actual painted application. Use when source checks, DOM state, or a passing build are insufficient.
---

# Frontend Acceptance Harness

Verify the user's real journey, not merely source code, a passing build, or a changed URL.

## Define The Acceptance Contract

Record the route, starting state, role, viewport, input method, actions, expected painted transitions, persistence behavior, responsive expectations, and accessibility checks. Treat modal behavior, saving, and mobile fit as separate claims.

## Orient To The Runtime

Identify the exact working tree, process, host, port, route, fixture, and verification time. Reuse a healthy intended runtime or start the repository-native one. Run targeted automated gates when practical, but do not treat them as visual acceptance.

## Exercise The Painted Journey

Use the real controls and inspect loading, empty, error, retry, success, disabled, and completed states. Check dialogs, keyboard flow, focus restoration, refresh persistence, back navigation, realistic viewports, clipping, broken media, obscured actions, console errors, failed requests, and stale responses.

## Repair And Replay

When implementation is authorized, reproduce the failure, fix the smallest root cause, rerun code gates, restart or refresh the correct runtime, and replay the same acceptance path. For review-only work, report the failure without editing.

## Produce The Receipt

Report the claim, route or state, viewport, action, observed result, and pass, fail, or blocked status. Distinguish source changed, build passed, runtime live, journey exercised, and visually verified. State every important boundary that was not checked.