Design an API
One requirement, walked through the learning loop one decision at a time: consumers → resources → operations → contracts → errors → pagination → authorization → idempotency → versioning → observability → review. Engineer Atlas grades the reasoning, assembles your decision log, and hands the result to four review lenses and the failure simulator.
The requirement
Build the API for a project-management product. Users create projects, invite members by email, assign roles, remove members (or leave), and delete projects. A web app ships first, a mobile app three months later, and partners have asked about integrating within the year.
Requirement→Consumers→Resource Model→Style→Contract→Validation→Authorization→Errors→Idempotency→Pagination→Versioning→Observability→Evolution→Trade-offs
→→→→→→→→→→
Step 1 · Consumers
Who is this contract for — and which of them can you never call when it changes?
What you know
Nothing is designed yet. The product brief names a web app now, a mobile app in three months and partners "within the year".