## Summary Tracks the lifecycle of the **`duo_agent_readiness_settings`** feature flag, which hides the "Run GitLab Duo agents on this project" readiness card in **Settings › General › GitLab Duo** while it is being built across several MRs. - Flag: `duo_agent_readiness_settings` - Type: `beta` (transitioned from `wip` in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256778) - Actor: **user** - `default_enabled: false` - Definition: `ee/config/feature_flags/beta/duo_agent_readiness_settings.yml` - Introduced by: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247931 <details><summary>Background: why a separate flag, why it started as <code>wip</code>, why the user actor (written before the beta transition)</summary> ## Why a new flag rather than `duo_agent_onboarding` `duo_agent_onboarding` gates the standalone **Automate → Onboarding** page, which is being [removed entirely](https://gitlab.com/gitlab-org/gitlab/-/work_items/607425). The readiness card in settings is its replacement and has to roll out on its own schedule, so the two must not share a switch — enabling one should never reveal the other. ## Why `wip` Per the [feature flag guidance](https://docs.gitlab.com/development/feature_flags/#wip-type), `wip` is for features that "need to be implemented through several MRs" and must stay hidden until complete. That matches this work: the card is assembled across https://gitlab.com/gitlab-org/gitlab/-/work_items/607424, https://gitlab.com/gitlab-org/gitlab/-/work_items/604766, https://gitlab.com/gitlab-org/gitlab/-/work_items/604770, https://gitlab.com/gitlab-org/gitlab/-/work_items/604771 and https://gitlab.com/gitlab-org/gitlab/-/work_items/607423. The guidance notes a rollout issue is usually unnecessary for `wip` flags, because they should be transitioned to another type before being enabled. This issue therefore tracks that **transition**, not a percentage rollout. ## Why the actor is the user A `wip` flag exists so the team can work on an unfinished feature without exposing it, and the user actor is what makes that practical: an engineer or designer can switch the card on for themselves and dogfood it without flipping it for a whole project and everyone else who opens its settings. Other `wip` flags do the same, for example `Feature.enabled?(:activation_tracking, user, type: :wip)`. The trade-off is that two maintainers of the same project can see different layouts while the flag is being rolled out. That is acceptable for a `wip` flag, where the audience is the team building it, and it disappears when the flag is removed. If the flag is later transitioned to `beta` for customer-facing rollout, revisit the actor then — at that point per-project or per-group consistency starts to matter. </details> ## What the flag controls **Off (default) — the page renders exactly as it does today.** This is verified by diffing the rendered DOM against `master`; the flag-off path keeps every existing setting in its original position, including `Allow flow execution` and `Allow foundational flows`, and a test asserts it. **On** — the readiness card renders, with those settings relocated into it as rows. ## What could go wrong? - Blast radius: every project's **Settings > General > GitLab Duo** page for users who can edit project settings (maintainer/owner). The card only reads existing project settings and relocates existing controls; it writes nothing on render. - Known past failure: the agent-config row's blob lookup 500'd on empty repositories (fixed in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254784, caught by preprod smoke tests, inc-14045). Watch `ProjectsController#edit` 5xx. - Row state is loaded asynchronously (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250804): a slow readiness query degrades to a loading state, not a page error. - Dashboards: [Rails 5xx / error ratio](https://dashboards.gitlab.net/d/web-main/web-overview) and the Kibana queries under Events below. ## Events - [Exceptions with duo_agent_readiness_settings:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.exception.feature_flag_states.keyword:%22duo_agent_readiness_settings:1%22'),columns:!(json.exception.class,json.exception.message,json.extra.workflow_id,json.meta.caller_id),sort:!(!(json.time,desc)))) - [Events with duo_agent_readiness_settings:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.feature_flag_states:%22duo_agent_readiness_settings:1%22'),columns:!(json.meta.caller_id,json.feature_flag_states),sort:!(!(json.time,desc)))) - [Error rate and other graphs by modifying the examples in the Visualization Library](https://log.gprd.gitlab.net/app/visualize#/?_g=h@358d019&s=FF%20Observability) Feature Flag events are only logged by default for feature flags marked for the current or future milestones. To enable while the feature flag is active, see https://docs.gitlab.com/development/feature_flags/#logging ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_dap-repository-flows`. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). **Non-production** — done 2026-09-09 (dev, pre, gstg, gstg-ref all `true`): ``` /chatops gitlab run feature set duo_agent_readiness_settings true --dev --pre --staging --staging-ref ``` **Production** — the flag is checked with a **user** actor (`Feature.enabled?(:duo_agent_readiness_settings, current_user)`), so `--group=`/`--project=` gates would not match; the internal-dogfood step uses the `gitlab_team_members` feature group (every gitlab-com group member), then global (no percentage step needed for a settings-page relocation): - [x] Dogfood scoped to the working group on gprd (`--user=` tgao3701908, mikewronski, uchandran, phikai, alex, akozovski, mnohr — 2026-09-09 / 2026-09-22) - [x] Transition the flag from `wip` to `beta` — https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256778 (merged 2026-09-22; wait for it to reach gprd before the next step) - [x] Confirm no change for projects with the flag off — asserted by the flag-off DOM-diff spec, and two weeks of user-scoped production (2026-09-09 → 2026-09-23) with the card hidden for everyone else produced no reports - [x] Enable for GitLab team members via the `gitlab_team_members` feature group — done 2026-09-23 15:54 UTC (https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/work_items/64925); dogfood for about a week, collecting feedback in the dogfooding issue https://gitlab.com/gitlab-org/gitlab/-/work_items/630557; announced in #whats-happening-at-gitlab 2026-09-23 (https://gitlab.slack.com/archives/C0259241C/p1790185442192929): ``` /chatops gitlab run feature set --feature-group=gitlab_team_members duo_agent_readiness_settings true ``` - [x] Enable globally — done 2026-10-06 00:40 UTC by @tgao3701908 (https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/work_items/65696); 12 days of team-member dogfood before this (one feedback item, not blocking: https://gitlab.com/gitlab-org/gitlab/-/work_items/630557); keep it on for 2–4 working days (until about 2026-10-09) before judging stability, per the [feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release): ``` /chatops gitlab run feature set duo_agent_readiness_settings true ``` - [x] Set `default_enabled: true` by 2026-10-08 (3–4 working days before the 19.5 release) so self-managed 19.5 gets the card — https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259939 (merged 2026-10-06) ## Before global rollout Confirm the relevant gotchas before going to 100% — see [enabling a feature for GitLab.com](https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom): - [x] [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated — https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250834 merged 2026-09-23 (approved by @ashrafkhamis) - [x] [Breaking changes](https://docs.gitlab.com/development/documentation/release_notes/#deprecations-removals-and-breaking-changes) announced, if any — none: the card relocates existing controls, no setting is removed or renamed - [x] [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required — not required (UI-only, instant rollback via flag) - [x] [External API consumers](https://docs.gitlab.com/development/feature_flags/#do-not-use-feature-flags-in-external-api-consumers) handled with a fail-open mechanism, if applicable — not applicable (no API surface behind the flag) - [x] Product + UX sign-off recorded: @uchandran confirmed the merged copy on gprd 2026-09-22 (https://gitlab.slack.com/archives/C0B95JYPFST/p1790089156795089?thread_ts=1790015898.360649&cid=C0B95JYPFST); @phikai confirmed 2026-10-05 ("I'm good to turn it in globally and default enable for 19.5", https://gitlab.enterprise.slack.com/archives/C0B95JYPFST/p1791236401461749); UX strings reviewed by @uchandran, treated as signed off on 2026-10-06; the agent configuration row change is in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259925 - [x] Notify `#support_gitlab-com` — skipped on 2026-10-06: UI-only relocation of existing settings with instant rollback, no support impact expected ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) — see [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Track it here, or open a follow-up [Feature Flag Cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/new?description_template=Feature%20Flag%20Cleanup). Remove the flag and its YAML definition from the codebase (`ee/config/feature_flags/beta/duo_agent_readiness_settings.yml`, `EE::ProjectsHelper`, `Projects::Settings::GitlabDuo::AgentConfigController`), then: ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete duo_agent_readiness_settings --dev --pre --staging --staging-ref --production ``` - [x] Remove the flag and its checks ## Feature flag guidance followed - Flag types and constraints (`wip` must be transitioned before enabling; `beta` may later default on and is auto-documented): https://docs.gitlab.com/development/feature_flags/#types-of-feature-flags — https://docs.gitlab.com/development/feature_flags/#wip-type, https://docs.gitlab.com/development/feature_flags/#beta-type, https://docs.gitlab.com/development/feature_flags/#gitlab_com_derisk-type - Definition file and validation (type must match the definition directory; validated at boot in dev/test): https://docs.gitlab.com/development/feature_flags/#feature-flag-definition-and-validation - Feature actors (this flag uses the user actor): https://docs.gitlab.com/development/feature_flags/#feature-actors - Rolling out with ChatOps — pre-production first, then GitLab.com, with change logging: https://docs.gitlab.com/development/feature_flags/controls/#rolling-out-changes, https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-pre-production-testing, https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom, https://docs.gitlab.com/development/feature_flags/controls/#feature-flag-change-logging - Cleaning up once enabled everywhere: https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up - Issue templates: [Feature Flag Roll Out](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md), [Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Cleanup.md) - Documenting a feature behind a flag: https://docs.gitlab.com/development/documentation/feature_flags/ - Handbook lifecycle overview: https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/ ## Rollback ``` /chatops gitlab run feature set duo_agent_readiness_settings false # production /chatops gitlab run feature set duo_agent_readiness_settings false --dev --pre --staging --staging-ref # non-production ``` Disable the flag. There is no data migration and no persisted state behind it — the card only reads existing project settings and renders existing controls in a different place, so turning it off restores the previous page immediately.