Retire obsolete feature flags while preserving behaviour

Why use this

1. A flag that appears always enabled may still shape test fixtures, emergency controls or behavior in a less visible environment. Removing its branch can simplify code only if the intended surviving behavior and every relevant dependency are understood.

2. A retirement-review manifest could connect each flag to its approved state, dependent paths and evidence needed for removal. Engineers could evaluate the cleanup scope without treating a dashboard setting or passing local checklist as proof that all consumers are safe.

Why an agent / simpler alternative

Useful judgment

Trace flag references and identify hidden assumptions across tests, configuration and shared code.

Simpler alternative

Remove a single well-understood flag manually when its consumers and retirement decision are already documented.

Unsuitable when

The flag's lifecycle owner or behavior across environments is uncertain.

Proposed inputs

1. Name

   Flag retirement inventory

   Owner

   Feature owner

   Minimum scope

   Fictional flag IDs, approved intended states and environment scope

   Quality check

   Separate retirement approval from a temporarily enabled setting.

2. Name

   Dependency sample

   Owner

   Maintainer

   Minimum scope

   Code-path descriptions, test references and configuration consumers

   Quality check

   Identify fallback, emergency and downstream uses.

Access and setup — proposed or unknown

Proposed minimum

1. Offline flag/dependency descriptions and a proposed cleanup map.

Compatibility unknowns

1. Unknown: current runtime, flag-provider coverage, repository tooling and regression environment.

External actions requiring approval

1. Flag-state changes, code cleanup, shared pull requests, merge and production release.

Expected deliverable and review checks

Proposed artifact

Flag-to-consumer removal proposal with preserved behavior, unresolved dependencies and integration-review plan.

Critical checks

1. Every retired flag has an explicit owner-approved surviving behavior.

2. Test changes retain meaningful coverage instead of merely deleting failures.

Missing output evidence

No new workflow run or output inspection was performed for this overlay; use the canonical source-outcome references.

Failure signals and proposed responses

1. Signal

   A flag is enabled in production but differs in another supported environment.

   Why it matters

   Removing its branch could change behavior outside the main deployment.

   Proposed response

   Keep the retirement unresolved and ask the owner to confirm the full environment scope.

2. Signal

   A failing test is removed without explaining its dependency.

   Why it matters

   The cleanup may conceal a missed behavior rather than fix it.

   Proposed response

   Require a maintainer-reviewed coverage replacement or a justified retirement decision.

Effort and cost — unknown

Setup work

1. Identify flag owners, consumers and preserved behavior.

Ongoing review

1. Reconcile parallel changes and inspect later regression findings.

Unknowns

1. Unknown: hidden dependency coverage, cleanup effort and test costs.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A fictional flag manifest has conflicting environment states and a proposed test deletion with no coverage rationale.

Acceptance checks

1. Block premature retirement in the plan.

2. Require a dependency explanation without editing or running tests.

Stop conditions

1. Real flag access, repository changes, tests or release actions are required.

Limits

1. This proposed dependency review establishes no preserved runtime behavior or successful feature-flag cleanup.