Audit register/account/console access model for organization managers

[wauputr4]

Context

Product clarification from Multica PEN-82:

• Default registered users are organization managers, not generic organization members.
• Register/account should be oriented around organization management onboarding.
• A newly registered/default user should not see or access the full owner console until they have an approved organization role or another valid management state.
• The current distinction between ordinary registered user, org owner/admin, member/viewer, /account, /console, and /admin is confusing and needs an audit.

Goal

Audit and clarify the access model, UX, and documentation for registered organization-manager users versus approved organization owners/admins.

Scope

• Audit registration/account copy and routing assumptions: default user = organization manager onboarding, not member profile.
• Audit /account CTA visibility and copy for users with no approved organization role.
• Audit /console access and empty state for unauthenticated users, default registered users, pending claim users, rejected claim users, approved owner/admin users, member/viewer users, and superadmin.
• Ensure default registered users cannot see full owner/admin features until allowed by role/state.
• Define expected feature visibility for each user state.
• Clarify whether users with pending create/claim flow should see onboarding/status only, not full management tools.
• Update docs to distinguish /admin superadmin/global workspace, /console org-scoped owner/admin workspace, and /account onboarding/status surface.
• Identify backend/API guard gaps and frontend-only hiding risks.

Acceptance criteria

• A role/state matrix exists for registration/account/console/admin access.
• Product copy states that registration is for organization managers/onboarding, not generic members.
• Default registered users without an approved org role see onboarding/status paths only.
• Approved org owner/admin users can access only their scoped organization console.
• Member/viewer behavior is explicit and documented.
• Backend permission expectations and frontend navigation expectations are aligned.
• Follow-up implementation tasks are created if the audit finds gaps.

Related

• Organization onboarding/create epic: Epic: Add organization creation onboarding flow #81
• Admin organization field audit: Pre-release: Complete admin organization create/edit fields audit #42
• Auth/claim API hardening: Pre-release: Harden auth and organization claim API behavior #41