paco/rag-service
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rag-service/docs/REGISTRO_SITUACIONES.md

6.2 KiB
Raw Blame History

Registro de situaciones detectadas

Este documento registra errores, incidencias, bloqueos y hallazgos concretos. No sustituye HISTORIAL_SESIONES.md, que resume las sesiones de trabajo.

Como registrar una entrada

  1. Usa fecha y hora local en formato YYYY-MM-DD HH:mm.
  2. Incluye evidencia verificable cuando exista.
  3. Indica el estado: pendiente, en analisis, resuelto o descartado.
  4. No borres entradas anteriores; actualizalas o anade una nota posterior.

Plantilla de entrada

### Entrada (YYYY-MM-DD HH:mm)

- Contexto:
- Situacion observada:
- Resultado esperado:
- Resultado real:
- Evidencia:
- Accion aplicada:
- Validacion posterior:
- Estado: pendiente | en analisis | resuelto | descartado

Entradas

Entrada (2026-09-17 12:00)

  • Contexto: Diagnostico remoto de solo lectura del error OCR FacturaTech v4.
  • Flujo probado: Automatizacion SSH hacia VPS2 a partir de la fuente canonica de acceso.
  • Situacion observada: Los delimitadores Markdown de la contrasena causaban extracciones incorrectas recurrentes; un intento PTY que reenvio la entrada estandar expuso el valor en la salida local y no autentico.
  • Resultado esperado: Extraer y usar la credencial sin delimitadores ni exponerla.
  • Resultado real: Se eliminaron los backticks de la fuente canonica; la linea de contrasena se valido sin delimitadores.
  • Evidencia: Servidores/VPS2/Vps2_despliegue_apps/instrucciones_montado_y_despliegue_apps_vps2_easypanel.md; Engram #3197, #3292 y #3598.
  • Hipotesis de causa: El formato Markdown introducia ambiguedad para extractores automatizados; script no es apto para recibir una contrasena por entrada estandar porque puede hacer eco antes de que SSH desactive el eco.
  • Accion aplicada: Eliminados los delimitadores Markdown con aprobacion explicita del usuario. Queda prohibido reenviar la contrasena por entrada estandar a una pseudo-terminal.
  • Validacion posterior: La linea de contrasena existe y no contiene backticks; acceso remoto pendiente mediante un mecanismo PTY que no use entrada estandar.
  • Estado: en analisis
  • Notas: El usuario difiere la rotacion de credenciales hasta el cierre de desarrollo. No registrar ni volver a mostrar el valor.

Entrada (2026-09-17 12:10)

  • Contexto: Revision productiva de la candidata OCR FacturaTech v4 ce1b6462-7617-4721-aa3a-8e8216a584ed.
  • Flujo probado: GET /ingestions/:versionId/review, comprobacion remota de solo lectura del volumen /data/ingestions y recuperacion administrativa autenticada aprobada por el usuario.
  • Situacion observada: La version estaba en review_required, pero su evidencia durable estaba incompleta.
  • Resultado esperado: Preservar manifest, paginas nativas, resultado OCR, imagenes y candidate-pages.json antes de pasar a revision.
  • Resultado real: Solo existen manifest.json y el PDF original; faltan las paginas nativas, resultados OCR, imagenes de revision y candidate-pages.json.
  • Evidencia: ENOENT para /data/ingestions/ce1b6462-7617-4721-aa3a-8e8216a584ed/candidate-pages.json; inspeccion de solo lectura del contenedor RAG y Engram #3600.
  • Hipotesis de causa: Confirmada. v4 se creo seis horas antes de desplegar el lector durable de revision. El flujo anterior marcaba review_required sin persistir paginas nativas, resultado OCR, imagenes ni candidata compuesta.
  • Accion aplicada: Tras confirmar el contrato seguro 409 OCR_ARTIFACT_UNAVAILABLE con accion use_admin_recovery y recibir aprobacion explicita del usuario, POST /ingestions/:versionId/recover cerro exclusivamente v4 como failed con resultado closed_failed.
  • Validacion posterior: PostgreSQL confirma que v4 no es activa, conserva la version activa previa de la fuente, contiene un registro de auditoria y ya no hay candidatas OCR bloqueantes.
  • Estado: resuelto
  • Notas: No se aprobo, rechazo, indexo ni activo contenido.

Entrada (2026-09-11 23:00)

  • Contexto: Inspeccion SSH de PostgreSQL para preparar la base del RAG.
  • Flujo probado: Conexion mediante SSH_ASKPASS usando la fuente canonica de credenciales de VPS2.
  • Situacion observada: Las primeras conexiones fallaron porque el agente incluyo los backticks Markdown de la contrasena al extraerla del documento.
  • Resultado esperado: Conectar usando solo el valor de la contrasena, sin delimitadores de formato.
  • Resultado real: La conexion funciono al eliminar los backticks. La consulta posterior a PostgreSQL no pudo usar el rol postgres porque ese rol no existe en la instancia.
  • Evidencia: Servidores/VPS2/Vps2_despliegue_apps/instrucciones_montado_y_despliegue_apps_vps2_easypanel.md; salida SSH; error FATAL: role "postgres" does not exist.
  • Hipotesis de causa: La instancia usa el usuario administrativo configurado por EasyPanel, no necesariamente el rol estandar postgres.
  • Accion aplicada: Anadida una nota permanente en la fuente canonica indicando que no se deben usar los backticks.
  • Validacion posterior: SSH funciona; queda identificar el usuario administrativo real sin asumir postgres.
  • Estado: en analisis
  • Notas: No repetir intentos con postgres hasta consultar la configuracion de la instancia sin exponer contrasenas.

Entrada (2026-09-11 20:27)

  • Contexto: Deploy del punto 2 del ciclo de vida del conocimiento del RAG.
  • Flujo probado: Inicio del servicio y consulta GET https://rag.por-correo.com/health.
  • Situacion observada: El RAG se desplego y escuchaba, pero PostgreSQL aparecia como no disponible.
  • Resultado esperado: PostgreSQL preparado, conectado y disponible para el catalogo de fuentes y versiones.
  • Resultado real: Qdrant y el reconciliador estaban operativos, pero postgres.ok=false por falta de configuracion de conexion en EasyPanel.
  • Evidencia: Respuesta de /health; src/config/env.ts; src/modules/catalog/client.ts; migrations/001_knowledge_lifecycle.sql; commit 551cfe8.
  • Hipotesis de causa: Faltaba crear o confirmar la base de datos, configurar POSTGRES_URL/POSTGRES_SSL y completar la preparacion operativa de PostgreSQL.
  • Accion aplicada: Se detuvieron la migracion legacy, la activacion de enforcement y el inicio de OCR. Se creo un prerrequisito bloqueante en docs/PENDIENTES_RAG.md.
  • Validacion posterior: Esta incidencia historica fue superada; la validacion local de 004 sigue pendiente como R4.
  • Estado: resuelto
  • Notas: No compartir credenciales.