Un entorno de desarrollo que se puede reconstruir, inspeccionar y cambiar con seguridad.

Dotfiles empezó como una forma de conservar ajustes de shell y terminó convirtiéndose en una pregunta de ingeniería: ¿cómo reconstruir una estación de trabajo sin depender de memoria, pasos invisibles o cambios peligrosos sobre el directorio personal? El proyecto responde con una arquitectura operativa para Ubuntu y WSL2 en la que configuración, secretos, herramientas y flujos asistidos por agentes pueden evolucionar sin mezclarse en un único script de instalación.

El problema no era copiar archivos

Una colección de ficheros enlazados resuelve la sincronización, pero no explica qué instala una máquina nueva, qué materializa la configuración del usuario, qué actualiza herramientas ya instaladas ni qué acciones pueden modificar el sistema. Cuando esas responsabilidades se confunden, una operación rutinaria puede sobrescribir configuración local o convertir el estado de una máquina en algo imposible de reproducir.

El proyecto trata esas diferencias como parte del diseño. Las operaciones de diagnóstico son de solo lectura por defecto; las mutaciones importantes requieren una intención explícita; y la documentación describe tanto el recorrido normal como sus límites. La seguridad aquí no es una promesa abstracta: está expresada en contratos de comandos, comprobaciones y pruebas.

Tres capas con responsabilidades distintas

La arquitectura separa tres ciclos que suelen acabar acoplados:

• Bootstrap prepara dependencias y comprueba si la máquina está lista.
• Materialización usa Chezmoi para calcular y aplicar el estado de configuración que debe llegar al entorno del usuario.
• Mantenimiento actualiza sistema y herramientas sin fingir que sustituye a la materialización de Chezmoi.

SOPS y age mantienen los secretos cifrados en origen y permiten generar configuración local durante la materialización. Esta separación evita convertir credenciales o estado privado de una máquina en contenido portable. Docker queda acotado a herramientas que necesitan un runtime reproducible, incluidos algunos servicios MCP y la validación visual con Playwright.

La experiencia de desarrollo también es una interfaz

Make ofrece puntos de entrada reconocibles, mientras que utilidades de desarrollo agrupan diagnósticos y flujos frecuentes. El objetivo no es esconder cada herramienta, sino dar a humanos y agentes el mismo vocabulario operativo: inspeccionar antes de aplicar, distinguir validación de mutación y elegir el alcance mínimo de cada cambio.

Esa filosofía se extiende a los flujos con agentes. El repositorio mantiene instrucciones, skills, manifiestos MCP y políticas que separan recursos canónicos de artefactos generados. GitNexus forma parte del soporte para explorar relaciones de código y mantener índices de conocimiento, pero sus operaciones mutables siguen sujetas a una política explícita.

Validación como parte de la arquitectura

El repositorio no confía solo en que una instalación “parezca funcionar”. Una suite Bats cubre contratos de Chezmoi, comandos, hooks, MCP, perfiles, shell, GitNexus y guardas de operaciones del sistema. Las comprobaciones de Python validan tooling especializado, y GitHub Actions ejecuta el agregado de CI junto con la gobernanza MCP, linting y controles de secretos.

Las pruebas usan fixtures y entornos acotados para no aplicar cambios reales sobre el directorio personal. Esa decisión importa tanto como la cantidad de checks: un sistema de validación para dotfiles deja de ser seguro si su propia prueba puede modificar la máquina que pretende proteger.

Qué demuestra el proyecto

Dotfiles demuestra una forma de trabajar con infraestructura personal como producto mantenible: responsabilidades delimitadas, automatización observable, secretos fuera del contenido público, documentación operativa y una ruta de validación proporcional al riesgo. El resultado no es una máquina “mágicamente idéntica”, sino un proceso comprensible para reconstruirla, detectar divergencias y decidir cuándo un cambio es seguro.