SergioandClaude Opus 4.7
1fc8c97617
Cierra el primer entregable del roadmap. Cambios: - `Source`: ahora admite dos modos mutuamente excluyentes — `git` (repo+commit) o `tarball` (url+sha256). El hash de entrada del artefacto usa el commit en modo git y el sha256 en modo tarball; ambos son identificadores inmutables del contenido fuente. Validación en `Source::kind()` con error claro. - `fetch`: dispatch por modo. Tarball cacheado en `work/tarballs/<sha>.tar`, descarga vía `curl -fL`, verificación sha256 con `sha2`, extracción con `--strip-components` (default 1, GNU-style). - `recipes/grep.toml`: GNU grep 3.12 desde el tarball release de gnu.org (sha256 fijado, sin patches, `--disable-perl-regexp --disable-nls`). - Bootstrap: añade `binutils` al rootfs Alpine — configure de autotools mira ld/ar/ranlib incluso cuando el compilador real es zig cc. - `.gitignore`: `/work/` (artefactos transitorios del build). - `docs/10-roadmap.md`: Fase 0 y Fase 1 marcadas ✅; entregable cerrado. Nota sobre v3.11 vs v3.12: probé primero v3.11 y el binario producido daba "memory exhausted" en cualquier regex (bug conocido de grep+musl static al inicializar DFA). v3.12 corrige y funciona limpio dentro del rootfs Alpine. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
4.0 KiB
4.0 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 ✅
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.- Fuente git y tarball (sha256 fijado), patches opcionales.
- Heurística de build system: autotools / cmake / meson / make plano.
- Caché persistente de zig entre builds (~30s/build ahorrados).
Fase 1 — Hidratación ✅
hydrate(hash, target, mode): hardlink a FHS,patchelfpara el caso dinámico.hammer hydrate <hash> --into /.
🎯 Primer entregable (Fase 0 + 1) ✅
GNU grep 3.12 compilado estático desde el tarball upstream, sellado en el store
(b3:b81e893e…), hidratado por hardlink a /usr/bin/grep y ejecutado dentro del rootfs
Alpine vía bwrap — confirma el corazón "fábrica funcional → FHS mutable" sobre el
substrato Alpine. La VM/LXC dedicada queda como ejercicio de empaque, no como
pre-requisito de validación.
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.