qaa-agent 1.9.2 → 1.9.6

package/commands/qa-test-report.md

@@ -1,219 +1,254 @@
-# QA Test Report
-
-Generate a per-ticket QA execution summary and append it to the Azure DevOps work item's `Custom.QATestCasesReport` field. For each test case linked to the work item, pull the execution status from ADO Test Runs — or prompt the user when ADO has no run result — then render a bulleted "Tested Scenarios" list (with a separate "Failures" section when anything failed).
-
-## Usage
-
-```
-/qa-test-report <work-item-id>
-```
-
-### Arguments
-
-| Parameter | Purpose | Default |
-|-----------|---------|---------|
-| `<work-item-id>` | Azure DevOps work item ID (Bug, Feature, User Story, Ticket) whose linked test cases you want reported | Required — prompt the user if missing |
-
-## What It Produces
-
-- Markdown report printed to chat (for user review)
-- HTML report **appended** to the work item's `Custom.QATestCasesReport` field, separated from prior content by a blank line
-- No local file is written
-
----
-
-## Process
-
-### Phase 1 — Resolve the Work Item
-
-1. If `$ARGUMENTS` is empty or missing a work item ID, ask the user: *"Which Azure DevOps work item ID should I build the QA Test Cases report for?"* Wait for the answer before proceeding.
-2. Call `wit_get_work_item` with `expand: "relations"` for the resolved ID.
-   - Capture: **title**, **type** (`Bug`, `Feature`, `User Story`, `Ticket`), **state**, **area path**, **iteration path**.
-   - For context used in Phase 4, capture type-appropriate content fields:
-     - `Bug` / `Ticket`: **Repro Steps** (`Microsoft.VSTS.TCM.ReproSteps`), **System Info** (`Microsoft.VSTS.TCM.SystemInfo`), **Description**, **QA Notes** (`CIIScrum.QANotes`), **What is expected to happen** (`Custom.Whatisexpectedtohappen`), **What is actually happening** (`Custom.Whatisactuallyhappening`).
-     - `User Story`: **Acceptance Criteria** (`Microsoft.VSTS.Common.AcceptanceCriteria`), **Description**.
-     - `Feature`: **Description**, **Acceptance Criteria** if present.
-   - Note the project for all subsequent ADO calls.
-3. Also call `wit_list_work_item_comments` — comments often contain fail reasons or tester observations referenced in Phase 3 fallbacks.
-
----
-
-### Phase 2 — Resolve the Test Case List
-
-Source-resolution order:
-
-1. **Check for a local file** at `ai-tasks/ticket-{id}/test-cases.md` (produced by `/qa-create-test --ado`). If it exists, parse the TC IDs it contains — this is a hint list only.
-2. **Always query ADO** — inspect the relations returned in Phase 1, filter for link type `"Microsoft.VSTS.Common.TestedBy-Forward"` (*Tested By*), and build the authoritative list of linked TC IDs.
-3. **If both exist and disagree**: trust **ADO**. Log the discrepancy in chat as an FYI (e.g., `"TC#4521 was in local file but not linked in ADO — skipped"` or `"TC#4530 is linked in ADO but missing from local file — included"`) but proceed with the ADO list.
-4. **If no TCs are found in ADO** (and the local file has none either): print `"No test cases linked to work item #{id} — nothing to report."` and stop.
-
-For every TC ID in the final list, call `wit_get_work_item` with `expand: "relations"` to capture: **title**, **state**, **steps** (`Microsoft.VSTS.TCM.Steps`), **priority**, **tags**, and any linked runs.
-
----
-
-### Phase 3 — Resolve Execution Status Per Test Case
-
-For each TC, determine a status of **Passed**, **Failed**, or **Blocked** using this order.
-
-**Step 1 — Fetch Test Point outcomes via ADO REST (formal path).**
-
-The ADO MCP surface does not expose Test Point outcomes, but the REST API does. Use the same auth pattern as `/qa-create-test --ado`: the `ADO_MCP_AUTH_TOKEN` env var as a PAT, sent via Basic auth.
-
-1. Derive **org** and **project** from the work item context captured in Phase 1 (not hardcoded). The work-item URL / project name on the `wit_get_work_item` response gives you both.
-2. If `ADO_MCP_AUTH_TOKEN` is **not set**, skip directly to Step 2 (and note in the final report: *"Auto-status skipped — ADO_MCP_AUTH_TOKEN not set."*).
-3. Otherwise, call the Test Points REST endpoint once per run with the list of linked TC IDs:
-
-   ```bash
-   curl -s \
-     --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
-     --header "Content-Type: application/json" \
-     --request POST \
-     --data '{"pointsFilter":{"testcaseIds":[<id1>,<id2>,...]}}' \
-     "https://dev.azure.com/{org}/{project}/_apis/test/points?api-version=7.1"
-   ```
-
-4. Parse the response. For each returned point you get: `testCase.id`, `testPlan.id`, `suite.id`, `outcome`, `lastTestRun.id`, `lastResultDetails.dateCompleted`, `lastResultDetails.runBy`.
-5. **If a TC has multiple points** (e.g., it lives in several suites or runs on multiple configurations), pick the point with the **most recent `lastResultDetails.dateCompleted`**.
-6. Map `outcome` (case-insensitive) to our statuses:
-   - `passed` → **Passed**
-   - `failed` → **Failed**
-   - `blocked` → **Blocked**
-   - `notExecuted` / `none` / `notApplicable` / `paused` / `inProgress` / `warning` / `error` → treat as missing, fall through to Step 2 for this TC
-7. **If the call fails** (non-2xx, network error, token rejected): log the failure briefly in chat, skip to Step 2 for all TCs, and note in the final report that auto-status was unavailable.
-
-**Step 2 — Ask the user** (per TC that didn't resolve in Step 1). Show the TC ID and its synthesized scenario description (from Phase 4) for context:
-
-```
-TC #{id} — {scenario description}
-Status? [Passed / Failed / Blocked]
-```
-
-Accept case-insensitive input. Re-prompt if the answer is not one of the three.
-
-**Step 3 — If the resolved status is Failed**, capture a reason:
-
-1. Check the Test Run data first — when Step 1 returned an outcome, also fetch the Test Result for `lastTestRun.id` to read `errorMessage`/`comment`:
-   ```bash
-   curl -s \
-     --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
-     "https://dev.azure.com/{org}/{project}/_apis/test/Runs/{runId}/results?api-version=7.1"
-   ```
-   If the result has a non-empty `errorMessage` or `comment`, use that as the reason.
-2. Also check the TC's own comments (`wit_list_work_item_comments` for the TC ID) and the parent work item's comments for any line mentioning this TC.
-3. If no reason is found, ask the user:
-   ```
-   TC #{id} failed — what was the reason?
-   ```
-   Accept a free-text one-liner.
-
-Keep the per-TC answers (status, reason, and auto/manual source) in memory; do not write them anywhere intermediate.
-
----
-
-### Phase 4 — Synthesize Scenario Descriptions
-
-For each TC, produce a **readable one-line scenario description** for the bullet list. Do **not** copy the raw TC title when it is terse or cryptic — TC titles are often shorthand.
-
-Build the description from:
-- TC **title** (starting point)
-- TC **steps** (each step's action + expected result — gives you what was actually verified)
-- Parent work item **description / repro steps / acceptance criteria** (gives you the user-facing phrasing of *what should be true after the fix*)
-
-Write the description in the voice of the tested outcome, not the test action. Examples:
-
-| Raw TC title | Good scenario description |
-|---|---|
-| `Verify PH row display logic` | `$0 Previous Balance row no longer appears in Payment History` |
-| `Check login 401 scenario` | `Invalid credentials return a 401 with an error banner` |
-| `Regression: limit 100` | `Entry limit enforced at 100 — the 101st entry is rejected` |
-
-Keep bullets short — one line, past-tense or assertive present-tense, user-visible wording.
-
----
-
-### Phase 5 — Build the Report
-
-**Markdown version (for chat output):**
-
-```markdown
-Tested Scenarios
-
-- ✅ {scenario}
-- ✅ {scenario}
-- ❌ {scenario}
-- ⚠️ {scenario}
-
-Failures
-
-- ❌ {scenario}: {reason}
-```
-
-Rules:
-- Status emoji: **Passed → ✅**, **Failed → ❌**, **Blocked → ⚠️**
-- Include the `Failures` section **only if at least one TC failed**. One bullet per failure with the captured reason appended after `:`.
-- Do **not** include a "Result" section.
-- Do **not** include TC IDs, priority, tags, or counts in the bullets.
-- Keep order stable — preserve the order TCs appeared in the ADO linked list.
-
-**HTML version (for the ADO field):**
-
-Render with the minimum markup needed for ADO's rich-text field to display bullets and line breaks:
-
-```html
-<b>Tested Scenarios</b><br>
-<ul>
-  <li>✅ {scenario}</li>
-  <li>✅ {scenario}</li>
-  <li>❌ {scenario}</li>
-  <li>⚠️ {scenario}</li>
-</ul>
-<b>Failures</b><br>
-<ul>
-  <li>❌ {scenario}: {reason}</li>
-</ul>
-```
-
-Rules:
-- Escape scenario text for HTML (`&` → `&amp;`, `<` → `&lt;`, `>` → `&gt;`).
-- Emit the `<b>Failures</b>…` block **only if at least one TC failed**.
-- No inline styles, no classes, no wrapping `<div>`.
-
----
-
-### Phase 6 — Append to the ADO Field
-
-1. Re-read the current `Custom.QATestCasesReport` value for the work item (it may contain prior runs you must preserve).
-2. Build the new field value:
-   - If the existing value is empty or whitespace: new value = the HTML report from Phase 5.
-   - Otherwise: new value = existing content + `<br><br>` + the HTML report from Phase 5.
-3. Call `wit_update_work_item` setting `Custom.QATestCasesReport` to the new value. Pass only this field — do not include any others in the update.
-
-Do **not** overwrite other fields. Do **not** create a local file.
-
----
-
-### Phase 7 — Present to User
-
-Print the **markdown** version of the report to the user in chat. After the report, print a one-line confirmation:
-
-```
-Appended to work item #{id} → Custom.QATestCasesReport.
-```
-
-If any scenarios required a manual status answer or a manual failure reason during Phase 3, append a short note listing how many:
-
-```
-{n} status(es) entered manually · {m} failure reason(s) entered manually.
-```
-
-If the TC list had any local-vs-ADO discrepancies (Phase 2), append a short note listing them.
-
----
-
-## Notes
-
-- This skill does **not** create test cases. Use `/qa-create-test --ado <id>` for that.
-- This skill is read-mostly on the ADO side — it only writes to `Custom.QATestCasesReport`. It does not change TC state, does not create Test Runs, and does not modify links.
-- Scenario descriptions are synthesized, not verbatim TC titles — review the chat output before trusting the field content.
-
-$ARGUMENTS
+# QA Test Report
+
+Generate a per-ticket QA execution summary and append it to the Azure DevOps work item's `Custom.QATestCasesReport` field. For each test case linked to the work item, pull the execution status from ADO Test Runs — or prompt the user when ADO has no run result — then render a bulleted "Tested Scenarios" list (with a separate "Failures" section when anything failed).
+
+## ⚠ MANDATORY: How to Execute This Command
+
+Execute these steps IN ORDER. Every step is mandatory. Do NOT improvise,
+reorder, skip, or invent steps. This command reads Azure DevOps and writes ONLY
+the `Custom.QATestCasesReport` field; it spawns no sub-agents and creates no
+test cases.
+
+1. PHASE 1 — Resolve the work item: if `$ARGUMENTS` has no work item ID, ask the
+   user before proceeding. Fetch it with `wit_get_work_item` (relations) plus
+   its comments.
+2. PHASE 2 — Resolve the test-case list. ADO is authoritative: build the list
+   from the *Tested By* links; a local `test-cases.md` is only a hint. If no TCs
+   are linked, print "nothing to report" and STOP.
+3. PHASE 3 — Resolve each TC's status (Passed/Failed/Blocked): try the ADO Test
+   Points REST endpoint first; for any TC that doesn't resolve, ask the user. For
+   Failed TCs, capture a reason (run data → comments → ask the user).
+4. PHASE 4 — Synthesize a readable one-line scenario description per TC (not the
+   raw TC title).
+5. PHASE 5 — Build BOTH the markdown (for chat) and HTML (for the field) reports.
+   Include the Failures section only if something failed.
+6. PHASE 6 — APPEND the HTML report to `Custom.QATestCasesReport`: re-read the
+   current value and preserve it (existing + `<br><br>` + new). Update ONLY that
+   field — never overwrite others.
+7. PHASE 7 — Print the markdown report + the append confirmation to the user.
+
+### DO NOT
+- OVERWRITE `Custom.QATestCasesReport` — always append, preserving prior content
+- Write to any field other than `Custom.QATestCasesReport`
+- Create test cases, change TC state, or create Test Runs (this command is read-mostly)
+- Copy raw TC titles as scenario descriptions when they are terse
+- Invent steps not in this command, or reorder the phases
+
+If you find yourself overwriting the field, touching other fields, or creating or
+modifying test cases — STOP and restart from step 1.
+
+## Usage
+
+```
+/qa-test-report <work-item-id>
+```
+
+### Arguments
+
+| Parameter | Purpose | Default |
+|-----------|---------|---------|
+| `<work-item-id>` | Azure DevOps work item ID (Bug, Feature, User Story, Ticket) whose linked test cases you want reported | Required — prompt the user if missing |
+
+## What It Produces
+
+- Markdown report printed to chat (for user review)
+- HTML report **appended** to the work item's `Custom.QATestCasesReport` field, separated from prior content by a blank line
+- No local file is written
+
+---
+
+## Process
+
+### Phase 1 — Resolve the Work Item
+
+1. If `$ARGUMENTS` is empty or missing a work item ID, ask the user: *"Which Azure DevOps work item ID should I build the QA Test Cases report for?"* Wait for the answer before proceeding.
+2. Call `wit_get_work_item` with `expand: "relations"` for the resolved ID.
+   - Capture: **title**, **type** (`Bug`, `Feature`, `User Story`, `Ticket`), **state**, **area path**, **iteration path**.
+   - For context used in Phase 4, capture type-appropriate content fields:
+     - `Bug` / `Ticket`: **Repro Steps** (`Microsoft.VSTS.TCM.ReproSteps`), **System Info** (`Microsoft.VSTS.TCM.SystemInfo`), **Description**, **QA Notes** (`CIIScrum.QANotes`), **What is expected to happen** (`Custom.Whatisexpectedtohappen`), **What is actually happening** (`Custom.Whatisactuallyhappening`).
+     - `User Story`: **Acceptance Criteria** (`Microsoft.VSTS.Common.AcceptanceCriteria`), **Description**.
+     - `Feature`: **Description**, **Acceptance Criteria** if present.
+   - Note the project for all subsequent ADO calls.
+3. Also call `wit_list_work_item_comments` — comments often contain fail reasons or tester observations referenced in Phase 3 fallbacks.
+
+---
+
+### Phase 2 — Resolve the Test Case List
+
+Source-resolution order:
+
+1. **Check for a local file** at `ai-tasks/ticket-{id}/test-cases.md` (produced by `/qa-create-test --ado`). If it exists, parse the TC IDs it contains — this is a hint list only.
+2. **Always query ADO** — inspect the relations returned in Phase 1, filter for link type `"Microsoft.VSTS.Common.TestedBy-Forward"` (*Tested By*), and build the authoritative list of linked TC IDs.
+3. **If both exist and disagree**: trust **ADO**. Log the discrepancy in chat as an FYI (e.g., `"TC#4521 was in local file but not linked in ADO — skipped"` or `"TC#4530 is linked in ADO but missing from local file — included"`) but proceed with the ADO list.
+4. **If no TCs are found in ADO** (and the local file has none either): print `"No test cases linked to work item #{id} — nothing to report."` and stop.
+
+For every TC ID in the final list, call `wit_get_work_item` with `expand: "relations"` to capture: **title**, **state**, **steps** (`Microsoft.VSTS.TCM.Steps`), **priority**, **tags**, and any linked runs.
+
+---
+
+### Phase 3 — Resolve Execution Status Per Test Case
+
+For each TC, determine a status of **Passed**, **Failed**, or **Blocked** using this order.
+
+**Step 1 — Fetch Test Point outcomes via ADO REST (formal path).**
+
+The ADO MCP surface does not expose Test Point outcomes, but the REST API does. Use the same auth pattern as `/qa-create-test --ado`: the `ADO_MCP_AUTH_TOKEN` env var as a PAT, sent via Basic auth.
+
+1. Derive **org** and **project** from the work item context captured in Phase 1 (not hardcoded). The work-item URL / project name on the `wit_get_work_item` response gives you both.
+2. If `ADO_MCP_AUTH_TOKEN` is **not set**, skip directly to Step 2 (and note in the final report: *"Auto-status skipped — ADO_MCP_AUTH_TOKEN not set."*).
+3. Otherwise, call the Test Points REST endpoint once per run with the list of linked TC IDs:
+
+   ```bash
+   curl -s \
+     --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
+     --header "Content-Type: application/json" \
+     --request POST \
+     --data '{"pointsFilter":{"testcaseIds":[<id1>,<id2>,...]}}' \
+     "https://dev.azure.com/{org}/{project}/_apis/test/points?api-version=7.1"
+   ```
+
+4. Parse the response. For each returned point you get: `testCase.id`, `testPlan.id`, `suite.id`, `outcome`, `lastTestRun.id`, `lastResultDetails.dateCompleted`, `lastResultDetails.runBy`.
+5. **If a TC has multiple points** (e.g., it lives in several suites or runs on multiple configurations), pick the point with the **most recent `lastResultDetails.dateCompleted`**.
+6. Map `outcome` (case-insensitive) to our statuses:
+   - `passed` → **Passed**
+   - `failed` → **Failed**
+   - `blocked` → **Blocked**
+   - `notExecuted` / `none` / `notApplicable` / `paused` / `inProgress` / `warning` / `error` → treat as missing, fall through to Step 2 for this TC
+7. **If the call fails** (non-2xx, network error, token rejected): log the failure briefly in chat, skip to Step 2 for all TCs, and note in the final report that auto-status was unavailable.
+
+**Step 2 — Ask the user** (per TC that didn't resolve in Step 1). Show the TC ID and its synthesized scenario description (from Phase 4) for context:
+
+```
+TC #{id} — {scenario description}
+Status? [Passed / Failed / Blocked]
+```
+
+Accept case-insensitive input. Re-prompt if the answer is not one of the three.
+
+**Step 3 — If the resolved status is Failed**, capture a reason:
+
+1. Check the Test Run data first — when Step 1 returned an outcome, also fetch the Test Result for `lastTestRun.id` to read `errorMessage`/`comment`:
+   ```bash
+   curl -s \
+     --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
+     "https://dev.azure.com/{org}/{project}/_apis/test/Runs/{runId}/results?api-version=7.1"
+   ```
+   If the result has a non-empty `errorMessage` or `comment`, use that as the reason.
+2. Also check the TC's own comments (`wit_list_work_item_comments` for the TC ID) and the parent work item's comments for any line mentioning this TC.
+3. If no reason is found, ask the user:
+   ```
+   TC #{id} failed — what was the reason?
+   ```
+   Accept a free-text one-liner.
+
+Keep the per-TC answers (status, reason, and auto/manual source) in memory; do not write them anywhere intermediate.
+
+---
+
+### Phase 4 — Synthesize Scenario Descriptions
+
+For each TC, produce a **readable one-line scenario description** for the bullet list. Do **not** copy the raw TC title when it is terse or cryptic — TC titles are often shorthand.
+
+Build the description from:
+- TC **title** (starting point)
+- TC **steps** (each step's action + expected result — gives you what was actually verified)
+- Parent work item **description / repro steps / acceptance criteria** (gives you the user-facing phrasing of *what should be true after the fix*)
+
+Write the description in the voice of the tested outcome, not the test action. Examples:
+
+| Raw TC title | Good scenario description |
+|---|---|
+| `Verify PH row display logic` | `$0 Previous Balance row no longer appears in Payment History` |
+| `Check login 401 scenario` | `Invalid credentials return a 401 with an error banner` |
+| `Regression: limit 100` | `Entry limit enforced at 100 — the 101st entry is rejected` |
+
+Keep bullets short — one line, past-tense or assertive present-tense, user-visible wording.
+
+---
+
+### Phase 5 — Build the Report
+
+**Markdown version (for chat output):**
+
+```markdown
+Tested Scenarios
+
+- ✅ {scenario}
+- ✅ {scenario}
+- ❌ {scenario}
+- ⚠️ {scenario}
+
+Failures
+
+- ❌ {scenario}: {reason}
+```
+
+Rules:
+- Status emoji: **Passed → ✅**, **Failed → ❌**, **Blocked → ⚠️**
+- Include the `Failures` section **only if at least one TC failed**. One bullet per failure with the captured reason appended after `:`.
+- Do **not** include a "Result" section.
+- Do **not** include TC IDs, priority, tags, or counts in the bullets.
+- Keep order stable — preserve the order TCs appeared in the ADO linked list.
+
+**HTML version (for the ADO field):**
+
+Render with the minimum markup needed for ADO's rich-text field to display bullets and line breaks:
+
+```html
+<b>Tested Scenarios</b><br>
+<ul>
+  <li>✅ {scenario}</li>
+  <li>✅ {scenario}</li>
+  <li>❌ {scenario}</li>
+  <li>⚠️ {scenario}</li>
+</ul>
+<b>Failures</b><br>
+<ul>
+  <li>❌ {scenario}: {reason}</li>
+</ul>
+```
+
+Rules:
+- Escape scenario text for HTML (`&` → `&amp;`, `<` → `&lt;`, `>` → `&gt;`).
+- Emit the `<b>Failures</b>…` block **only if at least one TC failed**.
+- No inline styles, no classes, no wrapping `<div>`.
+
+---
+
+### Phase 6 — Append to the ADO Field
+
+1. Re-read the current `Custom.QATestCasesReport` value for the work item (it may contain prior runs you must preserve).
+2. Build the new field value:
+   - If the existing value is empty or whitespace: new value = the HTML report from Phase 5.
+   - Otherwise: new value = existing content + `<br><br>` + the HTML report from Phase 5.
+3. Call `wit_update_work_item` setting `Custom.QATestCasesReport` to the new value. Pass only this field — do not include any others in the update.
+
+Do **not** overwrite other fields. Do **not** create a local file.
+
+---
+
+### Phase 7 — Present to User
+
+Print the **markdown** version of the report to the user in chat. After the report, print a one-line confirmation:
+
+```
+Appended to work item #{id} → Custom.QATestCasesReport.
+```
+
+If any scenarios required a manual status answer or a manual failure reason during Phase 3, append a short note listing how many:
+
+```
+{n} status(es) entered manually · {m} failure reason(s) entered manually.
+```
+
+If the TC list had any local-vs-ADO discrepancies (Phase 2), append a short note listing them.
+
+---
+
+## Notes
+
+- This skill does **not** create test cases. Use `/qa-create-test --ado <id>` for that.
+- This skill is read-mostly on the ADO side — it only writes to `Custom.QATestCasesReport`. It does not change TC state, does not create Test Runs, and does not modify links.
+- Scenario descriptions are synthesized, not verbatim TC titles — review the chat output before trusting the field content.
+
+$ARGUMENTS

package/commands/qa-testid.md

@@ -2,6 +2,37 @@
 
 Scan frontend source code, audit missing data-testid attributes, and inject them following the naming convention in CLAUDE.md. Creates a separate branch for the changes.
 
+## ⚠ MANDATORY: How to Execute This Command
+
+Execute these steps IN ORDER. Every step is mandatory. Do NOT improvise,
+reorder, skip, or invent steps.
+
+1. Read `CLAUDE.md` — the data-testid Convention section — before anything else.
+2. Execute `workflows/qa-testid.md` end-to-end, in order, without skipping steps.
+3. Preserve ALL workflow gates. In particular, do NOT bypass:
+   - **Framework detection** (workflow Step 2, `detect_frontend`): if no frontend
+     directory, no framework, or no component files are found, STOP with the
+     workflow's error — do NOT proceed to injection.
+   - **Audit checkpoint / user approval** (workflow Step 4, CHECKPOINT phase):
+     the testid-injector MUST present TESTID_AUDIT_REPORT.md and wait for the
+     user to approve proposed values BEFORE injecting. Do NOT inject without it.
+   - **Branch creation** (workflow Step 4 INJECT phase / Step 5,
+     `create_branch_and_commit`): injection happens ONLY on the separate branch
+     `qa/testid-inject-{YYYY-MM-DD}` — never on the working branch.
+4. Spawn the scanner and testid-injector via Task() with their
+   `<critical_directive>` blocks, as the workflow specifies — do NOT do the
+   scan/audit/injection inline.
+
+### DO NOT
+- Inject any data-testid before the user approves the audit report
+- Modify source files on the working branch (injection is branch-isolated)
+- Change application logic — only add data-testid attributes
+- Skip framework detection or proceed when it reports no frontend
+- Invent steps not in the workflow, or reorder them
+
+If you find yourself injecting before approval, working off-branch, or skipping
+the framework-detection gate — STOP and restart from step 1.
+
 ## Usage
 
 /qa-testid [<source-directory>]

package/frameworks/cypress.json

@@ -0,0 +1,54 @@
+{
+  "name": "cypress",
+  "display_name": "Cypress",
+  "languages": [
+    "typescript",
+    "javascript"
+  ],
+  "extensions": [
+    ".cy.ts",
+    ".cy.js"
+  ],
+  "detection": {
+    "manifest_files": [
+      "package.json"
+    ],
+    "manifest_grep": "\"cypress\"",
+    "config_files": [
+      "cypress.config.ts",
+      "cypress.config.js"
+    ],
+    "file_patterns": [
+      "cypress/**/*.cy.ts",
+      "cypress/**/*.cy.js"
+    ]
+  },
+  "validation_commands": {
+    "syntax_check_ts": "tsc --noEmit",
+    "syntax_check_js": "node --check {file}",
+    "dry_run": "npx cypress verify",
+    "lint": "eslint {file}"
+  },
+  "conventions": {
+    "test_dirs": [
+      "cypress/e2e/",
+      "cypress/integration/"
+    ],
+    "pom_dirs": [
+      "cypress/support/page-objects/",
+      "cypress/pages/"
+    ],
+    "fixture_dirs": [
+      "cypress/fixtures/"
+    ],
+    "config_filename": "cypress.config.ts"
+  },
+  "context7_keys": [
+    "cypress",
+    "cypress-io"
+  ],
+  "test_kinds": [
+    "e2e",
+    "component"
+  ]
+}

package/frameworks/jest.json

@@ -0,0 +1,59 @@
+{
+  "name": "jest",
+  "display_name": "Jest",
+  "languages": [
+    "javascript",
+    "typescript"
+  ],
+  "extensions": [
+    ".test.js",
+    ".test.ts",
+    ".spec.js",
+    ".spec.ts"
+  ],
+  "detection": {
+    "manifest_files": [
+      "package.json"
+    ],
+    "manifest_grep": "\"jest\"",
+    "config_files": [
+      "jest.config.ts",
+      "jest.config.js",
+      "jest.config.cjs",
+      "jest.config.mjs"
+    ],
+    "file_patterns": [
+      "**/*.test.js",
+      "**/*.test.ts",
+      "__tests__/**/*",
+      "tests/**/*.test.*"
+    ]
+  },
+  "validation_commands": {
+    "syntax_check_ts": "tsc --noEmit",
+    "syntax_check_js": "node --check {file}",
+    "dry_run": "jest --listTests",
+    "lint": "eslint {file}"
+  },
+  "conventions": {
+    "test_dirs": [
+      "__tests__/",
+      "tests/",
+      "src/__tests__/"
+    ],
+    "pom_dirs": [],
+    "fixture_dirs": [
+      "__fixtures__/",
+      "tests/fixtures/"
+    ],
+    "config_filename": "jest.config.ts"
+  },
+  "context7_keys": [
+    "jest",
+    "facebook/jest"
+  ],
+  "test_kinds": [
+    "unit",
+    "integration"
+  ]
+}