Check the app people will actually use

A code change can compile while leaving a button off-screen or a form impossible to submit. The running application supplies evidence that the source and test output alone cannot. Preview belongs in the development task whenever the result has an interface.

Give the interaction an expected result

For a tip calculator, enter a bill of 80, a 20% tip, and four people. You should see a total of $96.00 and $24.00 per person. Then enter zero people and confirm the app explains the invalid input.

That is a stronger check than asking whether the page looks finished. It describes an action and a result that a person or a browser tool can verify. A screenshot can help inspect layout, while clicking and typing check behavior.

For a larger app, choose its main task: submit the form, find the record, or complete the navigation. Try loading, empty, success, and failure states where they apply.

Know who can perform the check

In a Rigless Browser workspace, the agent edits source and you test the result in your browser. The agent cannot run a shell or inspect the live page with screenshot tools. Describe a failure in the conversation, let it correct the source, and repeat the same action.

Hosted workspaces provide Linux tools and can support automated runtime and browser checks through the selected agent. Ask what was actually run and what remains untested. A tool being available does not mean the agent used it or exercised every path.

The preview guide explains static and hosted setup, including the framework-specific commands for making a server reachable.

Include the phone layout

A desktop view can hide mobile failures. Check whether the main control stays reachable, inputs remain readable, dialogs fit the screen, and navigation works without sideways scrolling. Repeat the main task at a phone-sized width, rather than judging only the initial page.

If something breaks, name the control, the screen size, the action, and the observed result. That gives the agent a concrete defect to investigate and gives you a repeatable check after the fix.

Check the public release too

Publishing can use a different build command, environment values, and routing configuration from the development preview. After publishing, open the public URL in a private browser window and repeat the important checks.

Do the same when running an export elsewhere. The code is portable when you can retrieve it; the application is ready in the new environment when its setup and behavior have been verified there.