Module feature_flag 

Feature-flag capability trait and types.

A FeatureFlagPlugin answers the question “what does flag X evaluate to for this caller, right now?”. Backends fall into two broad groups:

1. Local (@bext/flags-static) — flag definitions live in a config file loaded at construction time; evaluation is a pure lookup.
2. Remote (@bext/flags-openfeature, @bext/flags-unleash, @bext/flags-launchdarkly) — flag state is fetched from an external provider; refresh pulls a fresh snapshot.

The trait is deliberately sync to match the rest of bext-plugin-api. Backends that need network I/O (OpenFeature providers, LaunchDarkly SDK) either use a blocking client or block on a runtime handle the same way the JWKS fetcher in the JWT middleware does — plugins cannot expose native async across the WASM boundary, so the host-facing shape stays sync.

FlagValue is kept small and typed so that the host-function shims (flags.bool, flags.string, flags.int, flags.json) can return the same data without reaching back into the plugin for re-decoding. JSON-shaped values are carried as a JSON-encoded String — this keeps the ABI flat and matches the way session.rs carries session data and the way lifecycle.rs carries event payloads.

Structs

FlagContext

Evaluation context handed to a flag provider on every call.

Enums

FlagValue

A single flag value. Four concrete shapes cover every flag provider the plan lists (OpenFeature, Unleash, LaunchDarkly, Statsig) without making any of them special.

Traits

FeatureFlagPlugin

A feature-flag provider.