# Architecture Decision Records — gitea-dashboard ## ADR-001 : Stack Python + requests + rich **Date** : 2026-03-10 **Statut** : accepte **Contexte** : Besoin d'un outil CLI de dashboard pour Gitea. Choix du langage et des librairies. **Decision** : Python avec requests pour les appels API et rich pour le formatage terminal. **Consequences** : - Stack simple et maitrisee par l'utilisateur - Pas de framework CLI lourd (argparse suffit si besoin) - rich offre des tableaux et couleurs sans configuration complexe - Dependance a requests (pas de client async, acceptable pour un affichage unique) ## ADR-002 : 4 modules maximum (client, collector, display, cli) **Date** : 2026-03-10 **Statut** : accepte **Contexte** : Definir la granularite des modules Python pour un projet simple (dashboard CLI). **Decision** : Limiter a 4 modules avec des responsabilites claires : `client.py` (API), `collector.py` (agregation), `display.py` (formatage), `cli.py` (entree). **Consequences** : - Separation des responsabilites sans over-engineering - Chaque module est testable independamment - Un fichier = une responsabilite = un jeu de tests - Si le projet grandit, chaque module peut evoluer independamment ## ADR-003 : Pas de parallelisation en v1 **Date** : 2026-03-10 **Statut** : accepte **Contexte** : La collecte de donnees necessite N appels par repo (release + milestones). La parallelisation (ThreadPoolExecutor) est possible mais ajoute de la complexite. **Decision** : V1 en sequentiel. La parallelisation est differee a v1.1+. **Consequences** : - Code plus simple a ecrire, deboguer et tester - Temps de reponse acceptable pour < 20 repos (estimee < 10s) - Pas de problemes de concurrence - Facile a ajouter plus tard sans changer les interfaces (le collecteur est le seul point d'appel)