ember-memory-test/episodes/TRAZA_el-git-mv-que-prepar-se-lo-llev_S20260807.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
0a7af929-29df-42f1-b568-2ac8bc890e92	TRAZA_el-git-mv-que-prepar-se-lo-llev_S20260807.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260807.COTEJO_ARCHIVOS_SERVIDOR	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 4 — HANDOFF_PROMPT.md: El `git mv` que preparé **se lo llevó...	claude_code	internal	2026-08-11T03:47:27.400185+00:00	false	pending

El git mv que preparé se lo llevó otra instancia en su commit 08b07831, con un git add amplio sobre el índice compartido. El movimiento quedó correcto, pero con un mensaje que no explica nada; por eso la justificación va en mis commits 2348cdcb y 997d34a8. Es el reverso exacto del riesgo que evité ayer cuando yo estuve a punto de barrer su trabajo: el índice de git es estado compartido y ninguno de los dos lo trata como tal.

Y un detalle que ilustra bien la lección de medir con contexto: el grep de importadores devolvía tres coincidencias de import memory_sync. Ninguna era código — eran líneas de telemetría que registraban búsquedas anteriores. Contarlas habría dado un falso positivo.

Todo en los tres remotos (997d34a8) y confirmado dentro de MEMORIA.

—

Hice: retiré memory_sync.py a legacy/ con su README y sus 5 tests, tras confirmar por la wiki y la doctrina que implementaba un borrador nunca aprobado. Marcadores de obsolescencia en el servidor sin borrar nada. Tests: 9 + 5 verdes.

Falta: el borrado real de las copias viejas del servidor (espera tu GO), y las dos decisiones que dejamos abiertas antes.

Mi consejo: deja las copias del servidor donde están un tiempo. El marcador ya evita el daño —que alguien las lea como verdad— y borrar no aporta nada urgente. Lo que sí conviene cerrar es lo del móvil: sigue siendo el único punto donde una decisión puede salir mal hoy.

Para avanzar, elige:

• 🟢 A (recomendado) — Cerramos sesión: actualizo STATE.md, HANDOFF_PROMPT.md y dejo la posta lista con los pendientes ordenados.
• 🟡 B — Sigo con el hueco de los generadores en server-sync (la decisión A/B/C que quedó abierta).
• ⚪ C — Borro ya las copias obsoletas del servidor (shared_memory/ y data/docs/), previa lista de lo que desaparece.