@keber/qa-framework 1.11.3 → 1.13.0

package/skills/qa-test-cases/SKILL.md

@@ -12,10 +12,10 @@ description: >
 
 # QA Skill: Test Case Step Expansion (Stage 4 of 6)
 
-**Stage**: 4 — Test Case Steps (expand / complete Plan de Pruebas)
+**Stage**: 4 - Test Case Steps (expand / complete Plan de Pruebas)
 **Prerequisite**: Plan de Pruebas exists at `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md`
 **Output**: Updated Plan de Pruebas table (primary) OR `qa/03-test-cases/TC-{ID}.md` files (standalone, optional)
-**Next stage**: Stage 5 — Automation (`qa-automation`) or ADO Integration (`qa-ado-integration`)
+**Next stage**: Stage 5 - Automation (`qa-automation`) or ADO Integration (`qa-ado-integration`)
 
 > **Pipeline rule**: TC IDs must be unique across the module. Never reuse a TC ID.
 > **Primary output** is the table in the Plan de Pruebas, not standalone files.
@@ -29,28 +29,28 @@ description: >
 | Plan de Pruebas has summary steps (from `05-test-scenarios.md`) that aren't concrete enough | Expand steps row by row in the table |
 | A specific TC requires multi-scenario, multi-role documentation | Create standalone `TC-{ID}.md` in `qa/03-test-cases/` |
 | TC is reused across multiple sprints unchanged | Create standalone file with cross-reference |
-| All steps in the table are already concrete and observable | Stage 4 not needed — proceed to Stage 5 or ADO |
+| All steps in the table are already concrete and observable | Stage 4 not needed - proceed to Stage 5 or ADO |
 
 ---
 
 ## Inputs Required
 
-1. `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` — table to expand
-2. `qa/01-specifications/module-{name}/submodule-{name}/00-inventory.md` — UI field names, button labels, routes
-3. `qa/01-specifications/module-{name}/submodule-{name}/05-test-scenarios.md` — original scenario text
+1. `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` - table to expand
+2. `qa/01-specifications/module-{name}/submodule-{name}/00-inventory.md` - UI field names, button labels, routes
+3. `qa/01-specifications/module-{name}/submodule-{name}/05-test-scenarios.md` - original scenario text
 
 ---
 
 ## Process
 
-### Step 1 — Identify rows needing expansion
+### Step 1 - Identify rows needing expansion
 
 Review the Tabla de Pruebas. Flag rows where Steps are:
 - Summary-level (e.g., "Navegar al módulo y verificar comportamiento")
 - Missing intermediate steps (fewer than 2 steps for a non-trivial scenario)
 - Using vague verbs ("hacer lo necesario", "verificar que funciona")
 
-### Step 2 — Expand steps in-table
+### Step 2 - Expand steps in-table
 
 For each flagged row, rewrite the Steps cell using:
 - `00-inventory.md` for exact UI element names and routes
@@ -62,14 +62,14 @@ Quality rules per step:
 - One action + one verification per step (when applicable)
 - Resultado Esperado must be measurable (specific text, state, count)
 
-### Step 3 — Standalone TC files (only when needed)
+### Step 3 - Standalone TC files (only when needed)
 
 If a TC requires standalone documentation (see "When to use" table above):
 - Save as `qa/03-test-cases/TC-{ID}.md`
 - Use template from `references/test-case-template.md`
 - Add a note in the Plan de Pruebas table row: "See qa/03-test-cases/TC-{ID}.md"
 
-### Step 4 — Quality gates
+### Step 4 - Quality gates
 
 Before marking stage complete:
 - [ ] Every row in the table has ≥ 2 numbered steps
@@ -77,6 +77,7 @@ Before marking stage complete:
 - [ ] Every Resultado Esperado is measurable
 - [ ] No blank cells in Confirma column (Task ID or `N/A`)
 - [ ] Standalone TC files (if created) are cross-referenced in the table
+- [ ] Output verification run and the counts reported (see `../qa-module-analysis/references/output-verification.md`) - report the command output, never a compliance claim
 
 ---
 
@@ -95,74 +96,3 @@ Before marking stage complete:
 
 - Updated `Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` (rows with expanded steps)
 - Optionally: `qa/03-test-cases/TC-{ID}.md` for complex/reusable TCs
-
-
----
-
-## Inputs Required
-
-1. `qa/01-specifications/{module}/05-test-scenarios.md` — source scenarios to expand
-2. Test plan (if available) — defines priority and which scenarios are in scope
-3. Module TC-ID range prefix (e.g., `PROV` → `TC-PROV-001`)
-
----
-
-## Process
-
-### Step 1 — Audit existing TCs
-
-Check `qa/03-test-cases/automated/` for existing TC files in this module. Note:
-- Highest existing TC number (to continue sequence from next number)
-- Any `PENDING-CODE` TCs (skip automation loop; flag for manual follow-up)
-- Any TCs for scenarios already documented (do not duplicate)
-
-### Step 2 — Map scenarios to TC IDs
-
-For each scenario in `05-test-scenarios.md`:
-- Assign sequential TC ID: `TC-{PREFIX}-{NNN}` (zero-padded to 3 digits)
-- Annotate with priority and automation feasibility from test plan (if available)
-- Skip scenarios marked with `BLOCKED-PERMISSIONS` or `NOT-AUTOMATABLE` — generate TC shells only
-
-### Step 3 — Write TC documents
-
-Full template: `references/test-case-template.md`
-
-Each TC file must include:
-- **ID** and **Title**
-- **Priority** (P0/P1/P2/P3)
-- **Automation feasibility** (fully / partially / not)
-- **Preconditions** (setup state + test data reference)
-- **Steps** (numbered, action + input + expected result per step)
-- **Postconditions** (cleanup or state left after TC)
-- **Tags** (e.g., `smoke`, `regression`, `happy-path`)
-
-### Step 4 — Quality gates
-
-Before saving each TC:
-- Every step has an expected result — no steps with "verify it works"
-- Test data references a named fixture or `qa/01-specifications/{module}/04-test-data.md`
-- For CRUD TCs: steps cover create → verify → update → verify → delete → verify
-- Preconditions do not duplicate setup that belongs in a shared fixture
-
-### Step 5 — Update index
-
-Create or update `qa/03-test-cases/automated/{module}-index.md`:
-- Table: TC ID | Title | Priority | Feasibility | Spec reference
-
----
-
-## Key Rules
-
-| Rule | Correct | Wrong |
-|---|---|---|
-| TC isolation | Each TC is independent | TCs depend on prior TC's data |
-| Step granularity | One action + one assertion per step | Multi-action steps |
-| Data hygiene | Named fixtures or spec data | Hardcoded values in steps |
-| ID stability | Never re-number existing IDs | Renaming breaks ADO links |
-
----
-
-## Outputs
-
-- `qa/03-test-cases/automated/TC-{ID}.md` (one per scenario)
-- `qa/03-test-cases/automated/{module}-index.md`

package/skills/qa-test-cases/references/test-case-template.md

@@ -16,7 +16,7 @@
 | Submodule | {Submodule display name} |
 | Priority | P0 / P1 / P2 / P3 |
 | Type | Functional / Negative / Regression / Security / Integration |
-| Origin | UI-OBSERVED / PENDING-CODE / BLOCKED-PERMISSIONS |
+| Origin | UI-OBSERVED / PENDING-BROWSER / PENDING-CODE / BLOCKED-PERMISSIONS |
 | Observation date | YYYY-MM-DD |
 | Automatable | Yes / Partial / No |
 | Playwright file | (fill when automation is written) |
@@ -106,7 +106,7 @@
 Create at: `qa/03-test-cases/automated/{module}-index.md`
 
 ```markdown
-# TC Index — {Module Display Name}
+# TC Index - {Module Display Name}
 
 | TC ID | Title | Priority | Feasibility | Spec reference |
 |-------|-------|----------|-------------|---------------|
@@ -133,10 +133,10 @@ Create at: `qa/03-test-cases/automated/{module}-index.md`
 ### Defect links
 
 When skipping a step due to a bug:  
-✅ `Step 4 — SKIPPED: DEF-001 (ADO #21944). Switch defaults to OFF. Re-enable after fix.`
+✅ `Step 4 - SKIPPED: DEF-001 (ADO #21944). Switch defaults to OFF. Re-enable after fix.`
 
 ### TC isolation
 
-- Each TC is fully independent — no TC depends on state from a prior TC
+- Each TC is fully independent - no TC depends on state from a prior TC
 - All required data is provisioned in preconditions or `beforeAll`
-- CRUD TCs cover: create → verify → update → verify → delete → verify
+- CRUD TCs cover: create -> verify -> update -> verify -> delete -> verify

package/skills/qa-test-plan/SKILL.md

@@ -13,37 +13,37 @@ description: >
 
 # QA Skill: Plan de Pruebas (Stage 3 of 6)
 
-**Stage**: 3 — Plan de Pruebas (test plan + detailed test case table)
+**Stage**: 3 - Plan de Pruebas (test plan + detailed test case table)
 **Prerequisite**: `05-test-scenarios.md` must exist for all in-scope submodules (Stage 2 complete)
 **Output**: `qa/02-test-plans/sprints/Sprint-{N}/Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md`
-**Next stage**: Stage 4 — Expand steps (`qa-test-cases`) if steps need more detail; or Stage 5 — Automation (`qa-automation`)
+**Next stage**: Stage 4 - Expand steps (`qa-test-cases`) if steps need more detail; or Stage 5 - Automation (`qa-automation`)
 
 > **Pipeline rule**: Do not automate TCs that are not in an active Plan de Pruebas.
-> **ADO rule**: The Plan de Pruebas is the source for ADO Test Cases — steps in the table become steps in ADO.
+> **ADO rule**: The Plan de Pruebas is the source for ADO Test Cases - steps in the table become steps in ADO.
 
 ---
 
 ## Inputs Required
 
-1. `qa/01-specifications/module-{name}/submodule-{name}/` — spec files, especially:
-   - `00-inventory.md` — UI fields, buttons, routes (source for concrete step text)
-   - `05-test-scenarios.md` — TC list with summary steps and expected results
+1. `qa/01-specifications/module-{name}/submodule-{name}/` - spec files, especially:
+   - `00-inventory.md` - UI fields, buttons, routes (source for concrete step text)
+   - `05-test-scenarios.md` - TC list with summary steps and expected results
 2. Sprint number and module name (ask the user if not given)
 3. ADO sprint tasks/stories (if available; use for "Confirma" column; `N/A` if not)
-4. Project name from `qa/qa-framework.config.json` → `project.name`
+4. Project name from `qa/qa-framework.config.json` -> `project.name`
 
 ---
 
 ## Process
 
-### Step 1 — Collect TC inventory
+### Step 1 - Collect TC inventory
 
 For each in-scope submodule, read `05-test-scenarios.md` and aggregate:
 - Total TC count by priority (P0/P1/P2/P3)
 - TC count by type: Manual / Automatizado / Ambos
-- TCs marked `BLOCKED-PERMISSIONS` or `PENDING-CODE` → include in table but mark type as `Bloqueado`
+- TCs marked `BLOCKED-PERMISSIONS`, `PENDING-CODE`, or `PENDING-BROWSER` -> include in table but mark type as `Bloqueado`
 
-### Step 2 — Apply priority rules
+### Step 2 - Apply priority rules
 
 Use the priority decision tree (see `references/plan-de-pruebas-template.md`):
 - **P0**: happy path confirmation; show-stopper risk; data corruption
@@ -51,14 +51,14 @@ Use the priority decision tree (see `references/plan-de-pruebas-template.md`):
 - **P2**: secondary features (export, pagination, search); regression adjacent
 - **P3**: edge cases; exploratory charters (timeboxed)
 
-### Step 3 — Define TestSuites (ADO grouping)
+### Step 3 - Define TestSuites (ADO grouping)
 
-Group TCs by functional area. Each group → one ADO Test Suite:
-- 3–7 suites per module is typical
+Group TCs by functional area. Each group -> one ADO Test Suite:
+- 3-7 suites per module is typical
 - Name suites after the functional area, not the priority (e.g., "Solicitud Individual", "Aprobación Web")
 - Last suite: "Exploratoria" if there are P3 charters
 
-### Step 4 — Write the Plan de Pruebas document
+### Step 4 - Write the Plan de Pruebas document
 
 Full template: `references/plan-de-pruebas-template.md`
 
@@ -67,25 +67,25 @@ Required sections:
 2. Objetivo
 3. Alcance (en alcance / fuera de alcance)
 4. Items del Sprint normalizados (grouped by area; Task IDs if available)
-5. Priorización (P0–P3 summary)
+5. Priorización (P0-P3 summary)
 6. TestSuites (agrupación para ADO)
 7. Precondiciones generales (ambiente, roles, datos base)
 8. Datos mínimos sugeridos (table with env var references)
 9. Supuestos & Faltantes críticos (TODO items before execution)
 10. **Tabla de Pruebas** (see Step 4a)
-11. Matriz de Trazabilidad (Task ↔ N)
+11. Matriz de Trazabilidad (Task <-> N)
 12. Notas de automatización
 
-#### Step 4a — Tabla de Pruebas (most important section)
+#### Step 4a - Tabla de Pruebas (most important section)
 
 Each row in the table is one test case. Columns:
 
 | Column | Rules |
 |--------|-------|
-| **N** | Sequential number (1, 2, 3...) — used in trazabilidad matrix |
+| **N** | Sequential number (1, 2, 3...) - used in trazabilidad matrix |
 | **TC-ID** | `TC-{MODULE}-{SUB}-{NNN}` from specs; or assign sequentially if new |
 | **Suite / Área Funcional** | Suite name from Step 3 |
-| **Título** | `[ETIQUETA][P#] Descripción concisa` — etiquetas: CONFIRMACION, SMOKE, REGRESION, EXPLORATORIA |
+| **Título** | `[ETIQUETA][P#] Descripción concisa` - etiquetas: CONFIRMACION, SMOKE, REGRESION, EXPLORATORIA |
 | **Descripción** | What scenario this validates (1-2 sentences) |
 | **Steps** | Numbered, separated by `<br>`. Use concrete UI verbs from `00-inventory.md`: "Navegar a", "Ingresar", "Hacer click en", "Verificar que", "Seleccionar". Reference env vars as `{ENV_VAR}` |
 | **Resultado Esperado** | Observable outcome: specific text, state change, notification. Not vague ("works correctly") |
@@ -99,9 +99,9 @@ Each row in the table is one test case. Columns:
 - Reference test data by env var name (`{QA_USER_EMAIL}`) or pattern (`EXEC_IDX`)
 - Exploratory charters: steps = "Timebox N min" + charter goal + "Registrar hallazgos"
 
-### Step 5 — Update status
+### Step 5 - Update status
 
-- Update `qa/README.md` module row (plan status → ✅)
+- Update `qa/README.md` module row (plan status -> ✅)
 - If ADO enabled: stub the ADO Plan ID field for the ADO integration skill
 
 ---
@@ -119,68 +119,4 @@ Each row in the table is one test case. Columns:
 - [ ] Resultado Esperado is measurable (specific text/state, not "works correctly")
 - [ ] Matriz de Trazabilidad covers all Tasks mentioned in the table
 - [ ] `Confirma` column has no blank cells (must be Task ID or `N/A`)
-
-
-> **Pipeline rule**: Do not automate TCs that are not in an approved or active test plan.
-
----
-
-## Inputs Required
-
-1. `qa/01-specifications/module-{name}/` — all submodule specs
-2. Scope definition — which submodules are in this test plan (ask the user if not given)
-3. Priority guidance (from team or implied by sprint scope)
-
----
-
-## Process
-
-### Step 1 — Collect TC inventory
-
-For each in-scope submodule, read `05-test-scenarios.md` and aggregate:
-- Total TC count by priority (P0/P1/P2/P3)
-- TC count by automation feasibility (fully / partially / not automatable)
-- Any TCs marked `BLOCKED-PERMISSIONS` or `PENDING-CODE` (these go in the exclusion list)
-
-### Step 2 — Apply priority rules
-
-Use the priority decision tree (see `references/priority-and-feasibility.md`) to assign or validate priorities. Key rules:
-
-- **P0**: primary happy path; show-stopper risk; critical data corruption
-- **P1**: common negative scenarios; cross-module dependencies; state machine transitions
-- **P2**: secondary features (export, pagination, search)
-- **P3**: edge cases, cosmetic, rare scenarios
-
-### Step 3 — Apply automation feasibility rules
-
-- **Fully automatable**: deterministic, observable via browser, no external system dependency
-- **Partially automatable**: some result requires human inspection OR external system can be mocked
-- **Not automatable**: physical access required; inherently non-deterministic; irreversible QA side effects; BLOCKED-PERMISSIONS
-
-### Step 4 — Write the test plan document
-
-Full document template: `references/test-plan-template.md`
-
-Required sections:
-1. Objective
-2. Scope (in/out)
-3. Automation feasibility analysis table (per submodule)
-4. Priority distribution table
-5. TC selection suites (P0 suite, P1 suite)
-6. Azure DevOps mapping (if ADO enabled)
-7. Test environment
-8. Risks and assumptions
-9. Excluded TCs (with reason)
-10. Execution schedule
-
-### Step 5 — Update status
-
-- Update `qa/README.md` module row (plan status → ✅)
-- If ADO enabled: stub the ADO Plan ID field for Step 6 (ADO integration)
-
----
-
-## Outputs
-
-- `qa/02-test-plans/automated/{module}-test-plan.md`
-- `qa/README.md` plan status updated
+- [ ] Output verification run and the counts reported (see `../qa-module-analysis/references/output-verification.md`) - report the command output, never a compliance claim

package/skills/qa-test-plan/references/plan-de-pruebas-template.md

@@ -1,4 +1,4 @@
-# Reference: Plan de Pruebas — Template and Conventions
+# Reference: Plan de Pruebas - Template and Conventions
 
 > Loaded by `skills/qa-test-plan/` when generating a Plan de Pruebas document.
 
@@ -17,7 +17,7 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 ## Complete Document Template
 
 ```markdown
-# Plan de Pruebas — {PROYECTO} — Sprint {NNN} — {MODULO_NOMBRE}
+# Plan de Pruebas - {PROYECTO} - Sprint {NNN} - {MODULO_NOMBRE}
 
 **Proyecto:** {PROYECTO}
 **Sprint:** {NNN}
@@ -25,7 +25,7 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 **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}]({ADO_TEST_PLAN_URL})  ← omit if ADO disabled
+**ADO Test Plan:** [Plan {ADO_PLAN_ID}]({ADO_TEST_PLAN_URL})  <- omit if ADO disabled
 
 ---
 
@@ -34,19 +34,19 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 ### En alcance
 ### Fuera de alcance
 ## 3. Items del Sprint (normalizados)
-## 4. Priorización (P0–P3 summary)
+## 4. Priorización (P0-P3 summary)
 ## 5. TestSuites (agrupación para ADO)
 ## 6. Precondiciones generales
 ## 7. Datos mínimos sugeridos
 ## 8. Supuestos & Faltantes críticos
-## 9. Tabla de Pruebas    ← PRIMARY ARTIFACT
+## 9. Tabla de Pruebas    <- PRIMARY ARTIFACT
 ## 10. Matriz de Trazabilidad
 ## 11. Notas de automatización
 ```
 
 ---
 
-## Tabla de Pruebas — Column Conventions
+## Tabla de Pruebas - Column Conventions
 
 | Column | Type | Rules |
 |--------|------|-------|
@@ -62,10 +62,10 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 | Prioridad | enum | `P0` \| `P1` \| `P2` \| `P3` |
 
 ### Title Etiquetas
-- `[CONFIRMACION]` — confirms a specific sprint item is implemented
-- `[SMOKE]` — happy path end-to-end
-- `[REGRESION]` — validates no regression in adjacent functionality
-- `[EXPLORATORIA]` — charter-based, timeboxed, no fixed expected result
+- `[CONFIRMACION]` - confirms a specific sprint item is implemented
+- `[SMOKE]` - happy path end-to-end
+- `[REGRESION]` - validates no regression in adjacent functionality
+- `[EXPLORATORIA]` - charter-based, timeboxed, no fixed expected result
 
 ---
 
@@ -79,9 +79,9 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 - `5) Revisar bandeja de correo del usuario {QA_NOTIFY_EMAIL}`
 
 **DO NOT:**
-- `1) Ejecutar la funcionalidad` ← too vague
-- `2) Verificar que funciona` ← not measurable
-- `3) Hacer las acciones necesarias` ← not observable
+- `1) Ejecutar la funcionalidad` <- too vague
+- `2) Verificar que funciona` <- not measurable
+- `3) Hacer las acciones necesarias` <- not observable
 
 **References to test data:**
 - Env vars: `{QA_USER_EMAIL}`, `{QA_ADMIN_EMAIL}`, `{QA_BASE_URL}`
@@ -90,7 +90,7 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 
 **Exploratory charters:**
 ```
-1) Timebox: 45–60 min
+1) Timebox: 45-60 min
 2) Objetivo: {CHARTER_GOAL}
 3) Explorar {AREA} variando {VARIABLES}
 4) Registrar hallazgos con evidencia (screenshot + descripción)
@@ -101,15 +101,15 @@ Where `{modulo}` is the module code (e.g., `RCL-Casino`, `PortalProveedores`, `A
 ## Priority Decision Tree
 
 ```
-Is it the primary happy path?                    → P0
-Is it a show-stopper risk or data corruption?    → P0
-Is it a common negative scenario?                → P1
-Is it a cross-module dependency?                 → P1
-Is it a state machine transition?                → P1
-Is it a secondary feature (export/search)?       → P2
-Is it regression in adjacent functionality?      → P2
-Is it an edge case or low-frequency scenario?    → P3
-Is it exploratory / cosmetic?                    → P3
+Is it the primary happy path?                    -> P0
+Is it a show-stopper risk or data corruption?    -> P0
+Is it a common negative scenario?                -> P1
+Is it a cross-module dependency?                 -> P1
+Is it a state machine transition?                -> P1
+Is it a secondary feature (export/search)?       -> P2
+Is it regression in adjacent functionality?      -> P2
+Is it an edge case or low-frequency scenario?    -> P3
+Is it exploratory / cosmetic?                    -> P3
 ```
 
 ---
@@ -145,4 +145,4 @@ If no ADO tasks: substitute with requirement IDs or user story references.
 When a sprint covers multiple modules:
 - Create one `Plan-de-Pruebas-{proyecto}-Sprint-{N}-{modulo}.md` per module
 - The consolidated `Plan-de-Pruebas-{proyecto}-Sprint-{N}.md` is generated by `@keber/ado-qa consolidate-sprint`
-- **Do not create the consolidated file manually** — it is a derived artifact
+- **Do not create the consolidated file manually** - it is a derived artifact

package/skills/qa-test-stabilization/SKILL.md

@@ -11,7 +11,7 @@ description: >
 
 # QA Skill: Test Stabilization (Stage 5b)
 
-**Stage**: 5b — Stabilization (parallel to / after Stage 5)  
+**Stage**: 5b - Stabilization (parallel to / after Stage 5)  
 **Prerequisite**: Failing or flaky tests exist in `qa/07-automation/e2e/`  
 **Output**: Stable passing tests + `STABILIZATION-REPORT.md`  
 **Next stage**: Return to Stage 5 to continue automation, or Stage 6 if all tests pass
@@ -22,16 +22,16 @@ description: >
 
 ## Inputs Required
 
-1. Failure output — CI log, local run output, or list of failing test names
-2. `qa/07-automation/e2e/{file}.spec.ts` — failing spec files
-3. `qa/01-specifications/{module}/` — ground truth for expected behavior
-4. `qa/07-automation/playwright.config.ts` — current runner config
+1. Failure output - CI log, local run output, or list of failing test names
+2. `qa/07-automation/e2e/{file}.spec.ts` - failing spec files
+3. `qa/01-specifications/{module}/` - ground truth for expected behavior
+4. `qa/07-automation/playwright.config.ts` - current runner config
 
 ---
 
 ## Process
 
-### Step 1 — Reproduce locally
+### Step 1 - Reproduce locally
 
 Run failing tests in isolation:
 ```
@@ -39,42 +39,52 @@ npx playwright test {file}.spec.ts --project={project} --reporter=list
 ```
 Do not trust CI-only failures until reproduced, or classify immediately as Category H (CI environment).
 
-### Step 2 — Classify each failure
+Any finding produced by a standalone script - Node + Playwright run outside the project's test
+runner, such as an ad-hoc diagnosis script - must be confirmed through `npx playwright test` before
+it decides anything about a defect's status. A standalone script and the official suite have
+produced opposite, independently reproducible results for the same scenario: a polling diagnostic
+saw a toast 4/4 times while the official suite saw none, 6/6 across two runs. The defect had already
+been closed on the standalone evidence and had to be reopened. Standalone output is diagnostic
+input, never a verdict.
+
+### Step 2 - Classify each failure
 
 Use the classification protocol: `references/classification-protocol.md`
 
 Category summary:
-- **A — Selector broken**: locator no longer matches; fix selector
-- **B — Timing/flaky**: async operation not awaited correctly; replace with proper wait
-- **C — Data conflict**: parallel test data collision; apply `EXEC_IDX`
-- **D — Auth/session**: session expired or role mismatch; repair fixture
-- **E — Spec mismatch**: behavior changed; update spec first, then test
-- **F — Network dependency**: external call not mocked; add mock or skip
-- **G — Environment**: missing env var or wrong base URL; fix config
-- **H — CI environment**: OS/browser difference; add retry or tag as `@ci-skip`
-- **I — Logic error**: test assertion does not match the spec; fix assertion 
-  to match spec — **not** to match wrong app behavior. If the app is at fault, 
+- **A - Selector broken**: locator no longer matches; fix selector
+- **B - Timing/flaky**: async operation not awaited correctly; replace with proper wait
+- **C - Data conflict**: parallel test data collision; apply `EXEC_IDX`
+- **D - Auth/session**: session expired or role mismatch; repair fixture
+- **E - Spec mismatch**: behavior changed; update spec first, then test
+- **F - Network dependency**: external call not mocked; add mock or skip
+- **G - Environment**: missing env var or wrong base URL; fix config
+- **H - CI environment**: OS/browser difference; add retry or tag as `@ci-skip`
+- **I - Logic error**: test assertion does not match the spec; fix assertion 
+  to match spec - **not** to match wrong app behavior. If the app is at fault, 
   use `test.fail()` instead of correcting the assertion direction.
 
-### Step 3 — Apply fixes in priority order
+### Step 3 - Apply fixes in priority order
 
-Fix category priorities: A → C → D → B → I → E → F → G → H
+Fix category priorities: A -> C -> D -> B -> I -> E -> F -> G -> H
 
 For each fix:
-1. Apply minimal change — do not refactor surrounding code
+1. Apply minimal change - do not refactor surrounding code
 2. Re-run the specific TC to verify fix
 3. Re-run the full describe block to verify no regression
 4. Note confidence score (0-100) for each fix
 
-**Category I special rule — assertion polarity:**  
+**Category I special rule - assertion polarity:**  
 Before flipping or weakening an assertion, confirm its direction against the 
-spec. If the spec says the condition should hold and the app violates it → 
-the original assertion was *correct* and the app is broken → use `test.fail()` 
+spec. If the spec says the condition should hold and the app violates it -> 
+the original assertion was *correct* and the app is broken -> use `test.fail()` 
 + open a defect. Do NOT invert the assertion.  
 A test flipped from failing to passing by inverting its assertion is masking 
-a defect - which is worse than a failing test.
+a defect - which is worse than a failing test.  
+The confirmation that the app violates the spec must come from the official 
+suite, not from an isolated or standalone script.
 
-### Step 4 — Confidence scoring
+### Step 4 - Confidence scoring
 
 Calculate composite confidence:
 - Consistent pass ×3 locally: +40
@@ -84,17 +94,35 @@ Calculate composite confidence:
 
 Target: ≥ 90 before marking TC as stable.
 
-### Step 5 — Handle unresolvable failures
+### Step 5 - Handle unresolvable failures
 
 If a failure cannot be fixed without application code change:
 - Add `test.skip(true, 'PENDING-CODE: {ADO item or description}')` annotation
 - Update `qa/01-specifications/{module}/05-test-scenarios.md` with `PENDING-CODE` note
 
-### Step 6 — Update spec if behavior changed (Category E)
+**BLOCKING - before creating any defect file under `qa/06-defects/open/`:**
+
+1. Search the project's known-issues record for this module. Where a defect tracker is integrated,
+   that means the tracker's already-filed items; where the project keeps a local known-issues file,
+   search that too. Use the symptom, not the TC ID - the same defect reaches different TCs.
+2. Record the search inside the defect file itself: source consulted, terms searched, matches found
+   (or "none"). A defect file without that section is not ready to be filed.
+3. If a match exists in an open state: do **not** create a new defect. Reference the existing item
+   in the test's `test.fail()` / `test.skip()` note instead.
+4. If a match exists in a closed state: this is a regression, not a new defect. File it as such and
+   say which item it reopens - a defect closed three times and refiled as new each time reads as
+   three unrelated bugs.
+5. Only with no match, create a new defect using the project's `defectIdPattern`.
+
+This gate exists because it was skipped: four defects were filed in one session without it, and a
+later manual check found one of them sharing its exact symptom with three already-closed tracker
+items.
+
+### Step 6 - Update spec if behavior changed (Category E)
 
 Follow `qa-maintenance` skill for mid-sprint spec updates. Do not change spec to match wrong behavior.
 
-### Step 7 — Re-run full suite
+### Step 7 - Re-run full suite
 
 After all fixes applied, run the full module suite:
 ```
@@ -102,7 +130,7 @@ npx playwright test --project={module} --reporter=list
 ```
 All previously failing TCs should pass or be explicitly skipped.
 
-### Step 8 — Produce stabilization report
+### Step 8 - Produce stabilization report
 
 Template: `references/classification-protocol.md` (STABILIZATION-REPORT section)
 
@@ -121,8 +149,9 @@ Required sections:
 | No `waitForTimeout` | Use `waitForSelector` or `waitForResponse` |
 | No app code changes | Fix tests only, not application |
 | Spec is ground truth | Never change spec to match wrong behavior |
-| Unresolvable → skip | With PENDING-CODE annotation |
+| Unresolvable -> skip | With PENDING-CODE annotation |
 | Report required | Every stabilization session produces a report |
+| Official suite is source of truth | Only `npx playwright test`, run with the project's real config and fixtures, determines a test's or a defect's status. Standalone diagnostic scripts provide complementary evidence only - never grounds to close a defect or flip a `test.fail()` |
 
 ---