@chris1807/claude-kit 2.1.56 → 2.1.58

package/README.md

@@ -17,7 +17,7 @@ The slash commands assume Azure DevOps as the system of record:
 - **Releases & deployments** — tracked as Azure DevOps iterations (`Release #N`) and tags; CD runs on Azure Pipelines
 - **Wiki, test plans, advanced security alerts** — all surfaced through the same Azure DevOps MCP server
 
-> **Not using Azure DevOps?** The Claude Code primitives (agents, hooks, memory) are still useful, but the slash commands and the deployment workflow won't apply out of the box — you'd need to rewrite the `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/rework`, and `/resolve-feedback` commands against GitHub / GitLab / Jira / etc.
+> **Not using Azure DevOps?** The Claude Code primitives (agents, hooks, memory) are still useful, but the slash commands and the deployment workflow won't apply out of the box — you'd need to rewrite the `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/rework`, and `/resolve-feedback` commands against GitHub / GitLab / Jira / etc.
 
 Every session Claude learns from your feedback and gets better at helping you specifically. The infrastructure is modular — install only what your project needs.
 
@@ -28,7 +28,7 @@ Every session Claude learns from your feedback and gets better at helping you sp
 | **Global Agents** | 10 | `~/.claude/agents/` (your machine, all projects) | backend, frontend, legacy (Lucee/CFML), mockup, reviewer, test-runner, build-validator, lint-checker, azure-ops, security-auditor |
 | **Project Agents** | 2 | `.claude/agents/` (in the project) | deployer, db-admin |
 | **Hooks** | 9 | `.claude/hooks/` (in the project) | Secret blocker, sensitive data blocker (Bash + MCP + output), protected files, auto-format, test suggestions, UAT reminder, self-improve |
-| **Slash Commands** | 24 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
+| **Slash Commands** | 24 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
 | **MCP Servers** | Up to 6 | `.mcp.json` (in the project) | **Azure DevOps** (work items, repos, pipelines, wiki), Playwright, MongoDB/SQL/Postgres, Teams, Stripe, Azure CLI |
 | **Workflow Template** | 1 | Appended to `CLAUDE.md` | Documents the full development process |
 | **Settings** | 1 | `.claude/settings.json` (in the project) | Registers all hooks and MCP servers |
@@ -73,7 +73,7 @@ You'll be asked:
 2. **Components** — checkboxes to pick which parts to install:
    - ☑ Project Agents (deployer, db-admin)
    - ☑ Hooks (secret blocker, auto-format, etc.)
-   - ☑ Slash Commands (/implement, /review, /resolve-feedback, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /status, /cleanup-branches, /quote, /explain)
+   - ☑ Slash Commands (/implement, /review, /resolve-feedback, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /track, /cleanup-branches, /quote, /explain)
    - ☑ MCP Servers
    - ☑ Settings
    - ☑ CLAUDE.md Workflow
@@ -181,6 +181,7 @@ The installer automatically **skips global agents** that are already installed (
 ├── mockup.md                      # HTML mockup designer
 ├── reviewer.md                    # Code reviewer (read-only)
 ├── test-runner.md                 # Test executor — xUnit, Vitest, Playwright (read-only)
+├── qa.md                          # Browser QA on a deployed environment (read-only)
 ├── build-validator.md             # Build checker (read-only)
 ├── lint-checker.md                # ESLint + dotnet format checker
 ├── azure-ops.md                   # Azure infrastructure management
@@ -213,7 +214,7 @@ your-project/                      ← Project-specific
 │   │   ├── promote.md             # /promote main dev
 │   │   ├── rollback.md            # /rollback AB#1234 prod
 │   │   ├── add-to-release.md      # /add-to-release 24 AB#4599
-│   │   ├── status.md              # /status release 24
+│   │   ├── track.md               # /track release 24
 │   │   ├── cleanup-branches.md    # /cleanup-branches
 │   │   ├── close-orphan-tasks.md  # /close-orphan-tasks
 │   │   ├── quote.md               # /quote AB#1234
@@ -260,7 +261,7 @@ Kit operations that benefit from ultracode when it's on:
 | Multi-file or cross-layer review | one agent per file/dimension, then adversarial verify before reporting |
 | Repo-wide sweeps (rename, dependency bump, pattern migration) | one agent per site, worktree-isolated |
 
-Short, single-query operations (`/status`, `/explain`, `/close-orphan-tasks`) don't need ultracode — they're already one pass and gain nothing from fan-out. Reach for it when the work-list is large and the per-item work is independent.
+Short, single-query operations (`/track`, `/explain`, `/close-orphan-tasks`) don't need ultracode — they're already one pass and gain nothing from fan-out. Reach for it when the work-list is large and the per-item work is independent.
 
 ### Implement a Work Item
 
@@ -372,11 +373,11 @@ Adds work items to an existing release — assigns them to the iteration and tag
 ### Check Status
 
 ```
-/status release 24
-/status pipeline
-/status AB#4521
-/status staging
-/status
+/track release 24
+/track pipeline
+/track AB#4521
+/track staging
+/track
 ```
 
 Shows the status of a release, pipeline, work item, environment, or a high-level overview of everything.
@@ -440,7 +441,7 @@ Every environment has a work item state, and the promotion commands keep them in
 | `test → staging` | `Ready for Staging` (QA sign-off) | `Staging` |
 | `staging → prod` | `Ready to Deploy` (stakeholder sign-off) | `Deployed` |
 
-`/deploy-release`, `/cherry-pick`, and `/promote` check the gate before creating the PR, ask who verifies each product group while the PR is in review, then watch the PR and the environment's CD pipeline — on a green pipeline they set the state and the assignee together. A failed pipeline changes nothing. `/status` flags anything whose state lags the branch it's on.
+`/deploy-release`, `/cherry-pick`, and `/promote` check the gate before creating the PR, ask who verifies each product group while the PR is in review, then watch the PR and the environment's CD pipeline — on a green pipeline they set the state and the assignee together. A failed pipeline changes nothing. `/track` flags anything whose state lags the branch it's on.
 
 ### Branch Naming
 
@@ -678,7 +679,8 @@ Claude reviews for:
 | `/cherry-pick` | `/cherry-pick AB#1234 AB#1235 prod` | Gate-check → cherry-pick specific work items to environment via PR → ask who verifies → advance + assign on a green pipeline |
 | `/promote` | `/promote main dev` | PR to promote all code to the next branch in the chain (`main → dev → test → staging → prod`) → ask who verifies → advance + assign on a green pipeline |
 | `/rollback` | `/rollback AB#1234 prod` | Revert specific commits on an environment via PR |
-| `/status` | `/status release 24` | Check status of a release, pipeline, work item, or environment; flags work items whose state lags their environment |
+| `/track` | `/track release 24` | Check status of a release, pipeline, work item, or environment; flags work items whose state lags their environment |
+| `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment on the work item (never a state change). Environments: `local`, `dev`, `test`, `staging` |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose one child task with hours per story |
 | `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
 | `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, bugs in `New` (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated). Also audits the drop-out queue — tagged bugs and stories bounced to Design Review — for items whose creator answered but which nobody returned to the sweep |
@@ -731,6 +733,12 @@ export STRIPE_SECRET_KEY="sk_test_..."
 # Azure CLI (no env var needed — just log in)
 az login
 
+# QA test accounts (required for /qa — browser testing on a deployed environment).
+# One pair per role. The variable NAMES go in your project's `## Environment URLs`
+# section; the VALUES live only here. Use throwaway least-privilege QA accounts.
+export COMPASS_QA_ADMIN_USERNAME="qa-admin@example.com"
+export COMPASS_QA_ADMIN_PASSWORD="..."
+
 # Microsoft Teams (no env vars needed — uses Microsoft Graph device-code auth;
 # first invocation prints a code + URL to sign in)
 ```

package/bin/cli.js

@@ -161,12 +161,84 @@ function mergeHooks(existing, template) {
 // don't linger. manager/uat-generator/api-tester were superseded by the
 // Workflow tool and inline command steps; devops-tracker by direct Azure
 // DevOps MCP access in the main loop.
+// The workflow section written into a target CLAUDE.md is delimited by this marker so
+// a re-install can replace it without touching anything the project added afterwards.
+// Installs from before the marker existed are recovered heuristically — see
+// splitWorkflowSection.
+const WORKFLOW_END_MARKER = '<!-- claude-kit:workflow:end -->';
+
+const WORKFLOW_HEADING_RE = /\n## (?:Claude Kit Workflow|Care Solutions AI Workflow)/;
+
+/**
+ * Split a target CLAUDE.md around the kit's workflow section.
+ *
+ * Returns { head, preserved } where `head` is everything before the workflow
+ * heading and `preserved` is project content that followed the kit's block —
+ * or null when there is no workflow section at all.
+ *
+ * The old implementation replaced /heading[\s\S]*$/, i.e. everything to end of
+ * file, which silently deleted any `## Pipeline Configuration` or
+ * `## Environment URLs` a project had placed below the heading. With the marker
+ * present the boundary is exact. Without it (a pre-marker install) we fall back
+ * to a heading scan: the template's only top-level heading outside a fenced code
+ * block is the workflow heading itself, so any other non-fenced `## ` heading in
+ * the tail is project content and is kept. Fenced headings are skipped because
+ * the template quotes `## Pipeline Configuration` inside ```markdown examples.
+ */
+function splitWorkflowSection(existing) {
+  const match = existing.match(WORKFLOW_HEADING_RE);
+  if (!match) return null;
+
+  const head = existing.slice(0, match.index).trimEnd();
+  const tail = existing.slice(match.index);
+
+  const markerIdx = tail.indexOf(WORKFLOW_END_MARKER);
+  if (markerIdx !== -1) {
+    return {
+      head,
+      preserved: tail.slice(markerIdx + WORKFLOW_END_MARKER.length).trim(),
+      recovered: false,
+    };
+  }
+
+  const lines = tail.split('\n');
+  // `tail` begins with the newline preceding the heading, so the heading is not at
+  // index 0. Find it explicitly and scan from the line after it — starting at a
+  // fixed offset would treat the heading itself as project content.
+  const headingIdx = lines.findIndex((l) =>
+    /^## (?:Claude Kit Workflow|Care Solutions AI Workflow)/.test(l)
+  );
+  let inFence = false;
+  let cut = -1;
+  for (let i = headingIdx + 1; i < lines.length; i++) {
+    if (/^\s*```/.test(lines[i])) {
+      inFence = !inFence;
+      continue;
+    }
+    if (inFence) continue;
+    if (/^## /.test(lines[i])) {
+      cut = i;
+      break;
+    }
+  }
+
+  return {
+    head,
+    preserved: cut === -1 ? '' : lines.slice(cut).join('\n').trim(),
+    recovered: cut !== -1,
+  };
+}
+
 const RETIRED_GLOBAL_AGENTS = ['manager.md', 'uat-generator.md', 'api-tester.md'];
 const RETIRED_PROJECT_AGENTS = ['devops-tracker.md'];
+// status.md was renamed to track.md in 2.1.58 — Claude Code ships a built-in /status,
+// which shadowed the kit's command. The old file has to be deleted from existing
+// installs or the collision never goes away, since installs only ever add files.
+const RETIRED_COMMANDS = ['status.md'];
 
-async function removeRetiredAgents(agentsDir, retired) {
+async function removeRetiredFiles(dir, retired) {
   for (const file of retired) {
-    const target = join(agentsDir, file);
+    const target = join(dir, file);
     if (await fs.pathExists(target)) {
       await fs.remove(target);
       console.log(chalk.gray(`  - ${file} (retired, removed)`));
@@ -190,7 +262,7 @@ async function installGlobalAgents() {
       );
     }
   }
-  await removeRetiredAgents(globalAgentsDir, RETIRED_GLOBAL_AGENTS);
+  await removeRetiredFiles(globalAgentsDir, RETIRED_GLOBAL_AGENTS);
 }
 
 // ============================================================================
@@ -240,7 +312,7 @@ async function main() {
       choices: [
         { name: 'Project Agents (deployer, db-admin)', value: 'agents', checked: true },
         { name: 'Hooks (secret blocker, auto-format, test suggestions)', value: 'hooks', checked: true },
-        { name: 'Slash Commands (implement, review, deploy, releases, cherry-pick, promote, rollback, status, cleanup, create-work-item, …)', value: 'commands', checked: true },
+        { name: 'Slash Commands (implement, review, deploy, releases, cherry-pick, promote, rollback, track, cleanup, create-work-item, …)', value: 'commands', checked: true },
         { name: 'MCP Servers (Playwright, DB, Teams, Stripe, Azure, Azure DevOps)', value: 'mcp', checked: true },
         { name: 'Settings (hook registration)', value: 'settings', checked: true },
         { name: 'CLAUDE.md Workflow Section', value: 'workflow', checked: true },
@@ -265,7 +337,7 @@ async function main() {
         );
       }
     }
-    await removeRetiredAgents(agentsDir, RETIRED_PROJECT_AGENTS);
+    await removeRetiredFiles(agentsDir, RETIRED_PROJECT_AGENTS);
   }
 
   // ── Hooks ─────────────────────────────────────────────────────────────
@@ -301,6 +373,7 @@ async function main() {
         );
       }
     }
+    await removeRetiredFiles(cmdsDir, RETIRED_COMMANDS);
   }
 
   // ── MCP Servers (interactive selection) ───────────────────────────────
@@ -515,13 +588,16 @@ async function main() {
       'utf8'
     );
 
+    // Delimited so a re-install replaces only the kit's own section.
+    const workflowBlock = `${workflowContent.trimEnd()}\n\n${WORKFLOW_END_MARKER}\n`;
+
     const sensitiveDataPolicy = `## SENSITIVE DATA — MANDATORY RULE
 
 **NEVER query, display, read, grep, or expose sensitive PII fields from the database or codebase — even if the values are encrypted.** Blocked fields: TIN, SSN, EIN, TaxId, BankAccountNumber, RoutingNumber, and any \`Encrypted*\` variants. Always use explicit inclusion projections listing only non-sensitive fields. Direct users to the application UI for sensitive data access.
 `;
 
     if (!await fs.pathExists(claudeMdPath)) {
-      await fs.writeFile(claudeMdPath, `# ${basename(targetDir)}\n\n${sensitiveDataPolicy}\n${workflowContent}`);
+      await fs.writeFile(claudeMdPath, `# ${basename(targetDir)}\n\n${sensitiveDataPolicy}\n${workflowBlock}`);
       console.log(chalk.green('  ✓ Created CLAUDE.md with sensitive data policy and workflow'));
     } else {
       let existing = await fs.readFile(claudeMdPath, 'utf8');
@@ -547,8 +623,22 @@ async function main() {
       if (existing.includes('Claude Kit Workflow') || existing.includes('Care Solutions AI Workflow')) {
         // Check whether the existing workflow section matches the current template.
         // If it does, nothing to do. If not, replace it (auto in --all, prompt otherwise).
-        const cleaned = existing.replace(/\n## (?:Claude Kit Workflow|Care Solutions AI Workflow)[\s\S]*$/, '').trimEnd();
-        const expected = `${cleaned}\n\n${workflowContent}`;
+        const split = splitWorkflowSection(existing);
+        const { head, preserved, recovered } = split;
+        const expected = preserved
+          ? `${head}\n\n${workflowBlock}\n${preserved}\n`
+          : `${head}\n\n${workflowBlock}`;
+        if (recovered && preserved) {
+          const names = (preserved.match(/^## .*$/gm) || []).map((h) => h.replace(/^##\s*/, ''));
+          console.log(
+            chalk.yellow(
+              `  ! Kept project content found below the workflow section: ${names.join(', ') || 'unlabelled section'}`
+            )
+          );
+          console.log(
+            chalk.gray('    It now sits after the end marker, so future updates will leave it alone.')
+          );
+        }
         if (existing.trim() === expected.trim()) {
           console.log(chalk.gray('  = Workflow section up to date'));
         } else if (installAll) {
@@ -569,7 +659,7 @@ async function main() {
           }
         }
       } else {
-        await fs.appendFile(claudeMdPath, `\n\n${workflowContent}`);
+        await fs.appendFile(claudeMdPath, `\n\n${workflowBlock}`);
         console.log(chalk.green('  ✓ Workflow appended to CLAUDE.md'));
       }
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.56",
+  "version": "2.1.58",
   "description": "Claude Code starter kit for Azure DevOps teams — agents, hooks, MCP servers, slash commands, and end-to-end work item → PR → release → deploy workflow automation",
   "type": "module",
   "bin": {

package/templates/agents/global/qa.md

@@ -0,0 +1,136 @@
+---
+name: qa
+description: Regression-tests a work item in a real browser via Playwright MCP. Signs in with test-account credentials from environment variables, exercises the affected screens, and reports pass/fail with evidence. Read-only against the codebase and against Azure DevOps.
+tools: Read, Glob, Grep, Bash, mcp__playwright__browser_navigate, mcp__playwright__browser_navigate_back, mcp__playwright__browser_snapshot, mcp__playwright__browser_find, mcp__playwright__browser_click, mcp__playwright__browser_type, mcp__playwright__browser_fill_form, mcp__playwright__browser_select_option, mcp__playwright__browser_press_key, mcp__playwright__browser_hover, mcp__playwright__browser_wait_for, mcp__playwright__browser_resize, mcp__playwright__browser_handle_dialog, mcp__playwright__browser_console_messages, mcp__playwright__browser_network_requests, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_tabs, mcp__playwright__browser_close
+disallowedTools: Write, Edit
+model: sonnet
+---
+
+# QA Agent
+
+You test a work item in a real browser against a running environment, then report what you found. You are **read-only** against the codebase and you have **no Azure DevOps tools** — you never post a comment, never change a work item state, and never ask the caller a question. You return one report; the main loop does the writing.
+
+## Tools you deliberately do not have
+
+Do not work around these. If a check genuinely needs one, report the check as `NOT TESTABLE` and say which capability was missing.
+
+| Missing | Why it was withheld |
+|---|---|
+| `browser_evaluate`, `browser_run_code_unsafe` | Arbitrary page JS could read any DOM value and defeat every rule below. The omission is the enforcement. |
+| `browser_network_request` (singular) | It returns full request and response bodies — the likeliest route for a TIN or SSN into a transcript. Use `browser_network_requests` (plural), which gives method, URL, and status. |
+| `browser_file_upload`, `browser_drag`, `browser_drop` | Not needed by the checklist below. |
+| Any `mcp__azure-devops__*` tool | You must be structurally unable to advance a work item. |
+| `Write`, `Edit` | You test the app; you never change the code. |
+
+## What you are given
+
+The caller passes a brief containing: the work item id, title, type and state; the target environment name and its App URL (and API URL if known); a **baseline** environment URL for differential re-checks; the sign-in descriptor; the **names** of the environment variables holding the test account credentials; the ordered list of screens with each screen's changed files; and the acceptance criteria.
+
+You are never given a password. You read it yourself.
+
+## Signing in
+
+1. Read the credentials with Bash — `printenv <USERNAME_VAR>` and `printenv <PASSWORD_VAR>`. If either is empty, stop immediately and report `BLOCKED — <VAR> is not set`.
+2. `browser_navigate` to the App URL, then to the login route from the sign-in descriptor if you are not redirected there.
+3. Fill both fields in **one** `browser_fill_form` call, then submit. One call, not two `browser_type` calls — the credential should appear once.
+4. Confirm you are signed in by finding an element that only exists when authenticated (the descriptor names the landing route). If you land back on the login form, stop and report `BLOCKED — sign-in failed`. Do not retry more than once; a second failure on a shared environment risks locking the account.
+5. If the browser is redirected to an external identity provider (`login.microsoftonline.com` or similar) or an MFA prompt appears, stop and report `BLOCKED — sign-in requires MFA/SSO, cannot run unattended`.
+
+**Never** echo, log, repeat, screenshot, or include either credential value in your report. Never write one to a file.
+
+## Regression Method
+
+Work the screens in the order given. For each one, run **every** row of the checklist — the acceptance criteria are additional, not a substitute. Record a result per row before moving on.
+
+| # | Test | How | Expected |
+|---|------|-----|----------|
+| 1 | Route loads | `browser_navigate` to the route | Renders. No error boundary, no blank region |
+| 2 | Deep link | Navigate straight to the URL rather than clicking through | Route rehydrates; no bounce to login, no 404 |
+| 3 | Console clean | `browser_console_messages` | No uncaught errors. React key/prop warnings are noted, not failed |
+| 4 | Network clean | `browser_network_requests` | No 4xx/5xx to the API. Record `METHOD path → status` only |
+| 5 | Data or empty state | `browser_snapshot` | Rows render, **or** an explicit empty-state message. A blank region is a **fail** |
+| 6 | Filters, search, sort | Exercise each control once | Result set changes, no error, control reflects its state |
+| 7 | Pagination | Next, then previous | Content changes; the indicator tracks |
+| 8 | Form — invalid | Submit each form empty | **Inline** validation; nothing submitted |
+| 9 | Form — valid | Submit valid data | Success indication; the list or detail updates |
+| 10 | Form — cancel | Fill, then cancel | No mutation; returns to the prior view |
+| 11 | Dialogs | Open and close each modal and row action | Opens, closes, focus returns. A native `window.confirm`/`alert`/`prompt` is a **fail** |
+| 12 | Back button | Browser back after a mutation | Lands somewhere coherent; no stale or duplicated data |
+| 13 | Responsive | `browser_resize` to 1440, then 768 | No overlap, no clipped controls, no horizontal scroll |
+| 14 | Role gating | If a second role's credentials are named in the brief, sign in as it and revisit | Restricted controls are **absent**, not present-and-erroring |
+
+Then one explicit test per acceptance criterion: `PASS`, `FAIL`, or `NOT TESTABLE (reason)`.
+
+**Retry once before recording a failure**, using `browser_wait_for` on the element you expect rather than a fixed delay. A cold-start 502 on a Dev App Service is the most common false failure. If it passes on the retry, record `FLAKY`, not `PASS`.
+
+**Differential re-check.** For each failure, if the brief gave you a baseline URL, re-run *only* the failing steps there. Fails on the baseline too → the issue predates this story. Passes on the baseline → this story introduced it. Report the outcome per failure; do not draw the final conclusion, the caller attributes it. Cap at 5 re-checks and say if you hit the cap.
+
+## Write Safety
+
+You are operating on a shared environment with real integrations. A wrong click here sends real money or real email.
+
+- Prefer creating a new record over editing an existing one.
+- Prefix everything you create with `QA AB#<id>` so a human can find it.
+- **Never delete a pre-existing record.**
+- **Never** fire a bulk or destructive action, a payment submission or settlement, a batch approval, a 1099 or tax-document generation, an export-all, or anything that emails or notifies a real person.
+- If a screen can only be exercised by a destructive action, record `NOT TESTABLE — destructive` and move on.
+- List everything you created in the report.
+
+## Sensitive Data
+
+The project's `CLAUDE.md` forbids exposing TIN, SSN, EIN, TaxId, BankAccountNumber, RoutingNumber, and any `Encrypted*` variant — including encrypted values. On a real screen these are rendered, so:
+
+- **Never transcribe a field value** from a snapshot. Report only *present*, *populated*, *empty*, *masked*, or *validation shown*.
+- Prefer `browser_find` over a full `browser_snapshot` when you only need to check one element on a screen that displays protected fields.
+- **Never screenshot a screen showing a protected value.** Screenshots are failure evidence only, saved outside the repo, and referenced by local path — they are never attached to a work item.
+- If a screen exists to display protected data, test its structure, validation, and navigation, and record the content checks as `NOT TESTABLE — sensitive screen`.
+- If a tool result comes back blocked by the sensitive-data hook, do not retry it. Record `BLOCKED — protected fields on screen, manual QA required` and move to the next screen.
+
+## Report Format
+
+```markdown
+## QA — AB#{id}: {title}
+{type} · {state} · {environment} — {app-url}
+Signed in as: {role} (from {USERNAME_VAR}) — value not shown
+Screens tested: {n} · {route list}
+
+### Acceptance Criteria
+| # | Criterion | Result | Evidence |
+|---|-----------|--------|----------|
+| 1 | {criterion} | PASS | {route} — {what you observed} |
+
+### Screen Regression — {route}
+| # | Test | Steps | Expected Result | Result |
+|---|------|-------|-----------------|--------|
+| 1 | Route loads | Navigate to {route} | Renders, no error boundary | PASS |
+
+### Failures
+#### F1 — {short title}
+- Screen: {route}
+- Steps: 1. … 2. … 3. …
+- Expected: {what should happen}
+- Actual: {what happened}
+- Evidence: console `{first line}` | network `POST /api/x → 500`
+- Differential: {passes on baseline | fails on baseline too | not checked — {reason}}
+- Touches this story's changed files: {yes — <file> | no}
+- Screenshot: {local path}
+
+### Not testable
+- {check} — {why}
+
+### Test data created
+- {entity} "QA AB#{id} — …" (id {x})
+
+**Sweep status:** COMPLETE | INCOMPLETE — {what was not reached}
+```
+
+## Rules
+
+- Never modify any file. Never post anything anywhere. Never ask the caller a question — report and stop.
+- Never change a work item state. You have no tool that can, and that is deliberate.
+- Never echo a credential value, and never include one in the report.
+- Never transcribe a protected field's value. See Sensitive Data.
+- A control you could not find is a **FAIL**, never a PASS. "I didn't see it" is not "it works."
+- If you run out of room and cannot finish the screens, report `INCOMPLETE` and name what you did not reach. A truncated sweep must never read as a pass.
+- Report what you observed, not what you expected the code to do. You are testing the deployed build, not the source.
+- Close the browser (`browser_close`) when you are done.

package/templates/commands/cherry-pick.md

@@ -233,4 +233,4 @@ Cherry-pick is deployed to {environment} (pipeline {build-number}, succeeded).
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track` will flag the lag later.

package/templates/commands/deploy-release.md

@@ -292,7 +292,7 @@ Release #{N} is on {environment} (pipeline {build-number}, succeeded).
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status release {N}` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track release {N}` will flag the lag later.
 
 ## Step 11: Notify Team (if Teams MCP is configured)
 

package/templates/commands/promote.md

@@ -227,4 +227,4 @@ Report both fields, so a wrong assignment is easy to put back:
 Next: {the human step — "QA tests on Test and sets Ready for Staging" / "stakeholders verify on Staging and set Ready to Deploy" / "verify in production, then Close"}.
 ```
 
-If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/status` will flag the lag later.
+If the user said `stop watching`, or an update fails, leave the rest alone, say exactly which items were and were not updated, and note that `/track` will flag the lag later.

package/templates/commands/qa.md

@@ -0,0 +1,353 @@
+Regression-test a work item in a real browser against a running environment. Usage: `/qa <work-item-id> [environment] [--role=<role>] [--screens=/a,/b]`
+
+Parse `$ARGUMENTS` to extract the work item ID. Accept formats like `AB#1234`, `#1234`, or just `1234`. If no ID is provided, report the error and stop.
+
+- **Environment**: optional — `local`, `dev`, `test`, or `staging`. Defaults to `dev`.
+- **`--role=<role>`**: optional — which test account to sign in as. Defaults to the row marked `Default` in the Environment URLs table, else the first row.
+- **`--screens=/a,/b`**: optional — skip the affected-screen scoping in Step 5 and test exactly these routes.
+
+**`prod` and `production` are refused.** An unattended regression pass signs in and clicks through live member data. Say so and stop.
+
+## Step 1: Fetch the Work Item
+
+Read the work item from Azure DevOps using the project from the current repo's CLAUDE.md configuration. Expand with `relations` so PR links are included.
+
+If the work item is not found, report the error and stop.
+
+Capture: id, title, type, state, and any linked Pull Request artifacts. Then extract the requirements **by type** — the field differs and getting this wrong silently produces an empty test plan:
+
+- **User Story / Feature** → `Microsoft.VSTS.Common.AcceptanceCriteria`.
+- **Bug / Hot Fix** → `Microsoft.VSTS.TCM.ReproSteps`. Neither type has an acceptance criteria field.
+
+Treat all of these as **empty**: `""`, whitespace, `<div></div>`, `<p><br></p>`, and the process-template placeholder `💡 Tip: Add "@serena rewrite" to Description for AI suggestions  Define acceptance criteria: - [ ]  - [ ]  - [ ]`. That last one is the trap — it is non-empty, so a length check says the opposite of the truth.
+
+If the type's field is empty, fall back to `System.Description` and note `AC read from Description — misfiled` in the report. If both are empty, **continue anyway** and report `Acceptance criteria: none — regression sweep only`. The screen sweep is the point of `/qa`; it does not need acceptance criteria.
+
+Download and view every embedded `<img>` in the description or criteria with WebFetch — mockups define the expected layout.
+
+## Step 2: Resolve the Environment
+
+Read the **Environment URLs** table from the current repo's `CLAUDE.md`:
+
+```
+| Branch | Environment | App URL | API URL |
+|--------|------------|---------|---------|
+| (none) | local | http://localhost:5173 | https://localhost:7001 |
+| dev | Dev | https://dev.myapp.example.com | https://dev.api.myapp.example.com |
+| test | Test | https://test.myapp.example.com | https://test.api.myapp.example.com |
+```
+
+Capture the target row's App URL and API URL, the `**Sign-in:**` descriptor, the test-account table, and — for the differential re-check in Step 7 — the **App URL of the row immediately below the target**. That row serves the pre-change build, which is what lets a failure be attributed rather than guessed at.
+
+If the section is missing, or the target environment has no row, report:
+
+```
+AB#{id}: {title}
+
+This project has no `## Environment URLs` section in CLAUDE.md, so I don't know where
+the {environment} app is hosted. /qa cannot run.
+
+Add this to CLAUDE.md — **above the `## Claude Kit Workflow` heading**, because
+everything below that heading is replaced on the next kit update:
+
+## Environment URLs
+
+| Branch | Environment | App URL | API URL |
+|--------|------------|---------|---------|
+| dev | Dev | https://… | {inferred, or …} |
+| test | Test | https://… | {inferred, or …} |
+
+**Sign-in:** form at `/login`. Signed-in landing: `/dashboard`.
+
+**Test accounts** — values live in environment variables; never write a password here.
+
+| Role | Username variable | Password variable | Default |
+|------|-------------------|-------------------|---------|
+| Admin | `{PROJECT}_QA_ADMIN_USERNAME` | `{PROJECT}_QA_ADMIN_PASSWORD` | yes |
+
+Want me to draft it with the API URLs filled in from your .env files? (yes / no)
+```
+
+The API URLs can be inferred from the client's per-environment env files (`Client/.env.development`, `.env.testing`, …), which already carry the API base URL. Grep for the single base-URL key and echo **only that value** — never print the contents of those files.
+
+For `dev`, `test`, and `staging` also read the **Pipeline Configuration** table; the two tables are joined on the branch column, and a mismatch is a configuration error worth reporting. If Pipeline Configuration is missing, report that the project has no pipeline configuration in `CLAUDE.md` and stop.
+
+## Step 3: Gate — Is a Browser Available?
+
+Two checks, both required:
+
+1. `.mcp.json` contains a `playwright` server. It is opt-in at install time, so a project that unchecked it has no browser.
+2. `mcp__playwright__browser_navigate` is present in this session's tools. The server can be configured and still have failed to start.
+
+```
+AB#{id}: {title}
+
+Playwright MCP isn't {configured for this project | connected in this session},
+so I can't open a browser. /qa cannot run.
+
+{To add it:  npx @chris1807/claude-kit init . --all --db=<your-db>  and check
+ "Playwright (browser testing)", then restart the session.}
+{It's in .mcp.json but didn't connect. Restart the session; if it still fails, the
+ browser binaries may be missing — npx playwright install chromium}
+```
+
+## Step 4: Gate — Credentials and Sign-in Method
+
+Resolve the role: `--role=<x>`, else the row marked `Default`, else the first row. Then check **presence only**. Never read a credential value in this step — the agent does that, inside its own transcript:
+
+```bash
+for v in {PROJECT}_QA_ADMIN_USERNAME {PROJECT}_QA_ADMIN_PASSWORD; do
+  [ -n "${!v}" ] && echo "$v SET" || echo "$v MISSING"
+done
+```
+
+Any `MISSING`:
+
+```
+AB#{id}: {title}
+
+Missing test-account credentials for the {role} role:
+  - {PROJECT}_QA_ADMIN_PASSWORD
+
+/qa signs in unattended, so these must be exported before it can run:
+
+  export {PROJECT}_QA_ADMIN_USERNAME="qa-admin@example.com"
+  export {PROJECT}_QA_ADMIN_PASSWORD="…"
+
+Use a throwaway QA account with least privilege, never a personal login. Never put
+the password in CLAUDE.md, .env, or any file in the repo.
+```
+
+If the `**Sign-in:**` descriptor says the app uses SSO or Entra ID with MFA, stop here:
+
+```
+{environment} sign-in goes through {provider} with MFA, which can't be completed
+unattended. /qa can't test this project until a cloud-only, MFA-exempt QA account
+exists — or run the checks by hand against {app-url}.
+```
+
+## Step 5: Gate — Is the Code Actually There?
+
+### For `dev`, `test`, `staging`
+
+Being merged is not being deployed. Two separate facts, both required.
+
+**5a. Every commit is on the branch.** Same method as `/where`:
+
+1. `git fetch origin <target-branch>` and `git fetch origin <baseline-branch>`.
+2. Find the item's commits three ways and dedupe by SHA: linked PRs → `lastMergeCommit`; `git log --all --grep="AB#<id>\b" --grep="#<id>\b" -i --format=%H`; branch names matching `*AB#<id>-*`.
+3. For each commit: `git merge-base --is-ancestor <commit> origin/<target-branch>`.
+
+**`/qa` requires all of them.** A partial match is the cherry-pick case `/where` reports as `1 of 2`, and testing half a story produces failures that are really missing code — a FAIL comment that blames a developer for a deployment mistake:
+
+```
+AB#{id}: {title}
+
+Not fully deployed to {environment} — 1 of 2 commits present.
+
+Present on origin/{branch}:
+  a1b2c3d  AB#{id}: add export button
+Missing:
+  e4f5g6h  AB#{id}: fix CSV encoding
+
+This is a partial cherry-pick. Get the rest onto {branch} (`/promote` or
+`/cherry-pick AB#{id} {environment}`), then re-run. `/where AB#{id}` shows the
+full picture.
+```
+
+No commits at all → `No commits found referencing this work item — nothing to test.` and stop.
+
+**5b. The pipeline that deployed them is green.** Same method as `/promote`:
+
+1. Take the merge time of the item's newest commit on the target branch.
+2. Look up the branch's pipeline ID(s) in Pipeline Configuration. Poll `pipelines_build` for runs on `refs/heads/<target-branch>` **queued at or after that time**, matching the merge commit where the run exposes it, and **capture each run's id**. A run that completed before the merge is not this deployment — never take "the latest run on the branch".
+3. Every pipeline on the branch (API **and** client) must be `succeeded`.
+4. **Never block on a foreground `sleep`.** If a run is still going, watch its **run id** with `Monitor` or Bash `run_in_background`, and match failures as well as success.
+
+| Result | Action |
+|---|---|
+| all `succeeded` | Proceed. Record `{pipeline} run {id}` for the report. |
+| `inProgress` | `The {environment} deployment is still running ({pipeline} run {id}). I'm watching it and will start testing when it's green. Say \`stop\` to cancel.` |
+| `partiallySucceeded` | `Not green — {stage} failed in run {id}. Test anyway? (proceed / hold)` and record it in the report. |
+| `failed` / `canceled` | Stop. `The {environment} deployment failed — run {id}, stage {stage}: {log link}. The app may not contain AB#{id} at all.` |
+| no run after the merge | Stop. `The commits are on {branch} but no CD run was queued after the merge. Nothing deployed AB#{id}.` |
+
+### For `local`
+
+No commit or pipeline gate — you are testing the working tree. Instead, probe the local App URL. If nothing answers:
+
+```
+Nothing is listening on {local-url}.
+
+/qa doesn't manage dev servers — start the app first:
+  {the project's start commands, e.g. `dotnet run --project src/API` and `npm run dev`}
+
+Then re-run /qa AB#{id} local.
+```
+
+Also check whether the working tree actually contains the item's commits (`git log --grep="AB#<id>"` on `HEAD`). If not, warn but continue — the user may be mid-implementation, which is a legitimate reason to run `/qa local`.
+
+## Step 6: Scope the Affected Screens, Then Get Approval
+
+Skip to the approval block if `--screens=` was given.
+
+1. **Changed files** — union of `git show --name-only --format= <sha>` over the item's commits, cross-checked against the linked PR's iteration changes. If they disagree, prefer the union and note it.
+2. **Partition** into frontend (`*.tsx`, `*.ts`, `*.css`, `*.scss` under the client project found via `Glob("**/package.json")`), backend (`*.cs`), and other.
+3. **Find the router** — `Glob("**/src/routes/**", "**/src/{App,Routes,router}.{tsx,ts}")`, then grep for `<Route`, `createBrowserRouter`, `path:`, `lazy(` to build a `{path → component file}` map.
+4. **Reverse-import walk, max 4 hops.** For each changed frontend file, grep the client `src/` for importers of its basename or path, and walk upward until you reach a file that is a router element. The union of reached routes is the candidate screen list. Keep the hop chain — it is the evidence for *why* a screen is in scope.
+5. **Backend endpoints → screens.** For each changed `*.cs` controller, read its route attributes (`[HttpGet("…")]`, `[Route("…")]`) to get endpoint paths, grep the client for each path to find the calling component, and feed those components back into step 4. This is what catches a backend-only story that still has a UI surface.
+6. **Name matching** — match nouns from the title and criteria against route paths and nav labels. Union in.
+7. **Confidence:**
+   - 1–6 routes reached by a clean import chain → proceed, and list them.
+   - More than 6 → present them all, test the 6 with the most changed files, say plainly that you are capping, and mention `--screens=`.
+   - **0 routes → stop and ask.** Never silently test nothing:
+     ```
+     I couldn't map the changed files to any screen. Changed: {n} frontend, {m} backend files.
+     {reason: no router found | only shared utilities changed | backend-only, no client caller found}
+
+     Which screens should I test?   /qa AB#{id} --screens=/payments,/invoices
+     ```
+
+Known blind spots, worth saying out loud in the report when they apply: computed `import()`, barrel-file re-exports that flatten the graph, and theme, design-token, or i18n changes that touch every screen. For a genuinely global change, say so and cap at the 4 highest-traffic routes rather than claiming to be exhaustive.
+
+Then present the plan and **wait**:
+
+```
+## QA plan — AB#{id} on {environment}
+
+Work item: {title} ({type}, {state})
+Target: {environment} — {app-url}
+Role: {role} ({USERNAME_VAR})
+Build: {n} of {n} commits on `{branch}`, {pipeline} run {id} green
+Baseline for attributing failures: {baseline-env} — {baseline-url}
+
+Screens the story touched:
+| Screen | Route | Why |
+|--------|-------|-----|
+| Payment History | /payments/history | PaymentHistory.tsx changed |
+| Export dialog | /payments/history | new component |
+| Payment detail | /payments/:id | calls the changed endpoint |
+
+Full regression of these {n} screens — every control, not just the new behaviour —
+plus {m} acceptance criteria, console errors, and failed network calls.
+
+This will create test data on {environment}, prefixed `QA AB#{id}`.
+
+Open the browser and run it? (yes / edit the screen list / cancel)
+```
+
+## Step 7: Run It, Then Attribute Every Failure
+
+Delegate to the **qa** agent with a brief containing: the work item id, title, type and state; the target App and API URLs; the baseline App URL; the sign-in descriptor; the **names** of the credential variables (never the values — say "they are set, read them yourself, never echo them"); the ordered screen list with each screen's changed files; and the criteria. Above 3 screens, invoke it once per batch so a long sweep can't exhaust its context mid-run.
+
+When the report comes back, sort every failure using three filters, in order:
+
+1. **Blame filter** — if the failing surface is not in the story's changed-file set and no changed file reaches it in the import walk, it is **pre-existing**. State the reasoning.
+2. **Differential result** — the agent re-ran failing steps against the baseline environment, which serves the pre-change build. Fails on both → **pre-existing**; passes on the baseline → **regression introduced by this story**, which is the strongest evidence a FAIL can carry. Caveat that seed-data and config drift between environments can confound this.
+3. **Flake filter** — the agent retried once. A pass on retry is `FLAKY`, not a failure.
+
+Only filter 1's output can drive a `FAIL` verdict. A run that finds nothing but pre-existing issues is `PASS WITH FINDINGS` — do not let old bugs turn into this story's failure.
+
+## Step 8: Report
+
+```
+QA — AB#{id}: {title}
+{type} · {state} · {environment} — {app-url}
+Build: {pipeline} run {id} · succeeded · commit {sha7}
+Signed in as: {role} (from {USERNAME_VAR}) — value not shown
+Screens tested: {n} · {route list}
+
+## Acceptance Criteria
+| # | Criterion | Result | Evidence |
+|---|-----------|--------|----------|
+| 1 | {criterion} | PASS | {route} — {observation} |
+| 2 | {criterion} | FAIL | see R1 |
+| 3 | {criterion} | NOT TESTABLE | {reason} |
+
+## Screen Regression — {route}
+| # | Test | Steps | Expected Result | Result |
+|---|------|-------|-----------------|--------|
+| 1 | Route loads | Navigate to {route} | Renders, no error boundary | PASS |
+
+## Regressions (attributable to AB#{id}) — {n}
+### R1 — {short title}
+- Screen: {route}
+- Steps: 1. … 2. … 3. …
+- Expected: {x}. Actual: {y}
+- Evidence: console `{line}` | network `POST /api/x → 500`
+- Differential: passes on {baseline-env} — introduced by this story
+- Screenshot: {local path} — local only, not attached to the work item
+
+## Pre-existing issues (found, not caused by AB#{id}) — {n}
+- {route} — {issue}. Also fails on {baseline-env}. Recommend a separate Bug.
+
+## Not testable — {n}
+- {check} — {why}
+
+## Test data created on {environment}
+- {entity} "QA AB#{id} — …" (id {x}) — left in place for review
+
+Verdict: PASS | PASS WITH FINDINGS | FAIL | INCOMPLETE
+Work item state unchanged — `Ready for Staging` is yours to set.
+```
+
+## Step 9: Comment on the Work Item
+
+Draft the comment, preview it, and **wait**. Before drafting, check the item's existing comments for a prior `/qa` result on the same commit SHA — three runs should not leave three near-identical comments. If one exists: `A /qa comment already exists for commit {sha7} ({date}). Post an updated one anyway? (yes / skip)`.
+
+> **Why this comment is not the redundant kind.** `/rework` deliberately posts no summary comment, because the commits and the diff are already the record of what changed. A QA result duplicates nothing: it is the outcome of *executing* the software at a specific build in a specific environment, which exists in no diff, no PR, and no pipeline log. It is precisely the evidence the person who later sets `Ready for Staging` needs. Don't delete this step by applying the `/rework` rule uniformly.
+
+The body, as HTML (Azure DevOps renders HTML in comments):
+
+```html
+<b>Automated QA — {verdict}</b> · {environment} · {date}<br>
+Build: {pipeline} run {id} ({result}) · commit {sha7}<br>
+Screens tested: {route list}<br>
+Signed in as: {role} test account<br><br>
+
+<b>Acceptance criteria — {x} of {y} pass</b>
+<ul>
+  <li>✅ {criterion}</li>
+  <li>❌ {criterion} — {one-line reason}</li>
+  <li>➖ {criterion} — not testable: {reason}</li>
+</ul>
+
+<b>Regressions introduced by this story ({n})</b>
+<ol>
+  <li><b>{title}</b> — {route}. Steps: {1-2-3}. Expected {x}, got {y}.
+      Passes on {baseline-env}, so it came in with this story.</li>
+</ol>
+
+<b>Pre-existing issues found ({n})</b> — not caused by this story; also fail on {baseline-env}.
+<ul><li>{route} — {issue}. Separate Bug recommended.</li></ul>
+
+<b>Test data created on {environment}</b>
+<ul><li>{entity} "QA AB#{id} — …"</li></ul>
+
+<hr>
+<i>Posted by <code>/qa</code>. Work item state unchanged — <b>Ready for Staging</b> remains
+a human QA gate. No screenshots and no field values are attached, per the sensitive-data
+policy.</i>
+```
+
+A `PASS` collapses to the header, the criteria list, the test-data list, and the footer.
+
+Then:
+
+```
+QA drafted — nothing has been posted to AB#{id} yet.
+
+## Work item comment
+{the full body as it will appear}
+
+Reply with one of:
+- "approve" → post the comment exactly as shown
+- "skip"    → post nothing (the report above is yours to keep)
+- "edit <section>: <new text>" → revise, then I'll re-preview before posting
+
+Wait for my response. Never post to the work item until I reply "approve".
+```
+
+On `approve`, post exactly one comment via `mcp__azure-devops__wit_work_item_comment_write`.
+
+That's it. `/qa` never changes the work item's state — not `Ready for Testing`, not `Ready for Staging`, not anything. `Ready for Staging` is the human QA gate and no command in this kit sets it. `/qa` also never merges, pushes, creates a PR, triggers a pipeline, edits code, attaches a screenshot to the work item, or transcribes a field value from a screen. It reads, it clicks, it reports.

package/templates/commands/{status.md → track.md}

@@ -1,4 +1,4 @@
-Check the status of a release, pipeline, environment, or work item. Usage: `/status <target>`
+Check the status of a release, pipeline, environment, or work item. Usage: `/track <target>`
 
 Parse `$ARGUMENTS` to determine what to check:
 - **Release**: "release 24" or "r24" → show release status
@@ -23,7 +23,7 @@ Work item states track environments. Use this to spot **state lag** — an item
 
 `Ready for Staging` and `Ready to Deploy` are human sign-offs and are never "lag". Only User Stories, Bugs, and Hot Fixes are checked — Features and Tasks have no environment state.
 
-## If Release (e.g., `/status release 24`):
+## If Release (e.g., `/track release 24`):
 
 Query all work items tagged `release-{N}` or in the `Release #{N}` iteration. For each, find which environment branches contain its commits (`repo_search_commits` with `includeWorkItems: true`, or `git merge-base --is-ancestor`).
 
@@ -51,7 +51,7 @@ Catch these up? (yes/no)
 
 If the user says yes, set `System.State` on each lagging item to the expected state via `wit_update_work_item` — never backward, never on a Feature or Task — and report `Was → Now`.
 
-## If Pipeline (e.g., `/status pipeline` or `/status build`):
+## If Pipeline (e.g., `/track pipeline` or `/track build`):
 
 Query recent builds for each pipeline in the Pipeline Configuration table.
 
@@ -67,7 +67,7 @@ Query recent builds for each pipeline in the Pipeline Configuration table.
 
 A run on `main` would be unexpected — `main` has no pipeline. If one appears, say so.
 
-## If Work Item (e.g., `/status AB#4521`):
+## If Work Item (e.g., `/track AB#4521`):
 
 Read the work item from Azure DevOps and show its full status, including which environment branches contain its commits.
 
@@ -102,7 +102,7 @@ State `Staging` matches the furthest environment. ✓
 
 If the state lags the furthest environment, flag it and offer to catch it up as in the release view.
 
-## If Environment (e.g., `/status staging`):
+## If Environment (e.g., `/track staging`):
 
 Map the name to its branch through the Pipeline Configuration table. Show the last deployment and what's currently there.
 
@@ -123,9 +123,9 @@ Map the name to its branch through the Pipeline Configuration table. Show the la
 {count} commits on `test` are not on `staging` — run `/promote test staging` or `/deploy-release <N> staging`.
 ```
 
-`/status main` is allowed but reports "compare branch — nothing deploys from main" and lists what's on `main` that hasn't been promoted to `dev`.
+`/track main` is allowed but reports "compare branch — nothing deploys from main" and lists what's on `main` that hasn't been promoted to `dev`.
 
-## If No Argument (e.g., `/status`):
+## If No Argument (e.g., `/track`):
 
 Show a high-level overview.
 

package/templates/commands/where.md

@@ -88,6 +88,6 @@ Open PRs:
 - PR #<n> → <target branch> (<status>)
 ```
 
-Finally, compare the work item's state with its furthest environment (`dev` → `Ready for Testing`, `test` → `Testing`, `staging` → `Staging`, `prod` → `Deployed`). If the state lags — e.g. commits on `staging` but the item is still `Testing` — add one line: `⚠ State lags environment: Testing, expected at least Staging — /status AB#<id> can catch it up.`
+Finally, compare the work item's state with its furthest environment (`dev` → `Ready for Testing`, `test` → `Testing`, `staging` → `Staging`, `prod` → `Deployed`). If the state lags — e.g. commits on `staging` but the item is still `Testing` — add one line: `⚠ State lags environment: Testing, expected at least Staging — /track AB#<id> can catch it up.`
 
 That's it — read-only. Do not modify branches, push, create PRs, or change states.

package/templates/hooks/sensitive-data-output-blocker.sh

@@ -1,12 +1,29 @@
 #!/bin/bash
-# Sensitive Data Output Blocker Hook (PostToolUse - Bash, Read, Grep, MCP DB tools)
-# Scans tool output for sensitive PII field names that may have been returned
-# by broad database queries, file reads of seed/dump data, or grep results.
+# Sensitive Data Output Blocker Hook (PostToolUse - Bash, Read, Grep, Playwright, MCP DB tools)
+# Scans tool output for sensitive PII that may have been returned by broad database
+# queries, file reads of seed/dump data, grep results, or a rendered browser page.
 # Exit code 2 = BLOCK (prevents the output from being used).
+#
+# Two pattern sets, chosen by tool:
+#   * Database / file / grep tools -> match sensitive field NAMES. A query or a seed
+#     file that names TIN or SSN at all is already returning data it shouldn't.
+#   * Playwright (mcp__playwright__*) -> match a field name only when followed by
+#     something VALUE-shaped. A rendered screen legitimately shows "SSN:" as a form
+#     label, and blocking on the label alone would make every such screen untestable
+#     and send /qa into a retry loop.
 
 # Read the tool result from stdin
 INPUT=$(cat)
 
+# Extract the tool name so the pattern set can be chosen below
+TOOL=$(echo "$INPUT" | python3 -c "
+import sys, json
+try:
+    print(json.load(sys.stdin).get('tool_name', ''))
+except:
+    pass
+" 2>/dev/null)
+
 # Extract output from any tool type (Bash stdout, Read content, Grep results, MCP results)
 OUTPUT=$(echo "$INPUT" | python3 -c "
 import sys, json
@@ -38,24 +55,45 @@ if [ -z "$OUTPUT" ]; then
     exit 0
 fi
 
-# Check if output contains sensitive field names as keys (indicating PII was returned)
-# These patterns match field names in JSON documents, MongoDB output, C# properties, etc.
-SENSITIVE_PATTERNS=(
-    # JSON/MongoDB style: "TIN": or 'TIN':
-    '"(TIN|Tin|TaxId|TaxIdentificationNumber|EIN|SSN|SocialSecurityNumber|EncryptedTin|EncryptedSSN|EncryptedTaxId|BankAccountNumber|AccountNumber|RoutingNumber)"\s*:'
-    # C# property style: .TIN = or .TaxId =
-    '\.(TIN|TaxId|TaxIdentificationNumber|EIN|SSN|SocialSecurityNumber|EncryptedTin|EncryptedSSN|EncryptedTaxId|BankAccountNumber|AccountNumber|RoutingNumber)\s*='
-    # YAML/config style: TIN: (start of line or after whitespace)
-    '(^|\s)(TIN|TaxId|TaxIdentificationNumber|EIN|SSN|SocialSecurityNumber|EncryptedTin|EncryptedSSN|EncryptedTaxId|BankAccountNumber|AccountNumber|RoutingNumber):\s'
-)
+FIELDS='TIN|Tin|TaxId|TaxIdentificationNumber|EIN|SSN|SocialSecurityNumber|EncryptedTin|EncryptedSSN|EncryptedTaxId|BankAccountNumber|AccountNumber|RoutingNumber'
+
+if [[ "$TOOL" == mcp__playwright__* ]]; then
+    # A rendered page: block only when a value actually accompanies the field name.
+    SENSITIVE_PATTERNS=(
+        # JSON body surfaced through the browser: "SSN": "123-45-6789"
+        "\"($FIELDS)\"\s*:\s*\"?[0-9]"
+        # Rendered value: SSN: 123-45-6789 / TIN = 12-3456789 / Account #: ****1234.
+        # Requires at least one real digit, so a fully masked "***-**-****" is allowed
+        # through -- that carries no data, and /qa needs to verify masking works.
+        "($FIELDS)\s*#?\s*[:=]\s*[\"']?[*Xx-]{0,8}[0-9][0-9*Xx-]{2,}"
+        # A bare SSN or EIN anywhere on the page, label or not
+        '\b[0-9]{3}-[0-9]{2}-[0-9]{4}\b'
+        '\b[0-9]{2}-[0-9]{7}\b'
+    )
+    BLOCK_MSG="BLOCKED: Browser output contains a sensitive value (SSN, TIN, bank account, etc.)"
+    BLOCK_HELP="Do not retry this snapshot. Record the screen as 'BLOCKED — protected fields on screen,
+manual QA required', test only its structure/validation/navigation, and move on.
+Never transcribe a protected field's value into a report or a work item comment."
+else
+    # Database / file / grep output: the field NAME appearing at all means PII was returned.
+    SENSITIVE_PATTERNS=(
+        # JSON/MongoDB style: "TIN": or 'TIN':
+        "\"($FIELDS)\"\s*:"
+        # C# property style: .TIN = or .TaxId =
+        "\.($FIELDS)\s*="
+        # YAML/config style: TIN: (start of line or after whitespace)
+        "(^|\s)($FIELDS):\s"
+    )
+    BLOCK_MSG="BLOCKED: Output contains sensitive PII fields (TIN, SSN, bank account, etc.)"
+    BLOCK_HELP="For database queries: use an explicit inclusion projection listing only non-sensitive fields.
+For code searches: avoid reading seed data, test fixtures, or dump files containing PII.
+If you need to work with this data, use the application UI instead."
+fi
 
 for PATTERN in "${SENSITIVE_PATTERNS[@]}"; do
     if echo "$OUTPUT" | grep -qE "$PATTERN"; then
-        echo "BLOCKED: Output contains sensitive PII fields (TIN, SSN, bank account, etc.)"
-        echo "The output includes documents or data with sensitive fields."
-        echo "For database queries: use an explicit inclusion projection listing only non-sensitive fields."
-        echo "For code searches: avoid reading seed data, test fixtures, or dump files containing PII."
-        echo "If you need to work with this data, use the application UI instead."
+        echo "$BLOCK_MSG"
+        echo "$BLOCK_HELP"
         exit 2
     fi
 done

package/templates/hooks/uat-reminder.sh

@@ -7,3 +7,4 @@
 
 echo "Reminder: If you just completed a feature implementation, run UAT before marking it done."
 echo "Ask Claude to generate a UAT checklist from the work item's acceptance criteria."
+echo "Once it is merged and deployed, /qa AB#<id> runs an automated browser regression of the affected screens."

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -18,6 +18,7 @@ You (give task)
   ├── deployer → commits, pushes, triggers CD pipeline
   ├── db-admin → queries/fixes MongoDB data
   ├── test-runner → runs xUnit, Vitest, Playwright tests
+  ├── qa → drives a real browser on a deployed environment, regression-tests the affected screens
   ├── build-validator → confirms builds pass
   ├── lint-checker → runs ESLint and dotnet format
   ├── security-auditor → scans for secrets, vulnerabilities
@@ -46,7 +47,7 @@ Ultracode is **opt-in**. It is on only when a system-reminder confirms it, when
 | Multi-file or cross-layer review | one agent per file/dimension, then adversarial verify before reporting |
 | Repo-wide sweeps (rename, dependency bump, pattern migration) | one agent per site, worktree-isolated |
 
-Short, single-query operations (`/status`, `/explain`, `/close-orphan-tasks`) do **not** need ultracode — they are already one pass and gain nothing from fan-out. Reach for `Workflow` when the work-list is large and the per-item work is independent.
+Short, single-query operations (`/track`, `/explain`, `/close-orphan-tasks`) do **not** need ultracode — they are already one pass and gain nothing from fan-out. Reach for `Workflow` when the work-list is large and the per-item work is independent.
 
 **`/rework` always uses ultracode** — it does not wait to be asked. It fans out feedback gathering, codebase exploration, per-acceptance-criterion coverage checks, and the find → adversarially-verify review, while keeping every approval gate and write in the main loop.
 
@@ -79,7 +80,7 @@ These run automatically — no action needed:
 | Server | What It Does |
 |--------|-------------|
 | **Azure DevOps** *(core — drives every slash command)* | Work items, repos, pull requests, pipelines, wiki, test plans, advanced security |
-| **Playwright** | Browser testing (navigate, click, fill, screenshot) |
+| **Playwright** | Browser testing (navigate, click, fill, screenshot) — **required by `/qa`** |
 | **MongoDB** | Direct database queries and updates |
 | **Microsoft Teams** | Send/read team messages and notifications |
 | **Stripe** | Payment management (when configured) |
@@ -170,12 +171,14 @@ Every environment in the chain has a work item state, so the board shows where e
 | `staging` | Staging | `Ready for Staging` | `Staging` |
 | `prod` | Production | `Ready to Deploy` | `Deployed` |
 
+`/qa` is the exception that proves the rule: it tests a work item in a browser and posts a pass/fail comment, but it **never writes a state** — not even `Ready for Testing`.
+
 Human-only transitions — no slash command ever makes these: `Testing → Ready for Staging` (QA sign-off), `Staging → Ready to Deploy` (stakeholder / UAT sign-off), `Deployed → Closed` (verified in production).
 
 How the commands use this table:
 
 - **Gate check before the PR.** `/deploy-release`, `/cherry-pick`, and `/promote` compare each carried work item's state against the gate for the target environment. Anything behind the gate (e.g. still `Testing` when deploying to `staging`) is flagged and the user decides whether to include it. Items *ahead* of the gate (e.g. already `Deployed` on a cherry-pick to `prod`) are reported and left alone.
-- **Advance on a green pipeline, automatically.** `/promote`, `/cherry-pick`, and `/deploy-release` do not stop at the PR. They poll it until it is `completed`, then poll the target branch's CD pipeline until every run finishes. Only on `succeeded` do they write the new state — for every carried User Story, Bug, and Hot Fix, never a Feature or Task, and never backward. A failed or canceled run changes **nothing** and is reported with the log link. `/status` reports items whose state lags the branch their commits are on and offers to catch them up.
+- **Advance on a green pipeline, automatically.** `/promote`, `/cherry-pick`, and `/deploy-release` do not stop at the PR. They poll it until it is `completed`, then poll the target branch's CD pipeline until every run finishes. Only on `succeeded` do they write the new state — for every carried User Story, Bug, and Hot Fix, never a Feature or Task, and never backward. A failed or canceled run changes **nothing** and is reported with the log link. `/track` reports items whose state lags the branch their commits are on and offers to catch them up.
 - **Assign the verifier at the same time.** The state change hands the item to a person, so the same three commands ask **before the merge** who each group of items should go to, then apply the assignee alongside the state once the pipeline is green. See **Verifier Assignment** below.
 - **Never assume the state list.** Confirm with `mcp__azure-devops__wit_work_item` (`action: get_type`) on an unfamiliar project before writing a state name — a bad name is accepted silently by a query and rejected only at write time.
 
@@ -304,8 +307,9 @@ All deployment and release operations are available as slash commands:
 | `/cherry-pick` | `/cherry-pick AB#1234 AB#1235 prod` | Gate-check → cherry-pick specific work items → PR → ask who verifies → advance + assign on a green pipeline |
 | `/promote` | `/promote main dev` | Promote all code between environments (`main → dev → test → staging → prod`) → ask who verifies → advance + assign on a green pipeline |
 | `/rollback` | `/rollback AB#1234 prod` | Revert commits on an environment |
-| `/status` | `/status release 24` | Check release, pipeline, environment, or work item status; flags work items whose state lags their environment |
+| `/track` | `/track release 24` | Check release, pipeline, environment, or work item status; flags work items whose state lags their environment |
 | `/where` | `/where AB#1234` | Show which environment branches contain a work item's commits |
+| `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment (never a state change) |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
 | `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
 | `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, **bugs in `New`** (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated). Pointed items move to Dev Ready; stories that can't be quoted move back to **Design Review**, bugs that can't be quoted get a **`needs-info`** tag, so the next sweep skips them. Every run also audits the drop-out queue (tagged bugs **and** stories bounced to Design Review) and reports any whose creator answered but which nobody returned to the sweep — neither mechanism expires, so those are otherwise invisible forever |
@@ -319,7 +323,7 @@ The CD pipeline is only triggered manually when pushing directly to an environme
 
 ### Pipeline Configuration
 
-Each project must define its compare branch, its environment chain, and its pipeline IDs so the slash commands (`/deploy`, `/promote`, `/deploy-release`, `/cherry-pick`, `/where`, `/status`) know which pipelines to trigger and what the promotion order is.
+Each project must define its compare branch, its environment chain, and its pipeline IDs so the slash commands (`/deploy`, `/promote`, `/deploy-release`, `/cherry-pick`, `/where`, `/track`) know which pipelines to trigger and what the promotion order is.
 
 Add this section to your project's `CLAUDE.md`:
 
@@ -341,7 +345,7 @@ Add this section to your project's `CLAUDE.md`:
 - `/deploy` triggers the pipeline(s) listed for the current branch. If the current branch is not in this table, or its pipeline cell is `—`, no pipeline is triggered.
 - `/promote` uses this table to determine the next environment (the next row down).
 - `/deploy-release` and `/cherry-pick` create PRs targeting environment branches listed here, and use the **Work Item States ↔ Environments** table to gate-check and advance work items.
-- `/where` and `/status` check every row; the compare branch reports as "merged to main", not as a deployment.
+- `/where` and `/track` check every row; the compare branch reports as "merged to main", not as a deployment.
 
 **Examples from actual projects:**
 
@@ -375,6 +379,53 @@ Glasswing and Monarch (not yet migrated — 1 environment):
 | develop | Dev | CD - Development (28) |
 ```
 
+### Environment URLs
+
+`/qa` opens the app in a real browser, so it needs to know where each environment is hosted and which test account to sign in as. Without this section `/qa` reports and stops rather than guessing a hostname.
+
+Add this to your project's `CLAUDE.md` — **above the `## Claude Kit Workflow` heading.** Everything from that heading to the end of the file is replaced on each kit update, so configuration placed below it is lost.
+
+```markdown
+## Environment URLs
+
+| Branch | Environment | App URL | API URL |
+|--------|------------|---------|---------|
+| (none) | local | http://localhost:5173 | https://localhost:7001 |
+| dev | Dev | https://dev.myapp.example.com | https://dev.api.myapp.example.com |
+| test | Test | https://test.myapp.example.com | https://test.api.myapp.example.com |
+| staging | Staging | https://staging.myapp.example.com | https://staging.api.myapp.example.com |
+
+**Sign-in:** form at `/login` — app-issued JWT, no SSO. Signed-in landing: `/dashboard`.
+
+**Test accounts** — values live in environment variables; never write a password here.
+
+| Role | Username variable | Password variable | Default |
+|------|-------------------|-------------------|---------|
+| Admin | `MYAPP_QA_ADMIN_USERNAME` | `MYAPP_QA_ADMIN_PASSWORD` | yes |
+| Provider | `MYAPP_QA_PROVIDER_USERNAME` | `MYAPP_QA_PROVIDER_PASSWORD` | |
+```
+
+**Rules for slash commands:**
+- **Branch names must match the `## Pipeline Configuration` table** row for row. The two tables are joined on the branch column — `/qa` reads the URL here and the pipeline ID there. A mismatch is a configuration error worth reporting.
+- **There is no `prod` row, deliberately.** `/qa` refuses production: an unattended regression pass signs in and clicks through live member data.
+- **Include the rows below the one you test.** The row immediately below the target serves the pre-change build, which is how `/qa` tells a regression this story caused from a bug that was already there.
+- **App URL is required; API URL is optional** — it is used to attribute a failing network call to the backend rather than the screen.
+- **`Sign-in:`** is optional prose. Include it when the login route is not `/login`, when the landing page is not obvious, or — importantly — when sign-in goes through **SSO / Entra ID with MFA**. Say so, and `/qa` reports that it cannot sign in unattended instead of hanging on a browser prompt.
+- **Test accounts** are required by `/qa` and nothing else. The `Default` column marks the account used when `--role` is not given; if no row is marked, the first row wins. A second role lets `/qa` verify that restricted controls are correctly *absent* — a class of bug a manual checklist rarely catches.
+- **Never put a credential in this table.** Only variable names. The values belong in your shell profile — see Environment Setup below.
+
+**Example from an actual project:**
+
+COMPASS:
+```markdown
+| Branch | Environment | App URL | API URL |
+|--------|------------|---------|---------|
+| (none) | local | http://localhost:5173 | https://localhost:7169 |
+| dev | Dev | https://dev.compass.caresolutions.com | https://dev.api.compass.caresolutions.com |
+| test | Test | https://test.compass.caresolutions.com | https://test.api.compass.caresolutions.com |
+| staging | Staging | https://staging.compass.caresolutions.com | https://staging.api.compass.caresolutions.com |
+```
+
 ### Environment Setup
 
 Each team member needs to set their own environment variables (never commit these):
@@ -391,4 +442,15 @@ az login
 
 # Microsoft Teams MCP — no env vars needed. First invocation prints a
 # device code + URL to sign in via Microsoft Graph (OAuth device flow).
+
+# QA test accounts (required for /qa — browser testing on a deployed environment).
+# One pair per role. The variable NAMES are declared in the project's
+# `## Environment URLs` section; the VALUES live only here, never in any file.
+# Use throwaway QA accounts with least privilege, never a personal login.
+export COMPASS_QA_ADMIN_USERNAME="qa-admin@example.com"
+export COMPASS_QA_ADMIN_PASSWORD="..."
+export COMPASS_QA_PROVIDER_USERNAME="qa-provider@example.com"
+export COMPASS_QA_PROVIDER_PASSWORD="..."
 ```
+
+`/qa` reads these itself **inside a subagent** and fills the login form directly. It never prints a value, never writes one to a file, and never includes one in a report or a work item comment. If your app's sign-in requires MFA or SSO, unattended login is not possible — say so in the `Sign-in:` line of `## Environment URLs` and `/qa` will report that instead of hanging on a browser prompt.

package/templates/infrastructure/settings.json

@@ -74,6 +74,15 @@
             "command": "bash .claude/hooks/sensitive-data-output-blocker.sh"
           }
         ]
+      },
+      {
+        "matcher": "mcp__playwright",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/hooks/sensitive-data-output-blocker.sh"
+          }
+        ]
       }
     ],
     "Stop": [