{"owner":"Ripple-TS","repo":"ripple","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md","GEMINI.md"],"skills":{"CLAUDE.md":"# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","AGENTS.md":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","GEMINI.md":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n"},"files":{"CLAUDE.md":"# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","AGENTS.md":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","GEMINI.md":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","category":"root","tokens":1680},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","category":"root","tokens":1725},{"name":"GEMINI.md","path":"GEMINI.md","title":"GEMINI.md","content":"# Additional Conventions Beyond the Built-in Functions\n\nAs this project's AI coding tool, you must follow the additional conventions below, in addition to the built-in functions.\n\n# Ripple Project Guide for AI Agents\n\nRipple is a TypeScript-first UI framework and monorepo maintained by Dominic\nGannaway. The current authoring format is centered on `.tsrx` files and the shared\nTSRX compiler stack. Older `.ripple`-specific docs and compiler details still\nexist in repo history and changelogs, but they are not the right default source of\ntruth for current work.\n\n## Start From Current Sources\n\nUse the nearest live source rather than historical summaries:\n\n- `website-tsrx/public/llms.txt` for current target-neutral TSRX syntax,\n  compiler-facing authoring guidance, and examples\n- `website/public/llms.txt` for Ripple runtime APIs, Ripple target behavior, and\n  Ripple-specific authoring guidance\n- `README.md` for project overview, positioning, and quick-start examples\n- `packages/*/README.md` for package-specific usage and public APIs\n- `vitest.config.js` for the current test projects and file globs\n- `package.json` for workspace-wide scripts such as `rules:generate`, `test`,\n  `format`, `format:check`, and `typecheck`\n\nIf a guide in this repo conflicts with nearby code or package READMEs, trust the\nnearby code and current package docs.\n\n## RuleSync\n\nThis repository uses RuleSync as the single source of truth for shared AI agent\ninstructions. Edit `.rulesync/rules/` and regenerate derived files instead of\npatching generated outputs directly.\n\nGenerated targets include:\n\n- `AGENTS.md`\n- `.github/copilot-instructions.md`\n- `CLAUDE.md`\n- `GEMINI.md`\n- `.cursor/rules/project.mdc`\n\nAfter changing RuleSync content, run:\n\n```bash\npnpm rules:generate\n```\n\n## Monorepo Map\n\nThis is a pnpm monorepo. The current high-level layout is:\n\n- `packages/tsrx/`: core parser, transforms, and shared compiler infrastructure\n- `packages/tsrx-ripple/`, `packages/tsrx-react/`, `packages/tsrx-solid/`,\n  `packages/tsrx-preact/`: target-specific compiler layers\n- `packages/ripple/`: Ripple runtime, server helpers, and framework behavior\n- `packages/vite-plugin/`, `packages/rollup-plugin/`,\n  `packages/vite-plugin-react/`, `packages/vite-plugin-solid/`,\n  `packages/vite-plugin-preact/`, `packages/rspack-plugin-react/`,\n  `packages/turbopack-plugin-react/`: bundler integrations\n- `packages/adapter/`, `packages/adapter-node/`, `packages/adapter-bun/`,\n  `packages/adapter-vercel/`: deployment and platform adapters\n- `packages/language-server/`, `packages/typescript-plugin/`,\n  `packages/vscode-plugin/`, `packages/intellij-plugin/`, `packages/nvim-plugin/`,\n  `packages/sublime-text-plugin/`, `packages/zed-plugin/`: editor and language\n  tooling\n- `packages/eslint-parser/`, `packages/eslint-plugin/`,\n  `packages/prettier-plugin/`, `packages/prettier-plugin-ripple/`: linting and\n  formatting\n- `packages/create-ripple/`, `templates/`, `playground/`: scaffolding and local\n  examples\n- `website/`, `website-new/`, `website-tsrx/`: documentation and website work\n\nWhen routing a change, prefer the package that directly owns the behavior rather\nthan editing generated output, tests, or editor integrations first.\n\n## Current Working Assumptions\n\n- Default component files are `.tsrx`. Do not describe the project as primarily\n  using `.ripple` files unless the local file you are editing actually does.\n- Prefer the current TSRX component shape: `function Component(props) @{ ... }`\n  when setup and output share a scope, or\n  `function Component(props) { return <div />; }` for simple single-root output.\n- TSRX templates use JSX-shaped elements, fragments, text, expression containers,\n  and directive control flow. Do not introduce removed experimental\n  template-boundary or legacy component syntaxes in new examples.\n- When a template scope mixes TypeScript setup with rendered output, setup\n  statements come first and the scope finishes with one output node: a JSX\n  element, JSX fragment, or JSX control-flow expression. Wrap text, expression\n  containers, or multiple siblings in a fragment when they are the output after\n  setup.\n- Use `@if`, `@for`, `@switch`, and `@try` for template control flow. Plain\n  JavaScript control flow remains ordinary setup code.\n- Some packages still preserve compatibility or historical references. Treat them\n  as compatibility context, not the default architecture description.\n- Use `pnpm` for all package management and workspace scripts.\n- Follow the conventions of the package you are changing. This repo mixes plain\n  JavaScript, JSDoc-typed JavaScript, and TypeScript depending on package.\n- Match nearby naming, file layout, and test style instead of applying a single\n  convention repo-wide.\n\n## Finding The Right Package\n\nUse these rough routing rules:\n\n- Ripple syntax, parsing, source transforms, or shared AST behavior:\n  `packages/tsrx/` and the relevant target package under `packages/tsrx-*`\n- Ripple runtime behavior, hydration, reactivity, DOM updates, or server output:\n  `packages/ripple/`\n- Vite, Rollup, Rspack, Turbopack, or adapter behavior: the relevant plugin or\n  adapter package in `packages/`\n- Diagnostics, completions, hover, definitions, or editor integration:\n  `packages/language-server/`, `packages/typescript-plugin/`, and editor plugin\n  packages\n- Formatting or lint behavior: `packages/prettier-plugin/`,\n  `packages/prettier-plugin-ripple/`, `packages/eslint-parser/`, or\n  `packages/eslint-plugin/`\n\n## Validation\n\nPrefer the smallest validation that covers the touched surface.\n\nCommon workspace commands:\n\n```bash\npnpm rules:generate\npnpm format:check\npnpm test\npnpm test --project ripple-client\npnpm test --project ripple-server\npnpm typecheck\n```\n\nCurrent Vitest projects are defined in `vitest.config.js`. Ripple runtime suites\nuse `.test.tsrx` files for many client, server, and compat tests, while tooling\npackages often use `.test.js` or `.test.ts`.\n\n## Changesets\n\nAdd a changeset for user-facing package changes. Skip changesets for docs-only,\ntest-only, and internal tooling updates.\n\nOnly use `patch` changesets. Do not use `minor` or `major` bump types in this\nrepo; prerelease packages must stay on the patch track until a release plan\nexplicitly changes that policy.\n\n```bash\npnpm changeset\n```\n\nValidate pending changesets before versioning or publishing:\n\n```bash\npnpm changeset:check\n```\n\n## Practical Guidance For Agents\n\n- Prefer the current docs in `website-tsrx/public/llms.txt` and\n  `website/public/llms.txt` over stale architectural summaries.\n- Avoid copying removed compiler APIs, old package layouts, or legacy `.ripple`\n  examples into new guidance.\n- If you need exact behavior, read the owning package and its tests instead of\n  relying on a repo-wide summary.\n- Keep documentation updates short and durable. High-level guidance ages better\n  than detailed internal call lists.\n","category":"root","tokens":1725}]}