Navigation and hubs

SupaCloud’s navigation is organised around the work you do, not the system’s internal structure. Closely-related surfaces sit together, four feature families each collapse into a single hub route, and the whole sidebar fits a phone. Understanding the shape makes it obvious where any feature lives.

Route hubs

A hub is one route that folds several related surfaces into one page with a top pill-rail of sub-tabs. Instead of a separate sidebar entry per feature, you open the hub and pick a tab. Four hubs cover the families that used to scatter:

Hub	Route	Sub-tabs
Build	/build	Workflows · Scripts · Apps · Schedules
Reports	/reports	Overview · Usage · Delivery · Audit · Operations · Scheduled reports
Inbox	/inbox	Notifications · Review/Approvals · Proposals
Intelligence	/intelligence	Councils and the evaluation surfaces

The hub route is the canonical URL. The first tab is the hub landing — opening /build lands on Workflows, and the other tabs live one segment deeper (/build/scripts, /build/apps, /build/schedules). A new build primitive or reporting surface arrives as a new tab inside its hub, not as a new sidebar entry, so the navigation never regrows into a flat list.

Triggers are not a hub

Workflow triggers have no hub of their own — a trigger is defined implicitly inside the workflow that consumes it. The prominent integration surface is Connections (/resources), the credential and integration store that stands beside Build as the second automation surface.

The grouped sidebar

Top-level entries are organised into named groups that follow your mental model:

• Overview — Dashboard (/) and Inbox (/inbox).
• Work — Tasks (/tasks), Runs (/runs), Backlog (/backlog) and Projects (/projects). Projects join Work because project organisation is the home of the backlog.
• Automation — Build (/build) and Connections (/resources).
• Evaluate — Reports (/reports) and Intelligence (/intelligence).

Marketplace is a singleton: it stands ungrouped, set off by a divider rather than wrapped in a one-item group that would only add noise. The footer carries the utility surfaces — Web Terminal (/cli) and Settings (/settings) — and an admin-gated slot near the bottom holds the Owner console (/admin) and the Operator console (/operator), which appear only when your account is an instance admin.

Where runner management went

Runner management is operator configuration, not a day-to-day work surface, so it folds into Settings rather than holding its own top-level entry.

Old links still resolve

The navigation is a clean cut: there is no parallel old menu alongside the new one. To keep existing bookmarks and deep-links working, each retired top-level route keeps a thin redirect (HTTP 307) to its new home:

Old route	Redirects to
/workflows	/build
/scripts	/build/scripts
/apps	/build/apps
/schedule	/build/schedules
/councils	/intelligence/councils
/notifications	/inbox
/review	/inbox

The reporting routes redirect into /reports/* the same way. The redirect is a courtesy for an old link, not a second navigation surface — the canonical URL is always the hub route, so a shared link or screenshot should point at the hub (/build, /reports, …) rather than the redirect path.

On a phone

A phone gets a fixed bottom bar of the few global root destinations — Dashboard, Tasks, Build and Reports — plus a Menu sheet that holds everything else (Inbox, Backlog, Projects, Connections, Intelligence, Marketplace, and the footer utilities). The bottom bar stays fixed and global; it never switches per hub. A hub’s sub-tabs render as the same top pill-rail on mobile as on desktop, so opening Build on a phone still gives you the Workflows · Scripts · Apps · Schedules tabs.

---

This information architecture is defined in ADR 0055 and composes with the ubiquitous-language model in Workspaces and Organizations.