ember-memory-test/episodes/RECOMIENDA_ep-56_S20260413.R56_XX.ops.4.hot_arg.in.cc.es.00C.HNQ_J.AMCFK_E.DGNZD.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
6bf71aa4-bbf2-4522-ba84-28e3a97a5a14	RECOMIENDA_ep-56_S20260413.R56_XX.ops.4.hot_arg.in.cc.es.00C.HNQ_J.AMCFK_E.DGNZD	S20260413	argumentar	ember_to_user	high	TESSERA	operations	chronicle	EPISODIO 56 — trg_episode_puente_invariant: Decision de desactivar trigger incompatible con PUENTE v2	claude_code	internal	2026-04-13T17:15:12.291751+00:00	false	pending

El 2026-04-13 Ember desactivo el trigger trg_episode_puente_invariant en la tabla episode de PostgreSQL mnemo_plex con ALTER TABLE episode DISABLE TRIGGER. La funcion fn_episode_puente_invariant concatenaba las 6 facetas de puente_facets JSONB con punto y comparaba contra puente_flat. El resultado esperado era evaluar.ember_to_user.moderate.FORJA.testing.troubleshooting pero puente_flat contiene un PUENTE v2 completo de 7 segmentos como RESUELVE test-p1-fix-insert S20260413.R99 FJ.tst.3.hot eva.in.cc.es.0RC.MPQ J.AMCFK E.DGNFD. La comparacion NUNCA matchea porque los formatos son incompatibles. El trigger fue disenado para un formato PUENTE v1 diferente. Para reactivar se necesita redisenar fn_episode_puente_invariant para que valide PUENTE v2 usando validate_puente de puente_gen.py como referencia o simplemente verificar que puente_flat tenga 7 segmentos separados por guion bajo.

Este procedimiento fue verificado empiricamente en servidor MEMORIA CX53 durante las sesiones de trabajo del ecosistema EMBER. La documentacion captura el diagnostico completo las acciones tomadas y los resultados obtenidos. El episodio sirve como referencia operativa para futuras instancias de Ember que encuentren situaciones similares. Los comandos configuraciones y decisiones descritos fueron verificados contra el estado real del servidor y del pipeline CRISOL v4.0. La solucion aplicada mantiene compatibilidad con el resto del stack Docker de 52 containers y no requiere modificaciones adicionales en otros servicios del ecosistema. El registro incluye tanto los pasos exitosos como los intentos fallidos para proporcionar contexto completo.