ember-memory-test/episodes/TRAZA_paridad-exacta-en-los-tres-remotos-9dca_S20260907.R1_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
14102a19-fb36-4c89-a5f2-da63691d8a52	TRAZA_paridad-exacta-en-los-tres-remotos-9dca_S20260907.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260907.SID0E5240A2E6D1	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 1 — MEMORIA: Paridad exacta en los tres remotos ( 9dca4b4f...	claude_code	internal	2026-09-12T22:28:12.299234+00:00	false	pending

Paridad exacta en los tres remotos (9dca4b4f). El enjambre sigue trabajando en segundo plano y me avisará.

—

Retomé el plan por la guía que Fable dejó escrita y lo primero que hice fue re-medirlo todo, como esa misma guía ordena. El pre-vuelo salió limpio: ningún fichero se movió en cuatro días, 140 pruebas en verde, el portón abierto y el ledger sin evidencias rotas.

Cerré el pendiente más crítico del plan. El respaldo de las 16 colecciones está validado, y no por un log complaciente sino por cuatro vías:

Comprobación	Resultado
Corridas con VERIFY Qdrant: 16/16	4 (días 09-09, 09-10, 09-11, 09-12)
Control negativo (corridas del 05 al 08)	sin esa línea, como debía
Ficheros .snapshot en el directorio del día	16, con las dos colecciones que faltaban
Réplica a LUMEN	RSYNC 2/2 rc=0, 2,8 GB

Al validarlo aparecieron tres hallazgos que nadie tenía registrados:

• La rotación del respaldo falla en silencio. Emite 27 errores de permiso al borrar respaldos viejos y aun así el script declara BACKUP_STATUS: OK. Es el mismo defecto que se corrigió en la cobertura, sobrevivido en la limpieza. Crece medio giga al día contra 118 libres, así que el margen son meses, no días.
• La guía y la POSTA mandaban leer una ruta de log que no existe. Quien siguiera la instrucción al pie habría visto un resultado vacío, habría concluido que el respaldo no corrió y podría haber revertido un instrumento sano. Corregido en ambos documentos.
• El pipeline de ingesta sí está vivo, y esto refuta una hipótesis mía. Cuatro señales coincidían en que llevaba ocho días muerto. Era falso: hay dos caminos de ingesta y el servicio despachador vacía la bandeja antes de que el cron horario mire, por eso su log lleva días mudo mientras el trabajo se hace. La premisa que tenía congelada la aceptación de MF-T-15 ha caducado.

Lo dejé todo medido y con dueño. Los seis pendientes de John estaban solo en tablas que el detector de vencimientos no lee, así que eran huérfanos de hecho aunque tuvieran fecha escrita: ahora viven en la cola como una sola entrada con seis sub-gates. El rollback de la Fase 1 está íntegro, 47 ficheros entre repo y servidor.

Seis commits con paridad en los tres remotos.