# What Are the Two Independent Feature Gate Sets in OpenHuman and Where Are They Enforced? > Discover the two independent feature gate sets in OpenHuman: Contributor for local dev and Product for desktop builds. Learn where they are enforced and how they manage features. - Repository: [Tiny Humans/openhuman](https://github.com/tinyhumansai/openhuman) - Tags: deep-dive - Published: 2026-08-26 --- **OpenHuman maintains two independent Cargo feature gate sets—the Contributor set defined in the root [`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml) default features for local development, and the Product set listed in [`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt) for shipped desktop builds—enforced respectively by standard Cargo commands and CI pipelines that forward features through [`app/src-tauri/Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml).** The OpenHuman repository uses a dual-gate architecture to separate lightweight contributor builds from fully-featured product releases. Understanding these two independent feature gate sets is essential for developers compiling the core library, running tests, or building the Tauri desktop application. This guide explains exactly how the Contributor and Product sets differ and where the codebase enforces each configuration according to the `tinyhumansai/openhuman` source. ## The Two Independent Feature Gate Sets ### Contributor Feature Set (Default) The **Contributor feature set** represents the baseline configuration used for everyday development and continuous integration "lite" runs. Defined in the `[features] default` block of the root **[`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml)**, this set enables a curated group of core crates and optional dependencies necessary for contributor testing without bloating the compile time with product-specific domains. When you run any Cargo command without explicit `--features` flags, Cargo automatically applies this default set, making it the standard environment for writing and testing code. ### Product Feature Set The **Product feature set** determines which optional domains compile into the shipped **Tauri desktop application**. This set is explicitly listed in **[`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt)** and consumed by the helper script **[`scripts/ci/product-features.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.sh)**, which outputs a comma-separated feature list suitable for Cargo’s `--features` flag. Unlike the Contributor set, the Product set includes domains required for the end-user experience—such as web3, documents, and modules—ensuring the released binary contains exactly the functionality intended for production without extraneous development dependencies. ## Where Each Set Is Enforced in the Codebase The enforcement of these two sets occurs at distinct layers of the build system. **Contributor enforcement** happens automatically in the root **[`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml)** through the `default` features key. When you execute `cargo check`, `cargo test`, or `cargo build` without additional flags, Cargo resolves dependencies based on this default feature set. **Product enforcement** occurs in two critical locations. First, CI pipelines invoke builds using the explicit flag `--features "$(scripts/ci/product-features.sh)"`, overriding the defaults with the product list. Second, the Tauri shell’s **[`app/src-tauri/Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml)** forwards exactly those product features to ensure the desktop binary and core library stay synchronized. The **`scripts/ci/check-feature-forwarding.mjs`** script validates this forwarding, preventing mismatches where the core might compile a feature the UI never receives. ## Building with Each Feature Set ### Contributor Build (Default) Use this for local development and running the test suite: ```bash # Compile and test using the default contributor features cargo test # Check the core library with contributor settings cargo check ``` ### Product Build Use this to reproduce the exact binary shipped to users: ```bash # View the active product features scripts/ci/product-features.sh # Build the release binary with the complete product feature set cargo build --release --features "$(scripts/ci/product-features.sh)" ``` ### Minimal Build (No Optional Features) To compile only the kernel without any optional domains: ```bash # Disable all defaults and enable only the core flows feature cargo build --release --no-default-features --features "flows" ``` ## Adding New Domains Across Both Sets When introducing a new optional domain (for example, `media`), you must update both independent gate sets to maintain consistency: 1. **Add to the Contributor set** by updating the `[features] default` array in the root **[`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml)** if the feature should be available during development. 2. **Add to the Product set** by appending the feature name to **[`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt)**, ensuring the shipped application includes the domain. 3. **Forward through the Tauri shell** by verifying that **[`app/src-tauri/Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml)** propagates the new feature, then run **`scripts/ci/check-feature-forwarding.mjs`** to validate the synchronization. ## Summary - OpenHuman uses two independent feature gate sets: the **Contributor set** (default features for development) and the **Product set** (defined in [`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt) for releases). - The Contributor set is enforced automatically by Cargo when running commands without `--features` flags, configured in the root **[`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml)**. - The Product set is enforced by CI pipelines passing `--features "$(scripts/ci/product-features.sh)"` and by the Tauri shell’s **[`app/src-tauri/Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml)** forwarding those features. - The **`scripts/ci/check-feature-forwarding.mjs`** script prevents drift between the core library and desktop shell feature configurations. - Developers can build with `--no-default-features` to compile a minimal kernel excluding all optional domains. ## Frequently Asked Questions ### What is the difference between the Contributor and Product feature sets? The Contributor feature set is the default configuration in the root **[`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml)** used for local development and testing, while the Product feature set is the explicit list in **[`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt)** that defines which optional domains ship in the Tauri desktop application. The Contributor set prioritizes fast compilation cycles for developers, whereas the Product set prioritizes complete end-user functionality. ### How do I build OpenHuman without optional features? Run `cargo build --no-default-features --features "flows"` to compile only the core kernel. This command disables the default Contributor set and manually selects only the essential `flows` feature, producing a minimal binary suitable for embedded environments or debugging the core engine. ### Where is the Product feature set defined? The Product feature set is defined in the plain-text file **[`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt)**, located in the repository’s CI scripts directory. The adjacent **[`scripts/ci/product-features.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.sh)** script reads this file and formats the contents for use with Cargo’s `--features` command-line argument during CI builds. ### How does the CI prevent feature mismatches between the core and the desktop app? The CI runs **`scripts/ci/check-feature-forwarding.mjs`**, a Node.js validation script that compares the features listed in **[`scripts/ci/product-features.txt`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/product-features.txt)** against the forwarded features in **[`app/src-tauri/Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml)**. If the Tauri shell fails to forward exactly the same product features defined for the core library, the script exits with an error, blocking the build and ensuring the desktop binary never desynchronizes from the core.