Sergio
97ceb72411
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.
35 lines
1.5 KiB
Markdown
35 lines
1.5 KiB
Markdown
# 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 `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.
|