Sergio
6809ef4be2
«simi» es boca/lengua en quechua. Es el sh que el frente C necesitaba: busybox está en la raíz de confianza del arranque (STAGE1_COMPONENTS, ATTEST_PATHS) y en el exec de cada card, y el candidato ajeno que se midió —brush 0.4.0— pesa 6,9 MB, arranca 4x más lento que el ash y trae dos divergencias medidas (#1394, #1396). Alcance MEDIDO, no supuesto: las 23 cards con shell (8 builtins, 13 construcciones), los 21 /init empotrados de las imágenes (+ if, funciones, case, aquí-documentos) y el POSIX de takana-live-install.sh. Resultado del banco diferencial, 159 casos contra el ash de busybox 1.36.1 (10 fixtures de regresión, 107 de tortura de comillas, 23 fragmentos de cards, 19 /init empotrados): simi DIVERGE=0 bash DIVERGE=8 brush DIVERGE=35 Incluye el bucle REAL de config.status que genera cualquier configure de autotools — el que tumbó a brush. 499 KB release, 1,4x la latencia del ash (brush: 4,1x). 47 pruebas propias en verde. Seis bugs que el banco destapó, y ninguno se veía sin un control al lado: 1. El lexer fundía lo entrecomillado con lo desnudo, así que x="a b" se ejecutaba como ORDEN y el error decía «no encontrado» — mandando a buscar al lugar equivocado. Ahora el comillado es por carácter. 2. Usaba la barra invertida como marca interna y la quitaba al final, así que una barra PRODUCIDA por una sustitución se perdía. La quita de comillas es sobre las comillas de la palabra, nunca sobre el resultado de una expansión: hace falta una máscara de protección, no un escape dentro del texto. 3. set -e no se suspendía dentro del cuerpo de una función llamada desde una condición. Ahora es un contador dinámico, que entra solo donde corresponde. 4. Los delimitadores de la sustitución de orden y de ${ } no respetaban la barra invertida: un paréntesis escapado cerraba la sustitución. 5. Las clases entre corchetes no entendían la barra invertida — y la del config.status de libtool es literalmente una clase con cuatro escapes. 6. Dentro de comillas dobles el cuerpo de un backtick sigue entre comillas, así que la barra también se elimina ante la comilla doble. Y uno que el banco NO vio y sí vio la prueba de regresión: el trap EXIT HEREDADO se disparaba en el subshell. POSIX §2.12 manda resetearlo — es la mitad complementaria del #1396 de brush, y al revés. Los dos oráculos hacen falta; el caso quedó agregado al fixture 08.
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.