systematic-qa

name

systematic-qa

description

Executes full-project QA like a real user by discovering the repository verification contract, running build, lint, test, and startup commands, exercising core workflows end-to-end, creating realistic fixtures when needed, fixing root-cause regressions, and rerunning the full gate. Use when validating a branch, release candidate, migration, refactor, or risky commit. Do not use for static code review only, one-off unit test edits, or architecture brainstorming without execution.

Systematic Project QA

Procedures

Step 1: Discover the Repository QA Contract

1. Read root instructions, repository docs, and CI/build files before running commands.
2. Execute python3 scripts/discover-project-contract.py --root . to surface candidate install, verify, build, test, lint, and start commands.
3. Prefer repository-defined umbrella commands such as make verify, just verify, or CI entrypoints over language-default commands.
4. Read references/project-signals.md when command ownership is ambiguous or when multiple ecosystems are present.
5. Identify the changed surface and the regression-critical surface before choosing scenarios.
6. Choose a QA artifact location using repository conventions. If the repository has no QA artifact convention, store scratch artifacts under /tmp/codex-qa-<slug>.

Step 2: Define the QA Scope

1. Build a short execution matrix covering baseline verification, changed workflows, and unchanged business-critical workflows.
2. Read references/checklist.md and ensure every required category has a planned validation.
3. Prefer public entry points such as CLI commands, HTTP endpoints, browser flows, worker jobs, and documented setup commands over internal test helpers.
4. Create the smallest realistic fixture or fake project needed to exercise the workflow when the repository does not already include one.