4621381050cff2ca28659398eabd075db12d218b
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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
|
4be4680310 |
atuq: la bóveda ENTREGA una contraseña, y sólo cuando alguien dice que sí — las seis etapas en verde
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-2 s
C ✓ el diálogo ABRE en el compositor y se lo CONTESTA: «1» ⇒ yes, «2» ⇒ no
D ✓ vault.save con consentimiento real guarda, y vault.match la encuentra SIN contraseña
E ✓ el navegador real, sobre una página servida por HTTP: la contraseña llega al CAMPO
F ✓ contestando que NO, al campo no llega NADA
Dos corridas seguidas en verde, 6 min cada una. La unidad 12 del SDD queda CERRADA.
La E es la promesa entera del §6 y sola no probaría nada —una bóveda que entrega siempre se ve
idéntica a una que entrega con permiso—; por eso la F corre lo mismo diciendo que no. Y lo que se
mide no es lo que el host contesta sino lo que hay EN EL CAMPO: la página delata al servidor lo que
le pongan. Es la lección del §7.quater aplicada al otro extremo.
Tres fallos del ARNÉS, los tres disfrazados de fallo del producto:
· `wait` a secas esperaba también a la app de la bóveda ⇒ la jaula se comía su timeout y a la app la
mataba un KILL, y con ella lo recién guardado (sled no alcanzaba a volcar). La etapa siguiente no
encontraba la credencial: «la bóveda no guarda», el diagnóstico contrario al verdadero;
· el diálogo NO responde al teclado mientras la app de la bóveda inicializa su GPU — dos llimphi
arrancando a la vez sobre render por software se pisan: doce teclas sin efecto y `denied` por
timeout con la ventana abierta. Ahora se espera a que la app PINTE (12-13 s), no a su socket;
· una sola tecla no alcanza y el borde se mueve: el contestador insiste hasta que la ventana se va,
que es la única señal que no depende de adivinar cuánto tarda.
El guardián entra ENTERO a la suite (era `--hasta A`): 20 en verde, ~38 min.
Lo que costó llegar: el guardián se escribió para medir una función y destapó tres piezas rotas,
NINGUNA en atuq — el dueño y el diálogo no estaban en el corpus, ninguna ventana llimphi podía pintar
sin Vulkan, y el dueño atendía de a un cliente. Las tres se veían igual desde el navegador: una
bóveda que no ofrece nada, sin un solo error.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
SergioandClaude Opus 5
|
2fafb3a589 |
atuq: el vigésimo guardián entra a la suite, y entra TRUNCADO — con el motivo escrito al lado
`test-atuq-boveda-metal --hasta A` pasa a correr con los otros diecinueve. Corre truncado a propósito: las etapas B..F chocan contra el muro del §7.septies —ninguna app llimphi de escritorio abre ventana sin Vulkan— que no es de la bóveda, y un rojo permanente por una causa ajena se aprende a ignorar en tres días. Lo que la A afirma es la medición que costó tres semanas de no ver: **sin la app dueña, el host contesta `locked:true` con `ok:true`**, o sea que «cerrada» es una respuesta exitosa. La cabecera del runner dice ahora 20 y avisa que un verde de éste NO dice que la bóveda ande. Es la misma advertencia que ese fichero ya se aplicó dos veces: un número escrito como predicción envejece callado, y un cuadro entero en verde puede ser un producto sano o un runner que no mide nada. Probado en los dos sentidos, que es lo único que distingue un guardián de una decoración: · en verde, 3 s, dentro del runner y sobre el sello vigente (`b3:e556024b`); · ROJO con una rotura a propósito —invertir la aserción de la etapa A— ⇒ salida 1. Y el tamaño que faltaba para la decisión del §7.sexies: `boveda` 22 M y `shuma-pregunta` 21 M, ~43 M por perfil. Hoy la respuesta a «en qué imágenes se declaran» es NO, y no por el tamaño: declararlas antes de que llimphi se destrabe sería instalar una bóveda que niega todo sin un error. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Sergio
|
2098e86ba4 |
atuq: la boveda ANDA — 19 guardianes en verde, y el bloqueo de tres semanas era un fichero sin empujar
El pin de `puriy-costura` subio a `23a292863` y con eso se apagaron los dos rojos del cable. La suite entera sobre `b3:e556024b`: **19 verdes, 0 rojos, 32,1 min**. No se toco ningun guardian — que la suite existiera ANTES del arreglo es lo que permite afirmarlo: el cuadro de ayer y el de hoy son el mismo instrumento. La medicion que cierra es la que abrio el §7.quinquies, leida al reves: `strings` sobre el binario sellado da `vault` **10** veces donde daba 0, con `cas`/`sct` de control; y `vigia-atuq-verbos` pasa de 3 verbos sin dueno a cero, con su control positivo intacto. Lo destrabo publicar el `Cargo.lock` de tawasuyu (`23a292863` alla), regenerado en un arbol limpio: 215 lineas, todas de contabilidad de deps por ruta, cero `checksum` y cero `source` movidos. Y el remate, que es la leccion: **ese lock era byte a byte el que la otra sesion ya tenia en su arbol sin commitear**. Tres semanas de bloqueo y el fichero correcto estaba escrito, sin empujar, a un directorio de distancia. Antes de decir «bloqueado por otro repo», mirar si lo que falta no esta ya hecho y sin publicar. Commiteado alla con indice temporal (`GIT_INDEX_FILE` + `commit-tree`), que es la unica forma de publicar una ruta en `MM` sin llevarse por delante lo del otro agente: su arbol quedo byte a byte igual, comprobado con `cmp` antes y despues. ⚠ Y la cabecera del runner se desmintio SOLA dos veces: anuncio «un rojo» cuando eran dos, y «dos» cuando ya no quedaba ninguno. Un numero escrito como prediccion envejece callado. Con todo en verde el numero ya no distingue un producto sano de un runner que no corre nada, asi que lo que sostiene la corrida queda escrito: la puerta del sello (verificada contra un store vacio) y el control interno de cada guardian. |
||
|
Sergio
|
fb7dba530d |
atuq: el que estaba «nombrado como hueco» entra a la suite — 17 verdes y 2 rojos en 32 min
La primera version dejaba afuera al guardian de notificaciones (`dunst-headless.sh --via-atuq`) con
la excusa de que vive en el arnes de sway, y lo escribia en la cabecera «para que su ausencia no se
lea como cobertura». Eso dura tres dias: al cuarto la lista ES la cobertura y el parrafo no lo lee
nadie. Corrido aparte: verde en 180 s. Entra.
Es ademas el que mide lo que ningun auditor de ELF puede ver: una pagina llama `new
Notification(...)`, `libxul` hace `dlopen("libnotify.so.4")` —que no es NEEDED de nada—, el bus
activa dunst y dunst DIBUJA. Cinco piezas y la unica forma de saber que estan las cinco es verlo.
Para que entrara, la lista pasa a llevar el COMANDO de cada guardian en vez de su nombre de fichero:
lo que lo tenia afuera era el despacho por extension, no una decision.
Corrida entera de los diecinueve sobre `b3:e556024b`: **17 verdes, 2 rojos, 32,2 min**, que es
exactamente lo que la cabecera predice — y la cabecera es el control, no un adorno.
Los caros: sct 242 s, archivo semantico 238 s, ia 182 s, instalacion 180 s, notificaciones 180 s.
Los cuatro primeros salen en 5 s y no tocan el navegador.
|
||
|
Sergio
|
ba202d7826 |
atuq: los dieciocho guardianes en UN comando — y el sello llevaba nueve horas atrás
`atuq` es `source.dir` entero, asi que el commit de la boveda de esta manana (`6f0ba974`) movio el ArtifactHash y dejo el artefacto vigente SIN SELLAR. Durante esas nueve horas ningun guardian podia medir: se niegan a correr contra uno que no sea el vigente, que es lo correcto. Pero un guardian que se niega solo grita CUANDO alguien lo corre, y nadie lo corria — el repo se veia sano y la unica senal era un `hash --check` que nadie tenia motivo para teclear. Resellado en 3,7 s (es derivado y el firefox vigente estaba en el store) y corridos los dieciocho sobre `b3:e556024b`: 16 en verde y 2 en ROJO, los dos por la MISMA causa —los tres verbos de la boveda del §7.quinquies—. O sea que la unidad 12 no rompio nada de al lado, que es lo que habia que saber antes de seguir: toco `atuq.cfg`, la politica y el empaquetado de extensiones. `scripts/test-atuq-suite.sh` deja eso en un comando, en serie (cuatro nucleos sin swap; dos navegadores a la vez es un OOM) y cada guardian a SU fichero, porque dos corridas sobre el mismo log se mezclan y el resultado parece un pase. Lo primero que mira es el sello y NO corre nada si falta: verificado contra un store vacio, sale por ahi y devuelve 1. Dos cosas quedan escritas como control y no como adorno: · el numero de rojos esperados va en la cabecera. Un cuadro entero en verde puede ser un producto sano o un runner que no corre nada, y se ven igual; · esa cabecera decia «un rojo» —prediccion escrita antes de correr— y la primera corrida dijo dos: el guardian de coherencia de la boveda lleva el mismo chequeo del cable adentro. Coste medido en gioser: ~29 min. Los cuatro primeros salen en 10 s y no tocan el navegador. |