feat(episode): TRAZA_para-john-siguiente-fork_S20260618.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: chronicle
Summary: EPISODIO 4 — filesystem celular: 📍 PARA JOHN — siguiente fork

episodes/TRAZA_para-john-siguiente-fork_S20260618.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,40 @@
+---
+episode_id: "87ebb3ec-933c-4be7-8969-4ec769c77498"
+puente_flat: "TRAZA_para-john-siguiente-fork_S20260618.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260618.VERIFY_FIRST_PASSPORT_FIX"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "chronicle"
+summary_one_line: "EPISODIO 4 — filesystem celular: 📍 PARA JOHN — siguiente fork"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-18T13:44:16.060861+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**Fase 2 con dato real entregada.** Doc actualizado: [docs/estructura-empirica/RESULTADOS_PILOTO_H1_S20260618.md](docs/estructura-empirica/RESULTADOS_PILOTO_H1_S20260618.md). Resumen de lo que validamos hoy:
+
+| Gate | Antes | Ahora |
+|---|---|---|
+| Infra servidor MEMORIA + Qdrant | "no confirmado" (boot) | ✅ vivo, verde, embeddings OK |
+| H1 mecanismo (proxy keyword) | sin registrar | ✅ PASS |
+| **H1 embeddings reales (N=12)** | ⏳ Fase 2 | ✅ **precision@3=1.00 · p@1=0.83** con `gemini-embedding-2` |
+| H1 plena (N=60) | — | ⏳ único pendiente de H1 |
+
+El número clave: con **vectores reales** y queries **parafraseadas** (no match léxico) + distractores del mismo dominio, el eje PUENTE recupera el store correcto en el top-3 **6/6 veces**, y como #1 en 5/6. El proxy era `[soft_fact]`; esto es `[hard_fact]` a N=12.
+
+### 📍 PARA JOHN — siguiente fork
+**La historia:** veníamos de "validar antes de migrar". Hoy cerramos H1 por dos vías (mecanismo + embeddings reales) y H4 ya estaba. O sea, la hipótesis de *retrieval* (¿las 4 coordenadas recuperan bien?) está sólida. Lo que queda son **riesgos distintos**: ¿se puede migrar sin perder nada (H2)? ¿la profundidad degrada (H3)? ¿o escalar H1 a 60 carpetas?
+
+- **Consecuencias por camino:**
+  - 🟢 **A — H2/H3 (seguridad de migración):** rama aislada `migracion-celular` + reconstrucción ≥95% + límites de profundidad. Es el gate que de verdad falta antes de tocar el repo en serio.
+  - 🟡 **B — Escalar H1 a N=60 carpetas reales:** cierra el hard_fact completo de H1, pero su valor marginal es menor (ya sabemos que recupera).
+  - ⚪ **C — Empezar migración progresiva:** inyectar las 4 coords en frontmatter de carpetas nuevas (mecanismo + embeddings validados), bajo riesgo.
+- **Mi inclinación:** **A**. H1 (retrieval) ya está bien soportada; el riesgo real de migrar es la *reconstrucción* (H2) y la *profundidad* (H3), que son hipótesis sin tocar. Validar eso antes de migrar es la misma disciplina de toda la sesión. Lo que la cambiaría: que quieras producto visible ya → C.
+- **La pregunta esencial:** ¿atacamos los gates de seguridad de migración (H2/H3, mi inclinación), escalamos H1 a 60, o arrancamos la migración progresiva?
+
+(Pendientes independientes en la repisa: el one-liner de `.secrets.baseline.json` por tu mano + commit de lo acumulado cuando quieras.)