645 líneas. Los ADR entran porque en este repo SON documentos vivos, no registros inmutables: el 0013 tiene 5 commits, el 0009 dos. Eso se comprobó antes de decidir, no se asumió por convención general. EXCLUIDOS por ser REGISTRO o generado: docs/evidencia/ (6), el HANDOFF de la noche de KDE (1) y docs/state/ (24, se regenera solo). Reescribir un comando dentro de una evidencia la falsifica. Y el ADR 0016 se excluye de todo barrido, con un aviso adentro para el próximo que barra: habla SOBRE el renombre, así que necesita seguir diciendo 'hammer'. El barrido se lo llevó puesto y lo dejó titulado 'Renombre del sistema: takana → takana'; revertido. Congelados, verificados uno por uno con controles: /opt/hammer, /var/lib/hammer, /usr/bin/hammer, /mnt/vvv/hammer, la URL de gitea, hammer-farm.service, hammer-live-install.sh, BRIEFING-hammer.md, hammerd, hammer-recover y HAMMER_LIVE.
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 takana: 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
takana. - 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.