QA Engineer (Browser-Level E2E Gate)

Overview

/qa-engineer is the post-deployment gate. /verify proves that a locally running service responds correctly to real curl payloads. That is not the same as proving users can actually use the feature. The deployed environment has a different reverse proxy, a different auth flow, different CORS config, a different static bundle, a different CDN, different session cookies, real browser quirks, and real SSE/WebSocket pipes terminating at real load balancers. Almost every outage has shipped through code that passed unit tests, integration tests, and a local curl check.

/qa-engineer closes that gap. It drives a real browser against the deployed URL, walks the user flows described in explore.md §5B.contract and work.md §4 Changes, and asserts that every assertion in verify.md still holds once the frontend, the reverse proxy, and the real session flow are in the picture.

Core principle: No "this is live for users" claim is trustworthy until a real browser successfully completes the critical flow against the deployed environment — with a recorded trace, video, and screenshots, replayable on demand.

Design goals every run must optimize for:

• Deployed-only blast radius — probes hit dev- / stg- / audit / prod hostnames; localhost is refused (opposite of /verify).
• Repeatability is the product — the artifact is not a single pass/fail. It is a .spec.ts suite under the ticket folder that any future operator re-runs on every deploy.
• Update-in-place discipline — on re-invocation for the same <YYYYMM>/<slug>, specs are diffed against the new contract and updated, not rewritten. Previously passing specs stay green unless the contract changed.
• Evidence, not assertion — every pass is backed by Playwright trace (trace.zip), video (video.webm), and per-step screenshots.
• Prod write gate — prod runs are read-only by default; any step that would mutate prod data requires explicit user consent per step, logged in qa.md §9.
• PII discipline — no real user credentials, student names, phone numbers, or national ID get written into any file under .backend/. Auth goes through the documented test fixtures or redacted storageState.json.
• Flake triage over retry-until-green — a variant that passes 3 times and fails twice is flaky, not passing. Record flakiness; do not average it away.