Feature Flags Need Cleanup Expectations, Not Just Naming Conventions

A flag named new-checkout-flow tells an engineer what it probably controls. It does not say when cleanup starts, which branch should remain, which metrics matter, or which downstream systems must be checked.

That missing policy is why teams can have clean naming and still accumulate stale flags. A coding agent can search a name, but it still needs a cleanup expectation to decide whether the flag is removable, active, or blocked by missing evidence.

Release flags, experiment flags, operational flags, permission flags, migration flags, and configuration flags should not share one cleanup rule. They have different purposes and different end states.

A release flag might be reviewed 30 stable days after 100% rollout. An experiment flag should be removed after the decision and losing variants are no longer needed. A permission flag may be a long-lived business rule that is reviewed when packaging changes.

FeatBit stores useful evidence such as tags, creation time, rollout state, audit history, and experiment state. The cleanup policy itself should live in repository rules such as AGENTS.md, a project skill, or another file your coding tools read before making changes.

This turns cleanup from a remembered norm into an executable contract. The same rule can guide a developer review, an agent-assisted implementation, and a later cleanup pull request.