# Execution and safety

## Default execution order

1. Use an already-running local or staging test target when explicitly in scope.
2. If source is present but no target runs, detect the documented start command and show the exact command, ports, data changes, and cleanup. Ask for scoped permission before starting or hosting it.
3. For a UI, use an isolated test browser/profile/context controlled through the available computer-use or browser automation tool.
4. For an API, prefer direct HTTP requests against the isolated local/staging service, plus any user-visible client that consumes the changed contract.
5. For CLIs, jobs, files, or integrations, use the safest real boundary available with synthetic inputs.

Do not use the user’s existing live Chrome session by default. Do not inherit their cookies, browsing history, extensions, open tabs, saved passwords, or logged-in identity.

## Isolated browser contract

- Create a fresh dedicated profile/context for the run.
- Record browser/version, viewport, locale, time zone, permissions, and storage state.
- Reuse that isolated context only within the same run when session continuity is required.
- Close or preserve it according to the pause/resume plan.
- Use computer vision and semantic/accessibility information together; do not rely only on coordinates.
- Capture screenshots, visible state, network/console evidence when available, and stable business IDs.

If isolated execution cannot complete because a required state exists only in the user’s live browser, stop and offer a clearly labeled opt-in live-session attempt. Explain exactly what CARBON would access/change and obtain explicit approval first.

## Credentials and secrets

Prefer environment-variable names such as:

- `CARBON_TEST_USERNAME`
- `CARBON_TEST_PASSWORD`
- `CARBON_TEST_MFA_SECRET`
- `CARBON_TEST_API_TOKEN`
- `CARBON_TEST_CREDENTIALS_FILE`

Ask the user to set variables or provide a local ignored file path. Never ask them to paste secrets into chat, command output, a plan, or a report. Record only which variable/file supplied a credential. Redact secrets from screenshots, logs, traces, URLs, and errors.

`CARBON_TEST_CREDENTIALS_FILE` may point to either:

- a JSON object using only the keys `username`, `password`, `mfaSecret`, and `apiToken`; or
- an env-style file using only `CARBON_TEST_USERNAME`, `CARBON_TEST_PASSWORD`, `CARBON_TEST_MFA_SECRET`, and `CARBON_TEST_API_TOKEN`.

Require owner-only permissions (`0600`) where supported, confirm the file is excluded from version control, read it only for the run that needs it, and do not copy its values into CARBON state. The user owns deletion or rotation after the run; CARBON may remind them but must not delete or rotate credentials without explicit authorization.

## Mutation boundary

Use synthetic users, tenants, records, files, payment-provider test tokens, suppressed notifications, and reversible fixtures.

Treat local cart edits, quantity changes, synthetic addresses, and review-screen navigation as reversible when evidence confirms they have no provider-facing effect. Treat payment authorization/capture, order submission, refunds, cancellations, inventory reservation, tax-service calls, and customer or staff notifications as commits or external side effects; keep them planned until the target is confirmed as a test integration and the user authorizes that boundary.

Keep destructive, high-volume, real-payment, external-notification, privilege-escalation, privacy-invasive, production, and aggressive security cases planned until explicit authorization, isolation, recovery, and stop conditions exist.

Never weaken product controls, disable security, or silently change production-like data to make execution possible.

## Failure behavior

When execution fails:

- distinguish product failure, environment/setup failure, tool limitation, missing credential/data, and unknown outcome;
- preserve evidence and run state before recovery;
- retry only when idempotency/reversibility is known;
- pause rather than converting uncertainty into pass/fail;
- keep remaining independent tests runnable.
