sergio/takana

1# shuma-pregunta — la pregunta con opciones que contesta una PERSONA, y devuelve la elegida por
2# stdout en una línea de JSON. Hermano de `shuma-askpass`: dentro del cajón de shuma si el pedido
3# sale de una de sus pestañas, y en su propia ventana llimphi si no.
4#
5# ── POR QUÉ ENTRA AL CORPUS AHORA (2026-09-18) ─────────────────────────────────────────────────
6# Porque es **el consentimiento de la bóveda**, y sin él la bóveda del navegador no entrega nada.
7# `pacha_boveda::navegador::PorDialogo` —la política que la app le pone al socket del navegador—
8# es literalmente un `Command::new("shuma-pregunta")`, y su primera línea de manejo de error es:
9#
10#     let Ok(mut hijo) = hijo else {
11#         // No hay con qué preguntar ⇒ no.
12#         return false;
13#     };
14#
15# O sea que **sin este binario en la imagen, todo `vault.fill` se deniega**, y se deniega bien: la
16# extensión lee `f.denied === true` y se calla, que es lo correcto y es indistinguible de que el
17# usuario haya dicho que no. La función se ve apagada y nada falla. Ver `recipes/boveda.toml`, que
18# trae la otra mitad (el dueño de la base) y la medición que destapó las dos ausencias.
19#
20# No es sólo de la bóveda: es el diálogo declarado de la suite (`COLA-SHUMA` §I2), y existe para
21# sacar del medio la costumbre de reconocer un menú por su forma en la pantalla de un terminal y
22# contestarlo a ciegas con flechas.
23#
24# ── LA FORMA DE LA RECETA ──────────────────────────────────────────────────────────────────────
25# llimphi GUI del monorepo, igual que `recipes/boveda.toml`: `link = "dynamic"` (winit + wgpu
26# cargan EGL/Vulkan/wayland por `dlopen`) y el mismo pin `23a292863` que comparten `shuma-daemon`,
27# `shuma-gateway`, `shuma-tui`, `puriy-costura` y `pacha-*`. ⚠ Ese párrafo decía que un pin distinto
28# costaba «otro vendoreo de 2,4 G»: es FALSO y está corregido en el bloque `[source]` — el árbol se
29# nombra por RECETA, así que cada una paga el suyo con el pin que sea.
30name    = "shuma-pregunta"
31version = "0.1.0"
32license = "MIT OR Apache-2.0"
33
34[source]
35# ⚠ El pin subió el 2026-09-22 a `cd9acd0d9`, y el arreglo que trae es `4f2b5eac7`: **«el llavero
36# falló» se contaba como «no hay identidad»**. Los cinco lectores de `pacha_llavero::SEED_IDENTIDAD`
37# hacían `.ok().flatten()`, que aplasta tres estados en dos, y uno de los cinco es JUSTO el que
38# pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al entrar a la
39# sesión» —verdad si no hay seed sembrada, MENTIRA si el llavero falló, porque entrar a la sesión
40# no lo arregla—. `pacha-llavero` gana `SeedDeSesion` (`Hay`/`NoHay`/`Fallo`) con tres textos
41# distintos a propósito. Medido en el LXC del worker, que es donde se destapó: `add_key` funciona y
42# `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ con la seed presente en `/proc/keys` la app igual decía que
43# no había (SDD 26 §7.terdecies).
44# ⚠ El pin ya NO es propio: `cd9acd0d9` es también el de `pacha`/`pacha-secretos`. Lo que esta
45# receta pide del commit es estar por encima de `eed3120b6` —donde llimphi aprende a pasarle el
46# display handle a wgpu; sin eso el binario sella, arranca y NO ABRE VENTANA, con un «index out of
47# bounds» que no nombra nada de esto (§7.septies)—, y `cd9acd0d9` lo está, así que el commit propio
48# dejó de hacer falta.
49# ⚠⚠ Y ACÁ SE CORRIGE UNA PREMISA QUE ESTA RECETA REPITIÓ TRES VECES: **compartir commit NO
50# comparte el árbol de fuentes, así que no ahorra ningún vendoreo.** El árbol es
51# `work/sources/<NOMBRE DE RECETA>-<commit>` (`crates/takana-build/src/fetch.rs`, el `format!` de
52# `{}-{}`), y encima se BORRA y se rehace en cada build (`remove_dir_all` antes del `git archive`).
53# O sea que cada receta paga su copia del monorepo y su `cargo vendor` SIEMPRE, con el pin que sea.
54# Ya estaba medido y en CLAUDE.md §3 bis, con estas dos recetas de ejemplo: `boveda` y
55# `shuma-pregunta` en el MISMO `b80f7567…` ocupaban 2,7 G **cada una**. Lo que sí se comparte es el
56# `CARGO_HOME` del hub —`cargo vendor` corre fuera del sandbox—, o sea la DESCARGA; la copia de
57# 2,4 G al árbol, no. El motivo para subir el pin es el arreglo de arriba y nada más.
58# ⚠ `cd9acd0d9` es el commit donde el `Cargo.lock` cierra de verdad: repone la arista `rpassword`
59# de `agora-cli`, que un merge de import (`338d4a9b9`) había resuelto quedándose con el lado viejo.
60# Sin ella `cargo vendor --locked` muere con «cannot update the lock file» sin nombrar el crate.
61# Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
62# `--locked`) corrida en una jaula con el registro INCOMPLETO devuelve 0 y deja un lock al que le
63# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto. Se cierra donde
64# el registro está completo; acá, en el worker.
65# Los pines anteriores: `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con
66# el navegador abierto la bóveda quedaba MUDA) y `6f0408d40` (2026-09-21, §7.undecies: una bóveda
67# que NO abrió le levantaba el socket al navegador igual, sobre la temporal
68# `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba `locked:false` y un `vault.save`
69# consentido se perdía con el proceso). Las dos recetas se mueven JUNTAS porque son las dos mitades
70# de la MISMA función —el dueño y el diálogo de consentimiento—, no por compartir nada en disco.
71repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
72commit = "de491e951687ef7a02e19d2592f8cc2c4b60fd66"
73cargo_vendor_dir = ".hammer-cargo-vendor"
74
75[build]
76compiler = "zig-cc"
77target   = "x86_64-linux-musl"
78link     = "dynamic"
79flags    = ["-p", "shuma-pregunta", "--bin", "shuma-pregunta"]
80
81# Fase `compile` explícita por `LOCKSTEP_XML_PATH` — la causa, entera, está en `mirada-greeter.toml`
82# y repetida en `recipes/boveda.toml`: `accesskit_winit` → `atspi` → `zbus-lockstep-macros`, cuyo
83# `#[validate]` panica al encontrar el subdir `xml/schemas/`. La comprobación falla a gritos porque
84# un `cp` mudo dejaría la variable apuntando a un directorio vacío.
85[build.phases]
86compile = '''
87set -e
88XMLDIR="$PWD/.atspi-lockstep-xml"
89mkdir -p "$XMLDIR"
90ls .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; }
91cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
92export LOCKSTEP_XML_PATH="$XMLDIR"
93printf '%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"
94chmod +x "$PWD/.hammer-zig-cc"
95RF="-C linker=$PWD/.hammer-zig-cc"
96rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
97CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline -p shuma-pregunta --bin shuma-pregunta -- -C target-feature=-crt-static
98'''
99install = '''
100set -e
101test -x target/release/shuma-pregunta || { echo "no hay target/release/shuma-pregunta" >&2; exit 1; }
102install -Dm755 target/release/shuma-pregunta /out/usr/bin/shuma-pregunta
103'''
104
105[deps]
106build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]