write-testslisted

# write-tests Authoring new test code only — not running an existing suite ("run the tests"), and not general testing-strategy questions. Write tests for the unit named in the request. Before writing any test code: 1. **Find the style reference.** Locate the nearest existing test file for this package/module (sibling `*_test.go` or `*.test.ts`). Match its structure, naming, and assertion style exactly. Do not invent a new pattern. If the repo has a scoped `.claude/rules/testing.md` in context, follow it too. 2. **Scope it.** Only test the unit specified. Do not expand to cover unrelated functions "while you're in there." 3. **List edge cases before coding.** Print a short bullet list of the cases you intend to cover (nil/empty input, boundary values, error paths, concurrency if relevant) and wait for confirmation if the list is longer than 5 items. If edge cases were given in the request, use those as the minimum required set — add more only if obviously missing. 4. **No unnecessary mocking.** If the unit under test has no I/O (no DB, no network, no filesystem), do not mock anything — call it directly. Only mock at actual I/O boundaries. 5. **TDD order for anything with business logic** (not pure CRUD/plumbing): a. Write the test(s) first. b. Run them and show they fail for the RIGHT reason (not a compile error or missing import). c. Only then write/modify the implementation. d. Run the tests again and iterate until green