sergioandClaude Opus 4.8
8bf1623044
Arranque del proyecto hammer (distro AI-nativa: laboratorio funcional en el sótano, terminal mutable clásica arriba, integración de IA programadora). - Workspace Rust (compila, tests verdes): hammer-core, hammer-build, hammer-cli (bin `hammer`), hammerd. - SDDs 00-10 + 6 ADRs en docs/ con toda la arquitectura. - Esqueletos navegables mapeados a las fases del roadmap; Fase 0/1 listas para implementar el sandbox real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
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 hammer 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,
/storey/var/lib/hammerviven 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 cccubre 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.