A limit can be tested without draining the process: give the token buckets a reset seam #132

src/limits.ts now exports resetLimits() — one call that puts every bucket the module owns (boardCreationBucket and writeBucket) back to full — and TokenBucket.reset()'s comment stops describing itself as a test-only trick; it is plain code with no branch on the environment, and nothing in the running app calls it.

The test suite no longer leans on file order. server.test.ts, drag.test.ts, theme.test.ts and live-refresh.test.ts call beforeEach(resetLimits) instead of resetting once at module load, which also lets server.test.ts's newBoard drop its 429-retry and three stale "spending a token here narrows the margin" comments. write-limit.test.ts, the one file that wants a limit exhausted, resets before each test so its drain starts from a full bucket and resets after the file so nothing inherits the empty one. limits.test.ts asserts the seam itself: a drained TokenBucket is full again and owes nothing after reset(), and resetLimits() hands back both module buckets rather than just one.

Checked bun test (202 pass, 0 fail), bun test src/write-limit.test.ts and bun test src/limits.test.ts on their own, and the whole suite twice with the file list shuffled — all green. What I did not do: make the buckets injectable or thread them through callers; the limits stay module state and the reset is the only new surface. Worth a look in the diff: src/limits.ts's new function and the deleted retry in server.test.ts:32.

🤖 Generated with Claude Code

Closes #86