regression

name	regression
description	Runs the end-to-end regression pass against an isolated mock stack — boots the stack, fans the checklist out to subagents by area, collates verdicts and defects. Use when the user says "run regression", "run the QA pass", "/regression", or a task is at PROVE and needs the chat surface re-verified.

CDP Browser regression skill

Drives docs/conventions/e2e-verification.md. Read it before the first run — the rules there are the contract; this file is the procedure.

The two rules that make or break a run:

• You (the orchestrator) never execute test cases. Subagents do. You get verdicts, not evidence.
• Subagents drive the UI with real input events (page.click, Chrome DevTools MCP, CDP Input.*). A synthetic dispatchEvent bypasses pointer-events and reports a false PASS.

1. Pick a run id and boot an isolated stack

Node 24 (nvm use 24) — better-sqlite3 is built for that ABI.

MOCK_DIR=.mock-data-<run> WEB_PORT=<p> BFF_PORT=<p+10> pnpm chat:mock

Default <p> is 7900; use 7920, 7940 … for concurrent runs. Never reuse a port or a MOCK_DIR across live runs, and never point at the real stack. Wait for /api/chat/conversations on WEB_PORT to answer before dispatching.

2. Choose the scope

• Fix verification — the failed case IDs plus their component's neighbours.
• Task PROVE — the areas the change can reach.
• Full sweep — every area; end of a task only.

Cases live in docs/testing/chat-qa.md, grouped by area (Delivery, Edit/delete history, Settings, Hover overlays, Composer, Assistant, Links, Conversation list, Core regression).

3. Dispatch one subagent per area

One Agent call per area, in a single message so they run in parallel. Give each subagent:

• the run's URL (http://localhost:<WEB_PORT>/chat) and MOCK_DIR;
• the verbatim case rows for its area;
• a screenshot dir (/tmp/<run>/<area>/);
• these instructions:

Drive the UI with real input events only — Playwright/CDP/Chrome DevTools MCP. evaluate_script reads state, it never clicks. Run every content-bearing case twice: shortest plausible value and an abusive one (80+ char name, 200-char topic, 4000-char message, 300-char URL, 12 reactions, empty and one-item lists). Check both themes and 390×844 for any layout case. Do not edit files, commit, or stash. Do not boot another stack.

Return ONLY a table: case-id | PASS | FAIL | BLOCKED plus, per failure, one line of symptom and the minimal repro. No screenshots, no DOM dumps, no logs, no narration. Screenshots stay on disk; give the path only.

4. Collate and act

• Merge the verdicts into one defect list, ranked: data loss > broken flow > visual.
• Fix in the main session (subagents don't write), then re-dispatch only the affected case IDs.
• Append a case for every defect fixed — that is the point of the checklist.
• Update docs/testing/chat-qa.md: new rows, and the Last run line (date · commit SHA · tally).

5. Tear down

Stop the stack (Ctrl-C kills both processes) and rm -rf $MOCK_DIR. Report to the user: pass/fail tally per area, the defect list with repro steps, and what was fixed vs filed.

Guardrails

• No script backs this skill — pnpm chat:mock already boots the stack. Don't add one unless the dispatch itself becomes mechanical.
• Never run the pass inline "just to save a subagent". That is how the orchestrator's context dies.
• A case that can't be driven by a real event is PASS (synthetic), never PASS.
• Areas needing network, a real tenant, or a device stay in the checklist's "cannot be verified locally" table — mark them BLOCKED, don't fake them.