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.
Los llamadores EJECUTABLES: scripts/ (incluida toda la granja), los runbooks y
CLAUDE.md. Seguro porque la 3a ya garantiza que el worker emite los dos
binarios, y porque en farm-lab-sync.sh el cargo build remoto precede a la
invocación remota en el mismo script.
Verificado: sintaxis de los 49 (bash -n / py_compile — ojo que
why-differs-barrido.sh es Python con extensión .sh) y `takana hash` devuelve
hash real sobre el store.
NO se toca en esta etapa, a propósito:
- La variable de entorno HAMMER=. Es interfaz de los scripts entre sí y hay
llamadores que la fijan; renombrarla va con la etapa 4.
- docs/evidencia/ y los HANDOFF: son REGISTRO de lo que se corrió ese día.
Reescribir un comando dentro de una evidencia la falsifica.
- docs/state/: es generado, se regenera solo.
- Los ADR y los docs de diseño: texto, y `hammer` sigue funcionando. Van con
la etapa 5, que es la de churn de texto.
Un guardián que nunca falló no se sabe si sirve, y uno que falla SIEMPRE se ve
idéntico a uno que funciona. Por eso el control con el sysroot intacto —que
tiene que PASAR— no es un extra: es la mitad de la prueba. El método lo aportó
la sesión hammer-f8 (scripts/test-atuq-politica.py hace lo mismo con el cruce
política<->XPI).
Le pone delante a la cadena las cuatro formas conocidas de romperla —sin la
sonda include/c++/v1, sin cstring, sin libc++.a, sin libc.a— y exige que las
cuatro maten, usando la invocación EXACTA del configure de firefox dentro del
lab. No construye nada, no toma work/.farm-build.lock y no escribe en el store:
trabaja sobre copias temporales de artefactos ya sellados, así que corre con la
granja a pleno.
Y el control se ganó el sueldo en su primera corrida: salió en ROJO. La causa no
era un guardián flojo sino este script, que resolvía el artefacto con
y agarraba el VIEJO —el de antes de que la
receta creara el directorio-sonda—. Misma trampa que el cache-hit que congela
regresiones: un artefacto anterior se hace pasar por el actual y la prueba mide
otra cosa. Sin el control se habría leído como «4 en verde, guardianes ok».
Ahora el artefacto se resuelve por de la receta, nunca por glob.
5 en verde, 0 en rojo.
Sergio