tdd

These are standing instructions for the rest of this task, not a one-time checklist. Every increment of $ARGUMENTS goes through the cycle below.

The cycle

1. RED — write a failing test that specifies the behavior. Run it. Confirm it fails for the reason you expect, not because of a typo or a missing import. A test that has never failed proves nothing.
2. GREEN — write the minimal implementation that makes it pass. Run it. Resist implementing the next requirement early.
3. REFACTOR — improve names and structure with the tests green. Re-run after each change.
4. Repeat for the next behavior. Small increments; do not batch five behaviors into one test.

For a bug fix, RED means a test that reproduces the bug. Write it before touching the fix.

Rules

• Implementation never runs ahead of tests. If you find yourself writing code with no failing test pointing at it, stop and write the test.
• Fix the implementation, not the test — unless the test encodes the wrong expectation, in which case say so explicitly before changing it.
• Structure every test Arrange-Act-Assert, with a name that states the behavior (returns empty array when no markets match query), not the function name.
• Cover error paths and edge cases, not just the happy path. Coverage floor is 80%; run the project's coverage command and report the number rather than assuming.
• Never weaken an assertion or delete a test to get to green.

Reporting

At the end, state: which tests were added, current pass/fail counts, the coverage figure with the command that produced it, and anything you deliberately left untested and why.