ember-memory-test/episodes/DEPURA_hola-john_S20260801.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
Ember ee0eb24ab5 update(episode): DEPURA_hola-john_S20260801.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD
Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 1 — MEMORIA: Hola John 👋
2026-08-02 03:16:56 +00:00

3.4 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
44ca1ba6-09bc-45ff-a82f-f6210d8c70ac DEPURA_hola-john_S20260801.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD S20260801.PIPELINE_FIXES informar multi_actor low TESSERA operations troubleshooting EPISODIO 1 — MEMORIA: Hola John 👋 claude_code internal 2026-08-02T03:16:19.449255+00:00 false pending

Hola John 👋

Arranqué la sesión S20260801.PIPELINE_FIXES en zona 🟢 GREEN (~868K tokens disponibles). Tu mensaje llegó como una sola letra ("e") — asumo que fue un roce de teclado, así que no ejecuto nada todavía.

Lo que el boot dejó sobre la mesa, por si quieres arrancar por ahí:

  • 5 gates vencidos de 11 en GATES_REEVALUACION.md esperan decisión documentada.
  • PUENTE_VEREDICTOS sin contacto SSH con el servidor MEMORIA (timeout) — los plazos no se están midiendo; último estado conocido hace 13h: 2 veredictos en GATE_EN_FALLA.
  • 3 episodios en cola local LOOP_WRITE (recordatorio: dedup-first, nunca push a ciegas).
  • TASK_BOARD.md tiene 23h y nadie tiene tareas reclamadas.
  • COLA_JOHN: 5 ítems abiertos, el más antiguo lleva 28 días.

¿Qué hacemos? Si era otra cosa lo que ibas a escribir, mándala completa y arranco.

Chip ejecutado completo: el boot ya no puede ser engañado por un cambio de espacio de embedding

El sensor que pediste está vivo, probado y respaldado. La próxima vez que el espacio del embedding cambie (como pasó el 19-21 de julio sin que nadie lo viera durante 13 días), el arranque lo dirá en rojo ese mismo día. ## Qué quedó construido

La sonda (pipeline_health.py, extensión aditiva junto a su hermana check_model_drift): re-embebe 3 canarios fijos dentro del container ember-mcp (el mismo patrón docker exec que usa el gate de retrieval) y exige que cada uno reproduzca su vector almacenado. Coseno ≥0.99 = espacio sano · zona gris [0.95, 0.99) = vigilar · <0.95 = alerta roja · sin datos = unknown, jamás un falso "ok" (IV-2). Cache de 6 horas — máximo 4 sondas al día, costo despreciable. El boot gana una línea nueva: 🧬 Espacio embedding: … junto a la vieja de drift de nombre. Los canarios: 3 puntos post-22jul sembrados con cos=1.0000 verificado en vivo. Si apruebas el re-embedding de los 731 viejos, los canarios no se ven afectados. ## La verificación (evidencia cruda, no auto-reporte)

Prueba Resultado
Suite local (7 tests nuevos + 8 legacy de pipeline_health) 15 passed — nada roto
Sonda real end-to-end {"status":"ok","cos_min":1.0,"n":3}
Control positivo real (punto pre-19jul 0014f0c2) PROBE=0.85473{"status":"alert"}el sensor muerde ante el caso real medido
Deploy del probe al servidor sha256 idéntico local↔remoto; destino verificado NO_EXISTE antes (cero overwrite, el guard SSH-SAFETY lo confirmó a su manera)
Respaldo commit a0657f68 en origin + sriyantra + forgejo (rangos reales)

El control positivo es lo que separa este sensor de los 6 que mentían: no solo demostré que corre — demostré que alerta cuando debe, usando como oráculo los ~731 puntos del espacio viejo que existen hoy.