design guide: field notes from proof-of-work Case-B extract

Two process learnings: render hue/shade reconcile candidates as pixels
(Chrome headless screenshot of an in-context vignette) rather than relying
on hex/monospace previews; and how to absorb one owner-driven accent in a
document-as-is extract (single canonical hue, distinguish overlap by
treatment not a second color, surface the collision before picking).

guides/design.md

@@ -345,6 +345,23 @@ us things. Brand facts never go here; only generalizable process/distillation kn
   **proposed-not-canonical pending an explicit owner decision** rather than silently adopting it —
   and surface it as the reconcile call (an A/B "adopt vs. exploration-only" question). Small in-idiom
   refinements (a 13→15px type bump) just get absorbed.
+- *(Case-B doc-as-is extract, 2026-06-19, proof-of-work)* **For a hue/shade reconcile call, render the
+  candidates as pixels — hex values + monospace previews aren't enough.** When the owner says "I like
+  adding X, *depending on the shade*," author a small HTML vignette in the app's real fonts/treatments on
+  the real canvas color, screenshot it with **Chrome headless** (`--headless=new --screenshot
+  --force-device-scale-factor=2 --window-size=W,H` against a `file://` URL — present on macOS at
+  `/Applications/Google Chrome.app/Contents/MacOS/Google Chrome`), and show the candidates in-context with
+  the *unchanging* reference element beside each (here: the white primary button drawn in every row) so the
+  comparison isolates the one variable. Turned "which red" into a single-look decision; keep the rendered
+  comparison in `inspiration/` as decision provenance.
+- *(Case-B doc-as-is extract, 2026-06-19, proof-of-work)* **A document-as-is extract can still carry one
+  owner-driven accent — handle the semantic collision *before* picking the value.** Here red was promoted
+  from error-only to *the* brand accent. Reusable handling: keep the existing signature intact (white stayed
+  the primary button), make the new accent the **single canonical hue** (never a second red on screen), and
+  where it overlaps an existing semantic hue, **distinguish by treatment, not by a new color** (solid
+  edge/fill = brand accent; wash + tinted text = error; never a solid button in that hue) — then encode that
+  distinction in §Do's/Don'ts so `design-checker` can enforce it (it caught the lone solid-red button as the
+  one regression). Surface the collision as the framing the owner chooses *within*, not a discovery after.
 
 ## Final report