Add update-user endpoint

CLAUDE.md

@@ -0,0 +1,58 @@
+# CLAUDE.md
+
+Small Express API (CommonJS, Node's built-in test runner). Routes live in `routes/`, all data
+access goes through `db/store.js`, and `server.js` exports `app` so tests can import it without
+opening a port.
+
+- `npm test` — runs `node --test`
+- `npm run dev` — `node --watch server.js`
+- `npm run lint` — eslint
+
+Current task: add `PUT /users/:id` to `routes/users.js`, with the store helper it needs in
+`db/store.js`. `tests/update-user.test.js` is the spec — do not edit it.
+
+## Models
+
+Plan with **Opus**, execute with **Sonnet**.
+
+Use Opus in plan mode to decide the approach — which files change, how validation and the
+not-found path work, how the work splits into commits. Switch to Sonnet (`/model sonnet`) to
+write the code, run tests, and commit. If a plan turns out to be wrong mid-execution, stop and
+re-plan with Opus rather than improvising in Sonnet.
+
+## Commits
+
+One logical change per commit. Write the message from the actual diff — read what changed, then
+describe it; do not paraphrase the task description.
+
+Run `npm test` as you go, not just at the end. The `update-user` tests turn green once the
+endpoint is right; that is the signal the feature is done.
+
+Each message must be understandable without opening the diff. A reader scanning `git log`
+should know what changed and why.
+
+    Good:  Add updateUser helper to store, returning undefined for unknown ids
+    Bad:   Update store.js
+
+Do not bundle the store helper, the route, and `NOTES.md` into one commit — they are separate
+logical changes.
+
+## Review before the PR
+
+Before opening the pull request, review the changes yourself — `git diff main...HEAD` — and
+report what you find. Look specifically for:
+
+- bugs and edge cases (non-numeric `:id`, empty-string vs missing field, extra body fields)
+- the not-found path — 404, not a crash or a 500
+- the validation path — 400 with a clear error, matching the shape `POST /users` already uses
+
+Present what you flag as findings for me to judge. I decide what is real; fix those, and say
+plainly which ones I chose to skip.
+
+A green test run and a clean review are signals, not a guarantee. Do not describe the change as
+verified on the strength of passing tests alone — say what was actually checked and what was not.
+
+## PR
+
+The description must say what changed, why, and what a reviewer should test — including the
+not-found and invalid-input cases.

NOTES.md

@@ -0,0 +1,26 @@
+# Notes on the update-user endpoint
+
+**Plan.** Add `PUT /users/:id` to `routes/users.js` and a matching `updateUser(id, { name, email })`
+helper to `db/store.js`, following the exact shape of the existing `POST /users` route: validate
+`name`/`email` first (400 with the same error message format), then look the user up through the
+store (404 if it doesn't exist, matching `GET /users/:id`'s not-found handling), else update and
+return it. No changes to `tests/update-user.test.js`.
+
+**Model.** Sonnet for planning and execution — this was a small, well-specified change (one route,
+one store helper) with an existing pattern to mirror, so there was no design ambiguity that needed
+Opus's deeper reasoning; Sonnet was fast enough to plan and build in one pass.
+
+**Commits.** Split into three logical commits: `CLAUDE.md` (workflow documentation, unrelated to
+the feature itself), the `updateUser` store helper, and the route that uses it. Kept the helper and
+the route separate because they're independently reviewable/testable changes — the helper has no
+effect on behavior until the route calls it, so bisecting or reviewing either one in isolation makes
+sense. `NOTES.md` is its own commit since it's documentation, not code.
+
+**Review.** Self-reviewed the diff (`git diff main...HEAD`) before opening the PR. Checked: the
+not-found path (non-numeric `:id` becomes `NaN`, which cleanly misses every lookup and falls
+through to 404 instead of crashing), the validation path (matches `POST`'s exact error shape), and
+whether extra body fields could be abused (they're ignored via destructuring, so a client can't
+override `id` through the request body). Found no bugs to fix. One design choice worth noting: when
+both the id is unknown and a field is missing, the route returns 400 (validates before it looks up
+the user) rather than 404 — no test exercises that combination, so it was a judgment call, not
+something the tests forced.

db/store.js

@@ -24,4 +24,16 @@ function createUser({ name, email }) {
   return user;
 }
 
-module.exports = { getAllUsers, getUserById, createUser };
+function updateUser(id, { name, email }) {
+  const user = getUserById(id);
+
+  if (!user) {
+    return undefined;
+  }
+
+  user.name = name;
+  user.email = email;
+  return user;
+}
+
+module.exports = { getAllUsers, getUserById, createUser, updateUser };

routes/users.js

@@ -32,4 +32,22 @@ router.post("/", (req, res) => {
   res.status(201).json(user);
 });
 
+// PUT /users/:id — update an existing user; name and email are required
+router.put("/:id", (req, res) => {
+  const id = Number(req.params.id);
+  const { name, email } = req.body;
+
+  if (!name || !email) {
+    return res.status(400).json({ error: "name and email are required" });
+  }
+
+  const user = store.updateUser(id, { name, email });
+
+  if (!user) {
+    return res.status(404).json({ error: "User not found" });
+  }
+
+  res.json(user);
+});
+
 module.exports = router;