When to use this profile
Browser QA differs from open-ended browsing: the goal is a repeatable assertion about your own app. Use a staging deployment or an isolated preview, seed known fixture data and collect traces only when a test fails. Give the agent selectors and assertions that describe user behavior, then compare the changed interface against those checks.
Prepare a repeatable environment
- Match Playwright and browser versions and lock fonts and viewport settings for visual checks.
- Prepare disposable test accounts and seed fixture data before each run.
- Set retries deliberately and distinguish flaky infrastructure from an assertion failure.
pnpm --dir /work/project exec playwright test --workers=2Return results the agent can use
- A test report with passing and failing assertions.
- Screenshots, videos or traces for failures.
- A reviewable patch to tests and application code.
Run a deterministic login and navigation test, introduce a known UI regression and confirm the trace explains the failed assertion. Repeat to detect flaky results.
Resources and boundaries
Start with 4 vCPU and 8 GB of RAM, then measure peak memory and task duration on a representative fixture. These are workload planning values, not a benchmark or a provisioned configuration. Use the sandbox cost calculator to estimate running time and retained snapshots.
- Each worker launches browser processes; two workers are a starting profile, not a throughput guarantee.
- Trace files may contain authentication and customer data; sanitize artifacts before sharing.
- Do not run destructive test actions against production accounts.
Keep model inference separate from this execution profile. A hosted model or gpuOS can decide the next action while the CPU environment runs it. The quickstart describes the account workflow and the proposed runtime contract.