sergio/takana

1# boveda — la app de la bóveda de la suite, y **el dueño único** de su base (SDD-BOVEDA §8.5).
2#
3# ── POR QUÉ ESTA RECETA, Y POR QUÉ RECIÉN AHORA (2026-09-18) ────────────────────────────────────
4# `atuq` trae desde el 2026-09-15 la extensión `boveda@atuq.tawasuyu` —la décima— y desde el
5# 2026-09-16 el host `puriy-costura` pineado a un commit que SÍ atiende `vault.*`. Con eso el SDD 26
6# (§7.quinquies.bis) dio la unidad 12 por destrabada y anunció que «ahora sí se puede escribir el
7# guardián de metal porque hay con qué correrlo».
8#
9# ⚠ **Y no había.** Medido contra el artefacto sellado, en esta máquina, con el binario que va en la
10# imagen:
11#
12#     ← {"id":2,"ok":true,"verb":"vault.status","locked":true,"count":0}
13#     ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]}
14#     stderr: puriy-costura: sin bóveda (No such file or directory (os error 2)):
15#             los verbos vault.* dirán «cerrada»
16#
17# El host **nunca abre la bóveda por su cuenta, a propósito**: `sled` toma un lock exclusivo, y el
18# proceso que lanza el navegador muere y revive con cada pestaña, así que no es un buen dueño de la
19# base. El host le habla al DUEÑO por un socket… y el dueño no estaba en el corpus. O sea que la
20# función que el navegador anuncia —insignia, `vault.match`, `vault.fill`— hoy contesta «cerrada»
21# en las cuatro imágenes de escritorio, sin un solo error a la vista. Es exactamente la forma de
22# fallo que el §7.quinquies describe: ficheros en orden, navegador sin la función.
23#
24# El dueño es ESTA app: abre la bóveda para su propia ventana y levanta el socket en un hilo para
25# el navegador (`atender_al_navegador`), con políticas distintas de cada lado — sin preguntar a
26# quien está mirando la ventana, preguntando SIEMPRE a lo que llega de afuera (`PorDialogo`, que
27# lanza `shuma-pregunta`; ver `recipes/shuma-pregunta.toml`, sin la cual todo `vault.fill` se
28# deniega).
29#
30# ── LA FORMA DE LA RECETA ──────────────────────────────────────────────────────────────────────
31# Es una llimphi GUI del monorepo: el patrón es `mirada-greeter` (winit + wgpu/vello ⇒ `link =
32# "dynamic"`, porque EGL/Vulkan/wayland se cargan por `dlopen` en runtime y `crt-static` lo
33# impediría) sobre el pin `23a292863`, que es el que ya comparten `puriy-costura`, `shuma-*`,
34# `pacha-*` y `tejido`. ⚠ Ese párrafo decía que un pin distinto costaba «otro vendoreo de 2,4 G»:
35# es FALSO y está corregido en el bloque `[source]` — el árbol se nombra por RECETA, así que cada
36# una paga el suyo con el pin que sea.
37name    = "boveda"
38version = "0.1.0"
39license = "MPL-2.0"
40
41[source]
42# ⚠ El pin subió el 2026-09-22 a `cd9acd0d9`, y el arreglo que trae es `4f2b5eac7`: **«el llavero
43# falló» se contaba como «no hay identidad»**. Los cinco lectores de `pacha_llavero::SEED_IDENTIDAD`
44# hacían `.ok().flatten()`, que aplasta tres estados en dos, y uno de los cinco es JUSTO el que
45# pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al entrar a la
46# sesión» —verdad si no hay seed sembrada, MENTIRA si el llavero falló, porque entrar a la sesión
47# no lo arregla—. `pacha-llavero` gana `SeedDeSesion` (`Hay`/`NoHay`/`Fallo`) con tres textos
48# distintos a propósito. Medido en el LXC del worker, que es donde se destapó: `add_key` funciona y
49# `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ con la seed presente en `/proc/keys` la app igual decía que
50# no había (SDD 26 §7.terdecies).
51# ⚠ El pin ya NO es propio: `cd9acd0d9` es también el de `pacha`/`pacha-secretos`. Lo que esta
52# receta pide del commit es estar por encima de `eed3120b6` —donde llimphi aprende a pasarle el
53# display handle a wgpu; sin eso el binario sella, arranca y NO ABRE VENTANA, con un «index out of
54# bounds» que no nombra nada de esto (§7.septies)—, y `cd9acd0d9` lo está, así que el commit propio
55# dejó de hacer falta.
56# ⚠⚠ Y ACÁ SE CORRIGE UNA PREMISA QUE ESTA RECETA REPITIÓ TRES VECES: **compartir commit NO
57# comparte el árbol de fuentes, así que no ahorra ningún vendoreo.** El árbol es
58# `work/sources/<NOMBRE DE RECETA>-<commit>` (`crates/takana-build/src/fetch.rs`, el `format!` de
59# `{}-{}`), y encima se BORRA y se rehace en cada build (`remove_dir_all` antes del `git archive`).
60# O sea que cada receta paga su copia del monorepo y su `cargo vendor` SIEMPRE, con el pin que sea.
61# Ya estaba medido y en CLAUDE.md §3 bis, con estas dos recetas de ejemplo: `boveda` y
62# `shuma-pregunta` en el MISMO `b80f7567…` ocupaban 2,7 G **cada una**. Lo que sí se comparte es el
63# `CARGO_HOME` del hub —`cargo vendor` corre fuera del sandbox—, o sea la DESCARGA; la copia de
64# 2,4 G al árbol, no. El motivo para subir el pin es el arreglo de arriba y nada más.
65# ⚠ `cd9acd0d9` es el commit donde el `Cargo.lock` cierra de verdad: repone la arista `rpassword`
66# de `agora-cli`, que un merge de import (`338d4a9b9`) había resuelto quedándose con el lado viejo.
67# Sin ella `cargo vendor --locked` muere con «cannot update the lock file» sin nombrar el crate.
68# Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
69# `--locked`) corrida en una jaula con el registro INCOMPLETO devuelve 0 y deja un lock al que le
70# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto. Se cierra donde
71# el registro está completo; acá, en el worker.
72# Los pines anteriores: `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con
73# el navegador abierto la bóveda quedaba MUDA) y `6f0408d40` (2026-09-21, §7.undecies: una bóveda
74# que NO abrió le levantaba el socket al navegador igual, sobre la temporal
75# `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba `locked:false` y un `vault.save`
76# consentido se perdía con el proceso). Las dos recetas se mueven JUNTAS porque son las dos mitades
77# de la MISMA función —el dueño y el diálogo de consentimiento—, no por compartir nada en disco.
78repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
79commit = "619431cac9753cd55d0f9e2d99ff8efe7fab651b"
80# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado por `[patch.crates-io]` POR RUTA); el
81# `cargo vendor` de takana lo pisaría y el error hablaría de un crate cualquiera, no de esto.
82# No entra en `hash_inputs`.
83cargo_vendor_dir = ".hammer-cargo-vendor"
84
85[build]
86compiler = "zig-cc"
87target   = "x86_64-linux-musl"
88link     = "dynamic"
89flags    = ["-p", "pacha-boveda-llimphi", "--bin", "boveda"]
90
91# Fase `compile` EXPLÍCITA —réplica de la que takana genera para Cargo— porque hay que inyectar
92# `LOCKSTEP_XML_PATH` ANTES del build. La causa está escrita entera en `mirada-greeter.toml` y es
93# la misma acá, con el mismo `accesskit_winit` 0.33 y el mismo `zbus-lockstep-macros` 0.5.2 en el
94# lock: su `#[validate]` escanea el dir `xml/` de `atspi-common` llamando `.extension().expect()`
95# en CADA entrada ⇒ PANICA en el subdirectorio `xml/schemas/`. Apuntando la variable a un dir con
96# sólo los `.xml` se evita.
97#
98# ⚠ La ruta NO es `vendor/`: con `cargo_vendor_dir` los crates vendoreados
99# caen en `.hammer-cargo-vendor/`. Y la comprobación es a GRITOS: si mañana `atspi-common` deja de
100# vendorearse ahí, un `cp` que falla en silencio dejaría la variable apuntando a un dir vacío y el
101# panic volvería con el error lejos de la causa.
102[build.phases]
103compile = '''
104set -e
105XMLDIR="$PWD/.atspi-lockstep-xml"
106mkdir -p "$XMLDIR"
107ls .hammer-cargo-vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay .hammer-cargo-vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
108cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
109export LOCKSTEP_XML_PATH="$XMLDIR"
110printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec zig cc -mcpu=baseline "$@"' > "$PWD/.hammer-zig-cc"
111chmod +x "$PWD/.hammer-zig-cc"
112RF="-C linker=$PWD/.hammer-zig-cc"
113rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
114CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline -p pacha-boveda-llimphi --bin boveda -- -C target-feature=-crt-static
115'''
116install = '''
117set -e
118test -x target/release/boveda || { echo "no hay target/release/boveda — ¿cambió el nombre del bin en pacha-boveda-llimphi?" >&2; exit 1; }
119install -Dm755 target/release/boveda /out/usr/bin/boveda
120
121# ── EL LANZADOR, Y POR QUÉ ES PARTE DE LA FUNCIÓN Y NO UN ADORNO (2026-09-21) ─────────────────
122# Sin esta entrada la app viaja en la imagen y **no existe para quien la usa**: los lanzadores de
123# los cuatro escritorios leen `/usr/share/applications`, y a un binario que nadie lista sólo se
124# llega escribiendo `boveda` en una terminal. Sería exactamente la forma de fallo que esta receta
125# existe para cerrar —la función instalada, apagada y en silencio (SDD 26 §7.sexies)— una capa más
126# arriba: la bóveda declarada en el perfil, la insignia del navegador vacía, y nada que falle.
127#
128# `Icon=dialog-password` es nombre del icon naming spec y está MEDIDO en los tres temas que los
129# perfiles declaran, no supuesto: `breeze-icons` 6 ficheros, `adwaita-icon-theme` 1, `cosmic-icons`
130# 2. El cuarto perfil (sway) lleva sólo `hicolor`, que por diseño no trae iconos: ahí el lanzador
131# cae al genérico, que es degradarse, no romperse.
132#
133# No lleva `StartupWMClass`, y la razón es que NO HACE FALTA — no que no se pueda. `llimphi_ui`
134# arma la ventana con `with_name`, que en Wayland es el `app_id` del xdg-toplevel: usa el
135# `App::app_id()` que la app declare y, si no declara ninguna —que es el caso de `BovedaApp`—, cae
136# al **nombre del ejecutable** (`app_id_del_ejecutable`, el piso que llimphi se puso cuando 163 de
137# sus 178 apps compartían el genérico del compositor). O sea `app_id = "boveda"`, que es
138# exactamente el basename de este `.desktop` ⇒ el emparejamiento estándar ya funciona.
139# Medido, no leído: el guardián de metal espera `'"app_id": *"boveda"'` en el árbol de sway y lo
140# encuentra a los 12-13 s (SDD 26 §7.novies).
141# ⚠ Lo que sí sigue mal es el TÍTULO: `App::title()` devuelve `"llimphi"` por defecto y `BovedaApp`
142# no lo sobrescribe, así que la barra y el conmutador de ventanas dicen «llimphi». Es de llimphi/la
143# app, no de esta entrada.
144mkdir -p /out/usr/share/applications
145cat > /out/usr/share/applications/boveda.desktop <<'DESKTOP'
146[Desktop Entry]
147Type=Application
148Name=Bóveda
149Name[en]=Vault
150GenericName=Gestor de contraseñas
151GenericName[en]=Password Manager
152Comment=Tus contraseñas, y quien las pide tiene que preguntarte
153Comment[en]=Your passwords, and whoever asks has to ask you
154Exec=boveda
155Icon=dialog-password
156Terminal=false
157Categories=Utility;Security;
158Keywords=contraseñas;claves;bóveda;passwords;
159StartupNotify=true
160DESKTOP
161chmod 0644 /out/usr/share/applications/boveda.desktop
162test -s /out/usr/share/applications/boveda.desktop || { echo "boveda.desktop quedó vacío" >&2; exit 1; }
163'''
164
165[deps]
166# Las mismas que `mirada-greeter` menos `linux-pam` (eso era de `auth-core`, que esta app no usa:
167# su segundo factor es `nakui-auth`, Rust puro). El stack gráfico se consulta en build-time por
168# pkg-config y se carga por `dlopen` en runtime.
169build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]