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>
92 lines
6.0 KiB
TOML
92 lines
6.0 KiB
TOML
# shuma-pregunta — la pregunta con opciones que contesta una PERSONA, y devuelve la elegida por
|
|
# stdout en una línea de JSON. Hermano de `shuma-askpass`: dentro del cajón de shuma si el pedido
|
|
# sale de una de sus pestañas, y en su propia ventana llimphi si no.
|
|
#
|
|
# ── POR QUÉ ENTRA AL CORPUS AHORA (2026-09-18) ─────────────────────────────────────────────────
|
|
# Porque es **el consentimiento de la bóveda**, y sin él la bóveda del navegador no entrega nada.
|
|
# `pacha_boveda::navegador::PorDialogo` —la política que la app le pone al socket del navegador—
|
|
# es literalmente un `Command::new("shuma-pregunta")`, y su primera línea de manejo de error es:
|
|
#
|
|
# let Ok(mut hijo) = hijo else {
|
|
# // No hay con qué preguntar ⇒ no.
|
|
# return false;
|
|
# };
|
|
#
|
|
# O sea que **sin este binario en la imagen, todo `vault.fill` se deniega**, y se deniega bien: la
|
|
# extensión lee `f.denied === true` y se calla, que es lo correcto y es indistinguible de que el
|
|
# usuario haya dicho que no. La función se ve apagada y nada falla. Ver `recipes/boveda.toml`, que
|
|
# trae la otra mitad (el dueño de la base) y la medición que destapó las dos ausencias.
|
|
#
|
|
# No es sólo de la bóveda: es el diálogo declarado de la suite (`COLA-SHUMA` §I2), y existe para
|
|
# sacar del medio la costumbre de reconocer un menú por su forma en la pantalla de un terminal y
|
|
# contestarlo a ciegas con flechas.
|
|
#
|
|
# ── 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.
|
|
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
|
|
# `--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"
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "dynamic"
|
|
flags = ["-p", "shuma-pregunta", "--bin", "shuma-pregunta"]
|
|
|
|
# Fase `compile` explícita por `LOCKSTEP_XML_PATH` — la causa, entera, está en `mirada-greeter.toml`
|
|
# y repetida en `recipes/boveda.toml`: `accesskit_winit` → `atspi` → `zbus-lockstep-macros`, cuyo
|
|
# `#[validate]` panica al encontrar el subdir `xml/schemas/`. La comprobación falla a gritos porque
|
|
# un `cp` mudo dejaría la variable apuntando a un directorio vacío.
|
|
[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 shuma-pregunta --bin shuma-pregunta -- -C target-feature=-crt-static
|
|
'''
|
|
install = '''
|
|
set -e
|
|
test -x target/release/shuma-pregunta || { echo "no hay target/release/shuma-pregunta" >&2; exit 1; }
|
|
install -Dm755 target/release/shuma-pregunta /out/usr/bin/shuma-pregunta
|
|
'''
|
|
|
|
[deps]
|
|
build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]
|