Restructure repo: move RAG content to repo root

- RAG/ subfolder content promoted to repo root (git detected as renames)
- Remove parent-level docs/ and .gitignore from tracking (not part of RAG project)
- Add .atl/ to .gitignore (local agent caches)
- No history rewrite; prior commits preserved as-is

.env.example

@@ -1,6 +1,6 @@
-PORT=3000
-NODE_ENV=development
-QDRANT_URL=http://localhost:6333
+PORT=80
+NODE_ENV=production
+QDRANT_URL=http://qdrant:6333
 QDRANT_API_KEY=
 QDRANT_COLLECTION=rag_chunks
 EMBEDDING_PROVIDER=openrouter

.gitignore

@@ -1 +1,12 @@
-docs/ACCESOS_INFRAESTRUCTURA_LOCAL.md
+node_modules/
+dist/
+.env
+.env.local
+.env.production.local
+.env.easypanel.local
+.env.*
+!.env.example
+npm-debug.log*
+
+# Local agent caches and tooling artifacts
+.atl/

RAG/.gitignore

@@ -1,5 +0,0 @@
-node_modules/
-dist/
-.env
-.env.local
-npm-debug.log*

RAG/docs/HISTORIAL_SESIONES.md

@@ -1,66 +0,0 @@
-# Historial de sesiones
-
-**Proyecto:** Workspace de tools IA para empresas  
-**Modulo:** RAG  
-**Ultima actualizacion:** 2026-04-06  
-**Ultima modificacion por:** Agente RAG 2  
-**Estado:** Activo
-
----
-
-## Registro de sesion
-
-### 2026-04-06 - Agente RAG 2
-
-**Modelo:** gpt-5.4  
-**Conversation ID:** `N/D (OpenCode no lo expone en este entorno)`  
-**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`  
-**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA`
-
-**Rol asumido:**
-Dar continuidad al RAG en `RAG/` a partir del estado actual documentado.
-
-**Contexto recuperado:**
-- No existe `README` en la raiz de `RAG/`.
-- La base documental principal revisada ha sido:
-  - `docs/SISTEMA_RAG_BASE.md`
-  - `docs/BITACORA_DISENO_RAG.md`
-  - `docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md`
-  - `docs/PLAYGROUND.md`
-  - `docs/LOGS_EVALUACION.md`
-- La v1 figura como operativa y desplegada en `https://rag.por-correo.com`.
-- Endpoints documentados como operativos: `GET /health`, `POST /ingest`, `POST /retrieve`, `POST /answer`.
-- El playground y los logs de evaluacion aparecen implementados en codigo y pendientes de redeploy segun la documentacion.
-
-**Criterio de continuidad asumido:**
-- Trabajar desde el estado ya documentado, sin redescubrir decisiones nucleares de la v1.
-- Mantener actualizada la documentacion relevante cuando se hagan cambios reales.
-- Usar este historial para dejar trazabilidad entre sesiones y agentes.
-
-**Trabajo realizado en esta sesion:**
-- Auditoria inicial de documentacion, codigo y estado observable del modulo `RAG/`.
-- Registro de un reporte temporal de auditoria de modelo en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md` para comparacion futura.
-- Implementacion de ayuda visual en la zona de `Bootstrap` del playground.
-- Añadidos tooltip y `aria-label` en `Cargar bootstrap`, `Reemplazar contexto`, `Vaciar contexto`, `Preset docs`, `Preset RAG docs` y `Preset codigo`.
-- Actualizacion de `RAG/docs/PLAYGROUND.md` y `RAG/docs/TEXTOS_AYUDA_PLAYGROUND.md` para reflejar la mejora.
-- Implementacion de la pestaña Limpieza en el playground y soporte en el backend (`POST /cleanup`) para borrado seguro de contextos ya ingeridos.
-- Limpieza ejecutada exitosamente sobre el `scope` del código fuente antiguo (`RAG/src`).
-- Reingesta del directorio `RAG/src` con el código actualizado.
-- Documento de seguimiento `RAG/docs/TASK_LIMPIEZA.md` y documentacion API `RAG/docs/API_RAG.md` actualizados.
-- Comparacion de auditorias del modelo (pre y post cleanup) documentada en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md`, confirmando una ganancia clara en nitidez y precision del RAG al evaluar el codigo.
-- Implementacion de ingesta directa de carpetas locales desde el playground: el navegador empaqueta la carpeta en un `.zip` en memoria (filtrando `node_modules`, `dist`, `.git`, etc. con logica nativa) y el backend usa `adm-zip` para extraerla de forma segura en un directorio temporal antes de la ingesta.
-- Correccion en `IngestService` (`resolveInputFiles` y `normalizeDocumentKey`) para escanear archivos desde la ruta temporal extraída (`readPath`) en lugar del identificador lógico al subir carpetas completas, evitando error de `ENOENT`.
-- Revision inicial del corpus `/_imports/gstreamer-rag-text` como futura base documental especializada para GStreamer.
-- Creacion de `RAG/docs/TASK_INGESTA_GSTREAMER.md` con el plan operativo para ingerirlo bajo un scope unico, validar retrieval y prepararlo para uso posterior con modelo local.
-- Diagnostico y correccion del fallo real de ingesta masiva en corpus documentales: algunos ficheros generaban chunks sobredimensionados que acababan rompiendo la llamada a embeddings.
-- Correccion aplicada en `src/modules/process/chunking.ts` y endurecimiento defensivo de `src/modules/embeddings/provider.ts`.
-- Ingesta completada del corpus GStreamer bajo el scope unico `gstreamer-official` / `corpus:gstreamer:official:v1` con `3117` documentos y `22003` chunks.
-- Validacion funcional en produccion mediante `GET /sources` y `POST /retrieve` para bootstrap y consulta especifica sobre request pads.
-- Creacion y configuracion del agente primario `gstreamer` en OpenCode para diagnostico tecnico sobre proyectos con GStreamer, priorizando el scope `gstreamer-official` del RAG.
-- Documentacion del agente en `RAG/docs/AGENTE_GSTREAMER.md`.
-- Ajuste del agente `gstreamer` para asumir por defecto el scope `gstreamer-official` sin que el usuario tenga que mencionarlo expresamente en cada prompt.
-- Creacion de un paquete portable para recrear el agente `gstreamer` en otro PC: `RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc` y `RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md`.
-- Conexion operativa real del agente `gstreamer` al RAG remoto `https://rag.por-correo.com` mediante scripts dedicados fijados al scope `gstreamer-official`.
-- Soporte explicito para flujos de `bootstrap` y `precarga` dirigida antes de revisar codigo.
-- Ajuste del paquete portable del agente para usar placeholder `__IA_WORKSPACE_ROOT__` y poder reinstalarlo correctamente en otros equipos sin depender de rutas locales de este PC.
-- Creacion de `RAG/agente_gstreamer/` como carpeta autocontenida para llevar el agente a otro PC con configuracion, scripts e instrucciones en un solo paquete.

docs/DESPLIEGUE_EASYPANEL.md

@@ -199,6 +199,30 @@ Dato importante para `RAG`:
 - `ANSWER_BASE_URL=https://openrouter.ai/api/v1`
 - `ANSWER_API_KEY=<valor real>`
 
+### Variables de entorno con las que quedo operativo en VPS2
+
+Valores funcionales confirmados en EasyPanel:
+
+- `NODE_ENV=production`
+- `PORT=80`
+- `QDRANT_URL=http://qdrant:6333`
+- `QDRANT_API_KEY=`
+- `QDRANT_COLLECTION=rag_chunks`
+- `EMBEDDING_PROVIDER=openrouter`
+- `EMBEDDING_MODEL=qwen/qwen3-embedding-8b`
+- `EMBEDDING_BASE_URL=https://openrouter.ai/api/v1`
+- `EMBEDDING_API_KEY=<secreto>`
+- `ANSWER_PROVIDER=openrouter`
+- `ANSWER_MODEL=openai/gpt-4.1-mini`
+- `ANSWER_BASE_URL=https://openrouter.ai/api/v1`
+- `ANSWER_API_KEY=<secreto>`
+
+Para respaldo operativo local fuera de EasyPanel se deja un archivo ignorado por Git:
+
+- `RAG/.env.easypanel.local`
+
+Ese archivo no debe versionarse porque contiene secretos reales.
+
 ### Volumen persistente
 
 - no es obligatorio para la app RAG en esta fase

docs/HISTORIAL_SESIONES.md

@@ -1,130 +1,66 @@
 # Historial de sesiones
 
-## Proyecto: Workspace de tools IA para empresas
-
-Este archivo registra agentes y sesiones de trabajo de este workspace.
+**Proyecto:** Workspace de tools IA para empresas  
+**Modulo:** RAG  
+**Ultima actualizacion:** 2026-04-06  
+**Ultima modificacion por:** Agente RAG 2  
+**Estado:** Activo
 
 ---
 
-## Indice de agentes
+## Registro de sesion
 
-| Agente | Responsabilidad | Identificador |
-|--------|-----------------|---------------|
-| **Agente tools IA para potenciar servicios empresariales** | Desarrollo de tools, herramientas, skills, RAGs, MCPs y utilidades para potenciar soluciones con IA para empresas | `session_id OpenCode por workspace cuando aplique` |
-| **Agente RAG 2** | Continuidad operativa y evolutiva del modulo `RAG/`, incluyendo codigo, pruebas y documentacion del servicio | `ses_29bdbd003ffeLrLjUlFgnp08Y7` |
+### 2026-04-06 - Agente RAG 2
 
----
-
-## Sesiones de trabajo
-
-### Sesion 1 (2026-04-02) - Agente tools IA para potenciar servicios empresariales
-**Agente:** **Agente tools IA para potenciar servicios empresariales**  
-**Modelo:** gpt-5.4  
-**Conversation ID:** `N/D (OpenCode no lo expone en este entorno)`  
-**Session ID OpenCode:** `ses_2b208e826ffeqyzvUVG7Tal0r0`  
-**Titulo de sesion:** `Registro de agente para tools IA empresariales`  
-**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA`
-
-#### Trabajo realizado:
-- Registro del agente para este workspace.
-- Lectura y alineacion inicial de la documentacion base.
-- Creacion de `docs/PENDIENTES_GENERALES.md` con las primeras lineas de trabajo.
-- Limpieza de documentacion heredada de otros proyectos en archivos base del workspace.
-- Creacion inicial del documento marco del sistema RAG reutilizable.
-- Definicion inicial del modulo de ingesta en `RAG/docs/INGESTA.md`.
-- Definicion inicial del modulo de procesado en `RAG/docs/PROCESADO.md`, incluyendo la decision de una estrategia de chunking comun para la v1.
-- Creacion de `RAG/docs/BITACORA_DISENO_RAG.md` para conservar el camino de decisiones, razones y posibilidades abiertas del diseño del sistema.
-- Definicion inicial del modulo de salida en `RAG/docs/SALIDA.md`, incluyendo la estructura acordada para el `retrieve` inicial como paquete de contexto de arranque.
-- Ajuste del alcance de la v1 para dejar explicito que los PDFs deben estar soportados desde el inicio y que el modo `codigo` sigue siendo parte de la direccion del sistema.
-- Definicion de `RAG/docs/STACK_TECNICO_V1.md` con el stack tecnico minimo acordado para construir la primera version funcional del sistema.
-- Aclaracion del diseño de embeddings desacoplados, dejando documentado que los cambios de modelo requieren reindexacion coherente y trazabilidad por proveedor/modelo.
-- Cierre de la decision de embeddings fijando `Qwen3 Embedding 8B` como modelo base estable del sistema, con arranque via proveedor compatible y objetivo futuro de despliegue local.
-- Creacion del scaffold inicial de `RAG/` con API Express, modulos base, Dockerfile, configuracion por entorno y orientacion de despliegue compatible con EasyPanel.
-- Implementacion funcional inicial del pipeline con parsers `md/txt/pdf`, chunking documental, proveedor real de embeddings via OpenRouter, cliente Qdrant y endpoints operativos de ingesta y retrieve.
-- Creacion de `RAG/.env.local` como fichero local de claves y configuracion sensible fuera del control de versiones.
-- Prueba real completada contra `Qdrant` remoto en EasyPanel, con ingesta funcional de `docs/` y retrieves reales en modos `specific` y `bootstrap`.
-- Ampliacion del retrieve para aceptar `scope` por fuente, referencia o tags, dejando preparado el bootstrap enfocado por workspace o proyecto.
-- Mejora del `retrieve bootstrap` mediante subconsultas internas y sintesis orientada a mapa inicial del dominio.
-- Implementacion funcional de `POST /answer`, apoyado en `retrieve` y con respuesta generada por modelo usando solo el contexto recuperado.
-- Mejora de `retrieve specific` para preguntas operativas frecuentes, logrando respuestas mas concretas sobre backlog y estado del workspace.
-- Limpieza de la coleccion `rag_chunks`, reingesta separada de `docs/` y `RAG/docs/`, y prueba satisfactoria de consultas acotadas por `scope` a cada fuente.
-- Implementacion completa del modo `codigo`, incluyendo ingesta de `RAG/src/`, chunking semantico por bloques top-level, retrieve filtrado y respuesta con referencias de lineas.
-- Prueba satisfactoria del modo `codigo` con una consulta real sobre la construccion de `source_id` en el sistema.
-- Auditoria inicial de `VPS2`, identificando recursos, servicios del proyecto `ia_servicios`, patron de montaje de `webfetch` y forma recomendada de desplegar `RAG` en EasyPanel.
-- Creacion de `RAG/docs/DESPLIEGUE_EASYPANEL.md` con la base de despliegue del servicio en el VPS.
-- Aclaracion de que la guia de despliegue en EasyPanel aplica especificamente a `VPS2` y creacion de `RAG/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md` para recopilar informacion faltante del despliegue de `webfetch`.
-- Incorporacion del patron real de despliegue de `webfetch` en `VPS2`, dejando documentado que la imagen se construyo localmente en el VPS y no desde EasyPanel.
-- Contraste del patron manual de `webfetch` con la documentacion oficial de EasyPanel, dejando definido que `RAG` deberia montarse como `App Service` con fuente Git o imagen publicada para quedar bien integrado.
-- Verificacion de que Forgejo ya esta operativo en `git.por-correo.com` y que el acceso Git por SSH en puerto `2222` responde correctamente, dejando preparado el camino de despliegue integrado para `RAG`.
-- Creacion del repo remoto `paco/rag-service` en Forgejo y subida correcta del estado actual del workspace mediante Git SSH.
-- Despliegue correcto de `RAG` en EasyPanel como `App Service` usando Forgejo y `Dockerfile`, con dominio activo `https://rag.por-correo.com`.
-- Pruebas satisfactorias en produccion de `health`, `retrieve` y `answer`, tanto en modo documental como en modo codigo.
-- Deteccion y anotacion como pendiente del cambio futuro del modelo actual de `answer`.
-- Creacion de `RAG/docs/API_RAG.md` como referencia operativa de la API para conectar rapidamente el servicio desde n8n, agentes y otras aplicaciones.
-- Alineacion de las variables de entorno para EasyPanel, dejando `.env.example` ajustado al despliegue esperado y `RAG/.env.easypanel.local` como respaldo operativo local ignorado por Git.
-- Implementacion de un playground web interno servido por el propio backend del RAG para probar `health`, `ingest`, `retrieve`, `answer` y comparacion sin RAG.
-- Creacion de `RAG/docs/PLAYGROUND.md` para documentar la tecnologia elegida, su ubicacion y su papel dentro del modulo.
-- Ajuste de la API y del playground para hacer visible y seleccionable el modelo de `answer`, evitando dejarlo oculto como una decision fija del backend.
-- Evolucion del playground a una mecanica mas completa con pestañas `Ingesta / Bootstrap / Chat`, indicador visual de contexto activo y endpoint `/chat` con bootstrap reutilizable y consultas adicionales al RAG durante la conversacion.
-- Ampliacion de la ingesta y del playground para soportar upload directo de archivos y `sourceId` personalizado, permitiendo aislar documentos ajenos al RAG en scopes separados.
-- Implementacion de logs de evaluacion persistentes en `Qdrant`, con disparo automatico por contexto insuficiente y registro manual con nota desde el playground.
-- Ampliacion de los logs de evaluacion para permitir seguimiento real (`pending`, `resolved`, `ignored`, etc.) y documentacion de su arquitectura en `RAG/docs/LOGS_EVALUACION.md`.
-- Ajuste visual del playground con branding de POR-CORREO, nuevo titulo y contador visible de logs para detectar de un vistazo actividad de evaluacion.
-- Creacion de `RAG/docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md` para dejar explicito el flujo ya validado de implementacion, prueba local, commit, push y redeploy en EasyPanel.
-- Creacion de `RAG/docs/TEXTOS_AYUDA_PLAYGROUND.md` y nueva task asociada para que otro agente implemente ayuda visual y textos ALT en los botones principales del playground.
-- Reorganizacion de RAG como modulo raiz independiente con documentacion propia en `RAG/docs/`.
-- Ajuste del indice documental global para reflejar la separacion entre documentacion global y documentacion por tool.
-- Creacion de `docs/TASK.md` para descomponer lineas de trabajo amplias en puntos de analisis y acuerdos.
-- Creacion de `docs/ACCESOS_INFRAESTRUCTURA_LOCAL.md` para recoger accesos de VPS2, EasyPanel y servicios de infraestructura del workspace.
-
-#### Estado final:
-- Documentacion base alineada con este workspace.
-- Agente registrado.
-- Backlog inicial disponible para continuar el trabajo.
-- Carpeta `RAG/docs/` creada y primera documentacion RAG registrada con la estructura correcta del workspace.
-- Existe ya un documento global para partir planificaciones amplias en tasks de trabajo.
-- Existe ya una base tecnica compilable del modulo `RAG/` lista para continuar con implementacion funcional.
-- Existe ya una primera implementacion funcional compilable del servicio RAG, pendiente de probar con claves reales y Qdrant activo.
-- El servicio ya ha sido probado con embeddings reales y vector store remoto operativo.
-- El servicio soporta ya modo documental y modo codigo con pruebas reales sobre documentacion y codigo del propio modulo.
-- La v1 del RAG ya esta desplegada y operativa en VPS2 con dominio publico funcional.
-
----
-
-### Sesion 2 (2026-04-06) - Agente RAG 2
-**Agente:** **Agente RAG 2**  
 **Modelo:** gpt-5.4  
 **Conversation ID:** `N/D (OpenCode no lo expone en este entorno)`  
 **Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`  
-**Titulo de sesion:** `Continuación de proyecto Agente RAG 2`  
 **Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA`
 
-#### Trabajo realizado:
-- Lectura del `docs/README.md` global del workspace para alinear reglas de documentacion y registro.
-- Revision de `docs/HISTORIAL_SESIONES.md` y `docs/sesion_actual_opencode.md` como base operativa de continuidad.
-- Revision inicial de la documentacion principal del modulo `RAG/` para retomar el estado de la v1.
-- Registro de continuidad como `Agente RAG 2` orientado especificamente al trabajo sobre `RAG/`.
-- Creacion de `RAG/docs/HISTORIAL_SESIONES.md` como historial interno del modulo para trazabilidad local entre sesiones del propio RAG.
-- Configuracion del agente primario `gstreamer` en OpenCode para trabajo especializado con el RAG de GStreamer.
-- Indexacion y documentacion del comportamiento del agente `gstreamer`.
-- Preparacion de ficheros portables para reinstalar el agente `gstreamer` en otro PC con OpenCode.
-- Conexion real del agente `gstreamer` al RAG remoto de GStreamer mediante scripts versionados en `RAG/scripts/`.
+**Rol asumido:**
+Dar continuidad al RAG en `RAG/` a partir del estado actual documentado.
 
-#### Estado final:
-- `Agente RAG 2` registrado en el historial global del workspace.
-- Contexto global del workspace alineado con el contexto especifico de `RAG/`.
-- Sesion actual identificada con su `session_id` real de OpenCode.
+**Contexto recuperado:**
+- No existe `README` en la raiz de `RAG/`.
+- La base documental principal revisada ha sido:
+  - `docs/SISTEMA_RAG_BASE.md`
+  - `docs/BITACORA_DISENO_RAG.md`
+  - `docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md`
+  - `docs/PLAYGROUND.md`
+  - `docs/LOGS_EVALUACION.md`
+- La v1 figura como operativa y desplegada en `https://rag.por-correo.com`.
+- Endpoints documentados como operativos: `GET /health`, `POST /ingest`, `POST /retrieve`, `POST /answer`.
+- El playground y los logs de evaluacion aparecen implementados en codigo y pendientes de redeploy segun la documentacion.
 
----
+**Criterio de continuidad asumido:**
+- Trabajar desde el estado ya documentado, sin redescubrir decisiones nucleares de la v1.
+- Mantener actualizada la documentacion relevante cuando se hagan cambios reales.
+- Usar este historial para dejar trazabilidad entre sesiones y agentes.
 
-## Agentes activos
-
-### Agente tools IA para potenciar servicios empresariales
-- **Responsabilidad:** Desarrollo de tools, herramientas, skills, RAGs, MCPs y utilidades para potenciar soluciones con IA para empresas.
-- **Estado:** Activo
-- **Trabajo principal:** Desarrollo de herramientas reutilizables e integraciones para potenciar otros servicios de IA empresariales.
-
-### Agente RAG 2
-- **Responsabilidad:** Continuidad operativa y evolutiva del modulo `RAG/`, incluyendo backend, playground, retrieval, answer, logs y documentacion del servicio.
-- **Estado:** Activo
-- **Trabajo principal:** Retomar y hacer avanzar el proyecto `RAG/` sin perder continuidad entre sesiones.
+**Trabajo realizado en esta sesion:**
+- Auditoria inicial de documentacion, codigo y estado observable del modulo `RAG/`.
+- Registro de un reporte temporal de auditoria de modelo en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md` para comparacion futura.
+- Implementacion de ayuda visual en la zona de `Bootstrap` del playground.
+- Añadidos tooltip y `aria-label` en `Cargar bootstrap`, `Reemplazar contexto`, `Vaciar contexto`, `Preset docs`, `Preset RAG docs` y `Preset codigo`.
+- Actualizacion de `RAG/docs/PLAYGROUND.md` y `RAG/docs/TEXTOS_AYUDA_PLAYGROUND.md` para reflejar la mejora.
+- Implementacion de la pestaña Limpieza en el playground y soporte en el backend (`POST /cleanup`) para borrado seguro de contextos ya ingeridos.
+- Limpieza ejecutada exitosamente sobre el `scope` del código fuente antiguo (`RAG/src`).
+- Reingesta del directorio `RAG/src` con el código actualizado.
+- Documento de seguimiento `RAG/docs/TASK_LIMPIEZA.md` y documentacion API `RAG/docs/API_RAG.md` actualizados.
+- Comparacion de auditorias del modelo (pre y post cleanup) documentada en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md`, confirmando una ganancia clara en nitidez y precision del RAG al evaluar el codigo.
+- Implementacion de ingesta directa de carpetas locales desde el playground: el navegador empaqueta la carpeta en un `.zip` en memoria (filtrando `node_modules`, `dist`, `.git`, etc. con logica nativa) y el backend usa `adm-zip` para extraerla de forma segura en un directorio temporal antes de la ingesta.
+- Correccion en `IngestService` (`resolveInputFiles` y `normalizeDocumentKey`) para escanear archivos desde la ruta temporal extraída (`readPath`) en lugar del identificador lógico al subir carpetas completas, evitando error de `ENOENT`.
+- Revision inicial del corpus `/_imports/gstreamer-rag-text` como futura base documental especializada para GStreamer.
+- Creacion de `RAG/docs/TASK_INGESTA_GSTREAMER.md` con el plan operativo para ingerirlo bajo un scope unico, validar retrieval y prepararlo para uso posterior con modelo local.
+- Diagnostico y correccion del fallo real de ingesta masiva en corpus documentales: algunos ficheros generaban chunks sobredimensionados que acababan rompiendo la llamada a embeddings.
+- Correccion aplicada en `src/modules/process/chunking.ts` y endurecimiento defensivo de `src/modules/embeddings/provider.ts`.
+- Ingesta completada del corpus GStreamer bajo el scope unico `gstreamer-official` / `corpus:gstreamer:official:v1` con `3117` documentos y `22003` chunks.
+- Validacion funcional en produccion mediante `GET /sources` y `POST /retrieve` para bootstrap y consulta especifica sobre request pads.
+- Creacion y configuracion del agente primario `gstreamer` en OpenCode para diagnostico tecnico sobre proyectos con GStreamer, priorizando el scope `gstreamer-official` del RAG.
+- Documentacion del agente en `RAG/docs/AGENTE_GSTREAMER.md`.
+- Ajuste del agente `gstreamer` para asumir por defecto el scope `gstreamer-official` sin que el usuario tenga que mencionarlo expresamente en cada prompt.
+- Creacion de un paquete portable para recrear el agente `gstreamer` en otro PC: `RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc` y `RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md`.
+- Conexion operativa real del agente `gstreamer` al RAG remoto `https://rag.por-correo.com` mediante scripts dedicados fijados al scope `gstreamer-official`.
+- Soporte explicito para flujos de `bootstrap` y `precarga` dirigida antes de revisar codigo.
+- Ajuste del paquete portable del agente para usar placeholder `__IA_WORKSPACE_ROOT__` y poder reinstalarlo correctamente en otros equipos sin depender de rutas locales de este PC.
+- Creacion de `RAG/agente_gstreamer/` como carpeta autocontenida para llevar el agente a otro PC con configuracion, scripts e instrucciones en un solo paquete.

docs/INDICE_DOCUMENTACION.md

@@ -1,454 +0,0 @@
-# Indice de documentacion
-
-**Proyecto:** Workspace de tools IA para empresas  
-**Ultima actualizacion:** 2026-04-02  
-**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales
-
----
-
-## Proposito
-
-Este documento es el mapa de la documentacion activa del workspace.
-
-Usalo para:
-- saber que documentos existen
-- evitar documentacion duplicada
-- identificar donde registrar cambios del workspace
-- mantener limpia la documentacion de este proyecto
-
----
-
-## Protocolo rapido
-
-1. Lee `docs/README.md` antes de crear o reorganizar documentacion.
-2. Verifica aqui si el documento ya existe o si su contenido pertenece a otro archivo.
-3. Si creas un documento nuevo, anadelo aqui en la misma sesion.
-4. Si limpias documentacion heredada, actualiza este indice para reflejar el estado real.
-
-Convencion de estructura:
-- `docs/` en raiz contiene solo documentacion global del workspace.
-- cada tool o modulo independiente debe vivir en su propia carpeta raiz.
-- la documentacion propia de cada tool debe vivir dentro de su carpeta, por ejemplo `RAG/docs/`.
-
----
-
-## Documentos activos
-
-### `README.md`
-
-**Ubicacion:** `docs/README.md`
-
-**Proposito:**
-Reglas base para agentes y criterios de trabajo del workspace.
-
-**Cuando leerlo:**
-- al empezar a trabajar en este workspace
-- antes de crear o modificar documentacion
-
-**Cuando actualizarlo:**
-- si cambian las reglas del workspace
-- si se incorporan nuevas normas de documentacion o trabajo
-
----
-
-### `INDICE_DOCUMENTACION.md`
-
-**Ubicacion:** `docs/INDICE_DOCUMENTACION.md`
-
-**Proposito:**
-Inventario maestro de la documentacion vigente.
-
-**Cuando leerlo:**
-- antes de crear un nuevo documento
-- al revisar estructura documental del workspace
-
-**Cuando actualizarlo:**
-- cuando se crea, elimina o renombra un documento en `docs/`
-
----
-
-### `HISTORIAL_SESIONES.md`
-
-**Ubicacion:** `docs/HISTORIAL_SESIONES.md`
-
-**Proposito:**
-Registro de agentes y sesiones de trabajo de este workspace.
-
-**Cuando leerlo:**
-- al identificar un agente
-- al revisar continuidad del trabajo anterior
-
-**Cuando actualizarlo:**
-- al registrar una nueva sesion relevante
-- al dar de alta o ajustar un agente activo
-
----
-
-### `PENDIENTES_GENERALES.md`
-
-**Ubicacion:** `docs/PENDIENTES_GENERALES.md`
-
-**Proposito:**
-Backlog principal de tools, experimentos, investigaciones e integraciones del workspace.
-
-**Cuando leerlo:**
-- al decidir en que trabajar a continuacion
-- al revisar prioridades del workspace
-
-**Cuando actualizarlo:**
-- cuando aparece una nueva linea de trabajo
-- cuando cambia el enfoque o estado de una iniciativa
-
----
-
-### `TASK.md`
-
-**Ubicacion:** `docs/TASK.md`
-
-**Proposito:**
-Descomponer lineas de trabajo amplias en bloques de analisis, decisiones y acuerdos para avanzar sin dejar puntos importantes fuera.
-
-**Cuando leerlo:**
-- cuando una linea de trabajo requiera varias conversaciones o decisiones encadenadas
-- al continuar una planificacion tecnica ya iniciada
-
-**Cuando actualizarlo:**
-- cuando se abra una nueva task de analisis relevante
-- cuando cambien los puntos a convenir de una task activa
-
----
-
-### `ACCESOS_INFRAESTRUCTURA_LOCAL.md`
-
-**Ubicacion:** `docs/ACCESOS_INFRAESTRUCTURA_LOCAL.md`
-
-**Proposito:**
-Registrar accesos temporales y datos de infraestructura necesarios para auditoria, despliegue y revision operativa del workspace.
-
-**Cuando leerlo:**
-- al necesitar acceder al VPS, EasyPanel o servicios relacionados
-- al revisar como estan montados servicios de infraestructura como webfetch o qdrant
-
-**Cuando actualizarlo:**
-- cuando se añadan o cambien accesos de infraestructura
-- cuando se incorporen nuevos entornos o servicios relevantes
-
----
-
-### `RAG/docs/SISTEMA_RAG_BASE.md`
-
-**Ubicacion:** `RAG/docs/SISTEMA_RAG_BASE.md`
-
-**Proposito:**
-Documento marco del sistema RAG base reutilizable que se quiere construir para este workspace y para futuros proyectos.
-
-**Cuando leerlo:**
-- al iniciar el trabajo sobre la linea RAG
-- al necesitar recordar objetivos, alcance y enfoque del sistema
-
-**Cuando actualizarlo:**
-- cuando cambie la vision del sistema RAG
-- cuando se definan o ajusten objetivos clave del diseño base
-
----
-
-### `RAG/docs/INGESTA.md`
-
-**Ubicacion:** `RAG/docs/INGESTA.md`
-
-**Proposito:**
-Definir el modulo de ingesta del sistema RAG, su alcance, responsabilidades y preparacion para futuras actualizaciones.
-
-**Cuando leerlo:**
-- al diseñar la entrada de conocimiento al RAG
-- al decidir como se incorporan y registran las fuentes
-
-**Cuando actualizarlo:**
-- cuando cambie el alcance de la ingesta
-- cuando se acuerden metadatos, tipos de fuente o comportamiento base
-
----
-
-### `RAG/docs/PROCESADO.md`
-
-**Ubicacion:** `RAG/docs/PROCESADO.md`
-
-**Proposito:**
-Definir el modulo de procesado del RAG, especialmente la preparacion del contenido y la estrategia de chunking.
-
-**Cuando leerlo:**
-- al definir como se transforma el contenido ingerido antes de indexarlo
-- al trabajar decisiones sobre chunking y estructura recuperable
-
-**Cuando actualizarlo:**
-- cuando se acuerde o cambie la estrategia de chunking
-- cuando se amplie el tratamiento por tipo de documento o fuente
-
----
-
-### `RAG/docs/BITACORA_DISENO_RAG.md`
-
-**Ubicacion:** `RAG/docs/BITACORA_DISENO_RAG.md`
-
-**Proposito:**
-Mantener una vision panoramica del camino de diseño del RAG, incluyendo decisiones, razonamiento, contexto y opciones abiertas.
-
-**Cuando leerlo:**
-- al retomar la conversacion de diseño del RAG
-- al necesitar entender por que se eligio una direccion concreta
-- al querer ver la vision general que da sentido al resto de documentos del modulo
-
-**Cuando actualizarlo:**
-- cuando se cierre una decision relevante de diseño
-- cuando aparezca un cambio de rumbo, matiz importante u opcion abierta que merezca conservarse
-
----
-
-### `RAG/docs/SALIDA.md`
-
-**Ubicacion:** `RAG/docs/SALIDA.md`
-
-**Proposito:**
-Definir la salida del sistema RAG, especialmente la recuperacion de contexto y la estructura del retrieve inicial.
-
-**Cuando leerlo:**
-- al diseñar como consumiran el RAG agentes, apps o herramientas
-- al revisar que debe devolver `retrieve` y como debe servir de contexto de arranque
-
-**Cuando actualizarlo:**
-- cuando cambie la estructura de salida del RAG
-- cuando se ajusten los modos de retrieve, answer o sintesis
-
----
-
-### `RAG/docs/STACK_TECNICO_V1.md`
-
-**Ubicacion:** `RAG/docs/STACK_TECNICO_V1.md`
-
-**Proposito:**
-Documentar el stack tecnico minimo acordado para construir la primera version funcional del RAG.
-
-**Cuando leerlo:**
-- al iniciar la implementacion tecnica del RAG
-- al revisar decisiones de backend, vector store, parsing y forma de acceso
-
-**Cuando actualizarlo:**
-- cuando cambie alguna decision tecnica base del stack
-- cuando se cierre o cambie el proveedor inicial de embeddings
-
----
-
-### `RAG/docs/DESPLIEGUE_EASYPANEL.md`
-
-**Ubicacion:** `RAG/docs/DESPLIEGUE_EASYPANEL.md`
-
-**Proposito:**
-Documentar el patron de despliegue del modulo RAG en EasyPanel tomando como referencia los servicios ya montados en `ia_servicios`.
-
-**Cuando leerlo:**
-- al preparar el despliegue de `RAG` en VPS2
-- al revisar como conectarlo correctamente con `qdrant` y el proyecto `ia_servicios`
-
-**Cuando actualizarlo:**
-- cuando cambie el patron de despliegue en EasyPanel
-- cuando el servicio `RAG` quede finalmente publicado y probado en el VPS
-
----
-
-### `RAG/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md`
-
-**Ubicacion:** `RAG/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md`
-
-**Proposito:**
-Recoger dudas concretas sobre como se desplego `webfetch` en `VPS2` para reutilizar el patron correcto al publicar `RAG`.
-
-**Cuando leerlo:**
-- al pedir informacion a otro agente o compañero sobre el despliegue actual de `webfetch`
-- al preparar el despliegue de `RAG` siguiendo el patron de `ia_servicios`
-
-**Cuando actualizarlo:**
-- cuando se reciban respuestas sobre el despliegue de `webfetch`
-- cuando las dudas queden resueltas y sirvan para desplegar `RAG`
-
----
-
-### `RAG/docs/API_RAG.md`
-
-**Ubicacion:** `RAG/docs/API_RAG.md`
-
-**Proposito:**
-Documentar de forma practica la API del servicio RAG, con endpoints, payloads y ejemplos listos para conectar desde n8n, agentes o aplicaciones.
-
-**Cuando leerlo:**
-- al integrar el RAG desde n8n o cualquier otro cliente HTTP
-- al necesitar ejemplos listos de `health`, `ingest`, `retrieve` y `answer`
-
-**Cuando actualizarlo:**
-- cuando cambie algun endpoint o payload del servicio
-- cuando se añadan nuevos modos o patrones de integracion
-
----
-
-### `RAG/docs/PLAYGROUND.md`
-
-**Ubicacion:** `RAG/docs/PLAYGROUND.md`
-
-**Proposito:**
-Documentar la tecnologia, ubicacion y utilidad del playground interno del RAG para pruebas y evaluacion.
-
-**Cuando leerlo:**
-- al querer probar el RAG con interfaz web interna
-- al revisar por que se eligio esta forma de playground y no otra
-
-**Cuando actualizarlo:**
-- cuando cambie la interfaz de prueba
-- cuando el playground se amplie o se conecte tambien por MCP
-
----
-
-### `RAG/docs/LOGS_EVALUACION.md`
-
-**Ubicacion:** `RAG/docs/LOGS_EVALUACION.md`
-
-**Proposito:**
-Documentar como se guardan, siguen y revisan los logs de evaluacion del RAG.
-
-**Cuando leerlo:**
-- al revisar logs generados por el playground o por la API
-- al planificar mejoras del RAG a partir de incidencias registradas
-
-**Cuando actualizarlo:**
-- cuando cambie el esquema o el flujo de revision de logs
-- cuando se amplie el sistema de evaluacion del RAG
-
----
-
-### `RAG/docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md`
-
-**Ubicacion:** `RAG/docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md`
-
-**Proposito:**
-Documentar la metodologia de trabajo ya validada para implementar, probar, subir y redeplegar mejoras del RAG sin reinventar el flujo en cada sesion.
-
-**Cuando leerlo:**
-- al continuar el trabajo del RAG desde una nueva sesion
-- al necesitar saber cuando un cambio ya esta listo para pedir `Deploy` al usuario
-
-**Cuando actualizarlo:**
-- cuando cambie el flujo operativo de iteracion, validacion o despliegue
-- cuando se detecte una mejora estable en la metodologia de trabajo
-
----
-
-### `RAG/docs/AGENTE_GSTREAMER.md`
-
-**Ubicacion:** `RAG/docs/AGENTE_GSTREAMER.md`
-
-**Proposito:**
-Documentar el agente `gstreamer` de OpenCode, su scope documental por defecto, su comportamiento esperado y su orientacion a diagnostico tecnico sobre proyectos con GStreamer.
-
-**Cuando leerlo:**
-- al usar o ajustar el agente `gstreamer`
-- al revisar como debe apoyarse en el RAG de GStreamer y como debe comportarse frente a cambios de codigo
-
-**Cuando actualizarlo:**
-- cuando cambie el prompt o el comportamiento del agente
-- cuando se amplie para soportar cambio dinamico de scope u otros corpus del RAG
-
----
-
-### `RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc`
-
-**Ubicacion:** `RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc`
-
-**Proposito:**
-Bloque portable de configuracion del agente `gstreamer` para instalarlo en otra instancia de OpenCode.
-
-**Cuando leerlo:**
-- al querer replicar el agente `gstreamer` en otro PC
-- al necesitar copiar exactamente su configuracion de OpenCode
-
-**Cuando actualizarlo:**
-- cuando cambie el prompt o comportamiento efectivo del agente
-- cuando cambie la configuracion de permisos o modo del agente
-
----
-
-### `RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md`
-
-**Ubicacion:** `RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md`
-
-**Proposito:**
-Explicar como instalar el agente `gstreamer` en otro PC, tanto manualmente como usando otro agente OpenCode.
-
-**Cuando leerlo:**
-- al migrar el agente `gstreamer` a otro equipo
-- al querer reinstalarlo o automatizar su despliegue local
-
-**Cuando actualizarlo:**
-- cuando cambie el proceso de instalacion del agente
-- cuando se añada una integracion real con el RAG remoto
-
----
-
-### `RAG/scripts/rag_gstreamer_bootstrap.sh`
-
-**Ubicacion:** `RAG/scripts/rag_gstreamer_bootstrap.sh`
-
-**Proposito:**
-Consultar el RAG remoto de GStreamer con `intent=bootstrap`, fijado al scope `gstreamer-official`.
-
-**Cuando leerlo:**
-- al revisar como el agente `gstreamer` se conecta realmente al RAG remoto
-- al portar la integracion a otro PC
-
-**Cuando actualizarlo:**
-- cuando cambie el endpoint del RAG
-- cuando cambie el scope o el payload de bootstrap
-
----
-
-### `RAG/scripts/rag_gstreamer_retrieve.sh`
-
-**Ubicacion:** `RAG/scripts/rag_gstreamer_retrieve.sh`
-
-**Proposito:**
-Consultar el RAG remoto de GStreamer con `intent=specific`, fijado al scope `gstreamer-official`.
-
-**Cuando leerlo:**
-- al revisar como el agente `gstreamer` se conecta realmente al RAG remoto
-- al portar la integracion a otro PC
-
-**Cuando actualizarlo:**
-- cuando cambie el endpoint del RAG
-- cuando cambie el scope o el payload de retrieve
-
----
-
-### `sesion_actual_opencode.md`
-
-**Ubicacion:** `docs/sesion_actual_opencode.md`
-
-**Proposito:**
-Instruccion universal para detectar la sesion activa de OpenCode del workspace actual.
-
-**Cuando leerlo:**
-- al necesitar identificar `session_id`, titulo y directorio de la sesion actual
-
-**Cuando actualizarlo:**
-- solo si el usuario lo pide expresamente o cambia el mecanismo canonico de deteccion
-
----
-
-## Estado actual de la documentacion
-
-- La documentacion global del workspace esta concentrada en `docs/`.
-- La documentacion especifica de cada tool debe vivir dentro de su propio modulo raiz.
-- Se ha eliminado el arrastre documental de proyectos anteriores en los archivos base.
-- Cualquier documento nuevo debe responder al objetivo de tools IA para empresas.
-
----
-
-## Estadistica global
-
-**Total de documentos indexados:** 24

docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md

@@ -0,0 +1,200 @@
+# Metodologia de iteracion y redeploy del RAG
+
+**Proyecto:** Workspace de tools IA para empresas  
+**Modulo:** RAG  
+**Ultima actualizacion:** 2026-04-06  
+**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales  
+**Estado:** Activa
+
+---
+
+## Proposito
+
+Dejar explicado de forma explicita el flujo de trabajo que se esta siguiendo para:
+
+- implementar mejoras del RAG
+- validarlas localmente
+- subir solo los cambios adecuados al repo propio
+- avisar al usuario cuando ya solo queda hacer `Deploy` en EasyPanel
+
+La idea es que futuros agentes o nuevas sesiones no tengan que redescubrir este proceso.
+
+---
+
+## Principio general
+
+El flujo correcto que ya esta funcionando bien es este:
+
+1. implementar cambios en local
+2. validar localmente antes de tocar produccion
+3. documentar lo relevante
+4. hacer commit y push solo de lo que debe versionarse
+5. avisar al usuario de que ya puede hacer `Deploy` en EasyPanel
+6. probar el resultado desplegado en produccion
+
+---
+
+## Flujo operativo paso a paso
+
+### 1. Implementacion local
+
+Los cambios se hacen en el workspace local, dentro del modulo:
+
+```text
+RAG/
+```
+
+Esto incluye:
+- backend
+- playground
+- documentacion del modulo
+
+---
+
+### 2. Validacion local obligatoria
+
+Antes de pedir redeploy, se valida en local.
+
+Minimo esperado:
+
+```bash
+cd /home/pancho/Documentos/Empresa/Desarrollo/IA/RAG
+npm run build
+```
+
+Y si aplica, pruebas HTTP locales contra:
+
+- `/health`
+- `/ingest`
+- `/retrieve`
+- `/answer`
+- `/chat`
+- endpoints de logs
+
+No se debe pedir deploy al usuario sin haber comprobado antes que la mejora compila y que el flujo principal funciona en local.
+
+---
+
+### 3. Documentar antes de cerrar el bloque
+
+Si el cambio introduce una mejora real o un comportamiento nuevo, hay que dejarlo reflejado en la documentacion adecuada.
+
+Documentos tipicos a revisar:
+
+- `RAG/docs/API_RAG.md`
+- `RAG/docs/PLAYGROUND.md`
+- `RAG/docs/LOGS_EVALUACION.md`
+- `RAG/docs/DESPLIEGUE_EASYPANEL.md`
+- `docs/HISTORIAL_SESIONES.md`
+
+Objetivo:
+- que otros agentes entiendan el cambio sin tener que inferirlo del codigo
+
+---
+
+### 4. Separar versionable de sensible
+
+Antes de commitear, revisar que no entren en Git cambios sensibles o aun no cerrados.
+
+No subir:
+- `.env.local`
+- `.env.easypanel.local`
+- accesos o secretos
+- respaldos locales
+
+Solo subir:
+- codigo
+- docs sin secretos
+- cambios de UX/API realmente listos para produccion
+
+---
+
+### 5. Commit y push
+
+El commit se hace en el repo local del workspace y luego se sube al repo propio en Forgejo.
+
+Remote actual:
+
+```text
+ssh://git@git.por-correo.com:2222/paco/rag-service.git
+```
+
+Regla importante:
+- usar solo la configuracion local del repo
+- no tocar `git config --global`
+
+---
+
+### 6. Aviso al usuario
+
+Cuando los cambios ya estan:
+
+- implementados
+- validados en local
+- documentados
+- subidos al repo
+
+entonces se avisa al usuario con un mensaje claro de este tipo:
+
+- ya esta subido
+- commit: `<hash>`
+- ya puedes darle a `Deploy` en EasyPanel
+
+La idea es que el usuario no tenga que adivinar si falta algo mas.
+
+---
+
+### 7. Redeploy en EasyPanel
+
+El usuario hace `Deploy` en EasyPanel para que el servicio:
+
+- coja el ultimo commit del repo
+- reconstruya desde `Dockerfile`
+- redepliegue la app
+
+No hace falta reconstruir a mano en el VPS como se hizo antiguamente con `webfetch`.
+
+---
+
+### 8. Validacion en produccion
+
+Tras el deploy, hay que probar el dominio publico:
+
+```text
+https://rag.por-correo.com
+```
+
+Probar segun aplique:
+
+- `health`
+- funcionamiento del playground
+- consultas documentales
+- consultas de codigo
+- logs
+- uploads
+- bootstrap
+- chat
+
+---
+
+## Criterio de corte
+
+Un agente no deberia decir "haz deploy" si no se cumplen estas condiciones:
+
+- compila en local
+- el flujo nuevo ha sido probado localmente
+- la documentacion minima esta actualizada
+- el commit y push ya estan hechos
+- no se han subido secretos por error
+
+---
+
+## Resultado esperado de esta metodologia
+
+Aplicando siempre este flujo se consigue:
+
+- menos redeploys innecesarios
+- menos pruebas rotas en produccion
+- mejor continuidad entre agentes
+- cambios mas explicables y revisables
+- una forma estable de trabajar que ya ha demostrado funcionar bien en este workspace

docs/PENDIENTES_GENERALES.md

@@ -1,151 +0,0 @@
-# Pendientes Generales
-
-**Proyecto:** Workspace de tools IA para empresas  
-**Ultima actualizacion:** 2026-04-05  
-**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales  
-**Estado:** Activo
-
----
-
-## Proposito
-
-Este documento centraliza las lineas de trabajo, experimentos, investigaciones y tools pendientes del workspace para dar continuidad al objetivo principal:
-
-- Desarrollar tools, herramientas, skills y componentes reutilizables para potenciar soluciones con IA para empresas.
-- Priorizar piezas que puedan integrarse facilmente con servicios ya en funcionamiento.
-- Mantener visible el estado de las iniciativas activas y sus siguientes pasos.
-
----
-
-## Como usar este documento
-
-Este archivo funciona como listado rapido de ideas, lineas de trabajo y frentes pendientes del workspace.
-
-Cuando el usuario pregunte que hay pendiente por hacer, este documento debe permitir responder con un panorama rapido y claro.
-
-No debe convertirse en un gestor detallado de tareas ni duplicar informacion que pertenezca a otros documentos.
-
----
-
-## Lineas de trabajo prioritarias
-
-### 1. Sistema basico RAG reutilizable
-
-**Objetivo:**  
-Diseñar una base RAG simple, modular y facil de conectar a otros servicios ya existentes.
-
-**Enfoque inicial:**
-- Definir una arquitectura minima reutilizable.
-- Permitir conexion sencilla desde otros servicios o agentes.
-- Separar claramente ingesta, almacenamiento, recuperacion y consumo.
-- Evaluar un formato de configuracion que permita adaptar el RAG a distintos clientes o casos de uso.
-
-**Pendientes iniciales:**
-- Definir estructura base del proyecto o modulo.
-- Elegir estrategia inicial de almacenamiento y vectorizacion.
-- Definir interfaz de integracion con servicios externos.
-- Identificar un primer caso real de uso para validacion.
-- Revisar y sustituir mas adelante el modelo actual de `answer` por una opcion alineada con la decision de no depender de OpenAI para esa capa.
-
-**Estado:** En marcha
-
-**Estado actual resumido:**
-- La v1 del servicio RAG ya esta desplegada y operativa en `VPS2`.
-- Dominio activo: `https://rag.por-correo.com`
-- Modos ya funcionales: `documental` y `codigo`
-- Endpoints operativos: `health`, `ingest`, `retrieve`, `answer`
-
-**Pendientes inmediatos reales:**
-- Sustituir el modelo actual de `answer` por una opcion no-OpenAI.
-- Crear una metodologia reutilizable de despliegue correcto en EasyPanel para futuros servicios.
-- Valorar refinados adicionales en retrieval y answer segun uso real.
-
----
-
-### 2. Estructura MCP para integracion de tools
-
-**Objetivo:**  
-Preparar una estructura MCP que permita ir conectando nuestras tools con otros servicios que vayamos desarrollando y poniendo en funcionamiento.
-
-**Enfoque inicial:**
-- Dejar una base de organizacion clara para futuras tools.
-- Definir criterios para exponer capacidades de forma consistente.
-- Diseñar una estructura que facilite escalar nuevas integraciones.
-- Mantener separacion entre tools independientes y tools de soporte para otros servicios.
-
-**Pendientes iniciales:**
-- Definir estructura minima MCP del workspace.
-- Establecer convenciones de organizacion para nuevas tools.
-- Identificar primeras capacidades a exponer.
-- Documentar como se conectara con servicios internos y externos.
-
-**Estado:** Pendiente
-
----
-
-### 3. Potenciar agentes de Retell con herramientas y flujos externos
-
-**Objetivo:**  
-Preparar una integracion para que Retell pueda conectarse con flujos y servicios externos, como n8n y otros sistemas, de manera que el agente telefonico pueda apoyarse en herramientas adicionales y fuentes externas de informacion.
-
-**Contexto actual:**
-- Existe un flujo en n8n para atencion al cliente.
-- Ese flujo ya dispone de varias herramientas para atender clientes de una empresa concreta.
-- Actualmente las peticiones suelen llegar desde WhatsApp.
-- Se quiere que Retell pueda aprovechar ese tipo de flujos externos y tambien futuras integraciones similares.
-
-**Enfoque inicial:**
-- Analizar como Retell puede invocar herramientas o endpoints externos.
-- Diseñar una capa de integracion reutilizable para conectar Retell con n8n u otros servicios.
-- Reutilizar herramientas ya existentes sin acoplarlas a un unico canal.
-- Dejar preparada una via estandar para futuras integraciones de voz con fuentes externas.
-
-**Pendientes iniciales:**
-- Definir payloads de entrada y salida entre Retell y servicios externos.
-- Identificar endpoint, adaptador o capa intermedia de integracion.
-- Mapear como reutilizar el flujo actual de n8n desde Retell.
-- Detectar necesidades de contexto, autenticacion, trazabilidad y control de errores.
-
-**Estado:** Pendiente
-
----
-
-### 4. Explorar posible potenciacion del RAG con Obsidian
-
-**Objetivo:**  
-Evaluar si Obsidian puede aportar valor como capa de organizacion, fuente de conocimiento o apoyo a futuras capacidades del sistema RAG.
-
-**Pendientes iniciales:**
-- Revisar en que puntos podria integrarse con el RAG.
-- Valorar si aporta ventajas reales para documentacion, enlaces entre conceptos o gestion de conocimiento.
-- Dejarlo como linea futura, sin afectar a la salida de la v1.
-
-**Estado:** Pendiente
-
----
-
-## Criterios generales de desarrollo
-
-- Priorizar soluciones simples y reutilizables.
-- Favorecer integraciones desacopladas de un unico canal o proveedor.
-- Diseñar cada tool pensando en reutilizacion por otros servicios.
-- Documentar decisiones tecnicas y aprendizajes a medida que avancemos.
-
----
-
-## Proximos pasos sugeridos
-
-1. Sustituir el modelo actual de `answer` por una alternativa alineada con la estrategia del proyecto.
-2. Documentar la metodologia correcta para desplegar futuros servicios en EasyPanel.
-3. Diseñar la estructura inicial MCP del workspace.
-
----
-
-## Resumen rapido
-
-| Linea | Estado |
-|-------|--------|
-| Sistema basico RAG reutilizable | En marcha |
-| Estructura MCP para integracion de tools | Pendiente |
-| Retell conectado con herramientas externas | Pendiente |
-| Posible potenciacion del RAG con Obsidian | Pendiente |

docs/README.md

@@ -1,75 +0,0 @@
-# README para agentes del workspace
-
-## Proyecto: Workspace de tools IA para empresas
-
-Lee este archivo antes de crear documentos, editar documentacion o registrar sesiones.
-
----
-
-## Objetivo del workspace
-
-En este workspace desarrollamos tools, herramientas, skills, integraciones y componentes reutilizables para potenciar implementaciones de IA en empresas.
-
-Esto incluye, entre otros:
-- sistemas RAG
-- servidores o estructuras MCP
-- integraciones con servicios externos
-- herramientas reutilizables para otros servicios de IA
-- pruebas tecnicas, experimentos e investigaciones aplicadas
-
----
-
-## Documentos base
-
-Consulta siempre estos documentos:
-
-1. `docs/INDICE_DOCUMENTACION.md`
-2. `docs/README.md`
-3. `docs/HISTORIAL_SESIONES.md`
-4. `docs/PENDIENTES_GENERALES.md`
-5. `docs/sesion_actual_opencode.md`
-
----
-
-## Reglas de documentacion
-
-1. Toda la documentacion del workspace va en `docs/`.
-2. Antes de crear un documento nuevo, revisa `docs/INDICE_DOCUMENTACION.md` para evitar duplicados.
-3. Si creas un documento nuevo, indexalo en `docs/INDICE_DOCUMENTACION.md` en la misma sesion.
-4. Si haces un cambio relevante en el workspace, revisa si hay que actualizar `docs/PENDIENTES_GENERALES.md` o `docs/HISTORIAL_SESIONES.md`.
-5. `docs/sesion_actual_opencode.md` es una instruccion universal del workspace y no debe modificarse salvo peticion explicita del usuario.
-
----
-
-## Identificacion del agente
-
-Si el usuario pide identificacion, revisa `docs/HISTORIAL_SESIONES.md` y responde con:
-
-```text
-Soy el [Nombre del Agente].
-Trabajo en el proyecto: [Nombre del Proyecto].
-Mi Conversation ID es: [valor disponible o N/D].
-Me encargo de: [responsabilidad].
-```
-
-En este entorno OpenCode puede no exponer `Conversation ID`, por lo que puede usarse `session_id` del workspace como referencia operativa cuando aplique.
-
----
-
-## Registro de sesiones
-
-Al finalizar una sesion de trabajo relevante:
-
-1. Actualiza `docs/HISTORIAL_SESIONES.md`.
-2. Registra el agente, modelo y trabajo realizado.
-3. Incluye `session_id` de OpenCode cuando sea util para identificar la sesion del workspace.
-
----
-
-## Criterios de trabajo
-
-1. Priorizar soluciones simples, reutilizables y desacopladas.
-2. Pensar cada tool como pieza aprovechable por otros servicios.
-3. Mantener foco en integraciones utiles para IA empresarial.
-4. Evitar arrastrar documentacion de otros proyectos a este workspace.
-5. Mantener la documentacion alineada con el estado real del workspace.

docs/TASK.md

@@ -1,73 +0,0 @@
-# TASK
-
-**Proyecto:** Workspace de tools IA para empresas  
-**Ultima actualizacion:** 2026-04-02  
-**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales
-
----
-
-## Proposito
-
-Este documento sirve para partir lineas de trabajo amplias en bloques de analisis y acuerdos, de forma que podamos avanzar sin dejarnos puntos importantes por el camino.
-
-No sustituye a `docs/PENDIENTES_GENERALES.md`.
-
-- `PENDIENTES_GENERALES.md` mantiene el panorama rapido de ideas y lineas pendientes.
-- `TASK.md` descompone una linea concreta cuando requiere varias conversaciones, decisiones o pasos.
-
----
-
-## Task principal
-
-### Diseño y planeacion del tipo de RAG a crear
-
-**Objetivo de esta task:**
-Definir con claridad que tipo de sistema RAG queremos construir para que sea util, reutilizable, robusto desde una primera version sencilla y preparado para crecer hacia proyectos de clientes.
-
-**Puntos a analizar y convenir:**
-
-1. Diseño de fuentes
-- Que tipos de fuentes debe soportar el sistema.
-- Si empezamos solo con documentos o dejamos preparada entrada para APIs, bases de datos u otras fuentes.
-- Como desacoplar conectores para que el sistema se adapte a distintos clientes.
-
-2. Modelo de conocimiento
-- Como representar la informacion de forma util para recuperacion.
-- Que metadatos minimos conviene guardar desde el inicio.
-- Como preparar el sistema para distintas clases de contenido.
-
-3. Estrategia de chunking
-- Como dividir la informacion en fragmentos utiles.
-- Que nivel de contexto debe conservar cada fragmento.
-- Como evitar fragmentos demasiado pequenos, demasiado grandes o sin sentido aislado.
-
-4. Recuperacion
-- Como encontrar el contexto mas relevante para una consulta.
-- Que enfoque minimo usar en la primera version.
-- Como dejar abierta la puerta a mejoras posteriores.
-
-5. Multi-tenant y reutilizacion por cliente
-- Como dar servicio a distintos clientes o proyectos con una misma base RAG.
-- Como aislar informacion por cliente, app o entorno.
-- Como preparar el sistema para que mejoras internas beneficien a todos los consumidores del servicio.
-
-6. Interfaz de integracion
-- Como consumiran el RAG otros agentes, tools o servicios.
-- Si la primera interfaz sera API, libreria, CLI, MCP o una combinacion.
-- Como evitar acoplar el RAG a un unico tipo de consumidor.
-
-7. Observabilidad
-- Que informacion necesitaremos para entender que esta recuperando el sistema.
-- Como sabremos de donde sale el contexto devuelto.
-- Que datos son utiles para depurar y mejorar el RAG.
-
-8. Evaluacion
-- Como validar si recupera bien.
-- Como medir si la respuesta mejora con el contexto recuperado.
-- Como detectar errores, ruido o falta de cobertura.
-
-**Criterio de trabajo para esta task:**
-- Empezar simple.
-- Diseñar con vision de crecimiento.
-- Evitar complejidad innecesaria en la primera version.
-- Dejar preparadas las decisiones que condicionan una evolucion futura sana.

docs/sesion_actual_opencode.md

@@ -1,41 +0,0 @@
-# Sesion actual de OpenCode (instruccion universal para cualquier agente)
-
-Objetivo:
-- Que cualquier agente, incluso uno simple, pueda identificar su sesion del workspace actual sin ambiguedad.
-
-## Mensaje exacto para dar al agente
-
-Copiar y pegar tal cual:
-
-```text
-Lee `docs/sesion_actual_opencode.md` y ejecuta exactamente este comando para identificar tu sesion del workspace actual:
-
-opencode db "SELECT id,title,directory,datetime(time_updated/1000,'unixepoch','localtime') AS updated FROM session WHERE directory='$(pwd)' ORDER BY time_updated DESC LIMIT 1" --format tsv
-
-Luego responde SOLO con:
-1) `session_id`
-2) `title`
-3) `directory`
-4) `updated`
-
-Si no hay filas, responde exactamente: `SIN_SESION_EN_ESTE_WORKSPACE`.
-No inventes datos.
-```
-
-## Comando canonico (fuente de verdad)
-
-```bash
-opencode db "SELECT id,title,directory,datetime(time_updated/1000,'unixepoch','localtime') AS updated FROM session WHERE directory='$(pwd)' ORDER BY time_updated DESC LIMIT 1" --format tsv
-```
-
-## Continuar automaticamente la sesion detectada
-
-```bash
-opencode -s "$(opencode db \"SELECT id FROM session WHERE directory='$(pwd)' ORDER BY time_updated DESC LIMIT 1\" --format tsv | awk 'NR==2{print $1}')"
-```
-
-## Ver historial corto del workspace actual (ultimas 10)
-
-```bash
-opencode db "SELECT id,title,datetime(time_updated/1000,'unixepoch','localtime') AS updated FROM session WHERE directory='$(pwd)' ORDER BY time_updated DESC LIMIT 10" --format tsv
-```