gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1389Shell 137Markdown 80Rust 802602 Definiciones

regla 2 ter: el comando NO es el culpable — probado en un repo de juguete

Pasó dos veces el mismo día, con el mismo reflog: commit propio, `(start): checkout <otro>`,
`(finish): returning to main`, y ni un `pick` en el medio.

Antes de escribir otra hipótesis, se probó: dos clones de juguete, el otro empuja, yo commiteo local,
`git pull --rebase -q origin main` ⇒ mi commit SE REAPLICA y mi fichero sigue. O sea que `pull
--rebase` hace lo suyo, y lo que falla es que este árbol lo comparten varios agentes y alguien mueve
`refs/heads/main` mientras el rebase está en vuelo.

La receta práctica no cambia (mirar `git log -1` después de cada pull; recuperar con reflog +
cherry-pick), pero el diagnóstico sí: evita ir a buscar el bug al lugar equivocado.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

61bf2cfd988b8de9e8cdfaa2773f79495a666e0b · por Sergio · (hace 1 mes) · padre cb9cf291b · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +10 −1

diff --git a/CLAUDE.md b/CLAUDE.md
index 6b675cca..ad9432fa 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -134,7 +134,16 @@ f3d7be6c HEAD@{2}: commit: los 9 daemons propios entran al catálogo…     ←
 **Entre `start` y `finish` no hay ni un `pick`**: el rebase no encontró NADA que reaplicar, y con
 `-q` eso se ve igual que un pull limpio.
 
-⚠ **La CAUSA no está determinada, y conviene decirlo así en vez de inventarla.** Lo medido es el
+⚠ **PASÓ DOS VECES EL MISMO DÍA** (2026-09-16 y 2026-09-17), con el mismo reflog: `commit` propio,
+`(start): checkout <otro>`, `(finish): returning to refs/heads/main` — y ni un `pick` en el medio.
+
+**Y el comando NO es el culpable: se reprodujo en un repo de juguete y ahí funciona bien.** Dos
+clones, el otro empuja, yo commiteo local, `git pull --rebase -q origin main` ⇒ **mi commit se
+reaplica y mi fichero sigue ahí**. O sea que lo que falla no es `pull --rebase`: es que este árbol
+lo comparten varios agentes y **alguien mueve `refs/heads/main` mientras el rebase está en vuelo**.
+La receta práctica no cambia; el diagnóstico sí, y evita ir a buscar el bug al lugar equivocado.
+
+⚠ **La CAUSA exacta no está determinada, y conviene decirlo así en vez de inventarla.** Lo medido es el
 reflog de arriba y que los diez ficheros desaparecieron también del ÁRBOL, que es lo que un
 `reset --hard` o un `checkout` concurrente de otro agente sí explicaría. Lo que NO es evidencia —y
 se escribió como si lo fuera— es que los commits que trajo el `pull` cuelguen del commit anterior al