sergio/takana

Es la cola que el SDD 26 §7.terdecies dejó dicha: `boveda` y `shuma-pregunta` seguían
pineadas en `6f0408d40`, o sea SIN `4f2b5eac7` — el arreglo de los cinco lectores de
`SEED_IDENTIDAD` que aplastaban tres estados en dos. Uno de los cinco es justo el que
pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al
entrar a la sesión», que es verdad si no hay seed sembrada y mentira si el llavero falló.

Se sube a `cd9acd0d9` —no a `4f2b5eac7`— porque es el que ya tienen `pacha` y
`pacha-secretos` y el que cierra el `Cargo.lock` (la arista `rpassword` que un merge
de import había perdido).

⚠ Y de paso se CORRIGE una premisa que estas dos recetas repetían tres veces y que el
SDD daba por buena: compartir commit NO comparte el árbol de fuentes. El árbol es
`work/sources/<NOMBRE DE RECETA>-<commit>` (fetch.rs, `format!("{}-{}")`) y además se
borra y se rehace en cada build, así que cada receta paga su copia y su `cargo vendor`
con el pin que sea. Ya estaba medido en CLAUDE.md §3 bis, con estas dos de ejemplo:
mismo `b80f7567…`, 2,7 G cada una.

b3:5c43a827 → b3:1b7365bf (boveda) · b3:cd4277c5 → b3:fcc745e8 (shuma-pregunta)

diff --git a/recipes/boveda.toml b/recipes/boveda.toml
index c521af0a..4c1b173e 100644
--- a/recipes/boveda.toml
+++ b/recipes/boveda.toml
@@ -31,36 +31,52 @@
 # Es una llimphi GUI del monorepo: el patrón es `mirada-greeter` (winit + wgpu/vello ⇒ `link =
 # "dynamic"`, porque EGL/Vulkan/wayland se cargan por `dlopen` en runtime y `crt-static` lo
 # impediría) sobre el pin `23a292863`, que es el que ya comparten `puriy-costura`, `shuma-*`,
-# `pacha-*` y `tejido`: **un pin distinto es otro vendoreo de 2,4 G**, no un detalle de gusto.
+# `pacha-*` y `tejido`. ⚠ Ese párrafo decía que un pin distinto costaba «otro vendoreo de 2,4 G»:
+# es FALSO y está corregido en el bloque `[source]` — el árbol se nombra por RECETA, así que cada
+# una paga el suyo con el pin que sea.
 name    = "boveda"
 version = "0.1.0"
 license = "MPL-2.0"
 
 [source]
-# ⚠ El pin subió el 2026-09-21 a `6f0408d40`: **una bóveda que NO abrió le levantaba el socket al
-# navegador igual**, sobre la temporal `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba
-# `locked:false` y un `vault.save` consentido se perdía con el proceso. Es el caso NORMAL en las
-# cuatro imágenes, donde nada puede sembrar la identidad (SDD 26 §7.undecies). Arreglado con test
-# de regresión en los dos sentidos (el arreglo es `7917fbb96`; éste trae además el `Cargo.lock`
-# cerrado de VERDAD, sin el cual `cargo vendor --locked` muere con «cannot update the lock file»).
-# ⚠ Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
+# ⚠ El pin subió el 2026-09-22 a `cd9acd0d9`, y el arreglo que trae es `4f2b5eac7`: **«el llavero
+# falló» se contaba como «no hay identidad»**. Los cinco lectores de `pacha_llavero::SEED_IDENTIDAD`
+# hacían `.ok().flatten()`, que aplasta tres estados en dos, y uno de los cinco es JUSTO el que
+# pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al entrar a la
+# sesión» —verdad si no hay seed sembrada, MENTIRA si el llavero falló, porque entrar a la sesión
+# no lo arregla—. `pacha-llavero` gana `SeedDeSesion` (`Hay`/`NoHay`/`Fallo`) con tres textos
+# distintos a propósito. Medido en el LXC del worker, que es donde se destapó: `add_key` funciona y
+# `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ con la seed presente en `/proc/keys` la app igual decía que
+# no había (SDD 26 §7.terdecies).
+# ⚠ El pin ya NO es propio: `cd9acd0d9` es también el de `pacha`/`pacha-secretos`. Lo que esta
+# receta pide del commit es estar por encima de `eed3120b6` —donde llimphi aprende a pasarle el
+# display handle a wgpu; sin eso el binario sella, arranca y NO ABRE VENTANA, con un «index out of
+# bounds» que no nombra nada de esto (§7.septies)—, y `cd9acd0d9` lo está, así que el commit propio
+# dejó de hacer falta.
+# ⚠⚠ Y ACÁ SE CORRIGE UNA PREMISA QUE ESTA RECETA REPITIÓ TRES VECES: **compartir commit NO
+# comparte el árbol de fuentes, así que no ahorra ningún vendoreo.** El árbol es
+# `work/sources/<NOMBRE DE RECETA>-<commit>` (`crates/takana-build/src/fetch.rs`, el `format!` de
+# `{}-{}`), y encima se BORRA y se rehace en cada build (`remove_dir_all` antes del `git archive`).
+# O sea que cada receta paga su copia del monorepo y su `cargo vendor` SIEMPRE, con el pin que sea.
+# Ya estaba medido y en CLAUDE.md §3 bis, con estas dos recetas de ejemplo: `boveda` y
+# `shuma-pregunta` en el MISMO `b80f7567…` ocupaban 2,7 G **cada una**. Lo que sí se comparte es el
+# `CARGO_HOME` del hub —`cargo vendor` corre fuera del sandbox—, o sea la DESCARGA; la copia de
+# 2,4 G al árbol, no. El motivo para subir el pin es el arreglo de arriba y nada más.
+# ⚠ `cd9acd0d9` es el commit donde el `Cargo.lock` cierra de verdad: repone la arista `rpassword`
+# de `agora-cli`, que un merge de import (`338d4a9b9`) había resuelto quedándose con el lado viejo.
+# Sin ella `cargo vendor --locked` muere con «cannot update the lock file» sin nombrar el crate.
+# Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
 # `--locked`) corrida en una jaula con el registro INCOMPLETO devuelve 0 y deja un lock al que le
-# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto (-15 líneas contra
-# +1). Se cierra donde el registro está completo; acá, en el worker.
-# El pin anterior fue `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con el
-# navegador abierto la bóveda quedaba MUDA). Las dos recetas se mueven juntas para no pagar un
-# tercer vendoreo de 2,4 G: comparten árbol por `<repo>-<sha>`.
-# ⚠ EL PIN NO ES EL DE SUS HERMANAS, Y ES A PROPÓSITO (desde el 2026-09-18). Las demás recetas del
-# monorepo están en `23a292863`, que es ANTERIOR a `eed3120b6` — el commit donde llimphi aprende a
-# pasarle el **display handle** a wgpu en el camino de escritorio—, y sin eso este binario sella,
-# arranca y **no abre ventana**: wgpu cae a la plataforma EGL surfaceless, la surface no tiene un
-# solo formato y la app panica con un «index out of bounds» que no nombra nada de esto (SDD 26
-# §7.septies). Por eso ésta y `boveda`/`shuma-pregunta` van siempre a un commit posterior; cuál es
-# hoy lo dice el bloque de arriba, que es el que se actualiza. El precio es un árbol de fuentes
-# propio —otro vendoreo de 2,4 G, porque el árbol se comparte por `<repo>-<sha>`—; se paga hasta
-# que las demás suban al mismo commit.
+# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto. Se cierra donde
+# el registro está completo; acá, en el worker.
+# Los pines anteriores: `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con
+# el navegador abierto la bóveda quedaba MUDA) y `6f0408d40` (2026-09-21, §7.undecies: una bóveda
+# que NO abrió le levantaba el socket al navegador igual, sobre la temporal
+# `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba `locked:false` y un `vault.save`
+# consentido se perdía con el proceso). Las dos recetas se mueven JUNTAS porque son las dos mitades
+# de la MISMA función —el dueño y el diálogo de consentimiento—, no por compartir nada en disco.
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "6f0408d40d05d7961e811f9062ce5d5127987635"
+commit = "cd9acd0d913dd0bb74212f577b6673c7a09024cf"
 # tawasuyu COMMITEA su propio `vendor/` (smithay parcheado por `[patch.crates-io]` POR RUTA); el
 # `cargo vendor` de takana lo pisaría y el error hablaría de un crate cualquiera, no de esto.
 # No entra en `hash_inputs`.
diff --git a/recipes/shuma-pregunta.toml b/recipes/shuma-pregunta.toml
index c17ca6f9..a49124d6 100644
--- a/recipes/shuma-pregunta.toml
+++ b/recipes/shuma-pregunta.toml
@@ -24,37 +24,52 @@
 # ── LA FORMA DE LA RECETA ──────────────────────────────────────────────────────────────────────
 # llimphi GUI del monorepo, igual que `recipes/boveda.toml`: `link = "dynamic"` (winit + wgpu
 # cargan EGL/Vulkan/wayland por `dlopen`) y el mismo pin `23a292863` que comparten `shuma-daemon`,
-# `shuma-gateway`, `shuma-tui`, `puriy-costura` y `pacha-*` — un pin distinto es otro vendoreo de
-# 2,4 G del workspace entero.
+# `shuma-gateway`, `shuma-tui`, `puriy-costura` y `pacha-*`. ⚠ Ese párrafo decía que un pin distinto
+# costaba «otro vendoreo de 2,4 G»: es FALSO y está corregido en el bloque `[source]` — el árbol se
+# nombra por RECETA, así que cada una paga el suyo con el pin que sea.
 name    = "shuma-pregunta"
 version = "0.1.0"
 license = "MIT OR Apache-2.0"
 
 [source]
-# ⚠ El pin subió el 2026-09-21 a `6f0408d40`: **una bóveda que NO abrió le levantaba el socket al
-# navegador igual**, sobre la temporal `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba
-# `locked:false` y un `vault.save` consentido se perdía con el proceso. Es el caso NORMAL en las
-# cuatro imágenes, donde nada puede sembrar la identidad (SDD 26 §7.undecies). Arreglado con test
-# de regresión en los dos sentidos (el arreglo es `7917fbb96`; éste trae además el `Cargo.lock`
-# cerrado de VERDAD, sin el cual `cargo vendor --locked` muere con «cannot update the lock file»).
-# ⚠ Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
+# ⚠ El pin subió el 2026-09-22 a `cd9acd0d9`, y el arreglo que trae es `4f2b5eac7`: **«el llavero
+# falló» se contaba como «no hay identidad»**. Los cinco lectores de `pacha_llavero::SEED_IDENTIDAD`
+# hacían `.ok().flatten()`, que aplasta tres estados en dos, y uno de los cinco es JUSTO el que
+# pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al entrar a la
+# sesión» —verdad si no hay seed sembrada, MENTIRA si el llavero falló, porque entrar a la sesión
+# no lo arregla—. `pacha-llavero` gana `SeedDeSesion` (`Hay`/`NoHay`/`Fallo`) con tres textos
+# distintos a propósito. Medido en el LXC del worker, que es donde se destapó: `add_key` funciona y
+# `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ con la seed presente en `/proc/keys` la app igual decía que
+# no había (SDD 26 §7.terdecies).
+# ⚠ El pin ya NO es propio: `cd9acd0d9` es también el de `pacha`/`pacha-secretos`. Lo que esta
+# receta pide del commit es estar por encima de `eed3120b6` —donde llimphi aprende a pasarle el
+# display handle a wgpu; sin eso el binario sella, arranca y NO ABRE VENTANA, con un «index out of
+# bounds» que no nombra nada de esto (§7.septies)—, y `cd9acd0d9` lo está, así que el commit propio
+# dejó de hacer falta.
+# ⚠⚠ Y ACÁ SE CORRIGE UNA PREMISA QUE ESTA RECETA REPITIÓ TRES VECES: **compartir commit NO
+# comparte el árbol de fuentes, así que no ahorra ningún vendoreo.** El árbol es
+# `work/sources/<NOMBRE DE RECETA>-<commit>` (`crates/takana-build/src/fetch.rs`, el `format!` de
+# `{}-{}`), y encima se BORRA y se rehace en cada build (`remove_dir_all` antes del `git archive`).
+# O sea que cada receta paga su copia del monorepo y su `cargo vendor` SIEMPRE, con el pin que sea.
+# Ya estaba medido y en CLAUDE.md §3 bis, con estas dos recetas de ejemplo: `boveda` y
+# `shuma-pregunta` en el MISMO `b80f7567…` ocupaban 2,7 G **cada una**. Lo que sí se comparte es el
+# `CARGO_HOME` del hub —`cargo vendor` corre fuera del sandbox—, o sea la DESCARGA; la copia de
+# 2,4 G al árbol, no. El motivo para subir el pin es el arreglo de arriba y nada más.
+# ⚠ `cd9acd0d9` es el commit donde el `Cargo.lock` cierra de verdad: repone la arista `rpassword`
+# de `agora-cli`, que un merge de import (`338d4a9b9`) había resuelto quedándose con el lado viejo.
+# Sin ella `cargo vendor --locked` muere con «cannot update the lock file» sin nombrar el crate.
+# Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
 # `--locked`) corrida en una jaula con el registro INCOMPLETO devuelve 0 y deja un lock al que le
-# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto (-15 líneas contra
-# +1). Se cierra donde el registro está completo; acá, en el worker.
-# El pin anterior fue `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con el
-# navegador abierto la bóveda quedaba MUDA). Las dos recetas se mueven juntas para no pagar un
-# tercer vendoreo de 2,4 G: comparten árbol por `<repo>-<sha>`.
-# ⚠ EL PIN NO ES EL DE SUS HERMANAS, Y ES A PROPÓSITO (desde el 2026-09-18). Las demás recetas del
-# monorepo están en `23a292863`, que es ANTERIOR a `eed3120b6` — el commit donde llimphi aprende a
-# pasarle el **display handle** a wgpu en el camino de escritorio—, y sin eso este binario sella,
-# arranca y **no abre ventana**: wgpu cae a la plataforma EGL surfaceless, la surface no tiene un
-# solo formato y la app panica con un «index out of bounds» que no nombra nada de esto (SDD 26
-# §7.septies). Por eso ésta y `boveda`/`shuma-pregunta` van siempre a un commit posterior; cuál es
-# hoy lo dice el bloque de arriba, que es el que se actualiza. El precio es un árbol de fuentes
-# propio —otro vendoreo de 2,4 G, porque el árbol se comparte por `<repo>-<sha>`—; se paga hasta
-# que las demás suban al mismo commit.
+# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto. Se cierra donde
+# el registro está completo; acá, en el worker.
+# Los pines anteriores: `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con
+# el navegador abierto la bóveda quedaba MUDA) y `6f0408d40` (2026-09-21, §7.undecies: una bóveda
+# que NO abrió le levantaba el socket al navegador igual, sobre la temporal
+# `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba `locked:false` y un `vault.save`
+# consentido se perdía con el proceso). Las dos recetas se mueven JUNTAS porque son las dos mitades
+# de la MISMA función —el dueño y el diálogo de consentimiento—, no por compartir nada en disco.
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "6f0408d40d05d7961e811f9062ce5d5127987635"
+commit = "cd9acd0d913dd0bb74212f577b6673c7a09024cf"
 cargo_vendor_dir = ".hammer-cargo-vendor"
 
 [build]