jardinero
Jardinero es una plataforma de automatización que orquesta agentes externos (Tenki, Freestyle, Daytona) en sandboxes aislados para mantener repositorios: monitoriza logs con Grafana, implementa tickets de Linear y mantiene PRs sin tocar el código fuente directamente.
Ficha actualizada 25 sept 2026, 18:33 · upstream 25 sept 2026, 18:14 · release v0.9.0
Qué es jardinero
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Jardinero actúa como un ingeniero de software siempre activo que opera sobre tu códigobase mientras estás ausente. El sistema no ejecuta agentes internamente, sino que orquesta instancias efímeras en proveedores externos (Tenki, Freestyle o Daytona) para cada tarea. Cada pieza de trabajo corre en un sandbox aislado y devuelve resultados como pull requests para revisión humana.
El núcleo técnico se basa en máquinas de estado (RequestRouter, LinearImplementer, FixImplementer, PrMaintainer, LogReviewer) que gestionan flujos de trabajo completos desde la detección hasta la entrega. El estado persiste en SQLite y el sistema requiere Node 24 con pnpm para funcionar correctamente.
La arquitectura prioriza la seguridad mediante aislamiento total: cada agente corre en una VM distinta por repositorio, evitando contaminación entre trabajos. Las credenciales se gestionan exclusivamente vía variables de entorno, nunca en archivos de configuración estáticos.
- Monitorización proactiva de logs detectando errores críticos en Grafana y generando PRs automáticos con soluciones validadas.
- Implementación autónoma de tickets desde Linear: planifica, escribe código en sandbox, ejecuta tests y entrega PRs listos para merge.
- Mantenimiento continuo de pull requests respondiendo a comentarios de revisión y corrigiendo fallos en checks automáticamente.
- Orquestación de agentes externos con aislamiento por repositorio mediante imágenes personalizadas o snapshots efímeros.
- Arquitectura basada en máquinas de estado que garantiza trazabilidad completa de cada tarea desde la solicitud hasta el PR final.
- Aislamiento total mediante VMs efímeras por repositorio, evitando contaminación entre trabajos y garantizando seguridad.
- Integración nativa con GitHub Apps, Discord y Linear para orquestación sin intervención manual constante.
- Costes transparentes: registra tiempo de VM y tokens de Codex consumidos en el dashboard para auditoría financiera.
- Dependencia crítica de proveedores externos (Tenki/Freestyle/Daytona) que incrementan costes operativos según uso.
- Requiere Node 24 y pnpm, limitando despliegues en entornos legacy sin migración previa del runtime.
- La autenticación con Codex necesita renovación periódica mediante cron jobs para evitar fallos por caducidad de sesión.
- Solo soporta telemetría Kubernetes/Loki; no hay adaptadores para otras stacks de monitorización alternativas.
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.
Configurar host persistente con Node 24, ~1GB RAM y disco para SQLite. Establecer webhooks HTTPS públicos para GitHub/Linear. Usar config/local.yaml con credenciales en variables de entorno (ver docs/secrets.md). Proveedor sandbox seleccionado vía worker.runner. Para logs: Grafana remoto + token service account + Loki labels. Para tickets: Linear workspace + OAuth app client_credentials. Para chat: Discord application + guild configurado.
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.