La cascada que temíamos no existía: los cinco consumidores declaran gcc-libs en `runtime`, que está
fuera de hash_inputs, así que ninguno se re-hasheó. 938 selladas, 3 ajenas, 0 en deuda, y las cinco
imágenes al 100 %.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rust selló en el worker (b3:6441302d…, 352 M, 17m47s de build), y con eso no queda ninguna receta en
deuda ni sin construir: base 74/74, cli 142/142, escritorio-mirada 41/41, metal-tigerlake 7/7 y
servidor 175/175.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
linux-firmware sella por primera vez (1,9 G, 4885 ficheros y los 2415 enlaces de WHENCE),
wireless-regdb entra al corpus y firmware-tigerlake deriva sus 55 blobs (wifi=28, i915=15, sof=10).
Con eso `metal-tigerlake` pasa de 2/6 a 7/7 y `cli` sigue en 142/142.
937 selladas, 3 ajenas, 1 en deuda: rust.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Regenerado tras sellar zsh estático y traer del store de la caja los tres artefactos que sólo vivían
allá (intel-ucode, sof-firmware, linux-generic; verificados por huella de contenido, no por `du`, que
cuenta directorios y difiere entre sistemas de ficheros).
Quedan tres: linux-firmware (nunca construida, bloquea a firmware-tigerlake) y rust en deuda.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`build-state-view.py` traía los cuatro estados del corpus cableados (sealed/debt/never/unhashable) y
contaba TODOS los nodos contra ese diccionario. `build-state.py` emite dos más —`wanted` (hueco
declarado en targets.toml, sin receta) y `ajeno` (imagen de qorpa, que no se construye desde
fuente)—, así que el visor moría con `KeyError: 'ajeno'` y el tablero HTML llevaba sin poder
generarse. O sea: agregar un estado nuevo rompía el tablero entero, en silencio para quien no lo
corriera.
Ahora los de fuera del corpus se cuentan aparte y se NOMBRAN en la leyenda —no se cuelan a la barra,
que es sobre `totals["recipes"]` y pasaría del 100 %—, y cualquier estado que aparezca mañana cae en
esa misma rama en vez de tumbar el visor.
De paso, el grafo regenerado: 930 selladas, 2 en deuda, 5 nunca, 3 ajenas; git ya figura sellado en
su hash nuevo (b3:215742cb…) y no arrastró a nadie, como decía el radio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con las ocho puertas en verde, lo único que queda de la mudanza son decisiones sobre datos. Esta
hoja las junta todas, ordenadas por tamaño, con lo que la herramienta se anima a sugerir POR UN
HECHO entre corchetes (servido / usado por un proceso vivo / caché / repo limpio con remoto) y en
blanco lo que sólo sabe el dueño.
Se decide editando el fichero y aplicando en una pasada:
python3 scripts/mudanza/planear.py --censo work/mudanza/censo-detalle.toml \
--decidir docs/state/mudanza-decisiones-pendientes.txt --target root@2.29.29.217
⚠ Y dice qué NO cubre, porque una hoja titulada «lo que falta» que omite 329 G se lee mal: no están
`/mnt/vvv` (monorepo, repo, store, rustup — el store ya está respaldado y los repos viven en el gitea
de la caja) ni los servicios y dominios, que ya están decididos y ejecutados.
Va a `docs/state/` y no a `work/`, que está en .gitignore: el fichero donde el usuario decide no
puede vivir sólo en la máquina que la mudanza borra.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El ciclo que corrió desde la caja (commit 45b5685a) dejó en `main` un `build-state*.json` diciendo
`unhashable: 936` y `unhashable: 1112` — o sea, que NO SE PUDO CALCULAR el hash de ninguna receta,
porque el lab entra en el ArtifactHash y esa máquina no lo tiene (§6.42).
Regenerado desde gioser, que sí lo tiene: 929 selladas de 936 · KDE 1105 de 1112. El grafo CIERRA y
el topo-sort pasa en los dos.
⚠ Lo que esto enseña sobre el propio fichero: un `build-state` con `unhashable` en el total no es
«el corpus está mal», es «quien lo generó no podía mirarlo». Los dos se leen igual en un tablero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio