What Are the Two Independent Feature Gate Sets in OpenHuman and Where Are They Enforced?

OpenHuman maintains two independent Cargo feature gate sets—the Contributor set defined in the root Cargo.toml default features for local development, and the Product set listed in 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.

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, 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 and consumed by the helper script 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 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 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:

# 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:

# 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:

# 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 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, ensuring the shipped application includes the domain.

3. Forward through the Tauri shell by verifying that 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 for releases).
• The Contributor set is enforced automatically by Cargo when running commands without --features flags, configured in the root 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 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 used for local development and testing, while the Product feature set is the explicit list in 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, located in the repository’s CI scripts directory. The adjacent 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 against the forwarded features in 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}