Trasladar un proyecto de Codex a Hermes en un servidor

Para obtener ayuda sobre el uso del servicio, consulta la documentación de Ailoot.

¿Qué debes preparar antes de transferir un proyecto de Codex a Hermes?#

Un repositorio es una carpeta de proyecto con su historial de cambios de Git. Una copia de trabajo contiene los archivos que editas. El objetivo aquí es llevar esa copia al servidor y continuar el desarrollo. Todavía no hace falta poner la aplicación a disposición de los visitantes.

Si el agente aún no está instalado en el servidor, empieza por instalar Hermes Agent en un VPS. En este caso, necesitarás una instalación funcional de Hermes, el terminal del servidor y Git. Necesitas un repositorio remoto accesible desde el servidor; si todavía no tienes uno, créalo primero y guarda allí el proyecto sin secretos. Si el repositorio es privado, configura de antemano el acceso de lectura desde tu propia cuenta; no pongas un token en la URL del repositorio ni se lo envíes al agente en un mensaje.

Pausa las ediciones paralelas del proyecto durante la transferencia. En el ordenador de origen, abre un terminal directamente en la carpeta del proyecto y ejecuta:

git status --short --branch
git status --short --ignored

El primer comando muestra la rama y el estado de los archivos. M indica una modificación y ??, un archivo que Git aún no sigue. En el segundo comando, los archivos ignorados se marcan con !!. Que el estado aparezca limpio normalmente no demuestra que no haya archivos necesarios fuera de Git.

Guarda los cambios necesarios en un commit independiente y haz push de la rama correcta a tu repositorio remoto como de costumbre. Antes de hacer push, comprueba qué incluye el commit: no debe contener claves, contraseñas ni datos reales de usuarios. Si no sabes qué cambios guardar, pide primero a Codex que los enumere y explique su propósito, sin borrar archivos ni hacer push al repositorio.

No des por hecho que clonar el repositorio transferirá una base de datos externa, el contenido de una carpeta ignorada o tus conversaciones con Codex. El historial del chat, las suscripciones, los perfiles y la configuración propia de los agentes no forman parte de este método de transferencia.

Copiar la rama correcta al servidor#

Primero, guarda en el ordenador de origen la salida de este comando:

git status --porcelain=v2 --branch

La línea # branch.oid muestra el commit actual y # branch.head muestra la rama. Un commit es una versión guardada del proyecto. En un proyecto típico con commits existentes, esto te permite comparar la copia de origen con la nueva; la comparación no comprueba los cambios sin confirmar.

En el servidor, ve al directorio donde guardarás tus proyectos. Clona el repositorio en una carpeta nueva. En la plantilla siguiente, sustituye REPOSITORY_URL por la URL de tu repositorio, BRANCH_NAME por el nombre de la rama que guardaste e incluiste en el push, y my-project por el nombre que quieras para la nueva carpeta:

git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch

Esto es una plantilla, no una URL lista para copiar. git clone crea una carpeta y una copia de trabajo de la rama seleccionada. Si la carpeta de destino ya existe, debe estar vacía: no borres su contenido para volver a ejecutar el comando; elige un nombre nuevo.

Compara # branch.oid en ambas copias. Si los valores difieren, no empieces a corregir código en el servidor: comprueba la rama seleccionada, los commits que incluiste en el push y si se hicieron cambios en paralelo. Si la salida del estado muestra archivos modificados, investígalos por separado. No uses una limpieza ni un restablecimiento forzado para «hacer que coincidan».

Los repositorios con submódulos de Git —repositorios anidados— también requieren que obtengas su contenido. git clone tiene la opción --recurse-submodules para hacerlo; úsala si el proyecto realmente contiene submódulos y has comprobado sus URL. Los proyectos con otros recursos externos pueden requerir un procedimiento adicional descrito en el README.

Restaurar las dependencias según las reglas del proyecto#

Primero, lee el README y los archivos de configuración del proyecto. Averigua qué versión del entorno de ejecución se necesita y qué gestor de paquetes se usa para instalar las dependencias. No sustituyas la herramienta habitual del proyecto por npm solo porque aparezca en el ejemplo siguiente.

Ejemplo hipotético con Node.js y npm: el repositorio tiene archivos package.json y package-lock.json coherentes, y en el servidor está instalada una versión de Node.js adecuada para el proyecto. En ese caso, ejecuta esto en la carpeta del proyecto:

npm ci

Según la documentación de npm ci, el comando instala las dependencias de todo el proyecto desde el archivo de bloqueo sin reescribir package.json ni package-lock.json. Si su contenido no es coherente, la instalación falla. Antes de instalar, se elimina cualquier carpeta node_modules existente.

Si el archivo de bloqueo se creó con opciones que afectan al árbol de dependencias, como --legacy-peer-deps, npm ci necesita las mismas opciones. Comprueba las instrucciones y la configuración del proyecto de origen. No borres el archivo de bloqueo ni actualices todas las dependencias para ocultar el primer error de transferencia.

Antes de instalar, comprueba los comandos de instalación e inicio de tu proyecto. Ejecútalos en una copia de trabajo independiente sin acceso a los datos de producción y configura cualquier valor de entorno necesario fuera del chat y de Git. Siempre que sea posible, utiliza credenciales de prueba con permisos limitados para comprobar el proyecto. Si el proyecto depende de una base de datos o de archivos, restaura primero un conjunto de datos de prueba permitido siguiendo sus instrucciones; los archivos de código fuente idénticos no sustituyen esos datos.

Tras la instalación, ejecuta las comprobaciones existentes del README: las pruebas y una compilación, si el proyecto las proporciona. Los nombres de los comandos dependen del proyecto. Que las dependencias se instalen correctamente no significa todavía que la aplicación funcione.

Abrir la copia de trabajo en Hermes#

En el terminal del servidor, ve a la raíz de la nueva copia e inicia el agente que ya está instalado:

cd /absolute/path/to/my-project
hermes

Aquí, /absolute/path/to/my-project es un marcador de posición para la ruta completa de tu proyecto. En la pantalla de inicio de Hermes, comprueba el directorio de trabajo y el entorno en el que se ejecutan los comandos del terminal. Este método de inicio está pensado para el entorno de terminal local de Hermes en el servidor. Si SSH o Docker están configurados, el agente puede ejecutar comandos en otro entorno; confirma primero que la ruta del proyecto esté disponible allí.

Pide al agente que confirme su directorio de trabajo real con su herramienta de terminal y, después, lee el README y las instrucciones del proyecto. El nombre de una carpeta mencionado en un mensaje no basta para verificarlo.

El orden que aparece a continuación está indicado en una versión fijada de la documentación y puede diferir del de tu versión instalada de Hermes. Comprueba las instrucciones actuales en tu sesión. Hermes admite AGENTS.md, pero que lea ese archivo depende de la prioridad de los archivos de contexto. Según la documentación oficial de Hermes, se selecciona un tipo de archivo de instrucciones: .hermes.md, después AGENTS.override.md, AGENTS.md, CLAUDE.md y .cursorrules. Antes de empezar a trabajar, comprueba si hay un .hermes.md antiguo o un AGENTS.override.md personal; no des por hecho que el agente aplicará necesariamente el archivo AGENTS.md que está junto a ellos.

Conserva en las instrucciones seleccionadas el propósito del proyecto, los comandos de comprobación y las restricciones sobre los cambios. No las conviertas en un archivo histórico de conversaciones. Si también necesitas transferir la configuración de los agentes, ese es otro proceso; su alcance se explica en la guía para migrar de Claude Code a Codex.

Asignar una tarea al agente y comprobar el resultado#

Empieza por pedirle que revise el proyecto sin hacer cambios. Por ejemplo:

Estamos trabajando con un proyecto existente en la carpeta que he indicado.
Confirma el directorio de trabajo real con la herramienta de terminal.
Lee el README y las instrucciones actuales del proyecto.
No abras archivos que contengan secretos ni muestres valores de entorno.
Enumera los comandos de comprobación y los requisitos previos para ejecutarlos.
Por ahora, no cambies ni instales nada, ni hagas push al repositorio.

Después, acordad una tarea pequeña, como corregir un texto de la interfaz. Especifica qué archivos o área se pueden modificar y prohíbe las actualizaciones de dependencias incidentales. Si quieres separar el experimento de la copia principal, infórmate primero sobre una copia de trabajo independiente de Git con worktree.

Acepta el resultado basándote en los cambios de los archivos y en las comprobaciones del proyecto repetidas. Antes de un experimento que podría fallar, guarda la copia de origen y un punto de recuperación; no le pidas al agente que restablezca todos los cambios de una vez. Si una comprobación falla, compara el error con el de la copia de origen: esto ayuda a distinguir un problema de transferencia de un defecto que ya existía.

La transferencia puede considerarse completa cuando está instalada la versión requerida de los archivos de origen, se ha restaurado el entorno, los datos necesarios están disponibles en un entorno de prueba seguro, las comprobaciones se superan y Hermes trabaja en esta carpeta exacta. Publicar la aplicación para los visitantes es una etapa posterior independiente y no forma parte de esta comprobación.

Descubre Ailoot.