Serve a dedicated GLQL schema API to decouple consumers from GLQL releases

Why

The Data Analyst agent in ai-assist maintains its own hand-written, hardcoded copy of the GLQL schema (_SCHEMAS dict in get_glql_schema.py). Every time GLQL adds or changes a data source, field, or display type, someone has to remember to open a companion MR in ai-assist to keep the agent's schema in sync. This has already happened at least twice:

This is a manual, drift-prone process with no single source of truth, and it will only get worse as GLQL adds more sources.

What

Ship a GET /api/v4/glql/schema endpoint that serves the GLQL schema — data sources, type values, query fields, display fields/types per source, sort fields, and functions — so that:

  1. The agent tool (get_glql_schema in ai-assist) can call the API instead of shipping a hardcoded _SCHEMAS dict.
  2. Docs generation (follow-up in #118 (closed)) can eventually consume the same source of truth.

In scope

  • Auto generated schema document covering, per source (WorkItems, MergeRequests, Pipelines, Jobs, Projects):
    • Type values (e.g. WorkItems → Issue, Epic, Task, …)
    • Query fields: name, aliases, operators, value types
    • Display fields: name, aliases, and supported display type (e.g. scalar, reference/link, percentage, date) — this is the piece the agent currently has no visibility into and hand-maintains
    • Sort fields
    • Functions (currentUser(), today(), startOfDay(n), labels(...))
  • GET /api/v4/glql/schema endpoint (lib/api/glql.rb in the gitlab monorepo) serving the curated schema
  • Update ai-assist's get_glql_schema tool to call the new endpoint and delete the hardcoded _SCHEMAS dict

Out of scope (tracked elsewhere / follow-up)

  • Markdown docs generation from the schema (#118 (closed))
  • Exposing GLQL grammar/DSL as its own tool (raised as a related idea in the #118 (closed) discussion, similar to how Orbit exposes its DSL)
Edited by Daniele Rossetti