# Trasladar un proyecto de Codex a Hermes en un servidor > Transferir un repositorio a un servidor para trabajar en Hermes: cambios guardados, dependencias, secretos, carpeta de trabajo y comprobaciones antes de continuar el desarrollo. Source: https://ailoot.ai/blog/es/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/es/codex-project-to-hermes-server/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-ebc046e881baf9e3e75fe0d1bdc771d124b9adbd54fca19549185be68209487e Para obtener ayuda sobre el uso del servicio, consulta la [documentación de Ailoot](https://ailoot.ai/docs/).
Idea clave Para continuar en Hermes con un proyecto creado con Codex, transfiere el propio repositorio y restaura su entorno. Este método no requiere un paso aparte para «importar un proyecto desde un agente». Primero comprueba los archivos guardados y las dependencias; después, abre la carpeta correcta en Hermes. Esta guía da por hecho que el servidor y Hermes ya están configurados y que tienes acceso al repositorio.
## ¿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](https://ailoot.ai/blog/es/hermes-agent-vps-24-7/). 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: ```bash 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. | Parte del proyecto | Qué comprobar antes de la transferencia | |----|----| | Archivos de código fuente e historial de Git | Los cambios necesarios están guardados y disponibles en la rama seleccionada del repositorio remoto | | README e instrucciones del agente | Los pasos de inicio, las comprobaciones y las restricciones están documentados; las instrucciones están actualizadas | | Archivos de dependencias | Están guardadas las definiciones de dependencias y el archivo de bloqueo que usa el proyecto, que fija las versiones | | Secretos | Hay una forma independiente y segura de configurarlos en el servidor; sus valores no están en Git ni se envían por chat | | Base de datos y archivos subidos | Sabes dónde obtener datos de prueba permitidos y cómo restaurarlos siguiendo las instrucciones del proyecto | 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: ```bash 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: ```bash 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: ```bash npm ci ``` Según la [documentación de npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md), 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: ```bash 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](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md), 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](https://ailoot.ai/blog/es/migrate-claude-code-to-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](https://ailoot.ai/blog/es/codex-worktree-separate-task/). 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](https://ailoot.ai/). ## Preguntas sobre Codex y Hermes Agent ### ¿Clonar el repositorio transfiere todo el entorno de trabajo? No. Git no transfiere archivos ignorados, bases de datos externas, datos subidos, secretos ni historial de chat del agente. Restaura por separado las dependencias y los datos de prueba permitidos según las instrucciones del proyecto. ### ¿Qué comparo antes de editar la copia del servidor? Compara la rama y el identificador de commit guardados con la copia original, revisa los cambios sin commit y pide a Hermes que verifique su directorio de trabajo real. Ejecuta después las comprobaciones existentes del proyecto en esa copia exacta. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.