chore: playwright

.claude/commands/e2e-all.md

@@ -0,0 +1,80 @@
+# E2E Test Runner - All Tests (OSS + Enterprise)
+
+**IMMEDIATELY run all E2E tests (both OSS and enterprise), analyze failures, fix them, and re-run failed tests until all pass or unfixable issues are identified.**
+
+## Prerequisites
+Read `.claude/context/e2e.md` for full E2E configuration details and setup requirements.
+
+## Workflow
+
+**IMPORTANT: Always start by changing to the frontend directory** - the `.env` file and dependencies are located there.
+
+1. **RUN TESTS NOW** from the frontend directory:
+   ```bash
+   cd frontend
+   E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=20 npm run test -- --quiet
+   ```
+
+   **Note:** Using `E2E_RETRIES=0` to fail fast on first failure for immediate analysis and fixing.
+
+2. **If ANY tests fail:**
+
+   For EACH failed test, **ALWAYS READ TRACES FIRST:**
+
+   a. **Read error-context.md** in the failed test directory:
+      - Check `frontend/e2e/test-results/<test-directory>/error-context.md`
+      - Shows exact DOM state when test failed
+      - YAML tree with all elements, their states, and data-test attributes
+      - Check if expected elements exist and their actual values
+      - Verify selector is correct by searching for the data-test attribute
+
+   b. **If error-context.md doesn't show the issue**, unzip and check trace files:
+      ```bash
+      cd frontend/e2e/test-results/<failed-test-directory>
+      unzip -q trace.zip
+      grep -i "error\|failed" 0-trace.network  # Check for network errors
+      ```
+
+   c. **Only after analysing traces**, read the test file and fix:
+      - Wrong selector → Update to match actual DOM from error-context.md
+      - Missing `data-test` attribute → Add it to the component
+      - Element hidden → Filter for visible elements or wait for visibility
+      - Missing wait → Add appropriate `waitFor*` calls
+      - Race condition → Add network waits, increase timeouts, or use more specific waits
+      - Flaky element interaction → Add `scrollIntoView` or `waitForVisible` before clicking
+
+   d. **After making fixes**, re-run ONLY the failed tests:
+      ```bash
+      cd frontend
+      E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=1 npm run test -- tests/flag-tests.pw.ts tests/invite-test.pw.ts
+      ```
+      - Use `E2E_RETRIES=0` to fail fast and see if the fix worked
+      - Use concurrency=1 to avoid race conditions
+      - Only run the specific test files that failed
+
+   e. **Repeat the fix/re-run cycle:**
+      - If tests still fail after fixes but the error changed, analyse the new error and fix again
+      - Re-run failed tests after each fix attempt
+      - Continue until all tests pass or you've identified unfixable issues
+      - Maximum 3 fix/re-run cycles per test before reporting as unfixable
+
+3. **Report final results:**
+   - Break down results by category:
+     - OSS tests: X passed / Y failed
+     - Enterprise tests: X passed / Y failed
+     - Total: X passed / Y failed
+   - List which tests passed/failed
+   - Document any fixes that were applied
+   - For unfixable issues, explain why and suggest manual investigation
+   - Show the error message and line number for any failures
+
+## Important Notes
+
+- **DO NOT** just report that retries passed - if tests failed initially, investigate and fix the root cause
+- **DO** modify test files to fix timing issues, missing waits, or broken selectors
+- **DO** add `data-test` attributes to components if they're missing
+- **DON'T** modify test assertions or business logic unless the test is clearly wrong
+- If the failure is in application code (not test code), report it as a bug but don't try to fix it
+- Always explain what fixes you're attempting and why
+- Test files are in TypeScript and use the `helpers.playwright.ts` helper functions
+- The built-in retry mechanism is a safety net, not a substitute for fixing flaky tests

.claude/commands/e2e-create.md

@@ -0,0 +1,85 @@
+# E2E Test Creator
+
+Create a new E2E test following the existing patterns in the codebase.
+
+## Prerequisites
+Read `.claude/context/e2e.md` for full E2E configuration details, test structure, and debugging guides.
+
+## Workflow
+
+**IMPORTANT: Always start by changing to the frontend directory** - the `.env` file and dependencies are located there.
+
+1. **Ask the user what they want to test:**
+   - What feature/page/flow to test
+   - Any specific scenarios or edge cases
+
+2. **Determine if this is OSS or Enterprise:**
+   - Check if the feature being tested exists in enterprise-only code paths
+   - Look for clues in existing tests that test similar features
+   - If unclear, ask the user
+   - Tag the test with `@oss` or `@enterprise` accordingly
+
+3. **Review existing test patterns:**
+   - Read 2-3 similar existing test files from `frontend/e2e/tests/`
+   - Read `frontend/e2e/helpers.playwright.ts` to understand available utilities
+   - Note common patterns like:
+     - Login flow
+     - Navigation
+     - Element selection using `data-test` attributes
+     - Waiting for elements/network
+     - Assertions
+
+4. **Scan the relevant application code:**
+   - Find the components/pages being tested in `frontend/web/components/` or `frontend/common/`
+   - Check if elements already have `data-test` attributes
+   - If missing, add `data-test` attributes to make tests reliable:
+     - Use descriptive names like `data-test="create-feature-btn"`
+     - Follow existing naming patterns in the codebase
+     - Add them to buttons, inputs, and key interactive elements
+
+5. **Create the test file:**
+   - Follow the naming convention: `*-test.pw.ts` or `*-tests.pw.ts`
+   - Use the test structure from existing tests
+   - Use helper functions from `helpers.playwright.ts`
+   - Include proper test descriptions and tags
+   - Add comments explaining complex test logic
+
+6. **Run the new test to verify it works:**
+   - Run the test 2-3 times to ensure it's stable:
+     ```bash
+     cd frontend
+     SKIP_BUNDLE=1 E2E_CONCURRENCY=1 npm run test -- tests/new-test.pw.ts --quiet
+     ```
+   - **If the test fails, ALWAYS READ TRACES FIRST:**
+     1. **Read error-context.md** in the failed test directory:
+        - Shows exact DOM state when test failed
+        - YAML tree with all elements, their states, and data-test attributes
+        - Check if expected elements exist and their actual values
+        - Verify selector is correct by searching for the data-test attribute
+     2. **If error-context.md doesn't show the issue**, unzip and check trace files:
+        ```bash
+        cd frontend/e2e/test-results/<failed-test-directory>
+        unzip -q trace.zip
+        grep -i "error\|failed" 0-trace.network  # Check for network errors
+        ```
+     3. **Only after analyzing traces**, fix the issue:
+        - Wrong selector → Update to match actual DOM from error-context.md
+        - Missing `data-test` attribute → Add it to the component
+        - Element hidden → Filter for visible elements or wait for visibility
+        - Missing wait → Add appropriate `waitFor*` calls
+     - Re-run until it passes consistently
+
+7. **Report what was created:**
+   - Show the test file path
+   - List any `data-test` attributes that were added
+   - Report test stability (how many runs passed/failed)
+   - If there were failures, explain what was fixed
+
+## Important Notes
+
+- Always use `data-test` attributes for selectors, not CSS classes or IDs
+- Use existing helper functions instead of raw Playwright APIs
+- Follow the login pattern from other tests
+- Tests should be independent and not rely on order of execution
+- Use descriptive test names that explain what's being tested
+- Add appropriate waits for async operations

.claude/commands/e2e-ee.md

@@ -0,0 +1,96 @@
+# E2E Enterprise Test Runner with Auto-Fix
+
+**IMMEDIATELY run enterprise E2E tests (tagged with @enterprise), analyze failures, fix them, and re-run failed tests until all pass or unfixable issues are identified.**
+
+## Prerequisites
+Read `.claude/context/e2e.md` for full E2E configuration details and setup requirements.
+
+## Workflow
+
+**IMPORTANT: Always start by changing to the frontend directory** - the `.env` file and dependencies are located there.
+
+1. **RUN TESTS NOW** from the frontend directory:
+   ```bash
+   cd frontend
+   E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=20 npm run test -- --grep @enterprise --quiet
+   ```
+
+   **Note:** Using `E2E_RETRIES=0` to fail fast on first failure for immediate analysis and fixing.
+
+2. **ALWAYS check for flaky tests after test run completes:**
+
+   **CRITICAL:** Tests that fail initially but pass on retry are FLAKY and MUST be investigated, even if the final result shows all tests passed.
+
+   a. Check the test output for any tests that failed on first run (look for the initial failure messages before "Retrying")
+
+   b. For EACH test that failed initially (even if it passed on retry):
+      - Parse the error from the test output:
+        * Error type (e.g., `TimeoutError`, `AssertionError`)
+        * Error message (e.g., `"waiting for locator('#button') to be visible"`)
+        * File path and line number where it failed
+        * Stack trace showing the call chain
+      - Read the test file at the failing line number to understand what was being tested
+      - **Report these as FLAKY TESTS** - they indicate timing issues, race conditions, or environmental problems
+      - **Analyze the root cause**:
+        * Timeout errors → likely missing waits or race conditions
+        * Assertion errors → check if value is correct or if timing is off
+        * Element not found → selector may have changed or element loads slowly
+
+   c. **If ANY tests are still failing after automatic retries:**
+
+      For EACH failed test, **ALWAYS READ TRACES FIRST:**
+
+      1. **Read error-context.md** in the failed test directory:
+         - Shows exact DOM state when test failed
+         - YAML tree with all elements, their states, and data-test attributes
+         - Check if expected elements exist and their actual values
+         - Verify selector is correct by searching for the data-test attribute
+
+      2. **If error-context.md doesn't show the issue**, unzip and check trace files:
+         ```bash
+         cd frontend/e2e/test-results/<failed-test-directory>
+         unzip -q trace.zip
+         grep -i "error\|failed" 0-trace.network  # Check for network errors
+         ```
+
+      3. **Only after analyzing traces**, read the test file and fix:
+        - Wrong selector → Update to match actual DOM from error-context.md
+        - Missing `data-test` attribute → Add it to the component
+        - Element hidden → Filter for visible elements or wait for visibility
+        - Missing wait → Add appropriate `waitFor*` calls
+        - Race condition → Add network waits, increase timeouts, or use more specific waits
+        - Flaky element interaction → Add `scrollIntoView` or `waitForVisible` before clicking
+
+   d. **After making fixes**, re-run ONLY the failed tests:
+      ```bash
+      cd frontend
+      E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=1 npm run test -- tests/flag-tests.pw.ts tests/invite-test.pw.ts --grep @enterprise
+      ```
+      - Use `E2E_RETRIES=0` to fail fast and see if the fix worked
+      - Use concurrency=1 to avoid race conditions
+      - Only run the specific test files that failed
+      - Include `--grep @enterprise` to ensure only enterprise tests run
+
+   e. **Repeat the fix/re-run cycle:**
+      - If tests still fail after fixes but the error changed, analyze the new error and fix again
+      - Re-run failed tests after each fix attempt
+      - Continue until all tests pass or you've identified unfixable issues
+      - Maximum 3 fix/re-run cycles per test before reporting as unfixable
+
+3. **Report final results:**
+   - **ALWAYS report flaky tests first** (tests that failed initially but passed on retry)
+   - List which tests passed/failed after all retries
+   - Document any fixes that were applied
+   - For unfixable issues, explain why and suggest manual investigation
+   - Show the error message and line number for any failures
+
+## Important Notes
+
+- **DO NOT** just report that retries passed - if tests failed initially, investigate and fix the root cause
+- **DO** modify test files to fix timing issues, missing waits, or broken selectors
+- **DO** add `data-test` attributes to components if they're missing
+- **DON'T** modify test assertions or business logic unless the test is clearly wrong
+- If the failure is in application code (not test code), report it as a bug but don't try to fix it
+- Always explain what fixes you're attempting and why
+- Test files are in TypeScript and use the `helpers.playwright.ts` helper functions
+- The built-in retry mechanism is a safety net, not a substitute for fixing flaky tests

.claude/commands/e2e.md

@@ -0,0 +1,95 @@
+# E2E Test Runner with Auto-Fix
+
+**IMMEDIATELY run OSS (non-enterprise) E2E tests, analyze failures, fix them, and re-run failed tests until all pass or unfixable issues are identified.**
+
+## Prerequisites
+Read `.claude/context/e2e.md` for full E2E configuration details and setup requirements.
+
+## Workflow
+
+**IMPORTANT: Always start by changing to the frontend directory** - the `.env` file and dependencies are located there.
+
+1. **RUN TESTS NOW** from the frontend directory:
+   ```bash
+   cd frontend
+   E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=20 npm run test -- --grep-invert @enterprise --quiet
+   ```
+
+   **Note:** Using `E2E_RETRIES=0` to fail fast on first failure for immediate analysis and fixing.
+
+2. **ALWAYS check for flaky tests after test run completes:**
+
+   **CRITICAL:** Tests that fail initially but pass on retry are FLAKY and MUST be investigated, even if the final result shows all tests passed.
+
+   a. Check the test output for any tests that failed on first run (look for the initial failure messages before "Retrying")
+
+   b. For EACH test that failed initially (even if it passed on retry):
+      - Parse the error from the test output:
+        * Error type (e.g., `TimeoutError`, `AssertionError`)
+        * Error message (e.g., `"waiting for locator('#button') to be visible"`)
+        * File path and line number where it failed
+        * Stack trace showing the call chain
+      - Read the test file at the failing line number to understand what was being tested
+      - **Report these as FLAKY TESTS** - they indicate timing issues, race conditions, or environmental problems
+      - **Analyze the root cause**:
+        * Timeout errors → likely missing waits or race conditions
+        * Assertion errors → check if value is correct or if timing is off
+        * Element not found → selector may have changed or element loads slowly
+
+   c. **If ANY tests are still failing after automatic retries:**
+
+      For EACH failed test, **ALWAYS READ TRACES FIRST:**
+
+      1. **Read error-context.md** in the failed test directory:
+         - Shows exact DOM state when test failed
+         - YAML tree with all elements, their states, and data-test attributes
+         - Check if expected elements exist and their actual values
+         - Verify selector is correct by searching for the data-test attribute
+
+      2. **If error-context.md doesn't show the issue**, unzip and check trace files:
+         ```bash
+         cd frontend/e2e/test-results/<failed-test-directory>
+         unzip -q trace.zip
+         grep -i "error\|failed" 0-trace.network  # Check for network errors
+         ```
+
+      3. **Only after analyzing traces**, read the test file and fix:
+        - Wrong selector → Update to match actual DOM from error-context.md
+        - Missing `data-test` attribute → Add it to the component
+        - Element hidden → Filter for visible elements or wait for visibility
+        - Missing wait → Add appropriate `waitFor*` calls
+        - Race condition → Add network waits, increase timeouts, or use more specific waits
+        - Flaky element interaction → Add `scrollIntoView` or `waitForVisible` before clicking
+
+   d. **After making fixes**, re-run ONLY the failed tests:
+      ```bash
+      cd frontend
+      E2E_RETRIES=0 SKIP_BUNDLE=1 E2E_CONCURRENCY=1 npm run test -- tests/flag-tests.pw.ts tests/invite-test.pw.ts
+      ```
+      - Use `E2E_RETRIES=0` to fail fast and see if the fix worked
+      - Use concurrency=1 to avoid race conditions
+      - Only run the specific test files that failed
+
+   e. **Repeat the fix/re-run cycle:**
+      - If tests still fail after fixes but the error changed, analyze the new error and fix again
+      - Re-run failed tests after each fix attempt
+      - Continue until all tests pass or you've identified unfixable issues
+      - Maximum 3 fix/re-run cycles per test before reporting as unfixable
+
+3. **Report final results:**
+   - **ALWAYS report flaky tests first** (tests that failed initially but passed on retry)
+   - List which tests passed/failed after all retries
+   - Document any fixes that were applied
+   - For unfixable issues, explain why and suggest manual investigation
+   - Show the error message and line number for any failures
+
+## Important Notes
+
+- **DO NOT** just report that retries passed - if tests failed initially, investigate and fix the root cause
+- **DO** modify test files to fix timing issues, missing waits, or broken selectors
+- **DO** add `data-test` attributes to components if they're missing
+- **DON'T** modify test assertions or business logic unless the test is clearly wrong
+- If the failure is in application code (not test code), report it as a bug but don't try to fix it
+- Always explain what fixes you're attempting and why
+- Test files are in TypeScript and use the `helpers.playwright.ts` helper functions
+- The built-in retry mechanism is a safety net, not a substitute for fixing flaky tests