The fallback variant is documented with two different shapes, and neither matches the response

[truecourse-agent]

What happens

Two documentation pages describe the fallback ("disabled") variant with different shapes, and neither matches what the API returns.

concepts/strategy-variants.md:79-88, § Fallback variant, "If no variant matches in the given context or if the flag is disabled":

{ "name": "disabled", "enabled": false, "feature_enabled": false }

concepts/feature-flag-variants.md:116-125, § The disabled variant, "When a flag has no variants or when a flag is disabled for a user":

{ "name": "disabled", "enabled": false }

Those cannot both be right. The first says the object carries feature_enabled: false, the second says it has two fields.

On the wire, for the case both pages name, a flag that is enabled but where no variant matched, the Playground returns:

features[0].variant.feature_enabled = true

Not false, which is what strategy-variants.md prints, and not absent, which is what feature-flag-variants.md prints.

Why the returned value is arguably the correct one

feature_enabled describes the flag, not the variant. When the flag is on and only the variant lookup fell through to the fallback, true is the honest answer, and the repo's own e2e asserts exactly that, src/lib/features/frontend-api/frontend-api.e2e.test.ts:469-474:

variant: { enabled: false, name: 'disabled', feature_enabled: true, featureEnabled: true }

Four fields, with feature_enabled: true.

So the code looks right and both doc pages look wrong, in different ways. strategy-variants.md folds two distinct situations, "no variant matched" and "the flag is disabled", into one example and prints the value belonging to the second. feature-flag-variants.md omits the field entirely.

Why it matters

An SDK author or an integrator reading either page will branch on the wrong thing. Someone following strategy-variants.md will treat feature_enabled: false as the signal that they received the fallback, which is false whenever the flag is on, exactly the common case. Someone following feature-flag-variants.md will not expect the field at all.

Reproduction

Instance built from source at 3d91a51635859f13a5bc23547d323c19718629fb (unleash-server 8.1.0), PostgreSQL 15 in Docker, OSS, stock config.

1. Create a flag in project default with a strategy and at least one variant whose constraints will not match.
2. Enable the flag in development.
3. POST /api/admin/playground with a context that matches no variant.
4. Read features[0].variant.

Observed: feature_enabled: true.

Expected, per concepts/strategy-variants.md:79-88: feature_enabled: false.

The useful fix is probably to the docs rather than the code, splitting the two cases on that page and adding the field to the other, since the behaviour matches the repo's own test.

Suggested labels: documentation