Limit AI Governance agent-class filter to DAP behind a feature flag

Dependency: stacked on !254043 (closed), target branch will change

This MR targets djadmin/aigov-agent-class-ranked-cards, not master. That branch is the source of !254043 (closed) (Segment Developer activity and Project exposure by agent class). Both MRs touch dashboard_app.vue, so this one is stacked on top to avoid a conflict.

  • !254043 (closed) must merge first.
  • Once it merges, this MR's target branch should be retargeted to master.

What does this MR do and why?

The AI Governance dashboard's agent-class control offers "All agents | DAP | Connected", backed by the AiGovernanceAgentClass GraphQL enum (ALL, INTERNAL_DAP, EXTERNAL). The 19.4 release is a limited beta scoped to DAP only. Connected agents (Claude Code, OpenCode) are deferred to 19.5, and their session ingestion isn't fully in place yet, so a "Connected" option would just show an empty view today.

This MR gates the wider filter behind a new feature flag so the beta ships DAP-only, with the full filter ready to switch on once 19.5 lands.

Changes:

  • Adds feature flag ai_governance_connected_agents_filter (ee/config/feature_flags/wip/ai_governance_connected_agents_filter.yml, type: wip, default_enabled: false, milestone 19.4, group group::compliance).
  • Pushes the flag to the frontend from both governance controllers: ee/app/controllers/groups/settings/gitlab_duo/governance_controller.rb and ee/app/controllers/projects/settings/gitlab_duo/governance_controller.rb.
  • In dashboard_app.vue: with the flag off, the control renders a single "DAP" option and every query sends agentClass: INTERNAL_DAP. With the flag on, the full "All agents | DAP | Connected" set returns and the default goes back to ALL.

The control still shows with one option rather than being hidden. That's a product decision: it keeps the segmentation visible and makes the scope of the beta explicit to users.

Implementation note: why agentClass became a computed property

The default value now depends on the feature flag, but Vue 2 runs data() before computed properties, so glFeatures isn't readable inside data(). To work around that, selectedAgentClass is a plain data field initialized to null, and agentClass is a computed property with a getter and setter:

  • Getter: returns selectedAgentClass if the user picked something, otherwise falls back to the flag-dependent default.
  • Setter: writes straight to selectedAgentClass.

This keeps v-model on the control working unchanged while letting the unselected default follow the flag.

Caveat: rubocop not run locally

Local Ruby tooling in this environment can't load gems (Bundler::GemNotFound), so rubocop could not be run against the two controller changes. Each change is a single added line matching the pattern of the adjacent lines. CI will be the first real rubocop run against them.

References

Screenshots or screen recordings

Pending.

Before After

How to set up and validate locally

  1. Enable the dashboard for a group:
    Feature.enable(:ai_governance_dashboard)
  2. Visit the group's GitLab Duo governance settings page, dashboard tab.
  3. Confirm the agent-class control shows only "DAP", and that the summary and card queries all use INTERNAL_DAP.
  4. Enable the new flag:
    Feature.enable(:ai_governance_connected_agents_filter)
  5. Reload the dashboard tab and confirm all three options ("All agents", "DAP", "Connected") are offered, and the default selection is "All agents".

Tests

ee/spec/frontend/ai/governance/components/dashboard passes, 78 examples. The existing suite's default glFeatures now sets aiGovernanceConnectedAgentsFilter: true so the pre-existing ALL-based assertions keep their meaning.

Added a describe('with the connected agents filter disabled') block covering:

  • DAP is the only option offered by the control.
  • The metrics query sends agentClass: INTERNAL_DAP.
  • Both the Developer activity and Project exposure cards receive INTERNAL_DAP.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Dheeraj Joshi

Merge request reports

Loading
Loading