sergio/takana

`work_root` sale de `dirname(store)/work`, o sea `/work` con el store en `/store`, y ahí `sources`
y `out` son ENLACES a `/work/sergio/work/…`, que es del usuario. Publicar como root dejaría
directorios de root en su árbol y su siguiente build moriría con un permiso denegado que no
menciona la causa. No es hipotético: root ya congeló el clon de tawasuyu del dueño dejándole 24
entradas suyas dentro del `.git`, y del lado de root no falló nada (ver publicar-webs.sh).

Si corre como root y nadie fijó TAKANA_WORK, lo manda a /var/tmp/takana-publicar-work y lo dice.
Comprobado que el override no mueve el hash: zsh sella en b3:0be3630d… con y sin él.

Y el mensaje final deja de decir «falta el vhost» cuando lo acaba de poner: si se instaló y aun así
no responde, lo que hay que mirar es el certificado, el DNS y el repo, en ese orden.

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index 63a589f8..ff5e2d68 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -589,6 +589,14 @@ no tiene el admin abierto)*:
 El orden es lo único que lo hace seguro: copia → añadir → `caddy validate` → **sólo entonces**
 `reload`. Un reload con la config rota no tira el sitio nuevo: tira los 19.
 
+⚠ **Y root no escribe en el árbol del usuario.** `work_root` sale de `dirname(store)/work` ⇒ con el
+store en `/store` es `/work`, donde `sources` y `out` son **enlaces a `/work/sergio/work/…`**, que es
+del usuario (CLAUDE.md §3 bis). Publicar como root dejaría ahí directorios de root y el siguiente
+build suyo moriría con un permiso denegado que no menciona la causa — es exactamente lo que ya pasó
+cuando root hizo `git pull` en el clon de tawasuyu y lo congeló para el dueño (`publicar-webs.sh`).
+El guion, si corre como root y nadie fijó `TAKANA_WORK`, lo manda a `/var/tmp/takana-publicar-work`
+y lo dice. Comprobado que el override no mueve el hash: `zsh` sella en `b3:0be3630d…` igual.
+
 ⚠ **Y trae su propia guarda contra el error más fácil de cometer:** si el `takana` de la caja es
 anterior al §5.5 (se detecta porque no conoce `outdated`), **aborta antes de publicar**. Con uno
 viejo el repo sale con las 16 recetas multi-parche irreproducibles y 8 paquetes prometiendo un
diff --git a/scripts/servidor/publicar-repo.sh b/scripts/servidor/publicar-repo.sh
index 1025d3c2..b164d3cf 100755
--- a/scripts/servidor/publicar-repo.sh
+++ b/scripts/servidor/publicar-repo.sh
@@ -68,6 +68,19 @@ export KEY
     exit 2
 }
 
+# ⚠ ROOT NO ESCRIBE EN EL ÁRBOL DEL USUARIO. `work_root` sale de `dirname(store)/work`, o sea `/work`
+# con el store en `/store` — y ahí `sources` y `out` son ENLACES a `/work/sergio/work/…`, que es del
+# usuario. Publicar como root dejaría directorios de root en su árbol y el siguiente build suyo
+# moriría con un permiso denegado que no menciona esto. Ya pasó con otro guion: root hizo `git pull`
+# en el clon de tawasuyu, dejó 24 entradas suyas dentro del `.git` y congeló el clon para el dueño
+# sin que nada fallara del lado de root (ver `publicar-webs.sh`). Así que el scratch va aparte.
+if [ "$(id -u)" = "0" ] && [ -z "${TAKANA_WORK:-}" ]; then
+    TAKANA_WORK="${TAKANA_WORK_ROOT:-/var/tmp/takana-publicar-work}"
+    export TAKANA_WORK
+    install -d -m 755 "$TAKANA_WORK"
+    echo "==> como root: scratch de build en $TAKANA_WORK (no en el árbol del usuario)"
+fi
+
 echo "==> publicando el perfil '$PERFIL' en $DESTINO"
 install -d -m 755 "$DESTINO"
 PERFIL="$PERFIL" STORE="$STORE" REPO="$DESTINO" TRUST="$TRUST" TAKANA="$TAKANA" \