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 `takana`: 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 `takana`.
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.