ember-memory-test/episodes/TRAZA_el-hallazgo-central-la-cadena-causal-com_S20260711.R43_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
c5b6257e-63a2-41ac-9e22-65193e86c8e8	TRAZA_el-hallazgo-central-la-cadena-causal-com_S20260711.R43_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260711.SHERPA_BRIEFING_FABLE	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 43 — ember_experience: El hallazgo central (la cadena causal completa, con evidenci	claude_code	internal	2026-07-12T15:16:10.038260+00:00	false	pending

El hallazgo central (la cadena causal completa, con evidencia literal)

1. La regla MNEMO-HYDE (jun-13) exige ≥10 preguntas HyDE por episodio; el schema PostgreSQL v2 (spec 011) tiene un CHECK que acepta entre 3 y 5. Crisol envía hasta 10 → el constraint episode_hyde_queries_check rechaza todo INSERT nuevo. Lo vi literal en los logs de PostgreSQL: ERROR: new row violates check constraint "episode_hyde_queries_check". Dos contratos del mismo ecosistema, nunca reconciliados.
2. El fallo es invisible por tres capas de contabilidad falsa: crisol ejecuta el batch con psql ON_ERROR_STOP=off (retorna éxito aunque todos los statements fallen), cuenta pg_ok = tamaño del batch, imprime "PG +43", y pipeline_runs graba success con errors=[]. Es la misma clase de bug de contabilidad que arreglaron en el outbox el 18-jun, una capa más adentro.
3. Consecuencia 1 — deadlock de la cola: el sha-gate cliente verifica aterrizaje contra PG; como PG nunca recibe los sha nuevos, los 71 payloads se re-empujan en cada turno y crisol re-procesa 43-50 episodios por ciclo, para siempre.
4. Consecuencia 2 — contaminación: Qdrant y Neo4j (sin ese constraint) sí escriben; cada vez que el cuerpo generado evoluciona (p.ej. el strip de chrome aprendió patrones nuevos el 11-jul), el mismo episodio produce un sha distinto y entra como punto/nodo NUEVO. Sesión S20260705: 122 puntos en Qdrant vs 10 filas en PG. Esto ya degradó el retrieval medible: recall@1 cayó de 0.675 a 0.544 con el corpus casi duplicado.
5. Agravante: el upsert de F5 (ON CONFLICT (puente_flat) DO UPDATE) solo refresca metadata de clasificación, no content_sha256 ni el texto — así que aunque se destape el constraint, la convergencia del gate seguiría rota para re-pushes con cuerpo evolucionado. H-1 y H-5 se arreglan juntos.
6. Y el hueco del 8-11 jul: el transporte SCP estuvo fallando (Connection timed out, el gotcha de rate-limit SSH) 4 días sin que nadie lo notara — el watchdog C2 (SLO 2h) que se diseñó el 18-jun nunca se construyó, y el retrieval_gate está roto (timeout corto → FAIL espurio con nulls) y no está en ningún cron.

Calidad de las memorias y del retrieval