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-*` — un pin distinto es otro vendoreo de
28# 2,4 G del workspace entero.
29name    = "shuma-pregunta"
30version = "0.1.0"
31license = "MIT OR Apache-2.0"
32
33[source]
34# ⚠ El pin subió el 2026-09-21 a `6f0408d40`: **una bóveda que NO abrió le levantaba el socket al
35# navegador igual**, sobre la temporal `/tmp/boveda-sin-abrir-<pid>` ⇒ `vault.status` contestaba
36# `locked:false` y un `vault.save` consentido se perdía con el proceso. Es el caso NORMAL en las
37# cuatro imágenes, donde nada puede sembrar la identidad (SDD 26 §7.undecies). Arreglado con test
38# de regresión en los dos sentidos (el arreglo es `7917fbb96`; éste trae además el `Cargo.lock`
39# cerrado de VERDAD, sin el cual `cargo vendor --locked` muere con «cannot update the lock file»).
40# ⚠ Y ojo con cómo se cierra ese lock: la operación mínima documentada (`cargo metadata` sin
41# `--locked`) corrida en una jaula con el registro INCOMPLETO devuelve 0 y deja un lock al que le
42# faltan dos miembros del workspace — y su diff se ve MÁS mínimo que el correcto (-15 líneas contra
43# +1). Se cierra donde el registro está completo; acá, en el worker.
44# El pin anterior fue `b80f7567c` (2026-09-18, §7.octies: el dueño atendía de a UN cliente y con el
45# navegador abierto la bóveda quedaba MUDA). Las dos recetas se mueven juntas para no pagar un
46# tercer vendoreo de 2,4 G: comparten árbol por `<repo>-<sha>`.
47# ⚠ EL PIN NO ES EL DE SUS HERMANAS, Y ES A PROPÓSITO (desde el 2026-09-18). Las demás recetas del
48# monorepo están en `23a292863`, que es ANTERIOR a `eed3120b6` — el commit donde llimphi aprende a
49# pasarle el **display handle** a wgpu en el camino de escritorio—, y sin eso este binario sella,
50# arranca y **no abre ventana**: wgpu cae a la plataforma EGL surfaceless, la surface no tiene un
51# solo formato y la app panica con un «index out of bounds» que no nombra nada de esto (SDD 26
52# §7.septies). Por eso ésta y `boveda`/`shuma-pregunta` van siempre a un commit posterior; cuál es
53# hoy lo dice el bloque de arriba, que es el que se actualiza. El precio es un árbol de fuentes
54# propio —otro vendoreo de 2,4 G, porque el árbol se comparte por `<repo>-<sha>`—; se paga hasta
55# que las demás suban al mismo commit.
56repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
57commit = "6f0408d40d05d7961e811f9062ce5d5127987635"
58cargo_vendor_dir = ".hammer-cargo-vendor"
59
60[build]
61compiler = "zig-cc"
62target   = "x86_64-linux-musl"
63link     = "dynamic"
64flags    = ["-p", "shuma-pregunta", "--bin", "shuma-pregunta"]
65
66# Fase `compile` explícita por `LOCKSTEP_XML_PATH` — la causa, entera, está en `mirada-greeter.toml`
67# y repetida en `recipes/boveda.toml`: `accesskit_winit` → `atspi` → `zbus-lockstep-macros`, cuyo
68# `#[validate]` panica al encontrar el subdir `xml/schemas/`. La comprobación falla a gritos porque
69# un `cp` mudo dejaría la variable apuntando a un directorio vacío.
70[build.phases]
71compile = '''
72set -e
73XMLDIR="$PWD/.atspi-lockstep-xml"
74mkdir -p "$XMLDIR"
75ls .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; }
76cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
77export LOCKSTEP_XML_PATH="$XMLDIR"
78printf '%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"
79chmod +x "$PWD/.hammer-zig-cc"
80RF="-C linker=$PWD/.hammer-zig-cc"
81rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
82CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline -p shuma-pregunta --bin shuma-pregunta -- -C target-feature=-crt-static
83'''
84install = '''
85set -e
86test -x target/release/shuma-pregunta || { echo "no hay target/release/shuma-pregunta" >&2; exit 1; }
87install -Dm755 target/release/shuma-pregunta /out/usr/bin/shuma-pregunta
88'''
89
90[deps]
91build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]