test

test - Verification Stage

Invariants

• Verify against the task document acceptance criteria.
• Use the best available project verification path.
• Do not require one specific browser automation tool in core workflow.
• Always write one final report to docs/testing/.
• When tests pass and the user approves, update TASKS.md to Approved and re-read the tracker to confirm the row moved. A stale tracker blocks downstream and headless sessions.

Runtime adapters may expose this stage as a slash command, menu action, or natural-language skill invocation. The portable stage name is test.

Workflow

1. Read AGENTS.md.
2. Resolve the task ID and read docs/task/{ID}-{task-name}.md.
3. Confirm the task reached the quality gate.
4. Build a verification plan from Acceptance Criteria and Verification Approach.
5. Prefer existing project commands and CI-compatible checks.
6. Run safe verification commands.
7. Use browser automation or manual checks only when required by the task.
8. Write docs/testing/{ID}-{task-name}.md from the project's docs/templates/test-report.md if it exists, otherwise from templates/test-report.md bundled next to this file.
9. Move the task to Approved only after tests pass and the user approves, or leave it in Testing if fixes are needed.
10. If the move was made, re-read TASKS.md and verify the task row is in Approved and absent from Testing. If the row is not in the expected section, the move was missed — perform the edit now before handoff.

Verification Priority

Use the narrowest reliable check first:

1. Unit tests for pure logic.
2. Integration tests for API, database, service, or cross-module behavior.
3. Browser or end-to-end checks for user-visible workflows.
4. Static checks such as typecheck, lint, or build where they are part of project quality.
5. Manual inspection only when automation is unavailable or not cost-effective.

If no viable verification path exists, write a BLOCKED report explaining what is missing.

Evidence Rules

• Run each criterion's check and compare it with the task doc's Baseline. Record both values. A criterion passes only when its check ran and showed the expected result.
• Grade the oracle. A check that asserts source text, file structure or a mock's call count shows the code has a shape, not that it behaves. Mark such results weak evidence and, where a behaviour or output check is possible, run that instead.
• No-regression checks are required, not optional: re-run the behaviour the task says must not change.
• Never mark PASS from reasoning alone. If a check couldn't run, the result is SKIPPED or BLOCKED, with the reason.

Live Verification

Passing tests show the code is right; they don't show the change is live. When the change ships through separately deployed parts (services, functions, workers, migrations):

• Verify output in the running system (the rows, messages or records the change should produce), not liveness (status codes, "job succeeded", a deployed version number).
• Name any check that needs a deploy or an owner action first as Deferred, with the exact step, instead of marking it PASS.

Report Rules

• Write the final report only under docs/testing/.
• Do not scatter temporary reports in the repo root.
• Record commands exactly as run.
• Record skipped checks with reasons.
• Include enough evidence for the implementation stage to fix failures without session history.

Handoff

PASS:

Verification passed for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Next stage after user approval: document {ID}

FAIL or BLOCKED:

Verification failed or blocked for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Return to implementation with the report context.