grant/standards
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

design guide: distill a Claude Design .dc.html at its default props, not the screenshots

Browse Source 
The .dc.html prototypes are parameterized components whose data-props defaults encode
the decisions the user landed on; the bundled screenshots are option-history (rejected
options + stale iterations). Read the .dc.html at its defaults as the source of truth
and confirm with the user — don't anchor the contract on screenshots. (Learned on the
ten31 CRM: a screenshot-anchored read locked a plan onto a rejected card the .dc.html
defaults had already superseded.)
This commit is contained in:
Keysat
2026-06-19 19:35:04 -05:00
parent 04a190b8f2
commit 4533cc1d85
1 changed files with 19 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
guides/design.md
+19 -2
View File
@@ -145,8 +145,25 @@ If the user used Figma or just talked through the look, that's fine — the same
Turn the input — a cloud export, imported guidelines, or a reconciled inventory — into the Turn the input — a cloud export, imported guidelines, or a reconciled inventory — into the
vendor-neutral contract. When distilling a Claude Design export, note it is **agent-mediated, vendor-neutral contract. When distilling a Claude Design export, note it is **agent-mediated,
not a mechanical export**: Claude Design emits standalone HTML with *inline, hardcoded* CSS not a mechanical export**: Claude Design emits standalone HTML with *inline, hardcoded* CSS
(no CSS custom properties, no DTCG tokens), so you read values out of the export/screenshots (no CSS custom properties, no DTCG tokens), so you read values out of the export and author
and author the contract yourself. Worth a human glance the first few runs. the contract yourself. Worth a human glance the first few runs.
**Read the `.dc.html` at its *default props* as the source of truth — the screenshots are
option-history, not the final.** A Claude Design bundle ships renderable `*.dc.html` prototypes
(React + a `support.js` dc-runtime + a `store.js` mock store) next to a `screenshots/` folder.
Each `.dc.html` is a **parameterized component**: a top-of-file `data-props` blob declares every
option the session explored as an `editor:"enum"` with a `default` (e.g. `lpFlag:
star|earmark|banner` default `"earmark"`; `variant: compact|roomy` default `"compact"`; plus
`font`, `theme`, …). **Those defaults are the decisions the user actually landed on.** The PNG
screenshots, by contrast, are captures of *assorted* prop combinations from across the session —
they include rejected options and stale iterations, so they are **not** a reliable "final".
Read the `.dc.html` render markup at its default props (the `<sc-for>`/`<sc-if>` blocks + the
`data-props` defaults), or render the file at defaults (needs a local server — `support.js`
expects `window.React` and `fetch`es), and trust *that* over any screenshot — then confirm with
the user, who is the authority on which options won. *(Hard-won on the ten31 CRM: a
screenshot-anchored read locked a whole build plan onto a rejected card — disposition badges, a
6-stage funnel, a star flag — that the `.dc.html` defaults had already superseded with the final
earmark + 4-stage-pipeline card. The files didn't lie; we'd read the wrong one.)*
1. **Preserve provenance.** Confirm the raw input is committed under `design/_imports/<date>/`. 1. **Preserve provenance.** Confirm the raw input is committed under `design/_imports/<date>/`.
2. **Author `design/DESIGN.md`** in the nine-section format coding agents parse: **Visual 2. **Author `design/DESIGN.md`** in the nine-section format coding agents parse: **Visual