À propos du projet

dotfiles-web est le centre de présentation public et de documentation du système dotfiles dotgibson, décrit dans le README comme un environnement terminal à trois couches et onze dépôts (Core → OS-native → Role). Il documente ce système plutôt que de configurer une machine, il ne fait donc explicitement pas partie des trois couches. Le site est construit avec Astro, utilise le thème Tokyo Night et est déployé sur GitHub Pages. Structure Le README liste cinq routes principales : une page d'accueil avec le hero, le modèle à trois couches, la carte des dépôts et les instructions d'installation ; une page de démarrage avec des conseils d'installation par plateforme ; une page d'architecture couvrant le modèle de couches, la logique des subtrees, le chargeur et des analyses approfondies ; un hub de documentation avec des concepts, des guides, des références et une page générée par dépôt ; et un changelog qui reflète le fichier CHANGELOG.md de chaque dépôt. Contenu piloté par les données Le site se décrit comme étant piloté par les données et largement dérivé des sources : les cartes de présentation, les pages de documentation par dépôt, la bande « by the numbers » et le changelog proviennent de fichiers sous src/data ainsi que des dépôts frères, afin que la documentation ne diverge pas silencieusement du code qu'elle décrit. Les entrées modifiables incluent src/data/site.ts (nom du site, propriétaire, navigation, liens GitHub), src/data/repos.ts (carte des dépôts, prose par dépôt et statut), src/data/install.ts (étapes d'installation par plateforme) et les pages Markdown sous src/content/docs. Quatre collecteurs sous scripts/ dérivent des données générées à partir des dépôts frères : collect-metrics.mjs produit generated.json à partir des onze dépôts dotfiles ; collect-snippets.mjs produit snippets.json à partir de huit fichiers sélectionnés dans six dépôts ; collect-corpus.mjs produit corpus.json à partir de htpx ; et collect-coverage.mjs produit coverage.json à partir de dotfiles-Defense. Strictitude et gardes de provenance npm run data est décrit comme le chemin de publication et est strict : l'absence d'un dépôt, ou un dépôt frère positionné sur une branche de fonctionnalité ou contenant des modifications non commitées dans un fichier lu par les collecteurs, fait échouer l'exécution. Le README explique que ce contrôle existe car un dotfiles-core extrait sur une branche de fonctionnalité a un jour publié une entrée de changelog absente de la branche main de Core. Les collecteurs individuels et npm run data:lenient restent souples pour les exécutions exploratoires ; le README distingue un cas inoffensif (dépôt source absent — fichier commité intact, exit 0) d'un cas qui écrit tout de même des données contaminées (flotte présente mais non propre, marquée generatedFrom.clean: false). Deux gardes lisent ce verdict de provenance : un hook de pré-commit installé par npm install ou npm run hooks:install (une machine, couvre generated.json et snippets.json) et une tâche CI committed-data-provenance dans data-freshness.yml (chaque PR). Le hook s'interrompt bruyamment lorsque core.hooksPath est défini et peut être contourné avec DOTFILES_ALLOW_DIRTY_DATA=1 ou --no-verify ; la tâche CI ne le peut pas. Automatisation fleet-sync.yml exécute les quatre collecteurs chaque semaine et ouvre une PR lorsque la sortie diverge. data-freshness.yml fait échouer la CI lorsqu'un des quatre fichiers commités ne correspond plus à sa source, et additionally lorsque la version Core de generated.json est en retard sur la dernière version de dotfiles-core. Le push vers main déclenche deploy.yml (build Astro → GitHub Pages), et les dépôts sources peuvent demander une reconstruction via repository_dispatch, authentifié par un jeton GitHub App à courte durée de vie comme décrit dans docs/WEBHOOK-SETUP.md. Développement Les prérequis sont Node.js avec npm ; le projet est un projet Astro standard. Les commandes incluent npm run dev (serveur de dev local), npm run build (build de production dans dist/), npm run preview et npm run check (vérifications de type Astro et de collections de contenu). Les conseils de contribution demandent aux contributeurs de traiter les dépôts sources comme canoniques, de garder le contenu dans les fichiers de données plutôt que de le coder en dur dans les pages, et de passer npm run check et npm run build avant de pusher. Une licence MIT est stipulée.