Agentic Chat doesn't work outside of project (Group/Namespace-level duo workflow)

Problem

Agentic Chat button should be shown when user logged in with a user that has a seat in Duo Addon. It should not depend on what kind of project they has opened.

This limitation was originally coming from that Duo Workflow is tightly coupled with project entity. We need to make the project instance optional from Agentic Chat workflow execution.

This is required for the feature parity with Classic Duo Chat which has already cross-project and group-level entity support (e.g. ask question about epic where there are no 1-to-1 relationships with a project). Also, competitors such as Windsurf has cross-project context support by default.

Proposal

• Make projects optional from duo workflow tables in PostgreSQL. While we allow chat workflows to skip persisting project_id, it's still required for the other non-chat workflows. Instead we use namespace_id column to represent where a workflow is executed at. This could be the top-level group where the user is permitted to use the workflow execution (and most likely the group has workflow related settings e.g. duo_workflow_mcp_enabled).
• Clients have to specify either project_id or namespace_id (the ID is either string path or numeric ID)
  • e.g. User opens gdk/gitlab workfspace in VSCode editor, which has a corresponding remote GitLab project at https://gitlab.com/gitlab-org/gitlab. The persisted workflow entry is associated with the project.
  • e.g. User interacts with Agentic Chat on Web UI at https://gitlab.com/gitlab-org. The persisted workflow entry is associated with the group.
• Clients can't execute a workflow if both are missing. This technically leaves a gap with classic duo chat that allows such execution. We would need a confirmation with PM that this limitation is inevitable. This is a tradeoff between security, governance, auditing, and data integrity versus easy onboarding.
  • An important implication of this spec is that this limitation is applied to self-managed GitLab users as well, where basically perform auth[N|Z] at instance level.
• Clients should provide a user interface to select a fallback namespace/group where we can't identify a container (project or group) for workflow executions.
  • e.g. User creates a new directory and ask agentic chat to write an application from scratch.
• Clients perform access check to agentic chat against the current project or fallback namespace. If the user is allowed to use agentic chat under the namespace, agentic chat UI is visible for them.
• Tools or agent handover which require project context are excluded at workflow execution if the project context is not specified. The same thing can be said to namespaces.
• Databases:
  • duo_workflows_workflows.project_id column represents in which project context the workflow was executed.
  • duo_workflows_workflows.namespace_id column represents in which namespace context the workflow was executed.
  • This is effectively introducing "Group-level Duo Worfklow" in the contrast of current "Project-level workflow".
• Introduce user-level access check GraphQL API for agentic chat. Currently, we only have project-level access check GraphQL API which is used by LSP.
• Expose gitlab URL for DWS. Currently, DWS fetches workflow metadata and its project metadata from Rails to validate the tool execution. Instead of extracting gitlab URL from project web URL, we can just expose the gitlab URL. This effectively improves the performance of workflow execution since we can omit the project Rest API request which could take approx. 10-100ms.
• Update VSCode Extension to use namespace-level access check API and show the agentic chat UI even if the user hasn't selected a GitLab project (e.g. local repositories that doesn't exist in the connected GitLab instance).
• Update GitLab-LSP to use the namespace-level access check API, and adjust health check facility according to it.

PoC

1. GitLab-Rails: !194821 (closed)
2. Duo Workflow Service: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!2807 (merged)
3. GitLab-LSP gitlab-org/editor-extensions/gitlab-lsp!1870 (closed)
4. Editor Extension (VSCode): gitlab-vscode-extension!2693 (closed)

Current behaviour:

With a newly created local project that doesn't have correspondence with a project from GitLab server:

Expected behaviour:

User should be able to use Agentic Chat.