ember-memory-test/episodes/TRAZA_qu-pas-en-una-frase_S20260618.R4_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
85443496-76ae-4134-be50-0f7fc4f28ef3	TRAZA_qu-pas-en-una-frase_S20260618.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260618.VERIFY_FIRST_PASSPORT_FIX	informar	multi_actor	low	FORJA	operations	troubleshooting	EPISODIO 4 — MNEMO Pipeline: Qué pasó, en una frase	claude_code	internal	2026-06-18T16:46:02.921592+00:00	false	pending

✅ Worker forgejo ARREGLADO y verificado — diagnóstico FORENSE + fix RELOJERO completos.

📄 Outputs del panel (D-DEBUG-L3): CONSEJO · DECISION — PROBATOR verdict PASSES.

Qué pasó, en una frase

El proceso outbox_dispatcher.py arrancó el Jun 12 19:24 con el password plex viejo en memoria; el password se rotó el Jun 16 y el .env del worker se actualizó con el nuevo, pero el proceso nunca se reinició → siguió usando el viejo → password authentication failed durante ~2 días.

FORENSE — cómo lo confirmé (no asumí)

Evidencia	Resultado
ps -o lstart del proceso	Fri Jun 12 19:24 (pre-rotación)
.env PG_DSN ¿autentica?	ENV_DSN_CONNECT: PASS (el .env ya tiene el password bueno)
dispatcher.log	973MB de retry-loop con authentication failed
Hipótesis SCIENTIA	H1 stale-process ✅ · H2/H3/H4 falsadas

RELOJERO — fix mínimo + verificación triple

Fix: outbox_service.sh restart (= systemctl --user restart ember-outbox). Cero cambio de código, cero edición de secreto, reversible.

Capa verificación	Resultado
A — proceso	nuevo PID 2192550, Running, unidad única
B — log post-restart	32 commits outbox.forgejo Committed → <hash> en 3 min · 0 auth-fail
C — backlog	episode_outbox pending 125 → partial 120 + processing 9 (drenando, ~10 min para completar los 125)

La réplica a Forgejo (y de paso neo4j + nextcloud, que compartían el mismo proceso) está viva y drenando el backlog de 19h.

Lección sistémica (para no repetirlo)

Un proceso long-running no recoge un secreto rotado hasta reiniciarse. Toda rotación de secreto debe incluir "restart de consumidores vivos" — este bug existió 2 días solo por esa omisión.

📍 PARA JOHN — R36

• Hice: FORENSE → root cause (proceso stale con password viejo, .env ya correcto) → RELOJERO fix (restart) → verificado (32 commits forgejo, 0 auth-fail, backlog drenando). CONSEJO + DECISION + PROBATOR PASSES entregados.
• Falta: Nada del fix. Residuales de higiene: rotar el dispatcher.log de 973MB; commitear los 3 docs nuevos a los remotos.
• Mi consejo: El worker está arreglado y la réplica drenando — puedes cerrar. Lo único que vale la pena rematar pronto es truncar/rotar el log de 973MB (riesgo de disco).
• Para avanzar, elige:
  • 🟢 A (recomendado) — Cerrar: forgejo arreglado y verificado.
  • 🟡 B — Rotar el dispatcher.log (973MB) + commitear los docs a los 3 remotos.
  • ⚪ C — Otra cosa (limpiar scripts capa2_*, drenar los 54 LOOP_WRITE, etc.).

📌 PILA-PENDIENTES (R36): 🟡 dispatcher.log 973MB rotar · 🟡 commitear 3 docs (CONSEJO/DECISION/VERIFICACION) · 🟡 54 LOOP_WRITE local · ✅ worker forgejo arreglado+verificado