docs(adr): ADR-032 visual refresh — light(B)+dark(C) charm-reader themes + sketches (issue #17)

2026-06-12 11:54:54 +02:00
parent f98b640531
commit 8ca767c144
4 changed files with 237 additions and 0 deletions
@@ -1267,6 +1267,53 @@ map) → TDD → implement → SemVer + docs.

 ---

+## ADR-032 — Visual refresh: one charm-reader layout, light + dark themes
+
+**Status:** Proposed (2026-06-12). Issue #17. **Draft for review — no code yet.** Follows the
+sketch-first explore step (3 throwaway mockups in `docs/sketches/`, screenshotted for review).
+
+**Context / decision.** The UI is flat. From the mockups, directions **B (light reader + charm)**
+and **C (dark cozy terminal)** are the SAME layout — readable sans body, monospace meta, charm
+palette accents, lipgloss-style bordered cards — in two palettes. Direction A (full-monospace TUI)
+is dropped as too heavy to read long summaries. Decision: ship that one layout with **both a light
+theme (B) and a dark theme (C)**, user-toggleable, defaulting to the OS preference.
+
+**Requirements.**
+- R1: one set of markup/structure; the two themes are pure palette (CSS variables), no duplicate templates.
+- R2: a **theme toggle** persisted across visits; default to `prefers-color-scheme` when no choice stored.
+- R3: charm language in both — mint/purple/pink accents, mono meta + section labels, lipgloss
+  bordered/gradient cards, the (fixed) ASCII tapir; readable sans body.
+- R4: style the existing pieces — list, compact card, **expanded card incl. the already-present
+  video embed (ADR-031/summaryBody)**, detail page, chat dock, the queue note, the charm spinner.
+- R5: WCAG-AA contrast for body text in BOTH themes; keep `prefers-reduced-motion` (already honoured).
+- R6: stay HTMX+Templ; no CSS framework.
+
+**Architecture.**
+1. **Palette as CSS variables.** `:root` holds the light (B) tokens; `:root[data-theme="dark"]`
+   holds the dark (C) tokens; a `prefers-color-scheme: dark` media block sets the dark tokens when
+   no explicit `data-theme` is set. All component CSS references variables only (R1). The existing
+   `CharmMint/Purple/Pink/Cream/Dim` Go consts remain the source for the spinner's inline colours.
+2. **Theme toggle** = a small inline script (a dozen lines, no framework) in `Layout`: on load,
+   apply stored theme (localStorage) or fall through to the media query; a header toggle button
+   flips `data-theme` on `<html>` and stores it. This is the one new bit of JS; everything else
+   stays server-rendered + HTMX. (Considered: cookie + server-render — rejected, a full round-trip
+   per toggle is clunky for a pure presentation flip.)
+3. **Scope = the `styleTag` CSS in `view.go`** (the single style source) plus tiny class hooks in
+   the templ where needed; content/structure are unchanged, so existing view tests keep passing.
+
+**Verification.** The deployed UI is behind auth (web-shot can't log in), so visual review is via
+the mockups now + a styled full-set mockup screenshot before merge, then a live eyeball on device.
+Automated tests stay structural/behavioural (theme tokens present, toggle persists, expanded card
+embeds the video, no-JS still renders a readable default) — colours are not unit-tested.
+
+**Reversibility.** A CSS theme swap + one small script + a few class hooks; revert `styleTag` to
+roll back. No schema, no structural change.
+
+**Next steps (gated):** on approval → BDD (`docs/use-cases/visual_theme.feature` + coverage map)
+→ TDD → implement → SemVer + docs.
+
+---
+
 ## Rejected alternatives

 Approaches considered during the 2026-06-02 planning + grill session and **deliberately not