Sergio
66db4e4054
MEDIDO al ir a declarar las recetas nuevas, y es más grande que ellas: de las 892 recetas selladas del corpus, **649 no están en NINGÚN perfil**. El 73% del catálogo está compilado y no viaja en ninguna imagen. No es deuda de build (drenaje.json dice 0) y la métrica de perfil NO lo puede ver: mide la clausura de lo DECLARADO. Es la lección de foot a escala de catálogo. Concreto: yazi, atuin, zellij, jujutsu, just, direnv, watchexec, mise, xh, age, rclone, restic, lazygit, difftastic, bottom y duf estaban selladas hace meses y en cero imágenes; y `helix` estaba declarada sólo en escritorio-gnome, que es donde menos sentido tiene. perfil.cli += esas 16 + las nuevas de hoy (btop, ncdu, nushell, aerc, cmus, syncthing). Cero recetas nuevas y cero builds: sólo dejan de ser invisibles. Como los CUATRO escritorios y `servidor` heredan `cli`, una sola edición los alcanza a todos. perfil.servidor += wireguard-tools: el kernel ya trae WireGuard (SDD 22) y no había con qué configurarlo — misma figura que el cortafuegos y el reloj que este perfil ya declaraba. Los cuatro escritorios += cups, bluez (punto 8 de PUBLICABLE, docs/20). Viven en el CORPUS y no en las colas por lo mismo que mpv y atuq: se alcanzan sibling-first→padre, una copia para los cuatro. ⚠ DEUDA DECLARADA, NO OLVIDO: las dos recetas traen su [[service]] y los perfiles NO los arrancan — de los cuatro escritorios sólo escritorio-gnome tiene lista `servicios`. Los otros tres no arrancan NADA, y eso es más grande que cups y bluez. Va escrito en el fichero para que se vea. El barrido de las 649 queda pendiente y es su propia unidad de trabajo: 363 son recetas Go importadas en tanda (herramientas de desarrollo) y NO todas deben entrar en una imagen. Comprobado con scripts/targets.py: los ocho perfiles resuelven, sin nombres desconocidos.
hammer
Una distribución Linux construida con un laboratorio funcional y hermético en el sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada desde el suelo para que una IA programadora entienda, modifique y comparta el sistema.
hammer no es otro gestor de paquetes inmutable. Es una arquitectura de dos mundos:
- El laboratorio compila desde fuentes upstream (commits fijados), de forma
determinista y aislada (
bubblewrap+zig cc+ musl estático), y direcciona cada artefacto por su hash (BLAKE3) en un content-addressed store. - El userland es un Linux clásico, mutable, con FHS de verdad (
/bin,/lib,/etc). Los binarios se hidratan desde el store por hardlinks. Puedes pisar archivos en caliente, romper cosas con unrm -rf, y revertir cuando quieras.
Entre ambos mundos viven las tres piezas que hacen a hammer distinto:
- Overlay de experimentación — prueba cambios sobre el sistema real con red de
seguridad;
hammer try/commit/discard. - Diario de mutaciones — un daemon
fanotifyregistra todo lo que tú (o la IA) cambiáis a mano. Vives imperativamente; el sistema genera el delta contra la base limpia. El diario es tu configuración — sin ser declarativa. - Manifiesto
.swm— compartes la receta de la mutación (parche de fuente + flags + ediciones de config), no el binario cocinado. El receptor reproduce y verifica; no confía en tu binario.
Encima de todo corre el bus de agente (/run/agent.sock): la IA habla un protocolo
pequeño y legible, dispara compilaciones, inyecta en el overlay, escucha fallos y reacciona.
Tú tienes la última palabra.
Estado
Fase de arranque. Validamos la capa AI-nativa sobre Alpine (musl + FHS ya cocidos)
antes de bajar a distro propia. Ver docs/10-roadmap.md.
Documentación de diseño (SDD)
Toda la arquitectura está en docs/. Empieza por
docs/00-vision.md y docs/01-architecture.md.
Estructura
crates/
hammer-core tipos compartidos: Recipe, Swm, hashing CAS, store
hammer-build el laboratorio: sandbox + compilación + hidratación
hammer-cli el binario `hammer` (build, hydrate, try, commit, apply, export…)
hammerd daemon: bus de agente + diario de mutaciones
docs/ SDDs y ADRs
Stack
| Capa | Decisión |
|---|---|
| Base de validación | Alpine (musl + FHS mutable) |
| Tooling / daemons | Rust (estático-musl) |
| Compilador del lab | zig cc por defecto, pluggable por receta |
| Sandbox de build | bubblewrap (namespaces) |
| Direccionamiento | BLAKE3 content-addressed store |
| Despliegue | Hidratación por hardlinks + patchelf |
Filosofía
La automatización es mi empleada en el sótano, pero en el piso de arriba mando yo.
Eficiencia matemática en la manufactura, libertad biológica en la ejecución.