#0005 — Pas de submodules

#Contexte

• Le dépôt hub héberge la documentation, les scripts et la structure organisationnelle de référence.
• Le répertoire projects/ sert uniquement de conteneur pour des dépôts Git indépendants présents ou futurs.
• Git propose les submodules pour embarquer un dépôt dans un autre, mais ce mécanisme ne correspond pas à l'objectif de ce hub.

#Décision

• Ne pas utiliser de submodules dans le dépôt hub.
• Ne jamais référencer les projets de projects/ via .gitmodules.
• Préférer des dépôts totalement indépendants, versionnés et publiés séparément.

#Raisons

• Éviter la complexité opérationnelle propre aux submodules (initialisation, mise à jour, synchronisation des commits parents/enfants).
• Supprimer la friction lors des opérations clone, pull et des workflows de maintenance.
• Maintenir l'indépendance stricte des projets vis-à-vis du hub.
• Conserver une structure simple, lisible et prévisible pour la maintenance personnelle.
• Rester aligné avec un usage itératif et pragmatique du hub.

#Conséquences

#Positives

• Workflow Git plus direct et sans gestion croisée de sous-dépôts.
• Vision claire des responsabilités du dépôt hub versus celles des projets.
• Clonage et maintenance simplifiés, sans commandes supplémentaires.
• Séparation nette entre documentation partagée et projets applicatifs.

#Négatives

• Absence de référence versionnée entre le hub et les projets stockés dans projects/.
• Impossibilité d'obtenir une vue intégrée d'un projet depuis le dépôt parent sans se rendre dans son dépôt dédié.

#Alternatives considérées

• Submodules Git : rejetés car jugés trop complexes et fragiles pour ce cas personnel.
• Monorepo : rejeté afin que chaque projet conserve son dépôt, ses dépendances et son historique.

#Statut

Accepté.