sergio/takana

Esa regla documentaba el arreglo del 21-sep —dos symlinks— y decía «si la jaula se rehace, los
enlaces se van: rehacerlos es lo de arriba». Eso ya no es lo que hay que hacer: la causa está
arreglada en `config.rs`, y seguir esa instrucción ahora sería trabajo inútil sobre un problema que
el código resuelve solo.

Se deja el síntoma escrito, porque alguien lo va a volver a buscar, y se marca el arreglo. Y queda
la lección, que es lo que se pagó DOS veces: el parche con enlaces se perdió al rehacer la jaula y
el 15-oct `/work` se llenó al 100 % con 15 G de scratch que debía estar en el disco grande. *Un
arreglo que hay que recordar no es un arreglo*, y eso vale igual para un `export TAKANA_WORK`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/CLAUDE.md b/CLAUDE.md
index 13f10002..6aa3b579 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -256,21 +256,25 @@ Dos cosas lo empeoran, y ninguna se ve desde `df`:
   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`.
+✅ **ARREGLADO EN EL CÓDIGO el 2026-10-15, y ya no hay nada que recordar.** Lo de abajo se deja
+porque explica el síntoma, pero **los enlaces NO hacen falta y no hay que rehacerlos.**
+
+La causa era que `defaults_for_store_with_lab` derivaba `work_root = dirname(store)/work` para que
+el scratch cayera en el filesystem DEL STORE —el `seal` es un `rename`, atómico sólo dentro del
+mismo fs—, y esa derivación **sólo lo consigue si el store no es un punto de montaje**. Acá
+`/store` es su propio montaje (`sdc`), su padre es `/`, y `/work` es `sda4`: la derivación hacía
+exactamente lo contrario de lo que pretendía, en silencio. Ahora, **si el store es punto de
+montaje, el scratch va dentro del store en `.work`** — mismo fs por construcción (`store_es_punto_de_montaje`
++ `work_root_para` en `config.rs`). El worker no se mueve: ahí store y padre comparten fs.
+
+⇒ En esta caja: `/store es montaje=true ⇒ work_root=/store/.work`. Sin variables y sin enlaces.
+
+⚠ **Lo que SÍ hay que recordar es la lección, porque se pagó dos veces:** el 21-sep esto se parcheó
+con symlinks (`ln -sfn /work/sergio/work/sources /work/sources`), **se perdieron al rehacer la
+jaula**, y el 2026-10-15 `/work` se llenó al 100 % con 15 G de scratch que debía estar en el disco
+grande. *Un arreglo que hay que recordar no es un arreglo* — y vale igual para un `export
+TAKANA_WORK` en una shell o en un script: el día que alguien construya desde otro sitio, el
+problema vuelve sin avisar. El override `TAKANA_WORK` sigue existiendo para casos deliberados.
 
 **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`,