ticket-implementation-tddlisted

# ticket-implementation-tdd The detailed maker loop `coder` invokes. One ticket. Gate first. Real seams. ## Step 1 — Lock the gate BEFORE editing Take the ticket's `Verification-command` verbatim. Then: 1. **Run it before any change.** You need to know whether it was already green, already red, or doesn't run at all. 2. If it doesn't run (missing harness, wrong path, no such script) — that's a **ticket defect**. Fix the command with the user's agreement *before* treating it as the done-definition, and note the correction on the ticket. 3. If the ticket has no command, derive one and get it agreed. Do not invent a private definition of done. Once locked, the gate does not move to accommodate your implementation. If the gate is wrong, you change it deliberately and say so — you never quietly relax it. ## Step 2 — Red at the highest meaningful seam Write the failing test at the **outermost seam that still fails fast and specifically**: - Prefer a real domain/service/API boundary over a unit test of a private helper. - The test must exercise the seam **production traffic actually uses**. A test against a path the app never takes proves nothing — this is the single most common false-green in this pipeline. - Watch the test fail. A test that passes before you write the code tests nothing. - Assert on **anchored tokens**, not substrings. `not.toContain("9.99")` breaks against `"119.99"`. Cover the corners the ticket's invariants imply, not just the happy path: malformed, em