Make the project’s identity unambiguous
Document the site’s repository or source folder, its build.host project, and its live address. Use that identity when asking an agent for changes. Avoid duplicate projects whose similar names make it unclear which one serves the current site.
Record which integrations and environment variables the app requires, without publishing secret values. A short, current handoff is more useful than a large document that no longer matches the deployment.
Agree on what a finished change means
For content changes, review the rendered page and the links around it. For forms and integrations, test the real success and error states. For navigation or visual changes, inspect narrow and wide layouts and keyboard access.
Keep the acceptance check close to the actual work. A homepage screenshot cannot prove a settings flow, and an unchanged build command cannot prove a newly introduced API connection.
Operate with visible history
After deploying, note the source revision and verify the live result. If a problem appears, use logs and an available earlier deployment to recover while the source is corrected. Preserve the evidence that explains why a change was made.
Review production capacity and access requirements with the team. build.host’s dashboard and agent operations are useful views of the same projects; they do not substitute for an agreed ownership and permission model.