Capivara got a new skin — theme v2 with per-project design tokens
A capybara that changed its skin
The second brain lived for months with a hand-stitched theme: colors scattered across components, each screen with its own way of declaring background and text. It worked, but any identity change turned into a hunt through forgotten <style> blocks. Then came the theme v2 redesign.
The idea: a theme that is a contract
Instead of loose colors, v2 tied everything into a ThemeProvider with design tokens — the theme became a set of variables that components only reference. Changing the whole identity means changing the tokens, not chasing selectors.
Two details made the difference:
- CSP-compliant anti-flash — the theme applies without flashing the wrong background on first paint (the infamous FOUC), and without relying on inline styles that Capivara’s CSP would block.
- Per-project tokens — each project (Arachne, Dogwalk, Portfolio…) carries its own token palette, so the second brain’s UI reflects the identity of every system it manages.
The email that disappeared and came back
During the cycle, invitation emails stopped arriving. The cause wasn’t the code — it was the Resend domain: it pointed to the wrong place, and the sender rejected silently. A single-line fix aligned the domain to seu.pet and invites started sending again.
As a bonus, email_service gained real test coverage (Resend 200, HTTP error, fallback) and the httpx mock in the test was corrected.
Lesson
Refactoring visuals isn’t just CSS — it’s changing discipline. When the theme becomes a contract via tokens, the design becomes versioned and consistent instead of improvised. And the classic lesson repeated itself: the most invisible email bug is who is allowed to send from that domain, not the message body.