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