# Skill: Regression Check

Purpose: Validate that a change has not broken existing functionality, especially in legacy stacks lacking automated test coverage.

## Steps
1. Re-read the spec's Acceptance Criteria and Verification Plan.
2. Confirm TDD was actually followed, not just that tests exist: for each implementation task in the spec's Implementation Plan, its paired test/manual-verification task should appear before it and there should be no implementation task without one. Check the red/green timestamp note recorded against each pair (per `specs/templates/spec-template.md` and `specs/templates/tasks-template.md`) — the test task's completion time must precede the implementation task's. If a test was clearly written after its implementation, or no timestamp note was recorded, flag it as a process gap for the retrospective.
3. **When a real test harness exists for the affected stack** (e.g. an `aspunit` suite under `tests/` for a RouteKit ASP Classic app, or an automated suite for a modern stack), actually run it using the command(s) recorded in `.devfoundry/references/environments.md` and read its real output — do not mark a checklist item verified from checklist prose alone. Paste or summarize the actual pass/fail output in the spec's Verification & Regression Plan.
4. **When no test harness exists** for the affected stack (legacy code with no `tests/` app, or a stack `environments.md` explicitly records as having none), manually trace affected queries, forms, and reports per the spec's written manual-verification steps, and record exactly what was traced and observed — a documented manual trace is the accepted substitute only in this case, never a silent skip.
5. Check any known dependent features listed in `.devfoundry/references/data-dictionary.md`.
6. Record verification results in the spec's Verification & Regression Plan checklist, including which of step 3 or step 4 applied and why.