[posthog]

Why

The on-feature-flags spec classifies Android and Flutter as readiness-only listeners that "expose
a readiness signal with no direct payload; callers re-read flags through getter APIs when notified".
Both SDKs changed that in their next majors, converging on the PostHogFeatureFlagsLoaded shape the
spec already records for posthog-ios 4.0, so the classification and both surface-variant entries are
now wrong.

What changed

Source SDK changes:

• PostHog/posthog-android#877 — 4.0 replaces
  PostHogOnFeatureFlags with PostHogFeatureFlagsCallback, whose loaded(...) receives a
  PostHogFeatureFlagsLoaded (flags, variants, errorsLoading). Both
  PostHogConfig.onFeatureFlags and reloadFeatureFlags(...) take it.
• PostHog/posthog-flutter#664 — 6.0 changes
  PostHogConfig.onFeatureFlags from void Function() to void Function(PostHogFeatureFlagsLoaded)
  and reloadFeatureFlags() from Future<void> to Future<PostHogFeatureFlagsLoaded>.

Spec updates:

• on-feature-flags: Android (4.0+) and Flutter (6.0+) move into the payload-carrying and
  error-aware groups, so the existing failed-load scenario now covers them. Unity stays
  readiness-only. Surface variants updated, with the pre-major shapes kept as history.
• on-feature-flags: new requirement Flags-loaded result on a payload-carrying listener — the
  three pieces of information a payload-carrying listener must carry, that a disabled flag is left
  out of the PostHogFeatureFlagsLoaded shape, and that the result describes the load on every
  invocation path rather than only a successful remote one. Two scenarios.
• reload-feature-flags: Android and Flutter surface variants and the Error-handling note updated;
  the existing Reload completion failure reporting requirement widened past iOS, with one added
  scenario for a reload that never issues its request because there is no usable distinct id
  (posthog-android#877 reports a blank distinct id as errorsLoading = true).

Validation

• openspec validate --specs --strict --no-interactive (CLI 1.4.1, as in CI): 67 passed, 0 failed.
• git diff --check is clean.

Specification only. No SDK conformance was executed.

Uncertain / needs review

• Both source PRs merged into their majors' integration branches (chore/v4-remove-deprecated,
  chore/v6-adopt-posthog-android-4), not main. The spec records them as 4.0+ / 6.0+, the same
  way posthog-ios 4.0 was recorded before release. If either API is still expected to change before
  the major ships, this should wait.
• The requirement deliberately does not impose one argument list. posthog-js passes
  (flags, variants, context) and is not known to omit disabled flags from variants, so the
  omit-disabled rule is scoped to the PostHogFeatureFlagsLoaded shape. Whether posthog-js should
  converge is a separate decision.
• Behavior item 5 (replaying current values to a late-registered listener) is left unchanged —
  carrying a payload is a different property, and neither SDK is recorded as doing that.
• Paths other than "no usable distinct id" that skip the flags request (disabled, opted-out SDK) are
  left SDK-specific; only the distinct-id case has cross-SDK evidence.
• The two new on-feature-flags scenarios reuse the existing payload-carrying /
  error-aware listener-class steps but add "the SDK passes its flag-loaded result as a
  PostHogFeatureFlagsLoaded" and "the result should not contain …", which need harness bindings.
• The posthog-android and posthog-flutter compliance rows are not touched here; left to the weekly
  compliance matrix.

Proposed, applied and archived on this branch under
openspec/changes/archive/2026-10-29-record-mobile-flags-loaded-result/.

---

Created with PostHog Desktop

🤖 Generated with Claude Code