Semana del 8 al 14 de junio de 2026
Resumen: Una semana de consolidación a fondo: el sistema aguantó (y aprendió de) un incidente serio de infraestructura, los productos de visualización 3D están a punto de entrar en producción, y ORACLE tiene ya los cimientos para tomar decisiones con datos reales.
🛡️ El sistema se pone a prueba — y sale reforzado
El miércoles 11 el Programador de Tareas de Windows colapsó sin previo aviso: todas las tareas «solo interactivo» empezaron a rechazarse con el error 0x800710E0, dejando sin vigilancia al canal durante horas. La causa fue un colapso en cascada de los servicios de sesión que dejó el estado del programador corrupto. El único arreglo era reiniciar la máquina, y así se hizo el viernes 12.
Con el reinicio también afloró un hallazgo inesperado: había una tarea registrada como SYSTEM (invisible sin permisos de administrador) que resucitaba en cada arranque del servidor, se peleaba por el fichero de log con el watchdog ECHO y lo mataba en silencio. Lo que llevaba días pareciendo un misterio tenía una explicación concreta. Solucionado: ahora cada watchdog tiene su propio log y no se pisan. Aproveché también para reescribir arrancar_vigilancia como script PowerShell, porque la versión en batch puro rompía por las comillas en los pipes, y para añadir tres análisis nuevos a AEGIS (el módulo de seguridad): vigilancia del antivirus de Windows, comprobación de que meteoendirecto.com responde, y escaneo de posibles credenciales expuestas en logs y ficheros de estado.
El cambio más interesante de la semana en este frente es orphan_detector.py, un detector nuevo dentro de ALOY (el agente autónomo de reparación). Hasta ahora ALOY tardaba más de dos horas en detectar un protocolo huérfano, es decir, un proceso que murió pero quedó marcado como «en ejecución». El detector nuevo combina dos señales simultáneas: el PID arrancó antes del último boot del sistema, o el PID ya no existe y el heartbeat lleva más de diez minutos parado. Lo probé en un huérfano real que había dejado la caída del miércoles y lo detectó, limpió y relanzó en cuestión de segundos.
🌪️ Sand & Wind 3D — a un paso de entrar en emisión
El producto de polvo volcánico y corrientes en 3D llevaba semanas bloqueado por un bug geográfico que nadie había notado: el polvo aparecía pintado sobre Europa cuando el modelo MONARCH lo ponía claramente sobre el Sáhara. Era un error de volteo norte/sur que se coló al refactorizar la carga de datos. Corregido, y el preview lo confirma: el polvo aparece donde toca.
Sobre ese mismo producto he añadido las colas de cometa: las partículas de viento ahora llevan una estela cuya longitud es proporcional a la velocidad y cuyo color sigue un gradiente estilo pistas de esquí (verde en calma → azul → amarillo → naranja → rojo a partir de 35 m/s). Las partículas nacen en zonas con polvo, viven entre 30 y 70 fotogramas y se desvanecen al morir, de modo que los ríos de color se auto-alimentan donde hay actividad y el mapa nunca parece vacío.
También corregí el timing de render_v2.py: la fórmula de ciclos consumía los datos un poco antes de tiempo y el timestamp del overlay seguía corriendo en falso hasta +123 h después del último dato real. Ahora hay exactamente dos pasadas de 0 a 120 h más un freeze de 3 s sobre la hora del último dato. El vídeo se trocea automáticamente en cuatro partes de 15 s para el bucle en OBS. Solo falta el visto bueno al preview para lanzar el render de producción completo.
En paralelo, polvo_3d.py y muestreo.py tenían sendos fallos de descarga con el servicio ADS de Copernicus que llevaban días dando «Falta NetCDF de precipitación»: ambos consultaban la fecha de hoy cuando el dataset publica con un día de retraso. El fix consulta primero los constraints de la API para elegir la fecha más reciente con datos disponibles antes de pedir nada.
🤖 ORACLE v2 — el planificador aprende de verdad
ORACLE (el módulo de estrategia de contenido) tenía hasta ahora un problema de diseño: tomaba decisiones sin saber si las de la semana anterior habían funcionado. Eso cambia con la Fase 1: un colector diario extrae métricas reales de YouTube y GA4 (suscriptores, vistas, retención, tráfico por fuente, top vídeos) y las guarda en una base de datos local. Los lunes, un script de retrospectiva compara el plan de la semana pasada con los KPIs reales, escribe las lecciones aprendidas y las inyecta en el prompt del plan siguiente. El bucle se cierra.
La Fase 2 es la base de conocimiento: cinco libros de marketing que tenía en la biblioteca han sido destilados a playbooks aplicables al canal — método experimental de growth hacking, el embudo AARRR, monetización programática, el código reptil de la meteo según Klarić, y los principios creativos de Bassat. Cada playbook tiene secciones etiquetadas para que el planificador las inyecte cuando la situación lo pida, en lugar de recomendar siempre lo mismo genérico.
En el frente de contenido también hubo mejoras concretas:
- Los títulos de los Shorts de previsión pasaron de «Previsión meteo DD/MM» (cero términos buscables) a «[evento+zona] | Previsión España DD/MM», usando el mini-título que ya genera el redactor automático.
- Se corrigió un bug que duplicaba la marca del sitio en los resultados de Google («Meteo en Directo – Meteo en Directo»).
- atlas_archivar_directos.py está listo para pasar a «no listado» los 929 directos archivados con menos de 200 vistas y sin eventos relevantes en el título — dejando solo lo que aporta señal al canal.
🧪 Lo que ha quedado en el tintero
Hay varios pasos listos que requieren acción directa:
- Lanzar atlas_archivar_directos.py en real y registrarlo como tarea diaria a las 03:30.
- Reautorizar las métricas de ORACLE: python oracle/reauth_metrics.py (abre el navegador una vez para el token de lectura de YouTube y GA4).
- Registrar las tareas de ORACLE en el Programador de Tareas (ORACLE_Metrics diaria a las 07:50, ORACLE_Retro los lunes a las 08:10).
- Dar el visto bueno a previews/sandwind_preview.mp4 para lanzar el render completo de Sand & Wind 3D (varias horas de GPU).
- Matar el watchdog legacy e inhabilitar las tareas antiguas «meteo-watchdog», «Watch Dog Jupiter» y «Watchdog Aloy» — requiere permisos de administrador.
- Registrar AEGIS_Scan cada 6 h (requiere admin para schtasks).
📆 Próxima entrada: semana del 15 al 21 de junio de 2026.