Brooklyn Nicholson
bd853747bb
Two things a genuinely fresh instance surfaced that no existing profile could. The renderer's mode fell back to `light` when nothing was stored, so a dark-mode desktop opened a white window on first launch. Main already defaulted its own themeSource to `system`, so the two disagreed at boot — and once translucency became per-appearance it also handed those users light's much heavier tint, tuned for a bright desktop they don't have. Both the normalizer and the SSR fallback now say `system`; an explicit choice still wins. The accent plugin reached straight into `@/components` and `@/themes`, which the plugin lint rule exists to prevent: plugins import `@hermes/plugin-sdk` and nothing else, so the app can move its internals without breaking them. The fix is to widen the SDK rather than exempt the plugin — it now exports the OKLCH colour maths, `useTheme`, `retintTheme`, and the accent override, so any plugin can derive a palette instead of hardcoding one.
Bundled plugins
Drop a <name>/plugin.{ts,tsx} here that default-exports a HermesPlugin and
it registers automatically at boot (vite glob in ../contrib/plugins.ts), with
the same inventory + live enable/disable contract as runtime plugins.
Keep this tree for real shipped plugins (and the small authoring fixtures that
dogfood the SDK). One-off demos that rebuild a core chrome piece 1:1 do not
belong here — they double the UI and confuse Settings ▸ Plugins. Publish those
in the companion
hermes-example-plugins
repo instead.
User- and agent-authored plugins load at runtime from
$HERMES_HOME/desktop-plugins/<name>/plugin.js (the disk door) — see the
hermes-desktop-plugins skill.