---
name: test-validation
description: Use existing test/build tooling for validation - no invented commands.
tags: ['testing', 'validation', 'ci']
---

# Test Validation

## Purpose
Run the project's existing test and build tooling to validate a change, without inventing new commands.

## When to Use
- After any implementation block (Phase 4)
- Before declaring a feature complete
- Before a release
- When verifying a bug fix

## Phase Context
Full phase sequence: 1 (Intake) → 2 (Architecture) → 3 (UI Design) → 4 (Implementation) → 5 (Test) → 6 (Runtime) → 7 (Deployment) → 8 (Release)
Test validation occurs in Phase 5, after Implementation (Phase 4). UI Design (Phase 3) produces mockups and design specs that guide implementation.

## When Not to Use
- When no test framework exists (create one first, see implementation_engineer)
- For purely documentation changes (no test needed)

## Procedure
1. Discover test framework from package.json, requirements.txt, Makefile, etc.
2. Discover build command from the same files
3. Run tests using the discovered command (e.g., `npm test`, `pytest`, `make test`)
4. Run build using the discovered command (e.g., `npm run build`, `make build`)
5. Capture pass/fail counts and detailed failure output
6. If failures, classify and delegate to test_debug_engineer for root cause

## Quality Gates
- Tests pass (no failures, no skips without justification)
- Build succeeds without warnings (or warnings documented)
- Type check passes (e.g., `tsc --noEmit`, `mypy`)

## See Also
- Tool: `terminal` (for running test commands)
- Subagent: `test_debug_engineer`