Sergio
60202bf526
Primera prueba de `atuq` dentro de una imagen de disco arrancada, y el resultado no es el de la jaula. La cadena previa funcionó, y eso también es medición: el perfil `escritorio-cosmic` hidratado con el cierre de hoy (275 nodos, 8,4 G) trae `/usr/bin/atuq`, `/usr/bin/llama-server` y el modelo — declarar en el perfil SÍ pone las cosas en la imagen—, la imagen EFI de 12 G arranca en QEMU y COSMIC pinta panel y dock en ~2 min. Y `atuq` arranca —sus extensiones inician, la del foco sondea cada minuto, WebRender inicializa— sin que la ventana aparezca nunca. Descartado, para que nadie lo repita: no es el sandbox de Gecko (relanzado con los cinco MOZ_DISABLE_* puestos, idéntico), no es que el proceso muera (sigue ejecutando el JS de las extensiones), y no es la IA (pasa con about:blank). La pista: bajo sway headless el MISMO artefacto pinta perfecto y hay capturas del panel contestando. La diferencia son el compositor (cosmic-comp+llvmpipe contra sway+pixman) y el arranque real contra bwrap. Es su propia unidad de trabajo, no un parche apurado. ⚠ La lección del método: quince guardianes en verde, `vigia-imagen.py` en ✓, y el navegador igual no se puede usar en la imagen. «Sella», «hidrata» y «los tests pasan» son tres cosas distintas de «arranca y se ve». De paso, `metal-iso.sh` acepta ahora STORE y AUG por entorno, porque en esta máquina no funcionaba: arma el rootfs con `cp -al` desde el store y el store es un BIND-MOUNT del volumen — `linkat` rechaza cruzar mounts aunque sea el mismo disco, así que hay que nombrar los dos lados dentro del mismo mount. Es la cuarta vez que aparece el mismo EXDEV hoy.
Documentación de diseño de takana
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de takana | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
| 26 | atuq: el envoltorio Gecko |
Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no |
| 30 | Los servicios que trae un paquete | [[service]] en la receta → Card de arje; por qué arje-absorb no cubre una distro construida desde fuente; los tres árboles de servicios y cuál es el canónico |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.