takana/docs/28-servidor-de-produccion.md

SDD 28 — El servidor de producción: instalar takana puro en una caja remota y mudarse a ella

Escrito 2026-09-09 a pedido del usuario («qué tan lejos estamos de montar un server takana en Hetzner y que sea producción, y mover allá todo lo que tengo acá, y de una vez mantenerlo por repo takana»). Todo número marcado (medido) salió de un comando corrido ese día sobre gioser.

Continúa SDD 19 (lanzamiento público) y SDD 27 (metapaquetes e instalador). No repite el instalador: SDD 27 decide QUÉ se instala y con qué verbo; esto decide DÓNDE, y cómo se llega.

---

0. La corrección de encuadre: ya estamos en Hetzner

gioser es un servidor Hetzner (hcloud id 126324694, hel1, 4 cores / 7,6 GiB) (medido). La pregunta no era «cómo llegar a Hetzner» sino cómo tener una caja de takana en vez de ser un inquilino más de una máquina compartida que:

• sirve 19 dominios por Caddy,
• tiene /mnt/vvv al 89 % (27 G libres) (medido),
• es fija y sin backup por pedido explícito del usuario (blindaje anti-borrado en deadman.sh y farm-down.sh, ver ADR 0014 y la memoria del proyecto),
• y no publica nada de takana: cero entradas de takana en el Caddyfile (medido).

0.1 El hallazgo que cambia el tamaño del problema

$ ps -p 1 -o comm=,args=
arje-zero  /usr/local/sbin/arje-zero
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-linux root=UUID=54de62df-… rw net.ifnames=0 splash \
  init=/usr/local/sbin/arje-zero loglevel=4

El init de takana ya gobierna un servidor de producción real. Caddy, gitea, sshd, qdrant y act-runner cuelgan directo de PID 1 (medido: ps -eo pid,ppid,comm | awk '$2==1').

Pero eso no es takana puro: es Artix con nuestro init inyectado por init= en el cmdline. El kernel, la libc y los 19 servicios son ajenos. Se probó la mitad difícil sobre userland prestado.

0.2 ⚠ La declaración del arranque no existe en ningún sitio legible

rc-status de OpenRC dice stopped para caddy, gitea, sshd, cronie y act-runner, y los cinco están vivos (medido, los dos comandos). /etc/arje/cards.d tiene 4 tarjetas (acpid, openrc-openclaw, squid, zram-swap) y ninguna de ellas los levanta.

⇒ La secuencia de arranque de esta caja no está escrita. Es lo menos reproducible de toda la mudanza y lo primero que hay que capturar — ver §4.

---

1. Inventario de lo que hay que mudar (medido 2026-09-09)

Datos en /mnt/vvv (217 G de 255)

tawasuyu	124 G
takana	91 G — incluye el store de 55 G bind-mounteado desde el otro volumen ⇒ ~36 G propios
rustup	29 G
act-runner · gioserv · _respaldo	6,5 · 5,4 · 4,1 G
~20 dirs *-standalone	agora, card, chasqui, cosmos, dominium, khipu, minga, mirada, nakui, nahual, pata, pineal, pluma, shuma, takiy, llimphi…

El volumen harkaq-cosecha (250 G, 148 G usados)

store	55 G, 1327 artefactos — lo irreemplazable
work-sources + cargo-home + gopath	~85 G — caché regenerable, no se muda
work-tarballs · devfs-cache · work-out	3,2 G · 4,5 G · 397 M

El store no se copia por red. Los dos volúmenes están en hel1; un volumen hcloud se desengancha de una caja y se engancha a otra en la misma ubicación. La mudanza del store son dos comandos.

Servicios vivos, todos hijos de arje-zero

caddy :80/:443 · gitea :3002 · sshd :2345 · act_runner (el CI de tawasuyu) · qdrant :6333/:6334 · openclaw · zeroclaw · shuma-gateway :7378 · tejido :4102 y :33097 · puerta-f6e393ff · uvicorn :8771 · python3 :8770 · squid :1137 · fail2ban · glances · php-fpm · metalog · adb :5037.

Lo que no está en ningún repo

/var/lib/gitea (2,2 G: SQLite + los repos de git de todo, incluido el origin de takana) · /var/www (287 M) · /home/sergio/gioser-web/ · /etc/caddy/Caddyfile + 20 ficheros .bak · los certificados de letsencrypt · los crontabs · /etc/arje/cards.d · las 3 credenciales de ~/.config/hammer/*.env · las llaves ~/.ssh/{github5,sergio} · el token hcloud · y la memoria del agente en ~/.claude/.

1.1 La basura, contada — porque una mudanza fiel copia también la basura

De los 19 dominios del Caddyfile (probados uno por uno desde la propia caja):

responden 200	rotos
gioser.net · tawasuyu.net · git.gioser.net · summa.gioser.net · sergio.gioser.net	api.gioser.net → 502 (backend caído)
	aura · sigma · kosmofono · terapeuta.ec → sin DNS

Y sus raíces no existen en disco: /var/www sólo tiene terapeuta, goaccess, ogisoer, git-tawasuyu, letsencrypt y un .bak — no hay aura_frontend, ni sigma, ni summa/frontend, ni kosmofono. La mitad del Caddyfile describe un servidor que ya no existe.

⇒ Regla de la mudanza: no se muda lo que no responde. Lo que no tiene DNS ni ficheros se anota y se deja morir con la caja vieja. La utilidad del §4 tiene que saber decir declarado / vivo / fósil.

---

2. La caja: qué, cuánto y por qué

Precios consultados a la API de hcloud el 2026-09-09 (hel1, x86, tipos no deprecados) (medido):

tipo	recursos	€/mes
cx53	16 c / 32 G / 320 G	29,49
cpx41	8 c / 16 G / 240 G	32,49
ccx23 (dedicado)	4 c / 16 G / 160 G	85,99

Elegido cx53: es el mejor punto de la tabla y entra holgado el conjunto tawasuyu + takana + rustup (~244 G) si algún día se muda todo.

Decisiones del usuario (2026-09-09):

1. La caja PUBLICA; el LXC prestado sigue moliendo. dev.gioser.net cuesta €0 y es la máquina con más RAM (6 c / 16 G + 8 G swap). Separar servir de compilar mantiene la caja chica y barata. La caja nueva puede además compilar, con el LXC enchufado como segundo worker.
2. «Producción» = operativo pero privado. Sin descarga pública todavía ⇒ no se activan los bloqueantes legales del SDD 19 §2 (espejo de fuentes público por HTTP, marca de terceros). Lo que sí hace falta igual es la clave de release estable (§5).
3. gioser se BORRA cuando la mudanza esté comprobada. Eso convierte esto en un experimento con fecha de caducidad, y cambia el diseño entero: ver §6.

⚠ El blindaje anti-borrado de gioser es deliberado y hay que levantarlo a mano y a propósito. deadman.sh y farm-down.sh lo protegen por lista negra de nombre y por ausencia del label role=hammer-worker. Ninguna automatización debe poder borrarlo: cuando llegue el día, se borra a mano, con la comprobación del §6 en verde y no antes.

---

3. Instalar takana puro en una caja remota

3.1 Lo que ya está, y por qué está más cerca de lo que parece

El dato que lo destraba: Hetzner Cloud arranca por BIOS, no por EFI. (medido en gioser: no existe /sys/firmware/efi; GPT + GRUB; /boot es vfat de 1 G.) Y scripts/takana-install.sh escribe exactamente ese layout: GPT + GRUB BIOS, SeaBIOS → GRUB → kernel → arje-zero PID1. El camino EFI —que fue el que más trabajo costó (ADR 0010)— es el que Hetzner no necesita.

pieza	estado (medido)
kernel con virtio	recipes/linux.toml compila VIRTIO, VIRTIO_PCI, VIRTIO_BLK, VIRTIO_NET, EXT4_FS =y ⇒ sin initramfs
red	crates/netup = cliente DHCPv4 propio en Rust sobre netlink, autodetecta interfaz y espera carrier. gioser toma su IP por DHCP en eth0 (/32, net.ifnames=0, DNS 185.12.64.2) ⇒ es justo su caso
acceso	recipes/openssh.toml sellado; el product-rootfs vigente ya trae sshd; takana-install.sh acepta AUTHKEYS
servir	recipes/caddy.toml existe
escritura a disco	scripts/takana-install.sh (no interactivo) y scripts/takana-live-install.sh (TUI), probado por scripts/install-tui-test.sh

3.2 El camino remoto: rescue → dd → reboot

Hetzner Cloud tiene un sistema de rescate (Debian por SSH) que se activa desde la API sin tocar la caja. Desde ahí se escribe la imagen al disco y se reinicia. No hace falta ISO, ni consola, ni medio físico — que es justo lo que hace innecesario el 90 % del trabajo de ISO/USB para este caso.

3.3 Los cuatro huecos, nombrados

1. perfil.servidor — HECHO hoy en docs/state/targets.toml. Ver §3.4.
2. console=ttyS0 en el cmdline — el único salvavidas si el arranque falla y no hay teclado. Hetzner da consola web; sin serial en el kernel, esa consola no muestra nada útil.
3. IPv6 — netup hace DHCPv4 y Hetzner entrega un /64 estático. La caja arrancaría con IPv4 sola. Aceptable para empezar, pero hay que saberlo antes, no descubrirlo.
4. Un .img del perfil servidor que el rescue pueda escribir. Es hydrate-profile.py + install-image.sh, los dos ya existentes — ver §7.

3.4 El perfil, y la deuda que declara (hecho 2026-09-09)

[perfil.servidor] hereda cli (que hereda base, SDD 27 §7.1) y añade 5 raíces que existen (openssh, caddy, curl, wget, tmux) y 5 que NO:

raíz que no resuelve	por qué está declarada igual
takana	el propio takana no tiene receta. El corpus construye 869 recetas y no la suya ⇒ el binario sólo existe como cargo build sobre un clon. Es EL bloqueante del §5
chrony	sin NTP, un reloj que deriva rompe TLS y las firmas — y falla diciendo «firma inválida», no «la hora»
nftables	dev.gioser.net está hoy expuesto con fuerza bruta a root en el journal; una caja nueva no debería nacer así
cronie	el latido son tres líneas de crontab, y sin systemd no hay timers: o hay cron, o el latido es una tarjeta de arje-zero. Decisión pendiente
logrotate	en una caja que sirve, el log de acceso crece hasta llenar el disco

Quedan wanted en el grafo, y wanted no es debt ⇒ drenaje.json seguirá diciendo deuda=0. Se declaran igual porque una deuda escrita se ve y una omitida no: sin ellas el perfil saldría N/N —completo y verde— describiendo un servidor sin hora, sin cortafuegos y sin latido. Es la lección de foot en escritorio-sway (121/121 sellado y sin emulador de terminal), pagada por adelantado. Cuenta esperada: 5. Un sexto wanted es un error de tipeo, no una receta nueva.

3.5 La caja, creada (2026-09-10)

nombre / id	takana / 165447050
tipo	cx33 — 4 c / 7,6 GiB / 76,3 G — €8,49/mes
ubicación	hel1 — la misma que los volúmenes vvv y harkaq-cosecha y que el Storage Box
IPv4 / IPv6	2.29.29.217 · 2a01:4f9:c014:2f9c::/64
imagen inicial	debian-13 — desechable: existe sólo para recibir ficheros hasta el dd del §3.2
label	role=takana-server
protección de borrado	NO, a propósito: es la caja de sacrificio

⚠ El label importa: farm-down.sh y deadman.sh borran sólo lo que lleva role=hammer-worker. Esta caja no lo tiene ⇒ ninguna automatización de la granja puede tocarla. Es la misma capa fuerte que protege a gioser, aplicada al revés: no se protege por nombre, se protege por no haber nacido de farm-up.

⚠ cx53 no se pudo comprar: sale Available: no en las TRES ubicaciones. Y la disponibilidad cambia por día — cx33 salió no en hel1 el 2026-09-09 y yes el 2026-09-10, con la misma consulta. ⇒ el precio de la tabla no dice que la máquina exista: hcloud server-type list devuelve precios para tipos que no se pueden crear. Consultar Available por ubicación, y volver a consultarlo el día que se compra.

Lo que la caja confirma, medido EN ELLA y no inferido de gioser

1. Arranca por BIOS — no existe /sys/firmware/efi… y sin embargo la imagen trae un ESP (sda15, 244 M vfat en /boot/efi). O sea: la presencia de una partición EFI no indica arranque EFI. Si el instalador decidiera la rama mirando particiones en vez de /sys/firmware/efi, elegiría mal en esta caja exacta. takana-live-install.sh mira lo correcto.
2. console=tty1 console=ttyS0 viene en el cmdline de Debian. Confirma que el serial es lo que Hetzner espera, y que el hueco 2 del §3.3 es real: nuestra imagen tiene que traerlo o la consola web no muestra nada.
3. eth0 con /32 dinámico por DHCP — idéntico a gioser ⇒ es exactamente el caso de netup.

Dos cosas pendientes en la caja, anotadas

• 7,6 GiB de RAM y CERO swap — la misma clase de máquina que ya provocó global_oom en gioser. Coherente con la decisión de §2.1 (la caja publica, el LXC muele), pero significa que no se construye pesado acá mientras siga así.
• sshd trae PasswordAuthentication yes (con PermitRootLogin without-password, así que root por clave igual). El journal del LXC muestra fuerza bruta a root desde IPs random; esta caja está igual de expuesta. Se cierra cuando se instale takana puro, o antes si se queda días con Debian.

3.6 La imagen del perfil.servidor, armada y validada (2026-09-10)

Receta del ensamblado (todo con scripts que ya existían, §7):

# 1. base con init: el product-rootfs sellado (trae /sbin/init -> /usr/bin/arje-zero)
cp -al /mnt/cosecha/store/5011955a…-product-rootfs/. $D/
# 2. userland del perfil encima
scripts/hydrate-profile.py servidor --into $D --store /mnt/cosecha/store --keep
# 3. ⚠ restaurar el init (ver abajo) y meter la clave
ln -sf /usr/bin/arje-zero $D/sbin/init ; cp github5.pub $D/root/.ssh/authorized_keys
# 4. imagen
ROOTFS=$D STAGE=/mnt/cosecha/.install-stage KERNEL=store/23f1cc43…-linux-generic/boot/bzImage \
CMDLINE="console=ttyS0,115200 console=tty0 root=/dev/sda2 rw init=/usr/bin/arje-zero" \
  ./scripts/install-image.sh

Resultado: 86 nodos, 30.500 ficheros, 2,0 G de rootfs → imagen de 7.172 M (2,1 G en disco, sparse).

El kernel correcto es linux-generic, y linux.toml NO sirve para hcloud

El disco de una caja hcloud lo maneja virtio_scsi (driver sd, disco sda) — no virtio_blk. recipes/linux.toml apaga SCSI explícitamente (-d SCSI) ⇒ su kernel arranca y no ve el disco. linux-generic, linux-metal y linux-metal-dual sí sirven.

⚠ Y ninguna receta nombra SCSI_VIRTIO. Está encendido igual, porque make defconfig lo trae y -e SCSI -e BLK_DEV_SD lo mantiene. Se supo mirando el .config que linux-generic publica en su artefacto (/boot/config-7.1.2-generic), no leyendo la receta. La receta dice lo que se cambió; sólo el .config sellado dice lo que quedó.

⚠ La hidratación PISA /sbin/init, y el resultado arranca igual

busybox entra en la clausura del perfil y su /sbin/init -> ../bin/busybox gana por llegar después, borrando el -> /usr/bin/arje-zero del product-rootfs. La imagen habría arrancado perfecta con el init de busybox: no takana puro, y sin un solo error. Se tapa por las dos puntas — restaurando el symlink al ensamblar y con init=/usr/bin/arje-zero explícito en el cmdline, que es lo que hace gioser y es autoritativo pase lo que pase con el symlink.

Y la guarda que existía para esto estaba INVERTIDA (arreglada en el mismo commit): [ -e "$ROOTFS/sbin/init" ] sigue el symlink y lo resuelve contra el host, así que el symlink ABSOLUTO a arje-zero daba falso y el rootfs correcto era rechazado, mientras que el relativo a busybox —el equivocado— pasaba. Ver guardian-que-nunca-fallo: una guarda que nunca falló no se sabe si sirve; ésta fallaba al revés.

EXDEV, dos veces en la misma tarde

store y work/out son bind-mounts de /dev/sdb; work/ está en /dev/sdc. Un hardlink no cruza un montaje aunque sea el mismo disco, así que reventaron (1) hydrate-profile.py con el destino fuera del montaje del store —que avisa RUIDOSO y bien— y (2) el staging de install-image.sh, que lo tenía cableado a work/. Ahora STAGE es env. Ver hardlink-cruza-mount-exdev.

La validación: arrancó en QEMU reproduciendo virtio-scsi, y se entró por SSH

SeaBIOS → GRUB → kernel 7.1.2 propio → EXT4-fs (sda2): mounted → Pivoted into new rootfs
→ Run /usr/bin/arje-zero as init process → "arje-zero: despierta como PID 1"
→ netup (DHCP) → ssh-keygen -A → sshd

Y desde fuera: ssh -p 2299 root@127.0.0.1 entra, /proc/1/comm dice arje-zero, ip addr da la IP que negoció netup. Es la puerta 1 del §6 ensayada en local antes de gastar la caja.

El card sshd de /ente/seed.card.json ya hacía el trabajo entero sin que hubiera que tocar nada: sh -c "/usr/bin/netup; /usr/bin/ssh-keygen -A; exec /usr/sbin/sshd -D -e" — red, claves de host y demonio en una línea. Lo único que hubo que inyectar fue authorized_keys.

Un resto del renombre, encontrado por el arranque

arje-zero: hammer no corre, sin menú de arranque: No such file or directory (os error 2)

arje-zero invoca el binario por el nombre VIEJO (hammer). No es fatal —sigue arrancando— pero el menú de arranque por grafo del ADR 0010 queda muerto. Y viene de tawasuyu, pineado por commit en recipes/arje-zero.toml, así que no se arregla desde este repo: hay que subirlo allá y re-pinear. Se suma a que la imagen tampoco trae takana (§3.4).

3.7 ⚠ El muro real: la puerta de enlace de Hetzner está FUERA del prefijo

La imagen validada en QEMU se escribió a la caja, arrancó… y no se pudo entrar. hcloud decía running, el puerto 22 cerrado, y desde fuera Connection timed out — el modo de fallo más caro de todos, porque no hay consola serie en hcloud para mirar.

La causa, medida entrando al rescue de la propia caja:

inet 2.29.29.217/32 scope global eth0
default via 172.31.1.1 dev eth0
172.31.1.1 dev eth0 scope link      ← ESTA es la que faltaba

La IPv4 viene con prefijo /32 y la puerta (172.31.1.1) no pertenece a ninguna red conectada. netup mandaba el default con RTA_GATEWAY y scope UNIVERSE y nada más, así que el kernel lo rechazaba con ENETUNREACH: la máquina se quedaba con IP y sin salida, contestando el DHCP y levantando sshd, sin nada visiblemente roto por dentro.

Control causal, en un netns con una dummy y una /32:

ip route add default via 172.31.1.1 dev dummy0   ⇒ Error: Nexthop has invalid gateway.
ip route add 172.31.1.1 dev dummy0 scope link    ⇒ ok
ip route add default via 172.31.1.1 dev dummy0   ⇒ ACEPTADO

Arreglado con add_onlink_host_route (dst /32, scope LINK) antes del default.

Por qué no había aparecido nunca: netup se validaba contra el DHCP de QEMU slirp, que entrega un /24 con la puerta dentro de la subred. El escenario que rompe sólo existe en una nube de verdad. Es cache-congela-regresiones en su otra forma: no es que el test estuviera mal, es que el ÚNICO entorno donde se probaba no contenía el caso.

Y destapó un segundo problema de fondo: el binario de netup venía dentro del product-rootfs, o sea congelado en un artefacto sellado del bootstrap ⇒ arreglar netup no llegaba a la imagen. Por eso netup pasa a ser raíz de perfil.servidor: así la hidratación lo proyecta encima y la imagen lleva el vigente. Verificado por sha256 (imagen a23df20e…, product-rootfs a84b0a0d…).

3.8 ✅ Puerta 1, pasada (2026-09-10)

PID 1    : arje-zero          kernel : 7.1.2 (linux-generic propio)
IP       : 2.29.29.217        rutas  : default via 172.31.1.1 + 172.31.1.1 scope link
montajes : /dev/sda3 -> /store      /dev/sda4 -> /var/lib/hammer
salida   : ping 1.1.1.1 0% pérdida · curl http://1.1.1.1 -> 301 · resolv.conf escrito por netup

Una caja Hetzner Cloud corriendo takana puro: nuestro kernel, nuestro init, nuestro cliente DHCP, nuestro sshd — sin una línea de Debian debajo. El camino entero es scripts/servidor-image.sh + rescue + dd, y la escritura de los 7,1 G comprimidos tarda ~17 s (gioser y la caja están las dos en hel1).

Lo que la caja todavía no tiene, y es el paso 2: takana (sin receta, §3.4), el store real (el volumen no se engancha hasta acá) y las otras cuatro raíces wanted.

---

4. La utilidad de migración: absorber lo VIVO, no lo declarado

arje-absorb ya existe, está sellado (recipes/arje-absorb.toml) y su --help dice: lee sysvinit | runit | dinit | openrc | auto y emite una Tarjeta Semilla con cada servicio del init ajeno como hija de arje-zero. Tiene parsers para los cinco (systemd.rs, openrc.rs, runit.rs, dinit.rs, sysvinit.rs).

Pero lee la declaración, y en gioser la declaración miente (§0.2). Un arje-absorb --from openrc sobre esta caja produciría una Semilla que no levanta el servidor, y lo haría en silencio: la Semilla sería sintácticamente perfecta.

⇒ Lo que falta es un segundo lector: absorber del proceso vivo (/proc: ppid==1, cmdline, cwd, entorno, fds en LISTEN) y reconciliar ambas lecturas marcando dónde discrepan. Eso es lo que el usuario nombró como «lo aprendido de matilda» — absorber lo que hay, no lo que está escrito.

La utilidad debe clasificar en tres, no en dos:

clase	criterio	qué se hace
vivo	proceso corriendo y declarado	se muda
declarado, muerto	en la config, sin proceso ni ficheros (los 4 dominios sin DNS)	fósil: se anota y se deja morir
vivo, no declarado	proceso con ppid==1 que ningún init declara (caddy, gitea, sshd, act-runner)	se escribe la tarjeta que faltaba — es el trabajo real

Se construye al final, estrenándose con la migración gioser → caja nueva, con el caso del rc-status que miente como test de aceptación. Su especificación es el §1 de este documento.

---

5. Que el servidor sirva sus propios paquetes a su propio host

Existe el camino entero: scripts/build-repo.sh (corpus → .swm firmados + índice), takana install --repo que ya acepta lista HTTP multi-origen y verifica cada paquete contra el digest del índice firmado (ADR 0014), takana upgrade con rollback, y caddy para servir dist/repo con un file_server.

Lo que falta no es servir, son dos cosas:

1. La clave. build-repo.sh firma hoy con una clave efímera por defecto (keygen release si no se le pasa KEY=) (medido, línea 33). Sin clave estable, «firmado» no significa nada. Es el SDD 19 §3.2 y es requisito aunque el repo sea privado.
2. La receta de takana (§3.4). El host necesita takana instalado para consumir los paquetes, y hoy no puede instalarlo desde el repo porque takana no está en el repo.

5.1 Hecho (2026-09-10): clave estable, repo firmado, y la caja sirviéndolo

• trust/ — la clave PÚBLICA de release en el repo; la privada en ~/.config/takana/keys/ (0600, fuera de git). scripts/repo-perfil.sh aborta si no la encuentra en vez de inventar una efímera, y tras firmar verifica el índice contra trust/.
• 88/88 paquetes del perfil servidor publicados con expected_hash anclado.
• La caja los sirve con caddy file-server sobre /srv/repo.

El control de la firma, en los dos sentidos, contra el repo servido por la caja:

--trust	resultado
./trust	release: trusted (by release) ⇒ instala
un directorio vacío	release: unknown-key … clave no confiada ⇒ ABORTA

5.2 ⚠ Lo que el lazo destapó: strip_debug no viajaba en el paquete

La primera instalación real de takana desde su propio repo falló:

Error: expected_hash no coincide:
  declarado = b3:941d1857…   obtenido = b3:2727050e…

why-differs lo nombró: los dos binarios pesaban exactamente lo mismo y sólo divergían en .shstrtab — la firma de un strip que corrió una vez y la otra no. swm_bridge re-inyecta con cuidado flags, phases, zig_version, strip_components, patches, deps… y se olvidaba de strip_debug, que ni siquiera existía en SwmBuild. Como entra en hash_inputs, el receptor reconstruía en otra dirección.

Alcance: 40 recetas del corpus, 18 de las 88 de este perfil. Una quinta parte del repo no se podía instalar, y nadie lo sabía porque nunca se había cerrado el lazo. Arreglado, con test de regresión y su control. Tras el arreglo, install takana da cache-hit en el hash anclado.

5.3 ⚠ Y el loopback nunca se levantaba

Al intentar que la caja instalara de sí misma por http://127.0.0.1: timeout de 30 s, con caddy escuchando en 0.0.0.0:80. lo estaba DOWN y sin dirección — con systemd o OpenRC lo levanta el init; con arje-zero no lo hacía nadie. El síntoma no era «connection refused», que se diagnostica en un minuto: era un cuelgue que parecía del servidor. Arreglado en netup (es quien configura la red) y verificado desde la imagen, sin tocar la caja a mano.

5.4 🚧 Lo que NO se puede todavía, y por qué importa

Con todo lo anterior en verde, la caja sigue sin poder instalar de su propio repo:

release: trusted (by release)              ← la firma verifica
repo: bajados 2 .swm de http://127.0.0.1   ← descarga de sí misma
Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
       El toolchain entra en el ArtifactHash, así que sin rootfs no se puede
       calcular un hash comparable

O sea: la mitad de servir está cerrada y probada; la de consumir, no — y no por un detalle de instalación, sino porque install reproduce desde fuente y eso exige el LAB ENTERO en el cliente. No es «falta un compilador»: el lab entra en el ArtifactHash, así que sin él no se puede ni calcular el hash a comparar.

Es exactamente el punto que SDD 27 §4 dejó planteado y sin decidir —reproducir o hidratar— visto desde el otro lado: para un servidor, o para cualquiera que no sea un hub de build, reproducir no es una opción. El camino normal tiene que ser hidratar artefactos firmados, con --reproduce como camino auditable. Mientras esa decisión no se tome, el repo firmado sirve para distribuir a hubs, no a usuarios.

⚠ Y una caja que se sirve a sí misma es un solo origen — justo lo que el ADR 0014 existe para no tener. El camino normal puede ser el local, pero la lista de orígenes del host debe incluir también el Storage Box o gioser. Si no, el primer origen roto es el último.

Lo que esto vale: cerrar el bucle es el ensayo de «actualización en sitio probada de verdad» (SDD 19 §5.2), hecho sobre una máquina que importa pero que no es el laptop de nadie.

---

6. La mudanza como experimento: el criterio de borrado

El usuario decidió que gioser se borra al final. Eso no es un detalle de calendario: es lo que convierte la mudanza en un experimento con criterio de aceptación, y hay que escribirlo antes.

Regla base: un ausente falla ruidosamente; un vacío llega hasta el final diciendo que todo fue bien. Aplicado acá: «lo copié» no es prueba de nada. La prueba es que el servicio responde en la caja nueva y que el dato se verifica por contenido.

6.1 Las puertas, en orden. Ninguna se salta.

#	puerta	cómo se comprueba
1	la caja nueva arranca takana puro y se entra por SSH	ssh a la IP nueva tras el reboot del rescue
2	el store está entero	1327 artefactos y ninguno vacío — respaldo-storagebox.sh --listar separa los vacíos; un directorio vacío no es un artefacto
3	los grafos salen idénticos	build-state.py en las dos máquinas ⇒ los cuatro grafos byte a byte. Es la prueba de que un hub está bien montado, no que «funcione»
4	la granja late en la caja nueva	una cosecha completa con el LXC enchufado por .fleet y artefactos que vuelven
5	el repo se sirve y el host se actualiza de sí mismo	§5 en verde, con la clave estable
6	cada dominio vivo responde 200 desde fuera	la tabla del §1.1, repetida contra la IP nueva
7	el respaldo al Storage Box corre desde la caja nueva	una corrida completa, no un --seco
8	lo fósil está anotado y decidido	lista del §1.1 con «muere» o «revive» al lado de cada uno

⚠ Puerta 3 tiene una trampa conocida: sealed_remoto dependía de la máquina (laptop 700, gioser 751 sobre el MISMO corpus) y por eso se sacó del JSON. Si los grafos difieren, mirar primero si la diferencia es «cuánto de esto tengo en disco» y no «qué existe».

6.3 Estado de las puertas (2026-09-10)

#	puerta	estado
1	arranca takana puro y se entra por SSH	✅ §3.8
2	el store está entero	✅ 1362 artefactos reales, 0 vacíos
3	los cuatro grafos idénticos	✅ byte a byte — §6.7
4	la granja late en la caja nueva	✅ cosecha completa: 1369→1575, 0 vacíos — §6.8
5	el repo se sirve y el host se actualiza de sí mismo	⬖ mitad: sirve (§5.1), no consume (§5.4)
6	cada dominio vivo responde 200	⬖ sondeados: 6 vivos de 19 — §6.9
7	el respaldo corre desde la caja	⬖ alcanza el box y lista 3140; arreglados 3 bloqueos — §6.10
8	lo fósil, anotado y decidido	✅ decidido — §6.9

Puerta 2, medida acotando al patrón <hash>-<nombre>: 1362 artefactos, 0 vacíos. Los 3 sin .hammer/recipe.toml son stage1-rootfs, product-rootfs y seed-zig — productos de bootstrap, que por diseño no salen de una receta. (El primer conteo dio «3 vacíos» y eran .mirror-tmp, .bootstrap-tmp y .divergen: directorios de trabajo con punto inicial, no artefactos. El chequeo tiene que acotar por el patrón, no listar el directorio.)

De paso, el disco: la imagen ocupaba 7 G de los 76,3 G de la caja y los otros 69 eran inalcanzables. Arreglado en install-image.sh — el store pasa a ser la ÚLTIMA partición (la única que puede crecer sin mover datos) y el wrapper de /sbin/init la extiende en el primer arranque. Medido en la caja: /store = 68,7 G, contra los 487 M de antes. Con eso el store de 55 G entra en el disco local y la mudanza no depende de mover el volumen de gioser.

6.4 ⚠ El muro de la puerta 3: la imagen trae 23 binarios que NO PUEDEN CORRER

Al ir a computar los grafos en la caja:

$ python3 -c "print(1)"
sh: python3: not found          ← y `command -v python3` decía /usr/bin/python3

No es que falte: está y no arranca. /usr/bin/python3.12 son 23 MB y es un ELF dinámico:

Requesting program interpreter: /lib/ld-musl-x86_64.so.1
NEEDED  libc.so

Y en toda la imagen no hay ningún cargador dinámico. Tampoco en el store: el artefacto musl publica sólo lo estático (libc.a, crt*.o, headers) — no hay libc.so ni ld-musl-x86_64.so.1 en ningún artefacto del corpus. Lo que hace que estos binarios funcionen en gioser es el rootfs Alpine del LAB, que sí lo trae (.dev-fs/alpine/lib/ld-musl-x86_64.so.1).

Es la fuga de needed-colgante-libstdcxx otra vez, y esta vez en el piso de abajo: sella, reproduce y no corre, porque pide algo que sólo existe en el laboratorio.

Contado sobre la imagen: 23 binarios inertes de 726 (703 estáticos están bien). Son la suite binutils entera (ar as ld nm objcopy objdump ranlib readelf strip addr2line c++filt elfedit gprof size ld.bfd), más perl, python3, sqlite3, flex y nft.

Por qué frena la mudanza y no es un detalle: todo el instrumental del proyecto es Python — build-state.py, targets.py, yupana.py, hydrate-profile.py, drenar.py, triaje.py. Un servidor takana no puede correr ni una de sus propias herramientas. La puerta 3 (los cuatro grafos) y la 4 (la granja) dependen de eso.

Y no se arregla de paso. Las salidas son tres y ninguna es barata:

1. Publicar el cargador — que musl emita libc.so + ld-musl-x86_64.so.1. Es lo correcto y lo más chico en concepto, pero toca un componente de Stage 1: mueve el baseline of_tree del selfhost y hay que rehacerlo a propósito, no de rebote.
2. Construir python/perl estáticos — el camino que evita el cargador, y es un frente propio: Python estático con módulos de extensión es notoriamente arisco.
3. Aceptar que el instrumental vive en el HUB y que el servidor sólo sirve. Es la respuesta honesta a corto plazo, pero contradice «mover allá todo lo que tengo acá»: el hub seguiría siendo gioser, que es justo lo que se quiere apagar.

Es decisión de ADR, y de las que conviene tomar mirando también el SDD 27 §4: las dos preguntas —«¿el cliente reproduce o hidrata?» y «¿el cliente puede correr lo que le mandamos?»— son la misma pregunta sobre qué es un sistema takana sin laboratorio.

6.5 ✅ El muro, derribado: el corpus publica su propio cargador (2026-09-11)

De las tres salidas del §6.4 el usuario eligió la 1 y la 2. Hecha la 1, que resultó ser más barata de lo que parecía y desbloquea la 2 en vez de competir con ella.

recipes/musl-shared.toml — variante dinámica de musl que publica /usr/lib/libc.so (4,2 M) y /lib/ld-musl-x86_64.so.1. En musl el cargador Y la libc son el mismo objeto.

Por qué una variante y no --enable-shared en la canónica, con su control: musl es componente de Stage 1 y su of_tree es el baseline de selfhost-verify. Tocarla obliga a rehacer ese baseline a propósito. Con el patrón *-shared —que el corpus ya usa 23 veces— la canónica no se mueve: takana hash recipes/musl.toml sigue dando b3:ce952f72…, el mismo sellado de Stage 1. Y además musl no es dep de nadie (medido: sólo de sí misma; el enlace estático lo resuelve el musl que trae zig), así que esto suma sin mover un solo ArtifactHash del corpus.

⚠ Y hubo que cambiar de compilador, medido

Con zig-cc el libc.so sale con 1586 símbolos dinámicos contra los 1654 del musl de Alpine, y los 68 que faltan son exactamente los que musl implementa en ensamblador x86_64 — memset, memcpy, memmove, memcmp, strlen y toda la familia matemática (ceil floor sqrt fmod exp log sin cos tan fma round trunc) — más los __stack_chk_*.

No es que no se compilen: en el libc.a del musl canónico están. Lo que pasa es que zig los resuelve con su propio musl y los deja FUNC LOCAL HIDDEN de tamaño 0, fuera de la tabla dinámica. El síntoma es un cargador que arranca, reloca y muere con memset: symbol not found — que se lee como «el binario está roto», no como «a la libc le faltan símbolos».

Con compiler = "gcc": 1651 símbolos, memset y ceil presentes.

El resultado, en la caja

antes	después
sh: python3: not found (con command -v contestando /usr/bin/python3)	Python 3.12.10
23 binarios inertes de 726	1

perl 5.040002, readelf/objdump/nm (GNU Binutils 2.45.1) y el resto corren. El único que quedaba era sqlite3, con Error loading shared library libz.so.1: la zlib canónica también es --disable-shared y nadie publicaba ese soname. zlib-shared ya existía sellado en el corpus — sólo faltaba declararla en base.

La salida 2 (python/perl estáticos) sigue viva y ahora es opcional, no urgente: con el cargador publicado el sistema ya no depende del rootfs del lab. Estático seguiría siendo mejor (un binario menos que puede quedar colgado de un soname), pero es un frente propio y ya no bloquea la mudanza.

6.6 Sembrar el hub: un hub no es repo+store, es repo+store+LAB

Con python3 vivo, takana hash en la caja seguía fallando:

Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
       El toolchain entra en el ArtifactHash ⇒ sin rootfs no hay hash comparable.

El lab es parte de la IDENTIDAD, no del entorno. Una máquina sin él no puede ni preguntar «¿cuál es el hash vigente de esta receta?», así que no puede computar el grafo ni decidir qué falta. Sembrado el lab (tarball pineado + tools/, bajo /store/dev-fs porque la raíz son 6 G), el hash testigo coincide byte a byte: takana hash recipes/zlib.toml da b3:dc363f26… en las dos máquinas.

⚠ Y la caja no podía desempacar su propio lab: el tar del rootfs es el de busybox y contesta tar: unrecognized option: zstd. La distro comprime todo con zstd —la imagen del lab, el respaldo, el dd remoto— y la imagen no traía el binario. zstd ya tenía receta sellada; declarado en base.

⚠⚠ Copiar un store con rsync -a es una fábrica de vacíos, y ahora se sabe POR QUÉ

La primera copia murió con No space left on device en un .so de Qt, dejando el destino al 100 % y 1367 de 1368 artefactos VACÍOS. La puerta 2 corrida EN EL DESTINO lo cazó en el acto.

La causa, medida:

medición sobre el store de gioser
du -sh (hardlinks contados UNA vez)	60 G
du -sh --count-links (hardlinks EXPANDIDOS)	85 G
.dmerge (la caché que hardlinkea al store)	11 G

rsync sin -H no preserva hardlinks: los expande en copias enteras. Así que «el store son 60 G» —que es lo que dice du y lo que uno planifica— se convierte en 85 G + lo que .dmerge expanda al otro lado. La partición de 68,7 G no tenía ninguna chance, y el modo de fallar es el peor: el disco se llena a mitad y quedan cientos de nombres de artefacto sin contenido, que el store da por presentes.

La copia correcta es rsync -aH --exclude='.dmerge': -H preserva los enlaces (60 G reales) y .dmerge no se copia porque es caché regenerable — la misma que ya llenó un disco en el worker.

La lección de método: du -sh sobre un árbol con hardlinks no dice cuánto ocupa copiarlo. Para dimensionar una copia hay que medir con --count-links, o preservar los enlaces.

Y el instrumental apunta al binario de DESARROLLO, no al instalado

La primera corrida de build-state.py en la caja devolvió 875 recetas unhashable — todas — con el lab bien sembrado y takana hash funcionando a mano. La causa:

HAMMER = os.environ.get("HAMMER", str(ROOT / "target/release/takana"))

Los scripts asumen un árbol de desarrollo: target/release/takana. En una caja instalada el binario es /usr/bin/takana y target/ ni existe (la siembra lo excluye a propósito). No falla ruidosamente: cada hash falla y el grafo sale entero como unhashable, que se lee como «este corpus no se puede hashear» y no como «no encontré el binario».

Se destraba con HAMMER=/usr/bin/takana STORE=/store, que la propia cabecera del script documenta. Pero la deuda queda anotada: el instrumental debería caer a command -v takana antes de rendirse, porque el caso «hub instalado» es justamente el que esta mudanza quiere que exista.

6.7 ✅ PUERTA 3 EN VERDE: los dos grafos, idénticos byte a byte

gioser: 7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605
caja:   7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605

base 61/61 · cli 84/84 · escritorio-mirada 41/41 · servidor 96/96 · falta 0, wanted 3 (chrony, cronie, logrotate — la deuda declarada), grafo CIERRA, topo-sort OK. Las dos máquinas.

Costó tres intentos, y los dos fallos son la parte que vale.

Intento 1 — unhashable 875, todas. Ver arriba: los scripts apuntan a target/release/takana.

Intento 2 — dos nodos divergentes: aichat y zola, sealed en gioser y never en la caja. No era deriva ni pérdida: ninguno de los dos está en disco en gioser tampoco. Son los «2 sellados que no están en esta máquina, avalados por los manifiestos» que el propio resumen imprime. build-state.py lee work/farm-sellados.txt y work/respaldo-sellados.txt — y work/ está gitignored, así que un hub recién sembrado no los tiene y degrada esos nodos a never sin que nada falle.

Es la misma familia que scripts/farm/.fleet: un fichero fuera de git del que depende una medición compartida. La regla que sale: sembrar un hub no es clonar el repo — es repo + store + lab + los manifiestos. Copiados los dos ficheros, los grafos coinciden exactamente.

6.8 Puerta 4: el camino de la granja, PROBADO; la cosecha completa, sin disco

Probado desde la caja (sin tocar el latido de gioser, todo de sólo lectura salvo el último paso):

• llevada la clave de la granja (~/.ssh/github5 → /root/.ssh/github5, 0600) y escrito scripts/farm/.fleet — los dos están fuera de git a propósito y hay que copiarlos a mano;
• la caja alcanza al worker: PruebasIA, load 3, 775 artefactos;
• estado-granja.sh corre allá y lee bien el worker y el avance KDE (198/199);
• y el paso que cierra el lazo: se cosechó un artefacto real del worker (speedtest-go, 12 M) con el mismo transporte de la granja, llegó con su .hammer/recipe.toml y su binario CORRE en la caja (speedtest-go v1.7.10). Worker construye → hub cosecha → binario ejecuta.

✅ CERRADA (2026-09-11) con el volumen takana-store

Resuelto el disco (§6.12), la cosecha completa corrió: 1369 → 1575 artefactos, 0 vacíos, que son exactamente los 206 que faltaban. 12,4 G por la red para 39 G lógicos —speedup 3.14, el ahorro de -H— y /store queda en 73,7 G de 97,9 (79 %).

⚠ El enlace con el worker va a 11 MB/s, no a los 90 MB/s de gioser↔caja: el LXC vive en el Proxmox de gioser, fuera de la red de Hetzner. Media hora para una cosecha de este tamaño.

⚠ Lo que faltaba no era mecanismo: era DISCO.

artefactos en el worker que la caja no tiene	206
a ~113 MB de media (el artefacto medio del corpus)	~23 G
libre en /store de la caja	3,7 G (61,5 de 68,7 · 94 %)

Una cosecha completa no entra, y forzarla repetiría exactamente el llenado que dejó 1367 artefactos vacíos hace un rato. La puerta 4 queda pendiente de una decisión de CAPACIDAD, no de una de ingeniería:

1. Enganchar harkaq-cosecha (250 G) a la caja. Es el plan original y no cuesta nada extra — pero hay que DESENGANCHARLO de gioser, y ahí vive el store, work/sources, los tarballs y el CARGO_HOME de la granja. O sea: es el cutover. gioser deja de construir en ese mismo instante, y hoy está moliendo el árbol KDE.
2. Un volumen nuevo para la caja (€0,052/GB/mes: 100 G ≈ €5,2/mes). No interrumpe nada y destraba la cosecha ya; se paga por duplicado hasta que gioser muera, y entonces se suelta.
3. Podar el store de la caja — deshace parte de la mudanza. No.

6.9 Puerta 8: los 19 dominios, sondeados uno por uno (2026-09-11)

El Caddyfile de gioser declara 19 sitios. Sondeados por DNS y por HTTP desde fuera, sólo 6 los sirve gioser de verdad:

dominio	DNS	HTTP	qué es
gioser.net · tawasuyu.net	gioser	200	VIVO — las dos landings
git.gioser.net · git.tawasuyu.net	gioser	200	VIVO — el gitea (aloja el origin de takana)
sergio.gioser.net · api.sergio.gioser.net	gioser	200	VIVO
summa · api.summa · dev.summa	154.197.1.2	200	YA MUDADOS a otra máquina: el bloque de Caddy en gioser es fósil aunque el sitio viva
api.gioser.net	gioser	502	backend caído
mail.sigma.gioser.net	gioser	502	backend caído
aura · api.aura · sigma · kosmofono · api.kosmofono	SIN DNS	—	fósil: ni DNS ni ficheros en /var/www
terapeuta.ec · andino.ec	SIN DNS	—	fósil con datos: 279 M en /var/www/terapeuta
gitea.gioser.net	SIN DNS	—	era un redir a git.gioser.net; inofensivo

Lo que esto cambia respecto del §1.1: no son «4 fósiles» sino 13 de 19 entradas que no hay que mudar — 8 sin DNS, 2 con el backend caído y 3 que ya viven en otra máquina. La superficie real a mudar son 6 sitios, y de esos el que pesa es el gitea, porque aloja el origin de takana.

✅ DECIDIDO (usuario, 2026-09-11)

fósil	decisión
aura · api.aura · sigma · kosmofono · api.kosmofono	mueren — ni DNS ni ficheros
gitea.gioser.net	muere — era un redir, y git.gioser.net lo cubre
api.gioser.net · mail.sigma.gioser.net	mueren — backend caído, sin dueño
summa · api.summa · dev.summa	no se mudan: ya viven en 154.197.1.2. Sólo hay que sacar sus bloques del Caddyfile al apagar gioser
terapeuta.ec · andino.ec	MUEREN — decisión explícita del usuario. Los 279 M de /var/www/terapeuta se van con la caja; no se archivan

⇒ De las 19 entradas del Caddyfile, 13 no se mudan. La superficie real es de 6 sitios, y el que pesa es el gitea porque aloja el origin de takana.

⚠ Que esto quede escrito ES la puerta: el día que se borre gioser, terapeuta.ec no va a poder recuperarse, y la diferencia entre «lo decidimos» y «se nos pasó» es este párrafo.

6.10 Puerta 7: el respaldo desde la caja — y tres bloqueos que sólo se ven corriéndolo

Llevadas las credenciales (~/.config/hammer/*.env, 0600) y la clave, la caja alcanza el Storage Box por el puerto 23 y lista su contenido. El manifiesto se refresca desde allá: 3140 artefactos, y de paso el script detecta 2 VACÍOS en el respaldo (gnome-desktop ×2) que excluye del manifiesto — su propia guarda, funcionando.

Para llegar ahí hubo que arreglar cinco cosas, y todas son de la misma familia: el instrumental asume que el hub es gioser. El --seco ahora completa los tres pasos desde la caja y lee la ocupación del box (111 G de 1 T).

1. La raíz cableada. RAIZ="${RAIZ:-/mnt/vvv/takana}" ⇒ desde cualquier otra máquina el script moría con cd: /mnt/vvv/takana: No such file or directory. Ahora se deriva de dónde está el script, como el resto de scripts/.

2. El binario de desarrollo. HAMMER = ROOT/target/release/takana (§6.7).

3. El store no estaba donde el script creía. Usaba $RAIZ/store cableado: en gioser es un bind-mount DENTRO del repo, pero en una caja instalada es una partición en /store ⇒ change_dir "/opt/takana/store" failed. Y rsync devuelve 23, que está en la lista de reintentables, así que el bucle insistía — el cuadro que la propia cabecera del script documenta («un error reintentable que se repite 40 veces no es un corte de red: es algo estructural»). Ahora STORE es env, con una guarda que aborta ANTES del bucle si la ruta no existe.

4. 🚨 Y una que habría costado el historial. El paso [2/3] sube el repo con --delete — correcto, para eso está git. Pero el /opt/takana de la caja llegó por rsync --exclude=.git: es una COPIA, no un clon. Una corrida real desde ahí habría borrado .git del Storage Box, o sea el historial entero, y en silencio: rsync haría exactamente lo que se le pidió. Añadida una guarda que aborta si la raíz no tiene .git (escotilla REPO_INCOMPLETO=1), probada en los tres sentidos.

   La regla que sale: un --delete convierte «respaldar» en «sincronizar», y sincronizar desde un origen incompleto no sube menos — BORRA. Cualquier respaldo con --delete necesita una guarda de completitud del ORIGEN, no sólo del destino.

5. El rsync del corpus no puede correr el respaldo del corpus. El script exige --compress-choice=zstd y recipes/rsync.toml lo construía con --disable-zstd — porque cuando se escribió, zstd no estaba en el catálogo. Hoy sí. Peor aún: el error 4 que devuelve rsync el script lo clasifica como «no de red» y no reintenta, así que el respaldo simplemente no se hacía. Arreglado por los dos lados: la receta enciende zstd (control: zstd zlibx zlib none vs zlibx zlib none; radio cero, rsync no es dep de nadie) y el script degrada a zlib avisando en vez de morir.

6.11 ⚠ La distro traía un git que NO PODÍA CLONAR

Para cerrar la puerta 7 la caja necesita un clon de verdad (el --delete del respaldo exige un origen completo, §6.10). Llevada la clave del gitea —que es ~/.ssh/tawasuyu, no la de la granja— git ls-remote contesta… y git clone muere:

fatal: fetch-pack: invalid index-pack output

El informe completo, que la traza corta escondía:

panic: load of misaligned address 0x… for type 'const uint32_t',
       which requires 4 byte alignment
  in sha1_compression_states → sha1_process → SHA1DCUpdate → git_SHA1DCUpdate
  → git_hash_update → unpack_entry_data → cmd_index_pack

Dos causas, encadenadas:

1. -fsanitize=undefined estaba en CFLAGS, no sólo en LDFLAGS. El motivo original era legítimo —las libz.a materializadas traen referencias __ubsan_handle_* que bajo -static no se resuelven solas, y el flag al enlazar trae el runtime de zig— pero en CFLAGS instrumenta el código de git. Un arreglo de ENLACE convertido en una mina de RUNTIME, justo en la ruta de hash: por donde pasa todo lo que git recibe.
2. sha1collisiondetection lee palabras de 32 bits SIN alinear. Es el backend SHA1 por defecto de git, el que detecta SHAttered. En x86 la lectura desalineada funciona y por eso nadie lo nota jamás; según el estándar es UB, y basta con que el runtime ubsan esté enlazado para que aborte. -DSHA1DC_FORCE_ALIGNED_ACCESS lo hace leer byte a byte: quita el UB en la fuente en vez de esconderlo.

Con las dos: git clone --depth 1 del propio repo desde la caja ⇒ 877 recetas. Radio cero (git no es dep de nadie), pero sí es raíz de perfil.base ⇒ esto arregla la distro entera.

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.13 ✅ takana upgrade, probado de verdad — y el bug de durabilidad que destapó

§6.12 dejó dicho que el camino de actualización de una caja instalada es takana upgrade, no dd ni hydrate. Probado con un paquete que la caja realmente necesitaba: zstd.

paso	resultado
upgrade apply …-zstd-cli	✓ generación 2 aplicada · + 1 añadidos, ~ 1 pisados, - 8 retirados
la prueba de uso	zstd -dc lab-image.tar.zst | tar -xf - ⇒ la caja desempaca su propio lab
upgrade rollback	✓ generación 2 revertida · 9 restaurados, 1 borrados — zstd se va, libzstd.a vuelve
re-apply + corte duro sin sync	sobrevive: generación viva 1, manifiesto íntegro

✔ Y cruza la frontera que hydrate no puede: el store está en el volumen y / en el disco local, y upgrade copia en vez de enlazar. Es, de hecho, el único camino que funciona en una caja instalada.

⚠ El bug: write_atomic era atómico pero NO DURABLE

El primer intento pareció funcionar y se perdió al reiniciar. La caja volvió con:

pending.json                   0 bytes
generations/2/manifest.json    0 bytes
upgrade status  → Error: json: EOF while parsing a value
upgrade recover → Error: json: EOF while parsing a value

write_atomic hacía temporal + rename: atómico frente a otros PROCESOS, no frente a un CORTE. rename sobre un fichero cuyos datos siguen en caché deja, tras el corte, la entrada apuntando a bloques nunca escritos — cero bytes. Y hcloud server reset es un corte duro, no un apagado limpio: ahí está la mitad operativa de la lección.

Lo grave no es perder un upgrade: es que recover —que existe exactamente para «un apply interrumpido por un corte»— abortaba con la huella más probable de ese corte.

Arreglado: fsync del temporal antes del rename y fsync del directorio después (hacen falta los dos), y un pending.json vacío se reporta como PendingCorrupt, nombrando el corte y apuntando al árbol de respaldos. Con tests y su control.

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: 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.

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 un catálogo de software real en producción, y cada servicio que hoy corre sobre binarios de Artix es una receta candidata con un caso de uso comprobado detrás:

lo que corre hoy en Artix	receta
caddy	✅ existe (recipes/caddy.toml)
openssh	✅ existe
gitea	✅ SÍ existe (recipes/gitea.toml) y está sellada (35bb4f04…) — ver la corrección abajo
qdrant, squid, fail2ban, php-fpm, metalog, glances	✗
chrony, nftables, cronie, logrotate	✗ — ya declaradas wanted en perfil.servidor

CORRECCIÓN (2026-09-11). Esta tabla decía que gitea NO tenía receta y que «es la que más peso tiene». Las dos cosas eran falsas: recipes/gitea.toml existe desde el 2026-09-09 y su artefacto está sellado. Lo escribí de memoria, sin mirar el catálogo.

Lo destapó planear.py al cruzar cada binario contra recipes/: de los servicios de gioser, 4 ya tienen receta takana y están sellados (caddy, gitea, python3…), 4 vienen de un paquete ajeno y 11 son binarios sueltos sin dueño. Ésos últimos son el trabajo real, no gitea.

Es exactamente para esto que la herramienta existe: yo afirmé de memoria y el programa fue a mirar.

Cada una que se cierre se prueba sola: el servicio o levanta en la caja nueva o no, y eso se ve el mismo día. Es la diferencia entre una receta «sellada» y una receta usada.

---

7. Reusar los scripts que ya existen, y no escribir de nuevo

Pedido explícito del usuario. El inventario de lo que ya hace el trabajo:

para	script existente	qué le falta
armar el rootfs de un perfil	scripts/hydrate-profile.py	nada — es el camino bueno (los hydrate-*.sh por escritorio divergen de targets.toml)
producir el .img	scripts/install-image.sh / scripts/product-image.sh	apuntar al perfil.servidor
escribir a disco	scripts/takana-install.sh	el envoltorio de rescue del §3.2
instalador con TUI	scripts/takana-live-install.sh	ser el mismo motor que el remoto, con las respuestas por fichero
provisionar un worker	scripts/farm/vps-setup.sh	ya soporta apt y dnf; le falta la rama «takana puro» (sin gestor de paquetes ajeno)
enchufar a la granja	scripts/farm/.fleet	está en .gitignore ⇒ un hub recién clonado nace con la flota vacía en silencio
latido	scripts/farm/cosecha-cron.sh	decidir cron vs tarjeta de arje (§3.4)
respaldo	scripts/respaldo-storagebox.sh	nada — es interrumpible y continuable
absorber el init ajeno	arje-absorb	el lector de procesos vivos (§4)

⚠ Un motor, tres frentes. La tentación es escribir el instalador remoto aparte del TUI. Ahí es donde divergen: ya pasó con los hydrate-*.sh contra targets.toml, y con la unidad systemd del worker que quedó vieja mientras el repo estaba al día. La instalación remota tiene que ser la misma que hace la persona, grabada en un fichero de respuestas.

---

8. churay como instalador centralizado — la dirección, no la decisión

El usuario lo planteó el 2026-09-09: un instalador único, con CLI y TUI, que sirva para

• las apps de tawasuyu,
• paquetes sueltos en cualquier distro, al estilo nix (instalar sin ser root, sin tocar el sistema anfitrión),
• takana mismo,
• y llimphi.

Encaja con lo que ya hay y por eso vale escribirlo: takana install ya resuelve por nombre contra un índice firmado y ya acepta múltiples orígenes; qorpa (ADR 0015) ya corre imágenes ajenas enjauladas sobre el mismo kernel; y el vigía de espejos de churay ya corre en cron desde gioser.

No se decide acá. Es un ADR propio, y tiene al menos tres preguntas abiertas antes de escribir una línea: (1) si el instalador «en cualquier distro» hidrata binarios o reproduce desde fuente —la misma pregunta del SDD 27 §4, y la respuesta puede no ser la misma fuera de takana; (2) quién es el dueño del verbo, si takana install crece o si churay lo envuelve; (3) qué pasa con un host glibc, que es exactamente lo que el ADR 0015 aparta del store a propósito. Queda anotado para que se decida, no para que se descubra a mitad.

---

9. Estado y orden

paso	estado
0. perfil.servidor + este documento + el renombre hammer-* de los instaladores	✅ 2026-09-09
1a. caja de sacrificio creada — cx33 (no había cx53), hel1, §3.5	✅ 2026-09-10
1b. imagen del perfil.servidor + rescue → dd → arranca takana puro (§3)	✅ 2026-09-10 — puerta 1 pasada, §3.8
2a. clave estable + receta de takana + repo firmado servido por la caja (§5.1)	✅ 2026-09-10
2b. que el host se actualice DESDE su propio repo (§5.4)	🚧 bloqueado por la decisión de SDD 27 §4: install reproduce, y eso exige el lab entero
3. mudanza con las 8 puertas del §6, y recetas nuevas del §6.2	pendiente
4. la utilidad de absorción (§4), estrenándose con esta migración	pendiente
5. churay como instalador centralizado (§8)	ADR propio, sin decidir

El volumen del store NO se engancha a la caja nueva hasta que pase la puerta 1. Una caja de sacrificio con el store dentro deja de ser de sacrificio.