[posthog]

Why

The capture spec says server SDKs stamp $feature/<key> and $active_feature_flags onto an event, but never says where those properties sit in the property merge order — the server bullet of Behavior step 4 does not list them at all. The one precedence requirement in the spec is client-only, and #143 keeps it that way, so nothing covers the server side.

Two SDKs converged on the same order this week, which makes it a contract rather than an implementation detail.

Source changes

• posthog-python#1121 — moves flag properties into the SDK-values layer on v1, so the call's properties, context tags and super_properties all win over them (matching 7.x).
• posthog-go#392 — documents the same order for v2: flag properties fill under the event's Properties, the request context and DefaultEventProperties.
• posthog-node merges buildFlagEventProperties(...) before the event's own properties in packages/node/src/client.ts, so the caller wins there too.

Changes

• New capture requirement Server SDKs add feature flag properties as defaults: on server SDKs the flag properties fill only the keys left unset by the event's own properties and, where the SDK has them, the ambient request context and the SDK-level default/super properties. $active_feature_flags replaces rather than merges, and the properties are stamped before before_send.
• Behavior step 4's Server bullet and the Feature flags entry under Interactions now name the flag properties, so the ordering is visible where the merge is described.
• Change proposed, applied and archived on this branch under openspec/changes/archive/2026-10-25-server-flag-property-precedence/.

openspec validate --specs --strict gives the same totals as main (31 passed, 36 failed — all pre-existing long-requirement warnings), and capture reports no errors beyond those warnings.

Uncertain / left out

• Scenarios are spec-only. They follow the existing @server scenarios of the release-identifier requirement (descriptive, asserting on the enqueued event) and are not tagged @sdk:server, because no adapter-backed harness run has verified them. No acceptance/ file changed.
• Caller vs. SDK-level defaults is deliberately untouched. The spec currently says super_properties / DefaultEventProperties apply after the caller's properties; posthog-python 8.0 and posthog-go v2 reverse that, while posthog-dotnet and posthog-elixir still match the spec. That is a separate contract change and needs a human decision — see the open question in design.md.
• posthog-go 1.x's SendFeatureFlags path overwrites a value set on the event or in the request context, so it is non-conforming until v2. Tracked in posthog-go.

---

Created with PostHog Desktop

🤖 Generated with Claude Code