feat(episode): 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
Skill: NONE | Type: troubleshooting Summary: EPISODIO 4 — HANDOFF_PROMPT.md: El `git mv` que preparé **se lo llevó...
This commit is contained in:
parent
8c951e70f8
commit
e120bd900e
1 changed files with 36 additions and 0 deletions
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
episode_id: "0a7af929-29df-42f1-b568-2ac8bc890e92"
|
||||
puente_flat: "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"
|
||||
session_code: "S20260807.COTEJO_ARCHIVOS_SERVIDOR"
|
||||
acto_dialogico: "informar"
|
||||
actor_flujo: "multi_actor"
|
||||
criticidad_aegis: "low"
|
||||
skill_dominante: "NONE"
|
||||
fase_proyecto: "operations"
|
||||
tipo_semantico: "troubleshooting"
|
||||
summary_one_line: "EPISODIO 4 — HANDOFF_PROMPT.md: El `git mv` que preparé **se lo llevó..."
|
||||
source_type: "claude_code"
|
||||
trust_boundary: "internal"
|
||||
created_at: "2026-08-11T03:47:27.400185+00:00"
|
||||
relectura_tagged: false
|
||||
forgejo_commit_sha: "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.
|
||||
Loading…
Reference in a new issue