84aff18a16
Skill: AEGIS | Type: troubleshooting
Summary: EPISODIO 102 — MNEMO_PRE_DIGEST: 🕐 **Estado del sprint re-calibración — modo esp
2.9 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 15d998a5-9f8e-4546-a401-28b2f30ded43 | DEPURA_estado-del-sprint-re-calibracin-modo-e_S20260702.R99_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260702.MADUREZ_ECOSISTEMA_CONCILIO | informar | multi_actor | low | AEGIS | operations | troubleshooting | EPISODIO 102 — MNEMO_PRE_DIGEST: 🕐 **Estado del sprint re-calibración — modo espera... | claude_code | internal | 2026-07-12T16:16:36.832824+00:00 | false | pending |
🕐 Estado del sprint re-calibración — modo espera vigilada, John:
- ✅ El oráculo multistore está CORRIENDO dentro de ember-mcp (lanzado detached antes de que venciera el TTL) — resultados a
/home/johnember/data/recalib_out.txt, persisten pase lo que pase. - ⛔ Canal SSH bloqueado (resets activos en el kex tras ~40 conexiones mías hoy — sospecho fail2ban/rate-limit, posiblemente del hardening de seguridad de tu otra instancia). El servidor está SANO (MCP HTTP respondía perfecto).
- ⏳ TTL del MCP venciendo (~2 min) y sin SSH no puedo renovar el unlock — el runbook de renovación es server-side.
- 👁️ Vigía armado: sonda SSH cada 4 min (suave a propósito) por hasta 1 hora; en cuanto el canal reviva me despierto solo, leo los resultados de la re-calibración, re-desbloqueo el MCP y te traigo la tabla V0-V7 con el veredicto.
Si el bloqueo es fail2ban típico (10-60 min), esto se resuelve solo. Si tu otra instancia de seguridad está a la mano, puede confirmar/levantar el ban antes (fail2ban-client status sshd en el servidor MEMORIA).
🏁 Sprint re-calibración CERRADO, John — con un veredicto que vale oro aunque no sea el que esperábamos.
📄 ENTREGA: addendum sec. 6 en docs/SPRINT_DEDUP_TWINS_S20260702.md — pusheado a los 3 remotos ✓.
El veredicto de la re-calibración
Corrí el banco completo de variantes (multistore_oracle.py, 3,338 queries — todas las HyDE del corpus final del día):
| Variante | recall@1 | recall@5 |
|---|---|---|
| V0 denso puro | 0.317 | 0.614 |
| V1 producción | 0.603 | 0.826 ← ÓPTIMA, confirmada |
| V2 (+PostgreSQL) | 0.603 | 0.826 (no suma) |
| V3-V7 (grafo, pesos varios) | 0.583-0.595 | 0.790-0.815 (resta) |
La hipótesis "re-calibrar dará el salto" queda REFUTADA con datos — y eso es un resultado bueno: tu configuración de producción está confirmada como la mejor posible del banco actual, incluso con el grafo enriquecido. En el oráculo duro, el día completo movió a V1 de 0.798→0.826 @5 (+2.8pp). El tramo restante hacia 0.85@1 ya no es tuerca que apretar — es fusión v2 (variantes nuevas: hyde-match directo, diversidad/MMR, re-ranking): un sprint de investigación para otra ventana.