The generic frontend is a complete configurable implementation, not a component library. Each operational workflow has its own application identity. Spell and Allocation Risk have independent bespoke frontends that use the same public backend.
A skin is only bounded appearance data: one palette, spacing preset, layout preset and logo reference. Custom components, navigation callbacks, page replacements, arbitrary CSS and page schema trees are not skins. If an application needs those things, build a bespoke frontend.
Application identity and workflow filtering do not add or remove backend access. Existing permissions, ownership, sharing and activity checks remain authoritative. A hidden navigation link does not prohibit typing its URL, and a different hostname does not imply data isolation.
The existing root commands and NEXT_PUBLIC_FRONTEND_ID values remain available: default,
spell-request and allocation-risk. They now select whole independently owned frontends,
not a profile with custom component slots. Unknown values fail rather than silently choosing
another product. Static environment access keeps server/client identity consistent.
The default root remains the cross-workflow operator console. Generic workflow applications have their own mounted URLs and appear in the authenticated application catalog. Newly published repository templates receive generic applications without an additional approval step.
Either a generic or a bespoke application can use a default address or a custom domain. The frontend's implementation does not own DNS. An operator configures the trusted public mount, backend connection and OAuth callbacks. Browser sessions remain local to their origin; bearer tokens are not passed between applications in URLs.
See frontend ownership, add a skin and deployment. Web frontends do not start extra shared workers.