## Summary A maintainer who wants to run GitLab Duo agents on a project has to look in several places, read errors that do not explain themselves, and guess what to configure next. This epic puts all of it in one place, in the settings they already use. We add a block to Settings › General › GitLab Duo called "Run GitLab Duo agents on this project". It reads the project's live state and shows what is in place, what is missing, and one action for each gap. Every row gives a state, one line of description, and one control, which is either a toggle, a link, or an action. The standalone Automate → Onboarding page is removed. This block replaces it. ## Goal Give a maintainer one place to see whether this project can run agents, and what to do next. Most of the remediation already exists. This epic builds the surface that reports state and points at the fix. ## Design spec Build to the Turn 4 designs: https://claude.ai/design/p/54bcc27d-fe37-450f-90c1-4457674092f0 Later turns in that file explore how the pattern could grow. They are not committed scope. ## Scope The block sits inside the existing GitLab Duo project settings, behind a feature flag. A header runs across the top. It shows the title, a progress bar, a count of required steps, and a state line. The state line reports one of five things: the project is not set up yet, chat and code suggestions work but flows do not, some steps remain, the project is ready, or something blocks execution. Below the header are three groups of rows, followed by the project's existing Duo toggles. The Required group lists what has to be in place before agents can run flows here. | Row | Control | | --- | --- | | Agent Platform | Read-only. Links to whoever can change it. | | GitLab Duo | Toggle | | Flow execution | Toggle | | Allow foundational flows | Nested toggle. Not counted. | | CI/CD runner | Check again, or view runners | | Agent configuration file | Generate, or view file. Whether it counts is still open. | The Optional group adds capability. These rows never read as failures when they are unset. It holds GitLab Orbit and MCP servers. The Local setup group covers tooling that people install for themselves. There is no project state behind it. It holds the IDE extensions, the GitLab CLI, and the GitLab Duo CLI. A heading called "Other GitLab Duo settings" then introduces the toggles that already sit on this page today. Those toggles all survive the move. Some of them relocate into the rows above, but nothing is dropped, and no setting ends up rendering in two places. Every row carries a state. A row is done, or to do, or waiting on a prerequisite, or in error. A row whose setting is locked by a group or by the instance keeps the treatment it has today. Rows that start work need two more states, one while the work runs and one while a merge request waits to merge. Finally, this epic removes the Automate → Onboarding page and every entry point to it. That happens after the new block is usable. ## Open decisions | # | Decision | Where | | --- | --- | --- | | 1 | Does the agent configuration file count toward Required? Flows run without it, because the container falls back to a default image. The header currently claims that agents cannot run. Either demote the row, or keep it and correct both the row copy and the header. | gitlab-org/gitlab#607580 | | 2 | Do we keep a save button, or save each toggle immediately? A deferred save lets a row disagree with its own control. Saving immediately changes every toggle on this page, not only the ones that move. | gitlab-org/gitlab#607424 | | 3 | Can a project maintainer enable GitLab Orbit at all? It may only be settable higher up. If so, the row becomes a link rather than an action. | gitlab-org/gitlab#604770 | | 4 | Which state do we read while the page loads, and which do we defer? The runner check and the repository read are both expensive, and every maintainer loads this page. | gitlab-org/gitlab#607644 | | 5 | Do we accept that the Local setup links only reach maintainers, or do we surface them where a developer can see them? | gitlab-org/gitlab#604771 | | 6 | Do we need a group-owner handoff? Without one, a maintainer who cannot register a runner has no way forward. | No owner | ## Definition of done - [ ] The block renders in Settings › General › GitLab Duo and looks like the Turn 4 designs. - [ ] Every row reports the project's real state, and the counter and the state line agree with the rows below them. - [ ] Every row offers the right next step. That is a toggle to flip, a link to follow, or an action to run. Where the viewer cannot make the change themselves, the row says who can. - [ ] Optional rows read as opportunities rather than failures. - [ ] Every Duo setting that works on this page today still works, whether it moved up into a row or stayed below. - [ ] Turning a setting on or off updates the rows and the counter the way a user would expect, including the rows that depend on it. - [ ] The page loads as quickly as it does today. A check that cannot complete affects only its own row, never the rest of the page. - [ ] The Automate → Onboarding page is gone and nothing links to it. - [ ] The documentation covers the readiness card, and the onboarding page docs are removed with redirects (gitlab-org/gitlab#607643). - [ ] A maintainer can take an unconfigured project to ready without leaving this page, except where the fix genuinely lives elsewhere. - [ ] The work ships behind a feature flag, and the flag is removed once it is on by default.