548 Commits

Include renames

Author	SHA1	Message	Date
Sergio	01e721db84	verificar-repro: decir que además es el CENSO de la deuda invisible, con el número medido ... `no construyó` no es ruido del verificador: es EL hallazgo. Un `sealed` en el grafo dice que alguien construyó eso alguna vez con algún lab, no que se construya hoy — y el lab rueda desde Alpine edge. Este script es lo único que convierte esa sospecha en un número SIN RIESGO, porque aparta en vez de borrar y restaura si el build falla. Barriendo las 15 recetas CMake baratas del corpus: REPRODUCEN 9 · DERIVA 1 · no construyeron 5. Cinco selladas y rotas a la vez, todas por el mismo crash del lld de zig con `--dependency-file`. Y la nota de método que hace legible el censo: barrer por FAMILIA de sistema de build. Si el fallo es del toolchain se concentra en una familia y el patrón salta; barrer al azar lo diluye.	2026-09-12 11:21:34 +00:00
Sergio	eb85c5976e	latido: el vigía de servicios entra al cron — 18 demonios se embarcan y nadie los arranca ... Contesta la pregunta que ni el grafo ni `vigia-sonames` contestan: no «¿está sellado?» ni «¿arranca el binario?» sino **«¿hay alguien que lo LEVANTE?»**. Un demonio puede estar sellado, con contenido, con todos sus sonames resueltos, y que ninguna imagen lo arranque nunca. Va al latido por la lección que `vigia-sonames` ya dejó escrita doce líneas más arriba —un vigía que hay que acordarse de invocar no se distingue de no tenerlo— y con más motivo: su entrada son DOS ficheros que cambian por separado (las recetas y `targets.toml`), así que la divergencia entre «declarado» y «habilitado» aparece sola, sin que nadie toque el vigía. Corre PRIMERO su propio `--selftest`: si el guardián está roto, su silencio no es una respuesta. Primera lectura, ya en el repo: 0 errores y 18 avisos. El más ruidoso es `dbus-system`, que viaja en SEIS perfiles y sólo GNOME lo arranca.	2026-09-12 11:13:12 +00:00
Sergio	1b56b16402	SDD 30 §4a+§4c: los 9 demonios de GNOME declarados — y aparecieron dos que no estaban en NINGÚN perfil ... Lo que el script de sesión lanza con `&` ahora está declarado en las recetas y habilitado en el perfil. Ninguna receta movió su hash: 9/9 idénticos a los que los grafos ya registraban. EL HALLAZGO, y no lo buscaba: la comprobación inversa del resolutor rechazó `arje-logind-compat` y `arje-polkit-compat` porque están en CERO perfiles — y sin embargo qemu-desktop-image.sh los copia al rootfs a mano y el de COSMIC hace `exit 1` si falta logind-compat. Dos binarios imprescindibles, presentes en la imagen y ausentes del destino declarado: la misma forma del agujero de `foot`, encontrada por una comprobación en vez de por una imagen inusable. Son raíces de escritorio-gnome (los dos) y de escritorio-cosmic (sólo logind, verificado que sus scripts no nombran polkit). DOS COSAS QUE NO SON TRANSCRIPCIÓN: - `dbus-daemon --fork` no se traduce tal cual: arje supervisa al HIJO DIRECTO y Type=forking no existe, así que un daemon que forkea y sale deja a arje viendo morir al padre con éxito y reencarnándolo para siempre. La card usa --nofork. - `scope = system|session` decide DÓNDE va la card. Las de sesión necesitan XDG_RUNTIME_DIR y usuario logueado; en el genesis arrancarían antes de que exista ninguno. Y fuera de mirada NADIE entrega cards de sesión todavía, así que salen con AVISO: el hueco queda contado, no omitido. Correcciones propias: la unicidad del label es DENTRO del perfil, no del corpus (upower vive legítimamente en dos colas); la membresía se lee de los CINCO grafos, no sólo el del corpus; una RAÍZ manda sobre el grafo, que es derivado y lo regenera el cron; y la flag nace en inglés (`--services`) como manda la regla 4, aunque `--lista` sea deuda vieja del mismo fichero. `--selftest`: 7 casos, el primero es el CONTROL que tiene que pasar en verde.	2026-09-12 11:08:58 +00:00
SergioandClaude Opus 5	0b5dae7812	censar: 26 repositorios existen SÓLO en la máquina que se va a borrar — el paso 1 del plan ... Buscando cómo escribir la receta de `tawasuyu` apareció que su ÚNICO remoto es el gitea de gioser (`ssh://gitea@git.tawasuyu.net:2345/…`, y ese nombre resuelve a 204.168.193.248 = gioser). Al mirar el resto: **28 repositorios con remoto en esta máquina, 26 SIN NINGUNA copia fuera**. Sólo `takana` y `llimphi-standalone` tienen espejo externo. Apagar el origen no borra unos servicios: borra EL CÓDIGO CON EL QUE SE VOLVERÍAN A CONSTRUIR, y los clones de trabajo están en el mismo disco que también muere. Entre los 26 está `tawasuyu`, que produce 10 de los 13 binarios que nadie más provee — la dependencia circular completa. No se ve desde ninguna otra parte del censo: un repo no es un proceso, ni un puerto, ni un dominio. Se descubre cuando ya no hay de dónde sacarlo. · `censar.py` lo mira ahora (`[[repo]]`), y reporta NO «tiene remoto» sino si alguno de sus remotos NO es esta máquina: un remoto que apunta afuera es la prueba de que el código sobrevive. La lista de «esta máquina» sale del censo mismo (sus IPs + los dominios que sirve), no de nombres cableados. · `planear.py` lo emite como PASO 1, por delante del rescate de binarios: aquello pierde un servicio, esto pierde la posibilidad de reconstruirlo. El arreglo ya está escrito en el repo —takana usa `pushurl` doble por `scripts/espejo-setup.sh`. Y una corrección de algo que dije antes: la perilla por receta que vi en `recipe.rs` es `strip_debug`, no una versión de rust. NO existe `rust_version`; sólo `zig_version`. Pinear rustc por receta para honrar el `rust-toolchain.toml` de tawasuyu (1.96.0, contra 1.97.0 del lab) sería código nuevo en takana-core, no una opción ya disponible. De paso, medido el subárbol de los diez binarios por separado: cuatro (`willay-daemon`, `sandokan-seguridad-core`, `pacha-secretos`, `tupu-cli`, entre 84 y 153 deps) NO arrastran criptografía en C; cuatro traen `ring` y dos `aws-lc-sys`. O sea que hay un escalón por donde empezar sin pelear con cmake. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 11:06:52 +00:00
Sergio	556fcad5fa	SDD 30 §4a: el perfil ya sabe HABILITAR — y avisa del demonio que nadie arranca ... `paquetes` decía qué se INSTALA; no había dónde decir qué se LEVANTA. El sshd del producto arrancaba porque su Card estaba escrita a mano en una constante de Rust, no porque nadie lo hubiera declarado. `servicios = [...]` por perfil (se hereda como `paquetes`, mismo orden y dedup) + `targets.py --servicios <perfil>`, que cruza label → receta → exec contra los `[[service]]` del corpus y la membresía de perfil de build-state.json. Lo que vale más es la comprobación INVERSA: avisa de los paquetes que están en la imagen, TRAEN un demonio y el perfil no arranca. Es la versión servicios de la lección de `foot` —la métrica mide la clausura de lo DECLARADO y no ve lo que falta en la declaración— y no es hipotética: antes de escribir `servicios = ["sshd"]` el resolutor ya avisaba «openssh está en la imagen y TRAE este servicio, pero el perfil no lo arranca». Probado con roturas A PROPÓSITO, 5/5, y con un control que TIENE que pasar: habilitado sin declarar (ERROR) · dos recetas con el mismo label (ERROR) · lo declara una receta que no está en el perfil (ERROR: el card apuntaría a un binario ausente y arje lo encarnaría con ENOENT en cada backoff) · la inversa (AVISO, no rompe el cron) · el caso bueno (rc=0). Los 8 perfiles siguen expandiendo igual y los llamadores de shell no cambian.	2026-09-12 10:59:59 +00:00
Sergio	29831e6296	descargas: el guardián estaba ROJO hace dos días y nadie lo corría ... La barrida de regresión del frente (14 guardianes tras rehacer host y navegador) encontró uno en rojo: `test-atuq-descargas.py` buscaba el CAS en `<estado>/descargas-cas` y el host lo escribe en `<estado>/cas` desde el commit del archivo personal (357791a85, 2026-09-10) — el §6.3 UNIFICÓ los dos CAS, que es justo lo que hace que una página archivada y un fichero bajado con el mismo contenido sean un solo objeto. Lo renombré yo y no actualicé este guardián. Lo que importa no es el renombre: es que el guardián estuvo rojo dos días sin que nadie se enterara, porque **un guardián que no se ejecuta no protege de nada** — la misma familia que el cache-hit que congela regresiones. Los otros 13 pasan. Arreglado el path, y el README dice ahora por qué el directorio se llama `cas` y no `descargas-cas`.	2026-09-12 10:51:10 +00:00
SergioandClaude Opus 5	6187c83c36	planear: metalog NO APLICA — el destino trae su propio journal ... Un demonio de syslog no se muda a un sistema que ya tiene journal propio: la semilla de arje declara `provides: ["Spawn", "Journal"]` (crates/takana-bootstrap/src/lib.rs:185) y existe el crate `takana-journal`. Mismo razonamiento que dbus/udev/elogind, que ya estaban en NO_APLICA: no es gusto, es que el destino provee la función. Vale para metalog, syslogd, syslog-ng, rsyslogd, socklog y busybox-syslogd. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 10:26:52 +00:00
Sergio	76fc142244	verificar-repro: activar el mirror — el veredicto dependía de la suerte del caché ... Medido hoy: `ia-modelo-embeddings` dio REPRODUCE y `ia-modelo-chat` «no construyó», y la ÚNICA diferencia entre las dos era que el tar de la primera seguía en `work/tarballs` y el de la segunda lo había borrado yo liberando disco. Sin caché, el build sale a buscar la fuente a una URL `.invalid` —que es lo que el ADR 0013 pone a propósito cuando el objeto vive sólo en nuestro mirror— y muere con `Could not resolve host`. O sea que el gate informaba «no construyó» para `firefox-pgo-profile` y los dos modelos de IA según qué hubiera en el caché local. Un guardián cuyo veredicto depende de eso no es un guardián. Ahora hace `source` de `scripts/fuentes/mirror-env.sh` si existe. Aditivo, como manda el ADR 0013: si el fichero no está, todo sigue igual que antes. Con eso, ia-modelo-chat: REPRODUCE.	2026-09-12 05:04:43 +00:00
Sergio	4a28013316	atuq §6.3: la búsqueda semántica, VERDE en la jaula — y la barra lateral tiene las dos preguntas ... Los cuatro guardianes pasan sobre los artefactos sellados (atuq bfc14c92, puriy-costura 3f31233e, ia-modelo-embeddings 2c0c4258): semántico 0.6252 gato / 0.2471 red / 0.0973 pan → y la otra pregunta gana la otra página control «no hay modelo de embeddings en …» y NINGÚN orden inventado ia el modelo contesta y el motor se va con el navegador (0 vivos) foco los tres estados, y el estado intacto tras la sesión La barra lateral ahora tiene dos botones: «Al modelo» (genera texto) y «A mis páginas» (ordena lo que ya leíste). No se mezclan a propósito — una inventa y la otra recuerda, y juntas sería imposible saber cuál contestó. Los resultados van EN ORDEN y sin porcentaje: el puntaje es un coseno y leerlo como «85 % de acierto» sería inventarle un significado. ⚠ Y el guardián nació midiendo NADA: metía las tres páginas en `<iframe>` y archivó cero, porque el §6.3 ignora lo que no es marco principal. Encadenadas como navegación de verdad entran las tres; y las páginas de tránsito van sin texto visible para que el archivo las descarte y la evidencia no liste coincidencias sin título. Dos cosas más del camino, las dos medidas: el `cp` del install buscaba el nombre de upstream y el tar —nuestro— lleva el fichero con nombre corto; y el build murió dos veces por DISCO LLENO (0 bytes en /mnt/vvv), no por el lock. `scripts/poda-fuentes.sh --horas 6` liberó 4,6 G, que es exactamente para lo que existe.	2026-09-12 04:25:35 +00:00
SergioandClaude Opus 5	f2bffd9e4b	planear: cruzar la config contra las decisiones — y los puertos se adjudicaban por NOMBRE ... La config del servidor declara de qué servicios depende: cada `reverse_proxy` y cada `php_fastcgi` apuntan a algo. Cruzarlo contra la decisión tomada sobre cada servicio caza un fallo que ninguna otra parte ve: **el dominio se MUDA y el servicio que lo sirve está marcado MUERE**. Las dos decisiones son razonables por separado y juntas dejan el sitio nuevo devolviendo 502 — no lo ve el DNS, no lo ven los procesos, y no lo ve quien decide de a una entrada por vez, que es como se decide. En gioser apareció el revés: dos sitios proxean a un puerto que NINGÚN servicio censado sirve, o sea que ya devuelven 502 hoy, en el origen — `mail.sigma.gioser.net` → :9000 y `api.gioser.net` → :8000. Confirmado aparte con `ss -lntp`: no hay nada escuchando en ninguno de los dos. **Y un falso positivo que hubo que matar primero.** La primera corrida acusaba a `sergio.gioser.net` de mudarse dejando atrás a `shuma`. Falso, y la causa estaba en el CENSO: los puertos se adjudicaban por prefijo de nombre (`proc.startswith(name[:15])`), así que un `shuma` DECLARADO-MUERTO se quedaba con el 7378 — que lo escucha `shuma-gateway` (pid 294, verificado con `ss -lntp`). Un declarado-muerto por definición no puede estar escuchando. Ahora se atan por PID, que es lo único sin ambigüedad, con caída al nombre sólo para servicios VIVOS cuando `ss` no da el pid. El puerto es la señal más fuerte de que algo sirve, así que colgárselo al servicio equivocado envenena todo lo que se derive de él — acá se derivó un guardián acusando al inocente, que es la forma más rápida de que un guardián se deje de leer. De paso, el lector de Caddy entiende `php_fastcgi` (antes caía en «directiva no reconocida») y registra a dónde proxea cada sitio, incluidos los bloques anidados. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 03:03:49 +00:00
SergioandClaude Opus 5	053e5e7edf	planear: buscar la receta por el PAQUETE del origen — y el intérprete no es el programa ... `origen_binario` buscaba la receta por el nombre del SERVICIO, y ése casi nunca es el nombre del paquete: `sshd` lo trae `openssh`, `crond` lo trae `cronie`. El censo ya le preguntó al gestor de paquetes quién posee cada binario, así que ese nombre también se prueba. El perfil pasó de 4 recetas a 7, y los 27 servicios quedan: receta-takana 9 · suelto 9 · paquete-ajeno 13 · interprete 4 · borrado 4. **La trampa, que es la que haría mentir al perfil.** `openclaw` lo posee el paquete `nodejs`; `fail2ban-server`, `glances` y `uvicorn` los posee `python`. Contarlos como cubiertos porque existe `recipes/nodejs.toml` haría salir el perfil N/N describiendo un servidor al que le faltan CUATRO programas. Tienen clase propia (`interprete`) y cuentan las DOS cosas a la vez, porque las dos son ciertas: su runtime entra al perfil —`openclaw` necesita `nodejs` en la imagen pase lo que pase— y el servicio sigue listado como NO cubierto. Meterlo sólo en las raíces miente; dejarlo sólo en los faltantes arma una imagen sin runtime y el programa, cuando llegue, no arranca. Y el paquete del origen no se llama igual que la receta ni para el mismo intérprete: Artix empaqueta `python` y el catálogo tiene `python3.toml`. Sin ese alias tres servicios decían «hace falta una receta takana» teniendo el runtime sellado — dos trabajos muy distintos. **Sellada y sin sellar tampoco son lo mismo**, y el perfil las listaba igual: una sellada se INSTALA del repo firmado, una sin sellar hay que CONSTRUIRLA. Salió con un caso real — `recipes/qdrant.toml` entró al catálogo desde otro frente mientras se escribía esto y no tiene artefacto. Ahora se marca en la línea y se resume al pie. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 02:37:10 +00:00
Sergio	fb3a326dfd	latido: los dos vigías nuevos entran al cron — un guardián que hay que acordarse de invocar no existe ... `vigia-subcomandos.py` y `hydrate-profile.py --auditar-raices` nacieron ayer encontrando cosas reales: 46 binarios sellados que no se pueden invocar por falta de driver, y 4 comandos de `bzip2` apuntando a `/out/usr/bin/…`. **Las dos las encontré a mano, y eso no se repite solo.** El argumento ya estaba escrito tres líneas más abajo en este mismo fichero, al lado de `vigia-sonames`, y costó caro: nadie lo corría, así que `libstdc++.so.6` —que rompía el navegador en los CUATRO perfiles— estuvo en su salida meses sin que nadie la leyera. Van FUERA de la puerta diaria porque son baratos: **4 s y 22 s** medidos. Dentro del `if` del sello correrían una vez al día sin motivo. ⚠ **Y la primera versión de este commit los metió DENTRO de la puerta**, justo lo contrario de lo que decía su propio comentario — el ciclo de prueba no imprimió ni una línea de ellos y así se vio. Por eso se corre el ciclo de verdad antes de dar por bueno un cablazo al cron: un bloque mal colocado en un script desatendido no avisa, simplemente no pasa nada. Dejan fichero en `docs/state/` con la FECHA DE MEDICIÓN por delante, por la misma razón que el static-audit: con el frente en verde el texto es constante, `git diff --cached --quiet` no vería cambio, y dentro de tres meses el fichero sería indistinguible de uno rancio. Con la fecha, cada ciclo deja huella en el `git log` — se ve que el vigía sigue VIVO, no sólo que el último veredicto fue bueno. Verificado corriendo el ciclo completo: subcomandos.txt ✓ TOTAL: 44 herramientas selladas que no se pueden invocar. raices.txt ✓ ✓ 0 ofensores NUEVOS sobre 1 artefactos. ==> estado commiteado+pusheado	2026-09-12 02:35:21 +00:00
SergioandClaude Opus 5	edc95325d9	censar: cuatro binarios que YA NO EXISTEN en disco — y el paso de rescate, que caduca ... `/proc/<pid>/exe` termina en « (deleted)» para cuatro servicios de gioser: el fichero ya no está en disco, sólo vive el inodo que sostiene su proceso. Y en tres de los cuatro hay AHORA otro fichero en la misma ruta, de distinto tamaño: tejido corre 12750368 B · en su ruta hay 13815864 B shuma-gateway corre 8431896 B · en su ruta hay 10363504 B pacha-secretos corre 8634240 B · en su ruta hay 8647456 B puerta-f6e393ff corre 197262440 B · en su ruta NO HAY NADA Copiar la ruta NO FALLA: muda otra cosa, y el servicio nuevo no es el que estaba andando. Todo verde, todo distinto — el modo de fallo más caro que hay en este frente. Se recuperan leyendo `/proc/<pid>/exe`, y SÓLO mientras el proceso viva. En una mudanza que termina BORRANDO el origen, un reinicio de gioser antes de este paso los pierde para siempre. Por eso: · clase propia en `origen_binario` (`borrado`), no una coletilla dentro del texto de `suelto`: no es «hay que llevarlo», es «se pierde en el próximo reinicio y el que está en su ruta no es el mismo». El motivo trae el comando literal de rescate con su pid. · paso `rescate` en el plan, ANTES del preflight, porque es el único paso que puede volverse IMPOSIBLE mientras se piensa el resto. · su verificación COMPARA TAMAÑOS contra el que corre. No es celo: un `cat` de un `/proc` que ya no existe crea un fichero VACÍO y devuelve 0, así que sin comparar el rescate «pasa». Probado en los dos sentidos — el paso real sale 0, y con un fichero vacío a propósito dice `FALTA tejido` y sale 1. Los cuatro ya están rescatados en `work/mudanza/rescate/` (gitignored), byte a byte iguales a los que corren, con su SHA256SUMS. Y el empalme se hizo comprobando que el marcador fuera ÚNICO antes de cortar, que es la lección del `def pasos` duplicado de ayer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 02:28:37 +00:00
SergioandClaude Opus 5	0f3b137578	censar: leer la config del servidor web — cinco sitios sirven un root que NO EXISTE ... La sonda DNS dice si un dominio resuelve; no si el servidor tiene algo que servirle. Eso lo dice el FICHERO DE CONFIGURACIÓN, y leerlo no toca al origen: ni una petición, ni riesgo de fail2ban. Para leerlo se agregó un LECTOR de Caddy al centro (`formatos/caddy.py` ya tenía el escritor), y el censo lo usa en vez de tener su propio parser a medias — los de nginx y apache ya existían, y dos parsers del mismo formato es cómo se separan sin que nadie lo note. Cuarto par de la familia web. Sobre el Caddyfile real de gioser, cinco sitios apuntan a un `root` que no existe — y son justo los que devolvían los 502 que en su día hicieron que el censo SE BANEARA A SÍ MISMO al sondearlos: aura.gioser.net → /var/www/aura_frontend · sigma → /var/www/sigma/frontend summa → /var/www/summa/frontend · kosmofono → … · dev.summa → … Es evidencia MÁS FUERTE que el DNS: no hay nada que servir, devuelve 502 resuelva donde resuelva. Va como recomendación `muere` con la ruta y el fichero donde está el bloque. **Y sirve para lo contrario, que es donde el aviso hacía daño.** Un directorio que la config SÍ referencia no es huérfano: el plan marcaba `/var/www/git-tawasuyu` como «nadie lo recuerda» estando servido, y ese aviso aplicado tira `git.tawasuyu.net`. Dos bugs propios, los dos encontrados contra el fichero real y no sobre un ejemplo mío: · El `root` de ese sitio vive DENTRO de un `handle`, y yo saltaba los bloques anidados enteros por no saber modelarlos. Que el pivote no sepa MODELAR algo no es razón para no VERLO: el bloque sigue marcado SIN-TRADUCIR pero sus `root`/`reverse_proxy` se leen. Con eso aparecieron dos raíces ausentes más, también anidadas. · Detectar la cabecera de sitio con una lista negra de directivas dejaba pasar `log { output file … {` y el snippet `(acceso) {`: DOS dominios inventados que el censo habría puesto a decidir. La regla que aguanta es positiva — todos los tokens de la cabecera tienen que PARECER una dirección. Sin regresión: `nginx → caddy` y `apache → caddy` siguen dando `Valid configuration` con el caddy del corpus. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 01:49:02 +00:00
Sergio	0ca88fdcd5	atuq §6.3.ter: preguntarle al archivo por lo que DECÍA, no por las palabras exactas ... El muro no era un daemon ni un LLM — y el propio comentario de la extensión lo decía mal, copiando lo que hace willay-rag. Medido: para ordenar por parecido no hace falta ningún LLM (eso es un coseno) y el «daemon de embeddings» resultó ser el mismo llama-server que ya levanta el chat, con otro modelo. La corrección quedó escrita donde estaba la afirmación. Del lado de la suite (tawasuyu 22527f7d1 y b4ecffea8): el protocolo de llama-server salió a `shared/foreign-llama` (regla 4 — vivía dentro de puriy-costura y ya tenía dos consumidores), el `Provider` es `rimay-verbo-llama` (regla 10 — la familia verbo YA es la abstracción de embeddings, y éste es su primer backend sin nube ni descargas), y el índice es `rimay-verbo-index::VectorIndex`. Acá: la receta del modelo (multilingual-e5-small, MIT), que se pinea en fp32 y la receta CUANTIZA a Q8_0 con nuestro llama-quantize — así la procedencia es de quien declara la licencia, la imagen se lleva 126 MB en vez de 476, y la transformación es nuestra y verificable. Más el guardián y la extensión, que ahora expone `archive.ask` al lado del `archive.search` literal: son dos preguntas distintas y conviven. ⚠ El guardián está escrito pero NO corrió todavía: `ia-modelo-embeddings` quedó en la cola del flock detrás del build de otro agente. Lo medido hasta acá es el modelo a mano (384 dimensiones, el pasaje correcto gana con y sin los prefijos de e5) y 45 tests en tawasuyu. La línea del SDD que lo dice se borra cuando dé verde.	2026-09-12 01:32:12 +00:00
Sergio	af20d90648	bzip2: cuatro comandos rotos desde siempre — /usr/bin/bzcmp -> /out/usr/bin/bzdiff ... `bzcmp`, `bzegrep`, `bzfgrep` y `bzless` son symlinks con **la ruta del SANDBOX horneada dentro**. El Makefile de bzip2 los crea con `ln -s $(PREFIX)/bin/bzdiff bzcmp` —con `$(PREFIX)` DENTRO del destino— y como bzip2 **no soporta `DESTDIR`**, la receta pasa `PREFIX=/out/usr` (el mismo truco que valkey) ⇒ el destino que queda es `/out/usr/bin/bzdiff`. Al hidratar, esos cuatro apuntan a un directorio que en el sistema real no existe. ⚠ **Cinco indicadores en verde sobre cuatro comandos que no funcionan**: el artefacto tiene contenido, `bzip2`/`bzgrep`/`bzdiff` corren, `static-audit` pasa, el grafo lo cuenta y la receta REPRODUCE. Ninguna métrica existente mira a dónde apunta un enlace. Arreglo: rehacerlos RELATIVOS después del install, que es lo correcto para un artefacto direccionado por hash — un enlace relativo sigue valiendo esté el árbol montado donde esté. Verificado: los cuatro resuelven y `bzip2 -c | bzcat` sigue dando `hola`. ## El guardián, en el mismo sitio y por la misma pregunta `--auditar-raices` ya contestaba «¿esta receta dejó ficheros donde no van?». Ahora contesta también la otra mitad: «¿dejó ENLACES a una raíz que no es del FHS?». Son la misma familia —un `install` que se equivocó de destino— y comparten la definición de `FHS_RAIZ`, que es lo que evita dos listas que se desincronizan. La regla es independiente del perfil, y por eso vale sobre el store entero: un enlace a OTRO artefacto es normal (`kinfocenter -> /usr/bin/systemsettings`, los dos en `escritorio-kde`, resuelve en el rootfs fundido). Lo que nunca puede estar bien es un destino absoluto cuya primera componente no sea del FHS: `/out`, `/src`, `/tmp` son rutas del lab. Dos correcciones al propio guardián, las dos aprendidas midiendo: · **Sólo audita el artefacto VIGENTE de cada receta.** El store guarda todos los sellados históricos, así que la primera versión acusaba a bzip2 por el artefacto YA SUPERADO — el mismo sobre-reporte que `static-audit.sh` tuvo que quitarse de encima. El hash vigente sale de los grafos de estado, no de 1150 llamadas a `takana hash`. ⚠ Y hay que regenerar **los cinco** grafos: con sólo el principal regenerado, el de KDE seguía apuntando al bzip2 viejo y el filtro lo dejaba pasar. · **Un barrido que no miró NADA lo dice y sale 2.** Filtrar por hash vigente hace que un `--store` que no case con los grafos deje cero artefactos auditados, y sin la guarda eso se imprimía como «✓ 0 ofensores»: una respuesta falsa con forma de respuesta. Probado: `--store /tmp` → exit 2. El control del hallazgo es el propio arreglo, sobre datos reales y no sintéticos: antes del fix el barrido nombra los cuatro enlaces de bzip2; después, `✓ ninguno`.	2026-09-12 00:46:10 +00:00
SergioandClaude Opus 5	0f58df4795	planear: el preflight medía contra / — y los datos de gioser no entran ahí ... La cadena `censar → planear → aplicar` corrió entera contra gioser por primera vez: 59 pasos, 20 ejecutables y 39 manuales, bien separados. El ensayo en seco destapó lo que ninguna prueba de juguete iba a mostrar: **33,6 G de datos contra una raíz con 3,5 G libres** (el sitio está en `/work`, 66 G). Dos cosas estaban mal a la vez: · **El plan copiaba ruta → MISMA ruta**, sin forma de decir dónde cae cada árbol en el destino. Ahora `[[datos]]` tiene `destino` (vacío = la misma ruta). El fallo que evita es caro: aparecía a mitad de un rsync de 22 G. · **El preflight sumaba todo y lo comparaba contra `/`.** Acierta POR CASUALIDAD mientras todo caiga en `/`, y da un veredicto completamente falso en cuanto una ruta va a otro montaje — en las dos direcciones. Ahora mide por sistema de ficheros, agrupa los destinos, nombra qué rutas caen en cada uno, y el veredicto lo saca el propio comando en vez de un humano leyendo una columna. Los dos controles, contra la caja de verdad: ✗ / necesita 34386 MiB · libres 3596 ⇐ /var/www /var/lib /srv /opt /home exit 1 ✓ /work necesita 34386 MiB · libres 66192 ⇐ /work/var/www … /work/home exit 0 Además, el paso `muere` ahora cumple la regla 2 ENTERA («por su nombre Y CON SU TAMAÑO»). Un dominio fósil no pesa nada por sí mismo: pesa lo que dejó en disco, y `terapeuta.ec` —que no resuelve en ningún DNS— tiene 279 M en `/var/www/terapeuta`. Que eso se supiera dependía de que alguien se acordara. Se lista un renglón POR DIRECTORIO (siete dominios `*.gioser.net` reclaman el mismo `gioser.bak`; repetirlo siete veces convierte el aviso en ruido) y se dice «podría ser de», nunca «es»: el directorio se llama `terapeuta` y el dominio `terapeuta.ec`, y emparejar «casi» acierta casi siempre y el resto de las veces manda a borrar lo que no era. Los directorios que no reclama nadie se listan aparte: son los que nadie recuerda. ⚠ Y un bug que me hice yo y que el control cazó: empalmar por `str.index('# ── 1. datos ───')` cuando ese marcador existe en DOS funciones. Tomó el corte al revés (j < i) y DUPLICÓ `def pasos` entero; Python se queda con la última definición, así que el fichero importaba bien y generaba planes con el preflight viejo. Se vio porque el comando del plan no era el que yo acababa de escribir. Un marcador de empalme que no es único no es un marcador. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 00:45:27 +00:00
SergioandClaude Opus 5	bd1fa8bf8a	boot entry backup/restore: el arranque como estado reproducible (ADR 0018 §5) ... Guarda las variables de NVRAM CRUDAS —se reescriben tal cual; decodificarlas para volver a codificarlas al restaurar sería una oportunidad de perder algo que no entendemos— y de la ESP un manifiesto con hashes, no los bytes: el kernel ya vive en el store y copiarlo otra vez sería churn. El manifiesto es evidencia de qué había; para lo que no esté en el store dice qué falta, en vez de prometer reponerlo. El ADR se equivocaba en DÓNDE: decía "volcar al store". No va al store, porque lo barre store-gc.sh, que clasifica por nombre de receta — un respaldo ahí sería huérfano y se borraría en el primer --huerfanos. Vive en /var/lib/hammer/boot/, que en las imágenes es su propia partición. El nombre sale del CONTENIDO, así que un arranque que no cambió produce el mismo fichero: corre en cada arranque sin llenar la partición de copias. Lo que encontró la prueba de punta a punta y no estaba en el diseño: restaurar es volver al pasado, y lo que llegó DESPUÉS no estaba en ese pasado. Al reponer el BootOrder del respaldo, el Windows instalado más tarde quedaba FUERA del orden — correcto, y justo lo que el usuario no espera de algo llamado "restaurar el arranque". Ahora se avisa antes, con nombre y apellido, y restore NO escribe por defecto: la NVRAM es lo único de la máquina que no se rehace desde el store. El lector FAT ganó lectura de ficheros, con su trampa propia: hay que truncar al tamaño DECLARADO en el directorio, no al final del último cluster. Un fichero de 1,5 MB en clusters de 1 KiB termina con relleno y hashear el relleno daría un hash distinto al del mismo fichero en disco — el síntoma sería "dos respaldos del mismo arranque difieren". Verificado contra mtools como oráculo (1 500 000 y 900 000 bytes exactos, mismo sha256 que los originales) y con un test determinista que fabrica una FAT16 a mano, sin depender de que mtools esté. 79/79 del CLI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj	2026-09-12 00:34:21 +00:00
SergioandClaude Opus 5	d0e3aadb12	declarar: /proc pasa a ser un lector del centro — y había DOS emisores de tarjetas, mal los dos ... `declarar.py` tenía su propio molde de card de arje y `formatos/arje.py` el suyo: el N×M que el pivote existe para evitar, adentro de mi propio código. Y no quedó en teoría — CADA COPIA TENÍA UN CAMPO MAL DE LA RAÍZ, Y NINGUNO DE LOS DOS EL MISMO: campo declarar.py arje.py semilla REAL del producto provides ["Spawn","Journal"] ✓ [] ✗ ["Spawn","Journal"] supervision Restart{…} ✗ "OneShot" ✓ "OneShot" Las consecuencias son concretas: sin `Spawn`/`Journal` las hijas no tienen quién las lance ni dónde escribir, y una card `Virtual` con `Restart` le pide a arje que respawnee algo que nunca corrió. Ahora hay un lector `proc` (el censo es un formato de origen, igual que systemd u OpenRC) y el escritor `arje` es el ÚNICO que emite tarjetas; `declarar.py` queda con lo suyo, el perfil. Tres lectores en la familia: systemd y openrc leen LO DECLARADO —que es lo que miente, `rc-status` daba `stopped` para cinco servicios vivos— y `proc` lee LO QUE CORRE, que es donde aparecen los 15 `no-declarado`. Dos cosas más, las dos sobre no mentir: · **Una semilla vacía parecería un éxito.** Si ningún servicio tiene `decision = "muda"`, el lector lo DICE y sale ≠0 en vez de emitir cero tarjetas en silencio. Mismo modo de fallo que un artefacto vacío en el store. · **El acta se ahogaba en su propio ruido.** Anotaba el `envp` vacío una vez POR SERVICIO: 26 líneas idénticas que tapaban los dos hallazgos reales (`shuma-daemon` corre como `sergio`; los que no tienen cmdline). La limitación es del lector y vale para todos ⇒ una entrada nombrando a los 26. Un acta donde casi todo es la misma línea se deja de leer, y entonces no queda ningún acta. Y al revés: las entradas que SÍ son por servicio ahora lo nombran (`gitea: cwd=/var/lib/gitea`). Controles: la raíz generada coincide campo por campo con la del producto; dos corridas dan el fichero byte a byte idéntico; 26 tarjetas con 26 ids únicos. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-12 00:31:09 +00:00
Sergio	43a7ef0bd1	static-audit: auditaba SÓLO recipes/ y remataba con «toda receta lo cumple» — las 5 colas nunca se miraron ... El audit del enlace estático globeaba `recipes/*.toml` y nada más, y cerraba con «✅ toda receta que declara link=static lo cumple»: una frase verdadera de una PARTE del corpus, presentada como si fuera de todo él. Las cinco colas (`incoming{,-kde,-gnome,-cosmic,-wlr}`) son ~305 recetas que **nunca se auditaron**. Lo destapé por accidente: al promover `libseccomp` de `incoming-gnome/` a `recipes/`, **el artefacto no cambió ni un byte** y el audit pasó de MIENTEN:0 a MIENTEN:1. La mentira estaba ahí desde siempre y lo único que la tapaba era el glob de una línea. Un guardián que mide menos de lo que su resumen afirma es peor que no tenerlo: da por cubierto lo que no mira. Ampliado el barrido a las colas, aparecen **3** que llevaban invisibles: libseccomp scmp_sys_resolver 6 rebuilds (corpus 1 + incoming-gnome 5) libgcrypt dumpsexp y 2 más 41 rebuilds (corpus 1 + incoming-kde 40) libgpg-error gpg-error 45 rebuilds (corpus 4 + incoming-kde 41) Radios medidos con `yupana radio`, que cruza colas — no con `grep recipes/*.toml`, que es justo el error que este commit arregla. En las tres, lo dinámico es un **binario auxiliar de diagnóstico**, no la librería: los consumidores enlazan el `.a`, así que el impacto funcional hoy es NULO. Lo que está mal es la declaración, y arreglarla cuesta ~92 rebuilds casi todos de KDE. Van con el próximo bump de cada una, cuando el re-hash ya esté pagado — mismo criterio que la deuda de `perl`. Decisión con el número delante, no olvido. Por eso entran en `DEUDA_DECIDIDA` y se imprimen como `•` sin hacer fallar: si el audit fallara siempre por tres viejas, un ofensor NUEVO se perdería entre el ruido. El resumen ahora distingue «MIENTEN (nuevos)» de «deuda decidida». Probado con los dos controles y no sólo con el que da verde: quitándole a propósito el `LDFLAGS=-all-static` a `crun` y reconstruyéndola, el audit sale **1** y la nombra; restaurada, sale **0**. O sea que la tabla de deuda no se traga a un ofensor nuevo. El artefacto de la prueba se borró del store.	2026-09-11 23:04:02 +00:00
SergioandClaude Opus 5	2fa89ce3fa	censar: tres nombres equivocados que llegaban al plan, y los 7 «binario desconocido» eran permisos ... El censo nombraba los servicios por `comm`, que viene del kernel. De ahí salieron tres errores de CLASIFICACIÓN — y no son cosméticos: ese nombre es el que el plan mete en `--in /etc/init.d/<n>` y el que va de `label` en la tarjeta de arje. · `comm` está capado a 15 caracteres: `willay-crosscheck` llegaba como `willay-crossche` y con ese nombre no casaba contra su declaración ⇒ figuraba como `no-declarado` TENIENDO su tarjeta en la semilla de arje. La línea de comando trae el nombre entero. · `supervise-daemon` no es un servicio, es un ENVOLTORIO. Los cinco de gioser se fundían en una entrada `supervise-daemo`; y del otro lado `dbus`, `metalog`, `dhcpcd`, `squid` y `shuma-daemon` salían como `declarado-muerto` ESTANDO VIVOS — el mismo agujero que este censo existe para tapar, entrando por la otra puerta. El nombre real es su argv[1] y el comando real es el último token antes del `--` suelto (comprobado contra los cinco). · `head -15` con ppid==1 era un resto de tubería reparentado, contado como servicio. Va a `descartados`, que se imprimen: un huérfano es un hallazgo, no basura. **Y los 7 «no se pudo leer su binario» eran dos cosas distintas.** Muchos demonios reescriben su `argv[0]` (`sshd: /usr/bin/sshd [listener]`, `php-fpm: master process (…)`), así que la línea de comando no dice cuál es el binario — `/proc/<pid>/exe` sí, y necesita ser dueño o root. Medido: uid 1001 : desconocido 7 · paquete-ajeno 13 · receta-takana 6 · suelto 13 root : desconocido 0 · paquete-ajeno 20 · receta-takana 5 · suelto 14 Ahora el censo DICE cuál de las dos pasó: «repetilo con sudo» y «averigualo a mano» son trabajos muy distintos, y confundirlos manda a alguien a investigar un permiso. Desenvolver al supervisor arregló además dos datos que salían falsos: el `exec` de `squid` era `/usr/bin/supervise-daemon` (⇒ figuraba provisto por el paquete `openrc`), y el `cmdline` guardado era el del SUPERVISOR — una tarjeta hecha con eso arrancaría `supervise-daemon` dentro de arje, que ya supervisa. Y se rescata el `--user`: `shuma-daemon` corre como `sergio`, dato que la tarjeta de arje no puede guardar (no tiene campo de usuario), así que ahora se avisa EN LA REVISIÓN — sin eso a la vista, un servicio que acá corre sin privilegios termina de root en el destino. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 22:56:47 +00:00
SergioandClaude Opus 5	2201fac08e	boot entry survey: el informe del terreno, leyendo la ESP SIN montarla (ADR 0018 §4) ... Reporta firmware, discos, ESPs, con quién se comparten y si la instalación entra. No escribe nada — y para poder prometer eso hubo que leer la ESP sin montarla, que es lo que obligó al lector FAT de sólo lectura (fat_ro.rs). Montar para averiguarlo pedía privilegios, dejaba un efecto secundario justo cuando prometimos no tocar nada, y falla si el vecino dejó la FAT sucia por su hibernación. Sobre una ESP de fábrica (100 MiB) con Windows dentro: FAT32 «ESP» — 100.0 MiB totales, 77.1 MiB usados, 22.1 MiB libres vecinos en \EFI: Microsoft, BOOT ⚠ «Microsoft» ⇒ hay Windows en esta ESP. Es el que reordena BootOrder al actualizarse. ✗ NO ENTRA: hacen falta 31.0 MiB y hay 22.1 MiB libres Contrastado contra mtools como oráculo, que es lo que hace creíble el número: mdir dice "23 221 248 bytes free" y el lector propio dice 22.1 MiB — el mismo. Los clusters libres se cuentan recorriendo la FAT y NO se lee el FSInfo de FAT32 a propósito: ese campo lo deja desactualizado un SO que desmontó mal, y un número optimista de más haría fallar la instalación a mitad — justo lo que el §4 evita. En el instalador el §4 resultó ser algo más que "cuánto espacio hay": la rama UEFI se lleva el disco ENTERO, así que lo que hay que decir en voz alta es con qué se lo va a llevar puesto. El survey corre antes de particionar y nombra el \EFI\Microsoft si está. El usuario se entera ANTES, y no después de que su Windows dejó de arrancar. Dos cosas que habrían pasado inadvertidas sin test: el nombre largo tiene que ganarle al 8.3 (sin juntar los LFN, "Microsoft" se lee "MICROS~1" y la advertencia no dispara nunca), y el tipo de FAT sale del número de clusters y no del texto del BPB, que es informativo y hay formateadores que mienten. El primer test del tipo lo escribí mal —1999 clusters ES FAT12— y el síntoma es idéntico a un bug del lector. 78/78 del CLI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj	2026-09-11 22:55:46 +00:00
Sergio	beb1c2a597	auditar-raices: el guardián de la raíz sucia sólo veía los perfiles — y hay 649 recetas fuera ... `hydrate-profile.py` ya tenía el bloque «quién ensucia la RAÍZ del rootfs», y es bueno: mira por ARTEFACTO y no sobre el árbol fundido, porque en el fundido el nombre del culpable ya se perdió. Pero sólo corre al hidratar un perfil ⇒ **sólo ve lo que alguna imagen declara**. Hoy hay **649 recetas que no alcanza ninguna imagen**, y una fase `install` que se equivoca de destino en una de ésas es invisible hasta el día que alguien la declare. Lo destapó `qdrant`: selló con **69 M** de cabeceras de protobuf bajo `/src`, y no está en ningún perfil ⇒ ningún guardián lo habría visto. Lo encontré mirando el árbol del artefacto a mano antes de promoverlo, que es justo lo que no se puede dejar a que alguien se acuerde. `--auditar-raices` hace la misma pregunta sobre el STORE ENTERO sin hidratar nada, reutilizando el mismo `FHS_RAIZ` (una sola definición de «qué puede ir en la raíz», no dos que se desincronizan). Y dos tablas, porque un barrido que canta tres cosas de las cuales dos son correctas se deja de leer: · `RAIZ_POR_CONTRATO` — `seed-zig` (el toolchain ES el artefacto) y los rootfs (`store`/`ente` son suyos por diseño). Se imprimen como ⊘ con el motivo y no cuentan. · `RAIZ_DEUDA_DECIDIDA` — `perl` y sus 945 páginas nroff en `/`. Es suciedad REAL pero su arreglo está decidido EN CONTRA por ahora (una línea, 305 rebuilds, va con el próximo bump). Se imprime como contexto y **no hace fallar**: si fallara siempre, un ofensor NUEVO se perdería entre el ruido del viejo — que es exactamente cómo se muere un guardián. Probado con los dos controles, no sólo con el que da verde: sobre un store de juguete con una suciedad inventada sale **1** y la nombra; quitándola sale **0**. Sobre el store real: 0 ofensores nuevos sobre 3 artefactos conocidos.	2026-09-11 22:53:29 +00:00
Sergio	54bf3e810e	ia: el modelo de chat, pineado — Qwen2.5-1.5B-Instruct Q4_K_M (Apache-2.0) ... Elegido por tres cosas, y las tres medidas antes de pinearlo: licencia Apache-2.0 (lo que una distro puede shipear sin letra chica, al revés que Llama-3.2 o Gemma), habla español —se le preguntó qué es una distribución de GNU/Linux y contestó dos frases correctas— y corre en CPU: 20,1 tokens/s en el hub sin GPU, 1,04 GiB. El objeto pineado es un tar que envuelve el .gguf, publicado en el mirror y servido por sha256: takana extrae toda fuente con `tar` y un GGUF pelado no lo es. Es el camino de firefox-pgo-profile. La receta anota el sha256 del GGUF DE UPSTREAM (el lfs.oid de HuggingFace, verificado al bajarlo) y no sólo el del tar nuestro, para que nadie tenga que confiar en nuestro tar. Round-trip verificado: apartados el caché y el artefacto, el build lo bajó del mirror y selló el mismo ArtifactHash. Guardián en la receta, porque el fallo es callado: un fichero truncado o un HTML de error renombrado a .gguf se instala igual y sella en verde. Se comprueban el mágico GGUF y el tamaño. ⚠ Y el modelo de verdad destapó una CARRERA en el guardián del §6.7: el censo de motores contaba en el instante del cierre — con el de juguete daba 0 y con el de la imagen daba 1, que se lee como fuga cuando en realidad matar un proceso con un giga mapeado tarda ~1 s. Ahora espera hasta 15 s y anota cuánto tardó. La rotura a propósito sigue fallando, ahora con el tiempo a la vista. Falta decidir en qué imágenes se declara (con el motor son ~1,25 GiB por perfil) y pinear el de embeddings (multilingual-e5-small) para la mitad semántica del §6.3.	2026-09-11 22:41:46 +00:00
SergioandClaude Opus 5	66eaf8738f	el reconciliador ARRANCA solo: montar sysfs, y un diagnóstico que no mentía a medias ... Cierra el §2 del ADR 0018, verificado con dos arranques de la imagen completa en OVMF: 1º (por la fallback) → "ESP detectada en /dev/vda p1", "⚠ EL ARRANQUE ESTABA CAMBIADO — takana lo repuso", "faltaba la entrada «takana» ⇒ escrita en Boot0004", "BootOrder: 0000,0001,0002,0003 → 0004,0000,0001,0002,0003" 2º → BdsDxe: starting Boot0004 "takana" from HD(1,GPT,923A070F-…) /\EFI\takana\takanax64.efi "✓ arranque en orden: Boot0004 «takana» ya es la primera" Un sistema recién instalado se da de alta en el firmware en su PRIMER arranque y desde el segundo arranca por su propia entrada, sin que nadie corra un comando. Y el segundo no escribe nada. Lo caro no fue el reconciliador sino un diagnóstico FALSO: el primer arranque con el hook dijo "sin firmware EFI — esta máquina no arrancó por UEFI" en una VM que SÍ arrancó por UEFI. La causa no tenía nada que ver con UEFI: busybox switch_root no arrastra /sys —igual que no arrastra /dev, cosa que el script ya contemplaba— así que el directorio de efivars no existía. El mensaje mandaba a investigar el firmware, que estaba perfecto. Dos arreglos: - el wrapper monta sysfs y después efivarfs. CONFIG_EFIVAR_FS=y ya estaba en el .config SELLADO (verificado, no supuesto) ⇒ no se re-hashea ningún kernel. - el mensaje distingue TRES estados que se parecen: no existe (BIOS o /sys sin montar), existe y está VACÍO (falta el mount, y lo dice con el comando exacto), o tiene variables. Decir "no hay UEFI" cuando falta un mount manda a diagnosticar al lugar equivocado. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj	2026-09-11 22:25:12 +00:00
SergioandClaude Opus 5	236abe48f3	boot entry reconcile: converger con la NVRAM en CADA arranque (ADR 0018 §2) ... La NVRAM es estado compartido y el vecino la reescribe sin coordinarse. Contra eso no sirve confiar: sirve converger. `reconcile` descubre su propia ESP, repone la entrada y el BootOrder, y es idempotente. Descubre la ESP por TIPO de partición (GUID de ESP en GPT, 0xEF en MBR), que es el único dato fiable sin montar nada — un reconciliador que monta sistemas de ficheros en el arranque es un efecto secundario que no queremos. Si hay VARIAS ESP no adivina: las lista y pide --disk. Elegir mal significa escribir una entrada que apunta a un disco que puede no estar, y eso es peor que no escribir nada. No rompe el arranque por nada: sin firmware EFI (máquina por BIOS) lo dice y sale 0. Y cuando actúa, GRITA — va a /dev/tty0 además del serial, a diferencia del menú de arranque. Un reconciliador que repara en silencio deja al usuario conviviendo con una rareza intermitente que no entiende; el mensaje dice explícitamente que si se repite en cada arranque es que otro sistema operativo le está reescribiendo la NVRAM. Enganchado al wrapper de PID1 de las dos imágenes, con el mismo timeout y el mismo || true que el menú: corre ANTES del exec de arje-zero y colgarse ahí es un arranque muerto e indistinguible de un kernel colgado. El test que vale es el escenario completo: takana se instala, llega el vecino y se pone primero, y el siguiente arranque lo repone — SIN borrar la entrada del vecino (takana se pone primera, no lo echa) — y el arranque siguiente ya no escribe nada. Más el GUID de ESP, que va en orden DE DISCO y no en el legible: escribirlo "como se lee" es el error clásico y no casaría con ninguna ESP real. 15 tests en el módulo, 74/74 del CLI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj	2026-09-11 22:18:16 +00:00
SergioandClaude Opus 5	73f75d45ed	censar: sonda DNS-only (--probe-dns) — y los dominios fósiles vuelven a la lista de decisiones ... Censo real de gioser (204.168.193.248, identificado por IP y no por hostname, que dice «momento»): 19 vivos, 18 NO-DECLARADOS, 85 declarados-muertos, 29 dominios. **El HTTP toca al origen; el DNS no.** Sondear los dominios desde la propia máquina disparó su fail2ban y la dejó incomunicada, así que el censo en local los salteaba — y quedaban 29 de 66 ítems SIN recomendación por una precaución correcta aplicada de más. Lo que dispara la jaula es el HTTP: `getent` le pregunta al DNS, no al servidor. `--probe-dns` sondea sólo el nombre, sin UNA SOLA petición a gioser, y contesta la pregunta que más pesa en una mudanza: cuáles siguen apuntando acá y cuáles son fósiles. 29/29 clasificados: 12 apuntan acá, 4 ya se mudaron, 13 NO RESUELVEN. Lo que el DNS solo no puede decir es si el backend contesta, así que ésos quedan en `apunta-aca`, clase propia y NO `vivo`: decir «vivo» sin haber pedido una página sería la respuesta falsa con forma de respuesta que este censo existe para evitar. **Y un hueco de verdad: los `fosil-sin-dns` quedaban fuera de `entradas()`**, con el argumento de que un dominio sin DNS no necesita ningún paso. Cierto para el DNS, FALSO para lo que arrastra: son 13 de 29, y `terapeuta.ec` tenía 279 M de contenido y su bloque en el servidor web. Fuera de la lista eran invisibles, así que nadie decidía borrarlos y sus datos viajaban a la caja nueva por omisión — el «mudar fósiles» que este plan existe para evitar, y contra su propia regla 2 («lo que muere se dice por su nombre y con su tamaño, ANTES de borrar nada»). Ahora entran, con recomendación `muere` y el aviso de revisar qué dejaron en disco. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 21:21:03 +00:00
SergioandClaude Opus 5	3aab82d6f6	planear: el centro de traducción ENGANCHADO al plan — y el plan que emitíamos no era TOML válido ... El plan ya advertía «cambiar de servidor web obliga a REESCRIBIR la configuración entera». Cierto, y la advertencia correcta, pero dejaba al humano con un párrafo y ninguna herramienta. Ahora es un PASO con su comando literal: `traducir.py --from openrc --to arje --in /etc/init.d/caddy …`. Dos traducciones distintas por servicio, y confundirlas es caro: la DECLARACIÓN (cómo se levanta, `openrc`/`systemd` → tarjeta de arje) y la CONFIGURACIÓN (qué hace, sólo si se eligió un equivalente). Un servicio que se muda a sí mismo no necesita la segunda: ofrecérsela es inventarle trabajo. Los pares se le PREGUNTAN al registro de plugins, no se listan acá — una lista propia se desincroniza del centro y el plan ofrecería una traducción que no existe. Sin par, el paso lo dice. La verificación es HUMANA a propósito: `traducir.py` sale ≠0 cuando algo quedó sin traducir, así que dar el paso por bueno por su código de salida sería al revés de lo que hay que mirar. Lo que verifica es que alguien LEYÓ el acta. **Y en el camino salió un fallo del producto: el plan no era TOML válido.** Apareció con el primer comando multilínea, pero estaba latente desde el principio y tiene DOS modos: · `awk "\$1==1"` —que está en el `verifica` de TODO servicio— con cadena básica da `Unescaped '\' in a string`: el plan queda ILEGIBLE. · `cmd --from x \` + salto: la cadena básica PARSEA y se come el salto y la sangría ⇒ el comando que sale NO es el que se escribió, sin que nada falle. Ése es el peor. El plan es el producto: se revisa, se versiona, se lleva a otro proveedor y se vuelve a correr. Uno que no vuelve a parsear no sirve para ninguna de las dos cosas para las que existe. Arreglado con cadena literal, y con un guardián que ESCRIBE Y RELEE antes de tocar el disco: si el TOML generado no parsea, no se escribe nada. Convierte un fallo diferido —aparecía cuando alguien iba a EJECUTAR el plan— en uno inmediato. Probado de punta a punta: el comando que el plan emite, copiado tal cual, traduce el `/etc/init.d/caddy` real de esta máquina a una tarjeta con `Restart{initial:3000}` (de su `respawn_delay=3`) y reporta la única `reload()` que no se puede portar. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 20:49:52 +00:00
SergioandClaude Opus 5	294959c1da	arranque y GC: las dos rutas EFI, guardián de ESP y el kernel vivo como raíz ... Primera tanda de los ADR 0017/0018, con las mediciones que la corrigieron. ADR 0018 §3 — install-image-efi.sh y takana-live-install.sh escriben el kernel en \EFI\takana\takanax64.efi ADEMAS de la ruta fallback, con un guardián de capacidad que comprueba ANTES y con los números a la vista (duplicar el kernel cuesta, y el costo se dice). En el live-install la verificación es por TAMAÑO, no por presencia: un cp truncado en FAT32 deja el fichero ahí y test -e diría que todo salió bien. Verificado con imagen real en OVMF: las dos copias dan el mismo sha256 que el bzImage del store, y la imagen arranca hasta arje-zero PID1. CONTROL NEGATIVO: pisando la fallback con 4K de basura el firmware dice "No bootable option or device was found" y no aparece HAMMER-EFI ni una vez ⇒ el escenario de Windows, reproducido. Y lo que NO se pudo verificar cambia el alcance, así que va en el ADR: sin entrada NVRAM el firmware NO busca el vendor path. La copia vendor es hoy un seguro que no se cobra solo — el §3 es necesario y NO suficiente sin el §1. Eso asciende la receta efibootmgr a bloqueante. ADR 0017 §4 — store-gc.sh suma como raíz el kernel EN EJECUCIÓN, identificado por .config byte a byte. Sin esto el artefacto del kernel vivo cae en "superados" cuando la receta se movió, y se borra: el sistema sigue andando perfecto hasta el día que hace falta volver atrás. Probado en los tres sentidos, incluido el control que TIENE que seguir condenado. Además, dos bugs preexistentes que aparecieron al ir a medir: - install-image-efi.sh abortaba con "ROOTFS sin /sbin/init" en TODO rootfs sano: /sbin/init es un symlink ABSOLUTO (→/usr/bin/arje-zero) y [ -e ] lo sigue contra la raíz del HOST. Un chequeo que validaba algo distinto de lo que creía validar. Arreglado resolviendo el destino dentro del rootfs. - (no arreglado, es del entorno) el cp -al del staging da EXDEV si ROOTFS y STAGE no están en el MISMO MOUNT — y el bind-mount del store cuenta como otro mount aunque sea el mismo /dev/sdb. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj	2026-09-11 20:40:34 +00:00
Sergio	4cb776ecd7	vigía: 46 herramientas selladas que NO SE PUEDEN INVOCAR — cuatro verdes sobre algo inerte ... Hay una familia de recetas que no son programas: son SUBCOMANDOS. `protoc-gen-go` es un plugin que ejecuta `protoc`; `cargo-audit` existe para escribirse `cargo audit`; `kubectl-tree` lo despacha `kubectl`. Están selladas, tienen contenido, resuelven sus sonames, el grafo las cuenta y `verificar-repro` dice que reproducen. **Cuatro indicadores en verde sobre binarios que no se pueden usar**, porque el driver que los invoca no está en el catálogo. Ninguna métrica existente puede verlo: la arista «me ejecuta aquél» NO es una dep de build, así que no existe en el grafo. Lo descubrí por accidente — `protoc-gen-go` llevaba meses sellado y el catálogo no tenía `protoc`; lo delató ir a escribir la receta de un servicio gRPC y preguntarme con qué se generan los stubs. Eso es exactamente un punto ciego, y acá va su guardián. Lo que mide hoy: ✗ falta `cargo` ⇒ 44 recetas INERTES (cargo-audit, cargo-nextest, cargo-deny, …) ✗ falta `kubectl` ⇒ 2 recetas INERTES (kubectl-neat, kubectl-tree) TOTAL: 46. No es deuda de BUILD —construyen y reproducen— es deuda de CATÁLOGO. Dos decisiones de diseño que son la diferencia entre un vigía que se lee y uno que se ignora: · **Comprueba el BINARIO, no el nombre de la receta.** El driver de `protoc-gen-*` es `protoc`, que lo publica la receta `protobuf`. Preguntar «¿existe recipes/protoc.toml?» habría seguido diciendo «no» DESPUÉS de cerrarlo, y un guardián que grita cuando ya está arreglado se empieza a ignorar. · **La tabla de drivers es explícita, no una heurística sobre guiones.** `git-cliff` es subcomando de git; `gettext-tiny` no es subcomando de `gettext`. Adivinar por el guión da falsos positivos, y un vigía con falsos positivos no se lee. Y trae `--autoprueba` con los dos controles, porque un guardián que nunca falló no se sabe si sirve: NEGATIVO (escondo `git`, que sí está ⇒ tiene que cantar `git-`) y POSITIVO (sin tocar nada, no debe cantar sobre los drivers presentes). Los dos pasan. ⚠ Una trampa medida escribiéndolo, dentro del propio script: `glob('store/*-go')` casa por SUFIJO y matchea `…-protoc-gen-go`, o sea que contestaba que `go` estaba sellado cuando no lo estaba. El nombre de receta se saca con una regex ANCLADA sobre el basename.	2026-09-11 20:31:12 +00:00
SergioandClaude Opus 5	61c33800c5	traducir: lector de OpenRC — el par que cierra el camino de gioser, y casi la mitad NO se puede leer ... `openrc → arje` sin escribir ningún traductor de ese par: cuarto plugin, cuarto par. OpenRC es el init de gioser, la máquina que esta mudanza termina borrando. **El hecho que manda acá: un servicio de OpenRC es un PROGRAMA, no una declaración.** Un unit de systemd se lee; un script de OpenRC puede hacer cualquier cosa antes de arrancar nada. Medido sobre el `/etc/init.d` real: **60 de 121 definen su propia `start()`/`stop()`**. En ésos no hay `command=` que valga — leer las variables y emitir tarjeta daría un servicio que arranca OTRA COSA. Regla al revés que en systemd: `start()` propia ⇒ SIN-TRADUCIR y NO se emite tarjeta. Los números del corpus real cierran solos: 121 − 1 (no es openrc-run) − 60 (start propia) − 1 (sin `command=`) = 59, y el lector emitió exactamente 59, con 59 ids únicos. Dos cosas que OpenRC obliga a ir a buscar fuera del script: `/etc/conf.d/<x>`, donde viven los argumentos de verdad (a diferencia del `EnvironmentFile=` de systemd, éste SÍ está en la máquina: se lee y se aplica), y `/etc/runlevels/`, que es lo único que dice si el servicio arranca solo. **Tres defectos que sólo aparecieron corriendo contra las 121 de verdad**, no sobre un ejemplo mío: - `name=` no es un identificador sino un rótulo humano: en gioser vale «Aura Backend», con espacio, y se iba al id de la tarjeta y al path del cgroup. El identificador es el nombre del fichero. - Ids repetidos: `/etc/init.d` guarda copias `*.bak-FECHA` junto a los servicios vivos y son scripts válidos; dos con el mismo nombre dan el MISMO id determinista ⇒ semilla con dos cards homónimas. El escritor lo detecta y no emite la segunda. - La tarjeta decía `"desde": "systemd"` viniendo de OpenRC: el campo que existe para saber de dónde salió algo era justo el que mentía. Estaba cableado. Y el centro deja de filtrar la entrada por extensión: los servicios de OpenRC no tienen ninguna, y filtrar en el centro es que lo que no entra se pierda EN SILENCIO. Filtra el lector, que sabe, y lo anota — así un `.bak` en `/etc/init.d` se REPORTA en vez de desaparecer. Controles: dos corridas dan el fichero byte a byte idéntico; los tres pares previos sin regresión (`nginx → caddy` sigue dando `Valid configuration`, `systemd → arje` sigue emitiendo sus 3 tarjetas). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 20:30:20 +00:00
Sergio	a14b62436c	atuq §6.7.bis: la barra lateral pregunta, y contesta un modelo de ESTA máquina ... Inferencia REAL de punta a punta, en una jaula sin red: panel → fondo → host → `llama-server` (el llama-cpp del corpus) → respuesta. El servidor lo levanta el host en la primera pregunta —no hay servicio de IA en la imagen— y **se muere con el navegador**, al revés que el daemon del torrent (§6.9): un torrent tiene trabajo que sobrevive; medio giga de modelo en RAM, no. El puerto nativo vive en el FONDO y no en la página: si viviera en la página, cerrar la barra lateral se llevaría el host y el modelo cargado con él. `scripts/test-atuq-ia.py` mide tres cosas: que la respuesta salga del modelo de la imagen, que no venga VACÍA, y que al cerrarse el navegador queden cero `llama-server`. Control negativo: sin modelo aparece la causa y NO hay respuesta inventada. ⚠ Ese censo nació roto y del género que este repo colecciona: `pgrep -c` no existe en busybox y el `|| echo 0` convertía el error en un cero — o sea en un verde. Con un motor vivo a propósito el guardián pasaba igual. Ahora cuenta leyendo /proc y la rotura falla como debe. Y el PRIMER intento de romperlo tampoco rompía nada: el motor de mentira moría al hacer bind porque el socket estaba en /salida, compartido entre las dos corridas. Queda UNA decisión, no trabajo: qué modelo se pinea (tamaño de imagen y licencia). Hasta entonces la imagen no trae modelo y el panel lo dice con todas las letras.	2026-09-11 19:24:33 +00:00
SergioandClaude Opus 5	fefa92ec5a	traducir: familia «servicio» — systemd → tarjeta de arje, y el pivote pasa a ser uno POR FAMILIA ... Un unit de systemd no es un sitio web. Meterlo en `Sitio`/`Ruta` sería justo el «parecerse» que el acta existe para evitar, así que cada familia tiene su modelo y el centro empareja SÓLO dentro de la familia. Un par cruzado se rechaza con un error, no con un intento: `systemd → caddy` sale por `sys.exit`, porque traducir entre familias daría un fichero que PARECE correcto. Dos familias hoy: `web` (nginx, apache → caddy) y `servicio` (systemd → arje). 3 pares con 5 plugins. **Dónde una elisión silenciosa no pierde una opción sino que CAMBIA el sistema.** El payload `Native` de arje acepta `exec`, `argv` y `envp` y nada más (comprobado en la semilla real del producto): NO hay campo de usuario. Un `User=git` traducido en silencio correría el servicio COMO ROOT — escalación de privilegios en un fichero generado que nadie vuelve a leer. Sale SIN-TRADUCIR con su línea. Igual `EnvironmentFile=` (el fichero no está en la máquina donde se traduce ⇒ envp incompleto, falla tarde), `Type=forking` (arje supervisa al proceso que lanza ⇒ BUCLE DE REINICIO) y todo el endurecimiento, que callado entrega un servicio MENOS confinado que el original. Lo que sí tiene destino exacto: `Type=oneshot` → `"supervision": "OneShot"`, que ya existe en la semilla del producto — buscarlo antes de declararlo intraducible evitó una elisión inventada. **Lector y escritor no opinan del mismo campo.** `User=` lo CAPTURA el lector y lo JUZGA el escritor; cuando los dos anotaban, el acta decía dos cosas distintas de la misma línea, y un acta que se contradice se deja de leer. El lector registra en qué línea vio cada campo (`Servicio.lineas`) para que el escritor señale la línea real en vez de un 0. Controles: la tarjeta generada tiene el MISMO juego de claves que la tarjeta real de `sshd` del producto (+`_mudanza` de procedencia); dos corridas dan el fichero byte a byte idéntico; y la familia `web` sigue validando con el caddy del corpus (`Valid configuration` en los dos pares). De paso, `ulid_determinista` sale a `ids.py`: lo necesitaban `declarar.py` y el escritor de arje, y copiarlo habría dejado dos generadores de id que se pueden separar sin que nada falle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 19:15:21 +00:00
SergioandClaude Opus 5	3137d47f16	traducir: CENTRO de traducción con modelo pivote y plugins — N+M en vez de N×M ... Traducir de a pares no escala: con nginx, apache, caddy, haproxy y lighttpd son 20 traductores, y cada formato nuevo agrega 2N. Con un modelo intermedio son N lectores + M escritores: un formato nuevo cuesta uno o dos plugins y estrena todos los pares de golpe. **Probado, no argumentado**: el lector de apache se agregó SIN TOCAR el escritor de Caddy, y con eso `apache → caddy` funciona sin que exista ningún traductor de ese par. Las dos salidas las valida el caddy del propio corpus: `Valid configuration` en las dos. Los plugins se DESCUBREN (`formatos/` + `@lector` / `@escritor`): una lista mantenida a mano se desincroniza y el formato nuevo «no existe» sin que nada falle. `--list` dice qué pares habilita. **El acta viaja DENTRO del modelo**, y es la decisión que hace que el pivote no mienta: si fuera un efecto de cada traductor, lo que el LECTOR no entendió se perdería antes de llegar al escritor. El escritor además puede agregarle — Caddy no tiene equivalente de `location ~`, así que en vez de emitir un `handle` de prefijo que SE PARECE, lo manda al acta. Parecerse es peor que faltar. Y un bug del lector de apache, encontrado probando: `ProxyPass` tiene dos formas y dentro de `<Location>` lleva sólo la URL. Mirar sólo la de tres tokens dejaba sin traducir la forma más común y el acta la reportaba como «no reconocida» — un falso negativo que manda a escribir a mano algo que el lector sí sabe hacer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 18:27:32 +00:00
SergioandClaude Opus 5	033913bb4a	traducir.py: nginx → caddy, con acta — y validar con el binario real cazó un bug que CAMBIABA el sentido ... Cambiar de nginx a caddy es reescribir la configuración. `traducir.py` hace la parte mecánica y dice CON NÚMERO DE LÍNEA lo que no pudo traducir. Doctrina heredada de `soltar`/`paskaq` (tawasuyu): su dominio es otro —datos presos en formatos cautivos— pero sus principios son los que hacían falta. **Elisión honesta**: lo que no se pudo traducir se reporta con su línea y su motivo, porque un traductor que descarta en silencio te deja un servidor sin una redirección o sin una regla de auth y el sitio parece funcionar. **No adivinar en silencio**: cada heurística queda como decisión explícita. **Procedencia**: cada bloque dice de qué línea salió. ⚠ **Validar con el caddy real destapó dos bugs que leer la salida no mostraba:** 1. `ambiguous site definition` — en nginx dos `server` con el mismo nombre se distinguen por su `listen`; en Caddy, por el esquema de la dirección. 2. **El grave**: un `if (...) { return 403; }` salía como `respond 403` INCONDICIONAL — el sitio entero devolviendo 403. La directiva estaba dentro de un bloque declarado intraducible y se absorbía igual al de afuera. Es peor que la pérdida silenciosa: no pierde, CAMBIA el sentido. Ahora todo lo que vive en un bloque opaco sale `SIN-TRADUCIR` con su motivo. Con los dos arreglados: `Valid configuration` según el caddy del propio corpus. Y es honesto sobre su alcance: traduce el núcleo común y declara el resto. Uno que cubre el 70 % y dice cuál es el 30 % restante es útil; uno que aparenta cubrir el 100 % es una trampa. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 17:46:44 +00:00
SergioandClaude Opus 5	68fdd9eb72	mudanza: el perfil — el software del servidor nuevo se DECLARA, no se instala a mano ... `declarar.py --perfil-out` emite un `[perfil.<label>]` listo para `targets.toml`, generado desde el censo: cada raíz está ahí porque un servicio que CORRÍA la necesita y takana tiene receta. Por qué un perfil y no una lista de `install`: mudar servicio por servicio a una caja viva va contra el diseño —el software de una máquina se declara y viene en la imagen, reproducible y firmado— y un servidor armado a fuerza de instalaciones sueltas no se puede volver a construir. Que es justo el problema que esta mudanza existe para no repetir: el `caddy` de gioser no tiene dueño ni receta y se pierde con la máquina. Y hay un impedimento medido, no estético: `takana install` REPRODUCE desde fuente y eso exige el lab entero en el cliente (SDD 28 §5.4), que una caja de destino no tiene. El perfil lo resuelve por el lado correcto: el software entra al armar la imagen, en el hub, que sí tiene lab. Del censo de gioser salen `caddy`, `gitea`, `python3` (agrupado: lo piden python3 y uvicorn). Verificado que el instrumental lo acepta: `targets.py gioser-mudado` expande a 33 raíces. ⚠ Y dice lo que NO puede cubrir, uno por uno con su motivo: 34 servicios entre `suelto`, `paquete-ajeno` y `desconocido`. Un perfil que se calla lo que le falta sale N/N describiendo un servidor incompleto — la lección de `foot` en escritorio-sway. Con esto la mudanza produce TRES documentos declarativos que reconstruyen el servidor desde cero: el perfil (qué software), la semilla (qué corre y cómo) y el plan (qué datos, en qué orden). Ninguno es un log de lo hecho: los tres son entradas que se vuelven a ejecutar. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 17:16:16 +00:00
SergioandClaude Opus 5	8ad9f0490d	planear: alternativas por familia funcional, con una recomendación que no es gusto ... Un servicio casi nunca es insustituible. `planear.py` agrupa por familia (servidor web, base de datos, caché, forja git, contenedores, dns, correo, base vectorial), muestra qué equivalentes tiene takana —marcando sellado / receta sin sellar / no está— y recomienda. Pero no «el mejor» en abstracto: un gusto disfrazado de dato es peor que no recomendar. Los criterios son hechos comprobables, en orden: 1. **El que ya corre, si takana lo construye** — porque cambiar de servidor web no es cambiar un binario: es REESCRIBIR la configuración entera, y eso casi siempre pesa más que cualquier ventaja teórica del otro. 2. Si el que corre no está en el catálogo pero un equivalente sí, se recomienda ése (takana puede construirlo, firmarlo y reproducirlo) diciendo lo que cuesta. 3. Si no hay ninguno, se dice. **No se sugiere «usá otro» cuando ese otro tampoco está.** Probado contra el catálogo real: `caddy` → se queda (ya corre y está sellado); `nginx` → recomienda caddy nombrando el costo; `redis` → «recomendado: NINGUNO», porque ni redis ni valkey ni memcached están en el corpus. ⚠ Y el dato que la recomendación destapa, que vale más que la recomendación: de servidores web el corpus sólo tiene **caddy y traefik**. No hay nginx ni apache. Si se elige un equivalente queda en el censo (`alternativa = "…"`) y el plan lo dice en su paso, con la advertencia arriba de todo: la configuración del origen no sirve tal cual. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 17:07:05 +00:00
SergioandClaude Opus 5	6f5cc2629a	mudanza: de dónde sale cada binario — y la herramienta corrigió un error mío ... «Instalá el paquete» es lo que uno ya sabía. La respuesta útil sale de cruzar dos hechos: quién posee el fichero en el ORIGEN (el censo se lo pregunta al gestor de paquetes de esa máquina, en un lote) y si el corpus de takana tiene una receta con ese nombre. receta-takana → instalarlo del repo firmado, NO copiar el binario paquete-ajeno → escribir receta, o qorpa (ADR 0015) suelto → nadie lo provee: llevarlo con su entorno o escribirle receta Medido sobre gioser (37 servicios vivos): 4 receta-takana · 4 paquete-ajeno · **11 SUELTOS** · 7 sin binario legible. Los sueltos viven en `/usr/local/bin` o en un home (`qdrant`, `matilda`, `pacha-secretos`, `act_runner`, `shuma-gateway`) y son los que se pierden al apagar el origen. Sorpresa medida: `/usr/bin/caddy` tampoco tiene dueño — está puesto a mano. **Y corrigió un error mío**: en el SDD 28 escribí que `gitea` no tenía receta y que «es la que más peso tiene». Las dos cosas falsas — `recipes/gitea.toml` existe y está sellada. Lo afirmé de memoria; el programa fue a mirar. Corregido allá con la nota. **Y un fallo del clasificador, que vale como regla**: calculaba la raíz del repo con un `dirname` de menos, no encontraba ninguna receta y contestaba `suelto` A TODO, incluido `caddy`. Un clasificador que contesta siempre lo mismo no clasifica. Ahora falla ruidosamente si no encuentra el catálogo, en vez de dar una respuesta falsa con forma de respuesta. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 17:02:52 +00:00
SergioandClaude Opus 5	808e4a4660	install-image: UNA imagen que arranca por BIOS **y** por UEFI ... «Instalable en Hetzner o en cualquier otro servicio» se rompía en el arranque: Hetzner Cloud arranca BIOS y otros proveedores sólo ofrecen UEFI. Tener dos imágenes hermanas obliga a elegir por proveedor y a que diverjan — y ya divergían: la hermana EFI documenta etiquetas `takana-*` que su propio código no escribe (corregido en este commit; son `hammer-*` y están congeladas a propósito por el ADR 0016, porque viven en sistemas YA INSTALADOS). Layout nuevo: `p1` BIOS-boot · **`p2` ESP FAT32** · `p3` `/` · `p4` estado · `p5` store (última, la que crece). El `core.img` de i386-pc y el `BOOTX64.EFI` de x86_64-efi apuntan **los dos** a `(hd0,gpt3)/boot/grub`: **un solo `grub.cfg`, una sola línea de comando, un solo sitio donde editarla.** La ESP se puebla con mtools, sin root y sin loop, como el resto del script. No se usa EFI-stub directo acá (sí `install-image-efi.sh`, ADR 0010): el stub por la ruta fallback recibe LoadOptions VACÍO y necesita la cmdline HORNEADA en el kernel; la de `linux-generic` sólo trae la consola, sin `root=`. Hornearla ataría la línea de comando al ArtifactHash del kernel. Verificado con LA MISMA imagen en los dos firmwares, hasta entrar por SSH: UEFI (OVMF) → /sys/firmware/efi presente · PID1 arje-zero · raíz sda3 · store sda5 BIOS (SeaBIOS)→ /sys/firmware/efi ausente · PID1 arje-zero · raíz sda3 · store sda5 Si falta `grub-mkimage` con x86_64-efi o mtools, la ESP se saltea con un aviso que dice qué se pierde —no en silencio—: la imagen sigue arrancando por BIOS, pero eso la ata a esos proveedores. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 16:47:54 +00:00
SergioandClaude Opus 5	96dc488842	mudanza: recomendaciones CON MOTIVO, y la lista completa a la vista para elegir ... Correr en el origen no significa que aplique en el destino. `planear.py --revisar` muestra todo agrupado con su recomendación **y su razón**, y `--decide` deja aceptarlas en bloque o revisarlas una por una. Cuatro familias que no aplican en una caja remota, cada una con su motivo: · hardware local → bluetoothd, ModemManager, upowerd, adb · escritorio o pantalla → waypipe · la red del destino → NetworkManager, dhcpcd: **pelearían** con el init de allá · lo provee el init destino → udevd, dbus-daemon, elogind, polkitd, agetty 11 de 37 servicios de gioser caen ahí. El motivo no es cortesía: una recomendación sin razón no se puede discutir, así que o se acepta a ciegas o se ignora entera. **Y la recomendación DERIVADA, que es la más fuerte**: si el binario vive en un árbol que no se muda, el servicio no podría arrancar allá. Se calcula cruzando el `cmdline` leído de `/proc` contra las decisiones de datos. Probado en los dos sentidos: con `/mnt/vvv` muriendo, `puerta-f6e393ff` sale «no mudar — su binario vive en /mnt/vvv»; con `/mnt/vvv` mudándose, sale «mudar». Por eso la revisión decide los DATOS PRIMERO: de ellos se deriva la recomendación de los servicios, y al revés no se puede calcular. Y los datos salen SIN recomendación a propósito — qué datos valen no se deduce de la máquina; `terapeuta.ec` eran 279 M sin DNS y sólo el usuario podía decidirlo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 16:27:58 +00:00
SergioandClaude Opus 5	d682b9b240	mudanza: el APLICADOR — idempotente, reanudable, y que no marca como hecho lo que no ejecutó ... `aplicar.py` ejecuta un plan. La regla que lo define: **un paso que no se ejecutó no se marca como hecho**. Un plan tiene pasos ejecutables y pasos MANUALES cuyo `cmd` son comentarios («instalá el paquete», «cambiá el registro A»); un aplicador que ejecuta un bloque de comentarios obtiene exit 0 y lo marca «ok» — la peor mentira posible, porque deja el servicio caído con el informe en verde. Acá quedan `pendiente-humano`, la corrida sale con ≠0, y `--hecho N` los confirma — negándose si el paso sí tenía comandos («corrélo, no lo marques»). Se le cree a la VERIFICACIÓN, no al exit code: el rsync que llenó el disco devolvió 0 y dejó 1367 artefactos vacíos. Si el comando sale bien y la verificación falla, queda `sospechoso`. Y las verificaciones van TIPADAS (`cmd`/`humano`): «la columna Available debe ser > X» no es un comando. Estado reanudable en `<plan>.estado.json`, escrito con temporal + fsync + rename — la lección que costó un upgrade entero en el SDD 28. **Y un fallo propio, encontrado en la primera corrida real**: la verificación del paso de datos imprimía el número de directorios vacíos y devolvía 0 igual. Dio «✓ verificado: 2» donde ese 2 eran dos vacíos en destino. Un guardián que siempre pasa no es un guardián. Ahora COMPARA los ficheros de los dos lados y falla si difieren. Probado con rotura a propósito y con el control que debe pasar: copia no hecha ⇒ origen=5 destino=0 ⇒ FALLA; copia hecha ⇒ 5 y 5 ⇒ PASA. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 15:20:15 +00:00
SergioandClaude Opus 5	1a89592b72	mudanza etapa 3: declarar.py — de «corre y nadie sabe cómo» a una Semilla que arranca ... Copiar un binario no lo levanta al arrancar. Esto toma la invocación que el censo leyó de `/proc` y emite `seed.card.json`. Medido sobre gioser: **37 de 37 servicios vivos declarados, cero fallos**, y la tarjeta de caddy sale con su invocación real — exactamente lo que faltaba para que no muriera en el próximo reinicio. Por qué no alcanza con `arje-absorb`: absorb lee la DECLARACIÓN del init ajeno, que es justo la que miente (`rc-status` daba `stopped` para cinco servicios vivos), y los `no-declarado` no aparecen en ninguna declaración por definición. Absorber la declaración reproduce el agujero. Se complementan. Tres reglas: 1. Un servicio sin `cmdline` legible NO se emite y se dice: una tarjeta que no arranca es peor que una ausente — la ausente falla ruidosamente, la rota deja el servicio caído en silencio. 2. El `cwd` se preserva ENVOLVIENDO, porque el payload `Native` acepta `exec`/`argv`/`envp` y no `cwd` (comprobado sobre la semilla real). 9 de 37 servicios de gioser dependen de su directorio. 3. IDs deterministas ⇒ misma entrada, misma semilla BYTE A BYTE (verificado con sha256). Un fichero generado que cambia en cada corrida no se puede revisar con `diff`. **Y un bug del censo que costaba el 70 % del dato**: `cmdline` y `cwd` se leían en un solo comando, y como `readlink /proc/<pid>/cwd` exige permiso de ptrace, en cualquier proceso de root el comando entero salía ≠0 y se descartaba TAMBIÉN el `cmdline`. 26 de 37 servicios quedaban sin invocación. Sondas separadas. **Una sonda que falla es un dato; no puede arrastrar a las que funcionaron.** Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 15:13:53 +00:00
SergioandClaude Opus 5	6f12c231fa	mudanza etapa 2: el PLAN — exportable, con el comando literal de cada paso ... `planear.py` convierte un censo decidido en un plan ejecutable. Cada paso lleva su COMANDO LITERAL y su verificación, así que el fichero se ejecuta a mano, línea por línea, sin la herramienta y sin este repo. Eso es lo que el usuario pidió como «pasos exportables». Las tres reglas, cada una pagada en el SDD 28: 1. **Nada sin decidir se ejecuta**: aborta con código 2 listando qué falta. El silencio no es consentimiento — sin decisión, ni mudar ni matar es correcto. Probado en los dos sentidos. 2. **Lo que muere se dice por su nombre y con su tamaño ANTES de borrar**, y el paso no borra nada: es una lista para leer antes de apagar el origen. 3. **Cada copia se verifica EN DESTINO**: el `rsync` que llenó el disco devolvió 0 y dejó 1367 artefactos vacíos; sólo se vio contando del otro lado. Y el preflight dimensiona con el tamaño de COPIA (hardlinks expandidos, 60 G → 85 G medidos), no con `du`; si un tamaño resulta ilegible lo dice en vez de contarlo como 0. **El añadido que cambia el valor: la invocación real.** Decir «este servicio no está declarado» nombra el problema; lo que hace falta para resolverlo es cómo corre AHORA. El censo lo lee de `/proc` (`cmdline` + `cwd`, nunca `environ`: el entorno trae tokens) y el plan lo emite: # cmdline: /mnt/vvv/tawasuyu/target/debug/deps/puerta-f6e393ffbef3999e # cwd : /mnt/vvv/tawasuyu/shared/tejido # puertos: 34221, 44961 Ese servicio de gioser es un binario de `target/debug/deps/` corriendo en producción, con dos puertos, que ninguna declaración conoce. Apagada la máquina vieja, eso no se reconstruye de memoria. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 15:03:33 +00:00
SergioandClaude Opus 5	5d1120e583	censar: la sonda de dominios dejó a gioser incomunicado — «sólo lee» era falso ... Censar gioser en `--local` disparó 29 peticiones HTTPS a sus propios dominios. Varios devuelven 502, y su `fail2ban` (jaula `caddy-backend-down`) **baneó la propia IP de la máquina**: gioser dejó de poder hablar con su propio gitea y los `git push` empezaron a fallar con «Could not read from remote repository». Un censo que deja la máquina incomunicada no es de sólo lectura. **La frase del script era la mentira**: «sólo lecturas, no se toca nada». No escribe nada, cierto — pero leer POR RED tiene efectos. Corregida. Tres arreglos: 1. **La sonda no se hace contra uno mismo.** Por defecto sólo con `--host`; en `--local` se saltea y se avisa por qué, con `--probe` para forzarlo. Además es metodológicamente mejor: lo que interesa es qué ve EL MUNDO, no qué ve la máquina de sí misma. 2. **Espaciada** medio segundo entre dominios, para no parecerle un escaneo al fail2ban del objetivo. 3. Clase nueva `sin-sondear`, para que un dominio sin datos no se confunda con un fósil. Desbaneado 204.168.193.248 de `caddy-backend-down`. Y queda la regla: **antes de sondear una máquina, pensar qué defensa propia le estás disparando.** Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 14:53:05 +00:00
SergioandClaude Opus 5	95c16097e4	SDD 29 + censar.py: la mudanza como PRODUCTO — censo, plan, aplicación. Sin IA. ... Corrección de rumbo pedida por el usuario: el SDD 28 derivó hacia «poner ESTA caja a punto» — instalar caddy, copiar claves, montar discos—, y eso es configurar un servidor, no construir algo. **caddy no es un hueco de la imagen: es una instalación particular del usuario, y el programa tiene que DESCUBRIRLA, no traerla.** Y la consecuencia de método: todo lo que hice a mano en el SDD 28 ES la especificación de este programa. Cada paso fue determinista; el único juicio fue «¿esto se muda o muere?», que es justo lo que se le pregunta al usuario. No hace falta IA: hace falta que esté escrito. **Etapa 1 implementada: `scripts/mudanza/censar.py`.** Sólo lee. Cruza lo DECLARADO contra lo VIVO y reporta tres clases, cada una justificada por un error medido: - `rc-status` decía `stopped` de cinco servicios que estaban VIVOS ⇒ la verdad es `ppid==1`, no el init. - De 29 dominios, 10 vivos: 13 sin DNS, 2 en 502 y **4 que ya resuelven a otra máquina** — por eso se compara la IP del DNS contra las de la máquina, o `ya-mudado` se lee como `vivo`. - `du -sh` no dice cuánto ocupa COPIAR con hardlinks (60 G vs 85 G): se reportan los dos. - Los nombres no coinciden (`act-runner`/`act_runner`, `crond`/`cronie`, `dbus-daemon`/`dbus`): sin normalizar, el mismo servicio sale a la vez como `no-declarado` y `declarado-muerto`. - Lo descartado se CUENTA: un `ppid==1` que no es servicio suele ser un huérfano, y eso es hallazgo. Probado contra gioser, donde las respuestas ya se sabían a mano: encuentra MÁS (29 dominios contra los 19 que probé; apareció `hifas.gioser.net`). Y afinarlo importó: la primera versión daba 28 `no-declarado` con ruido, la segunda da 18 y son reales (`matilda`, `pacha`, `puerta-…`, `adb`). Un guardián con hallazgos falsos se ignora entero. El SDD deja escritas las etapas 2 (plan exportable: el fichero ES la interfaz) y 3 (aplicación idempotente que verifica EN DESTINO y deja el server corriendo), y mide qué ata la imagen a Hetzner: menos de lo que parece — BIOS vs UEFI y los metadatos de red. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 14:51:08 +00:00
SergioandClaude Opus 5	77cda9a865	install-image: un filesystem etiquetado hammer-work se monta en /work ... Convención opcional, no requisito: la imagen no crea esa partición y si la etiqueta no existe el arranque no hace nada ni avisa. Existe por un caso concreto. Al mudar el store de la caja de producción al volumen, la partición local del store —69,8 G de un disco de 76,3— quedó huérfana: re-etiquetada para que el `findfs` del arranque no la confundiera con el volumen, y sin montar. La caja tenía 70 G de disco ocioso mientras `/store` iba al 80 %. `/work` es el destino natural: es donde un HUB pone lo pesado —`work/sources`, los tarballs, el `CARGO_HOME`—, que en gioser son 85 G y que no cabe ni conviene en una raíz de 6 G. En la caja: `sda4` re-etiquetada `hammer-work`, REFORMATEADA (traía los 61,5 G del store viejo, anterior a la cosecha; control antes de borrar: el store vivo tiene 1579 artefactos y el respaldo 3140) y `/opt/takana/work` pasa a ser un enlace a `/work`. Verificado tras reiniciar: se monta solo, 68,1 G con 64,6 G libres, y los manifiestos siguen donde `build-state.py` los busca. La caja usa ahora su disco entero: `/` 5,8 G · `/var/lib/hammer` 487 M · `/work` 68,1 G local · `/store` 97,9 G en el volumen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 14:01:23 +00:00
SergioandClaude Opus 5	d1d6645bd0	respaldo: una guarda que evita BORRAR el historial de git del Storage Box ... Encontrado corriendo el respaldo desde la caja de producción (SDD 28, puerta 7). El paso [2/3] sube el repo **con `--delete`** —correcto: para eso está git—. Pero el `/opt/takana` de la caja llegó por `rsync --exclude=.git`: es una COPIA, no un clon. Una corrida real desde ahí no habría subido menos cosas: **habría borrado del respaldo todo lo que le falta al origen, empezando por `.git`** — el historial entero. Y en silencio, porque rsync haría exactamente lo que se le pidió. Ahora falla ruidosamente si la raíz no tiene `.git`, con `REPO_INCOMPLETO=1` como escotilla para el caso deliberado. Probado en los tres sentidos: en gioser (con `.git`) pasa; en un árbol sin `.git` aborta; con la escotilla pasa igual. **Y el store tampoco estaba donde el script creía.** Usaba `$RAIZ/store` cableado — en gioser es un bind-mount dentro del repo, pero en una caja takana instalada es una partición en `/store`, así que el paso [3/3] moría con `change_dir "/opt/takana/store" failed`. Peor: rsync devuelve 23, que está en la lista de reintentables, así que el bucle lo reintentaba — exactamente el cuadro que la cabecera de este script ya documenta («un error reintentable que se repite 40 veces no es un corte de red: es algo estructural»). Ahora `STORE` es env y hay una guarda ANTES del bucle que aborta si no existe. Con eso el `--seco` completa los tres pasos desde la caja y lee la ocupación del box (111 G de 1 T). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 03:04:24 +00:00
SergioandClaude Opus 5	4190c7b43e	atuq §6.7: entra el motor de inferencia local — y SOURCE_DATE_EPOCH le había apagado el AVX2 ... La IA local de la barra lateral (§6.7) y la mitad semántica del archivo personal (§6.3) figuraban como dos pendientes distintos. Son uno: el corpus no tenía con qué correr un modelo. `pluma-llm` sólo trae backends de NUBE y `rimay-verbo-fastembed` DESCARGA onnxruntime (glibc) y el modelo de HuggingFace en el primer arranque. `recipes/llama-cpp.toml` (b10901, estática, 199 M) derriba el muro entero: el mismo binario sirve `/v1/chat/completions` y `/v1/embeddings`. ⚠ Lo que este commit deja medido, y es lo que no se podía deducir: el PRIMER sello llevaba sólo `-DGGML_NATIVE=OFF` —leído en `ggml/CMakeLists.txt:141`, que con NATIVE=OFF debería ENCENDER las perillas explícitas de ISA— y salió con CERO instrucciones vectoriales. La causa está 36 líneas más arriba: `if (CMAKE_CROSSCOMPILING OR DEFINED ENV{SOURCE_DATE_EPOCH})` apaga `GGML_NATIVE_DEFAULT`, y el sandbox de takana exporta `SOURCE_DATE_EPOCH=1` (`sandbox.rs:453`) justamente para que los builds REPRODUZCAN. O sea: la variable que nos da reproducibilidad apagaba todas las instrucciones vectoriales del motor de inferencia — y no falló nada. El artefacto selló, `--version` contestaba, y el binario era x86-64 pelado: 0 `%ymm`, 0 `vfmadd`, 0 `roundps` en 1.634.770 líneas de `objdump -d`. Ahora las seis van declaradas una por una y el `install` LAS COMPRUEBA en el binario: 42.356 `%ymm` / 1.298 `vfmadd` / 86 `roundps`. `strip_debug = true` porque zig cc emite debug_info por defecto y son 16 binarios estáticos: 1,8 G → 199 M. Guardián `scripts/test-llama-cpp.py`, sobre el artefacto VIGENTE (resuelto por `takana hash`, no por `ls store/*`) y con control negativo vivo (`--sin-modelo`, que TIENE que fallar): ISA, hermético (0 NEEDED), una pasada de inferencia REAL con `stories260K` pineado por sha256, y el endpoint de embeddings — vector de verdad, el mismo texto da el mismo vector, dos textos distintos dan vectores distintos, y no son ceros. Y `verificar-repro.sh`: REPRODUCE, 0 no-determinismos. ⚠ Esto es el MOTOR, no la función. Un motor sin modelo no contesta nada: el modelo de producción es fuente pineada aparte, como el perfil de PGO de firefox, y es su propia unidad de trabajo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GqBhowvFe3aiieGCKgvxwa	2026-09-11 03:03:31 +00:00
SergioandClaude Opus 5	01b1dcfefe	respaldo: el rsync del propio corpus no podía correr el respaldo del propio corpus ... Corriendo el respaldo desde la caja de producción (SDD 28, puerta 7): ==> [1/3] estado (el grafo: qué había construido y con qué hash) unknown compress name: zstd !! estado: error 4 que NO es de red — no reintento El script exige `--compress-choice=zstd` (medido: el doble de rendimiento efectivo, porque el 79 % del store son secciones `.debug_*` y comprimen como texto) y **`recipes/rsync.toml` lo construía con `--disable-zstd`**. El comentario de la receta decía por qué: «deps externas quitadas (no en catálogo)». Ya no es cierto — `zstd` tiene receta y está sellada. Dos arreglos, y los dos hacen falta: 1. **La receta enciende zstd** (dep `zstd`, fuera el `--disable-zstd`). Control en los dos sentidos: el rsync nuevo lista `zstd zlibx zlib none`, el anterior `zlibx zlib none`. Radio cero: `rsync` no es dep de ninguna receta (medido), así que no re-hashea nada más. 2. **El script DEGRADA en vez de morir.** Detecta el soporte (`rsync --version` → «Compress list») y cae a zlib avisando. Un respaldo que no corre por un algoritmo de compresión es peor que un respaldo lento — y el fallo era especialmente malo porque el error 4 se clasifica como "no de red" y el script no reintenta: el respaldo simplemente no se hace. Y de paso queda cubierto el caso de un hub que todavía no reconstruyó su rsync. **También la raíz cableada**: el script hacía `cd /mnt/vvv/takana` por defecto —la ruta de gioser— así que desde cualquier otro hub moría con `No such file or directory`. Ahora se deriva de la ubicación del script, como el resto de `scripts/`; el override por `RAIZ` se conserva. Control: en gioser sigue resolviendo a `/mnt/vvv/takana`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-11 02:59:13 +00:00
Sergio	10c499777e	atuq §6.5.bis: la extensión foco — muestra el foco del sistema y no tiene con qué apagarlo ... La mitad del navegador del §6.5, deliberadamente asimétrica: sólo lee. Pregunta `focus.state` (nuevo en puriy-costura, commit 38815b5f3) y pinta tres estados — `foco`, nada, y `?` cuando nadie escribió el estado. Ese tercero es el que importa: si «no sé» se redondeara a «apagado», la insignia afirmaría que no hay foco sin haberlo mirado. No hay verbo para apagarlo, y es la propiedad y no un pendiente: si el navegador pudiera levantar el foco, valdría lo que vale un bloqueador de extensión. En tawasuyu hay un test que lo fija; acá el guardián mide el EFECTO — tras una sesión entera, el fichero de estado quedó igual. `scripts/test-atuq-foco.py` corre los tres estados sobre el path de PRODUCCIÓN (`/etc/takana/focus`), no la escotilla de pruebas: una escotilla mide el código, no el contrato con la imagen. Verde sobre el artefacto vigente (atuq 5d1afc50, puriy-costura 0de6b4ca), y verificado rompiéndolo — con una extensión parcheada que pinta «foco» siempre (en una COPIA del artefacto, vía ATUQ_DIR), falla nombrando la insignia.	2026-09-10 23:17:32 +00:00