Sergio
d570a8e03f
El enlace `~/.cargo/bin/go` del worker apuntaba a `/opt/hammer/.dev-fs/tools/go/bin/go` — la ruta de ANTES del renombre a takana (ADR 0016, 2026-09-09). `/opt/hammer` ya no existe, así que el enlace estaba COLGADO desde entonces. Nada falló. `go` lo invoca takana DEL LADO DEL HOST (`go mod vendor` durante el fetch, con red), fuera del sandbox, así que el rootfs no lo cubre — es el mismo modo de fallo que `patch` en agosto, y `vps-setup.sh` ya lo tiene escrito como regla: «toda herramienta que takana invoque HOST-SIDE va en esta lista». `go` no estaba. Cómo se descubrió: por casualidad, verificando reproducibilidad. 16 de 25 recetas Go murieron en SEGUNDOS. Un fallo sistémico se lee como 16 recetas rotas si nadie abre el error — el verificador manda la salida del build a /dev/null. El error era `spawn go mod vendor: No such file or directory (¿está `go` en el PATH del host?)`, que lo decía todo. Arreglado en el worker (enlaces repuestos a /opt/takana) y COMPROBADO con un build real: `gron` no construía, ahora construye y reproduce bit a bit (why-differs: 5 entradas idénticas, 0 divergen). Acá va la parte que evita la repetición: el script daba «go enlazado ✓» sin comprobar nada — `ln -sfn` crea un enlace colgado tan campante. Ahora repone un enlace colgado preexistente (avisando) y comprueba que RESUELVE ejecutando `go version` A TRAVÉS DE ÉL; si no ejecuta, sale 1 con el síntoma escrito. Un enlace que existe no es un `go` que corre. Probado en los tres sentidos, con control que TIENE que pasar: · enlace sano ⇒ ok, rc=0 · enlace colgado a /opt/hammer ⇒ avisa, lo repone, rc=0 · destino inexistente ⇒ falla ruidoso, rc=1
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.