Automated Cleanup PRs
Understand eligibility, draft review, and the exact support boundaries for removing obsolete flag code.
FlagShark can propose source changes that remove eligible feature-flag evaluations and simplify obsolete branches. Every operation depends on a supported source pattern, trustworthy terminal-value evidence and your workspace policy. Human review and merge remain part of the workflow.
Current support boundaries
As of September 9, 2026, the source registry has no generally available retirement cell. Access and eligible stages are controlled by the assessed capability and workspace admission. The retirement support matrix exposes exact registered boundaries.
| Path | Current source capability | Important boundary |
|---|---|---|
| OpenFeature JavaScript/TypeScript on Node | Inventory through draft PR for bounded literal-key boolean/string calls | Full CI/post-merge verification certification is not registered for this cell |
| LaunchDarkly Node version-2 retirement candidate | Narrow awaited boolVariation contract with stronger validation/verification gates | Candidate, not GA; exact versions, arguments and syntax apply |
| Other languages/APIs | Exact cell and recipe dependent | Detection and Piranha parser availability do not establish complete cleanup support |
The stronger LaunchDarkly candidate does not certify OpenFeature removal. A separate TypeScript boolean-call candidate now has local compiler-backed constant-key, validation and post-merge verification coverage; it remains unpromoted. Automatic cleanup also needs current deployment-to-provider binding, terminal-state evidence and pilot admission. Missing authority blocks publication. Consult the assessed support contract before expecting OpenFeature adoption to proceed directly into cleanup.
How a candidate becomes a proposed change
- Refresh repository inventory and bind the source to an immutable revision.
- Check the supported call shape and workspace controls, including permanent flags, exclusions, pause and age policy.
- Establish an authoritative terminal value from the configured backend evidence. A flag being old is not enough. Unknown or stale evidence blocks automatic retirement.
- Apply the exact registered recipe to a pinned source snapshot, inspect the proposed diff and account for residual usage.
- Run the validation stages supported and required by that contract. Publish a draft only when its admission, permissions and gates allow it.
- Review the diff and CI, then merge through your normal process. Where the cell supports post-merge verification, check actual default-branch evidence; otherwise do not treat the result as verified cleanup.
Drafts and review
Current pre-GA cleanup paths enforce draft PRs. A workspace preference does not override a capability's draft-only gate. Draft status also does not guarantee CI will wait: your GitHub workflows determine when checks run.
Review the retained terminal branch, argument effects, initialization, dependencies and remaining usages. Unsupported calls can block a change rather than being removed optimistically. A successful transform does not guarantee every helper or import can be deleted safely.
CI failure, source drift, permission loss and unsupported residuals must remain visible. A merged PR alone is not proof that a flag is absent from all source or all environments.
Source removal and provider state
Cleanup removes admitted source usage. It does not silently delete the flag definition from LaunchDarkly or another provider. Review provider archival separately after establishing that no required consumers remain.
Ongoing operation
Scheduling and deduplication exist, with policy and provider-readiness gates. The complete advertised post-migration loop still needs integrated certification: verified adoption, durable enrollment, OpenFeature retirement and repeated cycles. Do not interpret a dashboard health indicator as proof that every one of those steps is enabled.
See how the engine works, branch protection and custom libraries.