Custom Flag Libraries

A private SDK or wrapper needs more than a method-name match before FlagShark can safely rewrite or remove its calls. Your library may add context, defaults, caching, initialization or side effects that must be preserved.

Detection configuration

The shallow providers entries in .flagshark.yml describe custom detection patterns. They help find usage; they do not authorize migration or cleanup and do not establish runtime provider state.

Semantic migration profiles

The platform has data-only migration profile foundations for package/import identity, client provenance, argument roles, types, invocation and lifecycle semantics, plus fixtures. Repository profiles can be discovered under .flagshark/migration-profiles/ or explicitly included by .flagshark/migration-profiles.yml:

schemaVersion: 1
includes:
  - migration-profiles/acme-node.yml

This is an include manifest, not a complete semantic profile. Profile contents must match the supported schema and compiler contract. Ask for a scoped profile assessment with representative source and dependency versions before relying on the migration path.

As of September 9, 2026, repository-authored profiles start as unverified workspace assessment input. Passing your own fixtures does not grant publication, verified cleanup or general support. Approval helpers and conformance exist, but a complete self-service profile approval workflow and universal production dispatch are not available.

What to provide for scoping

• The library package/version and representative imports, client initialization and calls.
• How flag keys, defaults and context are supplied; sync/async behavior and possible side effects.
• Which service supplies values, with the project/environment relationship described without credentials.
• Examples of expected behavior, tests and unsupported patterns you already know about.

A call named isEnabled is insufficient evidence of boolean/default/context semantics. Dynamic keys, ambiguous receivers, hooks and wrappers remain bounded by the actual assessed contract.

Planned extension model

The design separates language frontends, source API profiles, runtime backend integrations, OpenFeature target/provider setup, retirement recipes and validation. This should allow new languages and APIs to join the existing lifecycle through versioned registrations and conformance.

Customers should eventually be able to choose an explicitly supported strategy: rewrite their library's call sites, or retain their API while migrating its implementation. Neither strategy is inferred automatically. Arbitrary uploaded executable plugins and a plugin marketplace are not current features.

Start with OpenFeature adoption for the available migration path. Broader detection support does not imply safe transformation support.