<!--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> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=602777) </details> <!--IssueSummary end--> ## Consolidate MR Ready and Code Conflict triggers as configuration ### Summary Consolidate the **MR Ready** (`merge_request_ready`) and **Code Conflict** triggers into a unified, configuration-driven approach for flows and agents, consistent with how other event triggers (e.g. MR Approved, pipeline events) are surfaced under `Automate > Triggers`. ### Background Event triggers are being introduced incrementally for flows and agents. The **MR Approved** trigger configuration UI is tracked in [#600519](https://gitlab.com/gitlab-org/gitlab/-/work_items/600519). The **MR Ready** trigger backend was implemented in [#592454](https://gitlab.com/gitlab-org/gitlab/-/work_items/592454) (behind the `merge_request_ready_flow_trigger` feature flag, see [#598421](https://gitlab.com/gitlab-org/gitlab/-/work_items/598421)). Rather than maintaining bespoke handling per trigger type, the MR Ready and Code Conflict triggers should be expressed as configuration so they appear and behave consistently in the **New Trigger** form alongside other trigger types. ### Problem Without consolidating these triggers as configuration: * Each trigger type requires custom UI/handling, increasing maintenance overhead * The trigger selection experience is inconsistent across MR Ready, Code Conflict, MR Approved, and pipeline events * Adding future triggers requires duplicating logic instead of extending configuration ### Proposed Solution * Define **MR Ready** and **Code Conflict** triggers as configuration entries (consistent with the pattern used for MR Approved and pipeline event triggers) * Surface both as selectable trigger types in the **New Trigger** form under `Automate > Triggers` * Ensure each trigger persists and displays correctly when viewing an existing configuration * Provide appropriate help text describing when each trigger fires ### Acceptance Criteria - [ ] **MR Ready** and **Code Conflict** triggers are defined as configuration rather than bespoke handling - [ ] Both triggers are available as options in the New Trigger form - [ ] Selecting either trigger shows appropriate configuration UI and help text - [ ] Each trigger is persisted and displayed correctly when viewing an existing trigger - [ ] Behavior is consistent with other event triggers (MR Approved, pipeline events) /cc Related to [#600519](https://gitlab.com/gitlab-org/gitlab/-/work_items/600519)