130 lines
11 KiB
Markdown
130 lines
11 KiB
Markdown
# Historial de sesiones
|
|
|
|
## Proyecto: Workspace de tools IA para empresas
|
|
|
|
Este archivo registra agentes y sesiones de trabajo de este workspace.
|
|
|
|
---
|
|
|
|
## Indice de agentes
|
|
|
|
| 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` |
|
|
|
|
---
|
|
|
|
## 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/`.
|
|
|
|
#### 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.
|
|
|
|
---
|
|
|
|
## 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.
|