FireweaveProvider and FireweaveWebProvider from every language SDK. There is no makeFireweaveLocalProvider, and no OpenFeature extra or peer dependency in the core packages.
Why the provider was unbundled
ADR-0010’s rationale, not a restatement of it:- The provider was a thin delegation layer, not a second evaluation path.
getBooleanValueandresolveBooleanEvaluationboth called the same runtime. - The OpenFeature peer dependency was mandatory by accident. A consumer who only called
controlPoints.*was still told to install an OpenFeature SDK they never imported. - The surface is seven languages. Requiring a mature OpenFeature SDK in each language made Rust and Swift depend on another project’s coverage.
What you call instead
v1 exposes exactly two capabilities: control-point reads and target registration.getBooleanValue, getStringValue, getNumberValue, getObjectValue, the four *Details variants, and evaluate) live on controlPoints / control_points / ControlPoints in every language. See Control points.
flagKey is still the parameter name on the wire, on Decision envelopes, and in conformance fixtures. Removing the OpenFeature dependency did not rename flagKey. The product noun in prose is control point.
What was removed
A search for those symbols in a v1 install should find nothing.
conformance/surface/control-points.surface.json asserts mustNotExpose for FireweaveProvider and FireweaveWebProvider.
Next
Migrate 2.1 to 2.3
Before and after call sites for the provider removal and the package rename
Control points
The nine-method native surface

