qaa-agent 1.8.0 → 1.8.5

package/.mcp.json

@@ -3,6 +3,10 @@
     "playwright": {
       "command": "npx",
       "args": ["@playwright/mcp@latest"]
+    },
+    "context7": {
+      "command": "npx",
+      "args": ["-y", "@upstash/context7-mcp@latest"]
     }
   }
 }

package/CHANGELOG.md

@@ -3,6 +3,33 @@
 
 All notable changes to QAA (QA Automation Agent) are documented here.
 
+## [1.8.5] - 2026-04-17
+
+### Added
+
+- **Azure DevOps mode in `/qa-create-test`** — new `--ado` flag enables creating Test Cases directly in Azure DevOps from a work item. Supports work item ID or full ADO URL, auto-detects `dev.azure.com` and `*.visualstudio.com` URLs. Features include: boundary value triplet detection (N-1, N, N+1), deduplication against existing linked TCs, confidence scoring (Specified vs Draft), keyword-based Critical tagging, and preconditions block per test case.
+- **`/qa-create-test-ado` standalone command** — dedicated command for Azure DevOps test case creation with 7-phase workflow: retrieve work item with comments/attachments, dedup check, type-based content extraction (Bug → Repro Steps, User Story → Acceptance Criteria), test case design, creation in ADO via `testplan_create_test_case`, structured report generation, and report attachment to source work item.
+- **ADO-specific flags** — `--area-path`, `--iteration-path` (override paths for created TCs), `--skip-dedup` (skip deduplication check).
+
+### Changed
+
+- **`/qa-create-test` now supports 5 modes** — from-code, from-ticket, ADO, update, and POM-only (previously 3 modes). Mode detection updated to recognize ADO URLs before ticket URLs to avoid routing conflicts.
+
+## [1.8.1] - 2026-04-16
+
+### Added
+
+- **Context7 MCP integration** — `@upstash/context7-mcp` is now bundled alongside Playwright MCP. The installer registers both MCP servers in the user-scope config (`~/.claude.json`) so they're available in every project on the machine, not just in the QAA repo. Context7 gives every QAA agent on-demand access to up-to-date library documentation (Playwright, Cypress, Jest, Vitest, pytest, and any other framework), keeping generated tests aligned with current APIs instead of outdated training data.
+- **`bin/install.cjs` installer script** — the file was referenced in `package.json` but didn't actually exist on npm, causing `npx qaa-agent` to fail silently (`No bin file found at bin/install.cjs`). The installer now performs three steps on every run: (1) copies agents, commands, skills, templates, workflows, docs, and config files into the chosen scope (`~/.claude/qaa` for global, `./.claude/qaa` for local), (2) registers both MCP servers in `~/.claude.json` with idempotency — existing entries are not duplicated, and (3) deep-merges the QAA permissions into the user's `settings.json` without overwriting their existing settings.
+
+### Changed
+
+- **MCP registration is now user-scope by default** — previously MCPs were defined only in the project-level `.mcp.json`, which meant they only activated when the user opened the QAA repo itself. They now register in `~/.claude.json`, making them available in every Claude Code project on the user's machine. The project-level `.mcp.json` is kept for QAA development purposes but is no longer the source of truth for end users.
+
+### Fixed
+
+- **Silent `npx qaa-agent` failure** — users who installed QAA via npm before this release did not get Playwright or Context7 MCPs registered because the installer script was missing from the published package. Publishing 1.8.1 restores the expected behavior: a single `npx qaa-agent` command copies all files and registers both MCPs globally.
+
 ## [1.8.0] - 2026-04-13
 
 ### Added

package/README.md

@@ -43,7 +43,9 @@ npx qaa-agent
 The interactive installer:
 
 1. Copies agents, commands, skills, templates, and workflows into your runtime directory
-2. Configures the [Playwright MCP](https://www.npmjs.com/package/@playwright/mcp) server in your user-scope config (`~/.claude.json`) so it's available in **all projects**
+2. Registers **two MCP servers** in your user-scope config (`~/.claude.json`) so they're available in **all projects**:
+   - [Playwright MCP](https://www.npmjs.com/package/@playwright/mcp) — live browser control for E2E tests and locator extraction
+   - [Context7 MCP](https://www.npmjs.com/package/@upstash/context7-mcp) — up-to-date library documentation on demand
 3. Merges required permissions into `settings.json`
 
 **Supported runtimes:** Claude Code, OpenCode
@@ -55,48 +57,34 @@ The interactive installer:
 - [Node.js](https://nodejs.org/) 18+
 - [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installed
 
-### Playwright MCP (required for E2E)
+### Bundled MCP servers
 
-QAA uses [`@playwright/mcp`](https://www.npmjs.com/package/@playwright/mcp) to open a real browser, extract locators from live pages, run E2E tests, and auto-fix locator mismatches.
+Both MCP servers are **registered automatically** in `~/.claude.json` when you run `npx qaa-agent`. No manual setup required — once installed, they're available in every Claude Code project on your machine.
 
-**You need to install the Playwright MCP server manually in your environment:**
+#### Playwright MCP — live browser control
 
-<details>
-<summary><strong>VS Code (Claude Code extension)</strong></summary>
+Uses [`@playwright/mcp`](https://www.npmjs.com/package/@playwright/mcp) to:
 
-1. Open VS Code Settings (`Ctrl+Shift+P` > `Preferences: Open User Settings (JSON)`)
-2. Add the MCP server config:
+- Open a real browser and navigate your running app
+- Extract actual locators (`data-testid`, ARIA roles, labels) from live pages
+- Run E2E tests, capture failures, and auto-fix locator mismatches
+- Build a persistent **Locator Registry** (`.qa-output/locators/`) that caches real locators across features
 
-```json
-{
-  "claude-code.mcpServers": {
-    "playwright": {
-      "command": "npx",
-      "args": ["@playwright/mcp@latest"]
-    }
-  }
-}
-```
+#### Context7 MCP — up-to-date library docs
 
-Or add it to your project's `.vscode/mcp.json`:
+Uses [`@upstash/context7-mcp`](https://www.npmjs.com/package/@upstash/context7-mcp) to:
 
-```json
-{
-  "servers": {
-    "playwright": {
-      "command": "npx",
-      "args": ["@playwright/mcp@latest"]
-    }
-  }
-}
-```
+- Fetch the latest documentation for Playwright, Cypress, Jest, Vitest, pytest, and any other library the agent is working with
+- Keep generated tests aligned with current framework APIs instead of outdated training data
+- Free tier: ~60 requests/hour, ~3,300 tokens/query
 
-</details>
+#### Verifying the MCPs are connected
 
-<details>
-<summary><strong>Claude Code CLI</strong></summary>
+Open Claude Code in any project and type `/mcp`. You should see both `playwright` and `context7` listed as connected.
 
-Add to `~/.claude.json` (user-scope, all projects):
+#### Manual config (fallback)
+
+If for any reason the automatic registration fails, you can add the servers manually to `~/.claude.json`:
 
 ```json
 {
@@ -104,21 +92,15 @@ Add to `~/.claude.json` (user-scope, all projects):
     "playwright": {
       "command": "npx",
       "args": ["@playwright/mcp@latest"]
+    },
+    "context7": {
+      "command": "npx",
+      "args": ["-y", "@upstash/context7-mcp@latest"]
     }
   }
 }
 ```
 
-Or add a `.mcp.json` file in your project root for project-scope only.
-
-</details>
-
-Once configured, Playwright MCP enables QAA to:
-- Open a real browser and navigate your running app
-- Extract actual locators (`data-testid`, ARIA roles, labels) from live pages
-- Run E2E tests, capture failures, and auto-fix locator mismatches
-- Build a persistent **Locator Registry** (`.qa-output/locators/`) that caches real locators across features
-
 ---
 
 ## Quick Start
@@ -328,7 +310,7 @@ qaa-agent/
   bin/             # Installer and CLI tools
   docs/            # User documentation
   CLAUDE.md        # QA standards (read by every agent)
-  .mcp.json        # Playwright MCP server config
+  .mcp.json        # Playwright + Context7 MCP server config
   settings.json    # Claude Code permissions
 ```
 

package/bin/install.cjs

@@ -0,0 +1,253 @@
+#!/usr/bin/env node
+
+/**
+ * QAA Agent Installer
+ *
+ * Installs QAA (QA Automation Agent) into the user's Claude Code environment.
+ *
+ * What it does:
+ *   1. Copies agents, commands, skills, templates, workflows, docs, bin, and config files
+ *      to the chosen install directory (global ~/.claude/qaa or local ./.claude/qaa)
+ *   2. Registers Playwright MCP and Context7 MCP as global MCP servers
+ *   3. Merges required permissions into Claude Code settings.json
+ *
+ * Usage:
+ *   npx qaa-agent
+ */
+
+const fs = require('fs');
+const path = require('path');
+const readline = require('readline');
+const { execSync } = require('child_process');
+
+// ── Helpers ──────────────────────────────────────────────────────────────────
+
+function log(msg) { console.log(`  ${msg}`); }
+function success(msg) { console.log(`  ✓ ${msg}`); }
+function warn(msg) { console.log(`  ⚠ ${msg}`); }
+function fail(msg) { console.error(`  ✗ ${msg}`); }
+
+function ask(question) {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise(resolve => {
+    rl.question(`  ${question} `, answer => {
+      rl.close();
+      resolve(answer.trim());
+    });
+  });
+}
+
+function copyDirRecursive(src, dest) {
+  if (!fs.existsSync(src)) return 0;
+  fs.mkdirSync(dest, { recursive: true });
+  let count = 0;
+  const entries = fs.readdirSync(src, { withFileTypes: true });
+  for (const entry of entries) {
+    const srcPath = path.join(src, entry.name);
+    const destPath = path.join(dest, entry.name);
+    if (entry.isDirectory()) {
+      count += copyDirRecursive(srcPath, destPath);
+    } else {
+      fs.copyFileSync(srcPath, destPath);
+      count++;
+    }
+  }
+  return count;
+}
+
+function deepMerge(target, source) {
+  for (const key of Object.keys(source)) {
+    if (
+      source[key] && typeof source[key] === 'object' && !Array.isArray(source[key]) &&
+      target[key] && typeof target[key] === 'object' && !Array.isArray(target[key])
+    ) {
+      deepMerge(target[key], source[key]);
+    } else if (Array.isArray(source[key]) && Array.isArray(target[key])) {
+      // Merge arrays without duplicates
+      const merged = [...new Set([...target[key], ...source[key]])];
+      target[key] = merged;
+    } else {
+      target[key] = source[key];
+    }
+  }
+  return target;
+}
+
+// ── MCP Registration ─────────────────────────────────────────────────────────
+
+function registerMcpServers(claudeJsonPath) {
+  const mcpServers = {
+    playwright: {
+      command: 'npx',
+      args: ['@playwright/mcp@latest']
+    },
+    context7: {
+      command: 'npx',
+      args: ['-y', '@upstash/context7-mcp@latest']
+    }
+  };
+
+  let config = {};
+  if (fs.existsSync(claudeJsonPath)) {
+    try {
+      config = JSON.parse(fs.readFileSync(claudeJsonPath, 'utf-8'));
+    } catch {
+      config = {};
+    }
+  }
+
+  if (!config.mcpServers) config.mcpServers = {};
+
+  let added = [];
+  for (const [name, serverConfig] of Object.entries(mcpServers)) {
+    if (!config.mcpServers[name]) {
+      config.mcpServers[name] = serverConfig;
+      added.push(name);
+    }
+  }
+
+  fs.writeFileSync(claudeJsonPath, JSON.stringify(config, null, 2) + '\n');
+  return added;
+}
+
+// ── Settings Merge ───────────────────────────────────────────────────────────
+
+function mergeSettings(installDir, packageDir) {
+  const srcSettings = path.join(packageDir, 'settings.json');
+  if (!fs.existsSync(srcSettings)) return false;
+
+  const claudeDir = path.dirname(installDir);
+  const destSettings = path.join(claudeDir, 'settings.json');
+
+  const source = JSON.parse(fs.readFileSync(srcSettings, 'utf-8'));
+
+  let target = {};
+  if (fs.existsSync(destSettings)) {
+    try {
+      target = JSON.parse(fs.readFileSync(destSettings, 'utf-8'));
+    } catch {
+      target = {};
+    }
+  }
+
+  deepMerge(target, source);
+  fs.writeFileSync(destSettings, JSON.stringify(target, null, 2) + '\n');
+  return true;
+}
+
+// ── Main ─────────────────────────────────────────────────────────────────────
+
+async function main() {
+  console.log('');
+  console.log('  ╔═══════════════════════════════════════╗');
+  console.log('  ║   QAA — QA Automation Agent Installer ║');
+  console.log('  ╚═══════════════════════════════════════╝');
+  console.log('');
+
+  // Determine package root (where the npm package files are)
+  const packageDir = path.resolve(__dirname, '..');
+
+  // Check that package files exist
+  const requiredDirs = ['agents', 'commands', 'skills'];
+  const missing = requiredDirs.filter(d => !fs.existsSync(path.join(packageDir, d)));
+  if (missing.length > 0) {
+    fail(`Package incomplete — missing: ${missing.join(', ')}`);
+    process.exit(1);
+  }
+
+  // Ask install scope
+  console.log('  Install scope:');
+  console.log('    1) Global  — ~/.claude/qaa  (available in all projects)');
+  console.log('    2) Local   — ./.claude/qaa  (this project only)');
+  console.log('');
+  const scopeChoice = await ask('Choose [1/2] (default: 1):');
+  const isGlobal = scopeChoice !== '2';
+
+  const homeDir = process.env.HOME || process.env.USERPROFILE;
+  const claudeDir = isGlobal
+    ? path.join(homeDir, '.claude')
+    : path.join(process.cwd(), '.claude');
+  const installDir = path.join(claudeDir, 'qaa');
+
+  // Check for existing installation
+  if (fs.existsSync(installDir)) {
+    const overwrite = await ask('QAA already installed at this location. Overwrite? [y/N]:');
+    if (overwrite.toLowerCase() !== 'y') {
+      log('Installation cancelled.');
+      process.exit(0);
+    }
+  }
+
+  console.log('');
+  log(`Installing to: ${installDir}`);
+  console.log('');
+
+  // ── Step 1: Copy files ──────────────────────────────────────────────────
+
+  const dirsToCopy = ['agents', 'commands', 'skills', 'templates', 'workflows', 'docs', 'bin'];
+  const filesToCopy = ['CLAUDE.md', 'CHANGELOG.md', '.mcp.json', 'package.json'];
+
+  let totalFiles = 0;
+
+  for (const dir of dirsToCopy) {
+    const src = path.join(packageDir, dir);
+    const dest = path.join(installDir, dir);
+    if (fs.existsSync(src)) {
+      const count = copyDirRecursive(src, dest);
+      success(`${dir}/ — ${count} files`);
+      totalFiles += count;
+    }
+  }
+
+  for (const file of filesToCopy) {
+    const src = path.join(packageDir, file);
+    const dest = path.join(installDir, file);
+    if (fs.existsSync(src)) {
+      fs.mkdirSync(path.dirname(dest), { recursive: true });
+      fs.copyFileSync(src, dest);
+      success(file);
+      totalFiles++;
+    }
+  }
+
+  console.log('');
+
+  // ── Step 2: Register MCP servers ────────────────────────────────────────
+
+  const claudeJsonPath = path.join(homeDir, '.claude.json');
+  const addedMcps = registerMcpServers(claudeJsonPath);
+
+  if (addedMcps.length > 0) {
+    success(`MCP servers registered: ${addedMcps.join(', ')} → ${claudeJsonPath}`);
+  } else {
+    success('MCP servers already configured (playwright, context7)');
+  }
+
+  // ── Step 3: Merge settings ──────────────────────────────────────────────
+
+  const settingsMerged = mergeSettings(installDir, packageDir);
+  if (settingsMerged) {
+    success('Permissions merged into settings.json');
+  }
+
+  // ── Done ────────────────────────────────────────────────────────────────
+
+  console.log('');
+  console.log('  ╔═══════════════════════════════════════╗');
+  console.log('  ║         Installation complete!        ║');
+  console.log('  ╚═══════════════════════════════════════╝');
+  console.log('');
+  log(`${totalFiles} files installed to ${installDir}`);
+  log('MCP servers: playwright, context7');
+  log('');
+  log('Restart Claude Code, then run any QAA command:');
+  log('  /qa-start --dev-repo ./your-project');
+  log('  /qa-create-test login');
+  log('  /qa-map');
+  console.log('');
+}
+
+main().catch(err => {
+  fail(err.message);
+  process.exit(1);
+});

package/commands/qa-create-test-ado.md

@@ -0,0 +1,404 @@
+# QA Create Test — Azure DevOps
+
+Retrieve an Azure DevOps work item, analyze its content, and generate well-structured Test Cases directly in Azure DevOps using the ADO MCP tools. Each test case is tagged for test plan membership (Smoke, Regression, Critical) and linked back to the source work item for full traceability. Integrates with the QAA pipeline: reads codebase map, locator registry, and user preferences for context-aware test case generation.
+
+## Usage
+
+```
+/qa-create-test-ado <work-item-id> [--area-path=<path>] [--iteration-path=<path>] [--skip-map] [--skip-dedup] [--app-url <url>]
+```
+
+### Arguments
+
+| Parameter | Purpose | Default |
+|-----------|---------|---------|
+| `<work-item-id>` | Azure DevOps work item ID to generate test cases from | Required |
+| `--area-path=<path>` | Override area path for all created test artifacts | Source work item's area path |
+| `--iteration-path=<path>` | Override iteration path for all created test artifacts | Source work item's iteration path |
+| `--skip-map` | Skip codebase map check and proceed without project context | false |
+| `--skip-dedup` | Skip deduplication check against existing linked test cases | false |
+| `--app-url <url>` | URL of running application for locator extraction via Playwright MCP | auto-detect |
+
+## What It Produces
+
+- Test Cases created directly in Azure DevOps (via `testplan_create_test_case`)
+- Test Cases linked to source work item via *Tested By* relationship
+- Tags applied: `Smoke`, `Regression`, `Critical`, `AutomationCandidate`, `NeedsReview`
+- `ai-tasks/ticket-{id}/test-cases.md` — structured report
+- Report attached to work item (if `ADO_MCP_AUTH_TOKEN` is set) or written to `Custom.QATestCasesReport` field (fallback)
+
+---
+
+## Process
+
+### Phase 1: Read Pipeline Context
+
+Before retrieving the work item, read QAA pipeline artifacts for context-aware generation.
+
+1. **Read `CLAUDE.md`** — POM rules, locator tiers, assertion rules, naming conventions, quality gates, test spec rules.
+
+2. **Read user preferences** — `~/.claude/qaa/MY_PREFERENCES.md` (if exists). User overrides win over defaults.
+
+3. **Check for codebase map** (`.qa-output/codebase/`):
+   - Look for: `CODE_PATTERNS.md`, `API_CONTRACTS.md`, `TEST_SURFACE.md`, `TESTABILITY.md`, `RISK_MAP.md`, `CRITICAL_PATHS.md`
+   - If at least 2 exist: read them all for project context (naming conventions, API shapes, testable surfaces, risk areas).
+   - If NONE exist and `--skip-map` not passed: warn the user that test cases will lack project context, suggest running `/qa-map` first. Continue anyway (ADO test cases are higher-level than code-level tests).
+
+4. **Check locator registry** — `.qa-output/locators/LOCATOR_REGISTRY.md` (if exists):
+   - If locators exist for pages related to the work item's feature: reference them in test step expected results (e.g., "Verify element `[data-testid='login-submit-btn']` is visible").
+   - If `--app-url` provided and locators missing: use Playwright MCP to extract locators from the live app before designing test steps:
+     ```
+     mcp__playwright__browser_navigate({ url: "{app_url}/{feature_path}" })
+     mcp__playwright__browser_snapshot()
+     ```
+   - Write extracted locators to `.qa-output/locators/{feature}.locators.md` and update the registry.
+
+---
+
+### Phase 2: Retrieve the Work Item
+
+Use `wit_get_work_item` with `expand: "relations"` to fetch the full work item:
+
+- Capture: **title**, **type** (`Bug`, `User Story`, `Ticket`), **state**, **assigned-to**, **area path**, **iteration path**
+- Capture all relevant content fields based on type (see Phase 3)
+- Note the project for all subsequent calls
+
+**Also retrieve comments** using `wit_list_work_item_comments`:
+
+- Read all comments in chronological order
+- Look for: acceptance criteria added in comments, QA notes, scope clarifications, tester feedback, or any conditions of satisfaction mentioned informally
+- These often contain implied test cases not captured in the formal fields
+
+**Also check attachments** from the relations list (entries where `rel` equals `AttachedFile`):
+
+- Filter to `.csv` and `.txt` files (case-insensitive) by inspecting `attributes.name`
+- If found, download via:
+  ```bash
+  curl -s --user ":{AZURE_DEVOPS_PAT}" "{attachment-url}"
+  ```
+- Read content for test data, expected values, error logs, or sample datasets that define expected behavior
+
+---
+
+### Phase 2b: Deduplication Check — Query Existing Test Cases
+
+Before generating any new test cases, check whether the source work item already has linked test cases to prevent duplicates.
+
+1. Inspect the relations returned in Phase 2 — filter for link type `"Microsoft.VSTS.Common.TestedBy-Forward"` (i.e., *Tested By* links).
+2. For each linked test case ID found, call `wit_get_work_item` to retrieve its **title** and **state**.
+3. Build an **existing TC registry** — a list of `{ id, title, state }` for all currently linked test cases.
+4. In Phase 5, before calling `testplan_create_test_case` for each planned TC, compare its title (normalized: lowercase, trimmed) against every title in the registry.
+   - **If match found** and existing TC is in state `Design`, `Ready`, or `Closed`: skip creation, log `"Skipped — duplicate of TC #{id}"`.
+   - **If match found** but existing TC is in state `Removed`: create the new TC anyway (the old one was intentionally discarded).
+   - **If no match**: proceed with creation.
+5. Include a **Dedup Summary** section in the output report.
+
+Skip this check with `--skip-dedup`.
+
+---
+
+### Phase 3: Identify Work Item Type and Extract Test Source Content
+
+Apply the correct extraction strategy based on work item type:
+
+#### If type is `Bug` or `Ticket`:
+
+Primary source — **Repro Steps** (`Microsoft.VSTS.TCM.ReproSteps`):
+- Each distinct action sequence is a candidate test case
+- The repro steps define the *negative path* (what triggers the bug)
+- Derive the *positive/fix-verification path* by inverting the expected outcome
+- Also read: **System Info** (`Microsoft.VSTS.TCM.SystemInfo`), **Description**, **QA Notes** (`CIIScrum.QANotes`)
+- Check `Custom.Whatisexpectedtohappen` and `Custom.Whatisactuallyhappening` to anchor pass/fail assertions
+
+Secondary sources:
+- Comments for tester observations or specific scenarios to cover
+- Attachments for error data or sample inputs
+
+#### If type is `User Story`:
+
+Primary source — **Acceptance Criteria** (`Microsoft.VSTS.Common.AcceptanceCriteria`):
+- Each acceptance criterion (Given/When/Then or checklist) maps to one or more test cases
+- Also read: **Description** for context and implied behaviors
+
+Secondary sources:
+- Comments for clarifications, edge cases raised in refinement, or stakeholder scenarios
+- Attachments for wireframes described in text, sample data, or business rules documents
+
+#### If type is unrecognized or fields are empty:
+
+Fall back to **Description** as the primary source. Extract any stated behaviors, expected outcomes, or constraints. Note the fallback in the output.
+
+**Cross-reference with codebase map** (if available):
+- Match mentioned components/features against `TEST_SURFACE.md` entry points
+- Check `RISK_MAP.md` for risk level of affected areas
+- Use `API_CONTRACTS.md` for exact endpoint shapes if the work item mentions API behavior
+- Use `CODE_PATTERNS.md` to align test step language with project conventions
+
+---
+
+### Phase 4: Analyze and Design Test Cases
+
+Before creating anything in Azure DevOps, plan out all test cases:
+
+**For each distinct scenario identified, determine:**
+
+1. **Test Case Title** — concise action-oriented name (e.g., "Verify guest pass entry counter resets at midnight")
+2. **Steps** — formatted as `{step action} | {expected result}` per step, using `|` as the delimiter
+3. **Priority** — 1 (Critical), 2 (High), 3 (Medium), 4 (Low)
+4. **Tags** — one or more of: `Smoke`, `Regression`, `Critical`, `AutomationCandidate`, `NeedsReview`
+5. **Preconditions** — required setup before executing the test
+6. **Confidence** — `Specified` or `Draft`
+
+**Minimum test case coverage per work item type:**
+
+| Scenario Type | Bug/Ticket | User Story |
+|---------------|-----------|------------|
+| Happy path (fix verified / AC met) | Required | Required per AC item |
+| Negative / error path | Required (original repro) | Where AC implies failure states |
+| Boundary / edge cases | If data-driven | If AC contains limits or conditions |
+| Boundary value triplets (n-1, n, n+1) | If limits detected | If AC contains limits/ranges |
+| Regression guard (related area) | Required | Required |
+
+#### Boundary Value Detection
+
+Scan all source content for **boundary keyword triggers**:
+
+> `max`, `min`, `limit`, `threshold`, `cap`, `ceiling`, `floor`, `range`, `between`, `up to`, `at most`, `at least`, `no more than`, `no fewer than`, `maximum`, `minimum`, `exactly`, `exceeds`, `boundary`
+
+When a trigger is found alongside a numeric value **N**:
+
+1. **Generate three test cases** (the boundary triplet):
+   - **N - 1** — just below the boundary
+   - **N** — exactly at the boundary
+   - **N + 1** — just above the boundary
+2. Title them clearly: e.g., `"Verify entry limit at 99 (below threshold)"`, `"...at 100 (at threshold)"`, `"...at 101 (above threshold)"`.
+3. Tag all three with `Regression`.
+4. If the boundary is on a critical-path field (per `CRITICAL_PATHS.md` or keyword detection), also tag `Critical`.
+
+If the source mentions a range, generate boundary triplets for **both** ends.
+
+#### Tagging Rules
+
+| Tag | Assign when... |
+|-----|---------------|
+| `Smoke` | Verifies core, user-facing functionality that must work for the app to be usable at all. Limit to the most essential 1-2 cases per work item. |
+| `Regression` | Guards against the specific bug or behavior being re-introduced. Every fix-verification test for a Bug/Ticket should be tagged. For User Stories, tag tests covering AC that touches shared or high-traffic code paths. |
+| `Critical` | Covers functionality whose failure would directly impact revenue, security, data integrity, or legal compliance. **Also apply when critical keywords are detected** (see Keyword-Based Critical Tagging below). Apply conservatively. |
+| `AutomationCandidate` | Test has: (a) deterministic steps with no subjective judgment, (b) assertions based on concrete data/state, (c) no manual-only prerequisites. Advisory only — QA confirms. |
+
+**Do not assign Smoke to every test case.** Smoke tests are a small, fast-running set.
+
+#### Keyword-Based Critical Tagging
+
+Automatically tag as `Critical` when any of the following keywords appear in the source content:
+
+> `auth`, `authentication`, `login`, `password`, `OAuth`, `SSO`, `payment`, `billing`, `charge`, `invoice`, `PII`, `personal data`, `SSN`, `date of birth`, `security`, `encryption`, `token`, `certificate`, `data integrity`, `transaction`, `rollback`, `compliance`, `HIPAA`, `GDPR`, `SOC`, `audit`, `permission`, `role-based`, `access control`
+
+Cross-reference with `RISK_MAP.md` (if available) for additional risk-based tagging.
+
+#### Confidence Scoring
+
+| Confidence | Criteria | Behavior |
+|------------|----------|----------|
+| **Specified** | Source content explicitly describes the scenario, expected outcome, and data. | Create the TC normally. |
+| **Draft** | Scenario is implied or partially described — inferred from context or sparse source. | Prefix TC title with `[DRAFT]`. Add `NeedsReview` tag. Add final step: `"Review — this test case was auto-generated from sparse source material and requires QA validation before execution." | "QA has reviewed and confirmed or updated the steps."` |
+
+**Threshold**: If more than 50% of the source content fields are empty or contain fewer than 20 words, default all inferred TCs to Draft.
+
+#### Preconditions Block
+
+Every test case documents preconditions:
+
+| Field | Description | Example |
+|-------|-------------|--------|
+| **Required Role(s)** | User role(s) or permission level(s) needed | `Admin`, `Property Manager`, `Resident` |
+| **Application State** | System/feature state that must be true before step 1 | `User is logged in`, `Feature flag X is enabled` |
+| **Test Data** | Specific data that must exist or be created | `Resident account with active lease` |
+| **Environment** | Environment-specific requirements | `Staging`, `API key configured` |
+
+Prepend preconditions to the TC description field in Azure DevOps:
+
+```
+**Preconditions**
+- Role(s): {roles}
+- State: {state}
+- Test Data: {data}
+- Environment: {env}
+```
+
+If locator registry data is available, include relevant locator references in test steps for E2E-related scenarios.
+
+---
+
+### Phase 5: Create Test Cases in Azure DevOps
+
+**Dedup gate**: Before creating each TC, check against the registry from Phase 2b.
+
+For each planned test case, call `testplan_create_test_case` with:
+
+- `project`: the work item's project
+- `title`: the test case title — prefixed with `[DRAFT]` if confidence is Draft
+- `steps`: formatted as `1. {action}|{expected result}\n2. {action}|{expected result}` — use `|` as delimiter. **Never pass XML or pre-formatted `<steps>` markup** — the tool generates XML from plain-text format.
+- `priority`: numeric priority (1-4)
+- `iterationPath`: use `--iteration-path` override if provided, otherwise source work item's iteration path
+- `areaPath`: use `--area-path` override if provided, otherwise source work item's area path
+
+**After creating each test case:**
+
+1. Call `wit_add_artifact_link` or `wit_work_items_link` to link the new TC to the source work item using link type `"tested by"`:
+   ```
+   source work item  --[Tested By]-->  test case
+   ```
+
+2. Call `wit_update_work_item` on the new TC to set `System.Tags` to semicolon-separated tags (e.g., `"Regression; Critical; AutomationCandidate"`).
+   - Draft TCs always include `NeedsReview`.
+
+Create all test cases sequentially — capture each new TC ID before proceeding.
+
+---
+
+### Phase 6: Synthesize the Output Report
+
+Save the report to `ai-tasks/ticket-$ARGUMENTS/test-cases.md`.
+
+**Required document structure:**
+
+```markdown
+# Test Cases: {work-item-id} — {Work Item Title}
+
+**Generated**: {current date}
+**Work Item**: [{work-item-id}]({azure-devops-url}) — {type} | {state}
+**Assigned To**: {assigned-to}
+**Area Path**: {area path}
+**Iteration**: {iteration path}
+**Test Source**: {Repro Steps / Acceptance Criteria / Description (fallback)}
+**Pipeline Context**: Codebase map: {yes/no}, Locator registry: {yes/no}, Preferences: {yes/no}
+
+---
+
+## Source Analysis
+
+### Work Item Summary
+{2-3 sentences describing the work item and what behavior needed to be tested.}
+
+### Key Scenarios Identified
+{Bulleted list of distinct testable scenarios extracted before designing test cases.}
+
+### Source Content Notes
+{Observations about quality/completeness of source material. Were repro steps/AC clear? Did comments add scenarios?}
+
+### Codebase Context Used
+{If codebase map was available: list which documents were read and what context they provided. If not available: note that test cases were generated without codebase context.}
+
+---
+
+## Test Cases Created
+
+### TC-{azure-devops-id}: {title}
+
+**Confidence**: `Specified` or `[DRAFT] — NeedsReview`
+**Tags**: `{Smoke}` · `{Regression}` · `{Critical}` · `{AutomationCandidate}` · `{NeedsReview}` *(show only tags that apply)*
+**Priority**: {1 – Critical / 2 – High / 3 – Medium / 4 – Low}
+**Linked To**: Work Item #{work-item-id} via *Tested By*
+**Azure DevOps ID**: {test-case-id}
+
+**Preconditions:**
+- **Role(s)**: {required roles or N/A}
+- **State**: {required application state or N/A}
+- **Test Data**: {required data or N/A}
+- **Environment**: {environment requirements or N/A}
+
+**Test Steps:**
+
+| # | Action | Expected Result |
+|---|--------|-----------------|
+| 1 | {action} | {expected result} |
+| 2 | {action} | {expected result} |
+
+{Repeat for each test case.}
+
+---
+
+## Tag Summary
+
+| Tag | Count | Test Case IDs |
+|-----|-------|---------------|
+| Smoke | {n} | {comma-separated IDs} |
+| Regression | {n} | {comma-separated IDs} |
+| Critical | {n} | {comma-separated IDs} |
+| AutomationCandidate | {n} | {comma-separated IDs} |
+| NeedsReview | {n} | {comma-separated IDs} |
+
+---
+
+## Dedup Summary
+
+| Planned Title | Skipped Reason | Existing TC |
+|---------------|---------------|-------------|
+| {title} | Duplicate of TC #{id} | #{id} — {state} |
+
+{If no duplicates: "No duplicates detected — all test cases were created."}
+
+---
+
+## Traceability
+
+All test cases linked to work item **#{work-item-id}** via *Tested By*.
+
+**Path Overrides Applied**: {If --area-path or --iteration-path provided, state them. Otherwise: "None — used source work item paths."}
+**Confidence Breakdown**: {n} Specified, {n} Draft (NeedsReview)
+**Boundary Triplets Generated**: {n} (from {n} detected boundaries)
+```
+
+---
+
+### Phase 7: Attach Report to Source Work Item
+
+**If `ADO_MCP_AUTH_TOKEN` is set:**
+
+Upload `test-cases.md` as an attachment:
+
+```bash
+# Step 1: Upload file
+ATTACHMENT_URL=$(curl -s \
+  --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
+  --header "Content-Type: application/octet-stream" \
+  --request POST \
+  --data-binary "@ai-tasks/ticket-$ARGUMENTS/test-cases.md" \
+  "https://dev.azure.com/{org}/{project}/_apis/wit/attachments?fileName=test-cases.md&api-version=7.1" \
+  | python3 -c "import sys,json; print(json.load(sys.stdin)['url'])")
+
+# Step 2: Link attachment to work item
+curl -s \
+  --header "Authorization: Basic $(echo -n :${ADO_MCP_AUTH_TOKEN} | base64)" \
+  --header "Content-Type: application/json-patch+json" \
+  --request PATCH \
+  --data "[{\"op\":\"add\",\"path\":\"/relations/-\",\"value\":{\"rel\":\"AttachedFile\",\"url\":\"${ATTACHMENT_URL}\",\"attributes\":{\"comment\":\"Generated test cases report\"}}}]" \
+  "https://dev.azure.com/{org}/{project}/_apis/wit/workItems/$ARGUMENTS?api-version=7.1"
+```
+
+**If `ADO_MCP_AUTH_TOKEN` is NOT set (fallback):**
+
+Write the full report as HTML to the work item's `Custom.QATestCasesReport` field via `wit_update_work_item`. Include all sections converted to HTML.
+
+Note in the final report which method was used.
+
+---
+
+## Final Report to User
+
+After completing all phases, provide:
+
+1. Brief inline summary (2-3 sentences) of scenarios covered
+2. Full path to generated file: `ai-tasks/ticket-{id}/test-cases.md`
+3. Table of every created TC: ID, title, tags, confidence
+4. Counts by tag: Smoke, Regression, Critical, AutomationCandidate, NeedsReview
+5. Dedup summary: how many planned TCs were skipped
+6. Confidence summary: Specified vs Draft counts
+7. Boundary summary: how many boundary triplets generated
+8. Pipeline context: which codebase map documents and locator registry data were used
+9. Gaps or assumptions made
+10. Path override confirmation (if used)
+11. Report delivery confirmation (attached as file or written to custom field)
+
+$ARGUMENTS

package/commands/qa-create-test.md

@@ -1,6 +1,6 @@
 # QA Create Test
 
-Create, update, or generate tests from tickets — all in one command. Supports three modes: generate tests from code analysis, generate tests from a ticket (Jira/Linear/GitHub), or update/improve existing tests. Uses Playwright MCP to extract real locators from the live app when available.
+Create, update, or generate tests from tickets — all in one command. Supports five modes: generate tests from code analysis, generate tests from a ticket (Jira/Linear/GitHub), create Test Cases in Azure DevOps from a work item, update/improve existing tests, or generate POM files only. Uses Playwright MCP to extract real locators from the live app when available.
 
 ## Usage
 
@@ -14,6 +14,7 @@ Create, update, or generate tests from tickets — all in one command. Supports
 |------|---------|---------|
 | **From code** | Feature name (no URL, no path to tests) | `/qa-create-test login` |
 | **From ticket** | URL, shorthand (#123), or `--ticket` flag | `/qa-create-test https://github.com/org/repo/issues/42` |
+| **Azure DevOps** | `--ado` flag with work item ID or ADO URL | `/qa-create-test --ado 85508` |
 | **Update existing** | Path to existing test files or `--update` flag | `/qa-create-test --update tests/e2e/` |
 | **POM only** | `--pom-only` flag | `/qa-create-test --pom-only src/pages/` |
 
@@ -25,6 +26,10 @@ Create, update, or generate tests from tickets — all in one command. Supports
 - `--ticket <source>` — force ticket mode with: URL, shorthand (#123, org/repo#123), file path, or plain text
 - `--update <path>` — force update mode: audit and improve existing tests at path
 - `--scope fix|improve|add|full` — for update mode only (default: full)
+- `--ado <work-item-id>` — Azure DevOps mode: read a work item and create Test Cases in ADO (accepts ID or full ADO URL)
+- `--area-path <path>` — (ADO mode) override area path for created test cases (default: source work item's area path)
+- `--iteration-path <path>` — (ADO mode) override iteration path for created test cases (default: source work item's iteration path)
+- `--skip-dedup` — (ADO mode) skip deduplication check against existing linked test cases
 - `--pom-only [path]` — generate only Page Object Model files (BasePage + feature POMs), no test specs
 - `--framework <name>` — override framework auto-detection (playwright, cypress, selenium) — used with --pom-only
 
@@ -33,8 +38,9 @@ Create, update, or generate tests from tickets — all in one command. Supports
 ```
 if --pom-only:
   MODE = "pom-only"
-elif argument matches URL pattern ...
-if argument matches URL pattern (github.com, atlassian.net, linear.app) OR contains "#" + digits OR --ticket flag:
+elif --ado flag OR argument matches ADO URL (dev.azure.com, *.visualstudio.com):
+  MODE = "ado"
+elif argument matches URL pattern (github.com, atlassian.net, linear.app) OR contains "#" + digits OR --ticket flag:
   MODE = "from-ticket"
 elif --update flag OR argument is path to existing test directory/files:
   MODE = "update"
@@ -57,6 +63,13 @@ else:
 - Test spec files with `traces_to` fields linking back to ticket ACs
 - VALIDATION_REPORT.md
 
+### Azure DevOps Mode
+- Test Cases created directly in Azure DevOps (via `testplan_create_test_case`)
+- Test Cases linked to source work item via *Tested By* relationship
+- Tags applied: `Smoke`, `Regression`, `Critical`, `AutomationCandidate`, `NeedsReview`
+- `ai-tasks/ticket-{id}/test-cases.md` — structured report
+- Report attached to work item (if `ADO_MCP_AUTH_TOKEN` is set) or written to `Custom.QATestCasesReport` field (fallback)
+
 ### Update Mode
 - QA_AUDIT_REPORT.md — current quality assessment
 - Improved test files (after user approval)
@@ -70,8 +83,8 @@ Parse `$ARGUMENTS` to determine mode using the detection logic above.
 Print mode banner:
 ```
 === QA Create Test ===
-Mode: {from-code | from-ticket | update}
-Target: {feature name | ticket URL | test path}
+Mode: {from-code | from-ticket | ado | update | pom-only}
+Target: {feature name | ticket URL | ADO work item ID | test path}
 App URL: {url or "auto-detect"}
 ===========================
 ```
@@ -203,6 +216,34 @@ Key steps in the workflow:
 
 ---
 
+### ADO MODE (Azure DevOps)
+
+Create Test Cases directly in Azure DevOps from a work item. Reads the work item content (repro steps, acceptance criteria, comments, attachments), designs test cases with boundary detection and deduplication, and creates them in ADO with full traceability.
+
+**Prerequisites:** ADO MCP server must be connected (provides `wit_get_work_item`, `testplan_create_test_case`, etc.).
+
+Execute the full ADO workflow defined in `@commands/qa-create-test-ado.md`:
+
+1. **Phase 1** — Read pipeline context: CLAUDE.md, MY_PREFERENCES.md, codebase map, locator registry
+2. **Phase 2** — Retrieve work item with relations, comments, and attachments
+3. **Phase 2b** — Deduplication check against existing linked test cases (skip with `--skip-dedup`)
+4. **Phase 3** — Extract test source content based on work item type (Bug → Repro Steps, User Story → Acceptance Criteria)
+5. **Phase 4** — Design test cases with boundary value detection, tagging rules, confidence scoring, and preconditions
+6. **Phase 5** — Create test cases in ADO via `testplan_create_test_case`, link via *Tested By*, set tags
+7. **Phase 6** — Generate structured report to `ai-tasks/ticket-{id}/test-cases.md`
+8. **Phase 7** — Attach report to source work item
+
+**Key features:**
+- Boundary value triplets: detects `max`, `min`, `limit`, `threshold` keywords with numeric values → generates N-1, N, N+1 test cases
+- Deduplication: checks existing linked TCs before creating, prevents duplicates
+- Confidence scoring: `Specified` (explicit source) vs `Draft` (inferred, tagged `NeedsReview`)
+- Cross-references codebase map for project-specific context when available
+- Supports `--area-path` and `--iteration-path` overrides
+
+For the complete step-by-step process, see `@commands/qa-create-test-ado.md`.
+
+---
+
 ### UPDATE MODE
 
 1. Read `CLAUDE.md` — quality gates, locator tiers, assertion rules, POM rules.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qaa-agent",
-  "version": "1.8.0",
+  "version": "1.8.5",
   "description": "QA Automation Agent for Claude Code — multi-agent pipeline that analyzes repos, generates tests, validates, and creates PRs",
   "bin": {
     "qaa-agent": "./bin/install.cjs"
@@ -22,7 +22,8 @@
   "author": "Backhaus7997",
   "license": "MIT",
   "dependencies": {
-    "@playwright/mcp": "latest"
+    "@playwright/mcp": "latest",
+    "@upstash/context7-mcp": "latest"
   },
   "files": [
     "bin/",