ember-memory-test/episodes/TRAZA_ab-gate-pass-el-2-confirmado-en-produc_S20260618.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

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
b488be26-84ef-40c3-9296-d503a8b74b64	TRAZA_ab-gate-pass-el-2-confirmado-en-produc_S20260618.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260618.VERIFY_FIRST_PASSPORT_FIX	informar	multi_actor	low	FORJA	operations	troubleshooting	EPISODIO 1 — ember_experience: 🎯 A/B GATE: PASS — el 2× confirmado en producción (la condic	claude_code	internal	2026-06-19T05:43:52.964326+00:00	false	pending

🎯 A/B GATE: PASS — el 2× confirmado en producción (la condición dura de PROBATOR queda satisfecha)

Pero verify-first ANTES de pegar el wrapper en producción cazó un tercer gotcha (comparé el _serialize_point nuevo contra la función VIVA real): la ruta fusion=False NO es byte-idéntica en datos vivos.

Campo	Live search_memories (vieja)	_serialize_point (nueva)	Efecto en ember_experience
type	type→doc_type→category	type→doc_type→**memory_type**	"" → "operational" (¡cambia!)
date	date→created_at→**timestamp**	date→created_at→""	drop del fallback timestamp (edge)
semántica	.get(key, default) (key-present)	or (truthy)	difiere si valor "" presente

El test byte-identity pasó porque sus mocks tenían type truthy → no expuso la divergencia en datos reales. El kernel debe replicar la extracción vieja EXACTA para que el rollback (fusion=False) sea limpio. Esto se arregla en fusion.py:_serialize_point (10 líneas) + re-test + re-subir, ANTES del swap de server.py.

Por eso NO completé el swap de server.py este turno. Estado de producción: intacto (server.py sin tocar, backup .bak.pre_fusedv1_S20260619 creado; fusion.py subido pero INERTE — nada lo importa aún). Cero impacto. Rushear un edit de 54KB en producción al final de un turno de ~38 llamadas, con una divergencia byte-identity sin cerrar, sería imprudente.

📍 PARA JOHN — R57

• Hice (turno grande, alto valor): cerré los 6 bloqueadores de la remediación + re-verifiqué yo mismo (90/90 verde); corregí el test over-estricto (kernel fiel al oráculo) y la paridad del A/B script; corrí el A/B en vivo → PASS con 2.03× recall@1 (0.30→0.608), algoritmo desplegable, corpus real; preparé el deploy (backup + fusion.py subido); cacé una divergencia byte-identity en la ruta de rollback.
• Hallazgo de corpus (honesto): el eval "duro" con queries naturales (realistic_oracle.json) NO corre — su corpus mnemo_lab fue barrido del Qdrant. El A/B se hizo self-query (misma base que el 0.617). Re-ingestar mnemo_lab para el eval duro = tarea aparte.
• Falta: (1) fix _serialize_point byte-identity + re-test + re-subir; (2) swap server.py (import + función, fusion=False) + syntax-guard + restart + smoke; (3) [GATE tuyo] flip a fusion=True (justificado por el A/B 2×).
• Mi consejo: finalizo el deploy (pasos 1-2, todos seguros/reversibles) en el siguiente paso; cuando el smoke confirme, autorizas el flip a True. El A/B ya te dio la evidencia: V1 duplica el recall@1.

📌 PILA-PENDIENTES (R57)

• 🟠 HIGH · D-FUSED-001 (EN PROGRESO) — ✅ remediación+re-verify (90/90), ✅ A/B PASS 2.03×, ✅ deploy prep. ⏭ (a) fix _serialize_point byte-identity [type:category no memory_type; date:+timestamp; semántica .get(default)], (b) swap server.py, (c) smoke, (d) [GATE John] flip fusion=True.
• 🟡 MEDIUM · G-ABCORPUS-008 (NUEVO) — re-ingestar mnemo_lab (40 eps corpus_calibration_episodes.json) para el A/B duro con queries naturales. [diagnóstico R56: mnemo_lab ausente del Qdrant]
• 🟡 MEDIUM · G-C2-002 C2 watchdog · D-XB-004 X-b ledger.
• ⚪ LOW · G-WIKI-007 wiki FROZEN · G-DUR-005 durabilidad · G-PUSH-006 push triple-remoto (batch tras deploy) · G-COSECHA-009 (NUEVO) LEXICON cosecha pendiente (4 PRE_DIGEST hoy) [cierre].