Add a goal field to each flow trigger condition

What does this MR do and why?

A goal tells a flow what to do when a trigger condition is met. Goals are stored per event type. The condition form edits one event type at a time, so the goal field belongs there. That form is shared, so the field appears both on the trigger page and in the catalog enable modal.

The goal travels through both save paths. The trigger form sends it as goals. The enable modal sends it as triggerGoals, which ai_catalog_item_show must forward, because it names each key it copies into the mutation input.

The edit page query now maps goals. Without it, the form loads an empty set, and a save with no edits erases the stored goals.

The merge_request fold helpers now fan the goal out. One visible merge_request card can split into up to three event types on save. The goal has to follow each one, or goal_keys_match_event_types refuses the write. The helpers collapse the goals again on load.

The query selects acceptsTriggerGoal through inline fragments. The field is on the concrete flow types, not on the item interface, so a query that asks for it on the interface gets nothing back. A foundational flow sets the field to false, and the goal field stays hidden.

The form clears the goals when the chosen flow stops accepting one. The field hides, but the value would otherwise stay in the payload. The model would then refuse the write, and you could not fix it from the form.

The textarea has no maxlength. That truncates a long paste in silence. The form reports the 4096 character limit instead, and blocks the save.

The collapsed condition row now shows the goal. The goal was visible only after you open the card, so a saved goal read as lost.

This MR also adds a "Goals" section to the trigger documentation.

The feature flag ai_flow_trigger_goals is off by default. The project controller pushes it. The group controller does not need it, because it renders no trigger form. The Explore controller pushes it too, for the enable modal, with current_user as the actor. The model checks the flag against the container. Explore has no project until the user picks one in the modal, so the two actors cannot agree. Please turn the flag on for everyone rather than for a share of actors.

The form adds or changes no goal while the field is hidden. The model accepts a goal that is removed while the flag is off, but not one that is added or changed, and the author cannot see the field to repair a refused write. So an edit drops a hidden goal when the event type changes, and the submit sends no goal that is not already stored.

One merge_request card holds one goal, and that card can cover up to three event types. Their goals collapse onto the card on load, and a goal already on merge_request wins. Two of those event types hold different goals only if the API wrote them, because the form always writes them together. #632627 tracks a goal for each action.

This is MR 4, the last in the stack. Every earlier MR is merged.

• !256658 (merged) added the goals column and its validations.
• !257218 (merged) composes the goal at dispatch time.
• !258739 (merged) added the goals GraphQL field and the trigger mutation arguments.
• !260002 (merged) added triggerGoals to the item consumer mutations.

References

• Work item: #627896
• MR 1: !256658 (merged)
• MR 2: !257218 (merged)
• MR 3: !258739 (merged)
• MR 3.1: !260002 (merged)

Screenshots or screen recordings

	Before	After
Enable flow modal
Edit trigger page
Edit trigger page (editing)

How to set up and validate locally

1. Turn the feature flag on in the Rails console: Feature.enable(:ai_flow_trigger_goals).
2. Create a custom flow in the AI catalog.
3. Open a project. Go to Automate > Flows. Turn the flow on.
4. In the enable modal, add a trigger condition. Fill in the goal. Save.
5. Go to Automate > Triggers. Confirm the goal shows on the collapsed condition row.
6. Edit the trigger. Confirm the goal shows in the condition form.
7. Save the trigger with no edits. Confirm the goal is still there.
8. Add a merge request condition with a goal. Save, then edit again. Confirm the goal is still on that condition.
9. Change the flow to a foundational flow, for example Code review. Confirm the goal field goes away.
10. Paste more than 4096 characters into a goal. Confirm the form shows the limit and blocks the save.
11. Turn the flag off. Confirm the goal field goes away.

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.