e2e-testinglisted

# End-user tests that stay stable End-to-end tests earn their bad reputation when they are flaky, slow and entangled with markup. Everything below exists to keep them from being those things: stable selectors, focused flows, Page Objects that hide the DOM, assertions on what a user can see. ## Read the project first Before writing a test, gather the facts — never assume a layout: 1. **The project's conventions**, searched in this order: an explicit path given to you, `.agents/dca/conventions.md`, `.claude/dca/conventions.md`, `AGENTS.md`, `CLAUDE.md`. Look for the end-user test source set, the base URL and how the application is started for tests, any existing base test or base page class, the stable-selector attribute (`data-test`, `data-testid`, `data-qa`), the test framework, and the commands. 2. **The existing tests and Page Objects.** Adopt the local idiom: shared base classes, the selector naming convention, whether Page Objects validate the URL on construction, whether tests chain through return values. 3. **A project with nothing yet**: propose defaults — Playwright plus Page Objects plus a stable-selector attribute plus the project's unit-test framework — and ask before establishing a layout. Establishing one is a stack decision, not part of a story. The discipline below is library-agnostic; the API specifics are not. Default to **Playwright** in any binding; where the project uses Cypress, Selenium or WebDriverIO, adapt and say which you