feat(header): reflect signed-in state in the marketing header

[sweetmantech]

What

The marketing site header always rendered Sign In + Sign Up, even for a user who is already signed in. This makes the header reflect the signed-in state: once Privy resolves and the user is authenticated, the header shows a single "Open app" CTA (→ siteConfig.appUrl) instead of the sign-in/sign-up pair. The mobile menu's auth link swaps to "Open app" too.

Changes

• components/layout/Header.tsx
  • Read auth state via usePrivy() (ready, authenticated).
  • signedIn = ready && authenticated — gated on ready so the server render and first client render both show the signed-out CTAs, avoiding a hydration mismatch; the header then swaps in place once Privy resolves.
  • Desktop: signed-in → one primary "Open app" pill; signed-out → existing Sign In (outline) + Sign Up (primary).
  • Mobile menu: the auth link reads "Open app" when signed in.
• app/layout.tsx
  • Move <Header /> inside <PrivyAuthProvider> so the header can consume Privy context (it previously sat outside the provider). The provider is documented SSR-safe — it renders a plain context on the server — so pages stay statically prerenderable.

Achromatic chrome preserved (no new color); reuses the existing pill styles per DESIGN.md.

Verification

• pnpm exec tsc --noEmit — clean for both changed files.
• pnpm build — compilation + TypeScript pass (✓ Compiled successfully, Running TypeScript ...).
• Full static export could not complete locally: prerender throws Cannot initialize the Privy provider with an invalid Privy app ID because there is no real NEXT_PUBLIC_PRIVY_APP_ID secret in this environment (Privy rejects placeholder IDs at init). This is pre-existing and env-driven — PrivyAuthProvider already wraps every page on main, so any static page throws the identical error without the production secret; it is not introduced by this change. Vercel builds/previews with the real app id prerender normally.
• Visual confirmation of the signed-in swap on a Vercel Preview (with the real Privy app id) recommended before merge.

Scope

Implements only the "marketing header signed-in state" slice of the P3 long tail in chat#1885. Explicitly out of scope (remaining P3 follow-ups): bash/skill tool components, and "Unknown artist" rows (needs song_artists ingestion).

Targets main. Part of chat#1885.

🤖 Generated with Claude Code

---

Summary by cubic

Make the marketing header reflect the signed-in state. When Privy resolves, show a single “Open app” CTA instead of “Sign In” + “Sign Up”, and update the mobile menu.

• New Features

  • Read auth via usePrivy (ready, authenticated) from @privy-io/react-auth; use signedIn = ready && authenticated to avoid hydration mismatch, then swap to “Open app” linking to siteConfig.appUrl.
  • Mobile menu auth link shows “Open app” when signed in.

• Refactors

  • Wrapped <Header />, <Footer />, and ViewModeBar inside PrivyAuthProvider in app/layout.tsx so the header can consume Privy context (SSR-safe).

^{Written for commit 5f0e193. Summary will update on new commits.}

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
marketing	Ready	Preview	Jul 23, 2026 11:21am

[coderabbitai]

Warning

Review limit reached

@sweetmantech, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43c530bc-5cbb-48b9-86ae-6da7dc7272b2

📥 Commits

Reviewing files that changed from the base of the PR and between 61e79f0 and 5f0e193.

📒 Files selected for processing (2)

• app/layout.tsx
• components/layout/Header.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/marketing-header-signed-in

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[sweetmantech]

Preview verification — 2026-07-27

Preview: https://marketing-4bbca0fux-recoup.vercel.app — built from 5f0e1930 (PR head, sha-filtered deployment 5571473385, state success).

Results

#	Check	Expected	Actual	Result
1	Server-rendered HTML, signed out	Sign In + Sign Up, no "Open app"	exactly that — curl on the raw HTML returns 1× Sign In, 1× Sign Up, 0× Open app	✅
2	After hydration, signed out	unchanged	still Sign In + Sign Up, both → https://chat.recoupable.dev	✅
3	Signed in	single Open app CTA	Open app → https://chat.recoupable.dev; both sign-out CTAs gone	✅
4	Mobile menu variant	Open app replaces Sign In	DOM shows two nodes: the desktop CTA and the sm:hidden menu link, both reading Open app	✅
5	Footer + ViewModeBar inside the widened Privy boundary	render normally	full footer (nav columns, socials, legal) + theme toggle render on every page checked	✅
6	Privy modal on the marketing origin	opens, brand-themed	opens with the light-mode wordmark and email-only login	✅

Signed out

Signed in

Row 1 is the one worth calling out: the ready && authenticated guard does what its comment claims. The server render and the first client render both produce the signed-out CTAs, so there's no hydration mismatch — the swap happens in place once Privy resolves.

How the signed-in state was reached (and the caveat that comes with it)

The marketing header has no login control of its own — it only links out to chat. The single login() trigger in the whole app is inside useCatalogValuation, so signing in on this origin required running the valuation flow.

I first tried the zero-side-effect route: reusing a browser context already authenticated against a chat preview. It stayed signed out. localStorage is origin-scoped and the two previews are unrelated domains (marketing-*.vercel.app vs chat-*.vercel.app), so no session carries over — even though both use the same preview Privy app (cmc52us2g…).

That means this preview cannot reproduce the production condition this PR actually targets: a session established on chat.recoupable.dev being read by recoupable.dev, which works only because they share a parent domain. What's verified here is that the component logic is correct given an authenticated Privy session on the same origin. The cross-subdomain half — the chat#1801 gap — still wants a confirmation on prod after merge: sign in at chat.recoupable.dev, then load recoupable.dev and check the header reads Open app.

To keep the forced valuation cheap I picked the smallest artist I could find — Sound of Fractures StemsDAO, 5 followers. The run returned $389 (range $267–$547) across 6 measured tracks, and it also confirms the flow still works end-to-end under the reparented provider.

Note on the app/layout.tsx reparenting

Header, Footer, and ViewModeBar all move inside PrivyAuthProvider. Row 5 covers the render check. Worth a reviewer's eye on prerendering specifically: PrivyAuthProvider's docstring says it "renders a plain context on the server, so pages stay statically prerenderable (chat#1798, chat#1814)" — that property is what makes this move safe, and it held on every page I loaded here, but it's the thing to watch if a future change makes the provider client-only.