# Informe Meta Evolution **Ecosistema HJAZZI** · VPS Contabo (Ubuntu) · Auditoría del 2026-07-24 Este informe explica qué es Meta Evolution, para qué sirve, en qué estado está, y qué conviene mejorar. Está escrito en dos niveles: la **Parte 1** no requiere conocimientos técnicos; de la **Parte 3** en adelante se entra en detalle. --- # PARTE 1 — Para qué sirve, en palabras simples ## El problema que resuelve Tienes varios negocios funcionando en internet: la tienda HJAZZI, los sorteos de UROPIC, el mercado Shangri-La, Estilo y Vida, LOGIS, la web de Nicolás, el capturador de contactos y algunos servicios internos. Todos viven dentro de un mismo computador alquilado que está encendido las 24 horas del día. Imagina ese computador como **un edificio con doce locales**. Cada local es uno de tus negocios. El problema de un edificio así es sencillo de enunciar: **si un local cierra a las tres de la madrugada, nadie se entera.** Tus clientes llegan, encuentran la puerta cerrada, y se van. Tú lo descubres horas después — o no lo descubres, y solo notas que ese mes vendiste menos. Contratar a alguien para vigilar el edificio 24 horas es caro. Revisarlo tú mismo cada día es agotador y no cubre las noches ni los fines de semana. ## La solución Meta Evolution es **el personal de mantenimiento automático del edificio**. Son programas que trabajan solos, sin sueldo y sin descanso: **El vigilante** pasa cada 15 minutos y anota si cada local está abierto, cuánta electricidad se está usando y cuánto espacio queda en la bodega. **El enfermero** es el más importante. Si el vigilante reporta que un local lleva un rato cerrado, el enfermero va e intenta reabrirlo. Lo intenta tres veces. Si a la tercera no lo consigue, deja de insistir —para no hacer daño— y avisa a un humano. **El inspector** toca el timbre de cada local para confirmar que de verdad hay alguien atendiendo. Es distinto del vigilante: un local puede tener las luces encendidas y la puerta abierta pero sin nadie dentro. El inspector detecta eso. **El archivista** anota todo lo que pasa: qué se rompió, cuándo, qué se hizo, si funcionó. Con el tiempo el sistema aprende que "este local siempre falla los lunes" o "a este no sirve de nada reiniciarlo". **El adivino** revisa las tendencias. Si un local tarda cada día un poco más en responder, avisa **antes** de que se caiga del todo. **El contador** genera cada mañana un resumen: cómo está todo, qué pasó ayer, qué se reparó solo. ## Qué ganas con esto - Los problemas se arreglan solos de madrugada, sin despertarte. - Cuando algo no se puede arreglar solo, te enteras enseguida en vez de por un cliente enojado. - Tienes historial: no dependes de recordar qué pasó hace tres semanas. - Escala sin costo: da igual que sean 12 locales o 30. ## Lo que Meta Evolution NO hace Conviene tener las expectativas claras: - **No crea ni mejora tus negocios.** Los mantiene funcionando; no vende por ti. - **No arregla problemas de fondo.** Si una aplicación tiene un error de programación, el sistema la reinicia una y otra vez, pero no corrige el error. - **No sustituye copias de seguridad.** Mantener algo encendido y tener una copia de respaldo son cosas distintas. Esto es importante — ver la Parte 4. --- # PARTE 2 — Cómo funciona ## Las doce capas Cada capa es un programa independiente que hace una sola cosa. No hay base de datos: todo se guarda en archivos de texto. Si un archivo se corrompe, se pierde ese dato, no el sistema entero. | # | Capa | Qué hace | Cada cuánto | |---|---|---|---| | 0 | **Guardian** | Vigila que el propio sistema de vigilancia esté vivo | 15 min | | 1 | **Health Monitor** | Toma las métricas: servicios, RAM, disco, carga | 15 min | | 2 | **Auto Watcher** | Repara servicios caídos, con límite de 3 intentos | 5 min | | 3 | **Memory Core** | Memoria persistente: incidentes, lecciones, patrones | continuo | | 4 | **Predictor** | Detecta degradación antes de que sea una caída | 1 hora | | 5 | **Benchmark Suite** | 8 pruebas de calidad con nota de A a F | diario 6AM | | 6 | **Daily Digest** | Informe diario del estado del ecosistema | diario 8AM | | 7 | **Post-Session** | Reflexión al cerrar una sesión de trabajo | por evento | | 8 | **Proyectos** | Marco para proyectos autónomos | bajo demanda | | 9 | **Market Intelligence** | Escanea oportunidades de negocio | diario 7AM | | 10 | **Memory Compactor** | Limpia datos viejos para que no se acumulen | diario 3AM | | 11 | **Deep Diagnosis** | Diagnóstico con IA cuando todo lo demás falló | 15 min* | | — | **Drift Detector** | Verifica que el sistema no se mienta a sí mismo | diario 5AM | \* Solo consume dinero cuando hay un problema real que las demás capas no pudieron resolver. En operación normal termina en 130 milisegundos sin gastar nada. ## El circuito completo ``` health_monitor ──► timeseries.jsonl ──► predictor (¿está abierto?) │ (¿va a fallar?) ▼ auto_watcher (reinicia si cayó) │ ¿falló 3 veces? │ ▼ deep_diagnosis (IA investiga y explica) │ ▼ escalar a un humano ``` La lógica de fondo: **cada nivel solo entra cuando el anterior se rindió.** Es barato y rápido en el caso normal, y solo se vuelve costoso cuando de verdad hace falta. ## Los doce servicios vigilados | Servicio | Puerto | Qué es | |---|---|---| | hermes-gateway | 8765 | Cerebro central del agente Hermes | | hermes-dashboard | 5050 | Panel de métricas | | hermes-upload | 5060 | Subida de archivos | | acta-core | 8000 | Motor de ingesta documental (ACTA) | | shop-hjazzi | 5021 | Tienda HJAZZI | | uropic | 5010 | UROPIC Sorteos | | shangrila | 5020 | Mercado Shangri-La | | estiloyvida | 5022 | Tienda Estilo y Vida | | logis | 5015 | LOGIS Multi-nicho | | nicolas | 5016 | Web de servicios de Nicolás | | leadcapture | 5030 | Captura de contactos | | n8n | 5678 | Plataforma de automatización (Docker) | --- # PARTE 3 — Estado actual y auditoría ## Resultado general El sistema funciona y lleva acumuladas más de 4.800 mediciones. Pero la auditoría del 2026-07-24 encontró **cuatro fallos**, uno de ellos grave, y todos llevaban tiempo sin detectarse. ## Fallo 1 — El auto-reparador llevaba tiempo muerto **Gravedad: alta.** `auto_watcher.py` fallaba en **cada** ejecución, cada cinco minutos, con este error: ``` UnboundLocalError: cannot access local variable 'heal_state' ``` La causa: la variable se usaba en la rama "no hay servicios caídos" pero se asignaba unas líneas más abajo, después del punto de salida de esa rama. Dicho de otro modo, **fallaba justamente cuando todo estaba bien** — que es el caso normal el 99% del tiempo. Consecuencia práctica: durante todo ese periodo el sistema vigilaba y anotaba, pero **no reparaba nada**. El enfermero estaba de baja y nadie lo sabía. *Corregido y verificado.* ## Fallo 2 — El inspector tocaba en puertas equivocadas **Gravedad: media-alta.** Dos capas verificaban el gateway en el puerto 8080, pero el gateway escucha en el **8765**. Toda la documentación decía 8080 — un residuo de un incidente anterior. Peor todavía: `health_checker` verificaba el servicio `nicolas` consultando el puerto **5015**, que pertenece a `logis`. Como logis sí respondía, el informe decía "nicolas ✅ correcto" **sin haber comprobado nunca nicolas**. Este es el fallo más peligroso de los cuatro, porque no parece un fallo: el sistema informaba salud mientras verificaba lo que no era. *Corregido: el benchmark pasó de 5/8 a 8/8 (grado A) y el inspector de 9/10 a 10/10.* ## Fallo 3 — Tres servicios invisibles **Gravedad: media.** `health_monitor` no vigilaba `hermes-dashboard`, `hermes-upload` ni `acta-core`. Los tres estaban activos, pero eran invisibles para el sistema: si se caían, el auto-reparador ni sabía que existían. *Corregido: pasó de 9 a 12 servicios vigilados.* ## Fallo 4 — Documentación desviada de la realidad **Gravedad: baja, pero es la causa de los otros.** La documentación declaraba 17 tareas programadas cuando había 13, listaba 9 servicios cuando había 12, y omitía por completo `acta-core` y `hermes-upload`. *Corregido: documentación y `STATE.md` sincronizados con la realidad verificada.* ## La causa raíz común **Tres de los cuatro fallos comparten un mismo origen:** cada capa tenía su propia lista de servicios y puertos, escrita a mano y duplicada en cuatro archivos distintos. Con el tiempo esas listas dejaron de coincidir con la realidad, y como nadie las comparaba, la divergencia creció en silencio durante meses. Esto no es un descuido de quien lo programó; es un defecto estructural previsible en cualquier sistema con configuración duplicada. ## Lo que se añadió para que no se repita **Registro único** (`config/services.json`): una sola lista oficial de los doce servicios, con su puerto y su forma de verificación. **Detector de deriva** (`drift_detector.py`): cada día a las 5 de la mañana compara ese registro contra la realidad — qué servicios existen, qué puertos escuchan de verdad, qué endpoints responden, y qué puertos hay escritos a mano en el código. Si algo no cuadra, avisa. Se validó inyectando errores a propósito: detectó las cinco discrepancias, incluida exactamente la clase de fallo encontrada hoy. **Habría cazado los cuatro fallos automáticamente.** ## La nueva Capa 11 — diagnóstico con IA Cuando el auto-reparador agota sus tres intentos, antes simplemente se rendía. Ahora entra **Claude Fable 5**: reúne los registros del sistema, el historial del servicio y las métricas recientes, y produce un informe con la causa raíz probable, la evidencia que la sustenta, y acciones concretas priorizadas. Está en **Fase 1: solo diagnostica, no ejecuta nada.** La decisión sigue siendo humana. En la prueba real dio una buena señal: ante evidencia insuficiente **se negó a inventar una causa raíz**, y distinguió correctamente entre un servicio detenido a propósito y uno que está fallando — que son problemas opuestos. Costó $0.047. --- # PARTE 4 — Cómo mejorarlo Ordenado por urgencia real, no por dificultad. ## 🔴 Prioridad 1 — Las aplicaciones no tienen copia de seguridad **Este es el punto más importante de todo el informe.** La copia diaria que corre a las 4 de la mañana respalda **únicamente los archivos internos de Meta Evolution**: memoria, métricas, incidentes. Son 2,7 MB de archivos JSON. **El código de tus aplicaciones no se respalda.** Ni la tienda, ni UROPIC, ni Shangri-La, ni ninguna otra. Y esto ya te costó caro una vez: seis servicios siguen marcados como "código perdido en la migración" — sus archivos de arranque existen, pero las aplicaciones no se pudieron recuperar porque no estaban en ninguna copia. Existe un script hecho precisamente para evitar que se repita (`app_backup.sh`, que sube el código a GitHub), pero **nunca se programó** — necesita una clave SSH de GitHub que no está configurada. Tienes la lección aprendida, tienes la herramienta escrita, y está apagada. **Qué hacer:** 1. Generar una clave SSH en el servidor y añadirla a GitHub. 2. Registrar `app_backup.sh` como tarea diaria. 3. Verificar que la primera copia sube de verdad — no darlo por hecho. 4. Probar una restauración real. Una copia que nunca se restauró no es una copia, es una suposición. ## 🟠 Prioridad 2 — Las alertas no llegan a ningún lado El sistema detecta problemas, los anota y prepara el aviso por Telegram — pero el token de acceso no está configurado, así que **el mensaje no sale**. Es como una alarma de incendios que enciende una luz en el sótano. **Qué hacer:** crear un bot de Telegram, obtener el token y configurarlo. Es una tarea de quince minutos que convierte la vigilancia pasiva en aviso real. ## 🟠 Prioridad 3 — Migrar las capas al registro único El detector de deriva **avisa** cuando las listas se desincronizan, pero no las corrige: cada capa sigue leyendo su lista escrita a mano. Es una mejora a medias, y es honesto decirlo. El siguiente paso natural es que las cuatro capas lean de `config/services.json`, con lo que el problema desaparece de raíz en vez de quedar solo monitorizado. **Esfuerzo:** moderado. **Beneficio:** elimina definitivamente la clase de fallo más frecuente encontrada. ## 🟡 Prioridad 4 — Decidir sobre los seis servicios perdidos Seis servicios llevan meses marcados como "pendientes de restaurar". Ocupan espacio mental, ensucian los informes y generan ruido en las verificaciones. **Qué hacer:** decidir uno por uno — restaurarlo o retirarlo formalmente. Un sistema con seis fantasmas permanentes entrena a quien lo mira a ignorar las alertas, que es exactamente lo que no quieres. ## 🟡 Prioridad 5 — Poner saldo para la Capa 11 La cuenta de OpenRouter está en cero, así que el diagnóstico con IA no puede funcionar. La capa maneja el error sin romper nada, pero tampoco diagnostica. Cada diagnóstico cuesta unos **5 centavos de dólar** y solo se activa cuando hay un problema real. Con 10 dólares tienes cobertura para meses. ## 🟡 Prioridad 6 — Dos capas sin latido `memory_compactor` y `market_intelligence` corren correctamente pero no registran su "latido", así que el Guardian no puede confirmar que sigan vivos. Si dejaran de funcionar, nadie lo notaría. **Qué hacer:** añadirles la llamada a `heartbeat.py`. Son dos líneas. ## 🟢 Prioridad 7 — El publicador de blog está a medias `blog_publisher.py` marca los temas como publicados y guarda el registro, pero **no genera el artículo**. Actualmente registra publicaciones que no existen. **Qué hacer:** completarlo, o desactivarlo hasta que se complete. Un proceso que informa éxito sin hacer el trabajo es peor que uno apagado. ## 🟢 Prioridad 8 — Fase 2 de la Capa 11 Cuando hayas leído varios diagnósticos reales y el criterio te convenza, se puede habilitar la ejecución automática con lista blanca: reiniciar servicios, recargar nginx, limpiar temporales. Nunca borrar datos ni tocar configuración crítica. **No lo actives antes de haber revisado diagnósticos reales.** Dar poder de ejecución a un sistema cuyo criterio no has validado es cómo se rompe un servidor de madrugada. ## Sobre la exposición pública de este sitio `evolution.hjazzi.com` es público y sin contraseña. Cualquiera puede ver la arquitectura, los nombres de los servicios y sus puertos internos. Los puertos internos no son accesibles desde fuera, así que el riesgo directo es bajo. Pero publicar qué tienes, cómo está montado y qué partes están incompletas le ahorra trabajo de reconocimiento a quien quiera atacarte. **Sugerencia:** proteger el sitio con usuario y contraseña, o mover el detalle de arquitectura a un documento privado y dejar público solo lo general. Es una decisión tuya; conviene tomarla a conciencia y no por omisión. --- # Resumen ejecutivo **Qué es:** un sistema de doce capas que vigila, repara y documenta tu infraestructura de forma autónoma, sin intervención humana en el caso normal. **Cómo está:** funcionando y verificado. Se encontraron y corrigieron cuatro fallos, uno grave —el auto-reparador llevaba tiempo inoperativo—, y se añadieron dos capas nuevas: diagnóstico con IA y detección de deriva. **Lo más urgente:** el código de tus aplicaciones no tiene copia de seguridad, y ya perdiste seis aplicaciones una vez por esa misma razón. La herramienta para evitarlo está escrita y apagada. Encenderla es cuestión de una tarde. **La lección de la auditoría:** el fallo más caro no fue el que rompía cosas, sino el que decía que todo estaba bien mientras verificaba lo que no era. Por eso la mejora más valiosa no fue arreglar los cuatro errores, sino añadir el mecanismo que los habría detectado solo. --- *Informe generado el 2026-07-25 · Ecosistema HJAZZI · Documentación técnica completa en `META_EVOLUTION.md`*