Los 13 agentes que mantienen el sistema vivo y mejorando: 6 con LLM para reparar código y revisarlo, 7 deterministas que vigilan procesos, memoria, OOM, backups y publican métricas. Es la capa que evita que tengas que entrar al servidor.
Lee GitHub Issues con label "bug"/"code-review" y la cola interna improvement_queue. Usa ReAct con LLM para implementar el fix mínimo, ejecuta pytest, commit+push si pasan. Filtro de errores transitorios (P1.1): 429/503/timeout no disparan patch — se silencian 1h porque no son bugs sino síntomas de cuota agotada o caída ajena.
git diff de los últimos 7 días en cada repo activo. El LLM analiza cambios buscando bugs reales (condiciones de carrera, excepciones tragadas, lógica invertida). Abre GitHub Issue con el fix propuesto, máx 2 por repo y ciclo.
Consulta PyPI para cada requirements.txt. Clasifica cambios en PATCH/MINOR/MAJOR. Auto-aplica PATCH y MINOR con rollback. MAJOR de paquetes críticos (torch, sklearn) requiere aprobación por Telegram.
Ejecuta pytest sobre los 3 proyectos ML clave. Si hay fallos el LLM analiza el traceback y propone el fix. Reporta a Telegram y abre GitHub Issue. Si un proyecto no tiene tests, hace HTTP health-check como fallback.
Recorre todos los repos del portfolio. Si hay cambios sustantivos (filtro de ruido: ignora *.log, __pycache__, *_cache.json), commit + push con mensaje "chore: auto-sync". Detecta repos sin remoto y silencia el aviso 7 días.
Tras cada improvement aplicado por ProjectImprover, refresca dos campos del proyecto en MySQL: descripcion_corta (≤160 chars, forzado por LLM + truncado por palabra) y descripcion_larga (preserva la sección "Sobre el Proyecto" curada, sustituye solo el bloque "Última actualización"). Coalesce de mejoras múltiples del mismo slug en un solo write (P1.2).
Cada 30 min revisa agent_status.json buscando agentes "silenciosos" (sin reporte >2h). Lee los logs de las últimas 30 min, clasifica errores en críticos/no críticos por keywords (OOM, ENOMEM, traceback…), y reinicia el agente si está dead. Sin LLM — heurística determinista.
Cada 5 min escanea state.db en busca de tareas "running" colgadas más allá del umbral. Reinicia el servicio responsable vía systemctl, marca la tarea como recuperada en agent_errors, y limita reintentos para no entrar en bucle de restart.
Cada 15 min mide RAM/swap/disco con psutil. Si RAM ≥90% o swap=100%, pausa automáticamente 7 agentes pesados (improver, builder, bug_fixer, test_runner, competitive, market_review, analytics). Reanudación con histéresis al 80%, o forzosa tras TTL 4h aunque la RAM siga alta (P4.1).
Cada 15 min healthcheck profundo a los 17 servicios ML (puertos 8001-8102). Distingue vivo (2xx/3xx/401/403) de degradado (404+/openapi.json sí responde) y muerto (5xx o timeout). Si OOM kill detectado, amplía MemoryMax 25% y reinicia. Los degradados NO se reinician — alerta para investigación.
Diario a las 05:00 UTC. Lee la tabla MySQL projects del portfolio y sincroniza con /var/www/neuralops/projects.json. Asigna puertos libres a proyectos nuevos, normaliza keywords y categoría → sector. Sin esto, los agentes de NeuralOps no se enteran de proyectos añadidos vía web.
Cada domingo 23 UTC limpia el state.db: events >30 días, alertas >14 días, llm_cache >7 días. NO toca colas operativas (linkedin_drafts, email_drafts). También prunes llm_metrics >30 días. Sin esto, la tabla memory crece sin freno (~340 events/día).
Cada 60 s captura el snapshot de core.system_telemetry (Groq quota, errores 24h, latencia LLM P95/P99, colas, agentes pausados) y lo escribe atómicamente en /var/www/neuralops/state/telemetry.json. El portfolio Laravel lo sirve como /sistema sin tener que llamar a Python.
Otros clusters