Building from a spec

Build labs are the opposite of debugging: the tests describe a component that doesn't exist yet.

1. Read every test name before writing code. They are the requirements list. Group them: happy path, validation, edge cases, errors.
2. Write the skeleton: exported names, method signatures, return shapes. Run the tests: the failures should now be about behaviour, not "is not a function".
3. Happy path first, then validation, then edge cases. Re-run after each step; watch the count of green climb.
4. Choose data structures deliberately. LRU → Map (insertion order) or hash map + doubly-linked list. Leaderboard → sorted structure or heap. Rate limiter → per-key timestamps or counters.
5. Keep state private and return copies, so callers can't mutate internals.
6. Error contract: throw specific errors or return specific status codes exactly as the tests expect.

Treat the test file as the API doc. If a test expects 201 and { id }, that's the spec, even if you'd design it differently.