CLAUDE.md §3.bis: el scratch de build caía en el overlay desechable, con 223 G al lado sin usar
`work_root` sale de `dirname(store)/work`, y con el store en `/store` el padre es `/`: todo el scratch iba al overlay de 69 G de la jaula, que además es capa DESECHABLE — la caché de fuentes vivía en algo que se tira. Mientras tanto `/dev/sdc`, 255 G, estaba al 9 %. De los 6,8 G de `work/sources`, 5,4 G eran DOS COPIAS del mismo commit de tawasuyu: los árboles se nombran por receta, no por commit, así que cada receta del monorepo cuesta otros 2,7 G. Queda anotado que es deliberado (aislamiento del ADR 0012) y que no se deduplica de paso. Arreglado con enlaces a `/work/sergio/work` en vez de con `TAKANA_WORK`: el override existe y funciona, pero una docena de scripts llama a `takana build` y un export que hay que recordar se olvida. Comprobado con un build real sin ninguna variable — rc=0, el árbol cayó en sdc y el hash salió idéntico al de la corrida anterior. Overlay de 6,9 G a 14 G libres. Anotado también que el worker NO tiene este problema (un solo disco de 196 G), que los enlaces se van si la jaula se rehace, y que la premisa del `seal` (rename atómico ⇒ mismo filesystem) ya estaba rota en el hub antes de esto, porque `/work` y `/store` son discos distintos.
Semántico sayk'uy
Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.
1 qillqakuna · +38 −0
- CLAUDE.md +38 −0
diff --git a/CLAUDE.md b/CLAUDE.md
index f06c426f..ecc62a11 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -218,6 +218,44 @@ Un directorio **vacío** en el store no es un artefacto: es un nombre. `Store::h
sigue valiendo para cualquier código nuevo — **un ausente falla ruidosamente; un vacío llega hasta
el final diciendo que todo fue bien**.
+## 3 bis. En el HUB, el scratch de build no cae donde parece — y el disco bueno estaba sin usar
+
+⚠ **Medido el 2026-09-21.** `work_root` no es una ruta elegida: sale de `dirname(store)/work`
+(`crates/takana-build/src/config.rs`). Con el store en `/store`, el padre es `/` ⇒ **todo el scratch
+de build cae en el overlay de la jaula**. En esta caja eso son 69 G compartidos, y el disco de
+verdad —`/dev/sdc`, 255 G— estaba **al 9 %, sin usar**.
+
+Dos cosas lo empeoran, y ninguna se ve desde `df`:
+
+- **El overlay es capa DESECHABLE.** `/work` no tiene montaje propio: si la jaula se rehace, los
+ árboles de fuentes se van con ella. La caché de build vivía en algo que se tira.
+- **Los árboles se nombran por RECETA, no por commit.** `boveda` y `shuma-pregunta` salen del mismo
+ `b80f7567…` de tawasuyu y ocupaban **2,7 G cada una** — 5,4 G de los 6,8 G totales eran el mismo
+ contenido dos veces. Cada receta nueva de ese monorepo cuesta otros 2,7 G. Es deliberado (árbol
+ por receta = el aislamiento que evita el destrozo del ADR 0012); **no deduplicar de paso.**
+
+**Arreglado con enlaces, no con una variable de entorno**, porque una docena de scripts llama a
+`takana build` y un `export` que hay que recordar se olvida:
+
+```sh
+ln -sfn /work/sergio/work/sources /work/sources
+ln -sfn /work/sergio/work/out /work/out
+```
+
+Comprobado con un build real contra un store tirable y **sin ninguna variable**: `rc=0`, el árbol
+cayó en `sdc` y el hash salió idéntico al de la corrida anterior. El overlay pasó de **6,9 G a 14 G
+libres**. Existe `TAKANA_WORK` como override (junto a `TAKANA_LAB`/`ROOTFS`/`ZIG`/`CACHE`) y
+funciona, pero el enlace no se puede olvidar.
+
+⚠ **Si la jaula se rehace, los enlaces se van y el scratch vuelve al overlay en silencio** — nada
+falla, sólo se llena otra vez. Rehacerlos es lo de arriba; el contenido sigue en `/work/sergio/work`.
+
+**El WORKER no tiene este problema:** un único disco de 196 G con todo encima (`/`, `/opt/takana`,
+su store), así que ahí `work_root` y el store comparten filesystem y el `seal` —que es un `rename`,
+atómico sólo dentro del mismo fs— cumple su premisa. **En el hub esa premisa ya estaba rota** antes
+de este cambio: `/work` en `sda4` y `/store` en `sdb` son discos distintos. Mover el store al disco
+grande lo restauraría, pero es su propia unidad de trabajo — toca la granja, el hub y los scripts.
+
## 4. La superficie de la CLI va en INGLÉS; los mensajes, en castellano
Subcomandos, flags y nombres de opciones: **inglés** (`build`, `hash`, `hydrate`, `mirror push`,