atuq: un .pyc invisible movía el hash — el hub sellaba algo que un clon limpio no reproduce

Buscando si los cambios de atuq habían llegado a la caja apareció esto: el hub y el worker
calculaban `b3:e556024b` y un clon limpio `b3:5156cb8f`, con los 52 ficheros versionados de
`recipes/atuq/` byte a byte IGUALES en las tres máquinas y la receta con el mismo md5.

La diferencia era un fichero de más: `tools/__pycache__/rebrand.cpython-314.pyc`, bytecode que dejó
alguien al correr `rebrand.py` dentro del repo. Comprobado en los dos sentidos — metiendo y sacando
ese .pyc en un clon limpio, el hash salta de `5156cb8f` a `e556024b` y vuelve.

Lo traicionero es que `__pycache__/` está en `.gitignore`: el árbol se ve limpio en `git status`
mientras el hash ya es otro. Y el artefacto sellado en el store era el de `e556024b` — o sea uno que
un clon limpio no puede reproducir jamás. Es la regla 3 al revés: no un vacío que pasa por lleno,
sino basura invisible que pasa por fuente.

`ArtifactHash::of_tree` no sabe de `.gitignore`, y son dos cosas legítimamente distintas; pero hoy
divergen por descuido y no por decisión. Queda escrito en la receta, con la comprobación barata al
lado, para las cuatro que usan `source.dir`. El `.pyc` se barrió del hub y del worker: las tres
máquinas ya convergen en `5156cb8f`.
This commit is contained in:
Sergio
2026-09-18 18:52:31 +00:00
parent 3609b50220
commit 0f46c0976b
+21
View File
@@ -15,6 +15,27 @@
# vive en `recipes/atuq/` y se hashea por CONTENIDO con `ArtifactHash::of_tree`, igual que ya se
# hacía con los `patches`. No hay commit que pinear y no hay fetch: editar un CSS mueve el hash.
#
# ⚠ **Y MUEVE EL HASH CUALQUIER FICHERO DEL ÁRBOL, INCLUIDOS LOS QUE `git` NO VE.** Medido el
# 2026-09-18: el hub y el worker calculaban `b3:e556024b` para esta receta y un clon limpio
# `b3:5156cb8f`, con los 52 ficheros versionados BYTE A BYTE IGUALES en las tres máquinas. La
# diferencia era **un solo fichero de más**: `tools/__pycache__/rebrand.cpython-314.pyc`, bytecode
# que dejó alguien al correr `rebrand.py` dentro del repo. Comprobado en los dos sentidos —metiendo
# y sacando ese `.pyc` el hash salta de uno a otro—.
#
# Lo que lo hace traicionero es que `__pycache__/` **está en `.gitignore`**: git no lo muestra, así
# que el árbol se ve limpio en `git status` mientras el hash ya es otro. Y el artefacto que estaba
# sellado en el store era el de `e556024b`, o sea **uno que un clon limpio no puede reproducir
# jamás**. Es la regla 3 de CLAUDE.md invertida: no un vacío que pasa por lleno, sino basura
# invisible que pasa por fuente.
#
# `ArtifactHash::of_tree` no sabe nada de `.gitignore` — y son dos cosas distintas a propósito: lo
# que no se versiona y lo que no entra al hash no tienen por qué coincidir. Pero hoy no coinciden
# **por descuido**, no por decisión. Hasta que eso se decida (ver el ADR que toque), las cuatro
# recetas con `source.dir` —`atuq`, `firmware-tigerlake`, `os-release`, `wasi-sdk`— se hashean con
# lo que haya en el directorio, y conviene comprobarlo antes de creerle a un sello:
#
# find recipes/atuq -type f | wc -l # 52 · si da más, algo se coló
#
# ══ v0.2: EL BRANDING VIVE DENTRO DEL ZIP ══════════════════════════════════════════════════════
# La v0.1 dejó el branding fuera porque había que mirar el árbol real antes de adivinar. Ya se miró,
# y lo que se encontró decide la forma de esta versión: