Sistema autónomo de 12 capas — monitoreo, auto-reparación, diagnóstico con IA y memoria persistente.
Version 7.6 + 8 mejoras operativas · Auditado 2026-07-24 · Ecosistema HJAZZI
Qué es Meta Evolution y para qué sirve, explicado desde cero y sin tecnicismos, más el detalle técnico, los resultados de la auditoría y una hoja de ruta de mejoras ordenada por urgencia.
Incluye el hallazgo más importante de la auditoría: el código de las aplicaciones no tiene copia de seguridad.
⬇ Descargar informe o leerlo en el navegador →Referencia completa: arquitectura, las 12 capas en detalle, flujo de datos, comandos y rutas de archivos.
⬇ Descargar META_EVOLUTION.mdSacá una foto desde el celular y los datos van solos a la planilla: proveedor, RUT, número, fecha, neto, IVA y total. Si ya cargaste ese documento antes, lo saltea.
Marca en amarillo lo que conviene mirar con el original al lado: cuando la suma no cuadra, la moneda no es UYU, el RUT no es uruguayo, o la extracción salió floja.
📷 Cargar factura ⬇ bajar la planillaSubí imágenes, documentos, capturas — cualquier archivo de hasta 100MB. Se guarda con hash único y te da un link directo para compartir o descargar.
📤 Ir a upload
auto_watcher.py fallaba en cada ejecución con
UnboundLocalError: heal_state. La variable se usaba en la rama
«no hay servicios caídos» pero se asignaba después del return de
esa rama — o sea, fallaba justamente cuando todo estaba bien.
Durante ese tiempo el sistema monitoreaba pero no reparaba: si un servicio caía de madrugada, nadie lo levantaba. Corregido y verificado.
Dos capas chequeaban el gateway en el puerto 8080 cuando escucha en
el 8765. Y health_checker verificaba nicolas
consultando el puerto de logis — daba ✅ midiendo el servicio
equivocado. El fallo más peligroso, porque no parece un fallo.
Benchmark: 5/8 → 8/8 (grado A). Healthcheck: 9/10 → 10/10.
hermes-dashboard, hermes-upload y acta-core
no estaban en la lista de vigilancia: activos, pero invisibles para el
auto-reparador. Corregido: 9 → 12 servicios vigilados.
Tres de los cuatro fallos venían del mismo sitio: cada capa tenía su propia lista de servicios y puertos, escrita a mano y duplicada en cuatro archivos. Con el tiempo dejaron de coincidir con la realidad, y como nadie las comparaba, la divergencia creció en silencio durante meses.
Por eso se añadió un registro único y un detector de deriva que lo compara contra la realidad cada día. Habría cazado los cuatro fallos automáticamente.
Watchdog general: verifica gateway activo, scripts en disco, heartbeats recientes, espacio en disco. Es la primera línea de defensa.
Toma métricas del VPS: estado de servicios (systemctl + docker), RAM, disco, load average, health HTTP, nginx, UFW, puertos. Genera la serie temporal timeseries.jsonl.
Cerebro de auto-reparación: detecta servicios caídos en 3+ mediciones consecutivas, consulta la memoria antes de actuar, intenta restart, y aplica circuit breaker (3 strikes → escalar).
API unificada sobre service_memory.json, incidents.json y lessons.json. Todos los scripts la consultan antes de decidir. Proporciona historial, acción sugerida y patrones.
Analiza tendencias de las últimas 24h. Detecta drift en health checks, patrones de memoria, servicios con reinicios frecuentes. Genera alertas anticipadas.
8 tests de calidad con score A-F. Verifica respuesta de servicios, disponibilidad 24h, latencia. Consulta systemctl y docker en VIVO, sin depender de archivos.
Reporte diario con score de salud, benchmarks, incidentes, auto-healing, predicciones y tendencias de mercado. Auto-actualiza STATE.md.
Reflexión al finalizar cada sesión de Hermes. Analiza lo hecho, detecta patrones reusables y propone nuevos skills. Funciona standalone.
Framework para proyectos con ciclo de 9 pasos. 4 proyectos activos: auto-deployer, blog-publisher, trading-agent, visual-marketer.
Escanea Hacker News, GitHub Trending y Google Trends. Genera reportes con oportunidades de negocio identificadas automáticamente.
Purga snapshots >30d, comprime incidents resueltos >7d, rota cron outputs, reporta heartbeats incompletos. Corre sin supervisión.
La primera capa con razonamiento. Se dispara solo cuando el circuit breaker se abre — es decir, cuando el auto-reparador ya agotó sus tres intentos y se rindió. Reúne logs, métricas e historial, y le pide a Claude Fable 5 causa raíz, evidencia y acciones priorizadas.
En operación normal sale en 130 ms sin gastar un token. En Fase 1
solo diagnostica: no ejecuta nada, la decisión sigue siendo humana. Un diagnóstico
real costó $0.047.
Verifica que el sistema no se mienta a sí mismo. Compara el registro único
(config/services.json) contra la realidad: qué servicios existen, qué
puertos escuchan de verdad, qué endpoints responden, y qué puertos hay codificados
a mano en el código de las capas.
Validado inyectando deriva a propósito: detectó las cinco discrepancias.
Flask + gunicorn en puerto 5050. Muestra servicios, RAM, disco, uptime 24h por servicio y eventos recientes. Auto-refresh cada 30s. Sin base de datos — lee los JSON que el sistema ya genera.
Cuando un servicio cae 3 mediciones consecutivas, envía mensaje a Telegram. También notifica recuperaciones y alertas críticas si 3 reintentos fallan. Configurable vía token.
Verifica cada 15min que 10 endpoints respondan HTTP 200. No solo mira systemctl — verifica que la app realmente conteste. Endpoints /health agregados a servicios que no tenían.
Todos los scripts escriben eventos en events.jsonl. Un solo archivo para todo el ecosistema. Consumible desde el dashboard y desde terminal con tail -f.
Archiva automáticamente servicios sin actividad >7 días. Mantiene la memoria limpia y las predicciones precisas. Corre cada 24h a las 2AM.
health_monitor (Capa 1)
│ cada 15min
▼
timeseries.jsonl ◄── predictor (Capa 4)
│
├──► auto_watcher (Capa 2) cada 5min
│ ├──► memory_core (Capa 3)
│ ├──► systemctl restart
│ ├──► incidents / lessons / service_memory
│ └──► event_logger + Telegram
│
├──► daily_digest (Capa 6) → STATE.md
│
│
├──► ¿3 fallos? ──► deep_diagnosis (Capa 11)
│ └──► Fable 5 → informe de diagnóstico
│
└──► dashboard (puerto 5050)
└──► /api/system + /api/events
config/services.json ──► drift_detector (diario)
(registro único) └──► ¿el registro miente?# Ver estado completo del sistema
python3 ~/.hermes/scripts/health_checker.py
# Verificar que el registro coincide con la realidad
python3 ~/.hermes/scripts/drift_detector.py
# Ver servicios activos (los 12)
for s in hermes-gateway hermes-dashboard hermes-upload acta-core \
shop-hjazzi uropic shangrila estiloyvida logis nicolas leadcapture; do
echo "$s: $(systemctl is-active $s)"
done
# Ver heartbeats
python3 -c "import json; print(
json.dumps(json.load(open(
'$HOME/.hermes/evolution/metrics/heartbeats.json'
)), indent=2))"
# Ver eventos recientes
tail -10 ~/.hermes/evolution/metrics/events.jsonl \
| python3 -m json.tool
# Ver métricas del dashboard
curl -s http://127.0.0.1:5050/api/system | python3 -m json.tool