SergioandClaude Opus 4.7
fe1601e669
Nuevo crate hammer-overlay + integración al CLI. Diseño:
- API: try_overlay(targets, state_root) → OverlayId, status, discard, commit.
- Layout: <state>/<id>/{state.json, mounts/<slug>/{upper,work}}. El manifiesto
permite a `status` enumerar overlays sin estado en memoria.
- commit: desmonta primero, luego cp -a upper→lower por archivo, procesa
whiteouts (char dev 0/0) como remove en el lower. Sin diario aún (Fase 3).
- discard: umount LIFO + rm del state. Idempotente sobre `not mounted`.
- Privilegios: la librería no asume; emite `mount`/`umount` y deja que el
caller los tenga. CLI sin sudo falla con mensaje claro. El daemon de
Fase 5 los obtendrá desde contexto privilegiado.
Tests:
- 6 unit tests (slug, defaults, manifest, errores).
- E2E bajo bwrap+user-ns con CAP_SYS_ADMIN: ciclo try → escribir → commit →
verificar persiste; try → escribir → discard → verificar revertido;
remove en merged → commit → whiteout aplicado al lower. Gateado en
HAMMER_OVERLAY_TESTS=1: por defecto, los kernels deniegan el mount
overlayfs en user-ns no-privilegiado (sysctl/AppArmor); el dev habilita
cuando su entorno lo permite o corre con sudo.
CLI: hammer try [targets…] --state-root, commit <id>, discard <id>, status.
Refactor mínimo: las cmds que no tocan artefactos ya no abren (ni crean) el
store. `hammer status --state-root /tmp` no toca /store.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
90 lines
4.4 KiB
Markdown
90 lines
4.4 KiB
Markdown
# 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 `hammer` **sobre 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](adr/0002-alpine-first.md).
|
||
|
||
---
|
||
|
||
## Fases (sobre Alpine)
|
||
|
||
### Fase 0 — Laboratorio de build ✅
|
||
- [x] `hammer-core`: tipos `Recipe`, `ArtifactHash`, `Store` (BLAKE3, layout `/store`).
|
||
- [x] `hammer-build`: sandbox con `bubblewrap` + `zig cc` → binario musl estático.
|
||
- [x] CAS: hashing de entrada, caché por hash, sellado en el store.
|
||
- [x] `hammer build <recipe.toml>` → imprime el hash del artefacto.
|
||
- [x] Fuente git **y** tarball (sha256 fijado), patches opcionales.
|
||
- [x] Heurística de build system: autotools / cmake / meson / make plano.
|
||
- [x] Caché persistente de zig entre builds (~30s/build ahorrados).
|
||
|
||
### Fase 1 — Hidratación ✅
|
||
- [x] `hydrate(hash, target, mode)`: hardlink a FHS, `patchelf` para el caso dinámico.
|
||
- [x] `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 ▶ *en progreso*
|
||
- [x] Crate `hammer-overlay`: `try` / `commit` / `discard` / `status` sobre `overlayfs`.
|
||
- [x] Manifiesto persistente en `<state_root>/<id>/state.json`; `status` enumera.
|
||
- [x] `commit` promociona archivos y procesa whiteouts (char dev 0/0) como remove.
|
||
- [x] Subcomandos del CLI: `hammer try [targets…]`, `commit <id>`, `discard <id>`, `status`.
|
||
- [x] Tests E2E con bwrap+user-ns, gateados en `HAMMER_OVERLAY_TESTS=1` (kernel-dependiente).
|
||
- [ ] Hook al diario en `commit` (queda para Fase 3).
|
||
- [ ] Anidación real de overlays (un solo overlay activo por target hoy).
|
||
|
||
### Fase 3 — Diario de mutaciones
|
||
- [ ] `hammerd` con `fanotify` sobre `/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`; eventos `BUILD_*`/`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 `commit` humano.
|
||
|
||
---
|
||
|
||
## 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 `/store` y `/var/lib/hammer`.
|
||
- Log de transparencia para compartir en comunidad ([SDD 09](09-trust-model.md) §4).
|
||
- Mini-lenguaje de consulta del sistema para la IA ([SDD 08](08-ai-integration.md) §6).
|
||
|
||
---
|
||
|
||
## Estado actual
|
||
- ✅ Repo y workspace Rust inicializados.
|
||
- ✅ SDDs y ADRs redactados.
|
||
- ✅ Esqueletos de crates que compilan (`hammer build` stub).
|
||
- ⏭️ 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`.
|