main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SergioandClaude Opus 5
|
557e127f6f |
atuq: la bóveda entró a las imágenes y NADIE puede abrirla — y al navegador le servía una TEMPORAL
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> |
||
|
SergioandClaude Opus 5
|
e6ab5a5016 |
atuq: la bóveda estaba SELLADA y en ninguna imagen — y estar en la imagen no es poder abrirla
El §7.novies dio la función por cerrada: las seis etapas del guardián de metal en verde, con el
navegador de verdad y el diálogo a la vista. Lo que seguía abierto era la decisión 1 del §7.sexies
—«en qué imágenes se declaran»—, escrita como NO mientras ninguna app llimphi pudiera pintar. Ese
motivo se cayó el 2026-09-18, así que antes de tomarla se volvió a medir en vez de darla por sabida:
atuq sealed perfiles=[cosmic, gnome, kde, sway]
puriy-costura sealed perfiles=[cosmic, gnome, kde, sway]
boveda sealed perfiles=[]
shuma-pregunta sealed perfiles=[]
`sealed` con `perfiles: []` es sellado ≠ instalado: la lección de `foot`, que targets.toml repetía
QUINCE veces antes de hoy y que igual volvió a morder. Las dos entran a los cuatro perfiles de
escritorio, las dos o ninguna —sin el dueño `vault.match` no ofrece nada; sin el diálogo,
`Command::new` falla y TODO `vault.fill` se deniega—: media bóveda es una que niega todo en
silencio. ~43 M por imagen (22 M + 21 M medidos), contra los ~1,25 GiB que ya lleva el §6.7.
Y al declararlas apareció el hueco de una capa más arriba: la receta instalaba `/usr/bin/boveda` y
nada más, y los lanzadores de los cuatro escritorios leen `/usr/share/applications`. La app viajaría
en la imagen sin existir para quien la usa — la misma forma de fallo que esto viene persiguiendo.
Entra `boveda.desktop`, con tres cosas medidas antes de escribirlo:
· el icono existe: `dialog-password` está en breeze-icons (6), adwaita (1) y cosmic-icons (2). El
cuarto perfil lleva sólo hicolor, que no trae iconos: ahí cae al genérico, que es degradarse;
· lo acepta el `desktop-file-validate` del store, con `atuq.desktop` de control. Deja un hint sobre
`Security`, y las dos formas de callarlo lo cambian por uno PEOR (dos categorías principales ⇒ la
app aparece dos veces en el menú). Se queda como está;
· ⚠ y lo que NO puede hacer: emparejar la ventana con el lanzador. `llimphi_ui::run` no llama nunca
a `with_name` ⇒ winit no manda `set_app_id` y la ventana sale SIN app_id y con el título
"llimphi". Por eso no hay `StartupWMClass`. Vale para toda app llimphi; se arregla en llimphi.
La receta se reconstruyó en el worker con la guarda del §7.quinquies puesta (`### receta verificada
3f1072cc` antes de compilar nada, porque el latido revierte la receta cada media hora y un acierto
de caché sobre la vieja imprime SELLADA en cero segundos): `b3:b0c6adc4` ⇒ `b3:3f1072cc`, 22 M, con
el árbol mirado por dentro y la entrada dentro del artefacto.
Y el guardián de coherencia pasa de CINCO lugares a SEIS: el sexto es `targets.toml` —quién DECLARA
al dueño en la imagen—, con control positivo (`atuq` tiene que estar, o el chequeo está leyendo el
campo equivocado) y su propio control negativo, el tercero. Probado en los dos sentidos: cuatro
perfiles en verde, y `--negative-control-perfil` en rojo.
Abierto, y dicho como lo que es: quién levanta la app con la sesión (atado a la decisión 2 del
§7.sexies, la raíz de las claves), y que el único proveedor de GL de las cuatro imágenes es iris
—mesa-llvmpipe en ningún perfil—, que la bóveda hereda y no agrega.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
SergioandClaude Opus 5
|
bd8f9fbbb2 |
atuq: la bóveda ANDA hasta la etapa D — y con el navegador abierto quedaba muda por un tercer fallo
Con el arreglo de llimghi sellado, el guardián de metal pasó de la A a la D:
A ✓ sin la app dueña, el host contesta locked:true (y con ok:true, que es la trampa)
B ✓ con la app, vault.status dice ABIERTA — el socket sube en 1 s
C ✓ el diálogo ABRE en el compositor y se lo CONTESTA: «1» ⇒ yes, «2» ⇒ no (los dos sentidos)
D ✓ vault.save con consentimiento real guarda, y vault.match la encuentra SIN contraseña
E ✗ el navegador pide la contraseña y no llega nunca
La E destapó un fallo que no es de atuq ni de llimphi: el dueño de la bóveda atendía de a UN cliente
—`atender_cliente` no vuelve hasta que el cliente se va, y se lo llamaba en el hilo del accept—, así
que la primera conexión se quedaba con él mientras viviera. Y el caso normal es ése: Gecko lanza un
`puriy-costura` por PUERTO, ocho en atuq, y todos conectan al arrancar. La extensión de la bóveda
mandaba `vault.match` y no volvía nunca: sin insignia, sin log y sin error, indistinguible de «este
sitio no tiene contraseñas».
Control sin navegador, en los dos sentidos: un solo cliente contesta en milisegundos; con otro host
conectado y quieto, la misma pregunta queda colgada y la mata el timeout a los 30 s.
Arreglado en tawasuyu (`cf3540460`, un hilo por conexión; los diálogos los serializa ahora el Mutex
de la bóveda) con su test de regresión, que además cazó que el arreglo obvio —clonar el Dueno— borra
el socket en el Drop del primer hilo que termina. Los siete tests que ya había no podían ver el fallo:
abrían un cliente por vez, que es justo lo que producción nunca hace.
⚠ Y subir el pin volvió a chocar con el `Cargo.lock` abierto de tawasuyu. Lo que importa para la
próxima es CUÁL operación lo cierra: `cargo metadata` sin `--locked` da **1 línea** de diff y cero
checksums movidos; `cargo generate-lockfile` da 6.305 líneas y 750 checksums, e invalidaría el
vendoreo de todos. Publicado en `b80f7567c` con índice temporal (estaba MM).
Del lado del guardián, tres cosas que salieron de fallar:
· el contestador INSISTE hasta que la ventana se va — con el mismo `wtype rc=0`, una corrida
contestaba y otra volvía `denied`: la ventana entra al árbol del compositor antes de que llimphi
tenga el teclado enganchado, y un sleep más largo sólo mueve el borde;
· el contestador busca la ventana POR PATRÓN: con el navegador abierto, teclear «la enfocada» le
contestaría a la página, y eso es un sí que nadie dio;
· la sonda del chrome mira `isShownForTab` y la insignia ANTES de apretar — `triggerClickOrPopup`
sale por la puerta de atrás si la acción no está mostrada, y un click que no llega se ve igual que
una bóveda que no contesta. (Y `WebExtensionPolicy` no es global en el scope de una ventana: sale
del módulo. Eso costó una corrida.)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
SergioandClaude Opus 5
|
063200214c |
atuq: el muro de llimphi, arreglado en llimphi — y las dos recetas re-pineadas a ese commit
El §7.septies dejó el diagnóstico: sin display handle, el camino de escritorio de llimphi abre el display EGL surfaceless, la surface no tiene un solo formato y la app panica. El arreglo está empujado allá (`eed3120b6`) y son dos ficheros: `Hal::new_con_display` —que usa el `instancia_con` que YA existía para el camino layer-shell— y el llamador de escritorio pasándole la `window`, que estaba ahí, creada una línea antes para hacerle la surface. La pieza no faltaba: faltaba enhebrarla. Control antes de empujar, porque hasta reconstruir no se puede medir: `cargo check -p shuma-pregunta` pasa con el parche y FALLA con una rotura a propósito en la línea tocada — un check que no compila el fichero se ve igual que uno que sí. Commiteado allá con índice temporal (GIT_INDEX_FILE + commit-tree + push <sha>:main), que es lo único que publica dos rutas sin llevarse por delante los 181 ficheros que otra sesión tiene en vuelo; el control (`git diff-tree -r --name-only`) nombra dos. El primer push fue rechazado porque el remoto se movió: se rehízo el commit-tree sobre el FETCH_HEAD nuevo, comprobando antes que esos dos ficheros no habían cambiado allá. ⚠ Con esto el pin de las dos recetas DIVERGE del `23a292863` de sus once hermanas del monorepo, y eso cuesta un árbol de fuentes propio — otro vendoreo de 2,4 G, porque el árbol se comparte por `<repo>-<sha>`. Queda dicho en las dos recetas. ⚠ Y el sello todavía no está: las dos están encoladas en el worker detrás del build de rust. Hasta que sellen y la etapa B del guardián pase, esto es un arreglo compilado, no un arreglo medido. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
SergioandClaude Opus 5
|
589c656262 |
atuq: la bóveda del navegador contesta CERRADA — faltaban el dueño y el diálogo, no el guardián
El §7.quinquies.bis cerró la unidad 12 diciendo que el guardián de METAL «ahora sí se puede escribir
porque hay con qué correrlo». No se podía, y la primera pregunta que ese guardián iba a hacer lo dice
en veinte segundos, contra el artefacto sellado y por marcos de 4 bytes:
← {"id":1,"ok":true,"verb":"ping","version":"0.1.0"} ← el control: el host ESTÁ
← {"id":2,"ok":true,"verb":"vault.status","locked":true,...}
← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]}
stderr: puriy-costura: sin bóveda (No such file or directory): los verbos vault.* dirán «cerrada»
Lo que engaña es el `ok:true`: **«cerrada» es una respuesta exitosa**, así que ningún log, ningún
reintento y ninguna insignia la distinguen de un usuario que todavía no desbloqueó la suya. Hoy, en
las cuatro imágenes de escritorio, atuq instala la décima extensión y la función está apagada.
Las dos mediciones del §7.quinquies eran correctas y lo siguen siendo —`strings` da `vault` 10 veces,
`vigia-atuq-verbos` da cero verbos sin dueño—, pero las dos preguntan si el host CONOCE el verbo.
Ninguna pregunta quién contesta del otro lado del socket: el host no abre la bóveda nunca, a propósito
(sled toma un lock exclusivo y el proceso que lanza el navegador muere con cada pestaña), así que le
habla a un DUEÑO — y el dueño no estaba en el corpus. Saber el verbo no es poder contestarlo.
Entran las dos piezas que faltaban, las dos con el mismo efecto de «se ve apagado y nada falla»:
`boveda` (pacha-boveda-llimphi, el dueño único de la base, que levanta el socket del navegador) y
`shuma-pregunta` (el diálogo que lanza `PorDialogo`; sin él `Command::new` falla y **todo vault.fill
se deniega**, indistinguible de que el usuario haya dicho que no).
Las dos pineadas al MISMO 23a292863 que ya comparten puriy-costura, shuma-* y pacha-* —un pin
distinto es otro vendoreo de 2,4 G— y con la forma de mirada-greeter, que es el patrón de una llimphi
GUI: link dinámico (winit/wgpu dlopean EGL/Vulkan/wayland) y la inyección de LOCKSTEP_XML_PATH que
evita el panic de zbus-lockstep-macros en el subdir xml/schemas/ de atspi.
⚠ El sello TODAVÍA NO ESTÁ: las dos están encoladas en el worker detrás del build de rust, bajo
`flock -o`. Hasta que sellen, estas recetas son una hipótesis escrita, no un artefacto medido.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|