@tenphi/tasty 0.0.0-snapshot.056b911

package/dist/zero/next.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"next.js","names":[],"sources":["../../src/zero/next.ts"],"sourcesContent":["/**\n * Next.js configuration wrapper for tasty-zero.\n *\n * Supports both webpack and Turbopack bundlers:\n * - **webpack**: Injects a babel-loader rule with the tasty-zero Babel plugin\n *   via `webpack()` config hook. Config is passed as a jiti factory function.\n * - **Turbopack**: Adds a `turbopack.rules` entry with babel-loader and\n *   JSON-serializable options (`configFile` path instead of a function).\n *   The Babel plugin loads the config internally via jiti.\n *\n * The generated CSS is injected automatically — `@tenphi/tasty/static`\n * imports are replaced with an import of the output CSS file at build time.\n * No manual CSS import in layout files is needed.\n *\n * @example\n * ```javascript\n * // next.config.js\n * const { withTastyZero } = require('@tenphi/tasty/next');\n *\n * module.exports = withTastyZero({\n *   output: 'public/tasty.css',\n *   configFile: './app/tasty-zero.config.ts',\n * })({\n *   // your Next.js config\n * });\n * ```\n */\n\nimport { createRequire } from 'module';\nimport * as path from 'path';\nimport { fileURLToPath } from 'url';\n\nimport { createJiti } from 'jiti';\n\nimport type { TastyZeroBabelOptions, TastyZeroConfig } from './babel';\n\nconst __filename = fileURLToPath(import.meta.url);\nconst __dirname = path.dirname(__filename);\n\n// Next.js types (inline to avoid requiring next as a dependency)\ninterface WebpackConfigContext {\n  isServer: boolean;\n  dev: boolean;\n  buildId: string;\n  dir: string;\n}\n\n/* eslint-disable @typescript-eslint/no-explicit-any -- webpack/Next.js config types are complex */\ninterface TurbopackLoaderItem {\n  loader: string;\n  options?: Record<string, unknown>;\n}\n\ninterface TurbopackRuleConfig {\n  loaders: (string | TurbopackLoaderItem)[];\n  as?: string;\n  condition?: unknown;\n}\n\ninterface TurbopackConfig {\n  rules?: Record<string, TurbopackRuleConfig | TurbopackRuleConfig[]>;\n  [key: string]: unknown;\n}\n\ninterface NextConfig {\n  webpack?: (config: any, context: WebpackConfigContext) => any;\n  turbopack?: TurbopackConfig;\n  [key: string]: unknown;\n}\n\nexport interface TastyZeroNextOptions {\n  /**\n   * Output path for CSS relative to project root.\n   * @default 'public/tasty.css'\n   */\n  output?: string;\n\n  /**\n   * Whether to enable the plugin.\n   * @default true\n   */\n  enabled?: boolean;\n\n  /**\n   * Tasty configuration for build-time processing.\n   * For static configs that don't change during dev.\n   *\n   * For configs that depend on theme files, use `configFile` instead.\n   */\n  config?: TastyZeroConfig;\n\n  /**\n   * Path to a TypeScript/JavaScript module that exports the tasty zero config\n   * as its default export. The module is re-evaluated on each\n   * compilation, enabling hot reload when the file (or its imports) change.\n   *\n   * @example './app/tasty-zero.config.ts'\n   */\n  configFile?: string;\n\n  /**\n   * Extra file paths (relative to project root) that the config depends on.\n   * When any of these files change, the Babel cache is invalidated and\n   * the config is re-evaluated.\n   *\n   * The `configFile` itself is always tracked automatically.\n   * Use this for transitive dependencies that aren't directly imported\n   * by the config file, or when using `config` instead of `configFile`.\n   *\n   * @example ['./app/theme.ts']\n   */\n  configDeps?: string[];\n\n  /**\n   * Output mode for extracted CSS.\n   *\n   * - `'file'` (default): CSS is written to a single output file.\n   * - `'inject'`: CSS is embedded inline in JS and injected at runtime.\n   *   No CSS file is written. Best for reusable components and extensions.\n   *\n   * When `mode` is `'inject'`, `output` is ignored.\n   *\n   * @default 'file'\n   */\n  mode?: 'file' | 'inject';\n}\n\n/**\n * Next.js configuration wrapper for tasty-zero.\n * Configures both webpack and Turbopack bundlers automatically.\n */\nexport function withTastyZero(options: TastyZeroNextOptions = {}) {\n  const {\n    output = 'public/tasty.css',\n    enabled = true,\n    config: tastyConfig,\n    configFile,\n    configDeps = [],\n    mode,\n  } = options;\n\n  return (nextConfig: NextConfig = {}): NextConfig => {\n    if (!enabled) {\n      return nextConfig;\n    }\n\n    const projectDir = process.cwd();\n    const absoluteOutput = path.resolve(projectDir, output);\n    const babelPluginPath = path.resolve(__dirname, 'babel.js');\n\n    const absoluteConfigFile = configFile\n      ? path.resolve(projectDir, configFile)\n      : undefined;\n\n    const allDeps = [\n      ...(absoluteConfigFile ? [absoluteConfigFile] : []),\n      ...configDeps.map((dep) => path.resolve(projectDir, dep)),\n    ];\n\n    // --- Turbopack configuration ---\n    // Turbopack loader options must be JSON-serializable (no functions).\n    // The Babel plugin loads config internally via `configFile` path + jiti.\n    const turbopackBabelOptions: Record<string, unknown> = {\n      babelrc: false,\n      configFile: false,\n      parserOpts: {\n        plugins: ['typescript', 'jsx', 'decorators-legacy'],\n      },\n      plugins: [\n        [\n          babelPluginPath,\n          {\n            output: absoluteOutput,\n            injectImport: true,\n            ...(mode ? { mode } : {}),\n            ...(absoluteConfigFile\n              ? { configFile: absoluteConfigFile }\n              : tastyConfig\n                ? { config: tastyConfig }\n                : {}),\n            ...(allDeps.length > 0 ? { configDeps: allDeps } : {}),\n          },\n        ],\n      ],\n    };\n\n    const existingTurbopack = nextConfig.turbopack || {};\n    const existingRules = existingTurbopack.rules || {};\n\n    const existingExperimental =\n      (nextConfig.experimental as Record<string, unknown>) || {};\n\n    return {\n      ...nextConfig,\n\n      experimental: {\n        ...existingExperimental,\n        turbopackUseBuiltinBabel: true,\n      },\n\n      turbopack: {\n        ...existingTurbopack,\n        rules: {\n          ...existingRules,\n          '*.{ts,tsx,js,jsx}': {\n            condition: { not: 'foreign' },\n            loaders: [\n              {\n                loader: 'babel-loader',\n                options: turbopackBabelOptions,\n              },\n            ],\n          },\n        },\n      },\n\n      webpack(config: any, context: WebpackConfigContext) {\n        const { dir } = context;\n\n        const wpProjectDir = dir || projectDir;\n        const wpAbsoluteOutput = path.resolve(wpProjectDir, output);\n        const projectRequire = createRequire(\n          path.resolve(wpProjectDir, 'package.json'),\n        );\n\n        const wpAbsoluteConfigFile = configFile\n          ? path.resolve(wpProjectDir, configFile)\n          : undefined;\n\n        const wpAllDeps = [\n          ...(wpAbsoluteConfigFile ? [wpAbsoluteConfigFile] : []),\n          ...configDeps.map((dep) => path.resolve(wpProjectDir, dep)),\n        ];\n\n        const babelPluginOptions: TastyZeroBabelOptions = {\n          output: wpAbsoluteOutput,\n          injectImport: true,\n          ...(mode ? { mode } : {}),\n        };\n\n        if (wpAbsoluteConfigFile) {\n          const jiti = createJiti(wpProjectDir, {\n            moduleCache: false,\n          });\n\n          babelPluginOptions.config = () => {\n            return jiti(wpAbsoluteConfigFile) as TastyZeroConfig;\n          };\n        } else if (tastyConfig) {\n          babelPluginOptions.config = tastyConfig;\n        }\n\n        if (wpAllDeps.length > 0) {\n          babelPluginOptions.configDeps = wpAllDeps;\n        }\n\n        const babelPluginConfig = [babelPluginPath, babelPluginOptions];\n\n        const existingRule = config.module?.rules?.find(\n          (rule: any) =>\n            rule.use?.loader === 'babel-loader' ||\n            rule.use?.some?.((u: any) => u.loader === 'babel-loader'),\n        );\n\n        if (existingRule) {\n          const babelUse = Array.isArray(existingRule.use)\n            ? existingRule.use.find((u: any) => u.loader === 'babel-loader')\n            : existingRule.use;\n\n          if (babelUse?.options) {\n            babelUse.options.plugins = babelUse.options.plugins || [];\n            babelUse.options.plugins.push(babelPluginConfig);\n          }\n        } else {\n          config.module = config.module || {};\n          config.module.rules = config.module.rules || [];\n          config.module.rules.push({\n            test: /\\.(tsx?|jsx?)$/,\n            exclude: /node_modules/,\n            use: [\n              {\n                loader: projectRequire.resolve('babel-loader'),\n                options: {\n                  babelrc: false,\n                  configFile: false,\n                  parserOpts: {\n                    plugins: ['typescript', 'jsx', 'decorators-legacy'],\n                  },\n                  plugins: [babelPluginConfig],\n                },\n              },\n            ],\n          });\n        }\n\n        if (typeof nextConfig.webpack === 'function') {\n          return nextConfig.webpack(config, context);\n        }\n\n        return config;\n      },\n    };\n  };\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAoCA,MAAM,aAAa,cAAc,OAAO,KAAK,IAAI;AACjD,MAAM,YAAY,KAAK,QAAQ,WAAW;;;;;AA8F1C,SAAgB,cAAc,UAAgC,EAAE,EAAE;CAChE,MAAM,EACJ,SAAS,oBACT,UAAU,MACV,QAAQ,aACR,YACA,aAAa,EAAE,EACf,SACE;AAEJ,SAAQ,aAAyB,EAAE,KAAiB;AAClD,MAAI,CAAC,QACH,QAAO;EAGT,MAAM,aAAa,QAAQ,KAAK;EAChC,MAAM,iBAAiB,KAAK,QAAQ,YAAY,OAAO;EACvD,MAAM,kBAAkB,KAAK,QAAQ,WAAW,WAAW;EAE3D,MAAM,qBAAqB,aACvB,KAAK,QAAQ,YAAY,WAAW,GACpC,KAAA;EAEJ,MAAM,UAAU,CACd,GAAI,qBAAqB,CAAC,mBAAmB,GAAG,EAAE,EAClD,GAAG,WAAW,KAAK,QAAQ,KAAK,QAAQ,YAAY,IAAI,CAAC,CAC1D;EAKD,MAAM,wBAAiD;GACrD,SAAS;GACT,YAAY;GACZ,YAAY,EACV,SAAS;IAAC;IAAc;IAAO;IAAoB,EACpD;GACD,SAAS,CACP,CACE,iBACA;IACE,QAAQ;IACR,cAAc;IACd,GAAI,OAAO,EAAE,MAAM,GAAG,EAAE;IACxB,GAAI,qBACA,EAAE,YAAY,oBAAoB,GAClC,cACE,EAAE,QAAQ,aAAa,GACvB,EAAE;IACR,GAAI,QAAQ,SAAS,IAAI,EAAE,YAAY,SAAS,GAAG,EAAE;IACtD,CACF,CACF;GACF;EAED,MAAM,oBAAoB,WAAW,aAAa,EAAE;EACpD,MAAM,gBAAgB,kBAAkB,SAAS,EAAE;EAEnD,MAAM,uBACH,WAAW,gBAA4C,EAAE;AAE5D,SAAO;GACL,GAAG;GAEH,cAAc;IACZ,GAAG;IACH,0BAA0B;IAC3B;GAED,WAAW;IACT,GAAG;IACH,OAAO;KACL,GAAG;KACH,qBAAqB;MACnB,WAAW,EAAE,KAAK,WAAW;MAC7B,SAAS,CACP;OACE,QAAQ;OACR,SAAS;OACV,CACF;MACF;KACF;IACF;GAED,QAAQ,QAAa,SAA+B;IAClD,MAAM,EAAE,QAAQ;IAEhB,MAAM,eAAe,OAAO;IAC5B,MAAM,mBAAmB,KAAK,QAAQ,cAAc,OAAO;IAC3D,MAAM,iBAAiB,cACrB,KAAK,QAAQ,cAAc,eAAe,CAC3C;IAED,MAAM,uBAAuB,aACzB,KAAK,QAAQ,cAAc,WAAW,GACtC,KAAA;IAEJ,MAAM,YAAY,CAChB,GAAI,uBAAuB,CAAC,qBAAqB,GAAG,EAAE,EACtD,GAAG,WAAW,KAAK,QAAQ,KAAK,QAAQ,cAAc,IAAI,CAAC,CAC5D;IAED,MAAM,qBAA4C;KAChD,QAAQ;KACR,cAAc;KACd,GAAI,OAAO,EAAE,MAAM,GAAG,EAAE;KACzB;AAED,QAAI,sBAAsB;KACxB,MAAM,OAAO,WAAW,cAAc,EACpC,aAAa,OACd,CAAC;AAEF,wBAAmB,eAAe;AAChC,aAAO,KAAK,qBAAqB;;eAE1B,YACT,oBAAmB,SAAS;AAG9B,QAAI,UAAU,SAAS,EACrB,oBAAmB,aAAa;IAGlC,MAAM,oBAAoB,CAAC,iBAAiB,mBAAmB;IAE/D,MAAM,eAAe,OAAO,QAAQ,OAAO,MACxC,SACC,KAAK,KAAK,WAAW,kBACrB,KAAK,KAAK,QAAQ,MAAW,EAAE,WAAW,eAAe,CAC5D;AAED,QAAI,cAAc;KAChB,MAAM,WAAW,MAAM,QAAQ,aAAa,IAAI,GAC5C,aAAa,IAAI,MAAM,MAAW,EAAE,WAAW,eAAe,GAC9D,aAAa;AAEjB,SAAI,UAAU,SAAS;AACrB,eAAS,QAAQ,UAAU,SAAS,QAAQ,WAAW,EAAE;AACzD,eAAS,QAAQ,QAAQ,KAAK,kBAAkB;;WAE7C;AACL,YAAO,SAAS,OAAO,UAAU,EAAE;AACnC,YAAO,OAAO,QAAQ,OAAO,OAAO,SAAS,EAAE;AAC/C,YAAO,OAAO,MAAM,KAAK;MACvB,MAAM;MACN,SAAS;MACT,KAAK,CACH;OACE,QAAQ,eAAe,QAAQ,eAAe;OAC9C,SAAS;QACP,SAAS;QACT,YAAY;QACZ,YAAY,EACV,SAAS;SAAC;SAAc;SAAO;SAAoB,EACpD;QACD,SAAS,CAAC,kBAAkB;QAC7B;OACF,CACF;MACF,CAAC;;AAGJ,QAAI,OAAO,WAAW,YAAY,WAChC,QAAO,WAAW,QAAQ,QAAQ,QAAQ;AAG5C,WAAO;;GAEV"}

package/docs/PIPELINE.md

@@ -0,0 +1,519 @@
+# Tasty Style Rendering Pipeline
+
+This document describes the style rendering pipeline that transforms style objects into CSS rules. The pipeline ensures that each style value is applied to exactly one condition through exclusive condition building, boolean simplification, and intelligent CSS generation.
+
+**Implementation:** [`src/pipeline/`](../src/pipeline/) — TypeScript file names below are relative to that directory.
+
+## Overview
+
+The pipeline takes a `Styles` object and produces an array of `CSSRule` objects ready for injection into the DOM. Entry points include `renderStylesPipeline` (full pipeline + optional class-name prefixing) and `renderStyles` (direct selector/class mode). The per-handler flow has seven main stages:
+
+```
+Input: Styles Object
+         ↓
+    ┌─────────────────────────────────────┐
+    │  1. PARSE CONDITIONS                │
+    │     parseStyleEntries + parseStateKey│
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  2. BUILD EXCLUSIVE CONDITIONS      │
+    │     Negate higher-priority entries  │
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  3. EXPAND AT-RULE OR BRANCHES       │
+    │     expandExclusiveOrs (when needed)│
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  4. COMPUTE STATE COMBINATIONS      │
+    │     Cartesian product across styles │
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  5. CALL HANDLERS                   │
+    │     Compute CSS declarations        │
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  6. MERGE BY VALUE                  │
+    │     Combine rules with same output  │
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  7. MATERIALIZE CSS                 │
+    │     Condition → selectors + at-rules│
+    └─────────────────────────────────────┘
+         ↓
+    ┌─────────────────────────────────────┐
+    │  runPipeline: dedupe identical rules │
+    └─────────────────────────────────────┘
+         ↓
+Output: CSSRule[]
+```
+
+**Simplification** (`simplifyCondition` in `simplify.ts`) is not a separate numbered stage. It runs inside exclusive building, `expandExclusiveOrs` branch cleanup, combination ANDs, merge-by-value ORs, and materialization as needed.
+
+**Post-pass:** After `processStyles` collects rules from every handler, `runPipeline` filters duplicates using a key of `selector|declarations|atRules|rootPrefix` so identical emitted rules appear once.
+
+---
+
+## Stage 1: Parse Conditions
+
+**Files:** `exclusive.ts` (`parseStyleEntries`), `parseStateKey.ts` (`parseStateKey`)
+
+### What It Does
+
+Converts each state key in a style value map (like `'hovered & !disabled'`, `'@media(w < 768px)'`) into `ConditionNode` trees. `parseStyleEntries` walks the object keys in source order and assigns priorities; `parseStateKey` parses a single key string.
+
+### How It Works
+
+1. **Tokenization**: The state key is split into tokens using a regex pattern that recognizes:
+   - Operators: `&` (AND), `|` (OR), `!` (NOT), `^` (XOR)
+   - Parentheses for grouping
+   - State tokens: `@media(...)`, `@root(...)`, `@parent(...)`, `@own(...)`, `@supports(...)`, `@(...)`, `@starting`, predefined states, modifiers, pseudo-classes
+
+2. **Recursive Descent Parsing**: Tokens are parsed with operator precedence:
+   ```
+   ! (NOT) > ^ (XOR) > | (OR) > & (AND)
+   ```
+
+3. **State Token Interpretation**: Each state token is converted to a specific condition type:
+   - `hovered` → `ModifierCondition` with `attribute: 'data-hovered'`
+   - `theme=dark` → `ModifierCondition` with `attribute: 'data-theme', value: 'dark'`
+   - `:hover` → `PseudoCondition`
+   - `@media(w < 768px)` → `MediaCondition` (`subtype: 'dimension'`) with bounds
+   - `@media(prefers-color-scheme: dark)` → `MediaCondition` (`subtype: 'feature'`, `feature` + `featureValue`)
+   - `@root(schema=dark)` → `RootCondition` wrapping the inner condition
+   - `@parent(hovered)` → `ParentCondition` (optional `direct` for immediate parent)
+   - `@own(hovered)` → `OwnCondition` wrapping the parsed inner condition
+   - `@supports(display: grid)` → `SupportsCondition`
+   - `@(w < 600px)` → `ContainerCondition` (dimension, style, or raw subtypes)
+   - `@mobile` → Resolved via predefined states, then parsed recursively
+
+Pipeline warnings for invalid inputs (e.g. bad `$` selector affix) are emitted from `warnings.ts`.
+
+### Why
+
+The condition tree representation enables:
+- Boolean algebra operations (simplification, negation)
+- Semantic analysis (detect contradictions)
+- Flexible CSS generation (different output for media vs. selectors)
+
+### Example
+
+```typescript
+// Input
+'hovered & @media(w < 768px)'
+
+// Output ConditionNode
+{
+  kind: 'compound',
+  operator: 'AND',
+  children: [
+    { kind: 'state', type: 'modifier', attribute: 'data-hovered', ... },
+    { kind: 'state', type: 'media', subtype: 'dimension', upperBound: { value: '768px', ... }, ... }
+  ]
+}
+```
+
+---
+
+## Stage 2: Build Exclusive Conditions
+
+**File:** `exclusive.ts` (`buildExclusiveConditions`)
+
+### What It Does
+
+Ensures each style entry applies in exactly one scenario by ANDing each condition with the negation of all higher-priority conditions.
+
+### How It Works
+
+Given entries ordered by priority (highest first):
+```
+A: value1 (priority 2)
+B: value2 (priority 1)
+C: value3 (priority 0)
+```
+
+Produces:
+```
+A: A                    (highest priority, no negation needed)
+B: B & !A               (applies only when A doesn't)
+C: C & !A & !B          (applies only when neither A nor B)
+```
+
+Each exclusive condition is passed through `simplifyCondition`. Entries that simplify to `FALSE` (impossible) are filtered out. The default state (`''` → `TrueCondition`) is not added to the “prior” list for negation (see `buildExclusiveConditions`).
+
+### Why
+
+This eliminates CSS specificity wars. Instead of relying on cascade order, each CSS rule matches in exactly one scenario. Benefits:
+- Predictable styling regardless of rule order
+- No conflicts from overlapping conditions
+- Easier debugging (each rule is mutually exclusive)
+
+### Example
+
+```typescript
+// Style value mapping
+{ padding: { '': '2x', 'compact': '1x', '@media(w < 768px)': '0.5x' } }
+
+// After exclusive building (highest priority first):
+// @media(w < 768px): applies when media matches
+// compact & !@media(w < 768px): applies when compact but NOT media
+// !compact & !@media(w < 768px): default, applies when neither
+```
+
+---
+
+## Stage 3: Expand At-Rule OR Branches
+
+**File:** `exclusive.ts` (`expandExclusiveOrs`)
+
+### What It Does
+
+Runs **after** `buildExclusiveConditions`. When an entry’s **exclusive** condition contains a top-level OR that mixes **at-rule** context (`media`, `container`, `supports`, `starting`) with other branches, those ORs are split into mutually exclusive branches so each branch keeps the correct at-rule wrapping (e.g. after De Morgan: `!(A & B)` → `!A | !B`).
+
+### How It Works
+
+1. Collect top-level OR branches of `exclusiveCondition`.
+2. If there is no OR, or **no** branch involves at-rule context, the entry is unchanged (pure selector ORs are handled later via `:is()` / variant merging in materialization).
+3. Otherwise, branches are sorted with `sortOrBranchesForExpansion` so at-rule-heavy branches come first, then each branch is made exclusive against prior branches: `branch & !prior[0] & !prior[1] & ...`, then simplified.
+4. Impossible branches are dropped; expanded entries get a synthetic `stateKey` suffix like `[or:0]`.
+
+### Why
+
+Without this pass, a condition like `!(@supports & :has)` could produce one rule missing the `@supports` wrapper. Exclusive OR expansion ensures negated at-rule groups still nest modifiers correctly.
+
+### Example (conceptual)
+
+See the comment block in `exclusive.ts` (~195–206): a default value’s exclusive condition can become `!@supports | !:has`; expansion yields one branch under `@supports (not …)` and another under `@supports (…) { :not(:has()) }` instead of a bare `:not(:has())` rule.
+
+---
+
+## Stage 4: Compute State Combinations
+
+**File:** `index.ts` (`computeStateCombinations`)
+
+### What It Does
+
+Computes the Cartesian product of all style entries for a handler, creating snapshots of which value each style has for each possible state combination.
+
+### How It Works
+
+1. Collect exclusive entries for each style the handler uses
+2. Compute Cartesian product: every combination of entries
+3. For each combination:
+   - AND all `exclusiveCondition` values together
+   - `simplifyCondition` the result
+   - Skip if simplified to `FALSE`
+   - Record the values for each style
+
+### Why
+
+Style handlers often depend on multiple style properties (e.g., `padding` might look at both `padding` and `gap`). By computing all valid combinations, we can call the handler once per unique state and get the correct CSS output.
+
+### Example
+
+```typescript
+// Handler looks up: ['padding', 'size']
+// padding has entries: [{ value: '2x', condition: A }, { value: '1x', condition: B }]
+// size has entries: [{ value: 'large', condition: C }, { value: 'small', condition: D }]
+
+// Combinations:
+// { padding: '2x', size: 'large', condition: A & C }
+// { padding: '2x', size: 'small', condition: A & D }
+// { padding: '1x', size: 'large', condition: B & C }
+// { padding: '1x', size: 'small', condition: B & D }
+```
+
+---
+
+## Stage 5: Call Handlers
+
+**File:** `index.ts` (within `processStyles`)
+
+### What It Does
+
+Invokes style handlers with computed value snapshots to produce CSS declarations.
+
+### How It Works
+
+1. For each state snapshot (condition + values):
+   - Call the handler with the values
+   - Handler returns CSS properties (e.g., `{ 'padding-top': '16px', 'padding-bottom': '16px' }`)
+   - Handler may also return `$` (selector suffix) for pseudo-elements
+2. Create computed rules with the condition, declarations, and selector suffix
+
+### Why
+
+Style handlers encapsulate the logic for translating design tokens (like `'2x'`) to actual CSS values (like `'16px'`). They can also handle complex multi-property styles (e.g., `padding` → `padding-top`, `padding-right`, etc.).
+
+---
+
+## Stage 6: Merge By Value
+
+**File:** `index.ts` (`mergeByValue`)
+
+### What It Does
+
+Combines rules that have identical CSS output into a single rule with an OR condition.
+
+### How It Works
+
+1. Group rules by `selectorSuffix` plus a stable string for declarations (JSON via an internal `declStringCache` `WeakMap` on declaration objects)
+2. For rules in the same group:
+   - Merge their conditions with OR
+   - `simplifyCondition` the resulting condition
+3. Output one rule per group
+
+### Why
+
+Different state combinations might produce the same CSS output. Rather than emitting duplicate CSS, we combine them into a single rule. This reduces CSS size and improves performance.
+
+### Example
+
+```typescript
+// Before merging:
+// condition: A → { color: 'red' }
+// condition: B → { color: 'red' }
+
+// After merging:
+// condition: A | B → { color: 'red' }
+```
+
+---
+
+## Stage 7: Materialize CSS
+
+**File:** `materialize.ts` (`conditionToCSS`, `materializeComputedRule` in `index.ts`)
+
+### What It Does
+
+Converts condition trees into actual CSS selectors and at-rules.
+
+### How It Works
+
+1. **Condition to CSS components** (`conditionToCSS`): Walk the condition tree and build `SelectorVariant` data:
+   - `ModifierCondition` → attribute selectors (e.g. `[data-hovered]`); optional `operator` (`=`, `^=`, `$=`, `*=`)
+   - `PseudoCondition` → pseudo-class (e.g. `:hover`)
+   - `MediaCondition` → `@media` (dimension, feature, or type)
+   - `ContainerCondition` → `@container` (dimension, style query, or raw)
+   - `RootCondition` → `rootGroups` / root prefix fragments
+   - `ParentCondition` → `parentGroups` / ancestor selectors (`direct` → child combinator path)
+   - `OwnCondition` → `ownGroups` on the **styled** element (sub-element / `&` scope), optimized with `optimizeGroups`
+   - `SupportsCondition` → `@supports` at-rules
+   - `StartingCondition` → `@starting-style` wrapper
+
+2. **AND / OR on variants**: AND merges variant dimensions; OR yields multiple variants (later merged into `:is()` / `:not()` groups where appropriate).
+
+3. **Contradiction detection**: During variant merging, impossible combinations are dropped (e.g. conflicting media, root, or modifier negations).
+
+4. **`materializeComputedRule`**: Groups variants by sorted at-rules plus root-prefix key; within each group, `mergeVariantsIntoSelectorGroups` merges variants that differ only in flat modifier/pseudo parts; builds selector strings and emits one or more `CSSRule` objects.
+
+### Why
+
+CSS has different mechanisms for different condition types:
+- Modifiers → attribute selectors
+- Media queries → `@media` blocks
+- Container queries → `@container` blocks
+- Root state → `:root` / root groups
+- Supports → `@supports` blocks
+
+The materialization layer handles these differences while maintaining the logical semantics of the condition tree.
+
+### Output Structure
+
+```typescript
+interface CSSRule {
+  selector: string | string[]; // Selector fragment(s); array when OR’d selector branches
+  declarations: string; // CSS declarations (e.g. 'color: red;')
+  atRules?: string[]; // Wrapping at-rules
+  rootPrefix?: string; // Root state prefix
+}
+```
+
+When `renderStylesPipeline` runs **without** a class name, returned rules include `needsClassName: true` (compatibility field for the injector); that flag is not part of `CSSRule` inside `materialize.ts`.
+
+---
+
+## Condition Types
+
+**File:** `conditions.ts`
+
+### ConditionNode Hierarchy
+
+```
+ConditionNode
+├── TrueCondition     (matches everything)
+├── FalseCondition    (matches nothing)
+├── CompoundCondition (AND/OR of children)
+└── StateCondition
+    ├── ModifierCondition    (data attributes; optional value + match operator)
+    ├── PseudoCondition      (CSS pseudo-classes: :hover)
+    ├── MediaCondition       (subtype: dimension | feature | type)
+    ├── ContainerCondition   (subtype: dimension | style | raw)
+    ├── RootCondition        (inner condition under :root)
+    ├── ParentCondition      (@parent(...); optional direct parent)
+    ├── OwnCondition         (@own(...); scoped to styled / sub-element)
+    ├── SupportsCondition    (@supports(...))
+    └── StartingCondition    (@starting-style wrapper)
+```
+
+### Key Operations
+
+- `and(...conditions)`: Create AND with short-circuit and flattening
+- `or(...conditions)`: Create OR with short-circuit and flattening
+- `not(condition)`: Negate with De Morgan's law support
+- `getConditionUniqueId(condition)`: Get canonical ID for comparison
+
+---
+
+## Simplification
+
+**File:** `simplify.ts`
+
+### What It Does
+
+Applies boolean algebra rules to reduce condition complexity and detect impossible combinations.
+
+### Rules Applied
+
+1. **Identity Laws**:
+   - `A & TRUE = A`
+   - `A | FALSE = A`
+
+2. **Annihilator Laws**:
+   - `A & FALSE = FALSE`
+   - `A | TRUE = TRUE`
+
+3. **Contradiction Detection**:
+   - `A & !A = FALSE`
+
+4. **Tautology Detection**:
+   - `A | !A = TRUE`
+
+5. **Idempotent Laws** (via deduplication):
+   - `A & A = A`
+   - `A | A = A`
+
+6. **Absorption Laws**:
+   - `A & (A | B) = A`
+   - `A | (A & B) = A`
+
+7. **Range intersection**: For **media and container** dimension queries, impossible ranges simplify to `FALSE` (e.g. `@media(w > 400px) & @media(w < 300px)`).
+
+8. **Container style queries**: Conflicting or redundant `@container` style conditions on the same property can be reduced (see `simplify.ts` around the container-style conflict pass).
+
+9. **Attribute conflict detection**:
+   - `[data-theme="dark"] & [data-theme="light"] = FALSE`
+
+### Why
+
+Simplification reduces CSS output size and catches impossible combinations early, preventing invalid CSS rules from being generated.
+
+---
+
+## Caching Strategy
+
+LRU and small auxiliary caches:
+
+| Cache | Size | Key | Purpose |
+|-------|------|-----|---------|
+| `pipelineCache` | 5000 | `pipelineCacheKey \|\| stringifyStyles(styles)` | Skip full pipeline for identical styles |
+| `parseCache` | 5000 | `trimmedStateKey + '\\0' + isSubElement + '\\0' + JSON.stringify(localPredefinedStates)` | Skip re-parsing identical state keys in context |
+| `simplifyCache` | 5000 | `getConditionUniqueId(node)` | Skip re-simplifying identical conditions |
+| `conditionCache` | 3000 | `getConditionUniqueId(node)` in `conditionToCSS` | Skip re-materializing identical conditions |
+| `variantKeyCache` | — | `WeakMap<SelectorVariant, string>` | Stable string keys for variants during materialization |
+| `declStringCache` | — | `WeakMap<Record<string,string>, string>` | Stable JSON keys for declaration objects in `mergeByValue` |
+
+---
+
+## Example Walkthrough
+
+### Input
+
+```typescript
+const styles = {
+  color: {
+    '': '#white',
+    '@media(prefers-color-scheme: dark)': '#dark',
+    hovered: '#highlight',
+  },
+};
+```
+
+### Stage 1: Parse Conditions
+
+```
+'' → TrueCondition
+'@media(prefers-color-scheme: dark)' → MediaCondition(subtype: 'feature', feature: 'prefers-color-scheme', featureValue: 'dark')
+'hovered' → ModifierCondition(attribute: 'data-hovered')
+```
+
+### Stages 2–3: Exclusive conditions + expand OR
+
+Processing order (highest priority first): `hovered`, `@media(dark)`, default.
+
+```
+hovered: [data-hovered]
+@media(dark) & !hovered: @media(dark) & :not([data-hovered])
+!hovered & !@media(dark): :not([data-hovered]) & not @media(dark)
+```
+
+No at-rule OR expansion needed on these exclusives.
+
+### Stages 4–5: Compute combinations and call handler
+
+Single style, three snapshots; the `color` handler emits `color` plus `--current-color*` variables.
+
+### Stage 6: Merge by value
+
+Each snapshot yields distinct declarations; no merge.
+
+### Stage 7: Materialize CSS
+
+Using `renderStyles(styles, '.t1')` (single class prefix; `renderStylesPipeline` doubles the class for specificity when a class name is supplied):
+
+```css
+.t1[data-hovered] {
+  color: var(--highlight-color);
+  --current-color: var(--highlight-color);
+  --current-color-oklch: var(--highlight-color-oklch);
+}
+@media (prefers-color-scheme: dark) {
+  .t1:not([data-hovered]) {
+    color: var(--dark-color);
+    --current-color: var(--dark-color);
+    --current-color-oklch: var(--dark-color-oklch);
+  }
+}
+@media (not (prefers-color-scheme: dark)) {
+  .t1:not([data-hovered]) {
+    color: var(--white-color);
+    --current-color: var(--white-color);
+    --current-color-oklch: var(--white-color-oklch);
+  }
+}
+```
+
+---
+
+## Key Design Decisions
+
+### 1. Exclusive Conditions Over CSS Specificity
+
+Rather than relying on CSS cascade rules, we generate mutually exclusive selectors. This makes styling predictable and debuggable.
+
+### 2. OR Handling: DNF, `:is()`, and `expandExclusiveOrs`
+
+OR of conditions is ultimately expressed as DNF (OR of ANDs) for CSS—comma-separated selectors, multiple rules, or `:is()` / `:not()` groups. **User-authored** ORs on pure selector conditions are handled in materialization. **`expandExclusiveOrs`** is an additional, **post-exclusive** pass for ORs that appear on **exclusive** conditions and involve **at-rule** branches (often from De Morgan on `@supports` / `@media` / `@container` / `@starting`), so each branch keeps correct at-rule nesting.
+
+### 3. Early Contradiction Detection
+
+Impossible combinations are detected at multiple levels (simplification, variant merging) to avoid generating invalid CSS.
+
+### 4. Aggressive Caching
+
+Parse, simplify, condition-to-CSS, and full-pipeline results are cached independently, enabling fast re-rendering when only parts of the style object change.

package/docs/README.md

@@ -0,0 +1,31 @@
+# Tasty Docs
+
+Tasty is a styling engine for design systems that turns component state into deterministic CSS by compiling state maps into mutually exclusive selectors. Use this hub to choose the right guide once you know whether you are evaluating the model, adopting it in a design system, or implementing reusable, stateful components day to day.
+
+## Start Here
+
+- **New to Tasty**: [Getting Started](getting-started.md) for installation, the first component, optional shared `configure()`, ESLint, editor tooling, and rendering mode selection.
+- **Learning the component model**: [Methodology](methodology.md) for root + sub-elements, `styleProps`, tokens, extension, and recommended boundaries between `styles`, `style`, and wrappers.
+- **Evaluating the selector model**: [Style rendering pipeline](PIPELINE.md) for how mutually exclusive selectors make stateful styling deterministic.
+- **Evaluating fit**: [Comparison](comparison.md) for tool-selection context, then [Adoption Guide](adoption.md) for audience fit and rollout strategy inside a design system.
+
+## By Role
+
+- **Application developer using an existing design system**: [Getting Started](getting-started.md), then [React API](react-api.md).
+- **Design-system author**: [Methodology](methodology.md), [Building a Design System](design-system.md), [Configuration](configuration.md), and [Adoption Guide](adoption.md).
+- **Platform or tooling engineer**: [Configuration](configuration.md), [Zero Runtime (tastyStatic)](tasty-static.md), [Server-Side Rendering](ssr.md), and [Debug Utilities](debug.md).
+
+## By Styling Approach
+
+- **React components**: [React API](react-api.md)
+- **Zero-runtime / build-time extraction**: [Zero Runtime (tastyStatic)](tasty-static.md)
+- **Runtime `tasty()` with server collection and hydration**: [Server-Side Rendering](ssr.md)
+
+## By Task
+
+- **Learn the style language**: [Style DSL](dsl.md)
+- **Look up a property handler**: [Style Properties](styles.md)
+- **Define tokens, units, recipes, keyframes, or properties globally**: [Configuration](configuration.md)
+- **Debug generated CSS or cache behavior**: [Debug Utilities](debug.md)
+- **Understand how selector generation works internally**: [Style rendering pipeline](PIPELINE.md)
+- **Understand runtime injection internals**: [Style Injector](injector.md)