@tenphi/tasty 0.0.0-snapshot.e9718c0 → 0.0.0-snapshot.ea42c0b

package/README.md

@@ -17,21 +17,32 @@
 
 ---
 
-Tasty is a styling engine for design systems that generates deterministic CSS for stateful components. It compiles state maps into **mutually exclusive selectors**, so each property resolves from declared state logic instead of selector competition.
+Tasty is a styling engine for design systems that generates deterministic CSS for stateful components.
 
-It fits best when a team is defining a house styling language for reusable components: tokens, style props, state aliases, recipes, and sub-element rules that need to stay predictable as the system grows.
+It compiles state maps into **mutually exclusive selectors**, so for a given property and component state, one branch wins by construction instead of competing through cascade and specificity.
+
+That is the core guarantee: component styling resolves from declared state logic, not from source-order accidents or specificity fights.
+
+Tasty fits best when you are building a design system or component library with intersecting states, variants, tokens, sub-elements, responsive rules, and extension semantics that need to stay predictable over time.
+
+On top of that foundation, Tasty gives teams a governed styling model: a CSS-like DSL, tokens, recipes, typed style props, sub-elements, and multiple rendering modes.
+
+- **New here?** Start with [Comparison](docs/comparison.md) if you are evaluating fit.
+- **Adopting Tasty?** Read the [Adoption Guide](docs/adoption.md).
+- **Want the mechanism first?** Jump to [How It Actually Works](#how-it-actually-works).
+- **Ready to build?** Go to [Getting Started](docs/getting-started.md).
 
 ## Why Tasty
 
-- **Deterministic composition, not cascade fights** — Tasty generates mutually exclusive selectors, so stateful styles resolve from the state map you declared rather than source order or specificity accidents. See [How It Actually Works](#how-it-actually-works).
-- **Built for design-system teams** — Best fit for teams building reusable components with intersecting states, variants, tokens, sub-elements, responsive rules, and extension semantics that must stay predictable over time.
-- **A governed styling model, not just syntax sugar** — Tasty is not just a syntax layer. It gives design-system teams a way to define the styling language product teams consume: tokens, units, recipes, style props, state aliases, and sub-element rules.
-- **DSL that still feels like CSS** — Property names you already know (`padding`, `color`, `display`) with syntax sugar that removes boilerplate. Learn the DSL in minutes, not days. Start with the [Style DSL](docs/dsl.md), then use [Style Properties](docs/styles.md) as the handler reference.
+- **Deterministic composition, not cascade fights** — Stateful styles resolve from the state map you declared, not from selector competition. See [How It Actually Works](#how-it-actually-works).
+- **Built for design-system teams** — Best fit for reusable component systems with complex state interactions.
+- **A governed styling model, not just syntax sugar** — Design-system authors define the styling language product teams consume.
+- **DSL that still feels like CSS** — Familiar property names, less selector boilerplate. Start with the [Style DSL](docs/dsl.md), then use [Style Properties](docs/styles.md) as the handler reference.
 
 ### Supporting capabilities
 
-- **Typed style props** — `styleProps` lets you expose selected styles as typed React props. Use `<Button placeSelf="end">` or `<Space flow="row" gap="2x">` without extra wrappers, utility classes, or `styles` overrides. The same props also accept state maps, so responsive values work with the same API. See [CSS properties as props](#css-properties-as-props).
-- **Runtime, SSR, and zero-runtime options** — Use `tasty()` for runtime React components, add SSR integrations when your framework renders that runtime on the server, or use `tastyStatic()` when you specifically want build-time extraction instead of runtime styling.
+- **Typed style props and mod props** — `styleProps` exposes selected CSS properties as typed React props (`<Space flow="row" gap="2x">`); `modProps` does the same for modifier keys (`<Button isLoading size="large">`). Both support state maps and full TypeScript autocomplete. See [Style Props](#style-props) and [Mod Props](#mod-props).
+- **Server-compatible by default, zero client JS in server-only contexts** — All `tasty()` components and style functions are hook-free. In server-only rendering (Next.js RSC, Astro without islands, SSG), they produce zero client JavaScript with the full feature set. Add SSR integration only when your app also has client-side hydration. Use `tastyStatic()` only when you need build-time extraction without React.
 - **Broad modern CSS coverage** — Media queries, container queries, `@supports`, `:has()`, `@starting-style`, `@property`, `@keyframes`, and more. Features that do not fit the component model (such as `@layer` and `!important`) are intentionally left out.
 - **Performance and caching** — Runtime mode injects CSS on demand, reuses chunks aggressively, and relies on multi-level caching so large component systems stay practical.
 - **TypeScript-first and AI-friendly** — Style definitions are declarative, structurally consistent, and fully typed, which helps both humans and tooling understand advanced stateful styles without hidden cascade logic.
@@ -40,7 +51,7 @@ It fits best when a team is defining a house styling language for reusable compo
 
 Modern component styling becomes fragile when multiple selectors can still win for the same property. Hover, disabled, theme, breakpoint, parent state, and root state rules start competing through specificity and source order.
 
-Tasty replaces that competition with explicit state-map resolution. Each property compiles into mutually exclusive branches, so reusable component styling stays deterministic as systems grow. For the full mechanism, jump to [How It Actually Works](#how-it-actually-works).
+Tasty replaces that competition with explicit state-map resolution. Each property compiles into mutually exclusive branches, so component styling stays deterministic as systems grow. For the full mechanism, jump to [How It Actually Works](#how-it-actually-works).
 
 ## Installation
 
@@ -63,10 +74,12 @@ yarn add @tenphi/tasty
 
 ## Start Here
 
+For the fuller docs map beyond the quick routes above, start here:
+
 - **[Comparison](docs/comparison.md)** — read this first if you are evaluating whether Tasty fits your team's styling model
 - **[Adoption Guide](docs/adoption.md)** — understand who Tasty is for, where it fits, and how to introduce it incrementally
 - **[Getting Started](docs/getting-started.md)** — the canonical onboarding path: install, first component, optional shared `configure()`, ESLint, editor tooling, and rendering mode selection
-- **[Style rendering pipeline](docs/PIPELINE.md)** — see the selector model behind deterministic style resolution
+- **[Style rendering pipeline](docs/pipeline.md)** — see the selector model behind deterministic style resolution
 - **[Docs Hub](docs/README.md)** — choose docs by role and task: runtime, zero-runtime, runtime SSR integration, design-system authoring, internals, and debugging
 - **[Methodology](docs/methodology.md)** — the recommended component model and public API conventions for design-system code
 
@@ -95,7 +108,9 @@ const Card = tasty({
 <Card>Hello World</Card>
 ```
 
-Every value maps to CSS you'd recognize. This example is intentionally plain and config-free. When you want a more design-system-shaped authoring model, Tasty also supports built-in units, tokens, recipes, state aliases, and color values such as `okhsl(...)` without extra runtime libraries.
+Every value maps to CSS you'd recognize. This example is intentionally a simple first contact, not a tour of the whole DSL.
+
+When you want a more design-system-shaped authoring model, Tasty also supports built-in units, tokens, recipes, state aliases, and color values such as `okhsl(...)` without extra runtime libraries.
 
 Use `configure()` when you want to define shared tokens, state aliases, recipes, or other conventions for your app or design system. For a fuller onboarding path, follow [Getting Started](docs/getting-started.md).
 
@@ -163,58 +178,17 @@ configure({
 
 Use `configure()` once when your app or design system needs shared aliases, tokens, recipes, or parser extensions. Predefined states turn complex selector logic into single tokens, so teams can write `@mobile` instead of repeating media query expressions in every component.
 
-### CSS properties as props
-
-Beyond state resolution, Tasty can also expose selected style controls as typed component props. That lets design systems keep layout and composition inside governed component APIs instead of pushing teams toward wrapper elements or ad hoc styling escapes.
-
-With `styleProps`, a component can expose the styles you choose as normal typed props. You can adjust layout, spacing, alignment, or positioning where the component is used while staying inside a typed, design-system-aware API.
-
-```tsx
-import { tasty, FLOW_STYLES, POSITION_STYLES } from '@tenphi/tasty';
-
-const Space = tasty({
-  styles: {
-    display: 'flex',
-    flow: 'column',
-    gap: '1x',
-  },
-  styleProps: FLOW_STYLES,
-});
-
-const Button = tasty({
-  as: 'button',
-  styles: {
-    padding: '1.5x 3x',
-    fill: '#primary',
-    color: '#primary-text',
-    radius: true,
-  },
-  styleProps: POSITION_STYLES,
-});
-```
+### Props as the public API
 
-Now you can compose layout and tweak component positioning directly in JSX:
+`styleProps` exposes selected CSS properties as typed React props, and `modProps` does the same for modifier keys. Together they let design systems define a governed, typed component API without wrapper elements or `styles` overrides:
 
 ```tsx
 <Space flow="row" gap="2x" placeItems="center">
-  <Title>Dashboard</Title>
-  <Button placeSelf="end">Add Item</Button>
-</Space>
-```
-
-The same props also support state maps, so responsive values use the exact same API:
-
-```tsx
-<Space
-  flow={{ '': 'column', '@tablet': 'row' }}
-  gap={{ '': '2x', '@tablet': '4x' }}
->
-  <Sidebar />
-  <Content />
+  <Button isLoading size="large" placeSelf="end">Submit</Button>
 </Space>
 ```
 
-Layout components can expose flow props. Buttons can expose positioning props. Each component can offer only the style props that make sense for its role, while still keeping tokens, custom units, and state maps fully typed. This works in runtime `tasty()` components, not in `tastyStatic()`.
+See [Style Props](#style-props) and [Mod Props](#mod-props) below, or the full reference in [React API](docs/react-api.md#style-props).
 
 ## Choose a Styling Approach
 
@@ -222,16 +196,17 @@ Once you understand the component model, pick the rendering mode that matches yo
 
 | Approach | Entry point | Best for | Trade-off |
 |----------|-------------|----------|-----------|
-| **Runtime** | `@tenphi/tasty` | Interactive apps with reusable stateful components and design systems | Full feature set; CSS is generated on demand at runtime |
-| **Zero-runtime** | `@tenphi/tasty/static` | Static sites, SSG, landing pages | Requires the Babel plugin; no component-level `styleProps` or runtime-only APIs |
+| **Runtime (default)** | `tasty()` from `@tenphi/tasty` | All React apps — server-rendered by default, zero client JS until you need interactivity | Full feature set; CSS computed during React rendering (server or client) |
+| **Runtime + SSR integration** | Add `@tenphi/tasty/ssr/*` | Apps with client-side hydration (Next.js client components, Astro islands) | Adds CSS deduplication, FOUC prevention, and client cache hydration |
+| **Zero-runtime** | `tastyStatic()` from `@tenphi/tasty/static` | Non-React frameworks or when you need build-time extraction without React | Requires the Babel plugin; no component-level `styleProps` or runtime-only APIs |
 
-If your framework can execute runtime React code on the server, you can also add **SSR on top of runtime** with `@tenphi/tasty/ssr/*`. This uses the same `tasty()` pipeline, but collects CSS during server rendering and hydrates the cache on the client. That is the model for Next.js, generic React SSR, and Astro islands. See [Getting Started](docs/getting-started.md#choosing-a-rendering-mode), [Zero Runtime](docs/tasty-static.md), and [Server-Side Rendering](docs/ssr.md).
+All `tasty()` components are hook-free and work as React Server Components. In server-only contexts — Next.js RSC without `'use client'`, Astro without `client:*` directives, and other SSG setups — they produce the same end result as `tastyStatic()` (static HTML + CSS, zero client JavaScript) but with the full feature set including `styleProps`, sub-elements, and variants. SSR integration is only needed when your app also has client-side rendering. See [Getting Started](docs/getting-started.md#choosing-a-rendering-mode), [Zero Runtime](docs/tasty-static.md), and [Server-Side Rendering](docs/ssr.md).
 
 ## How It Actually Works
 
 This is the core idea that makes everything else possible.
 
-For the end-to-end architecture — parsing state keys, building exclusive conditions, merging by output, and materializing selectors and at-rules — see **[Style rendering pipeline](docs/PIPELINE.md)**.
+For the end-to-end architecture — parsing state keys, building exclusive conditions, merging by output, and materializing selectors and at-rules — see **[Style rendering pipeline](docs/pipeline.md)**.
 
 ### The structural problem with normal CSS
 
@@ -327,7 +302,7 @@ Every rule is guarded by the negation of higher-priority rules. No two rules can
 
 By absorbing selector complexity, Tasty makes advanced CSS patterns practical again — nested container queries, multi-condition `@supports` gates, and combined root-state/media branches. You stay in pure CSS instead of relying on JavaScript workarounds, so the browser can optimize layout, painting, and transitions natively. Tasty keeps the solution in CSS while removing much of the selector bookkeeping that is hard to maintain by hand.
 
-[Try it in the Cube UI Kit Storybook playground →](https://cube-ui-kit.vercel.app/?path=/story/getting-started-tasty-playground--playground)
+[Try it in the playground →](https://tasty.style/playground)
 
 ## Capabilities
 
@@ -373,7 +348,7 @@ Every style property accepts a state mapping object. Keys can be combined with b
 | Feature query | `@supports(display: grid)` | `@supports (display: grid)` |
 | Entry animation | `@starting` | `@starting-style` |
 
-Combine with `&` (AND), `|` (OR), `!` (NOT):
+Combine with `&` (AND), `|` (OR), `!` (NOT), `^` (XOR):
 
 ```tsx
 fill: {
@@ -385,220 +360,109 @@ fill: {
 
 ### Sub-Element Styling
 
-Style inner elements from the parent component definition. No extra components, no CSS leakage:
+Compound components can style inner parts from the parent definition with capitalized keys in `styles` and optional `elements` declarations, producing typed sub-components like `<Card.Title />` instead of separate wrapper components or ad hoc class naming.
 
-```tsx
-const Card = tasty({
-  styles: {
-    padding: '4x',
-    Title: { preset: 'h3', color: '#primary' },
-    Content: { color: '#text', preset: 't2' },
-  },
-  elements: { Title: 'h2', Content: 'div' },
-});
-
-<Card>
-  <Card.Title>Heading</Card.Title>
-  <Card.Content>Body text</Card.Content>
-</Card>
-```
+Sub-elements share the root state context by default, so keys like `:hover`, modifiers, root states, and media queries resolve as one coordinated styling block. Use `@own(...)` when a sub-element should react to its own state, and use the `$` selector affix when you need precise descendant targeting.
 
-Sub-elements use `data-element` attributes — no extra class names, no naming conventions.
+See [React API - Sub-element Styling](docs/react-api.md#sub-element-styling), [Style DSL - Advanced States](docs/dsl.md#advanced-states--prefix), and [Methodology](docs/methodology.md#component-architecture-root--sub-elements).
 
-By default, sub-elements participate in the same state context as the root component. That means mappings like `:hover`, `theme=danger`, `[role="button"]`, and other keys are evaluated as one unified block, which keeps styling logic predictable across the whole markup tree.
+### Style Props
 
-Use `@own(...)` when a sub-element should react to its own state instead of the root state context.
-
-Class selectors are also supported, but modifiers/pseudo-classes are usually the better default in design-system code.
-
-Use the sub-element selector `$` when you need precise descendant targeting to avoid leakage in deeply nested component trees.
-
-### Variants
-
-Variants are designed to keep single-component CSS lean. Instead of generating dozens of static button classes up front, define all versions once and let runtime usage decide what CSS is actually emitted.
+`styleProps` exposes selected CSS properties as typed React props. Components control which properties to open up; consumers get layout and composition knobs without `styles` overrides. Supports state maps for responsive values.
 
 ```tsx
-const Button = tasty({
-  styles: { padding: '2x 4x', radius: '1r' },
-  variants: {
-    default: { fill: '#primary', color: '#on-primary' },
-    danger: { fill: '#danger', color: '#on-danger' },
-    outline: { fill: 'transparent', border: '1bw solid #primary' },
-  },
+const Space = tasty({
+  styles: { display: 'flex', flow: 'column', gap: '1x' },
+  styleProps: FLOW_STYLES,
 });
 
-<Button variant="danger">Delete</Button>
+<Space flow="row" gap={{ '': '2x', '@tablet': '4x' }}>
 ```
 
-### Recipes
+See [React API - Style Props](docs/react-api.md#style-props) and [Methodology - styleProps](docs/methodology.md#styleprops-as-the-public-api).
 
-Recipes are predefined style sets that work like composable styling classes for Tasty. They can be pre-applied or post-applied to current styles, which lets you add reusable state logic while still allowing local style overrides.
+### Mod Props
 
-```tsx
-configure({
-  recipes: {
-    card: { padding: '4x', fill: '#surface', radius: '1r', border: true },
-    elevated: { shadow: '0 2x 4x #shadow' },
-  },
-});
+`modProps` exposes modifier keys as typed React props — the modifier equivalent of `styleProps`. Accepts an array of key names or an object with type descriptors (`Boolean`, `String`, `Number`, or enum arrays) for full TypeScript autocomplete.
 
-const ProfileCard = tasty({
+```tsx
+const Button = tasty({
+  as: 'button',
+  modProps: { isLoading: Boolean, size: ['sm', 'md', 'lg'] as const },
   styles: {
-    recipe: 'card elevated',
-    color: '#text',
+    fill: { '': '#primary', isLoading: '#primary.5' },
+    padding: { '': '2x 4x', 'size=sm': '1x 2x' },
   },
 });
-```
 
-Use `/` to post-apply recipes after local styles when you need recipe states/styles to win the final merge order. Use `none` to skip base recipes: `recipe: 'none / disabled'`.
+<Button isLoading size="lg">Submit</Button>
+```
 
-### Auto-Inferred `@property`
+See [React API - Mod Props](docs/react-api.md#mod-props) and [Methodology - modProps](docs/methodology.md#modprops-and-mods).
 
-CSS custom properties do not animate smoothly by default because the browser does not know how to interpolate their values. The [`@property`](https://developer.mozilla.org/en-US/docs/Web/CSS/@property) at-rule fixes that by declaring a property's syntax, such as `<number>` or `<color>`.
+### Variants
 
-In Tasty, you usually do not need to declare `@property` manually. When a custom property is assigned a concrete value, Tasty infers the syntax and registers the matching `@property` for you:
+Variants let one component expose named visual versions without pre-generating a separate class for every possible combination. In runtime mode, Tasty emits only the variant CSS that is actually used.
 
-```tsx
-const Pulse = tasty({
-  styles: {
-    animation: 'pulse 2s infinite',
-    transform: 'scale($pulse-scale)',
-    '@keyframes': {
-      pulse: {
-        '0%, 100%': { '$pulse-scale': 1 },
-        '50%': { '$pulse-scale': 1.05 },
-      },
-    },
-  },
-});
-```
+See [React API - Variants](docs/react-api.md#variants).
 
-Here, `$pulse-scale: 1` is inferred as `<number>`, so Tasty injects `@property --pulse-scale` automatically before using it in the animation. Numeric types (`<number>`, `<length>`, `<percentage>`, `<angle>`, `<time>`) are inferred from values; `<color>` is inferred from the `#name` token convention.
+### Recipes
 
-If you prefer full manual control, disable auto-inference globally with `configure({ autoPropertyTypes: false })`.
+Recipes are reusable style bundles defined in `configure({ recipes })` and applied with the `recipe` style property. They are useful when your design system wants shared state logic or visual presets without forcing every component to repeat the same style map.
 
-### Explicit `@properties`
+Use `/` to post-apply recipes after local styles when recipe states should win the final merge order, and use `none` to skip base recipes entirely.
 
-Declare `@properties` yourself only when you need to override the defaults, for example to set `inherits: false` or provide a custom `initialValue`:
+See [Style DSL - Recipes](docs/dsl.md#recipes) and [Configuration - recipes](docs/configuration.md#recipes).
 
-```tsx
-'@properties': {
-  '$pulse-scale': { syntax: '<number>', inherits: false, initialValue: 1 },
-},
-```
+### Auto-Inferred `@property`
 
-### React Hooks
+Tasty usually removes the need to hand-author CSS [`@property`](https://developer.mozilla.org/en-US/docs/Web/CSS/@property) rules. When a custom property receives a concrete value, Tasty infers its syntax and registers the matching `@property` automatically, which makes transitions and animations on custom properties work without extra boilerplate.
 
-For cases where you don't need a full component:
+If you prefer explicit control, disable inference with `configure({ autoPropertyTypes: false })` or declare the properties yourself.
 
-```tsx
-import { useStyles, useGlobalStyles, useRawCSS } from '@tenphi/tasty';
+See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
-function App() {
-  const { className } = useStyles({ padding: '2x', fill: '#surface' });
-  useGlobalStyles('body', { margin: '0' });
-  useRawCSS('@font-face { font-family: "Custom"; src: url(...); }');
+### Explicit `@properties`
 
-  return <main className={className}>...</main>;
-}
-```
+Use explicit `@properties` only when you need to override defaults such as `inherits: false` or a custom `initialValue`.
 
-### Zero-Runtime Mode
+See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
-Extract all CSS at build time. Zero JavaScript overhead in production:
+### Style Functions
 
-```tsx
-import { tastyStatic } from '@tenphi/tasty/static';
+When you do not need a full component wrapper, use the style functions directly: `useStyles` for local class names, `useGlobalStyles` for selector-scoped global CSS, `useRawCSS` for raw rules, plus `useKeyframes`, `useProperty`, `useFontFace`, and `useCounterStyle` for animation, custom-property, font, and counter-style primitives. All style functions are hook-free and work in React Server Components.
 
-const card = tastyStatic({
-  padding: '4x',
-  fill: '#surface',
-  radius: '1r',
-  color: { '': '#text', '@dark': '#text-on-dark' },
-});
+See [React API - Style Functions](docs/react-api.md#style-functions).
 
-// card is a CSS class name string
-<div className={card}>Static styles, zero runtime</div>
-```
+### Zero-Runtime Mode
 
-Configure the Babel plugin:
+Use `tastyStatic` when you want the same DSL and state model, but with CSS extracted at build time and no styling runtime in the client bundle. It is a strong fit for static sites, landing pages, and other build-time-first setups.
 
-```js
-module.exports = {
-  plugins: [
-    ['@tenphi/tasty/babel-plugin', {
-      output: 'public/tasty.css',
-      config: {
-        states: { '@dark': '@root(schema=dark)' },
-      },
-    }],
-  ],
-};
-```
+See [Zero Runtime (tastyStatic)](docs/tasty-static.md) and [Getting Started - Choosing a rendering mode](docs/getting-started.md#choosing-a-rendering-mode).
 
 ### `tasty` vs `tastyStatic`
 
-| | `tasty` (runtime) | `tastyStatic` (zero-runtime) |
-|---|---|---|
-| **Output** | React component | CSS class name |
-| **CSS injection** | Runtime `<style>` tags | Build-time extraction |
-| **Runtime cost** | Style generation on mount | None |
-| **Generated CSS scope** | Only styles/variants used at runtime | All extracted static styles at build time |
-| **Dynamic values** | Fully supported | Via CSS custom properties |
-| **Sub-elements** | Built-in (`<C.Title>`) | Manual (`data-element`) |
-| **Variants** | Built-in (`variants` option) | Separate static styles |
-| **Framework** | React | Any (requires Babel) |
-| **Best for** | Interactive apps with reusable stateful components, design systems | Static sites, SSG, landing pages |
+`tasty()` returns React components that compute CSS during rendering. In server-only contexts, this produces static HTML + CSS with zero client JavaScript — the same end result as `tastyStatic()` but with the full feature set. `tastyStatic()` returns class names and extracts CSS during the build via a Babel plugin, with no React dependency at runtime. Both share the same DSL, tokens, units, state mappings, and recipes. Use `tasty()` as the default for any React-based setup; use `tastyStatic()` when you need build-time extraction without React.
 
-Both share the same DSL, tokens, units, state mappings, and recipes.
+See [Zero Runtime (tastyStatic)](docs/tasty-static.md), [React API](docs/react-api.md), and [Comparison - Build-time vs runtime](docs/comparison.md#build-time-vs-runtime).
 
 ### Server-Side Rendering
 
-SSR with zero-cost client hydration. Existing `tasty()` components work unchanged — SSR is opt-in and requires no per-component modifications. Supports Next.js (App Router with streaming), Astro (middleware + islands), and any React-based framework via the core API. Requires React 18+.
-
-**Next.js setup:**
+`tasty()` components already work on the server without any SSR integration — they are hook-free and render as React Server Components by default. In server-only contexts (Next.js RSC, Astro without islands), they produce zero client JavaScript with the full feature set.
 
-```tsx
-// app/tasty-registry.tsx
-'use client';
-
-import { TastyRegistry } from '@tenphi/tasty/ssr/next';
+SSR integration (`TastyRegistry`, `tastyIntegration`) adds CSS batching, deduplication across component trees, FOUC prevention, and client cache hydration. Use it when your app also has client-side rendering:
 
-export default function TastyStyleRegistry({
-  children,
-}: {
-  children: React.ReactNode;
-}) {
-  return <TastyRegistry>{children}</TastyRegistry>;
-}
-```
-
-```tsx
-// app/layout.tsx
-import TastyStyleRegistry from './tasty-registry';
-
-export default function RootLayout({
-  children,
-}: {
-  children: React.ReactNode;
-}) {
-  return (
-    <html>
-      <body>
-        <TastyStyleRegistry>{children}</TastyStyleRegistry>
-      </body>
-    </html>
-  );
-}
-```
+- `@tenphi/tasty/ssr/next` for Next.js App Router (mixed server + client components)
+- `@tenphi/tasty/ssr/astro` for Astro (with or without islands)
+- The core SSR API for other React SSR setups
 
-See the [full SSR guide](docs/ssr.md) for Astro integration, streaming SSR, generic framework usage, troubleshooting, and the current requirements.
+See the [full SSR guide](docs/ssr.md).
 
 ## Entry Points
 
 | Import | Description | Platform |
 |--------|-------------|----------|
-| `@tenphi/tasty` | Runtime style engine (`tasty`, hooks, `configure`) | Browser |
+| `@tenphi/tasty` | Runtime style engine (`tasty`, style functions, `configure`) | Browser |
 | `@tenphi/tasty/static` | Zero-runtime static styles (`tastyStatic`) | Browser |
 | `@tenphi/tasty/core` | Lower-level internals (config, parser, pipeline, injector, style handlers) for tooling and advanced use | Browser / Node |
 | `@tenphi/tasty/babel-plugin` | Babel plugin for zero-runtime CSS extraction | Node |
@@ -606,7 +470,8 @@ See the [full SSR guide](docs/ssr.md) for Astro integration, streaming SSR, gene
 | `@tenphi/tasty/next` | Next.js integration wrapper | Node |
 | `@tenphi/tasty/ssr` | Core SSR API (collector, context, hydration) | Node |
 | `@tenphi/tasty/ssr/next` | Next.js App Router SSR integration | Node |
-| `@tenphi/tasty/ssr/astro` | Astro middleware + auto-hydration | Node / Browser |
+| `@tenphi/tasty/ssr/astro` | Astro integration + middleware | Node |
+| `@tenphi/tasty/ssr/astro-client` | Astro client-side cache hydration | Browser |
 
 ## Browser Requirements
 
@@ -624,11 +489,13 @@ All sizes measured with [size-limit](https://github.com/ai/size-limit) — minif
 
 | Entry point | Size |
 |-------------|------|
-| `@tenphi/tasty` (runtime + SSR) | ~44 kB |
-| `@tenphi/tasty/core` (runtime, no SSR) | ~41 kB |
-| `@tenphi/tasty/static` (zero-runtime) | ~1.5 kB |
+| `@tenphi/tasty` (runtime + SSR) | 50.19 kB |
+| `@tenphi/tasty/core` (runtime, no SSR) | 47.76 kB |
+| `@tenphi/tasty/static` (zero-runtime) | 16.43 kB |
+| `@tenphi/tasty/zero` (programmatic extraction) | 29.6 kB |
+| `@tenphi/tasty/babel-plugin` (Babel plugin entry) | 43.7 kB |
 
-Run `pnpm size` for exact up-to-date numbers.
+Run `pnpm size` to reproduce (outputs may shift slightly with releases).
 
 ### Runtime Benchmarks
 
@@ -746,7 +613,7 @@ Start from the docs hub if you want the shortest path to the right guide for you
 ### Reference
 
 - **[Style DSL](docs/dsl.md)** — The Tasty style language: state maps, tokens, units, color syntax, extending semantics, recipes, keyframes, and @property
-- **[Runtime API](docs/runtime.md)** — React-specific API: `tasty()` factory, component props, variants, sub-elements, and hooks
+- **[React API](docs/react-api.md)** — React-specific API: `tasty()` factory, component props, variants, sub-elements, and style functions
 - **[Configuration](docs/configuration.md)** — Global configuration: tokens, recipes, custom units, style handlers, and TypeScript extensions
 - **[Style Properties](docs/styles.md)** — Complete reference for all enhanced style properties: syntax, values, modifiers, and recommendations
 
@@ -757,7 +624,7 @@ Start from the docs hub if you want the shortest path to the right guide for you
 
 ### Internals
 
-- **[Style rendering pipeline](docs/PIPELINE.md)** — How `Styles` become mutually exclusive CSS rules: parse → exclusives → combinations → handlers → merge → materialize (`src/pipeline/`)
+- **[Style rendering pipeline](docs/pipeline.md)** — How `Styles` become mutually exclusive CSS rules: parse → exclusives → combinations → handlers → merge → materialize (`src/pipeline/`)
 - **[Style Injector](docs/injector.md)** — Internal CSS injection engine: `inject()`, `injectGlobal()`, `injectRawCSS()`, `keyframes()`, deduplication, reference counting, cleanup, SSR support, and Shadow DOM
 - **[Debug Utilities](docs/debug.md)** — Runtime CSS inspection via `tastyDebug`: CSS extraction, element inspection, cache metrics, chunk breakdown, and performance monitoring
 

package/dist/{ssr/async-storage.js → async-storage-B7_o6FKt.js}

@@ -1,5 +1,4 @@
 import { AsyncLocalStorage } from "node:async_hooks";
-
 //#region src/ssr/async-storage.ts
 /**
 * AsyncLocalStorage integration for SSR collector discovery.
@@ -9,27 +8,37 @@ import { AsyncLocalStorage } from "node:async_hooks";
 * The middleware calls runWithCollector() around the render, and
 * useStyles() calls getSSRCollector() to find it.
 *
+* Uses globalThis to ensure the AsyncLocalStorage instance is shared
+* across module instances — frameworks like Astro may load middleware
+* and page components from separate module graphs.
+*
 * This module imports from 'node:async_hooks' — it must be excluded
 * from client bundles via the build configuration.
 */
-const tastySSRStorage = new AsyncLocalStorage();
+const ALS_KEY = "__tasty_ssr_als__";
+function getSharedStorage() {
+	const g = globalThis;
+	if (!g[ALS_KEY]) g[ALS_KEY] = new AsyncLocalStorage();
+	return g[ALS_KEY];
+}
 /**
 * Run a function with a ServerStyleCollector bound to the current
 * async context. All useStyles() calls within `fn` (and any async
 * continuations) will find this collector via getSSRCollector().
 */
 function runWithCollector(collector, fn) {
-	return tastySSRStorage.run(collector, fn);
+	return getSharedStorage().run(collector, fn);
 }
 /**
 * Retrieve the ServerStyleCollector bound to the current async context.
 * Returns null when called outside of runWithCollector() or on the client.
 */
 function getSSRCollector() {
-	if (typeof tastySSRStorage?.getStore !== "function") return null;
-	return tastySSRStorage.getStore() ?? null;
+	const storage = getSharedStorage();
+	if (typeof storage?.getStore !== "function") return null;
+	return storage.getStore() ?? null;
 }
-
 //#endregion
-export { getSSRCollector, runWithCollector };
-//# sourceMappingURL=async-storage.js.map
+export { runWithCollector as n, getSSRCollector as t };
+
+//# sourceMappingURL=async-storage-B7_o6FKt.js.map

package/dist/async-storage-B7_o6FKt.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"async-storage-B7_o6FKt.js","names":[],"sources":["../src/ssr/async-storage.ts"],"sourcesContent":["/**\n * AsyncLocalStorage integration for SSR collector discovery.\n *\n * Used by Astro middleware and generic framework integrations where\n * the library cannot wrap the React tree with a context provider.\n * The middleware calls runWithCollector() around the render, and\n * useStyles() calls getSSRCollector() to find it.\n *\n * Uses globalThis to ensure the AsyncLocalStorage instance is shared\n * across module instances — frameworks like Astro may load middleware\n * and page components from separate module graphs.\n *\n * This module imports from 'node:async_hooks' — it must be excluded\n * from client bundles via the build configuration.\n */\n\nimport { AsyncLocalStorage } from 'node:async_hooks';\n\nimport type { ServerStyleCollector } from './collector';\n\nconst ALS_KEY = '__tasty_ssr_als__';\n\nfunction getSharedStorage(): AsyncLocalStorage<ServerStyleCollector> {\n  const g = globalThis as Record<string, unknown>;\n  if (!g[ALS_KEY]) {\n    g[ALS_KEY] = new AsyncLocalStorage<ServerStyleCollector>();\n  }\n  return g[ALS_KEY] as AsyncLocalStorage<ServerStyleCollector>;\n}\n\n/**\n * Run a function with a ServerStyleCollector bound to the current\n * async context. All useStyles() calls within `fn` (and any async\n * continuations) will find this collector via getSSRCollector().\n */\nexport function runWithCollector<T>(\n  collector: ServerStyleCollector,\n  fn: () => T,\n): T {\n  return getSharedStorage().run(collector, fn);\n}\n\n/**\n * Retrieve the ServerStyleCollector bound to the current async context.\n * Returns null when called outside of runWithCollector() or on the client.\n */\nexport function getSSRCollector(): ServerStyleCollector | null {\n  const storage = getSharedStorage();\n  if (typeof storage?.getStore !== 'function') return null;\n  return storage.getStore() ?? null;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;AAoBA,MAAM,UAAU;AAEhB,SAAS,mBAA4D;CACnE,MAAM,IAAI;AACV,KAAI,CAAC,EAAE,SACL,GAAE,WAAW,IAAI,mBAAyC;AAE5D,QAAO,EAAE;;;;;;;AAQX,SAAgB,iBACd,WACA,IACG;AACH,QAAO,kBAAkB,CAAC,IAAI,WAAW,GAAG;;;;;;AAO9C,SAAgB,kBAA+C;CAC7D,MAAM,UAAU,kBAAkB;AAClC,KAAI,OAAO,SAAS,aAAa,WAAY,QAAO;AACpD,QAAO,QAAQ,UAAU,IAAI"}