Run TestSprite Frontend

Use TestSprite as an independent cloud browser against an authorized frontend target. Discover repository truth, freeze the verification contract, run exact tests to terminal verdicts, fix the demonstrated layer, deploy the exact artifact, and prove it with a newly triggered run.

For TestSprite backend API work, hand off to the sibling run-testsprite-backend skill. Do not adapt this frontend workflow to backend tests.

Non-negotiable rules

1. Read repository and deployment policy before changing code, TestSprite state, a target, or MCP configuration.
2. Treat every network write, billable run, deployment, project create/update, plan/code/create/cancel operation, MCP mutation, browser mutation, and application side effect as blocked until explicitly authorized.
3. Record authorization scope: account/profile, project/test IDs, exact target origin, intended effect, concurrency, cleanup, rollback/restoration, and retention.
4. Inherit TESTSPRITE_API_KEY without printing or persisting it. Reject inherited endpoint overrides unless the exact TLS endpoint and credential environment are separately authorized.
5. Bind application login/project credentials to the explicitly authorized target origin. Never put credentials in target URLs, plans, source, arguments, logs, or transcripts.
6. Use the CLI only for public HTTP(S) targets. Treat localhost/private-only MCP as an exceptional, disposable, explicitly authorized workflow.
7. Freeze required test IDs and plan identities before execution. Removing, weakening, or reclassifying one after failure changes the contract; it is not remediation.
8. Preserve terminal JSON and run-scoped steps for every run. Preserve an artifact for failed/blocked runs when available, under restricted temporary storage.
9. Final proof must trigger a newly queued run after deployment proof, capture its new run ID/enqueue time/target/code version, and then wait that exact run to a fresh terminal pass.

Reference router