sergio/takana

> 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 co…

Clonar por HTTPS, con el git de siempre

⎇ 8bf1623044075274682e4351a0f8e120047c2bed docs/10-roadmap.md Markdown · 80 líneas · 3.8 KB Historia crudo

Scaffold inicial: workspace Rust + SDDs completos 8bf162304 · sergio · hace 4 meses

1# SDD 10 — Roadmap
2
3## Estrategia: validar la capa AI-nativa sobre Alpine antes de la distro propia
4
5La innovación de `hammer` no es la distro — es el substrato AI-nativo (build determinista +
6mutable + diario + `.swm`). Construir bootstrap + init + userland de cero antes de validar esa
7capa sería arriesgar meses contra una hipótesis no probada. Por eso:
8
9> **Fase 0–6:** montamos `hammer` **sobre Alpine** (musl + busybox + FHS mutable, ya cocidos).
10> Validamos el bucle completo en semanas.
11> **Track posterior:** una vez probado, bajamos a distro propia (init propio, bootstrap propio,
12> userland propio) reusando todo el tooling sin retrabajo.
13
14Ver [ADR 0002](adr/0002-alpine-first.md).
15
16---
17
18## Fases (sobre Alpine)
19
20### Fase 0 — Laboratorio de build  ▶ *empezamos aquí*
21- [ ] `hammer-core`: tipos `Recipe`, `ArtifactHash`, `Store` (BLAKE3, layout `/store`).
22- [ ] `hammer-build`: sandbox con `bubblewrap` + `zig cc` → binario musl estático.
23- [ ] CAS: hashing de entrada, caché por hash, sellado en el store.
24- [ ] `hammer build <recipe.toml>` → imprime el hash del artefacto.
25- **Hecho cuando:** una receta compila reproduciblemente y queda en el store.
26
27### Fase 1 — Hidratación
28- [ ] `hydrate(hash, target, mode)`: hardlink a FHS, `patchelf` para el caso dinámico.
29- [ ] `hammer hydrate <hash> --into /`.
30- **Hecho cuando:** un artefacto del store aparece como `/bin/<x>` real y ejecutable.
31
32### 🎯 Primer entregable (Fase 0 + 1)
33**Compilar `grep` estático desde su repo con un patch, hidratarlo a `/bin/grep`, y que corra**,
34todo dentro de una VM/LXC Alpine. Esto prueba el corazón "fábrica funcional → FHS mutable".
35
36### Fase 2 — Overlay de experimentación
37- [ ] `try` / `commit` / `discard` / `status` sobre `overlayfs`.
38- **Hecho cuando:** puedes romper `/bin` en un overlay y revertir con `discard`.
39
40### Fase 3 — Diario de mutaciones
41- [ ] `hammerd` con `fanotify` sobre `/bin`,`/sbin`,`/lib`,`/etc`.
42- [ ] Log JSON-líneas append-only; `hammer journal`.
43- **Hecho cuando:** toda mutación trazable/opaca queda registrada y consultable.
44
45### Fase 4 — Formato y flujo `.swm`
46- [ ] `Swm` (de/serialización YAML), `hammer export`, `hammer apply` (con overlay), `verify`.
47- **Hecho cuando:** exportas un cambio, lo aplicas en otra máquina y reproduce idéntico.
48
49### Fase 5 — Bus de agente
50- [ ] `/run/init.control` (FIFO humano) + `/run/agent.sock` (JSON-líneas, `SO_PEERCRED`).
51- [ ] Comandos `COMPILE`/`INJECT`/`QUERY`/`INIT`; eventos `BUILD_*`/`CRASHED`/`MODIFIED`.
52- **Hecho cuando:** un cliente externo dispara un build y recibe el evento de fin por el socket.
53
54### Fase 6 — Integración de la IA
55- [ ] Cliente de agente; traductor intención NL → `.swm`; bucle plan→build→try→verify→propose.
56- **Hecho cuando:** una intención en lenguaje natural produce un cambio probado en overlay,
57  presentado para `commit` humano.
58
59---
60
61## Track posterior — distro propia
62- Reemplazar el init de Alpine por **tu init** (bus por pipes nativo).
63- **Bootstrap from-scratch** con `zig`/`musl-cross-make` (Stage 0/1/2 → imagen destino).
64- Userland propio (busybox/toybox a elección), `/etc/service/*` propios.
65- Decidir particionado/montaje de `/store` y `/var/lib/hammer`.
66- Log de transparencia para compartir en comunidad ([SDD 09](09-trust-model.md) §4).
67- Mini-lenguaje de consulta del sistema para la IA ([SDD 08](08-ai-integration.md) §6).
68
69---
70
71## Estado actual
72- ✅ Repo y workspace Rust inicializados.
73- ✅ SDDs y ADRs redactados.
74- ✅ Esqueletos de crates que compilan (`hammer build` stub).
75- ⏭️ Siguiente: implementar el sandbox de build real (Fase 0) y montar la VM/LXC Alpine.
76
77## Notas de entorno
78- Desarrollo principal: laptop del autor.
79- Host actual: Proxmox (`gioser.net`). La VM/LXC Alpine de pruebas vivirá aquí o en la laptop.
80- Repo: `https://gitea.gioser.net/sergio/hammer`.

10-roadmap.md

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.

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 §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 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.