QA

(MUST) For Codex: When QA must use plugins

• Browser - Control the in-app browser
• Chrome - Control the user's real Chrome browser
• Computer Use - Control Windows apps or installed artifacts when QA requires real app interaction outside a browser.
• Playwright: use as an automation arm for browser actions, control sweeps, screenshots, videos, traces, and reports.
• Backend/API tools: use HTTP clients (curl/fetch), database CLI tools, or test runners for non-UI scopes.

(MUST) For Claude or other agents:

• Use the equivalent browser, Chrome/session, computer-control, or HTTP/database CLI capability exposed by that agent/runtime.

QA Runtime Review

Use this skill to verify real runtime behavior from the user's point of view. QA is a no-fix role: inspect, execute, record, classify, and report. Do not repair product code, tests, specs, fixtures, or generated files during QA.

Iron Laws

• QA MUST NOT fix code. Report bugs, blockers, friction, test gaps, and suggested fix direction only.
• Runtime behavior is the source of QA truth. Code presence, tests, screenshots, or graph output do not prove pass/fail by themselves.
• Must have screenshot Evidence for UI scopes. For non-UI / Backend / Database scopes, follow references/backend-qa-protocol.md (structured payload, DB state diff, and execution logs).
• Tests verify already-correct behavior. Tests do not define expected behavior and must not legitimize wrong UX.
• Wrong tests are findings. A green test that encodes wrong behavior is not QA proof.
• Do not skip steps. Every in-scope flow step matters equally.
• Every in-scope surface, action, state, data path, and blocker needs an explicit verdict or out-of-scope mark.
• An incomplete inventory or action ledger means QA is incomplete.
• If a blocker prevents downstream verification, downstream scope is Blocked, not passed.
• For final visible QA, open the real built website, runtime, or generated app artifact the same way a user would open it, in a visible browser or app window on the user's physical PC. Headless, hidden, source-only, test-only, or screenshot-only execution cannot approve final visible QA.
• QA must run on the real, officially built application (actual Electron artifact or release binary).
• For UI/visible scopes: Every action (clicking buttons, entering data, changing state) must capture clear PNG screenshots saved sequentially into the screenshots/ directory.
• For UI/visible scopes: Visually inspect each captured image / visual artifact to detect UI and behavioral defects; never rely solely on in-code assertions or generated .json/.md summary files.
• Never accept a UI QA report lacking the actual screenshot evidence set for each interaction. For Backend / non-UI reports, require structured HTTP status, response payload, and DB state diff evidence per references/backend-qa-protocol.md.

Source Of Expected Behavior

Use the first available applicable authority, in this order:

1. User's explicit QA scope and no-fix instruction.
2. Repository rules such as AGENTS.md.
3. Active execution plan, QA plan, or SPEC family.
4. Visible-browser plan when final visible QA is requested or the plan is in scope.
5. This skill's QA protocol.
6. Coverage model, inventory requirements, and control/state protocols below.
7. Automated tests as verification evidence only.

If authorities conflict, state the conflict and follow the higher authority. Never use a test expectation to override real required product behavior.

Record evidence and report findings, including:

• route/page candidates
• mounted entry candidates
• action/handler/API candidates
• data source/store/API/DB candidates
• permission/context gate candidates
• likely source files for suggested fix direction

Pass/fail requires runtime evidence.

Core Workflow (Frontend / UI)

1. Preflight → build, runtime, browser (references/frontend-runtime-and-build-rules.md)
2. Inventory → surfaces, controls, states (references/frontend-coverage-model.md)
3. Automation → screenshots, control sweep (references/frontend-automation-and-control-sweep.md)
4. Data flow → field/button tracing, E2E roundtrip (references/e2e-data-flow.md)
5. Source-of-truth → verify against real DB state (references/source-of-truth-rules.md)
6. Locale → if i18n in scope (references/frontend-i18n-and-locale.md)
7. Evidence & Report → screenshots, visual blockers, report, handoff (references/reporting.md)

Core Workflow (Backend / API & DB)

1. Preflight & Protocol → verify server runtime, DB connection, closed-loop API execution (references/backend-qa-protocol.md)
2. Source-of-truth → verify real DB state mutations, no mock data (references/source-of-truth-rules.md)
3. Evidence & Blockers → verify test bounds, blocker propagation (references/evidence-and-blockers.md)
4. Report & Escalation → HTTP status, DB diff, latency/RAM, handoff; escalate to Edge-Case if hostile chaos is required (references/reporting.md)

Red Flags

Stop, report, or re-scope if:

• QA starts fixing code.
• QA runs only headless/hidden browser for final visible QA.
• QA skips inventory.
• QA skips a step in an in-scope flow.
• QA clicks only the happy path.
• QA ignores disabled, no-op, rejected, empty, error, stale, or blocked states.
• QA uses fake app/commercial data as if it were real production state.
• QA ignores DB/source readback for DB-backed behavior.
• QA ignores locale/session/permission changes when in scope.
• QA reports downstream scope as passed after an upstream blocker.