@cruglobal/cornerstone-components 0.1.0

package/dist/bundled/skills/cornerstone/references/frameworks/react.md

@@ -0,0 +1,252 @@
+# React
+
+**Full documentation:** https://cruglobal.github.io/cornerstone-design-system/frameworks/react
+
+<div class="cs-cluster cs-gap-2xs cs-not-prose">
+  <cs-badge variant="success" appearance="filled" pill>
+    <cs-icon name="check_circle" slot="start"></cs-icon>Shipped support
+  </cs-badge>
+  <cs-badge variant="neutral" appearance="filled" pill>70 wrappers</cs-badge>
+</div>
+
+React is the only stack with integration code in the package itself: the build generates a wrapper for every
+component, so `@cruglobal/cornerstone-components/react/*` is a first-class entry point rather than advice.
+React 19 needs none of it — it speaks custom elements natively — but the wrappers exist for 18 and below.
+
+## Installation
+
+To add Cornerstone to your React app, install the package from npm.
+
+```bash
+npm install @cruglobal/cornerstone-components
+```
+
+Next, include the Cornerstone theme in your app, import the components you need, and start using them!
+
+```jsx
+import '@cruglobal/cornerstone-components/styles/cornerstone.css';
+import '@cruglobal/cornerstone-components/components/button/button.js';
+
+export default function App() {
+  return <cs-button variant="brand">Button</cs-button>;
+}
+```
+
+React 19+ [supports custom elements](https://react.dev/blog/2024/04/25/react-19#support-for-custom-elements) natively, so you can use Cornerstone components just like any other HTML element. No wrappers needed!
+
+If you're using React 18 or below, skip to the [legacy React wrappers](#legacy-react-wrappers-react-18-and-below) section.
+
+## TypeScript
+
+If you're using TypeScript, you can add type safety using the types file included with Cornerstone.
+
+```
+node_modules/@cruglobal/cornerstone-components/dist/unbundled/custom-elements-jsx.d.ts
+```
+
+This gives you inline documentation, autocomplete, and type-safe validation for every component. Add the types to whichever tsconfig holds your app's `compilerOptions`. In a Vite project that is `tsconfig.app.json` — the root `tsconfig.json` is a solution file carrying only `files: []` and `references`, so options placed there have no effect.
+
+The leading `./` is required. TypeScript reads a bare entry as a package name rather than a path, and fails with `TS2688: Cannot find type definition file`.
+
+```json
+{
+  "compilerOptions": {
+    "types": ["./node_modules/@cruglobal/cornerstone-components/dist/unbundled/custom-elements-jsx.d.ts"]
+  }
+}
+```
+
+Alternatively, you can create a declaration file and extend JSX's `IntrinsicElements`:
+
+```ts
+import type { CustomElements, CustomCssProperties } from '@cruglobal/cornerstone-components/custom-elements-jsx.d.ts';
+
+declare module 'react' {
+  namespace JSX {
+    interface IntrinsicElements extends CustomElements {}
+  }
+  interface CSSProperties extends CustomCssProperties {}
+}
+```
+
+## Event Handling
+
+Many Cornerstone components emit [native events](https://developer.mozilla.org/en-US/docs/Web/API/Event). For example, the [input component](https://cruglobal.github.io/cornerstone-design-system/components/input) emits the `input` event when it receives input. In React, you can listen for the event using `onInput`.
+
+Here's how you can bind the input's value to a state variable.
+
+```jsx
+import { useState } from 'react';
+import '@cruglobal/cornerstone-components/components/input/input.js';
+
+function MyComponent() {
+  const [value, setValue] = useState('');
+
+  return <cs-input value={value} onInput={event => setValue(event.target.value)} />;
+}
+
+export default MyComponent;
+```
+
+If you're using TypeScript, it's important to note that `event.target` will be a reference to the underlying custom element. You can use `(event.target as any).value` as a quick fix, or you can strongly type the event target as shown below.
+
+```tsx
+import { useState } from 'react';
+import '@cruglobal/cornerstone-components/components/input/input.js';
+import type CsInputElement from '@cruglobal/cornerstone-components/components/input/input.js';
+
+function MyComponent() {
+  const [value, setValue] = useState('');
+
+  return <cs-input value={value} onInput={event => setValue((event.target as CsInputElement).value)} />;
+}
+
+export default MyComponent;
+```
+
+### Preact
+
+Preact users facing type errors using components may benefit from setting "paths" in their `tsconfig.json` so that react types will instead resolve to preact/compat as described in [Preact's typescript documentation](https://preactjs.com/guide/v10/typescript/#typescript-preactcompat-configuration).
+
+## Testing with Jest
+
+Testing with web components can be challenging if your test environment runs in a Node environment (i.e. it doesn't run in a real browser). Fortunately, [Jest](https://jestjs.io/) has made a number of strides to support web components and provide additional browser APIs. However, it's still not a complete replication of a browser environment.
+
+Here are some tips that will help smooth things over if you're having trouble with Jest + Cornerstone.
+
+> **Info**
+>
+> If you're looking for a fast, modern testing alternative, consider [Web Test Runner](https://modern-web.dev/docs/test-runner/overview/).
+
+### Upgrade Jest
+
+Jest underwent a major revamp and received support for web components in [version 26.5.0](https://github.com/facebook/jest/blob/main/CHANGELOG.md#2650) when it introduced [JSDOM 16.2.0](https://github.com/jsdom/jsdom/blob/master/Changelog.md#1620). This release also included a number of mocks for built-in browser functions such as `MutationObserver`, `document.createRange`, and others.
+
+If you're using [Create React App](https://reactjs.org/docs/create-a-new-react-app.html#create-react-app), you can update `react-scripts` which will also update Jest.
+
+```
+npm install react-scripts@latest
+```
+
+### Mock Missing APIs
+
+Some components use `window.matchMedia`, but this function isn't supported by JSDOM so you'll need to mock it yourself.
+
+In `src/setupTests.js`, add the following.
+
+```js
+Object.defineProperty(window, 'matchMedia', {
+  writable: true,
+  value: jest.fn().mockImplementation(query => ({
+    matches: false,
+    media: query,
+    onchange: null,
+    addListener: jest.fn(), // deprecated
+    removeListener: jest.fn(), // deprecated
+    addEventListener: jest.fn(),
+    removeEventListener: jest.fn(),
+    dispatchEvent: jest.fn(),
+  })),
+});
+```
+
+For more details, refer to Jest's [manual mocking](https://jestjs.io/docs/manual-mocks#mocking-methods-which-are-not-implemented-in-jsdom) documentation.
+
+### Transform ES Modules
+
+ES Modules are a [well-supported browser standard](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/). This is how Cornerstone is distributed, but most React apps expect CommonJS. As a result, you'll probably run into the following error.
+
+```
+Error: Unable to import outside of a module
+```
+
+To fix this, add the following to your `package.json` which tells the transpiler to process Cornerstone modules.
+
+```js
+{
+  "jest": {
+    "transformIgnorePatterns": ["node_modules/(?!(@cruglobal|lit|@lit-labs))"]
+  }
+}
+```
+
+These instructions are for apps created via Create React App. If you're using Jest directly, you can add `transformIgnorePatterns` directly into `jest.config.js`.
+
+For more details, refer to Jest's [`transformIgnorePatterns` customization](https://jestjs.io/docs/tutorial-react-native#transformignorepatterns-customization) documentation.
+
+## Legacy React Wrappers (React 18 & Below)
+
+React 18 and below have [poor support](https://custom-elements-everywhere.com/#react) for custom elements. For these versions, Cornerstone provides React wrappers for every component.
+
+### Importing React Wrappers
+
+Every Cornerstone component is available to import as a React component. Note that you import the `<CsButton>` _React component_ instead of the `<cs-button>` _custom element_ in the example below.
+
+```jsx
+import CsButton from '@cruglobal/cornerstone-components/react/button/index.js';
+
+const MyComponent = () => <CsButton variant="brand">Click me</CsButton>;
+
+export default MyComponent;
+```
+
+You can find a copy + paste import for each component by selecting the _React_ tab in the _Importing_ section of each component's documentation.
+
+#### Notes About Tree Shaking
+
+Previously, it was recommended to import from a single entrypoint like so:
+
+```jsx
+import { CsButton } from '@cruglobal/cornerstone-components/react';
+```
+
+However, tree-shaking extra Cornerstone components proved to be a challenge. As a result, we now recommend cherry-picking components you want to use, rather than importing from a single entrypoint.
+
+```diff
+- import { CsButton } from '@cruglobal/cornerstone-components/react';
++ import CsButton from '@cruglobal/cornerstone-components/react/button/index.js';
+```
+
+### Event Handling with React Wrappers
+
+Event handling works the same as with [native custom elements](#event-handling) — bind to `onInput` and type `event.target` identically, just importing the `CsInput` wrapper instead of the custom element.
+
+Wrappers add two conveniences. Pass `defaultValue` for an uncontrolled input:
+
+```jsx
+import CsInput from '@cruglobal/cornerstone-components/react/input/index.js';
+
+<CsInput defaultValue="Foo" />;
+```
+
+Each wrapper re-exports a type for every `cs-`prefixed event it emits, so callbacks for those can be typed directly. `<CsInput>` exports `CsClearEvent` and `CsInvalidEvent`; check the component's own page for the full list, since the set differs per component.
+
+Native events — `input`, `change`, `focus`, `blur` — keep their ordinary DOM types. Read the value from `currentTarget`, remembering that `value` is `string | null`:
+
+```tsx
+import { useCallback, useState } from 'react';
+import type { FormEvent } from 'react';
+import CsInput, { type CsClearEvent } from '@cruglobal/cornerstone-components/react/input/index.js';
+import type CsInputElement from '@cruglobal/cornerstone-components/components/input/input.js';
+
+function MyComponent() {
+  const [value, setValue] = useState('');
+
+  const onInput = useCallback(
+    (event: FormEvent<CsInputElement>) => setValue(event.currentTarget.value ?? ''),
+    [],
+  );
+  const onCsClear = useCallback((_event: CsClearEvent) => setValue(''), []);
+
+  return <CsInput value={value} onInput={onInput} onCsClear={onCsClear} />;
+}
+
+export default MyComponent;
+```
+
+Cornerstone's event classes extend `Event` rather than `CustomEvent`, so they carry no `detail`. Read what you need from the element.
+
+<cs-callout variant="success">
+  <strong>Cornerstone is ready to use.</strong><br />
+  Explore components, utilities, and theming to start building.
+</cs-callout>

package/dist/bundled/skills/cornerstone/references/frameworks/wordpress.md

@@ -0,0 +1,186 @@
+# WordPress
+
+**Full documentation:** https://cruglobal.github.io/cornerstone-design-system/frameworks/wordpress
+
+<div class="cs-cluster cs-gap-2xs cs-not-prose">
+  <cs-badge variant="success" appearance="filled" pill>
+    <cs-icon name="check_circle" slot="start"></cs-icon>Verified on WordPress 7.1
+  </cs-badge>
+  <cs-badge variant="neutral" appearance="filled" pill>PHP 8.5</cs-badge>
+  <cs-badge variant="neutral" appearance="filled" pill>Script Modules</cs-badge>
+</div>
+
+Every snippet below has run on a real WordPress install — 7.1 on PHP 8.5.1, plugin activated, front end and
+block editor both checked. See [what has been verified](#what-has-been-verified) at the end for what that
+covered and the two things it did not.
+
+WordPress renders HTML on the server, so `cs-*` tags work in a template, a shortcode or a block's `render_callback`
+with no integration code. What takes the work is WordPress's asset API, which was built for classic scripts and
+needs telling that Cornerstone's loader is an ES module.
+
+Nothing here requires a Node build step. The library ships a **bundled** build with its dependencies inlined,
+so a plugin or theme can vendor those files and enqueue them as they are.
+
+## Vendoring the files
+
+Install once, wherever you keep build tooling, and copy the bundled build into the plugin or theme:
+
+```bash
+npm init -y   # if the plugin has no package.json yet
+npm install @cruglobal/cornerstone-components
+mkdir -p assets
+cp -R node_modules/@cruglobal/cornerstone-components/dist/bundled assets/cornerstone
+```
+
+Both extra lines matter in a fresh plugin. Without `mkdir -p assets` the copy fails outright
+(`cp: assets/cornerstone: No such file or directory`), and `npm install` in a directory with no
+`package.json` walks up and installs into whichever ancestor has one, editing that manifest instead.
+
+Copy the whole directory. The loader imports its chunks by relative path and fetches each component file at
+runtime, so a lone `cornerstone.loader.js` will not work on its own.
+
+## Enqueuing
+
+`cornerstone.loader.js` is an ES module, and `wp_enqueue_script()` emits a classic `<script>`. On WordPress
+6.5 and later, use the Script Modules API, which emits `type="module"` for you:
+
+```php
+add_action( 'wp_enqueue_scripts', function () {
+    $base = plugin_dir_url( __FILE__ ) . 'assets/cornerstone';
+
+    wp_enqueue_style( 'cornerstone', "$base/styles/cornerstone.css", array(), null );
+    wp_enqueue_script_module( 'cornerstone', "$base/cornerstone.loader.js", array(), null );
+} );
+```
+
+On older versions, enqueue it normally and promote it to a module with `script_loader_tag`:
+
+```php
+add_filter( 'script_loader_tag', function ( $tag, $handle ) {
+    if ( 'cornerstone' !== $handle ) {
+        return $tag;
+    }
+
+    return str_replace( '<script ', '<script type="module" ', $tag );
+}, 10, 2 );
+```
+
+## Pass `null` as the version, or set the base path
+
+This one fails silently, so it is worth understanding rather than copying.
+
+The autoloader finds components by URL, not through the module graph: it watches the DOM, and when it sees an
+unregistered `cs-*` tag it imports `{basePath}/components/{tag}/{tag}.js`. It works the base path out from its
+own module URL, which means WordPress's cache-busting query string is harmless — `?ver=6.9` on the script tag
+changes nothing about where the module itself lives.
+
+You therefore do not need to pass `null` as `$ver`, and you do not need a `data-cornerstone` attribute.
+Verified against a server that appends `?ver=6.9` to the loader: every component upgrades, no failed
+requests, clean console.
+
+Earlier versions of this library matched the script's `src` against the literal filename
+`cornerstone.loader.js`, which `?ver=` defeated — so if you are following an older snippet that passes `null`
+or sets `data-cornerstone`, neither does any harm, but neither is doing anything either.
+
+`data-cornerstone` is still the way to point at a different directory, and it may sit on **any** element on
+the page:
+
+```php
+add_action( 'wp_head', function () {
+    $base = plugin_dir_url( __FILE__ ) . 'assets/cornerstone';
+
+    printf( '<meta name="cornerstone-base" data-cornerstone="%s">', esc_url( $base ) );
+} );
+```
+
+It now keeps the origin, so an absolute URL to a CDN works as the doc comment always claimed. It previously
+kept only the path, which silently turned a cross-origin base into a same-origin one.
+
+## The block editor
+
+Editor canvases are iframed in current WordPress, and assets enqueued for the front end do not reach them.
+If your blocks render `cs-*` tags in the editor, enqueue on `enqueue_block_assets` — it runs for the front end
+*and* inside the canvas, so it replaces the `wp_enqueue_scripts` hook above rather than joining it. But
+**enqueue classically here, not as a script module**:
+
+```php
+add_action( 'enqueue_block_assets', function () {
+    $base = plugin_dir_url( __FILE__ ) . 'assets/cornerstone';
+
+    wp_enqueue_style( 'cornerstone', "$base/styles/cornerstone.css", array(), null );
+    wp_enqueue_script( 'cornerstone', "$base/cornerstone.loader.js", array(), null );
+} );
+
+add_filter( 'script_loader_tag', function ( $tag, $handle ) {
+    return 'cornerstone' === $handle ? str_replace( '<script ', '<script type="module" ', $tag ) : $tag;
+}, 10, 2 );
+```
+
+> **Warning**
+>
+> **`wp_enqueue_script_module` does not reach the editor canvas.** Measured on WordPress 7.1: with the module
+> enqueue the loader lands only in the parent admin document, the canvas iframe receives no loader, and a
+> `cs-*` element inside it never upgrades. Enqueued classically, WordPress injects the tag into the canvas, the
+> filter's `type="module"` survives the injection, and components upgrade normally.
+>
+> The *stylesheet* crosses into the iframe either way, so the canvas looks styled even when nothing has
+> upgraded — which is the easy way to be fooled here.
+
+A block registered with a `viewScriptModule` is the other route into the canvas, and may well be the better
+one; it has not been tested.
+
+Prefer `enqueue_block_assets` over `enqueue_block_editor_assets`, which targets the editor chrome around the
+canvas rather than the canvas itself — where the components actually render.
+
+## Icons
+
+`<cs-icon>` fetches its SVGs at runtime from a CDN by default. For a site that should not depend on a
+third-party host, serve them yourself — the bundled build's base path already points at your own domain, and
+`setIconPath` sets where icons resolve from. See [`<cs-icon>`](https://cruglobal.github.io/cornerstone-design-system/components/icon) for the directory layout.
+
+## Theme styles will fight you
+
+WordPress themes commonly reset margins on everything, and a component's slotted content is styled by the
+**page**, not the shadow root — an outer declaration wins regardless of specificity. If slotted text looks
+wrong inside a component, that is usually the theme reaching in. Cornerstone defends against the common cases,
+but a theme with an aggressive universal selector can still get through; scope the reset away from `cs-*` tags
+rather than fighting it inside the component.
+
+## What has been verified
+
+> **Info**
+>
+> The base-path behaviour was reproduced directly, serving the bundled build from one path and the document
+> from another:
+>
+> Re-verified on a real install — **WordPress 7.1, PHP 8.5.1**, SQLite drop-in, Twenty Twenty-Five, plugin
+> activated — rather than in a harness. No PHP notices or deprecations from the plugin.
+>
+> - **The Script Modules enqueue works as printed**, with `null` as `$ver`: the loader renders as
+>   `<script type="module">` and `cs-button`, `cs-badge` and `cs-icon` all upgrade with shadow roots and no
+>   console output. Icons come from jsdelivr, as stated above.
+> - **`?ver=` used to break autoloading**, when the base path was found by matching the script's filename. It
+>   no longer does: base-path resolution now comes from the library's own module URL, so a query string on the
+>   script tag is irrelevant. Re-verified against a server that appends `?ver=6.9` — every component upgrades,
+>   zero failed requests, clean console, with no `data-cornerstone` and no `null` version.
+> - **`data-cornerstone` is no longer needed for this**, and is now only for pointing at a different directory.
+>   It also keeps the origin now, so a CDN base works.
+> - **The classic `wp_enqueue_script` + `script_loader_tag` path also works on WordPress 7.1**, so it is a live
+>   fallback rather than an old-version story — and inside the block editor it is the *only* path that works.
+>
+> **How the failure actually looks**, since two earlier claims here were wrong:
+>
+> - It is **not silent.** The autoloader logs one `console.error` per component:
+>   `Unable to autoload <cs-button> from /components/button/button.js`. It was a `console.warn` until
+>   2026-08-24; nothing downstream recovers from a component that never upgrades, so it is an error.
+> - There is **no 404 to find.** WordPress's rewrite rules turn the request into a `301` and then a **`200`** —
+>   a 66 KB HTML 404 page served with a success status. Anyone told to watch for a 404 in the network panel will
+>   not see one. Watch the console instead.
+>
+> WordPress serves plugin files verbatim, so unlike Rails there is no filename-digest problem on top — which is
+> why setting the base path is sufficient here.
+>
+> Theme interference is real, mildly: Twenty Twenty-Five's `Manrope` inherits into the components in place of
+> Cornerstone's Inter. Nothing broke.
+>
+> **Not verified:** a registered block using `viewScriptModule`, and anything about WP VIP's asset policy.

package/dist/bundled/skills/cornerstone/references/installation.md

@@ -0,0 +1,151 @@
+# Cornerstone Components
+
+**Full documentation:** https://cruglobal.github.io/cornerstone-design-system
+
+Cornerstone Components is the `cs-*` custom-element library of the Cornerstone design system. The
+pages under **Components** are its reference: every one is generated from the same Custom Elements
+Manifest the package ships, so what you read here is what the component actually does.
+
+> **Info**
+>
+> This site is being ported from its previous generator a page at a time. Pages carry their original
+> prose until each is revised, so some of it still describes the library this one was forked from.
+
+## Installing via npm
+
+```bash
+npm install @cruglobal/cornerstone-components
+```
+
+The package is public. There is no registry to configure and nothing to authenticate against.
+
+It ships two builds of the same library, and which one you want depends on whether you have a bundler.
+**Unbundled** is ES modules that leave `lit` and the other dependencies as bare specifiers — it is what
+every import specifier resolves to, and your bundler resolves the rest. **Bundled** is the same modules
+with those dependencies inlined, so a browser loads them with no build step; that is the one to copy if
+you are self-hosting.
+
+`dist` never appears in an import specifier. It is the container the two builds sit in, not part of the
+public API.
+
+## Loading the library
+
+Two things have to reach the page: `cornerstone.css`, which carries the theme every component reads its
+tokens from, and the components themselves.
+
+<cs-tab-group>
+<cs-tab panel="npm">npm</cs-tab>
+<cs-tab panel="self-hosted">Self-Hosted</cs-tab>
+<cs-tab-panel name="npm">
+
+Import the stylesheet once, then import each component you use.
+
+```js
+import '@cruglobal/cornerstone-components/styles/cornerstone.css';
+import '@cruglobal/cornerstone-components/components/button/button.js';
+```
+
+```html
+<cs-button variant="brand">Click me</cs-button>
+```
+
+Every component's page carries its own import line under **Importing**, for npm, self-hosted and React.
+
+</cs-tab-panel>
+<cs-tab-panel name="self-hosted">
+
+Copy the bundled build out of the installed package and serve it from your own origin.
+
+```bash
+cp -R node_modules/@cruglobal/cornerstone-components/dist/bundled public/cornerstone
+```
+
+Copy the whole directory. The loader imports its chunks by relative path and fetches each component file
+at runtime, so `cornerstone.loader.js` on its own will not work.
+
+Then link the stylesheet and the loader.
+
+```html
+<link rel="stylesheet" href="/cornerstone/styles/cornerstone.css" />
+<script type="module" src="/cornerstone/cornerstone.loader.js"></script>
+
+<cs-button variant="brand">Click me</cs-button>
+```
+
+Nothing else is imported by hand: the loader watches the document and registers each `cs-*` element as
+it appears.
+
+</cs-tab-panel>
+</cs-tab-group>
+
+## Choosing how components load
+
+There are three ways to get a component's definition onto the page, and the right one depends on how
+your project serves JavaScript.
+
+**Cherry-picked imports** are the answer behind a bundler. Each one is a static specifier, so the
+bundler can see it, and you ship only the components you used.
+
+```js
+import '@cruglobal/cornerstone-components/components/button/button.js';
+```
+
+**The autoloader** registers components on demand — it watches the DOM and imports each `cs-*` element's
+definition as it finds one, including elements added later.
+
+```js
+import '@cruglobal/cornerstone-components/cornerstone.loader.js';
+```
+
+> **Warning**
+>
+> The autoloader resolves those imports at runtime, from its own module URL. A bundler cannot see an
+> import built that way, so it never emits the files the autoloader will ask for — it works where the
+> library is served as files, and 404s in a production bundle. Behind a bundler, cherry-pick.
+
+**Everything at once** loads the whole library in one import. It is the bundled build, so it carries its
+own copy of the dependencies — good for a prototype, wasteful for an application.
+
+```js
+import '@cruglobal/cornerstone-components/all';
+```
+
+## Light and dark
+
+Cornerstone's theme is light at the document root and switches to dark under a `cs-dark` class. Nothing
+applies it for you, `prefers-color-scheme` included, so a page that never sets it stays light.
+
+```html
+<html class="cs-dark"></html>
+```
+
+See [Theming](https://cruglobal.github.io/cornerstone-design-system/theming-overview) for what else that class list can carry, and
+[Built-in Themes](https://cruglobal.github.io/cornerstone-design-system/themes) for the two themes that ship.
+
+## Avoiding the flash
+
+Until a definition loads, the browser treats a `cs-*` tag as an unknown inline element — so the page
+paints unstyled and then reflows. The `cs-cloak` class hides an element, or the whole document, until
+its components have registered:
+
+```html
+<html class="cs-cloak"></html>
+```
+
+The autoloader removes it as soon as discovery completes, or after two seconds, whichever comes first.
+See [Reducing FOUCE](https://cruglobal.github.io/cornerstone-design-system/utilities/fouce).
+
+## Where to start
+
+- **Components** — the reference for all 70 elements, grouped by what they are for.
+- Each page opens with the component's tag, status and the version it landed in, then live examples,
+  then its full API: slots, attributes and properties, methods, events, CSS custom properties,
+  custom states and CSS parts.
+
+## Where to go next
+
+- [Usage](https://cruglobal.github.io/cornerstone-design-system/usage) — attributes, properties, slots, events, methods, and editor code completion.
+- [Frameworks](https://cruglobal.github.io/cornerstone-design-system/frameworks) — React, Vue, Angular, Svelte, Rails and WordPress.
+- [Theming](https://cruglobal.github.io/cornerstone-design-system/theming-overview) — themes, palettes, variants and design tokens.
+- [Form Controls](https://cruglobal.github.io/cornerstone-design-system/form-controls) — validation and form submission.
+- [Server Rendering](https://cruglobal.github.io/cornerstone-design-system/ssr) — rendering components on the server.