sergio/takana

Lo destapó usarlo dos veces seguidas: tras aplicar `zstd-cli` y después `rsync`, el informe dice
`- 1 retirados` y `zstd` desaparece. Aplicar un árbol nuevo RETIRA los ficheros del anterior, porque
una generación es el estado completo y no un incremento. Es coherente con la ayuda («aplica un árbol
Stage1/PRODUCTO») y con que exista `rollback`: lo que se revierte es un sistema, no un paquete.

⇒ Usarlo para paquetes sueltos funciona una vez y se deshace a la siguiente. La forma correcta de
poner una caja al día es componer el árbol del perfil —lo que ya hace `servidor-image.sh`—, sellarlo
y aplicar ESO. Que además sería la «actualización en sitio probada» del SDD 19 §5.2 de verdad: una
imagen entera con rollback sobre una caja viva.

La caja quedó con `zstd` y `rsync` puestos a mano: funciona y no es el camino, igual que el `git`.

De paso, verificado que el arreglo de `recipes/rsync.toml` sirve: el respaldo ya no imprime el aviso
de compresión degradada — `compress list` pasó de `zlibx zlib none` a `zstd zlibx zlib none`.

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 89a1954c..2e82b6fa 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -938,6 +938,30 @@ dos), y un `pending.json` vacío se reporta como `PendingCorrupt`, nombrando el
 **Verificado en la máquina, en los dos sentidos**: con el binario viejo, apply + reset duro ⇒ estado
 en 0 bytes; con el nuevo, la misma secuencia ⇒ estado íntegro y el paquete en su sitio.
 
+#### ⚠⚠ `upgrade apply` NO es un gestor de paquetes: cada generación ES UN ÁRBOL
+
+Lo destapó usarlo dos veces seguidas. Tras aplicar `zstd-cli` y después `rsync`:
+
+```
+✓ generación 2 aplicada
+  + 0 añadidos, ~ 8 pisados, - 1 retirados      ← el `zstd` de la generación 1
+$ zstd --version
+AUSENTE
+```
+
+**Aplicar un árbol nuevo RETIRA los ficheros del anterior**, porque una generación es el estado
+completo, no un incremento. Es coherente con lo que la ayuda dice —«aplica un árbol Stage1/**producto**
+del store»— y con que exista `rollback`: lo que se revierte es un sistema, no un paquete.
+
+⇒ Usarlo para instalar paquetes sueltos, como hice acá, funciona una vez y se deshace a la siguiente.
+**La forma correcta de poner una caja al día es componer el árbol del perfil —lo que ya hace
+`servidor-image.sh`— sellarlo, y aplicar ESO como una generación.** Eso además sería, de verdad, la
+«actualización en sitio probada» del [SDD 19 §5.2](19-lanzamiento-publico.md): una imagen entera, con
+rollback, sobre una caja viva.
+
+Mientras tanto la caja quedó con `zstd` y `rsync` puestos a mano — funciona y **no es el camino**,
+igual que el `git`.
+
 ⚠ Lo que NO se arregló: si el manifiesto se pierde, `recover` no puede deshacer solo — no sabe qué se
 tocó. El árbol de respaldos tiene la información; reconstruir desde ahí es su propia unidad.