@tenphi/tasty 0.0.0-snapshot.89ab060 → 0.0.0-snapshot.8c027cf

package/README.md

@@ -5,8 +5,8 @@
 <h1 align="center">Tasty</h1>
 
 <p align="center">
-  <strong>The styling engine built for design systems.</strong><br>
-  Deterministic CSS generation. State-aware DSL. Zero specificity conflicts. Ever.
+  <strong>Deterministic styling for stateful component systems.</strong><br>
+  A design-system styling engine that compiles component states into mutually exclusive selectors.
 </p>
 
 <p align="center">
@@ -17,23 +17,41 @@
 
 ---
 
-Most CSS-in-JS libraries emit rules that compete through cascade and specificity. Tasty emits **mutually exclusive CSS selectors** — for any component state combination, exactly one selector matches each property at a time. No cascade conflicts, no specificity wars, no `!important` escapes. Components compose and extend without breaking each other.
+Tasty is a styling engine for design systems that generates deterministic CSS for stateful components.
 
-That guarantee unlocks a concise, CSS-like DSL where design tokens, custom units, responsive states, container queries, sub-element styling, and theming all compose without surprises — one coherent system that scales from a single component to an enterprise design system.
+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 at any scale** — Exclusive selector generation eliminates the entire class of cascade/specificity bugs. Every state combination resolves to exactly one CSS rule per property. Refactor freely. See [How It Actually Works](#how-it-actually-works).
-- **AI-friendly by design** — Style definitions are declarative, self-contained, and structurally consistent. AI tools can read, understand, and refactor even advanced state bindings as confidently as a human — because there's no hidden cascade logic or implicit ordering to second-guess.
-- **DSL that 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.
-- **CSS properties as normal component 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).
-- **Design-system native** — Color tokens (`#primary`), spacing units (`2x`), typography presets (`h1`, `t2`), border radius (`1r`), and recipes are first-class primitives, not afterthoughts. Built-in units and standard color values work out of the box, and [Configuration](docs/configuration.md) lets teams define shared conventions on top.
-- **Near-complete modern CSS coverage** — Media queries, container queries, `@supports`, `:has()`, `@starting-style`, `@property`, `@keyframes`, etc. Some features that don't fit Tasty's component model (such as `@layer` and `!important`) are intentionally omitted, but real-world use cases are covered almost completely.
-- **Runtime, zero-runtime, or SSR — your call** — Use `tasty()` for dynamic React components with runtime injection, `tastyStatic()` with the Babel plugin for zero-runtime CSS extraction, or enable SSR with zero-cost client hydration for Next.js, Astro, or any React framework. Same DSL, same tokens, same output.
-- **Only generate what is used** — In runtime mode, Tasty injects CSS on demand for mounted components/variants, so your app avoids shipping style rules for UI states that are never rendered.
-- **Runtime performance that holds at scale** — The runtime path is tested against enterprise-scale applications and tuned with multi-level caching, chunk-level style reuse, style garbage collection, and a dedicated injector.
-- **Composable and extensible by design** — Extend any component's styles with proper merge semantics, and evolve built-in behavior through configuration and plugins.
-- **TypeScript-first** — Full type definitions, module augmentation for custom properties, and autocomplete for tokens, presets, and themes. See [Configuration](docs/configuration.md).
+- **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 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).
+- **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.
+- **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.
+
+## Why It Exists
+
+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 component styling stays deterministic as systems grow. For the full mechanism, jump to [How It Actually Works](#how-it-actually-works).
 
 ## Installation
 
@@ -56,20 +74,15 @@ 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
-- **[Docs Hub](docs/README.md)** — choose docs by role and task: runtime, zero-runtime, SSR, design-system authoring, internals, and debugging
+- **[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
 
-## Choose a Rendering Mode
-
-| Mode | Entry point | Best for | Trade-off |
-|------|-------------|----------|-----------|
-| **Runtime** | `@tenphi/tasty` | Interactive apps 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 |
-| **SSR** | `@tenphi/tasty/ssr/*` | Next.js, Astro, and other streaming React SSR setups | Uses runtime `tasty()` with server-collected CSS and hydration cache transfer |
-
-All three share the same DSL, tokens, units, and state mappings. See [Getting Started](docs/getting-started.md#choosing-a-rendering-mode), [Zero Runtime](docs/tasty-static.md), and [Server-Side Rendering](docs/ssr.md).
-
 ## Quick Start
 
 ### Create a styled component
@@ -82,12 +95,12 @@ const Card = tasty({
   styles: {
     display: 'flex',
     flow: 'column',
-    padding: '4x',
-    gap: '2x',
-    fill: 'okhsl(98% 0.02 255)',
-    color: 'okhsl(28% 0.03 255)',
-    border: '1bw solid okhsl(88% 0.02 255)',
-    radius: '1r',
+    padding: '24px',
+    gap: '12px',
+    fill: 'white',
+    color: '#222',
+    border: '1px solid #ddd',
+    radius: '12px',
   },
 });
 
@@ -95,7 +108,9 @@ const Card = tasty({
 <Card>Hello World</Card>
 ```
 
-Every value maps to CSS you'd recognize. This example is intentionally config-free: built-in units work immediately, and standard color values such as `rgb(...)`, `hsl(...)`, named colors, and `okhsl(...)` are all valid without setup. `okhsl(...)` is the recommended choice when you want a design-system-friendly color authoring path from day one.
+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,28 @@ 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
-
-With `styleProps`, a component can expose the styles you choose as normal typed props. That means you can adjust layout, spacing, alignment, or positioning right where the component is used, instead of introducing wrapper elements or reaching for a separate styling API.
-
-This is especially good for prototyping and fast UI iteration: you can shape interfaces quickly, while still staying inside a typed, design-system-aware component API that scales to production.
-
-```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>
+  <Button isLoading size="large" placeSelf="end">Submit</Button>
 </Space>
 ```
 
-The same props also support state maps, so responsive values use the exact same API:
+See [Style Props](#style-props) and [Mod Props](#mod-props) below, or the full reference in [Runtime API](docs/runtime.md#style-props).
 
-```tsx
-<Space
-  flow={{ '': 'column', '@tablet': 'row' }}
-  gap={{ '': '2x', '@tablet': '4x' }}
->
-  <Sidebar />
-  <Content />
-</Space>
-```
+## Choose a Styling Approach
+
+Once you understand the component model, pick the rendering mode that matches your app.
+
+| 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 |
 
-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()`.
+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).
 
 ## How It Actually Works
 
@@ -222,7 +207,7 @@ 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)**.
 
-Traditional CSS has two structural problems.
+### The structural problem with normal CSS
 
 First, the **cascade** resolves conflicts by specificity and source order: when multiple selectors match, the one with the highest specificity wins, or — if specificity is equal — the last one in source order wins. That makes styles inherently fragile. Reordering imports, adding a media query, or composing components from different libraries can silently break styling.
 
@@ -235,7 +220,11 @@ A small example makes this tangible. Two rules for a button's background:
 
 Both selectors have specificity `(0, 1, 1)`. When the button is hovered **and** disabled, both match — and the last rule in source order wins. Swap the two lines and a hovered disabled button silently turns blue instead of gray. This class of bug is invisible in code review because the logic is correct; only the ordering is wrong.
 
-Second, **authoring selectors that capture real-world state logic is fundamentally hard.** A single state like "dark mode" may depend on a root attribute, an OS preference, or both — each branch needing its own selector, proper negation of competing branches, and correct `@media` nesting. The example below shows the CSS you'd write by hand for just *one* property with *one* state. Scale that across dozens of properties, then add breakpoints and container queries, and the selector logic quickly becomes unmanageable.
+### Why real state logic is hard to author by hand
+
+Authoring selectors that capture real-world state logic is fundamentally hard. A single state like "dark mode" may depend on a root attribute, an OS preference, or both — each branch needing its own selector, proper negation of competing branches, and correct `@media` nesting. The example below shows the CSS you'd write by hand for just *one* property with *one* state. Scale that across dozens of properties, then add breakpoints and container queries, and the selector logic quickly becomes unmanageable.
+
+### What Tasty generates instead
 
 Tasty solves both problems at once: **every state mapping compiles into mutually exclusive selectors.**
 
@@ -280,8 +269,6 @@ Better — but the bare `.t0` default still matches unconditionally. It matches
 
 This is just *one* property with *one* state, and getting it right already takes multiple iterations. The correct selectors require negating every other branch — which is exactly what Tasty generates automatically:
 
-Tasty generates the correct version automatically:
-
 ```css
 /* Branch 1: Explicit dark schema */
 :root[data-schema="dark"] .t0.t0 {
@@ -308,11 +295,13 @@ Tasty generates the correct version automatically:
 }
 ```
 
+### What guarantee that gives you
+
 Every rule is guarded by the negation of higher-priority rules. No two rules can match at the same time. No specificity arithmetic. No source-order dependence. Components compose and extend without collisions.
 
-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 doesn't limit CSS; it unlocks its full potential by removing the complexity that held teams back.
+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
 
@@ -370,214 +359,99 @@ 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' },
-});
+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.
 
-<Card>
-  <Card.Title>Heading</Card.Title>
-  <Card.Content>Body text</Card.Content>
-</Card>
-```
+See [Runtime API - Sub-element Styling](docs/runtime.md#sub-element-styling), [Style DSL - Advanced States](docs/dsl.md#advanced-states--prefix), and [Methodology](docs/methodology.md#component-architecture-root--sub-elements).
 
-Sub-elements use `data-element` attributes — no extra class names, no naming conventions.
+### Style Props
 
-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.
+`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.
 
-Use `@own(...)` when a sub-element should react to its own state instead of the root state context.
+```tsx
+const Space = tasty({
+  styles: { display: 'flex', flow: 'column', gap: '1x' },
+  styleProps: FLOW_STYLES,
+});
 
-Class selectors are also supported, but modifiers/pseudo-classes are usually the better default in design-system code.
+<Space flow="row" gap={{ '': '2x', '@tablet': '4x' }}>
+```
 
-Use the sub-element selector `$` when you need precise descendant targeting to avoid leakage in deeply nested component trees.
+See [Runtime API - Style Props](docs/runtime.md#style-props) and [Methodology - styleProps](docs/methodology.md#styleprops-as-the-public-api).
 
-### Variants
+### Mod Props
 
-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.
+`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.
 
 ```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' },
+  as: 'button',
+  modProps: { isLoading: Boolean, size: ['sm', 'md', 'lg'] as const },
+  styles: {
+    fill: { '': '#primary', isLoading: '#primary.5' },
+    padding: { '': '2x 4x', 'size=sm': '1x 2x' },
   },
 });
 
-<Button variant="danger">Delete</Button>
+<Button isLoading size="lg">Submit</Button>
 ```
 
-### Recipes
+See [Runtime API - Mod Props](docs/runtime.md#mod-props) and [Methodology - modProps](docs/methodology.md#modprops-and-mods).
 
-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.
+### Variants
 
-```tsx
-configure({
-  recipes: {
-    card: { padding: '4x', fill: '#surface', radius: '1r', border: true },
-    elevated: { shadow: '0 2x 4x #shadow' },
-  },
-});
+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.
 
-const ProfileCard = tasty({
-  styles: {
-    recipe: 'card elevated',
-    color: '#text',
-  },
-});
-```
+See [Runtime API - Variants](docs/runtime.md#variants).
 
-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'`.
+### Recipes
 
-### Auto-Inferred `@property`
+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.
 
-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>`.
+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.
 
-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:
+See [Style DSL - Recipes](docs/dsl.md#recipes) and [Configuration - recipes](docs/configuration.md#recipes).
 
-```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 },
-      },
-    },
-  },
-});
-```
+### Auto-Inferred `@property`
+
+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.
 
-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.
+If you prefer explicit control, disable inference with `configure({ autoPropertyTypes: false })` or declare the properties yourself.
 
-If you prefer full manual control, disable auto-inference globally with `configure({ autoPropertyTypes: false })`.
+See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
 ### Explicit `@properties`
 
-Declare `@properties` yourself only when you need to override the defaults, for example to set `inherits: false` or provide a custom `initialValue`:
+Use explicit `@properties` only when you need to override defaults such as `inherits: false` or a custom `initialValue`.
 
-```tsx
-'@properties': {
-  '$pulse-scale': { syntax: '<number>', inherits: false, initialValue: 1 },
-},
-```
+See [Style DSL - Properties (`@property`)](docs/dsl.md#properties-property).
 
 ### React Hooks
 
-For cases where you don't need a full component:
-
-```tsx
-import { useStyles, useGlobalStyles, useRawCSS } from '@tenphi/tasty';
+When you do not need a full component wrapper, use the hooks directly: `useStyles` for local class names, `useGlobalStyles` for selector-scoped global CSS, `useRawCSS` for raw rules, plus `useKeyframes` and `useProperty` for animation and custom-property primitives.
 
-function App() {
-  const { className } = useStyles({ padding: '2x', fill: '#surface' });
-  useGlobalStyles('body', { margin: '0' });
-  useRawCSS('@font-face { font-family: "Custom"; src: url(...); }');
-
-  return <main className={className}>...</main>;
-}
-```
+See [Runtime API - Hooks](docs/runtime.md#hooks).
 
 ### Zero-Runtime Mode
 
-Extract all CSS at build time. Zero JavaScript overhead in production:
-
-```tsx
-import { tastyStatic } from '@tenphi/tasty/static';
-
-const card = tastyStatic({
-  padding: '4x',
-  fill: '#surface',
-  radius: '1r',
-  color: { '': '#text', '@dark': '#text-on-dark' },
-});
-
-// card is a CSS class name string
-<div className={card}>Static styles, zero runtime</div>
-```
-
-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, design systems | Static sites, SSG, landing pages |
+`tasty()` returns React components and injects CSS on demand at runtime. `tastyStatic()` returns class names and extracts CSS during the build. Both share the same DSL, tokens, units, state mappings, and recipes, so the main choice is runtime flexibility versus build-time extraction.
 
-Both share the same DSL, tokens, units, state mappings, and recipes.
+See [Zero Runtime (tastyStatic)](docs/tasty-static.md), [Runtime API](docs/runtime.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:**
-
-```tsx
-// app/tasty-registry.tsx
-'use client';
-
-import { TastyRegistry } from '@tenphi/tasty/ssr/next';
+SSR layers on top of runtime `tasty()` rather than introducing a separate styling model. Existing components stay unchanged while Tasty collects CSS during server rendering and hydrates the cache on the client.
 
-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>
-  );
-}
-```
+Use `@tenphi/tasty/ssr/next` for Next.js App Router, `@tenphi/tasty/ssr/astro` for Astro, or 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
 
@@ -714,9 +588,9 @@ Open-source React UI kit built on Tasty + React Aria. 100+ production components
 
 ## Documentation
 
-Start from the docs hub if you want the shortest path to the right guide for your role or rendering mode.
+Start from the docs hub if you want the shortest path to the right guide for your role or styling approach.
 
-- **[Docs Hub](docs/README.md)** — audience-based navigation across onboarding, design-system authoring, runtime, zero-runtime, SSR, debugging, and internals
+- **[Docs Hub](docs/README.md)** — audience-based navigation across onboarding, design-system authoring, runtime, zero-runtime, runtime SSR integration, debugging, and internals
 
 ### Start here
 

package/dist/_virtual/_rolldown/runtime.js

@@ -3,6 +3,5 @@ var __require = /* @__PURE__ */ ((x) => typeof require !== "undefined" ? require
 	if (typeof require !== "undefined") return require.apply(this, arguments);
 	throw Error("Calling `require` for \"" + x + "\" in an environment that doesn't expose the `require` function. See https://rolldown.rs/in-depth/bundling-cjs#require-external-modules for more details.");
 });
-
 //#endregion
-export { __require };
+export { __require };

package/dist/chunks/cacheKey.d.ts

@@ -0,0 +1 @@
+export { };

package/dist/chunks/cacheKey.js

@@ -1,5 +1,4 @@
 import { extractLocalPredefinedStates, extractPredefinedStateRefs } from "../states/index.js";
-
 //#region src/chunks/cacheKey.ts
 /**
 * Chunk-specific cache key generation.
@@ -72,7 +71,7 @@ function generateChunkCacheKey(styles, chunkName, styleKeys) {
 	}
 	return parts.join("\0");
 }
-
 //#endregion
 export { generateChunkCacheKey };
+
 //# sourceMappingURL=cacheKey.js.map

package/dist/chunks/cacheKey.js.map

@@ -1 +1 @@
-{"version":3,"file":"cacheKey.js","names":[],"sources":["../../src/chunks/cacheKey.ts"],"sourcesContent":["/**\n * Chunk-specific cache key generation.\n *\n * Generates cache keys that only include styles relevant to a specific chunk,\n * enabling more granular caching and reuse.\n *\n * Enhanced to support predefined states:\n * - Global predefined states don't affect cache keys (constant across app)\n * - Local predefined states only affect cache keys if referenced in the chunk\n */\n\nimport {\n  extractLocalPredefinedStates,\n  extractPredefinedStateRefs,\n} from '../states';\nimport type { Styles } from '../styles/types';\n\nconst _stableStringifyCache = new WeakMap<object, string>();\n\n/**\n * Recursively serialize a value with sorted keys for stable output.\n * This ensures that {a: 1, b: 2} and {b: 2, a: 1} produce the same string.\n * Uses a WeakMap cache for object values to avoid re-serializing the same references.\n */\nfunction stableStringify(value: unknown): string {\n  if (value === null) {\n    return 'null';\n  }\n  if (value === undefined) {\n    return 'undefined';\n  }\n  if (typeof value !== 'object') {\n    return JSON.stringify(value);\n  }\n\n  const cached = _stableStringifyCache.get(value as object);\n  if (cached !== undefined) return cached;\n\n  let result: string;\n  if (Array.isArray(value)) {\n    result = '[' + value.map(stableStringify).join(',') + ']';\n  } else {\n    const obj = value as Record<string, unknown>;\n    const sortedKeys = Object.keys(obj).sort();\n    const parts: string[] = [];\n    for (const key of sortedKeys) {\n      if (obj[key] !== undefined) {\n        parts.push(`${JSON.stringify(key)}:${stableStringify(obj[key])}`);\n      }\n    }\n    result = '{' + parts.join(',') + '}';\n  }\n\n  _stableStringifyCache.set(value as object, result);\n  return result;\n}\n\n/**\n * Generate a cache key for a specific chunk.\n *\n * Only includes the styles that belong to this chunk, allowing\n * chunks to be cached independently.\n *\n * Also includes relevant local predefined states that are referenced\n * by this chunk's styles.\n *\n * @param styles - The full styles object\n * @param chunkName - Name of the chunk\n * @param styleKeys - Keys of styles belonging to this chunk\n * @returns A stable cache key string\n */\nexport function generateChunkCacheKey(\n  styles: Styles,\n  chunkName: string,\n  styleKeys: string[],\n): string {\n  // Start with chunk name for namespace separation\n  const parts: string[] = [chunkName];\n\n  // styleKeys are already sorted by categorizeStyleKeys\n  let chunkStylesStr = '';\n\n  for (const key of styleKeys) {\n    const value = styles[key];\n    if (value !== undefined) {\n      // Use stable stringify for consistent serialization regardless of key order\n      const serialized = stableStringify(value);\n      parts.push(`${key}:${serialized}`);\n      chunkStylesStr += serialized;\n    }\n  }\n\n  // Extract local predefined states from the full styles object\n  const localStates = extractLocalPredefinedStates(styles);\n\n  // Only include local predefined states that are actually referenced in this chunk\n  if (Object.keys(localStates).length > 0) {\n    const referencedStates = extractPredefinedStateRefs(chunkStylesStr);\n    const relevantLocalStates: string[] = [];\n\n    for (const stateName of referencedStates) {\n      if (localStates[stateName]) {\n        relevantLocalStates.push(`${stateName}=${localStates[stateName]}`);\n      }\n    }\n\n    // Add relevant local states to the cache key (sorted for stability)\n    if (relevantLocalStates.length > 0) {\n      relevantLocalStates.sort();\n      parts.unshift(`[states:${relevantLocalStates.join('|')}]`);\n    }\n  }\n\n  // Use null character as separator (safe, not in JSON output)\n  return parts.join('\\0');\n}\n"],"mappings":";;;;;;;;;;;;;AAiBA,MAAM,wCAAwB,IAAI,SAAyB;;;;;;AAO3D,SAAS,gBAAgB,OAAwB;AAC/C,KAAI,UAAU,KACZ,QAAO;AAET,KAAI,UAAU,OACZ,QAAO;AAET,KAAI,OAAO,UAAU,SACnB,QAAO,KAAK,UAAU,MAAM;CAG9B,MAAM,SAAS,sBAAsB,IAAI,MAAgB;AACzD,KAAI,WAAW,OAAW,QAAO;CAEjC,IAAI;AACJ,KAAI,MAAM,QAAQ,MAAM,CACtB,UAAS,MAAM,MAAM,IAAI,gBAAgB,CAAC,KAAK,IAAI,GAAG;MACjD;EACL,MAAM,MAAM;EACZ,MAAM,aAAa,OAAO,KAAK,IAAI,CAAC,MAAM;EAC1C,MAAM,QAAkB,EAAE;AAC1B,OAAK,MAAM,OAAO,WAChB,KAAI,IAAI,SAAS,OACf,OAAM,KAAK,GAAG,KAAK,UAAU,IAAI,CAAC,GAAG,gBAAgB,IAAI,KAAK,GAAG;AAGrE,WAAS,MAAM,MAAM,KAAK,IAAI,GAAG;;AAGnC,uBAAsB,IAAI,OAAiB,OAAO;AAClD,QAAO;;;;;;;;;;;;;;;;AAiBT,SAAgB,sBACd,QACA,WACA,WACQ;CAER,MAAM,QAAkB,CAAC,UAAU;CAGnC,IAAI,iBAAiB;AAErB,MAAK,MAAM,OAAO,WAAW;EAC3B,MAAM,QAAQ,OAAO;AACrB,MAAI,UAAU,QAAW;GAEvB,MAAM,aAAa,gBAAgB,MAAM;AACzC,SAAM,KAAK,GAAG,IAAI,GAAG,aAAa;AAClC,qBAAkB;;;CAKtB,MAAM,cAAc,6BAA6B,OAAO;AAGxD,KAAI,OAAO,KAAK,YAAY,CAAC,SAAS,GAAG;EACvC,MAAM,mBAAmB,2BAA2B,eAAe;EACnE,MAAM,sBAAgC,EAAE;AAExC,OAAK,MAAM,aAAa,iBACtB,KAAI,YAAY,WACd,qBAAoB,KAAK,GAAG,UAAU,GAAG,YAAY,aAAa;AAKtE,MAAI,oBAAoB,SAAS,GAAG;AAClC,uBAAoB,MAAM;AAC1B,SAAM,QAAQ,WAAW,oBAAoB,KAAK,IAAI,CAAC,GAAG;;;AAK9D,QAAO,MAAM,KAAK,KAAK"}
+{"version":3,"file":"cacheKey.js","names":[],"sources":["../../src/chunks/cacheKey.ts"],"sourcesContent":["/**\n * Chunk-specific cache key generation.\n *\n * Generates cache keys that only include styles relevant to a specific chunk,\n * enabling more granular caching and reuse.\n *\n * Enhanced to support predefined states:\n * - Global predefined states don't affect cache keys (constant across app)\n * - Local predefined states only affect cache keys if referenced in the chunk\n */\n\nimport {\n  extractLocalPredefinedStates,\n  extractPredefinedStateRefs,\n} from '../states';\nimport type { Styles } from '../styles/types';\n\nconst _stableStringifyCache = new WeakMap<object, string>();\n\n/**\n * Recursively serialize a value with sorted keys for stable output.\n * This ensures that {a: 1, b: 2} and {b: 2, a: 1} produce the same string.\n * Uses a WeakMap cache for object values to avoid re-serializing the same references.\n */\nfunction stableStringify(value: unknown): string {\n  if (value === null) {\n    return 'null';\n  }\n  if (value === undefined) {\n    return 'undefined';\n  }\n  if (typeof value !== 'object') {\n    return JSON.stringify(value);\n  }\n\n  const cached = _stableStringifyCache.get(value as object);\n  if (cached !== undefined) return cached;\n\n  let result: string;\n  if (Array.isArray(value)) {\n    result = '[' + value.map(stableStringify).join(',') + ']';\n  } else {\n    const obj = value as Record<string, unknown>;\n    const sortedKeys = Object.keys(obj).sort();\n    const parts: string[] = [];\n    for (const key of sortedKeys) {\n      if (obj[key] !== undefined) {\n        parts.push(`${JSON.stringify(key)}:${stableStringify(obj[key])}`);\n      }\n    }\n    result = '{' + parts.join(',') + '}';\n  }\n\n  _stableStringifyCache.set(value as object, result);\n  return result;\n}\n\n/**\n * Generate a cache key for a specific chunk.\n *\n * Only includes the styles that belong to this chunk, allowing\n * chunks to be cached independently.\n *\n * Also includes relevant local predefined states that are referenced\n * by this chunk's styles.\n *\n * @param styles - The full styles object\n * @param chunkName - Name of the chunk\n * @param styleKeys - Keys of styles belonging to this chunk\n * @returns A stable cache key string\n */\nexport function generateChunkCacheKey(\n  styles: Styles,\n  chunkName: string,\n  styleKeys: string[],\n): string {\n  // Start with chunk name for namespace separation\n  const parts: string[] = [chunkName];\n\n  // styleKeys are already sorted by categorizeStyleKeys\n  let chunkStylesStr = '';\n\n  for (const key of styleKeys) {\n    const value = styles[key];\n    if (value !== undefined) {\n      // Use stable stringify for consistent serialization regardless of key order\n      const serialized = stableStringify(value);\n      parts.push(`${key}:${serialized}`);\n      chunkStylesStr += serialized;\n    }\n  }\n\n  // Extract local predefined states from the full styles object\n  const localStates = extractLocalPredefinedStates(styles);\n\n  // Only include local predefined states that are actually referenced in this chunk\n  if (Object.keys(localStates).length > 0) {\n    const referencedStates = extractPredefinedStateRefs(chunkStylesStr);\n    const relevantLocalStates: string[] = [];\n\n    for (const stateName of referencedStates) {\n      if (localStates[stateName]) {\n        relevantLocalStates.push(`${stateName}=${localStates[stateName]}`);\n      }\n    }\n\n    // Add relevant local states to the cache key (sorted for stability)\n    if (relevantLocalStates.length > 0) {\n      relevantLocalStates.sort();\n      parts.unshift(`[states:${relevantLocalStates.join('|')}]`);\n    }\n  }\n\n  // Use null character as separator (safe, not in JSON output)\n  return parts.join('\\0');\n}\n"],"mappings":";;;;;;;;;;;;AAiBA,MAAM,wCAAwB,IAAI,SAAyB;;;;;;AAO3D,SAAS,gBAAgB,OAAwB;AAC/C,KAAI,UAAU,KACZ,QAAO;AAET,KAAI,UAAU,KAAA,EACZ,QAAO;AAET,KAAI,OAAO,UAAU,SACnB,QAAO,KAAK,UAAU,MAAM;CAG9B,MAAM,SAAS,sBAAsB,IAAI,MAAgB;AACzD,KAAI,WAAW,KAAA,EAAW,QAAO;CAEjC,IAAI;AACJ,KAAI,MAAM,QAAQ,MAAM,CACtB,UAAS,MAAM,MAAM,IAAI,gBAAgB,CAAC,KAAK,IAAI,GAAG;MACjD;EACL,MAAM,MAAM;EACZ,MAAM,aAAa,OAAO,KAAK,IAAI,CAAC,MAAM;EAC1C,MAAM,QAAkB,EAAE;AAC1B,OAAK,MAAM,OAAO,WAChB,KAAI,IAAI,SAAS,KAAA,EACf,OAAM,KAAK,GAAG,KAAK,UAAU,IAAI,CAAC,GAAG,gBAAgB,IAAI,KAAK,GAAG;AAGrE,WAAS,MAAM,MAAM,KAAK,IAAI,GAAG;;AAGnC,uBAAsB,IAAI,OAAiB,OAAO;AAClD,QAAO;;;;;;;;;;;;;;;;AAiBT,SAAgB,sBACd,QACA,WACA,WACQ;CAER,MAAM,QAAkB,CAAC,UAAU;CAGnC,IAAI,iBAAiB;AAErB,MAAK,MAAM,OAAO,WAAW;EAC3B,MAAM,QAAQ,OAAO;AACrB,MAAI,UAAU,KAAA,GAAW;GAEvB,MAAM,aAAa,gBAAgB,MAAM;AACzC,SAAM,KAAK,GAAG,IAAI,GAAG,aAAa;AAClC,qBAAkB;;;CAKtB,MAAM,cAAc,6BAA6B,OAAO;AAGxD,KAAI,OAAO,KAAK,YAAY,CAAC,SAAS,GAAG;EACvC,MAAM,mBAAmB,2BAA2B,eAAe;EACnE,MAAM,sBAAgC,EAAE;AAExC,OAAK,MAAM,aAAa,iBACtB,KAAI,YAAY,WACd,qBAAoB,KAAK,GAAG,UAAU,GAAG,YAAY,aAAa;AAKtE,MAAI,oBAAoB,SAAS,GAAG;AAClC,uBAAoB,MAAM;AAC1B,SAAM,QAAQ,WAAW,oBAAoB,KAAK,IAAI,CAAC,GAAG;;;AAK9D,QAAO,MAAM,KAAK,KAAK"}

package/dist/chunks/definitions.d.ts

@@ -1,6 +1,6 @@
 //#region src/chunks/definitions.d.ts
 declare const CHUNK_NAMES: {
-  /** Special chunk for styles that cannot be split (e.g., @starting-style) */readonly COMBINED: "combined";
+  /** Special chunk for styles that cannot be split */readonly COMBINED: "combined";
   readonly SUBCOMPONENTS: "subcomponents";
   readonly APPEARANCE: "appearance";
   readonly FONT: "font";

package/dist/chunks/definitions.js

@@ -1,5 +1,4 @@
 import { isSelector } from "../pipeline/index.js";
-
 //#region src/chunks/definitions.ts
 /**
 * Style chunk definitions for CSS chunking optimization.
@@ -238,7 +237,7 @@ function categorizeStyleKeys(styles) {
 	const chunkData = {};
 	const keys = Object.keys(styles);
 	for (const key of keys) {
-		if (key === "$" || key === "@keyframes" || key === "@properties" || key === "recipe") continue;
+		if (key === "$" || key === "@keyframes" || key === "@properties" || key === "@fontFace" || key === "@counterStyle" || key === "recipe") continue;
 		if (isSelector(key)) {
 			if (!chunkData[CHUNK_NAMES.SUBCOMPONENTS]) chunkData[CHUNK_NAMES.SUBCOMPONENTS] = [];
 			chunkData[CHUNK_NAMES.SUBCOMPONENTS].push(key);
@@ -253,7 +252,7 @@ function categorizeStyleKeys(styles) {
 	for (const chunkName of Object.keys(chunkData)) if (!orderedChunks.has(chunkName)) orderedChunks.set(chunkName, chunkData[chunkName].sort());
 	return orderedChunks;
 }
-
 //#endregion
 export { CHUNK_NAMES, STYLE_TO_CHUNK, categorizeStyleKeys };
+
 //# sourceMappingURL=definitions.js.map