Sergio
c7097e4a91
El §7.undecies dejó la bóveda declarada y a NADIE capaz de abrirla: ninguna imagen traía un binario que sembrara `pacha_llavero::SEED_IDENTIDAD`. Esta es esa unidad. De las dos formas posibles entra `agora-cli`, y el motivo no es que sea mejor: el wizard `churay-welcome-llimphi` SÍ tiene binario (medido: `src/main.rs` sin `[[bin]]`, o sea que cargo lo descubre), pero decide además backend de IA, dotfiles, fondo de pantalla y chasqui — la experiencia de primer arranque entera, que no se decide dentro de una unidad del navegador. ⚠ Y antes de poder declararlo apareció lo que lo volvía imposible: sin `AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo "agora-dev" con un aviso por stderr y un ✓ en pantalla. La cadena que eso toca: frase → Argon2id → ChaCha20-Poly1305 que cifra la seed → la clave con la que `boveda` descifra su base. O sea, en una imagen de escritorio, la bóveda de todo el mundo cerrada con una palabra escrita en el fuente, y nada que falle. Arreglado en tawasuyu (`fd08dc03a`): variable > terminal (se pregunta, sin eco, y DOS veces en la génesis, donde un error de tipeo no se nota hasta que la seed ya no se recupera) > desarrollo sólo si no hay a quién preguntarle. La decisión vive en una función pura con cuatro tests, probada AL REVÉS: con el brazo `Preguntar` borrado falla con `left: Desarrollo / right: Preguntar`. Pin `9967b02c` → `da5fb8968` ⇒ `b3:46529e14`, 1,9 M, sellado en el worker con la guarda PEGADA al build. Mirado por dentro (regla 3) y probado como artefacto, con control negativo: `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys`, y con la frase equivocada contesta «autenticación fallida» y NO re-siembra. El muro del `Cargo.lock` por cuarta vez, con la causa cambiada: esta vez no la puso quien tocó el lock sino otro agente que metió `shuma-taller` en un `Cargo.toml`. Cerrado en el worker, donde el registro está completo: +1 línea. Y el lock del árbol compartido traía otra vez el malo (índice y árbol con dos versiones distintas, las dos rotas), así que el commit se armó con `commit-tree` sin pasar por el índice. Corrección al §7.undecies: el verbo es `agora-cli unlock`, no `agora-cli identity unlock`. El guardián de coherencia pasa de SEIS lugares a SIETE, con su cuarto control negativo; los cuatro, en verde. Queda: la herencia del llavero de SESIÓN entre procesos hermanos (sin medir — y `/proc/keys` como root no la mide), y `pacha`/`pacha-secretos` en `perfil.servidor` con el mismo hueco.
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.