docs(rag): record OCR cleanup closure

docs/CONTEXTO_PROYECTO.md

@@ -37,5 +37,5 @@ Servicio RAG para ingesta, versionado y recuperacion de conocimiento. Incluye un
 
 - `rag-service` es el unico proyecto Engram canonico; la sesion debe iniciarse desde la raiz de este worktree.
 - RAG y OCR `0.2.1` estan desplegados y verificados conjuntamente. El OCR queda aceptado para esta fase como servicio best-effort autonomo; la mejora de precision y la consola humana son evoluciones futuras no bloqueantes.
-- El scheduler durable y la validacion productiva hibrida estan completados. Los defectos de rechazo blank y purga OCR quedaron corregidos y validados localmente; la unidad esta autorizada para commit/push y el usuario realizara el despliegue posterior.
+- El scheduler durable, la validacion productiva hibrida y la correccion de rechazo blank/purga OCR estan desplegados y verificados en `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`.
-- FacturaTech v8 fue rechazada sin aprobarse, indexarse ni activarse. Tras el despliegue corregido se purgaran las candidatas descartadas y se verificara que v1 sigue activa.
+- Las dos candidatas sinteticas y FacturaTech v2-v8 estan `purged`; no quedan candidatas bloqueantes. FacturaTech v1 `3fc78163-9cfb-4979-985c-1520a63327b0` sigue activa con `36/36` puntos.

docs/HISTORIAL_SESIONES.md

@@ -10,6 +10,16 @@
 
 ## Registro de sesion
 
+### 2026-09-25 - Agente RAG 3 - Cierre productivo de limpieza OCR
+**Agent:** Agente RAG 3 · **Model:** openai/gpt-5.6-sol · **Session:** `ses_f358ccfe9ffeEzEVNuKo93aHyH`
+**Role:** Desarrollo, mantenimiento y continuidad del servicio RAG y su integracion con el servicio OCR reutilizable.
+**Work:** En VPS2 PRODUCCION se verifico el despliegue conjunto `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. Se rechazo la candidata sintetica blank usando su hash vigente y se purgaron secuencialmente las dos candidatas sinteticas y FacturaTech v3-v8; FacturaTech v2 ya estaba purgada. No se aprobo, indexo ni activo ninguna candidata.
+**Validation:** RAG confirma PostgreSQL, Qdrant y reconciliador sanos; OCR esta ready, con worker/sweeper operativos y cola vacia. Las etiquetas OCI de ambos contenedores coinciden con la revision. Las ocho purgas devolvieron `200`, todas las versiones descartadas quedaron `purged`, sus ocho directorios duraderos no existen y PostgreSQL no conserva estados `review_required`, `purging`, `ocr_queued`, `ocr_running` ni `indexing`. FacturaTech v1 `3fc78163-9cfb-4979-985c-1520a63327b0` sigue activa con `36/36` puntos.
+**Next:** Mantener como paquete posterior no bloqueante la recuperacion automatica de la ventana post-borrado/pre-CAS y la alineacion del contrato historico de retencion. Decidir por separado si una nueva ingesta del PDF original aporta valor.
+**Files:** `docs/OPERATIVA.md`, `docs/PENDIENTES_RAG.md`, `docs/SISTEMA_RAG_BASE.md`, `docs/CONTEXTO_PROYECTO.md`, `docs/HISTORIAL_SESIONES.md`.
+
+---
+
 ### 2026-09-25 - Agente RAG 3 - Publicacion de correccion de limpieza OCR
 **Agent:** Agente RAG 3 · **Model:** openai/gpt-5.6-sol · **Session:** `ses_f358ccfe9ffeEzEVNuKo93aHyH`
 **Role:** Desarrollo, mantenimiento y continuidad del servicio RAG y su integracion con el servicio OCR reutilizable.

docs/OPERATIVA.md

@@ -1,8 +1,8 @@
 # Operativa del servicio RAG
 
 **Modulo:** RAG
-**Ultima actualizacion:** 2026-09-24
+**Ultima actualizacion:** 2026-09-25
-**Version:** 1.7
+**Version:** 1.8
 
 ---
 
@@ -12,9 +12,9 @@ Este documento registra los hechos operativos del servicio RAG: la configuracion
 
 - Preflight R5 de solo lectura (2026-09-23): el contenedor RAG usa la base `db_rag` con el rol `usr_rag`. `rag_schema_migrations` contiene `001_knowledge_lifecycle.sql`, `002_ocr_review.sql` y `003_ocr_recovery_audit.sql`, todos con checksums coincidentes con el commit publicado; la unica migracion pendiente es `004_ocr_quality_diagnostics.sql`.
 - Despliegue R5 verificado (2026-09-23): RAG y OCR exponen `version=0.2.1` y `revision=0654ce5`; sus etiquetas OCI coinciden. Digests: RAG `sha256:9a22730406c09c6b773891d8953f451e6263bf9fb0033188f4479f0b93ec8bbf`, OCR `sha256:6725991d3893a4f16ae6c75f28e9dd59b051bdbc344b28d79f1292224ddceda1`. `004_ocr_quality_diagnostics.sql` esta aplicada; OCR esta `live/ready`, con cola vacia, worker/sweeper operativos y almacenamiento disponible; RAG confirma PostgreSQL, Qdrant y reconciliador sanos.
-- Despliegue vigente verificado (2026-09-24): RAG y OCR exponen `version=0.2.1` y `revision=bfb2d48`; sus etiquetas OCI coinciden, las migraciones `001-004` conservan sus checksums y PostgreSQL, Qdrant, reconciliador, OCR, cola y almacenamiento estan sanos.
+- Despliegue vigente verificado (2026-09-25): RAG y OCR exponen `version=0.2.1` y `revision=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`; sus etiquetas OCI coinciden y PostgreSQL, Qdrant, reconciliador, OCR, cola y almacenamiento estan sanos.
 - Candidata R5 historica: FacturaTech v8 `f4fd1502-1d4d-454f-bbfb-4c3b6820ee97` completo 25/25 paginas OCR y su revision visual, pero el 2026-09-24 fue rechazada por decision del usuario sin aprobarse, indexarse ni activarse. La version activa `3fc78163-9cfb-4979-985c-1520a63327b0` sigue intacta.
-- Limpieza pendiente: la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed` permanece `review_required` y la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` permanece `purging`. Los dos defectos que bloqueaban rechazo y purga estan corregidos y validados localmente; no reintentar la limpieza productiva hasta que el usuario despliegue la correccion.
+- Limpieza completada (2026-09-25): la candidata sintetica blank fue rechazada y las dos candidatas sinteticas quedaron `purged`; FacturaTech v2-v8 tambien estan `purged`. No quedan versiones en `review_required`, `purging`, `ocr_queued`, `ocr_running` ni `indexing`. Los ocho directorios duraderos descartados fueron eliminados.
 - Diagnostico de precision (2026-09-24): los PNG productivos verificados de las paginas 8, 15 y 16 muestran los ceros correctos, mientras `ocr-result.json` ya contiene las tres confusiones `o/0` con confianza alta y la candidata las conserva sin cambios. Se descartan renderizado, reconstruccion y RAG como origen. El OCR queda aceptado para esta fase como servicio best-effort autonomo; la mejora de precision, la consola humana y un posible revisor visual por IA quedan diferidos. Esta aceptacion no aprueba ni activa v8.
 - `KNOWLEDGE_LIFECYCLE_ENFORCED=true`: el ciclo de vida del conocimiento esta activo; no queda pendiente ninguna activacion.
 - `OCR_INGEST_ENABLED=true`: la ingesta OCR esta habilitada en el RAG desplegado.
@@ -24,11 +24,11 @@ Este documento registra los hechos operativos del servicio RAG: la configuracion
 - Volumen transitorio del OCR en `/data/jobs`: cola SQLite y trabajos en curso.
 - La respuesta publica sin token de una ruta OCR protegida es `401`, lo que confirma que el proceso desplegado tiene OCR habilitado. Con OCR deshabilitado, la misma ruta responderia `404` antes de autenticar.
 - El estado mostrado en EasyPanel debe contrastarse con su entorno persistido y con el entorno del contenedor en ejecucion; anteriormente la UI mostro valores distintos por variables duplicadas y desfasadas.
-- `GET /health` del RAG confirma PostgreSQL, Qdrant y reconciliador sanos. OCR responde internamente `live=ok` y `ready=true`, con cola vacia, worker/sweeper operativos y version/revision `0.2.1`/`bfb2d48`.
+- `GET /health` del RAG confirma PostgreSQL, Qdrant y reconciliador sanos. OCR responde internamente `live=ok` y `ready=true`, con cola vacia, worker/sweeper operativos y version/revision `0.2.1`/`960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`.
 - La migracion `003_ocr_recovery_audit.sql` esta aplicada y su tabla de auditoria existe.
 - Las rutas autenticadas de revision y recuperacion devuelven errores estructurados y seguros para una candidata inexistente: `404`, `OCR_CANDIDATE_NOT_FOUND` y accion `verify_version_id`.
 - La candidata OCR heredada de FacturaTech v4 fue cerrada como `failed` el 2026-09-20 mediante recuperacion administrativa auditada tras confirmar `OCR_ARTIFACT_UNAVAILABLE`. No fue indexada ni activada; la fuente conserva su version activa y no tiene candidatas OCR bloqueantes.
-- Las imagenes en ejecucion tienen ambas etiquetas OCI `org.opencontainers.image.revision=bfb2d48`: EasyPanel recibe `BUILD_REVISION` durante el build. La identidad se verifica mediante las etiquetas y el health; los digests registrados de entregas anteriores son evidencia historica, no la identidad de la revision vigente.
+- Las imagenes en ejecucion tienen ambas etiquetas OCI `org.opencontainers.image.revision=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`: EasyPanel recibe `BUILD_REVISION` durante el build. La identidad se verifica mediante las etiquetas y el health; los digests registrados de entregas anteriores son evidencia historica, no la identidad de la revision vigente.
 
 ## Version de despliegue
 

docs/PENDIENTES_RAG.md

@@ -35,7 +35,7 @@ La prioridad actual es publicar y desplegar la correccion de rechazo/purga OCR,
 
 ### Fase 3. Hardening OCR y aceptacion de FacturaTech
 
-**Estado:** `0.2.1` revision `bfb2d48` desplegada y verificada conjuntamente en produccion. v8 completo la aceptacion no activa, pero fue rechazada por decision del usuario sin aprobarse, indexarse ni activarse; FacturaTech v1 sigue activa.
+**Estado:** `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` desplegada y verificada conjuntamente en produccion. Las candidatas descartadas quedaron purgadas y FacturaTech v1 sigue activa.
 
 La candidata v5 `5f2317c6-7a8a-4e08-a614-f8189602ebb8` completo 25/25 paginas OCR, pero fallo despues cuando RAG solicito 25 imagenes de revision en paralelo. El rerender concurrente provoco un `SIGSEGV` de PDFium/FreeType, salida `139` y reinicio del contenedor; no hubo OOM. La candidata quedo fallida y la version activa no cambio.
 
@@ -153,7 +153,7 @@ Validacion completada: suite Node `121/121`, suite OCR `26/26`, regresiones del
 
 - [x] Preparar una unidad versionada para el scheduler durable y la operacion autonoma, revisar el diff y registrar codigo, pruebas, contrato, operativa y rollback.
 - [x] Solicitar y recibir autorizacion para commit/push. El despliegue conserva una autorizacion explicita posterior y separada.
-- [x] Publicar y desplegar RAG/OCR juntos segun la regla operativa vigente, con OCR habilitado y version, revision y etiquetas coincidentes. La revision `bfb2d48` quedo desplegada el 2026-09-24.
+- [x] Publicar y desplegar RAG/OCR juntos segun la regla operativa vigente, con OCR habilitado y version, revision y etiquetas coincidentes. El scheduler se desplego en `bfb2d48` y la correccion final de limpieza en `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` el 2026-09-25.
 - [x] Verificar migraciones esperadas, health, scheduler rapido, reconciliador de cinco minutos, cola OCR, almacenamiento, PostgreSQL y Qdrant. La validacion productiva conjunta paso y la version activa permanecio intacta.
 
 ##### G. Validacion productiva sin activar contenido
@@ -170,19 +170,19 @@ Validacion completada: suite Node `121/121`, suite OCR `26/26`, regresiones del
 - [x] Corregir la purga de versiones OCR para eliminar de forma transaccional las filas hijas de `rag_review_corrections`, `rag_document_pages` y `rag_ocr_jobs` antes de `rag_version_documents`, respetando las claves foraneas y la reanudacion desde `purging`.
 - [x] Eliminar idempotentemente los artefactos duraderos de la version antes de completar `purging -> purged`, evitando directorios huerfanos marcados como `retention_deleted`.
 - [x] Anadir pruebas de regresion para ambos defectos y ejecutar la bateria local completa. Las regresiones finales `47/47`, Node `124/124`, OCR `26/26`, typecheck, build y builds Docker RAG/OCR pasan.
-- [ ] Publicar la correccion autorizada mediante commit/push y desplegar conjuntamente RAG/OCR con la nueva `BUILD_REVISION`.
+- [x] Publicar la correccion autorizada mediante commit/push y desplegar conjuntamente RAG/OCR con `BUILD_REVISION=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`.
-- [ ] Tras el despliegue por el usuario, rechazar y purgar la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed`, completar la purga de la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` y purgar FacturaTech v3-v8.
+- [x] Rechazar y purgar la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed`, completar la purga de la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` y purgar FacturaTech v3-v8.
-- [ ] Verificar al terminar que no quedan candidatas OCR de prueba utiles o bloqueadas y que FacturaTech v1 conserva el puntero activo.
+- [x] Verificar que no quedan candidatas OCR de prueba utiles o bloqueadas y que FacturaTech v1 conserva el puntero activo con `36/36` puntos. Los estados finales son 7 versiones activas y 9 purgadas; no hay estados intermedios.
 - [ ] Decidir por separado, solo si aporta valor, si se realiza una nueva ingesta del PDF original de FacturaTech con el sistema ya validado.
 
 **Paquete posterior no bloqueante:** implementar recuperacion automatica si la purga se interrumpe despues de eliminar artefactos y antes del CAS `purging -> purged`, y alinear el contrato historico de retencion con el comportamiento real. La operacion actual es recuperable repitiendo `DELETE`; este paquete no requiere ampliar ahora la bateria de pruebas ni bloquea la publicacion.
 
 ##### I. Criterio de servicio completamente operativo
 
-- [ ] Confirmar en produccion que el PDF controlado hibrido no envia las paginas nativas, envia solo las visuales y compone un documento unico sin duplicar texto dentro de una pagina.
+- [x] Confirmar en produccion que el PDF controlado hibrido no envia las paginas nativas, envia solo las visuales y compone un documento unico sin duplicar texto dentro de una pagina.
-- [ ] Confirmar que las limitaciones de precision conocidas quedan trazables, el scheduler corto funciona tras reinicio, los leases evitan dobles procesamientos y el reconciliador recupera fallos residuales.
+- [x] Confirmar que las limitaciones de precision conocidas quedan trazables, el scheduler corto funciona tras reinicio, los leases evitan dobles procesamientos y el reconciliador recupera fallos residuales.
-- [ ] Confirmar health, observabilidad, almacenamiento, cola, PostgreSQL, Qdrant, revision no activa y rollback documentado sin incidencias abiertas de severidad bloqueante.
+- [x] Confirmar health, observabilidad, almacenamiento, cola, PostgreSQL, Qdrant, revision no activa y rollback documentado sin incidencias abiertas de severidad bloqueante.
-- [ ] Declarar cerrado el trabajo tecnico solo cuando toda la evidencia anterior este registrada. Este cierre significa que el servicio RAG-OCR esta funcionando completamente y que las candidatas descartadas quedaron limpias; no implica una nueva ingesta de FacturaTech.
+- [x] Declarar cerrado el trabajo tecnico con la evidencia registrada. RAG-OCR funciona completamente y las candidatas descartadas quedaron limpias; esto no implica una nueva ingesta de FacturaTech.
 
 Las advertencias `LOW_P10_CONFIDENCE` de las paginas 2, 20 y 21 no son un defecto de comunicacion ni un bloqueo pendiente de codigo. Son senales de revision. Las confusiones puntuales `o/0` de las paginas 8, 15 y 16 son una limitacion aceptada del reconocimiento best-effort y, si aparece una futura candidata, deben corregirse explicitamente durante su revision, nunca mediante una autocorreccion silenciosa. Una futura consola podra incorporar revision humana y un revisor visual por IA podra proponer correcciones con imagen y contexto; ambos quedan fuera de esta fase.
 
@@ -196,7 +196,7 @@ Si aparece un fallo real cuyos sintomas justifiquen aislar servicios, valorar en
 
 El SDD `ocr-ingest-integration` se archiva con 29/30 tareas completas y 7.4 incompleta. La continuidad del hardening y de la aceptacion se controla mediante el contrato ODD canónico, sin declarar retrospectivamente superada la aceptacion fallida.
 
-**Salida anterior:** `0.2.1` supero los criterios del anexo y FacturaTech alcanzo `review_required` con evidencia completa. v8 fue rechazada posteriormente por decision del usuario; el bloque A-I solo se cierra al desplegar la correccion de limpieza, purgar las candidatas descartadas y verificar que v1 sigue activa.
+**Salida actual:** `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` supero el cierre A-I. Las candidatas descartadas estan purgadas, no quedan estados bloqueantes y FacturaTech v1 sigue activa con `36/36` puntos. Una nueva ingesta del PDF original sigue siendo una decision opcional separada.
 
 ## 1. Documentacion y descubrimiento de la API
 

docs/SISTEMA_RAG_BASE.md

@@ -2,9 +2,9 @@
 
 **Proyecto:** Workspace de tools IA para empresas  
 **Modulo:** RAG  
-**Ultima actualizacion:** 2026-09-24
+**Ultima actualizacion:** 2026-09-25
 **Ultima modificacion por:** Agente RAG 3
-**Estado:** RAG y OCR `0.2.1` revision `bfb2d48` desplegados; v8 rechazada y correccion de limpieza OCR validada localmente pendiente de despliegue
+**Estado:** RAG y OCR `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` desplegados y verificados; candidatas descartadas purgadas y FacturaTech v1 activa
 
 ---
 
@@ -281,7 +281,7 @@ La revision puede proponer correcciones exactas por linea. Aprobarla genera un a
 
 ### Comportamiento desplegado
 
-Este comportamiento esta publicado y desplegado en la revision `bfb2d48`.
+Este comportamiento se publico en `bfb2d48` y permanece desplegado en la revision vigente `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`.
 
 Al aceptar una ingesta OCR, RAG intenta despacharla inmediatamente. Si OCR sigue en `queued` o `running`, el dispatcher guarda `next_attempt_at` con un backoff entre 2 y 15 segundos.
 
@@ -340,12 +340,12 @@ En documentos hibridos, `imageUrl` es `null` para paginas nativas y solo referen
 
 ## Estado productivo verificado
 
-- RAG y OCR `0.2.1` estan desplegados desde la revision `bfb2d48`.
+- RAG y OCR `0.2.1` estan desplegados desde la revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`.
 - PostgreSQL, Qdrant, OCR y reconciliador estan sanos.
 - FacturaTech v8 completo OCR y revision, pero fue rechazada sin aprobar, indexar ni activar; v1 sigue activa.
 - Una prueba productiva sintetica demostro el flujo hibrido: pagina 1 nativa, pagina 2 OCR y `review_required` en menos de 18 segundos, sin activacion y con cola final vacia.
-- La limpieza de versiones OCR descubrio dos defectos en la decision de paginas blank y el orden de purga. Ambos estan corregidos y validados localmente.
+- La limpieza de versiones OCR descubrio dos defectos en la decision de paginas blank y el orden de purga. Ambos estan corregidos y verificados en produccion.
-- Produccion conserva una candidata sintetica en `review_required` y otra en `purging`; no se reintenta su limpieza hasta desplegar la correccion.
+- Las dos candidatas sinteticas y FacturaTech v2-v8 estan `purged`; sus directorios duraderos descartados fueron eliminados. No quedan estados bloqueantes y v1 conserva `36/36` puntos.
 
 ## Fuentes de detalle