feat: add Geist Contrast skin

[intellectronica]

Thinking Path

This PR adds a narrowly scoped Geist Contrast skin to Hermes WebUI without changing the theme/mode model. It keeps the skin as a selectable visual style that works with both light and dark themes.

The skin key is geist-contrast; the user-facing label is Geist Contrast.

What Changed

• Adds the Geist Contrast skin tokens and scoped component overrides.
• Registers geist-contrast in the early boot allowlist, runtime skin picker, server settings validation, and /theme help text.
• Documents the new skin in the theme docs, UI/UX guide, README, and changelog.
• Adds focused regression coverage for skin registration, contrast-critical dark-mode affordances, neutral selected/sidebar states, and the command help skin list.

Verification

• python -m pytest tests/test_geist_contrast_skin.py tests/test_issue2462_theme_i18n.py tests/test_sprint26.py -q
  • 20 passed in 2.21s
• Browser-verified with an isolated WebUI server and extensions disabled:
  • dark mode using hermes-theme=dark, hermes-skin=geist-contrast
  • light mode using hermes-theme=light, hermes-skin=geist-contrast
  • Appearance picker shows Geist Contrast selected
• Verified the screenshot run loaded only the skin supplied by this PR.

Screenshots

Dark

Light

Appearance picker

Model Used

Implemented with Fnord via GPT-5.5.

[nesquena-hermes]

Summary

Skin registration looks clean. Reading static/boot.js:1204 (the _SKINS entry), static/index.html:20 (the early boot allowlist), api/config.py:4167 (server validation), and the CSS at static/style.css:296-464, the geist-contrast key is wired end-to-end and consistent. The value:'geist-contrast' field plus the (s.value||s.name).toLowerCase() change in _VALID_SKINS and _buildSkinPicker is the right move — it lets the user-facing label keep the space while the storage/data-attr key stays hyphenated.

One concrete bug I want to flag before merge, plus a couple of optional notes.

Bug: /theme geist-contrast slash command won't match this skin

cmdTheme in static/commands.js:665-707 still derives its skin allowlist from s.name.toLowerCase() only — it does not respect the new s.value field:

async function cmdTheme(args){
  const themes=['system','dark','light'];
  const skins=(_SKINS||[]).map(s=>s.name.toLowerCase());   // ← "geist contrast" (space)
  ...
  const val=(args||'').toLowerCase().trim();
  ...
  if(skins.includes(val)){ ... }                             // ← never true for "geist-contrast"

So when a user types /theme geist-contrast (the form the docs and i18n strings advertise — see static/i18n.js:191, cmd_theme: '... default/ares/.../catppuccin/nous/geist-contrast'), val is geist-contrast but skins contains geist contrast and the picker falls through to the usage toast. The only way /theme succeeds for this skin today is if the user types /theme geist contrast, which is not how the command tokenizes argument strings.

Same one-line fix you already applied in boot.js works here:

const skins=(_SKINS||[]).map(s=>(s.value||s.name).toLowerCase());

That is genuinely all this needs; the rest of cmdTheme already calls _normalizeAppearance(..., val) which routes through the shared _VALID_SKINS set and is correct.

While you're in cmdTheme, the usage-toast at line 707 (showToast(t('theme_usage')+...+skins.join('|')+...)) will also emit the wrong label for this skin until the same change is made — users see ... | geist contrast | ... which they can't type back.

Optional notes

1. THEMES.md got updated to "eleven named skins" which is right today, but consider switching to "the built-in skins ship as default, ares, ..." once the count starts changing more often. Tiny nit.

2. The dark-mode active-tab icon override at static/style.css:399-402 stomps [data-lucide] to var(--accent-text). That value is #f5e65f, a pale yellow on #000. Contrast on the active rail/nav glyphs is borderline — looks fine on the screenshots but might want a real-world check on the mobile rail at 14 px. Not a blocker, just a touch point if anyone reports the active icon being hard to see.

3. The five tests in tests/test_geist_contrast_skin.py are all string-match assertions over the source files — they exercise registration and rule presence but not the cmdTheme codepath. If you take the fix above, a quick assertion that 'geist-contrast' in (s.value||s.name for s in _SKINS) (or just a string match (s.value||s.name) in the commands.js source) would catch this regression next time someone touches the picker.

Test plan

After the one-line commands.js:667 change:

• /theme geist-contrast from the composer → skin switches, toast t('theme_set')+'geist-contrast'.
• /theme geist contrast → falls through to usage toast (expected; the space form is not a key).
• Existing tests/test_geist_contrast_skin.py still green.
• No other call sites of _SKINS.map(s=>s.name) need touching — grep confirms _buildSkinPicker and _VALID_SKINS are the only other consumers and both were already updated in this PR.

[intellectronica]

Thanks for the careful review — especially for catching the /theme geist-contrast mismatch.

I addressed the actionable bug by updating cmdTheme in static/commands.js to build the slash-command skin allowlist from (s.value || s.name).toLowerCase(), matching the boot-time and picker paths. That makes /theme geist-contrast resolve to the stored skin key and also keeps the usage toast from advertising the untypeable geist contrast label.

I also added a focused regression assertion in tests/test_geist_contrast_skin.py so this codepath stays pinned if _SKINS handling changes again.

Validation run:

• python -m pytest tests/test_geist_contrast_skin.py tests/test_issue2462_theme_i18n.py tests/test_sprint26.py -q
  • 21 passed in 2.17s

I left the optional documentation wording and active-icon contrast notes unchanged for this follow-up because they were non-blocking observations rather than requested fixes, and the main bug/test coverage are now handled in the PR branch.

[intellectronica]

Updated after Eleanor's clarification.

• Addressed the documentation request by changing THEMES.md away from the brittle hard-coded skin count wording. It now describes the built-in skin palette generically while still listing geist-contrast in the accepted /theme skin names and skin table.
• Also updated docs/CONTRACTS.md so the appearance contract index lists the new geist-contrast skin alongside the current static/boot.js / static/style.css skin axis.
• Kept the active-icon contrast unchanged: Eleanor revalidated the current contrast and wants it intentionally left as-is for this PR.
• Rebased the PR branch onto current master (v0.51.92 / 71c7035) and resolved the CHANGELOG.md conflict from the release history moving ahead.
• Validation run: uv run python -m pytest tests/test_geist_contrast_skin.py tests/test_issue2462_theme_i18n.py tests/test_sprint26.py -q → 21 passed in 1.87s.

[nesquena-hermes]

Sign-off

Re-read the four commits at 52cdeac1 HEAD and the verification looks solid.

static/commands.js:667:

const skins=(_SKINS||[]).map(s=>(s.value||s.name).toLowerCase());

That matches the boot-time + picker paths exactly, and the usage toast at commands.js:707 now emits geist-contrast (the typeable form) since it reads from the same skins array. tests/test_geist_contrast_skin.py::test_geist_contrast_slash_theme_uses_skin_value_key pins both the allowlist line and the success-toast wording, so a regression here would surface immediately.

Doc changes also look right:

• THEMES.md swap from "eleven named skins" → "built-in skins ship as named keys" is the right level of abstraction — it stops the doc from rotting on every new skin without losing the user-facing contract.
• docs/CONTRACTS.md:64-68 appearance index now includes geist-contrast next to nous, which keeps the contracts inventory honest.

The rebase onto 71c7035 resolved the CHANGELOG.md conflict cleanly (the new entry under v0.51.92 reads fine). And the explicit decision to leave the dark-mode active-icon contrast as-is is fine on my end — that was a "touch point" note, not a blocker.

No further asks from me. Verdict: ready to merge once any final maintainer checks pass.