Production-target browser checks

Local development, preview environments, and staging are the default targets. Blop also supports an intentionally selected production URL for a flow whose real deployment must be verified. Production is not inferred from branch, configuration, or environment names: the operator supplies the target through --base-url or reviewed baseUrl configuration.

blop test tests/production-smoke.blop.ts \
  --base-url https://app.example.com \
  --report-dir .blop/production-smoke

The command is simple; the operational policy is not. Complete the safeguards below before enabling the check.

Use synthetic identity

• Create dedicated synthetic users, service accounts, and isolated test tenants. Never automate a customer account.
• Grant only the permissions required by the flow. Do not use owner, billing, support impersonation, or global administrator roles.
• Keep credentials in the CI or runtime secret store. Do not place them in the check goal, repository, screenshots, or command line.
• Make synthetic records recognizable without including secrets or personal data, for example with a reserved tenant and email domain.

Bound side effects

• Prefer read-only checks. For writes, use idempotent or reversible operations.
• Define cleanup for every created cart, project, order, file, or invitation. Run cleanup on success, failure, and timeout, and add a TTL backstop.
• Never use real payment credentials. Use provider test mode or a production path designed specifically for synthetic transactions.
• Inventory email, SMS, webhook, analytics, fulfillment, support, and other third-party effects. Disable, sandbox, route, or explicitly accept each one.
• Exclude destructive account, tenant, data-export, and administrator flows by default.

Control execution

• Keep the target URL and allowed flow set in reviewed configuration.
• Rate-limit and identify synthetic traffic so operators can separate it from customer activity and stop it quickly.
• Avoid broad crawls. Run the smallest authored flow that proves the claim.
• Provide a kill switch by disabling the schedule, workflow, or credentials; document who owns it.
• Start manually, observe several clean runs, then schedule conservatively.

Protect evidence

Browser evidence can contain names, account details, URLs, console output, DOM text, and tokens. Treat screenshots, progress files, results.json, events.jsonl, and uploaded report bundles as production data.

• Minimize the evidence captured and keep retention short.
• Review goals and assertions so they do not echo credentials or personal data.
• Restrict artifact access to the operators who need it.
• Confirm the platform project and ingest credentials before upload. Local telemetry and platform run evidence remain separate stores.
• Re-review the policy whenever the flow, permissions, target, or third-party integrations change.

Before enabling a production check

• The target is explicit and reviewed.
• A dedicated least-privilege synthetic identity exists.
• Every write is reversible or has tested cleanup and a TTL.
• Payment, messaging, webhooks, and other external effects are sandboxed or accepted by the owning team.
• Synthetic traffic is identified, rate-limited, and easy to stop.
• Artifact contents, access, upload destination, and retention are reviewed.
• An operator owns failures and cleanup alerts.

For runner setup, continue with Run browser checks with the CLI. For the browser capability boundary, read the Browser Harness security model.