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>
This commit is contained in:
Sergio
@@ -3317,6 +3317,107 @@ llimphi de escritorio podía pintar sin Vulkan (§7.septies), y que el dueño at
|
||||
(§7.octies). Las tres se veían igual desde el navegador: una bóveda que no ofrece nada, sin un solo
|
||||
error. Es el argumento entero a favor de medir en metal y no leer ficheros.
|
||||
|
||||
#### 7.decies La bóveda estaba SELLADA y en ninguna imagen — el sexto lugar donde una extensión se enchufa (2026-09-21)
|
||||
|
||||
El §7.novies cerró la función: las seis etapas en verde, el diálogo a la vista, el control de decir
|
||||
que no. Lo que quedaba abierto era la **decisión 1 del §7.sexies** —«en qué imágenes se declaran»—
|
||||
con su respuesta escrita como **NO**, y con el motivo: mientras ninguna app llimphi pudiera pintar
|
||||
(§7.septies), declararlas era instalar 43 M de binarios que niegan todo sin un error.
|
||||
|
||||
Ese motivo se cayó el 2026-09-18. La respuesta de hoy es **SÍ, en las cuatro**, y antes de tomarla
|
||||
la pregunta se volvió a medir en vez de darla por sabida:
|
||||
|
||||
```
|
||||
atuq sealed perfiles=['escritorio-cosmic','escritorio-gnome','escritorio-kde','escritorio-sway']
|
||||
puriy-costura sealed perfiles=['escritorio-cosmic','escritorio-gnome','escritorio-kde','escritorio-sway']
|
||||
boveda sealed perfiles=[]
|
||||
shuma-pregunta sealed perfiles=[]
|
||||
```
|
||||
|
||||
**`sealed` con `perfiles: []` es la lección de `foot` otra vez** —y no por falta de haberla
|
||||
escrito: `targets.toml` la repetía **quince veces** antes de hoy—: una receta sellada que ningún
|
||||
perfil declara NO ESTÁ EN NINGUNA IMAGEN, y la métrica de clausura no lo puede ver porque mide lo
|
||||
declarado. Las dos entran a los cuatro perfiles de escritorio de
|
||||
`docs/state/targets.toml`, **las dos o ninguna**: sin el dueño `vault.match` no ofrece nada, y sin
|
||||
el diálogo `Command::new` falla y TODO `vault.fill` se deniega — media bóveda es una que niega todo
|
||||
en silencio. Cuestan **~43 M por imagen** (22 M + 21 M medidos sobre los artefactos sellados), contra
|
||||
los ~1,25 GiB que ya lleva el §6.7.
|
||||
|
||||
##### El hueco que apareció al declararlas: estar en la imagen no es poder abrirla
|
||||
|
||||
Con las dos raíces puestas, la app viaja en las cuatro imágenes y **sigue sin existir para quien la
|
||||
usa**: `recipes/boveda.toml` instalaba `/usr/bin/boveda` y nada más, y los lanzadores de los cuatro
|
||||
escritorios leen `/usr/share/applications`. A un binario que nadie lista sólo se llega escribiendo
|
||||
`boveda` en una terminal. Es **la misma forma de fallo, una capa más arriba**: la función instalada,
|
||||
apagada y sin un error — que es lo único que este capítulo entero viene persiguiendo.
|
||||
|
||||
Entra `boveda.desktop` en la fase `install` de la receta. Tres cosas se midieron antes de escribirlo:
|
||||
|
||||
- **el icono existe.** `Icon=dialog-password` es nombre del icon naming spec, y está en los tres
|
||||
temas que los perfiles declaran: `breeze-icons` (6 ficheros), `adwaita-icon-theme` (1),
|
||||
`cosmic-icons` (2). El cuarto perfil (sway) lleva sólo `hicolor`, que por diseño no trae iconos:
|
||||
ahí cae al genérico, que es degradarse y no romperse;
|
||||
- **el fichero lo acepta el validador de verdad** —el `desktop-file-validate` del artefacto
|
||||
`desktop-file-utils`, con `atuq.desktop` de control, que pasa sin una observación—. Deja un hint
|
||||
sobre `Categories=Utility;Security;`: que `Security` se empareja con `Settings` o `System`. **Las
|
||||
dos formas que callan ese hint lo cambian por uno peor** —medido: `Utility;Security;System;` y
|
||||
`Utility;Security;Settings;` traen dos categorías principales ⇒ «application might appear more
|
||||
than once in the application menu»—. Se queda como está, que es además lo que usa KeePassXC;
|
||||
- **⚠ y la ventana NO se va a poder emparejar con el lanzador, y no es de acá.** `llimphi_ui::run`
|
||||
no llama nunca a `with_name`, y winit 0.30.13 sólo manda `set_app_id` `if let Some(name) =
|
||||
attributes.platform_specific.name` ⇒ **la ventana sale sin `app_id`**, y con el título `"llimphi"`,
|
||||
que es el default de `App::title` y `BovedaApp` no sobrescribe. Por eso el `.desktop` no lleva
|
||||
`StartupWMClass`: no habría contra qué emparejarlo. Vale para **toda** app llimphi, no para ésta:
|
||||
el dock las ve a todas iguales y sin nombre. Es de llimphi —como el muro del §7.septies— y se
|
||||
arregla allá.
|
||||
|
||||
El `.desktop` mueve el hash de la receta: `b3:b0c6adc4` ⇒ `b3:3f1072cc`, reconstruida en el worker
|
||||
con la guarda del §7.quinquies puesta (`### receta verificada 3f1072cc…` antes de compilar nada,
|
||||
porque el latido revierte la receta del worker cada media hora y un acierto de caché sobre la receta
|
||||
vieja imprime `SELLADA` en cero segundos). Y el artefacto se miró por dentro, que es la regla 3:
|
||||
|
||||
```
|
||||
/.hammer/recipe.toml
|
||||
/usr/bin/boveda
|
||||
/usr/share/applications/boveda.desktop ← 22 M, y el validador del store lo acepta
|
||||
```
|
||||
|
||||
##### El SEXTO lugar, y su guardián
|
||||
|
||||
`test-atuq-boveda-coherente.py` decía —y este documento con él— que una extensión de `atuq` está
|
||||
enchufada en **cinco** lugares. Son **seis**, y el sexto es el que faltaba:
|
||||
|
||||
| lugar | qué decide | cómo se ve cuando falta |
|
||||
|---|---|---|
|
||||
| `manifest.json` | el id que la extensión declara | — |
|
||||
| `distribution/policies.json` | la política que la instala | navegador sin la función |
|
||||
| `native-messaging/*.json` | el permiso para hablarle al host | `connectNative` falla en silencio |
|
||||
| `atuq.cfg` | las preferencias que la acompañan | el gestor de Gecko se pelea por el campo |
|
||||
| `recipes/puriy-costura.toml` | el COMMIT del host: si sus verbos existen | «verbo desconocido» ⇒ se calla |
|
||||
| **`docs/state/targets.toml`** | **quién DECLARA al dueño y al diálogo en la imagen** | **`ok:true, locked:true`** |
|
||||
|
||||
El sexto chequeo mira `targets.toml` —el manifiesto de objetivo, no `build-state.json`, que es su
|
||||
derivado— y exige las dos raíces en los cuatro perfiles, con **control positivo**: `atuq` tiene que
|
||||
estar ahí, porque un `in` que no encuentra puede ser una raíz ausente o un campo equivocado y las dos
|
||||
se ven igual. El tercer control negativo (`--negative-control-perfil`) saca a `boveda` de una copia
|
||||
en memoria y exige que esto lo vea; sin él, un chequeo que siempre dice que sí se vería idéntico a
|
||||
uno que funciona. Probado en los dos sentidos: los cuatro perfiles en verde, y el control en rojo.
|
||||
|
||||
##### Lo que queda abierto, dicho como lo que es
|
||||
|
||||
1. **quién levanta la app.** Hoy: la persona, desde el lanzador. Mientras no esté abierta, la bóveda
|
||||
del navegador contesta `locked:true` —correcto, y es lo que hace cualquier gestor de contraseñas—,
|
||||
pero nadie decidió todavía si debe autoarrancar con la sesión. No se decide de paso: autoarrancar
|
||||
la ata a que la identidad del llavero esté desbloqueada en el login (la decisión 2 del §7.sexies,
|
||||
que sigue abierta);
|
||||
2. **el único proveedor de GL de las cuatro imágenes es `iris` (Intel).** `mesa-llvmpipe` no está en
|
||||
ningún perfil y `mesa-swrast` sólo en `escritorio-mirada` — y softpipe no le alcanza a wgpu, que
|
||||
pide compute (§7.septies). O sea que en metal sin GPU Intel el diálogo no pinta… igual que no
|
||||
pintaría el escritorio entero, que también es cliente de GL: **la bóveda no agrega un hueco, lo
|
||||
hereda**. Lo que taparía el caso de la VM es un proveedor por software en el perfil, y eso es una
|
||||
decisión de tamaño con dos candidatos (`mesa-llvmpipe`, o lavapipe como receta nueva), no un
|
||||
arreglo de paso.
|
||||
|
||||
## 8. Plan, por unidades de trabajo
|
||||
|
||||
Cada una cierra sola, se commitea y se pushea. El orden no es preferencia: cada una destraba a la
|
||||
@@ -3344,7 +3445,7 @@ siguiente.
|
||||
| 9 | **Medios (6.6) ✅ y torrent (6.9) ✅ — 2026-09-10.** El medio lo abre `mpv`; el torrent lo toma `puriy-costura-torrent`, un daemon **propio, configurable y perezoso** que sobrevive al navegador y cosecha al CAS. Medido antes de decidir: la pila de librqbit compila para musl (226 crates), así que la decisión fue «no ahí» y no «no se puede». **Faltan** el foco (6.5) y la IA local (6.7), ésta bloqueada porque el corpus no tiene modelo ni embeddings | 6.5–6.7, 6.9 | 5 ✅ |
|
||||
| 10 | **Foco (6.5) — 2026-09-10.** Entra al corpus la cadena `nftables` (libmnl + libnftnl + nft 1.1.6), que el grafo pedía y nadie había puesto, con dos arreglos de fábrica: el sello de tiempo que rompía la reproducción y un bashismo. Medido con root: el cgroup en foco no sale y el de al lado sí. Y del lado del navegador, la extensión `foco` MUESTRA el estado y **no tiene verbo para apagarlo**. **Falta** quién pone a `atuq` en un cgroup (delegación, decisión de arje) y quién aplica la política (root) | 6.5 | 6 ✅ |
|
||||
| 11 | **Motor de inferencia local (6.7) — 2026-09-11.** Entra `recipes/llama-cpp.toml` (b10901, estática, 199 M, **REPRODUCE**), que resulta ser **un solo muro para dos pendientes**: el §6.7 y la mitad semántica del §6.3 no eran dos problemas, era que el corpus no tenía con qué correr un modelo (`pluma-llm` sólo tiene backends de nube; `rimay-verbo-fastembed` DESCARGA onnxruntime glibc + el modelo). ⚠ Y dejó medido lo que no se podía deducir: **`SOURCE_DATE_EPOCH` —la variable que nos da reproducibilidad— apagaba las SEIS perillas de ISA de ggml**, y el artefacto sellaba y corría con 0 `%ymm`. Ahora van declaradas y el `install` las comprueba. Guardián `scripts/test-llama-cpp.py` con control negativo vivo. **Faltan** el modelo (fuente pineada, no receta), los verbos del host y quién levanta el servidor | 6.7, y la mitad semántica de 6.3 | 5 ✅ |
|
||||
| 12 | **La bóveda (SDD-BOVEDA §8) — a medias, 2026-09-15.** La décima extensión: ofrece la credencial del sitio abierto y no puede sacar una contraseña por su cuenta —`vault.match` contesta títulos y usuarios; la contraseña sale por `vault.fill`, que **pregunta en el escritorio**—. La dirección la pone el chrome, nunca la página. El gestor de Gecko se aparta como VALOR DE ARRANQUE y no como política. **Destrabada el 2026-09-16** (§7.quinquies.bis): el `Cargo.lock` de tawasuyu publicado —y resultó ser byte a byte el que la otra sesión ya tenía sin commitear—, el pin subido a `23a292863` ⇒ `b3:7d63655a`, construido en el worker (el vendoreo son 2,4 G y el hub estaba al 99%) y medido con el mismo `strings` que había diagnosticado el hueco: `vault` de **0 a 10**, con `cas`/`sct` de control. **Falta**, y no era lo que este renglón decía (§7.sexies, 2026-09-18): el host sellado contesta `vault.status → locked:true` porque **el dueño de la bóveda y el diálogo de consentimiento no estaban en el corpus** — la función está apagada de fábrica en las cuatro imágenes. Entran `recipes/boveda.toml` y `recipes/shuma-pregunta.toml`, **las dos SELLADAS el 2026-09-18** (`b3:59ffd74b` y `b3:99763eca`, construidas en el worker). ⚠ Y con eso apareció el muro de verdad, que no es de la bóveda: **ninguna app llimphi de escritorio abre ventana en esta distro** porque no hay Vulkan en ninguna imagen y el camino GL de llimphi arma la instancia sin display handle (§7.septies). **CERRADA el 2026-09-18** (§7.novies): el guardián de metal —`scripts/test-atuq-boveda-metal.py`— pasa sus **seis etapas**, con el navegador de verdad, el diálogo a la vista y el control de decir que NO. Para llegar hubo que arreglar **tres piezas ajenas al navegador**: el dueño y el diálogo no estaban en el corpus (§7.sexies), ninguna ventana llimphi podía pintar sin Vulkan (§7.septies, arreglado en llimphi) y el dueño atendía de a UN cliente, lo que con el navegador abierto dejaba la bóveda muda (§7.octies, arreglado en pacha con su test de regresión) | el gestor de contraseñas de la suite dentro del navegador | 5 ✅ |
|
||||
| 12 | **La bóveda (SDD-BOVEDA §8) — a medias, 2026-09-15.** La décima extensión: ofrece la credencial del sitio abierto y no puede sacar una contraseña por su cuenta —`vault.match` contesta títulos y usuarios; la contraseña sale por `vault.fill`, que **pregunta en el escritorio**—. La dirección la pone el chrome, nunca la página. El gestor de Gecko se aparta como VALOR DE ARRANQUE y no como política. **Destrabada el 2026-09-16** (§7.quinquies.bis): el `Cargo.lock` de tawasuyu publicado —y resultó ser byte a byte el que la otra sesión ya tenía sin commitear—, el pin subido a `23a292863` ⇒ `b3:7d63655a`, construido en el worker (el vendoreo son 2,4 G y el hub estaba al 99%) y medido con el mismo `strings` que había diagnosticado el hueco: `vault` de **0 a 10**, con `cas`/`sct` de control. **Falta**, y no era lo que este renglón decía (§7.sexies, 2026-09-18): el host sellado contesta `vault.status → locked:true` porque **el dueño de la bóveda y el diálogo de consentimiento no estaban en el corpus** — la función está apagada de fábrica en las cuatro imágenes. Entran `recipes/boveda.toml` y `recipes/shuma-pregunta.toml`, **las dos SELLADAS el 2026-09-18** (`b3:59ffd74b` y `b3:99763eca`, construidas en el worker). ⚠ Y con eso apareció el muro de verdad, que no es de la bóveda: **ninguna app llimphi de escritorio abre ventana en esta distro** porque no hay Vulkan en ninguna imagen y el camino GL de llimphi arma la instancia sin display handle (§7.septies). **CERRADA el 2026-09-18** (§7.novies): el guardián de metal —`scripts/test-atuq-boveda-metal.py`— pasa sus **seis etapas**, con el navegador de verdad, el diálogo a la vista y el control de decir que NO. Para llegar hubo que arreglar **tres piezas ajenas al navegador**: el dueño y el diálogo no estaban en el corpus (§7.sexies), ninguna ventana llimphi podía pintar sin Vulkan (§7.septies, arreglado en llimphi) y el dueño atendía de a UN cliente, lo que con el navegador abierto dejaba la bóveda muda (§7.octies, arreglado en pacha con su test de regresión). **Y ENTRA A LAS IMÁGENES el 2026-09-21** (§7.decies): hasta ese día las dos estaban `sealed` con `perfiles: []` —o sea selladas y en ninguna imagen, la lección de `foot` que ese mismo fichero repetía quince veces—, así que la función seguía apagada de fábrica aunque anduviera. Se declaran en los cuatro perfiles de escritorio (~43 M por imagen) y la receta aprende a instalar `boveda.desktop`, porque estar en la imagen no es poder abrirla: sin entrada en `/usr/share/applications` a la app sólo se llega escribiendo su nombre en una terminal. El guardián de coherencia pasa de CINCO lugares a SEIS —el sexto es `targets.toml`— con su tercer control negativo. **Abierto**: quién la levanta con la sesión, y de dónde sale la raíz de las claves (decisión 2 del §7.sexies) | el gestor de contraseñas de la suite dentro del navegador | 5 ✅ |
|
||||
| 9.a | **Proxy por contenedor ✅ v0.5** — contenedores por política + extensión con `proxy.onRequest` | 6.8, y NO dependía de 5: es API de Firefox | — |
|
||||
|
||||
Las unidades 2 y 4 son **paralelizables**: la toolchain no toca el chrome y el chrome no toca la
|
||||
|
||||
@@ -328,6 +328,30 @@ paquetes = [
|
||||
# trampa, porque el panel está en todas. Bajarlo de acá es bajarlo de la imagen, no de la receta.
|
||||
"llama-cpp",
|
||||
"ia-modelo-chat",
|
||||
# ── LA BÓVEDA DEL NAVEGADOR (SDD 26 §7.sexies, decisión 1 — 2026-09-21) ──────────────────────
|
||||
# `atuq` trae la décima extensión desde el 2026-09-15 y el host pineado atiende `vault.*` desde
|
||||
# el 2026-09-16; aun así la función venía **APAGADA DE FÁBRICA en las cuatro imágenes**, sin un
|
||||
# solo error: `vault.status` contesta `{"ok":true,"locked":true}` porque el host NUNCA abre la
|
||||
# base (sled toma lock exclusivo y el proceso que lanza Gecko muere y revive con cada pestaña);
|
||||
# le habla a un DUEÑO por un socket, y el dueño no estaba declarado en ningún perfil. Las dos
|
||||
# recetas estaban selladas desde el 2026-09-18 con `perfiles: []` — sellado ≠ instalado, que es
|
||||
# la lección de `foot`, escrita QUINCE veces en este fichero antes de hoy (`grep 'lección de
|
||||
# .foot.'`) y aun así vuelta a pasar. Y «cerrada» es una respuesta EXITOSA:
|
||||
# ni un log, ni un reintento, ni la insignia la distinguen de un usuario que no desbloqueó la suya.
|
||||
# `boveda` la app DUEÑA de la base: la abre para su ventana y levanta el socket del
|
||||
# navegador en un hilo. Sin ella, `vault.match` no ofrece nada, nunca.
|
||||
# `shuma-pregunta` el diálogo de consentimiento que `PorDialogo` lanza por PATH. Sin él,
|
||||
# `Command::new` falla ⇒ TODO `vault.fill` se deniega, indistinguible de que
|
||||
# la persona haya dicho que no.
|
||||
# **Las dos o ninguna**: media bóveda es una que niega todo en silencio. Cuestan ~43 M por imagen
|
||||
# (22 M + 21 M medidos sobre los artefactos sellados), contra los ~1,25 GiB del §6.7 de acá arriba.
|
||||
# ⚠ La respuesta fue NO hasta el 2026-09-18, y no por el tamaño: ninguna app llimphi de escritorio
|
||||
# podía abrir ventana sin Vulkan (§7.septies), así que declararlas habría sido instalar una bóveda
|
||||
# que niega todo. Eso se arregló en llimphi y se MIDIÓ en metal: las seis etapas de
|
||||
# `scripts/test-atuq-boveda-metal.py` en verde —con el navegador de verdad, el diálogo a la vista
|
||||
# y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
|
||||
"boveda",
|
||||
"shuma-pregunta",
|
||||
# ── CAPTURA Y STREAMING ──────────────────────────────────────────────────────────────────────
|
||||
# `obs-studio` (2026-09-04). A diferencia de mpv, ésta vive en ESTA COLA y no en el corpus, y no
|
||||
# es preferencia: su frontend es Qt6 y las 13 recetas Qt viven sólo en `incoming-kde`. Un qtbase
|
||||
@@ -566,6 +590,30 @@ paquetes = [
|
||||
# trampa, porque el panel está en todas. Bajarlo de acá es bajarlo de la imagen, no de la receta.
|
||||
"llama-cpp",
|
||||
"ia-modelo-chat",
|
||||
# ── LA BÓVEDA DEL NAVEGADOR (SDD 26 §7.sexies, decisión 1 — 2026-09-21) ──────────────────────
|
||||
# `atuq` trae la décima extensión desde el 2026-09-15 y el host pineado atiende `vault.*` desde
|
||||
# el 2026-09-16; aun así la función venía **APAGADA DE FÁBRICA en las cuatro imágenes**, sin un
|
||||
# solo error: `vault.status` contesta `{"ok":true,"locked":true}` porque el host NUNCA abre la
|
||||
# base (sled toma lock exclusivo y el proceso que lanza Gecko muere y revive con cada pestaña);
|
||||
# le habla a un DUEÑO por un socket, y el dueño no estaba declarado en ningún perfil. Las dos
|
||||
# recetas estaban selladas desde el 2026-09-18 con `perfiles: []` — sellado ≠ instalado, que es
|
||||
# la lección de `foot`, escrita QUINCE veces en este fichero antes de hoy (`grep 'lección de
|
||||
# .foot.'`) y aun así vuelta a pasar. Y «cerrada» es una respuesta EXITOSA:
|
||||
# ni un log, ni un reintento, ni la insignia la distinguen de un usuario que no desbloqueó la suya.
|
||||
# `boveda` la app DUEÑA de la base: la abre para su ventana y levanta el socket del
|
||||
# navegador en un hilo. Sin ella, `vault.match` no ofrece nada, nunca.
|
||||
# `shuma-pregunta` el diálogo de consentimiento que `PorDialogo` lanza por PATH. Sin él,
|
||||
# `Command::new` falla ⇒ TODO `vault.fill` se deniega, indistinguible de que
|
||||
# la persona haya dicho que no.
|
||||
# **Las dos o ninguna**: media bóveda es una que niega todo en silencio. Cuestan ~43 M por imagen
|
||||
# (22 M + 21 M medidos sobre los artefactos sellados), contra los ~1,25 GiB del §6.7 de acá arriba.
|
||||
# ⚠ La respuesta fue NO hasta el 2026-09-18, y no por el tamaño: ninguna app llimphi de escritorio
|
||||
# podía abrir ventana sin Vulkan (§7.septies), así que declararlas habría sido instalar una bóveda
|
||||
# que niega todo. Eso se arregló en llimphi y se MIDIÓ en metal: las seis etapas de
|
||||
# `scripts/test-atuq-boveda-metal.py` en verde —con el navegador de verdad, el diálogo a la vista
|
||||
# y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
|
||||
"boveda",
|
||||
"shuma-pregunta",
|
||||
# ── VISOR DE IMÁGENES, TAMBIÉN EN LAS CUATRO ─────────────────────────────────────────────────
|
||||
# `swayimg` y no `imv`, que era lo que proponía `docs/plan-apps-usuario-final.md`: imv dibuja con
|
||||
# OpenGL de función fija (`glBegin`/`glOrtho`) y esta distro NO tiene proveedor de GL de
|
||||
@@ -941,6 +989,30 @@ paquetes = [
|
||||
# trampa, porque el panel está en todas. Bajarlo de acá es bajarlo de la imagen, no de la receta.
|
||||
"llama-cpp",
|
||||
"ia-modelo-chat",
|
||||
# ── LA BÓVEDA DEL NAVEGADOR (SDD 26 §7.sexies, decisión 1 — 2026-09-21) ──────────────────────
|
||||
# `atuq` trae la décima extensión desde el 2026-09-15 y el host pineado atiende `vault.*` desde
|
||||
# el 2026-09-16; aun así la función venía **APAGADA DE FÁBRICA en las cuatro imágenes**, sin un
|
||||
# solo error: `vault.status` contesta `{"ok":true,"locked":true}` porque el host NUNCA abre la
|
||||
# base (sled toma lock exclusivo y el proceso que lanza Gecko muere y revive con cada pestaña);
|
||||
# le habla a un DUEÑO por un socket, y el dueño no estaba declarado en ningún perfil. Las dos
|
||||
# recetas estaban selladas desde el 2026-09-18 con `perfiles: []` — sellado ≠ instalado, que es
|
||||
# la lección de `foot`, escrita QUINCE veces en este fichero antes de hoy (`grep 'lección de
|
||||
# .foot.'`) y aun así vuelta a pasar. Y «cerrada» es una respuesta EXITOSA:
|
||||
# ni un log, ni un reintento, ni la insignia la distinguen de un usuario que no desbloqueó la suya.
|
||||
# `boveda` la app DUEÑA de la base: la abre para su ventana y levanta el socket del
|
||||
# navegador en un hilo. Sin ella, `vault.match` no ofrece nada, nunca.
|
||||
# `shuma-pregunta` el diálogo de consentimiento que `PorDialogo` lanza por PATH. Sin él,
|
||||
# `Command::new` falla ⇒ TODO `vault.fill` se deniega, indistinguible de que
|
||||
# la persona haya dicho que no.
|
||||
# **Las dos o ninguna**: media bóveda es una que niega todo en silencio. Cuestan ~43 M por imagen
|
||||
# (22 M + 21 M medidos sobre los artefactos sellados), contra los ~1,25 GiB del §6.7 de acá arriba.
|
||||
# ⚠ La respuesta fue NO hasta el 2026-09-18, y no por el tamaño: ninguna app llimphi de escritorio
|
||||
# podía abrir ventana sin Vulkan (§7.septies), así que declararlas habría sido instalar una bóveda
|
||||
# que niega todo. Eso se arregló en llimphi y se MIDIÓ en metal: las seis etapas de
|
||||
# `scripts/test-atuq-boveda-metal.py` en verde —con el navegador de verdad, el diálogo a la vista
|
||||
# y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
|
||||
"boveda",
|
||||
"shuma-pregunta",
|
||||
# ── VISOR DE IMÁGENES, TAMBIÉN EN LAS CUATRO ─────────────────────────────────────────────────
|
||||
# `swayimg` y no `imv`, que era lo que proponía `docs/plan-apps-usuario-final.md`: imv dibuja con
|
||||
# OpenGL de función fija (`glBegin`/`glOrtho`) y esta distro NO tiene proveedor de GL de
|
||||
@@ -1179,6 +1251,30 @@ paquetes = [
|
||||
# trampa, porque el panel está en todas. Bajarlo de acá es bajarlo de la imagen, no de la receta.
|
||||
"llama-cpp",
|
||||
"ia-modelo-chat",
|
||||
# ── LA BÓVEDA DEL NAVEGADOR (SDD 26 §7.sexies, decisión 1 — 2026-09-21) ──────────────────────
|
||||
# `atuq` trae la décima extensión desde el 2026-09-15 y el host pineado atiende `vault.*` desde
|
||||
# el 2026-09-16; aun así la función venía **APAGADA DE FÁBRICA en las cuatro imágenes**, sin un
|
||||
# solo error: `vault.status` contesta `{"ok":true,"locked":true}` porque el host NUNCA abre la
|
||||
# base (sled toma lock exclusivo y el proceso que lanza Gecko muere y revive con cada pestaña);
|
||||
# le habla a un DUEÑO por un socket, y el dueño no estaba declarado en ningún perfil. Las dos
|
||||
# recetas estaban selladas desde el 2026-09-18 con `perfiles: []` — sellado ≠ instalado, que es
|
||||
# la lección de `foot`, escrita QUINCE veces en este fichero antes de hoy (`grep 'lección de
|
||||
# .foot.'`) y aun así vuelta a pasar. Y «cerrada» es una respuesta EXITOSA:
|
||||
# ni un log, ni un reintento, ni la insignia la distinguen de un usuario que no desbloqueó la suya.
|
||||
# `boveda` la app DUEÑA de la base: la abre para su ventana y levanta el socket del
|
||||
# navegador en un hilo. Sin ella, `vault.match` no ofrece nada, nunca.
|
||||
# `shuma-pregunta` el diálogo de consentimiento que `PorDialogo` lanza por PATH. Sin él,
|
||||
# `Command::new` falla ⇒ TODO `vault.fill` se deniega, indistinguible de que
|
||||
# la persona haya dicho que no.
|
||||
# **Las dos o ninguna**: media bóveda es una que niega todo en silencio. Cuestan ~43 M por imagen
|
||||
# (22 M + 21 M medidos sobre los artefactos sellados), contra los ~1,25 GiB del §6.7 de acá arriba.
|
||||
# ⚠ La respuesta fue NO hasta el 2026-09-18, y no por el tamaño: ninguna app llimphi de escritorio
|
||||
# podía abrir ventana sin Vulkan (§7.septies), así que declararlas habría sido instalar una bóveda
|
||||
# que niega todo. Eso se arregló en llimphi y se MIDIÓ en metal: las seis etapas de
|
||||
# `scripts/test-atuq-boveda-metal.py` en verde —con el navegador de verdad, el diálogo a la vista
|
||||
# y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
|
||||
"boveda",
|
||||
"shuma-pregunta",
|
||||
# `dunst` es LA OTRA MITAD, y sólo hace falta acá: KDE la atiende con plasma-workspace, GNOME con
|
||||
# gnome-shell y COSMIC con cosmic-notifications; sway no tenía a NADIE escuchando
|
||||
# `org.freedesktop.Notifications`, así que una página que pedía notificar mandaba el mensaje al bus
|
||||
|
||||
Reference in New Issue
Block a user