Sergio
44b3624de6
Antes: dos reconstrucciones con las mismas entradas y el mismo lab daban artefactos
distintos. Ahora: `why-differs` da 464 entradas idénticas · 0 divergen.
Hash: 41eea38e… → a72b1626… (arrastra 37 dependientes directos, 39 transitivos).
── CAUSA 1: el AOT de QML compilaba un conjunto DISTINTO de funciones cada vez ─────────
`libKirigamiTemplates.so` cambiaba de tamaño (5.737.344 vs 5.795.072) y difería en 177
símbolos locales, todos `QmlCacheGeneratedCode…__invoke` y concentrados en CUATRO ficheros:
InlineMessage, LinkButton, NavigationTabBar y Badge.
Y esos cuatro son justo los que importan módulos QML HERMANOS del propio proyecto
(`org.kde.kirigami.platform`, `.primitives`, `.controls`). `qmlcachegen` sólo compila a AOT
lo que puede resolver de tipos, y los tipos del hermano salen de su `.qmltypes`, que produce
otro objetivo del mismo build. `src/templates/CMakeLists.txt` no declara `DEPENDENCIES`
ninguna ⇒ con ninja en paralelo es una CARRERA.
Control que sostiene el diagnóstico: `Chip` y `Heading`, del mismo directorio, no divergen —
y `kirigami-addons` y `kquickcharts`, que también llevan QML, reproducen. No es «QML es
no-determinista».
Arreglo: `-j1` en el compile. Orden topológico fijo ⇒ el cachegen ve siempre lo mismo.
NO es throttling (eso va por nice/taskset justamente para no re-hashear): es corrección, y
el re-hash es el precio que se paga a propósito.
Descartadas, con motivo: `-DQT_QML_NO_CACHEGEN=ON` apaga también el bytecode precompilado
(coste de arranque en el escritorio); `--only-bytecode` sería lo quirúrgico pero
`QT_QMLCACHEGEN_ARGUMENTS` es propiedad de objetivo y NO es INHERITED, así que no hay forma
de ponerla desde la línea de órdenes.
── CAUSA 2: el .tar.bz2 de plantillas se armaba sin orden ──────────────────────────────
`kde_package_app_templates` de ECM tiene camino reproducible —`--sort=name --mtime=@
SOURCE_DATE_EPOCH --numeric-owner --owner=0 --group=0`— pero detrás de `if(GNU_TAR_FOUND)`,
que exige que `tar --version` diga «GNU tar». El rootfs del lab es Alpine: `tar` es BUSYBOX
⇒ caía al respaldo `cmake -E tar cvfj`, que ni ordena ni normaliza. El orden lo ponía readdir.
Arreglo: `tar` (GNU tar 1.35, ya en el corpus) entra en `[deps] build`.
Comprobado mirando el artefacto, no deducido:
drwxr-xr-x 0/0 1970-01-01 00:00 ./
-rw-r--r-- 0/0 1970-01-01 00:00 ./CMakeLists.txt
-rw-r--r-- 0/0 1970-01-01 00:00 ./LICENSES/BSD-3-Clause.txt
owner 0/0, mtime al epoch (SOURCE_DATE_EPOCH=1 lo fija el sandbox) y la lista ORDENADA.
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/.