Three files keep the portal from ever showing a blank screen

The portal has three fallback components and each one catches a different failure mode. The loading skeleton renders during server-side rendering while the page data is being fetched. It is a server component — no JavaScript, no state, just HTML with a pulse animation. The skeleton shapes match the real dashboard layout: a heading bar at 48 pixels wide, a subheading bar at 72 pixels, three summary cards in a responsive grid, and a large content area below. Every shape uses the same glass border and glass background as the real components so the skeleton feels like part of the portal, not a placeholder from a different design system. The error boundary is a client component because React error boundaries need component state to capture the error and the reset callback. If any server component or client component inside the portal throws, the boundary catches it and renders the error message with a Try again button. The button calls React's reset function which re-renders the errored component tree from scratch. The not-found page handles two cases with one sentence — This portal page does not exist or you do not have access. To a client, the distinction does not matter. Whether they typed a wrong URL or tried to access another client's project, the response is the same: a message and a link back to the dashboard. All three fallbacks share the same visual language. Centred text, accent-coloured interactive elements, 44-pixel minimum touch targets on every button and link. The error button uses the accent border. The not-found link uses the accent text colour. The loading skeleton uses the glass surface colours. Three files, fifteen lines each on average, and the portal never crashes to a raw error trace or a white screen.