sergio/takana

Documenta la unidad: el pin de boveda/shuma-pregunta sube a cd9acd0d9, nace el OCTAVO
lugar del guardián de coherencia, y se mide la herencia del llavero entre hermanos.

Y corrige dos cosas que el propio §7.terdecies daba por buenas:

· «subirlas colapsa dos árboles de fuentes en uno» — FALSO. El árbol se nombra por
  RECETA (fetch.rs) y se borra y 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 recetas de ejemplo. Corolario que sí vale: el pin propio que estas dos llevan desde
  el 2026-09-18 NUNCA costó un vendoreo extra. La forma de la lección es nueva: una frase
  que justifica una decisión se copia entre ficheros y se revisa menos que un número.

· «la herencia entre hermanos, sin medir» — medida, y la respuesta es SÍ con condición:
  sólo si el ancestro común abrió sesión. Sin eso el kernel le fabrica una sesión AL
  PROCESO y la seed muere con quien la sembró. Es un requisito sobre arje que nadie había
  escrito.

diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md
index cc0fdbe7..3a277b04 100644
--- a/docs/26-atuq-envoltorio-gecko.md
+++ b/docs/26-atuq-envoltorio-gecko.md
@@ -3953,10 +3953,136 @@ los cuatro objetos a directorios nuevos; `git fsck` limpio.
 
 `boveda` y `shuma-pregunta` siguen pineadas en `6f0408d40`, o sea **sin** este arreglo: la ventana
 de la bóveda todavía dice «se abre al entrar a la sesión» cuando el llavero es el que falló. Subirlas
-a `4f2b5eac7` las arregla **y de paso colapsa dos árboles de fuentes en uno** —ahora comparten
-commit con `pacha`/`pacha-secretos`—, así que el vendoreo de 2,4 G ya estaría pagado. No se hizo acá
-porque son dos builds de llimphi GUI y esto era la unidad del servidor; queda dicho con su precio
-para que sea una decisión.
+las arregla. No se hizo acá porque son dos builds de llimphi GUI y esto era la unidad del servidor;
+queda dicho para que sea una decisión.
+
+⚠ **Este párrafo decía además que subirlas «colapsa dos árboles de fuentes en uno» y que así el
+vendoreo de 2,4 G ya estaría pagado. Es FALSO, y se corrige en el §7.quaterdecies**, que fue a
+hacerlo: el árbol de fuentes se nombra por RECETA, no por commit, así que compartir pin no comparte
+nada. Ya estaba medido, y en CLAUDE.md §3 bis, con estas dos mismas recetas de ejemplo.
+
+#### 7.quaterdecies La cola del capítulo anterior — y dos premisas suyas que no eran ciertas (2026-09-22)
+
+El §7.terdecies cerró con dos pendientes escritos: subir `boveda`/`shuma-pregunta` al commit que
+las arregla, y medir la herencia del llavero de SESIÓN entre procesos HERMANOS. Esto es ir a pagar
+los dos. Los dos se pagaron, y los dos destaparon que la nota que los pedía tenía una premisa
+equivocada adentro — una por pendiente.
+
+##### El pin sube, y el motivo que la nota le ponía no existe
+
+`boveda` y `shuma-pregunta` estaban en `6f0408d40`; el arreglo del llavero se publicó en
+`4f2b5eac7` y `pacha`/`pacha-secretos` ya estaban en `cd9acd0d9`, que lo contiene y además cierra
+el `Cargo.lock`. Se suben las dos a **`cd9acd0d9`**, no a `4f2b5eac7`: mismo arreglo y encima el
+lock que `cargo vendor --locked` necesita.
+
+Lo que cambia de verdad es un texto, y por eso importa. `pacha-boveda-llimphi` es uno de los cinco
+lectores que hacían `.ok().flatten()` sobre `SEED_IDENTIDAD` —`Option` tiene dos estados y el
+llavero tiene tres— así que la ventana decía **«La bóveda está cerrada. Se abre al entrar a la
+sesión»** en los dos casos: cuando no hay seed sembrada, que es verdad, y cuando el llavero FALLÓ,
+que es mentira y encima le echa la culpa a quien mira. Un mensaje equivocado no tiene código de
+salida: el artefacto sella, reproduce, entra a las cuatro imágenes y abre su ventana.
+
+⚠⚠ **Y la nota decía que subirlas «colapsa dos árboles de fuentes en uno», con lo que el vendoreo
+de 2,4 G «ya estaría pagado». No es cierto, y las dos recetas lo repetían en tres párrafos cada una
+como si fuera el motivo del pin propio.** El árbol de fuentes 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**; lo único compartido es el `CARGO_HOME` del hub, porque `cargo vendor` corre fuera del
+sandbox: se comparte la DESCARGA, no la copia.
+
+Lo incómodo es que esto **ya estaba medido, y en CLAUDE.md §3 bis, con estas dos recetas de
+ejemplo**: «`boveda` y `shuma-pregunta` salen del mismo `b80f7567…` y ocupaban 2,7 G cada una».
+La nota del §7.terdecies y los cabezales de las dos recetas afirmaban lo contrario al lado de la
+medición que lo desmentía. Corregido en los tres sitios. La lección no es nueva —es
+`la-etiqueta-no-es-el-hecho` otra vez— pero la forma sí: **una frase que justifica una decisión se
+copia entre ficheros y se revisa menos que un número**, porque nadie la lee como una afirmación
+medible. Ésta viajó por dos recetas y un SDD.
+
+⇒ Corolario práctico, que sí vale: el pin propio de estas dos recetas —vigente desde el 2026-09-18
+porque necesitaban estar por encima de `eed3120b6`, donde llimphi aprende a pasarle el display
+handle a wgpu (§7.septies)— **nunca costó un vendoreo extra**. Costaba exactamente lo mismo que
+compartirlo. Lo que se gana subiéndolas es el arreglo, y nada más.
+
+    boveda           b3:5c43a827 → b3:1b7365bf
+    shuma-pregunta   b3:cd4277c5 → b3:fcc745e8
+
+⏳ Los dos artefactos van al **worker**, como las tres veces anteriores: son llimphi GUI y el hub
+es la jaula qorpa. La tanda se lanzó con la guarda por receta del §7.undecies **dentro** del
+`flock`, que es donde la ventana existe de verdad — la del §7.terdecies se disparó justamente
+porque el latido revirtió una receta entre dos builds de la misma tanda. Quedó encolada detrás de
+la tanda de otro frente (once recetas del monorepo subiendo a `c7545339a`), que es lo que el lock
+del ADR 0012 hace y para lo que está.
+
+##### El OCTAVO lugar: nadie vigilaba que la receta no se quedara DETRÁS de su propio paquete
+
+`test-atuq-boveda-coherente.py` miraba siete lugares y los siete preguntaban lo mismo: ¿la pieza
+ESTÁ? Ninguno preguntaba si la que está es la de hoy. Y ésa es exactamente la forma en que se rompió
+esto: la receta pineada tres días atrás, el arreglo publicado en el otro repo, y nada que falle.
+Es el cuerpo del §7.quinquies —el cable tiene dos puntas en dos repos y se desincronizan en
+silencio— un piso más abajo: allá la punta que se quedaba atrás era el HOST y el síntoma era
+«verbo desconocido»; acá es la receta de la app y el síntoma es un texto.
+
+La pregunta se hace en la forma que **no envejece**: no se busca el símbolo `SeedDeSesion`
+—renombrarlo dejaría al guardián mintiendo en verde, que es el modo de falla de
+`umbral-a-mano-envejece`— sino que se le pregunta a git si hay commits en `main` que TOQUEN el
+paquete que la receta construye y que el pin no tenga:
+
+    boveda.toml          → shared/pacha/pacha-boveda-llimphi, shared/pacha/pacha-llavero
+    shuma-pregunta.toml  → 02_ruway/shuma/shuma-pregunta
+
+Y no dice «subí el pin»: dice **cuántos y cuáles**, porque un pin viejo puede ser deliberado y
+«estás atrás» sin decir de qué no sirve para decidir. El control POSITIVO es que el pin sea ancestro
+de `main`: si no lo es, el `pin..main` da cero por una razón que no es «al día» —otra rama, un clon
+sin `fetch`— y el verde sería falso. El control negativo (`--negative-control-deriva`) finge el pin
+viejo, y es el único de los cinco cuyo «mal» ya ocurrió de verdad:
+
+```
+✗ boveda.toml pineada (6f0408d40) está DETRÁS de 2 commit(s) que tocan su propio paquete
+      · pacha-boveda-llimphi: 4f2b5eac7 fix(pacha): «el llavero falló» se contaba como…
+      · pacha-llavero:        4f2b5eac7 fix(pacha): «el llavero falló» se contaba como…
+```
+
+##### La herencia entre HERMANOS: sí, pero sólo si alguien abrió sesión
+
+El otro pendiente. El §7.terdecies lo dejó «sin medir» y con la razón bien puesta: `/proc/keys` como
+root no lo mide, sólo dice que la clave existe. Ver que `add_key` funcionó no dice que el hermano
+pueda ENCONTRARLA — y en el LXC del worker esas dos cosas se separan de la peor manera.
+
+La pregunta es del producto, no del kernel: en las cuatro imágenes la persona corre `agora-cli
+identity unlock` en una terminal y después abre `boveda` desde el lanzador. Son dos procesos y
+ninguno es hijo del otro: **hermanos**. Sonda nueva, `scripts/sonda-llavero-hermanos.{c,sh}`, con
+los roles como `exec` aparte y no como forks —un fork heredaría por definición y la sonda
+contestaría que sí sin haber medido nada—. Medido en el anfitrión (kernel 7.1.2, root):
+
+```
+A  el ancestro NO tiene sesión propia   sembrada ✓ · el hermano NO la encuentra
+B  el ancestro se une a una sesión      sembrada ✓ · el hermano la ENCUENTRA (mismo id)
+```
+
+Los dos escenarios se corren **juntos y siempre**, porque el interesante es el contraste: el A
+solo, en rojo, se lee como «los hermanos no comparten nunca», que es falso y habría cerrado el
+flujo del escritorio por construcción. Lo que pasa en A es que pedir `@s` sin sesión previa hace
+que el kernel le fabrique una **al proceso**, y la seed muere con quien la sembró.
+
+⇒ **El flujo del escritorio es posible, pero no gratis**: `agora-cli unlock` y `boveda` tienen que
+colgar de un ancestro con llavero de SESIÓN. Si arje lanza cada app sin eso, la bóveda contesta
+`locked:true` para siempre y no falla nada — la forma de fallo de todo este capítulo, una capa más
+abajo todavía. Es un requisito sobre arje que nadie había escrito, y es lo que esta medición
+agrega sobre «sí, los hermanos comparten».
+
+Tres controles, y los tres se dispararon de verdad. El del INSTRUMENTO es el que más vale: corrida
+en el LXC del worker, la sonda **se niega a contestar** —`keyctl(KEYCTL_SEARCH)` da `ENOSYS`, se
+puede sembrar y no cosechar— y así reproduce sola la medición del §7.terdecies en vez de citarla.
+El POSITIVO es que el sembrador se busque su propia clave antes de salir. Y el NEGATIVO —un tercer
+proceso que salta a una sesión nueva y no la encuentra— **sólo se corre donde el hermano SÍ
+encontró**: si arriba salió «no», un «no» del control es el mismo «no» y no separa medir de no
+encontrar nunca.
+
+ℹ El primer intento fue en Python con `ctypes` y no corre donde hace falta: el python del anfitrión
+musl no trae `_ctypes` (falta `libffi.so.8`) y se cae **al importar**, antes de medir nada.
+`keyutils`/`keyctl(1)` no están en el corpus. Queda el syscall pelado, que además es lo que hace
+`pacha-llavero`.
 
 ## 8. Plan, por unidades de trabajo