Story: Prototype the post-setup IAM journeys in ores.web

This story is a wayfinder map: an index of decisions. Each decision lives in its task. Tasks carry a [wayfinder:<type>] tag. Each task names its blockers in its goal. The frontier is every BACKLOG task whose blockers are all DONE.

• The journey catalogue names every post-setup IAM journey, with the member's journeys and the tenant administrator's journeys listed separately.
• Every journey has an accepted prototype, or a recorded reason it has none.
• Every IAM operation a person can perform is reachable through some journey.
• Every non-secret IAM field is visible or editable somewhere.
• No secret field reaches the browser. The forbidden fields are password_hash, password_salt, service_password_hash, totp_secret, every cleartext password field, and every JWT.
• Service-only operations are listed as out of scope, so the gap is deliberate.
• Every modeling error and every missing server-side operation a prototype exposed is recorded in the gap log.

• Charted 2026-09-23. This map supersedes the screen-per-entity approach. The generated TypeScript stays as the data and API layer; the screens are hand-crafted from journeys. Which artefacts are decommissioned is Decide what building material to reuse and what to decommission's to settle.
• Charted 2026-09-23. The member's journeys and the tenant administrator's journeys are separate journeys with separate screens. The journey is the unit of design, so the journeys are identified before any prototype is specified.
• Charted 2026-09-23. Prototypes follow the bootstrap pattern: one prototype/<journey> branch per journey, cut from feature/iam-screens-from-user-journeys.
• Charted 2026-09-23. The map stops at accepted prototypes. Implementing the screens is a later story.
• Charted 2026-09-23. Coverage bar: every IAM operation a person can perform is reachable through some journey, and every non-secret field is visible or editable somewhere. A prototype also records the modeling errors and the missing server-side operations it exposes.
• Charted 2026-09-23. System-administrator cross-tenant operations are a later map.
• Inventory the IAM functionality a journey can surface: account.image_id is a real profile picture into ores.assets, so a journey may show it. Contact details are one flat 1:1 child per account, not a hierarchy. login_info is current-state only and cannot carry a History screen. Accounts have no activate or deactivate, only locked. There is no forgot-password operation, no way for an administrator to end another account's session, and no subject for session statistics. The secrets are password_hash, password_salt, service_password_hash, totp_secret, every cleartext password field and every JWT.
• Formalise the IAM vocabulary and the screen rules: journey is already a project term – a server-stateful guided path – and user is not a term at all, only one value of account type. Screens are bound by entity_specification.org and component_specification.org, which live in projects/ores.web/modeling/. Neither UI document mentions journeys or steps, so the journey shape has no written rule yet. ux_language.org requires an event-log screen to be called Audit, never History.
• Inventory the reusable ores.web building material: AccountsPage.tsx and the mainline prototype tree are both already deleted, so the two rival implementations named in story Implement every IAM entity in the web client are gone. All eleven IAM entities sit on the shared entity shell and the BFF routes are uniform. The JourneyStep and JourneyPage renderer survives on the prototype branches and in git history.
• Create the user_journey document type: a journey is documented before it is built. Journeys live under doc/knowledge/journeys/<group>/journey_<slug>.org, grouped by logical topic, never by component. A PlantUML salt wireframe must not carry a title directive.
• Identify the post-setup IAM journeys: fourteen journeys in six topic groups. A journey is one person and one goal. The member's journeys and the administrator's journeys are separate. List, detail and history survive as primitives but are no longer per entity. Most journeys carry no server-side state.
• Document every post-setup IAM journey: done. Fourteen documents, each with a rendered salt wireframe and a coverage table. 105 claimed subjects were checked against the generated protocol and all exist; every id-link resolves. The exercise paid for itself: it found three server-side security defects, captured as Account secrets reach the browser in the accounts wire shape, Change-password ignores the current password and IAM handlers skip their permission checks, plus the design gaps the coverage tables record.
• 2026-09-23, after auditing every ores.iam data type and responsibility: the corpus was incomplete. Every entity was covered, which is why the gap was invisible, but four message families had no journey at all — login_messages, signup_messages, bootstrap_messages and reset_messages — and tenant_provisioning_messages had none either. Seven journeys were added: Sign in, Sign up, First run, New tenant, New party, Register a service account and Retire or reset a tenant. The corpus is now 21 journeys in 8 groups, with Entry and Setup as new groups. Every journey carries * Related journeys, which is a UI requirement rather than an editorial one: each entry becomes a link on the screen. The three setup journeys carry * Prototype and link the throwaway branches prototype/first-run-journey, prototype/new-tenant-journey and prototype/new-party-journey. The hub was renamed from "Journeys" to "User Journeys", because these are client-side journeys and a "journey" in ores.workflow is a different thing.
• Retire or reset a tenant found two more server-side defects, captured separately because they are defects rather than design gaps: the generic delete can terminate the system tenant (Delete can terminate the system tenant), because the guard lives in the lifecycle functions the generic path does not call; and suspension is not enforced anywhere on the sign-in path (Suspending a tenant does not suspend it), so a suspended tenant still admits its accounts.

• System-administrator cross-tenant operations: tenant create, update and delete, tenant provisioning, system bootstrap and system reset.
• The bootstrap and first-run journeys, which Prototype ORE Studio bootstrap in ores.web already covers.
• Service-only operations: service login, impersonation and the publish-from-dq triggers, except as notes in the gap log.

Abandoned at sprint 25 close. Sprint 26 orders the work as: codegen sync for each module, then user-journey analysis, then UX. New journey and UX stories start clean after the codegen pass. This story is not carried forward. The journey documents that this story produced stay in place as input to the journey pass.