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 0004 — No escribir nuestro propio Nix
- Estado: aceptada
- Fecha: 2026-06-06
Contexto
Es tentador escribir desde cero un motor completo de grafo de dependencias con caché content-addressed, resolución, y aislamiento — "nuestro propio Nix". El concepto de hashing de derivaciones es el núcleo de nuestra fábrica.
Decisión
No construir un motor de build genérico tipo Nix desde cero. Implementamos lo mínimo
que necesita hammer: un builder con recetas explícitas, sandbox bubblewrap, hashing CAS
BLAKE3 de entradas conocidas, y un DAG simple de dependencias declaradas. Nada de un lenguaje
funcional, evaluación perezosa, ni resolución general de paquetes.
Razones
- Un motor de grafo hermético con caché correcta es, por sí solo, un proyecto de años.
No es donde está el valor de
hammer. - Nuestro valor es el pegamento AI-nativo (overlay + diario +
.swm+ bus), no reescribir teoría de build ya resuelta. - El alcance mínimo (recetas explícitas + CAS + DAG) cubre las Fases 0–6 sin esa complejidad.
Consecuencias
- No tendremos resolución automática de dependencias estilo distro completa al principio; las
recetas declaran sus
depsexplícitamente. Suficiente para el MVP. - Si en el futuro hiciera falta más potencia de grafo, se evaluará usar Nix como backend de build (no reescribirlo) y sólo hidratar su salida a FHS. Decisión diferida.
- Mantiene el código del lab pequeño, auditable y comprensible — coherente con la filosofía de baja entropía.