Modules
Theme tokens and brand imagery for the storefront and the admin. Core.
branding is how a tenant looks: its logos and its colour.
The tenant's colour is a selection, not a sheet: a named theme from a committed catalog plus per-token overrides for light and dark. The catalog is data, so fixing a theme once reaches every tenant on it, and adding a theme is an entry with no code and no rebuild. A raw pasted sheet is accepted too. The selection injects at runtime, so a change repaints the store on the next request.
Light or dark is the viewer's device choice and composes with it: the tenant's tokens define both palettes, and the device decides which applies.
An app with no tenant runtime bakes a catalog theme into its own stylesheet at build time instead.
The light and dark logos and the brand images live in the tenant's public bucket and are named in the application settings. An edit to one leaves the other alone. The public site falls back to the store's name as text when a tenant has none.
/branding: the logo form, a gallery of catalog themes each previewed in its own palette, and the custom-sheet paste form.
get_appearance, propose_theme, manage_theme. A proposal previews in the pane before it applies, and applying folds the stored overrides into the tokens it was given, so a token this call does not restate is kept.
Admin.
Never. Every project links it at provisioning.