e2e-testinglisted

# End-to-End Testing E2E tests verify real user flows through the browser. Unit tests don't catch CSS, layout, or rendering bugs — runtime verification does. Playwright is the default automation tool (adapt if your project uses Cypress or another); pair it with a browser-inspection tool like Chrome DevTools MCP for visual and network inspection when available. ## When to use - Writing or reviewing E2E tests (Playwright by default, or your framework's equivalent) - Testing form submissions, authentication flows, user journeys - Debugging flaky browser tests - Verifying UI changes render correctly at runtime **Not for:** backend-only changes, CLI tools, code that doesn't run in a browser. API contract testing (use `api-testing`); generating test scaffolds for existing code (use `test-generation`). ## Steps ### 1. Detect the stack Check `package.json` for `@playwright/test`. Detect the frontend framework (React, Vue, Next.js) — it affects waiting strategy and form input handling. Detect auth pattern (session vs token) and rate limiting (throttle middleware in dev causes 429s after ~5 login attempts). ### 2. Choose locators by priority Role-based locators mirror how users and assistive technology interact with the page. They survive refactoring; CSS selectors and test IDs don't. Priority order and code examples — see [references/playwright-rules.md](references/playwright-rules.md). Handle strict mode violations with `{ exact: true }`, scoped locators, or `.first()` — ne