# Decision: the canonical React designbook (WHYNOT-WP-0002 · T04)

> **Status: RESOLVED.** The canonical React designbook **already exists** — it is
> the **"WhyNot Design System"** project in Claude Design
> (`fb2eef8c-c1fc-4c75-bff4-3782552e5511`, owner Bernd). The remaining concrete
> action is the first `/design-sync` pull into `designbook/`.

## Correction to the earlier premise

An earlier draft of this doc assumed the Claude Design project held only the
hand-authored **Lit** experiment, and therefore proposed *authoring* a new React
designbook. That premise was wrong. Inspecting the project
(`DesignSync.list_files` / `get_file`) shows it already contains a real React
source:

- `ui_kits/whynot-control/*.jsx` — **React function components**: `Atoms.jsx`
  (`Eyebrow`, `Tag`, `Button`, `StageDot`, `Stamp`, `Icon`), `Chrome.jsx`,
  `Screens.jsx`, `DocView.jsx`, `data.jsx`. Props are expressed as JSX function
  parameters with defaults (e.g. `Button({ variant = 'secondary', icon, … })`).
- `preview/comp-*.html` — per-component preview cards (the exemplar renders).
- `styles.css`, `colors_and_type.css`, `_ds_manifest.json`, `_ds_bundle.js` —
  token/style layers + the grouping manifest.
- `_whynot-design-seed/` — a full copy of this Lit repo that seeded the project.

So Claude Design is genuinely canonical today, and `/design-sync` provides the
React origin from which Lit (and any future stack) is generated. This is the
directionality the workplan already assumes: **React → IR → stacks.**

## Resolution

- **Canonical source:** the existing "WhyNot Design System" Claude Design project.
  No new designbook is authored; nothing is adopted from a foreign kit.
- **How it reaches `designbook/`:** run **`make designbook-pull`**
  (`scripts/designbook_pull.py`) — it drives the local `claude` binary headless
  (`claude --print --permission-mode acceptEdits`) so the `DesignSync` fetch+write
  happens in a subprocess, and stamps freshness on success. (The bundled
  `/design-sync` skill goes the other way — it *pushes* repo→cloud — so it does not
  populate `designbook/`.) **Done 2026-06-23:** 44 files pulled (the `.jsx` ui-kit,
  `_ds_manifest.json`, style layers, and `preview/*.html` exemplars);
  `_whynot-design-seed/**` excluded.

## Consequence for the extractor (T05)

The React source is a **bundled `.jsx` ui-kit** (several components per file),
**not** the per-component `.d.ts` + `.prompt.md` layout the T01 schema notes
assumed. The neutral IR **contract schema is unaffected** (it describes the
*output* shape), but `scripts/ir-extract.mjs` (T05) must:

- read component **props/defaults from the JSX function signatures** in
  `ui_kits/whynot-control/*.jsx` (not `.d.ts`),
- take **grouping** from `_ds_manifest.json`,
- take **exemplars** from `preview/comp-*.html`,
- take **tokens** from the project's `styles.css` / `colors_and_type.css` (and/or
  the seed `tokens/*.json`), normalising to W3C DTCG.

This is recorded so T05 is designed against the real source layout.

## What unblocks the rest of the pipeline

1. Run `/design-sync` → `designbook/` receives the React mirror (more than README).
2. Stamp + `make designbook-sync`.
3. `make ir` (T05) extracts the IR from the `.jsx` ui-kit + previews + manifest.
4. T06–T08 (Lit adapter + parity) then run against real data.