feat(episode): TRAZA_prlogo-d4-la-nica-decisin-urgente-go-a_S20260612.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: AEGIS | Type: troubleshooting
Summary: EPISODIO 1 — PostgreSQL: 📖 Prólogo D4 — La única decisión urgente: GO a la repar
This commit is contained in:
Ember 2026-06-12 18:38:28 +00:00
parent 83437abb40
commit 5b5c3cb6e8

View file

@ -0,0 +1,31 @@
---
episode_id: "ac50db35-9a36-457b-bb1a-663f77de9aff"
puente_flat: "TRAZA_prlogo-d4-la-nica-decisin-urgente-go-a_S20260612.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260612.FORMATEO_CANONICO_MNEMO"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "AEGIS"
fase_proyecto: "operations"
tipo_semantico: "troubleshooting"
summary_one_line: "EPISODIO 1 — PostgreSQL: 📖 Prólogo D4 — La única decisión urgente: GO a la reparación"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-12T18:38:26.336751+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Tienes razón en pedir el prólogo completo en el chat para la decisión que realmente urge — la presento sola, como manda PRO-4 (una decisión a la vez); D1-D3 pueden esperar y tienen su prólogo en [DECISION §5](docs/DECISION_S20260612_diagnostico_integral_ecosistema.md).
## 📖 Prólogo D4 — La única decisión urgente: GO a la reparación de backups del servidor MEMORIA
**Reframe (qué se decide realmente):** no estás decidiendo "un fix de script" — estás decidiendo si el activo más valioso del ecosistema (la memoria viva: 7 collections Qdrant + PostgreSQL canónico con 31 tablas) sigue o no **una noche más sin ninguna copia de seguridad real**.
**Historia (cómo llegamos aquí):** el backup diario corre todos los días a las 10:00 UTC y reporta "completado"… pero desde al menos el 4 de junio captura **0 de 7** collections (el script llama a Qdrant sin el header `api-key` que Qdrant ahora exige) y el dump del PostgreSQL canónico sale **vacío — 20 bytes** (el script usa credenciales `ember:ember` cuando el contenedor real usa `plex/mnemo_plex`). El mecanismo secundario (restic, 03:00) está muerto: su repositorio no existe y sus errores se pierden por una redirección invertida. El sync offsite a LUMEN funciona — y replica fielmente backups vacíos: **falsa sensación de redundancia 3-2-1**. Ninguna alerta lo detectó en 8 días porque el verificador del propio script degrada los fallos a warnings que nadie lee. Seis lentes del CONCILIO convergieron en esto como prioridad #1 (PROBATOR R1 lo movió por encima de todo lo SOTA).
**Consecuencias por camino:** · **GO hoy** → ~1h de trabajo bajo protocolo SSH safety (leer → backup `.bak` del script → 4 ediciones quirúrgicas → corrida manual → verificar `Qdrant: 7/7` + dump >1MB → restore drill en contenedor efímero). Riesgo bajo: solo toca el script de backup, reversible con el `.bak`. · **Esperar** → cada día adicional la ventana de pérdida total crece; un fallo de disco/contenedor hoy significaría perder los episodios regrabados post-FORMATEO que no existen en ningún otro lugar. · **Camino intermedio** (si prefieres mirarlo tú primero) → te dejo el diff propuesto en un doc y tú lo aplicas — añade horas de exposición pero maximiza tu control.
**Inclinación razonada:** **GO hoy**, con restore drill como verificador (no me creo el "completado" del log — esa es exactamente la mentira que nos trajo aquí). Lo que me haría cambiar de opinión: si tienes cambios en curso en el servidor que yo no veo, o si prefieres presenciar la primera corrida.
**Pregunta esencial (lo único que solo tú pones):** ¿me das GO para editar `ember-backup-5am.sh` en el servidor MEMORIA ahora, con backup previo del script y restore drill como prueba de cierre?