From 88f3977e2c5fbb9b81b2592c1d64e60e0f64178d Mon Sep 17 00:00:00 2001
From: Sergio <sergio@gioser.net>
Date: Fri, 18 Sep 2026 17:45:11 +0000
Subject: [PATCH] jaula-preparar: enlazar takana/patch/gh/hcloud del store al
 PATH de adentro
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Cuarto defecto de la misma familia que los tres que el script ya repone, encontrado construyendo
DESDE la jaula: los binarios que el agente necesita no están en la imagen de Arch, pero sí sellados
en `/store`, que la instancia ya tiene concedido. Son musl estáticos y corren dentro de una imagen
glibc, así que no hay que instalar nada — sólo enlazarlos.

El que costó encontrarlo es `patch`: takana aplica los parches FUERA del sandbox, o sea que lo busca
en el PATH de la jaula, no en el del lab. `wtype` (sin parches) construía y `zsh` (con seis) moría en
`spawn patch: No such file or directory`. El `patch` del lab no sirve de nada acá: es musl DINÁMICO
y no arranca en una imagen glibc.

Los wrappers ya viven en /work/<usuario>/bin, que es bind del anfitrión y sobrevive al recreate; lo
único que se pierde es el enlace en el PATH.
---
 scripts/servidor/jaula-preparar.sh | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/scripts/servidor/jaula-preparar.sh b/scripts/servidor/jaula-preparar.sh
index 8aca0b4b..011b0c15 100755
--- a/scripts/servidor/jaula-preparar.sh
+++ b/scripts/servidor/jaula-preparar.sh
@@ -61,4 +61,31 @@ done
 chown "$U:$U" "$K" 2>/dev/null || true; chmod 600 "$K" 2>/dev/null || true
 echo "  ✓ known_hosts con $(grep -c . "$K" 2>/dev/null || echo 0) entradas"
 
+# ── 4. las herramientas del STORE, en el PATH de adentro ────────────────────────────────────────
+# MEDIDO el 2026-09-18 construyendo DESDE la jaula. Cuatro binarios que hacen falta adentro y que no
+# tienen por qué venir del gestor de paquetes de la imagen: ya están sellados en `/store`, que la
+# instancia tiene concedido, y son musl estáticos — corren igual dentro de una imagen glibc.
+#
+#   · `takana`  el que construye. `/opt/takana/target/release/takana` del anfitrión es un enlace a
+#               `/usr/bin/takana`, que ADENTRO es el /usr/bin de Arch y no lo tiene.
+#   · `patch`   takana aplica los parches FUERA del sandbox, así que lo busca en ESTE PATH. Sin él,
+#               toda receta con parches muere en `spawn patch: No such file or directory` — `wtype`
+#               (sin parches) pasaba y `zsh` (con seis) no. El del lab NO sirve: es musl DINÁMICO y
+#               no arranca en una jaula glibc.
+#   · `gh`      el espejo a GitHub empuja por HTTPS con su token como credential helper.
+#   · `hcloud`  para ver la flota de Hetzner sin salir de la jaula.
+#
+# Los wrappers viven en /work/<usuario>/bin, que es bind del anfitrión y SOBREVIVE al recreate; lo
+# que se pierde es el enlace en el PATH, y eso es lo que repone esto. Cada wrapper elige el artefacto
+# MÁS RECIENTE del store en vez de un hash cableado, para sobrevivir a un re-sellado.
+BIN=/work/$U/bin
+if [ -d "$BIN" ]; then
+  install -d -o "$U" -g "$U" "$UP/usr/bin"
+  for t in takana patch gh hcloud; do
+    [ -x "$BIN/$t" ] || continue
+    ln -sfn "$BIN/$t" "$UP/usr/bin/$t" 2>/dev/null || true
+  done
+  echo "  ✓ takana/patch/gh/hcloud enlazados al PATH desde $BIN"
+fi
+
 echo "jaula $INST preparada — lo del manifiesto (paquetes, concesiones) lo pone `takana qorpa provision`"