Distill agent memory when a merged MR triggers the Developer flow

Junming Huangrequested to merge
feature/mr-merged-trigger-memory-distillation into master

What does this MR do and why?

Makes the merged-MR Developer flow trigger useful and safe:

  1. Gate on an existing session — only fire when the merge request already has at least one developer/v1 session, so merging an unrelated MR no longer starts a brand-new flow.
  2. New goal: distill agent memory — instead of posting a change-summary note, the goal now instructs the agent to analyze the MR's past Developer session traces and persist learnings into repo memory (AGENTS.md, agent skills, env config) via a follow-up MR.

The worker already queries the sessions for the gate, so it forwards their IDs into the goal through a new additional_run_params hook on the shared CloudEventsFlowTriggerWorker concern (default {}, other workers unaffected).

Everything stays behind the merge_request_merged_flow_trigger feature flag (disabled by default).

close gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#2529 (closed)

How to set up and validate locally

  1. I have a stacked testing MR for end-to-end testing. Checkout branch in !249523
  2. Run the command as suggested: bundle exec rails runner scripts/duo/merged_trigger_demo.rb
  3. Watch the developer session finish and pushed the fix
  4. Then merge the MR
  5. You will see a developer flow is triggered that distill learnings and proposed a new MR to improve the repo harness AGENTS.md

Database query

The worker runs this query on every merged-MR event (when the flag is enabled):

SELECT id
FROM duo_workflows_workflows
WHERE merge_request_id = $1
  AND workflow_definition = 'developer/v1'
ORDER BY id DESC
LIMIT 20;

Index used: index_duo_workflows_workflows_on_merge_request_id (btree (merge_request_id)).

PostgreSQL uses the merge_request_id index to narrow the scan to rows for the given MR, then filters by workflow_definition in memory. In practice a single MR will have at most a handful of Developer flow sessions, so the post-index filter is negligible. A composite index on (merge_request_id, workflow_definition) would be marginally more efficient but is not warranted at this traffic level.

MR acceptance checklist

Evaluated against the MR acceptance checklist.

Edited by Junming Huang

Merge request reports