@keber/qa-framework 1.10.0 → 1.12.0

package/scripts/validate.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 /**
- * scripts/validate.js — Validate qa/ folder structure and conventions
+ * scripts/validate.js - Validate qa/ folder structure and conventions
  *
  * Usage:
  *   qa-framework validate
@@ -9,7 +9,7 @@
  *
  * Checks:
  *   1. Required top-level folders exist
- *   2. All submodule folders contain the 6 required spec files
+ *   2. All submodule folders under 01-specifications/ contain the 6 required spec files
  *   3. No plaintext credentials in spec files (basic scan)
  *   4. Test case naming convention (TC-NNN pattern in spec files)
  *   5. [--strict] Automation spec files exist for every submodule
@@ -47,7 +47,7 @@ const warnings = [];
 // -----------------------------------------------------------------------
 const requiredFolders = [
   '00-standards',
-  '05-test-plans',
+  '05-test-execution',
   '06-defects',
   '07-automation',
 ];
@@ -70,18 +70,18 @@ const SPEC_FILES = [
   '05-test-scenarios.md',
 ];
 
-const SKIP_DIRS = new Set([
-  '00-guides', '00-standards', '05-test-plans',
-  '06-defects', '07-automation', '08-azure-integration',
-]);
+// Specs live at qa/01-specifications/{module}/{submodule}/. Rooting the scan
+// here keeps it at the right depth and means sibling folders such as
+// 02-test-plans/ or memory/ are never mistaken for modules in the first place.
+const specsRoot = path.join(qaRoot, '01-specifications');
 
-if (fs.existsSync(qaRoot)) {
-  const topDirs = fs.readdirSync(qaRoot).filter(d => {
-    return fs.statSync(path.join(qaRoot, d)).isDirectory() && !SKIP_DIRS.has(d);
-  });
+if (fs.existsSync(specsRoot)) {
+  const moduleDirs = fs.readdirSync(specsRoot).filter(d =>
+    fs.statSync(path.join(specsRoot, d)).isDirectory()
+  );
 
-  for (const moduleDir of topDirs) {
-    const modulePath = path.join(qaRoot, moduleDir);
+  for (const moduleDir of moduleDirs) {
+    const modulePath = path.join(specsRoot, moduleDir);
     const subDirs = fs.readdirSync(modulePath).filter(d =>
       fs.statSync(path.join(modulePath, d)).isDirectory()
     );
@@ -90,15 +90,15 @@ if (fs.existsSync(qaRoot)) {
       const subPath = path.join(modulePath, subDir);
       for (const specFile of SPEC_FILES) {
         if (!fs.existsSync(path.join(subPath, specFile))) {
-          errors.push(`Missing spec file: qa/${moduleDir}/${subDir}/${specFile}`);
+          errors.push(`Missing spec file: qa/01-specifications/${moduleDir}/${subDir}/${specFile}`);
         }
       }
 
       // Strict: automation spec must exist
       if (strict) {
-        const specTs = path.join(qaRoot, '07-automation', 'e2e', moduleDir, `${subDir}.spec.ts`);
+        const specTs = path.join(qaRoot, '07-automation', 'e2e', 'tests', moduleDir, `${subDir}.spec.ts`);
         if (!fs.existsSync(specTs)) {
-          warnings.push(`[STRICT] No automation spec found: qa/07-automation/e2e/${moduleDir}/${subDir}.spec.ts`);
+          warnings.push(`[STRICT] No automation spec found: qa/07-automation/e2e/tests/${moduleDir}/${subDir}.spec.ts`);
         }
       }
     }
@@ -147,7 +147,7 @@ for (const f of specFiles) {
 // -----------------------------------------------------------------------
 console.log('');
 if (errors.length === 0 && warnings.length === 0) {
-  console.log('✅ Validation passed — no issues found.');
+  console.log('✅ Validation passed - no issues found.');
   process.exit(0);
 }
 

package/skills/qa-ado-integration/SKILL.md

@@ -12,31 +12,31 @@ description: >
 
 # QA Skill: ADO Integration (Optional Stage)
 
-**Stage**: Optional — ADO Integration (no pipeline order dependency)
+**Stage**: Optional - ADO Integration (no pipeline order dependency)
 **Prerequisite**: `Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` exists with a complete Tabla de Pruebas (steps filled in); valid `ADO_PAT` env var
 **Output**: ADO Test Plan populated with Test Suites and Test Cases (with steps) + `qa/08-azure-integration/module-registry.json` updated
-**Use any time** after Stage 3 (Plan de Pruebas) is ready — Stage 4 and 5 are not required
+**Use any time** after Stage 3 (Plan de Pruebas) is ready - Stage 4 and 5 are not required
 
 > **Credential rule**: NEVER hardcode PAT, username, or organization URL in any file. Always read from env vars or `<PLACEHOLDER>` in documentation.
-> **Steps rule**: ADO Test Cases must have steps. Do not sync TCs from a Plan de Pruebas with empty or summary-only steps — run Stage 4 first to expand them.
+> **Steps rule**: ADO Test Cases must have steps. Do not sync TCs from a Plan de Pruebas with empty or summary-only steps - run Stage 4 first to expand them.
 
 ---
 
 ## Inputs Required
 
-1. `qa/qa-framework.config.json` — ADO org URL, project name, test plan ID (or "create new")
-2. `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` — one file per module; each file's Tabla de Pruebas becomes one Test Suite in ADO
-3. `ADO_PAT` environment variable — personal access token with Test Plans read/write
+1. `qa/qa-framework.config.json` - ADO org URL, project name, test plan ID (or "create new")
+2. `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` - one file per module; each file's Tabla de Pruebas becomes one Test Suite in ADO
+3. `ADO_PAT` environment variable - personal access token with Test Plans read/write
 4. Optionally: `qa/08-azure-integration/module-registry.json` for existing ID mapping
 
 > **Note**: The consolidated `Plan-de-Pruebas-{proyecto}-Sprint-{N}.md` (without module suffix)
-> is for human reference only — do not use it as input for ADO scripts.
+> is for human reference only - do not use it as input for ADO scripts.
 
 ---
 
 ## Process
 
-### Step 1 — Verify ADO config
+### Step 1 - Verify ADO config
 
 Check `qa/qa-framework.config.json` for:
 ```json
@@ -48,25 +48,25 @@ Check `qa/qa-framework.config.json` for:
 ```
 If `planId` is null, a new plan will be created in Step 2.
 
-### Step 2 — Create or verify Test Plan
+### Step 2 - Create or verify Test Plan
 
 Use the PowerShell script: `integrations/ado-powershell/scripts/create-testplan-from-mapping.ps1`
 
 See `references/scripts-and-config.md` for usage, parameters, and required env vars.
 
 Required env vars:
-- `$env:ADO_ORG` — organization URL (e.g., `https://dev.azure.com/myorg`)
-- `$env:ADO_PROJECT` — project name
-- `$env:ADO_PAT` — PAT token
+- `$env:ADO_ORG` - organization URL (e.g., `https://dev.azure.com/myorg`)
+- `$env:ADO_PROJECT` - project name
+- `$env:ADO_PAT` - PAT token
 
-### Step 3 — Sync test cases from Plan de Pruebas
+### Step 3 - Sync test cases from Plan de Pruebas
 
 For each `Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` file:
 1. Read the Tabla de Pruebas
 2. Create one **Test Suite** in ADO named after the module (or use the suite groupings from section 5 of the plan)
 3. For each row in the table, create one **Test Case** with:
    - Title: the Título column value
-   - Steps: the Steps column value (numbered steps, `<br>`-separated → each becomes one ADO step)
+   - Steps: the Steps column value (numbered steps, `<br>`-separated -> each becomes one ADO step)
    - Expected result: the Resultado Esperado column value
    - Tags: Tipo + Prioridad values
 4. Write the returned ADO Test Case IDs back into the table (column "ADO WI") and into `module-registry.json`
@@ -75,19 +75,19 @@ Use `inject-ado-ids.ps1` to automate the create + inject cycle.
 
 After sync, each row in the Plan de Pruebas table must have an ADO WI ID.
 
-### Step 4 — Configure Playwright ADO reporter
+### Step 4 - Configure Playwright ADO reporter
 
 See `references/scripts-and-config.md` for the reporter config block to add to `qa/07-automation/e2e/playwright.config.ts`.
 
 Required fields:
 - `orgUrl`, `projectName`, `planId`, `runName`
-- All values must come from environment variables — no hardcoded IDs
+- All values must come from environment variables - no hardcoded IDs
 
-### Step 5 — Run sync and validate
+### Step 5 - Run sync and validate
 
 Run `sync-ado-titles.ps1` after automation runs to update ADO test outcomes from Playwright report JSON.
 
-### Step 6 — Update registry
+### Step 6 - Update registry
 
 Update `qa/08-azure-integration/module-registry.json` with:
 - Module name
@@ -112,6 +112,6 @@ Update `qa/08-azure-integration/module-registry.json` with:
 ## Outputs
 
 - ADO Test Plan populated with test cases
-- `qa/03-test-cases/automated/TC-*.md` — ADO IDs injected
+- `qa/03-test-cases/automated/TC-*.md` - ADO IDs injected
 - `qa/08-azure-integration/module-registry.json` updated
 - `qa/07-automation/e2e/playwright.config.ts` updated with reporter config

package/skills/qa-ado-integration/references/scripts-and-config.md

@@ -18,7 +18,7 @@ Creates a new ADO Test Plan with suites and test cases from the mapping JSON fil
   -MappingFile .\qa\08-azure-integration\ado-ids-mapping-{project}.json
 ```
 
-Output: `TestPlanId` and `SuiteIds` — record in `module-registry.json`.
+Output: `TestPlanId` and `SuiteIds` - record in `module-registry.json`.
 
 ---
 
@@ -104,7 +104,7 @@ Apply with `-DryRun:$false`.
       "specsPath": "qa/07-automation/e2e/tests/{module-kebab}",
       "planId": 0,
       "suiteId": 0,
-      "description": "{Module display name} — {N} submodules"
+      "description": "{Module display name} - {N} submodules"
     }
   ]
 }
@@ -130,7 +130,7 @@ Add to `qa/07-automation/playwright.config.ts` reporter array:
 }]
 ```
 
-**`isDisabled: !process.env.CI`** — prevents publishing from local developer runs.
+**`isDisabled: !process.env.CI`** - prevents publishing from local developer runs.
 
 ---
 
@@ -194,8 +194,8 @@ steps:
 
 ## Credential Security Rules
 
-1. `ADO_PAT` is **never** committed to any file — always from env var or CI variable group
+1. `ADO_PAT` is **never** committed to any file - always from env var or CI variable group
 2. `ADO_PAT` is **never** logged, printed, or written to any markdown file
 3. If a PAT appears in any log or output: revoke it immediately in ADO Portal, generate new one
-4. Variable group `qa-secrets` must be scoped to the pipeline only — no project-wide access
-5. PAT minimum scopes: `Work Items (Read, Write)`, `Test Management (Read, Write)` — never use full-access PATs
+4. Variable group `qa-secrets` must be scoped to the pipeline only - no project-wide access
+5. PAT minimum scopes: `Work Items (Read, Write)`, `Test Management (Read, Write)` - never use full-access PATs

package/skills/qa-automation/SKILL.md

@@ -12,10 +12,10 @@ description: >
 
 # QA Skill: Automation Generation (Stage 5 of 6)
 
-**Stage**: 5 — Automation  
+**Stage**: 5 - Automation  
 **Prerequisite**: All specs for the target submodule are complete and contain no `PENDING-CODE` sections  
 **Output**: `qa/07-automation/e2e/tests/{module}/{submodule}.spec.ts` + supporting files  
-**Next stage**: Stage 6 — Maintenance (`qa-maintenance`) or Stage 5b — Stabilization (`qa-test-stabilization`) if tests fail
+**Next stage**: Stage 6 - Maintenance (`qa-maintenance`) or Stage 5b - Stabilization (`qa-test-stabilization`) if tests fail
 
 > **Pipeline rule**: Never automate a TC whose spec contains `PENDING-CODE`. Resolve spec gaps first.
 
@@ -23,27 +23,27 @@ description: >
 
 ## Inputs Required
 
-1. `qa/01-specifications/{module}/` — full spec set for target submodule
-2. `qa/07-automation/e2e/playwright.config.ts` — confirm project name maps to submodule tag
-3. `qa/07-automation/e2e/fixtures/auth.ts` — identify available auth fixtures
-4. TC list (from test plan or Stage 4) — defines which TCs to automate in this session
-5. `qa/qa-framework.config.json` → screenshotPath, automationRoot
+1. `qa/01-specifications/{module}/` - full spec set for target submodule
+2. `qa/07-automation/e2e/playwright.config.ts` - confirm project name maps to submodule tag
+3. `qa/07-automation/e2e/fixtures/auth.ts` - identify available auth fixtures
+4. TC list (from test plan or Stage 4) - defines which TCs to automate in this session
+5. `qa/qa-framework.config.json` -> screenshotPath, automationRoot
 
 ---
 
 ## Process
 
-### Step 0 — Pre-inspection (MANDATORY before writing any test code)
+### Step 0 - Pre-inspection (MANDATORY before writing any test code)
 
 For every new submodule, run a dedicated inspection script before writing tests.
-**Template**: `references/dom-inspection-template.js` — copy, set the 4 constants at the top, run.
+**Template**: `references/dom-inspection-template.js` - copy, set the 4 constants at the top, run.
 
-1. Copy `references/dom-inspection-template.js` → `qa/07-automation/e2e/_inspect-{submodule}.js`
+1. Copy `references/dom-inspection-template.js` -> `qa/07-automation/e2e/_inspect-{submodule}.js`
 2. Set the 4 constants at the top of the script:
-   - `MODULE_ROUTE` — the submodule's URL path (e.g. `'/Users'`, `'/Products/list'`)
-   - `APP_SHELL_SEL` — a selector that confirms the SPA has loaded (nav, sidebar, app shell)
-   - `CREATE_BTN` — regex matching the create/new button label in this app
-   - `BASE_URL` — already read from `process.env.QA_BASE_URL`
+   - `MODULE_ROUTE` - the submodule's URL path (e.g. `'/Users'`, `'/Products/list'`)
+   - `APP_SHELL_SEL` - a selector that confirms the SPA has loaded (nav, sidebar, app shell)
+   - `CREATE_BTN` - regex matching the create/new button label in this app
+   - `BASE_URL` - already read from `process.env.QA_BASE_URL`
 3. Run: `QA_BASE_URL=<env> node _inspect-{submodule}.js`
 4. Paste key findings as a comment block at the **top of the `.spec.ts` file** before writing any test:
    ```
@@ -59,14 +59,14 @@ The template covers 5 inspection areas automatically: SPA warmup, list view (gri
 **Never skip this step for submodules inside complex forms (tabs, dialogs, nested entities).
 The cost of one inspection run is far lower than 10+ debugging iterations.**
 
-### Step 1 — Scan for blockers
+### Step 1 - Scan for blockers
 
 Before writing a line of code:
-- Search all spec files for `PENDING-CODE` — stop and flag if found
+- Search all spec files for `PENDING-CODE` - stop and flag if found
 - Confirm `playwright.config.ts` exists; scaffold it if missing using `references/config-checklist.md`
 - Verify `fixtures/auth.ts` has the roles required by this submodule
 
-### Step 1b — Decide POM vs inline locators
+### Step 1b - Decide POM vs inline locators
 
 Create a Page Object in `qa/07-automation/e2e/page-objects/{SubmoduleName}Page.ts` when ANY of these is true:
 - The submodule has a form with 5+ fields (locators will be reused across P0 + P1 suites)
@@ -77,7 +77,7 @@ Otherwise, inline locators are acceptable for simple catalog submodules (single
 
 POM template: `references/pom-template.md`
 
-### Step 2 — Scaffold spec file
+### Step 2 - Scaffold spec file
 
 Full spec file template and 7 implementation patterns: `references/patterns.md`
 
@@ -87,30 +87,30 @@ Required scaffold elements:
 - `test.describe('{Submodule Name}', () => { ... })`
 - Use fixture-based auth (never hardcode credentials)
 
-### Step 3 — Implement tests in priority order
+### Step 3 - Implement tests in priority order
 
 Implement P0 TCs first, then P1. Within each priority, follow scenario order from `05-test-scenarios.md`.
 
 For each TC:
 1. Map TC preconditions to `beforeAll`/`beforeEach` setup
 2. Write navigation to the starting URL (use relative paths, not hardcoded base URL)
-3. Use `test.step()` to group logical sub-actions — improves traceability
-4. Assert observable outcomes — avoid asserting internal implementation details
+3. Use `test.step()` to group logical sub-actions - improves traceability
+4. Assert observable outcomes - avoid asserting internal implementation details
 
-### Step 4 — Apply stability rules
+### Step 4 - Apply stability rules
 
-- Never use `waitForTimeout` — use `waitForSelector`, `waitForResponse`, or role-based locators
+- Never use `waitForTimeout` - use `waitForSelector`, `waitForResponse`, or role-based locators
 - Prefer `getByRole`, `getByLabel`, `getByTestId` over CSS selectors
 - Locators attached to dynamic data must use `EXEC_IDX` suffix
-- All test data cleared in `afterAll` — never leave residue
+- All test data cleared in `afterAll` - never leave residue
 
-### Step 4b — Assertion polarity check (MANDATORY before committing any test)
+### Step 4b - Assertion polarity check (MANDATORY before committing any test)
 
 Every assertion must be verified against the spec, not against the app's 
 observed output.
 
 **Rule**: if the app does X but the spec requires NOT X, use `test.fail()` 
-with the correct assertion — do not adapt the assertion to match the app.
+with the correct assertion - do not adapt the assertion to match the app.
 
 Red flags that require review before proceeding:
 - `expect(X).toBe(false)` where the spec describes a positive condition
@@ -118,7 +118,27 @@ Red flags that require review before proceeding:
 - Assertions inside an `if (condition)` that only execute on the happy path
 - A test that starts passing after a refactor without a clear spec justification
 
-### Step 5 — Module Completion Checklist
+### Step 5 - Static Check, Smoke Run & Completion Checklist
+
+Two gates run **before** the checklist below. Both must come back clean.
+
+**Gate 1 - static check.** From the automation root (`qa/07-automation/e2e`):
+
+```
+npx tsc --noEmit
+```
+
+Must exit 0. Do not proceed with pending TypeScript errors.
+
+**Gate 2 - smoke run.** Run every new or modified spec at least once against the official runner:
+
+```
+npx playwright test {spec} --project={module} --reporter=list
+```
+
+The goal is to surface reference, import and syntax errors that only appear at execution time - a variable used but never declared passes every review and fails only when the line runs. A full green suite is Stage 5b's job, not this gate's: a test that fails on a real assertion has still cleared Gate 2.
+
+Only when both gates are clean, continue:
 
 Before marking the submodule as ✅ Automation Complete:
 - [ ] All P0 TCs passing in CI
@@ -127,6 +147,8 @@ Before marking the submodule as ✅ Automation Complete:
 - [ ] `playwright.config.ts` project includes submodule tag
 - [ ] `qa/README.md` automation status updated
 - [ ] AGENT-NEXT-STEPS.md active sprint updated (remove completed items)
+- [ ] `npx tsc --noEmit` run, exit 0
+- [ ] New/modified specs run at least once via `npx playwright test` (smoke)
 
 ---
 

package/skills/qa-automation/references/config-checklist.md

@@ -12,7 +12,7 @@ import { defineConfig, devices } from '@playwright/test';
 export default defineConfig({
   testDir: './tests',
   timeout: 30_000,            // Per-test timeout
-  actionTimeout: 10_000,      // Per-action timeout — REQUIRED, prevents silent hangs
+  actionTimeout: 10_000,      // Per-action timeout - REQUIRED, prevents silent hangs
   navigationTimeout: 60_000,  // Per-navigation timeout (SPAs may need longer)
   retries: process.env.CI ? 2 : 0,
   workers: process.env.CI ? 1 : 2,
@@ -31,7 +31,7 @@ export default defineConfig({
 
   reporter: [
     ['html', { outputFolder: 'playwright-report' }],
-    // ADO reporter — add only when integration is enabled:
+    // ADO reporter - add only when integration is enabled:
     // ['@alex_neo/playwright-azure-reporter', {
     //   orgUrl: process.env.ADO_ORG,
     //   projectName: process.env.ADO_PROJECT,
@@ -59,7 +59,7 @@ export default defineConfig({
 
 Before marking automation as complete, confirm:
 
-- [ ] `actionTimeout` is set — **not optional**; without it, `textContent()` and similar calls silently hang
+- [ ] `actionTimeout` is set - **not optional**; without it, `textContent()` and similar calls silently hang
 - [ ] `testIgnore` excludes seed scripts and debug files
 - [ ] `baseURL` reads from `process.env.QA_BASE_URL` (never hardcoded)
 - [ ] `storageState` path exists (created by `globalSetup`)
@@ -72,7 +72,7 @@ Before marking automation as complete, confirm:
 
 ## global-setup.ts Checklist
 
-- [ ] Reads every credential from `process.env` — no hardcoded values
+- [ ] Reads every credential from `process.env` - no hardcoded values
 - [ ] Uses `evaluate()` for password input (trace safety)
 - [ ] Saves storageState to `.auth/session.json` (or per-role paths)
 - [ ] Handles login failure explicitly (does not silently save an unauthenticated state)

package/skills/qa-automation/references/dom-inspection-template.js

@@ -1,5 +1,5 @@
 /**
- * DOM / API Inspection Script — {SUBMODULE_DISPLAY_NAME}
+ * DOM / API Inspection Script - {SUBMODULE_DISPLAY_NAME}
  *
  * Purpose: Capture real UI structure before writing automation specs.
  *          Run ONCE per submodule. Output drives selector and fixture decisions.
@@ -32,7 +32,7 @@
 const { chromium } = require('@playwright/test');
 const path = require('path');
 
-// ── Configuration — edit these 4 constants, leave the rest ───────────────────
+// ── Configuration - edit these 4 constants, leave the rest ───────────────────
 const STATE_FILE    = path.resolve(__dirname, '.auth/user-default.json');
 const BASE_URL      = process.env.QA_BASE_URL || '';
 const MODULE_ROUTE  = '/{EntityRoute}';                          // e.g. '/Users', '/Orders/list'
@@ -54,7 +54,7 @@ async function run() {
   console.log('BASE_URL:', BASE_URL);
   console.log('MODULE_ROUTE:', MODULE_ROUTE);
 
-  // ── 0. Intercept API calls — runs passively throughout the entire session ──
+  // ── 0. Intercept API calls - runs passively throughout the entire session ──
   const apiCalls = [];
   page.on('request', req => {
     try {
@@ -148,7 +148,7 @@ async function run() {
     ).catch(() => []);
     console.log('  <select> elements:', JSON.stringify(selects, null, 2));
 
-    // Custom dropdowns — uses ARIA roles (framework-agnostic)
+    // Custom dropdowns - uses ARIA roles (framework-agnostic)
     const customDDs = await page.$$eval(
       '[role="combobox"], [role="listbox"], [aria-haspopup="listbox"]',
       dds => dds.map((dd, i) => ({
@@ -181,7 +181,7 @@ async function run() {
     ).catch(() => []);
     if (tabs.length > 0) console.log('  Tabs:', JSON.stringify(tabs));
 
-    // Validation — submit empty form to capture required-field messages
+    // Validation - submit empty form to capture required-field messages
     const saveBtn = page.getByRole('button', { name: /guardar|save|submit|crear|create/i }).first();
     if (await saveBtn.isVisible({ timeout: 3_000 }).catch(() => false)) {
       await saveBtn.click();
@@ -194,7 +194,7 @@ async function run() {
     }
 
     // ── ADD EXTRA STEPS HERE for tabbed/nested forms ──────────────────────
-    // Example — inspect a specific tab:
+    // Example - inspect a specific tab:
     //   await page.getByRole('tab', { name: /identif/i }).click();
     //   await page.waitForTimeout(1_000);
     //   const tabDDs = await page.locator('[role="tab"][aria-selected="true"] + ... .rz-dropdown')...
@@ -227,7 +227,7 @@ async function run() {
   console.log('\n[STEP 5] API calls captured during session:');
   const unique = [...new Map(apiCalls.map(c => [`${c.method} ${c.url}`, c])).values()];
   if (unique.length === 0) {
-    console.log('  (none captured — app may use WASM-level data, not REST calls)');
+    console.log('  (none captured - app may use WASM-level data, not REST calls)');
   } else {
     unique.forEach(c => {
       console.log(`  ${c.method} ${c.url}`);

package/skills/qa-automation/references/patterns.md

@@ -30,9 +30,9 @@ test.describe('{Feature Suite Name}', () => {
   });
 
   test.skip(
-    '[TC-{MODULE}-{SUB}-003] {TC title} @P1 — DEF-{NNN}: {description}. Reactivate when {ADO WI or DEF ID} is resolved.',
+    '[TC-{MODULE}-{SUB}-003] {TC title} @P1 - DEF-{NNN}: {description}. Reactivate when {ADO WI or DEF ID} is resolved.',
     async ({ page }) => {
-      // Write test as if bug is fixed — documents expected behavior
+      // Write test as if bug is fixed - documents expected behavior
     }
   );
 
@@ -41,7 +41,7 @@ test.describe('{Feature Suite Name}', () => {
 
 ---
 
-## Pattern 1: EXEC_IDX — Unique Test Data
+## Pattern 1: EXEC_IDX - Unique Test Data
 
 ```typescript
 const EXEC_IDX = Math.floor(Date.now() / 60_000) % 100_000;
@@ -70,7 +70,7 @@ export default async function globalSetup() {
 
   await page.goto(process.env.QA_BASE_URL + process.env.QA_LOGIN_PATH);
   await page.fill(process.env.QA_LOGIN_EMAIL_SELECTOR, process.env.QA_USER_EMAIL);
-  // Use evaluate() for password — excluded from traces
+  // Use evaluate() for password - excluded from traces
   await page.evaluate(
     ([sel, pwd]) => { (document.querySelector(sel) as HTMLInputElement).value = pwd; },
     [process.env.QA_LOGIN_PASSWORD_SELECTOR, process.env.QA_USER_PASSWORD]
@@ -83,23 +83,23 @@ export default async function globalSetup() {
 }
 ```
 
-For multiple roles: run login sequence **sequentially** (not in parallel — apps often reject concurrent sessions).
+For multiple roles: run login sequence **sequentially** (not in parallel - apps often reject concurrent sessions).
 
 ---
 
 ## Pattern 3: Fast-Fail for Status Checks
 
 ```typescript
-// BAD — hangs silently for full test timeout
+// BAD - hangs silently for full test timeout
 const status = await page.locator('.status-badge').textContent();
 
-// GOOD — fails fast if element not available
+// GOOD - fails fast if element not available
 const status = await page.locator('.status-badge').textContent({ timeout: 3_000 });
 ```
 
 ---
 
-## Pattern 4: Email Validation — 3-Layer Strategy
+## Pattern 4: Email Validation - 3-Layer Strategy
 
 ```typescript
 // Layer 1: HTTP route interception
@@ -168,7 +168,7 @@ await page.evaluate(
 ## Pattern 8: afterAll Cleanup for Data-Mutating Tests
 
 When a test assigns, creates, or modifies persistent data (e.g., assigning a role, linking a record),
-always implement `afterAll` cleanup — otherwise the second run finds a different state and fails.
+always implement `afterAll` cleanup - otherwise the second run finds a different state and fails.
 
 ```typescript
 afterAll(async () => {
@@ -184,11 +184,11 @@ afterAll(async () => {
 ```
 
 Rule: if beforeAll sets up a fixture by reading state from the API, afterAll must restore that same state.
-Design cleanup from the start — retrofitting it costs as many runs as the test itself.
+Design cleanup from the start - retrofitting it costs as many runs as the test itself.
 
 ---
 
-### Pattern 9: Debug Screenshots — Path-bound Artifacts
+### Pattern 9: Debug Screenshots - Path-bound Artifacts
 
 Screenshots MUST always be saved to `agentSettings.screenshotPath` defined in `qa/qa-framework.config.json`. Never save to the workspace root or any ad-hoc path.
 
@@ -196,23 +196,23 @@ Screenshots MUST always be saved to `agentSettings.screenshotPath` defined in `q
 // Read screenshotPath from config or use default
 const DIAG_DIR = 'qa/07-automation/e2e/diagnosis';
 
-// On test failure — capture state for diagnosis:
+// On test failure - capture state for diagnosis:
 await page.screenshot({ path: `${DIAG_DIR}/${SUBMODULE}-${tcId}-fail-${Date.now()}.png` });
 
 // In beforeAll for warm-up verification:
 await page.screenshot({ path: `${DIAG_DIR}/{submodule}-warmup.png` });
 
-// In inspection scripts (_inspect-*.js) — always use the same dir:
+// In inspection scripts (_inspect-*.js) - always use the same dir:
 await page.screenshot({ path: `${DIAG_DIR}/_inspect-${SUBMODULE}.png`, fullPage: true });
 ```
 
 Naming convention: {submodule}-{context}-{optional-timestamp}.png
 When to capture:
 
-* End of beforeAll warmup — confirms the app state before tests run
-* Inside catch blocks in beforeAll/beforeEach — documents the failure condition
-* Inside inspection scripts — captures the rendered UI state at each navigation step
-* Never inside individual test() bodies — Playwright's built-in trace (--trace on) already captures this
+* End of beforeAll warmup - confirms the app state before tests run
+* Inside catch blocks in beforeAll/beforeEach - documents the failure condition
+* Inside inspection scripts - captures the rendered UI state at each navigation step
+* Never inside individual test() bodies - Playwright's built-in trace (--trace on) already captures this
 * Enforcement: The diagnosis/ folder is gitignored. Screenshots are local-only artifacts, never committed to the repo.
 
 ---
@@ -222,11 +222,11 @@ When to capture:
 Create `COVERAGE-MAPPING.md` in the test directory after automation is complete:
 
 ```markdown
-# Coverage Mapping — {Module}
+# Coverage Mapping - {Module}
 
 | TC ID | Title | Spec file | Playwright spec | Status |
 |-------|-------|-----------|----------------|--------|
 | TC-MOD-SUB-001 | {title} | 05-test-scenarios.md | tests/{module}/{file}.spec.ts | ✅ Automated |
-| TC-MOD-SUB-002 | {title} | 05-test-scenarios.md | — | ⛔ BLOCKED-PERMISSIONS |
-| TC-MOD-SUB-003 | {title} | 05-test-scenarios.md | — | 🔲 PENDING-CODE |
+| TC-MOD-SUB-002 | {title} | 05-test-scenarios.md | - | ⛔ BLOCKED-PERMISSIONS |
+| TC-MOD-SUB-003 | {title} | 05-test-scenarios.md | - | 🔲 PENDING-CODE |
 ```