sergio/takana

Medido hoy en este repo compartido: commit propio con 10 ficheros → push rechazado porque otro
agente empujó → `git pull --rebase` → el commit YA NO ESTÁ, ni en el log ni en el árbol (los diez
ficheros desaparecidos del disco).

El reflog lo explica: entre `pull --rebase (start)` y `(finish)` no hay ni un `pick`. El rebase no
encontró nada que reaplicar porque, para cuando corrió, el commit ya no colgaba de `main` — los tres
commits que trajo el pull tienen de padre al commit ANTERIOR al mío, o sea que otro agente movió la
rama hacia atrás. Con `-q`, el resultado se ve igual que un pull limpio.

La recuperación es `git reflog` + `git cherry-pick <sha>`: vuelve entero. Y la comprobación que
evita el susto es mirar `git log --oneline -1` después de cada `pull --rebase`.

De paso, el corolario del espejo: el push doble puede triunfar en un remoto y fallar en el otro
(gitea rechazó, GitHub aceptó), así que tras recuperar queda un sha huérfano en GitHub con el mismo
contenido. Se repara empujando SÓLO esa URL con `--force-with-lease=main:<huérfano>`, después de
comprobar con `git diff --stat` que no se pierde nada.

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

diff --git a/CLAUDE.md b/CLAUDE.md
index 8950af84..132f4ee0 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -115,6 +115,45 @@ sigue siendo cierto. Corolario: **un fichero que aparece `MM` y que vos no tocas
 ni con pathspec — se avisa.** Pasó con el `Cargo.lock` de tawasuyu (SDD 26 §7.quinquies), donde el
 árbol del otro agente ya traía la reparación que hacía falta.
 
+## 2 ter. `git pull --rebase` puede DESCARTAR tu commit sin decir nada
+
+⚠ **Medido acá el 2026-09-16, y cuesta una hora de trabajo si no sabés mirar el reflog.**
+
+Secuencia real: commit propio en `main` (10 ficheros nuevos) → `git push` → **gitea lo rechaza**
+porque otro agente empujó → `git pull --rebase` → el push vuelve a fallar y **el commit ya no está**,
+ni en el log ni en el ÁRBOL: los diez ficheros habían desaparecido del disco.
+
+El reflog lo explica y es lo único que lo explica:
+
+```
+11a9ead6 HEAD@{0}: pull --rebase (finish): returning to refs/heads/main
+11a9ead6 HEAD@{1}: pull --rebase (start): checkout 11a9ead6
+f3d7be6c HEAD@{2}: commit: los 9 daemons propios entran al catálogo…     ← el mío
+```
+
+**Entre `start` y `finish` no hay ni un `pick`**: el rebase no encontró NADA que reaplicar. Eso pasa
+cuando, en el momento del `pull`, el commit propio ya no colgaba de `main` — otro agente movió la
+rama (los tres commits que trajo el `pull` tienen de padre al commit ANTERIOR al mío, así que main
+había retrocedido). El `--rebase` no rompió nada: rebasó una rama de la que tu commit ya había sido
+sacado, y como `-q` calla, el resultado se ve igual que un pull limpio.
+
+**Qué hacer:**
+
+```sh
+git reflog -15                      # tu commit está acá, con su sha
+git cherry-pick <sha>               # vuelve entero, ficheros incluidos
+```
+
+Y la comprobación que evita el susto: **`git log --oneline -1` después de cada `pull --rebase`.** Si
+tu commit no es el primero, no se rebasó — se perdió de la rama, y el reflog lo tiene.
+
+⚠ **El espejo de GitHub queda DIVERGENTE en ese escenario**, y es normal: el `push` doble puede
+triunfar en un remoto y fallar en el otro (pasó: gitea rechazó, GitHub aceptó). Tras recuperar el
+commit, el espejo tiene un sha huérfano con el mismo contenido. Se repara empujando **sólo la URL de
+GitHub** con `--force-with-lease=main:<sha-huérfano>` — con lease, que verifica que el remoto sigue
+donde creés antes de pisarlo. Comprobar antes que el contenido no se pierde:
+`git diff --stat <huérfano> HEAD`.
+
 ## 3. Antes de dar un artefacto por presente, mirá que tenga contenido
 
 Un directorio **vacío** en el store no es un artefacto: es un nombre. `Store::has` ya lo rechaza y