Lock tests first

Lock Tests First

Treat tests as the behavioral contract. Do not weaken or rewrite protected tests merely to make implementation pass.

Workflow

1. Confirm the contract.
   • Start from approved acceptance criteria or derive observable inputs, outputs, errors, state changes, and invariants.
   • Resolve any ambiguity that would change expected behavior before editing files.
2. Inspect the test system.
   • Read repository instructions, test commands, nearby tests, fixtures, and production interfaces.
   • Match existing test levels and conventions.
3. Design coverage.
   • Cover the happy path, meaningful boundaries, failures, regression cases, and relevant authorization or security behavior.
   • Prefer behavior-level assertions over implementation details, excessive mocks, or broad snapshots.
4. Write the contract tests only.
   • Modify only tests and the minimum test-only fixtures or infrastructure required to express the contract.
   • Do not write or change production behavior yet.
5. Prove the red state.
   • Run the smallest relevant test command.
   • Confirm each new test fails because the behavior is missing or wrong, not because of syntax, setup, import, fixture, or unrelated failures.
   • If a test passes unexpectedly, determine whether the behavior already exists or the assertion is ineffective. Do not proceed with a false red state.
6. Audit and protect the tests.
   • Check that assertions are meaningful, deterministic, and capable of detecting a wrong implementation.
   • Record the protected test paths and their exact pre-implementation diff or content hash.
   • Commit a test-only baseline only when the user requested or approved committing. Otherwise state that the freeze is procedural and keep the baseline for comparison.
7. Implement the smallest production change.
   • Do not modify protected tests, their expected values, or test selection.
   • If a protected test is genuinely incorrect, stop and explain the flaw; obtain approval before changing the contract.
8. Prove the green state.
   • Run the focused tests, then relevant surrounding tests and available type, lint, or build checks in proportion to risk.
   • Compare protected tests to the baseline and confirm they were not altered during implementation.
9. Review the result.
   • Inspect the production diff for overfitting, hard-coded test values, bypassed code paths, weakened validation, or unrelated changes.

Output

Report the red evidence, protected test files, implementation summary, green evidence, broader checks, and anything not verified. Never report success from a passing test whose pre-implementation failure was not established. Use the review-changes skill before packaging commits.