Portal UX fixes: clean landing video player, outage-safe role verification, rebranded 404#903
Conversation
The landing video player on the builder, validator, and community
landings now shows only the media, the center play button, and the
bottom control bar. The copy overlay (eyebrow, title, description) and
the left-side darkening gradient that backed it are gone; the title
now serves only as the player's accessible label.
## Implementation Notes
- frontend/src/components/funnel/RoleLandingVideo.svelte: Removed the landing-video-copy block, its styles, and the horizontal sheen gradient layer; dropped the eyebrow/description props; the group now uses aria-label={title} instead of aria-labelledby.
- frontend/src/components/funnel/BuilderLanding.svelte, CommunityLanding.svelte, ValidatorLanding.svelte: Call sites pass only variant and title.
Backend failures were read as "not a member": a failed auth verify logged the user out for the session and wiped saved auth, a failed profile fetch cleared the loaded user, role-gated routes bounced members back to the start of their journey, and the journey pages could even fire the journey-start mutation for an existing member. Verification now distinguishes "couldn't verify" from a definitive rejection: only 401/403 (or sub-500 verify responses) demote the session or clear the user, while network errors and 5xx keep the current state and retry later. Role guards fail open on unverifiable membership since the backend enforces real permissions on every API call, and journey auto-start waits reactively for a loaded user profile instead of deciding at mount. ## Implementation Notes - frontend/src/lib/auth.js: performVerification only calls setAuthenticated(false) on sub-500 responses; network/5xx keeps state and leaves hasVerified unset so verifyAuth retries later. - frontend/src/lib/userStore.js: loadUser keeps the previously loaded user unless the failure is 401/403. - frontend/src/App.svelte: requireRoleForRoute returns true (fail open) when loadUser fails with a non-auth error instead of redirecting to the journey/funnel. - frontend/src/routes/BuilderJourney.svelte, CommunityJourney.svelte: journey-start moved from onMount to a one-shot $effect gated on a non-null user, so direct visits that mount before /users/me/ resolves still set the welcome marker, and outages never fire the mutation. - frontend/CLAUDE.md: Documented the guard error semantics under Routing.
The not-found view now uses the portal look: a mono "Error 404" kicker, a large display-font headline, muted body copy, and the standard rounded button pair (dark primary back home, bordered secondary to the contributions explorer). Navigation uses plain anchors handled by the router's link interceptor. ## Implementation Notes - frontend/src/routes/NotFound.svelte: Full rewrite with font-display headline, font-mono kicker, and CTASection-style buttons; dropped the push() click handlers in favor of intercepted anchors. - frontend/src/tests/NotFound.test.js, frontend/src/tests/routes.test.js: Assertions updated to the new copy (error 404, back to home).
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (14)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
0b80ce8 to
2fae1b0
Compare
2fae1b0 to
77b25cc
Compare
What changed
Landing videos show only the player
The video on the builder, validator, and community landings no longer renders the eyebrow, title, and description overlay. Only the media, the center play button, and the bottom control bar (play, time, seek, mute, fullscreen) remain. The left-side darkening gradient that existed to back the text was removed too; the title is kept solely as the player's accessible label.
Members stay recognized when the backend is down or overloaded
Under high load, backend failures were interpreted as "not a member", which produced a broken experience for existing members across all three roles:
/api/auth/verify/marked the user unauthenticated, deleted the saved auth from localStorage, and cached the logged-out state for the rest of the session./users/me/cleared the loaded user, so every role check (user.creator/user.builder/user.validator) returned false.The fix distinguishes "couldn't verify" from a definitive rejection everywhere:
Rebranded 404 page
The not-found view was rewritten in the portal design language: mono "Error 404" kicker, large display-font headline, muted body copy, and the standard rounded button pair (dark primary back home, bordered secondary to the contributions explorer).
Testing
npm run buildpasses.npx vitest run: 165 passed / 23 failed, matching the pre-existing baseline exactly (failures inProfile,api,routes,AuthButton,metapredate this branch on dev).