250 líneas de comentario en 151 scripts. Control verificado: el diff no toca
NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa.
El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces:
las tres eran el MOTD que el script escribe DENTRO de la imagen construida —
texto del producto, no comentario del script. Se cambiaron aparte y a
propósito, que es rebranding, no limpieza.
Y el hallazgo caro: casaba contra ,
que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate.
La etapa 4 lo movió a y el script quedó casando NADA. No fallaba:
imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado
con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y
tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja.
Además 14 rutas de módulo en docs, que el barrido anterior no tocó
porque no es frontera de palabra.
El driver marca FALLA en la receta que invocó, pero `hammer build` construye
deps recursivamente: si una dep muere, la FALLA sale a nombre del dependiente.
El 2026-08-27 siete recetas figuraban rotas (xdg-desktop-portal, gnome-desktop,
gjs, gdm, gnome-session, gnome-settings-daemon, gnome-shell) y ninguna lo
estaba: los 1978 errores los emitía gdk-pixbuf. Los tiempos de 2-10 s son la
firma — demasiado rápido para ser un build propio.
Método: quitar ANSI, partir el log por los marcadores `fetch … name=X` y
atribuir cada error al último fetch anterior. Ya destapó dos causas reales
(gdk-pixbuf/gif y gtk4/PIC) y desinfló la lista de la frontera _ssl, donde
`No module named` lo emite SÓLO spidermonkey.
Sergio