ember-memory-test/episodes/TRAZA_las-dos-vas-de-ingestin_S20260726.R2_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
cb26689b-330a-4105-87c2-570a0c0f93c2	TRAZA_las-dos-vas-de-ingestin_S20260726.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260726.ARCO_CICLO4_AUTOMEJORA	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 2 — MNEMO_PRE_DIGEST: Las dos vías de ingestión	claude_code	internal	2026-07-27T02:23:11.478148+00:00	false	pending

—

Hice — descarté que el aviso de LiteLLM fuera regresión mía; encontré que la unidad ember-outbox.service se contradecía a sí misma (su descripción prometía 4 stores, su comando ejecutaba 2 — parche de junio nunca revertido); la restauré a los 4 con respaldo, y verifiqué el drenaje con un episodio real proyectado hace menos de un minuto. La vía B está viva tras cinco semanas.

Falta — 🔴 el reindexado de los 152: ahora sí es viable y duradero (el worker genera embeddings ✓, el despachador lo despacha ✓, el upsert es idempotente ✓). Requiere crear 152 eventos nuevos, porque los suyos quedaron marcados completed. · 🟠 los 8 huérfanos con 10 reintentos agotados · 🟠 los 4 archivos restantes (OpenRouter + el manual).

Mi consejo — proceder con el reindexado ahora, que es la última pieza. Con las tres condiciones verificadas, es exactamente el P3 que el plan pedía: crear los eventos y dejar que la maquinaria canónica haga el trabajo, con el lockbox f63e5788… como registro de qué se tocó.

Para avanzar, elige:

• 🟢 A (recomendado) — ejecuto el reindexado de los 152 por la vía B recién reparada
• 🟡 B — primero dejamos correr el despachador unas horas y verificamos que los episodios nuevos fluyen solos
• ⚪ C — paramos aquí; la reparación está hecha y documentada

—