tdd-frontendlisted

# TDD frontend The payoff of test-first in an unattended run is narrow and specific: **a test observed failing first is a test you know can fail**. Written after the code, it passes immediately, and a test that has never been red may be asserting nothing at all. You find out eighteen months later, when the regression it was supposed to catch ships. ## The seam is already decided A test needs a boundary to observe behaviour at — the public interface you assert against without reaching inside. Choosing badly is the difference between a suite that survives refactoring and one that goes red every time anything moves. That choice belongs to `spec-forge`, not to this loop. The spec names the seams for the work before implementation starts, which is what lets the loop run without stopping to ask. Where a step arrives without one, prefer the existing seam its neighbours already use over introducing a new one, take the highest seam that can still observe the behaviour, and record the choice in the ledger. ## The loop **Red.** Write the smallest test stating one behaviour from the acceptance criteria. Run it. It must fail *for the reason you predicted* — "expected the error panel, found nothing", not "cannot read property of undefined". A wrong-reason failure means the test is broken, so fix the test before writing any implementation. **A test asserting an absence is green from the start.** `expect(queryByRole(...)).not.toBeInTheDocument()` passes trivially while the element doe