Test
Prove the behavior that matters. A passing build or a source-code reading can support the proof, but neither proves a user-visible flow.
Process
- Read the task, its source spec when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or reviewed spec. Preserve their wording and
AC-n, REQ-n, or INV-n IDs. Never rewrite criteria to match the code.
- Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve.
- If automated tests cannot exercise the affected behavior, explain why and give other evidence.
- Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks.
- Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario.
- Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed.
- When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser.
- Check desktop and mobile when layout or responsive styles changed.
- Check keyboard use when interactions changed.
- Check console errors and failed requests during every flow.
- Capture evidence. Reading source is not browser proof.
- Report each
AC-n, REQ-n, INV-n, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence.
Return
Report each criterion in this shape:
Lead with failures and unverified criteria. Do not hide them below passing checks.
Boundaries
- Do not weaken assertions to make a change pass.
- Do not fix unrelated failures.
- If required browser tooling is unavailable, report the check as blocked unless the user explicitly accepts a manual exception.