Move dependency_bump_web_search feature flag to ops type

What does this MR do and why?

Converts the dependency_bump_web_search feature flag from beta type to ops type.

File changes:

  • Moves ee/config/feature_flags/beta/dependency_bump_web_search.yml to ee/config/feature_flags/ops/dependency_bump_web_search.yml
  • Changes type: beta to type: ops
  • Rewrites description to state when an operator would turn the flag off

The flag is wanted as a long-lived kill switch, not a rollout flag. Reasons to turn it off: web search driving up LLM cost or flow latency, or degradation of the upstream web search provider.

There is no behavior change. default_enabled stays true, milestone stays 19.2, and the push to the AI Gateway in ee/lib/api/helpers/duo_workflow_helpers.rb is untouched. The flag is not read by Rails logic at all; it is only forwarded to the AI Gateway as a header, and the gateway does the gating. If the flag were removed outright instead of converted, the gateway would stop receiving the header and web search would silently turn off, with no deliberate way to disable it later.

References

Screenshots or screen recordings

Not applicable. Feature flag definition change only, no UI surface.

How to set up and validate locally

Behavior is unchanged, so validation is a check that the definition still resolves the same way:

  1. Confirm the definition loads with the new type:

    d = Feature::Definition.get(:dependency_bump_web_search)
    d.path   # => ee/config/feature_flags/ops/dependency_bump_web_search.yml
    d.type   # => "ops"
    d.validate!
  2. Confirm the flag still resolves as enabled by default:

    Feature.enabled?(:dependency_bump_web_search) # => true
  3. Confirm the flag is still pushed to the AI Gateway in ee/lib/api/helpers/duo_workflow_helpers.rb.

Both checks above were run locally and returned the expected values, and ee/spec/lib/api/helpers/duo_workflow_helpers_spec.rb plus spec/lib/feature/definition_spec.rb pass (65 examples, 0 failures).

MR acceptance checklist

  • Tests: no new specs. No production code changes, and existing specs assert the push list without naming this flag.
  • Documentation: none needed. doc/administration/feature_flags/list.md is auto-generated from the YAML definitions during the docs build. The version history entry in doc/user/application_security/dependency_scanning/agentic-breaking-change-resolution.md stays accurate because the flag still exists.
  • Changelog: Changelog: other with EE: true is on the commit. Danger requires a changelog entry whenever a feature flag definition file is deleted, and moving the file between type directories deletes the old path, so the trailer is required even though nothing changes for users.
  • Database, security, performance: not applicable.

🤖 Generated with Claude Code

Merge request reports

Loading
Loading