browser-automationlisted

# Browser Automation Use a real browser only when rendered behavior matters: UI state, navigation, forms, auth, screenshots, recordings, accessibility, visual checks, or end-to-end flows. Keep automation temporary unless the user asks for permanent tests. Do not use a browser for plain HTTP API checks or pure logic tests. ## Runtime Selection 1. Prefer a platform built-in browser tool when available in the active tool list. See [`references/platform-browser-tools.md`](references/platform-browser-tools.md). 2. Use the project's configured browser runner when it exists. 3. Use `playwright-skill` only as the bundled fallback/runtime reference. 4. If no runtime is available, report blocked with the missing tool/package. Use the cheapest runtime that proves the claim. ## Workflow 1. Define the goal: explore, validate, screenshot, record, debug, or test. 2. Read needed local context: start scripts, browser config, routes, fixtures, seed/reset docs, and auth notes. 3. Detect or start the dev server. Reuse a reachable server. 4. Use deterministic data: seeded users, fixed dates, stable IDs, reset state, and mocked external services. 5. Drive with semantic targets first: role, label, text, test id; CSS last. 6. Capture artifacts needed to support the result: screenshot, trace, console errors, network failures, accessibility snapshot, or report. 7. Report pass, fail, or blocked. Do not imply success if the check did not run. ## Playwright Fallback Use Playwright wh