Test and deploy coding changes

Coding tools provide focused test, lint, command, and preview-deployment operations. The available commands depend on the selected coding profile and runtime policy.

Choose proportional verification

Start with the narrowest test that exercises the changed behavior, then run the repository’s normal suite or build. A frontend change should pass its production build. A backend route change should run focused route tests and the service suite.

If a command is not available through a test or lint alias, request command execution and review the exact command in the approval card.

Treat project scripts as code

Package scripts, test hooks, and build tools execute project-controlled code. Review unfamiliar projects before running them, especially when the coding sandbox has network access.

Do not turn off resource, network, or approval controls solely because a build is inconvenient.

Preview a web application

A coding profile can start a bounded web preview when deployment tools are enabled. Record the assigned preview, process status, and port. Stop previews that are no longer needed.

A local preview is not a production deployment. It may use temporary storage, development settings, or an ephemeral process.

Prepare a publication bundle

Before publishing:

1. ensure the workspace origin matches the intended repository;
2. record the remote base branch state;
3. prepare an immutable change bundle;
4. inspect its file list and trusted diff preview;
5. approve the connector publication action.

If the base branch moves, prepare a new bundle. Do not force publication of a stale reviewed artifact.

Report evidence

The completion report should name the tests and builds that actually ran, their result, and any checks that were skipped. A passing narrow test must not be described as proof that unrelated services or browsers work.