Story: Implement the access journeys in ores.web

The first three Access journeys run in ores.web against the real server:

• Know what I may do — the member reads the roles they hold and the permissions those roles carry.
• Change someone's access — the tenant administrator grants and revokes a colleague's roles.
• Shape the role catalogue — the tenant administrator defines roles and the permissions each one bundles.

The fourth journey, Ask for more access, is Land the role request journey, split out at the sprint 26 close on 2026-10-05.

This is the fifth group of Implement the user journeys in ores.web. It reuses the journey runtime the Setup group landed and adds no journey entity. The journey documents stay with the extraction pass, except where this group's survey proves one wrong.

Three of the four documents were written on 2026-09-23, before the IAM clean standard and the security hardening, and two of the gaps they record have already closed: iam.v1.roles.assign checks iam::roles:assign now, and the account's credential fields are :no_wire:, so no read returns them. What is left is a shorter and sharper list, and the build is sized from the survey rather than from the documents as they stand.

On 2026-10-05, at the sprint 26 close, this story was reworded to the three journeys it delivered and closed DONE. The fourth journey, the role request, is Land the role request journey, and the task Land the role request moved there.

• Every claim in the four journey documents is checked against the tree, and every gap is either closed with its evidence or still open with the subject that would close it.
• A member reads only their own access: the role reads are self-scoped or permission-gated, and a test proves that another account's access is refused.
• A role's permission bundle can be written, so the catalogue journey can save what it composes rather than reading it back unchanged.
• An assignment read exists, so who granted a role, when, and why is visible to the member and to the administrator from the same answer.
• The three journeys run in ores.web against the real server, and the shell reaches the same subjects for the operations it carries today.

The survey comes first and the reads come second, because the documents are older than the code they describe and a screen drawn from a stale gap list builds the wrong thing.

• The survey precedes the build. Three of the four documents predate the clean standard that changed the code they describe, and two of their gaps have closed without anybody saying so. A build sized from the documents as they stand would re-do work that is done and miss what is left.
• The reads are closed before any screen shows them. A read that proves only a session and takes an arbitrary account id lets a member read a colleague's access. That is a defect with a screen in front of it, so it is fixed at the subject rather than guarded in the browser.
• The catalogue's write is one subject, not a screen. The journey's whole gap is that a role's permissions can be read and not written, so the unit is the write and its permission, and the screen is the group's own screen task.
• The bundle write takes the whole set. The screen knows the set it wants, not the difference, so one call carries the complete bundle: what is missing is added, what is unticked is removed, and sending the same set twice changes nothing. An add and a remove would make the screen compute a difference and then depend on both landing.
• A role's fields and a role's bundle are separate permissions. iam::roles:write guards the role's own fields and iam::roles:update guards what the role grants, which is what the seeded descriptions already said. An administrator can shape what a role grants without being able to rename or delete the role itself.
• The caller's account id is resolved from the actor, in one place. The request context carries the JWT's username, and the database-backed check and every self read are keyed by account id. Reading the username as a uuid failed every live access request, so the service joins the two once and the subjects take the id it returns.
• A cross-sprint group closes DONE and gets a successor. The programme's rule applies here: if the role request's waiting state does not land in sprint 26, what lands is recorded and the rest continues in a successor story.
• The role request's waiting state belongs to ores.workflow. The journey says so: a request that waits on a person keeps its state as a workflow instance, and the engine has no state that means "a person decides" yet. That is a workflow decision with a workflow owner, recorded here and not assumed.
• Both clients reach one operation. ores.web and ores.shell call the same subjects, so the group carries the shell side of its journeys and does not move the disagreement to the other client.
• A journey a person cannot reach from a screen is not finished. The four documents each carry a * Related journeys list, and each entry is a link on the screen. A screen that omits them has not implemented the journey.
• The screens follow the accepted contracts. The UX language, the UI design principles and the TypeScript Clean Standard bind the work. The entity specification is void and binds no screen.

• The journey extraction and the journey documents, which Extract the user journeys that replace the ores.qt screens owns, except where this group's survey proves one wrong.
• The notification that tells an administrator a request is waiting, and that tells the member the answer. The journey records it as a gap of its own.
• The approval workflow behind system.signup_requires_authorization, which is a workflow in ores.workflow and the Entry group's recorded gap.
• Two-factor authentication, and the credential journeys' screens, which are the Credentials group's.