dotfiles-web

dotfiles-web es el centro de exhibición pública y documentación para el sistema de dotfiles dotgibson, descrito en el README como un entorno de terminal de tres capas y once repositorios (Core → OS-native → Role). Documenta dicho sistema en lugar de configurar una máquina, por lo que explícitamente no es una de las tres capas. El sitio está construido con Astro, utiliza el tema Tokyo Night y está desplegado en GitHub Pages. Estructura El README enumera cinco rutas principales: una página de inicio con el hero, el modelo de tres capas, el mapa de repositorios e instrucciones de instalación; una página de inicio rápido con guía de instalación por plataforma; una página de arquitectura que cubre el modelo de capas, la lógica de subtree, el cargador y análisis profundos; un centro de documentación con conceptos, guías, referencias y una página generada por repositorio; y un registro de cambios (changelog) que refleja el CHANGELOG.md de cada repositorio. Contenido basado en datos El sitio se describe como basado en datos y derivado en gran medida de las fuentes: las tarjetas de exhibición, las páginas de documentación por repositorio, la franja de "números" y el changelog provienen de archivos en src/data más los repositorios hermanos, evitando que la documentación se desvíe del código que describe. Las entradas editables incluyen src/data/site.ts (nombre del sitio, propietario, navegación, enlaces de GitHub), src/data/repos.ts (mapa de repositorios, prosa por repositorio y estado), src/data/install.ts (pasos de instalación por plataforma) y páginas Markdown en src/content/docs. Cuatro colectores en scripts/ derivan datos generados de los repositorios hermanos: collect-metrics.mjs produce generated.json desde los once repositorios de dotfiles; collect-snippets.mjs produce snippets.json desde ocho archivos seleccionados en seis repositorios; collect-corpus.mjs produce corpus.json desde htpx; y collect-coverage.mjs produce coverage.json desde dotfiles-Defense. Estrictura y guardias de procedencia npm run data se describe como la ruta de publicación y es estricta: la falta de un repositorio, o un hermano ubicado en una rama de funcionalidad o con ediciones no confirmadas en un archivo que los colectores lean, provoca el fallo de la ejecución. El README explica que este control existe porque una vez, un dotfiles-core en una rama de funcionalidad publicó una entrada de changelog que no estaba en la rama main de Core. Los colectores individuales y npm run data:lenient se mantienen flexibles para ejecuciones exploratorias; el README distingue un caso inofensivo (repositorio fuente ausente — archivo confirmado intacto, salida 0) de uno que escribe datos contaminados (flota presente pero no limpia, marcada con generatedFrom.clean: false). Dos guardias leen ese veredicto de procedencia: un hook de pre-commit instalado mediante npm install o npm run hooks:install (una máquina, cubre generated.json y snippets.json) y un trabajo de CI de committed-data-provenance en data-freshness.yml (cada PR). El hook se omite ruidosamente cuando core.hooksPath está configurado y puede evitarse con DOTFILES_ALLOW_DIRTY_DATA=1 o --no-verify; el trabajo de CI no puede. Automatización fleet-sync.yml ejecuta los cuatro colectores semanalmente y abre un PR cuando los resultados varían. data-freshness.yml falla la CI cuando cualquiera de los cuatro archivos confirmados ya no coincide con su fuente, y adicionalmente cuando la versión de Core en generated.json está retrasada respecto al último lanzamiento de dotfiles-core. Hacer push a main activa deploy.yml (construcción de Astro → GitHub Pages), y los repositorios fuente pueden solicitar una reconstrucción vía repository_dispatch, autenticado mediante un token de GitHub App de corta duración como se describe en docs/WEBHOOK-SETUP.md. Desarrollo Los requisitos previos son Node.js con npm; el proyecto es un proyecto Astro estándar. Los comandos incluyen npm run dev (servidor de desarrollo local), npm run build (construcción de producción en dist/), npm run preview y npm run check (verificaciones de tipo y colección de contenido de Astro). La guía de contribución pide a los colaboradores tratar los repositorios fuente de verdad como canónicos, mantener el contenido en los archivos de datos en lugar de codificarlo directamente en las páginas, y pasar npm run check y npm run build antes de hacer push. Se indica una Licencia MIT.