## Context Part of moving DAP project readiness into **Settings › General › GitLab Duo** per the Turn 4 design ([discussion](https://gitlab.com/groups/gitlab-org/-/work_items/22591#note_3614220179)). Split out of [#604766](https://gitlab.com/gitlab-org/gitlab/-/work_items/604766), which now covers only the Agent Platform and CI/CD runner rows. This row is separated because, unlike those two, it is not a plain read-and-render: it introduces a new endpoint, a permission, and a change to a service the still-live onboarding page shares. Stacks on top of that work. ## Scope The **Agent configuration file** row in the Required card, and the Generate action behind it. ### The row | State | Description | Action | |---|---|---| | file on default branch | `.gitlab/duo/agent-config.yml` is on the default branch. | **View file** | | generating | a session was just started from this page | **View session** | | merge request open | a merge request adding the file is open | **View merge request** | | flow execution off | waiting on a prerequisite | none | | absent | see the copy correction below | **Generate** | ### The Generate action - Re-home the setup endpoint under project settings. The current `POST` lives on `Projects::DuoAgentsPlatformController`, which is removed by [#607425](https://gitlab.com/gitlab-org/gitlab/-/work_items/607425). Hardcode the `init_execution_env` initializer rather than accepting an event type from params. - Preserve the gate the old controller applied through `check_access` but which is **not** inside `RunService`: DAP available **and** remote flows **and** Duo features. - `Ai::Catalog::Onboarding::RunService` is shared with the standalone onboarding page and currently requires `duo_agent_onboarding`. It needs to accept the readiness flag too, or the button renders and the request 404s. - Restore the `setup_duo_agent_onboarding` permission. **It does not exist on `master`** — it was defined only in a closed MR stack, so any call site would silently evaluate to `false`. - Gate on Duo Developer being resolvable for the project. Without a `developer/v1` consumer the request fails with *"Item consumer is required"*, which means nothing to a maintainer, so the action should not be offered. ## Two corrections the code forces **1. This file is not a blocker.** The mock counts it toward "5 of 5 required" under *"Agents can't run here until all five are in place"*. Flows run without it: - `lib/gitlab/duo_agent_platform/config.rb` returns `{}` for a missing file - `start_workflow_service.rb` errors only when the file **exists and is malformed** - the image resolves as `@workflow.image.presence || configured_image || instance_image`, falling back to the instance default The goal template itself says *"Without this file, every flow falls back to a generic container that does not include the project's language toolchain or dependencies."* The row must describe that, not claim agents cannot run. **2. Generate opens a _draft_ merge request**, but `config_present?` reads the default branch. Without handling that, the row keeps offering Generate while a draft MR is already open and produces duplicates. Detect the open merge request with the existing `MergeRequest.by_blob_path` scope via `MergeRequestsFinder` — not `Ai::Catalog::Onboarding::WorkflowTracker`, whose Rails.cache entry expires after 7 days while a draft MR can easily stay open longer. ## Acceptance criteria - [ ] Row renders each state above with the correct status icon - [ ] Copy describes the real failure mode, not a false blocker - [ ] Generate starts a `developer/v1` session and links to it - [ ] An open merge request is linked instead of offering Generate again - [ ] Generate is hidden when the user cannot set up, or Duo Developer is unavailable - [ ] Endpoint returns 201 with the workflow id, 422 with a usable message, 403 below maintainer, 404 with the flag off - [ ] Behind `duo_agent_readiness_settings` ([#607567](https://gitlab.com/gitlab-org/gitlab/-/work_items/607567)) like the rest of the card ## Also in scope: move the prompt to the AI Gateway Absorbs [#606937](https://gitlab.com/gitlab-org/gitlab/-/work_items/606937). That issue originally covered six goal templates; five were dropped when the content generators were cut, leaving exactly the one this row uses — so it is the same piece of work and is tracked here. On [!242729](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/242729) @eduardobonet flagged that these prompts should not live in Rails: > **Question** How are we using this template? Isn't it better to keep it on AIGW side as a tool for chat to use? Adding prompts to rails bring a lot of issues @wanpol and @mikewronski agreed to ship the monolith version and migrate as a follow-up, and @eduardobonet approved on that basis. **Move `ee/app/models/ai/catalog/goal_templates/developer/init_execution_env.rb` to the AIGW / DWS prompt registry**, so Rails references the prompt rather than embedding it. The remaining `init_*` templates stay where they are — they no longer have a UI entry point, and their fate is decided by [#607425](https://gitlab.com/gitlab-org/gitlab/-/work_items/607425). ### This makes the work cross-repo Two merge requests, each in its own repo, cross-linked: - **`gitlab-org/gitlab`** — the row, the endpoint, and the switch from an embedded template to a prompt reference - **`gitlab-org/modelops/applied-ml/code-suggestions/ai-assist`** (AI Gateway) — the prompt definition in the registry ### Sequencing question to settle Does the Generate button ship against the monolith template first and migrate after, or wait for the registry? Shipping first gets the row in front of users sooner; waiting avoids writing a prompt reference twice. @eduardobonet approved the original MR on a follow-up framed around 19.3. ## Out of scope Nothing further — this issue owns the row, its endpoint, and its prompt. ## Merge requests - `gitlab-org/gitlab` — https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247978 (row, endpoint, permission, `RunService`) - AI Gateway — https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6373 (the `agent_config` prompt definitions and the flow config that uses them) **Merge the AI Gateway MR first** — the GitLab MR is what starts referencing the flow.