sergioandClaude Opus 4.8
8bf1623044
Arranque del proyecto hammer (distro AI-nativa: laboratorio funcional en el sótano, terminal mutable clásica arriba, integración de IA programadora). - Workspace Rust (compila, tests verdes): hammer-core, hammer-build, hammer-cli (bin `hammer`), hammerd. - SDDs 00-10 + 6 ADRs en docs/ con toda la arquitectura. - Esqueletos navegables mapeados a las fases del roadmap; Fase 0/1 listas para implementar el sandbox real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
SDD 10 — Roadmap
Estrategia: validar la capa AI-nativa sobre Alpine antes de la distro propia
La innovación de hammer no es la distro — es el substrato AI-nativo (build determinista +
mutable + diario + .swm). Construir bootstrap + init + userland de cero antes de validar esa
capa sería arriesgar meses contra una hipótesis no probada. Por eso:
Fase 0–6: montamos
hammersobre Alpine (musl + busybox + FHS mutable, ya cocidos). Validamos el bucle completo en semanas. Track posterior: una vez probado, bajamos a distro propia (init propio, bootstrap propio, userland propio) reusando todo el tooling sin retrabajo.
Ver ADR 0002.
Fases (sobre Alpine)
Fase 0 — Laboratorio de build ▶ empezamos aquí
hammer-core: tiposRecipe,ArtifactHash,Store(BLAKE3, layout/store).hammer-build: sandbox conbubblewrap+zig cc→ binario musl estático.- CAS: hashing de entrada, caché por hash, sellado en el store.
hammer build <recipe.toml>→ imprime el hash del artefacto.- Hecho cuando: una receta compila reproduciblemente y queda en el store.
Fase 1 — Hidratación
hydrate(hash, target, mode): hardlink a FHS,patchelfpara el caso dinámico.hammer hydrate <hash> --into /.- Hecho cuando: un artefacto del store aparece como
/bin/<x>real y ejecutable.
🎯 Primer entregable (Fase 0 + 1)
Compilar grep estático desde su repo con un patch, hidratarlo a /bin/grep, y que corra,
todo dentro de una VM/LXC Alpine. Esto prueba el corazón "fábrica funcional → FHS mutable".
Fase 2 — Overlay de experimentación
try/commit/discard/statussobreoverlayfs.- Hecho cuando: puedes romper
/binen un overlay y revertir condiscard.
Fase 3 — Diario de mutaciones
hammerdconfanotifysobre/bin,/sbin,/lib,/etc.- Log JSON-líneas append-only;
hammer journal. - Hecho cuando: toda mutación trazable/opaca queda registrada y consultable.
Fase 4 — Formato y flujo .swm
Swm(de/serialización YAML),hammer export,hammer apply(con overlay),verify.- Hecho cuando: exportas un cambio, lo aplicas en otra máquina y reproduce idéntico.
Fase 5 — Bus de agente
/run/init.control(FIFO humano) +/run/agent.sock(JSON-líneas,SO_PEERCRED).- Comandos
COMPILE/INJECT/QUERY/INIT; eventosBUILD_*/CRASHED/MODIFIED. - Hecho cuando: un cliente externo dispara un build y recibe el evento de fin por el socket.
Fase 6 — Integración de la IA
- Cliente de agente; traductor intención NL →
.swm; bucle plan→build→try→verify→propose. - Hecho cuando: una intención en lenguaje natural produce un cambio probado en overlay,
presentado para
commithumano.
Track posterior — distro propia
- Reemplazar el init de Alpine por tu init (bus por pipes nativo).
- Bootstrap from-scratch con
zig/musl-cross-make(Stage 0/1/2 → imagen destino). - Userland propio (busybox/toybox a elección),
/etc/service/*propios. - Decidir particionado/montaje de
/storey/var/lib/hammer. - Log de transparencia para compartir en comunidad (SDD 09 §4).
- Mini-lenguaje de consulta del sistema para la IA (SDD 08 §6).
Estado actual
- ✅ Repo y workspace Rust inicializados.
- ✅ SDDs y ADRs redactados.
- ✅ Esqueletos de crates que compilan (
hammer buildstub). - ⏭️ Siguiente: implementar el sandbox de build real (Fase 0) y montar la VM/LXC Alpine.
Notas de entorno
- Desarrollo principal: laptop del autor.
- Host actual: Proxmox (
gioser.net). La VM/LXC Alpine de pruebas vivirá aquí o en la laptop. - Repo:
https://gitea.gioser.net/sergio/hammer.