A theme switch looks too small to be a framework test. It is one button, two colors and a preference that needs to survive a refresh. On a site with page transitions, though, the button asks a useful question: which part of the system is responsible for what you see first?
The browser can remember which theme you chose. The build cannot know that choice, but it can give the browser a complete page and a clear place to apply the preference. If the first paint uses the wrong colors, a perfectly smooth toggle still feels broken.
Give the build the information it can use
On this portfolio, routes and layouts are known at build time. An editor can change the caption on an image; that edit does not need to redefine how the image frame draws. The content arrives as structured data, Zenith produces a page, and the browser gets an address it can open directly.
That sounds like a quiet detail until something changes underneath. Moving the content to Payload involved changing how the build receives it. The theme switch still had the same job, and the existing case-study URLs still had to open.
Try the boring test
Switch the theme. Scroll. Open a project. Reload on that page. If the first paint, navigation and reload agree, the parts have a working contract. If one of them flashes the old theme, the sequence tells you where to look.
That is why I build a real site alongside the compiler. A language demo can show that a component compiles. A portfolio can ask whether the component still feels right after a person clicks three things in an order I did not think to try.