Los repos del rootfs apuntan a Alpine edge (bump deliberado por el techo
MSRV). Es RODANTE: el mismo script en dos fechas da compiladores distintos.
Medido el 2026-08-10 al bootstrapear gioser — el laptop tenia rust 1.96 y
aqui edge resolvio 1.97.0-r0. Para un proyecto cuyo invariante es reproducir
eso es deriva del LAB, y no aparece en build-state.json.
No es un pin y no puede serlo: edge sirve solo la ultima version (`apk policy
rust` lista unicamente 1.97.0-r0), asi que `apk add rust=1.96.0-r0` rompe en
cuanto edge avanza, y Alpine no publica snapshots datados de edge. Anclar de
verdad pide espejar APKINDEX + los .apk, que es un frente aparte.
Lo que si se puede hoy: registrar los 92 paquetes resueltos en
docs/state/lab-toolchain.lock —que viaja por git, que es como los dos hubs lo
comparan— y AVISAR con el diff delante cuando la maquina difiere. Aceptar el
cambio es deliberado: --relock. Un lock que no se puede imponer sigue
valiendo si al menos nombra lo que cambio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Primer paso del SDD 22 (armador de kernel), en el orden que fija su §8. Regla dura
respetada literalmente: hammer LEE el grafo de Kconfig, no lo resuelve — el .config lo
sigue produciendo el olddefconfig del propio kernel.
hammer-core/src/kernel/: lector tolerante (18.212 símbolos, 1646 ficheros, 0 avisos de
parseo sobre 6.16.12) + lector de .config. hammer kernel {stats,closure}.
La semántica de arista, que el §3 pedía definir antes de escribir el predicado:
· dependencia dura = símbolo en posición CONJUNTIVA (en "A && (B|C)" sólo A). La
disyunción, la negación y las comparaciones no aportan. Conservador a propósito:
apagar de menos se nota, apagar de más hace un ladrillo.
· símbolo con varias definiciones ⇒ INTERSECCIÓN entre ellas, no unión.
· select es el portillo, no una arista más: fuerza el destino IGNORANDO sus depends.
select_leaks las enumera; closure_off_fixpoint cierra el bundle contra ellas y REPORTA
el precio en vez de aplicarlo solo.
La medición que decide §2.1, contra el bundle N1 hecho a mano de recipes/linux.toml:
clausura estricta de WIRELESS ......................... 350
punto fijo (3 fugas: WLAN, IWLEGACY, GELIC_WIRELESS) .. 406, cierra en 1 ronda
bundle a mano ......................................... 421
SOBRA 0 · falta 15
Los 15 son todos RFKILL, que no es wifi sino el interruptor de radio compartido con
bluetooth y NFC. El humano apagó DOS bundles en la misma línea ⇒ el catálogo necesita
"sin radios" como entrada propia. §2.1 es viable.
Y el punto fijo también dice cuándo no: cerrar "sin audio" exige tragarse DRM_I915/
NOUVEAU/AMD_DC, que hacen select del códec HDMI. En linux.toml sale gratis porque los
gráficos ya están apagados; en un escritorio sería una decisión.
De regalo: linux.toml apaga REISERFS_FS, que 6.16.12 ya no tiene. Un -d a un símbolo
inexistente se pierde HOY en silencio — justo lo que el diff-back (paso 4) va a atrapar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Selladas 6: wayland, wayland-protocols, libxkbcommon, mesa, mirada-compositor
y mirada-greeter. Corpus 766 -> 768, deuda 11 -> 9, y la clase rust
desaparece. El perfil escritorio-mirada pasa a 31/31.
Las cuatro primeras figuraban como selladas y no lo estaban: el respaldo
tiene 7 artefactos VACIOS (mesa, wayland, wayland-protocols, libxkbcommon x2,
dbus x2), --listar los cuenta por nombre de directorio, build-state los toma
por buenos y hammer build hace cache-hit sobre el directorio vacio. Sellaba
sin construir y salia 0. Un ausente falla ruidosamente; un vacio llega hasta
el final diciendo que todo fue bien.
Para construirlas hacian falta dos piezas del lab que gioser no tenia: zig
0.13.0 (lo pinean 84 recetas, y se busca por directorio versionado, no por
el symlink) y el paso apk del rootfs, que trae rust/cargo. Quedan bloqueadas
gnome-session (no hay receta de GTK3 en el corpus) y gnome-settings-daemon
(geocode-glib existe, esta en deuda y no figura en su [deps]).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierre de la reparación. Lo que faltaba eran cuatro recetas que caían todas por `libsndfile`
—cuyo configure de autotools sólo busca python2.x— y `gnome-shell`, que había que rehacer.
Selladas en el hub: wireplumber, xdg-desktop-portal, xdg-desktop-portal-cosmic,
xdg-desktop-portal-gnome y gnome-shell.
ESTADO FINAL DE LOS PERFILES:
base 51/51 · cli 74/74 · escritorio-sway 121/121 · escritorio-kde 162/162
escritorio-cosmic 88/89 · escritorio-gnome 122/125
Lo que queda NO es deuda técnica sino decisiones ya tomadas:
· gdm, gnome-session, gnome-settings-daemon → CERRADAS por decisión (GTK3, 2026-08-08);
· portal-probe → git privado por SSH, HUB-ONLY estructural.
⚠ HALLAZGO EN LA GOLDEN NUEVA, que hay que arreglar antes de confiar en ella: el volumen
persistente `harkaq-cosecha` se monta ENCIMA de `/opt/hammer/store` y **tapa el store horneado
en la imagen**. El worker nuevo arrancó con 2 artefactos en vez de los ~900 que trae el
snapshot, así que la caché de la golden es hoy inútil: el bind del volumen la esconde. El
toolchain sí se heredó bien (cargo/rustc 1.96.0, go 1.26.4 verificados en el arranque).
⇒ O el volumen deja de montarse sobre esa ruta, o la golden no necesita traer store. Hoy hace
las dos cosas y se anulan.
Por eso estas cinco se construyeron en el hub y no en la granja: para cinco recetas no valía la
pena resolver el solapamiento, y el hub las tenía todas cacheadas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Al lanzar COSMIC, sus 30 raíces fallaron de golpe con «spawn cargo vendor: No such file».
Medido:
worker: cargo AUSENTE · rustc AUSENTE · go AUSENTE
hub: cargo ✓ · rustc ✓ · go ✓
hammer invoca `cargo vendor` en el HOST, no dentro del sandbox — el vendoreo pasa ANTES de
entrar a la caja. El worker no trae toolchain de Rust ni Go ⇒ la granja no puede construir
NINGUNA receta Rust o Go: COSMIC entero, las 228 Rust del corpus y las 362 Go. **El 76% del
catálogo sólo puede construirse en el hub**, que es UNA SOLA MÁQUINA — justo lo que el respaldo
de ayer intentaba dejar de asumir.
ESTO EXPLICA HACIA ATRÁS todos los «no construyó» de esta campaña (amp, anew, apko, atlas, bom,
broot, cargo-audit, cargo-hack, git-absorb). Yo lo atribuí a «necesitan red para sus módulos» y
lo escribí así en el SDD 23 y en memoria. Era falso: **falta el binario**, no la red.
Y ARREGLARLO NO ROMPE LA HERMETICIDAD: cargo/go aquí son herramientas de FETCH, del mismo orden
que `git` para clonar — se usan para traer y fijar deps ANTES del build, no dentro del sandbox.
Instalarlos en la imagen golden no relaja el aislamiento; el build sigue ocurriendo en la caja
con el árbol ya vendoreado. Es lo contrario del caso «no engordar el rootfs del worker», que
habla del rootfs DEL SANDBOX.
⇒ Decisión de aprovisionamiento, no de arquitectura, y desbloquea tres cuartas partes del
catálogo para la granja.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
perl-xml-parser, libpcap, libnl, lm-sensors, libxkbcommon, vulkan-loader y dbus — las siete
sombras de incoming-kde cuyas deps sí estaban al día, o sea el origen de la deriva. 7 de 7
selladas, sin un solo fallo: confirma el diagnóstico de que no había muro técnico, sólo
artefactos que nadie había reconstruido.
Quedan 79, todas aguas abajo. En vez de ir ola por ola se lanzó la construcción de las 11
RAÍCES del perfil y hammer resuelve la clausura solo — que es para lo que sirve el grafo de
deps y evita adivinar el orden a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Diagnóstico completo. No es daño de la campaña del split ni un fallo de store-gc.
LO MEDIDO, en orden:
1. 86 nodos del perfil sin artefacto en su hash vigente.
2. NO lo causó el split: revertidas una por una todas las recetas tocadas hoy (3 bibliotecas
base, 30 hojas, dbus, 38 de la 2ª tanda) el número NO se movió de 198 en ningún caso.
3. La FRONTERA son 7 recetas —las únicas cuyas deps sí están al día—: dbus, libnl, libpcap,
libxkbcommon, lm-sensors, perl-xml-parser, vulkan-loader. Las otras 79 cuelgan de ellas.
4. Las 7 son SOMBRAS de incoming-kde, no las canónicas. Las del corpus están al día, y por eso
el problema es INVISIBLE desde el grafo del corpus — que es justo el que yo miraba.
5. No fue store-gc: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres nunca
se podaron. (Lo sospeché porque la regla de «superado» es por NOMBRE y una sombra comparte
nombre con la canónica; la sospecha era razonable y los manifiestos la descartan.)
6. Ni el hub ni el worker los tienen. No están en otro sitio: NO ESTÁN.
LA CAUSA DE FONDO, que importa más que KDE: la cola se construyó en workers EFÍMEROS, el sync
del store es unidireccional (worker→hub) y esos workers ya no existen. Cuando algo del sustrato
compartido cambió después, las sombras se re-hashearon y nadie las reconstruyó, porque el hub
nunca fue la máquina donde vivía ese escritorio.
⇒ Con flota efímera y sync unidireccional, un escritorio puede dejar de ser
reconstruible-desde-el-store SIN QUE NINGÚN INDICADOR LO DIGA. El grafo seguía reportando
162/162 desde un JSON generado semanas antes.
Coste de arreglarlo: 86 reconstrucciones en la granja, empezando por las 7 de la frontera. No
hay muro técnico conocido — son recetas que ya construyeron. Es cómputo, no investigación.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Al desplegar la 2ª tanda de hojas noté 198 recetas de las colas de escritorio sin artefacto
vigente (KDE 133, GNOME 37, COSMIC 24) y asumí que las había roto yo. **No.**
LO VERIFIQUÉ REVIRTIENDO, una causa por vez: las 3 bibliotecas base (expat, zstd, ncurses), las
30 hojas de la 1ª tanda, `dbus`, y las 38 de la 2ª. **El número no se movió de 198 en ningún
caso.** Y mirando el histórico, `escritorio-kde` está en 76/162 en TODOS los commits recientes
—09:10, 09:41, 10:12, 10:44, 11:16, 11:49— o sea desde antes de que la campaña empezara.
EL ERROR FUE MÍO Y DE MÉTODO: escribí «KDE cierra 162/162» leyendo
`docs/state/build-state-kde.json` **sin regenerarlo**. Es un fichero GENERADO, y un generado que
no se regenera es una foto vieja con aspecto de dato fresco. El mismo tipo de fallo que citar el
«79%» midiendo otra unidad: el dato existía, lo que fallaba era de cuándo era.
⇒ Y hay un aviso de fondo para toda la sesión: **medí «cero daño colateral» sobre el grafo
`--wlr`, que sólo carga corpus + incoming-wlr.** Las colas de escritorio son INVISIBLES ahí, así
que ese «cero» era cierto en el grafo que miraba y no decía nada del catálogo completo. Para
juzgar impacto hay que cargar TODAS las colas.
Las 38 de la 2ª tanda quedan revertidas: hasta entender los 198 no conviene añadir cambios
encima. Las 30 de la 1ª y las 5 del piloto siguen puestas y verificadas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
base 51/51 · cli 74/74 · escritorio-sway 121/121. Cosecha verificada: cero artefactos en el
worker que el hub no tenga.
De la tanda: 25 de 30 selladas. Los 5 fallos, ninguno causado por el split:
· cargo-audit, cargo-hack, git-absorb — 'spawn cargo vendor': el grafo las clasifica como clase
`c` porque declaran compiler=gcc para sus deps de C, pero por dentro son Cargo. Filtrar por la
clase del grafo NO basta.
· hammerd — git privado por SSH (HUB-ONLY, como las de tawasuyu).
· coreutils — 'you should not run configure as root'. Esto NO lo causó el split: es DERIVA. La
receta llevaba tiempo sin poder construirse en el lab actual y nadie lo sabía porque su
artefacto viejo seguía en el store. Es exactamente lo que la campaña destapa.
⚠ Y de ahí sale un riesgo que conviene nombrar: cada receta que deja de reconstruir convierte su
artefacto viejo en un REHÉN — store-gc no puede podarlo (es el único ejemplar) y nadie puede
regenerarlo. Hoy son ~12 G inmovilizados, y crecen con cada receta que se rompe en silencio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`base`, `cli` y `escritorio-sway` bajaron a 50/51, 73/74 y 120/121 después de la cascada del
split, y los tres fallaban por LA MISMA receta: dbus.
EL ERROR NO MENCIONABA LA RED POR NINGÚN LADO:
meson.build:372:11: ERROR: Unhandled python exception
Y arriba, enterrado entre reintentos:
<urlopen error unknown url type: https>
WARNING: failed to download with error: name 'ssl' is not defined
dbus declara subproyectos con `.wrap` y meson intenta DESCARGARLOS. En el sandbox no hay red y
python no trae ssl ⇒ «Unhandled python exception», que se lee como un bug de meson y es
simplemente que no hay salida a internet. Y no debe haberla: el build es hermético a propósito.
`--wrap-mode=nodownload` obliga a usar las deps del sistema (nuestros artefactos, vía
pkg-config) y deja los wraps inertes. Mismo caso que `wl-clipboard` anoche.
⇒ base 51/51 · cli 74/74 · escritorio-sway 121/121. Los tres cierran otra vez.
ESTADO DE LA REPARACIÓN DE LA CASCADA: de las 54 que quedaron sin artefacto, 42 reconstruidas.
Las 12 restantes son EXACTAMENTE las que ya estaban en deuda antes de la campaña:
· 6 el muro del PIC (gtk4 y su cadena estática — duplicado superado de la dinámica de GNOME);
· 3 HUB-ONLY (mirada-*, llimphi-counter: git privado / commit en ceros);
· dwarves (libdw/musl), y adwaita-hello (error 39 = la carrera del ADR 0012).
O sea que la campaña no dejó deuda nueva.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Activar strip_debug en tres bibliotecas BASE (expat, zstd, ncurses) re-hasheó 54 recetas en
cascada, incluida la cadena wlroots/sway. Tocar cincuenta HOJAS no habría costado ninguna
reconstrucción extra. El desplegador ordena alfabéticamente y debe ordenar por profundidad en
el grafo, de hoja a raíz.
Y ADR 0012 —la carrera del árbol de fuentes, 'pendiente sin decidir' desde hace meses— acaba de
morder: adwaita-hello murió con error 39 (Directory not empty). Una reconstrucción masiva es
exactamente el escenario que lo dispara, así que decidirlo deja de ser opcional si la etapa 4
va a correr en paralelo.
Más dos lecciones de operación: un drenaje largo no puede vivir dentro del ssh (se cortó a las
14 de 54), y la flota efímera reusa IPs, así que la clave de host cambia y cada conexión grita
MITM — conviene que farm-up lo limpie solo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §1.bis dijo «sí hay no-determinismo» porque appstream y bison divergían. También estaba mal,
y por un fallo de diseño del propio test.
`verificar-repro.sh` compara el artefacto GUARDADO contra una reconstrucción de hoy. Pero el
guardado puede tener meses: se construyó con OTRO estado del lab. El test conflaba dos cosas:
· NO-DETERMINISMO — mismas entradas, mismo lab, salidas distintas (rompe el invariante);
· DERIVA — el artefacto viejo no es lo que el lab de hoy produce (el mundo se movió).
LA PRUEBA QUE LAS SEPARA es construir DOS VECES HOY, y se dio sin querer: al reejecutar el
verificador sobre recetas ya reconstruidas, TODAS pasaron a reproducir.
anew ✗ diverge → ✓ REPRODUCE
gron ✗ diverge → ✓ REPRODUCE
age ✗ diverge → ✓ REPRODUCE (y en la 1ª ni instalaba los mismos ficheros: faltaba age-inspect)
⇒ EL CORPUS ES DETERMINISTA HOY. Lo que hay es deriva contra artefactos viejos.
QUÉ SIGNIFICA, sin adornos:
· El argumento de reproducibilidad para el split de debug SE CAE. El split se justifica por
ESPACIO (~60%), que sigue siendo real y grande. Nada más.
· Pero la DERIVA es un problema por derecho propio y mayor: el store contiene artefactos que el
lab de hoy no reproduciría, así que «nuestros artefactos son verificables por terceros» es
falso para parte del corpus — quien reconstruya no obtendrá lo publicado. `age` es el caso
feo: la reconstrucción ni siquiera instala los mismos ficheros.
· ⇒ La reconstrucción masiva SIGUE valiendo la pena, pero por otra razón: no para arreglar el
determinismo sino para PONER EL STORE AL DÍA CON EL LAB y que la promesa sea cierta.
Y otro hallazgo del mismo experimento: en el hub las recetas Go SÍ reconstruyen (0 fallos). Lo
que fallaba en el worker era la RED para bajar los módulos, no las recetas. Eso cambia el
bloqueante de la etapa 4: no es «Go no reconstruye», es «el worker no tiene red para módulos».
LA LECCIÓN, que es la misma tres veces en este documento: un test hay que diseñarlo contra la
PREGUNTA, no contra lo que es fácil de comparar. Comparar con lo que hay en el store es cómodo;
comparar dos builds de hoy es lo que contesta. El script queda anotado con esto en la cabecera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El «79%» que este plan y los SDD 19/20 venían citando era **el 79% del CONTENIDO BINARIO**,
medido sobre una muestra de .so/.a. Es cierto y es la cifra equivocada para planificar, porque un
artefacto no es sólo binarios: trae cabeceras, datos, iconos, locales, .pc y documentación, que
no encogen.
MEDIDO con `scripts/medir-debug.sh` (suma los tamaños reales de las secciones .debug_* vía
readelf -S y los compara con el tamaño del árbol, sin reconstruir nada):
40 artefactos · 876 MB · 27%
100 artefactos · 2955 MB · 38% (truncada a 60 ficheros/artefacto)
250 artefactos · 8874 MB · 60% ← la que manda: sin truncar, ~7% del store
La varianza es alta porque unos pocos artefactos grandes dominan el total, así que el número
necesitaba validación independiente — y la tiene: el piloto de la etapa 2, donde se reconstruyó y
se pesó de verdad, dio bison −50% y appstream −68%. Los dos ENCIERRAN el 60% de la muestra
grande. El modelo predice lo que el rebuild produjo.
CIFRAS CORREGIDAS, con el store en 127 G:
se venía diciendo medido
reserva de disco ~96 G ~76 G
store tras el split ~30 G ~51 G
espejo público ~30 G ~51 G
Sigue siendo el mayor ahorro disponible en el proyecto —76 G no es poco— pero no es lo
prometido, y la diferencia importa para dimensionar el alojamiento del espejo, que es una
decisión con factura.
LA LECCIÓN: una cifra medida sobre una cosa (contenido binario) se citó durante semanas como si
midiera otra (tamaño de artefacto), y llegó a tres documentos. El número no era falso; LA UNIDAD
sí. Cuando un número vaya a decidir un gasto, hay que volver a la medición original y comprobar
QUÉ estaba midiendo.
Corregido en los tres sitios donde se había propagado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergio