Paco POR-CORREO
d63a096bdc
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).
102 lines
No EOL
6.6 KiB
Markdown
102 lines
No EOL
6.6 KiB
Markdown
# 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` |