What this prototype argues

One screen, three panels: who you are, where you are acting, and where you can be. The journey document fixes the panels; the variants decide their arrangement.

• A · One place each (recommended). A card per party, and each card states the two things a member does to it — act for it, or make it the default. The actions sit with the place they change, so nothing depends on a selection made somewhere else.
• B · One list, one action bar. The parties are rows and the actions wait in a bar under them. Compact for many parties; it needs a selection that the member can lose sight of.
• C · Where I am, where I can be. The acting party and the identity sit in one column, the list in the other. Best when a member switches often; it repeats the acting party in both columns.
• The account menu is the entry point. Open it from the circle with your initials, top right.
• No party name can be read here today. The sign-in reply is the only read that returns a party name; the association read carries an id alone, and no read the screen may call turns one into the other. The names below are mock data.
• The switch works; the screen that uses it does not exist. POST /api/session/switch-party, api/client.ts and SessionProvider.switchParty are wired end to end, and the new-party journey is the only caller. The account menu has no entry point and no member screen offers the switch.
• The journey document says nothing in the web client switches party. That claim is stale: the call is wired and called. What is missing is the member's screen. The correction belongs to the extraction pass.
• Set as default is not reachable. iam.v1.ops.set_my_default_party exists on the server and has no BFF route, no client method and no control.
• Clearing the default cannot be asked for. The request carries a party id and no way to say "none", so the build draws no Clear default control. It is drawn here only to show what is missing.
• The association read has no client wrapper. account_parties.list_by_account_id is generated and nothing in the BFF or the wire client speaks it.
• A switch issues a fresh sign-in token, so the actions here are the session's, not the record's. Nothing on this screen holds state after the reply.