chrome: navbar home-route check assumes single locale, no basePath

[yigitdot]

Tracking comment from Gemini's review of #114.

Background

After #114, components/site/Chrome.tsx derives the navbar tone from:

const effectiveActive = pathname === "/" && scrolled ? active : "intro";

The pathname === "/" literal is correct today — the static export ships a single locale and next.config.ts has no basePath. If we ever add either, this check (and any other Chrome.tsx guard that conflates "home" with the literal "/" route) will silently mis-fire and the original #112 symptom returns: the navbar paints in a dark-section tone on what is functionally the home page.

When this matters

Before adding any of:

• i18n routing (/en/, /de/, …)
• a basePath in next.config.ts
• any other prefix-rewriting layer that changes the home pathname

…audit components/site/Chrome.tsx for pathname === "/" and replace it with a routing-aware home check (e.g. strip locale prefix from pathname before comparing, or thread the home route through a config helper).

Out of scope for #114; filed so the assumption is documented and discoverable.

[github-actions]

🎯 Agentic Issue Triage

Type: Technical debt / forward-compatibility guard
Component: components/site/Chrome.tsx
Urgency: Low — no current breakage; only matters before adding i18n or basePath

This issue documents a hardcoded pathname === "/" assumption in Chrome.tsx that correctly identifies the home route today, but would silently regress (restoring the #112 navbar tone bug) if i18n locale prefixes or a basePath are ever introduced.

📍 Affected code

// components/site/Chrome.tsx
const effectiveActive = pathname === "/" && scrolled ? active : "intro";

usePathname() from Next.js returns the path after the basePath but including locale prefixes (when i18n routing is enabled). So /en/ would not match "/", causing effectiveActive to always resolve to "intro" — the navbar would never adopt the scroll-driven dark-section tone on the home page.

🛠️ Suggested fix approaches

1. Strip locale prefix before comparing — extract locale from pathname (e.g. via next/navigation's useLocale() when i18n is added) and compare the de-prefixed path:

   const isHome = pathname.replace(/^\/[a-z]{2}(-[A-Z]{2})?(?=\/)/, "") === "/";

2. Config helper — add a isHomePath(pathname: string): boolean utility in lib/links.ts (or a new lib/routing.ts) that centralises the check and can be updated in one place when routing changes.

3. Use useSelectedLayoutSegment() — if the home page has a distinct layout segment, this avoids string-matching entirely.

Option 2 (config helper) is the cleanest long-term approach and makes the intent explicit.

✅ Checklist when addressing

• Audit components/site/Chrome.tsx for all pathname === "/" occurrences
• Replace with a routing-aware isHome helper
• Add the helper to lib/ (e.g. lib/routing.ts) and export it
• Verify: pnpm lint && pnpm exec tsc --noEmit && pnpm test && pnpm build
• Smoke-test navbar tone on /, /blog/, /blog/[slug]/ after change

🔗 Related issues

• fix(nav): drop stale dark tone on non-home routes #114 — PR that introduced this check (fixing Navbar renders with stale dark-section tone on /blog/ (invisible against paper) #112)
• Navbar renders with stale dark-section tone on /blog/ (invisible against paper) #112 — Original navbar stale-tone bug on /blog/

Generated by Agentic Triage for issue #115 · ● 2.6M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@c7d030cd6d4607b90d9ac3ffc8b24aff4f251632

[yigitdot]

Audited against current main as of 2026-05-25 alongside the #117 work in #137. The pathname === "/" literal was the only home-route check in Chrome.tsx; the assumption still holds (no basePath, no i18n routing in next.config.ts).

#137 extracts that check into resolveActiveSection(pathname, scrolled, observed, fallback) in components/site/chrome-active.ts — when this issue is actioned, the routing-aware fix collapses to changing that helper (and its unit tests) in one place.

Leaving open as the tripwire the issue was filed to be.