SergioandClaude Opus 5
557e127f6f
Seguir con lo que el §7.decies dejó abierto —quién levanta la app, de dónde sale la raíz de las claves— terminó en una respuesta incómoda y en un bug que valía la pena encontrar. La cadena, medida hacia atrás desde la app: · `raiz_de_identidad()` saca la seed del llavero del KERNEL (`pacha_llavero::SEED_IDENTIDAD`); · la escriben dos lugares en todo tawasuyu: `agora-cli identity unlock` y `churay-welcome-runner`; · `agora-cli` está sellado y en `perfiles: []` — en ninguna imagen. Y aunque se declarara, su pin es del 2026-06-18, donde no existen ni `SEED_IDENTIDAD` ni `desbloquear` (git grep sobre el pin, con HEAD de control: 4 y 1 aciertos); · `churay-welcome` no tiene receta en takana. ⇒ en ninguna imagen hay un binario capaz de sembrar la identidad. No es que el usuario no la desbloqueó: es que no tiene con qué. Y lo que el navegador veía NO era «cerrada». Cuando `abrir()` falla, la app levantaba el socket igual, sobre `bóveda_imposible()` —un sled en /tmp/boveda-sin-abrir-<pid>—, así que la extensión recibía `locked:false, count:0` y un `vault.save` consentido guardaba en un temporal que muere con el proceso. La ventana decía la verdad; el navegador, lo contrario. Arreglado en tawasuyu (`7917fbb96`) con test de regresión en los dos sentidos, y probado al revés: con el `if` neutralizado, el test falla con el mensaje que corresponde. Pin de las dos recetas a `6f0408d40`, que trae además el `Cargo.lock` cerrado. Ahí apareció la vuelta que no estaba escrita: la «operación mínima» del §7.octies (`cargo metadata` sin `--locked`) corrida en una jaula con el registro de cargo 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). Que diera byte a byte igual al de otra sesión no lo confirmaba: las dos se calcularon con el mismo instrumento roto. Y una trampa más, medida hoy: la guarda de receta del §7.quinquies.bis NO alcanza para una TANDA. Puesta una vez al principio, `shuma-pregunta` selló bien y `boveda` —once minutos después— dio «artefacto ya en el store» sobre la receta VIEJA, porque el latido revierte el árbol del worker en el medio. La guarda va pegada a CADA build, y la cura de fondo es publicar la receta antes de construir. De paso, dos correcciones a lo que este mismo frente escribió hace unas horas: · el `app_id`: llimphi SÍ lo pone (`with_name`, con el nombre del ejecutable de piso) ⇒ la ventana es `boveda`, igual que el basename del `.desktop`, y por eso no hace falta `StartupWMClass`. Lo que sí queda mal es el TÍTULO, que dice «llimphi»; · el GL: que las imágenes sean iris-only no es una decisión pendiente sino una escrita (SDD 14), y el caso de la VM ya tiene camino — los runbooks montan `mesa-llvmpipe` como capa. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
154 lines
10 KiB
TOML
154 lines
10 KiB
TOML
# boveda — la app de la bóveda de la suite, y **el dueño único** de su base (SDD-BOVEDA §8.5).
|
|
#
|
|
# ── POR QUÉ ESTA RECETA, Y POR QUÉ RECIÉN AHORA (2026-09-18) ────────────────────────────────────
|
|
# `atuq` trae desde el 2026-09-15 la extensión `boveda@atuq.tawasuyu` —la décima— y desde el
|
|
# 2026-09-16 el host `puriy-costura` pineado a un commit que SÍ atiende `vault.*`. Con eso el SDD 26
|
|
# (§7.quinquies.bis) dio la unidad 12 por destrabada y anunció que «ahora sí se puede escribir el
|
|
# guardián de metal porque hay con qué correrlo».
|
|
#
|
|
# ⚠ **Y no había.** Medido contra el artefacto sellado, en esta máquina, con el binario que va en la
|
|
# imagen:
|
|
#
|
|
# ← {"id":2,"ok":true,"verb":"vault.status","locked":true,"count":0}
|
|
# ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]}
|
|
# stderr: puriy-costura: sin bóveda (No such file or directory (os error 2)):
|
|
# los verbos vault.* dirán «cerrada»
|
|
#
|
|
# El host **nunca abre la bóveda por su cuenta, a propósito**: `sled` toma un lock exclusivo, y el
|
|
# proceso que lanza el navegador muere y revive con cada pestaña, así que no es un buen dueño de la
|
|
# base. El host le habla al DUEÑO por un socket… y el dueño no estaba en el corpus. O sea que la
|
|
# función que el navegador anuncia —insignia, `vault.match`, `vault.fill`— hoy contesta «cerrada»
|
|
# en las cuatro imágenes de escritorio, sin un solo error a la vista. Es exactamente la forma de
|
|
# fallo que el §7.quinquies describe: ficheros en orden, navegador sin la función.
|
|
#
|
|
# El dueño es ESTA app: abre la bóveda para su propia ventana y levanta el socket en un hilo para
|
|
# el navegador (`atender_al_navegador`), con políticas distintas de cada lado — sin preguntar a
|
|
# quien está mirando la ventana, preguntando SIEMPRE a lo que llega de afuera (`PorDialogo`, que
|
|
# lanza `shuma-pregunta`; ver `recipes/shuma-pregunta.toml`, sin la cual todo `vault.fill` se
|
|
# deniega).
|
|
#
|
|
# ── LA FORMA DE LA RECETA ──────────────────────────────────────────────────────────────────────
|
|
# 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.
|
|
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
|
|
# `--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.
|
|
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
|
|
commit = "6f0408d40d05d7961e811f9062ce5d5127987635"
|
|
# 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`.
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "dynamic"
|
|
flags = ["-p", "pacha-boveda-llimphi", "--bin", "boveda"]
|
|
|
|
# Fase `compile` EXPLÍCITA —réplica de la que takana genera para Cargo— porque hay que inyectar
|
|
# `LOCKSTEP_XML_PATH` ANTES del build. La causa está escrita entera en `mirada-greeter.toml` y es
|
|
# la misma acá, con el mismo `accesskit_winit` 0.33 y el mismo `zbus-lockstep-macros` 0.5.2 en el
|
|
# lock: su `#[validate]` escanea el dir `xml/` de `atspi-common` llamando `.extension().expect()`
|
|
# en CADA entrada ⇒ PANICA en el subdirectorio `xml/schemas/`. Apuntando la variable a un dir con
|
|
# sólo los `.xml` se evita.
|
|
#
|
|
# ⚠ La ruta NO es `vendor/` como en `mirada-greeter`: con `cargo_vendor_dir` los crates vendoreados
|
|
# caen en `.hammer-cargo-vendor/`. Y la comprobación es a GRITOS: si mañana `atspi-common` deja de
|
|
# vendorearse ahí, un `cp` que falla en silencio dejaría la variable apuntando a un dir vacío y el
|
|
# panic volvería con el error lejos de la causa.
|
|
[build.phases]
|
|
compile = '''
|
|
set -e
|
|
XMLDIR="$PWD/.atspi-lockstep-xml"
|
|
mkdir -p "$XMLDIR"
|
|
ls .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; }
|
|
cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
|
|
export LOCKSTEP_XML_PATH="$XMLDIR"
|
|
printf '%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"
|
|
chmod +x "$PWD/.hammer-zig-cc"
|
|
RF="-C linker=$PWD/.hammer-zig-cc"
|
|
rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
|
|
CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline -p pacha-boveda-llimphi --bin boveda -- -C target-feature=-crt-static
|
|
'''
|
|
install = '''
|
|
set -e
|
|
test -x target/release/boveda || { echo "no hay target/release/boveda — ¿cambió el nombre del bin en pacha-boveda-llimphi?" >&2; exit 1; }
|
|
install -Dm755 target/release/boveda /out/usr/bin/boveda
|
|
|
|
# ── EL LANZADOR, Y POR QUÉ ES PARTE DE LA FUNCIÓN Y NO UN ADORNO (2026-09-21) ─────────────────
|
|
# Sin esta entrada la app viaja en la imagen y **no existe para quien la usa**: los lanzadores de
|
|
# los cuatro escritorios leen `/usr/share/applications`, y a un binario que nadie lista sólo se
|
|
# llega escribiendo `boveda` en una terminal. Sería exactamente la forma de fallo que esta receta
|
|
# existe para cerrar —la función instalada, apagada y en silencio (SDD 26 §7.sexies)— una capa más
|
|
# arriba: la bóveda declarada en el perfil, la insignia del navegador vacía, y nada que falle.
|
|
#
|
|
# `Icon=dialog-password` es nombre del icon naming spec y está MEDIDO en los tres temas que los
|
|
# perfiles declaran, no supuesto: `breeze-icons` 6 ficheros, `adwaita-icon-theme` 1, `cosmic-icons`
|
|
# 2. El cuarto perfil (sway) lleva sólo `hicolor`, que por diseño no trae iconos: ahí el lanzador
|
|
# cae al genérico, que es degradarse, no romperse.
|
|
#
|
|
# No lleva `StartupWMClass`, y la razón es que NO HACE FALTA — no que no se pueda. `llimphi_ui`
|
|
# arma la ventana con `with_name`, que en Wayland es el `app_id` del xdg-toplevel: usa el
|
|
# `App::app_id()` que la app declare y, si no declara ninguna —que es el caso de `BovedaApp`—, cae
|
|
# al **nombre del ejecutable** (`app_id_del_ejecutable`, el piso que llimphi se puso cuando 163 de
|
|
# sus 178 apps compartían el genérico del compositor). O sea `app_id = "boveda"`, que es
|
|
# exactamente el basename de este `.desktop` ⇒ el emparejamiento estándar ya funciona.
|
|
# Medido, no leído: el guardián de metal espera `'"app_id": *"boveda"'` en el árbol de sway y lo
|
|
# encuentra a los 12-13 s (SDD 26 §7.novies).
|
|
# ⚠ Lo que sí sigue mal es el TÍTULO: `App::title()` devuelve `"llimphi"` por defecto y `BovedaApp`
|
|
# no lo sobrescribe, así que la barra y el conmutador de ventanas dicen «llimphi». Es de llimphi/la
|
|
# app, no de esta entrada.
|
|
mkdir -p /out/usr/share/applications
|
|
cat > /out/usr/share/applications/boveda.desktop <<'DESKTOP'
|
|
[Desktop Entry]
|
|
Type=Application
|
|
Name=Bóveda
|
|
Name[en]=Vault
|
|
GenericName=Gestor de contraseñas
|
|
GenericName[en]=Password Manager
|
|
Comment=Tus contraseñas, y quien las pide tiene que preguntarte
|
|
Comment[en]=Your passwords, and whoever asks has to ask you
|
|
Exec=boveda
|
|
Icon=dialog-password
|
|
Terminal=false
|
|
Categories=Utility;Security;
|
|
Keywords=contraseñas;claves;bóveda;passwords;
|
|
StartupNotify=true
|
|
DESKTOP
|
|
chmod 0644 /out/usr/share/applications/boveda.desktop
|
|
test -s /out/usr/share/applications/boveda.desktop || { echo "boveda.desktop quedó vacío" >&2; exit 1; }
|
|
'''
|
|
|
|
[deps]
|
|
# Las mismas que `mirada-greeter` menos `linux-pam` (eso era de `auth-core`, que esta app no usa:
|
|
# su segundo factor es `nakui-auth`, Rust puro). El stack gráfico se consulta en build-time por
|
|
# pkg-config y se carga por `dlopen` en runtime.
|
|
build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]
|