@keber/qa-framework 1.5.2 → 1.6.2

package/agent-instructions/05-ado-integration.md

@@ -1,247 +0,0 @@
-# Agent Instructions: Azure DevOps Integration
-
-> ⚠️ **DEPRECATED**: This file is superseded by `.github/skills/qa-ado-integration/SKILL.md`.
-> Kept as reference during the transition period. Do not update this file.
-
-**File**: `agent-instructions/05-ado-integration.md`  
-**Purpose**: Instructions for an agent to create, configure, and maintain Azure DevOps Test Plans integration with Playwright automation results.
-
-> **This section is OPTIONAL**. Only use it when `integrations.azureDevOps.enabled = true` in `qa-framework.config.json`.
-
----
-
-## Prerequisites
-
-1. Azure DevOps PAT stored in `ADO_PAT` environment variable  
-   Required scopes: `Work Items (Read, Write)`, `Test Management (Read, Write)`
-2. `ADO_ORG` and `ADO_PROJECT` environment variables set
-3. PowerShell 5.1+ available
-4. `@alex_neo/playwright-azure-reporter` installed in the E2E package
-5. `qa/08-azure-integration/module-registry.json` exists with module paths and plan IDs
-
----
-
-## Step 1: Create ADO Test Plan
-
-If no Test Plan exists yet:
-
-```powershell
-# qa/08-azure-integration/scripts/create-testplan-from-mapping.ps1
-# Reads ado-ids-mapping-{project}.json and creates the plan + suites + TCs in ADO
-# Parameters: -Organization $env:ADO_ORG -Project $env:ADO_PROJECT -Token $env:ADO_PAT
-.\qa\08-azure-integration\scripts\create-testplan-from-mapping.ps1 `
-  -Organization $env:ADO_ORG `
-  -Project $env:ADO_PROJECT `
-  -Token $env:ADO_PAT `
-  -MappingFile .\qa\08-azure-integration\ado-ids-mapping-{project}.json
-```
-
-After running, the script outputs a `TestPlanId` and `SuiteIds`.  
-Record these in `qa/08-azure-integration/module-registry.json`.
-
----
-
-## Step 2: Inject ADO IDs into Spec Files
-
-Once Test Cases are created in ADO and have Work Item IDs:
-
-```powershell
-# Dry run first to preview changes
-.\qa\08-azure-integration\scripts\inject-ado-ids.ps1 `
-  -MappingFile .\qa\08-azure-integration\ado-ids-mapping-{project}.json `
-  -TestDir .\qa\07-automation\e2e\tests `
-  -DryRun
-
-# Apply changes
-.\qa\08-azure-integration\scripts\inject-ado-ids.ps1 `
-  -MappingFile .\qa\08-azure-integration\ado-ids-mapping-{project}.json `
-  -TestDir .\qa\07-automation\e2e\tests
-```
-
-This converts test titles from:
-```
-'[TC-OPER-CAT-001] Access catalog list @P0'
-```
-to:
-```
-'[22957] Access catalog list @P0'
-```
-
-Plus adds annotation:
-```typescript
-test.info().annotations.push({ type: 'TestCase', description: '22957' });
-```
-
----
-
-## Step 3: Configure playwright-azure-reporter
-
-In `playwright.config.ts`:
-
-```typescript
-import type { PlaywrightTestConfig } from '@playwright/test';
-
-const config: PlaywrightTestConfig = {
-  reporter: [
-    ['html'],
-    ['@alex_neo/playwright-azure-reporter', {
-      orgUrl: `https://dev.azure.com/${process.env.ADO_ORG}`,
-      token: process.env.ADO_PAT,
-      planId: Number(process.env.ADO_PLAN_ID),
-      projectName: process.env.ADO_PROJECT,
-      isDisabled: !process.env.CI,                    // only publish in CI
-      publishTestResultsMode: 'testRun',
-      testRunTitle: `QA Run - ${new Date().toISOString()}`,
-      uploadAttachments: true,
-      attachmentsType: ['screenshot', 'video', 'trace'],
-    }],
-  ],
-};
-export default config;
-```
-
-**Note**: Set `isDisabled: !process.env.CI` so the reporter only publishes from CI, not from local runs.
-
----
-
-## Step 4: Module Registry
-
-Maintain `qa/08-azure-integration/module-registry.json`:
-
-```json
-{
-  "modules": [
-    {
-      "name": "operacion",
-      "specsPath": "qa/07-automation/e2e/tests/operacion",
-      "planId": 0,
-      "suiteId": 0,
-      "description": "Módulo Operación — 7 submodules"
-    }
-  ]
-}
-```
-
-The CI pipeline uses this file to detect which module changed (via `git diff`) and run only the relevant spec.
-
----
-
-## Step 5: ADO IDs Mapping File
-
-Maintain `qa/08-azure-integration/ado-ids-mapping-{project}.json`:
-
-```json
-{
-  "planId": 22304,
-  "module": "operacion",
-  "specsPath": "qa/07-automation/e2e/tests/operacion",
-  "suites": [
-    {
-      "suiteId": 22956,
-      "suiteName": "Suite 1.1 - Catálogos de Trabajo",
-      "testCases": [
-        { "id": 22957, "title": "Access catalog list @P0", "tags": ["automatable", "playwright"] },
-        { "id": 22958, "title": "Create labor type @P1", "tags": ["automatable", "playwright"] }
-      ]
-    }
-  ]
-}
-```
-
----
-
-## Step 6: Configure CI Pipeline
-
-Template in `qa/08-azure-integration/pipelines/azure-pipeline-qa.yml`:
-
-```yaml
-trigger:
-  branches:
-    include:
-      - {{CI_TRIGGER_BRANCH}}
-
-pool:
-  vmImage: 'ubuntu-latest'
-
-variables:
-  - group: qa-secrets        # Must contain: QA_USER_EMAIL, QA_USER_PASSWORD, QA_BASE_URL, ADO_PAT
-
-steps:
-  - checkout: self
-    fetchDepth: 2
-
-  - task: NodeTool@0
-    inputs:
-      versionSpec: '20.x'
-    displayName: 'Install Node.js 20'
-
-  - script: |
-      cd qa/07-automation/e2e
-      npm install
-      npx playwright install chromium --with-deps
-    displayName: 'Install Playwright'
-
-  - script: |
-      cd qa/07-automation/e2e
-      npx playwright test
-    displayName: 'Run Playwright tests'
-    env:
-      QA_BASE_URL: $(QA_BASE_URL)
-      QA_USER_EMAIL: $(QA_USER_EMAIL)
-      QA_USER_PASSWORD: $(QA_USER_PASSWORD)
-      ADO_PAT: $(ADO_PAT)
-      ADO_PLAN_ID: $(ADO_PLAN_ID)
-      CI: 'true'
-
-  - task: PublishTestResults@2
-    inputs:
-      testResultsFormat: 'JUnit'
-      testResultsFiles: '**/test-results/*.xml'
-    displayName: 'Publish JUnit results'
-    condition: always()
-
-  - task: PublishPipelineArtifact@1
-    inputs:
-      targetPath: 'qa/07-automation/e2e/playwright-report'
-      artifact: 'playwright-html-report'
-    displayName: 'Publish HTML report'
-    condition: always()
-```
-
----
-
-## Syncing ADO TC Titles with Spec Titles
-
-If TC titles drift between ADO and the spec files:
-
-```powershell
-.\qa\08-azure-integration\scripts\sync-ado-titles.ps1 `
-  -Organization $env:ADO_ORG `
-  -Project $env:ADO_PROJECT `
-  -Token $env:ADO_PAT `
-  -MappingFile .\qa\08-azure-integration\ado-ids-mapping-{project}.json `
-  -DryRun
-```
-
-This reads ADO TC titles and compares them against the spec. Outputs a diff report. Apply with `-DryRun:$false`.
-
----
-
-## Credential Security Rules for ADO
-
-1. `ADO_PAT` is **never** committed to any file — always comes 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 and generate a new one
-4. Variable group `qa-secrets` in Azure DevOps must be scoped to the pipeline only
-5. PAT minimum scopes: `Work Items (Read, Write)`, `Test Management (Read, Write)` — do not use full access PATs
-
----
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-|---------|-------------|-----|
-| Reporter silently does nothing in CI | `isDisabled: true` or `CI` env not set | Verify `process.env.CI` is `'true'` in pipeline |
-| Tests report as "Not Run" in ADO | ADO WI ID not in test title or annotation | Re-run `inject-ado-ids.ps1` |
-| TestRun created but no results attached | `publishTestResultsMode` wrong | Use `'testRun'` not `'testCase'` |
-| PAT error 401 | PAT expired or wrong scopes | Generate new PAT with correct scopes |

package/agent-instructions/06-maintenance.md

@@ -1,135 +0,0 @@
-# Agent Instructions: Maintenance and Updates
-
-> ⚠️ **DEPRECATED**: This file is superseded by `.github/skills/qa-maintenance/SKILL.md`.
-> Kept as reference during the transition period. Do not update this file.
-
-**File**: `agent-instructions/06-maintenance.md`  
-**Purpose**: Instructions for updating QA artifacts after application code changes.
-
----
-
-## When to use
-
-- A developer reports a feature change or new feature in a module
-- A sprint delivers changes to an already-analyzed module
-- A defect is resolved and related `test.skip()` calls need to be reactivated
-- The QA environment is updated and existing specs need to be refreshed
-
----
-
-## Step 1: Identify What Changed
-
-Gather from the developer or ticket:
-- Which module/submodule was changed?
-- Was it a new feature, a modification, or a bug fix?
-- Are there new routes, fields, or API endpoints?
-- Were any existing behaviors removed or changed?
-
-If the change scope is unclear, navigate to the affected module in the QA environment and compare against the existing `00-inventory.md`.
-
----
-
-## Step 2: Spec Update Rules
-
-### A new field was added to a form
-
-1. Add the field to `00-inventory.md` under UI Elements table
-2. If the field has validation: add a business rule to `01-business-rules.md` (`RN-{MODULE}-{next-number}`)
-3. Add TCs to `05-test-scenarios.md`:
-   - TC for happy path with the new field
-   - TC for required validation (if applicable)
-   - TC for any new business rule
-
-### A field was removed from the UI
-
-1. Mark the field in `00-inventory.md` as `[REMOVED - {YYYY-MM-DD}]` — do not delete the row
-2. If automation tests reference the field selector: update or skip them
-3. If a business rule only applied to that field: mark as `[DEPRECATED - {YYYY-MM-DD}]`
-4. Leave TCs in `05-test-scenarios.md` marked as `[DEPRECATED]` for traceability
-
-### A workflow was changed
-
-1. Update `02-workflows.md` with the new flow
-2. Mark the old version as `[PREVIOUS - {YYYY-MM-DD}]`
-3. Review all TCs that test the affected steps
-4. Update expected results in `05-test-scenarios.md`
-
-### A new submodule was added
-
-Follow the full module analysis process in `00-module-analysis.md`.
-
-### A defect was fixed
-
-1. Find all `test.skip()` calls that reference the DEF-ID or ADO WI
-2. Remove the `test.skip()` wrapper
-3. Run the test at least 2 times with different EXEC_IDX values to confirm stability
-4. Update `06-defects/DEF-{NNN}.md` (or ADO WI) status to Resolved
-5. If the spec assertion was adapted to document the bug (e.g., `toBeFalsy()` for a wrong default), restore the correct assertion
-
----
-
-## Step 3: Automation Update Rules
-
-### Selectors changed (redesign, framework update)
-
-1. Locate the POM file or spec file that contains the old selector
-2. Check `CORRECTIONS` block at top of spec file (convention for documenting selector audits)
-3. Update the selector
-4. Run the affected test 2+ times to confirm the new selector is stable
-5. Add an entry to the `CORRECTIONS` block noting the change and date
-
-### New test suite needed
-
-Follow `04-automation-generation.md` for the new suite.  
-Update `COVERAGE-MAPPING.md` with the new TCs.
-
-### Test became flaky after app update
-
-Use the 5-layer debugging methodology:
-1. Environment: is QA env stable?
-2. Timeout: did an operation become slower?
-3. Data: did a seed or precondition change?
-4. Selector: did the element structure change?
-5. System: is this a real defect?
-
----
-
-## Step 4: Version the Spec
-
-At the bottom of each updated spec file, add to the changelog:
-
-```markdown
-## Changelog
-
-| Version | Date | Description |
-|---------|------|-------------|
-| 1.0 | YYYY-MM-DD | Initial creation |
-| 1.1 | YYYY-MM-DD | Added RN-{MODULE}-{NNN}: {rule title}. TC count: N → M |
-| 1.2 | YYYY-MM-DD | Removed field {name} from UI inventory (deprecated) |
-```
-
----
-
-## Step 5: Update qa/README.md
-
-After every maintenance session, update the master index:
-- TC count (if changed)
-- Automation status (if changed)
-- Last updated date for the module
-
-If a **sprint was fully completed** as part of this maintenance pass (all TCs passing after the changes):
-1. Move the completed sprint checklist from `AGENT-NEXT-STEPS.md` to the `## Sprint History` section of `qa/README.md`
-2. Delete the completed sprint block from `AGENT-NEXT-STEPS.md`
-3. Confirm `AGENT-NEXT-STEPS.md` contains **only one active sprint** — never let it accumulate history
-
-Also update `qa/memory/INDEX.md` if any memory files were created or modified.
-
----
-
-## Step 6: Write a Session Summary
-
-Create `qa/SESSION-SUMMARY-{YYYY-MM-DD}-maintenance.md` documenting:
-- What changed
-- Which files were updated
-- Any new TCs or deprecated TCs
-- Any tests that were reactivated or newly skipped

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.