El banco POSIX de 57 casos lo pasa brush 56/57 y aun así no construye una
receta autotools: mide lo que a uno se le ocurrió preguntar. Este pregunta si
el candidato hace LO MISMO que el control sobre el material que hay.
- compara (rc, stdout, árbol de ficheros producido); stderr es aviso, no
divergencia — el texto de error diverge legítimamente
- el árbol es la columna que faltaba: el caso 10 diverge SÓLO ahí, que es la
clase de bug del libtool mal escapado (rc=0, stdout idéntico)
- toda divergencia se confirma re-corriendo control y candidato: separa caso
no determinista de shell inestable de divergencia real
- fuentes: fixtures de regresión, generador de tortura de comillas, las 1130
fases del corpus y configure/libtool reales en sh -n
Medido, 1273 casos en 5,5 s: brush 35 duras, bash 8, y CERO en los 1156 casos
de parseo. El generador saca el #1394 entero sin conocerlo. Hallazgo nuevo:
brush no ejecuta nunca el trap EXIT de un subshell — y eso golpea el frente
del PRODUCTO, donde el veredicto del paso 3 decía que no había evidencia en
contra.
Se ensamblaron dos Stage 1 completos y se arrancaron los dos, para que cualquier
diferencia se atribuya al recorte y no al azar:
base b3:1a3823b4... 400 applets qemu rc=0
recortado b3:3aa8cd2d... 278 applets qemu rc=0
Los dos dan shell y se apagan limpio. El diff de las dos consolas son 35 líneas y
ninguna es funcional: TSC, direcciones del RAMDISK, BogoMIPS, hora del RTC. La única
diferencia real es el conteo de applets desde dentro de la imagen: 410 contra 288.
Verificado en el recortado: arje-zero como PID 1, la seed card carga (la getty llegó
a incarnar), getty -l /bin/sh da prompt y responde, y poweroff -f apaga de verdad
-- uno de los cinco indultados, probado en vivo.
Corrido en el worker con QEMU en TCG: el LXC no expone /dev/kvm. Hubo que instalar
qemu-system-x86-core y reingerir la semilla de Stage 0, que no estaba en ese store y
salió con el mismo hash que el manifiesto ya anotaba.
Es Stage 1, no el producto: product-boot-test.sh sigue pendiente porque al store del
worker le faltan netup, openssh, uutils, findutils-xargs, diffutils y ripgrep.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El nombre está dado de alta en la zona de Hetzner con la convención de la zona (A, ttl 60, la misma
IP que takana/git/gitea/www). Resuelve — comprobado contra Cloudflare; el resolutor de Google aún
servía el NXDOMAIN cacheado, que es negativo de 1 h por el `minimum` del SOA y no un fallo del alta.
⚠ La API vieja de DNS de Hetzner (dns.hetzner.com/api/v1) ya no es la buena y devuelve HTML de la
consola web, que es lo peor que puede devolver: no falla, contesta. Las zonas están hoy en la API de
cloud y las lee el MISMO token de ~/.config/hcloud/cli.toml (gioser.net = zona 986350).
Hoy el nombre resuelve y no sirve nada: falta el vhost, que es root. `publicar-repo.sh` hace la
parte publicable —repo firmado en /srv/repo + verificación contra trust/— y para imprimiendo el
bloque de Caddy en vez de editarlo: esta caja sirve 19 dominios y su Caddyfile ya lleva 20 `.bak`.
Y aborta antes de publicar si el takana de la caja es anterior al arreglo del SDD 28 §5.5 (se
detecta porque no conoce `outdated`): con uno viejo el repo sale con las 16 recetas multi-parche
irreproducibles y 8 paquetes prometiendo un binario que no existe.
El control que agregué en el commit anterior era el natural y estaba mal: publicar el perfil
`servidor` entero con él dejó 65 de 175 paquetes fuera, porque son LIBRERÍAS (zlib, ncurses,
openssl, musl-*, gmp…) que no traen ningún binario y existen para que otros las resuelvan como
dep — un campo que su consumidor ni mira habría tirado un tercio del repo. Lo destapó el barrido,
no el razonamiento: la versión que abortaba pasaba los tests igual.
Ahora: corrige el path si el binario quedó en otro bindir (que es el caso que importa), y si no
hay ninguno lo dice y publica igual.
Medido con el perfil `servidor`: 162 publicados y firmados, 8 con target_bin corregido (bash, sed,
tar, parted, dhcpcd, squid, wpa_supplicant, zsh — todos publicados hasta hoy prometiendo un path
que no existe), 64 sin binario, 12 sin sellar en este store, 1 fallo (os-release, ya conocido).
Contra el repo firmado por HTTP: parted (6 parches + binario en /usr/sbin) instala en 0,17 s y
responde 3.7; bash responde 5.3.0(1).
Queda vivo: `install <librería>` directo sigue fallando tras hidratar (el .swm exige que el
target_bin exista). Hacer el campo opcional toca el formato — su propia unidad de trabajo.
Corre `takana outdated --json` contra el índice firmado y deja el resultado en un fichero de
estado. No actualiza nada: instalar es reproducir y verificar, y eso no se cuelga de un cron — el
aviso dice qué comando correr.
Tres cosas deliberadas:
· Sólo grita cuando la LISTA de novedades difiere de la del ciclo anterior. Un guardián que repite
lo mismo cada 30 min se deja de leer, y entonces no avisa de nada.
· La huella es nombre+versión publicada, no el JSON entero: éste trae contadores que se mueven
solos y harían «cambiar» un estado idéntico.
· Un repo caído NO se resume en «al día»: lo dice, sale ≠ 0 y conserva el último estado bueno.
Probado en los tres caminos contra un repo servido por HTTP en la caja.
Cerrar el lazo servir→instalar sobre `zsh` (pedido del usuario) destapó dos fallos de la familia
del `strip_debug` del SDD 28 §5.2: cosas que el `.swm` no transportaba fiel y que sólo se ven
cerrando el lazo, no leyendo el código.
1. `pack` CONCATENABA los N parches en el `patch` inline único, y `hash_inputs` mete una entrada
por parche (con `of_inputs` length-prefijado) ⇒ el receptor sellaba en otra dirección y el
`expected_hash` no coincidía NUNCA. Medido: zsh anclado b3:0be3630d…, reproducido b3:d6329a62…
(idéntico al de una copia de la receta con sus 6 parches concatenados a mano). Afectaba a las
16 recetas del corpus con ≥2 parches. Ahora viajan como lista `patches`, en orden, un fichero
por parche del lado del receptor; el `patch` único se sigue leyendo para no invalidar lo
publicado. Regresión con control negativo en swm_bridge.
2. `target_bin` se adivinaba `/usr/bin/{name}`; zsh instala en `/bin` (--bindir=/bin), así que el
paquete prometía un path que el artefacto no tiene y el error salía en el cliente DESPUÉS de
hidratar 1331 ficheros. Con `--build` el artefacto está delante: se comprueba, se corrige
diciéndolo, y si no hay ningún binario con ese nombre se ABORTA al publicar.
Y el verbo que faltaba para «avisame cuándo actualizar»: `takana outdated` compara la DB de
instalados con el índice firmado (por hash, no por versión: una re-publicación con la misma
etiqueta es otro artefacto). No construye, no baja .swm y no actualiza — instalar es verificar.
Medido tras el arreglo: install zsh ⇒ cache-hit del hash anclado, 1331 ficheros en 0,14 s, zsh 5.9
corriendo.
Paso 1 de docs/plan-botar-busybox.md. 124 applets fuera del defconfig: los 105 que
no se reemplazan (dpkg, rpm, httpd, telnetd, ubi*, nand*, i2c*) y 19 cuya función ya
hace otro componente (init/runit -> arje-zero, syslogd/klogd/logread -> hammerd).
Binario de 1.230.976 a 977.096 bytes.
CORRIGE UN ERROR DEL PLAN: arje-zero y hammerd reemplazan la FUNCIÓN, no el COMANDO
-- son un binario cada uno. Por eso 5 indultos: setuidgid (la card de gitea lo
ejecuta), switch_root (el /init del instalador, antes de que arje exista) y
poweroff/halt/reboot (nada más en el corpus apaga la máquina).
scripts/busybox-vigia.py falla si alguien invoca un applet retirado; lee la lista de
la propia receta para que no haya dos que se desincronicen. Su primera versión daba
91 hits y ninguno real: las cuatro reglas que lo bajaron a 0 están documentadas.
El mapa applet->símbolo sale de las líneas //applet: del fuente, no de poner el
nombre en mayúsculas: eso falla en 6 casos medidos, dos de ellos en la lista.
Verificado: 277 applets exactos, los 5 indultados presentes, y zlib-ng, jq y
logrotate reconstruidas y selladas con el busybox recortado -- el sandbox sigue en
pie. Son 3 de las 24 dependientes, no las 24, y el boot de la imagen no se probó.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bajando al config.status que genera el libtool apareció el mecanismo, y es de una
línea: brush aplica a `...` las reglas de $( ). POSIX manda que dentro de comillas
invertidas la barra se ELIMINE cuando precede a $, ` o \ (2.6.3). Que el caso con
$( ) sí esté bien es lo que delata la causa.
Por eso rompe libtool: el case que decide si cada variable necesita escapado evalúa
a cadena vacía bajo brush, así que todas caen en la rama sin escapar. El configure
termina bien; el fichero sale mal escrito.
Se construyó main de hoy (737dd57e, cuatro meses y medio sobre nuestro pin) y
reproduce idéntico los cuatro casos ⇒ adelantar el pin no arregla nada.
Reportado: https://github.com/reubeno/brush/issues/1394
Y la recomendación: no pelear el shell. Los pasos 1, 2 y 5 del plan no dependen de
él y valen 129 applets y dos piezas de userland.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Medido en el worker, con el único cambio de /bin/sh en una copia por hardlinks del
lab (sed/grep/awk siguen siendo busybox) y stores tirables. Control busybox: 3/3
recetas selladas. brush: 0/3.
Lo que pasa: 56/57 del banco POSIX (igual que busybox), 0 rechazos sobre las 1130
fases de shell del corpus, parsea el configure de ffmpeg, funciona como argv[0]=sh
y con el patrón de las cards de arje.
Lo que falla: el configure corre entero pero el libtool que GENERA sale con un
nivel de escapado de menos en 25 líneas, y ese fichero ya no lo parsea ningún
shell. El parser de brush está bien — parsea sin quejarse el libtool del control.
Mecanismo exacto no determinado: echo, sustitución de comando y el propio
func_quote_for_eval de libtool dan idéntico en ambos shells aislados.
Y un dato independiente del bug: 813us de arranque contra 91us de busybox (8,9x),
sobre decenas de miles de shells por configure. El binario son 7,25 MB contra los
1,23 MB del busybox con sus 401 applets.
De paso: brush selló con el mismo hash que traía build-state del otro hub.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §7.undecies dejó la bóveda declarada y a NADIE capaz de abrirla: ninguna
imagen traía un binario que sembrara `pacha_llavero::SEED_IDENTIDAD`. Esta es
esa unidad.
De las dos formas posibles entra `agora-cli`, y el motivo no es que sea mejor:
el wizard `churay-welcome-llimphi` SÍ tiene binario (medido: `src/main.rs` sin
`[[bin]]`, o sea que cargo lo descubre), pero decide además backend de IA,
dotfiles, fondo de pantalla y chasqui — la experiencia de primer arranque
entera, que no se decide dentro de una unidad del navegador.
⚠ Y antes de poder declararlo apareció lo que lo volvía imposible: sin
`AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo
"agora-dev" con un aviso por stderr y un ✓ en pantalla. La cadena que eso toca:
frase → Argon2id → ChaCha20-Poly1305 que cifra la seed → la clave con la que
`boveda` descifra su base. O sea, en una imagen de escritorio, la bóveda de
todo el mundo cerrada con una palabra escrita en el fuente, y nada que falle.
Arreglado en tawasuyu (`fd08dc03a`): variable > terminal (se pregunta, sin eco,
y DOS veces en la génesis, donde un error de tipeo no se nota hasta que la seed
ya no se recupera) > desarrollo sólo si no hay a quién preguntarle. La decisión
vive en una función pura con cuatro tests, probada AL REVÉS: con el brazo
`Preguntar` borrado falla con `left: Desarrollo / right: Preguntar`.
Pin `9967b02c` → `da5fb8968` ⇒ `b3:46529e14`, 1,9 M, sellado en el worker con
la guarda PEGADA al build. Mirado por dentro (regla 3) y probado como
artefacto, con control negativo: `identity new` + `unlock` deja
`user pacha:id:default: 32` en `/proc/keys`, y con la frase equivocada contesta
«autenticación fallida» y NO re-siembra.
El muro del `Cargo.lock` por cuarta vez, con la causa cambiada: esta vez no la
puso quien tocó el lock sino otro agente que metió `shuma-taller` en un
`Cargo.toml`. Cerrado en el worker, donde el registro está completo: +1 línea.
Y el lock del árbol compartido traía otra vez el malo (índice y árbol con dos
versiones distintas, las dos rotas), así que el commit se armó con
`commit-tree` sin pasar por el índice.
Corrección al §7.undecies: el verbo es `agora-cli unlock`, no
`agora-cli identity unlock`.
El guardián de coherencia pasa de SEIS lugares a SIETE, con su cuarto control
negativo; los cuatro, en verde.
Queda: la herencia del llavero de SESIÓN entre procesos hermanos (sin medir —
y `/proc/keys` como root no la mide), y `pacha`/`pacha-secretos` en
`perfil.servidor` con el mismo hueco.
`cargo vendor --locked` sobre `fd08dc03a` muere con «cannot update the lock
file»: le faltaba la arista `shuma-taller`, que otro agente había metido en un
`Cargo.toml` sin el lock. Es la cuarta vez que este monorepo pone el mismo muro
(SDD 26 §7.quinquies.bis, §7.octies, §7.undecies).
Cerrado en el WORKER —sobre el árbol que takana ya había bajado, que es donde el
registro de cargo está completo—: +1 línea, cero checksums movidos. En la jaula
la misma operación devuelve 0 y borra miembros del workspace, con un diff que se
ve más mínimo que el correcto.
hash: b3:6520470e → b3:46529e14
La unidad 12 del SDD 26 quedó en esto (§7.undecies): la bóveda entró a las
cuatro imágenes y NADIE puede abrirla, porque ninguna trae un binario capaz de
sembrar `pacha_llavero::SEED_IDENTIDAD`. `agora-cli` es el único del corpus que
sabe hacerlo — y estaba sellado con `perfiles: []` y pineado al 2026-06-18,
donde el verbo todavía no existe (`git grep` sobre el pin: 0 y 0, con HEAD de
control dando 4 y 1).
Sube a `fd08dc03a`, que además trae el arreglo que este oficio vuelve
obligatorio: sin `AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de
desarrollo "agora-dev" con un aviso por stderr y un ✓ en pantalla. En una
máquina de trabajo es cómodo; en una imagen de escritorio es la bóveda de todo
el mundo cifrada con una palabra pública, porque el keystore va con Argon2id +
ChaCha20-Poly1305 bajo esa frase. Ahora con terminal se pregunta, sin eco y dos
veces al crear; la de desarrollo queda sólo para el caso sin terminal.
Y con el pin nuevo hace falta `cargo_vendor_dir`, que el pin viejo no
necesitaba: tawasuyu commitea su propio `vendor/` desde entonces.
hash: b3:e05c41f1 → b3:6520470e (sin construir todavía)
Medido contra el artefacto sellado (401 symlinks) cruzado con build-state.json:
148 applets ya tienen dueño sellado Y en perfil, 125 tienen dueño sellado que no
viaja en ninguna imagen (uutils, brush, findutils, diffutils, arje-zero, hammerd),
y de los 128 sin dueño 105 son basura que se borra.
Dos hallazgos que cambian el plan: busybox entra a los 7 perfiles como dep de BUILD
de 24 recetas, no como raíz de producto en targets.toml; y brush (shell Rust) ya
está sealed, sin validar y sin perfil.
docs/state/busybox-applets.tsv es la tabla applet-por-applet (generada), con 24
parejas marcadas NO-drop-in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`work_root` sale de `dirname(store)/work`, y con el store en `/store` el padre es `/`: todo el
scratch iba al overlay de 69 G de la jaula, que además es capa DESECHABLE — la caché de fuentes
vivía en algo que se tira. Mientras tanto `/dev/sdc`, 255 G, estaba al 9 %.
De los 6,8 G de `work/sources`, 5,4 G eran DOS COPIAS del mismo commit de tawasuyu: los árboles se
nombran por receta, no por commit, así que cada receta del monorepo cuesta otros 2,7 G. Queda
anotado que es deliberado (aislamiento del ADR 0012) y que no se deduplica de paso.
Arreglado con enlaces a `/work/sergio/work` en vez de con `TAKANA_WORK`: el override existe y
funciona, pero una docena de scripts llama a `takana build` y un export que hay que recordar se
olvida. Comprobado con un build real sin ninguna variable — rc=0, el árbol cayó en sdc y el hash
salió idéntico al de la corrida anterior. Overlay de 6,9 G a 14 G libres.
Anotado también que el worker NO tiene este problema (un solo disco de 196 G), que los enlaces se
van si la jaula se rehace, y que la premisa del `seal` (rename atómico ⇒ mismo filesystem) ya
estaba rota en el hub antes de esto, porque `/work` y `/store` son discos distintos.
Cierra el renglón que quedaba en vuelo cuando se commiteó la sección: `boveda` `b3:5c43a827` (22 M)
y `shuma-pregunta` `b3:cd4277c5` (21 M), selladas en el worker.
Y miradas por dentro, que es la regla 3: el árbol del artefacto trae el binario, el `.desktop` del
§7.decies y nada más, y `strings` encuentra en el ELF el aviso del arreglo («NO se levanta el socket
del navegador»). Que el arreglo esté en el commit no dice que esté en el binario: es exactamente la
lección del §7.quinquies, donde el host conocía los verbos y la función igual no existía.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Seguir con lo que el §7.decies dejó abierto —quién levanta la app, de dónde sale la raíz de las
claves— terminó en una respuesta incómoda y en un bug que valía la pena encontrar.
La cadena, medida hacia atrás desde la app:
· `raiz_de_identidad()` saca la seed del llavero del KERNEL (`pacha_llavero::SEED_IDENTIDAD`);
· la escriben dos lugares en todo tawasuyu: `agora-cli identity unlock` y `churay-welcome-runner`;
· `agora-cli` está sellado y en `perfiles: []` — en ninguna imagen. Y aunque se declarara, su pin es
del 2026-06-18, donde no existen ni `SEED_IDENTIDAD` ni `desbloquear` (git grep sobre el pin, con
HEAD de control: 4 y 1 aciertos);
· `churay-welcome` no tiene receta en takana.
⇒ en ninguna imagen hay un binario capaz de sembrar la identidad. No es que el usuario no la
desbloqueó: es que no tiene con qué.
Y lo que el navegador veía NO era «cerrada». Cuando `abrir()` falla, la app levantaba el socket
igual, sobre `bóveda_imposible()` —un sled en /tmp/boveda-sin-abrir-<pid>—, así que la extensión
recibía `locked:false, count:0` y un `vault.save` consentido guardaba en un temporal que muere con
el proceso. La ventana decía la verdad; el navegador, lo contrario. Arreglado en tawasuyu
(`7917fbb96`) con test de regresión en los dos sentidos, y probado al revés: con el `if`
neutralizado, el test falla con el mensaje que corresponde.
Pin de las dos recetas a `6f0408d40`, que trae además el `Cargo.lock` cerrado. Ahí apareció la
vuelta que no estaba escrita: la «operación mínima» del §7.octies (`cargo metadata` sin `--locked`)
corrida en una jaula con el registro de cargo INCOMPLETO devuelve 0 y deja un lock al que le faltan
dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto (−15 líneas contra +1). Que
diera byte a byte igual al de otra sesión no lo confirmaba: las dos se calcularon con el mismo
instrumento roto.
Y una trampa más, medida hoy: la guarda de receta del §7.quinquies.bis NO alcanza para una TANDA.
Puesta una vez al principio, `shuma-pregunta` selló bien y `boveda` —once minutos después— dio
«artefacto ya en el store» sobre la receta VIEJA, porque el latido revierte el árbol del worker en
el medio. La guarda va pegada a CADA build, y la cura de fondo es publicar la receta antes de
construir.
De paso, dos correcciones a lo que este mismo frente escribió hace unas horas:
· el `app_id`: llimphi SÍ lo pone (`with_name`, con el nombre del ejecutable de piso) ⇒ la ventana
es `boveda`, igual que el basename del `.desktop`, y por eso no hace falta `StartupWMClass`. Lo
que sí queda mal es el TÍTULO, que dice «llimphi»;
· el GL: que las imágenes sean iris-only no es una decisión pendiente sino una escrita (SDD 14), y
el caso de la VM ya tiene camino — los runbooks montan `mesa-llvmpipe` como capa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio