@keber/qa-framework 1.11.3 → 1.12.0

package/templates/integration-scaffold/global-setup.ts

@@ -87,7 +87,27 @@ async function setupWithBrowserLogin(): Promise<void> {
 
     await page.locator(emailSelector).waitFor({ state: 'visible', timeout: 30_000 });
     await page.locator(emailSelector).fill(email);
-    await page.locator(passwordSelector).fill(password);
+    // Trace safety: Playwright records fill() argument values in traces, so a project
+    // that enables trace/video capture would persist the plaintext password in its
+    // artifacts. Setting the value through evaluate() keeps it out of the trace.
+    // Do not "simplify" this back to fill().
+    // The input/change events are required because assigning .value directly does
+    // not notify SPA frameworks (Blazor/Radzen bind on those events).
+    // evaluate() has no auto-wait, so the explicit waitFor replaces the one that
+    // locator().fill() performed implicitly.
+    await page.locator(passwordSelector).waitFor({ state: 'visible', timeout: 30_000 });
+    await page.evaluate(
+      ([selector, pwd]) => {
+        const input = document.querySelector(selector) as HTMLInputElement | null;
+        if (!input) {
+          throw new Error(`[qa-framework] Password input not found for selector: ${selector}`);
+        }
+        input.value = pwd;
+        input.dispatchEvent(new Event('input', { bubbles: true }));
+        input.dispatchEvent(new Event('change', { bubbles: true }));
+      },
+      [passwordSelector, password] as const
+    );
     await page.locator(submitSelector).click();
     await page.waitForSelector(successSelector, { timeout: 60_000 });
 

package/templates/integration-scaffold/playwright.config.ts

@@ -14,8 +14,22 @@
 
 import { defineConfig } from '@playwright/test';
 import * as dotenv from 'dotenv';
+import * as fs from 'fs';
 
-dotenv.config();
+// Least privilege: read only the keys this config actually uses. dotenv.parse() returns
+// a plain object without touching process.env, so the other secrets in .env - the other
+// QA accounts, ADO tokens - are never loaded into a process that has no use for them.
+// QA_USER_PASSWORD is included because the credentials check below reads it; its value
+// is only tested for presence, never logged. Do not "simplify" this back to config().
+const ENV_KEYS = ['QA_BASE_URL', 'QA_API_TOKEN', 'QA_USER_EMAIL', 'QA_USER_PASSWORD'] as const;
+if (fs.existsSync('.env')) {
+  const parsed = dotenv.parse(fs.readFileSync('.env'));
+  for (const key of ENV_KEYS) {
+    if (process.env[key] === undefined && parsed[key] !== undefined) {
+      process.env[key] = parsed[key];
+    }
+  }
+}
 
 const required = ['QA_BASE_URL'];
 for (const key of required) {

package/templates/qa-framework.instructions.md

@@ -8,7 +8,7 @@ This project uses `@keber/qa-framework` v{{VERSION}} for spec-driven automated t
 ## Agent behavior rules
 
 0. **On every conversation start:** check if `qa/AGENT-NEXT-STEPS.md` exists. If it does, read it and complete its steps before anything else.
-1. Before performing any QA task, load the relevant skill from `.github/skills/`. For project context, read `qa/memory/INDEX.md` if it exists, then load only the memory files relevant to the current task — do not load all memory files unconditionally. Never execute a pipeline stage unless its prerequisite is satisfied.
+1. Before performing any QA task, load the relevant skill from `.github/skills/`. For project context, read `qa/memory/INDEX.md` if it exists, then load only the memory files relevant to the current task - do not load all memory files unconditionally. Never execute a pipeline stage unless its prerequisite is satisfied.
 2. Always save artifacts in the correct `qa/` subfolder - refer to `qa/QA-STRUCTURE-GUIDE.md`
 3. Never hardcode credentials - always use env vars and `<PLACEHOLDER>` in documentation
 4. Follow the naming conventions in `qa/00-standards/naming-conventions.md`
@@ -16,9 +16,10 @@ This project uses `@keber/qa-framework` v{{VERSION}} for spec-driven automated t
 6. Project QA config is at `qa/qa-framework.config.json`
 7. Save learnings in `qa/memory/` with proper naming and metadata. Always update `qa/memory/INDEX.md` after adding or updating any memory file.
 8. **Sprint/module completion criteria:** A sprint or module is complete when every TC in scope has one of these three valid states - and no other: (a) `test()` passing: the app meets the spec; (b) `test.fail()`: the app violates the spec **and** a file `qa/06-defects/open/DEF-SIS-NNN_*.md` exists documenting which business rule is violated and what the app actually does; (c) `test.skip()`: the TC is not yet executable, annotated with `PENDING-CODE` and a linked issue. A sprint is **not** complete if any TC is failing without `test.fail()`, or has `test.fail()` without a defect file, or has `test.skip()` without a `PENDING-CODE` reason.
-9. **On sprint/module completion:** (1) update the module status row in `qa/README.md`; (2) move the completed sprint checklist from `AGENT-NEXT-STEPS.md` to the `## Sprint History` section of `qa/README.md`; (3) trim `AGENT-NEXT-STEPS.md` so it contains only the next sprint — never let it accumulate more than one active sprint.
-10. **Assertion polarity rule (BLOCKING):** A test must assert what the **spec** requires, not what the app currently does. If the app fails to meet the spec, use `test.fail()` + correct assertion to document the defect — **never invert or weaken an assertion to make a test go green.** A failing test that exposes a real defect is always more valuable than a passing test that hides one.
+9. **On sprint/module completion:** (1) update the module status row in `qa/README.md`; (2) move the completed sprint checklist from `AGENT-NEXT-STEPS.md` to the `## Sprint History` section of `qa/README.md`; (3) trim `AGENT-NEXT-STEPS.md` so it contains only the next sprint - never let it accumulate more than one active sprint.
+10. **Assertion polarity rule (BLOCKING):** A test must assert what the **spec** requires, not what the app currently does. If the app fails to meet the spec, use `test.fail()` + correct assertion to document the defect - **never invert or weaken an assertion to make a test go green.** A failing test that exposes a real defect is always more valuable than a passing test that hides one.
 11. **Character encoding safety (BLOCKING):** In ALL generated content (markdown, scripts, test titles, ADO fields, config files), never use characters at these Unicode code points: em-dash (U+2014), en-dash (U+2013), horizontal ellipsis (U+2026), smart/curly quotes (U+201C, U+201D, U+2018, U+2019), or directional arrows (U+2190-U+21FF). Use ASCII equivalents instead: ` - ` (hyphen with surrounding spaces) for dashes, `...` for ellipsis, `"` and `'` for quotes, `->` and `<-` for arrows. Exception: Latin Extended characters (U+00C0-U+024F) are always permitted - this covers Spanish vowels with accents (U+00E0-U+00FA), n with tilde (U+00F1/U+00D1), and u/o with umlaut (U+00FC/U+00DC, U+00F6/U+00D6).
+12. **Lane lock for parallel QA execution (BLOCKING):** Parallel QA lanes exist because the applications under test invalidate a session when the same account logs in again - two concurrent workers on one account silently destroy each other's session, and the damage surfaces later as an unexplained logout or as evidence recorded under the wrong account. Before dispatching any worker (sub-agent, test runner project, or CI job) against one of the lanes configured in `parallelLanes.lanes` in `qa/qa-framework.config.json`, **acquire a lane through the project's lane-lock script and release it when the work is done.** Never assign a lane by prompt or config alone without going through the lock. Use `acquire` when the worker does not care which lane it gets, and `reserve <laneId>` when it needs a specific predictable lane (a CI job or a local CLI run) - these are two verbs because there are two use cases, and collapsing them is how a CI job lands on a random lane. If no lane is free, queue (capped at the configured lane count) or reject - **never force a lane assignment past that cap.** Check that a lane actually has the capability a worker needs before handing it over: capabilities are per-lane, so a lane that lacks (for example) an MCP server must not be given to a worker that needs one. A held lane is swept as stale only after the configured threshold and only when no recent heartbeat proves the holder alive, so **the dispatcher must keep the lane alive with `heartbeat` while the work is in flight** - do not rely on the dispatched worker to do it, since a worker that was never told the mechanism exists cannot be expected to use it. A lock held far longer than the app's session TTL is a signal to verify, not a defect to ignore; each project's agent-specific instructions define how it verifies a lock is still legitimately held and how it clears a stale one.
 
 ## Formatting rules for generated content
 1. Generate the output in `UTF-8` encoding without BOM (`UTF-8`, no signature).
@@ -27,7 +28,7 @@ This project uses `@keber/qa-framework` v{{VERSION}} for spec-driven automated t
 ## Azure DevOps integration
 
 Before any ADO operation, check if `.github/skills/ado-qa/` exists or if
-`integrations.ado.enabled` is `true` in `qa/qa-framework.config.json`. If either
+`integrations.azureDevOps.enabled` is `true` in `qa/qa-framework.config.json`. If either
 condition is met, load `.github/skills/qa-ado-integration/SKILL.md` and use it for
 all ADO interactions (work items, test plans, test cases, bugs, etc.).
 
@@ -46,8 +47,8 @@ Stages must run in order. Never start a stage unless its prerequisite is met.
 | 5 | Generate automation | `.github/skills/qa-automation/SKILL.md` | Specs approved, no PENDING-CODE |
 | 5b | Stabilize failing tests | `.github/skills/qa-test-stabilization/SKILL.md` | Failing tests exist |
 | 6 | Maintenance | `.github/skills/qa-maintenance/SKILL.md` | Application change delivered |
-| — | ADO integration | `.github/skills/qa-ado-integration/SKILL.md` | ADO enabled in config |
+| - | ADO integration | `.github/skills/qa-ado-integration/SKILL.md` | ADO enabled in config |
 
 ## Project KB
-1. `qa/README.md`          — The Living Index: module status, sprint history, blockers, quick-start commands.
-2. `qa/memory/INDEX.md`    — Index of all memory files; load this before selecting which files to read.
+1. `qa/README.md`          - The Living Index: module status, sprint history, blockers, quick-start commands.
+2. `qa/memory/INDEX.md`    - Index of all memory files; load this before selecting which files to read.

package/templates/qa-framework.rules.md

@@ -0,0 +1,53 @@
+# QA Framework Instructions
+
+This project uses `@keber/qa-framework` v{{VERSION}} for spec-driven automated testing.
+
+## Agent behavior rules
+
+0. **On every conversation start:** check if `qa/AGENT-NEXT-STEPS.md` exists. If it does, read it and complete its steps before anything else.
+1. Before performing any QA task, run the corresponding `/qa-{name}` command (see `.claude/commands/`), which loads the relevant skill via `.github/skills/qa-{name}/SKILL.md`. For project context, read `qa/memory/INDEX.md` if it exists, then load only the memory files relevant to the current task - do not load all memory files unconditionally. Never execute a pipeline stage unless its prerequisite is satisfied.
+2. Always save artifacts in the correct `qa/` subfolder - refer to `qa/QA-STRUCTURE-GUIDE.md`
+3. Never hardcode credentials - always use env vars and `<PLACEHOLDER>` in documentation
+4. Follow the naming conventions in `qa/00-standards/naming-conventions.md`
+5. Read previous test suites code in `qa/07-automation/e2e/tests/` if available before writing new automation to maintain consistency in style and approach
+6. Project QA config is at `qa/qa-framework.config.json`
+7. Save learnings in `qa/memory/` with proper naming and metadata. Always update `qa/memory/INDEX.md` after adding or updating any memory file.
+8. **Sprint/module completion criteria:** A sprint or module is complete when every TC in scope has one of these three valid states - and no other: (a) `test()` passing: the app meets the spec; (b) `test.fail()`: the app violates the spec **and** a file `qa/06-defects/open/DEF-SIS-NNN_*.md` exists documenting which business rule is violated and what the app actually does; (c) `test.skip()`: the TC is not yet executable, annotated with `PENDING-CODE` and a linked issue. A sprint is **not** complete if any TC is failing without `test.fail()`, or has `test.fail()` without a defect file, or has `test.skip()` without a `PENDING-CODE` reason.
+9. **On sprint/module completion:** (1) update the module status row in `qa/README.md`; (2) move the completed sprint checklist from `AGENT-NEXT-STEPS.md` to the `## Sprint History` section of `qa/README.md`; (3) trim `AGENT-NEXT-STEPS.md` so it contains only the next sprint - never let it accumulate more than one active sprint.
+10. **Assertion polarity rule (BLOCKING):** A test must assert what the **spec** requires, not what the app currently does. If the app fails to meet the spec, use `test.fail()` + correct assertion to document the defect - **never invert or weaken an assertion to make a test go green.** A failing test that exposes a real defect is always more valuable than a passing test that hides one.
+11. **Character encoding safety (BLOCKING):** In ALL generated content (markdown, scripts, test titles, ADO fields, config files), never use characters at these Unicode code points: em-dash (U+2014), en-dash (U+2013), horizontal ellipsis (U+2026), smart/curly quotes (U+201C, U+201D, U+2018, U+2019), or directional arrows (U+2190-U+21FF). Use ASCII equivalents instead: ` - ` (hyphen with surrounding spaces) for dashes, `...` for ellipsis, `"` and `'` for quotes, `->` and `<-` for arrows. Exception: Latin Extended characters (U+00C0-U+024F) are always permitted - this covers Spanish vowels with accents (U+00E0-U+00FA), n with tilde (U+00F1/U+00D1), and u/o with umlaut (U+00FC/U+00DC, U+00F6/U+00D6).
+
+## Formatting rules for generated content
+1. Generate the output in `UTF-8` encoding without BOM (`UTF-8`, no signature).
+2. Ensure the raw output is `UTF-8` encoded with no `EF BB BF` bytes at the beginning.
+
+## Azure DevOps integration
+
+Before any ADO operation, check if `.github/skills/ado-qa/` exists or if
+`integrations.azureDevOps.enabled` is `true` in `qa/qa-framework.config.json`. If either
+condition is met, run `/qa-ado-integration` (see `.claude/commands/`), which loads
+`.github/skills/qa-ado-integration/SKILL.md`, and use it for all ADO interactions
+(work items, test plans, test cases, bugs, etc.).
+
+> To enable Azure DevOps integration run: `npm install github:keber/ado-qa`
+
+## QA Pipeline
+
+Stages must run in order. Never start a stage unless its prerequisite is met.
+
+| Stage | Task | Command | Prerequisite |
+|---|---|---|---|
+| 1 | Analyze module | `/qa-module-analysis` | None |
+| 2 | Generate specifications | `/qa-spec-generation` | 00-inventory.md exists |
+| 3 | Generate test plan | `/qa-test-plan` | 05-test-scenarios.md exists |
+| 4 | Generate test cases | `/qa-test-cases` | Test plan exists |
+| 5 | Generate automation | `/qa-automation` | Specs approved, no PENDING-CODE |
+| 5b | Stabilize failing tests | `/qa-test-stabilization` | Failing tests exist |
+| 6 | Maintenance | `/qa-maintenance` | Application change delivered |
+| - | ADO integration | `/qa-ado-integration` | ADO enabled in config |
+
+Each command reads its full skill from `.github/skills/qa-{name}/SKILL.md` before acting - see `.claude/commands/` for the generated wrappers.
+
+## Project KB
+1. `qa/README.md`          - The Living Index: module status, sprint history, blockers, quick-start commands.
+2. `qa/memory/INDEX.md`    - Index of all memory files; load this before selecting which files to read.

package/templates/qa-readme.md

@@ -1,8 +1,8 @@
-# QA — {PROJECT_DISPLAY_NAME}
+# QA - {PROJECT_DISPLAY_NAME}
 
 > Framework: `@keber/qa-framework` v{VERSION}
 > Language: {LANGUAGE} | Base URL: `{QA_BASE_URL}`
-> ADO Project: `{ADO_ORG} / {ADO_PROJECT}` _(optional — remove line if not using Azure DevOps)_
+> ADO Project: `{ADO_ORG} / {ADO_PROJECT}` _(optional - remove line if not using Azure DevOps)_
 
 ---
 
@@ -10,7 +10,7 @@
 
 | Module | Submodule | TCs Total | TCs Automated | Plan | ADO Suite | Status | Last Run |
 |---|---|---|---|---|---|---|---|
-| {MODULE_NAME} | {SUBMODULE_NAME} | — | — | ⬜ | — | 🔲 Not started | — |
+| {MODULE_NAME} | {SUBMODULE_NAME} | - | - | ⬜ | - | 🔲 Not started | - |
 
 **Legend**: ✅ Done · ⚠️ Partial · 🔲 Not started · ⛔ Blocked
 
@@ -44,7 +44,7 @@ npx playwright test --last-failed
 
 | ID | Description | Affects | Opened | Status |
 |---|---|---|---|---|
-| — | No active blockers | — | — | — |
+| - | No active blockers | - | - | - |
 
 ---
 
@@ -52,8 +52,8 @@ npx playwright test --last-failed
 
 | Suite | Date | Pass | Fail | Skip | CI Link |
 |---|---|---|---|---|---|
-| E2E | — | — | — | — | — |
-| API | — | — | — | — | — |
+| E2E | - | - | - | - | - |
+| API | - | - | - | - | - |
 
 > Update this table after each significant run. The CI Link can be an ADO TestRun URL, a
 > GitHub Actions run URL, or a path to a local report file.
@@ -62,7 +62,7 @@ npx playwright test --last-failed
 
 | Date | Suite | Pass | Skip | Fail | Duration | Report |
 |---|---|---|---|---|---|---|
-| — | — | — | — | — | — | — |
+| - | - | - | - | - | - | - |
 
 ## Flaky Tests
 
@@ -81,7 +81,7 @@ npx playwright test --last-failed
 <!-- Completed sprint checklists are moved here from AGENT-NEXT-STEPS.md -->
 <!-- Format per sprint: -->
 <!--
-### Sprint N — {SPRINT_NAME} ({YYYY-MM-DD})
+### Sprint N - {SPRINT_NAME} ({YYYY-MM-DD})
 
 **Submodules**: {list}
 **TCs automated**: {N} P0 + {M} P1

package/templates/session-summary.md

@@ -1,4 +1,4 @@
-# Session Summary — {{SESSION_TITLE}}
+# Session Summary - {{SESSION_TITLE}}
 
 **Date**: YYYY-MM-DD
 **Session type**: Module Analysis / Spec Generation / Test Plan / Automation / ADO Sync / Maintenance
@@ -44,7 +44,7 @@
 
 | DEF-ID | Title | Severity | File opened? |
 |--------|-------|----------|--------------|
-| DEF-{{NNN}} | {{title}} | {{severity}} | Yes — `qa/06-defects/open/DEF-{{NNN}}.md` |
+| DEF-{{NNN}} | {{title}} | {{severity}} | Yes - `qa/06-defects/open/DEF-{{NNN}}.md` |
 
 ---
 

package/templates/specification/00-inventory.md

@@ -1,4 +1,4 @@
-# MODULE: {{MODULE_NAME}} — Submodule: {{SUBMODULE_NAME}}
+# MODULE: {{MODULE_NAME}} - Submodule: {{SUBMODULE_NAME}}
 
 > **Template version**: 1.0 | Replace all `{{...}}` with actual values before committing.
 
@@ -18,7 +18,7 @@
 
 | Level | Label | URL |
 |-------|-------|-----|
-| 1 | {{TOP_MENU}} | — |
+| 1 | {{TOP_MENU}} | - |
 | 2 | {{SUBMENU}} | `{{URL}}` |
 
 ---
@@ -71,7 +71,7 @@
 | Submodule | Relationship | Notes |
 |-----------|-------------|-------|
 | {{submodule}} | Provides data to this module | Dropdown populated from {{API}} |
-| {{submodule}} | Depends on data from this module | — |
+| {{submodule}} | Depends on data from this module | - |
 
 ---
 

package/templates/specification/01-business-rules.md

@@ -1,4 +1,4 @@
-# Business Rules — {{MODULE_NAME}}: {{SUBMODULE_NAME}}
+# Business Rules - {{MODULE_NAME}}: {{SUBMODULE_NAME}}
 
 > **Module code**: {{MODULE_CODE}} | **Submodule code**: {{SUBMODULE_CODE}}  
 > **Last updated**: YYYY-MM-DD
@@ -32,7 +32,7 @@
 - **Type**: Access Control
 - **Trigger**: When user with role {{role}} navigates to {{URL}}
 - **Behavior**: {{redirect / error / empty page}}
-- **Notes**: —
+- **Notes**: -
 
 ---
 
@@ -42,7 +42,7 @@
 - **Trigger**: When {{action}} is performed on a record with status {{STATUS_A}}
 - **Behavior**: Record transitions from {{STATUS_A}} to {{STATUS_B}}
 - **Invalid state**: Attempting this action on status {{STATUS_C}} results in {{error}}
-- **Notes**: —
+- **Notes**: -
 
 ---
 
@@ -51,7 +51,7 @@
 - **Type**: Calculation
 - **Trigger**: When {{field}} or {{field}} changes
 - **Behavior**: {{calculated_field}} = {{formula}}
-- **Notes**: —
+- **Notes**: -
 
 ---
 
@@ -59,9 +59,9 @@
 
 - **Type**: Integration
 - **Trigger**: When {{action}} completes successfully
-- **Behavior**: {{external system}} is notified/called — {{what happens}}
+- **Behavior**: {{external system}} is notified/called - {{what happens}}
 - **Fallback**: {{what happens if external system fails}}
-- **Notes**: —
+- **Notes**: -
 
 ---
 

package/templates/specification/02-workflows.md

@@ -1,4 +1,4 @@
-# Workflows — {{MODULE_NAME}}: {{SUBMODULE_NAME}}
+# Workflows - {{MODULE_NAME}}: {{SUBMODULE_NAME}}
 
 > **Module code**: {{MODULE_CODE}} | **Submodule code**: {{SUBMODULE_CODE}}  
 > **Last updated**: YYYY-MM-DD

package/templates/specification/03-roles-permissions.md

@@ -1,4 +1,4 @@
-# Roles and Permissions — {{MODULE_NAME}}: {{SUBMODULE_NAME}}
+# Roles and Permissions - {{MODULE_NAME}}: {{SUBMODULE_NAME}}
 
 > **Module code**: {{MODULE_CODE}} | **Submodule code**: {{SUBMODULE_CODE}}  
 > **Last updated**: YYYY-MM-DD

package/templates/specification/04-test-data.md

@@ -1,4 +1,4 @@
-# Test Data — {{MODULE_NAME}}: {{SUBMODULE_NAME}}
+# Test Data - {{MODULE_NAME}}: {{SUBMODULE_NAME}}
 
 > **Module code**: {{MODULE_CODE}} | **Submodule code**: {{SUBMODULE_CODE}}  
 > **Last updated**: YYYY-MM-DD
@@ -23,13 +23,13 @@ The following data must exist in the QA environment before tests run:
 
 ## Data Shapes for Key Scenarios
 
-### Scenario: Happy path — create record
+### Scenario: Happy path - create record
 
 | Field | Value / Rule |
 |-------|-------------|
-| {{name-field}} | `Test-{EXEC_IDX}` — unique per run via EXEC_IDX pattern |
+| {{name-field}} | `Test-{EXEC_IDX}` - unique per run via EXEC_IDX pattern |
 | {{select-field}} | Any valid option (first option is acceptable) |
-| {{date-field}} | `${2120 + (EXEC_IDX % 10)}-01-01` — future date, collision-resistant |
+| {{date-field}} | `${2120 + (EXEC_IDX % 10)}-01-01` - future date, collision-resistant |
 | User | `{{Role 1}}`, credentials from `QA_USER_{{ROLE1_UPPER}}_EMAIL` |
 
 ### Scenario: Required field validation
@@ -49,7 +49,7 @@ The following data must exist in the QA environment before tests run:
 
 **Expected**: System error message: "{{exact duplicate error text}}"
 
-### Scenario: State transition — {{action}}
+### Scenario: State transition - {{action}}
 
 | Field | Value |
 |-------|-------|
@@ -82,8 +82,8 @@ const testDate = `${year}-${month}-${day}`;
 
 ## Data Isolation Rules
 
-1. Each test creates its own data — no shared mutable state between tests
-2. `beforeAll` creates records for the entire suite — provision ≥ N records for N consuming tests
+1. Each test creates its own data - no shared mutable state between tests
+2. `beforeAll` creates records for the entire suite - provision ≥ N records for N consuming tests
 3. No test teardown required when EXEC_IDX-based names are used (future-dated records do not collide across runs)
 4. If a test modifies shared data (approve/reject), it must create its own record in `beforeAll`
 
@@ -93,7 +93,7 @@ const testDate = `${year}-${month}-${day}`;
 
 | Item | Reason for retirement | Replaced by |
 |------|-----------------------|-------------|
-| {{item}} | Real employee data — PII risk | EXEC_IDX-generated test record |
+| {{item}} | Real employee data - PII risk | EXEC_IDX-generated test record |
 
 ---
 

package/templates/specification/05-test-scenarios.md

@@ -1,4 +1,4 @@
-# Test Scenarios — {{MODULE_NAME}}: {{SUBMODULE_NAME}}
+# Test Scenarios - {{MODULE_NAME}}: {{SUBMODULE_NAME}}
 
 > **Module code**: {{MODULE_CODE}} | **Submodule code**: {{SUBMODULE_CODE}}  
 > **Last updated**: YYYY-MM-DD
@@ -75,7 +75,7 @@
 
 ---
 
-### TC-{{M}}-{{S}}-004: Create new record — happy path
+### TC-{{M}}-{{S}}-004: Create new record - happy path
 
 | Field | Value |
 |-------|-------|
@@ -97,7 +97,7 @@
 
 ---
 
-### TC-{{M}}-{{S}}-005: Required field validation — name empty
+### TC-{{M}}-{{S}}-005: Required field validation - name empty
 
 | Field | Value |
 |-------|-------|
@@ -213,9 +213,9 @@
 
 | TC ID | Business Rules | Workflow |
 |-------|---------------|---------|
-| TC-{{M}}-{{S}}-001 | — | — |
+| TC-{{M}}-{{S}}-001 | - | - |
 | TC-{{M}}-{{S}}-004 | RN-{{M}}-001 | FL-{{M}}-001 |
-| TC-{{M}}-{{S}}-005 | RN-{{M}}-001 | — |
+| TC-{{M}}-{{S}}-005 | RN-{{M}}-001 | - |
 
 ---
 

package/templates/test-case.md

@@ -1,4 +1,4 @@
-# Test Case — TC-{{MODULE}}-{{SUB}}-{{NNN}}: {{Title}}
+# Test Case - TC-{{MODULE}}-{{SUB}}-{{NNN}}: {{Title}}
 
 | Field | Value |
 |-------|-------|
@@ -11,8 +11,8 @@
 | Type | Functional / Integration / Regression / Smoke |
 | Execution | Manual / Automated / Both |
 | Automation file | `qa/07-automation/e2e/{{module}}/{{submodule}}.spec.ts` (if automated) |
-| Preconditions | {{List required setup — see 04-test-data.md}} |
-| Author | (agent output — reviewed by human) |
+| Preconditions | {{List required setup - see 04-test-data.md}} |
+| Author | (agent output - reviewed by human) |
 | Last updated | YYYY-MM-DD |
 
 ---

package/templates/test-data-guidelines.md

@@ -16,7 +16,7 @@ All user emails, passwords, API keys, and tokens must come from environment vari
 const email    = process.env.QA_USER_EMAIL!;
 const password = process.env.QA_USER_PASSWORD!;
 
-// ❌ WRONG — never commit credentials
+// ❌ WRONG - never commit credentials
 const email    = 'admin@example.com';
 const password = 'secret123';
 ```
@@ -25,7 +25,7 @@ Document env var names in `qa/04-test-data/users.md`. Use `<PLACEHOLDER>` for va
 
 ### 2. Use EXEC_IDX for unique values per run
 
-Never create records with static names — they collide between runs and can leave leftover data.
+Never create records with static names - they collide between runs and can leave leftover data.
 
 ```typescript
 const EXEC_IDX = Math.floor(Date.now() / 60_000) % 100_000;
@@ -42,7 +42,7 @@ const date  = `${year}-${month}-${day}`;
 
 ### 3. Provision in `beforeAll`, not `beforeEach`
 
-Create required records once per suite, not once per test. Each test that **consumes** a record needs its own provisioned record — never share a single record among multiple tests.
+Create required records once per suite, not once per test. Each test that **consumes** a record needs its own provisioned record - never share a single record among multiple tests.
 
 ```typescript
 test.beforeAll(async ({ browser }) => {
@@ -61,10 +61,10 @@ Complex setup that cannot be done via the UI goes in a seeder script, not inside
 
 ```
 qa/04-test-data/
-├── users.md          ← Role catalog + env var names (no real values)
-├── fixtures/         ← Static JSON/Markdown for reference data
-├── factories/        ← Dynamic data generation patterns
-└── seeders/          ← DB/API seed scripts for complex prerequisites
+├── users.md          <- Role catalog + env var names (no real values)
+├── fixtures/         <- Static JSON/Markdown for reference data
+├── factories/        <- Dynamic data generation patterns
+└── seeders/          <- DB/API seed scripts for complex prerequisites
 ```
 
 ### 5. Add `.env` and `.auth/` to `.gitignore`

package/templates/test-plan-sprint.md

@@ -1,4 +1,4 @@
-# Plan de Pruebas — {{PROYECTO}} — Sprint {{NNN}} — {{MODULO_NOMBRE}}
+# Plan de Pruebas - {{PROYECTO}} - Sprint {{NNN}} - {{MODULO_NOMBRE}}
 
 **Proyecto:** {{PROYECTO}}
 **Sprint:** {{NNN}}
@@ -6,7 +6,7 @@
 **Código módulo:** {{MODULO_CODE}}
 **Fecha planificación:** {{YYYY-MM-DD}}
 **Ventana QA:** {{YYYY-MM-DD}} y {{YYYY-MM-DD}}
-**ADO Test Plan:** [Plan {{ADO_PLAN_ID}} — {{PROYECTO}} Sprint {{NNN}}]({{ADO_TEST_PLAN_URL}}) *(omitir si ADO no está habilitado)*
+**ADO Test Plan:** [Plan {{ADO_PLAN_ID}} - {{PROYECTO}} Sprint {{NNN}}]({{ADO_TEST_PLAN_URL}}) *(omitir si ADO no está habilitado)*
 
 ---
 
@@ -37,27 +37,27 @@
 > Si no hay ADO, listar los requerimientos o módulos abordados.
 
 ### {{AREA_FUNCIONAL_1}}
-- Task {{ID}} — {{DESCRIPCION}}
-- Task {{ID}} — {{DESCRIPCION}}
+- Task {{ID}} - {{DESCRIPCION}}
+- Task {{ID}} - {{DESCRIPCION}}
 
 ### {{AREA_FUNCIONAL_2}}
-- Task {{ID}} — {{DESCRIPCION}}
+- Task {{ID}} - {{DESCRIPCION}}
 
 ---
 
 ## 4. Priorización
 
-**P0 – Confirmación (obligatorio)**
+**P0 - Confirmación (obligatorio)**
 - {{ESCENARIO_CRITICO_1}}
 - {{ESCENARIO_CRITICO_2}}
 
-**P1 – Smoke (camino feliz)**
+**P1 - Smoke (camino feliz)**
 - {{FLUJO_PRINCIPAL}}
 
-**P2 – Regresión mínima adyacente**
+**P2 - Regresión mínima adyacente**
 - {{REGRESION_1}}
 
-**P3 – Exploratoria (timeboxed)**
+**P3 - Exploratoria (timeboxed)**
 - Charter 1 ({{N}} min): {{DESCRIPCION_CHARTER}}
 
 ---
@@ -77,8 +77,8 @@
 
 - Ambiente QA disponible en `{{QA_BASE_URL}}`
 - Roles disponibles:
-  - Usuario **{{ROL_1}}** — para {{ACCION}}
-  - Usuario **{{ROL_2}}** — para {{ACCION}}
+  - Usuario **{{ROL_1}}** - para {{ACCION}}
+  - Usuario **{{ROL_2}}** - para {{ACCION}}
 - Datos base:
   - {{DATO_BASE_1}}
   - {{DATO_BASE_2}}
@@ -109,7 +109,7 @@
 
 > Convenciones:
 > - **TC-ID:** `TC-{{MODULO_CODE}}-{{SUBMODULO_CODE}}-NNN` (o `N/A` si no hay ID asignado aún)
-> - **Steps:** numerados, separados por `<br>` — verbos concretos de UI (`Navegar a`, `Ingresar`, `Hacer click`, `Verificar`)
+> - **Steps:** numerados, separados por `<br>` - verbos concretos de UI (`Navegar a`, `Ingresar`, `Hacer click`, `Verificar`)
 > - **Confirma:** `Task NNNNN` si hay tarea ADO relacionada; `N/A` si no aplica
 > - **Tipo:** `Manual` | `Automatizado` | `Ambos`
 > - **Prioridad:** `P0` | `P1` | `P2` | `P3`
@@ -149,4 +149,4 @@
 > `qa/02-test-plans/sprints/Sprint-{{NNN}}/Plan-de-Pruebas-{{PROYECTO}}-Sprint-{{NNN}}.md`
 >
 > El consolidado se genera con el script `@keber/ado-qa consolidate-sprint --sprint {{NNN}}`.
-> **No editar manualmente** — es derivado de los archivos por módulo.
+> **No editar manualmente** - es derivado de los archivos por módulo.

package/templates/test-plan.md

@@ -4,12 +4,12 @@
 >
 > This file is retained for reference only.
 
-# Test Plan — {{MODULE_NAME}}
+# Test Plan - {{MODULE_NAME}}
 
 **Plan ID**: TP-{{MODULE}}-{{VERSION}}
 **Module**: {{MODULE_NAME}}
 **Sprint / Release**: Sprint {{NNN}}
-**Prepared by**: (agent output — reviewed by human)
+**Prepared by**: (agent output - reviewed by human)
 **Date**: YYYY-MM-DD
 **ADO Test Plan**: #{ADO_PLAN_ID} (if ADO enabled)
 
@@ -74,7 +74,7 @@
 
 | Scenario | Feasible? | Reason if not |
 |----------|-----------|---------------|
-| Happy path create | Yes | — |
+| Happy path create | Yes | - |
 | Export to PDF | No | Requires visual validation |
 | Third-party OAuth | No | External system |