grr — Google Workspace CLI + MCP server

Google Workspace desde la terminal: 401 métodos en 14 APIs de Google en un árbol de comandos generado, más un servidor MCP tipado (grr mcp). Binarios de lanzamiento sin configuración, JSON en stdout, HTTP/3 con respaldo honesto. Rust, MIT.

GitHubPrueba este MCPPatrocinado

Documentación

grr

Herramientas de Google desde la terminal, al máximo rendimiento. grr-cli es un paquete Rust publicado, construido alrededor del binario de línea de comandos grr. Catorce APIs de Google comparten un único inicio de sesión OAuth y un único árbol de comandos — generado directamente desde el propio Discovery Service de Google — mientras que stdout permanece limpio y legible por máquinas.

Sitio del proyecto: grr-cli.pages.dev · Privacidad

grr es un proyecto independiente y no está afiliado ni respaldado por Google.

grr auth login
grr gmail users messages list --user-id me --q "in:inbox" --max-results 5
grr drive files list --page-size 10
grr api describe calendar.events.list
grr schema

Instalación

Binarios precompilados — macOS arm64, Linux x86_64, Linux aarch64, Windows x86_64 y Windows en ARM (aarch64, Snapdragon X / Oryon): GitHub Releases

Los binarios de las versiones son de configuración cero — un cliente OAuth está compilado dentro, por lo que grr auth login funciona de inmediato. Los archivos son .tar.zst (zstd nivel 22) en unix y .zip en Windows; los binarios están empaquetados con UPX usando --best --lzma donde el compresor lo soporta — el flujo de trabajo verifica que la copia empaquetada aún se ejecuta y, si no, recurre al binario sin empaquetar con una advertencia.

Desde el código fuente (la compilación CLI predeterminada requiere Rust nightly — ver Desarrollo):

cargo install --git https://github.com/debanjanbasu/grr-cli

o desde un clon local en la raíz del repositorio:

git clone https://github.com/debanjanbasu/grr-cli
cd grr-cli
cargo install --path .

Una compilación desde el código fuente no tiene cliente OAuth compilado — ver Autenticación y configuración.

Gestores de paquetes:

winget install debanjanbasu.grr       # Windows (manifest not yet published — see Packaging & status)
cargo install grr-cli                 # crates.io

Homebrew (macOS + Linux), desde el tap debanjanbasu/tap:

brew tap debanjanbasu/tap
brew trust debanjanbasu/tap
brew install grr

brew trust es obligatorio, no decorativo: desde Homebrew 4.4 los taps de terceros no son confiables por defecto, y brew install se niega a instalar una fórmula de un tap no confiable hasta que lo confíes una vez. Omitir esa línea es el fallo más común en el primer uso.

La compilación CLI de crates.io necesita Rust nightly y RUSTFLAGS="--cfg reqwest_unstable" para HTTP/3; las versiones precompiladas evitan ese paso de compilación desde el código fuente. cargo install también produce un binario sin cliente OAuth integrado, así que presupuesta cinco minutos para grr auth setup (o un .env) en ese camino.

Inicio rápido en 60 segundos

brew tap debanjanbasu/tap
brew trust debanjanbasu/tap
brew install grr

grr auth login
grr gmail users getProfile --user-id me

No hay nada que configurar primero: un binario de versión ya lleva un cliente OAuth, por lo que grr auth login abre el navegador, das tu consentimiento y todos los servicios funcionan. ¿Máquina sin pantalla? grr auth login --device imprime una URL + código en lugar de abrir el navegador.

¿Compilas desde el código fuente en lugar de instalar una versión? Lee Autenticación y configuración antes de tu primera invocación de grr.

Autenticación y configuración

Los binarios de versión son de configuración cero. build.rs lee GRR_CLIENT_ID / GRR_CLIENT_SECRET del entorno de compilación — secretos de repositorio de GitHub Actions para las compilaciones oficiales — y los compila dentro, por lo que GitHub Releases y las instalaciones de Homebrew no necesitan archivo de configuración ni visita a la consola.

Las compilaciones desde el código fuente traen su propio cliente. cargo install grr-cli compila las fuentes publicadas sin nada en el entorno de compilación, por lo que ese binario no tiene cliente integrado. Cualquiera de estas opciones lo soluciona:

Un .env junto a Cargo.toml — copia .env.example a .env, completa ambos valores y recompila. build.rs lee el entorno primero y .env en segundo lugar, por lo que cada compilación posterior también es de configuración cero. .env está en gitignore; nunca lo confirmes.
Variables de entorno para una sola compilación — GRR_CLIENT_ID=… GRR_CLIENT_SECRET=… cargo build --release.
grr auth setup — no requiere recompilación, porque escribe ~/.grr/config.toml (Windows: %USERPROFILE%\.grr\config.toml) en su lugar.

`grr auth setup`

Create and store an OAuth client. Release builds ship with one, so this is only needed when using
your own client

Usage: grr auth setup [OPTIONS]

Options:
      --client-id <CLIENT_ID>          Google OAuth client id (…apps.googleusercontent.com).
                                       Prompted for when omitted
      --client-secret <CLIENT_SECRET>  Google OAuth client secret. Prompted for when omitted
      --print-only                     Print the instructions and the resolved path, but write
                                       nothing. Useful for a first look, and for agents that only
                                       want the recipe
      --force                          Overwrite an existing ~/.grr/config.toml instead of refusing
      --enable-apis                    Try `gcloud services enable` for the APIs when gcloud is on
                                       PATH
  -f, --format <FORMAT>                Output format [default: json] [possible values: json, jsonl,
                                       table, pretty]
      --readonly                       Refuse every write method (POST/PATCH/PUT/DELETE); only reads
                                       run
      --deny-service <SERVICE>         Refuse every method of this service (repeatable)
      --deny-verb <VERB>               Refuse this HTTP verb (repeatable)
  -h, --help                           Print help

Comprueba la forma del client-id antes de escribir nada (debe terminar en .apps.googleusercontent.com, y un pegado truncado se rechaza), rechaza un secreto truncado, escribe el modo de archivo 0600 en unix y se niega a sobrescribir un config.toml existente sin --force. Imprime las URLs exactas de Cloud Console y la línea gcloud services enable que cubre cada API detrás de un comando — gmail, calendar-json, drive, people, chat, forms, tasks, docs, sheets, slides, script, analyticsadmin, analyticsdata y searchconsole …googleapis.com — y --print-only te entrega esa receta sin tocar el disco, que es el primer comando correcto cuando no tienes ningún cliente:

grr auth setup --print-only

Como se ejecuta antes de que se resuelva cualquier cliente, grr auth setup funciona incluso cuando nada está configurado: es la vía de escape, no el último recurso. Con stdin que no es TTY (CI, agentes, tuberías) da error en lugar de colgarse, así que pasa --client-id y --client-secret explícitamente en lugar de depender de los avisos.

Orden de resolución en tiempo de ejecución: GRR_OAUTH__CLIENT_ID / GRR_OAUTH__CLIENT_SECRET → ~/.grr/config.toml → el cliente compilado en el binario (el entorno gana sobre el archivo; el cliente compilado es el respaldo). GRR_CONFIG_PATH mueve el archivo; RUST_LOG establece el nivel de registro.

Incrustar un secreto de cliente es aceptable aquí porque Google trata los secretos de clientes de aplicaciones instaladas como no confidenciales — el flujo está protegido por PKCE, que siempre está activo. El secreto vive en los secretos del repositorio de GitHub Actions y se compila en el momento de la versión; nunca debe entrar en el repositorio ni en un registro de CI.

Para crear un cliente desde cero, sigue docs/gcp-setup.md — solo lo necesitas si compilas desde el código fuente o quieres deliberadamente tu propio cliente.

El proyecto/fork es Google Rust Rewrite; la aplicación de la pantalla de consentimiento de Google se llama Rust Rewrite. La pantalla de consentimiento es donde aparece ese nombre más corto.

`grr ask` y System One (JEV)

grr ask "<request>" enruta palabras simples a un método tipado + parámetros e imprime el plan; --run lo ejecuta a través de la misma ruta de llamada que grr api. El enrutamiento son tres juicios de System One — servicio, luego método, luego parámetros — cada uno una pequeña solicitud HTTP. El modelo solo selecciona entre candidatos que la CLI proporciona: los 14 servicios, los métodos de un servicio, los valores de enumeración de un parámetro o los rangos encontrados en tu solicitud. No puede inventar un id de método ni un valor — la CLI decide qué se ejecuta.

Establece TYPESAFE_API_KEY y funciona contra el Jev alojado de TypeSafe:

export TYPESAFE_API_KEY=...
grr ask "show my unread messages"

La ruta de entorno es la preferida: una clave en un archivo de configuración puede filtrarse con el archivo. El bloque [systemone] en ~/.grr/config.toml es la única otra superficie:

Clave	Predeterminado	Significado
`endpoint`	`https://api.typesafe.ai/v1/systemone`	cualquier proveedor que hable el contrato de System One (POST `state` + `questions` tipado, devuelve `answers` estructurado)
`model`	`jev-latest`	nombre del modelo enviado a ese endpoint
`api-key`	—	enviado como `Authorization: Bearer`; vacío se comporta como ausente
`confidence-threshold`	`0.6`	por debajo de esta confianza de elección de método, el plan se marca, nunca se bloquea

Cualquier clave también acepta la forma genérica de entorno GRR_SYSTEMONE__ENDPOINT / GRR_SYSTEMONE__MODEL / GRR_SYSTEMONE__API_KEY (la misma ruta GRR_ que GRR_OAUTH__*), y TYPESAFE_API_KEY anula a api-key. La clave nunca aparece en el plan impreso ni en el cuerpo de una solicitud — viaja solo en el encabezado Authorization.

Apuntar endpoint/model a tu propio proveedor solo cambia qué modelo clasifica los candidatos proporcionados por la CLI; los conjuntos de candidatos, el relleno de parámetros tipados y lo que realmente se ejecuta siguen siendo de grr. grr ask respeta los indicadores globales de seguridad (--readonly, --deny-service <name>, --deny-verb <VERB>) pases o no --run, y la compuerta se ejecuta tan pronto como se resuelve el método — antes del juicio de relleno de parámetros y antes de que se construya o envíe cualquier solicitud a Google.

Destacados de uso

grr gmail users messages list --user-id me --q "from:github.com" --max-results 10
grr gmail users messages get --user-id me --id 191f8ab2 --param-format metadata
grr gmail users threads list --user-id me --max-results 10
grr calendar events list --calendar-id primary --time-min 2026-10-01T00:00:00Z --max-results 10
grr drive files list --q "name contains 'report'" --page-size 10
grr drive files export --file-id <id> --mime-type application/pdf
grr chat spaces messages create --parent spaces/AAAA --body-file ./message.json
grr sheets spreadsheets values get --spreadsheet-id 1AbC… --range Sheet1!A1:B10
grr tasks tasklists list
grr transport
grr schema

Cada comando acepta -f/--format json|jsonl|table|pretty (predeterminado json). Para gmail users messages get, el parámetro MIME de Gmail llamado format llega como --param-format full|metadata|minimal|raw (ver la regla de colisión abajo), mientras que -f/--format aún selecciona el formato de salida impreso. Los registros van a stderr, por lo que stdout siempre es analizable:

grr gmail users messages list --user-id me --q "in:inbox" --max-results 1 | jq -r '.[0].id'

grr --version imprime el semver en su primera línea (los scripts dependen de eso), luego la mascota cangrejo: en arte de píxeles a todo color de 24 bits en una terminal que anuncia COLORTERM/color directo, y como ASCII simple en cualquier otro lugar — una tubería, TERM=dumb o NO_COLOR. Establece CLICOLOR_FORCE=1 para forzar el logotipo en color a través de una tubería (grr --version | less -R); NO_COLOR aún gana sobre él.

Referencia de comandos

El árbol de comandos está generado desde el índice de Discovery confirmado por scripts/generate-commands.ts (con compuerta de CI mediante --check), por lo que esta tabla es deliberadamente general: grr --help y grr schema son la fuente de verdad, y cada uno de los 401 métodos es un comando real y tipado.

Grupo	Qué cubre	Métodos
`grr auth`	`login [--device] [--account name]`, `status [--account name]`, `setup [--client-id] [--client-secret] [--print-only] [--force] [--enable-apis]`	—
`grr ask`	`"<request>" [--run] [--service] [--method]` — lenguaje natural a un método tipado + parámetros mediante un modelo System One; imprime el plan por defecto	-
`grr mcp`	un servidor MCP (JSON-RPC sobre stdio) que expone cada método como una herramienta tipada; `--readonly` para solo lectura	-
`grr api`	`list [--service X] [--filter substr] [--grouped]`, `describe <id>`, `call <id> …`, `refresh [--service X]` — cada método por id, la vía de escape plana	401
`grr schema`	todo el árbol de comandos como JSON	—
`grr transport`	versión HTTP negociada + características de tiempo de ejecución	—
`grr skills`	`install [--dir PATH] [--claude] [--force]`, `list` — los 16 archivos de habilidades empaquetados (la habilidad principal, una por servicio y su índice) en el directorio de habilidades a nivel de usuario (`~/.agents/skills`, sin conexión; `--claude` se refleja en `~/.claude/skills`)	—
`grr gmail`	mensajes, hilos, borradores, etiquetas, historial, adjuntos, filtros, reenvío, POP/IMAP, enviar como, CSE, delegados, relojes	79
`grr calendar`	calendarios, eventos, instancias, ACL, libre/ocupado, colores, configuraciones	38
`grr drive`	archivos, permisos, comentarios, respuestas, revisiones, cambios, unidades, aplicaciones, aprobaciones	64
`grr people`	contactos, conexiones, grupos de contactos, otros contactos, personas del directorio	24
`grr chat`	espacios, miembros, mensajes, reacciones, medios, emoji personalizados, estado de lectura	54
`grr forms`	cuerpos de formularios, respuestas, relojes, configuraciones de publicación	10
`grr tasks`	listas de tareas y las tareas dentro de ellas	14
`grr docs`	documentos `get` / `create` / `batchUpdate`	3
`grr sheets`	hojas de cálculo, valores, operaciones por lotes, metadatos de desarrollador	17
`grr slides`	presentaciones, páginas, miniaturas	5
`grr script`	proyectos de script, implementaciones, versiones, procesos, funciones en ejecución	16
`grr analyticsadmin`	cuentas, propiedades, flujos de datos, dimensiones y métricas personalizadas, eventos de conversión	55
`grr analyticsdata`	informes estándar, en tiempo real, dinámicos y por lotes, exportaciones de audiencia	11
`grr searchconsole`	consultas de análisis de búsqueda, mapas de sitio, sitios, inspección de URL	11

Perfiles de seguridad. --readonly, --deny-service <name> y --deny-verb <VERB> son indicadores globales respetados por el árbol generado, grr api call, grr ask y grr mcp por igual — se analizan antes o después del subcomando y convierten métodos destructivos en errores accionables:

grr --readonly gmail users messages delete --user-id me --id abc   # refused: DELETE
grr --deny-service chat chat spaces list                            # refused: the chat service

El árbol generado

Todos los comandos de servicio anteriores se generan a partir del índice confirmado mediante scripts/generate-commands.ts — no hay comandos por servicio escritos a mano ni clientes por servicio escritos a mano. scripts/generate-commands.ts lee el índice de Discovery confirmado (src/discovery/*.json, ~430 KiB en los 14 servicios) y emite todo el árbol en src/commands/generated.rs — 401 hojas, 994 indicadores tipados, usando la API de construcción de clap. Un flujo de trabajo diario vuelve a obtener el Servicio de Discovery de Google, regenera el índice junto con el árbol de comandos, las habilidades de agente por servicio y la tabla de cobertura del sitio, y abre un PR, para que la nueva superficie de API llegue a ti sin esperar a una versión de grr. El árbol y el índice son artefactos generados: nunca los edites a mano.

Las reglas, para que puedas predecir cualquier comando sin memorizarlo:

La regla de nomenclatura. Una hoja refleja su id de método de Discovery: gmail.users.messages.list → grr gmail users messages list. Los recursos se anidan como subcomandos; cada hoja también lleva su nombre de método simple como alias visible (list, get — los métodos camelCase mantienen su capitalización, p. ej. getProfile).
Indicadores tipados por método. Los nombres de los parámetros provienen de los mismos ids: userId → --user-id, maxResults → --max-results. Los enteros se analizan como i64, los booleanos son indicadores de presencia, los parámetros repetidos se repiten (--label-ids a --label-ids b), los parámetros de enumeración validan sus valores y los parámetros obligatorios se aplican mediante clap.
La regla de colisión. Un parámetro llamado format, query, params, body-file, dry-run o help colisionaría con las vías de escape compartidas, por lo que se expone como --param-format / --param-query / … (ver RESERVED_FLAG_IDS en scripts/script-utils.ts).
Cuerpos sin tipar. Los esquemas de solicitud de Discovery no forman parte del índice, por lo que los cuerpos POST/PATCH/PUT pasan a través de --params <JSON> (fusionados; los indicadores tipados ganan) o --body-file <PATH|-> textualmente.
Cada hoja también lleva las vías de escape: --params <JSON>, --body-file, --query KEY=VALUE repetible, --dry-run y -f json|jsonl|table|pretty.

El despacho resuelve el id de la hoja contra el índice integrado y lo canaliza hacia una única ruta de llamada compartida — el mismo motor que usa grr api call. Las dos rutas son intercambiables:

grr api call gmail.users.messages.list --param userId=me --dry-run
grr gmail users messages list --user-id me --dry-run
# byte-identical output

grr api sigue siendo la vía de escape plana: list [--service] [--filter] [--grouped] para explorar, describe <id> para parámetros y ámbitos, call <id> para invocar, refresh [--service] para adelantar el índice entre versiones. Debido a que el índice está integrado en lugar de obtenerse, tanto grr api list como grr schema funcionan sin red alguna.

La autorización se verifica por método: grr auth login consiente un conjunto fijo de ámbitos, y cada llamada compara el ámbito de menor privilegio del método contra ese conjunto en lugar de escalar silenciosamente — así, un método que necesita algo que nunca concediste imprime una nota nombrando el ámbito y puede fallar con un 403 explícito en lugar de un error opaco. Docs, Sheets y Slides funcionan a través del ámbito drive que grr ya posee; Tasks necesita el ámbito tasks, que esta compilación no solicita, por lo que una llamada a Tasks imprime una nota nombrando el ámbito y puede devolver 403. Sus APIs (tasks.googleapis.com, docs.googleapis.com, sheets.googleapis.com, slides.googleapis.com) también deben estar habilitadas en tu proyecto de Cloud — ver docs/gcp-setup.md.

Filosofía de diseño

Configuración cero. Los binarios de lanzamiento llevan un cliente OAuth compilado por build.rs, por lo que una instalación nueva ejecuta grr auth login sin nada que configurar. ~/.grr/config.toml es la anulación, no el requisito previo, y contiene solo el cliente OAuth (ID, opcionalmente un secreto) más — si apuntas grr ask a tu propio modelo — su bloque [systemone] (ver grr ask y System One). Los ámbitos, la URI de redirección, los tamaños de pool, los tiempos de espera y la política de reintentos son constantes de compilación ajustadas para los frontends de Google (src/core/http.rs). GRR_CONFIG_PATH anula la ubicación del archivo, RUST_LOG el nivel de registro (existen variables de entorno GRR_OAUTH__* para anulaciones sin interfaz) — nada más es configurable, a propósito.
Servicios generados y con espacios de nombres. El árbol de comandos se compila a partir del índice de Discovery — la misma descripción legible por máquina que publica Google — por lo que las adiciones de métodos llegan como un PR diario en lugar de un backlog escrito a mano. Mail es grr gmail …; Calendar, Drive, People, Chat, Forms, Tasks, Docs, Sheets y Slides viven junto a él, y las preocupaciones a nivel de cuenta permanecen de nivel superior (grr auth, grr api, grr ask, grr mcp, grr transport, grr schema, grr skills). Un solo inicio de sesión cubre todos los servicios.
Instalaciones auto-migratorias. Un binario más nuevo actualiza las habilidades de agente que instaló por sí solo: los archivos que nunca tocaste se reemplazan, los archivos que editaste reciben una fusión de tres vías contra los bytes que grr escribió por última vez, y un conflicto deja tu archivo intacto con la versión entrante a su lado (.grr-incoming). Los archivos que grr no instaló nunca se tocan. La verificación es perezosa — una comparación de versiones; nada se hashea hasta que algo realmente necesita fusionarse.
Pureza de stdout. Los registros van a stderr, los resultados a stdout, por lo que | jq siempre funciona. -f jsonl transmite arreglos con un objeto por línea.
Almacenamiento de tokens con prioridad en el llavero. Los tokens viven en el llavero del sistema operativo (Administrador de credenciales de Windows, Llavero de macOS, Servicio secreto de Linux vía D-Bus), con respaldo automático a <cache dir>/grr/token.json en sistemas sin interfaz. Un token encontrado en el archivo de respaldo se auto-importa al llavero a primera vista.
Prioridad al agente. grr schema vuelca el árbol de comandos completo como JSON con configuración cero — el contrato legible por máquina para agentes de IA, descubrible sin tocar un archivo de configuración ni raspar --help. Un CLI rápido reemplaza los servidores MCP por servicio: sin configuración de MCP, solo grr schema. También hay una habilidad de agente empaquetada en skills/grr/SKILL.md — ver Habilidades de agente.

Habilidades de agente

grr incluye una habilidad de agente empaquetada: skills/grr/SKILL.md — la disciplina de descubrimiento primero (schema → api list → api describe → --dry-run), la regla de nomenclatura por id de método y el contrato de salida en un solo archivo, escrito para cualquier agente de IA. La habilidad principal más las 14 habilidades por servicio generadas se compilan en el binario, por lo que grr skills install las escribe en ~/.agents/skills/ sin red (Codex, opencode, Cursor, Gemini CLI, Copilot CLI y omp leen esa ubicación; --claude se refleja en ~/.claude/skills/ para Claude Code, que no lee nada más):

grr skills install            # all 16 into ~/.agents/skills/ (idempotent; identical files are a no-op)
grr skills install --claude   # also mirror into ~/.claude/skills/
grr skills install --force    # replace files that differ from the packaged copy
grr skills list               # the packaged set, and what each target directory holds

o instala directamente desde el repositorio con el CLI de habilidades:

npx skills add https://github.com/debanjanbasu/grr-cli

La guía de agentes del sitio lleva el mismo contrato para humanos y autores de arneses.

Rendimiento

HTTP/3 (QUIC) por defecto — h3 con conocimiento previo con una sonda autenticada al inicio y respaldo silencioso a HTTP/2; grr transport muestra lo que realmente se negoció.
Runtime de Tokio de múltiples hilos, auto-dimensionado a los núcleos — sin pool de hilos que ajustar.
Válvula de solicitudes en vuelo — un semáforo (no un pool de hilos) limita las solicitudes HTTP concurrentes a 64, manteniéndose bajo los límites de tasa por usuario de Gmail para que las ráfagas no se auto-bloqueen con 429. Los 429 se reintentan respetando Retry-After (esperas limitadas a 30s); el tiempo de espera total de la solicitud es de 30s.
Compresión siempre activa — descompresión de respuestas gzip, deflate, zstd y brotli.
E/S de archivos io_uring es una dependencia específica de Linux solo para ese objetivo, auto-detectada en tiempo de ejecución; no es una característica de Cargo.

Las mediciones de inicio, tamaño del binario y latencia de solicitudes contra los otros CLIs de Google Workspace viven en grr-cli.pages.dev/compare/, verificadas cada noche por un flujo de trabajo automatizado y re-medidas cada vez que se lanza una nueva versión.

Arquitectura

grr-cli es un crate publicado en la raíz del repositorio. src/lib.rs construye el objetivo de biblioteca grr_cli; src/main.rs es un envoltorio delgado sobre src/cli.rs, y el binario se llama grr.

.
├── src/
│   ├── core/                 # auth/device/oauth/server/store, http.rs,
│   │                         # config.rs, config_loader.rs, error.rs,
│   │                         # runtime.rs (the io_uring probe)
│   ├── commands/             # auth.rs, api.rs, setup.rs, transport.rs,
│   │                         # skills.rs, mcp.rs, ask.rs, safety.rs (the static
│   │                         # + generated.rs (GENERATED — the
│   │                         # whole service tree, ~470 KiB) and gen_dispatch.rs
│   │                         # (resolves leaf ids, funnels into the shared path)
│   ├── discovery.rs          # loader over the embedded index
│   ├── discovery/             # generated *.json index (~430 KiB, committed,
│   │                         # refreshed daily by workflow PR)
│   ├── schema.rs
│   ├── output.rs
│   ├── cli.rs
│   ├── lib.rs
│   └── main.rs
└── tests/                    # 5 integration test files

Un núcleo compartido, sin módulos de cliente por servicio: el CLI habla Discovery a través de una única ruta de llamada (src/commands/api.rs), y los modelos tipados de solicitud/respuesta de la era de la biblioteca 0.3.x han desaparecido. El repositorio también contiene el assets/, site/ (el sitio Astro en grr-cli.pages.dev, desplegado desde main por Cloudflare Pages), packaging/ y el material scripts/ utilizado para el sitio del proyecto y la distribución.

Desarrollo

grr requiere Rust nightly — el script de compilación falla con un mensaje claro en cualquier otra cadena de herramientas. rust-toolchain.toml flota en el nightly más reciente y proporciona los componentes necesarios para la compilación, mientras que .cargo/config.toml establece el cfg reqwest_unstable para HTTP/3.

cargo build
cargo test
cargo clippy --all-targets -- -D warnings
cargo fmt --all --check
cargo run -- api list

node scripts/fetch-discovery.ts          # refresh the Discovery index
node scripts/generate-commands.ts        # regenerate the service command tree
node scripts/generate-skills.ts          # regenerate skills/<service>/SKILL.md
node scripts/generate-coverage.ts        # regenerate the site coverage table
node scripts/generate-changelog.ts       # regenerate CHANGELOG.md + site data

Cada generador toma --check y sale con 1 cuando su salida está desactualizada — esa es la puerta de CI. Cambia el índice o el generador, nunca src/commands/generated.rs a mano.

Las pruebas nunca tocan credenciales reales — las rutas de tokens se inyectan, y wiremock sirve los endpoints de API.
RUST_LOG=debug rastrea solicitudes; el nivel predeterminado silencia las advertencias IPv6 inofensivas de quinn_udp (info,quinn_udp=error).
Una compilación local necesita un cliente OAuth antes de que una llamada en vivo pueda funcionar: copia .env.example a .env y complétalo (compilado por build.rs), o ejecuta grr auth setup para escribir ~/.grr/config.toml. Ver CONTRIBUTING.md.
cargo run -- api list y cargo run -- schema no necesitan ningún cliente — el índice está integrado.

Empaquetado y estado

Canal	Instalación	Estado
Lanzamientos de GitHub	Binarios de 5 plataformas (macOS arm64, Linux x86_64, Linux aarch64, Windows x86_64, Windows en ARM) construidos en etiquetas `v*`, empaquetados con UPX, `.tar.zst` en unix y `.zip` en Windows	en vivo — cada push a main lanza; lanzamientos siempre lleva lo más nuevo
crates.io	`cargo install grr-cli` (el binario se instala como `grr`; necesita nightly + `RUSTFLAGS="--cfg reqwest_unstable"` para la compilación CLI HTTP/3 predeterminada, y no trae cliente OAuth integrado)	en vivo — un crate, publicado en cada lanzamiento. La publicación confiable usa OIDC (sin tokens de API almacenados)
winget	`winget install debanjanbasu.grr`	aún no publicado — la primera presentación se estancó porque los archivos nombraban el binario según su objetivo (`windows-x86_64.exe`) mientras el manifiesto prometía `grr.exe`; la validación de winget nunca pudo encontrar el instalador anidado. Ambos lados están corregidos (los archivos v0.8.1 envían `grr.exe`; `node scripts/generate-winget.ts <tag>` deriva el manifiesto del archivo lanzado y viaja en cada lanzamiento como `grr-<tag>-winget-manifests.tar.gz`)
Homebrew	`brew tap debanjanbasu/tap && brew trust debanjanbasu/tap && brew install grr` (tap: debanjanbasu/homebrew-tap, fórmula `Formula/grr.rb`, actualizada automáticamente en cada lanzamiento)	en vivo (macOS arm64 + Linux x86_64/arm64)

El proyecto publica un paquete, grr-cli, cuyo binario es grr. Las etiquetas v* activan el flujo de trabajo de lanzamiento, y la publicación en crates.io se maneja mediante publicación confiable.

Licencia

MIT — ver LICENSE.