@rfdtech/components 1.22.0 → 2.0.1

package/dist/mcp/paths.js

@@ -0,0 +1,63 @@
+import path from "node:path";
+import { existsSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+const thisFileUrl = import.meta.url;
+const __dirname = path.dirname(fileURLToPath(thisFileUrl));
+// Running via `tsx src/*.ts` keeps the .ts extension in the module URL; a
+// compiled build (dist/*.js, whether tested locally or installed from npm)
+// does not. This tells us which layer we're running from without relying on
+// directory naming.
+const isDevSource = thisFileUrl.endsWith(".ts");
+// mcp/src/paths.ts (dev) and mcp/dist/paths.js (build output, local or
+// published) both sit exactly one level inside the `mcp/` package dir, which
+// in a repo checkout sits at the repo root alongside `demo/` and `src/`. When
+// installed from npm, this resolves into node_modules and none of those
+// sibling dirs exist — that absence is how we detect "published" mode.
+const REPO_ROOT = path.resolve(__dirname, "..", "..");
+export const SOURCE = {
+    pages: path.join(REPO_ROOT, "demo/docs/pages"),
+    examples: path.join(REPO_ROOT, "demo/docs/previews/examples"),
+    types: path.join(REPO_ROOT, "src/types"),
+    rules: path.join(REPO_ROOT, "demo/docs/rules"),
+    themeDir: path.join(REPO_ROOT, "src/styles/theme"),
+    componentsDir: path.join(REPO_ROOT, "src/components"),
+    // The generated, authoritative registry of every --clet-* token cletTheme()
+    // actually accepts (global + per-component) — see
+    // scripts/generate-theme-tokens.mjs. Parsed for token IDENTITY/grouping;
+    // actual values still come from the theme CSS files (global) and each
+    // component's own styles/*.css (component-scoped).
+    generatedTheme: path.join(REPO_ROOT, "src/generated/components.theme.ts"),
+};
+/**
+ * True only when this package is running from inside the gsl-components repo
+ * checkout (dev, or a local `npm run build` test) — i.e. there is live source
+ * to index. False when installed as a dependency (published, no sibling
+ * demo/src dirs), in which case we must never attempt to rebuild and only
+ * ever read the generated snapshot bundled at publish time.
+ */
+export const hasRepoSource = existsSync(SOURCE.pages) && existsSync(SOURCE.types);
+/**
+ * Where the generated JSON knowledge base lives.
+ * - Dev (tsx from src): mcp/generated — gitignored, rebuilt from live source.
+ * - Local dist / published dist: <dist>/generated — bundled at publish time
+ *   via `files: ["dist"]`, since the source it was built from won't travel.
+ */
+export const GENERATED_DIR = isDevSource
+    ? path.join(__dirname, "..", "generated")
+    : path.join(__dirname, "generated");
+/**
+ * The hand-authored skill doc. Same dev/dist split as GENERATED_DIR: in dev
+ * it's read straight from mcp/skill/ (committed source); in a build/publish
+ * it's read from the copy bundled next to the compiled JS.
+ */
+export const SKILL_SOURCE_PATH = isDevSource
+    ? path.join(__dirname, "..", "skill", "SKILL.md")
+    : path.join(__dirname, "skill", "SKILL.md");
+/**
+ * The hand-authored image/text-to-components skill doc. Same dev/dist split
+ * as SKILL_SOURCE_PATH; `prepare-dist.mjs` copies the whole `skill/` dir so
+ * this travels to the published tarball automatically.
+ */
+export const SKILL_IMAGE_SOURCE_PATH = isDevSource
+    ? path.join(__dirname, "..", "skill", "image-to-components.md")
+    : path.join(__dirname, "skill", "image-to-components.md");

package/dist/mcp/skill/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: rfdtech-ui
+description: Use before building or modifying UI with @rfdtech/components — search the component index, pull authoritative types and examples, and follow design rules instead of inventing APIs or styles.
+---
+
+Before generating or editing UI code that uses `@rfdtech/components`:
+
+1. **Search first.** Call `search_components` (or `search_docs`) with the feature you're building
+   ("date range filter", "confirmation dialog", "wizard") before writing any markup — a component
+   for it may already exist.
+2. **Never invent props or types.** Call `get_component_types` (or `get_component`) and use the
+   real prop names, variants, and types straight from `src/types/<slug>.ts` — do not guess from
+   memory or from a component's visual appearance. MDX prop tables are prose and can go stale;
+   the type source is authoritative.
+3. **Read real examples.** Call `get_component_examples` before composing a non-trivial usage
+   (tables, forms in modals, async flows) — every known example is included, not just the ones
+   the doc page happens to show inline.
+4. **Follow the rules.** Call `get_rules` (whole corpus, a category like `forms`/`theming`, or a
+   component slug) and follow its do/don't guidance — these are real conventions pulled from a
+   production consumer of this library, not generic advice.
+5. **Prefer composition over new components.** If an existing component covers most of the need,
+   compose or extend it (`classNames`, slots, wrapping) rather than hand-rolling a replacement.
+6. **Building a new page, screen, dashboard, or layout shell?** Call `get_rules("page-composition")`
+   first — it's a required, non-negotiable pattern set (not a style suggestion): the
+   `AppLayout`/`AppHeader`/`Sidebar` variant trio, required `SidebarFooter` + `ProfilePopover`,
+   `RoleSelect` wired into all three locations when the system has multiple roles, `Launchpad` over
+   the deprecated `AppSwitcher`, the `Table`/`MetricCard`/`Tabs` variant set, and more. Also see
+   `get_component("migration-v2")` for the full migration/adoption checklist.
+7. **Migrating a project that already overrides tokens?** Never decide silently. Find every
+   existing override of a *known* token — `gslTheme()` calls, or CSS setting a real `--clet-*` or
+   legacy `--gsl-*` color token (not custom/arbitrary variables) — list them, and ask the user
+   about each one individually: keep it, or drop it for the new approved default. Every color
+   token has both a `--clet-*` name (preferred — use this for any *new* override you write) and a
+   `--gsl-*` alias (legacy, still functional — only relevant when reading/preserving existing
+   consumer code, never write new overrides with it). Non-color tokens (radius/shadow/font/
+   spacing/z-index) only have a `--gsl-*` name. See `get_rules("theming")`.

package/dist/mcp/skill/image-to-components.md

@@ -0,0 +1,49 @@
+---
+name: image-to-components
+description: Use when the user hands over a screenshot, image, mockup, or textual description of a screen/interface to build — decompose it into existing `@rfdtech/components` components and variants via the MCP before writing any markup, instead of hand-rolling custom UI.
+---
+
+Whenever the user gives you a screenshot, image, mockup, or a written description of a
+screen, page, or dashboard they want built, treat it as a **translation** job: turn the
+image/text into a page composed of `@rfdtech/components` that already exist — not a spec
+for custom-built UI.
+
+1. **Decompose the design first.** Before writing any code, break the screen into its
+   regions and elements: layout shell, header/nav, sidebar, tables, forms and their fields,
+   cards/metrics, tabs, modals, buttons, badges, empty/loading states, etc. Do this for
+   every distinct element visible in the image or described in the text — don't skip
+   anything because it looks "simple enough to just write."
+
+2. **Map every element to an existing component via the MCP.** For each element:
+   - Call `search_components` (or `search_docs`) with what the element does or looks like
+     to find candidate matches.
+   - Call `get_component_types` / `get_component` to confirm the real prop names and
+     variants — never guess an API from how something looks in the image.
+   - Call `get_component_examples` for non-trivial compositions (a table inside a modal, a
+     multi-step form, etc.).
+   - Call `get_rules` for the component (and its category) to follow real do/don't
+     conventions.
+   - **Building a layout shell, full page, or dashboard?** Call
+     `get_rules("page-composition")` first — it's a required pattern set (the
+     `AppLayout`/`AppHeader`/`Sidebar` trio, `SidebarFooter` + `ProfilePopover`, `RoleSelect`
+     wiring, `Launchpad` over `AppSwitcher`, the `Table`/`MetricCard`/`Tabs` variant set),
+     not a style suggestion.
+   - Pick the variant that best aligns with what's in the image, not just the first result.
+
+3. **Compose only from matched rfd components.** Build the page exclusively out of
+   `@rfdtech/components` you've confirmed via step 2. Prefer image → page and text → page
+   translation grounded in the component set that already exists — do not introduce new
+   one-off components or raw markup/CSS to reproduce something a real component already
+   covers.
+
+4. **No match found? Stop and ask — never build custom silently.** If an element in the
+   image/description has no reasonable match in the component library, do not hand-roll
+   custom UI for it. Stop and ask the user exactly what they want for that specific
+   element. Only build custom UI when the user has explicitly said to build custom; if they
+   say "build custom" without specifics, ask exactly what they want (markup, behavior,
+   styling) before writing it. Never default to custom UI just because a match wasn't
+   obvious on the first search — exhaust `search_components`/`search_docs` first.
+
+5. **Everything else about writing the code follows `rfdtech-ui`** — authoritative types
+   over guessed props, real examples over invented ones, and the do/don't rules — see that
+   skill for the full discipline once components are identified.

package/dist/next-index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"next-index.d.ts","sourceRoot":"","sources":["../src/next-index.ts"],"names":[],"mappings":"AAAA,OAAO,oBAAoB,CAAC;AAU5B,cAAc,oBAAoB,CAAC;AACnC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,yBAAyB,CAAC;AACxC,cAAc,yBAAyB,CAAC;AACxC,cAAc,qBAAqB,CAAC;AACpC,cAAc,oBAAoB,CAAC;AACnC,cAAc,yBAAyB,CAAC;AACxC,cAAc,gCAAgC,CAAC;AAC/C,cAAc,qBAAqB,CAAC;AACpC,cAAc,mBAAmB,CAAC;AAClC,cAAc,uBAAuB,CAAC;AACtC,cAAc,sBAAsB,CAAC;AACrC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,4BAA4B,CAAC;AAC3C,cAAc,oBAAoB,CAAC;AACnC,cAAc,oBAAoB,CAAC;AACnC,cAAc,mBAAmB,CAAC;AAClC,cAAc,oBAAoB,CAAC;AACnC,cAAc,wBAAwB,CAAC;AACvC,cAAc,iCAAiC,CAAC;AAChD,cAAc,kCAAkC,CAAC;AACjD,cAAc,qBAAqB,CAAC;AACpC,cAAc,wBAAwB,CAAC;AACvC,cAAc,uBAAuB,CAAC;AACtC,cAAc,0BAA0B,CAAC;AACzC,cAAc,oBAAoB,CAAC;AACnC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,sBAAsB,CAAC;AACrC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,0BAA0B,CAAC;AACzC,cAAc,oBAAoB,CAAC;AACnC,cAAc,sBAAsB,CAAC;AACrC,cAAc,uBAAuB,CAAC;AACtC,cAAc,mBAAmB,CAAC;AAClC,cAAc,uBAAuB,CAAC;AACtC,cAAc,oBAAoB,CAAC;AACnC,cAAc,sBAAsB,CAAC;AACrC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,SAAS,CAAC;AACxB,OAAO,EAAE,WAAW,EAAE,kBAAkB,EAAE,MAAM,uBAAuB,CAAC;AAGxE,OAAO,EAAE,qBAAqB,EAAE,MAAM,mCAAmC,CAAC;AAG1E,OAAO,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC"}
+{"version":3,"file":"next-index.d.ts","sourceRoot":"","sources":["../src/next-index.ts"],"names":[],"mappings":"AAAA,OAAO,oBAAoB,CAAC;AAQ5B,cAAc,oBAAoB,CAAC;AACnC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,yBAAyB,CAAC;AACxC,cAAc,yBAAyB,CAAC;AACxC,cAAc,qBAAqB,CAAC;AACpC,cAAc,oBAAoB,CAAC;AACnC,cAAc,yBAAyB,CAAC;AACxC,cAAc,gCAAgC,CAAC;AAC/C,cAAc,qBAAqB,CAAC;AACpC,cAAc,mBAAmB,CAAC;AAClC,cAAc,uBAAuB,CAAC;AACtC,cAAc,sBAAsB,CAAC;AACrC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,4BAA4B,CAAC;AAC3C,cAAc,oBAAoB,CAAC;AACnC,cAAc,oBAAoB,CAAC;AACnC,cAAc,mBAAmB,CAAC;AAClC,cAAc,oBAAoB,CAAC;AACnC,cAAc,wBAAwB,CAAC;AACvC,cAAc,iCAAiC,CAAC;AAChD,cAAc,kCAAkC,CAAC;AACjD,cAAc,qBAAqB,CAAC;AACpC,cAAc,wBAAwB,CAAC;AACvC,cAAc,uBAAuB,CAAC;AACtC,cAAc,0BAA0B,CAAC;AACzC,cAAc,oBAAoB,CAAC;AACnC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,sBAAsB,CAAC;AACrC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,0BAA0B,CAAC;AACzC,cAAc,oBAAoB,CAAC;AACnC,cAAc,sBAAsB,CAAC;AACrC,cAAc,uBAAuB,CAAC;AACtC,cAAc,mBAAmB,CAAC;AAClC,cAAc,uBAAuB,CAAC;AACtC,cAAc,oBAAoB,CAAC;AACnC,cAAc,sBAAsB,CAAC;AACrC,cAAc,2BAA2B,CAAC;AAC1C,cAAc,SAAS,CAAC;AACxB,OAAO,EAAE,WAAW,EAAE,kBAAkB,EAAE,MAAM,uBAAuB,CAAC;AAGxE,OAAO,EAAE,qBAAqB,EAAE,MAAM,mCAAmC,CAAC;AAG1E,OAAO,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC"}