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.