sergio/takana

El texto de esta mañana afirmaba que «otro agente movió la rama», y daba como prueba que los commits
que trajo el `pull` cuelgan del commit ANTERIOR al mío. Eso no es prueba de nada: es lo normal
cuando el otro lado empujó desde una máquina que había hecho `fetch` antes — en este caso la laptop,
cuyos tres commits llevan su huso (-04:00) y no pasaron por acá.

Lo MEDIDO es el reflog (entre `start` y `finish` no hay un solo `pick`) y que los diez ficheros
desaparecieron también del ÁRBOL, cosa que un `reset --hard`/`checkout` concurrente sí explicaría.
Queda escrito como hipótesis, que es lo que es.

La receta práctica no cambia y es lo que vale: mirar `git log --oneline -1` después de cada
`pull --rebase`, y si el commit propio no está, `git reflog` + `cherry-pick`.

De paso, descartado el sospechoso obvio: `cosecha-cron.sh` NO hace pull ni reset — commitea acotado
por pathspec y si el push falla sólo lo anota.

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

diff --git a/CLAUDE.md b/CLAUDE.md
index 132f4ee0..6b675cca 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -131,11 +131,16 @@ El reflog lo explica y es lo único que lo explica:
 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.
+**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
+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
+mío: eso es lo normal cuando el otro lado empujó desde una máquina que había hecho `fetch` antes, y
+no dice nada de lo que pasó acá. **Que el árbol perdiera los ficheros es el dato fuerte; el resto,
+hipótesis.**
 
 **Qué hacer:**