cómo se instala software de tawasuyu en la caja — y por qué no con actualizar-servidor.sh

`install-tawasuyu.sh` y `actualizar-servidor.sh` existen y siguen ahí (el monorepo está clonado en
/work/sergio/tawasuyu), pero lo que hacen es `cargo build --release` + `install -m755` a
/usr/local/bin: producen exactamente la clase de binario que la mudanza encontró irreproducible —2,7
G de sueltos que nadie provee, tres de ellos corriendo desde un inodo BORRADO— y además escriben
servicios en /etc/init.d/, que en esta caja no existe.

La forma de acá, hecha de punta a punta con shuma-tui: receta pinneada ⇒ `takana build` ⇒ sellado
b3:f795ee0f… ⇒ el artefacto viaja por rsync ⇒ symlink desde el store ⇒ `shuma-tui --help` contesta.
El camino completo es el del §6.46 (repo firmado + `takana install --require-signed`), que es lo que
convierte «copiar un binario» en «instalar un paquete».

⚠ Y el límite de hoy: el build NO se puede hacer en la caja para recetas que clonan por HTTPS,
porque su git no tiene remote-https. Las que bajan tarballs con curl sí construyen ahí (hoy sellaron
intel-ucode y sof-firmware); las de tawasuyu se construyen en el worker. Arreglarlo es re-sellar
`git` con libcurl, raíz de perfil.base: unidad propia.

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

docs/28-servidor-de-produccion.md

@@ -2983,6 +2983,50 @@ Y el agente se abre sobre cualquiera de ellos:
   → «Es tawasuyu (/work/sergio/tawasuyu, origin git.gioser.net:2345/…), último commit 55e5f0f27»
 ```
 
+### 6.50 quater 📦 Cómo se instala software de tawasuyu en la caja — y por qué NO con `actualizar-servidor.sh` *(2026-09-17)*
+
+Pregunta del usuario: *«¿ahí tengo la confianza de `install-tawasuyu` y `actualizar-servidor`? ¿o
+cómo es la forma de instalar, por ejemplo, `shuma-tui`?»*
+
+**Esos guiones existen y siguen ahí** —el monorepo está clonado en `/work/sergio/tawasuyu`— pero lo
+que hacen es:
+
+```
+  cargo build --release <crates>        …y después…        install -m755 <nuevo> /usr/local/bin/<x>
+```
+
+O sea: **producen exactamente la clase de binario que la mudanza encontró irreproducible** — 2,7 G
+de sueltos que ningún paquete provee (§6.35), de los cuales tres corrían desde un inodo BORRADO.
+Además `actualizar-servidor.sh` escribe servicios en `/etc/init.d/`, que en esta caja no existe: el
+init es arje.
+
+#### La forma de acá, hecha de punta a punta con `shuma-tui`
+
+```
+  1. receta      recipes/shuma-tui.toml   — pinneada al commit del monorepo, zig-cc, musl, estática
+  2. build       takana build             ⇒ b3:f795ee0f… sellado en el store
+  3. viaja       worker → hub → caja      (rsync del artefacto, que es content-addressed)
+  4. instalar    ln -s /store/<hash>-shuma-tui/usr/bin/shuma-tui /usr/bin/
+  5. control     shuma-tui --help  →  contesta
+```
+
+Los pasos 3 y 4 son el atajo honesto de hoy; el camino completo es el del §6.46 —publicar en el repo
+firmado y `takana install <nombre> --require-signed`—, que ya está probado y es lo que convierte
+«copiar un binario» en «instalar un paquete».
+
+⚠ **El paso 2 NO se puede hacer en la caja todavía**, y el motivo es la deuda ya conocida: su `git`
+**no tiene `remote-https`**.
+
+```
+  git: 'remote-https' is not a git command
+  Error: git ["clone","--mirror",…,"https://git.tawasuyu.net/…"] falló
+```
+
+Las recetas del corpus que bajan tarballs con `curl` **sí** construyen ahí (hoy se sellaron
+`intel-ucode` y `sof-firmware`); las que clonan por HTTPS —todas las de tawasuyu— hay que
+construirlas en el worker, que sí tiene git completo. Arreglar eso es re-sellar `git` con libcurl, y
+es raíz de `perfil.base`: unidad propia.
+
 ### 6.51 🔥 Me dejé afuera de la caja — 20 minutos caída, y tres causas encadenadas *(2026-09-17)*
 
 Crear una cuenta de usuario tiró el servidor de producción. Queda escrito entero porque **ninguna de