feat(episode): TRAZA_diagnstico_S20260523.R13_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 13 — PostgreSQL: Diagnóstico

episodes/TRAZA_diagnstico_S20260523.R13_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,61 @@
+---
+episode_id: "40c6633c-c2ff-4fcc-9ea3-c7cdffa82b1d"
+puente_flat: "TRAZA_diagnstico_S20260523.R13_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 13 — PostgreSQL: Diagnóstico"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-05-23T22:37:59.017698+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**✅ DRAIN ACTIVO confirmado:**
+
+| Métrica | Antes (stuck) | **60s post-trigger** | Análisis |
+|---------|--------------:|--------------------:|----------|
+| PID activo | 1576017 stuck | **2741655 nuevo** | ✅ Reemplazo limpio |
+| ELAPSED | 3h19m | 4m15s | Fresh |
+| TIME CPU | 17s (en 3h19m) | **6s (en 4m15s)** | ✅ Tasa CPU ~23x mayor que stuck |
+| %CPU | 0.1% | **2.3%** | ✅ Procesando activo |
+| Inbox | 2593 | 2620 | +27 (ingress paralelo) |
+| BLC chain pos | (no visible) | **pos 8204→8218** | ✅ 14+ episodes ingresados al BLC chain en últimos minutos |
+| PostgreSQL episode | 884 | 884 | ⏳ Aún no commit (batch write al cierre del run) |
+
+## Diagnóstico
+
+Pipeline procesando legítimo. El BLC chain crece (pos 8204→8218 visible en log = 14 episodes con hash criptográfico en ~60s = **~14 episodes/min**). A esa tasa, **2620 archivos drainados en ~3 horas** (estimate).
+
+PostgreSQL aún en 884 porque el commit cross-store ocurre en batch al final del run o por umbral. El comportamiento es consistente con la evidencia time-series Día 4 (793 episodes commit @02:00 fueron batch único, no continuo).
+
+## Plan recomendado cierre Día 5
+
+1. **Dejar PID 2741655 correr autónomo** — está drainando naturalmente
+2. **Verificar a 15:00 UTC** (próximo cron hourly) que el lock release funcione al terminar (el nuevo proceso debería completar batch + exit limpio + liberar lock)
+3. **Si quieres, antes de cerrar Día 5** puedo:
+   - **(i)** Hacer un check final del drain en ~30 min para validar progreso sostenido
+   - **(ii)** Cerrar disciplina MD-7 ahora (STATE + HANDOFF Día 6 + commit BLINDADA-29 + B15 LEXICON cosecha del hallazgo FORENSE B-NEW13)
+   - **(iii)** Ambas (i+ii secuencial)
+
+## Lección capturada B-NEW13 para LEXICON cosecha
+
+**B-NEW13 — Atascamiento inbox por lock fcntl no-liberado:**
+- **Síntoma:** crisol_run.py PID stuck con `wchan=do_poll` + 0.1% CPU + lock `/tmp/crisol_run.lock` ocupado → cron hourly exit graceful por horas/días → inbox crece sin drain
+- **Causa raíz:** proceso completa batch pero queda esperando event que no llega (mismo síndrome B-NEW1 Día 2)
+- **Diagnóstico:** `ps -o time,pcpu PID` muestra CPU casi cero en horas elapsed + log `crisol_cron.log` con N×"otra instancia ya esta corriendo (lock ocupado). Exit graceful."
+- **Fix in-act:** `kill -TERM PID_stuck` → lock liberado kernel auto → manual `python3 crisol_run.py` background trigger drain
+- **Prevención:** considerar timeout máximo en crisol_run.py main loop (e.g. 30 min idle → SIGTERM autoexit), o watchdog systemd que detecta CPU near-zero + ELAPSED >1h → kill auto
+
+¿Cuál camino? **(i) check 30 min** / **(ii) cerrar MD-7 ahora** / **(iii) ambas** / **(iv) otra**
+
+## 📌 PILA-PENDIENTES (R8) — PP-9 COMPACT
+
+## 📁 BITÁCORA S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT.R8
+
+⛽ 🟢 GREEN ~850K | 📋 S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT.R8 | routing: drain confirmado activo + espera John