Applying TDD

Use tests as executable behavior specifications, not as a coverage ritual.

Scope the Boundary

Before writing a test:

1. Load test boundaries, resolve the repository's actual production and test layouts from its manifests, package configuration, imports, runner configuration, and established paths, then apply the matching ecosystem fallback only where that evidence is insufficient. More-specific repository instructions override the fallback.
2. Partition eligible work by observable behavior rather than by file.
3. Apply TDD to a work unit only when all are true:
   • it changes a contract observable at a stable boundary
   • a focused test can fail for the intended reason before implementation
   • the test would catch a plausible regression that cheaper validation would not catch as clearly

Treat supporting edits such as config, wiring, schemas, fixtures, and generated artifacts as part of the behavior slice, not as separate units that each require a red-green cycle. Test custom parsing, defaults, validation, precedence, or resulting runtime behavior; do not write a test that merely repeats static config values, standard framework declarations, or metadata.

If no meaningful behavior contract exists, skip TDD and use the cheapest proportionate check: parse or schema validation, compile or type checking, linting, a focused smoke check, an existing integration test, or the repository gate. Do not add production abstractions solely to make a low-risk declarative edit unit-testable, and do not require an exception report for work that is outside this boundary.