Add repo migration notice for next RAG agent

Document the .git migration from Desarrollo/IA/ to RAG/ and the
restructuring commit b9a37f2 that promoted RAG/ content to repo root.
Includes instructions for the next RAG agent to verify EasyPanel
deployment after the path changes (Dockerfile now at repo root).

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`