Sergio
98c9e4daa6
Cuatro arranques fríos en serie, el perfil partiendo del 5 que dejó la corrida del umbral: S1 pin 0 antes 5 después 1 el navegador ✓ +97 s S2 sin pin antes 1 después 2 el navegador ✓ +98 s S3 sin pin antes 2 después 3 (matada a los 60 s) S4 sin pin antes 3 después 4 EL DIÁLOGO ✗ en 420 s Tres cosas: · la tasa, por fin con perfil sano: dos corridas independientes y pegadas, +97 y +98 s, contra los +123/+195/+197/+204 de antes. Con el anfitrión descargado el mismo artefacto pinta en la mitad del tiempo ⇒ el número es de la máquina y la carga tanto como del producto, y se publica con sus condiciones; · el umbral se reprodujo solo y en otra secuencia: S4 arrancó con 3, sumó a 4 y abrió el diálogo — segunda medición independiente del mismo borde, esta vez identificando la ventana por `min_size` y no por el título (que está traducido, así que un grep por «Troubleshoot Mode» en una imagen en castellano no engancha y su ausencia se lee como la conclusión contraria); · ⚠ y una corrida que PINTA no limpia el contador: S2 pintó y dejó 2. Más todavía, `toolkit.startup.last_success` vale lo mismo en las CUATRO (1789494795, las 17:53) ⇒ el gancho de cierre no corrió ni una vez, ni en las que pintaron. Pintar no es terminar de arrancar. Entonces «quién limpia el contador» SIGUE SIN MEDIR, y el propio documento decía que esta serie lo cerraría: no lo cierra, y queda escrito así. Hace falta una corrida que deje al navegador terminar de arrancar y salir limpio. Lo más caro es para el instrumento: con `--until-paint` cada corrida suma uno, pinte o no, así que una serie se rompe sola a la cuarta — que es lo que pasó ayer sin que nadie lo viera. El arnés ahora AVISA cuando el contador está en 3 («esta corrida va a abrir el diálogo, no el navegador») y la receta para una serie queda escrita: pinnear `--crashes 0` en cada corrida, que resetea la base (S1 lo muestra partiendo de 5). También cae una candidata mía, con un cero que viene con control (medido por la otra sesión): el pref no tiene default en este build, así que fijarlo en 0 SÍ se persiste y el «ausente» no era el pin.
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.