El §7.undecies dejó la bóveda declarada y a NADIE capaz de abrirla: ninguna imagen traía un binario que sembrara `pacha_llavero::SEED_IDENTIDAD`. Esta es esa unidad. De las dos formas posibles entra `agora-cli`, y el motivo no es que sea mejor: el wizard `churay-welcome-llimphi` SÍ tiene binario (medido: `src/main.rs` sin `[[bin]]`, o sea que cargo lo descubre), pero decide además backend de IA, dotfiles, fondo de pantalla y chasqui — la experiencia de primer arranque entera, que no se decide dentro de una unidad del navegador. ⚠ Y antes de poder declararlo apareció lo que lo volvía imposible: sin `AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo "agora-dev" con un aviso por stderr y un ✓ en pantalla. La cadena que eso toca: frase → Argon2id → ChaCha20-Poly1305 que cifra la seed → la clave con la que `boveda` descifra su base. O sea, en una imagen de escritorio, la bóveda de todo el mundo cerrada con una palabra escrita en el fuente, y nada que falle. Arreglado en tawasuyu (`fd08dc03a`): variable > terminal (se pregunta, sin eco, y DOS veces en la génesis, donde un error de tipeo no se nota hasta que la seed ya no se recupera) > desarrollo sólo si no hay a quién preguntarle. La decisión vive en una función pura con cuatro tests, probada AL REVÉS: con el brazo `Preguntar` borrado falla con `left: Desarrollo / right: Preguntar`. Pin `9967b02c` → `da5fb8968` ⇒ `b3:46529e14`, 1,9 M, sellado en el worker con la guarda PEGADA al build. Mirado por dentro (regla 3) y probado como artefacto, con control negativo: `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys`, y con la frase equivocada contesta «autenticación fallida» y NO re-siembra. El muro del `Cargo.lock` por cuarta vez, con la causa cambiada: esta vez no la puso quien tocó el lock sino otro agente que metió `shuma-taller` en un `Cargo.toml`. Cerrado en el worker, donde el registro está completo: +1 línea. Y el lock del árbol compartido traía otra vez el malo (índice y árbol con dos versiones distintas, las dos rotas), así que el commit se armó con `commit-tree` sin pasar por el índice. Corrección al §7.undecies: el verbo es `agora-cli unlock`, no `agora-cli identity unlock`. El guardián de coherencia pasa de SEIS lugares a SIETE, con su cuarto control negativo; los cuatro, en verde. Queda: la herencia del llavero de SESIÓN entre procesos hermanos (sin medir — y `/proc/keys` como root no la mide), y `pacha`/`pacha-secretos` en `perfil.servidor` con el mismo hueco.
79 lines
5.3 KiB
TOML
79 lines
5.3 KiB
TOML
# agora-cli — la cara CLI del ágora (tawasuyu): opera el keystore y el grafo firmado en shell,
|
|
# compartidos con agora-app.
|
|
#
|
|
# ── POR QUÉ ESTA RECETA CAMBIÓ DE OFICIO (2026-09-21) ──────────────────────────────────────────
|
|
# Nació para la etapa G (poblar el catálogo con apps propias de tawasuyu) y estuvo sellada con
|
|
# `perfiles: []` —o sea en ninguna imagen— desde entonces. Entra a las cuatro imágenes de
|
|
# escritorio por otra razón, y es la que cierra la unidad 12 del SDD 26: **es el único binario del
|
|
# corpus capaz de sembrar la identidad con la que la bóveda se abre.**
|
|
#
|
|
# La cadena, medida entera hacia atrás desde la app (SDD 26 §7.undecies):
|
|
#
|
|
# `boveda` abre su base con una clave derivada de la seed de identidad
|
|
# └─ que `pacha-boveda-llimphi` saca del llavero de SESIÓN, clave `pacha_llavero::SEED_IDENTIDAD`
|
|
# └─ que en TODO tawasuyu escriben dos binarios: `agora-cli unlock`
|
|
# y el onboarding `churay-welcome-llimphi`
|
|
# └─ `agora-cli` estaba en ninguna imagen · `churay-welcome` no tiene receta
|
|
#
|
|
# ⇒ hasta hoy, en las cuatro imágenes, `abrir()` daba `Err(boveda-cerrada)` SIEMPRE. No «el
|
|
# usuario todavía no la desbloqueó»: **no tenía con qué**. Y como «cerrada» es una respuesta
|
|
# EXITOSA (`{"ok":true,"locked":true}`), ni un log ni la insignia la distinguían de lo otro.
|
|
#
|
|
# ⚠ **No es el camino de DISEÑO y conviene decirlo.** El de diseño es el wizard de bienvenida
|
|
# (`churay-welcome-llimphi`, que SÍ tiene binario: `src/main.rs` sin `[[bin]]` ⇒ cargo lo descubre
|
|
# con el nombre del paquete), que pide la frase en un campo y no en una terminal. Pero ese wizard
|
|
# decide además backend de IA, dotfiles, fondo de pantalla y chasqui: traerlo es decidir la
|
|
# experiencia de primer arranque entera, y eso no se hace de paso. Ésta hace UNA cosa, es la que
|
|
# el propio tawasuyu nombra como «la que siembra el login» (comentario de `pacha-secretos`), y no
|
|
# impone ningún flujo. Cuando `churay-welcome` tenga receta, esto se revisa.
|
|
#
|
|
# ── EL PIN, Y POR QUÉ NO ES EL DE SUS HERMANAS ────────────────────────────────────────────────
|
|
# Sube de `9967b02c` (2026-06-18) a `fd08dc03a`. Dos razones, las dos medidas:
|
|
#
|
|
# 1. **en el pin viejo el verbo no existe**: ni `SEED_IDENTIDAD` ni `desbloquear` están en ese
|
|
# commit (`git grep` sobre el pin da 0 y 0, con HEAD de control dando 4 y 1). O sea que
|
|
# declararlo en los perfiles con el pin viejo habría metido 3 M en cuatro imágenes que siguen
|
|
# sin poder abrir nada — el error de `foot`, otra vez, disfrazado de arreglo.
|
|
# 2. **y en el pin nuevo hay además un arreglo que este oficio vuelve obligatorio**: sin
|
|
# `AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo `"agora-dev"` con un
|
|
# aviso por stderr y un ✓ en pantalla. En una máquina de trabajo es cómodo; en una imagen de
|
|
# escritorio es **la bóveda de todo el mundo cifrada con una palabra pública**, porque el
|
|
# keystore que guarda la seed va con Argon2id + ChaCha20-Poly1305 bajo esa frase. Ahora, con
|
|
# terminal, se PREGUNTA (sin eco, y dos veces al crear); la frase de desarrollo queda sólo
|
|
# para el caso sin terminal —cron, pipes, CI—, que es a quien rompería quitarla.
|
|
# Arreglado en tawasuyu en `fd08dc03a`, con test en los dos sentidos.
|
|
#
|
|
# ⚠ Y el pin NO es `fd08dc03a` sino su hijo `da5fb8968`, por el muro del `Cargo.lock` que este
|
|
# monorepo pone CADA VEZ (SDD 26 §7.quinquies.bis, §7.octies, §7.undecies, y ésta): con
|
|
# `fd08dc03a`, `cargo vendor --locked` muere con «cannot update the lock file» porque un miembro
|
|
# del workspace (`shuma-taller`) había entrado a un `Cargo.toml` sin que el lock lo acompañara. El
|
|
# cierre se hizo **en el worker, sobre el árbol que takana ya había bajado**, que es donde el
|
|
# registro de cargo está completo: ahí el diff es +1 línea y cero checksums movidos. Corrido en la
|
|
# jaula, la misma operación devuelve 0 y BORRA miembros del workspace — y su diff se ve MÁS mínimo
|
|
# que el correcto, que es la trampa entera del §7.undecies.
|
|
#
|
|
# ⚠ El pin NO coincide con el de `boveda`/`shuma-pregunta` (`6f0408d40`) ni con el de sus hermanas
|
|
# de monorepo (`9967b02c`: `dominium-cli`, `cosmos-cli`, los `arje-*`). El árbol de fuentes se
|
|
# comparte por `<repo>-<sha>`, así que esto **paga un vendoreo propio de ~2,4 G** en el worker. Se
|
|
# paga a propósito: mover `boveda` (22 M, llimphi GUI) para que coincidan cuesta dos builds caros y
|
|
# arrastra 28 commits de upstream sin relación con esto. El día que el pin de `boveda` suba, que
|
|
# suba a éste y los árboles se colapsan.
|
|
name = "agora-cli"
|
|
version = "0.0.1"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
|
|
commit = "da5fb896843541ec5fb76f1d1c7752fa750cb140"
|
|
# 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. El
|
|
# pin viejo era de antes de que ese `vendor/` existiera, por eso esta receta no lo traía. No entra
|
|
# en `hash_inputs`.
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["-p", "agora-cli"]
|