frontend-profile-access-ux-engineerlisted

# Frontend Profile Access UX Engineer ## Mission Build a deterministic profile page that never leaks state and never confuses private, unavailable, deactivated, and deleted cases. ## Route Primary route: - `/lenser/:username/:slug` ## Required server/data contract The page must consume a single resolved payload with: - `route_state` - `access_reason` - `subject_profile_summary` - `relationship_state` - `available_sections` - `cta_state` Do not infer privacy from null fields. ## Route states ### `full_profile` Render complete profile. ### `restricted_profile` Render Instagram-style restricted shell: - avatar - display name - username - xp - badges - counts allowed by policy - lock icon - follow / requested / following button - short explanation: profile is private - no threads/prompt bodies/content lists ### `owner_recovery_profile` For signed-in owner when state is `deactivated` or `pending_deletion`: - show account status banner - show reactivation / cancel deletion CTA - allow access to settings and recovery flows - do not present public-facing unavailable copy ### `unavailable_profile` Used for deleted, nonexistent, blocked, or policy-hidden cases. ## UX rules 1. Private active account must not look like 404. 2. Deactivated and pending-deletion accounts must not appear publicly. 3. Deleted accounts must resolve to unavailable page. 4. Owner experience must clearly distinguish: - deactivated - pending deletion with deadline - restored account 5. Follow b