ember-memory-test/episodes/TRAZA_entonces-qu-s-est-mal-aqu-no-la-asimetra_S20260618.R5_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
7b330c22-a0f8-4f64-9fd4-fffca5bc95d1	TRAZA_entonces-qu-s-est-mal-aqu-no-la-asimetra_S20260618.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260618.VERIFY_FIRST_PASSPORT_FIX	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 5 — MNEMO Pipeline: Entonces, ¿qué SÍ está mal aquí? (no la asimetría)	claude_code	internal	2026-06-18T21:55:49.090050+00:00	false	pending

1. El rate-limit mata el batch. Forgejo permite 1 push cada 5 s. crisol ingiere en lotes de hasta 50 episodios. Inline, eso son 50 × 5 s = 250 s de pushes git bloqueando cada corrida — el retrieval esperaría minutos por una réplica que nadie lee.
2. Un fallo remoto frenaría la ingesta. Si Forgejo o Nextcloud está caído (red, auth, disco), una escritura inline fallaría o colgaría toda la ingesta → el retrieval dejaría de acumular memoria por culpa de un respaldo. Justo lo que NO quieres.
3. El insight profundo: si quisieras hacerlo inline sin bloquear, tendrías que escribir Forgejo/Nextcloud "fire-and-forget" — pero entonces, si fallan, pierdes el episodio (no hay reintento). Para no perderlo necesitas persistir el pendiente + reintentar… que es exactamente lo que la tabla episode_outbox + el dispatcher YA hacen (entrega at-least-once con retry). O sea: "hacerlo igual inline" o bloquea el núcleo, o te obliga a reconstruir el outbox dentro de crisol. El patrón no es arbitrario — es la forma mínima correcta de hacer efectos-secundarios asíncronos confiables.

Entonces, ¿qué SÍ está mal aquí? (no la asimetría)

La asimetría es diseño correcto. Lo que está mal es otra cosa:

• 🔴 El dispatcher muere en silencio (sin alarma de liveness) → 6 días sin que nadie lo note. Ese es el defecto operativo real.
• 🟡 Doble-write redundante: el dispatcher también tiene workers de Qdrant+Neo4j (los 4), así que esos 2 se escriben dos veces (crisol inline + worker). Eso SÍ es deuda — el outbox original fanout-a-4, luego crisol ganó las 3 inline, y nadie quitó Qdrant+Neo4j del dispatcher. Probable fuente de los "gemelos" de Neo4j.

Implicación para tu decisión de antes: por esto la opción correcta es A (revivir + monitorear el dispatcher), no B (meter todo inline). Meter Forgejo+Nextcloud inline sería un paso atrás — reintroduce el acoplamiento que el patrón outbox existe justo para evitar. Lo único que vale revisar de B es podar el doble-write (que el dispatcher maneje SOLO Forgejo+Nextcloud, ya que Qdrant+Neo4j los cubre crisol).

—