From 0f46c0976b36703ac8bdbe570a4b096921bcbe39 Mon Sep 17 00:00:00 2001 From: Sergio Date: Fri, 18 Sep 2026 18:52:31 +0000 Subject: [PATCH] =?UTF-8?q?atuq:=20un=20`.pyc`=20invisible=20mov=C3=ADa=20?= =?UTF-8?q?el=20hash=20=E2=80=94=20el=20hub=20sellaba=20algo=20que=20un=20?= =?UTF-8?q?clon=20limpio=20no=20reproduce?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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`. --- recipes/atuq.toml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) 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: