Ejecutas hermes update en Windows, ves pasar una pantalla de líneas de log, y la última es:

⚠ Update follow-up 'launchers' did not finish: launchers: source launcher publication failed — retry the source update (the next launch or `hermes update` retries it)

Se lee como «esto se arreglará solo la próxima vez», así que cierras la ventana. Al día siguiente hermes --version sigue reportando la versión antigua, bin\hermes.exe ya no está y solo queda hermes.cmd. Si vuelves a lanzar la actualización, sale el mismo aviso. Dos PRs mergeados el 22 y 23 de octubre de 2026 desmontan ese bucle.

Dos síntomas, una misma causa raíz

Esa línea de log son en realidad dos fallos distintos apilados:

1. Un exe en ejecución no se puede borrar. La actualización volvió a fijar Python (pm/lock.json pasó de 3.14.7 a 3.14.9), así que hay que volver a publicar los launchers — bin\hermes.exe y compañía. La publicación borra primero el hermes.exe viejo para que no tape el comando nuevo, y Windows se niega a borrar una imagen mapeada. La imagen en cuestión es justamente la que está ejecutando hermes update.
2. La escritura del stamp se salta cuando falla la publicación. Sin launcher no hay write_source_stamp, así que install-stamp.json y .hermes-bootstrap-complete siguen diciendo v0.22.4.

Y luego la tercera capa, la que hace que esto se quede pegado: el consejo del aviso —la próxima ejecución u otro hermes update lo reintenta— reintenta desde ese mismo exe. Nunca se puede limpiar. Tú esperas que se cure solo; él espera un exe distinto.

Por qué solo pasa en Windows

En POSIX, un archivo en ejecución se puede desvincular y el proceso sigue usando el inode. Windows no permite borrar una imagen mapeada.

El disparador también es estrecho: Windows, y solo al cruzar un cambio de versión de Python. Al actualizar de v0.22.3 a v0.22.4 Python se quedó en 3.14.7, así que el exe existente coincidía y se mantenía. Eso es exactamente lo que lo vuelve difícil de detectar: casi todas las actualizaciones salen bien.

Arreglo uno: si no se deja borrar, renómbralo y apártalo

#143291 añade _retire_exe en hermes_cli/_launchers.py: intenta el borrado; cuando Windows se niega porque el archivo está en uso, lo renombra y lo aparta como hermes.exe.<pid>.deleteme. Windows sí permite renombrar una imagen mapeada — distlib hace el mismo movimiento. La copia apartada se recoge en una publicación posterior, cuando su proceso ya ha terminado.

Como la publicación ya no falla, el stamp vuelve a escribirse. _collect_retired además barre el hermes.exe.deleteme que distlib deja por su cuenta cuando el exe que se reemplaza es el de la propia actualización.

Arreglo dos: dejar de degradar a .cmd

Arreglar solo el borrado no bastaba. #143339 documenta la otra mitad: el proceso de actualización activa únicamente el entorno de dependencias, que no tiene distlib, y las site-packages del Python de la store (donde vive pip) quedan fuera. Entonces mint_launcher no encuentra ningún ScriptMaker y publica un .cmd; y como el arreglo anterior ya puede renombrar y apartar el exe en ejecución, ese exe quedó retirado para siempre. La instalación termina con hermes.cmd y nada más.

El instalador originalmente acuñaba su primer exe con el pip incluido en python-build-standalone, una ruta que la actualización nunca consultaba. El arreglo la conecta: cuando el proceso en ejecución no puede importar distlib, mint_launcher carga pip._vendor.distlib desde al lado del intérprete que está vinculando (<python>\Lib\site-packages\pip\_vendor\distlib, incluido en toda build de PBS), bajo un nombre de módulo privado para que el pip de la store nunca responda a import pip dentro del proceso. Sigue habiendo un fallback a .cmd para un intérprete sin distlib alguna: solo que ahora es raro.

Qué revisar en tu máquina

Si estás en Windows y hace poco cruzaste un cambio de versión de Python, tres comprobaciones rápidas:

hermes --version                                    # versión semántica y Python vinculado

• ¿Sigue ahí bin\hermes.exe, dentro de tu home de Hermes? Si solo ves hermes.cmd, te has topado con esto.
• Abre install-stamp.json y .hermes-bootstrap-complete: el commit que indican debería ser la build que estás ejecutando de verdad, no la anterior.
• Si no coinciden, pásate primero a una build que incluya los dos arreglos y luego ejecuta hermes update una vez más — solo el código de publicación nuevo puede mover el exe viejo fuera del camino mientras está en ejecución.

Si la instalación parece genuinamente rota en vez de medio actualizada (un worktree de git sucio, comandos que a veces existen y a veces no), la guía de reparación de git dañado tiene la lista de comprobación larga. La semántica de canales y rollback está en la guía del canal estable, y los flags viven en la referencia de hermes update.

Estado del release

Ambos arreglos se mergearon a main el 22 y 23 de octubre de 2026; un tercer PR (#143261) arregla la huella en disco del E2E de Windows, que había llenado el runner — cada recorrido de prueba ahora borra su instalación al desmontar. Los fallos los detectó la ejecución E2E del release candidate v0.22.5 en la ruta de actualización de v0.22.4 a HEAD, así que la población afectada son los usuarios de Windows que actualizan desde v0.22.4. La última release sigue siendo v0.22.4 (21 de octubre): estos arreglos todavía no han llegado al canal estable.

Una nota sobre por qué esto no es simple mantenimiento de CI: en cuanto un launcher de Windows degrada a .cmd, los accesos directos, las tareas programadas y cualquier script que tenga .exe en su entrada de PATH fallan en silencio — y la única señal es esa única línea ⚠.