## Problem The readiness rows in **Settings › General › GitLab Duo** are resolved server-side while the page renders. `gitlab_duo_settings_data` calls `Ai::DuoWorkflow::ProjectReadiness`, and every row's state is read before the response is sent. Raised by @mikewronski in review of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247916: > Just noting here: we probably need an async solution to load the readiness state of all rows so they don't block the request. The CI/CD runner check and the agent file checks are probably the heaviest. > makes sense, but there may be more checks to come in the future and if they are all synchronous it may start slowing this page down, especially if tested on different instances with different configurations, project sizes etc. ## Where it stands today Measured on GDK against a project with the card fully rendered: | Read | Median | Notes | | --- | --- | --- | | `platform_enabled?` | 0.3 ms | `Ai::Setting` singleton, memoized | | `runner_available?` | 1.9 ms | one query, index-backed on every branch, memoized | | **Total** | **~2 ms, 2 SQL queries** | skipped entirely when the card does not render | So it is not a problem at the current row count. The concern is the trajectory: the agent-config row in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247978 adds a repository blob lookup and an open-merge-request lookup, and the Optional rows (MCP servers, GitLab Orbit) are still to come. These are GDK numbers, not gitlab.com ones. ## What loads when This issue owns the epic's open decision 4: which state we read at page load, and which we defer. Settings the page already has render immediately: Agent Platform ([#607581](https://gitlab.com/gitlab-org/gitlab/-/work_items/607581)) and the three toggles ([#607424](https://gitlab.com/gitlab-org/gitlab/-/work_items/607424)). Everything else defers until after first paint: | Row | Read | Today | | --- | --- | --- | | CI/CD runner ([#604766](https://gitlab.com/gitlab-org/gitlab/-/work_items/604766)) | tag, liveness, `RunnerValidator`, executor | already async — `Project.duoWorkflowRunnerAvailable` resolves on request only, and *Check again* refetches just that field | | Agent config file ([#607580](https://gitlab.com/gitlab-org/gitlab/-/work_items/607580)) | default-branch blob read plus the open-MR lookup | synchronous in the helper | | GitLab Orbit ([#604770](https://gitlab.com/gitlab-org/gitlab/-/work_items/604770)) | graph freshness | already loads after first paint (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/248298); the enabled flag is one indexed `EXISTS` and can stay at load | | MCP servers ([#607423](https://gitlab.com/gitlab-org/gitlab/-/work_items/607423)) | one indexed `COUNT` | synchronous in the helper | ## Proposal Move the per-row state behind a request the card makes after render, so each row resolves independently and a slow check degrades that row rather than the whole settings page. Generalise the runner row's pattern: a per-row GraphQL field, resolved on request only, refetched without a reload. The per-row loading contract, which the row issues assume exists: - While a check runs, its row shows a loading state and its control is disabled. - When it resolves, the row updates. - A check that fails or times out marks its own row with a retry; the rest of the page is unaffected. ## MCP row: match the destination's full gate The row's gate and the destination's gate check different things. `duo_mcp_data` checks only `read_ai_catalog_mcp_server`. `Projects::DuoAgentsPlatformController#check_access` checks the `ai_catalog_public_explore` flag or `read_duo_agent_platform` first, then the same ability for the `mcp-servers` route. @thomasrandolph raised this in review of MR 248298: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/248298#note_3678308272 The gap is reachable. The only DAP check inside `read_ai_catalog_mcp_server` is user-scoped: the user belongs to some Premium or Ultimate root group with the DAP switch on — not this project's root namespace. On SaaS, a project's root group can have `duo_workflow_mcp_enabled` on and `duo_agent_platform_enabled` off; a Maintainer who also belongs to a DAP-enabled group then sees a "View servers" link that leads to a 404. This is dormant today because `ai_catalog_public_explore` is `default_enabled: true`, so `check_access` passes on the flag alone on GitLab.com and on default self-managed instances. When this issue moves the row's state off the main request, the row's gate must evaluate the same predicate as `check_access` — one shared method, not two copies — so the two checks cannot drift apart again. ## Acceptance criteria - [ ] No readiness check runs during the settings page request. - [ ] Each deferred row renders a loading state and resolves on its own. - [ ] While a row loads, its control is disabled. - [ ] A failed or timed-out check marks only its own row and offers a retry. - [ ] Behind `duo_agent_readiness_settings` ([#607567](https://gitlab.com/gitlab-org/gitlab/-/work_items/607567)). - [ ] The MCP row's gate and `check_access` share one predicate, so they cannot drift. Blocks the progress header ([#607644](https://gitlab.com/gitlab-org/gitlab/-/work_items/607644)): the counter and the state line read the row states this issue makes independently loadable.