# 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-*`. ⚠ Ese párrafo decía que un pin distinto
# costaba «otro vendoreo de 2,4 G»: es FALSO y está corregido en el bloque `[source]` — el árbol se
# nombra por RECETA, así que cada una paga el suyo con el pin que sea.
name    = "shuma-pregunta"
version = "0.1.0"
license = "MIT OR Apache-2.0"

[source]
# ⚠ El pin subió el 2026-09-22 a `cd9acd0d9`, y el arreglo que trae es `4f2b5eac7`: **«el llavero
# falló» se contaba como «no hay identidad»**. Los cinco lectores de `pacha_llavero::SEED_IDENTIDAD`
# hacían `.ok().flatten()`, que aplasta tres estados en dos, y uno de los cinco es JUSTO el que
# pinta esta ventana: `pacha-boveda-llimphi` decía «La bóveda está cerrada. Se abre al entrar a la
# sesión» —verdad si no hay seed sembrada, MENTIRA si el llavero falló, porque entrar a la sesión
# no lo arregla—. `pacha-llavero` gana `SeedDeSesion` (`Hay`/`NoHay`/`Fallo`) con tres textos
# distintos a propósito. Medido en el LXC del worker, que es donde se destapó: `add_key` funciona y
# `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ con la seed presente en `/proc/keys` la app igual decía que
# no había (SDD 26 §7.terdecies).
# ⚠ El pin ya NO es propio: `cd9acd0d9` es también el de `pacha`/`pacha-secretos`. Lo que esta
# receta pide del commit es estar por encima de `eed3120b6` —donde llimphi aprende a pasarle el
# display handle a wgpu; sin eso el binario sella, arranca y NO ABRE VENTANA, con un «index out of
# bounds» que no nombra nada de esto (§7.septies)—, y `cd9acd0d9` lo está, así que el commit propio
# dejó de hacer falta.
# ⚠⚠ Y ACÁ SE CORRIGE UNA PREMISA QUE ESTA RECETA REPITIÓ TRES VECES: **compartir commit NO
# comparte el árbol de fuentes, así que no ahorra ningún vendoreo.** El árbol es
# `work/sources/<NOMBRE DE RECETA>-<commit>` (`crates/takana-build/src/fetch.rs`, el `format!` de
# `{}-{}`), y encima se BORRA y se rehace en cada build (`remove_dir_all` antes del `git archive`).
# O sea que cada receta paga su copia del monorepo y su `cargo vendor` SIEMPRE, con el pin que sea.
# Ya estaba medido y en CLAUDE.md §3 bis, con estas dos recetas de ejemplo: `boveda` y
# `shuma-pregunta` en el MISMO `b80f7567…` ocupaban 2,7 G **cada una**. Lo que sí se comparte es el
# `CARGO_HOME` del hub —`cargo vendor` corre fuera del sandbox—, o sea la DESCARGA; la copia de
# 2,4 G al árbol, no. El motivo para subir el pin es el arreglo de arriba y nada más.
# ⚠ `cd9acd0d9` es el commit donde el `Cargo.lock` cierra de verdad: repone la arista `rpassword`
# de `agora-cli`, que un merge de import (`338d4a9b9`) había resuelto quedándose con el lado viejo.
# Sin ella `cargo vendor --locked` muere con «cannot update the lock file» sin nombrar el crate.
# 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. Se cierra donde
# el registro está completo; acá, en el worker.
# Los pines anteriores: `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) y `6f0408d40` (2026-09-21, §7.undecies: 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). Las dos recetas se mueven JUNTAS porque son las dos mitades
# de la MISMA función —el dueño y el diálogo de consentimiento—, no por compartir nada en disco.
repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
commit = "de491e951687ef7a02e19d2592f8cc2c4b60fd66"
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"]