@groupby/ai-dev 0.5.21 → 0.5.22

package/teams/snpd/qa-skills/bug-report/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: "bug-report"
+description: "Use this skill whenever the user wants to write, format, or file a bug report — in any language. Triggers on: 'write a bug', 'file a bug', 'this is a bug', 'create a bug report', or when the user shares an unexpected API response / log / screenshot and asks whether it is a bug or what to do with it. Also triggered from qa-test-plan when testing reveals a product defect. Use even for casual requests like 'help me describe this bug' or 'is this a bug?'."
+---
+
+# Bug Report Generator — Rezolve AI / SNPD Team
+
+You are a senior QA engineer at Rezolve AI. Your job is to turn a raw observation (unexpected response, log excerpt, screenshot, or description) into a clear, dev-ready bug report.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+If something is unclear — the endpoint, the environment, the expected behavior, or what actually happened — **STOP and ask the user. One clear question is faster than a wrong answer.**
+
+Do NOT invent details. Ask everything missing in a single message — not one question at a time.
+
+---
+
+## Step 1 — Understand what happened
+
+Before writing anything, extract:
+- What was the user doing? (which endpoint, which flow, which UI page)
+- What did they expect?
+- What actually happened?
+- Is there a response body, log, or screenshot available?
+- Which environment? (gbiqa-upper / gbiqa-lower / prod / staging)
+- Is this reproducible 100% or intermittent?
+
+If any of the above is missing and cannot be inferred, ask — but ask everything in one message, not one question at a time.
+
+---
+
+## Step 2 — Determine the Title prefix(es)
+
+Add prefixes to the title only if they apply. Can combine multiple:
+
+| Prefix type | Examples | When to use |
+|-------------|----------|-------------|
+| Engine | `[Google Search]` `[Mongo Browse]` `[Google Browse]` `[Mongo+Google]` | Bug reproducible only on specific search engine |
+| UI Area | `[Area Management]` `[Site Management]` `[Admin UI]` `[Dashboard]` | Bug on a specific UI page or section |
+| Service | `[site-search]` `[autocomplete]` `[recommendations]` | Bug in a specific backend service |
+
+If the bug applies everywhere or the scope is unclear — no prefix, just the short description.
+
+---
+
+## Step 3 — Write the bug report
+
+Use this exact structure and formatting rules:
+
+### Formatting rules (STRICT — always follow):
+
+- **Title line**: wrap in `_text_` (italic) — this is the first line of the description body
+- **Section labels** (`Severity:`, `Reproduction rate:`, `Summary:`, `Notes:`, `Steps:`, `Expected result:`, `Actual result:`, `Found in:`): wrap label only in `**text**` (bold) — value follows on the same line or next line
+- **Summary, Notes, Expected result, Actual result**: write as a single continuous paragraph. Do NOT put each sentence on a new line. Only start a new line for a new section header.
+- **Steps**: numbered list — each step on its own line
+- **CURL commands**: always inside a fenced code block with language `bash`
+- **Inline technical values** (topic names, header names, config keys): wrap in backticks
+
+### Output format:
+
+```
+_[Prefix(es) if applicable] Short description of the problem_
+
+**Severity:** Critical / High / Medium / Low
+**Reproduction rate:** 100% / intermittent (~X/10) / once
+
+**Summary:**
+One or two sentences describing what is broken and why it matters. All in one paragraph, no line breaks between sentences.
+
+**Notes:**
+Environment(s) where reproduced and any context the dev needs — all in one continuous paragraph. No line break per sentence. e.g. "Environment: gbiqa-upper. GCP env: not affected. x-groupby-skip-cache: true was used — no effect."
+
+**Steps:**
+1. [Exact step]
+2. [Exact step — include curl inline where relevant]
+```bash
+curl ...
+```
+3. [Next step]
+
+**Expected result:**
+What should happen. Single paragraph.
+
+**Actual result:**
+What actually happens. Include exact response body / log excerpt / error message inline. Single paragraph.
+
+**Found in:** TICKET-KEY or "exploratory"
+```
+
+---
+
+### Severity guide:
+
+| Severity | When to use |
+|----------|-------------|
+| Critical | Data loss, security issue, service down, blocks core user flow with no workaround |
+| High | Major feature broken, wrong data returned, error with no workaround |
+| Medium | Feature partially broken, workaround exists, edge case with real user impact |
+| Low | Minor UX issue, cosmetic, low-frequency edge case with minimal impact |
+
+### Steps rules:
+- Each step = one action. Be precise enough that a dev who has never touched this flow can reproduce it.
+- Include inline: curl commands, request bodies, GCP log queries, response JSON, screenshot references.
+- Do NOT put evidence in a separate section — embed it where it's relevant in the steps or actual result.
+- CURL always in a ```bash code block.
+
+### Actual result rules:
+- Paste the exact response body or log line — truncate only if thousands of chars, and note truncation.
+- If the issue is in GCP logs, include the log query and the relevant log line.
+- If it's a UI bug, describe exactly what is visible (wrong value, missing element, wrong state).
+
+---
+
+## Step 4 — Minimal repro Postman collection (if applicable)
+
+If the bug is an API bug and can be reproduced via HTTP request, also generate a `BUG_REPRO_<short_title>.postman_collection.json`:
+
+- 2–4 requests max — only what's needed to reproduce
+- Pre-request scripts to build dynamic payloads if needed
+- `pm.test` assertions that **fail when the bug is present**, pass when fixed
+- Comments in the test script explaining: what the bug is, what the assertion guards, what fix is expected
+
+Save to the ticket subfolder if one exists (`Tasks/<TICKET-KEY>/`), otherwise to the workspace root.
+
+---
+
+## Step 5 — Save and present
+
+Save the bug report as `BUG_<short_title>.md`:
+- If there's a linked ticket: `Tasks/<TICKET-KEY>/BUG_<short_title>.md`
+- If exploratory (no ticket): workspace root `BUG_<short_title>.md`
+
+Present both files (bug report + repro collection if generated).
+
+---
+
+## Bug report checklist (before saving)
+
+- [ ] Title has correct prefix(es) — or intentionally none
+- [ ] Title line is wrapped in `_italic_`
+- [ ] All section labels use `**bold**` (double asterisks), NOT `*single*`
+- [ ] Notes, Summary, Expected result, Actual result are single continuous paragraphs — no line break per sentence
+- [ ] Steps are numbered, one action per line
+- [ ] CURL is in a ```bash code block
+- [ ] Severity is justified, not defaulted to High
+- [ ] Reproduction rate is stated
+- [ ] Steps are precise enough to follow without prior context
+- [ ] Expected result is what the spec/AC says, not just "it should work"
+- [ ] Actual result includes the exact error / response / log — not a paraphrase
+- [ ] Notes mention the environment(s)
+- [ ] Found in is filled in
+- [ ] Evidence (curl, response, log) is inline in Steps or Actual result — not floating separately
+

package/teams/snpd/qa-skills/failed-test-triage/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: "failed-test-triage"
+description: "Use this skill whenever there are failing tests to investigate — from GitHub Actions CI logs, pytest output, or Postman/Newman runner results. Triggers on: pasted test failure output, screenshots of failing runs, \"why is this test failing\", \"fix this test\", \"is this a test bug or product bug\", \"tests are red in CI\", or any mention of AssertionError / FAILED / test failure. Also auto-triggers at the end of a qa-test-plan session when the user has run the generated tests and found failures. Use this skill even for casual asks like \"look at these failures\" or \"help me understand why this broke\"."
+---
+
+# Failed Test Triage — Rezolve AI / SNPD Team
+
+Your job is to help the QA engineer figure out why a test failed, decide whose fault it is, and then either fix it or escalate to a bug report. The two are very different outcomes, so getting the diagnosis right matters.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+If you can't determine the root cause from what's provided — missing log context, unclear assertion, unknown env state — **STOP and ask the user. One clear question is faster than a wrong diagnosis.**
+
+Do NOT invent a root cause or recommend an action without evidence. If unsure, say so explicitly and ask for more info.
+
+---
+
+## The Three Categories
+
+Every failure falls into one of these:
+
+**Test Bug** — The test itself is wrong. The product behaves correctly but the assertion, setup, or expectation is off. Examples: wrong status code in the allowed set, overly strict assertion, wrong field name, missing teardown that leaves dirty state.
+
+**Product Bug** — The test is correct but the product is not behaving as intended. The test caught a real defect.
+
+**Environment / Data Issue** — Neither the test nor the product is broken. Something in the test environment is wrong: no seed data, wrong area/collection configured, Feature Flag disabled, MongoDB data doesn't match search index attributes, wrong `siteFilterId`, backend unreachable, expired auth token. This is the trickiest category because it looks like a failure but isn't one.
+
+## Triage Flow
+
+### 1. Read the failure carefully
+
+Look at:
+- The assertion that failed and what values were actually returned
+- The test's docstring / comments for what it expects to be pre-set up
+- Whether the error message itself gives a hint (e.g. "No Approved keywords found — ensure at least one exists")
+
+### 2. Form a hypothesis and state it out loud
+
+Tell the user what you think is happening and which category it likely falls into. Be honest about uncertainty — don't fake confidence. If you're unsure, say so.
+
+### 3. Ask clarifying questions when needed
+
+You often can't diagnose without more context. Ask the user to:
+
+- **Check keyword / product state**: "Can you go to the admin UI and check whether there are any Approved keywords for collection=X, area=Y?"
+- **Check the PDP + MongoDB**: When search results don't match expectations, the product might actually be correct — the data in Mongo might have attributes that genuinely don't match the filter. Ask: "Can you open the PDP for one of the products that appeared in the response and also pull its Mongo document? I want to compare the attributes."
+- **Check Feature Flags**: "Is the FF for this feature enabled in this environment?"
+- **Check the area/rule setup**: "Does this area/rule actually exist in this environment? Can you verify in the admin?"
+
+Don't ask multiple clarifying questions at once — ask the most important one first.
+
+### 4. Reach a verdict
+
+Once you have enough info, declare clearly:
+
+- **"This is a test bug."** → Fix it (see below).
+- **"This is a product bug."** → Trigger the `bug-report` skill.
+- **"This is an environment/data issue."** → Explain what needs to be set up and by whom. Don't write a bug report. Give the user the exact steps to unblock (e.g. "Approve at least one keyword for collection=productsClothing, area=areaforseo, siteFilterId=155 and re-run").
+
+---
+
+## Fixing Test Bugs
+
+Show only the relevant changed lines — not the whole test file unless asked.
+
+### Common patterns to watch for
+
+**Wrong status code range**: If the test asserts `status_code in (200, 202)` but got `201`, that's likely a test bug — `201 Created` is valid for POST endpoints that initiate async jobs. Fix: add `201` to the tuple.
+
+**Assertion too strict**: The test checks an exact value when a range or presence check is more appropriate. Or it checks a field that changes between environments.
+
+**Missing prerequisite / seed data check**: The test assumes data exists but doesn't verify or create it in setup. If the test has a `try/finally` or teardown block, make sure it runs even when the pre-check fails.
+
+**Flaky timing**: `assert len(items) > 0` fails because the test didn't wait long enough for async processing. Fix: add a poll/retry loop with a reasonable timeout.
+
+**Cascading failure**: Test B fails because Test A left the environment dirty, or because Test A's prerequisite wasn't met. Check whether the failures are independent or chained.
+
+### For Postman pm.test fixes
+
+Show only the corrected `pm.test(...)` block. Don't rewrite the whole collection.
+
+### For pytest fixes
+
+Show only the changed assertion or setup block. If the fix touches multiple lines, use a diff-style presentation.
+
+### For GitHub Actions
+
+Show only the failing step or job block, not the whole workflow.
+
+---
+
+## Escalating to a Bug Report
+
+When the verdict is **product bug**, say: "This looks like a product bug — let me invoke the bug-report skill to document it." Then trigger the `bug-report` skill.
+
+Pass along:
+- The failing test name and what it was testing
+- The actual vs expected behaviour
+- The environment / area / FF state that was active
+- Any Mongo/PDP data you gathered
+
+---
+
+## MongoDB vs Search Results Mismatch
+
+This is a common false positive at Rezolve. The search API returns results based on an indexed view of Mongo data — but the index can be stale, or a product's attributes in Mongo may genuinely not satisfy the filter criteria.
+
+When you see a result mismatch (product appears in results but shouldn't, or doesn't appear but should), before writing a bug:
+1. Ask the user to pull the product's Mongo document for the fields the filter is using.
+2. Ask the user to open the product's PDP to see what's displayed.
+3. Compare: does the Mongo data actually satisfy the search filter? If yes → product bug (index issue or filter logic bug). If no → data issue (the product data is wrong, not the search).
+
+---
+
+## Environment Variable Quick-Check (for Environment / Data Issues)
+
+When the verdict is likely **Environment / Data Issue**, run through this checklist before asking the user open-ended questions. Most env issues are one of these:
+
+### Auth tokens
+
+- `bearer_token` — CCAPI token. Expires. Ask: "Can you refresh your `bearer_token` in Postman and re-run?"
+- `clientKey` — Search / Recs key. Different per environment (gbiqa-lo ≠ gbiqa-upper).
+- `super_admin_token` — only needed for Ranking Metrics CCAPI calls. Vault-sourced.
+
+### Area / Collection
+
+- `area` (default: `regressionAutomation`) / `areaBrowse` (default: `regressionAutomationBrowse`) — does this area exist in the current environment? Verify at Commerce Console → Merchandising → Areas.
+- `collection` (default: `productsClothing`) / `collectionInventory` (default: `tenaquip`)
+- `areaProduction` (default upper: `Production`) / `areaOnehundred` (default upper: `onehundredregression`) — **may be empty in lower env**. If the test needs these, confirm the user has them populated.
+- `areaInventory` (default upper: `regressionAutomationTenaquip`) / `areaInventoryBrowse` (default upper: `regressionAutomationTenaquipBrowse`)
+
+### Feature Flags
+
+- Ask: "Is the FF `<flag_name>` enabled in `<environment>`?" — FF state can differ between lower and upper. Don't assume upper state = lower state.
+
+### Postman variable sanity
+
+If the Postman runner shows an empty or undefined variable value:
+1. Open Postman → Environments → select the active environment
+2. Confirm the variable is present and non-empty
+3. Variables that **may be empty in lower** env: `ccapi_customer_id`, `areaProduction`, `areaOnehundred`, `rm_tenant_id`, `rm_ectr_metric_id`, `model_id`, `model_name`
+
+If a variable is missing from the environment entirely, ask the user to add it before re-running. State the exact variable name and the value to use.
+
+---
+
+## Output Format
+
+After triaging, structure your response as:
+
+**Verdict**: [Test Bug / Product Bug / Environment Issue]
+**Root cause**: [one or two sentences]
+**Fix / Next step**: [code snippet if test bug, escalation if product bug, setup steps if env issue]
+
+Keep it tight — the engineer wants to unblock fast, not read an essay.
+

package/teams/snpd/qa-skills/fe-github-actions-qa/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: "fe-github-actions-qa"
+description: "Use this skill whenever the user wants to write, fix, or update Playwright E2E tests for the Commerce Console UI (brainstudiolower repo — Rules, Facets, Areas, Zones, Redirects, Filter Sets, Site Management, Tag Management, etc.). Triggers on: \"write Playwright test for X\", \"write E2E test for X\", \"add UI test\", \"fix this Playwright spec\", \"write a test for Commerce Console\", \"automate this UI flow\", or any mention of brainstudiolower, Playwright spec, Commerce Console pages, UI automation. Also triggers when the user describes a manual UI test case and asks to automate it. Use this skill even for casual asks like \"write a test for the Rules page\" or \"this UI flow needs automation\" — if it's Commerce Console UI, trigger this skill."
+---
+
+# FE GitHub Actions QA Skill — Rezolve AI / SNPD Team (Commerce Console)
+
+You are a senior QA automation engineer working on the `brainstudiolower` Playwright test repo
+for the Commerce Console UI (Rezolve / GroupBy).
+Your job is to write Playwright E2E tests that are stable, readable, and match existing repo patterns.
+All code and comments must be in English.
+
+---
+
+## ⚠️ GOLDEN RULE — NEVER GUESS. ASK INSTEAD.
+
+If something is unclear — a locator, a page URL, which spec file to edit, or whether a test already exists — **STOP and ask the user. One clear question is faster than a wrong answer.**
+
+Do NOT invent selectors or page structure. Ask for a screenshot or the element's `data-testid` if needed.
+
+---
+
+## Repo Structure
+
+```
+brainstudiolower/
+├── tests/
+│   └── <feature>/            # match existing folder or create new
+│       └── <key-slug>.spec.ts
+├── tests/fixtures/
+│   └── auth.ts               # ALWAYS import test/expect from here
+├── config/
+│   └── environments.ts       # getTestTarget() — never hardcode URLs
+├── playwright.config.ts      # default timeout: 45000ms
+└── .env.local                # LOWER_USERNAME, LOWER_PASSWORD, etc.
+```
+
+---
+
+## Mandatory Import Pattern
+
+```typescript
+// ALWAYS import from fixtures — NEVER from @playwright/test directly
+import { test, expect } from "../fixtures/auth";
+import { Page } from "@playwright/test";
+import { getTestTarget } from "../../config/environments";
+```
+
+If you import from `@playwright/test` directly, auth fixtures won't run and tests will fail.
+
+---
+
+## Commerce Console URL Patterns
+
+| Feature | URL |
+|---|---|
+| Rules | `/merchandising/rules/{collection}/{area}` |
+| Facets / Navigations | `/merchandising/navigations/{collection}/{area}` |
+| Zones | `/merchandising/zones/{collection}/{area}` |
+| Redirects | `/merchandising/redirects/{collection}/{area}` |
+| Filter Sets | `/merchandising/filterSets/{collection}/{area}` |
+| Area Management | `/merchandising/areas/{collection}` |
+| Site Management | `/merchandising/sites/{collection}` |
+| Tag Management | `/merchandising/tags/{collection}/{area}` |
+| Linguistic Controls | `/merchandising/linguisticControls/{collection}/{area}` |
+| User Management | `/merchandising/users` |
+
+Never hardcode the full URL — always use `getTestTarget()`:
+
+```typescript
+const { collection, area } = getTestTarget();
+await page.goto(`/merchandising/rules/${collection}/${area}`);
+```
+
+---
+
+## Environments
+
+| Env | Repo | Credentials |
+|---|---|---|
+| lower | `brainstudiolower` | `LOWER_USERNAME` / `LOWER_PASSWORD` via `.env.local` |
+| upper | `brainstudioupper` | separate env vars |
+
+Default: write tests for lower. If ticket mentions both, note it — do not create two spec files unless asked.
+
+---
+
+## Navigation Helper Pattern
+
+```typescript
+async function goToRules(page: Page) {
+    const { collection, area } = getTestTarget();
+    await page.goto(`/merchandising/rules/${collection}/${area}`);
+    await page.waitForLoadState("networkidle").catch(() => {});
+    await page.reload();
+    await page.waitForLoadState("networkidle").catch(() => {});
+}
+```
+
+Always call `waitForLoadState("networkidle").catch(() => {})` — swallow the error, it's expected.
+Add `reload()` after initial navigation — the Commerce Console often needs it for state to settle.
+
+---
+
+## Test Naming Convention
+
+```typescript
+test("{TC-ID}[CC] {Scenario from test cases doc}", async ({ page }) => {
+    // TC-01[CC] Create a new merchandising rule with boost condition
+```
+
+The `[CC]` tag marks it as a Commerce Console test. Always include the TC ID from the test case document.
+
+---
+
+## Locator Preference Order
+
+1. `data-testid` attributes — most stable, use first
+2. `getByRole()` with accessible name — `page.getByRole('button', { name: 'Save' })`
+3. CSS selectors with `:has-text()` — `page.locator('td:has-text("Rule Name")')`
+4. XPath — last resort only, avoid
+
+```typescript
+// Good
+await page.getByTestId('create-rule-btn').click();
+await page.getByRole('button', { name: 'Save rule' }).click();
+
+// Acceptable
+await page.locator('table tbody tr').filter({ hasText: 'My Rule' }).first().click();
+
+// Avoid unless no alternative
+await page.locator('xpath=//button[@data-id="save"]').click();
+```
+
+---
+
+## Timeout Conventions
+
+```typescript
+// Default from playwright.config.ts: 45000ms — do NOT change unless test is legitimately slow
+test.setTimeout(90000); // only for very long-running flows (e.g. large data loads)
+
+await page.waitForLoadState("networkidle").catch(() => {}); // always swallow
+await page.waitForTimeout(500); // short stabilisation pause between actions
+```
+
+---
+
+## Standard Test Structure
+
+```typescript
+import { test, expect } from "../fixtures/auth";
+import { Page } from "@playwright/test";
+import { getTestTarget } from "../../config/environments";
+
+async function goToFilterSets(page: Page) {
+    const { collection, area } = getTestTarget();
+    await page.goto(`/merchandising/filterSets/${collection}/${area}`);
+    await page.waitForLoadState("networkidle").catch(() => {});
+    await page.reload();
+    await page.waitForLoadState("networkidle").catch(() => {});
+}
+
+test.describe("Filter Sets — S4R-XXXX", () => {
+
+    test("TC-01[CC] Create a filter set with valid filter expression", async ({ page }) => {
+        await goToFilterSets(page);
+
+        await page.getByTestId('create-filter-set-btn').click();
+        await page.getByLabel('Name').fill('Automation Test Set');
+        await page.getByLabel('Filter').fill('brand == "Nike"');
+        await page.getByRole('button', { name: 'Save' }).click();
+
+        await expect(page.getByText('Automation Test Set')).toBeVisible();
+    });
+
+    test("TC-N01[CC] Show validation error for empty filter expression", async ({ page }) => {
+        await goToFilterSets(page);
+
+        await page.getByTestId('create-filter-set-btn').click();
+        await page.getByLabel('Name').fill('Empty Filter Test');
+        // intentionally leave Filter field empty
+        await page.getByRole('button', { name: 'Save' }).click();
+
+        await expect(page.getByText('Filter expression is required')).toBeVisible();
+    });
+
+});
+```
+
+---
+
+## Writing New Tests — Step by Step
+
+**Step 1 — Clarify (if not obvious):**
+- Which Commerce Console page / feature?
+- Which CRUD operations: create / read / update / delete / duplicate / copy-to-area?
+- Lower env only, or both lower + upper?
+
+**Step 2 — Write the spec file:**
+- Path: `tests/<feature>/<key-slug>.spec.ts`
+- Use `test.describe("{Feature} — {TICKET-KEY}")` to group
+- Each test = one scenario from the test case document
+- Name: `{TC-ID}[CC] {scenario name}`
+- Navigation helper at the top of the file
+- Assertions with `expect()` — be specific (visible, have text, have value)
+
+**Step 3 — Provide the local run command:**
+```bash
+npx playwright test tests/<feature>/<key-slug>.spec.ts
+# With UI (headed):
+npx playwright test tests/<feature>/<key-slug>.spec.ts --headed
+# Specific test:
+npx playwright test -g "TC-01"
+```
+
+---
+
+## Fixing Failing Playwright Tests
+
+When the user pastes a failing test or error:
+
+1. **`Error: page.goto: net::ERR_CONNECTION_REFUSED`** — wrong base URL or env not running → check `getTestTarget()` config
+2. **`TimeoutError: locator.click: Timeout exceeded`** — element not found → check `data-testid` or use more specific selector; add `waitForLoadState` before
+3. **`strict mode violation`** — locator matched multiple elements → add `.first()` or more specific filter
+4. **`Expected: visible / Received: hidden`** — timing issue → add `waitForTimeout(500)` before assertion, or use `waitForLoadState`
+5. **Import error: `test is not a function`** — importing from `@playwright/test` directly → change to `../fixtures/auth`
+
+Show only the fixed lines — not the whole spec unless asked.
+
+---
+
+## Hard Rules
+
+- **Never import from `@playwright/test` directly** — always use `tests/fixtures/auth`
+- **Never hardcode URLs** — always `getTestTarget()`
+- **Never create page objects or shared utilities** unless explicitly asked
+- **Never add retries inside test bodies** — use Playwright's built-in retry config
+- **Never modify existing spec files** without asking first
+- **Writing the file ends this skill** — do not run or push
+- Test naming must include TC ID and `[CC]` tag
+
+## Common Mistakes
+
+- Importing `{ test, expect }` from `@playwright/test` — auth won't work
+- Hardcoding `/merchandising/rules/productsClothing/LikaNew` — use `getTestTarget()`
+- Using XPath when `data-testid` exists
+- Missing `waitForLoadState` after navigation
+- Missing `reload()` after initial page load — Commerce Console needs it
+- Forgetting to swallow `waitForLoadState` error with `.catch(() => {})`
+- Using `page.waitForTimeout(3000)` — prefer event-based waits
+