Menu IA + page-width recommendation

1 · Route inventory

Every page under src/app/(app)/. “In menu?” = reachable from the desktop sidebar today.

2 · Menu-surface inventory · where they diverge

Four surfaces render navigation. They are not consistent today.

Divergences

• Sidebar Help Center → /faqs. Signed-out account menu Help Center → /help. Mobile sheet → /faqs.
• Mobile sheet has dedicated “Invite someone” + “Vouch for a member” entries that don’t exist in the sidebar.
• Mobile bottom bar uses “Dashboard”, sidebar uses “Host dashboard”.
• Mobile sheet does not consume NAV_GROUPS, so any sidebar change drifts here.

3 · Issues found

Eight concrete problems flagged during the route walk.

1. Network menu item is dead. Removed because /dashboard?tab=network 500s. The route file at /dashboard/network still exists and forwards to the broken target. Nothing in the sidebar surfaces vouch-network management today.
2. Pending invites is fully orphaned. /dashboard/pending-vouches has no link from any menu surface. Only reachable from notification deep-links or direct URL.
3. Three parallel invite flows. /invite (5-step), /invite/share (5-step + mode chooser), and VouchModal (component, exists-user vouching). Punchlist item 2 covers this.
4. Dashboard duplicates standalone pages. /trips ≈ /dashboard?tab=traveling · /proposals ≈ /dashboard?tab=proposals. Two URLs per concept means two places that can drift.
5. Legacy redirect files still on disk. /dashboard/traveling and /dashboard/network exist purely to redirect. They imply structure that doesn’t exist.
6. /help vs /faqs split. /faqs is the richer TOC-driven encyclopedia. /help is the older variant with FAQ list + contact form. Sidebar → /faqs; signed-out menu → /help.
7. Mobile sheet hardcoded. Not consuming NAV_GROUPS, so any sidebar IA work needs a parallel edit. Source of “Invite someone” and “Vouch for a member” surfacing on mobile but not desktop.
8. No “create” affordances in sidebar. Mobile sheet has “Create a listing” + “Invite someone”. Desktop sidebar has neither.

4 · Recommended menu

Adopts your first-pass structure. Five groups, divided by horizontal rules. One source of truth in nav-items.tsx that every surface consumes.

Why this works

• Groups read top-to-bottom in priority of where I am: explore → talk → travel → host → me.
• Dividers separate verbs (find / talk / travel / host / manage me), not arbitrary 3-item chunks.
• No “Network” black hole — the slot points to a real page.
• Same shape across desktop sidebar + mobile sheet + avatar dropdown.

5 · Decisions on open questions

Each question got a binding recommendation. Open to override — these are not locks.

5a · /help vs /faqs — revised

• /help = contact the team. Above the contact form, a FAQ search bar and a “Looking for answers? Browse the FAQs →” link. The form is the main affordance.
• /faqs = standalone, searchable knowledge base. At the bottom of the page, a “Still need help? Contact us →” CTA that links to /help.
• Cross-link everywhere. “Need help? Get in touch” buttons across the app point to /help. Sidebar “Help Center” entry → /help (the human-help front door; FAQ is one click away).
• Why this is better than collapsing: two distinct user intents (find vs. ask) each get a focused surface.

5b · Wishlists → Saved — revised

• Pre-launch — no SEO concern.
• Mechanical: rename the folder src/app/(app)/wishlists/ → saved/, update href references in nav-items.tsx, mobile-nav.tsx, account menu, “Add to wishlist” actions on listings. Possibly rename /api/wishlists/* → /api/saved/*.
• DB tables and column names stay (wishlist_listings etc.) — internal vocabulary doesn’t need to change.
• Add a redirect from /wishlists → /saved as a safety net for any deep links in the wild.
• Not a can of worms — couple-hour search-replace job inside one session.

5c · Dashboard tab duplicates + Listings handling — revised

• Sidebar Listings → /dashboard#listings (scroll-anchors to the listings section of the host dashboard). Same URL as Host dashboard, different scroll target.
• Tab primitive stays. UnifiedDashboard keeps its tab UI scaffolding — we just don’t render multiple tabs today. When Listings grows into its own page (deferred per 5f), promote it then.
• What gets stripped: traveling + proposals tab content from the dashboard. Legacy redirect files (/dashboard/traveling, /dashboard/network) deleted.
• Net: your proposed menu structure (two host items) is intact, and no future option is foreclosed.

5d · Sidebar Network slot — what page does it open?

Contents (one page, three sections):

1. Hero summary — vouch count, trust score, “New invite” CTA.
2. Your network — current NetworkSection content (1° / 2° / inner circle / vouch-backs).
3. Pending invites — pull in PendingVouchesList from /dashboard/pending-vouches. That route then dies or redirects.

• Three surfaces logically belong together.
• getNetworkData() already exists — fixing whatever makes the dashboard tab 500 unblocks the page.

5e · Profile photo as menu item — revised

• Avatar renders at the same dimensions as the existing Lucide icons in the sidebar (likely ~16–20px square, depending on the locked icon size).
• Same row padding, same hover state, same active-state treatment.
• No name label next to it — just “Profile”. Reads as a normal nav row with a personalized glyph.
• Click target = the Profile row → /profile. Account settings + Proposal alerts + Help Center stay as siblings underneath.

5f · Listings — standalone or stay as dashboard tab?

5g · Create affordances in the sidebar?

6 · Page-width tiers — revised

Loren’s note: form cards can stay narrow, but the heading + supporting copy + step indicators above them shouldn’t inherit that narrow width. Two separate concerns — outer page band vs. inner card width.

Revised: 3 outer tiers + a separate inner card primitive

Today: 15 distinct max-w-[...] values across pages. Target: 3 outer tiers (every page picks one) + a <FormCard> primitive for narrow form blocks inside a wider page band.

Plus a separate <FormCard variant="narrow" | "default"> primitive (≈480px / ≈680px). Form pages mount a general PageShell with a FormCard inside — the heading band is wide, the form itself stays narrow.

Re-bucketing every current page

7 · Build sequencing — revised

Multi-session workstream. Each session runs autonomously — no mid-flight check-ins. Surface ONE comprehensive review at the end of each session, with side-by-side proofs on key surfaces. M1 + M3 are lowest-risk and go first.