rag-service/docs/HISTORIAL_SESIONES.md

284 lines
16 KiB
Markdown

# Historial de sesiones
**Proyecto:** Workspace de tools IA para empresas
**Modulo:** RAG
**Ultima actualizacion:** 2026-09-08
**Ultima modificacion por:** Agente RAG 2
**Estado:** Activo
---
## Registro de sesion
### 2026-09-11 - Agente RAG 2 - Preparacion PostgreSQL
**Modelo:** gpt-5.6-luna
**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Trabajo realizado:**
- Inspeccion de solo lectura completada por SSH en VPS2 usando el contenedor `ia_servicios_postgres-ia-servicios`.
- Creada la base `db_rag` y el usuario dedicado `usr_rag`, propietario de su base y con permisos completos sobre su esquema y objetos futuros.
- Verificado el acceso de `usr_rag` por TCP contra `db_rag`.
- Separada la ejecucion de migraciones SQL del arranque normal del servicio RAG.
- Actualizados el procedimiento de despliegue y los paquetes de mejoras diferidas.
**Validacion:**
- `npm run check` correcto.
- `npm test` correcto: 25/25.
- `npm run build` correcto.
- `git diff --check` correcto.
**Estado final:**
- PostgreSQL preparado a nivel de base y usuario.
- Pendiente configurar la conexion en EasyPanel, ejecutar explicitamente el esquema y verificar produccion.
- La contraseña se conserva en el archivo local ignorado `RAG/llaves` y no se persiste en documentacion versionada.
**Archivos modificados:**
- `Dockerfile`
- `package.json`
- `docs/DESPLIEGUE_EASYPANEL.md`
- `docs/PENDIENTES_RAG.md`
- `docs/HISTORIAL_SESIONES.md`
### 2026-09-11 - Agente RAG 2 - Mejoras diferidas
**Modelo:** openai/gpt-6-astra
**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`
**Rol:** Continuidad operativa y evolutiva del RAG.
- Añadido paquete posterior de seguimiento del corpus por API y frontend al punto 2.
- Añadido paquete posterior de backups manuales al punto 7, limitado a RAG y Qdrant; la base de n8n queda fuera.
- Retirados los backups habituales del prerrequisito bloqueante PostgreSQL, conservando el snapshot propio de la migracion legacy.
- Estado: mejoras diferidas sin urgencia; preparacion PostgreSQL sigue como tarea actual.
- Archivos: `RAG/docs/PENDIENTES_RAG.md`, `RAG/docs/HISTORIAL_SESIONES.md`, `docs/HISTORIAL_SESIONES.md`.
### 2026-09-11 - Agente RAG 2
**Modelo:** gpt-5.6-luna
**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Trabajo realizado:**
- Confirmado que PostgreSQL se introdujo con el punto 2 y que no existia una URL previa del RAG que se hubiera perdido.
- Detectada la omision de configuracion operativa de la nueva dependencia en EasyPanel.
- Documentado el incidente en `docs/REGISTRO_SITUACIONES.md`.
- Creado en `PENDIENTES_RAG.md` el prerrequisito bloqueante de preparar PostgreSQL, crear/verificar esquema, configurar conexion, revisar operacion y cargar las fuentes actuales.
- Actualizados los estados de la documentacion del punto 2.
**Estado final:**
- No se ejecutaran migraciones legacy, pruebas de ciclo de vida ni OCR hasta completar el prerrequisito PostgreSQL.
**Archivos modificados:**
- `RAG/docs/PENDIENTES_RAG.md`
- `RAG/docs/API_RAG.md`
- `RAG/docs/INGESTA.md`
- `RAG/docs/SISTEMA_RAG_BASE.md`
- `RAG/docs/CONTRATO_CICLO_VIDA_Y_OCR.md`
- `RAG/docs/DESPLIEGUE_EASYPANEL.md`
- `RAG/docs/HISTORIAL_SESIONES.md`
- `docs/REGISTRO_SITUACIONES.md`
### 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.
---
### 2026-09-08 - Agente RAG 2
**Modelo:** gpt-5.6-sol
**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Trabajo realizado:**
- Auditoria de las 14 operaciones HTTP existentes y de sus contratos reales.
- Implementacion de `GET /help` y `GET /openapi.json`, dejando 16 operaciones documentadas.
- Creacion de un contrato OpenAPI 3.1.1 con esquemas, parametros, respuestas, errores y ejemplos.
- Reescritura de `docs/API_RAG.md` como guia operativa enlazada al contrato OpenAPI.
- Correccion del estado obsoleto de playground, logs, cleanup, stack y documentos de diseño.
- Correccion de la metodologia: local se limita a compilacion y comprobaciones estaticas; los flujos HTTP se validan tras publicar en produccion.
- Validacion satisfactoria con `npm run check`, `npm run build`, comprobacion de referencias OpenAPI y contraste automatico entre rutas implementadas y documentadas.
- Deteccion del build context obsoleto `/RAG` en EasyPanel tras la migracion del repositorio.
- Ajuste por el usuario de `Ruta de compilacion` a `/` y despliegue satisfactorio del commit `f1cd87c`.
- Validacion en produccion de health, Qdrant, playground, sources, `/help` y `/openapi.json`.
- Regresion satisfactoria de retrieval sobre FacturaTech: 6 resultados, cero fugas de scope y coincidencias `504` en los primeros resultados.
- Deteccion posterior de que `/help` enlazaba OpenAPI pero no explicaba para que debia consultarse.
- Incorporacion de una instruccion explicita en `/help` sobre parametros, cuerpos, respuestas, errores y ejemplos disponibles en `/openapi.json`.
- Deploy del ajuste `953ff25` y revalidacion satisfactoria de `/help`, `/openapi.json` y `/health` en produccion.
**Estado final:**
- Pendiente 1 completado y validado definitivamente en `https://rag.por-correo.com`.
- La API dispone de descubrimiento rapido y contrato OpenAPI para sus 16 operaciones.
- Siguiente prioridad: ciclo de vida del conocimiento.
---
### 2026-09-08 - Agente RAG 2
**Modelo:** gpt-5.6-sol
**Session ID OpenCode:** `ses_29bdbd003ffeLrLjUlFgnp08Y7`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Subagentes de analisis:**
- `Subagente Extraccion de versiones PaddleOCR`: contraste de versiones PyPI compatibles para el benchmark CPU.
- `Subagente Validacion del ciclo de vida`: revision adversarial del catalogo PostgreSQL y versionado Qdrant.
- `Subagente Validacion OCR`: revision adversarial de deteccion, servicio privado, quality gates y revision humana.
- `Subagente Auditoria de claridad del contrato`: detecto contradicciones de hashes, idempotencia, migracion y revision.
- `Subagente Revalidacion de ejecutabilidad`: detecto bloqueos restantes en metadata, concurrencia y artefactos.
- `Subagente Revalidacion de resiliencia`: reviso carreras, barreras de migracion y recuperacion de jobs.
- `Subagente Revision final del contrato`: verifico y cerro la secuencia segura de rollback legacy.
**Trabajo realizado:**
- Auditoria del pipeline actual de ingesta, IDs, Qdrant, parser PDF, API e infraestructura EasyPanel.
- Confirmacion de PostgreSQL 17 como catalogo transaccional y Qdrant como almacenamiento vectorial versionado.
- Benchmark aislado en VPS2 con el PDF mixto real de FacturaTech.
- Descarte de Tesseract como motor unico por omitir identificadores criticos.
- Seleccion de PaddleOCR como motor principal y deteccion de errores alfanumericos de alta confianza que obligan a revision humana.
- Creacion de `docs/CONTRATO_CICLO_VIDA_Y_OCR.md` con esquema, estados, APIs, migracion, OCR, tareas, pruebas, despliegue y rollback.
- Enlace del contrato desde el backlog canonico.
- Correccion del contrato mediante revisiones adversariales hasta eliminar sus bloqueos criticos conocidos.
- Limpieza de los artefactos e imagenes temporales usados en el benchmark local y de VPS2.
**Estado final:**
- Diseño de los pendientes 2 y 3 cerrado y listo para implementacion secuencial.
- El punto 2 debe completarse y validarse en produccion antes de iniciar el punto 3.
- No se modifico codigo ni produccion durante esta fase de diseño.
**Archivos modificados:**
- `RAG/docs/CONTRATO_CICLO_VIDA_Y_OCR.md`
- `RAG/docs/PENDIENTES_RAG.md`
- `RAG/docs/HISTORIAL_SESIONES.md`
- `docs/INDICE_DOCUMENTACION.md`
- `docs/HISTORIAL_SESIONES.md`
---
### 2026-09-11 - Subagente Implementacion ciclo de vida del conocimiento
**Modelo:** openai/gpt-5.5
**Session ID OpenCode:** `ses_f6fe0ad30ffeiottYsATsRemCo`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Rol asumido:**
Ejecutar la fase apply del punto 2 del RAG y corregir los bloqueadores finales detectados antes de commit, push o despliegue.
**Trabajo realizado:**
- Ajuste del migrador legacy para permitir reanudacion por `--batch-id`, reutilizando versiones ya creadas y completando activacion tras actualizaciones de payload ya aplicadas.
- Endurecimiento de rollback legacy con lock global de migracion, comprobacion de snapshot y operaciones serializadas sobre fuentes/versiones.
- Reconciliador protegido con advisory lock no bloqueante, timeout configurable basado en `indexing_started_at` y validacion de coleccion/dimensiones.
- Protecciones adicionales: `POST /cleanup` respeta `INGEST_WRITES_ENABLED`, `markPurged` valida `rowCount`, rollback usa locks y OpenAPI refleja `503` en health con `ok` booleano.
- Script `migrate:legacy:lifecycle` ajustado para ejecutarse desde `dist/` con Node tras build.
- Añadidos tests unitarios para reanudacion legacy, activacion idempotente, cleanup con escrituras deshabilitadas, reconciliador, mismatch de coleccion y `markPurged`.
**Validacion local:**
- `npm run check` correcto.
- `npm test` correcto: 18 tests pasan.
- `npm run build` correcto.
- `git diff --check` correcto.
**Estado final:**
- Punto 2 implementado y validado localmente.
- No se hizo commit, push, deploy ni lectura de `.env`.
- Sigue pendiente la verificacion independiente y la validacion/migracion en produccion antes de marcar el punto 2 como cerrado.
**Archivos modificados en esta correccion:**
- `.env.example`
- `package.json`
- `package-lock.json`
- `src/config/env.ts`
- `src/modules/catalog/client.ts`
- `src/modules/catalog/repository.ts`
- `src/modules/catalog/reconciler.ts`
- `src/modules/vectorstore/client.ts`
- `src/modules/retrieve/service.ts`
- `src/modules/ingest/service.ts`
- `src/scripts/migrate-legacy-lifecycle.ts`
- `src/api/openapi.ts`
- `tests/lifecycle-services.test.ts`
- `docs/API_RAG.md`
- `docs/DESPLIEGUE_EASYPANEL.md`
- `docs/SISTEMA_RAG_BASE.md`
- `RAG/docs/HISTORIAL_SESIONES.md`
---
### 2026-09-11 (reanudacion final) - Subagente Implementacion ciclo de vida del conocimiento
**Modelo:** openai/gpt-5.5
**Session ID OpenCode:** `ses_f6fe0ad30ffeiottYsATsRemCo`
**Directorio:** `/home/pancho/Documentos/Empresa/Desarrollo/IA/RAG`
**Rol asumido:**
Completar los 4 bloqueos del sdd-verify y cerrar la validacion local del punto 2.
**Trabajo realizado:**
- Reconciliador: recupera versiones huerfanas `pending/indexing` a `ready` contando puntos Qdrant y validando documentos, coleccion y dimensiones; marca `failed` solo si quedan incompletas; try-locks evitan matar ingestas vivas.
- Ingesta: rechaza embeddings con dimensiones distintas de las esperadas antes del upsert y antes de alcanzar `ready`.
- Rollback legacy: transaccion diferida del lote, confirmacion de cero punteros activos, restauracion de snapshot con verificacion de recuentos y limpieza posterior del catalogo.
- OpenAPI: `/sources` documenta `503`.
- Retrieval: locks compartidos adquiridos antes de validar recuento/dimensiones y mantenidos durante toda la consulta Qdrant.
- Interrupcion por limite de uso a mitad de la validacion; reanudada tras cambio de cuenta y completada hasta el final.
**Validacion local:**
- `npm run check` correcto.
- `npm test` correcto: 25/25 tests pasan.
- `npm run build` correcto.
- `git diff --check` correcto.
- Verificacion independiente (sdd-verify): PASS local.
**Estado final:**
- Implementacion local del punto 2 verificada de forma independiente: PASS local.
- No se hizo commit, push, deploy ni lectura de `.env`.
- Pendiente: commit/push, deploy con enforcement desactivado, migracion legacy y validacion en produccion antes de cerrar el punto 2.