Identify the existing project
Use the project name or live address when asking for a change. Your agent should resolve the existing project before operating on it, so an update does not accidentally create a duplicate deployment or change another app.
Read the right logs
Ask for build logs when a deployment will not finish, and runtime logs when a deployed app is failing. Include the action that triggered the problem and roughly when it happened. For example: “Show the latest runtime logs for fieldwork and explain why the contact form fails.” Logs are evidence; a successful build alone does not prove every application flow works.
Change configuration deliberately
Specify whether a variable belongs at build time or runtime. Public frontend values may be compiled into downloadable JavaScript and must not contain secrets. Use the supported credential flow for sensitive values. build.host encrypts stored configuration at rest; redeploy the app to apply changes.
Choose restart, redeploy, or rollback
A restart restarts the current app. A redeployment builds or publishes an updated version of the project. A rollback restores an available earlier deployment. Tell the agent which outcome you want—for example, “Roll fieldwork back to the previous deployment, then check the homepage.”
Verify after the operation
Check the final deployment state, the live URL, and the user flow that matters. If your app depends on an external database or service, restoring frontend code does not automatically reverse changes made in that external system. Report the actual result and any remaining configuration or application issue.