feat(feature-flags): Handle all feature flag lifecycle events

[stanleyphu]

Why

Namespaced feature flag events currently fall through to raw snake_case data, and callers cannot use their names in typed Events API filters. All eight flag, rule and target lifecycle events now produce typed camelCase data and context through event listing and verified webhooks. Flag owner/environment fields, update history, optional rule actors, and both historical value-bearing targets and current rule memberships are preserved.

This draft targets codex/auth-7099-rule-management to reuse the management resource contracts and should retarget main after those resources land. Delivery still depends on the event launch: webhook subscription enums need published-spec regeneration, and rule-update webhook delivery needs API catalog registration.

Not covered by CI

• Ran the new boundary suite against the previous SDK: 26 new-contract checks failed because payloads remained snake_case; all four historical event checks passed. All 30 checks pass after the change.
• Exercised the built Node ESM/CJS and worker ESM/CJS entrypoints with all eight names, both target formats, Events API fixture responses and independently signed webhook bytes. All four entrypoints passed.
• Compiled an external consumer against built Node and worker declarations, including all eight exported event interfaces, typed filters and discriminant narrowing.

Proof

A signed fixture containing feature_flags.flag_target.created with rule_id: "flag_rule_test", environment_id: "environment_test", target_id: "org_test" and context client_id: "client_test" returns data.ruleId, data.environmentId, data.targetId and context.clientId. The membership result omits value; the historical target result retains valueType: "boolean" and value: false and omits ruleId. Listing the same fixture produces the identical event in all four built entrypoints.

These checks use API-schema fixtures and local signatures, not live webhook delivery. Before release, verify actual delivery and published subscription enums when the event launch is enabled.

Fixes AUTH-7214

[linear-code]

AUTH-7214

[stanleyphu]

@greptileai review

[stanleyphu]

@greptileai review this draft

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds feature flag event types and deserialization.

The draft's SDK parsing changes appear safe to merge, with no actionable defects found.

What we checked:

• Historical events keep their shape: The historical names still use deserializeFeatureFlag. Their context still comes from the unchanged shared event fields.
• Webhooks still verify first: constructEvent awaits the signature check before parsing the payload or calling deserializeEvent.

Summary

Adds typed support for all eight namespaced feature flag lifecycle events through the Events API and verified webhooks.

• Converts event data and context to camelCase.
• Preserves flag owners, sparse update history, optional rule actors, and both target formats.
• Adds boundary tests and usage guidance. Historical flag.* conversion remains unchanged.
• No actionable issues were found. Tests were inspected, not executed during this review.

Acknowledged by stanleyphu: webhook subscription enums await published-spec regeneration, and rule-update webhook delivery awaits API catalog registration. The PR description explicitly defers these launch requirements and live-delivery checks.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Events API response] --> D[deserializeEvent]
  B[Webhook payload] --> C[Verify signature]
  C --> D
  D --> E[Namespaced flag conversion]
  D --> F[Existing historical flag conversion]
  E --> G[Typed event with camelCase fields]
  F --> H[Historical event shape]

Loading

_{Reviews (1) · Last reviewed commit: "feat(feature-flags): Handle all feature ..." · Reviewed by Greptile}