Add USER-WP-0036 for account situational awareness.

The account page currently presents the token tenant as membership. This plan separates login state, active sign-in, and allowed memberships.

Assistant: grok
Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f

workplans/USER-WP-0036-account-situational-awareness.md

@@ -0,0 +1,119 @@
+---
+id: USER-WP-0036
+type: workplan
+title: "Show allowed and active access on the account page"
+domain: communication
+repo: user-engine
+status: ready
+flavor: extension
+owner: grok
+topic_slug: user-engine
+created: "2026-09-26"
+updated: "2026-09-26"
+related: [USER-WP-0026, USER-WP-0028]
+---
+
+# USER-WP-0036 - Account situational awareness
+
+The signed-in account page mixes three different facts. The verified token
+names the tenant this sign-in is using. A portal membership row is access the
+portal has recorded. A tenant account written on first sign-in is neither.
+
+On 2026-09-26 a directory sign-in for `tenant:trial:demo-company` had a portal
+tenant account, no membership rows, and company admission from the directory
+group on the token. The account page showed that token tenant under "Tenant
+access" and then "No tenant memberships yet." Workload access listed nothing,
+because the page only reads memberships whose scope is an application,
+service, workload, or asset. The company application does not consult that
+list.
+
+A person may hold access to more than one tenant and more than one workload.
+An ordinary session uses one tenant at a time. Vendor roles, administrators,
+and a person hired by more than one vendor may have more than one tenant
+active, and each active tenant stays visible. Allowed access and active
+access are both shown. Login state is shown separately from either list.
+
+Allow, deny, and unavailable workload decisions stay with USER-WP-0026-T03
+and USER-WP-0028-T02. This plan does not infer those decisions.
+
+## Separate login state, active access, and allowed access
+
+```task
+id: USER-WP-0036-T01
+status: todo
+priority: high
+```
+
+On `/onboarding`, and in the signed-in home identity block, present three
+labelled situations in ordinary language.
+
+Login state names the verified portal identity, or says the portal session is
+absent. Say that this is the portal session and that an application can keep
+its own session. Do not infer identity from the URL.
+
+Active now is this verified token: its tenant, roles, and directory groups.
+An ordinary session has one active tenant. A tenant administrator,
+platform operator, platform root, vendor role, or multi-hire membership may
+have more than one tenant active, and each one is marked. Until the account
+carries one of those exception roles, show a single active tenant. Do not
+invent a new role catalogue to detect the exception.
+
+Allowed access is portal membership rows for this user. A tenant membership
+shows the tenant and kind. A workload membership is only a row whose scope is
+application, service, workload, or asset. An empty list says that nothing is
+recorded. A tenant account created on first sign-in is not a membership. The
+token tenant is not repeated as a membership. Remove the "Viewing <tenant>"
+line that currently does that.
+
+A workload with no catalogue decision is "not checked." That is neither
+access nor a denial. Do not copy a successful application login, a directory
+group, a platform role, or a tenant account into a membership to fill the
+list.
+
+The observed case renders as: signed in, one active tenant taken from the
+token, no allowed tenants, no allowed workloads, workload decisions not
+checked. Keep the layout readable on a phone.
+
+## Change the active tenant only through sign-in
+
+```task
+id: USER-WP-0036-T02
+status: todo
+priority: high
+```
+
+An ordinary user changes the active tenant through the existing
+reauthentication handoff, `/login?tenant_hint=`. The identity provider
+replaces the token tenant. After return, the page shows that tenant as the
+only active one and leaves other allowed memberships inactive.
+
+An exception role may show more than one active tenant. Those tenants still
+come from verified sign-in context. Do not add a control that marks a second
+tenant active inside the portal session alone. Recognize only roles and
+membership kinds the account already stores: `tenant-admin`,
+`platform-operator`, `platform-root`, and a vendor or multi-hire kind when
+one is already recorded.
+
+Switching tenant does not claim to end application sessions. The existing
+sign-out copy remains the place that explains a remaining shared sign-in.
+
+## Record the journey and prove the three situations
+
+```task
+id: USER-WP-0036-T03
+status: todo
+priority: medium
+```
+
+Update `docs/account-journeys.md` U01 and U09 so login state, active access,
+and allowed access are the contract. U10 keeps explicit reauthentication as
+the tenant switch.
+
+Add portal tests for signed-out, a token tenant with no membership, an
+allowed tenant that is not active, a recorded workload membership, and an
+exception role whose verified context has two active tenants. Assert that a
+tenant account alone does not appear as allowed access, and that an absent
+catalogue decision renders as not checked.
+
+Do not close USER-WP-0026-T03 or USER-WP-0028-T02 from this plan. They remain
+the owners of allow, deny, and unavailable workload decisions.