- Ya
- 15 Agosti 2026, 07:08 UTC
- Mwandishi
- Kamo
- Ahadi ya
- ac80907
KamoMeet is a Meet fork with no access to OrgContext, so it learns org branding from the theme config.json this service bakes. The org stores an overlay TOKEN; this resolves it against that org's own palette and writes the finished hex as kamomeetLogoOverlayColor. Resolving here rather than shipping the thirteen-token table into the fork is the point: that repo already carries the org background slideshow as one of nine independent copies, and a second such table would drift the same way. Baking a resolved colour is also not the "frozen hex" this feature avoids in the database — config.json is regenerated on every branding save, colour changes included. The prefix match is explicit rather than "not SECONDARY means PRIMARY". A test caught what the loose version did: "#FF0000" is exactly as long as "PRIMARY", so it left an empty step and resolved to the primary base — a colour nobody chose, arriving on a screen no one on the platform side ever looks at. Unknown tokens and unset shades are omitted from config.json entirely, which is how every client reads "no overlay". The token table must stay in step with kamo-internal's logoOverlay.ts; the tests are what make a divergence a build failure.