Launch Route Fallbacks

Last updated: 2026-06-02

Purpose

task-0594 standardizes launch-critical loading.tsx and error.tsx route states so dashboard, case workspace, portal, communications, documents, billing, integrations, and AI/automation flows have consistent recovery UX, accessible status roles, and Sentry tagging.

Shared components

• LaunchRouteLoading renders a route-level status region, user-facing loading copy, and layout-specific skeletons for dashboard, table, cards, documents, case workspace, and portal surfaces.
• LaunchRouteError renders a route-level PageError, logs the segment failure to Sentry with a route_area tag, shows the Next error digest when available, and supports both current unstable_retry and existing reset recovery callbacks.

Coverage

• Dashboard shell and dashboard analytics hub.
• Case workspace parent segment, covering nested case tools.
• Client portal parent segment, covering portal subpages.
• Communications, documents, billing, integrations, agents, workflows, and AI Co-Pilot entry points.

Usage rules

• Add route-specific copy at the route boundary, but keep layout and recovery chrome in the shared components.
• Prefer unstable_retry in new Next route error files; keep reset as a compatibility fallback only where existing route conventions need it.
• Use a parent segment fallback for large route families unless a child route needs a materially different loading or recovery experience.
• Do not add page-local spinner-only fallback UI for launch-critical pages. Use LaunchRouteLoading, PageLoading, or a Suspense fallback built from the shared skeleton primitives.

Verification

The shared route fallbacks are covered by src/__tests__/components/route-fallbacks.test.tsx.