La fila de la tabla se leía como «bloquear sitios». El cortafuegos NO sabe de sitios: su política de
egress tiene UNA dimensión, qué cgroup sale, y ninguna de destino (leído en UnidadRed, no supuesto).
El foco que estas piezas dan es «el navegador no sale», con todo lo local andando — promesa más
honesta, además: una lista de dominios se esquiva con un espejo; un cgroup sin egress no.
Medido con nuestro propio nft, en el LXC donde somos root:
linea-base exit=0 · control exit=0 · foco exit=1
Tres medidas y no una: la línea base porque un harness roto se lee igual que un foco que funciona, y
el control porque un reglaset que niega de más tampoco se distingue. `--broken-rules` abre egress al
cgroup en foco y el guardián falla nombrándolo (sale 1). Verificado en los dos sentidos.
Restricciones reales que salieron de medir: crear un cgroup pide root (EPERM incluso en un userns con
CAP_ALL), y `nft -c` no es sintaxis — resuelve el path del cgroup contra la máquina viva.
⚠ Y lo que rompí en el camino, documentado: `/sys/fs/cgroup` está montado SHARED, así que desmontar
la copia de un --rbind se propaga al montaje real. Dejé al worker sin cgroup2 dos veces, en silencio.
Remontado y jerarquía intacta. Ahora todo va en un mount namespace propio (--propagation private),
sin `umount -l` antes de un rm -rf, y con /proc/mounts consultado antes de borrar.
Tres falsos positivos más que cazó el harness, todos con cara de éxito: un gmp viejo tomado por
`ls store/*-gmp` (sin .so ⇒ nada conectaba, y el lab del hub lo tapaba), /sbin fuera del PATH del
chroot (sin `ip`, loopback caído), y un COMENTARIO que se ejecutó — backticks dentro de un heredoc
sin comillas corrieron `ip`/`ifconfig` en el host y pegaron su salida en el guión generado.
Entra por el §6.5 del SDD 26 —el «modo foco» de atuq lo sostiene el cortafuegos del sistema y no
una extensión que el navegador puede apagar— pero `nftables` estaba `wanted` en el grafo desde
antes: la cadena sirve igual al servidor de producción del SDD 28.
Selladas y MEDIDAS con el consumidor, no por presencia:
nft --version → nftables v1.1.6, corriendo desde nuestro artefacto
nft -c -f / nft -f → aceptan Y APLICAN en un netns privado (bwrap --unshare-net + CAP_NET_ADMIN)
socket cgroupv2 level 1 "<cgroup>" → la expresión EXACTA que genera cortafuegos-core: aplica
Dos hallazgos del camino, los dos en los comentarios de la receta:
1. nftables NO reproduce de fábrica: `MAKE_STAMP` es `$(shell date +%s)` y `nftversion.h` lo mete
byte a byte en el binario — la familia del BuildID de waterfox. No mira SOURCE_DATE_EPOCH. Se
fija en 0, que además es lo correcto: el sello sólo sirve para comparar qué nft creó una tabla,
y dos builds de la misma versión SON el mismo nft.
2. su `config.status` trae un bashismo (`for ((i = 56; ...))`) que busybox rechaza con
«bad for loop variable». Se arregla en el parche y no con CONFIG_SHELL=bash: el lab no entra en
`hash_inputs`, así que apoyarse en su bash sería una dependencia invisible.
Y una medición que condiciona al guardián que viene: `nft -c` NO es un chequeo de sintaxis — resuelve
el path del cgroup contra la máquina viva y falla con «cgroupv2 path fails» si no existe. O sea que
verificar una política del cortafuegos exige crear los cgroups, y eso pide root.
Cerrado: clave de release estable, 88/88 del perfil publicados con hash anclado, servidos por la
caja, y el control de firma en los dos sentidos (confianza buena ⇒ instala; confianza vacía ⇒
aborta).
El lazo destapó dos cosas que sólo se ven cerrándolo:
- **`strip_debug` no viajaba en el `.swm`** y ES entrada de hash ⇒ 40 recetas del corpus (18 de las
88 de este perfil) no se podían instalar. Nadie lo sabía porque nunca se había hecho el viaje
completo receta → paquete → `install --require-signed`.
- **El loopback nunca se levantaba.** `lo` DOWN, y el síntoma era un timeout de 30 s con caddy
escuchando: un cuelgue que parece del servidor, no un "connection refused".
Y deja el límite escrito, que es lo que más vale: **la caja sirve, verifica y descarga, pero NO
puede reproducir**. `install` construye desde fuente y eso exige el LAB ENTERO en el cliente — no es
que falte un compilador: el lab entra en el ArtifactHash, así que sin él no se puede ni calcular el
hash a comparar. Es el SDD 27 §4 visto desde el otro lado: para cualquiera que no sea un hub de
build, reproducir no es una opción, y el default tiene que ser hidratar artefactos firmados.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
`build-repo.sh` generaba una clave nueva en cada corrida si no se le pasaba `KEY=`. Un índice firmado
con una clave que nadie conoce y que cambia cada vez no lo verifica nadie: es decoración. El SDD 19
§3.2 lo dice sin vueltas — la firma sin gestión de claves es teatro.
- `trust/release.ed25519.pub` — la clave PÚBLICA, en el repo, que es donde tiene que estar para que
un cliente pueda verificar. La privada vive en `~/.config/takana/keys/release.ed25519` (0600),
fuera del repo, mismo trato que las credenciales del Storage Box.
- `trust/README.md` dice también **lo que esto NO es**: no hay clave raíz fuera de línea, ni
rotación, ni procedimiento de filtración. Cierra el agujero de la clave efímera, NO el §3.2.
- `scripts/repo-perfil.sh` publica la clausura de un perfil y **aborta si no encuentra la clave**, en
vez de inventar una. El conjunto sale de `yupana.membresia()` sobre `targets.toml`, la misma fuente
que usa la imagen ⇒ el repo y la imagen no pueden divergir: son la misma lista.
- Y trae su propia guarda: tras firmar, VERIFICA el índice contra `trust/` y falla si no ancla.
Medido: 88/88 del perfil `servidor` con `expected_hash` anclado, índice firmado que verifica.
Control en los dos sentidos contra el repo servido por la caja:
--trust ./trust => "release: trusted (by release)" ⇒ instala
--trust <dir vacío> => "release: unknown-key ... clave no confiada" ⇒ ABORTA
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
En un sistema con systemd u OpenRC el init levanta `lo`. Con arje-zero no lo hacía **nadie**.
Medido en la caja de producción el 2026-09-10:
ip -o link show lo => lo: <LOOPBACK> DOWN (y CERO direcciones)
caddy escuchando en 0.0.0.0:80
curl http://127.0.0.1/index.json => timeout de 30 s
No «connection refused», que se diagnostica en un minuto: un CUELGUE, que parece del servidor. Se
descubrió intentando que la caja instalara un paquete de su propio repo — o sea que el primer
servicio que habló con 127.0.0.1 fue también el primero en chocarse.
Cualquier cosa que use loopback fallaba igual: un backend detrás de un proxy, un socket TCP entre
demonios, un repo local. Va en `netup` porque es quien configura la red, y no es fatal: si ya estaba
levantado los errores son EEXIST y no deben tumbar el arranque.
Probado en un netns, en los dos estados: antes `lo: <LOOPBACK>` con 0 direcciones; después
`lo: <LOOPBACK,UP,LOWER_UP>` con `inet 127.0.0.1/8 scope host`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
Encontrado instalando `takana` desde su propio repo (SDD 28 §5), que es la primera vez que se hace
el viaje completo receta → `.tkn` → `install --require-signed` sobre un paquete con `strip_debug`.
Error: expected_hash no coincide:
declarado = b3:941d1857e6e93ebbfbad8240a1c30405263e5ff8fc881a923aee312160563eea
obtenido = b3:2727050ebdbd7817b53e79ffe9796569e9364454ed35474b51e881fcc6048766
`why-differs` sobre los dos artefactos lo nombró: las recetas selladas diferían en `version`,
`license` y **`strip_debug`**. Los dos binarios pesaban EXACTAMENTE lo mismo (3.374.768 bytes) y sólo
divergían en `.shstrtab` — la firma de un `strip` que corrió una vez y la otra no.
`swm_bridge` re-inyecta con cuidado `flags`, `phases`, `zig_version`, `strip_components`, `patches`,
`deps`, `evidence` y `slots` («fidelidad de reconstrucción», dice su comentario) y **se olvidaba de
`strip_debug`**, que ni siquiera existía en `SwmBuild` ⇒ no viajaba en el `.swm` en absoluto. Como
ENTRA EN `hash_inputs` (`recipe.rs:572`, con el comentario «cambia el CONTENIDO del artefacto, así
que TIENE que entrar»), el receptor reconstruía con `None` y sellaba en otra dirección.
**Alcance medido: 40 recetas del corpus lo usan, 18 de las 88 del perfil `servidor`.** Para todas,
el `expected_hash` anclado por `pack --build` no coincidía NUNCA y `install --require-signed`
abortaba. O sea: una quinta parte del repo no se podía instalar, y nadie lo sabía porque nunca se
había cerrado el lazo.
Por qué no lo cazó nadie antes: `tree` —sin `strip_debug`— da cache-hit y funciona perfecto. El bug
sólo aparece en las recetas que lo declaran, y el dogfood previo no las tocaba.
Test de regresión con su control: una receta CON `strip_debug` lo lleva en el `.swm`, y una SIN él no
gana un `false` inventado. 221 tests de takana-core en verde.
Verificado end-to-end tras el arreglo: `install takana --repo http://<caja> --require-signed` da
cache-hit en `b3:941d1857…` —el mismo hash anclado— e hidrata los 3 ficheros.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
Encontrado con `ps` sobre la máquina, no por un test: al cerrar el sandbox quedaban
vivos el daemon y su `bwrap` interno, sosteniendo overlays ya borrados. Es correcto que
el daemon se quede —su torrent de prueba no tiene enjambre, así que nunca termina y
nunca está «sin nada»—, lo que faltaba era despedirlo y MEDIR que se fue.
- el guión de adentro le pide `puriy-costura-torrent stop` (el verbo del producto);
- la huella del socket se anota adentro y ANTES del stop: el daemon lo borra al irse;
- el guardián censa daemons antes/después con `ps -C` (nunca `pkill -f`) y falla
nombrando el PID; el `finally` barre lo propio para que un test rojo no deje basura;
- tope de 180 s al sandbox, como seguro contra un cuelgue.
Comprobado en los dos sentidos con una copia rota fuera del repo: sin el `stop` el
guardián daba ✓ igual, y con la aserción nueva sale ✗ nombrando el PID. La hipótesis
de que se COLGARÍA era falsa: el `bwrap` externo vuelve; el que espera es el interno.
Verde: positivo, control negativo y rotura a propósito.
El corpus construía 869 recetas y no la suya. `takana` sólo existía como `cargo build --release`
sobre un clon del repo, y eso bloqueaba lo de arriba de todo del SDD 28: que un servidor takana se
sirva sus propios paquetes **a su propio host**. El host necesita `takana` instalado para consumir
el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo.
**El muro, que nadie había tocado porque takana nunca se había empaquetado:** `takana-cli` declara
DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`, la compatibilidad de la etapa 2 del
ADR 0016). El camino Cargo del corpus invoca `cargo rustc … -- -C target-feature=+crt-static`, y
`cargo rustc` con argumentos extra **sólo admite UN target**:
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target
O sea: la decisión de emitir dos binarios —tomada para que el alias sobreviviera a `cargo clean` y a
la siembra de la granja, que excluye `/target`— hacía que el crate no se pudiera empaquetar. Se
resuelve con `--bin takana` y reponiendo `hammer` como ENLACE en la fase de instalación: en el árbol
de build un symlink no sobrevive, pero en el ARTEFACTO sellado es permanente y no duplica los megas.
Y ese alias tapa un agujero real: **`arje-zero` todavía invoca el binario por el nombre viejo** — en
el primer arranque de la caja de producción se leyó `hammer no corre, sin menú de arranque`. Viene
pineado desde tawasuyu, así que no se arregla desde este repo; mientras `hammer` esté en el
artefacto, el menú de arranque por grafo del ADR 0010 tiene qué ejecutar. Cuando la etapa 6 retire
el alias, hay que subir arje-zero ANTES.
Sellado `b3:941d1857…`, 3,3 M con el split de debug. Verificado: ELF estático, `takana --version` y
`hammer --version` dan los dos `takana 0.0.1`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El §6.9 apunta ahora a tawasuyu `3bd1440d` (`b3:27c7b73a`), que arregla un daemon que
quedaba VIVO PARA SIEMPRE cuando su sesión de torrent no arrancaba: el bucle hacía
`let Ok(g) = gestor() else { continue }` y el `continue` saltaba la evaluación de
«¿sobro?».
Y lo que queda escrito en el §6.9 es CÓMO se encontró, porque es lo reutilizable: no lo
encontró ningún test sino mirar `ps` después de las pruebas —un daemon con 23 minutos y
`idle_seconds = 300`—. Los tests cubrían la decisión como función PURA, y esa función
estaba bien: el que no llegaba a llamarla era el bucle. **Una decisión correcta que
nadie toma se ve igual que una que no existe.**
Los dos guardianes vuelven a pasar sobre los artefactos vigentes (`atuq b3:d1a444ad`,
`puriy-costura b3:cad5c855`, `puriy-costura-torrent b3:27c7b73a`): el positivo con
`TOMADO prueba-atuq.bin` y el socket que nadie arrancó, y el control negativo nombrando
lo que falta.
El 6.9 del SDD 26, con la arquitectura que pidió el operador: daemon PROPIO,
CONFIGURABLE y PEREZOSO. Vivaldi ya trae torrent y termina en una carpeta; acá lo que
baja entra al CAS —un objeto BLAKE3 con la misma identidad que una descarga del
navegador (§6.2) o un `.swm`—, y ésa es la razón por la que esto vale.
página de la extensión → fondo → connectNative → puriy-costura
→ /usr/bin/puriy-costura-torrent add (que LEVANTA el daemon si no está)
→ daemon: librqbit, y al completarse, el CAS
POR QUÉ NO ES UN VERBO MÁS DEL HOST — dos razones, y la primera decide:
1. una descarga tiene que sobrevivir al navegador, y Gecko mata al host cuando se
cierra el puerto (medido hoy);
2. librqbit + tokio + rustls son 226 crates: dentro del host, ese binario —952 K,
compartido por CINCO extensiones— pasaría a ~20 MB y cada iteración de cualquier
función del navegador a un cuarto de hora.
⚠ Que esa pila COMPILA para musl con zig-cc se midió ANTES de decidir, con una receta
desechable: 226 crates y sella. Era una incógnita real —ninguna receta del corpus
había construido tokio+rustls desde tawasuyu— así que la decisión no fue «no se
puede», fue «no ahí». El artefacto del daemon pesa 7,7 M.
PEREZOSO EN LOS DOS SENTIDOS: no hay servicio en la imagen (el binario está y no corre
hasta que hay un torrent; lo levanta su cliente con `setsid`, sin lo cual moriría con
el navegador) y se va solo tras `inactividad_seg` sin nada activo — sembrar cuenta como
actividad.
CONFIGURABLE: TOML opcional; sin fichero anda, y uno ROTO es error. El CAS por defecto
es el del host, con un test que falla si esas raíces se separan.
LO QUE EL GUARDIÁN NO HACE, Y POR QUÉ (está en su cabecera y en el §6.9):
· no usa un `magnet:` sino un `.torrent` servido por HTTP —dar de alta un magnet
BLOQUEA esperando metadata que sin peers no llega: se mediría un timeout y no la
cadena—. El `.torrent` se arma en el propio guardián, en bencode a mano, porque un
binario de prueba en el repo es una dependencia que nadie revisa;
· no pasa por el despacho de protocolos de Gecko: un clic en `magnet:` abre el diálogo
de «¿con qué lo abro?», que en headless no contesta nadie, y eso es una elección del
usuario y no código nuestro. Se abre la página de la extensión —la misma que el
handler abriría— descubriendo su URL base del `dump` de una primera corrida, porque
el UUID lo asigna Gecko por perfil y adivinarlo sería inventar.
El control negativo saca el cliente del daemon de la imagen y exige que el host lo diga
NOMBRANDO lo que falta, en vez de fingir que lo tomó.
⚠ Y sigue sin haber test automático de un transfer REAL entre peers: haría falta un
sembrador y una espera que volverían la suite una que nadie corre. Dicho en el test del
daemon y en el §6.9, para que nadie lo lea como «probado de punta a punta».
La página de la extensión NO valida la forma del origen: la valida el host, que es
quien decide qué le pasa al daemon. Tener esa regla escrita dos veces es tenerla
mintiendo el día que una cambie.
Del §6 quedan el foco (6.5) y la IA local (6.7), ésta bloqueada por algo medido: el
corpus no tiene ninguna receta de LLM ni de embeddings.
MEDIDO sobre `atuq b3:d1a444ad`, `puriy-costura b3:cad5c855` y
`puriy-costura-torrent b3:76afb7a8` (7,8 M):
MAGNET http://…/prueba.torrent
TOMADO prueba-atuq.bin · nuevo · en /salida/hogar/Downloads · id=0
socket del daemon: run/puriy-costura-torrent.sock ← nadie lo arrancó
⚠ Y DOS COSAS QUE EL GUARDIÁN DESTAPÓ, las dos por comprobar el NOMBRE y no sólo que
la respuesta llegara:
1. **la extensión leía claves que el daemon no manda** (`name`/`files`/`bytes` contra
`nombre`/`carpeta`), y el síntoma era «TOMADO — 0 fichero(s), 0 bytes»: parecía un
torrent vacío y era un vocabulario inventado del lado del lector — la misma trampa
que había evitado en el host y no acá;
2. mirándolo apareció que **el socket y la config del daemon estaban en castellano**, y
la regla 7 de tawasuyu nombra explícitamente las claves de configuración entre lo
que se tipea. Corregido allá antes de que llegara a ninguna imagen: un protocolo y
un fichero de config son contrato, y renombrarlos después rompe lo que alguien ya
escribió.
tawasuyu: 4f36f057 (el crate) · 3f69aab2 (lock) · 3b56db26 (el verbo del host) ·
066b3761 (el log del daemon, que faltaba y hacía invisible su único fallo de arranque)
· ca9947b9 (las claves en inglés).
Puerta 1 pasada: PID 1 `arje-zero`, kernel 7.1.2 propio, `/dev/sda3 -> /store` y
`/dev/sda4 -> /var/lib/hammer` montados por etiqueta, IP y salida por `netup`, y se entra por SSH.
Una caja Hetzner sin una línea de Debian debajo. Escribir los 7,1 G comprimidos: ~17 s.
Queda escrito lo que costó, que es lo reusable:
- **El kernel del corpus no sirve para hcloud** (`linux.toml` apaga SCSI; el disco es virtio-SCSI).
`linux-generic` sí, y su `CONFIG_SCSI_VIRTIO=y` no está en la receta: lo pone `defconfig` y sólo se
ve en el `.config` que el artefacto publica. La receta dice lo que se cambió; el `.config` sellado
dice lo que quedó.
- **La hidratación pisa `/sbin/init`** con el de busybox: la imagen habría arrancado perfecta con el
init equivocado.
- **La puerta de enlace de Hetzner está FUERA del prefijo** (IP `/32`, gw `172.31.1.1`). Sin ruta
on-link el default se rechaza y la caja queda con IP y sin salida — arranca, levanta sshd y no se
puede entrar. Nunca había aparecido porque netup sólo se probaba contra el slirp de QEMU, que da
un /24 con la puerta dentro: el único entorno de prueba no contenía el caso.
- **Un binario dentro del `product-rootfs` está congelado**: arreglar netup no llegaba a la imagen
hasta declararlo raíz del perfil.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El ensamblado dejaba de ser reproducible en cuanto se cerraba la terminal: cuatro pasos, tres de
ellos con una trampa que no se ve. Ahora es un script, con las trampas escritas en su cabecera:
1. **El kernel.** `linux.toml` NO sirve para hcloud (apaga SCSI y el disco de Hetzner es virtio-SCSI).
Va `linux-generic`, que sí trae `CONFIG_SCSI_VIRTIO=y` — dato que no está en la receta, lo pone
`make defconfig`, y sólo se ve en el `.config` que el artefacto publica.
2. **El init se pisa.** La clausura del perfil trae busybox y su `/sbin/init` gana por hidratarse
después. El script lo restaura e IMPRIME la reparación (`../bin/busybox → /usr/bin/arje-zero`),
que es la diferencia entre arreglarlo y creer que estaba bien.
3. **EXDEV.** Comprueba con `findmnt` que STORE y WORKDIR estén en el MISMO montaje y aborta con un
mensaje que dice qué hacer, en vez de fallar fichero por fichero a mitad de un `cp -al`.
4. **La clave es obligatoria.** Sin `AUTHKEYS` no arma nada: una instalación remota sin
`authorized_keys` deja una máquina viva e INALCANZABLE, que es peor que una que no arrancó.
Y el cmdline va SIN `init=`, a propósito: así corre el wrapper que escribe `install-image.sh`, que
es quien monta `/store` y `/var/lib/hammer`.
**`netup` entra como raíz de `perfil.servidor`** aunque su binario ya venga dentro del
`product-rootfs`. La razón es concreta y se pagó hoy: el del producto está congelado en el artefacto
sellado del bootstrap, así que el arreglo de la ruta on-link NO llegaba a la imagen. Declarado como
raíz, la hidratación lo proyecta encima y la imagen lleva el vigente — verificado por sha256: la
imagen trae `a23df20e…` y el product-rootfs `a84b0a0d…`.
`recipes/netup.toml` re-pineado a `be383ea4` (el commit del arreglo).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
Medido en la caja `takana` (Hetzner Cloud, hel1) el 2026-09-10. Hetzner entrega la IPv4 así:
inet 2.29.29.217/32 scope global eth0
default via 172.31.1.1 dev eth0
172.31.1.1 dev eth0 scope link <-- ESTA es la que faltaba
La dirección es un /32 y la puerta no pertenece a ninguna red conectada. `add_default_route` mandaba
`RTA_GATEWAY` con scope UNIVERSE y nada más, así que el kernel rechazaba la ruta.
**Y el modo de fallo es el peor**: la máquina arranca, `netup` consigue el lease, se pone la IP,
arje-zero levanta sshd... y no se puede entrar, porque las respuestas no tienen por dónde salir. Un
`ssh` desde fuera da `Connection timed out` y desde dentro no hay nada que se vea roto.
Se agrega `add_onlink_host_route` (dst=/32, scope LINK) y se llama ANTES del default. Es lo que hace
`ip route add <gw> dev <if> scope link`, y es literalmente lo que el propio rescue de Hetzner tiene
en su tabla. No es fatal si falla —un EEXIST no debe tumbar la red—; el default sí lo sigue siendo.
**Control causal**, en un netns con una dummy y una /32:
ip route add default via 172.31.1.1 dev dummy0 => Error: Nexthop has invalid gateway.
ip route add 172.31.1.1 dev dummy0 scope link => ok
ip route add default via 172.31.1.1 dev dummy0 => ACEPTADO
O sea: no es que "ayude", es que era exactamente eso. netup se validaba contra el DHCP de QEMU slirp,
que da un /24 con la puerta dentro — por eso nunca apareció hasta tocar una nube de verdad.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El wrapper que `install-image.sh` escribe como `/sbin/init` monta las dos particiones dedicadas
antes de hacer `exec` del init real, y las nombraba `/dev/vda3` y `/dev/vda4`. Eso vale sólo donde
el disco es virtio-blk. **En una caja Hetzner Cloud la controladora es virtio-SCSI y el disco es
`sda`** (medido: el driver de `sda` es `sd` y `virtio_scsi` está cargado), así que los dos montajes
fallaban.
Y fallaban del peor modo posible: **el sistema arranca igual**. Sólo que `hammerd` —que la semilla
de arje lanza con `--store /store --journal /var/lib/hammer/journal`— queda sin store y sin diario,
con dos líneas de aviso perdidas en el arranque. Es exactamente la regla 3 de CLAUDE.md: un ausente
falla ruidosamente, un vacío llega hasta el final diciendo que todo fue bien.
Ahora el disco se DERIVA de dónde está montada la raíz (`/proc/mounts`), que es la única fuente que
no depende ni del nombre del dispositivo ni de udev. Probado en los dos sentidos con /proc/mounts
sintéticos: `/dev/sda2` → `/dev/sda3`, `/dev/vda2` → `/dev/vda3`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
Dos cosas encontradas armando la primera imagen del `perfil.servidor` (SDD 28 §1b).
**1. `[ -e "$ROOTFS/sbin/init" ]` rechazaba el rootfs CORRECTO y aceptaba el equivocado.** `-e`
sigue el symlink y lo resuelve contra el HOST. El `/sbin/init` del product-rootfs es un symlink
ABSOLUTO a `/usr/bin/arje-zero`, que en el host no existe ⇒ la guarda daba falso. Y al revés: un
rootfs cuyo init es `../bin/busybox` —symlink RELATIVO, que sí resuelve dentro del árbol— la pasaba
sin chistar. O sea que la única guarda que separaba «esto arranca takana» de «esto arranca otra
cosa» estaba exactamente al revés. Ahora acepta `-L`, y se probó en los dos sentidos: acepta el
symlink absoluto a arje-zero, sigue rechazando un directorio sin init.
Esto no es teórico: hidratar `perfil.servidor` sobre el product-rootfs **pisa `/sbin/init`** —
busybox entra en la clausura y su symlink gana por llegar después—. La imagen habría arrancado
perfecto con el init de busybox en vez de arje-zero, que es peor que no arrancar. Se restaura el
symlink al ensamblar y el cmdline lleva `init=/usr/bin/arje-zero` explícito, por las dos puntas.
**2. `STAGE` estaba cableado a `work/.install-stage`.** El staging HARDLINKEA desde `$ROOTFS`, y un
hardlink no cruza un montaje aunque sea el mismo disco. Con el layout normal de este repo —`store`
y `work/out` son bind-mounts de /dev/sdb, `work/` está en /dev/sdc— el rootfs vive del otro lado y
`cp -al` muere con EXDEV fichero por fichero. Ahora es env, documentado en la cabecera.
De paso: el fichero no tenía bit de ejecución (100644) mientras sus siete hermanos son 100755, así
que su propio ejemplo de uso `./scripts/install-image.sh` no funcionaba. Venía de antes; corregido.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
`takana` (id 165447050, cx33, hel1, 2.29.29.217, €8,49/mes). Va sin el label `role=hammer-worker`
a propósito: `farm-down.sh` y `deadman.sh` borran SÓLO lo que lo lleva, así que ninguna
automatización de la granja puede tocarla. Sin protección de borrado, también a propósito: es la
caja de sacrificio.
**`cx53` no se pudo comprar — `Available: no` en las TRES ubicaciones.** Y la disponibilidad cambia
por día: `cx33` daba `no` en hel1 el 09 y `yes` el 10 con la misma consulta. `hcloud server-type
list` devuelve precios de tipos que no se pueden crear ⇒ la recomendación de ayer (cx53 a €29,49)
estaba hecha sobre la tabla de precios, no sobre el stock. Queda escrito para no repetirlo.
**Tres cosas del §3 quedan confirmadas en la caja DESTINO, no inferidas de gioser:**
- Arranca por BIOS (sin `/sys/firmware/efi`) **y aun así la imagen trae un ESP** (`sda15`, 244 M
vfat). ⇒ **una partición EFI presente NO significa arranque EFI**; un instalador que decidiera la
rama mirando particiones elegiría mal justo acá. `takana-live-install.sh` mira lo correcto.
- `console=tty1 console=ttyS0` viene en el cmdline de Debian ⇒ el hueco del serial es real: sin él
la consola web de Hetzner no muestra nada.
- `eth0` con `/32` dinámico por DHCP, idéntico a gioser ⇒ es el caso exacto de `netup`.
Anotado lo que la caja arrastra: 7,6 GiB y CERO swap (misma clase que el `global_oom` de gioser ⇒
no construir pesado ahí) y `sshd` con `PasswordAuthentication yes`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El 6.6 de la unidad 9 del SDD 26. Una navegación de PRIMER NIVEL a un medio
(`Content-Type: video/*` o `audio/*`) se cancela y la URL se la lleva `mpv`, que ya viaja en las
cuatro imágenes de escritorio: esto no agrega ni una receta, es cablear lo que ya estaba.
MEDIO http://…/audio.wav
CANCELADA la navegación http://…/audio.wav
ABIERTO /usr/bin/mpv pid=266 http://…/audio.wav
mpv: AO: [null] 8000Hz mono 1ch u8 ← su propio log: DECODIFICÓ, no sólo arrancó
LA REGLA ES ESTRECHA A PROPÓSITO: sólo el primer nivel. Un `<video>` embebido es parte de la página y
sacarlo de ahí rompería el sitio que lo puso. Las reglas anchas en el camino de cada petición son las
que terminan rompiendo la web de alguien.
FAIL-OPEN, y es lo que prueba el control negativo: cancelar es SÍNCRONO y la respuesta del host llega
después, así que no se puede saber en el momento si el reproductor arrancó. Se cancela sólo con el
puerto vivo y, si el host contesta que no pudo, la URL VUELVE al navegador con una marca para no
entrar en bucle:
SIN REPRODUCTOR no hay reproductor en /usr/bin/mpv: esta imagen no lo trae
VUELVE AL NAVEGADOR http://…/audio.wav?atuq-medios=no
Quedarse sin vídeo Y sin pestaña es el único resultado inaceptable, y es justo el que se consigue si
uno confía en que salió bien.
⚠ EL BUG QUE ESTE GUARDIÁN DESTAPÓ VALE MÁS QUE LA FUNCIÓN, y estaba DESPUÉS del éxito aparente: la
primera corrida detectó el medio, canceló y recibió el pid… y después el puerto murió con «Native
application tried to send a message of 546281442 bytes». **Un hijo hereda los descriptores del padre,
y los del padre SON la tubería de native messaging**: `mpv` escribía su salida ahí y el navegador la
leía como un marco. Arreglado en tawasuyu (`2e99d216`, pineado acá) con tres redirecciones, cada una
contra un fallo distinto — `stdin` a null porque mpv LEE stdin y se comería los mensajes del
navegador; `stdout` al stderr del host y no a `/dev/null`, porque apagarlo arreglaría el bug y se
llevaría puesto el diagnóstico; `stderr` heredado por lo mismo.
Y dos cosas del ARNÉS, las dos ya vistas antes en esta misma sesión:
· la URL NO se pasa por la línea de comandos: una petición del arranque compite con la
inicialización de la extensión (la misma carrera del guardián de `sct`). El guardián navega a una
página que redirige a los 3 s, que además es lo que hace una persona: seguir un enlace;
· la evidencia de que el reproductor CORRIÓ se le pide a su propio `log-file`, porque su salida ya no
va al stdout del host y Gecko no vuelca el stderr del host al del navegador. Sin eso sólo se sabría
que hubo un `spawn`.
Del §6 quedan el foco (6.5), la IA local (6.7) —que además es la que traería el motor que le falta al
archivo del §6.3— y el torrent (6.9). Medido de paso: **el corpus no tiene ninguna receta de LLM ni de
embeddings**, así que 6.7 hoy no se puede pagar.
Medido sobre `atuq b3:a7080058` y `puriy-costura b3:060314e6`.
La unidad 8 del SDD 26 (§6.3), en su mitad pagable. Cada página que se lee se congela: el HTML **ya
ejecutado** —lo que la persona vio, no lo que mandó el servidor— va al CAS con su BLAKE3, y la url,
el título y el texto visible al índice. Después se busca, sin el navegador.
visita 1 (página A) ⇒ archivada, visitas=1, total=1
visita 2 (página A) ⇒ dedup, visitas=2, total=1 ← volver NO duplica
visita 3 (página B) ⇒ total=2
«masa» → 1 de 2 · «tobera» → 1 de 2 · «masa tobera» → 0 · «helicóptero» → 0
LA IDENTIDAD ES EL BLAKE3 DEL HTML, NO LA URL, y de ahí sale lo que hace que esto valga: la misma URL
con otro contenido ES otra página, así que el archivo tiene VERSIONES de lo que leíste. Un historial
de direcciones guarda punteros, y los punteros se pudren.
⚠ LA MITAD QUE NO SE PAGA HOY, dicha en el código, en el LEEME de allá y en el §6.3.bis: preguntarle
al historial en LENGUAJE NATURAL. Eso es el registro semántico y en la suite ya tiene forma —un motor
`rag-motor::RagMotor`, como `willay-rag`—, que necesita un daemon de embeddings y un backend LLM real
y devuelve `None` cuando no están. `archive.search` es el registro LITERAL: todas las palabras tienen
que aparecer. Enseñar lo uno diciendo que es lo otro sería el peor cambio posible.
LO QUE NO SE ARCHIVA ES LA PARTE QUE HAY QUE MIRAR: nada de una ventana privada, nada fuera del marco
principal (un `<iframe>` de publicidad no es una página que alguien leyó) y nada sin texto visible (el
HTML de un visor de PDF llenaría el archivo de cosas que no se encuentran). Y si no se puede saber si
la pestaña es privada, NO se archiva.
⚠ Y EL CONTROL NEGATIVO NO SÓLO COMPRUEBA QUE NO SE ARCHIVE: DICE QUIÉN LO IMPIDIÓ. La respuesta
medida no es la que uno supondría — hoy lo impide **el navegador**, porque las extensiones no corren
en ventanas privadas salvo que se las habilite, así que nuestro `if (incognito) return` no se ejecuta
nunca. No es código muerto: es lo que haría seguro habilitar `private_browsing` el día que haga
falta. Lo que sí habría sido un error es escribir «la extensión no archiva lo privado» sin saber cuál
de las dos cosas estaba pasando.
DOS TECHOS CON NOMBRE (en el host): 4 KiB de texto por página en el índice —es JSON para poder leerse
con `cat`, y uno sin techo deja de poder— y el corte por CARÁCTER y no por byte, porque `truncate`
sobre medio multibyte entra en pánico y en un archivo personal el texto con acentos es el caso normal.
Del lado de tawasuyu (`357791a8`, pineado acá): `archive.add`/`archive.search`, 6 tests nuevos (20 en
total) y el CAS renombrado de `descargas-cas` a `cas` — el mismo almacén guarda ahora lo bajado y lo
leído, y un nombre que describe la mitad de su contenido es el que se lee mal dentro de seis meses.
Medido sobre `atuq b3:5cfe3221` y `puriy-costura b3:c06f55aa`.
La unidad 7 del SDD 26 (§6.2). Cuando una descarga TERMINA, la extensión
`descargas@atuq.tawasuyu` le pasa al host la ruta, el nombre y de dónde salió; el host la ingiere a
un CAS BLAKE3 y contesta el hash, el tamaño y **cuántas veces se bajó ese mismo contenido**. El mismo
contenido con otro nombre es UN objeto y dos nombres, y el navegador lo dice — que es exactamente lo
que ningún navegador sabe hacer: para todos una descarga es un blob con nombre, y por eso la bajás
dos veces y no te enterás.
No es un almacén nuevo: es `arje-cas`, el mismo formato y el mismo hash que usan arje, takana y
tejido. El `<hex>` del CAS ES el `expected_hash` de un `.swm`.
⚠ TRES DECISIONES QUE SALIERON DE MEDIR, NO DE DISEÑAR:
1. **La raíz del CAS de descargas no es la del sistema.** `arje_cas::gc` borra todo blob que no esté
en el set `reachable` de su llamador, y el único que existe (`arje-brain`, `GcCas`) lo arma con la
cadena de audit y las raíces vivas del grafo. Una descarga del usuario no está en ninguno: el
primer GC se la llevaría, en silencio. Van a `<estado>/descargas-cas` — mismo formato (mover un
objeto al CAS del sistema es un `rename`), fuera del alcance del GC de otro. El precio queda
escrito: tejido sirve el CAS por defecto, así que compartir una descarga hoy exige apuntarlo ahí.
2. **El fichero del usuario no se toca**: se copia y se deja donde estaba. El guardián lo comprueba
byte a byte. Borrar o mover lo que alguien acaba de bajar no es decisión de un navegador.
3. **La extensión observa, no intercepta.** Se entera cuando la descarga terminó. Meterse en el medio
obligaría a decidir qué pasa si el CAS falla, y la respuesta correcta —que la descarga siga igual—
es lo que se consigue no metiéndose.
Y EL HALLAZGO QUE COSTÓ LA TARDE, que no es de esta unidad: **en `--headless` el navegador se cae con
SIGSEGV en cuanto una descarga termina.** Se atribuyó con dos controles antes de tocar nada:
--headless, con la extensión → baja el fichero, TERMINADA, Segmentation fault (139)
--headless, SIN la extensión → baja el fichero, Segmentation fault (139) ← no es nuestro
--headless, panel de descargas apagado → Segmentation fault (139)
sway headless (compositor REAL) → baja, INGIERE al CAS, y no se cae ← no es del producto
Sin el primer control esto se leía como «la extensión de descargas rompe el navegador» (perseguir un
bug que no existe); sin el último, como «atuq no puede descargar» (reportar un bug de producto que
tampoco existe). Por eso `scripts/test-atuq-descargas.py` corre sobre sway y no sobre `--headless`, y
por eso lo dice en su cabecera: un arnés distinto al de los demás guardianes, sin explicación, es una
invitación a «simplificarlo» de vuelta al que se cae. Queda en el §6.10.bis del SDD, que es donde vive
lo que atuq NO puede hacer.
El guardián baja de verdad (`Content-Disposition: attachment`, no una llamada a la API) dos veces
dentro de un mismo compositor, y trae control negativo: con OTRO contenido la segunda vez exige
`dedup=false` y dos objetos. Sin él, una sonda que dijera «ya lo tenías» siempre se vería idéntica a
una que funciona.
Del lado de tawasuyu (`ffa939c6`, pineado acá): `cas.ingest`/`cas.list` en el host y
`arje-cas::almacenar_fichero_en` — ingesta en streaming, porque `store` toma `&[u8]` y una ISO de
4 GiB serían 4 GiB de `Vec`. 5 tests nuevos en arje-cas y 5 en puriy-costura.
Y EL BUG QUE EL GUARDIÁN DESTAPÓ, que vale más que la función: **hay un host por PUERTO, no uno por
perfil.** Con `sct` y `descargas` hablando hay dos procesos vivos a la vez, cada uno con su copia en
memoria del estado, y cada uno escribía el fichero ENTERO al guardar: el de descargas borraba el
registro TOFU de `sct` al salir, y el de `sct` revertía el índice de descargas. Los dos contestaban
bien — el daño estaba sólo en el disco. Se vio porque el guardián lee el índice EN DISCO en vez de
creerle a la respuesta: decía `veces=2` y el fichero decía 1. Arreglado en tawasuyu (`55b918e8`,
pineado acá): cada proceso escribe sólo la parte que tocó, y el test que lo fija se comprobó
ROMPIENDO el arreglo a propósito — porque la primera versión de ese test abría los hosts en secuencia
y pasaba con el bug puesto.
La unidad 6 del SDD 26, que es el diferenciador del §6 que no tiene ningún navegador. Cadena entera,
medida de punta a punta con un servidor HTTP real y seis cargas de página:
servidor HTTP → filterResponseData → connectNative → /usr/lib/mozilla/native-messaging-hosts/
→ puriy-costura --state → puriy-sct (TOFU + bitácora)
carga 1-3 (mismo script) fase=learning eventos=0 insignia vacía
carga 4 (mismo script) fase=stable eventos=0 insignia vacía
carga 5 (mismo script, estable) fase=stable eventos=0 insignia vacía ← control
carga 6 (script CAMBIADO) fase=stable eventos=1 insignia "1"
EVENTO ext:…/app.js 0ff4771fb797→f7ccb9fedfbd +27B
La extensión NO hashea ni guarda nada: ve bytes y pregunta. El registro es `puriy-sct`, del otro lado
del cable — duplicarlo en JS habría sido un segundo registro que se desalinea del primero, y el
primero es el que está certificado sin red.
CINCO COSAS QUE SE MIDIERON EN VEZ DE SUPONERSE, y las cinco fallan calladas:
1. el manifiesto va en `/usr/lib/mozilla/native-messaging-hosts/` y NO en el appdir: la ruta sale de
`XRESysNativeManifests`, un `/usr/lib/mozilla` COMPILADO dentro de Gecko;
2. **el manifiesto no puede llevar argumentos** — `NativeMessaging.sys.mjs` hace
`command = manifest.path` y los únicos argumentos son `[ruta-del-manifiesto, id]`. Y sin `--state`
el host corre en MEMORIA: cada arranque volvería a «aprendiendo» y nada alertaría nunca. De ahí el
lanzador `bin/puriy-costura-host`, que además decide la ruta del estado — dónde vive el estado de
un usuario es layout del FHS, o sea asunto de la distro y no del crate;
3. `filterResponseData` y el permiso `webRequestFilterResponse` SÍ están en nuestro `omni.ja`
(se le preguntó al artefacto, no a la documentación de Mozilla);
4. los scripts `inline` NO se ven por esta vía —`filterResponseData` entrega el cuerpo de una
PETICIÓN— y para v1 alcanza: el ataque que sct nombra es la sustitución en el CDN;
5. ⚠ **una carga de página puede producir dos peticiones del mismo documento, y una llega con
`tabId = -1`.** La primera versión agrupaba por `(tabId, documento)` y contaba esa carga como DOS
visitas. No es cosmético: inflar las visitas estabiliza el origen ANTES de conocer su código real,
y entonces alerta por churn legítimo — el falso positivo que la spec de puriy-sct pide evitar por
encima de todo. Ahora agrupa por documento (dos pestañas con la misma url cuentan UNA: es el error
seguro, tarda más en proteger y no alerta de más) y el guardián VIGILA el invariante «una carga,
una visita», así que si vuelve, falla ruidoso.
DOS CORRECCIONES DEL PROPIO §6.1, que decía «consulta al testigo antes de dejarla pasar»: el cable
del testigo es un POST con postcard, así que un JS no puede ser su cliente; y v1 OBSERVA Y AVISA, no
bloquea — es lo que puriy-sct dice de su propia v1, y poner un viaje entre procesos en el camino
crítico de cada script de cada página no es «más seguro», es un navegador que nadie usa.
EL AVISO SE MIDE, NO SE SUPONE: la extensión relee la insignia con `getBadgeText` después de ponerla,
y el guardián exige vacía en las cinco cargas sin novedad y "1" en la del script cambiado. Es la única
parte de la cadena que el usuario ve; dejarla en «se llamó a la API» era dejar sin medir el final.
CONTROL NEGATIVO: `--negative-control` borra el manifiesto y exige que NO haya veredicto — o sea que
el veredicto de la corrida positiva viene del host y no de la extensión inventándolo.
Y el aviso pasivo es decisión, no falta de tiempo: insignia y tooltip, no modal. Un modal por cada
despliegue de un sitio entrena a la gente a cerrarlo sin leer, y entonces el que importa también se
cierra.
Además: `rebrand.py` instala y CRUZA los manifiestos nativos (que el `path` exista y sea ejecutable
dentro del artefacto, y que sus `allowed_extensions` sean extensiones que de verdad empaquetamos), y
de paso se corrige el comentario del §4.ter que repetía la afirmación falsa sobre quién instala las
extensiones — lo mide `scripts/test-atuq-instalacion.py`: instala el escaneo de la carpeta.
`runtime = [..., "puriy-costura"]` en atuq.toml: sin eso la imagen llevaría manifiesto y extensión y
el host NO estaría, y la función se apagaría sola sin una línea de error. `yupana radio` confirma que
llega a las cuatro imágenes de escritorio.
⚠ Límite escrito en `fondo.js`, en el `lib.rs` del host y en los dos LEEME: se hashea el TEXTO ya
decodificado que entrega la extensión, no los bytes que sirvió el servidor. Vale para comparar dos
cargas nuestras; NO es comparable con el hash que publique un tercero sobre los bytes servidos, ni
con el de la v2, que engancha el script loader y ve los bytes reales.
Y una segunda cosa que el guardián encontró y que es del PRODUCTO, no del test: **la página que abre
el navegador al lanzarse puede no ser observada** — compite con la inicialización de la extensión, y
la carrera se gana o se pierde según la corrida. En uso real sólo afecta a esa primera página (después
la extensión ya está escuchando). Por eso las aserciones van sobre la SECUENCIA OBSERVADA y no sobre
un calendario: se exige que ninguna carga se observe dos veces, que la única que puede faltar sea la
del arranque, y que la secuencia aprender→estabilizar→no-alertar→alertar sea la correcta.
Sin regresiones: `test-atuq-politica.py` («guardianes: todos correctos», y sus cinco roturas siguen
matando el build con tres extensiones) y `test-atuq-inicio.py` (la home y la pestaña nueva siguen
siendo las nuestras) pasan sobre el artefacto final `b3:d3ced586`.
Cierra la fila 5 del plan con lo que hay: `puriy-costura` + `shared/foreign-webext` en tawasuyu
(`ebe41e96`, 14 tests) y `recipes/puriy-costura.toml` acá (`b3:3b633431`, verificado como artefacto:
contesta un marco de 4 bytes y hace la promesa del §6.1 completa).
El §7.quater deja tres cosas que no estaban escritas:
· POR QUÉ HACÍA FALTA el host y no se podía atajar: el §6.1 decía que la extensión «consulta al
testigo», y el cable del testigo es un POST con postcard, no JSON — un JS no puede ser su cliente.
Reimplementar el TOFU en la extensión sería el sustituto paralelo que la regla 10 de tawasuyu
prohíbe, además de duplicar la única pieza ya certificada.
· CÓMO SE ELIGIÓ EL NOMBRE, con el grep de la regla 10 hecho ANTES: ningún término del dominio
significaba esto, y los que suenan a mensajero están ocupados por dominios ajenos y grandes
(chasqui = type broker, chaka = puente a COBOL, paloma = correo, tampu = común de objetos). El
nombre salió del título de este propio §7: la costura.
· LOS DOS LÍMITES, que van en el código y en los LEEME y no en una nota de sesión: se hashea el texto
ya decodificado (vale para detectar, no es comparable con el hash de un tercero ni con el de la v2),
y la semilla del log sale del directorio de estado ⇒ a prueba de reescritura, no de suplantación.
Y lo medido para la unidad 6 preguntándole al artefacto: `filterResponseData` y el permiso
`webRequestFilterResponse` SÍ están en nuestro omni.ja ⇒ la extensión podrá leer el cuerpo de un
script. Los inline NO se ven por esa vía, y para v1 está bien: el ataque que sct nombra es la
sustitución en el CDN, o sea el caso `<script src>`.
El binario de «la costura» (SDD 26 §7) entra al corpus: `b3:3b633431`, ELF estático musl de 952 K
pineado a tawasuyu `ebe41e96`. Verificado como artefacto y no sólo como build — un marco de 4 bytes
por stdin y contesta `{"id":1,"ok":true,"verb":"ping","version":"0.1.0"}`; y la promesa del §6.1
entera contra el binario SELLADO: cuatro visitas aprendiendo, a la cuarta `stable`, y en la quinta un
script cambiado ⇒ un evento que nombra el recurso y el delta de tamaño (+6 bytes). Deja
`registro.postcard` y `bitacora.postcard` en el `--state`.
Las dos cosas que costaron, las dos con el mismo patrón (el error no nombra la causa):
1. `cargo vendor --locked` murió con «cannot update the lock file», que NO dice qué crate falta. El
lock de tawasuyu estaba desalineado con su propio `main`, y —esto es lo reutilizable— **un
`Cargo.lock` regenerado en ese clon compartido NO describe su `main`**: ese árbol tiene cientos de
ficheros en vuelo de otras sesiones. El nombre del crate culpable salió de diffear el lock
publicado contra el que resuelve un árbol LIMPIO del commit (`git archive <sha> | tar -x`, que
además no toca el `.git` compartido). Arreglado allá en dos commits; acá se pinea el que cierra.
2. Después murió por el `vendor/` propio del monorepo: tawasuyu parchea `smithay` a mano y lo enchufa
con `[patch.crates-io] path = "vendor/smithay"`. Un patch por RUTA no necesita
`.cargo-checksum.json` —y upstream no lo commitea—, pero `cargo vendor` convierte su directorio de
salida en un directorio de REEMPLAZO DE FUENTE, donde cada crate sí tiene que traerlo. El síntoma
fue 1 de 1699 crates sin checksum y un error que hablaba de `taffy`. La solución ya estaba en el
corpus: `cargo_vendor_dir`, que las otras cinco recetas de este monorepo ya llevan.
⚠ Y la explicación FÁCIL era falsa: «cargo vendor borró el checksum» — `git ls-tree` dice que ese
fichero nunca existió. Queda escrito en la receta para que nadie lo vuelva a deducir.
El precio, medido y anotado: el vendoreo es del workspace ENTERO (2,4 G, 1699 crates, `axum` y
`aws-lc-sys` incluidos) para un host que usa quince deps. Mismo precio que ya pagan las otras cinco.
NO se declara en ningún perfil de `targets.toml` todavía, y NO se agrega el manifiesto de native
messaging a atuq: sin la extensión que lo llame (unidad 6) sería un binario que nadie invoca y un
manifiesto apuntando a una extensión inexistente, que es un fallo silencioso — el navegador arranca
igual y la función no está.
Medido recorriendo los `.service` de D-Bus de TODO el store: los únicos backends de portal sellados
eran los de COSMIC y GNOME. Ninguno de KDE, y la cola `incoming-kde` no tenía ni el frontend.
Consecuencia concreta: la imagen KDE trae `obs-studio` con su plugin linux-pipewire, que captura
pantalla POR EL PORTAL — o sea que en Plasma no tenía con quién hablar mientras en los otros dos
escritorios ese frente estaba cerrado. Sin portal tampoco hay diálogo de fichero ni compartir
pantalla para nada que los use.
Van los DOS paquetes porque la cadena es de tres:
cliente → org.freedesktop.portal.Desktop [frontend] → org.freedesktop.impl.portal.* [backend]
El frontend se copia de la cola de COSMIC y **comparte artefacto**: hash idéntico (ecbe13f68eca6)
desde las dos colas ⇒ un solo directorio en el store, cero builds.
El backend es receta NUEVA, 6.7.2 — la MISMA versión que plasma-workspace, kwin y kscreenlocker de
esta cola, porque habla interfaces privadas de kwin para el ScreenCast y desalinear ahí es pedir que
dos mitades del mismo release se entiendan por casualidad. **Cero frontera nueva**: sus 22
dependencias (Qt6, KF6, KWayland, protocolos de Wayland, xkbcommon) ya estaban todas, verificadas
una por una antes de escribir la receta.
⚠ SIN EL PORTAL DE IMPRESIÓN, y la causa es más honda que el error. El build moría en
`src/print.cpp:27` con `'QtPrintSupport/private/qcups_p.h' file not found`, y la cadena está medida
entera: no hay NINGUNA receta de cups en el catálogo ⇒ qtbase 6.11.1 se construyó sin CUPS ⇒ su
`QtPrintSupport/private/` trae qpaintengine_alpha_p.h y qprintengine_pdf_p.h pero NO qcups_p.h.
No falta una cabecera: falta el subsistema. Un portal de impresión sin con qué imprimir no es
funcionalidad que se pierde, es código muerto que no enlaza.
Upstream no expone `option()` para portales —se compilan todos—, así que el parche va en TRES
sitios y no en uno: la fuente, la instanciación (desktopportal.cpp/.h) y **la lista de interfaces
que el backend ANUNCIA**. El tercero es el que se olvidaría y el que importa: anunciar
`impl.portal.Print` sin implementarlo hace que el frontend enrute a un portal que no contesta, que
es peor que no tenerlo. Cada `sed` lleva su `grep` de verificación al lado, para que el día que
upstream mueva esas líneas el parche falle RUIDOSO en vez de volverse inerte.
VERIFICADO sobre el artefacto sellado: publica `org.freedesktop.impl.portal.desktop.kde.service`,
y su `kde.portal` anuncia 17 interfaces con **0 apariciones de Print** e incluyendo ScreenCast,
Screenshot y RemoteDesktop, que es exactamente lo que OBS necesita. Y sobre el rootfs hidratado:
están el frontend (`org.freedesktop.portal.Desktop.service`), el backend y el `kde.portal`.
⚠ Y la licencia casi la firmo mal: leí la cabecera de UN fichero y generalicé. Contadas las
etiquetas SPDX del árbol entero: 88 `LGPL-2.0-or-later`, 23 de la fórmula de KDE e.V. y 1
`GPL-2.0-or-later`. El binario las enlaza a todas ⇒ la expresión es la CONJUNCIÓN.
El perfil pasa a 98 raíces, 361/361 listo, deuda 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
El README de la receta afirmaba (a) que las extensiones las instala la POLÍTICA porque el
sideloading desde `distribution/extensions/` «ya no funciona», y (b) que el chrome de verdad
—split view— exige entrar a `omni.ja` y escribirlo nosotros. Las dos son falsas, y ninguna
observación del artefacto las distinguía: hubo que romper un mecanismo por vez.
scripts/test-atuq-instalacion.py — tres escenarios:
as-is nada roto ⇒ las dos extensiones puestas
no-policy `policies.json` sin ExtensionSettings ⇒ SIGUEN puestas
policy-only los XPI fuera de la carpeta ⇒ NINGUNA, y la home vuelve a about:home
⇒ instala el ESCANEO de la carpeta; `install_url` con `file://` no instala nada. El §7.bis del
SDD 26 tenía razón. El control es por construcción: la sonda vive en la carpeta y ninguna política
la nombra, así que una corrida muda se declara ROTA en vez de leerse como «no instaló». Y la
segunda señal que probé NO discrimina, queda dicho: el `location` de `extensions.json` sale
`app-profile` también cuando instala la carpeta.
scripts/test-atuq-chrome.py — el chrome se programa desde `atuq.cfg`, sin abrir el zip: observando
`browser-delayed-startup-finished` se toca el `gBrowser` de cada ventana. Y la vista dividida ya la
trae el motor (fx 154) PRENDIDA de fábrica, ejercitada de verdad —`addTabSplitView` ⇒
`activeSplitView` + 2 navegadores—, no «el fichero está». Dos pendientes que eran de upstream.
Control negativo del propio motor: con las pestañas fijadas devuelve null (WRAPPER null, ACTIVA no).
Corolario para lo que venga: cada función del chrome que NO entre a `omni.ja` es una que no pelea
con el orden del `jarlog` del PGO — que es justo lo que tiene al jarlog aparcado.
Queda escrito lo que NO está: ninguno de los `test-atuq-*` corre en el latido (sólo lo hace
`vigia-sonames.py`), y meterlos cuesta ~3 min por ciclo más el rootfs hidratado en el hub.
Medido sobre atuq b3:fab2fbfb → b3:8f6d09c2 (el README entra en el hash: documentar la medición
re-hashea el artefacto medido, y los guardianes se niegan a medir uno que no sea el vigente).
ADR 0016 los listaba entre los CONGELADOS; el usuario pidió descongelarlos al abrir el SDD 28. La
enmienda queda escrita en el propio ADR, que si no la etiqueta deja de describir el hecho.
`hammer-install.sh` → `takana-install.sh`, `hammer-live-install.sh` → `takana-live-install.sh`,
`hammer-banner.txt` → `takana-banner.txt`, `BRIEFING-hammer.md` → `BRIEFING-takana.md`.
**Lo que hacía caro esto no es el nombre del fichero.** El instalador se inyecta en el ISO como
`/usr/bin/hammer-install` y su éxito se detecta con un `grep` de `HAMMER-INSTALL-OK` desde TRES
scripts de prueba. Renombrar un solo lado los deja casando NADA — sin fallar —, que es literalmente
el modo en que `atribuir-fallos.py` quedó mudo cuando el renombre movió el target de `tracing`.
Se renombraron las dos puntas en el mismo commit (`/usr/bin/takana-install`,
`TAKANA-INSTALL-OK/FAIL`, `TAKANA_INSTALL_*`, `work/takana-install.img`, `/run/takana-install`),
se comprobó por `grep` que no quede ningún token viejo fuera del ADR, y —lo que decide— se CORRIÓ
`install-tui-test.sh`: 4/4 casos verdes.
Las tres `TAKANA_INSTALL_*` caen al nombre viejo (`${TAKANA_INSTALL_X:-${HAMMER_INSTALL_X:-}}`):
el llamador puede ser un ISO anterior al renombre. Misma convención que `TAKANA_ROOT_PW` unas
líneas más arriba en ese mismo script.
NO se tocó `/usr/sbin/hammer-recover` ni su hook de arranque —renombrarlo rompe máquinas YA
INSTALADAS, no el repo—: sobrevive intacto dentro del script renombrado, verificado por conteo
antes y después (8 ocurrencias). Tampoco `hammerd`, `hammer-edit` (su `name` está en la ruta del
store), `/var/lib/hammer`, `HAMMER_LIVE` ni los siete literales de hash.
De paso: `scripts/.hammer-banner.txt.kate-swp` era un swap de editor commiteado por error. Fuera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El frente arranca con el inventario MEDIDO de gioser, no con un plan: PID 1 es `arje-zero` (nuestro
init ya gobierna un servidor real, aunque sobre userland Artix), Hetzner Cloud arranca por **BIOS**
—que es justo el layout que `takana-install.sh` ya escribe— y el kernel propio trae VIRTIO/EXT4 `=y`
con `netup` haciendo DHCPv4, que es exactamente el caso de una caja hcloud.
Dos hallazgos que cambian el trabajo:
- **La secuencia de arranque de gioser no está escrita en ningún lado.** `rc-status` dice `stopped`
para caddy, gitea, sshd, cronie y act-runner y los cinco están VIVOS colgando de PID 1. Un
`arje-absorb --from openrc` produciría una Semilla perfecta que no levanta el servidor.
- **La mitad del Caddyfile describe un servidor que ya no existe**: 4 de 19 dominios sin DNS y sin
ficheros en `/var/www`, uno en 502. Una mudanza fiel copia también la basura ⇒ la regla queda
escrita: no se muda lo que no responde.
`[perfil.servidor]` hereda `cli` (SDD 27 §7.1) y declara 5 raíces que existen (openssh, caddy, curl,
wget, tmux) y **5 que NO** (takana, chrony, nftables, cronie, logrotate). Quedan `wanted`, y `wanted`
no es `debt` ⇒ `drenaje.json` seguirá diciendo `deuda=0`. Se declaran igual: sin ellas el perfil
saldría N/N —completo y verde— describiendo un servidor sin hora, sin cortafuegos y sin latido. Es
la lección de `foot` en escritorio-sway, pagada por adelantado. Cuenta esperada: 5, verificada
resolviendo cada nombre contra el campo `name` de las 869 recetas.
La peor de esas cinco: **takana no tiene receta**. El corpus construye 869 y no la suya, así que el
host no puede instalar takana desde el repo de takana — el bloqueante de que el servidor se sirva a
sí mismo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
El usuario preguntó si va a poder ejecutar kate desde mirada o si kate «está para KDE y no se
hereda». La pregunta separa dos cosas que hoy comparten un solo mecanismo: qué CONTIENE un
metapaquete (lo que resolvió el §7.1) y qué PUEDE CORRER en un sistema.
MEDIDO sobre la clausura de kate: son 110 recetas, y lo único que suena a Plasma —kwindowsystem,
plasma-activities, plasma-wayland-protocols— son LIBRERÍAS. No aparece plasmashell, ni kwin, ni
plasma-workspace. O sea que kate necesita Qt6 + KF6 + un compositor, y mirada TIENE compositor: que
hoy no corra ahí no es técnico, es que no está instalado. Coste medido: mirada son 41 nodos, kate
110, ya coinciden 24 ⇒ faltan 86, que es traerse Qt6 y KF6. Ese precio no lo cobra KDE, lo cobra Qt.
Y la distinción YA EXISTE en el repo sin estar nombrada: mpv, atuq, swayimg y libnotify están
declaradas en los CUATRO escritorios —repetidas, no heredadas—, zathura en tres, foot en dos. El
repo ya trata las apps distinto de kwin, sólo que copiando la línea en cada perfil.
Propuesta escrita: que el metapaquete del escritorio sea el ESCRITORIO (shell, compositor, tema,
ajustes) y que las apps salgan a metapaquetes propios instalables desde cualquier sistema, de modo
que `takana install kate` funcione desde mirada sin instalar Plasma. Se lleva bien con el §8: con
vistas montables, «tengo KDE y GNOME y elijo en el greeter» y «uso kate dentro de GNOME» dejan de
ser dos problemas y pasan a ser uno solo — qué clausura se compone para esta sesión.
Cuesta mover ~20 declaraciones de targets.toml y no toca ninguna receta ni ningún artefacto: es
reclasificar, no reconstruir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Paso 1 del SDD 27. Resultó ser UNA LÍNEA POR PERFIL: el mecanismo `hereda` ya existía en
`scripts/targets.py` —transitivo, con detección de ciclos y orden preservado— y `escritorio-sway`
ya lo usaba desde el 2026-08-07. Los otros tres nunca lo declararon, y eso no era una decisión: era
composición no declarada.
LO QUE ARREGLA, medido antes: de los 27 paquetes del perfil `base`, la clausura de escritorio-kde
alcanzaba DOS. Contra el rootfs real: sin `bash`, sin `sudo`/`doas`, sin `git`, sin `useradd`, sin
`gpg` y **sin `dhcpcd`** —o sea sin con qué pedir una IP—; y lo que parecía estar (`ip`, `mount`,
`fsck`) eran applets de busybox (`/sbin/ip → ../bin/busybox`).
DESPUÉS, verificado hidratando de verdad y no leyendo el grafo: en el rootfs aparecen `bash`,
`sudo`, `doas`, `git`, `dhcpcd`, `useradd`, `gpg`, `rg`, `fd`, `bat`, y `/sbin/ip` pasa a ser el
BINARIO de iproute2 en vez del applet.
raíces kde 49→96 · gnome 39→86 · cosmic 43→88
nodos kde 301→356 · gnome 204→256 · cosmic 162→216
deuda 0 en los tres — no hubo que construir NADA, ya estaba todo sellado
colisiones nuevas al hidratar: CERO (los 28 .hammer-tmp son los de gmp/mpfr de antes)
⚠ `escritorio-mirada` NO hereda a propósito: es el rootfs *slim* del USB y sumarle 47 raíces
contradice su razón de ser. Si algún día se quiere, es la misma línea.
`kde-rootfs` en el volumen se rehidrató con la herencia (11 G) para que el nombre canónico no quede
viejo — que es el error que este mismo día costó encontrar en GNOME y COSMIC. El rootfs FUNDIDO y la
imagen siguen siendo los de antes: rehacerlos es un paso aparte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
El usuario señaló que «perfil» suena a preset exclusivo y preguntó lo que hay que preguntar: si no
va a poder instalar KDE, GNOME y mirada a la vez y elegir en un greeter.
MEDIDO, comparando los dos rootfs hidratados que hay en disco (kde-rootfs 78.934 ficheros,
gnome-rootfs 19.955): 14.455 rutas están en LOS DOS, y de ésas **12.766 comparten INODO** — o sea
que son el mismo artefacto del store, no un conflicto. Sólo **1.689 (12 %) colisionan de verdad**.
⇒ Lo que impide instalar dos escritorios NO es el store, que ya los tiene conviviendo: es
proyectarlos al MISMO /usr. Y las colisiones no son misteriosas —libuuid.so.1.3.0, dbus-daemon,
gdbus, gapplication, /etc/dbus-1/*.conf— salen de que cada cola tiene su propia glib y su propio
dbus. Es el mismo cuadro de las dos poppler que targets.toml ya documenta, y el de gmp/mpfr que
dejó 28 .hammer-tmp al hidratar KDE hoy.
Dos caminos, no excluyentes: bajar las colisiones unificando lo duplicado (una glib, un dbus), o no
proyectar a un /usr único — que es literalmente lo que el SDD 18 ya propone («activar un nodo =
montar su composefs como /usr»). Con vistas, las 1.689 dejan de existir por construcción. El
greeter encaja solo: el arranque por grafo del ADR 0010 ya elige qué clausura activar.
Y queda anotado el corolario de orden: el paso 5 del plan (unificar imagen e instalador) construiría
sobre el supuesto de un solo escritorio a la vez. Hay que decidir FHS plano vs vista composefs ANTES
de unificarlos, porque es la diferencia entre «instalás uno» y «instalás los tres».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
PROPUESTA, nada implementado. Escrito a pedido del usuario mientras se tapaba el hueco de upower.
⚠ EL HALLAZGO QUE LO MOTIVA, y es peor de lo que parecía: `targets.toml` ya avisaba que
«kde/gnome/cosmic NO heredan base», pero la consecuencia no estaba escrita en ningún lado. Medida:
**de los 27 paquetes del perfil `base`, la clausura de escritorio-kde alcanza 2**. Y comprobado
contra el rootfs real de la imagen: NO hay `bash`, ni `sudo`/`doas`, ni `git`, ni `useradd`, ni
`gpg`, **ni `dhcpcd`** — o sea que la imagen no sabe pedir una IP. Lo que sí hay (`ip`, `mount`,
`fsck`) son APPLETS DE BUSYBOX: `/sbin/ip → ../bin/busybox`.
O sea que la respuesta a «¿abrir un escritorio es como si base no existiera?» es **sí**. Y la causa
es que hay DOS cosas llamadas base que nadie había distinguido por escrito:
· base de ARRANQUE (`metal-rootfs`): arje-zero + busybox. La imagen la funde. Existe.
· base de USERLAND (`[perfil.base]`): las 27. No la funde nadie.
El documento separa las cuatro capas (piso / escritorio / extras / toolbox CLI), explica que un
«metapaquete» YA EXISTE y se llama perfil, y nombra las tres cosas que le faltan para ser
instalable: herencia entre perfiles, publicación al repo firmado, y un verbo que resuelva una LISTA
y no un paquete.
Y plantea la única decisión que no es de implementación: instalar un escritorio REPRODUCIENDO
(coherente con que el canal no distribuya binarios, pero son horas en la máquina del usuario) o
HIDRATANDO artefactos firmados (segundos, pero es entregar binarios y activa entera la obligación
de licencias que se cerró hoy). La salida propuesta es la del ADR 0014: que existan las dos y que
reproducir sea lo que hace verificable a hidratar.
Nota de nomenclatura, porque el usuario preguntó: `.swm` NO es residuo del renombre — significa
«Software Mutación» y describe lo que el fichero ES. El verbo ya es el correcto, `takana install`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Primero de los dos huecos que dejaban a KDE POR DEBAJO de una instalación estándar. El perfil
declaraba `powerdevil` —el gestor de energía de Plasma— pero no a `upower`, que es con quien
powerdevil habla para leer la batería y aplicar perfiles. Medido: upower sólo existía en la cola de
GNOME, y las colas no se ven entre sí (HERMANO→corpus, nunca de reojo). En un portátil eso es un
escritorio sin indicador de batería, y el arranque no falla ⇒ no se ve hasta usarlo.
Cuesta TRES recetas y no siete, y la diferencia es una perilla: `-Dintrospection=disabled`.
GNOME la necesita ENCENDIDA porque su shell hace `imports.gi.UPowerGlib` desde JavaScript, o sea que
carga el typelib. powerdevil NO: habla D-Bus con `org.freedesktop.UPower`. Apagarla saca de la
frontera gobject-introspection, gi-foreign-girs, glib-introspected y py3-setuptools, que sólo viven
en la cola de GNOME.
⚠ Y NO SE PROMUEVEN AL CORPUS, aunque era lo primero que intenté. Al mover `libgudev` allá su
ArtifactHash CAMBIÓ (7404bc8d → 87ca5e73) y eso no es una mudanza: `glib` existe en las DOS colas y
son recetas distintas, así que desde `incoming-gnome/` se construye contra la glib de GNOME y desde
el corpus contra la del corpus. Promoverla habría arrastrado a GNOME a la glib del corpus — el
cuadro de las «dos glib» que este repo ya pagó caro. Revertido y verificado que vuelve al hash de
antes (7404bc8d), o sea GNOME intacto. Se COPIAN a la cola de KDE.
`udev-pc` sí comparte artefacto (sus deps son sólo pkgconf ⇒ mismo hash desde las dos colas, un
solo directorio en el store). `libgudev` es otro a propósito, por la glib.
VERIFICADO sobre el artefacto sellado, no supuesto: trae `usr/libexec/upowerd`, el
`org.freedesktop.UPower.service` de system-services y su política en `system.d` — que es exactamente
lo que powerdevil necesita para que el demonio arranque por activación D-Bus.
El perfil pasa a 49 raíces, 301/301 listo, deuda 0.
Queda el segundo hueco: KDE no tiene backend de portal (ni `xdg-desktop-portal` en su cola), o sea
que no hay compartir pantalla — y en particular la captura de obs-studio, que la imagen ya trae, no
tiene con quién hablar en Plasma. Eso es más caro: pide traer el portal a la cola y ESCRIBIR
`xdg-desktop-portal-kde`, que no existe como receta en ninguna cola.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Arrancando la imagen KDE recién regenerada, el serial dijo:
"applications.menu" not found in QList("/etc/xdg/menus")
y el escritorio pintó perfecto igual: fondo, panel, reloj, bandeja. Ése es justo el modo de fallo
que este repo persigue — nada falla, simplemente el menú de aplicaciones no tiene qué mostrar.
⚠ Y EL DIAGNÓSTICO OBVIO ERA EL EQUIVOCADO. Lo primero que anoté fue «falta el fichero, hay que
empaquetarlo». **No falta**: `plasma-workspace` instala `/etc/xdg/menus/plasma-applications.menu`
—verificado en el store Y en el rootfs de la imagen, 9904 bytes—. Lo que faltaba es el PREFIJO:
Plasma construye el nombre como `${XDG_MENU_PREFIX}applications.menu`, y sin la variable busca
`applications.menu` a secas, que no existe con ese nombre en NINGUNA distro con Plasma. El error
nombra un fichero que nunca tuvo ese nombre. La etiqueta contra el hecho, otra vez.
El arreglo es una línea. Lo que no era una línea es DÓNDE: los cinco lanzadores de Plasma exportan
`XDG_DATA_DIRS` y ninguno exportaba éste —comprobado uno por uno—, así que arreglar sólo el de QEMU
habría dejado la misma trampa en metal, metal-sw, el anidado y el headless. Es el cable que este
repo ya vio caer cinco veces en `cosecha-cron.sh` y en la frontera del sembrador: arreglar el caso
y dejar la trampa. Van los cinco.
plasma-start-qemu.sh · plasma-start-metal.sh · plasma-start-metal-sw.sh export
nested-plasma.sh · run-plasma-headless.sh --setenv (arman con bwrap)
VERIFICADO, y digo exactamente qué: que el nombre que Plasma construirá con el prefijo EXISTE en la
ruta donde lo busca (`/etc/xdg/menus/plasma-applications.menu` está en el rootfs de la imagen). Lo
que NO está verificado es el menú renderizado — eso pide reconstruir la imagen y arrancarla otra
vez. El `plasma-start` horneado en el rootfs fundido ya se refrescó con el script corregido, así que
la imagen queda a un rebuild de distancia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Misma divergencia que se encontró ayer en GNOME, medida igual: `hydrate-cosmic.sh` nombra 25 raíces
escritas a mano dentro del script, el perfil `escritorio-cosmic` declara 43, y **17 paquetes
declarados no llegaban al rootfs**:
adwaita-cursors · xkeyboard-config · bash · atuq (el navegador) · mpv · swayimg
zathura + zathura-pdf-poppler · dejavu-fonts y dejavu-fonts-nerd · libnotify
desktop-file-utils · hicolor-icon-theme · y las cinco *-shared de runtime
⚠ EL PRIMERO NO ES UNA COINCIDENCIA: `adwaita-cursors` es EXACTAMENTE el ejemplo con el que la
cabecera de `scripts/hydrate-profile.py` advirtió de esto el 2026-09-04 — «se añadió a las raíces de
cosmic y sway, y los scripts de hidratación, que no la conocen, habrían seguido armando un rootfs
sin cursores». No era hipotético: seguía pasando hoy, cinco días después. Y `xkeyboard-config` es la
cicatriz de sway repitiéndose: sin él el compositor arranca sin mapa de teclado.
Y AL REVÉS NO SE PIERDE NADA, que es lo que hace el cambio barato y lo separa del caso GNOME (donde
primero hubo que mover 11 raíces de runtime al perfil): de las 25 del script, la única que el perfil
no declara es `zlib-shared`, y la clausura del perfil la alcanza igual. O sea que el motivo que
justificaba la lista a mano —los componentes que `cosmic-session` lanza por PATH, que ningún grafo
de build ve— YA ESTÁ RESUELTO en el perfil, que los declara todos como raíces. La lista quedó
redundante sin que nadie lo notara.
VERIFICADO HIDRATANDO, no leyendo: `hydrate-profile.py escritorio-cosmic` proyecta 162/162 nodos
(24166 ficheros, 4,8 G) y ahí están los 17. (Ojo con la sonda: `bash` instala en `/bin/bash`, no en
`/usr/bin` — mi primer chequeo lo dio por ausente y era el chequeo el que miraba mal.)
⚠ Y UN DATO QUE MATIZA EL DIAGNÓSTICO Y LO EMPEORA. El rootfs que hay en disco
(`escritorios/cosmic-rootfs`, 3,9 G) SÍ tiene cursores, xkb y mpv — o sea que no se armó con la
lista por defecto, alguien le pasó raíces a mano. Y aun así le falta `atuq`. El problema real no es
que la lista esté mal: es que **lo que llega a la imagen depende de lo que alguien se acuerde de
teclear**. Derivarlo del perfil quita esa variable.
El script se deja porque su cabecera documenta por qué COSMIC necesita raíces de runtime explícitas
—sigue siendo cierto sobre la naturaleza de cosmic-session—; lo que ya no es cierto es que su lista
sea la verdad. Los dos armadores de imagen (qemu y metal) ahora apuntan a `hydrate-profile.py`.
── Y de paso, una nota vieja de targets.toml corregida ────────────────────────────────────────────
Decía que el perfil de KDE «son 13 raíces de ARRANQUE EN METAL, no la imagen completa», con
konsole/kate/dolphin y otras 19 apps selladas y sin declarar. Ya no: hoy son 48 raíces, con esas
apps, las fuentes y las *-shared declaradas — el frente KDE lo reordenó y la nota quedó atrás.
De su cola quedan 8 recetas fuera del perfil y son las que corresponde: libICE, libSM, libXtst y los
cinco eslabones huérfanos de xwayland desde que se retiró su receta.
Lo que a KDE le queda es OTRO problema, también medido hoy: su imagen no se hidrata del perfil sino
de un rootfs YA ARMADO (8,4 G) que nadie re-deriva. De las 18 hojas del perfil están 15 — faltan
`obs-studio` y `atuq`, justo las dos añadidas después de esa hidratación. Re-hidratarlo es decisión
del frente KDE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
El ASCII de densidad (#*+@) queda como fallback para consolas sin color; el
default ahora es MEDIOS BLOQUES: `▀` con color de frente Y de fondo, que mete
dos filas de pixeles por renglon de terminal. Trae la placa obsidiana y la celda
de espacio libre que pide la hoja de marca.
Y las JUNTAS entre teselas, que es lo que faltaba para que se pareciera al
simbolo de verdad: en el SVG las teselas son cuadrados de 100 con 8 de aire. La
tocapu son piezas SEPARADAS, no un bloque macizo, y sin la junta el dibujo se
lee como una mancha. Se apagan solas por debajo de escala 3, donde la junta se
comeria media tesela.
Lo que NO se hace, y va escrito: no se interpola ni se suaviza el gradiente.
El simbolo ES una reticula de cuadrados; difuminarlo seria «recolorear y
deformar», que la propia hoja de marca prohibe. Subir la escala repite pixeles.
Verificado reconstruyendo el dibujo desde los colores que emite el propio ANSI,
no mirando el codigo: sale el martillo con las cuatro tintas y la chispa en el
centro. Las tres formas y --escala=5 corren sin error.
scripts/logo-ascii.py emite la tocapu 7x7 en color (ANSI 24-bit) y en
monocromo. Se DERIVA del SVG en vez de dibujarse a mano: una copia aparte se
desincroniza el dia que la marca cambie y nadie se entera.
Para shuma: su fetch no lleva arte ASCII a proposito —su propio doc explica que
los *fetch clasicos empaquetan el ASCII de trescientas distros y que eso
envejece— pero expone SHUMA_FETCH_LOGO, que toma una IMAGEN.
Y el hallazgo que hay que dejar escrito: NO sirve exportarla desde el perfil de
la shell. shuma absorbe el entorno de la login shell, pero su es_denegada
rechaza todo lo que empiece con SHUMA_, por diseño. La via correcta es su propio
env.json, que aplica los grupos activos al proceso al arrancar.
El icono se instala fuera del repo (~/.local/share/pixmaps/takana.png): una ruta
dentro del arbol se rompe cuando el repo se mueve, que es literalmente lo que
paso hoy con ~/hammer.
GitHub: sergiovelasquezzeballos/hammer -> takana (sigue privado). El segundo
pushurl del origin y el default de espejo-setup.sh actualizados; push real
verificado contra los DOS destinos.
Las dos colas las encontro hammer-4a y las verifique antes de aplicarlas:
1) CINCO scripts hardcodeaban /home/sergio/hammer y hoy funcionaban SOLO por el
symlink que puse al mover. El peor era respaldo-storagebox.sh, cuya RAIZ por
defecto salia de ahi: si alguien limpia el symlink dando el renombre por
cerrado, el RESPALDO apunta a una ruta inexistente. Un respaldo que no
encuentra su raiz no falla ruidosamente — se descubre el dia que lo
necesitas. Ahora apuntan a /mnt/vvv/takana, la ruta real, sin depender de
ningun enlace.
2) Cuatro referencias a gitea.gioser.net/sergio/hammer. El diagnostico del peer
era el correcto y lo comprobe: ese HOST no resuelve, y no por el renombre —
ya estaba mal antes, el remoto real es git.gioser.net. Cambiar solo
hammer->takana las habria dejado igual de rotas. Van a
https://git.gioser.net/sergio/takana, que responde 200.
Se afirmo que la etapa 4 invalidaba el baseline of_tree porque el nombre del
crate va en los simbolos de hammerd. El razonamiento era correcto y la
conclusion no: recipes/hammerd.toml pinea su fuente por COMMIT, no por el arbol
de trabajo, asi que el renombre no la alcanza.
Medido: los cuatro componentes de Stage 1 tienen vigente == sellado
(musl ce952f72, busybox 2a2b1280, hammerd 48bbbe52, arje-zero b34c571b).
No hay nada que rehacer por causa del renombre.
Queda anotado aparte que el of_tree del stage1 sellado hoy (d152f060) no
coincide con ninguna de las dos constantes del script. No se re-ancla: sin
correr el verify in-VM seria poner una constante que nadie verifico, y esta
maquina no tiene KVM.
Rotura que introduje yo al renombrar el repo en gitea, y que no fallaba todavia
porque las tres tienen su artefacto sellado en cache:
git ls-remote sergio/hammer.git -> no responde
git ls-remote sergio/takana.git -> b393687d
hammerd, netup y portal-probe clonan el propio repo por ssh. Cualquier rebuild
de esas tres —o un hub nuevo sin store— habria muerto en el fetch.
El ArtifactHash NO se mueve, y esta comprobado receta por receta antes y despues
del cambio (48bbbe52, 8d093d74, 13ebb33d): la URL es locator y no entra en
hash_inputs, solo el commit (ADR 0013). Por eso mismo el arreglo es gratis.
Tambien el default de GITEA en espejo-setup.sh. git.tawasuyu.net y
git.gioser.net son la MISMA maquina (204.168.193.248), asi que el renombre le
aplica igual.
El espejo de GitHub sigue siendo sergiovelasquezzeballos/hammer: alla el repo no
se renombro. No rompe nada porque el push va por URL explicita, pero queda dicho.
El worker vive en /opt/takana con takana-farm.service, verificado por un ciclo
de build real alla y una cosecha completa aca.
Y queda anotada la recaida: el barrido ad-hoc de este mismo cambio no respeto
el aviso que este fichero tiene arriba y dio vuelta cuatro afirmaciones
HISTORICAS, dejandolo diciendo que a las 18:40 se reinicio takana-farm.service
cuando en ese momento se llamaba hammer-farm.service. Corregidas a mano. La
exclusion hay que ponerla en CADA barrido, no una sola vez.
Renombrado el directorio del worker y la unit, con las tres units del repo
(farm, deadman service y timer). Todas las rutas /opt/hammer del hub pasan a
/opt/takana: eran defaults REMOTE= y HAMMER_DIR=, mas los systemctl/journalctl
que nombraban la unit sin el sufijo .service, que el primer sed no casaba.
Orden, para que no quedara partido: el hub siembra por rsync a una ruta fija,
asi que se saco el cron ANTES de mover. Si se movia el worker con el hub
apuntando a la ruta vieja, la siguiente cosecha recreaba /opt/hammer y quedaban
dos arboles.
Verificado de punta a punta:
- el worker cerro un ciclo de build REAL desde /opt/takana (dunst sellado, 1/1)
- una cosecha completa del hub contra la ruta nueva: siembra, manifiesto, los
nueve grafos, static-audit (691 estaticos, MIENTEN 0) y estado pusheado
- la unit vieja quedo deshabilitada y borrada; /opt tiene una sola entrada
NO se tocan dos referencias a /opt/hammer que siguen siendo CORRECTAS:
docs/23-plan-rehasheo.md describe rutas EMBEBIDAS en artefactos ya construidos
—que literalmente dicen /opt/hammer/work en sus secciones .debug— y el HANDOFF
de la noche de KDE es registro. Cambiarlas haria que los documentos mientan.
Los cuatro bind-mounts desde /mnt/cosecha hacia dentro del arbol eran lo que
hacia imposible un mv a secas, y no estaban previstos. Tampoco que ~/hammer
fuera un symlink que quedaba colgado.
Avisar al otro agente sirvio: hammer-9f aporto dos sitios con la ruta absoluta
fuera del repo que no estaban en el inventario.
Verificado por el ciclo real del cron de las 20:00 desde la ruta nueva, que
ademas pusheo al gitea renombrado. Token de renombre revocado.
El directorio se movio de verdad, asi que las referencias absolutas dentro del
repo ya eran incorrectas. Tambien los ejemplos que usaban ~/hammer.
NO se tocan docs/evidencia/: son REGISTRO de lo que se corrio ese dia, y
reescribir una ruta ahi adentro falsifica la evidencia. Que nombren una ruta que
ya no existe es correcto: existia cuando se midio.
Verificando que las extensiones de la tanda anterior llegaran al rootfs apareció algo bastante peor
que lo que fui a buscar: **`scripts/gnome/hydrate-gnome.sh` no lee `targets.toml`**. Arma el rootfs
desde una lista de 14 raíces escrita a mano dentro del propio script, y de las 28 raíces que el
perfil declaraba sólo DOS coincidían.
MEDIDO recorriendo la clausura de esa lista (123 recetas) contra la membresía del perfil: **21
paquetes declarados en `escritorio-gnome` no llegaban al rootfs hidratado**. No son accesorios —
son las hojas, que es justo lo que un perfil declara porque no es dep de build de nadie:
atuq (el navegador) · foot (la terminal) · helix (el editor) · mpv · swayimg (el visor)
zathura + zathura-pdf-poppler (el lector de PDF) · dejavu-fonts y dejavu-fonts-nerd (las FUENTES)
xdg-desktop-portal-gnome · libnotify · desktop-file-utils
bzip2-shared, expat-shared, libffi-shared, ncurses-shared, xz-shared (las .so que se cazaron el
2026-09-03 recorriendo NEEDED, justamente para que el rootfs no resolviera contra el lab)
y las cuatro de ayer: las tres extensiones y gnome-tweaks
O sea que el trabajo de descubrir que la imagen no tenía terminal, ni editor, ni una sola fuente
—con su análisis largo escrito en este mismo fichero— estaba DECLARADO y no llegaba.
Y la divergencia iba en los dos sentidos: 11 raíces de RUNTIME vivían sólo dentro del script y el
perfil no las conocía (accountsservice, geoclue, libgdm, libgweather, upower, librsvg, ibus, los dos
gi-*-typelibs, gsd-schemas y wireplumber). Sin ellas el shell no arranca: las carga por
`imports.gi.*`, que es invisible para la clausura de deps.
ARREGLO: las 11 se mueven a `targets.toml` con la justificación que el script ya traía bien escrita,
y el script queda marcado como SUPERADO por `scripts/hydrate-profile.py`, que hidrata desde el
perfil — la única declaración que existe. Su propia cabecera ya advertía de este modo de fallo
(«DOS fuentes de verdad para lo mismo, y divergen sin que nada lo diga»); esto es esa advertencia
cumpliéndose. El perfil pasa de 28 a 39 raíces y de 190 a 204 nodos, deuda 0.
VERIFICADO HIDRATANDO DE VERDAD, no leyendo: `hydrate-profile.py escritorio-gnome` proyecta
210/210 nodos (27993 ficheros, 3,5 G) y ahí están las tres extensiones, `gnome-tweaks` con su
módulo `gtweak`, y los tres gschemas en el directorio GLOBAL. Después se corrió el bloque nuevo del
lanzador contra ESE árbol: enumeró las tres, escribió el override y `glib-compile-schemas` salió 0
con stderr vacío.
⚠ DOS COSAS QUE APRENDÍ MIDIENDO Y CONVIENE QUE ESTÉN DICHAS:
1. **El hub NO puede hidratar GNOME hoy.** `gjs`, `gnome-shell` y `spidermonkey` salen «no sellado»
localmente. No es deriva ni un grafo mintiendo: sus hashes vigentes SÍ están en
`work/farm-sellados.txt` — o sea sellados EN EL WORKER — y la cosecha baja el manifiesto y no el
store, a propósito (bajarlo deshacía la poda). `build-state` los cuenta bien porque mira también
el manifiesto; `hydrate-profile.py` mira sólo el disco local. Los dos tienen razón.
2. **EXDEV entre bind-mounts, otra vez.** Hidratar a `work/` o a `work/out` falla con «Invalid
cross-device link» AUNQUE `work/out` esté en el mismo /dev/sdb que el store: son bind-mounts
distintos y `linkat()` no cruza montajes. Hay que hidratar accediendo al store por su montaje
raíz (`--store /mnt/cosecha/store --into /mnt/cosecha/escritorios/…`). El mensaje de error del
script lo dice y aun así me costó dos intentos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
La etapa 6 no es un barrido: son seis despliegues coordinados. Dos hechos
(--takana-bin, y la unit del worker fijando las dos variables, que era lo que
bloqueaba retirar las caidas), dos que conviene esperar, uno atado al baseline
del selfhost, y el directorio del repo que necesita decision porque hay otro
agente trabajando adentro ahora mismo.
Y queda anotada la tabla de las 7 etiquetas de separacion de dominio que el
barrido ancho habria reescrito, con hammer-tree-v1 a la cabeza: es el prefijo
de ArtifactHash::of_tree, o sea los 4750 hashes del store.
Era la ultima superficie de CLI que quedaba con el nombre viejo. Mismo patron
que forja: el canonico es el nuevo, el viejo sigue aceptandose como alias.
El default pasa a .../release/takana.
El DESTINO no se toca: el binario se sigue instalando en /usr/bin/hammer dentro
del rootfs del producto, porque ese rootfs se hashea. Moverlo cambia el hash del
producto y obliga a rehacer el baseline del selfhost — es etapa 6 y decision
aparte, no efecto colateral de renombrar un flag.
Verificado en el subcomando correcto (bootstrap builder, no product): las dos
formas se aceptan. 605 tests en verde.
Lo destapó empaquetar gnome-tweaks: su meson pide `pygobject-3.0 >= 3.46` y resolvió sin receta
nueva, porque `recipes/incoming-gnome/py3-gobject.toml` ES PyGObject 3.50.0 —la escribió el frente
GNOME para el build de libgweather— y publica `pygobject-3.0.pc`.
Esta mañana la firmé `opcional` razonando que sólo la usan los tests de libsecret y modemmanager.
Eso sigue siendo cierto para esas dos recetas, pero el veredicto estaba mal de CATEGORÍA: `opcional`
dice «no la queremos» y el hecho es «ya la tenemos». La diferencia no es cosmética — un `provisto`
realimenta el sembrador como alias y la saca de la frontera; un `opcional` la deja saliendo en cada
barrido.
OCTAVO alias, y estrena la sexta forma de fallar el cruce por nombre: el prefijo `py3-` de nuestro
catálogo contra el nombre de upstream. Las anteriores eran puntuación (nlohmann_json), mayúsculas
(libxfont_2), prefijo lib (gusb), versión en el nombre (glad2) y homonimia cruzada (libmpc/mpc).
Y la lección de método, que es la que vale: el veredicto de esta mañana lo saqué mirando SÓLO a
quién la pedía y por qué. No miré si el catálogo ya la tenía bajo otro nombre — que es justo la
comprobación que la categoría `provisto` existe para hacer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
GNOME deja de ser la cáscara: tres extensiones y la app que el proyecto no instala y todo el mundo
termina instalando. El perfil queda 190/190 con 28 raíces, deuda 0.
dash-to-panel v73 junta dash, ventanas y bandeja en una sola barra (lo que más cambia el uso)
appindicator v64 devuelve los ICONOS DE BANDEJA que GNOME quitó; sin ella las apps que usan
StatusNotifierItem corren y no tienen dónde mostrarse
blur-my-shell v72 (ya estaba; se le saca el override, ver abajo)
gnome-tweaks 46.1 tema, iconos, cursor, tipografías, los botones de minimizar/maximizar que
GNOME esconde, y el interruptor de las extensiones
⚠ LA LISTA DE ACTIVAS SE MUEVE A UN SOLO SITIO, y esto era una bomba de relojería. `enabled-extensions`
es un ARRAY: un override de GSettings lo escribe ENTERO. Con la primera extensión el override vivía
en su receta y funcionaba; con la segunda NO se habrían sumado — ganaría la que compile última
(orden alfabético) y las otras quedarían instaladas y MUERTAS, sin un solo error. Ahora la arma
`scripts/gnome/gnome-start-qemu.sh`, que ya compilaba los esquemas al arrancar, enumerando los uuid
presentes en /usr/share/gnome-shell/extensions. La política es «lo que la imagen instala, se
activa»; el dconf del usuario gana sobre el default.
Una receta NO puede ser ese sitio: hammer exige `[source]` en toda receta («missing field `source`»),
así que no hay forma de escribir una receta de pura política. Se probó el bloque contra un árbol de
juguete: lista las dos extensiones, salta un directorio sin metadata.json, el override compila con
stderr vacío y `gsettings get` devuelve las dos. Y si la lista cambia borra `gschemas.compiled` para
forzar recompilación — sin eso, una imagen ya arrancada ignoraría la extensión nueva en silencio.
⚠ EL HALLAZGO CARO: `msgfmt` de gettext-tiny REVIENTA con las formas plurales del árabe. SIGILL,
exit 132, «index 6 out of bounds for type 'size_t[6]'», y deja un .mo de 0 bytes. Reproducido FUERA
de la receta con el binario sellado. No es el idioma sino el mensaje: blur-my-shell compila su
ar.po sin problema porque no tiene NINGÚN plural (msgstr[5] = 0); el de tweaks tiene exactamente
uno. Acá se saca `ar` del LINGUAS y se pierde la traducción de UNA app, con el diagnóstico escrito
en la receta. ARREGLARLO ES OTRA UNIDAD DE TRABAJO: gettext-tiny la usan 108 recetas.
Cada receta usa el mecanismo de SU upstream, que no es el mismo en las tres:
blur-my-shell `make build` llama a `gnome-extensions pack` —el CLI que nuestro shell apaga— así
que se copia el árbol a mano, con el layout LEÍDO del zip de EGO y comparado
contra él (idéntico, sin sobras ni faltantes)
dash-to-panel su Makefile tiene un `install` que honra DESTDIR y hace lo de un paquete de
distro: gschema y locale a los directorios GLOBALES. ⚠ `VERSION=73` se pasa a
mano porque sin ella el Makefile hace `git describe` y el árbol viene por
`git archive`, sin `.git` ⇒ metadata quedaría con el marcador "version": 9999
appindicator meson. ⚠ `-Dlocal_install=disabled` explícito: en `auto` decide mirando si el uid
es 0, o sea que hoy acierta POR ACCIDENTE — y si el lab dejara de correr como
root instalaría en $HOME/.local y el artefacto sellaría vacío. Y `jq` va en deps
aunque sea JavaScript puro: su meson saca el uuid del metadata.json con jq
⚠ gnome-tweaks NO costó ninguna receta nueva, y eso hubo que medirlo: su meson declara siete deps
mínimas de runtime y las siete ya estaban selladas. La que parecía traer una cadena de Python
entera —`pygobject-3.0`— la provee `py3-gobject`, que YA ESTABA en el corpus con otro nombre y
publica `pygobject-3.0.pc`. El nombre no es el hecho, otra vez.
Sí costó dos deps que el configure reclamó y que son el patrón `.pc Requires` → `[deps].build`:
`appstream` (la pide `libadwaita-1.pc` y el error culpa a libadwaita, que está bien instalada) y
`desktop-file-utils` (meson la busca como PROGRAMA para `update-desktop-database`).
Sus deps de RUNTIME —python3 y py3-gobject— van declaradas: es una app de Python, si no están en la
imagen se instala y no arranca, y ningún build lo delata.
Las cuatro licencias, verificadas en la fuente pineada y NINGUNA leída del COPYING —cuyo apéndice
«How to Apply» trae siempre la frase «or any later version»—: blur-my-shell del README del commit,
dash-to-panel y appindicator de la cabecera de sus fuentes, gnome-tweaks de su etiqueta SPDX.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Medido: esta unit era el UNICO sitio fuera del repo que traia una variable
vieja puesta (Environment=HAMMER_DIR=/opt/hammer), y por eso es lo que impide
retirar la caida del codigo. Ahora fija las dos.
Se ponen las dos y no solo la nueva porque un script viejo —o una copia del
repo que todavia no sincronizo— solo mira HAMMER_DIR.
Desplegada y verificada en dev.gioser.net: daemon-reload + restart, servicio
active, y el entorno del servicio muestra las dos.
205 lineas en 73 ficheros de crates, mas la prosa de CLAUDE.md y del skill,
que se me habian quedado afuera de los barridos anteriores (no eran ni recetas
ni docs/ ni scripts/).
EL BARRIDO ANCHO ESTUVO A UN COMMIT DE ROMPER EL CORPUS ENTERO.
El primer intento reescribia los .rs completos, no solo los comentarios. Entre
las lineas de codigo que tocaba estaban SIETE etiquetas de separacion de
dominio, que son ENTRADA DE HASH:
b"hammer-tree-v1" <- el prefijo de ArtifactHash::of_tree (hash.rs:60)
b"hammer-seed-v1" la funcion que hashea TODOS los artefactos:
b"hammer-stage1-rootfs-v2" cambiarla mueve los 4750 hashes del store
b"hammer-product-rootfs-v3"
b"hammer-product-attested-v2"
b"hammer-builder-rootfs-v1"
b"hammer-attest-dev-rootkey-0001!!" <- clave raiz de atestacion, [u8;32]
Revertido y rehecho solo sobre comentarios, esquivando ademas las cadenas
crudas de Rust (r#"..."#) porque el SYSTEM_PROMPT del traductor tiene lineas
que empiezan como comentario.
Controles: las 7 etiquetas siguen ahi, el diff toca CERO lineas de codigo,
605 tests en verde y el hash de zlib sigue en b3:dc363f26.
La leccion es la misma de toda esta etapa: un literal que parece prosa puede
ser entrada de hash, y la unica forma de saberlo es mirar donde se usa.
5a recetas (1427 comentarios, cero hashes movidos y medido), 5b docs (59),
5c scripts (250, sin tocar una sola linea que no empiece por #).
Los dos guardianes que hicieron trabajo real: la linea base de hashes atrapo 3
recetas que se movian porque un comentario de SHELL dentro de una fase parece un
comentario de TOML; y el salteo de heredocs atrapo 3 MOTD que son texto del
producto, no comentarios.
Y queda anotado el bug que introdujo la etapa 4: atribuir-fallos.py casaba
contra el target de tracing, que es el module_path y por lo tanto el nombre del
crate. Quedo casando nada sin fallar.
250 líneas de comentario en 151 scripts. Control verificado: el diff no toca
NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa.
El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces:
las tres eran el MOTD que el script escribe DENTRO de la imagen construida —
texto del producto, no comentario del script. Se cambiaron aparte y a
propósito, que es rebranding, no limpieza.
Y el hallazgo caro: casaba contra ,
que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate.
La etapa 4 lo movió a y el script quedó casando NADA. No fallaba:
imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado
con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y
tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja.
Además 14 rutas de módulo en docs, que el barrido anterior no tocó
porque no es frontera de palabra.
645 líneas. Los ADR entran porque en este repo SON documentos vivos, no
registros inmutables: el 0013 tiene 5 commits, el 0009 dos. Eso se comprobó
antes de decidir, no se asumió por convención general.
EXCLUIDOS por ser REGISTRO o generado: docs/evidencia/ (6), el HANDOFF de la
noche de KDE (1) y docs/state/ (24, se regenera solo). Reescribir un comando
dentro de una evidencia la falsifica.
Y el ADR 0016 se excluye de todo barrido, con un aviso adentro para el próximo
que barra: habla SOBRE el renombre, así que necesita seguir diciendo 'hammer'.
El barrido se lo llevó puesto y lo dejó titulado 'Renombre del sistema: takana
→ takana'; revertido.
Congelados, verificados uno por uno con controles: /opt/hammer, /var/lib/hammer,
/usr/bin/hammer, /mnt/vvv/hammer, la URL de gitea, hammer-farm.service,
hammer-live-install.sh, BRIEFING-hammer.md, hammerd, hammer-recover y
HAMMER_LIVE.
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash
movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los
ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no
hasheaban de antes).
El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza
con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una
fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL
también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en
hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de
TOML y no entra ahí.
Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales
dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
Con lo que la medición cambió respecto del plan, los dos controles negativos
del helper, y la distinción que importa: la caída sirve al lector NUEVO; donde
el script exporta, hay que seguir poniendo la vieja porque el lector puede ser
un binario viejo.
TAKANA_X con caída a HAMMER_X (ADR 0016). No es un sed: estas variables son
contrato de usuario —knobs del instalador, el entorno del worker, mirror-env.sh—
y viven en perfiles de shell y units FUERA del repo, así que un renombre duro no
falla ruidosamente: la variable no aparece, se toma el default y el build se
comporta distinto sin que nada lo diga.
Rust: takana_core::env::{var,var_os} toma el nombre canónico y deriva el viejo
cambiando el prefijo — se le pasa TAKANA_* para que un grep del nombre nuevo
encuentre todas las lecturas. 5 tests, con DOS controles negativos: sin ninguna
de las dos no hay valor, y un nombre sin prefijo no inventa una caída.
Migrados los 17 sitios directos y los indirectos que el grep no mostraba
(bases_de_mirror, las constantes de kernel_cmd, ROOT_ENV de qorpa, env_path de
recover). takana-recover lleva la caída inline: es un mini-binario que se copia
a /usr/sbin y no vale arrastrarle una dep entera por dos líneas.
Scripts: 30 lecturas pasan a default, manteniendo el
nombre INTERNO de la variable para no tocar sus 190 usos.
Y donde el script EXPORTA en vez de leer, se ponen LAS DOS (mirror-env.sh y el
fragmento in-VM de bootstrap): ahí el lector puede ser un binario viejo —worker
sin recompilar, el /usr/bin/hammer pinado del baseline— que sólo conoce HAMMER_*.
La caída sirve para lectores nuevos; los viejos necesitan que la vieja siga puesta.
Verificado de punta a punta con el binario, no sólo con unit tests: HAMMER_LAB
sigue surtiendo efecto, TAKANA_LAB hace lo mismo, y con las dos gana TAKANA_LAB.
605 tests en verde y el hash de zlib sigue en b3:dc363f26… , intacto.
Cambio de comportamiento que va aparte y hay que decir: el hostname por defecto
de una instalación nueva pasa de 'hammer' a 'takana' (sólo si no se fija ninguna
de las dos variables).
NO se tocan: las rutas /var/lib/hammer de sistemas instalados, el volid
HAMMER_LIVE del ISO, ni el namespace HARKAQ_*, que es de otro subsistema.
La imagen de GNOME traía la CÁSCARA: el shell sabe cargar extensiones —`ui/extensionSystem.js` va
en el gresource sin opción que lo apague y su gschema sellado trae `enabled-extensions`— pero no
había ninguna que cargar. Esta es la primera, y fija el patrón para las otras ~1400.
⚠ NO HIZO FALTA TLS, que era la conclusión fácil del análisis de ayer. glib-networking sólo lo pide
BAJARLAS desde extensions.gnome.org con el descargador del shell. Empaquetada, una extensión se
instala como cualquier receta y no toca la red.
LA FUENTE ES EL REPO DEL AUTOR, NO EL ZIP DE EGO, por dos razones y las dos medidas:
1. hammer no sabe abrir un zip: el fetch extrae con `tar -x` y GNU tar contesta «This does not
look like a tar archive». Ninguna receta del corpus usa .zip.
2. Y aunque lo abriera, el zip de EGO es un ARTEFACTO que construye EGO desde este mismo repo.
Pinear el zip es pinear el binario de un tercero; pinear el commit es pinear el código.
El tag v72 es el que EGO sirve para shell 48 —preguntado a su API, no supuesto— y el metadata.json
declara ['46','47','48','49','50']. ⚠ Eso hay que preguntarlo por extensión: nixpkgs va por GNOME
50 y hay extensiones que ya sólo declaran el major nuevo.
SIN `gnome-extensions pack`, que es lo que usa el Makefile de upstream y es el CLI que nuestra
receta del shell apaga (-Dextensions_tool=false; encenderlo costaría gnome-autoar y re-hashear
gnome-shell entero). No hace falta: `pack` sólo arma un zip que después alguien descomprime, y lo
que el shell lee es un DIRECTORIO. El layout no se inventó — se leyó del zip de EGO v72, que es la
salida de ese mismo `pack`, y el artefacto sellado se comparó contra él: **entradas idénticas, ni
sobras ni faltantes**, 45 .mo compilados.
⚠ INSTALADA ≠ ACTIVA, y esto es lo que hace que la receta sirva. El shell sólo carga lo que esté en
`org.gnome.shell enabled-extensions`: sin eso el artefacto sella, el fichero está en la imagen y NO
PASA NADA al arrancar — el mismo cuadro de «sellado ≠ instalado» que este repo ya se comió con
foot, mpv y libnotify, un escalón más abajo. Se resuelve con un override de GSettings, que cambia
el DEFAULT y deja ganar al dconf del usuario que no la quiera.
PROBADO DE VERDAD, no deducido: se compiló el directorio de esquemas del shell con el override
puesto (`glib-compile-schemas`, exit 0 y stderr vacío — que hay que mirar, porque sale 0 aunque
RECHACE un esquema) y después `gsettings get org.gnome.shell enabled-extensions` devolvió
['blur-my-shell@aunetx'].
⚠ TRAMPA ANOTADA PARA LA SEGUNDA: `enabled-extensions` es un ARRAY y el override lo escribe ENTERO.
Dos recetas con su propio override no se suman — gana la que compile última y la otra queda
instalada y muerta, sin error. Cuando llegue la segunda, la lista pasa a un solo sitio.
Y una corrección sobre la licencia, que casi firmo mal: el LICENSE es el texto del GPLv3, y su
apéndice «How to Apply» CONTIENE la frase «either version 3 … or any later version» siempre, así
que grepearla ahí no distingue -only de -or-later (la trampa que la memoria del repo ya tenía
escrita). La evidencia buena es el README del commit pineado: «This program is distributed under
the terms of the GNU General Public License, version 3 or later». El árbol JS no lleva cabecera de
licencia en ningún fichero.
Va de RAÍZ en escritorio-gnome por la lección de `foot` que targets.toml ya aprendió tres veces.
El perfil queda 183/183 listo con 25 raíces, deuda 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Decisión del usuario (2026-09-09): X11 se erradica, y eso incluye no construir el servidor que lo
mantiene vivo. La receta se retira; `xwayland` VUELVE a ser lo que sus propios documentos decían.
⚠ LO QUE APARECIÓ AL MIRAR: esto ya estaba decidido, por escrito y DOS VECES, el 2026-09-03
(commit f64859ba):
docs/state/targets.toml:143 «`xwayland` sigue acá como RAÍZ pero su receta NO se va a escribir:
lo provee una imagen ajena enjaulada … el hueco se disuelve sin
receta y sin tocar la postura Wayland-only»
docs/state/qorpa-ajenos.toml «X11 está fuera de alcance para toda la distro … el Xwayland vive
DENTRO de la imagen —Arch y Fedora ya lo traen— y se cuelga de
nuestro kwin por el socket. La receta no se escribe.»
El 2026-09-08 se escribió igual (3d8c6fc6, «cerrar los 3 huecos que quedaban»), y los dos
documentos siguieron diciendo lo contrario durante toda la jornada de hoy. No hubo que cambiar
ninguno de los dos: alcanzó con borrar la receta para que el repo volviera a coincidir con ellos.
MEDIDO ANTES DE SACARLA, no supuesto:
· Sólo kwin podía lanzarlo. mutter va con -Dxwayland=false y wlroots con -Dxwayland=disabled ⇒
GNOME, sway y COSMIC no podían usarlo aunque el binario existiera. Nunca sirvió a más de un
perfil de los cuatro.
· NINGUNA app del catálogo necesita servidor X: todo lo gráfico es Wayland nativo (Qt6 con
qtwayland, GTK3 Wayland-only, mpv, OBS con ENABLE_WAYLAND=ON, foot, fuzzel, swayimg). El
consumidor que lo justificaba está nombrado en qorpa-ajenos.toml y es Steam, que corre
enjaulado y TRAE EL SUYO ADENTRO.
· Y la imagen KDE ya arrancaba sin él: la propia receta contaba que KDE sellaba 1037/1037 con las
apps X11 muertas. Esto no estrena una configuración, vuelve a una ya probada.
EFECTO EN EL GRAFO, verificado regenerando: `xwayland` deja de ser una receta y pasa a clase
`ajeno` —que es como targets.toml decía que había que contarlo— y el perfil escritorio-kde baja de
304 a 299 nodos con deuda 0. Los cinco que se van son la cadena que sólo él usaba.
⚠ QUEDAN CINCO RECETAS HUÉRFANAS, y no las borro de paso: `libfontenc`, `libXfont2`, `libxkbfile`,
`libxshmfence` y `xkbcomp`. Medido: NADA más en el catálogo las declara, y ninguna es raíz de
ningún perfil ⇒ siguen selladas pero no entran en ninguna imagen. Sacarlas es su propia unidad de
trabajo y su propia decisión.
El triaje pasa de `provisto` a `opcional` con la historia entera en su `porque`, y con eso se cae
el alias `xwayland xwayland` de alias-triaje.txt, que habría afirmado que tenemos una receta con
ese nombre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
Sergio