Sdlc Test

---
name: sdlc-test
description: Execute project verification for an implemented, planned change and report real test and applicable eval output before it can be reviewed. Do NOT use for drafting plans, implementing features, speculative test advice, PR review, merging, deployment, or monitoring.
---

# SDLC Test

Run Stage 4 of 6 in the AI-Native SDLC playbook described in `docs/PLAYBOOK.md`.

## Purpose

Prove the implementation against `plan.md` and `spec.md` before review.

The agent must execute verification. Never claim that tests pass based on source
inspection, an earlier run, or an assumption.

## Entry gate

Locate `.sdlc/<slug>/plan.md`, `.sdlc/<slug>/spec.md`, and the implemented code.

Verify that `plan.md` contains **Proof** and that `spec.md` contains
**Verification strategy**.

Verify that the spec was accepted and that implementation is available to test.

If any artifact, required section, or implementation is missing, return to
`sdlc-build` and stop.

## Procedure

1. Read `plan.md` **Proof** in full.
2. Read `spec.md` **Verification strategy** in full.
3. Map the planned proof to the spec's requirements and verification strategy.
4. Discover the project's documented test commands and test suites.
5. Execute all tests in the project, including the tests named by the plan where
   applicable.
6. Capture actual command output, exit status, skipped tests, and failures.
7. Quote the real relevant output in the verification report.
8. Determine whether this change modified `CLAUDE.md`, any skill, or any hook.
9. If it did, discover the project's existing eval suite for that configuration.
10. Run the applicable eval suite and quote its actual output and exit status.
11. If no eval suite exists, state that none was found; do not invent an eval.
12. Compare evidence with every planned and specified verification claim.

Do not omit a suite because it is slow, inconvenient, or unrelated at first glance.

If the project documents a required environment that is unavailable, report the
specific blocker and do not mark verification green.

## Evals

An eval is a fixed prompt set with expected-behaviour assertions, versioned beside
the configuration it protects.

When `CLAUDE.md`, a skill, or a hook changes, find and run the project evals that
guard that configuration.

Do not invent an eval suite, expected results, or passing result. Note plainly when
no project eval suite can be found.

## Failure loop

If any test, required check, or applicable eval is red, return to code.

Report the real failure output and identify the failed proof or verification claim.

Do not ask for review, produce a deployment handoff, or call verification green
while any required evidence is red or missing.

After code is corrected, rerun the affected verification and all project tests.

## Required report

Show a concise evidence report containing:

- The tests and commands actually executed.
- Quoted real output for pass or failure.
- The result of each relevant `Proof` and verification-strategy item.
- Whether configuration changed.
- Applicable eval commands and quoted results, or the fact that none was found.

Do not replace quoted output with “tests pass.” The output is the evidence.

## Exit gate

Proceed only when all of the following are true:

1. All project tests pass, with quoted output.
2. If protected configuration changed, all applicable evals pass, with quoted output.
3. The agent explicitly states: `Verification is green`.

Stop and show the test output before handing off.

If any condition is false, loop back to code and do not request review.

## Handoff

Hand off to `sdlc-deploy` only with the complete test evidence.

Include commands, quoted results, relevant eval status, and any limitations that
were resolved before the final green result.