From 1a702387e787ee8d59a80610e311220ae7fd3f9b Mon Sep 17 00:00:00 2001 From: Keysat Date: Fri, 19 Jun 2026 12:15:11 -0500 Subject: [PATCH] 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 | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/guides/design.md b/guides/design.md index 3de4f24..5c0d99e 100644 --- a/guides/design.md +++ b/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