Vooya is a WASM integration layer for existing Web applications. It compiles ordinary Rust component and store implementations into browser-consumable WebAssembly and exposes them through host-framework adapters. The old .voo format was an exploratory intermediate and is no longer a supported authoring path. Vue and React are the supported first-party adapters; Solid and Svelte are experimental with current evidence on the Vite 7 Rust-file path.

This directory is the source of truth for user-facing documentation and is published as a VitePress site. Markdown remains the canonical content format; the site adds navigation, search, version context, and deployable static output without creating a second documentation repository.

The Vooya Lab turns these authoring and compatibility boundaries into runnable browser cases. Its source lives in the vooyajs/vooya-lab repository; the lab links back here for the contracts and guides behind each case. Contributors should start with the Lab's case specification standard and case portfolio strategy: the Lab owns case metadata, source presentation, and browser evidence, while this repository owns any compiler, ABI, runtime, adapter, or toolchain fix a case reveals.

Vooya FS continues Rush-FS as a Rust-powered batch filesystem engine for Node.js. It shares Vooya's boundary-first and evidence-gated design, but uses native Node-API for direct host filesystem semantics instead of browser WebAssembly.

• Contributing: project scope, development setup, testing, and pull request expectations.
• Getting started: install the alpha toolchain and run a first component through a current Vue, React, Solid, or Svelte adapter path.
• Rust-file authoring: component/store roles, schema records, generated bindings, and the current first-party Vite path.
• API reference: public package exports, options, and current alpha boundaries.
• The component boundary: what the host framework owns, what WASM owns, and why that boundary exists.
• Tooling reference: Vite options, generated files, Rust dependencies, and development rebuilds.
• Maintainer releases: release state, alpha publication, and the stable-release lifecycle.
• Project status: what works, what remains experimental, and the next milestones.
• Compatibility matrix: automated framework and browser evidence, plus explicit unsupported boundaries.
• Benchmarks: workload-specific measurements and the limits of their conclusions.
• Beta boundary: the current product scope, authoring decision, and remaining contract gate.
• Scatter-plot demo: a repeatable browser check for a Rust-owned Canvas rendering surface.

The RFCs record decisions and their original stage context. They are not a substitute for the current guides.

Open a GitHub issue titled RFC: <proposal> first. The issue is where options, compatibility effects, acceptance gates, and the maintainer decision are recorded. After a decision, maintainers may add a numbered document here; bugs, chores, and implementation tasks do not consume RFC numbers. RFC 0009 is the next available number.

• RFC 0001: component islands
• RFC 0002: reactive component model
• RFC 0003: first public alpha
• RFC 0005: island events and lifecycle diagnostics
• RFC 0006: precompiled Vue artifacts
• RFC 0007: Rust-file authoring and ABI v1
• RFC 0008: layer boundary and version roadmap

Performance work is recorded separately:

• Data-grid benchmark plan
• July 2026 data-grid result

• Vooya is the product and project name.
• @vooya is the npm package scope.
• vooya is the runtime and public API prefix, such as vooya() and data-vooya-host.
• Rust role attributes and the vooya prefix describe the current authoring and runtime boundary.
• Voo is the retired legacy component file format, using the .voo extension. File-format tooling may still use the voo prefix.

The GitHub repository follows the same convention at vooyajs/vooya.