feat(episode): TRAZA_r7seccion5l1-3-opciones-de-accin_S20260523.R11_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 11 — PostgreSQL: [R7.seccion5.L1] 3 opciones de acción

episodes/TRAZA_r7seccion5l1-3-opciones-de-accin_S20260523.R11_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,59 @@
+---
+episode_id: "b4f3a1e1-2f99-4dd0-b3f8-4157c7de2e4c"
+puente_flat: "TRAZA_r7seccion5l1-3-opciones-de-accin_S20260523.R11_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 11 — PostgreSQL: [R7.seccion5.L1] 3 opciones de acción"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-05-23T15:55:46.520212+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**PID 1576017 está STUCK** con el lock `/tmp/crisol_run.lock`:
+- ELAPSED 03:19:39 (3h 19min)
+- TIME CPU solo 17 segundos en 3h (0.1% CPU)
+- WCHAN `do_poll` STAT S — esperando event que no llega
+- Procesó batch 91 episodes Día 5 12:00 + se quedó en limbo
+- **Mismo síndrome B-NEW1 Día 2** (PID 1319274 stuck 12h44m, resuelto con SIGTERM)
+- **Mismo síndrome falso alarma B-NEW7 Día 3** (PID 2220038 que ese día sí era legítimo waiting)
+- Esta vez **NO es legítimo** porque hay 2540 archivos esperando + cron bloqueado
+
+## [R7.seccion5.L1] 3 opciones de acción
+
+**(a) SIGTERM PID 1576017 + verify lock liberado** (recomendación):
+- Mata proceso stuck + libera `/tmp/crisol_run.lock`
+- Próximo cron hourly (15:00 UTC) lanzará proceso nuevo + drainará ~2540 archivos
+- Riesgo: si procesaba algo crítico in-flight, podría perder ese estado (pero 17s CPU en 3h19m sugiere NO está procesando nada activo)
+- Token cost: ~5K
+
+**(b) Esperar próximo batch automático overnight 02:00 AM**:
+- Tu hipótesis original — si el lock se libera espontáneamente (timeout, GC, restart), batch procesará
+- Riesgo: lock fcntl advisory típicamente NO se libera hasta que proceso muera
+- Inbox seguirá creciendo +50-100/h hasta 02:00 AM (16h restantes) → posible saturación disco eventually
+
+**(c) Investigar más profundo cuál event espera PID 1576017**:
+- Strace -p PID + lsof para identificar qué bloquea
+- Read crisol_run.py código para entender main loop
+- Token cost: ~15-20K
+- Beneficio: entender bug raíz para fix permanente (no solo síntoma)
+
+**Mi recomendación: (a)** — equivalente exitoso B-NEW1 Día 2. Después de SIGTERM, el cron hourly hará drain. Si quieres entender el root cause underlying ANTES de matar, vamos (c) primero.
+
+## [R7.seccion6.Q1] Pregunta John
+
+¿Cuál camino? **(a) kill stuck PID + verify** / **(b) esperar overnight** / **(c) investigar más profundo antes de matar** / **(d) otra**
+
+**Nota sobre tu hipótesis "no cerrar turno sin subir":** sigue siendo PRÁCTICA BUENA aunque NO técnicamente necesaria. El push_to_server local SÍ debería ejecutarse al cierre Ember-CC-Local (Stop hook lo hace). El problema REAL es que el server-side procesamiento se traba por lock stuck, no porque falten archivos en inbox.
+
+## 📌 PILA-PENDIENTES (R7) — PP-9 COMPACT
+
+## 📁 BITÁCORA S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT.R7
+
+⛽ 🟢 GREEN ~865K | 📋 S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT.R7 | routing: FORENSE atascamiento inbox + espera John