Mantienes dos perfiles: un asistente personal y un bot de equipo, cada uno con su propio bot de Telegram o Feishu. A las 3 de la madrugada, el trabajo programado del bot de equipo termina — y el resultado se entrega desde tu bot personal. O peor: la entrega falla con Bot not in chat — el trabajo tuvo éxito, pero nadie llegó a ver el resultado. Una corrección fusionada el 31 de agosto (PR #99375) ataca toda esta clase de cruces de raíz: qué bot entrega el mensaje de un trabajo de cron lo decide el perfil dueño del trabajo — no el proceso que casualmente lo ejecutó.

La causa raíz: la identidad de entrega seguía a la “persona” equivocada

En el diseño multiprofile de Hermes, cada perfil tiene su propia configuración, credenciales, base de datos de sesiones y bots de mensajería. Pero antes de esta corrección, la entrega de cron tenía un defecto fatal: la identidad de entrega seguía al proceso que ejecutaba en lugar del perfil dueño del trabajo.

En concreto: arrancas el gateway desde tu perfil principal, y de paso aloja los trabajos del perfil B. Cuando el trabajo de B se ejecuta, el sistema lee las credenciales de “el proceso actual” — que pertenecen al perfil principal — así que el resultado de B sale por el bot del perfil principal. ¿Entregar al chat de grupo de B? El bot no está en ese grupo, así que da error. ¿Entregar al chat del perfil principal? El mensaje aterriza en el sitio equivocado. El trabajo tuvo éxito, pero el resultado se esfumó.

Y eso era solo la mitad. cron status tenía una mentira pareja: trataba el gateway de cualquier perfil vivo como prueba de salud — incluso cuando el planificador del propio perfil B no estaba corriendo en absoluto. El estado parecía verde mientras los trabajos de B nunca se dispararían.

La solución: cuatro causas raíz, un principio

El PR #99375 selecciona commits de nueve colaboradores y arregla cada eslabón de esta cadena bajo un solo principio: la identidad de entrega debe venir del perfil dueño del trabajo. En concreto:

• Cada tick de cada perfil recibe su propio mapa de adaptadores: al multiplexar (_start_multiplex), el tick de cada perfil recibe su propio mapa de adaptadores de plataforma; los adaptadores compartidos quedan reservados solo para el perfil predeterminado y nunca sirven de respaldo para perfiles secundarios no conectados;
• El ámbito de los secretos del perfil ahora cubre la entrega: antes el ámbito se restablecía justo después de ejecutar el trabajo, así que los fallbacks de standalone-send resolvían los tokens de plataforma del proceso que ejecutaba; ahora el ámbito abarca _deliver_result de principio a fin;
• Los IDs del chat principal se resuelven desde los secretos del perfil dueño: el id del chat y el del hilo destino se resuelven con get_secret bajo el ámbito del perfil dueño, en lugar de variables de entorno en bruto;
• Los trabajos de cada perfil escriben sus sesiones en su propio state.db: el SessionDB se construye con contextvars.copy_context(), así que las ejecuciones de cron de B dejan de persistir sesiones en la base de datos del perfil predeterminado;
• Rescate de preflight para perfiles satélite: los satélites enrutados por gateway.profile_routes leen la configuración principal directamente, fallan de forma cerrada y no filtran entorno;
• cron status dice la verdad: la detección del PID de systemd se limita al nombre de servicio de este perfil, y un heartbeat nunca visto se lee como advertencia, no como verde.

Cómo verificarlo en tu máquina

Tras actualizar a la última versión de main, comprueba primero que el estado del planificador de tu perfil ahora es de fiar:

# Estado del planificador propio de un perfil, no una luz verde de "cualquier gateway vivo"
hermes -p work cron status

Después ejecuta un trabajo de cron con entrega y observa si el mensaje llega desde el bot de ese perfil y aterriza en el chat principal de ese perfil. Para cualquiera que ejecute varios perfiles en varias plataformas, esta es una mejora de experiencia inmediatamente visible: los resultados ya no se esfuman, los cruces desaparecen y los mensajes fantasma de “el trabajo tuvo éxito pero nadie lo recibió” se acaban.

Cuándo puedes usarlo

El PR #99375 se fusionó el 31 de agosto de 2026 y está solo en main — todavía no está en ninguna release. Arregla un conjunto de informes reales de usuarios: #94862, #97909, #99028, #98790, #97476 — todas quejas de “el mensaje nunca llegó” o “el estado miente”.

Los perfiles múltiples son una de las capacidades más infravaloradas de Hermes: cada perfil tiene su propia identidad, memoria y bots. Para usarlos bien, empieza por nuestra guía completa de multiprofile y la guía de enrutamiento multiprofile en Feishu; el manual completo de cron está en la guía completa de automatización con cron.