another idea, do we just use the flag that comes from Admin Duo settings? Something like enable beta features?

@donaldcook here is the thread with them. I landed on this consent flow after thinking through w/ Glean if recording this in docs is enough.

The non-interactive is understandable problematic. wondering if there's a better workaround.

Share your feedback on Duo CLI beta

We're running an open beta for Duo CLI. Anyone can leave feedback here — whether you're a design partner or trying it out on your own.

What to include:

• What you were trying to do
• What worked well
• What didn't work, or could be improved
• Any bugs or unexpected behavior

Thanks for helping us improve Duo CLI!

Background

Duo CLI will be releasing to an open beta with ~10 design-partner accounts. Legal confirmed that it is an experimental/beta feature governed by the GitLab Testing Agreement, which requires an explicit user action (prompt or toggle) at enablement time — passive documentation is not sufficient.

Because Duo CLI runs on the developer's machine rather than being toggled from the GitLab web UI, we need an in-CLI consent step.

Problem

A user can install and run Duo CLI today without any explicit, in-product beta consent. This does not satisfy Legal's requirement.

Proposed Solution

Add a one-time, first-run consent prompt that:

1. States that Duo CLI is experimental/beta and not recommended for production.
2. Links to the Testing Agreement via https://about.gitlab.com/terms/#current-terms-of-use.
3. Requires explicit y/Y before continuing — any other input exits with a non-zero status code.
4. Persists a betaConsentAccepted: boolean flag in the existing config so the prompt is never shown again after acceptance.

Prompt text (baseline)

GitLab Duo CLI is an experimental/beta feature.

By continuing, you confirm that you have read and accept GitLab's Testing Agreement for
experimental and beta features, available under "Use of any experimental or beta feature"
in the Current Terms of Use:
  https://about.gitlab.com/terms/#current-terms-of-use

Continue using Duo CLI beta? [y/N]:

• y/Y → persist consent flag, proceed normally.
• Anything else → print "Duo CLI beta requires accepting the Testing Agreement. Exiting without making any changes." and exit non-zero.

Implementation Notes

• Schema: Add betaConsentAccepted?: boolean to duoConfigurationSchema (or equivalent Zod schema), following existing naming conventions.
• Config load path: Expose the flag wherever config is loaded
• Initialization: In cli_initialization_service.ts (or equivalent entry point), check the flag after config is loaded but before any other work. Show the prompt if missing or false; save true on acceptance.
• Non-interactive / headless: Fail fast for now if consent was never recorded.

Acceptance Criteria

• Fresh install (no config): prompt is shown with the exact Terms URL; exits on non-y input; persists consent and skips prompt on subsequent runs.
• Existing config with betaConsentAccepted: false or missing: prompt is shown once.
• Existing config with betaConsentAccepted: true: Duo CLI starts without showing the prompt.

Description

This change updates the documentation to clarify which versions of GitLab work with the Visual Studio Code extension. Instead of listing specific version numbers, it now explains that the extension officially supports only currently maintained GitLab versions (following GitLab's standard support policy). The update also reorganizes the requirements section to be clearer about what's needed for different features - like basic functionality, AI coding assistance, and security scanning - making it easier for users to understand what they need for the specific features they want to use.

Related Issues

Resolves #[issue_number]

How has this been tested?

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
• Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes

@donaldcook we need this addressed in 18.11, it prevents us from understanding where DAP requests are coming from. we can't tell the difference between DAP from Duo CLI, Editor Extensions, or Web. This should give us that.

@aelhusseiny

GKG DoD Section Trackers Created

The following section-level tracker issues have been created to map DoD coverage, gaps, and Q1 scope:

GLQL Q1 Tracking View: #593790

Each section tracker includes a coverage table, gap analysis, and Q1 scope callouts. The tracking view issue (#593790) contains a live GLQL query rendering all 9 section trackers as a table.

GKG DoD — GA Readiness at a Glance

Parent work item: #589475 | .com GA target: End of April 2026

Check off each item when verified end-to-end in staging. The live table below each section shows the issues tracking that work.

1. Discovery & Opt-In — #593781

• Admin can find GKG on their GitLab subscription or settings page
• Admin sees a pricing summary and Sales offer at point of opt-in
• Admin can start engage with Sales for a PoC
• Billing Owner can see GKG as a line item in their GitLab account
• Developer can discover GKG is available via Duo chat or Orbit settings

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Discovery" AND state = opened

2. Setup & Configuration — #593782

• Admin can enable GKG for their namespace with a single toggle
• Admin can disable GKG at any time; queries return a graceful "not available" state
• Admin can find the GKG settings page without hunting (clear navigation)
• Admin can scope which top-level namespaces are indexed
• Developer can connect an external agent (e.g. Claude Code) via MCP
• Agent can be configured via a copy-paste setup prompt from GKG documentation

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Setup" AND state = opened

3. Onboarding & First-Time Experience — #593783

• New user sees a welcome guide or walkthrough on first GKG interaction
• Admin has access to a quick-start checklist covering setup, consent, and first query
• Developer can access sample queries or prompts to explore GKG capabilities
• New user understands what data types are searchable (code, MRs, issues, etc.)
• Developer receives a success confirmation after their first successful GKG query
• Admin can share onboarding materials with their team (documentation links, videos, etc.)
• Developer can access a "Getting Started" guide directly from the GKG-enabled interface

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Onboarding" AND state = opened

4. Data Consent & Governance — #593784

• Admin sees a consent flow before indexing begins covering what data is indexed and how
• Admin consent is recorded with a timestamp for compliance audit purposes
• Admin is clearly informed that indexing is global but search respects project-level RBAC
• Security Officer can confirm users only see results they are already authorized to access (Reporter+ minimum)
• Security Officer can request GKG data deletion for their namespace
• Admin is notified if indexing scope changes in a future release and must re-consent

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Consent" AND state = opened

5. Day-to-Day Usage — #593785

Duo / DAP

• Developer can ask natural language questions about their codebase and SDLC in DAP and get accurate answers
• Duo calls GKG tools automatically
• Developer receives noticeably better answers with GKG enabled vs. without (validated by evals)
• Developer can ask cross-repository questions and get accurate answers
• Developer sees a human-readable message when GKG is still indexing (not a raw error)
• Duo falls back gracefully if GKG is unavailable — workflow is not fully broken

MCP / External Agents

• Agent can call foundational graph tools
• Agent only receives data the authenticated user is authorized to see

Evals

• Opencode efficacy with and without Orbit on
• DAP efficacy with and without Orbit on
• Tool call reduction / token consumption / qualitative evals

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Usage" AND state = opened

6. Observability & Trust — #593786

Admin

• Admin can see GKG health status at a glance: Running / Indexing / Degraded / Off
• Admin can see indexing progress per namespace and project
• Admin can see a last-indexed timestamp per namespace
• Admin can see basic index statistics: projects, MRs, code symbols, languages indexed
• Admin sees actionable error messages, not generic failures

Developer

• Developer can see an indicator that GKG is enabled for their namespace
• Developer can see which languages and entity types are indexed for their projects (out of scope for Q1)
• Developer can optionally see which GKG tools were called in an agent interaction

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Observability" AND state = opened

7. Billing & Credits — #593787

• Billing Owner can see GKG credit consumption in their GitLab account dashboard
• Billing Owner can see a breakdown of what triggered credit usage (queries vs. indexing)
• Billing Owner can access a billing event log with enough detail to verify or dispute charges
• Billing Owner understands how DAP-invoked queries differ from external API/MCP queries in credit consumption

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Billing" AND state = opened

8. Troubleshooting & Support — #593788

• Admin can find a troubleshooting guide mapping error states to resolution steps
• Support team has runbooks for: indexing failures, query errors, access issues, billing disputes
• Escalation path from support to GKG engineering is defined and documented
• Developer has a way to flag a bad or incomplete GKG-powered Duo response

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Support" AND state = opened

9. Telemetry & Product Analytics — #593789

• GitLab can understand how many accounts have GKG toggled on
• GitLab can understand DAU (Daily Active Users)
• GitLab can understand AI surface distribution of usage (CLI vs DAP vs MCP vs API %)

display: table
fields: title, status, health, assignee, milestone
query: label = "GKG-Telemetry" AND state = opened

GA Sign-Off Criteria

• All items above verified end-to-end in staging
• Each item has a corresponding GitLab child issue with acceptance criteria
• No items in sections 1–6 are failing or untested at go/no-go
• Section 8 (Support) verified by Support team, not Engineering
• Named DRI has signed off on each section

GKG Definition of Done — 9. Telemetry & Product Analytics

Parent work item: #589475

User Story → Issue Mapping

Gaps

✅ No gaps. This section is well-covered by the telemetry epic (&21189) and #591558.

Q1 Scope

• ✅ In scope: &21189, #591558
• All three user stories are covered — no new issues needed

GKG Definition of Done — 8. Troubleshooting & Support

Parent work item: #589475

User Story → Issue Mapping

Gaps

⚠️ Three gaps — all need issues with Support team as DRI:

1. Support runbooks — step-by-step guides for common KG failure modes
2. Escalation path — formal L1→L2→Engineering escalation process
3. Support team sign-off — explicit tracking issue for Support DRI approval before GA

Q1 Scope

• ✅ In scope: #584169, &21190, &20992, #592436
• ⚠️ Needs issues: runbooks, escalation path, Support sign-off

GKG Definition of Done — 7. Billing & Credits

Parent work item: #589475

User Story → Issue Mapping

Q1 Scope

⚠️ All items OOS for Q1. GA will launch without credit gating. Billing deferred to future milestone.

GKG Definition of Done — 6. Observability & Trust

Parent work item: #589475

User Story → Issue Mapping

Admin

Developer

Q1 Scope

• ✅ In scope: #175, #591396, #591905
• 🚫 OOS: per-project indexing progress, index stats, language/entity visibility, tool call trace

GKG Definition of Done — 5. Day-to-Day Usage

Parent work item: #589475

User Story → Issue Mapping

Duo / DAP

MCP / External Agents

Evals

Q1 Scope

• ✅ In scope: &21075, #591558, #591397, #178, #591905
• ⚠️ Needs issues: evals (DAP, Opencode), DAP fallback specifics

GKG Definition of Done — 4. Data Consent & Governance

Parent work item: #589475

User Story → Issue Mapping

Gaps

⚠️ Three consent gaps need issues — compliance-critical:

1. Consent UI flow — user-facing modal/flow at opt-in
2. Consent timestamp recording — audit trail
3. Re-consent trigger — re-prompt when data scope expands

Q1 Scope

• ✅ In scope: #222, #207
• ⚠️ Needs issues: consent UI, timestamp, re-consent
• 🚫 OOS: data deletion (&20248)

GKG Definition of Done — 3. Onboarding & First-Time Experience

Parent work item: #589475

User Story → Issue Mapping

Gaps

• No issue for success confirmation after first query

Q1 Scope

⚠️ All items OOS for Q1. This section is fully deferred to a future milestone.

GKG Definition of Done — 2. Setup & Configuration

Parent work item: #589475

User Story → Issue Mapping

Gaps

• No issue for copy-paste setup prompt in docs — needs owner and issue created

Q1 Scope

• ✅ In scope: #591396, #207, #588317, #591397
• ⚠️ Gap: copy-paste setup prompt (no issue)

GKG Definition of Done — 1. Discovery & Opt-In

Parent work item: #589475

User Story → Issue Mapping

Gaps

• #584171 exists but is an empty placeholder — needs content or a dedicated issue
• No issue for Admin engaging Sales for a PoC

Q1 Scope

• ✅ In scope: #588317, #589559, #593194, #589476
• ⚠️ At risk: #584171 (empty)
• 🚫 No issue: Sales PoC engagement