## Problem Today, `@duo` mentions in MR and issue comments trigger Duo Developer flows using a hardcoded pattern. The [Duo Messaging Service architecture (ADR 008)](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19020) introduces an adapter pattern with lifecycle hooks (:eyes: → :white_check_mark:/:x:) that would benefit GitLab comment mentions as well — providing consistent UX signals (reactions on comments), better error handling, and a shared orchestration path. However, the GitLab comment context differs from external messaging services in important ways: - The **project is already known** (the MR/issue belongs to a project) — no need for a `duo-workspace` project - The **service account** should be the existing Duo Developer service account, not a messaging-specific one - Reactions are Note reactions (GitLab API), not Slack API calls ## Proposal Explore refactoring the existing `@duo` mention trigger to use the messaging adapter pattern. ### `Adapters::GitLabComment` A new adapter implementing lifecycle hooks via the GitLab Notes/Reactions API: | Hook | GitLab behavior | |------|-----------------| | `deliver_result` | Post a reply note on the MR/issue | | `deliver_error` | Post an error note or system note | | `on_flow_started` | Add :eyes: reaction to the comment | | `on_flow_completed` | Remove :eyes:, add :white_check_mark: reaction | | `on_flow_failed` | Remove :eyes:, add :x: reaction + error note | ### `TriggerFlowService` flexibility The current `TriggerFlowService` hardcodes namespace resolution, workspace project creation, and service account creation. For GitLab comments, these need to be different: - **Project**: use the project the mention is in, not `duo-workspace` - **Service account**: use the existing Duo Developer service account for the project, not `duo-messaging-<namespace>` The proposed change is to add optional parameters to `TriggerFlowService` (e.g., `project:`, `service_account:`) that override the defaults when provided. This is a small refactor (\~20 lines) that keeps the current behavior as the default while allowing the GitLab comment adapter to supply its own context. ### Open questions - How much of `TriggerFlowService` can be reused vs. needs to be made configurable? - Should this share the same `CallbackWorker` path or use a different delivery mechanism? - Own feature flag, separate from `slack_duo_agent` This issue is exploratory — it captures the long-term direction for unifying mention handling across platforms. ## Related - Parent issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/590434 - ADR: https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19020