# 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  ▶ *empezamos aquí*
- [ ] `hammer-core`: tipos `Recipe`, `ArtifactHash`, `Store` (BLAKE3, layout `/store`).
- [ ] `hammer-build`: sandbox con `bubblewrap` + `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, `patchelf` para 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` / `status` sobre `overlayfs`.
- **Hecho cuando:** puedes romper `/bin` en un overlay y revertir con `discard`.

### 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`.