/dashboard is the app's canonical post-login / fallback route in eight places, but drb-frontend/app/dashboard/page.tsx does not exist. Every one of these lands the user on the Next.js 404 page:
app/login/page.tsx:34 — router.replace(orgId ? "/dashboard" : "/onboarding") — this is the normal sign-in path
app/onboarding/page.tsx:32
middleware.ts:31 — redirects an already-authed visitor off the login page
app/admin/page.tsx:1070, app/nodes/page.tsx:19, app/systems/page.tsx:1188, app/tokens/page.tsx:29, app/settings/layout.tsx:30 — the non-admin/non-operator guards
components/marketing/MarketingHeader.tsx:44,84 — the "Go to dashboard" button
Observed in prod (git_sha 861ea41, 2026-08-23): navigating to https://drb.cusano.net/admin ends on https://drb.cusano.net/dashboard showing "404 | This page could not be found."
app/ has no dashboard directory — the routes that exist are /live, /incidents, /map, /nodes, /systems, /calls, /alerts, /trips, /settings/*, /profile, /admin, plus the marketing pages. Looks like the redesign (chunk 4, navigation and routing, eaae452) renamed the landing route without updating the redirect targets.
Fix: pick the real post-login home (/live is what the nav treats as first) and replace all nine call sites, or add a /dashboard route that redirects. Grep guard: grep -rn '"/dashboard"' app components lib middleware.ts should return zero after the fix.
`/dashboard` is the app's canonical post-login / fallback route in eight places, but `drb-frontend/app/dashboard/page.tsx` does not exist. Every one of these lands the user on the Next.js 404 page:
- `app/login/page.tsx:34` — `router.replace(orgId ? "/dashboard" : "/onboarding")` — **this is the normal sign-in path**
- `app/onboarding/page.tsx:32`
- `middleware.ts:31` — redirects an already-authed visitor off the login page
- `app/admin/page.tsx:1070`, `app/nodes/page.tsx:19`, `app/systems/page.tsx:1188`, `app/tokens/page.tsx:29`, `app/settings/layout.tsx:30` — the non-admin/non-operator guards
- `components/marketing/MarketingHeader.tsx:44,84` — the "Go to dashboard" button
Observed in prod (git_sha 861ea41, 2026-08-23): navigating to `https://drb.cusano.net/admin` ends on `https://drb.cusano.net/dashboard` showing "404 | This page could not be found."
`app/` has no `dashboard` directory — the routes that exist are `/live`, `/incidents`, `/map`, `/nodes`, `/systems`, `/calls`, `/alerts`, `/trips`, `/settings/*`, `/profile`, `/admin`, plus the marketing pages. Looks like the redesign (chunk 4, navigation and routing, `eaae452`) renamed the landing route without updating the redirect targets.
Fix: pick the real post-login home (`/live` is what the nav treats as first) and replace all nine call sites, or add a `/dashboard` route that redirects. Grep guard: `grep -rn '"/dashboard"' app components lib middleware.ts` should return zero after the fix.
Wider than filed: two of the five nav destinations have no route at all either. components/Nav.tsx:19 links /watch and :25 links /network, and neither app/watch/ nor app/network/ exists — so "Watch" and "Network" in the primary nav both 404, same as /dashboard. That also left /systems and /tokens with no entry point anywhere in the UI, since the redesign moved them behind the Network hub that was never built.
Fix applied locally, all three together:
/dashboard → / at all 9 call sites (app/login, app/onboarding, middleware.ts, the app/admin / app/nodes / app/systems / app/tokens / app/settings/layout guards, MarketingHeader). / is the real signed-in home — app/page.tsx renders <LiveView/> for an authed user with an org, which is what the nav labels "Live".
app/watch/page.tsx — re-exports the existing alerts screen; /alerts stays reachable so old links keep working.
app/network/page.tsx — new hub: node/system counts, a "needs setup" badge off useUnconfiguredNodes, and cards through to /nodes, /systems, /tokens. Hooks all run before the admin/operator guard, per d041c86.
Verified with a full next build: 31 routes, /network and /watch both present, no /dashboard, tsc --noEmit clean.
Wider than filed: two of the five nav destinations have no route at all either. `components/Nav.tsx:19` links `/watch` and `:25` links `/network`, and neither `app/watch/` nor `app/network/` exists — so "Watch" and "Network" in the primary nav both 404, same as `/dashboard`. That also left `/systems` and `/tokens` with no entry point anywhere in the UI, since the redesign moved them behind the Network hub that was never built.
Fix applied locally, all three together:
- `/dashboard` → `/` at all 9 call sites (`app/login`, `app/onboarding`, `middleware.ts`, the `app/admin` / `app/nodes` / `app/systems` / `app/tokens` / `app/settings/layout` guards, `MarketingHeader`). `/` is the real signed-in home — `app/page.tsx` renders `<LiveView/>` for an authed user with an org, which is what the nav labels "Live".
- `app/watch/page.tsx` — re-exports the existing alerts screen; `/alerts` stays reachable so old links keep working.
- `app/network/page.tsx` — new hub: node/system counts, a "needs setup" badge off `useUnconfiguredNodes`, and cards through to `/nodes`, `/systems`, `/tokens`. Hooks all run before the admin/operator guard, per `d041c86`.
Verified with a full `next build`: 31 routes, `/network` and `/watch` both present, no `/dashboard`, `tsc --noEmit` clean.
Verified against the deployed tree this morning (live /health SHA a1bdccf):
Commit be79499 (2026-08-23) is a confirmed ancestor of the live SHA.
Searching drb-frontend/{app,components,lib} and middleware.ts for the string "/dashboard" returns zero hits. All nine former call sites now point at /. The only two surviving mentions anywhere in the tree are inside code comments describing the old behaviour, not routes.
No route in the frontend redirects to a non-existent /dashboard any more. Closing.
Ref be79499. Found by the 2026-08-25 unattended session while auditing tracker-vs-repo drift.
(An earlier version of this comment was posted with its formatting mangled by a shell-quoting fault in the session tooling. This is the corrected text.)
**Fixed and live — closing as tracker drift.**
Verified against the deployed tree this morning (live `/health` SHA `a1bdccf`):
- Commit **`be79499`** (2026-08-23) is a confirmed ancestor of the live SHA.
- Searching `drb-frontend/{app,components,lib}` and `middleware.ts` for the string `"/dashboard"` returns **zero** hits. All nine former call sites now point at `/`. The only two surviving mentions anywhere in the tree are inside code comments describing the old behaviour, not routes.
No route in the frontend redirects to a non-existent `/dashboard` any more. Closing.
Ref `be79499`. Found by the 2026-08-25 unattended session while auditing tracker-vs-repo drift.
*(An earlier version of this comment was posted with its formatting mangled by a shell-quoting fault in the session tooling. This is the corrected text.)*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
/dashboardis the app's canonical post-login / fallback route in eight places, butdrb-frontend/app/dashboard/page.tsxdoes not exist. Every one of these lands the user on the Next.js 404 page:app/login/page.tsx:34—router.replace(orgId ? "/dashboard" : "/onboarding")— this is the normal sign-in pathapp/onboarding/page.tsx:32middleware.ts:31— redirects an already-authed visitor off the login pageapp/admin/page.tsx:1070,app/nodes/page.tsx:19,app/systems/page.tsx:1188,app/tokens/page.tsx:29,app/settings/layout.tsx:30— the non-admin/non-operator guardscomponents/marketing/MarketingHeader.tsx:44,84— the "Go to dashboard" buttonObserved in prod (git_sha
861ea41, 2026-08-23): navigating tohttps://drb.cusano.net/adminends onhttps://drb.cusano.net/dashboardshowing "404 | This page could not be found."app/has nodashboarddirectory — the routes that exist are/live,/incidents,/map,/nodes,/systems,/calls,/alerts,/trips,/settings/*,/profile,/admin, plus the marketing pages. Looks like the redesign (chunk 4, navigation and routing,eaae452) renamed the landing route without updating the redirect targets.Fix: pick the real post-login home (
/liveis what the nav treats as first) and replace all nine call sites, or add a/dashboardroute that redirects. Grep guard:grep -rn '"/dashboard"' app components lib middleware.tsshould return zero after the fix.Wider than filed: two of the five nav destinations have no route at all either.
components/Nav.tsx:19links/watchand:25links/network, and neitherapp/watch/norapp/network/exists — so "Watch" and "Network" in the primary nav both 404, same as/dashboard. That also left/systemsand/tokenswith no entry point anywhere in the UI, since the redesign moved them behind the Network hub that was never built.Fix applied locally, all three together:
/dashboard→/at all 9 call sites (app/login,app/onboarding,middleware.ts, theapp/admin/app/nodes/app/systems/app/tokens/app/settings/layoutguards,MarketingHeader)./is the real signed-in home —app/page.tsxrenders<LiveView/>for an authed user with an org, which is what the nav labels "Live".app/watch/page.tsx— re-exports the existing alerts screen;/alertsstays reachable so old links keep working.app/network/page.tsx— new hub: node/system counts, a "needs setup" badge offuseUnconfiguredNodes, and cards through to/nodes,/systems,/tokens. Hooks all run before the admin/operator guard, perd041c86.Verified with a full
next build: 31 routes,/networkand/watchboth present, no/dashboard,tsc --noEmitclean.Fixed and live — closing as tracker drift.
Verified against the deployed tree this morning (live
/healthSHAa1bdccf):be79499(2026-08-23) is a confirmed ancestor of the live SHA.drb-frontend/{app,components,lib}andmiddleware.tsfor the string"/dashboard"returns zero hits. All nine former call sites now point at/. The only two surviving mentions anywhere in the tree are inside code comments describing the old behaviour, not routes.No route in the frontend redirects to a non-existent
/dashboardany more. Closing.Ref
be79499. Found by the 2026-08-25 unattended session while auditing tracker-vs-repo drift.(An earlier version of this comment was posted with its formatting mangled by a shell-quoting fault in the session tooling. This is the corrected text.)