@keber/qa-framework 1.5.1 → 1.6.1

package/docs/comparison-matrix.md

@@ -1,131 +0,0 @@
-# docs/comparison-matrix.md
-
-**Phase 1 Artifact** — Source: analysis of two embedded QA implementations.
-
-> **Note**: This document covers the comparative inventory of Repo A (`redacted-repo-web`) and Repo B (`redacted-repo`). It was the primary input for Phase 2 (classification) and Phase 3 (framework design).
-
----
-
-## Repository Profiles
-
-| Attribute | Repo A (`redacted-repo-web`) | Repo B (`redacted-repo`) |
-|---|---|---|
-| **Application stack** | ASP.NET MVC 5 + Web API 2 + SQL Server | Blazor WebAssembly + .NET + Radzen |
-| **UI component library** | jQuery, Select2, toastr, SweetAlert2, Metronic | Radzen Blazor components |
-| **Authentication** | Form login: RUT + password, `/Seguridad/Login` | Form login: email + password, Blazor identity |
-| **QA environment URL** | `https://redactedURL.com` | `https://redactedURL.com` |
-| **Modules documented** | 1 module (RCL Colación Fría), 7 submodules | 4 modules (Personas, Operación, Sistema, Reportes), 17+ submodules |
-| **Test cases documented** | ~160 TCs across 7 submodules | ~894 TCs across 17+ submodules |
-| **ADO integration level** | Partial (Wiki tools, Plan IDs referenced) | Full (pipeline, reporter, inject-ado-ids.ps1, module-registry.json) |
-| **Playwright suite** | Yes (Sprint 40: 26 P0 tests, 24 pass/2 skip) | Yes (67 automated, 53 pass/2 fail/12 skip) |
-| **Standards folder** | No (`00-standards/` not present) | Yes (naming-conventions, bug-template, TC-template, test-data-guidelines) |
-| **Session retrospectives** | Yes (06-defects used, 2 defects filed) | Extensive (SESSION-SUMMARY-* files at qa root) |
-| **08-azure-integration** | Not present | Fully implemented |
-
----
-
-## Item-by-Item Comparison Matrix
-
-| Item | Repo A | Repo B | Common? | Different? | Generalizable? | Needs Param? | Out of Framework? |
-|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| **8-folder qa/ structure (00–08)** | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
-| **6-file submodule template** | ✅ | ✅ | ✅ | Minor | ✅ | ❌ | ❌ |
-| `00-inventory.md` | ✅ | ✅ | ✅ | ❌ | ✅ | Module code | ❌ |
-| `01-business-rules.md` | ✅ (RN-* IDs) | ✅ (RN-* IDs) | ✅ | ❌ | ✅ | Module code | ❌ |
-| `02-workflows.md` (FL-* IDs) | ✅ | ✅ | ✅ | ❌ | ✅ | Module code | ❌ |
-| `03-roles-permissions.md` | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
-| `04-test-data.md` | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
-| `05-test-scenarios.md` (TC-* IDs) | ✅ | ✅ | ✅ | ❌ | ✅ | Module code | ❌ |
-| **Agent instructions: module analysis** | ✅ (766 lines) | ✅ (834 lines) | ✅ | Minor | ✅ | Project URL | ❌ |
-| **Agent instructions: E2E generation** | ✅ (Sprint-specific) | ❌ | ❌ | Major | ✅ (extract pattern) | Module scope | ❌ |
-| **ADO integration instructions** | ❌ | ✅ (AGENT-ADO-INTEGRATION.md) | ❌ | — | ✅ | Org/Project/IDs | ❌ |
-| **QA Structure Guide** | ✅ (994 lines) | ✅ (1018 lines) | ✅ | Minor wording | ✅ | ❌ | ❌ |
-| **00-standards/ folder** | ❌ | ✅ | ❌ | — | ✅ (adopt from B) | ❌ | ❌ |
-| **Naming conventions doc** | Embedded in structure guide | Standalone doc | Partial | Yes | ✅ | Module codes | ❌ |
-| **Bug report template** | ❌ | ✅ | ❌ | — | ✅ | ❌ | ❌ |
-| **Test case template** | ❌ | ✅ | ❌ | — | ✅ | ❌ | ❌ |
-| **Test data guidelines** | ❌ | ✅ | ❌ | — | ✅ | Env var names | ❌ |
-| **session-summary.md pattern** | ❌ | ✅ (2 examples) | ❌ | — | ✅ | ❌ | ❌ |
-| **Multi-role globalSetup (Playwright)** | ✅ (3 roles, sequential) | ✅ (1 role, single) | ✅ (pattern) | Parameters | ✅ | Role count, selectors | ❌ |
-| **storageState auth reuse** | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
-| **EXEC_IDX / RUN_SLOT date pattern** | ✅ | ❌ (uses Date.now() only) | ❌ | Major | ✅ (adopt from A) | ❌ | ❌ |
-| **3-layer email validation strategy** | ✅ | ❌ | ❌ | — | ✅ (domain-agnostic) | ❌ | Optional |
-| **playwright-azure-reporter** | ❌ | ✅ | ❌ | — | ✅ | planId, suiteId | Optional |
-| **inject-ado-ids.ps1** | ❌ | ✅ | ❌ | — | ✅ | ❌ | Optional |
-| **ADO pipeline (azure-pipeline-qa.yml)** | ❌ | ✅ (367 lines) | ❌ | — | ✅ | Org, project, branch | Optional |
-| **module-registry.json** | ❌ | ✅ | ❌ | — | ✅ | Module paths/IDs | Optional |
-| **ado-ids-mapping.json** | ❌ | ✅ | ❌ | — | ✅ | All IDs | Optional |
-| **Debug artifact policy** | ❌ | ✅ (DEBUG-ARTIFACTS-POLICY.md) | ❌ | — | ✅ | ❌ | ❌ |
-| **UI as source of truth principle** | Implied | ✅ (UI_COMO_FUENTE_DE_VERDAD.md) | ✅ (implicit) | Documentation | ✅ | ❌ | ❌ |
-| **TC origin classification** | ❌ | ✅ (UI-OBSERVADO/PENDIENTE-CODE/BLOQUEADO-PERMISOS) | ❌ | — | ✅ | ❌ | ❌ |
-| **BLAZOR_WASM_AUTOMATION.md** | ❌ | ✅ | ❌ | — | Partial | UI library | Optional |
-| **RADZEN_COMPONENTS_PLAYWRIGHT.md** | ❌ | ✅ | ❌ | — | Partial | UI library | Optional (Blazor adapter) |
-| **DB schema documentation pattern** | ✅ (Mermaid ER) | ❌ | ❌ | — | ✅ (pattern only) | DB naming | Optional |
-| **Correctness criteria** | ✅ (≥2 passes with different EXEC_IDX) | ❌ | ❌ | — | ✅ | ❌ | ❌ |
-| **5-layer debugging methodology** | ✅ | ❌ | ❌ | — | ✅ | ❌ | ❌ |
-| **Page Object Model (POM) pattern** | ✅ (4 POMs) | Inline (no POMs) | Partial | Approach | ✅ (recommend POMs) | ❌ | ❌ |
-| **06-defects/ directory** | ✅ (2 active DEFs used) | ✅ (folder only, no active DEFs) | ✅ | Usage | Conditional | ❌ | Optional |
-| **Seed specs pattern** | ❌ | ✅ (seeds/*.spec.ts excluded from runs) | ❌ | — | ✅ | ❌ | Optional |
-| **automation-feasibility-analysis.md** | ❌ | ✅ | ❌ | — | ✅ | ❌ | ❌ |
-| **Coverage mapping (COVERAGE-MAPPING.md)** | ❌ | ✅ | ❌ | — | ✅ | ADO IDs | Optional |
-| **Project-specific URLs** | ✅ (redacted) | ✅ (redacted) | Both | Different | ❌ (parameterize) | QA_BASE_URL | ❌ |
-| **ADO org / project names** | redacted-organization / redacted-project | redacted-organization / redacted-project | Org same | Project different | ❌ (parameterize) | ADO_ORG, ADO_PROJECT | ❌ |
-| **Login selectors** | `#m_login_signin_submit` (Metronic) | `#email-input`, `#password-input` (Blazor) | Different | Major | ❌ (parameterize) | LOGIN_EMAIL_SELECTOR, etc. | ❌ |
-| **Application-specific form selectors** | `#tbl_redacted`, `#redacted` | `.rz-data-row`, `input.rz-textbox` | None | Major | ❌ | ❌ | Yes (project adapters) |
-| **Test user DNIs / real personal data** | DNIs in test-data.ts, personas.md | None (uses env vars) | None | Major | ❌ | ❌ | Yes (project data) |
-| **Module-specific business data** | redacted | redacted | None | Major | ❌ | ❌ | Yes (project data) |
-| **Sprint references** | redacted sprint | No sprints (session-based) | None | Different | ❌ | ❌ | Yes (project context) |
-| **Developer names** | redacted names | None | None | — | ❌ | ❌ | Yes (project context) |
-| **Internal SOAP email service** | EnvioMailSoapClient | None | None | — | ❌ | ❌ | Yes |
-
----
-
-## Summary Counts
-
-| Category | Count |
-|---|---|
-| Items common to both repos | 14 |
-| Items only in Repo A, generalizable | 8 |
-| Items only in Repo B, generalizable | 16 |
-| Items that need parameterization | 12 |
-| Items that are purely project-specific (out of framework) | 10+ |
-| Optional/plugin items | 9 |
-
----
-
-## Key Differences That Create Design Tensions
-
-### 1. Login credential type: RUT vs email
-
-- Repo A uses RUT (Chilean national ID) as username
-- Repo B uses email as username
-- **Resolution**: Parameterize via `QA_USER_EMAIL` and `QA_USER_PASSWORD` env vars; the login selector set is a project config parameter in `qa-framework.config.json`
-
-### 2. Single-role vs multi-role globalSetup
-
-- Repo A: 3 roles (solicitante, encargado, admin) saved sequentially to `.auth/{role}.json`
-- Repo B: 1 role saved to `.auth/session.json`
-- **Resolution**: Scaffold supports both. Config parameter `testUsers[]` drives how many roles are set up. Template defaults to single-role; multi-role is documented as an extension.
-
-### 3. ADO integration depth
-
-- Repo A: ADO IDs referenced in comments; no pipeline or reporter
-- Repo B: Full pipeline, playwright-azure-reporter, inject-ado-ids.ps1, module-registry.json
-- **Resolution**: ADO integration is a fully optional plugin (`integrations/ado-powershell/`). The framework core does not require it.
-
-### 4. Standards folder
-
-- Repo B has a mature `00-standards/` folder absent from Repo A
-- **Resolution**: Adopt the standards from Repo B as the framework baseline, since they are the more complete and generalized set.
-
-### 5. `06-defects/` directory
-
-- Repo A: Used actively (2 bugs filed, test skips reference DEF-IDs)
-- Repo B: Folder exists but no active defect files
-- **Resolution**: See `docs/generalization-decisions.md` §7 for the full evaluation. Decision: **keep as optional, not required by framework core**.
-
-### 6. Test naming convention
-
-- Repo A: `[Nx] Title @Pp` (sprint-relative sequential numbering)
-- Repo B: `[ADO_ID] Title` (ADO Work Item ID prefix)
-- **Resolution**: Framework uses `[{ID}] {title} @{priority}` where `{ID}` defaults to a local TC-ID (e.g., TC-MOD-SUB-001) and is replaced with ADO WI ID when ADO integration is enabled.

package/docs/generalization-decisions.md

@@ -1,203 +0,0 @@
-# docs/generalization-decisions.md
-
-**Phase 2 Artifact** — Classification and decision log for every element found during discovery.
-
-Every decision in this document follows the format:
-
-> **Decision ID** | **Item** | **Source** | **Decision** | **Rationale** | **What was discarded**
-
----
-
-## §1 — 8-Folder QA Directory Structure
-
-- **Item**: Numbered folder hierarchy `00-guides/` through `08-azure-integration/`
-- **Source**: Both repos (identical structure)
-- **Decision**: ✅ **Framework core**
-- **Rationale**: Both repos independently converged on this same structure. It provides a clear, numbered namespace that agents can navigate predictably. The numbers prevent alphabetical re-ordering from breaking conventions.
-- **What was discarded**: Nothing. Structure adopted as-is.
-
----
-
-## §2 — 6-File Submodule Template Set
-
-- **Item**: `00-inventory.md` → `05-test-scenarios.md`
-- **Source**: Both repos (Repo B more consistently follows the pattern)
-- **Decision**: ✅ **Framework core** (reusable template)
-- **Rationale**: This is the most consistently-replicated pattern across both repos and the most clearly generalizable unit of work. Every submodule follows this structure regardless of domain.
-- **Naming difference**: Repo A names file 1 `01-business-rules.md`; Repo B sometimes uses `01-functional-analysis.md`. **Resolution**: Standardize as `01-business-rules.md`. Functional analysis is a technique to produce business rules, not the output itself.
-- **What was discarded**: `01-functional-analysis.md` naming variant.
-
----
-
-## §3 — Agent Instructions: Module Analysis
-
-- **Item**: `AGENT-INSTRUCTIONS-MODULE-ANALYSIS.md` — 766 lines (A), 834 lines (B)
-- **Source**: Both repos (conceptually identical, slightly different phrasings)
-- **Decision**: ✅ **Agent instructions** (generalized, project-specific refs removed)
-- **Rationale**: Both are 4-phase instructions (Prepare → Explore → Document → Review). The core process is identical. Project-specific items removed: hardcoded URLs, project names, session names.
-- **What was discarded**:
-  - Repo A: `https://redactedURL.com`, `redacted@mail.com`, `playwright-cli MCP tool reference`
-  - Repo B: `https://redactedURL.com`, `redacted-project` session name
-  - Replaced with: `{{QA_BASE_URL}}`, `{{QA_USER_EMAIL}}` placeholders
-- **Adopted from Repo B** (merged): TC origin classification (UI-OBSERVADO / PENDIENTE-CODE / BLOQUEADO-PERMISOS), 50–85 TC target per submodule, 3-condition TC validity rule (VISIBLE + ACCESIBLE + OBSERVABLE)
-
----
-
-## §4 — Agent Instructions: E2E Automation
-
-- **Item**: `AGENT-INSTRUCTIONS-E2E-PLAYWRIGHT-SPRINT40.md` (Repo A only)
-- **Source**: Repo A — sprint-specific, 961 lines
-- **Decision**: ✅ **Agent instructions** + **Optional integration** (heavily refactored)
-- **Rationale**: The document contains highly valuable generalizable patterns (multi-role auth, EXEC_IDX date strategy, 3-layer email validation, skip+DEF pattern, storageState) embedded within Sprint 40-specific content. The generalizable patterns were extracted; the sprint-specific content (task IDs, routes, form selectors) was discarded.
-- **What was discarded**: Azure Task IDs (20111, 21944–21949, 20528–20529), all `/RCL/`, `/Seguridad/` route references, all Sprint 40 test counts and scope, specific ADO Plan/Suite IDs.
-- **What was extracted**: The 18-section structure was collapsed into a generalized `04-automation-generation.md` agent instruction with parameterized sections.
-
----
-
-## §5 — Standards Folder (`00-standards/`)
-
-- **Item**: Naming conventions, bug template, TC template, test-data guidelines
-- **Source**: Repo B only
-- **Decision**: ✅ **Framework core** — adopt from Repo B as the baseline
-- **Rationale**: Repo B has a full and well-designed standards set absent from Repo A. These are fully generalizable with minor parameterization (module/submodule codes).
-- **What was discarded**:
-  - Repo B has `admin.qakeber.com` hardcoded in bug-report template and test-data guidelines. Replaced with `{{QA_ADMIN_EMAIL}}`.
-  - Module codes (AUTH, PERS, USER, AGRI, OPER, REP) were kept as example values in templates but removed from any "authoritative" list.
-
----
-
-## §6 — Playwright Integration
-
-- **Item**: `playwright.config.ts`, `global-setup.ts`, `.env.example`, `fixtures/auth.ts`, page objects, spec files
-- **Source**: Both repos
-- **Decision**: ✅ **Optional integration** (playwright adapter) + ✅ **Reusable templates** for config files
-- **Rationale**: Playwright is the automation framework of choice in both repos but must remain optional. Projects may use a different test runner (Jest, Cypress). The configuration patterns (storageState, globalSetup, testIgnore for seeds, CI vs local workers) are generalizable as templates.
-- **What was discarded**:
-  - All project-specific selectors (form fields, route paths, element IDs)
-  - All hardcoded URLs
-  - Sprint-specific npm scripts (`sprint40`, `sprint40:p0`)
-  - Application-specific form constants from `fixtures/test-data.ts`
-  - All page objects (too application-specific)
-- **What was templated**:
-  - `playwright.config.ts` — with `{{...}}` placeholders for baseURL, test path, ADO credentials
-  - `global-setup.ts` — generic login flow with configurable selectors
-  - `.env.example` — with all credential variables documented
-  - `fixtures/auth.ts` — generic multi-role fixture
-
----
-
-## §7 — `06-defects/` Directory
-
-**This is the evaluation specifically requested in the brief.**
-
-- **Item**: The `06-defects/` folder and its defect-tracking purpose
-- **Source**: Repo A (actively used: DEF-001, DEF-002), Repo B (folder exists, no files)
-- **Analysis**:
-
-  | Criteria | Finding |
-  |---|---|
-  | Is real value demonstrated? | Yes, in Repo A: DEF-* IDs are referenced from `test.skip()`, linking automation state to bug state. This provides traceability from failing test → known defect. |
-  | Is it redundant with ADO? | Partially. ADO Work Items serve the same purpose in organizations that use ADO. However, not all projects use ADO. |
-  | Is the format standardized? | No. In Repo A: freeform Markdown. Repo B has a bug-report template in `00-standards/`. |
-  | Does it create maintenance burden? | Yes, if not kept in sync with ADO. Two sources of truth for defects is a known anti-pattern. |
-
-- **Decision**: ✅ **Keep as optional** — not required by framework core, but recommended when:
-  1. ADO is not in use (lightweight alternative)
-  2. The project needs offline/local defect tracking during sprint stabilization
-  3. The team wants to document the `test.skip() → DEF-* → reactivation path` explicitly
-
-- **Recommended evolution**: When ADO is enabled, `06-defects/` becomes a cache/mirror of ADO bugs relevant to QA automation. The defect file links to the ADO WI, rather than replacing it.
-
-- **What would be removed**: If this folder is removed from a project, the `test.skip('DEF-XXX: ...')` convention should still be kept in spec files; the DEF ID should then reference the ADO WI ID directly.
-
----
-
-## §8 — Azure DevOps Integration
-
-- **Item**: Pipeline YAML, `playwright-azure-reporter`, PowerShell scripts, `module-registry.json`, `ado-ids-mapping.json`
-- **Source**: Repo B (fully implemented), Repo A (partial — referenced but not implemented)
-- **Decision**: ✅ **Optional integration** (ado-powershell adapter + playwright-azure-reporter adapter)
-- **Rationale**: ADO integration provides real value (E2E result sync with Test Plans, CI pipeline, WI ID injection) but creates a strong dependency on a specific vendor (Azure DevOps). The framework must work without it.
-- **What was kept**: The full set of scripts from Repo B — `inject-ado-ids.ps1`, `create-testplan-from-mapping.ps1`, `sync-ado-titles.ps1` — generalized by removing hardcoded org/project/ID values.
-- **What was parameterized**: `ADO_ORG`, `ADO_PROJECT`, `ADO_PAT`, `planId`, `suiteId`, variable group name.
-- **What was marked as stub**: The Repo B pipeline references a specific trigger branch (`keber.flores/qa-test/qa-specs`). This is replaced with a parameterized `{{CI_TRIGGER_BRANCH}}` in the template.
-
----
-
-## §9 — Blazor-Specific Automation Guides
-
-- **Item**: `BLAZOR_WASM_AUTOMATION.md`, `RADZEN_COMPONENTS_PLAYWRIGHT.md`, `RETROSPECTIVA_CASCADA_2026-02.md`
-- **Source**: Repo B only
-- **Decision**: ✅ **Optional integration** (blazor-radzen adapter) for reusable helper functions; ❌ **Out of framework** for retrospective
-- **Rationale**: The Blazor/Radzen automation patterns (`openDropdownAndSelectFirst()`, `toBeAttached()`, `waitForFunction()` for popup detection) are highly reusable across any Radzen Blazor project. However, they are not generic enough for the framework core. The retrospective is project-specific debug log.
-- **What was extracted**: `openDropdownAndSelectFirst()` function moved to `integrations/blazor-radzen/helpers.ts` (stub — marked as `ADAPTER`).
-- **What was discarded**: Retrospective content, specific route references in cascade-dropdown backtrack.
-
----
-
-## §10 — EXEC_IDX / RUN_SLOT Date Generation Pattern
-
-- **Item**: `Math.floor(Date.now() / 60_000) % 100_000` (EXEC_IDX), `Math.floor(Date.now()/300_000)` (RUN_SLOT)
-- **Source**: Repo A (primary), Repo B (uses raw `Date.now()` without the slot pattern)
-- **Decision**: ✅ **Framework core** (general convention, extracted to template)
-- **Rationale**: This pattern solves a real cross-project problem: parallel or repeated test runs creating data collisions. It avoids the need for test teardown and is independently applicable to any project with CRUD tests.
-- **Action**: Documented in `agent-instructions/04-automation-generation.md` as a required pattern for data-producing tests. Moved to `templates/automation-scaffold/fixtures/test-helpers.ts`.
-
----
-
-## §11 — Naming Convention: Test Titles
-
-- **Item**: Test title format — `[Nx] Title @Pp` (Repo A) vs `[ADO_ID] Title` (Repo B)
-- **Source**: Both repos, incompatible
-- **Decision**: ✅ **Framework core** (adopt unified convention)
-- **Unified convention**: `[{LOCAL_ID}] {title} @{priority}` — e.g. `[TC-OPER-CAT-001] Access catalog list @P0`
-- **When ADO is enabled**: Local ID is replaced with ADO WI ID by `inject-ado-ids.ps1`, becoming `[22957] Access catalog list @P0`
-- **Rationale**: The local ID format preserves traceability without requiring ADO. The ADO ID injection is an idempotent upgrade step, not a prerequisite.
-
----
-
-## §12 — Page Object Model (POM) vs Inline Automation
-
-- **Item**: POMs (Repo A) vs inline selector logic (Repo B)
-- **Source**: Repo A has 5 POMs; Repo B uses inline `page.locator()` calls in spec files
-- **Decision**: ✅ **Framework recommendation: use POMs** for production automation; inline is acceptable for exploratory scripts
-- **Rationale**: POMs provide selector encapsulation and reuse across suites. Repo A's approach led to smaller spec files and easier maintenance. Repo B's inline approach was faster to write but led to selector duplication. The framework templates use POMs, but the agent instruction notes that inline is acceptable for single-use diagnostic specs.
-
----
-
-## §13 — `SITEMAP_TERRAVIX_QA.md` / `ui-menu-map.md` Pattern
-
-- **Item**: Auto-generated application sitemap from a real Playwright session
-- **Source**: Both repos (Repo B: SITEMAP file, Repo A: auto-generated ui-menu-map.md)
-- **Decision**: ✅ **Reusable template** — the `ui-menu-map.spec.ts` script extracted and generalized
-- **Rationale**: Generating a live sitemap from a Playwright session is a highly valuable, universally applicable pattern. It provides the ground truth for module analysis and access-control testing.
-- **What was parameterized**: `BASE_URL` env var, output path in `qa/01-specifications/shared/ui-menu-map.md`.
-
----
-
-## §14 — Session Summary Pattern
-
-- **Item**: `SESSION-SUMMARY-YYYY-MM-DD.md` files at qa/ root (Repo B)
-- **Source**: Repo B only
-- **Decision**: ✅ **Reusable template**
-- **Rationale**: Provides a living log of what was produced in each QA working session. Useful for agent continuity (can resume from a known state) and for traceability.
-- **What was discarded**: Specific content (Personas module, 19 files created, etc.)
-
----
-
-## §15 — `06-defects/` vs ADO Work Items Decision Tree
-
-For completeness, here is the recommended decision tree:
-
-```
-Is Azure DevOps enabled in this project?
-├── YES → Use ADO Work Items for ALL defects.
-│         Keep 06-defects/ as a lightweight reference cache only.
-│         Each DEF-*.md file = summary + link to ADO WI URL.
-│         test.skip() references ADO WI ID, not DEF-ID.
-│
-└── NO  → Use 06-defects/ as the primary defect tracker.
-          Follow the bug-report-template.md format.
-          test.skip() references DEF-ID.
-          When ADO is enabled later: migrate IDs.
-```