Verify agent work with tests and a browser

The diff adds a loading state. The tests pass. You open the app, click Save twice, and create two records.

A UI change can be correct at the component level and still fail in the running application. The request may finish in an unexpected order. The test may mock away the behavior that caused the bug. Or the browser may be showing an old dev server.

When you delegate a fix, include a verification plan that exercises the behavior where it happens. The agent needs a running app and a browser for that work, and the plan still needs to say what to check.

Reproduce the failure first

Consider a hypothetical project-creation form. On a slow connection, clicking Create twice sends two requests and creates duplicate projects. A useful task starts with the steps that demonstrate it:

Reproduce duplicate project creation when the form receives two submissions before the first request completes. Use development data. Record the observed behavior, add a regression test, and fix the duplicate submission while preserving retry after a failed request. Verify the finished flow in the browser and open a draft PR. Don't merge.

Ask for before-and-after screenshots if a visual comparison will help. For this particular bug, a short interaction recording may be more informative than still images, so request that explicitly if you need it. Keep the artifacts proportional to the change; a tool that screenshots every edit buries the one that matters.

If the agent cannot reproduce the failure, have it report the missing condition. It may need a delayed response or a specific application state. Changing code before resolving that uncertainty makes it harder to know whether the patch fixes the reported bug.

Write a test that fails on the old code

The regression test should submit twice while the first request is pending and check the behavior the application promises. If the expected behavior is one request, assert that one request occurs. Then check that a failure allows the user to try again.

Avoid a test that merely verifies a button has a disabled attribute after rendering a mocked loading state. That can pass while the real event handler still dispatches two requests before the state update takes effect.

Run the test against the original behavior first when practical. Record whether it fails for the expected reason. A failing assertion from a missing environment variable tells you about the setup, not the bug.

After the patch, rerun the regression and the relevant existing checks. If unrelated failures existed before the change, describe them separately. Don't turn "the suite has an existing failure" into "tests passed."

Check the running app

The agent needs the app running from the patched revision, and so do you. Locally that means a spare dev server and a browser you aren't using for anything else, and it means trusting that the agent's copy and yours are the same build.

If your setup doesn't give you that, Hoplite's preview gives you and the agent a URL to the same running revision.

Confirm which branch and revision the process uses. Then repeat the original sequence with development data. For the form example, inspect the pending state, attempt the second submission, and confirm the resulting record count. Also trigger a failed request and retry, because a permanently disabled button would prevent duplicates rather enthusiastically.

Look for browser errors and unexpected requests during that interaction. A screenshot alone cannot establish that the server received one request. Use the application's observable state or appropriate test output to support that part of the claim.

Attach the evidence to the PR

A useful PR description can be short:

• Explain the original reproduction and why it happened.
• Describe the behavior the patch changes.
• List the commands that ran and their results.
• Link the relevant browser evidence and identify anything left unverified.

Keep screenshots and recordings out of the application diff, in a git-ignored directory or attached to the PR. Proof files committed to the source tree become changes someone has to review.

If a reviewer requests a change that affects submission behavior, repeat the relevant verification. Evidence from the previous implementation may no longer support the revised code.

For the next UI bug you delegate, include one reproducible failure and one nearby success case that must keep working. That gives the agent a concrete test target and gives you a shorter path through the finished review.