# Aviso: migracion del repo a RAG como raiz **Fecha:** 2026-07-21 **Originado por:** Agente SerpBot API (ses_07a0ef286ffepXsTZOrCVa95nc) en `serpbot-api/` **Commit de migracion:** `b9a37f2 Restructure repo: move RAG content to repo root` **Remote:** `ssh://git@git.por-correo.com:2222/paco/rag-service.git` --- ## Que paso El repo `rag-service` estaba mal configurado desde hacia varias sesiones. Un agente anterior ejecuto `git init` en `/home/pancho/Documentos/Empresa/Desarrollo/IA/` (carpeta contenedora del workspace) en lugar de hacerlo dentro de `RAG/`. Como consecuencia: - El `.git` vivia en `Desarrollo/IA/.git`. - El remote apuntaba a `paco/rag-service.git` pero el working tree absorbia toda la carpeta `Desarrollo/IA/`, incluyendo `docs/` del workspace padre, `.gitignore` del padre, y cualquier carpeta nueva creada bajo `Desarrollo/IA/` (por ejemplo `propios/serpbot-api/`). - En HEAD los paths estaban commiteados como subcarpetas de `RAG/`: `RAG/src/...`, `RAG/docs/...`, `RAG/Dockerfile`, etc. - Tambien estaba commiteada la carpeta `docs/` del workspace padre, que NO pertenece al proyecto RAG. Esto confundia a agentes nuevos y a Engram (que detectaba cualquier carpeta nueva bajo `Desarrollo/IA/` como parte del proyecto `rag-service`). ## Que se hizo 1. Backup del `.git` original en `/tmp/opencode/rag-git-backup-1784664617` (por seguridad, conservar si hace falta). 2. Se movio `Desarrollo/IA/.git` a `Desarrollo/IA/RAG/.git`. 3. Commit `b9a37f2` con `git add -A` desde `RAG/`. Git detecto el cambio como renombres masivos (`R100`/`R082`/`R092`), preservando la historia: - `RAG/src/*` pasa a `src/*` (raiz del repo). - `RAG/docs/*` pasa a `docs/*`. - `RAG/Dockerfile` pasa a `Dockerfile`. - `RAG/package.json` pasa a `package.json`. - etc. 4. Se eliminaron del index las entradas que no pertenecen a RAG: - `docs/INDICE_DOCUMENTACION.md`, `docs/HISTORIAL_SESIONES.md`, `docs/PENDIENTES_GENERALES.md`, `docs/TASK.md`, `docs/README.md`, `docs/readme.md`, etc. (carpeta `docs/` del workspace padre). - `.gitignore` del workspace padre. 5. Se anadio `.atl/` al `.gitignore` de RAG para que las caches locales de skill-registry no se commiteen. 6. Push normal (sin force) a `rag-service.git`: `fe41e40..b9a37f2 main -> main`. 7. La carpeta `Desarrollo/IA/` queda como carpeta contenedora pura, sin `.git`. ## Lo que NO se hizo - No se reescribio el historial. Los commits anteriores a `b9a37f2` siguen teniendo paths `RAG/...` y `docs/...` del padre. Esto es esperado y no es un problema: a partir de `b9a37f2` el repo vive con RAG como raiz. - No se borraron archivos del filesystem del workspace padre. Los archivos de `Desarrollo/IA/docs/`, `Desarrollo/IA/.gitignore` etc. siguen fisicamente donde estaban, solo que dejan de estar trackeados por el repo de RAG. - No se toco el contenido de `RAG/docs/` (la documentacion interna de RAG). Solo se reorganizo el arbol del repo. --- ## Lo que el agente de RAG tiene que saber / hacer ### Sobre Docker y el despliegue en EasyPanel **IMPORTANTE - verificar antes del proximo deploy.** Antes de la migracion, el `Dockerfile` estaba commiteado en el repo como `RAG/Dockerfile` (subcarpeta). En EasyPanel, segun como este configurado el servicio `rag-service`: - **Si el build context de EasyPanel apunta a la raiz del repo** y esperaba `Dockerfile` en raiz: antes no lo encontraba, ahora SI lo encuentra. Mejora. Deberia funcionar. - **Si el build context estaba configurado en `RAG/`** (porque ahi estaba el Dockerfile): ahora el path `RAG/Dockerfile` ya no existe en el repo, el build fallara. Hay que cambiar el build context a la raiz del repo (`/`). - **Si el Dockerfile hace `COPY RAG/...`**: hay que revisar los paths internos del Dockerfile. Tras la migracion, el codigo vive en raiz, no en `RAG/`. Si el Dockerfile sigue haciendo `COPY RAG/package.json ./` o `WORKDIR /app/RAG`, va a fallar. **Accion requerida:** 1. Abrir EasyPanel, revisar la configuracion del servicio `rag-service`. 2. Verificar el build context y el path del Dockerfile. 3. Si el Dockerfile usa paths `RAG/...` internos, actualizarlos para que apunten a la raiz del repo. Ejemplo: - `COPY RAG/package.json ./` -> `COPY package.json ./` - `WORKDIR /app/RAG` -> `WORKDIR /app` 4. Hacer un deploy de prueba y verificar que el contenedor arranca y el endpoint `health` responde. 5. Si algo falla, revisar los logs de build en EasyPanel y ajustar paths. ### Sobre futuras sesiones de RAG - A partir de `b9a37f2`, trabajar normalmente en `RAG/` como raiz del repo. Los paths en el working tree son `src/`, `docs/`, `Dockerfile`, `package.json`, etc. - Los commits antiguos (pre-`b9a37f2`) seguiran mostrando paths `RAG/...` en `git log` y `git blame`. Es esperado. - La carpeta `docs/` que se ve en `RAG/docs/` es la documentacion interna de RAG. La carpeta `docs/` del workspace padre (`Desarrollo/IA/docs/`) ya no forma parte de este repo. - `.atl/` esta en `.gitignore`. No commitear caches locales de skill-registry ni herramientas similares. ### Sobre el backup - El `.git` original (pre-migracion) esta en `/tmp/opencode/rag-git-backup-1784664617`. Si hace falta recuperar algo, ahi esta. Si todo funciona bien tras el siguiente deploy, se puede borrar. ### Sobre Engram y la deteccion de proyectos - Antes de la migracion, Engram detectaba cualquier carpeta bajo `Desarrollo/IA/` como proyecto `rag-service` (porque git subia por ancestros hasta encontrar el `.git` en `Desarrollo/IA/`). Esto causaba colisiones con otros proyectos como `serpbot-api`. - Tras la migracion, Engram detectara `RAG/` por su propio remote y cada proyecto bajo `Desarrollo/IA/` que tenga su propio `.git` se detectara como proyecto independiente. - Si Engram sigue mostrando comportamientos raros, revisar que el remote de RAG siga siendo `ssh://git@git.por-correo.com:2222/paco/rag-service.git`. --- ## Pendiente concreto para el agente de RAG 1. Verificar y ajustar la configuracion de build de EasyPanel para `rag-service` segun lo descrito arriba. 2. Hacer un deploy de prueba tras ajustar los paths del Dockerfile si fue necesario. 3. Confirmar que `health`, `retrieve` y `answer` siguen respondiendo en produccion. 4. Si todo va bien, borrar el backup `/tmp/opencode/rag-git-backup-1784664617`. 5. Registrar la verificacion en `RAG/docs/HISTORIAL_SESIONES.md` cuando quede cerrado. --- ## Referencias - Commit de migracion: `b9a37f2` en `rag-service` (rama `main`). - Remote: `ssh://git@git.por-correo.com:2222/paco/rag-service.git` - Backup del `.git` pre-migracion: `/tmp/opencode/rag-git-backup-1784664617` - Sesion que origino la migracion: `ses_07a0ef286ffepXsTZOrCVa95nc` (Agente SerpBot API, en `propios/serpbot-api/`). - Documentacion de despliegue base: `docs/DESPLIEGUE_EASYPANEL.md`