tdd

The user invoked /procoder:tdd with arguments:

The command below is the procoder binary on PATH.

The iron law: no production code without a failing test first. Wrote code before the test? Delete it and start over — don't keep it "as reference". Violating the letter of this rule is violating its spirit. The arguments (if any) name the feature or fix to drive; apply the cycle to it.

The cycle, every behaviour:

1. RED — write one minimal test for one behaviour, then RUN it and watch it fail. This step is mandatory evidence, not ceremony: a test that passes immediately is testing existing behaviour (fix the test); a test that errors isn't failing for the right reason (fix it until it fails on the assertion you meant).
2. GREEN — the simplest code that passes. No options, no flags, no flexibility nobody asked for. Run the test (pass), run the suite (pass), output pristine — a new warning is a finding.
3. REFACTOR — only on green, no new behaviour, suite green after.

Writing tests that earn their keep:

• Name the break: before writing the body, answer "what production change makes this test fail — and is that change a bug?" No answer → redesign the test around observable behaviour. Asserting a constant equals itself, or that source text contains a line, catches decisions, not bugs.
• Derive expectations independently: literal expected values, not values computed by the same code path being tested — mirror assertions always pass.
• Test your code, not the framework: constructors, getters, and trivial forwarding earn tests only when they validate, normalise, default, or cause side effects.
• Mocks: mock the slow or external edge, keep what the test actually depends on real; a mock mirrors the real data completely (a partial mock passes the test and fails the integration); mock setup outgrowing the test logic means you want an integration test.
• The mutation check (before calling the work done): mentally break the production code — wrong constant, flipped branch, missing side effect, empty return, dropped validation. At least one test must fail for each realistic mutation; a mutation nothing catches marks that behaviour as unprotected.

Exceptions (throwaway spikes, generated code) exist — but ask the user first; "skip TDD just this once" arriving mid-task is rationalisation, not an exception. When stuck: hard to test = hard to use; a test needing heavy mocking is telling you the design is too coupled.

Evidence discipline: the RED command + failing output and the GREEN command + passing output go into the task's ## Evidence section — that is exactly what procoder todo close will ask you for.