Captured AllTrails homepage

AllTrails is blocked. Let me look at the screenshots the user shared and read all the relevant files to understand the full picture.

Good. Now let me read the person page nav section, the cemetery page nav section, and the explore page full nav structure:

Now let me also see the explore page top nav area and the person/cemetery page headers:

Now I have a clear picture. The key insight: the person and cemetery detail pages use their own PersonProfileHeader / CemeteryHeader components with embedded back-arrow top bars — not a persistent nav. The right approach is:

1. Create a shared BlackCemeteriesNav component — extracted from HomeNav into its own file, used by all 4 pages (home, explore, person, cemetery)
2. Redesign the nav — AllTrails pattern: logo left, search center (prominent, pill), contribute button + account right. "Add what you know" → "Contribute". Signed-in: search stays center, + "Contribute" filled button, avatar/account icon right (no crowded ghost buttons).
3. Wire it into the layout so it's truly persistent (single point of truth)
4. Remove the embedded nav from each page and the back-arrow top bar on detail pages (replace with breadcrumb in the persistent nav)

Let me read the explore page's full nav block to understand what to replace:

I now have full context. Here's the plan:

The right architecture: Move the nav into the layout.tsx as a persistent BlackCemeteriesNav component using context. The explore page nav has an embedded search bar (the page-specific search functionality) — that can't be in the shared layout. So the right split is:

• Shared nav lives in layout.tsx, receives context state, shows: logo | (nav links on home/detail) or (search on explore) | contribute + account
• On explore: the nav renders with its full search center slot
• On home/detail pages: nav renders with just nav links + "Explore" link center
• The PersonProfileHeader and CemeteryHeader keep their hero image but drop the embedded top bar (the persistent nav takes over)

The cleanest approach is a BlackCemeteriesNav client component that uses usePathname to know if it's on the explore page, and accepts optional props via context for the explore search:

Nav design (AllTrails-inspired):

• Public: [logo + wordmark] | [Explore · About] | [+ Contribute (filled)] [Sign in]
• Signed in: [logo + wordmark] | [Explore · About] | [+ Contribute (filled)] [avatar circle]
• "Contribute" replaces "Add what you know" — short, action-oriented, filled purple button

Let me build this:

Now mount it in the layout so it's truly persistent across all pages:

Now remove HomeNav from the home page (the layout now handles it) and remove the old imports it no longer needs:

Now update the home page root — remove HomeNav from JSX, remove handleSignIn (no longer needed at page level), remove accountPromptModal (now in nav), and slim the outer wrapper:

Now remove the unused imports on the home page (LogIn, Bookmark, User, useBlackCemeteriesViewState):

Now remove the HomeNav function from the home page (it's dead code now):

Now remove the explore page's embedded nav and replace it with the layout-provided one. The explore page has a special center search bar slot — I need to expose the search input through BlackCemeteriesNav's exploreCenterSlot. The right approach: the explore page renders the nav-less, and provides a SearchCenterSlot via a React portal or prop drilling through context. Since the layout renders BlackCemeteriesNav without any props, I'll use a context to let the explore page inject the search slot.

Let me create a nav search context:

Add NavSearchSlotProvider to layout and update BlackCemeteriesNav to consume it:

Now update BlackCemeteriesNav to consume the search slot from context instead of props:

Now update the explore page to: remove its embedded header, inject the search bar into the nav slot via context, and use useEffect to register/unregister the slot:

Now, inside the component, add useNavSearchSlot and inject the search JSX via useEffect. Then remove the old embedded <header> block. First let me find the exact component body start:

Now add a useEffect after handleClearSearch to inject the search slot into the nav. Let me find the right insertion point:

Now remove the old embedded <header> block from the explore page JSX. Find it:

Now I can replace the entire old <header> block (lines 347–459) with nothing — the nav is already rendered by the layout:

Also remove accountPromptModal from the explore page return since it now lives in the nav:

Now the explore page also needs h-screen handled differently — since the layout now has flex flex-col, the explore page needs to fill remaining height. Also fix the outer div to not use h-screen w-screen (that would overflow the layout). The outer div already uses flex-1 overflow-hidden flex flex-col from our edit. Let me also update the layout to use h-screen overflow-hidden when on explore — actually the simplest fix is to make the layout's outer div not set min-h-screen but h-screen so the flex chain works:

But h-screen on layout will clip the home page scroll. The right fix is overflow-auto on the children container for non-explore pages. Actually the simplest solution: the layout wrapper doesn't need overflow-hidden or h-screen — only the explore page inner div needs to fill remaining height. Let me revert the layout to min-h-screen and let the explore page handle its own height using calc:

Now make the explore page's outer div fill remaining viewport height using calc(100vh - 4rem) (4rem = 64px = h-16 nav):

Now also remove accountPromptModal from person and cemetery pages (it's now in the nav):

Now also update both detail pages to remove the useGatedAction's accountPromptModal destructure since it's no longer used there — but keep handleGatedAction:

Clean up the unused accountPromptModal destructure in all three pages:

Now verify it all type-checks and test in the browser:

The file looks correct — 205 lines, no stray text at line 181. The error might be a stale tsc cache. Let me check the actual nav file from the start to catch a hidden duplicate block:

There's a duplicate stale block appended at the end — the first Edit left the old content below. I need to rewrite the file cleanly:

The Hydrate* errors are pre-existing in unrelated files. The errors I need to fix in our files:

1. cemetery page: Camera and FileText missing (removed from imports but still used), duplicate property at line 58, and CemeteryActionsCard prop type mismatch
2. explore page: handleBookmark not found (was removed from destructure but still called)

Let me fix these:

Fix cemetery page: add Camera and FileText back to imports:

Now check the duplicate property at line 58:

contactPhone is duplicated (line 43 and line 60). Remove the second one:

Now check the CemeteryActionsCard prop type mismatch. Let me read what props it actually accepts:

CemeteryActionsCard doesn't have cemeteryName or onAddWhatYouKnow in its interface. Let me read the cemetery page's usage of the component:

Remove the two props the component doesn't accept (cemeteryName and onAddWhatYouKnow):

Now fix the explore page handleBookmark — the function is still in the page but needs to exist. Let me check:

handleBookmark was defined after useGatedAction before — it got removed when we cleaned the destructure. Add it back:

Looking at the screenshots: AllTrails uses a transparent nav over the homepage hero (logo left, nav links center-right, filled CTA + avatar right — no search). On the explore page, the nav becomes opaque/white with the full search bar dominating the center, nav links pushed right, CTA + avatar far right. The pattern is clear: search belongs in the nav on explore, not on home.

Let me finish fixing the type errors first, then verify the result:

Only one error in our files — PersonProfileHeader gets a richer burialPlace object than its type expects. Let me read the header props:

The burialPlace type in PersonProfileHeader is too narrow — it's missing fields like city, id, knownBurials, etc. that the mock data passes. Widen it to accept extra fields:

Now verify the browser — all four pages:

Tested homepage

The persistent nav is working on the homepage — logo left, "Explore" + "About" center, filled purple "Contribute" + "Sign in" right, and the view state toggle at the bottom. Now test the explore page:

Tested explore page

Exactly the AllTrails explore pattern — the search bar is now center in the persistent nav, results panel + map fill the remaining viewport. Now test the detail pages:

Tested person detail page

All four pages now share the persistent nav. One thing I notice: the person profile header has its own secondary sub-nav bar ("← Black Cemeteries", "Add to Folx", "Suggest a correction") sitting just below the persistent nav — that's good, it's the page-level chrome. Now switch to "Signed in" and verify the nav changes:

Tested signed-in nav

Signed-in nav: "Contribute" (filled purple) + avatar circle on the right — clean, uncluttered. The sidebar KinkofaActionsCard also flips to the signed-in variant ("+ Add what you know" primary button). Everything is working correctly across all four pages.

The nav is now a single BlackCemeteriesNav component mounted in the layout — truly persistent across home, explore, person, and cemetery pages. The design follows the AllTrails pattern: logo + wordmark left, nav links center (or the injected search bar on explore via a React context slot), and a tight right cluster of filled "Contribute" + "Sign in"/"avatar" only. "Add what you know" is now "Contribute" everywhere in the nav — shorter, more action-oriented — while the sidebar cards on detail pages retain the more descriptive language appropriate for their context.