Design route order

Before choosing a tool or writing more code, make the requirement concrete. The literal /notes/new route appears before /notes/:id, and the final not-found handler runs only after every router declines.

Express evaluates routes and middleware in registration order, which makes order part of application behavior. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to register broad parameter or wildcard routes first and debug why later handlers never run. The happy path may still work, which makes the mistake easy to miss. list concrete route examples, order the narrow matches first, and test the fallback explicitly. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Design routes that match intentionally, parse input from the correct location, and return one complete response. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Create a route table with conflicting paths, predict the handler for each request, and verify it with tests. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.