Start Duo Developer from a work item status change

What does this MR do and why?

The Developer foundational flow can now start from a flow trigger with the Work item event and the Status changed action. This trigger and an assignment of Duo Developer to a work item now use one goal, and both give the agent the Workplan of the work item.

Before this change, a status change trigger for Developer saved, but it did not start a session. Ai::Catalog::GoalTemplates::Developer.handler_for raised ArgumentError for the work_item event, and Ai::CloudEventsFlowTriggerWorker sent the error to error tracking only. An assignment started a session, but its goal did not give the agent the Workplan.

Changes:

• Add Developer::ImplementWorkItem. handler_for uses it for the assign event on a resource that is not a merge request, and for the work_item event with the status_changed action. It replaces Developer::AssignIssue. Other work_item actions, such as created, still raise.
• The text is based on the AssignIssue goal, with these changes:
  • The opening line is neutral: "@user asked you to solve the following work item". The goal does not name the status.
  • The bug-only wording is now: "If it is a bug, find the root cause. Otherwise, work out what the change requires."
  • "the issue" is now the name of the resource type, so the text fits every work item type.
• Rails decides how the Workplan reaches the agent:
  • No Workplan: the goal does not mention it.
  • A Workplan of up to 60,000 characters and 120 KiB: the goal includes it. Tags that could close the <workplan> block are removed.
  • A larger Workplan: the goal gives the command that fetches it. The REST API does not return the Workplan. The query is a constant, and a spec validates it against the GraphQL schema.
  • A larger Workplan on a work item without a project: the goal does not mention it, because the query needs a project.
• With a Workplan, the agent follows it, and it states each deviation and its reason in the merge request description. It still reads the description and comments for context. If the description and the Workplan disagree, it follows the Workplan, because the Workplan is the result of planning.
• The limits keep the goal under Workflow::GOAL_MAX_LENGTH (65,536 characters) and Workflow::GOAL_MAX_BYTESIZE (127 KiB). A spec checks the goal at both limits. The Developer flow accepts no trigger goal, so the limits leave no room for one.
• Base.interpolate now fills all placeholders in a single pass. User text in any variable stays literal, whatever the order of the variables. This applies to every goal template, so one run_service_spec example now checks the single-pass result.
• ExecuteWorkItemStatusChangedWorkflowTriggersWorker passes the username from the event. For this, CloudEventsFlowTriggerWorker#additional_run_params also receives the cloud event. ExecuteMergeRequestMergedWorkflowTriggersWorker, the only other override, uses the new signature.
• Document the status change trigger and the Workplan support in doc/user/project/merge_requests/developer.md.

Not in this MR:

• supported_events for the Developer flow definition. Developer continues to accept every event type when a trigger is saved.
• A feature flag:
  • The status change trigger did not start a session before this change.
  • The assignment goal changes for every assignment. Without a Workplan, the change is small. With a Workplan, the agent now gets it, which is the intended behavior. An owner of the Developer flow agreed to ship this without a flag: !261053 (comment 3986653143).

This MR takes over the Developer part of the proof of concept in !254378, with the agreement of its author. The shared goal comes from the review in !261053 (comment 3985896314).

References

• Closes #633027
• Proof of concept: !254378
• Status filter for work item triggers: #607577 (closed)

Screenshots or screen recordings

Not applicable. This is a backend change.

How to set up and validate locally

1. In a project with the Developer flow turned on, create a work item. Add a Workplan to it.
2. Create a trigger for the Developer flow:
   • Event type: Work item.
   • Action: Status changed, and no other action.
   • Status: a status of your choice, for example In progress.
3. Change the status of the work item to that status.
4. In the left sidebar, select AI > Sessions, and open the new Developer session. Make sure that:
   • The goal contains the Workplan.
   • The merge request follows the Workplan, and it is assigned to you.
5. Assign Duo Developer to a second work item that has a Workplan. Make sure that the goal of the new session contains the Workplan.
6. Remove the Workplan from a third work item, and change its status. Make sure that the goal does not mention a Workplan.
7. Add a Workplan of more than 60,000 characters to a fourth work item, and change its status. Make sure that the goal contains the fetch command, and that the agent fetches the Workplan before it writes code.

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.

🤖 Generated with Claude Code