Validating in Reality — Prove Fixes Against the Live System

Illustrative transcript: this listing has no real server behind it. The commands are exactly what the skill runs; the outputs show the checks it performs against the fictional service described in the request. This is not a real run.

Summary. The bug reproduces. The handler applies the change in memory and returns it, but never calls save(), so nothing reaches Postgres. Two more holes showed up during the negative cases: any field in the body was assigned (including ownerId), and any authenticated user could patch any task. After the fix, the cURL returns 200, the row persists as done, and the negative cases return 400/401/404. UI not exercised (no frontend in this flow).

1. System is running

$ docker compose ps --format '{{.Service}} {{.State}}'
api running
db running

2. BEFORE: acceptance test (live RED)

$ curl -s -i -X PATCH http://localhost:3000/api/v1/tasks/42 -H "Authorization: Bearer <redacted>" -H "Content-Type: application/json" -d '{"status":"done"}'
HTTP/1.1 200 OK
{"id":42,"title":"Ship invoices","status":"done","ownerId":3,"updatedAt":"2026-10-08T14:02:11.000Z"}

$ docker compose exec db psql -U app -d tasks_dev -c "select id, status, owner_id, updated_at from tasks where id = 42;"
 id | status | owner_id |      updated_at
----+--------+----------+---------------------
 42 | todo   |        3 | 2026-10-01 09:15:40

The response says done and the row says todo. Bug reproduced.

Negative probe before the fix

$ curl -s -i -X PATCH .../tasks/42 -H "Authorization: Bearer <redacted:OTHER_TOKEN>" -d '{"status":"done","ownerId":5}'
HTTP/1.1 200 OK
{"id":42,...,"status":"done","ownerId":5,...}

User 5 got a 200 on user 3's task, and ownerId was accepted from the body. It isn't persisted today only because save() is missing. Adding save() alone would turn this into a live privilege escalation.

3. Fix

const ALLOWED_STATUS = new Set(['todo', 'in_progress', 'done']);

router.patch('/tasks/:id', auth, async (req, res) => {
  const { status, ...rest } = req.body ?? {};
  if (Object.keys(rest).length > 0 || !ALLOWED_STATUS.has(status)) {
    return res.status(400).json({ error: 'invalid_payload' });
  }
  const task = await Task.findOne({ where: { id: req.params.id, ownerId: req.user.id } });
  if (!task) return res.status(404).json({ error: 'not_found' });
  task.status = status;
  await task.save();
  res.json(task);
});

Regression tests are added alongside, following fixing-bugs: persists status, rejects unknown fields, 404 for a non-owner.

4. AFTER: same cURL, as given

HTTP/1.1 200 OK
{"id":42,"title":"Ship invoices","status":"done","ownerId":3,"updatedAt":"2026-10-08T14:09:52.000Z"}

Compared with BEFORE: status code unchanged (200), body unchanged except updatedAt. The real difference shows in the database.

5. Persisted state

$ docker compose exec db psql -U app -d tasks_dev -c "select id, status, owner_id, updated_at from tasks where id = 42;"
 id | status | owner_id |      updated_at
----+--------+----------+---------------------
 42 | done   |        3 | 2026-10-08 14:09:52

6. Negative cases

DB re-checked after the negative cases: task 42 still done, owner_id = 3.

7. UI

Not exercised: no frontend for this flow (per the request).

Validation status

In a real run this section would read: request + DB + negative cases checked, UI not exercised. Nothing above was executed for this listing.

Next steps

1. Run the project's automated suite and /verify gates. This live check sits on top of them and does not replace them.
2. Audit other task.set(req.body) call sites for the same mass-assignment pattern.
3. Save how this project starts and queries its DB as a learning, so the next validation starts at step 2.