<!--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=607673) </details> <!--IssueSummary end--> Phase A. Blocks [#603494](https://gitlab.com/gitlab-org/gitlab/-/work_items/603494) and the removal of the project setting. ## Problem The Recommend Reviewers flow needs `reviewer_data` (current reviewers, approval rules, ranked candidates) to do anything useful. That payload is produced by the flow item's `additional_context_resolver`: - `ee/app/models/ai/catalog/foundational_flow/items.rb:200-204` — `recommend_reviewers/v1` defines `additional_context_resolver` calling `Ai::DuoWorkflows::RecommendReviewers::ReviewerDataBuilder` `FoundationalFlow#resolve_additional_context_for` (`ee/app/models/ai/catalog/foundational_flow.rb:86-95`) is called from exactly one place: - `ee/app/services/ai/duo_workflows/create_and_start_workflow_service.rb:128` — the bespoke path The DAP trigger path never calls it. `Ai::FlowTriggers::RunService#additional_context` (`ee/app/services/ai/flow_triggers/run_service.rb:422-437`) returns early unless the resource is a `Ci::Pipeline`, then hardcodes pipeline and merge request URL context. So a trigger-driven run of Recommend Reviewers receives no `reviewer_data`, and the flow has nothing to reason over. This is not a latent gap. Neither the trigger worker nor the catalog item is gated by `dap_powered_recommend_reviewers`, so any group with beta flows enabled can configure the **Merge request > Marked ready** trigger today and get exactly these empty runs. ## Feasibility — verified, the transport already exists end to end Both paths converge on the same delivery mechanism, so no new plumbing is needed: 1. `RunService#start_catalog_workflow` already passes `additional_context:` (`run_service.rb:232`) → `Ai::Catalog::Flows::ExecuteService` (`ee/app/services/ai/catalog/flows/execute_service.rb:18, 89`) → `Ai::Catalog::ExecuteWorkflowService` (`ee/app/services/ai/catalog/execute_workflow_service.rb:29, 145`) → `Ai::DuoWorkflows::StartWorkflowService`, which serializes it into the `DUO_WORKFLOW_ADDITIONAL_CONTEXT_CONTENT` workload variable (`ee/app/services/ai/duo_workflows/start_workflow_service.rb:297, 550-579`). 2. The bespoke path uses the **same** `StartWorkflowService` and the same variable (`create_and_start_workflow_service.rb:42-45, 128`) — this mechanism carries `reviewer_data` in production today. 3. The envelope formats match: `resolve_additional_context_for` wraps the resolver's `Hash[category => content]` into the `[{"Category" => ..., "Content" => json}]` array that `serialized_flow_additional_context` expects and that `RunService` already builds for pipelines. 4. The flow formally consumes it: `duo_workflow_service/agent_platform/v1/flows/configs/recommend_reviewers/1.0.0.yml` in `gitlab-org/gitlab-ai-gateway` declares `flow.inputs: category: reviewer_data` (with an input schema) and binds `context:inputs.reviewer_data` in the `post_recommendation` and `assign_reviewers` components. Prior art: draft [!242137](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/242137) implemented this exact change in June (as an `additional_context_builder` hook, with passing specs) before `additional_context_resolver` existed on master (added by `cfe7397b52ae`, 2026-07-14, wired only into the bespoke path). This issue is effectively rebasing that MR's `RunService` half onto the resolver that now exists. ## Implementation In `ee/app/services/ai/flow_triggers/run_service.rb`, generalize `#additional_context` (currently lines 422-437): ```ruby def additional_context contexts = [] contexts.concat(pipeline_additional_context) if resource.is_a?(::Ci::Pipeline) contexts.concat(foundational_flow.resolve_additional_context_for(resource: resource)) if foundational_flow contexts.presence end ``` - Extract the existing pipeline envelopes into `pipeline_additional_context` unchanged. - `resolve_additional_context_for` returns `[]` for flows with no resolver (`context = {} → .map → []`), so every other foundational flow is a no-op — no behaviour change outside flows that declare a resolver. - The resolver is called with `resource:` only (no user), exactly as the bespoke path calls it — `ReviewerDataBuilder.build(resource)` needs no user context. - `foundational_flow` is already memoized in this service (`run_service.rb:404-409`). Specs: - `ee/spec/services/ai/flow_triggers/run_service_spec.rb` — trigger-driven run of a foundational flow with a resolver receives the envelopes; `Ci::Pipeline` resources get pipeline context unchanged (and merged with resolver output if the flow declares one); flows without a resolver get `nil` as today. - Reuse the spec shapes from !242137. ## Coordination / caveats 1. **Pending conflict:** unmerged commit `769b3540cf38` (Paulo Martins, security-review custom instructions) adds another one-off special case to this same method (`security_review_flow?` branch). The resolver approach subsumes it — `security_review/v1` could declare an `additional_context_resolver` calling `CodeReview::CustomInstructionsContextBuilder` instead. Coordinate before both land to avoid stacking special cases. 2. **Latent bug worth fixing in passing:** `StartWorkflowService#serialized_flow_additional_context` drops caller envelopes whose category collides with reserved categories using `envelope[:Category]` (symbol key, `start_workflow_service.rb:556-558`), but every producer builds string-keyed `"Category"` envelopes — the guard is currently a no-op. Normalize the key access while in there (or use `envelope["Category"] || envelope[:Category]`). 3. The resolver now runs in the Sidekiq trigger worker for every matching trigger fire; `ReviewerDataBuilder` does non-trivial work (approval rules, candidate ranking). This is the same cost the bespoke worker pays today, but it lands on the `ai_catalog_flows` queue instead — no action needed, just expected load shift. ## Acceptance criteria - [ ] A trigger-driven run of `recommend_reviewers/v1` receives the same `reviewer_data` additional context as the bespoke path - [ ] Existing pipeline additional context is unchanged for `Ci::Pipeline` resources - [ ] Flows with no `additional_context_resolver` are unaffected - [ ] Reserved-category guard in `serialized_flow_additional_context` works for string-keyed envelopes - [ ] Verified end to end on a real merge request, not only in specs