implement-with-tddlisted

# Implement with TDD Work from the outside in and let each failure name the next move. Stop at shameless green; a later step refactors. The discipline exists because you're fluent enough to write plausible code for almost anything, and plausible isn't correct. A failing test tells them apart. ## What you were handed The thing to build: `$ARGUMENTS` If that's empty, ask. If it's a path, read it. Take the acceptance criteria and nothing else. Those are behavior, and behavior is what you can test. A file list, a suggested test path, an ordering: that's a guess from a session that never ran the suite. Yours will run it, so your evidence is better. Where the repo contradicts the plan the repo is right — say so rather than diverge quietly. ## Before the first test **Run the whole suite before touching anything** and keep the list of what fails. Those failures are inherited: you don't fix them and they don't count against you. Without that list you'll adopt someone else's broken test as your problem and spend the session on it. If the suite can't be made to run using the repo's documented setup, stop and report what's missing — a missing database or service isn't something to work around. Then learn the suite: - The command for one test file, and the one for everything - Which layers exist here (end-to-end, request or API, unit) — you can only start at the outermost layer the repo actually has - The local idiom: factories or fixtures, helpers, naming Read the two or thr