Frontend Apps

SterlingIndex has three shipped product frontends plus one standalone documentation app with different runtime assumptions:

• apps/www is the public marketing site and evaluation funnel.
• apps/docs is the public documentation site and architecture portal.
• apps/dashboard is the customer-facing product app.
• apps/admin-desktop is the active internal control-plane console.
• apps/legacy-admin is retained as the old hosted admin reference app.

Read this section to understand where routing lives, which app owns auth handoffs, where the documentation surface fits into the public-site boundary, and where the frontend layer stops and shared/backend contracts begin.

What To Read First

• Start with Marketing Site if you need the public-site shell, root-site routing behavior, or CTA/login handoff rules.
• Read Docs Site when you need the documentation app's Fumadocs shell, docs-host deployment model, or its shared login CTA behavior.
• Continue to Dashboard and Admin for the two React application shells, their data-loading strategies, and the split between customer product and internal operations.
• Follow with /docs/shared when the question turns from "which app?" to "which package or type contract?"

Deep Dives

Frontend Boundary Rule

When documenting or changing frontend behavior, keep the ownership model consistent:

• public acquisition and content storytelling live in apps/www,
• public documentation and architecture reference live in apps/docs,
• authenticated analyst workflows live in apps/dashboard,
• operator tooling and orchestration supervision live in apps/admin-desktop,
• cross-app URL, session, and payload contracts live outside this section in shared packages and backend docs.