dispatch
Dispatch es una capa de Kanban y despacho de trabajo para agentes de IA que operan sobre GitHub Issues y PRs. Es agnóstico a harnesses, mantiene GitHub como fuente de verdad y proporciona seguimiento de ejecuciones de agentes con trazabilidad completa.
Ficha actualizada 23 sept 2026, 22:46 · upstream 23 sept 2026, 22:41 · release v0.5.63
Qué es dispatch
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Dispatch funciona como una capa intermedia entre GitHub y los agentes de IA, transformando issues y PRs en colas reclamables. El sistema almacena metadatos cacheados, registros de ejecución de agentes y logs de auditoría sin modificar la fuente de verdad en GitHub.
La arquitectura soporta múltiples carriles de ejecución (por defecto 'default' y 'backlog'), con configuración vía variables de entorno. Incluye un sistema de etiquetas completo para estados, propietarios, agentes, prioridades y tipos de issue. También ofrece una opción de groomer alojado opcional que utiliza LLMs para preparar issues.
El despliegue requiere PostgreSQL con TLS configurado, Redis para caché, y S3/MinIO para almacenamiento. Soporta autenticación básica, OIDC o sin autenticación (solo desarrollo local). La complejidad es alta debido a la configuración de múltiples servicios y variables de entorno necesarias.
- Gestión de trabajo de agentes de IA sobre GitHub Issues
- Tablero Kanban para seguimiento de ejecuciones de agentes
- Trazabilidad completa de transiciones de estado de issues
- Automatización de grooming/triage de issues con LLM opcional
- Detección automática de fallos en CI y creación de issues
- Capa de despacho agnóstica a diferentes frameworks de agentes
- GitHub como fuente de verdad - no duplica datos de issues/PRs
- Sistema de etiquetas completo para status, owner, agent, priority y type
- Soporte para autenticación OIDC con integración SSO empresarial
- Groomer alojado opcional con validación de salida estructurada
- Logs de auditoría para todas las transiciones de estado
- Múltiples carriles de ejecución configurables vía variables de entorno
- Requiere acceso a GitHub API (token personal o app)
- No incluye docker-compose - orquestación manual necesaria
- Complejidad alta en despliegue inicial
- PostgreSQL obligatorio sin fallback a SQLite
- Configuración de harness de agentes no montada localmente
Capturas del proyecto
Imágenes reales detectadas en la documentación del repositorio.
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Mínimo: DATABASE_URL (PostgreSQL con sslmode=require o no-verify), GITHUB_TOKEN, DISPATCH_AGENT_TOKEN, GITHUB_REPOSITORIES. RAM 4GB, CPU 4 cores, disco 30GB. TLS en conexión a Postgres obligatorio para producción. Opcional: GitHub App auth para identidad separada en timelines, AUTH_URL si hay reverse proxy. Para grooming alojado: añadir LLM_BASE_URL y API_KEY. Verificar sslmode en DATABASE_URL - no usar require con CA autofirmada sin verify-full.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.