Story: Move the IAM collections onto their areas
Table of Contents
This page documents a story in Sprint 29. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
The IAM entity collections answer under the area they belong to, and no two routes want the same path for different reasons.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 29 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-31 |
3. Acceptance
- Each IAM entity model declares the area the inventory decided for it.
- The generated routes, tests, recipes and hurl scripts state the new paths.
- The session door keeps its path and the generated session collection takes another, with the reason recorded.
- The iam tests build and pass, and the gates are green.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Move the IAM collections onto their areas | DONE | 2026-10-31 | 2026-10-31 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Move the IAM collections to access and auth | DONE | 2026-10-31 | 2026-10-31 | Initial task for: Move the IAM collections onto their areas |
5. Decisions
- The session door keeps
/api/v1/auth/sessionsand the generated session collection moves to/api/v1/access/sessions. The door mints the credential and the collection is the ledger an administrator reads, so they are different things that wanted one path. - A model that renders no route unit does not declare an area. The declaration would be inert and would read as a decision nobody can observe.
6. Result
The IAM collections answer on their published areas, the collision between the session door and the session collection is settled with a reason a reviewer can check, and the generated tests pass against the built unit. The operation routes are the remaining IAM work, and they need the declaration to reach operations rather than entities.