ember-memory-test/episodes/TRAZA_b-anlisis-de-la-migracin-hardcodedenv_S20260616.R10_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
3ef78624-418c-41ca-abce-a3ee2f1b50ff	TRAZA_b-anlisis-de-la-migracin-hardcodedenv_S20260616.R10_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260616.LOOP_WRITE_BACKLOG_DISCARD	informar	multi_actor	low	NONE	operations	chronicle	EPISODIO 10 — PostgreSQL: B — análisis de la migración hardcoded→env	claude_code	internal	2026-06-17T21:21:02.684785+00:00	false	pending

✅ A completado: MEMORY.md actualizado (override LEY-ZERO con tu OK) + auto-sincronizado a cx43. Una instancia futura ya sabe que la rotación está hecha — no la repetirá.

B — análisis de la migración hardcoded→env

Investigué el patrón antes de tocar nada, y encontré algo que cambia el riesgo de B:

• Los scripts NO tienen POSTGRES_MNEMO_DSN en su runtime env (por eso run_from_inbox mantiene un fallback hardcoded y run_iter5/decay_cron lo hardcodean directo). El scripts/mnemo/.env tiene MNEMO_PG_DSN, no POSTGRES_MNEMO_DSN.
• decay_cron.py (el del cron vivo cada 6h) no carga un .env — corre con el env que le dé el cron.
• Patrones mixtos: unos via postgres-mnemo (scram, password funcional), otros via 127.0.0.1/localhost (trust, password decorativo).

Implicación: migrar bien no es un sed — requiere cablear una fuente de env en ~10 scripts + sus puntos de invocación (incl. el cron) + verificar cada uno para no romper decay_cron. Y la urgencia de seguridad ya está resuelta (password rotado); esto es higiene de deuda, no emergencia.

📍 PARA JOHN — R1

• Hice: A completo (MEMORY.md registra la rotación + el gotcha, synced a servidor). B: analizado a fondo el patrón de carga de DSN de los ~10 scripts.
• La historia de B: los scripts hardcodearon el password precisamente porque POSTGRES_MNEMO_DSN nunca estuvo en su env. Migrarlos exige primero darles esa fuente de env y luego quitar el hardcode — con verificación per-script para no tumbar el cron de decay_cron.
• Mi consejo: NO ejecutar el refactor de 10 scripts al final de esta sesión enorme (es justo donde se cuelan errores — hoy ya sorteé 2 gotchas en la rotación, y decay_cron es un cron vivo). La migración merece un sprint fresco con foco + verificación per-script. La seguridad ya está cubierta por la rotación; esto puede esperar sin riesgo.
• Para avanzar, elige:
  • 🟢 A (recomendado): cerramos esta sesión (fue extensa y muy productiva: Fase C retrieval resuelto + rotación CRÍTICA cerrada); dejo la migración como sprint dedicado con el plan ya en MEMORY.md.
  • 🟡 B: insistes y arranco la migración AHORA, con cuidado per-script (primero cableo el env, luego quito hardcode, verifico cada script — más lento pero seguro).
  • ⚪ C: hago solo el subset 100%-seguro ahora (los 2 scripts trust-host donde el password es decorativo), y el resto en sprint fresco.

📌 PILA-PENDIENTES (R1)

• 🟠 HIGH — migrar ~10 secretos hardcoded→env (sprint dedicado: cablear env-source + quitar hardcode + verificar per-script; cron decay_cron en juego)
• ⚪ LOW — redactar correo CORREO_S20260405_R3 (ya inofensivo)
• ✅ RESUELTAS — MEMORY.md registra rotación · rotación plex COMPLETA+verificada · Fase C retrieval (d3h1s1, H4 falsada)