Catching the theme mismatch led straight to fixing it: the real light and dark tokens from theme.css, switched automatically via prefers-color-scheme. That alone wasn’t quite enough once it existed, though — a follow-up request asked for a way to override the system setting by hand, not just follow it. The fix was a CSS specificity trick (an attribute selector on :root always outranks a bare one, regardless of source order or media query), with the choice injected server-side into the first bytes of the page so there’s no flash of the wrong theme on load. Testing that selector surfaced an unrelated bug from the original build — the settings panel’s open/close toggle checked the wrong property and needed two clicks to open on a fresh page load — caught and fixed along the way.

The last step was getting the code somewhere other than one machine: a public GitHub repo under the same account the site itself lives under. That meant being honest about what actually runs where — this app is macOS-only, held together by AppleScript, launchd, and a native .app bundle, none of which travels — and making the repo prove that framing instead of just claiming it: the checked-in launchd plist got a placeholder path instead of a real username, and a README instruction that quietly claimed the installer handles the daily trigger got corrected once a grep showed it doesn’t.

Main takeaways

  • An explicit user choice needs a mechanism to beat an automatic one on command — CSS specificity did that job cleanly here, no JavaScript toggling classes required.
  • Publishing something as a “reference” means making the repo itself prove that framing — placeholder paths and accurate instructions, not just a README claim.
  • Bugs and inaccuracies surface fastest while testing something adjacent to them, not while looking for them directly.

What I got wrong

  • The settings panel had a stale toggle bug from the very first build that went unnoticed until a new, unrelated feature required actually clicking through it repeatedly.
  • Wrote setup instructions claiming the installer script handles the launchd job before checking — it doesn’t, and the README said otherwise until corrected.