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
• Run the checks for a change
• 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. Vortex does not deploy apps: checks run against the local app, and publishing happens through your own hosting process, for example a push to the repository your host builds from. Decide which environment should receive the change before you start that process.

A failed or partial publish stays visible in that process's own 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, connections 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.

Run the checks for a change#

After an agent run, the change summary can list checks such as an HTTP response, the project's tests, an SQL or API result, a captured mail or a file. Use Run checks again after a fix, Run project tests for the test command, Check the app answers for the local address and Add a check to add one. Restart app and run checks again restarts the local app first. Checks run locally against the app's Local address and Run tests command from Workspace settings; without a Preview address, Vortex asks you to set one there.

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#

Choose the target and the release process outside the local preview. Review the exact operation, including whether it changes remote data, sends mail or exposes the app publicly. A Git push to a branch your host deploys is a release action, separate from starting a local preview, and it needs your explicit authorization when an agent performs it.

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.