- Shipped
- September 4, 2026 at 8:28 PM UTC
- Author
- Kamo
- Commit
- 021a5ff
The org chooses "Register Site Logo Overlay" in kamo-internal beside the home page and loading screen overlays. One setting for the whole site: every step of the registration flow, the organization and team screens, the completion screen and the closed-signup screen. So ThemeLogo takes no prop for it and reads the colour itself, the way it already reads the company-vs-software auth logo identity - config.json is this site's only source of org branding, and a prop would be one more thing every call site has to remember. The colour arrives already resolved: kamo-internal stores a TOKEN so an org that rebrands keeps a matching overlay, and securityservice resolves it against that org's palette when it writes config.json. Nothing here needs the thirteen-token vocabulary. A value CSS cannot parse is dropped rather than passed through - an invalid background-color paints the masked box transparent, which reads as a logo that vanished. A mask, not a filter: a filter can only push a logo's existing colours around and cannot reach an arbitrary target. The <img> stays mounted and merely invisible so it keeps holding its exact box for the mask to fill, leaving every caller's layout unchanged. Its own column and its own config.json key, separate from the sign-in site's: the two are branded independently, and an org that white-labels one need not white-label the other.