1# ADR 0002 — Validar sobre Alpine antes de la distro propia
2
3- **Estado:** aceptada
4- **Fecha:** 2026-06-06
5
6## Contexto
7
8El instinto es construir la distro desde el bootstrap (toolchain, init, userland) y luego poner
9la capa AI-nativa encima. Pero el bootstrap from-scratch es el trabajo más largo y arriesgado
10del proyecto (meses), y **no es donde está la innovación**. La innovación es la capa AI-nativa:
11build determinista + mutable + diario + `.swm`.
12
13## Decisión
14
15Montar y validar toda la capa de `takana` **sobre Alpine Linux** (Fases 0–6). Sólo después,
16una vez probado el concepto, bajar a la distro propia (track posterior).
17
18## Razones
19
20- Alpine ya es **musl + busybox + FHS mutable + minimalista** — exactamente nuestra filosofía,
21 ya cocida y mantenida.
22- Permite validar el bucle disruptivo (overlay, diario, `.swm`, bus de IA) **en semanas**, no
23 meses.
24- Todo el tooling (Rust) y el lab (`zig cc`) se reusan sin retrabajo cuando bajemos a la distro
25 propia: cambia el *suelo*, no las herramientas.
26
27## Consecuencias
28
29- En la fase Alpine, `/store` y `/var/lib/hammer` viven dentro del rootfs de Alpine; el init es
30 el de Alpine (OpenRC), no el propio. El bus por pipes nativo del init propio es track posterior.
31- No probamos el bootstrap completo en esta fase; `zig cc` cubre la compilación sin necesitar
32 bootstrap (ver [ADR 0003](0003-zig-cc-builder.md)).
33- Riesgo: alguna fricción musl/static en Alpine que no represente la distro propia. Aceptable —
34 Alpine es musl real, la fricción es representativa.
0002-alpine-first.md
ADR 0002 — Validar sobre Alpine antes de la distro propia
- Estado: aceptada
- Fecha: 2026-06-06
Contexto
El instinto es construir la distro desde el bootstrap (toolchain, init, userland) y luego poner
la capa AI-nativa encima. Pero el bootstrap from-scratch es el trabajo más largo y arriesgado
del proyecto (meses), y no es donde está la innovación. La innovación es la capa AI-nativa:
build determinista + mutable + diario + .swm.
Decisión
Montar y validar toda la capa de takana sobre Alpine Linux (Fases 0–6). Sólo después,
una vez probado el concepto, bajar a la distro propia (track posterior).
Razones
- Alpine ya es musl + busybox + FHS mutable + minimalista — exactamente nuestra filosofía,
ya cocida y mantenida.
- Permite validar el bucle disruptivo (overlay, diario,
.swm, bus de IA) en semanas, no
meses.
- Todo el tooling (Rust) y el lab (
zig cc) se reusan sin retrabajo cuando bajemos a la distro
propia: cambia el suelo, no las herramientas.
Consecuencias
- En la fase Alpine,
/store y /var/lib/hammer viven dentro del rootfs de Alpine; el init es
el de Alpine (OpenRC), no el propio. El bus por pipes nativo del init propio es track posterior.
- No probamos el bootstrap completo en esta fase;
zig cc cubre la compilación sin necesitar
bootstrap (ver ADR 0003).
- Riesgo: alguna fricción musl/static en Alpine que no represente la distro propia. Aceptable —
Alpine es musl real, la fricción es representativa.