## Problem context We want to be able to test how the duo developer benefits from our knowledge graph (Orbit). We don't yet know how to best instruct the developer or how to integrate orbit fully but we want to make first steps to allow us testing things. We need a gating mechanism that allows us to point the developer flow to use a specialized Orbit-aware developer which is being created in https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2246 . ## Proposal ~~Create a feature flag similar to how `developer_unstable` is handled by the `duo_developer_next_unstable` feature flag — see ~~[~~start workflow service logic~~](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/ai/duo_workflows/start_workflow_service.rb#L403-410)~~). We should be able to activate the feature flag on a user and group level.~~ **Updated proposal:** Instead of a separate feature flag, leverage the existing `orbit_settings` JSONB user preference (added in !234196). This preference already provides per-user opt-in/opt-out for Orbit features, gated behind the `orbit_user_preference` feature flag. ### Implementation plan 1. **Add a new key to `orbit_settings`** (e.g. `duo_developer_orbit_enabled`) — or reuse the existing `enabled` key if the intent is "use Orbit everywhere it's available". 2. **Update `resolve_developer_workflow`** in [`StartWorkflowService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/ai/duo_workflows/start_workflow_service.rb#L403-410) to check the user's `orbit_settings` preference. When the preference is active, point to the new `developer/v1` with flow version `2.0.0-orbit` (or what eventually gets implemented here https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/5456/diffs) instead of the default developer flow. 3. The `orbit_user_preference` feature flag remains the top-level gate — when it's disabled (default), the user preference is ignored and behavior is unchanged. ### Why user preference instead of a feature flag? - We already have a per-user `orbit_settings` JSONB column with a UI toggle in Preferences → Behavior (!234196). - This gives users explicit control (opt-in/opt-out) rather than relying on admins toggling a feature flag per user/group. - The `orbit_user_preference` feature flag still acts as the main gate for the rollout — when it's off, no Orbit behavior is active regardless of user settings. - More granular keys can be added to the JSONB column as we expand Orbit integration (e.g. per-flow toggles). When active, we want to adjust the `resolve_developer_workflow` logic to point to the new flow created in https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2246. Right now, it is planned to be `developer/v1` with flow version `2.0.0-orbit` .