# SDD 00 — Visión y filosofía

## 1. El problema

El panorama de distribuciones Linux te obliga a elegir entre dos extremos malos:

- **Inmutables / declarativas** (NixOS, Guix, Fedora Silverblue): determinismo y
  reproducibilidad reales, pero a costa de tu agencia. El sistema operativo *es* el grafo.
  Pierdes la estructura familiar de directorios, pierdes el control directo en la terminal,
  y vives editando un archivo de configuración abstracto en lugar de habitar el sistema.
  Para una herramienta de automatización (una IA), además, la complejidad está *oculta tras
  capas de abstracción* que la obligan a simular a un humano.

- **Tradicionales / imperativas** (Arch, Gentoo, Slackware): control y mutabilidad totales,
  pero con el tiempo se pudren — el gestor de paquetes pierde el rastro de lo que el usuario
  hizo a mano, se acumulan archivos huérfanos, y reproducir tu sistema en otra máquina es
  imposible sin documentar cada acción manualmente.

Ninguno de los dos sirve bien para el escenario que viene: **un usuario con una IA
programadora que entiende, modifica y comparte su sistema en cualquier contexto.**

## 2. La tesis

Se puede tener lo mejor de ambos separando dos mundos que hoy están fusionados:

> **La automatización funcional es mi empleada en el sótano. En el piso de arriba mando yo.**

- **El sótano (el laboratorio):** compilación determinista, hermética, direccionada por
  contenido. Aquí reina la teoría de grafos y el hashing. Cero efectos secundarios.
- **El piso de arriba (el userland):** un Linux clásico, mutable, con `/bin`, `/lib`, `/etc`
  reales. Aquí reina el usuario. Un `rm -rf` rompe cosas de verdad. La terminal es un espacio
  vivo de interacción directa, no la interfaz de lectura de un archivo de config.

El puente entre ambos es la **hidratación**: los artefactos del store se proyectan al FHS
real por hardlinks, normalizados para no arrastrar rutas del store.

## 3. Por qué esto es AI-nativo (el verdadero diferenciador)

La distro en sí no es la innovación — ensamblar componentes conocidos (musl, busybox, un
kernel) es trabajo conocido. **La innovación es el substrato de baja entropía** que resulta:

1. **Compilación determinista** → la IA pide cambios de fuente, recompila en el lab aislado,
   y el binario es predecible. Vuelve atrás sin dramas.
2. **El sistema ejecutable es texto plano + binarios atómicos** → la IA no parsea bases de
   datos binarias de configuración (registro de Windows, journal de systemd). Lee/escribe
   archivos e inspecciona binarios con `readelf`/`objdump`.
3. **Mutabilidad = agencia real** → la IA experimenta en un overlay y promueve cambios. Si se
   equivoca, desmontas la capa. Sin rollbacks complejos ni snapshots pesados.
4. **musl mantiene el código C legible** para el contexto de un LLM (glibc es un laberinto de
   macros prehistóricas).
5. **El enlazado estático** garantiza que una herramienta mutada por la IA corre sin romper
   enlaces de librerías en otros programas.

Mientras la industria diseña sistemas para *proteger al sistema del administrador*
(restringiendo, aislando, inmutabilizando) — y al hacerlo también ciega a las herramientas de
IA — `hammer` hace lo contrario: **mantiene las tuberías expuestas y de baja entropía**, y
trata al usuario (y a su IA) como un operador consciente, no como un peligro.

## 4. Principios de diseño

- **Determinismo en la fábrica, libertad en la ejecución.** No negociar ninguno de los dos.
- **Texto plano y binarios atómicos por encima de bases de datos opacas.** Si algo del sistema
  no se puede `cat`, `grep` o `readelf`, es una bandera roja.
- **Verificar, no confiar.** Se comparten recetas reproducibles, nunca binarios cocidos.
- **La IA propone; el humano dispone.** Toda acción de la IA es reversible y queda registrada.
- **No reinventar lo resuelto.** Usamos motores y compiladores existentes como herramientas;
  el valor está en el pegamento AI-nativo, no en reescribir Nix o un toolchain.
- **El diario es la verdad.** Vives imperativamente; el sistema deriva el estado declarativo
  *a posteriori*. Nunca al revés.

## 5. Anti-objetivos (lo que `hammer` NO es)

- No es un gestor de paquetes inmutable ni un daemon que restaura estado.
- No reescribe un motor de build desde cero (ver [ADR 0004](adr/0004-no-custom-nix.md)).
- No compila contra `HEAD` vivo a ciegas (ver [ADR 0006](adr/0006-pinned-commits.md)).
- No oculta complejidad tras abstracciones que cieguen al usuario o a la IA.
- No promete estabilidad de ABL de musl como magia (ver [SDD 03](03-hydration.md)).