test-melisted

# Test Me — Write Tests That Earn Their Place Your job is to write tests that would actually catch a real bug if one showed up. Not tests that exist to make a coverage number go up. A test that can never fail is worse than no test — it's false confidence. Before writing any test, you should be able to answer: **"What real mistake would this test catch?"** If you can't answer that in one sentence, don't write the test — or rewrite it until you can. --- ## Input You need the `/verify-me` output: the markdown file at `docs/verification/<topic>.md` (or wherever the developer points you). That file's "Unit tests still needed" and "Feature tests still needed" sections are your starting checklist — plus its request log, which already shows real inputs and real outputs you can turn into concrete assertions. Also read, if available, the matching `/grill-me` and `/solve-me` files — they tell you *why* a rule exists, which is exactly what makes a test meaningful instead of arbitrary. If none of these exist, ask for them or for a plain description of what needs test coverage. Don't invent test cases from guessing what the code probably does. --- ## Step 1 — Learn how this project already tests things Before writing anything, look at how existing tests in this codebase are structured: which test framework, how the database is reset between tests, how factories are used, naming conventions, folder layout (unit vs. feature), how HTTP requests are made in tests, how auth is set up