Phased/Stepped Execution

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A teaching service returns 500 for an empty email. Required behavior is parameter error without breaking valid input. A has empty email; B has a@example.test; the project contract expects A=400 and B=200. Establish the failure, change it and verify rather than listing unchecked verbs.

Mechanism

Use dependent reproduction, implementation and verification stages. Record A’s actual status/revision first; change the confirmed validation path only; recheck A and B against observed output. Each exit supplies the next stage. Report missing environment or unreproduced failure instead of skipping to a pass.

Bad example

Fix the empty-email issue, improve the whole service and test later. Reasonable-looking code is enough to report completion.

Good example

Use three stages for this fixture: 1. Reproduce A returning 500 on the current revision and record request/command/result; explain inability to reproduce. 2. Modify the confirmed empty-email path within scope. 3. Check A=400 and B=200, inspect output and identify the tested revision. Preserve unfinished stages; a numbered plan is not verification evidence.

Why the change matters

Reproduction anchors changes to a trigger; checking invalid and valid inputs exposes unintended breakage. Explicit exits distinguish code written from behavior verified.

Observable expectation

The teaching acceptance table lists A original 500/target 400 and B target 200, with actual results/revision filled only after execution. A-only checks, absent reproduction or relevant edits after a pass cannot establish current completion.

This is a check design, not a real service run.

Limits

Small tasks can use short stages without unrelated paperwork or repeated approvals. Use appropriate environments and project status/data contracts. Phases do not grant permission for external actions.