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…

Ch'ipachiy HTTPSninta, git kaqllawan

⎇ a87b16dd852a3a6e7be7ad0f080b3ad97c75fdbc docs/10-roadmap.md Markdown · 95 siq'ikuna · 4.9 KB Ñawpa willay ch'uya

Fase 3 — diario de mutaciones (hammer-journal + fanotify + hammer journal) a87b16dd8 · Sergio · 4 killa ñawpaq

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  ✅
21- [x] `hammer-core`: tipos `Recipe`, `ArtifactHash`, `Store` (BLAKE3, layout `/store`).
22- [x] `hammer-build`: sandbox con `bubblewrap` + `zig cc` → binario musl estático.
23- [x] CAS: hashing de entrada, caché por hash, sellado en el store.
24- [x] `hammer build <recipe.toml>` → imprime el hash del artefacto.
25- [x] Fuente git **y** tarball (sha256 fijado), patches opcionales.
26- [x] Heurística de build system: autotools / cmake / meson / make plano.
27- [x] Caché persistente de zig entre builds (~30s/build ahorrados).
28
29### Fase 1 — Hidratación ✅
30- [x] `hydrate(hash, target, mode)`: hardlink a FHS, `patchelf` para el caso dinámico.
31- [x] `hammer hydrate <hash> --into /`.
32
33### 🎯 Primer entregable (Fase 0 + 1) ✅
34**GNU grep 3.12 compilado estático desde el tarball upstream, sellado en el store
35(`b3:b81e893e…`), hidratado por hardlink a `/usr/bin/grep` y ejecutado dentro del rootfs
36Alpine vía `bwrap`** — confirma el corazón "fábrica funcional → FHS mutable" sobre el
37substrato Alpine. La VM/LXC dedicada queda como ejercicio de empaque, no como
38pre-requisito de validación.
39
40### Fase 2 — Overlay de experimentación  ✅
41- [x] Crate `hammer-overlay`: `try` / `commit` / `discard` / `status` sobre `overlayfs`.
42- [x] Manifiesto persistente en `<state_root>/<id>/state.json`; `status` enumera.
43- [x] `commit` promociona archivos y procesa whiteouts (char dev 0/0) como remove.
44- [x] Subcomandos del CLI: `hammer try [targets…]`, `commit <id>`, `discard <id>`, `status`.
45- [x] Tests E2E con bwrap+user-ns, gateados en `HAMMER_OVERLAY_TESTS=1` (kernel-dependiente).
46- [x] Hook al diario en `commit` (Fase 3 lo añadió vía `commit_with_journal`).
47- [ ] Anidación real de overlays (un solo overlay activo por target hoy).
48
49### Fase 3 — Diario de mutaciones  ▶ *en progreso*
50- [x] Crate `hammer-journal`: `MutationEvent`, `Source` (HammerHydrate/HammerCommit/External),
51      append/read/tail/follow JSON-líneas. RFC 3339 sin chrono.
52- [x] `hammerd` con `fanotify` (FAN_CLOSE_WRITE) sobre `/bin`,`/sbin`,`/usr/bin`,`/usr/sbin`,
53      `/lib`,`/usr/lib`,`/etc`. Filtra eventos bajo overlays activos. Fallback graceful sin
54      CAP_SYS_ADMIN.
55- [x] `hammer journal [--tail N] [--follow] [--format pretty|json]`.
56- [x] `hammer commit` registra cada archivo promocionado vía `commit_with_journal`.
57- [ ] Refinar op del watcher (Create vs Replace vs Edit con FAN_REPORT_DFID_NAME).
58- [ ] Hash del contenido tras la mutación (`content_hash`) y de-dup idempotente.
59
60### Fase 4 — Formato y flujo `.swm`
61- [ ] `Swm` (de/serialización YAML), `hammer export`, `hammer apply` (con overlay), `verify`.
62- **Hecho cuando:** exportas un cambio, lo aplicas en otra máquina y reproduce idéntico.
63
64### Fase 5 — Bus de agente
65- [ ] `/run/init.control` (FIFO humano) + `/run/agent.sock` (JSON-líneas, `SO_PEERCRED`).
66- [ ] Comandos `COMPILE`/`INJECT`/`QUERY`/`INIT`; eventos `BUILD_*`/`CRASHED`/`MODIFIED`.
67- **Hecho cuando:** un cliente externo dispara un build y recibe el evento de fin por el socket.
68
69### Fase 6 — Integración de la IA
70- [ ] Cliente de agente; traductor intención NL → `.swm`; bucle plan→build→try→verify→propose.
71- **Hecho cuando:** una intención en lenguaje natural produce un cambio probado en overlay,
72  presentado para `commit` humano.
73
74---
75
76## Track posterior — distro propia
77- Reemplazar el init de Alpine por **tu init** (bus por pipes nativo).
78- **Bootstrap from-scratch** con `zig`/`musl-cross-make` (Stage 0/1/2 → imagen destino).
79- Userland propio (busybox/toybox a elección), `/etc/service/*` propios.
80- Decidir particionado/montaje de `/store` y `/var/lib/hammer`.
81- Log de transparencia para compartir en comunidad ([SDD 09](09-trust-model.md) §4).
82- Mini-lenguaje de consulta del sistema para la IA ([SDD 08](08-ai-integration.md) §6).
83
84---
85
86## Estado actual
87- ✅ Repo y workspace Rust inicializados.
88- ✅ SDDs y ADRs redactados.
89- ✅ Esqueletos de crates que compilan (`hammer build` stub).
90- ⏭️ Siguiente: implementar el sandbox de build real (Fase 0) y montar la VM/LXC Alpine.
91
92## Notas de entorno
93- Desarrollo principal: laptop del autor.
94- Host actual: Proxmox (`gioser.net`). La VM/LXC Alpine de pruebas vivirá aquí o en la laptop.
95- 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 ✅

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.
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, patchelf para 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 ✅

Crate hammer-overlay: try / commit / discard / status sobre overlayfs.
Manifiesto persistente en <state_root>/<id>/state.json; status enumera.
commit promociona archivos y procesa whiteouts (char dev 0/0) como remove.
Subcomandos del CLI: hammer try [targets…], commit <id>, discard <id>, status.
Tests E2E con bwrap+user-ns, gateados en HAMMER_OVERLAY_TESTS=1 (kernel-dependiente).
Hook al diario en commit (Fase 3 lo añadió vía commit_with_journal).
Anidación real de overlays (un solo overlay activo por target hoy).

Fase 3 — Diario de mutaciones ▶ en progreso

Crate hammer-journal: MutationEvent, Source (HammerHydrate/HammerCommit/External), append/read/tail/follow JSON-líneas. RFC 3339 sin chrono.
hammerd con fanotify (FAN_CLOSE_WRITE) sobre /bin,/sbin,/usr/bin,/usr/sbin, /lib,/usr/lib,/etc. Filtra eventos bajo overlays activos. Fallback graceful sin CAP_SYS_ADMIN.
hammer journal [--tail N] [--follow] [--format pretty|json].
hammer commit registra cada archivo promocionado vía commit_with_journal.
Refinar op del watcher (Create vs Replace vs Edit con FAN_REPORT_DFID_NAME).
Hash del contenido tras la mutación (content_hash) y de-dup idempotente.

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.