tdd

Identify the intended versus actual behavior, write the smallest test that encodes the intended behavior, confirm it fails, then make the smallest production change and rerun the test until it passes. Finish by running nearby validation such as adjacent tests, type checks, or lint.

Skip the failing test when it would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, or vague reproduction steps. State why the test is impractical and use the closest executable check, such as a targeted script or manual reproduction command.

A bad test mostly asserts mocks, mirrors current implementation details, depends on timing or unrelated global state, or needs expensive infrastructure for a small fix. Prefer no new test over a bad test and use manual or scripted verification instead.

The workflow requires a named bug, a candidate cheap test path, and authority to edit code before starting. When any input is missing it returns a HOLD describing the gap, because inventing inputs produces tests that encode guesses rather than intended behavior.

No. Tests should encode intended behavior, not mirror a wrong implementation. Existing assertions are only weakened when the expected behavior has genuinely changed and the reason is confirmed and clear.