tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1569Shell 203Rust 109Markdown 993728 Sutichaykuna

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.

ffa203910f1677b3df1042107a6ad0af62326977 · ruwaq Sergio · (1 killa ñawpaq) · tayta cc425c561 · kay commitpi sach'ata qhaway

Semántico sayk'uy

Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.

1 qillqakuna · +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`,