hammer/docs/00-vision.md

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).
• No compila contra HEAD vivo a ciegas (ver ADR 0006).
• 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).