Test-Driven Development

Build or fix behavior one verified slice at a time. A cheap local test path writes the failing check first. An expensive or unclear path names why and uses the closest executable proof instead.

Contract

Inputs:

• Feature request, bug report, PRD, issue, or implementation plan
• Existing test commands and project conventions
• Public interface or user-facing behavior to protect

Outputs:

• Test-first implementation plan when a cheap path exists
• New or updated tests and code when implementation is requested
• Verification commands and the failing-before / passing-after evidence