Check the app before you publish

3 minute read · Projects & Git

Try the behavior you wanted before deciding the app is ready. “The process started” and “the page loaded” are useful checks, but neither proves that a person can complete the intended task.

• Check a complete journey
• Review before sharing
• Define success before asking for a release
• Review captured evidence
• Publish deliberately

Check a complete journey#

For Small Stories, open the list, read each article and return. After adding search, try a matching title, an empty search and no results. For an editor, save a title, reload and confirm the stored value. Ask the agent to run the project’s tests and inspect the relevant API or database result.

Vortex can retain command output, HTTP responses, SQL results, test mail and captured previews as evidence. Open a captured result to inspect it; a result link does not repeat the original query or request.

Review before sharing#

Inspect the diff and commit the version you want to keep. Decide which environment should receive it. Supported project configuration can use command/Forge deployment or saved Vercel integration data, but a publishing path must be configured and authorized.

A failed or partial publish stays visible in its output. Do not treat a successful local preview as a deployed app. Review secrets, test data and access controls before inviting real users.

Continue with saved versions, project environments and test mail.

Define success before asking for a release#

For a feature that saves an article, success includes a valid form submission, a stored row, the API read response and the same article after reload in Preview. Add the invalid-input and empty-result cases that matter. For a visual change, inspect both a wide and narrow view. For an email feature, confirm that the intended message actually reaches the selected test catcher.

Ask the agent to report the commands or user flows checked, their results and any remaining blocker. “Dependencies installed”, “process started” and “HTTP 200” describe different partial checks. A response with incorrect data can still be a failed feature.

Review captured evidence#

Vortex can retain command output, HTTP responses, query results, test mail, files and preview images. Open the relevant result in its tool view when you need detail. Result links inspect the captured result rather than automatically repeating a mutation. Check whether a test used local fixtures or a real external service; those are different levels of verification.

Before sharing evidence, remove private headers, credentials, customer records and unnecessary paths. A screenshot of a real account may contain more sensitive information than the error being reported.

Publish deliberately#

Select the correct project environment and saved deployment connection. Review the exact target and operation, including whether it changes remote data, sends mail or exposes the app publicly. A Git push, Forge action, Vercel action and command-based deployment are separate from starting a local preview.

If a deployment only partly completes, retain the logs and identify which step changed state. Do not report success from the last command alone. Verify the requested public behavior after an authorized release and keep a recovery plan appropriate to that project's infrastructure. This guide does not assume that Vortex supplies hosting or automatically deploys every generated app.