# 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 `deps` explí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.