feat(episode): DEPURA_listo-john-el-inbox-dejar-de-inflarse_S20260605.R29_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 29 — PostgreSQL: ✅ Listo, John — el inbox dejará de inflarse

episodes/DEPURA_listo-john-el-inbox-dejar-de-inflarse_S20260605.R29_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,44 @@
+---
+episode_id: "54898e1d-4d77-4b84-acfe-518375ca3c90"
+puente_flat: "DEPURA_listo-john-el-inbox-dejar-de-inflarse_S20260605.R29_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260605.AGENTES_READINESS_PIPELINE"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 29 — PostgreSQL: ✅ Listo, John — el inbox dejará de inflarse"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-06T03:25:33.527144+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**B-8 cerrado, commit `d7bf16f`, push 3/3 remotos.** Temp patches limpiados.
+
+—
+
+## ✅ Listo, John — el inbox dejará de inflarse
+
+Lo arreglé de raíz y **verificado en producción**. Te cuento qué pasó:
+
+**La causa raíz real** (que casi se me escapa): crisol movía los `.md` procesados a `procesados/` **solo al final del pipeline, después de F6** (Neo4j, ~30 min, la parte lenta). Cuando crisol se mataba por timeout antes de llegar ahí, **su rebanada procesada se quedaba en el inbox y se re-procesaba cada hora** → el inbox solo crecía. Como los archivos solo se leen al inicio (F1), no había razón para retenerlos hasta el final.
+
+**El fix:** mover los archivos a `procesados/` **justo después del INSERT a PostgreSQL** (la parte rápida = el aterrizaje real), antes de la parte lenta. Así, aunque F6 haga timeout, los archivos ya están a salvo y no se re-procesan.
+
+**Confianza honesta — casi meto un bug de pérdida de datos:** mi primer intento movía **TODOS** los archivos (894), pero crisol procesa solo una **rebanada de 50** por corrida. Mover los 894 tras procesar 50 = perder 844 (el mismo Bug#5 que perdió 184 episodios en el pasado). **FASE 5 lo atrapó antes de soltarlo** — reverti, investigué que cada episodio guarda su archivo origen, y corregí a mover solo la rebanada procesada. El protocolo de verificación de ramas funcionó exactamente para esto.
+
+**Prueba en producción (log real):**
+
+**inbox 931 → 881** (−50 exacto) · **procesados 17.283 → 17.333** (+50). Cero pérdida.
+
+**Qué esperar ahora:** el inbox **drenará su rebanada en cada corrida horaria** (incluso las que hagan timeout) en vez de acumularse. Trend hacia abajo, no arriba. No se vacía instantáneamente (son ~880 esperando), pero ahora baja sostenido.
+
+**Lo que queda (ninguno sangra):**
+- `rejected/` 119MB — housekeeping destructivo, tu OK.
+- Deltas cross-store — mild (edad+dedup, no pérdida).
+- B-4 classifier — calidad, no bloquea.
+
+El fix vive server-side en `crisol_run.py` (backup `.bak.B8v2.*`, rollback trivial). Documentado y auditable en [docs/VERIFICACION_PIPELINE_MNEMO_S20260605.md](docs/VERIFICACION_PIPELINE_MNEMO_S20260605.md) (`d7bf16f`).