write-testslisted

# Write tests ## When to use - You implemented a feature and the acceptance criteria are not yet covered. - You are about to fix a bug (write the failing test FIRST). - A PR changes behavior but adds no test. - A reviewer asks "how do we know this works?". This skill is about tests that verify the SPECIFIC behavior that changed, not about chasing a line-coverage number. A test that passes whether or not the code is correct is worse than no test. ## Procedure 1. Restate the behavior under test in one sentence. If it came from a spec, quote the acceptance criterion. If it is a bug, state the wrong behavior and the correct behavior. 2. For a bug: write the regression test FIRST and run it. It must FAIL against the current code, reproducing the bug. A test that passes before the fix proves nothing. Only then write the fix and confirm the test flips to green. 3. For a feature: turn each acceptance criterion into at least one test. Cover the happy path, one boundary (empty, null, max), and one error path. Name each test after the behavior, e.g. `test_widget_search_returns_empty_on_no_match`. 4. Use the repo's existing test framework and fixtures. Read a neighboring test first and match its style; do not introduce a new runner or assertion library. 5. Run the full suite (for example `npm test`, `pytest`, or `./gradlew test` depending on the repo), not just the new file, so you catch a regression the change caused elsewhere. 6. If a test is flaky or en