From b9a37f27c982fd1b2d65c34edb572edbaa9c1638 Mon Sep 17 00:00:00 2001 From: Paco POR-CORREO Date: Tue, 21 Jul 2026 22:11:28 +0200 Subject: [PATCH] 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 --- RAG/.dockerignore => .dockerignore | 0 RAG/.env.example => .env.example | 6 +- .gitignore | 13 +- RAG/Dockerfile => Dockerfile | 0 RAG/.gitignore | 5 - RAG/docs/HISTORIAL_SESIONES.md | 66 --- .../AGENTE_GSTREAMER_OPENCODE.jsonc | 0 .../INSTALAR_EN_OTRO_PC.md | 0 .../rag_gstreamer_bootstrap.sh | 0 .../rag_gstreamer_retrieve.sh | 0 {RAG/docs => docs}/AGENTE_GSTREAMER.md | 0 .../AGENTE_GSTREAMER_OPENCODE.jsonc | 0 {RAG/docs => docs}/API_RAG.md | 0 {RAG/docs => docs}/BITACORA_DISENO_RAG.md | 0 {RAG/docs => docs}/DESPLIEGUE_EASYPANEL.md | 24 + .../DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md | 0 docs/HISTORIAL_SESIONES.md | 166 ++----- docs/INDICE_DOCUMENTACION.md | 454 ------------------ {RAG/docs => docs}/INGESTA.md | 0 .../INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md | 0 {RAG/docs => docs}/LOGS_EVALUACION.md | 0 docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md | 200 ++++++++ docs/PENDIENTES_GENERALES.md | 151 ------ {RAG/docs => docs}/PLAYGROUND.md | 0 {RAG/docs => docs}/PROCESADO.md | 0 docs/README.md | 75 --- {RAG/docs => docs}/SALIDA.md | 0 {RAG/docs => docs}/SISTEMA_RAG_BASE.md | 0 {RAG/docs => docs}/STACK_TECNICO_V1.md | 0 docs/TASK.md | 73 --- {RAG/docs => docs}/TASK_INGESTA_GSTREAMER.md | 0 {RAG/docs => docs}/TASK_LIMPIEZA.md | 0 .../TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md | 0 {RAG/docs => docs}/TEXTOS_AYUDA_PLAYGROUND.md | 0 docs/sesion_actual_opencode.md | 41 -- RAG/package-lock.json => package-lock.json | 0 RAG/package.json => package.json | 0 {RAG/public => public}/playground/app.js | 0 {RAG/public => public}/playground/index.html | 0 {RAG/public => public}/playground/styles.css | 0 .../rag_gstreamer_bootstrap.sh | 0 .../rag_gstreamer_retrieve.sh | 0 {RAG/src => src}/app.ts | 0 {RAG/src => src}/config/env.ts | 0 {RAG/src => src}/modules/answer/service.ts | 0 .../modules/embeddings/provider.ts | 0 {RAG/src => src}/modules/ingest/service.ts | 0 {RAG/src => src}/modules/logs/service.ts | 0 .../modules/parsers/parser-registry.ts | 0 {RAG/src => src}/modules/process/chunking.ts | 0 {RAG/src => src}/modules/retrieve/service.ts | 0 .../src => src}/modules/vectorstore/client.ts | 0 {RAG/src => src}/server.ts | 0 {RAG/src => src}/shared/types/rag.ts | 0 {RAG/src => src}/shared/utils/files.ts | 0 {RAG/src => src}/shared/utils/ids.ts | 0 RAG/tsconfig.json => tsconfig.json | 0 57 files changed, 290 insertions(+), 984 deletions(-) rename RAG/.dockerignore => .dockerignore (100%) rename RAG/.env.example => .env.example (82%) rename RAG/Dockerfile => Dockerfile (100%) delete mode 100644 RAG/.gitignore delete mode 100644 RAG/docs/HISTORIAL_SESIONES.md rename {RAG/agente_gstreamer => agente_gstreamer}/AGENTE_GSTREAMER_OPENCODE.jsonc (100%) rename {RAG/agente_gstreamer => agente_gstreamer}/INSTALAR_EN_OTRO_PC.md (100%) rename {RAG/agente_gstreamer => agente_gstreamer}/rag_gstreamer_bootstrap.sh (100%) rename {RAG/agente_gstreamer => agente_gstreamer}/rag_gstreamer_retrieve.sh (100%) rename {RAG/docs => docs}/AGENTE_GSTREAMER.md (100%) rename {RAG/docs => docs}/AGENTE_GSTREAMER_OPENCODE.jsonc (100%) rename {RAG/docs => docs}/API_RAG.md (100%) rename {RAG/docs => docs}/BITACORA_DISENO_RAG.md (100%) rename {RAG/docs => docs}/DESPLIEGUE_EASYPANEL.md (92%) rename {RAG/docs => docs}/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md (100%) delete mode 100644 docs/INDICE_DOCUMENTACION.md rename {RAG/docs => docs}/INGESTA.md (100%) rename {RAG/docs => docs}/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md (100%) rename {RAG/docs => docs}/LOGS_EVALUACION.md (100%) create mode 100644 docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md delete mode 100644 docs/PENDIENTES_GENERALES.md rename {RAG/docs => docs}/PLAYGROUND.md (100%) rename {RAG/docs => docs}/PROCESADO.md (100%) delete mode 100644 docs/README.md rename {RAG/docs => docs}/SALIDA.md (100%) rename {RAG/docs => docs}/SISTEMA_RAG_BASE.md (100%) rename {RAG/docs => docs}/STACK_TECNICO_V1.md (100%) delete mode 100644 docs/TASK.md rename {RAG/docs => docs}/TASK_INGESTA_GSTREAMER.md (100%) rename {RAG/docs => docs}/TASK_LIMPIEZA.md (100%) rename {RAG/docs => docs}/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md (100%) rename {RAG/docs => docs}/TEXTOS_AYUDA_PLAYGROUND.md (100%) delete mode 100644 docs/sesion_actual_opencode.md rename RAG/package-lock.json => package-lock.json (100%) rename RAG/package.json => package.json (100%) rename {RAG/public => public}/playground/app.js (100%) rename {RAG/public => public}/playground/index.html (100%) rename {RAG/public => public}/playground/styles.css (100%) rename {RAG/scripts => scripts}/rag_gstreamer_bootstrap.sh (100%) rename {RAG/scripts => scripts}/rag_gstreamer_retrieve.sh (100%) rename {RAG/src => src}/app.ts (100%) rename {RAG/src => src}/config/env.ts (100%) rename {RAG/src => src}/modules/answer/service.ts (100%) rename {RAG/src => src}/modules/embeddings/provider.ts (100%) rename {RAG/src => src}/modules/ingest/service.ts (100%) rename {RAG/src => src}/modules/logs/service.ts (100%) rename {RAG/src => src}/modules/parsers/parser-registry.ts (100%) rename {RAG/src => src}/modules/process/chunking.ts (100%) rename {RAG/src => src}/modules/retrieve/service.ts (100%) rename {RAG/src => src}/modules/vectorstore/client.ts (100%) rename {RAG/src => src}/server.ts (100%) rename {RAG/src => src}/shared/types/rag.ts (100%) rename {RAG/src => src}/shared/utils/files.ts (100%) rename {RAG/src => src}/shared/utils/ids.ts (100%) rename RAG/tsconfig.json => tsconfig.json (100%) diff --git a/RAG/.dockerignore b/.dockerignore similarity index 100% rename from RAG/.dockerignore rename to .dockerignore diff --git a/RAG/.env.example b/.env.example similarity index 82% rename from RAG/.env.example rename to .env.example index 6f561ee..e204341 100644 --- a/RAG/.env.example +++ b/.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 diff --git a/.gitignore b/.gitignore index 95f02ec..aa533d4 100644 --- a/.gitignore +++ b/.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/ diff --git a/RAG/Dockerfile b/Dockerfile similarity index 100% rename from RAG/Dockerfile rename to Dockerfile diff --git a/RAG/.gitignore b/RAG/.gitignore deleted file mode 100644 index 3ac57e1..0000000 --- a/RAG/.gitignore +++ /dev/null @@ -1,5 +0,0 @@ -node_modules/ -dist/ -.env -.env.local -npm-debug.log* diff --git a/RAG/docs/HISTORIAL_SESIONES.md b/RAG/docs/HISTORIAL_SESIONES.md deleted file mode 100644 index c68d7bd..0000000 --- a/RAG/docs/HISTORIAL_SESIONES.md +++ /dev/null @@ -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. diff --git a/RAG/agente_gstreamer/AGENTE_GSTREAMER_OPENCODE.jsonc b/agente_gstreamer/AGENTE_GSTREAMER_OPENCODE.jsonc similarity index 100% rename from RAG/agente_gstreamer/AGENTE_GSTREAMER_OPENCODE.jsonc rename to agente_gstreamer/AGENTE_GSTREAMER_OPENCODE.jsonc diff --git a/RAG/agente_gstreamer/INSTALAR_EN_OTRO_PC.md b/agente_gstreamer/INSTALAR_EN_OTRO_PC.md similarity index 100% rename from RAG/agente_gstreamer/INSTALAR_EN_OTRO_PC.md rename to agente_gstreamer/INSTALAR_EN_OTRO_PC.md diff --git a/RAG/agente_gstreamer/rag_gstreamer_bootstrap.sh b/agente_gstreamer/rag_gstreamer_bootstrap.sh similarity index 100% rename from RAG/agente_gstreamer/rag_gstreamer_bootstrap.sh rename to agente_gstreamer/rag_gstreamer_bootstrap.sh diff --git a/RAG/agente_gstreamer/rag_gstreamer_retrieve.sh b/agente_gstreamer/rag_gstreamer_retrieve.sh similarity index 100% rename from RAG/agente_gstreamer/rag_gstreamer_retrieve.sh rename to agente_gstreamer/rag_gstreamer_retrieve.sh diff --git a/RAG/docs/AGENTE_GSTREAMER.md b/docs/AGENTE_GSTREAMER.md similarity index 100% rename from RAG/docs/AGENTE_GSTREAMER.md rename to docs/AGENTE_GSTREAMER.md diff --git a/RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc b/docs/AGENTE_GSTREAMER_OPENCODE.jsonc similarity index 100% rename from RAG/docs/AGENTE_GSTREAMER_OPENCODE.jsonc rename to docs/AGENTE_GSTREAMER_OPENCODE.jsonc diff --git a/RAG/docs/API_RAG.md b/docs/API_RAG.md similarity index 100% rename from RAG/docs/API_RAG.md rename to docs/API_RAG.md diff --git a/RAG/docs/BITACORA_DISENO_RAG.md b/docs/BITACORA_DISENO_RAG.md similarity index 100% rename from RAG/docs/BITACORA_DISENO_RAG.md rename to docs/BITACORA_DISENO_RAG.md diff --git a/RAG/docs/DESPLIEGUE_EASYPANEL.md b/docs/DESPLIEGUE_EASYPANEL.md similarity index 92% rename from RAG/docs/DESPLIEGUE_EASYPANEL.md rename to docs/DESPLIEGUE_EASYPANEL.md index 5b43782..930a7a1 100644 --- a/RAG/docs/DESPLIEGUE_EASYPANEL.md +++ b/docs/DESPLIEGUE_EASYPANEL.md @@ -199,6 +199,30 @@ Dato importante para `RAG`: - `ANSWER_BASE_URL=https://openrouter.ai/api/v1` - `ANSWER_API_KEY=` +### 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=` +- `ANSWER_PROVIDER=openrouter` +- `ANSWER_MODEL=openai/gpt-4.1-mini` +- `ANSWER_BASE_URL=https://openrouter.ai/api/v1` +- `ANSWER_API_KEY=` + +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 diff --git a/RAG/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md b/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md similarity index 100% rename from RAG/docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md rename to docs/DUDAS_DESPLIEGUE_WEBFETCH_VPS2.md diff --git a/docs/HISTORIAL_SESIONES.md b/docs/HISTORIAL_SESIONES.md index f448aa5..c68d7bd 100644 --- a/docs/HISTORIAL_SESIONES.md +++ b/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. diff --git a/docs/INDICE_DOCUMENTACION.md b/docs/INDICE_DOCUMENTACION.md deleted file mode 100644 index af0f1d4..0000000 --- a/docs/INDICE_DOCUMENTACION.md +++ /dev/null @@ -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 diff --git a/RAG/docs/INGESTA.md b/docs/INGESTA.md similarity index 100% rename from RAG/docs/INGESTA.md rename to docs/INGESTA.md diff --git a/RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md b/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md similarity index 100% rename from RAG/docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md rename to docs/INSTALAR_AGENTE_GSTREAMER_EN_OTRO_PC.md diff --git a/RAG/docs/LOGS_EVALUACION.md b/docs/LOGS_EVALUACION.md similarity index 100% rename from RAG/docs/LOGS_EVALUACION.md rename to docs/LOGS_EVALUACION.md diff --git a/docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md b/docs/METODOLOGIA_ITERACION_Y_REDEPLOY.md new file mode 100644 index 0000000..cc27d46 --- /dev/null +++ b/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: `` +- 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 diff --git a/docs/PENDIENTES_GENERALES.md b/docs/PENDIENTES_GENERALES.md deleted file mode 100644 index 3e1ee6c..0000000 --- a/docs/PENDIENTES_GENERALES.md +++ /dev/null @@ -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 | diff --git a/RAG/docs/PLAYGROUND.md b/docs/PLAYGROUND.md similarity index 100% rename from RAG/docs/PLAYGROUND.md rename to docs/PLAYGROUND.md diff --git a/RAG/docs/PROCESADO.md b/docs/PROCESADO.md similarity index 100% rename from RAG/docs/PROCESADO.md rename to docs/PROCESADO.md diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index cb63b10..0000000 --- a/docs/README.md +++ /dev/null @@ -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. diff --git a/RAG/docs/SALIDA.md b/docs/SALIDA.md similarity index 100% rename from RAG/docs/SALIDA.md rename to docs/SALIDA.md diff --git a/RAG/docs/SISTEMA_RAG_BASE.md b/docs/SISTEMA_RAG_BASE.md similarity index 100% rename from RAG/docs/SISTEMA_RAG_BASE.md rename to docs/SISTEMA_RAG_BASE.md diff --git a/RAG/docs/STACK_TECNICO_V1.md b/docs/STACK_TECNICO_V1.md similarity index 100% rename from RAG/docs/STACK_TECNICO_V1.md rename to docs/STACK_TECNICO_V1.md diff --git a/docs/TASK.md b/docs/TASK.md deleted file mode 100644 index 1490a14..0000000 --- a/docs/TASK.md +++ /dev/null @@ -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. diff --git a/RAG/docs/TASK_INGESTA_GSTREAMER.md b/docs/TASK_INGESTA_GSTREAMER.md similarity index 100% rename from RAG/docs/TASK_INGESTA_GSTREAMER.md rename to docs/TASK_INGESTA_GSTREAMER.md diff --git a/RAG/docs/TASK_LIMPIEZA.md b/docs/TASK_LIMPIEZA.md similarity index 100% rename from RAG/docs/TASK_LIMPIEZA.md rename to docs/TASK_LIMPIEZA.md diff --git a/RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md b/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md similarity index 100% rename from RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md rename to docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md diff --git a/RAG/docs/TEXTOS_AYUDA_PLAYGROUND.md b/docs/TEXTOS_AYUDA_PLAYGROUND.md similarity index 100% rename from RAG/docs/TEXTOS_AYUDA_PLAYGROUND.md rename to docs/TEXTOS_AYUDA_PLAYGROUND.md diff --git a/docs/sesion_actual_opencode.md b/docs/sesion_actual_opencode.md deleted file mode 100644 index d7469a4..0000000 --- a/docs/sesion_actual_opencode.md +++ /dev/null @@ -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 -``` diff --git a/RAG/package-lock.json b/package-lock.json similarity index 100% rename from RAG/package-lock.json rename to package-lock.json diff --git a/RAG/package.json b/package.json similarity index 100% rename from RAG/package.json rename to package.json diff --git a/RAG/public/playground/app.js b/public/playground/app.js similarity index 100% rename from RAG/public/playground/app.js rename to public/playground/app.js diff --git a/RAG/public/playground/index.html b/public/playground/index.html similarity index 100% rename from RAG/public/playground/index.html rename to public/playground/index.html diff --git a/RAG/public/playground/styles.css b/public/playground/styles.css similarity index 100% rename from RAG/public/playground/styles.css rename to public/playground/styles.css diff --git a/RAG/scripts/rag_gstreamer_bootstrap.sh b/scripts/rag_gstreamer_bootstrap.sh similarity index 100% rename from RAG/scripts/rag_gstreamer_bootstrap.sh rename to scripts/rag_gstreamer_bootstrap.sh diff --git a/RAG/scripts/rag_gstreamer_retrieve.sh b/scripts/rag_gstreamer_retrieve.sh similarity index 100% rename from RAG/scripts/rag_gstreamer_retrieve.sh rename to scripts/rag_gstreamer_retrieve.sh diff --git a/RAG/src/app.ts b/src/app.ts similarity index 100% rename from RAG/src/app.ts rename to src/app.ts diff --git a/RAG/src/config/env.ts b/src/config/env.ts similarity index 100% rename from RAG/src/config/env.ts rename to src/config/env.ts diff --git a/RAG/src/modules/answer/service.ts b/src/modules/answer/service.ts similarity index 100% rename from RAG/src/modules/answer/service.ts rename to src/modules/answer/service.ts diff --git a/RAG/src/modules/embeddings/provider.ts b/src/modules/embeddings/provider.ts similarity index 100% rename from RAG/src/modules/embeddings/provider.ts rename to src/modules/embeddings/provider.ts diff --git a/RAG/src/modules/ingest/service.ts b/src/modules/ingest/service.ts similarity index 100% rename from RAG/src/modules/ingest/service.ts rename to src/modules/ingest/service.ts diff --git a/RAG/src/modules/logs/service.ts b/src/modules/logs/service.ts similarity index 100% rename from RAG/src/modules/logs/service.ts rename to src/modules/logs/service.ts diff --git a/RAG/src/modules/parsers/parser-registry.ts b/src/modules/parsers/parser-registry.ts similarity index 100% rename from RAG/src/modules/parsers/parser-registry.ts rename to src/modules/parsers/parser-registry.ts diff --git a/RAG/src/modules/process/chunking.ts b/src/modules/process/chunking.ts similarity index 100% rename from RAG/src/modules/process/chunking.ts rename to src/modules/process/chunking.ts diff --git a/RAG/src/modules/retrieve/service.ts b/src/modules/retrieve/service.ts similarity index 100% rename from RAG/src/modules/retrieve/service.ts rename to src/modules/retrieve/service.ts diff --git a/RAG/src/modules/vectorstore/client.ts b/src/modules/vectorstore/client.ts similarity index 100% rename from RAG/src/modules/vectorstore/client.ts rename to src/modules/vectorstore/client.ts diff --git a/RAG/src/server.ts b/src/server.ts similarity index 100% rename from RAG/src/server.ts rename to src/server.ts diff --git a/RAG/src/shared/types/rag.ts b/src/shared/types/rag.ts similarity index 100% rename from RAG/src/shared/types/rag.ts rename to src/shared/types/rag.ts diff --git a/RAG/src/shared/utils/files.ts b/src/shared/utils/files.ts similarity index 100% rename from RAG/src/shared/utils/files.ts rename to src/shared/utils/files.ts diff --git a/RAG/src/shared/utils/ids.ts b/src/shared/utils/ids.ts similarity index 100% rename from RAG/src/shared/utils/ids.ts rename to src/shared/utils/ids.ts diff --git a/RAG/tsconfig.json b/tsconfig.json similarity index 100% rename from RAG/tsconfig.json rename to tsconfig.json