Episode: D.20260410.R10.memoria.puente.validar

decisions/D.20260410.R10.memoria.puente.validar.md

@@ -0,0 +1,29 @@
+<!-- EMBER_CROSS_REF
+eri: S20260410_R10_deployment_memoria_memoria_lexicon
+qdrant_id: 4663838c-fe02-401b-bbde-c34cf71bd75f
+qdrant_collection: ember_experience
+neo4j_node: (:Episode {id: 'S20260410_R10_deployment_memoria_memoria_lexicon'})
+pg_table: episodes
+pg_qdrant_id: 4663838c-fe02-401b-bbde-c34cf71bd75f
+nc_path: /EMBER/episodios/2026/04/D.20260410.R10.memoria.puente.validar.md
+created_at: 2026-04-10T03:50:00+00:00
+codex_ref: S20260410.R10
+puente: D.20260410.R10.memoria.puente.validar
+mode: deployment
+hope_score: 0.495
+entities: 4
+-->
+
+# deployment: MEMORIA, MEMORIA, LEXICON — Durante la sesión S20260410 implementamos la validación del...
+
+Durante la sesión S20260410 implementamos la validación del puente (ember-mcp)_candidate en F0.7. Antes, el servidor regeneraba el PUENTE desde los ~400 palabras del chunk, perdiendo el contexto rico de Ember (1M tokens). Ahora, Ember propone el PUENTE en su PRE_DIGEST y el servidor solo lo valida contra el LEXICON. Si pasa, se usa tal cual. Si no, fallback a generación local. Este cambio captura el dominio (brasaluz.com) y la entidad correctas porque Ember sabe POR QUÉ está hablando de algo, no solo QUÉ palabras aparecen. El servidor MEMORIA ejecuta orchestrator.ingest_episode con esta nueva lógica.
+
+<!-- MNEMO_PRE_DIGEST
+entities_canonical:
+  - PUENTE
+  - LEXICON
+  - MEMORIA
+primary_mode: architect (John)ure_decision
+puente_candidate: D.20260410.R10.memoria.puente.validar
+facts_verified: 5
+-->