diff --git a/docs/AVISO_MIGRACION_REPO.md b/docs/AVISO_MIGRACION_REPO.md new file mode 100644 index 0000000..fb375a5 --- /dev/null +++ b/docs/AVISO_MIGRACION_REPO.md @@ -0,0 +1,102 @@ +# 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` \ No newline at end of file