feat(episode): DEPURA_causa-raz-b-1-en-una-frase_S20260605.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 5 — HANDOFF_PROMPT.md: Causa raíz B-1 — en una frase

episodes/DEPURA_causa-raz-b-1-en-una-frase_S20260605.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,51 @@
+---
+episode_id: "c1050a6f-5df1-4823-9c94-51d16e784575"
+puente_flat: "DEPURA_causa-raz-b-1-en-una-frase_S20260605.R5_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: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 5 — HANDOFF_PROMPT.md: Causa raíz B-1 — en una frase"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-05T23:01:34.321465+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Es `batch_process_session` (lee un session file, fusiona, luego chunkea). **Es el único sitio donde `merge_short_turns` está cableado.** Diagnóstico cerrado.
+
+—
+
+## Causa raíz B-1 — en una frase
+
+> **El camino vivo de ingesta (`stop-enricher` → `process_turn_to_memory` por turno individual → cola → `push_to_server` 1:1) nunca pasa por `merge_short_turns` ni filtra mensajes de sistema — solo el reprocesado offline `batch_process_session` los fusiona. Así, cada turno <200 palabras y cada mensaje de boot (ej. `SessionStart`) se empuja como episodio individual y F0 lo mata por CHK-05.**
+
+Eso explica TODO el patrón observado, sin contradicciones:
+- El run **per-turn con prosa real larga** → 50/50 PASS (el chunker moderno sí defiende cuando hay párrafos que acumular).
+- Los **89 encolados** (`ember_ep_..._001..089`, incluyen un `SessionStart`) → 1:1 sin fusión → ~55% rechazados por <200w.
+- El cementerio de **10,378 rechazados** = acumulación histórica de este mismo bug de cableado.
+
+`merge_short_turns` **existe y funciona** — solo está desconectado del path que importa. No hay que escribir el algoritmo; hay que **enchufarlo** y añadir un filtro de no-episodios (boot/system).
+
+## El cuadro completo (bug board)
+
+| ID | Qué | Gravedad | Dónde | Estado |
+|----|-----|----------|-------|--------|
+| **B-1** | Episodios <200w rechazados (CHK-05) → pérdida de memoria activa | 🔴 alta | cliente: enqueue/push no fusiona ni filtra | **causa raíz localizada** |
+| **B-2** | Escritura cross-store desincronizada (PG +50 / Qdrant +1 / Neo4j +1) — hipótesis: PG no deduplica | 🟠 media | servidor F5 | inferencia, falta query directa |
+| **B-3** | Retrieval 1/50 score >0.60 — "arreglo" de mayo no se sostiene | 🟠 media | servidor/embedding | abierto |
+| **B-4** | Clasificador F2: 4/50 match | 🟡 baja | servidor | no bloquea |
+| Deuda | `rejected/` 119MB sin limpiar · cola 89 vs inbox 17 · `format_episode` muerto · `manual_ingest` legacy | 🟡 | mixto | conocido |
+
+## Fix mínimo propuesto para B-1 (ataca la causa, no el síntoma)
+
+1. **Enchufar `merge_short_turns`** en el path vivo — antes de que la cola se empuje 1:1 (en `push_to_server` al recolectar, o en el enqueue de stop-enricher). Reusa la función probada; no la reescribo.
+2. **Filtro de no-episodios:** descartar turnos de sistema/boot (`SessionStart`, paneles, salidas de hook) que nunca deberían ser memoria. Esto es una decisión de política que te corresponde bendecir — define qué NO es memoria.
+3. **Tests** (Hypothesis property-based: "ningún payload emitido tiene cuerpo <200w") + verificación empírica re-empujando los 89 y midiendo rechazos.
+4. **Rollback** listo: `git checkout HEAD -- .claude/hooks/lib/{push_to_server,tessera_pipeline}.py`.
+
+No toco el path todavía porque cambiar la ingesta viva es consecuente y el punto 2 es tu decisión. **¿Le doy luz verde al fix de B-1 con ese enfoque (enchufar merge + filtrar sistema), o prefieres que primero confirme B-2/B-3 con queries directas a los stores (necesito que me pases el passphrase del MCP, está locked)?**