1# SDD 26 — `atuq`: el envoltorio Gecko de la distro
2
3Escrito 2026-09-05, a partir de la pregunta del usuario: *«ya habiendo compilado firefox y waterfox,
4qué tan complicado vs provechoso suena crear nuestro propio envoltorio, en vez de zen?»*, y de su
5aclaración de por qué la pregunta existe: **`puriy` quedó muy verde y es difícil sacarlo de ahí**.
6
7`atuq` es *zorro* en quechua. El nombre estaba libre —verificado con `grep -ri atuq` sobre
8`/mnt/vvv/takana` y `/mnt/vvv/tawasuyu`, cero coincidencias— y dice exactamente lo que la cosa es:
9otro fox, con marca propia y sin usar la de Mozilla (ver el §branding de `recipes/firefox.toml`).
10
11**Este documento no reemplaza a `puriy` ni lo cancela.** `puriy` sigue siendo el motor soberano; el
12§9 explica por qué `atuq` es su andamio y no su desvío.
13
14---
15
16## 1. La corrección que ordena todo: no hay envoltorio fuera del chrome
17
18La intuición natural —una carcasa Llimphi con nuestros widgets, y Gecko adentro pintando la página—
19**no es posible**. Gecko no tiene API de embebido en escritorio desde que murió XULRunner; GeckoView
20existe y es de Android. No hay forma soportada de meter el motor en una ventana de `mirada`.
21
22⇒ un envoltorio de Gecko es, necesariamente, **chrome-level**: JS/CSS/XHTML *dentro* del propio
23Firefox, más extensiones, más procesos externos que hablen con él.
24
25Y eso es exactamente lo que Zen es. Zen no toca el motor: su diferencia entera —workspaces, split
26view, glance, compact mode— vive en el chrome, más una herramienta (`surfer`) que reaplica sus
27parches sobre el árbol de Firefox y recompila. **Su costo no es el motor: es la cinta de correr del
28rebase cada cuatro semanas.** Copiar su método sería heredar su costo sin heredar su equipo.
29
30## 2. La decisión de arquitectura: artefacto DERIVADO, no fork de fuente
31
32Si `atuq` parchea el árbol, **cada iteración de UI cuesta un build de Gecko de cuatro horas**. Eso
33mata el proyecto en la primera semana de diseño, porque el diseño de chrome es iterativo por
34naturaleza.
35
36Pero nosotros no distribuimos un binario: sellamos artefactos. Entonces `atuq` es una receta cuyo
37`[deps]` incluye `firefox`, y cuyas fases copian el árbol instalado e inyectan encima:
38
39| Qué se inyecta | Mecanismo de Firefox | Sin recompilar |
40|---|---|---|
41| Marca, iconos, nombre | `distribution/`, `application.ini` | ✅ |
42| Prefs de fábrica | `defaults/pref/*.js` + autoconfig (`.cfg`) | ✅ |
43| Política de empresa | `distribution/policies.json` | ✅ |
44| Chrome propio (dientes, layout) | `userChrome.css` + re-empaque de `omni.ja` | ✅ |
45| Extensiones nuestras | `distribution/extensions/` | ✅ |
46
47**Ventajas que esto tiene sobre el método de Zen, y que son estructurales:**
48
491. **Iteración en segundos, no en horas.** El chrome se toca sin volver a compilar C++.
502. **No mueve el `ArtifactHash` de `firefox`.** El corpus no se invalida; `waterfox` y cualquier otro
51   fork siguen compartiendo el mismo artefacto base.
523. **Las CVE se heredan gratis.** Un fork de fuente te vuelve dueño del reloj de seguridad del
53   binario más atacado de la máquina — es lo que hundió a casi todos los forks de Firefox, y el
54   reproche histórico a Waterfox. Un derivado se reconstruye solo cuando sube `firefox`.
55
56**Los dos gotchas reales del camino, que son trabajo pero chico:**
57
58- **`omni.ja` es un zip ⇒ hay que re-empacarlo determinista** (mtimes fijos, orden estable) o el
59  artefacto deja de reproducir bit a bit. Es la misma disciplina que ya exige la imagen del lab.
60- **El `jarlog` del PGO ordena el `omni.ja` para el arranque** (§3.bis). Re-empacarlo a lo bruto
61  tira esa optimización a la basura sin que nadie lo note. El re-empaque preserva el orden.
62- **Hay que invalidar el startup cache** tras tocarlo (fichero `.purgecaches` junto al binario, o
63  bump del BuildID). Si no, los cambios no se ven y **parece que el overlay no agarró**: un falso
64  negativo de los caros, de la misma familia que el cache-hit que congela regresiones.
65
66### 2.bis Cuándo SÍ hay que parchear el árbol
67
68Cuando algo necesite tocar C++ del motor. Hoy conocemos un caso: `sct` en su forma fuerte (§6.1).
69La regla es: **nada baja al árbol antes de que exista la toolchain del §3**, porque hasta entonces
70cada intento cuesta cuatro horas. Y cuando baje, el vigía de parches (`scripts/vigia-parches.py`,
71commit `aa200a4`) es lo que convierte esas cuatro horas en un minuto para saber si el parche agarra.
72
73## 3. La puerta de las optimizaciones: no es un flag, es una toolchain
74
75El usuario decidió habilitar las optimizaciones. Lo que hay que saber antes de intentarlo:
76
77`recipes/firefox.toml` va con `compiler = "gcc"` por el **muro 3** (zig enlaza `libc++` estática para
78musl y el `configure` de Mozilla exige encontrar un `NEEDED …libc++`; es negativa de upstream, no una
79perilla). El problema es que **PGO, LTO y BOLT son cadena de clang en Gecko**:
80
81- `--enable-lto=cross` quiere clang + lld. El LTO de GCC sobre Gecko no está soportado upstream.
82- `--enable-profile-use` espera `-fprofile-instr-use` (clang), no `-fprofile-use` (gcc).
83- BOLT necesita `llvm-bolt`.
84
85Y **el corpus no tiene clang usable como compilador**. Verificado en las recetas, no supuesto:
86
87- `recipes/clang18.toml` compila `ninja -C build libclang.so clang-resource-headers` y su fase
88  `install` copia **sólo** `build/lib/libclang.so*` y las cabeceras `clang-c`. Está ahí porque
89  `bindgen` carga `libclang.so` en runtime. **No hay driver `clang`, ni `lld`, ni `libc++`.**
90- `llvm18` se selló con `-DLLVM_ENABLE_PROJECTS=""` — LLVM a secas.
91
92⇒ la primera versión de este documento concluyó que hacía falta **una receta `llvm-toolchain`
93(clang+lld+libc++ desde fuente)**. **Era caro de más, y se corrigió el mismo día mirando el lab en
94vez de suponerlo:**
95
96- `.dev-fs/alpine` **ya trae clang22 + llvm22 22.1.8** — la misma major que usa el APKBUILD de
97  Alpine para este mismo Firefox (`_llvmver=22`).
98- **`Compiler::Clang` ya existe en takana**, cableado de punta a punta (`parse_compiler` lo acepta;
99  `takana-build` pone `CC=clang`, `CXX=clang++`, `AR=llvm-ar`). Ninguna receta lo usaba.
100- Faltaba **sólo `ld.lld`**: `apk add lld` ⇒ dos paquetes, cero upgrades.
101
102Y los tres muros caen sin perder lo que gcc daba: el sondeo de linker se satisface con
103`--enable-linker=lld`, el `ar` lo pone takana solo, y el `NEEDED` de la stdlib de C++ existe porque
104clang++ de Alpine usa la `libstdc++` **compartida** — la prueba no es teórica: Alpine construye este
105Firefox con clang22 y **sin** `libcxx` en sus makedepends.
106
107**La huella del lab no se movió, y se midió antes de tocar nada.** `lld` no casa ningún prefijo de
108`TOOLCHAIN_PREFIXES` (`takana-core/src/lab.rs`), así que los 43 paquetes que entran en `hash_inputs`
109salieron idénticos ⇒ **los 837 artefactos sellados quedan intactos**. Eso abarata el cambio hoy y a
110la vez deja un agujero escrito: la versión de `lld` no es parte de la identidad del artefacto, y sólo
111expone a las recetas `compiler="clang"` — hoy, una. Cerrarlo cuesta re-hashear el corpus entero.
112
113**Hecho el 2026-09-05** (commit `cb3ecd5`): `firefox` va con `compiler = "clang"`,
114`--enable-linker=lld`, `--enable-lto=cross`, `--enable-packed-relative-relocs` y
115`--with-unsigned-addon-scopes=app,system`. Falta construirlo.
116
117**Riesgos de PGO, escritos antes de empezar:**
118
119- El PGO de Mozilla **corre el navegador** para juntar el perfil (`profileserver.py`, headless +
120  marionette). Dentro de un sandbox hermético, sin red y sin X11, eso hay que hacerlo andar.
121  Headless no necesita display, pero sí necesita que el árbol de perfil se genere adentro.
122- **El perfil resultante es un input del artefacto.** O entra en `hash_inputs`, o `atuq` deja de ser
123  determinista y no lo vamos a notar: sería otra forma del lab que no está en `hash_inputs`.
124- Ganancia esperable, para calibrar expectativas: PGO+LTO en Gecko son del orden de 10-25% en carga
125  de página y JS. **Hoy estamos ATRÁS de Zen en este eje, no adelante** — Zen hereda la
126  configuración de Mozilla tal cual. Esto no es una ventaja nuestra: es una deuda que se salda.
127
128### 3.bis El diff contra Alpine — y no es sólo PGO
129
130Medido el 2026-09-05 trayendo el `APKBUILD` y el `mozconfig` de `community/firefox` de aports y el
131`PKGBUILD` de Arch, y comparándolos línea a línea con el mozconfig de `recipes/firefox.toml`.
132**Alpine es nuestro propio upstream** —de ahí salen los once parches de musl— así que la comparación
133no es contra una distro lejana: es contra la que ya construye este mismo código.
134
135| | `recipes/firefox.toml` | Alpine `community/firefox` |
136|---|---|---|
137| LTO | **no** | `--enable-lto=cross` |
138| PGO | **no** | `--enable-profile-use=cross` + `merged.profdata` + `jarlog` |
139| Linker | GNU ld (via gcc) | `--enable-linker=lld` (lld 22) |
140| RELR | **no** | `--enable-packed-relative-relocs` |
141| Sandbox RLBox | **APAGADO** (`--without-wasm-sandboxed-libraries`) | `--with-wasi-sysroot` |
142| Extensiones sin firmar | **no declarado** | `--with-unsigned-addon-scopes=app,system` |
143| Allocator | `--disable-jemalloc` | `--disable-jemalloc` — **igual, no es desviación nuestra** |
144| Librerías | todo bundleado | `--with-system-{icu,nss,nspr,av1,vpx,webp,png,jpeg,zlib,ffi,libevent,pixman,pipewire}` |
145
146Arch hace lo mismo en el eje de velocidad («Do 3-tier PGO», `--enable-lto=cross`,
147`--enable-profile-use=cross`). **Ni Alpine ni Arch usan BOLT** (cero menciones en los dos ficheros)
148⇒ BOLT no es la desventaja, es el extra. Lo que nos separa del resto del mundo es **PGO + LTO**, del
149orden de 10-20% en carga de página y JS.
150
151**Tres lecturas que hay que sacar de esa tabla:**
152
1531. **RLBox apagado es una desventaja de SEGURIDAD, no de velocidad, y probablemente pesa más que el
154   PGO.** Es la jaula wasm alrededor de los parsers de fuentes y medios —graphite, ogg, expat,
155   woff2—, o sea exactamente el código que come entrada no confiable. Encenderlo pide `wasi-sdk` +
156   `wasi-compiler-rt` en el corpus: receta propia, no un flag.
1572. **`--with-unsigned-addon-scopes=app,system` nos falta y `atuq` lo NECESITA** para shipear sus
158   propias extensiones desde `distribution/extensions/` (§6.1, §7). Es un flag de `configure` ⇒
159   **una capacidad de `atuq` que no se resuelve en el overlay: exige tocar la base.**
1603. **Las librerías del sistema son diferencia a propósito, no deuda.** Alpine usa las suyas; nuestro
161   corpus *es* la fuente y bundlear es lo que mantiene la clausura cerrada.
162
163**Corolario que ordena el plan: todo esto entra en UN SOLO rebuild de `firefox`.** Cada rebuild son
164cuatro horas y re-sella la cola Gecko entera (waterfox incluido), así que LTO, PGO, RELR, lld, RLBox
165y el scope de addons se juntan en una sola pasada, no en seis.
166
167### 3.ter Los dos muros del PGO que las distros no tienen
168
169**El perfil se junta corriendo el navegador, y las dos distros lo hacen bajo `xvfb-run`** (Alpine:
170`xvfb-run -a -s "-screen 0 1920x1080x24" ./mach python build/pgo/profileserver.py`; Arch, idéntico).
171**Nosotros no tenemos X11 en el corpus** —es la decisión Wayland-only de toda la distro— así que ese
172camino no existe acá. La salida takana-nativa es correrlo bajo un **sway headless**
173(`WLR_BACKENDS=headless`), que ya tenemos del frente wlr/sway y arranca en segundos.
174
175**✅ EL MURO DEL DISPLAY ESTÁ DESPEJADO (2026-09-06).** No es una previsión: se corrió. `sway`
176headless con `WLR_BACKENDS=headless` y `WLR_RENDERER=pixman` arranca en **gioser**, que es un LXC
177**sin `/dev/dri`** —o sea sin GPU ninguna, todo software— y dibuja píxeles de verdad:
178`docs/evidencia/sway-headless-gioser-sin-gpu-2026-09-06.png` (sway 1.10 / wlroots 0.18.2 /
179foot 1.27.0, los tres binarios nuestros, salida `HEADLESS-1` a 1280x720). El ciclo entero es de
180~2 min con `scripts/wlr/sway-headless.sh`.
181
182Dos cosas que hubo que resolver y conviene tener escritas antes de repetirlo:
183· **Hidratar bajo el montaje del store.** `hydrate-profile.py` ENLAZA, y un hardlink no cruza
184  montajes: con `--into work/...` sale `EXDEV` porque el store vive en otro disco. Con
185  `--into store/.rootfs/sway` son 193/193 nodos, 41.677 ficheros y **4,9 G que no ocupan** (son
186  hardlinks al store).
187· **Inyectar el loader de musl.** `sway` salió DINÁMICO y pide `/lib/ld-musl-x86_64.so.1`, que el
188  cierre no trae; el error es `exec: /usr/bin/sway: not found`, que se lee como «falta el binario»
189  y lo que falta es su intérprete. Se resuelve con
190  `--ro-bind /usr/lib/musl/lib/libc.so /lib/ld-musl-x86_64.so.1` (en musl el `libc.so` ES el
191  loader). Es la misma familia que el resto de la noche: el mensaje nombra lo que buscó, no lo que
192  falta.
193
194**Y el perfil no es determinista.** Los contadores dependen del timing de la corrida, así que dos
195generaciones del profdata no dan los mismos bytes — a las distros no les importa porque no persiguen
196bit-repro; a nosotros nos rompe el invariante. La salida: **generar el perfil UNA vez y sellarlo como
197artefacto propio, consumido por hash** desde `firefox`. El build optimizado vuelve a ser determinista
198aunque su insumo no lo sea, y el perfil se regenera a propósito, no por accidente.
199
200### 3.quinquies El PGO, y los tres muros que el plan no tenía escritos (2026-09-07)
201
202El §3.ter daba dos muros: el display (X11 que no tenemos) y el no-determinismo del perfil. Los dos
203eran ciertos. Aparecieron **tres más**, y ninguno se ve sin construir:
204
2051. **`libclang_rt.profile.a` no existía.** El lab trae clang 22.1.8 pero **ninguna runtime de
206   compiler-rt** — su `lib/` del resource dir ni existe, exactamente como ya documentaba
207   `wasi-compiler-rt` para el caso wasm. El build instrumentado murió en el minuto 38:56 con
208   `ld.lld: cannot open …/libclang_rt.profile.a`. De ahí sale `recipes/compiler-rt-profile.toml`.
209
2102. **Los sandboxes de Firefox matan la corrida de perfilado.** Con ellos puestos los procesos hijo
211   mueren con **signal 11**, el que renderiza no llega a nacer, el servidor local registra **0 GET**
212   y el único `.profraw` que queda es el del padre arrancando — un perfil de nada, con todo en
213   verde. Es lo mismo que hace el `profileserver.py` de Mozilla. Sólo aplica a la corrida de
214   entrenamiento: el firefox que se distribuye lleva sus sandboxes intactos.
215
2163. **El worker no puede bajar del mirror de fuentes.** Tiene `scripts/fuentes/mirror-env.sh` desde
217   el 2026-09-01 pero no la clave del Storage Box, así que una receta pineada al mirror —y el perfil
218   es la primera— no se construye allá. Se sembró el artefacto sellado, que es content-addressed:
219   consigue lo mismo sin mover una credencial de máquina.
220
221**Cómo se verificó que el PGO llegó, y por qué NO como RLBox.** Con RLBox el artefacto delata la
222jaula (símbolos `w2c_*`, cero → 634). Acá el discriminante análogo serían las secciones
223`.text.hot`/`.text.unlikely` que clang emite al particionar por temperatura — y **no sirve**: con
224lld y ThinLTO el enlazador las fusiona, así que dan cero en el binario con PGO y sin él. La
225evidencia que sí vale está un nivel por debajo del `configure`: **189 invocaciones del compilador
226llevan `-fprofile-use`**, el configure encontró `llvm-profdata`, y no hay ni un aviso de perfil que
227no cuadre. `libxul.so` pasa de 226.078.752 a 227.802.816 bytes, consistente con inlining de caminos
228calientes. Es evidencia de build, no de artefacto, y conviene decirlo así.
229
230⚠⚠ **LEER PRIMERO: LOS PORCENTAJES DE LAS TRES TABLAS QUE SIGUEN ESTÁN DILUIDOS Y NO SON LO
231QUE PARECEN.** Miden el ciclo completo del proceso, del que **~16 s son arranque**. La corrección,
232con el control que faltaba, está más abajo en «EL CONTROL QUE FALTABA». Se dejan tal cual se
233publicaron, sin retocar, porque el error de método es el que enseña.
234
235**LA GANANCIA, MEDIDA (2026-09-07).** Mismo rootfs, mismo script, corridas INTERCALADAS A/B/A/B
236para que la deriva de carga afecte a las dos, mediana de 7, calentamiento descartado. Lo único que
237cambia entre variantes es un `--ro-bind` de `/usr/lib/firefox`.
238
239| página | sin PGO | con PGO | |
240|---|---|---|---|
241| DOM+layout+strings, **fuera** del corpus de entrenamiento | 23.540 ms | 21.327 ms | **−9,4 %** |
242| SunSpider `3d-raytrace`, **dentro** del corpus | 16.034 ms | 15.878 ms | −1,0 % |
243
244Los rangos no se solapan en ninguna de las dos (23.185–23.654 vs 21.030–21.650), así que las dos
245diferencias son reales y no ruido.
246
247⚠ **Y el resultado sale al revés de lo esperable, que es lo interesante.** La intuición dice que
248medir sobre el conjunto de ENTRENAMIENTO infla la ganancia; acá el corpus da el número MÁS BAJO. La
249razón es que `3d-raytrace` es aritmética pura en un bucle caliente, y ese bucle **no lo ejecuta el
250C++ de SpiderMonkey: lo ejecuta código máquina que el JIT genera en tiempo de ejecución**. El PGO
251optimiza el intérprete, el GC y el propio compilador JIT — no el código que el JIT emite. Un
252benchmark JIT-bound es casi ciego al PGO por construcción.
253
254Donde sí se ve es en el camino DOM/layout/arranque, que es C++ de principio a fin. Y eso es también
255lo que un usuario percibe: la medición cubre el ciclo COMPLETO del proceso (arrancar → renderizar →
256capturar → salir), no el rendimiento en régimen de una página ya cargada. De ahí que hasta la página
257de SunSpider tarde 16 s: casi todo es arranque.
258
259**Corolario para el corpus de entrenamiento — APLICADO Y MEDIDO (2026-09-08).** El corpus estaba
260sesgado hacia JS justo donde el PGO menos rinde, así que se le sumaron 10 páginas de maquetación
261propias (`scripts/pgo-corpus/`): flexbox, grid, tablas con los dos algoritmos de layout, texto en
262columnas, selectores contra 600 reglas, pintado, transforms, SVG, scroll pegajoso y layout
263thrashing. El perfil pasó de 5.885.254.799 ejecuciones registradas a **38.498.366.335 (6,5×)**.
264
265| | sin PGO | PGO v1 (36 pág.) | PGO v2 (46 pág.) |
266|---|---|---|---|
267| DOM/maquetación, fuera del corpus | 23.285 ms | 21.050 ms (−9,6 %) | **20.640 ms (−11,4 %)** |
268| SunSpider `3d-raytrace` | 16.003 ms | 15.846 ms (−1,0 %) | 15.857 ms (−0,9 %) |
269
270**La mejora en maquetación es real y no de medianas:** SEIS de las siete muestras de v1 son más
271lentas que TODAS las de v2; sólo una cae dentro del rango de v2. En SunSpider, en cambio, v1 y v2
272son **indistinguibles** —los valores se entrelazan por completo— que es justo lo esperable: ese
273camino lo ejecuta el JIT y el PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no
274alcanza.
275
276⚠ Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis: un atípico
277transitorio. **La mediana lo ignora por diseño**; una media lo habría convertido en «v2 es
278catastróficamente peor». Fue la razón de elegir mediana antes de ver un solo número.
279
280**EL JARLOG: PROBADO, MEDIDO, Y APARCADO PORQUE ROMPE `atuq` (2026-09-08).** Desde
281`d9833a58` el perfil trae también el `jarlog` y `firefox` lo consume con `--with-pgo-jarlog`. No
282hizo falta la extensión `Quitter` de Mozilla, que este documento daba por bloqueante: su
283`profileserver.py` sólo traduce `JARLOG_FILE` a `MOZ_JAR_LOG_FILE` en el entorno del navegador.
284
285| | sin PGO | v1 (36 pág.) | v2 (46 pág.) | v3 (= v2 + jarlog) |
286|---|---|---|---|---|
287| DOM/maquetación | 23.008 ms | 20.851 (−9,4 %) | 20.527 (−10,8 %) | 20.502 (−10,9 %) |
288| SunSpider | 16.006 ms | 15.859 (−0,9 %) | 15.869 (−0,9 %) | 15.838 (−1,0 %) |
289
290**El jarlog solo aporta −0,1 % y −0,2 %: indistinguible de cero.** Y el argumento no es que los
291rangos se solapen —que se solapan— sino que **la misma variante varía ~1 % entre corridas de días
292distintos** (v1 dio 20.851 hoy y 21.050 ayer). El suelo de ruido del banco es **diez veces** el
293efecto buscado.
294
295Eso NO es un fallo del jarlog: es que el banco corre con la **caché de página caliente**, y ahí
296reordenar `omni.ja` no ahorra ninguna lectura. Su terreno es el arranque EN FRÍO, que este
297instrumento no reproduce; medirlo pediría vaciar la caché entre corridas, que es una acción de
298sistema. **Lo que sí está probado es que la función existe**, y del lado del artefacto: `libxul` es
299IDÉNTICO byte a byte entre v2 y v3 y el `omni.ja` difiere en 26 bytes — el jarlog tocó exactamente
300lo que debía tocar y nada más. **Y sí costaba.** Al reconstruir `atuq` sobre ese firefox, murió:
301
302    zipfile.BadZipFile: Bad magic number for central directory   (rebrand.py)
303
304El jarlog convierte el `omni.ja` al **formato «jar optimizado» de Mozilla**, que mueve el directorio
305central al principio:
306
307    sin jarlog:  PK\003\004    ZIP estándar — `zipfile` lo abre, 5306 entradas
308    con jarlog:  \376\204#\0   `zipfile` lo rechaza
309
310Y `atuq` reempaqueta el `omni.ja` con `zipfile` para su branding. O sea que el jarlog **rompe el
311navegador propio de la distro**.
312
313**Aparcado, y la cuenta es asimétrica:** el coste está MEDIDO y el beneficio NO. Cambiar algo que
314funciona por una ganancia que no se pudo medir, rompiendo algo que sí funcionaba, es mal negocio.
315Se retoma cuando (1) se mida el arranque EN FRÍO, que es su terreno, y (2) `rebrand.py` sepa leer el
316jar optimizado o des-optimizarlo antes. El blob `92497cdd…` del mirror ya trae el jarlog, así que
317retomarlo es cambiar una línea y re-pinear el sha256 — no volver a perfilar.
318
319⚠ **Y la lección de método, que es la que más vale:** el jarlog parecía GRATIS. «Es lo que hace
320upstream y no cuesta nada» — lo escribí yo, en este documento, hace unas horas. El coste no apareció
321midiendo el jarlog sino **construyendo lo que dependía de él**. Una función que se declara gratuita
322sin haber reconstruido a sus consumidores no es gratuita: es no medida.
323
324⚠ **Dato que los datos delatan:** los dos valores atípicos del banco son 120.034 y 120.030 ms, o sea
325exactamente el `timeout 120` del arnés. No son ruido de carga: son corridas COLGADAS al arrancar en
326headless, 2 de 56 (~3,5 %). Sin perseguir, pero anotado.
327
328⚠ Y lo que este banco NO puede afirmar: las 10 páginas nuevas ejercitan los mismos subsistemas que
329la página de medición, así que el parentesco con lo que ahora se entrena es mayor que antes. El
330−11,4 % es real para ESTA carga; generalizarlo a «cualquier página» sería justo el error que el
331propio corpus de Mozilla cometía al revés.
332
333## EL CONTROL QUE FALTABA: el arranque eran 16 s, y sin restarlo ningún porcentaje significa nada (2026-09-08)
334
335Todo lo de arriba mide **el ciclo completo del proceso**: arrancar firefox, renderizar, capturar el
336PNG y salir. Nunca se midió cuánto de eso era la página. Faltaba el control más barato posible —una
337página VACÍA— y con él las cifras publicadas se leen distinto:
338
339| carga | total sin PGO | total con PGO | **trabajo** sin → con | mejora del TRABAJO |
340|---|---|---|---|---|
341| `vacia.html` (arranque puro) | 16.026 ms | 15.883 ms | — (ES la línea base) | **−0,9 %** |
342| DOM/maquetación | 23.307 ms | 20.627 ms | 7.281 → 4.744 ms | **−34,8 %** |
343| carga ajena (canvas/JSON/img) | 20.576 ms | 20.517 ms | 4.550 → 4.634 ms | **+1,8 % (nada)** |
344| SunSpider `3d-raytrace` | 15.992 ms | 15.877 ms | **−34 → −6 ms** | bajo el ruido |
345
346Las cuatro cargas y las dos variantes, **en una sola sesión intercalada**: restar el arranque de una
347corrida al total de otra no vale, porque la misma variante deriva ~1 % entre días.
348
349**Qué cambia, en concreto:**
350
3511. **El «−10,9 %» que publiqué es correcto como número y engañoso como afirmación.** Es real para el
352   ciclo completo, que es lo que un usuario espera al abrir el navegador. Pero se leía como
353   «firefox es un 11 % más rápido», y sobre el trabajo de la página la mejora es **−34,8 %**: el
354   PGO rinde TRES VECES más de lo que dije. El error subestimaba mi propio resultado.
355
3562. **La explicación que di del SunSpider era aire.** Escribí que el −1,0 % se explicaba porque un
357   benchmark JIT-bound es ciego al PGO. Mirá la fila: su trabajo mide **−34 ms**, negativo — la
358   página con el benchmark tardó MENOS que la vacía. `3d-raytrace` corre en decenas de ms y su
359   trabajo es más chico que la variación entre corridas. **Ahí no había nada que medir.** El −1,0 %
360   era el −0,9 % del arranque, y yo le colgué encima una teoría sobre el JIT.
361
362   La teoría puede ser cierta —el mecanismo es real y está bien descrito— pero **esta medición nunca
363   la probó**, y la presenté como si sí. Un número real más un mecanismo real no hacen una
364   explicación: hace falta que el número mida el mecanismo.
365
3663. **La carga ajena confirma que el PGO no es magia.** +1,8 % sobre su trabajo, o sea cero: mejora
367   lo que se le entrenó (maquetación, −34,8 %) y no lo que no (canvas/JSON, 0 %). Eso es exactamente
368   lo que un PGO honesto debe hacer, y es mejor evidencia de que funciona que el número grande.
369
3704. **El jarlog no se rehabilita.** Su −0,1 % diluido pasa a ~−0,5 % sin diluir; sigue muy por debajo
371   del ~1 % que la misma variante deriva entre días. La conclusión de aparcarlo no se mueve.
372
373⚠ **La lección, que es la misma de toda esta jornada con otro disfraz.** El instrumento funcionaba,
374las medianas eran correctas, las corridas estaban intercaladas, los rangos no se solapaban — todo el
375rigor estadístico estaba puesto **sobre una cantidad que no era la que yo creía estar midiendo**.
376Ninguna cantidad de repeticiones lo habría revelado: sólo lo revela un control, y el control costó
377siete corridas de una página vacía. **Antes de refinar la precisión de un número, hay que gastar una
378medición en averiguar qué mide.**
379
380Y el detalle que lo vuelve barato de recordar: el control salió NEGATIVO en una fila. Un valor
381imposible es la forma más limpia que tiene una medición de avisar que el modelo está mal, y por eso
382esa fila se deja publicada con su signo menos en lugar de redondearla a cero.
383
384**Y la pregunta que un insumo no determinista obliga a hacer, respondida: `firefox` SIGUE
385REPRODUCIENDO bit a bit** (`verificar-repro.sh`: REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0). Era el
386riesgo real de esta unidad, no el rendimiento: si el `-fprofile-use` hubiera metido cualquier
387decisión dependiente del orden o del timing, habríamos cambiado velocidad por el invariante del
388proyecto. Congelar el perfil como fuente pineada era el argumento; esto es la medición.
389
390### 3.quater La cadena wasm, y las tres cosas que costó (2026-09-06)
391
392`--without-wasm-sandboxed-libraries` se cambió por `--with-wasi-sysroot=/usr/share/wasi-sysroot`,
393que es literalmente el flag de Alpine. Detrás hay cinco recetas nuestras, en este orden obligatorio:
394
395```
396wasi-libc-headers → wasi-compiler-rt → wasi-libc → wasi-libcxx → wasi-sdk → firefox
397```
398
399`wasi-libc-headers` existe **sólo** para romper el ciclo del bootstrap y pinea un commit VIEJO a
400propósito (triple `wasm32-wasi`), mientras `wasi-libc` pinea el nuevo (`wasm32-wasip1`, el que
401clang 22.1 usa de verdad). Es lo mismo que hace Alpine y no es un descuido.
402
403**Lo que costó, que es la parte reusable:**
404
4051. **`check-symbols` falla por sesgo de clang, no por un artefacto malo.** El lab trae clang 22.1.8
406   y el snapshot del árbol viene de uno anterior: sobra `#define __wasip1__ 1` y nada más. Se
407   reconcilia el snapshot; **no** se salta con `make no-check-symbols`, que se lleva por delante la
408   comparación de símbolos —la mitad que sí vale y que pasaba byte a byte.
409
4102. **Faltaba `wasi-libcxx`, y el hueco era visible en el grafo sin construir nada.** El configure
411   murió a los 6 s con `'cstring' file not found`, culpando a los headers de WASI, que estaban
412   perfectos: `<cstring>` es C++ y las librerías enjauladas no son todas C. El `wasi-sdk` de Alpine
413   declara `wasi-libc wasi-libcxx wasi-compiler-rt` —TRES— y la cadena tenía dos. **El `depends`
414   del paquete ajeno equivalente es una comprobación de completitud gratis**, antes de gastar CPU.
415
4163. **Un directorio VACÍO que sí importa.** Con `wasi-libcxx` sellado el configure volvió a morir
417   igual, y `cstring` estaba en el artefacto: clang no lo buscaba. Falta el `mkdir -p
418   include/c++/v1` que Alpine tiene en su `package()` y que parece ruido de empaquetado — es la
419   sonda por la que el driver decide que el sysroot tiene layout de libc++. Medido dentro del lab:
420   sin ese directorio, `'cstring' file not found`; con él, exit 0. Es el **reverso exacto de la
421   regla 3 del `CLAUDE.md`**: allá un directorio vacío es un artefacto mentiroso, acá es una
422   declaración dirigida al compilador.
423
424De ahí sale el criterio de guardián que ahora usan estas recetas: **«existe» no es «se encuentra»**.
425`wasi-libcxx` corre hoy la misma prueba que hace el configure de firefox, contra un sysroot
426fusionado con el de su dep, así que un fallo aparece en el segundo 20 de una receta chica —con la
427lista de búsqueda de clang impresa— y no en el segundo 6 de un build de cuatro horas que además
428culpa a otro. Y `firefox` exige RLBox **en el binario**: sobre `b3:352d7880` (el último con RLBox
429apagado) los patrones `w2c_`, `rlbox` y `wasm2c` dan cero los tres en `libxul.so`, así que
430cualquiera apareciendo prueba que la jaula entró. Es la tercera repetición de la lección de
431`MOZ_REQUIRE_SIGNING` y `MOZ_BUILD_DATE`: una bandera que el configure acepta y el artefacto ignora.
432
433**Evidencia de reproducibilidad cruzada (2026-09-06).** Las cinco recetas se construyeron por
434separado en las DOS máquinas —el hub (gioser, 4c) y el worker (`dev.gioser.net`, LXC 6c)— y los
435cinco artefactos salen **byte a byte idénticos**, comparando el árbol completo de cada uno:
436
437| receta | sha256 del árbol | |
438|---|---|---|
439| `wasi-libc-headers` | `0d34f9cb27530606…` | ✓ |
440| `wasi-compiler-rt` | `0c4fc6fdf08ef908…` | ✓ |
441| `wasi-libc` | `c13acdf896f2b78c…` | ✓ |
442| `wasi-libcxx` | `b1d9aeec08499063…` | ✓ |
443| `wasi-sdk` | `b49f7a74a5caed3f…` | ✓ |
444
445No es un trámite: **el lab NO entra en `hash_inputs`**, así que dos labs distintos pueden sellar
446bytes distintos en la misma dirección del store y nada lo detecta. Esto dice que para esta cadena
447los dos labs coinciden de verdad, y no sólo que coinciden los `ArtifactHash`.
448
449## 4. Lo que `atuq` NO promete
450
451Esta sección existe antes que la lista de features a propósito, con el mismo criterio que el modelo
452de adversario de `qullqa`: **lo que no se promete se escribe primero, porque una promesa falsa de
453privacidad es peor que no ofrecer nada.**
454
455**`atuq` no es Tor Browser y no va a tener «modo Tor».** Tor Browser no es «Firefox + SOCKS»: su
456valor son las contramedidas de huella (RFP, letterboxing, normalización de fuentes/canvas/timers) y
457sobre todo **un conjunto de anonimato donde todos se ven idénticos**. `atuq` es, por construcción, un
458binario único en el mundo: musl, Wayland-only, branding propio, extensiones propias. Alguien saliendo
459por Tor desde `atuq` es **más** identificable, no menos, y su conjunto de anonimato son diez
460personas. Para anonimato: Tor Browser, y lo decimos nosotros primero.
461
462Lo que sí se ofrece, y es honesto porque es otra cosa: **proxy por contenedor** (§6.8) — separación
463de tráfico, no anonimato.
464
465**`atuq` tampoco promete** anti-fingerprinting propio (es un programa de investigación con equipo
466full-time) ni bloqueo de anuncios propio (se shipea uBO y listo).
467
468## 5. Contexto verificado al escribir (2026-09-05)
469
470De `docs/state/build-state.json`, no de memoria:
471
472| Dato | Valor |
473|---|---|
474| Recetas / nodos | 838 / 840 |
475| Selladas | 837 |
476| `firefox` 154.0 | **sealed**, cola `corpus` |
477| `waterfox` 6.7.1.1 | **never** — primer build en curso |
478| Plataforma compartida | `gtk3`, `atk`, `nodejs`, `clang18`, `cbindgen`: todas sealed |
479
480**`atuq` no arranca hasta que `waterfox` selle.** Waterfox es la prueba de la tesis del reúso —«las
481diferencias reales con `firefox.toml` son TRES: la fuente, el branding y la versión»—. Si esa tesis
482falla, el precio de todo este documento cambia y hay que releerlo.
483
484## 6. Los diferenciadores, priorizados
485
486La columna «quién más lo tiene» es lo que evita que nos contemos un cuento.
487
488| # | Qué | Quién más lo tiene | Pieza que ya existe | Costo |
489|---|---|---|---|---|
490| 6.1 | **`sct` — transparencia de scripts** | **nadie** | `puriy-sct`, `puriy-sct-testigo` | medio |
491| 6.2 | **Descargas direccionadas por contenido** | nadie | store CAS de takana, `tejido` | bajo |
492| 6.3 | **Archivo personal + RAG local** | Rewind/Recall (nube, Windows); SingleFile (guarda, no busca) | `khipu`, `rag-motor`, `willay-rag` | medio |
493| 6.4 | **Historial y perfil sobre `qullqa`** | nadie | `qullqa-core`, `qullqa-pozo` | medio |
494| 6.5 | **Foco por `cortafuegos`, no por extensión** | nadie (nadie es dueño del navegador *y* del sistema) | `cortafuegos`, `pacha` | bajo |
495| 6.6 | **Medios por fuera del navegador** | extensiones sueltas; de fábrica no | `foreign-ytdlp`, `-platform`, `-dlna` | bajo |
496| 6.7 | **IA local en la barra lateral** | Chrome/Edge son nube; Zen no tiene | `rimay`, `iniy` | bajo |
497| 6.8 | **Proxy por contenedor** ✅ **v0.5** | nadie de fábrica | — (API de Firefox) | bajo |
498| 6.9 | **Torrent adentro** | **Vivaldi lo trae; Brave tuvo WebTorrent** | `shared/foreign-torrent` (SDD propio, sobre librqbit) | bajo |
499
500### 6.1 `sct` es la joya
501
502BLAKE3 a todo lo que se ejecuta, y **negarse a correr código que ningún testigo vio nunca**. Es lo
503más cerca que hay de «Certificate Transparency, pero para el JavaScript que te corre en la cara», y
504no lo tiene nadie: ni Zen, ni Brave, ni Tor Browser.
505
506En tawasuyu ya está escrito y —dice su README— la lógica es **agnóstica del transporte** y está
507certificada sin red; `puriy-sct-testigo` es sólo el cable HTTP.
508
509- **v1 — HECHA 2026-09-10, y con una corrección de este propio párrafo.** La extensión intercepta el
510  cuerpo de cada `<script src>` con `filterResponseData` y se lo pasa al **host** (§7), que hashea y
511  decide. Decía «consulta al testigo antes de dejarla pasar», y las dos mitades había que ajustarlas:
512  el cable del testigo es un POST con **postcard**, así que un JS no puede ser su cliente (§7.quater);
513  y v1 **observa y avisa, no bloquea** — que es lo que `puriy-sct` dice de su propia v1, y además
514  bloquear cada script contra un viaje entre procesos no es «más seguro», es un navegador que nadie
515  usa. Medida de punta a punta por `scripts/test-atuq-sct.py`, con servidor HTTP real, seis cargas de
516  página y dos controles.
517- **v2, forma fuerte:** gancho en el script loader de Gecko. Eso sí es parche de árbol ⇒ §2.bis ⇒
518  después de la toolchain del §3. Es también lo único que ve los scripts **inline** —
519  `filterResponseData` entrega el cuerpo de una PETICIÓN, y un inline viaja dentro del HTML— y lo único
520  que puede negarse a ejecutar.
521
522#### 6.1.bis Lo que costó armarla, que es lo que no se puede deducir (2026-09-10)
523
524Cinco cosas se midieron en vez de suponerse, y cada una tenía su forma de fallar en silencio:
525
526| Qué | Cómo falla si se supone mal |
527|---|---|
528| El manifiesto va en `/usr/lib/mozilla/native-messaging-hosts/`, no en el appdir (`XRESysNativeManifests` es un `/usr/lib/mozilla` **compilado**) | el puerto se cierra «sin error y sin mensaje» |
529| **El manifiesto NO puede llevar argumentos** — `NativeMessaging.sys.mjs`: `command = manifest.path`, y los únicos argumentos son `[ruta-del-manifiesto, id]` | `puriy-costura` sin `--state` corre en memoria ⇒ cada arranque vuelve a «aprendiendo» y **nada alerta nunca**: la función existe, no falla, y no protege |
530| `filterResponseData` + el permiso `webRequestFilterResponse` **están** en nuestro `omni.ja` | se habría escrito la extensión contra una API que el build no tiene |
531| Los `inline` no se ven por esta vía | se habría prometido cobertura total teniendo la mitad |
532| **Una carga puede producir dos peticiones del mismo documento, y una llega con `tabId = -1`** | agrupando por `(tabId, documento)` esa carga contaba **dos visitas** |
533
534La última es la que más importa y la que menos se veía. Con las visitas infladas, un origen **se
535estabiliza antes de conocer su código real**, y entonces alerta por churn legítimo: el falso positivo
536que la spec de `puriy-sct` pide evitar por encima de todo. Se agrupa por documento —lo que hace que dos
537pestañas con la misma url cuenten UNA, que es el error seguro: tarda más en proteger, no alerta de
538más— y el guardián vigila el invariante «una carga, una visita», así que si vuelve, falla ruidoso.
539
540**Y el aviso se mide, no se supone.** La extensión relee la insignia con `getBadgeText` después de
541ponerla y lo dice, así que el guardián exige insignia vacía en las cinco cargas sin novedad y `"1"` en
542la del script cambiado. Es la única parte de toda la cadena que el usuario llega a ver: dejarla como
543«se llamó a la API» sería dejar sin medir justo el final.
544
545**Dos límites escritos donde no se pueden no leer** (el propio `fondo.js`, el `lib.rs` del host y los
546dos LEEME): se hashea el TEXTO ya decodificado, que vale para comparar dos cargas nuestras y **no** es
547comparable con el hash de los bytes servidos que publique un tercero; y el aviso es pasivo (insignia,
548no modal) porque un modal por despliegue entrena a cerrarlo sin leer.
549
550### 6.2 Una descarga con identidad
551
552Lo bajado no es un archivo en `~/Downloads`: es un objeto BLAKE3 en el store — deduplicado,
553verificable, y re-compartible por `tejido`. El torrent (6.9) alimenta lo mismo. **Ningún navegador
554trata una descarga como algo con identidad**; para todos es un blob con nombre, y por eso lo bajás
555dos veces y no lo sabés.
556
557Ésa, y no «tener torrent», es la razón por la que 6.9 vale: Vivaldi ya tiene torrent, pero termina en
558una carpeta.
559
560### 6.3 El archivo personal es la razón por la que alguien usaría `atuq`
561
562Cada página visitada se congela en el CAS y entra al DAG de `khipu`; después le preguntás a tu
563propio historial en lenguaje natural, **todo local**. Es la feature que más justifica el proyecto
564entero, y sale de piezas que ya están escritas.
565
566### 6.4 `qullqa` con su advertencia puesta
567
568Almacenamiento con negación plausible y modelo de adversario **escrito** — ningún navegador tiene
569eso; el modo incógnito es teatro. ⚠ Con la advertencia que el propio SDD de `qullqa` ya anotó y que
570**hay que repetir acá, no esconder**: en una máquina con swap sin cifrar, el documento no aplica.
571Se promete lo que se puede probar.
572
573### 6.8 Proxy por contenedor — HECHO (v0.5, 2026-09-06)
574
575**Es el primer diferenciador del §6 que se paga entero**, y se pudo pagar ahora porque es el único
576de la lista que no pasa por el host del §7: es API de Firefox y nada más. Cada contenedor
577—Personal, Trabajo, Banco, Compras— puede salir por su propio proxy.
578
579Tres piezas, en tres ficheros, y **ninguna alcanza sola**:
580
581| Pieza | Dónde | Qué aporta |
582|---|---|---|
583| `privacy.userContext.enabled` | `atuq.cfg` | prende los contenedores, que Firefox trae apagados |
584| `Containers.Default` | `distribution/policies.json` | los CREA — es el único mecanismo que los pone en un perfil NUEVO |
585| `3rdparty.Extensions` | `distribution/policies.json` | la config de fábrica, que la extensión lee como `storage.managed` |
586| `proxy.onRequest` | `extensions/proxy/fondo.js` | lo único que ve el `cookieStoreId` de cada petición |
587
588**Las cuatro se comprobaron DENTRO del artefacto antes de escribir una línea**, que es la regla que
589dejó el §2.sexies: `Containers` y `3rdparty` están en el `policies-schema.json` de `browser/omni.ja`,
590`cookieStoreId` en el `schemas/proxy.json` de `omni.ja`, y `storage.managed` lee
591`Services.policies.getExtensionPolicy(id)` en `ext-storage.js`. Ninguna de las cuatro se leyó de la
592documentación de Mozilla: se leyeron de **nuestro** build, que es el que las tiene que traer.
593
594**Tres decisiones de diseño que valen más que el código:**
595
5961. **La configuración se indexa por NOMBRE de contenedor, no por `cookieStoreId`.** El id
597   (`firefox-container-3`) depende del ORDEN en que se crearon, así que la misma configuración
598   aplicada a otro perfil apuntaría a otro contenedor. Un identificador que cambia de significado
599   entre máquinas no sirve para configurar una distro.
6002. **Fail closed.** Un contenedor que TIENE proxy configurado y no se pudo honrar —entrada
601   inválida, API que falla, mapa a medio construir— **no sale directo**: va a un destino cerrado y
602   el navegador muestra el error. Salir directo sería una fuga silenciosa, y es la misma familia
603   que el artefacto vacío de la regla 3: el fallo que llega hasta el final diciendo que todo fue
604   bien. Un usuario que pidió que «Banco» no salga por su línea tiene que ver un error, no navegar.
6053. **`proxyDNS` viene PRENDIDO.** Sin él, Gecko resuelve el nombre por su cuenta antes de hablar
606   con el proxy: la consulta DNS sale justo por la línea que se quería evitar. Es la fuga clásica de
607   esta configuración, así que el default es el seguro y hay que apagarlo a mano.
608
609**Y lo que NO promete está en la propia página de opciones, arriba de todo y no en un pie**:
610separación de tráfico, no anonimato; no toca la huella del navegador; para anonimato, Tor Browser.
611Es el §4 cumplido en el sitio donde el usuario lo va a leer.
612
613#### Lo que quedó PROBADO, y con qué
614
615Corriendo el árbol de atuq en la misma jaula que usa `scripts/atuq-nested.sh`:
616
617| Afirmación | Prueba |
618|---|---|
619| La política CREA los cuatro contenedores | captura de `about:preferences#containers` con Personal/Trabajo/Banco/Compras y sus iconos, más el `containers.json` del perfil |
620| Las dos extensiones se INSTALAN | `extensions.json` del perfil nombra `inicio@atuq.tawasuyu` y `proxy@atuq.tawasuyu` |
621| El ruteo se arma contra los contenedores reales | `console.info: "atuq/proxy: 4 contenedor(es) enrutado(s)"` — o sea que leyó la config de fábrica por `storage.managed` Y la casó con los contenedores que creó la política |
622| **Una petición hecha en «Banco» SALE por el proxy de «Banco»** | `scripts/test-atuq-ruteo.py`: dos pestañas piden la misma url; al destino llega `GET /directo` y al puerto del proxy un saludo **SOCKS5 (`\x05\x01\x00`)**, y la de «Banco» no aparece nunca en el destino. Con `--negative-control` (sin proxy configurado) las dos van directas y al proxy no llama nadie |
623| Los guardianes del cruce política↔XPI FALLAN cuando deben | `scripts/test-atuq-politica.py`: 5 formas de romperlo, las 5 matan el build, y el control con la política intacta pasa |
624| La capa sobrevive al cambio de BASE | rehecho sobre el `firefox` con RLBox (`b3:8116bdec`, 2026-09-06): `atuq` sella en 2 s como `b3:f2960991`, su `libxul.so` trae **634 símbolos que se LLAMAN `w2c_*`** donde la base anterior traía 0, y los cuatro contenedores y las dos extensiones siguen apareciendo en un arranque real |
625
626⚠ **Ese 634 hay que contarlo anclado, y la primera vez se contó mal.** `llvm-nm --defined-only \| grep -c w2c_` da **1547** sobre el mismo fichero, y los 913 de más son nombres C++ mangleados que contienen `w2c_` en el MEDIO (`_ZN5rlbox...PK16w2c_mem_capacity...`), no símbolos de la jaula. El patrón que cuenta lo que dice contar es `grep -c ' w2c_'` —o el equivalente `awk '{print $3}' \| grep -c '^w2c_'`—, y da 634, que es lo que mide el guardián de `recipes/firefox.toml`. La conclusión no cambia (la base anterior daba **0** con cualquiera de los dos patrones); lo que cambia es que un número sin su patrón no es una medición. Muestra de lo que sí es un símbolo de la jaula: `w2c_rlbox_0x5F_cxa_atexit_0`.
627
628**Y de paso quedó comprobado que la dep SÍ se sigue**, que era la promesa del §2 y no una que convenga
629creer sin medir: en un catálogo de sonda, cambiar una bandera del `firefox` copiado mueve el hash de
630`atuq` (`f2960991` → `60ade76a`), mientras que con el `firefox` idéntico al del corpus da el mismo
631hash. O sea que un `atuq` viejo **no** puede quedarse tapando un motor nuevo — que es justo la forma
632que tendría acá el cache-hit que congela regresiones.
633
634**Cómo se cerró lo que faltaba (2026-09-06).** Durante unas horas esta sección decía que probar el
635paquete quedaba pendiente, con tres puertas cerradas. Las tres siguen cerradas y la prueba existe
636igual, porque el camino era otro.
637
638Las tres puertas, que conviene NO volver a golpear:
639
6401. **Desde la línea de comandos no hay flag** para el `userContextId` de la pestaña inicial. Y un
641   `moz-extension://` tampoco se abre así: el manejador intenta resolverlo como fichero y muere con
642   `NS_NOINTERFACE [nsIFileURL.file]`, abriendo la home en su lugar.
6432. **Marionette está en el artefacto y responde** —se le habló con un cliente propio de 60 líneas,
644   el protocolo es `<longitud>:<json>`—, pero abrir una pestaña de contenedor pide contexto chrome,
645   y eso exige `-remote-allow-system-access`; en la jaula no lo tomó ni por bandera, ni con
646   `--remote-debugging-port`, ni por `MOZ_REMOTE_ALLOW_SYSTEM_ACCESS=1`, que es lo que
647   `RemoteAgent.sys.mjs` lee en su constructor. Cabo suelto medido, no suposición.
6483. **Desde la extensión, `tabs.create({cookieStoreId})` exige el permiso `cookies`**
649   (`ext-tabs-base.js:getUserContextIdForCookieStoreId`). Dárselo a la extensión del proxy para que
650   pueda probarse a sí misma sería pagar con la superficie de ataque del producto una comodidad del
651   test. Sigue sin dárselo.
652
653**La cuarta puerta estaba abierta: el fichero de sesión.** `sessionstore` guarda el `userContextId`
654de cada pestaña y Gecko lo restaura, así que se fabrica a mano. El formato es `mozLz40\0` + tamaño +
655un bloque LZ4, y **un bloque de sólo literales es LZ4 válido**: veinte líneas, sin depender de
656ninguna librería. Con eso se abren dos pestañas —misma url, distinto contenedor— sin pedirle nada al
657navegador.
658
659Y la medición no le pregunta nada tampoco: **se le ponen dos oídos en la red y se mira a cuál llama.**
660El destino contesta un HTTP 200; el «proxy» no habla SOCKS, sólo anota quién lo saludó. Que al
661puerto del proxy llegue un `\x05\x01\x00` es la prueba: ese saludo sólo aparece si Gecko decidió
662hablar con un proxy para esa petición, y el único que se lo pudo indicar es nuestro
663`proxy.onRequest` mirando el `cookieStoreId`.
664
665Tres detalles sin los cuales la prueba mide un silencio y se lee como un fallo:
666`browser.sessionstore.restore_on_demand=false` (si no, las pestañas restauradas no piden nada hasta
667que alguien las mira), `network.proxy.allow_hijacking_localhost=true` (Gecko saltea el proxy para
668localhost, y la petición de «Banco» iría directa haciendo parecer culpable a la extensión), y
669`triggeringPrincipal_base64: vQ==` en cada entrada de sesión (sin principal la pestaña se restaura
670pero no navega).
671
672**Y la prueba trae su propio control negativo**, porque es lo que este repo se exige desde hoy: con
673`--negative-control` no se configura el proxy y se exige el resultado CONTRARIO —las dos pestañas
674directas, nadie llamando al proxy—. La única diferencia entre las dos corridas es una línea de
675configuración y el observable se da vuelta entero. Sin ese modo, una prueba que se hubiera vuelto
676ciega se vería idéntica a una que funciona.
677
678### 6.10 Lo que `atuq` NO PUEDE hacer hoy, y por qué (2026-09-07)
679
680Sale de un punto ciego que nombramos entre los dos frentes y que **ningún auditor de `readelf`
681puede cubrir**. La jerarquía de lo que se ve:
682
683    NEEDED del ejecutable          → lo ve `test-atuq-rootfs.py` y lo ve `vigia-sonames.py`
684    NEEDED de un .so dlopeado      → lo ven los dos, si el fichero está en el artefacto
685    dlopen("libfoo.so.1") LITERAL  → NO LO VE NINGUNO
686
687Y un navegador vive del tercer escalón: Firefox sondea ffmpeg, VA-API, vulkan, libnotify y una
688docena más **por nombre**, y cuando no están **no falla: apaga la función y sigue**. No hay línea
689roja; hay una función que nadie ofrece y nadie reclama. Es la misma forma que ya nos costó caro con
690OBS (`dlopen("libGL.so.1")` desde su glad).
691
692`scripts/test-atuq-rootfs.py --dlopen` busca esas cadenas y las cruza contra el rootfs. **Es un
693heurístico y se declara como tal** —una cadena no prueba un `dlopen`, y su ausencia no prueba que no
694lo haya—, así que no falla nunca: imprime un mapa triado. Lo que sí se puede afirmar es lo
695contrario, que es lo útil: **si la cadena está y el fichero no, esa función no existe en esta
696imagen.**
697
698De 85 cadenas con forma de soname, **47 no tenían quién las provea**. Triadas (y con dos filas
699corregidas el mismo día — ver §6.11, que las midió en vez de deducirlas; hoy el mapa da **7 huecos**):
700
701| Qué se pierde | Estado |
702|---|---|
703| **Códecs del sistema (H.264/AAC)** | ❌ **ERA FALSO** — `recipes/ffmpeg.toml` existe, está sellada y ya viajaba en los cuatro escritorios por `mpv`. Corregido en §6.11: **reproduce** |
704| **Notificaciones web** (`libnotify`) | ✅ **CERRADO el 2026-09-07**: `recipes/libnotify.toml`, 0.8.8, compartida. Es el primer hueco que este mapa encontró Y cerró |
705| **Llavero** (`libsecret`) | hueco — pero **la receta ya existe** en `incoming-gnome` |
706| **Sonidos del sistema** (`libcanberra`) | hueco — receta en `incoming-kde` |
707| **WebGPU / vulkan** (`libvulkan`) | hueco — receta `vulkan-loader` en `incoming-kde` |
708| **Vídeo por hardware** (VA-API) | hueco, pero **no por falta de receta**: `libva` está sellada y en las cuatro imágenes. Falta el driver — las tres mesa van con `-Dgallium-va=disabled` y `-Dvideo-codecs=` vacío ⇒ ni un `*_drv_video.so` |
709| **Lectura en voz alta** (`libspeechd`) | hueco — sin receta |
710| `libGL` | **decisión**: la distro es Wayland-only sin GLX y Firefox va por EGL |
711| `libcurl` | **decisión**: sólo lo usa `pingsender`, que manda telemetría — apagada |
712| Kerberos, menú global, ML | fuera de alcance |
713| `libdl/libpthread/librt/libudev.so.0/libfreebl3` | ruido: musl los funde, o el soname es viejo |
714
715**El primero ya está cerrado.** `libnotify` no tenía receta y ahora la tiene: es la prueba de que el
716mapa sirve para algo más que mirarlo. ⚠ Con una advertencia que va escrita en la propia receta:
717`libnotify` no trae un daemon, manda `org.freedesktop.Notifications` por D-Bus ⇒ tenerla resuelve la
718mitad —que firefox la encuentre— y la otra mitad es que en la imagen haya alguien escuchando ese
719nombre. Nadie debería leer «notificaciones arregladas» y esperar un globo en un QEMU pelado.
720
721**⚠ CORRECCIÓN, mismo día: escribí que tres de los siete eran «baratos, promoción y no autoría»
722—`libsecret`, `libcanberra`, `vulkan-loader`— y es FALSO.** Lo comprobé antes de declararlos en los
723perfiles, y en los tres casos falta la otra mitad:
724
725| «barata» | por qué NO alcanza con declararla |
726|---|---|
727| `vulkan-loader` | **las tres recetas de mesa construyen con `-Dvulkan-drivers=` VACÍO** ⇒ el loader no encontraría un solo dispositivo. Un cargador sin ICD no es WebGPU |
728| `libsecret` | no hay receta de `gnome-keyring` ni de ningún servicio de secretos: firefox hablaría a `org.freedesktop.secrets` y no habría nadie |
729| `libcanberra` | no hay receta de `sound-theme-freedesktop`: la librería carga y no suena nada |
730
731Declararlas habría subido el número de paquetes de la imagen sin encender una sola función. **Una
732librería es media función; la otra mitad es quien la atiende**, y eso vale para todas las de esta
733tabla. Quedan como huecos, no como promociones pendientes.
734
735⚠ **Y esta frase también se cayó el mismo día.** Decía que de los otros cuatro «el más caro para el
736usuario es `ffmpeg`: sin él, un sitio que sirva H.264 no reproduce» — con lo cual el hueco más caro
737del mapa **no existía**. Ver §6.11: la receta estaba, faltaba declararla en el runner, y H.264 (y
738AAC, VP9, Opus, AV1, MP3, FLAC) reproducen. De los cuatro «sin receta» quedan tres, y ninguno es un
739códec: lectura en voz alta (`libspeechd`), el driver de VA-API, y `libpci` —que sólo lo usa
740`glxtest`, o sea irrelevante sin GLX.
741
742**Y la misma vara aplicada a `libnotify`, que sí se declaró:** su otra mitad es un daemon que
743escuche `org.freedesktop.Notifications`. Medido perfil por perfil:
744
745    escritorio-kde      plasma-workspace        ✓ completa
746    escritorio-gnome    gnome-shell             ✓ completa
747    escritorio-cosmic   cosmic-notifications    ✓ completa
748    escritorio-sway     dunst 1.12.2            ✓ completa — CERRADA el 2026-09-07
749
750La de sway se cerró el mismo día con `recipes/incoming-wlr/dunst.toml`, y la trampa del homónimo
751—**el nombre `mako` YA ESTÁ OCUPADO en el corpus** por el motor de plantillas de Python de Mesa— se
752esquivó eligiendo dunst, que además habla D-Bus por GDBus y no por `sd-bus`, o sea sin receta nueva
753de `basu`. La prueba no es que selle: `scripts/wlr/dunst-headless.sh` levanta sway headless y un bus
754de sesión, manda un `notify-send` y **deja que el bus active el daemon solo** —el mismo camino que
755recorre una página web en `atuq`—, y mide un diff de píxeles antes/después: 14.832 cambiados con el
756`.service` puesto, 0 sin él. Evidencia en `docs/evidencia/dunst-sway-notificacion-2026-09-07.png`.
757
758Y la cadena se cerró hasta el final, que es donde vive la promesa: con `--via-atuq` el emisor no es
759`notify-send` sino **una página web dentro del navegador**. Ahí se ejercitan las cinco piezas —
760`new Notification(...)` → `libxul` haciendo `dlopen("libnotify.so.4")` (que no es NEEDED de ningún
761ELF, o sea invisible para cualquier auditor) → D-Bus → activación → dunst dibujando—, y el veredicto
762es el `onshow` del motor, no el diff de píxeles: con el `.service` puesto llega a `MOSTRADA #33`, sin
763él el motor dice `ERROR al mostrar` y no se dibuja nada. Evidencia en
764`docs/evidencia/atuq-notificacion-web-sway-2026-09-07.png`.
765
766Vale la pena decir qué prueba eso de más: que en el proceso de `atuq` **la GLib no se duplica**. El
767navegador usa la cadena `-shared` (la que arrastra su GTK3) y `libnotify.so.4` enlaza esa misma, así
768que el `dlopen` no repite GObject. El que sí lo repetía era `dunstify`, y por eso no se shipea.
769
770⚠ De paso apareció otra media función, y ésta toca a `libnotify` directamente: **`dunstify`
771segfaultea hasta en `--help`** porque mezcla la GLib ESTÁTICA del corpus con la COMPARTIDA que
772arrastra `libnotify.so.4` — dos copias de GObject en un proceso. No se shipea; el emisor es
773`notify-send`, que viene dentro del artefacto de libnotify y enlaza toda la cadena compartida. Vale
774como recordatorio de que en este corpus **quién enlaza qué GLib es parte del contrato**, no un
775detalle del build.
776
777**Lo que esta sección cambia de fondo:** hasta hoy la pregunta era «¿arranca?», y la respuesta era
778sí. La pregunta que faltaba era «¿y qué NO puede hacer?», que ninguna métrica del repo respondía
779porque todas miran presencia y ésta mira ausencia declarada por el propio binario.
780
781### 6.11 Y ahora la pregunta que faltaba: ¿REPRODUCE? (2026-09-07)
782
783El §6.10 preguntó «¿qué NO puede hacer?» y contestó leyendo cadenas. Media pregunta. La otra mitad
784—**¿se ve el vídeo?**— no la contesta ningún auditor de ELF, y al hacerla aparecieron **dos errores
785del mapa y un bug real del navegador**.
786
787**Error 1: «no hay receta de ffmpeg».** La hay. `recipes/ffmpeg.toml`, 7.1, sellada, publica
788`libavcodec.so.61` —uno de los once sonames que `libxul.so` sondea por `dlopen` literal— y **ya
789viajaba en la clausura de los cuatro escritorios**, arrastrada por `mpv`. Comprobado con
790`yupana.membresia`, que es la vista honesta por par `(cola, nombre)`, no leyendo el TOML:
791
792    escritorio-kde 308 nodos · escritorio-gnome 192 · escritorio-sway 203 · escritorio-cosmic 163
793    ffmpeg ✓ en los cuatro · libva ✓ en los cuatro
794
795Lo que faltaba no era la receta: era **la lista de raíces de `scripts/atuq-nested.sh`**, escrita a
796mano, que hidrataba un rootfs más pobre que la imagen. Otra vez el instrumento y no el artefacto —
797la misma forma que `gcc-libs` el día anterior. Y la comprobación previa que sí se pudo hacer sin
798correr nada: de los 82 símbolos con forma `av*_` que `libxul` dlsimboliza, **los 9 que nuestro
799`libavcodec` no exporta son los de la API vieja** (`avcodec_decode_video2`, `av_lockmgr_register`,
800`avcodec_register_all`…), que Firefox sólo pide para las versiones 53-57.
801
802**Error 2: «VA-API, sin receta».** También la hay, y también está en las cuatro imágenes. El hueco
803es real pero por la OTRA mitad: las tres recetas de mesa construyen con `-Dgallium-va=disabled` y
804`-Dvideo-codecs=` vacío ⇒ **no existe un solo `*_drv_video.so`**. Un cargador sin ICD no acelera
805nada, exactamente como `vulkan-loader`. ⚠ Y con una trampa nueva: ahora que `libva` está en el
806rootfs, **el mapa de `--dlopen` ya no la reporta**, porque mide presencia de fichero. La librería
807presente SILENCIA el aviso sin encender la función. Queda escrito acá porque el guardián ya no
808puede decirlo.
809
810**El bug real: AV1 no reproducía.** Gecko **se come el primer elemento de `LD_LIBRARY_PATH`** al
811lanzar el proceso RDD, el que decodifica vídeo. El lanzador ponía `/usr/lib/atuq` una sola vez —o
812sea, primero—, así que el RDD arrancaba sin él, no encontraba el ffvpx bundleado (donde vive dav1d)
813y anotaba `FFVPX: Link result: NoProvidedLib`. Y ahí **no falla**: se cae al ffmpeg del sistema, que
814cubre H.264/AAC/VP8/VP9/MP3/FLAC/Opus… pero **no AV1 por software**, porque el decodificador `av1`
815de ffmpeg es sólo hwaccel y nuestra receta va sin dav1d. Resultado: un vídeo AV1 se quedaba en
816`readyState=1` para siempre, sin un error, sin un NEEDED faltante y sin una cadena ausente.
817
818Tres corridas del MISMO artefacto que sólo cambian esa variable:
819
820    LD=/usr/lib/atuq:/usr/lib:/lib             → RDD NoProvidedLib   AV1 ✗
821    LD=/usr/lib/atuq:/usr/lib/atuq:/usr/lib    → RDD Success         AV1 ✓
822    LD=/relleno:/usr/lib/atuq:/usr/lib         → RDD Success         AV1 ✓   (el relleno se lo come)
823
824El arreglo es repetir el appdir en `recipes/atuq/bin/atuq`. Feo y correcto mientras no haya
825`patchelf` en el corpus para grabar `RUNPATH=$ORIGIN`, que borraría la variable entera.
826
827**Lo que quedó medido**, con `scripts/test-atuq-codecs.sh`, headless, por el lanzador de verdad y
828sin `LD_LIBRARY_PATH` de afuera:
829
830| Muestra | Veredicto |
831|---|---|
832| H.264 + AAC (mp4) | ✅ `t=3.00`, 75 cuadros |
833| VP9 + Opus (webm) | ✅ `t=3.00` |
834| AV1 (mp4) | ✅ `t=3.00` — sólo desde el arreglo del lanzador |
835| MP3 | ✅ |
836| FLAC | ✅ |
837
838El veredicto **no es «se creó el decodificador»**: es que `currentTime` AVANCE. La distinción no es
839retórica — en el caso de AV1 el decodificador se creaba (`RemoteDecoderChild … codec: av1`) y no
840entregaba un solo cuadro. El guardián corre con `--negative-control`, que saltea el lanzador y
841**exige que AV1 falle**: probado en los dos sentidos, porque uno que no puede fallar y uno que nunca
842falló se ven igual desde afuera.
843
844**Dos bugs de andamiaje que salieron de paso**, los dos en `atuq-nested.sh` y los dos escondidos
845detrás de una caché: el bucle de hidratación salía 1 siempre (línea vacía final + `set -e`) y mataba
846el script sin imprimir nada, y la comparación del sello nunca daba igual (un `\n` que `$(cat …)`
847recorta de un lado y no del otro), así que el rootfs se rehidrataba entero en cada corrida. El
848primero sólo se veía cuando cambiaban los hashes; lo destapó agregar `ffmpeg` a las raíces.
849
850### 4.g El chrome se programa SIN abrir `omni.ja` — y la vista dividida ya la trae el motor (2026-09-09)
851
852El pendiente escrito era «el chrome de verdad dentro de `omni.ja` (split view, dientes propios): el
853re-empaque ya está resuelto, lo que falta es el contenido». Las dos mitades de esa frase eran falsas,
854y las dos se midieron con `scripts/test-atuq-chrome.py` sobre el artefacto vigente:
855
856    VIVO el JS de atuq.cfg corre
857    VENTANA con gBrowser
858    PREF splitView.enabled=true
859    WRAPPER tabs=2
860    ACTIVA si
861    BROWSERS 2
862
863**1. El zip no es el gancho del chrome; `atuq.cfg` sí.** Ese fichero ya corre con privilegios —de ahí
864sale `nsIStyleSheetService`, y es la razón de `sandbox_enabled = false`—, así que desde ahí se observa
865`browser-delayed-startup-finished` y se toca el `gBrowser` de CADA ventana que abra el navegador. La
866sonda abre dos pestañas y las parte en dos desde `atuq.cfg`, sin tocar `omni.ja`.
867
868Y no es un atajo: es la vía CORRECTA, porque re-empacar `omni.ja` es exactamente lo que pelea con el
869orden del `jarlog` del PGO —el motivo por el que el `jarlog` está aparcado (`c3413d29`)—. Dicho al
870revés: **cada función del chrome que no entre al zip es una que no compite con la optimización de
871arranque.** Eso cambia el orden de preferencia para todo lo que venga: primero prefs, después
872extensión de sistema, después JS de chrome por autoconfig, y `omni.ja` sólo si no queda otra.
873
874**2. La vista dividida no hay que escribirla: Firefox 154 la trae y viene PRENDIDA.** En
875`browser/omni.ja` están `tabbrowser/tabsplitview.js` (492 líneas, el custom element completo con
876`addTabs`/`unsplitTabs`/`reverseTabs`), `opentabs-splitview.mjs` y `split-view-footer.js`; y
877`defaults/preferences/firefox.js` trae `pref("browser.tabs.splitView.enabled", true)`. La sonda no se
878queda en «el fichero está»: llama a `gBrowser.addTabSplitView([t1, t2])` y le pregunta al motor, que
879contesta `activeSplitView` puesta y `splitViewBrowsers.length == 2`. **Funciona en nuestro build.**
880
881Es el mismo patrón que ya pagó dos veces en este SDD —los dientes (`sidebar.verticalTabs`), los
882contenedores (`privacy.userContext.enabled`)—: la función existe en el motor y viene apagada o sin
883usar, y el trabajo es prenderla y comprobarla, no escribirla. La forma de equivocarse es al revés:
884declarar como deuda propia algo que upstream ya nos dio.
885
886⚠ **Lo que esto NO dice.** atuq todavía **no lleva JS de chrome propio**: lo medido es el GANCHO, con
887la sonda inyectada por una capa de overlay que no viaja en el artefacto. Cuando haya una función que
888lo justifique, va en `recipes/atuq/chrome/atuq.js` y la carga `atuq.cfg`. No se shipea un cargador
889vacío para «tenerlo listo».
890
891El control negativo sale del propio motor y no de una idea nuestra: `addTabSplitView` documenta que
892si TODAS las pestañas están fijadas borra el wrapper y devuelve `null`. `--negative-control` las fija
893y exige justamente eso — sin él, una sonda que dijera «partió» pase lo que pase se vería idéntica a
894una que funciona.
895
896### 2.ter Dónde vive la fuente de `atuq` — hizo falta un modo de `[source]` nuevo
897
898Escribir la receta destapó un muro que este documento no había visto: `[source]` era
899**obligatoriamente** git o tarball, así que una receta cuyo contenido no viene de upstream sino de
900nosotros no se podía ni expresar. Los rodeos eran todos peores — fetchear una fuente que después se
901ignora **miente** sobre la identidad del artefacto, y colgar el overlay de un repo aparte obliga al
902worker a tener acceso a un repo privado.
903
904Se agregó **`source.dir`** (commit `54fa4a9`): un árbol dentro del propio repo, hasheado por
905**contenido** con `ArtifactHash::of_tree` —que ya existía para verificar bit-reproducibilidad en
906Stage 2— y no por ruta. Es la misma disciplina que ya tenían los `patches`, que entran al hash por
907bytes. Editar un CSS del overlay mueve el `ArtifactHash`; renombrar el directorio, no.
908
909Un `.swm` **no** puede llevar una receta derivada, y los cuatro sitios que lo tocan fallan
910diciéndolo: el manifiesto es compartible y necesita un puntero resoluble desde fuera.
911
912**Hecho el 2026-09-05** (commits `aeebb19` y `6f6c32b`): `recipes/atuq.toml` + `recipes/atuq/`.
913La **v0.2** (`b3:7eff4ba4`) ya trae el branding: `application.ini` (Vendor/Name/RemotingName/
914CodeName, con el `ID` intacto para no salirse del ecosistema de complementos), `brand.ftl` dentro de
915`browser/omni.ja`, los binarios renombrados, iconos propios y `.desktop`. El re-empaque preserva
916orden, `STORED` y fechas del original, y se verificó contra el artefacto: **5306 entradas, mismo
917orden, y una sola con contenido distinto**. El `BuildID` se deriva del contenido del overlay —no de
918la fecha— porque es la clave con la que Gecko invalida su startup cache: sin eso, un cambio de
919chrome arranca con la interfaz vieja y *parece* que el overlay no agarró.
920
921La capa de configuración de la v0.1 son cuatro ficheros —autoconfig, `atuq.cfg`, `chrome/atuq.css`,
922`policies.json`— y el CSS se registra como `USER_SHEET` desde autoconfig porque `userChrome.css`
923vive en el perfil y exigiría que el usuario prenda una pref: atuq tiene que verse como atuq en el
924primer arranque. Falta construirlo: su dep `firefox` está en vuelo.
925
926### 2.quater Abrirlo en una pantalla: tres fallos que la clausura no podía ver
927
928El 2026-09-05, con `atuq` sellado y verificado, se hidrató y se abrió en el compositor de la sesión
929(waypipe). **No arrancó**, y los tres motivos son la diferencia entre «sellado» y «usable»:
930
9311. **EXDEV al hidratar.** `hydrate` proyecta con hardlinks y `linkat()` rechaza cruzar un punto de
932   montaje aunque los dos lados sean el mismo filesystem. Acá el store es `/dev/sdb` bind-monteado
933   y `work/` vive en `/dev/sdc`. El rootfs va bajo `/mnt/cosecha`, donde el volumen está montado
934   entero. Se comprueba con `findmnt -T`, **nunca** con `stat -c %d`.
9352. **El lanzador no puede ser un symlink.** Ni el binario ni sus `.so` traen `RPATH`/`RUNPATH`
936   (`readelf -d`), así que el motor no encontraba su propio `libnspr4.so` y moría en
937   `XPCOMGlueLoad`. Es un script con `LD_LIBRARY_PATH` + `exec`, como Debian y Fedora. La
938   alternativa limpia —`RPATH=$ORIGIN` con `patchelf`, que es lo que hace Alpine— espera a que
939   `patchelf` exista como receta del corpus.
9403. **Un bug del corpus, no de atuq: `atk` se había tragado GObject.** Declaraba la variante
941   ESTÁTICA de glib y produce un objeto compartido, así que `libatk-1.0.so` llevaba una copia
942   entera del sistema de tipos. Dos GObject en un proceso ⇒ 45 `GLib-GObject-CRITICAL` y
943   `Segmentation fault`. **El síntoma no nombra a atk**, y no se ve mirando el rootfs: había una
944   sola `libgobject`. Se cazó preguntando quién DEFINE el símbolo:
945   `nm -D --defined-only <cada .so> | grep " T g_type_register_static"` — deben salir uno, salieron
946   dos.
947
948Radio medido antes de tocar (`yupana radio atk`): 4 transitivos, 3 sellados a deuda; GNOME fuera
949porque usa gtk4. La cadena `atk → gtk3 → firefox → atuq` volvió a sellar 4/4, y **firefox tardó
950~50 minutos, no las cuatro horas** que repetía este documento — el número venía del folclore de la
951receta, no de una medición.
952
953**La lección para el plan: ninguna unidad de este frente está cerrada hasta que algo se ABRE en una
954pantalla.** La clausura decía 100% con un navegador que no llegaba a pintar un píxel.
955
956### 2.quinquies La v0.3 y los tres mecanismos: dos muertos, uno vivo
957
958La página de inicio y la pestaña nueva parecían un `pref` y resultaron ser un frente. Lo que se
959midió, en orden:
960
961| Mecanismo | Resultado |
962|---|---|
963| `distribution/extensions/` — el clásico de las distros | **No instala nada.** Firefox retiró el *sideloading*. El `extensions.json` del perfil ni lo mencionaba y el log no dijo una palabra: fallo perfectamente silencioso |
964| `policies.json` → `ExtensionSettings` con `install_url` | **Se lee** (`browser.policies.applied=true` en el perfil) y falla nombrándose: `ERROR_SIGNEDSTATE_REQUIRED` |
965| `xpinstall.signatures.required = false` | **No alcanza** — la exigencia viene COMPILADA |
966
967**El instrumento que destrabó el diagnóstico fue un testigo.** `defaultPref` no deja rastro en
968`prefs.js` —sólo se guarda lo que difiere del default— así que un autoconfig que **no se ejecuta**
969es indistinguible de uno que sí y no hace nada. `atuq.cfg` escribe ahora `atuq.autoconfig.ok` como
970pref de **usuario**, legible desde fuera sin abrir el navegador. Salió `true` ⇒ el `.cfg` corría, y
971por lo tanto la pref de firma se estaba ignorando.
972
973De ahí `MOZ_REQUIRE_SIGNING` vacío en `recipes/firefox.toml`. Dos detalles que costaron cada uno su
974vuelta:
975
9761. El default sale del **milestone** (`milestone.is_release_or_beta`), no del canal de actualización.
977   El nuestro es `default` y la exigencia estaba activa igual.
9782. **Se desactiva con el valor VACÍO, no con cero.** `=0` muere con «takes 0 values»: es booleana y
979   el cero es un valor que no acepta. Leído del parser de mozbuild, no deducido.
980
981**El precio, escrito:** este Firefox deja de exigir la firma de Mozilla para cualquier complemento.
982La alternativa es firmar en AMO —cuenta y revisión de Mozilla por versión—, que es la dependencia
983externa que esta distro existe para no tener. Y no es un desvío: **sin esto, el `sct` del §6.1
984tampoco se podría shipear nunca**, así que la unidad 6 dependía de ésta sin que el plan lo dijera.
985
986**Método que conviene repetir:** la prueba del testigo se hizo **sin reconstruir**, montando el
987`.cfg` modificado con `--ro-bind` por encima del artefacto. Editar el fichero en el rootfs habría
988escrito sobre un **hardlink del store** y corrompido el artefacto sellado.
989
990### 2.sexies Lo que quedó PROBADO, y con qué
991
992Tres afirmaciones que este documento venía haciendo sin medir, y cómo se cerraron:
993
994| Afirmación | Prueba |
995|---|---|
996| El re-empaque del `omni.ja` es determinista | `why-differs` entre dos builds de `atuq`: **85 entradas idénticas, 0 divergen** |
997| La capa de configuración se aplica | testigo `atuq.autoconfig.ok` escrito como pref de **usuario** en el perfil |
998| El branding se ve | captura de la pantalla real con `grim` desde dentro de la jaula, y la página de inicio renderizada por el propio navegador con `--headless --screenshot` |
999| La base también reproduce | `why-differs` entre dos builds de `firefox` en el worker: **56 entradas idénticas, 0 divergen** |
1000
1001Y el contraste que salió de la primera: **el derivado reproducía y la base no.** El `BuildID` de
1002`firefox` era la hora del build, así que dos construcciones con el mismo `ArtifactHash` daban bytes
1003distintos — y `build-state.json` no lo podía ver, porque el hash es input-addressed y no se mueve
1004por esto. Verde y mintiendo. Cerrado con `MOZ_BUILD_DATE` desde `SOURCE_DATE_EPOCH`, que es el
1005mecanismo de hermeticidad que el sandbox ya tenía — y **comprobado como se comprueba esto**:
1006apartando el artefacto como `.ref`, construyendo de nuevo y pasándole `why-differs`. Reproduce.
1007
1008**Dos guardianes nuevos en la fase `install` de `firefox`**, hermanos entre sí, porque los dos fallos
1009son de la misma familia —una bandera que el `configure` acepta y el artefacto ignora, muda y a 50
1010minutos de distancia—: uno comprueba `MOZ_REQUIRE_SIGNING: false` dentro del `omni.ja`, el otro que
1011el `BuildID` sea el que `SOURCE_DATE_EPOCH` obliga.
1012
1013**La regla que sale de todo el día:** cuando la duda es «¿llegó al artefacto?», la respuesta no está
1014en el log del build ni en la receta — está **dentro del artefacto**, y hay que ir a buscarla ahí.
1015
1016## 7. La costura: un host de native messaging en Rust
1017
1018Todo lo del §6 que no es CSS pasa por **un solo mecanismo**: un proceso Rust que habla native
1019messaging con la extensión de `atuq` y, del otro lado, con la suite (`agora` para identidad Ed25519,
1020`khipu`, el store, `foreign-*`, `cortafuegos`).
1021
1022Que sea **uno** y no siete es la decisión: cada feature del §6 pasa a ser un verbo de ese host, no un
1023proyecto nuevo. El binario vive en tawasuyu (es suite, no build system); `atuq` sólo lo declara como
1024dep y le deja el manifiesto de native messaging en su sitio. **El nombre del crate se decide en
1025tawasuyu y con su regla 10 puesta** — acá no se bautiza nada de allá.
1026
1027### 7.bis El camino EXISTE, y tres cosas que no eran obvias (2026-09-07)
1028
1029Antes de escribir un crate contra un mecanismo hay que saber si el mecanismo funciona en NUESTRO
1030build —propio, rebrandeado, con `MOZ_REQUIRE_SIGNING` vacío—, así que se puso una **sonda**:
1031extensión de diez líneas con permiso `nativeMessaging` y un host de tres que contesta `{"ok":true}`.
1032Vive en `scripts/test-atuq-nativo.py`, con control negativo:
1033
1034    positivo  MENSAJE {"ok":true}
1035    control   DESCONECTADO No such native application puente_atuq
1036
1037El control no sólo falla: **nombra la causa**, que es lo que confirma que la ruta del manifiesto es
1038la que se probó. Lo que hay que saber para escribir el host:
1039
1040| Qué | Medido |
1041|---|---|
1042| Dónde va el manifiesto | **`/usr/lib/mozilla/native-messaging-hosts/`**, NO el appdir. Sale de `XRESysNativeManifests`, un `/usr/lib/mozilla` compilado; el rebranding a `atuq` no lo mueve |
1043| Cómo se instala la extensión | por el **escaneo de `distribution/extensions/`**. `ExtensionSettings.install_url` con `file://` no instala nada, ni con `force_installed` ni con el XPI dentro del appdir, y **sin una línea de log** |
1044| Forma del host | un proceso **largo**: si escribe la respuesta y sale, Gecko cierra el puerto sin entregarla — `onDisconnect` «sin error y sin mensaje», el peor informe posible |
1045| Con qué diagnosticar | el error del puerto de `connectNative`. `sendNativeMessage` devuelve «An unexpected error occurred» para todo y no distingue nada |
1046
1047⚠ La tercera fila del cuadro corrige una lectura fácil de `policies.json`: los dos mecanismos
1048apuntan a los mismos ficheros y se tapan uno al otro, así que la política PARECE ser la que instala.
1049Fija y configura; instalar, no.
1050
1051### 7.ter Y esa fila ahora tiene guardián — porque el README decía lo contrario (2026-09-09)
1052
1053La fila «cómo se instala la extensión» era una nota al pie de una sonda de native messaging, y
1054mientras tanto **`recipes/atuq/README.md` afirmaba lo opuesto**: que el *sideloading* desde
1055`distribution/extensions/` «ya no funciona» y que instalaba `ExtensionSettings`. Dos documentos
1056nuestros, contradictorios, sobre el mecanismo del que cuelgan TODAS las extensiones de atuq —hoy
1057`inicio` y `proxy`, mañana la de `sct`—. Y ninguna observación del artefacto los distingue, porque
1058los dos apuntan a los mismos ficheros.
1059
1060`scripts/test-atuq-instalacion.py` lo rompe de a uno y mira qué pasa. Medido sobre
1061`atuq b3:fab2fbfb` (firefox 154 con PGO v2) y REPETIDO sobre `b3:9e16ac35` —el artefacto que esta
1062misma corrección creó, porque el README vive dentro de `source.dir` y editarlo re-hashea atuq—,
1063tres escenarios:
1064
1065| escenario | qué se rompe | motor (`homepageOverride`) | perfil |
1066|---|---|---|---|
1067| `as-is` | nada | `moz-extension://…/inicio.html` | `inicio` y `proxy` activas |
1068| `no-policy` | `policies.json` **sin** `ExtensionSettings` | **sigue siendo la nuestra** | **las dos siguen activas** |
1069| `policy-only` | los XPI mudados a `/usr/lib/atuq/xpi-politica/`, con `install_url` apuntando ahí | `about:home` | **ninguna de las dos existe** |
1070
1071⇒ **instala el escaneo de la carpeta; `install_url` con `file://` no instala nada.** El §7.bis
1072queda confirmado y el README corregido.
1073
1074Dos cosas que este guión trae y que valen más que el veredicto:
1075
10761. **El control es por construcción, no un modo aparte.** La sonda que le pregunta al motor vive en
1077   `distribution/extensions/` y **ninguna política la nombra**: si la sonda habla, el escaneo está
1078   vivo en esa corrida. Una corrida muda no se lee como «no instaló» — se declara ROTA y se guarda
1079   el log. Sin eso, un atuq que no arranca se vería idéntico a una política que no instala.
10802. **La segunda señal que probé NO discrimina, y queda dicho.** Esperaba que el `location` de
1081   `extensions.json` separara los mecanismos (`app-system-defaults` vs. `app-profile`). No: los dos
1082   XPI salen `app-profile` **también** cuando los instala la carpeta y no hay política que los
1083   mencione. Se imprime igual porque dice si están, pero como discriminador es cero — y una señal
1084   que uno cree que discrimina y no discrimina es peor que ninguna.
1085
1086**Por qué esto es un guardián y no un test más.** Mozilla lleva años retirando el *sideloading*, y
1087el día que la carpeta deje de instalar, atuq arranca **sin ninguna de sus extensiones** y sin una
1088línea de error: la página de inicio vuelve a ser la de Firefox y el proxy por contenedor
1089simplemente no enruta. Es el modo de fallo silencioso de siempre, y el que aparece cuando SUBE la
1090dep, no cuando alguien toca atuq.
1091
1092⚠ **Y por eso mismo hay que decir lo que todavía NO está: ninguno de los `test-atuq-*` corre en el
1093latido.** `cosecha-cron.sh` sólo ejecuta `vigia-sonames.py`; los de atuq se corren a mano. Meterlos
1094cuesta ~3 min por ciclo (tres arranques de navegador headless por escenario) y exige que el hub tenga
1095hidratado el rootfs de `scripts/atuq-nested.sh`, así que **es una decisión con precio y no un
1096`echo` más en el cron** — queda escrita acá y sin dar por hecho lo contrario. El día que se meta, el
1097sitio es el bloque de guardianes de `cosecha-cron.sh` (L341-352).
1098
1099### 7.quater El host, escrito — y por qué la extensión NO puede hablarle al testigo (2026-09-10)
1100
1101El §6.1 decía que `sct` v1 es «extensión con `webRequest` bloqueante que hashea cada respuesta de
1102script y **consulta al testigo** antes de dejarla pasar». La primera mitad es correcta; la segunda es
1103imposible tal como está escrita, y conviene decirlo porque parecía un atajo para saltarse esta
1104unidad: **el cable de `puriy-sct-testigo` es un POST con `postcard` en el body**, no JSON. Un JS no
1105puede ser su cliente. Y reimplementar el registro TOFU en la extensión sería fabricar un sustituto
1106paralelo del original —lo que la regla 10 de tawasuyu prohíbe— además de duplicar la única pieza que
1107ya estaba certificada. Entonces v1 pasa por el host, y el host es esta unidad.
1108
1109Se decidió con el operador, con el `grep` de la regla 10 hecho primero: **ningún término del dominio
1110significaba «host de native messaging»**, y los que suenan a mensajero están todos ocupados por
1111dominios ajenos y grandes (`chasqui` es un type broker, `chaka` el puente a COBOL, `paloma` el cliente
1112de correo, `tampu` el común de objetos). El nombre salió del título de este propio §7: **la costura**.
1113
1114| Pieza | Dónde | Por qué ahí |
1115|---|---|---|
1116| `puriy-costura` | `00_unanchay/puriy/` | regla 1: subcrate del dominio, no proliferación lateral. Precedentes: `puriy-sct-testigo`, `rimay/verbo-daemon`, `watuy-daemon` |
1117| `foreign-webext` | `shared/` | regla 4: el protocolo es AJENO. Lib pura sin binario, como los otros 37 puentes (medido: ninguno lleva `[[bin]]`) |
1118| `recipes/puriy-costura.toml` | takana | el artefacto: estático musl, pineado por commit, `--locked` |
1119
1120Verbos v1: `ping`, `sct.observe`, `sct.state`. Claves del cable en inglés (regla 7 de allá y regla 4
1121de acá: se tipean). `phase` es `learning`/`stable`/`not-evaluable`, y un `events[]` vacío es lo normal
1122— sólo hay evento cuando un origen **ya estable** ejecuta un hash que nadie vio nunca.
1123
1124**Los tres tests que hacen que el veredicto signifique algo** (de catorce): el mismo cambio de script
1125mientras el origen todavía aprende **no** alerta; rotar `?v=` con el mismo código **tampoco** (la
1126identidad del recurso es su contenido, y sin eso cada despliegue con cache-buster sería un aviso de
1127supply-chain: un detector que grita todos los días no se mira más); y el aprendizaje **sobrevive al
1128cierre del navegador**, sin lo cual cada arranque volvería a «aprendiendo» y ningún cambio sería nunca
1129un evento.
1130
1131**Los dos límites, escritos en el código y en los dos LEEME, no en una nota de sesión:**
1132
11331. **Qué bytes se hashean.** La extensión manda el TEXTO ya decodificado; se hashea su UTF-8. La
1134   detección vale —el TOFU compara lo mismo contra lo mismo—, pero nuestro hash **no es comparable**
1135   con el de los bytes servidos que publique un tercero, ni con el de la v2 (el gancho en el script
1136   loader). Un hash que uno cree comparable y no lo es sería peor que no tenerlo.
11372. **La semilla del log es provisional**: se deriva del directorio de estado, así que es
1138   determinística (el log se reanuda) pero **no es un secreto** ⇒ la bitácora es a prueba de
1139   REESCRITURA, no de SUPLANTACIÓN. La de verdad sale del perfil cuando el almacén del perfil exista.
1140
1141**Y lo que queda medido para la unidad 6, preguntándole al artefacto y no a la documentación de
1142Mozilla** (§2.sexies): `filterResponseData` y el permiso `webRequestFilterResponse` **están** en
1143nuestro build (`omni.ja`, `chrome/toolkit/content/extensions/schemas/web_request.json`), así que la
1144extensión va a poder leer el cuerpo de un script. Lo que NO va a poder es ver los scripts **inline**
1145por esa vía —`filterResponseData` entrega el documento, no cada `<script>`—, y eso está bien para v1:
1146el ataque que `sct` nombra es la sustitución en el CDN, que es exactamente el caso `<script src>`.
1147
1148## 8. Plan, por unidades de trabajo
1149
1150Cada una cierra sola, se commitea y se pushea. El orden no es preferencia: cada una destraba a la
1151siguiente.
1152
1153| # | Unidad | Puerta que abre | Bloqueada por |
1154|---|---|---|---|
1155| 1 | **`waterfox` SELLA** ✅ 2026-09-06 — `b3:88b5a762`, 377 M, BuildID determinista **y REPRODUCE bit a bit**. Cuatro muros, **ninguno de la receta**: takana viejo en el worker, el watchdog barriendo el post-mortem, deps estáticas vs. el cairo bundleado, y una rotura de upstream sólo-Linux | valida la tesis del reúso | — |
1156| 2 | ~~`llvm-toolchain`~~ → **`apk add lld` + `compiler="clang"`** ✅ 2026-09-05 | LTO **y** el muro 3 | — |
1157| 3 | Construir el `firefox` con LTO (hash `b3:6f2a3b2f`) | el eje de velocidad **y** las extensiones de `atuq` | 2 ✅ |
1158| 3.a | **PGO ENCENDIDO** ✅ 2026-09-07 — perfil de 501.521 funciones recogido bajo headless, publicado en el mirror y pineado por sha256; 189 compilaciones con `-fprofile-use`. Sin `jarlog` todavía | la otra mitad de la ganancia | 3 ✅ |
1159| 3.b | **RLBox ENCENDIDO** ✅ 2026-09-06 — cadena wasm de CINCO recetas selladas + guardián que la exige en el binario; firefox sellado **y REPRODUCE bit a bit** (`verificar-repro.sh`: 0 no-determinismos) | cierra el hueco de seguridad del §3.bis | 2 ✅ |
1160| 4 | **`atuq`: receta derivada + overlay de chrome** ✅ v0.1 escrita | el andamio de todo lo demás | 3 |
1161| 4.b | Branding + re-empaque de `omni.ja` ✅ v0.2 | el chrome de verdad | — |
1162| 4.d | **Abrirlo en pantalla** — destapó EXDEV, el lanzador, el `atk` envenenado y la cadena GTK3 estática | «usable», no sólo «sellado» | — |
1163| 4.e | **v0.3: página de inicio y pestaña nueva** por extensión de sistema; exigió `MOZ_REQUIRE_SIGNING` vacío. **Verificado 2026-09-07** con `scripts/test-atuq-inicio.py`: se le pregunta al MOTOR (`browserSettings.homepageOverride` / `newTabPageOverride`) y da `moz-extension://…/inicio.html` en las dos, contra `about:home`/`about:newtab` en el control | y con eso queda destrabada la unidad 6 (`sct`) | rebuild de firefox |
1164| 4.f | **Los códecs, medidos** ✅ 2026-09-07 — H.264+AAC, VP9+Opus, AV1, MP3 y FLAC reproducen; arreglado el `LD_LIBRARY_PATH` que dejaba al RDD sin ffvpx (AV1 muerto en silencio) y nacido `scripts/test-atuq-codecs.sh` con control negativo | «se ve el vídeo», que ningún auditor de ELF podía responder | — |
1165| 4.c | `MOZ_BUILD_DATE` determinista ✅ — `BuildID=19700101000001`, con guardián en install y **`why-differs` 56/56 sobre dos builds reales** | el invariante de reproducibilidad | — |
1166| 4.g | **El chrome se programa desde `atuq.cfg`, sin abrir `omni.ja`** ✅ 2026-09-09 — y de paso: la **vista dividida ya la trae el motor y viene prendida** (fx 154), ejercitada de verdad con `gBrowser.addTabSplitView` ⇒ `activeSplitView` + 2 navegadores. Guardián `scripts/test-atuq-chrome.py` con control negativo del propio motor | retira dos pendientes que eran de upstream, y deja el camino del chrome que NO pelea con el `jarlog` | — |
1167| 4.h | **Quién instala las extensiones, medido** ✅ 2026-09-09 — tres escenarios en `scripts/test-atuq-instalacion.py`: instala el ESCANEO de `distribution/extensions/`, `install_url` con `file://` no instala nada. El README de la receta afirmaba lo contrario y quedó corregido | el mecanismo del que cuelga la extensión de `sct` deja de ser una nota al pie y pasa a estar vigilado | — |
1168| 5 | **Host de native messaging — HECHO 2026-09-10.** `puriy-costura` en tawasuyu (`ebe41e96`) + el cable `shared/foreign-webext`, 14 tests sin navegador; y del lado de acá `recipes/puriy-costura.toml` ⇒ `b3:3b633431`, ELF estático de 952 K **verificado como artefacto**: contesta un marco de 4 bytes y hace la promesa del §6.1 completa (4 visitas aprendiendo → `stable` → un script cambiado = un evento). El camino ya estaba comprobado en el §7.bis con sonda y control negativo | los verbos del §6 | 4 ✅ |
1169| 6 | **`sct` v1 — HECHA 2026-09-10.** Extensión `sct@atuq.tawasuyu` (`filterResponseData` → native messaging) + el manifiesto en `/usr/lib/mozilla/native-messaging-hosts/` + el lanzador que le pone el `--state` que el manifiesto no puede llevar. Guardián `scripts/test-atuq-sct.py`: servidor HTTP real, seis cargas, **una carga = una visita** vigilado, la insignia releída, y dos controles (la 5ª repite el mismo script y no alerta; sin manifiesto no hay veredicto) | el diferenciador que nadie tiene, andando | 5 ✅ |
1170| 7 | Descargas al CAS | 6.2, y alimenta 6.9 | 5 |
1171| 8 | Archivo + RAG | 6.3 | 5, 7 |
1172| 9 | Torrent, medios, foco | 6.5–6.7, 6.9 | 5 |
1173| 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 | — |
1174
1175Las unidades 2 y 4 son **paralelizables**: la toolchain no toca el chrome y el chrome no toca la
1176toolchain. Si hay dos frentes, van juntas.
1177
1178## 9. Por qué esto no abandona a `puriy`
1179
1180`puriy` es el motor DOM/CSS propio con JS real (QuickJS-NG sobre `wasmi`) cuyo límite declarado no es
1181el lenguaje sino **el wiring nativo**: DOM bindings completos, red, render. Eso no se acelera
1182escribiendo otro navegador; se acelera con tiempo.
1183
1184`atuq` no le compite porque no comparte una sola línea con él, y **le sirve** porque todo lo del §6
1185vive del lado Rust: el host del §7, el testigo de `sct`, las descargas al CAS, el archivo con RAG.
1186Son **agnósticos del motor**. Cuando `puriy` madure, se enchufan del mismo lado sin reescribirse.
1187
1188Dicho al revés, que es como conviene recordarlo: **`atuq` es el navegador que se puede usar mientras
1189`puriy` crece, y el andamio de las features que `puriy` va a heredar.** Si dentro de dos años `atuq`
1190se apaga, lo que se tira es una receta derivada y una hoja de CSS; todo lo demás sobrevive.