sergio/takana

Dos consecuencias de que la caja ya sea un hub:

1. **`dd` de la imagen ya no es actualizar: es perder.** Sobrescribe el disco local, donde ahora
   viven el clon, las dos claves, las credenciales del respaldo, `/srv/repo` y caddy. El store se
   salva sólo por estar en el volumen. Y peor: la imagen etiqueta su partición local como
   `hammer-store`, así que tras un `dd` habría DOS filesystems con esa etiqueta y el `findfs` del
   arranque elegiría cualquiera. El `dd` es para PROVISIONAR; actualizar es `takana upgrade`, que
   existe con generaciones y rollback y está sin probar acá.

2. **`takana hydrate` no puede proyectar al root vivo**: hidrata con hardlinks y en una caja
   instalada el store es SIEMPRE otra partición que `/` (`Cross-device link`). No es culpa del
   volumen — en el layout original `/store` es sda4 y `/` es sda2. Hidratar al FHS vivo nunca fue
   posible en una caja instalada; funciona en el hub porque ahí store y destino comparten filesystem.

El `git` arreglado se instaló copiando el artefacto a mano: funciona, y no es el camino.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index d97e225b..97f282d3 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -869,6 +869,34 @@ Con las dos: `git clone --depth 1` del propio repo desde la caja ⇒ **877 recet
 **La lección**: `ls-remote` andaba, así que el fallo parecía de red. Lo que lo destapó fue leer el
 informe COMPLETO en vez de la última línea — la primera decía exactamente qué y dónde.
 
+### 6.12 ⚠ La caja dejó de ser desechable — y `hydrate` no cruza el store
+
+Dos consecuencias de que la caja ya sea un hub, y las dos cambian el procedimiento:
+
+**1. Re-escribir la imagen con `dd` ya NO es una actualización, es una pérdida.** El `dd` sobrescribe
+el disco local, y ahí viven ahora `/opt/takana` (el clon), `/root/.ssh` (las dos claves),
+`/root/.config/hammer` (las credenciales del respaldo), `/srv/repo` y la configuración de caddy. El
+store se salva sólo porque está en el volumen. **Y hay una trampa peor**: la imagen etiqueta su
+partición local como `hammer-store`, así que tras un `dd` habría **dos filesystems con esa etiqueta**
+y el `findfs` del arranque elegiría cualquiera — con suerte el volumen, con mala suerte una partición
+vacía. ⇒ el `dd` es para PROVISIONAR; actualizar es `takana upgrade` (que existe, con generaciones y
+rollback) y está sin probar en esta caja.
+
+**2. `takana hydrate` no puede proyectar al root vivo.** Hidratar enlaza en DURO, y en una caja
+instalada el store es **siempre** otra partición que `/`:
+
+```
+Error: store: hardlink /store/51aa5e13…-git/.hammer/recipe.toml → /.hammer/…: Cross-device link
+```
+
+No es culpa del volumen: en el layout original `/store` es `sda4` y `/` es `sda2`, también distintos.
+**Hidratar al FHS vivo nunca fue posible en una caja instalada** — funciona en el hub porque ahí
+store y destino están en el mismo filesystem. Es la misma familia de EXDEV que ya mordió dos veces
+(§6.6), ahora a nivel de sistema y no de herramienta.
+
+Para instalar el `git` arreglado se copió el artefacto a mano. Eso **funciona y no es el camino**: el
+camino es `takana upgrade`, y probarlo es su propia unidad de trabajo.
+
 ### 6.2 Lo que la mudanza tiene que producir, además de la mudanza
 
 El usuario lo pidió explícito: **que este experimento saque recetas y las pruebe**. La caja vieja es