Proyecto
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?
La tesis estable actual es más amplia:
Dotfiles ha evolucionado de configuración personal reproducible a un harness gobernado de desarrollo y agentes que hace inspeccionables el estado del entorno, las capacidades disponibles, el tooling semántico, la validación y las fronteras de mutación.
Esa evolución no convierte el Project en un changelog. La serie pública v0.3 → v0.4 → v0.5 cuenta las lecciones; esta página mantiene el mapa durable.
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.
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. Docker queda acotado a herramientas que necesitan un runtime reproducible, incluidos algunos servicios MCP y la validación visual con Playwright.
El harness compartido: devx
Sobre esa base, Dotfiles materializa un harness operativo compartido:
devx
→ discovery de capacidades de agente
→ inventory / orientación
→ project diagnostics
→ ownership de herramientas
→ frescura y riesgo de GitNexus
→ inteligencia semántica via Serena
→ facade Playwright
→ operaciones de release gobernadasPrincipio crítico: los contratos pertenecen al proyecto consumidor. Dotfiles no impone a cada repositorio los mismos language servers, scripts o defaults. Diagnostica readiness; no muta silenciosamente la configuración semántica ajena.
Validación como parte de la arquitectura
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 gobernanza MCP, linting y controles de secretos.
Las pruebas usan fixtures y entornos acotados para no aplicar cambios reales sobre el directorio personal.
Serie de evolución
Para el recorrido reciente del harness:
- v0.3 — capacidades, Serena y releases gobernadas
- v0.4 — inventory, diagnostics y riesgo con evidencia
- v0.5 — semántica por proyecto y localhost sin fricción
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 — también cuando quien opera es un agente.