sergio/takana

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`.

diff --git a/recipes/atuq.toml b/recipes/atuq.toml
index 50adc35d..02a30c84 100644
--- a/recipes/atuq.toml
+++ b/recipes/atuq.toml
@@ -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: