<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Collaborate/take over this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=607676) </details> <!--IssueSummary end--> Phase A. Decides whether Beta gets a catalog-visibility gate at all. ## Problem This issue was originally framed as *preserving* the Beta gate once the project setting is gone. Verification against the code shows the flag never gated catalog visibility in the first place: - `recommend_reviewers/v1` declares no `feature_flag` (`ee/app/models/ai/catalog/foundational_flow/items.rb:186-205`), so the flow is **already visible today** to every group with beta flows enabled — `available_for_group` only applies beta/ultimate gating plus `blocked_by_feature_flag?`, which is a no-op without a declared flag (`foundational_flow.rb:38-48`). - The `merge_request_ready` trigger worker is not flag-gated either, so those groups can already create the trigger and execute the flow — currently without `reviewer_data` ([#607673](https://gitlab.com/gitlab-org/gitlab/-/work_items/607673)). What `dap_powered_recommend_reviewers` actually gates today is the bespoke execution branch in `MergeRequests::AutoAssignReviewersWorker` (via `Project#dap_powered_recommend_reviewers_available?`, project actor) and the settings-page radio group. Once the setting and bespoke path are removed, that method goes with them and the flag gates nothing. So the decision here is whether Beta **should add** a catalog gate, not whether to preserve one. `/cc` `@phikai` — if the current ungated availability is acceptable for Beta, this issue can be closed and the flag retired in Phase D ([#607679](https://gitlab.com/gitlab-org/gitlab/-/work_items/607679)). ## Implementation (if a gate is wanted) — with verified blast radius Declare the flag on the item, matching the single existing precedent (`business_context_security_guidelines/experimental` → `feature_flag: "sdlc_context_agent_trigger"`, `items.rb:293`): ```ruby # ee/app/models/ai/catalog/foundational_flow/items.rb (recommend_reviewers/v1 block) feature_flag: "recommend_reviewers_flow", ``` **This is a hard availability gate, not cosmetic visibility.** `blocked_by_feature_flag?` (`foundational_flow.rb:58-64`) has three callers, and one of them blocks execution: 1. `EE::Groups::SettingsHelper#available_foundational_flows_json` (`settings_helper.rb:222`) — flow disappears from the group Duo settings list. Actor: the root group. 2. `Ai::Catalog::ItemConsumerPolicy` condition `foundational_flow_feature_flag_disabled` (`item_consumer_policy.rb:88-93, 119-127`) — **prevents `:execute_ai_catalog_item`, `:read_ai_catalog_item_consumer`, and `:admin_ai_catalog_item_consumer`**. `Ai::Catalog::Flows::ExecuteService#allowed?` checks `:execute_ai_catalog_item` (`flows/execute_service.rb:65-67`), so a disabled flag **stops trigger-driven runs**, not just visibility. Actor: `project&.root_ancestor || group&.root_ancestor`. 3. `EE::Groups::UpdateService#strip_feature_flag_gated_foundational_flows!` (`update_service.rb:479-484`) — silently drops the flow from `enabled_foundational_flows` on group-settings save. Actor: root group. The bespoke path is **not** affected by an item-level flag (`CreateAndStartWorkflowService` checks only `flow_configured_for_container?`, not the policy), so existing `dap_powered` rows keep working through Phases B–C regardless. **Use a fresh flag, not `dap_powered_recommend_reviewers`.** Through Phases B–C the existing flag still gates bespoke runtime with a **project** actor, while all three call sites above evaluate with a **root-group** actor. Reusing it means one flag, two actor types, two meanings that need flipping independently. Flag YAML template (`ee/config/feature_flags/gitlab_com_derisk/recommend_reviewers_flow.yml`, patterned on `sdlc_context_agent_trigger.yml`): ```yaml --- name: recommend_reviewers_flow description: Gates availability of the Recommend Reviewers foundational flow in the AI catalog feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/work_items/607676 rollout_issue_url: <new rollout issue> milestone: '19.4' group: group::code review type: gitlab_com_derisk default_enabled: false ``` **Rollout sequencing is the risky part.** The flag defaults off, and via caller 2 that blocks execution — so before merging, every group currently relying on the flow (trigger-based setups **and** the root groups of the `dap_powered` projects on [#602418](https://gitlab.com/gitlab-org/gitlab/-/issues/602418)) must be enabled by **root-group actor**. Get the group list from the Phase C audit ([#607678](https://gitlab.com/gitlab-org/gitlab/-/work_items/607678)) or `Ai::FlowTrigger` rows joined to the recommend_reviewers item consumer. ## Acceptance criteria - [ ] Product decision recorded: does Beta need a catalog gate at all? - [ ] If yes: `recommend_reviewers/v1` declares a fresh `feature_flag`, all three call-site behaviours verified per group (settings list, policy/execution, enabled-flows stripping), and every currently-functioning group enabled before the flag ships - [ ] If no: issue closed, and the flag retirement noted on [#607679](https://gitlab.com/gitlab-org/gitlab/-/work_items/607679)