El grafo buscaba store/<hash>-<basename> pero el artefacto se sella por el name INTERNO de la receta
(qtbase.toml → name=qt6-qtbase → store/<hash>-qt6-qtbase). Las qt6-* KDE salían 'debt' aunque
estuvieran selladas. Fix: nodo lleva iname=d['name']; state_of busca por iname. Las aristas de deps
siguen por basename (así resuelve resolve_dep_path). qtbase ahora sale sealed correctamente.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El --disable-jit anterior movió el error de pcre2_jit_compile.o a pcre2_compile.o (pso_list): el
fondo NO era el JIT, era que los objetos del .a se compilaban SIN -fPIC. qtbase construye Qt SHARED
(BUILD_SHARED_LIBS=ON, libQt6Core.so) y linkea libpcre2-16.a DENTRO de ese .so; un .a no-PIC lleva
relocaciones absolutas R_X86_64_64 que ld.lld rechaza en un objeto compartido. El propio
pcre2-shared.toml ya lo documentaba: 'el canónico es --disable-shared SIN --with-pic ⇒ su .a no
enlaza dentro de un .so'.
Fix: --with-pic + CFLAGS=-fPIC ⇒ objetos position-independent, linkables en .so y en PIE. Convive
con el -no-pie del ejecutable pcre2grep (el audit static lo quiere). JIT queda off igual (W^X +
tablas frágiles). VERIFICADO: qtbase pasó el punto de fallo (objeto 400) y compila de largo (490+),
sin el 'relocation cannot be used against local symbol'.
Es un fix raíz del modelo static↔dinámico (Capa 0 KDE): cualquier consumidor .so del pcre2 canónico
lo necesitaba.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
qtbase falló al linkear: ld.lld 'relocation R_X86_64_64 cannot be used against local symbol' en
libpcre2-16.a(pcre2_jit_compile.o). El JIT de PCRE2 emite relocaciones absolutas en .rodata (sus
tablas de código generado) que son incompatibles con PIE — y TODO binario static musl de hammer se
enlaza PIE. No es un problema de Qt: es un landmine para el modelo entero; cualquier binario PIE que
linkee pcre2 con JIT lo pisa.
Fix raíz: --disable-jit. El regex queda un pelo más lento y la API NO cambia (pcre2_jit_compile
devuelve error si no hay JIT, los consumidores lo manejan). Rehashea pcre2 y sus dependientes, pero
ya estaban en deuda (lo re-sellé este ciclo con el arreglo static). Destraba qtbase → la raíz del
árbol KDE (↑117).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tanda de base libs KDE construidas en el laptop mientras qtbase compila en background. qtbase (la
raíz, ↑117) va por 400/2163 objetos. libsndfile falló por fetch de red (no código).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MOTIVO: 'estábamos haciendo kde'. La cola recipes/incoming-kde/ (206 recetas) era punto ciego del
grafo (sólo miraba recipes/ top-level). Modo --kde: build-state.py/build-state-view.py cubren la cola
KDE (sombreando canónicas homónimas sibling-first, como el sandbox) → build-state-kde.{json,html}.
CAUSA de la deriva (193/206 en deuda): fui YO — esta sesión re-sellé pkgconf y samurai (arreglos
static), y 194 recetas KDE declaran pkgconf, 142 samurai ⇒ re-hash en cascada de todo el árbol. El
sistema determinista funcionando: cambia un input base, cascan los dependientes. Deuda legítima.
DESBLOQUEO (el 'GUI rompe en el laptop' era sólo cairo/pango, NO la base): construida en el laptop
toda la base KDE guiado por el orden de ataque del grafo — extra-cmake-modules, util-macros,
xorgproto, xcb-proto, wayland, libdrm, dbus, icu4c, util-linux, fontconfig, pixman, glib, freetype,
harfbuzz, fribidi, libXau/libXdmcp, la cadena X11 (xtrans/libxcb/libX11/libXext/libXrender/libXfixes/
libXi), la familia xcb-util, libxkbcommon, wayland-protocols, mesa (24.0.9 iris-only, sin LLVM), y
los -shared. KDE 9→39 selladas. qtbase (↑117, la raíz) quedó DESBLOQUEADO y compilando.
DISCO: el build llenó el disco (100%). Liberados 82G borrando work/sources (57G, se re-extrae solo)
y .farm-harvest (26G, verificado 100% redundante en el store, CAS).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Señal fuerte para Rust: la receta copia su binario de target/release/ en las fases. Medido 225
recetas, 0 con dep go ⇒ sin falsos positivos con Go (findutils entra bien: es uutils/findutils, find
en Rust). LÍMITE: un crate BuildSys::Cargo PURO sin fase install propia (zellij) no deja rastro en el
TOML y cae a 'c' — sólo se ve bajando la fuente, que el generador no hace.
Efecto: clases c 322→141, rust 45→226 (la mayoría eran Rust auto sin fase cargo explícita). Y la
LECTURA de la deuda cambia: la deuda C REAL es sólo 8 (casi toda saldada esta sesión), no 74. Lo que
queda es Rust (15, CLI pesados → granja), GUI (29 → granja), Go (5 → worker), kernel (4).
musl sellado (base). Avance: sealed 703→704, debt 53→52.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tres tandas más de C-base de sistema, todas verifican (MIENTEN 0): perl (background, desbloquea 8),
la cadena curl/ca-certificates/gnupg, y bwrap dosfstools e2fsprogs gzip htop iproute2 iputils jq kbd
lz4 libsodium libuv mandoc parted pciutils procps-ng rsync shadow strace usbutils dhcpcd git vim
wget openssh tmux xorriso wpa_supplicant libssh2.
Avance acumulado de la sesión: sealed 647→703 (+56), debt 109→53. La deuda C-base cayó 74→18, y de
esos 18 la mayoría son Rust CLI mal-clasificados como 'c' (amp/broot/delta/gitui/zellij…) + musl.
La deuda que queda es GUI (29, granja), Rust (5), kernel (4), go (5).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Segunda tanda de sistema-base en el laptop, todas C puras listas: libudev-zero mtdev libevdev npth
libusb libevent libassuan libksba socat less nano sed gawk doas. MIENTEN 0 en las link=static.
Avance acumulado de la sesión: sealed 647→671 (+24), debt 109→85. La deuda C-base bajó 74→50; la
GUI (29) sigue intacta para la granja, como manda el orden de ataque (glib/wayland/pixman ↑).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Construidas y selladas en el laptop (C-base, listas, no-GUI, sistema): zstd (desbloquea 10), xz,
tar, tree, tzdata, tig, scdoc, when. Todas verifican: MIENTEN 0 en las link=static. Es progreso
real visible en el grafo — el resto de la deuda de alto impacto es GUI-céntrica (glib/wayland/pixman)
y va a la granja, como muestra el orden de ataque.
Snapshot del grafo actualizado: sealed 647→655, debt 109→101, never 8.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El grafo ahora computa, sobre las dependencias, dos campos por receta:
blocked_by — deps que están en deuda (lo que impide construirla ya)
unblocks — cuántas recetas EN DEUDA la declaran como dep (su impacto de desbloqueo)
Una receta en deuda sin blocked_by es construible YA; ordenadas por unblocks desc, dan el orden que
libera el grafo más rápido. La vista muestra la pastilla ↑N en las filas listas y ordena por ahí.
Top de impacto (todo el stack GUI concentrado, más zstd/perl de C-base):
glib ↑14 wayland ↑13 pixman ↑12 libdrm ↑11 fontconfig ↑11 zstd ↑10 libxkbcommon ↑9 perl ↑8
Es la guía para cuando se levante la granja: construir esas primero desbloquea el grueso.
De paso, diagnóstico de las 8 'never' (ninguna es cruft ni bug): dwarves BLOQUEADA-documentada
(necesita libdw, elfutils da sólo libelf a propósito — sub-proyecto elfutils-libdw); llimphi-counter
es un EJEMPLO/plantilla intencional; las otras 6 son imports Go/Rust que van al worker. Y confirmado
parseando: 0 recetas con FIXME real en el campo sha256 (el grep decía 43, todas comentarios) — otra
vez grep miente, el grafo (parsea) dice la verdad.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dashboard self-contained (sin recursos externos, tema claro/oscuro) que rinde build-state.json para
VER y SEGUIR: barra de avance del corpus, tiles por estado, reparto de deuda por clase, y los huecos
en ORDEN DE ATAQUE. Ese último es el uso accionable del grafo: cada receta en deuda muestra sus deps
coloreadas por estado; una fila 'lista' tiene todas sus deps al día (construible ya), una 'espera N'
depende de N recetas también en deuda. Foto actual: 117 en deuda, 71 listas ahora.
Publicado como Artifact para verlo en el navegador; el HTML también queda en el repo (abrir con
file://). Regenerar ambos: scripts/build-state.py && scripts/build-state-view.py.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El estado real del build vivía disperso —en mi cabeza, en docs que envejecen (matar-gcc decía 47,
eran 16), en el store (que guarda TODOS los sellados históricos, no el vigente)— y cada medición a
mano mentía distinto. Este generador lo deriva de la ÚNICA fuente de verdad (recetas + hammer hash
+ store) a un JSON firme. El git diff de ese fichero ES el avance entre dos corridas: qué se saldó,
qué se rompió, qué cambió de estado.
NODO = receta {name, class, link, compiler, deps[], hash, state}:
sealed — el artefacto del hash VIGENTE está en el store (al día)
debt — hay sellados históricos pero ninguno vigente (cambió, falta rebuild)
never — sin ningún sellado
unhashable — hammer hash falló (hueco real)
ARISTA = dep de build. El grafo CIERRA (0 deps huérfanas) y topo-ordena sin ciclos.
Foto inicial (764 recetas): sealed 647 | debt 109 | never 8. Deuda por clase: c=74 go=5 gui=29
kernel=4 rust=5. Clases: go 362, c 322, rust 45, gui 30, kernel 5.
Validado contra lo que sé de esta sesión: samurai/which sealed, curl/openssl debt, helix sealed
(rust/gcc), naabu sealed (dynamic/go), mesa debt (gui), linux debt (kernel). Todos correctos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Las 7 recetas del stack gráfico (libdrm/mesa/meson/samurai/seatd/wayland/wayland-protocols) +
6 patches eran imports crudos de Alpine, redundantes: las 7 ya tienen receta CANÓNICA en recipes/
(mesa pineada a 24.0.9 iris-only A PROPÓSITO, no la 26.1.1 cruda con FIXME-sha256). Su trabajo
aterrizó por la vía canónica (7131cd4) hace 3 semanas; la cola quedó de cruft rompiendo cada ciclo.
fa45978 las sacó de QUEUES creyéndolas de 'otro agente' (5126a8b). Confirmado que NO hay otro
agente ⇒ borradas. recipes/incoming/ vuelve a ser cola de staging general y REGRESA a QUEUES; el
guard ls-vacío la salta si no hay nada. recipes/incoming/.deferred/ (24 recetas aparcadas con
diagnóstico, git con muro en libgit.a) NO se toca: el glob de QUEUES es top-level, no la muele.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El nuevo 'sin artefacto' del static-audit (deuda de rebuild ya no enmascarada) son 92 recetas
link=static cuyo hash VIGENTE no está sellado: el trabajo reciente (matar-gcc, static, harkaq)
cambió recetas base sin re-sellar, y cada cambio re-hashea en cascada todo lo que las declara.
Este script las salda. Calcula la deuda EN VIVO con 'hammer hash --check' (nunca una lista que
envejece), y construye cada receta NO-SELLADA. NO necesita orden topológico: 'hammer build' arrastra
sus deps recursivamente (construir curl construye openssl+perl primero); las cache-hit son instant.
Pensado para el WORKER (store completo, toolchain que no rompe el stack GUI): SKIP_GUI=1 por default
salta cairo/pango/gtk… que fallan en el laptop por zig-skew. Reparto medido: 76 C-base + 16 GUI.
Verificado end-to-end SIN quemar el laptop: modo DRY lista la deuda; y construí UNA receta diminuta
(which: NO-SELLADO → build 58s → SELLADO, hash vigente idéntico, estática de verdad en el audit).
El ciclo build+re-check del script es correcto. which quedó saldada de paso (deuda 76→75).
Confirma la decisión de usar la granja: 58s × 76 con openssl/gnupg/perl pesadas = 2-4h de laptop.
Cuando levantes la granja: farm-up, correr esto en el worker (SKIP_GUI=0 para incluir el GUI),
farm-down.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El agujero que dejé señalado 3 veces esta sesión: nada podía saber el sellado VIGENTE de una receta
sin construirla, así que static-audit.sh auditaba el más reciente por mtime (ls -dt) y acusaba a
recetas ya sanas (dbus/libnl) por un sellado anterior a sus flags.
FIX = subcomando `hammer hash <receta> [--check]`. Calcula el ArtifactHash puro sobre las recetas
(source_id + compiler/target/link + patches + flags + fases + hashes de deps recursivos) SIN bajar
fuentes ni compilar. artifact_hash() ya era pub; el CLI sólo lo expone. Cero cambios en la lógica
de hashing ⇒ NINGÚN sellado se mueve.
Verificado: `hash` da EXACTAMENTE el mismo hash que `build` (samurai, byte a byte); `--check` sobre
receta editada → NO-SELLADO en 2ms, exit 1, sin construir nada.
static-audit.sh ahora selecciona el artefacto VIGENTE por hash, no el más reciente por mtime. Con
fallback a ls -dt si hammer no está compilado. Efecto en el store completo: las ~65 recetas cuyo
sellado no es el vigente pasan de 'auditadas' (falsa cobertura) a 'sin artefacto' (deuda de rebuild
REAL, ahora visible): estáticas de verdad 615 | MIENTEN 0 | sin artefacto 123. Corre en 15s, sin
build. El '58 sin medir' de antes estaba enmascarando ~65 recetas más.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mi hipótesis de partida era falsa y conviene dejarlo escrito: el libgcc_s.so.1 NO lo metía un
sys-crate en C, y -static-libgcc (el patrón de cmake) no aplicaba — ese patrón es para C/C++.
CAUSA REAL, una sola y compartida: ambas recetas PISABAN la fase compile del lab. El lab sólo
autogenera la fase si la receta no la trae (lib.rs:779, `if out.compile.is_none()`). Las dos venían
del import de Alpine con un `cargo build --frozen --release` propio que REEMPLAZA el comando del
lab entero, y con él las tres cosas que hacen honesto al link=static:
-C target-feature=+crt-static -C relocation-model=static -C linker=.hammer-zig-cc
Sin crt-static, el rust enlaza dinámico contra musl Y contra libgcc_s — que es el UNWINDER DE LA
STD DE RUSTC, no un sys-crate.
LA EVIDENCIA QUE LO CIERRA (contraste, sin bisectar): estaba ya escrita en recipes/cargo-hack.toml
—'receta MÍNIMA sin fase compile custom (una fase cargo build produce binario DINÁMICO; el PATH
DEFAULT del lab aplica crt-static + linker zig → estático)'. cargo-hack es Rust puro y sale
estático; tuc TAMBIÉN es Rust puro, sin una línea de C, y arrastraba el mismo libgcc_s. Misma
toolchain, único delta = quién arma el cargo.
tuc: borrada la fase compile (no aportaba nada sobre el default) + flags=["--bin","tuc"] (cargo
rustc exige un único target y tuc expone lib+bin homónimos). NEEDED=0, tuc 1.3.0 corre y
'hola,mundo | tuc -d, -f2' → mundo.
helix: la fase custom es OBLIGATORIA (exporta HELIX_DEFAULT_RUNTIME y HELIX_DISABLE_AUTO_GRAMMAR_
BUILD) ⇒ replicado a mano el setup del lab siguiendo cargo-edit. Su raíz es un manifiesto
VIRTUAL ⇒ 'cargo rustc' cortaba con 'is a virtual manifest'; resuelto con -p helix-term, que
declara [[bin]] name="hx". Sigue con compiler=gcc (el gueto cc-rs/tree-sitter es real).
NEEDED=0, helix 25.07.1 corre.
MARCADOR: static-audit global = estáticos de verdad: 680 | MIENTEN: 0. Con dos honestidades: el
audit corrió DESPUÉS de los rebuilds (si no, sobre-reporta), y quedan 58 'sin artefacto o sin ELF'
que NO son un pase sino recetas no medidas. El cero es real para lo que el store cubre hoy, no una
prueba de clausura.
TRAMPA ARMADA (no tocada): el riesgo generaliza a toda receta Cargo importada de Alpine que traiga
compile propio — alpine_import.rs traduce el build() del APKBUILD literal. Hoy las 5 con compile
propio llevan crt-static, pero cada receta Rust nueva puede nacer mintiendo. Un gate barato: que el
lab avise/falle si una receta Cargo con link=static define compile sin crt-static. Cambia el lab ⇒
re-hashea sellados ⇒ decisión aparte.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
De las 4, sólo 2 eran mentiras reales. Las otras 2 eran ARTEFACTOS RANCIOS: el audit hace
`ls -dt store/*-<n>` = el sellado MÁS RECIENTE, que no es el VIGENTE (hammer no expone el hash de
una receta sin construirla — no hay 'hammer hash' ni dry-run). Con el store desactualizado, el
audit acusa a recetas ya sanas. El propio script lo advierte ('correr DESPUÉS del rebuild, nunca
antes') y aun así la lista del frente se armó sin re-sellar. => el '11 mienten' está INFLADO;
hay que re-sellar antes de asumir que cada una necesita fix.
pcre2 — mentira real de libtool. NEEDED libz.so.1+libc.so → 0. -all-static en compile Y install.
pcre2grep 10.47 corre y matchea de verdad ('foo bar' con 'b(a|o)r').
libcap — mentira real, pero la causa NO era libtool: Makefile plano, -all-static no aplica.
progs/Makefile ASIGNA `LDFLAGS = -Wl,-Bstatic` + sufijo `-Wl,-Bdynamic`, y una asignación del
makefile PISA el LDFLAGS=-static del lab. El comentario de upstream admite que su default es
'estático contra libcap.a, DINÁMICO contra libc'. Fix = LIBCSTATIC=yes, la palanca que upstream
expone justo para esto (la usa su kdebug/test-kernel.sh) ⇒ rama con `LDFLAGS = --static` sin
sufijo. NO se pasa LDFLAGS por línea de comando: pisaría la rama y devolvería el sufijo.
NEEDED=0; capsh/getcap/setcap corren y getpcaps devuelve caps reales.
dbus — no mentía. Construye con MESON, no libtool ⇒ el agujero no existe acá. Ya tenía
--prefer-static -Ddefault_library=static: libdbus-1.a, cero .so, todos los binarios NEEDED=0.
Verificado end-to-end: dbus-run-session levantó un daemon estático y dbus-send ListNames obtuvo
method return. Sólo se documentó.
libnl — no mentía. Ya tenía --disable-shared --enable-static --disable-cli: 0 .so, 6 .a, sin
ejecutables (es el 'sin ELF: 1' del audit, esperado). libnl-3.a válido con nl_connect/
nl_socket_alloc como T. Sólo se documentó.
LECCIÓN: -all-static no es la única causa. Hay paquetes que pisan LDFLAGS por asignación de
makefile (libcap) y otros que ya están bien. Hay que LEER el Makefile, no aplicar el patrón a ciegas.
Van 9 de 11 (2 eran falsos positivos).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
naabu declaraba link=static y salía dinámica con NEEDED: libdl.so.2, libpthread.so.0, libc.so.6.
Ese libc.so.6 parecía GLIBC dentro de una distro musl — un cuerpo extraño. NO lo es.
CAUSA, y es la inversión contraintuitiva: CGO_ENABLED=0 es quien lo CAUSA, no quien lo evita.
naabu → Mzack9999/gopacket → ebitengine/purego v0.10.0, una FFI SIN cgo que dlopenea libpcap en
runtime. Su internal/fakecgo/zsymbols_linux.go está guardado con //go:build !cgo y hardcodea:
//go:cgo_import_dynamic purego_malloc malloc "libc.so.6"
//go:cgo_import_dynamic purego_pthread_create pthread_create "libpthread.so.0"
//go:cgo_import_dynamic purego_dlopen dlopen "libdl.so.2"
El linker interno de Go honra esos pragmas ⇒ emite binario dinámico (derrotando link=static) con
esos DT_NEEDED literales. Verificado en el artefacto: CGO_ENABLED=0 y purego v0.10.0 presentes.
NO hay glibc: el rootfs Alpine no tiene NI UN libc.so.6, y el INTERP es musl (se construyó en el
sandbox). La musl los absorbe — su ldso reserva esos nombres y los resuelve a sí misma. Strings
vestigiales, no dependencia real. Corre en musl puro (verificado con bwrap) y escanea de verdad.
OJO: en el laptop engaña — este host tiene glibc Y musl.
FIX = declarar la verdad. link=static es INALCANZABLE por diseño: purego existe para dlopen, y un
estático no puede dlopen. cgo=true tampoco sirve: el lab liga con -extldflags=-static ⇒ mismo muro,
y lobotomizaría el escaneo SYN en silencio.
DATO DURO: el binario nuevo es BYTE-IDÉNTICO al viejo ⇒ link=static nunca hizo NADA en recetas Go
(go build no lee LDFLAGS con CGO off): era pura declaración falsa. Las demás recetas Go pasan el
audit por accidente — sin purego, CGO_ENABLED=0 da estático natural.
TICKET APARTE (no tocado): naabu no declara libpcap y NO existe recipes/libpcap.toml. El escaneo
SYN —su feature principal— está INERTE hasta que exista. No es expresable en [deps] hoy: no se
linkea, se dlopenea.
Van 5 de 11.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eran 47 el 2026-07-16. Desde entonces se migraron 31 y nadie actualizó el doc, así que el frente
se leía 3x más grande de lo que es. Recontado hoy: 16 = 4 C (file/libgcrypt/libsodium/linux-pam)
+ 12 Rust con sys-crate C.
CÓMO CONTAR, documentado en el doc: NO con grep. `grep -l 'compiler = "gcc"' recipes/*.toml` da
18 — cuenta bzip2 y pigz, que ya son zig-cc y sólo MENCIONAN gcc en un comentario. El grep no
distingue campo de comentario; hay que parsear el TOML. (Me comí ese error yo mismo antes de
medirlo bien.) Y la otra dirección también engaña: pigz DECLARABA zig-cc y construía con gcc igual
(7d86dbf) — la receta dice la intención, harkaq dice el hecho.
xplr estaba mal clasificada como 'C puro': es Rust (embebe mlua-sys, que compila Lua en C).
LO QUE IMPORTA — las 12 Rust no son 12 problemas, son uno: bajo zig-cc el link falla con símbolos
de unwinding sueltos (_Unwind_GetCFA/_Unwind_DeleteException) que aporta libgcc. La deuda no es
'zig miscompila 12 programas', es 'falta un runtime de unwinding para el C de los sys-crates'.
Y converge con el frente static: helix y tuc salían dinámicas arrastrando libgcc_s.so.1 de Alpine
DENTRO del binario — la misma libgcc, la misma razón, medida en runtime en vez de en build. Un fix
del unwinding cerraría los dos frentes a la vez. Precedente: cmake se arregló con
-static-libstdc++ -static-libgcc.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Las dos enlazan con libtool, que lee el LDFLAGS=-static del lab como 'preferí mis .a' y no como
flag al linker ⇒ salían dinámicas (NEEDED: libc.so) jurando ser estáticas. Patrón conocido:
-all-static en compile Y en install (libtool RELINKEA al instalar; sólo en compile se pierde en
silencio). Nunca en configure.
file: el ./configure venía metido DENTRO de la fase compile (herencia del import de abuild,
envuelto en _abuild_phase()). Partido en configure/compile/install explícitos + --disable-shared
(sólo tenía --enable-static). NEEDED=0, file --version = file-5.47, y clasifica de verdad
(MAGIC=<art>/usr/share/misc/magic.mgc file /bin/sh → 'symbolic link to bash').
libgcrypt: ya tenía fases; sólo -all-static conservando --with-libgpg-error-prefix/--disable-doc.
NEEDED=0 en los 3 ELF (hmac256, dumpsexp, mpicalc) y hacen trabajo real: hmac256 devuelve un HMAC
efectivo, mpicalc '2 40 + p' → 42.
CONTROL del gotcha de xz (lista de ficheros vs el sellado viejo): idéntica en ambas — file conserva
libmagic.a + magic.mgc + mans; libgcrypt sus 3 binarios + libgcrypt.a + libgcrypt-config. No se
perdió nada.
Siguen con compiler="gcc" a propósito: el fix es ortogonal al compilador y migrarlas es el frente
matar-gcc. No hay evidencia nueva de que compilen con zig-cc — no se probó.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
.farm-harvest/ son 438 dirs <hash>-<nombre>: artefactos del store cosechados de la granja, 26G.
Nació de un rsync a mano — ningún script, doc ni commit del repo lo referencia — y quedó SIN
ignorar, así que un `git add -A` habría intentado commitear el store entero. Justo el accidente
que la regla 'nunca git add -A' (otro agente comparte el working-tree) existe para evitar.
Las 438 están YA en ./store, verificadas una a una (no por muestreo). Como el store es CAS —el
nombre ES el hash del contenido— mismo nombre = mismos bits por construcción ⇒ es 100% redundante.
No lo borro acá: 26G de disco son del usuario, no míos. Queda ignorado, que era el riesgo real.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El smoke de harvest-go.sh ejecutaba cada binario cosechado con el cwd en la RAÍZ DEL REPO, así que
un binario que escribe estado al arrancar dejaba basura entre las fuentes. Pasó: `gocron version`
—y `version` es justo el PRIMER flag que prueba el smoke, así que se disparaba siempre— sembró
config/{config.yaml,db.sqlite} (5 jobs de ejemplo + una sqlite) el 2026-07-04, y quedó sin trackear
hasta hoy. Medido, un flag a la vez, en cwd limpios:
[version] DEJO: ./config ./config/db.sqlite ./config/config.yaml
[--version] limpio [-v] limpio [--help] limpio [-h] limpio
Un `--help` no debería poder tocar el repo. El smoke ahora corre en un mktemp -d que se borra.
Vale para cualquier herramienta futura, no sólo gocron.
Sin regresión en el veredicto: en tmpdir `gocron version` panica (le falta web/index.html), el
smoke ya trata el panic (continue) y pasa a --version, que funciona ⇒ gocron sigue aprobando.
config/ borrado (no trackeado, sin una sola referencia en scripts/recetas/código).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
756928a generalizó de más. El alcance real, medido dentro del sandbox con readelf sobre un
`int main(){return 0;}` trivial:
zig 0.13.0: -static → NEEDED=1 (dinámico) ← el bug
zig 0.13.0: -target x86_64-linux-musl -static → NEEDED=0 (estático)
zig 0.16.0: -static → NEEDED=0 (estático) ← default, sano
O sea: el -static roto es de ZIG 0.13.0, NO del framework. Con el zig default el -static que el
lab exporta por link="static" funciona ⇒ CC sin -target (sandbox.rs:415) está BIEN y NO hay que
re-hashear los 841 sellados, al revés de lo que decía 756928a. samurai lo sufría por caer en la
intersección de dos rarezas: pinea zig 0.13.0 Y no usa libtool (nada absorbía el -static).
Las otras 4 recetas con zig 0.13.0 + link=static (mtools/openssh/openssl/xorriso): auditadas,
0 mienten — usan libtool, que absorbe el -static por su cuenta.
pkgconf: el diagnóstico ORIGINAL (libtool se come el -static) era el correcto. Usaba el BuildSys
automático ⇒ fases explícitas sólo para meter -all-static en compile Y en install. Estático de
verdad (NEEDED=0).
Van 2 de 11: samurai, pkgconf.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
samurai declaraba link=static y salía DINÁMICO (NEEDED: libc.so). No usa libtool, así que el
patrón -all-static de jq/parted/shadow no aplicaba. Medido DENTRO del sandbox con readelf, sobre
un `int main(){return 0;}` trivial:
zig cc -mcpu=baseline -static → NEEDED=1 (dinámico)
zig cc -mcpu=baseline -target x86_64-linux-musl -static → NEEDED=0 (estático)
El lab exporta CC="zig cc -mcpu=baseline" SIN -target (sandbox.rs:415) ⇒ zig compila NATIVO,
detecta la musl de Alpine del rootfs (/usr/lib/libc.a existe) y enlaza contra ella IGNORANDO el
-static que el propio lab exporta por link="static". El -target fuerza la musl bundleada de zig.
Las recetas YA declaran target = "x86_64-linux-musl": el campo existe y no llega al CC. El fix
de framework re-hashea los 841 sellados ⇒ decisión aparte; por ahora va por receta.
samurai: estático de verdad (NEEDED=0), corre en el host, samu --version = 1.9.0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
recipes/incoming/ es la cola del stack gráfico tawasuyu, de otro agente. Sus 7 recetas son
imports crudos de Alpine con sha256='FIXME-sha256' y deps sin expandir (clang$_llvmver, _dev,
py3-gpep517) ⇒ NO construibles por construcción. El worker las fallaba en CADA vuelta (CPU
pagada) y farm-down repetía los 6 errores al bajar, con pinta de ser nuestros.
Su trabajo YA aterrizó por la vía canónica (7131cd4 'MESA iris-only CONSTRUIDA — stack gráfico
COMPLETO'), así que la cola quedó obsoleta. Pero NO es nuestra para borrarla: 370e7b7 ya la
parqueó una vez como cruft y 5126a8b tuvo que revertirlo. Dejamos sus ficheros en paz y sólo
los sacamos de QUEUES.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Petición explícita del usuario: gioser.net es FIJO y NO TIENE BACKUP. Vive en el
MISMO proyecto hcloud que los workers, y Hetzner no da tokens por-recurso: el
token que el dead-man switch necesita para auto-borrarse puede borrar CUALQUIER
server del proyecto. farm-down era peor: borraba por NOMBRE leído de .fleet sin
verificar NADA — un nombre equivocado en esa lista y adiós.
Dos capas, porque una sola no basta cuando el fallo es irreversible:
1. LISTA NEGRA por nombre (gioser*) — explícita y legible.
2. LABEL role=hammer-worker — sólo se borra lo que NACIÓ de farm-up. Ésta es la
capa fuerte: no depende de mantener una lista al día. Un server que no es
worker no se borra, punto.
VERIFICADO contra los servers vivos, no en teoría:
gioser labels=map[] ⛔ PROTEGIDO
hworker-4 labels=map[role:hammer-worker] BORRABLE
Y .fleet sólo contiene hworker-4.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dos fallos de raíz, no uno:
1. HABÍA DOS CAMINOS de crear workers. harkaq-vol.sh ya tenía volumen Y
automuerte desde la 1ª campaña; farm-up.sh no tenía ninguna de las dos.
hworker-4 nació por farm-up ⇒ 5 días idle con 37G que nadie salvó. La
protección existía y el camino que usé la esquivaba. Ahora farm-up monta el
MISMO volumen (harkaq-cosecha) ⇒ collect/close cosechan y clausuran ambos.
2. NI harkaq-vol salvaba los artefactos: su rsync excluye /store y el volumen
sólo guardaba verdicts/ y logs/. Los 438 artefactos KDE se habrían perdido
igual.
FIX: el store del worker ES /mnt/cosecha/store (symlink desde /store).
Sellar YA es persistir: cada artefacto está en el volumen en el instante en que
se crea. "Guardar lo generado" deja de ser un paso que puede fallar antes de
morir y pasa a ser la estructura.
⇒ la automuerte puede ser INCONDICIONAL. Quitada la guarda "no borrar si hay
cosecha pendiente": era el bug de hworker-4 con otra cara — el worker se queda
VIVO justo cuando hay trabajo que salvar. Un switch que se desarma solo cuando
más falta hace no sirve. Antes de morir sólo sync+umount: no es guardar (ya está
guardado), es cerrar la puerta al salir.
El volumen sobrevive al server a propósito (~€0.044/GB/mes). El baseline €0 lo
da harkaq-vol.sh close, que es decisión del usuario, no de un timer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
hworker-4 estuvo 5 DÍAS idle (carga 0.00, sin crontab, sin loops, 37G de KDE
sin cosechar) quemando dinero. El usuario había pedido esto explícitamente
—"los vps se autoapagan cuando se detectan idle por un tiempo"— y de sus 3
puntos (volumen / auto-apagado / cosecha) implementé el 1 y el 3. Éste faltaba.
EL FALLO ERA ESTRUCTURAL, no un olvido: farm-down.sh existe pero es MANUAL. El
modelo "efímero" dependía de que el agente se acordara de llamarlo — y si su
contexto se corta, o la sesión muere, el server queda vivo para siempre. Un
invariante que necesita que alguien recuerde NO es un invariante. Por eso el
switch vive EN EL WORKER: para apagarse no necesita ni al hub ni a mí.
BORRA, no apaga: en Hetzner un server apagado SIGUE COBRANDO (disco + IP). Un
poweroff daría sensación de ahorro y seguiría facturando. Precio: el token vive
en el worker (/etc/hammer-deadman.env 0600). Riesgo real y consciente; se acepta
porque la alternativa MEDIDA fue peor: 5 días de VPS idle.
Cuenta por INACTIVIDAD CONTINUA, no por antigüedad: cualquier señal de trabajo
(hammer build, worker-loop, heartbeat <30min) resetea los ticks. Guarda
/var/lib/hammer-no-borrar aborta el borrado si hay cosecha pendiente.
systemd timer y NO cron, por la lección medida: un cron "validado a mano" nunca
disparó porque el PID 1 de aquella máquina (arje-zero) no tenía crond. Validar
la LÍNEA no es validar que un demonio la ejecute. y el
farm-up comprueban que el timer quedó ACTIVO — evidencia, no fe.
Cableado en farm-up: todo worker NACE con el switch puesto.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Segunda de las 3 con gcc oculto en las fases (tras bzip2). La receta declaraba
compiler=zig-cc y su compile pasaba CC=gcc ⇒ el gcc de Alpine hacía el trabajo.
El frente contaba compiler="gcc" y no miraba las fases, así que pigz nunca
figuró como deuda. Queda cargo-edit de esa terna.
CC="$CC" usa el zig cc que el sandbox exporta por default (lib.rs:269,
Compiler::ZigCc no pisa CC).
Verificado: 0 NEEDED, corre en el host (pigz 2.8), comprime/descomprime,
bit-repro b3:f5614e5b6b0a ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
367 ficheros, lista intacta vs el sellado viejo. b3:2a937a913b52
LDFLAGS="-all-static -no-pie" inyectado en las líneas make de compile e install.
samurai revertida: con -static su binario (samu) SIGUE dinámico ⇒ el control la
echó atrás. libcap revertida: mi regex rompió el TOML (parse error línea 37);
su make ya pasa CC/BUILD_CC/AR explícitos y necesita mano, no regex.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El audit tomaba 'ls -d store/*-<n> | head -1' = orden ALFABÉTICO POR HASH, no el
artefacto vigente. El store guarda TODOS los sellados de una receta (expat tenía
5, de junio a hoy), así que auditaba uno de hace tres semanas. Mismo bug de
clase que comparar libpng.a con libpng16.a por find|head -1.
Con 'ls -dt' (más reciente): 28 → 11. Tres de las supuestas mentirosas
(cargo-audit, git-absorb, yazi) nunca lo fueron: su artefacto reciente ya era
estático y el audit leía el viejo.
Lo que NO cambia: el hallazgo central es real y verificado a mano. libtool
ignora el -static del lab, el curl sellado NO arrancaba en el host, y de las 14
que arreglé cada una se verificó contra sus artefactos previos (expat: los 4
viejos con NEEDED=1, el nuevo con 0). Estaban rotas de verdad.
HONESTIDAD escrita en el script: 'más reciente' ≠ 'vigente'. Lo vigente sería el
artefacto cuyo hash corresponde a la receta de HOY, y hammer no lo expone sin
construir (no hay hammer hash / dry-run). Por eso el audit va DESPUÉS del
rebuild, nunca antes.
Quedan 11: file, helix, libcap, libgcrypt, pcre2, pkgconf, samurai, tuc,
util-linux, xz + naabu (nuevo: Go con libc.so.6 de GLIBC, otro caso).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fases multilínea: LDFLAGS inyectado en las líneas make de compile e install.
Control de lista de ficheros intacta: libwebp 33, kbd 689, sudo 32, lsof 4.
libwebp b3:138b70a6962f · kbd b3:248de1120197 · sudo b3:6fdbe83990ef ·
lsof b3:d30ddb01b86e
mandoc revertida: no usa libtool ("Unknown Clang option: '-all-static'") y con
-static pierde binarios (apropos, demandoc) ⇒ el control la echó atrás. Necesita
otro enfoque, como xz y pcre2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
parted es el caso didáctico: YA tenía -all-static en compile — era el precedente
que citaban jq/shadow/procps-ng — y aun así salía dinámico, porque le faltaba en
INSTALL. libtool RELINKEA el binario al instalar y ahí pierde el flag. El
patrón citado estaba a medias, y por eso el propio precedente mentía.
libarchive: mismo patrón, forma de fase con comillas dobles.
Control de lista de ficheros intacta: parted 23, libarchive 55.
parted b3:1f2046dde4dd · libarchive b3:238f1fdfc704
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mismo patrón de libtool: LDFLAGS="-all-static -no-pie" en compile Y en install.
El control duro (lista de ficheros vs sellado viejo + 0 NEEDED en TODOS los
ejecutables, si no revierte) hizo su trabajo: pcre2 salió del build con
pcre2grep y pcre2test todavía dinámicos y se revirtió sola. Sin ese control
habría entrado como "arreglada" — es la misma trampa de xz, que devolvía rc=0
con el artefacto mutilado.
sqlite b3:235b18d98f18 (8 ficheros) · libgpg-error b3:8ccbe32ccb41 (36) ·
fontconfig b3:ad960af29ef5 (65) — todas con la lista de ficheros intacta.
Quedan 20: 9 con forma de fase distinta (mandoc, libwebp, kbd, parted, sudo,
libarchive, lsof, samurai, pkgconf, libcap: van a mano), pcre2 y xz que
necesitan otro enfoque, y 5 Rust (helix, yazi, git-absorb, cargo-audit, tuc)
que arrastran libgcc_s por crt-static, no por libtool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mismo patrón que curl: LDFLAGS="-all-static -no-pie" en compile Y en install,
porque libtool relinkea al instalar.
Verificado con un CONTROL que xz obligó a añadir: no basta rc=0 + hash. El
build de xz con -all-static devolvió rc=0 y hash válido, pero el artefacto SALIÓ
SIN NINGÚN BINARIO (el viejo tenía xz, xzgrep, xzdiff, xzless, lzmainfo): con
-all-static, libtool no produce la lib compartida (liblzma.la -rpath) y el
enlace de los ejecutables se saltea EN SILENCIO. Un "éxito" que mutila el
paquete. xz queda revertida: necesita otro enfoque (separar la lib de los
binarios), no este patrón.
⇒ el criterio ahora compara la LISTA DE FICHEROS del artefacto nuevo contra la
del viejo, además de NEEDED=0. Los tres pasan: 15, 13 y 114 ficheros, idénticos
a sus sellados previos.
expat b3:e6990b3e555f · libpng b3:f65887051274 · libxml2 b3:c4c65c4b17b8
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El frente contaba `compiler = "gcc"` y no miraba las FASES. bzip2 declaraba
compiler=zig-cc y decía "migrado de gcc, matar-gcc 2026-07-16" en la cabecera,
mientras su compile pasaba `CC=gcc`: migración cosmética, cambió el campo y no
el build. El Makefile de bzip2 además HARDCODEA CC=gcc, así que un `make` a
secas tampoco habría usado zig.
Barrido: 7 recetas invocan gcc en sus fases sin declararlo. 4 son escapes ya
conocidos (los 3 kernels + cmake); las otras 3 son deuda que nadie contaba:
bzip2 (ésta), pigz y cargo-edit.
De paso cumple link=static: el -static que hammer exporta (lib.rs:261) se
pierde si la receta no lo pasa al make de un Makefile custom.
OJO -static y NO -all-static: -all-static es flag de LIBTOOL (patrón de
jq/parted/shadow/procps-ng); bzip2 usa Makefile crudo y el flag llega tal cual
al compilador → "error: Unknown Clang option: '-all-static'".
Verificado: 0 NEEDED, corre en el host, comprime/descomprime, bit-repro
b3:48b91bb1b658 ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primera de las 28 que static-audit.sh destapó. libtool ignoraba el -static del
lab (lo lee como "preferí mis .a"), así que el curl sellado salía dinámico con
NEEDED libz.so.1 + libc.so — y libc.so es el soname de la musl de zig, que en
el host son 255B de linker script. Resultado: el artefacto NO arrancaba fuera
del sandbox ("Error relocating /lib/libz.so.1: __snprintf_chk").
Fix: LDFLAGS="-all-static -no-pie" en compile Y en install (libtool relinkea
al instalar); nunca en configure, donde rompería los link-tests.
Verificado: 0 NEEDED, corre en el HOST (curl 8.20.0, OpenSSL/3.5.4, zlib/1.3.1)
y hace HTTPS real (http=200). Bit-repro: b3:19a919b28c25 ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Destapado migrando procps-ng. libtool lee el -static del lab como "preferí mis
.a", NO como flag al linker: el binario sale dinámico y la receta jura que es
estático. Con gcc pasaba igual — no es regresión de zig, es un agujero que
nadie había medido.
Tres consecuencias medidas, no teóricas:
1. NO CORREN. El curl sellado en el host: "Error relocating /lib/libz.so.1:
__snprintf_chk: symbol not found". Su NEEDED libc.so es el soname de la musl
de zig; en el host /lib/libc.so son 255B de linker script. El artefacto sólo
funciona dentro del sandbox.
2. ARRASTRAN GCC. helix, yazi, git-absorb, cargo-audit y tuc traen libgcc_s.so.1
de Alpine DENTRO del binario. Deuda de matar-gcc que ningún compiler="gcc"
declara: invisible para el frente entero hasta ahora.
3. Un NEEDED es una entrada no declarada — lo que harkaq mide en build, pero en
RUNTIME. Rompe el cono de affected.py (SDD 17 §4): un CVE en zlib no
alcanzaría a un curl que se declara estático.
Script, no gate duro: fallar hoy rompe 28 selladas de golpe, varias del sistema
base (curl, util-linux, sudo). Primero se arreglan con evidencia, después se
cierra la puerta. Exit 1 mientras haya mentirosos ⇒ sirve de gate en CI cuando
la lista llegue a cero.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
31 migradas. La justificación escrita ("gueto, como vim/nano/htop") había
caducado: vim/nano/htop ya estaban en zig-cc. Tres problemas reales, ninguno
"zig miscompila":
1. rpl_realloc: la musl que zig bundlea (estática) devuelve NULL para
realloc(p,0); AC_FUNC_REALLOC acierta y hace #define realloc rpl_realloc,
pero procps-ng no trae esa función (la pide por AC_LIBOBJ y ningún
Makefile.am usa @LIBOBJS@) ⇒ roto upstream en cualquier libc que conteste
"no". Se suprime el renombrado por cache vars; no afirmamos que realloc sea
GNU-compatible. Afectará a todo autoconf con AC_FUNC_REALLOC/MALLOC.
2. SIGSEGV: el binario salía musl-DINÁMICO con NEEDED libc.so. libtool lee el
-static del lab como "usá mis .a", NO como flag al linker ⇒ link=static
nunca se cumplió, ni con gcc. Fix con el patrón de jq/parted/shadow:
LDFLAGS="-all-static -no-pie" en compile Y en install (libtool relinkea al
instalar), nunca en configure.
3. UBSan: zig-cc lo activa por defecto; ps --sort=-rss aborta en sortformat.c
(offset sobre puntero nulo, UB genuino de upstream pero inocuo). Patrón de
libarchive/dwarves: -fno-sanitize=undefined.
Bit-repro verificado; 18 binarios responden y ps --sort da salida idéntica a gcc.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sin parches ni flags: el config.sub de wget 1.25.0 ya conoce -musl* y el
configure no se atraganta con AR="zig ar". Bit-repro verificado (2 builds
desde cero, mismo hash) y la ruta openssl viva (descarga HTTPS real, exit 0).
Como link=static, el ELF no tiene sección dinámica: cero NEEDED ⇒ no arrastra
libgcc_s/libstdc++ de Alpine. El comentario viejo listaba gcc como parte de la
de-Alpinización, que era justo al revés; corregido.
30 migradas. Quedan 17: 12 Rust con sys-crate C (cc-rs invoca el compilador del
sistema desde los build-scripts), 4 matraca dura, procps-ng en vuelo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
zlib-ng: el veredicto T5 hecho receta — dispatch SIMD en runtime en vez de
variantes v3; modo ZLIB_COMPAT, zlib.toml intocada (dep del frente rust).
dwarves: pahole para destrabar sched-ext; el kernel NO lo declara aún (el
análisis de repro BTF/pahole-skew va primero). Ambas al worker.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- harkaq-trace.c: fanotify FAN_MARK_FILESYSTEM — agnóstico de mount-ns, el
tracer en el HOST ve los open() de dentro del bwrap (ptrace lo deniega el
seccomp D4; audit sólo emite denegaciones). Crudo y tonto a propósito
(reparto Q1c); D9: sin fanotify ⇒ exit 3 SinEvidencia, jamás traza vacía.
- harkaq-trace-norm.py: canoniza (drop /proc /sys /dev /tmp /out /src, dedupe,
orden estable — la lección nº1 de META MODE) + atribución por dep con
--resumen = la señal de PODA (T1.4): dep declarada con 0 toques = grasa.
- VALIDADO: modo --fs como root (worker, 5s, sin tocar colas): capturó
exactamente zlib.h + 3×libz.a de un cat/head; laptop sin privilegio ⇒
SinEvidencia honesto. Piloto completo (traza de un hammer build real +
resumen de poda) pendiente de un rebuild natural en el worker.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
El bug que declaró `busybox` en 29 recetas y rompió binutils: harkaq-suggest veía
`/bin/busybox` denegado, encontraba `recipes/busybox.toml` en el store y decía
"declarar dep: busybox" — sin mirar que la política YA lo concede (`ro /bin/busybox`:
el sandbox corre `sh -c` y /bin/sh→busybox ⇒ es CONTRATO, no dep).
Fix: harkaq-suggest ahora lee los paths CONCEDIDOS de la política (`ro`/`rw`/`list`),
no sólo los `# expect`. Si un path está concedido ⇒ categoría RUNTIME BASE: no se
declara, aunque el store lo provea.
Las 4 clasificaciones verificadas tras el cambio:
/bin/busybox → RUNTIME BASE (ya concedido; NO declarar) ← el fix
/usr/bin/make → DECLARABLE (declarar dep: make)
/usr/lib/libstdc++.so → IRREDUCIBLE (nadie lo provee)
/usr/bin/gcc en broot → DEUDA DE COMPILADOR (compiler=gcc)
/usr/bin/gcc en zlib → sin deuda (sonda esperada; zlib compila con zig)
Con esto puesto, busybox JAMÁS se habría declarado. Cierra el TODO que dejó el
revert: la campaña automática ya no puede cimentar contrato como dependencia.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DOS ERRORES MÍOS, uno de dirección y otro técnico, los dos en la cosecha automática:
1. DIRECCIÓN: declaró `busybox` como dep en 29 recetas — cuando la Etapa C lo está
ELIMINANDO (USERLAND_COMPONENTS=[uutils,findutils,…], ya cerrada; joyas-reusables
§5 lo confirma: "uutils… Ubuntu 25.10 los envía como default"). Estaba cimentando
la deuda que el roadmap borra.
2. TÉCNICO: busybox YA está en el runtime base de harkaq (`ro /bin/busybox`, `ro
/bin/sh` — el sandbox corre `sh -c` y /bin/sh→/bin/busybox). Es CONTRATO, no dep.
Declararlo apila el busybox de hammer sobre el de Alpine y ROMPE el build:
binutils daba "cannot run C compiled programs" en las DOS máquinas. Verificado:
sin busybox declarado, binutils construye (b3:f4507dcd…). Y la cadena se explica:
binutils roto ⇒ zlib (que lo declara) tampoco construía.
Auditoría de la cosecha (diff real, no la línea completa del +): añadió sólo 5 deps
distintas — make ×73, busybox ×29, perl ×8, pkgconf ×5, binutils ×1. Sólo busybox
estaba mal; las otras 4 son deps reales medidas. busybox revertido de 30 recetas
(queda sólo en busybox.toml, pre-existente).
Es el mismo error que ya me habían señalado con otro disfraz: MEDIR BIEN Y ACCIONAR
MAL. harkaq midió correcto (el build toca /bin/busybox: es el shell); la acción
correcta no era declararlo sino reconocerlo como contrato.
+ COORDINACIÓN del §3 con Fable 5 (mismo diseño, tareas repartidas):
- Su lección casper queda CONFIRMADA y REFORZADA: la clausura de build no sólo le
FALTAN las clases del mundo (offline) — también le SOBRA casi todo (headers, gcc).
Medido: htop (estático, 0 NEEDED) no toca NADA al correr ⇒ política = su binario.
- Su "la clase viaja como campo de la ConcesionCapacidad, sin formato nuevo" se
cumple LITERALMENTE: lo firmado es format::Permisos = u32 bitmask en 36 bytes
canónicos (Ring 0) ⇒ las clases SON los bits. La cripto no se toca.
- Diseño unificado: frontera (clases, u32, declaradas) + detalle (paths, Landlock,
medidos). D3 rige en ambos.
- Reparto: clases→Fable 5; medición/harness→Opus. CONTACTO: runtime-policy.sh ahora
emite la CLASE detectada (/etc/resolv.conf→dns, /etc/ssl/certs→tls-certs, …), no
sólo el path: la medición alimenta la tabla, la tabla decide el bit.
- Consumidor esperando: plan-jaula-juegos F1 (Steam que no puede leer ~/.ssh).
+ juez.sh (§10): nombre único por corrida (con uno fijo pega en caché ⇒ falso
"sin evidencia"). Fue el juez quien destapó todo esto en su primera corrida real.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
sergioandClaude Opus 4.8