El diseño es la parte que vale: NO SELLA NADA. Modificar una receta le cambia el ArtifactHash, así
que medirlo a lo bruto habría dejado una docena de duplicados basura en un store que se respalda. En
vez de eso se inyecta `set -e` en cada fase Y un `exit 77` al final de la última: el build siempre
falla, nunca sella, y el veredicto se lee en el código de salida — 77 significa que todas las fases
corrieron enteras bajo set -e. Queda en scripts/farm/exp-ec.sh.
Muestra de 12 recetas ligeras (los pesos pesados quedan fuera por tiempo, y el sesgo va declarado):
10 sobreviven sin tocar nada, 1 se rompe, 1 inconcluso por timeout.
El que se rompe es `e2fsprogs`, y mirarlo de cerca cambia lo que significa: su ./configure aborta con
`external uuid library not found` pese a que la receta pasa --disable-libuuid, y hoy eso se traga
—comprobado: la misma receta sin set -e y con exit 77 LLEGA al 77—. Pero el artefacto que sella está
bien: 149 ficheros con e2fsck, mke2fs, los cuatro fsck.ext* y los mkfs.ext*. O sea que ahí `-ec` no
atrapa un bug: rompe una receta que funciona. Ése es el coste, y es el número que no se podía
adivinar leyendo: ~8%, unas 8 recetas sobre las 96 expuestas.
También se corrige el recuento: 96, no 89. El 89 salía de restar 142−53 dando por hecho que las 53
con `set -e` propio estaban todas dentro de las 142, y no lo estaban.
jaula-preparar suma lo que hizo falta para poder correr todo esto desde adentro: rsync/python3/jq/
cargo enlazados del store, y el cargador de musl, sin el cual python3 y cargo no arrancan en una
imagen glibc.
Medido al construir `wtype` en la caja: su fase de install empieza con `set -e` puesto a mano por el
autor. No es la única — 53 de las 142 recetas con fase multi-comando hacen lo mismo.
Son dos datos. Uno: nadie escribe `set -e` en 53 recetas por gusto, se escribe después de que algo
selle mal, así que el default ya estaba pagándose de a una. Dos: esas 53 ya corren bajo `set -e` y
no romperían con `-ec`, o sea que la migración es sobre las 89 restantes y la muestra del
experimento sale de ahí, no de las 142.
El usuario chocó con Resource busy al abrir un segundo agente y lo llamó por su nombre: «no quiero
restricciones arbitrarias». Conviene separar las tres cosas, porque desde afuera se sienten igual.
Del kernel: dos overlays sobre el mismo upper los niega overlayfs, no nosotros. Eso no se toca.
Nuestro: una instancia por persona, de ahí «un solo Claude» — y instancias distintas conviven; crear
la segunda cuesta 0 s y 16 K porque la imagen se comparte de sólo lectura. Accidentes, ya
corregidos: el directorio de instancias era root-only (una persona no podía crear la suya), ~/.ssh
iba ro, /store iba ro (el agente no podía sellar), claude abría /opt/takana siempre y /usr/bin/claude
era una copia congelada.
Y queda un defecto real que hoy bloquea la segunda instancia: aprovisionarla muere con «Can't mkdir
parents for /run/user/0». Medido: esta caja no tiene /run/user —no hay logind— y qorpa arma esa ruta
sin alternativa; XDG_RUNTIME_DIR no alcanza porque lo honra otra rama. Es arreglo en el crate.
La distinción que importa: la jaula restringe al agente, no a la persona —sergio tiene sudo y manda
en la caja—, y dentro de la jaula el alcance es declarativo. Lo indefendible no es que haya límites:
es que un límite accidental parezca de diseño.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sale de construir `zsh`. El agujero es estrictamente el de los comandos NO FINALES de una fase: el
estado de salida de `sh -c` es el del último comando, así que `make … install install.info` podía
morir con `makeinfo: not found` y el artefacto sellaba con `/usr/share/info` VACÍO adentro.
Medido, no supuesto: 144 logs del worker, 88 sellados, 4 con fallo de alta señal. Clasificados uno
por uno da UN hueco real confirmado (zsh, ya reparado en 3b36e9df), uno que NO lo es (python3: ahí
takana SÍ abortó, porque el `make` era el último comando de su fase) y uno inconcluso (strace, en
logs multi-receta donde el target que falla no se puede atribuir).
Ese caso de python corrige mi propio encuadre inicial, que decía «las fases sellan con huecos
silenciosos» a secas y era demasiado amplio. Queda escrito en el ADR porque la versión amplia manda
a buscar el bug donde no está.
Exposición medida: de 943 recetas, 142 tienen fase multi-comando escrita a mano. Las ~800 restantes
NO están expuestas — usan las fases de `resolve_phases`, que encadena con `&&` y sí propaga.
La decisión (`-ec` o no) queda ABIERTA a propósito: falta el único número que importa, que es
cuántas de esas 142 dejan de sellar bajo `-ec`, y eso no se saca leyendo sino reconstruyendo.
Cambiar el default a ciegas sobre 1115 sellados es el reflejo que este repo evita.
Primer informe hecho DESDE la jaula, y vale más que cualquier inspección desde el anfitrión porque
son las cosas con las que se choca al usarla. Queda registrado qué se arregló y —lo importante—
DÓNDE vive cada arreglo: 1 y 2 en el upper, que es caché descartable, y por eso hay un guion que los
repone tras cada recreate; 3 y 5 en el manifiesto; 4 en el worker.
Del 4: se autorizó la clave de la caja, no la de root — credencial distinta y revocable. Del 5:
takana NO se compila adentro; el binario es el musl del store, y lo que fallaba es que el
target/release del anfitrión enlaza a /usr/bin/takana, que adentro es el de Arch.
Y las tres trampas de orientación que el agente reportó: el store real es /store y los runbooks dicen
./store porque están escritos para el hub; hay dos checkouts y no son intercambiables; y el .fleet
ausente no es defecto, lo repone la cosecha.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A ✓ sin la app dueña, el host contesta locked:true — y con ok:true, que es la trampa
B ✓ con la app, vault.status dice ABIERTA: el socket sube en 1-2 s
C ✓ el diálogo ABRE en el compositor y se lo CONTESTA: «1» ⇒ yes, «2» ⇒ no
D ✓ vault.save con consentimiento real guarda, y vault.match la encuentra SIN contraseña
E ✓ el navegador real, sobre una página servida por HTTP: la contraseña llega al CAMPO
F ✓ contestando que NO, al campo no llega NADA
Dos corridas seguidas en verde, 6 min cada una. La unidad 12 del SDD queda CERRADA.
La E es la promesa entera del §6 y sola no probaría nada —una bóveda que entrega siempre se ve
idéntica a una que entrega con permiso—; por eso la F corre lo mismo diciendo que no. Y lo que se
mide no es lo que el host contesta sino lo que hay EN EL CAMPO: la página delata al servidor lo que
le pongan. Es la lección del §7.quater aplicada al otro extremo.
Tres fallos del ARNÉS, los tres disfrazados de fallo del producto:
· `wait` a secas esperaba también a la app de la bóveda ⇒ la jaula se comía su timeout y a la app la
mataba un KILL, y con ella lo recién guardado (sled no alcanzaba a volcar). La etapa siguiente no
encontraba la credencial: «la bóveda no guarda», el diagnóstico contrario al verdadero;
· el diálogo NO responde al teclado mientras la app de la bóveda inicializa su GPU — dos llimphi
arrancando a la vez sobre render por software se pisan: doce teclas sin efecto y `denied` por
timeout con la ventana abierta. Ahora se espera a que la app PINTE (12-13 s), no a su socket;
· una sola tecla no alcanza y el borde se mueve: el contestador insiste hasta que la ventana se va,
que es la única señal que no depende de adivinar cuánto tarda.
El guardián entra ENTERO a la suite (era `--hasta A`): 20 en verde, ~38 min.
Lo que costó llegar: el guardián se escribió para medir una función y destapó tres piezas rotas,
NINGUNA en atuq — el dueño y el diálogo no estaban en el corpus, ninguna ventana llimphi podía pintar
sin Vulkan, y el dueño atendía de a un cliente. Las tres se veían igual desde el navegador: una
bóveda que no ofrece nada, sin un solo error.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Para saber si el bit setuid elevaba copié busybox sobre /usr/bin/id (busybox elige el applet por
argv[0] y necesitaba un nombre válido) y después borré «mis» copias de prueba. Una era el `id` del
sistema, y no quedaba otro: /bin/id tampoco existía. El usuario se lo encontró de frente: «claude:
line 23: id: not found» y «-bash: /usr/bin/id: No such file or directory».
Restaurado como sus hermanos de identidad —whoami y groups apuntan a ../../bin/busybox— y comprobado
con id de root, de sergio y con el `id -un` que usa el lanzador. Barrido: 0 enlaces colgados en
/bin, /usr/bin, /sbin y /usr/sbin.
La lección es de método: para probar una propiedad del sistema no se usa un nombre que el sistema ya
ocupa. La sonda correcta fue la que terminé escribiendo —cinco líneas de C a un nombre inventado—.
Y es la misma familia que el /etc/shadow del §6.51: la caja no avisa cuando le falta algo esencial,
se entera el que lo usa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con el arreglo de llimghi sellado, el guardián de metal pasó de la A a la D:
A ✓ sin la app dueña, el host contesta locked:true (y con ok:true, que es la trampa)
B ✓ con la app, vault.status dice ABIERTA — el socket sube en 1 s
C ✓ el diálogo ABRE en el compositor y se lo CONTESTA: «1» ⇒ yes, «2» ⇒ no (los dos sentidos)
D ✓ vault.save con consentimiento real guarda, y vault.match la encuentra SIN contraseña
E ✗ el navegador pide la contraseña y no llega nunca
La E destapó un fallo que no es de atuq ni de llimphi: el dueño de la bóveda atendía de a UN cliente
—`atender_cliente` no vuelve hasta que el cliente se va, y se lo llamaba en el hilo del accept—, así
que la primera conexión se quedaba con él mientras viviera. Y el caso normal es ése: Gecko lanza un
`puriy-costura` por PUERTO, ocho en atuq, y todos conectan al arrancar. La extensión de la bóveda
mandaba `vault.match` y no volvía nunca: sin insignia, sin log y sin error, indistinguible de «este
sitio no tiene contraseñas».
Control sin navegador, en los dos sentidos: un solo cliente contesta en milisegundos; con otro host
conectado y quieto, la misma pregunta queda colgada y la mata el timeout a los 30 s.
Arreglado en tawasuyu (`cf3540460`, un hilo por conexión; los diálogos los serializa ahora el Mutex
de la bóveda) con su test de regresión, que además cazó que el arreglo obvio —clonar el Dueno— borra
el socket en el Drop del primer hilo que termina. Los siete tests que ya había no podían ver el fallo:
abrían un cliente por vez, que es justo lo que producción nunca hace.
⚠ Y subir el pin volvió a chocar con el `Cargo.lock` abierto de tawasuyu. Lo que importa para la
próxima es CUÁL operación lo cierra: `cargo metadata` sin `--locked` da **1 línea** de diff y cero
checksums movidos; `cargo generate-lockfile` da 6.305 líneas y 750 checksums, e invalidaría el
vendoreo de todos. Publicado en `b80f7567c` con índice temporal (estaba MM).
Del lado del guardián, tres cosas que salieron de fallar:
· el contestador INSISTE hasta que la ventana se va — con el mismo `wtype rc=0`, una corrida
contestaba y otra volvía `denied`: la ventana entra al árbol del compositor antes de que llimphi
tenga el teclado enganchado, y un sleep más largo sólo mueve el borde;
· el contestador busca la ventana POR PATRÓN: con el navegador abierto, teclear «la enfocada» le
contestaría a la página, y eso es un sí que nadie dio;
· la sonda del chrome mira `isShownForTab` y la insignia ANTES de apretar — `triggerClickOrPopup`
sale por la puerta de atrás si la acción no está mostrada, y un click que no llega se ve igual que
una bóveda que no contesta. (Y `WebExtensionPolicy` no es global en el scope de una ventana: sale
del módulo. Eso costó una corrida.)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
terapeuta y los .ec quedan decididos —respaldar, no mudar, y los dominios vencieron hace tiempo—, lo
que explica el NXDOMAIN del §10 y lo saca de los bloqueos.
El gitea de la caja YA tenía sergio/takana.git al lado de sergio/tawasuyu.git; lo que faltaba era el
árbol de trabajo. Los tres clones quedan en /work/sergio de sergio:sergio y los tres EMPUJAN: se le
generó clave en la caja y se registró en su cuenta de gitea por la API con un token de `gitea admin`.
Y los sitios pasan a servirse de los clones, así que publicar es `git pull`. El contenido estaba al
día —se comparó lo servido con lo que generan hoy los repos y coincidía byte a byte—; lo roto era el
modelo: cuando el repo cambiara, la web no se iba a enterar, y eso no se nota porque un sitio viejo
responde 200 igual que uno nuevo.
Lo de humanoid es distinto: su repo es el proyecto Android y lo que se sirve son APK ya construidos,
salida de release que no vive en ningún repo. Refrescar esa página no es publicar, es compilar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La condición del usuario está cumplida y medida: la caja sella recetas de takana y de tawasuyu desde
fuente (puriy-costura al mismo hash que predice el hub), tiene compilador propio, driver de C y el
latido empujando. Y los diez dominios de gioser.net/tawasuyu.net resuelven a la caja.
Dos hallazgos del barrido. terapeuta.ec, andino.ec y mercedes.andino.ec NO RESUELVEN en ningún lado
—NXDOMAIN desde dos resolvedores— aunque gioser las siga sirviendo por IP: para el público ya están
caídas. Y el que cambia el orden de las cosas: A GIOSER YA NO SE ENTRA. El 22 está cerrado desde el
laptop, desde la caja y desde el worker; 443, 80 y 2345 abiertos; hcloud dice `running`.
Eso importa porque quedan 127 de 150 entradas de datos sin decidir, y hoy no se pueden bajar sin modo
rescate. O sea: lo que bloquea el borrado no es capacidad —la caja ya reemplaza a gioser— sino datos
sin clasificar en una máquina en la que ya no se puede entrar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §7.septies dejó el diagnóstico: sin display handle, el camino de escritorio de llimphi abre el
display EGL surfaceless, la surface no tiene un solo formato y la app panica. El arreglo está empujado
allá (`eed3120b6`) y son dos ficheros: `Hal::new_con_display` —que usa el `instancia_con` que YA
existía para el camino layer-shell— y el llamador de escritorio pasándole la `window`, que estaba ahí,
creada una línea antes para hacerle la surface. La pieza no faltaba: faltaba enhebrarla.
Control antes de empujar, porque hasta reconstruir no se puede medir: `cargo check -p shuma-pregunta`
pasa con el parche y FALLA con una rotura a propósito en la línea tocada — un check que no compila el
fichero se ve igual que uno que sí.
Commiteado allá con índice temporal (GIT_INDEX_FILE + commit-tree + push <sha>:main), que es lo único
que publica dos rutas sin llevarse por delante los 181 ficheros que otra sesión tiene en vuelo; el
control (`git diff-tree -r --name-only`) nombra dos. El primer push fue rechazado porque el remoto se
movió: se rehízo el commit-tree sobre el FETCH_HEAD nuevo, comprobando antes que esos dos ficheros no
habían cambiado allá.
⚠ Con esto el pin de las dos recetas DIVERGE del `23a292863` de sus once hermanas del monorepo, y eso
cuesta un árbol de fuentes propio — otro vendoreo de 2,4 G, porque el árbol se comparte por
`<repo>-<sha>`. Queda dicho en las dos recetas.
⚠ Y el sello todavía no está: las dos están encoladas en el worker detrás del build de rust. Hasta que
sellen y la etapa B del guardián pase, esto es un arreglo compilado, no un arreglo medido.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El envoltorio existe y está puesto: /usr/bin/cc y c++ sobre el seed-zig que ya estaba en el store,
más las tres banderas en profile.d. No mete nada nuevo en el corpus; volver a zig el compilador
oficial de la distro sigue siendo decisión de ADR.
Y el cuarto control —preguntar por la VARIABLE en una shell de login, no por el fichero— encontró que
en esta caja /etc/profile.d no lo leía nadie porque /etc/profile no existía: las banderas habrían
quedado presentes, con contenido y sin efecto, y el bash_completion.sh que ya estaba ahí llevaba
quién sabe cuánto igual de mudo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio